Unix руководство для системного администратор э немет

Unix и Linux. Руководство системного администратора. 5 e издание 2020Это современное и полное руководство по инсталляции, настройке и обслуживанию любой системы UNIX или Linux, включая системы, предоставляющие базовую инфраструктуру Интернета и облачную инфраструктуру.

Обновленное с учетом новых дистрибутивов и облачных сред, это всестороннее руководство охватывает лучшие практики для всех аспектов системного администрирования, включая управление хранением данных, проектирование и администрирование сети, безопасность, веб-хостинг, автоматизацию, управление конфигурацией, анализ производительности, виртуализацию, DNS, безопасность и управление IT-организациями. Авторы — специалисты мирового класса — рассмотрели облачные платформы, методологию DevOps, непрерывное развертывание, контейнеризацию, мониторинг и многие другие важные темы.

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

img

Нажмите на звезду, чтобы оценить!

Прочитали: 1 123

Данное издание, появившееся в год, когда исполняется 20 лет со дня появления мирового бестселлера по системному администрированию UNIX, стало еще лучше благодаря описанию распространенных вариантов системы Linux: Ubuntu, openSUSE и RHEL.

Системное администрирование в книге рассматривается с практической точки зрения. Она представляет собой бесценный справочник как для начинающих администраторов, так и для опытных профессионалов. В ней подробно описываются эффективные методы работы и рассматриваются все аспекты системного администрирования, включая управление памятью, проектирование и управление сетями, электронную почту, веб-хостинг, создание сценариев, управление конфигурациями программного обеспечения, анализ производительности, взаимодействие с системой Windows, виртуализацию, DNS, безопасность, управление провайдерами IT-услуг и многое другое.

В данной книге отражены текущие версии следующих операционных систем: Ubuntu®Linux, openSUSE® Linux, Red Hat® Enterprise Linux, Oracle America® Solaris™ (бывший Sun Solaris), HP HP-UX®, IBM AIX®

Описание

В настоящее время в море информации по UNIX и Linux можно утонуть, поэтому мы решили с помощью этой книги проложить свой курс и удовлетворить потребности именно системных администраторов, заняв тем самым вполне конкретную нишу в эко­системе разного рода справочных страниц (man pages), блогов, журналов, книг и прочих справочных материалов. Во-первых, это — руководство, в котором рассматриваются различные компонен­ты основных систем администрирования и принципы их совместной работы. Во мно­гих случаях, когда нам приходилось выбирать между разными реализациями некоторой идеи, мы описывали преимущества и недостатки основных вариантов. Во-вторых, это — краткий справочник, в котором собрано все, что необходимо знать для выполнения задач общего характера в различных версиях UNIX- и Linux-систем. Например, команда ps, отображающая статус текущих процессов, поддерживает более 80 ключей (опций) командной строки в системах Linux. Но всего несколько комбина­ций ключей удовлетворяют 99% нужд системного администратора (см. раздел 5.7). Наконец, в этой книге делается акцент на администрировании корпоративных сер­веров и сетей, т.е. на серьезной теме системного администрирования. Несложно установить операционную систему на отдельном компьютере, гораздо труднее поддерживать устойчивую работу виртуализированной сетевой среды при больших нагрузках, сбоях в работе дисков и умышленных атаках. Поэтому мы описываем методы и практические способы, которые позволят вам “поднимать” “упавшие” сети, а также выбирать решения, которые останутся актуальными при расширении и усложнении вашего сайта и из­менении его гетерогенности. Мы не претендуем на абсолютную степень объективности в решении перечисленных выше задач, поэтому по ходу изложения постарались максимально ясно пояснить свои субъективные взгляды и предпочтения. Особенность системного администрирования заключается в том, что опытные администраторы могут иметь совершенно разные пред­ставления о правилах и процедурах управления системами. Читателям придется само­стоятельно решать, какой именно материал и в какой степени соответствует той среде, в которой они работают.

Здесь будут храниться ваши отложенные товары.

Вы сможете собирать коллекции книг,
а мы предупредим, когда отсутствующие товары снова появятся в наличии!


Ваша корзина невероятно пуста.
Не знаете, что почитать?

Лабиринт.Сейчас


Здесь наша редакция собирает для вас
лучшие книги и важные события.

Главные книги


А тут читатели выбирают все самое любимое.


Сумма без скидки


0
р.


Вы экономите


0
р.


Итого
подарков:
со скидкой


0
р.

Оформить

На складе

Unix and Linux/ System Administration Handbook

Издательство: Вильямс, 2020 г.

ID товара: 749458

ISBN: 978-5-907144-10-1

Страниц: 1168 (Офсет)

Оформление

Масса: 1660 г

Размеры: 240x180x55 мм

Аннотация к книге «Unix и Linux. Руководство системного администратора»

«Как автор, редактор и издатель, я никогда не придавал большого значения конкуренции — за исключением нескольких случаев. Это один из таких случаев. Unix System Administration Handbook — это одна из немногих книг, на которые мы равняемся».
— Тим О’Рейли, основатель компании O’Reily Media.
«Это издание предназначено для тех, чьи системы работают в облаке или в виртуализированных центрах обработки данных; тех, чья административная работа в основном принимает форму исходного кода автоматизации и конфигурации; тех, кто тесно сотрудничает с разработчиками, сетевыми инженерами, сотрудниками по вопросам соблюдения требований и всеми другими рабочими пчелами, которые обитают в современном улье.»
— Пол Викси (Paul Vixie), изобретатель и основатель компаний ISC и Farsight Security, лауреат премии Зал Славы Интернета (Internet Hall of Fame).
Это современное и полное руководство по инсталляции, настройке и обслуживанию любой системы UNIX или Linux, включая системы, предоставляющие…


Читать полностью


1 акция по этому товару сегодня

Осталось:

0
7

дней

1
7

часов



45 %

Рецензии на книгу «Unix и Linux. Руководство системного администратора»

  • Покупатели 1

Вы можете стать одним из первых, кто напишет
рецензию на эту книгу,
и получить бонус
— до 15 рублей на баланс в Лабиринте!
Или оставьте заявку, чтобы кто-то другой написал ее скорее.

zakhar

Понравилось?
Да

|

Рейтинг:

+4

Скажу сразу, книга сама по себе очень достойная. Как по объёму, так и по затрагиваемым темам. Но, как обычно, есть несколько НО которые сильно портят впечатление. Добрые люди нашли экземпляр и дали полистать. Довольно быстро пришло ощущение, что где-то что-то не так пишут. Взял оригинал на английском, сверил — не ошибся, действительно не так.
1) Неточности перевода. Не то чтобы они с ног на голову переворачивали смысл, но действительно сильно искажают информацию по отношению к оригиналу. В…


Читать полностью

Асипова Кристина

(рецензий 2 / оценок +13)

Понравилось?
Да

|

Рейтинг:

+10

Великолепная книга, но на удивление необоснованно завышенная цена на нее в Лабиринте

odj

Понравилось?
Да

|

Рейтинг:

+5

Перед нами легендарная «красная книга» (только почему-то теперь она стала какой-то голубой.. видимо, влияние Линукс).
Но с учетом того, что в августе 2017 выходит уже 5-е издание (доступен предзаказ на английском), имеет смысл 10 раз подумать, прежде, чем покупать по такой цене. Сисадмины ведь не олигархи, а книга носит скорее справочный характер (хоть и является своего рода библией юниксовода, наряду с Unix Power Tools и еще парой книжек).

Короче, если есть бабки — берите, не…


Читать полностью

Популярные книги в этом жанре

Внимание!
Если вы обнаружили ошибку в описании

книги «Unix и Linux. Руководство системного администратора» (авторы Эви Немет, Гарт Снайдер, Хейн Трент Р.)

, пишите об этом в сообщении об ошибке. Спасибо!

  • Доставка и оплата
  • Сертификаты
  • Рейтинги
  • Новинки
  • Скидки
  • 8 800 600-95-25
  • Контакты
  • Поддержка
  • 24 пункта самовывоза
  • Главное 2023
  • Все книги
  • Билингвы

    • Назад в «Книги»
    • Все книги в жанре «Билингвы»

    • Все книги жанра

    • Билингвы для детей

    • Билингвы. Английский язык

    • Билингвы. Другие языки

    • Билингвы. Испанский язык

    • Билингвы. Итальянский язык

    • Билингвы. Немецкий язык

    • Билингвы. Французский язык

  • Книги для детей

    • Назад в «Книги»
    • Все книги в жанре «Книги для детей»

    • Все книги жанра

    • Детская художественная литература

    • Детский досуг

    • Первые книги малыша. Развитие ребенка

    • Познавательная литература для детей

  • Книги на иностранных языках

    • Назад в «Книги»
    • Все книги в жанре «Книги на иностранных языках»

    • Все книги жанра

    • Книги на английском языке

    • Книги на других языках

    • Книги на испанском языке

    • Книги на итальянском языке

    • Книги на немецком языке

    • Книги на французском языке

  • Комиксы, Манга, Артбуки

    • Назад в «Книги»
    • Все книги в жанре «Комиксы, Манга, Артбуки»

    • Все книги жанра

    • Артбуки. Игровые миры. Вселенные

    • Комиксы

    • Комиксы для детей

    • Манга

    • Манга для детей

    • Новеллизации

    • Образовательные комиксы

    • Ранобэ

    • Фан-сувениры

  • Молодежная литература
  • Нехудожественная литература

    • Назад в «Книги»
    • Все книги в жанре «Нехудожественная литература»

    • Все книги жанра

    • Бизнес. Экономика

    • Государство и право. Юриспруденция

    • Домашние ремесла. Рукоделие

    • Домоводство

    • Естественные науки

    • Информационные технологии

    • История. Исторические науки

    • Книги для родителей

    • Коллекционирование

    • Красота. Этикет

    • Кулинария

    • Культура. Искусство

    • Медицина и здоровье

    • Охота. Рыбалка. Собирательство

    • Психология

    • Публицистика

    • Развлечения. Праздники

    • Растениеводство

    • Ремонт. Строительство. Интерьер

    • Секс. Камасутра

    • Технические науки

    • Туризм. Путеводители. Транспорт

    • Универсальные энциклопедии

    • Уход за животными

    • Филологические науки

    • Философские науки. Социология

    • Фитнес. Спорт. Самооборона

    • Эзотерика. Парапсихология

  • Периодические издания
  • Религия

    • Назад в «Книги»
    • Все книги в жанре «Религия»

    • Все книги жанра

    • Ислам

    • Религии мира

    • Религиоведение

    • Христианство

  • Учебная, методическая литература и словари

    • Назад в «Книги»
    • Все книги в жанре «Учебная, методическая литература и словари»

    • Все книги жанра

    • Вспомогательные материалы для студентов

    • Демонстрационные материалы

    • Дополнительное образование для детей

    • Дошкольное обучение

    • Иностранные языки: грамматика и учебники

    • Книги для школы

    • Педагогика

    • Подготовка в вуз

    • Пособия для детей с ограниченными возможностями

    • Словари и разговорники

  • Художественная литература

    • Назад в «Книги»
    • Все книги в жанре «Художественная литература»

    • Все книги жанра

    • Афоризмы

    • Басни

    • Детективы

    • Драматургия

    • Историческая проза

    • Классическая проза

    • Отечественный боевик

    • Поэзия

    • Приключения

    • Сентиментальная проза

    • Современная проза

    • Фантастика

    • Фэнтези

    • Эпос и фольклор


  • Скидки
    ·
    Обзоры
    ·
    Рецензии
    ·
    Подборки читателей
    ·
    Новинки
    ·
    Рейтинг
    ·
    Авторы
    ·
    Изд-ва
    ·
    Серии
  • Все книги на иностранном языке
  • Книги на английском языке

    • Назад в «Иностранные»
    • Все книги в жанре «Книги на английском языке»

    • Все книги жанра

    • Книги на английском языке для детей

    • Курсы изучения языка

    • Нехудожественная литература на английском языке

    • Художественная литература на английском языке

  • Книги на других языках

    • Назад в «Иностранные»
    • Все книги в жанре «Книги на других языках»

    • Все книги жанра

    • Литература на других языках

    • Литература на других языках для детей

  • Книги на испанском языке

    • Назад в «Иностранные»
    • Все книги в жанре «Книги на испанском языке»

    • Все книги жанра

    • Литература на испанском языке

    • Литература на испанском языке для детей

  • Книги на итальянском языке
  • Книги на немецком языке

    • Назад в «Иностранные»
    • Все книги в жанре «Книги на немецком языке»

    • Все книги жанра

    • Курсы изучения языка

    • Литература на немецком языке

    • Литература на немецком языке для детей

  • Книги на французском языке

    • Назад в «Иностранные»
    • Все книги в жанре «Книги на французском языке»

    • Все книги жанра

    • Курсы изучения языка

    • Литература на французском языке

    • Литература на французском языке для детей

  • Все игрушки
  • Детское творчество

    • Назад в «Игрушки»
    • Все товары в разделе «Детское творчество»

    • Все товары раздела

    • Алмазные мозаики

    • Витражная роспись

    • Гравюры

    • Другие виды творчества

    • Конструирование из бумаги и другого материала

    • Лепка

    • Наборы для рукоделия

    • Наклейки детские

    • Панч-дыроколы фигурные

    • Работаем с воском, гелем, мылом

    • Работаем с гипсом

    • Работаем с деревом

    • Скрапбук

    • Сопутствующие товары для детского творчества

    • Творческие наборы для раскрашивания

    • Фрески

  • Игры и Игрушки

    • Назад в «Игрушки»
    • Все товары в разделе «Игры и Игрушки»

    • Все товары раздела

    • Все для праздника

    • Головоломки

    • Детские сувениры

    • Детские часы

    • Другие виды игрушек

    • Игрушка-антистресс

    • Игрушки для самых маленьких

    • Игры для активного отдыха

    • Игры с мишенью

    • Книжки-игрушки

    • Конструкторы

    • Куклы и аксессуары для кукол

    • Кукольный театр

    • Магнитные буквы, цифры, игры

    • Машинки и Транспорт

    • Музыкальные инструменты

    • Мягкие игрушки

    • Наборы для тематических игр

    • Настольные игры

    • Научные игры для детей

    • Пазлы

    • Роботы и трансформеры

    • Ростомеры

    • Сборные модели

    • Слаймы

    • Фигурки

    • Электронные игры


  • Скидки
    ·
    Отзывы
    ·
    Новинки
    ·
    Рейтинг
    ·
    Производители
    ·
    Серии
  • Все канцтовары
  • Аксессуары для книг

    • Назад в «Канцтовары»
    • Все товары в разделе «Аксессуары для книг»

    • Все товары раздела

    • Закладки для книг

    • Обложки для книг

  • Глобусы
  • Обложки для документов

    • Назад в «Канцтовары»
    • Все товары в разделе «Обложки для документов»

    • Все товары раздела

    • Другие обложки

    • Конверты для путешествий

    • Обложки для автодокументов

    • Обложки для военных билетов

    • Обложки для зачетных книжек

    • Обложки для паспортов

    • Обложки для проездных билетов

    • Обложки для студенческих билетов

    • Чехлы для карт, обложки для пропусков

  • Офисная канцелярия

    • Назад в «Канцтовары»
    • Все товары в разделе «Офисная канцелярия»

    • Все товары раздела

    • Бумажная продукция для офиса

    • Мелко-офисная канцелярия

    • Офисные принадлежности

  • Папки, скоросшиватели, разделители

    • Назад в «Канцтовары»
    • Все товары в разделе «Папки, скоросшиватели, разделители»

    • Все товары раздела

    • Папки из картона

    • Папки из пластика

    • Папки из текстиля

    • Папки-портфели (с пластиковыми отделениями)

  • Письменные принадлежности

    • Назад в «Канцтовары»
    • Все товары в разделе «Письменные принадлежности»

    • Все товары раздела

    • Карандаши черногрифельные

    • Ручки

  • Принадлежности для черчения

    • Назад в «Канцтовары»
    • Все товары в разделе «Принадлежности для черчения»

    • Все товары раздела

    • Другие виды чертежных принадлежностей

    • Линейки

    • Наборы для черчения, готовальни

    • Транспортиры

    • Треугольники

    • Тубусы

    • Циркули

    • Шаблоны, трафареты, лекала

  • Рисование

    • Назад в «Канцтовары»
    • Все товары в разделе «Рисование»

    • Все товары раздела

    • Аксессуары для рисования

    • Инструменты и материалы для каллиграфии

    • Карандаши цветные

    • Кисти

    • Краски

    • Линеры для творчества

    • Маркеры акварельные

    • Мелки

    • Наборы для рисования

    • Палитры, стаканы-непроливайки

    • Папки для чертежей и рисунков

    • Пастель

    • Тушь, перья

    • Уголь художественный

    • Фломастеры

    • Холсты. Мольберты

  • Сумки
  • Товары для школы

    • Назад в «Канцтовары»
    • Все товары в разделе «Товары для школы»

    • Все товары раздела

    • Веера, счетный материал, счетные палочки

    • Другие виды школьной канцелярии

    • Канцелярские наборы

    • Косметички, кошельки

    • Ластики

    • Мешки для обуви

    • Ножницы школьные

    • Обложки для тетрадей и книг

    • Папки для школьных тетрадей. Папки для труда

    • Пеналы

    • Пластилин

    • Подставки для книг

    • Рюкзаки, портфели

    • Точилки

    • Фартуки. Клеенки для уроков труда

    • Школьная бумажно-беловая продукция

    • Школьные наборы, подставки, органайзеры


  • Для школы
    ·

    Скидки
    ·
    Отзывы
    ·
    Новинки
    ·
    Производители
    ·
    Серии

  • Все CD/DVD
  • Аудио

    • Назад в «CD/DVD»
    • Все товары в разделе «Аудио»

    • Все товары раздела

    • Аудиокниги

    • Музыка

    • Религия

  • Видео

    • Назад в «CD/DVD»
    • Все товары в разделе «Видео»

    • Все товары раздела

    • Документальные фильмы

    • Концерты. Постановки. Мюзиклы. Видеоклипы

    • Мультфильмы

    • Познавательные фильмы

    • Художественные фильмы

    • Эротика

    • Юмор

  • Софт

    • Назад в «CD/DVD»
    • Все товары в разделе «Софт»

    • Все товары раздела

    • Игры

    • Иностранные языки

    • Мультимедиа для школьников и студентов

    • Программное обеспечение и обучение работе на ПК

    • Руководства, справочники и энциклопедии


  • Скидки
    ·
    Отзывы
    ·
    Новинки
    ·
    Рейтинг
    ·
    Производители
    ·
    Серии
  • Каталог журналов
  • Новое в мире толстых литературных журналов
  • Все сувениры
  • Календари

    • Назад в «Сувениры»
    • Все товары в разделе «Календари»

    • Все товары раздела

    • Адвент-календари. Семейные календари-планеры

    • Календари на магните

    • Квартальные календари

    • Настенные календари

    • Настольные календари

  • Сувенирная продукция

    • Назад в «Сувениры»
    • Все товары в разделе «Сувенирная продукция»

    • Все товары раздела

    • Альбомы, рамки для фотографий

    • Воздушные шары

    • Детские сувениры

    • Значки и медали

    • Игрушки для животных

    • Конверты для денег

    • Магниты

    • Новогодние сувениры

    • Открытки

    • Пакеты подарочные

    • Подарочная упаковка

    • Подарочные сертификаты

    • Постеры

    • Праздничные аксессуары

    • Таблички и статусы для рабочего стола

    • Шкатулки

    • Другое


  • Скидки
    ·
    Отзывы
    ·
    Новинки
    ·
    Рейтинг
    ·
    Производители
    ·
    Серии
  • Все товары
  • Мыло
  • Салфетки влажные

  • Скидки
    ·
    Отзывы
    ·
    Новинки
    ·
    Рейтинг
    ·
    Производители
    ·
    Серии
  • Весь клуб
  • Журнал

    • Назад в «Клуб»
    • Лабиринт. Сейчас

    • Детский навигатор

    • Новости Лабиринта

    • Книжные обзоры

    • Рецензии читателей

    • Подборки читателей

    • Литературные премии

  • Скидки и подарки

    • Назад в «Клуб»
    • Акции

    • Бонус за рецензию

  • Только у нас

    • Назад в «Клуб»
    • Главные книги

    • Подарочные сертификаты

    • Эксклюзивы

    • Предзаказы

  • Развлечения

    • Назад в «Клуб»
    • Литтесты

    • Конкурсы

    • Дома с детьми

  • Лабиринт — всем

    • Назад в «Клуб»
    • Партнерство

  • Приложения Лабиринта

    • Назад в «Клуб»
    • Apple App Store

    • Google Play

    • Huawei AppGallery

Журнал

  • Лабиринт. Сейчас

  • Детский навигатор

  • Новости Лабиринта

  • Книжные обзоры

  • Рецензии читателей

  • Подборки читателей

  • Литературные премии





  • Школа
  • Игрушки
  • Канцтовары
  • CD/DVD
  • Сувениры
  • Журналы
  • Товары для дома

Мы используем файлы cookie и другие средства сохранения предпочтений и анализа действий посетителей сайта.
Подробнее в пользовательском соглашении. Нажмите «Принять», если даете согласие на это.

Авторизируясь в Лабиринте, я подтверждаю, что я старше 18 лет, принимаю условия пользовательского соглашения и даю добровольное согласие на обработку своих персональных данных и получение E-mail / SMS и Viber рассылок с информацией об акциях и новых поступлениях Интернет-магазина. См. основные правила.

клуб ЖЖ

Введите Ваш логин в ЖЖ, и цена товаров пересчитается согласно величине Вашей скидки


Примем заказ, ответим на все вопросы

Укажите регион, чтобы мы точнее рассчитали условия доставки

Например: 
Москва,
Санкт-Петербург,
Новосибирск,
Екатеринбург,
Нижний Новгород,
Краснодар,
Челябинск,
Кемерово,
Тюмень,
Красноярск,
Казань,
Пермь,
Ростов-на-Дону,
Самара,
Омск

Table of contents :
Содержание
Предисловие
Введение
Часть I. Основы администрирования
Глава 1. С чего начать
Глава 2. Загрузка и системные демоны
Глава 3. Управление доступом и привилегии суперпользователя
Глава 4. Управление процессами
Глава 5. Файловая система
Глава 6. Инсталляция и управление программным обеспечением
Глава 7. Сценарии и командная оболочка
Глава 8. Управление учетными записями пользователей
Глава 9. Облачные вычисления
Глава 10. Журналирование
Глава 11. Драйверы и ядро
Глава 12. Печать
Часть II. Работа в сетях
Глава 13. Сети TCP/IP
Глава 14. Сетевые аппаратные средства
Глава 15. IP-маршрутизация
Глава 16. DNS: система доменных имен
Глава 17. Система единого входа
Глава 18. Электронная почта
Глава 19. Веб-хостинг
Часть III. Хранение данных
Глава 20. Дисковая память
Глава 21. Сетевая файловая система NFS
Глава 22. Файловая система SMB
Часть IV. Эксплуатация
Глава 23. Управление конфигурацией
Глава 24. Виртуализация
Глава 25. Контейнеры
Глава 26. Непрерывная интеграция и доставка
Глава 27. Безопасность
Глава 28. Мониторинг
Глава 29. Анализ производительности
Глава 30. Центры обработки данных
Глава 31. Методология, политика и стратегии
Краткая история системного администрирования
Предметный указатель

UNIX И LINUX РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА 5-е издание

UNIX® AND LINUX® SYSTEM

ADMINISTRATION HANDBOOK

——-

FIFTH EDITION

——

Evi Nemeth Garth Snyder Trent R. Hein Веп Whaley DanMackin

with James Garnett, Fabrizio Branca, and Adrian Mouat

Boston Dubai

Columbus • lndianapolis

New York

San Francisco

Amsterdam

С а р е Town

Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City Sao Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo

London

UNIXИLINUX РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА

—- 5-еиздание

—-

ЭвиНемет, Гарт Снайдер, ТрентХейн, Бэн Уэйли, ДэнМакин при участии Джеймса Гарнетта, Фабрицио Бранка и Адриана Муата

Москва

Санкт-Петербург 2020

Б Б К 32.973 .26-0 1 8 . 2 . 75 Н 50 УД К 68 1 . 3 . 07 ООО «Ди ал е кти ка» Зав. редакцией С.Н. Тригуб Перевод с англ ийского и редакция докт. физ.-мат. наукД.А. Клюшина По общим вопросам обращайтесь в издательство «Диалектика» по адресу: [email protected] , http://www. dialektika.com

Немет, Эви, Снайдер, Гарт, ХеАн, Тре нт, УэАли, Бен , Макни, Дэ н

Н 50

.

Uпix и Linux: руководство системною администратора, 5-е изд.: Пер. с ан гл . СПб. : ООО «Диалектика» , 2020. — 1 1 68 с. : ил. П арал . тит. англ.

ISBN 978-5-907 1 44- 1 0- 1 (рус . )

ББК 32.973.26-018.2.75

Все названия про11Jаммных продуктов являются зарегистрированными торговыми марками со­ ответствующих фирм. Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами , будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разре­ шения и111ательства Addisoп-�sley PuЫishiпg Company, lnc. Copyright © 2020 Ьу Dialektika Computer PuЫishing Ltd.

Authorized Russian translation of the English edition of UNIX and Linux System Administration

Handbook, 5th Edition

(ISBN

978-0-13-427755-4) © 2018 Pearson Education lnc.

T his translation is puЫished and sold Ьу permission of Pearson Education lnc., which owns or contгols all rights to puЫish and sell the same. All rights reserved.

N o ра11 of this book may Ье reproduced or transmitted in any form or Ьу any means,

electronic or mechanical, including photocopying, recording, or Ьу any information storage or retrieval sys­ tem, without the prior written permission of the copyright owner and the PuЫisher.

Научно-популярное издание Эви Немет, Iарт Снайдер, ‘!Рент ХеАн, Бен Уэйли, Дэн Макни

Unix и Linux: руководство системного администратора 5-е издание Подписано в печать 24.03.2020. Формат 70х100/16 Гарнитура Times Усл. печ. л. 94, 17. Уч.-и111. л. 81,2 Тираж 500 экз. Заказ No 2141

Отпечатано в АО «Первая Образцовая типо11>афия» Филиал «Чеховский Печатный Двор»

142300, Московская область, r. Чехов, ул. Поли11>афистов, д. 1 Сайт: www.chpd.ru, E-mail: [email protected], тел. 8 (499) 270-73-59 ООО «Диалектика», 195027, Санкт-Петербург, Магнитогорская ул» д. 30, лит. А, пом. 848

ISBN 978-5-907144-IO-l (рус.) ISBN 978-0-13-427755-4 (англ.)

© ООО «Диалектика», 2020 © Pearson Education, 1 nc» 2018

Оглавление Предисловие

36

Введение

38

частьl.Основыадминистрирования Глава 1. С чего начать Глава 2. Загрузка и системные демоны Глава 3. Управление доступом и привилегии суперпользователя Глава 4. Управление процессами Глава 5. Файловая система Глава 6. Инсталляция и управление программным обеспечением Глава 7. Сценарии и командная оболочка Глава 8. Управление учетными записями пользователей Глава 9. Облачные вычисления Глава 10. Журналирование Глава 11. Драйверы и ядро Глава 12. Печать

часть 11. Работа в сетях Глава 13. Сети TCP/IP Глава 14. Сетевые аппаратные средства Глава 15. JР-маршрутизация Глава 16. DNS: система доменных имен Глава 17. Система единого входа Глава 18. Электронная почта Глава 19. Веб-хостинг

Часть 111. Хранение данных Глава 20. Дисковая память Глава 21. Сетевая файловая система N FS Глава 22. Файловая система SMB

частьlV.Эксплvатация Глава 23. Управление конфигурацией Глава 24. Виртуализация Глава 25. Контейнеры Глава 26. Непрерывная интеграция и доставка Глава 27. Безопасность Глава 28. Мониторинг Глава 29. Анализ производительности Глава 30. Центры обработки данных Глава 31. Методология, политика и стратегии Краткая история системного администрирования Предметный указатель

41 43 69 103 127 155 187 215 273 299 321 351 383 395 397 477 499 517 595 613 689 729 731 805 833 845 847 909 923 955 985 1043 1071 1093 1107 1139 1149

Содержание О соавторах Об авторах Памяти Эви

33

Предисловие

36 36 37 37

Организация книги Авторы Контактная информация

Введение

34 35

Благодарности От издательства

38 39 40

Часть I. Основы администрирования

41

Глава 1. С чего начать

43 44 44 44 44 44 45 45 45 45 46 46 46 46 46 47 48 49 50 51 52 53 54 54 55 55 56 56 56

1.1. Основные обязанности системного администратора Управление доступом Добавление оборудования Автоматизация задач Управление резервными копиями Установка и обновление программного обеспечения Мониторинг Исправление проблем Ведение локальной документации Бдительный мониторинг безопасности Настройка производительности Разработка правил Работа с поставщиками Тушение пожаров 1.2. Предварительный опыт 1.3. Дистрибутивы Linux 1.4. Примеры систем, используемых в этой книге Примеры дистрибутивов Linux Пример дистрибутива UNIX 1.5. Обозначения и типографские соглашения 1.6. Единицы измерения 1.7. Man-страницы и другая онлайн-документация Организация man-страниц Команда man: чтение страниц интерактивного руководства Хранение страниц интерактивного руководства 1.8. Другая официальная документация Руководства по конкретным системам Документация по конкретным пакетам

Содержание

7

Книги Документы RFC 1.9. Другие источники информации Сохранение актуальности Практические руководства и справочные сайты Конференции 1.10. Способы поиска и установки программного обеспечения Как определить, установлено ли программное обеспечение Добавление нового программного обеспечения Создание программного обеспечения из исходного кода Установка с помощью веб-сценария 1.11. Где разместить программное обеспечение 1.12. Специализация и смежные дисциплины Методология DevOps Инженеры по надежности сайтов Инженеры по безопасности Сетевые администраторы Администраторы баз данных Инженеры центра сетевых операций Технические специалисты центров обработки данных Архитекторы 1.13. Литература Системное администрирование и методология DevOps Важные инструменты

57 57 57 58 58 59 60 60 61 63 64 65 66 66 66 66 66 67 67 67 67 67 68 68

Глава 2. Загрузка и системные демоны

69 69 70 71 72 72 74 74 74 76 76 77 77 78 78 79 79 80 80 81 82 82

2.1. Обзор процесса загрузки 2.2. Системные прошивки BIOS или UEFI Устаревший интерфейс BIOS UEFI 2.3. Загрузчики 2.4. GRUB: универсальный загрузчик Конфигурация GRUB Командная строка GRUB Параметры ядра Linux 2.5. Процесс загрузки FreeBSD Вариант BIOS: boot0 Вариант UEFI Конфигурация загрузчика Команды загрузчика loader 2.6. Демоны управления системой Обязанности демона init Реализации демона init Традиционный стиль init Менеджер systemd против остального мира Аргументы против init

8

Содержание

2.7. Менеджер systemd в деталях Модули и модульные файлы Команда systemctl: управление менеджером systemd Состояние модуля Цели Зависимости между модулями Порядок выполнения Более сложный пример файла Локальные службы и настройки Предостережения об управлении службами и запуском Журнал systemd 2.8. Сценарии инициализации и запуска системы FreeBSD 2.9. Процедуры перезагрузки и выключения Выключение физических систем Выключение облачных систем 2.10. Что делать, если система не грузится? Однопользовательский режим Однопользовательский режим в системе FreeBSD Однопользовательский режим с загрузчиком GRUB Восстановление облачных систем

83 83 84 85 87 88 90 90 91 92 94 95 96 97 97 97 98 99 100 100

Глава 3. Управление доступом и привилегии суперпользователя

103 104 104 105 106 106 107 107 108 108 115 116 117 118 118 119 119 120 120 121 121 122 123 123 125 126

3.1. Стандартное управление доступом в UNIX Контроль доступа к файловой системе Владение процессом Учетная запись суперпользователя root Установка флагов setuid и setgid 3.2. Управление учетной записью root Вход в учетную запись root Команда su: замена идентификатора пользователя Программа sudo: ограниченный вариант команды su Отключение учетной записи root Системные учетные записи, отличные от root 3.3. Расширения стандартной модели контроля доступа Недостатки стандартной модели PAM: подключаемые модули аутентификации Kerberos: сетевая криптографическая аутентификация Списки управления доступом к файловой системе Возможности Linux Пространства имен Linux 3.4. Современный контроль доступа Отдельные экосистемы Обязательный контроль доступа Контроль доступа на основе ролей SELinux: улучшенная безопасность Linux AppArmor 3.5. Литература

Содержание

Глава 4. Управление процессами 4.1. Компоненты процесса Идентификатор процесса PID Идентификатор родительского процесса PPID Идентификатор пользователя UID и текущий идентификатор пользователя EUID Идентификатор группы (GID) и текущий идентификатор группы (EGID) Фактор уступчивости Управляющий терминал 4.2. Жизненный цикл процесса Сигналы Команда kill: отправка сигналов Состояния процессов и потоков 4.3. Команда ps: текущий контроль процессов 4.4. Интерактивный мониторинг процессов с помощью команды top 4.5. Команды nice и renice: изменение приоритета выполнения 4.6. Файловая система /proc 4.7. Команды strace и truss: отслеживание сигналов и системных вызовов 4.8. Процессы, вышедшие из-под контроля 4.9. Периодические процессы Демон cron: команды расписания Системные таймеры Общее использование запланированных задач

Глава 5. Файловая система 5.1. Имена путей 5.2. Монтирование и демонтирование файловой системы 5.3. Структура файлового дерева 5.4. Типы файлов Обычные файлы Каталоги Жесткая ссылка Файлы символьных и блочных устройств Локальные сокеты Именованные каналы Символические ссылки 5.5. Атрибуты файлов Биты режима Биты setuid и setgid Дополнительный бит Команда ls: просмотр атрибутов файла Команда chmod: изменение прав доступа Команды chown и chgrp: смена владельца и группы Команда umask: задание стандартных прав доступа Дополнительные флаги в системе Linux

9 127 127 128 128 129 129 130 130 130 131 133 134 135 137 139 140 141 143 145 145 150 153 155 157 157 160 162 164 164 164 165 166 166 166 167 167 168 169 169 170 172 173 173

10

Содержание

5.6. Списки управления доступом Предупреждение Типы ACL Реализация списков ACL Поддержка ACL в системе Linux Поддержка ACL в системе FreeBSD Обзор POSIX ACL Списки NFSv4 ACL

175 175 176 176 177 177 178 181

Глава 6. Инсталляция и управление программным обеспечением

187 188 188 189

6.1. Инсталляция операционных систем Загрузка по сети на персональном компьютере Настройка PXE Использование Kickstart — автоматизированного инсталлятора Red Hat и CentOS Автоматизированная инсталляция систем Debian и Ubuntu 6.2. Управление пакетами 6.3. Системы управления пакетами для Linux Команда rpm: управление пакетами RPM Команда dpkg: управление пакетами .deb 6.4. Использование высокоуровневых систем управления пакетами в системе Linux Хранилища пакетов APT: усовершенствованное средство управления пакетами Настройка конфигурации хранилища Пример файла /etc/apt/sources.list Создание локального зеркала хранилища Автоматизация работы системы APT Система yum: управление выпусками для RPM 6.5. Управление программным обеспечением в системе FreeBSD Базовая система Менеджер пакетов pkg в системе FreeBSD Коллекция портов 6.6. Локализация и настройка конфигурации программного обеспечения Организация локализации Структурные изменения Ограничение количества выпусков Тестирование 6.7. Литература

Глава 7. Сценарии и командная оболочка 7.1. Основы сценариев Создание микросценариев Хорошо изучите несколько инструментов Автоматизируйте все, что возможно Избегайте преждевременной оптимизации

190 193 196 198 198 199 200 201 203 204 205 206 206 207 208 209 209 210 211 212 212 213 213 214 215 216 216 217 217 218

Содержание

Выберите правильный язык сценариев Следуйте рекомендациям 7.2. Основы работы с оболочками Редактирование команд Каналы и перенаправление потоков Использование переменных и кавычек Переменные окружения Команды фильтрации 7.3. Написание сценариев для оболочки sh Выполнение От команд к сценариям Ввод и вывод данных Пробелы в именах файлов Функции и аргументы командной строки Поток управления Циклы Арифметика 7.4. Регулярные выражения Процесс сопоставления Литеральные символы Специальные символы Примеры использования регулярных выражений Захваты Жадность, леность и катастрофический поиск с возвратом 7.5. Программирование на языке Python Страсти по Python 3 Python 2 или Python 3? Краткое введение в язык Python Объекты, строки, числа, списки, словари, кортежи и файлы Пример проверки ввода Циклы 7.6. Программирование на языке Ruby Инсталляция Краткое введение в язык Ruby Блоки Символы и хеши опций Регулярные выражения в языке Ruby Язык Ruby как фильтр 7.7. Управление библиотекой и средой для Python и Ruby Поиск и установка пакетов Создание воспроизводимых сред Несколько сред 7.8. Контроль версий с помощью системы Git Простой пример Git Ловушки Git Коллективное кодирование с помощью системы Git

11 218 220 222 223 223 225 226 227 230 231 232 234 235 235 237 239 241 241 242 242 242 244 245 246 247 247 248 249 250 252 253 254 255 255 256 258 259 260 260 261 261 262 265 267 269 269

12

Содержание

7.9. Литература Оболочки и сценарии оболочки Регулярные выражения Python Ruby

271 271 271 272 272

Глава 8. Управление учетными записями пользователей

273 274 274 275 276 278 278 279 279 280 280 282 282 283 284 285 286 287

8.1. Основы управления учетными записями 8.2. Файл /etc/passwd Регистрационное имя Зашифрованные пароли Идентификатор пользователя Идентификатор группы по умолчанию Поле GECOS Домашний каталог Регистрационная оболочка 8.3. Файлы /etc/shadow 8.4. Файлы /etc/master.passwd и /etc/login.conf в системе FreeBSD Файл /etc/master.passwd Файл /etc/login.conf 8.5. Файл /etc/group 8.6. Подключение пользователей вручную: основные действия Редактирование файлов passwd и group Задание пароля Создание домашнего каталога пользователя и инсталляция конфигурационных файлов Установка прав доступа и владения Конфигурирование ролей и административных привилегий Заключительные действия 8.7. Добавление пользователей с помощью сценариев: useradd, adduser и newusers Команда useradd в системе Linux Команда adduser в системах Debian и Ubuntu Команда adduser в системе FreeBSD Команда newusers в системе Linux: добавление пользователей пакетом 8.8. Безопасное удаление учетных записей пользователей и файлов 8.9. Блокирование регистрационных имен пользователей 8.10. Уменьшение риска с помощью модулей PAM 8.11. Централизация управления учетными записями Протокол LDAP и служба Active Directory Системы “единого входа” Системы управления учетными данными

Глава 9. Облачные вычисления 9.1. Облако в контексте 9.2. Выбор облачной платформы Публичные, частные и гибридные облака

287 289 289 290 290 291 292 292 293 294 295 296 296 296 297 297 299 300 301 302

Содержание

13

Amazon Web Services Google Cloud Platform DigitalOcean 9.3. Основы работы с облачными службами Доступ к облаку Регионы и зоны доступности Виртуальные частные серверы Сети Хранилище Идентификация и авторизация Автоматизация 9.4. Облака: быстрый запуск VPS на платформе Веб-службы Amazon Интерфейс aws: управление подсистемами AWS Google Cloud Platform DigitalOcean 9.5. Контроль затрат 9.6. Литература

303 303 304 304 306 306 308 308 309 310 310 311 311 312 315 317 318 320

Глава 10. Журналирование

321 323 325 325 326 327 328 328 329 330 331 331 332 340 343 344 345 345 346 347 347 348 348 349

10.1. Местоположение файлов регистрации Специальные журнальные файлы Как просмотреть записи в журнале systemd 10.2. Журнал systemd Настройка журнала systemd Добавление дополнительных параметров фильтрации для журнала Совместное использование с системой Syslog 10.3. Система Syslog Чтение сообщений системы Syslog Архитектура системы Rsyslog Версии Rsyslog Конфигурация Rsyslog Примеры конфигурационных файлов Отладка системы Syslog 10.4. Журнальная регистрация на уровне ядра и на этапе начальной загрузки 10.5. Управление журнальными файлами и их ротация Утилита logrotate: кросс-платформенное управление журналами Утилита newsyslog: управление журналами в системе FreeBSD 10.6. Управление журналами в крупном масштабе Стек ELK Graylog Журналирование как услуга 10.7. Принципы обработки журнальных файлов

Глава 11. Драйверы и ядро 11.1. Ядра и системное администрирование 11.2. Нумерация версий ядра

351 352 353

14

Содержание

Версии ядер для системы Linux Версии ядер FreeBSD 11.3. Устройства и их драйверы Файлы и номера устройств Проблемы управления файлами устройств Создание файлов устройств Управление современными файловыми системами Управление устройствами в Linux Создание правил и постоянных имен Управление устройствами в системе FreeBSD 11.4. Конфигурирование ядра Linux Конфигурирование параметров ядра linux Сборка ядра Добавление драйвера устройства в Linux 11.5. Конфигурация ядра системы FreeBSD Настройка параметров ядра FreeBSD Сборка ядра FreeBSD 11.6. Загружаемые модули ядра Загружаемые модули ядра в Linux Загружаемые модули ядра в системе FreeBSD 11.7. Загрузка Загрузочные сообщения системы Linux Загрузочные сообщения системы FreeBSD 11.8. Загрузка альтернативных ядер в облаке 11.9. Ошибки ядра Ошибки ядра Linux Паника ядра в системе FreeBSD 11.10. Литература

353 353 354 354 356 356 356 357 359 362 364 364 366 368 368 368 369 370 371 372 373 373 377 378 379 380 382 382

Глава 12. Печать

383 384 384 385 385 386 386 387 388 388 389 389 390 390 391 392 392 392

12.1. Система печати CUPS Интерфейсы для системы печати Очередь на печать Множество принтеров Экземпляры принтеров Сетевая печать Фильтры 12.2. Управление сервером CUPS Настройка сетевого сервера печати Автоматическое конфигурирование принтера Конфигурирование сетевых принтеров Примеры конфигурирования принтеров Отключение принтера Другие связанные с конфигурированием задачи 12.3. Советы по выявлению проблем Повторный запуск демона печати Регистрационные журналы

Содержание

15

Проблемы с прямой печатью Проблемы с печатью в сети 12.4. Литература

393 393 394

Часть II. Работа в сетях

395

Глава 13. Сети TCP/IP

397 397 398 399 400 401 403 404 405 405 406 407 407 408 409 409 410

13.1. Система TCP/IP и Интернет Кто управляет Интернетом Сетевые стандарты и документация 13.2. Основы работы в сети Версии IPv4 и IPv6 Пакеты и их инкапсуляция Стандарты формирования фреймов Ethernet 13.3. Адресация пакетов Аппаратная адресация (MAC) IP-адресация “Адресация” имен машин Порты Типы адресов 13.4. IP-адреса Классы адресов в протоколе IPv4 Подсети IPv4 Трюки и инструменты для арифметических вычислений, связанных с подсетями CIDR: протокол бесклассовой междоменной маршрутизации Выделение адресов Частные адреса и система NAT Адресация в стандарте IPv6 13.5. Маршрутизация Таблицы маршрутизации Директивы переадресации протокола ICMP 13.6. ARP: протокол преобразования адресов в IPv4 и IPv6 13.7. DHCP: протокол динамического конфигурирования хостов Программное обеспечение DHCP Схема работы DHCP Программное обеспечение DHCP, созданное организацией ISC 13.8. Вопросы безопасности Перенаправление IP-пакетов Директивы переадресации протокола ICMP Маршрутизация по адресу отправителя Широковещательные пакеты эхо-запросов и другие виды направленных широковещательных сообщений Подмена IP-адресов Встроенные брандмауэры Виртуальные частные сети 13.9. Основы конфигурирования сети Присвоение сетевых имен и IP-адресов

411 412 413 413 415 419 419 421 422 423 423 424 425 426 426 426 427 427 427 428 429 430 430

16

Содержание

Настройка сетевых интерфейсов и протокола IP Настройка маршрутизации Конфигурирование DNS Сетевое конфигурирование в различных системах 13.10. Сетевое конфигурирование в системе Linux Программа NetworkManager Команда ip: ручное конфигурирование сети Сетевое конфигурирование в системе Ubuntu Сетевое конфигурирование в системе Red Hat и CentOS Настройка сетевого оборудования в системе Linux Опции протокола Linux TCP/IP Переменные ядра, связанные с безопасностью 13.11. Сеть FreeBSD Команда ifconfig: настройка сетевых интерфейсов Конфигурация сетевого оборудования в системе FreeBSD Конфигурирование сети во время загрузки системы FreeBSD Конфигурирование протокола TCP/IP в системе FreeBSD 13.12. Сетевые проблемы Команда ping: проверьте, работает ли хост Команда traceroute: трассировка IP-пакетов Пакетные анализаторы трафика Утилита tcpdump: пакетный анализатор трафика из командной строки 13.13. Мониторинг сети Программа SmokePing: постепенный сбор статистики об эхо-запросах Программа iPerf: отслеживание производительности сети Программа Cacti: сбор и отображение данных 13.14. Брандмауэры и система NAT Утилита iptables в системе Linux: правила, цепочки и таблицы IPFilter для UNIX-систем 13.15. Облачные сети Виртуальное частное облако AWS (VPC) Сеть на платформе Google Cloud Platform Сеть DigitalOcean 13.16. Литература История Классика Протоколы

432 433 435 435 436 436 437 438 438 440 441 443 444 444 445 445 445 446 447 449 452 453 455 455 456 457 458 458 463 465 465 472 473 474 474 474 475

Глава 14. Сетевые аппаратные средства

477 478 479 479 480 482 483 487 487 488

14.1. Технология Ethernet: сетевая панацея Как работает Ethernet Топология Ethernet Неэкранированная витая пара Оптическое волокно Соединение и расширение сетей Ethernet 14.2. Беспроводные сети: локальная сеть для кочевников Стандарты беспроводных сетей Доступ клиентов к беспроводной сети

Содержание

17

Беспроводные коммутаторы и точки беспроводного доступа Безопасность беспроводных сетей 14.3. SDN: программно-коммутируемые сети 14.4. Тестирование и отладка сетей 14.5. Прокладка кабелей Неэкранированная витая пара Офисные точки подключения Стандарты кабельных систем 14.6. Проектирование сетей Структура сети и архитектура здания Расширение сетей Перегрузка Обслуживание и документирование 14.7. Управление сетью 14.8. Рекомендуемые поставщики Кабели и разъемные соединения Тестовые приборы Маршрутизаторы/коммутаторы 14.9. Литература

488 490 491 491 492 492 492 493 494 494 494 495 495 495 496 496 497 497 497

Глава 15. IP-маршрутизация

499 500 503 503 504 505 505 506 506 507 508 508 508 509 510 511 511 512 512 515

15.1. Подробнее о маршрутизации пакетов 15.2. Демоны и протоколы маршрутизации Дистанционно-векторные протоколы Топологические протоколы Метрика стоимости Внутренние и внешние протоколы 15.3. Основные протоколы маршрутизации Протоколы RIP и RIPng Протокол OSPF Протокол EIGRP BGP: протокол граничного шлюза 15.4. Многоадресатная координация протокола маршрутизации 15.5. Выбор критериев стратегии маршрутизации 15.6. Демоны маршрутизации Демон routed: устаревшая реализация в протоколе RIP Пакет Quagga: основной демон маршрутизации Маршрутизатор XORP 15.7. Маршрутизаторы Cisco 15.8. Литература

Глава 16. DNS: система доменных имен 16.1. Архитектура DNS Запросы и ответы Поставщики услуг DNS 16.2. DNS для поиска resolv.conf: конфигурация клиентского модуля распознавания nsswitch.conf: кого я запрашиваю по имени?

517 518 518 519 519 519 520

18 16.3. Пространство имен DNS Регистрация доменного имени Создание собственных поддоменов 16.4. Как работает система DNS Серверы имен Авторитетные и кеширующие серверы Рекурсивные и нерекурсивные серверы Записи о ресурсах Делегирование Кеширование и эффективность Неоднозначные ответы и балансировка загрузки DNS Отладка с помощью инструментов запросов 16.5. База данных DNS Команды синтаксического анализатора в файлах зон Записи о ресурсах Запись SOA Записи NS Записи A Записи AААА Записи PTR Записи MX Записи CNAME Записи SRV Записи TXT Записи SPF, DKIM и DMARC Записи о ресурсах DNSSEC 16.6. Программное обеспечение BIND Компоненты системы BIND Файлы конфигурации Инструкция include Инструкция options Инструкция acl Инструкция key (TSIG) Инструкция server Инструкция masters Инструкция logging Инструкция statistics-channels Инструкция zone Инструкция controls для команды rndc 16.7. Расщепление DNS и инструкция view 16.8. Примеры конфигурации системы BIND Зона локального хоста Небольшая компания, предоставляющая консалтинговые услуги в области безопасности 16.9. Обновление файла зоны Передача зоны Динамические обновления в системе BIND

Содержание

521 522 522 522 522 523 524 524 525 526 527 527 530 530 531 534 536 537 537 538 539 540 541 542 542 542 543 543 543 545 545 551 552 552 553 553 553 554 557 558 560 560 561 564 565 565

Содержание

16.10. Вопросы безопасности DNS Еще раз о списках управления доступом на сервере BIND Открытые распознаватели Работа в виртуальном окружении chroot Безопасные межсерверные взаимодействия посредством технологий TSIG и TKEY Настройка технологии TSIG для сервера BIND Технология DNSSEC Правила протокола DNSSEC Записи о ресурсах DNSSEC Настройка протокола DNSSEC Генерирование пар ключей Подписание зоны Цепочка доверия в протоколе DNSSEC Смена ключей DNSSEC Инструменты DNSSEC Отладка протокола DNSSEC 16.11. Отладка сервера BIND Журнальная регистрация на сервере BIND Некорректное делегирование 16.12. Литература Книги и другая документация Ресурсы в Интернете Документы RFC

Глава 17. Система единого входа 17.1. Основные элементы системы единого входа 17.2. LDAP: “облегченные” службы каталогов Особенности LDAP Структура данных LDAP OpenLDAP: традиционный LDAP-сервер с открытым исходным кодом 389 Directory Server: альтернативный LDAP‑сервер с открытым исходным кодом Создание LDAP-запросов Преобразования файлов паролей и групп LDAP 17.3. Использование служб каталогов для входа в систему Система Kerberos Демон sssd: служба системной безопасности nsswitch.conf: переключатель службы имен Модули PAM: украшение или чудо аутентификации? 17.4. Альтернативные подходы NIS: сетевая информационная служба Утилита rsync: более безопасная рассылка файлов 17.5. Литература

Глава 18. Электронная почта 18.1. Архитектура почтовой системы Пользовательские агенты

19 568 568 569 570 570 571 573 574 574 575 576 578 580 580 581 583 584 584 591 592 593 593 593 595 596 597 597 598 599 600 601 602 603 603 606 607 607 610 611 611 611 613 613 614

20 Агенты передачи Транспортные агенты Локальные агенты доставки Хранилища сообщений Агенты доступа 18.2. Структура почтового сообщения 18.3. Протокол SMTP Вы прислали мне привет (EHLO) Коды ошибок протокола SMTP Аутентификация SMTP 18.4. Спам и вредоносные программы Подделки Технология SPF и спецификации Sender ID Системы DKIM 18.5. Конфиденциальность и шифрование сообщений 18.6. Почтовые псевдонимы Загрузка псевдонимов из файла Направление почты в файл Направление почты в программу Хешированная база данных псевдонимов 18.7. Конфигурация электронной почты 18.8. Почтовый агент sendmail Файл переключения Запуск программы sendmail Почтовые очереди Препроцессор m4 Фрагменты конфигурации программы sendmail Конфигурационный файл, построенный на основе эталонного файла с расширением .mc Примитивы конфигурации программы sendmail Таблицы и базы данных Обобщенные макросы и функциональные возможности Конфигурация клиентов Параметры конфигурации препроцессора m4 Средства программы sendmail для борьбы со спамом Ретрансляция Безопасность и программа sendmail Владельцы файлов Права доступа Безопасная пересылка почты в файлы и программы Опции безопасности Выполнение программы sendmail в виртуальном каталоге (для настоящих параноиков) Отражение атак типа “отказ от обслуживания” TLS: безопасносный протокол транспортного уровня Тестирование и отладка программы sendmail Журнальная регистрация

Содержание

615 615 616 616 616 617 619 620 621 621 622 623 623 624 624 625 627 628 628 628 629 630 631 631 633 634 635 636 637 637 638 643 644 646 646 649 650 651 651 652 653 654 654 655 656

Содержание

21

18.9. Почтовый агент Exim Инсталляция почтового сервера Exim Загрузка почтового сервера Exim Утилиты почтового сервера Exim Язык конфигурации программы Exim Файл конфигурации программы Exim Глобальные параметры Сканирование содержимого на этапе применения списков управления доступом Аутентификаторы Маршрутизаторы Транспортные механизмы Конфигурация retry Конфигурация перезаписи Функция локального сканирования Регистрация Отладка 18.10. Почтовый агент Postfix Архитектура системы Postfix Безопасность Команды и документация системы Postfix Конфигурация системы Postfix Виртуальные домены Управление доступом Отладка 18.11. Литература Литература по программе sendmail Литература о системе Exim Литература о системе Postfix Документы RFC

657 658 659 660 661 661 662

Глава 19. Веб-хостинг

689 689 690 691 694 695 696 696 697 698 699 701 704 705 707 708 709

19.1. HTTP: протокол передачи гипертекста Унифицированные указатели ресурсов (URL) Структура транзакции протокола HTTP Утилита сurl: инструмент командной строки для работы с HTTP Повторное использование TCP-соединений HTTP на основе протокола TLS Виртуальные хосты 19.2. Основы программного обеспечения для веба Веб-серверы и прокси-сервер протокола HTTP Балансировщики нагрузки Кеши Сети доставки контента Языки веба Интерфейсы прикладного программирования (API) 19.3. Облачный веб-хостинг Сборка или покупка

667 667 668 672 672 673 673 673 674 675 675 677 677 678 682 683 686 687 688 688 688 688

22

Содержание

Платформа как услуга Статический хостинг содержимого Бессерверные веб-приложения 19.4. Веб-сервер Apache httpd Использование веб-сервера httpd Конфигурация логистики веб-сервера httpd Настройка виртуального хоста Базовая аутентификация протокола HTTP Ведение журнала 19.5. Веб-сервер NGINX Установка и запуск NGINX Настройка веб-сервера NGINX Настройка TLS для NGINX Балансировка нагрузки с помощью NGINX 19.6. Программное обеспечение HAProxy Проверки работоспособности Статистика сервера Липкие сессии Прекращение использования TLS 19.7. Литература

709 710 710 711 712 712 714 715 717 718 719 719 722 723 724 725 726 726 727 728

Часть III. Хранение данных

729

Глава 20. Дисковая память

731 732 733 734 735 736 739 742 743 744 744 744 745 746 747 747 748 749 749 750 752 752 753 755

20.1. Добавление диска Рецепт для Linux Рецепт для FreeBSD 20.2. Аппаратное обеспечение для хранения данных Жесткие диски Твердотельные диски Гибридные диски Расширенный формат и блоки по 4 KиБ 20.3. Интерфейсы устройств для хранения данных Интерфейс SATA Интерфейс PCI Express Интерфейс SAS Интерфейс USB 20.4. Подключение и низкоуровневое управление накопителями Проверка инсталляции на уровне аппаратного обеспечения Файлы дисковых устройств Непостоянные имена устройств Форматирование дисков и управление сбойными секторами Безопасное стирание дисков ATA Команды hdparm и camcontrol: параметры диска и интерфейса (Linux) Мониторинг жесткого диска с помощью стандарта SMART 20.5. Программное обеспечение накопителей Отображение устройств в системе Linux

Содержание

20.6. Разбиение диска Традиционное разбиение Разбиение диска по схеме MBR Схема GPT: таблица разделов GUID Разбиение дисков в системе Linux Разбиение дисков в системе FreeBSD 20.7. Управление логическими томами Управление логическими томами в системе Linux Управление логическими томами в FreeBSD 20.8. RAID: избыточные массивы недорогих дисков Программная и аппаратная реализации системы RAID Уровни системы RAID Восстановление диска после сбоя Недостатки конфигурации RAID 5 Команда mdadm: программное обеспечение RAID в системе Linux 20.9. Файловые системы 20.10. Традиционные файловые системы: UFS, ext4 и XFS Терминология файловых систем Полиморфизм файловых систем Форматирование файловых систем Команда fsck: проверка и исправление файловых систем Монтирование файловой системы Настройка автоматического монтирования Монтирование USB-накопителя Включение подкачки 20.11. Файловые системы следующего поколения: ZFS и Btrfs Копирование при записи Обнаружение ошибок Производительность 20.12. Файловая система ZFS: все проблемы решены ZFS в системе Linux Архитектура ZFS Пример: добавление диска Файловые системы и свойства Наследование свойств Один пользователь — одна файловая система Мгновенные копии и клоны Неразмеченные логические тома Управление пулом памяти 20.13. Файловая системы Btrfs: облегченная версия ZFS для Linux Btrfs или ZFS Настройка и преобразование хранилища Тома и подтома Снимки тома Поверхностные копии 20.14. Стратегия резервного копирования данных 20.15. Литература

23 756 758 759 759 760 760 761 761 766 767 767 767 770 771 772 776 777 778 779 779 779 781 781 784 784 785 785 786 786 787 788 788 789 789 791 792 792 794 794 796 797 797 800 800 801 802 803

24

Содержание

Глава 21. Сетевая файловая система NFS 21.1. Введение в протокол NFS Конкуренция Проблемы, связанные с состоянием Проблемы производительности Безопасность 21.2. Основные идеи, лежащие в основе протокола NFS Версии и история протокола Удаленный вызов процедур Транспортные протоколы Состояние Экспорт файловой системы Блокировка файлов Вопросы безопасности Идентифицирующее отображение в версии 4 Учетные записи root и nobody Производительность версии 4 21.3. Серверная часть протокола NFS Файл exports в системе Linux Файл exports в системе FreeBSD Демон nfsd: обслуживание файлов 21.4. Клиентская часть протокола NFS Монтирование файловых систем NFS на этапе начальной загрузки Ограничения экспорта привилегированными портами 21.5. Идентифицирующее отображение в протоколе NFS 4 21.6. Команда nfsstat: отображение статистики NFS 21.7. Специализированные файловые серверы NFS 21.8. Автоматическое монтирование Таблицы косвенных назначений Таблицы прямых назначений Главные таблицы Исполняемые таблицы Видимость программы automount Реплицированные файловые системы и программа automount Автоматическое монтирование (V3; все, кроме Linux) Специфика системы Linux 21.9. Литература

Глава 22. Файловая система SMB 22.1. Samba: сервер SMB для UNIX 22.2. Инсталляция и конфигурации пакета Samba Совместное использование файлов с локальной аутентификацией Совместное использование файлов с помощью учетных записей, прошедших аутентификацию Active Directory Настройка общих ресурсов 22.3. Монтирование общих SMB-ресурсов 22.4. Просмотр файлов на общих SMB-ресурсах

805 805 806 806 807 807 808 808 809 810 810 810 811 812 813 814 815 815 816 819 820 822 824 824 825 825 826 827 828 829 829 830 830 831 831 832 832 833 834 835 836 836 837 839 840

Содержание

25

22.5. Обеспечение безопасности Samba-сервера 22.6. Отладка Samba-сервера Запрос состояния Samba-сервера с помощью команды smbstatus Настройка журнала Samba-сервера Управление наборами символов 22.7. Литература

840 841 841 842 843 843

Часть IV. Эксплуатация

845

Глава 23. Управление конфигурацией

847 848 848 849 849 851 851 852 852 853 853 854 855 856 856 856 858 859 861 862 863 863 865 866 868 870 870 871 872 874 874 875 875 876 878 879 880 882 884

23.1. Краткое введение в управление конфигурацией 23.2. Опасности управления конфигурацией 23.3. Элементы управления конфигурацией Операции и параметры Переменные Факты Обработчики изменений Привязки Пакеты и репозитории пакетов Среды Учет и регистрация клиентов 23.4. Сравнение популярных систем СМ Терминология Бизнес-модели Архитектурные параметры Параметры языка Варианты управления зависимостями Общие комментарии по поводу систему Chef Общие комментарии по поводу системы Puppet Общие комментарии по поводу систем Ansible и Salt Ода YAML 23.5. Введение в систему Ansible Пример использования системы Ansible Настройка клиента Группы клиентов Присваивание переменных Динамические и вычисляемые группы клиентов Списки задач Параметры состояния Итерация Взаимодействие с Jinja Визуализация шаблона Привязки: сценарии и файлы сценариев Роли Рекомендации по структурированию базы конфигурации Параметры доступа в системе Ansible 23.6. Введение в систему Salt Настройка миньонов

26

Содержание

Привязка значения переменной к миньону Сопоставление миньонов Состояния системы Salt Система Salt и препроцессор Jinja Идентификаторы состояний и зависимости Функции состояния и выполнения Параметры и имена Привязка состояний к миньонам Состояния высокого уровня Формулы Salt Среды Документация 23.7. Сравнение систем Ansible и Salt Гибкость развертывания и масштабируемость Встроенные модули и расширяемость Безопасность Разное 23.8. Рекомендации 23.9. Литература

886 887 888 889 891 892 893 896 896 897 898 902 903 903 903 904 904 905 908

Глава 24. Виртуализация

909 910 910 913 913 913 915 915 916 917

24.1. Виртуальный жаргон Гипервизоры Динамическая миграция Образы виртуальных машин Контейнеризация 24.2. Виртуализация с помощью системы Linux Платформа Xen Инсталляция гостевой операционной системы на платформе Xen Платформа KVM Инсталляция гостевой операционной системы на платформе KVM и ее использование 24.3. Система FreeBSD bhyve 24.4. Компания VMWare 24.5. Гипервизор VirtualBox 24.6. Программа Packer 24.7. Программа Vagrant 24.8. Литература

Глава 25. Контейнеры 25.1. Основные концепции Поддержка ядра Образы Сеть 25.2. Докер: механизм с открытым исходным кодом Базовая архитектура Инсталляция Настройка клиента

918 919 919 919 920 922 922 923 924 924 925 926 926 927 928 929

Содержание

27

Методики работы с контейнерами Тома Контейнеры данных Сети Docker Драйверы хранилищ Изменение параметров настройки демона dockerd Сборка образа Реестры 25.3. Контейнеры на практике Ведение журнала Советы по безопасности Отладка и устранение неполадок 25.4. Создание и управление контейнерными кластерами Краткий обзор программного обеспечения для управления контейнерами Kubernetes Mesos и Marathon Менеджер Docker Swarm Контейнерная служба AWS EC2 25.5. Литература

929 933 934 934 937 938 939 942 944 945 946 948 949

Глава 26. Непрерывная интеграция и доставка

955 957 957 961 961 962 963 965 966 967 967 969 969 970 971 972 973 975 977 980

26.1. Основные концепции Принципы и практика Флаги функций 26.2. Конвейеры Процесс сборки Тестирование Развертывание Методы развертывания с нулевым временем простоя 26.3. Jenkins: сервер автоматизации с открытым исходным кодом Основные концепции сервера Jenkins Распределенные сборки Конвейер как код 26.4. Подход CI/CD на практике Тривиальное веб-приложение UlsahGo Модульное тестирование UlsahGo Знакомство с конвейером Jenkins Pipeline Создание образа DigitalOcean Обеспечение единой системы тестирования Тестирование дроплета Развертывание приложения UlsahGo на паре дроплетов и  балансировщике нагрузки Выводы, сделанные из демонстрационного конвейера 26.5. Контейнеры и упрощение среды CI/CD Контейнеры как среда сборки Контейнерные образы как артефакты сборки 26.6. Литература

951 951 952 953 953 954

980 981 982 983 983 984

28

Содержание

Глава 27. Безопасность 27.1. Элементы безопасности 27.2. Слабые места в системе защиты Социальная инженерия Уязвимости в программах Распределенные атаки типа “отказ в обслуживании” (DDoS) Инсайдерская информация Ошибки конфигурации сети, системы или приложения 27.3. Основные вопросы безопасности Обновления программного обеспечения Ненужные службы Удаленная регистрация событий Резервные копии Вирусы и черви Руткиты Фильтрация пакетов Пароли и многофакторная аутентификация Бдительность Тестирование приложений на проникновение 27.4. Пароли и учетные записи пользователей Изменение пароля Хранилища и депоненты паролей Устаревание паролей Групповые и совместно используемые учетные записи Пользовательские оболочки Привилегированные учетные записи 27.5. Инструментальные средства защиты Команда nmap: сканирование сетевых портов Nessus: сетевой сканер нового поколения Metasploit: программа для выявления попыток проникновения Lynis: встроенный аудит безопасности John the Ripper: средство для выявления слабых паролей Bro: программная система для распознавания вторжения в сеть Snort: популярная программная система для распознавания проникновения в сеть OSSEC: система для распознавания вторжения в сеть на уровне хоста Fail2Ban: система отражения атаки методом перебора 27.6. Основы криптографии Криптография с симметричными ключами Криптография с открытым ключом Инфраструктура с открытым ключом Протокол защиты транспортного уровня TLS Криптографические хеш-функции Генерация случайных чисел Выбор криптографического программного обеспечения Команда openssl Отладка TLS-сеанса с сервером

985 986 987 987 988 989 989 990 990 991 992 992 993 993 994 994 995 995 995 996 997 997 998 999 999 999 1000 1000 1002 1002 1003 1003 1004 1005 1005 1008 1008 1009 1009 1010 1012 1012 1014 1015 1016 1017

Содержание

29

PGP: довольно хорошая конфиденциальность Kerberos: унифицированный подход к сетевой безопасности 27.7. Система SSH Основы OpenSSH Клиент ssh Аутентификация с помощью открытого ключа Демон ssh-agent Псевдонимы хостов в файле ~/.ssh/config Мультиплексирование соединения Проброс портов Демон sshd: сервер OpenSSH Проверка ключа хоста с помощью записи SSHFP Передача файлов Альтернативы для безопасного входа в систему 27.8. Брандмауэры Брандмауэры, фильтрующие пакеты Принципы фильтрации служб Брандмауэры, осуществляющие инспекцию пакетов  с отслеживанием состояния соединений Насколько безопасны брандмауэры 27.9. Виртуальные частные сети (VPN) Туннели IPsec Так ли уж нужны виртуальные частные сети 27.10. Сертификаты и стандарты Сертификаты Стандарты безопасности 27.11. Источники информации по вопросам обеспечения безопасности Сервер SecurityFocus.com и списки рассылки BugTraq и OSS Блог Брюса Шнайера Отчет компании Verizon Data Breach Investigations Институт SANS Информационные ресурсы отдельных дистрибутивов Другие списки рассылки и веб-сайты 27.12. Что нужно делать в случае атаки на сервер 27.13. Литература

1017 1018 1019 1019 1021 1022 1024 1025 1026 1026 1027 1029 1030 1030 1031 1031 1031

Глава 28. Мониторинг

1043 1044 1044 1045 1045 1046 1047 1047 1048 1049 1050 1052

28.1. Обзор мониторинга Инструментарий Типы данных Ввод и обработка Уведомления Контрольные панели и пользовательские интерфейсы 28.2. Культура мониторинга 28.3. Платформы мониторинга Платформы реального времени с открытым исходным кодом Платформы временных рядов с открытым исходным кодом Платформы визуализации данных с открытым исходным кодом

1032 1032 1033 1033 1034 1034 1034 1035 1038 1038 1038 1038 1038 1039 1039 1040 1041

30

Содержание

Коммерческие платформы мониторинга Размещенные платформы мониторинга 28.4. Сбор данных StatsD: протокол передачи общих данных Сбор данных из вывода команды 28.5. Мониторинг сетей 28.6. Мониторинг систем Команды для мониторинга систем Сборщик обобщенных системных данных collectd Утилиты sysdig и dtrace: трассировки выполнения 28.7. Мониторинг приложений Мониторинг системного журнала Supervisor + Munin: простой вариант для некоторых предметных областей Коммерческие средства мониторинга приложений 28.8. Мониторинг безопасности Проверка целостности системы Контроль обнаружения вторжений 28.9. SNMP: простой протокол сетевого управления Организация протокола SNMP Операции протокола SNMP Net-SNMP: средства для серверов 28.10. Советы и рекомендации по мониторингу 28.11. Литература

1052 1053 1054 1054 1056 1057 1058 1059 1059 1060 1061 1061

Глава 29. Анализ производительности

1071 1072 1073 1075 1076 1077 1078 1078 1080 1080 1082 1084 1085 1086

29.1. Принципы настройки производительности 29.2. Способы повышения производительности 29.3. Факторы, влияющие на производительность 29.4. Захваченные циклы центрального процессора 29.5. Как анализировать проблемы производительности 29.6. Проверка производительности системы Инвентаризуйте свое оборудование Сбор данных о производительности Анализ использования центрального процессора Управление памятью в системе Анализ использования памяти Анализ операций обмена с диском Утилита fio: анализ производительности дисковой подсистемы Команда sar: сбор статистических данных и генерирование отчетов по ним Выбор планировщика ввода-вывода в системах Linux Программа perf: универсальный профилировщик системы Linux 29.7. Помогите! Мой сервер тормозит! 29.8. Литература

1062 1062 1063 1063 1065 1065 1066 1067 1067 1069 1070

1087 1088 1089 1090 1092

Содержание

Глава 30. Центры обработки данных 30.1. Стойки 30.2. Электропитание Требования к электроснабжению стоек Измерение Стоимость Удаленное управление 30.3. Охлаждение и окружающая среда Оценка нагрузки на систему охлаждения Теплые и холодные отсеки Влажность Мониторинг окружающей среды 30.4. Уровни надежности центров обработки данных 30.5. Безопасность центров обработки данных Местонахождение Периметр Доступ к объекту Доступ к стойке 30.6. Инструменты 30.7. Литература

Глава 31. Методология, политика и стратегии 31.1. Великая единая теория: DevOps DevOps — это CLAMS Системное администрирование в мире DevOps 31.2. Системы управления билетами и задачами Общие функции билетных систем Владелец билета Восприятие пользователями билетных систем Типовые билетные системы Диспетчеризация билетов 31.3. Поддержка локальной документации Инфраструктура как код Стандарты документации 31.4. Разделение окружающей среды 31.5. Восстановление после аварий Оценка рисков Планирование мероприятий по восстановлению Подбор персонала на случай аварии Проблемы с безопасностью 31.6. Инструкции и процедуры Различие между инструкциями и процедурами Лучшие практики применения инструкций Процедуры 31.7. Соглашения о качестве оказываемых услуг Спектр услуг и их описание

31 1093 1094 1094 1096 1098 1098 1098 1098 1099 1101 1102 1102 1103 1103 1104 1104 1104 1105 1105 1106 1107 1108 1109 1112 1113 1113 1114 1115 1116 1116 1117 1118 1118 1119 1120 1120 1121 1123 1123 1124 1125 1126 1126 1127 1127

32

Содержание

Стратегии управления очередями Показатели соответствия 31.8. Соответствие законам и стандартам 31.9. Правовые вопросы Конфиденциальность Реализация политики безопасности Контроль — это ответственность Лицензии на программное обеспечение 31.10. Организации, конференции и другие ресурсы 31.11. Литература

1128 1129 1129 1133 1133 1134 1135 1135 1136 1137

Краткая история системного администрирования

1139 1139

Рассвет компьютеризации: системные операторы (1952–1960) От узкой специализации к работе в режиме разделения времени (1961–1969) Рождение UNIX (1969–1973) UNIX становится знаменитой (1974–1990) Эра системных администраторов Документация по системному администрированию и обучение UNIX при смерти. Рождение Linux (1991–1995) Мир Windows (1996–1999) Расцвет UNIX и Linux (2000–2009) Системы UNIX и Linux в гипермасштабируемом облаке (2010– настоящее время) Завтрашний день UNIX и Linux Литература

Предметный указатель

1140 1140 1142 1143 1145 1145 1146 1147 1147 1148 1148 1149

О соавторах Джеймс Гарнетт имеет степень доктора компьютерных наук в  Уни­ верситете Колорадо и является старшим инженером-программистом в компании Secure64 Software, Inc., где он разрабатывает технологии перехода с системы DDoS на ядра Linux. Если он не погружен в код ядра, значит, он находится где-то в глубине Каскадных гор в штате Вашингтон. Фабрицио Бранка (@fbrnc) является ведущим разработчиком систем в компании AOE. Он, его жена и их двое детей только что вернулись в Германию после четырех лет жизни в Сан-Франциско. Фабрицио внес свой вклад в несколько проектов с открытым исходным кодом. Он фокусируется на архитектуре, инфраструктуре и высокопроизводи­ тельных приложениях. Кроме того, он разрабатывает процессы непре­ рывной разработки, тестирования и развертывания крупных проектов. Адриан Муат (@adrianmouat) работает с контейнерами с самых пер­ вых дней появления технологии Docker. Он опубликовал книгу Using Docker (amzn.to/2sVAIZt) в издательстве О’Рейли. В настоящее время он является главным научным сотрудником общеевропейской компании Container Solutions, специализирующейся на консалтинге и разработке продуктов для микрослужб и контейнеров.

С общими комментариями и сообщениями об ошибках, пожалуйста, обращайтесь по адресу [email protected] Мы сожалеем, что не можем ответить на технические вопросы

Об авторах Эви Немет уволилась с факультета вычислительной техники Уни­вер­ ситета штата Колорадо в 2001 г. Многие годы она исследовала просторы Тихого океана на своей 40-футовой яхте “Wonderland” (“Страна чудес”) до ее трагического исчезновения в 2013 г. Четвертое издание этой кни­ ги  — это последнее издание, в котором она принимала активное уча­ стие, но мы изо всех сил старались сохранить ее текст там, где это было возможно. Гарт Снайдер (@GartSnyder) работал в компаниях NeXT и Sun и по­ лучил степень бакалавра электротехники в колледже Суортмор, штат Пенсильвания, а также степени магистра медицины и делового админи­ стрирования в Университете Рочестера.

Трент Р. Хейн(@trenthein) — большой энтузиаст кибербезопасности и автоматизации. Помимо технологий, он любит езду на велосипеде, гор­ ные лыжи, ловлю рыбу нахлыстом, туристические походы, песни в сти­ ле кантри, собак и оксфордскую запятую1. Трент получил степень бака­ лавра вычислительной техники в Университете штата Колорадо.

Бэн Уэйли — основатель компании WhaleTech, занимающейся независи­ мым консалтингом. Он отмечен призом компании Amazon как один из выдающихся энтузиастов Amazon Web Services (AWS Community Heroes). Он получил степень бакалавра компьютерных наук в университете шта­ та Колорадо в Боулдере.

Дэн Макин (@dan_mackin)  получил ученую степень бакалавра элек­ трической и компьютерной инженерии в университете штата Колорадо в Боулдере. Он применяет систему Linux и другие технологии с откры­ тым исходным кодом не только для выполнения своих профессиональ­ ных обязанностей, но и в качестве хобби  — для автоматизации сбора метеорологических данных. Дэн любит горные лыжи, парусный спорт, внутренний туризм, а также проводить время со своей женой и собакой.

Запятая, которая ставится перед союзом and в конце перечисления. — Примеч. ред.

1 

Памяти Эви В каждой области знаний есть авторитет, который ее определяет и  олицетворяет. В системном администрировании таким человеком является Эви Немет. Это пятое издание книги, в  которой Эви является главным автором. Хотя Эви не смогла физически присоединиться к  нам, ее образ всегда был рядом, кроме того, ей принадлежат многие главы и примеры. Мы прилагали огромные усилия для сохранения необычного стиля Эви, для  которого характерна объективность, техническая глубина и внимание к деталям. Профессиональный математик и криптограф, Эви еще недавно работала профессором информатики в Университете Колорадо в Боулдере. То, как возникло системное администрирование, и какое участие Эви в нем приняла, подробно описано в последней главе этой книги “Краткая история системного администрирования”. На протяжении всей своей карьеры Эви с  нетерпением ждала выхода на  пенсию, чтобы отправиться в  кругосветное плавание. В 2001 г. она наконец осуществила свою мечту — купила парусник Wonderland и отправилась в путешествие. Многие годы Эви приводила нас в  восторг рассказами об  удивительных островах, замечательных людях и  парусных приключениях. Работая над  двумя изданиями этой книги, Эви бросала якорь как можно ближе к берегу, чтобы загружать свои наброски через сети Wi-Fi. Никогда не отказываясь от  рискованных приключений, в  июне 2013 г. Эви стала членом экипажа знаменитого парусника Nina и отправилась в плавание по Тасманскому морю. Вскоре после этого шхуна Nina исчезла в сильном шторме, и с тех пор мы ничего не слышали от Эви. Она жила своей мечтой. Эви научила нас гораздо большему, чем системное администрирование. Даже когда ей исполнилось 70 лет, она оставалась лучшей: лучше всех организовывала сети, настраивала серверы, отлаживала ядра, колола дрова, жарила цыплят, пекла пироги и пила вино. Вместе с Эви все было достижимым. Здесь невозможно кратко сформулировать всю мудрость Эви, но некоторые принципы глубоко внедрились в наши головы. • Будьте консервативными по отношению к тому, что вы отправляете, и либеральными — к тому, что вы получаете.1 • Будьте либеральными к тому, кого вы нанимаете, но своевременно их увольняйте. • Избегайте двусмысленности. • Бакалавры — секретное сверхмощное оружие. • Красных чернил не бывает слишком много. • Вы не поймете, что вы делаете, пока не сделаете. • Время для суши есть всегда. • Не бойтесь попробовать что-то дважды. • Всегда используйте программу sudo. Мы уверены, что некоторые читатели спросят нас, что на самом деле означают некоторые из приведенных выше афоризмов. Мы, по  примеру Эви, оставим это в  качестве упражнения. Вы можете даже услышать, как она говорит: “Попробуйте сами. Посмотрите, как это работает”. Счастливого плавания, Эви. Мы скучаем по тебе. Этот принцип также известен как Закон Постела, названный в  честь Джонатана Постела (Jon Postel), который был редактором серии документов RFC с 1969 г. до своей смерти в  1998 г. 1 

Предисловие Современные технологи — мастера в поиске ответов в Google. Если другой системный администратор уже столкнулся с проблемой (и, возможно, решил ее), вы найдете описание решения в  Интернете. Мы приветствуем и  поощряем этот открытый обмен идеями и решениями. Если в Интернете есть так много информации, зачем нужно новое издание данной книги? Мы считаем, что эта книга способствует профессиональному росту системного администратора. • Мы предлагаем принципы, руководство и контекст для надлежащего применения технологии. Важно рассмотреть любое пространство проблем с разных точек зрения. Необходимо владеть основами смежных дисциплин, таких как безопасность, согласованность, методология DevOps, облачные вычисления и жизненные циклы разработки программного обеспечения. • Мы принимаем практический подход. Наша цель — обобщить коллективную точку зрения на  системное администрирование и  рекомендовать подходы, которые выдержали испытание временем. Эта книга содержит описания многочисленных случаев из практики и множество прагматических советов. • Это книга не о том, как запустить операционную систему UNIX или Linux у себя дома, в гараже или на смартфоне. Вместо этого мы описываем управление производственными средами, такими как предприятия, правительственные учреждения и университеты. В этих средах есть требования, которые выходят далеко за пределы возможностей типичного любителя. • Мы учим вас, как быть профессионалом. Эффективное системное администрирование требует как технических, так и программистских навыков. А также чувства юмора.

Организация книги Книга разделена на четыре большие части: основы администрирования, сеть, хранение и эксплуатация. Раздел “Основы администрирования” содержит широкий обзор операционных систем UNIX и Linux, с точки зрения системного администратора. Главы в этом разделе охватывают большинство фактов и методов, необходимых для запуска автономной сис­ темы. Раздел “Сеть” описывает протоколы, используемые в  системах UNIX, и  методы, применяемые для настройки, расширения и поддержки сетей и серверов, работающих в Интернете. Здесь также рассматривается сетевое программное обеспечение высокого уровня. Среди предлагаемых тем — система доменных имен, электронная почта, единый вход и веб-хостинг. В разделе “Хранение” рассматриваются проблемы хранения и управления данными. В этом разделе также рассматриваются подсистемы, которые допускают совместное использование файлов в сети, такие как сетевая файловая система и  протокол SMB, совместимый с Windows. Раздел “Эксплуатация” посвящен ключевым темам, с  которыми сталкивается системный администратор на  ежедневной основе при управлении производственными

Предисловие

37

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

Авторы Мы рады приветствовать Джеймса Гарнетта, Фабрицио Бранку и  Адриана Муата в  качестве соавторов этого издания. Глубокие знания этих ученых в  разных областях значительно обогатили содержание книги.

Контактная информация Пожалуйста, отправляйте предложения, комментарии и  сообщения об  ошибках на адрес [email protected] Мы отвечаем на письма, но, пожалуйста, будьте терпеливы; иногда может пройти несколько дней до того, как один из нас сможет ответить. Из-за объема электронной почты, которая приходит на этот адрес, мы сожалеем, что не можем ответить на технические вопросы. Чтобы просмотреть текущий список ошибок и другую актуальную информацию, посетите наш веб-сайт admin.com. Надеемся, вам понравится эта книга, и желаем удачи в увлекательном системном администрировании! Гарт Снайдер Трент Р. Хейн Бен Уэйли Дэн Макин Июль 2017 г.

Введение В 1942 г. Уинстон Черчилль описал одну из первых битв Второй мировой войны: “Это еще не конец, это даже не начало конца, но это, возможно, конец начала”. Я вспомнил эти слова, когда мне было предложено написать предисловие к пятому изданию “UNIX и  Linux: руководство системного администратора”. Исчезновение в  море Эви Немет было большой печалью для сообщества UNIX, но я рад видеть ее наследие в виде этой книги и ее многочисленных достижений в области системного администрирования. В основе Интернета изначально лежала система UNIX. В отличие от сложных коммерческих операционных систем своего времени система UNIX была минималистичной, ориентированной на инструменты, переносимой и широко используемой людьми, которые хотели делиться своей работой с  другими. То, что мы сегодня называем программным обеспечением с  открытым исходным кодом, в  первые годы работы UNIX и Интернета было уже широко распространенным, но не имело названия. Технические и академические сообщества открыто публиковали свои результаты, потому что выгоды, очевидно, перевешивали издержки. Подробные истории UNIX, Linux и  Интернета были подробно описаны в  других книгах. Я касаюсь этих очень тонких тем только для того, чтобы напомнить всем нам, что современный мир во многом обязан открытому исходному программному обеспечению и Интернету, а его первоисточником является UNIX. Поскольку ранние UNIX- и интернет-компании стремились нанимать самых ярких людей и  реализовывать самые инновационные функциональные возможности, переносимость программного обеспечения часто приносилась в  жертву. В конце концов, системные администраторы вынуждены были учить немногое о  многом, потому что никакие две операционные системы в  стиле UNIX (тогда и  сейчас) не были абсолютно одинаковыми. Являясь действующим системным администратором UNIX в середине 1980-х и позже, я должен был знать не только сценарии оболочки и конфигурацию Sendmail, но и драйверы устройств ядра. Также важно было знать, как исправить файловую систему с помощью восьмеричного отладчика. Веселые были времена! Именно в  это время появилось первое и  все последующие издания данной книги. В разное время мы называли авторов “Эви и экипаж” или “Эви и ее дети”. Поскольку я работал над программой Cron и сервером BIND, каждый раз, когда выходило очередное издание этой книги, Эви проводила одну-две недели со мной (с моей семьей и  у меня на работе), чтобы убедиться, что книга содержит все, что нужно, в ней нет ошибок, а о каждой из программ сказано что-то уникальное и полезное. Честно говоря, общение с  Эви было изнурительным, особенно когда ее что-то очень интересовало или приближался контрольный срок, или, как в  моем случае, происходило и  то, и  другое. Тем не менее, как уже было сказано, я ужасно скучаю по Эви и ценю каждое воспоминание и каждую ее фотографию. За десятилетия многое изменилось. Удивительно наблюдать, как эта книга развивается вместе с самой системой UNIX. Из каждого нового издания постепенно исчезают устаревшие и неактуальные технологии, чтобы освободить место темам, которые стали важными для администраторов UNIX, по крайней мере по мнению авторов. Трудно поверить, что мы потратили десятки киловатт энергии на  компьютеры размером с грузовик, чьи возможности теперь затмеваются смартфоном Android. В равной степени трудно поверить, что мы использовали сотни или тысячи серверных и настольных компьютеров с уже устаревшими технологиями, такими как rdist. В те годы из-

39

Введение

дания этой книги помогали таким людям, как я (и Эви), справляться с разнообразными, а  иногда и  особенными компьютерами, которые были реальными, а  не виртуальными, и каждый из которых нужно было поддерживать, а не инсталлировать заново (или, как на платформе Docker, собирать заново) каждый раз, когда что-то требовало исправления или обновления. Мы адаптируемся или сходим со сцены. “Дети Эви”, которые продолжают наследие Эви, адаптировались и вернулись в этом пятом издании, чтобы рассказать вам, что необходимо знать о том, как работают современные компьютеры под управлением систем UNIX и  Linux и  как заставить их работать так, как вы хотите. Потеря Эви знаменует собой конец эры, но также поднимает вопрос о  том, сколько аспектов системного администрирования ушло в  историю вместе с  ней. Я знаю десятки умных и  успешных технологов, которые никогда не будут заделывать кабели в задней части стойки оборудования, не услышат тон модема и не увидят кабель RS-232. Это издание предназначено для тех, чьи системы живут в облаке или в виртуализированных центрах обработки данных; тех,  чья административная работа в  значительной степени принимает форму исходного кода автоматизации и конфигурации; тех, кто тесно сотрудничает с разработчиками, сетевыми инженерами, сотрудниками службы контроля и всеми другими рабочими пчелами, которые населяют современный улей. Вы держите в руках новейшее, лучшее издание книги, чье рождение и эволюция точно отслеживали рождение и  эволюцию UNIX и  интернет-сообщества. Эви очень гордилась бы своими детьми, как из-за этой книги, так и  из-за того, кем они оказались. Я ими горжусь. Пол Викси (Paul Vixie) Ла Хонда, Калифорния Июнь 2017 г.

Благодарности Многие люди внесли свой вклад в этот проект — от технических обзоров и конструктивных предложений до  общей моральной поддержки. Следующие лица заслуживают особой благодарности. Джейсон Каролан (Jason Carolan)

Нед Макклейн (Ned McClain)

Дэйв Рот (Dave Roth)

Рэнди Элсе (Randy Else)

Бет Мак-Элрой (Beth McElroy)

Питер Санкаускас (Peter Sankauskas)

Стив Геде (Steve Gaede)

Пол Нельсон (Paul Nelson)

Дипак Сингх (Deepak Singh)

Асиф Хан (Asif Khan)

Тим О’Рейли (Tim O’Reilly)

Пол Викси (Paul Vixie)

Сэм Лезерс (Sam Leathers)

Мадхури Пери (Madhuri Peri)

Наш редактор в издательстве Pearson, Марк Тауб (Mark Taub), заслуживает огромной благодарности за его мудрость, терпеливую поддержку и покровительственное отношение на протяжении работы на книгой. Можно с уверенностью сказать, что это издание не получилось бы реализовать без него.

40

Введение

Мэри Лу Нор (Mary Lou Nohr) уже более 20 лет является нашим безжалостным редактором рукописей. Когда мы начали работу над этим изданием, Мэри Лу уже ушла на заслуженную пенсию. После многочисленных и продолжительных просьб она согласилась присоединиться к нам на бис. (И Мэри Лу Нор, и Эви Немет изображены на обложке. Вы можете найти их?) У нас была фантастическая команда технических рецензентов. Три преданных друга оценили всю книгу: Джонатан Корбет (Jonathan Corbet), Пэт Парсегян (Pat Parseghian) и Дженнин Таунсенд (Jennine Townsend). Мы высоко ценим их упорство и тактичность. Удивительные картинки и обложка этого издания были задуманы и исполнены Лизой Хейни (Lisa Haney). Ее портфолио находится в режиме онлайн на сайте lisahaney.com. И последнее, но не менее важное: спасибо Ласло Немет (Laszlo Nemeth) за его готовность поддержать продолжение этой серии.

От издательства Вы, читатель этой книги, и  есть главный ее критик и  комментатор. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес. Мы ждем ваших комментариев и  надеемся на  них. Вы можете прислать нам электронное письмо, либо просто посетить наш веб-сайт и  оставить свои замечания там. Одним словом, любым удобным для  вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более интересными для вас. Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию последующих книг. Наши электронные адреса: E-mail: [email protected] WWW: http://www.dialektika.com

ЧА СТЬ

1

О сно вы администриро вания

Глава

1

с чеrо на чать

М ы нап исал и эту к н и гу, чтобы зан ять конкретную н и ш у в обш ирной экосистеме mаn-страниц, блогов, журналов, книг и других справочн ы х материалов, которые должны удовлетворять потребности с исте м н ых адми н истраторов UNIX и Linux. Во-перв ы х , это общее руководство . В н е м расс матриваются осн о в н ы е с исте м ы управле н и я , выделяются разн ые части каждой из н и х и объясняется , как он и работают вместе . Во м ногих случаях, когда вы должны выбирать между различн ы м и реализация ­ м и определен ной кон цепции, мы описываем пре и м ущества и недостатки самых попу­ л ярн ы х возможностей . Во- вторых, это краткий спра вочн и к , в котором собрано то, что необходи мо з нать, чтобы в ыпол н ять т и п и ч н ы е задач и н а м ножестве распростране н ны х с истем U N IX и Linux. Например, команда p s , показывающая состоя н и е вы пол н я е м ы х процессов , п оддержи вает более 80 параметров командной строки в с истемах Linux. Однако всего несколько комбинаций этих параметров удовлетворя ют большинство потребностей с и ­ стем ного адми нистратора; м ы приводим их в разделе 4.3. Наконец, в этой кни ге основное внимание уделяется управлению корпоратив н ы м и серверами и сетя м и , т.е. серьезному профессиональному с исте мному адми н истрирова­ нию. Легко настроить одну систему; сложнее сохранить распределенную облачную плат­ форму, работающую без сбоев, несмотря на опасность распростране н и я вирусов, наруше­ ние связности сетей и целенаправленные атаки. Мы описываем методы и эмпирические правила, помогающие восстанавливать системы после сбоев , и предлагаем решения, ко­ торые масштабируются по росту размеров, сложности и неоднородности вашей импери и . М ы не претендуе м н а пол ную объективность, но считае м , что в ыразили с вои предпо­ чтения достаточно ясно. Одной из и нтересных особен н остей с истемного админ истриро-

Часть 1. Основы администрирования

44

ван и я является то, что разум н ые л юди могут и меть соверш е н но разн ы е представления о наиболее подходящем ре ш е н и и . М ы предлагаем наши субъе ктивн ые м н е н ия как и н ­ формацию к разм ышле н и ю. Решайте сами , до какой степени в ы с н им и согласн ы и на­ с колько они соответствуют вашей среде .

1 . 1 . ОСНОВНЫЕ ОБЯЗАННОСТИ СИСТЕМНОГО АДМИНИСТРАТОРА В при веден н ых н иже разделах описан ы основные задачи , которые должны в ыпол ­ нять адми н истраторы . Эти обязан ности н е всегда возлагаются на одного человека, во м ногих орган изациях работа расп ределяется между нескол ьки м и чле н а м и команды . Одн ако по крайней мере оди н человек должен разбираться во всех ком понентах и обе­ спечивать правил ьное ре ш е н ие каждой задачи .

Уп равление доступом Систем н ый администратор создает учетные записи для новых пользователей, удаляет учетн ые записи н еакти вных пользователей и решает все связанные с учетн ы м и запися ­ ми проблемы, которые могут возникнуть ( например, забытые пароли и потеря н н ые пары кл ючей). Процесс добавления и удаления учетных записей обычно автоматизируется с по­ мощью систе м ы управления конфигурацией или централизованной службы каталогов. W Информация о работе с учетными записями пользователей приведена в главах 8,

1 7 и 23.

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

А втоматизация задач Использование инструментов для автоматизации повторяющихся и трудоем ких задач повышает эффективность работы , сн ижает вероятность ошибок и повышает вашу спо­ собность быстро реагировать н а изменяющиеся требования. Адми нистраторы стремят­ ся сократить кол ич ество ручного труда, необходимого для бесперебойной работы с истем. Знакомство с языками сценариев и и нструментами автоматизации — важная часть работы. W Информаци ю о сценариях и автоматизаци и см. в главе 7.

Уп равление резервн ыми коп иями Резервное копирование дан н ы х и их восстановл е н ие п р и необходимости я вл я ются важн ы м и ад м и нистративными задачам и . Хотя резерв ное копирование — долгое и скуч ­ ное занятие , ч астота бедствий в реальном м ире просто сл ишком вели ка , чтобы можно было и гнорировать эту работу. W Советы по резервному копированию см. в разделе 20. 1 3 . Существуют операцион н ы е систе м ы и отдел ьные пакеты программ ного обеспече­ н и я , которые заре коме ндовали себя как хорошие и нструменты и методы для облегчения

Глава 1 . с чего начать

45

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

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

W Информацию об управлении п рограммным обеспечением см. в главе б . Термин поставка программного обеспе чения относ ится к п роцес с у в ы п уска обновл е н ­ н ых верс и й , гла в н ы м образом , собстве н ного програм м ного обе с п ечения . Непрерывн ая поставка п ереносит этот п роцесс на следующий уровен ь , п редус матривая авто м атиче­ с кую регуля рную п оставку п рограм м ного обесп ечения п ол ьзователям п о м ере е го разра­ ботки . Ад м и н истраторы п о м огают внедрять надежн ые п роце с сы п оставки , отвечающие требован и я м п ред п риятия .

W Информацию о развертыва н и и и непрерывной поставке программ ного обеспечения см. в главе 2 6 .

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

W Информацию о мониторинге см . в главе

28 .

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

W Информацию о сетевых проблемах см. в разделе

1 3. 1 2.

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

Часть 1. Основы администрирования

46

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

m Информацию о локальной документации см. в разделе 3 1

.

3.

Бдител ьный мон иторинг безопасности Ад м и н истраторы — п ервая л и н и я защиты сетевых с и стем . Адм и н истратор должен вы пол н ять правил а безопас ности и вырабаты вать процедуры для предотвращен и я на ­ рушений . В зави си мости от контекста эти функции м огут в кл ючать как нескол ько п ро ­ стых проверок несанкционированного доступа , так и слож ную сеть ловушек и программ аудита. Систем ные ад м ин истраторы осторожн ы по с вое й природе и часто я вляются спе ­ циал истам и по безопасности в техничес ких организациях.

m И нформацию о системах безопасности см. в главе

27.

Настройка п роизводител ьности UN IX и Liпux это оп ерацио н н ы е с исте м ы обще го назнач е н и я , которые хорош о подходят практически для л юбой м ысли м ой вычисл ител ьн ой задач и . Адм и н истраторы м огут адаптировать с исте м ы для достижени я о п тимал ьной п роизводительн ости в соот­ ветствии с потребностя м и пользователей , доступ ной ин фраструктурой и услугам и , п ре ­ доставляе м ы м и систе м а м и . Есл и сервер работает плохо , задача адм и н истратора — п ро ­ а н ал изировать е го работу и определить области , которые нуждаются в улуч ш е н и и . —

W Информацию о вопросах п роизводительности с м . в главе

29 .

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

m Информацию о разработке локальных п равил см. в разделе

1 .8.

Работа с поста вщиками Для п редос тавле н и я разнообразных вспомогател ьн ы х услуг и продуктов , с вязан ных с их в ы ч исл ите л ьн о й и н фра с труктурой , бол ьш инство орган изаци й п рибе гае т к п о ­ стор о н н ей п о м ощи . Эту помощь мо гут оказы вать разработч и к и п рограм м н о го обе ­ с пе ч е н и я , поставщи ки облачной и н ф раст руктур ы , продавцы п рогра м м н ых п р одукто в ка к услуг (service-as-a-service — Saa S ) , сотрудн и к и службы поддержки , кон с ультанты , п одр ядчики , эксперты по безопас ности и пос тавщики платформ ил и ин фраструктур . Адм и н и с траторам м ож н о поруч ить выбирать поста в щ и ков , пом огать в пере говорах по контрактам и внедрять реш е ния по сл е заверш е н ия работы над документа ми .

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

Глава 1 . С чего начать

47

администраторов обруш и вается град жалоб , начиная с » О н еще вчера работал , а сегодня нет ! Ч то вы изменил и ? » и заканчивая » Я пролил кофе на клав и атур у! Мо жн о л и вылить на нее воду, чтобы смыть кофе? » В бол ьшинстве случаев ваш и ответы на эти вопросы гораздо больше вл и я ю т на то , наскол ько цен н ы м адми н истраторо м вас будут сч итат ь, чем л юбые техн ические н а вы ки , которы м и вы могл и бы обладать . Вы можете л ибо вы ть от нес п раведливости , л ибо радо­ ватьс я тому, ч то за одну хорошо вы п ол н ен ную п рос ьбу о п о м ощи ва м будет н ач исле но бол ьше баллов , чем за п ять часов ночной работы . Выбор за ва м и !

1 .2 . П РЕДВАРИТЕЛЬНЫЙ опыт В этой книге м ы предп олагаем , что у вас есть о пределе н н ы й о п ы т рабо т ы с с и с те ­ мам и Linux ил и U N IX. В частности , у вас должно бы ть общее предста влен и е о том , как система выгл ядит и вос п рин имается с точки зрен ия пользовател я , п оскольку мы н е рас ­ сматри вае м этот м атериал . Повысить уровень вашей квалификации п омогу т н ес кол ько хоро ш их книг ; с м . раздел » Рекомендуемое чтение » в к он ц е глав ы . М ы любим хорошо п родуманные графические и нтерфей с ы . К сожал е н и ю , инс тру­ менты графического п ол ьзовательского и нтерфейса для сист ем н ого ад м и н и с трир о в а н ия в системах U N IX и Linux остаются рудиментар н ы м и по сравнению с богатст вом базово­ го п рограммного обес п ечения . В реал ьном м и ре адм и н истраторам должно бы ть удобно испол ьзоват ь командную строку. Для редактирования текста м ы настоятел ьно ре ком е ндуе м и зучить ред а ктор vi ( те ­ п ерь он ч аще все г о рассматри вается в рас ш и ре н но й форм е , vim ) , которы й я вляется стандарт н ы м для всех систем . О н простой , м ощ н ый и эффе ктив н ы й . Ос воен и е редак­ тора vim — это , пожалуй , луч ш и й способ повыш е н и я п роизводител ьности , досту п н ы й для адми н истраторов. Исп ользуйте команду vimtutor для отличн ого инт ерактивного введен ия в эту тему. Существует альтернатива — редактор nano с графически м п ользовател ьск и м и нтер­ фе йсом , п редставл я ю щ ий собо й п росто й и компакт н ы й » р еда ктор для начинающих» с экранн ы м и подсказкам и . Не испол ь зуйте е го откр ы то ; п рофессио н альны м админ и­ страторам зачастую очень не н равится , когда их коллеги используют этот редактор . Хотя адм и н истраторы о б ы ч н о н е сч итаются разработч и ка м и п рограм м ного о бе ­ с п е ч е н и я , отрасл е в ы е те нде н ц и и разм ы вают гра н и ц ы м ежду эт и м и ф у н кц и я м и . Эффекти в н ы е адми н и страторы , как правило, знают м н ого я з ы ко в п рограм мирования и н е прочь освоить новый язык, если возн икнет такая необходимость.

W Введение в сценарии см . в главе 7. Для создан ия новых сценариев мы рекомендуем язы ки Bash (или bash, или sh), Ruby Python. Bash — это командн ая оболочка , принятая по умолчан и ю для больши нства си­

или

стем U N IX и Linux. Bash п римитивен как язык програм мирования , н о являе тс я хорошим средством интеграции инструментов системного администратора. Python — это ум н ый язык с хорошо понятным синтаксисом , широким сообществом разработчико в и библ иотеками , которые облегчают решение многих задач . Разработчи ки , использу ющи е язык Ruby, оп исы­ вают его как » п риятный » и » красивы й » . Языки Ruby и Python во мн огом п охожи , и мы об­ наружили , что они обладают одинаковыми фун кционал ьными возможностя м и д11 я уп равле­ н и я системами . Выбор между ними в ос новн ом за висит от личных предп очте ний. М ы также пред п олагаем , что в ы умеете работать с и н струм е нтом expect, которы й п редставляет собо й н е я з ы к п ро граммирован ия , а и нт ерфейс для за п уска и нтерактивных

Часть 1. Основы администрирования

48

програ м м . Это эффективная технология интеграции, которая может замен ить н екото­ рые сложные сценар и и и проста в ос вое н и и . Самые важн ые факты , которые необходимо знать о сценариях дп я работы с языками Bash, Python и Ruby, обобщаются в главе 7. В н е й также рассматриваются регулярные в ыраже н и я ( шаблоны соответствия текста) и некоторые идиом ы оболоч ки , полезные дпя систе м н ых админ истраторов.

1 .3 . ДистРИ&Утивы L1нux В дистрибутив Linux входит ядро операционной с истемы и пакеты, содержащие все команды, которые можно вы пол нять в с истеме. Все дистрибутивы имеют одну и ту же линейку ядер, но формат, тип и количество пакетов немного отличаются. Дистрибутивы также различаются по направленности, уровню поддержки и популярности. По-прежнему существуют сотни независи м ых дистрибутивов Linux, но м ы считае м , что в ближайшие годы в производствен н ых средах будут преобладать дистрибутивы Deblan и Red Hat . П о бол ьшому счету, различия м ежду дистрибутивам и Linux н е я вля ются очен ь уж больш и м и . Довольно странно, что существует так м ного разн ых дистрибутивов, каждый из которых утверждает, что он отличается «легкой инсталляцией» и » крупной библ и ­ отекой п рограммного обеспечения » . Трудно избежать вывода о том , что л юдям просто нравится создавать новые дистрибутивы Linux. Большинство основных дистрибутивов имеют относительно безболезненную процедуру инсталл я ции, среду рабочего стола и некоторую форму управления пакетами. Вы можете легко их испытать, запустив экземпляр на облаке или на локальной виртуальной машине. П о бол ьшей части незащищенность операционных систем общего назначения я вля ­ ется следствие м и х сложности. Практически все ведущие дистрибутивы забиты м ноже­ ством неиспользуем ых пакетов програм много обеспечения; в резул ьтате часто возн ика­ ют уязвимости в области безопасности и сложности в управл е н и и . В ответ поя вилось относительно новое поколен ие м и н ималистских дистрибутивов. Л идером среди н их яв­ ляется с истема CoreOS, которая предпочитает запус кать все программное обеспечение в контейнерах . Alpine Linux — это легкий дистрибутив, которы й используется в качестве основы дЛ Я м ногих публ ич н ых образов Docker. Учитывая эту редукционистскую тенде н­ цию, мы ожидаем , что в бл ижайшие годы доля дистрибути вов Linux будет сокращаться . Выбрав дистрибутив, вы делаете и нвестиции в какой-то кон кретный способ работы . Вместо того чтобы учитывать только функции инсталлированного программ ного обе­ с печен и я , разумно посмотреть, как ваша организация и кон кретн ы й поставщик будут работать друг с другом. Переч исл им некоторые важные вопросы. •

Будет л и существовать этот дистрибутив через пять лет?

Будет ли дистрибутив распространяться поверх последних исправлений уязвимости?

И меет ли этот дистрибутив активное сообщество и достаточную документацию?

Есл и у меня возникнут п роблемы , будет ли продаве ц говорить со м ной и сколько это будет стоить?

Н екоторые из самы х популярных распространенных дистрибутивов перечисл е н ы в табл. l . l . Наибол ее жизнеспособные дистрибутивы не обязательно являются корпоративн ы ­ м и . Например, м ы ожидаем , что дистрибутив Deblan Linux (ладно-ладно, Deblan G N U/ Linux!) останется жизнеспособным в течение дп ительного времени, несмотря на то, что Deblan не я вляется ком панией, ничего не продает и не предпагает поддержки на уров-

Глава 1 . с чего начать

49

н е предп риятия . П роект Deblan извле кает вы году из существован ия п реданной гру п п ы уч астн и ков и огром ной популярности дистрибути ва Ubuntu, основа н но го на нем . Таблица 1 . 1 . Самые распространенные общедоступ ные дистрибутивы Unux Дистрибутив

В еб-сайт

Комментарии

Arch CeпtOS CoreOS DеЬiап Fedora Kali Liпux Miпt

a r chl i nux . o r g

Для тех, кто не боится командной строки Бесплатный аналог R e d Hat Eпterprise Все в контейнерах Бесплатный, как и большинство дистрибутивов GNUish Испытательный стенд для R e d H a t Liпux Для специалистов по поиску уязвимых мест Ubuпtu для настольных компьютеров Бесплатный аналог SUSE Liпux Eпterprise Liпux для марш рутизаторов и встроенных устройств Версия RH EL, поддерживаемая Oracle 20МиБ, все в контейнерах Надежный, медленно меняющийся, коммерческий Древний, долгоживущий дистрибутив Очень популярный в Европе, мно г оязычный Улучшенная версия Deblaп

centos . org c o r e o s . с от debian . org fedoraproj ect . org kali . org l i nuxтi n t . сот ope n s u s e . o r g

openSUSE openWRT

openwrt . o r g

Oracle Liпux RaпcherOS Red Hat Eпterprise Slackware SUSE Liпux Enterprise Ubuпtu

o r a c l e . с от r a n che r . с от r e d h a t . с от s l a c kw a r e . сот s u s e . с от ubuntu . с от

Пол н ый с п исок дистрибути вов , вкл ючая м ножество неан глоязыч н ых , можно най ти н а сайтах l w n . ne t / D i s t r i but i o n s или d i s t rowa t c h . c om.

W Дополнительную информацию о платформе

Docker и контейнерах см. в главе 25 .

1 .4. П РИМЕРЫ СИСТЕМ, ИСПОЛЬЗУЕМЫХ

В

ЭТОЙ КНИГЕ

В кач естве основных примеров дл я этой кн и г и м ы выбр ал и три п о п ул я р н ы х дис ­ т рибут и ва Linux и оди н вариа нт U N IX: Deblan G N U / Linux, Ubuntu Linux , Red H at Enterprise Linux (и его клон CentOS) и Fre e B S D . Эти систе м ы я вляются ре презе н тати в ­ н ы м и дл я об щ е го рын ка с учетом знач и тел ь н ой ч асти и н стал л я ц ий , испол ь зуе м ы х се ­ годн я на круп н ых объектах. И нформация в этой кн и ге обы ч н о относ ится ко всем рассматри ваем ы м с истемам , если не указано иное. Де тал и , характер н ые для отдел ь ной систе м ы , отм ече н ы логотипом .

Deblan G N U/Linux 9 . 0 » St retch » Ubuntu00 1 7 . 04 » Zesty Zapus»

RHEL

Red H at® Enterprise Linux00 7 . 1 и CentOS00 7 . 1 Fre e B S D® 1 1 .0

Бол ь ш и н ство этих торговых марок п р и надл ежат п роизводи телям , в ы пускающи м со­ от ветствующее п рограммное обес п ече н и е , и испол ьзуются с л юбезного разр е ш е н и я и х владел ьцев . Те м н е менее поставщики н е рецензиров ал и и н е ут верждал и содержание ЭТОЙ К Н И Г И .

Часть 1. Основы администрирования

50

Мы н еодн ократно п ытал ись, н о не с могл и получить разреше ние от Red H at на ис­ пол ьзован ие их логотипа с красной шля пой , поэтому был и вынужден ы испол ьзовать а кро н и м RH EL. Более подробная информация о каждой из илл юстративных систем приводится в н и ­ жеследующих разделах.

При меры дистрибутивов Li nux И нформаци я , характерная для Linux, а н е для какого-либо кон кретного дистрибутива, отмечена логотипом с пингвином Туке , показа н н ы м сле ва. Deblan ( п роизносится как «деб-я н » в ч есть покойн о го ос нователя Я н а Мердока ( lan Merdock) и его жен ы Дебры (Debra)) я вляется одн им и з сам ых старых и наиболее популярных дистрибутивов. Это некоммерческий прое кт с более чем тысячами участн и ков по всему м иру. П роект Deblan поддержи­ вает идеологическую приверже н н ость развити ю сообщества и открытому доступу, поэтому для него никогда не возникает вопросов о том , какие части дистрибутива я вляются свободны м и или распространяе м ы м и . Существуют три выпус ка дистрибутива Deblan, которые поддержи ваются одновре ­ м е н но: стабил ьн ы й , н ацел е н н ы й на промы шл е н н ы е серверы ; нестабил ь н ы й , содержа­ щий пакеты , которые могут и меть ошибки и уязвимости с точ ки зрения безопасност и ; и тестовый, которы й находится где-то посреди не. Дистрибутив Ubuntu основан на проекте Deblan и поддержи вает его привер­ жен ность бесплатному програм мному обеспече н и ю с открытым исход н ы м кодо м . З а с истемой Ubuntu стоит бизнес — ком пания Canonical Ltd. , ос но­ ван ная предпринимателем М арком Ш аттлвортом ( Mark Shuttleworth). Ком пания Canonical предлагает множество выпус ков Ubunt u , предназна­ ч енн ых для облаков, настольных ком пьютеров и серверов без программного обеспече н и я . Существуют даже выпус к и , предназначен н ые дл я телефонов и планшетов. Номера верс и й Ubuntu означают год и меся ц, например вер­ сия 1 6. 1 О появилась в октябре 2016 года. Каждая версия также имеет аллите­ рацион ное кодовое и м я , такое как Vivid Vervet или Wily �rewolf. Ежегодно выпус каются две верс и и Ubuntu: в апреле и октябре . Апрел ьс кие выпуски в четн ые годы представляют собой долгосрочн ые верси и поддержки (long-term support LTS ) , которые обещают пять лет обновлений технического обслуживан ия. Это выпуски , рекомендова н н ые для испол ьзования в производстве.

RHEL

Система Red H at была дом и н ирующей силой в м ире Linux более двух десяти­ лети й , и ее дистрибутивы ш ироко испол ьзуются в Северной Америке и за ее пределам и . По количеству и нсталляций Red H at , l nc . я вляется самой усп е ш ­ н о й в м ире компанией с открытым исходн ым кодом .

С истема R e d H at Enterp rise Linux , часто сокращаемая д о R H E L, ориентирова н а на производствен н ые среды крупных предприяти й , которые требуют поддержки и кон ­ салтинговых услуг дл я бесперебойной работы своих систем . Как н и парадоксально, с и ­ стема R H E L является открытым исходн ы м кодом , но требует лицензии. Если вы не хо ­ тите платить за лицензи ю , вы не и меете права инсталлировать Red H at . Ком пания Red Hat также с понсирует с истему Fedora, коллекти вно разработа н н ы й дистрибутив , служащий и нкубатором для ультрасоврем е нного программного обеспече­ ния, которое н е считается достаточно стабильн ым для R H EL. Fedora испол ьзуется в ка-

Глава 1 . С чего начать

51

честве исходного тестового стенда для программного обеспечен ия и конфигураци й , ко­ торые позже находят свой путь к R H EL. Дистрибутив CeпtOS практически идентичен Red H at Enterprise Linux, но он бесплатный. CentOS Project ( c e n t o s . o rg ) принадлежит Red H at и выпол няет­ ся ее ведущи м и разработчи кам и . Однако они работают отдельно от команды Red H at Enterprise Linux. На дистрибутив CentOS не распространяется торго­ вая марка Red H at и в н е м нет нескол ьких патентованных инструментов, но в других отношен иях они эквивалентн ы . Cent O S отл и ч н ы й выбор для организаций , которые хотят развернуть производ­ стве н н ы й дистрибутив, не выплачивая десяти ну Red H at . Возможен и гибридны й под­ ход: основные серверы могут зап ус кать Red H at Enterprise Linux и пользоваться пре­ восходной поддержкой Red H at , в то время как дл я непроизводстве н н ы х систем может испол ьзоваться с истема CentOS. Это решение уч итывает все важн ы е аспекты с точ ки зрения риска и поддержки, а также минимизирует стоимость и сложность управления. Систем а Cent O S стрем ится к пол ной двоич ной совместимости и совместимости по спе цификац и я м и отклонениям с системой Red H at Enterprise Linux. В место того чтобы постоян но повторять » Red Hat и CentOS » , в этой книге мы обычно упоминаем только одн у из них. Текст зачастую в равной степени относится и к Red H at , и к CentOS, есл и не указано обратное . Другие популярные дистрибутивы также я вляются потом кам и Red Hat . Ком пания O racle продает переименован ную и видоизменен ную верс и ю Cent O S клиентам с воего програм м ного обеспечения для обслуживан ия корпоративных баз дан н ых. Дистрибутив Amazon Linux, доступный для пользователей служб Amazon Web Servises, первоначально был создан на основе систе м ы CentOS и по- прежнему разделяет м ногие ее соглашения. Бол ьш инство адм и н истраторов в какой-то момент своей карьеры обязательно стол­ кнутся с с истемой, подобной Red Hat , и знакомство с ее н юансам и полезно , даже если эта система не установлена в вашей организации. —

Пример дистрибут ива U N IX Популярность U N IX в течение н екоторого времен и постепенно ослабевает, и бол ь­ ши нство устаревших дистрибутиво в U N IX (например, Solaris, H P- UX и AIX) больше не испол ьзуются . Открытый исходн ы й код систе м ы B S D я вляется искл ючением из этой тенденции и продолжает оставаться п редметом культового поклонения, особенно среди экспертов по операцион н ы м системам, приверже н це в открытого програм м ного обеспе­ ч е н ия и систе м н ых адми нистраторов, нацел е н н ых на безопасность. Другим и слова м и , некоторые из ведущих операционных систем в м ире полагаются на различные дистрибу­ тивы B S D . Например, с истема MacOS компан ии Apple использует наследие B S D . Дистрибутив Free B S D , впервые вы пуще н н ы й в кон це 1 99 3 г. , я вляется наи­ более широко испол ьзуе м ы м производн ы м инструментом BSD. В соответ­ стви и со статисти кой ис пол ьзования он зан имает 70% дол и р ы н ка верси й B S D . Среди е го пол ьзователе й встречаются крупн ы е интернет- ком пан и и , такие как WhatsApp, Google и Netflix. В отличие от Linux, Free B S D — это полная операцион ная с истема, а не только ядро. Как программное обеспе­ чение ядра, так и пользовател ьское программное обеспечение лице нзируют­ ся в соответствии с разреш ител ьной л ицензией B S D , что с пособствует раз­ витию и расш ире н и ю бизнес-сообщества.

Часть 1. основы администрирования

52

1 .5. ОБОЗНАЧЕНИЯ И ТИПОГРАФСКИЕ СОГЛАШЕНИЯ И мена файлов, команды и аргументы команд, которые следует набирать на клавиа­ туре без измен е н и й , дан ы полужирным шрифтом. Аргументы , вместо которых следует подставлять кон кретн ые значения, дан ы курсивом. Например, в команде ер фа йл к а та лог

предполагается, что аргумент ф а йл следует заме н ить именем реального файла, а аргу­ мент ка талог именем реал ьного каталога. Фрагме нты сценариев и файлов конфигурации дан ы монош и р и н н ы м ш рифто м . Ком ме нтари и к и нтерактивным сеансам и ногда сопровождаются символом коммента­ рия языка bash и выделяются курсивом , напри мер: —

$ grep ВоЬ /puЬ/phone l i s t

# На й ти номер теле фона Бо ба

555-2834 5 5 5 -2 3 1 1

ВоЬ Knowl e s ВоЬ Smi t h

С и м вол $ обозначает приглашение оболочки ввести дан н ы е , адресован ное обы ч ­ ному, непри вилегированному пол ьзователю. П р и глаш е н и е дл я привилегирова н ного пользователя начинается символом # . Если команда я вляется специфичной для дистри­ бутива ил и семейства дистрибутивов, символ приглашения сопровождается название м дистрибутива. Например: $ sudo su — root # Ста ть привилегиро в а нным поль зова телем # passwd # Изменить пар оль суперполь з о в а теля roo t d e Ь i a n # dpkg — l # Выв е с ти инсталлир ов а нные # па к е ты в

Deb i a n

и

Ub un t u

Это соглашение принято в стандартных оболоч ках U N IX и Linux. За исключением специал ьных случае в мы старал ись избегать испол ьзова н ия особых шрифтов и форматов, чтобы не отвлекать читателей. Например, м ы часто говорим о таких сущностях, как группа daemon , никак не выделяя их с помощью отдел ьного формата. П р и описани и синтаксиса команд м ы , как правило, испол ьзуем те же обознач е н и я , что и в интерактивном руководстве: • текст, заключ е н н ы й в квадратн ые с кобки ( » [ » и ] » ) , я вляется необязательн ы м ; «

• •

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

«

«

Например, спецификации bork [ -х ]

( on l off } имя_ фа йла

соответствует л юбая из следующих команд: bork on / e tc /pas swd bork -х off /etc /pas swd /etc/ smartd . conf bork off /us r / l iЬ / tmac

В выражен иях с шаблонами поиска используются следующие метаси м вол ы : • •

звездочка ( * ) обозначает нуль или более символов; знак вопроса ( ? ) обозначает оди н символ ;

тильда ( — ) обозначает н ачальный каталог текущего пользователя ;

выражение

-пользов а тель

обозначает начальны й каталог указан ного пользователя .

Глава 1 . с чего начать

53

Например, и ногда м ы обозначаем каталоги , где хранятся сценар ии зап ус ка (eto/ rc* . d, eto/rc* . d и т.д . ) , сокращен н ы м шаблоном etc/rc* . d.

1 .6. Единицы ИЗМЕРЕНИЯ М етрические приставки кило- , м е га- и гига- определя ются показателя м и сте п е н и ч исла 1 0 (например, оди н мегагерц составляет м илл ион герц). Однако дл я ком пьютер­ н ых типов дан н ых испол ьзуются степени числа 2 . Например, один » мегабайт» памяти составляет 220 , ил и 1 048 576 байт. Ассоциация твердотел ьных техн ологий ( Solid State Technology Association) Объедин е н ного инженерного совета по эле ктро н н ы м устрой ­ ствам (Joint Electronic Device Engineering Council — J ED EC) даже превратила эти еди н и ­ ц ы измерения в официальны й стандарт Standard 1 00 8 . 0 1 , которы й признает их степеня­ м и двойки (не без н екоторых натяжек). П ытаясь внести ясность, М еждународная электротехническая ком иссия ( lnternational Elect rotechnical Commission — 1 ЕС) определила ряд ч исловых приставок , основа н н ы х именно н а степенях ч исла 2 : киби- (kibl — ) , меби- ( mebl — ) , гиби- (gibl ) и так далее с аб­ бревиатурам и Ки Б ( Ki ) , М и Б ( Mi ) и Ги Б (Gi) соответствен но. Эти еди н и ц ы измерения искл ючают двус мыслен ность, но их еще тол ько начинают испол ьзовать. П оэтому при ­ выч н ы й набор кило-, м е га- и гига-префиксов все еще в ходу в обоих см ыслах: десятич ­ ном И ДВОИЧНОМ . О предел ить кон кретное значение можно по конте ксту. Объе м оперативной пам я ­ ти всегда измеряется в степенях двойки, а пропус кная способность сети — в степенях ч исла 1 0. Размер дисков их производител и об ычно указы вают в десятичных един и цах, а размер секторов и страниц — в двоичн ых. В этой книге мы используем еди н ицы измере н и я МЭК ( I EC) дл я степеней двойки и м етрические — дл я сте п е н е й числа 1 0 . М етри ческие еди н и ц ы измере н ия м ы при­ меняем также для приблизительных значен и й и в тех случаях, когда точ ное основание сте пе ни неясно, н е зафи ксировано в документах ил и его невозможно определить. В ко­ мандах файлов конфигурации o u t p u t и i n мы оставляем исходн ые значен ия и указа­ тел и еди н и ц измере н и й . Для обозначения бита служит буква Ь, а для байта — буква В. Н е которые примеры и нтерпретации еди н и ц измерения приведе н ы в табл . 1 . 2 . —

Таблица 1 . 2 . П римеры интерпретации единиц измерения П ример

Описание возмо•иого варианта

1

Размер файла, равный 1 ООО байт

Кбайт ( kB )

4 КиБ ( КiВ)

Общий размер страниц твердотельного диска (SSD) 4 0 96 байт

8 Кбайт (КВ)

Размер памяти — не и спользуется в этой книге (см. описание ниже)

1 00

1 00 1 1

Мбайт (МВ) Номинально составляет 1 08 байт (неоднозначность, понимается по контексту)

М байт (МВ) Номинально составляет 1 08 байт, в зависимости от контекста, возможно, 99 999 744 байl»

ГиБ (GiB) Гбит/с (Gb/s)

б Тбайт (ТВ)

1 073 7 41

824 байт памяти

Скорость передачи информации в сети , равная 1 000 000 000 би т в секунду

Объем жесткого диска, равный 6 ООО ООО ООО ООО байт

• Число 1 08 округлено в меньшую сторону до ближайшего целого, кратного размеру 5 1 2-байтового сектора диска.

Буква К в аббревиатуре , как в случае «8 Кбайт ( КВ ) » , не я вляется частью стандар­ та. Это ком пьютерная адаптация метрической аббревиатуры k (обозначение приставки

Часть 1. Основы администрирования

54

кило-), которая означает 1 024 в отличие от 1 ООО. П ос кольку в аббревиатурах для м ногих м етрических приставок уже испол ьзуется прописная буква , стала возникать пута н и ца при новом и исходном использовании буквы К в качестве множителя 1 ООО. В большинстве стран эта проблема не считается важной, например в США метриче­ ские префиксы часто испол ьзуются неоднознач но. В дистрибутиве Ubuntu была п ред­ при нята попытка реал и зовать последовательную политику испол ьзован ия един и ц из­ мере н и й , но ш ирокой поддержк и , даже в самой компа н и и Canonical , она, похоже , н е получ ила (подробнее с м . w i k i . ubuntu . com / U n i t s Po l i c y).

1 .7. МАN-СТРАНИЦЫ И ДРУГАЯ ОНЛАЙН-ДОКУМЕНТАЦИЯ Традиционную онлайн-документацию образуют страницы с правочного руководства, обычно называемые тап-страницами, потому что они считываются с помощью команды man. ( Конеч но, в наши дни вся документация в той или иной форме находится в режиме онл ай н . ) Справочн ы е стран ицы поставляются вместе с новым и пакетами программного обеспечения. Даже в эпоху Google мы продолжаем рассматри вать с правочные страницы как а вторитет н ы й ресурс , потому что они доступны из командной строки и , как пра­ вило, содержат п олную и нформацию о параметрах п рогра м м ы , а также демонстр ируют полезные примеры и связанные с н и м и команды. Справоч н ы е страницы — это краткое описан ие отдел ьн ых команд, драйверов, фор­ матов файлов ил и библ иотеч н ы х процедур. О н и не затрагивают более общие тем ы , та­ кие как » Как установить н овое устройство? » или » Почему эта с истем а так м едл е н н о работает? «

Орга н иза ция mаn- стра ниц Систе м ы Free BS D и Linux разделя ют m а n -стра н и ц ы н а разделы . И х базовая схема показана в табл . 1 . 3 . Другие варианты U N IX иногда определ я ют раздел ы нескол ько иначе. Точ ная структура разделов н е важна для бол ьш инства тем , потому что человек на­ ходит соответствующую страницу там , где она хран ится . Просто учитывайте определе­ ния разделов, если тем а с тем же именем поя вляется в нескольких разделах. Например, pas swd это и команда , и конфигурацион н ы й файл , поэтому существуют соответству­ ющие записи как в разделе 1 , так и в разделе 5 . —

Таблица 1 .3 . Разделы шаn-страниц Раздел 1

Содержание

2

Пользовательские команды и приложе н ия Системные вызовы и коды ошибок ядра

3

Библиотечные вызовы

4

Драйверы устройств и сетевые протоколы

5

Стандартные форматы файлов

6

Игры и демонстрации

7

Различные файлы и документы

8

Команды администрирования систе мы

9

Спецификации ядра и интерфейсы

Глава 1 . с чего начать

55

Команда man: чтение стра ниц интера кти вного руководства Команда ma n з а г ол о в о к форматирует кон кретную стра н и цу и нтерактивного ру­ ководства и вы водит ее на терми нал пользователя с помощью утил ит mo r e , l e s s или другой програ м м ы постран ичной разбивки , которая задана в пер е м е н ной окружения PAGER. Аргумент з а гол о в о к это, как правило, и м я команды, устройства или файла, о которых необходимо получить справочную информацию . Поиск по разделам руковод­ ства осуществляется в порядке возрастан ия номеров, хотя разделы , посвященные описа­ н и ю команд ( 1 и 8), обычно просматриваются в первую очередь. —

W Информаци ю о переменных окружения см. в разделе 7 . 2 . Команда ma n р а з д е л з а гол о в о к вызывает с правоч ную страницу из указан ного раздела. Так, в большинстве систем команда man sync вызы вает сп равоч ную страницу для команды s yn c , а команда man 2 s yn c для систем ного вызова s yn c . Ком анда ma n — k клю ч е в о е_ сл о в о ил и a p r o p o s клю ч ев о е_ сл о в о выводит список справочных страниц, в строке пояснений к которым и меется указан ное кл ючевое слово. —

$ man — k translate obj c o p y ( 1 ) d c ge t t e x t ( 3 ) tr ( 1 ) snmp t r a n s l a t e ( 1 ) tr ( lp ) —

с о р у and t r a n s l a t e ob j e c t f i l e s t ra n s l a t e me s s age t rans late o r delete characte r s t r a n s l a t e SNMP OI D va l u e s i n t o mo r e u s e f u l i n f o rma t i on translate charact ers

База дан н ых кл ючевых слов может устаре вать. П р и добавл е н и и новых справоч н ы х страниц к с исте ме вам , возможно, придется перестроить этот файл с помощью команд ma kewha t i s ( Red Hat и Free BSD) ил и mandb ( Ubuntu) .

Х ранение стра ниц интера ктивного руководства Неформатирован н ая и н формация для справоч н ых стра н и ц ( входные дан н ые ко­ манды n r o f f ) обычно хран ится в подкаталогах каталога / u s r / s h a r e / ma n . В целях экономии м еста на диске систе м ы Linux сжимают страницы с помощью утилиты g z i p . Команда ma n может оче н ь быстро разархивировать их. Команда ma n поддержи вает ке ш отформатирован н ых стра н и ц в каталогах / v a r / c a c h e / ma n ил и / u s r / s h a r e /ma n , если соответствующие каталоги доступн ы дл я запи­ с и , но эти операци и рискован н ы с точки зрения безопасности. В бол ьш и нстве систем предварительное форматирован ие справоч ных стран и ц выполняется однократно во вре­ м я инсталляции (см. команду c a tma n ) или не выпол няется совсем . Команда ma n ищет страницы в ряде каталогов. В Linux-cиcтeмax выясн ить путь по­ ис ка позволяет команда ma npa t h . Результат ее работы (в системе Ubuntu) обычно таков. ubun t u $ manpath / u s r / l o c a l /man : / u s r / l oc a l / s h a re /man : / u s r / s ha r e /man

Эта установка хран ится в пере м е н ной среды МАN РАТ Н , и в случае необходимости ее можно измен ить. $ export МANPATH=/home/ share/ localman : /usr/share/man

Н екоторые с истем ы позволя ют установить общесисте м н ы й параметр пути поис ка для справочных страниц, который может оказаться полезн ы м в случае , есл и вам придет­ ся поддерживать паралл е льное дерево справоч ных страниц, например сгенерирован н ы х кроссплатформе н н ы м менеджером пакетов Open P KG . Если ж е вы хот ите рас простра-

Часть 1. Основы администрирования

56

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

1 .8. ДРУГАЯ ОФИЦИАЛЬНАЯ ДОКУМЕНТАЦИЯ С правоч н ы е стра н и ц ы — это л и ш ь малая ч асть офи ци ал ьн о й докуме нтац и и . Остальная в основном рассеяна в веб-пространстве.

Руководства по конкретн ым системам Одн и п роизводител и систем ведут собстве н н ы е онлайн- проекты по подготовке до­ кументаци и , другие выпускают полезные руководства в виде объем н ых к н и г. В насто­ я щее вре мя н ужное руководство быстрее найти в И н тернете , чем в форме печатного изда н и я . Объем и качество документации бы вают разн ы м и , но бол ьш инство произ­ водителей выпускает по м е н ьшей мере руководство по адм и н истрирова н и ю и инстал­ ляции систе м ы . Где найти документацию по каждому и з наших примеров систе м , по­ казано в табл . 1 . 4. Несмотря на полезность этой документаци и , она н е относится к тем книгам , кото­ рые ч итают перед сном (хотя отдельные поставщики п и ш ут с правоч ные руководства, которые могут усы п ить кого угодно). П режде чем обращаться к докуме нтации постав­ щиков, м ы обычно ищем ответы в системе Google. Таблица 1 .4 . Где найти документацию о т производителей операционных систем Система

UAL

DеЬiап

de Ь i a n . o r g / c om

Справочник для системного администратора, поставляемый вместе с текущей версией системы

UbuЫu

h e l p . u b u n t u . c om

Дружественная к пользователю; версии LTS описаны в разде­ ле «server guide».

RHEL

r e d h a t . c om / d o c s

Исчерпывающая документация для систе мных админист­ раторов

CeпtOS

wiki . ceЬtos . org

Советы , подсказки и ответы на часто задава е мые вопросы

FreeBSD

f r e e b s d . o r g / do c s . html

Описание

Информацию для системного администратора см. в FreeBSD

Handbook

Документация по конкретн ым па кетам Бол ьш ин ство важн е й ш и х програ м м н ых пакетов в м ире U N IX и Linux поддержива­ ют отдельные л и ца или такие сторонние организац и и , как I ntemet Systems Consortium и Apache Software Foundation . Сотрудники этих груп п п ишут собственную документа­ цию, качество которой варьируется от плохого до замечательного. При этом существуют и такие прекрасно выпол н е н н ы е документы, как Pro G it от g i t — s cm . / b o o k , которые вполне оправдывают ожидания. В число допол нительных документов входят: технические отчеты , проектные обосно­ вания и трактовки конкретных тем . Эти дополнительные материал ы зачастую н е ограни­ ч иваются простым описанием команд и могут включать самоучители и другие разделы . М ногие программ н ые пакеты , помимо справочных стран и ц , содержат и статьи п о соот­ ветствующим темам . Например, после вызова справочной страницы для редактора vim

Глава 1 . С чего начать

57

вам будет предложено не только ознакомиться с аргуме нтам и командной строки, но и пе­ рейти к разделу, из которого в ы узнаете, как в действительности отредактировать файл. Для большин ства проектов по разработке програм м ного обеспечения создаются спи­ с ки рассылки дл я пользователей и разработч иков, а также кан ал ы 1 RC дл я и нтернет­ чата. Если у вас возник вопрос о конкретной конфигурации или вы обнаружили ошиб­ ку, советуем в первую очередь обращаться туда.

Кн и ги К самы м луч ш и м источн и кам информации дл я с истемных адми нистраторов в книж­ ном м ире можно отнести серию к н и г издательства O ‘ Reill y. Начало этой сер и и было положено книгой UNIX in а Nutshell. Теперь же практически всем важны м подсистемам и командам U N IX и Linux посвящен ы ее отдельные тома. Издательство O ‘ Reilly п убли­ кует также к н и ги о сетевых п ротоколах, операционной с истем е Microsoft Wi ndows и дру­ гим темам , не связа н н ым с U N IX. Все эти книги имеют при е млемую цену, с воеврем е н ­ н ы и ориентированы н а конкретную аудиторию. М ногие читатели и здательства O ‘ Reilly используют и нтернет- магазин Safari Books Online — службу подписки , предлагающую доступ к электро н н ы м к н и гам , видео и дру­ гим учебны м материалам. Н аряду с кн и га м и издательства O’ Reilly в этом магазине мож­ но найти многочисленные к ниги других издателей.

Документы RFC Документы и з сери и R FC ( Re quest for Comments — запрос н а комм ентар и и ) о п и ­ с ы вают п ротоколы и процедуры , испол ьзуемые в И нтернете . Бол ьш и н ство и з этих до­ куме нтов достаточн о детализированы и специализи рованы , но н екоторы е написаны в в иде обзоров . И н формаци и , которую о н и содержат, впол н е можно доверять, но н е ­ которые из н и х я вл я ются всего л и ш ь обзорам и . Фраза » этал он н ая реализац и я » озна­ чает, что програм м а » разработан а надежны м источн и ком в соответствии со специфи­ кац и я м и R FC » . Авторитет R F C незыблем , а н екоторых из документов этой серии достаточно полез­ н ые для систе м н ых администраторов. Подробное описа н ие этих документов приведен о в разделе 1 3 . 1 . М ы будем часто ц итировать их в н а ш е й к ниге.

1 .9. ДРУГИЕ ИСТОЧНИКИ ИНФОРМАЦИИ Источники, рассмотрен н ые в предыдущем разделе , изучены экспертами и написаны авторитетн ы м и специалиста м и , но вряд ли это последнее слово в области управл е н и я с истемами U N IX и Linux. В И нтернете доступн ы бесчисленные блоги, дискуссионн ы е форумы и н овостные ленты. Однако, что ни говорите , но Google — луч ш и й друг систем ного адми нистратора. Если в ы и щ ите детали определен ной команды или формата файла, Googl e либо экви­ валентная поисковая система должны быть первым ресурсом, которы й вы запрашиваете для л юбого вопроса систем ного адми н истратора. Сделайте это привычкой ; так вы избе­ жите задержек и униже н и й , когда на ваши вопросы в интерактивном форуме отвечают с помощью ссылки на Google . 1 Если вы столкнулись со сложным вопросом, ищите ответ в Интернете. 1

Или, что еще хуже, указывают ссыпку на Google через сайт lmgt f y . сот.

Часть 1. Основы администрирования

58

Сох ра нение а кт уал ь ност и О перацион ные систе м ы , и нструменты и методы их поддержки быстро м е н я ются . Советуем вам ежедневно прос матривать сайты , перечисл е н н ые в табл . 1 . 5 , чтобы быть в курсе тенденций, наблюдае мых в отрасл и . Табпица 1 . 5 . Актуальные ресурсы Веб-сайт

Оnисание

d a r k re ading . c om

Новости о средствах безопасности , тенденции и обсуждение

devop s r e a c t i on s . t um Ы r . com

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

l i nux . c om

Сайт консорциума Liпux Fouпdatioп; форум полезен для новых пользователей

l i n u x f ounda t i on . o r g

Некоммерческий проект компании OSS, работодателя Линуса Торвальдса ( Uпus Torvalds)

l wn . n e t

Высококачественные, своевременные статьи о Liпux и OSS

l x e r . com

Новости о Liпux

s e c u r i t y f o c u s . c om

Отчеты об уязвимостях и списки рассылки, связанные с безопас­ ностью

@ Swi f t O n S e c u r i t y

Размышления о т имени Тейлор Свифт (Taylor Swift) о безопасно­ сти информации ( пародия )

@ nixcra f t

Твиты о системном администрировании UNIX и Liпux

eve r y t h i n g s y s a dmi n . с от

Благ Томаса Лимончелли (Tomas Limonchelli), авторитетного си­ стемного администратора•

s y s a dvent . Ы o g s p o t . с от

Благ для системных администраторов, публикующий статьи каж­ д ый декабрь

o r e i l l y . coт/ t o p i c s

Учебные ресурсы издательства O’ Reilly п о многим темам

s chne i e r . сот

Благ Брюса Шнайера ( Bruce Schneier), эксперта по криптографии и безопасности

• см. также сборник Томаса Лимон челли April Fools ‘s RFC на сайте r f c — humo r . сот

Социальные сети также полезн ы. Twitter и Reddit , в частности, имеют с ильные со­ общества с бол ьш и м количеством предложе н и й , хотя отношение сигнал — шум в этих се­ тях и ногда может быть довольно плохим . Н а сайте Reddit присоедин яйтесь к разделам основного форума s y s adm i n , l i nu x , l i nuxadmi n и n e t s e c .

П ра кти ческие руко в одства и сп равочные сайты Сайты , перечисле н н ы е в табл . 1 .6 , содержат руководства, учебники и статьи о том , как выпол нять определенные задач и в U N IX и Linux. Таблица 1 . 6 . Сnециапьные форумы и справочные сайты Веб·саiт

w i k i . a r c h l inux . o r g a s kubun t и . с от d i g i t a l o c e a n . сот

О n иоа им е

Статьи и руководства п о Arch Liпux; многие и з них носят более общий характер Вопросы и ответы для пользователей и разработчиков Ubuntu Уче б ники по многим темам OSS, разработки и системного администрирования•

Глава 1 . с чего начать

59

Окончнаие табл. 1 . 6

Веб-сайт

Описание

kernel . org

Официальный сайт ядра Liпux

s e rve r f a u l t . c om

Совместно отредактированная база данных вопросов системного адми­ нистрированияб

s е rve r s f or hac ke rs com •

Высококачественные видеоролики, форумы и статьи о системном адми­ нистрировании

‘ C м . D i g i t a l o c e a n . com / c ommun i t y / t ut o r i a l s б

Также с м . аналогичный сайт s t a c kove r f low . c om, посвященный программированию, но полезны й и ных администраторов

для систем­

Сайты Stack Overflow и Server Fault , указанные в табл . 1 . 6 (оба входят в группу сай­ тов Stack Exchange) , требуют более пристального взгляда. Если у вас возникла проблема, скорее всего, кто-то с ней уже сталкивался и попросил о помощи на одном из этих сай­ тов. Авторитетны й формат вопросов и ответов, испол ьзуе м ы й сайта м и Stack Exchange , хорошо подходит для тех п робл е м , с которы м и сталк иваются систе м н ые адми н и стра­ торы и программисты . Рекомендуем создать учетную запись и присоедин иться к этому бол ьшому сообществу.

Конференции Отраслевые конферен ц и и — отл и ч н ы й с пособ н аладить связь с другим и п рофесси ­ оналами , следить з а технологически м и тенде нциями , п роходить учебные курсы , полу­ чать сертификаты и узнавать о последних услугах и продуктах. В п оследние годы рез­ ко возросло коли чество конферен ц и й , связанных с с исте м н ы м адм и н истрированием . Некоторые из наиболее известны х конференций предстаме н ы в табл . 1 .7 . Таблица 1 . 7 . Конференции п о систем ному администрированию Конференция

Место

В рем•

Описание

LISA

Переменное

4 кв.

Управление инсталляцией крупных систем

Moпitorama

Портленд

Июнь

Инструменты и методы мониторинга

OSCON

Переменное (США/ЕС)

2 или з кв.

Долгосрочная конференция O’ Reilly OSS

SCALE

Пасадена

Я нварь

Southerп California Liпux Ехро

DefCoп

Лас- Вегас

Июль

Самый старый и самый большой съезд хакеров

Velocity

По всему миру

Переменное

Конференция O’ Reilly по веб-операциям

BSDCaп

Оттава

Май-июнь

Все о BSD для новичков и гуру

re: lпveпt

Лас-Вегас

4 кв.

АWS-конференция по облачным вычислениям в Лас-Вегасе

VMWorld

Переменное (США/ЕС)

з

LiпuxCoп

По всему миру

Переменное

RSA

Сан-Франциско

1

DevOpsDays

По всему миру

Переменное

Ряд тем для преодоления разрыва между командами разработки и групп по эксплуатации

QСоп

По всему миру

Переменное

Конференция для разработчиков программного обеспечения

или 4 кв.

Виртуализация и облачные вычисления Будущее Liпux

кв. или 2 кв. Промышленная криптография и безопасность информации

Часть 1. Основы администрирования

60

M eetups (me e t u p . c om) это е ще оди н с пособ обще н ия с едином ы шле н н и кам и . В большинстве городов С ША, как и во всем мире, есть групп ы пользователей Linux ил и DevOps, спонсирующие ораторов, дискусси и и хакерские сем инары. —

1 . 1 О. Спосо&ы поискА и УСТАновки ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Подгоrовка к работе программного обеспечения подробно рассматривается в главе 6. Но для самых нетерпеливых мы прямо :щесь расскажем о том , как выяснить, чrо уже установле­ но в вашей системе, и как получить новое программное обеспечение и инсталлировать его. В совреме н н ых операцион н ых системах програ м м ное обес печение разделено на па­ кеты , которые можно инсталлировать независимо друг от друга. П р и стандартной уста­ новке с исте м ы используется группа «стартовых» пакетов, которую можно при н еобхо­ димости расш ирить. Добавоч н ые п рограм м н ые продукты зачастую предоставляются также в виде пред­ варительно ском п илирова н н ых пакетов, но дале ко не во всех с истемах. Большая часть программного обеспечения создается независи м ы м и группами разработчи ков, выпуска­ ющим и программ ы в виде исходных кодов. Репозитории пакетов затем берут исходн ые коды , комп ил ируют их в соответствии с особенностя м и кон кретной систе м ы и вкл ю ­ чают в пакеты получ е н н ые би нарные файл ы . Как правило, нам ного проще инсталл и­ ровать бинарную верси ю пакета, п редназнач е н н ую для дан ной систе м ы , чем искать и компилировать исходн ы й код. Одн ако нужно учитывать, что и ногда создател и п акетов на оди н-два выпус ка отстают от текущей верси и систе м ы . Если в двух системах используется один и тот же формат обработки пакетов, 10 это еще не означает, чrо пакеты обеих систем будут взаи мозаменяемыми. Например, в системах Red Hat и S US E применяется формат RPM , однако структура их файловых систем неодинакова. Рекомендуется всегда пользоваться пакетами, со:щанными для конкретной системы. В рассматриваемых нами дистрибутивах предусмотрен ы отлажен н ые систем ы управ­ л е н и я пакета м и , которы е вкл ючают средства доступа к репозитори я м п ро гра м м н ы х продуктов и поиска их в И нтернете . Дистрибьюторы активно поддерживают эти репо­ зитори и от и м е н и сообщества , которое они представляют, чтобы облегч ить процесс ис­ правления и обновления систе м . Другим и словами , жизнь прекрасна! Адми нистраторы без доступа к предварительно скомпонован н ы м бинарным версиям пакеrов должны инсталлировать системы по-старому, т.е. загружать архив исходного кода tar, а затем вручную конфигурировать, компилировать и инсталлировать систему. Иногда этот процесс проходит гладко, а иногда может превратиться в кош мар: все зависит от ис­ пользуемого программ ного обеспечен ия и конкретной операцион ной системы . В этой книге м ы п редполагаем , что дополн ительное программ ное обеспечение уже установлено, и не собирае мся м уч ить вас ш аблон н ы м и и нструкци я м и по и нсталля ­ ц и и каждого пакета. П р и необходимости м ы будем указывать точ ные названия пакетов для выполнения кон кретного проекта. Однако большей частью мы не будем повторять инструкции по и нсталляции, поскольку они практически идентичны для всех пакетов.

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

Глава 1 . С чего начать

61

ответствующий бинар н ы й файл в ваш е м пути поиска. Например, следующая команда показывает, что компилятор G N U С уже установлен на этом комп ьютере: ubu n t u $ which gcc / u s r /Ь i n / gc c

Если в ы не можете найти нужную команду, попробуйте выпол н ить команду whereis; она и щет более ш ирокий набор систе м н ых каталогов и н е зависит от п ути поиска вашей оболочки. Другой ал ьтернативой я вл яется н евероятно полезная команда l o c a t e , которая справляется с предварител ьно скомп ил ирова н н ы м и ндексом файловой систе м ы , чтобы найти и м е на файлов , которые соответствуют определ е н ному шаблону. Система Free B S D реализует ком анду l ocate как часть базовой систе м ы . В с истем е Linux текущая реал и зация команды locate н аходится в пакете mlocate. В с истемах Red Hat и CentOS установите пакет mlocate с помощью ком анды yum; см. раздел 6.4. Ком а нда locate может найти л юбой тип файла, но это н е относится к командам ил и п а кета м . Напр и м е р , есл и в ы н е были увере н ы , где н айти подключае м ы й файл signal . h , вы м ожете попробовать выпол нить следующую команду. f r e e b s d $ locate s ignal . h /u s r / i n c l ude /mac h i n e / s i gn a l . h / u s r / i n c l ude / s i gn a l . h / u s r / i n c l u de / s y s / s i gn a l . h

База да н н ы х команды locate периодически обновляется командой updatedЬ ( в систем t Fre e B S D — командой locate . updatedЬ ) , которая запускается из программы cron. Поэтому результаты поиска не всегда отражают недавние изменения файловой си­ стемы. Зная имя пакета, которы й ищете, вы также можете испол ьзовать утилиты для упаков­ ки систе м ы , чтобы н апрям ую проверить наличие пакета. Например, в с истеме Red H at следующая команда проверяет наличие (и установленную версию) и нтерпретатора Python: r e dha t $ rpm -q python p y t h o n — 2 . 7 . 5 — 1 8 . e l 7 _1 . l . x 8 6_ 6 4

W Дополнительную и нформаци ю о б управле нии пакетами см. в главе

6.

Вы также можете узнать, к какому пакету принадлежит определен н ы й файл : redha t $ rpm -qf /etc/httpd HTT P D — 2 . 4 . 6 — 3 1 . e l 7 . c e n t o s . x 8 6 6 4 f r e e b s d $ pkg which /usr/ local / sbin/httpd / u s r / l o c a l / s Ь i n / h t tpd w a s i n s t a l l e d Ьу p a c k a g e a p a c he 2 4 — 2 . 4 . 1 2 ubun t u $ dpkg-query -S /etc/apache2 apach e 2 : / e t c / ap a c h e 2

Доб а вление нового п рограммного обеспечения Если в а м необходимо установить допол нительное программное обеспечен и е , сначала следует определить каноническое имя соответствующего пакета программ ного обеспе­ чения. Например, вам нужно будет перевести фразу Я хочу установить locate » в » Мне нужно установить п акет ml ocate » или перевести » М н е н ужен с правоч н и к named» в » М не нужно установить B I N D » . В этом м ожет помочь цел ы й ряд с исте м н ых и ндек»

Часть 1. Основы администрирования

62

сов в И нтерн ете , но Google , как правило, так же эффективен . Например, поиск » locate command» приводит вас непосредственно к нескольким соответствующим обсуждениям. В следующих примерах показана инсталл я ция команды tcpdwap для каждой и з наших иллюстративных систем. Команда tcpdump это и нструмент для захвата пакетов, позво­ ляющий просматривать исходные пакеты, отправляемые в систему и из системы в сети. —

В с истемах Deblan и Ubuntu и с пол ьзуется програм м а АРТ Advanced Package Tool.

Deblan

ubun t u # sudo apt-qet install tcpdump Re ading pac kage l i s t s . . . Done Building dependency t r e e Re ading s t a t e i n f o rmat i o n . . . Done The f o l l owing NEW p a c kages wi l l Ье i n s t a l led : tcpdump О upgraded, 1 newl y i n s t a l l e d , О to remove and 8 1 not upgraded . Need to g e t О В / 3 6 0 kB o f archive s . A f t e r t h i s ope r a t i o n , 1 , 1 7 9 kB o f add i t i onal di s k space w i l l Ье u s e d . S e l e c t ing previous l y uns e l ected package tcpdump . ( Reading databa s e . . . 6 3 8 4 6 f i l e s and d i r e c t o ri e s cu r re n t l y i n s t a l l e d . ) Preparing t o unpack . . . / tcpdump_4 . 6 . 2 — 4 ubuntul_amd 6 4 . deb Unpacking tcpdump ( 4 . 6 . 2 — 4 ubuntu l ) . . . Proce s s ing t r i gg e r s for man-db ( 2 . 7 . 0 . 2 — 5 ) S e t t i ng u p t cpdump ( 4 . 6 . 2 — 4 uЬunt u l ) . . .

RHEL

В с истемах Red Hat и CentOS аналогичная версия выглядит следующ и м образом. r e dha t # sudo yum install tcpdump Loaded p l u g i n s : f a s t e s tmi r r o r De t e rmi n i n g f a s t e s t mi r r o r s * b a s e : mi r r o r s . xmi s s i o n . com * e p e l : l i nu x . mi r r o r s . e s . ne t * e x t r a s : c e n t o s . a r v i x e . c om * updat e s : r e p o s . l a x . qu a d r a n e t . com Re s ol v i n g Dependenci e s — — > Runn i n g t ra n s a c t i on che c k — — — > P a c kage t c pdump . x 8 6_ 6 4 1 4 : 4 . 5 . 1 — 2 . е 1 7 wi l l Ь е i n s t a l l e d — — > F i n i s h e d Dependency Re s o l u t i on t cp dump — 4 . 5 . 1 — 2 . e l 7 . x 8 6_ 6 4 . rpm 1 3 8 7 kB 0 0 : 0 0 Run n i n g t r a n s a c t i o n c he c k Run n i n g t ra n s a c t i o n t e s t T r a n s a c t i o n t e s t s uc c e e d e d Run n i n g t r a n s a c t i on I n s t a l l i n g : 1 4 : t c pdump — 4 . 5 . l — 2 . e l 7 . x 8 6_ 6 4 1 / 1 Ve r i f y i n g : 1 4 : t cpdump — 4 . 5 . 1 — 2 . e l 7 . x 8 6_ 6 4 1 / 1 Installed : t c pdump . x 8 6_ 6 4 1 4 : 4 . 5 . 1 — 2 . е 1 7 Comp l e t e !

Менеджер пакетов в системе Free B S D называется pkg. f re e b s d # sudo pkq install -у tcpdump Upda t i n g F r e e B S D repos i t o r y catal ogue . . . Fetching me t a . tx z : 100% 944 В

0 . 9kB/s

00 : 01

Глава 1 . С чего начать

63

Fetching package s i t e . tx z : 100% 5 MiB 5 . 5 MB / s 00 : 01 Proce s s ing e n t r i e s : 1 0 0 % F r e e B S D repo s i t o r y upda t e comp l e t e d . 2 4 6 3 2 packages p r o ce s s e d . Al l repo s i t o r i e s a r e up — t o -da t e . The f o l l owing 2 pac kage ( s ) w i l l Ье a f f e c t e d ( o f О checked ) : New package s to Ье I N S TALL E D : tcpdump : 4 . 7 . 4 l i b smi : 0 . 4 . 8 1 The proce s s wi l l r e qui r e 1 7 M i B mo re space . 2 M i B to Ье downl oaded . Fetching t cpdump — 4 . 7 . 4 . tx z : 100% 3 0 1 KiB Fetching l i b smi — 0 . 4 . 8_ 1 . tx z : 100% 2 MiB Checking i n t e g r i t y . . . done ( 0 con f l i ct i n g ) ( 1 / 2 ] I n s t a l l ing l ibsmi — 0 . 4 . 8_ 1 . . . ( 1 / 2 ] E x t r a c t i n g l ibsmi — 0 . 4 . 8_ 1 : 1 0 0 % [ 2 / 2 ] I n s t a l l ing t cpdump — 4 . 7 . 4 . . . [ 2 / 2 ] E x t r a c t i n g tcpdump- 4 . 7 . 4 : 1 0 0 %

3 0 7 . 7 kB / s 2 . 0MB / s

00 : 01 00 : 01

Созда ние п рограммного обеспечения из и с ходного к од а В качестве иллюстраци и рассмотрим процесс создан ия версии tcpdump из исходного кода. Первая задача — найти сам код. Сторонн и ки програм м ного обеспе ч ения иногда хра­ нят индекс выпусков на веб-сайте проекта, которые можно загрузить в виде архивов. Для проектов с открытым исходным кодом вы, скорее всего, найдете код в репозитори и Git. Источн и к tcpdum.p хранится в репозитори и GitHub. Выпол н ите клонирование ре­ позитори я в каталоге / tmp, создайте ветку с тега м и , котору ю в ы хотите создать, затем распакуйте , настройте , создайте и установите : redh a t $ cd / tmp redha t $ qi t clone https : / /qi thuЬ . com/ the — tcpdump-qroup/ tcpdump . qit < s t a t u s me s s a g e s a s r e po s i t o r y i s c l on e d > redha t $ cd tcpdump redha t $ qi t checkout taqs/ tcpdump- 4 . 7 . 4 -Ь tcpdump- 4 . 7 . 4 Swi t c h e d t o а new b r anch ‘ t cp dump — 4 . 7 . 4 ‘ redh a t $ . / confiqure che c k i n g b u i l d s y s t em t yp e . . . x 8 6_6 4 — un known — l i n ux — gn u che c k i n g h o s t s y s t em t yp e . . . x 8 6_ 6 4 — u n known — l i n u x — gnu che c k i n g for gcc . . . g c c che c k i ng wh e t h e r t h e С c omp i l e r wo r k s . . . ye s redha t $ make < s eve r a l p a g e s o f comp i l a t i on outpu t > redh a t $ sudo make ins tal l < f i l e s a r e moved i n t o p l a c e >

Эта последовательность configure /m.ake /m.ake устанавли вается для бол ьш инства програм м , написанн ых на языке С, и работает во всех системах U N IX и Linux. Всегда полезно проверить файл INSTALL или READМE пакета для уто ч нения. Должна быть уста­ новлена среда разработки и любые необходимые для пакета требования. ( В случае паке­ та tcpdump необходимой предпосылкой я вл яется уста н овк а библ иотеки l ibpcap и со­ путствующих библиотек.)

Часть 1. Основы администрирования

64

Зачастую воз н икает необходимость настроить конфигурацию сборк и , поэтому ис­ пользуйте команду / configure — -help, чтобы просмотреть параметр ы , доступные дл я каждого конкретного пакета. Други м полез н ы м параметром команды configure является -prefix directory, которы й позволяет с комп илировать программ ное обе­ спечение дл я установки где-то, кроме /usr/ local , которое обычно я вляется значением по умолчан ию. .

=

Установ к а с по м ощью веб- сценария Кросс- платформ е н н ые пакеты програм м ного обеспечен ия все чаще предлага ют ускоре н н ы й процесс установки , которы й управляется сце нарием оболочки , загружае­ мым из И нтернета с помощью команд curl , fetch или wget.2 Например, чтобы настро­ ить маш ину как клиент Salt , вы можете выпол н ить следующие команды: $ curl о / tшp/ s al tЬoot -sL https : / /bootstrap . saltstack . com $ sudo sh / tшp/ saltЬoot —

Сценарий boo t s t rap исследует локал ьную среду, затем загружает, и нсталл и рует и настраивает соответствующую версию программного обеспечен и я . Этот тип и нстал ­ ляции особенно распространен в тех случаях , когда сам процесс сложен , но поставщик оче н ь мотивирован , чтобы облегчить пол ьзователя м работу. ( Еще оди н хороший при ­ мер RVM , с м . ра�ел 7 . 7 . ) —

III Дальнейшую информаци ю о б инсталляции пакетов см . в главе 6 . Этот метод установки отл ич но работает, но о н подни мает нескол ько п робл е м , ко­ торы е стоит упомя нуть. Во-первых, о н н е оставляет должной запи с и об и нсталля­ ц и и для будущих ссылок. Есл и ваша операцион н ая с исте ма предлагает пакетную верси ю п рограм много обеспече н и я , обыч н о луч ш е установить пакет вместо запус ка веб — и нсталлятора. П акеты легко отслеживаются , обновляются и удал я ются . (С другой сторо н ы , бол ьш инство пакетов на уровне операцион ных систем устарели . Вероятно, вы не получ ите самую последнюю верси ю програм много обес печения.) III Более подробную информацию о цепочке доверия НТТРS см. в разделе 27. 6 . Будьте оче н ь подозрител ьны м и , если U RL-aдpec загрузочного сценария небезопасен (т.е. он н е начинается с префикса https : ) . Незащищенный НТГР я вляется легкоуязви­ мым дл я захвата, а U RL-aдpeca и нсталляции представляют особый и нтерес для хакеров, потому что они знают, что вы, с корее всего , будете работать в качестве привилегиро­ ванного пользователя , независимо от того, какой код возвращается. В отличие от этого, протокол НТГРS проверяет подл и нность сервера с помощью криптографической це­ почки доверия . Это н е вполне, но достаточно надежны й способ. Некоторые продавцы публикуют U RL-aдpec и нсталл я ции по протоколу НТТР. кото­ рый автоматически перенаправляет пользователя на НТГРS-версию. Это глупо и на самом деле не более безопасно, чем прямой адрес НlТР. Н и что не мешает перехвату исходного НlТР-обмена, поэтому вы, возможно, никогда не достигнете перенаправления поставщика. Однако наличие таких переадресаций означает, что стоит попробовать собственную замену https для http в небезопасных U RL-aдpecax. Чаще всего это работает отлично. Оболоч ка принимает текст сценария как свой стандартн ы й вход, и эта функция по­ зволяет испол ьзовать процедуры инсталляции в режиме онлайн , например: $ curl -L https : / /badvendor . com 1 sudo sh

2Эrо все простые НТТР-клиенты, загружающие содержим ое U RL-aдpeca в локал ьн ы й файл или (необязательно) распечатывающие содержимое в виде результата своей работы.

Глава 1 . С чего начать

65

Тем н е менее существует потенциал ьная проблема, связанная с этой конструкци­ ей, — корневая оболочка все е ще работает, даже есл и команда cur l выводит частич ­ н ы й сценар и й , а затем терп ит неудачу — с каже м , из-за кратковре м е н ного сбоя сети. Конечный результат непредсказуем и потен циально не очен ь хорош. Нам неизвестны какие-либо докуме нтированные случаи проблем , связан н ых с этой причиной. Тем не менее это правдоподобн ы й режим отказа. Более того, направление результатов работы команды curl в оболочку в среде с исте м н ы х адми н истраторов рас­ сматри вается как тип и ч н ы й промах новичков, поэтому, есл и вы это сделаете , н и кому об этом не говорите. Исправить ситуаци ю легко: просто сохраните сценарий во времен ном файле, а затем запустите сценарий на отдел ьном этапе после успеш ного завершения загрузки.

1 . 1 1 . ГДЕ РАЗМЕСТИТЬ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Операцион н ы е систе м ы и програм м ное обеспечение могут размещаться в частных центрах обработки данн ых, на объектах совместного размещения, на облачной платфор­ ме ил и в некоторой их комбинации . Наиболее быстро растущие начи нающие компани и выбирают облако. У сол идных предприятий, вероятно, есть центры обработки данных, поэтому они могут организовать частное облако внутри организации. Самы й практичный выбор и наша рекомендация для новых прое ктов — это публич­ н ые облачные провайдеры. О н и предоставляют множество преимуществ по сравнен и ю с центра м и обработки дан н ых. •

Отсутствие капитальных затрат и н изкие начальн ые эксплуатационн ые расходы.

Отсутствие необходимости устанавливать, защи щать и управлять оборудование м .

Ре гул и ровка е м кост и , пропускной способности и выч исл ител ьной мощности по требованию. Готовые решения для общих вспомогательных потребностей , таких как базы дан ­ н ы х , балансировки нагрузки, очереди , мониторинг и т.д. Более дешевая и простая реализация высокодоступных или избыточ ных с исте м .

Ранн и е облачные с исте м ы и м ел и репутацию слабо защище н н ых и н изкопроизводи­ тельных, но это уже не я вляется серьезной проблемой. В наши дни большая часть адм и ­ н истративной работы выпол няется в облаке (см. главу 9 для общего введения в тему) . Наша предпочтител ьная облачная платформа я вляется л идером в своей области : Amazon Web Seivices (AWS). Gartner, ведущая исследовательская фирма п о технологиям , обнаружила, что AWS в десять раз превосходит всех кон курентов. AWS быстро внедряет и н новации и п редлагает гораздо более ш ирокий спектр услуг, чем л юбой другой постав­ щик. Она также имеет отличную репутацию по обслуживани ю клие нтов и поддерживает большое сообщество. На первых порах AWS предлагает бесплатный уровен ь обслужива­ н и я , включая использование в течение года маломощного облачного сервера. Облач ная платформ а Google ( G C P) активно соверше нствует и продает свои про­ дукты. Н екоторые утверждают, что эта технология не и меет себе равных по сравне н и ю с другим и поставщикам и. Рост G C P был медлен н ы м , отчасти благодаря репутаци и ком ­ пан и и Google, отказавшейся поддерживать несколько популярных служб. Те м не менее е го удобн ы е дл я клие нта условия ценообразован ия и у н и кал ьные фун кции я вляются привлекательн ы м и характеристиками . DigitaOcean — это более простая служба, целью которой я вляется высокая произ­ водительность. Она ориентирована на разработч иков, которы м DigitaOcean предла-

Часть 1. Основы администрирования

66

гает я с н ы й и нтерфейс прикладного программ и рован и я , н изкую цену и чрезвычайно быструю загрузку. Разработчики DigitalOcean — ярые сторо н н и ки программного обеспе­ чения с открытым исходным кодом , а их учебники и руководства по популярны м и нтер­ нет-технологиям я вляются одни м и из луч ш их.

1 . 1 2. СПЕЦИАЛИЗАЦИЯ И СМЕЖНЫЕ ДИСЦИПЛИНЫ Систе м н ые адм и н истраторы работают н е в вакууме ; создавать и поддержи вать слож­ ную сеть должна команда экспертов. В этом разделе описываются некоторые рол и , ко­ торые системные адми нистраторы могут выполнять в соответствии со с воим и навыками и возможностям и . Н е которы е адми н истраторы предпоч итают специализироваться в од­ ной ил и нескол ьких из этих областей . В а ш а цел ь к а к систе м ного адми н истратора или к а к п рофессионала, работающего в любой из этих смежных областей , — достижение целей организации. Не позволя йте пол итике или иерархии мешать прогрессу. Луч ш ие адм и н истраторы решают п роблем ы и с вободно обме н и ва ются и нформацией с другим и .

М етодология DevOps Ш Дополнительную информаци ю о методологии

DevOps см. в главе 3 1 .

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

И нженеры по надежности сайтов И н женеры по надежности сайтов ставят н а первое место время безотказной и пра­ вильной работы. Мониторинг сети , разверты вание программ ного обеспечения на про­ изводстве , координация работ, план ировани е будуще го расширения и аварий н ы е от­ кл ючен и я — все это лежит в основе эти х крестоносцев доступност и . Головной бол ью инженеров по надежности сайта я вляется единствен ная точка отказа.

И нженеры по безопасности Инженеры по безопасности сосредоrочены на практической, повседневной стороне ин­ формационной безопасности. Эrи люди устанавливают и используют инструменты дЛЯ по­ иска уязвимых мест и мониторинга дЛЯ предотвращения сетевых атак. Они также участвуют в имитации атак, чтобы оценить эффективность методов их профилактики и обнаружения.

Сетевые администраторы Сетевые адм ин истраторы проектируют, устанавл ивают, настраивают и управляют се­ Организаци и , в которых фун кционируют центры обработки дан н ых, скорее всего, будут использовать сетевых адм и нистраторов; это объясняется тем , что такие объе кты

п1 м �1 .

Глава 1 . С чего начать

67

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

Адм и н и стратор ы б аз д а н н ы х Адм и н истраторы баз дан ных являются экс пертам и по установке и управлению про­ грам мным обеспечением баз дан н ых. Они управляют схемами базы дан н ых, выполняют установки и обновления , настраивают кластеризацию, выбирают параметры для оптимал ь­ ной производительности и помогают пользователям формулировать эффе ктивные запросы. Адм ин истраторы баз данных обычно владеют одним или н ескольким и языкам и запросов и имеют опыт работы с реляцион ными и нереляционными (NoSQL) базами данн ых.

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

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

А рх ите ктор ы Систе м н ые архите ктор ы обладают глубокими знани я м и в более ч е м одной обла­ сти. О н и испол ьзуют свой опыт для разработки распределен н ых систе м . Их должност­ ные инструкции могут предусматривать определ е н ие зон безопас ности и сегме нтацию, устранен ие отдельных точе к отказа, план ирование будущего роста, обеспечение взаи мо­ действия между несколькими сетя м и и третьи ми сторонам и , а также принятие реш е н и й , касающихся всей организации. Хорошие архитекторы технически ком п етентн ы и обыч­ но п редпоч итают внедрять и тестировать свои собствен н ы е прое кты .

1 . 1 3 . Л ИТЕРАТУРА •

А ввотт, МлRП N L. , AN D М 1 с н л н Т. F 1 s H E R . The Art of Scalabllity: Sса!аЬ/е Web Architecture, Processes, and Organizations for the Modern Enterprise (2nd Edition) . Addison-Wesley Professional, 20 1 5 .

GлNcлRZ, М 1 кЕ . Linux and the Unix Philosophy. Boston: D igital Press, 2003.

L1моNСЕШ , Тномлs А. , AN D РЕТЕR Sлшs. The Comp/ete April Fools ‘ Day RFCs.

Часть 1. Основы администрирования

68 •

Peer-to- Peer Communications LLC. 2007. Юмор инженеров. Эту коллекцию истори й можно свободно прочитать на сайте r f c — humo r . c om.

RAvмoND, E R J c S. The Cathedral & The Bazaar: Musings оп Linux and Ореп Source Ьу ап Accidental Revolutionary. Sebastopol , СА: O ‘ Reilly Media, 200 1 .

SAшs, РЕТЕR Н . The Daemon , the G N U & the Pengui n : How Free and Ореп Software is Changing the World. Reed Media Services, 2008. Это увлекательная история борьбы за открытый исходный код, написанная самым известны м историком U N IX , так­ же доступна на сайте g ro k l a w . com под л ицензией Cгeative Commons. Адрес U RL для самой книги довольно дл и н н ы й ; н айдите текущую ссылку на сайте g r o k l aw . com или попробуйте этот сжатый эквивалент: t i n yu r l . com/ d бu 7 j ) .

S I EVER, ELLE N , STEPH E N FюG J N S , RoвERT LovE , AN D ARNOLD Roвв1Ns. Linux in а Nutshell (бth Edition). Sebastopol, СА: O ‘ Reily Media, 2009.

Систе мное а дмин истрирова ние и методол огия DevOps S PA FF O R D . The Phoenix Project: А Novel about Win. Portland, OR: 1Т Revolution Pгess, 20 1 4. создания современ ной IТ-организаци и , на­ Н епреходящая классика.

К 1 м , G EN E , KEVI N B E H R , AND G F.ORG E /Т, DevOps, and Helping Your Business Введение в философию и принципы писанная в повествовательном стиле.

К1 м , G E N E , J EZ Н u м вL Е , PATRICK D E вo 1 s , A N D J o н N W1 LL1s. The DevOps Handbook: Ноw to Create World-Class Agility, Reliabllity, and Security iп Technology Organizations. Portland, OR: 1Т Revolution Press, 20 1 6.

L1 мoNCELLI , ТномАs А. , CHRISТ I NA J . H oGAN , AND S т RATA R . СнАШР. The Practice о/ System and Network Administration (2nd Edition). Reading, МА: Addison-Wesley, 2008 . Это хорошая книга, в которой очен ь подробно описа н ы организационн ы е и про­ цедурн ы е аспекты системного адми н истрирования Авторы ведут блог, пос вя ще н ­ н ы й системному адми нистрированию: eve r yt h i n g s y s a dmi n . c om.

L1 м oNCELL I , ТномАs А. , C н R I SТI NA J. HoGAN , AND S тRАтА R . СнАШ Р. The Practice о/ Cloud System Administration. Reading, МА: Addison-Wesley, 20 1 4. Книга предыдущих авторов, посвящен ная распределе н н ы м систе мам и облачн ы м вычислениям.

Ва жн ые инструменты B R ESNAHAN .

B L u м , R 1cнAR D, AND Снюsп N Е ВiЫе (Зrd Edition). Wiley, 20 1 5 .

Dou a н E RТY, DALE, AND ARNOLD Roв 1 N s . Sed & A wk (2nd Edition) . Sebastopol , СА: O’ Reilly M edia, 1 997. Классическая книга издательства O ‘ Reilly о мощных и ш и ­ роко распространенных текстовых процессорах sed и awk.

Кl м , РЕТЕR. The H acker Playbook 2: Practical Guide То Penetration Testing. CreateSpace l ndependent PuЫ ishing Platform , 20 1 5 .

N ш., D REW. Practical Vim: Edit Text at the Speed о/ Тhought. Pragmatic Вookshelf, 20 1 2.

S 1ютrs , WILLIAM Е. The Linux Command Line: А Complete lntroduction. San Francisco, СА: No Starch Press , 20 1 2 .

S w E I G ART А1 . Automate the Boring Stuff with Python: Practica/ Programming for Total Beginners. San Francisco, СА: No Starch Pгess, 20 1 5. ,

.

Linux Command Line and She/l Scripting

Глава

2

Загрузка и системные д е м оны

» Загрузка» (booti ng) — это стандартн ы й терми н , означающий запус к компьютера. Он представляет собой сокращенную форму слова «самозагрузка» (bootstrapping) , которое подразум евает, что ком пьютер должен » привести себя в рабочее состоян и е с помощью собствен н ых программ начальной загрузки (bootstraps) » . Процесс загрузки состоит из н ескольких задач , определенных в ш и роком смысле. •

Поиск, ввод в память и запуск кода начальной загрузки.

Поиск, ввод в память и запус к ядра операционной систем ы .

Активирование сценариев запуска и системных демонов.

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

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

2 . 1 . ОБЗОР ПРОЦЕССА ЗАГРУЗКИ П роцедуры запуска в последн ие годы с ил ьно измен ились. Появление современ н ых B I O S с поддержкой U E F I ( U nified Ext ensiЫe Firmware l nterface — унифицированн ый и нтерфейс рас ш иряемой прош и в ки ) упростило ран н и е этапы загрузки , по край н е й м е р е с кон цептуальной точк и зрения. На более поздн их этапах больш инство дистрибу-

Часть 1. Основы администрирования

70

тивов Linux теперь испол ьзуют демон систе м ного менеджера под название м sys temd вм есто тради цион ного де мона U N IX init. Пом и мо всего прочего, менеджер systemd упрощает процесс загрузки путе м добавления управл е н и я зависимостя м и , поддержки одноврем е н н ы х процессов запуска и ком плексного подхода к протокол и рованию. Управл е н и е загрузкой также изме нялос ь по м ере того, как с исте м ы м и грировал и в облако. Дрейф в сторон у виртуал изации, облач ных экзем пляров и контейнеризации уме н ьш ил потребность в том , чтобы адм и нистраторы касались физического оборудова­ ния. Вместо этого у нас теперь есть управление изображе н и я м и , интерфе йсы A P I и па­ нел и управления. Во врем я н ачал ьной загрузки ядро загружается в память и нач и н ает выполн яться. П р и этом выпол н яется множество задач и н и циал изации , и затем с истема становится доступной для пол ьзователей. Общий обзор этого процесса показан на рис. 2 . 1 .

Загрузить ядро

Создать структуры данных ядра

Загрузить BIOS/UEFI из NVRAM

Определить, какое ядро загрузить

Запустить init/ systemd как PID 1

Собрать сведения об аппаратуре

Загрузить загрузчик (например, GRUB)

Выполнить сценарии запуска

Выбрать устройство для запуска (диск, сеть, …)

Идентифицировать системный раздел EFI

Запустить систему

Включить

Рис. 2. 1. Процессы загрузки Unux и Unix

Адм и н истратор ы не и м е ют средств дл я прямого интеракти вного управления боль­ шинством действий, необходи мых для загрузки систе м ы . Вместо этого адм инистраторы могут изменять конфигурации загрузч иков, редактируя файлы конфи гурации для сцена­ риев запуска системы или изменяя аргументы , которые загрузч ик передает ядру. Прежде ч е м система будет пол ностью загруже на, должны быть проверен ы и смон­ тирова н ы файловые систе м ы и запуще н ы систе м н ые де мон ы . Эти м и п роцедура м и управляет набор сценариев оболоч ки ( и ногда называе м ы х » с це нария м и ini t » ) л ибо файл ы , которые запус каются последовател ьно с помощью де мона i n i t ил и анал и ­ зируются м е н еджером sys temd. Точная ком поновка сценариев запус ка и способ и х выпол н е н и я зависит от операционной систе м ы . Подробн ости изложе н ы в этой главе ниже.

2.2. СИСТЕМНЫЕ ПРОШИВКИ При вкл юче н и и ком п ьютера процессор вы пол н яет загрузоч н ы й код, хранящи йся в постоян ном запоминающем устройстве . В виртуал ьных системах это постоян ное запо­ м и нающее устройство может быть виртуал ьн ы м , но концепция остается прежней.

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

71

Пр ош и вка с исте м ы , как правило, знает обо всех устрой ствах , которы е подкл ю­ чен ы к м атеринской плате , таких как контроллеры SATA, сетевые интерфейсы , U S В­ контроллеры и датч ики для п итания и тем пературы 1 • Поми мо возможности аппаратной настройки эти х устройств, прошивка позволяет вам либо сообщить о н и х операционной системе, либо отключить и скрыть их. На физическом ( в отл и чи е от в иртуального) оборудован и и бол ь ш и н ство прош и ­ вок п редлагает пол ьзовател ьски й и н терфейс. Те м н е менее оно, как правило, сл и ш ­ ком п ростое и неудобное. Для работы с н и м н еобходимо и м еть доступ к ком пьютеру и консол и , а также сразу же нажать на конкретную клавишу после включен и я систе м ы . Ксожалению, «золотой ключик» у каждого производителя свой; проверьте , сможете ли вы разобраться в загадочной строке инструкций в тот момент, когда с истема включ ится впервые2• Если не с можете , попробуйте клави ш и < Delet e > , < Ctrl > , < F6 > , < F8 > , < F l O > или < F l 1 > . Для увеличения ш ансов на успех косн итесь кл ав и ш и несколько раз, зате м удерживайте ее нажатой. Во врем я обычной начальной загрузки система прошивки проверяет аппаратное обе­ спечение и диски, запускает простой набор проверок работоспособн ости , а затем ищет следующ и й этап кода начал ьной загрузки. Пользовательский интерфейс прошивки по­ зволяет н азначить загрузоч ное устройство, как правило, путем определения приоритетов списка доступных параметров (например, » попробуйте загрузить с DVD-привода, затем с U S В -диска, а затем с жесткого диска » ) . В большинстве случаев системные диски входят в список вторичн ых приоритетов. Для загрузки с определенного диска необходимо смонтировать его как диск с самы м высоким приоритетом и убедиться, что в качестве загрузочного носителя включен » жесткий диск» .

BIOS ил и U E F I В прошлом обычная про ш ивка для персонального ком пьютера назы валась B I O S ( Basic l nput/Output System) . Однако з а последнее десятилетие тер м и н B I O S был вытес­ нен более формал изова н н ы м и современ н ы м стандартом — U E F I . Часто можно встре­ тить тер м и н » U EF I B I O S » , но для ясности в этой главе мы зарезервируем термин B IOS дл я устаревшего стандарта. Бол ьш инство систе м , реализующих U E F I , могут вернуться к устаревшей реализации B IOS, если операционная с истема, которую они загружают, н е поддерживает U E F I . U E F I — это текущая верси я предыдущего стандарта E F I . Ссьmк и на и м я E F I сохра­ няются в некоторых старых докуме нтах и даже в н е которых стандартн ы х терминах, та­ ких как «систе м н ы й раздел E F I » . Во всех, кроме самых очевидных ситуаци й , эти терми­ н ы можно рассм атривать как эквивалентные. В наши дни поддержка UEFI довольно тип ич н а для новых персональных комп ью­ теров, но в м ире существует очен ь м ного с истем BIOS. Более того, в иртуал ьн ы е среды часто используют B I O S в качестве основного механизма загрузки, поэтому м и р B I O S е щ е не находится под угрозой исчезновения. Поскольку м ы предпочли бы и гнорировать BIOS и говорить только об UEFI, вполне вероятно, что вы столкнетесь с обоими типами систем еще в течен и е довольно долгого вре м е н и . U E F I также и нтегрирует в себя н екоторые функции B I O S , поэтому рабоч ие знания BIOS могут быть весьма полезн ы для расшифровки документаци и U E F I .

1 Виртуальные системы и митируют, что имеют такой ж е набор устройств. 2 Возможно, вам будет полезно временно отключить функции управления п итанием монитора.

Часть 1. Основы администрирования

72

Уста ревший интерфейс BIOS Традицион н ы й B IOS предполагает, что загрузочное устройство начинается с записи (сектора) , называемой M B R (Master Boot Record). MBR содержит первич ный загрузчи к ( » bootЬock») и простую табли цу разделов диска. Объем свободного места для загрузчи ­ к а настол ько мал ( менее 5 1 2 байт) , что он не может вы пол н ять ничего, кроме загрузки и запуска вторичного загрузчика. Из-за ограниченности размера ни загрузочный сектор, ни B I O S не могут обрабаты ­ вать записи любой стандартной файловой системы, поэтому вторичный загрузчик должен храниться там , где е го легко найти. В одном типичном сценарии загрузочн ы й сектор счи­ тывает информацию о разбиении диска из M B R и идентифицирует раздел диска, поме­ ченный как «активны й » . Затем он считывает и выполняет вторичный загрузчик с самого начала этого раздела. Эта схема называется загрузочной записью тома (volume Ьооt record). 11) Разб и е н и е диска

ЭТО способ разделе н и я физич еского диска. Детал и

СМ. В

разде­

ле 20 . 5 .

В качестве альтернати вы вторич н ы й загрузч ик может находитьс я в » мертвой зоне » , которая расположена м ежду M B R и н ачалом первого раздела диска. П о историческим причинам первый раздел не начи нается до 64-го сектора диска, поэтому эта зона обыч ­ но содержит м и ни мум 32 Кбайт памяти : все еще не м ного, но достаточно для хране­ ния драйвера файловой систе м ы . Эта схе ма хранения обычно используется загрузчиком G RU B (см . раздел 2.4). Для успещной загрузки все компоненты загрузоч ной цепочки должны быть правиль­ но установл е н ы и совместим ы друг с другом . Загрузочн ы й сектор M B R н ичего не знает об операционной системе, но, поскол ьку он предполагает определ е нное местоположе ­ ние для второго этапа, может быть установлено несколько версий. Вторич н ы й загруз­ чик, как правило, хорошо ос ведомлен об операционн ы х системах и файловых системах (он может поддерживать нес кол ько из н их) и обычно и м еет собстве н н ые параметры конфи гурации.

UEFI Спецификация U E F I включает в себя современную схему разделения диска, извест­ ную как G PT (табли ца разделов G U I D, где G U I D (globaly unique identifier) обознача­ ет » глобал ьно уникальный идентификатор» ) . U EF I также понимает файловую систему FAT ( File Allocation ТаЬе), простую, но функциональную схему, впервые примене нную в MS DOS. Эти функции объединяются для определения концепции системного раздела E F I ( ES P — E F I System Partition ) . Во вре мя загрузки м и кропрограмма обращается к та­ блице разделов G РТ для идентификации E S P. Затем она считывает н астроен ное целевое приложение непосредственно из файла в E S P и выпол няет е го. W Дополнительную и нформаци ю о разделах G PT см. в разделе 20.б. Поскольку E S P представляет собой общую файловую систему FАТ, ее можно смон ­ тировать, проч итать, записать и поддерживать в л юбой операцион ной системе. Н и какие с крытые загрузочные се ктора на диске не требуются . 3 1 П о п равде говор я , для обле гче н и я вза и м одействия с систе м а м и B I OS с п е ц и ф и кация U E F I п редусматри вает М В R-совмести мую зап ись в начале каждого диска . Систе м ы B I OS н е могут видеть пол н ую табл и цу разделов в стиле G РТ, но о н и , по край ней мере, распознают диск как отфор матирова н н ы й . Будьте осторож н ы , не запускайте оп ределе н н ые адм и н и страт и в н ы е инструменты для M B R на дисках G P’I Он и могут неправильно и нтерпретировать структуру диска.

Глава 2. Загрузка и системные демоны

73

Фактически н и какой загрузчи к вообще не требуется. Целью загрузки U EFI может быть ядро U N IX или Linux, которое настроено дл я прямой загрузки U EFI , что приводит к загрузке без загрузчи ка. На практике, однако, большинство систем по-прежнему ис­ пользуют загрузчик, отчасти потому, что он упрощает поддержку совместимости с уста­ ревш и м и B IOS. И нтерфе йс U E F I сохран я ет имя пути для загрузки из ESP в качестве параметра конфигураци и . Если этот параметр не зада н , испол ьзуется стандартн ы й п уть, в со­ врем е н н ы х системах lntel обы ч н о это п уть /efi /boot/bootx 6 4 . ef i . Более типич­ ный путь в с исте м е с заданной кон ф и гурац и е й (для Ubuntu и загрузчика G RU B ) / e f i / ubun tu / grubx 6 4 . efi . Другие дистрибутивы п р идерживаются аналогичного соглаше н и я . И нтерфейс U E F I определяет стандартные и нтерфейсы API для доступа к аппарат­ н ы м средствам с исте м ы . В этом отнош е н и и он представляет собой нечто вроде м и ­ н и атюрной операционной систе м ы . О н даже обеспе чивает н ал и ч и е допол нительных драйверов устройств на уровне UEFI, которые записываются на языке, н е зависящем от процессора, и сохраняются в ESP. Операционные систе м ы могут испол ьзовать интер­ фейс U E F I или напрямую управлять оборудованием. П ос кольку U E F I и меет формальный и нтерфейс API , переменные UEFI можно про­ верять и изме нять ( включая зап ис и загрузочного меню) уже в загруженной с истеме. Например, команда efibootmgr -v показывает следующую с водку конфигурации за­ грузки: $ efiЬootmgr -v BootCurrent : 0 0 0 4 B o o t O r de r : 0 0 0 0 , 0 0 0 1 , 0 0 0 2 , 0 0 0 4 , 0 0 0 3 B o o t O O O O * E F I DVD / CDROM P c i Root ( O x 0 ) / Pc i ( O x l f , O x 2 ) / S a t a ( l , 0 , 0 ) B o o t O O O l * E F I H a r d D r i v e P c i Ro o t ( O x 0 ) / P c i ( O x l f , O x 2 ) / S a t a ( 0 , 0 , 0 ) B o ot 0 0 0 2 * E F I N e t wo r k P c i Ro o t ( O x 0 ) / P ci ( O x 5 , 0 x 0 ) /МAC ( 0 0 l c 4 2 fb 5 ba f , 0 ) В о оt О О О З * E F I I nt e rn a l S he l l Memo r yMapp ed ( l l , O x 7 e d 5 d 0 0 0 , 0 x 7 f 0 dc f f f ) / FvF i l e ( c 5 7 ad б b7 — 0 5 1 5 — 4 0 a 8 — 9 d2 1 — 5 5 1 6 5 2 8 5 4 e 3 7 ) B o o t 0 0 0 4 * ubun t u H D ( l , G PT , 0 2 0 c 8 d 3 e — f d 8 c — 4 8 8 0 — 9b 6 1 e f 4 c f f c 3 d7 6 c , O x 8 0 0 , 0 x l 0 0 0 0 0 ) / Fi l e ( E F I ubun t u s h imx 6 4 . e f i

Команда efibootmgr позволяет измен ить порядок загрузки , в ыбрать следующ и й н астроен н ы й параметр загрузки или даже создать и уничтожить загрузочные запи с и . Например, установить порядок загрузки так , чтобы сначала обращаться к с исте мному диску, а потом — к сети , и гнорируя другие парам етры загрузки , можно с помощью ко­ манды $ sudo efibootmgr — о 0 0 0 4 , 0 0 0 2

Здесь м ы указываем параметры Boot 0 0 0 4 и Boot 0 0 0 2 из выведенных в ы ш е дан ных. Возможность изменять конфигурацию UEFI из пользовательского п ростран ства оз­ начает, что и нформация о конфигурации прошивки может как читаться , так и записы­ ваться — это и благословение, и проклятие. В системах, разрешающих доступ на запись по умолчанию ( как правило, с помощью менеджера systemd) , команды rm -rf / мо­ жет быть достаточно, чтобы навсегда уничтожить систему на уровне прошивки; в допол­ нение к удалению файлов команда rm также удаляет переменные и другую информацию U E F I , доступ ную через / sys4• Не п ытайтесь повторить это дома!

4Для получения дополнительной и нформации см. g o o . g 1 / QMS i SG (ссьmка на статью Phoroпix) .

Часть l. Основы администрирования

74

2.3. ЗАГРУЗЧИКИ Большинство процедур начальной загрузки вкл ючают в себя выпол нение загрузчика, к ото ры й отл ичается от кода B IO S/ U E FI и ядра операцион ной систе м ы . Он также отде­ лен от начал ьного загрузочного сектора в B I O S , если вы считаете этапы. Основное задание загрузч и ка определить и загрузить соответствующее ядро опера­ ционной с исте м ы . Большинство загрузчи ков также могут предоставлять пол ьзовател ь­ ский и н терф е й с загрузки , которы й позволяет выбирать, какое из нескольких возмож­ н ых ядер или операционн ых систем вызвать. Другая задача загрузчи ка — это маршал и н г (marshaling) аргум ентов конфигураци и дл я ядра. Ядро н е и меет командной строки к а к таковой, но обработка е го параметров зап ус ка может показаться довол ьно похожей на работу с оболочкой . Например, аргу­ мент s ingle или -s обычно указы вает ядру войти в однопол ьзовател ьский режим , а не выпол н ять нормал ьны й п роцесс загрузки. Такие параметры могут быть жестко при вязаны к конфи гурации загрузчи ка, если вы хотите , чтобы они испол ьзовались при каждой загрузке , или предоставляться » на лету» через п ол ьзо вател ьс кий и н терфе й с загрузчика. В следующих нескольких разделах м ы обсудим G R U B (ос новной загрузчи к операци­ о н н о й с исте м ы Linux) и загрузч и к и , используемые с системой Free B S D . —

2 .4. G RU B: У НИВЕРСАЛЬНЫЙ ЗАГРУЗЧИК G RU B ( G Rand U nified Boot) , разработанный G N U Project , я вляется загруз­

ч иком по умолчан и ю для больши нства дистрибутивов Li nux. Л иния G R U B и м е ет два основных направл е н и я : ори гинал ь н ы й G R U В , теперь н азывае ­ м ы й G RU B Legacy, и новый G RU B 2 , который я вляется текущи м стандар­ том. Убедитесь, что вы знаете , с каким вариантом загрузчи ка G R U B вы име­ ете дело, поскол ьку эти две верс и и совершенно разные. G RU B 2 был загрузоч н ы м менеджером по умолчан и ю для систе м ы Ubuntu, нач и ­ ная с верси и 9. 1 О, и недавно стал загрузоч н ы м менеджером п о умолчан ию дл я систе м ы R H E L 7 . Все наш и примеры дистрибутивов Linux испол ьзуют его по умолчан ию. В этой кн и ге м ы обсуЖДаем только G RU B 2 и называем е го просто G RU B. У с исте м ы Fre e B S D есть собстве н н ы й загрузчи к (более подробно с м . раздел 2 . 5 ) . Однако G R U B отл ичн о с п ра вл яется с загрузкой Free B S D . Это может оказаться удоб­ н ы м , если вы план ируете загружать несколько операционн ых систем на одном компью­ тере. В п роти в н ом случае загрузч и ка Free B S D более чем достаточно.

Кон ф игураци я G R U B G RU B позвол яет указать такие параметры, как загрузочное ядро (указанное в каче­ стве записи меню G RUB) и режим работы для загрузки. П оскол ьку эта информация о конфигураци и н еобходима во вре м я загрузки , можно подумать, что она будет хран иться где-то в необычном месте , например в энергонеза­ виси мой с истем ной пам яти NVRA M или в секторах диска, зарезервированных для за­ грузчика. На самом деле G RU B понимает большинство используемых файловых с исте м и обычно может самостоятел ьно найти корневую файловую систему. Это позволяет за­ грузчи ку G RU B читать с вою конфигураци ю из обыч ного текстового файла.

Глава 2. Загрузка и системные демоны

75

Конфигурационный файл называется gruЬ . cfg, и е го обычно хранят в каталоге /boot/ gruЬ ( /boot/gruЬ2 в системах Red Hat и CentOS) вместе с выбором других ресурсов и мо­ дулей кода, которые G RU В может потребовать для доступа во время загрузки. 5 Изменение конфигурации загрузки — это простой вопрос об обновлении файла gruЬ . cfg. Хотя можно создать файл grub . cfg самостоятельно, чаще всего е го проще гене­ р ировать с помощью утил иты grub-mkconfig, которая называется grub2 -mkconfig в с истем ах Red H at и CentOS и update-gruЬ в системах Deblan и Ubuntu. Фактич ески большинство дистрибути вов предполагают, что файл gruЬ . cfg может быть регенериро­ ван по желанию, и они делают это автоматически после обновлений. Если вы не пред­ примете н и каких шагов, чтобы предотвратить это, ваш файл grub . cfg будет испорчен. Как обыч но в системе Linux, дистрибутивы задают конфигураци ю утилиты grub­ mkconfig различными способами . Чаще всего конфигураци я задается в каталоге /etc/ default/gruЬ в виде присваивания переменных sh. В табл . 2. 1 показаны н екоторые из часто изменяемых опций. Табли ца 2 . 1 . Общие параметры конфиrурации GRUB в файле / etc/ defaul t/ gruЬ Обозначение переменной оболочки

Содержимое или функция

GRUB BACKGROUN D

Фоновое изображение•

GRUB _ CMDL I N E _ L I NUX

Параметры ядра для добавления в записи меню для Li nux6

GRU B D E FAULT

Номер или название элемента меню по умолчанию

GRUB D I SABLE RECOVERY

Предотвращает создание записей режима восстановления

GRUB_ PRELOAD_MODULES

Список модулей GRUB, загружаемых как можно раньше

GRUB T I МEOUT

Секунды для отображения меню загрузки перед автозагрузкой

• Фоновое изображение должно иметь формат

.

pnq, . tqa, jpq или . jpeq. •

68 табл. 2.3 в разделе 3.4 перечислены некоторые из доступных опци й .

Ш Подробнее о режимах работы см . раздел 2.7. После редактирован ия каталога /etc/defau l t /grub запустите утилиты update ­ gruЬ ил и gruЬ2 -mkconfig, чтобы перевести вашу конфигурацию в правил ьн ы й файл gruЬ . cfg. В рамках процесса построения конфигурац и и эти команды п роверяют загру­ зочные ядра с исте м ы , поэтому он и могут быть полезны для запуска после внесения из­ менений ядра, даже если вы явно н е изменили конфигураци ю G RU B . Возможно, вам потребуется отредактировать файл /etc/gruЬ . d/ 4 0_cus tom, чтобы и зм е н ить порядок, в котором ядра указаны в меню загрузки (например, после созда­ н ия настраивае мого ядра) , установить пароль для загрузки или изменить имена пунктов м е н ю загрузки. Как обычно, после внесения изменений запустите утилиты update ­ gruЬ или gruЬ2 -mkconfig. Например, вот как в ыглядит файл 4 0_cus tom, которы й вызывает пользовательское ядро в системе Ubuntu.

‘ Есл и вы з накомы с соглаш ен и я м и файловой системы U N IX (см . главу 5 ) , то можете з адаться вопросом, почему каталог /boot/qruЬ не н а з ван как-то более стандартно, например /var/ lib/ qruЬ и л и /usr/ local /etc/gruЬ. Причина в том , что драй веры файловой с и стемы, используемые во время загрузки , несколько у проще н ы . Загрузч ики не могут обрабатывать доп ол н ительные функци и , такие как точки монтирова ния , когда они обходят файловую с и стему. Все в каталоге /boot должно быть простым файлом или каталогом .

Часть 1. Основы администрирования

76

# ! /Ь i n / s h ехес tail -n +3 $ 0 Jt T h i s f i l e p r ovi de s a n e a s y way t o add cus t om menu e n t r i e s . Ju s t t ype Jt t h e menu e n t r i e s you want t o a d d a f t e r t h i s comme n t . В е c a r e ful n o t to Jt change t h e ‘ ех е с t a i l ‘ line above .

menu e n t r y ‘ М у Awe s ome K e r ne l ‘ s e t r o o t = ‘ ( hd O , msdo s l ) ‘ / a we s ome_k e r n e l r o o t = U U I D=XXX -XXX — XXX r o qu i e t l i nux i n i t rd / i n i t rd . img- a we s ome_k e r n e l

W Для получ е н и я доп олнител ьной и н формации о монтирова н и и файловых систем с м . раздел 5 . 1 .

В этом примере G R U B загружает ядро из каталога /awesome_kerne l . П ути к ядру я вл яются относител ьн ы м и и связа н ы с загрузоч н ы м разделом котор ы й исторически монтировался как /boot, но с поя влением U E F I теперь, с корее все го, он я вляется де­ монтирова н н ы м систе м н ы м разделом EFI. Для проверки вашего диска и определения состоян ия загрузочного раздела испол ьзуйте команды gpart show и mount .

К ома ндная строка GRUB G RU B поддержи вает и нтерфейс командной строки для редактирования записей в файле конфигурац ии » на лету» во время загрузки. Ч тобы войти в режи м командной строки , введите команду с на экране загрузки G RU B. В командной строке можно загружать операцион н ые с исте м ы , которые не указаны в файле grub . cfg, отображать системную информаци ю и выпол н ять рудиментарное тестирован ие файловой с исте м ы . Все , что можно сделать через файл grub . cfg, также можно выполн ить с помощью командной строки. Н ажм ите клавишу , чтобы просмотреть список возможных команд. Некоторые наиболее полезные команды показаны в табл. 2 . 2 . Таблица 2 . 2 . Команды GRUB Команда

Функци•

boot

Загружает систему из указанного образа ядра Получает интерактивную помощь для команды Загружает ядро Linux Перезагружает систему Поиск устройств по файлу, метке файловой системы или UUID П роверка поддержки USB

help l inux reЬoot search usb

Для получения подробной информации о G RU B и параметрах командной строки об­ ратитесь к офи циал ьному руководству по адресу gnu . o rg / s o f t w a r e / g ru Ь / ma n u a l .

Параметры ядра Li nux П араметры запуска ядра обычно изменяют знач е н и я параметров ядра, инструкт и ­ руют ядро проверять определ е н н ы е устройства, указы вать п уть к процессу ini t ил и systemd л ибо назначать определенное корневое устройство. В табл . 2 . 3 приведено не­ сколько примеров.

Глава 2. Загрузка и системные демоны

77

Таблица 2 . 3 . Примеры параметров времени загр узки ядра Опция

·

Значение

debug

Включает отладку ядра

init=/Ьin/bash

Запускает только оболочку bash; полезна для аварийно го восстановления

r o ot = / dev / f o o

Инструктирует ядро использовать /dev/ foo в качестве корневого устройства

s in g l e

Загрузка в однопольэовательском режиме

Если параметры ядра задаются во врем я загрузки, они не я вляются постоя н н ы м и . Для того чтобы сделать изменение постоян н ы м при перезагрузке, отредактируйте соот­ ветствующую строку ядра в файле /etc/gruЬ . d/ 4 0-custom или /etc/defaults/gruЬ (переменная с именем GRUB CMD L I NE L I NUX) . В ядро Linux постоян но добавляются заплатки безопасности , исправления ош ибок и новые функции. Однако в отл и ч ие от других пакетов программного обеспеч е н ия но­ вые верс и и ядра обычно не заменяют старые. В место этого новые ядра устанавливаются наряду с предыдущи м и версиями , так что в случае возникновения проблем можно вер­ нуться к старом у ядру. Это соглашение помогает адми н истраторам отказаться от обновления, есл и заплатка ядра разрушает их с истему, хотя это также означает, что загрузочное меню и меет тенден­ цию сохранять старые верс и и ядра. Попробуйте выбрать другое ядро, если ваша система н е будет загружаться после обновления. Подробнее о параметрах ядра см. в главе 1 1 . _

_

2.5. П РОЦЕСС ЗАГРУЗКИ FREEBSD Система загрузки FreeBSD во многом похожа на G RU B , поскольку загрузчик конечной стадии ( под и менем loader) использует файл конфигураци и на ос­ нове файловой систе м ы , поддержи вает меню и предлагает интерактивн ы й режим командной строки. Загрузчик loader — это последнее пересечение вариантов загрузки B I OS и UEFI.

Вариант BIOS: boo tO Как и в случае с и нтерфейсом G RU B , полн ая среда загрузчика loader сли ш ком ве­ л и ка для размещения в загрузочном секторе M B R, поэтому в B IOS постепенно загружа­ ется и запус кается цепочка более сложных предварительных загрузчиков. Интерфейс G R U B объединяет все эти ком поненты под общим названием » G R U B» , но в с истеме FreeB S D ранние загрузчики я вляются частью отдельной систем ы под на­ зва н и е м bootO , которая используется только в системах B IOS. Система bootO и м еет свои собствен н ые опци и , главны м образом потому, что она хранит более поздние этапы цепочки загрузки в загрузочной записи тома (см. раздел » Устаревший и нтерфейс B IOS» в разделе 2 . 2 ) , а не перед первым дисковым разделом. П о этой причине для загрузочной записи M B R нужен указатель н а раздел, которы й необходимо испол ьзовать дл я продолжения процесса загрузки. Как правило, все это ав­ том атически настраивается как часть процесса установки FreeBSD, но если вам когда­ л ибо понадобится н астроить конфигурацию, это можно сделать с помощью команды bootOcfg.

часть 1. Основы администрирования

78

Вариант UEFI О перацион ная система Free B S D , использующая и нтерфейс U E F I , создает с истем ­ н ы й раздел E F I и устанавливает там заrрузоч н ы й код в файле /Ьооt/Ьооtхб4 . ef»i. 6 Это путь по умолчани ю , которы й проверяют систе м ы U E F I во врем я заrрузки (по крайней мере на совре м е н н ых платформах персональных ком пьютеров) , поэтому никакой кон­ фиrураци и прошивки не требуется , за исключением правил ьно установленных приори­ тетов заrрузки устройств. По умолчан и ю с истема Free B S D н е сохраняет смонтирован н ы м с исте м н ы й раздел E F I после заrрузки. Таблицу разделов можно идентифицировать с помощью команды gpart. $ gpart shov

=>

40 40 1640 1 2 7 92 63 0 4 1 3 4 2 1 7 68 7

134217648 1600 127924664 62 9 1 3 8 3 1

adaO 1 2 3

GPT ( 64G) efi ( 800К) f r e eb s d — u f s ( 6 1 G ) f r e e b s d — swap ( 3 . 0 G ) — free ( 5 128) —

Хотя существует возможность подключить систе м н ы й раздел ESP, чтобы узнать, что в нем содержится ( используя команду mount -t msdo s ) , вся файловая система — это всеrо л и ш ь копия образа, найден ного в файле /Ьoot/bootl . ef»if»at на корневом дис­ ке. Внутри нет деталей , которые пользовател ь мог бы измен ить. W Для п олуч е н и я допол н и тел ьной информации о монти рован и и файловых систе м с м . раздел 5 . 1 .

Если раздел ESP поврежден или удален , ero можно повторно создать, настрои в раз­ дел с помощью команды gpart, а затем скопировав образ файловой систе м ы с помо­ щью команды dd: $ sudo dd if=/boot/bootl . efifat of=/dev/ adaOpl

Как только начальн ы й заrрузчик первого этапа U E F I находит раздел типа f re e b s d ­ u f s 7 , он заrружает UЕFl-версию проrраммы loader из файла /Ьoot/ loader . ef»i . С это­ го момента загрузка в ыполняется точно так же , как под управлением B I O S : заrрузчи к loader определяет, какое ядро следует заrрузить, устанавливает параметры ядра и т.д.

Конфигурация загрузчика Заrрузчи к loader на самом деле является средой сценариев на языке Forth.8 Внутри каталога /boot хран ится код на языке Forth, управляющий операциями заrрузчика, но он вполне самодостаточн ы й — вам не нужно изучать Forth. Чтобы пол уч ить значения переменных конфиrураци и , сценарии на языке Forth счи­ тывают файл /boot/loader . conf», поэтому задавать их следует именно здесь. Н е путай­ те этот файл с файлом /boot/def»aults / l oader . conf», которы й содержит настройки по умолчанию и не предназначен для изменения. К счастью, присваиван ия пере м е н н ых 6 Н е пуrайте каталог /boot в с истемном разделе E F I с каталогом /boot в корневой файловой систем е Fre e B S D . Они отделен ы друг от друга и служат разл и ч н ы м uеля м , хотя , конечно, оба связаны с начальной загрузкой . 7 Н ач и н ая с верс и и Free B S D 1 0 . 1 , в качест ве корне вого раздела в с и ст е м е U E F J можно использовать Z FS . «Э то замечательны й и интересны й языков программирования.

факт, имеющи й значение лишь для люде й , интересующихся историей

Глава 2. Загрузка и системные демоны

79

в файле loader . conf с интаксически похожи на ста ндарт н ы е операци и присваивания в оболочке sh. С правоч н ы е mа n -страницы о загрузчи ке loader и файле loader . aonf содержат и н формацию обо всех параметрах загрузч и ка и перем е н н ы х к о нфигур а ц и и которые их контрол и руют. Не которые из наиболее и нтересных вариа нтов защищают меню за­ грузки паролем , м е н я ют экран заставки , отображаем ы й п р и загрузке , и передают па­ раметры ядра. ,

Кома нды за грузч ика loader Загрузчи к понимает разл и ч н ые и нтерактивные команды. Напр и мер, чтоб ы найти и загрузить альтернативное ядро, необходимо испол ьзо вать п оследовательность следу­ ющих команд: Т ур е ‘ ? ‘ f o r а l i s t of c ommand s , ок ls 1 d . s nap d dev

‘ help ‘

for more de t a i l e d h e l p .

d r e s cu e 1 h ome ок unload ОК load /boot/kernel/ kernel . old / b o o t / ke rn e l / ke r ne l . o l d t e x t = O x f 8 f 8 9 8 d a t a= O x l 2 4 ОК boot

.

.

.

Ь0 7 7 )

Здесь мы в ы вели содержи м ое корневой файловой с исте м ы (по умолчани ю ) , в ы ­ грузил и ядро по умолчани ю {/boot/ kerne l / kerne l ) , за г руз ил и более старое ядро {/boot/kernel/kernel . old) и продолжили процесс загрузки . Для получе н ия полной документации о доступных командах выпол ните команду man loader.

2.6. Д ЕМОНЫ УПРАВЛЕНИЯ СИСТЕМОЙ П осле загрузки и заверш е н ия процесса и н и циализации ядро создает спон та н н ы е процессы в пользовательском п ространстве. О н и н аз ы ва ю тся спонтанным и , п отом у что ядро запус кает их автономно — при нормал ьном ход е событий новые процессы созда­ ются тол ько по воле существующих процессов. Большинство спонтанных процессов действительно я вляютс я частью реализации ядра. Они не обязательно соответствуют программам в файл о вой системе. Они не настраивают­ ся и не требуют внимания со стороны системного администратора. Их можно распознать в списках ps (см. раздел 4.3) по низким значениям параметра PI D и скобкам вокруг их и м ен (например, [ pa gedaemon ] в системе Free BS D или [ kdump ] в системе Linux). И с кл ю ч е н и е м из этого ш аблона я вляется демон у п равл е н и я си стемой. Он и м е е т идентификатор процесса, рав н ы й 1 , и обычно работает под и м ен е м ini t. Систем а дает демону ini t несколько специальных привилегий , но по большей части это п росто про­ грам ма на уровне пользователя , как любой другой демон . «

«

Часть 1. Основы администрирования

80

О бязанности демона ini t Демон ini t и меет несколько фун кций , но его главной целью я вляется обеспечение того, чтобы система запускала правильные комплекты служб и демонов в л юбой момент времени. Для достижен ия этой цели ini t поддерживает понятие режима, в котором с истема должна работать. Н иже перечислены некоторые общепринятые режи м ы9• •

Однопользовательский режи м , в котором монтируется тол ько м и н и м ал ьн ы й на­ бор файловых систе м , н и одна из служб не запущена, а на консоли запущена кор­ невая оболоч ка.

М ногопол ьзовательский режи м , в котором монтируются все обыч ные файловые с исте м ы и запуще н ы все настроенные сетевые службы , а также око н ная система и графический менедЖер входа в консоль.

Режим сервера, аналогичный режиму м ногопользовательского режи ма, но без ис­ пользо вания графического пользовательс кого интерфейса на консол и .

Кажды й режим с вязан с определенным комплектом систе м н ых служб, а демон и н и ­ циал изации запус кает или останавл ивает службы п о мере необходимости , чтобы при­ вести фактическое состоян и е с исте м ы в соответствие с текущим акти вным режи мом . Режим ы могут также и меть связанные с н и м и контрол ьные задач и , которые запускают­ ся всякий раз, когда режим начинается или заканчивается. Например, демон ini t обычно выполняет м ногие задач и , с вя занн ые с запуском , в качестве побоч ного эффекта перехода от начал ьной загрузки к м ногопользовательско­ му режиму. К н и м могут относиться следующие задачи . •

Установка и м е н и ком пьютера.

Установка часового пояса.

П роверка дисков с помощью команды fsck.

Монтирование файловых систем .

Удаление старых файлов и з каталога / tJnp .

Н астрой ка сетевых и нтерфейсов.

Н астрой ка фил ьтров пакетов.

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

У демона init очен ь мало встроенных знаний об этих задачах. Он просто запускает набор команд или сценариев, которые были назначены для выполнения в этом кон крет­ ном контексте .

Реа л изации демона ini t В настоящее время широко используются три совершенно разных стиля в процессах системного управления. •

Стиль init, принятый в системе System V U N IX компании АТ&Т, которы й м ы называем «традиционн ы м стилем init» . Этот стиль был преобладающим в систе­ м ах Linux до поя вл е н ия менедЖера systemd.

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

Глава 2. загрузка и системные демоны

81

Вариант i n i t, которы й происходит от с истем ы B S D UN IX и испол ьзуется в больш и нстве В S D — с исте м , вкл ючая Free BSD, Ope n B S D и N et BS D . Он так же проверен временем, как и стиль SysV ini t , и и меет столько же прав называть­ ся «традицион н ы м » , но для ясности мы называем ero » B S D init» . Этот вариант довольно прост по сравнению с и н ициал изацией стиля SysV. Мы обсудим e ro от­ дельно в разделе 2 . 8 .

Относительно недавно у демона ini t появился конкурент — менеджер sys temd, целью которого является полное решение всех пробл е м , связа н н ы х с демонами и состоян и е м с истемы . Как следствие, менеджер sys temd захватил знач ительно большую территорию, чем л юбая традиционная версия демона ini t. Это несколь­ ко противоречивая с итуация, о которой мы поrовори м н иже . Те м не м е н ее все наши примеры дистрибутивов Linux теперь содержат менеджер systemd.

Хотя эти реали заци и являются преобладающ и м и в данн ы й м о м е н т, о н и дал е к и о т того, чтобы б ыть еди н ствен н ы м варианто м . Например, в операционн о й систе м е macOS компании Apple используется с истема и н ициализации с именем launchd. П ока в системе UЬuntu не бьm реализован менеджер systemd, в ней испол ьзовался друrой со­ временный вариант демона ini t под названи е м U pstart. В с истемах Linux теоретически можно заменить и нициализацию по умолча­ нию в зависимости от того, какой вариант вы предпочитаете . Но на прак­ тике демон ini t н астолько важен для работы с исте м ы , что м ногое до­ пол нительное програ м мное обеспечение может в ы йти из строя . Если вы не желаете испол ьзовать менеджер sys temd, примите в качества стандарта дистрибутив, которы й его не использует.

Традицион н ый стил ь ini t В традиционном мире и н и ц иализации системные режим ы (например, однопол ъзо­ вательские или мноrополъзовательские) называются уровнями выполнения. Бол ьш инство уровней выполнения обозначаются одной буквой или цифрой. Традиционн ы й стиль init появился в начал е 80-х гг. Е го сторонники (т. е . против­ н ики применения менеджера sys temd) часто ссьmаются на принцип: » Не сломалось не чини » . Тем не менее традиционн ы й стиль ini t имеет ряд зам етных недостатков. Начнем с тоrо, что традиционный демон init сам по себе не настолько силен, чтобы справляться с потребностям и современных операционн ых систем. Бол ьш инство систе м , которые ero испол ьзуют, на самом деле имеют стандартную и фикс ированную конфигу­ рацию ini t, которая никогда не изменяется. Эта конфигурация ссылается на второй уро­ вень сценариев оболочки, которые выполняют фактическую работу по изменению уров­ ней выполнения и позволяют администраторам вносить изменения в конфигурацию. Второй уровень сценариев поддерживает еще и третий уровен ь сценариев, связанных с де моном и с истемой, которые привяза н ы к каталогам определенного уровня, указы­ вающ и м , какие службы должны работать и на каком уровне запуска. Все это нем ного запутанно и неизящно. Говоря кон кретно, эта с истем а не и меет общей модели зависимосте й между служ­ бам и , поэтому требуется, чтобы все запуски и демонстрации выполнялись в порядке , заданном адм и нистратором . Более поздн ие действия не могут выполняться до тех пор, пока не будут закончены все предыдущие , поэтому выполнять и х параллел ьно невоз­ можно, и система тратит много времени, чтобы изменить состояние.

82

Часть 1. Основы администрирования

М енеджер sys temd п ротив остал ьного мира Л и ш ь нем ногие пробл е м ы в области Linux обсуждал ись более горячо, чем переход от традицион ного де мона init к менеджеру sys temd. По большей части , жалобы со­ средоточиваются на постоянно растущих масштабах систе м ы . Менеджер sys temd осуществляет все фун кции i n i t , ранее реал и зова н н ые с помо­ щью хитроумных уловок и приемов, и формал изует их в еди ное целое, позволяя настра­ и вать, получать доступ и управлять службам и . В качестве с исте м ы управлен и я пакетами менеджер sys temd определяет надежную модель зависимосте й не тол ько среди служб, но и среди » целе й » . Этот терм и н испол ь­ зуется в контексте sys temd для описания режимов работы, которые в контексте тради­ цион ного демона init называл ись уровнями выполнения. Менеджер systemd не толь­ ко управляет п роцессам и параллельно, но также управляет сете в ы м и подкл ючениями (networkd) , зап ися м и журнала ядра ( j ournald) и авторизацией (logind) . П ротивники использования менеджера sys temd утверждают, что философия U N IX закл ючается в том , чтобы систе м н ые ком поненты были небол ьш и м и , простым и и мо­ дульн ы м и . Говорят, что такой фундаментал ь н ы й ком понент, как ini t н е должен иметь монолитного контроля над м ноги м и другим и подсистемами операцион ной систе м ы . Менеджер systemd не тол ько порождает сложность, но и создает поте н циальные н е ­ достатк и в области безопасн ости и препятствует разграничению между платформой опе­ рац ион ной с исте м ы и служба м и , которые работают н а ее ос нове . Ш Дополнител ьную информацию об уп равлени и пакетами см. в главе 6 . Менеджер systemd также критикуют з а введен ие новых стандартов и обязанностей в ядро Linux, качество кода, предполагаемую н е вос п р и и м ч и вость е го разработч и ков к сообщениям об ошибках, дизайн его основных фун кций и неле пый вид. М ы не можем справедли во реш ить эти проблемы в этой книге , но читатели могут ознакомиться с аргу­ ментами в разделе Arguments against systemd по адресу w i t ho u t — s ys t emd . o r g , на основ­ ном сайте противн и ков sys temd.

А ргументы против ini t Архитектурн ы е возражен ия против менеджера sys temd, изложе н ные выше, я вл я ­ ются вполне разу м н ы м и . Он действител ьно имеет большинство тип и ч н ых недостатков надстрое нного п рогра м много проекта. Н а практике , однако, м ногие адми нистраторы оч е н ь л юбят испол ьзовать sys temd, и мы относимся к этому лагерю. Оставьте на время полем ику и предоставьте менеджеру systemd шанс завоевать ваше признание. Как только вы привы кнете к нему, вы, с корее всего . оцен ите е го м ногочисле н н ые преимущества. По крайней мере , имейте в виду, что традиционн ы й демон init, который вытесняет­ ся менеджером sys temd, не был идеальным. Помимо всего прочего, менеджер sys temd просто устраняет нескол ько ненужных разл ичий между дистрибутивами Linux. Дебаты действител ьно н е и м е ют значе н и я , потому что соре внован и е завершено. Аргументы против испол ьзования sys temd потеряли силу, когда на него переключились системы Red Hat , Deblan и Ubuntu. М ногие другие дистрибутивы Linux теперь принима­ ют systemd л ибо вольно, л ибо невольно. Традиционн ы й де мон ini t по- прежнему и грает определенную роль, есл и дистрибу­ тив л ибо нацелен на небольшой размер и нсталляци и , либо н е нуждается в расшире н н ых фун кциях управлен ия процессом sys temd. Также существует знач ительное количество

глава 2 . Загрузка и системные демоны

83

реван ш истов, которые презирают систему из принципа, поэтому н екоторые дистрибу­ тивы Li nux обязател ьно будут поддерживать тради цион ную и н ициал изацию в теч е н ие неопределе н ного срока в качестве формы протеста. Тем не менее м ы не считаем , что тради цио н н ы й демон ini t и меет будущее , чтобы заслужить подробное обсуждение в этой книге . Для систе м ы Linux мы в основном огра­ ничиваемся менеджером systellld . М ы также обсудим оче н ь простую систему инициализации, испол ьзуемую Free B S D , в разделе 2 . 8 .

2.7. МЕНЕДЖЕР

SYSTEМD

в ДЕТАЛЯХ

Конфигурация и управление систе м н ы м и службами — это область, в которой дис­ трибутивы Linux традиционно отличаются друг от друга. М е н еджер sys temd нацелен на стандартизацию этого аспекта систе м ного адми нистрировани я , и в этой области он достиг бол ьших успехов, чем л юбая предыдущая альтернатива. Систе м н ы й м е неджер sys temd это не отдельный демон , а набор п рограм м , де­ монов, библ иотек, технологий и ком понентов ядра. Как отмечается в сообще н и и , опу­ бл икованном в блоге , посвященном systemd на странице O p o i n t e r . de / Ь l og , полная сборка проекта генерирует 69 разн ых двоичных файлов. Подумайте об этом как о конди­ терской , в которой вы обязаны съесть все конфеты . Поскольку менеджер systemd с ил ьно зависит о т особенностей ядра Linux, это пред­ ложение предназначено тол ько дпя Linux. В ы не увидите е го в системе B S D ил и любом другом варианте U N IX в течен ие следующих пяти лет. —

М одул и и модульные файл ы Сущность, которой управляет менеджер sys temd, называется модулем (unit) 10• Более кон кретно, модулем может быть «служба, сокет, устройство, точка монтирования , точка автоматического монтирования , файл или раздел подкачки, цель запуска, просматри ва­ емый файловый путь, таймер, управляемый systemd, часть ресурса управлен и я , группа со:щанных извне процессов или портал в альтернативную вселенную» . 1 1 Хорошо, мы даже захватили часть ал ьтернативной вселен ной, но она все еще занимает м ного территории. Внутри менеджера systellld поведение каждого модуля определяется и настраи вается модульным файлом. Например, в случае службы файл модуля указы вает м естоположе ­ ние исполняемого файла дпя демона, сообщает systemd, как запускать и останавли вать службу, а также идентифицирует л юбые другие модули , от которых зависит служба. Вскоре м ы рассмотри м синтаксис модульных файлов, а пока приведем простой при ­ мер и з систе м ы Ubuntu. Этот файл устройства rsync . service; он обрабатывает запус к демона rsync, который отображает файловые систе м ы . [ Uni t ] De s c r i p t i on= f a s t rerno t e f i l e сор у p rograrn d a ernon Condi t i on P a t h Ex i s t s = / e t c / r s yncd . c on f [ S e rvi c e ] ExecS t a r t = / u s r /bi n / r s ync — — d a ernon — — n o — d e t a c h

111 Н а жаргоне п рограммистов

их

часто называют юн итами .

1 1 В осн овном , цитируется по mаn-стра н и це sys temd . uni t.

Примеч. ред.

часть 1. основы администрирования

84 [ I nstal l ] W a n t e dB y=mul t i — u s e r . t a r g e t

Если вам показалось, что это напоминает файл в формате . ini, испол ьзуемом в сис­ темах M S — D O S , знач ит, вы хорошо понимаете почему к sys temd так плохо относятся. Модульные файл ы могут находитьс я в нескол ьких местах. Основное место , где паке­ ты сохраняют свои модульные файл ы во время и нсталляции — / u s r / l iЬ / sys temd/ sys tem; в некоторых с истемах для этого испол ьзуется каталог / l ib / systemd/ sys tem. Содержимое этого каталога сч итается ресурсом , поэтому вы не должн ы изменять е го. Файлы локал ьных файлов и настройки могут выполняться в каталоге /etc / sys temd/ sys tem. В каталоге /run/ sys temd/system есть также каталог модулей, который я вл я ­ ется рабочей областью для переходных модулей. М е неджер sys temd поддерживает телескопическое представление всех этих катало­ гов, поэтому они в значител ьной степени эквивалентн ы . Если возникает конфл икт, то файл ы в каталоге /etc имеют наивысш и й приоритет. W Для получения дополнительной информации о демоне rsync с м . раздел 1 7.4. П о соглашению, модульные файлы именуются суффиксом , который зависит от ти па настраиваемого устройства. Например, служебны е модули имеют суффикс . servi ce , а тай меры используют суффикс . timer. Внутри модул ьного файла н е которые разде­ л ы (например, [ U n i t ] ) относятся в общем случае ко всем типам м одул е й , но другие (например, [ S e rv i c e ] ) могут отображаться тол ько в контексте определ е н н ого типа устройства.

Команда sys temctl: упра вление менеджером sys temd Команда sys temctl — это универсал ьная команда для изучен и я состоян ия менед­ жера sys temd и внесения изм е н е н и й в е го конфигурацию. Как и в случае с системой G it и нескольки м и другим и слож н ы м и пакетами программ ного обеспече ния , первый аргумент команды sys temctl обычно представляет собой подкоманду, которая задает общую последовательность действий , а посл едующие аргументы я вл я ются специфиче­ с ки м и для этой кон кретной подкоманды. Подкоманды могут быть отдельн ы м и коман ­ дам и верхнего уровня , но для согласован ности и ясности они объедин е н ы в команду systemctl. W Для получения дополн ител ьной информации о системе Git см . раздел 7 . 8 . Выпол не н и е команды sys temctl без каких-л ибо аргументов по умолчани ю вы­ зывает подкоманду l i s t-unit s , в которой отображаются все загружен н ые и активные службы , сокеты, цел и , смонтированные диски и устройства. Для того чтобы показывать только загружен н ые и активные службы, используйте кл юч — type service: =

$ systemctl lis t-uni ts — — type=service

UN I T a c c o un t s — daemon . s e rv i c e

L OAD l oa d e d

ACT I VE a c t ive

SUB runni n g

wpa_suppl i c a n t . s e rv i c e

l o aded

a c t ive

runn i n g

DESCRI P T I ON Account s S e rv i c e W PA supp l i c a n t

Также и ногда полезно видеть все инсталл ированные модульные файл ы , независимо от того, акти вны они ил и нет: $ sys temctl list-uni t-fi les — — type=service UN I T F I L E S TATE

c r o n . s e rv i c e

enaЫed

Глава 2. Загрузка и системные демоны

c r yp t d i s ks — e a r l y . s e rvi c e c r yp t d i s ks . s e rv i c e cup s — b rows e d . s e rv i c e cups . s e rv i c e

mas ked ma s ke d enaЫed d i s aЫ e d

wp a_s uppl i c a n t . s e rv i c e x l l — c ommon . s e rv i c e

d i s aЫ e d ma s ke d

85

1 8 8 unit f i l e s l i s ted .

Для подкоманд, действующих на определ е н н ы й модул ь ( н а п р и м е р , sys temc t l s tatus) , команда systemctl обычно может при н имать и м я модуля без суффикса, ука­ зывающего тип модуля ( например, cups вместо cups . servi ce) . Тем не менее тип моду­ ля по умолчан ию, с которы м объединены простые имена, зависит от подкоманды . В табл . 2 . 4 показа н ы наиболее востребова н н ы е и полезные подкоманды команды systemctl (для получения полного списка с м . тап-страницу systemctl) . Таблица 2 . 4 . Наиболее распространенные подкоманды команды sys temctl Подкоманда l i s t-uni t-files

Функци• [ша блон}

Показывает установленные модули; существует возможность сравнения по ша блону

еnаЫе модуль

Вкл ючает модуль для активации при загрузке

di s aЫe модуль

Запрещает запуск модуля при загрузке

isolate ц ель

Изменяет режим работы на целе в о й

s tart модуль

Немедленно активирует модуль

s top модуль

Немедленно деактивирует модуль

res tart модуль

Немедленно перезагружает (или запускает, если не работает) модуль

s tatus модуль

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

kill ша блон

Отправляет сигнал в модуль , соответствующий шаблону

reЬoot

Перезагрузка компьютера

daemon-reload

Переза г ружает файлы модулей и конфигураци ю sys temd

Состоян ие модул я В вы воде команды systemctl l i s t-uni t — f i l e s , приведе нном в ы ш е , м ы в идим , что модул ь cups . service отключе н . Дл я получения более подробной и нформации м ы можем испол ьзовать команду sys temctl status. $ sudo sys temctl s tatus — 1 cups cups . s e rv i c e — C U P S S chedul e r L o a d e d : l o aded ( / l i Ь / s y s t e md / s y s t e m / cup s . s e rv i c e ; d i s a Ы e d ; vendor p r e s e t : e n aЫ e d ) Ac t i ve : i n a c t i ve ( de a d ) s i nc e S a t 2 0 1 6 — 1 2 — 1 2 0 0 : 5 1 : 4 0 MST ; 4 s a g o D o c s : man : cup s d ( 8 ) Ma i n P I D : 1 0 0 8 1 ( code=e x i t e d , s t a t u s = O / S U C C E S S ) Dec 1 2 0 0 : 4 4 : 3 9 u l s a h s y s t emd [ l ] : S t a r t e d C U P S Schedu l e r . D e c 1 2 0 0 : 4 4 : 4 5 u l s ah s y s t emd [ l ) : S t a r t e d C U P S S c h e du l e r . D e c 1 2 0 0 : 5 1 : 4 0 ul s ah s y s t emd [ l ) : S t opp i n g C U P S Schedul e r . . . Dec 1 2 0 0 : 5 1 : 4 0 u l s a h s y s t emd [ l ] : S t opped C U P S S c h e du l e r .

Часть 1. Основы администрирования

86

Здесь команда sys temctl показы вает, что служба в настоя щее врем я неактивна (de a d ) , и сообщает, когда процесс был прекраще н . (Для этого примера м ы откл юч ил и его всего несколько секунд назад.) Он также показывает ( в разделе с надписью Loaded), что служба по умолчанию была включена при запуске , но теперь она отключена. П оследние ч етыре строки — это последние записи журнала. П о умолчан и ю зап и ­ си журнала конденсируются так , что каждая зап ись зан имает только одн у строку. Это сжатие часто делает записи нечитае м ы м и , поэтому мы включили оп цию -1 для запроса пол н ых записей. В этом случае нет н и какой разн ицы, но это полезная привычка. В табл . 2.5 отображаются состоя н и я , с которы м и вы чаще все го столкнетесь при про­ верке модулей. Табли ца 2 . 5 . Состояние модульных файлов СостОАние

Описание

Ьаd

У менеджера sys temd возникла какая-то проблема; обычно это связано с о сбоем модульного файла

d i s aЫ e d

Присутствует, но не настроен для автономного запуска

enaЫed

Инсталлирован и запущен; стартует автономно

indi rect

Отключен , но имеет одинаковые значения в разделах Al s o , которые могут быть включены

l i n ked

Модульный файл , доступный через символическую ссылку

mas ke d

Нежелательный статус с логической точки зрения

s tаtiс

Зависит от другого устройства; не требует установки

Состоя ния e n a Ы e d и d i s aЫ e d применяются только к модул ьн ы м файлам , которые находятся в одном из систе м н ых каталогов systemd (т.е. они не связа н ы символической сс ыл кой) и и м е ют раздел [ I n s t a l l J в своих модульных файлах. Включенные модул и , по- видимому, действител ьно должн ы сч итаться » и нсталл ирован н ы м и » , что означает, что директи вы в разделе [ I n s t a l l ] был и выпол н е н ы и что устройство подкл ючен о к его обычн ы м активацион н ы м три ггерам . В большинстве случаев это состояние застав­ ляет модуль автоматически активироваться после загрузки системы. Аналогично, состояние d i s aЫ e d я вляется чем-то неправильным , потому что един ­ стве н ное, что фактически откл ючено, — это нормальный путь активаци и . Можно вруч ­ ную активиро вать устройство, которое было откл ючено, запустив команду sys temctl ; менеджер systemd не будет возражать. У м ногих устройств нет процедуры инсталляции, поэтому нел ьзя с казать, что о н и вкл ючен ы или откл юче н ы ; о н и просто доступ н ы . Статус таких эле м ентов указан как s t a t i c . Они активируются только вручн ую (systemctl start) или указываются в ка­ честве зависимостей от других активных модулей. Файл ы , имеющие состояние l i n k e d , был и создан ы с помощью команды systemctl l ink. Эта команда создает с и м волическую ссылку из одного из каталогов sys tem ме­ н еджера sys temd на модульный файл , который находится в другом месте в файловой систе м е . Такие модул ь н ы е файлы могут обрабаты ваться команда м и или указы вать­ ся в качестве зависимосте й , но они не я вля ются полноправными элементами систе м ы и имеют некоторые заметные отклонения. Например, применение команды sys temctl di s aЬle к модульному файлу в состоя н и и l i n ke d приводит к удалению связи и всех ссылок на него. К сожалению, точ ное поведен ие модул ьных файлов в состоянии l i n ked недостаточ­ но хорошо докуме нтировано. Хотя идея хранить локальные модульные файлы в отдель-

Глава 2. Загрузка и системные демоны

87

ном репозитори и и связывать их с менеджером systemd имеет определенную привлека­ тельность, вероятно, это н е луч ш и й подход на данн ы й момент. П росто сделайте коп и и . Состоя н и е ma s ke d означает » заблокирован адм и н и стратором » . Менеджер sys temd знает о модул е , но е м у запре ще но активировать е го ил и де йствовать по л юбой из ero конфигурацион н ых директив с помощью команды systemctl mask. В этом случае сле­ дует откл ючить модул и , находящиеся в состоян и и enaЫed или l i n ke d , с помощью ко­ манды sys temctl di saЫe и зарезервировать команду sys temctl m.ask дл я модул ей в состоя н и и s t a t i c . Возвращаясь к нашему исследованию службы cups, м ы могл и б ы испол ьзовать сл е­ дующие команды для ее повторного вкл ючения и запуска. $ sudo sys temctl еnаЫе cups S ynch r o n i z i n g s t a t e o f cup s . s e rv i c e w i t h S y sV i n i t w i t h / l iЬ / s y s t emd / s y s t emd- s y s v- i n s t a l l . . . Execu t i n g / l i Ь / s y s temd / s y s temd- s y s v- i n s t a l l е n а Ы е c u p s i n s s e rv : w a r n i n g : c u r r e n t s t a r t r u n l e ve l ( s ) ( emp t y ) o f s c r i p t c u p s ove r r i d e s L S B de f au l t s ( 2 З 4 5 ) . i n s s e rv : w a r n i n g : c u r r e n t s t op run l e v e l ( s ) ( 1 2 З 4 5 ) o f s c r i p t ‘ c up s ove r r i d e s L S B de f a u l t s ( 1 ) . C r e a t e d s yml i n k f r om / e t c / s y s t e md / s y s tem/ s o c ke t s . t a r g e t . wa n t s / cup s . s o c k e t t o / l i b / s y s temd / s y s t e m / c u p s . s o c ke t . C r e a t e d s yml i n k f r om / e t c / s y s temd / s y s t em/mu l t i — u s e r . t a r g e t . wa n t s / c up s . p a t h t o / l i b / s y s t emd / s y s t em / c u p s . p a t h . $ sudo sys temctl s tart cups ·

Цел и Модул ь н ы е файл ы могут объя влять свои отно ш е н ия с други м и модулями разл и ч ­ ными способа м и . Так, в при мере , приведен ном в начале раздела » Модули и модульные файл ы » , спе цифи катор W a n t e d B y означает, что , есл и систе м а и м еет модул ь mul t i ­ user . target, то дан н ы й модуль должен зависеть от него (rsync . service } , когда тот находится в состоян и и e n a Ы e d . П ос кол ьку модули н е посредств е н н о поддержи вают управл е н и е зав и с и мостя м и , дл я реал изаци и экви вале нта уровней выпол н е н ия i n i t не требуется н и каких допол ­ н ител ьн ы х механизмов. Дл я ясности менеджер sys temd определяет отдел ь н ы й класс модулей (типа . target), чтоб ы испол ьзовать их как маркеры общих режимов работ ы . Однако цел и не и м е ют особой с ил ы , з а исключ е н ием управл е н и я завис и м остя м и . до­ ступного для л юбого другого модуля. Тради цио н н ы й де мон init оп ределяет как м и н и мум се м ь уровн е й выпол н е н и я , но многие из них на самом деле не используются . Стремясь к ложно понятой исторической преемстве н ности , менеджер sys temd определяет цел и как прям ы е а налоги уровней за­ пуска демона ini t (runleve l O . target и т.д. ) . Он также определяет м н емонические цел и для повседневного ис пользова н и я , такие как poweroff . target и graphical . target. В табл . 2.6 показано сопоставление между уровнями выполнения ini t и целя­ ми systemd. Единстве н н ы м и целями , которые действител ьно необходимо знать, являются mul ti ­ user . targe t и graphical . target дл я повседневного испол ьзован ия и res cue . target для доступа к однопол ьзовател ьскому режи му. Для того чтобы измен ить теку­ щий режим работы систе м ы , используйте команду systemctl i solate: $ sudo sys temctl isolate mul ti-user . tarqet

Часть 1. Основы администрирования

88

Таблица 2 . 6 . Сопоставление между уровня ми запуска ini t и системными целями

Уровень выполнения

Цепь

Описание

О

poweroff . target

Остановка системы

emergency

emergency . target

Простейшая оболочка для восстановления системы

1,

re scue . target

Однопользовательский режим

mul ti-user . target•

Многопользовательский режим ( командная строка)

s, single

2 3

mul ti -user . target•

Многопользовательский сетевой режим

4

mul ti-user . target•

Обычно не используется ini t

5

graphical . target

Многопользовательский сетевой режим с графическим интерфейсом

6

reЬoot . target

Перезагрузка системы

» По умолчанию цель 11ul ti -user . targe t соответствует runlevelЗ . target, многопользовательскому сете­ вому режиму.

П одкоманда i s o l ate н азывается так , потому что она активирует указанную цел ь и е е зависимости , но деактивирует все остальные модул и . В традиционном демоне i n i t для изменения уровней запуска после загрузки с и ­ сте м ы испол ьзуется команда te l i n i t . Некоторые дистрибутивы теперь определя ют telini t как символическую ссылку на команду systemctl. Для того чтобы увидеть цель, к которой система загружается по умолчанию, запусти­ те подкоманду get-defaul t: $ sys temctl ge t-default g r a ph i ca l . t a r g e t

Большинство дистрибути вов Linux загружаются п о умолчанию в модуль graphical . что не подходит для серверов, которы м не н ужен графический и нтерфейс. Но это легко изменить: targe t ,

$ sudo sys temctl set-default mul ti-user . target

Чтобы увидеть все доступные цели с истемы , запустите с исте м н ые списки: $ sys temctl l i s t-units — — type = target

За висимости между модулями П акеты п рогра м м ного обеспечения Linux обычно поставля ются со своим и соб­ стве н н ы м и модул ьн ы м и файлам и , поэтому с истемные адм и нистраторы не н уждаются в подробном знани и всего языка конфигурации . Тем н е менее и м н еобходим ы рабочи е знания с исте м ы зависимостей sys tem.d для диагностики и устранения пробле м с зави­ симостями. Во-первых, не все зависимости являются явными. Менеджер sys temd берет на себя функции старого демона inetd, а также расширяет эту идею в домене межпроцессной системы связи D — Bus. Другим и словами , менеджер sys temd знает, какие сетевые порты или I РС-соединения указывают, где будет размещаться указанная служба, и может про­ слуши вать запросы по этим каналам , не запуская службу. Если клиент выпол няет м ате­ риализацию, с истема просто запускает фактическое обслуживание и отключает соедине­ н ие. Служба запускается , есл и она фактически используется, и остается бездействующей в противном случае.

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

89

Во-вторых. менеджер sys temd делает некоторые предположен ия о нормальном по­ ведении бол ьш и нства видов единиц. Точные предположения варьируются в зависи мости от типа еди н ицы. Например, менеджер systemd предполагает, что среднестатистическая служба является надстройкой , которая не должна запускаться на ранних этапах и н и циа­ лизации системы. Отдельные блоки могут отключать эти допущен ия с помощью строки De f a u l t De p e n de n c i e s ; f a l s e

в разделе [ Un i t ] и х модульного файла; п о умолчан и ю значение равно t ru e . Чтобы уви­ деть точ ные предположен и я , которые применяются к каждому типу модул я , см. спра­ воч ную стран и цу дпя типа sys temd . uni t, ( например. man systemd . service). Третий класс зависимостей — те , которые я вно объявлены в разделе [ Un i t ] модуль­ н ы х файлов. Доступные параметры показа н ы в табл. 2 . 7 . Таблица 2 . 7 . Явные зависимости в разделе [ Unit] модульного файла Параметр

Значение

Wan t s

Модул и , которые должны быть активированы одновременно, если это возможно, н о н е обязательно

Requi re s

Строгие зависимости ; отказ от каких-либо предварительных условий прекращает работу этой службы

Requi s i t e

Аналогично Requi r e s , но модуль должен быть активным

Bindsтo

Аналогично R e qu i r e s , но модуль должен быть связан еще более тесно

PartOf

Аналогично R e q u i r e s , н о вли яет только на запуск и остановку

С on f 1 i с t s

Отрицательные зависимости ; не может взаимодействовать с этими единицами

За искл ючением параметра Co n f l i c t s , все параметры в табл. 2 . 7 выражают основ­ ную идею о том , что настраиваем ы й модуль зависит от некоторого набора других моду­ лей. Точ н ые различия между эти м и параметрами явл яются незнач ительны м и и в первую очередь и нтересн ы разработч икам служб. Когда это возможно, предпочтение следует от­ давать наименее ограничительному варианту, W a n t s . М ожно рас ш ирить груп пу W a n t s или R e qu i r e s , создав файл модул ь ный — ф а йл . wants ил и модуль ный — ф а йл . requires в каталоге /etc/systemd/ sys tem и добавив туда с и м волические ссылки на другие модул ьн ы е файл ы . Еще луч ш е , просто дайте ко­ манде sys temctl сделать это за вас. Например , команда $ sudo sys teшctl аdd-хочет шul ti-user . target my . local . s ervice

добавляет зависимость от модуля my . local . service к стандартной многопол ьзова­ тел ьской цел и , гарантируя , что служба будет запускаться каждый раз, когда система пе­ реходит в м ногопол ьзовател ьски й режим . В большинстве случаев такие специальные зависи мости устанавл иваются автомати­ чески на основе раздела [ I n s t a l l J в модульных файлах. Эгот раздел содержит опции W a n t e d B y и Re q u i r e d B y , которые ч итаются , только если модуль включен с помощью команды systemctl еnаЫе или отключен с помощью команды systemctl disaЫe. При включен и и они заставляют команду sys temctl выполнять эквивалент add-wants для каждой опции W a n t edBy или add-require для каждой опции R e q u i redBy. Раздел ы [ I n s t a l l J сам и по себе н е вл ияют на нормал ьную работу, поэтому, если модуль не запускается , убедитесь, что он правильно подключен и свя за н с сим воличе­ ской ссылкой .

90

часть 1. Основы администрирования

Порядок вы пол нен ия Разумно предположить, что есл и модуль А требует ( R e q u e r e s ) наличия модуля В, то модуль В будет запуще н ил и н астрое н до модуля А. Но на самом деле это н е так . В менеджере sys temd порядок, в котором блоки активируются ( ил и деактивируются), я вляется совершенно отдельным вопросом . Когда система переходит в но1юе состояние, менеджер systemd сначала отслежива­ ет различн ые источ н и ки инфор мации о зависимости , изложен н ые в предыдущем раз­ деле, чтобы определить задействованные модул и . Затем он испол ьзует разделы Be f o r e и A f t e r из модульных файлов, чтобы упорядоч ить с писок зада н и й . Есл и модул и н е имеют разделов Be f o r e или Af t e r , они м о гут быть скорректированы параллел ьно. Это удивительная , но достой ная внимания функция дизайна. Одной из основных целей проектирования менеджера syst8111d было облегчение параллелизма, поэтому логично, что модули не получают зависимостей сериализации, если они явно не запрашивают их. На практике раздел A f t e r испол ьзуется чаще , чем Wa n t s или Requ i r e s . Определе­ н ия цел е й ( и , в ч астност и , обратных зависимосте й , закодирова н н ы х в предложениях W a n t edBy и Requ i redBy) устанамивают общие контуры служб, работающих в каждом рабочем режи м е , а отдельные пакеты беспокоятся тол ько о своих непосредствен н ых и пря м ых зависимостях.

Б ол ее сл ож н ый п ри м ер ф ай л а Теперь внимател ьно рассмотр и м несколько директив, испол ьзуе м ы х в модульных файлах. Вот модул ьн ы й файл дл я веб-сервера NG I N X, nginx . service. [ Un i t ] De s c r i p t i on=The n g i n x Н Т Т Р and r e ve r s e p r o x y s e rv e r A f t e r = n e t wo r k . t a r g e t r emo t e — f s . t a r g e t n s s — l o o kup . t a r g e t [ S e rvi c e ] T ype= f o r k i n g P I DF i l e = / r u n / n g i n x . p i d Exe c S t a r t P re = / u s r /b i n / rm — f / r u n / ng i n x . p i d Exe c S t a r t P r e = / us r / s b i n / n g i nx — t E x e c S t a r t = / u s r / sb i n / ng i n x E x e c Re l oa d= / b i n / k i l l — s H U P $ МAI N P I D K i l lMode= p r o c e s s K i l l S i gn a l = S I GQU I T T ime ou t S t op S e c = S P r i v a t e Tmp= t rue [ Install ] Wante dBy=mul t i — u s e r . t a rge t

Эта служба имеет тип fo r k i n g , что означает, что команда запуска должна завершить­ ся , даже если демон продолжает работать в фоновом режиме. Так как менеджер systemd н е будет не посредственно запускать демона, тот записывает с вой идентификатор P I D ( идентификатор процесса) в указанном P I D Fi l e , чтобы systemd мог определить, какой процесс является ос новным экзе м пл яром демона. Строки Е х е с — это команды для запуска в разл и ч н ы х обстоятел ьствах. Ком а нды E xe c S t a rt P re запускаются до фактического запуска службы ; показанные здесь коман­ ды подтверждают синтаксис конфигурационного файла NG I NX и гарантируют удале ­ н ие л юбого существующе го РI D-файла. Exe c S t a r t — это команда, которая фактически

Глава 2. загрузка и системные демоны

91

запускает службу. Ком анда E x e cRe l o a d сообщает менеджеру sys tem.d, как заставить службу перечитать ее файл конфигурации . (Менеджер system.d автоматически устанав­ ливает переменную среды МAI N P I D в соответствующее значение.) m Дополнительную и нформаци ю о сигналах см. в разделе 4 . 2 . Завершение этой службы обрабатывается через параметры K i l lMode и Ki l l S i gna l , которые сообщают sys tem.d, что демон службы и нтерпретирует с игнал QU I T как и н ­ струкци ю мя очистки и выхода. Строка Exe c S t op = / bi n / k i l l — s H U P $ МA I N P I D

будет и м еть по существу тот ж е результат. Если работа демона не закончится з а коли­ чество секунд, заданных параметром T imeou t S t op S e c , менеджер sys tem.d заставит его прекратить работу с помощью сигнала ТЕRМ, а затем неперехватываем оrо с игнала K I LL. Параметр P r i va t e Tmp попытка повысить безопасность. О н помещает каталог службы / tmp в место, отличающееся от фактического каталога / tm.p, которы й использу­ ется всем и процессами и пользователя м и системы. —

Л окальные службы и настрой ки Как показано в предыдущих п р и мерах, довольно п росто создать модул ь н ы й файл мя домашней службы . Просмотрите примеры в каталоге /usr / l ib/ system.d/ system и адаптируйте их к своим потребностям . Для получ е н и я пол н о го с п и с ка парам е ­ тров конфигураци и служб обратитесь к справочной странице мя sys tem.d . service. Параметр ы , общ и е для всех типов устройств, о писан ы н а с правоч н ой стра н и це sys tem.d . uni t. Поместите свой новы й файл в каталог /etc/ sy s tem.d/ sys tem.. Затем можно запу­ стить команду $ sudo sys temctl еnаЫе custoш . service

мя активации зависимосте й , перечислен н ых в разделе [ I n s t a l l J в служебном файле. Как правило, н е следует редактировать модул ь н ы й файл , написан н ы й не вам и . Вместо этого создайте каталог конфигураци и в каталоге /etc/ system.d/ system./unit­ file . d и добавьте один или несколько файлов конфигураци и , которы е называются ххх . conf. Часть ххх не и меет значен и я ; п росто убедитесь, что файл и меет суффикс . conf и находится в нужном м есте. Имя override . conf я вляется стандартным. Файл ы с рас ш ирени е м . conf имеют тот же формат, что и м одульные файл ы , и на самом деле менеджер sys tem.d с глаживает и х все в месте с исходны м файлом. Однако, если оба источн и ка поп ытаются установить значение одного итого же параметра, пере­ определенные файлы имеют приоритет над исходны м и модул ьн ы м и файлами . Следует иметь в виду, что м ногие параметры менеджера system.d могут отображаться в модул ьном файле более одного раза. В этих случаях множествен н ы е значен и я обра­ зуют список и остаются акти в н ы м и одноврем е н но. Если вы задаете значение в файле override . conf, оно присоединяется к списку, но не заменяет существующие записи. Это может быть н е тем , что вы хотите. Чтобы удалить существующие зап ис и из с писка, просто присвойте параметру пустое знач е н ие , а затем добавьте свой . Рассмотри м пример. Предположим , что ваша организация хранит файл конфигу­ раци и N G I NX в нестандартном месте, напри мер /usr/ l ocal /www / nginx . conf. Вам нужно запустить демон nginx с параметром — с /usr/ local /www / nginx . conf, чтобы он мог найти нужный файл конфигурации .

Часть 1. Основы администрирования

92

Вы н е можете просто добавить эту опцию в файл / u s r / l ib / sys temd / sy s tem/ nginx . service , потому что он будет замен яться каждый раз, когда пакет N G I NX об­ новляется или модифицируется . Вместо этого можно использовать следующую последовател ьность команд. $ sudo mkdir /etc/sys temd/ sys tem/nginx . service . d $ sudo cat > ! $ / override . conf1 2 [ S e rv i c e ] Exe c S t a r t = Ex e c S t a r t = / u s r / s b i n / n g i n x — с / u s r / l oc a l / www / n g i n x . c on f < Ct r l + D> $ sudo sys temctl daemon-reload $ sudo sys temctl res tart nginx . service

Первый параметр E xe c S t a rt= удаляет текущую запись, а второй устанавл и вает ал ь­ тернативную команду запус ка. Ком анда sys temctl daemon-reload осуществляет по­ вторн ы й синтаксический разбор модульн ых файлов. Тем н е менее она не перезапускает демоны автоматически , поэтому вам придется по­ вторно выполн ить команду systemctl , чтобы изменения вступил и в силу немедленно. Эта последовател ьность команд представляет собой настол ько расп ространенную идиому, что менеджер systemctl теперь реализует ее непосредствен но: $ sudo sys temctl edi t nginx . service

$ sudo sys temctl res tart nginx . service

Как уж было сказано, вам все равно придется перезапустить менеджер вруч ную. П оследнее, что нужно знать о переопределяемых файлах, закл ючается в том , что он и не могут изменить раздел [ I n s t a l l ] модул ьного файла. Л юбые сделан н ые вам и изме­ нения молча и гнорируются. Просто добавьте зависимости напрямую с помощью команд systemctl add-needs или systemctl add-require.

Предостережения об уп равлен и и службами и запус ком П р и м е н е н ие м е н еджера sys temd имеет много архитектурн ых последстви й , и е го адаптация — не простая задача для разработчи ков дистрибути вов Linux. Текущие в ы ­ пуски — это в основном систе м ы Франке н штейна, которые используют большую часть с истем ы , но также сохраняют несколько ссылок на прошлые верс и и . И ногда старые верси и просто еще не полностью преобразованы . В других случаях для обл е гчения со­ вместимости был и оставлены различные форм ы устаревшего кода. Хотя менеджер sys temctl можно и нужно испол ьзовать для управления службам и и демонам и , н е уди вительно, если вы д о с их пор запус каете традицион н ы е сценарии ini t или связан ные с ними вспомогательные команды. Если в ы попытаетесь использо­ вать менеджер systemctl Д/I Я откл ючен ия сети в системе CentOS или Red Hat , напри­ мер, вы получите следующий вывод. $ sudo sys temctl di s aЫe network n e t w o r k . s e rv i c e i s n o t а n a t ive s e rvi c e , Exe c u t i ng / s b i n / ch k c on f i g n e t wo r k o f f

r e d i r e c t i n g to / s b i n / ch k c on f i g .

1 2 С и мвол ы > и ! $ это метасим волы обол очки . С и м вол > переадресовы вает вывод в файл , а дей ствие с и мволов ! $ рас п ространяется до последнего компонента п редыдущей команд н ой строки , так что вам не нужно его повторно вводить. Все обол очки понимают эти обозначени я . Информацию о некоторых других удобн ых функциях см . в раздел е 7 . 2 . —

Глава 2. Загрузка и системные демоны

93

W Дополнительную информацию о службе Apache см. в разделе 1 9 . 3 . Традиционные сценар и и и н ициализации часто продолжают функционировать в с и ­ сте ме sys temd. Н а п р и м е р , сценар и й инициализации / e t c / r c . d/ in i t . d/my — o l d ­ s e rv i c e м ожет б ыть автоматически сопоставл е н с модул ь н ы м файлом , так и м как my -old- service . servi ce , во врем я и н и циализации с истем ы или при выполнении команды systemctl daemon-reload. Примером я вляется служба Apache 2 н а Ubuntu 1 7.04: попытка откл ючить apache2 . service приводит к следующему выводу. $ sudo sys temctl di saЫe apache2 S y n c h r on i z i n g s t a t e o f a p a c he 2 . s e rvi c e w i t h S ys V s e rv i c e s c r i p t wi t h / l iЬ / s y s t emd / s y s t emd — s y s v — i n s t a l l . E x e c u t i n g : / l i Ь / s ys t emd/ s y s t emd- s y s v — i n s t a l l di s aЫ e a p a ch e 2

Конечный результат соответствует тому, что вы хотели , н о процесс проходит доволь­ но окольным путем . В системах Red Hat и CentOS все еще запус кается сценарий /etc/rc . d/ rc . l o c a l во вре м я загруз к и , есл и в ы настроите е го на в ы п ол н е н и е . 1 3 Теоретически можно испол ьзовать этот сценарий для взлома уязвимостей сайта или загрузки задач , если это необходимо. (На данн ы й момент, однако, вам нужно проигнорировать хакерские возможности и сделать что-то полез­ ное в системе, создав соответствующий набор файлов модулей.)

RHEL

Н екоторые задачи загрузки систем Red Hat и CentOS продолжают использовать кон­ фигурационн ы е файл ы , найденные в каталоге /etc/ sysconfig. Эти данные приведен ы в табл . 2 . 8 . Таблица 2 . 8 . Файлы и подкаталоги каталога Red

Hat

/etc/ sysconfig

Файл или каталоr

Содержимое

console/

Каталог, который исторически допускал настраиваемое сопоставление клавиш

crond

Аргументы для п ерехода к демону crond

ini t

Конфи гурация дл я обработки сообщений из сценариев запуска

iptaЫe s — config

Загружает дополнительные модул и ip taЫ e s , такие как NАТ- помощники

ne twork — s crip ts/ Сценарии аксессуаров и сетевые файлы конфи гураци и nfs

Необязател ьные аргументы RPC и N FS

ntpd

Параметры командной строки ntpd

s e linux

Символ ическая ссылка на каталог / etc/ sel inux/ config»

• устанавливает аргументы для системы SELinux или позволяет полностью отключить ее; см. раздел 3.4.

Пара пунктов табл . 2 . 8 заслуживают допол нительного комментария. •

Каталог сетевых сценариев содержит допол н ительные м атери ал ы , относящиеся к сетевой конфигурации . Единственное, что вам может понадобиться измен ить здесь, — файлы с именем ifcfg-interface. Например, файл network-scripts/ i fcfg-ethO содержит параметры конфигурации для интерфейса eth O . Он уста­ навливает I Р-адрес и сетевые параметр ы интерфейса. Дополнительная информа­ ция о настройке сетевых интерфейсов приведена в разделе 1 3 . 1 О. Файл iptaЫ e s — config фактически н е позволяет изменять правила iptaЬles (брандмауэра) . Это просто с пособ загрузки допол н ительных модул е й , таких как

1 1 Быстрая команда sudo chmod +х /etc/rc . d/rc . local гарантирует, что файл будет исполняться.

Часть 1. основы администрирования

94

трансляция сетевых адресов ( NAT) , есл и вы собираетесь пересылать пакеты или испол ьзовать с истему в качестве маршрутизатора. Допол н ител ьная и нформация о настройке iptaЫes содержится в разделе 1 3. 1 4.

Жу рнал sys temd Фиксация сообщен и й в журнале, созданных ядром , всегда был сложной задачей. Она стала е ще более важной с появлен и е м виртуальных и облач ных систе м , поскольку не­ возможно просто стоять перед консолям и этих систем и следить за тем , что происходит. Часто важнейшая диагностическая информация терялась в эфире. Менеджер systemd устраняет эту проблему с помощью универсальной структуры ве­ дения журнала, которая включает все сообщения ядра и службы от начал ьной загрузки до окончательного завершения. Этот объект, называем ы й журналом , управляется демо­ ном j ournald. Систе м н ые сообщен и я , зап иса н н ы е журналом , хран ятся в каталоге / run . Демон rsyslog может обрабаты вать эти сообщения и хранить их в традиционн ых файлах жур­ налов или пересыл ать их на удал е н н ы й сервер syslog. Можно также напрямую обра­ щаться к журналам с помощью команды j ournalctl. Без аргументов команда j ournalctl выводит все записи журнала (начиная с сам ых старых) . $ j ournalctl — L o g s b e g i n at F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 0 1 : 2 5 UTC , e n d at F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 0 5 : 1 6 uтс . — F e b 2 6 1 5 : 0 1 : 2 5 ubun t u s y s temd — j o u r n a l [ 2 8 5 ] : Run t ime j ou rn a l i s u s i n g 4 . 6М ( ma x a l l owed 3 7 . ом, t Feb 2 6 1 5 : 0 1 : 2 5 ubunt u s y s t emd- j ou r na l [ 2 8 5 ] : Run t ime j ou r n a l i s u s i n g 4 . 6М ( ma x a l l owed 3 7 . ОМ , t Feb 2 6 1 5 : 0 1 : 2 5 ubun t u k e r ne l : I n i t i a l i z i n g c g roup s ub s y s cpu s e t F e b 2 6 1 5 : 0 1 : 2 5 ubuntu k e r ne l : I n i t i a l i z i n g c g roup s u b s y s cpu Feb 2 6 1 5 : 0 1 : 2 5 u b u n t u k e r n e l : L i nux ve r s i on 3 . 1 9 . 0 — 4 3 — g e n e r i c ( bu i l d d @ l c y O l — 0 2 ) ( gc c ve r s i o n 4 . Feb 2 6 1 5 : 0 1 : 2 5 ubuntu k e r n e l : C ommand l in e : BOOT_ I МAGE= / b o o t /vml i n u z 3 . 1 9 . 0 — 4 3 -gene ric root=UUI Feb 2 6 1 5 : 0 1 : 2 5 u b u n t u k e r ne l : KERNEL s u pp o r t e d cpus : F e b 2 6 1 5 : 0 1 : 2 5 ubun t u k e r ne l : I nt e l Genui n e i n t e l

Можно настроить демон j ournald для сохранения сообщен и й из предыдущих загру­ зок. Для этого отредактируйте файл /etc/ systemd/ j ournald . conf и н астройте атри ­ бут S t o r a g e : [ Journa l ] St orage=pe r s i s tent

Изменив конфигурацию демона j ournald, вы получите список приоритетных загрузок. $ j ournalctl —lis t-boots

— 1 a 7 3 4 1 5 f a de 0 e 4 e 7 f 4 b e a 6 0 9 1 3 8 8 3 d l 8 0dc F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 0 1 : 2 5 UTC F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 0 5 : 1 6 UTC О O c 5 6 3 f a 3 8 3 0 0 4 7 e c a a 2 d 2 b 0 5 3 d4 e 6 6 l d F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 1 1 : 0 3 UTC Fri 2 0 1 6 — 0 2 — 2 6 1 5 : 1 2 : 2 8 uтс

Зате м можно получать доступ к сообщен и я м из предыдущей загрузки , ссылаясь на свой и ндекс или длинный идентификатор.

Глава 2. Загрузка и системные демоны

95

$ j ournalctl -Ь -1 $ j ournalctl -Ь a7 3 4 1 5fade0 e4e7f 4bea6 0 9 1 3 8 8 3d1 8 0 dc

Для того чтобы ограничиться кон кретны м модулем , используйте флаг -u. $ j ournalctl -u ntp — — L o g s b e g i n at F r i 2 0 1 6 — 0 2 — 2 6 1 5 : 1 1 1 5 : 2 6 : 0 7 uтс . — F e b 2 6 1 5 : 1 1 : 0 7 ub — t e s t — 1 s y s t ernd [ l ] : Feb 2 6 1 5 : 1 1 : 0 8 ub — t e s t — 1 s y s t e rnd [ l ] : Feb 2 6 1 5 : 1 1 : 0 8 ub — t e s t — 1 n t p [ 7 6 1 ] : *

: 0 3 UTC , e n d a t F r i 2 0 1 6 — 0 2 — 2 6 S t opped L S B : S t a r t N Т Р d a emon . S t a r t i n g L S B : S t a r t N Т Р d a emon S t a r t i n g N T P s e rve r n t p d

.

.

.

Ведение журнала sys temd более подробно описано в главе 1 О.

2 .8. СЦЕНАРИИ ИНИЦИАЛИЗАЦИИ и З А ПУС К А СИСТЕМЫ FREEBSD Система Free B S D использует и н ициал изацию в стиле B S D , который н е поддержи­ вает концепцию уровней выполнения. Чтобы привести систему в пол ностью загружен ­ н о е состояни е , и н ициал изация Free BSD запускает программу /etc/rc. Эта программа является сценарием оболоч к и , но ее нельзя изменять напрямую. Вместо этого система rc реал изует несколько стандартных с пособов расш ирения систе м ы запус ка и измене­ ния конфигураци и , доступных для систе м н ы х адми н истраторов и пакетов п рогра м м ­ ного обеспечения. Ш И нформацию о сценариях оболочки см . в главе

7.

Прежде всего , /etc/rc — это оболочка, которая за пус кает другие сценарии , боль­ ш инство из которых н аходятся в каталогах /u s r / l o ca l / e t c / rc . d . и / e tc / rc . d. Однако, прежде чем запускать любой из этих сценариев, с истема ro выпол няет три фай­ ла, которые содержат информацию о конфигурации мя системы. •

/etc/defaults/config

/ etc/ rc . conf

/etc/rc . conf . local

Эти файлы сами я вляются сценариям и , но обычно они содержат тол ько определения значений переме н н ых оболочки. Затем сценар и и запуска проверяют эти пере м е н н ые , чтобы определить, как вести себя дальше. ( Программа /etc/rc использует некоторые средства оболочки, чтобы гарантировать, что переменные, определен ные в этих файлах, будут видны повсюду. ) Ш Дополн ительную информацию о сценариях оболоч ки см . в глав е 7 . В файле /etc/defaul t s / rc . conf перечислены все параметры конфигурации и их настройки по умолчанию. Н икогда не редактируйте этот файл , чтобы сценарий и ници­ ализации не перезаписал ваш и изменения при следующем обновлен и и с истемы. В место этого просто переопределите значен и я по умолчан и ю , установив их с нова в файлах /etc / rc . conf или /etc/rc . conf . local . На справоч ной странице rc . conf и меется обширный список переменных, которые можно задать . Теоретически файлы rc . conf могут также содержать имена других каталогов, в ко­ торых для запуска сценариев м ожно установить значение переменной local s tartup. _

Часть 1 . основы администрирования

96

Значение по умолчан и ю /usr/local/etc/rc . d, и м ы рекоме ндуем оставить е го не­ изме н н ы м . 1 4 Загл я нув в файл / e t c / r c . d, м ожно увидеть , что существует м н ожество разл и ч ­ н ы х сценариев запуска, в стандартной установке их более 1 50 . Файл / e t c / r c запу­ с кает эти сце нар и и в порядке , определе нном командой rcorder, которая считывает сценар и и и и щет информацию о зависимостях, которая была закодирована стандарт­ н ы м образо м . Сценарии запуска Free B S D для разнообразных служб довольно просты . Например, верхняя часть сценария запуска s shd выглядит следующим образом : —

# # # #

! / Ьi n / s h PROVI D E : s s hd REQU I RE : LOG I N F I L E S Y S T EMS KEYWORD : s h u t d own /etc/rc . subr name= » s s hd » r c v a r = » s s h d е n аЫ е » c omma nd= » / u s r / s Ь i n / $ { n ame } «

П еремен ная r cvar содержит и м я пере м е н ной , которая должна быть определ е н а в одном из сценариев rc . conf’, в данном случае s shd enaЬle. Если вы хотите , что­ бы для автоматического запуска во время загрузки использовался демон s shd ( реаль­ ный демон, а н е с ценарий запуска, хотя оба называются sshd) , поместите в файл /etc/ rc . conf’ строку: _

s s hd е n а Ы е = » Y E S «

Если эта переменная и меет значение «NO» или закомментирована, сценарий s shd не за­ пускает демон или не проверяет, следует л и его останавливать при выключении системы . Команда servioe обеспечивает интерфейс реального времени в с истеме rc . d опера­ ционной систе м ы Free B S D . ‘ 5 Н апример, чтобы остановить службу sshd вруч ную, можно запустить команду $ sudo service s shd s top

Обратите внимание: этот метод работает тол ько в том случае , есл и служба указана в файлах /etc/rc . conf’. Если это не так, используйте подкоманды onestop, onestart или onerestart, в зависимости от того, что вы хотите сделать. ( Команда service , как правило, напомнит вам об этом, есл и это необходимо.)

2 .9. ПРОЦЕДУРЫ ПЕРЕЗАГРУЗКИ И ВЫКЛЮЧЕНИЯ И сторически сложилось так, что маши н ы U N IX и Linux очень строго регламе нтиро­ вал и процесс выкл ючения. Современные с исте м ы стали менее чувствител ьн ы м и , осо­ бенно если испол ьзуется надежная файловая система, но всегда полезно выключ ить ма­ шину, когда это возможно.

1 4Для л окал ьны х настроек можно л и бо создать стандартные сценари и в стиле rc . d, которые находятся в каталоге /usr/local/etc/rc . d, либо редактировать общедоступный сценари й /etc/ rc . local . Первый вариант предпочтител ьнее. 1 5 Версия с л ужбы , которую и с п ользует с и стема Free B S D , осн овы вается на команде s e rvi ce в системе Liпux, которая управляет тради ционн ы м и службам и ini t .

Глава 2. Загрузка и системные демоны

97

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

Выкл ючение физических систем Основные обязанности, необходимые для закрытия с исте м ы , вы пол няет команда hal t. Она регистрирует выкл ючение , прекрашает несуществен н ые процесс ы , сбрасыва­ ет кеш ирова н н ые блоки файловой с исте м ы н а диск и останавливает ядро. В большин­ стве с истем команда hal t -р начинает процесс выключения с истемы. Команда reboot по существу идентична команде hal t , но она заставляет маш и н у перезагружаться , а не останавл иваться. Команда shutdown — это надстройка над команда м и hal t и reboot, которая обе­ спечи вает заплан ирован ные выключения и выдачу тревожн ых предупрежден и й для за­ регистрированных пользователей. Она восходит к эпохе систем разделения времен и и в настоящее время в значительной степен и устарела. Команда shutdown не делает ничего важного, кроме выпол н е н ия команд hal t или reboot, поэтому ее можно не испол ьзо­ вать, если у вас нет м ногопол ьзовательских систе м .

Выключение облачных систем Можно остановить или перезапустить облачную систему л ибо с сервера (с помощью команды halt ил и reboot, как описано в предыдущем разделе ) , либо с помощью веб­ консоли поставшика облачных выч ислен и й ( ил и эквивале нтного и нтерфейса A P I ) . Вообще говоря , отключение систе м ы с помошью облачной веб-консоли сродн и от­ ключению питания. Л уч ш е , есл и виртуальный сервер будет управлять собствен н ы м вы­ ключе н и е м , но если он перестает отвечать н а запрос ы , все что вам остается — откл ю­ ч ить е го с помошью веб-консол и . Что еще можно сделать? В любом случае убедитесь, что вы понимаете , что означает выключение с точ ки зре­ ния поставщика облака. Б ыло бы очень обидно уничтожить ваш у систему, когда вы хо­ тели всего л и ш ь перезагрузить ее. В среде AWS операции S top и ReЬoot делают именно то, что вы ожидаете. Команда Terminate деактивирует экзем пляр и удаляет его из памяти . Есл и для базового устрой­ ства хранения установлено значение d e l e t e o n t e rm i n a t i o n (удалить при заверше­ нии) , будет ун ичтожен не тол ько ваш экзем пляр, но и дан ные на корневом диске . Все хорошо, если вы хотели сделать именно это. Если же вы считаете , что это плохо, можно включить параметр t e rm i n a t i o n p r o t e c t i o n (защита завершения) .

2.1 о. Что ДЕЛАТЬ, ЕСЛИ СИСТЕМА НЕ ГРУЗИТСЯ? М ножество п робл е м может помешать загрузке систе м ы , нач и н ая от неисправн ых устройств и заканч и вая обновле н и я м и ядра . Сушествует три основных подхода к этой ситуаци и, перечисленные здесь в порядке нежелател ьности.

Часть 1. Основы администрирования

98 • •

Не отлаживать; просто верн ите систему в хорошо известное состоя н ие. Довести с истему до уровня , достаточного для запус ка оболочки и отладки в и нте ­ рактивном режиме. Загрузить отдел ьн ы й с исте м н ы й образ , смонтировать файловые систе м ы неис­ правной с истемы и исследовать е го.

Первый вариант наиболее часто используется в облаке , но он может быть полезе н и на физических серверах, если у вас есть доступ к последнему образу всего загрузочного дис­ ка. Если ваша организация делает резервные копи и файловой систе м ы , восстановление все й систе м ы может создать больше проблем , чем хотелось бы. М ы обсуждаем вариант восстановлен ия все й системы в режиме восстановлен ия облачных систем немного ниже. В оставшихся двух подходах ос новное внимание уделяется предоставлению вам до­ ступа к с исте м е , определ е н и ю основной пробл е м ы и исправл е н и ю любых пробл е м . Загрузка неисправной систе м ы в оболочку на сегодн я ш н и й де н ь я вляется предпочти ­ тел ьным вариантом , но проблем ы , которые происходят на ранн и х этапах загрузки , мо­ гут привести к н арушению этого подхода. Режим » загрузка в оболочку» известен как однопол ьзовател ьский режим или режи м с пасения ( rescue mode) . Систе м ы , которые используют менеджер sys temd, имеют еще более примитивный вариант, доступный в форме аварий ного режима (emergency mode) ; он концептуально похож на однопол ьзовательский режи м , но делает абсол ютн ый мини­ м ум работы перед запуском оболочки. П оскол ьку однопол ьзовател ьский режи м , режи м спасе н ия и авар и й н ы й режи м не настраивают сеть и не запус кают связанн ые с сетью службы , обычно, чтобы их исполь­ зовать, н еобходим физический доступ к консол и . В результате одн опользовательский режим обычно н едоступен для облачных с исте м . Мы рассмотрим н екоторые варианты восстановления испорче н н ых облач н ых образов чуть н иже.

Однопользовател ьский режим В однопользовательс ком режиме , также известном как rescue . target, для систе м , использующих менеджер sys temd, запускается только м и н и мал ьн ы й набор процессов, де монов и служб. Корневая файловая система смонтирована ( как правило, / u s r ) , но сеть остается неини циал и зированной. Во врем я заrрузки вы запраши ваете однопол ьзовател ьский реж и м , передавая аргу­ мент ядру, обычно s ingle или — s . Это можно сделать с помощью интерфейса команд­ ной строки загрузчика. В некоторых случаях он может быть настроен автоматически в качестве опции м е н ю загрузки. Если с истема уже запущена, ее можно перевести в однопол ьзовател ьский р е ­ жим с помощью команды shutdown ( Free B S D ) , tel ini t (традицион н ы й ini t) ил и systemctl ( systemd). Ш Дополнительную информацию об учетной записи root см. в главе 3 . Системы Sane перед запуском однопользовательской корневой оболочки запрашива­ ют корневой парол ь. К сожалению, это означает, что сбросить забыты й корневой пароль в однопол ьзовательском режиме практически невозможно. Если вам нужно сбросить па­ роль, придется получить доступ к диску с помощью отдельного загрузочного носителя. Ш Допол нительную информацию о файловых системах и монитори н ге см. в главе 5. де

И з однопользовательс кой оболоч ки можно выпол нять команды так же , как при вхо­ систему с полной загрузкой . Однако и ногда монтируется только корневой раздел ;

в

Глава 2. Загрузка и системные демоны

99

чтобы испол ьзовать программ ы , которые не находятся в каталогах /Ьin, / sЬin или /etc, н еобходимо смонтировать другие файловые с исте м ы вручную. Ч асто можно н айти указател и на доступные файловые с исте м ы , просмотрев ка­ талог /etc/ f s tab . В с исте м е Linux можно выпол нить команду fdi s k -1 (буква L в н ижнем регистре) , чтобы п росм отреть с писок разделов диска локальной с исте м ы . Аналогичная процедура для с истемы Free B S D заключается в том , чтобы выпол н ить ко­ манду camcontrol devlist для идентификации дисковых устройств, а затем — коман­ ду fdi sk -s устройств о для каждого диска. Во м ногих однопол ьзовательских средах корневой каталог файловой систе м ы начи­ нает монтироваться в состоян и и » только дл я чте н ия » . Е сли каталог /etc является ча­ стью корневой файловой с исте м ы (обы ч н ы й случай ) , то будет невозможно редактиро­ вать многие важные файлы конфигурации . Чтобы устранить эту проблему, необходимо начать сеанс в одн опользовательс ком режиме, перемонтировав каталог в режиме чтения и записи. В системе Linux этот трюк обычно в ыпол няет команда # mount -о rw , remount /

В системах FreeB S D возможность повторного подключен и я я вляется неявной , когда вы повторяете монтирование, но н еобходимо явно указать исходное устройство. Например, # mount — о rw /dev/qpt/rootfs /

RHEL

Однопользовательский режим в системах Red Hat и CentOS нем ного более агресс и ве н , чем обычно. К моменту достижения командной строки эти си­ сте м ы уже п ытались п одключить все локальные файловые систе м ы . Хотя это умолчание обыч н о полезно, при несnравной файл овой системе могут возникнуть проблемы . В этом случае можно загрузиться в аварийном режи­ ме, добавив команду systemd . uni t=emergency . target к аргуме нтам ядра из загрузчи ка {обычно G RU B) . В этом режиме локальные файловые с исте­ мы н е монтируются и запускается всего несколько основных служб.

m Для получения дополнительной информаци и о файловых системах и их монтировании см. главу 5.

Команда fsck запускается во время обычной загрузки для проверки и восстановле­ н и я файловых с исте м . В зависимости от того, какую файловую с истему вы используе­ те для корневого каталога, вам может потребоваться запустить fsck вручную, когда вы подключаете с истему в однопол ьзовательском или аварийном режим е . Для получ е н ия более подробной и нформации о команде fsck обратитесь к разделу 20. 1 0. Однопользовательский режим — это просто точка на обычном пути загрузки , поэтому можно выйти из однопользовательской оболочки, введя команду exi t или нажав клави­ ш и < Ct rl + D > , чтобы продолжить загрузку. Вы также можете н ажать клавиши < Ct rl + D > в момент запроса пароля, чтобы полностью обойти однопользовательский режим.

Однополь зовател ь ск и й режим в с истеме FreeBSD Система Free B S D включает одноnользовател ьский вариант в меню загрузки. 1 2 3 4

. . . .

B o o t Mul t i U s e r [ En t e r ) Boot S ingle U s e r E s c a p e t o l o a d e r p r omp t Reboot

Часть 1. Основы администрирования

1 00 Op t i on s 5 . K e r n e l : d e f a ul t / ke rn e l ( 1 o f 2 ) 6 . C o n f i g u r e B o o t Op t i o n s . . .

Одна приятная особен н ость однопользовател ьскоrо режима в Free BS D заключается в том , что он спрашивает, какую проrрам му ис пользовать в качестве оболочки. П росто нажм ите < Enter> для оболоч ки /bin/ sh. Выбрав вариант 3, вы переЙдете в среду командной строки заrрузоч ного уровн я , реа­ лизованную финал ьн ы м загрузчи ком Free B S D loader.

Однополь зов ательски й режим с з а г ру зч и ком G R U B В системах, испол ьзующих менеджер systemd, можно заrрузиться в режиме восстановле н и я , добавив команду systemd . uni t=rescue . target в коне ц существующей строки ядра Linux. Чтобы измен ить параметры заrрузки, вы­ дел ите нужное ядро на заставке G R U B и нажмите клавишу . Аналогично для загрузки в авари йном режи м е испол ьзуйте команду sys temd . uni t= emergency . target. Вот пример ти пич ной конфигурации: l i nux l 6 /vml i nu z — 3 . 1 0 . 0 — 2 2 9 . e l 7 . x 8 6_ 6 4 r o o t = / dev /mapp e r / rhel_rhe l — r o o t r o c r a s h ke rn e l = a u t o rd . lvm . l v= r h e l _ r he l / swap rd . lvm . lv= rhel_rh e l / r o o t r h g b qu i e t LANG= en_U S . UT F — 8 s y s t e md . uni t = r e s cue . t a rg e t

Для того чтобы запустить систему после внесения изменен и й , нажм ите .

В ос становл е ние облачн ых си стем И з-за п р ироды облач н ы х с исте м н е возможно под кл юч ить м о н итор ил и U S В­ накопитель при возникнове н и и проблем с загрузкой . Облач ные провайдеры делают все возможное , чтобы облегчить решение проблем, но основные ограничения остаются . W Дл я более ши рокого ознакомления с облач ными вычислениями см . главу 9 . Резервные коп и и важны для всех систе м , н о для облач н ы х серверов сделать такую копи ю очень просто. П ровайдеры взимают допол нительную плату за резервные копии, но они н едороги. Чаще создавайте образы (snapshot) и вы всегда будете и меть разум н ы й систе м н ы й образ, чтобы вернуться к н е м у в короткие сроки. С философской точк и зрения вы, вероятно, ошибаетесь, есл и ваш им облачн ы м сер­ верам требуется отладка при загрузке . Н е исправные физические серверы можно срав­ н ить с домаш н и м и животн ы м и , которых лечат, есл и они заболели , но больной круп ­ н ы й рогатый скот не лечат, а просто заби вают. Ваш и облачн ые серверы — это крупн ы й рогат ы й с кот; есл и о н и плохо работают, зам е н ите и х заведомо рабоч и м и коп и я м и . Испол ьзование этого подхода помогает не только избежать критических сбоев, н о и об­ легчает масштабирование и м и rрацию системы. Тем не м е н ее вам н еизбежно придется попытаться восстановить облачн ы е систе м ы ил и диски, поэтому м ы кратко обсудим этот процесс н иже. В рамках AWS однопользовател ьские и аварийные режим ы недоступны. Однако файловые системы ЕС2 могут быть подключен ы к другим виртуальным серверам , если они поддержи­ ваются устройствами Elastic Block Storage ( EAS). Эrо значение по умолчани ю установлено для большинства экзем пляров ЕС2, поэтому вполне вероятно, что при необходимости вы

Глава 2. Загрузка и системные демоны

1 01

сможете использовать этот метод. Понятно, что это похоже на загрузку с U S В-накопителя, так что можно сориентироваться на загрузочном диске физической системы. Вот что надо сделать. 1 . Запустите новый экзем пляр в области видимости экзем пляра, с которым возник­ л и п роблемы. В идеале этот экзе м пляр восстановления должен запускаться с од­ ного и того же базового образа и использовать тот же тип экзе м пляра, что и неис­ правная система.

2 . Остановите проблематичный экзе м пляр. ( Но будьте осторож н ы , чтобы не вы пол ­ н ить операцию t e rтi n a t e , потому что она удаляет образ загрузочного диска.) 3 . С помощью веб- консол и AWS или CLI отсоедин ите том от проблемной систем ы и присоедин ите его к системе восстановления . 4 . Войдите в систему восстановления. Создайте точ ку монтирования и смонтируйте том , а затем сделайте все , что необходимо для устране н и я пробл е м ы . Затем от­ ключите том . (Не выходит? Убедитесь, что вы не н аходитесь в одном из каталогов этого тома.)

5 . В консол и AWS отсоедин ите том от экзе м пляра восстановл е н и я и подкл юч ите его к п роблемати чному экземпляру. Запустите п робле матич н ы й экзе м пляр и на­ дейтесь на лучшее. Дроплеты компании DigitalOcean предлагают консоль с поддержкой VN C , к которой можно получить доступ через И нтернет, хотя использовать неб-приложения в некоторых браузерах довольно неудобно. Компания DigitalOcean н е предоставляет возможности от­ соединить устройства хране ния и перенести их в систему восстановле ния, как это делает Amazon . В место этого большинство систем н ых образов позволяют загружаться с ал ьтер­ нативного ядра восстановления. Чтобы получ ить доступ к ядру восстановления, сначала откл юч ите дроплеты , а затем смонтируйте ядро восстановления и перезагрузитесь. Если все пойдет хорошо, виртуаль­ ный терминал предоставит вам доступ к однопользовател ьс кому режиму. Более подроб­ н ы е инструкции для этого процесса доступны на сайте d i g i t a l o c e a n . сот. П робл е м ы с загрузкой в экземпляре Google Compute Engi ne сначала должны быть исследованы путем изучения и нформации о последовательном порте экзе м пл яра: $ gcloud compute instances get- serial -port-output экземпляр

Такую же информацию можно получить через веб-консоль G C P. П роцесс перемеще н ия диска, аналоги ч н ы й описанному в ы ш е дл я облака Amazon, также доступен в Google Compute Engine. В ы используете CLI для удал е н и я диска из н еработающего экзем пляра и загрузки нового экзе м пляра, которы й монтирует диск в качестве дополн ительной файловой системы. Затем можно запускать проверки файло­ вой систе м ы , изменять параметры загрузки и при необходимости выбирать новое ядро. Этот процесс подробно описан в докуме нтации Google по адресу c l o u d . g o o g l e . сот/ c oтpu t e / do c s / t r o uЬ l e s h o o t i n g .

Глава

3

Управление д ос т уп ом и привилегии суперпользователя

Эта глава посвящена контролю доступа, под которым , в отличие от кон цепции без­ опасности , мы подразумеваем механ изм принятия реш е н и й , связанных с безопасно­ стью, реализуемый ядром и его делегатами. В главе 27 , посвященной безопасности , рас­ сматривается более общий вопрос о том , как настроить систему или сеть, чтобы свести к м и нимуму вероятность нежелательного доступа злоум ы шленников. Контроль доступа — это область активных исследований, которая уже давно я вляется одной из главных проблем разработки операционных с исте м . За последнее десятилетие мир U N I X и Liпux пережил кембрийск и й взр ы в новых возможностей в этой области . П ервич н ы м драйвером этого всплеска стало появление АРl — интерфейсов ядра, которые позволяют сторонни м модулям увеличивать или заменять традиционную систему управ­ ления доступом U N IX. Этот модульный подход создает м ножество новых возможностей ; контрол ь доступа теперь так ж е открыт для изменений и экспериментов, как и любой другой аспект U N IX. Тем не менее традицион ная система остается стандартом U N IX и Liпux, и она подхо­ дит для большинства установок. Даже системные адм и нистраторы , которые хотят вы йти на новые рубежи , должны овладеть основами .

Часть 1. Основы администрирования

1 04

3 . 1 . СТАНДА РТНОЕ УПРАВЛЕНИЕ ДОСТУПОМ в U N IX Стандартная модел ь контроля доступа в системе U N IX в течение десятилети й прак­ тически не измен илась. С н екоторы м и усовершенствованиями она по-прежнему я вля­ ется стандартной дл я распространенных дистрибутивов операционн ы х с исте м . Схема соответствует таким основны м правилам . •

Решения по управлению доступом зависят от того, какой пользователь п ытается в ы пол н ить операцию или в не которых случаях от членства этого пол ьзователя в группе U N IX.

Объекты (например, файл ы и процессы) имеют владельце в. Владельцы имеют ши­ роки й (но не обязательно неогран ичен н ый) контроль над своим и объектами.

Вы являетес ь владельцам и создаваем ых вами объектов.

Специал ьная учетная запись пользователя под названием root может действовать как владелец л юбого объекта.

Тол ько пол ьзовател ь root может выпол н ять особо важн ые адм и н истративные операции. 1

Некоторые систе м н ы е вызовы ( например, settimeofday) ограничен ы при вилегия­ м и пользователя root; реал изация просто проверяет подл и н ность те кущего пол ьзова­ теля и отклоняет операцию, есл и пользователь не является привилегированным (root) . Другие систе м н ы е вызовы ( например, k i l l ) реализуют различные выч ислен и я , кото­ рые включают как сравнение прав собственности , так и проверку специальных услови й для пол ьзователя root. Н аконец, файловые систе м ы и меют свои собственные системы управл е н и я доступом , которы е они реал изуют в сотрудничестве с уровнем ядра VFS . О н и , к а к правило, более слож н ы , чем эл е ме нты управления доступом в других местах ядра. Например, файловые системы гораздо чаще используют групп ы U N IX для контро­ ля доступа. Усложнение этой картины состоит в том , что ядро и файловая с истема тесно пере­ плетаются. Например, вы управляете и общаетесь с большинством устройств через фай­ л ы , которые п редставляют и х в каталоге /dev. П оскол ьку файл ы устройств я вляются объектами файловой с исте м ы , они подчиняются семантике управления доступом к фай ­ ловой системе. Ядро испол ьзует этот факт в качестве основной формы контроля доступа для устройств. m Дополнительную и нформацию о файлах устройств см. в разделе 5.4.

Ко нтр ол ь д о сту па к ф а й л о в о й с и сте ме В стандартной модели каждый файл имеет как владельца, так и группу, иногда назы­ ваемую » групповым владельцем » . Владелец может устанавливать разрешения для файла. В частности, владелец может установить их настолько о граничительно, что н и кто другой не сможет получить к нему доступ. М ы бол ьше говори м о разрешениях файлов в главе 5 (см. раздел 5 . 5 ) .

1 И мейте в виду, что м ы здесь описываем оригинальный диза й н с истемы контр оля доступа. В наши дни не все эти утвержден и я остаются истинными в буквальном смысле. Напри мер, процесс Liпux, который имеет соответствующие возможности (см . раздел 3 . 3 ) , теперь может вы полнять н екоторые опера ц и и , которые ранее были огра н и чены только компетенцией пользователя root.

Глава 3. Управление доступом и привилегии суперпользователя

1 05

Хотя владельцем файла все гда я вляется оди н человек , многие могуr быть владел ьца­ ми файлов, если они все являются частью одной групп ы . Группы традиционно опреде­ ля ются в файле /etc/group, но в настоящее время и нформация о группе часто сохра­ н яется в системе сетевых баз данных, такой как LDAP; для получения допол нительной и нформации см. главу 1 7 . m Для получения дополнительной и нформации о группах см. раздел 8 . 5 . Владелец файла определяет, что могут сделать с н им чле н ы групп. Эта схема позволя­ ет дел иться файлами между членами одного и того же проекта. Владел ьца файла можно определить с помощью команды l s — 1 : $ l s — 1 �qarth/ todo

— rw- r — — — — — 1 g a r t h s t a f f 1 2 5 9 Мау 2 9 1 9 : 5 5 / U s e r s / g a r t h / todo

Дан н ы й файл п р инадлежит пользовател ю garth и группе s taf’f’. Буквы и тире в первом столбце с и мволизируют разрешения на файл ; дл я получ е н и я подробной и н ­ формации о том , как декодировать эту и нформацию, обратитесь к разделу 5 . 5 . В данном случае коды означают, что пользователь garth может ч итать или записывать файл и что чле н ы групп ы s taf’f’ могут его прочитать. m Дополнительную и нформацию о файлах passwd и qroup см. в главе 8 . И ядро, и файловая с истема отслеживают владельцев и груп п ы как ч исла, а не как те кстовые и мена. В подавляющем больши нстве случаев идентификацион н ые номера пол ьзователе й ( короткие идентификаторы U I D) сопоставляются с именами пользовате­ лей в файле /etc/passwd, а идентификацион ные номера груп п ( G I D ) сопоставляются с и менами групп в файле /etc/ group. (Для пол учения и нформации о более сложных ВОЗМ ОЖН ОСТЯХ с м . главу 1 7. ) Текстовые и м е н а , соответствующие иде нтификаторам U I D и G I D , о пределяются только для удобства пол ьзователей систе м ы . Когда команды , такие как l s , должны ото­ бражать и нформацию о владел ьце в удобочитаемом формате, они и щуr каждое имя в со­ ответствующем файле ил и базе дан ных.

Вл а ден ие п р оц есс о м Владелец процесса может отправлять сигналы процесса (см. раздел 4.2), а также мо­ жет пон изить (повысить) приоритет план и рования процесса. П роцессы н а самом деле имеют нескол ько идентификаторов, связан н ых с н и м и : реал ьн ы й , текущи й и сохранен­ н ы й U I D ; реальн ы й , текущий и сохране н н ы й G I D; а в системе Linux — » идентифи катор файловой систем ы » , которы й испол ьзуется тол ько для определения разрешений доступа к файлам . Вообще говоря , реальные номера используются для учета (и в настоящее вре­ мя в знач ительной степени я вляются рудим ентар н ы м и ) , а текущие номера — для опре­ дел е н ия разрешений доступа. Реальные и текущие номера, как правило, оди наковы. Сохраненные U I D и G I D — это парковочн ы е м еста для идентификаторов, которые в настоя щее врем я не испол ьзуются , но остаются доступн ы м и для вызова из п роцесса. Сохране н н ые идентификаторы позволяют программе повторно входить в привилегиро­ ван н ы й режим работы и выходить из него ; эта предосторожность умен ьшает риск не­ преднамеренного неправильного поведения. Иде нтификатор U I D файловой систе м ы обычно описывается как деталь реал иза­ ции сетевой файловой систе м ы N FS. Обычно он совпадает с текущим идентификато­ ром U I D .

Часть 1. Основы администрирования

1 06

Учет ная з а п ис ь супе рп ол ьзователя root Учетная зап и с ь root

это за п и с ь все м о гуще го адм и н истративного пользователя

U N IX. Она также назы вается учетной зап и с ь ю суперпол ьзователя , хотя фактичес кое имя пол ьзователя

root ( коре н ь) .

Определ я ю щ е й характеристи кой учетной зап и с и

root я вляется е е иде нтифи катор

U I D , равн ы й О. Н и что не ме шает вам изменять и м я пол ьзователя в этой учетной зап и с и ил и создавать допол н ител ьные учетные записи , идентифи каторы U I D которы х рав н ы О ;

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

W Подробнее о системе N FS см . в главе 2 1 . Традиционная с и сте ма U N I X позволяет суперпол ьзовател ю (т. е . л юбому процессу, для которого текущи й иде нтификатор U I D равен О) выпол н ять л юбую допустимую опе­ рацию для л юбого файла или процесса.3 П еречислим н е которые п р и м еры привил е гирова н н ы х операц и й . •

Создание файлов устройстn.

Установка с исте м н ы х часо в .

Повыш е н и е л и м итов испол ьзования ресурсов и приоритетов процессов.

И з ме н е н и е и м е н и хоста систе м ы .

Настрой ка сете вых и нтерфе йсов.

Открытие при вилегирован н ых сетевых портов (с номера м и м е н ьш е

Выключение систем ы .

1 024) .

П ри м ером п ол н омоч и й супе рпол ьзовател я я вляется с пособн ость п р и н адлежащего е м у процесса изме нять свои иде нтификаторы U I D и G I D . П р и м ером может служить програ м м а входа в с исте м у

loqin и ее эквивале нты в в иде графического пол ьзовател ь­

с кого и нтерфейса ; процесс , котор ы й запра ш и вает ваш парол ь при входе в с исте му, из­ начально запускается с правами пользователя

root. Есл и введе н н ы й вами пароль и имя

пол ьзователя я вл я ются закон н ы м и , то программа входа в с истем у l ogin изменяет свои U I D и G I D на ваш и

U I D и G I D и запус кает среду оболочки ил и графический пол ь­ root и з м е н ит с воего владел ьца и станет

зовател ьск и й и нтерфей с . Как тол ько процесс

обычн ы м пользовател ьским процессом , он не с может восстановить п режн ее при вил е ги­ рован н ое состоя н и е .

Установка ф ла гов setuid и setgid Традицион н ы й контрол ь доступа U N IХ дополняется системой подстановки идентифи­ каторов, которая реализована ядром и файловой с истемой, взаимодействующи м и между собо й . Эта схе ма позволяет запускать специал ьно выдел е н н ые испол няемые файлы с по­ выше н н ы м и разрешения м и , обычно с правами пользователя

root. Это дает возможность

разработч икам и ад м и н истраторам создавать структурирова н н ы е способ ы , с помощью которых непривилегированные пол ьзовател и могут выпол нять привиле гирова н н ы е опе­ раци и .

2Дже н н и н Таунсенд, одна из наш и х рецензентов, прокомментировала это так : » Настолько плохие иде и , что я боюсь даже упоминать их, чтобы кого-нибудь не спровоцировать» . 3 3десь кл юче вое слово — «доп устимая » . Не которые операци и (например, выпол н е н и е файла, для которого не устаноw�ен бит разрешения выпол нения) запрещены даже суперпол ьзователю.

Глава 3 . Управление доступом и привилегии суперпользователя

1 07

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

s e t u i d или s e t g i d , о н о изменяет текущий идентифи катор U I D ил и G I D результиру­ ющего п роцесса на U I D или G I D файла, содержащего образ програм м ы , а н е на U I D и G I D пол ьзователя , который в вел ком анду. Так и м образо м , привилег и и пол ьзователя рас п ростран я ются только на выпол н е н и е этой конкретной команды . Например, пол ьзователи должн ы и м еть возможность изменять с вои парол и . Однако, поскольку парол и (традицион но) хранятся в защищенном файле /etc/ma s ter . pas swd ил и / e t c / shadow , пол ьзователя м н ужна команда pas swd, чтобы обесп е ч ить досту п . Команда pas swd проверяет, кто ее запус кает, и соответстве н но н астраи вает с вое пове ­ де н и е : пол ьзовател и могут изм е н ять только собствен н ые парол и , но пол ьзователь roo t может изменять л юбой парол ь. П рограмм ы , запус каем ы е с флагом s e t u i d , особен н о для пользователя root, могут создавать пробл е м ы безопасн ости . Команды с установл е н н ы м флагом s e t u i d , постав­ ляемые с системой , теоретически защище н ы ; однако в прошлом уже были обнаружен ы бре ш и в с исте ме безопасности и , н есомнен но, н екоторые будут обнаружен ы в будуще м .

проблем , с в я за н н ых с фла ­ программ , запус кае м ы х с эти м флаго м .

С а м ы й в е р н ы й с п особ м и н и м и з ировать кол и чество гом s e t u i d ,

м и н и м и зировать кол и чество

П одумайте дважд ы , прежде чем испол ьзовать програ м м н ое обес пече н и е , которое долж­ но устанавл и вать флаг s e t u i d , и избегайте п р и м е н е н и я фл ага s e t u i d в ваш е м соб­ стве н ном домаш н е м програм м ном обеспеч е н и и . Н и когда н е испол ьзуйте фла г s e t u i d в п рограммах, которые не бьm и написаны специально дл я этого. Вы можете откл юч ить установку флаго в s e t u i d и s e t g i d в отдель н ы х файловых с истемах, указав параметр n o s u i d при их монтирован и и . Рекомендуется испол ьзовать этот параметр в файловых с истемах, которые содержат дома ш н ие каталоги пол ьзовате­ лей или монтируются из менее надежн ых адми нистративных доменов.

W До полн ител ьную и нформаци ю о возм ожностях м онти рования файловой с и сте м ы см. в разделе 20 . 1 0 .

3.2. УПРАВЛЕНИЕ У ЧЕТНОЙ ЗАПИС Ь Ю ROOT Доступ к уч етной записи root н еобходим для ад м и н истрирова н и я систе м ы . Кро ме того, он представляет собой точ ку опоры дл я с исте м ы безопас ности . Правил ьное ис­ пол ьзование этой учетной записи является решающ и м навыком .

В ход в учетную з а пись root П оскольку root — это просто еще один пол ьзовател ь, бол ьшинство с истем позволя­ ют вам напрямую входить в учетную запись root. Однако это оказы вается плохой иде ­ е й , поэтому в с истеме

UЬuntu такие действия запрещен ы по умолчани ю .

Во- первых, учетн ые записи root н е содержат и нформации о том , какие операции вы­ пол нялись с правами root. Это плохо, когда вы пон имаете , что вчера испортили что-то в 3:00 утра и не можете вспом н ить, что именно вы и зм е н ил и ; это еще хуже , если доступ бьт несанкцион ирова н н ы м , и вы п ытаетесь выяснить, что нарушитель сделал с вашей си­ сте мой . Другим недостатком является то, что с ценарий входа в систе м у не содержит запи ­ сей о том , кто на самом деле выполняет данную работу. Если у нескольких пользователей есть доступ к учетной записи root, вы не сможете определить, кто ее использовал и когда. По этим прич и н ам бол ьш и нство с истем позволяют откл ючать вход в учетн ые записи roo t на терм и н алах, через окон н ы е с исте м ы и по всей сети — везде , кроме с исте м н о й

1 08

Часть 1. Основы администрирования

консол и . М ы преддагаем вам испол ьзовать эти возможности . Ч тобы узнать, как реал и ­ зовать эту пол итику в вашей кон кретной системе, с м . раздел 1 7 . 3 . Есл и у пол ьзователя r o o t есть парол ь (т. е . учетная зап ись r o o t не откл ючена, с м . н иже ) , этот парол ь должен быть очень сложны м . Для получе ния допол нител ьных комментариев относительно выбора пароля см. раздел 27.3.

Кома нда su: замен а идентификатора п ол ьзовател я Л уч ш е получать доступ к учетной записи root с помощью команды su. При вызове без аргументов она в ыдает приглашение на ввод пароля пользователя root, а затем за­ пус кает оболочку с при вилегированн ы м и правами. Эти права будут сохраняться , пока в ы не заверш ите работу (нажав комбинацию клавиш < Ct rl + D > ил и выпол н и в команду exi t). Команда su не фиксирует действия , производимые привиле гирова н н ы м пол ьзо­ вателем, но добавляет запись в журнал ьн ы й файл с указан ием , кто и когда вош ел в си­ стему под именем root. Команда su способна также подставлять вместо имени root имена других пол ьзова­ телей. И ногда единстве н н ый способ помочь пол ьзователю в решен и и пробл е м ы — во­ йти с помощью команды su в е го среду и воспроизвести ситуацию. З ная чей-л ибо пароль, можно непосредственно зарегистрироваться в системе под е го именем, введя команду su — имя_ поль з о в а т ел я. В ответ будет выдан запрос на ввод пароля. При использован и и в качестве кл юча команды su дефиса ( — ) оболочка перейдет в режим регистрации . Точная реализация этого режима зависит о т конкретной оболочки , но обычно в этом режиме меняются количество и имена файлов запуска, сч итываемых интерпретатором . Например, в режиме регистрации оболочка bash считывает файл «/ . bashyrofile, а вне этого режима — файл » / . bashrc. При диагностике проблем конкретного пользователя ре­ жим регистрации позволяет максимально точно воспроизвести среду, в которой он работал. В одних с истемах парол ь root позволяет регистрироваться с помощью команд su или login под любым именем. В других нужно сначала стать пользователем root, при­ менив в явном виде команду su, а затем с помощью этой же команды перейти в другую учетную запись. В таком случае вводить пароль не потребуется. Рекомендуем сделать правилом при вводе команды указывать пол ное имя , например /Ьin/ su или /usr/Ьin/ su, а не просто su. Это послужит определен ной защитой от тех програ м м с и м е н е м su, которые преднамеренно был и измене н ы злоум ышле н н и ко м , планировавшим собрать хорош и й » урожай » паролей4• В не которых с исте мах, чтобы испол ьзовать команду su, н еобходимо быть членом груп п ы whee. Команду su в знач ител ьной степени может замен ить програм ма sudo (см. следую­ щий раздел) , саму же команду su лучше всего оставить ддя авари йных ситуаций.

П рограмма sudo: огра ниченный ва риа нт кома нды su Без одной из усовершенствован ных систем управления доступом, описанных в раз­ деле 3.4, трудно разреш ить кому-то выполн ять какую-то задачу (например, резервн ые 4По аналогичной причи н е настоятельно рекомендуем не вкл ючать зап ись » . » (текущий каталог) в пере м е нную p a th ( которую можно увидеть, н абрав команду echo $ РАТ И ) . Несмотря на очевидное удобство, подобная конфи гурация п р и водит к тому, что можно н е п реднамере н н о зап устить «специал ьную» верси ю какой — н и будь систе м ной команды, которую з.лоумы ш ле н н и к оставил в качестве приманки . Пользователю root следует бьrrь бдительн ы м вдвой не.

Глава 3. Уп равление доступом и привилегии суперпользователя

1 09

коп и и ) , не предоставляя этому пользователю права свободно запускать с истему. И если учетная запись root используется нескольки м и адми нистраторам и , на самом деле у вас будет только смутное представление о том , кто ее использует или что они сделали. Н аибол е е ш ироко ис пол ьзуе м ы м ре ш е н ие м этих пробл е м я вл я ется программа под названием sudo , которая в н астоящее врем я поддерживается Тоддом М иллером (Todd M iller) . Эта программа работает на всех наших иллюстративных с истемах и также доступна в форм е исходного кода на сайте s u do . w s . М ы рекомендуем использовать ее в качестве основного метода доступа к учетной записи root. П рограмма sudo принимает в качестве аргуме нта командную строку, выполняемую с правами root (или правами любого другого ограниченного пользователя). П рограм ма sudo проверяет файл /etc/ sudoers (/usr/ local /etc/sudoers в системе FreeBSD), в ко­ тором перечислены люди, имеющие разрешение использовать программу sudo и команды, которые и м можно запускать на каждом хосте. Если предЛагаемая команда разрешена, про­ грамма sudo запрашивает собственный пароль пользователя и выполняет команду. В течение пяти минут после запуска программа sudo позволяет выполнять команды без обязательного введения пароля (продолжительность этого периода можно менять) , после чего программа sudo перейдет в режим ожидания. Этот тайм-аут служит скромной защитой от пользователей с привилегиям и sudo, которые оставляют терминалы без присмотра. Программ а sudo ведет журнал выполненных команд н ых строк, регистрирует хосты, на которых они выполнялись, людей , которые их выполнял и , каталоги , из которых они был и выпол н е н ы , и вре м я , в которое о н и были в ы пол н е н ы . Эта и н формация м ожет быть зарегистрирована в систе мном журнале или помещена в файл по вашему выбору. Мы рекомендуем испол ьзовать м еханизм Syslog дЛЯ пересылки записей журнала на без­ опасный центральны й сервер. Запись журнала для выпол н ен ия команды sudo /Ьin/cat /etc/ sudoers пользо­ вателя randy может выглядеть так: D e c 7 1 0 : 5 7 : 1 9 t i g g e r sudo : randy : T T Y= t t yp O ; PWD= / t i g g e r / u s e r s / r andy ; U S E R= r o o t ; COММAN D= /bi n / c a t / e t c / sudoe r s

Прим ер конфигурации Файл sudo e r s разработан так и м образо м , что одн а версия м ожет испол ьзоваться сразу на нескольких разных хостах. Вот типичный пример . # D e f i n e a l i a s e s f o r ma chi n e s i n C S & P h y s i c s dep a r tmen t s H o s t_Al i a s C S = t i gg e r , a n ch o r , p i pe r , moe t , s i g i H o s t Al i a s P H Y S I C S = e p r i n c e , p p r i n c e , i c a r u s # D e f i n e c o l l e c t i o n s o f commands Cmnd_Al i a s DUMP = / s b i n / dump , / s Ь i n / r e s t o r e Cmnd Al i a s WATCHDOG = / u s r / l oc a l / Ь i n /watchdog Cmnd Al i a s S H E L L S = / Ь i n / s h , / Ь i n / da s h , / Ь i n / b a s h # P e rmi s s i o n s ma r k , ed PHYS I C S = ALL C S = / u s r / sЬ i n / t cpdump : PHYS I C S = ( op e r a t o r ) he rb ALL = ( AL L ) ALL , ! SH E L L S l ynda % wh e e l ALL , ! P HYS I C S = NOPAS S W D : WATC H DOG

DUMP

Первые два н абора строк определяют группы хостов и команды , которы е упоми­ наются в дальнейших спецификациях разре ш е н и й , включен ных в файл . Списки могут быть включены буквально в с пецификации , но псевдонимы облегчают чте н ие и пони ­ ман ие файла sudoer s ; они также упрощают обновление файла в будуще м . Также воз-

Часть 1. Основы администрирования

110

можно определить псевдонимы для пользователей и групп пол ьзователе й , для которых могут выпол няться команды . m Дополнительную информацию о файле sysloq см. в главе 1 0 . Каждая строка спецификации разрешений содержит следующую и нформацию. •

П ользователи , к которым относится запись.

Хосты , на которые распространяется эта запись.

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

Пользователи , которы м разрешается выпол н ять команды.

Пе рвая строка разре ш е н и й применяется к пол ьзователям ma r k и e d на маш и н ах в группе P H Y S I C S ( e p r i n c e , pp r i n c e и i c a r u s ) . Встроен н ы й ком андны й псевдоним ALL позволяет и м в ыпол н ять л юбую команду. Поскол ьку в круглых с кобках н е указан сп исок пользователе й , программа sudo будет запускать команды с правами root. Вторая строка разрешений позволяет пользователю h e r b запускать утилиту tcpdump на машинах группы c s и команды вывода дампа н а машинах групп ы PHYS I C S . Однако команды в ывода дампа могут выпол няться только с правами пол ьзователя o p e r a t o r , а н е суперпользовател я . Реал ьная командная строка, которую должен был б ы ввести пользователь h e r b , выглядела бы так: ubun t u $ sudo -u operator /usr / sbin/ dWDp Ou /dev/ sdal

Пол ьзователь l yn d a может запускать команды как л юбой пол ьзовател ь н а л юбой машине, за исключ е н ие м того, что она не может запускать нескол ько общих оболочек. Означает л и это, что пол ьзовател ь l yn d a действител ьно не имеет доступа к корневой оболочке? Конечно, н ет: ubun t u $ ер -р /bin/sh/tmp/ sh ubunt u $ sudo / tmp/ sh

Вообще говоря, любая попытка разреш ить » все команды, кроме . . . » обречена на про­ вал , по крайней мере в тех н ическом с м ысл е . Те м не менее может о казаться целесоо­ бразным настроить файл sudoers таким образом, чтобы напомн ить о том , что вызывать оболочку с правами root крайн е нежелател ьно. Последняя строка позволяет пользователя м групп ы whe e l выполнять локальную ко­ манду watchdog с правами root на всех машинах, кроме e p r i n c e , p p r i n c e и i c a r u s . Кроме того, для выполнения этой команды не требуется пароль. Обратите в н и ма н ие на то, что команды в файле sudoers указа н ы с пол н ы м и име­ нами путе й , чтобы л юди не могл и выполнять с вои собствен н ые програм мы и сценарии с правами root. Хотя в вышеприведе нном примере это не показано, можно указать ар­ гументы, допустимые для каждой команды . Ч тобы вручную изменить файл sudoers , используйте команду vi sudo, которая про­ веряет, что никто другой не редактирует файл, вызывает для него редактор (vi или любой редактор, указанный вами в перемен ной среды E D I TOR) , а затем проверяет синтаксис от­ редактирован ного файла перед его установкой. Этот последний шаг особенно важен , по­ тому что н еправильный файл sudoers может помешать вам снова исправить ошибку.

Преимущества и недостатки программы sudo Использование программы sudo и меет следующие преимущества. •

Благодаря ведению журнала команд значительно улучшается учет.

П ол ьзователи могут выпол н ять определ е н н ые задачи , не имея неогран иче н н ых прав roo t.

Глава 3. Управление доступом и привилегии суперпользователя

111

Реальны й пароль root может быть известен тольк о одному или двум людя м . 5

Использование программ ы sudo быстрее, чем вызов su или вход в систему с пра­ вами root.

П ривилегии можно отменить без н еобходимости изменения пароля пользователя root.

Поддерживается канонический список всех пользователей с правами root.

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

Один файл может управлять доступом ко всей сети.

У программы sudo есть и несколько недостатков. Хуже всего то, что любое н аруше­ ние безопасности личной учетной записи sudoer мож ет быть эквивалентно нарушению самой учетной записи roo t. В ы не можете сделать м ногого, чтобы п ротивостоять этой угрозе , кроме как предостеречь пользователей, переч исленн ых в файле sudoers , чтобы он и защитил и свои учетн ые записи , поскольку они будут иметь учетную запись root. В ы также можете регулярно запускать взломщик паролей Дll Я п ол ьзователей, пер е ч и сле н ­ н ых в sudoers , чтобы убедиться, что они выбрали пра в ил ь ны е пароли . Все комментар ии п о выбору пароля с м . в разделе 2 7 . 3 . Регистрацию команд в программе sudo можно ле г ко обойти с помощью таких трю­ ков, как временный выход в оболочку из разрешенной программ ы , или к оман д ы sudo sh и sudo su. (Такие команды отображаются в журналах, поэтому вы по крайней мере узнаете , что они бьu ш запуще н ы . )

Программа sudo и расширенный контроль доступа П ро грамме sudo как способ разделения привилегий корневой учетной записи пре­ восходит многие из систем управления доступом , оп и с а н н ы х в разделе 3.4. •

Вы точно определяете , как будут разделены при ви л е ги и Ваше подразделение мо­ жет быть более грубы м или более тонким, чем привилеги и , определенн ые ДllЯ вас с помощью готовой системы.

П ростые конфигурации — самые распространенные — п росты в настро йке, обслу­ живани и и пониман ии. П рограмм а sudo работает на всех с истемах U N lX и Linux. Вам н е нужн о беспо ко иться об управлен и и различными решениями на разных платформах. В ы можете использовать оди н файл конфигурации во всей орган изации .

Вы бесплатно получаете качественные протокол ы .

.

Поскольку система уязви ма для катастрофическо й ком промета ци и , есл и корневая учетная запись будет взломана, основны м недостатком контроля доступа на основе про­ грамм ы sudo я вляется то, что потенциал ьная поверх н о ст ь атаки расш иряется и распр о ­ страняется на учетные записи всех адми н истраторов. П рограмма sudo хорошо работает как инструмент благонамере н н ых администрато­ ров, которым необходим общий доступ к привилегиям roo t. Она также отлично под­ ходит для того, чтобы остальные пользователи могли в ыпол н ить н ес кол ько конкретных операци й . Несмотря на синтаксис конфигурации, кото р ы й предполагает иное, програм­ ма sudo, к сожалению, не является безопасным спосо бом определить ограниченные об­ ласти автономи и или вынести определенные операции за пределы безопасной области. W Для получения дополнительной информации о взломе пароля см. раздел 27. 5 . 1 Или даже н икому, если у вас есть правильная с и стема хране н ия паролей .

Часть 1. Основы администрирования

112

Даже не п ытайтесь испол ьзовать эти конфигурации. Если вам нужна эта фун кцио­ нальная возможность, луч ш е всего подкл юч ить одну из с истем управления доступом , описан ных в разделе 3 . 4.

Типи чная настройка За м ногие годы система конфигурации sudo накопила м ного фун кци й . Она была модифи ц ирована , чтобы учесть м н ожество необыч н ых ситуаци й и край н их случаев. В резул ьтате текущая документация создает впечатление сложности , которое не обяза ­ тельно оправданно. Поскольку важно, чтобы программа sudo была надежным и безопасным и нструмен­ том , естественно задаться вопросом , можете л и вы подвергать свои систе м ы допол н и ­ тельному риску, если н е испол ьзуете е е рас ш иренные фун кции и не устанавливаете пра­ вильные значения дпя всех параметров. Ответ: нет. 90% содержимого файла sudoers выглядит примерно так: U s e r Al i a s ADM I N S

ADM I N S = a l i ce , ЬоЬ , cha r l e s AL L = ( AL L ) ALL

Это совершенно респектабельная конфигурация , и во м ногих случаях нет необходи­ мости ее усложнять. М ы упом и нали несколько допол н ительных функци й , которые вы можете испол ьзовать в следующих разделах, но все они являются и нструментами дпя ре­ ш е н и я пробл е м , которые полезны дпя конкретн ых с итуаций . Для общей надежности больше н ичего н е требуется .

Управл ение окружением Многие команды проверяют значения перемен н ых окружения и изменяют свое пове­ дение в зависимости от того, что они находят. В случае, если команды выполняются с пра­ вами root. этот механизм может быть полезным и многообещающи м способом атаки. Например, допустим, что несколько команд запускают программу, указан ную в пере­ менной окружения E D I TOR, дпя редактирования текстового файла. Если эта переменная указывает на вредоносную программу хакера вместо текстового редактора, вполне веро­ ятно, что в конечном итоге вы запустите эту программу с правами root.6 Чтобы минимизировать этот риск, поведение программ ы sudo по умолчанию закл ю­ чается в передаче только м и н имал ьного, дезинфицированного множества пере м е н н ых окружен ия дпя команд, которые она запускает. Если вам нужны дополн ител ьные пере­ менные окружения , которые нужно передать, вы можете их перечисл ить, добавив в спи­ сок env_ keep файла sudoers . Например, строки Defaul t s De f a u l t s

env_ k e e p += » S SH_AUT H_S OC K » e n v_ k e e p += » D I S P LAY XAUTHOR I ZAT I ON XAUTHOR I T Y «

сохраняют несколько переменных окружения, используе м ых Х Wi ndows и м еханизмом пересылки ключей S S H . Для разных пользователей или групп можно настроить разные списки e n v_ k e e p , н о конфигурация быстро усложн ится. М ы предпагаем придерживаться единого универсаль­ ного списка и быть относ ител ьно консервативным с исключениями. которые вы закре­ пляете в файле sudoer s . 1′ Пояс н и м , что сценарий в этом случае закл ючается в том , что ваша учетная за п и с ь была скомпрометирована, но злоум ышленни к не знает ваш фактически й пароль и поэтому не может напрямую запускать п рограмму sudo. К сожалению, это обычная ситуация, все, что требуется , это терми нальное окно, оставленное на м гновение без присмотра.

Глава 3. Уп равление доступом и привилегии супер п ользователя

113

Есл и н е обходимо сохр а н ить п е р е м е н ную среды , которая н е указа н а в файле sudoers , ее можно явно установить в командной строке sudo. Н апример, команда $ sudo ED ITOR=emacs vipw

редактирует файл с истем ного парол я с помощью редактора ema c s . Эта функция и меет н екоторые поте нциальные огра н ичен и я, но они н е распространяются на пользователей , которые могут запускать все команды.

Программа sudo без паролей Часто можно с сожален ием в идеть, что программа sudo н астроена н а в ы пол н е н ие команды с правам и roo t без необходимости вводить п ароль. Для справки, эта конфи­ гурация задается с помощью кл ючевого слова N O PAS SWD в файле sudoers . Например: ansiЫe

ALL

=

( AL L ) NOPAS SWD : ALL

# Н е д е л а й т е э то г о

И ногда это делается из-за лен и , но, как правило, основная причи н а — желание вы­ пол нить какие-то операции без санкции программы sudo . Наиболее распростране н н ы ­ м и случаям и я вляются удаленная настройка с помощью такой систе м ы , как AnsiЫe , или запус к команд из планировщика cron. W Дополнительную информацию о системе AnsiЫe см . в главе 23. Излишне говорить, что эта конфигурация опасна, поэтому избегайте ее, если може­ те . По крайн е й мере о граничьте выпол н е н ие небезопасного доступ а к определен ному набору команд, если сможете. Другим вариантом , которы й хорошо работает в контексте удале нного выпол н ения , я вл яется заме н а введе н н ых вручную п аролей аутентификации с помощью программы s sh — agent и перенаправленных S S Н — кл ючей. В ы можете настроить этот метод аутен ­ тификации с помощью модуля РАМ н а сервере , где будет выполн яться программа sudo . Бол ьш инство с истем не в ключают модуль РАМ , которы й по умолчани ю испол ьзует аутентификацию на основе S S H , но он легко доступе н . Найдите пакет pam_ s s h_ a g e n t _ auth. Пересылка ключей S S H и меет собстве н н ы й н абор проблем безопасности , н о это , безусловно , луч ш е , чем пол ное отсутствие аутентификации.

Приорит ет Вызов программ ы sudo потен циал ьно может быть рассмотрен нескол ькими запися­ м и в файле sudoers . Например , рассмотрим следующую конфигурацию: U s e r Al i a s U s e r Al i a s

ADM I N S a l i c e , ЬоЬ , cha r l e s a l i c e , ЬоЬ MYS QL_ADMI N S

% wh e e l MYSQL_ADM I N S ADM I N S

ALL ALL ALL

=

=

( ALL ) ALL ( my s q l ) N O PAS SWD : ALL ( ALL ) NOPA S SW D : / u s r / s b i n / l o g r o t a t e

W Дополнительную информацию о конф и гураци и РАМ см. в разделе 1 7. 3 . Здесь адм и н истраторы могут запус кать команду logrotate как обыч н ы й пользова­ тель без предоставления пароля. Адм инистраторы MySQ L могут выпол нять л юбую ко­ манду от имени пользователя mysql без пароля. Любой человек в группе whe e l может выпол н ять л юбую команду под любым идентификатором U I D , но сначала он должен пройти ауте нтификацию с помощью пароля.

Часть 1. Основы администрирования

114

Есл и пол ьзовател ь находится в гру п п е wh e e l , она потен циал ьно охваты вается каж­ дой из последних трех строк. Откуда вы знаете , какая из н их будет оп ределять п оведен и е sudo? П равило закл ючается в том , что sudo все гда подч и н яется последне й соответству­ ющей строке , п р и ч е м совпаде н и е определяется все м и четырьмя параметрам и : и м е н е м пол ьзователя , хостом , и ме н е м целевого пол ьзовател я и командой . Каждый и з этих эле ­ ментов долже н соответствовать строке конфи гурац и и , ил и строка просто и гнорируется . П оэтому искл юч е н ия NOPAS S W D должн ы соответствовать их более общ и м анал о гам , как по казано в ы ш е . Есл и бы порядок п осл едн и х трех строк был отм е н е н , то бед н о й Ал и с е 7 п р ишлось бы вводить парол ь независимо о т того , какую команду sudo о н а п ыта­ лась бы запустить.

Пр огр амма sudo без терминала управления П ом и м о п робл е м ы аутентифика ц и и без парол я , авто матическое в ы пол н е н ие про­ гра м м ы sudo (напри м е р , и з пла н и ровщика cron) часто происходит без обычного тер­ м и н ал а управле н и я . В этом н ет н и ч е го неправил ьного , н о это стран ная ситуация , кото ­ рую п рогра м м а sudo может обнаружить и отклон ить, есл и в файле sudoers вкл ючена опция r e qu i r e t t y . Этот параметр н е задается п о умолчани ю с точ к и зрен и я п ро гра м м ы sudo , н о н е ко­ торые дистрибутивы операцион н ых с истем вкл ючают е го в файл ы sudoers по умолча­ н и ю, поэтому его стоит п роверить и удал ить. Н айдите строку, и ме ющую вид De f a u l t s

r e qu i r e t t y

и пом е н яйте в н е й значен и е н а п роти воположное: De f a u l t s

! requi r e t t y

О п ция r e qu i r e t t y предлагает небольшую с и м вол ическую защиту от определ е н н ых с ценариев атаки . Те м не менее ее ле гко обойт и , та к и м образом , она дает мало реал ьных п р е и м уществ в плане безопасности. П о нашему м н е н и ю , опцию r e qu i re t t y н еобходи­ мо откл ючить, потому что это общи й источ н и к п робл е м .

Конфигурация sudo на уровне сайта П ос кольку файл sudoers вкл ючает текущ и й хост в качестве подходя щего критерия для строк конфи гура ц и и , вы можете испол ьзовать оди н главн ы й файл sudoers в адми­ н и страти вном дом е н е (т. е . в области , где гарантируется эквивалентность имен хостов и у•1етн ы х записей пол ьзовател е й ) . Этот подход н е м н ого усложняет исходные настройки sudoers , но это отл и чная идея по н ес кол ьким при ч и нам . Вам следует это попробовать. Осно вное п р е и мущество этого подхода закл ючается в том , что нет н и какой тайн ы в том , кто и какие и меет разре ш е н и я и дл я каких хостов. Все зап и сано в одном авто­ ритетн о м файле . Н а п р и м е р , когда ад м и н истратор покидает ваш у орга н и заци ю , нет н е ­ обходимости отслежи вать в с е хосты , на которых у этого пол ьзователя могл и б ы т ь пра­ ва sudo . Когда необход и м ы и з м е н е н ия , вы просто и зм е няете главн ы й файл sudoers и расс ылаете е го заново. Естествен н ы м следстви е м этого подхода я вляется то , что разре ш е н ия sudo м о гут б ыть луч ш е выраже н ы в тер м инах учетных зап и с е й пол ьзовател е й , а не гру п п Н а п р и м е р , зап и с ь % wh e e l

ALL = A L L

7Тради ц ион н ы й п е р с онаж в о п и сан и я х к р и п то гр аф и ч е с к их п рото к олов .

Прим еч . ред.

U N IX.

Глава 3. Управление доступом и привилегии суперпользователя

115

и меет некоторую и нтуитивную привлекательность, но она отменяет перечисление при­ вилегированных пользователей на каждой локальной машине. Вы не можете взглянуть на эту строку и определить, к кому она относится, не подходя к рассматриваемой маши­ не. П оскольку идея состоит в том , чтобы сохран ить всю соответствующую информацию в одном м есте, лучше избегать такого типа группировки при совместном испол ьзовани и файла sudoers в сети. Конечно, есл и членство в ваше й группе тесн о координируется по всей организации , группы можно использовать без проблем. Распределение файла sudoer s лучше всего достигается с помощью более ш ирокой систе м ы управл е н ия конфигурацией , как описано в главе 2 3 . Одна ко есл и вы еще не достигл и такого уровня, вы можете легко разослать его самостоятельно. Однако будьте осторожны : установка поддельного файла sudoer s это быстр ы й путь к катастрофе . Это также удобн ы й файл для испол ьзования в системе монитори н га целостности фай­ лов; см. раздел 2 8 . 8 . В случае отсутствия систе м ы управления конфигурацией лучше всего испол ьзовать сценарий извлечения информации, которы й заканчивается планировщиком cron на каж­ дом хосте. Используйте команду s cp для копирования текущего файла sudoer s из из­ вестного центрального репозитория , а затем проверьте его с помощью команды vi sudo -с -f n e ws udo ers перед установкой, чтобы убедиться , что формат является приемле­ мым для локальной программы sudo. Команда scp проверяет ключ хоста удаленного сер­ вера, гарантируя, что файл sudoers поступает с вашего хоста, а не с поддельного сервера. При совместном использован ии файла sudoers спецификация и м е н и хоста может б ыть н е много сложной. По умолчанию програм ма s udo испол ьзует вывод команды hos tname в качестве текста, который нужно сравнить. В зависи мости от согла ш е н и й , используемых в вашей организации, это имя может включать или не включать часть до­ мена ( например , a n c h o r или a n c ho r . c s . c o l o r a d o . e d u ) . В л юбом случае имена хо­ стов, указанные в файле sudoer s , должны совпадать с именам и , которые возвращают все хосты . (Вы можете включить опцию fqdn в файле sudoers , чтобы попытаться пре­ образовать локальные имена хостов в их полные формы . ) Совпадение и м е н хостов сложнее проверяется в облаке , где имена экземпляров часто по умолчанию имеют ал горитмически сгенерированные шаблон ы . Программа sudo по­ н и м ает простые с и м волы шаблонов соответствия (подстановки) в именах хостов, по­ этому рассмотрите возможность испол ьзования схе м ы и м енован и я , которая включает в себя некоторые указания на классификацию безопас ности каждого хоста с точки зре­ н ия программы sudo . Кроме того, можно использовать виртуальные сетевые фун кции облачного провай­ дера для разделе н и я хостов по J Р-адресу, а затем сопоставлять I Р-адреса в место и м е н хостов из файла sudoers. —

Откл ючение учетной з а писи roo t Есл и ваша организация стандартизирует испол ьзование прогр аммы sudo , вы вряд ли будете использовать реальные пароли root. Большая часть вашей админ истративной команды н икогда н е будет иметь возможности испол ьзовать их. Этот факт ставит вопрос о том , н ужен ли пароль root вообще. Если вы решите , что не нуже н , вы можете полностью отключить вход в с истему с права м и roo t , установив заш ифрованн ы й пароль root равны м * или другой произвольной строке фикс ирован­ ной дл и н ы . В с истеме Linux, команда pas swd — 1 блокирует учетную запись, добавляя знак ! к зашифрованному паролю с эквивалентн ыми результатами.

Часть 1. основы администрирования

116

С и м вол ы

* и

! — просто условности; н и какое п рогра м м ное обеспечение не проверя­

ет их я в н ы м образо м . И х эффе кт закл юч ается в зада н и и н е корректн ы х х е ш е й парол е й . В результате парол ь root просто н е п роходит проверку. Основной эффект блокировки уч етной зап ис и root закл ючается в том , что пользо­ вател ь root не может войти в систе м у, даже с консол и . Ни оди н и з п ол ьзователе й н е м ожет усп е ш н о запустить программу s u , потому что дпя этого также требуется проверка пароля root. Однако учетная зап и с ь roo t п родолжает существовать, и все програ м м ­ ное обеспече н и е , которое обыч но вы полняется с правами root, продолжает это делать. В частности , п рогра м м а sudo работает как об ычно. Основное пре и м ущество откл юч е н ия учетной зап и с и root закл юч ается в том , что вам н е нужно зап ис ы вать парол ь root и уп равл ять и м . Вы также устраняете возмож­ н ость взлома п ароля roo t, но это более п р иятн ы й п обоч н ы й эффект, ч е м убедительная п р и ч и н а для перехода без парол я . Редко испол ьзуе м ые парол и уже и м е ют н и зк и й риск ком прометаци и . Особе н н о полезно и меть реал ь н ы й п арол ь root на физических ком п ьютерах ( в от­ л и ч и е от обл а ч н ы х ил и виртуал ь н ы х экзе м пляров, с м . главы 9 и 24). Есл и пробл е м ы с оборудова н и е м и л и конфигура цией м е ш а ют процессу sudo ил и загрузке , реал ь н ы м ком п ьютерам необходимо будет удел ить в н и м а н и е . В этих случаях удобно и м еть тради ­ цион ную учетную зап и с ь root как авари й н ы й резерв. Система Ubuntu поставляется с откл ючен ной учетной записью root, и вес ь адм и н истративн ы й доступ осуществляется через програ м му sudo ил и ее эк­ в и валент с графическим пол ьзовател ьск и м интерфейсо м . Есл и хотите , мо­ жете установить парол ь root н а Ubuntu , а затем разблокировать учетную за­ пись с помощью команды sudo pa sswd -u root.

Системн ые учетные зап иси , отличн ые от root П ол ьзовател ь root об ычно я вляется еди нстве н н ы м , кто имеет особы й статус с точ ­ ки зре н ия ядра, но в бол ь ш инстве с истем существуют и другие псевдопол ьзователи . В ы можете иде нтифицировать эти фиктивные учетн ые зап и с и по и х иде нтифи каторам U I D, которые обычно не пре вышают

1 00. Ч аще всего идентификаторы U I D менее 1 0 относят­ 1 00 — к псевдопол ьзователя м , связан­

ся к с исте м н ы м учетн ы м зап ися м , а U I D от 1 0 до

ным с определ е н н ы м и ком поне нтам и програ м м ного обеспечен ия. Обычно п р и н ято зам е нять звездоч кой заш ифрова н н ое пол е пароля этих с п е ц и ал ь ­ н ы х пользователе й в файле shadow ил и ma s ter . pas swd, чтобы п од и х учетн ы м и за­ п и ся м и н ел ьзя было войти в систе м у. В качестве и х систе м н ы х оболоче к дол ж н ы быть установл е н ы програ м м ы /Ьin/false

или /Ьin/nologin, чтобы защ итить от удал е н н ы х

поп ыток входа в с и стему, которые испол ьзуют ал ьтернати в ы парол е й , такие к а к файл ы ключей

SSH.

Как и в случае с учетн ы м и зап ися м и пол ьзовател е й , в бол ьш и нстве с истем определя­ ются м н ожество связа н н ы х с с истемой груп п , которые и м е ют оди наково н изкие иде н ­ тифи каторы G I D.

W Дополнительную и нформаци ю о файлах shadow и шa s te r pa s swd см. в разделе 8 . 3 . .

Файлам и процесса м , я вляющимся частью операцио н ной систе м ы , которые не долж­ ны принадпежать к категори и roo t, иногда в качестве владельце в назначаются пользова­ тел и Ьin ил и daemon. Теория заключалась в том , что это соглаш е н и е поможет избежать угроз безопас ност и , связа н н ых с владением права м и root. Однако это не сл и ш ком ве­ ский аргумент, и в совре м е н н ых с истемах часто испол ьзуется тол ько учетная зап ись root.

Глава 3. Уп равление досту п ом и п ри в илегии су п ер п ользователя

117

Основное преимущество псевдоучетных записей и псевдогрупп заключается в том , что с их помощью можно безопаснее обеспечить доступ к определ е н н ы м группам ре­ сурсов , чем с помощью учетной записи roo t. Например , базы данн ы х часто реализуют сложные систем ы управления доступом . С точ ки зрен ия ядра он и работают как псевдо­ пользователь, такой как mys c q , которы й владеет всеми ресурсами , с вязанн ы м и с базой дан н ых. Сетевая файловая с истема ( N FS) использует учетную запись n o b o d y для представ­ ления пользователе й root в других с истемах. Для удал е н н ы х суперпол ьзователей, ко ­ торые должны быть л и ш е н ы своих привилегированных полномоч и й , удал е н н ы й U I D , равный О, должен быть сопоставлен с чем-то другим , кроме локального U I D , равного О . Учетная запись n o b o d y действует как общее имя для этих удал е н н ы х суперпол ьзовате ­ л е й . В систе м е N F Sv4 учетная запись n o b o d y может приме няться к удал е н н ы м поль­ зователям , которые также не соответствуют действительной локальной учетной записи.

Ш Дополнительную информацию об учетной записи

nobody

с м . в разделе 2 1 .2.

П ос кольку учетная зап ись n o b o d y должна представлять обоб щ е н ного и относ и ­ тельно бесправного пол ьзовател я , о н а не должна владеть файла м и . Есл и учетн ая за­ пись nobody владеет файла м и , значит, удал е н н ы е суперпол ьзователи могут их контро­ л ировать.

3 .3 . РАСШИРЕНИЯ СТАНДАРТНОЙ МОДЕЛИ КОНТРОЛЯ ДОСТУПА В предыдущих разделах описаны основные концепции традиционной модели управ­ ления доступом . Несмотря на то, что эту модель можно описать на нескольких страни ­ цах , о н а в ыдержала испытание временем , потому что проста, предсказуема и способна обрабатывать требования средне й организации . Все варианты U N IX и Linux продолжа­ ют поддерживать эту модел ь, и она по-прежнему остается стандартной и наиболее ш и ­ роко распространенной. В современных операционных системах эта модель включает в себя ряд важных усо­ вершенствований. Текущий статус- кво обеспечивают три уровня программного обеспе­ чения. •

Стандартная модель, описанная в этом пункте .

Расширен ия , которые обобщают и точно настраивают базовую модель.

Расшире н ия ядра, которые реал изуют альтернативные подходы.

Эти категории я вл я ются н е архитектур н ы м и слоя м и , а с корее историческими арте­ фактами. Ранн ие производные с исте м ы U N IX использовали стандартную модель, но ее недостатки был и ш ироко признаны даже тогда. Со временем сообщество начало разра­ батывать обходные пути для решения нескол ьких более насущных проблем. В интересах поддержания совместимости и поощрен ия широкого распространения изменения обыч­ но были структурированы как усовершенствования традиционной с исте м ы . Некоторые из этих настроек ( например, РАМ ) теперь считаются стандартами U N IX. За последнее десятилетие в области модуляризации систем контроля доступа были достигнуты большие успехи. Эта эвол юция позволяет еще более радикально изм е н ить контроль доступа. Мы рассмотрим некоторые из наиболее распространенных подклю­ чаемых параметров для Linux и Free B S D , начиная с раздела 3 .4.

Часть 1 . Основы администрирования

118

Пока мы расс мотр и м не которые из более п розаических расш ире н и й , которые связа­ н ы с бол ь ш и нством систе м . Во- первых, м ы расс мотр и м пробл е м ы , которые п ытаются ре ш ить эти рас ш и р е н и я .

Недостатки стандартной модел и Несмотря на свою эле гантность, стандартная модель имеет не которые очевидные н е ­ достатки. •

Нач н е м с того, что учетная зап ись root представл яет собой поте н ц иал ьно еди н ­ стве нную точ ку отказа. Если о н а будет с ко м прометирована, целостность все й с и ­ сте м ы будет н арушена, и , по существу, н е т огра н и ч е н и й на ущерб , который может нанести злоумышле н н и к .

Еди н стве н н ы й способ разделить при вилегии учетной записи r o o t — п исать про­ гра м м ы с флагом s e t u i d . К сожал е н и ю , как показывает постоян н ы й поток об­ новл е н и й програм м но го обес печ е н и я , связа н н ы х с безопасн остью , написать без­ опасное п рогра м м н ое обеспече н и е сложно. Л юбая программа, испол ьзующая флаг

s e t u i d , я вляется потен циал ьной целью. •

Стандартная модел ь мало что может сказать о безопасности в сети . Н ет ком п ью ­ тера, к которому н е п р ивилегирован н ы й пользователь и м ел бы физическ и й доступ и которому м ожно было бы доверять, чтобы точно п редставлять владел ьцев запу­ с кае м ы х п роцессов. Кто скажет, что кто-то н е п ереформатировал диск и н е уста­ новил свою собстве н н ую операционную систе му с идентификатором U I D по с во­ ему выбору?

В стандартной м одел и определ е н и е гру п п ы я вл я ется п р и вилегирова н н о й опера­ цие й . Например, ун и версальн ы й пол ьзовател ь не может выразить намере н и е , что тол ько пол ьзователи alice и ЬоЬ должны и меть доступ к определ е н ному файлу.

П ос кол ьку м ногие п равила управл е н и я доступом встро е н ы в код отдел ь н ы х ко­ манд и демонов (классически й пример — програ м м а pas swd) , н е возможно пере­ о пределить поведе н и е систе м ы без измен е н ия исходного кода и переко м п ил яц и и . В реал ьном м и ре это непракти ч н о и провоцирует ошибки.

Стандартная модел ь также практически н е поддерживает аудит ил и веде н и е жур­ н ал а . В ы можете в идеть, к как и м группам U N IX п р ин адл ежит пол ьзователь, но не можете определ ить, что такое членство в груп пах позволяет п ол ьзовател ю де ­ лать. Кроме того, нет реал ьного способа отслеживать испол ьзование повы ш е н н ых привилегий или посмотреть, какие операции о н и выпол н ил и .

РАМ : п одключ аемые модул и аутентиф и ка ци и Уч етн ы е зап ис и п ол ьзователе й трад и ц и о н н о защи ще н ы парол я м и , хра н я щ и м ися (в заш ифрова н н о м виде) в файлах /etc/ shadow ил и /etc/master . pas swd ил и в экви­ вале нтной сетевой базе дан н ых. М но г и м п р о гра м м а м м ожет потребоваться проверка учетн ы х з а п и се й , вкл ючая login, sudo , su и л юбую програ м м у, которая требует регистраци и на рабоче й станц и и с графическим пол ьзовательск и м и нтерфейсом .

m Дополнительную информацию о файлах shadow и 111a s ter . passwd см. в разделе 8 . 3 . Э т и п рограм м ы де йствител ьно н е дол ж н ы и м еть жестко запрогра м м и р о ва н н ы х ожидан и й о том , как должн ы ш ифроваться и п рове ряться парол и . В идеале о н и даже

Глава 3. Управление досту п ом и п ривилегии су п ер п ользователя

119

не должн ы предполагать, что парол и вообще испол ьзуются. Что делать, если в ы хотите испол ьзовать биометрическую идентификацию, систем у иде нтифи каци и сети или ка­ кую-л ибо двухфакторную аутентификацию? На помощь приходят подкл ючаемые моду­ ли аутентификации РАМ ! РАМ ( PluggaЬle Autentication Modules) — это оболочка для разл и ч н ы х библ иотек ау­ тентиф и кац и и , реал изующих разные методы. Систе м н ые адм и н истраторы определя ­ ют методы аутентификаци и , которые они хотят ис пользовать в системе, а также соот­ ветствующие конте ксты для каждого из них. Програ м м ы , требующие аутентиф и кации пол ьзователя , просто вызывают с истему РАМ , а не реализуют собстве н н ые методы ау­ те нтификации . В с вою очередь РАМ вызывает библ иотеку аутентифи каци и , указанную с исте м н ы м адм и н истратором . Строго говоря , РАМ это технология аутентификации , а не техно­ логия контроля доступа. Следовательно, вместо ответа на вопрос » И м еет л и пол ьзова­ тел ь Х разрешение н а выполнение операции У? » , она помогает ответить на вопрос » Как узнать, что это действител ьно пользователь Х?» РАМ я вляется важным ком понентом цепочки контроля доступа в большинстве с и ­ сте м , а конфигурация РАМ я вляется общей адм и н истративной задаче й . Более подроб­ ную информацию о РАМ вы можете найти в разделе 1 7. 3 . —

Kerberos: сетева я крипто г рафическа я а утентифик а ци я Как и РАМ , протокол Kerberos занимается аутентификацие й , а не контролем досту­ па как таковым. Однако, есл и РАМ я вляется основой проверки подлин ности , Ke rbe ros я вляется специфическим методом аутентификаци и . В организациях, которые исполь­ зуют Ke rberos , РАМ и Kerbe ros, как п равило, работают в месте , РАМ — это оболоч ка, а Kerberos — фактическая реал изация. Протокол KerЬeros использует доверенную стороннюю организацию (сервер) для ау­ тентификации всей сети. Вы не аутентифицируете себя на маш и н е , которую испол ь­ зуете , а предоставляете с вои учетн ые дан н ы е службе Kerberos. Зате м Ke rberos в ыдает криптографические дан ные, которые вы можете представить другим службам в качестве доказательства вашей подлин ности. Kerberos — это зрелая технология , которая широко используется десятилетиям и . Это стандартная система ауте нтификаци и , используемая системой Windows, которая я вля­ ется частью системы Active Directory Microsoft . Больше о технологии Kerberos нап исано в разделе 1 7 . 3 .

Сп иски уп ра вления доступом к файловой системе Поскольку управление доступом к файловой системе крайн е важно для систем U N IX и Linux, это одна из главных целей их разработки. Наиболее распространенн ы м допол ­ нением была поддержка списков управле ния доступом (access control lists — ACL) , обоб­ щение традиционной модел и прав пользователь/груп па/друтое, которая позволяет уста­ навл и вать разрешен ия для нескольких пользователей и групп одновреме н но. Списки AC L я вля ются частью реал изации файловой систе м ы , поэтому они должн ы явно поддерживаться любой файловой системой , которую в ы испол ьзуете . Тем н е менее теперь все основные файловые систем ы U N IX и Linux в той или иной форме поддержи ­ вают АС L. Поддержка AC L обычно осуществляется в одной из двух форм : ран н и й вариант стан ­ дарта POS IX, которы й так и не дошел до формал ьного при нятия, но был широко реа-

Часть 1. Основы администрирования

1 20

лизован в любом случае , и система, стандартизован ная N FSv4, которая адаптирует AC L M icrosoft Wi ndows. Оба стандарта AC L описан ы более подробно в разделе 5.6. Ш Дополн ительную и нформаци ю о б N FS см . в главе 2 1 .

Возможности Linux С исте м ы мандатов (capabllity syste ms) делят полномочия учетной зап иси root н а нескол ько (около 30) отдел ьных разрешени й .

Версия систе м ы мандатов в Linux основана н а черновике проекта PO S IX 1 00 3 . l e , который ис пол ьзуется , несмотря н а то, что о н официал ьн о н е был одобрен в качестве стандарта. Л омимо прочего, теорети ки считают, что эта зомби-система не соответствует академ ической кон цепции с истемы мандатов. Однако это не важно; система существует, и Linux называет ее мандатной, поэтому м ы подч и н яемся . Мандаты могут быть унаследова н ы от родител ьского процесса. Он и та кже могут быть вкл юче н ы или откл юч е н ы атрибута м и , установл е н н ы м и в и с пол н яемом файл е , в процессе , напоминающем выпол н е н ие программы с флагом s e t u i d . Лроцессы могут отказаться от мандатов, которые они не планируют использовать. Традиционн ы е полномочия root это просто объединение всех мандатов, поэтому существует довольно прямое сопоставление между традиционной моделью и мандатной. Мандатная модел ь я вляется более детальной. В качестве примера укажем , что мандат Linux под названием САР NET _B I N D_ SERV I CE контролирует возможность процесса связывания с привилегированными сетевыми порта­ ми (номера которых меньше 1 024). Некоторы м демонам , которые традиционно работают с правами root, нужен только этот конкретн ый мандат. В системе мандатов такой демон может теоретически работать как непривилегированный пользователь и получать мандат на возможность привязки к порту из исполняемою файла. Лока демон не проверяет явно, что он работает от имени пользователя root, он даже не должен знать о нем. Так л и все это в реал ьном м ире? Совсем нет. Как это обычно бывает, мандаты эво­ л юционировали и стали более мощной технологией, чем система взаимодействия с поль­ зователями . О н и ш и роко испол ьзуются системами более высокого уров н я , таким и как AppArmor (см. раздел 3.4) и Docker (см. главу 25) , но редко используются самостоятельно. Для адм ин истраторов полезно просмотреть тап-страницу capaЬili ties ( 7 ) , чтобы понять, что включено в каждую из категорий мандатов. —

_

Простр анства имен Li nux Система Linux может распределять процессы по иерархическим разделам (пространствам имен), из которых видна только часть системных файлов, се­ тевых портов и процессов. Ломимо прочего, эта схема действует как форма превентивного контроля доступа. Вместо того, чтобы основывать реш е н ия управления доступом на потенциально тонких критериях, ядро просто отри­ цает существование объектов, которые не видны изнутри данной области . Внутри раздела применяются обычные правила контроля доступа, и в большинстве случаев процессы , которые бъm и ограниче н ы , даже не знают об это м . Лоскол ьку огра­ н ичение я вляется н еобратим ы м , внутри раздела процессы могут выполняться с правами root, не опасаясь, что они могут поставить под угрозу другие части с исте м ы . Этот ум н ый трюк я вляется одни м из оснований для программной контейнеризаци и и его наиболее известной реализации Docker. Полная система намного сложнее и вклю-

Глава 3 . Управление досту п ом и п ривилегии су пер п ользователя

1 21

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

3 .4. С ОВРЕМЕННЫЙ КОНТРОЛЬ ДОСТУ П А Уч иты вая ш и рокий диапазон выч исл ительных сред и с м е шан н ы й ус пех усилий по продвижен и ю стандартной модели , разработчики ядра н еохотно выступ ал и в каче­ стве посредников в более ш ироких дискуссиях по контролю доступа. В м ире Linux си­ туация активизировалась в 200 1 г. , когда Агентство национальной безопасности США предложило и нтегрировать свою с истему Enhanced Linux ( S E Linux) в ядро в качестве стандартного средства. По нескольким причинам сторонники ядра сопротивлялись этому слиянию. Вместо того чтобы испол ьзовать S E Linux или другую альтернативную систему, они разработали и нтерфейс уровня ядра API Linux Security Modules, позволяющий системам управления доступом и нтегрироваться в качестве загружаемых модулей ядра. Систе м ы н а основе LSM н е действуют, если пользователи не загрузили и не вклю­ чили их. Этот факт с нижает барьеры для включен ия в стандартное ядро, и система Linux теперь поставляется с SELinux и четырьмя другим и системами (AppAnnor, Smack, ТОМ ОУО и Yama) , готовыми к работе. Разработки на стороне BSD примерно совпадают с разработкам и Linux, в основном благодаря работе Роберта Уотсона ( Robert Watson) н ад TrustedBSD. Этот код был вклю­ чен в с истему FreeB S D , начиная с верси и 5. Он также предоставляет технологию песоч­ н и ц ы приложений, используемую в системах MacOS и IOS от Apple. Если одновременно задействованы несколько модулей управления доступом , для их разрешения должна быть утверждена отдельная операция. К сожалению, с истема LSM требует я вн ого сотрудни чества между а ктивными модул я м и , и ни оди н из существую­ щих модулей не включает эту функцию. На данн ы й момент систе м ы Linux фактически ограничены выбором одного дополн ительного модуля LSM.

Отдел ьные экосистемы Контроль доступа по своей сути относится к уровню ядра. За исключением списков управления доступом к файловой системе (см . раздел 5 . 6 ) , по существу, среди систем в отношении ал ьтернативных механизмов контроля доступа нет стандартизации . В ре­ зультате каждое ядро имеет свой собствен н ы й набор доступн ых реал изаций, и ни одна из них н е я вляется кросс-платформенной. Поскольку дистрибутивы Linux имеют общую линию ядра, все они теорети­ чески совместим ы со всем и раз.личными предложе н и я м и обеспечения без­ опасности Linux. Одн ако на практике это не так: эти систе м ы нуждаются в поддержке на уровн е пользователя в виде допол н ительных команд , моди­ фикаций компонентов уровня пользователя и профиле й защиты для демо­ нов и служб. Следовательно, у каждого дистрибутива есть только один или два механизма контроля доступа, которые он активно поддерживает.

Часть 1. Основы администрирования

1 22

О бя з ател ь н ы й ко нтр ол ь доступ а Стандартн ая м одел ь

U N I X расс матри вается как форм а » и збирательного контрол я

доступа» , пос кольку позвол я ет вл адельцам контрол и руем ы х доступом объектов устанав­ л и вать права на н их. Н а п р и м е р , вы можете разреш ить други м пол ьзовател я м просматр и ­ вать содержимое ваш е го домашнего каталога ил и нап исать программу с флагом s e t u i d , которая позволяет други м л юдя м отправлять с и гнал ы ваш и м процессам . Избирател ьное упра вл е н и е доступом не обеспечивает особой гарантии безопас ности дан н ых на пол ьзовател ьс ком уров н е . Поскольку пол ьзовател и имеют возможность уста­ н а вл и вать разреш е н и я сам остоятел ьн о ; н и кто не знает, что о н и могут делать со с во и м и собстве н н ы м и файла м и . Даже сам ы е благонамере н н ые и обуч е н н ы е пол ьзовател и могут ошибатьс я . С исте м ы мандатн о го у п ра вл е н и я доступом (mandatory access control

МАС ) по­

зволяют адм и н истратора м п и сать пол итики контроля доступа, которые переопредел я­ ют ил и допол н я ют изби ратель н ы е разре ш е н и я тради ц и о н н о й модел и . Н а п р и м е р , в ы можете установить правило, что домаш н и е каталоrи пользовател е й досту п н ы только и х владельцам . Тогда не важ но, что п ол ьзователь делает при ватную коп и ю конфиде н циал ь­ ного документа и небрежно относится к разреш е н ия м документа ; в л юбом случае н и кто н и ч е го не может увидеть в домашн е м каталоге этого пользовател я . М андаты

МАС

это эффективная технология для реализации моделе й безопасно­

сти , таких как с исте ма м ногоуров н е во й безопас н ости М и н истерства оборо н ы . В этой модели пол ит и ки безопас ности контрол ируют доступ в соответствии с вос п р и н и маемой се кретностью контрол ируе м ы х ресурсов. П ол ьзователя м назначается урове н ь безопас­ ности из структурированной иерархии. Они могут ч итать и писать документы н а том же уровне се кретности ил и н и же , но не могут получ ить доступ к доку м е н там с более высо­ к и м уровнем секретност и . Н а п р и м е р , пол ьзовател ь с уровнем » се кретно » может ч итать и п и сать секретные документы , но не м ожет ч итать докуме нты , которые классифициру­ ются как совер ш е н н о секретн ы е . Есл и вы н е обрабаты ваете с е крет н ы е дан н ы е для государствен н о го органа, малове­ роятно , что в ы когда- н ибудь столкнетес ь или захотите развернуть такие всеобъемлющие м одел и безопасност и . Ч а ще всего с исте м а МАС ис пол ьзуется дл я защиты отдел ь н ых служб , в п роти вном случае они остаются вне доступа пол ьзовател е й . Хорошо реализова н н ая пол ити ка МАС основывается на п р и н ц и п е наи м е н ьш их при­ вилегий ( разре шая доступ тол ько тогда , когда это н еобходимо) , поскол ьку правильно с проектирова н н ы й бра ндмауэр позволяет проходить тол ько определ е н н ы м признан н ы м службам и кл и е нтам . С исте ма МАС может поме шать компрометаци и с исте м ы с уязви­ мым программ н ы м обес пече н и е м (например, н а ос нове перепол н е н ия буфера) , огра н и ­ ч и в объе м наруше н и я д о нескол ьких кон кретн ых ресурсов , требуе м ых этому програ м м ­ н о м у обеспече н и ю .

К сожале н и ю , систе ма МАС стала ч е м -то вроде модного слова, с и н о н и мом » расш и­ ренного контрол я доступа » . Даже общ и й А Р l — и нтерфейс безопасности Free B S D назы ­

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

вается и нтерфе йсом

н и каких реал ьных фун к ц и й

до облегч е н н ы х рас ш ире н и й , которые предназнач е н ы для кон кретных предметных об­ ластей и с ценариев и с п ол ьзован и я . Общим для реал изаци й МАС я вл яется то , что о н и обыч но доба вл я ют в с исте му контроля доступа централ и зован н ы е , нап исан н ы е адм и­ н истратором ( ил и поста вл я е м ы е поставщиком ) пол ити к и , а также обыч ное сочетание разре ш е н и й файлов, с п и с ков управл е н ия доступом и атрибутов п роцесса.

Глава 3. Уп равление досту п ом и п ривилегии су п ер пользователя

1 23

Н езавис имо от области действия , системы МАС представляют собой потенциально знач ительное отклонение от стандартных с исте м , которое может оказаться неожидан ­ н ы м для проrрам м , основанных на стандартной модели безопасн ости U N IX. ПреЖде чем перейти к пол номасштабному развертыванию МАС , убедитесь, что вы понимаете правила ведения журнала модуля и знаете , как идентифицировать и устранять пробле­ мы, связанные с МАС.

Контрол ь доступ а на основе ролей Еще одна фун кция, которая обычно проверяется системами контроля доступа, — это контроль доступа на основе ролей (также известн ый как RBAC ) , теоретическая модель, формал изованная в 1 992 r. Дэвидом Феррариоло ( David Ferraiolo) и Риком Куном ( Rick Kuhn). Основная идея состоит в том , чтобы добавить слой косвенности в управление до­ ступом к вычислениям. Разрешения назначаются не пользователям непосредственно, а промежуточ н ы м кон­ струкци я м , называе м ы м ролями , а рол и , в свою очередь, назначаются пользователя м . Чтобы принять решение, связанное с управлением доступом, с истема перечисляет роли текущеrо пользователя и проверяет, имеют ли какие-л ибо из этих ролей соответствую­ щие разрешения. Роли похожи на разные rруппы U N IX, но они носят более общий характер, посколь­ ку моrут испол ьзоваться вне контекста файловой с исте м ы . Роли также моrут образовы­ вать иерархии, что значительно упрощает адм инистрирование. Например, вы можете определ ить рол ь «старшеrо адм инистратора » , которая и меет все разреш е н ия «адми н и ­ стратора» плюс допол нительн ые разрешения Х, У и Z. М ноrие верси и U N IX, вкл ючая Solaris, H P- UX и AIX, вкл ючают в себя н екоторую форму встроен ной систем ы R BAC. Систем ы Linux и Free B S D не и м е ют четкоrо, соб­ стве н ноrо средства RBAC . Однако она встроена в нескол ько более полных вариантов системы МАС.

SELinux: улуч шенн ая безопасность Li n ux S E Linux является одной из старей ш их реализаций систе м ы Linux М АС и я вляется продуктом Аrентства национал ьной безопасности С ША. В зависимости от точ ки зре ­ н ия , этот факт может быть источ н и ком уверенности или подозрительности .8 Система S E Liпux использует максимал истский подход и реал изует почти все возмож­ ности МАС и R BAC, которые можно себе представить. Н есмотря на то что она внедрена в нескольких дистрибутивах, ею, как правило, сложно упраалять и устранять неполадки. Приведем аноним ную цитату из старой версии страницы S E Linux в системе Wikipedia, ко­ торая передает разочарование, испытываемое мноrими системными адми н истраторами.

Как ни странно, хотя заявленное предназначение SELiпиx заключается в том, чтобы облегчить создание индивидуализированных политик управления доступом, специаль­ но предназначенных для практики и правил хранения данных в организациях, ее про­ грамм11ые инструменты настолько скудны и неудобны, что поставщики выживают главным образом благодаря консалтингу, который обычно принимает форму дополни­ тельных изменений в политике безопасности шаблонов.

8 Есл и вы склонны к подозрен и я м , то стоит отметить. что в качестве части дистриб уr и ва ядра Linux кодовая база S E Linux открьrrа для проверки.

Часть 1. Основы администрирования

1 24

Нес мотря на сложность управл е н и я , внедре н и е систе м ы S E Linux медлен но рас ш и ­ раяетс я , особенно в таких средах, как п равител ьстве н н ы е орга н ы , финансы и здравоох­ ран е н и е , которые и м е ют высокие и кон кретн ые требования к безопас ности. Она также я вл яется стандартной частью платфор м ы Android. Наше общее м не н и е относительно систе м ы S E Linux закл ючается в том , что она спо­ собна при нести бол ьш е вреда, чем пол ьз ы .

К сожал е н и ю , этот вред м ожет п роя вляться

не тол ько как потеря н ное вре мя и испорче н н ое настрое н ие с исте м н ы х адм и н истрато­ ров, но и , как это ни парадоксал ь н о , в качестве недостатков в области безопас ност и . Сложные модели трудно обсуждать , а S E Linux — это не ровное и гровое пол е ; хакеры , которые с п е ц иализируются на этой систе м е , пони мают ее гораздо л уч ш е , ч е м средн и й с исте м н ы й адми н истратор .

В частности , разработка пол итики S E Linux я вля ется сложной задаче й . Н а п р и м е р , дл я защиты нового демона политика должна тщател ьно перечислить в с е файлы , каталоги и другие объекты , к которы м процесс должен получ ить доступ. Для сложного про грамм ­ ного обеспечени я , такого как sendmail ил и httpd, эта задача может быть довольно слож­ ной. Например, одна компания предлагает треХдневный курс по разработке политики.

К счастью, м ногие общие политики доступн ы в режиме онлайн , и бол ь ш и н ство дис­ трибуrивов S E Linux и м е ют разу м н ы е знач е н и я по умолча н и ю . Их можно л е гко устано­ вить и настроить для кон кретной среды. Пол номасштаб н ы й редактор пол итики , цел ью которого я вл я ется обл е гч е н и е п р и м е н е н ия п ол итики , можно н айти на сайте s e e d i t .

sourceforge . net. С исте ма S E Linux хорошо поддержи вается систе мам и Red Hat ( и , следова-

RHEL

тельно, CentOS) и Fedora. Систем а Red Hat устанавливает ее по умолчан и ю .

� Систе м ы Deblan и S U S E Linux также и м е ют не которую доступ н ую поддержку S E Linux, но вы должны установить допол н ител ьные пакеты , а конфигу­

рация по умолчан и ю я вля ется более слабо й . Систе м а Ubuntu н асл едует н е которую поддержку S E Linux от Deblan, н о в посл ед н и х верс и я х Ubuntu и с п ол ьзуется систе м а AppArmor ( с м . дал ее ) . Н е которые руди м е нтарн ы е пакеты , относящиеся к S E Linux, по-прежн е м у досту п н ы , но о н и , как правило, н е обновл яются . Файл /etc / sel inux/ config — это элемент управления верхнего уровня для систем

SELinux. В нем есть и нтересн ы е строк и : S E L I NUX= e n f o r c i n g S E L I NUXT Y P E= t a r g e t e d П е р вая строка и м е е т т р и возможн ы х з н ач е н и я : e n f o r c i n g , p e r m i s s i v e ил и d i s a Ы e d . П арам етр e n f o r c i n g гарантирует, что загруже н ная пол ити ка п р и м е н я ется и запре щает наруш е н ия . Параметр ре rmi s s i ve допус кает н аруш е н и я , но регистр и ­ рует их в журнале s ys l o g , что полезно дл я отладки и разработки п ол ити к и . П араметр d i s aЫ e d пол н остью отключает систему S E Linux. Имя S E L I NUXTYPE представляет собой имя испол ьзуемой базы дан н ых пол итик. Это, по суr и , и м я подкаталог11 внуrри каталога /etc/ selinux. В оди н и тот же момент вре­ м е н и п р и м е н яться м ожет тол ько одн а пол итика, а досту п н ы е н аборы пол итик зависят от с исте м ы .

RHEL

П о умолчан и ю стратегия систе м ы Red Hat задается параметром t a r g e t e d и напраалена на обеспечение дополн ительной безопасности нескольких демонов, которые она явно защищает, предоставляя остальную часть систе м ы самой

Глава 3. Управление доступом и привилегии суперпользователя

1 25

себе. Ран ьше существовала отдельная политика, называемая s t r i c t , которая применяла стратегию МАС ко всей системе, но эта политика была объединена с политикой t a rgeted. Чтобы получить полную систему МАС, удалите модули unc on f i nedus и unco n f i nedu s e r с помощью команды semodule -d . Систе м а Red H at также определяет пол итику ml s , которая реали зует м ногоуровне­ вую зашиту Do D . Она устанавл ивается отдельно с помощью команды yum i n s t a l l sel inux -po l i cy-ml s .

Есл и в ы заинтересован ы в разработке собственных пол итик S E Linux, обратите в н и ­ м а н и е н а утилиту audi t2 allow. Она создает определения пол итики из журналов нару­ ш е н и й . Идея заключается в том , чтобы разреш ить защиту подсистем ы , регистрируя , но н е запрещая ее наруш е н и я . Затем можно подключить подсистему и создать политику, которая , по существу, позволяет этой подсистеме все. К сожалению, трудно гарантиро­ вать полное покрытие всех путей кода с помощью такого подхода, поэтому автоматиче­ ски созданные профил и вряд л и будут идеальн ыми.

AppArmor С истем а AppArmor я вл яется продуктом комп а ни и Canonical , Ltd . , в ы ­ п ус кающей дистрибутив Ubuntu. Она поддерживается систем а ми Deblan и Ubuntu, н о также б ыла при нята в качестве стандарта дистрибутивами S US E . Систе м ы U buntu и S U S E позволяют устанавливать ее по умолчанию, хотя н абор защищенных служб не я вляется обш и рн ы м . Система AppArmor реализует стратегию МАС и предназначен а в качестве дополне­ ния к традицион ной системе управления доступом U N IX. Н есмотря на то что возмож­ на л юбая конфи гураци я , AppArmor не предназначена для с исте м ы , ориентированной на пользователя . Ее основная цель — обеспечение безопасности , т.е. ограничение ущер­ ба, которы й могут нанести отдельные програ м м ы , если они будут скомпрометированы или запущены . Защище н н ые програм м ы по- прежнему подвергаются все м огран ичен и я м , нал ага­ е м ы м стандартной моделью, но, кроме того, ядро фильтрует их действия через назна­ ч е н н ы й и специфи ч н ы й для приложен ия профиль AppArmor. По умолчани ю с истема AppArmor отклоняет все запросы, поэтому профиль должен явно указывать все , что раз­ решено для процесса. Про гра м м ы без проф ил е й , таких как пользовательские оболоч ки, не и м е ют особых ограничений и работают так, как если бы с истема AppArmor не была установлена. Эта роль обеспечения безопасности службы , по сути, я вляется той же конфигураци­ ей, которая реализован а системой S ELinux в целевой среде Red Hat. Тем не менее си­ стема AppArmor разработан а специально для обеспечения безопасности, поэтому она скрывает н е которые из самых загадочных н юансов SELinux. П рофили AppArmor хранятся в файле / etc/ apparmo r . d , и относительно понят­ ны даже без подробного знания систе м ы . Например, вот профиль для демона cup s ­ browsed, входящего в с истему печати в операционной системе Ubuntu: # i n c l ude < t u n aЫ e s / g l ob a l > / u s r / s b i n / cup s -b r ow s e d ( # i n c l ude < ab s t ra c t i on s / b a s e > # i nc lude < ab s t r a c t i o n s / n ame s e rv i c e >

Часть 1. Основы администрирования

1 26 # in c l ude < a b s t ra c t i on s / c up s — c l i e n t > # i n c l ude < a b s t r a c t i on s /dbu s > # i n c l ude < a b s t r a c t i on s / p l l — ki t > / e t c / cup s / cup s — b rows e d . c on f r , / e t c / cup s / l p o p t i o n s r , / { va r / , } run / c u p s / c e r t s / * r , / va r / ca c h e / c up s / * r w , / tmp / * * r w ,

# S i t e — s p e c i f i c addi t i o n s and ove r ri de s . S e e l o c a l / README . # i nc lude < l oc a l / u s r . s b i n . c up s -b r o w s e d >

Бол ьшая часть этого кода я вляется модул ь н ы м ш аблоном . Н а n р и м е р , этот де ­ мон должен в ыпол нять поиск и м е н хосто в, поэтому nрофил ь и н терnол и рует nуть aьstractions /nameservi ce и предостамяет доступ к библ иотекам разрешений име н , файлам /etc/ns swi tch . conf и /etc/ho s ts , сетевым портам , испол ьзуемым протоко­ лом L DAP и т.д. И нформация профилирования, специфичная для этого демона, состоит (в дан ном случ ае ) из с писка файлов, к которы м может обращаться демон , а также разреш е н и й для каждого файла. С интаксис сопостамения шаблонов немного отличается: символ ы * * могут соответствовать н ескол ьким компонентам пути , а { va r / , 1 соответствует стро­ ке va r / в соответствующем месте пути. Даже этот простой профиль устроен довольно сложно. Есл и рас крыть все и нструк­ ции i include , то профиль имеет длину около 750 строк. (А ведь мы выбрали этот nри­ мер ради его краткости . Увы ! ) С истема AppArmoг ссылается на файл ы и програм м ы no и м е н и пут и , ч т о дела­ ет профили удобоч итаем ы м и и независ и м ы м и от какой-л ибо кон кретной реализации файловой с исте м ы . Однако этот подход ямяется компром исс н ы м . Например, с истема AppArmor не распознает жесткие ссылки, указывающие на оди н и тот же объект.

3.5. Л ИТЕРАТУРА •

F ERRAJOLo, Dлvю F. , D . R1cнлRD Ku н N , д N D Rлмлswлмv CндNDRAMOULI . Role-Based Access Control (2nd Edition) . Вoston, МА: Artech House, 2007.

HлrNEs, RrcнлRD. The SELinux Notebook (4th Edition). 20 1 4. Сбор н и к информации, относящейся к системе S E Linux, наиболее близкий к официал ьной документаци и. Доступен для загрузки на сайте f r e e compu t e rboo ks . с от.

VERM E U L E N , SvEN . SELinux Cookbook. Birmingham, U K: Packt PuЬlishing, 20 1 4. Кн и га, содержащая сам ые разнообразные советы по работе с систе мой S E Linux. В ней описаны модели обеспечения безопасности как служб, так и пол ьзователей.

Глава

4

Упра вление процессами

Процесс представляет собой выполняемую проrрамму. Это абстракция, с помощью ко­ торой можно управлять памятью, временем работы процессора и ресурсами ввода-вывода. Это аксиома философии U N IX, позволяющая к а к можно больше работать в кон ­ тексте процессов, а н е ядра. С исте м н ы е и пол ьзовател ьс к и е п роцессы соответствуют одни м и тем же правилам , поэтому вы можете испол ьзоват ь один набор инструментов для управления и м и .

4. 1 . КОМПОНЕНТЫ ПРОЦЕССА П роцесс состоит из адресного пространства и н аб ор а структур да н н ы х внутри ядра. Адресное пространство представляет собой н абор стр а н и ц памяти , которые ядро выде­ л ило для использования процессу. 1 Эти стран ицы содержат код и библиотеки, которые в ы полн я ются процессом , пере менн ые процесса, ero стеки и различ ную допол н итель­ ную информацию, необходимую ядру во время выполнения. В иртуальное адресное про­ странство процесса вьщеляется в физической памяти случайным образом и отслежива­ ется табл и цами страниц ядра. В структурах данных ядра хран ится всевозможная и нформация о каждом пр о ц е с се . К н аиболее важ н ы м относятся следующие сведения: •

табли ца распределения памяти, выделен ной процессу;

текущее состоян ие процесса ( неактиве н , пр и ос тан овл е н вы п ол няется и т. п . ) ;

приоритет процесса;

,

1 Стран и цы — это базовы е бло ки памяти , раз м ер которы х состамяет от 1 до 8 Кбайт.

Часть 1. Основы администрирования

1 28 •

и н формация о ресурсах, ис пользуемых процессом ( централ ь н ы й процессор , память и т.д. ) ;

информация о файлах и сетевых портах, открытых процессом ;

маска с и гн алов (запись о том , какие сигнал ы блокируются);

имя владельца процесса.

Поток — это контекст выполнения процесса. Каждый процесс и меет как м и н и мум оди н поток, но н е которые процесс ы могут и меть нескол ько потоков. Каждый поток, де йствуя в адресном пространстве внешнего процесса, и меет свой собстве н н ы й сте к и регистры центрального процессора В современн ых ком пьютерн ы х с истемах испол ьзуются нескол ько центральн ых про­ цессоров и н ес колько ядер внутри каждого центрального процессора. Такие м ногопо­ точ н ые приложения , как B I N D и Apache, извле кают максимал ьную пользу и з мул ь­ тиядерн ых с истем бла годаря тому, что эти приложе н ия могут отрабаты вать нескол ько запросов одновременно. Многие характеристики процесса непосредстве н но вли я ют н а е го выпол н е н и е . В частност и , имеет значе н и е , с кол ько вре м е н и выделяется е м у централ ьн ы м процес ­ соро м , к каким файлам он и меет доступ и т.д. В следующих подразделах рассмотр и м наиболее интересные с точки зре н и я системного адм и н истратора характеристик и про­ цессов. Они поддерживаются во всех версиях систем U N 1Х и Linux.

И дентификатор п роцесса P I D Ядро назначает каждом у процессу уни кальный идентификатор. Бол ьшинство команд и с исте м н ых вызовов, работающих с процессами , требует указания кон кретного иден ­ тификатора, чтобы был ясен контекст операции. Идентификаторы P I D присваи ваются по порядку по мере создания процессов. В настоящее время с истема Linux испол ьзует кон цепцию пространства имен процесса, которая е ще больше ограничивает способность процессов видеть друг друга и вли ять друг на друга. Контейнерные реализации используют эту фун кцию для разделе н и я процессов. Оди н из побоч н ых эффектов закл ю­ чается в том , что процесс может и м еть раз н ые P I D в зависимости от про­ стран ства и м е н набл юдателя . Это похоже на эйнштей новс кую относител ь­ н ость для идентификаторов процессов. Для пол уч е н и я допол н ител ьной и нформации см. главу 25.

И дентифи катор родител ь ского п роцесса PPID Н и в U N IX, н и в Linux нет с истем ного вызова, который б ы и ници ировал новый про­ цесс для выполнения конкретной программ ы . Для того чтобы породить новый процесс , существующий процесс должен клонировать сам себя. Клон может заменить выполняе­ мую программу другой. В операции клонирова н ия исходный процесс назы вают родительским, а его клон дочерним . П о м и м о собствен н о го иде нтификатора, кажд ы й дочер н и й процесс и м еет атрибут P P I D ( Parent Process I D) , который совпадает с идентификатором породившего его родительс кого процесса2• —

2 По крайне й мере первоначально. Есл и родительский процесс п о какой -то причине завершается ран ьше потомка, демон ini t или sytemd (процесс с номером 1 ) подставляет себя на место п редка (подробности описан ы в разделе 4. 2).

Глава 4. Управление п роцессами

1 29

Идентификатор родительс кого процесса — весьма полезная и нформация , если при­ ходится и м еть дело с н еизвестны м (и, возможно, нестандартно ведущим себя) процес­ сом. Отслежи вание истоков процесса может облегч ить понимание его назначения и зна­ ч имости. W Дополнительную и нформацию об идентификаторах U I D с м . в разделе 8 . 2 .

Идентификатор пол ьзователя U I D и текущий идентификатор пол ьзователя EU I D U I D ( Useг I D) — это идентификатор пол ьзователя , создавшего данн ы й процесс , точнее, копия значения U I D родительского процесса. Менять атрибуты п роцесса могут только его создатель ( владелец) и суперпользовател ь. m Дополнительную информацию об установке флага s e t u i d см в разделе 3 . 1 . E U I D ( Effective User I D) — это текущи й пользовательский идентификатор процесса, п редназначе н н ы й для того, чтобы определить, к каки м ресурсам и файлам у процесса есть п раво доступа в дан ный моме нт. У большинства процессов значения U I D и EU I D одинаковы . Исключение составля ют программ ы , у которых установлен бит смены иден­ тификатора пол ьзователя ( s e t u i d ) . Зачем н ужн ы идентификаторы U I D и E U I D’? Просто чтобы разграни ч ить понятия идентификаци и и прав доступа. К тому же програ м м ы с установлен н ы м битом s e t u i d н е все гда выполняются с расшире н н ы м и привилегиям и . В бол ьш и нстве с истем знач е ­ н ие E U I D можно устанавл и вать, чтобы предоставлять процессу дополнительн ые полно­ моч и я , и сбрасывать, чтобы отбирать их. В бол ь ш и н стве систем хран ится нач ал ь н ы й идентификатор, т.е . коп ия значе ния E U I D, которое имел процесс в начальной точ ке. Если процесс не удалит сохран е н н ы й идентификатор , его можно будет использовать в качестве реального или текущего иден­ тификатора. Благодаря этому » консервати вно» написанная программа с установленным б итом s e t u i d может большую часть времени работать с обычными привилегия м и , пере­ ходя в режим расширенных привилегий л и ш ь в определенные моменты. В с истеме Linux есть еще и нестандартн ый параметр FS U I D, определяющий возможности работы с файловой системой, но вне ядра он испол ьзуется редко и не переносится на другие с исте м ы U N IX.

Идентификатор групп ы (G I D) и текущий идентификатор груп п ы (EG I D) m Дополнительную информацию о группах с м . в разделе 8 . 2 . G I D ( G roup I D) — это иде нтификатор груп п ы , к которой принадлежит владеле ц процесса. Идентификатор EG I D связан с атрибутом G I D так же , как с атрибутом U I D, т. е . они будут отличатьс я , если программа запус кается с установл е н н ы м битом s e t g i d . В ядре назначение сохранен ного G I D для каждого процесса аналогично назначен и ю со­ храненного атрибута U I D. В знач ительной сте п е н и атрибут G I D процесса я вл яется рудиментар н ы м . С точ к и зрения определения прав доступа процесс одновременно может относиться к нескол ь­ ким группам. Список групп хран ится отдел ьно от значений G I D и EG I D. П р и анал изе прав доступа проверяется текущи й идентификатор и допол н ител ьн ы й список групп , но не значе н ие G I D.

1 30

Часть 1. Основы администрирования

Еди нствен ная ситуация , в которой атрибут G I D и м еет реал ьное значен ие , — созда­ ние процессом новых файлов. В зависи мости от установленных прав доступа в данной файловой с исте ме новые файлы могут принимать атрибут G 1 D создающего их процесса. Подробнее эти вопросы рассмотрены в разделе 5 . 5 .

Фактор уступч ивости П риоритет процесса определяет, какую дол ю времени централ ьного процессора по­ лучает програм ма. Ядро применяет динамический ал горитм вычисления приоритетов, уч итывающ и й , с колько вре м е н и це нтрал ьного процессора уже испол ьзовал процесс и скол ько времен и он ожидает своей очереди. Кроме того , учитывается заданный адм и ­ н истратором так назы вае м ы й фактор уступчивости, который определяет, в какой сте­ п е н и п рограмма может «делитьс я » процессором с другим и пол ьзовател я м и . П одробнее этот механизм рассм атри вается в разделе 4.4.

У п ра вля ющий терминал m Дополнительную информаци ю о стандартных канал ах связи см в разделе 7 . 2 . С большинством процессов, не я вляющихся демонам и , связан управляющий терм и ­ нал , которы й определяет базовую конфигураци ю стандартн ых каналов ввода, вывода и ошибок. От управляющего тер м и нала зависит также распределение с и гналов в ответ на события клавиатур ы , например нажатие клавиш < Ctrl + C > , о чем пойдет реч ь в раз­ деле 4. 2.

4.2. Жизненный цикл ПРОЦЕССА Для создания нового процесса существующи й процесс , как правило, клонирует сам себя с помощью с исте м ного вызова fork . 3 В результате форм ируется копия исходного процесса, и м е ющая л и ш ь некоторые отличия. В частности , новому процессу присваи­ вается собстве н н ы й иде нтификатор P I D , и учет ресурсов ведется для него независимо от предка. Систе м н ы й вызов fork и меет уникальное свойство: он возвращает два разных зна­ ч е н и я . В дочернем процессе это ч исло О , а в родительском — идентификатор P I D про­ цесса- пото м ка. Поскол ьку в остал ьном процессы иде нти ч н ы , они должны проверять результат вызова, чтобы определ ить, какую роль следует и грать в дал ьнейше м . После завершения системного вызова fork дочерний процесс обычно запускает но­ вую программу с помощью одного из систе м н ых вызовов семейства ехес. Все вызовы этого семейства заменяют програм му, выполняемую п роцессом, и устанавл и вают сег­ ме нты памяти в исходное состоя ние. Формы вызовов ехес различаются тол ько с посо­ бам и указания аргументов командной строки и переменных среды , передавае мых новой программе. При загруз ке с исте м ы ядро самостоятел ьно запус кает н е с кол ько процессов. Наиболее важ н ы й из них — демон ini t или sys temd с номером процесса, всегда рав­ н ы м 1 . Эти процессы отвечают за выполнение сценариев запуска с исте м ы , хотя харак3 Техн и чески

в с и стемах L i n u x испол ьзуется с и стем н ы й вызов c l one , рас ши р е н ие систе м ного в ызова fork , которое обрабатывает потоки и включает допол н ительные функци и . Систе м н ый в ызов f o rk остается в ядре для обеспеч е н и я обратной совмести мост и , но на самом деле он в ы полняет систем н ы й вызов clone.

Глава 4. Управление процессами

1 31

тер их действий в U N IX и Linux разл ичается. Все процессы, кроме тех, что создаются ядро м , я вл я ются пото м ками этих п роцессов. Допол н ительная и н формация о загрузке и демоне ini t содержится в главе 2 . Д е м о н ini t ( или systemd) и грает и другую важную роль в управлен и и процесса­ м и . Завершающийся п роцесс вызывает фун кцию _exi t, чтобы уведомить ядро о с воей готовности прекратить работу. В качестве параметра функции _exi t передается код за­ вершения — целое число, обозначающее причину прекращен и я процесса. По общепри­ нятому соглашению, нул ь свидетельствует об успеш ном завершении процесса. Ядро систем ы требует, чтобы, прежде чем процесс окончательно исчезнет, его удале­ н и е было подтверждено родительским процессом с помощью с исте м ного вызова wai t. Этот вызов возвращает код завершен и я пото м ка (или сообщает о причине е го уничто­ же н и я , если завершение не было естествен н ы м ) и в случае необходимости статистику использования ресурсов. Описанн ы й механизм работает нормально, если родительский процесс завершается позже порожденных им процессов и вы пол няет с исте м н ые вызовы wai t для их унич­ тожен и я . Если же родительский процесс завершается ран ьше срока, то ядро распозна­ ет, что вызова wai t не последует, и переназначает все «осиротевшие» процессы демону init ( ил и sys temd). Он берет их под с вой контрол ь, осуществляя дл я каждого из н их вызов wаi t.

Сигн ал ы С и г н ал ы — это за просы н а п р е р ы ва н и е , реал изуе м ые н а уро в н е процессов. Существуют свыше тридцати различных сигналов, и они находят самое разное приме­ нение. •

Сигналы могут посылаться между процессами как средство коммуни кации .

Сигн ал ы могут посылаться драй вером тер м инала для уничтожения ил и приоста­ новки процессов, когда пользователь нажимает специальные комбинации клави ш , такие как и л и < Ctrl+Z>4•

Сигналы могут посылаться в самых разных целях пользователем или адм и нистра­ тором с помощью команды kill.

Сигналы могут посылаться ядро м , когда процесс выполняет недопусти мую и н ­ струкцию, например деление н а нуль.

Сигналы могут посылаться ядром для уведомле н ия процесса о » представляющем интерес » событии , таком как пре кращение дочернего процесса или доступность данных в канале ввода-вывода.

W Дам п памяти — это файл , содержащий образ памяти процесса. Его можно испол ьзовать для отладки .

Когда поступает сигнал , возможен оди н из двух вариантов развития событий . Если процесс назначил сигналу подпрограмму обработки , то после вызова ей предоставляется информация о контексте, в котором был сгенерирован с игнал. В проти вном случае ядро выполняет от и м е н и процесса действия, заданные по умолчанию. Эти действия зависят от сигнала. М ногие с и гн ал ы приводят к заверше н и ю процесса, а в некоторых случаях при этом еще и создаются дам п ы памяти. 4Функци и , связан ные с комбинациям и клави ш < Ctrl+Z> или , мо�уг назначаться други м клави шам с помо щ ью команды s tty, но на практике такое встречается очень редко. В этой главе мы подразумеваем , что с данными клавишами связаны их стандартные функци и .

Часть 1. Основы администрирования

1 32

П роцедура вызова обработч и ка называется перехватом сигнала. Когда выпол н е н и е обработчи ка завершается , п роцесс возобновляется с той точ ки , где б ы л получе н сигнал. Для того чтобы определенн ые с и гнал ы не поступал и в програм м у, н ужно задать их и гнорирование ил и блокирование. И гнорируемый сигнал просто пропускается и н е вли­ яет на работу процесса. Блокируемый сигнал ставится в очередь на обработку, но ядро не требует от процесса н и каких действ и й до я вного разблокирования с игнала. Обработч и к вызы вается DJIЯ разблокированного си гнала только оди н раз, даже если в течение перио­ да блокировки поступило несколько аналогичных сигналов. В табл . 4. 1 перечисле н ы сигнал ы , которые должны быть известны л юбому системно­ му адм и н истратору. Традиционно и мена сигналов записываются про п ис н ы м и буквами. И ногда к именам добавляется префикс SIG ( например, S I GHUP). Табпи ца 4. 1 . Сиrнапы, которые допжен знать каждый администратор•

№’

Имя

1

HUP

2

з

9

10

11

15

17

18

19 28

30 31

Описание

Отбой Пре рывание QU I T Выход K I LL Уничтожение BUS Ошибка на шине S EGV Ошибка сегментации ТЕRМ Запрос на завершение STOP Остановка TSTP Сигнал остановки, посылаемый с клавиатуры CONT Продолжение после остановки W I NCH Изменение окна U S Rl Определяется пользовател ем U S R2 Определяется пользовате л е м INT

Реа кция

Дамn

ПО yмD.llЧ8HMIO

ПереХ88ТЫ веется ?

&покируетсt1?

Завершение Завершение Завершение Завершение Завершение Завершение Завершение Остановка Остановка

� � �

� � �

Нет

Нет

Нет

� � �

� � �

� �

Нет

Нет

Нет Нет Нет

Игнорируется

Нет

Нет

Игнорируется Завершение

� �

� �

Нет Нет

Завершение

Нет

памяти?

Нет Нет

» Список назван ий сигналов и номеров также можно получить с помощью встроенной в оболочку bash команды

kill — 1 .

«

Зависит о т используемой системы . Подробнее с м . файл /usr/ include/ s ignal . h или тап-страницы интерак-

тивного руководства для системного вызова s i g n a 1

()

.

Существуют и другие сигнал ы , н е показа н н ые в табл . 4. 1 ; большинство из н их со­ общает о загадоч ных ошибках, например » н е верная и нструкция » . По умолчани ю та ­ кие сигнал ы , как правило, приводят к завершению программы и созданию дампа ядра. П ерехват и блокирование сигналов обыч н о разрешен ы , так как есть достаточно «ум­ ные» програм м ы , устраняющие последствия ошибок. Сигн ал ы вus и S E GV также посылаются при возни кнове н ии ошибок. Мы вкл юч ил и их в таблицу, поскольку они чрезвычайно распространены: обы ч но программа аварийно заве ршается именно из-за н их. Сам и по себе эти си гнал ы н е и м е ют диагностической цен ности . Они лишь указы вают на факт неправил ьного обращения к памяти . С и гнал ы K I L L и S T O P н ел ьзя ни перехватить, н и заблокировать, н и проигнориро­ вать. Сигнал K I LL приводит к уничтожен и ю процесса, которому он посылается, а сиг-

глава 4. Управление п роцессами

1 33

нал S T O P приостанавл ивает выполнение процесса до получения сигнала CON T . Сигнал CONT можно перехватить и проигнорировать, но н ел ьзя заблокировать. С игнал T S T P представляет собой более » гибкую» версию сигнала S T O P . Проще всего описать е го как запрос на остановку. Он ге нерируется драйвером терм инала при нажа­ тии пол ьзователе м комбинации клавиш < Ctrl + Z > . П рограмм ы , перехватывающие этот сигнал , обычно выполняют операции очистки , а затем посылают сам и себе сигнал STOP. С другой сторо н ы , программы могут и гнорировать сигнал T S T P , чтобы их нельзя было остановить командой с клавиатуры . Хотя назначение сигналов K I LL , I N Т , TERM, HU P и QU I T может показаться одинако­ в ы м , в действительности они совершенно разные. •

Сигнал K I L L не блокируется и приводит к безусловному завер ш е н и ю процесса на уровне ядра. П о сути, процесс не успевает даже принять этот сигнал. Си гнал I N Т посылается драй вером терм инала п р и н ажатии пол ьзователем ком ­ бинации клавиш < Ctrl + C > и служит запросом н а завершение текущей операции . П ерехватив этот сигнал , простые программы должны заверш ить работу или позво­ л ить ун ичтожить себя стандартному обработчи ку сигнала. Програм м ы , в которых есть интерактивный режим командной строки, должны прекратить текущую опе­ рацию, выполн ить оч истку и снова перейти в режим ожидания. Сигнал ТЕRМ представляет собой запрос на завершение програм мы. П редполагается , что процесс , получ и вший этот сигнал , осуществляет очистку и завершается. У сигнала HU P есть две распространен ные интерпретаци и . Во- первых, м ногие де­ мон ы воспринимают е го как команду сброса. Если демон способен повторно про­ честь свой конфигурационн ы й файл и адаптироваться к изме н е н и я м без переза­ пус ка, с игнал HUP позволяет менять его поведение.

Во-вторых, этот с и гнал иногда генерируется драйвером терминала при попытке уничтожить с вязан ные с терм иналом процесс ы . В основном это поведен и е сохра­ н илось со времен испол ьзовани я проводных соедине ний терм и налов и модемов. Отсюда и название » отбо й » . Оболочки семейства С (tcsh и другие) обычно делают фоновые процессы невос­ приимчивыми к сигналу HUP, чтобы они могл и продолжать свою работу, даже когда пользователь выходит из системы. Пол ьзователи оболочек семейства Bourne ( k s h , bash и так далее) могут эмул ировать такое поведение с помощью команды nohup. Сигнал QU I T напоминает сигнал T E RM , за искл ючением того , что по умолчанию стандартный обработчи к создает дам п памяти .

Сигналы U S R l и U S R 2 не имеют стандартного назначения. И м и можно пользоваться в различных целях. Например, веб-сервер Apache и нтерпретирует сигнал нuв как запрос на немедле н н ы й перезапуск. Сигнал U S R l иници ирует более плавн ы й переход, в ходе которого разрешается закончить сеансы связи существующего клиента.

Кома нда kill: отп ра вка сигналов Команду k i l l чаще всего испол ьзуют дл я уничтожения процессов. Эта команда мо­ жет послать процессу л юбой сигнал , но по умолчанию это с игнал T E RM. Команду k i l l могут выпол н ять к а к рядовые пол ьзовател и (для своих собствен н ы х п роцессов) , так и суперпользовател ь (для любого процесса). Она имеет следующий с и нтаксис: kill [ — сигна л ] p i d

Часть 1. Основы администрирования

1 34

где сигнал это номер ил и с и м вол ическое имя посылаемого си гнала (см. табл . 4. 1 ) , а pid иде нтификацион н ы й номер целевого процесса. Команда kill без номера сигнала не гарантирует, что процесс будет уничтоже н , по­ с кольку сигнал TERM можно перехватывать, блокировать и и гнорировать. Команда $ kill — 9 p i d —

» гарантированно» уничтожает процесс, так как сигнал с номером 9 ( K I LL) не перехваты­ вается. Используйте команду kill — 9 тол ько в случае , есл и » вежл ивый» запрос на за­ вершение программ ы не был выполнен. М ы написали слово » гарантированно» в кавыч­ ках, так как иногда процессы переходят в такое состояние, в котором их нельзя завершить даже таким способом (обыч но это связано с блокировкой ввода-вы вода, например при остановке жесткого диска). Единственный выход в такой ситуации — перезагрузка. Команда k i l l a l l уничтожает п роцессы , заданные именем. Например, следующая команда уничтожает все процессы веб-сервера Apache. $ sudo killall httpd

Команда pki l l осуществляет поиск п роцессов, зада н н ых и м е н а м и (или други м и атри бута м и , напр и м ер E U I D) , и посылает найде н н ы м п роцессам с и гнал . Например, следующая команда посылает сигнал T E RM всем процессам , выпол н яе м ы м от и м е н и пол ьзователя b e n . $ sudo pkil l — u Ьеn

Состо я ни я п роцессов и потоков Как показано в предыдущем разделе , процесс может быть приостановлен сигналом STOP и возвращен в активную нагрузку с сигналом CONT. Состоян ие приостановления или выполнения применяется к процессу в целом и наследуется всем и потоками процесса. 5 Даже при ном и н ал ьнqм запуске потоки часто должн ы ждать, пока ядро заверш ит какую-то фоновую работу дпя них, прежде чем они смогут продолжить выпол н е н ие . Например, когда поток считы вает дан ные из файла, ядро должно запраш ивать соответ­ ствующие блоки диска, а затем упорядочи вать их содержимое для доставки в адресное пространство процесса запроса. В течение этого времени запрашивающий поток входит в состояние краткосрочного спящего режима, в котором он не может быть выпол не н . Однако другие потоки в одном процессе могут продолжать работать. Существуют процесс ы , которые называют «спящи м и » (например, в вы воде резул ь­ татов работы команды ps — см. следующий раздел ) . Поскол ьку атрибут сна относ ится к потоку, этот термин немного обманчив. Обычно процесс считается спящим, когда все его потоки я вл я ются спящими. Разумеется , различие остается спорным в случае одно­ поточных процессов, которые представляют собой наиболее распространен н ы й случай . И нтерактивные оболоч к и и систе м н ые демоны проводят большую часть вре м е н и , ожидая ввода дан н ых с терминала ил и сетевых подкл юче н и й . Поскольку спящий поток эффективно блокируется до тех пор, пока его запрос не будет удовлетворен , его процесс обычно не получает н и какого процессорного вре м е н и , если он не получает сигн ал или ответ на оди н из с воих запросов ввода-вывода. W Дополн ител ьную и нформацию об инсталляции файловой систе м ы N FS с параметром hard см. в разделе 2 1 .4. 5Аналоrичным образом можно управлять отдел ьными потока м и . Однако эти объе кты в первую очередь п редста вл я ют и нтерес дл я разработч и ков; с и сте м н ы е адм и н и страторы н е должны беспокоиться по этому поводу.

Глава 4. Управление процессами

1 35

Н е которые операци и могут привести к тому, что процессы ил и потоки войдут в со­ стоя ние беспробудного сна. Это состояние обычно я вляется переходн ы м и не набл ю­ дается в резул ьтате работы команды p s (оно обозначается бук вой D в столбце S T A T , с м . табл . 4 . 2 ) . Однако нескол ько специфических ситуаций могут привести к тому, что это состоян ие станет постоя н н ы м . Наиболее распростране нная причина с вязана с про­ бл е м а м и сервера в файловой систе м е N FS , и нсталл ирован ной с параметром h a r d . П ос кольку процессы в состоянии беспробудного сна н е могут просыпаться даже дл я об­ служивания с и гнала, они не могут быть пре краще н ы . Ч тобы избавиться от н и х , в ы должн ы устран ить основную проблему или перезагрузить ком пьютер.

4.3 . КОМАНДА Ps: ТЕКУЩИЙ КОНТРОЛЬ ПРОЦЕССОВ Команда ps основной инструмент, которым систе м н ы й админ истратор пол ьзует­ ся дл я текуще го контроля процессов. Версии этой команды различаются аргумента м и и выходны м формато м , н о , п о сути , выдают одну и т у ж е и нформацию. В основном , различие в версиях — это следствие разных путей развития систем U N IX. Кроме того , поставщики систем могут настраи вать эту команду с учетом конфигурации системы, так как она тесно связана с особен ностям и обработки процессов в ядре и поэтому часто от­ ражает изменен ия в ядре. С помощью команды ps можно пол уч ить и нформацию об иде нтификаторах P I D , U I D , приоритете и управляющем терм инале того или и ного процесса. О н а также по­ зволяет выяснить, какой объем памяти использует процесс, сколько вре м е н и централь­ ного процессора заняло е го выпол н е н и е , каково е го текущее состоян и е (выпол няется , остановл е н , простаи вает и т.д. ) . П роцессы-зомби в л истин ге команды обозначаются как < e x i t i n g > или . Команда ps безнадежно усложн илась з а последние нес кол ько лет. Не которые по­ ставщики оставил и попытки стандартизировать выходной формат этой команды и сде ­ лал и ее пол ностью конфигурируемой. Проведя небольшую настрой ку, можно получить практически л юбые требуе м ые результаты. —

В с истеме Linux команда ps я вля ется настоящ и м хамелеоном и понимает наборы опций из ряда других систе м . В отличие от остальн ых команд с и ­ сте м ы U N IX, команда p s в систе ме Linux восприн и мает флаги командной строка как с дефисом , так и без дефиса, хотя их интерпретация может ока­ заться разной . Например, результат выполнения команды ps — а отличается от результата выпол нения команды ps а. Не пугайтесь всех этих сложносте й : пусть они будут кошмаром разработч и ков ядра, а не системных админ истраторов! Дпя повседневной работы достаточ но знать л и ш ь н е ­ скол ько наиболее важных опций команды p s . П олучить сп исок всех процессов, в ы полняющихся в с истемах, можно с помощью команды ps aux. Ключ а означает, что мы хотим увидеть все процесс ы , кл юч х что мы хотим увидеть даже процессы, отсоединенные от управляющего тер м инала, а кл юч u обес печивает фил ьтрование по имени или идентификатору пользователя , который запу­ стил программу. Н иже показаны результаты работы команды ps aux в с исте ме Red Hat . —

r e dh a t $ p s aux U S E R P I D % C PU % МЕМ 0.1 0.2 root 1 о о root 2 о root 3 о

vsz 3356

RSS 560

о о

о о

ТТУ

? ? ?

S ТАТ

s SN S
по­ зволяет вернуться к предыдущим командам и вызвать их для редактирования. С помо­ щью комбинации клавиш < Ctrl + R> вы сможете шаг за шагом » прокрутить» свою » пре­ дысторию» и найти старые команды. Если вы предпочитаете использовать редактор v i , п ерекл юч и те свою командную оболоч ку в режим vi . $ set -о vi

В режиме vi редактирование является модальны м , но вы начинаете работать в ре­ жиме ввода команд. Для того чтобы выйти из режима ввода, н ажмите вначале клавишу < Esc > , а затем клавишу < i > , чтобы вернуться в него. В режиме редактирован ия нажатие клавиш и < w > переместит вас вперед на одно слово; испол ьзование комби нации кла­ виш позволит найти следующий символ «Х» в строке и т.д. » Прогул яться » по ко­ мандам , зафиксированным в » предыстории» , можно с помощью клавиш < Esc> и < k > . Реш ил и вернуться в режим редактирования emacs? Выполн ите следующую команду. $ set -о emacs

К аналы и перена п ра вление потоков Каждому процессу доступн ы по мен ьшей мере три информацион н ых канал а : «стан­ дарт н ы й ввод » ( S TD I N) , » стандартн ы й вы вод» ( S TDOUT ) и » стандартная о ш и б ка » (SТDERR) . Эти каналы устанавл иваются ядром систе м ы «от имени процесса » , и поэтому сам процесс не обязательно знает их направленность. О н и , например, могут быть свя­ заны с окном терм и нала, файлом, подключе нием к сети или каналом , при надлежащи м другому процессу. Для с истем U N IX и Linux испол ьзуется унифицирован ная модель ввода-вывода , в которой каждому каналу присваивается целое ч исло, име нуемое файловым дескрипто­ ром. Точ ное ч исло (номер ) , назначаемое каналу, обычно не имеет значе н и я , но каналам SТD IN, SТDOUТ и STDERR гарантированно соответствуют файловые дескрипторы О, 1 и 2 соответственно, чтобы обеспечить безопасное обращение к н и м по номерам . В контек­ сте и нтерактивного окна терминала канал SТDIN обы чно сч итывает дан н ы е с клавиату­ ры, а оба канала SТDOUТ и STDERR записывают свои выходные дан ные на экра н . Большинство команд с истемы U nix принимают входн ые дан н ы е из канала STDIN. Выходная информация записывается ими в канал STD OUT , а сообще ния об ошибках в канал SТDERR. Это соглашение позволяет объединять команды подобно строительн ы м блокам для организации кон вейерной обработки дан ных. Командная оболочка и нтерпретирует с и м вол ы » < » , » > » и » > > » как инструкции по изме нению направления передаваемых командой дан н ых в файл или принимаемых

Часть 1. Основы администрирования

224

дан ных из файла. Символ » < » связывает канал STDIN с содержим ы м некоторого суще­ ствующего файла. Символы » > » и » > > » перенаправляют поток STDOUT ; причем символ » > » используется для замены содержимого файла, а » > > » — для добавления дан ных в его конец. Например, команда $ qrep bash /etc /passwd > / tmp/bash-users

коп ирует строки , содержащие слово «bash » из файла /etc/pas swd в файл / tmp/bash­ users (при необходимости файл будет создан). Следующая команда упорядочивает со­ держимое этого файла и выводит резул ьтат на терминал . $ sort < / tmp /bash-users7 r o ot : x : O : O : r o o t : / r o o t : / b i n / b a s h

Для того чтобы перенаправить потоки STDOUT и STDERR в одно и т о ж е м есто, и с ­ пользуйте с и м вол » > & » . Для того ч тобы перенаправить тол ько поток STDERR, испол ь­ зуйте вариант » 2 > » . На примере команды f i nd можно показать, почему важно обрабаты вать потоки STDOUТ и SТDERR отдельно. Дело в том , что она форм ирует выходн ые данные по обо­ им каналам , особенно в случае ее выполнения н е привилегированн ы м пол ьзователе м . Например, п р и выполнении команды $ find / -name core

обычно генерируется так м ного сообщен и й об ошибках » permission denied» (отсутствие прав доступа) , что настоя щие результаты поиска теряются в » шуме » . Ч тобы отбросить все сообщения об ошибках, можно использовать такой вариант. $ find /

-name

core 2> / dev/null

В этой версии команды find только настоящие совпадения (где пол ьзователь имеет разрешение на чтение родител ьского каталога) выводятся в окно терминала. Чтобы со­ хранить список совпадающих путей в файле, выпол ните такую команду. $ find / -name core > / tmp/corefiles 2> /dev/null

Эта командная строка отправляет совпадающие п ути в файл / tmp / c o r e f i l e s , от­ брасы вая все ошибки и ничего не посылая в окно терминала. Для того чтобы связать канал STDOUT одной команды с каналом STD IN другой, ис­ пользуйте символ » 1 » Рассмотрим несколько примеров. .

$ find / -name core 2 > /dev/null 1 less

П ер вая команда в ыпол няет операцию find из предыдущего примера, но посылает список найденных файлов не в файл , а в программу постраничного вывода les s . $ ps — e f 1 qrep httpd

Здесь команда ps генерирует список процессов, из которого команда grep выбирает строки , содержащие слово httpd. Результат выполнения команды grep никуда бол ьше не перенаправляется , поэтому совпадающие строки попадают в окно терми нала. $ cut -d : -f7 < /etc/pas swd 1 sort -u

Здесь команда cut выбирает из файла /etc/pas swd пути к оболоч ке каждого поль­ зователя . Список оболочек затем отправляется через команду sort -u, чтобы сформи­ ровать отсортированный список уникальных значений. Для того чтобы последующая команда вы пол нялась тол ько в случае успеш ного вы­ полнения предыдущей , можно раздел ить эти команды с и м волом » & & » . Например, ко­ мандная строка $ lllkd ir foo && cd foo

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

Глава 7. Сценарии и командная оболочка

225

п ытается создать каталог с именем foo и в случае успеха выполняет команду cd. В данном случае успех выпол нения команды mkdir будет зафиксирован при получении кода завер­ шения, равного нулю. Использование для этой цели символа, означающего операцию «ло­ гическое И » , может сбить с толку тех, кто в других языках программирования использовал вычисления в сокращен ной форме записи. Если кому-то это непонятно, не стоит слишком долго здесь застревать; а просто примите это как идиому командной оболочки. И наоборот, символ » 1 1 » обеспечит выпол не н ие следующей ком анды только в том случае, есл и предыдущая команда не выпол нится (т. е . сгенерирует ненулевое значен ие кода завершения). $ cd foo

1 1 echo «No such directory»

Для того чтобы разбить команду на нескол ько строк, для наглядности отделяя тем сам ы м код обработки ошибок от остал ьной части командного кон ве йера, можно ис­ пользовать в сценариях обратную косую черту. ер — — p r e s e rve — — r e c u r s ive / e t c / * / s p a r e / b a c kup 1 1 e c h o » Di d NOT ma ke b a c kup «

Для получ е н и я обратного эффекта, т. е . объедин е н и я нескольких команд в одн о й строке , можно использовать в качестве разделителя точ ку с запятой. $ mkdir foo ; cd foo ; touch afile

Использование переменных и ка вычек В операциях присваивания имена переменных н и как не выделяются, но предваряются знаком доллара при ссылке на их значен ия . $ etcdir= ‘ / etc ‘ $ echo $ etcdir /etc

Н е ставьте д о и после знака равен ства ( ) пробел ы , в противном случае оболочка ошибочно примет имя вашей переменной за имя команды. При ссьшке на переменную можно заключить ее имя в фигурные с кобки, чтобы син­ такс ический анал изатор (да и сам человек) не сомневался в том , где заканчивается имя перемен ной и нач инается другой текст; например, используйте запись $ { e t c d i r ) вме­ сто $ e t c d i r . Обычно без фигурных с кобок можно обойтись, но они могут оказаться по­ лезны м и в случае, если вам понадобится раскрывать переменные в строках с двойн ы м и кавычками . Часто нужно сделать так, чтобы после значен ия пер е м е н ной стояли буквы или знаки препинания . Например, =

$ echo » Saved $ { rev } th vers ion of mdadm . conf . » S aved B t h ve r s i on o f mdadm . c on f .

Для имен перемен н ых командной оболочки не существует стандартного соглашения, н о обычно предполагается, что имена, пол ностью написанн ы е проп и с н ы м и буквами , принадлежат перемен н ы м среды ил и переме н н ы м , счита н н ы м и з файлов глобальной конфигураци и . И чаще всего все буквы в именах локал ьных пере м е н н ы х — строчн ы е , а отдельные их ком поненты разделя ются символами подчеркивания. Вообще имена п е ­ ремен н ых чувствительн ы к регистру букв. Командная оболочка интерпретирует строки, заключен н ые в одинарные и двойные кавычки, почти одинаково. Различие состоит в том , что строки в двойных кавычках служат субъектам и для универсал и заци и файловых и м е н (зам е н ы реал ьн ых с и мволов в и м е н и и расширении файла универсал ьн ы м и , т. е. так и м и метас и м волам и , как » * » и » ? » ) и для раскрытия переменных (зам е н ы пере м е н н ых их значениями). Например,

Часть l. Основы администрирования

226

$ $ I $ I

mylang= » Pennsylvania Dutch » echo » I speak $ { mylang } . » s p e a k P e nn s y l va n i a Du t c h .

echo ‘ I speak $ { mylang } . ‘ s p e a k $ ( my l a n g ) .

Обратные апострофы (также известные как обратные галочки, левые кавычки, л е ­ вые одиноч н ы е кав ы ч ки ил и откр ы вающие кавычки) и нтерпретируются аналогично двой н ы м кавыч кам , но несут при этом допол нител ьную нагрузку. Эта нагрузка состоит в интерпретаци и содержимого такой строки, как команды оболочки , выполнении этой команды и замене строки результатом выполнения этой команды. $ echo » Тhere are ‘ wc — 1 < / etc/passwd » lines in the pas swd file . » T h e r e a r e 2 8 l i n e s i n t h e p a s swd f i l e .

Перемен н ые окружения П р и запус ке процесса U N I X он получает с п исок аргуме нтов командной стро к и , а также набор перем е н н ых окружения. Большинство оболочек показывают вам текущее окружен ие в ответ на команду printenv: $ printenv E D I T OR VI U S ER = garth EN’ / gome / g a r t h / . b a s h r c L S COLORS e x f x gx g x d x g x g x b x b x c x c x PW D = /me g a / Docume n t s / P r o j e c t s / C o d e / s p l HOl’IE = / home / g a r t h . . . < t o t a l o f abou t 5 0 > =

=

=

По соглаше н ию имена переменных окружения набираются пропис н ы м и буквам и, но формально это не требуется. П рограмм ы , которые вы запускаете, могут обращаться к этим перемен н ы м и соответ­ ствующим образом изменять их поведение. Н апример, программа vipw проверяет перемен­ ную среды E D I TOR, чтобы определить, какой текстовы й редактор будет работать для вас. П ерем е н н ые окружения автоматически импортируются в пространство имен пере­ м е н н ы х sh, поэтому их можно установить и проч итать с помощью стандартного син­ такс иса. Чтобы превратить переменную оболочки в переменную среды, испол ьзуйте ко­ ма нду export имя_ переменной. Вы также можете комбинировать этот си нтаксис со значение м прис ваи вания , как показано здесь: $ export EDITOR = nano $ vipw < з а п ускае т р е д а к т о р n a n o >

Несмотря на то что они называются перем е н н ы м и окруже н и я , эти значения н е су­ ществуют в каком-то абстрактном месте вне пространства и вре м е н и . Оболочка пере ­ дает сн имок текущих значен и й в л юбую запущен ную вам и програм му, но при этом нет н и каких открытых соеди н е н и й . Более того , каждая оболочка ил и программа и каждое окно терминала имеют свою собстве н ную отдельную коп и ю окруже н и я , которая может быть изменена отдельно. Команды для переме н н ых окруже ния , которые вы хотите настроить во вре мя вхо­ да в систему, должны быть вкл юч е н ы в ваш файл � / . profile или � / . bash_p rofile. Другие перемен н ые среды , такие как PWD для текущего рабочего каталога, автоматиче­ с к и поддерживаются оболоч кой.

Глава 7. Сценарии и командная оболочка

227

Ко м а нды фил ьт раци и Л юбая корректная команда, которая считывает данн ы е и з канала STDIN и записы­ вает данные в канал STDOUТ, может испол ьзоваться в качестве фил ьтра (т. е . компонента конвейера) для обработки дан н ых. В этом разделе мы кратко рассмотр и м некоторые из наиболее широко испол ьзуемых команд фильтра, но список практически бесконечен . Команды фильтрации отличаются настол ько с ил ьн ы м » коллекти визмом » , что порой даже трудно продемонстрировать их и ндивидуальное использование . Большинство команд фильтра принимают одно или нескол ько и м е н файлов в ко­ мандной строке. Тол ько если вы не укажете файл , они прочитают дан н ы е из стандарт­ ного входного потока.

Команда cu t: раз бивка строк на поля Команда cut в ыводит выбра н н ы е части входных строк. Она чаще всего в ыделяет поля с раздел ител я ми , как в примере , показанном н иже , но также может возвращать сегменты , определ я е м ы е гран и ца м и столбцов. Раздел ителе м по умолчан и ю служит символ , но вы можете измен ить разделители с помощью опции -d. Параметр -f определяет, какие поля включать в вывод. П ример испол ьзования команды cut приведен н иже в разделе, посвященном коман­ де uniq.

Команда sort: сортир овка строк Команда sort сортирует входные строки. Звучит просто, да? Хотя на самом деле не все так безоблачно: существуют потенциальные н юансы, связанные с точно заданными частя­ ми сортируемых строк (т.е. с использованием сортировочного ключа) и порядком сортиров­ ки. Наиболее распространенные варианты применения этой команды показаны в табл. 7.2, в отношении же остальных случаев обратитесь к соответствующей тап-странице. Таблица 7 . 2 . Ключи команды sort Ключ команды -ь

-f

-h —

k

-n

З начение

Игнорировать ведущие пробельные символы Сортировать независимо от регистра букв Сортировать «читабельные» числа (например, 2Мб) Указывать столбцы, которые формируют сортировочный ключ Сравнивать полR как целые числа

-r

Изменить порRдок сортировки на противоположный

-t

Установить разделитель полей (по умолчанию — пробельный сим вол)

-u

Выводить только уникальные записи

Н а при мерах приведе н н ых н иже команд демонстрируется различие м ежду ч исло­ вой и лексикографической сортировкой ( последняя действует по умолчани ю ) . В обеих командах испол ьзуются ключ и — t : и — kЗ , З для сортировки файла /etc/group по е го третьему пол ю ( в качестве разделителя испол ьзуется двоеточие), содержащему иденти ­ фикатор ( I D) групп ы . Первая команда реал изует числовую сортировку, а вторая — лек­ сикографическую (в алфавитном порядке) .

Часть 1. Основы администрирования

2 28

$ sort — t : -kЗ , З -n /etc/group’ root : x : O : Ь i n : x : l : da emon da emon : x : 2 : $ sort — t : -kЗ , З /etc/group root : x : O : Ь i n : x : l : da emon users : x : lO O :

Также полезна опция -h, реализующая ч исловую сортировку, которая пони мает суф­ фикс ы , такие как м мя мега и G мя ги га. Например, следующая кома нда правильно со­ ртирует размеры подкаталогов в каталоге /usr, сохраняя корректность вы вода. $ du -sh /usr/ * 1 sort -h l бК 128К 648К 1 5М 2 0М 1 1 7М 1 2 6М 8 4 5М 1 . 7G

/us r/locale / u s r / l oc a l / u s r / g ame s /usr/ sЬin / u s r / i nc l ude /us r / s rc / u s r /Ь i n /us r / share /us r / l ib

Команда uniq: вывод уникальных строк Команда uniq по существу подобна команде sort -u, но у нее есть некоторые по­ лезн ые ключ и , которые команда sort не эмул ирует. Так, кл юч — с испол ьзуется мя под­ счета количества э кзе м пляров каждой строки , кл юч -d — для отображе ния тол ько строк, име ющих дубликаты , а ключ -u — для отображения тол ько строк , н е имеющих дубл и каты . При этом вход н ы е дан н ы е должны быть предварител ьно отсортирован ы , обычно путем » пропус кания » через команду sort. Например, по результатам выполнения следующей команды видно, что 20 пользова­ телей в качестве стартовой оболочки используют / Ь i n / b a s h , а остал ьн ы е 1 2 — /Ьin/ false. ( Последн ий результат характерен л ибо для псевдопол ьзователе й , л ибо мя поль­ зователей, учетн ые записи которых были заблокирован ы . ) $ cut — d : -f7 /etc/pas swd 1 sort 1 uniq — с 2 0 /Ьin /ba sh 1 2 /Ьin / fa l s e

Команда wc: п одсчет строк, слов и символов П одсчет кол ичества строк, слов и символов в файле — еще одна расп ространен н ая операция , удобн ы м средством реал изации которой и я вляется команда wc ( word count) . В ыполнен ная без каких-либо ключей, о н а выведет все три резул ьтата подсчета. $ wc /e tc/pas swd 32 7 7 2 0 0 3 / e t c /p a s s wd

В контексте написания сценариев команду wc часто приме няют тол ько с одн и м из кл юч е й ( — 1 , -w ил и — с ) , чтобы резул ьтат ее выполнения состоял из одного ч исла . Эту форму чаще всего можно встретить внутри обратных апострофов, и тогда результат мо­ жет быть сохранен ил и испол ьзован по назначению. н команда sort при н имает ключ -kЗ (а не -kЗ , З ) , но, вероятно, она не делает то, что вы ожидаете . Без номера завершающего поля кл юч сортировки действует до конца строки .

глава 7. Сценарии и командная оболочка

229

Команда tee: коп иро вание входного п от ока в два места Командны й кон вейер, как правило, действует пря мол и нейно, но зачастую полез­ но распараллелить поток данных, т.е . » перехватить» его и отправить коп ию в файл ил и окно терминала. Это можно сделать с помощью команды t e e , которая отправляет свой стандартный входной поток как в стандартн ый выходной канал , так и в файл , указа н ­ ный в командной строке . Представьте действие этой команды в виде тройн и ка в трубо­ проводе ( tee (ан гл . ) — тройник. — Примеч. пер. ) . Устрой ство / de v / t ty м о ж н о сч итат ь с и н о н и м ом для те куще го тер м и н ал а . Например, команда $ find / -nаше core 1 tee /dev/ tty 1 wc — 1

выводит найденные путевые имена файлов c o r e и результат подсчета их количества. Ч асто работа кон вейера с командой tee , выводя щей резул ьтаты и в файл , и в окно терми нала (для проверки ) , занимает м ного времени. Вы можете понаблюдать за первы ­ ми результатами, чтобы убедиться в том , что все работает как надо, а зате м смело уходи­ те: результаты сохран ятся в файле.

Команды head и tail: чтение файла с на чала или с ко нца П росмотр строк с начала или кон ца файла — обыч ная адм и н истративная операция. Команды head и tai l отображают по умолчанию десять строк, но вы можете испол ьзо­ вать кл юч , задающий желаемое количество строк. Для интеракти вного испол ьзования команда head уже нескол ько устарела, и вме­ сто нее ( в этом контексте) часто испол ьзуется команда les s , которая разби вает файл ы для отображен и я по страницам. Однако команду head можно успеш но применять в сце­ нария х и с другой цел ью. С командой ta i l ис пол ьзуется кл юч — f , котор ы й чрезвычайно полезен для с и ­ сте м н ых адм и н истраторов. Вместо не медл е нн ого завершен ия посл е вы вода требуемо­ го кол ичества строк команда tai l -f ожидает поступления новых строк, которые будут добавл е н ы в конец файла, а затем вы веде ны по назначению, что оче н ь удобно для мо­ ниторинга журналов регистраци и . Однако следует и меть в виду, что программа, которая реализует запись дан н ых в файл , может буферизи ровать свои выходные дан н ы е . Даже есл и строки будут добавляться регулярно (с точки зрения логики) , они могут стать види ­ мыми только фрагментами объемом 1 или 4 КиБ.9 Команды head и tai l получают несколько имен файлов из командной строки. Даже команда tail -f допускает испол ьзование нескол ьких файлов, и это довол ьно удобно; когда появляются новые результаты , подлежащие выводу на экран , команда tail выво­ дит имя файла, содержащего эти резул ьтаты. Для остановки процесса мон иторинга нажм ите комбинацию клавиш .

Команда grep: по иск текста При выполнении команды grep по мере просмотра входного текста выводятся стро­ ки, которые совпадают с задан ным образцом (шаблоном ) . Свое назван ие эта команда получ ила » в наследство» от команды g / р е гул я р н о е выраже н и е /р) из старого (и ныне действующего) редактора ed, испол ьзуемого в самых первых версиях U N IX. » Ре гул я р н ы е выраже н и я » ( regular expressions) — это шаблон ы , предназначен н ы е для поиска совпадающего с н и м и текста и написан ные на стандартном языке шаблонов. _

» И нформаuию о еди н и цах измерения см . в разделе 1 .6 главы 1 .

Часть 1. Основы администрирования

230

Они представля ют собой универсальн ы й стандарт, испол ьзуемый большинством про­ грам м при поиске по совпаден и ю с шаблоном , хотя и с небольш и м и различиями в ре­ ализациях. Странное имя команды уходит своими корнями в оригинальные изыскан ия соответствующих разделов теории вычислений. Более детал ьно си нтаксис регулярных выражений рассматривается в разделе 7.4. П одобно больш инству фил ьтров, команда grep и меет множество кл ючей . Например, кл юч — с позволяет выводить количество совпавших строк, ключ — i служит для и гнори­ рования регистра букв при сопоставлении, а ключ v предназначен для вы вода отл ича­ ющихся (а не совпавших) строк. Оче н ь полезным является кл юч -1 ( пропис ная буква » [;’ ) , который заставляет команду g r e p вы водить только имена файлов, содержащие со­ впавш ие с шаблоном строки, а не все совпавшие строки. Например, выполнение команды —

$ sudo grep -1 mdadm /var/ log/ * /va r / l og / a u t h . l o g /va r / l og / s y s l o g . O

демонстрирует, что записи с именем утил иты mdadm нашлись в двух разл ичных файлах системных журналов. Команду grep можно сч итать классичес кой реал иза цией базового механизма ис­ пользования регулярных выражений, но в некоторых версиях предлагается выбор других диалектов. Например, Linuх-команда grep -р служит для поиска выражений в стил е языка Perl . хотя в справочных страницах можно найти н еопределенное предупрежден ие о том , что такой вариант носит » экспериме нтальный характер» . Для пол ной уверенно­ сти в своих сценариях просто испол ьзуйте язык Ruby, Python или Perl. Есл и вы ф ил ьтруете с помощью команд tai l — f и grep , то добавьте параметр — — l ine -buffered, чтобы убедиться , что вы увидите каждую соответствующую строку, как только она станет доступной $ tail — f /var/ log/шessages 1 grep — — line-buffered ZFS Ма у 8 0 0 : 4 4 : 0 0 n u t r i e n t Z FS : vdev s t a t e chan g e d , pool_ g u i d= l 0 1 5 1 0 8 7 4 6 5 1 1 8 3 9 6 8 0 7 vdev_g u i d = 7 1 6 3 3 7 6 3 7 5 6 9 0 1 8 1 8 8 2

7 3 НАПИСАНИЕ СЦЕНАРИЕВ ДЛЯ ОБОЛОЧКИ .

.

Оболочка sh отл ично подходит для простых сценариев, которые автоматизируют то, что вы в противном случае вводил и бы в командной строке. Ваш и навыки командной строки переносятся на с ценарии sh, и наоборот, что помогает вам извлечь максималь­ ную отдачу от времени обучения. которое вы вкладываете в изучение оболочки sh. Но как только сценарий sh получает более 50 строк или когда вам нужн ы фун кци и . кото­ рых нет в оболочке sh, приходит время переходить на язык Python или Ruby. Для с ценариев есть см ысл ограничить себя диалектом , понятным исходной оболочке Вoume, которая является стандартом I EE E и POS I X. Оболочки , совместимые с sh, часто дополняют эту базовую линейку язы ковыми функциям и . Целесообразно применять эти расширения, если вы делаете это намеренно и хотите использовать кон кретн ый и нтер­ претатор. Однако чаще всего сценарии в конечном итоге испол ьзуют эти рас ш ирения непреднамеренно, и затем адм инистраторы удивляются , когда их сценарии не работают в других системах.

Глава 7. Сценарии и командная оболочка

231

В частности , не предполагайте, что версией оболочки sh в ваше й системе всегда яв­ ля ется bash, ил и даже , что оболоч ка bash доступна. В 2006 году с истема U buntu заме ­ нила bash на dash в качестве интерпретатора сценариев по умолчан ию, и в рамках это­ го процесса преобразован ия был составлен удобн ы й список команд, за которы м и нужно следить. Вы можете найти его на сайте wiki . uЬuntu . com/DashAsBinSh.

Выпол нение В оболочке s h комме нтарии начинаются с о знака # и продолжаются до конца стро­ ки. Как и в командной строке, вы можете разбить одну логическую строку на несколько физических строк, обозначи в переход на новую строку символом обратной косой черты ( ) . И, наоборот, можно поместить на одной строке несколько операторов, раздел ив их точкой с запятой. Сценарий для оболочки s h может состоять только из последовательности командн ых строк. Н апример, следующий сценарий hel loworld просто выполняет команду echo . # ! /Ь i n / s h echo » H e l l o , wo r l d ! «

П ервая строка содержит сочетан ие символов # ! , которое означает, что данн ы й тек­ стовый файл я вляется сценарие м , предназначенн ы м для интерпретации командной обо­ лоч кой из каталога /Ьin/ sh ( которая сама может служить ссылкой на оболочку da sh и bash) При принятии решения о том , как выполнить этот файл , ядро найдет соответ­ ствующий синтаксис. С точки зрения оболочк и , выполняющей этот сценар и й , пер вая строка представляет собой просто ком ментарий. Теоретически, если ваша оболочка sh находится в другом месте , вам придется отре­ дактировать первую строку. Тем не менее м ногие существующие сценарии предполага­ ют, что она находится в каталоге /Ьin/ sh, который с истемы вынужде ны поддержи вать, хотя бы через ссыл ку. Если вам нужен сценарий для запуска в оболочке bash или в другом интерпретаторе , который может не иметь одного и того же командного пути в каждой системе, вы може­ те испол ьзовать каталог /usr/Ьin/env для поиска перемен ной среды РАТН для опреде ­ лен ной команды. 1 0 Например, # ! / u s r / Ь i n /env ruby

является распространенной идиомой для запуска сценариев на языке Ruby. П одобно ка­ талогу /Ьin/ sh, каталог /usr/Ьin/env является настол ько широко распростране н н ы м вариантом, что все систем ы обязаны его поддерживать. Для того чтобы подготовить этот файл к выполнению, достаточно установить его бит, «отвечающи й » за выполнение (см. раздел 5.5). $ chmod + х hel loworld $ /helloworld’ 1 •

He l l o , wo r l d !

‘ » П ои с к п утей и меет последствия для безопас ности , особе н н о п р и запуске сценариев в среде см. в разделе 3 . 2 . 1 1 Есл и в а ш а оболочка п о н и мает команду he l l owo r l d без п рефи кса / , это означает, что в вашем п ути поиска указан текущи й каталог ( . ) . Это плохо, п оскольку дает друг и м пол ьзователям возможность устраи вать для вас »ловуш к и » в н адежде , что в ы будете п ытаться в ы п ол н ить определенные кома нды при переходе к каталогу, в котором он и и меют доступ д.1я зап иси . sudo . Допол н ител ьную и нформац и ю об обработке переме н н ы х окружен и я в среде sudo .

232

Часть 1. Основы администрирования

Можно также н епосредстве нно запустить (активизировать) оболочку в качестве и н ­ терпретатора сценария. $ sh helloworld

H e l l o , wor l d ! $ source helloworld

Hello, world !

Первая команда выпол н ит сценарий helloworld в новом экземпляре оболочки sh, а вторая — заставит вашу начал ьную оболочку прочитать содержимое файла, а затем вы­ пол н ить его. Второй вариант полезе н в случае , когда сценарий устанавл и вает перемен­ н ые среды ил и выполняет другие операци и настройки , примен и м ы е тол ько к те кущей оболоч ке. Обычно этот вариант испол ьзуется при написании с ценариев, включающих содержимое файла конфи гурац и и , написанн ого в виде ряда присваива н и й знач е н и й переме н н ы м . 1 2 m Дополнительную информаци ю о битах разрешения можно прочитать в разделе 5 . 5 . Есл и вы пришл и из м ира Windows, то вам привычно испол ьзовать понятие рас ш и ­ р е н и я файла, по которому можно судить о т и п е файла, а также о том , можно л и е го выпол н ить. В м ире U N IX и Linux признак того, может ли файл быть выполнен ( и если да, то кем ) , содержится в специал ьных битах пол номоч и й . При желании вы можете на­ делить свои Ьаsh-сценарии суффиксом . sh, который бы напом инал вам об их тип е , но тогда при выпол н е н и и соответствующей команды вам придется вводить суффи кс . sh, поскольку UNIX не интерпретирует расш ирения специальным образом.

От кома нд к сценариям Прежде ч е м переходить к особенностя м написания сценарие в дл я оболочки sh, оста­ новимся на методике этого процесса. Многие пишут эти сценарии так же , как на языке Python ил и Ruby, т.е. используя какой- н ибудь текстовы й редактор. Однако удобнее рас­ с матри вать в качестве и нтерактивной среды разработки сценариев режи м с приглаше­ н ием на ввод команды . Предположим , например, что у вас есть журнал ы регистраци и , именованные с суф­ ф и ксами . l o g и . LOG и разбросан н ы е по все й иерархической с истеме каталогов. Допустим также, что вы хотите изменить эти суффиксы , переведя их в верхн и й ре гистр. П режде все го, попытаемся отыскать все эти файлы . $ find . -name ‘ * log ‘

. do — no t — t ou c h / impo r t a n t . l og a dmi n . com- l o g / foo . l og g e n i u s / spew . l o g l e a the r _ f l o g

Ой! П охоже на то, что нам надо включить в шаблон точ ку и при поиске и гнориро­ вать каталоги . Н ажм ите комбинацию клавиш < Ct rl + P > , чтобы верн уться в режим ко­ мандной строки , а затем модифи цируйте ее. $ find . — type f -name ‘ * . l og ‘

. do — no t — t ou c h / imp o r t an t . l o g f oo . l o g 1 2 С и н о н и мо м для команды s ource служ ит команда в в иде точ к и ( dоt-команда ) , н а п р и ме р

. helloworld .

Глава 7. Сценарии и командная оболочка

233

geni u s / spew . l o g

Отл ично, это уже выглядит л учше. П равда, каталог do -not- touch (т.е. » н е тро­ гать») вызывает смутное чувство тревоги; но мы можем избавиться от него. .

$ find . — type f -name ‘ * . log ‘

1 grep

-v . do -not- touch

foo . l o g geni u s / spew . l o g

Прекрасно, м ы получили абсолютно точн ы й список файлов, которые должны быть переименованы. Попробуем сгенерировать несколько новых имен. $ > > >

find . — type f -name ‘ * . log ‘ 1 grep -v . do -not- touch 1 while read fname do echo mv $ fname ‘ echo $fname 1 sed s / . log/ . LOG/ ‘ done

mv foo . l o g foo . LOG mv geni u s / spew . l o g g e n i u s / spew . LOG

Да, это и менно те команды, которые позволят переименовать нужные файл ы . Как же их выпол нить? Мы могл и бы снова вызвать уже выполненную команду и отредакти­ ровать команду echo, чтобы заставить оболочку sh выполн ять команды mv, а не просто выводить их. Ведь передача команд в отдельную копию оболочки sh более надежны й вариант работы, который к тому ж е требует меньшего объема редактирования. Нажав комбинацию клавиш < Ct rl + P > , мы обнаруживаем , что оболочка bash забот­ ливо свернула наш м и ни-сценарий в одну-единствен ную строку. К этой » уплотненной » командной строке м ы просто добавляем канал , передаюший выходные данные команде sh -х. —

$ find . — type f -name ‘ * . log • do echo mv $fname ‘ echo $ fname

grep -v . do-not- touch 1 while read fname ; sed s / . log/ . LOG/ ‘ ; done 1 sh — х

+ mv f o o . l og f o o . LOG + m v geni u s / spew . l og g e n i u s / s pew . LOG

Ключ — х команды bash обеспечивает вывод каждой команды п еред ее выполнением. М ы завершили переименование файлов, но нам хотелось бы сохранить этот сцена­ рий, чтобы испол ьзовать его с нова. Встроен ная в s h команда fc п о своему действию во м ногом аналогична нажатию комбинации клавиш < Ct rl + P > , н о вместо возврата по­ следней команды в командную строку она передает команду в заданный вами редактор. Добавьте в свой файл строку идентификацион ного комментария , поместите сохранен­ ный файл в приемлемый ДJIЯ вас каталог ( например, /Ьin ил и /usr/local /Ьin) , сде­ лайте файл исполняемым, и вы получите настоящий сценарий. Итак, подытожим. …

1 . Разрабатывайте сценарий ( ил и его часть) в виде конвейера команд, причем по­ шагово и в режиме выполнения командных строк. 2. Пересылайте резул ьтат в стандартн ы й выходной поток, проверяя п равильность работы используемых вам и команд. 3. На каждом этапе используйте буфер ранее выполненных команд ДJIЯ их появле­ н ия в командной строке и и нструменты редактирован ия ДJIЯ их модификаци и . —

Часть 1 . Основы администрирования

234

4. П ока вы получаете не правил ьные результаты, можно сч итать, что вы, по сути , ничего не сделал и , и до тех nop, пока команды не заработают так, как надо, ниче­ го (из уже сделанного) не надо удалять. 5. Если результат выглядит правил ьн ы м , выполните команды на реал ьном примере , чтобы убедитьс я , •по все получ илось так, как ожидалось. 6. Испол ьзуйте команду fo, чтобы зафиксировать свою работу в редакторе , оформи­ те ее соответствующим образом и сохран ите. В п р и веде н ном в ы ш е п ри мере мы вывел и командн ые строки , а затем направил и их в подоболочку для выполнения. Этот метод не является универсально приме н и м ы м , но часто оказы вается полезн ы м . В качестве ал ьтернативного варианта можно фиксировать резул ьтаты , перенапрамяя их в фа йл . Терпеливо доби вайтесь получения нужн ых резул ь­ татов и , пока не увидите их, не вы полняйте н и каких потенциально деструктивн ых де й­ ствий .

Ввод и вы вод данн ы х Команда eoho не отл и чается сложностью, но зато проста в применен и и . Для полу­ чения большего контроля над вы водом дан н ы х испол ьзуйте ком анду printf. Она не очен ь удобна, поскол ьку п редполагает, что вы должны в явном виде указы вать в нуж­ н ых для вас местах символы перехода на новую строку ( n) , но позволяет испол ьзовать с и м вол табуляции и другие средства форматирования резул ьтата . Сравн ите результаты выпол н е н ия следующих двух команд. $ echo 11 taa t.ЬЬ tccn » t aa t bb t c c п $ printf 11 taatЬbtccn» ЬЬ се аа

И ногда работа команд eoho и printf поддерживается на уровне операцион ной си­ стем ы (обычно соответствующие им исполняемые файл ы хранятся в каталогах /Ьin и /usr/Ьin соответствен но) . Хотя эти команды и встрое нные в оболочку утилиты в целом подоб н ы , о н и могут иметь незнач ител ьн ые отл и ч и я , особен но это касается команды printf. Вы можете либо придерживаться sЬ-синтаксиса, л ибо вызывайте » вн е ш н юю» команду printf, указы вая ее п олн ы й путь. Для того чтобы сформ ировать для пользователя приглашение ввести дан н ые , можно испол ьзовать команду r e a d . # ! /Ьiп/sh e ch o — п » Eп t e r y o u r пате : r e a d u s e r пате

«

i f [ — п » $ u s e r _ пaтe » ] ; t h e n e ch o » H e l l o $ u s e r_пaтe ! » exit О else e ch o » G r e e t i пg s , пaтe l e s s опе ! » exit 1 fi

Ключ -n в команде eoho п ода вляет привычный переход на новую строку, но здесь была бы кстати команда printf. Мы еще рассмотрим вкратце синтаксис оператора if, но е го действие здесь, с нашей точки зре н ия , очевидно. Кл юч -n в операторе if обе-

Глава 7. Сценарии и командная оболочка

235

спечит значение исти н ы , есл и е го строковый аргумент н е окажется н улев ы м . Вот как выглядит результат выполнения этого сценария. $ sh readexample Ent e r y o u r n ame : Ron H e l l o Ron !

Пробел ы в именах файлов Именован ие файлов и каталогов, по существу, не регламентируется, з а исключением того, что имена ограничены по длине и н е должны содержать косо й черты или нул и . В частности , допус каются пробел ы . К сожалению, система U N I X и меет давнюю тради­ цию разделе н ия аргументов командной строки на пробел ы , поэтом у устаревшее про­ граммное обеспечение имеет тенденцию давать сбой , когда в именах файлов появляют­ ся пробелы . П робелы в именах файлов был и обнаружен ы прежде всего в файловых системах, со­ вместно используе м ых с ком пьютерами Мае и персональн ы м и ком пьютерами, но те­ перь они внедрил ись в культуру U N IX и также встречаются в некоторых стандартных пакетах программного обеспечения. Выхода нет: адми нистративные сценарии должны быть готовы обрабатывать пробелы в именах файлов (не говоря уже об апострофах, звез­ дочках и различных других угрожающих пунктуационных метках). В оболочке и в сценариях можно указывать имена файлов с п робелам и , чтобы дер­ жать их части вместе. Н апример, команда $ less «Му spacey file»

считает файл Му spacey file в качестве единствен ного аргумента команды les s . В ы также можете избежать отдельных пробелов с помощью обратной косой черты: $ less Му spacey file

Фун кция заверш е н ия и м е н и файла большинства оболоче к (зачастую привязанная к клавише ) обычно автоматически добавляет обратную косую черту. Когда вы пи­ шете с ценарии , полезн ы м оружием, о котором нужно знать, является опция -printO . В сочета н и и с параметром xargs — 0 она делает комбинацию find /xargs коррект­ ной, независимо от пробелов, содержащихся в именах файлов. Например, команда $ find / home-type f — s i ze + 1М -printO 1 xarqs -0 ls — 1

выводит на экран длинный список всех файлов в каталоге /home размером более одного мегабайта.

Функци и и аргументы ком андной стро ки Аргументы командной строки служат для сценария переменными с ч исловы м и име­ нами : $ 1 первый аргумент командной строки, $ 2 второй и т.д. Аргумент $ О со­ держит имя, по которому бьm вызван сценарий, например /Ьin/ example . sh, т. е . это не фиксированное значение. Переменная $ # содержит количество переданных аргументов командной строки , а перем е нная $ * все эти аргументы. Ни одна из этих перем е н н ых не учитывает аргу­ мент $ 0 . Рассмотрим пример использования этих аргументов. —

.

# ! /Ьin / sh s how_u s ag e ( ) e c h o » U s a g e : $ 0 s o u r c e di r de s t d i r » 1 > & 2

Часть 1. Основы администрирования

236

exit 1

# Зд е с ь начин а е т с я о с н о в н а я программа i f [ $ # -ne 2 ] ; t h e n s h ow_u s a g e e l s e # T h e r e a r e t w o a r gume n t s i f [ -d $ 1 ] ; t h e n s o u r c e_di r = $ 1 else e c h o ‘ I nva l i d s o u r c e d i r e c t o r y ‘ 1 > & 2 s h o w_u s a g e fi if -d $ 2 ] ; then d e s t_di r = $ 2 else echo ‘ I nva l i d de s t i n a t i o n di r e c t o r y ‘ 1 > & 2 s h o w_u s a ge fi fi p r i n t f » S ou r c e d i r e c t o r y i s $ ( s o u r ce_di r } n » p r i n t f » De s t i n a t i on d i r e c t o r y i s $ ( de s t_di r } n «

Есл и в ы вызываете сценарий без аргументов или с недействител ьны м и аргумента­ м и , сценарий должен вывести короткое сообщен ие об ош ибке , чтобы напомн ить вам , как е го испол ьзовать. В приведенном выше примере сценарий принимает два аргумен ­ та, подтверждает, что оба аргумента являются каталогам и , и выводит на экран их и ме­ на. Если аргументы недействител ь н ы , сценарий печатает сообщение об испол ьзовании и выходит с н енулевым кодом возврата. Если вызывающий сценарий проверяет код воз­ врата, он будет знать, что этот сценарий не удалось выпол н ить правильно. Мы создали отдельную функцию show u sage для печати сообщения об ис пол ьзо­ _ ван и и . Если впоследствии сценарий будет обновлен, чтобы принимать дополнительные аргументы , сообщение об испол ьзовании должно быть изменено только в одном м есте. Обозначение 1 > & 2 в строках, которые отображают сообщен ия об ошибках, выводит ре­ зультаты в поток SТDERR. $ mkdir ааа ЬЬЬ $ sh showusage ааа ЬЬЬ S ou r c e d i r e c t o r y i s а а а D e s t i n a t i on d i r e c t o r y i s ЬЬЬ $ sh showusage foo bar I nva l i d s ou r c e d i r e c t o r y U s a g e : s howu s a g e s o u r c e_d i r de s t di r

Аргуме нты для функций оболоч ки sh рассматриваются как аргументы командной строки. Первый аргумент $ 1 и т.д. Как бьшо показано выше, $ О остается именем сце­ нария . Ч тобы сделать пример более надежн ы м , м ы могл и бы заставить про грамму s h o w_ u s a g e получать в качестве аргумента код ошибки. Это позволит возвращать бол ее опре ­ дел е н н ы й код для каждого типа сбоя . Следующий фрагмент кода показы вает, как это может выглядеть. —

Глава 7. Сценарии и командная оболочка

237

show _ u s a g e ( ) { e cho » U s a ge : $ 0 s o u r c e_di r de s t_di r » 1 > & 2 i f [ $ # -eq О ] ; then e x i t 9 9 # E x i t w i t h a rb i t ra r y non z e r o r e t u r n code else exit $ 1 fi

В этой верси и подпрограм м ы аргумент не я вляется обязательным. Внутри с и м волы $ # сообщают, с кол ько аргуме нтов б ыло передано. Если не указан более кон кретный код, сценарий заканчивает работу с кодом 99. Однако конкретное значение, например show_u s a g e 5

приводит к тому, что сценарий заверш ает работу после вывода сообщения об использо­ вании именно с этим кодом. ( Перемен ная оболочки $ ? содержит статус выхода послед­ ней выполненной команды, н езависимо от того , используется она внутри сценария или в командной строке. ) В оболочке sh сильна аналогия между функциям и и командами. В ы можете опре­ делить полезн ые функции в файле � / . bash profile (�/ . profi l e для обы чной обо­ _ лочки sh), а затем использовать их в командной строке , как если бы они были команда­ м и . Например, если ваш сайт стандартизован на сетевом порту 7988 для протокола S S H (форма «безопасность через безвестность») , вы можете определить функцию s sh ( ) { / u s r / b i n / s s h -р 7 9 8 8 $ * }

в каталоге � / . bash profi le, чтобы функция команда s sh всегда выполнялась с пара­ _ метрам и р 7 9 8 8 . Как и м ногие оболочки, bash имеет механизм псевдонимов, который может воспро­ извести этот пример более точно, при этом функция становится все более уни версаль­ ной И МОЩНОЙ . —

Поток упра вления Выше в этой главе м ы уже рассмотрели несколько конструкций i f — t h e n и i f- t hen­ e l s e (они работают вполне ожидаем ы м образо м ) . Тер м и н аторо м ( признаком кон ца) для оператора i f служит оператор f i . Для образования цепочки i f-операторов можно испол ьзовать ключевое слово e l i f , означающее » e l s e i f » . i f [ $ b a s e — e q 1 ] & & [ $ dm — e q 1 ] ; t h e n i n s t a l l DMBa s e e l i f [ $ b a s e -ne 1 $ dm — e q 1 ] ; t h e n && installBase e l i f [ $ ba s e — e q $ dm — n e 1 ] ; t h e n && i n s t a l l DM else e c h o ‘ == > I n s t a l l i ng n o t h i n g ‘ fi

Как и специальный [ ] -синтаксис для выполнения операций сравнения, так и » пара­ метрические» имена операторов целоч исленного сравнения ( например, -eq ) являются наследием утилиты /Ьin / te s t из ран ней командной оболочки Сти вена Борна. В дей —

Часть 1. Основы администрирования

238

ствительности квадратные скобки — это не что иное, как условное обозначение вызова утил иты tes t ; они не явля ются частью оператора i f . 1 3 В табл . 7 . 3 собра н ы операторы оболочки b a s h , позволя ющие сравни вать ч исла и строки. В отличие от языка Perl , в оболочке bash используются текстовые операторы для ч исел и символические операторы для строк. Таблица 7.3. Элементарные операторы сравнения оболочки sh Строки

Числа

=

х -eq

х х

у

Истина, если у

х -ne у

!= у

х -lt у

х < у

х » у х >= у

х -ge у

х -gt у

х равно у х не равно

у

х меньше у

х меньше или равно у х больше у

х больше или равно у

-n х

х не равно значению n u l l

-z х

х равно значению nul l

» Здесь должна использоваться обратная косая черта или двойные квадратные скобки, чтобы предотвратить интер­ претацию символа > в символ перенаправления ввода-вывода.

В оболочке bash предусмотрен ы возможности оценки свойств файлов (снова-таки как освобождение от наследства / Ь in / te s t ) . Н екоторые из операторов тестирован ия и сравнения файлов приведе н ы в табл . 7.4. Таблица 7.4. Операторы п роверки файлов оболочки sh Оператор

Истина, если

— d фа йл

Файл файл существует и является каталогом

— е фа йл

Файл ф а йл существует

— f фа йл

Файл файл существует и является обычным

— r фа йл

У вас есть право доступа для чтения файла

— s фа йл

Файл файл существует и он не пустой

-w файл

У вас есть право доступа для записи в файл

фа йл l

— n t фа йл2

Файл файл l новее, чем файл2

файл l

-ot файл

Файл файл l старше, чем файл2

Несмотря на всю полезность формы e l i f , зачастую с точ ки зре н ия ясности про­ грам много кода лучше испол ьзовать структуру case. Н иже показан ее синтаксис на при­ мере функции, которая централизует процесс регистрации сценария . Кон кретные вари­ анты описываются закры вающи м и скобками после каждого условия и двумя точ ками с запятой, завершающим и блок операторов, который должен быть выполнен при реали­ зации заданного условия. Оператор case завершается ключевым словом esac. # Уро в е н ь пр о т околиро в ания у с т а н а вли в а е т с я в г л о б а л ь н ой # переменной LOG_ LEVE L . Во зможные варианты п е р е числены в пор ядке # от с амо г о с тро г о г о до наиме н е е с тро г о г о : E r ro r , W a r n i n g , I n f o и Debug . l o gMs g { me s s ag e l e ve l = $ 1 13Сейчас

эти оnераuи и встроен ы в оболочку и уже не запускают на выполнение утилиту /Ьin/ test.

Глава 7. Сценарии и командная оболочка

239

me s s age_i t s e l f= $ 2 i f [ $ me s s a g e_l e v e l — l e $ LOG_LEVEL ] ; t h e n c a s e $me s s a g e_l eve l i n 0 ) me s s a ge_l eve l_t e x t = » E r r o r » ; ; 1 ) me s s age_l e v e l _ t e x t = » W a r n i n g » ; ; 2 ) me s s a ge_l eve l_t e x t = » I n f o » ; ; 3 ) me s s a g e_l e v e l _t e x t = » Debug » , , * ) me s s a ge_l e v e l _t e x t = » Ot he r » e s ac e c h o » $ { me s s a ge_l evel_t e x t } : $me s s a g e_i t s e l f » if

Эта функция илл юстрирует общеприн ятую паради гму «уровня р е гистр ации ( log leve l ) , используемую м ногим и приложен и я м и адми н истр а ти в н о го характера. Код это­ го сценария позволяет генерировать сообщения на различных уровнях детализации, но действительно регистрируются или отрабатываются тол ьк о те из н их, которые » прохо­ дят» глобал ьно устанавливаемый порог $ LOG LEVE L . Ч то бы прояснить важность каждо­ го сообщения, его текст предваряется меткой , опис ы вающей соответствующий уровень регистрации. «

_

Цикл ы В оболочке s h конструкция f o r». i n позволяет упростить выпол н е н ие н екоторых действи й для групп ы значений или файлов, особен но при ун и в е рс ал и за ци и файловых име н , т.е . замене реальных с и м волов в и м е н и и рас ш ирении ун иверсальны м и ( напри­ мер, » * » и » ? » ) с целью формирован ия целых с п ис ков и м е н файлов. Шабл он * . s h в приведенном н иже цикле f o r позволяет обработать целый список совпадающих с н и м (шаблоном) имен файлов и з текущего каталога. О ператор f o r , проходя п о этому списку, по очереди присваивает имя каждого файла перемен ной s c r i p t . # ! / Ьi n / s h s u f f i x=BACKU P — — ‘ da t e + % Y — %m- % d — % H % M ‘ f o r s c r i p t in * . s h ; do n ewname= » $ s c r i p t . $ s u f f i x » e cho » C op y i n g $ s c r i p t to $ ne wn ame . ер -р $ s c r i p t $ newn ame done .

.

«

Вывод выглядит следующим образом: $ sh forexample Cop y i n g rhe l . s h to r h e l . s h . BACKU P — — 2 0 1 7 — 0 1 — 2 8 — 2 2 2 8 . . Cop y i n g s l e s . s h to s l e s . s h . BACKU P — — 2 0 1 7 — 0 1 — 2 8 — 2 2 2 8 . .

. .

В раскрытии имени файла нет ничего магического; в с е работает в точном соответ­ ствии с тем , как написано в командной строке . Другим и слова м и , с начала и м я файла раскрывается (т. е . шаблон заменяется существующи м и м е н е м ) а затем обрабатывается интерпретатором в развернутом виде . Имена файлов можно также вводить статически , как показано н иже : ,

f o r s c r i p t in r h e l . s h s l e s . s h ; do

240

Часть 1. Основы администрирования

В действительности любой список и м е н , содержащих пробел ьные символ ы ( включая содержи мое переменной) , обрабаты вается как объект циклической конструкции f o r.» in. В ы также можете опустить сп исок пол ностью (вместе с кл ючевым словом i n) , и в этом случае цикл неявно выпол няет итераци и по аргуме нтам командной строки сцена­ рия ( на верхне м уровне) или аргументы , переданные функци и : # ! /Ьin/ s h for file ; do n e wn ame= » $ ( f i l e ) . ba c ku p » e c h o » Co p y i n g $ f i l e t o $ n e wn ame . . . » ер -р $ f i l e $ ne wn ame done

Ц и кл ы в оболочке bash, в отл и ч ие от традиционной оболочки sh, ближе к циклам из традицион ных языков програм мирования, в которых задается стартовое выраже н и е , и н крементация и условие окончания цикла. Например: # ba s h — s p e c i f i c f o r ( ( i = O ; i < $ C P U_COUNT ; i + + ) ) ; do C PU_L I S T= » $ C PU_L I ST $ i » done

Н а примере следующего сценария иллюстрируется цикл wh i l e , который часто при­ меняется д11 Я обработки аргуме нтов командной строки и чтения строк файла. # ! /Ьin/ s h ехес

0 < / t r > , с которой с вязан этот шаблон , — это последнее возмож­ ное допустимое вхождение искомого элемента во входном тексте , что, наверняка , совсем не отвечает ваш и м намере н и я м . Вероятно , вы хотели отыскать совпадение с подстро­ кой < img > , за которой следует тег < / t r > . Тогда лучше переписать этот шаблон в виде < i mg [ » > ] * > < / t r> , что позволит распростран ить совпадение с начал ь н ы м и групповы­ м и с и м вола м и только до кон ца текущего тега благодаря явно задан ной невозможности пересечь гра н ицу, обозначенную правой угловой с кобкой. Можно также использовать «ле н и вые» ( в противоположность «жадны м » ) оператор­ ные выражения: * ? вместо * и +? вместо +. Эти варианты квантификаторов ограничива­ ют кол ичество вхожден и й искомых символов во входном тексте до минимально возмож­ ного. Во м ногих с итуациях эти операторы работают эффективнее и дают резул ьтаты . более близкие к желае м ы м , ч е м «жадные» варианты. Однако обратите в н и м а н и е на то , что «ле н и в ы е » квантифи катор ы ( в отл ич и е о т » жад н ых » ) могут давать разл и ч н ы е совпаде н и я ; разн и ца состоит не просто в и с ­ пользуемой реализации. В н а ш е м НТМ L-примере «ленивый» шаблон выглядел бы так: < img . * ? > < / t r > . Но даже в этом случае эле мент . * ? мог бы стать причиной внесения в резул ьтат ненужн ых нам сим волов » > » , поскол ьку следующим после тега < img > может быть не тег < / t r> . А такой результат вас , скорее всего, не устроит. 17Несмоrря на то что в этом разделе в качестве примеров обрабатываемого текста показаны фрагменты НТМL-кода, регулярные выражен ия — не самый подходя щий и н струмент в дан ном случае (что не п реминули отметить и наши рецензенты) . Языки Ruby и Pythoп имеют прекрасные расширени я , которые анализируют НТМ L-документы надлежащи м образом . Вы можете получить доступ к и нтересующи м вас п орциям с помощью Xpath- ил и СSS-селекторов. Подробнее о модульных ре позиториях соответствующих языков можно узнать, обратившись к стра н и це В и к и п еди и , посвященной языку запросов Xpath (XM L Path Language) и соответству ющим модулям в репозиториях.

Глава 7. Сценарии и командная оболочка

247

Ш аблон ы с нескол ь ки м и секци я м и гру пповых с и м волов могут » с п ровоцировать» анал изатор регулярных выраже н и й на экспоненциальное поведен и е , особе н но в случае , есл и порции те кста могут совпадать с нескол ьки м и шаблон н ы м и выраже н и я м и , и те м более в случае , если иском ы й текст в действител ьности не соответствует шаблону. Эта ситуация не я вл яется такой уж необычной , как может показаться , глав н ы м образо:-.� тогда , когда ш аблон сопоставляется с НТМ L-кодом . Очень часто вам придется искать конкретн ые теги , за котор ы м и следуют другие те ги, возможно, раздел е н н ы е третьи м и тегам и , и так далее, одн и м словом , вам придется создавать задание, которое потребует, чтобы анализатор проверил массу возможных комбинаций. Большой специалист в области ре гулярных выраже н и й Я н Гойвертс (Jan Goyvae rts) называет этот эффект катастрофическим откатом (catast rophic backtracking) и оп исыва­ ет его в своем блоге (за подробностя м и и н екоторыми уда ч н ы м и реше н и я м и обращай ­ тесь по адресу: r e g u l a r — e x p re s s i on s . i n f o / c a t a s t r o p h i c . h t m l ) . Из всего сказанного выше можно сделать такие выводы . •

Есл и вы можете организовать построчное сопоставл е н ие шаблона, а н е пофа й ­ ловое (т.е. с просмотром сразу всего файла) , знач ит, вы значител ьно умен ьш аете риск получения, мягко говоря , н изкой производительности. Несмотря на то что ре гулярные выражен и я я вля ются » жадн ы м и » по умолчан ию, вам , скорее всего, такие не нужны . Используйте «ленивые» операторы . Все экзем пляры специальных с и м волов » . * » по существу подозрительны и долж­ н ы быть тщательно исследова н ы .

7 5 П РОГРАММИРОВАНИЕ НА ЯЗЫКЕ РпноN .

.

Python и Ruby и нтерпретируе м ые я з ы к и с выраже н н ы м объе ктно-ориентирова н ­ н ы м уклоном. Оба о н и ш и роко испол ьзуются в качестве языков сце нариев общего на­ значения и имеют обширные библиотеки сторо н н и х модулей. М ы обсудим Ruby более подробно в разделе 7 .6. Я з ы к Python предлагает простой синтаксис, которы й обычно довол ьно л е гко отсле ­ живать, даже п р и чте н и и кода других людей . М ы рекоме ндуе м в с е м с исте м н ы м адм и н истраторам с вобод н о владеть я з ы ко :-1 Python. Это оди н из луч ш их среди современ н ых языков систем ного адм и нистрирования и обще го назнач е н и я . О н также ш ироко поддержи вается в качестве связующе го сред­ ства для использования в других системах ( например, в базе дан н ых Postgre S Q L и среде разработки Xcode от Apple). Он отлично взаимодействует с и нтерфейсом прикладного програ м м ирова н и я REST и и м еет хорошо разработа н н ы е библ и оте ки для м а ш и н ного обуч е н и я , анализа данных и выч исле н и й . —

Ст р асти по Python 3 Pyt hon уже ус п ел стать ос новн ы м я з ы ком н а п исан и я сце н а р и е в в м ире , когда в 2008 году поя вилась версия Python 3. В этой верс и и разработч ики реш ил и отказаться от обратной совместимости с Python 2, чтобы можно было реал изовать группу скром ­ ных, но фундаме нтальных изме н е н и й и исправл е н и й в языке, особен н о в области и н ­ тернационал изирован ной обработки текста. 1 8 1 кточн ы й с п и сок изменен и й в верс и и Python 3 не я вляется предметом нашего обсужде н и я . можете найти и х описание на стран и uе docs . python . org/ З . O /whatsnew/ 3 . О . htшl .

но вы

Часть 1. Основы администрирования

248

К сожалению, разверты вание верси и Python 3 потерпело фиаско. Обновл е н ия языка были впол н е разум н ы м и , но не обязательн ы м и для среднестатистического програ м м и ­ ста н а Python с существующей базой поддерживаемого кода. В течен и е дол гого време­ н и разработч ики с ценариев избегал и испол ьзования Python 3 , потому что их л юбим ы е библ иотеки не поддерживал и е го, в т о вре мя как авторы библиотек не поддерживал и Python 3, потому что и х кл иенты все еще испол ьзовали Python 2 . Даже в сам ых благоприятн ых обстоятел ьствах трудно подтолкнуть большое и взаи­ мозависимое сообщество пользователей к такого рода разры ву. В случае Python 3 борьба шла в течение большей части десятилетия. Одн ако по состоян и ю на 20 1 7 год эта ситуа­ ция, по-видимому, меняется. Библ иоте ки совместимости , которые позволяют одному и тому же Python- кoдy ра­ ботать в л юбой верси и языка , в какой-то сте п е н и облегч ил и переход. Н о даже сейчас версия Python 3 остается менее распространенной, чем Python 2. На момент написания этой статьи книги руЗ r e a d i ne s s . org сообщает, что только 1 7 из 360 луч ш их библиотек Python остаются несовместимыми с Python 3 . Однако дл и н н ы й хвост непереноси мого програм м ного обеспечения хорошо отрезвляет: тол ько н е многим более 25% библ иотек, хран ящихся н а сайте p yp i . p y t h o n . org ( и ндекс Python Package , или PyPI) работает под управлением версии Python 3 . 1 9 Конечно, м ногие из этих п роек­ тов устарели и бол ьше н е поддерживаются , но 25% по-прежнему является относительно небол ь ш и м числом.

Python 2 ил и Python З? Замедл е н н ы й переход привел к тому, что версии Pythons 2 и 3 стали рассматриваться как отдел ьн ые язы ки. Вам не нужно делать взаимоисключающий выбор — в л юбой си­ стеме можно запус кать обе версии одновременно без конфл иктов. Все наши илл юстративные систе м ы устанавливают версию Python 2 по умолчанию, обычно как /usr/Ьin/python2 с символической ссьmкой из /usr/Ьin/python. Python 3 может быть установлен как отдельн ы й пакет; двоичн ы й код н азывается pythonЗ.

RHEL

П роект Fedora работает н ад те м , чтобы сделать Python 3 с вое й верс и ­ ей по умолчан и ю , а систе м ы R e d H at и Cent O S н а м ного отстают и даже не определя ют п редварител ьно построен н ый пакет для верс и и Python 3 . Однако вы м ожете выбрать оди н из ре п озитор и е в E P E L Fedora ( Ext ra Packages for Enterprise Linux) . Для пол учения инструкций по доступу к это­ му ре позитор и ю , обратитесь в раздел FAQ на сайте f e d o r a p r o j e c t . o r g / w i k i / E PE L для получения и нструкци й по доступу к этому репозиторию. Его легко настроить, но точн ы е команды зависят от версии.

Есл и вы впер вые приступаете к разработке с ценариев ил и к п рограмм ирова н и ю на языке Python , имеет см ысл перейти непосредствен но к Python 3 . И ме н но е го с и н ­ такс ис м ы де монстрируем в этой главе , хотя на самом деле разн и ца между Pyt hon 2 и Python 3 в наш их простых примерах заключается тол ько в строках p r i n t . Для существующего программ ного обеспечения вы можете использовать л юбую вер­ сию Python , которую предпочитает Программное обеспечение. Если ваш выбор сложнее, чем просто новый или стары й код, обратитесь к вики-системе Python на w i k i . pyt hon . o r g / mo i n / Python 2 o r Python 3 , в которой содержится отличная коллекция задач , реше­ ний и рекоме ндаций . ‘�Для получен и я актуальной статистики с м . сайт caniusepythonЗ . com.

Глава 7. Сценарии и командная оболочка

249

Краткое введение в язык Python Для более пол ного ознакомления с языком Python м ы рекомендуем 5-е издание двух­ том н и ка Изучаем Python М ар ка Лутца ( M ark Lutz). Полную ссылку можно найти в раз­ деле «Л итература» . П р иведем коротки й сценарий » Hello, world ! » , которы й н ужно сохран ить в файле helloworld. # ! /us r / local /bin/pythonЗ p r i n t ( » H e l l o , wo r l d ! » )

Чтобы запустить е го , установите бит выпол н е н и я или вызовите интерпретатор pythonЗ напрямую. $ chmod +х helloworld $ . /helloworld Hello world !

Самы й крупн ы й разрыв Python с традицио н н ы м стил е м программирования заклю­ чается в том , что отступы имеют логический см ысл . Для разграничения блоков в язы­ ке Python н е используются фигурные и квадратные скобки или ключевые слова be g i n и end. Блоки автоматически форм ируются и з выраже н и й , находящихся н а одном уровне отступов. Точн ы й стиль отступов (пробелы или табуляция , а также глубина отступов) значения н е имеет. Создан ие блоков н а языке Python луч ш е всего показано н а при мере . Рассмотр и м простое выражен ие i f — t h e n — e l s e : imp o r t s y s а = s y s . a r gv [ l ] i f а == » 1 » : print print else : print print print ( ‘ Это —

( ‘ а равно 1 ‘ ) ( ‘ Э т о в с е еще р аздел t h e n инструкции i f . ‘ ) ( ‘ а это ‘ , а ) ( ‘ Э т о в с е еще р а здел e l s e инс трукции i f . ‘ ) вывод nосле инструкции i f . ‘ )

Первая строка импортирует модуль s y s , которы й содержит м асс ив a rgv. Две ветки инструкци и i f состоят из двух строк, каждая с отступом до одного уровн я . (Двоеточие в кон це строки обычно обозначает начало блока и связано с отступом , которы й следует за н и м . ) Окончательный оператор печати находится вне контекста оператора i f . $ pythonЗ Ыockexample 1 а равно 1 Э т о в с е е ще р а з дел t h e n инс трукции i f . Э т о — вывод после инструкции i f . $ pythonЗ Ыockexample 2 а ЭТО 2 Э т о в с е е ще раздел e l s e и н струкции i f . Э т о — в ыв о д после инс трукции i f .

Соглашение об отступах в языке Python я вляется менее гибким средством формати­ рования кода, но оно уме ньшает беспорядок, связанн ы й с использован ием скобок и то­ чек с запятой. Это требует перестройки от тех, кто привык к традиционн ы м разделите­ лям , но большинство людей в конечном итоге приходят к выводу, что им это н равится .

Часть 1. Основы администрирования

250

Функция p r i n t в языке Pyt hon при н и мает произвол ьное кол и чество аргум е нтов. Она вставляет пробел между каждой парой аргументов и автоматически передает новую строку. В ы м ожете подавлять ил и изменять эти с и м вол ы , добавляя опции e n d или sep = в конец списка аргументов. Н апример, с тро ка =

print

( » один » ,

«два » ,

» три » ,

s ep

» — 11

,

end

«!

n» )

п роизводит вы вод один — д в а — три !

Комментарии нач и наются с сим вола # и простираются до кон ца строки , как и в я зы ­ ках sh, Perl и Ruby. Можно разделить дл и н н ые строки, поставив обратные косые черты в местах разрыва строк. Когда вы это делаете , зн а че ние имеют тол ько отступы первой строки . Вы може­ те отступать в строках продолжен ия настолько далеко, наскол ько вам нравится. Строки с н е сб ала нс иро ван н ы м и кругл ы м и , квадратн ы м и ил и фигурными скобками автоматиче­ ски си гн али з ируют о продолже н и и даже в отсутствие обратн ых косых черт, но вы може­ те вкл юч и ть обратную косую черту, есл и это упрощает структуру кода. Н е которые операци и вырезания и вставки преобразуют символ ы табуляции в пробе­ л ы , и , есл и вы не знаете , чего хотите , это может привести вас в беше нство. Золотое пра­ вило гласит: » Ни когда не смешивайте табуляцию и пробел ы ; испол ьзуйте для отступов ил и то, ил и другое » . М ногие п р ограм мн ые средства делают традиционное предположе ­ н и е о том , что табул я ц и и эквивал е нтны восьми пробелам , что я вляется сли ш ком бол ь­ ш и м отступом для ч итаем ого кода. Больш и нство специал истов из сообщества Python, похоже , предпочитают пробелы и четырехси м вольные отступы. Впроче м , бол ь ш и нст�ю те ксто вых редакторов и м е ют варианты , котор ые могут по­ мочь сохран ить ваш е душевное равновесие, либо путе м запрета табуляции в пользу про­ белов, либо путем разного отоб ражения пробелов и табуляции. В крайнем случае вы мо­ жете перевести табуляцию в п робел ы с помощью команды expand.

Объ екты , с т роки , ч и сла , списки, слова ри, кортежи и файл ы Все типы данн ы х в языке Pyth o n я вляются объектам и , и это дает им бол ьшую мощ­ ность и гибкость, чем о больш инс тве других языков. В языке Python с п и с ки закл юч е н ы в квадратные с кобки и и ндексируются с н уля. Они по существу похожи на масс и в ы , но могут содержать объекты л юбого типа.20 В языке Python есть кортежи , которые, по сути, явля ются неизм е н н ы м и с п искам и . Кортежи эффе ктивнее, ч е м с п ис к и , и полезн ы для представления постоян н ых дан ных. С интакс ис кортежей такой же , как и для с п исков, за исключением того , что в качестве раздел ителей испол ьзуются кругл ые , а не квадратные с кобки . П ос кол ьку вы ражен и е ( t h i ng ) в ыглядит как п ростое ал гебраическое выражение, кортежи , содержащие тол ь­ ко оди н элемент, должны содержать запятую, и грающую роль маркера, чтобы устран ить неоднозначность: ( t h i ng , ) . П р и ведем нескол ько основ н ы х переменных и типов дан н ых в языке Python: n ame = ‘ Г в е н ‘ rat ing 10 charac t e r s [ ‘ Губка Б об ‘ , =

=

‘ Па трик ‘ ,

‘ С квидвард ‘ ]

20 0днородн ый и более эффективн ый тип масси ва реализован в модуле array, но для бол ьшинства целей м ы рекомендуем использовать списки .

Глава 7. Сценарии и командная оболочка

251

e l eme n t s = ( ‘ литий ‘ , ‘ углерод ‘ , ‘ б ор ‘ ) p r i n t ( » Имя : t % s n Р ейтин г : t % d » % ( n ame , p r i n t ( » П е р с онажи : t % s » % c h a r a ct e r s ) p r i n t ( » Кумир : t % s » % c h a r a c t e r s [ O ] ) p r i n t ( » Элеме н ты : t % s » % ( e l eme n t s , ) )

rating ) )

В этом примере получается следующий результат: $ pythonЗ obj ects Г в ен Имя : 10 Рейтинг : Персонажи : [ ‘ Губка Б об ‘ , ‘ Па тр и к ‘ , ‘ Сквидвард ‘ ] Кумир : Губ ка Б о б ( ‘ ли тий ‘ , ‘ углерод ‘ , ‘ б ор ‘ ) Эле м енты :

Обратите внимание на то, что стандартное преобразование строки для типов списка и кортежей представляет их в том виде , в котором они были введены в исходном коде . Переменные в языке Python не я вляются синтаксически помеченными или не име­ ют объявления типа, но объекты , к которым они относятся , имеют базовый тип. В боль­ шинстве случаев Python не конвертирует типы автоматически , но отдельные функции или операторы могут это сделать. Н апример, вы не можете объединить строку и ч исло (с по­ мощью оператора +) без явного преобразования ч исла в его строковое представление. Тем не менее операторы и инструкции форматирования приводят все к строковой форме. Как показано выш е , каждый объект и м еет строковое представление . Словари , спи­ ски и кортежи рекурсивно форм ируют с вои строковые представлени я , создавая их со­ ставные элементы и комбинируя эти строки с соответствующей пунктуацией. Оператор форматирования строк % очень похож на функцию s p r i nt f и з языка С, но его можно использовать везде, где может появляться строка. Это двоичный оператор, который берет строку слева и значен и я , которые нужно вставить справа. Если необхо­ димо вставить более одного значения, значения должны быть представлены как кортеж. Словарь в языке Python (также известны й как хеш или ассоциатив н ы й массив) пред­ ставляет собой набор пар кл юч-значение. Хеш можно представить как масси в , чьи и н ­ дексы (кл юч и ) я вляются произвольными значе н ия м и ; они не должны быть цифрам и . Однако н а практике цифры и строки я вляются общими кл ючами . Словарные л итералы закл ючены в фигурные с кобки, каждая пара ключей-значений разделяется двоеточием . При использовании словари работают так же, как списки , за ис­ ключением того, что индексы (ключи) могут быть объектам и , отличны м и от целых чисел . ordinal { 1 : ‘ пер вый ‘ , 2 : ‘ в т ор ой ‘ , 3 : ‘ тр е т ий ‘ p r i n t ( » Упорядоченные слов арные литералы : » , o r d i na l ) р r i n t ( » Пер вый литерал : » , o r d i n a l [ l ] ) =

$ pythonЗ dictionary Упор ядоче нные словарные литералы : Первый литерал : п е р в ый

{1:

‘ первый ‘ , 2 :

‘ в т ор ой ‘ ,

3:

‘ тр е тий ‘ )

Python обрабатывает открытые файлы как объекты со ассоциированн ы м и методами . В соответствии с о с вои м названием метод rea d l i ne ч итает одну строку, поэтому в при­ веденном н иже примере считываются и в ыводятся на печать две строки из файла /etc/ pas swd. f = ope n ( ‘ / e t c / pa s swd ‘ , ‘ r ‘ ) p r i n t ( f . r e a d l i n e ( ) , end= » » ) p r i n t ( f . r e a d l i n e ( ) , end= » » ) f . close ( )

Часть 1. Основы администрирования

252

$ pythonЗ fileio root : x : O : O : root : / root : /bin/bash d a emon : x : l : l : d a emon : / u s r / s b i n : / u s r / s b i n / n o l o g i n

Переход на новую строку в кон це вызовов фун кции p r i n t подавляется с помощью параметра end » » , потому что каждая строка уже содержит символ перехода на но­ вую строку из исходного файла. Python не разделяет их автоматически. =

Пример п роверки ввода В следующем сце нарии показана общая схема проверки ввода в языке Python. О н также демонстрирует определение функций и испол ьзован ие аргументов командной строки, а также пару других специфических особенностей . i mp o r t s y s i mp o r t o s d e f s h ow_u s a g e ( me s s a g e , c ode 1) : p r i n t ( me s s a ge ) p r i n t ( » % s : и с ходный к а т а л о г целе вой к а т а ло г » % s y s . a r gv [ O ] ) s y s . e x i t ( c ode ) =

i f len ( sys . a rgv) ! = 3 : s h ow_ u s a g e ( » Hyжны 2 а ргуме н т а ; в ы в в е ли один % d » % e l i f n o t o s . pa t h . i s d i r ( s y s . a r gv [ l ] ) : s h ow_u s a ge ( » Иcx oдный к а т а л о г не найде н » ) e l i f n o t o s . pa t h . i s d i r ( s y s . a r gv [ 2 ] ) : s h ow_u s a g e ( » Ц e л e в o й к а т а л о г н е найд е н » )

( l en ( s y s . a r gv )

1) )

s ou r c e , d e s t s y s . a r gv [ l : З ] р r i n t ( » И с ходный к а т а л о г : » , s ou r c e ) р r i n t ( » Целе в ой к а т а л о г » , d e s t ) =

Помимо и м порта модуля s y s , м ы также импортируе м модуль o s для доступа к про­ цедуре o s . p a t h . i s d i r . Обратите внимание на то, что им порт не сокращает ваш доступ к любым символам , определен н ы м модулями; вы должны использовать полностью ква­ лифицированные имена, которые начинаются с имени модуля . О пределение п одпрогра м м ы s h ow u s a g e предоставляет значение по умолчан и ю для кода выхода, если вызывающий объект явно н е указывает этот аргуме нт. Поскольку все т и п ы дан н ы х я вля ются объе кта м и , аргуме нты фун кции эффективно переда ются по ссылке. В первой позиции с писок s y s . a r g v содержит имя сценария , поэтому е го дл и н а больше, ч е м коли чество аргуме нтов командной строки , которые были фактически пре­ это с писок фрагментов. Л юбопытно, что срезы доставлены. Форма s y s . a r gv [ 1 : З ] н е вкл ючают эле м е нт в дальнем конце указанного диапазона, поэтом у этот фрагмент включает только элементы s ys . a rgv [ 1 ] и s y s . a rgv [ 2 ] . Чтобы включить второй и по­ следующие аргументы, можно просто написать s y s . a rgv [ 1 : ] . Как и в sh, в языке P_ython есть специальное условие «else if’ ; ключевым словом я в­ ляется e l i f . Но в нем нет явной инструкции c a s e или s w i t c h . Параллел ьное присваивание переменных s ou r c e и de s t нем ного отличается о т н е ­ которых языков тем , что сам и переменные н е входят в список. Python допускает парал­ лельные назначения в любой форме. В я з ы ке Python испол ьзуются оди наковые оператор ы сравн е н и я для ч исловых и строковых знач е н и й . Оператор сравне н ия » н е раве н » и м еет вид ! но в языке нет _

=

,

Глава 7. Сценарии и командная оболочка

253

унарного оператора ! ; для этой цел и используется ключевое слово n o t . Существуют также булевы операторы a n d и o r .

Циклы В приведен н о м н иже фрагменте используется конструкция f o r . . . i n для обхода элементов в диапазоне от 1 до 1 О. f o r coun t e r i n r an g e ( 1 , 1 0 ) : p r i n t ( c o un t e r , e nd= » » ) print ( )

# После дний пе р е х о д н а н о в ую строку

Как и в срезе м асс и ва в предыдущем примере , правая конеч ная точка диапазона фактически в него н е входит. В ывод включает только ч исла от 1 до 9: 1 2 3 4 5 6 7 в 9

Это единственн ы й тип цикла в языке Python, но это очень мощ н ы й и нструмент. В языке Python есть несколько фун к ц и й , которые отл и ч ают е го конструкцию f o r от других языков. •

В ч исловых диапазонах нет ничего особен н ого. Л юбой объект может поддержи­ вать итерационную модель Python как обычно. Можно перебирать строку (по сим­ волам ) , список, файл ( по символам , строкам или блокам) , список и т. д. Итераторы могут принимать несколько значений, и можно иметь несколько пере­ м е н н ых цикла. Присваивание в верхней части каждой итерации действует так же , как обычные множествен н ы е присваивания в языке Python. Эта функция особен ­ н о хорош а дЛ Я обхода словарей. В циклах f o r и wh i l e в конце могут быть разделы e l s e , которые выполняются только в том случае , если цикл завершается нормал ьно, в отличие от выхода из цик­ ла по инструкции b r e a k . Поначалу это кажется неестестве н н ы м , но такой подход позволяет довольно элегантно обрабатывать некоторые варианты испол ьзования.

В приведенном ниже примере сценарий принимает регулярное выражен ие в команд­ ной строке и сопоставляет его с списком гномов из сказки о Белоснежке, а также с цве­ тами их костюмов. На экран выводится первое совпадение с частя м и , которые соответ­ ствуют регулярному выражению, окружен ному сим волами подчеркивания. imp o r t s y s imp o r t r e sui t s = { ‘ Ba s h fu l ‘ : ‘ y e l l ow ‘ , ‘ Sn e e z y ‘ : ‘ b rown ‘ , ‘ Doc ‘ : ‘ o r ange ‘ , ‘ Dop e y ‘ : ‘ g r e en ‘ , ‘ Нарру ‘ : ‘ Ы uе ‘ , ‘ S l e ep y ‘ : ‘ t aupe ‘

‘ Grump y ‘ : ‘ r e d ‘ ,

p a t t e r n = r e . c omp i l e ( » ( % s ) » % s y s . a r gv [ l ] ) for dwa r f , c o l o r i n s u i t s . i t ems ( ) : i f p a t t e r n . s e a r ch ( dw a r f ) or p a t t e rn . s e a rc h ( c o l o r ) : p r i n t ( » % s ‘ s dwa r f s u i t i s % s . » % ( p a t t e rn . s ub ( r «_ l _ » , dwa r f ) , p a t t e rn . sub ( r » 1_ » , c o l o r ) ) ) break else : p r i n t ( » No dwa rve s o r dwa r f s u i t s ma t ch e d t h e p a t t e rn . » )

Н иже приведен вариант вывода:

Часть 1. Основы администрирования

254

$ pythonЗ dwarfsearch ‘ [ aeiou] { 2 ) ‘ S l_ee_p y ‘ s dwa r f s u i t i s t_au_p e . $ pythonЗ dwarfsearch ‘ qa l gu ‘ No dwarve s o r dwa r f s u i t s ma t c h e d t h e p a t t e rn .

Присваивание переменной s u i t s демонстрирует синтаксис Python Д/JЯ ш ифрова­ н ия символьных словарей. М етод s u i t s . i t erns ( } я вляется итератором ДIJЯ пар ключ­ значен и е — обратите вн имание на то, что на каждой итерации м ы извлекае м как имя гнома, так и цвет его костюма. Есл и вы хотите перебирать тол ько кл ючи, вы можете просто написать dwa r f in s u i t s . Язык Pytho n реализует обработку регулярных выражений с помощью модуля r e . В язы­ ке нет встроенных функций для работы с регулярными выражениями, поэтому обработка регулярных выражения в языке Pyth o n немного более ограниченная , чем, скажем, в языке Perl. Здесь шаблон регулярного выражения изначально компил ируется из первого аргумента командной строки, окруженного скобками (для форм ирования группы захвата). Затем стро­ ки тестируются и модифицируются поисковыми и вспомогательными методам и объекта r e g e x . Вы также можете вызвать re . s e a r c h и другие функции непосредственно, предо­ стаRЛЯя регулярное выражение для использования в качестве первого аргумента. Символы 1 в строке подстановки представляют собой обратную ссылку на содер­ жимое первой группы захвата. Странно выглядящий префикс r , который предшествует строке подстановки ( r » _ 1 _ » ) , подавл яет нормальную подстановку управляющих сим­ волов в строковых константах ( r обозначает » raw » ) . Без этого шаблон заме н ы состоял бы из двух символов подчеркивания, окружающих символ с цифровым кодом 1 . Следует отметить, что в словарях н ет определенного порядка обхода. Если в ы запу­ стите поиск гномов во второй раз, то можете получить другой ответ: $ pythonЗ dwarfsearch ‘ [ aeiou ] { 2 ) ‘ Dope y ‘ s dwa r f s u i t i s g r _ e e_n .

7 6 П РОГРАММИРОВАНИЕ НА ЯЗЫКЕ Ruвv .

.

Язык Ruby, разработан н ы й и поддерживаем ы й японским разработчиком Юкихиро М ацумото (Yukihiro » Matz» Matsumoto) , обладает м ногим и функциям и , общими с язы­ ком Pyt ho n , включая ш ироко рас простра не н н ы й подход » Все я вл яется объекто м » . Первоначально в ыпуще н н ы й в середине 1 990-х годов , язык Ruby не получил известно­ сти , пока десятилетия спустя н е появилась платформа веб-разработки Rails. В умах л юдей язык Ruby по-прежнему тесно связан с сетью, но в самом языке нет ничего веб-специфичного. О н хорошо подходит для написания сценариев общего на­ значения. Однако язык Pytho n , вероятно, все же луч ш и й выбор для основного языка сценариев, хотя бы из-за его более широкой популяр ности. Хотя язык Ruby во многом эквивале нтен язы ку Pytho n , он я вл яется более гибким . Например, классы Ruby остаются открытым и для модификации другим п рогра м м н ы м обес пече н ие м , и сообщество программ истов на языке Ruby не возражает против расши­ рен и й , которые изменяют стандартную библиотеку. Язык Ruby нравится те м , у кого есть с клон ность к » с интакс ическому сахару » , т.е. особенностя м , которые н а самом деле н е меняют базовый язык, н о позволяют более четко и четко в ыражать код. В среде Rails, например, строка due d a t e

7 . da y s . f rom_now

Глава 7 . Сценарии и командная оболочка

255

создает объект класса т ime без ссылки на и м е н а л юб ы х связан н ых с вре м е н е м классов или выпол н е н и я явных арифметических операций над датой и вре м е не м . Платформ а Rails определяет объе кт days как расш ире н ие класса F i x num, предста вл я ю ще го цел ые числа. Этот м етод возвращает объект D u r a t i o n , котор ы й действует как ч и сл о ; исполь­ зуется в качестве значени я , эквивалентного 604800, т. е . количеству с е кунд в се м и днях. Если проверить его в отладчике , он опишет себя как » 7 дней » . 21 Язык Ruby упрощает разработку «доме н н ых язы к ов » ( н а п р и м е р , D S L) , м и н и — язы­ ков, которые на самом деле я вляются подмножеством яз ы ка Ruby, но которы е рассма­ триваются как специализированные систе м ы конфи гура ции. Н а п р им ер , язык Ruby D S L используется в средствах настройки Chef и Puppet .

W Дополнител ьную информацию об инструментах Chef и Puppet см . в главе 23.

Инсталля ция В н е которых системах язык Ruby установлен по умол ча н и ю , а в н е которы х — не т. Тем не менее он всегда доступен как пакет, часто в н е с кол ь ких версиях. На сегодн я ш н и й ден ь (версия 2 . 3 ) язык Ruby подде ржи вает относительно хорошую совместимость со стар ы м кодом. В отсутствие конкре т н ых предупрежден и й обычно луч­ ше всего установить самую последнюю версию. К сожал е н и ю , бол ь ш инство систе м н ых пакетов отстают н а н е с колько вы пусков от рел изов языка Ruby. Есл и ваша библ иотека паке тов не вкл ючает текущую версию (проверьте сайт ruby- l a ng . o r g , чтобы определить, так л и это) , установите самую све­ жую верси ю через RVМ ; не п ытайтесь делать это сами .

W Подробнее о б RVM см . в разделе

7.7.

К раткое введение в язык Ruby

Поскол ьку я з ы к и Ruby и Pyt hon настолько похожи , н е которы е фрагменты кода на языке Ruby могут показаться п охож и м и на фр а г м е н ты кода из раздела о я з ы к е Python , приведе н н ые ранее в этой главе . # ! / u s r /b i n / env ruby print » H e l l o , w o r l d ! n n » name ‘ Gwen ‘ rating 10 cha r a c t e r s [ ‘ SpongeBob ‘ , ‘ Pa t r i c k ‘ , ‘ S qui dwa r d ‘ ] e l eme n t s { З = > ‘ l i t h i um ‘ , 7 > ‘ c a rbon ‘ , 5 => ‘ b o r on ‘ =

=

=

=

p r i n t » N ame : t » , n ame , » nRa t i n g : t » , p r i n t » Ch a r a c t e r s : t # { ch a r a c t e r s } n » p r i n t » E l emen t s : t # { e l eme n t s } n n «

rating,

» n «

e l eme nt_name s e l eme n t s . va l u e s . s o r t ! . map ( & : upca s e ) . j o i n ( ‘ , p r i n t » E l eme n t n ame s : t » , e l emen t_name s , » n n » =

‘)

e l eme n t s . e a c h do J ke y , v a l u e l p r i n t » At omi c numЬ e r # { ke y } i s # { va l ue } . n » end

21 Эта форма п ол иморфизма я вл яется обще й для я з ыков Ruby и Python. Его час т о называют «утиной типизацией » : если объект ходит как утка и крякает ка к утка , вам не нужно беспокоиться о том , действительно ли это утка.

Часть 1 . основы администрирования

256

Вывод выглядит следующим образо м : Hello, world ! Name : Gwen 10 Ra t i n g : Ch a r a ct e r s : [ » SpongeBob » , » Pa t r i c k » , » S qu i dwa r d » ] E l emen t s : { З = > » l i t h i um » , 7 = > » c a rb on » , S = > » b o r on » ) E l eme n t name s : B ORON , CARBON , L I T H I UM At omi c numЬ e r З i s l i t h i um . A t omi c numЬ e r 7 i s c a rbon . At omi c n umЬ e r 5 i s b o ron .

Как и Python, язык Ruby испол ьзует скобки для разграничения массивов и фигурные скобки для разделения словарных л итералов. (В языке Ruby они называются «хешам и » . ) О п ератор = > отделяет каждый хе ш — кл юч о т е го соответствующе го значе н и я , а пары ключ-значение отделя ются друг от друга запятым и . В языке Ruby нет кортежей. Функция p r i n t в языке Ruby это фун кция (ил и , точ нее , глобальны й м етод) , как и в языке Python 3. Однако, есл и вы хотите испол ьзовать переход на новую строку, вы должны явно указать это.22 Кром е тоrо, круглые скобки, обычно встречающиеся вокруг аргуме нтов в вызовах функций, в Ruby я вляются н еобязательн ы м и . Разработчики обыч­ но н е в ключают их, есл и они не помогают прояснить код или устранить неоднознач ­ ность. (Обратите внимание на то, что н екоторые из вызовов функции печати включают в себя несколько аргументов, раздел е н н ых запятым и . ) В нескольких случаях м ы использовали фигурные скобки # { } скобки дл я интерполя­ ции значений переменных, заключен н ые в строках с двумя кавычками. Такие скобки мо­ гут содержать произвол ьный код Ruby; любое значение. созданное кодом , автоматически преобразуется в тип строки и вставляется во внешнюю строку. Вы также можете конка­ тенировать строки с помощью оператора +. но интерполяция обычно более эффективна. Строка, вычисляющая e l ement_name s , иллюстрирует еще нескол ько возможностей языка Ruby: —

e l ement_name s = e l eme nt s . va l u e s . s o r t !

. map ( & : upc a s e )

. j oin ( ‘ ,

)

Это серия вызовов методов , каждый из которых работает с резул ьтатом , возвра­ щае м ы м предыдущим методо м , подобно конвейеру. Например, метод v a l u e s объек­ та e l emen t s создает массив строк, которые зате м сортируются в алфавитном порядке функцией s o r t ! . 23 М етод m a p класса A r r a y вызывает метод u p c a s e для каждого эле­ м е нта, а затем с нова собирает все резул ьтаты в новый массив. Наконец, метод j o i n объединяет элементы этоrо масси ва, ч ередующиеся с запятым и , для создания строки.

Блоки В предыдущем коде текст между do и end представляет собой блок, известный в дру­ гих языках как лямбда-функция , зам ы кание или анон имная функция . 24 22 Есть также функция puts , которая добавляет символы перехода на новую строку автоматически, но она, возможно, сли ш ком изощрен ная . Если вы попытаетесь самостоятельно добавить с и мвол перехода на новую строку, функция puts не будет вставлять эти символ ы автоматически. 2.� восклицательный знак в и ме н и функции sort ! предупреждает вас, что при использова н и и этого метода н ужно быть осторож н ы м . Это не с интаксическое п равило, а п росто часть и м е н и метода. В данном случае функция sort ! сорти рует масс и в на месте . Существует также метод s o r t без восклицательного знака, который возврашает элементы в новом отсортированном массиве. 24Фактически в языке Ruby существуют три объекта этого общего типа, известн ые как блоки, процедуры и ля мбда. Различия меЖдУ ними незнач ительны и не важны для этого обзора.

Глава 7 . Сценарии и командная оболочка

257

e l eme n t s . e a c h do l ke y , v a l u e l p r i n t » A t om i c numЬ e r # { ke y } i s # { va l ue } . n » end

Данн ы й блок принимает два аргуме нта, которые он называет k e y и v a l u e , и выво­ дит их значен ия на экран . Оператор e a c h выглядит как функция языка, но это всего л и ш ь метод, определя­ емый хешам и . Оператор e a c h принимает блок как аргуме нт и вызывает его один раз для каждой пары ключ-значе н и е , содержаще й хеш . Этот тип итерационной функци и , используемой в сочетании с блоко м , очен ь характерен для кода на язы ке Ruby. И м я e a c h является стандартны м именем обобщен н ых итераторов, но многие классы опреде­ ляют более кон кретные версии, такие как e a c h_ l i ne или e a c h_ c h a r a c t e r . В языке Ruby есть ал ьтернативн ы й синтаксис для блоков, в котором в качестве раз­ делителей используются фигурные с кобки, а не do . . . end. Он означает точно то же са­ мое , но больше похож на часть выражения. Например, cha r a c t e r s . map { 1

с

1

c . r e ve r s e } #

[ » b oBe gnop S » ,

» kc i r t a P » ,

» d r awdiuqS » ]

Эта форма функционально идентична c h a r a c t e r . map ( & : reve r s e ) , но вместо того, чтобы просто указывать методу ma p , какой метод вызывать, м ы включил и явный блок, вызывающий обратны й метод. Значение блока — это знач е н и е последне го выраже н и я , которое оно выч исляет до завершения. Удобно, что почти все в языке Ruby является в ыражением (т. е . » фраг­ ментом кода, который может быть выполнен для создания знач е н ия » ) , вкл юч ая струк­ туры управления, такие как c a s e (аналог конструкции s w i t c h в большинстве языков) и i f — e l s e . Значения этих выражений отражают значение, получ е н н ое в зависимости от того, какой из разделов c a s e или ветви инструкции i f- e l s e был выполнен. Блоки имеют м ного применений, помимо итераци й . Они позволяют одной функции выполнять процедуры н астройки и удаления от и м е н и другого раздела кода, поэтому они часто представляют собой м ногоэтапные операции , такие как транзакции баз дан ­ ных или операции с файловой системой. Например, следующий код открывает файл / e t c / p a s s wd и выводит строку, опреде­ ляющую учетную запись root: o p e n ‘ / e t c / p a s s wd ‘ , ‘ r ‘ do 1 f i l e 1 f i l e . e a c h_l i ne do l l i n e l p r i n t l i ne i f l i ne . s t a r t w i t h ? end end

‘ ro o t : ‘

Фун кция o p e n открывает файл и передает его объект IO во вне ш н и й блок. После того как блок завершит работу, файл откроется автом атически. Нет необходимости в отдельной операции закрытия (хотя она существует, если вы хотите ее использовать) , и файл закрывается независимо от того , как завершается внеш н ий блок. Применяемая здесь постфиксная конструкция i f может быть знакома тем , кто ис­ пользовал язык Perl. Это хороши й способ выразить простые условн ы е обозначения без сокрытия основного действия. Здесь сразу видно, что внутренний бло к представляет со­ бой цикл , который выводит некоторые строки. В случае , если структура аргумента l i ne фун кции p r i n t не ясна, в нее снова вклю­ чаются необязательные круглые скобки. Оператор i f имеет сам ы й н изкий приоритет и использует один метод вызова для обоих вариантов: print

( l i ne )

i f l i n e . s t a r t wi t h ?

( ‘ root : ‘ )

Часть 1. Основы администрирования

2 58

Как и в случае метода s o r t ! знак вопроса представляет собой соглашение об именах методов, возвращающих логические значен и я . С и нтаксис для определения именован ной фун кuии нес кол ько отл ичается о т си нтак­ сиса для блока. ,

de f show_u s a ge ( ms g ni l ) S T DERR . pu t s m s g i f ms g S T DERR . pu t s » U s a ge : # { $ 0 ) exit 1 end =

f i l e n ame

Скобки все еще я вля ются н еобязател ьн ы м и , но на практике о н и все гда отобража­ ются в этом контексте , если фун кuия не п р и н и мает аргуме нтов. Здесь аргум ент m s g п о умолчанию раве н н улю. Глобальная перемен ная $0 явл яется довольно загадоч ной и содержит и м я , по кото­ рому вызывается текущая программа. (Традиuион но эти м именем является первый аргу­ мент масс и ва a rgv. Однако по соглашению в языке Ruby ARGV содержит только факти­ ческие аргументы командной строки . ) Как и в язы ке С , вы можете обрабаты вать н ебулевые знач е н и я , как если бы о н и были булевы м и , что показано здесь в форме i f ms g . Однако отображение в языке Ruby для этого преобразования н е м н ого необычное : все , кроме n i l и f a l s e , сч итается ис­ т и н н ы м . В частности , О это истин ное значение. ( На практике эта возможность часто оказы вается удобной . ) —

Символ ы и хеш и опций В я зы ке Ruby ш ироко испол ьзуется необыч н ы й ти п дан н ых, называе м ы й символом и обозначен н ы й двоеточи е м , например : : examp l e . О с и м волах можно думать как о не­ преложных строках. О н и обычно испол ьзуются как ярл ы к и или известн ые хеш — кл юч и . Внутре н н е язы к Ruby реал изует и х как ч исла, поэтому они быстро хеш ируются и срав­ н и ваются. С и м вол ы та к ч асто испол ьзуются в качестве хеш — кл юч е й , что в верс и и Ruby 2 . 0 определ ил и ал ьтернатив н ы й синтаксис для хеш -л итералов, чтобы уме н ьш ить кол иче­ ство знаков пре пинан и я . Стандартны й хеш h

=

{

: an i ma l =>

‘ ca t ‘ ,

: ve g e t a Ы e =>

‘ carrot ‘ ,

: mi n e r a l = > ‘ z e o l i t e ‘

}

можно написать в стиле Ruby 2 . 0 следующи м образом : h

=

{ a n ima l :

‘ c a t ‘ , vege t aЫ e :

‘ c a r r o t ‘ , mi n e r a l :

‘ zeolite ‘

}

Вне этого хеш-л итерального конте кста с и м вол ы сохраняют свои префиксы : везде , где они появляются в коде. Например, вот как получить кон кретные знач е н ия из хеша: h e a l t h y_s n a c k

=

h [ : ve g e t aЫ e ]

#

‘ c a r r ot ‘

В я з ы ке Ruby п р и н ято своеобразное , но мощное соглаше н и е для обработки пара­ метров в вызовах функuи й . Есл и вызывае мая фун кuия запра ш и вает такое поведе н и е , язык Ruby сdби рает завершающие аргументы вызова, которые напом и н ают хеш иро­ ван н ы е пары , в новый хеш . Затем он передает этот хеш функuии в качестве аргумента. Например, в выраже н и и , допустимом на платформе Rails, f i l e f i e l d_t a g : up l o a d , _

accept :

‘ appl i c a t i on / pd f ‘ ,

id :

‘ c omme n t p d f ‘

функuия f i l e _ f i e l d_ t a g получает только два аргумента — сим вол : u p l o a d и хе ш , со­ держащий кл юч и : a c c e p t и : i d . Пос кольку хеш и не и м е ют жесткого порядка, не важ­ но, в каком порядке появляются параметры.

Глава 7 . Сценарии и командная оболочка

259

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

Регулярные выра жения в языке Ruby В отличие от Python, язык Ruby и меет немного «синтаксического сахара» мя работы с регулярными выражениями. Язык Ruby поддерживает традиционную / . . . / нотацию для литералов регулярных в ыраже н и й , а содержимое может содержать упрамя ющие по­ следовательности символов # { ) , похожие на строки с двумя кавы ч ками. Кром е того, в языке Ruby определен оператор (и его отрицание ! — ) дЛЯ провер­ ки соответствия м ежду строкой и регулярны м выражением . О н возвращает либо и ндекс первого совпадения, либо n i l , если нет совпадения. =-

» He rmann He s s e » = — / H [ ae i o u ] / # = > О

Для того чтобы получить доступ к ком понентам соответствия , явно вызовите метод ma t c h регулярного выражения. Он возвращает л ибо n i l (если соответствий нет) , либо объект, к которому можно получить доступ в виде массива компонентов. if m = / ( л H w * ) s / . ma t c h ( » He in r i c h H o f fme y e r h e a d e d t h i s he i s t » ) put s m [ O ] # ‘ H e i n r i ch ‘ end

Рассм отрим предыдущую программу для определения цвета костюма гнома на языке Ruby. s ui t s = { B a s h f u l : ‘ ye l l ow ‘ , S ne e z y : ‘ b r own ‘ , D o c : ‘ o r a n g e ‘ , G rump y : Dope y : ‘ g r e en ‘ , Нарру : ‘ Ыu е ‘ , S l e e p y : ‘ t aupe ‘

‘ re d ‘ ,

abo rt » U s a g e : # { $ 0 ) p a t t e r n » u n l e s s ARGV . s i z e == 1 pat = / ( # { ARGV [ O ] ) ) / ma t che s = s u i t s . l a z y . s e l e c t { l dwa r f ,

color l pat

dwa r f 1 1 p a t

i f ma t c he s . a n y ? dwa r f , c o l o r = ma t c he s . f i r s t p r i n t » % s ‘ s dwa r f s u i t i s % s . n » % [ dwa r f . t o_s . s ub ( p a t , ‘ 1 ‘ ) , c o l o r . s ub ( p a t , ‘ 1 else p r i nt » N o dwa rve s o r dwa r f s u i t s ma t c h e d t h e p a t t e r n . n » end

co l o r )

‘)

Метод s e l e c t , применен н ы й к колл е кции , создает новую коллекцию, включаю­ щую только те элементы, для которых предоставленн ы й блок имеет значение как t ru e . В этом случае совпадения представл я ют собой нов ы й хеш , содержащий только пар ы , м я которых л и бо кл ю ч , л и бо знач е н ие соответствует шаблону поиска. Пос кольку м ы применили ленивый вызов ( l a z y) , фильтрация на самом деле не произойдет, пока м ы не попытаемся извлечь значения и з результата. Фактически этот код проверяет столько пар, сколько необходимо мя поиска соответствия . Вы зам етил и , что оператор сопостамения с образцом использовался на символах, которые представляют имена гномов? Он работает, потому что оператор достаточно умен, чтобы перед сопостамением преобразовать символы в строки. К сожалению, при =-

=-

часть 1. Основы администрирования

260

испол ьзовании шаблона подстановки мы должны явно выпол н ить это преобразование (с помощью метода t o _ s ) ; метод s u b определ е н только для строк, поэтому нам нужна настоя щая строка для его вызова. Обратите в н и м а н и е также на параллельное присваи ван и е гнома и цвета. М етод ma t c h e s . f i r s t возвращает двухэлементный массив, который Ruby рас паковывает ав­ томатически. Оператор % дл я строк работает аналоги ч но такому же оператору в языке Python; это версия фун кции s p r i n t f в языке Ruby. Здесь есть два ком понента для запол не ни я, по­ этому мы передаем значен ия как двухэлементн ый масс ив.

Я зык Ruby ка к фильтр Язык Ruby можно испол ьзовать без сценария , помещая изол ирован ные выражен ия в командную строку. Это простой способ сделать быстрые преобразования текста ( прав­ да, язык Pe rl по-прежнему нам ного лучше справляется с этой задачей). И спользуйте параметры командной строки -р и — е для цикл ического обхода пото­ ка STD IN, выпол н ите простое выраже ние для каждой строки ( представлен ное как пере ­ мен ная $ _ ) и распечатайте резул ьтат. Например, следующая команда пере водит строку /etc /pas swd в верхн и й регистр: $ ruЬy -ре ‘ $ . tr ! ( » a — z » , «A- Z » ) ‘ /etc/pas swd NOBODY : * : — 2 : -2 : UN P R I V I LEGED U S E R : /VAR / EMPT Y : / U S R / B I N / FA L S E ROOT : * : O : O : S Y S T EM ADM I N I S T RATOR : /VAR / ROOT : / B I N / S H

Команда ruЬy — а включает режим автоматического разделения, отделяющий входные строки от полей, которые хранятся в массиве с именем $ F. По умолчан ию разделителем яв­ ляется пробел , но вы можете установить другой шаблон разделителя с помощью опции -F. Режим разделения удобен для испол ьзования в сочетании с параметром -р или е го вариантом -n, которы й не подразумевает авто матического вывода на экран . В приве­ ден ной ниже команде конструкция ruЬy -ane ис пользуется для создания версии файла pas swd, которая включает тол ько имена пользователе й и оболочки. $ ruЬy -F : — ane ‘ print $F [ O ] , » : » , $F [ — l ] ‘ /etc/passwd nobody : / u s r / b i n / f a l s e r o o t : /Ь i n / s h

Тол ько бесстраш н ы й п рогра м м ист может испол ьзовать параметр — i в сочета н и и с парам етром -ре для редакти рован ия файлов на месте . Язык Ruby ч итает содержимое файлов, представляет их строки для редактирования и сохран яет резул ьтаты в исход­ ные файл ы . Вы можете задать параметр — i , который сообщает языку Ruby, как создать резервную коп ию исходной верс и и каждого файла. Например, — i . bak создает копи ю файла pas swd с и менем pas swd . bak. Остере гайтесь! Есл и в ы не создадите резервный шаблон , вы вообще не получ ите резервные копи и . Обратите вниман ие на то, что между параметром -i и суффиксом нет пробела.

7 7 У ПРАВЛЕНИЕ БИБЛИОТЕКОЙ И СРЕДОЙ для РvтноN и Ruвv .

.

Я зыки имеют много одинаковых вопросов управле н ия пакетами и версиями и часто решают их аналоги ч н ы м образом . Поскол ьку языки Python и Ruby в этой области по­ хожи друг на друга, мы обсуждаем их в этом разделе вместе .

Глава 7. Сценарии и командная оболочка

261

Пои ск и уста новка пакетов Самое ос новное требование — обеспеч ить простой и стандартизированн ы й способ обнаружения, получения, установки , обновления и распространения дополн ительного программ ного обеспечения. У языков Ruby и Python есть централизованные хран ил ища для этой цели, у Ruby — на сайте rubygems . org, в у Python — на сайте pypi . python . org. В м ире Ruby пакеты н азы ваются «драгоце н н ы м и ка м н я м и » (gems) , а команда для управлен ия м пакетами также называется gem. Команда gem search regex пока­ зывает доступн ые пакеты с соответствующим и именами , а gem install имя_ па к е та загружает и и нсталл ирует пакет. С помощью параметра — -user-install можно инстал ­ лировать приватную коп и ю вместо изменения модификации набора пакетов в системе. Эквивалент в языке Python называется pip (pip2 или рiрЗ , в зависимости от того , какие верс ии Pyt h o n установл е н ы ) . Н е все систе м ы включают его по умолчан и ю . Систе м ы , которые этого не делают, обеспечивают доступ к н е м у как к отдельному паке ­ ту на уровне операцион ной с исте м ы . Как и в случае с пакетами язы ка Ruby, основн ы м и командами я вляются pip search и pip ins tall . Опция — -user устанавл и вает пакеты в ваш домашн и й каталог. Утил иты gem и pip пон имают зависимости между пакетам и , по крайней мере на ба­ зовом уровне. Когда вы устанавливаете пакет, вы неявно запраш и ваете , чтобы все паке ­ ты , от которых он зависит, также были установлены (есл и они еще не и нсталлирова н ы ) . В базовой среде Ruby или Python может быть установлена только одна версия пакета. Если вы переустановите или обновите пакет, старая версия будет удалена. У вас часто есть выбор для установки пакета gem или pip с помощью стандартно­ го языкового механ изма (gem или pip) ил и пакета уровня операцион ной с исте м ы , ко­ торый хранится в стандартном хра н ил и ще вашего поставщика. Пакеты операцион ной системы с большей вероятностью будут устанавл иваться и запускаться без пробле м , но они с меньшей вероятностью будут обновляться . Ни оди н из вариантов не и меет явного преимущества.

Соэдание воспроизводимых сред Программы, библиотеки и языки развивают сложные сети зависимостей, поскольку они эволюционируют вместе во времени. Производствен н ый сервер может зависеть от десятков или сотен таких компонентов, каждый из которых имеет свои собственные ожидания отно­ сительно среды установки. Как определить, какая комбинация версий библиотеки создаст гармоничную среду? Как убедиться, что конфигурация , которую вы тестировали в лабора­ тории разработки, является той же самой, которая развертывается в облаке’? В обще м , как сделать так, чтобы управление всеми этими частями не было большой проблемой? Языки Python и Ruby имеют стандартизирован н ы й способ для выражения зависимо­ сти между пакета м и . В обеих с истемах разработч ики пакетов создают текстовый файл в корне проекта, который перечисляет е го зависи мости . В языке Ruby файл назы вается Gemfile, а в языке Python requirements . txt. Оба формата поддерживают гибкие спецификаци и версий для зависи мосте й , поэтому пакеты могут зая вить, что они совме­ сти м ы с «л юбой версией пакета s imple j son версии 3 ил и в ы ш е » или Ra il s 3, но не Rails 4″. Также можно указать точ ное требование к версии для л юбой зависимости. Оба формата файлов позволяют указать источник для каждого пакета, поэтому зави­ симости не обязател ьно дол жн ы распростран яться через стандартный пакет хранилища. Поддерживаются все рас простране н н ые источ н и ки : от веб-адресов до локал ь н ых фай ­ лов и хранил и щ G it Hub. —

«

Часть 1. Основы администрирования

262

И н сталл и руйте п а кет за в и с и м осте й Pyt h o n с парам етром p i p i n s t a l l — r requi rements . txt. Хотя команда pip отл ич н о с п равляется с определ е н и е м с п е ц­ и ф и ка ц и й отдел ь н ы х верс и й , она, к сожал е н и ю , не м ожет сам остоятел ьно р е ш ать сложные отношения зависимосте й между пакета м и . Разработч и кам и ногда приходит­ ся настраивать порядок, в котором пакеты упом инаются в файле requi rements . txt для достижения удовлетворител ьного результата. Кроме того , новые выпуски пакетов могуг наруш ить равновеси е верс и и , хотя это происходит редко. Команда p i p f r e e z e рас печат ывает текущи й пакет пакетов Python в формате requirements . txt , указывая точ ную верси ю для каждого пакета. Эта фун кция может быть полезна для репл и кации текущей среды на производственном сервере. В м ире Ruby пря м ы м аналогом команды pip -r я вляется команда gem i n s ta l l -g Gemfile. Однако в бол ьш и нстве случаев для управления зависимостя м и луч ш е ис­ пользовать менеджер управления пакета м и Bundler. Выпол ните команду gem install bundler, чтобы установить его (есл и он еще не установлен в системе), а затем запустите установку пакета из корневого каталога проекта, которы й вы настраи ваете. 25 У менеджера Bundl e r есть н есколько и нтересных особен ностей . •

О н действительно выполняет рекурси вное управл е н ие зависимостя м и , поэтому, есл и существуют пакеты , которые вза и м н о совместимы и удовлетворяют всем огран иче н и я м , менеджер Bu ndler может найти е го самостоятельно.

Он автоматически записывает резул ьтаты расчетов версий в файл Gemfi le . lock. П оддержание этой контекстной и нформации позволяет менеджеру Bundl e r об­ рабаты вать обновл е н ия в файле Gemfile надежно и эффективно. П ри переносе на новую версию G emfile менеджер Bundler изменяет только пакеты, в которых он нуждается .

Поскол ьку файл Gemfile . lock ассоци ирован с о средой, запуск установки пакета на сервере развертывания автоматически воспроизводит среду пакета , найденную в среде разработки. 26

В режи ме разверты ван и я (bundle i n s t a l l — -deployment) менеджер Bundler устанавл ивает отсутствующие пакеты в каталог локального проекта, помогая изо­ л ировать проект от любых будущих изменений. Затем можно использовать команду bundle ехес для запуска определенных команд в этой гибридной среде пакетов. 2 7

Нескол ько сред Команда pip и bundle успешно осуществл я ют управление зависимостя м и для от­ дел ьн ых программ Python и Ruby, но что, есл и две программы на одном сервере имеют противоречивые требования? В идеале каждая программа в производствен ной среде будет иметь собствен ную би­ блиотечную среду, которая не зависит от систе м ы и всех других программ .

2� n акеты в языке Ruby моrут содержать команды на уровне оболоч к и . Одна ко у н и х обычно нет с п равоч н ы х стра н и u ; дл я п олуч е н и я п одробн ы х с веде н и й о п акете выпол н ите команду bundle help или обратитесь к п олной документаuии на сайте bundler . io» 2» И л и , по край ней мере, это поведение по умолчанию. При необходимости в файле Gelllf i le леrко указывать разл ичные требова н ия к средам разработки и развертыван ия . 27 Н екоторые п рограммные пакеты, такие к а к Rails, я вляются совместимыми с менеджером Buпdler и моrут и с п ол ьзовать локал ьно установлен н ые пакеты даже без в ы п ол н е н и я команды ехес bundle.

Глава 7. сценарии и командная оболочка

263

Пакет virtualenv: виртуальные среды для языка Python Пакет v i r tualenv языка Python создает в иртуал ьные сред ы , которые находятся в своих собствен н ых каталогах. 2 8 Чтобы настроить новую среду, после установки пакета просто запустите команду virtualenv с именем пути . $ virtualenv myproject New python e x e c u t a Ы e i n / home / u l s ah /myp r o j e c t / b i n /p y t h on I n s t a l l i n g s e t u p t o o l s , p i p , whe e l . . . done .

Каждая в иртуал ьная среда и м еет каталог Ь i n / , содержа щ и й двои ч н ы е файлы Д11Я виртуальн ых сред Python и P I P. Когда вы запус каете оди н из этих двои ч н ых файлов, вы автоматически помещаетесь в соответствующую виртуальную среду. Установите па­ кеты в среду, как обычно, запусти в копи ю команды pip в виртуальной среде . Для того чтобы запустить виртуализованную программу Python из демона cron или из сценария запуска систе м ы , явно укажите путь к правил ьной копи и python. (В кач е ­ стве альтернативы поместите путь в строку сценария . ) При интеракти вной работе в оболочке можно запустить сценарий Ь i n / activate виртуальной среды , чтобы установить верс и и утилит python и pip в виртуальной сре­ де по умолчан ию. Сценарий перестраивает переменную РАТ Н вашей оболочки . Для того чтобы покинуть виртуальную среду, испол ьзуйте команду deactivate . Виртуал ьные среды привязаны к определенным версиям Python. Во врем я создания виртуальной среды вы можете установить связанный двоичный код Python с помощью па­ раметра — -python virtualenv. В результате будет устаномен бинарны й файл Python.

RVM: менеджер enVironmen t для языка Ruby В м ире Ruby все похоже , но несколько сложнее. Выше было указано, что мен еджер Bundler может кеш ировать локальные копи и пакетов Ruby от и м е ни конкретного при ложения. Это разум н ы й подход при перемеще н и и проектов в производство, но это н е так удобно дл я интерактивного использования. О н также предполагает, что вы хотите использовать установленную версию Ruby. Те, кто хочет получить более общее решение, должны подумать о менеджере RVМ , слож­ ном и довольно неудобном виртуализаторе среды, который использует несколько особен но­ стей оболочки. СправеД11 и вости ради отметим , что менеджер RVM я мяется чрезвычайно отполированным примером » кривых костьиrей». Н а практике он работает плавно. Менеджер RVM упрамяет как версиями Ruby, так и нескольки м и коллекциям и па­ кетов, и позволяет перекл ючаться между н и м и на ходу. Н апример, команда $

rvm

ruЬy-2 . 3 . 0 @ ulsah

активирует Ruby верси и 2 . 3 . 0 и набор пакетов под названием u l s a h . Ссьmки на утилиты ruby или gem теперь разрешаются в рамках указан н ых верс и й . Этот пример также ра­ ботает Д11 Я программ , устаномен н ых пакетами , таким и как bundle и rai l s . К счастью, упрамение пакетами не изменилось; просто используйте пакет или комплект, как об ыч­ но, и все вновь устаноме н н ые пакеты автоматически попадут в нужное м есто. Процедура установки менеджера RVM включает выбор сценария Bash из И н тернета и его локальное выполнение. В настоящее время используются команды $ curl — о / tmp/ install — s SL https : / /get . rvm . io $ sudo bash/ tmp/ install staЫe

28 Как и в случае с другим и командами, связанными с языком Pythoп, существуют верси и кома нды virtualenv с числовы ми суффиксами , которые поступают с определен н ы м и версиями Pyt hoп .

264

Часть 1. Основы администрирования

но все же проверьте текущую версию и криптографическую подп ись на сайте rvm . i o .29 Обязател ьно проведите инсталляцию с помощью програ м м ы sudo , как показано выш е ; есл и вы этого не сделаете , менеджер RVM настроит частную среду в ваш е м домаш не м каталоге . (Это не страш но, но н ичто в производственной системе н е должно сс ылать­ ся на ваш домаш н и й каталог.) Кроме того, вам нужно будет добавить автори зова н н ы х пользователей RVM в группу U N IX rvm. После первоначальной установки RVM не испол ьзуйте sudo при установке пакетов или изме н е н и и конфигураций RVM . Менеджер RVM контрол ирует доступ через член­ ство в группе rvm. Менеджер RVM выпол няет свою работу автоматически , ман ипул ируя пере м е н н ы м и среды оболочки и путем поиска. Следовательно, он должен быть включен в вашу среду во время запуска оболочки при входе в систему. Когда вы устанавл иваете RVM на си­ стемном уровне , он вкл ючает сценарий rvm . sh с соответствующ и м и командами в файл /etc /profi le . d. Н екоторые оболочки автоматически запускают эту заглушку. Есл и это не так, необходимо я вно вы пол нить команду s ou r c e , которую вы можете добавить в файлы запуска вашей оболочки: s ou r c e / e t c / p r o f i l e . d / rvm . s h

Менеджер RVM н и как н е изменяет исходную установку Ruby, в частности сценарии, на­ ч инающиеся с # ! / u s r / b i n / env ruby

С и м вол ы # ! в стандартном Ruby видят только системные пакеты. Следующий вариант более гибкий : # ! / u s r / b i n / env ruby

Он находит команду ruЬy в соответствии с контекстом RVM пользователя , который его запускает. Команда rvm install устанавл ивает новые верс и и язы ка Ruby. Эта фун кция RVМ позволяет легко устанавл ивать нескол ько раз н ых верс и й Ruby. Ее следует п редпочесть собстве н н ы м пакетам Ruby ваше й операционной систе м ы , которые редко обновляются . Команда rvm i n s tall загружает двоич н ые файл ы , если они досту п н ы . Если н ет, она устанавл ивает необходимые пакеты операционной систе м ы , а затем строит Ruby из ис­ ходного кода. Вот как м ы можем настроить развертывание приложения Rails, которое , как извест­ но, совместимо с Ruby 2 . 2 . l . $ rvm install ruЬy- 2 . 2 . 1 S e a r c h i n g f o r b i n a r y rub i e s , t h i s mi ght t a k e s ome t ime . No b i n a r y rubi e s a va i l aЫ e f o r : ubunt u / 1 5 . 1 0 / x 8 6_ 6 4 / ru b y — 2 . 2 . 1 . C o n t i n u i n g wi t h c omp i l a t i o n . P l e a s e r e a d ‘ rvm h e l p moun t ‘ t o g e t more i n f o rma t i on on b i n a r y rubi e s . C h e c k i n g r e q u i reme n t s f o r ubun t u . I n s t a l l i n g r e q u i r e d p a c k a ge s : gaw k , l i b r e a d l i n e б — d e v , z l i Ь l g — d e v , l ibnc u r s e s 5 — d e v , a u t oma k e , l i bt o o l , b i s o n , l i b f f i — dev . . . . . . . . . . . . . . . Requi reme n t s i n s t a l l a t i o n s u c c e s s f u l . I n s t a l l i ng Ruby f r om s ou r c e t o : / u s r / l oc a l / rvm / rubi e s / ruby- 2 . 2 . 1 , t h i s ma y t a k e а wh i l e depending o n y o u r cpu ( s ) . . .

.

29 С м . ком м е нтар и и о том , почему н а ш и команды н е соответствуют ре коме нда ц и я м RVM , в разделе 1 . 1 0.

Глава 7 . Сценарии и командная оболочка

265

Если вы установили RVM , к а к описано выш е , система Ruby устанавливается в ката­ логе /usr/local/rvm и доступна для всех учетных записей в системе. Для поиска версии RVM следует испол ьзовать команду rvm first known, которая , как известно, знает, как выполнять загрузку и сборку. Команда rvm l i s t выводит спи­ сок уже установленных и доступных для испол ьзования пакетов RVM . $ cd myproject . rails $ rvm ruЬy-2 . 2 . l @ myproj ect — — create — — default — -ruЬy-version rub y — 2 . 2 . 1 — # g ems e t c r e a t e d / u s r / l oc a l / rvm/ gems / ru b y — 2 . 2 . l @ myp r o j e c t rub y — 2 . 2 . 1 — # ge n e r a t i n g myp r o j e c t wrappe r s . . . . . . . . . . $ gem install bundler Fetching : bundl e r — 1 . 1 1 . 2 . gem ( 1 0 0 % ) Succ e s s fu l l y i n s t a l l e d bundl e r — 1 . 1 1 . 2 1 gem i n s t a l l e d $ bundle Fetching gem me t a d a t a f rom h t t p s : / / rubygems . o r g / . . . . . . . . . . . Fetchin g ve r s i o n me t a d a t a f r om h t t p s : / / rubygem s . o r g / . . . Fetching dependency me t a d a t a f r om h t t p s : / / rubygems . o r g / . . Re solving dependenc i e s . . . . . .

Строка ruby — 2 . 2 . l @ mypro j ect задает версии Ruby и комплекта пакетов. Флаг —create создает комплект п акетов, если он еще н е существует. Флаг — — default уста­ навливает эту комбинацию по умолчани ю , а флаг — ruЬy-vers ion записывает и м е н а интерпретатора Ruby и компле кта пакетов в файлы . ruЬy-version и ruЬy-gemset в текущем каталоге. Если файл * -ver s i on существует, то менеджер RVM автоматически считывает и оценивает их при работе со сценариями в этом каталоге. Эта функция позволяет каж­ дому проекту указывать свои собственные требован ия и освобождает вас от необходи­ мости помн ить, что с ним связано. Чтобы запустить пакет в запрошенной среде ( как описано в файлах ruЬy-version и ruЬy-gemset) , выпол ните команду .

.

.

.

rvm

in /путь /к/ка талогу do кома нда — з а пуска аргументы_ з а пуска . . .

Это удобн ы й синтаксис для испол ьзования при запуске заданий и з сценариев запу­ ска или демона cron. Он не зависит от текущего пользователя , настраивающего RVM , или от конфигурации RVM текущего пользователя . В качестве ал ьтернативы можно указать я вную среду дл я команды, например: rvm rub y — 2 . 2 . l @ myp r o j e c t do команда -за пуска аргументы_ за пуска . . .

Однако существует и третий вариант — запустить двоич н ы й код ruЬy изнутри обо­ лочки, поддерживаемой RУМ для этой цел и . Например, команда /usr/local/ rvm/wrappers/ruЬy-2 . 2 . l @ myproject/ruЬy

автоматически переносит вас в мир Ruby 2 . 2 . l .

7 8 КОНТРОЛЬ ВЕРСИЙ С ПОМОЩЬЮ СИСТЕМЫ G1т .

.

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

Часть 1 . Основы администрирования

266

С исте м ы контроля верс и й ре шают ряд пробл е м . Во- первых, они определя ют орга­ н изо ва н н ы й с п особ отсл е ж и ва н и я истори и изме н е н и й в файл е , чтобы эти изменения можно было понять в контексте и чтобы можно было восстановить более ран н ие вер­ с и и . Во- вторы х , они рас ш и р я ют кон цепцию верс и й выше уровня отдел ьн ы х файлов. Связа н н ы е груп п ы файлов могут быть сопоставл е н ы вместе с учетом их взаимозависи ­ м осте й . Наконец, систе м ы контроля версий координ ируют действия н ескол ьких редак­ торов, поэтому условия гонки не могут привести к тому, что ч ьи -л ибо изменения будут окон чательно потеряныJ0, и поэтому несовместим ы е изменен ия от нескол ьких редакто­ ров не станут акти в н ы м и одновре менно. Самой попул я р н о й в н астоящее вре м я систе мой я вляется G it , единолично создан ­ ная Л и н усом Торвальдсом ходн ы м кодом ядра

( Linus Torvalds) . Л и нус создал с истему G i t для управл е н ия ис­ Li nux из-за его разочарования в систе мах контроля верс и й , которые

сушествовал и в то вре м я . В настоящее время он является таким же вездесущи м и вли я ­ тельн ы м , к а к

Linux. Трудно с казать, какие из этих изобрете н и й Л и нуса оказал и бол ьшее

влия н и е на м ир . Больш и нство совре м е н н ы х програм м разработано с помощью систе м ы G it , и , как резул ьтат, адм и н и страторы стал к и ваются с н и м ежедн евно. Вы можете н а йти , загру­ зить и в нести в кл ад в проекты с открытым исходны м кодом на G it H ub , Git Lab и других сайтах колл е ктивной разработки. В ы также можете испол ьзовать систему G it для отсле­ живания изме н е н и й в сце н ар и я х , коде управл е н и я конфигурацией , шаблонах и л юбых других текстовых файлах , которые н еобходимо отслеживать с теч е н и е м вре м е н и . М ы испол ьзуем Git дл я отслеживан и я содержания этой книги. Он хорошо подходит для со­ вместной работы и совместного использован и я , что делает его важ н ы м и н струме нтом для сайтов, которые охваты вают DevOps.

W

Для получения дополнител ьной и нформации о DevOps см. раздел 3 1 . 1 .

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

Git использует интеллектуальную с истему сжатия, чтобы сн изить стоимость

хра н е н и я все й истор и и , и в больш инстве случаев эта с истема достаточно эффективна. Система

G it отл и ч н о подходит для разработч иков, потому что о н и могут с ворачи ­

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

G i t — бол ьш о й шаг вперед в управл е н и и

верс и я м и — или , возможно, бол ее точ но, это бол ьшой ш а г назад, но в хорошем с м ыс ­ л е . Ран ни е с исте м ы контроля верс и й , такие к а к RCS и CVS, испол ьзовал и локальн ые хран ил ища, но не могл и обеспе ч и вать совместную работу, слия н и е и з м е н е н и й и не-

1 0Напр и мер, п редположи м , ч то системные адм и н истраторы Алиса и Боб оба редактируют оди н и тот же файл и кажды й из н и х в н ос и т некоторые изменен и я . Алиса сохран я ет файл первой. Когда Боб сохраняет свою копи ю файла . он перезаписывает версию Али с ы . П осле того как Алиса выйдет из редактора , ее изменени я полностью и бесследно исчезнут.

Глава 7. Сценарии и командная оболочка

267

зависимую разработку проектов. В н астоящее время установка файлов под контрол е м версий — это быстрая , простая и локальная операция. В т о ж е время в с е рас ш иренные возможности совместной работы G it доступн ы для испол ьзования в соответствующих ситуациях. Систем а G it обладает сотнями функций и может быть довольно сложной в испол ьзо­ вании. Тем не менее большинство пользователе й Git обойдутся лишь нескольким и про­ стым и командами. Особые ситуации луч ш е всего обрабатывать путем поиска в Googl e описания того, что вы хотите сделать (например, «git undo last commit » ) . В первую оче­ редь Google , конечно же , предложит посетить сайт Stack Overflow и н айти дискуссию, которая точ но соответствует вашей ситуаци и . П режде всего, н е пан и куйте. Даже если вам кажется , что вы испортили хранилище и удалили результаты работы за последн ие несколько часов, в системе Git, скорее всего, есть скрытая копия. Вам просто нужно ис ­ пользовать флан re f l o g и найти ее. Прежде ч е м в ы начнете испол ьзовать систему Git, укажите с вое имя и адрес элек­ трон ной почты : $ qit confiq — — qlobal user . name » John Q . Ulsah» $ qi t confiq — — qlobal user . email «[email protected] admin . com»

Эти команды создают ini-файл конфигураци и G it -1 . gi tconfig, если он еще не су­ ществует. Более поздние команды git ч итают этот файл для н астройки конфигураци и . Система Git предоставляет пользователя м ш ирокие возможности для настройки рабоче­ го процесса.

Простой пример Git Мы разработали простое хранилище примеров для поддержки некоторых сценариев оболочки. На практике вы можете испол ьзовать Git для отслеживания кода управления конфигурацией, шаблонов инфраструктуры , с пециальных сценариев, текстовых докумен ­ тов, статических веб-сайтов и всего, что вам нужно дл я работы в течение долгого времени. Следующие команды создают новое хранилище G it и заполняют его: $ pwd /home /bwh a l e y

$ mkdir s cripts & & c d scripts $ qit ini t I ni t i a l i z e d emp t y G i t r e po s i t o r y i n /home /bwha l e y / s c r i p t s / . gi t /

$ cat > super- script . sh lt ! /Ьin/ sh > echo » Hello , world» > EOF $ chmod +х super- script . sh $ qit add . $ qi t commit -m » Initial commi t «

[ ma s t e r ( r o o t — c ommi t ) 9 a 4 d 9 0 c ] supe r — s c r i p t . s h 1 f i l e chang e d , О i n s e r t i on s ( + ) , О de l e t i on s ( — ) c r e a t e mode 1 0 0 7 5 5 supe r — s c r i p t . s h

В приведен ной выше последовательности команда gi t ini t создает инфраструктуру хранилища, создавая каталог . gi t в каталоге /home/bwhaley/ scripts. После того как вы создадите исходный сценарий «helo, world» , добавьте команду git add . Она копирует ero в » индекс» Git, который является промежуточной областью для предстоящей фиксации. Индекс — это не просто список файлов для фиксации; это дерево файлов, каждое из которых является таким же реальным, как текущий рабочий каталог и содержимое храни-

Часть 1. Основы администрирования

268

лища. Файлы в индексе имеют содержимое, и в зависимости от того, какие команды вы вы­ полняете , это содержимое может отличаться как от хранилища, так и от рабочего каталога. Команда

git add на самом деле просто означает «ер из рабочего каталога в индекс » . gi t commi t вводит содержимое и ндекса в хранилище. Для каждой фикса­ ции требуется сообщен и е журнала. Флаг -m позволяет вкл юч ить сообщение в команд­ ной строке. Если вы оставите это, команда gi t запустит для вас редактор . Команда

Теперь внесите изменения и проверьте их в хран ил ище. $ vi super- script . sh $ gi t commi t super- s cript . sh -m 11маdе the script more super » [ ma s t e r 6 7 5 1 4 f l ] Made t h e s c r i p t mo r e s up e r 1 f i l e c h a n g e d , 1 i n s e r t i on s ( + ) , О d e l e t i on s ( — ) И менован и е модифицированн ы х файлов в командной строке

gi t commi t обходит

обычное испол ьзован ие Git и ндекса и создает вариант, которы й вкл ючает только изме­ нения в указанные файлы . Существующий и ндекс остается неизменн ы м , и система Git и гнорирует любые другие файл ы , которые могут быть измен е н ы . Если изменение с вязано с нескольким и файлам и , существуют нескол ько вариантов. Есл и вы точ но знаете , какие файл ы были измен е н ы , вы всегда можете их перечислить в командной строке , как показано выше. Если вы ленивы, то можете выполнить команду

git commit

— а , чтобы с истема

Git добавляла все измененные файлы в и ндекс перед в ы ­

полнением фиксации. Однако у этого последнего варианта есть пара подводных камней. Во-первых, могут быть изм е н е н ы файл ы , которые вы не хотите включать в ф и кса­ цию. Напри м е р , есл и у сценария

super-script . sh был файл конфигураци и , и вы из­

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

git commit

— а выбирает только

изменения в файлах , которые в настоя щее врем я находятся под управл е н и е м систе м ы контроля верс и й . Он н е отображает новые файл ы , которые в ы , возможн о , создали в ра­ боч е м каталоге . Для обзора состоя н ия с исте м ы G it вы можете вы пол н ить команду

get s tatu s . Эта

команда сообщает вам о новых, измен е н н ых и и нде кс и рован ных файлах. Н априм е р , предпол ожим , ч т о в ы добавили с ц е н а р и й

more — s c r i p t s / an o the r — s c r ip t . s h .

Система Git может показать следующее. $ gi t s tatus On b ranch ma s t e r Chan ge s n o t s t a g e d f o r commi t : ( u s e » gi t add < f i l e > . . . » to upd a t e wh a t wi l l Ье commi t t e d ) ( u s e » g i t c h e c kout — — < f i l e > . . . » t o di s c a r d change s i n wo r ki n g d i r e c t o r y ) modi f i e d : s up e r — s c r ip t . s h U n t r a c ke d f i l e s : ( u s e » g i t add < f i l e > . . . » t o i n c l u de in wh a t wi l l Ье commi t t e d ) mo r e — s c r i p t s / tmp f i l e n o change s added t o commi t ( u s e » gi t add » and / o r » g i t commi t — а » ) Сценарий

another- script . sh не указан по и м е н и , потому что система Git еще н е

видит каталог m o re — s c r i p t s , который его содержит. Вы можете видеть, что сценар и й

super-script . sh был изменен , а также увидеть файл tmpfile, котор ы й , вероятно, не gi t diff super ­ script . s h , чтобы увидеть изм е н е н и я , внесен н ы е в сценар и й . Команда gi t предлагает

должен быть включен в хранилище. Вы можете выпол н ить команду команды для следующих операц и й , которые вы можете вы пол н ить.

глава 7 . Сценарии и командная оболочка

269

Предположим , в ы хотите отследить изменения в файле

super-script . sh отдельно

от вашего ново го файла another- script . sh. $ git colllllli. t super- s cript . sh -m » The mos t super change yet » C r e a t e d c ommi t б f 7 8 5 З с : T h e mo s t s u p e r change y e t 1 f i l e s c h a n ge d , 1 i n s e r t i on s ( + ) , О de l e t i on s ( — ) Для того чтобы искорен ить файл

tmpfi le из систе м ы Git, создайте ил и отредакти­ gi tignore и пом естите в него имя файла. Это заставляет систему G it игно­ рировать файл tmpfile раз и навсегда. Шаблон ы в тоже работают. руйте файл

.

$ echo tmpfile >> . gi tignore Наконе ц , зафиксируйте все сделанные изме н е н и я . $ git add . $ sudo git commi t -m » Ignore tmpfile ; Add another- script . sh to the repo » C r e a t e d commi t 3 2 9 7 8 е б : I gn o r e tmp f i l e ; add a n o t he r — s c r i p t . s h t o t h e r e p o 2 f i l e s c h a n ge d , 2 i n s e r t i on s ( + ) , О de l e t i on s ( — ) c r e a t e mode 1 0 0 6 4 4 . gi t i g n o r e c r e a t e mode 1 0 0 7 5 5 more — s c ri p t s / a n o t he r — s c r i p t . s h Обратите внимание на то, что сам файл

.

gi tignore становится частью управляемого

набора файлов, который обычно вы хотите. Зачастую приходится повторно добавлять фай­ лы, которые уже находятся под контролем , поэтому команда gi t

add

это простой способ

сказать: «Я хочу, чтобы образ нового хранилища выглядел как рабочий каталог, за исключе­ нием того, что указано в

gi tignore» . В этой ситуации нельзя просто выполн ить команду another-script . sh и . gi tignore; эти файлы являются новым и Д11 Я системы Git и поэтому должны быть явно добавлены.

gi t commi t

-а,

.

потому что она не найдет файлы

Л овушки G it Для того чтобы заставить вас думать, что с исте ма Git управляет файлам и разр е ш е ­ ний, а также их содержим ы м , о н а показывает в а м режим ы файлов при добавл е н и и но­ вых файлов в хранили щ е . Это н еправда ; с исте ма Git не отслеживает режи м ы , владель­ цев ил и вре мя модификации. Система Git

отслеживает бит исполнения. Если вы выпол няете сценар и й с установ­

ленным битом исполнения, л юбые будущие клоны также испол няютс я . Однако н е сле­ дует ожидать, что система Git будет отслеживать право собственности или статус «только Д11 Я чте ния » . Следствием является то , что вы не можете рассчитывать на испол ьзование

систем ы G it для восстановления сложных иерархий файлов в с итуациях, когда важ н ы права собственности и разрешения . Другим следствием является то, что в хранилище Git н икогда нельзя включать простые

текстовые пароли и другие секреты. Они не только открыты Д11 Я всех, кто имеет доступ к хранилищу, но также могут бьпь непреднамеренно распакованы в форме, доступной миру.

Коллективное кодирова н ие с помощью системы G it Появл е н и е и б ыстр ы й рост сайтов колл е ктивной разработки , таких как G it H ub и Git Lab, я вляется одн им из самых важных тенденций в нове й ш е й компьютерной исто­ рии . М илл ион ы проектов программного обеспечения с открытым исходны м кодом соз­ даются и п розрачн о управля ются огром н ы м и сообщества м и разработчи ков, которые испол ьзуют все м ы сл и м ы е языки . П рограм мное обеспечение н икогда н е б ыло проще создавать и рас пространять.

270

Часть 1. Основы администрирования

G itHub и Git Lab — это, по сути, хранилища Git с множеством дополнительных функ­ ций, связанн ы х с коммуникацией и рабочим процессом. Хранилище может создать лю­ бой человек. Хранилища доступны как благодаря команде gi t, так и в И нтернете. Веб­ и нтерфейс дружелюбен и предлагает функции поддержки сотрудничества и интеграции. О п ыт коллективного кодирования может быть несколько пугающим для новичков, но на самом деле это н е сложно, как только будут поняты некоторые основные терми н ы и методология. •

» Master» — это имя по умолчани ю , назначенное первой ветви в новом хранил и ще . Большинство программных проектов п о умолчан ию испол ьзуют это и м я в каче­ стве основной линии разработки, хотя у некоторых главная ветвь может отсутство­ вать. Главной ветвью обычно управл яют, чтобы поддерживать текущий, но рабо­ тоспособный код; разработка нового кода происходит в другом месте. Последняя фиксация называется вершиной главной ветви. Ветвление (fork) в системе G it Hub представляет собой моментальный снимок хра­ н ил ища в определ е н н ы й момент времени. Ветвления возн икают, когда у пол ьзо­ вателя нет разреш е н ия на изменение основного хранилища, но он хочет внести изменени я , либо для дал ьнейшей интеграции с основным проектом , либо для соз­ дания совершен но отдельного пути разработки . Запрос на вкл ючение (pull request) — это запрос на объеди н е н и е изменений из одной ветви или ветвления в другую. Они ч итаются сторонн и м и разработчи ками целевого проекта и могут быть приняты для включения кода других пользователей и разработчи ков. Каждый запрос на включение также является н итью дискуссии, поэтом у ком м е нтировать предполагаемые обновления кода могут как владелец, так и л юбой другой человек.

Разработчи к (committer) и специалист по эксплуатации (maintainer) — это л и цо, у которого есть доступ к хранил и щу для записи. Для крупных проектов с откры­ тым исходным кодом этот очень желанн ы й статус предоставляется только дове­ ренным разработчикам, которые имеют долгую историю вкладов. Вам часто придется обращаться в хранилище Git Hub или G it Lab , чтобы найти или обновить часть программ ного обеспечения. Убедитесь, что вы просматриваете главное хранилище, а не случайное ветвлен ие. Обратите внимание на ближайшую м етку «ответ­ вление от» и следуйте за ней. Будьте осторож н ы при оценке нового програ м м ного обеспеч е н и я с этих сайтов. Н иже приведе н ы нескол ько вопросов , которые стоит обдумать, прежде чем запус кать случайную часть нового программного обеспечения на своих ком пьютерах. •

Сколько участников принимали участие в разработке?

Означает ли история фиксации , что разработка я вляется недавней и регулярной?

Какова лицензия и совместима л и она с потребностя м и вашей орган изации?

На каком языке написано п рогра м м ное обеспече н и е , и знаете л и вы , как им управлять? Достаточ но ли докуме нтации для эффективного ис пол ьзован ия программного обеспечения?

Больши нство проектов имеют определенную стратегию ветвления, на которую они полагаются , чтобы отслеживать изменения программного обеспечения. Некоторые сто­ ронн и ки настаивают на строгом соблюдении выбранной и м и стратегии , а другие — более снисходительны . Одной из наиболее ш ироко используемых является модель Git Row, раз-

Глава 7. Сценарии и командная оболочка

271

работан ная Винсентом Дриссеном (Vincent Driessen); дополн итель н ую и нформацию см. на сайте goo . g l / GD a F. П режде чем вносить свой вклад в проект, ознакомьтесь с методами ero разработки , чтобы помочь специалистам , которые его сопровождают. Прежде всего, пом н ите , что разработчики с открытым исходным кодом часто не по­ лучают н и какой платы. Участвуя в коллективной разра б от к е и поддержи вая проекты , они ценят терпение и вежливость.

7.9. ЛИТЕРАТУРА •

B Rooкs, FREDER1cк Р. J R . The Mythical Man — Month : Essays оп Software Engineering. Reading, МА: Addisoп-Wesley, 1 995 .

СнлсоN , Sсотт, AN D SтRA u в , B E N . Pro Git, 2nd edition. 2014. g i t — s c m . c om / b o o k / e n / v 2 . Исчер п ы вающая книга о Pro Git, свободно оп убл и ко в а н н ая п о лицензии Creative Commons.

Оболоч ки и сцена рии оболоч ки •

Roв в 1 N s , ARNOLD, AN D №LsoN Н . F. В Е Е В Е . Classic Shell Scrlpting. Sebastopol , СА: O ‘ Reilly Media, 2005. Книга, посвященная тр адиц и он ному (и переносимому ) диа­ лекту оболочки Boume. Она также содержит довольно м ного и нфор м ац и и об ути­ литах sed и awk.

PoWERs , S н ELLEY, J ERRY РЕЕК, Т1м O RE I LLY , AND М1кЕ LotJКIDES. Unix Power Too/s, (Зrd Edition) , Sebastopol, СА: O ‘ Reilly Media, 2002. Классическая книга о с истеме U N IX, охватывающая м ного вопросов, в том ч исле с це н ар и и дл я о бол оч к и sh и работу с командной строкой . Некоторые разделы несколько устарел и , но матери ал , каса­ ющийся оболочек, остается актуальн ы м .

SoвELL, М д R К G . А Practical Guide to Linux Comm a nds, Editors, and Shell Programming. Upper Saddle River, NJ: Prentice Н а , 20 1 2 . Книга заслуж и вает в н и ман ия , пос коль­ ку в ней описываются оболочки tcsh и bash.

S ноттs , W1 L L 1 л м Е . , J R . The Linux Command Line: А Comple te lntroductio n . San Francisco, СА: No Starch Press , 20 1 2 . Книга по с в я ще н а оболочке bash, н о в ней также есть материал об и нтеракти вной работе и п рограм м ирован и и . Бол ьшая часть материала относится к системам U N IX и Linux.

В ш м , R 1 с н л R о , AND C н R1sп N E BRESNAHAN . Linux Command Lin e and Shell Scripting ВiЬ/е (Зrd Edition). l ndianapois, I N : John Wiley & Sons, Inc. 20 1 5. Кн ига посвя щ е на, в основном , оболоч кам , в частности оболочке bash.

CooPER, M E N D EL. Advanced Bash -Scripting Guide. www . t l d p . o r g / L D P / a b s / h t m l . Свободно распространяемая и легко доступн ая в И н те р н ете книга. Не с м отря на ее название, новички ее легко поймут благодаря м ножеству хорош и х п р имеро в .

Регулярные вы ражения •

FRIEDL, J EFFREY. Mastering Regular Expressions (Зrd Edition) , Sebastopol , СА: O ‘ Reilly M edia, 2006.

GovvлERтs , JлN AN D SтEVEN LЕvпнлN. Regular Expressions Cookbook. Sebastopol , СА: O ‘ Reilly Media, 20 1 2.

Часть 1 . Основы администрирования

272 •

r e g u l a r — e x p re s s i o n s . i n f o . П одробный интерактивный источ­ ник информаци и о регулярных выражен иях с учетом всевозможных диалектов.

G oYVAE RTS , J AN .

KR U M I NS , PEТ E R I S . Perl Oпe-Liпers: 130 Prograтs That Get Thiпgs Dопе. San Francisco, СА: No Starch Press, 20 1 3 .

Python •

A L . Аиtотаtе the Boriпg Stиff with Pythoп: Practical Prograттiпg for Total Begiппers. San Franc isco, СА: No Starch Press, 20 1 5 . Удачное введен и е в програм ­ м и рование н а языке Python 3 и програ м мирование в целом . Содержит м ножество при меров систем ного администрирован ия . (Эл СвЕйГАРТ. Автоматизация рутинных задач с помощью Pythoп: практическое руководство для начинающих, пер. с англ . , изд. «Диалекти ка» , 20 1 6. ) SwE I GART,

P t LG R I M , MARK. Dive /пtо Pythoп . Berkeley, СА: Apress, 2004. Класс ическая к н и га о языке Python 2 , свободно доступная на веб-сайте d i ve i n t opython . n e t .

P 1 LG R I M МАRк. Dive /пtо Pythoп 3. Berkeley, СА: Apress, 2009. Dive l nto Python updated for Python 3. Кн ига свободно доступна на веб-сайте di ve i n t opython З . n e t . ,

Luтz, МлRк. Learпiпg Pythoп, 5th Editioп. O ‘ Reilly, 20 1 3 . Фундаментал ьная книга о языке Pytho n . ( M A P K Л УГц. Изучаем Pythoп, 5-е издание, в двух томах, пер. с англ » изд. «Диалектика » , 20 1 9 . ) RАмл L но Luc1лNo. F/иепt Pythoп . Sebastopol , СА: O ‘ Reilly Media, 20 1 5 . Advanced , idiomatic Python 3 . ,

B EAZLEY, Dлvю, A N D BRtAN К. J o N E S . Pythoп Cookbook (3rd Editioп) , Sebastopol , СА: O ‘ Reilly Media, 20 1 3 . Covers Python 3. G t тт , N олн, A N D J E R EMY М . J o N E s . Pythoп for Uпix апd L iпих Systeт Adтiпistrators, Sebastopol , СА: O ‘ Reilly M edia, 2008.

Ruby •

F LA NAGAN , Dлvю , A N D Уuк 1 н 1 Rо Млтs u м ото . The RиЬу Prograттiпg Laпgиage. Sebastopol , СА: O ‘ Reilly Media, 2008 . Классическая , исчерпывающая и хорошо на­ п исанная книга о языке Ruby из первых рук. Она уже нем ного устарела и не уч и­ тывает Ruby 2.0 и более новые версии; однако языковые различия между н и м и яв­ ляются м и н и мал ьн ы м и .

В LАск, Dлvю А . The Well-Groипded Rиbyist (2пd Editioп). Shelter lsland, N Y: Manning PuЫicat ions, 20 1 4. Н е бойтесь назва н и я , которое может отпугнуть новичков; это хорошая , основател ьная книга о языке Ruby 2. 1 .

Тномлs, DAVE. Prograттiпg RиЬу 1. 9 & 2. 0: 1he Pragmatic Prograттer’s Gиide (4th Editioп). Pragmatic Вoo kshelf, 20 1 3 . Classic and frequently updated.

F u Lтo N , HAL. The RиЬу Way: Solиtioпs апd Techпiqиes iп RиЬу Prograттiпg (3rd Editioп). U pper Saddle River, NJ: Addison-Wesley, 20 1 5. Еще оди н классический и современ­ ный с правоч н и к по языку Ruby, с легким философским уклоном .

глава

8

Управление учетными записями п ользовател ей

Современные вычислительные среды состоят из физического оборудования, облач­ ных систем и виртуальных хостов. Гибкость этой гибридной и нфраструктуры порождает растущую потребность в централизован ном и структурированном управл е н и и учетн ы ­ ми записям и . Системные адми нистраторы должны понимать как традиционную модель учетных записе й , используем ую U N IX и Linux, так и с пособы рас ширен ия этой модели для и нтеграции с таким и службам и каталогов, как LDAP и M icrosoft Active Directory. Правильное управление учетны м и записями является ключевым фактором безопас­ ности систе м ы . Редко используемые учетные записи, а также учетны е записи с ле гко угады вае м ы м и п ароля м и являются основн ы м и целям и для злоу м ы шле н н и ков. Даже если вы используете автоматизированные инструменты ваш е й с истем ы для добавления и удаления пользователе й , важно пон имать измен е н и я , которые осуществляют эти ин­ струменты. По этой причине м ы нач инаем обсуждение управлен ия учетными записями с простых файлов, которые необходимо изменить, чтобы добавить пользователей авто­ номного комп ьютера. В последующих разделах мы рассмотри м команды управления бо­ лее высокого уровн я , которые поставляются с наш и м и демонстрацио н н ы м и примерами операцион ных систе м , и файлы конфигурации , которые контрол ируют их поведение. В большинстве систем также есть простые и нструменты с графическим пользователь­ ским интерфейсом для добавления и удаления пользователей, но они, как правило, не под­ держивают дополнительные функции , такие как пакетный режим или рас ширенная лока­ лизация. Эти инструменты достаточно простые, поэтому мы не считаем целесообразным детально анализировать их работу и в этой главе будем использовать командную строку.

Часть 1. Основы администрирования

2 74

В этой главе мы сосредоточ имся искл юч ител ьно на добавл е н и и и удал е н и и пол ьзо­ вателей. М ногие тем ы , связан н ы е с управлен ие м учетн ы м и зап ися м и , описан ы в других главах (здесь вы найдете соответствующие ссылки). •

• •

П одкл ючае м ые м одул и ауте н т и ф и каци и (pl uggaЬ l e aut h e nt i c at i o п modules РАМ ) для ш ифрован ия паролей и обеспече н и я их стой кости, описан ы в главе 1 7 (см. раздел 1 7 . 3 ) . Хранилища паролей оп исан ы в главе 27 (см . раздел 27.4). Службы каталогов, такие как Ope n LDAP и Active Directory, рассматри ваются в гла­ ве 1 7 (см. раздел 1 7 . 2 ) . Наконец, политические и п равовые вопросы яаляются основны м и темами главы 3 1 .

8. 1 . Основы УПРАВЛЕНИЯ УЧЕТНЫМИ ЗАПИСЯМИ По существу, пользователь предстааляет собой всего л и ш ь число, 32-битное целое чис­ ло без знака, известное как идентификатор пользователя , ID ил и U I D. Почти все, что свя­ зано с упраалением учетн ы м и запися ми пользователей, вращается вокруг этого числа. Система определяет и нтерфейс при кладного програм мирования (через стандартн ые подпрогра м м ы библиотеки С ) , который осущесталяет п рямое и обратное отображе ние между идентифи каторами U I D и более пол н ы м и н абора м и с веде н и й о пол ьзователях. Например, фун кция getpwuid ( ) п р и н имает U I D в качестве аргуме нта и возвращает соответствующую запись, содержащую имена пол ьзователя и е го домашнего каталога. Аналогично фун кция getpwnam ( ) просматри вает эту же информацию по имени учетной записи. Традицион н о эти библ иотеч н ые фун кции получал и аргументы непосредстве нно из текстового файл а /etc/pas swd. Со временем о н и начал и поддержи вать допол н итель­ ные источ ники информации , такие как сетевые информацион н ы е базы дан н ых (напри­ мер, L DAP) и файл ы с защитой от чте н и я , в которых заш ифрован н ые парол и можно было бы хран ить более надежно. Эти уровни абстракции ( которые часто устанаалива ются в файле ns swi tch . conf) позволяют фун кциям более высокого уровня фун кционировать без достоверного знания ис пользуемого метода управл е н и я базой дан н ых. Например, когда в ы входите в систе­ му как d o t t y , процесс регистрации (Window Serve r, login, getty или что-то еще) при­ меняет к этому и м е н и фун кцию getpwnam ( ) , а затем сравн и вает парол ь , который вы вводите , с е го заш ифрованной зап исью, возвращаемой библ иотеко й , независимо от его фактического источ н ика. Мы нач инаем с подкаталога /etc/pas swd, которы й по- прежнему поддержи вается везде. Другие варианты воспроизводят эту модель, есл и не по форме, то по духу.

W Допол нительную информаци ю о файле ns switch . conf см. в разделе 1 7. З .

8.2. ФАйЛ /Eтc / PASSWD Файл /etc/passwd содержит список пользователе й , которые известны системе. Его можно расширить или заме н ить службой каталогов, поэтому е го можно считать пол н ы м и достове р н ы м только в автономн ы х системах. Традицион но заш ифрован н ы й пароль каждого пол ьзователя также хран ился в фай­ ле /etc /pas swd, которы й был доступен для чте н и я . Однако поя ал е н и е более мощных процессоров повы с ил о вероятность взлома этих открытых парол е й . В ответ систе м ы

Глава 8. Управление учетными записями пользователей

275

U N IX

и Linux переместили пароли в отдельны й файл (/etc/master . passwd в Free B S D и /etc/ shadow в Linux), которы й защищен о т чтения. В наши дни с а м файл pas swd содержит тол ько формал ьную запись, чтобы отметить прежнее местоположен ие поля для ввода пароля (х в Linux и * в Fre e B S D) . В процессе регистраци и пользователя с истема обращается к файлу / etc/pas swd в поисках идентификатора пользователя и е го домашнего каталога , а также другой и н ­ формации. Каждая строка файла описывает одного пользователя и содержит семь следу­ ющих полей , разделенных двоеточиями: • регистрационное имя; • шифрованн ы й пароль или » запол нитель» пароля ( вопросы применения ш ифрованных паролей описа н ы далее в этом разделе); • идентификатор пользователя U I D; • идентификатор группы по умолчан ию G I D; • поле G ECOS ( полное и м я , номер офиса, рабочи й и домашний телефоны ) ; • домашн и й каталог; • регистрационная оболочка. Вот примеры правильно составленных записей файла /etc/passwd. roo t : x : O : O : Th e S y s t e m , , х 6 0 9 6 , : / : / Ь i n / s h j l : ! : l O O : O : Jim L a n e , E C OT B — 3 , , : / s t a f f / j l : /Ь i n / s h dott y : x : l 0 1 : 2 0 : : /home /do t t y : / Ь i n / t c s h

m Дополнительную информацию о файле nsswi tch . conf с м . в разделе 1 7. 3 . Если пользовательские учетные записи совместно испол ьзуются с помощью службы каталогов, например L DA P, в файле pas swd появляются специальн ые записи , которые начинаются с с и м вола » + » или » — » . Эти записи сообщают систе м е , как и нтегрировать данные службы каталогов в содержимое файла /etc/pas swd. Эта интеграция также мо­ жет быть реализована в файле / etc/nsswi tch . conf. В следующих разделах м ы рассмотри м поля файла /etc/passwd более подробно.

Регистрационное имя Регистрацион н ы е имена ( называемые также именами пользователей) должн ы быть уникальн ы м и и в зависимости от с исте м ы могут иметь ограничения на длину и н абор символов. В настоящее время во всех версиях систем UN IX и Linux эта длина не превы­ шает 32 символа. Пользовательские имена не могут содержать двоеточия и символы новой строки , по­ скольку эти с и м волы применяются в качестве разделителей полей и зап исей соответ­ стве нно в файле passwd. В зависимости от с исте м ы на пользовательские имена могут быть наложе н ы и другие о гра н и ч е н и я . В с истем е Ubuntu эти огра н и ч е н ия наиболее слабые , поскольку они допус кают и м е н а , нач инающиеся или цели ко м состоящие из чисел и других специальных символов. ‘ П о м ногочисленным причи н а м , которые было бы сли ш ком долго объяснять, м ы рекомендуем огран ичивать допусти м ы й диапазон ре­ гистрационн ых имен алфавитно-цифров ы м и с и м волами , испол ьзовать только н ижн и й регистр и начинать и м е н а с буквы . Регистрацио н н ы е и м е н а чувствител ьны к регистру. Нам неизвестн ы случ а и . ког­ да смешен ие регистров в именах приводило бы к возникнове н и ю проблем , но имена, 1 По какой-то непостижи мой причине допустимый набор символов в U nicode включает эмотиконы . Эrо делает нас © .

часть 1. Основы администрирования

276

состоящие из строч ных букв , считаются традицион н ы м и , к тому же их проще вводить. Есл и , например , такие регистрационные имена, как j oh n и Joh n , будут принадлежать различ н ы м л юдя м , проблемы обязател ьно возникнут. Следует выбирать такие регистрационные имена, которые легко запомнить, поэтому имя, состоящее из случайной последовательности букв, я вляется не сам ым удачн ы м ва­ риантом. П оскольку регистрацион н ые имена часто используются в адресах электрон ной почт ы , полезно определ ить стандартную процедуру их формировани я . П ол ьзователя м должна быть предоставлена возможность делать обоснованные предположен и я о реги­ страционн ых и м енах друг друга. И мена, фам ил и и , и н и циалы и сочетания этих эле мен ­ тов — вот приемлемые варианты для схе м формирования имен.2 Л юбая жестко заданная схема в конечном счете приводит к поя вл е н и ю дубли катов ил и сли ш ком дл и н н ых и м е н , поэтому и ногда придется делать искл ючен и я . Выберите стандартн ый способ разреш е н ия конфликтов, добавив, например, в конец имени цифру. В крупных организациях в адресах электрон ной почты часто используются пол н ы е и м е н а (например, J o h n . Q . Р u Ы i c @ m y s i t e . c om) , благодаря чему регистрацион н ые имена скрываются от внешнего м ира. Это пре красная идея , но, чтобы облегчить работу адми н истраторам , н еобходимо установить четкое и понятное соответствие между реги­ страционными именами и реальными именами пользователей. В закл ючение отмети м : н еобходимо, чтобы имя пол ьзователя н а всех ком пьютерах было оди наковы м . Это удобно как самому пользователю, так и адми н истратору.

З а ш ифрова н н ые па рол и И сторически с истем ы ш ифровали п арол и пользователей с помощью ал горитма По мере увеличения вычислительной мощности эти парол и стали тривиальными для взлома. Затем системы перешли на скрытые пароли и криптографию на основе алго­ ритма M D5. Теперь, когда в алгоритме M D5 были обнаружены значител ьн ые недостатки , текущим стандартом стало хеширование паролей с помощью криптографической «сол и » на основе алгоритма SHA- 5 1 2 ( с м . документ Guide to Cryptography на веб-сайте owa s p . o r g ) . Н аши илл юстративные с истем ы поддержи вают м ножество ал горитмов ш ифрования, но все они по умолчанию соответствуют алгоритму S HA-5 1 2 . Если в ы не обновляете си­ стемы из более старых версий, вам не нужно обновлять выбор ал горитма . DES.

В с истеме Fre e B S D алгоритм , задан н ы й по умолчан и ю , можно модифици­ ровать с помощью файла /etc/ login . conf. В с истемах Deblan и Ubuntu алгоритм , заданный по умолчанию, можно было модифицировать с помощью файла /etc/ login . defs, но после появления подключаемых модулей аутентификации РАМ , этот подход стал устаревши м . Политики установления паролей п о умолчанию, включая выбор алгоритма хеширования, можно найти в файле /etc/pam . d/common-passwd.

RHEL

В с истемах алгоритм ш ифрования паролей можно по-прежнему установить в файле /etc/ login . defs с помощью команды authconfig, как показано н иже: $ sudo authconfig

pas salgo= sha 51 2

— —

update

2 Стандарт RFC 5 3 2 1 требует, чтобы локал ьная часть адреса (т.е. часть перед з наком @ ) сч италась чувствительной к регистру. Остальная часть адреса обрабаты вается в соответстви и со стандартам и D N S , который нечувствителе н к регистру. К сожален ию, это различие я вля ется тонк и м , и о н о н е реал и зуется повсеместно. Помните также , что многие устаревш и е систем ы электронной почты возни кл и до появле н ия сообщества I E�F.

Глава 8. Управление учетными записями пользователей

277

Изменение ал горитма ш ифрования паролей не приводит к обновл е н и ю существу­ ющих парол е й , поэтому пользовател и должны вручную изме н ить свои парол и , прежде чем новый алгоритм вступит в действие. Для того чтобы аннулировать стары й пароль и принудительно внести обновления , используйте команду $ chage -d О имя_ поль з о в а теля

Качество пароля — еще одна важная проблема. Теоретически более длинные пароли более безопас н ы , как и парол и , содержащие разнотипные с и м волы (например, проп ис­ ные буквы , знаки пре п и нания и цифры). Бол ь ш и нство с истем позволя ют уста н а вл и вать ста ндарты построе н и я парол е й дл я пользователе й , н о имейте в виду, что пользователи могут умело обойти эти требо­ вания, есл и найдут их чрезмер н ы м и или обремен ител ьн ы м и . Стандарты , используемые наш ими иллюстративн ы м и с истемами , приведе н ы в табл . 8 . 1 . Таблица 8 . 1 . Стандарты качества паролей Место установки

Система Требования по умолчанию

/etc/login . defs /etc/ securi ty/pwquali ty . conf /etc/pam . d/ sys tem-auth

Red Hat CentOS

Больше В символов с требованием уровня сложности

DeЬian Ubuntu

Больше 6 символов с требованием уровня сложности

/etc/login . defs / etc/pam . d/ common-password

FreeBSD

Без ограничений

/etc/ login . conf

. .

.

.

. . . «. . . . . . . .

«

· · •· · · · ·

· ·

Ш Дополнительную информацию о выборе паролей см. в разделе 27. 3 . Требован ия к качеству пароля — это вопрос дебатов, н о м ы рекомендуем в а м опреде­ лить приоритет по сложности . 3 Двенадцать символов — это м и н и м ал ьная длина для бу­ дуще го парол я ; обратите вниман и е , что это значительно больш е , ч е м длина, задан ная по умолчанию в л юбой системе. В вашей организации могут существовать общие стан ­ дарты качества пароля. Если это так, отложите эти настройки. Если в ы реш ил и обойти с вои систе м н ы е и нструменты для добавления пол ьзовате ­ лей и вместо этого изм е н ить файл /etc/pas swd вручную ( в ы пол н и в команду vipw с м . раздел 8 . 6 ) , чтобы создать н овую учетную запись, поместите в зашифрова н ное поле пароля с и мвол * ( F ree B S D ) или х ( Linux) . Эта мера п редотвратит несан кцион и ­ рован ное испол ьзование учетной записи д о тех пор, пока в ы и л и пользовател ь не уста­ новите реальны й парол ь. Шифрованные пароли имеют постоян ную длину (86 символов для S HA-5 1 2 , 34 сим­ вола для M D5 и 1 3 символов для D E S ) независимо от длины н езашифрованного паро­ ля. П ароли шифруются в сочетании со случайной «солью» , так что одному паролю могут соответствовать разные заш ифрован ные фор м ы . Если два пользователя выбирают оди н и тот ж е пароль, этот факт обыч но не может быть обнаружен путем проверки зашифро­ ванн ых паролей. П арол и , заш ифрованные алгоритмом M D5 в файле тен евого парол я , всегда нач ина­ ются с с и мволов $ 1 $ или $ md 5 $ . Пароли Blowfish нач и н аются с символов $ 2 $ , пароли SHA-256 — с $ 5 $ , а пароли S HA- 5 1 2 — с $ 6 $ .

‘Допол нительную и н формаuию п о этой проблеме с м . п о адресу s t r e n g t h . png.

x k c d . с о т / c o m i c s / p a s s w o r d_

278

Часть 1 . Основы администрирования

Идентификатор пользов а теля Ш Дополнительную информацию об учетной записи пол ьзователя

root

см . в разделе 3. 1 .

П о определе н и ю иде нтификатор пол ьзователя r o o t равен нул ю . Бол ь ш и нство с и ­ стем также определя ют псевдопол ьзовател е й , например Ь i n и d a em o n , как владельцев команд ил и файлов конфигурации . Эти фикти вные регистрацион н ы е имена принято указывать в начале файла /etc/pas swd, присваивая им низкие идентифи каторы U I D и назначая дл я н и х фиктивную оболоч ку (напри мер, /Ьin/fal se) , чтобы н и кто н е мог войти в систему под эти м и именами. Для того чтобы зарезервировать достаточно места для будущих фиктивных пол ьзо­ вателе й , м ы рекомендуем назначать U I D для реал ьн ы х пол ьзователе й начиная с ООО или выше. (Желаем ы й диапазон для новых U I D можно указать в файлах конфигурации с помощью параметров команды useradd.) П о умолчанию наши систе м ы ссылок Linux присваи вают идентификаторы U I D , начи ная с 1 000. Система Free BSD прис ваивает пер­ вому реальному пользователю U I D, равн ы й 1 00 1 , а затем добавляет един ицу для каждо­ го нового пользователя . Не испол ьзуйте U I D повторно, даже когда пользовател и покидают вашу организа­ цию и вы удаляете их уч етные записи. Эта предосторожность предотвращает пута н и ­ цу, которая может возн икнуть при дал ьн е й ш е м восстановл е н и и файлов из резервных коп и й , в которых пол ьзователи могут быть идентифицирова н ы с помощью U I D , а не по регистрационному имен и . Иде нтификаторы U I D должны быть у н и кальн ы м и в мас ш табе всей орган иза ц и и . И н аче говоря , конкретн ы й U I D должен ссылаться на одно и то ж е регистрационное и м я и одного и того ж е человека на всех маши нах, которые разрешено исполь з овать этому человеку. Нес пособность поддерживать уникал ьн ы е U I D может при вести к проблемам безопасности в таких системах, как N FS, а также к путан ице , когда пользователи пере­ ходЯт из одной рабоче й груп п ы в другую. Трудно поддерживать ун и кальные U I D, есл и групп ы м а ш и н управляются разн ы м и л юдьми или организаци я м и . Эти пробл е м ы носят техн ический и политический харак­ тер. Л учшее решение — иметь централ ь н ы й сервер базы дан н ы х ил и каталог, которы й содержит запись дл я каждого пользователя и обес печивает уникальность. Более простая схе ма — назначить каждой группе внутри организации собстве н н ы й диапазон U I D и позвол ить каждой группе управлять собстве н н ы м диапазоном. Это ре­ ш е н ие ограничивает пространство U I D , но не устраняет параллельную проблему с уни­ кал ьн ы м и регистрацио н н ы м и именам и . Независимо от ваше й схе м ы , основной задачей я вляется согласован ность подхода. Если согласованность невозможна, у н икал ьность U 1 D становится второй по важности цел ью. Популярной системой управления и распростран е н и я и нформации об учетн ых за­ п ис я х , которая зарекоме ндовала себя в круп н ы х орга н изациях, я вляется п ротокол Lightweight Directory Access Protocol ( LDAP ) . Он кратко описан в этой главе и более под­ робно рассматривается в разделе 1 7 . 2 .

Идентификатор груп п ы по умолч а н и ю Как и идентификатор пол ьзовател я ( U I D) , иде нтифи катор груп п ы ( G I D) я вляет­ ся 32-битов ы м цел ы м ч ислом. Идентифи катор О зарезервирован для групп ы с и м е н е м roo t , s y s t em или whee l . Как и в случае идентификаторов пол ьзователей, систе м ы ис­ пользуют несколько предоп ределенных груп п для собствен н ы х нужд. Увы , в этом вопро­ се согласованности среди коллег — п роизводителей с истем не набл юдается. Например,

Глава 8. Управление учетными записями пользователей

279

груп па Ьin и меет идентифи катор G J D , рав н ы й 1 , в с истем ах Red Hat , CentOS и G I D , равный 2, — в системах Ubuntu, Deblan и G J D, равный 7, в системе Free B S D . В т е далекие времена, когда ком пьютеры б ы л и е щ е дорогим удовол ьствием , группы использовал ись для учета машин ного времени, чтобы время работы центрального про­ цессора, врем я , затраченное на регистрацию, и использованное дисковое п ространство оплач ивал соответствующи й отдел . В н астоящее время группы испол ьзуются , в основ­ ном , для организации совместного доступа к файлам. —

m Допол нительную и нформаци ю о каталогах с установленным битом s e t g i d см . в деле 5 . 5 .

раз­

Группы определя ются в файле /etc/group , а поле идентификатора групп ы в фай­ ле /etc/pas swd задает стандарт н ы й ( «фактичес к и й » ) идентификатор G I D на момент регистрац и и пользователя в систе м е . Этот идентификатор н е и грает особой роли при определении прав доступа; он испол ьзуется лишь при создан и и новых файлов и ката­ логов. Новые файлы обычно в кл ючаются в фактическую группу с воего владельца , но если вы хотите разделять файл ы с другим и участни кам и проектной групп ы , не забудьте вручную измен ить для этих файлов владел ьца группы. При этом следует и меть в виду, что если у каталогов установлен бит s e t g i d (02000) или файловая система с монтирована с опцией grpid, новые файлы включаются в груп­ пу родительского каталога.

П оле GECOS Это поле иногда ис пользуется для хранен и я персональной и нформации о каждом пол ьзователе . Оно я вл яется н аследием некоторых из ран н и х верс и й с истем ы U N IX, испол ьзовав ш и х для разных цел е й семейство операцион н ых с истем General Elect ric Comprehe nsive Operating Systems. Оно не и меет четко о предел е н ного с интакс и с а . В принципе структура пол я G ECOS может быть произвольной , а ее элементы разделя­ ются запятым и и размещаются в следующем порядке: •

полное имя (часто используется только это поле) ;

номер офиса и здания ;

рабочий телефон ;

домашний телефон.

lШ Дополн ительную информацию о базе данных LDAP см в разделе 1 7 . 2 . И нформацию, содержащуюся в поле G ECOS, можно изменять с помощью команды chfn. Эта команда используется для веден и я и обновл е н и я с п иска телефон н ых номе­ ров, но е ю часто злоупотребляют: например, пользовател ь может изменить и нформа­ цию так , что она станет н е цензурной или некорректной. В некоторых систем ах мож­ но установить ограничен и я , указав, какие поля может модифицировать команда chfn. Адми н истраторы сетей бол ь ш инства университетских городков совсем отключают ко ­ манду chfn. Во м ногих с истемах команда chfn » по н имает» только файл pas swd, по­ этому, если для управления регистрационной информацией вы испол ьзуете базу дан н ы х LDAP и л и какую-либо и н у ю службу каталогов, команда chfn может не работать вовсе.

Домаш ни й катало г Войдя в систему, пользовател ь попадает в свой домашн и й каталог. И менно в домаш­ них каталогах оболоч ки регистрации и щут и нформацию, связанную с учетной зап исью,

Часть 1. Основы администрирования

280

псевдонимы оболоч ки и переменные окруже н ия , а также кл ючи S S H , сертификаты сер­ веров и другие параметры. Следует и м еть в виду, что если домаш ние каталоги смонтирован ы вне файловой си­ сте м ы , то в случае проблем с сервером ил и с самой сетью они могут оказаться н едо­ ступ н ы м и . Если на момент регистрации этот каталог отсутствует, выводится сообщение вроде no h ome d i r e c t o r y (домашн и й каталог отсутствует) и пользовател ьские дан ные поме щаются в каталог / . 4 В качестве ал ьтернативы регистрацию можно отключить со­ всем с учетом систе м ной конфигурац и и. Более подробно домаш н и е каталоги описыва­ ются в разделе 8 . 6 .

Регистрационная оболоч ка В качестве регистрацион ной оболочки, как правило, задается и нтерпретатор команд, но в прин ципе это может быть л юбая программа. П о умолчани ю для системы Free B S D испол ьзуется и нтерпретатор sh, а дл я с исте м ы Linux и н терпретатор bash ( G N U ­ версия оболочки sh) . В не которых системах пол ьзовател и могут менять и нтерпретатор с помощью коман­ ды chsh, но, подобно chfn , эта команда может не работать, есл и дл я управления ре­ гистрационной и нформацией вы испол ьзуете базу дан н ых L DAP или какую-л ибо иную службу каталогов. Есл и вы испол ьзуете файл /etc/pas swd, систе м н ы й адм ин истратор всегда может замен ить интерпретатор пол ьзователя , отредактировав файл passwd с по­ мощью програ м м ы vipw. —

8.3 . ФАйлы /Eтc / sНADow Файл с крытых паролей доступен для чтения только суперпользователю и предназна­ чен для хране н ия зашифрован н ы х парол е й подальше от л юбоп ытн ых глаз и программ взлома. В нем также содержится учетная и н формация , которая отсутствует в исход­ ном файле /etc/passwd. В настоящее время механизм с крытых паролей ис пол ьзуется по умолчанию практически во всех с истемах. Файл shadow не включает в себя файл pas swd, и последний не генерируется автома­ тически при изменении файла shadow. Оба файла необходимо хран ить независимо друг от друга ( ил и испол ьзовать команду наподобие useradd для автоматического управле­ ния файлам и ) . Как и /etc/pas swd, файл /etc/ shadow содержит одну строку для каж­ дого пользователя . Каждая строка состоит из 9 полей, разделенных двоеточиями: •

регистрацион ное имя;

заш ифрованный пароль;

дата последнего изменен ия пароля ;

м и н и м ал ьное число дней м ежду измене н ия м и пароля;

максимальное число дней между изменения м и пароля;

коли чество дней до истечения срока действия пароля, когда выдается предупреж­ ден и е ;

4Это сообщен и е поя вляется п р и регистрации в системе через консоль и л и терминал , но не через экра н н ы й диспетчер , такой как xdm, gdm или kdm. В последнем случае пользовател ь вообще будет н емедленно вы веден и з систе м ы , поскольку п рограмма-диспетчер не сможет осуществить запись в нуж н ы й каталог ( например, / gnome). …

.

Глава 8. Управление учетными записями пользователей

281

количество дней по истечении срока действия парол я , когда учетная запись аннул ируется;

дата истечения срока действия учетной записи;

зарезервирован ное поле, в настоя щее время пустое.

Л и ш ь первые два поля обязательно должн ы быть запол н е н ы . П оля дат в файле /etc/ shadow задаются в виде ч исла дней (а не секунд) , п рошедших с 1 января 1 970 года, что не является стандартным способом вычисления времени в системах U N IX и Linux.5 Типичная зап ись выглядит так. mi l l e r t : $ 6 $ i TE FbMTM$ CXmx PwErbEe f 9 RUBv f l z v 8 EgXQd a Z g 2 e Od5 uXyvt 4 s F z i 6G 4 1 I qavL i l TQgniAHm3 C z w / L o aG z o F z aМm . Yw01 / : 1 6 9 7 1 : 0 : 1 8 0 : 1 4 : : :

Приведем более подробное описание некоторых полей. •

Регистрационное имя совпадает с именем из файла /etc/passwd. Оно связывает записи файлов pas swd и shadow. Зашифрован н ы й пароль идентичен тому, который ранее хранился в файле /etc/ pas swd. Третье поле содержит дату последне го измен е н и я пользователем с воего пароля. Это поле обычно заполняется командой passwd. В четвертом поле задано кол и чество дне й , спустя которые пользователь сможет снова изменить пароль. Это не позволяет пользователя м немедленно возвращать­ ся к привычн ы м паролям после их обязательного изменения. Такая возможность кажется нам опасной, если в течение указанного времени будет обнаружено на­ руш е н ие безопасности с исте м ы . Поэтому мы рекомендуем устанавливать дан ное поле равным нулю. В пятом поле задано максимальное ч исло дней между двумя изменениями паро­ ля. С помощью этой установки адм и нистраторы заставл яют пользователе й менять свои парол и (подробнее механизм устареван ия парол е й описан в разделе 27.4). В системе Linux макси мальное время жизни пароля определя ется суммой значе­ ний дан ного и седьмого (льготны й период) полей. В шестом поле задано количество дней , оставшихся до момента устаревания паро­ ля , когда программа login должна предупреждать пользователя о н еобходимости сменить пароль. В восьмом пол е задан ден ь, в которы й истекает срок действия учетной записи (считая от 1 я н варя 1 970 года) . По прошеств и и этой даты пользовател ь не смо­ жет зарегистрироваться в системе, пока адм и н истратор не сбросит значение поля. Если поле оставлено пустым , учетная зап ись всегда будет активной.6 Чтобы установить поле даты истече н и я срока, можно исп ол ьзовать команду usermod (даты здесь должны быть в формате гггг-мм-дд). Девятое поле зарезервировано на будущее. 7

Теперь, когда назначение полей понятно, вернемся к расс мотренному выше примеру. mi l l e r t : $ 6 $ i T E FbMTM$ CXmx PwErbEe f 9 RUBv f l z v 8 EgXQda Z g 2 e Od5 uXyvt 4 s F z i 6G 4 1 I qavL i l T QgniAHm3 C zw / L o a G z o F z aМm . Yw01 / : 1 7 3 3 6 : 0 : 1 8 0 : 1 4 : : :

5 При этом вы можете преобразовать секунды в дни с помощью команды expr ‘ date+’iss ‘ / 8 6 4 0 0 . 6 Седьмое поле в к н иге не оп исано. — Примеч. ред. 7 Возможно, это поле н икогда не будет использовано.

Часть 1 . Основы администрирования

282

В этой записи говорится о том , что пол ьзователь mi l l e r t последни й раз м енял свой парол ь 19 и юн я 20 1 7 года . Следую щ и й раз парол ь должен быть изменен через 1 80 дне й . З а две н едели до этого пол ьзовател ь нач н ет получать предупреждения о необходимости с м е н ить парол ь. Учетная зап ись не и меет срока действия. С помощью утил иты p w c o nv можно согласовать содерж и м ое файлов s h adow и passwd, выя вл я я и удал я я п ол ьзо вателей не указанных в файле pas swd. ,

8.4. ФАйлы /Етс /МАS ТЕR . PAS SWD и /Етс/ LOGIN . CONF в СИСТЕМЕ FREEBSD П оявление модулей РАМ и наличие аналогичных команд управления пол ь­ зователя м и в систе мах F ree B S D и Linux сделал и управление учетн ы м и за­ п исями относител ьно согласованным между платформам и , по крайней мере на самом верхне м уро1ше. Однако между ними существуют некоторые раз­ личия на уровне реал и зации.

Ф айл /etc/mas ter . pas swd В систе м е Free B S D » реал ьн ы м » файлом паролей я вляется /etc/ma s ter . pas swd, которы й доступе н тол ько для чте н ия . Файл /etc/pas swd предназначен для обратной совместимости и не содержит паролей (вместо этого он содержит с и м вол ы * в качестве заполни тел е й ) . Чтобы измен ить файл паролей, выполн ите команду vipw. Эта команда вызы вает ваш редактор для копии /etc/шaster . pas swd, затем и нсталл ирует новую версию и повтор­ но генерирует файл /e tc/pas swd, чтобы отразить все изм е н е н и я . ( Команда vipw яв­ ляется стандартной для всех систе м U N IX и Linux, но особенно важно испол ьзовать ее в системе Free B S D , потому что файлы с двойн ы м паролем должны оставаться синхро­ н из ированн ы м и (см . раздел 8 . 6 ) . ) Кром е полей файла pas swd файл mas ter . pas swd содержит т р и допол н ител ьных поля . К сожал е н и ю , по умолчан и ю о н и зажаты между пол е м G I D и пол е м G EC OS , зада н н ы м и по умолчан и ю , поэто м у фор м ат ы ф а й л о в н а п р я м у ю н е совмест и м ы . Допол н ител ьн ые три поля п е р е ч и слен ы н иже : •

класс регистраци и ;

в р е м я изме н е н и я п а рол я ;

врем я ис те ч е н и я срока де йствия пароля.

Класс регистрации (есл и он указан) относится к записи в файле /etc/ login . conf. Этот класс оп редел я ет огра н ич е н и я потребления ресурсов и управляет множеством дру­ гих параметров (см . следующий раздел) . П ол е времени измене н и я пароля отражает возраст пароля. Он содержит время в секун ­ дах с момента U N IX, после которого пользователь будет вынужден изменить свой пароль. Вы можете оставить это поле п уст ы м указав, что парол ь будет действовать веч но. Врем я истечения срока действия учетной записи означает время и дату ( в секундах, как и для моме нта исте ч е н ия срока действия парол я ) , по прошестви и которого истекает срок действия учетной зап иси пол ьзователя. Пользователь не может войти в систе м у по­ сле этой даты , есл и поле не будет сброшено адм и н истратором. Если это поле оставлено пустым, учетная запись останется действител ьной. ,

Глава 8. Управление учетными записями пользователей

283

Файл / etc/ loqin . conf Файл / e tc / l o q i n . conf в с и сте м е Free BS D задает параметры учетной запи с и для пол ьзователе й и групп пол ьзователе й . Его формат состоит из п а р ключ-значение с двоеточием и булевых флагов. Когда пользователь входит в систему, поле входа в каталог /etc/master . passwd опре­ деляет, какую запись из файла / etc/ loqin . conf применять. Если в записи пользователя master . passwd не указан класс входа в систему, используется класс по умолчанию. Элемент loqin . conf может установить любое из следующих значений. •

Ограничения ресурсов ( м акси м ал ьн ы й разм ер процесса, макс и м ал ь н ы й размер файла, количество открытых файлов и т.д. ) . Сеансовые огран ичения (с какого моме нта и нас кол ько дол го разреш е н ы регистрационные имена).

Переменные окружения по умолчан ию.

Пути ПО умолчани ю ( РАТН , МАN РАТН и т.д . ) .

Расположение файла с сообщениями для всех пользователей.

Хост и контрол ь доступа на основе подсистем ы ТТУ.

Стандартная маска для команды umask.

Контроль учетных записей ( в основном заменяется модулем РАМ pam_pa s s wdqc ) .

Следующий пример демонстрирует переопределение нескольких значен и й по умолчан ию. О н предназначен для назначения с истемных администраторов . s y s adrni n : : ignorenologin : : requi r ehome @ : : ma x p r oc=unl imi t e d : : op e n f i l e s=unl imi t e d : : t c=de f a ul t :

Пользователи , имеющие класс регистрации s y s a dm i n , могут войти в с истему, даже если их имя указано в файле /var/run/noloqin и у н их может не быть рабочего домаш­ него каталога (этот параметр позволяет регистрацию , когда с истем а N FS не работает) . Пользователи класса s y s a dmin могут запускать л юбое количество процессов и открывать любое количество файлов.� Последняя строка записывает и нформацию в запись d e f a u l t . Хотя с истема Free B S D и меет разумные стандартн ы е значе н и я , м ожет возни кнуть необходимость обновить файл / etc/ loqin . conf, чтобы установить предупрежде ния об истечени и врем е н и ожидания или об истечении срока действия пароля . Например, чтобы установить время ожидания равн ы м 15 мин. и вьщавать предупреждения за сем ь дней до истечения срока действия паролей, необходимо добавить следующие эле менты в запись d e f a u l t : warnp a s sword= 7 d : : i d l e t ime= l 5m :

Есл и вы изменяете файл / etc/ l oqin . conf , вы также должн ы в ыпол н ить следую­ щую команду дл я ком пиляции ваших изменений в хешированную верс и ю файла, кото­ рую система фактически ис пол ьзует в повседневной работе: $ cap_lllkdЬ /etc/loqin . conf

8 n о- прежнему существуют технические огран ичения на общее кол ичество процессов и открытых файлов. которые может подцержи вать ядро, но искусственно установленных ограничени й нет.

Часть 1. Основы администрирования

284

8.5. ФАйЛ /Eтc /GROUP Файл /etc/group содержит имена U N IХ-групп и с писки членов каждой групп ы . Вот как выглядит фрагмент файла group и з с истемы Free B S D. whe e l : * : O : ro o t s y s : * : З : r oot , Ьi n ope r a t o r : * : 5 : r o o t Ь in : * : 7 : r oot f tp : * : 1 4 : dan s t a f f : * : 2 0 : da n , b e n , t r e n t nobody : * : 6 5 5 3 4 : l p d

Каждая строка представляет одну группу и содержит следующие четыре пол я : •

имя групп ы ;

заш ифрова н н ы й пароль или заполн итель;

идентификатор групп ы ;

список членов, разделенный запятыми (пробелов быть не должно) .

Как и в файле /etc/pas swd, поля разделяются двоеточиям и . Дл ина и м е н и групп ы не должна превышать 8 с и м волов и з соображен и й совместимости , хотя во многих с исте­ мах такого ограничения нет. Несмотря на возможность установить пароль групп ы , позволяющий л юбому пользо­ вателю присоединиться к группе, выпол н и в команду newgrp , она используется редко. П ароль можно установить с помощью команды gpas swd; а его заш ифрован ная форма в системе Linux сохраняется в файле /etc/gshadow. Имена груп п и их идентифи каторы должн ы быть одинаковыми на всех ком пьютерах, получающих совместн ый доступ к файлам через сетевую файловую систему. Этого труд­ но достичь в гетероген ной среде , поскол ьку в разных операционных системах испол ьзу­ ются разн ые идентификаторы дпя одних и тех же груп п . Есл и в файле / e tc/pas swd пол ьзовател ь объя влен членом оп редел е н ной групп ы по умолчан ию, а в файле /etc/group — нет, пол ьзователь все равно включается в груп­ пу. На этапе регистрации членство в группе проверяется по обоим файлам, но луч ш е все же согласовывать их содержимое. В н е которых старых системах огран ичивается кол ичество групп , к которым может принадпежать пользователь. В современ н ых ядрах систе м Linux и Fre e B S D ограниче н и й нет вообще. Для того чтобы избежать конфли ктов , связанных с иде нтифи катора м и стандартн ых групп , рекомендуем выбирать иде нтификаторы локал ьн ых гру п п , начи ная со знач е ­ н ия 1 000. Согласно тради ц и и U N IX новые пол ьзователи добавля ются в группу, название ко­ торой отражает их категори ю , например » students» или » fi nance » . Однако следует учи ­ тывать, что подобная традиция повышает вероятность доступа пол ьзователе й к файлам друг друга из-за неаккуратной установки прав. Чтобы этого избежать, рекомендуем создавать дпя каждого пользователя ун икал ьную группу с помощью утилит useradd и adduser (т.е. группу, имя которой совпадает с именем пользователя и содержит только дан ного пол ьзователя ) . Это соглашение намного проще выполнить, чем обеспечить согласование между идентификаторами пользователя и группы. Чтобы пользователи могл и обмениваться файлами с помощью группового механизма, со:щайте отдельные группы. Идея персональных групп состоит в том , чтобы не препятство-

Глава 8. Управление учетными записями пользователей

285

вать испол ьзован ию групп как таковых, а просто создать более ограничительную группу по умолчанию для каждого пользователя , чтобы файлы не бьmи предоставлены для совмест­ ного пользователя непреднамеренно. Можно также ограничить доступ к вновь созданным файлам и каталогам, установив маску umask по умолчан и ю вашего пользователя в файле запуска по умолчанию, например /etc/profile или /etc/bashrc (см. раздел 8.6).

m Дополнительную и нформацию о п рограмме sudo см . в разделе 3.2. Членство в группах также может служить маркером для других контекстов или при­ вилегий . Например, вместо того , чтобы вводить имя пользователя каждого систе м ного администратора в файл sudoers , вы можете н астроить программу sudo так, чтобы все члены групп ы » admiп» автоматически и мели привилегии sudo . В с истеме Liпux для создания , изменения и удаления груп п предусмотрены команды groupadd, groupmod и groupdel . Система Free B S D для выпол н е н ия всех этих фун кций испол ьзует команду pw. Чтобы добавить пользователя d a n в группу s t a f f , а затем проверить,

что измене н ие было правил ьно реализовано, необходимо выпол нить следу­ ющие команды: $ sudo pw groupmod s taff -m dan $ pw groupshow s taff s t a f f : * : 2 0 : da n , evi , g a r t h , t r e n t , b en

8.6. ПОДКЛЮЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ ВРУЧНУЮ: ОСНОВНЫЕ ДЕЙСТВИЯ Прежде чем создавать учетную запись для нового пользователя в крупной коммерче­ ской компании , правительствен ном учрежде н и и или учебном заведен и и , важно заста­ вить его подписать соглашен ие о правилах работы в с исте м е . ( Как? ! У вас нет такого соглашения? Немедле н но прочтите материал в разделе 3 1 .9 , чтобы узнать, для чего оно нужно и как е го составлять . ) У пользователей н е т веских прич и н подписывать такое соглашение, поэтому в и нте­ ресах адм и нистратора убедить их сделать это, чтобы и меть рычаги влияния. П осле того как учетная зап ись создана, добиться подписи будет трудно, так что лучше получ ить ее заранее. Если существует такая возможность, прежде чем создавать учетную запись, по­ лучите подпись пользователя на бумажном докуме нте. Процесс подкл ючения нового пол ьзователя состоит из ряда этапов, определяемых систе м н ы м и требова н и я м и ; два с вязан ы с фор мирова н и е м пол ьзовательской сред ы , а еще нескол ько этапов может понадобиться для целей с истемного администрирования. •

Обязательные этапы : •

• •

отредактировать файлы pas s wd и shadow (или файл mas ter . pas swd в с исте­ ме FreeB S D ) , чтобы создать учетную запись пользователя ; добавить зап ись нового пользователя в файл /etc/group (в действительности это не необходимо, а желательно) ; задать первоначал ьн ы й пароль; создать для нового пол ьзователя домаш н и й каталог, н азначив его владельца с помощью команды chown и задав режим доступа с помощью команды chmod; настроить роли и права доступа (есл и вы используете RBAC ; с м . чуть н иже ) .

часть 1. Основы администриравания

286 •

П ользовательские этапы: •

скопировать в домаш н и й каталог пользователя стандартные конфигурацион ­ ные сценарии .

Административные эта пы : • • •

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

Для выпол н е н и я этого с п иска действий необходимо иметь сценарий ил и утил иту, и во всех наших иллюстративных с истемах они предусмотрен ы в виде команд adduser и useradd.

Реда кти рован ие фа йлов pas swd и qroup Ручное редактирова н ие файлов pas swd и group уязвимо для ош ибок и неэффек­ тивно, поэтому м ы рекомендуе м и н струменты высокого уровня , такие как useradd, adduser, usermod, pw и chsh. Есл и вам пр идется добавлять пол ьзователя вруч ную, испол ьзуйте команду vipw, чтобы отредактировать файл ы pas swd и shadow ( в системе Free B S D файл mas ter . passwd). По умолчанию выбирается редактор vi , но эту установку можно изменить, за­ дав новое значение переменной среды E D I TOR.9 Более важно то, что команда vipw бло­ кирует редактируе м ы й файл , позволяя только одному пользовател ю редактировать его. Это не допускает н и каких конфл иктов между действия м и разн ых пользователе й . —

В с истемах Linux после редактирования файла pas swd команда vipw авто­ матически напомн ит пользователю о необходимости отредактировать файл shadow. Для этого используется команда vipw -s . В систе м е FreeBS О команда vipw редактирует файл mas ter . pas swd, а не /etc/pas swd. П осле внесения измене н и й команда vipw запускает в ыпол­ н е н ие команды pwd mkdЬ для ге нерирования производного файла pas swd _ и двух хеш и рова н н ы х верс и й mas ter . pas swd (одна из них содержит за­ ш ифрова н н ы е парол и , доступные для чте н и я тол ько пользователю r o o t , а вторая не содержит паролей и доступна дл я чтения л юбому пользователю). Например, выпол н е н и е команды vipw и добавл е н и е следующей строки приведет к определен и ю учетной записи с именем whi t n e y . wh i t n e y : * : l O O З : l O O З : : O : O : Wh i t n e y S a t h e r , АМА Т Н 3 — 2 7 , х 7 9 1 9 , : / h ome / s t a f f / wh i tn e y : /b i n / s h

Обратите внимание н а звездочку в поле зашифрованного пароля. О н а предотвращает использование учетной записи, пока не будет установлен настоя щий пароль с помощью команды passwd (см. следующий раздел) . Затем отредактируйте / e t c / g roup , выпол н и в команду v i g r . Добавьте строку для новой персонал ьной груп п ы , есл и ваша орган изация использует их, и добавьте имя пользователя для каждой груп п ы , в которой пользователь должен иметь членство. » Если сначала выполн ить команду vipw ( или vigr ) , систем ы Ubuntu и Deblan п редложат вам выбрать одну из команд vim . basic, vim . tiny, nano или ed. Если впоследствии вы передумаете, выполните команду select-editor.

Глава 8. Управление учетными записями пользователей

287

Как и в случае с командой vipw, использование команды vigr гарантирует, что из­ менения, внесе н н ы е в файл /etc/group, я вляются коррект н ы м и и атомар н ы м и . После сеанса редактирования команда vigr должна попросить вас выпол н ить ко манду vigr — s дл я редактирования файла теневой групп ы (gshadow) . Если вы не хотите устанавливать пароль для групп ы , что необычно, вы можете пропустить этот шаг. Чтобы внести изм е н е н ия в файл /etc/group, в с истеме Free B S D ис пользу­ ется команда pw groupmod.

Задан ие па роля W Правила выбора удачных паролей при ведены в разделе 27.З. Установите пароль для нового пользователя с помощью следующей кома нды. $ sudo passwd но в о е — имя — поль з о в а теля

В некоторых автоматизированн ых систе мах п р и добавл е н и и н о в ы х пол ьзователе й необязательно вводить н ачал ь н ы й пароль. Задание пароля в таких случаях происходит при первой регистраци и . Несмотря на удобство, этот вариант приводит к образовани ю огромной дыры в системе безопасности ; тот, кто может угадать новые регистрацио н н ы е и м е н а ( ил и узн ать и х в файле /etc/passwd) , может в ы пол н ить » пи ратс к и е » действия по отнош е н и ю к учетным записям , прежде чем соответствующие пол ьзователи получат возможность заре гистрироваться . Помимо других функций команда pw в системе Free B S D ге нерирует и уста­ навл ивает случай н ы е парол и пол ьзователей. $ sudo p w usermod raphael -w random P a s sword f o r ‘ r a p h ae l ‘ i s : l n З t c Yu l s

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

Созда ние домаш него каталога пользовател я и инсталляция конфигура ционных фа йл о в Новые домаш н ие каталоги пол ьзователей создаются с помощью команд u s e radd и adduser, но вы вряд ли захотите выпол н ять двойную п роверку прав доступа и файлов запуска для новых учетных записей. Домаш н и й каталог создать легко. Если вы забыли это сделать п р и создани и учетной записи нового пол ьзователя , исправить положен и е можно с помощью простой команды mkdir. Вам также понадобится установить права владен ия н а новый каталог и права до­ ступа к нему, но луч ше все го сделать это после инсталляции локальных конфигурацион ­ ных файлов. Имена таких файлов традиционно начинаются с точ ки и зака н ч иваются суфф и ксом rc (сокраще н и е от «run command » команда запуска) — «от голосок» операционн о й систем ы CTS S. Предшествующая точка заставляет команду l в не в ключать э т и файлы в листинги каталогов, есл и только не указана опция — а . М ы рекомендуем предоставлять стандартные файлы запуска для всех и нтерпретаторов команд, которые популярны в ва­ ших с истем ах , чтобы пол ьзовател и по умол ч а н и ю п родол жал и работать в корректной среде даже при смене командной оболочки. Наиболее часто встречающиеся конфигура­ цион н ы е файлы перечислен ы в табл . 8 . 2 . —

Часть 1. Основы администрирования

288

Таблица 8 . 2 . Распространенные конфигурационные файлы Команда

И мя фама

Применение

loqin_сом

Все оболочки

sh

. profile

Установка пути поиска, типа терминала и среды

Ьаsь•

. bashrc

Установка типа терминала (если это необходимо)

. bash_profile

Установка опций программ Ьiff и me sq Установка переменных окружения Установка псевдонимов команд Установка пути поиска Установка атрибута umask для управления правами дос�упа Установка переменной C D PATH для поиска имен файлов Установка переменных Р s 1 (строка приглашения ) и HI s TCONT ROL

. loqin

Считывается всеми зарегистрированными экземплярами интерпретатора csh

csh/ tcsh

. cshrc …. . . .

..

.

.

.

. . . ……. . . .

. » . . .. . » …. —

Настройки параметров регистрации пользователя по умолчанию ( FreeBSD)

Считывается всеми экземплярами интерпретатора csh

. .. » . .. . .. .. . . . .. . . . …

. . . . . . » » .. . » ..

..

«

..

. .

.

. . ..

.

. .

.

.

.

.

. ..

.

.

.

vi/vim

. ею:с/ . vimrc

ешасs

qit

. qitcomiq

Установка параметров пользователя, редактора, цвета и псевдонимов в си­ стеме Git

. qcom

Среда GNOME: конфигурация среды пользователя посредством команды qconf

. qconfpa th

Путь для дополнительного варианта конфигурации среды пользователя по­ средством команды qconf

. . » . . .. .

…. » . . . .

. . . . . . .. . .

КDЕ .

……….. » …. -…..

ешасs

Устано вка опций редакторов vi/viш

. ………… » . . . . » . . . . » ……•.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . • . . . . — . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . » . . . . . . . . . . .

Установка опций редактора ешасs и функциональная привязка его клавиш

. . . . . . . . . . . . . . . » . . . » . . . . » . » . . . . » . » . . . . » . . . . . .. » . . . . » . . . . . » . . . . . . » » . » . . » . . . . . » . . . . . . » . . . » » . . . . . . » . . . . . » . . . . . . . . . . . . . . . . » » . . . » . » . » » . . . . . . » . . . . . » » . . » . . . » . . . . . . . » . . . . . . » » . . . . » » » . . . . » . . . . . . . » . » . . » . . . . . . . . » . . . . . . . . . . . • . . . . » . . .

. . . .. . . . . . . . . . . . . . . . . . . . . .. » . . . » . . . » » » . . » . » . . . … . . . . . . . » » . …. . «.» . . .. . » … . .. » » . . . . . . . . . . .. » . » . » . . . . . . . . . . » » . . » » . . » . . . » . » . » •

kde /

» . » ..

.. . . . » . . . » » .

. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .

«

Среда KDE: каталог файлов конфигурации

» Оболочка bash также читает файлы . profile или / e tc /prof i l e в режиме эмуляции s h . Файл . ba s h_ profile считывается командами регистрации, а файл . bashrc считывается с помощью интерактивных оболочек без регистрации.

Образцы файлов запус ка традиционно хранятся в каталоге /etc / ske l . Если вы бу­ дете редактировать примеры конфигурацион н ы х файлов, каталог / u s r / l o ca l / e tc / skel самое удач ное место для хранения модифицированных копи й . Конфигурационн ые файлы и каталоги , перечисленные для настол ьн ых сред G N OM E и K D E , представляют собой л и ш ь вершину айсберга. В частности. обратите в н и мание на уrилиту gconf, предназначен ную для хранения предпочтений в выборе приложе ний для программ под управлением G N O M E ( подобно тому, как это реализовано в систем­ ном реестре Wi ndows). —

W Дополнительную и нформацию об атрибуте uшask см. в разделе 5.5. Н е забудьте задать разум ное значение umask (рекомендуем 077, 027 ил и 022, в зави­ си мости от «дружел юбности» среды и размеров организаци и ) . Если вы не испол ьзуете индивидуальные группы, рекоме ндуем установить дл я umask значение 077, поскол ьку оно предоставляет владельцу пол н ы й доступ, а для групп ы и вообще для всех остал ь­ ных — н и какого доступа. В зависимости от и нтерпретатора , в каталоге / e tc могут содержаться систе м н ы е конфи гурацион н ы е файл ы , обрабаты вае м ы е р а н ь ш е пол ьзовател ьс ких. Н а п р и м е р , и нтерпретаторы b a s h и s h читают файл / etc/pro f i l e д о начала обработки файла

Глава 8. Управление учетными записями пользователей

289

/ . profile и / . bash_p rofile. В эти файлы стоит помещать стандартные установки , необходимые дл я функционирования вашего хоста, но следует иметь в виду, что пользо­ ватели могут переопределять свои установки в собственных конфигурацион н ы х файлах. И нформацию о других и нтерпретаторах можно найти в документац и и (см . соответству­ ющие mаn-страницы). �

По соглашению, систе м а Linux сохраняет фрагме нты загрузочн ы х файлов в каталоге / etc /pro f i l e . d. Хотя имя каталога происходит из соглаше­ ний, принятых для оболочки sh, файл /etc/profi le . d может фактически в ключать фрагменты для нескол ьких разных оболоче к . Кон кретн ые цел е ­ вые оболочки различаются суффикса м и имен файлов ( * . sh, * . c s h и т.д . ) . В оболочке не встроена поддержка файла pro f i le . d; фрагменты просто исполняются сценарием запуска по умолчан и ю в каталоге /etc ( например, /etc/profile в случае оболочки sh или bash) . Разделе н ие файлов запуска, зада н н ых по умолчанию, н а фрагме нты обл е гчает мо­ дульность и позволяет программ н ы м пакетам включать собствен н ы е значения по умол ­ чанию на уровне оболочки . Например, фрагменты colorl s . * указывают, как правиль­ но раскрасить вы вод команды ls, чтобы сделать его нечитаем ы м на темном фоне .

Уста новка прав доступа и владения После установки домашнего каталога переходите к пользователю и убедитесь, что о н и меет соответствующие права доступа. Команда $ sudo chown

R новый_ поль зова тель : но в а я_ гр уппа -новый_ поль з о в а т ель

должна надлежащим образом установить права владе н и я . Обратите в нимание на невоз­ можность использования команды $ sudo chown -R новый_ пользова тель : н о в а я_ группа -новый_поль з о в а т ель / . *

примен ител ьно к файлам , и м е н а которых нач и наются с точк и , поскол ьку н о вый_ поль з ов а тель станет владельцем не только собствен н ы х файлов, но и родительского каталога » . . » ( например, / home ) . Это распростран е нная и опасная о шибка.

Конфигурирова ние ролей и административных п ривилегий Управление доступом на основе ролей (role-based access control — RBAC) позвол я ­ е т «подогнать» систе м н ые права к отдел ьным пол ьзователя м и обеспечивается н а м но­ гих наших примерах с исте м . П олитика R BAC не я вляется тради цион ной частью моде­ л и управления доступом U N IX или Linux, но если на вашем хосте она испол ьзуется , то конфигурация ролей должна быть ч астью процесса добавления пользовател е й . М одель RBAC подробно описана в разделе 3 .4.

W Подробнее о законах SOX и

G LBA написано в главе 3 1 .

Принятые в С ША закон Сарбей нса-Оксли (Sarbanes-Oxley Act), закон о преемствен­ ности страхования и отчетности в области здравоохранения ( H ealth I nsurance Portabllity and Accountabllity Act — Н I РАА) и закон Грэм ма-Лича- Блайли ( G ramm — Leach- 8iey Act} , предназначенные, в частности, для защиты информации заказчика, полученной или используемой финансовым и организациям и С ША, от кражи, неавторизованного доступа либо злоупотребления , усложнили многие аспекты системного администрирования в кор­ поративной сфере , включая управление пользователями. Поэтому использование ролей

Часть 1. Основы администрирования

2 90

может быть вашим единственным жизнеспособным вариантом, позволяющим выполнить некоторые требования , устанавливаемые законами SOX, Н I РАА и G L BA.

З а кл юч ительные действия Дл я того чтобы удостовериться , что новая учетная запись сконфигурирована надл е ­ жа щим образом , завершите сеанс работы (т. е . вы йдите из систе м ы } , а зате м снова во­ йдите в систему под именем нового пользователя и выполните следующие команды . $ pwd $ ls -la

# Для п р о в ерки до м а ш не г о к а т а л о г а # Для п р о в е р ки в л аде л ь ц а / г ру пп ы фа й л ов ко н фи г ура ц ии

Вам необход и мо уведо м ить новых пользователе й об их ре гистрацион н ы х и менах и начал ьн ы х паролях. М ногие хосты отправл я ют эту информа ц и ю по эле ктронно й почте , но из соображе н и й безопас ности это не приветствуется . Делайте это при лич­ ном контакте ил и по тел ефону. Н о есл и вам приходится добавлять сразу 500 новичков на ун иверс итетские ком п ьютеры CS- 1 , переложите эту задачу на преподавателей! Есл и вам п риходится распростран ять п арол и через электрон н ую почту, п роследите за тем , чтобы срок и х действия истекал через несколько дне й , если они н е испол ьзуются и не были изменены.

W П одробнее о закл ючении п исьменных контрактов с пользовател я м и м ожно прочитать в разделе 31 . 9 .

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

8.7. Д ОБАВЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ С ПОМОЩЬЮ СЦЕНАРИЕВ: USERADD, ADDUSER И NEWUSERS Во всех иллюстративных системах сценарии useradd и adduser реализуют одну и ту же базовую процедуру, описанную выше. Но ее можно сконфигурировать под конкретную среду. К сожалению, в каждой системе существуют свои представления о том, что именно «‘ П оскол ь ку оди н и тот же п арол ь может и меть множество заш ифрованных предста м е н и й , эт от п роверяет тол ь ко сам факт изменения пол ьзователем свое го пароля , а не то , что пароль ре ал ьно был за м енен други м паролем. м е т од

глава 8. Управление учетными записями пользователей

291

следует настраивать, где следует реализовать настрой ки и каково должно быть стандарт­ ное поведение, поэтому мы описываем эти подробности в соответствующих разделах. В табл . 8 . 3 п р иведен ы команды и файл ы кон ф и гураци и , и м е ю щ и е отн о ше н и е к управлению пользователя м и . Таблица 8 . 3 . Команды и файлы конфиrурации дл я управления пользователями Система

Команды

Конфигурационные файлы

Все версии Linux

/etc/login . defs /etc/default/useradd

DeЬian/Ubuntu•

useradd , usermod , userdel adduser , deluser

FreeBSD

adduser , rmuser

/etc/adduser . conf /etc/deluser . conf /etc/login . defs

• в этот набор входят не только стандартные функции Unux, но и некоторые дополнительные функции.

Команда useradd в системе Linux В системе Linux предус мотрен сценарий useradd , извлекающий параметры конфигурации из файлов /etc/login . defs и /etc/default/useradd. Файл login . defs предн азначен для реше ния таких пробл е м , как старение парол я , выбор алгоритмов ш ифрования, расположен ие файлов почтовых каталогов и предпо­ чтительные диапазо н ы U I D и G I D. Редактирование файла login . def s выполняется вручную. П олезн ы м средством для понимания параметров я вляются комментарии. Параметр ы , хранящиеся в файле /etc/default/useradd, задают расположение до­ маш них каталогов и оболоч ку по ум олчанию для новых пользователе й . Эти значения устанавли ваются по умол ч а н и ю с помощью команды u s e radd. Например, команда useradd -D выводит на э кран текущие значен и я , а параметр -D в сочетан и и с другим и флагами задает значения определенн ы х опций . Например, команда $ sudo useradd -D -s /bin/bash

устанавливает bash как оболочку по умолчанию. Тип ич н ы м и опция м и по умолчан и ю я вля ются размещение новых п ол ьзователе й в отдельных группах, использование алгоритма ш ифрования S HA-5 1 2 для паролей и за­ полнение домаш н их каталогов новых пользователе й загрузочн ы м и файлами из каталога /etc/ ske l . Основная форма команды useradd принимает имя новой учетной зап иси в команд­ ной строке: $ sudo useradd hilЬert

Эта команда создает в файле / e t c / p a s swd запись, подобную показа н н о й н иже , а также соответствующую запись в файле shadow: h i l b e r t : x : 1 0 0 5 : 2 0 : : /home / h i l be rt : / b i n / s h

По умолчанию команда useradd блокирует новую учетную запись. Дл я фактическо­ го использования учетной записи необходимо назнач ить реальный пароль. Более реалистичный пример показан н иже. Мы указываем , что первичная группа поль­ зователя h i l be r t должна иметь имя «hilbert» и что он также должен быть добавлен в группу «faculty». М ы переопределяем местоположение и оболочку основного каталога по умолча­ нию и попросим команду useradd создать домашний каталог, если он еще не существует: $ sudo useradd -с «David HilЬert» -d/home/math/hilbert -g hilЬert — G faculty -m — s /bin/ tcsh hilbert

Часть 1. основы администрирования

292

Эта команда создает следующую запись в файле pas swd: h i l b e r t : x : l O O S : З O : Da v i d H i lb e r t : / h ome /ma t h / h i l b e r t : / b i n / t c s h

Назначен н ы й иде нтифи катор U I D превышает наивыс ш и й U I D , существующий в системе, а соответствующая запись в файле shadow имеет вид: hilbert : : 1 4 3 2 2 : 0 : 9 9 9 9 9 : 7 : 0 : :

Сим вол (символ ы) заполнения парол я в файлах passwd и shadow различаются в за­ висимости от операционной систем ы . Команда useradd также добамяет пол ьзователя h i l b e r t в соответствующие группы в файле /etc/group, создает каталог /home/math/ hilbert с надлежащими владел ьцами и запол няет его файлами из каталога /etc/ skel.

Команда adduser в системах Deblan и Ubuntu В допол нение к семейству команд uвeradd, линия Deblan также предостав­ ляет нескол ько сценариев более высокого уровня дл я этих команд в виде adduвer и deluвer. Эти дополн ител ьн ые команды настраиваются в файле /etc/adduвer . conf, где можно указать такие параметр ы : •

правила размещения дом а ш н и х каталогов: п о груп пам , по и м е н и пол ьзовател я и т.д. ;

настройки разрешения для новых домашних каталогов;

диапазоны U I D и G I D для системных и общих пользователе й ;

возможность создания отдел ьных групп для каждого пользователя ;

квоты диска (тол ько булевские, к сожалению);

сопостамение имен пользователей и групп с помощью регулярных выражений.

Другие т и п и ч н ы е параметры команды u s eradd , такие как правила для парол е й , устанами ваются к а к параметры модуля РАМ , которы й выпол няет обычную аутенти­ фикацию пароля. ( П одкл ючаем ые модул и аутентификации РАМ обсуждаются в разделе 1 7. 3 . ) У команд adduser и deluser есть аналоги для груп п : addgroup и delgroup.

Команда adduser в системе FreeBSD Система FreeBS D поставляется со сценариями оболочки adduser и rmuser, которые можно испол ьзовать в готовом в иде ил и модифицировать в соот­ ветстви и с ваш и м и потребностя ми. Сценарии построены на ос нове средств. предоставленных командой pw. При желан ии команду adduвer можно испол ьзовать интеракти вно. По умолчанию она создает записи пол ьзователе й и груп п и домаш н и й каталог. Можно указать сцена­ рию файл после флага -f, содержащий сп исок учетн ых записей для создания, ил и вве­ сти каждого пользователя в интеракти вном режиме. Например, процесс создания нового пользователя r a ph a e l выглядит так. $ sudo adduser U s e r n ame : raphael Ful l name : Raphael DoЬЬins U i d ( Le ave emp t y f o r d e f a u l t ) : L o g i n g r oup [ r aph a e l ] :

Глава 8. Управление учетными записями пользователей

293

Login g r oup i s raphae l . I nv i t e raph a e l i n t o o t h e r g r o up s ? ( ] : Login c l a s s ( de f a u l t ] : Shell ( s h csh t c s h b a s h rbash n o l o g i n ) ( s h ] : Ьавh Home di r e c t o r y ( /h ome / r ap h a e l ] : < r e t u r n > Home d i r e c t o r y p e rrni s s i on s ( Leave ernp t y f o r d e f a u l t ) : < r e t u r n > U s e p a s s wo rd — b a s e d a u t h e n t i c a t i o n ? ( ye s ] : < r e t u rn > U s e an ernp t y p a s s w o r d ? ( ye s / n o ) ( n o ] : < re t urn> Use а r a n d orn p a s s w o r d ? ( ye s /n o ) ( n o ] : уев Lock out t h e a c count a f t e r c r e a t i o n ? ( no ] : < re t urn> r apha e l U s e rnarne < r andorn> Password Raph a e l Dobb i n s Fu l l Name 1004 Uid Class r apha e l Gr oup s / home / r ap h a e l Home Ноте Mode / u s r / l oc a l / b i n / b a s h Shell no Locked ОК ? ( ye s / n o ) уев addus e r : I N FO : S u c c e s s f u l l y added ( rapha e l ) t o the u s e r d a t a b a s e . addus e r : I NFO : P a s s w o r d f o r ( raphae l ) i s : RSCAd s 5 f yOvxOt Add anothe r u s e r ? ( y e s / no ) : no Goodb ye !

Кома нда newusers в системе Li nux: добавление пол ьзователей пакетом При выполнении Linuх-команды newusers одновременно создается несколь­ ко учетн ых записей из содержимого подготовленного текстового файла. Это не вполне формал ь н ы й способ, но им удобно пользоваться в случае , есл и нужно добавить м ного пол ьзователей сразу, например при создании учетн ых зап исей для учебной групп ы. Команда newusers в качестве аргумента полу­ чает входной файл, состоя щий из строк, подобно файлу /etc/passwd, за ис­ ключением того, что его поле пароля содержит начал ьн ы й пароль, заданный открытым текстом. П оэтому хорошо подумайте о защите такого файла. Команда newu s e r s прин и мает связан ные со сроком де йствия пароля параметр ы , установленные в файле /etc/ login . defs , но не коп ирует стандартн ые конфигураци­ он ные файл ы , как это делает команда useradd. Еди нстве н н ы й файл , которы й предо­ ставляется в этом случае , — файл . xauth. В университетских системах действител ьно важно применять » пакетн ы й » сценарий adduser, который испол ьзует с писок студентов из дан ных регистраци и для генерирова­ ния входной и нформации для команды newuser s . Для этого необходимо и меть имена пользователе й , подготовленные в соответств и и с локал ь н ы м и правилам и при гаранти и их ун и кал ьности (на локал ьном уровне ) , а также метод случайного ген ерирования па­ ролей при увел и ч и вающихся значениях идентифи каторов пол ьзователе й и групповых идентификаторов для каждого студе нта. Возможно, вам луч ш е нап исать собстве нн ую оболочку для команды useradd на языке Python, чем п ытаться приспособить свои нужды к тому, что предлагает команда newusers.

Часть 1. Основы администрирования

294

8.8. Б ЕЗОПАСНОЕ УДАЛЕНИЕ УЧЕТНЫХ ЗАПИСЕЙ ПОЛЬЗОВАТЕЛЕЙ И ФАЙЛОВ Когда пользователь покидает орган изацию, его учетная запись и файлы должны быть удале н ы из систе м ы . Эта процедура включает удаление всех ссьmок на регистрацион ное имя, которые были введе н ы вручную ил и с помощью команд useradd и rm.user. При руч ном удалении учетной записи последовательность операций будет примерно такой: • •

удал ить записи пользователя из локальн ых баз дан н ых и телефонных списков; удал ить пол ьзовател ьские почтовые псевдон и м ы из файла л ибо организовать пе­ ренаправление поступающих ему сообщен и й ; удал ить пол ьзовател ьс кие задания из файла crontab , из очереди команды a t , а также из заданий на печать; уничтожить пользовател ьские процессы , которые е ще вы полняютс я ;

удалить записи пользователя из файлов pas swd, shadow, group и gshadow;

удалить домаш ний каталог пользователя ;

• •

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

П еред тем как удалять домаш н и й каталог пол ьзователя , необходимо переместить из него в другие каталоги все файл ы , которые нужны остальным пользователя м . Поскольку не всегда можно с уверенностью с казать, какие файлы понадобятся , .а какие — нет, лучше предварител ьно скопировать пол ьзовател ьские дома ш н и й и почтовый каталоги на какой-то носител ь. После удаления учетной записи пользователя убедитесь, что в системе не осталось фай­ лов с его идентификатором. Чтобы узнать точный путь к этим файлам , воспользуйтесь ко­ мандой find с аргументом -nouser. Поскольку команда find может вести поиск на сете­ вых серверах, проверяйте файловые системы по отдельности, задавая опцию -xdev. $ sudo find filesys tem

xdev

nouser

Есл и в орган и зации за пол ьзователя м и закре плен ы отдел ьные рабоч ие ста н ц и и , эффективнее всего переинсталлировать систе му, п режде ч е м предоставлять ее новому пол ьзовател ю. Но не забудьте сбросить на с исте м н ы й жесткий диск локал ьные файл ы , которые могут понадобиться в будущем. 1 1 Каждая система из наших примеров имеет команды , с помощью которых она авто­ матизирует процесс удаления пользователя . Если эти команды не отвечают ваш и м высо­ ким требования м , можете допол н ить их функциональные возможности предоставлени­ ем расширенного списка мест хранения данных о пол ьзователях. В с истемах Deblan и Ubuntu команда deluser представляет собой сцена­ рий на языке Perl , который вызывает обычную команду userde l , аннул ируя все результаты работы команды adduser. П ри этом вызы вается сценарий user/local / sЬin/deluser . local , если таковой существует, чтобы реа­ л и зовать несложную операцию локализации. Файл конфигурации / e tc/ deluser . conf позволяет установить следующие опции: 11 Помните о лицензион ных кл ючах!

Глава в. Управление учетными записями пользователей •

удалять л и домаш н и й и почтовый каталоги пол ьзователя ;

резервировать л и файлы пользователя и куда поместить резервные копии ;

удалять ли все файл ы . которым и владел пользовател ь;

удалять ли группу, есл и в дан н ы й момент она не имеет членов.

RHEL . •

295

В систем е Red Hat п редусмотре н сценарий userdel . loca l , но не предус­ мотрен ы префиксные и постфиксные сценар и и для автоматизации опера­ ций по резервированию файлов пользователя , подлежащего удал е н и ю . Сценарий rmsuser в с истеме Free B S D представляет собой превосход н ы й и нструмент для удале н ия файлов и процессов пользователей. С н и м не мо­ гут сравн иться н и какие программ ы userdel других поставщиков.

8.9. БЛОКИРОВАНИЕ РЕГИСТРАЦИОННЫХ ИМЕН ПОЛЬЗОВАТЕЛЕЙ И ногда возникает необходимость временно откл юч ить учетную запись пользователя . Проще всего сделать это, поставив звездочку ( * ) или какой-то другой символ в поле за­ шифрован ного пароля в файле /etc/ shadow или /etc/master . pas swd. Эта мера пре­ пятствует бол ь ш и нству типов доступа, управляем ых паролем , п оскол ьку деш ифровка больше не может привести к получению какого-либо приемлемого пароля .

Систе ма Free B S D позволяет блокировать учетны е зап и с и с помощью ко­ манды pw. Например , команда $ sudo pw lock пол ь зова тель

помещает строку * LOCKE D * в начало хешированного пароля , блокируя учет­ ную запись. Во всех дистрибути вах Linux, рассматри ваемых нами в качестве при меров. команды usermod -L поль зова тель и usermod -U поль з о в а тель позво­ ляют ле гко соответстве н но блокировать и разблокировать парол и . Флаг -L просто помещает сим вол » ! » перед заш ифрован н ы м паролем в файле /etc/ shadow, а флаг u удаляет его. —

К сожален и ю , модификация пароля пользователя п росто приводит к блокированию регистраци и . П р и этом пользовател ь не уведомляется о блокировке пароля и не полу•1а­ ет разъяс нен и й , почему его учетная запись бол ьше не работает. Ал ьтернативный способ блокировать регистрацион н ые имена состоит в замене интерп ретатора команд пол ьзо­ вателя программой , которая выдает сообщен ие, поясняющее , почему учетная запись от­ ключена, и содержащее инструкции по исправлению ситуаци и . Затем программа завер­ шается и вместе с ней заканчивается сеанс регистрации. Этот метод им еет как пре и мущества, так и недостатки. Те форм ы доступа, которые проверя ют парол и , но не обращают внимания на интерпретатор команд. н е будут забло­ кирован ы . М ногие демоны , предоставляющие доступ к системе без регистрации (напри­ мер, ftpd}, проверяют, упомянут л и и нтерпретатор пользователя в файле /etc/shells. Есл и он там не указан , вход в с исте му будет запрещен ( и м е н но это нам и требуется ) . К сожалению, этот метод нел ьзя назвать ун и версальн ы м . П оэтому, есл и дл я блокирова­ н ия учетных записей вы реш ите модифицировать интерпретатор команд, вам придется провести дополн ител ьные исследования с воей с исте м ы . Кроме того , пояс няющее сообщение нельзя увидеть, если пользователь пытается за­ регистрироваться в системе в окон ной среде или посредством эмулятора терминала, ко­ торый не позволяет увидеть сообщен и я после выхода из систе м ы.

296

Часть 1. Основы администрирования

8.1 о. УМЕНЬШЕНИЕ РИСКА с помощью МОДУЛЕЙ РАМ Подкл ючае м ы е модул и аутентифи кац и и ( PluggaЫe Authentication M odules — РАМ ) подробно описан ы в разделе 1 7 . 3 . В н их сосредоточено управление систе м н ы м и сред­ ствам и аутентификации посредством стандартн ых библ иотечных утил ит, чтобы такие програ м м ы , как login, sudo , pas swd и su, н е должны был и предоставлять собствен н ы й код аутентификаци и . М одул и РАМ умен ьшают риск, присущий отдельно взятым про­ грам м н ы м продуктам , позволяют администраторам устанавл ивать политики безопасно­ сти , действующие в рамках всего хоста сети , а также определяют простой способ добав­ ления в с исте му новых м етодов аутентификаци и . Добавление и удаление учетных записей пользователей не предусматри вает измене­ ние конфигурации модулей РАМ , но испол ьзуе мы е для этих целей инструме нты долж­ ны действовать по правилам РАМ и в соответстви и с требован и я м и РАМ . Кроме того, м ногие параметры конфигурации РАМ подобн ы тем , которые используются командами useradd или usermod. Есл и вы измен ите како й — н ибудь параметр ( как описано н иже в этой главе) , а команда useradd, казалось б ы , не обратит на это внимания, проверьте , не аннулировала л и системная конфигурация РАМ ваше новое значение.

8.1 1 . Ц ЕНТРАЛИЗАЦИЯ УПРАВЛЕНИЯ УЧЕТНЫМИ ЗАПИСЯМИ В средн их и крупн ых корпорациях всех типов (акаде м ических, частн ых и л и госу­ дарстве н н ых) важно испол ьзовать определ е н н ую форму це нтрализованного управления учетн ы м и зап исям и . Каждый пользователь должен и меть на хосте уникальное , удобное и безопас ное регистрацион ное и м я , идентификатор ( U I D) и парол ь. Администраторам нужна централ изованная система, которая бы н емедленно обеспечивала повсеместное распространение изменений (например, аннул ирование конкретной учетной записи). Такая централ и зация может быть достигнута разл и ч н ы м и способа м и , бол ьш и нство из которых (включая систему Active Directory компании M icrosoft) в той или и ной степе­ н и (от бесплатн ых инсталляций с открытым исходн ым кодом до дорогих комм ерческих с исте м ) ис пол ьзует упроще н н ы й протокол доступа к сете в ы м каталогам ( Lightwe ight Directory Access Protocol — L DAP).

П ротокол LDAP и служба Active Di rectory W Подробнее о п ротоколе LDAP и его реализациях рассказывается в разделе 1 7. 2 . П ротокол L DA P п редставляет собой обобще н н ы й репозитори й ( н аподобие базы дан н ых) , который может хра н ить дан н ы е , связан н ые с управл е н и е м пол ьзователя м и , а также другие т и п ы дан ны х . О н испол ьзует иерархич ескую модел ь » кл иент-сервер» , которая поддерживает несколько серверов и нескол ько одновременно работающих кли­ ентов. Одно из самых бол ьш их преимуществ LDAP как централизованного репозитория для учетных дан н ы х состоит в том , что он может обеспечить в с истемах уникальность идентификаторов U I D и G I D . Кроме того, он хорошо стыкуется с Wi ndows, хотя обрат­ ное утверждение справедли во л и ш ь в самой малой степен и . Служба Active Directory ком пании M icrosoft использует протокол ы L DAP и КеrЬегоs (сетевой протокол аутентификации ) и может управлять множеством типов дан н ых, вклю­ чая дан ные пользователей. Она ведет себя несколько «эгоистично» , навязывая «свою ли­ нию» при взаимодействии с U N IX- или Linuх-репозиториями LDAP. Если вам нужна еди­ ная система аутентификации для хоста, который включает Windоws-компьютеры , а также

Глава 8. Управление учетными записями пользователей

297

U N IX- и Linuх-системы , то, возможно, проще всего позволить службе Active Directory ис­ пользовать ваши U N IХ-базы данных LDAP в качестве вспомоrательных серверов. Подробнее вопросы и нтеграции систем U N IX и Linux со службам и L DAP, Kerberos и Active Directory см. в главе 1 7 .

Системы » еди ного входа » Систем ы с однократной идентификацией пользователе й (single sign-on SSO) уравно­ вешивают удобства пользователя с проблемами безопас ности. Их основная идея состоит в том, чтобы пользователь, один раз зарегистрировавшись (в ответ на соответствующее приглашение на веб-странице или в окне Wi ndows) , мог затем переходить, к примеру, из одного раздела в другой без повторной аутентификац и и . Инач е говоря, пользователь получает аутентификацион н ы й мандат (обычно в неявном виде , чтобы не требовалось больше никакого активного управления) , которы й затем можно использовать для доступа к другим ком пьютерам и приложен иям. Пользователь должен помнить только одну после­ довательность (а не м ного) , состоящую из регистрационного имени и п ароля. Эта схема позволяет усложнять мандаты (поскольку пользователю н е нужно помн ить о них и вообще и меть с н и м и дело) , которые теоретически повышают степень сложно­ сти . Однако влияние с компрометированной учетной записи в этом случае усили вается, поскольку одно регистрационное имя предоставл яет взломщику доступ сразу к несколь­ ким ком пьютерам и приложе н и я м . Систе м ы SSO переносят » арену действий » из на­ стольного ком пьютера (пока вы спокойно регистрировались) в зону особой уязвимости . Кроме того, узк и м м естом с исте м ы становится сервер аутентификации. Если он » упа­ дет» , вся работа организации остановится. Н есмотря на то что в основе с истем ы SSO лежит простая идея , она предполагает большую внутрен н юю сложность, пос кол ьку различные приложе н и я и ком п ьютеры , к которым пользователь хотел получить доступ, должны пони мать процесс аутентифи ­ кации и SSО-мандаты. Существует ряд систем SSO с открытым исходным кодом : —

• •

JOSSO, сервер SSO с открытым исходным кодом , написанн ы й на языке Java; служба CAS (Central Authent ication Service ) , созданная Й ельс к и м университетом (на языке Java) ;

продукт Snibboleth, система SSO с открытым кодо м , распространяемая по лицен­ зии Apache 2.

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

Системы управления учетн ыми да нн ы ми Управление учетн ы м и дан н ы м и (ident ity management) это последни й п ис к моды в области управления пол ьзователя м и . Если говорить проще, то этот тер м и н означает идентиф и кацию пользователей конкретной систе м ы , аутентифицирование и х лично­ стей и предоставление привилег и й н а основе этих аутентифицирован н ых л и чностей . Стандартизация этой деятельности проводится такими орган изациями , как World Wtde Web Consortium и The O pen G roup. Коммерческие систе м ы управлен и я учетны м и дан н ы м и сочетают несколько клю ­ чевых кон це п ц и й U N IX в в иде графичес кого и нтерфейса, » пр иправлен ного» тер м и —

Часть 1. основы администрирования

298

нам и из сферы маркети н га . Основ н ы м элеме нтом для всех этих систе м я вляется база дан ных, которая содержит и нформацию, связан ную с аутентифи кацие й и авторизацией пол ьзователе й , часто хран имую в формате LDAP. Управление реал изуется на базе таких поняти й , как груп п ы U N X, а огран иче н н ые админ истрати вные права усили ваются по­ средством таких утил ит, как sudo. Большинство таких систем было разработано с цел ью уре гул и рования требован и й , диктуемых с точки зрения возможности идентификаци и , использован ия контрольных записей и слеже ния за н и м и . Создано м ного ком мерческих систем в этой сфере, например: l dentity M anagement (Oracle), Sun ldentity Management Suite 1 2 , Courion, Avatier ldentity Management Suite (AI M S) и В М С l dent ity M anagement Suite. Оценивая с исте м ы управления учетны м и дан н ы м и , ищите следующие функции . •

Контроль: •

интерфейс, при испол ьзовании которого наем менеджеров может потребовать, чтобы учетн ые зап ис и предоставлялись в соответствии с рол ью; возможность согласования с базами данных кадров для автоматического уда­ ления доступ а для служа щих, которые уволены или сокращен ы .

Управление учетн ы м и записям и : • •

безо п ас н ы й веб- и н терфейс дл я управл е н и я , досту пного как изнутр и , так и снаружи организации;

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

Удобство использования: • •

возможность для пол ьзо вателей менять их пароли глобал ьно в одной операции; возможность разре ш ит ь пол ьзователя м изменять ( и восстанавл ивать) соб­ стве н н ые парол и при соблюдении правил выбора сил ьных паролей.

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

1 2 Теперь, коrда компания Oracle купила Sun, не ясно, выживет л и эта система как продукт после завершения процесса поглоще н и я .

глава

9

Обла чные вы числения

Облачные вычисления — это практика лизинга комп ьютерн ых ресурсов из пула об­ щей ем кости. Облачн ы е службы предоставл я ют пол ьзователя м ресурсы по их требова­ нию и получают за это установленную цену. Компан и и , испол ьзующие облако, быстрее выходят на рынок, де монстрируют большую гибкость и несут м е н ьш и е капитальн ые и эксплуатацион ные расходы , чем предприятия , управляющие традицион н ы м и центра­ ми обработки данных. Облако — это реал изация » ко ммунал ьн ы х вычислени й » , впервые задуманная уче­ н ы м — програм м истом Джоном Мак- Карти, которы й о п исал эту идею в одной беседе в Массачусетском технологическом и нституте в 1 96 1 году. М ногоч исл е н н ые техноло­ гичес кие достижен и я , появивш иеся за прошедшее вре м я , помогл и воплотить эту идею в жизн ь. П еречисл и м л и ш ь некоторые из них. •

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

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

Часть 1. Основы администрирования

300

В этой главе излагаются мотивы перехода в облако, описы ваются некоторые из ос ­ новных поставщи ков облачн ых вычисл е н и й , рассматриваются сам ые важные облач ные службы и предлагаются советы по контрол ю затрат. В качестве еще более краткого вве­ ден ия в разделе 9.4 показано, как создавать облачные серверы из командной строки. Управление облач н ы м и серверами упоми нается еще в нескольких разделах этой к н и ­ ги, которые пере ч ислен ы в таблице 9. 1 . Таблица 9 . 1 . Разделы , в которых рассматриваются темы , связанные с облачными вычислениями Раздел

2. 1 0 1 3. 1 5 1 9. З

Название и тема раздела или подраздела

Восстановление облачных систем (проблемы, связанные с загрузкой для облака) Облачные сети (сеть TCP/I P для облачных платформ) Веб-хостинг в облаке

24.6

Packer (использование

25.4

Контейнерная кластеризация и управление (особенно в разделе, посвященном AINS ECS)

26.4

Непрерывная интеграция и развертывание на практике (пример конвейера Cl/CD, использую­

28.7

Инструменты мониторинга коммерческих приложений ( инструменты мониторинга для облака)

инструмента Packer для создания изображений ОС для облака)

щего облачные службы )

Кроме того, облачные систем ы часто упоминаются в главе 2 3 .

9. 1 . ОБЛАКО В КОНТЕКСТЕ П ереход от серверов в ч астн ых центрах обработки дан н ых к современ ному вездесу­ щему облаку был быстр ы м и драмати ч н ы м . Давайте посмотрим на прич и н ы этого мас­ сового движения. Облачные провайдеры создают техн ически развитую и нфраструктуру, которую бол ь­ ш инство компани й не могут себе позвол ить по финансовым соображен и я м . О н и разме­ щают свои центры обработки дан н ых в районах с недорогой электроэнергией и много­ ч исл е н н ы м и сетевыми коммутаторам и . Они разрабатывают пользовател ьские серверные ш асс и , которые м акс и м изируют энергоэффе кти вность и м и н и м изируют сто и мость эксплуатации . Они используют спе циал ьно создан ную сетевую и нфраструктуру со спе­ циал ьн ы м аппарат н ы м и п рогра м м н ы м обеспече н и е м , точно настрое н н ы м на и х вну­ трен н ие сети . Они проводят и нте нсивную автоматизацию, чтобы обес печить б ыстрое рас ш ирение и уме н ьш ить вероятность человеческой ошибки. Благодаря всем эти м инженерны м усилиям (не говоря уже об экономии за счет мас­ штаба) стоимость распределенн ых вычисл ительных услуг для облач ного провайдера на­ м ного н иже , чем для типичной ком пан и и с н ебол ьш и м центром обработки дан н ых. Экономия затрат отражается как на цене облачн ых услуг, так и на прибьт и поставщиков. Н а этой аппаратной основе создан ы элементы управл е н и я , упрощающие и облегча­ ющие настрой ку инфраструктуры . Облачн ы е поставщики предлага ют как и нтерфейсы прикладного програ м мирован и я , так и инструменты , ориентирова н н ые на пользовате­ л я , которые контрол ируют предоставление и освобождение ресурсов. В резул ьтате весь ц и кл жизненного ц и кл а систе м ы ил и гру пп ы систе м , распредел е н н ых в в иртуал ьной сети , может быть автоматизирован. Эта концепция носит название » и нфраструктура как код» и резко контрастирует с процедурам и закупки и подготовки руч ного сервера про­ шлых времен .

Глава 9. Облачные вычисления

301

Гибкость — еще одн а важная движущая сила внедрения облаков. Поскольку облач­ ные систем ы могут предоставляться и освобождаться автоматически, л юбая ком пания, имебщая циклический с прос , может оптим изировать эксплуатационные расходы за счет добавления дополн ительных ресурсов в периоды максимального использования и уда­ ления допол нительной е мкости, когда она больше не нужна. Встроен н ы е функции ав­ томатического масштабирования , доступные на некоторых облачных платформах, упро­ щают этот процесс. Облачн ые провайдеры имеют глобальное присутствие на рынке. Приложив опреде­ ленные усилия по план ированию и проектировани ю , предприятия могут выйти на но­ вые рынки, предложив услуги в нескольких географических регионах. Кроме того , вы­ полнить авар и йное восстановление в облаке проще , чем в частных центрах обработки данных, поскольку резервн ые с истемы могут физически находиться в разн ых местах. W Дополнительную и нформацию о методике DevOps см . в разделе 3 1 . 1 .

Все эти характеристики хорошо сочетаются с методикой системного адми нистриро­ вания DevOps, делающей акцент на гибкости и повторяемости . В облаке вы больше не ограничены медленными процессами закупок или подготовки, и почти все можно авто­ матизировать. Тем не менее от вас требуется определ е н н ы й умстве н н ы й скачок, потом у что вы больше не контрол ируете свое собственное оборудование. Эту с итуац ию хорошо опи­ сывает одна промышленная м етафора: серверы следует рассматри вать как скот, а не как домашних животных. Домашнему животному дают и м я , его л юбят и лелеют. Когда до­ машнее животное болеет, его несут к ветеринару и лечат. Н апротив, крупн ы й рогатый скот — это товар, который пасется, продается и перемещается в бол ьших коли чествах. Заболевш и й крупн ы й рогатый скот пристреливают. Облач н ы й сервер — это всего л и ш ь один из членов стада , иначе пришлось бы игно­ рировать базовы й факт облачных вычислен и й : облачные системы являются эфемерны­ ми, и они могут выйти из строя в любое время. Планируйте эту ситуацию, и вы будете более успешны при работе с отказоустойчи вой инфраструктурой. Несмотря на все свои преимущества, облако не я вляется панацеей для быстрого сни­ жения затрат или повышения производительности. Н епростой пере нос существующе­ го корпоративного приложен и я из центра обработки данн ых в облач н ы й провайдер (по принципу » поднять и пере нести «) вряд ли будет успешным без тщательного планирова­ ния. Для облака нужн ы другие процессы эксплуатаци и , которые требуют обучения и те­ стирования. Кром е того, большинство корпоративных програм м предназначено для ста­ тических сред, но отдельные системы в облаке следует рассматривать как недол говечные и ненадежные. Система называется облачной, если она надежна даже перед л и цом не­ предвиден н ых событий .

9.2 . ВЫБОР ОБЛАЧНОЙ ПЛАТФОРМЫ На выбор поставщика облачных услуг влияет м ножество факторов. Вероятно, опре­ деленную роль будут играть стоимость, прошл ый опыт, совместимость с существующи­ ми технология м и , безопасность, требован ия соответствия и внутрен н яя пол итика. На процесс отбора также может повл иять репутация , размер провайдера, фун кции и, ко­ нечно же , маркетин г. К счастью, существует много облачных провайдеров. М ы решил и сосредоточиться только на трех основных провайдерах облачных услуг: Amazoп Web Services (AWS) , Google

Часть 1. Основы администрирования

302

Cloud Platfoпn (GCP) и DigitalOcean ( DO). В этом разделе мы упомянем несколько допол­ н ительн ых вариантов. Основные и гроки в этой области перечислены в табл. 9.2. Таблица 9 . 2 . Наиболее wироко испол ьзуемые облачные платформы Проваiдер

Отличительные черты

Amazoп We b Se rvi ce s … … O�POt.1� �1.�. Pa �t.1e. P:…� �’�!.PO e ..�.�.e.,[1pe.�.� e. ..�.�.�O.�a.L�.� · . �.ОJКе.т ..быть до . ро�О�: ��О)l(Н� я Dig i talOceaп Простая и надежная . Имеет удобный интерфейс прикладного программирования. .

Хороша для разработки

G oogle Cloud Platform Технически сложная и быстро совершенствующаяся . Делает акцент на производи . …. .. . …….. …… … » . …………….. ………………… !.е.�.��.О?.!.�.: .�.t.1е.е.!…��Р.О ��.� ..�.n._е.�!.Р …У��У.� П.О .П.е.Р.е.!:l��е.. .�.�.�.�.�.�..,!З..� ��.1� . …… … . .. . . .. . … … . … . IBM Softlayer Больше похожа на хостинг, чем на облачную платформу. Имеет глобальную част­

·················

.

.

..

..

.

·······-····

сеть

Micros oft Az ure Вторая по размеру, но далеко отстает от первой. Имеет историю отключений . . . …. …… ……… … …. . …. ………… …. . ……… … . …�О.�.t.1.0.’.»�0.�…�.З..��-�-�-�-а.е..т.��� t.1.З.��� ?.О �торо � ы м_� г�� ин ов M i cros oft . . . OpeпStack Модулярная DIY платформа с открытым исходным кодом для создания частных об. �З.�ОВ: �t.le.e.!. ���?.O�t.1e.�!.�t.1�1e � �!.е. Р Фе. йсы прикладного программирования .. — . — . . . ..

· · · · . . …. . . . . . ….. . ……….

Racks pace

VMware vCloud Ai r

Открытые и частные облака, реализующие проекты OpeпStack. Предлагает управ­ ляемые для . службы . . . . AWS и Azure. Имеет фанатичных сторонников

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

Публ и ч н ые, ч астные и гибри д ные обл а к а В публичном облаке поставщик контролирует все физическое оборудование и предо­ ставляет доступ к с истемам через И нтернет. Это с н имает с пользователей обяза нность и нсталлировать и обслуживать оборудован ие, но за счет меньшего контроля над фун к­ циям и и характеристиками платформ ы . AWS, G C P и DO я вляются общедоступны м и об­ лач н ы м и провайдерами. Ч астные облач ные платформ ы аналоги ч н ы , но размещаются в собственном центре обработки дан н ы х органи зации ил и управля ются поставщиком от имени одного кл и­ ента. Серверы в частном облаке я вл я ются единстве н н ы м и арендаторам и , а не делят е го с другим и клиентами , как в общедоступном облаке. Ч астн ые облака обес п е ч и вают гибкость и п рограм м н ы й контрол ь, так же , как и обы ч н ые облака. Они привлекательны для орган изац и й , которые уже ин вестировали значительный капитал в оборудовани е , а также для и нженеров, особе нно тех , которые ценят пол н ы й контроль над своей средой. OpenStack — это ведущая система с открытым исход н ы м кодом , ис пол ьзуе мая для создания частн ых облаков. Она получает финансовую и техн ическую поддержку от таких предприяти й , как АТ & Т, I BM и l ntel. Rackspace сама по себе я вляется одн им из крупнейших участников Open Stack . Комбинация публичных и частн ых облаков называется гибридным облаком . Гибриды могут быть полезн ы м и , когда предприятие с начала переходит с локал ьн ы х серверов в публичное облако, для добавления времен ной е мкости обработки п и ковых нагрузок и реализации других сценариев. Администраторы должн ы быть осторожн ы м и : работа с двумя разл и ч н ы м и облачн ы м и платформам и в тандеме непропорционально увеличи­ вает сложность. Облако VМware vSphere Air, основанное на технологии виртуал изации vSphere , пред­ ставляет собой удобное гибридное облако для клиентов, которые уже испол ьзуют вирту-

Глава 9. Облачные вычисления

303

ализацию VMware в своем локальном центре обработки да н н ы х . Эти п ол ьзователи могут прозрачно перемещать приложения в и нфраструктуру vCoud Air и и з не е. Термин публичное облако является немного неудачным и вызывает опасе н и я , связан н ые с безопасностью. На самом деле пользователи публичных облаков изолированы друг от друга несколькими слоями аппаратной и программной виртуализации. Частное облако практически не имеет преимущества в области безопасности над публичным облаком . Кроме того , работа с частны м облаком — это сложн а я и дорогостоя щая перспекти­ ва, которую нельзя предприн имать необдуманно. Только крупнейшие и наиболее совер­ шенные организации и меют и нженерные ресурсы и фи на нс о в ы е средства , н еобходи м ы е дЛЯ внедрения н адежного , безопасного частного обл а к а В то ж е врем я , после реал и ­ зации функции частного облака обычно н е соответствуют тем , которые предлагаются коммерческими облаками. Для большинства организаций мы рекомендуем публ и ч ное облако над част н ы м и или гибридны м и опция м и . П убличные облака предлагают наивысшую ценность и простоту администрирован ия. В оставшейся части этой книги мы огра н и ч и м с я публ и ч н ы м и об­ лаками . В следующих нескольких разделах представлен краткий обзор каждой из при­ веденных выше платформ . .

Amazon Web Services AWS (Amazon �Ь Services) предлагает множество услуг: от в иртуальных серверов ( ЕС2) до управляемых баз данных, хранилищ дан н ых (RDS и Redshift) и бессерверных фун кц ий выполняемых в ответ на события ( LamЬda) . Кажцый год компан ия AWS выпускает сотни об­ новлений и новых функций. Она имеет самое большое и самое активное сообщество поль­ зователей. AWS — безусловно, самая крупная ком пания в области облачных вычислений. С точки зрения большинства пользователе й , AWS имеет практически неограничен­ ные возможности . Однако новые учетные записи и м е ют огра н и ч е н и я , которые опред е­ ляют, какой объем вычислител ьной мощности вы можете запросить. Эти о гра нич е ния защищают как Amazon, так и вас , поскольку затраты м о гут быстро в ы р ваться из- под контроля , если услуги не будут долж н ы м образом управлятьс я . Ч тобы увел ичить свои лимиты, в ы должны запол н ить форму на сайте подде р жк и AWS . О гра н и ч е н и я , связан ­ ные с каждой службой , перечислены в документаци и по л и м и та м услуг. Онлай н о вая доку м е нтац и я AWS , расположе н н а я по адр е с у aws . a m a z o n . c o m / documentation , я вляется авторитетной , всеобъемлющей и хорошо ор г а н и зо ва н н о й . Это должно быть первое место, которое вы рассм атриваете п р и исследо ва н и и к он к ре тн о й услуги. Белые страницы, посвященные безопасности , пути м и грации и архитектуры , не­ оценимы для тех, кто заи нтересован в создании н адеж н ы х облачн ы х сред. ,

Google Cloud Platform Есл и AWS я вл яется действующ и м ч е м п ионом в обл ас ти облач н ых в ы ч и сл е н и й то компания Google я вляется его потен циал ьным прее м н и ком . Он ко н к ур и рует за клиен ­ тов, используя такие нечестн ые трюки, как сн ижение цен и пря м ое обраще н и е к боле­ вым точ кам AWS . Спрос на инженеров настолько ожесточе н , что Googl e , как известно , браковала быв­ ших сотрудников AWS . В прошлом компания Google п ро вод ил а вечеринки параллельно с конференцией AWS re: l nvent в Л ас- Вегасе, пытаясь п р и вл е ч ь как тал а нтл ивы х люде й , так и пользователей. По мере эскалаци и облач ных войн кл иенты в конечном итоге вы­ игрывают от этого конкурса в виде более н изких затрат и улуч ш е н н ы х ф ун к ц и й ,

.

Часть 1. Основы администрирования

304

G oogle испол ьзует самую передовую глобальную сеть в м и р е , которая приносит пользу облач ной платформе . Центр ы обработки данных Google — это технологические чудеса, которые п редлагают м ножество и нноваци й дл я повышения энергоэффективно­ сти и с ниже н ия э ксплуатацио н н ых затрат1 • Компания Google относительно прозрачна в с воих операциях, а ее вклад с открытым исходным кодом помогает развивать обл ач ­ ную индустрию. Несмотря на с вою тех н ическую подкован ность, по каким-то причинам ком пания Google я вл яется пр и верже н це м публичного облака, а не л идеро м . Когда оно поя в и ­ лось в 2 0 1 1 — 20 1 2 rr. 2 , G C P уже опаздывала на и гру. Е е службы имеют м ного оди нако­ вых функций (и ч асто одни и те же и мена) , эквивал е нтных фун кциям AWS. Если вы знакомы с AWS, то обнаружите, что веб-интерфейс GCP внешне несколько отличается от AWS , но их функциональные возможности поразительно похожи. Мы ожидаем , что в последующие годы GCP получит определ е н ную дол ю р ы н ка, поскольку компания G oogle улучш ает с вою продукцию и укрепляет доверие клиентов. Она наняла н екоторые из самых ярких умов в отрасли , которые должны разработать не­ которые инновационные технологии . Как потребители , м ы все выиграем от этого.

DigitalOcean DigitalOcean — это другая разновидность публичного облака. В то вре м я как AWS и G C P конкурируют за крупные п редприятия и стартапы , ориентированн ые н а рост, DigitalOcean п р и вл е кает м ал е н ьких кл и е н то в с более п росты м и потребностя м и . Название этой стратегии — м и нимализм . Нам нравится применять D igitalOcean дл я экс­ периментов и п роверок кон цепций. D igitalOcean предлагает центры обработки дан н ы х в Северной Америке , Европе и Азии . В каждом из этих регионов есть несколько центров, но они не связаны напря­ мую и поэтому не могут считаться зонами доступности (см. раздел 9 . 3 ) . В результате по­ строить глобальные высокодоступные производствен н ые службы на основе DigitalOcean значительно сложнее, чем на основе AWS или Google . Серверы DigitalOcean называются дроплетами (droplet) . О н и просто управляются и з командной строки или веб-консоли и быстро загружаются . DigitalOcean поставляет об­ разы для всех наших демонстрационных операционн ых систе м , кром е Red Hat. Он так­ же имеет несколько образов для популяр н ых приложений с открытым исходным кодом, таких как Cassandra, Drupal, Django и Git Lab. Платформ а DigitalOcean также имеет фун кц и и балансировки н агрузки и хран е н ия блоков. В главе 26 м ы п р и води м пример п редоставл е н и я балансировщика нагрузки DigitalOcean с двумя дроплета м и с использованием инструме нта обеспечен и я и нфра­ структуры Terraform ком пании HashiCorp.

9.3 . Основы РАБОТЫ с ОБЛАЧНЫМИ СЛУЖБАМИ Облачные службы слабо групп ируются по тре м категориям. •

И нфраструктура как услуга ( Infrastructure-as-s- Service — I aaS) , в которой пол ьзо­ ватели запрашивают исходны е ресурсы вычислен и й , памяти , сети и хран или ща.

1 См . сайт Google . com/ aЬout/datacenters , на котором можно найти фотографи и и факты о том , как работают центры обработки дан н ых Google. 2Компания Google выпустила другие облачные продукты уже в 2008 г» включая Арр Engine, первый продукт платформы. Однако стратегия Google и бренд GCP не были очевидны до 20 1 2 г.

Глава 9. Облачные вычисления

305

Обычно о н и поставля ются в в иде виртуальных частн ых серверов , а также VPS . Пользователи IaaS отвечают з а управление всем: операционн ы м и системам и , се­ тям и , системами хранения и собствен н ы м программ н ым обеспечением. •

Платформа как услуга ( Platform-as-s- Service — Paa S ) , в которой разработч и к и представля ют с в о и специализирован н ы е п р иложе н и я , упакова н н ы е в форм ате , указанном поставщиком. Затем поставщик запус кает код от и м е н и пользователя . В этой модели пользовател и несут ответствен ность за с вой собствен н ы й код, а по­ ставщик управляет операцион ной с истемой и сетью.

П рогра м мное обеспечение как услуга ( Software -as-s-Service — SaaS) — самая ш и ­ рокая категори я , в которой поставщик разме щает програ м м ное обес п е ч е н и е и управляет и м , а пользователи платят абонентскую плату з а доступ. Пользователи не поддерживают н и операцион ную систему, н и приложение. П очти л юбое разме­ щенное веб-приложение ( например, Word Press) попадает в категорию SaaS .

В табл . 9 . 3 показано , как каждая из этих абстрактн ых моделе й разбивается на слои , связанные с пол н ы м развертыванием. Таблица 9 . 3 . На каких споях вы отвечаете з а управление?

laaS

PaaS

.(

.(

.(

.(

.(

Спой

Локальный•

Приложение

.(

Базы данных Время выполнения приложения Операционная система Виртуальная сеть, хранилище и серверы Платформа виртуализации Физические серверы Системы хранения Физическ ая сеть Мощность, пространство и охлаждение

.(

.(

.( .(

.(

SaaS

.(

.(

.( .( .( .(

.(

‘ Локальный: локальные серверы и сеть laaS PaaS SaaS

инфраструктура как услуга ( виртуальные сервер ы ) . платформа как услуга ( например, Google Арр Епgiпе ) . программное обеспечение как услуга ( например, большинство веб-служб).

Из этих вариантов I aaS я вляется наиболее подходящим для систе м ного адми нистри­ рован и я . В допол н е н ие к определ е н и ю виртуал ь н ы х комп ьютеров, поставщики laaS виртуализируют связанн ые с ними аппаратн ые элементы, такие как диски (в настоящее время используется более общи й терм и н — » блочн ы е устройства хранения дан н ы х » ) и сети. Виртуал ьные серверы могут посещать виртуальные сети , для которых в ы указы­ ваете топологию, маршруты , адресацию и другие характеристики. В бол ьш и н стве случаев эти сети я вл яются частны м и для вашей организаци и . IaaS также может включать в себя другие основные службы , такие как базы данных, очереди, хранилища ключей-значений и вычисл ительн ые кластеры. Эти функции в совокупности создают полную замену традицион ного центра обработки данн ы х (и во многих случаях даже улучшение) .

306

Часть 1. Основы администрирования

PaaS — это область бол ьш и х обещан и й , которая еще не полностью реал и зован а. Те кущие предложе н и я , такие как AWS Elastic Beanstal k , G oogle Арр Engine и H e roku , и м е ют э кологические огран и ч е н ия ил и н юанс ы , которые делают их н е п ракти ч н ы м и ( ил и непол н ы м и ) дл я испол ьзован и я в загруже н н ы х производствен н ых средах. Снова и с н ова м ы в идел и , как бизнес перерастает эти услуг и . Одн а ко н о в ы м услугам в этой области уделяется бол ьшое в н и м а н и е . В бл ижа й ш и е годы м ы ожидае м значител ь н ы х улуч ш е н и й . Облач н ы е поставщики широко различаются по своим фун кциям и деталям реализа­ uии, но концептуал ьно м ногие услуги оче н ь похожи . В следующих разделах описывают­ ся облачн ы е службы в целом , но поскол ьку AWS является л идером в этом пространстве , мы и ногда п ри н и маем е го номен клатуру и услов н ы е обозначе н ия в качестве значе н и й по умолчан ию.

Доступ к обла ку П ервичн ы й и нтерфейс бол ь ш и н ства облач н ы х провайдеров — это с воего рода веб­ интерфейс. Новые систе м н ы е адми н истраторы дол ж н ы испол ьзовать эту веб- консоль дл я создания уч етной записи и для н астройки своих первых ресурсов . Облачн ые прова йде р ы также определяют и нтерфейсы прикладного программ и рова­ н ия , имеющие доступ к тем же базо в ы м фун кциям , что и к веб-консол и . В большинстве случаев у н их также есть стандартная оболоч ка командной строки , переносимая бол ь­ ш инством систе м для этих интерфейсов при кладного програм м и рован ия. Даже ветера н ы с исте м ного адм и нистрирования часто испол ьзуют веб-графические интерфейсы. Тем не менее важно также дружить с инструментам и командной строки , по­ с кол ьку они легче с п равляются с автоматизацией и повторяемостью. Испол ьзуйте сцена­ ри и , чтобы избежать утом ительного и вялого процесса запроса всего и вся через браузер. Облач н ы е поставщи ки также поддержи вают ком пл е кты разработки програм м н ого обес печения ( S D K) для м ногих популярн ых язы ков, чтобы помоч ь разработч икам ис­ пол ьзовать их и нтерфе й с ы прикл адного программирования . Сторо н н и е и н струме нты ис пользуют S D K дл я упроще н и я ил и автоматизаци и определен н ых наборов задач . В ы , несо м н е н но, стол к нетесь с эти м и S D K, есл и напишете свои собстве н н ые инструменты. Обычно для доступа к системам U N IX и Linux, работающим в облаке , испол ьзуется ал горитм S S H с аутентификацией открытого ключа. Для получ е н ия допол н ительной и н ­ формаци и о б эффективном испол ьзова н и и S S H с м . раздел 2 7 . 7 . Н е которы е поставщики облач н ых выч ислен и й позволяют получить доступ к сеансу консол и через веб-браузер , что может быть особен н о полезн ы м , есл и вы ош ибочно за­ блокируете себя с помощью правила брандмауэра или сломанной конфигурации S S H . Од нако это н е означает представл е н ие реальной консол и систе м ы , поэтому в ы н е мо­ жете испол ьзовать эту функцию для отладки начальной загрузки или проблем с B I OS.

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

Глава 9. Облачные вычисления

307

Например, регион Amazon u s — e a s t — 1 обслужи вается центрами обработки дан н ых в се­ верной Вирджи н и и . 3 Некоторые провайдеры также имеют зон ы доступности ( ил и просто зон ы ) , которые представля ют собой совокуп ность це нтров обработки дан н ы х в регионе . Зон ы внутри региона просматри ваются в сетях с высокой пропускной с пособностью и н и зкой за­ держкой . поэтому межзонал ьная с вязь выполняется быстро, хотя и не обязател ьно де­ шево. Например, мы наблюдали межзонную задержку длител ьностью менее 1 мс. Зоны обычно проекти руются так , чтобы быть независ и м ы м и друг от друга с точ ки зрения мощности и охлаждения, и они географически распредел е н ы , так что стихий ное бедствие, которое затрагивает одну зону, и меет ни зкую вероятность воздействия на дру­ гих людей в том же регионе. Ре гионы и зоны имеют ос новополагающее значение для создания высокодоступных сете вых услуг. В зависимости от требова ний доступности вы можете разверты вать свои ресурсы в нескольких зонах и регионах, чтобы м и н и м изировать последствия сбоя в це н ­ тре обработки дан н ы х и л и в географической области. Откл ючения зон ы доступности возможн ы , но редки ; регионал ьн ы е сбои происходят еще реже . Бол ьши нство служб , предоставляемых облач н ы м и провайдера м и , знают о зонах и испол ьзуют их для дости ­ же ния встрое н ной избыточности .

Регионы соединяются через Интернет или через частные сети; плата взимается в любом случае

Внутризонный трафик является бесплатным

Западный регион США

Межзонное соединение является частным и оплачивается в зависимости от объема

Восточный регион США

Рис. 9. 1. Серверы , распределенные между несколькими регионами и зонами

М ногоуровневые развертыван ия я вля ются более сложн ы м и из-за физических рас ­ стоя н и й между регионами и свя зан ной с н и м и бол ьше й задержки. Н е которые постав­ щики облач н ы х технологий испол ьзуют более быструю и надежную межре гионал ьную сеть, чем другие. Есл и ваш сайт обслуживает пользователе й по все му миру, качество сети вашего облачного поставщика имеет первостепен ное значение. Выбирайте регио н ы в зависимости от географической бл изости к вашей пол ьзова­ тел ьской базе . Для сценариев, в которых разработч ики и пол ьзовател и находятся в раз­ н ы х гео графических регионах, подума йте над те м , чтобы ва ш и систе м ы разработки были бл изки к разработч икам, а производствен н ы е систе м ы бл иже к пол ьзователя м . 5 мс, чтобы преодолеть 1 000 км, США с точки зре н и я производительности вполне

) Для сигнала, передаваемого 110 шпическому волокну, требуется около поэтому ре1·ион ы размером с восточн ое побережье приемлем ы . Сетевое под клю•1е ние, доступное

ДJIЯ дата- центра, важнее, чем его точное местоположение.

308

Часть 1. основы администрирования

Для сайтов, предоставля ющих услуги для глобал ьной пользовател ьской базы, работа в нескол ьких регионах может существен но повысить производител ьность для конечных пользователей. Запросы могут направляться на региональные серверы каждого клиента, испол ьзуя географическое DN S-разрешение, которое определяет местоположе н ие кл и ­ е нтов п о и х исходн ым I Р-адресам . Бол ьш и нство облачн ы х платформ и м е ют регио н ы в Северной Америке , Южной Амери ке, Европе и странах Азиатско-Тихоокеанского региона. Тол ько AWS и Azure н е ­ посредственно присутствуют в Китае. Н екоторые платформ ы , в частности AWS и vCloud , имеют ре гионы , совмести мые со строги м и федеральн ы м и требован и я м и I ТAR, прин я ­ т ы м и в С ША.

В и ртуальные частны е серверы Флагманской службой облака я вляется виртуал ьн ы й частн ы й сервер , виртуал ьная машина, работающая на ап паратном обеспеч е н и и провайдера. Виртуал ьн ые частн ые серверы иногда н азы ваются экземплярами. В ы можете создать стол ько экзе м пл я ров, с колько вам н ужно, запустив свою п редпочтител ьную операционную систему и прило­ же н и я , а затем закрыть экзе м пляры, когда они больше не нужны. В ы платите только за то, что испол ьзуете , и обыч но не несете авансовых расходов. П оскол ьку экзем пляры я вляются виртуал ьн ы м и маш инам и , их мощность процессо­ ра, память, размер диска и сетевые настройки могут настраи ваться , когда экзем пляр соз­ дается и даже корректируется постфактум . Открытые облач ные платформ ы определяют предустановленные конфигураци и , назы ваемые типами экземпляров. О н и варьируются от однопроцессорных узлов с 5 1 2 Мбайт памяти до бол ьших систем со м ногим и ядрами процессора и нескол ькими Ти Б памяти. Некоторые ти пы экзе м пляров сбалансированы для обще го использования , а другие специализируются на приложе н иях с процессором , памятью, диском или сетью. Конфигурации экземпл яров — это одн а из областей , в ко­ торой поставщики облач ных вычисл ен и й энергично кон курируют, чтобы соответство­ вать потребностям рынка. Экземпляры создаются из образов, сохраненного состоя ния операцион ной системы, которое содержит ( как м и н имум) корневую файловую с истему и загрузчик. Образ мо­ жет также включать в себя тома дисков для допол нительных файловых с исте м и других настраиваемых параметров. Вы можете легко создавать собственные образы с помощью собствен ного программного обеспечения и настроек. Все наши иллюстративные операцион ные систе м ы испол ьзуются ш ироко, поэтому облач ные платформ ы обычно предоставля ют для н их офи циальные образы .4 М ногие сторон ние поставщики програ м м ного обесп ечения также поддерживают образы обла­ ков, которые и меют предустановленное програм м ное обеспечение для облегчения при­ нятия клиентам и . Также легко создавать свои собствен н ые образы. Подробнее о том , как создавать об­ разы виртуальной маш и н ы в пакете , см. раздел 24. 5.

Сети Облач ные провайдеры позволяют создавать виртуал ьн ые сети с настраиваем ы м и то­ пологиям и , которые изоли руют ваш и систе м ы друг от друга и от И нтернета. На плат­ формах, которые предлагают эту фун кцию, вы можете установить диапазоны адресов ва48 настоящее вре мя вы должны создать свой собствен н ы й образ Free BSD, если используете Google Compute Eпgine.

глава 9. Облачные вычисления

309

ших сете й , оnределить nодсети , настроить маршруты , установить nравила брандмауэра и nостроить VPN для nодкл ючения к внеш ним сетя м . С сетью и эксnлуатацией более круnных и более сложных облачных nриложений связаны оnределен н ые издержки. Ш Дополнительную информацию о сети VPN см . в разделе 27.9. Вы можете сделать ваш и серверы достуnн ы м и в И нтернете nутем аренды nублично маршрутизируе м ы х адресов от вашего nровайдера. У всех nоставщи ков есть большой пул таких адресов, из которых nол ьзователи могут выбирать. В качестве альтернативы серверам может быть предоставлен тол ько частн ы й адрес RFC 1 9 1 8 в адресном про­ странстве , выбранном м я вашей сети, что делает их общедоступн ы м и . Ш Дополн ительную и нформ ацию о частн ых адресах R FC 1 9 1 8 см. в разделе 1 3 .4. Систе м ы без общедоступ н ы х адресов напрям ую не доступн ы и з И нтерн ета, даже для администраторов. Вы можете nолуч ить достуn к таким узлам через сервер nерехода или хост-бастион , которы й открыт для И нтернета, или через сеть VPN , которая под­ ключается к вашей облачной сети . Для безопасности лучше, чтобы внешняя зона вашей виртуальной и м перии была как можно меньше. Хотя все это звучит м ногообещающе , у вас меньше возможносте й управлять вирту­ альными сетя м и , чем традицион н ы м и , и вы должн ы подчи н яться прихотям и капризам набора функций, предоставленных ваш им выбранн ы м nровайдером . Это особе нно раз­ дражает, когда новая функция не может взаимодействовать с вашей частной сетью. ( М ы смотри м на тебя , Amazon!) Для n ол уч е н и я nодробной и н формации о сети TC P/ I P в облаке nерейдите в раз­ дел 1 3 . 1 5 .

Х ранили ще Важной частью облачн ы х вычисле н и й я вляется хранение данн ых. Облачн ы е про­ вайдеры и меют самые большие и самые современ н ые систем ы хранения данных на пла­ нете, поэтому вам будет трудно обеспечить их объем и возможности в частном центре обработки данных. Поставщики облачных вычислений взимают nлату с объема дан ных, которые вы храните. О н и оче н ь моти вированы , чтобы дать вам как можно больше воз­ можностей мя хране н ия ваш их данных.5 Перечисл и м нескол ько н аиболее важн ых сnособов хранения данн ых в облаке . •

Объектн ые хранил и ща содержат коллекции дискретных объектов (no существу, файлов) в nлоском простра нстве и м е н . Объектные хранилища могут в м е щать nрактически н еограничен н ы й объем данных с исключительно высокой надежно­ стью , но отн ос ител ьно н изкой производительностью. Они предназнач е н ы в ос ­ новном д11 я чтения. Файл ы в хран илище объектов доступны через сеть с помощью протокола Н ТТР S. П римеры — AWS SЗ и Google Cloud Storage . Блоч н ы е устройства хранения — это в иртуал изирова н н ы е жестки е диски. О н и могут быть настроен ы по вашему выбору и nодкл ючен ы к виртуальному серверу, nодобно томам SAN в традиционной сети. В ы можете перемещать тома между уз­ лами и настраивать свои п рофили ввода-вывода. П римеры — AWS EBS и Google Cloud Storage.

5 Н а пример, компания AWS п редлагает посетить ваш у орган изацию н а м а ш и н е AWS S nowmoblle, представляющей собой транспортный контейнер дли ной 45 футов, который буксируется грузовым тягачом и способен перевести 1 00 П и Б из вашего дата-центра в облако.

Часть 1. Основы администрирования

31 0 •

Эфемерное хра н ил ище — это локал ьное дисковое простра н ство на виртуал ь­ ном частном сервере (Virtual Private Server — VPS). создан ное на основе дисков на главном сервере. Они обычно бывают быстр ы м и и е м ки м и , но при удал е н и и VP S дан н ы е теря ются, поэтому эфемерное хра н ил и ще луч ш е всего испол ьзовать для временных файлов. П ри м еры — тома хра н ил и ща экзе м пляров на AWS и ло­ кальные SSD на G C P.

В дополнение к эти м службам хранения данных облачные провайдеры обычно пред­ лагают множество бесплатных служб баз дан н ы х , которые вы можете получить через сеть. Реляционн ые базы данных, такие как MySQ L, PostgreS Q L и O racle, выпол ня ются как службы AWS Relational Database Service. Они предлагают встроен ную мул ьтизон ную избыточность и ш ифрование дан н ых при хранении. Расп редел е н н ы е анал ит и ч е с к и е базы дан н ых . та кие как AWS Redshift и G C P BigQuery, предлагают н евероятную рентабельность ин вестиций; обе эти базы заслужива­ ют в н имательного изучения, прежде ч е м строить собственное дорогостоя щее хранил и ­ щ е . П оставщики облаков также предлагают обычн ы й ассортимент баз дан н ых в опера­ тивной памяти и NoSQL, таких как Redis и memcached.

Идентификация и авторизация Адм и н истраторам , разработч и кам и другим техническим сотрудн и кам н еобходимо управлять облач н ы м и служба м и . В идеал ьном случае средства управл е н и я доступом должн ы соответствовать принципу наименьших привилеги й : кажд ы й директор может иметь доступ тол ько к объектам , которые и м е ют к нему отноше н и е , и не более того. В зависи мости от контекста такие спецификации контроля доступа могут стать довол ь­ но сложным и . Ком пан ия AWS искл юч ител ьно с ил ьна в этой области . Е е служба под н азванием l dentity and Access M anagement ( IAM) определяет не тол ько пол ьзователе й и груп п ы , н о и роли дл я систем . Например, серверу могут б ы т ь назнач е н ы пол итик и , позволяю­ щие его программ ному обеспечению запус кать и останами вать другие серверы, хран ить и извлекать дан н ы е в хра н илище объектов или взаимодействовать с очередям и — все с автоматической ротацией ключей. Служба IAM также и меет и нтерфейс прикладного программирования для управления кл ючами , который поможет вам безопасно хранить секреты. Другие облач н ы е п л атфор м ы и м е ют м е н ьш е возможносте й автор и за ц и и . Н еуди вительно, что служба Azure основана н а службе Active Directory M icrosoft . Она хо­ рошо сочетается с сайта м и , для которых существует интегрирован н ы й каталог. Служба контрол я доступа G oogl e , также назы ваемая IA M , относ ител ьно грубая и н е пол ная по сравнению со службой компан ии Amazon.

А втоматизация И нструменты A P I и C L I , созданные поставщика м и облачных технологи й . я вля ют­ ся основны м и строительн ы м и блоками пользовател ьс кой автоматизации. но они часто неукл южи и непрактич н ы для организации бол ьш и х коллекций ресурсов. Например, что делать, есл и вам нужно создать новую сеть, запустить нескол ько экзе м пл яров VPS, предоставить базу дан н ы х , настроить брандмауэр и, наконец, подключ ить все эти ком ­ поненты’? С точки зрен ия облач ного API это бьш бы сложны й сценар и й . AWS CloudFormation стала первой службой дл я решения этой проблемы. О на принимает шаблон в формате J SON или YAM L, который описывает требуемые ресурсы и связан ные

Глава 9. Облачные вычисления

31 1

с ними детали конфиrураuии. Вы отпрамяете шаблон в службу CloudFormation, которы й проверяет его на наличие ош ибок, сортирует зависимости между ресурсами и создает или обновляет конфиrураuию облака в соответствии с вашими спецификациям и . Шаблоны Clou d Formation ямяются мощ н ы м и , но подверже н ы ош ибкам в челове ­ ческих руках из-за строгих требован и й с интаксиса. П ол н ы й ш аблон я вляется невыно­ симо многословн ы м , и л юдям сложно даже ч итать е го. Вместо того , чтобы п исать эти шаблон ы вручную, мы предпоч итаем автоматически генерировать их с п омощью биб,ш ­ отеки Python под названием Troposphe re от Марка П ика ( Mark Peek) (см. G i t h ub . com/ cloudtoo l s / t ropo s p h e r e ) . Третья сторонняя служба также нацелена на эту проблему. Служба Terraform с от­ крыты м исходн ы м кодом ком па н и и HashiCorp , я вляется средством для построе н ия и изме нения инфраструктуры независимо от особенностей облака. Как и в службе Clou d Formation , вы описываете ресурсы в настраиваемом ш аблоне, а затем позволяете службе Terraform создавать правил ьн ые вызовы API для реал иза ц и и вашей конфи rурации . Затем вы можете проверить с вой конфигурацион н ы й файл на управление версиJ1 ми и управлять инфраструктурой с течен ием времени.

9.4. ОБЛАКА: БЫСТРЫЙ ЗАПУСК VPS НА ПЛАТФОРМЕ Облако — отличная песоч ница, в которой можно изучить системы UN IX и Linux. Эrот короткий раздел поможет вам и нсталлировать и запускать виртуальные серверы на AWS , GCP ил и DigitaOcean . В качестве с истемных адми н истраторов м ы акти вно испол ьзуем командную строку (в отличие от веб-графических интерфейсов) для взаимодействия с об­ лаком , поэтому иллюстрируем здесь использование именно этих инструментов.

Веб -службы Amazon Для того чтобы использовать AWS , сначала настройте учетную запись н а сайте a w s . ama z o n . c om. Создав учетную зап ись, немедленно следуйте инструкциям AWS Trusted Advisor, чтобы настроить свою учетную запись в соответствии с предлагаемыми рекоменда­ циями . Затем вы можете перейти к отдельным консолям обслуживания для ЕС2, VPC и т.д. Каждая служба AWS и м еет с п е ц и ал ь н ы й пол ьзовательск и й и нтерфе й с . Когда вы войдете в веб-консоль, вы увидите вверху с писок служб. Внутри Amazon каждая служ­ ба управляется независимой командо й , и, к сожал е н и ю , дан н ы й и нтерфейс отражает этот факт. Хотя это решение помогло развивать АWS-службы , это приводит к нескол ь­ ко фрагментирован ному оп ыту взаимодействия. Не которые и нтерфейсы более удобн ы и интуитивн ы , ч е м другие . Для того чтобы защитить свою учетную зап ись, вкл юч ите м ногофакторную ауте нти­ фикацию ( M FA) для пользователя root , а затем создайте привилегированного пользова­ теля АМ для повседневного испол ьзования. Мы также обычно настраи ваем псевдон и м , чтобы пользовател и могли получ ить доступ к веб-консол и без ввода номера учетной за­ писи. Эта опция находится на начал ьной стран ице службы IAM . В следующем разделе м ы представляем официальный инструмент aws — интерфейс командной строки , написан н ы й на Python. Новые пользователи также могут воспол ьзо­ ваться службой быстрого запуска Amazon Lightsail , целью которой ямяется запуск эк­ земпляра ЕС2 с м и н имальн ы м и усил иями.

Часть 1. Основы администрирования

31 2

И нтерфейс aws: уп равление подсистемами AWS П рограмма aws — это ун ифи цированн ы й интерфейс командной строки для служб AWS . Он управляет экзем плярами , сохраняет резервные копи и , редактирует записи D N S и выполняет большинство других задач, отображаемых в веб-консол и . И нструме нт ос­ нован на замечател ьной библ иотеке Boto, S D K Python для AWS API и работает в л юбой системе с действующим интерпретатором Python. Установите этот инструмент с помощью команды pip: $ pip install awscli

Для того чтобы испол ьзовать aws , с начала выпол ните аутентифи кац и ю в интерфей ­ се прикладного програ м мирования AWS , используя пару случай н ых строк, называемых идентификатором ключа доступа и секретным ключом доступа . Создайте эти учетные дан ные в веб-консоли IAM , а затем скопируйте и вставьте их на м естном уровне. При выпол н е н и и команды aws confiqure вам будет предложено установить учет­ ные данные A P I и регион по умолчанию: $ aws confiqure AWS Acce s s К е у I D : AКIAIOSFODNN7EXAМPLE AWS S e c r e t Acc e s s К е у : wJalrXUtnFEМI/ K7МDENG/bPxRfiCYEXAМPLEКEY D e f a u l t r e g i on n arne [ u s — e a s t — 1 ] : De f a u l t o u t p u t f o rrnat [ N one ] :

Эти настройки сохраня ются в файле — / . aw s / config. П ока вы настраиваете среду, м ы также рекоме ндуем вам настроить фун кцию автозаполнения оболоч ки bash, чтобы легче было обнаружить подкоманды . Допол н ительная и нформация представлена в до­ кументах AWS C L I . Первый аргумент команды aws называет кон кретную службу, которой в ы хотите мани­ пул ировать; например, ес2 Дll Я действий, которые управляют веб-службой Elastic Compute Cloud. Вы можете добавить подсказку по ключевым словам в конце любой команды, что­ бы увидеть инструкции. Так, aws help, aws ес2 help и aws ес2 descriЬe- instance help помогают создавать полезные справочные страницы.

Создани е э кзем пляра ЕС2 m Дополн ительную и нформаци ю о команде pip см. в разделе 7 . 6 . Для создан и я и зап ус ка экзе м пляро в ЕС2 ис пол ьзуйте команду a w s е с 2 run­ instances. Хотя вы можете создавать нескол ько экзе м пляров с помощью одной коман­ ды ( испол ьзуя параметр — — count ), экзе м пляры должн ы иметь общую конфи гурацию. Вот м и н имал ьн ы й пример полной команды: $ aws е с 2 run- ins tances — — imaqe-id ami -d4 4 0 aбe7

— — ins tance — type t2 . nano — — associate-puЫic-ip-address — -key-name admin-key

# в ыв о д см . ниже

В этом примере указаны следующие дан ные конфигурации. •

Образ базовой системы представляет собой версию CentOS 7 , выпущенную Amazon, с именем ami — d 4 4 0 a бe 7 . (AWS называет эти образы AM I — Amazon Machine I mages. ) Как и другие объекты AWS , имена образов, к сожал е н и ю , не мнемоническ и е ; вы должны искать идентификаторы в веб- консол и ЕС2 или в командной строке (aws ес2 describe- images) Дll Я их декодирования.

Глава 9. Облачные вычисления •

31 3

Тип экзем пляра t 2 . n a n o , которы й в настоящее врем я является наименьшим типом э кзем пляра. Он и меет одно ядро центрального процессора и 5 1 2 Мбайт оперативной памят и . С веде н и я о доступн ы х типах экзе м пляров можно найти в веб-консоли ЕС2 . —

Для управления доступом SSH также назначается предварительно сконфиrуриро­ ван ная пара ключе й . В ы можете создать пару кл юч е й с помощью команды s sh­ keygen (см . раздел 2 7 . 7 ) , а затем загрузить открытый кл юч в кон соль AWS ЕС2.

Результат работы команды aws ес2 run-instance показан ниже. Эrо формат JSON , поэтому он легко распознается другим программ н ы м обеспечением. Например, после за­ пуска экземпляра сценарий может извлекать I Р-адрес экземпляра и настраивать DNS, об­ новлять систему инвентаризации или координ ировать запуск нескольких серверов. $ aws ес2 run- ins tances . . . # Те же кома нды , что и выше { » Owne r l d » : » 1 8 8 2 3 8 0 0 0 0 0 0 » , » Re s e rv a t i on l d » : » r — 8 3 a 0 2 3 4 6 » , » I n s t an c e s » : [ » P r i va t e i pAdd r e s s » : » 1 0 . 0 . 0 . 2 7 » , » I n s t a n ce l d » : » i — c 4 f 6 0 3 0 3 » , » I ma ge l d » : » ami — d 4 4 0 a б e 7 » , » P r iva t e Dn s N ame » : » ip — 1 0 — 0 — 0 — 2 7 . u s — we s t — 2 . c ompu t e . i n t e rn a l » , » K e yName » : » a dmi n — ke y » , » S e c u r i t yG r o up s » : [ { » G roupName » : » d e f a ul t » , » G roup l d » : » s g- 9 e b 4 7 7 fb » ] , » Subne t l d » : » s ub ne t — e f 6 7 9 3 8 a » , » I n s t a n c e T ype » : » t 2 . na no » ,

По умолчани ю экзем пляры ЕС2 в подсетях УРС н е и меют подключе н н ых общедо­ ступных I Р-адресов, что делает их доступными только из других с истем в пределах одно­ го УРС. Чтобы использовать экзе м пляры непосредственно из Интернета , задействуйте параметр —associate-puЫic-ip-address, как показано в нашем примере . В ы може­ те узнать назнач е н н ы й l Р-адрес постфактум с помощью команды aws ес2 des cribe­ ins tances или путем поиска экземпляра в веб-консол и . Брандмауэры в ЕС2 называются группами безопасн ости. Поскольку м ы не указали здесь группу безопасности, AWS принимает группу d e f a u l t , которая не дает доступа. Чтобы подключиться к экзем пляру, настройте группу безопасности , чтобы разр е ш ить выполнение ал горитма SSH с ваш е го I Р-адреса. В сценариях реального мира структура группы безопасности должна быть тщател ьно сплан ирована во врем я проектирования сети. Мы обсуждаем группы безопасности в разделе 1 3. 1 5 . Команда aws configure устанавливает область по умолчанию, поэтому вам не нуж­ но указывать регион для экзем пляра, если вы не хотите задать что-то , отличное от зна­ чения , п р и нятого по умолчанию. AM I , п ара ключей и подсеть относятся к региону, и интерфейс aws жалуется , если их нет в указанном вами регионе . ( В этом кон кретном случае A M I , пара ключей и подсеть находятся в регионе u s — e a s t — 1 . )

Часть 1. Основы администрирования

31 4

Обратите внимание на поле I n s t a n c e l d в с п иске резул ьтатов , которое я вляется ун и кал ьн ы м идентифи катором для нового экзем пляра. Команда aw s ес2 describe ­ ins tance -instance-id id выводит подробную информацию о существующем экзем­ пляре, а команда aws е с 2 de sc ribe — i n stan ce s — обо всех экземплярах в регионе. Когда экзе м пляр запуще н и группа безопасности по умолчанию настрое на для пере­ дач и трафи ка по ТС Р-порту 22, вы можете ис пол ьзовать ал горитм S S H для входа в си­ стему. Большинство AM I настроены с учетной записью nonroot с привилегиям и sudo. Для с исте м ы Ubuntu и м я п ол ьзователя — u b u n t u ; дл я CentOS — c e n t o s . Free B S D и Amazon Linux испол ьзуют и м я e c 2 — u s e r . В документации дл я выбранного вам и A M I должно быть указано и м я пол ьзователя, если оно н е я вляется одн им и з них. П равильно настрое н н ы е образы позволя ют использовать тол ько открытые кл ючи для аутентификации S S H , а не пароли. После того как вы вошли в систему с се кретным кл ючом S S H , у вас будет пол н ы й доступ к sudo без н еобходимости пароля. Мы реко­ ме ндуем откл юч ить пол ьзовател я по умолчан ию после первой загрузки и создать лич­ ные учетн ые записи .

Просмотр журнала консоли Отладка н изкоуровневых проблем , таких как проблемы при запуске и ошибки диска, может быть сложной задаче й без доступа к консоли экземпляра. И нтерфе йс ЕС2 позво­ ляет получ ить вывод консол и экземпляра, который может быть полезен , если экземпляр находится в состоян и и ош ибки ил и , по-видимому, зависает. Вы можете сделать это че­ рез веб- и нтерфейс ил и с помощью команды aws ес2 get-console-output, как пока­ зано ниже . $ aws ес2 qet- console- output — — ins tance-id i — c 4 f 6 0 3 0 3 {

» I n s t anc e l d » : » i — c 4 f 6 0 3 0 3 » , » T ime s t amp » : » 2 0 1 5 — 1 2 — 2 1 T 0 0 : 0 1 : 4 5 . 0 0 0 Z » , » Output » : » [ 0 . 0 0 0 0 0 0 ] I n i t i a l i z i ng c g r oup s ub s y s cpu s e t r n [ 0 . 0 0 0 0 0 0 ] I n i t i a l i z i ng cg roup s ub s y s cpu r n [ 0 . 0 0 0 0 0 0 ] I n i t i a l i z i ng c g r o up s u b s y s c p u a c c t r n [ 0 . 0 0 0 0 0 0 ] L i n u x ve r s i on 4 . 1 . 7 — 1 5 . 2 3 . am z n l . x 8 6_ 6 4 ( mo c kbu i l d @ gob i — b u i l d — 6 0 0 0 6 ) ( gc c ve r s i on 4 . 8 . З 2 0 1 4 0 9 1 1 ( Red H a t 4 . 8 . 3 — 9 ) ) # 1 SMP Mon S e p 1 4 2 3 : 2 0 : 3 3 UTC 2 0 1 5 r n

W Дополнительную и нформацию о б управлении пользователями с м . в главе 8 . П ол н ы й жур н ал , коне ч н о , нам ного дольше, ч е м этот фрагмент. В дам пе J SON со­ держимое журнала, к сожален ию склеивается в одну строку. Для луч шей ч итаемости от­ форматируйте его с помощью команды sed. ,

$ aws ес2 qet- console- output — — ins tance-id i — c 4 f 6 0 3 0 3 1 sed ‘ s / r n/ n/q ‘

» I n s t anc e i d » : » i — c 4 f 6 0 3 0 3 » , » T ime s t amp » : » 2 0 1 5 — 1 2 — 2 1 T 0 0 : 0 1 : 4 5 . 0 0 0 Z » , » Output » : » [ 0 . 0 0 0 0 0 0 ] I n i t i a l i z i n g c g r oup s ub s y s cpu s e t [ 0 . 0 0 0 0 0 0 ] I n i t i a l i z i n g c g r oup s ub s y s cpu [ 0 . 0 0 0 0 0 0 ) I n i t i a l i z i n g c g r oup s ub s y s cpua c c t [ 0 . 0 0 0 0 0 0 ) L i n u x ve r s i on 4 . l . 7 — 1 5 . 2 3 . am z n l . x 8 6_ 6 4 ( mo c kbu i l d @ gob i — bu i l d — 6 0 0 0 6 ) ( g cc ve r s i on 4 . 8 . З 2 0 1 4 0 9 1 1

Глава 9. Облачные вычисления

( Red H a t 4 . 8 . 3 — 9 ) )

31 5

# 1 SMP Mon S e p 1 4 2 3 : 2 0 : 3 3 UTC 2 0 1 5

Эта запись журнала поступает непосредственно и з процесса загрузк и Linux. В приве­ денном выше примере показано несколько строк с момента и н ициализации экзем пляра. В больши нстве случаев вы найдете самую и нтересную информацию в конце журнала.

Остановка и завер ше ние ра боты э кземпляров Когда вы законч ите работать с экзе м пляром , вы можете остановить (stop) его, чтобы закрыть экзе м пляр, но сохранить его для последующего испол ьзования, или завершить (terminate) е го, чтобы полностью удалить э кзе м пляр. По умолчанию завершение также полностью освобождает корневой диск экземпляра. После прекращен и я работы экзем­ пляр не может быть восстановлен даже с помощью AWS. $ aws ес2 s top- ins tances — — ins tance — id i — c4 f 6 0 3 0 3 { » S t opp i n g i n s t ance s » : { » I n s tance i d » : » i — c 4 f 6 0 3 0 3 » , » C u r r en t S t a t e » : { » Code » : 6 4 , » N ame » : » s t opp i n g » ), » P re v i o u s S t a t e » : { » C ode » : 1 6 , » N ame » : » runn i n g «

Обратите внимание на то, что виртуал ьные м аш и н ы н е меняют состоян ие мгновен­ но; им требуется перезагрузка. Следовательно, суmествуют переходны е состоян и я , такие как начало (starting) и остановка (stopping) . Обязательно учитывайте их в любых сцена­ риях, которые вы можете написать.

Goog le Cloud Platform Для того чтобы начать работу с платформой GCP, создайте учетную зап ись на сайте c l oud . goog l e . com. Если у вас уже есть идентификатор Google , вы можете зарегистри­ роваться в той же учетной записи. Службы G C P работают в разделе , известном как проект . В каждом проекте есть от­ дельные пользователи , данные о счетах и учетные данные API , поэтому вы можете до­ стичь пол ного разделения между разрозненн ы м и приложе н и я м и или областям и бизне­ са. Создав с вою учетную запись, создайте проект и включите отдел ьные службы GCP в соответствии с ваши м и потребностям и . G oogle Compute Engine, служба VPS , я вляется одной из первых служб, которые вы, возможно, захотите включить.

Настройка gcloud П ро грамма g c l oud, приложе н и е на языке Pytho n , я вляется и нструментом C LI для G C P. Это ком понент Google Cloud S DK , которы й содержит м н ожество библ иотек и и нструментов для взаимодействия с G C P. Чтобы установить его, следуйте инструкци­ я м по установке на сайте c l oud . goog l e . com/ s d k.

31 6

Часть 1. Основы администрирования

П ервое действие должно состоять в том , чтобы настроить среду, выпол н и в команду gcloud ini t. Эта команда запускает небольшой локал ьн ы й веб-сервер, а затем откр ы ­ вает ссыл ку браузера для отображен и я пользовательского и нтерфейса Google для аутен ­ тификации . П осле аутентификации через веб-браузер gcloud попросит вас ( в оболоч ­ ке) в ыбрать профиль проекта, зону по умолчан и ю и другие знач е н ия по умолчан и ю . Настройки сохраняются в файле � / . config/gcloud / . Выполн ите команду gcloud help для получения общей и нформации или gcloud — h для краткого описания использования. Также доступна помощь п о подкоманде; например, команда gcloud help compute показывает справочную страни цу для службы Compute Engine.

Запуск э кзем пляра на GCE В отличие от команд aw s , которые немедленно возвращают управл е н и е , команда gcloud compute работает синхронно. Н апример, когда вы выполняете команду create для запроса нового экземпляра, команда gcloud делает необходимый вызов A P I , а затем ждет, пока экземпляр не будет настроен и запущен , а затем возвращает его. Это соглаше­ ние позволяет избежать необходимости опроса состояния экземпляра после его создания. 6 Для того чтобы создать экзе м пляр, сначала определите имя ил и псевдон и м образа, которое вы хотите загрузить: $ gcloud compute images l i s t — — regexp ‘ debian . * ‘ AL I AS NАМЕ P ROJECT d eЬ i a n — 7 — wh e e z y- v2 0 1 6 0 1 1 9 deЬi a n — c l oud deЬ i a n — 7 d e Ь i a n — 8 — j e s s i e — v2 0 1 6 0 1 1 9 deЫ a n — c l oud deЬian- 8

D E P RECAT E D S TATU S READY READY

Затем создайте и загрузите экземпляр, указав его имя и образ. $ gcloud compute ins tances create ulsah — — image dehian-8 # ожид а е т э к з емпл яра для запуска . . . NАМЕ Z ONE МAC H I N E Т У Р Е I NT E RNAL I P EXT E RNAL I P u l s a h u s -central l — f n l — s tandard- 1 10 . 100 . 0 . 4 1 0 4 . 1 97 . 65 . 2 1 8

STATUS RUNN I N G

Обыч но результаты работы этой ком анды содержит столбец, которы й показывает, я вляется л и экзе м пляр вытесняемым , но в этом случае он был пустым , и м ы удалил и е го, чтобы уместить в ывод на странице. В ытесняемые экзе м пляры м е н ее дороги , чем стандартные э кзем пляр ы , но о н и могут работать только 24 часа и их работа может быть прекращена в л юбое вре м я , если Google нуждается в ресурсах дл я другой цел и . О н и предназнач е н ы для долговрем е н н ых операций , которые могут допускать перерывы, на­ пример задания пакетной обработки . В ытесняемые экзе м пляры а налогичн ы спот-экзем плярам ЕС2 в том с м ысле , что вы платите дисконтированную ставку за остальную резервную е м кость. Тем не менее м ы обнаружили , что вытесняемые экземпляры Google более разум н ы и проще в управле­ н и и , чем спот-экземпляры AWS. Однако долговреме н н ые стандартные экзе м пляры оста­ ются наиболее подходящ и м выбором для большинства задач. П рограмм а gcloud и н и циализирует экзе м пляр публ и ч н ы м и частн ы м I Р-адресом . Вы можете испол ьзовать публ и ч н ы й I Р-адрес с ал горитмом S S H , но программа gcloud имеет полезную оболочку для упрощения входа в систему S S H : $ gcloud compute s sh ulsah L a s t l o gi n : Mon Jan 2 5 0 3 : 3 3 : 4 8 2 0 1 6 u l s ah : — $

6 Выполните команду aws ес2 wai t для получения и нформации об опросе событий или состоян и й в AWS ЕС2.

глава 9. Облачные вычисления

31 7

DigitalOcea n С объя вл е н н ы м временем загрузки 55 с виртуальн ые серверы D igitalOcean (дропле­ ты) — это сам ы й быстрый путь к корневой оболочке . Стоимость начального уровня со­ ставляет 5 долл. США в месяц , поэтому они также н е разорят вас.

m Дополнительную и нформаци ю о настрой ке «драгоценных кам ней» Ruby см. в разделе 7.6. После создания учетной записи в ы можете управлять своим и дроплетами через веб­ сайт DigitalOcean. Тем н е менее нам удобнее прим е н ять буксир, и нструмент ком анд­ ной строки, написанн ы й н а я з ы ке Ruby, которы й испол ьзует опубл и кован н ы й API DigitalOcean. Предположим, что у вас есть Ruby и е го менеджер библиотеки, gem, уста­ новленн ы й в локал ьной системе. Для и нсталляц ии программ ы tugboat просто выпол­ ните команду gem install tugboat. Необходимо выполнить несколько этапов настройки. Сначала создайте пару крипто­ графических ключей , которые вы можете испол ьзовать для контроля доступа к дроплетам . $ s sh-keygen — t rsa -Ь 2 0 4 8 -f / s sh/id rs a do Gene r a t i n g puЫ i c /p ri v a t e r s a k e y p a i r . Ent e r pa s s p h r a s e ( emp t y f o r n o p a s s p h r a s e ) : Ent e r s ame p a s s p h r a s e a g a i n : Your i d e n t i f i c a t i on h a s b e e n s aved i n / U s e r s /be n / . s s h / i d_ r s a_do . Your puЫ i c k e y h a s b e e n s aved in / U s e r s / b e n / . s s h / i d_ r s a_do . pub . «

.

_

_

Скопируйте содержи мое файла откры того кл юча и вставьте е го в веб- консоль DigitalOcean ( в настоящее врем я в разделе Setti n g � Secu rity) . В рамках этого процесса назначьте короткое имя открытому ключу. Затем подключ ите программу tugboat API D igitalOcean, введя токен доступа, кото­ рый вы получите с веб-сайта. П рограмма tugboat сохраняет токен для будущего ис­ пользования в файле » / . tugboat. W Допол нительную и нформацию об ал горитме SSH см. в разделе 22.7. $ tugboat authorize Note : You can get your Acce s s T o ke n f r om h t tp s : / / c l ou d . di g i t a l o c e a n . c om/ s e t t i n g s / t o ke n s / n e w Ent e r y o u r a c c e s s t o k e n : e 9dffla9a7 ffdd8faf3″. f3 7b0 1 5b3d4 5 9 c 2 7 95bб4 Ent e r your SSH key path ( de fa u l t s t o — / . s s h / i d_ r s a ) : » / . s sh/ id_rsa_do Ent e r you r S S H u s e r ( op t i o n a l , de f a u l t s t o roo t ) : Ent e r y o u r S S H p o r t numЬ e r ( op t i ona l , de f au l t s t o 2 2 ) : Ent e r y o u r de f a u l t r e g i o n ( op t i ona l , de f a u l t s to n y c l ) : sfol Aut h e nt i ca t i o n w i t h D i g i t a l Oc e a n wa s s u c ce s s f u l .

Чтобы создать и запустить дроплеты, с начала укажите имя образа систе м ы , которы й в ы хотите использовать в качестве базовой. Например, так. $ tugboat iшages 1 grep — i uЬuntu 16 . 04 16 . 04 16 . 04 16 . 04

.1 .1 .2 .2

х64 х64 х64 х32

( s l u g : , i d : 2 1 6 6 9 2 0 5 , di s t r o : Ubunt u ) ( s l u g : , i d : 2 2 6 0 1 3 6 8 , di s t r o : Ubun t u ) ( s l u g : ubun t u — 1 6 — 0 4 — x 6 4 , i d : 2 3 7 5 4 4 2 0 , di s t r o : Ubun t u ) ( s l u g : ubun t u — 1 6 — 0 4 — x 3 2 , i d : 2 3 7 5 4 4 4 1 , di s t r o : Ubu n t u )

Вам также нужен цифровой идентификатор DigitalOcean для ключа S S H , вставлен­ ного в веб- консоль.

Часть 1. основы администрирования

31 8

$ tuqboat keys SSH Keys : N ame : i d_ r s a_do , ( i d : 1 5 8 7 3 6 7 ) , f i ng e r p r i n t : b c : 3 2 : 3 f : 4 d : 7 d : b 0 : 3 4 : ac : 2 e : 3 f : O l : f l : e l : e a : 2 e : da

Этот вывод показывает, что ч исловой идентификатор для ключа с именем i d- r s a_ d o равен 1 58 7 367. Создайте и запустите дроплеты следующим образом: $ tuqboat create — i uЬuntu — 1 6 — 0 4 -x64 -k 1 5 8 7 3 67 ulsah-uЬuntu queue i n g c r e a t i on o f d r o p l e t ‘ ul s a h-ubun t u ‘ . . . D r op l e t c r e a t e d !

Здесь аргумент -k это идентификатор ключа S S H , а последни й аргумент — корот­ кое и м я для дроплета, которое вы можете назначить по своему усмотрению. Как только дроплет загрузится , вы м ожете войти в систему с помощью команды tugboat ssh. —

$ tuqboat ssh ulsah-uЬuntu D r op l e t f u z z y name p rovi de d . F i n d i n g d r op l e t I D . . . don e , 2 3 7 5 4 4 2 0 ( ub u n t u — 1 6 — 0 4 -x 6 4 ) E x e c u t i n g S S H on D r op l e t ( ub u n t u — 1 6 — 0 4 — x 6 4 ) . . . T h i s d r op l e t h a s а p r iva t e I P , c h e c k i n g i f you a s ke d t o u s e t h e P r i v a t e I P . . . You d i dn ‘ t ! U s i n g puЫ i c I P f o r s s h . . . A t t emp t i n g S S H : r o ot @ 4 5 . 5 5 . l . 1 6 5 W e l c ome to Ubun t u 1 6 . 0 4 ( ( GN U / L i nu x 4 . 4 . 0 — 2 8 — ge n e r i c х 8 6_ 6 4 ) r o o t @ u l s a h — ub u n t u : — #

В ы можете создать столько дроплетов, сколько вам нужно, но имейте в виду, что вам будет выставлен счет за каждый из н их, даже если он выключен . Чтобы отключить дроплет, выполните команду tugboat snapshot имя -дропле та имя — снимка , чтобы сделать сни­ мок памяти систе м ы, и команду tugЬoat destroy имя-дроплета, чтобы отключить дро­ плет. Позднее вы можете воссо:щать дроплет, используя снимок в качестве исходного образа.

9.5. КОНТРОЛЬ ЗАТРАТ Новички в облач н ых вычислениях часто наивно предполагают, что крупномасштабные систе м ы будут значительно дешевле работать в облаке, чем в дата- центре. Это ожидан ие может быть с вязано с превратной интерпретацией низкой стоимости ч аса работы с экзем­ пляром на облачной платформе. Кроме тоrо, возможно, пользователи поддаются уговорам облачн ы х маркетологов, чьи тематические исследования всегда показывают огромную экономию. Независимо от их источн и ка, мы обяза н ы отбросить надеж:ды и оптимизм. По наше­ му опыту, новые пользователи облачных вычислен и й часто уди вляются, когда затраты быстро растут. Тарифы облака обычно состоят из нескольких ком понентов. •

В ы числительные ресурсы виртуальных ч астны х серверов, балансировщиков на­ грузки и всеrо остального, которые потребляют циклы процессора для запус ка ва­ ш их служб. Цена взимается за час использования . Передача данных в И нтернете ( как входящая , так и исходящая ) , а также трафик меж:ду зонами и регионами. Цены взимаются за двоич н ые гига- ил и терабайты. Хран ил и ща всех типов: блочн ые тома хране н и я , объе ктные хран ил и ща , моме н ­ тал ьн ые с н и м ки диска, а в не которых случаях и операции ввода- в ывода в раз­ л и ч н ы х постоя н н ых хранили щах. Взимается цена за каж:дый двоич н ы й гига- или терабайт в месяц.

Глава 9. Облачные вычисления

31 9

Для вычислительн ых ресурсов наиболее дорогостоя ще й я вляется модель » плати или иди» , также известная как » ценообразование по требованию». У AWS и DigitalOcean мини­ мальный и нтервал биллинrа составляет один час, а на GCP м и нута. Цен ы варьируются от долей процента в час (самый маленький тип дроплета DigitalOcean с 5 1 2 Мбайт и одним ЯдРОМ процессора или экземплярами AWS t 2 . nano) до нескольких долларов в час (экзем­ пляр i 2 . 8 x l a rge в AWS с 32 ядрами , ОЗУ 1 04 ГиБ и 8 х 800 Г5 локальных SSD). Вы можете добиться существе н ной экономии н а в и ртуал ь н ы х серверах , заплатив авансом за более длительные сроки. В компании AWS это называется » ценой зарезерви­ рованных экзем пляров » . К сожалению, чтобы точно определ ить, что покупать, необхо­ димо выпол н ить очень тяжелую и дл ительную работу. Зарезервирован ные экзе м пляры ЕС2 привязаны к опр еделе н н ом у семейству экзе м ­ пляров. Если позже вы решите , что в а м н ужно что-то другое , в а ш и и н вести ц и и будут потеряны . С другой стороны , если вы зарезервируете экзе м пл я р , вам гарантируется , что он будет доступе н для вашего испол ьзования. С экзе м плярами по запросу желаем ы й тип может быть недоступен даже при его установке , в за в иси мост и о т текуще й емкости и спроса. AWS продолжает корректировать свою структуру ценообразова н и я , поэтом у, к счастью, нынешняя система может быть упрощена в будущем . Для рабочих нагрузок, которые допускают перерывы , AWS предл агае т точечное цено­ образование. Спот- рынок — это аукцион . Если ваша ставка п ре в ы ш ает текущую с пот­ цену, вам будет предоставл е н тип запраши ваемого вами экзе м пляра, пока цена не пре­ высит максимальную ставку, после чего работа вашего экзе м пляра будет прервана. Цен ы могут быть значительно с н ижен ы п о сравнению с ЕС2 п о требованию и зарезервирован­ ным ценам , но варианты испол ьзования ограниче н ы . Сравнить цен ы на Google Compute Engine достаточно п р ос то . П р и дл ительном и с ­ пол ьзовании автоматически применяются скидки , и в ы н икогда н е будете платить аван­ сом . Вы платите пол ную базовую цену за первую неделю месяца , а и н крем е н т н ая цена падает каждую неделю на 20% от базовой ставки до макс и мальной скидки 60% . Ч истая скидка на пол н ы й месяц ис пользования составляет 30% . Это примерно сопоставимо с дисконтом на оди н год зарезервированного экзе м пл яра ЕС2 , но в ы можете изменять экземпляры в л юбое время.7 Еще более сложно прогнозировать сетевой трафик. Факторы , к оторы е как правило, вызывают высокие затраты на передачу данн ых, включают в себя следующее. —

,

• •

Веб-сайты , которые загружают и обслуживают бол ьшие м ул ьтимедийные файлы (видео, образы , Р D F-файлы и другие крупные доку м е нты) н епоср едс т ве н н о из об­ лака, а не выгружают их в C D N . Межзо н н ы й или межрегиональный трафик для кла стеров баз данных, которые ре­ плицируются для отказоустойчивости; например, программ ное обеспечение, такое как Cassandra, MongoD B и Riak. MapReduce ил и кластер хранилищ данн ых, которые охватывают несколько зон . Образы дисков и с н и м к и томов, передаваем ы е между зона м и или регионами для резервного копирования (или другим автом ат и ч ес к и м процессо м ) .

В ситуациях, когда репли кация между несколькими зонами важна для обеспечения доступности, вы сэкономите на трансферных расходах , огра н и ч и в кл астеры до двух зон , 7Совет для бережливых людей: поскольку схема скидок связана с ва шим билли нrовым циклом, время переходов и меет значение. Вы можете переключать типы экземпляров в н ач ал е или в ко н це цикла без штрафа. Н аихудш и й случай заключается в том , чтобы перекл ючаться на пол пуrи б илл и н говоrо цикла. Эго переключение штрафуется примерно на 20% от меся чной базовой ставки экземпляра .

Часть 1. Основы администрирования

320

а н е испол ьзуя три ил и более. Н е которые программы предлагают такие настройки, как сжатие , которое может умен ьш ить коли чество ре плицирован ных дан н ых. Существен н ы м источ ником расходов на AWS я вляется количество операци й ввода­ вывода ( IO PS) Дll Я томов EBS ( Extemal B LO B Storage). Цены за использование EBS взима­ ются за кол ичество двоичных гигабайтов в месяц и за количество операций I OPS в месяц. Цена за 200 IОайт EBS объемом 5000 IOS составляет несколько сотен долл аров в месяц. Их кластер может разорить компанию. Л уч шая защита от высоких счетов — это измерение , мон итори н г и трезвый расчет. Испол ьзуйте функции автомасштабирования для удаления емкости , когда это не требу­ етс я , сн ижая затраты в периоды н изкого спроса. Используйте более мелкие экзе м пляры дл я более детального управле н и я . Следите за шаблонами ис пол ьзова н и я , прежде чем тратить пакет на зарезервированны е экзе м пляры ил и объем ы с высокой пропускной способностью. Облако я вляется гибким , и вы можете вносить изменения в свою инфра­ структуру по мере необходимости. W Дополнительную информацию об CDN см. в разделе 1 9 . 2 . О кружающая среда ЦС растет, выя вление того, где ден ьги расходуются , может стать проблемой. Больш им облач н ы м учетны м зап исям могут быть полезны сторонние служ­ б ы , которые анализируют испол ьзование и предлагают фун кции отслеживания и от­ четности . М ы испол ьзовал и Cloudabllity и Cloud Health. Оба подкл ючаются к фун кциям выставления счетов AWS для разбивки отчетов по пользовател ьскому тегу, сервису или географичес кому м естоположению.

9.6. ЛИТЕРАТУРА •

Wптю , A N D REлs , A N D М 1 с нлЕ L Wпт ю .

Amazon Web Services /п A ction . M a n ni ng

PuЫications, 20 1 5. •

G ooG L E .

c l o u d p l a t f o rт . g o o g l e Ы o g . с от. Официал ь н ы й блог Google Cloud

Platfonn . •

BAR R , J E F F , AN D OT H E RS АТ Амлzо N WE B S E RV I C E S . a w s . a тa z o n . c oт / Ы o g s / a w s . Официальн ы й блог Amazon We b Se rvices. D ю 1тлLОСЕАN . d i g i ta l o c ea n . coт / c oтpan y / Ь l og . Техн ический и производствен­ н ы й блог DigitalOcean.

А/1 Things Distributed. a l l t h i n g s d i s t r i b u t e d . сот. Блог Вернера Фогельса (Wemer Ьgels) , техн ического директора ком пан ии Amazon .

VoG ELS, WERN ER.

S1мoN . Bits or pieces ? Ы о g . g a rdev i a n c e . org. Блог исследователя и за­ конодателя мод в области облачных технологий Саймона Уордли ( Simon Wardley) , содержащий анализ тенденций в области облачных технологи й , а и ногда и резкую критику. Wл RDLEY,

В 1 л s , RлN DY. c l o u d s c a l i n g . с о т / Ы о g . Рэнди Байес — директор ком пании OpenStack, имеющий инсайдерскую информаци ю об и ндустри и частн ых облаков и е го будущем .

The Observation Deck. d t r a c e . o r g / Ы o g s / Ьт с . И нтересные точ­ ки зрения и технические идеи о вычислен иях технического директора ком пании Joyent, разработавшей специальную, но очень и нтересную платформу. CлNТRJ LL, BRYA N .

А м л zо N .

y o u t u b e . c oт / Aт a z o n W e b S e rv i c e s . В ы ступле ния на конферен циях и другие видеоматериалы от компании AWS.

глава

10

Журналирование

Систе м н ые демоны, ядро, утилиты и приложения — все они генерируют журнальные данн ые , которые ре г истрируются и попадают на дале ко н е безразмерные диски. Срок полезной службы большинства дан н ых о гран и че н , поэтому их приходится групп иро­ вать, сжим ать, архивировать и , наконец, удалять. Доступом и журнал а м и аудита необхо­ димо управлять точно в соответствии с ре гуляти в н ы м и правилами хранения и нформа­ ции или политикой безопасности, принятой для ва ше го хоста. В большинстве случаев ре гистрируемое событие перехватывается в виде одной стро­ ки текста, которая вкл ючает вре м е н ну ю метку, тип и сте п е н ь серьезности события , а также и м я и иде нтифи катор процесса. Систе м н ые адм и нистраторы н есут ответствен ­ ность з а извлечение полезной информации из это го потока сообще н и й . Данная задача называется управлением журналами , и е е можно разделить н а несколь­ ко основных подзадач. • •

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

322

Часть 1. Основы администрирования

Система UNIX исторически упрамяет журналам и через интегрированную, но несколько рудиментарную систему, известную как syslog, коrорая предстамяет приложения со стан­ дартизованным интерфейсом для отправки сообщений журнала. Демон syslog сортирует сообщения и сохраняет их в файлы или пересьтает их другому хосту по сети. К сожалению, sys log решает только первую из перечисленных выше задач регистрации (сбор сообще­ ний), а ее конфи l)’рация сил ьно варьируется среди операционн ых систем. Возможно, из-за недостатков демона sys log м н огие приложе н и я , сетевые де мон ы , с це нарии запуска и другие средства веден ия журнала пол ностью обходят syslog и зап и ­ с ы вают сообщения в свои собственные файлы . Это привело к тому, что в разных версиях U N I X и даже среди дистрибутивов Liпux журнал ы значительно отличаются друг от друга. Журнал sys temd от Linux представляет собой вторую попытку привнести здравомыслие в этот беспорядок. Журнал собирает сообще н и я , сохран яет их в и ндексированном и сжатом двоичном формате и предоставляет и нтерфе йс командной строки для прос мотра и фил ьтра ции жур налов. Журнал может существовать в одиночестве или сосуществовать с демоном syslog с разной степе нью и нтеграции в зависимости от конфигурации . Разнообразные сторонн и е и нструменты ( как запатентованные, так и с открытым ис­ ход н ы м кодом ) затрагивают более сложную проблему отбора сообще н и й , которые по­ ступают из большой сети с и сте м . Эти и н струменты вкл ючают такие вспомогательные средства, как граф ические интерфе й с ы , языки запросов, визуал и зация дан н ых, опове­ щен и е и автоматическое обнаружен и е аном ал и й . Они могут масштабироваться для об­ работки томов сообщен и й порядка терабайт в день. Вы можете подписаться на эти про­ дукты в виде облачной службы или разместить их самостоятельно в частной сети. Н а рис. 1 0. 1 изображе на архитектура сайта, на котором испол ьзуются все службы упрамения журнал ам и , упомянутые в ы ш е . Адм и н истраторы и другие заи нтересован­ ные сторон ы могут запус кать графи ческий и нтерфе йс централ изован ного журнально­ го кластера для прос м отра сообщен и й журнала, поступающих из систе м по всей сети. Администраторы могут также регистрироваться на отдел ьных хостах и получать доступ к сообщен и я м через журнал systemd ил и файл ы обычного текста, зап исанные демоном syslog. Если эта диаграмма вызывает у вас больше вопросов , чем ответов, вы ч итаете правил ьную главу. П р и отладке пробл е м и устра н е н и и о ш и бок опытн ые адм и н истраторы в п ервую оч ередь обращаются к журнал а м . Файл ы журналов часто содержат важные подсказки, указывающие на источ н и к неприятных ош ибок конфи гураци и , ошибок програ м много обес печ е н и я и пробл е м безопасности. Журнал ы — это первое место , которое вы долж­ ны посмотреть, если демон дал сбой или произошел отказ от е го запуска л ибо возникла хрон ическая ош ибка при загрузке с исте м ы . П осле п р и нятия официал ьн ых стандартов, таких к а к PC I DSS, С О В П и I SO 2700 1 , и достижения зрелости регуляторн ых норм в отдел ьных отраслях важность четко опре­ дел е н н о й жур н ал ьной стратегии возросла. В н астоя щее вре мя эти в н е ш н и е стандарты могут потребовать, чтобы для веден и я журнала вы поддерживал и централ изован н ы й репозитарий предприятия с вре м е н н ы м и меткам и , подтвержден н ы м и протоколом N TP ( N etwork Тime Protocol) и строго определ е н н ы м граф и ком хранен ия . 1 Однако даже ор­ га н и зац и и , не и меющие нормативных требований или требован и й соответстви я , могут извлечь вы году из централ изованного веден ия журналов. 1 Конеч но, точ ное систем ное время и меет значение даже без н ал и ч и я ре гуляторных норм. Мы настоятел ьно рекомендуем включить протокол NTP дЛЯ всех ваш и х систе м .

Глава 1 О. Журналирование

323

Система Linux Источники журналов

Apache httpd SSH NTP cron другие…

systemd-journal

syslog

Двоичный журнал

Обычные текстовые файлы

Система FreeBSD Источники журналов

syslog

Apache httpd SSH NTP cron другие…

Обычные текстовые файлы

Централизованный кластер журналов

Рис. 10. 1. Архитектура централизованной журнальной системы

В этой гл аве описы вается собстве н н ое програм м н ое обес п еч е н ие для управл е ­ н ия журналам и , используемое в системах Li nux и Free B S D , в кл ючая syslog, журнал sys temd и приложение logrotate. М ы также вводим некоторые допол н ительные и н ­ струменты для централ и зации и анал иза журналов по всей сети . Глава закрывается н е ­ которы м и общими советами для создания разумной пол итики управления журналом .

1 0. 1 . МЕСТОПОЛОЖЕНИЕ ФАЙЛОВ РЕГИСТРАЦИИ Систему U N IX часто критикуют з а несогласован ность, и эта крити ка впол н е спра­ ведл и ва. П осмотрите на содержимое каталога файлов ре гистраци и — вы обязател ьно н айдете файл ы с таки м и и м е нам и , как ma i l log, cron . log и, возможно, еще нечто спе цифичное для демонов и дистрибутивов. По умолчанию бол ь ш инство этих фа йлов хран ится в каталоге /var/adm или /var/log, но некоторые приложения разбрас ы вают журнальные файлы по файловым системам. В табл . 1 0. 1 представлена информация о наиболее часто испол ьзуе м ых журнальных файлах демонстрацион ных дистрибутивов. Указа н ы , в частности , следующие сведения: •

журнал ьные файл ы , подлежащие архи вированию ил и другой обработке;

программа, создающая каждый из этих файлов ;

информация о том , где задается имя файла;

• •

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

Имена файлов в табл. 1 0. дан ы относительно каталогов, /var/log, если не указано и ное. М н огие журнал ьные файлы из числа перечисленных в табл . 1 0. 1 контролируются систе мой Syslog , а остал ьные — приложения м и .

Часть 1. Основы администрирования

3 24

Табл и ца 1 0 . 1 . Журнальные файлы ФаАл

Проrрамма

Место» Ч астота• СистемЫ» Содерасимое/наэн ачение

apache2 / *

httpd АРТ

д м

D D

Журналы НПР-сервера Арасhе (версия 2)

apt*

ф ф s ф ф

м м

DF R

Авторизационные сообщения

s

н

RA

Сведения о выполнении и об ошибках демона сrоn

s

н

D*

Все сообщения средств демона

s в ф н

д

auth . log

sudo и дp.6

boot . loq

Сценарии rс

cloudini t . log

cloud-init

cron, cron/ cron log daemon . Различные loq ceЬuq* Различные dmesq Ядро

Программы для инсталляции программных пакетов Выходная информация сценариев запуска Выходная информация сценариев запуска облаков

F, D*

Отладочные сообщения

все

Образ буфера сообщений ядра

м н

u

Журнал управления пакетом

D*

Сообщения о неудачных попытках регистрации в системе

ф s в

д н

R D R

Журналы НПР-сервера Apache

mail*

Связанные с элек- s тронной почтой

н

RF

Все сообщения средств электронной

messaqes

Различные

Основной системный журнальный файл

smЬd и др.

н н

R

saJDЬa/ *

s ф

secure

sshd и дp.6

s

м

R

Конфиденциальные авторизационные сообщения

suloq

su

ф

SAH

Учет удачных и неудачных попыток использования команды su

sysloq*

Различные loqin

s в

н м

D RD

Основной системный журнальный файл

wtmp

xen/*

Хеп

ф

1m

RD

ф

н

R

dpkq . loq

dpkq

failloq»

loqin

httpd/ *

httpd

kern . loq

Ядро loqin

lastloq

Xorq . n . loq Xorq

Все сообщения средств ядра Время последней регистрации в системе каждого пользователя (бинарный файл) ПОЧ1ЪI

SamЬa (совместное использование файлов в системах Wпdows/SMB)

Сообщения о регистрации в системе (бинарный файл) Информация от монитора виртуальных ма ш и нах Хе п Сообщения об ошибках сервера

X W пdows yum . loq

yum

ф

м

R

Журнал управления пакетом

‘ Здесь используются следующие обозначения: в столбце «Место» : Ф — конфигурационный файл , В — встроенный, S — Syslog , в столбце «Частота»: Д — ежедневно, Н — еженедельно, М — ежемесячно, Nмn — зависит от размера ( например, 1 m — мегабайт) , в столбце «Системы» : D — Deblan и Ubuntu , D* — только Deblan, R — Red Hat и CeпtOS, F — FreeBSD . б Команды

pas swd, s shd, login и shutdown тоже записывают информацию в журнал авторизации.

‘Двоичный файл, который должен быть прочитан с помощью утилиты faillog.

Глава 1 0. Журналирование

325

Журнал ьн ы е файл ы обы чно п р и надл ежат пол ьзовател ю r o o t , хотя соглаш е н и я о владел ьцах и режимах доступа к эти м файлам н е оди наковы в разных систе мах. В не­ которых случаях менее привилегированный де мон (такой как httpd или mysqld) может потребовать доступ для записи, а затем определ ить ее владел ьца и режим работы соот­ ветственно. Вам , возможно, для просмотра важн ых журнальных файлов, которые имеют строгие разрешения доступа, придется испол ьзовать команду sudo. m Дополнительную информацию о разделении диска см. в разделе 20 . б . Журнальные файлы могут очен ь быстро увел ичи ваться в размере , особенно это каса­ ется файлов для службы электронной почты , веб- и D N S -cepвepoв. Н е контролируе м ы й файл регистрации может запол н ить весь диск и тем сам ы м вы вести с истему из строя . Поэтому м ы п редпочитае м определять раздел /var/ 109 как отдел ьный раздел диска или отдел ьную файловую систему. (Этот совет одинаково полезен как для облач ных эк­ земпляров, и частн ых виртуал ьн ых маш и н , так и для физических серверов.)

Специал ьные журнальные фа йл ы Бол ьш и нство журнал ьных файлов — это обычные текстовые файл ы , в которые запи­ сываются сообщения о » важных» событиях. Но не которые файл ы из числа перечислен­ ных в табл . 1 0. 1 имеют совершенно другое назначение. Файл wtmp (иногда wtmpx) содержит зап иси о том, когда пользователи входил и в систе­ му и выходили из нее, а также когда система выкл ючалась или перезагружалась. Это до­ вольно простой файл (новые записи просто добавляются в конец), тем не менее он хранится в бинарном виде. Расшифровать содержимое файла можно с помощью команды last. В файле lastlog регистрируется время последнего входа в систему каждого пользовате­ ля. Это разреженный бинарн ый файл, записи которого индексируются по идентификатору пользователя U I D. Размер файла будет меньше, если назначать идентификаторы по поряд­ ку, хотя вряд ли об этом стоит сильно беспокоиться. Файл las tlog не должен участвовать в цикле ротаци и , поскольку его размер в больш инстве случаев остается неизменным. Кроме того, некоторые приложения (особе нно базы дан н ых) создают двоичные фай­ лы транзакций. Н е п ытайтесь управлять эти ми файлами и даже просматри вать их, иначе терминал ьное окно выйдет из строя.

Ка к п росмотреть зап иси

в

журнале sys temd

В с истемах Linux, в которых ведется журнал sys temd, сам ым простым и легким спо­ собом просмотра записей я вляется команда j ournal ctl , которая вы водит на экран сообще ния из журнала sys temd. С ее помощью можно прос мотреть все записи в жур­ нал е ил и , указав флаг -u, сообщения, касающиеся конкретного служебного модуля. Сообщения можно фил ьтровать и устанавл ивать другие огран иче н и я , такие как интер­ вал времени, идентификатор процесса и даже путь к конкретному выполняемому файлу. Например, следующая выходная информация извлечена из зап исей журнала о демо­ не S S H : —

$ j ou rna l c tl — u s sh — — Logs begin a t S a t 2 0 1 6- 0 8 — 2 7 2 3 2 3 : 3 3 : 2 0 uтс . — Aug 2 7 2 3 : 1 8 : 2 4 u x en i a l s s hd [ 2 2 3 0 ] Au g 2 7 2 3 : 1 8 : 2 4 u x e n i a l s s hd [ 2 2 3 0 ] Aug 2 7 2 3 : 1 8 : 2 4 u x e n i a l s y s temd [ l ] Aug 2 7 2 3 : 1 8 : 2 4 uxe n i a l s y s temd [ l ]

: 1 8 : 1 7 uтс , : : : :

end at S a t 2 0 1 6 — 0 8 — 2 7

S e rver l i s tening o n О . О . О . О port 2 2 . S e rve r l i s t e ning on : : p o r t 2 2 . S t a r t i n g S e c u r e S he l l s e r ve r . . . S t a r t e d Ope n B S D S e c u r e S h e l l s e rve r .

Часть 1. Основы администрирования

326

Aug 27 2 3 : 1 8 : 2 8 uxe n i a l s s hd [ 2 3 2 6 ] : Ac c e p t e d p uЫ i c ke y for bwh a l e y f rom 1 0 . 0 . 2 . 2 p o r t 6 0 3 4 1 s s h 2 : RSA S HA2 5 6 : a a R f G d 1 0 u n t n 7 5 8 +UCpx L 7 g kS w c s z kAYe / w u k r dBATc Aug 27 2 3 : 1 8 : 2 8 uxen i a l s s hd [ 2 3 2 6 ] : pam_un i x ( s s h d : s e s s i on ) : s e s s ion op e n e d f o r u s e r bwh a l e y Ь у ( ui d = O ) Aug 2 7 2 3 : 1 8 : 3 4 ux e n i a l s s h d [ 2 4 8 0 ] : D i d n o t r e c e ive i d en t i f i c a t i on s t r i n g f r om 1 0 . 0 . 2 . 2

С помощью команды j ournalctl — f можно выводить на экран новые сообще н ия по мере их постуШiения. Это эквивалент л юбимой команды tail -f, позволяющей сле­ дить за добамяемыми текстовыми файлами по мере их постуШiения. В следующем разделе мы рассмотрим демон systeшd-j ournald и его конфиrурацию.

1 0.2. ЖУРНАЛ

SYSTEМD

Журнал sys temd долже н б ыл заме н ить все остал ьные подс исте м ы Linux и поэтому он содержит демон регистрации с именем systemd — j ournald. О н выпол няет больши нство функци й , связа н н ых с регистрацией событи й , в зависимости о т конфигурации систе м ы . Есл и в ы сомневаетесь. стоит л и переходить на systemd, потому что syslog и так делает все , что вам нужно, пос вятите н е м ного времени изуч е н и ю возможностей sys temd. После этого вы убедитесь в его преимуществах. В отл ичие от системы syslog, которая обычно сохраняет сообщения журнала в тек­ стовых файлах, журнал systemd хранит сообщения в двоичном формате . Все атрибуты сообщен и й индексируются автоматическ и , что делает журнал проще и быстрее для по­ иска. Как обсуждалось выше, вы можете испол ьзовать команду j ournalctl дл я про­ смотра сообще н и й , хранящихся в журнале. Журнал собирает и индексирует сообщения из нескол ьких источн и ков. •

Сокет /dev/log для сбора сообщений от программного обеспечен и я , отпрамяю­ щего сообщения согласно соглашениям систе м ы Syslog. Файл устройства /dev/Шsg для сбора сообщений от ядра Linux. Журнал ьн ый де­ мон systemd заменяет традицион н ы й процесс klogd, который ранее прослуш и­ вал этот канал и п еренапрамял сообщения от ядра в систему Syslog. Сокет U N IX / run/ sys temd/ j ournal / s tdout для обслуживания програ м м н ого обеспечения, которое записывает сообщения журнала в стандартн ый вывод. Сокет U N IX / run/ systemd/ j ournal для сервисного программного обеспечения , отпрамяющего сообщения через API журнала systemd. Сообщения аудита от демона ядра audi td.

Смелые адм и н истраторы моrут испол ьзовать утил иту systemd — j ournal — remo te (и ее аналоги , sys temd — j ournal-gateway и systemd — j ournal-upload) для потоко­ вой передач и сериал изованных сообще н и й журнала по сети в удал е н н ы й журнал . К со­ жал е н и ю , эта фун кция не постамяется предуста новлен ной в обычн ы х дистрибути вах. На момент написания дан н ого те кста эти пакеты б ыл и доступн ы дл я систем Deblan и Ubuntu, но не для Red H at или CentOS. Мы ожидаем , что в ближайшее время эта ситу­ ация будет испрамена; тем временем мы рекомендуем придерживаться с исте м ы Syslog, если вам нужно пересьшать сообще ния журналов между системами .

Глава 1 о. Журналирование

327

Настройка журнала sys temd Конфигурацион н ы й файл журнала ло умолчан и ю / e t c / sys temd / j ournald . conf; однако этот файл не предназначе н для прямого редактирования . Вместо этого до­ бавьте свои настроен н ые конфигурации в каталог / etc/ sys temd/ j ournald . conf . d. Л юбые файл ы , размещен н ые там с рас ш ирением . con f , автоматически вкл ючаются в конфи гурацию. Чтобы настроить собствен н ые параметр ы , создайте в этом каталоге новый файл с расш ирением conf и вкл ючите н ужные параметры. П о умолчан и ю файл j ourna ld . conf содержит п роком м е н т и рова н ную верс и ю каждой возможной опци и , а также знач е н и е по умолчан и ю каждо го параметра, п о ­ этому вы �.tожете сразу увидеть, ка кие о п ц и и доступ н ы . О н и в кл ючают в себя м а к ­ симал ь н ы й размер жур нал а , период хран е н ия сообще н и й и разл и ч н ы е огран и ч е н и я скорости . Опция S t o ra g e определяет, следует ли сохранять журнал на диск. Возможные зна•1е­ ния н есколько сбивают с толку: —

.

• •

vo l a t i l e сохраняет журнал только в памяти . pe r s i s t e n t сохраняет журнал в каталоге /var/ log/ j ournal / , создавая его при необходи мости. auto сохраняет журнал в каталоге /var/ log/ j ournal / , но не создает каталог. Это значение по умолчанию. none удаляет все данные журнала.

Большинство дистрибутивов Linux (вкл ючая все наши примеры) по умолчани ю ис­ пол ьзуют значение a u t o и содержат каталог /var/ l og/ j ourna l . Следовательно, жур­ нал не сохраняется между перезагрузками по умолчанию, что я вляется неудачн ы м . В ы можете измен ить это поведе н и е л и бо путе м создан и я каталога / v a r / l og / j ournal , л ибо путем обновления журнала для испол ьзования постоя н ного хранил и ща и перезапуска systemd- j ournald: # mkdir /etc/ sys temd/ j ournald . conf . d/ # cat /etc/ sys temd/ j ournald . conf . d/ s torage . conf [ Journal ] Storage=pers i s tent

END # sys temctl res tart sys temd- j ournald

Эта серия команд создает настраи ваем ы й каталог конфигурации j ournald . conf . d, создает файл конфигураци и , чтобы установить параметр S t o ra g e равным p e r s i s t e n t , и перезапус кает журнал , чтобы новые настройки вступ ил и в силу. Демон sys temd ­ j ourna ld теперь создаст каталог и сохран ит журнал . М ы рекомендуем выпол н ить это изме нение для всех систем; было бы очень обидно терять все данн ы е журнала при каж­ дой перезагрузке системы. Одн и м из самых неожиданн ых параметров журнала я вляется S e a l , что позвол яет систе ме Forward Secure Sealing ( FSS) повысить целостность сообще н и й журнала. П р и вкл ючен ной системе FSS сообще ния , отправленные в журнал , не могут быть изме н е ­ ны без доступа к паре кри птографических кл ючей. Вы сам и генери руете пару ключе й , выпол н и в команду j ournal ctl — — setup — keys . Обратитесь к справоч н ы м стран и цам для файла j ournald . conf и команды j ournalctl , чтобы увидеть пол н ы й обзор этой опци и.

328

Часть 1. Основы администрирования

Доба вление дополн ительных параметров фильтрации для журнала В кон це разделе 1 0. 1 . м ы привели короткий пример поиска журнала с помощью ко­ манды j ournal ctl . В этом разделе мы покажем несколько допол н ительных способов испол ьзования команды j ournalctl для фильтрации сообще н и й и сбора информации о журнале. Для того чтобы нормальные пользовател и могл и ч итать из журнала без необходимых разрешений sudo, добавьте их в группу U N lX s y s t emd — j o u rna l . Опция -di sk-usage показывает размер журнала н а диске. # j ournalctl — -disk-us age J o u r n a l s t a ke up 4 . ОМ on di s k .

П араметр — l i s t -boots показывает посл едовател ьный список с исте м н ы х загрузок с числовы м и идентифи катора м и . Самая последняя загрузка всегда и меет идентифика­ тор, равн ый О. Даты в конце строки показы вают временные метки первого и последне го сообще н и й , с генерирован ных во время этой загрузки. # j ournalctl — — l i s t-boots — 1 с е О . . . Sun 2 0 1 6 — 1 1 — 1 3 1 8 : 5 4 : 4 2 UTC -Mon 2 0 1 6 — 1 1 — 1 4 0 0 : 0 9 : 3 1 о 8 4 4 . . . Mon 2 0 1 6 — 1 1 — 1 4 0 0 : 0 9 : 3 8 UTC -Mon 2 0 1 6 — 1 1 — 1 4 0 0 : 1 2 : 5 6

Вы можете использовать опцию -Ь, чтобы ограничить отображен и е журнала опреде­ л е н н ы м сеансом загрузки . Например, для просмотра журналов, сгенерирова н н ых ал го­ ритмом SSH во время текущего сеанса: # j ournalctl -Ь О -u s sh

Для того чтобы показать все сообще н и я , начи ная с прошлой пол ноч и до сегодняш­ него дня, выполн ите команду: # j ournalctl — — s ince=yes terday — -unti l=now

Для того чтобы показать последн ие 1 00 зап исей журнала из определен ного двоично­ го файла, выпол н ите команду: # j ournalctl -n 1 0 0 /usr/ sbin/ s shd

Дл я п ол уч е н и я краткой с п р а в к и об этих а р гу м е н тах и с п ол ьзуйте команду j ournalctl — -help.

Совместное использова ние с системой Syslog К а к система Syslog , т а к и журнал sys temd по умолчан и ю актив н ы для каждой из наших демонстрационных с истем Linux. Оба пакета собирают и сохраняют сообщения журнала. Зачем нужно, чтобы оба они работали , и как это сделать? К сожал е н и ю , в журнале отсутствуют м ногие функции , доступн ы е в системе Syslog. Как будет показано в разделе 1 0. 3 , с истема rsyslog может получать сообще н и я от раз­ л ичных входных допол нительных модулей и перенаправлять их на разнообразный набор выходов в соответствии с фил ьтрами и правила м и , которые невозможны , есл и исполь­ зуется журнал sys temd. В среде sys temd существует и нструмент удал е н ного потока, sys temd — j ournal — remote , но он относительно новы й и не сравни вался с систе мой Syslog. Адм и н истраторам также может быть удобно хран ить определ е н н ы е файлы жур­ налов в виде обычного текста , как это делает систе ма Syslog, а не в двоичном формате журнала.

Глава 1 о. Журналирование

329

М ы ожидае м , что с о временем новые функции в журнале узурп и руют обязан ности системы Syslog. Н о на дан н ы й момент дистрибутивам Linux по-прежнему необходимо запустить обе системы для достижения пол ной функциональности. Механ и ка взаимодействия между журналом sys temd и системой Syslog несколько запутанна. Н ачнем с того, что демон systemd- j ournald берет на себя ответственность за сбор журнал ьн ых сообщен и й из /dev/log, сокета протоколирова н и я , который исто­ рически контрол ировался системой Syslog.2 Для того чтобы с истема Syslog могла выпол ­ нить регистрацию, о н а должна получ ить доступ к потоку сообще н и й через систе м н ы й менеджер sys temd. Система Syslog может извлекать сообщен ия из журнала двумя с по­ собам и . •

Журнал sys tem.d может перес ылать сообщен ия другому сокету (обычно / run / sys tem.d/ j ournal / syslog ) , из которого демон систе м ы Syslog может их читать. В этом режиме демон system.d- j ournald им итирует исходны х отправителей со­ обще н и й в соответствии со стандартн ы м A P I с исте м ы Syslog. Следовател ьно, пе­ ренаправляются только основные параметры сообще н и я ; некоторые метаданные, специфич ные для систе м ы , теря ются. В качестве альтернати вы с исте ма Syslog может обрабаты вать сообще ния непо­ средстве нно из и нтерфейса прикладного програ м м ирован ия журнал а таким же образом, как и команда j ournalctl. Этот метод требует я вной поддержки сотруд­ н ичества со сторон ы syslogd, но это более полная форма и нтеграци и , которая сохраняет метаданные для каждого сообщения.3

СистеМ1>1 Deblan и Ubuntu по умолчанию используют преж ний метод, но Red Hat и CentOS ис пол ьзуют послед н и й . Чтобы определить, какой тип и нтегра ц и и был на­ строен в ваш е й с исте м е , проверьте о п ц и ю ForwaгdToSyslog в файле / e t c / s y s tem.d/ j ournald . conf. Есл и его значение равно ye s , испол ьзуется переадресация сокетов.

1 0.3. С истЕмА SvsLoG Syslog это пол нофун кционал ьная с и стем а регистрации событи й , нап исан ная Эриком Олл маном ( Eric Allman ) , и стандартн ы й п ротокол регистра ц и и событи й , ут­ вержде н н ы й I ETF.4 Она выполняет две важные фун кции : освобождает программ истов от утом ител ьной механ ической работы по веде н и ю журнал ь н ы х файлов и п ередает управление журнальной регистрацией в руки адми н истраторов. До поя вл е н ия систе м ы Syslog каждая программа сама выбирала схему регистрации событий , а у системных ад­ министраторов не было возможности контрол ировать, какая и нформация и где именно сохраняется. Система Syslog отличается высокой гибкостью. Она позволяет сортировать сообще­ ния по источ н и кам (facility) и уровню важности (severity) и направлять их в разл ичные пун кты назначения: в журнальные файл ы , на терминал ы пол ьзователе й и даже на дру­ гие ком пьютеры. Одной из самых цен н ы х особенностей этой систе м ы я вляется ее спо­ собность централ изовать процедуру ре гистрации событий в сети . —

2 Точнее, ссылки журнала из /dev/log в / run/ sys temd/ j ournal/dev- log . 1 Краткое описание досту п н ых метада н н ых с м . на с п равоч ной стран и uе s y s temd . j ourna l ­ fields .

•последняя по времени версия спецификации системы Syslog RFC5424, но п редыдущая версия, RFCЗ 64, луч ше отражает реальную инсталлирован ную систему. —

Часть 1. Основы администрирования

330

В с истемах Linux исходный демон систе м ы Syslog (syslogd) был заменен более но­ вой реал изацией , назы вае мой Rsyslog (rsys logd) . Rsyslog — проект с открытым исход­ н ы м кодом , который рас ш иряет возможности исходной систе м ы Syslog, но поддержива­ ет обратную совмести мость с интерфейсом прикладного программ и ро ван ия. Это сам ый разу м н ы й выбор для адм и н и страторов , работающих в совре м е н н ы х с истемах U N IX и Linux, и это единственная версия Syslog, которую м ы рассмотри м в этой главе . Систе ма Rsyslog доступна для Free B S D , и м ы рекомендуем вам прин ять ее, а не стандартный систе м н ы й журнал Free B S D , если у вас нет простых тре ­ бован и й . И нструк ции по преобразованию системы Free B S D для испол ьзован и я демона rsyslog содержатся по адресу w i k i . r s y s l o g . с от / i nd e x . php / FreeB S D .

Есл и в ы решите придержи ваться традиционной системы s y s l o g в операционной с и ­ стеме Free B S D , перейдите в раздел «Синтаксис sysklogd» для получ е н ия и нформации о конфи гурации .

Ч тение сооб щ ени й си сте м ы Syslog П ростые сообщ е н и я с исте м ы Syslog можно ч итать с помощью и н струм е нтов с и ­ стем U N IX и Linux для обработки те кста , например команд grep , l e s s , cat и awk. П р и веде н н ы й н иже фрагмент кода де монстрирует сообще н и я о т и п и ч н ы х со б ытиях в жур нале /var/ log/ eyelog, поступ ившие от хоста системы Deblan. j e s s i e # cat /var/ log/ sysloq Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e ne two r k i ng [ 2 4 4 ] : bound t o 1 0 . 0 . 2 . 1 5 — renewal i n

4 2 0 9 3 s e conds . Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e s t a t d i dm ap d . Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e Jul 16 1 9 : 4 3 : 0 1 j essie

rpcb i nd [ 3 9 7 ] : S t a r t i ng rpcb i n d daemon . . . . n f s c omm on [ 4 1 2 ] : S t a r t i n g NFS c ommon u t i l i t i e s : —

c r on [ 4 3 6 J : ( C RON ) I N FO ( p i d f i l e fd 3) c r on [ 4 3 6 ] : ( C RON ) I N FO ( Ru n n i n g @ r e b o o t j ob s ) acpid : s t a r t i ng up w i t h ne t l i n k and t he i n p u t l a y e r docke r [ 4 8 6 ] : t ime = » 2 0 1 6 — 0 7 1 6 T 1 9 : 4 3 : 0 1 . 9 7 2 6 7 8 4 8 0 Z » l e ve l = i n fo ms g = » Da emon h a s comp l e t e d ini t i a l i zation» J u l 1 6 1 9 : 4 3 : 0 1 j e s s i e doc k e r [ 4 8 6 ] : t ime = » 2 0 1 6 — 0 7 1 6T l 9 : 4 3 : 0 1 . 9 7 2 8 9 6 6 0 8 Z » l e ve l = i n fo m s g = » Do c ke r da emon » c ommi t= c 3 9 5 9Ы e x e c d r i v e r=n a t ive 0 . 2 g r a p h d r i ve r = a u f s ve r s i on= l . 1 0 . 2 Jul 1 6 1 9 : 4 3 : 0 1 j e s s i e doc ke r [ 4 8 6 ] : t i me= » 2 0 1 6 — 0 7 1 6T 1 9 : 4 3 : 0 1 . 9 7 9 5 0 5 6 4 4 Z » l e ve l = i n f o ms g = » A P I l i s t e n o n / v a r / ru n / d o c ke r . s o c k » =

Этот п р и м е р содержит сооб ще н и я , посту пив ш и е от нескол ьких разных де монов и п одсистем : сети , NFS, aron , D ock er и демона управл е н ия питан ием acpid. Каждое сообщение содержит следующие поля , разделен ные пробелам и. •

Времен ная метка.

Систе м ное и м я хоста , в да нном случае j e s s i e .

И м я п роцесса и его идентификатор в квадратных скобках.

Полезная нагрузка сообщен и я .

Глава 1 о. Журналирование

331

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

А рхитектура системы Rsyslog Сообще н ия журнала можно представить как поток событий, а с истему Rsyslog — как механ изм обработки потока событий . Журнальные сообщен ия , которые и нтерпретиру­ ются как события , представляются в виде входов , обрабатываются фил ьтрами и пере­ сылаются по ацресу назначения . В с истеме Rsyslog каждый из этих этапов является кон ­ фигурируе м ы м и модул ьн ы м . По умолчан ию система Rsyslog настроена в файле /etc/ rsyslog . conf. П роцесс rsy s l ogd обычно запус кается при загрузке и в ы полняется н е п рерывно. Програ м м ы , которые известн ы системе Syslog , заносят записи журнала в специальный файл /dev/ log, сокет домена U N IX. В конфигураци и систем без демона sys temd де­ мон rsyslogd напрямую считывает сообщения из этого сокета , консул ьтируется с его конфигурационн ы м файлом для руководства по их маршрутизации и отправляет каждое сообщение в соответствующее место назначения. Также можно (и желательно) настраи ­ вать демон rsyslogd для прослуш и вания сообщен и й в сетевом сокете. Есл и вы изменяете файл /etc / r sys log . conf ил и л юбой из его вкл юче н н ых фай­ лов, то должн ы перезапустить демон rsys logd, чтобы ваши изменения вступили в силу. Сигнал T E RM прекращает работу демона. Сигнал HU P заставляет демон rsyslogd закры­ вать все открытые файл ы журналов, что полезно для ротации ( пере и менования и пере­ запуска) журналов. По сложившейся трациции демон rsyslogd записывает свой идентификатор процесса в файл /var/run/syslogd . pid, поэтому послать сигнал из сценария в процесс rsyslogd не составляет труда.5 Например, следующая команда посылает сигнал зависания. $ sudo kill -НUР ‘ /bin/cat /var/run / sys loqd . pid ‘

Поп ытка сжать или выпол н ить ротацию журнал ьного файла, который был открыт демоном rsyslogd для зап иси, — плохая идея, которая приводит к непредсказуемым резул ьтатам , поэтому перед эти м обязател ьно отправьте сигнал H U P . И н формацию о правил ьной ротации журнала с помощью утилиты logrotate см. в разделе 1 0.4.

Версии Rsyslog Систе м ы Red H at и CentOS используют Rsyslog версии 7 , а Deblan и Ubuntu обновле­ н ы до версии 8. Пользователи Free B S D , устанавливающие с исте му из портов, могут вы­ брать л ибо верс и ю 7, либо 8 . Как и следовало ожидать, в проекте Rsyslog рекомендуется испол ьзовать самую последн юю версию, но мы не следуем эти м советам . Тем не менее, есл и ваша операцион ная система я вляется самой современ ной , это не повл ияет на ваш опыт ведения журнала. Версия Rsyslog 8 я вляется основным переработанным вариантом основного механиз­ ма, и, хотя в его устройстве м ногое изменилось с точки зрения разработчи ков модулей, аспекты , обращенные к пользователю, остаются в основном неизменными. За некоторы­ м и исключениями, конфигурации в следующих разделах действительны для обеих версий. 5 В современных версиях системы I.inux /var/ run является символической ссылкой н а / run.

332

Часть 1. Основы администрирования

К онфигурация Rsyslog Поведе н ие демона rsyslogd контролируется настрой ками в файле /etc/ rsyslog . conf. Все н аш и примеры дистрибутивов Linux включают в себя простую конфигураци ю с разум н ы м и значениями п о умолчани ю , которые подходят бол ьшинству организаций . Пустые строки и строки , начинающиеся с символа # , и гнорируются . Строки в конфигу­ рации систе м ы Rsyslog обрабатываются в порядке от н ачала до кон ца, а порядок имеет значение. В верхн е й части файла конфигурации находятся глобальные свойства, которые на­ страивают сам дем о н . В этих строках указа н ы загружаем ы е модул и , формат сообще­ н и й по умолчан и ю , п рава собствен ности и разрешения файлов, рабоч и й каталог, в ко­ тором можно сохранить состоян и е систем ы Rsyslog, и другие параметр ы . Следующая примерная конфигурация адаптирована из стандартного файла rsyslog . conf в вер­ сии Deblan Jessie. # Поддержка л о к а л ь н о й с и с т емы р е г и с т р а ции $ ModLoad imux s o c k # Поддержка р е ги с т р а ции ядра $ ModLoad imkl o g # Выводи т ь с о о бще ния в тр адици онном форма т е с временными мет ками $ Ac t i on F i l e D e f a u l t T e mp l a t e R S Y S L OG_T r a d i t i on a l Fi l e Fo rmat # Н о в ым файлам р е г и с т р ации н а з н ач а е т с я владелец r oot : a dm $ Fi l e 0wne r r o o t $ Fi l e G r oup a dm # С т андартны е пра в а д о с тупа дл я в н о в ь с о з данных файлов и к а т а л о г о в $ Fi l e C r e a t eMode 0 6 4 0 $ Di r C r e a t eMode 0 7 5 5 $ Uma s k 0 0 2 2 # К а т а л о г , в к о т о р ом х р а н я т с я р а б очие файлы r s y s l og $ W o r kDi r e c t o r y / va r / s p o o l / r s y s l o g

Большин ство дистрибутивов испол ьзуют устаревшую директиву $ I n c l ud e C o n f i g для вкл ю ч е н и я допол н ител ь н ы х файлов и з каталога конфигураци и , обы ч н о / e tc / rsyslog . d/ * . conf. Поскольку порядок важе н , дистрибутивы организуют файлы с по­ м ощью п редшествующих имен файлов с номерами . Например, конфигурация Ubuntu по умолчанию включает следующие файл ы : 2 0 -ufw . conf 2 1 — cloudini t . conf 5 0 — defaul t . conf

Система Rsyslogd и нтерполирует эти файлы в файл /etc/rsys log . conf в лексико­ графическом порядке , чтобы сформировать окончательную конфигурацию. Ф ил ьтр ы , иногда называемые селекторами , составляют основную часть конфигура­ ции систе м ы Rsyslog. Они определя ют, как с исте ма Rsyslog сортирует и обрабаты вает сообще н и я . Фильтры формируются из в ыраже н и й , выбираются конкретные критерии сообщений и действия , которые направляют выбранные сообщения в нужное место на­ значения.

Глава 1 0. Журналирование

333

Система Rsyslog понимает три синтаксиса конфигурации. •

Строки, испол ьзующие формат исходного файла конфигура ц и и с истем Syslog. П осле появления демона регистрации ядра sysklogd этот формат известен как «формат sysklogd » . О н прост и эффективен , но и меет некоторые ограничения. Ис пол ьзуйте е го для создания простых фильтров. Устаревшие директивы системы Rsyslog, которые всегда начинаются с знака $. И х с интакси с уходит корн я м и в старые версии с истем Rsyslog и действительно дол­ жен быть признан устаревш и м . Однако не все опции бьm и преобразованы в новый с интаксис, и поэтому этот с интаксис остается важны м для н екоторых фун кций. С интаксис RainerScript , назва н н ы й в честь Райнера Герхардса ( Reiner Gerhards) , ведущего автора систе м ы Rsyslog. Это с интаксис сценариев, который поддержи­ вает выражен и я и функции. Вы можете использовать е го для настройки большин­ ства, но н е всех аспектов с истемы Rsyslog.

М н огие конфигурации в реальном мире вкл ючают в себя сочетание всех трех фор­ матов, иногда с запутанным эффектом. Хотя синтаксис RainerScript существует с 2008 r. , он все еще испол ьзуется нем ного реже других. К счастью, н и оди н и з диалектов н е яв­ ляется особен но сложны м . Кроме того , н а м ногих сайтах н е придется делать крупную операцию по простым конфигурациям , включенным в их распределение ресурсов. Для того чтобы перейти из традиционной конфигураци и Syslog, просто начните с су­ ществующего файла syslog . conf и добавьте параметры для функций с исте м ы Rsysog, которые вы хотите активировать.

Модули Модули систем ы Rsyslog расш иряют возможности основного механизма обработки . Все входы (источн ики) и выходы (адресаты) н астраиваются через модул и , а модули мо­ гут даже анализировать и изменять сообщен ия . Хотя большинство модулей были н ап и ­ саны Рай нером Герхардсом , некоторые из н их были внесен ы третьим и лицами . Если в ы програм м ист на языке С , то можете написать свой собствен н ы й . И мена модулей соответствуют предсказуемому префиксному ш аблону. Те , которые нач инаются с префикса im, являются модулями ввода; om* модули вывода, mm* мо­ дули модификации сообщен и й и т.д. Большинство модулей и меют допол нительные па­ раметры конфигурации , которые настраи вают и х поведение. Докуме нтаци я о модулях с исте м ы Rsyslog является пол н ы м и исчерпывающи м справочн иком. В следующем списке кратко описаны некоторые из наиболее распространенных (или интересных) модулей ввода и вывода, а также несколько экзотических примеров. —

• •

Модул ь i m j o u rn a l и нтегрируется с жур н алом sys temd, как описано в разделе » Совместное использование с системой Syslog». М одул ь i m u x s o c k считывает сообщения из сокета домена U N IX. Если журнал systemd отсутствует, это значение устанавл ивается по умолчанию. Модуль i m k l o g пон имает, как читать сообщения ядра в с истемах Linux и BSD. М одул ь im f i l e преобразует простой текстовый файл в формат сообщен и я систе­ мы Syslog. Это полезно для импорта файлов журналов, созданных с помощью про­ грамм ного обеспечения, не имеюще го встроенной поддержки Syslog. Существуют два режима: режим опроса, который проверяет файл на наличие обновлений в на­ страиваемый интервал и режи м уведомления ( i n o t i f y ) , который использует и н ­ терфейс событий файловой систе м ы Linux. Этот модуль допускает восстановление после отключения при перезапуске демона rsyslogd.

Часть 1. Основы администрирования

334 •

Модул и imt c p и imudp прини мают сете вые сообще н ия через ТС Р и U D P соот­ ветствен но. Они позволяют централизовать веден и е журнала в сети . В сочетании с драй вера м и сетевого потока с истем ы Rsyslog модул ь ТС Р также может при н и ­ м ать взаимно аутентифицирован н ые сообщен ия систе м ы Syslog через T L S . Для сайтов Linux с чрезвычайно высоким объемом с м . также модуль imp t cp. Если модул ь imma r k присутствует, система Rsyslog создает сообщен ия с отметкой времени через равные промежутки времени. Эти метки времени могут помочь вам понять, что ваща машина потерпела крах между 3 : 00 и 3 : 20 утра, а не просто но­ чью. Эта информация также я вляется бол ьшой помощью, когда вы отлаживаете пробле м ы , которые происходят регулярно. Для настройки и нтервала метки ис­ пользуйте параметр Ma r kМe s s a g e P e r i od. М одул ь omf i l e зап исывает сообщения в файл . Это наиболее часто используе м ы й модул ь вывода и единстве н н ы й , который настроен п р и установке по умолчанию. М одул ь o m f w d пересылает сообщения на удал е н н ы й сервер Syslog через ТС Р ил и U D P. Этот модуль особен н о полезен , есл и ваша орган изация н уждается в центра­ л изован ном протоколировании. Модул ь omka f ka это реализация производителя для потокового движка Apache Katka. Пол ьзователи крупн ых сайтов могут извлечь выгоду из возможности обра­ батывать сообще н и я , у которых есть много поте нциальных потребителей. —

Аналогично модул ю omka f ka модуль ome l a s t i c s e a r c h записывается непосред­ ственно в кластер Elasticsearch. Дополн ител ьную и нформацию о стеке управления журналом ELK, который включает Elasticsearch в качестве одного из с воих ком по­ н ентов, с м . в разделе I 0. 5 . М одуль ommys q l отправляет сообщения в базу дан н ы х MySQL. Распределение ис­ точн и ков Rsyslog содержит примерную схему. Для повышен ия надежности объеди ­ н ите этот модуль с устаревшей директивой $Ma i nMs gQueue S i z e .

Модул и можно загружать и настраивать либо с помощью устаревших форматов кон ­ фигурац и и , л ибо с помощью с интаксиса RainerScript . Н иже м ы п р и водим н екоторые примеры в разделах, пос вяще н н ых кон кретны м форматам .

Синтаксис демона sysklogd С интаксис демона sysklogd это традицион н ы й формат систе м ы Syslog. Если вы знаете, как работает стандартный демон syslogd, например е го версия, и нсталли рован­ ная в системе Free B S D , то, вероятно, в ы знаете все , что требуется . (Но учтите , что файл конфигурации традиционного демона syslogd называется / etc/ syslog . conf , а н е /etc/rsyslog . conf . ) И значал ьно этот формат был предназначен для пересылки сообщен и й определен но­ го типа в заданный файл или по задан ному сетевому адресу. Базовый синтаксис зап исей файла таков. —

с ел ект ор

д е й ств ие

Селектор отделе н от действия одн и м или н ескол ькими пробелами ил и знаком табу­ ляции. Например, строка auth . *

/ va r / l o g / a u t h . l og

обеспечивает сохранение сообщений, связанных с аутентификацией пользователей, в файле /var/ log/auth . log.

Глава 1 0. Журналирование

335

Селектор указывает источник (facility), посьmающий журн ал ьн ое сообще н и е , и уровень важности (severity) эrого сообщения. Формат селектора выглядит следующим образом. и с то чни к . уров ень_в а жно с ти

Названия источ ников и уровней важности следует выбирать из стандартного спис ка значений; программ ы не могут самостоятельно составлять так и е с п и с к и . Есть источ н и ­ ки , определенные для ядра, для основных групп утилит и для локальных программ. Все остальное проходит под общим названием u s e r (т.е. пол ьзовател ь) . Селекторы могут содержать сим вол ы * и none , которые обозначают » все» и » н иче­ го» соответствен но. В селекторе разрешается через за п я тые перечислять группу и сточ­ ников. Допускается также разделение самих селекторов с помощью точки с запятой. В общем случае селекторы объединяются операцией OR, т. е . указанное действие бу­ дет выпол няться для сообщения, соответствующего любому селектору. Селектор уровня none означает исключение перечисленных в нем источ н и ков, независимо от того, что указано в остальных селекторах этой же строки. При ведем несколько примеров селекторов. # Приме н я ем д е й с т в и е ко в с е м с о о бще ниям о т f a c i l i t y . l eve l fac i l i t y . l e v e l

action

# Приме н я ем д е й с т в и е к о в с е м сообщениям о т f a c i l i t y l . l ev e l и f a c i l i t y2 . l eve l fac i l i t y l ,

f a c i l i t y 2 . l ev e l

action

# Приме н я ем д е й с т в и е т о л ь к о к с о общениям от f a c i l i t y l . l e ve 1 1· и f ac i l i t y 2 . l eve l 2 action

faci l i t y l . l e v e l l ; f a c i l i t y2 . 1 eve 1 2

# Приме н я ем д е й с т в и е т ол ь ко и с точникам с з аданным уровнем в ажн о с ти * . level

action

# Приме н я ем д е й с т в и е ко в с е м и с т очникам,

* . l e vel ; ba d f a c i l i t y . none

кр оме b a d f a c i l i t y action

В табл. 1 0.2 перечислен ы допустимые назван ия источн иков. Они определены в стан­ дартной библ иотеке в файле sys log . h. Таблица 1 0 . 2 . Названия средств Syslog Источник

Проrраммы или сообщения, которые ero ис п ольэу�от

auth

Команды, связанные с безопасностью и авторизацией

*

Все источники, кроме ma r k

a u t hp r i v

Конфиденциальные авторизационные сообщения

cron

Демон cron

daemon

Системные демоны

ftp

Демон ftpd (устаревший)

kern

Ядро

l o ca l 0 — 7

Восемь разновидностей локальных сообщений

lpr

Система спулинга построчной печати

ma i l

Система sendmail , pos tfix и другие почтовы е программы

ma r k

Метки времени, генерируемые через одинаковые промежутки

news

Система телеконференций Usenet (устаревшая )

syslog

Внутренние сообщения демона sys logd

user

Пользовательские процессы (это установка по умолчанию, если не указано иное)

Часть 1. Основы администрирования

336

Не воспри н и майте сл и ш ком серьезно различие между сообще н и я м и систе м ы Syslog типа a u t h и a u t h p r i v. В действительности все авторизационные сообщения явл яются конфиде н циальн ы м и , и ни одно из н их не должно быть открытым для всеобщего досту­ па. Журн ал sudo использует a u t h p r iv. В табл . 1 0. 3 перечислены уровни важности , существующие в системе Syslog ( в поряд­ ке убы вания важности ). Таблица 1 0 . 3 . Уровни важности сообщений Syslog Уровень

Приблиэитепьное значение

eme r g

Экстренные сообщения; система вышла из строя Срочные сообщения ; требуются срочные действия Критические состояния Другие ошибочные состояния Предупреждения Необычные события, которые заслуживают внимания Информационные сообщения Отладочные сообщения

alert crit err warning notice info debug

Уровень сообще н и я определяет е го важность. Границы между разл и ч н ы м и уровн я ­ м и н есколько размыты. Существует четкое различие между событи я м и , заслуживаю­ щими внимания, и предупреждениями (а также между предупрежде н и я м и и сообщен и ­ я м и о б ошибках), но трудно однозначно разграничить значения уровней a l e rt и c r i t . Уровн и обозначают м и н им ал ьн ую важность, которую сооб ще н и е должно и м еть дл я того, чтобы быть заре гистрирова н н ы м . Например, сообще н и е от SSH и меющее уровен ь важности wa r n i n g , будет соответствовать селектору a u t h . w a r n i n g , а также сел е кторам a u t h . i n f o , a u t h . n o t i c e , a u t h . debug , * . w a r n i n g , * . n o t i c e , * . i n f o и * . d e b u g . Если в конфигурации указано, что сообщен ия a u t h . i n f o должн ы регистр и ­ роваться в файле, т о сообщен ия a u t h . wa r n i n g тоже будут направляться в этот файл . Этот формат также допускает с и м вол ы = и ! перед назван иями уровней , означаю­ щие «тол ько этот урове н ь » и » за исключением этого и более высоких уровн е й » соот­ ветствен но (табл . 1 0.4). Таблица 1 0.4. Примеры использования квалификаторов уровня Селекто р

Назначение

auth . info

Выбор почтовых сообщений уровня i n f o и выше Выбор почтовых сообщений только уровня i n f о Выбор почтовых сообщений уровней i n f o , n o t i c e и wa r n i n g Выбор почтовых сообщений любого уровня, кроме w a r n i n g

auth . =info auth . in f o ; auth . ! e r r a u t h . debug ; a u th . ! =wa r n i n g

Поле действие определяет способ обработки сообще ния. Возможн ые варианты пе­ речислены в табл . 1 0. 5 . Таблица 1 0 . 5 . Типичные действия

Действие

Назначение

имя_ фа йл а

Дописать сообщение в указанный файл на локальном компьютере

@имя_х о с та

Переслать сообщение демону rsyslogd, выполняющемуся на компьютере с указанным именем

Глава 1 о. Журналирование

337 Окончание табл. 10.5

действие

Назначение

Переслать сообщение на rР_адрес по протоколу UDP, порт 5 1 4 Переслать сообщение на IР_ адрес п о протоколу ТСР, порт 5 1 4 l имя_ FIFO Записать сообщение в указанный именованный канал• польз о ва тель l , польз о ва тель 2 , … Вывести сообщение на экраны терминалов указанных пользовате­ лей, если они зарегистрированы в системе * Вывести сообщение на экраны терминалов всех пользователей, зарегистр ированных в системе Игнорировать сообщение лпроrрамма ;ша блон Форматировать сообщение в соответствии со спецификацией шаблон и п ослать его пр о rрамме как первый аргумент

на

Orde r Deny , Al l ow Deny From A l l Al low F r om 1 2 7 . 0 . 0 . 1 Al l ow F r om а дре с_ с е ти < / Loc a t i on >

В качестве параметра адрес с е ти следует указать I Р-адрес сети , из которой должны приниматься задания на печать ( например, 1 9 2 . 1 6 8 . О . О ) . Далее нужно отыс кать кл ючевое слово B r ow s eAdd r e s s и указать напротив него адрес рассылки в этой сети и порт C U PS. Brows eAdd r e s s 1 9 2 . 1 6 8 . 0 . 2 5 5 : 6 3 1

Эти два действия заставят сервер принимать запросы с л юбой маш и н ы в сети и рас­ сылать известную е му и нформацию об обслуживаемом им принтере все м и меющимся в сети демонам CU PS. Вот и все! П осле перезапуска демон cupsd станет сервером.

А втоматическое конфигурирование принтера На самом деле систе ма C U P S может испол ьзоваться и без при нтера ( н апример, для преобразования файлов в формат P D F или формат факса) , но в основном она все­ таки испол ьзуется для управл е н и я принтерам и . В этом разделе реч ь пойдет о самих принтерах. В некоторых случаях добавление при нтера явля ется тривиал ьн ы м . Система C U PS старается автоматически обнаружить U S В — принтеры при их подключении и выясн ить, что с ними нужно делать. Даже если установку приходится выполн ять самостоятельно, процесс добавления принтера часто состоит всего лишь из подключения оборудован ия, установки соединения с веб-интерфейсом C U PS по адресу l o c a l h o s t : 6 3 1 / a dmi n и предоставления ответов на несколько вопросов. Среды KDE и GNOM E поставляются с собственными утилитами для конфигурирования принтера, которые могут использоваться вместо интерфейса CU PS. Если кто-то другой добавляет принтер и об этом становится известно одному или не­ скольким фун кционирующим в сети серверам C U PS, ваш сервер C U PS тоже уведомля­ ется о появлении нового принтера. Н и добавлять этот при нтер явно в локальный пере­ чень устройств, ни копировать его РDD-файл на свою машину вам не нужно. Это магия.

Конфигурирование сетевых при нтеров Сетевым принтерам — ос новной частью интерфейса которых явл яется сетевая пла­ та Ethemet или оборудование Wi- Fi н еобходима собствен ная конфигурация тол ько для того, чтобы быть членами сети TC P/I P. В частности, им необходимо знать свой I Р­ адрес и сетевую маску. Такая информация обычно передается им одни м из двух способов. Почти все современные принтеры могут получать эту информацию по сети от серве­ ра ВООТР или D H C P. Этот метод работает хорошо в средах со множеством гомогенных принтеров. Более подробную информацию о D H C P можно найти в разделе 1 3 .6. —

Часть 1. Основы администрирования

390

Второй с пособ закл юч ается в установке статического 1 Р-адреса при помощи консол и п р и н тера, которая обы ч но состоит из ряда кнопок на п е редн е й панел и и одностроч н ой и ндикатор ной панел и . Все , что нужно сдел ать, — это » походить» по м е н ю и отыскать раздел , где можно уста новить I Р-адрес. ( Если вдруг попадется команда , позвол я ю щая распечатать м е н ю , следует воспол ьзоваться е ю и сохранить печатную верс и ю . ) П осле заве р ш е н и я к о н ф и гур и р о ва н и я сете в ы е п р и нтеры об ы ч н о пол у ч а ют в е б ­ консол ь , доступную ч ерез браузер . Однако для того , чтобы с н и м и м о ж н о б ыло рабо­ тать через эту консол ь , у них должен быть I Р-адрес и они уже должны фун кционировать в сети , когда вы к н и м обратитес ь , так что этот интерфейс оказывается недоступн ы м как раз тогда , когда он вам оче н ь н уже н .

Примеры конфигурирования при нтеров В качестве п р и меров добав и м п р и нтер с параллельн ы м и нтерфе йсом g ro u c h o и с е ­

тевой принтер f е zmo и з командной строки.

$ sudo lpadmin -р groucho -Е -v parallel : /dev/ lpO -m pxl color . ppd $ sudo lpadmin -р fe zmo -Е -v socke t : / / 1 92 . 1 6 8 . 0 . 1 2 -m laserj e t . ppd Ка к вы видите , и н те р ф е й с g r o u c h o п р едост а вл я ется ч е р е з порт а femz o

/ de v / l p O ,

через I Р-адрес 1 9 2 . 1 6 8 . О . 1 2 . М ы указывае м каждое устройство в в иде у н и ­

версал ьного иде нтифи катора ресурса ( U RI ) и в ы б и р а е м Р D D-файл и з с п и с ка Р D D ­

/usr/ share/ cups /mode l . cupsd с конфигурирован как сетевой сервер, он сразу ж е сде­

файлов, находящихся в каталоге Есл и локал ьн ы й демон

лает эти новые принтеры доступн ы м и для других кл иентов в сети . Пос кольку сервер

cupsd конфи гурируется как сетевой , он н емеме нно делает новые

при нте р ы доступн ы м и для других кли ентов в сет и . Перезапус к при этом н е требуетс я . C U PS п озвол я ет ис пол ьзовать мя при нтеров самые разн ы е U Rl — иде нтификаторы . Вот е ще нескол ько п р и меров.

i pp : / / z o e . c a n a r y . com/ipp l pd : / / r i l e y . c a na r y . c om / p s s e r i a l : / / d e v / t t y S O ? b a u d= 9 6 0 0 +p a r i t y= e v e n +b i t s= 7 s o c k e t : / / g i l l i an . c a na r y . com : 9 1 0 0 u sb : / /X EROX / Ph a s e r % 2 0 6 1 2 0 ? s e r i a l =YGG2 1 0 5 4 7 Одн и U RI — идентифи каторы п р и н им ают параметры (например, s e r i a l ) , а другие нет. Команда

lpinfo -v отображает с п и сок устройств, которы е система м ожет в идеть,

и с писок типов U Rl-идентификаторов, которые понимает система C U P S .

Откл ючение принтера Есл и в ы хотите удал ить п р и нтер ил и клас с , это можно л е гко сделать при помощи команды

lpadmin -х.

$ lpadmin -х fezmo Но к а к быть, есл и н ужно тол ько вре м е н н о откл ю ч ить п р и нтер для прохожде н ия тех н и ч е с ко го ос м отра , а н е удал ять е го? В таком случае можно просто заблокировать очередь печати на входе ил и выходе. Есл и отключ ить «хвост» (т. е . выходную или п р и н ­ тер н ую сторону) очереди , пользователи по- прежне м у с м о гут отправлять зада н и я , но эти задан ия н и когда не будут печататься. Есл и откл юч ить » головную» ( входную) часть оче­ реди , те задания , которы е уже находятся в очереди , будут расп ечата н ы , а вот все попыт­ к и добавить в очередь новые зада н и я будут отклоняться .

Глава 1 2. печать

391

cupsdisaЫe и cupsenaЫe контрол ируют выходную сторон у очереди , rej ect и accept ее п р и н и мающую сторону.

Команды а команды

$ sudo cupsdisaЫe qroucho $ sudo rej ect corbet Какую же и з н их луч ш е испол ьзовать’? П р и н и м ать зада н и я н а печать, которые точ но не будут распечата н ы в бл ижа й ш е м будуще м , гл упо, поэтом у для дл ител ьн ых периодо в простоя луч ш е испол ьзовать команду

rej ect. Для коротких перерывов, которые даже

не должн ы быть за м ет н ы пол ьзователя м ( н а п р и м е р , когда н ужно п росто удал ить за ­ стря вшую в п р и нтере бум агу) , луч ш е испол ьзовать команду

cupsdisaЬle.

Адм и н истраторы и н огда п росят дать и м какую — н и будь подс каз ку, которая помогла бы запо м н ить, какие ко манды контролируют каждый коне ц очереди . П редлагае м поп ро­ бовать такой вар иант: есл и с истема

C U PS » отклоняет» (rej ect) зада н и е , это означ ает,

что его н ел ьзя » предоставить » . Еще оди н с пособ не путать команды — это запом н ить,

(accept) и отклон яться (rej ect) могут тол ько задания на печать, а от­ (disaЬle) и включаться (enaЬle) только принтеры. Систе ма CU PS и н огда сама вре ме н но откл ючает при нте р , с которы м н е м ожет н ор­

что пр и н и м аться

кл ючаться

мал ьно работать ( н а п р и м е р , из-за того , что кто-то вьщер н ул е го кабел ь) . Устран и в п ро­ бле му, следует с нова активизировать очередь. Есл и забыть это сделат ь , команда

lpstat

напом н ит. ( Бол ее подробную и н формаци ю по это й те м е и ал ьтер н ат и в н о м у п одходу можно н айти по адресу www . l i nuxp r i n t i n g . o r g / b e h . html . )

Другие связа нные с конфигурирова нием задач и Совре м е н н ы е при нте р ы и м е ют оч е н ь м н ого о п ц и й , которые можно конфигуриро­

C U PS позволяет н астраи вать самые раз н ы е фун к ц и о н ал ьн ы е возмож­ lpadmin и lpopt i o n s . Как правил о , ком анду lpadmin испол ьзуют для в ы п ол н е н ия задач н а уро в н е с и сте м ы , а кома нду lpoptions для выпол н е н ия задач на уровне пол ьзователя . Ко манда lpadmin позволяет более четко задать о гран и ч е н и я доступа, ч е м команды disaЬle и rej ect. Н а п р и м е р , с ее помощью можно создавать квоты на печать и ука:1 ы ­ ват ь. Систе м а

ности с помощью е е веб- и н терфе йса и ком а нд —

вать, на каких и м е н н о при нте рах разре шается вы пол нять печать те м ил и и н ы м пол ьзо­ вател я м .

В табл . 1 2 . 1 перечисл е н ы все команды , которые поставля ются с систе мой C U PS , и и х источ н и к и , в которых он и испол ьзовал ись первоначал ьн о . Таблица 1 2 . 1 . Утилиты командной строки , поставляемые с системой CUPS, и системы, в которых они использовались первоначально

CUPS

Команда

Фун кция

cups-confiq

Выводит информацию об АР l -интерфейсе , компиляторе, каталоге и ка­ нале связи системы CUPS

cupsdisaЬle• cupsenaЬle» lpinf o lpoptions «»»»..» … «.»»

Останавливает печать принтера или класса

Восстанавливает печать принтера или класса

П оказывает доступные устройства или драйверы Отображает или устанавливает опции и параметры по умолчанию принтера

:1:����� �� … «.» .. » … » . .�?.?.������»�.�.� �����.���.У.������.��Р.О��.?.:�.���.�.?.:�…… .

.

. . .

«.» «» » «

.

.»…….. «»

Часть 1. Основы администрирования

392

Окончание табл. 1 2. 1

Команда

Syste m V accept , re j ect cancel lpadllli. n lps tat

BSD

lpc lpq

Принимает или отклоняет поступа ющие в очередь задания Отменяет задания Печатает файлы

lp lp111ove

Функция

К онфигурирует принтеры и классы CUPS Перемещает задание в новое место Печатает информацию о состоянии CUPS

.»» . . » . » » . . » » » … » . . . . . . . . . . » . . . . » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . » . . . . . . . . . . . «» . . . » . . . » . » . . . . . . . . » . . . . . . . . . . . . . . . . .. . . . . . » . . . . • . • . . • » . . . . . . . . . . . . . » . . . . . . » … » » . .

Представляет собой общую программу для управления принтерами Отображает статус очереди принтера

lpr

Печатает файлы

lprm

Отменяет задания на печать

• На самом деле это просто переименованные команды disaьle и еnаЫе из System V.

1 2 .3 . СОВЕТЫ ПО ВЫЯВЛЕНИЮ ПРОБЛЕМ П р и нтеры сочетают все слабости механичес кого устройства со стран ностя м и внеш­ ней операционной систе м ы . О н и (и п рограмм ное обеспечение, которое и м и управляет) обожают создавать проблемы для вас и ваш их пользователей. Рассмотрим нескол ько со­ ветов по борьбе с проблемными принтерами.

Повторный запуск демона печати Н и когда н е следует забы вать пе резапус кать демо н ы после внесе н и я измене н и й в конфигурационн ы й файл . Перезапустить демон cupsd можно л юбым способом , которы й операцион ная систе­ ма предусматривает для повторного запуска демонов, — выпол нить команду sys temctl re s tart org . cups . cupsd . service или аналогичную команду. Теоретически можно также отправить демону cupsd сигнал H U P или испол ьзовать графичес кий пол ьзова­ тельский и нтерфейс систе м ы CU PS.

Регистра ционные журналы Система CU PS поддерживает три регистрационных журнала: журнал страниц, жур­ нал доступа и журнал ошибок. Журнал страниц представляет собой просто сп исок напе­ чатанных страниц. Журнал доступа и журнал ошибок похожи на аналогичные журнал ы в неб-сервере Apache. И в этом нет н ичего удивительного, потом у что сервер C U PS это веб-сервер. Уровен ь регистрации и путь к журнальным файлам задается в файле cupsd . conf. Обычно журнал ьные файл ы сохраняются в каталоге /var/log. Н иже приведен фрагмент из журнального файла, охватывающий одно задание на печать. —

I I I I I

[ 1 2 / Ju l / 2 0 1 7 : 1 8 : 5 9 : 0 8 — 0 6 0 0 ) [ 1 2 / Ju l / 2 0 1 7 : 1 8 : 5 9 : 0 8 — 0 6 0 0 ) [ 1 2 / Ju l / 2 0 1 7 : 1 8 : 5 9 : 0 8 — 0 6 0 0 ) [ 1 2 / Ju l / 2 0 0 6 : 1 8 : 5 9 : 0 8 — 0 6 0 0 ) ( P I D 1 9 9 8 5 ) f o r j ob 2 4 . [ 1 2 / Jul / 2 0 1 7 : 1 8 : 5 9 : 0 8 — 0 6 0 0 ) ( P I D 1 9 9 8 6 ) f o r j ob 2 4 .

Addi ng s t a r t b a nn e r p a g e » none » to j ob 2 4 . Adding end bann e r p a g e » none » t o j ob 2 4 . Job 2 4 queue d on ‘ Ph a s e r_ 6 1 2 0 ‘ Ь у ‘ j s h ‘ . S t a r t ed f i l t e r u s r / l i be x e c / cups / f i l t e r / p s t o p s S t a r t e d bac kend / u s r / l i b e x e c / cu p s / b a c k e n d / u s b

Глава 1 2. П ечать

393

Проблемы с п рямой печатью Удостовериться в наличии физического соединения с локальны м принтером можно, напрямую выпол н и в внутреннюю программу принтера. Например, вот что мы получи м , если выпол н и м внутрен н юю программу принтера, которы й подключается через U S В ­ кабель. $ /usr/ li.Ь/ cups /backend/usb d i r e c t u s b » Un known » » U S B P r i n t e r ( u sb ) » d i r e c t u s b : / /X E ROX / P ha s e r % 2 0 6 1 2 0 ? s e r i a l =YGG2 1 0 5 4 7 » XEROX Pha s e r 6 1 2 0 » » Ph a s e r 6 1 2 0 «

Если U S В — кабель принтера Phaser 6 1 20 отключится, строка дл я этого принтера ис­ чезнет из вывода внутренней программ ы . $ /usr/liЬ/ cups /backend/usb di r e c t u s b » U n known » » U S B P r i n t e r ( u sb ) «

Проблемы с печатью в сети Прежде чем нач инать искать проблему печати в сети, попробуйте установить соеди­ нение с обслуживающи м данн ы й принтер демоном cupsd при помощи браузера (имя_ хоста: б З l } или команды telnet ( telnet имя_ х о с т а 6 3 1 ) . В случае возникнове н и я проблем при настройке соедине ния с сетевым принтером помните о том , что на кл и ентском комп ьютере у вас должна быть очередь для заданий, способ для решения того, куда отправлять задани е , и метод отправки задан и я на ком ­ пьютер, которы й отвечает за обслуживание очереди на п ечать. Н а сервере печати у вас должно быть м есто для постановки задания в очередь, соответствующие п рава доступа для разрешения печати задания и с пособ для вывода данных на устройство. Для того чтобы выяснить причину этих пробл е м , возможно , п р идется загл я н уть в следующие файлы . •

С исте м н ы е журнал ь н ы е файлы на кл иентском комп ьютере ( в случае пробл е м с распознаванием и мен и правами доступа) . Систе мные журнальные файлы на сервере печати ( в случае п роблем с правами до­ ступа). Журнальные файлы на клиентском ком пьютере (если отсутствуют какие-то филь­ тры или каталоги или есл и имеются неизвестные принтеры и т.д. ) . Журнальные файлы демона на сервере печати ( в случае появл е н и я сообщен и й о неправил ьных именах устройств, неправил ьн ых форматах и т.д. ) . Журнальные файлы при нтера на комп ьютере , получившем задан ие ( в случае по­ я вле н и я ошибок при передаче зада н и я ) , как указано в перем е н ной l f в файле /etc/printcap/ в системе B S D . Журнальные файл ы принтера на ком пьютере , отправившем задание ( в случае по­ я вл е н и я сообщений о н еправил ьной предварительной обработке или ошибочной постановке задания в очередь).

Путь к журнал ьн ы м файлам C U PS указан в файле /etc/ cups / cupsd . conf. Общую информацию об управлен ии журналами регистраци и см. в главе 1 0.

Часть 1. Основы администрирования

3 94

1 2.4. ЛИТЕРАТУРА Система C U PS поставляется с обш ирной документацией в формате HTM L. Для того чтобы пол уч и т ь к н е й дос ту п необходимо соедин иться с сервером C U PS и щелкнуть на справоч ной ссылке . Разумеется это не поможет, ели у вас нет с вязи с этим серве­ ро м . Впрочем , на вашем ком п ьютере эта документация инсталлируется в каталог /usr/ share/ doc/ cups в форматах H T M L и P D F. Есл и ее там нет, обратитесь к менеджеру, поставившему дистр ибути вный пакет, или на сайт cups . o r g . ,

Sн лн , AN KtJ R. CUPS Administrative Guide: А practical tutorial to installing, managing, and securing this powerful printing system. Birmingham , U К: Packt PuЫ ishing, 2008.

ЧА СТЬ

11

Ра б ота в сетях

глава

13

Сети TCP/IP

Трудно переоцен ить важность сетей в современном компьютерном мире, хотя мно­ гие все же п ытаются это сделать. Во м ногих орган изациях — возможно, даже в боль­ шинстве из них — компьютеры используются , в первую очередь, для работы в веб и до­ ступа к эле ктронной почте . По оцен кам сайта i n t e r n e t w o r l d s t a t . c om , к средине 20 1 7 года в И нтернете работало более 3 , 7 млрд пользователе й , что составляет чуть менее половины населения Земл и . В Северной Америке внедрение И нтернета уже прибл ижа­ ется к 90% . TC P/I P (Transmission Control Protocol/lnternet Protocol) — это сетевая система, ле­ жащая в основе И нтернета. Она не зависит н и от аппаратного обеспечения , н и от опе­ рационной систе м ы , поэтому все устройства, использующие протокол ы TCP/IP, могут обмениваться дан н ы м и (» взаимодействовать» ) , несмотря на различия. Система TC P/ I P работает в сетях л юбого размера и л юбой топологии , независимо от того, соедине н ы они с внешн и м м иром или нет. В этой главе протоколы TCP/ I P рас­ сматри ваются в пол итическом и техническом аспектах, связанных с И н тернетом , но изолирован ные сети на уровне протоколов TC P/ I P очень похожи друг на друга.

1 3. 1 . С ИСТЕМА TCP/I P и И НТЕРНЕТ И стория систе м ы TC P/I P тесно связана с историей И н тернета и уходит корнями на нескол ько десятилетий назад. Популярность Интернета во м ногом обусловлена эле ­ гантностью и гибкостью системы TC P/ I P, а также тем , что это открытое и некоммерче­ ское семейство протоколов. В свою очередь, широкое распространение системы TC P/IP

Часть 11. Работа в сетях

3 98

именно в И нтернете позвол ило этому семейству одержать верх над нескольким и кон ку­ рирующими семействами , популярн ы м и в свое время по политическим ил и ком мерче­ ским прич инам. П рародител ь н и ц е й И нтерн ета была сеть A R PAN EТ, организованная в 1 969 году М и н истерством оборон ы США. К кон цу 1 980-х годов эта сеть перестала быть науч ­ но-исследовател ьской и наступ ила эра ком мерческого И нтернета. В настоящее врем я И нтернет представляет собой совокупность частных сете й , принадл ежащих провайде­ рам и нтернет-услуг (intemet service provider — I S P) и соединяющихся в так называем ых «точках обмена трафиком » (peering points).

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

I CAN N ( l nte rnet Corpo ration for Assigned Names and Numbe rs — Кор порация по назнач е н и ю и м е н и адресов в И нтернете ) . Эта группа с н аибол ьш и м правом может быть названа ответствен ной за И нтернет. Только она обладает всем и реал ь­ н ы м и полномочиями. Корпорация I CAN N контрол ирует выделение адресов и до­ м е н н ых и м е н в И нтернете , а также другие аспекты его деятельности , например номера протокол ьных портов. Эта органи заци я , основанная как некоммерческая корпораци я , расположе на в Калифорнии (www . i c a n n . o rg ) . I SO C ( l ntemet Soc iety — Сообщество пользователе й И нтерн ета) — открытая членс кая орга н иза ц и я , представл я ю щая и нтересы пол ьзо вателе й И нтер н ета. Н е с м отря на то что эта орга н и зация пресл едует образовател ьные и пол и т и ­ ч еские цел и , о н а ш ироко известна к а к п р и крытие для техн ического развития И нтерн ета. В частности , орга н и зация I SOC я вл яется головной орга н и за ц и е й по отно ше н и ю к пробл е м ной груп п е проектирова н и я И нтернета ( i e t f . o r g ) , контролирующей в с ю техническую работу. I SOC я вляется м еждун ародной н е ­ ко м м ерчес ко й орган и зац и е й . Ее офи с ы рас п оложе н ы в Ваш и н гтоне , округ Колумбия , и Жен е ве ( www . i s o c . o r g ) . I G F ( l ntemet Gove rnance Foru m ) — это орган изация , создан ная Орга н и зацией Объединенн ых Наций относительно недавно, в 2005 году, чтобы предоставить воз­ можность для проведе н ия международных и пол итических дискусси й , посвящен­ н ых Интернету. Она п роводит ежегодные конфере н ц и и , но ее рол ь со временем возрастает, поскольку правител ьства разных стран п ытаются установить более жесткий контроль за И нтернетом ( i n t govfo rum . o r g ) .

Среди перечисленных организаций наибольшая ответстве нность лежит н а I CAN N : она выступает в качестве руководящего органа И нтернета, исправляя ошибки, допущен­ ные в прошлом , и продумы вая пути дал ьнейшего развития И нтернета с учетом потреб­ ностей пользователе й , правительств и бизнеса.

Глава 1 3. Сети TCP/ IP

399

Сетевые ста нда рты и документа ция Если вы не уснул и сразу после того , как прочитал и назван ие этого раздела, значит, вы выпили несколько чашек кофе. Тем не менее умение разбираться в технической до­ кументаци и , в ыпускаемой руководя щ и м и органам и И нте р н ета , ч резвычай н о важ но ДJIЯ сетевых адми н истраторов, и это не так уж и скучно, как кажется н а первый взгляд. Техническая деятельность сообщества пользовател ей И н тернета н аходит отражен и е в серии документов, известных к а к R F C ( Request For Comments запрос ком м ента­ риев). В формате документов RFC публ икуются ста н да рт ы п ротоколов, п р едлагае м ые нововведен и я , а также информационн ые бюллетен и . Получая сначала статус черновых проектов ( l ntemet Drafts) , после бурных дебатов в тел е ко н фере н ц иях и н а форумах I ETF они либо отвергаютс я , либо получают официал ьн ы й статус . Свое мнение по поводу предлагаемого стандарта может высказать л юбой уча ст н и к обсужде н и я . И ногда доку­ мент RFC представляет собой не стандартизацию протоколов И нтернета, а вс его л и ш ь констатацию и л и объяснение некоторых аспектов сов реме н но й практи ки . Докуме нты R FC и меют порядковые номера. На сеrодняшний ден ь их более 8200. У каждого документа есть описательное название ( на п р и мер Algorithms for Syn ch ron izing Network C/ocks алгор итмы сетевой синхронизации часов), но во избежание неодно­ значности на документы чаще всеrо ссылаются по номерам . Будучи о публ и кова н н ы м , документ R F C н икогда не меняется. Изменения и дополнения публи куются в виде но­ вых документов с собствен н ы м и номерам и . Обновл е н ие может л ибо дополн ять и разъ­ яснять документ RFC, либо полностью его заменять. Существует м ножество источн и ков, распростра н я ю щих документы RFC, но с ай т t f c — e d i t o r . o rg я вляется централ ьн ы м диспетчерским пункто м и всеrда содержит са­ мую свежую и нформацию. П режде чем тратить вре м я н а чте н и е документа R F C , в ы ­ ясните его статус на сайте t f c — e d i t o r . o r g ; возможно, этот документ уже не содержит наиболее актуальную информацию. Процесс публикации стандартов Интернета подробно описан в док у е н те RFC2026 . Другой полезн ый метадокумент — RFC5540, 40 Years о/ RFCs (40 л ет существования до­ кументов RFC). В нем описаны культурн ы е и техни ч е с кие аспекты пу блика ци и доку­ ментов RFC. Пусть читателей н е пугает обил ие технических под р о б н осте й в документах RFC. В большинстве из них содержатся вводн ые описани я , резюме и толкован и я , которые будут полезны с исте м н ы м адми н истраторам . Н екото рые документы специально напи­ саны в виде обзора или общего введения. Чте н ие докум е нтов R FC — это, возможно, не самый простой способ разобраться в той или иной тем е , но это авторитетны й , лаконич­ ный и бесплатн ый источн и к информации. Не все документы R FC написаны сухим техническим я з ы ко м Встречаются докумен­ ты развлекательного содержания (часть из н их опубл и ко ва на п ервого апрел я ) , с ред и них нам особенно нравятся следующие: —

,

м

.

RFC l 1 49 А Standardfor the Transmission о/ /Р Datagrams оп A v ia n Ca»iers (стандарт передачи датаrрамм с помощью птиц) 1 ; —

RFC 1 925 — The Twelve Networking Truths ( 1 2 сетевых исти н ) ;

R F C325 1 — Electricity over /Р (передача электричества п о протоколу I P) ;

1 Группа энтузиастов систе м ы Liпux и з города Берген в Норвеги и , назы вающая себя B L U G ( Bergen Linux User Group ) , действительно реализовала протокол С Р Р ( Carrier Pigeon l nternet Protocol межсетевой протокол голубиной почты) в соответствии с документом RFC l 1 39 . Детали см. на их веб-сайте по адресу: Ы u g . l i n ux . n o /r fc l l 4 9 . —

Часть 11. Работа в сетях

400 •

• •

R FC404 1 — Requirementsfor Morality Section in Routing Агеа Drafts ( морал ьный кодекс маршрутизатора) ; R FC62 1 4 — Adaptation of RFC I J49for /Рvб (адаптация RFC I 1 49 к протоколу 1 Pv6) ; R FC692 I — Design Considerationsfor Faster- Than-Light Communications ( вопросы про­ е ктирования систем связи , работающих со сверхсветовой скоростью) ; R FC75 1

I

— Scenic Routingfor /Рvб (живописная маршрутизация для lvб ) .

n ом и мо собстве н н ых порядковых номеров, докуме нтам RFC могут н аз начать­ ся номера серий FYI ( For You r l nfonnation — к вашему с веде н и ю ) , ВСР ( Best Current Practice — луч ш и й существующий подход) и STD (Standard — стандарт). Переч ислен н ые серии являются подмножествами серии RFC, группирующими документы по важности ил и назначен ию. Документы FYI — это вводные или информационные материал ы , п редназнач е н н ые для ш ирокой аудитории . Как правило, именно с них лучше все го начинать изучать не­ знакомую тем у. К сожалению, эта серия в последнее время стала иссякать, и сейчас со­ вре м е н н ых документов FYI оче н ь н е много. Документы ВС Р описыва ют рекоме ндуемые процедуры для адм и н истраторов веб­ сайтов в И нтернете . О н и содержат адм и н истрати вные предписан и я и представл я ют большую цен ность для систем ных ад ми н истраторов. Документы STD содержат описания протоколов И нтернета, прошедш их процедуру проверки и тестирования в I ET F и формально принятых в качестве стандартов. Нумерация документов в рам ках серий RFC, FYI , STD и В С Р ведется раздельно, по­ этому оди н документ может и м еть несколько номеров. Например, документ RFC 1 7 1 3 , Toolsfor DNS Debugging ( инструменты для отладки системы DNS) известен также под но­ мером FYl 1 27 .

1 3.2. Основы РАБОТЫ в СЕТИ Заве р ш и в краткий обзор , давайте подробнее рассмотр и м , что собой представляют п ротоколы TC P/ I P. TC P/ I P — это семе йство сетевых протоколов, ориентирова н н ы х на совместную работу. В состав семейства входит несколько ком поне нтов: •

I P ( lntemet Protocol — межсетевой протокол) обеспечивает передачу пакетов дан ­ н ы х с одного компьютера на другой ( RFC79 I ) ; I C M P ( l ntemet Control M e ssage Protocol — протокол управляющих сообщен и й в Интернете) отвечает з а разли чн ы е виды н изкоуровневой поддержки протокола IP, вкл ючая сообщен ия об ошибках, вспомогательн ые маршрутизирующие запро­ с ы и отладочные сообщен ия ( RFC792) ; A R P (Address Resolution Protocol — протокол преобразования адресов) обеспечи­ вает трансляцию I Р-адресов в аппаратные адреса ( R FC826) 2 ; U DP ( U ser Datagram Protocol — протокол передачи датаграмм пользователя ) обе­ спечивает непроверяемую одностороннюю доставку дан ных ( R FC768) ; ТС Р (Transmission Control Protocol — протокол управления передачей) обеспеч и­ вает надежны й дупле кс н ы й канал связи меЖду процессами на двух ком пьютерах с возможностью управления потоками и контроля ош ибок ( R FC793).

2 М ы немного гре ш и м против ист и н ы , уrверждая , что п ротокол A R P входит в семейство TC P/I P. На самом деле он вполне может использоваться вместе с другими семействами протоколов. Просто этот протокол я вляется неотъемлемой частью стека ТС Р/1 Р в больши нстве локальных сете й .

Глава 1 3. Сети TCP/ IP

401

Эти протоколы образуют иерархи ю ( ил и стек) , в которой протокол верхнего уровня испол ьзует протокол н ижележащего уровн я . Систему TC P/I P обычно описывают в виде пятиуровневой структуры (рис. 1 3 . 1 ), но реал ьная с истема TC P/ I P содержит тол ько три из этих уровней. УРОВЕНЬ ПРИЛОЖЕНИЙ

arp

ТРАНСПОРТНЫЙ УРОВЕНЬ СЕТЕВОЙ УРОВЕНЬ

SSH, SMTP, HTTP

DNS, DOTA 3

TCP

UDP IP

traceroute

ICMP

КАНАЛЬНЫЙ УРОВЕНЬ

ARP, драйверы устройств

ФИЗИЧЕСКИЙ УРОВЕНЬ

Медный провод, оптоволокно, радиоволны Рис. 13. 1. Семейство протоколов ТСР//Р

В ерсии 1 Pv4 и I Pvб В течение последн их трех десятилетий ш ирокое распростране ние получила четвертая версия п ротокола TC P/ I P, известная также под и м е н е м 1 Pv4. В н е й ис пол ьзуются че­ тырехбайтовые 1 Р-адреса. Современная версия , 1 Рvб, расширила адресное пространство до 1 6 байт, а также учла опыт испол ьзования верс и и I Pv4. В нее не был и вкл ючены воз­ можности протокола 1 Pv4, которые оказались не очен ь нуж н ы м и . Это позволило уско­ рить работу протокола и облегчило его реализацию. Кроме того, версия 1 Pv6 объединила с исте м ы безопасности и ауте нтификации в рам ках одного базового протокола. Все совре м е н н ы е операционные с исте м ы и м ногие сетевые устройства уже поддер­ жи вают протокол 1 Pv6. Ком пания Google публ и кует статисти ку испол ьзования прото­ кола 1 Pv6 с вои м и кл иентам и на сайте g o o g l e . c o m / i pv б . По состоя н и ю на март 20 1 7 года дол я пол ьзователе й протокола 1 Рvб , обращавшихся к серверам ком пан и и Google , составила около 1 4% . В С ША и х доля составляет 30%. Хотя эти ч исла и выглядят правдоподобн ы м и , на самом деле они могут вводить в за­ блужде н и е , потому что бол ьш и нство мобил ьных устройств по умолчанию испол ьзуют протокол 1 Pv6 при передаче дан ных по сети. В то же время домашние и корпоративные сети преи муществе нно испол ьзуют протокол I Pv4. Разработка и развертывание протокола 1 Pv6 был и в бол ьшой степени моти вирован ы беспокойством о том , что четырехбайтное адресное пространство протокола 1 Pv4 прак­ тически исчерпано. Это действител ьно так: в настоящее время свободные 1 Рv4-адреса остал ись только в Афри ке (см . сайт i pv4 . p o t a roo . n e t ) . Первым свободные I Pv4 адре­ са исчерпал Азиатс ко-Тихоокеанский регион еще 19 апреля 20 1 1 года. Возн икает вопрос : если все 1 Рv4-адреса в м ире исчерпан ы , то почему эта версия про­ токола остается домин ирующей? По большей части это объясняется тем , что мы науч ились более эффективно испол ь­ зовать адреса 1 Pv4 , которые у нас есть. П ротокол NAT ( N etwork Address Translation трансляция сетевых адресов, см. раздел 1 3 .4) позволяет цел ым сетям маш ин скрываться за одн и м адресом 1 Pv4. Технология C I D R (Classless lnter- Domain Routing бесклассовая м еждомен ная маршрутизация , с м . раздел 1 3 .4) гибко разделяет сети и способствует эф-

402

Часть 11. Работа в сетях

фективной магистральной маршрутизаци и . Кон фл и кт адресов 1 Pv4 по- прежнему суще­ ствует, но, как и диапазон вещател ьных частот, в наши дни о н и , как п равил о , перерас­ пределя ются по экономически м , а не технологическим критерия м . Основная проблема, которая ограничивает принятие версии 1 Pv6, закл ючается в том , что поддержка верс ии 1 Pv4 остается обязател ьной д11 Я того, чтобы устройство было пол ­ ноце н н ы м эле м е нтом И нтернета. Например, вот нес кол ько основн ых веб-сайтов, ко­ торые по состоя н и ю на 20 1 7 год еще не доступны через протокол 1 Pv6: Amazon, Reddit , е Вау, I M D B , H ot mail, TumЬr, M S N , Apple, The N ew York Times, Twitter, Pinterest , Bing 3 , Word Press, Dropbox , Craigslist , Stack Overtlow. М ы моrл и бы продолжить, но полагае м . что вы понял и намек. 4 Ваш выбор не между 1 Pv4 и 1 Pv6, а между поддержкой исключител ьно 1 Pv4 и одновре­ менной поддержкой как 1 Pv4, так и 1 Pv6. Когда все службы , перечисле нные выше, и мно­ гие другие службы второго уровня, добавят поддержку 1 Pv6 , вы сможете трезво рассмо­ треть возможность испол ьзования 1 Pv6 вместо 1 Pv4. До тех пор будет впол не разум н ы м попросить разработчиков версии 1 Pv6 оправдать усилия по его внедрен и ю , обеспеч ивая луч шую производительность, безопасность или фун кционал ьность. Ил и , возможно, от­ крыть дверь в м ир услуг 1 Рvб , которые просто невозможно получить через 1 Pv4. К сожалению, этих услуг не существует, и 1 Pv6 фактически не предлагает каких-либо из этих преи муществ. Да, это эле гант н ы й и хорошо п родуман н ы й п ротокол , который улучшает 1 Pv4. И да, в некотором см ысле и м п роще управлять, чем 1 Pv4, и он требует меньше усил и й ( наприм е р , м е н ьше зависит от технологи и NAT) . Н о , в конце кон цов, это просто улуч ш е н ная версия 1 Pv4 с бол ьш и м адрес н ы м п ространством. Тот факт, что вы должны управлять и м вместе с 1 Pv4, искл ючает л юбое потенциал ьное повы ш е н ие эффективности . Прич и ной существования протокола 1 Pv6 остается опасение исчерпа­ ния 1 Рv4-адресов, и на сегодня ш н и й де нь последствия этого исчерпания п росто не был и достаточ но болезне н н ы м и , чтобы стимул и ровать широкомасштабный переход н а 1 Рvб . М ы издаем эту к н и гу в течение дл ительного врем е н и , и в последних нес кол ьких из­ дан иях мы писал и , что протокол 1 Pv6 находится всего в одном шаге от того, чтобы стать ос новной технологией. В 20 1 7 году мы исп ытываем сверхъестествен ное чувство дежавю, связанное с протоколом 1 Pv6 , которы й все ярче сияет на горизонте , но все еще н е реша­ ет н и каких пробл е м и п редлагает сли ш ком мало стимулов для преобразования. 1 Pv6 это будущее сете й , и , очевидно, так будет всегда. Аргументы в пол ьзу фактического развертывания 1 Рv б внутри вашей сети остаются прежн и м и : в какой-то момент это придется сделать. П ротокол 1 Pv6 превосходен с и нже­ нерной точк и зрения. Вам необходимо получить опыт работы с 1 Pv6 , чтобы вас не застал врасплох его п риход. Все крутые пар н и должны это уметь. Мы говор и м : » Конечно, вперед, поддержи вайте 1 Pv6, если вам так хочется. Это от­ ветстве н н ы й и перспе ктив н ы й путь. Это ваш гражданский дол г — осваи вая 1 Pv6 , вы прибл ижаете тот ден ь , когда п ротокол 1 Pv6 станет единствен н ы м , с ч е м вам придется и м еть дело. Но если вам не нравится разбираться в его деталях, ничего страш н ого. У вас впереди годы, пока возникнет реальная необходимость п ерехода» . Разумеется, н и оди н и з этих ком м ентариев н е и м еет с ил ы , если ваша организация пред11агает публ ич н ые услуги в И нтернете . В этом случае внедре н ие 1 Pv6 — ваша свя’ П рисутствие сайта B i пg ком п ан и и M icrosoft в этом с п и с ке особе н но интересно, учитывая , что это оди н из нескольких круп ных сайтов, представленных в материалах Всем и рной маркетинговой кампани и Рvб Lauпch 20 1 2 (под девизом « Н а этот раз это реал ьно»). Мы не знаем полной истории этой с итуа ци и , но сайт B iпg, очевидно, поддерживал Рvб в какой -то момент, а затем ком пания реш ила, что это не стоит возн и кающих проблем. См. Wo r l dipvбl a u n c h . o rg. 4Эrо сайты, ч ьи первичные веб-адреса не связаны ни с одн и м адресом I Pvб (зап исью АААА) в D N S .

глава 1 3. Сети TCP/ IP

403

тая обязанность. Не слушайте тех, кто продолжает отговари вать вас от перехода на 1 Pv6. Кем вы хотите быть: Google ил и Microsoft Bing? Кроме того, есть аргументы в пользу внедрения протокола 1 Рvб в центрах обработки данн ых, где прямая с вязь с вне ш н и м м иром через 1 Pv4 не требуется. В этих ограничен­ ных средах у вас действительно есть возможность перейти на I Pvб и оставить 1 Pv4 поза­ ди, тем сам ы м упростив свою и нфраструктуру. Серверы , ориентированные на Интернет, могут общаться с помощью протокола 1 Pv4, даже если они маршрутизируют весь вну­ тренний и внутрен н и й трафи к через I Pvб. В заключен ие приведем несколько допол нительных соображен и й . •

П ротокол I Pvб уже давно готов к производству. Ошибки реали зации не я вляются серьезной проблемой. Ожидается, что он будет работать так же надежно, как и 1 Pv4. С точки зрения аппаратного обеспечения поддержка протокола I Pvб должна счи­ таться обязательной для всех новых приобретаем ых устройств. Сом нительно, что в наши дни вы можете найти какой-либо ком плект сетевого оборудования кор­ поративного уровн я , которы й н е поддерживает I Pvб, но многие потребительские устройства по-прежнему испол ьзуют 1 Pv4.

В книге мы сосредоточились на протоколе 1 Pv4, поскольку именно он является ос­ новной версией протокола TC P/ I P. Все , что касается версии I Pvб, м ы отговари ваем от­ дельно. К счастью для с истемных адм и нистраторов, верси и 1 Pv4 и I Pvб очень похожи . Если в ы знаете протокол 1 Pv4, то в ы знаете большую часть того, что вам следует знать о протоколе 1 Рvб. Основное разл ичие между этими версиям и заключается в том, что они испол ьзуют разные схе м ы адресации . В верс и и I Pvб использовано несколько новых концепций адресации и несколько новых обознач ен и й . Вот и все .

Пакеты и их инка псуля ция Система TC P/I P располагает средства м и поддержки целого ряда физических сетей и транспортных систе м , включая технологии Ethemet , Token Ring, M P LS ( Multiprotocol Label Switchi ng) , беспроводную технологию Ethemet , а также систе м ы с последователь­ н ы м и соедин е н ия м и . Управл ени е аппаратн ы м и устройства м и осуществляется на ка­ нальном уровне архитектуры ТСР/1 Р, а протоколам более высоких уровней неизвестно, как именно испол ьзуются аппаратные средства. Дан н ы е передаются по сети в виде пакетов, которые имеют макс и м ал ь н ы й размер, определяемый огран ичени я м и канал ьного уровня. Каждый пакет состоит из заголовка и полезного содержимого. Заголовок содержит сведения о том , откуда прибыл пакет и куда он направляется. В него могут также включаться контрольные сум м ы , и нформа­ ция, характерная для конкретного протокола, и другие и нструкци и , касающиеся обра­ ботки пакета. Полезное содержимое — это данные, подлежащие пересылке. Название базового блока передачи дан н ы х зависит от уровня протокола. На каналь­ ном уровне это кадр, или фре й м , в протоколе IP — пакет, а в п ротоколе ТС Р — сегмент. М ы будем придерживаться универсального терм ина » пакет » . Готовя щ и йся к отправке пакет передается в н и з п о стеку протоколов, и каждый про­ токол добавл яет в него собствен н ы й заголовок. Сформированный пакет одного прото­ кола становится полезн ым содержим ы м пакета, генерируемого следующим протоколом. Эта операция называется инкапсуляцие й . Н а принимающей стороне и нкапсул ирован­ ные пакеты восстанавл иваются в обратном порядке при прохожден и и вверх по стеку. Например, пакет U D P, передаваем ы й по сети Ethemet , упакован в трех разл и ч н ых » конвертах » . В среде Ethernet он » вкладывается» в простой физический фре й м , заго-

Часть 11. Работа в сетях

404

ловок которого содержит сведения об ап паратных адресах отправителя и бл ижайш е го п олучател я , дл и н е фре й ма и е го контрол ьной сум ме ( C RC ) . П олезн ы м содержи м ы м Ethe rnet-фpe ймa я вляется I Р- пакет. П олезное содержи мое I Р-пакета — это U D Р- пакет, и, наконец, полезное содержи мое U D Р-пакета состоит из собствен н о дан ных, подлежа­ щих передаче . Ком поне нты такого пакета изображены на рис. 1 3 . 2 . Заголовок Ethernet

Заголовок IPv4

14 байт

20 байт

Заголовок UDP

Данные приложения

8 байт

100 байт

Ethernet CRC 4 байт

Пакет UDP (108 байт) Пакет IPv4 (128 байт)

Фрейм Ethernet (146 байт)

Рис. 13. 2. Стандартный сетевой пакет

Ста нда рты формирования фреймов Ethernet На канал ьном уровне к пакетам доба вля ются заголовки и между н и м и вставл я ют­ ся разделител и . Заголовки содержат информацию об адресах канального уровня и кон ­ трольные сум м ы , а раздел ител и позвол я ют прин имающей стороне пон ять, где зака н ­ ч и вается один пакет и нач и нается другой. П роцесс добавления вспомогател ьных битов назы вается форм ирован ием фре й мов ил и кадровой разби вкой. На самом деле канал ьн ы й урове н ь разделен на две части: МАС ( подуровен ь M e d ia Access Cont rol ) и L LC ( п одурове н ь Link Layer Contro l ) . П одурове н ь М АС работает с аудиовизуал ьной информацией и передает пакеты по проводам. Подуровен ь LLC фор­ м ирует фрей м ы . В настоя щее время существует единственный стандарт формирован ия фреймов по тех­ нологии Ethernet: DIX Ethernet 1 1 . Кроме того, по историческим причинам используется еще нескол ько стандартов, основанных на стандарте I EE E 802.2, особен но в сетях N ovell.

Максимальный разм ер пере даваемого блока Размер сете вых пакетов огран и ч и вается как характеристи кам и а п паратн ых средств, так и требован иями п ротоколов. Например, объем полезного содержимого стандартного Ethe rnet-фpe ймa не может превышать 1 500 байт. П редел ьн ый размер пакета устанавл и­ вается на канальном уровне и называется макс и м альной еди н и це й п ередач и ( Maxi mum Transfer Unit — M T U) . Стандартн ые значения параметра MTU для разных видов сете й приведены в табл . 1 3 . 1 . Табл ица 1 3 . 1 . Максимальные размеры передаваемых блоков в сетях различных типов Тип сетевого соединения

Максимальная единица передачи

Etheгnet

1 500 байт ( 1 492 в спецификации 802.2)

I Pvб

( на любом аппаратном обеспечении)

Token Ring Двухточечные WА N -соединения Двухточечные канал ы ГВС ( Т 1 , ТЗ)

а

Н е менее 1 280 байт на уровне I P

К онфигурируется 6 К онфигурируется , обычно 1 500 или 45006 байт К онфигурируется , обычно 1 500 или 4500 байт

‘Дополнительную информацию об Ethernet-naкeтax «jumbo» см. в разделе 1 4. 1 . 6 Распространенные

значения таковы : 552, 1 064, 2088, 4508 и 8232. Иногда выбирается значение 1 500 для совме­ стимости с Etheгnet.

Глава 1 3 . Сети TCP/ IP

405

Протокол 1 Pv4 разделяет пакеты на такие фрагменты , чтобы их размер соответство­ требованиям к MTU конкретного сетевого соединения. Есл и пакет проходит через несколько сете й , в одной из них параметр MTU может оказаться мен ьш и м , чем в исход­ ной сети . В этом случае марш рутизатор , пересылающий пакет в сеть с меньш и м значе­ нием MTU , подвергнет пакет дал ьнейшей фрагментаци и . Фрагментаци я » на лету» нежелательна в условиях сильной загруженности м аршрути­ заторов. В протоколе 1 Pv6 эта возможность устранена. Пакеты по-прежнему могут фраг­ ментироваться , но эту задачу должен выполнять вызываюши й хост. В рамках протокола 1 Pv4 отправитель может обнаружить канал , способны й пропустить пакет с наименьш им показателем MTU , установив на пакете флаг » не фрагментировать» . Если пакет достигнет промежуточного маршрутизатора, который не с пособен его пропу­ стить, этот маршрутизатор вернет отправителю сообщение об ошибке ICM P. Пакет I C M P содержит показатель MTU сети, требующей пакеты меньшего размера, и этот показатель за­ тем становится ориентировочным размером для пакетов, отправляемых по данному адресу. Обнаружение МТU- пути в п ротоколе 1 Pv6 осуществляется аналогично, но пос коль­ ку промежуточн ы м маршрутизаторам н и когда не разрешается фрагментировать пакеты 1 Pv6 , все пакеты 1 Pv6 действуют так, как будто у н их вкл ючен флаг » не фрагментиро­ вать» . Л юбой пакет 1 Pv6 , который сли ш ком вел ик для разме ще н ия в н исходящем кана­ ле, вызывает отправку I С М Р-сообщения отправителю. В п ротоколе ТС Р путь M T U определ яется автомати чески , даже в верс и и 1 Pv4 . Протокол U D P такой возможности не и меет и переклады вает допол н ительную работу на уровен ь I P. П роблема фрагме нтации в п ротоколе lv4 может оказаться достаточ но коварной . Несмотря на то что выявление пути MTU должно автоматически разре ш ить конфл и к­ ты , иногда админ истратору приходится вме ш и ваться. Например, в виртуальной частной сети с тун нельной структурой необходимо проверять размер пакетов, проходящих через тун нел ь. Обычно и х начальный размер 1 500 байт, но когда к н и м добавляется тун ­ нельн ы й заголовок, размер пакетов становится равн ым примерно 1 540 байт и уже требу­ ется фрагментация. Уме н ьшение максимал ьного размера передаваемого блока позволяет избежать фрагментации и повысить производител ьность туннел ьной сети. П росмотрите справочные страницы команд ifconfig ил и ip-l ink , чтобы узнать, как настроить па­ раметр MTU сетевой платы . вал

1 3 .3 . АДРЕСАЦИЯ ПАКЕТОВ Подобно п исьмам и сообще ниям электронной почты, сете вые пакеты могут достич ь пун кта назначения тол ько при налич и и правил ьного адреса. В с истеме TC P/I P исполь­ зуется сочетан ие нескол ьких схем адресации . • •

Адреса МАС (media access control) для испол ьзования в сетевом оборудован ии. Сете вые адреса протоколов 1 Pv4 и 1 Pv6 для использования в программном обе ­ спече н и и . И мена ком пьютеров для использования пользователя м и .

А ппа ратная адресация (М АС ) Каждый сетевой и нтерфейс ком пьютера и м еет оди н МАС-адрес канал ьного уров­ ня, который отличает е го от других ком п ьютеров в физической сет и , а также один ил и

Часть 11. Работа в сетях

406

нескол ько I Р-адресов, идентифицирующих и нтерфейс в глобал ьной сети И нтернета. П оследнее утверждение стоит повторить: I Р-адрес идентифицирует сетевые интерфейсы, а не машины. (Для пол ьзователе й это различие не и меет знач е н и я , но адми н истраторы должны об этом знать.) Сам ы й н и ж н и й урове н ь адреса ц и и задается сете в ы м и ап паратн ы м и с редства­ ми. Например, Еthеrпеt -устройствам в процессе изготовл е н ия назначаются у н и кал ь­ ные шестибайтовые аппаратн ые адреса. Эти адреса традиционно записываются в виде ряда двухцифровых ш естнадцатеричных байтов, разделенных двоеточ иям и , например 0 0 : 5 0 : 8d : 9a : Зb : df. Сетевые платы Token Ring также и м е ют шестибайтовые адреса. В некоторых сетях с двухточеч н ы м соеди н е н и е м ( например, в Р Р Р-сетях) аппаратные адреса вообще не н уж н ы : адрес пункта назнач е н и я указывается непосредстве н н о п р и установке соеди­ нения. Ш естибайтовый Ethemet-aдpec разби вается н а две части : первые три байта опре­ деля ют изготовителя устройства, а последние три — выступают в качестве ун и кал ь­ ного се р и й ного номера, назначае мого изготовител е м . Систе м н ы е адм и н и страторы могут выяснить марку устройства , вызывающего п робл е м ы в сети , поискав трехбай­ тов ы й идентифи катор соответствующих пакетов в таблице идентифи каторов изгото­ вител е й . Трехбайтовые коды на самом деле представл я ют собой идентификаторы O U I (Organizationally U nique l dentifier — у н и кал ьн ы й идентифи катор орган и за ц и и ) , при­ с ваиваем ы е орган и зацией I E E E , поэтому их можно найти непосредствен но в базе дан­ н ы х I E E E по адресу s t a nda rds . i e e e . o r g / r e g a u t h / o u i . Разумеется, отнош е н ия между производителя м и м и кросхем . ком понентов и с исте­ мы носят слож н ы й характер , поэтому иде нтифи катор изготовителя , закодирован н ы й в МАС-адресе , может ввести пол ьзователя в заблужде н и е . Теоретически аппаратн ые адреса Ethemet должны назначаться н а постоя н н о й ос­ нове и оставаться н е измен н ым и . К сожал е н и ю , н екоторые сете вые платы допус ка­ ют програ м м ное зада н и е аппаратн ы х адресов. Это удобно при зам е н е испорче н н ых ком пьютеров ил и сетевых карт, МАС-адрес которых м е нять по те м ил и и н ы м причи­ нам нежелател ьно (например, если е го фил ьтруют все ваш и ком м утаторы , есл и ваш D Н С Р-сервер выдает адреса на основе МАС-адресов или МАС-адрес б ыл испол ьзован как л и це н зион н ы й кл юч для програм м ного обес пече н ия ) . Ф ал ьсифицируе м ы е МАС­ адреса могут также оказаться полезны м и , есл и вам необходимо п рон и к н уть в беспро­ водную сеть, ис пользующую механизм управления доступом на основе М АС-адресов. Одн а ко , чтобы не усл ожн ять с итуа ц и ю , мы рекоме ндуе м сохран я т ь у н и кальность МАС-адресов.

I Р-адресация Ш Дополн ительную и нформацию о технологии NAT и п ространствах ч астн ых адресов см . в разделе 1 3 .4.

Н а следующе м , более высоком , уровне ис пол ьзуется и н тернет-адресация ( ч а ще назы ваемая I Р-адресаци е й ) . I Р-адреса ап паратно н езависи м ы . В л юбом кон кретном сете вом конте ксте 1 Р-адрес иде нтифи цирует кон кретное и уни кал ьное место назна­ чен ия . Тем не менее не совсем точ но говорить, что I Р-адреса глобал ьно ун и кал ьн ы , потому что существует н ескол ько искл ючен и й : N AT использует оди н I Р-адрес и нтер­ фейса для обработки траф и ка для нескольких маш и н ; п ространства частных адресов I P — это адреса , которые могут ис пол ьзовать сразу в нескол ьких локал ь н ы х сетях,

Глава 1 3 . Сети TCP/IP

407

есл и эти адреса не вид н ы в И нтернете ; ал ьтернати вная адресация н азначает оди н I Р­ адрес нескольким машинам одновре менно. Соответствие между I Р-адресам и и аппарат н ы м и адресам и устанавл и вается на ка­ нальном уровне модели ТС Р/1 Р. В сетях, поддерживающих ш ироковешательн ы й режим (т.е. в сетях, позволяющих адресовать пакеты » всем ком п ьютерам дан ного физичес кого сегмента » ) , протокол ARP обеспеч и вает автоматическую привязку адресов без вмеша­ тельства системного адм и н истратора. В протоколе 1 Pv6 МАС-адреса интерфе йсов мож­ но испол ьзовать как часть I Р-адресов, благодаря чему преобразование I Р-адресов в а п ­ паратные адреса становится практически автоматическим. W Подробнее о протоколе ARP рассказы вается в разделе 1 3. 5 . 11

Адресация » имен ма ш и н m Дополн ительную и нформацию о системе DNS см. в главе 1 6 .

Пос кол ьку 1 Р-адреса представля ют собой дл и н н ые ч исла , запоминать их трудно. Операционные системы позволяют закреплять за I Р-адресом одно или н есколько текстовых имен , чтобы вместо 4 . 3 1 . 1 9 8 . 4 9 пользователь мог ввести rfc-edi tor . org. В системах U N IX и Linux это отображен ие можно осуществить с помощью статического файла (/etc/ hosts), базы дан н ых LDAP и, наконец, DNS ( Domain Name System) — глобальной системы доменных имен. Следует помн ить о том , что имя ком пьютера — это лишь сокраще н н ы й способ записи I Р-адреса, и о н относится к сетевому интерфейсу, а н е ком пьютеру.

П орты I Р-адреса иде нтифицируют сетевые интерфейсы ком п ьютера, н о они недостаточно кон кретн ы для идентификации отдел ьн ых процессов и служб, м ногие и з которых могут активно испол ьзоваться в сети одновремен но. П ротоколы ТС Р и U D P расширяют кон ­ цепцию I Р-адресов, вводя понятие порта . Порт представляет собой 1 6-разрядное ч исло, добавляемое к I Р- адресу и указы вающее кон кретный канал взаи модействия. Его з н а 2 4 . 8 . 175 . 64 / 2 8 Networ k : B roadc a s t : 2 4 . 8 . 175 . 65 HostMin : 24 . 8 . 175 . 7 8 24 . 8 . 175 . 7 9 H o s t Ma x : 14 Host /Net

28

00110000 . 00001000 . 10101 1 1 1 . 0 1 00 lllllll l . 11111111 . 1111111 1 . 1111 00000000 . 00000000 . 00000000 . 1 1 1 1

0101 0000 1111

000 1 1000 00011000 00011000 00011000 Class А

0000 0001 1110 1111

. 00010000 . . 00010000 . . 00010000 . . 00010000 .

10101 1 1 1 . 1010111 1 . 10101111. 1010111 1 .

0100 0100 0100 0100

Эти результаты позволяют н е только просто и понятно представить адреса , но и » ко­ пировать и вставлять» версии. Оче н ь полезная п рограмма. Есл и этот калькулятор вам по каким-то причинам не подойдет, воспол ьзуйтесь стан­ дартной утилитой Ьс, поскол ьку она может в ыполнять арифметические операции в лю­ бой с истеме счисле н и я . Установите основан и я систе м счисления для ввода и вы вода, используя директивы ibase и obase. Сначал а вы пол ните директиву obase, в п ротив­ ном случае ее резул ьтат будет и нтерпретироваться в зависимости от нового основания системы счисл е н и я , устаноWiе н ной директивой ibase.

CI DR: п ротокол бесклассовой междоменной маршрутизации Как и подсети , пря м ы м расширен ием которых о н я вляется, протокол C I D R основан на испол ьзован ии я вной маски подсети , определяющей границу между сетевой и ма­ ш и н ной частям и адреса. Н о , в отличие от подсетей , п ротокол C I D R доп ускает, чтобы сетевая часть была меньше, чем того требует класс адреса. Благодаря укороче нной маске воз н икает эффект объединения нескол ьких сетей для облегчен ия маршрутизаци и . По этой причине протокол C I D R иногда называют протоколом формирования суперсетей . W Протокол C I D R определен в документе RFC4632. П ротокол C I D R упрощает и нформацию о маршрутизаци и и устанавл ивает иерархию в этом процессе. Несмотря на то что протокол C I D R задумывался как временная мера для облегчения маршрутизации в рамках протокола 1 Pv6, он оказался достаточно мощным средством для решения проблемы роста И нтернета, возникшей в последнее десятилетие. П редположим , организации предоставл е н блок и з восьм и адресов класса С, про­ нум е рова н н ы х п осл едовател ьно от 1 92 . 1 44 . 0 . 0 до 1 9 2 . 1 44 . 7 . 0 (в нотаци и C I D R 1 92. 1 44.0.0/2 1 ) . Внутри самой орган изаци и адреса могут распределяться так : •

1 сеть с дли ной маски /2 1 — 2046 хостов, сетевая маска 255.255.248 .0;

8 сетей с длиной маски /24 — 254 хоста в каждой , сете вая мас ка 255.255.255.0;

глава 1 3. Сети TCP/ IP

41 3

1 6 сетей с м иной маски /25 — 1 26 хостов в каждой , сетевая м ас ка 255.255.255 . 1 28 ;

32 сети с м иной маски /26 — 6 2 хоста в каждой, сетевая маска 255.255.255. 1 92 и т.д.

Для перечислен н ых адресов не обязательно иметь 32 , 1 6 или даже 8 записей в таблице маршрутизаци и . Ведь все о н и ссылаются на хосты одной и той же орга низац и и , поэтому пакеты предварител ьно н ужно доставлять в общи й приемн ы й пункт. В табли­ цу маршрутизации достаточно внести зап ись 1 9 2 . 1 44.0.0/2 1 . П ротокол C I D R позволяет даже выделять фрагменты адресных пространств классов А и В, благодаря чему увеличи­ вается ч исло доступных адресов. Внутри сети доп ус кается с м е ш е н и е подсете й с разной длиной маски , есл и только они не перекрывают друг друга. Это называется фор мирова н и е м подсетей пере м е н ­ ного размера . Например , и нтерн ет- провайде р , которому в ыделе н а адрес ная область 1 92 . 1 44 . 0 . 0/2 1 , может создать групп у сете й с маской /30 для коммутируе м ых Р РР ­ клиентов, несколько сетей с маской /24 — д11 я крупн ых клиентов и р яд сетей с м ас кой /27 — д11 я более мелких компаний. Все хосты кон кретной сети должны конфигурироваться с помощью одной сетевой маски . Нельзя д11 я одного хоста задать мину маски /24, а для другого — /25.

Выделение адресов Формал ьн о назначаются л и ш ь адреса сете й . Организаци и должн ы самостоятельно определять номера комп ьютеров и закреплять за н и м и I Р-адреса. Деле ние на подсети также осуществляется произвольно. Организация I CAN N в административном порядке делегировала полномочи я по рас­ предел е н и ю адресов тре м регионал ьн ы м организация м , которые предоставля ют блоки адресов и нтернет-провайдерам в рамках своих регионов (табл. 1 3 .4). Провайдеры , в свою очередь, вьщеля ют адреса отдельным кл иентам . Только крупные провайдеры могут напря­ мую посылать запросы в один из регистров, спонсируемых организацией I CAAN . Таблица 1 3 .4. Региональные реестры IР-адресов Орrаниэацин

Веб-адрес

ОхватываемыА регион

ARI N APNIC

arin . net

С еверная часть Карибских островов Азия и Океания , включая А встралию и Н овую З еландию Африка Центральная и Южная А мерика, часть Карибских островов Е вропа и прилегающие регионы

a p n i c . ne t

AfriNIC LACNIC

adrini c . ne t

RIPE NCC

ripe . ne t

l a cn i c . n e t

Делегирова н ие пол номоч и й организации I CAN N региональным регистрам обеспе­ ч и вает должную агрегацию адресов в табли цах маршрутизации магистральных сете й . Клиенты, получившие адреса о т своего провайдера, не обяза н ы иметь маршрутн ые за­ писи в магистрал ьных серверах. Достаточно одной записи , ссылающейся на провайдера.

Ч астные адреса и система NAT Другое временное решение проблемы сокращающегося адресного пространства п ро­ токола I Pv4 заключается в испол ьзова н и и частн ы х областей I Р-адресов , описан н ы х в докуме нте R FC 1 9 1 8 . Частные адреса используются только в о внутрен н е й сети пред­ приятия и н икогда не мар шрутизируются в И нтернет ( во вся ком случае , преднамерен ­ но) . Преобразовани е частных адресов в адреса, вьщеленн ые и нтернет-провайдером , осу­ ществляется погран и ч н ы м маршрутизатором .

Часть 11. Работа в сетях

41 4

Документ RFC 1 9 1 8 определяет, что одна сеть класса А, 1 6 сетей класса В и 256 сетей класса С резервируются для частного испол ьзования и н и когда не в ыделя ются глобал ь­ но. В табл . 1 3 . 5 показаны диапазо н ы частных адресов ( каждый диапазон представл е н в более короткой нотации протокол а C I D R) . Табnица 1 3 . 5 . IР-адреса, зарезервированные дn я частного испопьзования Кnасс

Начапо

Конец

Диапазон CIDR

в

1 0.0.0.0 1 72. 1 6.0.0 1 92. 1 68.0.0

1 0. 255.255.255 1 72.З 1 . 255. 255 1 92 . 1 68.255.255

1 0.0. 0.0/8 1 72. 1 6.0.0/1 2 1 92. 1 68.0.0/ 1 6

А

с

И значально идея состояла в том , чтобы хосты могл и самостоятельно выбирать класс адресов из указанных возможностей и правильно определять свой размер. Однако в на­ стоящее врем я протокол C I D R и подсети стал и универсал ьн ы м инструментом , поэтому дл я всех новых частных сете й целесообразнее всего испол ьзовать адреса класса А (раз­ умеется, с подсетям и ) . Для того чтобы хосты , ис пол ьзующие частн ы е адреса, могл и получать доступ в И нтернет, н а пограничном маршрутизаторе организации должна выполняться с исте­ ма NAT ( N etwork Address Translation — трансляция сетевых адресов) . Эта система пере­ х ватывает пакеты и заменяет в них адрес отправителя реал ьным вне ш н и м I Р-адресом. Может также происходить замена номера исходного порта. Систе ма хран ит табл и цу преобразовани й между внутре н н и м и и внеш н и м и адресам и/портами , чтобы ответные пакеты доставлялись нужному адресату. Многие варианты системы NAT на самом деле выполняют преобразование адресов пор­ тов ( Port Addre� Tmnslation — РАТ): они используют оди н внешний I Р-адрес и соединяют его с несколькими внутренними хостами. Например, эта конфигурация по умолчанию уста­ новлена в большинстве популярных маршрутизаторов, использующих кабель и модемы. На практике реализации систем NAT и РАТ очень похожи, поэтому они обе называются NАТ. Хост, испол ьзующий с истему NАТ, запрашивает небольшой сегм е нт адресного п ро­ странства у провайдера, но большинство адресов теперь используется дл я внутрисистем­ н ых привязок и н е назначается отдельным ком п ьютера м . Есл и хост позднее пожелает смен ить провайдера, потребуется л и ш ь измен ить конфигурацию пограничного маршру­ тизатора и е го с исте м ы NАТ, но не самих ком пьютеров. Крупные организаци и , использующие адреса NAT и R FC l 9 1 8 , должны и меть неко­ торую форму центральной координации , чтобы все хосты , независи мо от их отдела или адм инистративной груп п ы , и мели уникал ьн ые I Р-адреса. Ситуация может осложниться , когда одна компан и я , испол ьзующая адресное пространство R FC 1 9 1 8 , приобретает дру­ гую ком панию, которая делает то же самое, или объединяется с ней. Части объединен­ ной организации необходимо часто перенумеровывать. Существует возможность заставить операционные систе м ы U N IX ил и Linux вы пол ­ нять функции N АТ, хотя в о м ногих организациях предпочитают делегировать эти обя ­ занности маршрутизаторам или устройствам подключения к сети .6 Вопрос ы , с вязан ные с кон кретны м и поставщикам и , мы обсудим в этой главе позднее. Неправильная конфигурация с истемы NAT может привести к тому, что пакеты с част­ ными адресами начнут проникать в И нтернет. Они могут достичь хоста н азначен ия , но от-

» Разумеется , м ногие маршрутизаторы в н астоя щее время могут запускать встрое н н ы е ядра систе м ы Linux. Но даже в этом случае их изначальные с исте м ы остаются более эффекти в н ы м и и безопас н ы м и , ч е м ун иверсал ьные компьютеры , которые также пересылают пакеты .

Глава 1 3. Сети TCP/ IP

41 5

ветные пакеты не будуг получены. Организация CAI DA7, замеряющая трафик магистраль­ ных сетей , сообщает о том , что О, 1 -0 , 2 % пакетов, проходящих по магистрали , и м е ют либо частные адреса, либо неправильные контрольные суммы. На первый взгляд показа­ тель кажется незначительным, но на самом деле это приводит к тому, что каждую минуту в сети циркулируют тысячи пакетов. Информацию по статистике И нтернета и средствам измерения производительности глобальной сети можно получ ить на сайте ca ida . o r g . Одной из особен ностей системы NAT является то, что хост Интернета не может на­ прямую подключиться к внугрен н и м машинам организации. Для того чтобы преодолеть это огран ичение, в некоторых реализациях систе м ы NAT разрешается создавать тунне­ ли, которые поддерживают пря м ые соединения с выбран н ы ми хостами . н Еще одн а проблема закл ючается в том , что некоторые приложен ия встраи вают I Р­ адреса в информационную часть пакетов. Такие приложен и я не могуг нормально ра­ ботать совместно с NАТ. К н и м относятся о пределе н н ые протоколы маршругизаци и , програм мы потоковой доставки дан ных и ряд FТР-ком анд. Система NAT иногда также отключает виртуал ьн ые частные сети (virtual private network — YPN ) . Система NAT скрывает внугреннюю структуру сети. Это может показаться преимуще­ ством с точки зрен ия безопасности, но специалисты считают, что на самом деле система NAT не обеспечивает должную безопасность и уж во всяком случае не устраняет потреб­ ность в брандмауэре. Кроме того, она препятствует попыткам оценить размеры и топологию Интернета (см. документ RFC4864, Local Network Protection /or !Рvб, содержащий полезную информацию о реальных и мнимых преимуществах системы NAT и протокола 1 Pv4).

Ад реса ция в ста н дарте I Pvб Адреса 1 Pv6 имеют длину 1 28 бит. Эrи длинные адреса изначально бьvtи предназначен ы дл я решения проблемы исчерпания I Р-адресов. Однако теперь они, помимо прочего, позво­ ляют справиться с проблемами маршругизации , мобильности и локальности ссылок. Гран и ца между сетевой частью и машинной частью 1 Рv6-адреса фиксирована на /64, поэтому не может возн икн угь н и каких разногласий ил и путаницы в отнош е н и и того, насколько длин ной является сетевая часть адреса на самом деле. И н ы м и словами , ис­ тин ной подсети в мире J Pv6 больше не существует, хотя терми н подсеть сохраняется как синоним локальной сети . Несмотря на то что номера сетей всегда и меют дли н у 64 бит, маршрутизаторы не должны учитывать все 64 бита при прин ятии решений о маршрути­ зации. Они могут маршрутизировать пакеты по префиксу, как и в п ротоколе C I D R.

Нотация адресов /Р vб Стандартная нотация адресов 1 Pv6 делит 1 28 бит адреса на 8 групп по 1 6 бит каждый , разделенных двоеточиями. Например, 2 6 0 7 : f 8 b 0 : 0 0 0 a : 0 8 0 6 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : 2 0 0 e9 7CA I DA ( Cooperative Association for l nternet Data Analysis — совместная ассоциация по анализу данн ы х в сети И нтернет) находится в Центре суперкомп ьютеро в , который рас п оложен в здании Калифорнийского университета в Сан -Диего ( www . c a i da . o r g ) . 8 М ногие м а р шрутизаторы поддержи вают также стандарты U n i versal Plug and Play ( U PnP) , продвигаемые компанией Microsoft . Эти стандарты позволяют внутренним машинам устанавливать собствен ные динамические туннели NАТ. В зависимости от точк и зрения пользователя , это может оказаться как удачным решени е м , так и угрозой безопасности . При желан ии эту функциональную возможность марш рутизатора легко отключить. �Это настоя щий 1Рv6-адрес , поэтому не используйте ero в своих системах даже для экспериментов. В стандарте RFC3 849 предполагается , что в документаци и и п ри м е рах указа н ы адреса 1 Pv6 в блоке с п р е ф и ксом 2 О О 1 : db В : : / З 2 . Н о мы хотели показать реальный п р и мер, которы й маршрутизируется в сети И нтернет.

Часть 11. Работа в сетях

41 6

Каждая 1 6-б итная группа представлена четырьмя ш естнадцатерич н ы м и ц ифрам и . Эrо отл ичается от нотации 1 Pv4, в которой каждый байт адреса представлен десятичн ы м номером. Несколько условных упрощен и й помогают о гран ичить объем ввода, н еобходимо­ го для представления адресов 1 Pv6. Во- первых, вам н е нужно указывать ведущие н ул и внутри груп п ы . Групп а О О О а в третьей группе выше может быть записана просто как а , а четвертая группа 0 8 0 6 как 8 0 6 . Групп ы с о значением 0 0 0 0 должны быть представ­ лены как О. Применен ие этого правила уменьшает адрес, приведе н н ы й выше, до следу­ ющей строки: —

2 60 7 : f8bO : a : 8 0 6 : 0 : 0 : 0 : 2 00e

Во-вторых, в ы м ожете заме нить любое кол ичество смежных нулевых 1 6-разрядных групп двойн ы м двоеточием: 2 60 7 : f8b0 : a : 8 0 6 : : 2 0 0 e

Символы : : в адресе можно использовать только оди н раз. О н и могут отображаться как первый или последний ком понент. Например, адрес обратной связи I Pv6 (аналоги ч ­ н ы й 1 27.0.0. 1 в 1 Pv4) равен : : 1 , что эквивале нтно О : О : О : О : О : О : О : 1 . Исходная спецификация адресов 1 Pv6, R FC492 l , описывала эти упрощения нотации , н о не требовала их использования. В результате для зап иси заданного 1 Рv6-адреса может существовать несколько с пособов, совместим ых со спецификацией RFC49 1 , что илл ю­ стрируется нескол ьк им и версиями приведен ного выше примера. Эrа полиморфность делает поиск и сопоставление трудной задаче й , потому что адре­ са перед сравнением необходимо нормализовать. Это проблема: мы н е можем ожидать, что стандартное програ м м ное обесп ечение для обработки данных, такое как электрон ­ ные таблицы, языки сценариев и базы данных, знает подробности нотации 1 Pv6. Документ R FC5952 обновил спецификаци ю RFC492 l , чтобы сделать упрощен н ые обозначения обязател ьн ы м и . Он также добавил еще несколько правил , гарантирующих, что каждый адрес и меет только одно текстовое представление. •

Ш естнадцатеричные цифры a — f должны быть представлены строчн ы м и буквами .

Эле мент : : не может заменять одну 1 6-битную группу. ( Просто используйте : О : . )

Если есть несколько групп , которые можно заменить элементом : : , то выбирать следует максимально дл и нную последовательность н улей.

Н а практике все еще сущест вуют адреса , несовмести м ые со с п е ц и ф и ка ц и е й RFC5952 , и почти все сетевое программное обеспечение их тоже принимает. Однако м ы настоятельно рекомендуем следовать правилам R FC5952 в ваших конфигурациях, веде­ н и и документаци и и программном обеспечении.

Пр еф иксь1 /Рvб Адреса 1 Pv4 н е были предназначены ДII Я географической класте ризаци и наподобие телефон н ых номеров или почтовых и ндексов, но кластеризация бьmа добавлена пост­ фактум в виде соглаш е н и й C I D R. ( Разумеется, соответствующая » география» на самом деле представляет собой пространство маршрутизаци и , а не физическое местоположе­ ни е .) П ротокол C I D R бьm настолько технически успеш н ы м , что иерархическое перена­ значение сетевых адресов теперь принимается во всем протоколе 1 Pv6. Ваш интернет-провайдер I Pv6 получает блоки префиксов 1 Pv6 от одного и з регио­ нальных реестров , перечислен н ых в табл . 1 3.4. И нтернет-провайдер, в с вою очередь, назначает вам префикс , которы й вы добавляете к локальным частям адресов, обычно

Глава 1 3. сети TCP/ IP

41 7

на пограничном маршрутизаторе . Организации могут с вободно устанавл ивать границы делегирования в назнач е н н ых им адресных пространствах. Всякий раз, когда префикс адреса представляется в текстовой форм е , протокол 1 Pv6 использует обозначение C I D R для представления дл и н ы префикса. Общий шаблон име­ ет следующи й вид:

/Рvб-адрес/преф икс-длина-в -д есятичном -виде Часть 1 Рv6-адреса приведена в предыдушем разделе . Это должен быть пол норазмер­ ный 1 28-разрядны й адрес. В большин стве случаев биты адресов за префиксом устанав­ ливаются равными нулю. Однако иногда бывает необходимо указать полный адрес хоста вместе с длиной префикса; намерение и с мысл обычно ясны из контекста. 1 Рv6-адрес , указанн ы й в предыдущем разделе , приводит к серверу Google. 3 2-разряд­ ный префикс, который маршрутизируется на североамериканской и нтернет- магистра­ ли, имеет вид: 2 607 :

f8b0 : : / 3 2

В этом случае адресн ы й префикс был присвоен региональным интернет-регистрато­ ром ARI N непосредстве нно компани и Google. Это можно проверить, просмотрев пре­ фикс на сайте a r i n . ne t . 1 0 Промежуточ н ы й и нтернет-провайдер отсутствует. Ком пания Google отвечает за структурирование оставш ихся 32 бит сетевого номера по с воему ус­ мотрению. Скорее всего , в и нфраструктуре G oogle используются нескол ько допол н и ­ тельных уровней префиксов.

Автомати ческая нумерация машин Идентификатор 64-битного и нтерфейса м аш и н ы (маш и нная часть адреса 1 Pv6) мо­ жет быть автоматически получен из 48-разрядного МАС-адреса и нтерфейса (аппаратно­ го) и нтерфейса с помощью алгоритма, известного как » изме н е н н ы й E U I -64″ , докуме н ­ тированного в спецификации RFC429 I . В частности , идентификатор и нтерфейса представляет собой тол ько МАС-адрес с двумя байтами O x FF FE , вставлен н ы м и в середин е , и одни м и н вертирова н н ы м битом . И нвертированн ы й бит — это седьмой самы й старш и й бит первого байта; други м и слова­ м и , вы применяете операцию XOR к первому байту и ч ислу О х 0 2 . Например, на интер­ фейсе с М АС-адресом О О : l b : 2 1 : 3 О : е 9 : с 7 идентификатор автоматически сгенериро­ ванного интерфейса будет равен O�l b : 2 1 f f : fе З О : е 9 с 7 . П одчеркнутая цифра равна 2 , а н е О, из-за и нвертированного бита. Эта схема позволяет автоматически нумеровать маш и н ы , что удобно для с исте м н ых адми н истраторов, поскольку и м достаточно управлять только сетевой частью адресов. То, что МАС-адрес можно увидеть на уровне протокола I P, и меет как хорошие, так и плохие последствия. Хорошая часть состоит в том , что н умерация машин м ожет быть полностью автоматической. Плохая часть закл ючается в том , что изготовител ь и н тер­ фейсной платы кодируется в первой половине МАС-адреса (см . раздел 1 3 . 3 ) , поэтому вы неизбежно частично отказываетесь от конфиденциальности. Это раскрывает хакерам часть и н формации об архитектуре сети. Стандарты 1 Pv6 указывают на то, что серверы не обязаны испол ьзовать МАС-адреса для получения идентификаторов ком пьютеров ; о н и могут использовать любую с истему н умерации . 1 0 8 этом случае дли н а префи кса блока адреса, н азначен ного регистратором AR1 N , и записи табл и цы маршрутизации одинаковы, но это не всегда верно. П рефикс распределен и я определяет адми н истративную гра н и ц у, тогда как преф и кс маршрутизаци и относится к местоположе нию маршрутного пространства.

418

часть 11. Работа в сетях

Виртуальные серверы имеют виртуальные сетевые и нтерфейсы. МАС-адреса, связан­ ные с эти м и интерфейсами , обы ч н о рандомизирован ы , что гарантирует уникальность тол ько в кон кретном локал ьном контексте .

Автомати ческая конф игурация локальных а дресо в Автоматичес к и с ге нерирован н ы е номера компьютеров, оп исан н ы е в предыдуще м разделе , объединяются с несколькими другими простыми фун кция м и 1 Pv6, чтобы обе­ спечить автоматическую настрой ку сети для и нтерфейсов 1 Рvб. Общая схема называет­ ся S LAAC (State Less Address AutoConfiguration ) . Конфигурация S LAAC для и нтерфейса нач инается с назначени я адреса локальной сети , которая и меет фикси рова н н ы й сете­ вой адрес f е В О : : / 6 4 . Ч асть адреса, определя ющая машину, устанавл и вается на основе МАС-адреса и нтерфейса, как описано выше. Протокол 1 Pv6 н е и меет ш ироковещательных адресов в стиле 1 Pv4 как таковых, но тер­ м и н локальная сеть и грает примерно ту же роль и означает «данную физическую сеть» . Маршрутизаторы н икогда не пересылают пакеты, отправленные по адресам в этой сети . П осле того как был установл е н локальн ы й адрес связи для и нтерфейса, стек прото­ кола 1 Pv6 отправляет пакет I C M P Router Solicitation (запрос к маршрутизатору по про­ токолу I C M P) на адрес м ногоадресатной рассылки , вкл ючающей все марщрутизаторы . Маршрутизаторы отвечают пакетами сообщен и й I C M P Router, в которых перечисле­ ны сетевые номера 1 Pv6 (на самом деле, префиксы ) , испол ьзуемые в сети . Если в одной из этих сетей установлен флаг автоконфигурации ( «autoconfiguration О К» ) , запраши вающи й хост назначает допол н ител ьн ы й адрес своему и нтерфейсу, кото­ ры й объединяет часть сети , объявляемую маршрутизатором , с частью автоматически ге­ нерируемого адреса хоста, создан ного с использованием модифицированного ал горитма E U I -64. Другие поля в анонсе маршрутизатора позволя ют ему идентифицировать себя ка к соответствующий шлюз по умолчанию и передавать сетевой параметр MTU . В конечном резул ьтате новый хост становится пол ноправн ы м элементом сети 1 Рvб без необходимости запус ка какого-либо сервера ( кроме м аршрутизатора) и без какой­ л ибо локальной конфигурац и и . К сожалению, эта система не расп ростран яется на кон ­ фигураци ю програ м много обеспечения более в ысокого уровня , такого как D N S , поэто­ му вы все равно должны запускать традицион н ы й сервер D H CPv6. m Дополнител ьную информацию ПО протоколу DCH P см . в разделе 1 3. 7 . И ногда можно встретить сетевую автоматическую конфигураци ю 1 Pv6, связанную с именем, получен ному по протоколу обнаружен ия соседей (Neighbor Discovery Protocol , N D P). Хотя протокол N D P описывается в документе R FC486 1 , этот тер м и н на самом деле довол ьно расплы вчатый. О н охватывает использова н ие и интерпретацию разл и ч ­ ных типов пакетов I C M Pv6 , н екоторые из которых связа н ы только с перифер и й н ы м до­ ступом к обнаружен и ю сетевых соседей . С техн ической точ ки зре н и я взаимосвязь за­ кл ючается в том , что описанная выше п роцедура S LAAC испол ьзует некотор ы е , но не все , типы I C M Pv6, определ ен н ые в документе R FC486 1 . П роще назвать это S LAAC или «автоконфигурацией 1 Pv6» и зарезервировать тер м и н обнаружение соседа для описан но­ го процесса сопоставления I P- M AC , описанного в разделе 1 3 . 5

Туннелирование /Р vб Для облегчения перехода от 1 Pv4 к 1 Pv6 был и п редложен ы разл и ч н ы е схе м ы , в ос­ новном ори е н тирова н н ы е на с пособы тун нелировани я трафика 1 Pv6 через сеть 1 Pv4 для ком пенсации пробелов в поддержке 1 Pv6. Две ш ироко испол ьзуе м ы е систе м ы тун-

Глава 1 3. С ети TCP/ IP

41 9

нелирования называются 6to4 и Teredo; последни й , н азванн ы й в честь семьи древес­ ных чер ве й , сверлящих деревья , может испол ьзоваться на системах, расположе н н ых за устройством NАТ.

Источники информации о протоколе /Рvб Н иже перечислены некоторые полезные источн и ки информации о протоколе 1 Pv6 . •

wo r l d i pv б l a u n c h . c o m — м н ожество разнообразной и нформации о протоколе I Pvб.

RFC3587 — спецификация /Рvб Global Unicast Address Fonnat.

R FC429 I

спецификация Version 6 Addressing Architecture.

1 3 .5. МАРШРУТИЗАЦИЯ Маршрутизация — это процесс н аправления пакета по лабиринту сете й , находящих­ ся между отправителем и получател е м . В системе TC P/I P маршрутизация происходит примерно так , как путешествен н и к , первый раз посетив ш и й страну, находит н ужн ы й ему дом , задавая вопросы м естны м жителям. Первый человек, с которы м он заговорит, возможно, укажет ему нужны й город. Войдя в город, путеш ествен н и к с просит другого человека, и тот расскажет, как попасть на нужную ули цу. В конце концов наш путеше­ ственник подойдет достаточно близко к конечному пункту своих странстви й , чтобы кто­ нибудь указал ему дом , которы й он и щет. Маршрутная и н формация в системе TC P/ I P и м еет форм у правил (маршрутов) , на­ пример: «Для того чтобы достичь сети А, посылайте пакеты через ком пьютер С». Часто существует и стандартн ы й маршрут. В нем объясняется , что нужно делать с пакетам и , предназначе н н ы м и для отправки в сеть, маршрут к которой не указан явным образом. Дан н ые маршрутизации хранятся в одной из табли ц ядра. Кажды й эле м е н т этой таблицы содержит нескол ько параметров , включая сетевую маску. Для н аправл е н и я пакета по заданному адресу ядро подбирает н а иболее кон крет н ы й маршрут (т. е . тот, где самая дл и н ная маска ) . Если н и оди н из маршрутов ( в том ч исле стандартн ы й ) н е подходит, т о отправителю возвращается I С М Р-сообщение вида » network unreachaЫ e » (сеть недоступна). Слово » маршрутизация » широко употребляется в двух различных смыслах: •

процедура поиска сетевого адреса в специал ьной таблице для передачи пакета в пункт е го назначен и я ; процесс построен ия этой таблицы.

Н иже м ы рассмотрим , как осуществляется переадресация пакетов и как вручную доба­ вить или удалить маршрут. Более сложные вопросы, связанн ые с работой протоколов марш­ рутизации, создающих и обслуживающих маршрутные таблицы, освещаются в главе 1 5.

Таблицы ма рш рутизации Табл ицу маршрутизации можно просмотреть с помощью команды i p route show в системе Linux или netstat — r в с истеме Free B S D . Команда netstat в с истеме Linux также существует и продолжает применяться. Мы используем ее в примерах просто, что­ бы не приводить две разные версии одного и того же вывода. Версия ip в ыдает такое же содержимое , но в другом формате.

Часть 11. Работа в сетях

420

Команда ne tstat — rn запрещает поиск дом е н н ых и м е н в с исте ме D N S и выводит всю и нформацию в числовом виде , что в принципе полезнее. Н иже пр иводится табли ца маршруrизаци и I Pv4, которая должна дать читателя м более ясное представление о том , что такое маршруr. r e dh a t $ nets tat — rn Destination Genma s k 132 . 236 . 227 . О 255 . 255 . 255 de f a u l t О.О.О.О 132 . 23 6 . 2 12 . О 255 . 255 . 255 1 3 2 . 2 3 6 . 22 0 . 64 2 5 5 . 255 . 2 55 127 . 0 . 0 . 1 255 . 255 . 2 55

.0 . 1 92 . 1 92 . 255

G a t e wa y 132 . 236 . 227 132 . 23 6 . 227 1 32 . 2 3 6 . 2 12 132 . 23 6 . 2 12 127 . 0 . 0 . 1

. . . .

93 1 1 6

Fl U UG U UG u

MS S 1500 1500 1500 1500 3584

I fa c e ethO ethO ethl e th l lo

В рассм атри ваемой с истеме есть два сетевых и нтерфе йса: 1 32 . 2 36 . 2 2 7 . 9 3 ( e t h O ) в сети 1 32 . 2 36. 227.Q/24 и 1 32.236.2 1 2 . 1 (e t h l ) — в сети 1 32. 236.2 1 2 .Q/26. Поле de s t i na t i on обычно содержит адрес сети. В поле g a t ew a y отображается адрес локального сетевого интерфейса или соседнего хоста; в ядре систе м ы Linux для вызова шлюза, установленного по умолчан ию, в поле g a teway может быть записан адрес О.О.О.О. Например, четвертый маршруr указывает, что для достижения сети 1 32 . 236. 220.64/26 пакеты следует посьшать в шлюз 1 32 . 2 36. 2 1 2 . 6 через и нтерфейс e t h l . Вторая запись со­ держит описание стандартного маршруrа. П акеты , не адресованные явно н и в одну из трех указанных сете й (или самому комп ьютеру), будуr направлены в стандартн ы й шлюз 1 32. 236.227 . 1 . Ком п ьютеры могут посылать пакеты тол ько тем шл юзам , которые физически под­ клю ч е н ы к той же сети. Л о кал ьн ы е ком п ьютеры м о гут пере м е щать пакеты только на оди н шаг в направле н и и пункта н азначения, поэтому в него бессм ысле н но включать и нформацию о шл юзах , не я вляющихся смежн ы м и в таблице локал ьной маршруrи­ заци и . Каждый шлюз, ч ерез которы й проходит пакет, при н и м ает следующее решение о его перемеще н и и , анал изируя собствен ную табл и цу локальной маршруrизаци и . 1 1 Вести таблицы маршруrизаци и можно статически, динамически или комбинирован­ ным способом. Статический маршруr задается в явном виде с помощью команды route ( Free B S D ) . О н должен оставаться в табли це маршрутизаци и в теч е н и е все го вре м е н и работы систе м ы . Во многих случаях такие маршруrы задаются н а этапе начал ьн о й за­ грузки с помощью одного из сценариев запус ка систе м ы . Например, команды в системе Linux ip route add 1 3 2 . 2 3 6 . 2 2 0 . 6 4 / 2 6 via 1 3 2 . 2 3 6 . 2 1 2 . 6 dev ethl ip route add default via 1 3 2 . 2 3 6 . 2 2 7 . 1 dev ethO

добавляют, соответстве н но, ч етвертый и второй маршруrы из ч исла тех , что отобража­ ются выше командой netstat — rn (первый и третий маршруrы добавляются командой i fconfig при конфигурирова н и и и н терфейсов e t h O и e t h l ) . Эквивал е нтная команда в системе Free B S D имеет вид route add -net 1 3 2 . 2 3 6 . 2 2 0 . 6 4 / 2 6 gw 1 3 2 . 2 3 6 . 2 1 2 . 6 ethl route add default gw 1 3 2 . 2 3 6 . 2 2 7 . 1 ethO

П оследн и й маршруr также добавляется на этапе начальной загрузки. Он определяет интерфейс обратной связи (loopback i nterface ) , препятствующ и й пакетам , которые ком ­

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

11

Маршрутизация по 1 Р-адресу отправителя является исключением из этоrо правила; см. раздел 1 3 . 8 .

Глава 1 3. Сети TCP/ I P

421

В относительно стабильной локальной сети статическая маршрутизация я вляется до­ статочно эффектив н ы м реше нием. Эта с истема проста в управл е н и и и надежна в экс­ плуатаци и , но требует знан и я с исте м н ы м администратором топологии сети на момент начал ьной загрузки , а также того, чтобы эта топология в периоды между загрузкам и не изменялась. Больш инство ком п ьютеров локал ьной сети имеет единстве н н ы й вы ход во в н е ш н и й м и р , поэтому маршрутизация осуществляется оче н ь просто: достаточ н о на этапе н а ­ чал ьной загрузки добавить стандарт н ы й маршрут. Ком п ьютер может получ ить ста н ­ дартный маршрут в месте со своим I Р-адресом у сервера D H C P (этот п ротокол описан в разделе 1 3 . 7 ) . В сетях с более сложной топологией требуется динамичес кая маршрутизация . О н а осуществля ется процессом -демоном , которы й ведет и модифицирует табли цу маршру­ тизации. Демоны маршрутизации , «обитающие» на различн ых ком пьютерах, взаимо­ действуют друг с другом с целью определения топологии сети и решен ия вопроса о том , как добраться до удален н ых адресатов. Существует несколько таких демонов. Подробно они будут рассмотрен ы в главе 1 5.

Директи вы переадреса ции протокола ICMP Несмотря н а то что протокол I P не предусматривает средств управления маршрутной информацией , в нем имеется м еханизм контроля наруш е н и й : директи вы переадреса­ ции протокола I C M P. Есл и маршрутизатор направляет пакет ком пьютеру, находящему­ ся в той же сети, из которой этот пакет б ыл получ е н , то что-то работает н е п равиль­ но. Поскол ьку отправитель, маршрутизатор и марш рутизатор следующего перехода находятся в одной сети , то пакет можно послать не через два перехода , а через оди н . Маршрутизатор делает в ывод о том , что табл ицы м аршрутизации отправителя я вляются неточн ы м и или непол н ы м и . В этой ситуации маршрутизатор может уведом ить отправителя о проблеме с помо­ щью переадресующеrо I С М Р-пакета. В таком пакете сообщается следующее: » Н е нужно посылать мне пакеты для хоста .ххх ; их следует адресовать хосту ууу » . Теоретически , получи в директиву переадресаци и , отправитель может обновить свою таблицу маршрутизаци и , чтобы следующие пакеты , предназначенные дан ному адресату, шли по более п рямому пути. На практике переадресация не подразумевает этапа ауте н ­ тифи кации и поэтому н е может считаться доверен ной. Маршрутизатор может проиг­ норировать получ е н н ую команду перенаправить трафик в другое место, но чаще всего систем ы U N IX и Liпux п ытаются это сделать по умолчанию. В таких ситуациях н еобхо­ димо уточнить возможн ые источн и ки команд переадресаци и в своей сети и откл ючить их, если они могут создать проблемы. В Liпux допусти мость I СМ Р-ди ректив определяется эле ментом accept_ redirects файловой с исте м ы /proc. О том , как проверять и устанавливать этот и подобные ему параметры, рассказывается в разделе 1 3 . 1 О . В с истеме Fre e B S D допустимость переадресаци и I C M P управляется параме­ трам и n e t . i n e t . i cmp . drop red i re c t и n e t . i n e t б . i cmp б . re d i r a c cept соответствен но. Для того чтобы игнорировать переадресацию установите их равны м и един и це и нулю соответствен но в файле /etc/ sysctl . conf. (Для активации новых установок н еобходимо в ы пол н ить перезагрузку ил и ко­ манду sudo /etc/rc . d/ sysctl reload) .

Часть 1 1 . Работа в сетях

422

1 3 .6. ARP: ПРОТОКОЛ ПРЕОБРАЗОВАНИЯ АДРЕСОВ в 1 Pv4 и 1 Pv6 Нес мотря н а то что I Р-адреса явля ются аппаратно-независ и м ы м и , для фактиче­ ской передачи дан н ы х н а канал ьном уровне должны применяться аппаратные адре­ са 1 2 . В протоколах 1 Pv4 и Jv6 испол ьзуются разные протокол ы , которые практически одинако в ы м образом определя ют, какой а п парат н ый адрес связан с тем и л и и н ы м I Р-адресом . прото­ В протоколе 1 Pv4 испол ьзуется протокол A R P (Address Resolution Protocol кол преобразован ия адресов), определенн ы й с пецификацией RFC826. В протоколе 1 Pv6 используется протокол обнаружен и я соседей ( Ne ighЬor Discovery Protocol , N D) , опре­ дел е н н ы й спецификацией RFC486 l . Эти протоколы можно применять в сетях л юбых типов, которые поддерживают ш и роковещательны й режим или м ногоадресатную рас­ сьmку по всем хостам , но чаще всего их рассматривают в контексте сетей Ethemet . Когда комп ьютер А хочет послать пакет ком п ьютеру Б , находящем уся в той же сети Etheгnet , он использует протоколы ARP или N D для н ахожден ия а п паратного адре­ са Б . Есл и же ком п ьютер Б расположе н в другой сети, то ком п ьютер А с помощью подсисте м ы маршрутиза ц и и определя ет I Р-адрес маршрутизатора следующего пере­ хода , а затем с помощью протоколов A R P ил и N D выясняет аппаратн ы й адрес этого маршрутизатора. Эти п ротоколы позвол я ют н аходить только адреса устройств, непо­ средственно подключен н ых к той же сети . Каждый компьютер хранит в памяти специальную табли цу, называемую кешем A R P или N D , которая содержит резул ьтаты последн их АRР-запросов. В нормал ьных усло­ виях м ногие адреса, необходимые ком пьютеру, выявляются вскоре после начальной за­ грузки , поэтому таблицы ARP и N D мало влияют на загружен ность сети . П ротоколы ARP и N D функцион ируют путем широковещательной рассылки паке­ тов примерно следующего содержания : » З нает л и кто-нибудь аппаратны й адрес для I Р­ адреса Х’?» Устройство, которое разыскивают, узнает свой I Р-адрес и посьmает ответ: «Да , это I Р-адрес одного из моих сетевых и нтерфейсов, соответствующий Ethernet­ aдpec О 8 : О О : 2 О : О О : fb : ба». И сходн ы й запрос вкл ючает I P- и МАС-адрес запрашивающей сторо н ы , бла годаря чему разыскиваемое устройство может ответить, не посылая собствен н ы й запрос . Это позволяет обоим компьютерам узнать адреса друг друга за оди н сеанс обмена пакетами. Другие ком пьютеры , «сл ышавшие» исходное ш ирокове щательное сообщен и е , послан­ ное и н и циатором запроса, тоже могут записать информацию о е го адресах. —

В систе м е Linux команда ip neiqh и зучает и обрабатывает содержимое кеша ARP или N D. Обычно она используется для добавления и удаления за­ писе й , но может также очищать всю таблицу и отображать ее. В частности, команда ip neigh show отображает содержимое кеша . В с истеме Free B S D команда arp управляет кешем ARP, а команда ndp пре­ доставляет доступ к кешу N D.

Эти команды , как правило, применяются для отладки и при работе со специальн ы м оборудованием. Например , если два хоста сети имеют оди наковый I Р-адрес , то н а од­ ном из н и х запись в АRР-табл и це будет правил ьной, а на другом — н ет. С помощью команды arp можно найти хост-наруш итель. 1 2 Это не касается двухточечных соединен и й , где получатель и ноrда подразумевается неявно.

Глава 1 3. Сети TCP/IP

423

Н е правильные записи в кеше могут быть признаком того, что н е кто, и меющий до­ ступ в вашу локальную сеть осуществляет подмену сетевого траф и ка. Этот вид атаки известен как АRР-фиш и н г (ARP spoofing) или отравление кеша (cache poisoni ng) .

1 3 .7. DHCP: ПРОТОКОЛ ДИНАМИЧЕСКОГО КОНФИГУРИРОВАНИЯ ХОСТОВ W Протокол DHCP определен в документах RFC2 1 3 1 , 2 1 32 и 3 1 1 5 . Когда вы добавляете устройство или ком пьютер в сеть, то обыч но получаете с вой I Р-адрес в локал ьной сети , настраиваете соответствующ и й маршрутизатор , зада н н ы й по умолчанию, и присоедин яетесь к локал ьному серверу DNS. В с е это з а вас может сде­ лать протокол D H C P ( Dynamic H ost Configuration Protocol протокол динамического конфигурирования хостов). П ротокол D H C P дает возможность клие нту взять сетевые и адм и н истрати вные параметр ы » в аренду» у це нтрального сервера , отвечающего за и х распростране н и е . Принцип аренды особенно удобен дл я персонал ьных ком пьютеров , которые вы ключе­ ны, когда на них н и кто не работает, и и нтернет-провайдеров, чьи кли енты подключают­ ся по коммутируе м ы м л и н ия м . К «арендуе м ы м » параметрам относятся следующие: —

I Р-адреса и сетевые маски;

адреса шл юзов (стандартные маршруты);

адреса DN S-cepвepoв;

имена комп ьютеров, на которых выполняется система Syslog;

адреса серверов WI N S , Х-серверов ш рифтов, прокси-серверов и NТР-серверов;

адреса серверов ТFТР (для получения файла начал ьной загрузки) .

Существуют десятки других параметров ( с м . R FC2 1 32 для Pv4 и RFC33 1 5 для lvб). Впрочем , на практике экзотические параметры используются редко. Периодически кл иенты должны повторно обращаться к D Н С Р-серверу с целью продл е н и я срока аренды . Есл и этого не делать, аренда рано ил и поздно закон ч ится . DНС Р-сервер будет тогда волен предоставить адрес ( ил и иной арендова н н ы й параметр) другому клиенту. Срок аренды конфигурируется , но обычно он достаточно вел и к (до не­ скольких дней). Даже если вы хотите , чтобы каждый хост и мел собствен н ы й постоян н ый I Р- адрес , протокол D H C P может знач ительно сэконом ить ваш и время и ус или я . Когда сервер D H C P сконфигурирован и запуще н , клиенты почти автоматически определяют параме­ тры сетевой конфигурации на этапе н ачал ьной загрузки, и н и какой путаницы не воз­ никает.

Программное обеспечение DHCP Организация I S C ( 1 11te rnet Software Consortium консорциум разработчиков про­ грамм ного обеспечен ия для И нтернета) поддерживает пре красный открыты й исто 11 1 0 . 1 1 0 . 0 . 0 / 1 6 11 de f a u l t n e t wo r k a c l i d : => 11 < c omput e d> 11 de f a u l t _s e c u r i t y_gr oup_i d : = > 11 < c ompu t e d > 11 dhcp op t i o n s i d : => 11 < c ompu t e d > 11 => » 1 » е n а Ы е dns h o s t name s : => » < compu t e d > » enaЫ e_dn s _ s upp o r t : = > » < comp u t e d > 11 ma i n r o u t e_taЫ e_i d : aws_vpc . de fa u l t : C r e a t i on comp l e t e aws_i n t e r n e t _ g a t e w a y . de fa u l t : C r e a t i n g . . . vpc_ i d : » » = > » vp c — a 9 e b e 3 c c 11 aws_subne t . puЫ i c — u s — we s t — 2 a : C r e a t i n g . . . avai l ab i l i t y_z o n e : 1 1 11 => » u s -we s t — 2 a » c i d r Ы о с k : » 11 => 11 1 0 . 1 1 0 . 0 . 0 / 2 4 » map_puЫ i c i p_on l aunch : » » => 11 0 11 vp c_i d : » » => » vp c — a 9 e b e 3 c c 11 aws_subne t . pu Ы i c — u s — we s t — 2 a : C r e a t i o n comp l e t e aws_r oute_taЫ e . puЫ i c — u s — we s t — 2 a : C r e a t i on c omp l e t e [ s nip ] App l y comp l e t e ! Re s o u r c e s : 5 adde d , О change d , О d e s t r o y e d . r e a l Om4 . 5 3 0 s u s e r Om0 . 2 2 1 s s y s Om0 . 1 7 2 s —

Ком анда time измеряет, с колько вре м е н и потребуется для создан и я всех ресурсов в конфигурации (около 4,5 с). Значения < c omput e d> указывают, что программа Terrafonn выбрала значения по умолчанию, потому что м ы не указали эти настройки явно. Состоян и е всех ресурсов, создан н ых Te rraform , сохраняется в файле terraform . tfstate. Этот файл должен быть сохране н , чтобы программа Terrafonn знала, какие ре­ сурсы находятся под ее контролем. В будущем Terraform самостоятельно откроет управ­ ляемые ресурсы . М ы также легко можем стереть УРС. $ terraform des troy — force aws_vpc . de f a u l t : Re f r e s h i n g s t a t e . . . ( I D : vpc — 8 7 eb e 3 e 2 ) aws_ s u b n e t . puЫ i c — u s — we s t — 2 a : Re f r e s h i n g s t a t e . . . ( I D : subnet — 7 c 5 9 6 a 0 b ) aws_i n t e r n e t_ g a t e wa y . de f a u l t : Re f r e s h i n g s t a t e . . . ( I D : i gw — dc 9 5 e db 9 ) aws_r oute_taЫ e . puЫ i c — u s — we s t — 2 a : Re f r e s h i n g s t a t e . . . ( I D : r t b — 2 f c 7 2 1 4 b ) aws _ r o u t e _ t a Ы e _ a s s o c i a t i o n . p uЫ i c — u s -we s t — 2 — a : Re f r e s h i n g s t a t e . . . ( I D : r t b a s s o c — da 4 7 9bbe ) aws_r o u t e _ t a Ы e _a s s oc i a t i on . p uЫ i c — u s -we s t — 2 — a : De s t r o y i n g . . . aws_r o u t e_taЫ e_a s s oc i a t i on . p uЫ i c — u s -we s t — 2 — a : De s t ru c t i o n c omp l e t e aws_subn e t . pu Ы i c — u s — we s t — 2 a : D e s t r o y i n g . . . aws_r o u t e _ t aЫ e . puЬ l i c — u s — we s t — 2 a : De s t r o y i n g . . . aws_r o u t e t a Ы e . puЫ i c — u s — we s t — 2 a : De s t ru c t i o n c omp l e t e _ aws_i n t e r n e t g a t e wa y . de f a ul t : D e s t r o y i n g . . . aws_s ubne t . p uЫ i c — u s — we s t — 2 a : D e s t r uc t i on comp l e t e a w s i n t e rn e t_g a t e w a y . de f a u l t : De s t ru c t i on comp l e t e aws_vpc . de fa u l t : D e s t r o y i n g . . . aws vpc . de f a u l t : De s t ru c t i on comp l e t e App l y c omp l e t e ! Re s o u r c e s : О adde d , О c h an g e d , 5 de s t r o y e d .

Часть 1 1 . Работа в сетях

472

П рограмма Te rгaform не зависит от кон кретного облака , поэтому она может управ­ лять ресурсам и для AWS , GCP, Digital Ocean , Azure , Docker и других п оставщи ков. Когда испол ьзоват ь Te rraform , а когда — C L I ? Есл и вы создаете и нфрастру ктуру для команды ил и проекта , ил и вам н ужно будет внести изм е н е н и я и повтор ить сборку позже , используйте Terraform . Если вам нужно запустить быстрый экзе м пляр в кач естве теста, просмотреть с ведения о ресурсе ил и получ ить доступ к A P I из с ценария оболоч ки, испол ьзуйте C L I .

Сеть на платформе Goog le Cloud Platform Н а платфор ме Google Coud Platform сете вое взаимоде йствие я вляется функцио­ нал ьной частью платформ ы , а н е представляет собой отдел ьн ы й сервис . Частн ые сети G C P я вля ются глобал ьн ы м и : экзе м пляр в регионе u s — e a s t l может с вязываться с дру­ гим экзе м пляром в ре гионе e u r o p e — w e s t 1 через частную сеть, что упрощает созда н ие глобальных сете вых служб. Сете вой трафик между экзе м пл я рами в одной и той же зоне я вляется бесплатн ы м , но есть плата за трафик между зонами или регионам и . Новые прое кты имеют сеть по умолчанию с диапазоном адресов 1 О . 2 4 О . О . О / 1 6 . Вы можете создать до пяти отдел ьн ых сетей для каждого проекта, а экзе м пляры я вля ются чл енами одной сети. М ногие сайты испол ьзуют эту сетевую архитектуру для и золяции тестов и разработки от производствен н ых систе м . Сети могут подразделяться п о регионам с подсетя м и . Это относ ительно недавнее до­ пол н е н и е к платформе G C P, которое отличается от подсетей на базе AWS . Глобал ьная сеть н е должна быть частью одного диапазона префиксов 1 Pv4, и в каждом ре гионе мо­ жет быть нескол ько префиксов. Платформа G C P настраи вает всю маршрутизацию, по­ этому экзе м пляры на разн ых С I D R-блоках в одной и той же сети могут по- п режнему взаимодействовать друг с другом . Эта топология показана на рис . 1 3 . 7 .

Внутренняя маршрутизация

10.100.0.103

10.100.0.105

us-central1-f

us-central1-b

10.120.0.94

192.168.10.19 us-central1 10.100.0.0/16 192.168.10.0/24

us-east1-b us-east1 10.120.0.0/16

Рис. 13. 7. Частная сет ь GCP с подсетями и несколькими регионами

Подсети не класс ифицируются как публ и ч н ые или частные; вместо этого экзе м пл я ­ р ы , которые н е должн ы п р и н и м ать входя щий трафик из И нтер н ета, могут просто не и меть общедоступ ного адреса , обраще н ного к И н те р нету. Ком п а н и я G oogle п редлага­ ет статические в н е ш н и е I Р-адреса, которые вы можете использовать в зап исях DNS, не

Глава 1 3. Сети TCP/IP

473

опасаясь, что они будут назнач е н ы другом у клиенту. Когда экзе м пляр и меет в н е ш н и й адрес , вы все равно н е увидите его, выпол н и в команду i p addr show; компания Google выполняет перевод адресов дЛ Я вас . По умол чани ю правила брандмауэра в сети G C P применяются ко всем экзе м плярам. Чтобы ограничить правила меньш и м набором экзем пляров, в ы м ожете пометить экзем ­ пляры и фил ьтровать правила в соответствии с тегами . Глобал ьные правила брандмауэра по умолчани ю запрещают все , кроме следующих: •

I С М Р-трафик дЛЯ О/О;

RDP (удален н ы й настольный ком пьютер

SSH (порт ТС Р 22)

дЛЯ

О/О;

все порты и протоколы

дЛЯ

дЛЯ

Wi ndows, ТСР-порт 3389)

дЛЯ

0/0;

внутренней сети (по умолчани ю 1 0. 240.0.0/ 1 6) .

Когда речь идет о реш е н и ях, влияющих на безопасность, м ы всегда возвращаемся к принципу наименьших привилегий. В этом случае мы рекомендуем сузить эти пра­ вила по умолчани ю , чтобы полностью блокировать R D P, разрешать SSH только и з ва­ ших собствен н ы х исходных I Р-адресов и допол н ительно ограни ч ивать трафик в сети GCP. В ы также можете заблокировать I C M P, но имейте в виду, что вам н ужно разреш ить I С М Р-пакеты типа 3, код 4, чтобы вкл юч ить обнаружен и е МТU-пути.

Сеть DigitalOcea n Сеть DigitalOcean не имеет частной сети , по крайней мере такой , как G C P и AWS. Дроплеты могут иметь частны е и нтерфейсы , которы е обмен и ва ются данн ы м и по вну­ тренней сети в одном регионе . Однако эта сеть испол ьзуется совместно со всем и други­ м и кл и ентами DigitalOcean в том же регионе . Это небольшое улучшение по сравнен и ю с использованием И нтерн ета, но брандмауэры и ш ифрование в пути становятся жестки­ м и требова н ия м и . М ы можем исследовать загружен н ый дроплет DigitalOcean с помощю и нтерфейса CLI tugboat: $ tugboat info ulsah D r op l e t f u z z y n ame p r ov i d e d . F i n d i n g d r o p l e t I D . . . done , 8 8 5 7 2 0 2 ( ul s ah — ubun t u — 1 5 — 1 0 ) u l s ah — ubun t u- 1 5 — 1 0 Name : ID: 8857202 Status : a c t ive 4 5 . 55 . 1 . 1 65 IP4 : 2 6 0 4 : A8 8 0 : 0 0 0 1 : 0 0 2 0 : 0 0 0 0 : 0 0 0 0 : 0 1 E F : D0 0 1 IP6 : 10 . 134 . 131 . 213 P rivate I P : S a n F r a nc i s co 1 — s fo l Re g i on : I ma g e : 1 4 1 6 9 8 5 5 — ubunt u — l 5 — 1 0 — x 6 4 5 1 2 МВ Size : B a c kup s Ac t i ve : false

Вывод включает в себя адрес I Pvб в дополнение к общедоступн ы м и частны м адре­ сам 1 Pv4. На примере мы можем продолжить изучение, просмотрев адреса на локал ьных интерфейсах. # tugboat ssh ulsah-uЬuntu- 1 5 — 1 0 # i p address show ethO

2 : e t h O : < BROADCAS T , MUL T I CAST , U P , LOWER_U P > mtu 1 5 0 0 qdi s c p f i f o f a s t s t a t e U P g r oup de f au l t q l e n 1 0 0 0 l ink/ether 0 4 : 0 1 : 8 7 : 2 6 : d6 : 0 1 b r d f f : ff : ff : f f : ff : ff

Часть 11. Работа в сетях

474

i n e t 4 5 . 5 5 . 1 . 1 6 5 / 1 9 brd 4 5 . 5 5 . 3 1 . 2 5 5 s c ope g l ob a l e t h O va l i d _ l f t f o r eve r p r e f e r re d _ l f t f o reve r i n e t 1 0 . 1 2 . 0 . 8 / 1 6 s c ope g l ob a l e t h O va l i d_l f t f o r e v e r p r e f e r r e d_l f t fo reve r i ne t 6 f e 8 0 : : 6 0 1 : 8 7 f f : fe 2 6 : d 6 0 1 / 6 4 s c ope l i n k va l i d_l f t f o r e v e r p r e f e r r e d_ l f t f o reve r # ip address show ethl

3 : e t h l : < BROADCAS T , MU L T I CAS T , U P , LOWER_U P > mtu 1 5 0 0 qdi s c p f i f o_ f a s t s t a t e UP g r oup de f a u l t q l e n 1 0 0 0 l ink/ether 0 4 : 0 1 : 8 7 : 2 6 : d 6 : 02 b r d f f : f f : f f : f f : f f : f f i n e t 1 0 . 1 3 4 . 1 3 1 . 2 1 3 / 1 6 b r d 1 0 . 1 3 4 . 2 5 5 . 2 5 5 s c op e g l ob a l e t h l va l i d_l f t f o r e v e r p r e f e r r e d_ l f t f o r e v e r i ne t 6 f e 8 0 : : 6 0 1 : 8 7 f f : f e 2 6 : d 6 0 2 / 6 4 s c ope l i n k va l i d _ l f t f o r e v e r p r e f e r r e d_ l f t f o r eve r

Общий адрес п р исваи вается непосредстве н но и нтерфейсу e t h O , а не трансл ирует­ ся провайдером , как на других облач ных платформах. Каждый интерфейс также и меет 1 Рv6 адре с , поэтому можно одновременно обслуживать трафи к через 1 Pv4 и 1 Pv6. —

1 3 . 1 6. ЛИТЕРАТУРА Исто рия •

С ом Е R Do u u Lлs Е. Jntern etworking with ТСР//Р Volume 1: Principles, Protocols, and Architectures (бth Edition) . U pp er Saddle River, N J : Prentice Hal l , 20 1 3 . Эта книга дол­ гое время являлась стандартным справоч н иком по протоколам TC P/ I P. Она напи­ сана как учеб н и к дл я студе нтов и я вляется хорошим введением в тему.

Sлшs, PET E R Н . Casting the Net, From ARPANET to INTERNET and Beyond. Reading, МА: Addison-Wesley P rofe ss i onal , 1 995. Это прекрасная истори я A R PAN ET, пред­ теч и И нтернета, написанная уче н ы м , который так долго был близко знаком с раз­ работч и кам и систе м ы U N IX, что стал восприн и маться как оди н из н их. Эта книга представляет собой отл и ч н ы й сбор н и к документов об истори и И нтернета и е го ра111 ичных технологиях (с м . сайт i s o c . o r g / i n t e rn e t / h i s t o ry).

,

Классик а •

SтEVF. N S , W. R1cнARIJ. UNJX Ne twork Programming. Upper Saddle River, N J : Pre ntice Hall, 1 990.

Sпvt.: N s , W. R 1 c 11 л R D , B I L. L F E N N E R , A N D A N D R E W М . R u DO FI’ . UNJX Network Programming, Volume 1, The Sockets Networking A PJ (Зrd Edition). Upper Saddle River, NJ: Addison-�sley, 2003.

SТEVENS, W. RICHARD. UNJX Network Programming, Volume 2: lnterprocess Communications (2nd Edition). Upper Saddle River, NJ: Addison-Wesley, 1 999.

Эти кн иги — кано н и ческие учебн и ки о сете вых классах, в том ч исле о сетевом програ м м и рован и и в U N IX. Есл и вам нужен тол ько и нтерфейс сокетов Berkeley, ори г и н ал ьное и зда н ие по- прежнему я вляется прекрас н ы м источ н и ком знан и й . Если ва м нужен и нтерфейс ST R EAM S, то третья версия, вкл ючающая I Pvб , хо­ рош и й выбор. Все три кн и ги четко и ясно написан ы в типичном стил е Ричарда Стивенса. —

Глава 1 3. Сети TCP/IP •

475

ТлN Е N влu м , AN DREW S. , A N D Dлvr o J. WEТ H E RALL. Computer Networks ( 5th Edition) . U pper Saddle River, NJ : Prentice H al l PTR, 20 1 1 .

Это первая книга о сетях, которая стала классикой . Она содержит подробное опи­ сание всех деталей физических и канальных уровней стека протоколов. Последнее издание охватывает бесп роводные сети , гигабитную сеть Ethernet , одноран говые сети , голосовую I Р-телефонию, сотовые сети и т.д.

Протоколы •

FлLL, KEVIN R» AN D W. R1снлRо SТEVENS. ТСР//Р lllustrated, Volume Опе: The Protocols (2nd Edition). Reading, МА: Addison-Wesley, 20 1 1 .

WRIGHT GлRY R » A N D W. RtcHARD S TEVEN S . ТСР//Р lllustrated, Volume Two: The lmplementation. Reading, МА: Addison-Wesley, 1 995 . ,

Книги в сер и и TC P/ I P l l lustrated протоколов ТСР/1 Р.

отличное и подробное руководство по стеку

H tJNT, СRлю. ТСР//Р Ne twork Administration (Згd Edition). Sebastopol , СА: O ‘ Reilly Media, 2002. Как и другие кн и ги данной сер и и , эта к н и га предназначена для ад­ м и нистраторов с истем U N IX. П оловина к н и ги посвящена п ротоколу TC P / I P, а остал ьная часть описывает высокоуровневые функции UN IX, такие как элек­ трон ная почта и удаленная регистрация .

FлRREL, AoRtAN . The lnternet and lts Protocols: А Comparative Approach . San Francisco, СА: Morgan Kaufmann PuЬlishers, 2004.

Kozr ERAK, CНARLES М. The ТСР//Р Guide: А Comprehensive, !llustrated lnternet Protocols Reference. San Francisco, СА: No Starch Press, 2005.

DoNAH U E , GARY А. Ne twork Warrior: Everything Уои Need to Know That Wasn ‘t оп the CCNA Ехат . Sebastopol , СА: O ‘ Reilly Media, 20 1 5 .

Глава

14

Сетевые аппаратные средства

Независимо от  того, работают ваши системы в  центре обработки данных, в  облаке или пусковой ракетной шахте, у  них есть нечто общее  — необходимость обмена информацией по  сети. Возможность быстрой и  надежной передачи данных необходима в любой среде. Если есть область, в которой технология UNIX затронула человеческие жизни и повлияла на другие операционные системы, то она связана с практической реализацией крупномасштабного пакетированного транспорта данных. Сети проходят такую же эволюцию, как и  серверы, поскольку физические и  логические представления сети все больше разделяются уровнем виртуализации, имеющим собственную конфигурацию. В облаке такие конфигурации являются стандартными, но даже физические центры обработки данных в настоящее время часто включают в себя слой программно конфигурируемых сетей (software-defined networking — SDN). Администраторы взаимодействуют с сетевым оборудованием реального мира менее часто, чем когда-то, но знакомство с традиционными сетями остается решающим навыком. Виртуализированные сети тесно имитируют физические сети в своих функциях, терминологии, архитектуре и топологии. Многие сетевые технологии продвигались в течение долгих лет, но в результате появился очевидный победитель — Ethernet. Сегодня технологию Ethernet можно встретить всюду: от игровых приставок до холодильников. Глубокое понимание принципов работы этой системы чрезвычайно важно для успешной работы системного администратора. Совершенно очевидно, что быстродействие и  надежность сетей непосредственно влияют на результаты деятельности компаний. Однако в настоящее время сетевые технологии настолько вездесущи, что состояние сети может повлиять на возможность вза-

478

Часть II. Работа в сетях

имодействия между людьми, например возможность делать телефонные звонки. Плохая организация сети — это личная и профессиональная неудача, которая может иметь катастрофические социальные последствия. Кроме того, устранение этих недостатков порой обходится очень дорого. Успешное создание сети зависит от по крайней мере четырех важнейших факторов: • разработки разумной структуры сети; • выбора высококачественного оборудования; • правильной инсталляции и документирования; • компетентной эксплуатации и сопровождения. В этой главе рассматриваются принципы, инсталляция и  функционирование сетей Ethernet. Мы также кратко опишем такие устаревшие технологии, как DSL (Digital Subscriber Line), которые обычно предстают перед конечными пользователями в облике — сюрприз! — технологии Ethernet.

14.1. Технология Ethernet: сетевая панацея Захватив более 95% мирового рынка локальных сетей (Local Area Network — LAN), технология Ethernet в самых разных формах проявляется почти всюду. Разработку стандарта Ethernet начал Боб Меткалф (Bob Metcalfe) из Массачусетского технологического института в рамках своей кандидатской диссертации, но в настоящее время она описана во многих стандартах IEEE. В первоначальной спецификации Ethernet была определена скорость передачи данных 3 Мбит/c (мегабит в секунду), но почти сразу же она выросла до 10 Мбит/с. Как только в 1994 году была закончена работа над стандартом, предусматривавшим скорость 100 Мбит/с, стало ясно, что технология Ethernet будет лишь эволюционировать, а не вытесняться новой технологией. Это вызвало гонку технологий, в ходе которой производители старались создать все более быстродействующую версию Ethernet, и это соревнование еще не закончено. Основные этапы эволюции различных стандартов Ethernet приведены в табл. 14.11. Таблица 14.1. Эволюция Ethernet Год

Скорость

Название стандарта

Номер IEEE Расстояние

Средство передачиа

1973

3 Мбит/с

Xerox Ethernet

?

Коаксиальный кабель

1976

10 Мбит/с

Ethernet 1

500 м

Коаксиальный кабель RG-11

1989

10 Мбит/с

10BASE-T

802.3

100 м

Медный кабель НВП категории 3

1994

100 Мбит/с 100Base-TX

802.3u

100 м

Медный кабель НВП категории 5

1999

1 Гбит/с

1000BASE-T (“gigabit”)

802.3ab

100 м

Медный кабель НВП категорий 5e и 6

2006

10 Гбит/с

10GBASE-T (“10 Gig”)

802.3an

100 м

ВП категории 6a, 7, НВП категории 7a

2009

40 Гбит/с

40GBASE-CR4

P802.3ba

10 м

Медный кабель НВП

100 м

ММ-оптоволокно

40GBASE-SR4

Мы не упомянули несколько менее популярных стандартов.

1 

479

Глава 14. Сетевые аппаратные средства

Окончание табл. 14.1

Год

Скорость

Название стандарта

Номер IEEE Расстояние

Средство передачиа

2009

100 Гбит/с

P802.3ba

2018б

200 Гбит/с

2018б

400 Гбит/с

2020б

1Тбит/с

100GBASE-CR10 100GBASE-SR10 200GBASE-FR4 200Gbase-LR4 400GBASE-SR16 400Gbase-DR4 400GBASE-FR8 400Gbase-LR8 TbE

Медный кабель НВП МM-оптоволокно CWDM-оптоволокно CWDM-оптоволокно МM-оптоволокно (16 жил) МM-оптоволокно (4 жилы) CWDM-оптоволокно CWDM-оптоволокно TBD

P802.3bsв P802.3bs

TBD

10 м 100 м 2 км 10 км 100 м 500 м 2 км 10 км TBD

а

 ММ — многомодовое, НВП — неэкранированная витая пара, ВП — витая пара, CWDM — разреженное спектральное мультиплексирование. б

 Промышленный проект.

в

 Мы немного сомневаемся и предполагаем, что этот вариант кодировки был неудачным совпадением.

Как работает Ethernet Технологию Ethernet можно представить в виде великосветского раута, на котором гости (компьютеры) не перебивают друг друга, а  ждут паузы в  разговоре (отсутствия трафика в сетевом кабеле), чтобы заговорить. Если два гостя начинают говорить одновременно (т.е. возникает конфликт), оба они останавливаются, извиняются друг перед другом, ждут немного, а затем один из них начинает говорить снова. В технической терминологии такая схема называется CSMA/CD (Carrier Sense Multiple Access with Collision Detection — множественный доступ с контролем несущей и обнаружением конфликтов). Смысл этого названия заключается в следующем: • контроль несущей (CS) — вы можете говорить одновременно с другими; • множественный доступ (MA) — говорить могут все; • обнаружение конфликтов (CD) — вы знаете, когда перебиваете кого-то. Фактическая задержка при обнаружении конфликтов является случайной. Это поз­ воляет избежать такого развития событий, при котором два компьютера одновременно передают сообщения в  сеть, обнаруживают коллизию, ждут некоторое время, а  затем синхронно возобновляют передачу, переполняя, таким образом, сеть конфликтами. В настоящее время важность соглашений CSMA/CD осознали даже приверженцы коммутаторов, которые обычно ограничивают количество хостов в домене, в  котором происходят коллизии, до  двух. (Если продолжить аналогию с  великосветским раутом, можно описать этот вариант как ситуацию, в  которой два собеседника, как в  старом кино, чопорно сидят на противоположных концах длинного обеденного стола.)

Топология Ethernet С точки зрения топологии сеть Ethernet представляет собой разветвляющуюся шину, но без петель. У пакета есть только один путь следования между любыми двумя хостами, расположенными в одной сети. В сети Ethernet могут передаваться пакеты трех типов: однонаправленные (unicast), групповые (multicast) и  широковещательные (broadcast). Пакеты первого типа адресованы одному хосту, второго  — группе хостов, третьего  — всем хостам сегмента.

480

Часть II. Работа в сетях

Широковещательный домен — это совокупность хостов, которые принимают пакеты, направляемые по  аппаратному широковещательному адресу. В каждом логическом сегменте сети Ethernet существует только один широковещательный домен. В ранних стандартах Ethernet и  средствах передачи (например, 10Base5) понятия физического и логического сегментов были тождественными, поскольку все пакеты передавались по одному большому кабелю, в который втыкались сетевые интерфейсы компьютеров2. С появлением современных коммутаторов логические сегменты стали включать в  себя множество (десятки и  даже сотни) физических сегментов, к  которым подключено всего два устройства: порт коммутатора и  компьютер. Коммутаторы отвечают за доставку групповых и однонаправленных пакетов в физический сегмент, где расположен нужный адресат (адресаты); широковещательные пакеты направляются во все сетевые порты логического сегмента. С появлением коммутаторов сегодняшние логические сегменты обычно состоят из многих физических сегментов (возможно, десятков или сотен), к  которым подключены только два устройства: порт коммутатора и  хост.3 Коммутаторы несут ответственность за сопровождение многоадресатных и  одноадресатных пакетов к  физическим (или беспроводным) сегментам, на  которых находятся предполагаемые получатели. Широковещательный трафик пересылается всем портам в логическом сегменте. Логический сегмент может состоять из физических сегментов, имеющих разную скорость передачи данных. Следовательно, коммутаторы должны иметь средства буферизации и синхронизации для предотвращения возможных конфликтов.

Неэкранированная витая пара Неэкранированная витая пара (НВП)  — самая популярная среда передачи данных в сетях Ethernet. Общая схема сети на основе НВП изображена на рис. 14.1. Коммутатор НВП

соединение с магистралью

Питание C:>

C:>

PUNISHER 2000

PUNISHER 2000

Рабочая станция

Рабочая станция

Ethernet-принтер

Рис. 14.1. Схема сети на основе НВП

Мы не шутим! Подключение нового компьютера к  сети предполагало прокалывание отверстия в изоляции кабеля с помощью специального соединителя, называемого «зуб вампира», который позволял добраться до центрального проводника. Этот соединитель затем зажимался винтами. 3  Беспроводные сети — еще один распространенный тип логического сегмента Ethernet. Они ведут себя, скорее, как традиционные формы Ethernet, которые используют один кабель для соединения многих хостов сети (cм. раздел 14.2). 2 

481

Глава 14. Сетевые аппаратные средства

Провода, используемые в  современных локальных вычислительных сетях на  основе неэкранированной витой пары, обычно подразделяют на восемь категорий. Эта система оценки параметров была впервые введена компанией Anixter, крупным поставщиком кабельной продукции, и  впоследствии стандартизирована организацией TIA (Telecommunications Industry Association  — ассоциация телекоммуникационной промышленности). Сегодня выделяются категории 1–7 и промежуточные категории 5e и 6a. Организация ISO (International Organization for Standartization  — Международная организация по стандартизации) тоже подключилась к процессу стандартизации кабелей и  предложила собственную классификацию, которая почти в  точности повторяет классификацию TIA. Например, кабель категории 5 в системе TIA эквивалентен кабелю класса D в системе ISO. Для наглядности в табл. 14.2 подытожены ключевые различия между основными современными стандартами кабелей. Эта таблица поможет вам произвести впечатление на своих друзей во время вечеринки. Таблица 14.2. Характеристики кабелей НВП Параметра Ширина полосы Затухание NEXT ELFEXT Затухание отраженного сигнала (обратная потеря) Задержка распространения сигнала

Единица измерения

Категории 5 Dб

5e

6E

6a EA 7 F

7a FA 8 I

МГц дБ дБ дБ дБ

100 24 27,1 17 8

100 24 30,1 17,4 10

250 21,7 39,9 23,2 12

500 18,4 59 43,1 32

600 20,8 62,1 46,0 14,1

1000 60 60,4 35,1 61,93

2000 50 35,6 – 8

нс

548

548

548

548

504

534

548

а

NEXT (Near-end crosstalk)  — ослабление перекрестной наводки на  ближнем конце. ELFEXT (Equal level far-end crosstalk) — ослабление равноуровневой перекрестной наводки на дальнем конце. б

Включая дополнительные спецификации TIA TSB 95 и ISO FDAM 2.

Кабель категории 5 поддерживает работу на скорости 100 Мбит/с. Кабели категорий 5е, 6 и 6а поддерживают скорость передачи 1 Гбит/с и в настоящее время используются в качестве стандарта. Кабель категории 6a лучше всего подходит для организации новых сетей, поскольку он особенно устойчив к  помехам, возникающим из-за использования старых стандартов передачи сигналов (например, 10BASE-T). При прокладке кабелей категорий 5 и 5е были зафиксированы определенные проблемы. Кабели категорий 7 и 7а предназначены для передачи данных со скоростью 10 Гбит/с, а кабели категорий 8 — 40 Гбит/с. Более быстродействующие стандарты требуют применения нескольких пар НВП. Это ускоряет передачу данных по линии связи по сравнению с использованием единственной пары. Для соединений 10BASE-T требуются две пары проводов категории 5. В соединениях 100BASE-TX предельная длина та же, но используются две пары проводов категории 5. Соединение 1000BASE-TX требует четырех пар проводов категорий 5e или 6/6а. Аналогично соединение 10GBASE-TX требует четырех пар проводов категорий 6а, 7 или 7а. Длина кабеля во всех стандартах ограничена 100 м. Существуют провода с поливинилхлоридной и тефлоновой изоляцией. Выбор изоляции диктуется средой, в которой будут проложены кабели. В замкнутых помещениях, связанных с вентиляционной системой здания, обычно требуется тефлоновая изоляция4. Поливинилхлоридная изоляция дешевле и проще в эксплуатации. Конкретную информацию можно получить у пожарного инспектора или ответственного за пожарную безопасность. 4 

482

Часть II. Работа в сетях

Подключая четырехпарный НВП-кабель к коммутационным панелям и настенным розеткам RJ‑45, придерживайтесь стандарта разводки TIA/EIA‑568A. Этот стандарт, совместимый с другими вариантами RJ‑45 (например, RS‑232), позволяет избежать ошибок при разводке концов кабеля, независимо от того, есть ли свободный доступ к парам. Требования стандарта отражены в табл. 14.3. Таблица 14.3. Стандарт TIA/EIA-568A для подключения четырехпарного НВП-кабеля к розетке RJ‑45 Пара

Цвета

Контакты разъема

1

Белый/синий

5/4

2

Белый/оранжевый

3/6

3

Белый/зеленый

1/2

4

Белый/коричневый

7/8

Имеющаяся в здании проводка может не подходить для прокладки сетей, в зависимости от того, как и когда она прокладывалась.

Оптическое волокно Оптическое волокно используется в  тех ситуациях, когда применение медного кабеля по  тем или иным причинам неприемлемо. Оптическое волокно передает сигнал быстрее, чем медный провод. Кроме того, оно является более устойчивым к электрическим помехам, что в некоторых приложениях очень важно. Там, где оптическое волокно не является абсолютно необходимым, обычно выбирают медный кабель, поскольку он дешевле и с ним легче работать. Оптическое волокно бывает “многомодовым” и “одномодовым”. Многомодовое оптическое волокно обычно используется в зданиях или комплексах зданий. Оно толще, чем одномодовое, и может проводить несколько лучей света; это свойство позволяет использовать менее дорогую электронику (например, в  качестве источника света можно использовать светодиоды). Одномодовое оптическое волокно часто используется в магистральных приложениях, например для прокладки линий связи между городами и регионами. Оно может проводить только один световой луч и требует дорогой прецизионной электроники в конечных точках. Стандарт TIA-598C рекомендует цветовую кодировку оптического волокна, представленную в табл. 14.4. Следует помнить основное правило: все элементы должны соответствовать друг другу. Оптическое волокно, соединяющее конечные точки, оптические кабели перекрестной коммутации и электронные приборы, установленные в конечных точках, должны иметь один и тот же тип и размер. Обратите внимание на то, что кабели OM1 и OM2 не являются взаимозаменяемыми, хотя и окрашены в один и тот же оранжевый цвет — проверьте размеры, указанные на кабелях, чтобы убедиться, что они соответствуют друг другу. Если вы нарушите это правило, то вам будет сложно обеспечить изоляцию в конечных точках. На концах оптических волокон используются разъемы более чем 30 типов, и нет ни четких правил, ни принципов, регламентирующих их выбор. В каждой конкретной ситуации на  выбор того или иного типа разъема влияют поставщики оборудования или параметры оптического волокна, уже проложенного внутри здания.

483

Глава 14. Сетевые аппаратные средства Таблица 14.4. Атрибуты стандартных оптических волокон Количество мод Название ISO*

Диаметр сердечника, мкм

Диаметр оптической оболочки, мкм

Цвет

Много

OM1

62,5

125

Оранжевый

Много

OM2

50

125

Оранжевый

Много

OM3

50 *

125

Голубой

Одна

OS1

8–10

125

Желтый

а

В соответсвии со стандартатом ISO 11801.

б

OM3 оптимизирован под лазерный луч.

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

Концентраторы Концентраторы (hub)  иногда еще называют повторителями (repeators). Это активные устройства, используемые для соединения сегментов сетей Ethernet на физическом уровне. Им требуется внешний источник питания. Выступая в качестве повторителя, концентратор ретранслирует Ethernet-фреймы, но никак не интерпретирует их. Он “не имеет представления” ни о  том, куда направляются пакеты, ни о том, какой протокол они используют. За исключением экзотических ситуа­ций, концентраторы больше не должны использоваться в промышленных сетях, и мы не советуем их использовать даже в домашних сетях. (Почему? Потому что коммутаторы (switches) значительно эффективнее используют полосу пропускания частот в  сети и в настоящее время стоят недорого.)

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

484

Часть II. Работа в сетях

Если сеть имеет петли, коммутатор может безнадежно запутаться, потому что пакеты, посылаемые одним компьютером, окажутся сразу на  двух (или более) портах коммутатора. В одной сети Ethernet петлей не бывает, но после объединения нескольких таких сетей с помощью маршрутизаторов и коммутаторов топология изменится, вследствие чего может образоваться несколько путей к одному хосту. Некоторые коммутаторы решают эту проблему путем резервирования альтернативных маршрутов на тот случай, если основной маршрут станет недоступным. Они упрощают топологию видимой ими сети, отсекая дублирующиеся пути до тех пор, пока в оставшихся сегментах не окажется только по одному маршруту к каждому хосту сети. Другие коммутаторы создают между сетями двойные каналы и переключают трафик по циклическому принципу. Коммутаторы должны просматривать каждый пакет, определяя, нужно ли его пересылать в другой сегмент. Производительность этих устройств обычно измеряют как скоростью просмотра пакетов, так и скоростью их пересылки. Многие поставщики не указывают в  диаграммах производительности коммутаторов размеры протестированных пакетов, поэтому реальная производительность может быть ниже объявленной. Несмотря на то что быстродействие коммутаторов Ethernet все время растет, эффективно использовать их можно при объединении в  один логический сегмент не более сотни компьютеров. В крупных коммутируемых сетях часто возникают проблемы наподобие “широковещательных штормов”, поскольку широковещательный трафик должен проходить через все порты. Для решения этой проблемы нужно изолировать широковещательный трафик между коммутируемыми сегментами посредством маршрутизатора (создавая тем самым более одного логического Ethernet-сегмента). Выбор коммутатора может представлять определенную трудность. В этом сегменте рынка очень высокая конкуренция, следствием которой являются многочисленные рекламные заявления, не всегда подтверждаемые на практике. Поэтому не стоит особо доверять данным, которые приводятся поставщиками; лучше прислушаться к советам независимых экспертов (просмотрите тесты, приводимые в журналах). В последние годы нередко случалось так, что чей-то продукт оказывался “лучшим” в течение нескольких месяцев, а затем, после попыток внесения улучшений, его производительность или надежность падала ниже критической отметки. В любом случае убедитесь, что скорость объединительной панели коммутатора является достаточной. У хорошо спроектированного коммутатора эта скорость должна превышать сумму скоростей всех его портов.

Коммутаторы, позволяющие создавать виртуальные локальные сети В крупных организациях можно использовать коммутаторы, позволяющие разбивать их порты (программным путем) на группы, называемые виртуальными локальными сетями (Virtual Local Area Network  — VLAN). Виртуальная локальная сеть  — это группа портов, принадлежащая к одному логическому сегменту, как если бы порты были соединены со своим собственным выделенным коммутатором. Подобное секционирование позволяет повысить степень изоляции трафика, что полезно с точки зрения как безопасности, так и производительности. Трафиком между виртуальными локальными сетями управляет маршрутизатор или, в некоторых случаях, модуль маршрутизации или уровень программной маршрутизации самого коммутатора. Расширение этой системы, называемое транкингом виртуальной локальной сети (один из примеров реализации — протокол IEEE 802.1Q), позволяет разным коммутаторам обслуживать порты одной логической виртуальной локальной сети.

Глава 14. Сетевые аппаратные средства

485

Важно помнить, что сами сети VLAN почти не обеспечивают дополнительной защиты. Для того чтобы обеспечить защиту, необходимо фильтровать трафик VLAN.

Маршрутизаторы Маршрутизаторы (известные также как “коммутаторы третьего уровня”) направляют трафик на третьем сетевом уровне модели OSI. Маршрутизаторы доставляют пакеты адресатам на основании информации, хранящейся в TCP/IP-заголовках. Помимо простого перемещения пакетов, маршрутизаторы могут также выполнять ряд особых функций, например фильтрацию пакетов (в соответствии с  правилами безопасности), разделение трафика по приоритетам (в соответствии с заданным качеством обслуживания) и обнаружение общей сетевой топологии. Конфигурация маршрутизаторов бывает фиксированной или модульной. • Устройства первого типа содержат сетевые интерфейсы, установленные в  заводских условиях. Они обычно подходят для специализированных применений. Например, маршрутизатор с интерфейсами T1 и Ethernet может оказаться удобным, когда нужно подключить небольшую компанию к Интернету. • Модульные маршрутизаторы имеют слотовую или шинную архитектуру, а  интерфейсы к  ним добавляются пользователями. Как правило, это более дорогие устройства, но зато они гибче в эксплуатации. В зависимости от необходимой надежности и ожидаемого трафика, специализированный маршрутизатор может оказаться как дороже, так и дешевле системы UNIX или Linux, сконфигурированной в  качестве маршрутизатора. Однако специализированное устройство, как правило, демонстрирует более высокую производительность и надежность. Это та область сетевого проектирования, где лучше заранее вложить чуть больше денег, чем потом иметь головную боль.

Автосогласование С появлением разных стандартов Ethernet возникла необходимость, чтобы устройства могли идентифицировать конфигурацию своих соседей и  согласовывать с  ними свои настройки. Например, сеть не будет работать, если на одной стороне соединения она работает со скоростью 1 Гбит/с, а  на другой — со скоростью 10 Гбит/с. Для выявления и решения этой проблемы организацией IEEE был разработан стандарт автосогласования Ethernet. В одних случаях он работает, а в других применяется неправильно и лишь усугубляет проблему. Следует запомнить два золотых правила автосогласования. • Вы обязаны использовать автосогласование всех интерфейсов, работающих на скорости 1 Гбит/с и выше. Этого требует стандарт. • Если интерфейсы ограничены скоростями 100 Мбит/с и ниже, необходимо либо конфигурировать оба конца соединения, либо вручную настроить скорость и дуплекс (половинный или полный) обеих сторон. Если в режиме автосогласования настроить только одну сторону соединения, то в большинстве случаев она не сможет выяснить, какую конфигурацию имеет другая сторона. В результате конфигурация станет несогласованной и производительность упадет. Для того чтобы выяснить, как задать стратегию автосогласования интерфейсов, прочитайте специальный раздел 13.10.

486

Часть II. Работа в сетях

Передача электропитания по сетям Ethernet Технология передачи питания по сетям Ethernet (Power on Ethernet — PoE) основана на передаче электропитания по той же неэкранированной витой паре (UTP Ethernet), по которой передается сигнал Ethernet. Данная технология регламентируется стандартом IEEE 802.3af. Это особенно удобно для систем связи, обеспечивающих передачу речевого сигнала по  сети Интернет (Voice over IP  — VoIP), или пунктов доступа к  системе беспроводной связи (мы указали только два примера, но список можно продолжить), в которых требуется как маломощный источник питания, так и сетевое соединение. По мощности питания системы PoE разделяются на  четыре класса в  диапазоне от 3,84 до 25,5 Вт. Промышленность, которая никогда не останавливается на достигнутом, уже работает над новым стандартом (802.3bt), предусматривающим более высокую мощность (более 60 Вт). Будет ли этого достаточно, чтобы подключить духовку EasyBake к сетевому порту в конференц-зале?5 Технология PoE порождает два обстоятельства, о  которых должен знать системный администратор. • Вы должны знать о существовании устройств PoE в вашей инфраструктуре, чтобы правильно спланировать доступ к портам коммутаторов, поддерживающих технологию PoE. Эти порты дороже, чем порты, не поддерживающие технологию PoE. • Вычисляя расход электроэнергии на  обслуживание коммуникационных шкафов, содержащих коммутаторы PoE, следует учитывать мощность устройств PoE. Обратите внимание на  то, что вы не должны учитывать дополнительный расход электроэнергии на охлаждение коммуникационных шкафов, поскольку большая часть тепла, выделяемого из-за потребления мощности PoE, рассеивается за пределами шкафа (обычно по офису).

Гигантские пакеты Технология Ethernet стандартизована для  типичного пакета размером 1  500  байт (вместе с фреймом — 1 518 байт). Это значение было выбрано давно, когда сети были медленными и память для буферов была дефицитной. В настоящее время пакеты размером 1 500 байт выглядят крохотными в контексте гигабитных сетей Ethernet. Поскольку с каждым пакетом связаны накладные расходы и определенное время задержки, производительность сети можно повысить, если допустить более крупные размеры пакетов. К сожалению, стандарты IEEE для разных типов сетей Ethernet запрещают использование крупных пакетов по соображениям совместимости сетей. Однако, поскольку скорость магистрального трафика часто во много раз превышает установленный предел, нестандартные большие пакеты Ethernet в современных сетях перестали быть редкостью. Подстрекаемые нетерпеливыми потребителями, производители сетевого оборудования негласно бойкотируют стандарт IEEE и  обеспечивают поддержку крупных фреймов в своей гигабитной продукции. Для использования так называемых гигантских пакетов (jumbo frames) необходимо лишь повысить максимально возможный размер пакета (maximal transmission unit  — MTU) в интерфейсах сети. Повышение производительности зависит от  вида трафика, но наибольший выигрыш достигается для крупномасштабных перемещений по протоколу TCP (например, в файловых службах NFSv4 или CIFS). Ожидается, что умеренное, но заметное повышение производительности должно составить примерно 10%. Для интересующихся этим вопросом: да, существует возможность загрузить небольшую систему Linux через порт сети PoE. Возможно, проще всего это сделать с помощью Raspberry Pi и коммутатора Pi PoE Switch HAT. 5 

Глава 14. Сетевые аппаратные средства

487

Тем не менее следует отметить следующее. • Поддерживать и использовать гигантские пакеты должно все сетевое оборудование в подсетях, включая коммутаторы и маршрутизаторы. Их нельзя смешивать и подгонять. • Поскольку гигантские пакеты являются нестандартными, обычно их необходимо разрешать явным образом. Устройства могут принимать гигантские пакеты по умолчанию, но, вероятнее всего, они не будут их генерировать. • Поскольку гигантские пакеты представляют собой незаконное явление, не существует соглашения, насколько большими они могут или должны быть. Типичной величиной является 9000 байт или 9018 вместе с фреймом. Необходимо проверить, какой максимальный размер пакета может принять ваше устройство. Пакеты размером больше 9 Кбайт иногда называют сверхгигантскими, но это экзотическое название вас пугать не должно. Чем больше размер, тем лучше, по крайней мере в диапазоне до 64 Кбайт. Мы одобряем использование гигантских пакетов в  гигабитных сетях Ethernet, но будьте готовы к  дополнительной отладке, если что-то пойдет не так, как надо. Лучше всего развернуть новую сеть, задав максимально возможный размер пакета по умолчанию, а позднее, когда надежность сети будет проверена, изменить эти настройки и разрешить гигантские пакеты.

14.2. Беспроводные сети: локальная сеть для  кочевников Беспроводные сети состоят из беспроводных точек доступа (Wireless Access Points — WAP) и  клиентов беспроводной сети. Точки WAP могут соединяться традиционными проводными сетями (обычная конфигурация) или с другими точками WAP без использования проводов (конфигурация известна под названием “беспроводная сеть”).

Стандарты беспроводных сетей Распространенными стандартами беспроводных сетей в настоящее время являются IEEE 802.11g, 802.11n и .802.11ac Стандарт 802.11g работает на частоте 2,4 ГГц и обеспечивает доступ к локальной сети со скоростью, достигающей 54 Мбит/с. Радиус действия одной точки доступа колеблется от 100 м до 40 км, в зависимости от оборудования и физических особенностей местности. Стандарт 802.11n обеспечивает скорость до 600 Мбит/с 6 и может использовать частоты как 5 ГГц, так и 2,4 ГГц (при этом рекомендуется использовать диапазон 5 ГГц). Радиус действия точки доступа в  стандарте IEEE  802.11n в  два раза больше, чем в  стандарте IEEE 802.11g. Преемником стандарта IEEE 802.11n является стандарт IEEE 802.11ac, поддерживающий производительность многостанционной сети на уровне до 1 Гбит/с. Все эти стандарты обозначаются одним общим термином Wi-Fi. Формально говоря, метка Wi-Fi ограничена семейством стандартов IEEE 802.11. Однако это лишь один из многих видов аппаратного обеспечения Ethernet, доступных на рынке, поэтому все беспроводные сети Ethernet называются Wi-Fi.  Скорость 600 Мбит/с в стандарте 802.11n является, скорее, теоретической. На практике полоса пропускания в окрестности точки WAP при оптимальной конфигурации может обеспечить скорость передачи данных не более 400 Мбит/с. Это объясняется различием между теоретическими и практическими возможностями оборудования и среды. В беспроводных сетях всякое бывает! 6

488

Часть II. Работа в сетях

В настоящее время стандарты 802.11g и 802.11n стали общепринятыми. Трансиверы недороги и встроены в большинство ноутбуков. Кроме того, платы расширения также стоят недорого и доступны для любых персональных компьютеров.

Доступ клиентов к беспроводной сети Вы можете настроить системы UNIX или Linux для  подключения к  беспроводной сети в качестве клиента, если у вас есть правильное оборудование и драйвер. Поскольку большинство беспроводных плат на  базе персональных компьютеров все еще предназначены для системы Microsoft Windows, они могут не поставляться с завода с драйверами FreeBSD или Linux. При попытке добавить беспроводное подключение к  системе FreeBSD или Linux вам, скорее всего, понадобятся следующие команды: • ifconfig — для конфигурирования интерфейса беспроводной сети; • iwlist — для получения списка доступных точек доступа к беспроводной сети; • iwconfig — для настройки параметров беспроводного соединения; • wpa_supplicant  — для  аутентификации в  беспроводной сети (или проводной сети 802.1x). К сожалению, гонка продаж дешевого оборудования часто означает, что для  настройки правильной работы беспроводного адаптера в  системе UNIX или Linux может потребоваться много часов проб и ошибок. Планируйте все заранее или выясните в Интернете, какой адаптер лучше всего подходит для вашей операционной системы.

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

Топология беспроводных сетей Точки беспроводного доступа (Wireless Access Point  — WAP) обычно представляют собой специализированные устройства, состоящие из одной или нескольких радиостанций и некоторой формы встроенной сетевой операционной системы, часто урезанной версии Linux. Одна точка WAP может обеспечить подключение нескольких клиентов, но их число ограничено. Хорошее эмпирическое правило состоит в том, чтобы одновременно обслуживать не более сорока клиентов с помощью одной корпоративной точки WAP. В качестве клиента может действовать любое устройство, которое обменивается данными по беспроводному стандарту, поддерживаемому вашими точками WAP. Точки WAP имеют один или несколько “служебных идентификаторов сети”, а также идентификатор SSID, который служит именем беспроводной локальной сети и должен быть уникальным в определенной окрестности. Когда клиент хочет подключиться к беспроводной локальной сети, он выясняет, какие идентификаторы SSID доступны, и выбирает одну из этих сетей. Вы можете сделать имя своего идентификатора SSID осмысленным и легко запоминающимся, например Third Floor Public (Третий этаж, открытый доступ), или изобрести что-нибудь необычное. Некоторые из наших любимых имен SSID:

Глава 14. Сетевые аппаратные средства

489

• FBI Surveillance Van (Служба наблюдения ФБР); • The Promised LAN (Обещанная локальная сеть); • IP Freely (Свободный IP); • Get Off My LAN (Убирайся из моей локальной сети); • Virus Distribution Center (Центр распространения вирусов); • Access Denied (Доступ запрещен). Нет ничего лучше, чем изобретательные чудаки… В простейших сценариях точка WAP объявляет единственный SSID, ваш клиент подключается к этому SSID и всё — вы в сети! Тем не менее несколько аспектов беспроводной сети действительно просты. Что делать, если ваш дом или здание слишком большие, чтобы обслуживаться одной точкой WAP? Или что если вам нужно предоставлять разные сети различным группам пользователей (например, сотрудникам или гостям)? Для этих случаев вам необходимо стратегически структурировать свою беспроводную сеть. Вы можете использовать несколько SSID для  разбивки групп пользователей или функций. Как правило, вы сопоставляете их с  отдельными виртуальными локальными сетями, которые затем можно маршрутизировать или фильтровать по желанию, как и проводные сети. Частотный спектр, выделенный для  беспроводной сети 802.11, разбивается на  полосы, обычно называемые каналами. Точка WAP самостоятельно выбирает свободный радиоканал для объявления SSID. Клиенты и точка WAP используют этот канал для связи, формируя единый широковещательный домен. Ближайшие точки WAP, скорее всего, будут выбирать другие каналы, чтобы максимизировать доступную полосу пропускания и минимизировать помехи. Теория состоит в  том, что по  мере того, как клиенты перемещаются по  окружающей среде, они будут отделяться от одной точки WAP, когда ее сигнал становится слабым, и соединяться с ближней точкой WAP с более сильным сигналом. Однако теория и реальность часто не согласуются друг с другом. Многие клиенты поддерживают связь с точкой WAP, излучающей слабый сигнал, и игнорируют лучшие варианты. В большинстве ситуаций вы должны разрешить WAP автоматически выбирать свои предпочтительные каналы. Если вы должны вручную вмешаться в  этот процесс, используя стандарты 802.11b/g/n, рассмотрите выбор между каналами 1, 6 или 11. Спектр, выделенный этим каналам, не перекрывается, поэтому комбинации этих каналов обеспечивают наибольшую вероятность широкого распространения  — открытую беспроводную магистраль. Каналы по  умолчанию для  802.11a/ac не перекрываются вообще, поэтому просто выберите свой любимый номер. Некоторые точки WAP имеют несколько антенн и используют технологию множественного ввода и  множественного вывода (multiple-input, multiple-output  — MIMO). Эта практика может увеличить доступную полосу пропускания, используя несколько передатчиков и приемников, чтобы использовать преимущества смещения сигнала в результате задержки распространения. В некоторых ситуациях эта технология может обеспечить небольшое улучшение производительности, хотя, вероятно, не такое значительное улучшение, как широкая сеть антенн. Если вам нужна физически большая зона покрытия, разверните несколько точек WAP. Если область полностью открыта, вы можете развернуть их в  структуре решетки. Если существуют физические препятствия вроде стен, проведите исследование для  определения наилучших вариантов размещения точек WAP с  учетом физических атрибутов вашего пространства.

490

Часть II. Работа в сетях

Дешевая беспроводная связь Нам нравятся продукты Ubiquiti (ubnt.com) для недорогих, высокопроизводительных домашних сетей. Google Wifi — замечательное облачное решение, если вы поддерживаете связь с удаленными членами семьи. Другим вариантом является запуск урезанной версии Linux (например, OpenWrt или LEDE) на коммерческой точке WAP (см. сайт Openwrt. org для получения дополнительной информации и списка совместимого оборудования). Буквально десятки продавцов сейчас поставляют оборудование для  точек беспроводного доступа. Вы можете купить их в Home Depot и даже в продуктовом магазине. Дешевые точки доступа (в диапазоне 30 долл.), вероятно, будут плохо работать при обработке больших файлов или наличии нескольких активных клиентов.

Дорогая беспроводная связь Большая беспроводная связь означает большие деньги. Предоставление надежной беспроводной сети высокой плотности (в крупных больницах, спортивных учреждениях, школах, городах) представляет собой сложную задачу, связанную с ограничениями физических установок, плотностью пользователей и законами физики. В таких ситуациях вам нужны беспроводные устройства корпоративного класса, которые знают местоположение и состояние каждой точки WAP и активно настраивают каналы WAP, силу сигналов и группы клиентов, чтобы обеспечить наилучшие результаты. Эти системы обычно поддерживают прозрачный роуминг, который позволяет группе клиентов с определенной виртуальной локальной сетью и сессией беспрепятственно перемещаться между точками WAP. Наши любимые крупные беспроводные платформы — это Aerohive и Meraki (последняя принадлежит компании Cisco). Эти платформы следующего поколения управляются из облака, что позволяет вам пить мартини на пляже, контролируя свою сеть через браузер. Вы даже можете выбросить отдельных пользователей из беспроводной сети, не вставая с шезлонга. Уйди, противный! Если вы развертываете беспроводную сеть в больших масштабах, вам, вероятно, придется приобрести анализатор беспроводной сети. Мы настоятельно рекомендуем аналитические продукты, разработанные компанией AirMagnet.

Безопасность беспроводных сетей Традиционно безопасность беспроводных сетей очень низкая. Существует протокол WEP (Wired Equivalent Privacy), применяемый в сетях 802.11b и для шифрования пакетов, передаваемых с помощью радиоволн. К сожалению, в современной версии стандарта была обнаружена фатальная проектная недоработка, которая делает его практически бесполезным. Посторонний человек, находящийся за пределами здания, может получить прямой доступ к сети и остаться незамеченным. Тем не менее недавно появившиеся стандарты Wi-Fi Protected Access (WPA) возродили доверие к безопасности беспроводных сетей. В настоящее время во всех новых инсталляциях должны использоваться стандарты WPA (в частности, стандарт WPA2), а не WEP. Без применения стандарта WPA2 беспроводные сети должны считаться полностью незащищенными и  не должны использоваться за пределами предприятия. Даже дома не используйте стандарт WEP! Для того чтобы запомнить, что стандарт WEP является незащищенным, а стандарт WPA — безопасным, просто расшифруйте аббревиатуру WAP (Wired Equivalent Privacy — конфиденциальность на  уровне проводных сетей). Это название точно отражает суть дела; протокол WEP обеспечивает такую защиту, как проводная сеть, допускающая

Глава 14. Сетевые аппаратные средства

491

непосредственное подключение посторонних лиц. (Иначе говоря, никакой защиты  — по крайне мере на уровне IP.)

14.3. SDN: программно-коммутируемые сети Как и при виртуализации серверов, разделение физического сетевого оборудования с функциональной архитектурой сети может значительно повысить гибкость и управляемость. Лучшим средством для достижения этих целей являются программно-коммутируемые сети (software-defined networking — SDN). Основная идея SDN заключается в том, что компоненты, управляющие сетью (плоскость управления), физически отделены от компонентов, которые пересылают пакеты (плоскость данных). Плоскость данных программируется через плоскость управления, поэтому вы можете настраивать или динамически изменять маршруты передачи данных для достижения целей производительности, безопасности и доступности. Как и многое в нашей отрасли, SDN для корпоративных сетей превратилась в маркетинговый трюк. Первоначальная цель состояла в том, чтобы стандартизировать независимые от поставщика способы перенастройки сетевых компонентов. Несмотря на то что некоторые из этих планов были реализованы, многие поставщики теперь предлагают собственные продукты SDN для предприятий, которые в какой-то мере степени противоречат первоначальной цели SDN. Если вы изучаете пространство предприятия SDN, выбирайте продукты, соответствующие открытым стандартам и совместимые с продуктами других поставщиков. Для крупных поставщиков облачных вычислений SDN добавляет уровень гибкости, который уменьшает вашу потребность знать (или заботиться) о том, где определенный ресурс находится физически. Хотя эти решения могут быть коммерческими, они тесно интегрированы в платформы облачных провайдеров и могут упростить настройку вашей виртуальной инфраструктуры. Сеть SDN и  ее система управления, основанная на  интерфейсах API, предлагают системным администраторам соблазнительную возможность интегрировать управление топологией сети с другими инструментами стиля DevOps для непрерывной интеграции и  развертывания. Возможно, в  каком-то идеальном мире у  вас всегда есть производственная среда, поставленная и  готовая к  активации одним щелчком мыши. По мере того как новая среда продвигается к производству, сетевая инфраструктура магическим образом преобразуется, устраняя простои, заметные для пользователя, и необходимость планировать окна обслуживания.

14.4. Тестирование и  отладка сетей Ключ к отладке сети — ее разбивка на сегменты и тестирование каждого из них до тех пор, пока не будет обнаружена неисправность. Загадочные лампочки на  коммутаторах и концентраторах (обозначающие, к примеру, состояние канала и наличие трафика пакетов) помогают быстро выявить источник проблемы. Для того чтобы эти индикаторы работали так, как вы хотите, следует руководствоваться первоклассной документацией. Как всегда, важно иметь под рукой нужные инструменты, чтобы выполнить работу правильно и без проволочек. На рынке предлагаются средства сетевой отладки двух типов (правда, наблюдается тенденция к их объединению). Устройство первого типа  — ручной кабельный тестер. Он измеряет электрические характеристики кабеля, включая его длину (для этого применяется особая технология,

492

Часть II. Работа в сетях

называемая рефлектометрией во временной области). Такие устройства способны выявлять простейшие проблемы, например разрыв или неправильную разводку кабеля. Нашим любимым инструментом тестирования локальных сетей является устройство Fluke LanMeter. Это универсальный анализатор, способный даже посылать эхо-пакеты протокола ICMP. Профессиональные варианты этого оборудования описаны на специальном веб-сайте. Для телекоммуникационных сетей WAN лучше всего подходит тестер T-BERD, выпускаемый компанией Viavi (viavisolutions.com). Средства отладки второго типа  — это анализаторы сетевых пакетов. Они просмат­ ривают сетевые пакеты на  предмет наличия ошибок протоколов, неправильной конфигурации и  прочего беспорядка. Эти анализаторы работают на  уровне каналов, а  не на  электрическом уровне, поэтому они не могут распознавать проблемы, связанные с физическими повреждениями кабелей или электропитанием. Существуют профессиональные анализаторы сетевых пакетов, но мы нашли свободно распространяемую программу Wireshark7 (wireshark.org), которая может выполняться на полнофункциональном ноутбуке. Именно ее можно считать наилучшим выбором. Более подробная информация об анализаторах сетевых пакетов приведена в разделе 13.12.

14.5. Прокладка кабелей Если вы занялись прокладкой кабелей в здании, то самый ценный совет, который мы можем вам дать, звучит так: “Делайте все правильно с первого раза”. Это не та область, в  которой можно скупиться или халтурить. Покупая качественные материалы, выбирая компетентного подрядчика для прокладки кабелей и устанавливая дополнительные разъемы (отводы), вы тем самым избежите многолетних мучений.

Неэкранированная витая пара Кабель категории 6a имеет наилучшее соотношение цены и производительности на современном рынке. Его стандартный вариант — четыре пары проводов под одной оболочкой, что подходит для большинства соединений, включая RS‑232 и гигабитные линии. Спецификации кабеля категории 6a требуют, чтобы скрутка провода заканчивалась в точке контакта. Для того чтобы обеспечить это требование, необходимы специальное обучение и оконечное оборудование. При этом необходимо использовать настенные розетки и коммутационные панели категории 6а. Самые хорошие отзывы заслужила продукция компании Siemon.

Офисные точки подключения Многие годы идут споры, сколько точек подключения требуется для офиса. Одной точки подключения на офис явно недостаточно. Сколько же нужно — две или четыре? Мы рекомендуем четыре, обосновывая это следующими причинами. • Их можно использовать просто для подключения телефонов и других специализированных устройств. • Большинство пользователей предпочитают подключаться с помощью беспроводных сетей, а не проводов. • Гораздо дешевле проложить весь кабель сразу, чем делать это поэтапно.  Как и многие популярные программы, программа Wireshark часто подвергается атакам хакеров. Убедитесь, что вы используете самую последнюю ее версию. 7

493

Глава 14. Сетевые аппаратные средства

• Средства, выделенные на приобретение проводов, лучше потратить на основную инфраструктуру, а не на оборудование отдельных офисов. При прокладке кабеля в здании можно установить дополнительные розетки в коридорах, конференц-залах, столовых, туалетных комнатах и  на потолках (для точек беспроводного доступа). Однако не забывайте о безопасности и размещайте открыто предоставляемые порты на “гостевой” виртуальной локальной сети, не допуская посторонних к своим внутренним сетевым ресурсам. Публикуя защищенные публичные порты, используйте стандарт аутентификации 802.1x.

Стандарты кабельных систем Необходимость обеспечения всех видов деятельности внутри современных зданий обусловливает потребность в крупной и сложной кабельной инфраструктуре. Заглянув в  обычный коммутационный шкаф, вы будете потрясены, увидев его стенки, сплошь покрытые непомеченными проводами одного цвета. С целью улучшения оперативного контроля и стандартизации кабельных систем зданий в феврале 1993 г. организация TIA опубликовала административный стандарт на телекоммуникационную инфраструктуру коммерческих зданий (TIA/EIA‑606). В 2012 г. появилась его обновленная версия TIA/EIA-606-B. Этот стандарт устанавливает требования и принципы идентификации и документирования телекоммуникационной инфраструктуры. Он касается следующих аспектов: • оконечной аппаратуры; • кабелей; • прокладки кабелей; • расстояний между элементами оборудования; • цветовой маркировки; • символических обозначений стандартных компонентов. В частности, определены стандартные цвета маркировки проводов (табл. 14.5). Таблица 14.5. Таблица цветовой маркировки по стандарту TIA/EIA-606 Тип оконечного устройства

Цвет

Кода

Комментарии

Граничное

Оранжевый

150С

Центральная телефонная станция

Сетевые соединения

Зеленый

353С

Также применяется для вспомогательных электросетей

Общее оборудованиеб

Фиолетовый

264С

Основное оборудование коммутации и передачи данных

Магистраль первого уровня

Белый

Кабели

Магистраль второго уровня

Серый

422С

Кабели

Станция

Синий

291С

Горизонтальные кабели

Магистраль между зданиями

Коричневый

465С

Кампусные кабели

Разное

Желтый

101С

Служебные и сигнальные линии

Ключевые телефонные системы

Красный

184C

а

В соответствии с цветовой моделью Pantone.

б

Офисные АТС, компьютеры, локальные сети, мультиплексоры и т.д.

494

Часть II. Работа в сетях

14.6. Проектирование сетей В этом разделе рассматриваются вопросы, связанные с  логическим и  физическим проектированием сетей среднего размера. Представленные здесь идеи подходят для нескольких сотен хостов, но неприменимы ни для трех, ни для нескольких тысяч компьютеров, включенных в одну сеть. Также предполагается, что работа будет начата с нуля. Основной объем работ по проектированию сети состоит из определения: • типов сред передачи; • топологии и способов прокладки кабелей; • системы концентраторов, коммутаторов и маршрутизаторов. Еще один ключевой вопрос проектирования сети связан с управлением перегрузкой. Например, файловые протоколы NFS и SMB очень сильно загружают сеть, поэтому такие файловые системы нежелательно подключать по магистральному кабелю. Ниже анализируются аспекты, которые необходимо учитывать при проектировании сети.

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

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

Глава 14. Сетевые аппаратные средства

495

чем нужно. Помните: основная часть стоимости прокладки сети приходится на оплату труда, а не на материалы. Даже если волоконно-оптические линии не планируется использовать немедленно, разумно будет все же проложить немного оптического волокна, особенно если известно, что впоследствии протянуть его будет гораздо труднее. Прокладывайте и многомодовый, и одномодовый кабели. Как правило, нужным оказывается как раз тот кабель, который не проложен.

Перегрузка Сеть  — как цепь: ее качество определяется самым слабым или самым медленным звеном. Производительность Ethernet, как и многих других сетевых технологий, при увеличении нагрузки падает. Активно эксплуатируемые коммутаторы, нестыкующиеся интерфейсы, низкоскоростные каналы связи  — все это может привести к  перегрузке. Эффективный способ борьбы с ней заключается в локализации трафика путем создания подсетей и установки маршрутизаторов. Подсети можно использовать и  для изоляции компьютеров, задействованных в отдельных экспериментах. Трудно проводить эксперимент на нескольких компьютерах, если нет надежного способа изолировать их физически и логически от остальной части сети.

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

14.7. Управление сетью Если необходимо обеспечить нормальную работу сети, одни функции управления следует централизовать, другие — распределить, а третьи — оставить на локальном уровне. Требуется сформулировать и согласовать обоснованные “правила поведения добропорядочных граждан”. Типичная крупномасштабная среда включает в себя: • магистральную сеть, соединяющую здания; • сети подразделений, подключенные к магистрали; • подсети рабочих групп в рамках подразделения; • соединения с внешним миром (например, с Интернетом или периферийными филиалами).

496

Часть II. Работа в сетях

При проектировании и реализации сетей следует предусматривать централизованные контроль, ответственность, сопровождение и финансирование. Поскольку подразделения, как правило, стремятся свести к  минимуму собственные расходы, быстро растет число сетей с централизованной оплатой каждого соединения. Вот основные объекты централизованного управления: • структура сети, в том числе принципы использования подсетей, маршрутизаторов, коммутаторов и т.д.; • магистральный кабель, в том числе подключения к нему; • IP-адреса и имена компьютеров, доменные имена; • используемые протоколы (требуется обеспечить их взаимодействие); • правила доступа в Интернет. Имена доменов, IP-адреса и сетевые имена компьютеров в определенном смысле уже находятся под  централизованным контролем таких организаций, как ARIN (American Registry for Internet Numbers) и ICANN, но координация использования этих элементов на локальном уровне также необходима. Центральный орган управления имеет общее представление о  сети, ее структуре, производительности и перспективах роста. Он может позволить себе иметь собственное контрольное оборудование (и обслуживающий его персонал) и следить за нормальной работой магистральной сети. Центральный орган может настоять на правильном выборе структуры сети, даже если для  этого придется заставить подразделение купить маршрутизатор и создать подсеть для подключения к магистрали. Такое решение иногда необходимо для того, чтобы новое соединение не навредило работе существующей сети. Если в сети работают разнородные компьютеры, операционные системы и протоколы, обязательно нужно иметь “высокоинтеллектуальный” маршрутизатор (например, компании Cisco), который будет служить шлюзом между сетями.

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

Кабели и разъемные соединения AMP (подразделение Tyco) (800) 522-6752 amp.com Belden Cable (800) 235-3361 (765) 983-5200 belden.com

Anixter (800) 264-9837 anixter.com

Black Box Corporation (724)746-5500 blackbox.com

Siemon Company (860) 945-4395 siemon.com

Newark Electronics (800) 463-9275 newark.com

497

Глава 14. Сетевые аппаратные средства

Тестовые приборы Fluke (800) 443-5853 fluke.com

Siemon (800) 945-4395 siemon.com

Viavi (844) 468-4284 vivasolutions.com

Маршрутизаторы/коммутаторы Cisco Systems (415) 326-1941 www.cisco.com

Juniper Network (408) 745-2000 juniper.com

14.9. Литература • ANSI/TIA/EIA-568-A. Commercial Building Telecommunications Cabling Standard и ANSI/TIA/EIA-606, Administration Standard for the Telecommunications Infrastructure of Commercial Buildings. Это стандарты телекоммуникационной промышленности для построения кабельных систем зданий. К сожалению, они не бесплатны. Посетите веб-сайт www.tiaonline.org. • Barnett David, Groth David and Jim McBee. Cabling: The Complete Guide to Network Wiring (3rd edition). San Francisco: Sybex, 2004. • Goransson, Paul, and Chuck Black. Software Defined Networks, A Comprehensive Approach (2nd Edition). Burlington, MA: Morgan Kaufman, 2016. • Spurgeon, Charles, and Joann Zimmerman. Ethernet: The Definitive Guide: Designing and Managing Local Area Networks (2nd Edition). Sebastopol, CA: O’Reilly, 2014.

Глава

15

IР- маршрутизация

Во всем м ире доступн ы более 4,3 миллиарда I Р-адресов, поэтому получение пакетов в нужном месте в И нтернете — непростая задача. 1 Маршрутизация I Р- пакетов уже была кратко представлена в главе 1 3 . В этой главе мы рассмотрим процесс м аршрутизации более подробно и исследуем несколько сетевых протоколов, которые позволяют марш­ рутизаторам автоматически обнаруживать эффективные маршруты. П ротоколы маршру­ тизации не только уменьшают административную нагрузку, связанную с обработкой ин­ формации о маршрутизации , но также позволяют быстро перенаправить сетевой трафик, если маршрутизатор, соединение или сеть не вышли из строя. Важно отл ичать реальное перенаправлен ие I Р- пакетов от управл е н и я табл и ц е й маршрутизаци и , хотя в обоих случаях употребляют один и тот ж е термин — маршрути­ зация . Перенаправление пакетов — простая п роцедура, тогда как вычислен ие маршрутов происходит по довольно запутанному алгоритму. Мы познакомимся только с одноадрес­ ной маршрутизацией, так как при многоадресной ( когда пакеты направл яются групп е подписчиков) возникает ряд новых проблем , рассмотреть которые, учитывая объем кни­ ги, не представляется возможным. Для того чтобы составить правильное представл е н ие о маршрутизации , в бол ьш и н ­ стве случаев достаточ н о и н формац и и , изложе н н о й в главе 1 3 . Если сетевая и нфра­ структура уже налажена, можно просто задать единственный статический маршрут ( как описано в разделе » Маршрутизация » ) и все готово — у вас есть и н формация обо все м И нтернете . Если ж е вы стрем итесь с правиться с сетью, имеющей сложную топологию , или используете операционные систе м ы U N IX л ибо Linux как часть своей сетевой и н ‘ C м . wapo . s t /w o r l d- i p .

Часть 11. Работа в сетях

500

фраструктур ы , тогда эта глава о протоколах и инструме нтах динамической маршрутиза­ ции окажется полезной для вас .2 Р- м аршрутизация ( как дл я 1 Pv4, так и для Рvб ) — маршрутизация » следующего перехода » . В л юбой момент времени с истеме, обрабатывающей пакет, необходимо опре­ дел ить тол ько следующ и й хост ил и маршрутизатор в пути пакета до конечного пун кта назначен и я . Это отличается от подхода многих устаревших протоколов, которые опре­ деляют точн ы й путь, по которому пакет будет перемещатьс я , прежде чем покинет свой исход н ы й хост, схему, известную как маршрутизация от источн и ка. 3

1 5 . 1 . ПОДРОБНЕЕ О МАРШРУТИЗАЦИИ ПАКЕТОВ П режде чем приступать к изуч е н и ю ал горитмов марш рутизаци и , расс мотрим под­ робнее , как испол ьзуются маршрутн ые табл и ц ы . П редположим , сеть и меет топологи ю , изображенную на р и с . 1 5 . 1 .

Хост A

199.165.146 сеть

145.17 145.24

Маршрутизатор R1

146.1

146.4

Хост B

146.3

Маршрутизатор R2

199.165.145 сеть

в Интернет 216.12.111.80

Рис. 15. 1. Демонстрационпая сеть

Для простоты м ы нач и наем этот пример с протокола 1 Pv4; табл и ца маршрутизации Рv б приведен а ниже . М аршрутизатор R I соед и н яет две сети , а маршрутизатор R2 одну из э т и х сете й с вне ш н и м миром. П осмотр и м , как выглядят таблицы маршрутизац и и и не которые кон­ кретные сценар и и перенаправле ния пакетов. Табл и ца хоста А выглядит следующим об­ разом. —

А$ nets tat — rn

De s t i n a t i on 127 . 0 . 0 . 0 1 9 9 . 1 65 . 1 4 5 . 0

Gateway

о.о.о.о о.о.о.о

Ge nma s k 255 . 0 . 0 . 0 255 . 255 . 255 . 0

u u

о.о.о.о

1 99 . 1 65 . 1 4 5 . 2 4

о.о.о.о

UG

Fl a g s

M S S W i ndow i r t t I fa c e о о lo о e th O о о о о ethO о о

В приведе н ном в ы ш е при мере для запроса табл и ц ы маршрутизаци и и спол ьзует­ ся хорошо известн ы й инструмент netstat. Этот и нструмент распространяется с опе­ рационной системой Free B S D и доступен для Li nux как часть пакета net — too l s . Этот пакет бол ьше не и меет активной поддержки и , как резул ьтат, считается устарев ш и м . Официал ьно рекомендован н ы м с пособом получить эту и н формаци ю в Linux я вляется менее фун кционал ьная команда ip route: 2 М ы не рекомендуем использовать с истемы U N I X или Linux в качестве сетевых маршрутизаторов в производствен ной и нфраструктуре — лучше купите выделенный маршрутизатор. ‘ 1 Р- п а кеты также м о гут м арш рут изи роваться на ос н ове адреса отп ра в ител я — п о кра й н е й мере теорети чес к и , но это почти н и когда не вы п ол няется . Эта фун к ция н е получ ила ш и рокого расп ространения из соображен и й безопасности .

Глава 1 5. IР-маршрvтизация

501

А$ ip route de f a u l t v i a 1 9 9 . 1 6 5 . 1 4 5 . 2 4 dev e t h O onl i n k 1 9 9 . 1 6 5 . 1 4 5 . 0 / 2 4 dev e t h O p r o t o k e r n e l s c ope l i n k s r c 1 9 9 . 1 6 5 . 1 4 5 . 1 7

Результат работы команды netstat — rn н е м ного легче ч итать, поэтому м ы исполь­ зуем его для последующих примеров и исследования рис. 1 5 . 1 . Хост А и меет самую п ростую кон ф и гурацию среди всех ч етырех ком пьютеро в . Первые два маршрута описы вают собствен н ы е сете вые интерфейсы хоста. О н и необхо­ дим ы , чтобы пакет ы , направляе м ы е непосредстве нно в подкл юче н н ые сети , не марш­ рутизировал ись особы м образом. Устройство e t h O — это Еthеrnеt- и нтерфейс хоста А, а lo — и нтерфейс обратной связи (виртуал ьн ы й сетевой и нтерфе йс, эмулируе м ы й про­ грам м н ы м обес печ е н и е м ) . Обы ч но такие записи автоматически добавля ются при кон ­ фигурирова н и и сетевого и нтерфейса.

W См. обсуждение сетев ых масок в разделе 1 3 .4. Ста ндартн ы й маршрут хоста А задает пере направл е н и е всех пакет ов, не адр есова н ­ н ых и нтерфейсу обратной связи и л и сети 1 95 . 1 65. 1 45, на маршрутизатор R I , адрес кото­ рого в дан ной сети — 1 99 . 1 65 . 1 45 . 24. Шлюзы должн ы находиться на расстоя н и и одного перехода.

m Дополн ительную и нформацию об адресах см. в разделе 1 3 . 3 . Предположи м теперь, что хост А пос ылает пакет хосту В с адресом 1 99. 1 65 . 1 46 . 4 . I Р- подсистема ищет маршрут к сети 1 99. 1 65. 1 46 и , не найдя такового , отправляет пакет по стандартному маршруту, т. е . маршрутизатору R 1 . На рис. 1 5 . 2 приведен а структура пакета, проходящего по сети Ethemet (в заголовке Ethe rnet указаны МАС-адреса соот­ ветствующих интерфейсов ком пьютеров А и R I в сети 1 45 ) . Заголовок Ethernet

Заголовок IP

От: A Кому: R1 Тип: IP

От: 199.165.145.17 Кому: 199.165.146.4 Тип: UDP

Заголовок UDP и данные

ПАКЕТ UDP ПАКЕТ IP ФРЕЙМ ETHERNET

Рис. 15. 2. Ethernet-naкem

Аппаратн ы й Ethernet-aдpec пол учателя соответствует марш рутизатору R 1 , но 1 Р­ пакет, скрытый в Ethe met-фpe й м e , не содержит н и каких упоми н ан и й о маршрутизато­ ре. Когда маршрутизатор просматривает поступи в ш и й пакет, он обнаруживает, что н е я вляется его получател е м . Тогда он обращается к собствен ной табли це маршрутизаци и , чтобы узнать, как переслать пакет хосту В , н е переписывая его I Р-заголовок ( необходи ­ мо, чтобы отправителем пакета оставался хост А). Табл ица маршрутизации устройства RI выглядит следующим образом. R l $ netstat — rn G a t ewa y De s t i na t i on о.о.о.о 127 . 0 . 0 . 0 1 9 9 . 1 65 . 1 4 5 . О о . о . о . о 1 99 . 1 65 . 1 4 6 . 0 о . о . о . о 1 99 . 1 65 . 1 4 6 . 3 о.о.о.о

Genma s k 255 . 0 . 0 . О 255 . 255 . 255 . 0 255 . 255 .255 . О

u u u

Flags

MSS

о.о.о.о

UG

о о о о

W i ndow i r t t I f a c e lo о о о ethO о ethl о о ethl о о

Часть 11. Работа в сетях

502

Она почти аналогична табл ице хоста А. за искл ючением того, что здесь присуrству­ ет два физических сетевых и нтерфейса. Стандартн ы й маршрут в дан ном случае ведет к устройству R2, поскольку через него осуществляется выход в И нтернет. Пакеты , адре­ сован ные любой из сетей 1 99. 1 65 , доставляются напря мую. Подобно хосту А, хост В имеет оди н реальный сетевой интерфейс. Но для корректного функцион ирования ему необходим допол н ительный маршруr, поскольку хост имеет пря­ мое соединен ие сразу с двумя маршруrизаторам и . Трафик сети 1 99 . 1 65 . 1 45 должен про­ ходить через устройство R l , а весь остальной трафик — направляться в И нтернет через устройство R2. В$ netstat rn De s t i n a t i on 127 . 0 . 0 . 0 1 99 . 1 65 . 1 4 5 . 0 1 99 . 1 65 . 14 6 . 0 —

о.о.о.о

G a t ewa y

Fl a g s

u u u

MSS

о.о.о.о

Genma s k 255 . 0 . 0 . 0 255 . 255 . 255 . 0 255 . 255 . 255 . О

1 99 . 1 65 . 1 4 6 . 3

о.о.о.о

UG

о о о

о.о.о.о 1 99 . 1 65 . 14 6 . 1

W i ndow i r t t I f a c e lo о о о ethO о о о ethO о ethO о

о

lll Описание переадресации I C M P с м . в разделе 1 3 . 5 . Теоретически, как и хост А, хост В можно сконфигурировать так, чтобы изначально он «знал » только об одном шл юзе , полагаяс ь на помощь дире ктив переадресации про­ токола I C M P для устранения избыточ ных переходов. Н иже показан пример начал ьной конфигурации. В $ netstat

rn

D e s t i n a t i on 127 . 0 . 0 . О 1 99 . 1 65 . 14 6 . 0 О.О.О.О

Gateway О.О.О.О О.О.О.О 1 99 . 1 65 . 1 4 6 . 3

G e nma s k 255 . О . О . О 255 . 255 . 255 . 0 О.О.О.О

Flags U U

UG

MSS О О О

W i ndow О О О

irtt О О О

I face lo ethO ethO

Теперь, есл и хост В посылает пакет хосту А ( 1 99. 1 6 5 . 1 45 . 1 7 ) , пря мой марш руr най­ ден не будет, и пакет отправится на устройство R2. П оскольку устройство R2 я вляется маршруrизатором , оно и меет полную информацию о состоя н и и сети и. следовател ьно, «знает» о роли устройства R l , куда и будет послан пакет. Кроме того, маршруrизатор R2 обнаружит, что хосты Rl и В находятся в одной сети, поэтому он допол н ител ьно напра­ вит хосту В I С М Р-сообщение, в соответстви и с которы м хост В добавит в свою табли цу маршруrизации прямой маршруr к хосту А. 1 9 9 . 1 6 5 . 1 4 5 . 1 7 1 9 9 . 1 6 5 . 1 4 6 . 1 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UGHD

о

о

о

ethO

Благодаря этому маршруту весь трафик, адресован н ы й хосту А, начнет идти непо­ средстве нно через маршруrизатор R l . Однако это изме н е н ие н е затраги вает трафи к к другим хостам в сети 1 45. Для н и х нужно получ ить отдельн ые директивы о т маршру­ тизатора R2. Некоторые адм и н истраторы выбирают для своих систе м директивы переадресации протокола I C M P в качестве основного » протокола» маршруrизаци и , думая , что подоб­ н ы й подход обеспечит бол ьшую динам ичность. К сожалению, с исте м ы и маршруrиза­ торы осуществля ют перенаправление по-разному. Н екоторые хранят эти директивы по­ стоя нно. Другие удаля ют их из табл и ц ы маршруrизаци и через относител ьно короткое время ( 5- 1 5 минут) . Третьи вообще и гнорируют их, что, вероятно, правил ьно с точ ки зрения безопасности. П ере направле н ия и м е ют нес кол ько других поте н циальных недостатков: напр и м е р , увел ичение нагрузки на сеть, увеличение нагрузки на R2 , беспорядок в табл и це мар ш ­ руrизации и зависимость о т дополнительных серверов, поэтому м ы не рекомендуе м и х

Глава 1 5 . IР- маршрутизация

503

использовать. В правил ьно настроен ной сети перенаправл е н и я н и ко гда не должны по­ являться в табл и це маршрутизации . Если в ы используете адреса 1 Pv6 , применяется та ж е модель. Вот как выгл ядит таб­ лица маршрутиза ц и и с хоста. работающе го под управл е н и е м операци о н н о й с исте м ы Fre e B S D , на котором запущен протокол 1 Pv6: $ ne tstat — rn De s t i n a t i on de fau l t 2 0 0 1 : 8 8 бЬ : 4 4 5 2 : : / 6 4 fe B 0 : : / 1 0 fe 8 0 : : % r e 0 / 6 4

G a t eway 2 0 0 1 : 8 8 6Ь : 4 4 5 2 : : 1 link# l : :1 link# l

Fl a g s UGS u

UGRS

u

Neti f reO reO loO reO

Exp i r e

Как и в протоколе 1 Pv4, первый маршрут я вляется значением по умолчани ю , которое испол ьзуется , когда нет более конкретн ых записей. Следующая строка содержит марш рут к глобальной сети 1 Pv6, где н аходится хост, 2 0 0 1 : 8 8 6Ь : 4 4 5 2 : : / 6 4 . П оследн ие две строки я вля ются особе н н ы м и ; о н и представл я ют марш рут к зарезервирова н н ой сети 1 Pv6 f e 8 0 , известной как локал ьная сеть одноадресатной п ередач и . Эта сеть испол ьзу­ ется для трафи ка, которы й при вязан к локальному ш ироковещател ьному домену ( как правило, к одному и тому же сегменту физической сет и ) . Он чаще всего используется сете в ы м и службам и , которые должны найти друг друrа в одноадресатной сети, напри­ мер OSPF. Н е испол ьзуйте подобн ы е локал ьн ы е адреса для обычных сетевых цел е й .

1 5.2. ДЕМОНЫ И ПРОТОКОЛЫ МАРШРУТИЗАЦИИ В простых сетях , подобно той , которая представлена на рис. 1 5 . 1 , маршрутизацию целесообразно настраи вать вручную. Одн ако с определен ного моме нта сети становят­ ся сл и ш ко м слож н ы м и для подобного адми нистрирова н и я . Вместо того чтобы явно со­ общать каждому ком п ьютеру, как находить другие ком п ьютер ы и сети , лучш е заставить сам и ком п ьютеры искать эту и н формацию. Данная задача возлагается н а протокол ы марш рутизации и демон ы , которы е их реал изуют. Основное преимущество протоколов маршрутизации над системами статической марш ­ рутизации закл ючается в том , что они позволяют быстро адаптироваться к изменениям в тополоrии сети. Когда пропадает канал с вязи, демоны быстро находят альтерн ативные маршруты, если они существуют, и сообщают о н их в сети, связанн ые с этим каналом. Де м о н ы марш рутиза ц и и собирают и н форм а ц и ю из трех источ н и ков: конфи гура­ цио н н ы х файлов , существующих табл и ц марш рутиза ц и и и » родстве н н ы х » демонов других с исте м . Собра н н ы е дан н ы е объединяются , и вычисляется оптимал ьн ы й набор марш рутов, после чего новые марш руты записываются в систе м н ую табл и цу (и при н е ­ обходимости пос ылаются другим систе мам посредством протоколов маршрутизац и и ) . Состоя н и е сети вре мя о т вре м е н и м е н яетс я , поэтому демон ы дол ж н ы периодически опра ш и вать друг друга , чтобы убедиться в актуал ьности имеющейся у них и н формации. Конкретн ы й ал горитм выч исл е н и я маршрутов зависит от протоколов. Последн и е бывают двух типов: дистанционно- векторн ые и топологические.

Ди ста нционно — векторные п ротокол ы В основе дистан ционно-векторных протоколов лежит следующая идея: если маршрути­ затор Х находится в пяти переходах от сети У и я вляется моим соседом, то я нахожусь в ше­ сти переходах от дан ной сети. Демон , работающий по такому протоколу, объя вля ет о том .

Часть 11. Работа в сетях

504

как далеко, по его расчетам, расположены известные ему сети. Если соседние демоны не «знают» более коротких маршрутов к этим сетям, они помечают данный компьютер как оп­ тимальны й шлюз. В противном случае они просто игнорируют этот анонс. Предполагается, что со временем таблицы маршрутизации придут в стабильное состояние. Это де йствител ьно эле гантная идея , и , если бы все работало так, как задумано, маршрутизация существенно упростилась бы. К сожал е н и ю , описа н н ы й ал горитм н е луч ш и м образом справляется с измен е н и я м и топологии . 4 И ногда стабилизация таблиц вообще н е наступает вследствие возникновения бесконеч н ых циклов (например, марш ­ рутизатор Х получает и нформацию от маршрутизатора У и посылает ее маршрутизатору Z, который возвращает ее маршрутизатору У) . На практике приходится вводить сложные эвристические правила или задавать ограничения . К примеру, в протоколе R I P ( Routing Information Protocol — протокол маршрутной и нформации) сч итается , что л юбая сеть, находящаяся на расстоян и и более пятнадцати переходов, недоступна. Даже в обы ч н ы х ситуациях может потребоваться сли ш ком м н ого циклов обновле­ ний, прежде чем все маршрутизаторы перейдут в стабильное состоя н ие. Следовательно, чтобы не превысить допустимые пределы , необходимо сделать периоды обновл е н и й ко­ ротк и м и , а это , в свою очередь, ведет к тому, что дистанционно-векторные протокол ы о казываются сли ш ком » словоохотл и в ы м и » . Н апример, протокол R I P требует, чтобы маршрутизаторы осуществляли ш и роковещательную рассылку всей и м е ющейся у н и х информации каждые 30 с. В протоколе E I G R P обновления анонсируются каждые 9 0 с. В противоположность этому в протоколе BG P ( Border Gateway Protocol — протокол гранич ного шлюза) вся таблица посылается один раз, после чего изменения распростра­ няются по мере возни кнове н и я . Такая опти м изация позволяет существе нно с н и зить » переговорн ы й » трафик (бол ьш е й частью ненужн ы й ) . В табл . 1 5 . 1 перечислены дистан ционно-векторные протоколы , ш ироко используе­ мые в настоящее время. Таблица 1 5 . 1 . Распространенные дистанционно- векторные протоколы маршруrизации Аббревиатура

Полное название

Область применения

RIP

Routing lnformation Protocol (протокол маршрутной информации)

Локальные сети

RI Png

Routing lnformation Protocol (протокол маршрутной информации), следующее поколение

Локальные сети с протоколом IPvб

EIGRP •

Enhanced lnterior Gateway Routing Protocol (улучшенный протокол маршрутизации внутреннего шлюза)

Глобальные сети, корпоративные локальные сети

BGP

Border Gateway Protocol (протокол граничного шлюза)

Магистральные сети Интернета

• П ротокол EIGRP является собственностью компании Cisco .

Топологические п ротокол ы В топологичес к и х протоколах, или протоколах состояния канал а , и н формация рассылается в относительно н еобработан ном виде . Записи в ы гл ядят п р и м ерно так: » Маршрутизатор Х является с м ежн ы м по отноше н и ю к маршрутизатору У, и канал функцион ирует » . Пол н ы й набор таких записей образует карту сетевых связе й , на ос4 П робле ма заклю ч ается в том , что и з м е н е н ия топологии могут п р и водит ь к удл и н е н и ю существующих маршрутов. Некоторые дистанционно-векторные протокол ы , например E I G RP, хранят и нформацию о всех возможны х марш рута х , чтобы н а кра й н и й случай б ыл » пл ан отступления » . Впрочем , ко н кретные детали не так уж важны .

Глава 1 5. IР-маршрутизация

505

нован и и которо й кажд ы й маршрутизатор может сформ ировать собственную табл ицу. Основное преимущество топологических протоколов, по сравнению с дистанционно­ вектор н ым и , закл ючается в с пособности быстро стабилизировать табли ц ы маршрути­ зации в случае н епредвиденного сбоя . К издержкам относится необходимость хранения полной карты соеди н е н и й на каждом хосте , дл я чего требуются допол н ительн ые про­ цессорные мощности и память. Поскольку процесс общения между маршрутизаторами не ямяется частью собственно алгоритма вычисления маршрутов, поямяется возможность реализовать топологические протоколы так, чтобы не возникало циклов. Изменения в тополоmческой базе данн ых рас­ пространяются по сети очень быстро, не перегружая ни канал, ни центральны й процессор. Топологические протоколы сложнее дистанционно-векторных, зато они позволяют ре­ ализовать такие технологии , как маршрутизация на основании запраши ваемого типа об­ служивания (поле TOS I Р- пакета) и поддержка нескольких маршрутов к одному адресату. Единствен н ы м топологически м протоколом , п ол уч и в ш и м ш ирокое распростране­ ние, я мяется протокол O S P F.

М етрика стоимости Для того чтобы протокол марш рутизации мог определить, какой путь к заданной сети я вляется кратчайш и м , необходи мо в начале выяснить, что значит » кратчайши й » . Это путь с наименьш им числом переходов? С наименьш е й задержкой? С наименьшими финансовы м и затратами? Для целей маршрутизации качество канала связи определяется числом , называем ы м метрикой стоимости . П утем сложения м етрик отдельных отрезков пути вычисл яется общая стоимость маршрута. В простейших с истемах каждому каналу назначается сто­ имость 1 , и в резул ьтате метрикой маршрута становится число переходов. Но л юбой из перечисленных выше критериев может я вляться метрикой стоимости . Эксперты в области сете й дол го и упорно трудил ись над тем , чтобы определ е н и е такого понятия , как метрика стоимости , было максимальн о гибки м , а н екоторые со­ временные протоколы даже позволяют использовать разн ые метрики для разн ых видов сетевого трафика. Тем не менее в 99% случаев на все это можно не обращать внимания. Для больши нства систем вполне подойдут стандартн ые метрики. Бы вают ситуаци и , когда кратчай ш и й физичес к и й марш рут к адресату н е должен быть выбран по умолчанию из адм ин истративных соображен и й . В таких случаях мож­ но ис кусстве нно завысить метрики критических каналов. Всю остал ьную работу предо­ ставьте демонам.

Внутрен ние и внеш ние п ротоколы Автономная система это группа сете й , находящ ихся под адми нистратив н ы м ил и пол итически м контролем одного юридического л и ца. Такое определен ие довольно рас­ пл ы вчато. Реальные автономные с исте м ы могут представлять собой как глобальные корпоративные сети , так и сети универс итетов или даже отдельных факультетов. Все зависит от того , как осуществляется маршрутизация . Се йчас наблюдается тенде нция к укрупнению автономных систе м . Это упрощает адми н истрирование и повышает эф­ фективность маршрутизации . Маршрутизация внутри автономной систе м ы отл ичается от маршрутизации между такими систе мам и. Протокол ы второго типа (внешние, или протокол ы вне ш н их шлю­ зов) дол ж н ы управлять множеством маршрутов к разл и ч н ы м сетя м и учиты вать тот —

Часть 11. Работа в сетях

506

факт, что соседн ие маршрутизаторы находятся под контролем других люде й . Внешние п ротокол ы не раскры вают топ ологи ю автономной систе м ы , поэтом у в определенном с м ысле и х можно рассматривать как второй уровен ь маршрутизаци и , на котором соеди­ н я ются групп ы сете й , а не отдельные ком пьютеры ил и кабели . На практике небольш и м и среднего размера организациям редко требуется внешний протокол, если только они не подключены к нескольким провайдерам одновременно. При наличии нескольких провайдеров традицион ное разделение на локальный домен и доме н Интернета нарушается, поскольку маршрутизаторам приходится определять, какой марш ­ рут в Интернете лучше всего подходит для конкретного адреса. (Это не означает, что каж­ дый маршрутизатор должен знать всю необходимую информацию. Большинство хостов мо­ жет направлять свои пакеты внутреннему шлюзу, хранящему необходимые сведения . ) Поскольку внеш ние протокол ы не сильно отличаются о т своих внутре нних аналогов, в этой главе мы сосредоточ им внимание на внутренних протоколах и демонах, которые их поддерживают. Есл и в ваш е й сети поддерживается внешний протокол , обратитесь к литературн ы м источн и ками , ссыл ки на которые при веде н ы в кон це главы .

1 5 .3 . ОСНОВНЫЕ ПРОТОКОЛЫ МАРШРУТИЗАЦИИ В этом разделе м ы познаком имся с ос новн ыми внутрен н и м и протоколами маршру­ тизаци и , узнаем их преи мущества и недостатки .

Протокол ы RI P и RI Png RIP ( Rout i ng I nform at ion Protocol — протокол мар шрутной и н формац и и ) — это стары й протокол ком п а н и и Xerox , адаптирован н ы й для I Р-сете й . Е го I Р- верс и я была описана примерно в 1 988 году в документе RFC 1 058. Существует три верс и и этого про­ токола: R I Pv l , RI Pv 2 и RI Png тол ько для протокола 1 Pv6 (ng (next generation) озн ачает «следующее поколен ие » ) . В с е версии этого протокола п редставля ют собой простые дистан ционн о -векторные протокол ы , метрикой стои мости в которых я вляется кол ичество переходов. П оскол ьку п ротокол R I P разрабатывался в те времена, когда отдельные ком п ьютеры были доро­ гим и , а сети мален ьки м и , в верс и и R I Pv l п редполагаетс я , что все хосты , находящие­ ся на расстоя н и и пятнадцати и более переходов, н едоступны. В более поздн их версиях это огран ичение не было с нято , чтобы стим ул ировать адм и н истраторов сложн ых сетей переходить на более сложн ые п ротокол ы маршрутизаци и. W И нформация о бе склассовой адресаци и , и з вестной под и м е н е м C I D R , п р и веде на в разделе 1 3 .4. П ротокол R I Pv2 это улучшенная версия протокола RI P, в которой вместе с адре­ сом следующего перехода передается сетевая маска. Это упрощает управление сетя м и , где есть подсети и применяется п ротокол C I D R, по сравн е н и ю с п ротоколом RI Pv l . В нем была также предпринята невнятная попытка усилить безопасность протокола R I P. П ротокол R I Pv2 можно в ыпол нять в режим е совместимости . Это позволяет сохра­ н ить бол ь ш инство его новых фун кциональных возможносте й , не отказываясь от п олу­ ч ател е й , ис пользующих простой протокол RI P. Во м н огих асп е ктах протокол R I Pv2 идентичен исходному протоколу, и отдавать предпочте ние следует именно е м у. —

W Детал и протокола 1 Pv6 при ведены в разделе 1 3. 2 .

Глава 1 5. IР-маршрутизация

507

Протокол RI Png представляет собой переформул ирование п ротокола RI P в терми­ нах протокола 1 Pv6. О н может испол ьзоваться только в рамках протокола 1 Pv6 , в то вре мя как п ротокол R I Pv 2 — тол ько в рамках протокола I Pv4. Если в ы хотите и с ­ пользовать к а к протокол I Pv4, так и протокол 1 Pv6 вместе с протоколом R I P, т о RI P и RI Png н еобходимо выполнять как отдел ьные протоколы . Н есмотря на то что протокол R I P известе н своим расточительн ы м испол ьзова н и ­ ем широковещательного режима, он весьма эффективен при частых изменениях сети , а также в тех случаях, когда топология удаленных сетей н еизвестна. Однако после сбоя канала он может замедлить стабилизацию системы. Сначал а исследовател и были уверен ы , что появл е н ие более сложных протоколов маршрутизации , таких как OSPF, сделает протокол R I P устаревшим. Тем не менее про­ токол R I P продолжает испол ьзоваться , потому что он п росто й , легкий в реал изац и и и не требует сложной настройки. Таким образо м , слухи о смерти протокола R I P оказа­ лись сли ш ком преувеличенными. Протокол R I P ш ироко испол ьзуется на платформах, н е использующих операцион ­ ную систему U N IX. М н огие устройства, вкл ючая сетевые принтеры и сетевые управля­ емые SNМ Р-ком поненты, с пособ н ы принимать RI Р-сообщения , узнавая о возможн ых сетевых шлюзах. Кроме того , почти во всех версиях с истем UN IX и Linux в той или иной форме существует клиент протокола RI P. Таким образом, протокол R I P считается » наименьш и м общим знаменателем» протоколов маршрутизации. Как правило, он при­ меняется для маршрутизации в пределах локальной сети, тогда как глобальную м аршру­ тизацию осуществляют более мощные протоколы . Н а некоторых серверах запускаются пассивные демоны протокола R I P (обычно де­ мон routed или ripd из пакета Quagga ) , которые ожидают сообщен и й об изме н ен и ­ я х в сети , н е осуществляя ш и роковещател ьной рассылк и собствен ной и н формаци и . Реал ьн ы е выч исления маршрутов выпол н я ются с помощью более производительных протоколов, таких как OSPF (см . следующий раздел) . П ротокол RIP используется толь­ ко как меха н изм распространения.

Протокол OSPF O S P F (Open Shortest Path First — открытый протокол обнаружения первого кратчайше­ го маршрута) является самым популярным топологическим протоколом . Термин первый кратчайший маршрут (shortest path first) означает специальны й математический алгоритм , по которому вычисляются маршруты; термин открытый (ореn) — синоним слова «непатен­ тованный». Основная версия протокола OSPF (версия 2) определена в документе RFC2328, а расш иренная версия протокола OSPF, поддерживающая протокол 1Pv6 (версия 3), — в до­ кументе R FC5340. Первая версия протокола OSPF устарела и сейчас не используется. O S PF — протокол про м ы шлен ного уров н я , который эффективно фун кцион ирует в кру п н ы х сетях со сложной топологией . По срав н е н и ю с протоколом R I P, он и меет ряд п р е и м уществ, вкл ючая возможность управл е н и я н е с кольким и маршрутам и , ве­ дущ и м и к одному адресату, и возможность разделения сети н а сегменты ( «области » ) , которые будут делиться друг с другом только высокоуровневыми дан н ы м и маршрути­ зац и и . Сам протокол очень сложны й , поэтому и меет смысл испол ьзовать е го только в крупных системах, где важна эффективность маршрутизации . Для эффективного ис­ пол ьзования протокола OSPF н еобходимо, чтобы ваша схема адресации и м ела иерар ­ хический характер.

508

Часть 11. Работа в сетях

В спецификации протокола O S P F не навязывается конкретная метрика стоимости. По умолчани ю в реализац и и этого протокола компанией Cisco в качестве метрики ис­ пользуется пропускная способность сети.

П ротокол EIGRP E IG RP ( Enhanced l nterior Gateway Routing Protocol — улуч ш е н н ы й протокол мар ш ­ рут изац и и внутр е н н е го шлюза) — это патентова н н ы й протокол маршрутизаци и , и с ­ пользуе м ы й только маршрутизаторам и ком пани и Cisco. Протокол I G RP б ы л разработан для устранения н е которых недостатков протокола R I P еще в те времена, когда не было такого надежного стандарта, как протокол O S PF. Протокол I G RP был отклонен в пользу протокола E I G R P, которы й допускает произвольные сетевые м аски C I D R. Протоколы I G RP и E I G P R конфигурируются оди наково, несмотря на различия в их организации . Протокол E I G RP поддерживает протокол 1 Pv6, но в н е м , как и во всех других про­ токолах маршрутизаци и , адресные пространства 1 Pv6 и 1 Pv4 конфигурируются отдельно и существуют как параллельные дом е н ы маршрутизации. П ротокол E I G R P является дистанционно-вектор н ы м , но он спроектирован так, что­ бы избежать пробл е м зацикливания и м едл е нной стабилизации , свойстве н н ых другим протокола м дан ного класса. В этом с мысле протокол E I G R P считается образцом . Для большинства прим е н е н и й протоколы E I G RP и O S P F обеспечи вают равн ые функцио­ нальные возможности.

BG P: п ротокол граничного шл юза Протокол BGP ( Border Gateway Protocol — протокол гран ич ного шл юза) я вляется протоколом внешней м ар шрутизаци и , т. е . он управляет трафиком между автономн ы м и системами , а не м ежду отдельны м и сетя м и . Существовало несколько популярных про­ токолов внеш н е й маршрутизации , но протокол BG Р пережил их всех. В настоящее время BG Р является стандартны м протоколом , испол ьзуе м ы м для ма­ гистральной м ар ш рутизации в И нтернете . В средине 20 1 7 года табл и ца маршрутиза­ ции И нтернета содержала около 660 тысяч префиксов. Совершенно оче видно, что это масштаб , при которо м маг истральная маршрутизация существе н н о отличается от ло­ кальной.

1 5.4. Мно гоАдРЕСАТНАЯ кооРдинАция ПРОТОКОЛА МАРШРУТИЗАЦИИ Маршрутизаторы должны обме н иваться информаци е й , чтобы узнать, как добраться до м ест в сети , но, чтобы добраться до мест в сети, он и должны поговорить с маршрути­ затором . Эта проблема с курицей и яйцом чаще всего решается посредством м ногоадре­ сатной связи. Это сетевой эквивалент согласия на встречу с ваш и м другом на опреде­ ленном углу улицы, если вы разделитесь. Этот процесс обычно невидим для с исте м н ых адми нистраторов, но иногда вы можете видеть этот м ногоадресатный трафик в трасси­ ровке пакета или при других видах сетевой отладки. Согласованн ые групповые адреса для различных протоколов маршрутизаци и пере­ ч исле н ы в табл . 1 5. 2 .

Глава 1 5. IР-маршрутизация

509

Таблица 1 5 . 2 . Групповые адреса дпя протоколов марwрутизации Описание

1 Pv6

1Pv4

Все системы в подсети

f f02 : : 1

22 4 . 0 . 0 . 1

Все маршрутизаторы в подсети

ff02 : : 2

224 . 0 . 0 . 2

Неназначенные

f f02 : : 3

224 . 0 . 0 . 3

Маршрутизаторы DVM RP

ff02 : : 4

224 . 0 . 0 . 4

f f02 : : 5

224 . 0 . 0 . 5

Маршрутизаторы OSPF Маршрутизаторы OSPF DR

f f02 : : 6

224 . 0 . 0 . 6

Маршрутизаторы RIP

f f0 2 : : 9

224 . 0 . 0 . 9

Маршрутизаторы EIGRP

f f02 : : 1 0

224 . 0 . 0 . 10

1 5.5. ВЫБОР КРИТЕРИЕВ СТРАТЕГИИ МАРШРУТИЗАЦИИ Существует четыре уровня сложности, характеризующих процесс управления мар ш рутизацией в сети: •

отсутствие маршрутизации как таковой;

только статическая маршрутизация;

п р е и м уществе н н о статическая мар ш рутизаци я , но кли енты п р и н имают RI Р­ обновления; динамическая маршрутизация.

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

Автономная сеть не нуждается в маршрутизации. Если из сети есть только оди н выход во внешний мир, клиенты сети (нешл юзовые хосты) должн ы иметь стандартный статический маршрут к этому шлюзу. Ни какой другой конфигурации не требуется , кроме как на самом шлюзе. Можно задать явный статический маршрут к шлюзу, ведущему в небольшую груп­ пу сете й , и стандартн ы й маршрут к шлюзу, ведущему во в не ш н и й м и р . Однако динамическая маршрутизация предпочтительнее , если до нужной сети можно до­ браться разн ы м и маршрутами. Если сети пересекают государствен н ые или адми нистративные границы , следует испол ьзовать динамическую маршрутизацию, даже если сложность сетей этого не требует. П ротокол R I P отл и ч н о работает и ш ироко испол ьзуется . Н е отказы вайтесь от него просто потому, что он и меет репутацию устаревшего протокола. П роблема протокола R I P заключается в том , что его невозможно масштабировать до бесконечности . Расширен ие сети рано или поздно приведет к отказу от него. Из-за этого протокол RIP считается промежуточ н ы м протоколом с узкой обла­ стью применения. Эта область ограничена с одной сторон ы сетя м и , которые яв­ ляются сл и ш ком простым и , чтобы примен ять в н их какой-либо протокол мар ш ­ рутизации , а с другой сторон ы — сетя м и , которые являются сл и ш ком сложны м и

Часть 11. Работа в сетях

51 0

для протокола RI Р. Если вы планируете расширять свою сеть, то было бы целесоо­ бразно игнорировать протокол R I P вообще. •

Даже если протокол R I P не соответствует вашей стратегии глобал ьной маршру­ тизации , он остается хоро ш и м способом распределения маршрутов к кон цевым хостам . Однако его не следует применять без особой надобности : систе м ы в сети, и ме ющей только оди н шлюз, н и когда не требуют динам ического обновления. П ротоколы E I G R P и OSPF имеют одинаковые функционал ьные возможности , но протокол E I G R P является собствен ностью ком пан и и Cisco. Ком пания Сisсо дела­ ет прекрасные и оптимал ьн ые по соотношению » цена — качество» маршрутизато­ р ы ; тем не менее стандартизация протокола EIG RP ограничивает ваши возмшк­ ности будущего расширения . Маршрутизаторы , подкл юченные к магистрали И нтернета, должны использовать протокол BG P. Обычно больши нство маршрутизаторов имеет только один вход и , следовательно, дл я н их достаточно задать простой статический стандартный маршрут. E I G RP и O S P F примерно одинаково фун кционал ь н ы , но E I G R P я вляется соб­ ствен н остью Cisco. Cisco делает превосходные и кон куре нтоспособн ы е по стои­ мости маршрутизаторы ; те м н е менее стандартизация E I G R P ограничивает ваш выбор для будущего рас ширения . Маршрутизаторы , подключе н н ые к И нтернету через нескол ько провайдеров вос­ ходя щего потока, должны ис пол ьзовать протокол B G P. Одн а ко бол ь ш и нство маршрутизаторов имеют только один восходящий путь и поэтому могут использо­ вать простой статический маршрут по умолчанию.

Хорош е й стратегией по умолчан и ю для орган изации среднего размера с относитель­ но стабильной локал ьной структурой и подключе н и е м к чужой сети является исполь­ зование комбинации статической и динами ческой маршрутизаци и . Маршрутизаторы в локальной структуре, которые не приводят к внеш н и м сетя м , могут использовать ста­ тическую маршрутизацию, пересылку всех неизвестн ых пакетов на машину по умолча­ нию, которая пон имает внешн и й мир и вы полняет динамическую маршрутизацию. Сеть, которая сли ш ком сложна для управления с помощью этой схе м ы , должна опи­ раться на динам ическую маршрутизацию. Статические маршруты по умолчан ию все е ще можно испол ьзовать в сетях, состоя щих из л истьев, но маш и н ы в сетях с нескол ь­ кими маршрутизатора м и должны запускаться маршрутизирова н н ы м или другим R I Р­ прие м н и ком в пассивном режиме.

1 5.6. ДЕМОНЫ МАРШРУТИЗАЦИИ М ы не рекомендуем использовать систем ы U N IX и Linux в качестве маршрутизато­ ров в производственных сетях. Специал изированные маршрутизаторы проще, надежнее, безопаснее и более быстродействующие (даже если они с крытно запускают ядро систе ­ мы Linux) . И наче говоря , очень хорошо иметь возможность организовать новую подсеть, используя всего лишь сетевую карту стоимостью 1 5 долл. и коммутатор за 40 долл . Это вполне разумный подход к организации разреже н н ых, тестовых и вспомогательных сетей. С исте м ы , действующие ка к шлюзы в так и х подсетях , н е требуют допол н ител ь­ н ых и нструм е нтов для управл е н и я их собстве н н ы м и табл и ца м и маршрутиза ц и и . Статические маршруты впол н е адекватны как для м аш и н , испол ьзуе м ы х в качестве шлюзов, так и для маш и н , представля ющих собой хосты самой подсети. Однако если

Глава 1 5 . IР-маршрутизация

51 1

вы хотите , чтобы ваша подсеть была доступной для других сетей в ваше й организации, вам необходимо сообщить о ее существова н и и и идентифицировать марш рутизатор , к которому будут привязаны пакеты, посылаем ы е дан ной подсетью. Обычно для этого на шлюзе запускается демон маршрутизации. Систем ы U N IX и Linux могут участвовать в большинстве п ротоколов маршрутизации с помощью различных демонов маршрутизаци и . Важ н ы м и с кл юче н и е м из этого пр ави ла является протокол E I G R P, которы й , наскол ько нам и звестно, не и м еет ш ироко до­ ступной реал изации в системах U N IX и Linux. Поскольку демон ы маршрутизаци и редко реализуются в производстве н н ы х систе­ мах, мы н е будем подробно описывать их использование и конфигурацию. Тем не менее в следующих разделах м ы приведем краткое описание типич н ых програм м и укаже м , где искать детали конфигурации . ­

Демон routed: уста ревшая реа л изаци я в протоколе RIP Долгое время демон routed был стандартным демоном маршрутизации, и его до сих пор включают в дистрибутивы н екоторых с исте м . Демон routed п о н и м ает только п ро­ токол R I P и при этом плохо: даже поддержка верси и R I Pv2 н е поправила с итуацию. Демон routed н е понимает протокол R I Png, реализация которого основана н а совре­ менн ых демонах, таких как Quagga и ramd в системе H P — UX. Демон routed целесообразн о ис пользовать в пасс и вном режим е ( -q) , в котором он п р и н и м ает сообщ е н и я об обновл е н иях маршрутов, но не осуществляет ш ироко­ вещател ьную расс ылку собствен н ых сообщен и й . Кроме указания оп ций в командной строке , демон routed не требует конфигурирования. О н представляет собой дешевый и простой с пособ получе н ия сообще н и й об обновлениях маршрутов без сложного кон ­ фигурировани я . Демон заносит обн аруже н н ы е маршруты в табл и цу ядра . Все маршруты долж­ н ы анонсироватьс я , как м и н и мум каждые четыре м и нуты , и наче они б удут удал е н ы . Правда , демон route пом н ит, какие маршруты он добавлял , и не удаляет статические маршруты , заданные с помощью команды route.

W С м . способы ручного управления табл ицами мар ш рути за ции

в

разделе 1 3 .5.

П акет Quagga : основной демон маршрут изаци и Quagga (qu a g g a . n e t ) это опытно- конструкторс кое подразделе н ие проекта Zebra, выполняемого в рам ках проекта G N U . Проект Zebra был запущен Кун ихиро И ш и гуро ( Kunihiro Ishiguro) и Й ошинари Й ошикава (Yoshinari Yoshikawa) для реализации много­ протокольной маршрутизации с помощью коллекции независимых демонов, а не одного монол итного приложения. В реальной жизни квагга (quagga) — это исчезнувший подвид зебры, которая была последний раз сфотографирована в 1 870 году. Но его цифровая ре­ инкарнация Quagga выжила, а проект Zebra закрылся . В настоящее время пакет Quagga реализует все протокол ы RI P ( все в е р с и и ) O S P F (верси и 2 и 3) и BG P. Он выпол н яется в системах Linux, Fre e B S D и разных вариантах систем ы B S D . В системе Solaris и версиях систе м ы Li nux , имеющихся в нашем распо­ ряже н и и , пакет Quagga л и бо и нсталлирован по умол ч а н и ю , л ибо доступен в качестве вспомогательного пакета, которы й можно загрузить из стандартного с исте м ного репо­ зитория программ ного обеспечен и я . В пакете Quagga демон zebra и грает роль информационного центра для маршрути­ зации . О н управляет взаимодействием между табл ице й марш рутиза ц и и ядра и демона-

,

Часть 11. Работа в сетях

51 2

м и , соответствующими отдельным протоколам маршрутизации (ripd, ripngd, ospfd, ospfбd и Ьgpd). Кроме того, он управляет потоками и нформации о маршрутах, которы ­ м и обмен иваются протокол ы . Кажды й демон имеет свой собствен н ы й конфигурацион ­ н ы й файл в каталоге /etc/’J)J.agga. Для того чтобы послать запрос или измен ить конфигурацию, можно соеди н иться с любым из демонов Quagga с помощью и нтерфейса командной строки (vtysh в систе­ ме Linux и ‘J)J.aggaadm в системе Solaris) . Командный язык разработан так , чтобы он был понятен пол ьзователя м операцион ной с истем ы I O S ком пании Cisco; допол нительные детали можно найти в разделе , посвященном маршрутизаторам Cisco. Как и в системе IOS, для того чтобы войти в режим «суперпользовател я » , необходимо выпол н ить коман­ ду еnаЫе, дл я того чтобы ввести команды конфигурирования , необходимо выполнить команду config term, а дл я того чтобы сохран ить изменения конфигурации в файле конфигурации демона, необходимо выполн ить команду wri te. Официальная документация доступн а на сайте qua g g a . n e t в виде файлов в форма­ тах HTM L и PDF. Несмотря на свою полноту, эта докуме нтация содержит, в основном , удобн ы й каталог опций , а не общи й обзор систе м ы . Более практичную докуме нтацию можно н айти на сайте w i k i . q u a g g a . n e t . Здесь находятся подробно прокомме нтиро­ ванные примеры файлов конфигурации, ответы на часто задаваемые вопросы и советы . Несмотря на то что файлы конфигурации имеют простой формат, необходимо знать протокол , конфигурацию которого вы настраиваете , а также пон и мать, что означают те или и н ы е опции. С писок рекомендованной литературы по этому вопросу приведе н в конце главы.

М а ршрутизатор XORP Проект XORP (eXtensiЫe Open Router Platform расширяемая платформа маршрути­ зации с открытым кодом ) бьm открыт примерно в то же вре м я , что и проект Zebra, но его цели бьmи более универсальными. Вместо маршрутизаци и проект XORP бьm нацелен на эмулирование всех функций задан ного маршрутизатора, включая фильтрацию пакетов и управление трафиком . И нформация об этом проекте хранится на сайте x o r p . o r g . И нтерес н ы й аспект платформ ы XOR P заключается в том , что она н е только фун к­ ционирует в раз н ых операцио н н ы х системах ( Linux, разных версиях B S D , Мае OS Х и Wi n dows Seiver 2003 ) , но и может запускаться н епосредстве н но с «живого » компакт­ диска (т. е . н епосредстве н н о с ком пакт-диска, без инсталля ции на жестк и й диск. Примеч. ред. ) н а персональном комп ьютере. Этот «живо й » ком пакт-диск ( live C D) скрытно основан на системе Linux, но он прошел долгую эвол юцию и позволяет превра­ щать типич н ы й персональный ком пьютер в специализированн ое устройство для марш­ рутизации. —

1 5.7. МАРШРУТИЗАТОРЫ C1sco Маршрутизатор ы , вы пускаем ы е компанией Cisco Systems, I nc . , се годня я вля ются стандартом де-факто -на р ы н ке и нтернет-маршрутизаторов. Захватив более 60% рынка, ком пан ия Cisco добилась ш ирокой известности своих продуктов, к тому же есть м ного специалистов, умеющих работать с этим и устройствами . Раньше в качестве маршрути­ заторов часто приходилось испол ьзовать U N IХ-систе м ы с несколькими сете в ы м и и н ­ терфейсам и . Сегодня специализирован ные маршрутизаторы размещены в ком мутаци­ онн ых ш кафах и над подвесн ы м и потолками , где сходятся сетевые кабели.

Глава 1 5. IР-маршрутизация

51 3

Большинство маршрутизаторов Cisco работает под управлением операционной систе­ мы Cisco IOS , которая я вляется собственностью ком пании и не и меет отношения к си­ стеме U N IX. У нее достаточно большой набор команд: полная бумажная документация занимает на полке почти полтора метра. Мы н икогда н е смогл и бы полностью описать здесь эту операционную систему, но все же постараемся дать о ней основные сведения. П о умолчанию в системе IOS определе н ы два уровня доступа (пол ьзовател ьск и й и привилегированный) , каждый из которых включает механизм парольной защиты . Чтобы войти в пользовательский режим можно воспол ьзоваться s sh. Вы получите приглаше н ие на ввод пароля. $ ssh acme-gw . acme . com Pas sword :

После ввода правильного пароля появится приглашение и нтерпретатора ЕХЕС. acme -gw . a cme . c om>

С этого момента можно нач и нать вводить команд ы , например show interface s для отображен и я списка сетевых и нтерфейсов мар шрутизатора или show ? для получе ­ ния справки по возможны м параметрам . Для того чтобы перейти в при вилегирова н н ы й режи м , введите команду еnаЫ е , а при последующем запросе — привилегирова н н ы й пароль. П ризнаком привилегиро­ ванного режима я вляется наличие символа » # » в конце строки приглашения. acme — gw . a cme . c om#

Будьте осторожн ы! В данном режиме можно делать все что угодно, включая удаление конфигурационной информации и даже самой операционной с исте м ы . Если сомневае­ тесь, обратитесь к справочным руководствам по системе Cisco или одной из исчерпыва­ ющих кни г, выпускаемых издательством Cisco Press. Команда show running позволяет узнать текущие динамические параметры м арш­ рутизатора , а по команде show config отображаются текущие неизменяемые парамет­ ры. В большинстве случаев оба набора дан н ых иденти ч н ы . Типичная конфигурация вы­ глядит следующим образом . acme — gw . a cme . c om# show running C u r r e n t c on f i gu r a t i on : ve r s i o n 1 2 . 4 hos t name a cme — gw еnаЫе s e c r e t х х х х х х х х i p s u b n e t — z e ro i n t e r f a c e E t h e rne t O de s c r ip t i on Acme i n t e r n a l n e t wo r k i p a dd r e s s 1 9 2 . 1 0 8 . 2 1 . 2 5 4 2 5 5 . 2 5 5 . 2 5 5 . О n o i p di r e c t e d — b r o a dc a s t i n t e r f a c e E t h e rne t l de s c r i p t i o n Acme b a c kbone n e t wo r k i p addre s s 1 9 2 . 2 2 5 . 3 3 . 2 5 4 2 5 5 . 2 5 5 . 2 5 5 . 0 n o i p di r e c t e d — b r o a dc a s t ip c l a s s l e s s line c o n О t ra n s p o r t input none l i ne aux О t r a n s p o r t input t e l n e t line vty О 4 pas sword хххххххх

Часть 11. Работа в сетях

514

login end

М оди ф и ц и р о вать конфи гураци ю м а р ш р утизатора м о ж н о раз н ы м и с п особам и . Ком па н и я Cisco предлагает графические утилиты , работающие в н е котор ы х верс и я х LJ N JX/Linux и Windows, но о п ы т н ы е сетевые адм и н истраторы н и ко гда и м и н е пользу­ ются . Их самы й м о щ н ы й » инструм е нт» — командная строка. Кром е того, с помощью команды s cp можно загрузить с маршрутизатора е го конфигурацио н н ы й файл и отре­ дакти ровать в л юби мом текстовом редакторе , после чего с нова записать файл в память маршрутизатора. Для того чтобы отредактировать конфи гурацион н ы й файл в режи м е ком а ндной строки, введите команду config term. acme — gw . a cme . c om# config term E п t. e r c o n f i g u r a t i o п c ommands , o n e p e r l i n e . End wi t h CNT L / Z . acme — gw ( co n f i g ) #

Теперь можно вводить конфигурационн ы е команды в том виде , в котором их будет отображать кома нда show running. Например, есл и требуется изменить I Р-адрес и н ­ терфейса E t h e r n e t O , введите следующее . i п t e r f a c e E t h e r пe t O i p addre s s 1 9 2 . 2 2 5 . 4 0 . 2 5 3 2 5 5 . 2 5 5 . 2 5 5 . О

П о окончани и в вода конфигурационн ы х команд нажмите < Ct rl + Z > , чтобы вернуть­ сн к обычной командной строке . Если все прошло успешно, сохраните новую конфигу­ ра цию в постоянной памяти посредством команды wri te mem. П р и ведем несколько советов, касающихся эффективной работы с маршрутизаторам и Cisco. •

Присвойте маршрутизатору и м я с помощью команды hostname . Это позволит из­ бежать несчастны х случаев, связанных с изменением конфигурации не того мар ш ­ рутизатора. Заданное и м я всегда будет отображаться в командной строке . Всегда храните резервную копи ю конфигурацион ного файла марш рутизатора. С помощью команд scp или tftp можно каждую ночь пересылать текущую конфи­ гурацию в другую систему на хранение. Зачастую сушествует возможность хран ить копию конфигурации в энергонезависи­ мой памяти NVRAM или на переносном флеш-накопителе. Не пренебрегайте этим! Сконфигурировав маршрутизатор для S S Н -доступа, откл юч ите протокол Tel net совсем . Контрол и руйте доступ к командной строке маршрутизатора , создавая списки до­ ступа для каждого порта УТУ (аналоги ч е н порту РТУ в U N IХ-системе). Это не по­ зволит посторо н н и м пользователя м » взломать» маршрутизатор. Управля йте трафиком между сетя м и (по возможности , и во внеш н и й мир тоже), создавая сп иски доступа для каждого и нтерфейса. Более подробная и нформация приведен а в разделе 22. 1 1 . Физически огран и ч и вайте доступ к маршрутизаторам . Ведь если у злоум ышлен­ н и ка будет физический доступ к устройству, он л егко сможет измен ить п ароль привилегированного режима.

Если у вас нес кол ько маршрутизаторов и н е с колько с отрудн и ко в , отвечающих за их работу, воспользуйтесь утилитой RAN C I D , которую можно загрузить с сайта s h r u b e r r y . n e t . Н азвание RANC I D ( и гра слов: rancid негодный. — Примеч. ред. ) го-

Глава 1 5. IР-маршрутизация

51 5

ворит само за себя , но у этой программ ы есть одно преимущество: она регистрируется на ваших маршрутизаторах каждую ноч ь и получает их файлы конфигурации. Затем она сравнивает эти файлы и сообщает вам об их изменен иях. Кроме того, она автоматиче­ ски передает файлы конфигурации системе контроля версий (см . раздел 7 . 8 ) .

1 5 .8. Л ИТЕРАТУРА •

PERLMAN Rло1л. Interconnections: Bridges, Routers, Switches, and lnterworking Protocols (2nd Edition) . Readiпg, МА: Addisoп-Wiley, 2000. Это вьщающаяся книга в данной

области . Если в ы реш ил и купить тол ько одн у к н и гу об основах работы в сетях, покупайте ее. Кроме того, не упус кайте шанса » зависнуть» с Радией — она оче н ь веселая и обладает удивительно обширн ы м и знаниями. •

EDG EWORT H , B RAD, AлRoN Foss, AND Rлм 1 Rо G лRZA Rюs. / Р Routing оп Cisco /OS, IOS ХЕ, and IOS XR: Ап Essential Guide to Understanding and Implementing /Р Routing Protocols. l пdiaпapolis, I N : Cisco Press, 20 1 4.

Н u пЕмл CнRISТIAN. Routing in the lnternet, Second Edition. Pre пt ice Hall , 2000. Эта книга представляет собой отл ич ное введение в маршрутизацию для нач инающих. В ней описано большинство используемых сегодня протоколов маршрутизаци и , а также рассматри вается ряд сложных тем , например групповое вещание.

Существует м ного документов RFC, посвященных маршрутизаци и . Основные из них перечислены в табл. 1 5 . 3 . Таблица 1 5 . З . Документы RFC, посвищенные маршрутизации RFC

Название

Авто р ы

1 256

ICMP Router Discovery Messages

Deering

1 724

RIP Version 2 MIB Extension

Malkin, Baker

2080

Rlng for 1 Pv6

Malkin, Minnear

2328

OSPF Version 2

М оу

2453

RIP Version 2

Malkin

427 1

А

Rekhter, Li , et al.

4552

Authentication/Confidentiality for OSPFv3

Gupta, Melam

4822

R I Pv2 Cryprographic Authentication

Arki nson, Fanto

486 1

Neighbor Discovery for 1 Pv6

Narten et al.

5 1 75

I Pvб Router Advertisement Flags Option

Haberman, Hinden

5308

Routing 1 Pv6 with IS-IS

Hopps

5340

OSPF for I Pvб

Coltun et al.

5643

Management l nformation Base for OSFv3

Joyal, NManral, et al.

Border Gateway Protocol 4 (BGP-4)

глава

16

DNS: система доменных имен

И нтернет обеспечивает мгнове н н ы й доступ к ресурсам по всему м иру, и каждый из этих ком п ьютеров или сайтов и м еет ун и кал ьное имя (например, g o o g l e . com). Те м не менее л юбой , кто пытался найти друга ил и потерянного ребен ка на переполненном ста­ дионе , знает, что мало просто знать имя и его вы кри кивать. Существе н н ы м фактором для поиска чего-л ибо ( ил и кого-либо) я вляется организован ная систе ма передач и , об­ новления и распространения имен и их местоположен и й . П ол ьзовател и и програм м ы на уровне пол ьзователя л юбят ссылаться на ресурс ы по имени (например, ama z o n . c om), но сетевое программ ное обеспечение н изкого уров­ ня пон имает только I Р-адреса (например, 54.239 . 1 7 .6). Сопоставл е н ие имен и адресов является самой известной и, возможно, самой важной фун кцией D N S , систе м ы домен­ н ых имен. D N S вкл ючает в себя другие элементы и фун кции , но почти без исключения все они существуют для поддержки этой ос новной цел и . На протяжении всей истории И нтернета система DNS вызывала как восхищение, так и критику. Ее первоначальная элегантность и простота способствовал и ус пеху в первые годы и позволили И нтернету быстро расти под небол ьшим централизован ным управлением. По мере роста потребностей в дополн ител ьных функциональных возможностях систе ма DNS стала нуждаться в усовершенствовании. И ногда эти фун кции добавлялись с пособом, ко­ торый сегодня выглядит уродливым. Скептики указывают на недостатки инфраструктуры DNS в качестве доказательства того, что Интернет находится на грани краха. Однако, что ни говори , основные кон цепции и протокол ы D N S до сих пор выдержи ­ вали рост от нескол ьких сотен хостов в одной стране до всемирной сет и , которая под-

Часть 11. Работа в сетях

51 8

держи вает более трех м иллиардов пол ьзователей на более чем одном м иллиарде ком­ п ьютеров. ‘ Примеров и н формацион ной с исте м ы , которая выросла до этого масштаба с таким количеством вопросов, бол ьше нет. Без D N S И нтернет давно бы провал ился .

1 6. 1 . АРХИТЕКТУРА D N S С истема D N S — это распределенная база дан ных. В рам ках этой модел и оди н сервер хра н ит дан н ы е для комп ьютеров, о которы х он знает, а другой сервер хранит дан н ые для с воего собствен ного набора комп ьютеров, при этом серверы взаимодействуют и об­ мени ваются данн ы м и , когда одному серверу н еобходимо найти данные на другом серве­ ре. С адми нистративной точки зрения DN S-cepвepы , которые вы настроил и для своего домена, отвечают на внешн ие запросы об именах в ваш е м домене и в свою очередь за­ праши вают серверы других доменов от и мен и ваш их пользователе й .

З а п росы и ответы DN S-зaпpoc состоит из имени и типа зап иси. Возвращаемый ответ — это набор «запи­ сей о ресурсах» (resource records — R R) , которые реаmруют на запрос (или, альтернативно, на ответ, указывающий, что имя и тип записи, которые вы запрашивали, не существуют). » Реаrирует» не обязательно означает «знает» . D N S-cepвepы образуют иерархию, и для ответа н а конкретный запрос может потребоваться связь с серверами на несколь­ ких уровнях (см. раздел 1 6.4) .2 Серверы, не знающие ответа на запрос , возвращают за­ писи ресурсов , которые могут помочь клиенту найти сервер, знающий ответ. Наиболее распростране н н ы й запрос — это запрос записи А, которая возвращает I Р­ адрес , связа н н ый с именем. На рис. 1 6. l показан типичный с ценарий.

“Переместите меня на сайт facebook.com.”

“Найти систему, в которой находится сайт facebook.com.”

“Какая запись A у сайта facebook.com?”

“Запись A у сайта facebook.com — 31.13.73.36.”

gethostbyname( ”facebook.com”)

Человек

Web-браузер

Системная библиотека и механизм преобразования имен

Сервер имен

Рис. 16. 1. Простой поиск имени

Во-первых, человек вводит имя желаемого сайта в веб-браузер . Затем браузер вызы­ вает библиотеку DNS Resolver для поиска соответствующего адреса. Библ иотека Resolver создает запрос на запись А и отправляет ее на сервер и м е н , которы й возвращает запись А в своем ответе. Наконец, браузер открывает ТСР-соединение с целевым хостом через I Р-адрес , возвращаем ы й сервером имен . ‘ Статистика относительно пол ьзователей взята с сайта i n terne t l i ve s t a t s . com/ interne t ­ u s e r s , а статисти ка по хостам — на сайте s tatista . com. 2Серверы и ме н обычно п олуч ают зап росы на порт 53 U D P.

Глава 1 6. DNS: система доменных имен

51 9

П оставщики услуг DNS Несколько лет назад одной из основных задач каждого с исте м ного адм и н истратора было создани е и обслуживан ие DNS-cepвepa. Сегодня с итуация измен илась. Есл и ор га­ н изация вообще поддерживает DNS-cepвep, он часто испол ьзуется тол ько для внутре н ­ него испол ьзования. 3 Каждой орган и за ц и и по-прежнему нужен внеш н и й DN S-cepвep, но те перь для ис­ пользования этой фун кции ис пол ьзуется оди н из м ногих ком м ерческих «управляем ых» поставщиков D N S . Эrи службы предлагают и нтерфе йс управлен ия графически м интер­ фейсом и высокодоступную, защище нную D N S — и н фраструктуру за очень небольшую плату в де нь. Amazon Route 5 3 , Cloud Flare , Go Daddy, D N S Made Easy и Rackspace это лишь некоторые из основных поставщи ков. Конечно, вы можете настроить и сохран ить свой собстве н н ы й DNS-cepвep (внутрен ­ ний ил и внеш н и й ) , если хотите . У вас есть десятки реали заци й D N S на выбор, но с и ­ стема и нтернет- и м е н Berkeley I nternet N a m e Domain ( B I N D) по- прежнему дом и н и рует в Интернете . Более 75% DN S-cepвepoв я вля ются ее разновидностью.4 Независимо от того , какой путь вы выберете , в кач естве с исте м ного адм и н истрато­ ра вам необходимо понять основн ые концеп ц и и и архитектуру D N S . Первые н есколько разделов дан ной главы посвяще н ы эти м важн ым фундаментальным зна н и я м . Н ач и ная с раздела 1 6 . 8 , мы показываем не которые конкретные конфи гурации для B I N D. —

1 6.2. DN S для ПОИСКА Независ имо от того, запус каете л и вы свой собстве н н ы й сервер и м е н , пользуйтес ь управляе мой службо й D N S ил и кто-то предоставляет службу D N S дл я вас , вы обяза­ тельно захотите настроить все свои системы на поиск и м е н в DNS. Для этого необходимо пройти два этапа. Во-первых, следует настроить с во и с исте ­ мы как D N S — кл ие нты . Во- вторых, нужно сообщить с истемам , когда испол ьзовать D N S , а не другие методы поиска имен , такие как статический файл /etc/hosts.

resol v . conf: конфигурация кл иентского модуля распознавания Кажд ы й комп ьютер, подкл юче н н ы й к сети , должен быть кл ие н том с исте м ы D N S . Конфигурация клиентс кой части систе м ы D N S задается в файле /etc/resolv . conf, содержащем список D N S-cepвepoв, которы м можно посылать запросы . m Дополн ител ьную информацию о протоколе с м . в разделе 1 3 . 6 . Есл и ваш ко м п ьютер получает свой 1 Р-адрес и сете вые параметры от D Н С Р­ сервера, то файл /etc/ resolv . conf должен заполн яться автоматически. В противно:! случае его нужно редактировать вручн ую. Формат зап исей файла и м еет следующи й вид. s e a r c h имя_ домена . . . name s e rve r IР- адрес

1Система Active Directory M icrosoft вкл ючает и нтегрирова н н ы й D N S -cepвep, которы й прекрас­ но сочетается с други м и службам и , поддержи вае м ы ми M ic rosoft в корпорати вной среде . Одн ако Active Directory п одходит только для внутреннего ис пользовани я . Эта система н и когда не должна использоваться как внеш н и й DN S-cepвep, связан н ы й с И нтернетом, из-за поте нuиа.1ьных проб­ лем с безопасностью. •см . обзор /SC lnternet Domain Survey , опубл и кованный в июле 20 1 5 г.

Часть 11. Работа в сетях

520

Может быть указано от одного до трех серверов имен . Рассмотрим пример. s e a rc h a t r u s t . com b o o k l a b . a t r u s t . com n ame s e rv e r 6 3 . 1 7 3 . 1 8 9 . 1 ; nsl ; ns2 n ame s e rv e r 1 7 4 . 1 2 9 . 2 1 9 . 2 2 5

В строке s e a r c h приведе н с писок доменов, которые следует опраш и вать, если и м я ком п ьютера определено не полностью. Н апример, когда пользователь вводит команду s sh coraline, то распознаватель дополняет имя первым доменом в списке (в рассмот­ ренном выше примере — a t r u s t . с от ) , после чего и щет хост c o r a l i n e . a t r u s t . с о т . Если это и м я н е найдено, делается попытка найти хост c o r a l i ne . b o o k l a b . a t r u s t . с от. Количество доменов, которые можно задать в директиве s e a r c h , зависит от специ­ фики распознавателя ; большинство из них допускает от ш ести до восьми доменов, при этом предельное количество символов равно 256. Серверы и м е н , указанн ы е в файле resol v . conf, должны разре шать вашему ком ­ п ьютеру посылать запросы и обязаны давать на них пол н ые ответы (т.е . быть рекурси в­ н ы м и ) , а не отсылать вас на другие серверы имен (см. раздел 1 6.4). Серверы и мен опрашиваются по порядку. Если первый сервер отвечает на запрос , другие серверы игнорируются. Если возникает проблема, то по истечен и и времен и , от­ веден ного для ответа на запрос , он переадресуется следующему серверу. Все серверы опра ш иваются по очереди , до четырех раз каждый . С каждой неудаче й тайм-аут уве ­ л ич и вается . По умолчанию интервал тай м — аута задается равн ы м пяти секундам , что для нетерпеливых пользователей кажется веч ностью.

ns swi tch . conf’: кого я за п ра ш ива ю п о имен и ? Операцион н ы е систе м ы Free B S D и Linux испол ьзуют файл перекл юче ния / e t c / nsswi tch . conf для того, чтобы указать, как выпол няется отображен и е I Р-адреса в и м я ком п ьютера и в каком порядке следует испол ьзовать с истему D N S — первой , последней или вообще не использовать. Если файла перекл ючения нет, то по умолчани ю устанав­ л ивается следующее поведение. h o s t s : d n s [ ! U NAVAI L= r e t u r n ]

files

Раздел ! UNAVAI L означает, что если служба D N S доступна, н о и м я в н е й не найдено, следует прекратить попытки поиска и не продолжать просмотр следующей записи (в дан ­ ном случае файла /etc/hosts). Если сервер имен н е был запущен (это бывает во время загрузки с истемы), то процесс поиска рекомендуется согласовывать с файлом hosts . Во всех рассматриваем ы х нами дистрибутивах систем в файле n s swi tch . conf со­ держится следующая запись, определяющую поведение по умолчанию. h o s t s : f i l e s dns

Эта конфигурация дает приоритет файлу /etc/hosts, который всегда проверяется . Обращен и е к системе D N S п роисходит только для поиска и м е н , которые невозможно распознать с помощью файла /etc/hosts . Не существует » наилучш его» способа конфигурации поиска — все зависит от того, как управляется ваша сеть. В общем , мы предпочитаем хранить как можно больше инфор­ мации об хаете в системе D N S , но м ы также п ытаемся сохран ить возможность вернуться при необходимости назад к статическим файлам hosts в процессе загрузки системы. Если служба имени предоставляется вам внешней организацией, вы м ожете выпол ­ н ить настройку D N S после настройки файлов resolv . conf и ns swi tch . conf . В этом случае вы можете пропустить оставшуюся часть этой главы или п родолжать ч итать даль­ ше, чтобы узнать больш е .

Глава 1 6. DNS: система доменных имен

521

1 6.3. П РОСТРАНСТВО ИМЕН D N S П ространство имен D N S представляет собой дерево с двумя основ н ы м и ветвям и , со­ ответствующ и м и пря м ы м и обратн ы м преобразования м . Прямые преобразован и я ставят в соответствие и ме н ам ком пьютеров их I Р-адреса (и другие зап и с и ) , а обратн ые пре­ образован и я отображают 1 Р-адреса в и м е н а ком пьютеров. Каждое пол ностью опреде­ ленное и м я ком пьютера (например, n u b a r k . a t r u s t . c oт) — это узел дерева на ветви пря мых преобразова н ий , а каждый I Р-адрес — это узел дерева на ветви обратн ых преоб­ разований. Уровни дерева разделя ются точ ками ; корнем дерева я вляется точ ка.

Зоны обратного преобразования

Зоны прямого преобразования

. (root)

arpa in-addr …

61

62 …

189 …

63

173

1

org

com

net …

amazon www

atrust

www

de

nubark

au … …

… …

… Рис. 1 6. 2. Дерево DNS-зoн

Для того чтобы система D N S могла работать с дан н ы м и обоих видо в , ветвь I Р­ адресов в пространстве имен и н вертируется , т. е. октеты I Р-адресов записываются в об­ ратном порядке. Например, если хост » n uba r k . a t ru s t . с от . » имеет адрес 63. 1 73 . 1 89. 1 , то соответствующий узел на ветви прямых преобразований в дереве и м еет имя » n uba r k . а t r u s t . сот . » а узел на ветви обратных преобразова н и й и м еет и м я » 1 . 1 8 9 . 1 7 3 . 6 3 . i n — a d d r . a rpa . » 5 Оба эти и м е н и зака н ч и ваются точ кой , так же как пол н ые пути файлов все гда на­ ч инаются с косой черты . Это делает их » пол ностью квал ифицирован н ы м и дом е н н ы м и и менам и » , или FQ D N для краткости . Вне контекста с истем ы D N S и м е на, такие как n u ba r k . а t r u s t . сот (без конечной точ к и ) , и ногда называются » полностью квалифицирова н н ы м и и менами хостов» , но это жаргонизм. В самой системе D N S налич ие или отсутствие конечной точки имеет реша­ ющее значение. Существует два ти па доменов верхнего уровня: национальн ые дом е н ы верхнего уров­ н я (country code top-level domain — ccTLD) и общие дом е н ы верхнего уровня (generic top level domain — gT LD). Орган изация I CAN N ( lnternational Corporation for Assigned Names and N umbers) управляет проектом регистраци и имен в доменах gTL D , таких как с от, n e t и o r g , с помощью аккредитован ных агентств. Для регистраци и и ме н и в дом е н е ccTLD зайдите на веб-страницу орган изации IANA ( l nternet Assigned Numbers Authority) i a na . o r g / c c t l d и найдите реестр соответствующей страны. ,

‘· Часть имени i n — add r . a r p a п редставляет собой фи ксирова н н ы й суффи кс .

Часть 1 1 . Работа в сетях

522

Регистра ци я дом е нного имени Для того чтобы зарегистрировать домен второго уровня, необходимо подать зая вку в админ истрацию соответствующего домена верхнего уровня. Для того чтобы запол н ить бланки ре гистрации , необходимо назнач ить ответствен ного техничес кого специал иста и ответстве н н ого адм и н истратора, а также выбрать хотя бы два ком п ьютера, которые будут серверами домена. Кроме того, необходимо выбрать доме н ное и м я , н и ке м не за ­ нятое . Стоимость ре гистрации зависит от аге нтства, но в настоящее вре мя она относи­ тельно небол ьшая .

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

Выбор и м е н и , уникал ьного в пределах орган изаци и .

Назначение двух и л и бол ее ком пьютеров серверами нового домена.6

Согласование де йствий с администратором родительс кого домена.

П режде ч е м передавать пол номоч и я , адм и н истратор родительского дом ена должен убедиться в том , что серr�еры и м е н дочернего доме на с конфигурированы и работают правил ьно. В противном случае произойдет то , что назы вается некорректным делегиро­ ванием, и вы получите по электронной почте неприятное сообщен ие с требованием ис­ править ош ибку (см. раздел 1 7 . 1 5) .

1 6.4. КАК РАБОТАЕТ СИСТЕМА D N S Серверы имен по всему м иру работают вместе . чтобы отвечать н а запросы . Как пра­ вило, они расп ространяют информацию, поддерживае мую л юбым адм и н истратором , ближайш и м к цели запроса . Понимание ролей и взаи моотношен и й серверов имен важ­ но как для повседневных операци й , так и для отладки.

Серверы им е н Сервер имен в ыполняет несколько рутин н ы х операци й . • •

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

Серверы и м е н работают с зона м и , которые представляют собой домен без поддоме­ нов. Часто терм и н домен употребляется как синон и м термина зона, даже в этой книге . Серверы и м е н работают в нескольких разных режимах , поэтому дать и х точное опре­ деление нелегко. Ситуация усложняется еще и тем , что оди н и тот же сервер может вы­ пол нять неодинаковые функции о разных зонах. В табл . 1 6. l перечисл е н ы прилагател ь­ н ые , употребляемые при оп исан и и серверов имен. 6С тех н ической точки зре н и я , пос кол ьку вы сами устанавл и ваете правила для своего п оддомена. может быть оди н сервер или нес колько.

Глава 1 6. DNS: система доменных имен

523

Таблица 1 6 . 1 . Классификация серверов имен Тип сервера

Описание

Авторитетный (authoritative) главный ( master)

Официальный представитель зоны Основное хранилище данных зоны; берет информацию из дискового файла Синоним термина главный Копирует данные с главного сервера Синоним термина подчиненный Похож на подчиненный сервер, но копирует данные только о серверах имен (записи NS) Сервер, доступный только в пределах домена (также называется

первичный (primary) подчиненный (slave) вторичный (secoпdary) тупиковый (stub) внутренний ( distributioп)

невидимым сервером )

Неавторитетный • (пoпauthoritative) Отвечает на запросы, пользуясь данными из кеша; не «знает» , являются ли эти данные корректными кеширующий (cachiпg) Кеширует данные, полученные от предыдущих запросов; обычно не имеет локальных зон переадресующий (forwarder) Выполняет запросы от имени многих клиентов; формирует большой кеш Рекурсивный (recursive) Осуществляет запросы от имени клиента до тех пор, пока не будет най­ ден ответ Нерекурсивный (пoпrecursive)

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

• строго говоря, атрибут «неавторитетный» относится к ответу на DNS-зaпpoc, а не к самому серверу.

Серверы имен систематизируются на основании источн ика данн ы х (авторитетны й , кеширую щ и й , главны й , подчиненн ы й ) , типа храни м ых данных (усечен н ы й ) , пути рас­ пространения запроса (переадресующи й ) , типа выдаваемого ответа (рекурсивн ы й , не­ рекурсивный) и , наконец, доступности сервера (внутре нн ий ) . В следующих подразделах конкретизируются наиболее важн ые из этих различ и й ; об остал ьных различиях пойдет речь в других разделах главы.

А вторитетн ые и кеширу ющие серверы Главны й , подч и н е н н ы й и кеширующий серверы различаются только двумя харак­ теристикам и : откуда поступают дан н ые и авторитетен л и сервер дл я домена. В каждой зоне есть один главны й сервер имен.7 Н а нем хранится официальная копия дан н ых зон ы (в файле на диске). Систе м н ы й администратор модифицирует информацию, касающую­ ся зоны , редактируя файлы главного сервера. Подч и н е н н ы й сервер копирует свои данные с главного сервера посредством опера­ ции, называемой передачей зоны (zone t гansfer) . В зоне должен быть как м ин имум оди н подчиненный сервер. Тупиковый сервер — особый вид подчиненного сервера, загружа­ ющий с главного сервера только записи N S (описания серверов и м е н ) . Один и тот же ком п ьютер может быть главным сервером для одних зон и подчиненным — для других.

m Дополнительную и нформацию о передаче зоны см. в разделе в разделе 1 6.9. Кеш ирующий сервер имен загружает адреса серверов корн евого домена из конфи­ гурационного файла и накапливает остальн ые дан ные, кешируя ответы на выдаваем ы е 7 Н е которы е органи зации испол ьзуют н е сколько главн ы х с е рве ров или вооб щ е обходятс я бе з них ; м ы описывае м вариант, в котором суще ствует оди н главный с е рве р.

Часть 11. Работа в сетях

524

им запросы . Собствен н ых дан ных у кеширующего сервера нет, и он не я вляется автори­ тетным н и мя одной зоны (за искл ючением , возможно, зоны локального ком пьютера) . Гарантируется, что авторитетны й ответ сервера имен является точ н ы м ; неавторитет­ н ы й ответ может быть устаревш и м . Тем не менее очень м ногие неавторитетные ответы оказываются совершенно корректн ы м и . Главные и подчиненные серверы авторитетн ы м я своих зон , н о не м я кеш ирован ной информации о других доме нах. П о правде го­ воря, даже авторитетные ответы могут быть неточ н ы м и , если систе м н ы й адми н истратор изменил данные главного сервера (например, обновил порядковый номер зоны) и забыл передать их подч и н е н н ы м серверам. В каждой зоне должен быть хотя бы оди н подч и н е н н ы й сервер. В идеале подч инен­ н ых серверов имен должно быть м и нимум два, причем оди н из них — вне организации . Подчиненные серверы на м естах должны быть включены в разные сети и в разные цепи электроснабжения. Если служба имен вдруг перестанет фун кционировать, пользователи не с могут нормал ьно работать в сети.

Реку рсивные и нереку рсивные серверы Серверы и м е н бывают рекурсивны м и и нерекурсивн ы м и . Если у н ере курсивного сервера есть адрес, оставшийся в кеше от одного из предыдущих запросов, или он явля­ ется авторитетн ы м мя домена, к которому относится запрашиваемое имя , то он даст со­ ответствующий ответ. В противном случае он вернет отсылку на авторитетные серверы другого домена, которые с большей вероятностью ответят на запрос . Кл иенты нерекур­ сивного сервера должны быть готовы принимать отсылки и обрабаты вать их. У нерекурсивных серверов обычно есть веские причины не выполнять дополнительную работу. Например, все корневые серверы и серверы доменов верхнего уровня являются не­ рекурсивными, поскольку и м приходится обрабатывать десятки тысяч запросов в секунду. Рекурсивн ы й сервер возвращает только реал ьные ответы ил и сообщения об ошиб­ ках. Он сам отслеживает отсыл к и , освобождая от этой обязан ности клиента . Базовая процедура анализа запроса, по сути, остается неизменной . И з соображен и й безопасности , серверы имен организаци и , доступн ые извне, всегда должн ы быть нерекурсивн ы м и . Рекурсивные серверы и м е н , которые видны извн е , мо­ гут стать объектом мя атаки. Учтите , что библиоте ч н ы е фун к ц и и распознаван ия и м е н не понимают отсылок. Л юбой локальны й сервер имен , указанн ы й в файле resolv . conf клиента, должен быть рекурсивным.

З а п иси о ресу рсах Каждая организация поддерживает оди н или несколько фрагментов распределенной базы данных, лежащей в основе всемирной системы DNS. Ваш фрагмент дан н ых состоит из текстовых файлов, содержащих записи о каждом компьютере вашей сети; эти записи на­ зываются «записями о ресурсах» . Каждая запись представляет собой отдельную строку, со­ стоящую из имени (обычно имени компьютера) , типа записи и некоторых значений. Поле имени можно не указывать, если его значение совпадает с именем в предьщущей строке. Например, строки n ub a r k

IN IN

А МХ

63 . 17 3 . 1 8 9 . 1 1 0 ma i l s e r ve r . a t r u s t . com .

в файле » прямого преобразования» (с именем atrus t . com) и строка 1

IN

PTR nuba r k . a t r u s t . com .

Глава 1 6. DNS: система доменных имен

525

в файле «обратного преобразования» ( с именем 63 . 17 3 . 1 8 9 . rev) связывают сайт nuba r k . a t ru s t . сот с I Р-адресом 63. 1 73. 1 89. 1 . Запись М Х перенапрамяет сообщение электронной почты , адресованное на эту машину, на комп ьютер тa i l s e rve r . a t ru s t . сот. Поля IN обозначают классы записей. Н а практике , эти поля означают И нтернет. Записи о ресурсах — это универсальный язык системы D N S . О н и н е зависят от фай ­ лов конфигурации , управляющих операциями , которые выполняются на л юбой реал и ­ заци и дан ного сервера D N S . В с е они я вляются фрагментами данн ы х , циркул ирующих внутри систе м ы DNS, и кешируются в разных м естах.

Делегирование Все серверы и м е н сч итывают имена корневых серверов из локальных файлов кон­ фи гураци и или содержат их в своем коде . Корневые серверы » знают» о доменах сот, o r g , edu, f i , d e и других доменах верхне го уровн я . Эта цепоч ка продолжается даль­ ше: сервер домена edu » знает» о домене c o l o ra d o . edu, be r ke l y . e d u , сервер домена сот » знает» о домене a dт i n . с от и т.д. Каждая зона может делегировать пол номоч и я п о управлению своим и поддоменами другим сервера м . Рассмотрим реальный пример. П редположим , требуется узнать адрес хоста vangogh . c s . b e r k e l e y . e d u , н аходяс ь на хосте l a i r . c s . c o l o r a d o . e d u . Ком пьютер l a i r просит локал ь н ы й сервер и м е н , n s . c s . c o l o r a d o . e d u , найти ответ на этот вопрос. П оследующие события представлены на рис. 1 6 . 3 .

Нерекурсивный

Рекурсивный 2-Q START

lair

3-R 1-Q

ns.cs.colorado.edu

10-A 9-A

Q = Запрос A = Ответ R = Ссылка

8-Q

4-Q 5-R 6-Q 7-R

root (“.”) edu berkeley.edu

cs.berkeley.edu Рис. 16. З. Обработка запроса в DNS

Ч исла возле стрелок определяют порядок событий , а буквы — тип транзакци и (запрос, ссыл ка ил и ответ) . П редполагается , что н и какие из требуемых дан н ы х п редварительно не кешировал ись, за исключением имен и I Р-адресов серверов корневого домена. Локал ь н ы й сервер и м е н н е » знает» адреса ком пьютера v a n g o g h . Более того, ему ничего н е известно о доменах c s . be r ke l e y . edu, b e r ke l e y . edu и даже edu. Он » зна­ ет» лишь н е которые серверы корневого домена, запраш и вает корн е вой домен об хосте v a n g o g h . c s . be r ke l e y . edu и получает ссылку на серверы в домене edu. Л окал ь н ы й сервер и м е н я вляется ре курс и вн ы м . Если ответ на зап рос содержит ссыл ку на другой сервер , то локал ьн ы й сервер повторно направляет запрос новому сер­ веру. Он продолжает этот процесс , пока не найдет требуемый сервер. В нашем примере локальный сервер имен посылает запрос серверу домена edu ( как всегда, запраши вая ком пьютер vangogh . c s . be r ke l e y . edu ) и получает ссылку на неза-

Часть 11. Работа в сетях

526

висимые серверы домена b e r ke l e y . e d u . Затем локальный сервер повторяет запрос, на­ правляя его в домен b e r ke l e y . edu. Если сервер университета Беркли не содержит ответ в кеше, он вернет ссьmку на доме н c s . be r ke l e y . edu. Сервер этого домена ком петентен в отношен и и запрашиваемой информации и возвращает адрес ком пьютера vangogh. По окон ч а н и и процедуры в кеше сервера n s . c s . c o l o r a d o . edu окажется адрес комп ьютера va n g o g h . В кеше будут также находиться с писки серверов доменов e d u , be r ke l e y . e d u и c s . b e r ke l e y . edu. Детал и процедуры запроса можно выяснить с помощью утил ит dig + trace или dril l -Т.8

Ке w и рование и э ффективность Кеш ирование повышает эффективность поиска: кешированн ы й ответ выдается поч­ ти мгновен но и обычно точ е н , так как адресно-и м е н н ые соответствия меняются редко. Ответ хранится в теч е н ие периода време н и , называемого TTL (time to live ) , продолжи­ тельность которого задается владельцем искомой записи. Большинство зап росов каса­ ется локальных ком пьютеров и обслуживается быстро. Повышен ию эффективности не­ вольно содействуют и сами пользователи , так как м ногие запросы повторяются. Обычно записи о ресурсах вашей организации должн ы испол ьзовать период TT L , продолжительность которого, как правило, лежит в диапазоне о т одн ого часа д о одн ого дня. Чем дольше период TTL, тем меньше трафик сети, потребляе м ы й и нтерн ет-клиен­ тами , получающими свежие коп и и записи. Если у вас есть специальная служба, загрузка которой сбалансирована между логи ­ ческими подсетям и (этот п роцесс называется балансированием нагрузки глобального сер­ вера) , вы можете потребовать, чтобы поставщик услуг, выполняющий балансирование загрузки , выбрал более короткую продолжительность TTL , например десять секунд или одну минуту. ( Коротки й период TTL позволяет балансировщику загрузки б ыстро реа­ гировать н а бездействие серверов и атаки на основе отказа в обслуживан и и . ) Система с коротки м и периода м и TT L продолжает работать корректно, н о ваш и серверы и м е н должн ы работать в более интенсивном режиме. В примере, описанном выше, продолжительность периодов TTL бьmа установлена так: на корневых серверах 42 дня, в домене edu — два дня, в домене b e r ke l e y . edu два дня и один ден ь — для сайта vangoug h . c s . be r ke l e y . edu. Это разумные величины. Если вы планируете крупную перенумерацию, то можете сделать периоды TTL короче, чем раньше. Серверы DNS также реализуют негативное кеширование. Иначе говоря , они помнят, в каких ситуациях запрос остался без ответа, и не повторяют его , пока не истечет период TTL для негативного кешировани я . Ответы при негативном кеш ировании сохран яются в следующих с итуациях. —

Н ет хоста или домена, соответствующего запрашиваемому имени.

Дан ные запрашиваемого типа для дан ного хоста не существуют.

Запраши вае м ы й сервер н е отвечает.

Сервер недоступе н из-за проблем в сети.

Сервер B I N D кеширует данные в двух первых ситуациях, а сервер UnЬound во всех четырех. Коли ч ество повторен и й негативного кеширования можно задавать в любой ре­ ализаци и . —

кутилиты diq и drill — это инструменты си стемы D N S ; утилита diq входит в дисТРибути вный набор сервера B I N D , а утилита drill разработана груп пой N Lпet Labs.

Глава 1 6. DNS: система доменных имен

527

Н еоднозначные ответы и бала нсировк а заг рузки DNS Сервер имен в ответ н а запрос часто получает нес колько зап исей. Напр и м ер, п р и по­ пытке узнать адрес сервера имен корневого домена можно получить с писок, содержа­ щий все 1 3 корневых серверов. Больш инство сер в ер о в и м е н возвращает ответы в слу­ чайном порядке, выполняя примитивный вид баланс ировани я загрузк и . Можно достич ь балансирован ия загрузки своих серверов, закре п и в одн о и м я з а н е ­ скольким и I Р-адресами ( которые в реальности соотве тст ву ют разным ко м п ьютерам ) . www

IN IN IN

А А А

1 92 . 1 68 . 0 . 1 1 92 . 1 68 . 0 . 2 1 92 . 1 68 . 0 . З

Большинство серверов и м е н возвращают м ногор е кордные множества в другом по­ рядке каждый раз, когда они получают запрос , вращая и х в цикл ическом режиме. Когда клиент получает ответ с нескол ьк им и запися м и , наи более распространен ное п о веде н и е заключается в том , чтобы попробовать адреса в поряд ке возвращаемом DNS-cepвepoм.9 Эта схема обычно н азы вается балансированием нагрузки на основе циклического рас­ предел е н ия нагрузки. Однако в л учшем случае это грубое реше н ие . На бол ьш и х сайтах используется программное обеспечение балансирован ия нагрузки ( н апример , HAProxy, см. раздел 1 9 .6) или специализирован ные устройства балансирова н и я нагрузки. ,

Отл адка с п омощью и нстру ментов за п росов W Дополн ительную информацию о спецификациях DNSSEC с м . в

разделе

1 6 . 1 О.

П ять инструментов командной строки , которые зап раш ивают базу дан н ых DNS, рас­ простран я ются с помощью дистибутивов B I N D : nsl ookup , dig, host, dri l l и delv. Утил иты n s l ookup и ho s t просты и имеют н еплохую п роизводительность, но, чтобы получить все детал и , нуж н ы утилиты dig ил и dr i l l . Утил ита dri l l лучш е работает с цепоч кам и подписей D N S S EC. И м я команды dr i l l обыгрывает и м я dig (Domain lnformation Groper средство сбора информации о доменах } , подсказывая , что благода­ ря этой утилите можно получить еще больше информации от системы DNS, чем с помо­ щью утилиты dig. Утилита delv впервые появилась в си сте м е B I N D 9. 1 0 и в кон еч н ом итоге заме н ит утилиту drill для отладки D N S S EC. —

W Дополн ител ьную и нформаци ю о расщеплении DNS см . в

разделе 1 6. 7 .

По умолчанию утил иты dig и dri l l посылают за п росы серверам им е н, сконфигу­ рированн ым в файле /etc/re solv . conf. Аргумент @ с ерв ер_ име н адресует команду конкретному серверу име н . Способность посылать запросы кон кретному серверу по­ зволяет гарантировать, что любые изме н е н и я , внос и м ые в зон у, будут распростран е н ы среди подч и н е н н ых серверов и во внешнем м ире. Это свойство особенно полезно, есл и в ы испол ьзуете представления (расще пляете D N S ) и должн ы проверять, пр а в ил ь но л и он и сконфигурированы. Если указать тип записи, то команды dig и dri l l будут вы пол нять запрос только к эти м зап исям . Псевдотип any действует нем ного неожиданно: вместо того чтобы вер­ нуть все дан н ы е , ассоциированные с указа н н ы м имене м , он в озв ра ща ет все кеширован­ ные данн ы е , связан ные с н и м . Итак, чтобы получить все зап иси , необходимо выпол нить команду dig домен NS , за которой следует выраже н ие dig @ n s l . д омен . домен any. (Авторитетные дан ные в этом контексте рассматриваются ка к ке ш и рованны е ) .

90днако это поведен ие не я вляется обязательн ы м . Разные кл и е нты могут иести себя по-разному.

Часть 11. Работа в сетях

528

Утилита dig имеет более 50 опци й , а утилита dri l l около полови н ы этого коли­ чества. Получив флаг h , эти утилиты выдают список всех своих опци й . (Для того чтобы упорядочить вывод, можно передать его утилите les s . ) Для обеих утилит опция -х зме­ няет порядок следования байтов в I Р-адресе на противоположный и выполняет обрат­ н ы й запрос. Флаги +trace утилиты dig и -т утилиты dri l l показывают итеративные шаги в процессе распознавани я , начиная от корн я и вниз по дереву иерархии. Если ответ я вляется авторитетны м (т.е. приходит непосредственно от главного или подчиненного сервера дан ной зоны ) , то команды dig и drill во флагах вывода испол ь­ зуют символы а а . Код ad означает, что ответ является аутентичным в смысле протокола D N S S EC . Тестируя новую конфигурацию, следует убедиться , что вам доступн ы дан ные как локал ьных, так и удаленных хостов. Если вы имеете доступ к хосту только по его 1 Р­ адресу, а не по имени, то в это м , вероятно, виновата с истема DNS. Чаше всего утилита dig испол ьзуется дл я выяснения того, какие записи в настоя ­ щее вре м я возвращаются для определенного и м е н и . Если возвращается только ответ AUTHOR I T Y , значит, вы перенаправл е н ы на другой сервер и м е н . Если возвращается от­ вет ANSWER, значит, на ваш вопрос был дан ответ ( и , может быть, была включена другая информаци я ) . Часто бывает полезно следить з а цепоч кой делегирования вручную с корневых сер­ веров, чтобы убедиться , что все находится в правильных местах. Н иже мы рассмотри м при м ер этого процесса для названия www . v i a we s t . с от . Во- первых, м ы запрашиваем корневой сервер, чтобы узнать, кто я вляется авторитетным для сайта v i a w e s t . с от, за­ проси в начальную запись (start-of-authority S OA) . —

$ dig @ a . root-servers . ne t viawes t . com soa

; ; , , , , ,

< < > > D i G 9 . 8 . 3 — P l < < > > @ a . r o o t — s e rve r s . ne t v i a we s t . c oт s o a ( 1 s e rve r found ) , g l ob a l op t i on s : + стd , G o t a n s we r : , — > >HEADER< < — opcode : QUERY , s t a tu s : NOERRO R , i d : 7 8 2 4 , f l a g s : q r r d ; QUERY : 1 , AN SWE R : О , AUTHORI TY : 1 3 , ADD I T I ONAL : 1 4 , WARN I NG : r e cu r s i on r e que s t e d b u t n o t avai l aЫ e

, , QUES T I ON SECT I ON : ; vi a we s t . c oт . I N S OA ; ; AUTHORI T Y SECT I ON : 1 7 2 8 0 0 I N NS сот . 172800 IN NS с от . 1 7 2 8 0 0 I N NS сот . ; ; ADD I T I ONAL SECT I ON : c . g t l d — s e r ve r s . ne t . 1 7 2 8 0 0 b . g t l d- s e rve r s . ne t . 1 7 2 8 0 0 b . g t l d- s e rve r s . ne t . 1 7 2 8 0 0 a . g t l d- s e rve r s . ne t . 1 7 2 8 0 0

, , , ,

, , , ,

IN IN IN IN

c . g t l d- s e rve r s . ne t . b . g t l d — s e rve r s . ne t . a . g t l d — s e rve r s . ne t .

А 1 92 . 2 6 . 92 . 3 0 А 1 92 . 33 . 14 . 30 АААА 2 0 0 1 : 5 0 3 : 2 3 l d : : 2 : 3 0

А

1 92 . 5 . 6 . 30

Que r y t iтe : 6 2 тs е с S E RVE R : 1 9 8 . 4 1 . 0 . 4 # 5 3 ( 1 9 8 . 4 1 . 0 . 4 ) WHEN : W e d Feb 3 1 8 : 3 7 : 3 7 2 0 1 6 MSG S I Z E r cvd : 4 8 9

Обратите внимание на то, что возвращен ное состоян ие имеет значение NOERROR. Это говорит о том, что запрос возвратил ответ без заметны х ошибок. Другим и распростра-

Глава 1 6. DNS: система доменных имен

529

ненными значениями состояния являются NXDOMA I N , которое указывает, что запрошен­ ное имя н е суmествует (или не зарегистрировано) и SERV FA I L , которое обычно указыва­ ет на ошибку конфигурации на самом сервере имен. Этот раздел AUTHOR I T Y SECT I ON указывает, что глобальн ые серверы домена верхне­ го уровня (gTLD) я вляются следующим звеном в цепочке полномоч и й для этого домена. Итак, мы выбираем оди н случай н ы м образом и повторяем оди н и тот же запрос. $ dig @ c . gtld- servers . net viawes t . com soa ; < < > > D i G 9 . 8 . 3 — P l < < > > @ c . g t l d- s e rve r s . n e t v i a we s t . c orn s o a ; ( 1 s e rv e r found ) , , g l o b a l o p t i o n s : + crnd , , Got a n s we r : ‘ ‘ — > >HEADER< < — opcode : QUERY , s t a t u s : NOERROR , i d : 9 7 6 0 ‘ ‘ f l a g s : q r r d ; QUERY : 1 , ANSWER : О , AUTHORI T Y : 2 , ADD I T I ONAL : 2 , , WARN I N G : r e c u r s i on reque s t e d b u t n o t a va i l aЫ e , , QUE S T I ON S E CT I ON : ; vi awe s t . corn .

I N S OA

; ; AUTHOR I T Y S ECT I ON : viawe s t . c orn . 172800 IN NS viawe s t . corn . 1 7 2 8 0 0 I N NS

n s l . vi a we s t . ne t . n s 2 . v i awe s t . n e t .

; ; ADD I T I ONAL SECT I ON : 1 7 2 8 0 0 IN А n s l . vi a we s t . ne t . 1 7 2 8 0 0 IN А n s 2 . vi a we s t . n e t . , , Que r y t irne : 5 2 rns e c

2 16 . 87 . 64 . 12 209 . 170 . 21 6 . 2

, , S ERVER : 1 9 2 . 2 6 . 9 2 . 3 0 # 5 3 ( 1 9 2 . 2 6 . 9 2 . 3 0 ) , , WHEN : Wed Feb 3 1 8 : 4 0 : 4 8 2 0 1 6 ‘ ‘ MSG S I Z E rcvd : 1 0 8

Этот ответ намного более краткий , и теперь м ы знае м , что следующий сервер дл я за­ проса — n s l . v i a we s t . сот (ил и n s 2 . vi awes t . c om ) . $ dig @ ns l . viawes t . net viawest . com soa ; < < > > D i G 9 . 8 . 3 — P l < < > > @ n s 2 . vi a we s t . n e t v i awe s t . c orn s o a ; ( 1 s e rv e r f o und ) , , g l o b a l opt i on s : + crnd , , Got a n s we r : ‘ ‘ — > >HEADER< < — opcode : QUERY , s t a t u s : NOERROR , i d : 6 1 5 4 3 ‘ ‘ f l a g s : q r а а r d ; QUERY : 1 , ANS WE R : 1 , AUTHORI T Y : 1 , ADD I T I ONAL : 1 , , WARN I N G : r e c u r s i on reque s t e d b u t n o t a va i l aЫ e , , QUE S T I ON S E CT I ON : ; vi awe s t . c orn . I N SOA ; ; AN SWER S E CT I ON : viawe s t . c orn . 3600 I N S OA rnve c . vi awe s t . ne t . ho s trna s t e r . v i a we s t . ne t . 2 0 0 7 1 1 2 5 6 7 3 6 0 0 1 8 0 0 1 2 0 9 6 0 0 3 6 0 0 , , AUTHOR I T Y S ECT I ON : 8 6400 viawe s t . c orn .

IN

NS

; ; ADD I T I ONAL SECT I ON : 3600 n s 2 . vi awe s t . ne t .

IN

А

n s 2 . vi awe s t . ne t .

209 . 170 . 2 1 6 . 2

, , Que r y t irne : 5 rns e c , , S E RVE R : 2 1 6 . 8 7 . 6 4 . 1 2 # 5 3 ( 2 1 6 . 8 7 . 6 4 . 1 2 )

Часть 11. Работа в сетях

530

‘ ‘ WHEN : W e d Feb 3 1 8 : 4 2 : 2 0 2 0 1 6 , , M S G S I Z E rcvd : 1 2 6

Этот запрос возвращает AN S W E R для домена v i a w e s t . с от. Теперь мы знаем авто­ ритетный сервер имен и можем запросить и м я , которое м ы действительно хотим , www . v i a we s t . сот. $ dig @ ns l . viawest . net www . viawes t . com any

; ; , , ‘ ‘ ,

, , ‘ ‘ ,

< < > > D i G 9 . 8 . 3 — P l < < > > @ n s l . vi awe s t . n e t www . v i awe s t . com any ( 1 s e rve r f ound ) g l ob a l op t i on s : + cmd Got a n s we r : — > > H EADER update add newhos t . cs . colorado . edu 8 64 0 0 А 1 2 8 . 13 8 . 2 4 3 . 1 6 > > prereq nxdomain gypsy . cs . colorado . edu > update add gypsy . cs . colorado . edu СNАМЕ evi — l aptop . cs . colorado . edu

Динамические обновления — очен ь опасная возможность. О н и потен ц иально спо­ соб н ы предоставить п раво н е контрол ируе м о й зап и с и важ н ы х с исте м н ы х дан н ы х. Не п ытайтесь контролировать доступ на ос нован и и I Р-адресов: и х легко подделать. Л уч ш е воспользоваться системой аутентификации T S I G с общи м секретн ы м ключом. Например, в с истеме B I N D 9 поддерживается команда $ nsupdate -k ка талог_ ключа : фа йл_ ключа

Глава 1 6. DNS: система доменных имен

567

или % nsupdate -k ка талог_ ключа : секре тный_ ключ

Поскольку пароль задается в командной строке после кл юча -у, е го может увидеть тот, кто запустит команду w ил и ps в правильный момент. По этой прич ине более пред­ почтительной я вляется форма k Подробнее технология TS I G описана в разделе 1 6 . I O . Динамические обновления зон ы разрешаются в файле named . conf посредством па­ раметра a l l o w- upda t e или upda t e — po l i c y . П араметр a l l o w — u pd a t e предоставляет право обновления л юбых зап исей кл иентам , ч ьи I Р-адреса и кл юч и ш ифрования указа­ ны в списке . П араметр upda t e — p o l i c y появ ился в B I N D 9 и позволяет точ нее управ­ лять обновлениями на основании имен хостов и типов зап исей. Он требует испол ьзовать механизмы аутентификаци и . Оба параметра я вляются зон н ы м и . С помощью параметра upda t e — po l i c y можно разре ш ить клиентам обновлять с вои записи А и P T R , но не S OA, NS ил и КЕУ. М ожно также позвол ить хосту обновлять тол ь­ ко свои зап иси. И мена допускается задавать я вно, в виде поддоменов, с метаси м вола­ ми или с помощью кл ючевого слова s e l f , которое задает правила доступа ком п ьютера к собствен н ы м зап ися м . Записи о ресурсах идентифицируются по классу ил и типу. Си нтаксис параметра upda t e — po l i c y выглядит следующим образом. —

( g rant l de n y )

.

сущность имя_ типа имя [ типы]

;

Сущно с ть — это и м я криптографического кл юча, необходи мого для авторизации обновлен и й . Имя_ типа имеет четыре значения: name , s ubdoma i n , w i l d ca rd ил и s e l f . Опция s e l f я вляется особенно полезной, потому что позволяет хосту обновлять тол ько свои записи. По возможности , следует испол ьзовать именно ее. Имя — это обновляемая зона, а типы — тип ы записей о ресурсах, которые можно об­ новить. Есл и типы не указаны, то могут обновляться записи всех типов, кроме S OA, :-i s , RRS I G и N S E C или N S E C З . Рассмотрим пример. updat e — p o l i c y ( grant dhcp — ke y s ubdoma i n dhcp . c s . c o l o r a d o . e du А ) ;

В такой конфигурации л юбому, у кого есть кл юч d h c p — k e y , разрешается обнов­ лять адресные зап и с и в поддомене d h c p . c s . c o l o r a d o . e d u . Эта дир·е кти ва должна появиться в файле named . conf в инструкци и z o n e домена d h c p . c s . c o l o r a d o . e 0j u . Потребуется также инструкция key, содержащая определение кл юча d h c p — key. Приведе н н ы й н иже фрагм ент файла named . conf факультета ко м пьютерных наук университета Колорадо (Computer Science Department at the U niversity of Colorado) ис­ пользует инструкци ю u p d a t e — p o l i c y для того , чтобы позвол ить студентам , находя ­ щимся в классе систем ного админ истратора, обновлять свои поддоме н ы , не касаясь при этом остал ьного окружен ия системы DNS. / / saclas s . net zone » s a c l a s s . n e t » ( t ype ma s t e r ; f i l e » s a c l a s s / s ac l a s s . ne t » ; upda t e — po l i c y ( g r a n t f e a n o r mroe . s ubdoma i n s a c l a s s . ne t . ; g r a n t mo j o_mr o e . s ubdoma i n s a c l a s s . ne t . ; g r a n t dawdl e mroe . s ubdoma i n s a c l a s s . ne t . ; g r a n t p i r a t e_mr oe . s ubdoma i n s a c l a s s . ne t . ; );

Часть 11. Работа в сетях

568

1 6. 1 0. ВОПРОСЫ БЕЗОПАСНОСТИ DNS DNS появилас ь как совершенно открытая с истема, н о в процессе развития она ста­ новилась все более защи щенной, приобретая необходим ы е средства защиты. По умол­ чан и ю кажды й , у кого есть доступ в Интернет, м ожет исследовать ч ужой доме н от­ дел ьн ы м и запросами с помощью таких команд, как dig, host, nslookup или dri l l . В некоторых случаях можно получить образ всей базы данн ы х D N S . Для устранения этих недостатков в последние верси и пакета B I N D б ы л и введены различные средства управления доступом , основанные на проверке адресов ил и крипто­ графической аутентификации. В табл . 1 6. 5 перечислены эле менты подсистем ы безопас­ ности, которые настраиваются в файлах named . conf. Табли ца 1 6. 5 . Средства защиты сервера BIND Параметр

Ч то оп ределнет

Инструкции

acl

Разные

a l l ow — qu e r y

opt i o n s ,

a l l ow — r e c u r s i on

opt i on s

a l l ow — t r an s f e r

opt i on s ,

a l l ow — u p d a t e

zone

Кто может выполнять динамические обновления

Ы a c kh o l e

opt i on s

Какие серверы нужно полностью игнорировать

bogus

s e rv e r

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

upda t e — p o l i c y

z on e

Какие обновления разрешены

Списки управления дос�упом zone

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

z on e

Кто может запраши вать передачи зон

Еще раз о с п исках у п равления доступом на сервере B I N D Список управл е н ия доступом — это и м е н ован н ы й с п исок соответствия адресов, который м ожет служить аргументом разл и ч н ы х директив , в частности a l l ow — q u e r y , a l l ow- t ra n s f e r и Ы a c kh o l e . С интаксис списков был рассмотрен ранее. Кроме того, с п и с к и управл е н и я доступом м огут способствовать укреплен и ю безопасности DNS­ cepвepoв. В каждой орга низации должен существовать хотя бы один с писок для недоступных адресов и оди н — для локальных. Рассмотри м пример. acl b o gu s n e t s { О . О . О . О/В ; 1 . 0 . 0 . 0/8 ; 2 . 0 . 0 . 0/8; 169. 254 . 0 . 0/16; 1 92 . 0 . 2 . 0 /24 ; 224 . 0 . 0 . 0/3; 10 . 0 . 0 . 0/8; 172 . 1 6 . 0 . 0/8 ; 1 92 . 1 68 . 0 . 0 / 1 6 ; };

// // // // // // // // // //

a c l cune t s { 128 . 138 . 0 . 0/16;

/ / список с е т е й уни в е р си т е т а ш т а т а Колор адо // о с н о в н а я кампусн а я с е т ь

список недоступных и фикти вных с е т ей а др е с а по умолчанию з а р е з ервированные адр е с а заре з ервированные адр е с а канал ь н о -локаль ные деле гируемые адр е с а т е с т о вые адр е с а , нап одобие e x amp l e . com простра н с т в о груп п о вых адр е с о в ч а стное адр е с н о е пространство ( RFC 1 9 1 8 ) 1 9 ч а стное адресное простр а н с т в о ( RFC 1 9 1 8 ) ч а стное адресное простр а н с т в о ( RFC 1 9 1 8 )

1′>Не делайте частные адреса недоступ н ы м и , если о н и испол ьзуются для кон ф и гурирования вну­ тренних DNS-cepвepoв!

Глава 1 6. DNS: система доменных имен

569

198 . 11 . 1 6 . 0/24 ; 2 0 4 . 22 8 . 6 9 . 0 /2 4 ; );

Далее н ужно в глобал ьной секции o p t i o n s конфигурационного файла разместить следующие директивы. a l l ow- r e c u r s i on { cune t s ; ) ; Ы a c kho l e { b o g u s ne t s ; ) ;

Желательно также огран и чить передачи зон только легити м н ы м и подч и н е н н ы м и серверами. Это достигается с помощью следующих списков. acl our s l ave s { 12 8 . 1 3 8 . 2 42 . 1 ;

1 1 сервер anchor

); acl me a s u r eme n t s { 1 98 . 32 . 4 . 0/2 4 ; 2001 : 478 : 6 : : : /48; );

1 1 про е к т Билла Маннинга , 1 1 п р о е к т Билла Маннин г а ,

адр е с v 4 адр е с v 6

Собствен но ограничение реализуется такой строкой . a l l ow- t ra n s f e r { our s l ave s ; me a s u reme n t s ; ) ;

Передач и разреш е н ы тол ько нашим подч и н е н н ы м серверам , а также компьютерам глобал ьного исследовател ьского проекта , который посвящен определ е н и ю размеров сети И нтернет и процента неправильно сконфигурированных серверов. Подобное огра­ ничение л ишает остал ьных пользователе й возможности получать дам п всей базы дан ­ ных с помощью команды dig (см . раздел 1 6.4). Разумеетс я , н ужно по-прежнему защи щать сеть на бол е е н изком уров н е с помо­ щью сп исков управления доступом на маршрутизаторе и стандартных средств защиты на каждом хосте . Если такой возможности нет, ограничьте трафик DNS-пакетов шлюзо­ вым компьютером , который находится под постоянн ы м адм и нистративным контролем.

Открытые распознавател и Открыты й рас познавател ь — это рекурсивн ы й кеширующий сервер имен , получаю­ щий запросы от л юбого пользователя И нтернета и отвечающи й н а н их. Открытые рас­ познаватели опасны. Внешние пользователи могут потреблять ваши ресурсы без вашего разрешения или ведома, и , если они делают это со злы м умыслом , кеш вашего распоз­ навателя может быть «зараже н » . Что е щ е хуже , открытые распознаватели иногда испол ьзуются злоумы шл е н н и ками для усилен и я рас пределенной атаки на основе отказа в обслуживан и и . Организаторы атаки посылают запрос на ваш распознаватель, указывая фальшивый адрес отправител я , который я вляется объектом атаки . Ваш распознаватель послушно отвечает на эти запро­ сы и посылает огром н ы й пакет жертве . Жертва не посьmала запрос ы , но она обязана выпол н ить маршрутизацию и обработать сетевой трафик. Умножьте объем пакета на ко­ личество распознавател е й , и вы осознаете реальную опасность, грозящую жертве . Статистика свидетел ьствует о том , что от 70 до 75% кеш ирующих серверов и м е н в настоящее вре мя я вля ются открыты м и распознавателями! Сайт d n s . m e a s u r eme n t ­ f a c t o r y . com/ t o o l s может помоч ь вам проверить вашу орган изацию. Зайдите н а него, щел кн ите на ссылке O pen resolver test и введите I Р-адрес вашего сервера имен . Вы мо-

Часть 11. Работа в сетях

570

жете также проверить все серверы имен вашей сети или все серверы вашей организации, испол ьзуя иде нтифи каторы wh o i s . Для того чтобы ваши кеш ирующие серверы имен отвечали на запросы только локаль­ н ых пользователей , испол ь.зуйте список упрамения доступом в файлах named . conf.

Работа в ви ртуал ь ном окружен ии chroot Есл и хакеры взломают ваш сервер, то он и смогут получ ить доступ к с истеме под ви­ дом зако н н ого пол ьзователя . Для того чтобы у м е н ьш ить опас н ость, воз н и кающую в этой с итуаци и , вы можете запустить сервер в виртуальном окружен и и chroot под ви­ дом непривилегирован ного пол ьзователя л ибо сделать и то, и другое одновремен но. Дл я демона n&lll8d флаг команды — t задает каталог виртуал ьного окружен ия chroot, а флаг -u указывает идентификатор пользователя , под которы м работает демон named. Рассмотрим п р и мер. $ sudo nalll8 d -u 5 3

Эта команда запускает демон named как корневой процесс , но после того как демон named закон чит рут и н н ы е опера ц и и в рол и корневого процесса, он потеряет привиле­ гии и запустится под идентификатором U I D 53. М ногие орга ни заци и не испол ьзуют флаги -u и — t , но если объя влена тревога , они должны реагировать быстрее , чем хакеры . В иртуальное о круже н ие chroot н е может быть пустым каталогом , поскольку оно должно содержать все файл ы , н еобходи м ы е серверу имен для нор м ал ьной работы , / dev/nu l l /dev/random, файл ы зон , файл ы конфигураци и , ключ и , файлы системного журнала и доменного сокета U N IX, /var и др. Для того чтобы настроить их, требуется выполнить довол ьно бол ьшую работу. Вызов системы chroot осуществляется после за­ грузки б иблиотек, поэтому коп и ровать общие библиотеки в виртуал ьное окружение не обязател ьно. ,

Безопасн ы е межсерверн ы е вза имодействия посредством тех нологий TSIG и ТК ЕУ П ока спецификация D NS S EC (см. следующий подраздел) находилась на стадии при­ н ят ия , группа I ETF разработала более простой механ изм , названный TSI G ( RFC2845). Он позволял организовать безопасное взаимодействие серверов благодаря использованию сиг­ натур транзакций . Контрол ь доступа, основанный на таких сигнатурах, надежнее контроля на основе исходных I Р-адресов. Технология TS I G позволяет защитить передачу зоны между главн ы м и подчинен н ы м серверам и, а также защитить динамические изменения. В технологии TSI G при м е н яется симметричная схема ш ифрования, т.е . кл юч ш иф­ рова н и я совпадает с кл ючом де ш ифрования. Такой ключ называется общим секретным ключом (shaгed secret). Спецификация TS I G допускает испол ьзование нескол ьких мето­ дов ш и фрова н и я . В пакете B I N D реализован ы некоторые из таких методов. Для каждой пары серверов, между которыми органи зуется защищен н ый канал с вязи , должен созда­ ваться свой кл юч . Спецификация TS I G гораздо менее затратная в вычисл ител ьном плане , чем ш ифро­ вание с открытым кл ючо м , но она подходит только для локальной сети , где ч исло пар взаимодействующих серверов н е велико. На глобал ьную сеть эта спецификация н е рас ­ пространяется.

глава 1 6. DNS: система доменных имен

571

Настройка технологии TSIG для сервера B I N D Утил ита dn s s e c — keyge n , я вл я ющаяся частью пакета B I N D , ген е р ирует ключ для пары серверов. Рассмотрим, например, следующую команду. $ dnssec-keygen -а НМАС — S НА2 5 6 -Ь 1 2 8 -n HOST mas ter- s l avel Кma s t e r — s l a ve l + l 6 3 + 1 5 4 9 6

Флаг -Ь 1 2 8 означает, что утилита dns sec-keygen должна создать 1 28 -разрядны й ключ . В дан ном случае м ы испол ьзуем 1 28 -разрядный кл ю ч только л и ш ь для того, что­ бы он поместился на стран ице. В реальной жизни следует испол ьзовать более дли н н ы й ключ ; максимально допусти мая дл и на ключа равна 5 1 2. Данная команда создает два файла: Кmas ter- s lavel . +1 63+154 9 6 . private Кmas ter — s lavel . +1 63+154 9 6 . key

Здесь 1 6 3 — код алгоритма H MAC- S HA256, а 1 5 4 9 6 — случайное ч исло, использу­ емое в качестве идентификатора ключа на случай, если у одной пары серверов есть не­ сколько ключей. 20 Оба файла содержат оди н и тот же ключ, но в разных форматах. Файл . private выглядит примерно так. Priva t e — k e y — f o rma t : v l . 3 Al go r i t hm : 1 6 3 ( НМАС_SНА2 5 6 ) Кеу : owKt 6 ZWOl u O g aV FkwOqGxA== B i t s : ААА= Created : 2 0 1 60 2 1 8 0 1 2 9 5 6 PuЬl i s h : 2 0 1 6 0 2 1 8 0 1 2 9 5 6 Act i va t e : 2 0 1 6 0 2 1 8 0 1 2 9 5 6

Содержимое файла key будет таки м . .

ma s t e r — s l ave l . I N К Е У 5 1 2 З 1 6 3 owKt 6 ZWOl u O g aVF kwOqGxA==

Обратите вн и мание на то, что утилита dnssec-keygen добавила точки в коне ц и ме ­ ни каждого кл юча в обоих именах файлов и внутри файла . key. Это объясняется тем , что когда утилита dnssec-keygen использует кл юч и DNSSEC, добавляемые в файлы зон , имена этих ключей должны � ыть полностью определ е н н ы м и именами доменов и , следовательно, должны заканчиваться точкой. Таким образом , нам нужны два и нстру­ мента: оди н для общих секретных ключей , а второй — для пар открытых ключей . Вообще-то, файл key на самом деле н е н уже н : о н создается потому, что утилита dns sec — keygen и меет двойное назначение. Просто удал ите е го. Ч исло 5 1 2 в записи КЕУ означает не длину кл юча, а флаг, идентифицирующий запись как запись о главном кл юче D N S . После всех эти х сложностей вы могл и б ыть разочарованы тем , что сгенерирован­ ный кл юч представляет собой п росто длин ное случайное ч исло. Этот кл юч можно бьuю бы сгенерировать вручную, записав строку в кодировке ASCI I , дл и н а которой делится на четыре , и считать, что вы применил и 64-разрядное кодирование, или испол ьзовать утилиту mmencode для того, чтобы заш ифровать случайную строку. С пособ, которы м вы кодируете кл юч , не и меет значения; он просто должен существовать на обеих машинах. Скопируйте ключ из файла . private на оба сервера с помощью команды scp ил и просто с копируйте и вставьте е го. Не используйте утилиты telnet и ftp для копирова­ н ия кл юча: даже внутренние сети могут быть небезопасными. .

20Это число выглядит случай н ы м , но на самом деле о н о представляет собой хешированное значе­ ние ключа TS J G .

Часть 11. Работа в сетях

572

W К о м а нда s c p я в л я ет с я ч а ст ь ю п а кета S S H . Д о п о л н и те л ь н у ю и н ф о р м а ц и ю см . в разделе 27 . 7 .

Ключ должен быть записан в файлах named . conf на обоих ком пьютерах . В связи с тем , что эти файлы общедоступн ы , а ключ — нет, поместите ключ в отдельный файл , которы й будет включаться в файл named . conf. Файл ключа должен иметь уровен ь до­ ступа, равный 600, и принадлежать пользовател ю демона named. Например, можно создать файл master-slavel . tsig и вкл юч ить в него следующий фрагмент. k e y ma s t e r — s l ave l { a l g o r i thm hma c -md5 s e c r e t » сгенерирова нный_ ключ» };

В файл named . conf ближе к началу нужно добавить такую строку. i n c l u d e «mas t e r — s l av e l . t s i g » ;

На дан ном этапе л и ш ь определен ключ . Для того чтобы его можно б ыло использо­ вать для подписи и проверки обновлений, нужно посредством и нструкци и s e rv e r и ди­ рективы k e y s заставить каждый сервер идентифицировать другую сторону. Например, в и нструкцию zone на главном сервере можно вкл ючить строку a l l ow- t r a n s f e r { k e y ma s t e r — s l ave l . ;

};

а в файл named . conf подчиненного сервера — строку s e rv e r IР — адрес -гла вного_ сервера { k e y s [ ma s t e r — s l ave l ; } ;

} ;

И мя ключа в нашем примере носит общ и й характер. Есл и вы испол ьзуете кл ючи TS I G для многих зон , то , возможно, захотите включ ить в имя кл юча имя зон ы , чтобы все стало ясно. Если в ы в п е р в ы е и с п ол ьзуете под п и с и транза к ци й , запус к а йте де м о н n amed на первом уровне отладки (режим ы отладки будут описаны поздне е ) , пока сообщен ия об ошибках не исчезнут. П р и использовани и ключей TSI G и подписей транзакций между глав ны м и подчи ­ н е н н ы м серверами необходимо синхронизировать часы на обоих серверах по протоколу NTP. Если часы сли ш ком сильно расходятся (более чем на пять м инут) , то верификация подписи не будет выполнена. Эту проблему иногда оче н ь сложно распознать. TSIG это механизм сервера B I N D , позволяющий двум хостам автоматически ге ­ нерировать общий секрет н ый ключ , не прибегая к телефонным звонкам или секретно­ му копированию для распростран е н ия ключа. Он испол ьзует алгоритм обмена кл ючами Диффи-Хелл мана ( Diffie- Hellman key exchange algorithm ) , в котором на каждой сторо­ не генерируется случайное ч исло, над н и м выполняются определенные математические операц и и , а резул ьтат посылается другой сторо н е . Затем каждая сторон а объединяет с вое и получ е нное ч исла по определенному математическому правилу и получает оди н и тот ж е кл ю ч . Злоум ышленн и к может перехватить сообщение, но он не сможет выпол­ н ить над н и м требуемые математические операции . 21 Серверы компании M icrosoft используют нестандартный вариант механ изма TS I G , которы й называется G S S-TS I G . В н е м для обмена кл юча м и испол ьзуется технология ТКЕУ. Если вам нужно, чтобы сервер компани и Microsoft взаимодействовал с сервером B I N D , используйте опции t ke y — d oma i n и t ke y — g s s a p i — c redent i a l . —

2 1 Математическую основу этого алгоритма образует задача дискретного логарифмировани я , осо­

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

Глава 1 6. DNS: система доменных имен

573

Другой механизм для подписи транзакций м ежду серверами или службам и динами­ ческого обновления и главным сервером называется S I G(O) . Он использует криптогра­ фию, основан ную на открытых ключах. Детали этой технологии описаны в документах RFC2535 и RFC293 l .

Технология DN SSEC D N S S EC — это набор расш и ре н ий D N S , позволяющих ауте нтифицировать ис­ точник дан ных зон ы и проверить их целостность, испол ьзуя ш ифрование с открытым ключом. Так и м образом , D N S S EC позволяет D N S — кл иентам задавать вопрос ы вида «Действительно ли дан ные зоны поступил и от владельца зоны ? » и «Те ли это данные, ко­ торые послал владелец?» Технология D N S S EC основана на цепочке доверия: корневые серверы предоставля­ ют подтверждающую информацию для доменов верхнего уровня, те — для доменов вто­ рого уровня и т.д. В системах ш ифрования с открыты м ключом испол ьзуются два кл юча: оди н шифру­ ет (подписывает) сообщение, а другой дешифрует (проверяет) его. П убликуемые дан н ые подписываются секретны м «лич н ы м » ключом . Л юбой может проверить правил ьность цифровой подписи с помощью соответствующего «открытого» ключа, которы й свободно распространяется. Если открытый кл юч позволил правильно рас ш ифровать файл зоны , значит, зона была зашифрована искомым личным кл ючом. Суть в том , чтобы убедиться в подлинности открытого ключа, испол ьзуемого для проверки. Такие с исте м ы ш ифрова­ ния позволяют одной из сторон поставить свою » подпись» на открытом ключ е , переда­ ваемом другой стороне, гарантируя легитимность ключа. Отсюда термин цепочка доверия. Данные, составляющие зону, слиш ком вел и ки для ш ифрования с открытым кл ючом ; процесс ш ифрования получится сли ш ком медленным. Вместе с тем данные сами по себе не секретн ы , поэтому они просто пропускаются через функцию хешировани я (к примеру, вычисляется контрольная сумма M DS ) , а резул ьтат подписывается ( шифруется) секрет­ ным ключом зоны . Полученный зашифрованный хеш — код называется цифровой подписью ил и сигнатурой зон ы . Цифровые подписи обычно добавляются к данн ы м , подли нность которых они удостоверяют в виде записей RRSIG в подписанном файле зоны . Для проверки с и гнатуры ее н ужно де ш ифровать открытым ключом подписавше й стороны, » прогнать» данные через тот ж е алгоритм хеширования и сравнить вычислен­ ный хе ш -код с рас ш ифрова н н ы м . В случае совпадения подписавшее л и цо считается аутентифицированным, а дан ные — целостным и . В технологии DNSS EC каждая зона имеет открытые и секретные ключи . Фактически она и меет два набора ключей: пара кл ючей для подписи зон ы и пара ключей для под­ писи ключа. Секретны м кл ючом подписи зон ы подписывается каждый набор ресурсов (т.е. каждый набор записей одного типа, относящихся к одному хосту) . Открытый ключ подписи зон ы испол ьзуется для проверки сигнатур и включается в базу данных зоны в виде записи DN SKEY. Родител ьские зон ы содержат записи DS, представляющие собой хеширова н н ы й ва­ риант записей DNSKEY для самоподписывающихся ключей подписи ключе й (self-signed key-signing k eys) . Сервер имен проверяет аутентичность записи D N S K E Y дочерней зон ы , срав н и вая ее с подписью родительской зон ы . Для проверки аутентичности ключа ро­ дительской зон ы сервер и м е н проверяет родительскую зону родительской зон ы и так далее, пока не вернется в корневую зону. Открытый ключ корневой зоны должен быть открыто опубликован и включен в файлы » подсказок» корневой зоны . В соответствии с о спецификациям и D N S S EC, если зона и меет нескол ько ключей , кажды й из них должен применяться при проверке данных. Это требование объясняется

часть 11. Работа в сетях

574

тем , что ключи мoryr быть изменены без прерывания работы службы D N S . Если рекур­ сивный сервер и м е н , испол ьзующий технологи ю D N S S EC , посылает запрос н еподп и ­ санной зон е , т о поступающий неподписан н ы й ответ сч итается корректн ы м . П роблема возникает лишь тогда, когда срок действия подп иси истек или родительс кая и дочерняя зон ы не согласовал и текущий ключ DNSKEY дочерней зон ы .

Пр а вила п рото кол а DNSSEC П режде чем приступать к развертыван и ю протокола D N S S EC, следует усвоить н е ­ сколько правил и процедур или хотя бы подумать о н их. Рассмотрим примеры. • Кл юч и какого размера вы будете испол ьзовать’? Более дл и н н ы е ключ и я вля ются более надежны м и , но они увеличивают размеры пакетов. • Как часто будете изменять кл юч и , если н и каких нарушений п равил безопасности не происходит’? М ы предлагаем завести с пециальный журнал , в который вы будете записывать дан ­ ные о каждом с ге нерированном кл юче ; о б ап паратном и програ м м ном обесп ечен и и , используемом дл я этого; о дескри пторе, присвоенном кл ючу; о верси и программ ного генератора ключей; испол ьзованном алгоритм е ; длине кл юча и сроке действия подписи. Если впоследствии криптографический алгоритм окажется ском про метирован н ы м , вы сможете проверить свой журнал и выясн ить, не подвергаетесь л и вы опасности .

За п иси о р есурсах DN SSEC П ротокол D N S S EC использует шесть типов зап исей о ресурсах, кратко описан н ых в разделе 1 6.4, D S , DLV, DN S K E Y , RRS I G , N S E C и N S E C З . Сначала м ы опишем их в це­ лом , а зате м очерти м их испол ьзование в процессе подписан ия зон ы . Каждая из этих записей создается инструментам и протокола D N S S EC, а не вводится в файл зон ы с по­ мощью текстового редактора. Запись DS ( Designated Signer) возн икает тол ько в дочерней зоне и означает, что под­ зона я вляется безопасной ( подписанной). Она также идентифицирует кл юч , испол ьзу­ емый дочерней зоной дл я подписания с воего собстве н ного набора записей о ресурсах К Е У . Запись DS содержит идентификатор кл юча ( пятизначное ч исло ) , кри птографи ­ ческий алгоритм , тип дайджеста (digest typ e ) и дайджест зап и с и о б открытом кл ю ­ че, разрешенном ( ил и испол ьзованном) для подписи записи о кл юче дочерней зон ы . Соответствующий пример приведен ниже . 22 —

e x amp l e . com . I N

DS

682

5

1

1 2 8 9 8 DC F 9 F7AD2 0 DBCE 1 5 9 E 7 . . .

Изменение существующих ключей в родительской и дочерней зонах я вляется сложной проблемой и требует сотрудничества и взаимодействия между родительской и дочерней зонам и . Для решения этой проблемы создаются записи DS, используются отдельные кл ю­ чи для подписи ключей и зон , а также применяются пары многократных кл ючей. Кл юч и , содержащиеся в зап и с и о ресурсах D N S K E Y , могут б ыть л и бо кл юч а м и дл я подписания кл юча ( key-signi ng k e y — K S K) , л ибо ключами для подписания зон ы (zone-sigпi ng key ZS K). Для разл ичия между н и м и испол ьзуется новый флаг под на­ званием SEP («secure eпtry poiпt » — «точка безопасного входа » ) . Пятнадцатый бит поля флагов устанавливается равны м един и це для ключа KS K и О для кл юча ZSK. Это со­ глашение делает поле флагов нечетны м числом для кл юча KS K и четным для кл ючей —

228 этом разделе 64-разрядн ые хеш и и кл ючи были усечен ы , чтобы сэкономить п ространство и лучше п роиллюстри ровать структуру зап исей .

Глава 1 6. DNS: система доменных имен

575

ZSK, если интерпретировать его как десятичное ч исло. В настоящее время эти значен ия равны 257 и 256 соответственно. Для обеспечения удобного перехода от одного ключа к другому можно генерировать многократные ключи. Дочерняя зона может изменить свои ключи подписания зоны, не со­ общая об этом родительской зоне. Она должна согласовывать с родительской зоной только изменение кл юча для подписания ключей. Когда ключ изменяется, и стар ы й , и новый кл ю­ чи на определенном отрезке времени считаются действующими . Как только срок действия кешированных значений в И нтернете истечет, старый кл юч будет считаться отмененным. Запись RRS I G — это подпись набора записей о ре с у рса х (т. е . набора всех записей од­ ного и того же типа и с одн и м и тем же именем внутр и зон ы ) . Записи RR S I G г е н ер и р у­ ются программ н ы м обеспечение м , предназнач е н н ы м для подпи са н и я зоны , и добавля­ ются в подписан ную верси ю файла зоны . Запись RRS I G содержит много информации. •

Тип записей о ресурсах, входящих в подписывае м ы й набор.

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

Количество меток (фрагментов, разделенных то ч ками) в поле и мени.

Значение ТТL для подписываемого набора зап исей .

Срок действия подписи ( в формате ггггмм ддччсссс) .

Время подписания набора записей (также в формате ггггммддччсссс).

Идентификатор ключа (пятизнач н ы й номер) .

И мя подписавшего (имя домена) .

Сама цифровая подпись (64-разрядная) .

Расс мотри м пример. RRS I G

NS 5 2 5 7 600 2 0 0 9 0 9 1 9 1 8 2 8 4 1 ( 2 0 0 9 0 8 2 0 1 8 2 8 4 1 2 3 3 0 1 e x ampl e . c om . pMK Z 7 6wa PVTЫ guEQNUo j NV1VewHau 4 p . . . == )

При подписани и зон ы также генерируются зап и с и N S E C или N S E C З . В отл и ч и е от подписан н ы х наборов зап исе й , о н и сертифицируют интервал ы между и м е на м и н а ­ боров записей и т е м сам ы м позволяют подписывать ответ типа » нет такого домена» ил и «нет такого набора записей о ресурсах» . Например, сервер может ответить н а запрос за­ писей А с именем b o r k . a t ru s t . с от , послав запись N S E C , подтверждающую отсутствие любых записей А между именами bo r k . a t ru s t . с от и b o r r e l i a . a t ru s t . с от. К сожал е н и ю , вкл юч е н ие в запи с и N S E C конеч н ы х точек позволяет обойти зону и выяснить все ее действующие хосты. В версии N S E C З этот недостаток был устранен пу­ тем вкл ючения в запись хешированных имен конечных точек, а не сам их имен. Правда, это было сделано за счет более интенсивных вычисл е н и й : чем выше безопасность, тем ниже производительность. В настоя щее время испол ьзу ютс я как запис и N S E C , так и за­ писи N S E C З , и вы должны будете сделать выбор между н и м и при генерирова нии с воих ключей и подписании своих зон . Если защита от блуждан ия по зоне не я вляется критически важной для ва ш е й орга­ низаци и , мы рекомендуем пока использовать запись N S E C .

Н астройка п ротокола DNSSEC Использование подписанных зон связано с двумя разн ыми рабочи м и потоками: один из них создает ключи и подписывает зоны , а второй обсл ужи вает содержимое этих подпи ­ санных зон . Эти функции не обязательно реализовывать на одном и том ж е компьютере.

576

Часть 11. Работа в сетях

На самом деле лучше изолировать закрытые ключи и процесс подписания зоны, сильно за­ Jl)ужающий центральный процессор, на компьютере, который не доступен из Интернета. ( Разумеется, компьютер, обрабатывающий данные, должен быть виден из И нтернета.) Н а первом этапе настройки протокола D N S S EC следует организовать файлы зон так , чтобы все файлы дан н ых для зон ы находил ись в одном каталоге . Это н еобходимо для п равил ьной работы инструментов, управляющих зонами по протоколу DN S S EC. Затем следует вкл ючить протокол DN S S EC н а с воих серверах с помощью оп иций файла named . conf.

op t i o n s { dn s s e c — enaЫ e ye s ;

для авторитетного сервера и op t i o n s { dns s e c — e na Ы e ye s ; dns s e c -v a l i d a t i on y e s ;

дл я рекурси вн ы х серверов. Опция d n s s e c — e n a Ы e приказы вает вашему а вторитет­ ному серверу вкл ючать подписи н аборов записей DN S S EC в свои ответы на запрос ы , поступающие от серверов имен , работающих п о протоколу D N S S EC . Опция d n s s e c ­ va l i d a t i o n заставляет демон named проверять легити мность подписе й , которые о н по­ лучает в ответ от других серверов.

Генери рован ие пар кл ючей Необходимо сгенерировать две пары ключей для каждой зон ы , которую хотите под­ п исать, — для подписан ия зон ы ( Z S K) и для подписания ключей ( KS K) . Каждая пара состоит из открытого и закрытого кл ючей. Закрытый ключ KSK подписывает ключ ZSK и создает безопасную точку входа для зон ы . Закрытый кл юч Z S K подписывает зап иси о ресурсах зоны . Открытые ключи зате м публикуются , чтобы позвол ить другим сайтам проверить ваш и подписи. Команды $ dnssec-keygen — а RSASRA25 б -Ь 1 0 2 4 -n ZONE example . com Kexampl e . c om . + 0 0 8 +2 9 7 1 8 $ dnssec-keygen — а RSASRA25 б — Ь 2 0 4 8 — n ZONE — f KSK example . com Kexampl e . c om . + 0 0 8 + 0 5 0 0 5

генерируют для сайта exampl e . сот пару 1 024-битовых ключей ZS K , испол ьзующую ал ­ горитмы RSA и S HA-256, а также соответствующую пару 2048-битовых ключей KS K.23 Серьезная п роблема, с вязанная с Оfl)ан ичен ием н а предельный размер пакета U D P, вы­ нуждает отдавать предпочтен ие коротким кл ючам для подписания зоны и ч асто их ме­ н ять. Дл я пов ы ше н ия уровня безопасности можно использовать более дл и н ные кл ючи для подписания ключей. Ген ерирование кл ючей зан и мает немн ого времени — всего нескол ько секунд. Как правило, Оfl)ан ичивающим фактором я вляется н е мощность централ ьного процессора, а энтропи я , доступная для рандомизации. В системе Linux для повы шения э нтропи и за счет допол нительных источ ников испол ьзуется демон haveged, которы й повышает ско­ рость генерирован ия ключей. 2 1 Рекомендаци и разных орга н и заций, касающиеся дл и н криптографических кл ючей , п р и веден ы н а веб-сайте ke y l e ng t h . c om.

глава 1 6. DNS: система доменных имен

577

Команда dnssec-keygen выводит в стандартн ы й поток в ывода базовое и м я файла для сгенерированного кл юча. В нашем примере example . com это имя ключа, 0 0 8 идентификатор набора алгоритмов RSA/S HA-256 , а 2 9 7 1 8 и 0 5 0 0 5 хеширова н н ы е значения, которые назы ваются идентификаторам и ключ е й , сле п ка м и кл ючей ил и де­ скрипторами ключе й . При каждом запус ке команда dnssec-keygen создает два файла ( . key и . private). —

Kexample . com+0 08+2 9 7 1 8 . key Kexample . com+0 08+2 9 7 1 8 . private

# О т крытый ключ дл я подписи з о н ы # З а крытый ключ для подписи зоны

Существует несколько ал горитмов ш ифрования, каждый из которых и м еет свой диа­ пазон дл и н ключей . Для того чтобы увидеть с писок доступн ых алгоритмов, можно вы­ полнить команду dnssec-keygen без аргументов. Кроме того, сервер B I N D может ис­ пользовать ключи , сгенерированные другим программ н ы м обеспечен и е м . В зависимости о т верс и и вашего программного обеспечения, и м е н а некоторы х до­ ступн ых алгоритмов могут содержать имя N S ECЗ в качестве префикса ил и окон чания. Если вы хотите испол ьзовать записи N S E C З , а н е N S E C дл я подписан и я отри цател ь­ ных ответов, должн ы сгенерировать N S ЕСЗ -совместим ы е кл ю ч и одн и м и з N S ЕС З ­ совместим ых алгоритмов ; подробности можно найти на справочной странице, посвя ­ щенной команде dnssec-keygen. Кажд ы й файл key содержит п о одной зап и с и о ресурсах D N S S EC для сайта examp l e . сот. Например, н иже приведен открытый ключ для подписания зоны , усечен­ ный по ш ирине стран ицы. Его можно назвать ключом ZS K, потому что поле файлов равно 256, а не 257, как для ключей KS K. .

ехатрl е . с от . IN DNSKEY 2 5 6 3 8 AwEAAc y L r g EN t 8 0J 4 P I Qiv2 Z hWwSviA . . .

Эти открытые ключи должн ы быть вставл е н ы в файл ы зон с помощью директив ы $ I NCLUDE или другим с пособом либо в коне ц , либо сразу после записи S OA. Для того чтобы скопировать ключи в файл зоны , можно добавить их с помощью команды cat24 и вставить с помощью текстового редактора. В идеале закрытая часть любой пары ключей должна храниться в ком пьютере, отклю­ ченном от сети, ил и хотя бы в ком пьютере, недоступном из Интернета. Для динамически обновляемых зон это требование практически невыполнимо, а для ключей, предназначен­ ных для подписания зон , еще и непрактично. Тем не менее для кл ючей , предназначенных для подписания других ключей , дан ное требование абсолютно разумно, поскольку эти ключи имеют долгий срок действия . Подумайте о скрытом главном сервере, недоступном извне для ключей ZSК. Распечатайте закрытый ключ KS K ил и зап и шите его на флешку, а затем спрячьте в сейфе , пока он не потребуется в следующий раз. » Заперев» новые закрытые ключи , целесообразно записать и н формацию о новых ключах в с исте м н ый файл ключей. При этом не обязательно записывать туда сами кл ю­ чи. Достаточно зап исать их идентификаторы , алгоритмы , дату, назнач е н ие и т.д. По умолчанию срок действия подписи огран ичен одни м месяцем для записей RRS I G (ZS К-подписи наборов записей о ресурсах) и тремя месяцами для записей DN S S I G ( КSК­ подписи ключей ZSK) . В настоящее время рекомендуется испол ьзовать 1 024-битовые ключи Z S K от трех месяцев до одного года, а 1 280-битовые кл ючи KSK — от одного до двух лет. 25 Поскольку рекомендуемые сроки действия ключей дол ьше, чем сроки, уста­ новленные для них по умолчанию, эти параметры необходимо указывать явно при под­ писании или периодическом переподписании зон , даже если сами ключи не изменил ись. 24Исполыуйте команду наподобие cat Кехтарl е . сот+* . key >> zone f i l e . Операция >> означает до­ бамение ключа в конец файла z one f i l e , а не его замену, как операция >. (Не перепугайте их!) 25Рекомендации разных органи заций , касающиеся м и н криптографических ключе й , при ведены на веб-сайте k e y l e n g t h . сот.

Часть 11. Работа в сетях

578

Под п исан ие зоны Итак, теперь, когда у вас есть кл ючи , в ы можете подписывать зон ы с помощью ко­ манды dns sec-s ignzone , добавляющей записи RRS I G и N S E C или N S E C З в каждый на­ бор записей о ресурсах. Эти команды считывают ори гинальны й файл зон ы и создают отдельную подп исанную копи ю с именем файл_ з о ны . signed. Си нтаксис команды dns sec- signzone для сервера B I N D и меет следующ ий вид. dns sec — signzone [ — о зона ] [ -N increment] [ — k КSК -файл] фа йл_ зоны [ ZSК-файл]

где параметр з она по умолчани ю равен ф а йл_ зоны, а кл ючевые файл ы по умолчан ию задаются командой dnssec-keygen, как описано выше. Есл и имена ваш их файлов зоны совпадают с именами зон , а и мена ключевых файлов не изменял ись, то команда сокращается до следующего варианта: dnssec- s ignzone [ -N increment] фа йл_ зоны

Флаг -N i n c remen t автом атически увеличивает порядковый номер в зап иси S OA, так что забыть это сделать будет невозможно. Кром е того , можно указать значение unixtime , чтобы установить порядковый номер равны м текущем у врем е н и U N IX ( ко­ лич еству секунд, прошедших с 1 я нваря 1 970 года) , или значение keep, чтобы предот­ вратить изменение оригинального порядкового ном ера командой dns sec — s ignzone. П орядковый номер увел и ч ивается в файле подписанной зон ы , но н е в оригинал ьном файле зоны . Рассмотрим пример, в котором используются сгенерированные ранее кл ючи . $ sudo dns sec-s ignzone — о example . com — N increment -k Kexample . com+ 0 0 8 + 0 5 0 0 5 example . com Kexample . com+0 08+2 9 7 1 8

П одп исанн ы й файл упорядочи вается в алфавитном порядке и содержит зап и с и DN S KE Y , добавленные вручную, а также записи RRS I G и N S E C , сгенерированные в ходе подп исания. Порядковый номер зон ы увеличен. Если вы сгенерировал и свои ключи с помощью алгоритма, совместимого с N S ECЗ, то должн ы подп исать зону так, как показано выше, но указав флаг — 3 sal t . Другие по­ лезн ые опции команды dnssec-signzone приведен ы в табл . 1 6. 6 . Таблица 1 6 . б . Флаги команды dnssec — siqnzone

Фл а г -g

-s начальный_момент конечный_момент

-t

Описание

Генерирование записи (записей ) os, которая должна быть включена в роди ­ тельскую зону Установка момента времени, с которого подп иси считаются действительными Установка момента времени, после которого подписи считаются недействительными Вывод статистических показателей

Дан н ые о сроках действия подписей можно выразить в виде абсолютного врем е н и в формате г г г гммдд ч ч мм с с или относительного вре м е н и , считая о т текущего момен­ та, в формате + N, где N количество секунд. По умолчанию период действия подписи юменяется от одного часа в прошлое до 30 дней в будущее. Рассмотр и м пример, в ко­ тором мы указы ваем , что подпис и должны быть действительны м и до окончания кален­ дарного 20 1 7 года. —

$ sudo dnssec- s ignzone -N increment -е 2 0 1 7 1 2 3 1 2 3 5 9 5 9 example . com

глава 1 6. DNS: система доменных имен

579

Размеры файлов подписан н ых зон от ч етырех до десяти раз больше, чем размеры файлов исходных зон , и все попытки навести логическ и й порядок н апрас н ы . Строка наподобие rnai l — r e l a y

А

63 . 173 . 18 9 . 2

превращается в нескол ько следующих строк. 57600 А 63 . 17 3 . 1 8 9 . 2 ma i l — r e l a y . e x ampl e . c om . 57600 RRS I G А 8 3 57600 20090722234636 ( 2 0 1 5 0 62 2 2 3 4 6 3 6 2 3 3 0 1 e x ampl e . c om . Y 7 s 9 j DWYuuXvo z e U 7 z GRdFCl + r z U 8 c L i w o e v O I 2 TG f L l b h s Rg J f k p E Y FVRUB 7 kKVRNguEYwk d 2 RS k D J 9 Q z RQ+w== ) ma i l — r e l a y 2 . e x amp l e . com . А RRS I G N S E C NSEC 3600 N S EC 8 3 3 6 0 0 2 0 0 9 0 7 2 2 2 3 4 6 3 6 ( RRS I G 3600 2 0 1 5 0 6 2 2 2 3 4 6 3 6 2 3 3 0 1 e xamp l e . com . 4 2 Q rX P 8 vp oC h s G P s e P roBMZ 7 t wf 7 e S 5WK+ 4 0 WNsN 8 4 h F O n o t ymRx Z R I Z yp qW z L I PBZAUJ7 7 R H P O h L f BDoqm Z Yw== )

С практической точки зрен ия файл подписанной зон ы больше н ельзя н азвать по­ нятн ым дпя человека и его невозможно отредактировать вруч ную из-за зап исей RRS I G и NSEC или N S E C З . Этот файл н е содержит н и одного фрагме нта, который пользователь мог бы измен ить вручную! За исключением записей D N S S EC , каждый набор зап исей о ресурсах (ресурсных за­ писей с один аковы м типом и и м е н е м ) пол учает одну подпис ь от кл юча Z S K. Записи о ресурсах DN S S E C подписываются как ключом ZSK, так и ключом K S K, поэтому они содержат две записи RRS I G . Тем не менее 64-разрядное представление подписи заканчи­ вается несколькими знаками равенства, потому что дпина записи должн ы быть кратной четырем . Как тол ько ваша зона подписана, остается л и ш ь указать сервер и м е н в подп исан ­ ных версиях файлов зон ы . Если вы ис пол ьзуете сервер B J N D , поищите и н струкцию zone, соответствующую каждой зон е в файле named . conf, и измените параметр f i l e с ехатр l е . сот н а е х атр l е . сот . s i gned. В закл ю ч е н и е перезапустите демон сервера и м е н , застав и в е го проч итать с нова свой файл конфигураци и . Для сервера B I N D следует выпол н ить команды sudo rndc reconfig и sudo rndc flush. Теперь мы обслуживаем подписанную зону D N S S EC! Для того чтобы внести измене­ ния, вы можете отредактировать либо исходны й неподписанн ы й файл зон ы , либо под­ писан н ы й файл зон ы , а затем переподписать зону. Редактирование подписанной зон ы иногда оказывается чрезвычайно сложной задаче й , но это проще, ч е м повторное под­ писан ие всей зон ы . Удалите зап иси RRS I G , соответствующие всем изменяе м ы м зап исям . Дл я того чтобы избежать путаницы между версиями, вероятно, следует внести идентич ­ н ы е изменения в неподписанную зону. П р и передаче подписанной зоны в качестве аргумента команде dns sec — s i gnzone все неподписанные записи подписываются, а подписи всех зап исей , срок действия ко­ торых подходит к кон цу, обновляютс я . Выраже н ие «срок действия подходит к кон цу» означает, что прошло три четверти периода де йствия подпи си . П о вторное подписа­ ние, как правило, приводит к изме н е н ия м , поэтому следует измен ить порядковы й но­ мер зон ы вруч ную ил и автоматически с помощью сервера B I N D , и спользуя паратмер -N increment в командной строке dns sec-signzone.

Часть 11. Работа в сетях

580

Это все , что касается локал ьной части конфигурации п ротокола D N S S EC . Осталос ь только реш ить трудную проблему: соединить наш безопас н ы й » DN S-островок » с дру­ гими надежн ы м и и подписан н ы м и частя ми иерархии D N S . Мы должны л ибо передать н а ш и зап иси DS в подписан ную родител ьскую зону, либо испол ьзовать динам ическую п роверку доменов. Решение этих задач описы вается в следующем разделе .

Це по ч ка д ов ерия в п р ото коле DNSSEC П родолжи м н а ш п р и м е р , с вязан н ы й с настро й ко й п ротокол а D N S S EC . Сайт e x amp l e . сот теперь подписа н , и е го серверы имен поддерживают протокол D N S S EC. Это знач ит, что при отправке запросов они испол ьзуют протокол E D N SO, рас ш ире н н ы й протокол DN S, а в D N S — заголовке пакета устанавливают флаг, вкл ючающи й протокол D N S S EC. Отвечая на запросы , которые приходят с таким установл е н н ы м битом в за­ головке , о н и включают в свой ответ подписан ные дан н ые. Кл иент, получающи й подп иса н н ые запросы , может оцен ить корректность ответа , проверив е го подпись с помощью соответствующего открытого ключа. Однако он полу­ чает этот ключ опять же из зап иси зон ы DN SKEY, что, есл и вдуматься, довольно подозри­ тельно. Ч то может помешать постороннему л и цу предоставить ложн ые записи и лож­ н ый открытый кл ю ч , чтобы пройти проверку’! Каноническое решение заключается в том , чтобы передать ваше й родительской зон е зап ись D S , которую о н а должна включ ить в свой файл зоны . Запись D S , приходящая и з родител ьской зон ы , сертифицируется родител ьским закрытым кл ючом. Если кл и е н т доверяет с вое й родител ьской зон е , он долже н верить в то, что зап и сь D S родител ьской зон ы правил ьно отражает открытый кл юч вашей зон ы . В свою очередь, родител ьская зона сертифицируется своей родител ьс кой зоной и так вплоть до корня.

См е на кл юч е й DN SSEC Для п ротокола DN S S EC смена кл юче й всегда была трудной задачей . Его исходн ые с п ецификации был и , по существу, изменен ы для того, чтобы реш ить проблем ы , связан­ н ы е с обеспечением взаимодействия между родител ьской и дочерней зонами для созда­ н и я , изме нения ил и удаления кл ючей. Новые спецификации называются D N S S EC-Ьis. Смена кл ючей ZSK представляет собой относ ител ьно н есложную задачу и не п реду­ сматривает наличия родител ьской зон ы ил и какой-либо точ ки доверия. Единстве н н ы м «скол ьзким » местом является расписание. Кл ючи имеют определен н ы й срок действия , поэтому и х зам ену н еобходимо производить до истече н ия этого срока. Однако кл юч и и м е ют период ТТL, определе н н ы й в файле зон ы . Для илл юстрации предположим , что период ТТL раве н одному дню и что ключи на следующей неделе еще будут действовать. Придется выпол н ить следующие действия . • • •

Сге нерировать новый кл юч ZSK. Включить его в файл зон ы . Впервые или повторно подписать зону с помощью кл юча KS K л ибо старого кл юча ZS K. Попросить сервер имен перезагрузить зону; теперь в ней будет действовать новы й ключ. Подождать 24 часа ( период ТТL) ; теперь все могут испол ьзовать как стары й кл юч , так и новый .

Глава 1 6. DNS: система доменных имен

581

Подписать зону с нова с помощью ключа KS K и нового ключа ZS K.

Попросить сервер имен перезагрузить зону.

П одождать 24 часа ; теперь все и меют новую зону.

Удалить старый ключ ZSK, например при следующем изменен и и зон ы .

Эта схема называется предварительной публикацией (prepuЫishing). Совершенно оче­ видно, что до того, пока все будут испол ьзовать новый кл юч , приходится запус кать этот процесс как м и н и мум дважды после истечения двух периодов TTL. Эти периоды ожи­ дания гарантируют, что л юбой сайт с кеш ирован н ы м и значен и я м и всегда будет и меть кеширова н н ы й ключ , соответствующий эти м кеширова н н ы м данн ы м . Еще одной пере м е н н о й , которая вл ияет на этот процесс, я вляется вре м я , которое потребуется вашему самому слабому подч инен ному серверу для обновления своей ко­ пии вашей зон ы после получения уведомлен ия от главного сервера. По этой при ч и не не следует ждать до последней м инуты , чтобы начать процесс смены ключей или повторно­ го подписания зон , срок действия подписей которых исте к. Просроченные подписи не­ действительн ы , поэтому сайты , проверяющие подп иси D N S S EC , н е смогут выпол н ить поиск имен для вашего домена. Механизм смены кл ючей KSK назы вается двойным подписанием (douЫe signing) и так­ же довольно прост. Однако вам придется переслать новую запись DS родительской зоне или послать запись DLV с воему «суррогатному родителю » . Убедитесь, что родительская зона или репозитарий точек доверия вас признал и , прежде чем переключиться на новый ключ . Процесс смены кл ючей KSK состоит из следующих этапов. •

Создать новый кл юч KSK.

Включить его в файл зон ы.

Подписать зон у и новы м , и стар ы м ключами KSK и ZSK.

Попросить сервер имен перезагрузить зону.

Подождать 24 часа (период ТТL) ; теперь у всех есть новы й кл юч .

Уведом ить все точки доверия о новом значении KSK.

После подтверждения удалить старую запись KSK из зон ы .

Заново подписать зону новым и кл ючами KS K и ZS K.

И нструменты DNSSEC В дистрибутивный набор B I N D 9. 1 0 входит новы й и н струмент для отладки . Domain Entity Lookup and Vcllidation Engine ( D ELV) выпол няет поиск аналогично утилите diq, но при этом он лучш е согласован с протоколом DN S S EC . Фактически утил ита delv проверяет цепочку доверия DNSSEC с помощью того же самого кода, которы й исполь­ зует демон named в пакете B I N D 9. Кроме и нструментов DNSSEC, поставляемых с пакетом B I N D , существует четыре набора инструме нтов для развертывания и тестирования : ldns, DNSS EC-Toos (бывш и й Sparta) , RI P E и Open D N S S EC (opendns s e c . o r g ) .

Инструменты ldns, nlnetlaЬs . nl/projects/ldns По словам сотруд н и ков ком пан и и N Lnet Labs, ldns это библиотека програм м для разработки и н струм ентов D N S , включающая примеры, демонстрирующие исполь­ зовани е этой библ иотеки. Эти и нструменты перечислен ы н иже вместе с кратки м описа-

Часть 11. Работа в сетях

582

нием каждого из них. Все они находятся в каталоге exaaple s , за искл ючением уrилиты dri l l , имеющей с вой собстве н н ы й каталог в дистрибуrивном пакете. Команды сопро­ вождаются справоч н ы м и стран и ца м и . Файл READМE , относящи йся к верхнему уровню иерархи и каталогов, содержит очен ь краткие инструкции по и нсталляции. •

ldns-chaos показывает идентификатор сервера имен, хранящийся в классе CHAOS.

ldns-compare-zones демонстрирует разницу между двумя файлам и зон .

ldns-dpa анализи рует пакеты D N S с помощью файлов слеже н ия tcpdwnp.

ldns-key2ds преобразовывает запись DN S S EC в запись D S .

ldns-keyfetcher извлекает открытые ключ и D N S S EC дл я зон .

ldns-keygen генерирует пары кл ючей TS I G и DNSSEC.

ldns-notify проверяет обномения подч и н е н н ы х серверов зон .

• •

ldns -nsecЗ -hash распечаты вает запись N S EC дл я задан ного и м е н и в хеширо­ ван ном виде. ldn s — read-zone читает зону и распечатывает ее в разн ых форматах. ldns -revoke устанавл и вает флаг отме н ы для кл юча RR в протоколе D N S S EC (см . документ RFC540 l l ). l dn s — rr s i g распечатывает в удобном для чте н и я виде даты истечения сроков действия ключе й из записей RRS I G .

ldn s — siqnzone подписывает файл зоны с записью N S E C ил и N S E C З .

ldns-update посылает пакет динамического обновления.

ldns -verify-zone проверяет состоя ние зап исей RRS I G , NSEC или N S E C З .

ldns -walk совершает обход зоны , испол ьзуя записи N S E C протокола D N S S EC.

ldns-zcat объединяет файлы зон, разбитые уrил итой ldns — z split на фрагменты.

ldn s — z split разбивает зону на фрагменты , чтобы подписывать их параллел ьно.

М ногие из этих и н струментов оче н ь п росты и выпол н я ют только одну рути нную — операцию для с исте м ы DNS. О н и был и написаны в качестве примеров испол ьзования библ иотеки ldns и демонстрируют, насколько простым становится код, когда библ иоте­ ка берет всю тяжелую работу на себя .

Инcmpyм eнm ы dnssec- tools . org Ком пл е кт и н струме н тов D N S S Ec-Tools создан на основе и нструментов сервера B I N D, предназнач е н н ы х для поддержки протокола D N S S EC, и включает в себя следу­ ющие команды. •

• •

dnspktflow отслеживает поток пакетов D N S в последовател ьности запросов и от­ ветов, перехваченных командой tcpdwnp, и создает диаграмму. donuts анализирует файлы зон в поисках ош ибок и несоответствий . donu t s d вы пол н я ет команду donu ts через о предел е н н ы е и нтервал ы вре м е н и и п редупреждает о проблемах. mapper отображает файл ы зон , де монстри руя защище н н ы е и незащ и ще н н ые фрагменты . rollerd, rollctl и roll ini t осуществляют автоматическую смену кл юч е й , ис­ пол ьзуя схему предварител ьной публ и кации для ключей ZSK и метод двойного подписания для кл ючей KS K.

Глава 1 6. DNS: система доменных имен

583

tru s tman управляет точ кам и доверия и включает реализаци ю с м е н ы клю•1е й RFC50 1 l .

validate

zonesigner ге нерирует ключи и подписи зон .

и нструмент для проверки подписи из командной строки .

Веб-сайт содержит хорошую документацию и учебные пособия для всех этих инстру­ ментов. И сходный код доступен для загрузки и защище н лицензией B S D .

Инструмен ты RIPE, ripe . net Инструменты ком пани и R I P E функционируют как внешн ий компонент инструме н ­ тов пакета B I N D , предназначен н ых для поддержки протокола D N S S EC , и ос новное вниман ие уделя ют вопросам управления. Их подробн ы е сообще н и я при выпол нен и и и упаковке многих аргументов и команд и меют более понятную форму.

Ин струмент ы Ор еп DNSSEC, opendnssec . org Open DN S S EC это набор инструментов, которые получают н еподписанные зо н ы , добавляют подписи и другие зап ис и для протокола D N SSEC, а затем передают их авто­ ритетны м серверам и м е н для этой зон ы . Эта автоматизация значительно упрощает на­ чальную настрой ку протокола DN S S EC . —

Отладка п ротокола DN SSEC Протокол D N S S EC был разработан для того, чтобы обеспечить взаимодействие меж­ ду подп исан н ы м и и неподписанными зонами, а также между серверами имен, поддер­ живающим и протокол D N S S EC и и гнорирующими его. Следовательно, возможно по­ степенное развертывание протокола, что часто и происходит, хотя и не всегда. D N S S EC это распределенная система с м ногочисленными изменчивыми частя м и . Все проблемы порождают авторитетн ые серверы , распознаватели клие нтов и л и н и и свя­ зей между н и м и . П роблема, которая кажется локал ьной , может отразиться на удаленном пользователе , поэтому такие инструменты , как SecSpideг и Yantages, отслежи ваю щие распределен ное состояние систе м ы , могут оказаться очень полезн ы м и . Эти и нструм е н ­ ты , а также утил иты , переч исле н н ые в ы ш е , и регистрацион н ы е файл ы ваше го сервера имен являются основными орудия м и отладки . Сначала убедитесь, что вы перенаправили категори ю вывода журнала регистрац и и по протоколу D N S S EC, указанную в файле named . conf, в файл н а локальном ком п ью­ тере. П олезно отдел ить все сообщения , связан ные с протоколом DN S S EC, чтобы не за­ писывать в этот файл никаких других категорий журнала регистрации . Рассмотри м при­ мер спецификации журнала регистрации для демона named. —

chann e l dn s s e c — l og { f i l e » / va r / l o g /name d / dns s e c . l o g » ve r s i on s 4 s i z e l Om p r i n t — t ime ye s print-category yes p r i n t — s e ve r i t y y e s s ev e r i t y debug 3 ; c a t e g o r y dn s s e c { dns s e c — l og ; }

В пакете B I N D следует установить уровень отладки равн ы м 3 ил и выше, чтобы уви­ деть этапы проверки , выполняемые рекурсивным сервером B I N D при попытках прове­ рить подпись. Этому уровню регистрации соответствуют две страницы регистрационной

Часть 11. Работа в сетях

584

и нформации для одной проверяе мой подписи . Есл и вы отслеживаете работу загружен ­ ного сервера, то регистрационная и н формация от нескольких запросов будет переме­ жаться другим и дан н ы м и . Разбираться в этой путанице — очен ь сложная и утомитель­ ная задача. Команда dri ll имеет два особен но полезных флага: — т — для отслеживания цепоч­ ки доверия от корн я до указанного хоста и -s для отслеживания подписей от ука­ зан ного хоста обратно к корню. Рассмотрим практический пример вывода, получ е н но ­ г о о т команды dri l l — S , позаимствованный из документа DNSSEC НО WТО компан и и N Lnet Labs. —

$ drill -s -k ksk . keyfile example . net SOA DNSSEC Trust t r e e : e x amp l e . n e t ( S OA ) 1 — — — e x amp l e . ne t . ( DN S K E Y k e y t a g : 1 7 0 0 0 ) 1 — — — e x amp l e . ne t . ( DN S KE Y k e y t a g : 4 9 6 5 6 ) 1 — — — e x amp l e . n e t . ( DS k e yt a g : 4 9 6 5 6 ) 1 — — — n e t . ( DN S K E Y KE YTAG : 6 2 9 7 2 ) 1 — — — ne t .

( DN S KE Y K E Y TAG : 1 3 4 6 7 ) ( DS KE YTAG : 1 3 4 6 7 ) 1 — — — . ( DN S KE Y KEYTAG : 6 3 3 8 0 ) 1 — — — n e t . ( DN S KE Y KEYTAG : 6 3 2 7 6 )

1 — —net .

;;

Cha s e s ucce s s fu l

Есл и сервер и м е н , выполняющий проверку, н е м ожет проверить подпись, о н воз­ вращает с игнал SERVFA I L . Проблема может заключаться в неправил ьной конфигурации одной из зон , входящих в цепочку доверия , в фальшивых данных, поступивших от зло­ умы шленн и ка, или в настройке самого рекурси вного сервера, выполняющего проверку. Попробуйте выпол нить команду dr i l l и отследить подписи вдол ь цепочки довери я , чтобы обнаружить источн и к проблемы. Если все подписи окажутся верифицирован н ы м и , то попытайтесь послать запрос проблем ному сайту с помощью команды dig, а затем dig +cd. (Флаг cd откл ючает про­ верку подписей . ) Примените их к каждой зоне , входящей в цепочку доверия , чтобы вы­ ясн ить, в ч е м проблема. Вы можете пере мещаться по цепочке доверия как вверх, так и вниз. Чаще всего причиной ошибки становятся устаревшие точк и доверия или про­ сроченные подписи.

1 6. 1 1 . ОТЛАДКА СЕРВЕРА B I N D Сервер B I N D предоставляет три основны х инструмента для отладки: журнальная ре­ гистрация, управляющая программа и инструмент запросов их командной строки .

Журнал ьная регистрация на сервере B I N D Ш Система Syslog описывается в главе 1 О . Возможности подсисте м ы журнал ьной регистрации де мона named действительно впечатляют. Сервер B I N D и спол ьзует систе му Syslog для записи сообще н и й об ошиб­ ках и аномал иях. В новей ш их версиях кон цепция журнальной регистрации обобщена: добавлен еще оди н уровень переадресации и поддерживается направление сообщений непосредствен н о в файлы . Прежде ч е м переходить к деталя м , приведем м и н и — словарь терминов, связан ных с журнальной регистрацией в пакете B I N D (табл . 1 6. 7 ) .

Глава 1 6. DNS: система доменных имен

585

Таблица 1 6 .7. Лексикон пакета BIND Термин

Ч то означает

Канал

Место, куда направляются сообщения, — система Syslog, файл или устройство /dev/null»

Категория Класс сообщений, генерируемых демоном named, например сообщения о динамических об­ новлениях или об ответах на запросы Модуль

Имя исходного модуля, который сгенерировал сообщение

Средство

Название средства системы Syslog; за DNS не закреплено собственное средство, но можно выбрать любое стандартное

Важность

Степень важности сообщения об ошибке

‘ /dev/null/

псевдоустройство, отбрасывающее всю входящую информацию.

Подсисте ма жур нальной регистрации конфигурируется при помощи и нструкц и и log g i n g в файле named . conf. Сначала определяются каналы — возможные пункты до­ ставки сообще н и й . Затем для различных категор и й сообщен и й задаются канал ы , куда они будут поступать. При форм ирова н и и сообщения ему назначаются категория, модуль и уровен ь важ­ ности. П осле этого оно рассылается по всем с вяза н н ы м с категори е й и модул е м ка­ налам . В каждом канале и меется фильтр , определяющ и й , сообщения какого уровня важности можно пропускать. Канал ы , ведущи е в систему Syslog, подвергаются допол­ н ител ьной фил ьтрац и и в соответствии с правилами , установлен н ы м и в файле /etc/ syslog . conf. Общий вид инструкции l o g g i ng таков. l ogging { определение_ канала определение_ ка нала c a t e g o r y имя_ ка тегории имя ка нала имя ка нала

}; };

Каналы Аргумент о пределение_ к а нала выглядит по-разному, в зависимости от того, ве­ дет он к файлу или к системе Syslog. Для каждого канала н еобходимо выбрать либо тип f i l e , л ибо тип s y s l og ; совмещать их канал не может. chann e l имя_ канала { f i l e путь [ ve r s i o n s число_ в ер сий 1 s y s l o g средс тв о ; s e ve r i t y в ажнос ть ; no; print-category yes

u n l i mi t e d )

[ s i z e ра змер ) ;

no; p r i n t — s e ve r i t y y e s p r i n t — t i me y e s 1 n o ;

};

Для файлового канала аргумент число_ в ер сий сообщает о том , с кол ько резервных копи й файла нужно хранить. Аргумент ра змер задает предельно допустим ы й размер файла (например, 2 0 4 8 , l O O k , 2 0rn, 1 5 g , u n l i rn i t e d , de f a u l t ) , по достижен и и кото-

Часть 11. Работа в сетях

586

рого произойдет автоматическая ротация . К примеру, если файловый канал называется mylog, то в п роцессе ротации появятся верси и mylog . О, mylog . 1 и т.д. Для каналов системы Syslog задается имя средства, указываемое при регистрации со­ обще ний. Это может быть л юбое стандартное средство, но на практике единствен н ы м разумн ы м выбором являются средства da emon и l o c a l O — l o c a l 7 . m Список средств системы Syslog при водился в главе 1 0. Остальные раздел ы в определ е н и и канала я вля ются необязател ь н ы м и . Аргумент может при н и мать сл едующие значения ( в порядке уме н ьш е н ия приорите­ та) : c r i t i c a l , e r r o r , wa r n i n g , n o t i c e , i n f o и d e b u g (здесь может добавляться но­ мер уровн я , например s e ve r i ty debug 3). З начен ие dynami c соответствует текущему уровню отладки сервера. П араметры p r i n t устанавл и вают ил и отм е н я ют вы вод разл и ч н ых префи ксов со­ общени й . С истема Syslog вставляет перед каждым сообщением метку времени , а также и м я хоста, но не урове н ь важности ил и категорию. Существует также параметр , по­ зволяющ и й отображать имя исходного файла (модуля) , сгенерировавшего сообщение. П араметр p r i n t — t ime рекомендуется вкл ючать только для файловых каналов, посколь­ ку в Syslog произойдет ненужное дубл ирование и нформации. В табл 16.8 перечислен ы четы ре канала, которые определены по умолчанию. В бол ь­ ш инстве случаев создавать новые канал ы не требуется. в а жно с т ь

.

Табли ца 1 6 .8. Станда ртнь1е каналы журнальной регистрации пакета BIND Имя канала

Назначение

de f a u l t _ s y s l o g

Направляет соо б щ ениs� уровнs� i n f o и выше в систему Syslog от имени средства da emon

de f а ul t _ debug

Направляет соо б щ ениs� в файл named . run; уровень важности устанавливаетсs� равным dyn ami c

defaul t stderr

Направляет соо б щ ениs� в стандартный канал ошибок демона named с уровнем важности i n f о

null

Отб расывает все сообщения

Категории В момент создан ия програ м м ы категори и определя ются програ м мистом . Они орга­ н изовывают сообщен ия по темам или функциональным возможностя м , а н е по важно­ сти. В табл . 1 6 . 9 п р и веде н текущий список категори й сообще н и й . Таблица 1 6 . 9 . Катего р ии сообщений пакета BIND Категория

Что ох11ты1 ает

client

Клиентские запросы

c on f i g

Оши б ки анализа и обработки конфигурационного файла

d a t ab a s e

Сообщения о б операциs�х с базой данных

de f au l t

Категории, для кото ры х не был явно назначен канал

de l e ga t i on — on l y Запросы , посланные в NXDOMAI N зонами, выполняющими только делегирование d i s p a t ch

Диспетчеризация входs�щих пакетов среди модулей сервера

dns s e c

Соо б щения протокола DNSSEC

e dn s — d i s aЫ e d

И нформация о с е рверах, вышедших из строя

Глава 1 6. DNS: система доменных имен

587

Окнчание табл. 16.9

Категория

Что охватывает

gene r a l

Неклассифицированные сообщения

l ame — s e rve r s

Сообщения о серверах, которые, как предполагается , обслуживают зону, но на самом деле зто не так •

netwo r k

Сетевые операции

not i f y

Сообщения об изменениях зон

que r i e s

Короткое сообщение для каждого ( ! ) запроса, принимаемого сервером

r e s o lve r

Операции преобразования имен, например рекурсивный поиск, выполняемый от имени клиента

securi t y

Принятые или непринятые запросы

unma t c h e d

Запросы, которые демон named не может классифицировать (неправильный класс, нет представлени я )

upd a t e

Сообщения о динамических обновлениях

upda t e — s e c u ri ty Одобрение или отклонение запросов на обновление xfer-in Сообщения о передачах зон , принимаемых сервером x f e r — ou t

Сообщения о передачах зон , отправляемых сервером

0Это может быть как родительская, так и дочерняя зона.

Журнал запросов Стандартный вид инструкции l o g g i ng таков. logging { c a t e g o r y de f a u l t ( d e f au l t _ s y s l o g ; d e f a u l t debug ; )

;

);

После внесе н ия существе н н ых изме н е н и й в с истем у B I N D необходимо просматри­ вать журнальные файл ы ; возможно, стоит также повышать уровен ь отладки . После того как демон named вернется в стабил ьное состоян и е, н астройте систем у так , чтобы реги­ стрировал ись только важн ые сообще ния. Журн ал запросов — источ н и к весьма полезной и нформации . Н а его ос нова н и и мож­ но проверить, работают ли директи вы a l l ow , узнать, кто посылает вам запросы , иде н ­ тифицировать неправил ьно сконфигурированные клиенты и т.д. Для того чтобы включить режим регистрации запросов, назначьте категории que r i e s какой-нибудь канал. Регистрация в системе Syslog менее эффективна, ч е м непосредствен ­ но в файле, поэтому при регистрации каждого запроса создайте файловый канал , связан­ ный с локальным диском. Зарезервируйте для журнала достаточно дискового простран­ ства и будьте готовы отключить регистрацию, когда накопится достаточный объем данных (команда rndc querylog включает и откл ючает регистрацию запросов) . И ногда отладка представления является довол ьно сложной задачей, но, к счастью , представление, соответствующее кон кретному запросу, можно занести в журнал вместе с запросом . Н иже переч ислен ы наиболее часто регистрируемые сообщения. •

Неправильно сконфигурированный сервер ( » Lame se rver resolving ххх » ) . Есл и по­ добное сообщение поступает от одной и з внутре нних зон , значит, в конфигура­ ции систе м ы и меется ошибка. Если же в сообще н и и говорится о какой-то зоне в И нтернете , то можно не беспокоиться : это «чужая » ошибка. Сообщения второго вида вполне можно отбрас ывать, направляя их в канал nu l l .

Часть 11. Работа в сетях

588 •

Отклонение запроса ( » » . query (cache) ххх denied» ) . Прич иной этого сообщения мо­ жет быть неправильная конфигурация удален ного сайта, нарушение правил или ситуаци я , в которой некто делегировал вам зону, но вы ее не конфигурировал и . Просроченное время при распознавании: отключение EDNS ( » too many timeouts resolving ххх: disaЫing EDN S » ) . Это сообщение может возникнуть вследствие от­ каза брандмауэра, не пропус кающего пакеты U D P, размер которых превы шает 5 1 2 байт, и не допускающего фрагментирование. Кроме того, оно может свиде ­ тельствовать о проблемах на кон кретном хаете . Следует убедиться , что проблема не связана с ваш и м брандмауэром , и рассмотреть возможность переадресац и и этих сообщен и й в н улевой канал . Неожиданное распознавание RCODE (SER VFA IL) ( » unexpected RCO D E ( S EVFAI L) resolving ххх » ) . Это сообщен и е может быть призн аком атак и ил и , что более ве­ роятно, сигналом о том , что кто-то постоянно посылает запросы к неправильно сконфигурированной зоне. Неправильная отсылка ( » Bad referral» ) . Это сообщение свидетельствует о непра­ вильном взаимодействии серверов имен зоны . Неавторитетен ( » Not authoritative for » ) . П одч и н е н н ы й сервер не может получ ить авторитетны е данн ы е о зоне . Возможно, у него хран ится н е правил ь н ы й адрес главного сервера или же тот не смог загрузить зону. Зона отклонена ( » Zone rejected » ) . Демон named отказался загружать файл зон ы , поскольку тот содержит ошибки. Не найдены записи NS ( » No NS RR for»). В файле зон ы после записи S OA не найде н ы записи N S . Возможно, они отсутствуют либо не нач инаются с табуляции ил и како­ го- н ибудь другого пробельного символа. Во втором случае они не присоединяются к зоне и, следовательно, интерпретируются неправильно. Не задано стандартное значение TTL ( » N o default ТТ L set » ) . Желательно задавать стандартное значение TTL посредством директивы $ T T L , располагаемой в нача­ ле файла зон ы . Ош ибка свидетел ьствует о том , что такая директива отсутствует. В верс и и B I N D 9 нал и ч ие этой директивы обязательно. Нет корневых серверов имен для класса ( » N o root nameservers for class » ) . Демону named н е удается найти корневые серверы имен. Следует проверить файл корне­ вых » подсказок» и подключение сервера к И н тернету. Адрес уже используется ( «Address already in use » ) . П орт, которы й нужен для работы демона named, занят другим процессом , возможно, другой копией демона. Если де­ мон отсутствует в списке выполняющихся процессов, то, очевидно, он перед эти м аварийно заверш ил свою работу и оставил открытым управляющий сокет утилиты rndc , которы й нужно найти и удалить. Хороший с пособ устран ить проблему остановить процесс с помощью утилиты rndc и перезапустить процесс named. $ sudo rndc s top $ sudo /usr/ sЬin/named . . .

Обновление не выполнено ( » » . updating zone ххх: update unsuccessful » ) . И м ела место попытка динамического обновлен и я зон ы , которая была отвергнута вследствие установки a l l ow- upda t e или upda t e — po l i c y для зоны в файле named . conf. Это оче н ь распространенное сообщение об ошибке , которая часто вызывается н епра­ вильной конфигурацией систем ы Windows.

Глава 1 6. DNS: система доменных имен

589

Пример конфигурации журнала запросов в пакете BIND Пр иведе н н ы й н иже фрагмент взят из файла named . conf одного из загружен н ых сер­ веров имен TLD и представляет собой полную конфигурацию журнала запросов. logging channe l d e f a u l t_l o g { # D e f a u l t channe l , t o а f i l e f i l e » l o g / n amed . l o g » ve r s i on s 3 s i z e l Om ; p r i n t — t ime ye s ; p r i n t — ca t e g o r y ye s ; p r i n t — s e ve r i t y ye s ; s eve r i t y i n f o ; }; c h a n n e l x fe r — l o g { # Z one t r a n s f e r s channe l , to а f i l e f i l e » l o g / x f e r . l o g » ve r s i o n s 3 s i z e l Om ; p r i n t — t ime ye s ; p r i n t — c a t e g o r y ye s ; p r i nt — s eve r i t y ye s ; s e ve r i t y i n fo ; }; c h a n n e l dn s s e c — l o g { # DN S S E C channe l , to а f i l e f i l e » l o g / d n s s e c . l o g » ve r s i on s 3 s i z e l Om ; s eve r i t y d e b u g 1 ; p r i n t — s e ve r i t y ye s ; p r i nt — t ime ye s ; }; c a t e g o r y d e f a u l t { de f a u l t_l o g ; d e f a u l a_debu g ; c a t e g o r y dn s s e c { dns s e c — l o g ; } c a t e g o r y x f e r — i n { x fe r — l o g ; } category x fe r-out { x fe r — log ; } category not i f y { x f e r — l o g ; } };

Уровни отла д ки в пакете BIND Уров н и отладки демона named обозначаются цел ы м и ч ислами от О до 1 00. Чем выше число, тем бол ьше текста содержит выходная информация. Уровен ь О выкл ючает отлад­ ку. Уровни 1 и 2 отлично подходят для отладки конфигурационного файла и базы дан ­ ных. Уровни выше 4 предназначен ы для разработчи ков кода демона. Отладку можно вкл юч ить из командной строки , запус кая демон named с флагом -d. Например, команда # sudo named — d2

запускает демон named на уровне отладки 2. По умолчани ю отладочная информация за­ писывается в файл named . run, находящийся в каталоге запуска демона. Этот файл рас­ тет очень быстро, поэтому во врем я отладки будьте внимательны. Отладку можно также вкл ючать в процессе работы демона named с помощью ко­ манды rndc trace , которая увели ч и вает уровен ь отладки на един ицу. Команда rndc notrace выкл ючает режим отладки. Кроме того, можно создать канал регистрации со­ обще н и й , в определение которого входит строка следующего вида. s e ve r i t y debug 3 ;

Эта строка обеспечивает направление в канал всех отладочн ых сообщен и й вплоть до уровня 3. Другие директивы в определении канала указывают на то, куда в конечном

Часть 11. Работа в сетях

590

итоге попадут сообщен ия . Чем выше уровен ь важности , тем больше информации реги­ стрируется. П росм атривая журнал ьн ы е файлы и отладочн ы е сообщен и я , можно заметить, как часто делаются ошибки в конфигурации D N S . Забыв поставить точку в конце имен и , можно спровоцировать угрожающий рост трафи ка DNS. П о м н ите : точка нужна в конце каждого полностью определе нного имени домена.

Управление сервером имен с помощь ю команды rndc Опции команды rndc перечисл е н ы в табл . 1 6. 1 О. Если ввести имя команды rndc без аргуме нтов, то она выведет на экран с писок доступных подкоманд и их краткое описа­ н ие . В предыдущих версиях программы rndc испол ьзовались сигнал ы . Однако количе­ ство доступн ы х подкоманд уже » перевалило» за 2 5 , поэтому разработчики пакета B I N D отказались от испол ьзования с игналов. П одкоманды, приводящие к созданию файлов, размещают их в каталоге , указанном в файле named . conf как начал ь н ы й каталог демо­ на named. Таблица 1 6 . 1 О. Опции команды rndc8 Инструкция

Назначение

duшpdЬ

Записывает образ базы данных DNS в файл named_duшp . dЬ

flush (представление]

Очищает все кеши или кеши, заданные предста влением

flushname имя [предста вление)

Удаляет имя из кеша сервера

freeze зона [кла сс [предс та вление]]

Приостанавливает обновления динамической зоны

thaw зона [кла сс [представление]]

Возобновляет обновления динамической зоны

halt

Останавливает демон named без обработки отложенных обновлений

querylog

Переключает режим трассировки входящих запросов

notify зона (кла сс [предста вление]]

Повторно посылает з оне уведомления

notrace

Отключает режим отладки

reconf ig

Повторно загружает конфигурационный файл и все новые зоны

recursing

Записывает текущие рекурсивные запросы в файл named . recursing

refresh з она [кла сс (предста вление]]

Планирует обновления для зоны

reload

Повторно загружает файл named . conf и файлы зон

reload зона [кла сс [предста вление]]

Повторно загружает только указанную зону или предста вление

retransfer зона [кла сс [предста вление]]

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

s tats

Записывает статистическую информацию в файл named . s tats

s tatus

Отображает на экране текущий статус выполнения демона named

stop

Сохраняет отложенные обновления и останавливает демон named

Глава 1 6. DNS: система доменных имен

591

Окончание табл. 1 6. 1 0

И нструкция trace

Назнач ение

Увел и ч и вает уровень отладки на единицу

trace приращение

Увел и чивает уровень отладки на приращение

validation новое сос тояние

Включает/отключает проверку DNSSEC на лету

• Аргумент кла с с означает то же , что и в случае записей о ресурсах; для И нте р н ета он обычно равен

IN.

Команда rndc rel oad заставляет де мон named за ново прочитать кон ф и гураци ­ онный файл и повторно загрузить файлы зон . Команду rel oad з о на удобн о п р и м е ­ нять н а и нтенсивно эксплуатируе м о м сервере , когда и зм е н е н и ю подвергается тол ь ­ ко одн а зон а , а остал ь н ы е трогать н е н ужно. Кром е того, м о ж н о задать параметр ы кла с с и пр ед с т а в л е ние, чтобы загрузить тол ько указанно е представл е н и е дан н ых зон ы . Обратите внимание на то , что команды rndc re l oad недостаточно, чтобы доба­ вить совершенно новую зону; для этого требуется , чтобы дем о н named проч итал файл named . conf и новый файл зон ы . Для новых зон следует ис пол ьзовать команду rndc reconfig, которая заново прочитывает файл конфи гурации и загружает л юбую новую зону, не трогая суrnествующие. Команда rndc free ze з о на останавл и вает дин а м и ч ес к и е обновлен и я и согласо­ вывает журнал динам ических обновлени й с файлами зон . После замораживания зон ы ее дан н ы е можно редактировать вруч ную. Поскол ьку зон а заморожена, динам ическое обновление происходить не будет. Завершив редактировани е , выпол ните команду rndc thaw зона , чтобы принимать динамические обновл е н и я снова . Команда rndc dumpdЬ заставляет демон named записать образ с воей базы данн ых в файл named dump . dЬ. Этот файл оче н ь бол ьшой и содержит не толь ко локальные дан­ ные, но и дан н ы е , накопл е н н ые в кеше сервера имен. Верси и демона named и программы rndc должны со1шадать, иначе будет выдано со­ общен ие о н есовпаден и и верси й протокола. Обычно они устанавл иваются на оди н и тот же комп ьютер, и расхождение верси й может вызвать проблем ы , есл и поп ытаться управ­ лять демоном named, запущен ном на другом ком пьютере . _

Н екорректное делегирование Подавая зая вку на ре гистрацию дом е н ного и м е н и , в ы просите , чтобы основному серверу имен и адм и н истратору D N S была выделена (деле гирована) часть дерева и м е н . Есл и не поддерживать работу дом ена или изм е н ить адреса серверов и м е н , не обновив связующие записи родительского домена, будет иметь место так называемое некоррект ­ ное делегирование (lame delegation) . Последствия не корректного дел е гирования могут оказаться весьма н е гатив н ы м и Есл и хотя бы оди н из ваш и х серверов окажется н е к орре к тн ы м то вся ваш а с истема D N S с н изит эффе кти вность работ ы . Есл и все сер в ер ы имен я вл я ются н е коррект­ н ы м и , то ни оди н из них н е будет доступе н . Все за п росы будут н а ч и н аться с кор­ ня, пока ответы будут кешироваться , поэтом у н е корре кт н ые серверы и н е ис п равное прогр а м м ное обес п е че н ие , которое не делает н е гат и в н о го к е ш ир о ва н и я о ш и бок S E R V FA I L , увел и ч и вают нагрузку н а кажд ы й хост, н ах одящ и й с я н а пути от корн я к н е корре ктному дом е н у. Н екорректное делегирование можно обнаружить с помощью и нструмента под назва­ нием doc (domain obscenity cont rol — проверка корр е кт н ост и домена) л ибо путе м н е .

,

Часть 11. Работа в сетях

592

посредствен ного просмотра записей из журнальн ых файлов. 26 Рассмотрим пример реги­ страционных зап исей. Jul 19 1 4 : 3 7 : 5 0 nuba r k n aтed [ 7 5 7 ] : l ате s e rve r r e s o l v i n g ‘ w3 w 3 . c oт ‘ ( i n ‘ w3 w 3 . c oт ‘ ? ) : 2 1 6 . 1 1 7 . 1 3 1 . 5 2 # 5 3

Послав с помощью команды dig запрос о серверах имен дл я домена w З w З . сот одно­ му из серверов gТLD-домена . с от, м ы получим следующую и н формацию. $ d.ig @ e . gtld-servers . net wЗwЗ . com ns

; ; AN SWER S E CT I ON : w3w3 . coт 172800 w3w3 . coт 172800

IN IN

NS NS

n s O . naтe s e rv i c e s . ne t . n s l . naтe s e r v i c e s . ne t .

Если же теперь опрос ить каждый из этих серверов по очереди, задав им этот же во­ прос , то мы получи м ответ от сервера n s O и не получ им ответа от сервера n s l . $ d.ig @ nsO . nameservices . net wЗwЗ . com ns

; ; AN SWER S E C T I ON : w3w3 . coт 1 4 4 0 0 IN w3w3 . coт 1 4 4 0 0 IN

NS NS

n s O . naтe s e rv i ce s . ne t . n s l . n aтe s e rv i ce s . ne t .

$ d.ig @ nsl . nameservices . net w3w3 . com ns

, , QUE S T I ON S E C T I ON : IN IN , , w3w3 . coт . , , AUTHOR I T Y RECORDS : 9 2 1 5 2 IN N S с от . 92 1 52 IN NS с от . 9 2 1 5 2 I N NS с от .

M . GTL D — S E RVER S . NET . I . GT L D- S E RVERS . N ET . E . G T L D — S ERVERS . NET .

Сервер имен n s l . naтe s e rv i c e s . n e t делегировал ответстве нность за доме н w З w З . с от серверам домена . с от, но они эту ответствен ность не принял и . Эта конфигурация является неправил ьной, и возникло н екорректное деле гирование. Клие нты , пытающи­ еся попасть в дом е н w З w З . с от, будут обслуживаться медленно. Если домен w З w З . с от оплачи вает услуги D N S домену naтe s e rv i c e s . n e t , то он заслуживает ком пенсации! И ногда, посылая запрос с помощью команды dig на авторитетн ы й сервер в поисках некорректности , можно не получ ить н и какой и нформации . В этом случае следует по­ пытаться повторить запрос с флагом +norecurse, чтобы можно было увидеть точно, что знает искомый сервер.

1 6. 1 2 . ЛИТЕРАТУРА Система доменных имен и пакет B I N D описаны во многих источ н и ках, включая до­ куме нтацию, входящую в состав пакета, отдел ьные главы в книгах об И нтернете , целую кн и гу серии ln а Nutshell издател ьства O ‘ Reilly, а также м ногочисленные ресурсы в гло­ бал ьной сети .

2680 м ногих орга н изациях в качестве канала l aтe — s e rve r s для журналов ре гистрации указан ка­ талог /dev/null , чтобы не беспокоиться о некорректном делегировании други х доменов, не при ­ надлежащих этой орга н изаци и . Это допусти мо, если ваш домен н аходится в полном порядке и не является н и источ н и ком , н и жертвой некорректного делегирова н и я .

Глава 1 6. DNS: система доменных имен

593

К н иги и другая документация •

Т н Е Noм 1 N U M B I N D D EVELOPMENT ТЕАМ . BINDv9 Admin istrator Reference Manual. Документ включен в дистрибутив B I N D (doc/arm) , а также доступен на веб-сайте www . i s c . o r g . В нем в общих чертах описаны при н ц и п ы админ истрирования па­ кета B I N D 9.

Lщ СR 1 скЕт , AND Pлu L АLвпz. DNS and В/ND (5th Edition) . Sebastopo , СА: O ‘ Reilly Media, 2006 . Эта к н и га стала настол ьн ы м справочн и ком по серверу B I N D , хотя и написана довольно тяжелы м языком.

Lщ CRICKET. DNS & В/ND Cookbook. Sebastopo , СА: O ‘ Rei l l y Media, 200 2 . Это упрощен ная версия книги издательства O ‘ Reilly о с истеме D N S , содержащая чет­ кие инструкции и примеры работы с серверами и ме н . Довольно старая , но все еще полезная .

Lщ СR1скп. DNS and В/ND оп !Рvб. Sebastopol, СА: O ‘ Reilly M edia, 20 1 1 . Кни га ориентирована на D N S и B I N D в рамках протокола I Pvб. Она невелика и содер­ жит искл ючительно м атериал, связанн ы й с протоколом I Pvб.

Lucлs, М 1снлн W DNSSEC Mastery: Securing the Domain Name System with BJND. Grosse Point Woods, M I : 1ilted Windmill Press, 20 1 3 .

Рес урсы в И нтернете Веб-сайты i s c . o r g , dn s — o a r c . n e t , r i pe . ne t , n l n e t l ab s . n l , f . ro o t — s e rve r s . org и k . r o o t — s e rve r s . o r g содержат м ного и нформации о системе D N S , исследовани ­ ях, результатах измере н и й , презентациях и др. Подробная и нформация о п ротоколе DN S , записях о ресурсах и других асп е ктах DNS приведена на сайте i a na . o rg / a s s i g nme n t s / d n s — p a rame t e r s . Этот документ со­ держит и н формацию о том , в каком документе RFC описан тот или иной факт, касаю­ щийся работы с истем ы D N S . Справо ч н и к DNSSEC НО WТО, написан н ы й Олафом Колкманом (Oaf Kolkman), это 70-страничный документ, в котором изложен ы все асп е кты разверты вания и отлад­ ки протокола D N S S EC . Его можно загрузить с сайта n l n e t l a b s . n l / d n s s e c _ h o wt o / dns s e c howt o . pd f . —

Доку менты RFC Документы RFC, в которых описывается система доме н н ых и ме н , доступны на веб­ сайте www . r f c — e d i t o r . o r g . Мы использовали только сам ы е важные из н их, хотя в на­ стоя щее вре м я есть около 1 00 документов и около 5 0 черновиков, опубл и кова н н ы х в И нтернете , поэтому рекомендуем читателям зайти на сайт www . r f c — e d i t o r . o r g и из­ учить весь архив. Для того чтобы увидеть все документы , касающиеся текущей верси и B I N D , найдите каталоги doc/ rfc и doc/draft.

Глава

17

Система единого входа

П ол ьзовател и и с и с те м н ые адм и н и с трато р ы хотел и бы , чтоб ы и н фор м а ц и я об учетно й записи вол ш е б н ы м образом распространял ас ь н а все ком п ьютер ы сети и пользовател ь мог войти в л юбую с истем у с оди н аковы м и учетн ы м и дан н ы м и . Эта фун кция назы вается » еди н ы м входом » ( s i ngle sing-on — S S O ) и потреб ность в н е й повсеместна. SSO вкл юч ает в себя две основные кон це п ц и и безопас н ости : идентифи ка ц и о н ­ ную и н формацию и ауте нтификаци ю . Иде нтификационная и н формация пол ьзовате­ ля — это абстрактное п редставл е н и е л и ца , которому необходим доступ к с истеме или приложен и ю . Обычно она вкл ючает такие атрибуты , как и м я пол ьзователя , парол ь , идентификатор пользователя и адрес эле ктронной почты . Ауте нтификация — это до­ казательство того, что л и цо я вляется закон н ы м владельцем иде нтификационной и н ­ формации . В этой главе основное в н и м а н и е уделя ется с истем е S S O как компонен ту с истем U N I X и Linux в рам ках единой орга низац и и . Для еди ного входа в нескольких орга н и ­ зациях ( которы й , например, может потребоваться для и нтеграции ваш их систем и си­ стем поставщика програм м ного обеспече н и я в рамках модели обслуж и ва н и я » про­ гра м мн ое обеспечение как услуга» ( Software -as-a-Se rvice — SaaS)) доступны несколько реш е н и й на основе стандартов и ком мерческих решен и й SSO. В этих случаях в каче­ стве первого шага м ы р е комендуем изуч ить язык Security Assertion M arkup Language ( SAM L) .

Часть 11. Работа в сетях

596

1 7 1 Основные ЭЛЕМЕНТЫ СИСТЕМЫ ЕДИНОГО ВХОДА .

.

Хотя существует м ножество с пособов создан и я еди ного входа , в каждом сценар и и обычно требуется четыре элемента. •

Централ изован ное хра н ил и ще катал огов , которое содержит идентификацион ­ ные дан ные пол ьзователя и и нформацию авторизации. Наиболее распространен­ ными ре ш е н и я м и явл я ются службы каталогов, основа н н ые на протоколе L DA P ( Lightweight Directory Access Protocol) . В средах, в которых сочетаются систе м ы Windows, U N IX и Linux, хорош им выбором явл яется популярная служба M icrosoft Active Directory, включающая н астраи ваем ы й , нестандартный интерфейс LDAP. И нстру м е н т для управл е н и я и нформацией пол ьзователя в каталоге. Для соб­ стве н н ых реал изаций LDAP м ы рекоме ндуе м php L DAPadmin ил и Apache Directory Studio. Оба являются простыми в испол ьзовании неб-инструментами, которые по­ звол я ют и м портировать, добавлять, изменять и удалять записи в каталоге. Есл и вы я вляетес ь приверженцем службы M icrosoft Active Directory, то для управления информацией в каталоге вы можете использовать и нтегрируе м ы й модуль Windows «Active Directory Users and Computers » . Механизм аутентификации иде нтификационной и нформации пол ьзователе й . Вы можете аутентифицировать пол ьзователей не посредствен но в хран ил и ще L DAP, но помимо этого часто испол ьзуется система ауте нтификации на основе манда­ тов на основе протокола Kerberos, первоначал ьно разработанная в М IТ. 1 В средах Windows Active Directory предоставляет доступ L DAP к идентификаторам пол ьзо­ вателей и использует настраиваемую версию KerЬeros для аутентификации. Аутентификация в современных с истемах U N IX и Linux вы полняется с истемой PluggaЫe Authentication Module, также известной как РАМ . Для агрегирования досту­ па к службам идентификации и аутентификации пользователя вы можете испол ьзо­ вать демон System Security Service Daemon (sssd) , а затем указать РАМ в sssd. Библ иотеки подпрограмм на языке С для централ и зованной идентификаци и и ау­ тентиф и кации, которые ищут пол ьзовател ьские атрибуты. Эти утилиты (напри­ мер, ge tpwent) тради ционно ч итают обы ч н ы е файлы , такие как / e tc/pas swd и /etc/group, и отвечают на запросы, основываяс ь на их содержании. В настоя ­ щее время источники дан н ых настраиваются в файле переключения службы и м е н , /etc/ns swi tch . conf.

На рис. 1 7 . 1 показан ы отношения высокого уровня между разл и чн ы м и компонен ­ там и SSO в тип ичной конфиrураци и . В этом при мере в качестве сервера каталогов ис­ пол ьзуется Act ive Directory. Обратите внимание на то, что как вре м е н ная с и н хрон иза­ ция ( NTP) , так и отображе ние имен хостов ( DN S ) имеют решающее значение для сред , испол ьзующих Kerberos, поскол ьку мандаты ауте нтификации имеют времен н ые метки и огран ичен н ы й срок действия . В этой главе м ы рассмотри м ос новные кон цеп ц и и систе м ы L DA P и п редстави м два кон кретных LDAP-cepвepa для систем U N IX и Linux. Зате м м ы обсудим шаги , н е ­ обходимые для того, чтобы маш и н а использовала централизованную службу каталогов для обработки авторизации. 1 Сообщество специалистов по системам безопасности дел ится на тех, кто считает, что наилучшую зашиту ауте нтификации обес печ и вает служба L DA P, и сторо н н и ков протокола Kerberos. Дорога жизн и усея на расплюще н н ы м и бел кам и , которые не могли сделать вы бор. Выберите свой вариант и не огляды вайтес ь назад.

Глава 1 7. Система единого входа

597

Локальная система login, getty, оконный сервер

Провайдер идентификации nss_sss

Внешние серверы ntpd Связующее звено LDAP

Библиотека C getpwent() getpwnam()

PAM

sssd Связующее звено Kerberos

Сервер NTP

Сервер Active Directory

pam_sss

Провайдер аутентификации Распознаватель DNS

Сервер DNS

Рис. 1 7. 1. Компоненты SSO

1 7 2 LDAP: 11 0БЛЕГЧЕННЫЕ » СЛУЖБЫ КАТАЛОГОВ .

.

Служба каталогов — это просто база данных, но такая , в которой сделан ряд допол­ н ительных предположен и й . Л юбой набор дан н ых, характеристики которых подпадают под эти предположения , становится кандидатом на вкл ючен ие в базу дан н ых. Основные предположен и я таковы: •

информационные объекты относительно невелики;

база данных будет реплицироваться и кеш ироваться н а множестве ком пьютеров;

у информации есть атрибуты ;

дан н ые извлекаются часто, но зап ис ьшаются редко;

операции поиска выпол н я ются оч е н ь часто.

Текущая стандартная система, пред.11 ожен ная орган изацией I ETF д.11 я этих целей, на­ зывается L DA P ( Lightweight Di rectory Access Protocol — упроще н н ы й протокол доступа к каталога м ) . 2 И значально L DA P задумывался как простой шл юзовой протокол , кото ­ рый позволял бы клиентам TC P/ I P взаимодействовать с серверами каталогов Х.500, те­ перь уже устаревш и м и . Н аиболее распространенной реал изацией протокола L DAP я вля ется служба Active Directory ком п а н и и M icrosoft . М ногие орга н и зации испол ьзуют эту службу д.11 я аутен ­ тификации как в системе Windows, так и в системах U N IX и Linux. Для таких организа­ ций стандартной реал изацие й стал пакет Ope n L DA P (ope n l d a p . o r g ) . Служба катало­ гов уровня предприяти я , остроумно названная 389 Directory Server (ранее известная как Fedora Directory Server и N etscape Directory Server) , также является прое ктом с открытым исходным кодо м , к которому можно получ ить доступ н а сайте p o r t 3 8 9 . o r g . 3

Особен ности LDAP Для уверен ной работы с L DA P вам нужен хотя бы небольшой опыт. П ротокол LDAP сам по себе н е решает какую-л ибо адм и н истрати вную проблему. Нет какой-то «‘ глав­ ной задач и » , которую можно было бы реш ить искл ючительно с помощью LDAP; к тому 2 Как это ни парадоксально, но протокол L DA P можно н а зва т ь ка к и м угодно, но только не упро­ щенн ы м . ‘ТС Р-порт 3 8 9 я вляется портом по умолчан и ю для всех реал изаций протокола L DAP.

Часть 11. Работа в сетях

598

же на разн ых сайтах по-разному подходят к необходимости развертыва н и я серверов LDA P. Поэтому прежде чем перейти к особенностям инсталляции и конфигурирован ия Ope n L DAP, поговори м о том , в каких случаях целесообразно испол ьзовать LDAP. •

L DA P можно испол ьзовать в качестве хра н ил и ща допол н ител ьной и нформации о пол ьзователях (телефо н н ых номеров, домашних и рабочих адресов). М н огие почтовые систе м ы , включая sendmai l , Exim и Postfix, могут получить дан н ы е о маршрутизаци и из L DA P, и этим отчасти можно объя с н ить популяр­ ность при м е н е н и я LDAP. Дополн ительную и нформаци ю об испол ьзова н и и про­ токола L DAP в почтовой системе sendmail см. в разделе 1 8 . 8 . L DAP позволяет упростить процесс аутентификации пользователей для приложе­ н и й (даже тех, которые написаны другим и командами программ истов и в других подразделе н иях) , и збавляя разработч иков от необходимости беспокоиться о точ­ н ых деталях управления учетными зап ися м и . Изменения , внесе н н ые в L DАР-данные , немедленно вступают в силу и мгнове н но становятся видимыми для всех хостов и приложен и й клиентов. L DA P всесторон н е поддерж и вается языка м и написа н и я сценариев вроде Perl и Python (посредством использован и я библ иотек). Следовател ьно, L DAP удобно испол ьзовать для передачи и нформаци и о конфигурации локально написан н ы м сценариям и утил итам адми н истрирования. L DA P хорош о поддержи вается и как служба общедоступных каталогов. М ногие ведущие почтовые кл иенты применяют L DA P дл я доступа к каталогам пол ьзо­ вателей. П ростой поиск с использованием L DA P поддерживается во м ногих веб­ браузерах посредством типа L DAP U RL.

Структура дан н ых LDAP Дан н ые протокола LDAP при н имают форму списков свойств, которые в мире L DAP называют «запися м и » (entry) . Каждая запись состоит из набора и менованных атрибутов (например, u i d , de s c r i p t i on) и значен и й этих атрибутов. Пол ьзовател и , работающие в среде Windows, вероятн о , заметят, что эта структура напом и нает структуру записей в с истем ном реестре . Как и в реестре Wi ndows, отдельн ый атрибут может и меть несколь­ ко разл ичных значен и й . В качестве при м ера рассмотри м обычную ( и упроще н ную) строку файла / e t c / passwd, выраже н н ую в виде записи L DAP. dn : u i d= ghoppe r , ou= P e op l e , dc=navy , dc=mi l obj e c t C l a s s : t op obj e c t C l a s s : p e r s on o b j e c t C l a s s : o r g an i z a t i on a l P e r s o n obj e c t C l a s s : i n e t Or g P e r s on obj e c t C l a s s : p o s i xAccount obj e c t C l a s s : s hadowAccount u i d : ghopp e r cn : G r a c e H opp e r u s e r P a s s w o r d : { c rypt } $ 1 $ p Z aGA2 RL $MPDJo c 0 a fuhHY 6 y k 8 HQFp 0 l o g i n S he l l : / b i n / b a s h u i dNumЬ e r : 1 2 0 2 g idNumbe r : 1 2 0 2 home D i r e c t o r y : / h ome / ghoppe r

Здесь мы видим простой пример формата LD I F ( L DAP Data l nterchange Format фор­ мат обмена данными LDAP), который применяется в больш инстве инструментов, связан —

Глава 1 7. Система единого входа

599

ных с LDAP. и в реализациях серверов. Причиной успеха этого формата я Шiяется то обсто­ ятельство, что LDAP можно без труда преобразовывать в простой текст и обратно. Зап и с и образуют и ерархи ю по » отл и ч и тел ь н ы м и ме н а м » ( и м я атри бута: dn distinguished name), которые формируют некоторую разновидность пути поиска. Как и в системе D N S , «сам ы й стар ш и й бит» находится справа. Например, в приведенном выше примере имя DN S n a v y . rn i l испол ьзуется для построен и я верхн их уровней иерархии LDAP. Оно разбивается на два компоне нта домена: navy и rn i l , хотя это всего л и ш ь одно и з не которых обычных соглашений. Каждая запись и меет тол ько одно отлич ител ьное имя. Записи соверше н но изолиро­ ваны друг от друга и н е образуют иерарх и и , за искл юче н и е м иерархи и , нея вно опре­ деляемой атрибутам и dn. Это гарантирует их ун и кал ьность и подсказывает реализации протокола, как эффе ктивно и ндекси ровать и искать дан н ые . В иртуал ьную иерархи ю , созданную атри бута м и d n , применяют разн ые пол ьзовател и протокола LDA P, но она является с корее соглаш е н и е м о структури зации дан н ых, чем я вной фун кционал ьной возможностью протокола L DA P. В то же время существуют возможности дл я создания символ ических связей между зап исям и и ссьш ками на другие серверы . Зап иси LDAP обычно составляются н а основе испол ьзования атрибута o b j e c t C l a. s s . Класс ы объектов определяют атрибуты , которые может содержать зап ись, причем н е ­ которые из них могут требоваться для проверки достоверности . Каждому атрибуту н а ­ значается тип дан ных. Схема вложения и комбин ирован ия классов объектов н ичем не отл ичается от схе м ы , при нятой в традиционном объектно-ориентированном програм ­ мирован и и . Верхний уровен ь дере ва класса объектов называется t o p ; он означает л и ш ь то, что запись должна иметь атрибут obj e c t C l a s s . В табл . 1 7 . 1 приведе н ы н е которые обы ч н ые атрибуты L DA P, назнач е н и е которых с первого взгляда может быть непонятн ы м . —

Таблица 1 7 . 1 Некоторые имена атрибутов, которые можно встретить в иерархиях LDAP •

Атриб ут

Расwи фровка

Назначение

о

Orgaпizatioп (организация)

Часто идентифицирует запись верхнего уровня сайта•

ou

Orgaпizatioп uпit (организаци ­ онная еди ница)

Логическое подразделение, например ma r ke t i n g ( отдел маркетинга)

cn

Commoп паmе (обычное имя)

Н аиболее естественное имя , с помощью которого можно передать смысл записи

dc

Domaiп соmропепt (компонент домена)

Используется в сайтах, в которых иерархия построена на основе DNS

obj ectC l a s s

Object class ( класс объектов)

Схема, в соответствии с которой формируются атри· буты данной записи

» Обычно не используется системами, в которых ШАР-иерархия построена на основе DNS.

OpenLDAP: тради цион ный LDAP- cep в ep с открытым исходн ым кодом Ope n L DAP — это рас ш ирение проекта, выполнен ного в М и ч и ганском университете . В настоя щее врем я он продолжает оставаться проектом с открытым исходным текстом и распространяется с больши нством дистри бути вов Linux (хотя и не всегда вкл ючается в стандартный вариант и нсталляции). Его документацию, вероятно, луч ш е всего харак­ теризует слово «оживленная » .

Часть 11. Работа в сетях

600

В дистрибут и ве Ope n L DAP стандарт н ы м демоном L DAP-cepвepa я вляется s l apd. В среде с н ес кол ьк и м и сервера м и Open L DA P демон s lurpd в ыполняется н а главном сервере и отрабаты вает механ изм репликации посредством внесен ия изменений на под­ ч и н е н н ые серверы . Утилиты командной строки позволяют выпол нять запросы и моди­ фицировать данн ые L DAP. Настройка довол ьно простая . В первую очередь потребуется создать файл / etc/ openldap/ slapd . conf, скопировав образец, который был и нсталли рован в месте с сер­ вером Ope n L DAP. Н еобходимо обратить внимание на следующие строки. d a t ab a s e bdb s u f f i x » dc=mydom a i n , dc= c om » r o o t dn » cn= a dm i n , dc=mydoma i n , dc=com» r o o t pw { c r y p t ) abJnggxh B / yW I d i r e c t o r y / va r / l iЬ / l d a p

По умолчани ю выбирается формат базы дан н ы х Be rkley DB, отлично подходя щий для дан ных, манипуляция которы м и будет производиться в системе OpenLDAP. В ы мо­ жете использовать разнообразны е и н терфейсы , вкл ючая специал ь н ы е методы ( напри­ мер, сценарии , создающие данные «на лету » ) . П еременная suffix задает » базовое и м я » LDA P. Это корен ь ваше й части простран­ ства имен LDAP, подобн ы й том у, что в DNS н азывается доме н н ы м именем . Этот пример показывает обычное испол ьзование доме н ного и м е н и в качестве базового и м е н и LDAP. П еременная rootdn задает административное имя, а переменная rootpw хеширо­ ванн ы й пароль адми нистратора. Обратите внимание н а то, что дом е н н ы е ком поненты , восходя щие к адми нистративному и м е н и , также должны быть указа н ы . Для генериро­ вания значения дл я этого поля можно использовать утилиту slappaswd; просто с копи­ руйте и вставьте в поле результат работы этой утилиты . Поскольку пароль хеш ируется , проверьте, что файл slapd . conf принадлежит при­ вилегирова нному пользователю , а ero уровен ь допуска равен 6 0 0 . Н ужно также отредактировать файл / etc/ openldap/ ldap . conf, чтобы указать сер­ вер по умолчани ю и базовое имя для клиентских запросов L DAP. Это несложно: просто задайте аргумент записи host рав ны м и м е н и сервера, а в переменную base занесите то же значен и е , что и в переменной suffix файла slapd . conf (убедитесь, что обе строки не являются комментар и я м и ) . Вот как выглядит пример для сайта a t ru s t . com. —

BAS E URI

dc=a t ru s t , dc=com l d a p : / / a t l an t i c . a t ru s t . c om

С этого момента можно запускать демон slapd без аргументов.

389 Di rectory Server: ал ьтернативн ый LDAP-cep в ep с открытым исходн ым кодом П одобно Ope n L DA P, служба каталогов уровня предприятия 389 D i rectory S e rver (port3 8 9 . org) является расширением проекта, в ы пол не нного в Мичиганском универ­ ситете . Однако прошло несколько лет ( в ком пан и и N etscape Communications) , прежде чем этот проект снова стал открытым . Существует множество прич и н рассматривать проект 389 Directory Serve r как ал ьтер­ нативу для Open LDAP, но среди е го явных преим уществ все же стоит в ыделить более соверш е нную документацию . Проект 389 Directory Server поставляется с инструкциями профессионального уровня по адми нистрированию и использованию, включая подроб­ ные руководства по инсталляции и в недрению.

Глава 1 7. система единого входа

601

К ключевым особен н остям проекта 389 Directory Server можно отнести следующие: •

испол ьзование нескольких полностью равноправных мастер-серверо в, что позволяет обеспечить огказоустойчивость и высокую скорость выполнения операций записи; возможность синхронизации пользователей, групп и паролей с контроллерами до­ мена Active Directory; консол ь адм и нистрирования с графическим интерфейсом , управле ния из команд­ ной строки и через веб- интерфейс; поддержка протокола L DAP, оперативное (без потерь времени) обновление схе м ы , конфигурации и управлен и я , а также механизм Access Control lnfonnation (AC I ) .

Прое кт 389 Directory Se rver и меет больше акти в н ы х разработч и ков, че м прое кт OpenLDAP. П оэтому мы обыч но рекомендуе м отдавать п редпочтение именно проекту 389 Directory Server. С адм и нистративной точки зрен ия эти два сервера с открытым исходны м кодом по­ разительно сходны в том , что касается структуры и функционирования. И это не удиви­ тельно, поскольку оба пакета были построен ы на базе одного и того же исходною кода.

Созда ние LDА Р- за п росов Для адм и н истрирова н ия L DA P вам н е обойтись без п росмотра содержи мого базы дан ных и управл е н и я и м . Для этого вам очень пригодится упомянутый выше с вободно распространя е м ы й пакет phpLDA Padmin, которы й предоставляет удобн ы й и нтерфейс, работающий по при н ципу » указал и щел кнул » . Помимо php L DA Padmin, м ожно ис­ пользовать утил иту ldapsearch (распространяемую с OpenLDA P и 389 Directory Server) , которая предназначена для поиска и нформации в службе каталога и я вл яется анало­ гичн ы м и нструм ентом командной строки, ген ерирующим результат в формате L D I F. Утилита ldapsearch особен но полезна дл я вызова из с ценариев , а также для сред ог­ ладки, в которых служба Active Directory действует в качестве сервера LDAP. В следующем п р имере запроса испол ьзуется утилита ldapsearch дл я просмотра информации о каталогах тех пользователе й , у которых обычное и м я сп (common name) нач и н ается с » n e d » . В дан ном случае найден только оди н резул ьтат, соответствующи й такому запросу. Назначения используе м ых :щесь флагов рассматриваются н иже. $ ldapsearch -h atlantic . atrus t . com -р 3 8 9 -х -D » cn=trent , cn=users , dc=boulder , dc=atrus t , dc=com» -W -Ь » cn=users , dc=Ьoulder , dc=atrus t , DC=com» » cn=ned* » Ent e r L DAP P a s s wo r d : # # # # # #

пароль

LDAPvЗ b a s e < c n = u s e r s , dc=bou l de r , dc= a t r us t , dc=com> w i t h s cope sub f i l t e r : cn=ne d * r e que s t i n g : ALL

n e d , U s e r s , b o u l de r . a t ru s t . com dn : cn=ned , cn=U s e r s , dc= b o u l de r , dc=at r u s t , dc=com obj e c t C l a s s : t o p ob j e c t C l a s s : p e r s on obj e c t C l a s s : o r g a n i z a t i on a l P e r s on obj e c t C l a s s : u s e r cn : n e d

Часть 11. Работа в сетях

602

s n : McC l a i n t e l ephone Numbe r : 3 0 3 2 4 5 4 5 0 5 g ive nN ame : N ed d i s t i ngui shedName : cn=ne d , cn= U s e r s , dc=bou l de r , dc= a t r u s t , d c = c om d i s p l a yN ame : N e d McC l a i n memЬ e r O f : cn= U s e r s , cn=Bui l t i n , dc=bo u l de r , dc= a t r u s t , dc=com memЬ e r O f : cn=Ente r p r i s e Admi n s , cn = U s e r s , dc=b o u l de r , d c = a t ru s t , d c = c om n ame : n e d sAМAc countName : n e d u s e r P r i nc i p a l N ame : n e d @ b o u l d e r . a t ru s t . com l a s t Lo g onTime s t amp : 1 2 9 0 8 6 9 5 2 4 9 8 9 4 3 9 7 4 ma i l : n e d @ a t ru s t . com

Флаги -h и -р команды ldapsearch позволяют указать в запросе хост и порт серве­ ра L DAP соответственно. Обычно вам потребуется аутентифицировать себя на сервере LDAP. В этом случае ис­ пользуются с пециальные флаг и Фл аг -х запрашивает простую аутентификацию (в отли­ чие от SAS L) . Флаг -D иде нтифицирует отличител ьное имя учетной зап иси пользователя, котор ы й имеет права доступа, необходим ы е для выполнения запроса. Наконец, флаг -w предписывает утилите ldapsearoh предложить вам ввести соответствующий пароль. Флаг — Ь указывает утилите ldapsearch, где имен но в иерархи и LDAP начать поиск. Этот параметр известен как baseDN (отсюда и имя флага » Ь » ) . По умолчанию утили­ та ldapsearch возвращает все соответствующие критерию поиска строки, найде н н ые н иже базово й точки дере ва baseDN, т. е. поиск будет выполняться только в дочерних эле­ ментах базы поиска (включая ее саму) . Уточнить характер такого поиска можно с по­ мощью фла га — s . Последни й аргумент п редставл яет собой » фильтр » , который описывает объект ва­ шего поиска. Он не требует использования флагов. Этот фил ьтр, cn=ned* , обеспечи­ вает возвращен и е всех строк LDAP, «обычное имя» которых нач и н ается с «ned » . Этот фильтр за кл ю чаетс я в ка вы ч к и ( » cn=ned* » ) , чтобы специал ьные с и м вол ы универсали­ зации в строке поиска (в дан ном случ ае это » звездочка») не были восприняты системой как управляющие символы командной оболочки. Если вы хотите извлечь все зап иси ниже заданной базы ba s e DN , п росто испол ьзуйте в качестве фил ьтра поиска в ы ражение obj ectClass=* ил и же опустите фильтр во­ обще , поскольку такой характер поиска действует по умолчанию. Л юбые аргу ме н т ы , которые указаны за фил ьтром , обеспечи вают выбор кон кретных атрибутов для возвращаемого резул ьтата Например, есл и бы вы добавили в кон е ц при­ веденной выше командной строки аргумент mail givenName, утил ита ldapsearch воз­ вратила бы только эти атрибуты отфильтрованных записей . .

.

П реобр азования фа йлов п аролей и груп п LDAP Если вы переходите на протокол LDAP и у вас уже есть и нформация о пользовате­ лях и группах, то вам , возможно, потребуется перенести существующие данн ы е . В доку­ менте RFC2307 определено ста н дар тное преобразован ие традицион н ых наборов данн ых U N IX, к которы м относятся файл ы pas swd и group , в пространство и м е н L DAP. Это полезны й справочн ы й документ ( по крайней мере с теоретической точки зре н и я ) . На практике в с е эти специфи каци и ч итать гораздо проще ком пьютерам , чем л юдя м ; вам же луч ш е просто просмотреть примеры. Ф и р м а Padl Software предлагает бесплатную коллекцию сценарие в , которые перево­ дят существующие текстовые файл ы или карты N IS в LDAP. Эти сценарии можно най-

Глава 1 7. С истема единого входа

603

ти по адресу: padl . com/OSS /MigrationTool s . html . Работать с н и м и очень просто. Сценари и можно использовать в качестве фильтров мя генераци и L D I F, а также мож­ но запускать, чтобы загружать данные прямо с сервера. Например, сценарий migrate _ group преобразовывает взятую из /etc/group строку c s s t a f f : x : 2 0 3 3 : evi , ma t t h e w , t re n t

в следующий блок L D 1 F: dn : cn= c s s t a f f , ou=Gr oup , dc=doma inname , dc=com cn : c s s ta f f obj e c t C l a s s : p o s i x G r oup obj e c t C l a s s : t op u s e r P a s sword : { c r ypt } x gi dNumЬ e r : 2 0 3 3 memЬe r u i d : evi memЬe ru i d : ma t t he w memЬ e r u i d : t r e n t

1 7 3 ИспользовАНИЕ СЛУЖБ КАТАЛОГОВ ДЛЯ ВХОДА В СИСТЕМУ .

.

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

Если вы планируете испол ьзовать службу Active Directory с протоколом Kerberos , настройте Kerberos и п рисоедин ите с истему к домену Active Directory. Настройте утилиту s s sd мя связи с соответствующ и м и хранилищами идентифи­ кации и аутентификации ( L DAP, Active Directory или Kerberos). Настройте кл юч службы имен, nsswitch . conf, чтобы испол ьзовать утил и ту sssd в качестве источн и ка информации о пользователе , группе и пароле. Настройте РАМ мя обслуживан ия запросов аутентификации с помощью демона s s sd.4

Н иже мы рассмотрим эти процедуры.

Система Kerberos Kerberos — это система аутентификации на основе мандатов, испол ьзующая кри п ­ тографи ю с симметричным ключом . Его популярность в последнее врем я была обеспе­ чена прежде все го компанией M icrosoft , которая использует ее как часть с истем ы ау­ тентификаци и в службе Act ive Directory и операционной системе Wi ndows. В контексте SSO мы описывае м , как и нтегрироваться со средой Active Di rectory Kerberos в системах Linux и Free B S D . Если вы используете LDA P-cepвep, отличный от Active Directory, или если вы хотите пройти аутентификаци ю в службе Active Directory с помощью L DAP, а не Kerberos, вы можете сразу перейти к обсуждению демона s s sd. W Дополнительную и нформацию о системе Kerberos см. в разделе 27. 6 . •одна часть програм м ного обеспече н и я испол ьзует традиционное семейство библиотечных про­ цедур getpwent для поиска информаци и о пользователе, но современные службы часто напрямую вызы вают п роцедуры ауте нтифи кации РАМ . Чтобы обеспечить пол ностью функцион альную среду, настройте и РАМ , и ns switch . conf.

Часть 11. Работа в сетях

604

Конф игурация Lin иx Kerberos для интеграции службы Active Directory Систе м н ые адм инистраторы часто хотят, чтобы их систем ы Linux были чле­ нами домена Active Directory. Ран ьше сложность этой конфигурации приво­ дила к тому, что некоторые из системных админ истраторов приходил и в от­ чаяние. К счастью, появление пакета realmd нам ного упростило эту задачу. П акет realmd действует в качестве инструмента настройки как мя демона s s sd, так и мя системы Kerberos. Прежде чем пытаться присоедин иться к домену Active Directory, п роверьте следующие условия. •

В с исте м е Linux , которую вы п р исоеди няете к дом е н у, и н сталл ирован пакет realmd.

Демон s s sd инсталлирован (см. н иже) .

Демон ntpd установлен и запуще н .

Вы знаете правил ьное имя своего домена Active Directory.

У вас есть учетные данные для учетной записи Active Directory, которой разреше­ но присоединяться к с истеме в домене. Это действие приводит к выдаче мандата на вьщачу мандатов в Kerberos (ticket granti ng ticket TGT) , чтобы он мог выпол­ нять операции аутентификации в будущем без доступа к парол ю администратора. —

Например, есл и ваше доменное имя Active Directory U LSAH . CO M , а учетная за­ пись Act ive D i rectory под именем t r e n t имеет право на присоединение с исте м ы к до­ мену, вы можете испол ьзовать следующую команду мя присоединения вашей с истемы к домену. —

$ sudo realm j oin — -user=trent ULSAН . COМ

Затем вы можете проверить результат. $ realm list u l s a h . c om t yp e : k e rb e r o s r e a lm-name : ULS AН . COM doma i n — n ame : u l s a h . c om c on f i gu r e d : k e r b e r o s -memЬ e r s e rve r — s o f twa r e : a c t i ve — d i r e c t o r y c l i e n t — s o f tw a r e : s s s d r e qu i r e d- p a c k a g e : s s s d r e qu i r e d- p a c k a g e : a d c l i r e qu i r e d — p a c k a g e : s amЬ a — common l o g i n — f ormat s : % U @ u l s ah . com l o g i n — p ol i c y : a l l ow- r e a l l o g i n s

Конф игурация Kerberos FreeBSD для интеграции A D Система Ke rberos печал ьно известна своим слож н ы м процессом настрой­ ки , особен но н а стороне сервера. К сожалению, система Free BS D не имеет надежного инструме нта, похожего на пакет realmd в системе Linux, кото­ р ый настраивает Kerberos и объединяет домен Active Di rectory за оди н шаг. Однако вам н еобходи мо настроить тол ько кл ие нтскую сторону Ke rbe ros. Конфигурационным файлом является /etc/krbS . conf.

Глава 1 7. Система единого входа

605

Во-первых, дважды проверьте , что пол ное доме нное имя систем ы включено в файл /e t c / h o s t s , а протокол NTP настроен и работает. Затем отредактируйте файл krbS . conf, чтобы добавить область, как показан о в следующем примере. Заме ните и м я до­ мена Active Diгectory ваш е го сайта для U LSAH .COM. [ l ogg i n g ] default F I LE : / va r / l o g / k r b 5 . l o g [ l i bde f a u l t s ] clocks kew 300 de f a u l t r e a l rn U L SAH . COM kdc_t irne s ync 1 c c ache_type 4 f o rwardaЫ e = t ru e t ru e proxiaЫe [ re a lrns ] ULSAH . COM kdc dc . ul s a h . corn a drni n s e rve r dc . ul s ah . corn de f a u l t dorna i n U L SAH =

=

=

=

=

=

=

=

[ dorna i n_ r e a lrn ] . u l s ah . corn = U L SAH . COM u l s ah . c orn U L SAH . COM =

В п р и в еде н н о м в ы ш е п р и м ере и н терес п р едставля ют н ес кол ько з н ач е н и й . Пятим и н утное рассогласование часов разрешено, даже если врем я установлено с по­ мощью протокола NTP. Эта свобода позволяет с истеме работать даже в случае проблем с протоколом NTP. Область по умолчанию установлена в домене Active Diгectory, а центр распределе н ия ключей (или КОС) настроен как контроллер домена Active Diгectory. Для отладк и может пригодиться файл k r b 5 . l o g . Запросите мандат и з контроллера Active Diгectory, запустив ком анду kini t . Укажите действительную учетную запись пользователя домена. Аккаунт a dmi n i s t ra t o r обы ч но является хорошим тестом , но подойдет и л юбая учетная запись. При появлен и и запроса введите пароль домена. $ kinit adminis [email protected] ULSAН . COМ Pas sword f o r a drnin i s t r a t o r @ UL SAH . COM :

Испол ьзуйте команду klist, чтобы показать мандат КегЬегоs. $ kli s t T i c k e t c a c h e : F I L E : / t rnp / k r b 5 c c_ l 0 0 0 De f au l t p r i nc i p a l : adrni n i s t ra t o r @ UL SAH . COM S e rv i c e p r i n c i p a l Va l i d s t a r t i n g Exp i r e s 0 4 / 3 0 / 1 7 1 3 : 4 0 : 1 9 0 4 / 3 0 / 1 7 2 3 : 4 0 : 2 1 k r b t g t / UL SAH . [email protected] UL SAH . C OM r e n e w unt i l 0 5 / 0 1 / 1 7 1 3 : 4 0 : 1 9 Kerbe r o s 4 t i c ke t c a c h e : / trnp / t kt l O O O kl i s t : Y o u have n o t i c k e t s c a c h e d

Есл и м андат отображается на экране, то аутентификация прошла успешно. В этом случае мандат действителен в теч е н ие 1 0 ч асов и может быть продлен на 24 часа. Для аннул и рования мандата можно испол ьзовать команду kdes troy.

Часть 11. Работа в сетях

606

Последн и й шаг — присоединить с истему к домену, как показано н иже . Испол ьзуемая учетная запись админ истратора (в дан ном случае t r e n t ) должна и м еть соответствующие полномоч ия на сервере

Active Directory для присоеди н е н и я с истем к домену.

$ net ads j oin -U trent En t e r t r e n t ‘ s p a s s w or d :

U s i n g s h o r t doma i n — — U LSAH J o i n e d ‘ ex amp l e . ul s a h . c om ‘ to doma i n ‘ UL SAH . COM ‘ Допол н ител ьн ы е параметры кон ф и гур а ц и и п р и веде н ы на с правоч ной стра н и це krb5 . conf.

Демон s s sd: сл ужба системной безо п асности В прошлом путь к установке с истем ы SSO в операцио н н ы х с истемах U N IX Linux был долог и труден . Несколько лет назад было п р и н ято устанавл и ­

и

вать н езав исимую ауте нтификацию для каждой служб ы ил и прил оже н и я . Такой подход часто приводил к появлению запутан н ых конфигураций и н е ­ докуме нтированн ы х зависимосте й , которые с о временем н евозможно было контролировать. Парол и пользователей будут работать с одни м прил ожением, но н е с другим , что в ызовет разочарован ие для всех. Ранее ком п а н и я M icrosoft опубл и ковала расширения (первоначально назы вае мые » Services for U N IX» , затем «Windows Security and D irectory Services for U N IX» и , нако­ н е ц , » ldentity Management for U N IX» в Windows Serve r 20 1 2) , которые обл е гч ил и раз­ меще н ие пользователе й и групп U N I X в службе Act ive Directory. Однако использование полномоч и й для управления эти м и атрибутами в систе м е , отличной от U N IX , было не­ естествен н ы м .

К облегчению многих пользователей ком пания M icrosoft прекратила под­ Windows Server 20 1 6 .

держку этой фун кци и в верси и

Эти пробл е м ы нуждались в каком-то ком пл е ксном реш е н и и , и и м е н но это м ы полу­

s ssd, Demon System Security Services. Доступн ы й как для Linux, Free B S D демон s s sd — это ун и версал ь н ы й инструме н т для проверки п рав

чили с помощью демона так и для

пользователе й , ауте нтификации и сопоставления учетных записе й . Он также м ожет ке­ ш и ровать учетн ые дан ные в автономном режим е , что полезно для мобильных устройств. Демон s s sd поддерживает ауте нтификацию как с помощью собствен ного протокола L DAP, так и протокола Kerberos. Демон s s sd настра и вается с помощью файла s s sd . conf. Н иже приведе н базовый пример для среды , которая ис пол ьзует Act ive Directory в качестве службы каталогов:

[ s ssd] s e rv i c e s doma i n s

= =

n s s , p am U LSAH . COM

[ doma i n / U L SAH . COM ] i d_p r ov i d e r ad a c c e s s _p rovide r ad =

=

L DAP, н е задействующий службу Act ive Directory, т о ваш s s sd . conf может выглядеть примерно так:

Если вы ис пол ьзуете сервер файл

[ sssd] s e rv i c e s n s s , pam doma i n s = L DA P =

Глава 1 7 . Система единого входа

607

[ doma i n / L DAP ] id_p r ovi d e r = ldap auth _p r o v i d e r = ldap ldap_u r i = l d ap : / / l dap . u l s a h . com ldap_u s e r_s e a r ch_b a s e = dc=ul s a h , dc=com t l s_reqc e r t = demand ldap_t l s_c a c e r t = / e t c / p ki / t l s / c e r t s / c a -bundl e . c r t

По очевидн ы м причинам безопасности демон s s sd не разрешает аутентификацию по незашифрованному каналу, поэтому требуется использование LDAPS/ТLS. Уста новка атрибута t l s_re q c e r t для запроса в приведенном выше примере застамяет демон sssd допол нительно проверять сертификат сервера. Демон s s sd откл юча е т соединение, если обнаруживается , что сертификат недостаточен . Когда де мон s s s d запущен и работает, в ы дол ж н ы сообщить с исте м е , чтобы она испол ьзовала е го в качестве источ н ика для иде нти ф и ка ц и и и ауте нтиф и каци и . Следующим ш агом в этом процессе я вляется настрой ка ключа служб ы и м е н и настрой ­ ка РАМ .

ns swi tch . conf: п ереключател ь сл ужб ы и м ен Ком мутатор службы имен (name service switch — NSS) был р а зр аботан для у прощ е ­ ния выбора между разл и ч н ы м и базами дан н ых конфигур ац и и и м е ха н изм а м и разреше­ ния имен . Вся конфигурация находится в файле /eto /nss w i toh . conf. Синтаксис п рост: для определенного типа поиска достаточно просто перечислить источ н и ки в том порядке , в котором и м следует обратиться . Вначал е следует запраши­ вать локальные систе м н ые файлы pas swd и group (задан н ые атр ибутом f i l e s ) , а затем можно привязаться к службе Active Di rectory или другой службе каталогов с помо щь ю демона sssd (указанного атрибутом sss). Этот трюк опи с ан в следующ и х строках .

pas swd : f i l e s s s s group : files sss shadow : f i l e s s s s

После настройки файла nsswi tch . conf, конфигурацию можно проверить с помо­ щью команды getent pas swd. Эта команда выводит с писок учетн ых за п исей пользова­ телей , определенных во всех источн и ках в формате /etc/passwd: $ getent passwd roo t : x : O : O : r o o t : / r o o t : / Ы n / b a s h daemon : x : l : l : da emon : / u s r / s Ы n : / b i n / s h bwh a l e y : x : l 0 0 0 6 : 1 0 0 1 8 : : / h ome /bwh a l e y : /Ы n / s h gue s t : * : l O O O l : l O O O l : Gue s t : / h ome /ULSAH / gu e s t : / Ы n / b a s h ben : * : l 0 0 0 2 : 1 0 0 0 0 : B e n Wha l e y : / h ome / U L SAН / be n : / Ы n / b a s h krb t g t : * : l O O O З : l O O O O : k r b t g t : / h ome / U L S AH / k rb t g t : / Ы n / b a s h

Как в идно из последних трех зап исе й , при веде н н ых выше, единствен н ы й способ отл и ч ить локал ьн ы х пол ьзователей от учетных записей домен а это ид ен т ифи катор пользователя и путь к домашнему каталогу. —

М одули РА М : у кра шен ие ил и ч уд о а утентифик а ции ? Аббревиатура РАМ означает » подкл ючае м ые модул и ауте нтиф и каци и » ( PluggaЬe Authentication M odules РАМ ) . Эти модул и освобождают програм м истов от необ­ ходимости вы пол нять рути н н ы е операции для реал и за ц и и с исте м ауте н т и ф и к ац и и —

.

Часть 11. Работа в сетях

608

Sun M icrosystems ( которая в настоя­ 1 996 юду в статье , авторами которой бьmи Самар ( Samar) и Лаи ( Lai ) из ком пании SunSoft . В далеко м прошлом команды вроде login включали встрое н н ы й код ауте нтифи ­ Кон це пция и тер м и н бьmи придум а н ы в компан и и

щее врем я я вляется частью компани и Oracle) и описаны в

кац и и , которы й п редлаrал пол ьзователю ввести парол ь, срав н и вал ею с заш ифрован ­ ной записью из файла /etc/ shadow (в настоя щее время этот файл н азы вается / etc/ passwd) и делал вы вод об их совпаде н и и ил и несовпаде н и и . Разумеетс я , друrие коман ­ ды ( например, pas swd) содержал и такой же код. Не имея доступа к открытому коду, было н е возможно измен ить метод ауте нтификаци и , поэто му адм и н истраторы и м ели мало возможносте й для управления настрой кам и паролей (например, задавать правила, опис ы вающие правил ьные парол и ) или не имели их вообще . Появле н и е модул е й РАМ в корне изме н ило положе ние дел . Систе м н ые процедуры ауте нтификаци и из м одул е й РАМ был и пом е щ е н ы в сов­ местно ис пользуемую библ иоте ку, которую может вызывать программа

login и другие

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

login и passwd.

Для с истемноrо администратора выбор правил ьною уровня безопасности для аутен ­ тификаци и стал простой задачей конфи гурирова н и я . П ро грамм исты также получ или в ы году: о н и бол ьше н е обяза н ы п исать сложны й код для ауте нтификац и и и , ч то еще более важно, их с исте м ы ауте нтиф и каци и правильно реал изуютс я с первой поп ытки. Модул и РАМ могут ауте нтифицировать все виды деятельности : регистрацию пользова­ телей , друrие фор м ы доступа к систе м е , использование защищенных веб-сайтов и даже настройку приложе н и й .

Конфигурация модуле й РА М Файлы конфи гурац и и модул е й РАМ содержат по одной строке , каждая из которых представляет собой имя модуля РАМ , испол ьзуемоrо в системе. Общий формат этих файлов имеет следующ и й вид. ти п_модуля упра в ляЮШJ1й_ фл а г пу ть_ к_мо дулю [ а ргументы ]

П оля разделяются пробелами . П ор ядок п ол е й в файле конфигурац и и РАМ и м еет знач е н и е . Н а пр и м ер , м одуль, предлагающий пользователю ввести пароль, должен выпол н яться раньше модул я , про­ веряющего корректность парол е й . Оди н модуль передает резул ьтаты с воей работы дру­ юму, устанавл и вая значения переменных окруже ния ил и пере м е н н ых РАМ . Поле тип_ модуля может иметь значения a u t h , a c c o u n t , s e s s i o n ил и pa s s wo rd. Модуль типа a u t h идентифицирует пользователя и может предоставлять ему право груп­ повою доступа. Модуль типа a c c o u n t выпол няет де йствия , не связан ные с ауте нтифи­ каци е й , например предоставляет доступ в зависимости от времени суток, огран ичивает количество одновременно работающих пользователей или количество портов, на которых может происходить регистрация . ( Например, можно испол ьзовать модуль типа a c count для огра н и ч е н ия ре гистрации суперпол ьзователя на консол и . ) Действия , котор ые не­ обходимо выпол н ить до или после тою , как пользователь получит доступ к требуемой службе, например монтирование файловой систе м ы , реализуются модулем типа s e s s ion. Наконец, модуль типа p a s sword применяется , когда пользователь должен ввести аутенти­ фикационную информацию ( например, пароль ил и кодовое словосочетание) .

Глава 1 7. Система единого входа

609

Поле упра вляющий_ фла г определяет, как должны взаимодействовать модул и , обра­ зующие стек (табл. 1 7. 2) . Таблица 1 7. 2 . Управляющие флаги модулей РАМ Флаг

Остановка в случ ае ошибки

Остановка в случае успеха

include

opt ional

Нет

Нет

Имеет значение, только если модуль единственный

required

Нет

Нет

Ошибка приводит со временем к 0″11

S e rve rName S e rve r Al i a s S e rverAl i a s Docume n t Root C u s t omLog E r r o rL o g S SL E n g i n e SSLCe r t i f i cateFile S S L Ce r t i f i c a t e Ke y F i l e

a dmi n . c om www . admi n . c om u l s a h . admi n . com / v a r /www / a dmi n . com/ /va r / l o g / apach e 2 / a dmi n_c om_a c c e s s c omЬ i n e d /va r / l o g / apache 2 / admin_c om_e r r o r on

» / e t c / s s l / c e r t s / a dm i n . c om . c r t » » / e t c / s s l / p r i va t e / a dmi n . c om . ke y «

Глава 1 9. Веб-хостинг

71 5

< D i r e c t o r y » / va r / www / a drni n . c om » > Requi r e a l l g r a n t e d < /Di rectory> < D i r e c t o r y » /v a r / www / a drni n . c om/ph o t o s » > Op t i o n s + I n dex e s < / Di r e c t o r y > < I fModu l e m o d r e w r i t e . c > Rew r i t e En g i n e оп Rew r i t e Ru l e л / ( u s ah l l s ah ) $ / u l s ah < / I fModu l e > E x t e ndedS t a t u s On < L o c a t i on / s e rve r — s t a t u s > S e tHandl e r s e rve r — s t a t u s Re qu i re i p 1 0 . 0 . 1 0 . 1 0 / 3 2 < / Lo ca t i on > < /Vi r t u a l Ho s t >

Бол ьшая часть этого кода не нуждается в разъяснениях, но стоит отметить несколько деталей. •

Первая директива VirtualHost отвечает при обращении к порту 80 и перенаправ­ ляет все НТГР-запросы к сайтам adтi n . с от , www . a dт i n . сот и u l s a h . a dт i n . сот в НТГРS-запрос ы. Запрос ы к каталогу a dтi n . coт / p h o t o s выводят список всех файлов в этом ката­ логе. Запросы к каталогам / u s a h и / l s a h переписываются в / u l s a h .

Состоян ие сервера, отображаемое в этой конфигурации п р и доступе п о U R L www . a dm i n . coт/ s e rve r — s t a t u s , представляет собой модуль, которы й показывает полезную информацию о производительности во время выпол нения , включая статистику о потреб­ лении процессорного времени и памяти демона, состоян и и запроса, средне м количестве запросов в секунду и т.д. Системы мониторинга могут испол ьзовать эту фун кцию для сбо­ ра данных о неб-сервере для оповеще н и я , отчетности и визуализации НТГР-трафика. Здесь доступ к состоянию сервера ограничен одним I Р-адресом , 1 0.0. 1 0. 1 0.

Базовая аутентифика ция п ротокола Н ТТ Р В базовой схеме ауте нтификации п ротокола Н ТГ Р кл иенты передают в Н ТТР­ заголовке Au t h o r i z a t i o n имя пол ьзователя и пароль, заш ифрова н н ы й по стандар­ ту Base64. Есл и пол ьзовател ь вкл ючает имя и парол ь в U R L ( н а п р и м е р , h t t p s : / / u s e r : pa s s @ www . a dтi n . c oт / s e rve r — s t a t u s ) , браузер автоматически выполняет пере­ кодировку и помещает закодирован ное значение в заголовок Aut ho r i z a t i o n . И м я пол ьзователя и парол ь н е заш ифрован ы , поэтом у базовая ауте нтификация не обеспеч и вает конфиденциальности. Таким образом, ее безопасно испол ьзовать толь­ ко в сочетании с протоколом НТГРS. Обычная аутентификация в веб-сервере Apache настраивается в блоках Loca t i o n или D i recto ry. Например, следующий фрагмент требует аутентификаци и для доступа к U RL / s e rve r — s t a t u s (луч шая практика) и ограничения доступа к нему всего из одной под­ сети: < L o ca t i on / s e rve r — s t a t u s > S e tHandl e r s e rve r — s t a t u s Re qu i r e i p 1 0 . 0 . 1 0 . 0 / 2 4

Часть 11. Работа в сетях

71 6

AuthType B a s i c AuthName » Re s t r i c t e d » Aut hU s e r F i l e / va r /www/ . h t p a s swd Requi r e v a l i d — u s e r < /Locat ion>

Обратите внимание на то, что информация об учетной записи не хран ится в файле конфигурации. Испол ьзуйте утил иту htpas swd для создания учетной зап иси : # htpasswd — с /var/www/ . htpas swd ben New p a s s w o r d : Re — t yp e new p a s sword : Addi n g p a s s w o r d f o r u s e r b e n # cat /var/www/ . htpasswd b en : $ a p r 1 $mPh 0 x 0 C j $ h f qMav kdH fVRV s cE 6 7 8 Sp O # chown www- data /var/www / . htpas swd # chmod 600 /var/www / . htpas swd

# Уста новка в л адел ьца # Огра ничение до с тупа

Файлы паролей являются обычно скр ытым и файлами, название которых начинается с точки, например, htpas swd, но их можно назвать как угодно. Н есмотря на то что па­ роли заш ифрованы, для файла htpasswd следует установить доступ только для чтения дл я того пользователя , от имени которого запущен веб-сервер. Эта предосторожность ограничивает с пособность злоумышле н ников видеть имена пол ьзователей и запускать пароли ч ерез программное обеспечение для взлома. .

.

Настройка ТLS Хотя имя SSL было заменено на TLS , в и нтересах обратной совместимости Apache сохраняет имя S S L для своих параметров конфи гурации (как и м н огие другие пакеты программного обеспечен ия). Для настройки TLS требуется несколько строк: S S LE n g i n e S SL P r o t o c o l S SL C e r t i f i c a t e F i l e S SL C e r t i f i c a t e K e y Fi l e

on all — S S Lv2 — S S LvЗ » / e t c / s s l / c e r t s / a dmi n . c om . c r t » » / e t c / s s l / p r i va t e / a dmi n . c om . ke y «

Здесь сертификат и ключ T L S находятся в самом сердце с исте м ы Linux, в каталоге / e t c / s s l . Открытые сертификаты могут быть проч итаны кем угодно, но кл юч должен быть доступен только пользователю мастер-процесса Apache, обычно r o o t . М ы предпо­ ч итаем устанавливать разрешения 4 4 4 для сертификата и 4 О О для ключа. Все версии фактического протокола SSL (предшестве н н и ка TLS), как известно, я в­ ляются небезопас н ы м и и должны быть отключены с помощью директивы S S LProtocol , показанной выше. W Полное описание руководства TLS на стороне сервера с м . в разделе 1 9 . 7 . В некоторых из алгоритмов ш ифрования выявлен ы слабые места. П оддерживаем ы е ал гор иты ш ифрова н и я н а в е б — с е р в е р е м о ж н о настроить с помощью д и р е кт и в ы S S L C i p h e r S u i t e . Рекомендации по точному использованию тех или и н ых настроек по­ стоянно меняются . Руководство Mozilla Server Side TLS лучший ресурс , о котором м ы знае м , чтобы оставаться в курсе передовых методов использован ия TLS. О н также имеет удобный справочник о синтаксисе конфигураци и для Apache, NGINX и HAProxy. —

Запуск веб-приложений в Apache Веб-сервер httpd может быть расширен с помощью модульной с исте м ы для запуска программ , написан ных на Pyt hon , Ruby, Perl , РН Р и других языках. М одул и выполня-

Глава 1 9. Веб-хостинг

71 7

ются внутри процессов Apache и имеют доступ к пол ному жизнен ному циклу Н ТТР­ запроса/ответа. Модул и предоставля ют допол н ительные директивы конфигураци и , которые позво­ ляют адм и н истраторам управлять характеристиками среды выпол н е н ия приложен и й . В табл . 1 9 . 7 перечислены некоторые расп ространенные модули сервера приложений. Таблица 1 9 .7. Модули сервера приложений для httpd Модуль

Slэык

mod_php mod_wsqi

РНР Python Несколько

mod_passenqer

mod_proxy_fcqi Любой mod_per 1

Perl

Устарел; использовать только с МРМ p r e f o r k Интерфейс шлюза веб-сервера, стандарт Python Гибкий, коммерчески поддерживаемый сервер приложений для не­ скольких языков, включая Ruby, Pythoп и Node.js Стандартный серверный интерфейс, который позволяет запустить про­ граммы на любом языке Реrl-интерпретатор, который реализован в httpd

В сл едующем примере настройки приложения Django Python для сайта a p i . a dm i n . испол ьзуется модул ь mod w s g i :

с от

LoadModu l e w s g i_modu l e mod_ws g i . s o

S e rve rName a p i . a dmin . c om Cu s t omLo g / va r / l og / ap a c h e 2 / a p i_a dmi n_com_a c c e s s comЬined E r r o r L o g / va r / l og / ap a c h e 2 / a p i_a dm i n_com_e r r o r SS LEngine on S S LC e r t i f i ca t e F i l e » / e t c / s s l / c e r t s / a p i_admin . com . c r t » S S LC e r t i f i c a t e Ke yFi l e » / e t c / s s l / p r i va t e / api_admi n . c om . ke y » W S G I D aemon P r o c e s s admi n_a p i u s e r =u s e r l g r oup= group l t h r e a d s = 5 WS G I S c r i p t Al i a s / / v a r /www / ap i . a dmi n . c om / a dmi n_a p i . ws g i < D i r e c t o r y / va r / www / a p i . admi n . c om> W S G I P r o c e s s G roup a dmin_api W S G I App l i c a t i onGr oup % ( GLOBAL } Requ i r e a l l g r a n t e d < / Di r e c t o r y > < /V i r t u a l Ho s t >

П осле того как модул ь mod_wsgi . so был загружен веб-сервером Apache, стали до­ ступным и нескол ько директив конфигурации WSG I . Файл W S G I S c r i pt Al i a s в приве­ денной выше конфигурации admin_api . wsgi содержит код на Python, необходи мый модул ю WSG I .

В едение журнала Веб-сервер httpd предлагает луч ш ие в своем классе возможности ведения журнала, с детал ьн ы м контролем над дан н ы м и , которые регистрируются , и возможностью разде­ лить дан ные журналов для разных виртуал ьных хостов. Адм и нистраторы используют эти журналы для отладки проблем конфигураци и , обнаружения потен циал ьн ых угроз без­ опасности и анализа информации об испол ьзовании. Пример сообще ния журнала admin . com . acces s . log выглядит так:

Часть 11. Работа в сетях

71 8

1 2 7 . 0 . 0 . 1 — — [ 1 9 / Jun / 2 0 1 5 : 1 5 : 2 1 : 0 6 + 0 0 0 0 ] 2 0 8 9 2 » — » » cu r l / 7 . 3 8 . 0 «

» GET / s e a r c h НТ Т Р / 1 . 1 » 2 0 0

Это сообщение показывает: •

источник запроса; в данном случае 1 2 7 . О . О . 1 , т.е . локальный хост;

временную метку;

путь запрашиваемого ресурса ( / s e a rch) и метода НТТР (GET ) ;

код состоян ия ответа ( 2 0 0 ) ;

размер ответа;

пользовательский агент ( инструмент командной строки cu r l )

.

В документаци и для mod_log_config есть все сведения о том , как настроить формат журнала. Загруже н н ы й веб-сайт генерирует большое количество журналов запросов, которые могут быстро запол нить диск. Адм ин истраторы несут ответственность за то, чтобы этого не произошло. Храните журналы веб-сервера в выделенном разделе диска, чтобы раз­ росшийся до больших размеров жур нал ьный файл не повл иял на работу остал ьной ча­ сти системы. m Дополнительную и нформацию о б утилите logrotate см. в разделе 1 0 . 5 . В большинстве дистрибутивов Linux установка пакета Apache по умолчан ию вклю­ чает в себя соответствующую конфигурацию logrotate. Система Fre e B S D не имеет та­ кого значения по умолчанию, и администраторы должны вместо этого добавлять зап ись в файл /etc/newsyslog . conf дл я журналов Apache. Каталог журналов и файлы в нутри него должны быть доступ ны для записи только пользователю основного процесса httpd, которы й обычно я вляется суперпол ьзовате­ лем r o o t . Если бы у остальных пользователей был доступ для зап ис и , то он и могл и бы создать символическую ссылку на другой файл , в результате чего он был бы перезаписан фиктивными дан н ы м и . Системные значения по умолчанию настроен ы безопасно, по­ этому избегайте изменений настройки владельца и групп ы .

1 9.S. ВЕБ-СЕРВЕР NGINX Загружен н ы й веб-сервер должен отвечать на м ногие тысяч и одновременных запро­ сов. Большая часть времени, необходимого для обработки каждого запроса, расходуется на ожидание поступления данных из сети или диска. Время, затрачиваемое на активную обработку запроса, намного короче времени ожидания . Чтобы эффективно обрабатывать эту рабочую нагрузку, веб-сервер NG I N X исполь­ зует с истему на основе событий , в которой всего несколько рабочи х процессов обра­ батывают м ножество запросов одновременно. Когда запрос или ответ (событие) готов к обслуживанию, рабочи й процесс быстро завершает обработку и переходит к обработке следующего события. П режде всего N G I NX стрем ится избежать блокировки сетевого или дискового ввода- вы вода. Событие М РМ , вкл юченное в новые верс и и Apache , испол ьзует аналогич ную ар­ хитектуру, но для сайтов с большим объемом и высокой производительностью NG I NX остается основны м программ н ы м обеспечением. Адм инистратор ы , работающие с веб-сервером NG INX, заметят как м и нимум два процесса: главн ы й и рабочи й . Главный процесс выпол няет основные обязан ности , та­ кие как открытие сокетов, считывание конфигурации и поддержание других процессов

Глава 1 9. Веб-хостинг

71 9

NG INX. Рабоч ие процессы выполняют бол ьшую часть тя желой работы с помощью об­ работки запросов. В некоторых конфигурациях используются дополн ител ьн ые процес­ сы, предназначенные мя кеш ирован ия. Как и в Apache , гла н н ы й п ро цесс ныпол няется как ro o t , поэтому он может откры вать сокеты для л юбых портов с номера м и меньше 1 024. Другие процессы выполняются как менее привилегированный п ол ьзо вател ь. Кол ичество рабоч их п роцессов м ожно задавать. Хоро ш е е э м п и р и ч ес кое прави­ л о состоит в том , чтобы запускать стол ько рабочих п роцессов, с кол ько п роцессор н ы х ядер есть у систе м ы . В с исте мах Deblan и Ubuntu и м е н но так и настраи вается N G I N X п о умолчан ию, есл и он установлен и з пакета. В систе мах Free B S D и R H E L по умолча­ нию запускается один рабочи й процесс.

Уста новка и запуск N G I NX Хотя популярность веб-сервера N G I N X п родолжает расти и он я вл яется основн ым продуктом среди сам ых загруженных веб-сайтов в м и ре , дистрибутивы операцио н н ы х систем по-прежнему отстают от его поддержки. Версии, доступные в официальных хра­ нилищах для систем Deblan и RH EL, обычно устаревш ие, хотя с истема Free B S D обычно является более актуальной. Веб-сервер N G I NX я вляе тс я продуктом с откр ытым исход­ ным кодом , поэтому его можно построить и установить вруч ную. Веб-стран и ца п рое кта, nginx . o rg , предлагает пакеты для утилит apt и yum , которы е, как правило, более позд­ нюю верс ию, чем те , которые поставля ются с дистри бути нам и ОС. m Дополнительную информацию о сигналах см. в разделе 4.2. Для повседневной работы с веб-сервером nginx н е требуется н и каких особых при­ емов управления службам и . Можно также запустить де мон nginx во врем я разработ­ ки и отладки . Для указания другого файла конфигура ц и и ис пол ьзуйте а р гу м е нт — с . Параметр — t вы пол няет проверку с и нтаксиса файла кон ф и гураци и . Веб-сервер nginx испол ьзует сигналы дл я запуска разл и ч н ых де йств и й п о обслужи­ ван ию, перечисленные в табл . 1 9 . 8 . Убедитесь, что вы передаете их основному процессу nginx (обычно тому, у которого сам ый низкий P I D). Таблица 1 9 .8. Сигналы, понятные демону nginx Сигнал

Функция

ТЕRМ ИЛИ I NT

Немедленное прекращает работу

QU I T

Завершает и закрывает все текущие соединения, затем прекращает ра б оту

USRl

Повторно открывает файлы журналов ( ис п ол ьзуется для облегчения ротации журна­ лов )

HUP

Перезагружает конфигурацию •

U S R2

Изящно заменяет двоичный файл сервера без прерывания служб ы 6

‘ Этот параметр проверяет синтаксис новой конфигурации, и, если синтаксис корректный, за пус ка ет новые рабочие процессы с новой конфигурацией , а затем аккуратно закрывает старые рабочие процессы . » Подробнее о том , как это работает, см. в документации nqinx.

Настройка веб — сервера NGINX Фор мат конфигурац и и N G I N X напом и н ает я з ы к С . О н и с пол ьзует ф и г ур н ы е с кобки , чтобы разл ичать бл оки строк конфигура ции и то ч к и с з а п ято й дл я разделе-

Часть 11. Работа в сетях

720

н и я строк. Основной файл кон ф и гурац и и по умолчан и ю назы вается nginx . conf. Наиболее важны е для конкретной систем ы аспекты конфигурации N G I NX приведены в табл. 1 9 . 9 . Таблица 1 9 . 9 . Детали конфигурации NGINX в зависимости от платформы RHEL/CentOS

Deblan/Ubuntu

FreeBSD

Имя пакета

nginx0

nginx

nginx

Путь к демону

/ sЬin/nginx

/usr/ sЬin/nginx

/usr/ local/ sЬin/nginx

Корневой каталог конфигурации

/etc/nginx

/etc/nginx

/usr/local/etc/nginx

site-availaЫe/

Нет заранее заданного места

Конфигурация виртуального хоста 6 conf . d

s ite-enaЫed/ Пользователь по умолчанию

nginx

www — data

nobody

• необходимо включить репозиторий программного обеспечения EPEL; см. fedo r apro j e c t . o r g / w i ki / E PEL. 6 0тносительно корневого каталога конфигурации.

В файле nginx . conf блоки директив конфигураци и , окруженные фигурн ы м и скоб­ ками , называются контекстами. Контекст содержит директив ы , специфич ные для дан­ ного блока конфигурац и и . Напр и мер , вот м и н и мальная (но пол н ая ) конфигурация NG INX, которая показывает три контекста: even t s { } http { s e rve r s e rv e r name www . a dmi n . com; root / v a r /www/ admi n . com;

Внеш н и й контекст ( называе м ы й ma i n ) я вляется неявн ы м и настраи вает базовую фун кциональность. События и контексты h t tp находятся в контексте ma i n . Контекст even t н еобходим для н астройки обработки соединений. Поскольку в этом примере этот контекст пуст, подразумеваются значения по умолчан ию. К счастью, значения по умол­ чан ию вполне разумные и определяют следующие действия. •

Запускается оди н рабочи й процесс (используется непривил егирован ная учетная запись пользователя).

П рослушивается порт 80, есл и сервер запущен с правами r o o t , ил и порт 8000 в противном случае.

Файлы журналов зап ис ываются в каталог /var/ log/nginx ( выбран н ый во время компиляции ) .

Контекст h t t p содержит все директивы, относящиеся к НТТР-службам веб и прок­ с и-серверу. Контексты s e rve r , определяющие виртуальные хосты, вложен ы в http. Lkz настройки нескольких виртуальных хостов испол ьзуется несколько контекстов s e rve r в разделе h t t p . В раздел s e rv e r n ame можно включить псевдонимы, чтобы установить соответствие между заголовком H o s t и группой поддоменов. _

Глава 1 9. Веб-хостинг

721

http { s e rve r s e rve r n ame a dmi n . c om www . a dmi n . com; root /va r /www / admi n . com; s e rve r { s e rve r_n ame e x ampl e . c om www . e x amp l e . com; ro o t /va r /www / e x amp l e . com;

Ш Обзор регулярных вы ражений см . в разделе 7.3. Значение s e rv e r _ n aтe также может быть регулярным выраже н и е м , а совпадение может быть даже перехвачено и присвоено переменной, которая будет испол ьзоваться в конфигурации в дальнейшем . Испол ьзуя эту функцию, можно реорганизовать преды­ душую конфигурацию следующим образом . http { s e rve r { s e rve r_name — л ( www . ) ? ( ? ( e x amp l e l admi n ) . com ) $ ; ro o t /va r /www / $ doma i n ;

Ре гул я р ное в ыраже н ие , которое н а ч и нается с тил ьд ы , с оответствует строкам ехатр l е . с от или a dтi n . с от, перед которыми могут стоять символы www. Значение со­ ответствующего регулярному выражению домена сохраняется в переменной $ doтa i n , которая затем испол ьзуется дл я определения того, корен ь какого сервера выбрать. 1 9 Виртуальн ые хосты н а основе имен можно отличить от хостов на основе I Р-адреса, используя вместе директивы l i s t e n и s e rve r пате. s e rve r ( l i s ten 1 0 . 0 . 1 0 . 1 0 : 8 0 s e rv e r_n ame a dmi n . c om www . a dmi n . com; root /va r /www / a dmi n . com/ s i t e l ; s e rve r { l i s ten 1 0 . 0 . 1 0 . 1 1 : 8 0 s e rve r_name admi n . c om www . a dmi n . com; root / va r / www / a dmi n . com/ s i t e 2 ;

Эта конфигурация создает две верс и и сайта a dт i n . с от, которые обслужи ваются из разных корневых каталогов. I Р-адрес интерфейса, на который был получе н запрос , определяет, какую версию сайта видит клиент. Каталог r o o t это базовый каталог, в котором хранятся H T M L, изображения, таб­ лицы стил е й , сценар и и и другие файлы для виртуального хоста. По умолч анию веб­ сервер N G I NX просто выбирает файл ы из каталога roo t , но для более сложной марш —

19 И мейте в виду, что использование этого с и нтаксиса обязывает веб-сервер NG INX выполнять проверку ре гулярного выражения для каждого НlТ Р-заnросом. М ы испол ьзуем его здесь, чтобы продемонстрировать гибкость N G I NX, но на п рактике вы, вероятно, захотите просто перечислить все возможные имена хостов в виде простого текста. Разумно исnоЛhЗОвать регулярные выражения в файле nginx . conf, но убедитесь. что они соответствуют реальным значениям, и старайтесь поддерживать их в нижней части иерархи и конфи гурации, чтобы они а кти визировались тол ько в определенных ситуациях.

722

часть 1 1 . Работа в сетях

рутиза ц и и запросов можно использовать директиву l o c a t i o n . Если задан н ы й путь н е соответствует директиве l o c a t i o n , веб-сервер N G I NX автоматически возвращается к базовому каталогу r o o t . В следующем примере ис пол ьзуются директивы l o c a t i o n и p r o x y_p a s s . О н и и н ­ структируют N G I NX обслуживать бол ьш и н ство запросов и з кор н е вого катало га веб­ хоста, но перенаправляют запрос ы к веб-сайту h t t p : / / www . a dmi n . com/ n g i n x на сайт nginx . org. s e rv e r { s e rv e r name a dmin . com www . admi n . c om ; r o o t /va r / ww w / a dmi n . com; location /nginx / { p r ox y_p a s s h t tp : / / n g i n x . o r g / ;

Директ и ва p r o x y _p a s s и нструктирует веб-сервер NG I N X действовать как прокс и ­ сер вер и перенаправлять запрос ы о т кл иентов н а другой сервер. М ы е щ е н е раз стол к ­ немся с директивой p roxy_pa s s , когда будем описывать ис пользование NG I N X в каче­ стве балансировщика нагрузки в разделе » Балансировка н агрузки с помощью NG I NX » . Директива l o c a t i o n м ожет испол ьзовать регулярные выраже н и я для выпол н е н и я пол ноценной маршрутизаци и в разн ые источн и к и на основе запрош енного содержимо­ го. Описание того , как веб-сервер NG I NX выпол няет директивы s e rve r_name , l i s t e n и l o c a t i o n для маршрутизаци и запросов , приводится в его официал ьной документаци и . Чаще всего в дистрибутивах устанавливаются разумные стандартные значения для м но­ гих директив в глобальном контексте h t t p , а зате м используются директивы i n c l u d e дл я добавления виртуальных хостов для конкретного сайта в окончательную конфи гураци ю. Например, файл nginx . conf в системе UЬuntu по умолчанию содержит строку i n c l ude / e t c / n g i nx / c o n f . d / * . con f ;

Эта структура помогает устран ить и зб ыточ ность, поскол ьку все дочер н и е объекты наследуют глобал ьн ы е настрой к и . Ад м и н и страторам в п ростых средах , возможно, не н ужно н ич е го делать, кроме как описать конфигураци ю виртуал ьного хоста , вы раже н ­ н у ю в контексте s e rv e r .

Настрой ка TLS дл я NGINX Н ес м отря н а т о что стил ь конфигурации неб-серве ра N G I NX м ал о похож н а стил ь конфигурации Apache, е го конфигурация TLS — это одна из областе й , в которой это не так . Как и в Apache, все ключевые слова конфигурации относятся к S S L, более раннему и м е н и TLS. Вкл ючение TLS, а также указание файла сертификата и закрытого ключа в ыполняет­ ся следующим образо м . s e rv e r { l i s ten 4 4 3 ; s s l on ; s s l c e r t i f i c a t e / e t c / s s l / c e r t s / admi n . c om . c r t ; s s l_ce r t i f i c a t e _k e y / e t c / s s l / p r i v a t e / a dmi n . c om . c r t ; s s l_p r o t o c o l s T L S v l T L S v l . 1 T L S v l . 2 ; s s l _ c i p h e r s ECDHE- RSA-AE S 1 2 8 -GCM — S HA2 5 6 : ECDHE . . # с трока о бреза на s s l _p r e f e r_ s e rver_ciphe r s on ; .

Глава 1 9 . Веб-хостинr

723

s e rve r n ame a dmi n . com www . a dmi n . com; root /va r /www / a dmi n . c om/ s i t e l ;

Должн ы быть вкл юче н ы тол ько фактические протокол ы T L S (а не стары е верси и SSL); все протоколы S S L устарели. П рава доступа к файлам сертификата и ключа долж­ ны соответствовать рекоме ндациям , изложен н ы м в подразделе , посвященном настрой ке протокола TLS дЛЯ неб-сервера Apache , раздела 1 9.4. Используйте директиву s s l c i p he r s , чтобы затребовать использование криптогра­ фически сил ьн ых ал горитмов шифрования и отключать более слабые ш ифры . П араметр s s l _pr e f e r_ s e rve r c ip h e r s в сочетании с s s l _c iphers инструктирует N G I NX выби­ рать шифр из с писка сервера, а не из клиента. В противном случае кл иент мог бы пред­ ложить л юбой шифр, который ему понравился . ( В предыдущем примере не отображается полный список алгоритмов ш ифрования, потому что соответствующий список довольно длинный; подробности представлены в руководстве Mozila Server Side TSL. Если вы пред­ почитаете более короткий список ш ифров, загляните на сайт c i p he r l i . s t .)

Баланси ровка нагрузки с помощью NGINX Веб-сервер N G I NX также выступает мощн ы м балансировщиком нагрузки. Его стил ь конфигурации является гибким , но несколько неочевидны м . Дл я созда н и я и м е нован н ых груп п серверов и с п ол ьзуйте м одул ь u p s t r e a т . Например, следующий раздел определяет группу a dтi n — s e rve r s как набор и з двух сер­ веров. up s t r e aт a dmi n — s e rv e r s { s e rve r weЫ . a dmin . com : 8 0 8 0 ша х f a i l s s e rve r web2 . a dm i n . com : 8 0 8 0 max f a i l s —

2; 2;

На групп ы u p s t r e am можно ссылаться из определения виртуальных хостов . В част­ ности , они могут испол ьзоваться в качестве прокси -адресов, как и имена хостов. http s e rve r { s e rve r_name a dmi n . com www . admi n . com; l o c a t i on / { p r o x y_p a s s h t tp : / / admi n — s e rve r s ; h e a l t h che c k i n t e r va l = З O f a i l s = З p a s s e s = l u r i = / he a l t h_ch e c k ma t ch=admi n — h e a l t h # в оригина л е с трока н е ра зрыв а е тся

ma t c h a dmi n — h e a l t h { status 2 0 0 ; h e a d e r C o n t e n t — T yp e = t e x t / h tml ; body — » Re d L e a de r , S t a n d i n g В у » ;

Здесь трафи к сайтов a dmi n . сот и www . a dт i n . с от обрабаты вается серверами wеЫ и web2 в цикл ическом порядке (по умолчанию). Эта конфигурация также устанавл и вает проверки работоспособ ности дЛ Я рабоч их неб-серверов. П роверки выполняются каждые 30 с ( i n t e rva l = З O ) дЛ Я каждого сервера в конечной точке / h e a l th c he c k ( u r i = / h e a l th _ c h e c k ) . NG I NX отмечает сервер как неработоспособ н ы й , если проверка работос пособности заверш ится неудачно после трех

724

Часть 11. Работа в сетях

последовател ьных попыток ( f a i l = З ) , но вернет сервер в ротацию, если он пройдет про­ верку хотя бы оди н раз ( pa s s = l ) . Ключевое слово ma t c h особе н но характерно для N G I NX. Оно определяет условия , п р и которых проверка работос пособности сч итается успешной. В этом случае веб­ сервер N G I NX должен получить код ответа 2 0 0 , заголовок C o n t e n t — T yp e должен быть установлен рав н ы м t e x t / h tm l , а тело ответа должно содержать фразу » R e d L e a d e r , S tanding Ву». М ы добавили в контекст uрs t r е а m дополн ительное условие, которое устанавливает, что максимал ьное кол ичество попыток подкл ючения должно быть равным двум. И наче говоря , если веб-сервер N G I NX вообще н е может подключиться к серверу после двух попыток, то он отказывается от этого сервера и удаляет е го из пула. Эта провер ка соеди­ н е н ия допол няет более структурированные проверки из раздела h e a l t h c h e c k . _

1 9.6. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ HAPROXY H A Proxy я вляется наиболее ш ироко используе м ы м програм м н ы м обесп е ч е н и е м для баланс ировки нагрузки с открытым исходным кодом . Оно позволяет проксировать трафи к по протоколам НТТР и ТСР, поддержи вает личные сеанс ы для привязки данно­ го клиента к определен ному веб-серверу и предлагает рас ш и ре н н ые возможности про­ верки работоспособности . Последние верси и также поддерживают протоколы TLS, I Pvб и сжатие для протокола Н ТТ Р. Поддержка НТТР/2 е ще не завершена и , как ожидается , появится в верси и HAProxy 1 . 7. Конфигурация HAProxy обычно содержится в одном файле haproxy . cfg. Она на­ стол ько простая , что поставщики операцио н н ы х с исте м обы ч н о н е усложн я ют себе жизнь и испол ьзуют структуру каталогов по умолчанию, рекомендова нную проектом. В с исте мах Deblan и R H E L конфигурация находится в файле / e t c / haproxy/ haproxy . cfg. Система Free B S D не предоставляет значен ие п о умолчан и ю , так как на самом деле для него не существует разумной рекомендации — все полностью зависит от вашей конфи гураци и . П ри мер конфигурации в системе Fre e B S D можно найти в ка­ талоге /usr/local/ share/examples/haproxy после установки пакета HAProxy. Следующая простая при мерная конфигурация позволяет HAProxy прослуш и вать порт 80 и распределять запросы с помощью цикл и ческого режим а м ежду двумя веб­ серверам и wеЫ и we b 2 , запуще н н ы м и на порту 8080. g l ob a l daemon max conn 5 0 0 0 de f a u l t s mode h t t p t ime out c o n n e c t 5 0 0 0 # Mi l l i s e c onds t ime o u t c l i e n t 1 0 0 0 0 t ime out s e rve r 1 0 0 0 0 f rontend http-in Ьind * : 8 0 d e f a u l t b a c kend web s e rv e r s b a c kend web s e rve r s balance roundroЬin s e rv e r wе Ы 10 . 0 . 0 . 10 : 8080 10 . 0 . 0 . 1 1 : 8080 s e rv e r web2

Глава 1 9. Веб-хостин г

725

Использован ие кл ючевых слов f r o n t e nd и b a c kend для конфи гурировани я НАРгоху показано на рис. 1 9. 7 . frontend

порт 80

Клиенты

HAProxy

backend

перенаправляет запросы на веб-серверы, прослушивающие порт 8080

Веб-серверы

Рис. 1 9. 7. Спецификации внеш11их и внутренних серверов НА Ргаху

Дире ктива f ro n t e n d определ яет, как программа HA Proxy будет обрабаты вать запро­ сы от кл иентов: какие адреса и порты испол ьзовать, какие типы трафика обслуживать и другие ориентированные на кл иента моменты . Директива b a c k e n d настра и вает набор серверов, которые фактически обрабаты ­ вают запрос ы . В одной конфигурации могут существовать нескол ько пар директи в f ro n t e n d / ba c ke n d , позволяя одному балансировщику нагрузки HAProxy обслужи вать нескол ько сайтов. Н астрой к и t i me o u t позвол я ют осуществл ять тщател ьн ы й контрол ь над тем , как дол го систе ма должна ожидать при поп ытке открытия нового соединения с сервером и как долго нужно держать соеди нения открыты м и после их установки. Точная настрой ­ к а этих значен ий важна дл я загруже н н ы х веб-серверов. В локал ьных сетях значе ние t ime o u t c o n n e c t может быть довол ьно н изки м ( 500 мс ил и меньше ) , потому что новые соеди нения устанавли ваются очен ь быстро.

П роверки работоспособности Хотя предыдущая конфигурация обес печивает базовые фун кци и , она не проверяет состоя ние нижестоящих веб-серверов. Есл и один из серверов wеЫ ил и web2 перестанет отвечать на запросы , половина входящих запросов даст сбой. Фун кция проверки состоя н ия HAProxy вы полняе т р е гул я р н ы е Н ТТ Р — запрос ы для определения работоспособности каждого сервера. П ока серверы отвечают кодом от­ вета Н ТТ Р 200, они сч итаются в работоспособном состоя нии и продолжают получать запросы от балансировщика нагрузки . Есл и сервер не проходит проверку работоспособности ( возвращая что-либо, кроме кода состоя ния 200), то программа HAProxy удаляет е го из пула. Однако HAProxy про­ должает в ыполнять проверки работоспособности этого сервера. Если он снова начнет отвечать успеш но, то программа HAProxy вернет его в пул. Все параметры проверки работос пособности , такие как метод запроса, и нтервал между проверками и U RL запроса, могут быть скорректирован ы . В следующем примере HAProxy выполняет запрос GET для каталога / на каждом сервере каждые 30 с : b a c kend w e b s e rve r s bal ance roundrobin op t i on h t t p c h k GET / s e rve r wеЫ 1 0 . 0 . 0 . 1 0 : 8 0 8 0 c he c k i n t e r 3 0 0 0 0 s e rv e r web2 1 0 . 0 . 0 . 1 1 : 8 0 8 0 c he c k i n t e r 3 0 0 0 0

Часть 11. Работа в сетях

726

Конечно, неплохо, что существует возможность связаться с неб-сервером маш и н ы , но это едва л и последнее слово в отношен ии получения состоя н и я сервера. Хорошо спроектированн ые неб-приложе н ия обыч но предоставл я ют конеч ную точку для п ро­ верки работоспособн ости , которая позволяет тщател ьно проанал изиро вать приложе ­ н и е , чтобы о предел ить е го исти н н ое состоя ние. Эти проверки могут вкл ючать про­ верку подключения к базе дан н ых ил и кешу, а также мон иторинг производител ьности . Испол ьзуйте эти более сложные проверки , есл и он и доступн ы .

Статисти ка сервера П ро гра м м ное обеспечение HAProxy предлагает удобн ы й неб-и нтерфе йс, котор ы й отображает статистику сервера , так ж е как модул ь mod_s tatus в веб-сервере Apache. Версия HAProxy показывает состоян ие каждого сервера в пуле и позволяет вруч ную вкл ючать и отключать серверы по мере необходи мости. Синтаксис прост: l i s ten stats : 8 0 0 0 mod e h t t p stats еnаЫе s t a t s h i d e — ve r s i on s t a t s r e a l m HAP r o x y S t a t i s t i c s stats uri / s t a t s a u t h myu s e r : mypa s s s t a t s admin i f T RUE

Статистика сервера может быть настроена как внутри кон кретного слушателя , так и внутри блоков f ro n t e n d и b a c kend, чтобы ограничить функцию только этой конфи­ гурацией.

Л и пкие сесси и НТТР это протокол без сохранения состоя н и я , поэтому каждая транзакция я вл я ­ ется независим ым сеансом. С точки зрения протокола запросы о т одного и того ж е кл и ­ ента не связаны между собой. В то же время большинство неб-приложений н уждаются в возможности отслежи вать поведение пол ьзователе й с течением времени. Классическим примером состояния яв­ ляется корзина для покупок. Пользовател и прос матривают магази н , добавля ют товары в корзину, и, когда они готовы оплатить покупки , отправляют свои платежные дан н ы е . Неб-приложение должно и м еть возможность для отслеживания содержимого корз и н ы на протяжен и и нескол ьких просмотров стран иц. Для отслежи ван ия состоя н ия бол ь ш инство веб- приложе н и й испол ьзуют систему c o o k i e . Неб-прил ожен и е создает сеанс для пол ьзователя и помещает идентифи катор сеанса в параметр c o o k i e , который отправляется обратно пол ьзователю в заголовке от­ вета. Каждый раз, когда кл иент отправляет запрос на сервер, вместе с н им отпрааляется и параметр c o o k i e . Сервер испол ьзует значение параметра c o o k i e для восстаноаления контекста клиента. В идеале неб-приложения должн ы хранить свою и нформацию о состоянии в постоян ­ н о м и общем хранил и ще, таком как база данных. Однако некоторые плохо упрааляемые веб-приложения сохраняют свои данные сеанса локально, в памяти сервера или на ло­ кальном диске. Когда они разме щаются за балансировщиком нагрузки , эти приложения прерываются , потому что запросы одного кл иента могут напраалятъся на несколько сер­ веров, в зависимости от капризов алгоритма планирования балансировки нагрузки . —

Глава 1 9. Веб-хостинг

727

Чтобы реш ить эту проблему, НАРгоху может вставить собстве н н ы й параметр c o o k i e в ответы , что назы вается липкими сессиями (sticky sessions) . Л юбые будущие запрос ы от одного и того же клиента будут содержать этот параметр c o o k i e . HAProxy может ис­ пользовать значение c o o k i e для перенаправления запроса на один и тот же сервер. Верс ия предыдуще й конфигураци и , модифицирован ная дл я поддержки л и п ких сесс и й , в ы гл ядит следующим образо м . Обратите внимание на добавление дире ктивы coo k i e . backend we b s e rve r s b a l a n c e roundrob i n op t i on h t t p c h k G E T / c o o k i e SERVERNAME i n s e r t h t tpon l y s e cu r e s e rv e r w е Ы 1 0 . 0 . 0 . 1 0 : 8 0 8 0 c o o k i e w е Ы che c k i n t e r 3 0 0 0 0 s e rve r web2 1 0 . 0 . 0 . 1 1 : 8 0 8 0 c o o k i e web2 c he c k i n t e r 3 0 0 0 0

В этой конфигурации HAProxy поддерживает параметры coo k i e SERVERNAМE дл я от­ слеживания сервера, с которым работает клиент. Ключевое слово s e c u r e указывает, •по значение c o o k i e следует отправлять только через ТLS-соеди нения, а ключ евое слово h t t p o n l y сообщает браузерам использовать c o o k i e тол ько через п ротокол НТТР. Для получения допол нительной информации об этих атрибутах обратитесь к специфика11 и и RFC6265.

П рекра щен ие испол ьзования TLS HAProxy 1 . 5 и более поздние версии включают поддержку T LS. Общая конфигурация закл ючается в прекраще нии испол ьзования протокола TLS на сервере HAProxy и вза и ­ модействия с внутрен н и м и веб-серверами через обыч н ы й протокол НТТР. Этот подход разгружает внутре н н и е веб-сервера от рас шифровки криптографического содержимого и умен ьшает кол ичество систе м , которым необходим закрытый ключ. Для сайтов с особыми требованиями к безопасности также можно испол ьзовать про­ токол Н ТТРS для взаимодействия НАРгоху с внутренними серверам и . Для этого можно испол ьзовать один и тот же сертификат TLS или другой; в любом случае прокси -сервер должен будет прервать сеанс протокола TLS и повторно возобновить его для взаимоде й­ ствия с внутре н н им и неб-серверами. П оскольку HAProxy преры вает соеди нение TLS с клие нтам и , необходи мо доба вить соответствующие параметры в блок конфигурации интерфейса. frontend https -in b i nd * : 4 4 3 s s l c r t / e t c / s s l / p r i v a t e / a dmi n . c om . p em de f a u l t b a c kend web s e rve r s

Веб-серверы Apache и NG I NX требуют, чтобы закрытый ключ и сертификат храни­ лись в отдел ьных файлах в формате РЕМ, но НАРгоху ожидает, что оба ком понента бу­ дут присутствовать в одном файле. Можно просто объеди нить отдельные файлы для со.з­ дан ия составного файла: # cat /etc / s s l / { private/ admin . com . key , certs/ admin . com . crt } > /etc / s s l /private/ admin . com . pem # chmod 4 0 0 /etc/ ssl /private/ admin . com . pem # ls -1 /etc/ s s l/private/ admin . com . pem -r 1 r o o t r o o t 3 6 6 0 Jun 1 8 1 7 : 4 6 / e t c / s s l / p r i va t e / admi n . c om . pem — — — — — — — —

П ос кол ьку закрытый кл юч я вляется частью составного файла, убедитесь, что файл принадлежит пол ьзователю root и не доступен для чтения другим пол ьзовател е м . ( Есл и

Часть 11. Работа в сетях

728

вы не запус каете HAProxy от и м е н и r o o t , поскол ьку вам не нужно получать доступ к каким-либо привилегированн ы м портам , убедитесь, что п раво собственности на файл ключа совпадает с идентификатором, под которым запускается HAProxy. ) Все обы ч н ые рекомендаци и для T LS применяются к HAProxy: отключить протоколы эпохи S S L и явно настроить приемлем ые алгоритмы ш ифрования.

1 9 .7. Л ИТЕРАТУРА •

ADRIAN , Dлvю, ЕТ AL.

C ш u o F LARE , I Nc .

Weak Diffie — Hellman and the Logjam A ttack. w e a kdh . o r g . Н а этой странице описывается атака Logjam на протокол обмена кл ючами Диффи­ Хеллмана и предлагаются способы обеспечения безопасности с исте м . Ы о g . c l oud f l a r e . c om. Это корпоратив н ы й блог сети достав­ ки содержимого CloudFare . Некоторые сообщения — всего л и ш ь маркетинговая и нформация , но м ногие из н и х содержат информацию о последних тенде н циях и технологиях в Интернете.

GooG L E , I N c . Web Fundamentals. deve l o pe r s . g o o g l e . c o m / we Ь / f u n da m e n t a l s . Это полезное руководство п о разл и ч н ы м передовы м м етодам веб-разработки , включая разделы по проектированию сайта, пользовательским и нтерфейсам , безо­ пасности , производител ьности и другим темам, представляющим и нтерес для раз­ работчи ков и адми н истраторов. Особенно полезно описани е кешировани я . G RJGORJ K , I LYA. Нigh Performance Browser Ne tworking. O ‘ Re il y M edia. 20 1 3 . И скл ю­ ч ительное руководство по протоколам , преимуществам, ограничениям и аспектам производительности сети. П олезно как для разработч и ков , так и для с исте м н ых адми нистраторов.

IANA. lndex о/ Н ТТР Status Codes. www . i a n a . o rg / a s s i g nmen t s / h t t p — s t a t u s ­ code s .

1 NTE RNAТJONAL ENG J N EERJNG Тлsк FoRc E . Hypertext Transfer Protocol Version 2. h t t р 2 . g i t hub . i o / h t t p 2 — sp e c . Рабочи й проект спецификации НТТР2.

Mozilla. Security/Server Side TLS. w i k i . mo z i l l a . o r g / S e c u r i t y / S e rve r_S i d e T L S . Отл и ч н ы й ресурс , который документирует луч ш ие методы н астройк и TLS на многих платформах.

STE N B E RG , D л N J E L . d a n i e l . h a x x . s e / Ь l o g . Это блог Даниэля Стенберга, автора утилиты curl и авторитетного эксперта по НТТР.

REMY. Strong Ciphers for Apache, nginx, and Lighthttpd. c i p h e r l i . s t . П равильная и безопасная настройка ш ифрования для Apache httpd, N G I NX и веб­ серверов lighttpd, а также инструмента для тестирования конфигурации TLS . vлN E Lsт,

ЧА СТЬ

111

Хра нение данных

глава

20

д исковая память

Систем ы хране н ия дан н ых все больше напоминают фрагменты огромной голово­ лом ки. которые можно соединять друг с другом , создавая бесчисленное множество ва­ р иантов. Из них можно собрать что угодно: от быстродействующего хранилища д;1я кри ­ тически важной базы дан н ых д о огромного архивного хранилища , в котором хра нятся по три коп и и всех данных с возможностью отката в л юбую точку в п рошлом . Механ ические жесткие диски остаются доми нирующим средством д;1я создан ия и н ­ терактивных хранил и щ дан ных, но п р и со:щании высокопроизводительн ых приложений они все чаще вытесняются твердотел ьн ы м и дисками (solid state d rive — SSD), которые луч ш е подходят д;1я приложе н и й , предъявляющих повы ш е н н ы е требования к произ­ водительности. Л учшие сторон ы этих двух технологий можно объеди н ить в одно целое с помощью программ н ых и аппаратн ых кеширующих систе м . На облачн ых серверах обыч но есть выбор оборудования для хране н и я , но за вирту­ альные диски с поддержкой S S D придется платить бол ьше. Можно также выбирать из множества специфических типов хранения , таких как хранил ища объектов, бесконечно расширяемые сетевые диски и реля цион н ые базы дан ных как услуга. Работу этого реал ьного и виртуального оборудования обеспечивает м ножество про­ грамм н ых компонентов, взаимодействующих с физическими устройствами хранения и ие­ рархией файловой системы, которые видят пользователи. Эrи компоненты включают в себя драйверы устройств, соглашения о ра:щелен и и , массивы RAJ D, менеджеры логических то­ мов, системы для виртуализации дисков по сети и сами реализации файловой системы. В главе обсуждаются адми нистративные проблемы и решения , возникающие на каж­ дом из этих уровней. Мы начнем с простых и нструкци й , позволяющих добавить базовый

732

Часть 1 1 1 . Хранение данных

диск в операцион н ых систе мах Liпux или Free BSD. Затем опишем технологи и , лежащие в основе современ ного аппаратного обеспечения для дисковой памяти , и рассмотри м общую архитектуру программного обеспечения для дисковой памяти. Затем м ы опишем проблем ы , связанные с дисковой памятью, начиная с н изкоуровневого форматирования и заканч и вая файловой с истемой. По ходу изложе ния рассмотрим вопросы , связанн ые с логическим разделением дисков, с исте мам и RAI D и менедЖерами логических томов. Н есмотря на то что все производители используют стандартизованное дисковое обо­ рудование , в области программного обеспечения набл юдается огром ное разнообразие. В главах 21 и 22 рассматри ваются две широко распростране н н ы е файловые с исте м ы : N FS для совместного испол ьзования файлов в системах U N IX и Li nux, и S M B дл я взаи­ модействия с истемах Windows и macOS.

20. 1 . ДОБАВЛЕНИЕ ДИСКА Прежде чем погрузимся в м ногостраничное повествование об архитектуре и теории дисковых с исте м , рассмотрим самы й обы ч н ы й сценари й : м ы хоти м и нсталл ировать жесткий диск и сделать его доступн ы м посредством файловой систе м ы . В этом сцена­ рии нет ничего особен ного: нет н икакого массива RAI D , все пространство диска на­ ходится на одном логическом томе, а тип файловой системы выбирается по умолчан ию. Шаг первый — подключить накопитель. Если рассматриваемая машина я вляется об­ лач н ы м сервером, пользователь обычно создает виртуал ьн ый диск требуе мого размера с помощью адми нистративного G U I — и нтерфейса провайдера (или с помощью с воего и нтерфейса A P I ) , а затем присоединяет его к существующе му виртуал ьному серверу в качестве отдельного шага. Обычно нет необходимости перезагружать сервер, посколь­ ку облачные (и виртуальные) ядра распознают такие аппаратные изменения » на лету » . В случае физического оборудования диски , которые обмениваются дан н ы м и через U S В- порт, могут просто подсоединяться и включаться в работу на лету. Приводы SATA и SAS необходимо монтировать в отсеке, корпусе или специал ьной корзине. Хотя неко­ торые аппаратные средства и драйверы предназначены для обеспечения горячего добав­ ления дисков SATA, эта функция требует аппаратной поддержки и необычна в оборудова­ н ии массового рынка. Перезагрузите систему, чтобы убедиться , что операционная система сконфигурирована правильно и адекватно реагирует на внесе н н ые изменения во время загрузки. Если вы используете настол ьную машину с окон ной системой и все настроено пра­ вильно, с истема может предложить вам отформатировать новый диск при его подкл ю­ чении. Это особенно вероятно, есл и вы подключаете вне ш н и й US В-диск или флеш ­ н акопитель. Опция автоматичес кого форматирова н и я обычно работает нормально; испол ьзуйте ее п о возможности. Однако после этого проверьте и нформацию о монтиро­ вании (запустив команду mount в окне терминала) , чтобы убедиться, что диск не смон­ тирован с ограничениями , которых вы не хотели (например, с заблокированным выпол­ нением программ или запретом пол ноцен ного владения файлами). Если вы добавили диск вручную, крайне важно определить и отформатировать пра­ вильное дисковое устройство. Н едавно добавл е н н ы й диск необязательно представлен файлом устройства с наивысш им номером , а в некоторых системах добавление н ового диска может измен ить имена устройств существующих дисков (обычно после переза­ грузки). Дважды проверьте идентификационн ы е дан н ые нового диска, просмотрев е го производителя , размер и номер модели , прежде чем делать что-либо потен циально раз­ рушительное! Используйте команды , упомянутые в следующих двух разделах.

глава 20. дисковая память

733

Рецепт для Linux Сначала вы пол ните команду l sЫk, чтобы получить список дисков с исте­ мы и определить новый диск. Если этот вывод не дает вам достаточной и н ­ формации, чтобы окончательно определить н о в ы й диск, вы можете указать модель и серийные номера с помощью команды l sЫk -о +MODEL , SERIAL. W Описание таблицы разделов GPT с м . в разделе 20 . 6 .

Как тол ько вы узнаете , какой файл устройства относится к новому диску (предпо­ ложи м , что это / dev/ sdb) , создайте табл ицу разделов на диске . Это можно сделать с помощью нескольких команд и утилит, включая parted, gparted, fdi sk, cfdi s k и sfdi sk; н е и м еет значен и я , какую из н и х вы используете , если о н а понимает табли ­ ц ы разделов в стиле G РТ. Утилита gparted, вероятно, самый простой вариант в системе с графическим и нтерфейсом пользователя . Н иже м ы показываем рецепт на основе ути­ литы fdi s k , которая работает во всех Linux-cиcтeмax. (В н екоторы х с истемах команда parted по-прежнему не поддерживает схему разбиения диска в стиле G РТ. ) $ sudo fdisk /dev/ sdЬ W e l c ome t o f d i s k ( u t i l — l inux 2 . 2 3 . 2 ) . Chang e s w i l l rema i n i n memo r y on l y , unt i l you d e c i d e t o wr i t e t h em . Ве c a r e f u l b e f o r e u s i ng t h e w r i t e c ommand . Command ( m f o r h e lp ) : g Bui l d i n g а n e w GPT di s k l a b e l ( GU I D : AB 7 8 0 4 3 8 — DA 9 0 — 4 2 AD — 8 5 3 8 — E EC 9 6 2 6 2 2 8 C 7 ) Command ( m f o r h e lp ) : n Pa r t i t i on n umb e r ( 1 — 1 2 8 , de f a u l t 1 ) : Fi r s t s e c t o r ( 2 0 4 8 — 1 0 4 8 5 7 5 9 6 6 , de f a u l t 2 0 4 8 ) : L a s t s e c t o r , + s e c t o r s or + s i z e { K , M , G , T , P } ( 2 0 4 8 — 1 0 4 8 5 7 5 9 6 6 , de f a u l t 1 0 4 8 5 7 5 9 6 6 } : C r e a t e d p a r t i t i on 1 Command ( m f o r h e lp ) : w The p a r t i t i on t а Ы е h a s b e e n a l t e re d ! C a l l i ng i o c t l ( ) Syncing di s k s .

to r e — r e a d pa r t i t i on t а Ы е .

П одкоманда g создает табли цу разделов G РТ. П одкоманда n создает нов ы й раздел ; нажатие клавиш и < Enter> в ответ на все вопросы утилиты fdi sk в ыделяет все свобод­ ное пространство для нового раздела (раздел ) . Наконец, подкоманда w записывает но­ вую табл и цу разделов на диск. Файл устройства для вновь создан ного раздела совпадает с файлом устройства для диска с добавлением 1 к его имени. В приведен ном выше примере разделом являет­ ся /dev/ sdЫ . Теперь вы можете создать файловую с истему на устройстве /dev/ sdЫ с помощью команды mkfs. Опция -L присваивает файловой системе короткую метку (здесь, s p a r e , т.е . запасной ) . Эта метка не меняется, даже если устройству, содержащему файловую си­ стему, будет назначено другое имя во время последующе й загрузки.

часть 111. Хранение данных

734 $ sudo mkfs -t ext4 -L spare /dev/ sdЫ mke 2 f s 1 . 4 2 . 9 ( 2 8 — D e c — 2 0 1 3 ) D i s c a r d i n g devi c e Ы o c k s : done F i l e s ys t em l a b e l = s p a r e OS t yp e : L i nu x B l o c k s i z e= 4 0 9 6 ( l og = 2 )

Далее мы создаем точку монтирования и монтируем новую файловую систему. $ sudo mkdir / spare $ sudo mount LAВEL=spare / spare

Как способ идентифи к ац и и раздела м ы могл и бы указать / dev / s dЫ в место LAВEL=spare, но это и м я не обязательно будет работать в будущем. Чтобы файловая с истем а автоматически монтировалась во врем я загрузки , отредак­ тируйте файл /etc/f s taЬ и продублируйте одн у из существующих записе й . Измените имя устройства и точку монтирования в соответствии с параметрами приведе нной выше команды монтирования. Например, LABEL= s p a r e

/ sp a r e

e r r o r s = remount — r o

ext4

О

О

Для идентификаци и файловой с истем ы можно также испол ьзовать идентификатор U U I D (см . раздел 20. 1 0) . П одробное описание файлов устройств с исте м ы Linux приведено в разделе 20.4. Информацию о раздел ени и диска с м . в разделе 20.6. Информация о файловой с истеме ext4 приведена в разделе 20. 1 О .

Рецепт для FreeBSD Выпол ните команду geom disk l i s t для отображения дисковых устройств, о которых известно ядру. К сожал е н и ю , с истема Fre e B S D не раскрывает н икакой и нформации , кроме имен и размеров устройств. С помощью команды geom d i s k l i s t можно устранить л юбую двус мыслен ность отно­ с ительно диска и узнать, какие устройства и меют существующие разделы . Неформ атированный диск н е должен иметь разделов. Как только вы узнаете имя диска, вы можете создать на нем табли цу разделов и фай ­ ловую с истему. В этом примере м ы предполагаем , что имя диска adal и что м ы хотим подключить новую файловую систему как / spare. $ sudo gpart create — s GPT adal adal created

# С о здаем таблицу разделов GPT

$ sudo gpart add — 1 spare — t freeЬsd-ufs ada l p l added

lM adal # Создаем р а здел

$ sudo newfs -L spare /dev/adalpl # Создаем файловую сист ему /dev / ada l p l : 5 1 2 0 . ОМВ ( 1 0 4 8 5 6 8 0 s e c t o r s ) Ы о с k s i z e 3 2 7 6 8 , f r a gment size 4096 u s i n g 9 c y l i n de r g roups o f 6 2 6 . 0 9МВ , 2 0 0 3 5 Ы ks , 8 0 2 5 6 i n o de s . s u pe r — Ы o c k b a c kup s ( fo r f s c k_f f s -Ь # ) a t : 1 92 , 1 2 8 2 4 32 , 2 5 6 4 67 2 , 3 8 4 69 1 2 , 5 1 2 9 1 5 2 , 64 1 1 3 9 2 , 7 6 9 3 6 3 2 , 8975872 , 10258112

Глава 20. дисковая память

735

Параметр — 1 команды gpart add назначает текстовую м етку к новому разделу. Метка делает раздел доступн ы м через путь / dev/ gpt/ spare независ и м о от и м е н и устройства, которое ядро назначает базовому дисководу. Опция — L коман д ы newfs п р и м е няет ана­ логичную (но другую) метку к новой файловой систе м е , чтобы сделать раздел досту п ­ ным как /dev/uf s / spare. Смонтируйте файловые системы с помощью следующих команд. $ sudo mkdir / spare $ sudo mount /dev/ufs/ spare / spare

Для того чтобы с монтировать файловую с исте м у во вре м я загрузки , добавьте е е в файл /etc / f s taЬ (см. раздел 20. 1 0) .

20.2 . АППАРАТНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ХРАНЕНИЯ ДАН НЫХ Даже после поя вл е н ия Интернета существует вс е го нескол ько основн ы х с пособов хранения ком п ьютерн ы х дан н ых: на жестких дис ках, во фле ш — памяти , на магнитн ы х лентах и на оптических носителях. П оследние две тех н ол о г и и и м е ют существен н ые ограничения, которые не позволяют использовать их в качестве основной файловой си­ стемы. Те м не менее они по-прежнему и ногда испол ьзу ются для резервного коп и рова­ ния и для автоном ных хранилищ, в которых м гнове н н ы й доступ и возможность переза­ писи не я вляются первоочередны м и . П осле 40-летнего господства традиционной техн ологи и на магнитны х д ис ках раз­ работч ики систе м , ориентирован н ых на производ ител ь ност ь наконец получили прак­ тическую ал ьтернативу в виде твердотел ьных дисков ( S S D ) . Эти устройства н а основе флеш -памяти предлагают различные комбинации ко м п р о м и ссов со стандартн ы м дис­ ком , которые будут вл иять на архитектуру баз дан ных, файловых с и стем и операцион­ ных систе м в течение многих лет. В то же время тради ционн ы е жесткие диски п родол жают экспон е н ц и ал ьное увели­ чение своей ем кости. Тридцать лет назад, на заре фор м ф актора 5 , 25 » , который остается в употреблении и сегодня, жесткий диск емкостью 60 Мбайт стоил 1 000 долл . Се годня обы ч н ый накопитель ем костью 4 Тбайт стоит около 1 25 дол л . Так и м образом , сегодн я за те ж е ден ьги можно сохран ить более ч е м в 500 ты с я ч раз бол ьше и н фор м ац и и , т. е . отношение объема памяти к стоимости удваивалось каждые 1 ,6 года. В теч е н и е того же периода пропус кная способность приводов м ассового р ы н ка последовательно увеличи­ валас ь с 500 Кбайт/с до 200 М байт/с , что характеризуется сравн ител ьно незначительным множителем , равн ы м 400. Время поиска с произвольным доступ о м п о ч т и н е измен и ­ лось. Чем больше меняется м и р , тем больше в нем ос тае тс я прежн его. Размеры дисков указываются в гигабайтах, которые рав н ы м илл иардам байтов, в от­ личие от памяти , которая указывается гибибайтах, т е 230 ( 1 07774 1 8 24) байтов. Разница составляет около 7 % . Обязательно проверяйте свои устройства п р и о це н ке и срав н е н и и емкости . Жесткие диски и SS D-устройства очен ь похожи в том с м ысле , что о н и могут зам е ­ нять друг друга, п о крайн ей мере на аппаратном ур о в н е О н и и с п ол ьз у ют т е ж е аппарат­ ные и нтерфейсы и интерфейсные протокол ы . И все же они и м е ют очень раз н ы е с иль­ ные сторон ы , как видно из табл . 20. 1 . ,

.

.

.

W Дополн ительную информаци ю о еди ницах I EC ( гибибайтах и п рочем ) см. в разделе 1 . 6 .

Часть 111. Хранение данных

736

Таблица 20. 1 . Сравнение технопоrий HDD и SSD• Характеристика

HDD

SDD

Типичный размер Время произвольного доступа Последовательное чтение Пр оизвольное чтение IOPS6 Стоимость Надежность Ограничение количества записей

< 1 6 ТБайт 8 мс 200 Мбайт/с 2 Мбайт/с 1 50 операций/с 0 , 03 долл./Гбайт Низкая Нет

< 2 Тбайт 0 , 25 мс 450 Мбайт/с 450 Мбайт/с 1 00000 операций/с 0 , 26 до лл /Гба й т Низкая• Теоретически .

• Про изводител ьность и стоимость приведены по состоянию на середину 20 1 7 г. 6 Операций ввода-вывода в секунду. • Мен ьше полных отказов устройств, чем у HDD, но более частые потери данных В следующих разделах м ы подробно рассмотри м каждую из этих технологи й , а также более новую категори ю устройств хранения данных — mбридн ые приводы .

Жесткие диски Обычн ы й жесткий диск состоит и з нескол ьких вращающихся пластин , покр ытых магнитным слое м . Считывание и запись данных осуществляются с помощью маленьких плавающих над поверхностью диска головок, смонтированн ых на металл и ческом рычаге, которы й перемещает их вперед и назад. Головки расположен ы близко к поверхности пла­ сти н , но не прикасаются к ним. Считывание с пластин ы осуществляется довольно быстро. Однако перед этим нужно механически переместить головку к требуемому сектору диска, что существенно снижа­ ет скорость произвольного доступа к дан н ы м . П р и этом существует два основных ис­ точн ика задержки. Рычаг, на котором расположен ы головки , должен резко перескакивать на соответ­ ствующую дорожку. Вре м я , которое требуется для этого, назы вается задержкой поис­ ка (seek delay) . Затем с истема должна подождать, пока требуе м ы й сектор не окажется под головкой при враще н и и пластин ы . Время, которое требуется для этого , называется временем ожидания (rotational latency) . Если последовател ьность операций чтения орга­ н и зована оптимал ьно, то диски могут передавать данные со скоростью до сотен мега­ байтов в секунду, но с корость п роизвол ьного доступа в луч ш е м случае составляет не­ сколько мегабайтов в секунду. Совокупность дорожек н а разных пласти нах , которы е находятся на один аковом расстоян и и от оси вращен и я , называется цилиндром. Дан н ы е , расположе н н ы е на ц и ­ л и ндре , можно считывать, н е перем е щая рычаг. Несмотря на т о что головки работа­ ют чрезвычайно б ыстро, о н и перемещаются намного медленнее, ч е м вращается диск. Следовательно, л юбой доступ к диску, не требующий перемещения головки в новую по­ зицию, будет выпол няться быстрее. Со временем скорость вращен и я пластин увеличилась. В настоящее время стандарт­ н ая с корость вращения дисков массового производства, ориентирован ных на высокую скорость доступа, составляет 7 200 оборотов в м инуту ( revolutions per minute RPM), а л уч ш ие диски дости гают скорости 1 О и 1 5 тысяч оборотов в м ин уту. Более высокая скорость вращен ия умен ьшает врем я ожидания и увеличивает пропус кную с пособность при передаче дан н ых, но при этом диски сильнее нагреваются. —

Глава 20. дисковая память

737

Надежность жестких д исков Жесткие диски довольно часто выходят из строя. В 2007 году подразделение Google Labs, изучив 1 00 тыс. дисков, удивило техническое сообщество сообщением, что средний еже­ годный процент отказов (annual failure rate — AFR) жестких дисков, проработавших более двух лет, превышает 6%, что намного больше показателя , предсказанного производителя­ м и на основе экстраполяции результатов краткосрочных тестирований. Поведение дисков можно описать так: несколько месяцев риска «детской смертности» , два года безупречной работы , а затем ежегодный процент отказов взлетает до 6-8 % . В целом вероятность пяти­ летнего » выживания» жестких дисков в исследовании ком пании Google не превышает 75%. Интересно, что компания Google не нашла корреляции между процентом отказов и дву­ мя факторами внешней среды, которые ранее считались важными, — тем пературный режим работы и активность диска. Полный отчет можно найти по адресу: goo . g l /Y7 S e n k. Совсем недавно компан ия BackЫaze, поставщик облач ных хран ил и щ , стала регу­ лярно публиковать свои сообщения о надежности различных моделе й жестких дисков на сайте b a c kЫ a z e . c om / Ы o g . Эти данные на 1 0 лет более поздние, чем оригинальное исследование Google, но предлагают одн у и ту же основную схему: сначала наблюдается высокий уровень сбоев, затем два-три года бесперебойной работы, а затем стремитель­ ный рост среднегодовой частоты отказа. Абсолютн ые цифры тоже довольно близки .

Вид ы сбоев и показатели на д ежности Сбои жестких дисков обычно возн икают из-за дефектов поверхности диска ( плохих блоков) или механических повреждений. Приводы пытаются автоматически исправлять ошибки первого вида и переназначать восстановленные данн ы е на другую часть диска. Когда секторы с ошибками становятся видны на уровне операционной систе м ы (т. е . от­ ражаются в систе м н ых журналах) , это означает, что дан н ы е уже потерян ы . Это плохой признак; вытащите привод из ком пьютера и замените е го. Прошивка и аппаратный интерфейс диска после сбоя обычно остаются работоспособ­ ными, и часто бывает интересно попытаться получить подробную информацию о том , что произошло с диском (см . раздел 20.4). Тем не менее диски настолько де шевы , что редко стоит делать это по экономически м соображениям , за исключением, возможно, обучения. Надежность диска производители обычно измеря ют с помощью средн его врем е н и наработки на отказ (mean time between failures — M T B F) , которое измеряется часам и . Обычно значен ие показателя MTB F у промышленного диска составляет 1 , 2 м л н часов. Однако этот показатель носит статистический характер и означает, что кон кретный диск проработает 1 40 лет до первого сбоя . Показатель MTBF я вляется обратн ы м по отношению к показателю AFR (Annualized Failure Rate , или частота сбоев за год) , вычисленному для установившегося режима ра­ боты диска, т.е . после включения в систе м у, но до износа. Показатель MTB F, указывае­ мый производител я м и и равный 1 ,2 млн часов, соответствует показателю AFR, равному 0 , 7 % в год. Это значен ие почти (но не совсем ) совпадает с показателем , выявл е н н ы м компанией Google ( 1 -2%) на протяжении первых двух лет работы и х тестовых дисков. Возможно, показатель MTBF, указываем ы й производител я м и , точен , но он получен на основе преднамере н ного подбора дан н ы х о самом благополучн о м периоде работы дисков. Следовательно, этот показатель можно считать лишь верхне й границей надеж­ ности, но его нел ьзя использовать для прогнозирован ия фактического проце нта отка­ зов в долгосрочной перспективе . 1 Основываясь на приведенных выше данн ых, следует 1 Наш технический рецензе нт Джон Корбет (Jon Corbet) называет этот показатель «уровнем надеж­ ности , достоверно не превышающим определенное значение» .

Часть 111. Хранение данных

738

раздел ить показатель MTBF, объявленный производителям и , на 7 ,5 или перейти к более реалистичн ы м методам выявлен ия частоты отказов за пять лет.

Тип ы накопителей Остал ись тол ько два производителя жестких дисков: Seagate и Western Digital . Вы можете увидеть нес кол ько других товарных марок для продажи , но все он и в конечном итоге принадлежат тем же двум компаниям, которые на протяжении десяти лет занима­ лись поглощением конкурентов. Товарные марки жестких дисков подразделяются на нескольких общих категори й . •

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

Диски ДJIЯ массовоrо рынка.

Накопители NAS. NAS означает «сетевое хранил ище» (network-attached storage) , но эти диски предназначен ы дпя использования во всех типах серверов, RАI D-системах и массивах — везде , где размещаются несколько дисков, работающих паралл ельно. Они предназначены для постоян ной работы без выключения , а также дпя баланси­ ровки нагрузки, характеризуются высокой надежностью и низкой теплоотдачей. Контрольные показател и производител ьности , которые характеризуют однополь­ зовательские шаблоны доступа, могут не выявить бол ьшой разницы в производи­ тельности по сравнению с экскл юзивны м и дисками , но NАS — накопители обычно более интеллектуально обрабатывают несколько потоков независимых операций ввода-вывода благодаря настройке прошивки. Н акопител и NAS часто имеют бо­ лее длител ьную гарантию, чем экскл юзивные диски; их цена находится где -то между эксклюзив н ы м и и массовыми дисками .

Это продукты , предназначенные для конечных поль­ зователе й (часто ком п ьютерных и гроков) , имеют более высокую скорость враще­ ния ш п и нделя и бол ьшую кеш — память, чем те , которы е имеют их эквиваленты . В больши нстве тестов они лучше, чем экскл юзивн ые диски. Как и в случае с экс­ клюзивн ы м и дискам и , настройка прошивки подчеркивает однопол ьзовательские шаблоны доступа, такие как бол ьш ие последовательности операций чтения и за­ писи. Эти диски часто работают в напряженном тем пературном режиме.

Промышленные диски . Слово » промы шле н н ы й » (enterprise) в контексте жестких дисков может означать м ного разных веще й , но чаще всего оно означает «доро­ гой » . Здесь вы найдете диски с интерфейсами, отличными от SATA, и необычные характеристи к и , такие как ш п и ндель с ч астотой вращен ия более 1 О ООО оборо­ тов в м и н уту. Это , как правило, накопители премиум — класса с длител ьной (часто до пяти лет) гарантией.

Разл ич и я м ежду эти м и категори я м и дисков наполовину реал ь н ы е , а наполови н у маркетинговые . Все классы дисков отлично работают в о всех приложе ниях, но произ­ водительность и надежность могут различаться. Н акопители NAS — это, пожалуй , луч ­ ш и й универсальны й выбор дпя дисков, чтобы удовлетворить всевозможные потен циаль­ ные потребности . Жесткие диски представля ют собой товар. Одна модель может оказаться луч ш е дру­ гой , и м ея оди наковые частоту вращения шпинделя , и нтерфе йс ап паратного обес пече-

Глава 20. дисковая память

739

н и я и уровен ь надежности. В настоя щее врем я существуют специал изирован ные лабо­ ратори и , которые проводят сравнительный анал из кон курирующих дисков. Надежность — другое дело. Данные компани й Google и BackЫaze демонстрируют су­ ществен н ые различия между моделям и . Наименее надежные чаще дают сбой, чем лучшие. К сожалению, нет никакого способа идентифицировать неудачные модели , пока они не будут проданы в течение года или двух и не создадут себе репутацию в реальном мире. 2 Впроч е м , это н е и меет значения. Даже сам ые луч шие диски могут выйти из строя . Невозможно избежать необходимости резервного копирования и доп олн ительного хра­ нил ища, когда на карту поставлены важн ые дан ные. Проектируйте с вою и нфраструкту­ ру на основе предположения, что диски могут выйти из строя , а затем выясните, скол ь­ ко в этом контексте стоит более надежн ы й диск.

Гарантии и списание Поскольку жесткие диски •1аще требуют гарантийного обслужи ван и я , чем другие типы аппаратного обеспечения, дл ител ьность гарантии ямяется важн ым фактором по­ купк и . П ром ы шле н н ы й стандарт сократился до н ичтожных двух л ет, подозрител ьно близко к длине среднегодового периода бесперебойной работы. Значительное преи му­ щество имеет трехлетняя гарантия , предлагаемая на м ногие диски NAS. Обм е н ы жестких дисков по гарантии выполняются просто, если вы сможете п роде­ монстрировать, что диски не прошл и диагностический тест, предоставл е н н ы й произ­ водителе м . Тестовые п рограм м ы обычно запус каются тол ько в системе Wi ndows и не­ применимы в средах виртуал изации и при испол ьзовании промежуточного аппаратного обеспечения для подключе ния дисков, такого как U S В — переходн ики. Если ваш и опе­ рации влекут за собой частые обм е н ы дис к ов, вы можете счесть н еобходимым поддер­ жи вать выделенный ком пьютер с операционной системой Windows в качестве стан ции для тестирования дисков. Как правило, следует п роямять особое внимание к поя м я ющимся признакам выхо­ да дисков из строя , даже есл и вы не можете достоверно подтвердить, что они достаточно неисправны , чтобы иметь право на обмен по гарантии . Даже , казалось бы, незначител ь­ ные признаки ( например, странные шумы ил и ошибки дис кового сектора во временных файлах ) , вероятно, указывают на то, что диск скоро выйдет из строя.

Твердотел ьные диски Твердотельные диски ( S S D) распределя ют операци и сч итыван ия и записи по груп­ пам ячеек памяти , каждая и з которых по отдел ьности работает медленне е , чем совре­ менные жесткие диски . Однако благодаря параллел ьной работе таких ячеек с корость обмена дан н ы м и дисков S S D в целом соответствуют с корости работы тради цион н ы х жестких дисков и даже в несколько раз превосходит ее. Огромное преимущество S S D­ дисков состоит в том , что они сохраняют свою скорость работы даже тогда , когда про­ исходит произвол ьное обращение к дан н ы м для чтения ил и зап иси. Эта особенность является очен ь примекательной в реал ьных приложен иях. Производители жестких дисков любят при водить скорость последовател ьной пере­ дачи да нных для с воей продукци и , поскольку эти числа впечатля юще высоки. Однако 2 Компания Hitachi ( H G SТ, часть компании W:stem Digital) заслуживает признания как особо высо­ конадежная торrовая марка. В течение последнеrо десятилетия ее диски последовательно л идиро­ вали на диаграммах надежности . Тем не менее диски H G ST продаются значительно дороже своих кон курентов.

740

Часть 111. Хранение данных

для тради цио н н ых жестких дисков этот показатель практически не имеет ничего обще ­ го с реал ьной скоростью его работы , набл юдаемой при чте н и и и записи п роизвольных секторов диска.3 Высокая с корость работы S S D-дисков не дается даром . Накопител и SSD не тол ь­ ко дороже в пересчете на оди н гигабайт храни мой информаци и , ч е м жесткие дис ки, но и порождают новые сложности и неопределен ности . В марте 2009 г. Ананд Шимпи (Anand Shimpi) опубл иковал статью о технологии S S D , которую м ы рекомендуем как за­ мечательное введение в эту тему. Ее можно найти на сайте t i n yu r l . c om/dexnЬt.

Огр а ни ченное коли ч ество пере3аn исей Каждая стра н и ца фле ш — па м яти на диске S S D ( в совре м е н н ы х дисках ее разм е р раве н четырем двоич н ы м килобайтам) может б ы т ь перезаписана огра н и ч е н ное ко­ л ичество раз (об ычно 1 00 тысяч , в за висимости от испол ьзованной технологи и ) . Для того чтобы о гра н и ч ить износ стран и ц ы , програм м ное обеспечен ие дисков S S D ве ­ дет таблицы отображе н и й и рас пределяет зап ис и по всем стран ицам накоп ител я . Эти отображе н и я остаются с крыты м и от операционной систе м ы , которая рассматри вает накоп ител ь как п оследовател ьн ы й ряд блоков. Такой накопитель м ожно считать вир­ туал ьной памятью. Теоретический предел для перезап иси фле ш-памяти , вероятно, н е так важен , как это может показатьс я . Для того чтобы е го превысить, вам нужно в течение 1 5 лет н епре­ рывно зап и с ывать на диск SSD 500 Гбайт дан ны х со с коростью 1 00 Мбайт/с . Намного важнее дол госрочная н адежность дисков S S D . На этот вопрос ответа пока нет. Нам до­ стоверно известно, как работает диск S S D , произведе н н ы й пять лет назад, но современ­ н ые продукты имеют совершенно другие свойства.

Флеш-память и типы контроллеров Диски S S D производятся на основе нес кол ьких типов флеш- памяти . Основное раз­ личие между типами связано с тем , сколько бит информации хранится в каждой отдел ь­ ной ячейке фле ш -памяти. Одноуровн евые ячейки памяти (single-level memories — S LC) хранят оди н бит; это сам ы й быстр ы й , н о и сам ы й дорогой вариант. Также в спектре дисков присутствуют м ногоуровневые ячейки (multilevel cells M LC) и трехуровневые ячейки (triple-level cells — TLC). Обзор ы , посвяще н н ые дискам S S D , подробно описы вают эти детал и реализации как само собой разумеющееся , но неясно, почему покупател и должны об этом думать. Н е которые S S D работают быстрее , чем другие, но для понимания этого факта не требу­ ется н и какой конкретной техн ической подготовки. Стандартные тесты довольно хоро­ шо отражают раз.личия в производител ьности. Теоретически флеш — память S LC и меет пре имущество в надежности над другим и ти­ пам и . На практи ке надежность, по- видимому, бол ьше с вязана с тем , насколько хорошо прош ивка накопителя управляет памятью и сколько памяти п роизводител ь зарезервиро­ вал для замены п роблем ных ячеек. Контроллеры , которые координируют SSD-компоненты , все еще эвол юционируют. Не которые из н их лучше других, но в наши дни все основные п редложе н и я , как прави­ ло, вполне приемлем ы . Если вы хотите потратить вре м я на изучение аппаратного обе-

·’ Здесь нужно учитывать ваш и реальные рабоч ие нагрузки . В обычн ых ситуациях, д11 я которых на са­ мом деле в значительной степен и характерн ы последовательн ые операции чтен ия и записи , жесткие диски все еще могуг кон курировать с твердотельн ы м и , особенно если уч итывать затраты на обору­ дование.

Глава 20. дисковая память

741

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

Кластер ы страниц и предварительное стирание Еще одна сложность закл ючается в том , что и нформация со стран и ц фле ш — памяти должна быть предварител ьно стерта перед записью в нее новых дан н ых. Стирание па­ мяти представляет собой отдел ьную операцию, которая выпол н яется мем е н н е е , чем сама зап ись. Кроме того, невозможно стереть одн у стра н ицу, поскольку все смежные страницы кластера (как правило, 1 28 штук ил и 5 1 2 кибибайт) стираются одновремен но. Есл и пул заранее стертых стран и ц исчерпа н , то скорость записи SS D- накопителя может значительно снизиться и устройство должно восстановить стран ицы на лету, чтобы про­ должить запись. П ерестроить буфер стертых страниц труднее, чем кажется , потому что файловые систе м ы , разработан н ые мя традицион н ых дисков, н и как не помечают и н е стирают блоки дан н ых, которые бол ьше не нужн ы . Накопитель не знает, что файловая система сч итает дан н ый блок с вободн ы м ; о н знает тол ько, что кто-то когда-то записал в него дан н ы е мя хранен и я . Для того чтобы S S D- н акоп итель мог поддержи вать работу кеша предварител ьно стертых стра н и ц (а знач ит, обеспечивать высокую с корость зап ис и ) , файловая с истема должна и меть возможность сообщать S S D — н акопителю, что опреде­ ленные стран и ц ы больше не нужны. Этой возможностью, которая называется операци­ ей ТЮ М , в н астоящий момент обладают практически все файловые с истемы. В рассма­ триваемых в книге при мерах операцион н ых систем еди н ственной файловой системой , которая еще не поддерживает операци ю T R I M , является файловая система Z FS в Linux.

Надежность дисков SSD В 20 1 6 г. Бьянка Шредер ( Bianka Schroeder) и соавторы ( g o o . g l / l z u X б c ) обобщил и обш ирны й набор дан н ых, с вязан ных с дисками S S D , получ е н н ы й и з центров обработки дан н ых Google . Основные вы воды приведе н ы н иже. •

Технология памяти не и меет отношения к надежности. Надежность сильно варьи­ руется среди модел е й , но, как и в случае с жестки м и дискам и , ее можно оцен ить только ретроспективно.

Больши нство ошибок чте н ия п роисходят на уровне бит и корректируются с помо­ щью технологии избыточ ного кодирования. Эти грубые (но исправляемые) ошиб­ ки чте н ия явля ются общим и и ожидае м ы м и . Они происходят на большинстве на­ копителей SSD в тече ние всего времени их работы.

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

Даже среди сам ых н адеж н ы х м оделе й S S D у 20% накопител е й набл юдал ас ь п о край н е й мере одна неисправимая ош ибка чте н и я . Среди наиме нее н адежн ых моделей — у 6 3 % .

Несмотря на т о что возраст и интенсивность использования диска должны влиять на кол ичество возникающих неисправи мых ош ибок, эта с вязь так и не была вы —

Часть 111. Хранение данных

742

я влена до конца. В ч астности , в исследовании не было обнаружено н и каких до­ казательств того, что старые твердотельные накопители представляют собой тика­ ющие бомбы замедленного действия , которые постепенно приближаются к своему полному отказу. •

П оскол ьку неисправим ы е ошибки только незначительно коррелируют с рабочей нагрузко й , стандартная цифра надежности, указанная производителя м и , — уро­ вен ь н е исправимых ошибок в битах или U B E R н е и меет см ысла. Рабочая на­ грузка мало влияет на кол ичество наблюдаемых ошибок, поэтому надежность н е следует характеризовать этим уровнем. —

Наиболее заметным из этих выводов является тот, что нечитаемые блоки появляются часто и обычно возни кают изолированно. При это м , как правило, диск S S D сообщает об ошибке блока, но затем продолжает нормально фун кцион ировать. m Дополн ительную информацию о создании всеобъемлющей програм м ы обследования см . в главе 28.

Конечно, ненадежные устройства хранения данных — не н овость; поэтому следует все гда делать нескол ько резервных коп и й , независимо от того, какое оборудование вы испол ьзуете. Однако уровен ь отказов SSD-дисков остается существенно н иже по срав­ нению с отказами жестких дисков. В отличие от жесткого диска, диск и SSD редко будут требовать ваше го внимания , пока сбой не станет явным и очевидным . Диски S S D требу­ ют структурированного и систематического мониторинга. Ошибки развиваются со временем независимо от рабочего цикла накопителя, поэто­ му твердотельные накопител и , вероятно, не являются хорошим выбором для архивного хранения. И н аоборот, отдел ьны й сбойн ы й блок не я вляется признаком того, что диск SSD испортился или срок его полезной службы прибл ижается к концу. В отсутствие бо­ лее крупн ых сбоев целесообразно переформатировать такой диск и вернуть его в строй .

Гибридные диски Проведя м ного л ет в категории » экзотики » , жесткие диски SS H D со встроенной фле ш — памятью становятся все более востребованн ы м и . В настоящее время все их ис­ пользуют все больше и больше потребителей. Аббревиатура S S H D означает «solid state hybrid d rive » ( «твердотельн ы й гибридны й диск» и является чем-то вроде триумфа маркетин га, с проектирован н ы м так, чтобы спо­ собствовать путанице с дисками SSD. S S H D — это просто традиционные жесткие диски с некоторы м и допол нительными функциями на плате систе мной логики; в действитель­ ности, они являются таким и же твердотельными, как и обычная посудомоечная маш ина. Тесты современных продуктов S S H D , как правило, бьm и не оче н ь впечатляющим и , особенно когда эталонные тесты п ытались воспроизвести реальные сценарии их работы. Во м ногом это связано с тем , что в текущих устройствах обычно встроен только симво­ л ический объем кеша из флеш-памяти . Н есмотря на то что эффективность современной технологии SS H D невели ка, основ­ ная идея м ногоуровневого кеширования вполне обоснована и хорошо используется в та­ ких системах, как ZFS и Apple Fusion D rive. Поскольку цена флеш -памяти продолжает падать, м ы ожидае м , что диски на основе традиц ионных вращающихся пластин будут продолжать включать все больше и больше кеша. Эти продукты могут п родаваться в ка­ честве S S H D как явно, так и неявно.

Глава 20. дисковая память

743

Расширенный формат и блоки по 4 Ки Б Н а п ротяже н и и дес ятилети й стандартный размер дискового блока был зафи кс ирован на уровне 5 1 2 байт. Это сл и ш ком мало и н еэффективно с точ к и зре н ия работы бол ь­ ш и н ства файловых с исте м , поэтому в самих файловых с исте мах 5 1 2 -байтовые се ктора объединяются в дл и н ные кластеры стра н и ц , размером от 1 до 8 Ки Б , которые читаются и записы ваются вместе . П оскол ьку реально н и в одном програм мном обеспече н и и при обмене данн ых с дис ­ к о м не в ы пол н я ются о п е р а ц и и чте н и я и зап и с и дан н ы х по 5 1 2 байт, сл и ш ком неэф­ фективно и расточ ител ьно для оборудован и я поддержи вать такие крошеч н ы е се ктора. Поэтому за последнее десятилетие и ндустри я хране ния дан ных пере шла на новый ста н ­ дартн ы й размер блока 4 Ки Б , известн ы й к а к расширенный формат (Advanced Format ) . Все современные устройства хран е н и я испол ьзуют внутри сектора п о 4 Ки Б , хотя бол ь­ ш и нство из н и х продолжают эмул ировать 5 1 2 — байтовые бло к и дл я совмест и м ости с устарев ш и м и файловыми системами и ради удобства для конеч ного потребител я . В настоя щее вре мя существуют т р и разн ых » мира » , в которых м ожет сущест вовать устройство хранения дан н ых. •

5 1 2 n , ил и реал ьн ы е 5 1 2 , — это старые устройства , которые фактически и м е ют 5 1 2 -байтовые се ктора. Эти устройства бол ьше не производятс я , но, конечно, они все еще есть в реал ьном м ире. Эти дис ки н ичего не знают об рас ш иренном формате. 4 K n , ил и реал ьн ы е 4 К , — устройства, поддерживающие рас ш ирен н ы й форм ат, которые и м е ют сектора по 4 Ки Б (или стран и ц ы , как в случае S S D ) , и сообща­ ют на главн ы й ком п ьютер, что и х размер блока равен 4 Ки Б . Все и н терфе йс н ы е ап парат н ы е средства и все программ ное обес пече н и е , которое напрямую связано с устройством , должны знать и готовиться к работе с блока м и по 4 Ки Б . 4 K n — это волна будущего, но, поскол ьку о н а требует к а к аппаратной , так и про­ гра м м ной поддержки , ее прин ятие будет постепен н ы м . П р и воды корпоративн ого уровня с и нтерфейса м и 4Kn стал и доступн ы в 20 1 4 г. , но на дан н ы й момент вы не рискуете стол кнуться с дис ком 4Kn, есл и вы явно не закажете его. 5 1 2е , ил и эмул ирован н ые 5 1 2 , — это устройства , ис пол ьзующие внутре н н ие б.’10ки по 4 Ки Б , н о сообщающие на главн ы й ком п ьютер, что их размер блока раве н 5 1 2 байт. П ро ш и вка в устройстве объед и няет 5 1 2 — байтовые бл оч н ые о п ера ц и и в операции с фактичес к и м и блоками хране н и я по 4 Ки Б.

П ереход с устройств 5 1 2 n на устройства 5 1 2е был завершен в 20 1 1 г. Эти две с исте ­ мы с точ ки зрения главного ком пьютера выглядят практически идентич н ы м и , п оэтому устройства 5 1 2е отлично работают со стар ы м и ком п ьютерам и и стар ы м и операцион н ы ­ м и с исте мам и . Еди нстве нное, что нужно знать о б устройствах 5 1 2е , это то, что о н и чувствител ьн ы к н есогласованности между размером кластера стра н и ц файловой с исте м ы и блока м и ап паратного диска. П оскол ьку д и с к может ч итать ил и зап и с ы вать тол ько стра н и ц ы по 4 Ки Б ( нес мотря на его эмул я ц и ю тради цион н ы х 5 1 2-байтовых блоков) , гран и ц ы кла ­ стеров файловой с истемы и границы блоков жесткого диска должны совпадать. Край не нежелател ьно, чтобы логичес кий кластер файловой с исте м ы размером в 4 Ки Б фи.зи ­ чески рас полагался в поло вине одного дискового блока в 4 К и Б и п оловине другого. В таком случае на диске потребуется вы пол н ить в два раза бол ьше опера ц и й чте н и я ил и зап иси физических блоков, чем требуется дл я обслужи вания определен ного кол ичества логических кластеров.

744

Часть 111. Хранение данных

Поскол ьку обы ч но кластер ы файловой систем ы располагаются с самого н ачала дис­ ковой памяти , выделяемой для н их, можно реш ить проблему вырав н и ван и я , помест и в начало дис кового раздела на гран ицу, адрес которой равен степен и двойки и которая я в ­ ляется большой по сравн е н и ю с вероятн ы м размером диска и размера кл астера файло­ вой систе м ы ( например , 64 Ки Б ) . Средства разделе н ия дисков в совре м е н н ых версиях операционн ы х систем Windows, Linux и BSD автоматически обес печивают такое вырав­ н и вание. Тем н е м е н ее диски 5 1 2е , которые были н е правильно распредел е н ы в устаре в­ ш их с истемах, не могут быть безболезн енно исправлен ы ; вам придется запустить ути ­ л иту выравниван ия , чтобы изменить границы раздела и физически переместить дан н ые или же просто пол ностью стереть устройство и распределить е го заново.

20.3 . ИНТЕРФЕЙСЫ УСТРОЙСТВ ДЛЯ ХРАНЕНИЯ ДАННЫХ В настоя щее время существует л и ш ь несколько наиболее распростране н ных стандар­ тов интерфейса. Если с исте ма поддерживает несколько разн ых интерфе йсов, следует ис­ пользовать тот, который наилуч ш и м образом удометворяет требован и я , предъямяемые к скорости , надежност и , мобильности и стоимости.

И нтерфейс SATA П оследовательн ы й и нтерфей с АТА, SATA, я вляется основн ы м а п паратн ы м и нтер­ фейсом дл я устройств хране н ия данн ых. Помимо п оддержки высоких скоростей переда­ ч и (в настоя щее врем я 6 Гб ит/с ) , SATA и м еет встроен ную поддержку для » горяче й » за­ м е н ы и ( необязательно) поддержку очереди команд, две функции , котор ые в конечном итоге делают АТА жизнеспособной альтернативой и нтерфейсу SAS в серверн ы х средах. Кабели SATA л е гко входят в свои соедин ительные разъем ы , но о н и могут так же лег­ ко выскол ьзнуть отrуда. Доступн ы кабел и с фиксаторами , но они имеют неодн означ ную репутацию. На материнских платах с ш естью или восемью разъе мами SATA, упакова н ­ н ы м и вместе , может б ы т ь трудно отсоеди н ить блокирующие соеди н ител и б е з п а р ы уз­ конос ых плос когубцев. И нтерфейс SATA также в вел стандарт кабелей для подключения внешних устройств, называе м ы й e SATA. Эти кабел и эл е ктр ически иде нтич н ы стандарт н ы м SATA, н о их разъем ы немного отличаются. Вы можете добавить порт eSATA в систему с внутрен н и м и разъе мами SATA, установив недорогой преобразователь на кронште й н е . Будьте в н и м ательн ы при работе с в н е ш н и м и м ногодисковы м и корпусам и , которые и м е ют только оди н порт eSATA, потому что некоторы е из них содержат интеллектуаль­ н ы е ( RAI D ) контролл ер ы , для работы которых требуется собствен н ы й драйвер, а драй­ веры таких устройств редко п оддерживаются в UNIX или Linux. Существуют и обычн ые корпуса, в которы х встроен разветвител ь портов SATA. О н и поте н ц иально могут ис­ пользоваться в с истемах U N IX , н о посколь ку н е все хост-адаптеры SATA поддерживают разветвл е н и е п орто в , обратите пристал ьное внимание на и нформацию о совм ести мо­ сти . Корп уса с нескол ьким и портами e SATA — п о одному н а отсек для диско в — м ожно всегда использовать без особых проблем.

И нтерфейс PCI Express Шина PCI Express ( Pe ripheral Component lnterconnect Express — PCie) используется на материнских платах персональных компьютеров более десяти лет. В настоящее время это ос новной стандарт для подключения всех типов дополнительн ых плат, а также видеокарт.

Глава 20. дисковая память

745

По мере развития рынка SSD стало ясно, что скорость 6 Гбит/с работы и нтерфейса SATA скоро станет узким местом при взаимодействии с сам ы м и быстрыми устройства­ ми хранения дан н ых. П оэтому вместо традиционной фор м ы 2 , 5 -дюймового жесткого диска для ноутбуков , передовые S S D стал и принимать форму печатных плат, которые подключаются н епосредствен но к шине PC le с исте м ы . И н те рфе йс PC le был при влекательн ы м благодаря своей гибкой архитектуре и б ы ­ строй с корости передачи. Версия, которая теперь я вляется ос новной, P C l e 3 . 0 , и м еет скорость передач и 8 гигатранзакций в секунду ( Гт/с ) . Фактическая пропускная с пособ­ ность зависит от того, сколько каналов передачи данн ы х и м еет устройство; их может быть всего л и ш ь оди н или целых 1 6. Устройства с самой широкой полосой пропускан ия могут достигать пропускной способности более 1 5 Гб/с.4 Ожидаем ы й в ближайшем буду­ щем стандарт PCle 4.0 удвоит базовую скорость передачи дан н ых до 1 6 Гт/с . Срав н и вая и нтерфейсы PC l e и SATA и м е йте в виду, что с корость SATA, равная 6 Гбит/с указы вается в гигабитах в секунду. Пол ноцен ная PC l e на самом деле более чем в 20 раз быстрее , чем SATA. Стандарт SATA подвергается давлению. К сожалению, экосистема SATA огран ичена прошл ы м и варианта м и дизайна и необходимостью поддерживать существующие кабе ­ ли и разъе м ы . Маловероятно, что скорость и нтерфейсов SATA может быть знач ител ьно улучшена в течение следующих нескольких лет. Вместо этого в последнее вре м я основная работа была сосредоточена на поп ытке унификаци и SATA и PC le на уровне разъе мов. Стандарт М . 2 для подключаемых плат­ марш рутизирует SATA, PC l e (с четырьмя каналами передач и дан н ых) и U S B 3 . 0 че­ рез стандарт н ы й разъем . Оди н или два и з этих слотов теперь я вляются стандарт н ы м и для портативных ком пьютеров, но их также можно найти на настольн ых с истемах. Платы стандарта М . 2 имеют ш ирину около дюйма и могут составлять до четырех дюймов в дл ину. Они тон кие, с обеих сторон разрешены только нескол ько м илл иметров для монтажа компонентов. U.2 — более новая версия М . 2 ; она только начинает внедряться . Вместо U S B . в до­ полнение к и нтерфейсам SATA и PC l e , через разъем U . 2 можно подключать устройства с интерфе йсом SAS .

И нтерфейс SAS Аббревиатура SAS означает Serial Attached SCS I , в которой часть SCSI представляет интерфейс Small Computer System l nterface , общий канал дан н ых , который когда-то со­ единял множество разн ых типов периферийных устройств. В наш и дни рынок для пе­ рифер и й н ых соедин е н и й захватил и нтерфе йс USB, и и нтерфейс SCSI можно встретить только в виде SAS , пром ы шлен ного интерфе йса, испол ьзуемого для подключения бол ь­ шого кол ичества устройств хранен ия дан ных. Теперь, когда назван ия SAS и S C S I в значительной степе н и я вляются синонима м и , обширная история раЗ11 и чных технологий SCS I , относящихся к 1 986 r. , служит в основ­ ном для создания путаницы. Операцион н ы е с исте м ы вносят допол н ительную неодно­ знач ность, фил ьтруя весь доступ к диску через » подсистему SCS I » н езависимо от того, задействовано действител ьно устройство S C S I ил и нет. Наш совет — и гнорировать всю эту историю и рассматривать SAS как отдел ьную систему.

4Эrа скорость совсе м немного не дотягивает до 1 6 Гб/с, потому что часть полосы пропускания за­ н и мают служебные сигнал ы . Однако объем накладных расходов настол ько мал (около 1 ,5 % ) , что его можно безопасно и гнорировать.

часть 111. Хранение данных

746

П одобно SATA, и н терфейс SAS представляет собой с исте му с пря м ы м и с вя зя м и (point-to-point system ) : вы подкл ючаете диск в порт SAS через кабел ьную или п ря м ую соединител ьную плату. Однако SA S позволяет «рас ш ирителям » подключать нес кол ько устройств к од н о м у хост- порту. О н и аналогич н ы разветвителям портов SATA, но в то врем я как поддержка этих ра з вет в ител е й п ортов иногда отсутствует, рас ш ирения SAS поддер ж и ва ю тся все гда. В настоящее время SAS работает со с коростью 1 2 Гбит/с , что вдвое превы шает ско­ ро сть SATA. В прошлых изданиях этой кн и г и SCSI был очевидным выбором и нтерфейса для сервер­ н ы х приложений. Он предлагал самую ш ирокую доступную полосу пропускани я , выпол ­ нен ие команды в н е очереди ( прие м , называемый очередью размечен н ых команд ) , более экономное исполь:ювани е централ ьного процессора, упрощен ие обработки большого ко­ личества устройств хранения данных и доступ к самым передовым жестким дискам рынка. Появл е н и е SATA н и вел и ро вал о или м и н и мизировало бол ьш инство из эти х п ре и му­ ществ, поэтом у SAS п р осто не дает явных преимушеств, которыми пользовался SCS I . Диски SATA конкурируют с э кв и вал е нтн ы м и дисками SAS почти в каждой категори и (а в некото­ рых случаях превосходят их). В то же время как устройства SATA, так и и нтерфейсы и кабе­ ли, ис п ол ьзуе м ые для их п одкл юч е н ия , дешевле и гораздо более широко доступн ы . И нтерфейс SAS •

все еше и меет нескол ько козырей.

Производители продолжают испол ьзовать разделе н и е SATA/SAS для стратифика­ ции рынка хран е н и я . Чтобы оправдать прем иальное ценообразование, сам ы е бы­ стрые и надежные дис к и по-прежнему доступ н ы тол ько с и нтерфейса м и SAS .

SATA ограничи вает глубину очереди 3 2 операциям и , в т о врем я как SAS может об­ рабатывать тысяч и .

SAS может обрабатывать м ногие устройства хран е н и я (сотн и и л и тысячи ) на од­ ном и нте р ф е й се хоста. Но и м е йте в в иду, что все эти устройства подкл ючаются к одному каналу; поэтом у в ы по- п режнему ограни ч е н ы совокупной пропускной способностью в 1 2 Гбит/с .

Обсужден и е SAS и SATA мож ет в конечном итоге быть спорн ы м , поскол ьку стандарт SAS в кл ю ч ает поддержку дисков SATA. Соедин ител и SAS и SATA настолько похожи , что через одну объединительную панель SAS м ожно подкл ючить диски л юбого типа. На ло­ ги че с ко м уровне команды SATA п р осто туннел ируются по шине SAS . Эта кон ве р ге н ц ия — уди в ител ьн ы й техн и ч е с к и й п одвиг, но е го экон о м и ч е с к и й с мысл н е я с е н З атрат ы на устанооку SAS в основном с вязан ы с хост-адаптером , объеди ­ н ител ьной панелью и и н фр а ст р у ктурой ; диски SAS сами по себе не сли ш ком дороги е . Вложив ср е дств а в н а стр о й к у SA S в ы м ожете п р идерживаться этой технологии SAS до упора. (С другой сторон ы , возможно, с кромн ы е цены на диски SAS я вля ются резуль­ татом того, что в место них можно легко установить диски SATA. ) .

,

И нтерфейс USB Ун иверсал ьная п оследооател ьная ш и на ( US B ) я вляется попул я р ной ал ьтернати­ вой дл я п од кл юч е н и я о н е ш н их жестких дисков. Текущая скорость с оставляет от 4 Гб/с для U S B 3.0 и до 1 0 Гб/с для U S B 3 . 1 . 5 Обе с исте м ы достаточно быстрые , чтобы обе ­ с п еч ит ь макс и м ал ьную с корость п ередачи всех дан н ых, уступая тол ько самым быстр ы м 5Скорость U S B 3 . 0 часто упом и нается как 5 Гбит/с, но из-за накладных расходов, связанных с обя ­ зательной кодировкой, более вероятно, что фактическая с корость передачи составляет 4 Гбит/с.

Глава 20. дисковая память

747

дискам S S D . Однако избегайте испол ьзования и нтерфейса U S B 2.0; е го скорость дости ­ гает 4 8 0 Мбит/с , что м ал о даже для работы обычного жесткого диска. У самих накопителей н икогда не бывает встроенных и нтерфейсов U S B . Внеш ние ди­ ски, продаваемые с этим и интерфейса м и , — это, как правило, диски SATA с преобразо­ вателе м протокола (переходн иком) , встроенным в корпус. Вы также можете приобрести эти корпуса отдельно и поместить в них с вой жесткий диск. U S В-адаптеры также доступны в виде специальных корзи н для подкл ючения дисков и кабельных адаптеров. Это особенно удобно, когда диски часто меняются : просто вы­ таскиваете стары й диск и вставляете новый. US В-флешки явля ются совершенно законн ы м и устройствам и хранения дан ных. Они представля ют собой блочный интерфейс, аналогичный и нтерфейсу л юбого другого дис­ ка, хотя их скорость работы обычно посредственная . Основополагающая технология по­ хожа на технологию S S D , но без некоторых преимуществ, которые дают дискам SSD их превосходную скорость и надежность.

20.4. ПОДКЛЮЧЕНИЕ и НИЗКОУРОВНЕВОЕ УПРАВЛЕНИЕ НАКОПИТЕЛЯМИ С пособ подкл юче н и я д и с к а к с исте ме зависит о т испол ьзуе м о го и нтерфе йса. Остальное определяется монтажн ы м и крон штейнами и кабелями. К счастью, современ­ ные разъе м ы SAS и SATA имеют встроен ную » защиту от дурака» . m Дополнительную информацию о динамической работе с устройствам и см. в разделе 1 1 . 3. Интерфейс SAS поддерживает » горячую» замену дисков. П оэтому при его испол ьзо­ вании вы можете сразу подкл ючать и откл ючать диски без прерывания работы систе м ы . Ядро ОС должно автоматически распознать новое устройство и создать для него соот­ ветствующий файл . И нтерфейс SATA также может теоретически поддерживать » горя ­ чую» замену устройств. Следует заметить, что в стандарте SATA на этот счет н е т н икаких специальных требован и й , поэтому большинство производителей ради экономи и не под­ держивают эту возможность. Даже есл и испол ьзуе м ы е вам и и нтерфе йсы допускают подключение устройств без перезагрузки системы (т. е . » горячее» подключение), все же безопаснее обесточить си­ сте му перед тем , как вносить изменения в ее аппаратное обеспечение. П р и работе с ин­ терфейсами SATA » горячее » подключение зависит от реализации . Некоторые систе м н ые платы ком п ьютеров не поддерживают эту функциональную возможность. Целесообразно поп ытаться подключить жесткий диск к интерфейсу SATA, чтобы вы­ ясн ить, работает л и горячее подключение в конкретной с истеме. Вы н ич е го не повреди­ те . В худшем случае система просто проигнорирует диск. 6

П роверка и нсталляции на уровне аппаратного обеспечения После инсталляции нового диска следует убедиться, что система знает о ero существо­ вании на самом н изком из возможных уровней. Для персональных компьютеров это не­ сложно: система B I OS показывает диски SATA и USB, подключенные к системе. Здесь » » Горячее » подкл ючение может показа ься очен ь при екательной фун кцие й , ко орая открывает т т вл м ножест во возможностей , например замены плохо го диска без прерывания ра боты проrрам м . Одна ­ ко обеспечи т ь безопасность и надежность это го прие м а на бол ее высоких уровнях реали за ции храни­ лища да нных очен ь сложно. В этой кни ге м ы не описы вае м упра вление » горячим » подключение м .

Часть 111. Хранение данных

748

также могут быть включены диски SAS, если материнская плата поддерживает их напря­ мую. Если в системе и меется отдельная интерфейсная плата SAS , вам может потребовать­ ся вызвать настройку B IOS для этой платы, чтобы просмотреть и нформацию о диске. На облачн ых серверах и системах, поддерживающих горячее подключение дисков, вам , возможно, придется немного поработать. П роверьте диагностический вывод ядра после опроса устройства. Например, одна из наших тестовых с истем вывела следующие сообщения для устаревшего диска SCS I , подключенного к хост-адаптеру Buslogic SCSI. s c s i O : B u s L o g i c ВТ — 9 4 8 csi : 1 host . Rev : 0 0 0 1 vendor : S EAGATE Mode l : S T 4 4 6 4 5 2W AN S I S C S I r e vi s i o n : 0 2 D i r e c t -Acce s s Туре : D e t e c t e d s c s i di s k s d a a t s c s i O , chann e l О , i d 3 , l u n 3 s c s i O : T a r g e t 3 : Que ue D e p t h 2 8 , Asynchronous S C S I d e v i c e s d a : hdwr s e c t o r = 5 1 2 byt e s . S e c t o r s = 9 1 9 2 3 3 5 6 [ 4 4 8 8 4 МВ ] [ 4 4 . 8 GB]

Эту информацию можно увидеть после завершения загрузки системы: просто загля­ н ите в файлы системного журнала. Для получения дополн ительной и нформации об об­ работке загрузочных сообщений из ядра обратитесь к разделу 1 0. 3 . Существуют несколько команд, выводящих с писок дисков, о которых с исте ма знает. В системах Linux луч ш и м вариантом обычно является команда lsЫk, которая является стандартной для всех дист­ рибутивов. Для получения дополнительной информации запросите модель и серийные номера: lsЫk

+MODEL , SERIAL

В системе Free B S D используйте команду geom di sk list.

Файл ы дисковых устройств Вновь добавленный диск представляется в системе в виде файлов дисковых устройств в каталоге /dev. Общую и нформацию о файлах дисковых устройств с м . в разделе 5 .4. Все рассмотрен ные нами систе м ы создают такие файлы автоматически, но систе м ­ н ы й адм и н истратор по-прежнему обязан знать, где искать файл ы дисковых устройств и какие из них соответствуют новому диску. Форматирование не того накопителя — это прямой путь к катастрофе. В табл . 20.2 приведе н ы соглашения об и м енах дисков, при­ нятые в рассматри ваем ых операционн ых системах. В место демонстраци и абстрактного шаблона, по которому дискам присваиваются имена, в табл . 20.2 приводится типичный пример выбора имени первого диска в системе. Таблица 20.2. Стандарты именования дисков С исте м а

Диск

Раздел

Linux

/dev/ sda

/dev/ sdal

FreeBSD

/dev/ adaO

/dev/adaOpl

Столбец, соответствующий дискам, содержат пути к диску, а столбец, соответствую­ щий разделам, демонстрирует путь к конкретному разделу. Например, /dev/ sda в системе Linux это первый диск, управляемый драйвером sd. Следующим диском будет /dev/sdЬ и т.д. В системе FreeBSD используются другие имена драйверов и ч исла вместо букв, но принцип остается тот же самый. Н е придавайте сли ш ком большого значения именам драйверов, которые отобража­ ются в файлах дисковых устройств. Современные ядра осуществляют управление дис-

Глава 20. дисковая память

749

ками SATA и SAS через общий уровень SCS I , поэтому не удивляйтесь, если SАТА-диски маскируются как устройства SCS I . Н азван ия драйверов также разл ичаются в облач ных и виртуализован ных системах; виртуальн ы й диск SATA может иметь или не и меть то же имя драйвера, что и фактический диск SATA. В файлы устройств для разделов добавляется дополнительная информация , чтобы ука­ зать номер раздела. Н умерация раЗделов обычно начинается с 1 , а не О.

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

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

Н икогда не указывайте имя файла дискового устройства н и в каком файле конфи­ гураци и , поскольку оно может измениться в сам ы й неожиданн ы й момент.

Последняя проблема наиболее примечательна при внесении изменений в файл /etc/ fstaЬ, содержащий перечень файловых систем , которые система монтирует во время за­ грузки. Когда-то было типично идентифицировать разделы диска по и менам файлов сво­ их устройств в /etc/fstaЬ, но это уже не безопасно. Ал ьтернативные подходы описаны в раЗделе 20. 1 0. В с истеме Linux предлагается нескол ько способов решения проблемы не по­ стоя нных имен дисковых устройств. Подкаталоги каталога /dev/disk со­ держат характеристики дисков, например их идентификационные номера, присвоен н ые производителем, или и нформацию о подключен и и . Эти имена устройств ( которые на самом деле представляют собой обыч ные ссылки в каталоге верхнего уровня /dev) явля ются постоя н н ы м и , но они дл и н н ы е и громоздкие. Н а уровне файловых систем и массивов дисков система Linux использует уникал ьные текстовые строки , которые постоян но идентифицируют объекты . Во м ногих случаях эти длинные строки скрыты , так что вам не придется работать с н и м и непосредственно. Команда parted — 1 выводит размеры , таблицы разделов, номера моделей и производителей каждого диска, существующего в системе.

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

Часть 111. Хранение данных

750

в которых невозможно надежно в ыпол нять операции чтения и записи. Во всех совре­ менных дисках встроено управление сбойн ы м и секторами , поэтому ни вам , ни драйверу н е нужно беспокоиться об управл е н и и этим и дефекта м и . Прошивка накопителя авто ­ матически заменяет сбойные секторы хорошими, взятым и из области н а диске , которая зарезервирована ДJJ Я этой цел и . В с е жесткие диски поставляются заранее отформатированны м и , а заводское форма­ тирование не хуже любого другого, которое вы можете выполнить в п роцессе эксплуата­ ции диска. Лучше избегать использования н изкоуровневого форматирования, есл и это не требуется. Не стоит переформатировать новые диски , как самоцель. Если на диске обнаруж иваются ошибки чте н и я ил и зап ис и , с н ачала н еобходимо проверить кабели , терм инаторы и адресацию. Кажды й из них может вызвать симптом ы , похожие на существование сбойных секторов. Если после проверки вы все еще уверен ы , что н а диске есть дефект, лучше заменить его сразу н а новый диск, а не ждать м ного ча­ сов, пока он отформатируется, в надежде , что проблемы исчезнут сами по себе . Сбойные секторы, п роявившиеся после форматирования диска, могут обрабатываться автоматически, но могут и не обрабатываться. Если микропрограмма управления накопите­ лем полагает, что эти блоки можно восстановить надежным образом, то вновь выявленный дефект может быть исправлен на лету, а данные записаны в новое место. При выявлении более серьезных или менее очевидных ошибок накопитель прекращает выполнение опера­ ций чтений или записи и сообщает об ошибке операционной системе ком пьютера. Диски SATA обычно не п редназначен ы для форм атирования за пределами завода изготовителя . Однако вы можете получить и нформацию о програм м н ом обеспечен и и ДJJ Я форматирования дисков от его производителей, как правило, ДJJ Я систе м ы Windows. Убедитесь, что программ ное обеспечение предназначено и ме н но ДJJ Я того накопител я , который вы собираетесь форматировать, и точно следуйте инструкциям производителя. 7 Диски SAS форматируются сами по стандартной команде , поступающей от ком п ью­ тера. Процедура отправки этой ком анды зависит от с исте м ы . Н а п ерсональных ком­ пьютерах часто существует возможность посылать эту команду из с исте м ы B I OS конт­ роллера SCSI. Для того чтобы отдать команду на форматирование диска SCS I от и м е н и операционной с исте м ы , следует выпол н ить команду sg_ format в системе Linux или camcontrol в системе Free B S D . Для проверки целостности диска существуют разнообразные утилиты , которые выпол н я ют зап ис ь дан н ых в случайно выбран н ы е области и считывают и х оттуда. Тщательные тесты зан имают м н ого врем е н и и, к сожалению, и ме ют н ебол ьшое п ро­ гностическое знач е н ие . Если вы подозреваете , что диск испорче н , и можете е го п росто заменить ( ил и заказать новый в течение часа) , то эти тесты можно проигнорировать. В противном случае запустите тест на ночь. Не беспокойтесь об » изнаш и вани и » диска вследствие избыточного или агресси вного тестирования . Промышлен н ые диски предна­ значены ДJJ Я постоян ной работы. —

Безопасное стирание дисков АТА Начи ная с 2000 года диски РАТА и АТА реализуют команду » безопасного стиран ия » , которая пере п исывает уничтожить все данн ые на диске, используя м етод, разработан­ н ы й производител я м и ДJJ Я защиты от н есанкционированного извлечения информации. Безопасное стирани е сертифицировано Национальным институтом стандартов и техно­ логии ( N I ST) и в большинстве случаев вполне удовлетворяет пользователей. По класси 7 С другой сторо н ы , если н акопитель емкостью 1 Тбайт стоит 8 0 долл . , зачем беспокоиться ?

Глава 20. дисковая память

751

фикации М и н истерства оборон ы С Ш А , оно одобрено к использован и ю на уровне кон­ фиденциал ьности ниже, чем «секретн о » . Зачем вообще нужна такая функционал ьная возможность? Во- п е р вых , фа йл ов ые си­ стемы сами н ич е го н е стирают, поэтому команды вроде rm -rf * оставляют дан н ы е , находящиеся н а диске , нетронутыми и допус кают их восстановление с помощью специ­ альны х программ . м Об этом всегда нужно помн ить пр и избавлении от дисков, независи­ мо от того, продаете л и вы их на аукционе е Вау, или выбрасы ваете в м усорник. Во- вторых, даже руч ное перезаписывание каждого сектора на диске может оставлять магнитные следы , которые злоумы шленник может в ыя в ить и восстановить в лаборатории. Безопасное стиран ие переписывает дан ные столько раз, сколько нужно для того, чтобы уничтожить эти следы. Остаточные магнитн ые сигнал ы для большинства организаций не составляют большой щюблемы, но всегда полезно знать, что вы защ ищены от разглашения конфиден циальных данных организации. Некоторые организаци и выполняют безопасное стиран ие по требованию регуляторных органов или исходя из своих бизнес-правил. В закл ючение, безопасное стиран ие делает накоп и тел и S S D абсол ютно пусты ми . Это позволяет повысить скорость их работы в ситуациях, когда нельзя использовать команду TRI M стандарта АТА ( команду для физического стир ани я блока ) л ибо потому, что фай ­ ловая с истема, используемая в накопителе S S D , не способна ее выпол нить, л и бо потому, что накоп итель S S D подключен через адаптер ком п ьютера ил и контроллер RA I D , кото­ рые не поддерживают команду T RI M . Команда безопас ного удаления АТА защищена п ар оле м н а уровне диска, чтобы сни­ зить риск ее н е п реднамерен ного использова н и я . Поэтому перед вы зовом команды в ы должны задать с вой парол ь на дис ке. Однако не торо п итесь зап ис ывать пароль; пр и же­ лан и и вы можете е го всегда сброс ить. Опасности бло к и ров к и дис ка не существует.

В систе ме Linux можно испол ьзовать ком анду hdparm. $ sudo hdparm —user-master u —security-set-pass пароль /dеv/диск $ sudo hdpann —user-master u —security-set-erase пароль /dеv/диск

В систем е Fre e B S D можно испол ьзовать команду oamoontrol. $ sudo camcontrol security диск — U user — s пароль — е пароль

Команда безопасного стиран и я в стандарте АТА н е имеет аналогов в стандарте SCS I , но команда «форматировать м одул ь» в стандарте SCS I , описанная выше, представляется вполне разумной ал ьтернативой . М н огие систе м ы имеют утилиту shred, которая выпол н яет безопасное стирание от­ дел ьны х файлов. К сожал е н и ю , ее работа основана н а предположен и и , что блоки фай ­ лов могут быть перезаписаны на том ж е месте. Однако в о м ногих ситуациях это условие не выполняется ( в частности , это относ ится к любым файловы м с истемам на любых на­ копителях S S D , любым логичес к и м том а м , имеющим механ изм м гновенных копи й , и, возможно , ко всей файловой с истеме Z FS) , поэтому полезность универсал ьной утилиты shred вызы вает сомнения. Для очистки всей дисковой систе м ы н а п ерсон ал ь н ом ком п ьютере сущ е ствует про­ грам м а Дар и ка ( Darik) Boot and N uke (dban . o rg ) . Этот и нструмент запускается со сво­ его загрузочного диска, поэтому он не испол ьзуется ка жды й ден ь. Те м не м е нее он до­ вольно удобе н для вывода из э ксплуатации старого а п п аратн о го обеспечен ия. �теперь, когда больш и нство файловых систем поддерживают команду T R I M дпя и н формирования диска S S D о блоках, которые больше не нужны системе, это утве ржде н и е стало н е совсем точ н ы м . Однако команда T R I М я вляется необязательной ; диск S S D не обя за н сти рать что-л и бо в ответ.

Часть 111. Хранение данных

752

Команды hdparm и camcontrol: параметры диска и и нтерфейса ( Li nux) Команды hdparm ( Linux) и camcontrol ( Free BSD) и м е ют немного больше возмож­ ностей , чем команды безопасного стирания. Обычно они испол ьзуются для взаимодей ­ стви я с о встрое н н ы м и м и кропрограммами управления жестки м и дисками SATA и SAS. Так как эти утилиты работают на уровне, близком к аппаратному, они работают пра­ вил ьно только в невиртуал и зованн ы х систем ах . Н а традиционном физическом серве­ ре они н а самом деле я вляются луч ш и м способом пол учить и нформацию о дисковых устройствах с исте м ы (hdparm -I и camcontrol devl i st ); мы не упоминаем и х в дру­ гом месте ( н апример, в рецептах добавления диска, приведе н н ых в начал е этой главы) только потому, что они не работают в виртуальных системах. Команда hdp a rm п роисходит из доисторического м ира дисков I D E и постепенно расш иряется, охватывая возможности SATA и SCSI. Команда camcontrol задум ы валась как альтернатива SCSI и бьmа усовершенствована для покрытия н е которы х фун кци й SATA. Их с интаксисы различны, но в наши дни эти средства примерно эквивалентны . Среди прочего эти инструм е нты могут устанавл ивать параметры мощности электро­ п итания , вл и ять на уровен ь шума при работе диска, устанавливать флаг только для чте­ ния и в ыводить подробную информацию о диске.

Мониторинг жесткого диска с помощью станда рта SMART Жесткие диски п редставля ют собой отказоустойчивые систе м ы , испол ьзующие ко­ дирование с и с правление м ошибок, и встроен н ы е м икропрограм м ы с развитой логи кой для сокрытия своих дефектов от операционной с исте м ы компьютера. В некоторых слу­ чаях жесткие диски сообщают операционной с истем е о неисправимой ошибке только после м ногочисленных попыток исправить ее. Б ыло бы хорошо заранее распознавать такие ошибки, пока не разразился кризис. Устройства SATA реал изуют подробную форму отчетов о состоя нии накопител я , ко­ торая и ногда позволяет предсказать сбой. Этот стандарт под назван ием SMART ( » self­ monitoring, analysis, and reporting technology» ) предусматривает более 50 параметров, ко­ торые может анализировать компьютер. Ссьmаясь на исследование дисков, проведен ное компан ией G oogle (см. раздел 20.2 ) , часто утверждают, что данные стандарта S MART не могут предсказать отказ накопителя. Это не совсем так. Н а самом деле ком пания Google обнаружила, что четыре параметра стандарта S МA RT обладают высокой прогнозной точностью, но сам сбой невозможно предотвратить с помощью изменения настроек стандарта S MARТ. Среди накопител е й , давш и х сбо й , 56% не содержали и зм е н е н и й в этих четырех п араметрах. С другой сто­ рон ы , м ы считае м , что предсказание сбоя даже у половины дисков является неплохим результатом! Четырьмя чувствител ьн ы м и параметрам и стандарта S MART являются : •

количество ошибок с канирования (scan error count) ;

количество повторного распределения памяти (reallocation count);

количество автоном ного повторного рас пределе н и я памяти (off-line reallocation count) ;

количество секторов «с испытательным сроком » (probation) .

Глава 20. дисковая память

753

Все эти значен и я должны быть равны нулю. Ненулевые значения этих параметров повышают вероятность отказа в течение 60 дней в 39, 1 4, 2 1 и 1 6 раз соответствен но. Для того чтобы извлечь пользу из параметров стандарта S MARТ. необходимо иметь специал ьное программ ное обеспечение, которое опраш ивает накопители и прогнози­ рует вероятность сбоя . К сожал е н и ю , стандарты отчетов варьируются в зависимости от производителе й накопителей , поэтому декодирование параметров не всегда я вляется простой задаче й . Бол ьшинство мониторов S МA RT накапл ивают основн ые параметр ы , а затем ищут внезапные изменения в неблагоприятном направл е н и и , вместо того что­ бы и нтерпретировать их абсол ютные вел и ч и н ы . ( В соответствии с отчетом ком пан и и Google учет этих » мягких» параметров стандарта S MA RT в дополнение к » большой чет­ верке » позволяет предсказать 64% сбоев.) Стандартны м программ н ы м обеспечение м стандарта S МA RT для контрол я накопи­ телей в с истемах UNIX и Linux я вляется пакет smartmontools с сайта sma rtmont o o l s . o r g . В с истемах Red H at , CentOS и Fre e B S D он инсталлируется по умолчанию и обычно входит в репозитори й пакетов в других системах. Пакет smartmontools состоит из демона smartd, который постоян но следит за на­ копителям и , и команды smartctl, которую можно использовать для выполнения и нте­ рактивных запросов или сценариев. Демон и меет оди н конфигурацион н ы й файл , как правило, / etc/ smartd . conf, содержащий подробные комментарии и м ного примеров. Накопител и SCSI имеют собствен ную систему отчетов о нестандартном состоян и и , н о , к сожалению, они менее подробные, ч е м отчеты системы S МA RT Разработчики па­ кета smartmontools попытались включить накопители SCSI в свою схему, но прогно­ зируе мая значимость данных стандарта SCSI я вляется менее ясной.

20.5. П РОГРАММНОЕ ОБЕСПЕЧЕНИЕ НАКОПИТЕЛЕЙ Если в а м когда- н ибудь приходилось подкл ючать н о в ы й д и с к и система Windows спрашивала, не желаете ли вы е го отформатировать, вы могл и поразиться том у, насколь­ ко сложны м я вляется управление накопителям и в системах U N IX и Linux. П очему же оно такое сложное? Для начала отметим , что в с истемах U N IX и Linux все не н астолько и сложно. В ы можете подкл ючиться к своему настольному ком пьютеру с графическим и нтерфе йсом , присоедин ить к нему накопител ь U S B и работать с н и м практически так же , как в си­ стеме Windows. В ы получите возможность выпол н ить простую процедуру установки на­ копителя для хранения персональн ых данных. Если это все , что вам нужно, то все в по­ рядке. Как об ычно, в этой кн и ге нас и нтересуют промы шлен н ы е с исте м ы хранения дан ­ ных: файловые систе м ы , доступ к которым и меет м ножество пользователе й (локал ь­ н ы х и удал е н н ых) и которы е в то же вре мя должны быть надежн ы м и , высокопроиз­ водител ьн ы м и , допускающими простое резервирование и обновление. Такие систе м ы требуют н е много больше внимания, и систе м ы U N IX и Li nux дают для этого достаточ­ но оснований. Типичный набор ком понентов программ ного обеспечения, осуществляющих взаимо­ действие между накопителем и е го пользователями, приведен на рис. 20. 1 . Архитектура, показанная на рис . 20. 1 , относится к с истеме Linux, но и другие операционные системы обладают аналогичными возможностям и , хотя и не обязательно в точно таком же виде .

Часть 111. Хранение данных

7 54

Файловые системы, области подкачки, хранилище базы данных Логические тома Разделы

Массивы RAID

Группы томов

Накопитель

Рис. 20. /. Уровни управления накопителем

Стрел к и на рис. 20. означают » могут быть созданы на основе » . Например, файловая с исте ма Linux может быть создана на основе раздела, массива RAI D ил и логич ес кого тома. Создание сте ка модул е й , соед и н я ющих каждый накоп ител ь с е го окончател ьн ы м приложе н и е м , является одн ой из задач адм ин истратора. В н и м ател ь н ы й читател ь за метит, что этот граф и м еет ц и кл , а в реал ьн ы х кон ф и гу ­ ра ш1ях циклов не бы вает. С исте ма L i n u x допус кает создание сте ков из масси вов RA I D и логических то мов в л юбом порядке , но н и оди н из ком поне нтов не м ожет испол ьзо­ ватьс я больше одного раза (хотя с тех н ической точки зре н и я это возможно) . Рассм отрим фрагменты рис. 20. 1 . •

(storage device) — это все , что напо м и нает диск. Это может быть жест­ к и й диск, фл е ш — накоп ител ь , диск S S D , вн е ш н и й м асс и в RAI D . реал и зова н н ы й в виде ап паратного обеспеч е н ия , и даже сете вая служба , обесп е ч и ва ющая доступ к удал е н ному устройству на уровне блока. Кон кретн ы й вид оборудова н и я знач е ­ н и я н е и м еет, поскол ьку устройство допус кает прямой доступ , обрабатывает блоч­ н ы й ввод-вы вод и представлено файлом устройства .

Накопитель

(partition) — это фрагме нт накоп ителя , имеющий фиксирован н ы й размер. Кажды й раздел имеет собстве н н ы й файл устройства и действует как независ и м ы й накопител ь. Для обеспеч е н и я эффекти вности раздел ы создаются с помощью того же дра йвера, которы й ис пол ьзуется для управл е н и я устройством . Бол ь ш и н ство схем раздел е н и я зан и мает нескол ько блоков в начале накоп ителя для зап иси диа­ пазонов блоков, котор ые зан и м ает каждый раздел . Раздел

• Группы томов и лоrические тома ассо ц и и руются с м е н едже ра м и логических то мов (logical volu m e ma nage r LVM ) . Эти с исте м ы объед и н я ют физические устройства и формируют пул накопител е й , которые назы ваются группами томов. Адм и н истратор может раздел ить этот пул на логичес кие тома почти та к же . как дис к и разби ваются на раздел ы . Например, диск объе мом 6 Тбайт и диск объе м о м 2 Тбайт можно объеди н ить в груп пу то мов объе мом 8 Тбайт, а затем разбить на два логичес ких том а по 4 Тбайт. В резул ьтате оди н логичес к и й том будет содержать блоки дан н ы х , относя щиеся к обоим жестким дискам . —

Пос кольку менеджер логических дисков LУМ добавляет урове н ь абстракции между логически м и и физичес к и м и блока м и , с его помощью можно зафи ксировать логи­ ческое состоян и е тома, просто сделав коп и и табл и цы отображен ия . Следовател ьно, менеджеры логических томов часто обеспечи вают возможность получ е н и я » м гно­ вен н ы х копи й » томов. После этого все последующие операц и и зап иси на том при­ водят к тому, что дан ные будут направляться в новые блоки , а менеджер LYM будет отслежи вать как старую , так и новую табл и цы отображе н и я . Разумеетс я , менед-

Глава 20. дисковая память

755

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

Массив RAI D (избыточ ный масси в недорогих и независи м ых дисков) объединяет м ногочисленные накопители в одно виртуальное устройство. В зависимости от на­ стройки м ассива, эта конфигурация может повысить производительность (путем чте н ия и записи дисков в параллельном режим е ) ил и надежность ( путе м дубл и ­ рования и проверки данных с контролем четности на всех дисках) л ибо оба этих показателя.

Как следует из названия , масси в RAID обычно инте рпретируется как совокуп­ ность обычных дисков, но современ н ые реализации позволяют испол ьзовать в ка­ честве ком понента этого массива все , что функционирует как диск. •

Файловая система служит посредн иком между набором блоков, представленных разделом , масси вом RA I D , логическим блоком и стандартным и нтерфейсом фай ­ ловой систе м ы , ожидаем ы м программами: путям и вроде /var/ spoo l /ma i l , ти­ пами файлов в с истем ах U N IX, правами доступа и т. п . Файловая с истема решает, где и как хран ится содержим ое файлов, как п редставить пространство имен и ор­ ганизовать поиск на диске , а также как избежать сбоя (и восстанавл иваться после него).

Бол ьшую часть накопителя занимает файловая система. Однако в некоторых опе­ рационных с истемах ( н е в текущих версиях Liпux) на диске могут существовать специал ьные раздел ы для файла подкачки или хранил и ща баз дан н ых. Такая кон­ фигурация (т. е . без » помощи » файловой с исте м ы ) может потен циально работать чуть быстрее. П ри этом ядро ОС или базы дан ных создает на диске собствен н ые структуры данн ых, делая испол ьзование файловой с исте м ы и зл и ш н и м . Если в ы считаете , что описан ная в ы ш е система содержит сли ш ко м м ного маленьких ком понентов, которые п росто реализуют оди н блоч н ы й накопитель на основе другого, то вы совершенно правы . В последнее врем я наблюдается тенде н ция в сторону консо­ л идации этих компонентов , чтобы повысить эффективность и устран ить дублирование. Хотя м е н еджеры логических томов изначально не фун кцион ировали как контроллеры RA I D , бол ьш инство из них воплотили некоторые фун кциональные возможности масси­ вов RAI D (в частности, чередование дан н ых по дискам и зеркалирование). В настоящее врем я на передовом крае находятся систе м ы , объединяющие файло­ вую систему, контроллер RAI D и систему LVM в оди н и нтегрирова н н ы й пакет. Первым примером такого рода я вляется файловая систем а Z FS , хотя файловая с истема Btrfs в Linux предназначена для реше ния аналогичных задач . Систем ы ZFS и Btrfs описывают­ ся в разделе 20. 1 1 . ( Забегая наперед, скаже м , что есл и у вас будет возможность испол ь­ зовать одну из этих систе м , то обязательно попробуйте. )

Ото б ражение устройств в системе Li nux Для п ростоты н а рис. 20. 1 м ы опустили централ ьн ый ком понент стека хра­ н е н и я Linux механизм отображен и я устройств. Это м ногообещающий механ изм , охватывающий несколько контекстов, среди которых основн ы м и я вляются реализация LVM 2 , уровни файловой систе м ы для контейнериза­ ции (см. главу 25) и механизм ш ифрования всего диска ( и щ ите в поисковых машинах слово LU KS). —

756

Часть 111. Хранение данных

Механизм отображения устройств позволяет реализовать абстрактную идею создания одного блочного устройства на основе набора других блочных устройств. О н создает таб­ лицу отображения устройств, на основе которой выпол няется преобразование входящих запросов к диску и определен ие размещения кон кретного блока дан н ы х на соответству­ ющем устройстве . Ч аще всего механизм отображения устройств я вляется частью реал изации устройств хранения дан ных в системах Linux и не предполагает прямое взаим одействие с пользо­ вателем. Тем не менее вы можете увидеть его следы всякий раз, получая доступ к устрой ­ ства м в каталоге / dev/mappe r . Вы также м ожете настроить собстве н н ы е табл и ц ы отображения с помощью команды dmsetup, хотя случаи, в которых вам может потребо­ ваться сделать это, относительно редки. В следующих разделах мы более подробно рассмотри м уровн и , относящ иеся к кон ­ фигураци и хранил и ща дан н ых: разбиение н а раздел ы , RA I D , управление логическим и томами и файловые с исте м ы .

20.6. РАЗБИЕНИЕ ДИСКА Разбиение логического тома и управление логическим томом — это два способа разделе­ ния диска (ил и совокупности дисков в случае менеджера LVM) на отдельные части опреде­ ленного размера. Операционные системы Linux и Free BSD поддерживают оба этих метода. Традиционно на самом н изком уровне управления диском использовалось е го разби­ ение на разделы , причем только диски можно было так разделить. Н апример, отдел ьные диски можно подключ ить к RА I D- контроллеру или диспетчеру логических томов, но тогда нельзя будет разбить на разделы результирующие логические тома или тома RA I D . П равило, что н а разделы можно разбить только диски , все чаще нарушается в пользу более общей модели , в рамках которой диски , раздел ы, пулы LVM и м ассивы RA I D могут быть создан ы на основе друг друга, в любом порядке или их комбинации . С точки зре­ ния архитектуры программного обеспечения это красиво и элегантно. Но с точки зрения практичности у него есть неудачн ы й побочный эффект, подразумевающий наличие раз­ умной причины разбивать сущности, отличающиеся от дисков. Фактически разбие н ие в большинстве случаев менее желательно, ч е м управл е н и е логическим томом . Этот подход груб ы й и ненадежн ы й , к том у же он не и м еет таких функций , как управление моментал ьн ы м и с н и м ками. Решения о разбие н и и диска труд­ но пересмотреть впоследствии . Еди нстве н н ы м и заметны м и преимущества м и разбие­ ния над управлением логически м томом являются его простота и тот факт, что с исте м ы Windows и прош ивки BIOS понимают эту структуру и могут с ней работать напрямую. В некоторы х версиях с истем U N IX, работающих на проприетарном оборудовани и , пол­ ностью отказались от разбиения дисков, и никто, похоже , по нему н е скучает. И разбиение диска , и логические тома обле гчают резервное коп ирован и е , предот­ вращая незакон н ы й захват пользователя м и дискового пространства и поте н циальные поврежде н ия от програ м м , вышедших из- под контроля. Все с исте м ы и меют корневой раздел , монтирующийся на » / » и содержащий большинство данных о конфигурации ло­ кального ком пьютера. Теоретически для того, чтобы перевести систему в однопол ьзова­ тел ьский режим работы , достаточно одного корневого раздела. Разл ичные подкаталоги (самые распространенные из н их — /var, /usr, / tmp , / share и /home) можно пом е­ стить на собствен н ые разделы диска или тома. Больши нство систем и меет по крайней мере одн у область подкачки .

Глава 20. дисковая память

757

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

/opt

/spare

Уровень разделов

/dev/sda1

/dev/sda2

/dev/sdb1

Физический уровень

Жесткий диск 1 /dev/sda

label

/home

label

Уровень файловой системы

Жесткий диск 2 /dev/sdb

Рис. 20.2. Традицио11ная схема разбиения дисков в системе Uпих

Расс мотрим ряд факторов, вл ия ющих на схему разбие н ия дисков. •

В дал е ком про шлом целесообразно было иметь резерв н ы й корневой накоп итель. с которого можно было загрузиться в ситуаци и . когда с обычн ы м корневым разде­ лом пошло что-то н е так. В настоящее время загружае мые диски U S B и инсталля ­ цион н ы е диски DVD операцион ных систе м обладают более сил ьн ы м и фун кция м и по восстановл е н и ю дан ных в больш инстве систе м . Резервн ый корневой радел соз­ дает бол ьше пробл е м . чем решает.

Разм е щ е н и е катал ога / tmp в отдел ьной файловой с исте ме о гра н и ч и вает раз­ м е р ы вре м е н н ы х файлов и позволяет н е вы пол н ять их резер в н ое коп и рова н и е . Н е которые систе м ы дл я повы ш е н и я производител ьности испол ьзуют дл я хра­ н е н ия каталога / tmp файловую систе му, рас положе н н ую в оперативной памяти. Файловые систе м ы . расположе н н ые в операти вной памяти, с случае н еобходи мо­ сти пере н осятся в область подкач к и , поэтому они хорошо работа ют в бол ьш и н ­ стве ситуаци й .

П ос кол ьку файл ы с исте м н ого жур нала хра нятся в каталоге /var / 1 09. целесоо­ бразно, чтобы каталог /var ил и /var/109 зан имал отдельн ы й раздел диска. Есл и каталог /var рас положе н в мал е н ьком корн е вом разделе , то ле гко перепол н ить этот раздел и вызвать авари й н ы й останов все го ком п ьютера.

Пол ьзовател ьс кие рабочие каталоги полезно разме щать в отдел ьном разделе ил и каталоге . В этом случае , даже если кор н е вой раздел будет поврежде н ил и разру­ ш е н , пол ьзовател ьские дан н ые с высокой вероятностью остан утс я цел ы м и . И на­ оборот, систе ма сможет продолжать работу, даже есл и ош ибоч н ы й пол ьзовател ь­ ский сценарий перепол нит каталог /home . Раздел е н и е области подкач ки между нескол ьки м и физичес к и м и диска м и п о в ы ­ шает скорость работы систе м ы . Этот метод работает и по отнош е н и ю к файловым система м ; разме щайте инте н с и в н о испол ьзуе м ые файлов ы е систе м ы на разн ых дис ках. Эта те ма освещается в разделе 29 . 2 . Добавляя модули пам яти в ком п ьютер , увел и ч ьте область подкач ки . Более подроб­ но виртуал ьная память описывается в разделе 29 .6. Старайтес ь разме щать кластеры с быстро изменя ющейся информацией в нескол ь­ ких разделах диска , которые часто подвергаются резе р в ному копи рова н и ю.

Часть 111. Хранение данных

758 •

Орга н и зация Center for l nt ernet Security публ и кует руководства по настрой ке для разл и ч н ы х операцио н н ы х систем по адресу www . c i s e c u r i t y . o r g / c i s ­ b e n c hma r k s . Они я вляются критериям и лучшей практики. Документы включают полезные рекомендации для разбиения дисков на разделы и компоновки файло­ вой с исте м ы .

Традиционное разбиение Систе м ы , допускающие разбиение, реализуют е го, записывая » м етку» в начало дис­ ка, чтобы определить диапазон блоков, включенных в каждый раздел. nодробности этой процедуры могут варьироваться; метка часто может существовать одновременно с другой установочной информацией (например, загрузочн ы м блоком) и часто содержит дополни­ тельную и нформацию, например имя или уникальн ый идентификатор всего диска. Драйвер устройства, представляющий диск, считывает эту метку и использует таблицу разбиения диска для вычисления физического местоположения каждого раздела. Как пра­ вило, каждому разделу соответствует один или два файла устройства (для блочного устрой ­ ства и для устройства посимвольного ввода-вывода; в системе Linux есть только блочные устройства). Кроме того, отдельный набор файлов устройств представляет диск в целом . Н есмотря н а всеобщую доступность менеджеров логических томов, в некоторых с и ­ туациях н еобходимо ил и желательно традиционное разбиение. •

В настоящее врем я используются тол ько две схе м ы разбие н и я : M B R и G РТ. М ы обсудим эти схем ы в следующих разделах. На персональных ком пьютерах загрузочный диск должен иметь таблицу разбиения. Систе м ы , произведенные до 20 1 2 r. , обыч но требуют схему M BR, а некоторые из более современ н ых G РТ Большинство новых систем поддерживают обе схемы. —

И нсталл ирован ие табл и ц M B R ил и G PT делает диск понятн ы м для с исте м ы Windows, даже если содержан ие е го отдел ьн ых разделов остается н едосту п н ы м . Если у вас н е т конкретных планов по взаимодействи ю с системой Windows, т о все же учтите повсем естную распростране нность с истем ы Windows, бол ьшую попу­ лярность виртуал ьных маши н и вероятность того, что ваш диск в оди н прекрас­ ный день может вступить с ней в контакт. Раздел ы зан имают точно определенное место на диске и гарантируют локальность ссылок. Логические том а этого не обеспечивают (по крайн е й мере по умолча­ н ию) . В большинстве случаев это н е имеет большого значения. Однако следует учитывать тот факт, что в традиционных дисках доступ к данным , расположенных в смежных цилиндрах, выпол няется быстрее, чем если данные разнесен ы по уда­ ленным цилиндрам . Кроме того, скорость обмена данн ы м и , расположен н ы м и на наружных цилиндрах диска (т. е . цил и ндрах , содержащих блоки с наименьш и м и номерами) примерно на 30% выше, ч е м н а внутрен н их. В системах RA I D (см. раздел 20. 8) испол ьзуются диски или раздел ы сопостави­ мого размера. Хотя в конкретной реализаци и с исте м ы RAID могут использовать­ ся диски разных размеров, скорее все го при этом будут испол ьзоваться только те диапазоны номеров блоков, которые я вля ются общими для всех дисков. Чтобы не терять избыточное дисковое пространство из него можно сделать отдельн ы й раз­ дел для редко используе м ых дан н ых. Если же поместить в этот раздел часто ис­ пользуемые дан ные, то такая схема разбиения с низит производительность работы все го масси ва RA I D .

Глава 20. дисковая память

759

Разбиение диска по схеме MBR Разб иение диска по схеме M B R ( M aster Boot Record) я ал яется стары м стандартш-1 ком пании M ic rosoft , созда н н ы м еще в 1 980-х годах. Это неудобн ы й и плохо продума н ­ н ы й форм ат, которы й не может поддержи вать диски размером более 2 Тб. Кто то гда знал, что диски могут стать таки м и бол ьш и м и ? Схема M B R не и меет преимуществ перед схемой G РТ. з а исключен и е м того, что это еди нстве н н ы й формат, из которого старое комп ьютерное оборудован и е может загружать Windows. Есл и у вас нет веских прич и н ис пользовать разделы M B R, то , как правило, н е нужно этого делать. К сожал е н и ю . схема M B R по-прежнему испол ьзуется по умолча­ нию при установке м ногих дистрибутивов операцион н ых систе м . Метка M B R находится в одном 5 1 2-байтовом дисковом блоке , бол ьшую часть кото­ рого занимает программа начал ьной загрузки . П р и этом хватило места только мя опре­ дел е н ия четырех разделов диска. Эти разделы н азы ваются первичными. поскол ьку о н и оп ределя ются непосредствен н о схе мой M B R. Один из первичных разделов можно определить как » расш и ре н н ы й » . Это знач ит, что он содержит собствен ную вс помоrател ьную табли цу разделов. К сожал е н и ю , рас ш и ре н ­ н ы е разделы вызвал и м н ожество сложн ых п роблем , поэтому их следует избегать. Схема разбиения дисков в систе ме Windows позволяет пометить оди н из разделов как «акти вн ы й » . Загрузч ики ищут активный раздел и пытаются загрузить операцион ную с и ­ сте му и з него . Кром е того , кажд ы й раздел и м еет однобайто в ы й атрибут т и п а , которы й обозна­ чает содержи мое раздела. Ка к правило, эти коды предстаал я ют л ибо типы файловой систе м ы . л ибо операцион н ы е с исте м ы . Эти коды не п р и с ваи ваются це нтрал и зова н ­ но, но со вре м е н е м был и при няты определ е н н ы е соглаш е н и я . О н и сформул ирова н ы Андрисом Э. Брауэром (Andries Е. Brouwer) на сайте goo . g l /AТ i З . Кома нда M S DOS, осущесталяющая разбиение жесткого диска, назы вается fdi s k . Бол ь ш и н ство операцио н н ы х с исте м , поддерживающих разбиение в стиле M B R , унас­ ледовал и это имя мя обозначе н и я своих собстве н н ых команд разбиен и я , н о они оче н ь разнообразн ы . Сама систе ма Windows от н е е отказалась, ее современ ная версия и нстру­ м е н та мя разбиения диска назы вается diskpart. Кроме того , с истем а Windows и м еет графический пол ьзовател ьс кий и нтерфе йс мя разб и е н и я дисков , кото р ы й досту п е н благодаря утилите Управление дисками ( Disk Management) из консоли упраал е н и я mmc. Не и м еет знач е н и я , с помощью какой операцион н о й с исте м ы вы разбил и д и с к на раздел ы Windows и л и какой-то другой. Окончател ьн ы й результат будет таким же . —

Схема G PT: таблица разделов G U I D П рое кт компан и и l ntel п о созданию рас ширяемого м икропрограм м ного и нтерфе йса (extensiЬe fi rmware interface — E F I ) был напраален на замену н еусто й ч ивых соглашен и й , касающихся с истем B I O S персонал ьн ы х ком пьютеров, более совре м е н ной и фун кцио­ нал ьной архитектурой.9 Схема разбие н и я EFI в настоящее вре мя стала стандартом в но­ вом аппаратном обесп еч е н и и персонал ьн ы х ком п ьютеров и п олучила ш ирокую под­ держку со сторон ы операцион н ых систе м . Схе ма разделе н ия E F I , известная как «табл и ца разделов G U I D » , ил и G РТ,, устраняет очевидн ые недостатки метки M B R. Она определяет только один тип разбиения (бол ьше » П роект E F I недавно был переименован в U E F I . Буква U означает «unified» ( ун и версал ьн ы й ) . Этот п роект поддержи вается м ноги ми п роизводител я м и . Однако название E F I употребля ется чаше . П о существу, названия U E FI и E FI я вля ются с и но н и мами .

Часть 111. Хранение данных

760

нет н и каких логических разделов в расш ирен ном разделе), а самих разделов может быть скол ько угодно. Кажды й раздел имеет тип , определ е н н ы й 1 6-байтовым идентификато­ ром ( глобально уникал ьн ы м I D , или G U I D) , которы й не требует централ и зованного управления. Следует подчеркнуть, что таблица G PT сохраняет простейшую совместимость с си­ стемами, испол ьзующими м етку M B R, записывая метку MBR в первы й блок таблицы разделов. Эта «ложная » метка M B R позволяет диску выглядеть так , будто он содержит только оди н раздел M B R (по крайн е й мере в пределах до 2 Тбайт) . Само по себе это не имеет значен и я , но присутствие «ложной » метки M B R защищает диск от случайного переформатирования в обычных системах. Верси и системы Windows, н ач иная с версии Vista, открыли эру дисков G РТ для хра­ нения данных, но только систе м ы , поддерживающие расширяемый м и кропрограммный и нтерфейс EFI, могут загружаться с этих дисков. Система Linux и ее загрузчи к G RU B продви н ул ись дальше: о н и поддерживают диски G РТ, с которых могут загружаться лю­ бые системы. Систем ы Мае OS для процессоров ком пан ии l ntel , поддерживают обе схе­ мы разбиения EFI и G РТ. Несмотря на то что схема разбиения диска G РТ хорошо поддерживается во м ногих ядрах операцион н ых с исте м , ее поддержка среди утилит управления дискам и остается эпизодической. Убедитесь, что все утилиты , которые вы запускаете на диске с разбиени­ ем по схеме G РТ, действительно поддерживают эту схему.

Разбиение дисков в системе Li nux В системах семейства Linux предусмотрено несколько вариантов разбиения дисков, которые только запутывают конечного пол ьзователя , учитывая то , что некоторые из н и х не поддерживают G РТ. По умолчан и ю используется команда parted утилита командной строки , понимающая разные форма­ ты м еток ( включая те, что использовались в системах Solaris). С ее помощью можно не только создать или удалить раздел диска, но и переместить его в другое место и даже изменить размер. В системе с графическим интерфей­ сом пол ьзователя GNOME существует ее специал ьная версия , называемая gparted. —

В целом мы рекомендуем испол ьзовать утилиту gparted, а не parted. Обе утилиты п росты, но gparted позволяет задавать размеры разделов, а не начало и конец диапа­ зона блоков. Для разбиения загрузочного диска лучше всего использовать графические и нсталляторы из дистрибутивных пакетов, так как они обычно предлагают разбиени е , которое я вляется оптимал ьн ы м для данного дистрибутива.

Разбиение дисков в системе FreeBSD Как и Linux, система Free B S D имеет несколько и нструментов для разби­ е н ия дисков на разделы . И гнорируйте все , кроме gpart. Остальные суще­ ствуют только для того, чтобы спровоцировать вас совершить какую-нибудь ужасную ошибку. Таинствен н ые объекты geom, которые вы увидите н а справочной стран ице gpart (и в других связанн ых с хранили щем контекстах в системе Free BSD ), это абстракция устройств хране н ия Free B S D . Не все объекты geom это дисковые накопители , но все —

Глава 20. дисковая память

761

дисковые накопители являются объектами geom, поэтому при вызове команды geom вы можете испол ьзовать общее имя диска , такое как adaO. В реце пте , посвященном добавл е н и ю диска в с исте м е Free B S D и з раздела 20. l , для настройки таблицы разделов на новом диске используется команда qpart.

20.7. УПРАВЛЕНИЕ ЛОГИЧЕСКИМИ ТОМАМИ П редста вьте с е б е с итуацию, в которой вы н е знаете , н асколько бол ь ш и м должен быть раздел . Ч ерез шесть месяцев после создания раздела выясняетс я , что он сл и ш ком бол ьшой , а в соседнем разделе недостаточно памяти. Знакомо’? М е н еджер логического тома позволяет вам динамически перерас предел ить память между перепол н е н н ы м раз­ делом и разделом , испытывающим нехватку памяти . Управл е н ие логическими томам и , по существу, я вляется максимал ьно эффективной и абстрактной версией процедуры разделения диска. Оно группирует отдельные накопи­ тели в » группу томов». Блоки в группе томов могут быть затем вьщел е н ы «логическим томам » , которые представлены файлам и блоч ных устройств и фун кционируют как раз­ делы диска. Однако логические тома являются более гибким и и мощн ы м и , чем раздел ы дисков. Перечислим ряд операций, которые можно выполнять с помощью менеджера тома. •

Перемеще н ие логических томов между нескол ькими физическими устройствам и .

Увел ичен ие и умен ьшение размеров логических томов на лету.

Получение » моментал ьных с н и м ков» логичес ких томов в резул ьтате выпол н е н и я операции копирования при записи.

Заме на накопителей без прекращения работы с исте м ы .

Создание зеркал или чередования дан н ых п о дискам н а логических томах.

Ком поненты логического тома можно объединить в одно целое разн ы м и способам и . П р и кон катенац и и физические блоки устройств объедин я ются вместе путем их по­ следовател ьного расположе ния друг за друrом . П р и чередовании данных ком поненты располагаются так, чтобы соседние виртуальные блоки по возможности располагал ись на разных физических дисках. Это позволяет устран ить узкие места, связа н н ы е с про­ изводител ьностью одноrо диска, увел и ч ить в разы скорость обмена дан н ы м и и снизить задержку доступа к дан н ы м . Есл и вы уже стал кивалась с масси ва м и RAI D (см . раздел 20. 8 ) , т о м ожете заметить, что чередование данн ых поразител ьно напом и н ает RAI D О. Однако реал и зации LVM с чередова н и е м , как правил о , более гибкие , чем RA I D . Например, они могут автома­ тически оптимизировать чередование или разрешать чередование н а устройствах разно­ го размера, даже если чередование фактически не произойдет в 1 00 % случаев. Гран и ца между LVM и RA I D стала разм ытой , и даже схе м ы с контрол е м ч етности, такие как RAI D 5 и RAI D 6, уже регулярно поя вляются в менеджерах томов.

Уп ра влен ие логическими томами в системе Linux Менеджер логических томов в с истеме Linux ( LVM2 ) на самом деле пред­ ставляет собой клон програ м м ы Ve ritas из систе м ы H P- U X . Команды для этих двух систем практически оди наковы и перечисл е н ы в табл . 20. 3.

Часть 111. Хранение данных

762 Таблица 20.З. Команды LVM в системе Linux

Сущность

О пе ра ция

Команда

Физичес к ий том

Со эдание

pvcreate

Ото б ражение

pvdisplay

Модифи кация Проверка

pvchange

Со эдание

vgcreate

Модифи кация

vgchange

Расширение

vgextend

Ото б ражени е

vgdi splay

Группа томов

Логиче ский том

pvck

П ров е р ка

vgck

Ввод в строй Со эдание

vgscan

М од ифи кация

lvchange

Изм е нение размера

lvresize

Ото б раже ни е

lvdisplay

lvcreate

Архитектур а LVM ве рх н е го уровня состоит в том , что отдел ьн ые диски и разделы (физические тома) собираются в пулы устройств хранения данных, н азываемые группа­ ми томов. З ат е м группы томов подразделяются на логические тома, которые являются блоч н ы м и устройствам и , в которы х хранятся файловые системы. Физический том долже н и м еть м етку LVM , задавае мую в команде pvc r e a t e . Применен ие такой метки sшл я е тся первым шагом для доступа к устройству через менед­ жер LVM . Помимо информации об испол ьзовании системных ресурсов, метка содержит уникал ьн ы й иде нтификатор мя идентификации устройства. Физический том несколько н еточный термин , поскольку физические тома не обяза­ н ы и меть прямое соответствие физическим устройствам . Они могут быть дисками , но они также могут быть дисковыми разделами или RAI О-массивами. Менеджеру LVM все равно. Вы м ож е т е уп равлять м е н еджером LVM л ибо большой группой простых команд, п ере ч и сл енн ых в табл 20. 3 , л и бо с помощью команды lvm и ее различных подкоманд. Эти вар ианты по сущ е ству идентичн ы ; отдельные команды — это просто ссылки на ко­ манду lvm, которые созданы только для того, чтобы своим названием говорить вам , что о н и делают. Хорошее в веде н ие в с истему и ее инструменты можно найти на справочной с тр а н и це команды 1vm. П р о ц есс н астройки менеджера логических томов в системе Linux состоит из н е скол ьких этапов. —

.

Создание (на самом деле определение) и и н ициал изация физических томов.

Добавл е н ие физических томов в группу томов.

Созда н и е логических том ов из групп ы томов.

Команды LVМ начинаются с буквы , определяющей уровен ь абстракци и , на котором о н и де й ст вуют : команды с префиксом pv манипул ируют физическими томам и , vg группами томов, а lv — логичес кими томами . Команды , имеющие префикс lvm (напри­ мер, lvmchanqe) , о перир уют системой в целом .

Глава 20. дисковая память

763

В следующем пр имере мы настроил и жестки й диск /dev/ s db объемом l Тбайт для и с п ол ьзова н и я в м е н еджере л о г и ч е с к и х томов и создал и л о г и ч е с к и й том . Предполагается, что диск содержит единствен н ы й раздел , поэтому м ы пропустим этот этап и будем испол ьзовать диск как п ростое физическое устройство, хотя это и н еэф­ фективно. Разбиение диска на разделы делает его доступным для самого ш и рокого спек­ тра программного обеспече н ия и операционных систе м . Для начала пометим раздел s d Ы как физический том LVM . $ sudo pvcreate /dev/ sdЬl Phy s i c a l vol ume » / dev / s dЫ » s u c c e s s fu l l y c r e a t e d

Наше физическое устройство теперь готово для добавления в группу томов. $ sudo vqcreate DЕМО /dev/sdЬl Vol ume g roup » DEMO » s u c c e s s f u l l y c r e a t e d

Несмотря на то что в этом примере испол ьзуется тол ько одно физическое устрой ­ ство, м ы , разумеется, могли добавить допол нительные накопител и . Для проверки наших действий используем команду vgdi splay . $ sudo vqdisplay DЕМО — — — Vol ume g r oup — — V G N ame S y s t em I D Forma t Me t a d a t a A r e a s Me t a d a t a S e quence No VG Acce s s VG Status МАХ L V Cur LV Open LV Мах PV C u r PV Act PV VG S i z e РЕ S i z e Total РЕ Alloc Р Е / S i z e F r e e РЕ / S i z e V G UU I D

DEMO l vm2 1 1 read/write resi zaЫe О О

о о 1 1 1 0 0 0 . 0 0 GiB 4 . 0 0 MiB 255999 О / О 2 5 5 9 9 9 / 1 0 0 0 . 0 0 GiB n 2 6 r x j -X 5 HN — x 4 nv- rdnM- 7AW e — OQ2 1 — EdDwEO

Аббревиатура » Р Е» обозначает физический экстент (physical extent) — един и цы вы­ деления дисковой памяти , на которы е разделяется группа томов. На последних этапах создается логический том в группе DEMO, а затем — файловая система внутри этого тома. В итоге мы получи м логический том размером 1 00 Гбайт. $ sudo lvcreate -L l O O G -n wеЫ DЕМО L o g i c a l v o l ume » w еЫ » c r e a t e d

Большинство и нтересных возможностей менеджера LVM 2 относится к уровн ю логи­ ческого тома. В частности, они включают в себя возможности созда н ия дисков с чередо­ ванием, зеркал и объединения нескол ьких устройств в один большой том . Теперь к логическому тому можно обращаться п о и м е н и / dev/DEMO/weЫ . М ы об­ судим файловые с исте м ы в разделе 20.9 , а пока кратко опишем создание стандартной файловой системы для демонстраци и некоторых особенностей работы менеджера LVM .

764

Часть 111. Хранение данных

$ sudo mkfs /dev/DEМO/weЫ

$ sudo mkdir /mnt/weЫ $ sudo mount /dev/DEМO/weЫ /mnt/weЫ

Мгновенные копии тома В ы можете создать копи ю при записи л юбого логического тома LVM 2 , независ имо от того , содержит он файловую систему или нет. Это свойство удобно для создани я ста­ тического образа файловой систе м ы , предназначен ного для резервного коп ирования , но, в отл и ч и е от мгнове н н ых копи й с исте м ZFS и Btrfs, м гнове н н ы е с н и м ки LVM 2 , к сожалению, не очень полезны дл я контроля версий. П роблема заключается в том , что логические тома имеют фиксирован н ы й размер. Когда создается логическ и й том , пространство на диске выделяется из групп ы томов. Коп ирование при записи изначал ьно не потребляет дисковую память, н о при модифи­ кац и и блоков менеджер тома должен найти место для хранения как старой, так и новой верс и и . При создании м гнове н н ых коп ий это пространство, необходимое для модифи­ цирован ных блоков, должно резервироваться, приче м , как и л юбой том LVM , выделен­ ная память должна и меть фиксированный размер. При этом н е и меет знач е н и я , что модифицируется — оригинал ь н ы й том ил и е го м гновенная копия (которая по умолчанию перезаписы вается ) . В любом случае затраты на дубл ирован ие блоков перекладываются на м гнове н н ы е копи и . Выделение памяти для м гновенных копи й могут быть сведе н ы на нет при активности исходного тома, даже если при этом создаются пустые м гновен н ые копи и . Если для м гновен ной коп и и не выделяется макс и мальный объем памяти , зан има­ емый том о м , для которого она создается , то вы можете столкнуться с нехваткой дис­ кового пространства в мгновен ной копи и . Это нам ного хуже , чем кажется , поскол ьку менеджер томов не с может обеспечить хранение согласован ного образа м гновенной ко­ п и и ; потребуется дополн ительная память только лишь для хранения самой копии. При не­ хватке выделенного пространства менеджер LVM прекращает поддерживать м гнове н н ые коп и и , и они безвозвратно повреждаются. Итак, как показывает практика, мгновенные копи и должны быть либо краткосроч ­ н ы м и , либо такими же бол ьш и м и , как их источн и к и . Эти аргуме нты с видетельствуют в пользу » м н огочисленных дешевых виртуальных коп и й » . Для того чтобы создать том / dev/DEMO/weЫ — snap как м гновенную коп и ю тома /dev/DEMO/weЫ , можно использовать следующую команду. $ sudo lvcreate -L l O O G — s -n weЫ -snap DЕМО/wеЫ L o g i c a l v o l ume » weЫ — s nap » c r e a t e d .

Обратите внимание на то, что м гновенная копия имеет самостоятел ьное и м я , а ее источн и к должен быть задан в виде групп а_ ‘.I!Онов/’.I!он. Теоретически том /mnt/weЫ сначала необходимо размонтировать, чтобы гарантиро­ вать согласованность файловой системы. На практике файловая система ext4 достаточно хорошо защищена от поврежден ия данн ых, хотя существует вероятность потерять сам ые с вежие изменения блоков данных. Это идеальный компро м исс для мгнове н н ых коп и й , используемых в качестве источн и ка дл я резервного копирования. Для того чтобы проверить состояние м гновенных копи й , следует выполнить команду lvdi splay. Если она сообщает, что мгновенная коп ия » н е активна » , это значит, что для нее уже не хватило места на диске , и ее следует удал ить, поскольку с такой м гновенной копией практически н ичего сделать уже нельзя .

Глава 20. дисковая память

765

Изменение размера файловых систем Переполнение файловых систем происходит гораздо чаще , ч е м сбои дисков , и одно из преи муществ логических томов заключается в том , что манипулировать и м и гораз­ до легче, чем физическими разделами на жестком диске . М ы сталкивались с разн ы м и ситуация м и , когда пользователи хранили на сервере л и ч н ы е видео-файлы , либо когда почтовые ящики организации были просто забиты спамом . Менеджер логических дисков ничего не знает о содержимом своих томов, но изме­ нять размеры необходимо на уровне как тома, так и файловой систе м ы . Порядок за­ висит от конкретной операци и . При уменьш е н и и размера следует сначала работать с файловой системой , а при увеличении — сначала с томом . Это правило запоминать не стоит: просто следуйте здравому смыслу. Предположим , что в нашем примере том /mnt/weЫ увеличился больше , чем пред­ полагалось, и ему нужно дополнительно 1 00 Гбайт дисковой памяти. Сначала проверим группу томов, чтобы убедиться, что дополнительное место существует. $ sudo vgdisplay DЕМО — — — V o l ume g r oup VG Name Sys tem I D Fo rma t Me t ad a t a A r e a s Me t ad a t a S e qu e n c e N o V G Ac c e s s VG S t a t u s Op e n LV Мах PV Cur PV Ac t PV VG S i z e РЕ Size Total Р Е Al l oc Р Е / S i z e Free РЕ / S i z e V G UU I D — — ­

DEMO l vm2

l 4 r e a d /wr i t e resi zaЫe

l о 1 1 1 0 0 0 . 0 0 GiB 4 . 0 0 MiB 255999 5 12 0 0 / 2 0 0 . 00 GiB 2 0 4 7 9 9 / 8 0 0 . 0 0 GiB n 2 6 r x j — X 5 HN — x 4 nv — rdnM — 7 AWe — OQ2 1 — EdDwEO

Обратите внимание на то, что мы использовали 200 Гбайт пространства: 1 00 Гбайт для исходной файловой системы и 1 00 Гбайт — для моментального с н и м ка. Тем не ме­ нее нам по-прежнему доступно много места. М ы размонтируем файловую систему и ис­ пользуем команду lvresize для добавления места в логический том . $ sudo umount /mnt/weЫ $ sudo lvchange -an DЕМО/wеЫ $ sudo lvre s i ze -L +lOOG DEMO/weЫ S i z e o f l o g i c a l v o l ume DEMO /weЫ c h a n g e d f r om 1 0 0 . 0 0 G i B ( 2 5 6 0 0 e x t e nt s ) t o 2 0 0 . 0 0 G i B ( 5 1 2 0 0 e x t e n t s ) . L o g i c a l vo l ume DEMO /weЫ s u cc e s s fu l l y r e s i z e d . $ sudo lvchange — ау DЕМО/wеЫ

Команды lvchange необходимы для того, чтобы деактивировать том , изм е н ить его объе м , а потом вновь активировать. Эта часть необходима только потому, что существует мгновен ная копия тома wеЫ из предыдущего примера. После изменения объема копия «увидит» дополн ител ьные 1 00 Гбайт, но, поскольку файловая с истема содержит только 1 00 М байт, копи ю можно по- прежнему использовать.

Часть 111. Хранение данных

766

Те п е р ь м ы м ожем и з м е н ить размер файловой систе м ы с помощью команды resize2fs. (Цифра 2 взята из имени оригинал ьной файловой систе м ы ext 2 , но коман­ да поддерживает все версии этой файловой систе м ы . ) Поскольку команда res i ze2fs может определять объем новой файловой с исте м ы по тому, нам н е обязательно указы­ вать новый объем я в н ы м образо м . Это н еобходимо только при уме н ь ш е н и и размера файловой систе м ы . $ sudo res i ze2fs /dev/DEМO/weЫ re s i z e 2 f s 1 . 4 3 . З { 0 4 — Sep- 2 0 1 6 ) Re s i z i n g t h e f i l e s y s t em o n / d e v / DEMO /weЫ t o 5 2 4 2 8 8 0 0 { 4 k ) Ы o c k s . T h e f i l e s y s t e m on / d e v / DEMO /weЫ i s now 5 2 4 2 8 8 0 0 { 4 k ) Ы o c k s l on g .

Ну вот! Проверка информации , которая вы водится командой df , с нова показывает изменения. $ sudo mount /dev/DFJ4.0/weЫ /Dlll t /weЫ $ df -h /Dlll t /weЫ Size U s e d Ava i l Fi l e s y s t em / d e v/mappe r / DEMO-weЫ 1 97G бОМ 187G

Use% 1%

Moun t e d on /mn t /weЫ

Аналогичн ы м образом работают команды для изменения размера в других файловых системах. Для файловых систем XFS (по умолчанию для систем Red Hat и CentOS) ис­ пользуйте команду xfs_growfs ; дл я файловых с истем UFS ( по умолчан и ю в с истеме Free BSD) используйте команду growf s . Файловые с исте м ы XFS дол жн ы быть с монти­ рованы так, чтобы они допускали рас ш ирение. Как показывают назва н ия этих команд, файловые с истемы XFS и U FS могут быть расширен ы , но не уменьшен ы . Если вам нужно освободить место, скопируйте содержимое файловой системы в новую, меньшую по раз­ меру файловую с истему. Стоит отметить, что «дис к и » , которые вы вьщеляете и прикрепляете к виртуальны м машинам в облаке , я вля ются по существу логическими томам и , хотя сам диспетчер то­ мов находится в другом месте облака. Эти объем ы обычно изменяются с помощью кон­ соли управления облачного провайдера или утилиты командной строки. Процедура и зменения размеров облачн ы х файловых систем такая :же , как и описан­ ная выше, но и м е йте в в иду, что, поскол ьку эти виртуальные устройства выдают себя за диск и , у н их , вероятно, есть таблицы разделов. Вам нужно будет измен ить размер на трех отдельных слоях: на уровне облачного п ровайдера, уровне раздела и уровне фай­ ловой с исте м ы .

Управление логическими томами в FreeBSD У с и сте м ы Free B S D есть п ол н о це н н ы й м е н еджер логичес к и х том о в . П редыдущи е верси и б ыл и известны под и м е н е м Vinum , н о теперь, когда с истем а была переписана, чтобы соответствовать обобщенной архитектуре g e om FreeB S D для устройств хранения, имя было изменено на GVi num. Как и LVМ2 , GVinum реализует множество типов RAI D. Разработч и к и с исте м Free B S D в посл е д н е е вр е м я п р иложил и м ного ус и л и й дл я п оддер ж к и файловой с и сте м ы Z F S , и хотя G Vi n u m о ф и ц и ал ьн о н е устар ел , общедосту п н ы е к о м м е н та р и и разработч и ко в показы вают, что Z FS я вл яется р е ­ коме ндуе м ы м подходом для уп р авл е н ия л о г и ч е с к и м том о м и RAI D в будуще м . Соответстве нн о , м ы н е обсуждаем здес ь GVinum . О писан и е файловой с исте м ы Z F S п р иводится в разделе 20. 1 2 .

Глава 20. дисковая память

767

20.8. RAI D: ИЗБЫТОЧ НЫЕ МАССИВЫ НЕДОРОГИХ дисков Даже при наличии резервных коп и й последствия сбоя диска на сервере могут б ыть катастрофическими. RAI D ( redundant arrays of inexpensive disks избыточные массивы недорогих дисков) — это система, распределяющая ил и дубл и рующая дан н ые по на­ бору нескольких дисков. 10 Система RAI D не только пом о гае т избежать потери данных, но и м и н и мизирует время п ростоя , связанного с от ка зо м аппаратуры (часто с водя его к нулю) , и потен циал ьно повышает скорость работы. Систему RAI D можно реализовать с помощью спе ци ал ьного аппаратного контроллера, благодаря которому операционная система будет видеть группу жестких дисков как оди н составной накопитель. Кроме того, е е можно реализовать так, чтобы операцион ная система просто считывала или записывала данные на жестких дис ках по правилам системы RAI D. —

П рогра ммная и а п па ратная реал иза ции с и с тем ы RAI D Поскольку диски сами по себе являются узким местом в реал и зации системы RAI D, нет причин предполагать, что аппаратная реализация системы RAID всегда будет работать бы­ стрее, чем программная на уровне операционной системы. В прошлом аппаратная система RAI D была доминирующей по двум причинам: из-за недостатка прогр аммн о й поддержки (отсутствие прямой поддержки со стороны операционных с исте м) и способности аппарат­ ного обеспечения буферизовать записываемые данные в энергонезависимой памяти. Последнее свойство, упомянутое выше, повышает с корость р аботы дисковой подси­ стемы, поскольку операции записи выполняется очень б ы стро . Кр ом е того, оно защища­ ет дисковую подсистему от потенциал ьного повре жде н ия которое п олучило назван ие «Дырка при записи в RAI D 5». Этот эффект описывается н и же . Одн а ко будьте внима­ тельн ы : м ногие ш ироко распространенные недорогие RАI D ко нтроллер ы используемые в персональн ых компьютерах, вообще не и меют энер го не зав иси м о й памяти. На самом деле они представляют собой старый добрый интерфейс SATA с эл е м е нтам и встроен ного программ ного обеспечения RA I D . Реализации системы RAI D на м ате р и н с ки х платах пер­ сональных компьютеров также относятся к этой категори и . В так и х случаях луч ш е вообще отказаться от испол ьзования подобного RAI D в систе м ах Linux или FreeBS D . А луч ш е всего используйте файловые системы Z F S или Btrfs. Однажды на важном пром ышленном сервере про и зо ш ел отказ контроллера диска. Несмотря на то что дан н ые бьuш распределены по нескольким фи зич е с к им накопителям, неисправный контроллер RA I О уничтожил данн ые на вс ех дисках. В результате пришлось долго и нудно восстанавливать дан н ые на сервере. Поэто м у теперь для управления средой RAI D на восстановленном сервере используется встрое н ное в ядро п рограммное обеспе­ чение, что позволило исключить возможность нового сбоя ко н тролл ер а RAI D. ,

,

У ровн и системы RAI D Система RA I D выпол няет две важные вещ и . Во- первых, она может повысить с ко­ рость работы дисковой подс исте м ы , » разбросав» дан н ые по м н ог и м накоп ителя м и позволив нескольким дискам одновременно передавать или получать поток данн ых. Во- вторых, она может реплицировать дан н ы е по м ногим физ и ч е с к и м устройствам , уменьшая риск потери дан ных, связанный со сбоем одного д и с ка .

‘°Аббревиатуру RAI D иногда расшифровывают как » redundant arrays of independent disks» ( » избы­ точные массивы независи мых дисков » ) . Оба варианта с истор ической точ ки зре н и я я вля ются п р а ­ вил ьн ы м и .

Часть 111. Хранение данных

768

Репл и кация может осуществляться в двух видах: зеркал ьное отраже н ие (mirrori ng) , при котором блоки да н н ых побитово репродуци руются на нескол ьких накоп ителях, и испол ьзование схем четности (parity schemes) , когда оди н ил и нескол ько накоп ите ­ лей содержат контрол ьную сумму блоков дан н ых, расположен н ых на других дисках и позволя ющую восстановить эти дан н ы е в случае отказа одного из дисков. Зеркал ьное отражение быстрее , но зан и мает много места на диске. Схемы четности более экономно ис пол ьзуют дис ковую пам ять, но работают медленнее. Система RAI D традиционно описы вается в терм инах » уровней » , определяющих кон­ кретн ые детал и параллелизма и избыточ ности. Возможно, этот термин я вляется неудач­ н ы м , потому что более высокий уровень не обязател ьно оказы вается луч ш и м . Уровн и это просто разные конфи гурации ; вы можете использовать любой из н их . На рисун ках , приведе н н ых н иже , ч исла обозначают логические сегменты, а буквы а , Ь и с — блоки дан н ых в этих сегментах. Блоки , помече н н ые буквами р и q, являются блокам и четности. •

» Л и н е й н ы й режи м » , известный также как J BO D (just а bu nch of disks — п росто группа дисков) , нел ьзя даже назвать реальным уровнем систе м ы RAI D. Его реал и­ зует каждый контроллер RA I D. В режи ме J BO D сектора нескол ьких накоп ителей объединяются в оди н бол ьшой виртуал ьн ый накопител ь. Это н е обеспеч и вает н и избыточности дан н ых, н и повы ш е н и я производител ьности. В настоя щее вре мя функционал ьная возможность J BO D лучше обеспеч и вается с помощью менеджера логических томов, а не контроллера RAI D. Урове н ь RAI D О испол ьзуется тол ько для повы ш е н и я производител ьности . Он объеди н яет два или более накопителе й оди накового размера, но вм есто их объ­ единения последовател ьно оди н за другим он распредел яет дан н ы е между диска­ м и , входящими в пул . Операци и последовател ьного чтения и зап иси в этом случае оказы ваются распредел е н н ы м и м ежду нескольки м и физически ми диска м и . что сн ижает время записи и доступа к диску. Обратите внимание на то, что надежность уровня О значительно ниже надежности отдел ьн ых дисков. Вероятность отказа массива из двух дисков в течение года примерно в два раза выше, чем у отдел ьного диска, и т.д.

Урове н ь RAI D 1 известе н как » зеркал ьное отраже н и е » . Записи дубл ируются одновре менно на нескол ьких дис­ ках. Эта схема замедляет процесс зап иси по сравн е н и ю с зап исью дан н ы х на отдел ьн ый диск. Однако о н а обе­ с п е ч и вает с корость с ч и т ы ва н и я , с ра в н и мую с уров­ нем RA I D О , п отому что чте н и е можно рас пределять между нескол ькими дубл ирующ и м и накоп ител я м и . Уров н и RA I D +О и О+ представля ют собой группы зеркал или зеркала груп п . С логической точ ки зре н и я о н и представл я ют собой сочета н и е уро в н е й RA I D О и RA I D 1 , но м ногие контролл еры и програм м ы обе ­ спечивают их непосредстве нную поддержку. Цель обоих режи мов — одновре менно достичь производительности уровня RAI D О и избыточности уровня RA I D .

RAID 0 1a 2a 3a 4a

1b 2b 3b 4b

RAID 1 1 2 3 4

1 2 3 4

Глава 20. дисковая память

769

RAID 1

RAID 0 1a 2a 3a 4a

1b 2b 3b 4b

1a 2a 3a 4a

1b 2b 3b 4b

RAID 0

RAID 1 1a 2a 3a 4a •

RAID 0

1a 2a 3a 4a

RAID 0+1:

Зеркало группы

RAID 1 1b 2b 3b 4b

RAID 1+0:

1b 2b 3b 4b

Группа зеркал

Уровен ь RAI D 5 распределяет и дан н ые , и информацию о четности, добавляя из­ быточ ность и одновременно повышая производительность чте н и я . Кроме того , урове н ь RAI D 5 более эффе ктивно испол ьзует дисковое п ространство, чем уро­ вен ь RA I D 1 . Если массив состоит из N накопителей (требуется не менее трех), то N — 1 из н их могут хранить дан ные. Следовательно, эффективность испол ьзования дисковой памяти на уровне RAI D 5 превы шает 6 7 % , в то время как зеркал ьное от­ раже ние не может превысить 50%.

RAID 5 1a 2a 3a 4p •

1b 2b 3p 4a

1c 2p 3b 4b

1p 2c 3c 4c

Урове н ь RAI D 6 аналогичен уровню RA I D 5 с двум я дисками четности. М ассив RA I D 6 может сохран ить работоспособность при пол ном отказе двух накопителей без потери дан ных.

RAID 6 1a 2a 3a 4p

1b 2b 3p 4q

1c 2p 3q 4a

1p 2q 3b 4b

1q 2c 3c 4c

Уровни RAI D 2, 3 и 4 хотя и определ ен ы , но испол ьзуются редко. Менеджеры логи­ ческих томов обычно могут и чередовать дан ные ( RA I D О), и осуществлять зеркал ьное отражение ( RAI D 1 ) . Системы Z FS и Btrfs, представля ющие собой системы RAI D, менеджеров логических дисков и файловые систе мы вместе взятые , обеспечивают групп ирование, зеркал ирова­ н ие и настройку аналогично уровням RA I D 5 и RAI D 6. Подробнее об этих возможно­ стях см. в разделе 20. 1 1 .

Часть 111. Хранение данных

770

Система Linux поддержи вает файловые систе м ы ZFS и Bt rfs, хотя систем у Z F S н ужно и нсталлировать отдел ьно. Допол н ительную информацию с м . в разделе 2 0 . l l . Для обы ч н ы х конфи гурац и й ч ередования и зеркал ьного отраже н и я система Li nux предоставляет выбор: использовать специализирован ную систему RAI D (например, ко­ манду md; см. ниже ) или менеджер логического диска. Подход LVМ , вероятно, явл яет­ ся более гибки м , хотя команда md может оказаться нем ного более предсказуемой. Есл и у вас есть возможность испол ьзовать команду md, вы можете продолжать использовать механизм LVM для управления п ространством на томе RA I D. Для п рограм мной реал и­ R зации AI D уровней 5 и 6 вы должн ы использовать команду md . Файловая система ZFS является предпочтительным выбором в операционной системе FreeBSD, хотя там существуют две дополнительные альтернативы . На уровн е драйвера диска с истема geom в файловой системе Free BSD может объеди­ нять диски в массивы RA I D с поддержкой RA I D О , RA I D l и RA I D 3 . ( RAI D 3 похож на RAI D 5, но использует выдел е н н ы й диск для хран ения блоков четности вместо рас ­ предел е н и я блоков четности среди всех дисков.) М ожно даже создавать стеки с исте м geom, так что возможны комбинации RA I D l + О и RA I D О + l . Система Free B S D также включает поддержку RAI D О, RA I D l и RA I D 5 в своем ло­ гическом диспетчере томов GVinum. Однако с появле нием полной встроен ной поддерж­ ки Z FS во Free B S D будущее GVinum , похоже , под вопросом . Он еще официал ьно не устарел, но больше не поддерживается.

Восста новлен ие диска после сбоя Исследован и е причин отказов дисков, проведен ное ком пан ией Google и описан ное вы ш е , свидетельствует о том , что в большинстве промы шленных ком паний необходимо обеспечивать избыточность хранения информации на диске. Так, при ежегодном уровне отказов, равном 8 % , вашей организации потребуется около 1 50 жестких дисков тол ько для того, чтобы снизить этот показатель до одного сбоя в месяц. Режимы J BOD и RAI D О в плане надежности ничем помоч ь не могут, когда возн и ка­ ет проблема с отказом диска, — здесь просто н ужно почаще выполнять резервное копи­ рован ие данн ых. Другие конфигурации RA I D при аппаратном сбое отмечают вышедш ие R И :J строя диски как неисправн ые. С точки зрения клиентов массивы AID продолжают нормально функционировать, хотя и с более низкой скоростью. Неис правные диски необходимо как можно быстрее зам е н ить новым и , чтобы вос­ становить избыточность массива. Массив RAI D 5 или двуХдисковы й масси в RA I D l мо­ жет только смягчить последствия отказа отдельного н акопителя. Как только оди н сбой произошел, масси в подвергается опасности второго сбоя с полной потерей данн ых. П роцедура замены диска оче н ь п ростая . Следует заме н ить неисправ н ы й диск дру­ гим диском , и меющим такой же или больший объем памяти , а затем сообщить системе RA I D о том , что стары й диск был заменен новым. Последует продолжительн ы й период, в течение которого и нформация о четности будет переписана на новый , ч истый , диск. Часто эту операцию вы полняют в ночное время. В течение этого периода массив остает­ ся доступным для клиентов, но производительность, скорее всего, будет очень низкой . Для того чтобы ограничить время простоя и уменьшить уязвимость массива при вто­ ром сбое , большинство систем RA I D позволяет назначать оди н или несколько дисков н а рол ь » горячего резерва» . Когда возникает сбой , неисправ н ы й диск автоматически

Глава 20. дисковая память

771

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

Недостатки конфигурации RAI D 5 RA I D 5 попул ярная конфигурация, но у нее есть ряд недостатков. Все , что будет сказано ниже , относится и к конфигурации RAI D 6, но для простоты мы ограничим об­ суждение системой RAI D 5 . Во- первых, что следует особо подчеркнуть, конфигурация RAI D 5 н е отменяет ре­ гулярное автоном ное резервное коп ирован ие дан н ых. Она защи щает с исте му л и ш ь от сбоя диска, и все . О н а не защищает систе му н и от случайного удаления файлов, н и от сбоев контроллера, пожара, хакерской атаки и других опасностей . Во-вторых, конфигурация RAI D 5 не отличается высокой производительностью. Она хран ит блоки дан н ы х на N — 1 дисках, а блоки четности — на N-м диске . 1 1 П осле зап и ­ си произвол ьного блока должны быть обновл е н ы по крайней м е р е оди н блок да н н ых и оди н блок четности для указан ного логичес кого сегмента . Более того, с истема RA I D н е знает, что именно должен содержать новый блок четности , пока н е прочитает старый блок четности и старые дан н ы е . Следовател ьно, каждая запись в случайно выбран ное место дисковой подсисте м ы состоит из четырех операци й : двух операций считывания и двух операций записи. ( Есл и реал изация обладает развитой логико й , то последова­ тельные записи могут оказаться намного эффекти внее. ) И наконец, конфигурация RAI D 5 уязвима к повреждениям п р и определен н ых обсто­ ятельствах. Ее инкрементальное обновление дан ных о четности является более эффектив­ н ы м , чем чтение всего логического сегмента и повторное вычисление для него информа­ ции о четности на основе исходн ых дан н ых. С друго й сторон ы , это знач ит, что дан н ые о четности больше н и где не выч исля ются и не хранятся. Поэтому если будет нарушена синхронизация какого-нибудь блока в логическом сегменте , содержащего блок четности , этот факт никак не проявится при нормальной работе для конечного пользователя; опера­ ции считывания блоков данных по-прежнему будут возвращать правильные дан ные. Эта п робл е м а в ы я с н ится тол ько при сбое диска . Блок четности , вероятно, бу­ дет перезап исан м н ого раз с момента возн икнове н и я исходной расси нхро н и заци и . Следовател ьно, реконструирова н н ы й блок дан н ых на запасном диске будет состоять, по существу, из случайных дан н ых. Эта разновидность расс инхрон изации между блокам и дан н ых и четности не еди н ­ ствен ная проблема. Дисковые накопители не являются транзакцио н н ы м и устройствам и . Б е з дополн ител ьного уровня защиты сложно гарантировать, что н а разн ых дисках будут правил ьно обновлен ы л ибо два блока, л ибо н и одного. Для нарушен ия си нхронизации между блоком дан н ых и блоком четности достаточ но, чтобы произошел сбой диска. от­ кл ючение электропитания ил и разрыв связи в неподходящий момент. Эта проблема известна под назван ием «дырка при записи на RAI D 5» ( RA I D 5 «write hole » ) . Она является объектом пристал ьного изучения в течение последних десяти лет. Авторы файловой системы ZFS утверждают, что благодаря переменной длине логических сегментов в системе ZFS она защищена от проблемы «дырки при записи на RA I D 5 » . —

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

Часть 111. Хранение данных

772

Кстати, это одна из причи н , по которой авторы назвали свою реализацию системы RAI D в ZFS именем RAI D-Z, а не RAI D 5, хотя на практике эти кон цепции похожи. Еще одн и м потенциальн ы м решен ием явл яется » чистка» («scrubblng » ) диска, кото ­ рая состоит из поочередной проверки блоков четности во время простоя дискового мас ­ сива. М ногие реал изаци и с истем ы RAI D и м е ют т у или иную функцию чистки . О т вас только требуется не забывать ее регулярно запускать, например через утилиту cron ил и таймер systemd.

Кома нда mdadm: п рограммное обеспечение RA I D в системе Linux Стандартная реал изация програм м ного обеспечен и я RA I D для с исте м ы Linux называется md, драйвер » нескольких дисков» ( » multiple disks» d river) . Его вне ш н и й интерфейс обеспечивает команда mdadm. Драйвер md поддер ­ жи вает все конфи гураци и RA I D, перечисл е н н ые выше , а также RAI D 4 . Предыдущая с истема под названием raidtools больше не испол ьзуется . В ы также можете реал изовать RA I D в системе Linux с помощью диспетчера логиче­ ских томов ( LVМ2), или Btrfs, или другой файловой системы со встрое н н ы м и функци я ­ м и управления томам и и поддержки RAI D. М ы рассматриваем менеджер LVМ2 в разде ­ ле 20. 7 , а файловые систе м ы следующего поколения — в разделе 20. 1 1 . Как правило, эти м ноrочислен н ые реал изации представляют разные эпохи разработки проrраммноrо обе­ спече н ия , причем mdadm относится к первому, а Z FS/Btrfs — к последнему поколению. Все эти систе м ы а кти вно поддержи ваютс я , поэтому выбирайте в зав и с и м ости от того, что вы предпочитаете . Сайтам без установленной базы лучше всего перейти не­ посредственно на систему » все-в-одном » , например Btrfs.

Создание массива В следующем сценарии выпол н яется конфи гурация масси ва RA I D 5, состоящего из трех идентичных жестких дисков объемом l Тбайт. Несмотря на то что драйвер md может ис пользовать в качестве ком понентов н еформ атированные диски , м ы предпо­ ч итаем снабдить каждый диск таблицей разделов, поэтому нач инаем с запуска утилиты gparted, создающей табл и цу разделов G РТ на каждом диске , и выделения всего дис­ кового пространства одному разделу типа » Linux RA I D» . Совершен но не обязательно задавать тип раздела, но это будет полезной информацией для тех, кто станет просма­ тривать таблицу разделов позднее. Следующая команда создает массив RA I D 5 из наших трех разделов диска. $ sudo mdadm — — create /dev/md/extra — — level=S — — raid-devices=З /dev/ sdfl /dev/ sdql /dev/ sdhl

mdadm : De f a u l t i n g t o ve r s i on 1 . 2 me t ad a t a mdadm : a r r a y /dev/md / e x t r a s t a r t e d .

В иртуал ь н ы й файл / p r o c / md s t a t все гда содержит краткое описан и е состоя­ н и я драйвера md , а т а кже состояния всех масси вов RA I D , существующих в с истеме. Особенно полезено проанал и зировать содержимое файла /proc/mds tat после добавле­ н ия нового диска или замены н е исправного. Для этой цел и рекомендуем испол ьзовать команду cat /proc/mds tat.) $ c a t /proc/mdstat

P e r s ona l i t i e s :

[ l inear ]

[ mu l t i p a t h ]

[ raidO J

[ raidl ]

[ raid б ]

[ raid5 ]

Глава 20. дисковая память

[ raid4 ] [ raidl O J md l 2 7 : a c t ive r a i d 5 s d h l [ 3 ] s d g l [ l ] s d f l [ O J 2 0 9 6 8 8 6 7 8 4 Ы o c k s s u p e r 1 . 2 l e v e l 5 , 5 1 2 k chun k , a l g o 2 ( 3 / 2 ) [ > . . . . . . . . . . . . . . . . . . . . ] re cove r y = 0 . 0 % ( 9 4 5 8 4 0 / 1 0 4 8 4 4 3 3 9 2 ) f i n i s h= 5 3 5 . 2min s p e e d= 3 2 6 1 5 K / s e c bi tmap : 0 / 8 p a g e s [ О КВ ] , 6 5 5 3 6КВ chunk unu s e d d e v i c e s : < n one >

773

[ UU_ ]

Драй вер md не следит за тем , какой блок в масс иве был испол ьзова н , поэтому он должен вручную синхрон изировать все блоки четности с их соответствующим и блоками дан н ых. Драйвер md запус кает операцию » восстановления» ( » recovery») дан ных, потому что, по существу, она совпадает с той процедурой , которая вы полняется после зам е н ы неисправного диска. Для больших массивов она может выпол н яться довольно дл ител ь­ ное врем я ( нескол ько часов, ил и даже дне й ) . В файлах /var/log/mes sages или /var/ log/ syslog также записаны полезные со­ общен и я . k e r ne l : md : b i n d< s d f l > k e r ne l : md : b i n d< s dg l > k e r ne l : md : b i nd< s dh l > ke r ne l : md / r a i d : md l 2 7 : device s d g l ope r a t i on a l a s r a i d di s k 1 k e r ne l : md / r a i d : md l 2 7 : d e v i c e s d f l ope r a t i on a l as r a i d di s k О k e r ne l : md / r a i d : md l 2 7 : a l l oc a t e d 3 3 1 6 kB k e r ne l : md / r a i d : md l 2 7 : r a i d l ev e l 5 a c t i ve wi t h 2 out o f З de v i ce s , a l g o r i thm 2 ke rne l : RA I D c o n f p r i n t ou t : ke rne l : — — — l e v e l : 5 r d : 3 wd : 2 ke rne l : d i s k О , o : l , d e v : s d f l ke rne l : d i s k 1 , o : l , dev : s dg l ke rne l : c r e a t e d b i tmap ( 8 pag e s ) f o r d e v i c e md 1 2 7 mda dm [ l l 7 4 ] : N e wAr r a y e v e n t d e t e c t e d o n md d e v i c e / d e v / md 1 2 7 mdadm [ l 1 7 4 ] : D e g r adedA r r a y event d e t e c t e d o n md d e v i c e / d e v /md 1 2 7 k e r ne l : md 1 2 7 : b i tmap i n i t i a l i z ed f rom d i s k : r e a d 1 p a ge s , s e t 1 5 9 9 8 o f 15998 Ьits ke r ne l : md l 2 7 : de t e c t e d capac i t y change f r om О t o 2 1 4 7 2 1 2 0 6 6 8 1 6 k e r ne l : RAI D c o n f p r i n t ou t : k e r ne l : — — — l e v e l : 5 r d : 3 wd : 2 ke rne l : d i s k О , o : l , dev : s d f l ke rne l : d i s k 1 , o : l , d e v : s d g l k e r ne l : d i s k 2 , o : l , d e v : s d h l ke rne l : md : r e c ove r y o f RA I D a r r a y md l 2 7 k e r ne l : md : min imum _gua r a n t e e d_ s p e e d : 1 0 0 0 KB / s e c / d i s k . ke rne l : md : u s i ng max imum ava i l aЫ e i d l e I O b andwi dth ( but n o t mo r e t h a n 2 0 0 0 0 0 K B / s e c ) f o r r e c ove r y . ke rne l : md : u s i ng 1 2 8 k window , ove r а t o t a l o f 1 0 4 8 4 4 3 3 9 2 k . mda dm [ l l 7 4 ] : Rebui ldS t a r t e d e v e n t de t e c t e d on md devi c e / d e v / md 1 2 7

Команда первоначал ьного создания также предназначена дл я «активизаци и » массива (т.е. для приведе н ия его в состоян и е , пригодное для испол ьзова н и я ) . При последующих перезагрузках в бол ьшинстве дистрибутивов ОС, вкл ючая те , которые рассматриваются в книге , поиск существующих массивов и их повторная акти визация выпол н я ются авто­ матически. Обратите в н и мание на то, что при выпол н е н и и команды mdadm — create указыва­ ется путь к устройству для составного масс и ва. Пути md-устройств старого стиля вы ­ глядел и как /dev/mdO , но когда вы указы ваете путь в каталоге /dev/md, как это было сделано в дан ном примере , mdadm записы вает вы бранное имя в суперблок массива. Эта

Часть 111. Хранение данных

774

мера гарантирует, что вы всегда можете найти массив по логическому пути , даже если после перезагрузки масси в активизирован автоматически и ему может быть присвоен другой номер. Как видно из записей журнала, приведе н ных выше, масси в также и меет традиционное имя (здесь, /dev/md12 7 ) , а /dev/md/extra это просто символ ическая ссыл ка на реальное устройство массива. —

mdadm . соп:Е: д о кументирование конфигурации массива Формал ьно, команда mdadm не требует нал и ч и я файла конфигураци и , но есл и он есть, она е го испол ьзует ( как правило, это файл /etc/mdadm/mdadm . conf ил и /etc/ mdadm . conf). М ы настоятельно рекомендуем испол ьзовать файл конфигурации и до­ бавить в него элементы ARRAY при создании нового масси ва. В результате вы создадите в стандартном м есте документаци ю по конфигурации систем ы RA I D , позволяя админи­ стратору просмотреть информацию при возни кнове н и и проблемы. В качестве альтерна­ тивы использован и ю файла конфигураци и можно задавать конфигурацию в командной строке при каждой активизации масси ва. Команда mdadm — -detai l — — scan зап исывает текущие н астройки систе м ы RA I D в файл конфигурации mdadm . conf. $ sudo mdadm — -detail — — s can ARRAY / d e v / md / e x t r a me t a d a t a= l . 2 name=ubun t u : e x t r a U U I D=b7 2 de 2 fb : 6 0 b 3 0 З а f : З с 1 7 6 0 4 8 : dс 5 Ь б с 8 Ь

Теперь команда mdadm с может прочитать файл mdadm . conf п р и загрузке или завер­ ш е н и и работы с исте м ы , что намного упростит управление м ассивом. Н апример, дпя того чтобы отключить массив, созда н н ы й выше, достаточ но запустить следующую ко­ манду. $ sudo mdadm -S /dev/md/extra

Для того чтобы запустить масси в снова, можно выпол н ить такую команду.

$ sudo mdadm -Ав /dev/md/extra

Первая из приведе н н ых выше команд сработает, даже если файла mdadm . conf не су­ ществует, а вторая — нет. В предыдущих и зданиях этой книги м ы ре комендовали добавлять записи D E V I C E дЛЯ компонентов каждого масси ва в файл mdadm . conf. Теперь м ы берем свои слова об­ ратно. Н азвания устройств в наши дни стали сли ш ком непостоя н н ы м и , и команда mdadm лучше находит и идентифицирует компоненты массива, чем ран ьше. Теперь м ы не счита­ е м , что записи DEV I CE — лучшая практика. Команда mdadm и м еет режим — -monitor, в котором она вы пол н я ется постоян но как демон и сообщает по электрон ной почте о проблемах , возникших в масси ве RA I D . Используйте эту возможность! Для того чтобы ее н астроить, добавьте строку МAI LADDR или PROGRAМ в с вой файл mdadm . conf. Конфигурация MAI LADDR указывает адресата, которому следует отправлять предупрежден и я по эле ктронной почте, а конфигурация PROGRAМ запускает в н е ш н юю програм м у дЛЯ фор мирован ия отчетов, которую вы уста­ новил и (это полезно дпя и нтеграци и с системой мониторин га; см. главу 2 8 ) . Кром е того, во врем я загрузки н еобходимо запустить дем о н монитор и н га. Во всех рассматр и ваем ых нами дистрибутивах ОС это делается с помощью сценария ini t, но имена и процедуры могут сле гка отличаться . deb i a n $ sudo update — rc . d mdadm еnаЫе ubu n t u $ sudo update-rc . d mdadm еnаЫе

Глава 20. дисковая память

775

redh a t $ sudo sys temctl еnаЫе mdmoni tor cent o s $ sudo sys temc tl еnаЫе mdmoni tor

Имитация сбоя Что произойдет, если диск действител ьно выйдет из строя? П опробуем разобраться! Команда mdadm предоставляет нам прекрасную возможность сымитировать сбойный диск. $ sudo mdadm /dev/md/extra f /dev/ sdql mdadm : s e t /de v / s d g l f a u l t y i n /dev/md / e x t r a —

$ sudo tai l — 1 /var/loq/messaqes Ap r 1 0 1 6 : 1 8 : 3 9 ubun t u ke r n e l : md / r a i d : md l 2 7 : D i s k f a i l u re on s dg l , d i s aЫ i n g devi ce . # 0 1 2md / r a i d : md l 2 7 : Op e r a t i on con t i nu i n g on 2 d e v i ce s . $ cat /proc/mds tat P e r s o na l i t i e s : [ l i n e a r ] [ mu l t i pa t h ) [ r a i d O ) [ r a i d l ) [ r a i d 6 ) [ r a i d 5 ] [ ra i d 4 ) [ ra i d l O ] md l 2 7 : a c t ive r a i d 5 s d h l [ 3 ) s d f l [ 0 ] s d g l [ 1 ] ( F ) 2 0 9 6 8 8 6 7 8 4 Ы o c k s s upe r 1 . 2 l e vel 5 , 5 1 2 k chun k , a l go 2 [ 3 / 2 ] [ UU_ ] unu s e d device s :

Поскол ьку RAI D 5 представляет собой устойчивую к отказу одного диска конфи гу­ раци ю, масс и в продолжает функцион ировать в режиме деградации, так что пользовате ­ ли могут не заметить возн икшей проблемы вовсе. Для того чтобы удал ить накоп ител и из конфи гураци и RA I D , в ы пол н ите команду mdadm -r. $ sudo mdadm /dev/md/ extra -r /dev/ sdql mdadm : hot r emoved /dev / s d g l f r om /dev/md / e x t ra

Как тол ько диск будет логически удал е н , вы можете остановить с истему и замен ить накопител ь. Ап паратное обеспечение, допус кающее » горячую замену», позволяет про­ изводить замену дисков без остановки систе м ы и ее перезагрузки . Если ваш RАI D- массив построен на основе физических дисков, вы должн ы заменять их только иде нтич н ы м и дискам и. Если вместо дисков используются разделы , то их мож­ но заменять л юбым и разделами подходя щего разм ера. Последнее утвержден ие я вляется достаточно веской причиной для того, чтобы создавать массивы на основе разделов, а не физических дисков. С точ ки зрения производительности л уч ш е , чтобы RА I D — массивы создавались из дисков одного производителя . ( Если ваша конфигурация RA I D построе ­ на на основе разделов, вы должны запустить утил иту разбиения диска и правил ьно соз­ дать разделы , прежде чем добавлять диск в массив.) В нашем при мере сбой всего лишь смоделирован , поэтому м ы можем вернуть на ко­ питель обратно в масси в , не заменяя ни какого физического диска. $ sudo mdadm /dev/md/extra mda dm : hot added /dev / s d g l

/dev/ sdql

Драйвер md немедленно начнет перестраивать массив. Как обы ч но, за выполнениеt этой процедуры вы можете следить с помощью файла /proc/mds tat. П ерестройка мо­ жет идти часам и , так что учтите этот факт, составляя план по восста новлению (и тест и ­ рован ию!) системы после сбоя.

776

Часть 111. Хранение данных

20.9. ФАЙЛОВЫЕ СИСТЕМЫ Даже после разбиен ия жесткого диска на раздел ы и л и логические тома на н е м еще нел ьзя хран ить файл ы . Для этого необходимо реализовать все абстракции и функци и , описанные в главе 5 , в тер м и нах блоков. О н и реал изуются кодом , которы й называется файловой системой и требует допол нител ьных затрат ресурсов и данных. В ран н их версиях операцион ных систем реализация файловой систе м ы была встро­ ена в ядро, но вскоре стало ясно, что поддержка м ногоч исленных типов файловых си­ стем я вляется важной целью. Разработчики систем U N IX создали хорошо определенный и нтерфейс ядра, позволявш и й одновременно активировать несколько ти пов файловых систе м . Кроме того, базовое аппаратное обеспечение было абстрагировано с помощью и нтерфейса файловой с исте м ы , так что файловые систе м ы видели примерно такой же и нтерфейс для накопителей, что и другие програм м ы систе м ы U N IX, имеющие доступ к дискам через файлы устройств в каталоге /dev. И значально поддержка нескольких типов файловых систем объяснялась необхо­ димостью поддерживать с истем у N FS и файловые систе м ы для с м е н н ых носителей . Однако, как только шлюз был открыт, началась эра поисков ; м ногие групп ы стали ра­ ботать над улучш е н ие м файловых с исте м . Н е которые из этих файловых систем б ыл и предназначены дл я кон кретных операционных систе м , а другие ( например, ReiserFS) не был и связаны ни с какими определенн ы м и операционн ы м и системами . В больши нстве операционных систем по умолчанию установлены одна или две фай ­ ловые с истемы . Э т и файловые систе м ы тщательно тестируются вместе с остальной ча­ стью с исте м ы до выпуска стабильных версий. Как правило, систе м ы официально поддерживают одну файловую систему традици­ онного стиля ( U FS , ext4 или XFS) и одну файловую систему следующего поколения , ко­ торая вкл ючает в себя функции управления томами и RA I D (ZFS или Btrfs) . Поддержка последних опций обычно луч ш е всего реал изуется на физическом оборудова н и и ; в об­ лач н ы х с исте мах они могут использоваться для разделов дан ных, но для загрузочного диска только изредка. Несмотря на то что реал изации других файловых систем как правило устанавливаются в виде обыч н ых пакетов, применение допол нительных файловых систем часто приносит риск и потенциальную нестабильность в работе для всей ОС. Файловые систе м ы яаляют­ ся основополагающи м и , поэтому он и должны быть на 1 00% стабильны и надежны при всех сценариях использования. Разработчики файловых систем упорно трудятся , чтобы достичь такого уровня надежности, но риск не может быть полностью исключе н . 1 2 Если тол ько вы н е создаете огро м н ы й п ул для хранения дан ных или д и с к для р а ­ боты специфического приложен и я, м ы рекомендуем использовать только т е файловые с исте м ы , которые поддерживаются в вашей ОС. И менно это, скорее все го, и предпо­ лагается в документации и средствах адм и нистрирования вашей ОС. В следующих разделах более подробно описаны наиболее распространенные файло­ вые систе м ы и их управление. Сначала мы опишем традицион ные файловые систе м ы U FS , ext4 и X F S , а затем перейдем к системам следующего поколения ZFS (раздел 20. 1 2) и Btrfs (раздел 20. 1 3) .

1 2 Н едавно ком п а н и я Apple перевела ЮS-устройства ( которых насчитывают более м иллиарда) н а совершенно новую написанную с н уля файловую систему под названием A P F S . То, что этот пере ­ ход был выпол н е н невидим о и без заметных катастроф, было поистине историческим достижени ­ е м и нженерного искусства.

глава 20. дисковая память

777

20. 1 о. ТРАДИЦИОННЫЕ ФАЙЛОВЫЕ СИСТЕМЫ: U FS, ЕХТ4 и XFS Файловые с исте м ы U FS , ext4 и XFS имеют разн ый код и истори ю , но со временем они стали очень похожими друг н а друга с точки зрения адм и н истрирования. Эти фай­ ловые систе м ы илл юстрируют старый подход, в котором управл е н и е томами и RA I D реализовано отдельно от самой файловой систе м ы . Эти с исте м ы предназн ачены исклю­ чител ьно дл я реал изац и и старых добрых файловых хра н ил и щ на блоч ных устройствах заранее определенного размера. И х возможности более или менее огран ичен ы тем и , ко­ торые описаны в главе 5. Старые файловые системы в этой категории имеют с крытый дефект: если в середине операции записи было прервано п ита н и е , то дисковые блоки могут содержать некор­ ректные структуры дан ных. Для решения этой проблемы и автоматического исправле­ ния других наиболее распространенных ошибок во врем я загрузки для проверки файло­ вых систем использовалась команда fsck. Совре м е н н ы е файловые систе м ы в ключают функцию, называемую журналировани­ ем, которая предотвращает возможность такого рода поврежде н и й . Когда происходит операция файловой систе м ы , необходимые изменения с начала записываются в журнал . После завершения обновления журнала записывается специал ьная » фиксирующая за ­ пись» (commit record) , помечающая конец элемента дан н ых. И только после этого будет изме нена нормальная файловая с истема. Есл и во врем я обновления п роизошел сбой , файловая система может позже воспроизвести журнал дл я восстановления идеал ьно со­ гласован ной файловой с исте м ы . 1 3 Журналирование умен ьшает вре м я , необходимое для выполнения проверки целост­ ности файловой системы (см . раздел , посвяще н н ы й команде fsck) примерно до одной секунды для каждой файловой систе м ы . Есл и произошел аппаратн ы й сбо й , состоя н ие файловой с истем ы может быть практически мгновенно оценено и восстановлено. Система Berkeley Fast File System, реал и зован ная Мак- Кьюзиком и другим и в 1 980х годах, была первым стандарто м , распространяющимся на м ногие с исте м ы U N IX. С некоторы м и н ебол ьш и м и корректировка м и она в конечном итоге стала известна как файловая с истема U N IX ( U FS) и легла в основу нескольких других реали заций файло­ вой системы, вкл ючая серию файловых системе ext для Linux. U FS остается стандартной файловой с истемой, испол ьзуемой в с истеме FreeBSD. » Вторая рас ш иренная файловая с исте ма» ( » second extended filesystem » ) , получ ив­ шая назван ие ext 2 , долгое время была основным стандартом в с истем е Linux. Она была разработана и реал изована Ре м и Кардом ( Remy Card) , Теодором Тс ‘о (Theodore Ts’o) и Стивеном Твиди ( Stephen Tweedie) . Помимо того, что код файловой систе м ы ext2 был на писан с п е циально дл я систе м ы Linux, с фун кциональной точ к и зрен и я он похож на файл овую систему Berkeley Fast File System. Файловая с исте ма ехt З рас ш и ряла возможности жур н ал ирова н и я , а с истем а ext4 представляет собой определен ное улучшение своих предшествен н и ков. Она расширяет предел ы максимально допусти мой памяти , увел ичивает производительность некоторых операций и позволяет испол ьзовать для выделения памяти не отдел ьные дисковые бло1 ‘ В больш и н стве случаев журналируются только изменения метада н н ых. Фактические дан н ы е , ко­ торые нужно сохран ить, зап исываются непосредственно в файловую систему. В некоторых фай­ ловых системах также может использоваться журнал для фиксации дан ных, н о это требует значи­ тел ьных экс плуатационных расходов.

778

Часть 111. Хранение данных

ки, а целые экстенты (логические диапазоны дисковых блоков) . Файловая система ext4 де-факто стала стандартной для операцион ных систем Deblaп и Ubuпtu. Файловая с истема XFS была разработан а ком пан и е й Silicon G гaphics, l nc . , позже известной как SG I . Это была стандартная файловая с истем а для I R IX, верси и U N IX от SGI. Она была одной из первых файловых с исте м , испол ьзовавш их экстенты. Это сделал о ее особе н н о подходящей для приложе н и й , обрабатывающих большие медиа­ файл ы , как это делали м ногие клиенты SG I . XFS я вляется стандартной файловой систе­ мой для операцио н н ых систем Red H at и CentOS.

Терминология фа йло в ы х систем Благодаря с воему родству м ногие файловые систе м ы испол ьзуют общую оп иса­ тел ьную тер м инологию . Реал и заци и базовых объектов часто изме няются , но тер м и н ы по-прежнему ш ироко употребля ются систе м н ы м и администраторам и к а к обозначения фундаментальных поняти й . Например, индексные дескрипторы ( » i nodes») — это записи фиксированной длины в табл и це , кажды й элемент которой хранит и нформацию об от­ дельном файле. Ранее они заносились в эту табли цу в момент создания файловой систе­ м ы , но в настоящее вре м я н е которые файловые систе м ы создают их динамически при необходимости . В л юбом случае и ндексный дескриптор обычно и меет идентификаци­ онный номер, который можно увидеть с помощью команды l s — i . И ндексные дескри пторы это т е объекты , на которые указывают элементы каталога. При создании жесткой ссыл ки на существующий файл создается новый элемент катало­ га, но не новый и ндексный дескри птор. Суперблок (superЫock) — это запись, описывающая характеристики файловой с и ­ сте м ы . Она содержит и н формацию о длине дискового блока, размере и местоположе­ н и и табли ц и ндексных дескрипторов, карту блоков и и нформаци ю об их испол ьзова­ н и и , размер rруп п блоков и не которые другие важн ые параметры файловой систе м ы . Поскол ьку повреждение суперблока может привести к потере оче н ь важной информа­ ции , несколько его копи й хран ятся в разных местах. Для пов ы ш е н и я производител ьности работы в ядре кеш ируются дисковые блоки. Кеш ировать можно все дисковые блоки , включая суперблоки, блоки и ндекс н ы х дес­ кри пторов и и нформ ац и ю о каталоге . Кеш и обычно не работают в режиме «сквозной записи » («write-through » ) , поэтому может возникнуть некоторая задержка между момен­ том , когда п риложе н и е «считает» , что блок зап исан , и моменто м , в которы й блок дей ­ ствительно записывается н а диск. П р иложения могут затребовать от файла более пред­ сказуемого поведен и я , но в этом случае резко снижается их скорость работы . Систе м н ы й вызов syno направляет модифицированные блоки в место их постоян но­ го хранения на диске , стараясь моментально обеспеч ить полную согласованность дис­ ковой файловой с исте м ы . Это периодическое сохранение м и н и м изирует потерю дан ­ ных, которая может произойти при сбое из-за м ногочисленных н есохраненных блоков. Файловые систе м ы могут самостоятельно выполнять синхрон изацию по собствен ному рас п исан и ю или предоставить это операционной системе. Совре м е н н ые файловые си­ сте м ы и м е ют м ехан изм журнал и ровани я , м и н и м и зирующий ил и искл ючающи й воз­ можность поврежден и я их структуры при сбое , поэтому частота синхронизаци и должна зависеть от того, с кол ько блоков могут оказаться потерян ны м и при сбое . В файловой системе карта дисковых блоков — это табл ица содержащихся в ней сво­ бодных блоков. При записи новых файлов система анализирует эту карту, чтобы найти эф­ фективную схему хранения. В файл овой системе также хран ится сводка по использованию дисковых блоков, где содержится важная информация об уже распределенных блоках.

Глава 20. дисковая память

779

П ол иморфизм фа йловых систем Файловая систем а — это програм м н ое обеспечение, состоящее из многочисленных компонентов. Одна ее часть находится в ядре (ил и же в пользовательс ком пространстве системы Linux; наберите в поисковой машине Google аббревиатуру FUSE) и реализует ос­ новные операции, связанные с трансляцией вызовов стандартного интерфейса API фай­ ловой системы в операци и чте н ия и записи блоков диска. Другие части состоят из поль­ зовательс ких команд для форматирования новых томов, проверки целостности файловой системы и выполнения других специальн ых операций, связанн ых с форм атированием . Ранее стандартные пользовательские команды » знал и все » о файловой с истеме, ко­ торую испол ьзовала операционн ая систе ма, и просто реализовали требуемые фун кцио­ нал ьн ые возможности. Так , команда mkfs создавала новые файловые с исте м ы , команда fsck устраняла проблемы , а команда mount, в основном, п росто вызывала систе м н ы е функци и . В н астоящее врем я существует м ножество файловых с исте м , поэтому операцион ­ ные с исте м ы должн ы реш ить, как испол ьзовать их возможности. Долгое время опера­ цион ная с истема Linux стрем илась подогнать все файловые систе м ы под оди н стандарт и скрыть их за командами-оболочкам и mkfs и fsck. Эти команды вызывали отдельные команды , например mkfs . имя_ файлов ой_ системы и fsck . имя_ ф а йлов ой_ системы в зависи м ости от кон кретной файловой систе м ы . В н астоящее время желание унифи­ цировать все файловые с истемы ушло в прошлое , и большинство операционных систем предлагают пользователя м вызывать команды файловых с истем непосредствен но.

Форматирование файловых систем Для создан ия новой файловой систе м ы следует выпол н ить следующую ко­ манду. mkfs . имя_ ф а йлов о й_ системы [ -L ме тка ]

[ другие_ параметры] ус трой с тв о

В системе Free B S D процесс создания файловой с исте м ы U FS аналогичен предыду­ щему, но в место команды mfks выполняется команда newfs. newfs [ -L ме тка ]

[ другие_ параметры] ус тр о йс тв о

П араметр -L в обоих вариантах задает метку тома для файловой систе м ы , например, spare , home или extra. Это только оди н из м ногих параметров, но м ы рекомендуем его использовать во всех файловых системах. Он позволяет избавиться от ручного отсле­ живан и я устройства, на котором расположена файловая с истема, при ее монтировани и . Это особенно удобно, если имя дискового устройства может изменяться. Остальные опци и , указываемые в другие_ параме тры, зависит от конкретной фай ­ ловой систе м ы , и используется редко.

Ком анда fsck: п роверка и исп равлен ие файловых систем Из-за буферизаци и блоков и того факта, что дисковые накопители на самом деле не являются транзакционными устройствам и , структуры дан ных н а файловых системах мо­ гут стать рассогласован ными. Если эти проблемы не устран ить как можно скорее, то это превращается в снежны й ком . П ервоначал ьно проблемы с файловой системой устранял ись с помощью вызова ко­ м анды fsck ( » filesystem consistency chec k » ; читается как » FS check» или «fisk » ) , которая тщательно проверяла все структуры дан н ых и просматривала дерево выделения для каж-

Часть 111. Хранение данных

780

дого файла. Она использовала набор эвристических правил , описывающих возможны й внешн и й вид файловой систе м ы после повреждения, в разные моменты времени в про­ цессе ее обновлен и я . Оригинал ьная схема fsck работала уди вител ьно хорошо, но поскольку о н а предус­ матривала чтение всех данн ы х с диска, для больших дисков процедура могла зан и м ать несколько часов. Одно из первых реш е н и й этой задач и было основано на кон цепци и бита » чистой файловой систе м ы » , которы й устанавл и вался в суперблоке , когда файло­ вая с истем а корректно демонтировалась. П р и повторном монтирован и и файловой с и ­ сте м ы этот б и т проверялся , и таким образом можно было узнать, что проверку с помо­ щью команды fsck можно пропустить. В настоящее время журнал ы файловой системы позволяют команде fsck сосредото­ ч ить свое внимание на том , что произошло во время сбоя . С их помощью команда fsck может просто восстановить предыдущее согласован ное состоян ие файловой систе м ы . К а к правило, диски обрабатываются командой fsck автоматически в о врем я началь­ ной загрузки с истемы, если они указан ы в системном файле /etc/fstaЬ. В файле fstaЬ есть уже устаревшие поля, с помощью которых задавался порядок проверки файловых си­ стем с помощью команды fsck и возможность распараллеливания этой работы. Однако в настоящее время команда fsck выполняется настолько быстро, что для нее и меет значе­ ние только оди н фактор — чтобы корневая файловая с истема проверялась первой. Команду fsck можно запустить вручную, чтобы выпол н ить глубокую проверку, ко­ торая была характерна для ее первых версий, но для этого потребуется время. Семейство файловых с истем ext в операционной системе Linux может быть настроено так, чтобы повторн ая проверка выполнялась после демонтирова­ ния определенное коли чество раз или по истече н и и определе н ного периода времени, даже есл и все демонтированные файловые систе м ы были » ч исты ­ м и » . Это полезная процедура, и в большинстве ситуаци й приемлем ы м я вл я ­ ется значен ие , задаваемое по умолчани ю (около 2 0 монтирований). Однако если файловые систе м ы монтируются часто, как это происходит в настоль­ ных рабочих станциях, то даже эта частота выполнения команды fsck может стать чрезмерной. Для того чтобы увеличить и нтервал вре ме ни до 50 монти­ рований, следует использовать команду tune2fs. $ sudo tune2fs — с 50 / dev/ sdaЗ t u ne 2 f s 1 . 4 3 . 3 ( 0 4 — S e p — 2 0 1 6 ) S e t t in g max imal mount count t o 5 0

Если файловая с истема повреждена и команда f s ck н е может восстановить е е ав­ томатически, то не следует с ней экспериментировать, пока н е будет создана н адежная резервная копи я . Лучшая пол итика страхования — прим е н ить ко всему диску команду dd и создать резервны й файл ил и диск. Большинство файловых систем создает каталог los t+found в корневом разделе каж­ дой файловой системы, где команда fsck может хранить файл ы , для которых невозможно определить родительский каталог. Каталогу lost+found предварительно выделяется до­ пол н ительное дисковое пространство, чтобы команда fsck могла хран ить «осиротевшие» файлы , н е создавая допол нительных каталогов в нестабильной файловой системе. Н е уда­ ляйте этот каталог. 14 1 4 8 н екоторых системах для восстановлен ия этого каталога после удаления испол ьзуется команда mklos t+found.

глава 20. дисковая память

781

Поскольку и м я , присвоенное файлу, записывается только в родительском каталоге , имена «осиротевш их» файлов недоступны, и файлы, хранящиеся в каталоге los t+found, именуются по названиям их индексных дескри пторов. Однако таблица и ндексных де­ скрипторов содержит идентификаторы U I D владельца файла, что позволяет легко возвра­ щать файл е го владельцу.

М онти рован ие фа йловой системы Файловую с исте му н еобходимо смонтировать до того , как она станет види мой для процессов. Точ кой монтирования для файловой системы может быть любой каталог, поэтому файлы и подкаталоги , которые расположен ы ниже этой точк и в иерархии, оста­ нутся недоступн ы м и , пока другая файловая система будет с монтирована в этой точке. Более подробную и нформацию можно найти в разделе 5 . 2 . После инсталляции нового диска необходимо с монтировать новые файловые систе­ мы вручную, чтобы убедиться , что все работает правильно. Например, команда $ sudo mount / dev/ sdal /mnt/ temp

монтирует файловую систему в разделе , представлен ном файлом устройства /dev/ sdal (имена устройств зависят от операцион ной системы) , в каталоге /mnt, который является традиционн ы м для временных точе к монтирования. Размер файловой системы можно проверить с помощью команды df. В приведе н ном ниже примере флаг -h системы Linux используется для выдачи результатов в понятном для человека виде. К сожалению, большинство систе м н ых значен и й , заданных по умол­ чанию для команды df, относятся к бесполезны м сущностям , таким как «дисковые бло­ ки», но есть флаг, заставляющий команду df выдавать кон кретную информацию, на­ пример двоичные кило- или гигабайты . $ d.f -h /mnt/weЫ

Fi l e s y s t em /dev /mappe r / DEMO -weЫ

Size

Used

Ava i l

l 97G

б ОМ

l87G

Use% 1%

Moun t e d o n /mn t / weЫ

Настрой ка автоматического монтирова ния Обычно операционные с истемы настраиваются так, чтобы локальные файловые си­ сте м ы автоматически монтировались на этапе начальной загрузки. В файле конфигу­ рации (среди прочей и нформации) /etc/ fstaЬ перечислен ы имена устройств и точки монтирования для всех системных дисков. Команды mount, umount, swapon и fsck читают содержимое файла f s tab, поэтому желательно, чтобы представленные в этом файле дан ные были правильными и полными. Команды mount и umount используют этот файл, чтобы выяснить, что м ы хотим , ука­ зывая в командной строке только имя раздела или точку монтирования. Например, при конфигурации файла fstaЬ в системе Linux, приведен ной далее, команда $ sudo mount /media/ cdrornO

эквивалентна следующей команде. $ sudo mount — t ud.f

user , noauto , exec , utf8 /dev/ scdO /media/ cdromO

Команда mount -а монтирует все регулярные файловые с исте м ы , перечислен н ые в файле fs tab ; обычно эта команда выпол няется в рамках сценария запуска на этапе

Часть 111. Хранение данных

782

начал ьной заrрузк и . ‘5 Аргумент -t тип_ ф а йл о в о й_ си с т емы ограничи вает операции над файловыми системами только указанного типа. Например, команда $ sudo mount -at ext4

монтирует все локал ь н ые файловые системы ext4. Команда mount ч итает файл fs taЬ посл едовател ьно. Следовател ьно, файловые с исте м ы , смонтирова н н ы е под другим и файловыми системами , должны следовать за своими родительскими разделам и , указан­ ными в файле fstaЬ. Например, строка для файла /var/ log должна следовать за стро­ кой /var, если /var — отдельная файловая система. Команда umoun t , предназначен н ая для демонтирования файловых систе м , и м е ет аналоги ч н ы й с интаксис. Файловую с истему, которую некий процесс испол ьзует в ка­ честве с воего текущего каталога или которая содержит открытый файл , демонтировать нельзя. Существуют команды , позволяющие идентифицировать процесс ы , препятству­ ющие попыткам выполнить команду umount; с м . раздел 5 . 2 . Файл fstaЬ в системе FreeB S D я вляется наиболее традиционным из наших примеров систе м . Рассмотри м его записи для систе м ы , имеющей тол ько одну файловую систему, смонтированной под корневой файловой системой ( / spare). # Device / d ev / gp t / r o o t f s / d ev / gp t / swap — a / d e v / gp t / swap-b f de s c p r oc / d e v / gp t / s p a r e

Moun t p o i n t / none none / de v / fd /proc / sp a r e

F S t yp e u fs s wap s wap f de s c f s procf s ufs

Op t i o n s rw sw sw rw rw rw

Dump 1

Pas s # 1

о о о о о

о о о о о

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

W Дополнительную информацию о системе N FS см . в главе 2 1 . Первое поле содержит имя устройства. Файл fstaЬ может содержать точки монтиро­ вания, находящиеся в удаленных системах. В этом случае первое поле содержит путь N FS. Обозначение s erver : /expor t означает каталог /expor t на машине с именем server. Второе поле задает точку монтирования, а третье — тип файловой систе м ы . Точ ное название типа, идентифицирующего локал ьные файловые с истемы, зависит от конкрет­ ной машины. Четвертое поле задает опции команды mount, которые должны применяться по умол­ чанию. Существует множество возможностей ; опции , общие для всех типов файловых с исте м , можно найти на с правочной странице для команды mount. Отдельные файло­ вые с истем ы обычно имеют собствен н ые опци и . П ятое и ш естое поля я вляются рудим ентар н ы м и . Предположительно они задавали «частоту создания коп и и » и параметр управления параллельны м выпол нением команд fsck.. Ни одна из этих возможностей в современных с истемах не актуальна. Устройства, указанные для файловых систем /dev/ fd и /proc, являются фиктивны ­ м и элементами . Эти виртуальные файловые систем ы зависят о т кон кретной операци­ он ной системы и н е требуют допол нительной информации для монтирования. Другие 1 5 0пция n o a u t o команды mount исключает указанную файловую систему из п роцесса автомат и ­ ческого монтирования с помощью команды mount а —

.

Глава 20. дисковая память

783

устройства идентифицируются их метками разделов G РТ, что я вляется более надежн ым вариантом , чем использование фактических и м е н устройств. Чтобы узнать метку суще­ ствующего раздела, выпол н ите команду gpart show — 1 диск

д11 я вывода таблицы разделов соответствующего диска. Чтобы установить м етку для раз­ дела, используйте команду gpart шodify -i индекс -1 метка диск16

Файловые с истемы U FS также имеют собствен н ы е метки, и они отображаются в ка­ талоге / dev/uf s . М етки U FS и м етки разделов я вл я ются разн ы м и , н о им можно ( и , вероятно, следует) присвоить одинаковые значен ия . В этом п р и м ере файловая система /dev/ufs / spare будет работать так же , как /dev/gp t / s pa re . Чтоб ы оп редел ить теку­ щую метку файловой систе м ы , вы пол н ите команду tunefs -р ус тро й с тв о

Чтобы установить метку, выпол н ите команду tunefs -L метка ус тройств о

Размонтируйте файловую с истему перед установкой метки . Н иже приводятся примеры файла fstaЬ из систе м ы Ubu ntu . Общий формат тот же , но системы семейства Linux часто и м е ют разн ые особен ности. # < f i l e s y s t em> proc UU I D= a 8 e 3 _ 8 f 8 a UU I D= l 3 e 9.»b 8 d 2 /de v / s cd O

/proc / none /me di a / cd r omO

< t yp e > proc ext4 swap udf , i s o 9 6 6 0

< op t i o n s > de f a u l t s

О

О

e r r o r s = r emo u n t — r o

О

1

sw u s e r , noaut o , e x e c , u t f 8

О О

О О

Первая строка относится к файловой с исте ме / p r o o , которая фа ктически пред­ ставлена драй вером ядра и не и м еет вспомогател ьного за по м и нающего устройства. Устройство p r o c , указан ное в первом столбце , просто зан и м ает м есто. Вторая и третья строки для идентификации томов испол ьзуют идентификаторы раз­ делов ( идентификаторы U U I D, которые мы сократил и , чтобы не сн изить читабел ьность текста), а не имена устройств. Эта систе ма похожа на систему меток U FS , используемую в операционной системе Free B S D , за исключением тоrо, что идентифи каторы представ­ ляют собой дл и н н ые случа й н ы е ч исла вместо те кстовых строк. Испол ьзуйте команду Ыkid для определения U U I D кон кретной файловой с истем ы . Файлов ы м систе мам также можно назначать адм и н истрати в н ы е метк и ; и с п ол ь­ зуйте команды e2 label ил и xfs admin для их чте н и я ил и уста новк и . Есл и вы хотите испол ьзовать метки в файле f s t;-ь (этот подход Я ВЛf1 ется п редпочтител ьн ы м ) , вместо UU I D=длинн ое_ случа йное_ число укажите LАВЕ L=ме тка . Разделы диска О РТ могут и м еть иде нтифи катор U U I D и собствен н ые метки , ко­ тор ые не зависят от U U I D и меток файловых систе м , которые он и содержат. Чтобы использовать эти опции для иде нтифи каци и разделоо в файле f s tab , применя йте па­ раметры PARTUU I D= и PARTLAВEL=. Однако обычная практика, похоже , с водится к ис­ пол ьзованию U U I D файловой системы. 1 6 П редупреждение : табл и цы разделов и ногда назы ваются метками диска . Убедитесь . что при чте ­ н ии документации вы разл и чаете метку отдел ьного раздела и метку самого диска . П ерезапись таб ­ лицы разделов диска потенциал ьно катастрофи чна .

часть 111. Хранение данных

784

В ы также можете идентифицировать устройства по их именам , расположен н ы м в ка­ талоге / dev/di sk. П оддиректори и , такие как / dev/di sk/by-uuid и /dev/di sk/by­ partuuid, автоматически обслуживаются менеджером устройств udev.

Монтирова н ие U S В- накоп ителя Применение устройств USB весьма разнообразно: например, персональные флешки, цифровые фото и видеокамеры , большие внешние диски. Большинство из них поддер­ живается в систем ах семейства U N IX в качестве накопителей дан н ых. В прошлом для управления US В- накопителями приходилос ь прибегать к специ­ альным трюкам . Однако в настоящее время, когда операционные систе м ы реализуют управление динамическими устройствами в кач естве фундаментального требован ия , U S В -накопители представляют собой просто еще оди н тип накопител е й , которые по­ я вляются и исчезают без предупреждения. С точки зрения управления с U S В -накопителями связаны следующие проблемы. •

Ядро должно распознавать устройство и назначать ему файл устройства.

Н еобходимо выяснять, какие назначен ия были сделаны.

Первый этап обычно выпол няется автоматически. После назначения файла устрой­ ства с ним можно выполнять операции , описанные выше в разделе 20.4. Допол нительная информация по динамическому управлению устройствами приведен а в главе 1 1 .

В кл ючение подкач ки Как правило, в качестве области подкачки используются разделы диска ил и логиче­ ские тома, а не структурированные файловые системы. Вместо использования файловой систем ы для слежения за содержим ы м области подкачки , ядро поддерживает собствен­ ное упрощенное отображен ие блоков памяти в блоки области подкачки. В некоторых системах можно выполнять подкачку с помощью файла, находящегося в разделе файловой системы. В старых операционных системах эта конфигурация может ра­ ботать мед.леннее, чем при использовани и специального раздела подкачки, но в некоторых случаях это бывает очень удобным. В любом случае с помощью менеджера логических то­ мов можно решить большинство проблем, по которым вам может понадобиться использо­ вать файл подкачки, а не том подкачки. Чем больше область подкачки, которую вы используете , тем больше виртуальной памя­ ти могут занимать ваши процессы. Максимальная производительность виртуальной памяти достигается , когда область подкачки разделена между несколькими физическими накопите­ лями. Разумеется, лучше всего вооб ще не использовать подкачку; если вам необходимо оп­ тимизировать производительность подкачки, лучше подумайте об увеличении оперативной памяти компьютера. Конкретный размер области подкачки зависит о того, как используется ком пьютер. Н ет ничего плохого в том (кроме потери дисковой памяти) , что будет соз��а н большой раз��ел для подкачки. Но, как правило, размер области подкачки должен составлять половину размера оперативной памяти компьютера и не быть меньше 2 Гбайт. Если система может работать в спящем режиме (как правило, на персональных компью­ терах) , она должна иметь возможность сохранять все содержимое памяти в области под­ качки, кроме сохранения страниц при обычной работе. На этих машинах следует увеличить размер области подкачки, рекомендованный выше, на объем оперативной памяти.

Глава 20. дисковая память

785

Облачн ые и в иртуал изированн ы е экзе м пляры серверов и м е ют свои особен ности в отношении пространства подкачки. Подкачка всегда с нижает их производительность, поэтом у некоторые источники рекомендуют полностью ее исключить; есл и вам н ужно больше памяти , вам нужен больший экзем пляр сервера. С другой стороны , для неболь­ ших экзем пляров серверов обычно н азначаются настолько скудные объе м ы оператив­ ной памяти, что они могут только едва загрузиться без использован ия области подкачки. Поэтому, как правило, следует вьщелять м есто для области подкачк и дл я л юбых экзем­ пляров серверов, если только вы не планируете его использовать для других целей, либо вам не нужно за него платить. Кякой бы подход вы н и выбрал и , проверьте с вои базовые образы, чтобы узнать, как они настроен ы . Н екоторые из них поставля ются с предвари­ тельно настроен ной подкач кой , а некоторые нет. Некоторые экзем пляры Amazon ЕС2 поставляются с локальным хранил ищем экзем­ пляров. Это, по сути, кусок локального жесткого диска на машине, н а которо й запущен гипервизор . Содержимое хран илища экземпляров не сохраняется м ежду сеанса м и ра­ боты . Это пространство входит в цену экземпляра, поэтому вы можете использовать ее для пространства подкачки, если нет ничего другого. В с истемах Linux область подкач ки и н ициализируется с помощью коман­ ды mkswap , которой нужно передать имя устройства в качестве аргуме нта. Команда mkswap записывает некоторую и нформацию в область заголовка раздела подкач ки. Эти дан ные вкл ючают идентификатор U U I D , поэтому раздел ы подкачки считаются файлов ы м и с истемами с точки зрения /etc/ fstaь и могут быть идентифицированы по U U I D . Вы можете вручную включ ить подкачку на конкретном устройстве с помощью коман­ ды swapon устройство. Однако лучше, чтобы эта фун кция выполнялась автоматически во время загрузки. Просто укажите области подкачки в файле fstaЬ и присвойте и м тип swap для файловой системы. Чтобы просмотреть активную конфигурацию системы подкачки, выполните команду swapon -s в системе Linux или swapctl 1 в системе FreeBSD. —

20.1 1 . ФАЙЛОВЫЕ СИСТЕМЫ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ: ZFS и BTRFS Несмотря на т о что Z F S и Btrfs обычно назы ваются файловы м и с истемам и , о н и представля ют собой вертикально и нтегрированные подходы к управл е н и ю хра н ил и ­ щами , которые включают функции диспетчера логических томов и RА I D -контроллера. Хотя текущие версии обеих систем имеют несколько ограничений, большинство из них относятся к категории «еще не реал изован ы » , а не к категории » не могут быть реализо­ ваны по архитектурн ы м прич инам» .

К опирова н ие при зап иси Как ZFS, так и Btrfs избегают перезаписи дан н ых на месте и вместо этого испол ьзу­ ют схему, известную как » копирование при записи». Чтобы обновить блок метаданных, например, файловая система модифици рует его копию в памяти, а затем записывает ее в ранее свободн ый блок диска . Конеч но, этот блок данных, вероятно, и меет роди­ тельский блок, который указывает на него, поэтому родитель также перезаписывается, как и родитель родителя и так далее до самого верхнего уровня файловой системы . ( Н а

786

часть 111. Хранение данных

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

О бнаружение ошибок Файловые с исте м ы ZFS и Btrfs также восприни мают целостность данн ы х гораздо более серьезно, ч е м традицион ные файловые систе м ы . В этих с истемах хранятся кон ­ трольные сумм ы дл я каждого дискового блока, и в н и х проверяются все прочитанные блоки, чтобы убедиться, что получ е н ы корректные дан ные. В пулах хранения , которые поддерживают зеркалирова н ие или контроль по ч етности , испорченные дан ные автома­ тичес ки восстанавл иваются из заведомо хорошей копии. В дисковых накоп ителя х реал изован собстве н н ы й урове н ь обнаружен ия ош ибок и исправления ош ибок, и хотя они довол ьно часто выходят из строя , предполагается , что о н и должны сообщать об ош ибке основному ком пьютеру. Тем не менее они иногда возвращают испорченные дан н ые без указания ошибки. Одно из часто упоминае м ы х э м пирических правил гласит, что на каждые 7 5 Тбайт дан н ы х п риход ится одн а скрытая о ш и б ка . В 2008 г. Байравасундарам и соавтор ы ( Bairavasundaram et al . ) опубликовали резул ьтаты иссл едова ния, в котором они проана­ лизировал и служебные записи более чем на 1 , 5 м иллиона дисков на серверах N etApp и обнаружили , что на 0,5% дисков возникают скрытые ошибки чтения в течение каждо­ го года обслужи ван ия . 1 7 Ч астота ошибок м ал а , но по все м признакам о н а остается примерно постоянной, несмотря на то, что как и емкость дисков, так и объем ы дан ных, хранящихся на дисках, экспоненциально увеличиваются. Вскоре у нас будут такие бол ьш ие диски, что будет невоз­ можно прочитать все содержимое, не избежав скрытой ошибки. Допол нительная проверка, выполняемая файловыми системами ZFS и Btrfs, начинает выглядеть очень важной. 1 8 Контроль по четности в масси вах RA I D не решает эту проблему, по край ней мере в обы чном режи м е . Четность н е может быть проверена без чтения содержи мого всего логического сегмента, а выпол нять чтение всего логического сегмента при каждой дис­ ковой операции неэффективно. Выполнение проверки всего диска ( команда scruЬ) мо­ жет помочь найти скрытые ошибки, но только если они воспроизводимы.

П роизводител ьность Все традиционные файловые систе м ы , которые по-прежнему широко испол ьзуются , имеют схожую производительность. Можно создать рабочие нагрузки , при которых одна файловая система и меет преимущество, н о тесты общего назначен и я редко показывают большую разницу. 1 7 И нтересно отметить, что одн и м из ключевых результатов этого исследован и я было то, что жест­ кие диски корпоративного уровня на порядок меньше подвержен ы эти м ошибкам. 1 8 Связанная, а также н едооцененная проблема — это риск случай н ых ошибок в оперативной па­ мяти . О н и нечастые, но они дей ствительно п роисходят. Все производстве н н ые серверы должн ы использовать ( и контролировать!) память с коррекцией ошибок (error correction code ЕСС) . —

Глава 20. дисковая память

787

Файловые с истем ы с коп ированием при записи несколько отличаются от тради ци­ онных файловых систе м , и и м не хватает десятилетий постепенного совершенствования, которые при вели старые файловые с исте м ы в их текущее состояние. Обычно произво­ дител ьность традицион ных файловых систем выше производительности файловых си­ стем Z FS и Btrfs. Во м ногих тестах ZFS и Btrfs показывают производительность, сравн и мую с тради­ цион н ы м и файловы м и системами. Н о в худшем случае эти файловые с исте м ы могут быть при мерно в два раза медленнее, чем традицион ные. Судя по тестам системы Liпux (единствен ной платформы, на которой возможно прямое сравнение, поскольку файловая система BtJfs предназначена только для Liпux) , BtJfs в на­ стоящее время имеет небольшое преимущество над Z FS. Однако результаты ш ироко варьи­ руются в зависимости от шаблона доступа. Это не редкость, когда одна из этих файловых систем хорошо работает в определенном контрольном тесте, а другая сильно отстает. Анал из производител ьности осложняется тем фактом , что каждая из этих файловых систем «в своем рукаве » и меет н е которые потен циал ь н ые трюки для ее повы ш е н и я . Тесты обычно н е уч итывают эти возможност и . Система Z FS позволяет добавлять кеш и ­ рование S S D в пул хране н и я ; о н а автоматически коп ирует часто сч иты ваем ые дан н ы е в кеш и избегает частого обращения к жестки м дискам . В систе ме Btrfs можно испол ьзо­ вать команду chattr +с, чтобы откл ючить семантику коп ирования при записи для дан ­ ных в определен н ых файлах (обычно бол ьших ил и часто модифицированных), т е м са­ мым обоЙДЯ некоторые типичные неэффекти вные сценарии. Для общего испол ьзования в качестве корневых файловых систем и хранилища до­ маш них каталогов Z FS и BtJfs работают хорошо и предлагают множество полезных пре­ имуществ. Они также могут хорошо работать как хранилище дан н ых для конкретн ых ра­ бочих нагрузок сервера. Однако в этих последн их сценариях стоит потратить н е которое время, чтобы тщател ьно проверить их поведение в конкретной среде.

20. 1 2 . ФАЙЛОВАЯ СИСТЕМА ZFS: ВСЕ ПРОБЛЕМЫ РЕШЕНЫ Система Z FS появилась в 2005 r. к а к ком понент операционной систе м ы OpeпSolaris и быстро вошла в состав систе м ы Solaris 1 О и разл и ч н ых дистрибутивных пакетов, ос ­ нован н ы х на л и цензии B S D . В 2008 г. она уже могла использоваться как корневая фай­ ловая система и с тех пор стала основн ым выбором дл я операционной с исте м ы Solaris. U FS продолжает быть корневой файловой с истемой в операционной систем е Free B S D , н о уже версия Fre e B S D 1 О официал ьно поддержи вает файловую с истему Z FS как оди н из ВОЗМОЖНЫХ вариантов. Система Z FS — не только файловая система со встроен н ы м и функциям и менеджера логических томов и контроллера RA I D . Как первоначально было задумано для операци ­ онной с исте м ы OpeпSolaris, в ней осуществлен всесторо н н и й пересмотр прежнего под­ хода к управлен и ю памятью: от с пособа монтирова н ия файловых с исте м до их экспор­ тирования в другие систе м ы на основе N FS и S M B. Совре м е н н ые с исте м ы B S D и Liпux должн ы учитывать разнообрази е файловых с и ­ стем и поэтому они был и вынужден ы немного отступить о т оригинал ьного уни версал ь­ ного подхода Z FS . Однако Z FS остается тщател ьно спроектирован ной системой , ко­ торая решает довольно много адми н истративных проблем на основе архитектур ы , а не с помощью добавле н и я фун кций.

788

Часть 111. Хранение данных

ZFS в системе Li nux Файловая систе ма Z FS — это бес платное програм м ное обеспече н и е . Е е использо­ вание в с истеме Linux было стимул ировано те м , что ее исходный код защищен лицен­ зией Common Development and Distribution License (C D D L) ком пани и Sun M icrosystems. Организация The Free Software Foundation ( FFS) сохраняет несовместимость лицензии C D D L с л и цензией G N U PuЫ ic License , которая защи щает ядро Linux. Хотя модул ь­ н ые верс и и Z FS для Linux долго были доступны через проект OpenZ FS (open z fs . o r g ) , позиция организаци и FS F препятствовала внедрен и ю файловой систе м ы ZSF в базовые дистрибутивы Linux. После почти десятилетней паузы позиция орган изации FS F была оспорена ком пани­ ей Canonical Ltd . , разработчиком операцион ной с исте м ы Ubuntu. П роведя юридический анализ, ком пан ия Canonical формал ьно оспорила позицию FS F и включила файловую с истем ы Z FS в версию Ubuntu 1 6.04 в форме загружаемого модуля ядра. Пока (середина 20 1 7 г. ) ни оди н судебн ы й процесс н е законч ился . Если ком пания Canonical останется безнаказан ной , файловая система ZFS сможет стать полноценно поддерживаемой кор­ невой файловой системой в операционной системе Ubuntu и другие дистрибутив ы смо­ гут последовать ее примеру. 19

А рхитекту р а ZFS На рис. 2 0 . 3 показаны основные объекты в системе ZFS и их отношения друг с другом . П ул с исте м ы Z FS аналогичен группе томов в других систем ах с механизмами управле ­ ния логическим и томами . Каждый пул состоит из виртуальных устройств, представляю­ щих собой накопители (диски, раздел ы, устройства SAN и так далее), групп ы зеркал или массивов RAI D . Массив ZFS RAI D по существу похож на массив RA I D 5 тем , что в нем используется одно или несколько устройств хранения четности для обеспечения избыточ­ ности массива. Однако в системе ZFS эта схема называется RA I D-Z и в ней используется последовательность логических сегментов переменных размеров, чтобы исключить поя в ­ ление «дырки при записи RAI D 5 » . Все операци и записи в пул хранения распределяются по виртуал ьн ы м устройствам пула, поэтому пул , содержащий только отдельные накопите­ ли, по существу представляет собой схему RAI D О, хотя накоп ител и в этой конфигурации не обязаны иметь одинаковые объемы. К сожал е н и ю , текущая версия масс и ва Z F S RA I D и меет н едостатк и . Напр и м е р , в н е й невозможно н и добавить новые устройства в массив после того, как он б ы л опре­ делен , н и удалить устройство ZFS. Как и в большинстве реал изаций масси ва RA I D , на­ копители в нем должн ы иметь оди наковые объе м ы ; вы можете заставить систему ZFS принять накопители переменных объемов, но общий размер масси ва будет определяться по наимен ьшему объем у накопителя. Для того чтобы эффективно использовать диски пере м е н н ых объемов в сочетани и со схемой Z FS RAID, необходимо заранее разбить ди­ ски н а разделы и определить оставшиеся области в качестве отдельных устройств. Большая часть работы по настройке систе м ы Z FS и управлению ею выполн яется по­ средством двух команд: zpool и z f s . Команда zpool испол ьзуется для создания пулов хране н и я и управления и м и , а команда zfs предназначена для создания сущносте й , возникших и з пула, в основном файловых систем и томов, используемых в качестве об­ ласти подкачки , хра н ил и щ баз дан н ых, и поддержки томов SAN . 1 9 И стория ZFS — и нтерес н ы й случай, когда лицензия G PL акти вно препятствует разработке паке­ та програм много обеспечения с открыты м исходн ы м кодом и блокирует его п р и н ятие п ол ьзовате­ лями и дистрибьюторами. Если вас и нтересуют юридические данные, почитайте новости Ричарда Фонтаны ( Richard Fontana) за 20 1 6 r. на сайте goo . gl / PC 9 i 3 t .

Глава 20. дисковая память

789

Пулы памяти Файловые системы, области подкачки, база данных Виртуальные устройства Массивы RAID-Z

Массивы RAID 1 (зеркала) Разделы

ZFS

Накопители Рис. 20.З. Архитектура файловой системы Zf’S

Пример : добавлен ие диска П режде чем погрузиться в детал и систе м ы Z FS , расс мотр и м н ебол ьшой п р и м е р . Допустим , что м ы добавил и н о в ы й д и с к в систе му Free B S D и он получ ил и м я / dev/ ada l . (Для того чтобы определ ить требуе мое устройство, следует в ы пол н ить команду geom disk list.) На первом этапе необходимо создать на этом диске новый пул хране н и я . $ sudo zpool create demo adal

На втором этапе . . . Ну, на самом дел е второго эта па нет. С истема Z F S создает пул demo, корневую файловую с истему внутри этого пула и м онти рует эту файловую с исте ­ му как каталог /demo за оди н эта п . Файловая систе ма будет с монтирована автоматиче­ ски при загрузке систе м ы . $ ls

/demo

Пример был бы е ще более впечатляющи м , есл и бы мы могл и просто доба н ить но­ вый диск в существующий пул хранения корне вого диска, которы й по умолчан и ю на­ зы вается z root. (Эта команда могла б ы выглядеть так: sudo zpool add zroot ada l . ) К сожалению, корневой пул может содержать тол ько одно виртуал ьное устройство. Тем не менее остальные пул ы допускают безболезнен ное расширение.

Файловые системы и свойства Одн им из замечател ьн ых свойств Z FS я вляется то, что она позволяет автоматически создавать файловые с исте м ы по умолчан и ю в новом пуле хран е н и я , причем эти файло­ вые с исте м ы не будут занимать какой-то предопределе н н ы й объе м памяти. Все файло­ вые с исте м ы , существующие в пуле, могут зан и мать доступ ное пулу простра нство. В отл и ч ие от тради цион н ы х файловых систе м , которые не зависят друг от друга , фа йловые систе м ы Z FS явл я ются иерархическим и и могут взаимоде йствовать со свои ­ м и родител ьс к и м и и дочерн и м и файловы м и системами нескол ьки м и способами. Новая файловая система создается с помощью команды zfs create. $ sudo zfs create demo/ new_fs $ zfs l i s t -r demo

Часть 111. Хранение данных

790 NАМЕ demo demo / n e w f s

USED 432К 9 6К

AVA I L 9 4 5G 9 4 5G

REFER 96К 96К

MOUN T P O I N T / demo / demo / n e w f s

Файл -r в команде zfs l i s t означает, что она рекурсивно применяется ко всем до­ черним файловым с истемам. Больш инство остальных подкоманд z f s также понимают флаг -r. Еще более полезно то, что система ZFS автоматически монтирует новую фай­ ловую систему сразу же после ее создания. Для того чтобы и м итировать тради цион н ые файловые с исте м ы , имеющие фик­ с и рован н ы й разме р , к с во йствам файловой систе м ы можно добавить параметры r e s e rv a t i on (объем дисковой памяти, зарезервированн ы й для пула хране н ия и пред­ назначен н ы й для использования файловой с истемой) и quot a . Эта настройка я вляется кл ючевой в управлении системой ZFS и представляет собой определенную смену пара­ дигмы для адми нистраторов, работающих с другим и с истемами . Для примера задади м оба значения равными 1 Гбайт. $ sudo zfs set reservati on=lg demo/new-fs $ sudo zfs set quota=lg demo/new_fs $ zfs l i s t -r demo NАМЕ USED AVA I L REFER MOUN T P O I N T demo l . OOG 944G 96К /demo demo / n e w f s 9 6К 1 0 2 4М 9 6К / d emo / n e w f s —

Новое значение параметра quota отражается в столбце AVA I L для файловой системы /demo/new fs. Значение параметра reservation показано в столбце USED для файло­ _ вой системы / demo . Это объясняется тем , что резерв для файловых систе м , дочерн их по отношению к с истеме / demo, должен быть учтен в ее размере. 20 Оба изменения этих свойств отражаются только в системе учета. Единствен ное изме­ нение, которое действительно касается пула хранения , — это изменение одного или не­ скольких блоков данных при зап иси новых параметров. При этом не запускается ни один процесс, чтобы отформатировать один гигабайт дискового пространства, зарезервирован­ ного для файловой систем ы /demo/new fs. Бол ьш инство операций ZFS, включая соз­ _ дание нового пула хранен ия и новых файловых систем, выпол няется так же легковесно. Используя иерархическую систему управления дисковы м пространство м , можно лег­ ко группировать несколько файловых систе м , чтобы гарантировать, что их общий объем не превысит задан ного порога; нет необходимости задавать этот порог для каждой фай­ ловой с истем ы отдельно. П араметры quota и reservation следует задавать так, чтобы они правильно и м и ­ тировали традиционную файловую систему фиксированного размера. 2 1 Сам п о себе па­ раметр reservation просто гарантирует, что файловая с истема будет иметь достаточно дисковой памяти , чтобы достичь по крайней мере указанного размера. П араметр quota ограни ч ивает размер файловой с исте м ы без гарантии, что она будет и меть этот объем памяти для своего увеличения; другая файловая система может занять все с вободное пространство пула, не оставив места для расширения файловой с исте м ы / demo/new fs. _

20Столбец REFER содержит объем дан н ы х в активной коп и и каждой файловой системы. Файловые системы / demo и / demo/new_f s и меют близкие значен ия RE FER, поскольку обе они пустые, а н е потому что между н и м и существует какая-то связь. 21 П араметры reservation и quota учитывают весь объем дисковой памяти, занимаемый файловой системой , включая пространство, занятое м гновенными копиями. Если вы хотите ограничить раз­ мер только активной копи и файловой системы, следует использовать параметры refreservation и refquota . П рефи кс ref означает «объем дан н ых, на которые ссьшается файловая система» . Именно это значен ие показано в столбце REFER в результатах работы команды z f s list.

Глава 20. дисковая память

791

С другой сторон ы , в реал ьной жизни существует оче н ь мало причин дл я такой на­ стройки файловой систе м ы . Эти свойства следует испол ьзовать тол ько для де монстра­ ции возможностей системы учета памяти в ZFS и чтобы подчеркнуть, что с истема Z FS при н еобходи мости может быть совместимой с тради ционной моделью.

Наследова ние свойств М ногие с войства естествен н ы м образом наследуются дочерними файловыми систе ­ мам и . Например, есл и м ы хотим с монтировать коре н ь пула файловой с исте м ы demo в каталоге / op t / demo , а не / demo , можно просто задать соответствующий парам етр mountpoint. $ sudo zfs set шountpoint=/mnt/ demo dешо $ zfs l i s t -r demo NAME AVAI L MOUNT P O I N T REFER USED l . OOG 96К /mn t / demo 9 4 4G demo /mn t / demo / n e w_ f s 96К demo / n e w_ f s 1 02 4М 96К

$ l s /mnt/deшo new f s

Параметр mountpoint автоматически демонтирует файловые с исте м ы , а изме н е н ие точ ки монтирования вл ияет на дочерние файловые систе м ы предсказуемым и оче вид­ ным образом. Обыч н ые правила, касающиеся файловой с исте м ы , те м не менее, остают­ ся в силе (см . раздел 5 . 2 ) . Для того чтобы увидеть действител ьное значение кон кретного свойства, испол ьзует­ ся команда zfs get, а команда zfs get all выводит список значен и й всех параметров. Столбец SOURCE содержит информацию, объясняющую, почему каждое свойство и меет кон кретное значе ние: слово l o c a l означает, что свойство было задано явно, а дефис что свойство п редназначено тол ько для чтения. Есл и знач е н ие свойства унаследовано от родител ьс кой файловой систе м ы , то в столбце S OURCE будут указан ы детал и того на­ следования. $ zfs get all demo /new_fs NAME demo / n e w f s demo / n e w_ f s demo / n e w f s demo / n e w_ f s demo / n e w_ f s demo / ne w f s demo / n e w f s demo / n e w f s demo / ne w_ f s demo / n e w_ f s demo / ne w f s demo / n e w_ f s

. . .

PROPERTY t yp e creat ion used ava i l aЫ e re f e r e n c e d comp r e s s ra t i o moun t e d qu o t a r e s e rva t i on moun t p o i n t c h e c k s um comp r e s s i o n

VALU E f i l e s y s t em Mon Ap r 0 3 0 : 1 2 2 0 1 7 9 6К 1 0 2 4М 9 6К

S OU RCE

1 . ООх

yes lG lG /mn t / n e w f s оп off —

local local i n h e r i t e d f rom demo de f a u l t de f a u l t

В н и мател ьные читател и могут заметить, что свойства a va i l aЫ e и r e f e r e n c e d по­ дозрител ьно похожи на столбцы AVA I L и RE FER, которые отображаются командой zfs list. Фактически команда zfs l i s t — это просто другой способ отображен ия свойств файловой систе м ы . Есл и бы выше мы привели полный список резул ьтатов, получ е н н ы х с помощью команды zfs get, т о среди них было бы и свойство u s e d . Для того чтобы

Часть 111. Хранение данных

792

указать, какие именно свойства нас интересуют, их можно указать с помощью опции -о команды zfs list. Поскол ьку н ет н икакого с м ысла задавать я в но значе н и я свойств u s e d и дру­ гих свойств, связа н н ы х с объемом , эти свойства предназначаются только мя чте н и я . Если кон кретные правила вычисления значе ния с войства u s e d вас по каким -то п р и ­ ч инам н е устраи вают, возможно , следует испол ьзовать другие с войства, такие как u s edbych i l d r e n и u s edbys n a p s ho t s , чтобы увидеть, как расходуется дисковая память. Для собствен ного испол ьзования и создания локальных сценариев можно задавать допол н ительны е , н естандартные свойства файловых с истем. Процесс их задания ничем не отл ичается от задан и я стандартных свойств. И мена пользовательских с войств долж­ ны содержать двоеточие, чтобы отличать их от стандартных свойств.

Оди н пользовател ь — одна файловая система П оскольку файловые систе м ы не расходуют дисковую память и не требуют м но­ го вре м е н и н а с вое созда н и е , их опти мал ьное кол ичество может быть скорее бл иже к » м ного» , чем к » мало » . Если рабочие каталоги пользователей находятся в пуле хране­ ния с исте м ы ZFS, рекомендуется создать отдельный рабочи й каталог в отдельной фай ­ ловой системе. Существует несколько преимуществ такой схе м ы . •

Если необходимо установить квоты по использованию дискового пространства, то рабочие каталоги пользователей я вля ются естестве н н ы м объектом мя этой цел и . Квоты можно установить к а к мя файловых с истем и ндивидуальных пол ьзовате ­ лей, так и мя файловых систе м , содержащих всех пользователей. М гновенные копи и соответствуют отдельны м файловы м системам. Если каждый рабочий каталог пользователя представляет собой отдельную файловую с истему, то пользователь может получить доступ к старым м гновенным копиям с через каталог � ! . zfs .22 Одно это сэкономит адми н истратору м ного времени, поскольку пользова­ тели смогут самостоятельно обслуживать свои потребности в восстановлении файлов. Система ZFS позволяет делегировать разрешение выпол нять разные операции, та­ кие как поиск м гнове н н ых коп и й и откат систе м ы в предыдущее состоя н и е . При желани и можно передать пол ьзователя м контроль над этим и операция м и , кото­ рые выпол н яются в их собствен н ых каталогах. В этой к н и ге м ы не будем описы­ вать детали м ехан изма управления разрешениями в системе ZFS; их можно найти в справочн ике ZFS Administration Guide, а также на страницах электронной справ­ ки, посвящен ной команде zfs allow.

М гновен н ые копии и клон ы Как и менеджер логических томов, система Z FS обес печивает копирование при за­ писи на пол ьзовательском уровн е , разрешая создавать м гновенные копи и . Однако есть важное отл и ч и е : м гнове н н ы е копи и с истем ы ZFS реал изуются мя файловых с исте м , а не м я логических томов, поэтому о н и и меют произвол ьную глубину детал и зации . М гновен н ую коп и ю можно создать с помощью команды z f s snapshot. Например, следующая последовательность команд илл юстрирует создание м гновен ной копи и , ее 2 2 Этот каталог по умолча н и ю я вляется скрытым ; он не появляется среди резул ьтатов работы ко­ манды ls а Е го можно сделать види м ы м с помощью команды z f s set snapdi r=vi siЫe —

.

ф а йло в а я_ сис т ема .

Глава 20. дисковая память

793

испол ьзование с помощью каталога . zfs/ snapshot и возвращение файловой системы в предыдущее состоян ие . $ sudo touch /mnt/demo/new_fs/now_]lou_see_me $ ls /mnt/demo/new_fs

now you s e e те s�do �fs snapshot demo/new [email protected] snapl sudo rm /mnt/demo/new_fs/n;,w_]lou_see_me ls /mnt/demo/new fs ls /mnt/demo/new::::f s/ . zfs/ snapshot/ snapl now_ you _ s e e _me $ sudo zfs rollback demo/[email protected] snapl $ ls /opt/demo/new_fs now_ you _ s e e _me $ $ $ $

Каждой мгновенной коп и и в момент ее созда н и я можно присвоить и м я . Полная спецификация м гновен ной коп и и обычно записывается в виде ф а йл о в а я_ сис т ема @ мгнов енная копия. Для рекурсивного создания мгновенных копий используется команда zfs snapshot -r. Ее эффект эквивалентен выпол нению команды zfs snapshot Дll Я каждого ООьекта по от­ дел ьности. При этом Дll Я каждого подком понента будет создана собствен ная мгновенная копия. Все мгновенные копии имеют одинаковые имена, но с логической точки зрения они отличаются друг от друга, поскольку их часть файловая_ система будет другой. М гнове н н ые коп ии в с исте ме Z F S предназнач е н ы тол ько дл я чте н и я , несмотря на определ е н н ы е с войства, они все же не я вляются файловы м и системами в подл и н ном см ысле. Однако в ы можете и ници ировать м гнове н н ую копи ю как п ол ноце н ную и до­ пускающую зап ись файловую систему, » клонировав» ее. $ sudo zfs clone demo/[email protected] snapl demo/ suЬclone $ ls /mnt/demo/ suЬclone

now_ you _ s e e _me $ sudo touch /mnt/demo/ suЬclone/and-me-too $ ls /mnt/demo/ suЬclone and_me _ t o o now_ you _ s e e _me

М гнове н ная коп и я , которая стал а оригиналом для клона, остается н етро н утой и предназначается только Д/J Я чте н ия . Однако новая файловая система ( в нашем приме­ ре demo/ suЬclone) сохраняет связь как с мгновенной копией, так и с файловой с исте­ мой, на которой она ос нована, и н и одну из них нел ьзя удалить, пока существует клон . Операция кл онирова н ия применяется относител ьно редко, но это единстве н н ы й способ создать новую ветвь на дереве эволюции файловой систе м ы . Операция z f s rol lback , п роде монстрированная выше, может тол ько восстановить файловую систе ­ м у в состоя н и и , соответствующем самой последней по вре м е н и м гновен ной коп и и . Поэтому перед е е использованием вам нужно будет перманентно удалить ( z fs destroy) все м гнове н н ые коп и и , сделан ные за вре м я , прошедшее после создания м гнове н ной ко­ п и и , к которой хотите вернуться. Клонирование позволяет вам вернуться в прошлое без потери изменений, внесе н н ых недавно. Предположим , в ы обнаружил и дыру в системе безопасности , воз н и кшую в течен ие прошедшей недел и . Для обеспече н ия безопасности вы захотите вернуть файл овую с и ­ сте му в состоя н ие , в котором она находилась недел ю н азад, чтобы б ы т ь уверен н ы м , что о н а не содержит лазеек, оставл е н н ых хакера м и . В то ж е время в ы н е хотите поте­ рять резул ьтаты работы за последнюю недел ю ил и данн ые дл я анал итического отчета. Ре ш е н ием этой проблемы я вляется клон и рование м гновен ной коп и и , сделан ной неде-

Часть 111. Хранение данных

794

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

Неразмеч е нн ы е логич еск ие тома Области подкачк и и неразмече н н ые области для хранения данн ы х создаются с по­ мощью команды zfs areate точно так же, как создаются файловые системы. Аргумент -v ра змер заставляет команду zfs обрабатывать новый объект как неразмечен н ы й ло­ гический том , а не файловую систему. В параметре ра змер может использоваться л юбая известная един ица измерения, например 12 8m. Поскольку том не содержит файловую систему, он не монтируетс я ; вместо этого он появляется в каталоге /dev/ zvol и ссылаться на него можно так, будто он представляет собой жесткий диск ил и раздел . С истема Z FS выполняет зеркальную копи ю иерархиче­ ской структуры пула хранения в этих каталогах, поэтому команда sudo zfs areate -v 1 2 8m demo/ swap создает том подкачки размером 1 28 М байт, размеще н н ы й в каталоге /dev/ zvol/demo/ swap. Мгнове н н ые копи и неразмеченных томов можно создавать точно так же , как м гно­ венные копи и файловых систе м , но поскольку в дан ном случае нет иерархии файловой систе м ы , в которой р азмещаетс я каталог . z f s / snapshot, м гнове н н ы е коп и и оказыва­ ются в том же самом каталоге , что и их исходные тома. Клон ы фун кциони руют точно так же , как ожидается . П о умолчан и ю неразмеченные тома получают резерв дисковой памяти, равны й е го указанному объем у. Можно умен ь ш ить резерв или отказаться от него вообще, но в этом случае попытки записи на том могут вызвать ошибку нехватки памяти. Клиенты нераз­ мече н н ы х томов могут не справиться с обработкой таких ошибок.

Уп равление пулом пам я т и Рассмотрев свойства систе м ы Z F S , относя щиеся к файловой с исте м е и уро в н ю » блок-клиент» , исследуем ее пул ы хранения. До сих пор м ы испол ьзо в ал и пул с именем demo , который создали на отдельном дис­ ке. Команда zpool l i s t отображает следующие результаты. $ zpool list S I Z E ALLOC NАМЕ demo 9 7 6М 5 1 6К z ro o t 1 9 . 9 G 1 6 . З G

FREE 9 7 6G З . бlG

EX PAN D S Z

FRAG 0% 24%

САР 0% 81%

DEDUP 1 . ООх 1 . ООх

HEALT H ONL I N E ONL I N E

ALT ROOT

П ул с и ме н е м z root содержит загружае мую кор невую файловую с исте му. Н а за ­ гружае м ы е пул ы в н астоящее вре м я наложено несколько огран и че н и й : о н и могут со­ держать только одно виртуал ьное устройство , и это устройство должно быть л ибо зер­ кал ь н ы м массивом , либо отдел ьным диском; оно не может состоять из расщепленных логическ и х сегментов и быть массивом RA I D-Z. ( П ока неясно, как это и нтерпретиро­ вать: как предел реал изаци и и л и как знач ител ьное повы ш е н и е надежности корневой файловой с исте м ы . )

Глава 20. дисковая память

795

Команда zpool status добавляет нескол ько деталей о виртуальн ых устройствах, из которых состоит пул хранения , и сообщает об их текуще м состоян и и . $ zpool s tatus demo pool : d emo s t a t e : ONL I N E s c a n : none r e qu e s t ed con f i g : NАМЕ demo ada l

STATE ONL I N E ONL I N E

READ

WRITE

C K S UM

о о

о о

о о

e r r o r s : No known da t a e r r o r s

Остави м пул demo и создадим нечто более сложное . М ы подключил и к нашей систе ­ ме пять накоп ителей ем костью 1 Тбайт. Сначала создадим пул с и м е н е м mon s t e r , со­ держащи й три таких накопителя , в конфигурации RA I D-Z с одни м разрядом контроля четности (siпgle-parity configuration) . $ sudo zpool des troy demo $ sudo zpool create mons ter raidz l adal ada2 $ zfs l i s t mons ter NАМЕ USED AVA I L REFER MOUN T P O I N T mon s t e r 8 7 . 2 К 1 . 84Т 2 9 . ЗК /mon s t e r

аdаЗ

С истема Z F S также распознает схе м ы raidz2 и raidzЗ для конфигурации с двумя и трем я разрядами контроля четности . М и н и м ал ьное количество дисков все гда на еди ­ ницу бол ьш е , ч е м кол ичество битов контроля четности. В дан ном случае оди н из трех накопителей предназначен для контроля четности , поэтому для файловой систе м ы до­ ступно при мерно два терабайта памяти. Для илл юстраци и добавим оставш иеся два накоп ител я , сконфигурирова н н ы х как зеркало. $ sudo zpool add mons ter mirror ada4 adaS

i nva l i d vdev s p e c i f i c a t i on u s e ‘ — f ‘ t o ove r r i de t h e f o l l ow i n g e r r o r s : m i s ma t c h e d r e p l i c a t i on l e v e l : p o o l u s e s r a i d z and new vdev i s mi r r o r $ sudo zpool add -f mons ter mirror ada4 adaS

Команда zpool сначала «споты кается » на этой конфигураци и , потому что эти два виртуал ьных устройства имеют разн ые схем ы избыточ ности. Данная конфигурация ра­ ботает хорошо, поскольку оба виртуальных устройства обладают определенной избыточ ­ ностью. В реальных условиях не следует смешивать виртуальные устройства, обладаю­ щие и не обладающие избыточ ностью, поскол ьку невозможно предсказать, какие блоки на каких устройствах будут находиться ; частичная избыточность здесь бесполезна. $ zpool s tatus mons ter pool : mon s t e r s t a t e : ON L I N E s c a n : none r e que s t e d con f i g : NАМЕ mon s t e r raid z l — 0 ada l ada2

STATE ONL I N E ONL I N E ONL I N E ONL I N E

READ

WRIT E

C K S UM

о о о о

о о о о

о о о о

Часть 111. Хранение данных

796

аdаЗ mi r r o r — 1 ada4 ada5

ONL I N E ONL I NE ONL I N E ONL I NE

о о о о

о о о о

о о о о

e r r o r s : No known d a t a e r r o r s

Систем а Z FS распределяет записи между всем и виртуал ь н ы м и устройствами пула. Как показано в нашем примере, виртуальные устройства не обязательно должны иметь оди наковый размер.23 Однако компоненты внутри избыточной гру п п ы должн ы и м еть одинаковые размеры . Если это условие не вы полняется , то кажд ы й ком понент будет иметь м и н и мальны й размер. При использован ии нескольких простых дисков в п уле хра­ нения важную роль и грает конфигурация RA I D О. Допол н ительн ые в иртуальные устройства можно добавить в п ул в л юбое вре м я . Однако суmествующие дан н ые н е будут перераспределены , чтобы воспользоваться преи ­ муmеством параллелизма. К сожалению, в настоящее время невозможно добавлять допол­ н ительные устройства в суmествующи й массив RAI D или зеркало. И как раз здесь файло­ вая система Btrfs имеет определенн ые преимущества, поскольку она позволяет выполнять все виды реорганизации пулов относительно безболезненно и в автоматическом режиме. С истем а ZFS и меет особенно хорошую реализацию кешировани я по чте н и ю , кото­ рое обеспечивает эффективное использование накопителей S S D . Для того чтобы уста­ новить эту конфигурацию, достаточно просто добавить накопители SS Ds в пул хранения как в иртуальные устройства типа cache . Система кешировани я использует алгоритм адаптивной зам е ны , разработа н н ы й ком пан ией I BM , которы й эффективнее обычного алгоритма кешировани я L R U (least recently used — наиболее давно испол ьзовавшийся). Ей известна частота обращения к блокам и момент вре м е н и , когда они использовались в последний раз, поэтому чте н ие больших файлов не предполагает очистку кеша. Горячее резервирование реал изуется с помощью виртуал ьн ых устройств типа spare. Оди н и тот же диск можно добавлять в нескол ько пулов хране ния ; при этом диск из пула, которы й первый даст сбой , будет заменен резервн ы м .

20. 1 3 . ФАЙЛОВАЯ СИСТЕМЫ BTRFS: ОБЛЕГЧЕННАЯ ВЕРСИЯ ZFS для LINUX П роект файловой систем ы Btrfs компан и и Oracle (аббревиатура » B-tree file system » официально произносится как «butter FS» ( «баттэ эфэс» ) или «better FS» ( «беттэ эфэс) , хотя трудно не думать о «butter face » (» баттэ фейс «24)) стремился повторить м ногие дости­ жения Z FS на платформе Linux в течение долгой паузы , когда разработчикам ZFS пока­ залось, что эта система может быть потеряна для Linux из-за проблем с лицензированием. Хотя файловая система Btrfs по-прежнему активно разрабаты вается , она я вл яется стандартной частью ядра Linux с 2009 г. Она доступна и готова к испол ьзованию прак­ тически во всех Linux-cиcтeмax, а в системе S U S E Enterprise Linux она даже поддержи ­ вается дл я корневой файловой систе м ы . Поскольку кодовая база развивается быстро, вероятно, сейчас лучше избегать использования Btrfs в системах, для которых важна ста­ бильность работы, таки х как Red Hat ; старые верси и Btrfs и меют известные проблемы. 2 3 8 данном п р имере д и с к и и меют оди наковые размер ы , а виртуальные устрой ства н е т ( 2 Тбайт п ротив 1 Тбайт) . 24 » Butter face» на сле н ге означает «девушка с краси вой фи гурой, но некрасивым л и цом » . При­

меч. ред.

Глава 20. дисковая память

797

Btrfs ил и ZFS Поскольку файловые системы Btrfs и ZFS имеют общий технический фундамент, их сравнение, вероятно, неизбежно. Одн ако Btrfs не я вляется клоном Z FS и не п ытается воспроизвести ее архитектуру. Например, тома Btrfs монтируются точно так же , как и в других файловы х с истемах, с помощью команды moun t или указа н и я в файле / e t c / fstaЬ. Хотя тома и подтом а файловой систе м ы Btrfs существуют в общем пространстве и м е н , м ежду н и м и нет и ерархических отношен и й . Чтобы внести изменения в гру п пу подтомов Btrfs, необходимо изменить каждый из н и х по отдельности. Команды Btrfs н е работают рекурсивно, а свойства том а не н аследуются. Это н е упущ е н и е : по м н е н и ю разработчиков, незаче м загружать файловую систему функциям и , которые можно эму­ лировать в сценар и и оболоч ки. С и сте м а Bt rfs отражает это стре мле н и е к простоте разл и ч н ы м и с п особа м и . Например, пул ы памяти Btrfs могут вкл юч ать только одн у группу дисков в одной кон ­ кретной конфигурации ( например , RA I D 5 ) , тогда как пулы Z FS могут включать в себя нескол ько групп дисков, а также кеш ировать диск и , журнал ы регистраци и намере н и й и горячие резервные копи и . К а к обычно бывает в области програ м много обеспече н и я , горячие с поры относи ­ тельно сравнительных достои нств ZFS и Btrfs в основном сосредоточе н ы н а стилисти­ ческих различиях. Однако несколько важн ых разл и ч и й м ежду этим и двумя с истемами поднимаются выше уровня придирок и личных предпочте н и й . •

Файловая система Btrfs является я в н ы м победител е м , когда дело доходит д о изме­ нения конфигурации ваше го оборудован и я ; Z FS даже не пытается соревноваться в этом. Вы можете добавлять или удалять диски в л юбое время или даже изменять тип RAI D , а с истем а Btrfs соответственно п ерераспределяет существующие дан ­ н ые , оставаясь в режиме онлайн . В с истеме Z F S такие изме н е н ия , к а к правило, невозможны без коп ирования данных на внешние носители и их повторной пере­ записи. Даже без испол ьзования функций , требующих большого объем а памяти (напри­ мер, дедупли каци и ) , систем а ZFS лучше всего работает с большим объемом опе­ ративной памяти . Рекомендуемый м и ни мум 2 Гбайт. Это большой объем памя­ ти для виртуального сервера. —

С пособность Z FS кешировать часто считываемые данн ы е н а отдельных кеш и ру­ ющих SSD-дисках я вляется уникальным преимуществом во м ногих с ценариях ис­ пол ьзования, система Btrfs в настоящее время не имеет аналогич н ы х функци й . По состоянию на 20 1 7 r. реализации RАID-массивов с проверкой четности ( RA I D 5 и 6) в файловой системе Btrfs еще не были готовы к использованию в производственной среде. Это не наше мнение; это официал ьное м нение разработчиков и существенный недостаток.

Настрой ка и п реобразова н ие хра нили щ а В этом разделе м ы демонстрируе м нескол ько общих процедур Bt rfs, аналогичн ы х тем , которые показа н ы для ZFS в предыдущих разделах. Сначал а создадим файловую с истему Btrfs для испол ьзования на н аборе из двух жестких дисков объемом в 1 Тбайт, настроен н ых как RAI D 1 (зеркалирование) :

часть 111. Хранение данных

798 $ sudo mkfs . btrfs -L demo -d raidl /dev/ sdЬ /dev/ sdc Labe l : demo UU I D : 16384 N o de s i z e : Sector s i z e : 4096 l . 9 1TiB Fi l e s y s t em s i z e : B l oc k g r oup p r o f i l e s : RA I D l l . O OGiB Data : RA I D l l . O O Gi B Me t adat a : RA I D l 8 . 00MiB System: S S D de t e c t e d : no e x t re f , s ki nn y -me t a d a t a I ncomp a t f e a t u re s : 2 N umЬ e r o f d e v i ce s : Devi c e s : ID S I ZE РАТН 1 9 7 8 . 00GiB / d ev / s db 2 9 7 8 . 0 0GiB /dev / s dc $ sudo mkdir /mnt/demo $ sudo mount LAВEL=demo /mnt/demo

Мы могл и б ы назнач ить и мя для л юбых компонентов устройств в командной строке mount, но проще всего использовать метку demo, которую мы назнач или группе. Команда Ьtrfs filesystem usage показывает, как в данн ы й момент испол ьзуется пространство на этих дисках. $ sudo btrfs filesys tem us age /mnt/demo Ove ra l l : l . 91TiB Device s i z e : 4 . 02GiB D e v i c e a l l oc a te d : l . 91TiB Devi c e u na l l oc a t e d : D e v i c e mi s s i n g : о . оов l . 2 5Mi B Used : 9 7 6 . 9 9GiB F r e e ( e s t imat e d ) : Data ratio : 2 . 00 Me t a d a t a r at i o : 2 . 00 1 6 . 0 0MiB G l o b a l r e s e rve : D a t a , RA I D l : / d ev / s db / d ev / s d c

( mi n : 9 7 6 . 9 9 G i B J

( used : О . О О В )

S i ze : l . O OGiB , U s ed : 5 1 2 . 00KiB l . O OGiB l . O OGiB

Me t a d a t a , RAI D l : S i z e : l . O O G i B , U s ed : l l 2 . 0 0 K i B / d e v/ s db l . O OGiB /dev/ sdc l . O O Gi B S y s t em , RA I D l : S i z e : 8 . 0 0M i B , U s ed : l 6 . 0 0 K i B / d ev / s db 8 . 0 0M i B /dev / s dc 8 . 0 0MiB Unal l oc a t e d : / d ev / s db / d ev / s d c

9 7 5 . 9 9GiB 9 7 5 . 9 9 Gi B

И н тересно отметить н ебол ьш ие начальные объем ы памяти в группе RAI D 1 , выде­ ленные для данных, метаданных и с исте м н ых блоков. Бол ьшая часть дискового про­ странства остается в нераспределенном пуле, который не и меет внутренней структуры . Запро ш е нное зеркал и рован и е н е затрагивает диски в целом , тол ько блоки , которые

Глава 20. Дисковая память

799

на самом деле ис пользуются . Эrо не такая жесткая стр у ктура как политика , которая бу дет реализована на уровне групп блоков. Это разл ичие я вляется ключом к пониманию того, как файловая с и с тем а Btrfs может адаптироваться к изменяющимся требованиям и зам е н е о бо р удова н и я Вот что проис­ ходит, когда мы хран и м некоторые файлы в новой файловой системе, а затем добавляем трети й диск. ,

­

.

$ mkdir /mnt/demo/usr $ cd /usr ; tar cf . 1 $ sudo btrfs device add $ sudo btrfs filesys tem Ove r a l l :

S i z e : 3 . 0 0 Gi B , U s e d : 2 . 9 0 G i B 3 . 0 0GiB 3 . 0 0GiB

Me t a d a t a , RA I D l : S i z e : l . O O Gi B , U s e d : l 4 8 . 9 4 M i B l . O OGiB /dev / s db l . O OGiB /dev / s dc Sys t em , RA I D l : S i z e : 8 . 0 0M i B , U s e d : l б . O O K i B 8 . 0 0M i B /dev / s db /dev/ sdc 8 . 0 0M i B Una l l oc a t e d : /dev / s db / d ev / s dc / d e v / sdd

9 7 3 . 9 9G i B 9 7 3 . 9 9GiB 9 7 8 . 0 0GiB

Н о в ы й д и с к / dev / sdd стал доступ н ы м для пула, н о существующие групп ы бло­ ков остались на своих местах, так как н и в одном из них не испол ьзуется новый диск. Будущие операции выдел е н и я памяти автоматически вос пол ьзуются нов ы м дис ком . При необходимости , мы можем заставить файловую с и сте м у Btrfs равномерно распреде лить данные по всем дискам. ­

$ sudo btrfs balance s tart — — full-balance /mnt/d8lllO S t a r t i n g b a l a n c e wi t hout a n y f i l t e r s . Done , h a d t o r e l o c a t e 5 out o f 5 chun k s

Преобразование между уровнями RA I D также является одной из форм баланс и ровки . Теперь, когда у нас есть три диска, м ы можем конвертировать масси в RAI D 1 в RAI D 5: $ sudo btrfs balance s tart -dconvert=raidS -mconve rt• r a i dS /mnt/ demo Don e , h a d t o r e l o c a t e 5 out o f 5 chun k s

Если бы м ы взглянул и на дан н ы е об испол ьзова н и и во вр емя п реобразова н и я , то увидел и б ы , что груп п ы блоков одновре менно активны и для RA I D , и дл я RA I D 5 . Процедуры удаления диска работают аналогично: систе м а Btrfs постепенно коп ирует все блоки в групп ы , которые не вкл ючают в себя удаляемый д и с к и в конечном итоге да н ных на нем не остается. ,

­

2 5 П одкоманды команды btrfs могут быть сокращен ы до л юбого ун и кал ьного префикса . Напри­ мер , вместо команды btrfs filesys tem us aqe можно ис пол ьзовать ее сокраще н н ы й вариант: btrfs f u. Для ясности м ы испол ьзуем пол н ы й вариант команды .

Часть 111. Хранение данных

800

Тома и подтома М гнове н н ые с н и м к и и квоты я вляются объектами уровня файловой с исте м ы Btrfs, поэтому полезно иметь возможность определять части дерева файлов как разн ые объ­ екты. Систем а Btrfs называет эти части » подтомам и » . Подтом очен ь похож на обыч н ы й каталог файловой систе м ы , и н а самом деле он остается доступн ы м как подкаталог е го родительского тома, как показано ниже . $ sudo btrfs suЬvolume create /mnt/demo / suЬ

C r e a t e subvolume ‘ /mn t / demo / s ub ‘

$ sudo touch /mnt/demo/ suЬ/file_in_a_suЬvolume $ ls /mnt/demo/suЬ

f i l e i n а s u b v o l ume

П одтом а н е монтируются автоматичес к и ; они отображаются здес ь как часть ро­ дительс кого тома. Тем н е менее существует возможность смонтировать подтом неза­ висимо от с воего родителя , указав в командной строке опцию монтирован ия subvol . Например, так. $ mkdir /suЬ

$ sudo mount LAВEL=demo — о suЬvol=/ suЬ / suЬ $ ls /suЬ

f i l e in а s u b vo l ume

Невозможно предотвратить появление подтома в его родительском томе при монтиро­ вании родителя . Чтобы создать иллюзию нескольких независимых, невзаимодействующих томов, просто сделайте их подчиненными корнями и смонтируйте каждый из них отдел ь­ но с опцией suЬvol. Сам корневой каталог не требуется монтировать нигде. Фактически система Btrfs позволяет указать том , отличный от корня, которы й должен быть целевым объектом монтирования по умолчанию, если не запроше н подтом ; см. команду btrfs suЬvolume set-default. Ч тобы увидеть или обработать всю иерархи ю Bt rfs в этой конфигураци и , просто смонтируйте кор е н ь в пустой каталог с помощью команды subvo l = / . Это обы ч н ая практика, которые н ужно монтировать нескол ько раз и которые доступн ы через не­ скол ько путей .

Сн имки тома Версия моментальны х с н и м ков Btrfs работает так же , как и команда ер , за исключе­ нием того, что коп и и являются поверхностны м и и изначально сохраняются в хранил и­ ще родительского тома. $ sudo btrfs suЬvolume snapshot /mnt/demo/ suЬ /mnt/demo/ suЬ_snap

C r e a t e а s n a p s h o t o f ‘ /mnt /demo / s u b ‘

in ‘ /mnt /demo / s ub_s nap ‘

В отл и ч и е от моментальных с н им ков Z F S , моментальные сн и м к и Btrfs доступ н ы для записи по умол чанию. Н а самом деле в файловой с истеме Btrfs н ет такой вещ и , как моментальный с нимок в ч истом виде; моментал ьн ы й с н и мок — это п росто том , кото­ рый совместно использует н екоторое хранилище с другим томом . $ sudo touch /mnt/demo/suЬ/another-file $ ls /mnt/demo/ suЬ

anot h e r f i l e f i l e i n а s ubvo l ume $ ls /mnt/demo/ suЬ_snap

f i l e i n а subvo l ume

Глава 20. дисковая память

801

Для создания неизменяемого моментального с н и м ка просто передайте параметр — r команде btrfs subvo lume snapshot. Система Btrfs н е проводит принципиал ьноrо различия между моментальными с н и м ка м и , доступными только для чте н и я , и записы­ вае м ы м и копи я м и , как это делает с истема Z FS . (В ZFS записывае м ые копи и я вл я ют­ ся клонами . Ч тобы создать такой клон , сначала создается с н имок тол ько дл я чте н и я , а затем клон н а основе этоrо моментального с н и м ка . ) Система Btrfs н е применяет ка­ кие-либо кон кретные соrлашения об именах или местоположен и и , коrда дело доходит до определения подтомов и моментал ьн ых с н и м ков , поэтому вам решать, как эти сущ­ ности должны быть организованы и названы . Докуме нтация по файловой с истеме Btrfs на сайте Ь t r f s . w i k i . k e r ne l . o r g предлагает несколько вариантов н а выбор. В с истеме Btrfs также нет операции отката, которая восстанавл ивает состояние том а в соответствии с конкретным моментал ьн ы м с н и м ком . Вместо этого можно п росто пе­ реместить исходный том в другое место, а затем в ыпол н ить команду mv или скопировать снимок на свое место: $ ls /mnt/ demo /suЬ anothe r f i l e f i l e i n а s ubvo l ume $ sudo mv /mnt/demo / suЬ /mnt/demo / suЬ . old $ sudo btrfs suЬvolume snapshot /mnt/demo / suЬ snap /mnt/demo/suЬ C r e a t e а s n a p s hot of ‘ /mn t / demo / s ub_s nap ‘ i n 7 /mn t / demo / s ub ‘ $ ls /mnt/demo / suЬ f i l e i n а s ubvolume —

Обратите в нимание на то, что это изме н е н ие мешает прямому монтированию под­ тома. После этого е го нужно будет перемонтировать.

П оверхностные коп и и Аналогия м ежду моментал ьн ы м и с н и м ка м и Btrfs и командой ер бол ьш е , чем про­ сто совпаден и е . Н е возможно создавать моментал ьн ые с н и м ки в чистом виде для фай ­ лов ил и каталогов, которые не я вляются кор н ями подтома. Н о , что и нтересно, м ожно создавать поверхностные коп и и произвольных файлов и каталогов с помощью ком анды ер — — reflink , даже пересекая границы подтома. Эта опция активизирует специфичн ы й для систе м ы Btrfs механизм команды ер , ко­ торая напрямую связывается с файловой системой , чтобы орган изовать дубл ирован ие записи с коп ированием. Ее семантика иде нтична семантике обычной команды ер и так­ же оче н ь напом инает семантику моментал ьного с н и мка. С истема Btrfs не отслеживает поверхностные копи и автоматически, как это было бы с моментал ьн ы м и с н и м ками, и , следовательно, н е гарантирует идеальную согласован ­ ность по вре м е н и активно изменяемых иерархи й каталогов. Однако в остал ьном две операции заметно похожи. Одна приятная особенность поверхностных коп и й заключа­ ется в том , что они не требуют специальных разре ш е н и й ; ими может воспол ьзоваться любой пользовател ь. Если вы укажете параметр команды ер в форме — — refl ink=auto, команда ер при возможности выпол н ит поверхностное копирован ие, а в противном случае будет вести себя как обычно. Это делает ее заманчивой целью для псевдонима в файле � / . bashre: a l i a s ср= » ср — — r e f l i n k=au t o «

Часть 111. Хранение данных

802

20. 1 4. СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ДАННЫХ В благополучных условиях основной задачей управления дисковой памятью я вляет­ ся обеспеч е н ие хорошей производительности и достаточного с вободного п ространства. К сожал е н и ю , такие условия выпол н я ются не всегда. По исследованиям Google Labs, у диска меньше 75% шансов выжить в течение пяти лет, поэтому всегда создавайте с и ­ сте м ы для защиты ценных дан ных от катастрофических потерь и будьте готовы акти ви­ зировать процедуру восстановления данных в кратчай шие сроки. Массивы RAI D и другие схемы репл и кации дан ных защищают от сбоя одного объекта и.1 и части оборудования. Однако есть м ного других вариантов потерять данные, которые эти технологии не предотвращают. Н апример, если у вас возн икло нарушение систе м ы безопасности ил и произошло заражение с помощью вредоносного программного обеспе­ чения, ваши дан н ые могут быть изменены или поврежде н ы , даже если физический уро­ вень остается совершенно неповрежде н н ы м . Автоматическая репл икация скомпромети ­ рованных данных на несколько дисков ил и сайтов тол ько усилит ваш и страдания . Вам нужны надежные резервные копии критических дан н ых, которые можно испол ьзовать в качестве резервного варианта. В последние десятилетия популярны м м етодом хранения автоном н ых резервн ых ко­ п и й бьm и такие носители , как магн итн ые ленты. Однако емкость этих носителей оказа­ лась нес пособной идти в ногу с экспоненциал ьно растущи м и размерами жестких дис ­ ков и твердотел ьных накопителей. Н аряду с физическими проблемам и транспортировки и хранения лент и поддержания в рабочем состоян и и капризн ых механ ических ленточ ­ н ы х накопителей, проблемы с объемом в конечном итоге оттесн ил и ле нточные нос ите ­ ли до статуса 3 5 — м иллиметровой пленоч ной фотокамер ы : она по-прежнему формал ьно находится на рынке , но вы должны задаться вопросом , кто на самом деле ее покупает. Сегодня бол ьш инство облач н ых платформ позволя ют создавать м гновенные резерв­ ные копии в виде с н и м ков, обычно в автоматическом режиме. Внося ежемесячную пла­ ту за память, зан и маем ую каждым с н и мком, вы можете устанавл ивать с вои собствен н ые правила хранения. Н езависимо от конкретной технологи и , которую вы испол ьзуете для реализации ре­ зервных копи й , вам н ужен письме н н ы й план , которы й отвечает хотя бы на следующие вопросы . Общая стратеrия •

Какие дан ные необходимо скопировать?

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

Где будут хран иться дан ные резервного копирования?

Будут ли заш ифрова н ы резервные копи и ? Есл и да, где будут хран иться кл ючи ш ифрован ия? Скол ько будет стоить хранение резервных коп ий с течением времени?

Хронологическая стратеmя • •

Как часто будут выполняться резервные копи и? Как часто будут проверяться резервн ые копи и и выпол няться их тест по восста­ новлению дан ных? Как долго будут сохраняться резервные коп ии?

Глава 20. дисковая память

803

П ерсонал • •

• •

Кто будет и меть доступ к дан н ы м резервного копирования? Кто будет и м еть доступ к кл ючам ш и фрова н ия , которые за щищают дан н ые ре­ зервного копирования? Кто будет отвечать за проверку выпол не н ия резервных коп ий? Кто будет отвечать за подтвержде ние факта резервного коп ирования и и х тести­ рования?

И с пол ьзование и за щита •

Как можно получ ить доступ к резервным дан н ы м или восстановить их в чрезвы­ чайной ситуации? Как убедиться , что н и хакер, ни вредонос н ы й процесс не могуr повредить, изме­ н ить или удалить резервн ые копии? ( Как обеспечить неизмен ность дан н ых’!) Как защитить резервные данные от захвата конкур ирующим провайдером облака, поставщиком оборудования или правител ьством?

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

20. 1 5 . ЛИТЕРАТУРА •

L 11 cдs М rсндн. W. , AN D ALLAN J u oE. FreeBSD Mastery: ZFS. lilted Windmill Press, 20 1 5.

J u DE , ALLAN , AN D М rсндЕL W. Lucдs. FreeBSD Mastery: Advanced ZFS. lilted Windmill Press, 20 1 6.

,

Две упомянутые в ы ш е к н и ги — совре м е н н ые справоч н и ки по Z F S . Хотя о н и и ориентированы на специфику систе м ы Free B S D , большинство материалов от­ носится также к Z FS в системе Linux. Книга Advanced ZFS особенно полезна осве­ щением таких разнообразных тем , как механизм Jail, делегирование пол номоч и й , стратегии кеш ирования и анализ производительности. •

Lucдs, M rcHAEL W. , AND ALLAN J u DE. FreeBSD Mastery: Storage Essentials. lilted Windmill Press, 20 1 5.

M c KtJ s r c к , MдRSHALL K r R к , G EORG E У. №v1 L L E- № 1 L , AN D Roв E RT N . М . WдтsoN . The Design and lmplementation о/ the FreeBSD Operating System (2nd Edition) . Upper Saddle Rive r, NJ: Addison-Wesley Professional , 20 1 4 . В этой к н и ге рассматри ваются разл и ч н ы е те м ы , связа н н ы е с ядро м , но в н их содержатся также пол н ы е главы о U FS , ZFS и уровне YFS.

Глава

21

Сетевая ф айловая система NFS

П ротокол сете вой файловой систе м ы ( Network File System , или N FS), позволя ет пользователям совместно работать с файлами, расположенными на разных ком пьютерах. П ротокол N FS почти прозрачен для пользователей, т.е. при сбое сервера, поддерживаю­ щего протокол N FS , информация не пропадает. Клиенты просто ждут, когда сервер вновь начнет фун кционировать, а затем продолжают работать так, будто н ичего не произошло. Протокол N FS разработала ком пания Sun M icrosystems в 1 984 году. Первоначально протокол N FS был реализован как суррогат файловой систем ы для бездисковых клиентов , однако предложе н н ы й протокол оказался столь удачн ы м , что со временем стал универ­ сальн ым решением п роблемы совместного ис пол ьзования файлов. Все дистрибути вные пакеты систем U N IX и Linux содержат версию протокола N FS ; м ногие из н их используют лицензию компании Sun. В настоящее время протокол N FS является открыты м стандар­ том и описан в документах RFC (см. RFC 1 094, RFC 1 983 и особен но R FC 7530) .

2 1 . 1 . ВВЕДЕНИЕ в ПРОТОКОЛ N F S Цел ь сетевой файловой службы — предоставить общий доступ к файлам и каталогам, которые хранятся на дисках удал е н н ых систе м . Пол ьзовател ьс кие приложен ия должн ы и меть возможность ч итать и записывать эти файл ы с помощью тех же с исте м н ых вы­ зовов, которые о н и испол ьзуют для локал ьных файлов; файл ы , хранящиеся в других местах сети , должн ы быть прозрачн ы м и для приложе н и й . Есл и нескол ько сетевых кли ­ ентов или приложений пытаются одновре менно изме н ить файл , служба совместного до­ ступа к файлам должна разре шать возн икающие конфликты.

часть 111. Хранение данных

806

Кон курен ция N FS не единствен ная система совместного использования файлов. Существует про­ токол Server Message Block ( S M B ) , встроенный в операционные систем ы Windows и macOS и предназначенный для этой же цели. Однако протокол S M B также может испол ьзоваться и в с истемах U NI X и Linux, если запустить допол нительный пакет Samba. Если вы запу­ скаете гибридную сеть, которая включает в себя множество различ ных операционн ых си­ сте м , то можете обнаружить, что протокол S M B обеспечивает наилучшую совместимость. —

m Подробную информацию о протоколе S M B и пакете SamЬa см. в главе 22. Протокол N FS чаще всего используется в средах, где преобладают U N IX и Linux. В этих ситуациях он предлагает несколько более естественную форму исполыования и бо­ лее высокую степень и нтеграции. Но даже в этих условиях протокол SM B остается вполне зако н н ы м вариантом. Для сете й , состоящих исключительно из с истем на основе U N IX и Linux, довольно необычно использовать протокол S M B в качестве основного протокола совместного исполыования файлов ( по крайне мере, мы об этом еще не слы шали!). Совместное использование файлов в сети выглядит простой задачей, но на самом деле она представляет собой сложную проблему, имеющую множество вариантов решения и н ю­ ансов. В качестве свидетельства сложности этой задачи напомн и м , что м ногочисленные ошибки протокола N FS проявились в необычных ситуациях только спустя четверть века ero использования. Современные адми нистраторы могут быть уверены в том, что протоколы совместною испол ьзован ия файлов ( N FS и SMB) не портят данные и не вызывают ярость пол ьзователей , но для того, чтобы этого достичь, пришлось немало потрудиться. Сети хране н и я дан н ы х (storage area network — SAN ) еще оди н вариант в ы ­ сокопро и з водител ьного управл е н и я хра н е н и е м дан н ы х в сети . Серверы S A N н е должн ы поддерживать н и ка к и е файловые систе м ы , пото м у ч т о о н и обрабаты ва­ ют тол ько зап росы на операци и с дисковы м и блока м и . И этим о н и отл и ч аются от протоколов N FS и S M B , которые работают на уровне файловых систем и файл о в , а н е на уровне устройств хранения. SAN обеспечи вает быс трый доступ для чтения и за­ п и с и , но он не м ожет управлять параллельным доступом нескольких клиентов без по­ мощи кластерной файловой с исте м ы . Д л я п роектов с бол ьш и м и дан н ы м и ш и роко испол ьзуются рас предел е н н ы е фай ­ ловые систе м ы с открытым исходны м кодом. G lusterFS и Ceph реал изуют как РОS IХ­ совместим ые файловые с исте м ы , так и хранил и ща объектов RESTfu l , распределен н ы е между кластера м и хостов для повышения отказоустойчивости . Ком мерческие верс и и обеи х систем продаются ком панией R e d Hat, которая приобрела обои х разработчиков. Обе систе м ы представля ют собой готовые к производству, высокопроизводительные файловые систе м ы , заслуживающие рассмотрен ия в таких случаях, как обработка боль­ ших данн ы х и высокопроизводител ьные вычисления. Облачные систе м ы имеют допол нител ьные возможности (см. раздел 9.3). —

П роблемы , связа нные с состоя н ием При разработке файловой с исте м ы необходимо реш ить, какая ее часть будет от­ слежи вать файл ы , открываем ы е кажд ы м кл ие нто м . И н формация об этих файлах на­ зывается состоянием (state) . Сервер , н е фиксирующий состояние файлов и кл ие нтов, называется сервером без сохранения состояния (stateless) , а сервер, которы й решает эту за­ дачу, сервером с сохранением состояния (stateful) . М н огие годы испол ьзовались оба этих подхода, причем каждый из н их имеет как преимущества, так и недостатки . —

Глава 21 . Сетевая файловая система NFS

807

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

П роблемы п роизводител ьности П ол ьзовател ьс к и й и н терфейс сете в ы х файловых с и сте м не должен отл и чаться от пол ьзовател ьс кого и нтерфейса локал ьных файловых систе м. К сожалению, глобал ь­ ные сети имеют бол ьшое время ожидания , что приводит к неправил ьному выпол не н и ю операций и паде н и ю с корости передач и данных. Все это в итоге при водит к с н иже н и ю производител ьности работы с большими файлам и . В большинстве п ротоколов файло­ вых служб , вкл ючая N FS , реализованы методы м и н и м изации потерь в производител ь­ ности как в локальных, так и глобал ьных сетях. В больши нстве протоколов пытаются м и н и м изировать кол и чество зап росов в сети . Например, страте гия упреждающего кеш ирован ия предусматри вает загрузку фрагмен ­ тов файла в локал ьн ы й буфер памяти , чтобы избежать задержки при считывании нового раздела файла. Ч асть полос ы пропускания сети используется для того, чтобы избежать задержки при двухстороннем обмене данными с сервером . Кроме того, в некоторых системах операции записи дан н ых кеш ируются в памяти , и в пакетах посылаются только их обновления, уменьшая тем сам ым задержку, вызва н н ую необходимостью выпол н ить операции записи на сервере. Эти пакетн ые операции обыч ­ н о назы вают объединением запросов (request coalescing).

Безопасность Л юбая служба , предоставля ющая удобн ы й доступ к файлам в сет и , я вляется ис­ точ н и ком серьезн ых угроз для безопасности . Л окальные файловые с исте м ы реал изуют сложн ые ал горитм ы управл ен и я доступом , наделя я пользователе й разн ы м и права м и . В с е т и эти пробл е м ы многократно усложн яютс я , поскольку существуют требован и я , предъя вляемые к быстродействи ю маш и н , а также имеются разл и ч и я между и х конфи­ гурация м и , ошибки в програ м м ном обеспеч е н и и файловых с истем и нере ше н н ые во­ прос ы , связан н ые с протоколами совместного использования файлов. Развитие служб каталогов и централ изован ной аутентификаци и повысило безопас­ ность сетевых файловых систе м . П о существу, н и один кл иент н е может ауте нтифи ц и ­ ровать себя самостоятел ьно, поэтому необходима доверенная централ изованная с исте­ ма, верифицирующая л ич ности и предоставля ющая им доступ к файлам . Больш и нство служб совместного ис пол ьзования файлов могут быть интегрированы с разнообразн ы м и провайдерами аутентификац и и . П ротокол ы совместного испол ьзования файлов обычно не затраrи вают пробл е м ы конфиде нциал ьности и целостности — ил и по край ней мере они н е делают этого н а —

Часть 111. Хранение данных

808

прямую. Как и при аутентификаци и , эта ответствен ность обычно передается на другой уровень, например п ротоколам Kerberos , S S H или УРN -тун нелю. В последн их версиях протокола S M B добавлена поддержка надежного ш ифрования и проверки целостности данных. Одна ко во многих организациях, использующих протокол N FS в защи ще н ной сети , обычно отказы ваются от этих средств, потому что они довольно громоздкие при реал изаци и и замедляют работу сети.

2 1 .2. ОСНОВНЫЕ ИДЕИ, ЛЕЖАЩИЕ В ОСНОВЕ ПРОТОКОЛА N f S Новейшая версия протокола N FS я вляется платформенно-независи мой , обеспечивает высокую производительность в глобальных сетях, таких как И нтернет, а также гарантиру­ ет высокую безопасность. Большинство его реализаций также содержат диагностические средства для решения проблем , связанных с настрой кой и производительностью. N FS это сетевой п ротокол , поэтому теоретически он может быть реал и зован в пользовательс ком пространстве , как и большинство других сетевых служб. Тем н е ме­ нее в рамках традиционного подхода протокол N FS реализован как на сторон е сервера, так и на сторон е кл и е нта, чтобы работать внутри ядра, в основном дл я повышения про­ изводительности. Этот общий ш аблон сохран яется даже в с истеме Linux, где функции блокировки и н екоторы е систе м ные вызовы оказались трудн ы м и для э кспорта в про­ странство пол ьзовател я . К счастью , части ядра N FS н е н уждаются в кон ф и гураци и и в значительной степени прозрач н ы дл я адм инистраторов. N FS не я вляется готовым решением всех проблем совместного доступа к файлам. В ысокая доступ ность может быть достигнута только с помощью » горячего резерва » , но протокол N FS н е и м еет встроен н ых средств синхрони зации с резервным и сервера м и . В неза пное исчезновение сервера N FS из сети может привести к тому, что клиенты будут хранить устаревшие дескрипторы файлов, которые могут быть удалены только при пере ­ загрузке. П р и этом реал изация средств повышенной безопасность возможна, но сли ш ­ ком сложна. Несмотря н а эти н едостатки , протокол N FS остается наиболее распростра­ н е н н ы м выбором для совместного испол ьзования файлов в локальной сети в с истемах U N IX и Linux. —

Версии и история протокола Первая открытая версия протокола N FS, появившаяся в 1 989 году, и мела номер 2 . Ориги нал ьн ы й протокол имел н есколько дорогостоящих компромиссов , отдавая пред­ почтение согласован ности, а не производительности, и быстро был заменен . В н астоя­ щее время эта верси я встречается крайне редко. В верси и 3, появившейся в начале 1 990-х годов, этот недостаток был устранен за счет схемы согласовани я , которая позволяла выполнять запись асинхронно. Были улучшены также другие аспекты п ротокола, связан ные с производительностью и обработкой боль­ ш и х файлов, вследствие чего версия N FS 3 стала работать гораздо быстрее, чем N FS 2 . Версия N FS 4, выпущенная в 2003 r. , но получившая ш ирокое распространение л и ш ь к кон цу этого десятилетия , ямяется резул ьтатом крупной переработки протокола; она содержит м ного усовершенствовани й и новых функциональных возможностей , перечис­ ленных ниже. • •

Совместимость и взаимодействие со всем и брандмауэрами и устройствам и NАТ. И нтегрирование в основном протоколе N FS протоколов блокировки и монтиро­ вания.

Глава 2 1 . Сетевая файловая система NFS

Поддержка операций с сохранением состоя ния.

Высокая интегрирован ная безопасность.

Поддержка репл икации и м и грации.

Поддержка как U N IX- , так и Wiпdоws-клиентов.

Списки управления доступом (AC L) .

809

Поддержка файлов в кодировке U nicode.

Хорошая производител ьность даже при низкой скорости передачи данных по сети.

Разные версии протокола не совместим ы друг с друго м , но на файловых серверах, поддержи вающих п ротокол N FS (вкл ючая все рассмотрен н ы е нами в к н и ге операци­ онные систе м ы ) , обычно реал изованы все три верс и и . Н а практике все кл иенты и сер­ веры протокола N FS могут взаимодействовать с помощью одной из этих верс и й . Если и клиентская , и серверная сторон ы поддержи вают протокол N FS 4, следует ис пол ьзо­ вать и м е н но эту версию. N FS продолжает активно развиваться и широко распространяться . Версия 4.2, напи­ санная некотор ы м и из первоначальных заинтересованных сторон еще во времена рас­ цвета Sun, достигла состоян и я чернового стандарта RFC в начале 20 1 5 r. Служба Elastic File System от AWS , которая стала общедоступной в середине 20 1 6 r., позволяет исполь­ зовать файловые систе м ы N FSv4. 1 в экзем плярах ЕС2 . Хотя версия 4 протокола N FS в о м ногих отноше н иях и я вляется знач ител ьн ы м ша­ гом вперед, в ней не сильно изменен процесс настройки и адм ин истрирования кл иентов и серверов. В некотором смысле это ее особенность; например, до сих пор используются одн и и те же файл ы конфигурации и команды дпя адми н истрирования всех верси й про­ токола N FS. С другой стороны , это проблема; некоторые аспекты п роцесса настройки явно я вля ются и м п ровизацией (особен но в систе м е Free B S D ) , а н екоторые фун кци и оказал ись неоднознач н ы м и ил и перегруже н н ы м и , с разным смыслом или формата м и файлов конфигурации в зависимости о т того, какую версию N F S вы испол ьзуете .

Удален н ый вызов п роцедур Коrда компания Sun разработала первые версии протокола N FS в 1 980-х rr. , ее разра­ ботчики понял и , что многие связан ные с сетью проблем ы , которые необходимо решить с помощью протокола N FS, относятся и к другим сетевым служба м . О н и разработали более общую структуру дпя удал е н ного вызова процедур, известную как R PC ( Re mote Procedure Са\) ил и SunRPC, и построили N FS на ее основе . Эта работа открыла воз­ можности дпя приложений всех в идов запус кать процедуры на удален н ых системах так, как если бы они выпол н ял ись локально. Систе ма RPC от Sun была примитивной и несколько хакерской ; сегодня существуют гораздо более соверше н н ые систе м ы дпя удовл етворения этой потребности. 1 Тем не ме­ нее в протоколе N FS по-прежнему используется технология RPC в стиле Sun в большей части его функционал ьности. Операции , которые читают и записыва ют файлы , монти­ руют файловые систе м ы , получают доступ к метадан н ы м файлов и разреш ают доступ к файлам , все реал изованы как удален н ые вызовы процедур. Спецификация протокола N FS написана в обще м виде , поэтому отдельн ы й урове н ь RPC формал ьно не требуется. Однако нам не известн ы какие-л ибо реализации N FS , которые отклонялись бы от ис­ ходной архитектуры в этом отноше н и и .

1 Как и бесконечно более ужасающие монстры, ч е м SunRPC, например, SOAP.

Часть 111. Хранение данных

81 0

Тра нспортные прото кол ы В верс и и N FS 2 приме нялся протокол U D P, поскол ьку он обеспечивал наилучшую скорость работы в локал ьн ы х сетях 80-х годов. Н есмотря на то что протокол N FS сам вы пол няет сборку пакетоо и осуществляет контрол ь ош ибок, н и в U D P, н и в N FS не реализован ы ал горитмы упрам е н ия перегрузкой, которые необходим ы для достижения хорошей производител ьности о круп ных I Р-сетях. Для решения этих проблем о больш и нстве U N IХ-с истем теперь разрешено испол ьзо­ вать в качестве транспортного протокола в версии N FS 3 как U D P, так и ТС Р, а в верси и N FS 4 — только ТСР. 2 Пероона•1ал ьно эта возможность предназначалась для обеспечения работы N FS в сетях с маршрутизаторам и и в И нтернете . По мере удешевления оператив­ ной памяти и роста производител ьности централ ьных процессоров и сетевых контроме­ ров первоначальное преимущество протокола U D P над протоколом ТС Р испарилось.

Состоя н ие П режде чем начать работать с файловой системой N F S , кл иент должен ее смонтиро­ вать, как есл и бы это была файловая система, находящаяся на локальном диске. Однако в версиях N FS 2 и 3 не сохран яется состоян и е , поэтому сервер не «знает » , какие кл иен­ ты с монтировали ту или и ную файловую систему. В место этого сервер вручает кл иенту секретн ы й кл юч по факту успеш ного завершения операци и монтировани я. Этот кл юч иде нтифици рует каталог монти рован и я на сервере N FS и дает кл и е нту возможность получ ить доступ к содержи мому каталога. Кл юч сохраняется при перезагрузке , чтобы сервер после сбоя смог оернуться в предыдущее состоя ние. Клиент может просто подо­ ждать, пока сервер перезагрузитс я , и повторить свой запрос . С другой стороны , оерсия N FSv4 п редставляет собой протокол с сохранением состо­ я н ия : и кл иент, и сервер хранят информацию об открытых файлах и блокировках. П р и сбое сервера кл иент облегчает процесс восстановления, посылая н а сервер информаци ю о состоянии, предшествующем сбою. Восстанавли вающийся сервер ожидает в течение за­ дан ного периода отсрочки, пока бы вшие клиенты отчитаются о своем предьщущем состо­ я ни и, прежде чем приступ ить к оы полнению новых операций и блокирооок. Управления кл ючами , которое существовало о оерсиях V2 и VЗ , в верси и N S Fv4 бол ьше нет.

Э кспо рт фа йловой сис тем ы Говорят, что сервер «экс портирует » файловую систе му (при этом поддержи вается список экспортируе м ых каталогоо) , есл и он делает ее доступ ной для использования дру­ гими ком п ьютерами. По определ ению, все серверы экспортируют хотя бы оди н каталог. Кл иенты затем могут смонтирооать эти экспортируе м ы е каталоги и внести и х в список файловых с исте м , хранящихся в их файле fstaЬ. W Дополнительную и нформацию о файле fstaЬ см. в разделе 20. 1 О. В версиях 2 и 3 каждый экспортируемый каталог рассматривается как независимая сущ­ ность. В верси и 4 каждый сервер экспортирует одну иерархическую псевдофайловую си­ стему, содержащую все свои экс портируемые каталоги . По существу, псевдофайловая си­ стема это пространство имен файловой системы сервера, из которой удалено все, что не подлежит экспорту. —

2 С формальной точ ки зре н ия можно испол ьзовать л юбой транспортный протокол , реализующий алгоритм управления перегрузкой , но в настоящее время еди нстве н н ы м разумны м выбором явля­ ется протокол ТС Р.

Глава 21 . Сетевая файловая система NFS

81 1

В качестве примера рассмотри м следующий список каталогов, в котором экспорти­ руемые каталоги выделены полужирным шрифтом. /wvw/domainl /wvw/doшain2 / www /doma i n З

/var/loqs /httpd / va r / sp o o l

В верси и N FS 3 каждый экспортируемый каталог должен конфигурироваться отдель­ но. Кл и е нтские системы должн ы выпол н ить три разных запроса на монтирование, что­ бы получить доступ ко всем экспортируе м ы м каталогам сервера. В то же врем я в верси и N FS 4 псевдофайловая с истема соединяет разрозне н н ы е ча­ сти структуры каталогов и создает единое представление для клие нтов N FS . В место за­ проса на монтирование каждого из каталогов /www/domainl , /www/ domain2 и /var/ logs / httpd, клиент может просто смонтировать серве рн ы й псевдокорневой каталог и просмотреть всю иерархи ю. Каталоги / www/domainЗ и /var/ spoo l , н е подл ежащие экспорту, н е появляют­ ся в этой иерархии. Кроме того, отдел ьные файл ы , содержащиеся в каталогах / , /var, /www и /var/ logs , не видны кл иенту, потому что псевдофайловая часть иерархии со­ стоит тол ько из указанных каталогов. Таки м образом, при испол ьзовании верс и и N FSv4 кл иент видит экспортируемую файловую систему в следующем виде.

[

/

var L logs L h t tpd www

t

doma i n l doma i n 2

На сервере коре н ь экспортированных файловых с истем определяется в файле кон ­ фи гурации exports, обычно храня ще мся в каталоге /etc. Обыч ные клиенты N FSv4 не могут п росматривать список точе к монтирования на удален ном сервере. В место этого он и просто монтируют псевдо-корневую файловую систему, а затем все экспортируемые каталоги становятся доступн ы м через эту точ ку монтирования. Так это выглядит с точ ки зре н ия спецификации R FC . Однако на практике ситуация несколько разм ыта. С одной сторон ы , реализация систе м ы Solaris соответствовала этой спецификации . С другой сторон ы , разработч ики операционной с исте м ы Linux сделали половинчатую попытку поддержки псевдофайловой с исте м ы в ран н е м коде N FSv4, но позже переработали ее, чтоб ы пол ностью поддерживать схему; сегодня шняя версия , по­ хоже, уч итывает цел и RFC. Система Free B S D не реализует псевдофайловую с истему, как описано в спецификации R FC. Семантика экспорта FreeB S D по существу такая же, как и в верс и и 3 ; все подкаталоги внутри экспортируе м ых доступн ы для клиентов.

Блокировка файлов Блокировка файлов (реал изуем ая систе м н ы м и вызовами flock, lockf или fcntl ) в течение долгого времени была слабым звеном в системах U N IX. В локальных файло­ вых с истемах этот механизм был воплощен далеко н е идеально. В ран н их версиях про­ токола N FS серверы н е сохранял и состоя н и е : и м н е известно, какие комп ьютеры ра­ ботают с конкретным файлом. Однако эта информация н еобходи ма для испол ьзования блокировок. Что же делать’!

Часть 111. Хранение данных

81 2

Традиционное решение заключается в реализации механизма файловых блокировок отдел ьно от протокола N FS. В бол ьшинстве с истем этой цели служат два демона: lockd и s tatd. К сожал е н и ю , по ряду п р и ч и н он и работают не оптим ал ьно, и блокировка файлов в протоколе N FS оставалась его слабым местом. В верси и N FSv4 демоны lockd и s tatd бол ьш е не испол ьзуются для блокировки в основном протокол е , поскольку серверы сохраняют состояние. Это изменение значи ­ тельно усложн ило протокол , н о устран ило множество пробл е м , характерных для более ран них верс и й п ротокола N FS . К сожал е н и ю , по отдельности демон ы lockd и s ta td все еще нужны для поддержки клиентов, использующих верс и и 2 и 3 . Все рассматривае­ м ы е нами примеры операц ионн ых с истем поставляются с ран н и м и версия м и протокола N FS , поэтому отдельные демоны по-прежнему запускаются по умолчани ю .

В оп росы безопасности Во м ногих аспектах верс и и 2 и 3 протокола N FS были типич н ы м и наследн и ка м и всех недостатков, касающихся вопросов безопасности в с истемах U N I X и Linux. Этот п ротокол изначально не предполагал н и каких мер безопасности, и благодаря этому он был удоб н ы м . Версия N FSv4 устранила дефекты с исте м ы безопасности , которые были присущи предыдущи м верс и я м , обеспечи в сильную поддержку службам безопасности и внедрив более совершенную идентиф и кацию пользователей. Все верс и и протокола N FS не зависят от механ изма, обеспечивающего безопасность работы в сети , и больши нство серверов поддержи вают разные режим ы аутентификации. Некоторые из этих режимов перечислены н иже. • •

AUTH_NONE — без ауте нтифи кации. AUTH_ S Y S — способ управления доступом для пользователей и групп , напоми наю­ щий стиль с истем ы U N IX.

R P C S E C _G S S строгий режим аутентифи каци и , предполагающий целостность и закрытость в дополнение к аутентификации. Традиционно в бол ь ш инстве организаций применяется режим AUT H_S Y S , который испол ьзует идентификаторы групп и пользователей в с истеме U N IX. В этой схеме при запросе к серверу кл иент п росто посылает локал ь н ы й идентификатор пол ьзователя и групп ы . Сервер сравнивает значен и я этих идентификаторов со значе н и я м и из свое ­ го файла /etc/pas swd3 и определяет, следует л и предоставлять доступ дан ному пол ь­ зователю. Так и м образом, если два пользователя имеют оди н аковые идентификаторы на двух разных клиентах, то они получат доступ ко всем файлам друг друга. Более того, пользователи , и м е ющие права адм и н истратора систе м ы , могут с помощью команды su установить л юбой идентификатор пользователя по своему усмотрен и ю ; после этого сер­ вер предоставит и м доступ к соответствующим файлам. Согласование файла pas swd со всем и системами играет очень существенную роль в сре­ дах, использующих режим AUTH_ S Y S . Однако даже это — всего лишь иллюзия безопасно­ сти; л юбой мошеннический хост (ил и Windows-мaшинa) может «аутентифицировать» своих пользователей по своему желанию и тем самым разрушить безопасность протокола N FS. Для того чтобы предотвратить эти п робл е м ы , в бол ь ш и нстве организаци й испол ь­ зуется более надежн ы й механизм идентификац и и , такой как п ротокол Kerberos в со­ четани и со слоем N FS R P S S E C G S S . Эта конфигурация требует от кл иента и сервера совместного участия в работе механизма Kerberos. М еханизм KerЬeros аутентифицирует кл и е нтов централ изованно, тем самым предотвращая возможность самоиде нтифика-

1 Или его экви вале нта в виде сетевой базы дан н ых, такой как N I S ил и L DAP.

Глава 21 . Сетевая файловая система NFS

81 3

ции, описан ной выше. Кроме того, протокол Kerberos обеспечи вает сильное ш ифрова­ ние и гарантирует целостность файлов, передаваемых по сети. Все системы, поддержи­ вающие протокол N FS версии 4, должны реализовать режим R P C S E C G S S , в то же время в версии 3 это требование не я вляется строгим . W Дополнительную информацию о протоколе Kerberos с м . в разделе 27.6.

Протокол N FSv4 использует в качестве транспортного протокола только ТСР и обычно осуществляет связь через порт 2049. Поскольку в протоколе N FSv4 не используются друтие порты , то чтобы открыть для него доступ из вне нужно в брандмауэре открыть доступ к порту 2049 протокола ТС Р. Как и в случае конфигурации всех списков управления досту­ пом , кроме порта, следует указать адреса отправителя и получателя . Если ваша организация не планирует предоставлять услути протокола N FS хостам , расположенным в И нтернете, заблокируйте доступ к нему в брандмауэре или используйте локальный фильтр пакетов. m Дополнительную информацию о брандмауэрах см. в разделе 27 . 8 . Н е рекоме ндуется испол ьзовать файловую службу в глобал ьных сетях с версиями протокола N FSv2 и 3 из-за длительной истории ош ибок в протоколах RPC и отсутствия сильных механ измов безопасности. Адм и н истратор ы серверов N FS версии 3 должн ы блокировать доступ к портам ТСР и U D P 2049 , а также порту 1 1 1 службы portmap. Уч иты вая м н ожество очевидн ых недостатков безопасности режима AU T H_ S Y S , м ы настоятельно рекомендуе м прекратить использование протокола N FSvЗ. Если у вас есть древн ие операцион ные с исте м ы , которые не могут быть обновл е н ы до совместимости с N FSv4, по крайней мере следует применять фил ьтры пакетов для огран ичения сетево­ го подключе ния.

Идентифици рующее отображение в версии 4 Прежде чем приступать к следующему обсужден и ю , должн ы предупредить: м ы счи­ тае м , что все реал изации безопасности AUTH_ SYS более или менее уязвим ы . М ы насто­ ятел ьно рекоме ндуе м ауте нтификацию Kerberos и R P C S E C G S S ; это еди нствен н ы й раз­ ум ны й выбор. Как указывалось в главе 8, операцион ная систе ма U N IX иде нтифицирует пользова­ телей с помощью н абора индивидуал ьных и групповых идентификаторов , записан н ых в локальном файле passwd или админ истративной базе дан н ых. С другой сторон ы , вер­ сия 4 протокола N FS представляет пользователей и груп пы в виде строковых идентифи­ каторов, и меющих вид поль зова тель @ п fs -домен ил и группа @ п fs -домен. И клиенты , и серверы , работающие по протоколу N FS , запускают демон идентифицирующего ото­ бражения (identity mapping daemon ) , которы й преобразовывает значен ия идентификато­ ров пользователе й U N IX в строки, соответствующие приведен ному выше формату. Когда кл иент, испол ьзующий версию 4, выполняет операцию, возвращающую иден­ тификаторы пол ьзовател е й , например команду ls — 1 , вы водящую л исти н г файлов, де мон идентифицирующего отображе н и я испол ьзует свой локал ь н ый файл pas swd для преобразован и я пол ьзовательских и групповых идентификаторов каждого файло­ вого объекта в строку, например b e n @ a dm i n . c om. Затем отображе н ие идентификаторов клиентов выпол няет обратное действие , превращая строку b e n @ a dm i n . com в локальные пользовател ьские и групповые идентификаторы , которые могут совпадать, а могут и н е совпадать с иде нтифи каторами сервера. Если строковое значен ие н е соответствует н и одной локал ьной сущности, используется учетная запись анони м ного пользователя . В этот момент вызов удаленной файловой системы (stat) завершается и возвращает вызвавшей ее команде (в данном случае команде ls) значения пользовательского и груп-

Часть 111. Хранение данных

81 4

пового идентификаторов. Однако, поскольку команда ls бьmа выполнена с флагом 1 она должна вывести на экран текстовые имена, а не ч исла. Итак, команда ls, в свою оче­ редь, переводит идентификаторы обратно в текстовые имена, используя библ иотечные утилиты getpwuid и getgrgid. Эти утилиты еще раз проверяют файл passwd ил и экви­ валентн ую ему базу дан н ых. Какая долгая и запутанная процедура! К сожалению, идентифицирующее отображение используется только при извлечении и записи атрибутов файлов, как правило, о праве владения. Идентифицирующее отобра­ жение не играет никакой роли в процессе аутентификации и управлении доступом. Оно лишь переводит идентификаторы в форму, принятую в протоколе R PC. Иде нтифицирующее отображение может оказаться полезнее , чем базовый протокол N FS , потому что оно по­ зволяет выявлять конфликт между разрешениями на доступ к файлам и реальными раз­ решениями, выданными сервером N FS. В качестве примера рассмотрим следующие команды клиента протокола N FSv4. —

,

[ b e n @ n f s — c l i e nt ] $ id Ьеn u i d= l O O O { b e n ) g i d= l O O O { b e n ) g r ou p s = l O O O ( be n ) [ b e n @ n f s — c l i e nt ] $ i d j ohn u i d= l O l O { j oh n ) g i d = l O l O { j ohn ) g r ou p s = l O l O ( j oh n ) [ be n @ n f s — c l i e nt ] $ ls — ld ben drwx r — x r — x 2 j ohn root

4 0 9 6 Мау 2 7 1 6 : 4 2

[ b e n @ n f s — c l i e n t ] $ touch Ьen/file [ be n @ n f s — c l i e nt ] $ l s — 1 ben/ file — rw- rw- r — — 1 j ohn n f s nobody

О

ben

Ма у 27 1 7 : 0 7

be n / f i l e

М ы видим, что пользователь b e n имеет идентификатор 1 000, а j oh n — 1 0 1 0 . Рабочий каталог Ьеn, экс портированный по протоколу N FS, и меет разрешение 7 7 5 и принадле­ жит пользователю j ohn. Однако пользователь b e n может создать файл в этом каталоге , даже если вывод команды l s — 1 означает, что у него нет прав на запись. Н а сервере пользователь j o h n и меет идентификатор 1 000. П оскольку на клиентском ком пьютере идентификатор пользователя j o h n равен 1 О 1 О, идентифицирующее отобра­ жение выполняет преобразование идентификатора, как описано выше , и в резул ьтате пользователь j ohn оказывается владельцем каталога. Однако демон идентифицирующего отображения не участвует в управлении доступом. П р и создании файла непосредственно н а сервер посылается идентификатор пользователя ben, равны й 1 ООО, которы й и нтерпре­ тируется как идентификатор пользователя j ohn, поэтому права доступа предоставляются Как узнать, какие операц и и используют идентифицирующее отображен ие , а какие нет? Это просто: как только пользовательский или групповой идентификатор испол ь­ зуется в вызовах АР! файловой системы (например, как в s tat или chown), он отобра­ жается . Если пользовательс кие или групповые иде нтификаторы неявно испол ьзуются для управления доступом, они проходят через специальную систему аутентификаци и . По этой причи н е принудительное согласован и е файлов pas swd и л и испол ьзование LDAP важно для пользователе й » безо пасного» режима AUTH_ S Y S . К сожал е н и ю дл я адми н истраторов , демоны идентифицирующего отображен и я н е стандартизован ы , поэтому и х п роцессы конфигурирован ия на разн ы х системах могут быть разны м и. Специфика каждой с истемы описывается в разделе 2 1 . 5 .

Учетн ые за писи root и nobody В общем случае пользователи должн ы иметь одинаковые привилегии в любой системе, к которой они получают доступ. Однако традиционно с истемные адм и нистраторы стара-

Глава 21 . Сетевая файловая система NFS

81 5

ются ограничивать возможности неконтрол ируемого применен ия прав привилегирован­ ного пользователя в файловых системах, смонтирован н ых посредством N FS. По умолча­ нию сервер N FS перехваты вает входящие запросы , посы л аем ые от и мен и пол ьзователя с идентификатором О, и «делает вид», будто они пос ту п а ют от другого пользователя . Этот прием называется » поражен ием в правах » ( «squashing root » ) . Так и м образом учетная за­ пись root не отменяется , но уравнивается в правах с обыч ными учетными запися м и Для этого спе циал ьно определена фиктивная учетн а я запись nobody, чтобы под нее «маскировался » пользовател ь root, работающий на сервере N FS. Тради ц ион но ее иден ­ тифи катор раве н 65534 ( 1 6-разрядное значен и е ч исла — 2 , представл е н ное в допол н и­ тел ьном коде )4• Значения U I D и G I D для пользователя root в файл е exports можно измен ить. С помощью опции a l l_s qu a s h можно заставить с исте м у преобразовать все клие нтс кие иде нтификаторы пользователей в оди наковый серверный идентификатор . В таком случае будут отменен ы все различия между пол ьзователям и и создан вариант открытой файловой систе м ы , доступной всем. Все эти предосторожности преследуют благородну ю цел ь, однако конеч н ы й резул ь­ тат дал е к от идеала. Даже будуч и клиентом N FS , пол ь зова т ел ь root может с помощью команды su » п ри нять облик» л юбого пол ьзователя , так что файл ы н икогда не бывают пол ностью защищен ы . Еди нстве н н ы й эффект от смены иденти ф и каторов заключается в том , что предотвращается доступ к файлам , которые принад11 е жат пол ьзовател ю root и недоступн ы для чте н ия ил и записи остал ьным пол ьзователя м . .

.

П роизводител ьность версии 4 П ротокол N FSv4 был разработан для того, чтобы обесп е ч ить высокую производи­ тел ьность в глобал ьн ых сетях. Большинство глобальных сетей и меет более высокую за­ держку и меньшую с корость передачи дан ных, чем локал ь н ы е сет и . П ротокол N FS дол­ же н был реш ить эти проблемы с помощью следующих усовершенствовани й . •

Процедура протокола R P C под названием COM POUN D вкл ючает нескол ько фа йло­ вых операци й в оди н запрос , сокращая вре мя ожида ния при в ы пол н е н и и м ного­ ч ислен н ых сете вых запросов.

М ехан изм деле гирования поддержи вает ке ш ирова н ие фа й лов на клиентской сто­ роне. Клиенты могут сохранять контроль над локальными коп иям и файлов, вклю­ чая их открытие для записи.

Эти функционал ьн ые возможности являются частью ядра протокола N FS и не требу­ ют специал ьного внимания со сторон ы систем ного администратора.

2 1 .3. (ЕРВЕРНАЯ ЧАСТЬ ПРОТОКОЛА N F S Говорят, что сервер N FS «экспортирует» каталог, когда делает этот каталог доступн ы м д11 я использования другими ком пьютерам и . Экспортиро ва н н ые каталоги п редставляются клиентам N FSv4 как единая иерархия файловой системы через псевдофайловую систему. В верс и и N FSvЗ процесс , испол ьзуе м ы й кл иента м и дл я м он тирован и я фа й л овой с исте м ы , отдел е н от процесса , испол ьзуе мого дл я доступа к фа йлам Эти операци и испол ьзуют отдел ь н ы е протокол ы , а запрос ы обрабаты ваются разн ы м и демонам и : .

4На сервере N FS в системе Red Hat стандартное значение U I D равно -2, тогда как в файле pas swd учетной заnиси n o b o d y nрисвоен идентифи катор 99. Мо жн о оставить все как ест ь но добавить в файл pas swd заnись с идентифи катором -2 ил и задать nараметры anonu i d и anong i d ра вн ым и 99. Это действител ьно все равно! В некоторых системах nр и сутстиует также учет ная заnись nfsnobody . ,

Часть 111. Хранение данных

81 6

mountd дл я запросов на монтирова н и е и nfsd для реал ьной файловой службы . В н екоторых систем ах эти демон ы назы ваются rpc . nfsd и rpc . mountd, поскол ьку основан ы на протоколе RPC, а знач ит, для их запуска н ужен демон portmap. В этой главе для простоты м ы будем пропус кать префикс rpc. В версии N FSv4 демон mountd н е испол ьзуется вообще. Однако, если не все ваш и клиенты используют верс и ю N FSv4, демон mountd следует запустить. На сервере N FS демон ы mountd и nfsd должны запускаться при загрузке с исте м ы и работать на протяжен и и все го времени е е функционирования. И в системе Linux и во FreeBSD эти демоны запускаются автоматически , если служба N FS была активизирована. В протоколе N FS используется единая база дан н ых для управления доступом , кото­ рая определяет, какие файловые систе м ы должн ы быть экспортирова н ы и какие кл и ­ е нты могут и х монтировать. Оперативная копия этой базы дан н ы х обычно хранится в файле хtаЬ, а также во внутренних табли цах ядра. Файл хtаЬ — это бинарн ы й файл . с которым работает демон сервера. Монтирование бинарного файла вручную — неблагодарная задача, поэтому в боль­ ш инстве систем п редполагается, что пользователь должен поддерживать текстовый файл ( как правило, он называется /etc/exports ) , в котором указываются все экспортиру­ е м ы е с исте м н ы е каталоги и права доступа к н и м . С истема считывает этот текстовый файл при загрузке и автоматически создает файл хtаЬ. В бол ьш инстве систем каталог /etc/exports является каноническим с п ис ком, до­ ступным для чтения человеком , в котором перечисляются все экспортируемые каталоги . В системе Linux е го содержимое перечитывается демоном после выполнения команды exportfs -а, а в с истеме Fre e B S D после перезапуска сервера N FS. Следовательно, после в несе н ия и зм е н е н и й в файл / e t c / expo r t s , необходимо в ыпол н ить команду exportfs — а , чтобы измен е н и я вступили в силу в с истеме Linux , или выпол н ить ко­ манду service nfsd re s tart в с истеме FreeB S D . Если вы обслужи ваете кл иентов верс и и 3 в с истем е Free B S D , перезапустите также демон mountd с помощью команды service mountd reload. Протокол N FS работает н а логическом уровне файловой систе м ы . Л юбой каталог можно экспортировать; он не обяза н быть точ кой монтирования или корнем физич е ­ ской файловой с исте м ы . Однако с точк и зрен ия безопасности протокол N FS различает границы между файлов ы м и с истемами и требует, чтобы каждое устройство было смон­ тировано отдельно. Например, на ком пьютере, имеющем отдельны й раздел / chinchim/ u s e r s , можно было бы экспортировать каталог / ch i nchim без экспорта каталога / chinchim/users. Клиентам обычно разрешается монтировать подкаталоги экспортируе м ы х катало­ гов, если это необходимо, хотя протокол этого н е требует. Например, если сервер экс ­ портирует каталог / chimchim/user s , то клиент может смонтировать тол ько каталог /chinchim/users/ j oe и и гнорировать остальную часть каталога users . —

Фа йл exports в системе Lin ux В систе м е Linux файл exports содержит сп исок экспортирова н н ы х ката­ логов в левом столбце и с писок связан н ы х с н и м и параметров в право м . С п исок файловых с истем отделе н о т списка кл и ентов пробелом , и после и м е н и каждого кл и е н та в с кобках стоит с п исок парам етров , разделе н ­ н ых запятым и . Продолжение строки обозначается обратной косой чертой. Например, строка / h ome

* . u s e r s . a dmin . c om ( rw )

1 7 2 . 1 7 . 0 . 0 / 2 4 ( ro )

глава 21 . сетевая Файловая система NFS

81 7

позволяет смонтировать каталог /home ДJIЯ чтения и записи на всех маш и нах в домене u s e r s . a dт i n . сот, и только ДJIЯ чтения н а всех маш инах в сети 1 72 . 1 7 . 0 . 0/24 класса С. Если система в домене u s e r s . a dтi n . сот находится в сети 1 72 . 1 7.0.0/24, ее клиент по­ лучает доступ только ДJIЯ чтения. Действует правило наименьшей привилеги и . Файловые с исте м ы , перечисл е н н ые в файле expo r t s б е з указа н и я кон кретн ы х хосто в , монтируются н а всех ком пьютерах, что я вляется значител ьной бре ш ь ю в с и ­ стем е безопасности . Такую же бре ш ь можно создать, случ а й н о н е п ра в и л ь н о расста в и в пробел ы . Н апример, строка / h ome

* . u s e r s . a drni n . com ( rw )

предоставл яет доступ ДJI Я чте н и я и зап и с и л юбому хосту, з а исключением * . u s e r s . a dтi n . сот, которые по умолчан ию имеют доступ только ДJIЯ чте н ия . Ой! К сожал е н и ю , нет способа указать несколько спецификаци й кл ие нтов для одно­ го н абора параметров. Вы должн ы повторить параметры ДJI Я всех желаем ы х клиентов. В табл . 2 1 . 1 перечисл е н ы т и п ы спецификаций клие н та , которые могут указы ваться в файле exports . Таблица 2 1 . 1 . Спецификации клиента в файле /etc/exports в системе Linux Тип

Синтаксис

Описание

Имя хоста

имя_х о с та

Отдельные хосты

Сетевая группа

@имя_ группы

Сетевые группы NIS ( используется редко )

Шаблонный символ

*и?

Полностью определенные имена доменов ( FQDN )• с шаблонны­ ми символам и , причем символ » * » не соответствует точке

1 Рv4-сеть

iр_ адр ес / ма ска

Спецификаци и в стиле CIDR ( например, 1 28 . 1 38.92. 1 28/25)

I Рvб-сеть

iр_ адре с / ма ска

Адреса J Pvб с системе обозначений CIDR ( 200 1 : db8: :/32)

• FQDN — Fully qualified domain names.

В табл. 2 1 .2 показаны наиболее часто используемые параметры экспорта, используе ­ м ые в системе Linux. Параметр s uЬ t r e e c he c k (установлен по умолчани ю) проверяет, что каждый файл , к которому обращается клиент, находится в экспортированном подкаталоге. Есл и вы от­ ключ ите этот параметр , будет проверен только тот факт, что файл находится в экспор­ тируемой файловой системе. Проверка поддеревьев может вызвать н еожидан ные проб­ лем ы , если запраши ваемы й файл пере именовывается в тот момент, когда он открыт на клиенте . Если вы ожидаете , что такие с итуации будут возникать часто, рассмотрите воз­ можность установить параметр no _ s u Ь t r e e _ c h e c k. Параметр a s yn c предписы вает серверу N FS игнорировать с пецификацию протоко­ ла и отвечать на запросы до их записи на диск. Это может привести к небольшому по­ вышению производительности , но также может привести к повреждению дан н ых, если сервер н еожидан но перезапустится. Значен ие по умолчани ю — это s yn c , т. е . полная синхронизация действий сервера. Параметр rep l i ca s это просто удобная возможность, которая помогает клиентам обнаруживать зеркала, если основной сервер вдруг выходит из строя . Фактическая реп­ ликация файловой с исте м ы должна быть выполнена автономно с помощью какого-то другого м еханизма, например r sync или D R B D (програм м ное обеспечение репл и кации ДJIЯ Linux) . Возможность репликации была добавлена в версию N FSv4. I . _

81 8

Часть 111. Хранение данных

Таблица 2 1 . 2 . Основные параметры экспорта файловых систем в Liпux О пция

Описание

ro

Экспорт только для чтения

rw

Экспорт для чтения и записи (по умолчанию)

rw= список

Экспорт преимущественно для чтения; в списке перечисляются хосты , кото­ рым разрешено монтировать файловую систему для записи; остальные долж­ ны монтировать ее только для чтения

r o o t_ s q u a s h

Отображает ( «поражает в правах») идентификаторы UID О и GID О в значе­ ния, заданные параметрами anonu i d и a n on g i d . Этот параметр задается по умолчанию

пo_ro o t_s qu a s h

Разрешает привилегированный доступ для всех. Опасно!

all_s qu a s h

Отображает все идентификаторы UID и GID в значения, установленные для ано­ нимных пользователей.•

anonui d= xxx

Задает идентификатор UID для удаленных привилегированных пользователей, которых следует лишить привилегий

a n o n g i d= xxx

Задает идентификатор GID для удаленных привилегированных групп пользова­ телей, которых следует лишить привилегий

noacce s s

Блокирует доступ к данному каталогу и подкаталогам (используется при вложенном экспорте)

wde l a y

Откладывает запись в ожидании объединения обновлений

n o_wd e l a y

Немедленно записывает данные на диск

a s ync

Заставляет сервер отвечать на запросы до того , как запись на диск будет вы­ полнена в действительности

n o h i de

Выявляет файловые системы, смонтированные в дереве экспортированных файлов

!1 i d e

s u lJ t r e e che c k

Противоположен по смыслу параметру n oh i de Проверяет, находится ли запрашиваемый файл в экспортированном дереве

n o s ub t r e e c h e c k

Проверяет, относится ли запраш иваемый файл к экспортированной файловой системе

s e c u r e l oc k s

Требует авторизации для всех запросов на блокировку

ins ecure locks

И спользует менее строгие критерии блокировки (поддерживает старых клиентов)

s е с =режим

Задает список методов обеспечения безопасности для экспортируемого каталога. Допускаются значения s y s (аутентификация в системе UNIX), dh ( DES), k r b 5 (аутентификация по протоколу Kerberos) , k r b 5 i (аутентификация и защита целостности по протоколу Kerberos) , k r b 5 p (аутентификация , также защита целостности и конфиденциальности по протоколу Kerberos) и none (анонимный доступ; не рекомендуется )

f s i d= n um

Задает псевдофайловую систему в версии 4 (обычно 0 )

pn f s

Разрешает параллельные расширения N FS в версии V4. 1 для обеспечения пря­ мого доступа клиентов

r е р l i с а s = путь @х о с т

Посылает клиентам список альтернативных сервером для этого экспорта

• Эта

опция пол езна для поддержки персональных компьютеров и других ненадежных однопользовательских хостов.

В ран них версиях реализации протокола N FSv4 в систем е Li nt1x требовалос ь, что­ бы адми н истраторы назначали корень псевдофайловой системы в файле /etc/exports с помощью флага f s i d= O . Этого больше не требуется. Чтобы создать псевдофайловую

Глава 21 . сетевая файловая система NFS

81 9

с истем у, как описано в спецификаци и RFC, просто перечислите э кспортируе м ы е ка­ талоги как обыч но, а из клиента N FSv4 смонтируйте каталог / н а сервере. При этом все подкаталоги , находящиеся н иже точк и монтирования, будут экс портироваться как файловые с исте м ы . Если вы укажете для экспорта опцию f s i d= O , эта файловая с истема и все ее подкаталоги будут экспортирован ы для клиентов У4.

Ф а йл exports в системе FreeBSD В соответствии с давней традицией системы U N IX формат файла exports , ис пользуемый в системе Free B S D , полностью отл ичаетс я от формата Linux. Каждая строка в файле (за исключением строк , начинающихся с # , которые представляют собой комментарии) состоит из трех компонентов: списка ка­ талогов для экспорта, параметров для применения к этому экспорту и набо­ ра хостов, к которы м применяется экспорт. Как и в системе Linux, обратная косая черта означает продолжение строки . / va r / www — r o , a l l d i r s www * . a dmin . c om

Строка, приведенная в ыше, экспортирует каталог /var/www и все е го подкаталоги в режиме только для чтения на все хосты, соответствующие ш аблону www * . a dm i n . c om. Чтобы реал изовать разл и ч н ые варианты монтирова ния для разных клиентов , просто с копируйте эту строку и укажите другие значения. Например, строка / v a r / www — a l l d i r s , s e c = k r b 5 p — n e t wo r k 2 0 0 l : db 8 : : / 3 2

открывает доступ дл я чтения и записи всем хостам в указанной сети 1 Рvб. Для аутенти­ фикации , проверки целостности и обеспечен ия конфиденциал ьности используется про­ токол Kerberos. В системе Free B S D экс портируемые каталоги должны находиться в пределах файло­ вой систе м ы сервера. П р и экспорте н ескол ьких каталогов из одной и той же файловой с исте м ы для одного и того же набора клиентских хостов, они должны быть перечислены в одной и той же строке. Например, /va r /wwwl / v a r /www2 — r o , a l l d i r s www* . a dmi n . com

О шибка возн икнет, если указать www l и www2 в разн ых строках, но для одинакового набора хостов, если при этом каталоги www l и www2 находятся в одной и той же файло­ вой системе. Чтобы подключить N FSv4, перед именем корня необходимо поставить префикс V4 : , например, V 4 : / e xp o r t s — s e c = k rb 5p , k r b 5 i , k rb 5 , s y s -n e t wo r k * . a dmi n . c om

Допус кается только один корневой путь У4. Однако он может быть указан несколько раз с разл и ч н ы м и вариантами для разн ых клиентов. Корен ь может появляться в л юбом м есте файла exports. Строка, содержащая префикс v 4 : , фактически не экспортирует н и какие файловые с истемы. Она просто выбирает базовый каталог для N FSv4-клиентов для монтирования. Чтобы активировать ее, укажите экспортируемые каталоги в корневом каталоге: / e xp o r t s / www — n e t wo r k * . admi n . c om

Несмотря на то что для корня указана верси я У4, сервер N FS в с истем е Free B S D не реализует псевдофайловую систем у, как оп исано в спецификации RFC. Когда назнача­ ется корень У4 и под эти м корнем существует по крайней мере оди н экспортируе м ы й каталог, клиент У4 может смонтировать корневой каталог и получ ить доступ к о все м

Часть 111. Хранение данных

820

файлам и каталогам внутри него независи мо от их опций экспортирован ия. На справоч­ ной стран и це exports ( 5 ) эта и нформация изложена неясно, и такая двусмыслен н ость может быть весьма опасной . Не назначайте локальную корн е вую файловую систему сер­ вера (/) в качестве корня У4; в противном случае вся корневая файловая система серве­ ра будет доступна для кл иентов . П р и нал и ч и и корн я У4 , для кли ентов У 2 и У З должн ы б ы т ь указан ы други е п ут и для монтирован ия файлов, которые отл ичаются о т т е х , что ис пол ьзуют клиенты У4. Например , рассмотрим следующий фрагмент экспортируемых каталогов: / e xp o r t s /www — n e t wo r k 1 0 . 0 . 0 . 0 -ma s k 2 5 5 . 2 5 5 . 2 5 5 . О V 4 : / e x po r t s — n e t wo r k 1 0 . О . О . О — ma s k 2 5 5 . 2 5 5 . 2 5 5 . О

Здесь клиенты У2 или УЗ в сети 1 0.0.0 .0/24 могут с монтировать каталог /exports /www. Однако так как каталог / expo rts принадлежит корн е вой псевдофайловой с исте м е , клиент У4 должен монтировать экспортируе м ы й каталог как /www . В качестве альтер­ нативы клиент У4 может смонтировать каталог / и обращаться к каталогу www под этой точкой монтирования. Для обеспечения максимальной производител ьности при экспорте на большое коли­ чество клиентов используйте сетевые диапазоны. Для протокола 1 Pv4 можно испол ьзо­ вать форму записи C I DR или маску подсети . Для протокола I Pvб необходимо использо­ вать C I D R; опция -ma s k не разрешена. Например: / v a r / www — n e t wo r k 1 0 . 0 . 0 . О -ma s k 2 5 5 . 2 5 5 . 2 5 5 . О / v a r /www — n e t wo r k 1 0 . 0 . 0 . 0 / 2 4 / va r / www — n e t wo r k 2 0 0 1 : db 8 : : / 3 2

В с истеме Free B S D меньш е опций для экспорта каталогов, чем в Linux. Их варианты перечислены в табл . 2 1 . З . Таблица 2 1 . 3 . Основные варианты экспорта в системе FreeBSD Вариант

Описание

alldirs

Позволяет монтировать разделы в любой точке файловой системы

ro

Экспорт только для чтения (чтение-запись по умолчанию)

о

Синоним для ro; экспортировать только для чтения

map r o o t = xxx

И мя пользователя или идентификатор UID для отображения удаленного пользова­ теля r o o t

map a l l = xxx

Отображает все х пользователей клиента на указанного пользователя ( например,

map r o o t ) s е с=режим

Задает допустимые режимы безопасности•

• Укажите несколько вариантов режимов безопасности в списке, разделенном запятыми, в порядке предпочтения. Возможными значениями являются s ys (аутентификация U N IX, значение по ум олч ан и ю ) , krb5 ( ауте н тификаци я Kerberos) , k r b 5 i (аутентификация и проверка целостности Kerberos) , k r b 5 p (аутентификация Kerber·os, проверка целостности и обеспечение конфиденциальности) и none (анонимный доступ, не рекомендуется).

Демон nfsd: о бс лужива ние файлов После того как демон mountd убедился в правил ьности клиентского запроса на мон ­ тирован и е , кл иенту разрешается запраш ивать разл ич н ые операции н ад файлам и . Эти запросы обрабатываются на сервере демоном nfsd5• Он не должен в ыпол н яться на ком ; д емон nfsd всего л и ш ь выпол н яет не п редусматривающий возврата с исте м н ы й вызов сервера N FS, код которого встроен в ядро.

Глава 21 . Сетевая файловая система NFS

821

л ьютере — кл ие нте N FS . Еди нствен ное исключение — когда клиент сам экспортирует файловые системы. У де мона nfsd не предусмотрен файл конфи гураци и . Все е го параметры указы ва­ ются в командной строке. Для запуска и остановки сервера nfsd следует использовать стандартн ые с исте м н ы е процедуры . В системе Linux, где запущен демон sys temd, ис­ пользуется команда systemctl , а в Free B S D — команда service. В табл . 2 1 .4 указан ы систе м н ые файлы и параметры, подлежащие изменению, если нужно изменить аргум е н ­ ты , передаваемые демону nfsd. Чтобы изменения в конфигурации демона nfsd вступил и в силу в с истемах семей­ ства Linux, следует выпол н ить команду sys temctl re s tart nf s — config . service n f s — s erver . servi ce . В с истеме Free B S D испол ьзуются команды servi ce n f s d restart и service mountd res tart. Параметр -N команды nfsd откл ючает указанную версию протокола N FS. Н апример, чтобы откл ючить версии протокола 2 и 3 , добавьте в соответствующий файл конфигура­ ци и , указа н н ы й в табл . 2 1 . 4 , опции -N 2 -N З и перезапустите службу. Это хорошая идея, если вы увере н ы , что вам не нужна поддержка старых клие нтов. Таблица 2 1 .4. Системные файлы конфигурации р,ля настройки параметров демона nfsd Система

Файл конфигурации

Параметр

Ubuntu

/etc/defaul t/nfs -kernel — server

Red Hat

/etc/ sysconfiq/nfs

RPCN FS DCOUNт• RPCN FS DARGS

FreeBSD

/ etc/ rc . conf

Параметры командной строки дeмoнa nfsd

• в н екоторых версиях пакета n f s — k e r n e l — s e r v e r неправильно предлагалось измен ить параметр R P CMOUNT D O P T S , чтобы задать некоторые параметры демона nfsd. Не дайте себя обмануть!

Де мону nfsd передается числовой аргумент, определя ющи й , скол ько экзе м пляров самого себя он должен создать посредством с исте м ного вызова fork. П равил ьн ы й вы ­ бор ч исла процессов очень важе н , но, к сожал е н и ю, это из области ч ерной магии. Есл и это ч исло будет сли ш ком мало или сл и ш ком вел и ко, скорость работы сервера N FS мо­ жет с низиться . Опти мальное количество выпол ня ющихся демонов nfsd зависит от операционной систем ы и используемого аппаратного обеспече ния. Есл и вы замечаете , •1то команда ps частен ько стала отображать демон nfsd в состоянии D (непрерьшае м ы й сон ) и при этом наблюдается простой некоторого количества це нтрал ьных процессоров, попробуйте уве ­ личить число потоков. Есл и при добавлении количества демонов nfsd происходит уве­ личение средне й загрузки систе м ы (о чем сообщит команда uptime) , знач ит, вы сли ш ­ ком увлекл ись и следует вернуться к прежнему состоянию. Регулярно запускайте команду nfs s tat, чтобы вовремя рас познать проблемы про­ изводител ьности , которые могут быть связа н ы с количеством потоков nfsd. Более под­ робная информация о команде nfsstat представлена в разделе 2 1 .6 . В системе Fre e B S D параметры -minthreads и -maxthreads команды nfsd обеспеч ивают автоматическое управление количеством потоков в указанных гра н и цах. Для выяснения допол н ител ьных настроек сервера N FS откройте с правоч ную страницу rc . conf в систе ме Free B S D и найдите описание па­ раметров с префиксом n f s .

Часть 1 1 1 . Хранение данных

822

2 1 .4. КлиЕнтскАя чАсть nРотоколА N F S П роцессы монтирования сетевых и локальных фа йловых систем во м ногом схожи . Команда mount пон имает запись вида имя_ хо ста : ка талог как пугь к каталогу, располо­ жен ному на указанном компьютере. Этому каталогу будет поставлен в соответствие ката­ лог локальной файловой системы. По завершении монтирования доступ к сетевой файло­ вой с истеме осуmествляется традиционн ы м и средствам и . Таким образом , команда mount и ее N FS-рас ш ирен ия — самое важное мя системного администратора на N FS-клиенте. Для того чтобы файловую систему N FS можно было монтировать, ее необходимо со­ ответствующим образом экспортировать (об этом рассказывалось в ы ш е ) . Клиентская команда showmount позволяет клиенту проверить, правил ьно ли сервер экс портирует файловые систе м ы . $ showmount — е monk E x p o r t l i s t f o r mon k : / h ome / b e n h a rp . a t ru s t . com

Как следует из этого примера, каталог /home /ben на сервере mo n k экспортирован в клиентскую систему h a r p . a t r a s t . с от. Если сетевая файловая система по какой-то причине не работает, возможно, вы про­ сто забыли в ыпол н ить команду exportfs — а (в с исте м е Linux) л и бо service nfsd restart ил и service mounts reload ( в системе FreeBSD). Проверьте после этого вы­ вод команды showmount. Если каталог был правильно экспортирован на сервере , а команда showmount со­ общает об ош ибке или возвращает пустой с писок, внимательно проверьте , все ли не­ обходимые п роцессы запущены н а сервере (portmap и nfsd, а также mountd, s tatd и lockd мя верси и 3), разрешен л и в файлах hosts . allow и hosts . deny доступ к этим демонам и, вообще , та ли это клиентская система. И нформация о пути , отображаемая командой showmount, например / home/ben, как в п редыдущем случае , я вляется корректной только дл я верси й протокола N FS 2 и 3. Серверы , работающие в рам ках протокола N FS 4, экспортируют целостную и еди­ нообразную псевдофайловую систему. Традицион ная кон цепция протокола N F S , от­ носящаяся к раз н ы м точ кам монтирован и я, в верси и 4 не работает, поэтому команду showmount применять нельзя . К сожалению, достойной альтернативы команде showmount в версии N FS 4 нет. На сервере команда exportfs -v демонстрирует существующие экспортированные файло­ вые систе м ы , но она работает только на в ра м ках локального комп ьютера. Есл и у вас нет пря мого доступа к серверу, смонтируйте коре н ь псевдофайловой систе м ы сервера и пройдите по структуре каталогов вручную. Можно также смонтировать любой из под­ каталогов экс портируе мой файловой с исте м ы . Реальное монтирование сетевой файловой систе м ы для версий 2 и 3 осуществляется примерно такой командой. $ sudo mount

о

rw , hard , intr , bg server : /home/ben /nfs /Ьen

Для того чтобы сделать то же самое в версии 4 под управлением с исте м ы Linux, вы­ пол ните следующую команду. $ sudo mount

rw , hard , intr , Ьq server : / /nfs /Ьen

В данном случае указанные после опции -о флаги говорят о том , что файловая систе­ ма монтируется в режиме чтения-записи (rw), файловые операции разрешается прерывать (intr), а повторные попытки монтирования должны выполняться в фоновом режиме (Ьq). Наиболее распространенные флаги команды mount в системе Linux приведены в табл . 2 1 .5.

глава 21 . сетевая файловая система NFS

823

Таблица 2 1 . 5 . Флаги команды mount в системе Linux

Флаг

Назначение

rw

Монтирование файловой системы для чтения-записи ( она должна экспортироваться сервером в режиме чтения-записи ) ro Монтирование файловой системы только для чтения bg Если смонтировать файловую систему не удается (сервер не отвечает), следует перевести операцию в фоновый режим и продолжить обработку других запросов на монтирование hard Если сервер отключился , операци и , которые пытаются получить к нему доступ, блокируются до тех пор, пока сервер не включится вновь soft Если сервер отключился , операции , которые пытаются получить к нему доступ , завершаются выдачей сообщения об ошибке. Этот флаг полезно устанавливать для того , чтобы предотвратить зависание процессов в случае н еудачного монтирования не очень важных файловых систем intr Позволяет прерывать с клавиатуры заблокированные операции ( будут выдаваться сообщения об ошибке) noint r Не позволяет прерывать с клавиатуры заблокированные операции ret rans=n Указывает, сколько раз нужно повторить запрос, прежде чем будет выдано сообщение об ошибке (для файловых систем , смонтированных с флагом s o f t ) t i me o = n Задает интервал тайм-аута для запросов (в десятых долях секунды) rsi ze=n Задает размер буфера чтения равным п байт ws i z e = n Задает размер буфера записи равным п байт s е с =режим Задает режим безопасности n f s ve r s = n Задает версию протокола N FS р r о t о = про токол Выбирает транспортный протокол; им должен быть протокол tcp для версии NVS 4

Кл ие нтс кая сторон а N FS обы ч н о п ытается автоматически согл асовать подходя ­ щую версию п ротокола. Вы можете указать кон кретную версию, передав параметры — о nfsvers= n . В с исте м е Free B S D команда m o u n t — это оболочка, которая в ы з ы вает кома нду / sЬin/mount_nfs для монтирования N FS . Эта оболоч ка устанавл и вает параметры N FS и осуществляет систе м н ы й вызов nmount. Ч тобы с монтировать файловую систему с с е р ­ вера N FS версии 4 в системе Fre e B S D , выполн ите команду: $ sudo mount -t nfs

nfsv4 server : / /mnt

Если вы явно не укажете версию, оболочка mount автоматически согласует ее в по­ рядке убывания. По сути можно испол ьзовать простую команду mount server : / /mnt, потому что оболочка mount может определить по формату указан н ы х параметров ко­ мандной строки , что файловой системой является N FS. Файловые систе м ы , с монтированные с флагом h a rd (установка по умолчан и ю) , мо­ гут вызы вать зависание процессов при откл юче н и и сервера. Это особе н но неприятно, когда таки ми процессами оказываются стандартные демоны . Вот почему не рекоменду­ ется запускать кл ючевые систе м н ые программы через N FS.6 В общем сл учае испол ь:ю»джефф Форис (JefТ Forys) , оди н из наш их рецензентов, заметил no этому поводу: » Больш инство сете вых файловых систем должно монтироваться с флагами h a rd, i n t r и b g, поскол ьку они шш­ луч ш и м образом соответствуют исходной кон це п ци и N FS (надежн ость и отсутствие и нформ�ш и и о состоя н и и ) . Флаг s o f t — это мерзкий сатани нский трюк! Если пользователь пожелает п рервать операцию монтирова н и я , пусть он сделает это сам. В противном случае следует дождаться включе­ ния сервера. и все в кон це кон цов нормализуется без какой бы то ни было п отери дан н ы х » .

Часть 111. Хранение данных

824

вание флага i n t r позволяет сократить ч исло проблем , связанных с N FS . Исправить не­ которые недостатки монтировани я позволяют средства автоматического монтировани я , например программа autofs (описывается далее) . Размеры буферов чте н и я и зап и с и устанавл и ваются на макс им ально возможном уровне , согласованном с клиентом и сервером. Рекомендуется устанавл ивать их между 1 Ки Б и 1 М и Б . Определить размер доступного дискового пространства на смонтирован ной сетевой файловой системе можно с помощью команды df , как если бы это была обыч ная ло­ кальная файловая система. $ df /nf s /ben

F i l e s y s t em l e op a r d : / h ome / b e n

l k- Ь l o c k s 17212156

Used 1 694128

Ava i l aЫ e 1 4 64 3 692

Use% 11%

Moun t e d on / n f s /ben

Разделы N FS размонтируются командой umount. Если сетевая файловая система кем -то испол ьзуется в момент размонтирования, будет выдано сообщение об ош ибке , показанное н иже. umoun t : / n f s / b e n : dev i c e is bu s � Найдите с помощью команд fuser или lsof процессы , у которых есть открытые фай­ лы в этой файловой системе, и уничтожьте эти процессы л ибо смените текущие каталоги в случае командных оболочек. Если н ичего не помогает или сервер отключен , восполь­ зуйтесь командой umount -f для принудительного размонтирования файловой системы.

М онти рова ние файловых систем N FS на эта пе на чал ьной за грузки С помощью ком анды mount можно создавать лишь временные сетевые точк и мон­ тирования. Файловые с исте м ы , которые я вляются частью постоян ной конфи гураци и , должн ы быть указаны в файле / e tc / f s tab , для того чтобы о н и автоматически мон­ тировались на этапе начальной загрузки . С другой стороны , он и могут обрабатываться утилитой автоматического монтирования, например программой autofs . rn Дополн ительную и нформаци ю о файле fзtаЬ см. в разделе 20. 1 о. Следующие элементы файла fs taЬ предназначены для монтирования файловой си­ сте м ы /home, расположенной на ком пьютере monk. # f i l e s y s t em mon k : / h ome

moun t p o i n t / n f s / h ome

f s t yp e nf s

flags r w , b g , i n t r , h a r d , nodev , no s u i d

dump О

fsck

о

В ы полнив команду mount -а -t nfs , можно сделать так, чтобы изменения вступи ­ л и в силу немедленно (без перезагрузки) . П араметры монтирования файловой с истемы N FS задает поле f l a g s в файле fstab; это те же самые параметр ы , которые н еобходимо указывать в команде mount.

Огра ничения экспорта привилеги рован н ыми портами Клиентам N FS разрешается использовать л юбой ТС Р- ил и U D Р- порт для подкл юче­ ния к серверу N FS. Однако некоторые серверы могут требовать, чтобы запросы поступа­ л и из привилегированного порта ( номер которого м е н ьше 1 024). Другие серверы позво­ ляют выбирать порт по своему усмотрению. Впрочем , применение привилегирован ных портов не приводит к реальному повышению безопасности системы. 7Устройство занято .

Глава 2 1 . Сетевая файловая система NFS

825

Тем н е менее бол ьш и нство кл и ентов протокола N FS следуют традиционному ( и по­ прежне му рекомендуе мому) подходу: по умолчан и ю выбирается привил е гирова н н ы й порт, что позволяет избежать ненужных конфликтов. Для того чтобы разреш ить запросы на монтирование, поступающие из непривилегированных портов, в с истеме Linux мож­ но использовать параметр i n s e c u r e .

2 1 .5. ИДЕНТИФИЦИРУЮЩЕЕ ОТОБРАЖЕНИЕ в ПРОТОКОЛЕ NFS 4 Ранее м ы уже изложил и общие иде и , касающиеся идентифи цирующе го отображе­ ния в п ротоколе N FSv4. В этом разделе мы обсудим адми нистративные аспекты демона идентифицирующего отображения. Все систе м ы , участвующие в работе систе м ы по протоколу N FSv4, должн ы и меть оди наковые домены N FS . В большинстве случаев в качестве домена N FS целесообразно испол ьзовать свой домен DN S . Например, естественно выбрать a dтi n . с от в качестве домена N FS дr1я сервера u l s ah . a dтi n . сот. Клиенты в поддоменах ( например, boo k s . a dт i n . с от) могут при желан и и испол ьзовать тот же самы й домен ( например, adтi n . сот) дr1я реал изации взаимодействия в рамках протокола N FS . К сожал е н и ю дr1я адм и н истраторов, ста ндартной реал и зации отображения иденти­ фи каторов U 1 D в п ротоколе N FSv4 н е существует. В табл . 2 1 .6 перечисл е н ы дем о н ы иде нтифицирующего отображе ния в каждой из с истем и указано м естонахожден и е и х конфигурационного файла. Таблица 2 1 . 6 . Демоны идентифицирующего отображения и их конфигурации Система

Демон

Файл конфигурации

Справочная страница

Linux

/ usr / sЬin/rpc . idmapd

/etc/ idmapid . conf

nfsidmap ( 5 )

FreeBSD

/usr / sЬin/nfsuserd

n f s u s e rd_ f l a g s в файле

idmap ( 8 )

/etc/rc . conf Кроме указания доменов N FS, дr1я реал изации идентифицирующего отображен и я необходима допол н ительная помощь системного адми нистратора. Демон запускается в момент загрузки системы в том же самом сценарии , который упрамяет системой N FS. После внесения изменения в файл конфигурации необходимо вновь перезапустить демон . Параметры , определяющие, например, детал изаци ю вывода в систе м н ы й журнал и аль­ тернативное упрамен ие анон имной учетной записью, обычно являются доступными.

2 1 .6. КОМАНДА NFSSTAT: ОТОБРАЖЕНИЕ СТАТИСТИКИ N FS Команда nfs s ta t отображает разл и ч н ы е статистические дан н ы е , накапл и вае м ы е в системе N FS . Ком анда nfs s tat — s вьщает статистику процессов сервера N FS , а ко­ манда nfs s tat -с отображает и нформацию, касающуюся кл ие нтских операци й . П о умолчан и ю команда nfs stat отображает статистику дr1я всех версий протокола N FS. $ nfsstat — с C l i e n t rpc : c a l l s badc a l l s 64235 1595 C l i e nt n f s :

ret rans

о

badxid 3

t ime ou t 1 5 92

wa i t

n ew s c r e d

о

о

t ime r s 886

Часть 111. Хранение данных

826 call s

Ьadc a l l s

nclget

62 6 1 3

3

null 0% write

getattr

setattr

34%

0%

wrcache 0% r e addr

create

3% mkdi r 0%

6%

62 6 4 3

о �. rmdi r о�

n s l s l e ep

о readl ink 21% r emove 0% fsstat 0%

l o o kup 30% rename 0%

root 0% link 0%

read 2% s yml i n k 0%

П р иведен н ы е резул ьтаты получены н а нормально фун кцион ирующем сервере N FS . Если более 3 % в ы зовов терпят неудачу, т о это говорит о н ал и ч и и п роблем на N F S ­ cepвepe или в сети. Как правило, прич ину можно выясн ить, проверив значение пара­ м етра b a d x i d . Есл и е го знач е н и е близко к нулю, а количество тай м — аутов больше 3 % , т о пакеты , поступающие на сервер и отправляемые с него, теряются в сети. Реш ить эту проблему можно, уме н ьш и в значе н ие параметров монтирования r s i z e и w s i z e (разме ­ р ы блоков для чтения и записи). Если знач е н и е параметра b a d x i d такое же бол ьшое , как и знач е н и е параметра t ime o u t , то сервер отвечает, но слишком медленно. В этом случае необходимо либо за­ мен ить сервер, либо увеличить параметр t imeo при монтирован и и . Регулярное в ы полнение команд nfs s tat и netstat и анализ выдаваемой и м и и н ­ формации помогут адми н истратору выявлять возникающие в N FS п роблемы раньш е , чем с н и м и столкнутся пользователи .

2 1 .7. СПЕЦИАЛИЗИРОВАННЫЕ ФАЙЛОВЫЕ СЕРВЕРЫ N FS Б ыстр ы й и надежный файловый сервер — оди н из важнейших элементов вычисл и ­ тельной среды. Конечно, дешевле все го организовать файловый сервер на рабочей стан­ ции, воспол ьзовавшись и м е ющим ися жестким и дисками . Однако это не оптимал ьное решение с точки зре н и я производител ьности и удобства администрирования. Уже м ного лет на рынке предлагаются специализированные файловые серверы N FS . У н и х есть ряд преимуществ п о сравнению с » кустарн ы м и » системам и . •

О н и оптим и зированы на в ыполнение операций с файлами и , как правило , обе­ спечивают н а илуч шую производительность при работе с системой N FS.

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

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

О н и обычно реализуют доступ к файлам для клиентов как UN IX, так и Wi ndows, а иногда даже содержат встроенные веб- , FTP- и S FТ Р-серверы.

Они обладают улуч ш е н н ы м и средствам и резервного копирования и контроля со­ стоян и я , по срав н е н и ю с обычн ы м и U N IХ-системам и .

Одни м и из луч ш их п о нашему мнению явля ются устройства N etApp. Диапазон пред­ ложе н и й — от малых до очен ь крупных систе м , и цены вполне приемле м ы . Компания ЕМС занимает нишу устройств высшего класса. Она выпускает хорош ие продукты , но их цен ы могут испугать кого угодно. В среде AWS служба Elastic File System является масштабируемым сервером N FSv4. 1 , которы й экспортирует фа йл овы е систе м ы в экзем пляры ЕС2. Каждая файловая с истема

Глава 21 . Сетевая файловая система NFS

827

может поддержи вать несколько потоков передач и данных по сети с гигабитной с коро­ стью, в зависимости от размера файловой систе м ы . Допол н ительную и н формацию с м . н а сайте aws . ama z on . com/ e f s .

2 1 .8. АВТОМАТИЧЕСКОЕ МОНТИРОВАНИЕ И ндивидуал ьное монтирование файловых систем посредством упоминания их в фай­ ле /etc/fstaЬ сопряжено в крупных сетях с рядом проблем. Во-первых, ведение файла fs taЬ на нескол ьких сотнях ком п ьютеров — весьма утом ител ьная задача. Каждый из ком пьютеров может отличаться от других и требовать особого подхода. Во- вторых, если файловые с истемы монтируются с множества ком пьютеров, то в случае сбоя всего лишь одного из серверов наступает хаос , так как все команды , п ытающиеся получ ить доступ к точкам монтирования этого сервера, зависают. Реш ить эту проблему можно с помощью де мона автоматического монтирования , ко­ торы й подключает файловые систе м ы , когда к н и м выполняется обращение, и отключает их, когда надобность в н их отпадает. Этот процесс осущестмяется н езаметно для поль­ зователей и позволяет свести к минимуму ч исло активных точек монтирован ия . Демону можно также предоставить список реплицирова н н ых (содержащих иден тичные данные) файловых систе м , чтобы сеть могла фун кцион ировать в случае отказа ос новного сервера. Как п исал Эдвард Томаш Наперала ( Edward Tomasz Napierala) , разработчи к инстру­ мента для автоматического монтирования файловых с истеме в операционной с истеме Free B S D , для решения проблемы требуется сотрудничество нескол ьких связанн ых ча­ стей программ ного обеспечения: •

драйвер autofs — резидентн ы й драйвер файловой систе м ы , который отслежи­ вает запросы на монтирование файловых систе м , приостанамивает вызывающую п ро грамму и вызывает и нструмент автоматического монтирования для монтиро­ ван и я целевой файловой системы перед возвратом упраме н ия вызы вающей про­ грам ме;

де моны au tomountd и autounmountd, которые сч итывают адм и н истрати вную конфигурацию и фактически монтируют или размонтируют файловые систе м ы ;

адм ин истративная утил ита automount.

Обыч но инструмент автоматического монтирования работает прозрачно для пользо­ вателей. Вместо того чтобы зеркально дубли ровать в сети реальную файловую с истему, програм ма автоматического монтирования воссоздает ее иерархию в соответстви и со спецификациям и , указан н ы м и в файле конфигурац и и . Когда пол ьзовател ь ссылается на каталог виртуал ьной файловой с исте м ы с автоматическим монтирова н и е м , послед­ н и й перехватывает эту ссыл ку, монтирует реал ьную файловую с истему, к которой об­ ращается пользовател ь, и передает ссылку дал ьше. На системах, поддерживающих драй­ вер autofs , файловая система N FS монтируется в файловой систем е с автоматическим монтированием в обычном для систе м ы U N IX режиме. Идея автоматического монтирования была предложена компанией Sun . И м еющаяся в Li nux програ м ма автоматического монтирования им итирует работу одноименной ути­ литы компании Sun, хотя реализована независимо и обладает рядом отличительных осо­ бе н ностей. Начиная с версии 1 0. операционная система Free BSD поддерживает новую реал изацию, отказавшись от когда-то ш ироко испол ьзовавшегося демона а втоматиче­ ского монтирования amd.

Часть 111. Хранение данных

828

Разные реал изации програ м м ы automount испол ьзуют три вида файлов конфигу­ раци и , которые н азываются таблицами (maps): таблицы прям ы х назнач е н и й , таблицы косве н ны х назначений и главные таблицы.и Табл ицы пря м ых и кос ве н н ых назначений содержат и нформацию о файловых систе мах, подлежащих автоматическому монтиро­ ванию. В главной табл ице указы ваются табл и цы прямых и косве н н ых назначен и й , ко­ торые должна учесть программа automount. В каждый момент времени может быть ак­ тивной только одн а главная таблица; по умолчани ю главная таблица хран ится в каталоге /etc/auto master в системе Free BS D и /etc/auto . master — в с истеме Linux. В большИ нстве с истем программа automount представляет собой отдельную коман­ ду, которая считывает свои файл ы конфи гурации, настраивает все необходимые для про­ грамм ы autofs параметры и прекращает работу. Действительные ссыл ки на файловые систе м ы , подлежащие автоматическому монтирован ию, обрабатываются (при участии программ ы autofs) други м процессом — де моном automountd. Этот демон выпол няет с вою работу незаметно и не требует допол нительной настройки. В системах Linux этот демон называется automountd, а фун кция настрой­ ки выполняется в сценарии загрузки / e tc/ i n i t . d/ auto f s . Подробная информация об этом приведена н иже . Далее м ы будем называть команду настройки именем automount, а демон автоматичес кого монтирования automountd. —

Если вы изме н ил и главную табли цу ил и одну из таблиц прямых назначени й , на ко­ торую она ссылается, то необходимо заново запустить программу automount, чтобы эти изменения вступили в силу. При использовании параметра v команда automount де­ монстрирует изменения , внесен ные в ее конфигурацию. Для достижения эффекта сухо­ го запуска, которы й позволяет вам анал изировать проблемы конфи гурации и отладки , можно добавить п араметр -L. Кроме того, программа automount (autounmountd в с истеме Free B S D ) и меет ар­ гумент -t, сообщающий, как долго (в секундах) файловая с истема, монтируемая авто­ матическ и , может оставаться неиспользуе мой перед те м , как будет размонтирована. П о умолчан и ю этот параметр равен 3 0 0 с ( 1 0 м и н . ) . Пос кол ьку точ ка монтирован ия N FS , принадлежащая сбойному серверу, может вызвать зависание програм м ы , целесообразно удалять автоматически смонтированные файловые систе м ы , которые больше не испол ь­ зуются . Кроме того, не следует задавать тайм-аут сли ш ком долгим.9 —

Табл и цы косвен ных назна чен ий Эти таблицы испол ьзуются для автоматического монтирования нескол ьких файло­ вых систем в общем каталоге . Однако путь к каталогу задается в главном файл е , а не в самой табл и це. Например , таблица назначений для файловых систем может иметь сле­ дующий вид. users deve l info

h a r p : / h a rp / u s e r s — s o f t h a rp : / h a r p / de v e l — r o h a rp : / h a rp / i n f o

В первом столбце указывается и м я подкаталога , в котором будет смонтирована фай ­ ловая система. В следующих столбцах перечислены опции монтирования и приведен ис»Табли ц ы п ря м ых н азнач е н и й могут поддержи ваться с помощью базы дан н ых N IS или сервером каталогов LDAP, но это сложно. » С другой сторон ы , монтирование файловой системы зани мает определен ное врем я . Систе ма от­ вечает быстрее и плавнее, если файловые системы не монтируются непрерывно.

глава 21 . Сетевая файловая система NFS

829

ходны й путь к файловой системе. В данном примере (файл /etc/auto . harp) програм­ ме automoun t сообщается о том , что она может монтировать каталоги /harp/users, /harp/devel и /harp/ info с ком пьютера harp , при этом каталог info монтируется только для чтения, а каталог devel — в режиме s o f t . В рассматриваемой конфигураци и подкаталоги н а компьютере harp и на локальном компьютере будут идентичн ы м и , хотя это вовсе не обязательно.

Таблицы п рямых назначений В рассматри ваем ы х табли цах указы ваются файловые систе м ы , н е и меющие общего префикса, такие как /usr/ src и / c s / tools. Табли ца прям ы х назнач е н и й (например, /etc / auto . direct), указывающая , что обе эти файловые систе м ы должны монтиро­ ваться автоматически, может выгл ядеть следующим образом. / u s r / s rc /cs/tools

h a rp : / u s r / s r c — ro mon k : / c s / t o o l s

П оскол ьку у этих файловых с истем нет общего родительского каталога, их монтиро­ вание должно реализовываться по отдельности. Эта конфигурация требует дополн итель­ ных расходов, но ее преимуществом является то , что точка монтирования и структура каталогов всегда остаются доступн ы м и таким командам , как l s . Применяя команду l s к каталогу, содержащему таблицы косвенных назначен и й , пользователи могут запутать­ ся , потому что программа automount не показывает подкаталоги , пока не получит до­ ступ к их содержимому ( команда ls не заглядывает внутрь каталогов, с монтированных автоматически , поэтому она не может вызвать их монтирование) .

Главные табли цы Главн ы й файл содержит список табл и ц пря м ы х и косвенных назнач е ни й , которые должна учитывать программа automount. Для каждой таблицы косве н н ых назнач е н ий указывается корневой каталог, используемый для монтирования, определенного в таблице. Главная табл и ца, испол ьзующая таблицы пря м ы х и косвен н ых назначен ий , упомяну­ тых в предыдущих примерах, может выглядеть следующим образом . # Directory / h a rp /-

М ар / e t c / a u t o . h a rp — p r o t o= t cp / e t c / a u t o . di re c t

В первом столбце указы вается и м я локал ьного каталога для табл и ц ы косве н н ы х назнач е н и й ил и специал ь н ы й токе н / для табл и ц ы п ря м ы х назнач е н ий . Во втором столбце указывается файл , в котором должна хран иться таблица. М ожет существовать несколько табли ц разного типа. Если параметр монтирования указы вается в кон це стро­ ки, то он по умолчанию применяется ко всем точ кам монтирования, указан н ы м в таб­ л и це . Адм и н истраторы систе м ы Linux всегда должн ы указывать флаг м онтирован ия — f s t ype=n f s 4 для серверов, испол ьзующих четвертую верси ю протокола NFS. —

В большинстве с истем параметры , задан ные по умолчанию для элементов главной таблицы , не смешиваются с параметрам и , зада н н ы м и для таблиц прямых и косвенных назначений. Если элемент главной табли ц ы имеет свой собственный список параметров, то значения, заданные по умолчанию, и гно­ рируются . Тем не менее в системе Linux эти наборы параметров смешивают­ ся . Если оди н и тот же параметр встречается в двух м естах, то значение эле­ мента главной таблицы заменяет значение, задан ное по умолчанию.

Часть 111. Хранение данных

830

Испол н я емые табл и цы Если файл , содержащий таблицу косвен ных назначен и й , является исполняемым, то он считается сценарие м ( ил и программой ) , динамически генерирующим и нформацию об автоматическом монтировании. Демон не ч итает таблицу в текстовом виде, а запу­ скает файл на выполнение, передавая ему аргумент ( » ключ » ) , где указывается, к какому подкаталогу пользователь пытается получить доступ. Сценарий отвечает за вывод соот­ ветствующей зап ис и таблицы. Если передан н ы й ключ неверен , сценарий завершается, ничего не отображая на экране. Такая методика очень удобна и позволяет компенсировать многочисленные недостат­ ки довольно странной системы конфигурирования программы automounter. По сути, она дает возможность создать един ы й для всей орган изации конфигурационный файл произвольного формата. Можно написать несложный сценарий , декодирующий глобаль­ ные конфигурационн ые парам етры на каждом компьютере. В состав некоторых систем входит удобны й сценарий / etc/ auto . net, которому в качестве ключа передается имя компьютера, а он монтирует все экспортируемые файловые системы этого компьютера. Поскольку автоматические сценарии запускаются динамически по мере необходимо­ сти, нет необходимости распространять главный файл конфигурации после каждого из­ менения или предварител ьно преобразовывать его в формат automounter; Фактически глобальный файл конфигурации может постоян но хран иться на сервере N FS.

В идимость п рограммы automount Когда вы выводите содержимое родительского каталога файловой системы, монтиру­ емой автоматически, этот каталог оказывается пустым независимо от того, сколько там было автоматически смонтировано файловых систем. Файловые системы, смонтирован­ ные автоматически, невозможно просмотреть с помощью графического пользователь­ ского браузера. Рассмотрим пример. $ ls /portal $ ls /portal/photos f l o r i s s an t 1 0 0 3 a r t_c l a s s_2 0 1 0 f r o z en_de a d_guy_Oc t 2 0 0 9 Ы i z z a rd2 0 0 8 boston02 1 1 3 0 g r e envi l l e . 0 2 1 1 2 9

rmnp O З rmnp_ 0 3 0 8 0 6 s t e ambo a t 2 0 0 6

Файловая система photos прекрасно работает и автоматически монтируется в катало­ ге /porta l . Для того чтобы получить к ней доступ , необходимо указать ее полное имя. Однако вывод содержимого каталога /portal не указывает на ее существование. Если бы вы смонтировали эту систему с помощью команды fstaЬ или mount, то она н ичем бы не отличалась от других каталогов и была бы видимой в родительском каталоге . Для того чтобы увидеть файловые с исте м ы , смонтирован ные автоматичес ки , ис­ пользуются символические ссьm ки на точки автоматического монтирован ия . Напри мер, если / automounts /photos это ссьmка на каталог /portal /photos , то команда l s позволяет увидеть среди содержимого каталога / au tomounts, что каталог photos бьи смонтирован автоматически. Ссылки на каталог / authomounts /photos по- прежнему проходЯт через механизм автоматического монтирования и работают правильно. К сожалению, эти символические ссылки требуют сопровождения и могут потерять согласован ность с реальными точками автоматического монтирования, если они перио­ дически не обновляются с помощью некоего сценария. —

Глава 21 . Сетевая файловая система NFS

831

Репл ицированные файловые системы и п р о г р а мм а autom.ount

В некоторых случаях файловая с исте ма, предназн а ч е н на я тол ько для чте н и я , н а п р и ­ мер /usr/ share , может оказаться иде нтичной на нес кольких серверах одновременно. В этом случае м ы м ожем сообщить програм м е automount о н ескольких потен ц и альн ых источн и ках для этой файловой системы. Демон самостоятел ьно вы б ер ет источник фай­ ловой с исте м ы , исходя из того , какой сервер окажется бл ижа й ш и м п о номеру в дан ной сети , по версии протокола N FS , а также по времени ответа на первоначальн ый запрос. Н есмотря на то что програ м ма au tomount не видит файловую с исте м у и не сл е­ дит за ее испол ьзован ием , репл ицирован н ые файло1�ые систе м ы должн ы предназна­ чаться только для чте ния (например, /usr/ share ил и /usr/ local /X1 1 ) . П рограм м а automount не имеет возможности синхрон изировать записи между сервера м и , поэтом у реплицированные файловые систе м ы , предназначен н ые для чте н и я/за п и с и , и м е ют н е ­ бол ьшое практические значен ие . П ри жела нии в ы можете назнач ить свои приоритеты , указав, какая репл и ка должна выбираться первой. П риоритет задается небольшим целым ч ислом , причем , чем больше число, тем н иже приоритет. Н аиболее подходящим я м яется приоритет по умол ча н и ю , который раве н О . Файл auto . direct, оп ределя ющи й файловые с исте м ы /usr/man и / as / tool s как репл ицированные, может выглядеть следующим образом. /us r /man / c s / t oo l s

— r o h a rp : / u s r / s ha r e /man mon k ( l } : / u s r /ma n — r o l e op a r d , mon k : / c s / t o o l s

Обратите внимание на то, что и мена серверов могут указываться вместе , есл и пути к их источникам совпадают. Значение ( 1 ) после имени mon k в первой строке задает при­ оритет сервера по отношению к файловой систем е /usr/man. Отс утствие такого значения после имени harp означает, что этот сервер имеет нея в н ы й приоритет, равн ы й нулю.

А втоматическое монтирова ние (VЗ; все, кр о ме Li n ux) Вм есто переч исле н и я всех возможн ы х монтируе м ых фа йл о в ы х систе м в таблице косвенных ил и пря м ых назначени й , вы м ожете сообщить п рогра м м е automount не­ много информации о правилах именования и предоставить ей во зм ожн ос ть разбираться в них самостоятельно. Главн ы м обстоятельством при этом является тот факт, что демон mountd, применяе м ы й к удален ному серверу, может п о сыла ть запрос ы о том , какие файловые систе м ы были с монтированы на этом сероере . В четвертой верс и и п ротоко­ ла N FS экспорт всегда обозначается символом / , что исключает необходимость в такой фун кционал ьной возмож ности. Существует нескол ько способов «автом атического конфигурирован ия автоматиче­ ского монтирования » . Сам ы й простой из них относится к т и пу мон т и рован и я с флагом — h o s t s . Есл и указать флаг — h o s t s в качестве имени та бл иц ы о фа йл е главной таблицы, то программа automount отобразит файловые систе м ы , экспортирова н н ые на указан­ ные хосты , в задан н ый каталог автоматического монтирования. / n e t — ho s t s — n o s u i d , s o f t

Напри мер, если сервер h a r p экспортировал файловую систему /usr/ share/man, то каталог должен стать доступным для демона автоматического монтирован ия с помощью пути /net/harp/usr / share/man. Реал изация флага — h o s t s не подразум е вает переч исле н и я всех возможн ых хостов, с которых можно экспортировать монтируемую файло1�ую с исте м у ; это просто практи-

часть 111. Хранение данных

832

чески н е возможно. В место этого команда ждет ссылки на имена конкретных подкатало­ гов , а затем монтирует экспортированные системы с указанного хоста. Анал о гичного, но более тонкого эффе кта можно достичь с помощью ш аблон ных сим волов » * » и » & » в таблице косвенных н азначен и й . Кроме того, существует множе­ ство макросов, испол ьзуе м ых в месте с табл и цами и именем текущего хоста, типом ар­ хитектуры и т.д. П одробности можно найти на справочной странице automount( l М ) .

Специфика системы Linux Реали зация програ м м ы automount в с истем е Linux н е м н ого отл ичается от реализации ком па н и и Sun. Ос новн ы е отл и ч и я касаются и м е н команд и файлов. В с истеме Linux automount это демон , которы й на самом деле монтирует и размонтирует удал е н н ы е файловые систе м ы . Он в ы пол н я ­ е т работу, которую демон automountd делает в других с истемах , и обычно не требует запуска вручную. —

По умолча н и ю гла вная табли ца записана в файле /etc/auto . ma s ter. Ее формат и формат табли ц косвенн ых назначе н и й о писан ы выше. Одн ако докуме нтаци ю о них найти трудно. Формат главной табл и ц ы описан на стран ице auto . ma s ter(5) , а фор­ мат таблицы косвенных назнач е н и й — на стран и це auto f s ( 5 ) . Будьте осторожн ы , не перепутайте их со страницей autofs(8), которая документирует команду autofs . ( Как сказано н а одной из справочных стран иц: «Документация оставляет желать лучшего » . ) Для того чтобы изменения вступил и в силу, выпол ните команду /etc/init . d/autofs / reload, я вляющуюся эквивалентом команды automount из систе м ы Solaris. Реализация с истемы Linux не поддерживает принятый в Solaris флаг — ho s t s для «ав­ томатического конфигурирования автоматического монтирования » .

2 1 .9. Л ИТЕРАТУРА Различные спецификации RFC, касающиеся с истем ы N FS, перечислены в табл . 2 1 . 7. Таблица 2 1 .7. Документы RFC , связанные с NFS Название

Автор

1 094

Network File System Protocol Specification

Sun Mircosystems

Май 1 989

1813

N FS Version 3 Protocol Specification

В. Callaghan et al.

Июнь 1 995

2623

N FS Version 2 and Version 3 Security lssues

M . Eisler

Июнь 1 999

2624

N FS Version 4 Design Considerations

S. Shepler

Июнь 1 999

3530

N FS Version 4 Protocol

S . Shepler et al.

Апрель 2003

566 1

NFS Version 4 Minor Version 1 Protocol

S.Shepler et al .

Январь 20 1 0

7862

NFS Version 4 Minor Version 2 Protocol

Т. Haynes

Ноябрь 20 1 6

RFC

Дата

глава

22

Файловая система sмв

В главе 2 1 описывается самая популярная система для совместного испол ьзования файлов в системах U N IX и Linux. Однако U N IХ-системам также необходимо обеспечи­ вать совместное использование файлов с такими систе мам и , как Windows, которые не поддерживают N FS . Введите S M B ! В н а ч ал е 1 980-х гг. Барр и Фейген баум ( Barry Feige nbaum ) создал протокол BAF для обеспечения совместного доступа к файлам и ресурсам . П еред выпуском название было изменено с и н ициалов автора на Server Message Block ( S M B) . П ротокол был бы­ стро подхвачен компанией M ic rosoft и сообществом пол ьзователе й персональных ком ­ п ьютеров, поскол ьку он давал доступ к файлам н а удал е н н ы х с истемах, практически н е отличающийся от доступа к локал ьны м файлам . В 1 996 г. компания M ic rosoft выпустила версию под названием Common l ntemet File System (C I FS ) , в основном в качестве м аркети н гового упражн е н ия . ‘ П ротокол C I FS внедрил (часто ошибоч н ые) изме нения в исходный протокол S M B. В результате ком па­ ния Microsoft выпустила S M B 2.0 в 2006 г. , а затем S M B 3.0 в 20 1 2 г. Хотя в отрасл и ш и ­ роко распространено обращение к файлам S M B как C I FS, правда в том , что C I FS давно устарел ; работает только S M B . Если вы работаете в однородной среде U N IX и Linux, эта глава, вероятно, не для вас. Но есл и вам н уже н способ коллективного испол ьзования файлов пользователя м и систем UN IX и Windows, ч итайте дальше. 1 Компания Sun M icrosystems также вступ ила в и гру в 1 996 г» предложив протокол �bN FS, и ком ­ пания M icrosoft увидела возможность продавать протокол S M B с более удобной реализацией и н а ­ званием.

часть 111. Хранение данных

834

2 2 . 1 . Sдмвд: СЕРВЕР SMB для U N IX Samba — популярный програ м м н ы й пакет, досту п н ы й под л и цензией G N U PuЫic License , который реализует серверную часть протокола S M B на хостах U N IX и Linux. Он был первоначально создан Эндрю Триджеллом (Andrew Tridgell), который первым дизас­ семблировал код протокола S M B и опубли ковал его в 1 992 г. Здесь мы сосредоточимся на верс ии Samba 4. Пакет Samba хорошо поддерживается и активно развивается , рас ш иряя свои функ­ u и о н ал ь н ы е возможности . О н предлагает стабил ьн ы й , пром ы шл е н н ы й способ со­ вм естного использован ия файлов пол ьзователями систем U N IX и Windows. Н астоящая красота Samba закл ючается в том , что вы устанавл иваете только оди н пакет на стороне сер вера ; на стороне Windows специальное программ ное обеспечен ие не требуется. В мире Windows файловая с истем а или каталог, доступная по сети , н азывается об­ щей папкой (share). Это звучит немного странно для пользователей U N IX, но мы следуем этому соглашению при обращен и и к файловой системе S M B. Хотя мы рассматриваем только совместное использование файлов в этой главе, Samba может также реализовать множество других кросс-платформенных служб, включая •

аутентифи кацию и авторизацию;

сетевую печать;

преобразование и м е н ;

анонсирован и е службы ( просмотр ресурсов файлового сервера и общих принте­ ров) .

Samba также м ожет в ыпол нять основные фун к ц и и контроллера Wi ndows Act ive Diгectory. Тем не менее эта конфигурация недостаточно надежная ; мы подозревае м , что контроллер AD, вероятно, лучше всего реализовать с помощью серверов Windows. Однако, кон ечно, важно, чтобы ваш и UN IX- и Linuх-систе м ы был и добавлены в до­ мен AD как клиенты. Это соглашение позволяет обмениваться идентификационной и н ­ формацией и и н формацией о б аутентификации на всех сайтах. Допол н ительную и нфор­ мацию см. в главе 1 7 . Аналогично мы не рекомендуем Samba в качестве сервера печати. В этом случае, ве­ роятно, луч ш е всего использовать пакет C U PS . Допол нител ьную информацию о печати в с истемах U N IX и Linux с помощью C U PS см. в главе 1 2. Большинство фун кций Samba реал изованы двумя де монам и , smЬd и nmЬd. Демон smЬd реализует обслуживание файлов и зада н и й н а печать, а также ауте нтификац и ю и авторизацию. Демон nmЬd обслужи вает другие основные ком поненты S M B : преобра­ зование имен и анонсирование служб. В отл и ч ие от систе м ы N FS , для которой требуется поддержка на уровне ядра, па­ кет Samba не требует каких-либо изменений драйверов или ядра и работает пол ностью как пол ьзовательский п роцесс . Он подключается к сокету, испол ьзуемому для запросов S M B , и ожидает поступл е н и я запроса от клие нта на доступ к ресурсу. После аутенти­ фикаци и запроса демон smЬd создает экзе м пляр самого себя и запус кает e ro от и м е н и пол ьзователя , приславшего запрос . В результате в с е обы ч н ы е права доступ а к фай ­ л у (включая групповые права) остаются ненаруш е н н ы м и . Единствен ная специальная функциональная возможность, которую добавляет демон smЬd, это служба блокиров­ ки файлов, которая предоставляет системам Windows семантику блокировки, к которой они привыкли. —

глава 2 2 . Файловая система sмв

835

Есл и вам по-прежнему и нтересно, зачем испол ьзовать S M B , а не, скажем , более и н ­ тегрирова нную в с истему U N IX удален ную файловую с истему, такую как N FS , т о ответ однозначе н . Почти все операцион н ы е с исте м ы поддержи вают S M B на определе н ном уровне. В табл . 22. 1 приведен ы некоторые ос новные различия меЖду S M B и N FS . Таблица 22. 1 . Сравнение протоколов S M B и N FS SMI

NFS

Серверы и процессы пользовательского пространства

Сервер ядра с потоками

Процессы дл я каждого пользователя

Один сервер ( один процесс) для всех клиентов

Использует базовую операционную систему для контроля доступа

Имеет собственную систему контроля доступа

Механизмы монтирования: обычно индивидуальные пользователи

Механизмы монтирования: обычно системы

Довольно хорошая производительность

Наилучшая производительность

Система N FS более подробно рассматри вается в главе 2 1 .

22.2. И НСТАЛЛЯЦИЯ И КОНФИГУРАЦИИ ПАКЕТА 5АМВА П а кет Samba может работать во всех расс мотре н н ы х н а м и о п е рацион н ы х с и ­ сте мах. Более того, в бол ь ш и нстве дистрибутивов Linux о н установл е н по умолча­ нию. Ис правления , документац и ю и другие файлы можно загрузить с сайта s am b a . o r g . Обязательно следует убедиться в том , что испол ьзуются нове й ш ие из доступ ных для дан н ой систе м ы пакеты Samba, потому что дефекты предыдущих верс и й чре ваты потерей дан н ых и возн икновением проблем с безопасностью. Если пакет Samba еще не установлен в ва ше й с исте м е , вы можете установить е го в системе Fre e B S D с помощью команды pkg install samЬa4 8 . В с истемах семейства Linux загрузите пакет saшЬa-coJDJDon через испол ьзуемый вами менеджер пакетов. Пакет Samba н астраи вается в файле / etc/ samЬa/ smЬ . conf ( /u s r / l o ca l / etc/ smЬ4 . conf в с истеме Free B S D ) . В этом файле указываются каталоги дл я совместного испол ьзования, их права доступа и общие рабоч ие параметры Samba. Пакеты Li nux до­ статоч но удобны тем , что в н их предоставляется хорошо докуме нтирован н ы й файл кон ­ фигурации Samba , которы й я вляется хорошей отправной точ кой Д/I Я новых н астрое к. Samba поставляется с разум н ы м и настройками по умолчан ию Д/I Я с воих параметров конфи гураци и , и Дll Я большинства приме нений н ужен только небольшой файл конфи­ гурации . Выполните команду testparm -v Дll Я вывода списка всех параметров конфи­ гурации Samba и знач е н и й , которые им в настоя щий момент назначен ы . Этот сп исок включает ваш и настройки из файла smЬ . conf ил и smЬ4 . conf, а также л юбые значения по умолчан ию, которые вы не переопредел ил и . Обратите внимание: после запуска пакет Samba проверяет свой файл конфигурации каЖдые несколько секунд и загрузит любые внесен ные в него изменения — перезагрузка не требуется! Наиболее распространенное испол ьзование пакета Samba обмен файлами с кл иен­ там и Windows. Доступ к этим ресурсам должен быть аутентифицирован через учетную за­ пись пользователя одн им из двух вариантов. В первом варианте испол ьзуются локал ьн ые учетн ые записи, Д/I Я которых определя­ ются идентификатор пользователя и пароль, которые никак не связа н ы с други м и учет­ н ы м и записям и пользователей ( например, с их логином на вход в доме н ) . Второй вари-

Часть 111. Хранение данных

836

ант объединяет аутентификацию Active Directory и , таки м образо м , совмещает учетн ые данные пользователей.

Совместное использова ние файлов с ло кал ьной аутентифи к а цией Сам ы й простой способ ауте нтификации пол ьзователе й , которые хотят получить до­ ступ к ресурсам Samba, — создать для них локальную учетную запись на сервере U N IX ил и Linux. Пос кол ьку парол и Windows работают совсем и наче , чем пароли U N IX, пакет Samba не может контролировать доступ к общим ресурсам S M B с помощью существую­ щих паролей учетных записей пользователей UN IX. Следовательно, для испол ьзован и я локальных учетных записей необходимо хран ить (и поддерживать) отдел ьный х е ш паро­ ля S M B для каждого пользователя . И ногда, однако, эта простота переве ш и вает удобство для пользователя , н о тем не м е ­ н е е эта систем а аутентификации действител ьно проста. Н иже приведен пример файла smЬ . conf, в котором используется эта система. [ g l ob a l ]

=

wo r k g r o up s e cu r i t y

=

u l s ah user

n e t b i o s n ame

=

freebsd-book

Параметр s e c u r i ty = u s e r предписывает пакету Samba испол ьзовать локальные учетные записи U N IX. Убедитес ь, что имя рабочей груп п ы ( w o r k g r o up ) установлен о в соответствии с вашей средой. Обычно это домен Active Directory, есл и вы находитесь в среде Wi ndows. Если в ы используете другую среду, то можете опустить эту настрой ­ ку. П акет Samba и меет собствен ную команду smЬpas swd для настрой к и хешей паролей в стиле Windows. Например, н иже м ы добавляем пол ьзователя t o Ь i и устанавл и ваем для него пароль. $ sudo slllЬpas swd

tobi

Re t yp e n e w SMB p a s s w o r d : < пароль> -а

N e w SMB p a s s w o r d :

Учетная запись U N IX должна существовать до того, как вы попытаетесь установить для нее свой парол ь Samba. Пол ьзователи могут изменять с вой пароль Samba, запусти в команду smЬpasswd без каких-либо параметров. $ slllЬp as swd N e w SMB p a s s wo r d :

< пароль > < пароль>

Re t yp e n e w SMB p a s s w o r d :

В этом примере изменяется пароль Samba текущего пользователя на сервере Samba. К сожал е н и ю , пол ьзовател и систе м ы Windows должны с н ачала заре гистрироваться в с исте мной оболочке на сервере , чтобы изменить пароль с воего общего доступа к S M B . Возможность удаленного входа в систему должна настраиваться отдельно, скорее всего, с помощью протокола S S H .

Совместное испол ьзова ние файлов с помощью учетных записей, п рошедш их аутентификацию Active Di rectory П ростой процесс сохране н и я отдельной базы дан н ы х аутентификац и и дл я совмест­ ного использования файлов с помощью команды smЬpas swd кажется архаичным в се­ годня ш не м гиперинтегрированном м и ре. В бол ь ш и н стве случаев н еобходимо, чтобы

Глава 22. Файловая система sмв

837

пользователи п роходили аутентификаци ю через н е которые фор м ы централ изова н н ых систем управления полномоч ия м и , такие как Active Directory ил и L DAP. П оследние годы привел и к большим ус пехам в этой области для операционных си­ стем U N IX и Linux. Н еобходимые ком поненты , вкл ючая службы каталого в , демон sssd2, а также файл nsswi tch . conf и библиотеки РАМ , описаны в главе 1 7 . П осле раз­ вертыван ия этих компонентов легко настроить пакет Samba для их испол ьзования. Н иже приведен пример файла конфигурации smЬ . conf для среды, в которой Active Directory выполняет аутентификацию пользователя (с помощью демона s s sd ) . [ g l ob a l ] w o r k g r oup u l s ah r e a lm = u l s ah . e x amp l e . c om security ads d e d i c a t e d k e y t ab f i l e F I L E : / e t c / s amЬ a / s amЬa . ke y t a b ‘ k e r b e r o s me thod = d e d i c a t e d k e y t a b =

=

=

В этом случае параметр r e a l m долже н быть таким же , как локальное и м я домена Active Directory. Параметры d e d i c a t e d k e y t a b f i l e и ke rbe r o s me t h o d позволя ют Samba корректно работать с реал изацией Kerberos Active Directory.

Настройка общих ресурсов После того как вы настроил и общие настройки и ауте нтификацию Samba, можете указать в файле smЬ . conf, какие каталоги должн ы испол ьзоваться совместно через про­ токол S M B . Каждому ресурсу совместного ис пол ьзова н и я , котор ы й вы откры ваете для обще го доступа, необходимо поставить в соответствие собственный раздел в файле конфигурации. И м я раздела становится и менем общего ресурса, которое анонсируется для клиентов S M B. Вот пример: [ bookshare ] path / s torage /bookshare read only = no =

Зде с ь кл и е н т ы S M B в идят монтируе м ы й ресур с с и м е н е м \ s a m b a s e r v e r boo k s h a r e . Это дает доступ к дереву файлов, рас положе н ному в каталоге / s t o r a g e / boo k s h a r e на сервере.

Совм естное исполыование рабочих каталогов пользователей Вы можете автоматически преобразовы ват ь рабочие каталоги пол ьзователей в от­ дельные S М В-ресурсы с помощью специал ьн ого назва н и я раздела [ home s J в файле smЬ . conf: [ h ome s ] comme n t Ноте D i r e c t o r i e s b r ows e a Ы e no va l i d u s e r s = % S r e a d on l y no =

=

=

2 8 прошлом для и нтеграци и Active Di rectory и пакета Samba использовался демон winЬind. В наши дн и предпочтител ьны м я вляется демон sssd. 1Этот файл keytaЬ создается демоном s s sd, есл и вы его настроил и в соответствии с и нструк ция ­ ми из главы 1 7 . Допол н ител ьн ые сведен ия о файлах keytaЬ в протоколе Samba с м . на са йте goo . gl/ ZxCUКA ( глубокая ссылка внутри wiki . samЬa . org) .

Часть 111. Хранение данных

838

Н апример, эта конфигурация позволит пол ьзователю j a n d e r s o n получить доступ к своему рабочему каталогу через путь \ samb a s e r ve rj a nd e r s o n из л юбой с исте м ы Wi ndows в сети. На некоторых серверах разрешения по умолчани ю для рабочи х каталогов позволяют пол ьзователя м просматривать файлы друг друга. Поскольку в пакете Samba используют­ ся разреш е н ия файлов U N IX для реализации контроля доступа, пользователи Windows, входящие через Samba, могут также ч итать домашние каталоги друг друга. Одн ако опыт показывает, что такое поведение приводит к путанице пользователе й Windows и делает их уязвим ы м и . Переменная % S , указанная как значение va l i d u s e r s в приведен ном в ы ш е примере, заменяется на имя пользователя , связанного с каЖдым общим ресурсом ; таким образом. она ограничивает доступ к владельцу домашнего каталога. Удалите эту строку, если такое поведение сервера S M B для вас нежелательно. П акет Samba испол ьзует специал ьн ы й раздел файла конфигурации [ home s ] в каче ­ стве последнего средства. Если в рабочем каталоге конкретного пользователя есть я вно определ е нн ы й общий ресурс в файле конфигурации , параметр ы , установленн ые там , переопределяют значения, установленные в разделе [ home s ] .

Совм естное использование каталогов проектов W Дополнительную информацию о списках ACL см. в разделе 5 . 6 . П акет Samba м ожет отображать с п иски управл е н и я доступом с исте м ы Windows (AC L) н а традиционн ые права доступа к файлам в с истемах UN IX или AC L, если это поддерживает файловая система. Однако на практике мы обнаруживае м , что ACL сли ш ­ ком сложны дл я большинства пользователей. Вместо испол ьзования списков AC L м ы обы ч но настраи ваем специальную общую папку для кацой групп ы пользователей, которая нуждается в каллективной рабочей об­ ласти . Когда пользователь пытается подключить этот ресурс , пакет Samba проверяет, что зая витель находится в соответствующей группе UN IX, преЖде чем разреш ить доступ. В приведенном н иже примере пользовател ь должен быть частью групп ы e n g для под­ кл юче ния общей папки и доступа к ее файлам . [ en g ] c ommen t Обща я nапка для инженерного отдела Для доступа к э тому р е сурсу поль з о в а тель долже н входи т ь в группу e n g . ; Поль з о в а т ели д олжны подключ а т ь с я со с в оими уче тными з а пис ями , созданными ; на с е р в е р е S amЬa . va l i d u s e r s = @ e n g path / h ome / e n g =

=

; От ключим N T AC L , т а к к а к nt a c l s up p o r t = n o

мы

их н е исполь зуем .

Убеди т е с ь , ч т о всем файлам в п апке н а значены с о о т в е т с т вующие пр а в а доступа и ч т о для э ти х каталогов ус тановлен бит s e t g i d ( наследование группы ) . c r e a t e ma s k = 0 6 6 0 d i r e c t o r y ma s k = 2 7 7 0 2000 f o r c e di r e c t o r y mode f o r c e g r oup = e n g

Глава 22. Файловая система sмв

839

; Об щи е п араме тры для в с е х р е с у р с о в . b r ows e a Ы e = no read only no gue s t o k = n o =

Эта конфи гурация не требует создания псевдопол ьзователя , чтобы он мог действо­ вать как владеле ц общей пап ки . Вам нужно просто создать груп п у в с исте ме U N / Х (здесь, e n g ) и включить в нее предполагаем ы х пользователей этого общего ресурса. Пол ьзователи будут подкл ючать общий ресурс под свои м и учет н ы м и зап ися м и , но для облегче н ия совместной работы мы предпочли б ы , чтобы л юбые файл ы , создан н ые в рамках этого ресурса, при надлежали группе e n g . Таким образом, другие член ы коман­ ды могут получить доступ к вновь созда н н ы м файлам по умолчан ию. Первым шагом на пути к обес пече н и ю такого поведен и я я вляется применение па­ раметра f o r c e g r o u p для принудител ьного испол ьзования текуще го идентифи катора групп ы U N IX e n g , которая контрол ирует доступ к общей папке. Однако этого шага не­ достаточ но, чтобы гарантировать, что все новые файлы и каталоги будут принадлежать к групп ы e n g . Как указы валось в разделе 5 . 5 , установле н н ы й для каталога флаг s e t g i d задает дл я всех новых файлов, созданных в этом каталоге , в качестве владел ьца группу этого ката­ лога.4 Чтобы гарантировать, что все вновь созда н н ые файлы будут принадлежать груп ­ п е e n g , м ы должны установить дл я корневой папки группу e n g , а затем вкл юч ить б и т s e t g i d для этого каталога, к а к показано н иже. $ sudo chown root : eng /home/eng $ sudo chmod u=rwx , g=rwxs , o= /home /eng

Эти меры достаточ н ы для управле н ия файлам и , созда н н ы м и в кор н е вой папке. Однако для того , чтобы с истема работала со слож н ы м и иерархия м и файлов, нам так ­ ж е необходимо обес печ ить установку битов s e t g i d для вновь созда н н ы х каталогов. Приведен ная выше примерная конфигурация реал изует это требован и е с помощью па­ раметров f o r c e d i r e c t o r y mode и d i r e c t o r y ma s k.

22.3 . МОНТИРОВАНИЕ ОБЩИХ SMB-PECYPCOB Монтирование общих S М В-ресурсов работает совсем не так, как это делается в дру­ гих сете вых файловых с исте мах. В частности , S М В-тома монтируются кон кретн ы м пол ьзователе м , а не самой системой. Для выполнения монтирования S М В-ресурсов требуется локальное разрешение. Вам также н ужен пароль для идентифи кации , которы й позвол ит удален н ом у S М В-серверу разре ш ить доступ к обще му ресурсу. Ти пич ная командная строка в с истеме Linux в ы ­ глядит следующим образом. $ sudo mount — t cifs

username=j oe / / redmond/ j oes /home/ j oe /mnt

Ее эквивалент в системе Free B S D имеет следующий вид. $ sudo mount — t smЬfs / / j [email protected] redmond/ j oes /home / j oe/mnt

В с истеме Win dows монтирования сете вых ресурсов выполняются для кон кретного пользователя (отсюда и параметр username=j oe) , тогда как в системе U N IX они выпол 4 Ил и , п о крайней мере, он делает это в системе Linux. В системе Free B S D н е устанавл и вается бит s e t g i d для каталога; однако поведение no умолчани ю закл ючается в унаследован и и rpyn n ы д,1я новых файлов, так же, как в Linux это делается с вкл ючен н ы м битом s e t g i d . В п роче м , устанонка бита s e t g i d в системе Free BS D н и чему не вредит.

Часть 111. Хранение данных

840

няются как правило для всей систе м ы в целом . Серверы Wi ndows обычно не допуска­ ют, чтобы несколько разных пол ьзователе й могли получ ить доступ к смонтированному общем у ресурсу Wi ndows. С точк и зрения клиента U N IX все файл ы в смонтирован ном каталоге , принадлежат пользователю, которы й его смонтировал . Если вы монтируете общий ресурс с права­ ми адм и нистратора, то все файлы будут принадлежать пользовател ю r oo t , а остальные пол ьзователи , возможно, не смогут зап исывать файлы н а сервере Windows. П араметры монтирования uid, gid, fmask и dmask позволяют н астроить эти пара­ метры так, чтобы п рава собствен ности и б иты разрешений бьш и более точно согласова­ ны с предполагаемой политикой доступа для этого ресурса. Допол нительную информа­ цию об этих параметрах можно найти на страницах с правочника для команды mount . cifs ( Linux) или mount_smЬfs ( Free BSD).

22.4. П РОСМОТР ФАЙЛОВ НА ОБЩИХ SMB-PECYPCAX В пакет Samba включена утилита командной строки, называемая smЬclient, которая позволяет отображать список файлов конкретного сетевого ресурса без фактического их монтирования. В нем также реализован FТР- подобный интерфейс дл я интерактивного доступа. Эта фун кция может быть полезна при отладке или когда сценарию н еобходим доступ к общей папке . Например, вот как можно вывести список доступных сетевых ресурсов для пользова­ теля dan на сервере h o a rde r . $ smЬclient L / /hoarder — U dan E n t e r dan ‘ s p a s s w o r d : Doma i n = [ WORKGROU P ] OS= [ Un i x ] S e rv e r = [ S amba 3 . 6 . 2 1 ] —

S h a r e name

Туре

Comme n t

Di s k Di s k Di s k Di s k

Temp S t o r a g e Va r i o u s P r o g r ams and App l i c a t i o n s S h a r e d Docume n t s B a c kups o f a l l s o r t s

— — — — — — — — —

T emp P r o g r am s Docs B a c ku p s

— — — — — — —

Для того чтобы подключиться к общему ресурсу и передать файл ы , уберите флаг и укажите имя этого ресурса.

-L

$ smЬclient / /hoarder/Docs -U dan

После подкл ючения введите команду help для получения списка доступн ых команд.

22.5. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ 5АМВА-СЕРВЕРА Важно помнить о влиян и и безопасности на совместное использование файлов и дру­ гих сетевых ресурсов. Чтобы обеспеч ить базовый уровен ь безопасности для типичной организации , необходимо сделать две вещи. •

Явно указать, какие клиенты могут получ ить доступ к общ и м ресурсам S М В­ сервера. Эта часть конфигураци и задается параметром hosts al low в файле smЬ . conf. Убедитесь, что он содержит только необходимые I Р-адреса, диапазоны адре­ сов или имена хостов.

Глава 22. Файловая система sмв

841

В файл smЬ . conf можно также включить параметр настройки hosts deny, но уч­ тите , что директива запрета на доступ к сетевым ресурсам имеет приоритет. Если вы укажете и м я хоста ил и его адрес как в параметре hos ts deny, так и в hosts allow, указанн ы й хост не сможет получ ить доступ к ресурсу. •

Блокировать доступ к S М В-серверу за пределами сети вашей организации . В па­ кете Samba испол ьзуется ш ифрование только дл я ауте нтификации с помощью парол я . В нем не испол ьзуется ш ифрование дл я передачи данн ых. П очти во всех случаях вам следует блокировать доступ извне сети ваше й орга н и заци и , чтобы пользовател и случайно не загружали файлы в открытом виде через И нтернет. Блоки ровка обычно выполняется на уровне сетевого брандмауэра. Пакет Samba испол ьзует U DР-порты 1 37- 1 39 и ТС Р-порты 1 37 , 1 39 и 445.

С момента выпуска Samba верси и 3 в викисистеме SamЬa по адресу w i k i . s arnЬa . o rg доступна отличная документация по настройке с истем ы безопасности.

22.6. ОТЛАДКА SAMBA-CEPBEPA Сервер Samba обычно не требует особого внимания. Если у вас возникла проблема, вы можете обратиться к двум основным источ никам информации для отладки : команде smЬstatus и средствам протокол ирования Samba.

З ап рос состоя ния Sa m ba — cep в epa с помощью команды smЬs tatus Команда smЬs tatus показы вает акти вные соеди нения и заблокирова н н ы е файл ы ; это первое место, в которое следует заглянуть, когда возн икают пробле мы. Выводимая информация особенно полезна для отслежива н ия п роблем с блокировкой (например, » У какого пользователя есть экскл юзивный доступ к файлу xyz для чтения и записи ? » ) . $ sudo smЬs tatus

# Ча с ть вывода сжа та для ясности

S amЬ a ve r s i on 4 . 3 . 1 1 -Ubuntu G r oup PID U s e rname 6130 23006

clay dan

S e rv i c e

pid

admin swde p o t 2 clients clients

6130 6130 6130 23006

1 92 1 92 1 92 1 92

Machine

atrust atrust

1 92 . 1 68 . 2 0 . 4 8 1 92 . 1 6 8 . 20 . 2 5

mac h i n e

C o nn e c t e d a t

. . . .

168 . 20 . 48 1 68 . 20 . 48 1 68 . 20 . 48 1 68 . 2 0 . 25

Wed Wed Wed Fri

Ap r Ap r Ap r Ap r

12 12 12 28

07 : 2 5 : 1 5 07 : 25 : 15 07 : 25 : 15 1 4 : 32 : 2 5

2017 2017 2017 2017

Locked f i l e s : Pid U i d DenyMode

R/W

Op l oc k

SharePath

N ame

6130 1035 6130 1035 23006 1009

RDONLY RDON L Y RDONLY

NONE NONE NONE

/ a t ru s t / admi n / h ome / c l a y /atrust/clients

New H i r e P r o c e s . . .

DENY NONE DENY ALL DENY NONE

Acme _ S upp l y / C o n . . .

Часть 111. Хранение данных

842

В перво м разделе в ы вода отображается с п исок подкл ю ч и в ш ихся пол ьзовател е й . В столбце S e rv i c e в следующе м разделе показаны фактические сетевые ресурсы , кото­ рые они с монтировали . В последнем разделе , из которого мы удалили несколько столб­ цов для эконом и и места , переч исле н ы любые активные блокировки файлов. Если вы завершите работу демона smЬd, связанного с определенн ы м пользователем , то все блокировки этого пользователя исчезнут. Некоторые приложен ия обрабатывают эту ситуацию изящно и запрашивают блокировки заново. Другие просто зависают и требуют вмешательства со сторон ы Windows, чтобы закрыть неудачное приложение. Как бы драма­ тично это н и звучало, никаких ис кажений дан н ых в файлах в результате такой процедуры не возн икает. Будьте в н имател ьн ы , когда Windows заявляет, что файл ы был и заблокирова н ы дру­ гим п р иложе н и е м ; это часто оказы вается правил ьн ы м предупрежден ие м . Устра н и те п роблему на стороне кл иента, закры в приложен и е — наруш ител ь, а не п ытайтес ь грубо сни мать блокировки на сервере.

Н аст р ойка жу р нала Samba — cep в epa Настройте параметры журнала в файле smЬ . conf. [ g l oba l ] # Параме тр %m создает отдель ный файл журнала для каждо г о кли е н т а . l o g f i l e = / va r / l o g / s amЬa . l o g . %m max l o g s i z e = 1 0 0 0 0 # Чтобы S аmЬ а — сервер выводил си с т емный журнал и с ключит е л ь но ср е д с т в ами s y s l o g , # установите значение сле дующе г о параме тра р а в ным ‘ y e s ‘ . s y s l og оп l у no =

# # # #

С т арайт е с ь минимизир о в а т ь выв од S а mЬ а — с е р в е р а в сист емный журнал s y s l og . В с я информация должна з апи с ы в а т ь с я в файлы / va r / l o g / s amba / l o g . { smЬd , nmЬd } . Ч т обы выв е сти в s y s l og бол е е подро бную информацию , увелич ь т е значение следующе г о параме тра s y s l og 7 =

П р и увел иче н и и значения параметра s y s l o g в журнал будет вы водиться бол ьше и н ­ формации . Для ведения журнала задействуются систе м н ые ресурсы , поэтому не устанав­ л и вайте сл и ш ком высоки й уровен ь ведения журнала, если вы не собираетесь выпол н ять активную отладку. В следую щ е м при мере показа н ы записи журнала, создан н ые в резул ьтате неудач ной попыткой подкл ючения. ( 2 0 1 7 / 0 4 / 3 0 0 8 : 4 4 : 4 7 . 5 1 0 7 2 4 , 2 , p i d= 8 7 4 9 8 , e f f e c t ive ( O , 0 ) , r e a l ( O , 0 ) , c l a s s = a ut h ] . . / s ou r c e 3 / a u t h / a u t h . c : 3 1 5 ( au t h_ c h e c k_n t l m_p a s sword )

c h e c k_n t l m_p a s sword : Au t h e n t i c a t i on f o r u s e r [ da n ] — > [ da n ] FA I LE D w i t h e r r o r NT _ S TATU S_WRONG_PAS SWORD [ 2 0 1 7 / 0 4 / 3 0 0 8 : 4 4 : 4 7 . 5 1 0 8 2 1 , 3 ] . . / s ou r ce 3 / smЬd / e r r or . c : 8 2 ( e r r o r p a c ke t s e t ) NT e r r o r p a c k e t a t � . / s o u r c e 3 / smЬd / s e s s s e t up . c ( 9 3 7 ) cmd= l l 5 ( SMB s e s s s e t upX ) NT_STATUS_LOGON_FA I LURE

Удач ная попытка подключе ния выглядит следующим образо м . [ 2 0 1 7 / 0 4 / 3 0 0 8 : 4 5 : 3 0 . 4 2 5 6 9 9 , 5 , p i d= 8 7 5 0 2 , e f f e c t ive ( O , 0 ) , real ( 0 , 0 ) , c l a s s=aut h ) . / s ou r ce З / a u t h / .

Глава 2 2 . Файловая система sмв

843

a u t h . c : 2 9 2 ( au t h _c he c k_n t l m_p a s swo r d ) che c k_n t lm_p a s s wo r d : Р АМ Account f o r u s e r [ dan ] s u c c e e d e d [ 2 0 1 7 / 0 4 / 3 0 0 8 : 4 5 : 3 0 . 4 2 5 8 6 4 , 2 , p i d= 8 7 5 0 2 , e f f e c t ive ( O , 0 ) , r e a l ( O , 0 ) , c l a s s = a ut h ] . . / s ou r c e 3 / a u t h / a u t h . c : 3 0 5 ( a u t h _ c h e c k_nt l m_p a s sword ) che c k_n t lm_p a s s w o r d : a u t h e n t i c a t i on f o r u s e r [ da n ] — > [ da n ] — > [ da n ] succeeded

Команда smЬcontrol удобна для изменения уровня отладки работающего Samba­ cepвepa без внесения изменений в файл smЬ . conf. Например, $ sudo sшЬcontrol sшЬd deЬuq «4 auth : l O «

Эта команда устанавл ивает дл я глобального уровня отладки значение 4 и устанавли­ вает уровен ь отладки для связанных с аутентификацией вопросов до 1 0. Аргумент smЬd указывает, что все демоны smЬd в системе должны и меть установленные уровни отладки. При отладке конкретного установленного соединен ия используйте команду smЬstatu s , чтобы определить, какой демон smЬd обрабаты вает соединение, а затем передайте его идентификатор P I D в smЬcontrol для отладки только одного соединения. При уровнях журнала более 1 00 вы начнете видеть зашифрованные пароли в журналах.

Уп равление наборами символов Н ач иная с версии 3.0, Samba кодирует все и мена файлов в кодировке UTF- 8 . Если ваш сервер работает с локал ьной кодировкой UTF- 8 , которую м ы рекомендуе м , то все отл ично. s Если вы находитесь в Европе и по-прежнему испол ьзуете на сервере один из языковых стандартов I SO 8859, то можете обнаружить, что созданные SаmЬа-сервером и м е на файлов, которые включают акце нтированн ые символ ы ( например, а, б , б , е или е ) , при выпол н е н и и команды l s отображаются не правил ьно. Реш е н ие состоит в том , чтобы Samba-cepвep использовал кодировку вашего сервера: u n i x c ha r s e t = I S 08 8 5 9 — 1 5 d i s p l a y c ha r s e t = I S 08 8 5 9 — 1 5

Убедитесь, что кодировка имен файлов правил ьно работает с самого начала. В про­ тивном случае файлы с неправил ьно закодированными именами накапл иваются. Их по­ следующее исправление — удивительно сложная задача.

22.7. ЛИТЕРАТУРА •

Rш Нлт. Red Наt Enterprise Linux System Administrator’s Guide: File and Print Servers. goo . g l / L P j NXa (глубокая ссьшка на сайте a c c e s s . redh a t . com/docume n t a t ion). Sлм вл PROJ ECT. Samba Wiki Page. w i k i . s amba . org. Эта вики-система обновляет­ ся относител ьно часто и является авторитетн ым источн и ком и нформации, хотя ее части несколько дезорганизованы .

� чтобы узнать, работает ли ваша система в режиме UTF-8, вы полн ите команду echo $LANG.

ЧА СТЬ

IV

Экспл уатац ия

глава

23

Управление кон фиг урацией

М ноголетн и й при н ци п с исте м ного адм и нистрирования закл ючается в том , что из­ менения должны быть структурирован н ы м и , автоматизированными и согласован н ы м и . Но это легче сказать, чем сделать, когда вы сталкиваетесь с разнородным парком с истем и сетей, пребывающих в разн ых состоян иях. Программное обеспечен и е для управлен и я конфигураци е й автоматизирует управ­ лен ие операционн ы м и системами в сети . Адми н истраторы составляют спецификации, описывающие, как серверы должны быть сконфигурирова н ы , а программ ное обеспече­ ние для управления конфигурацией затем воплощает в реальность соответствие с этим и спецификациям и . На практике широко используются верс и и управл е н ия конфигураци­ ями с открытым исходны м кодом. В этой главе мы расскажем о принципах управления конфигурацией и охарактеризуем основных и гроков. В качестве инструме нта автоматизации управление конфигурац и е й тес но с вязано с методологией П-операци й DevOps, о которой м ы более подробн о расскажем в раз­ деле 3 1 . l . Л юди зачастую н е разл ичают DevOps и управлен ие конфигурац ие й , поэто­ му иногда эти тер м и н ы используются как синон и м ы . Те м не менее он и и меют разный см ысл . В этой главе м ы приведем несколько примеров, демонстрирующих, как управ­ ле ние конфигурацией воплощает несколько ключевых элеме нтов методологии DevOps, в то же время не совпадая с н е й . Словосочетан и е «система управления конфигурацией» немного дл и нновато для чте­ ния и записи , поэтому мы часто сокращаем этот термин до «систе м ы СМ (configuration manage ment) » ( ил и даже просто С М ) . ( К сожал е н и ю , аббрев и атура C M S (content management system) уже ш ироко используется для обозначения «систем ы управления со­ держи м ым » . )

848

Часть lV. Эксnлvатация

23 . 1 . КРАТКОЕ ВВЕДЕНИЕ В УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ m Дополнительную информацию о сценариях оболочки см . в главе 7 . Традицио н н ы й подход к автоматизации систем ного адм и нистрирования основан на использовании сложного ком пл е кса самостоятельно разработанных с ценариев обо­ лоч ки , дополненных специальн ы м и средствам и безопасности на случай, если сценарии потерпят неудачу. Некоторое время эта схема работает хорошо, как и следовало ожидать. Однако со временем систе м ы , управляемые таким образом , обычно вырождаются в ха­ отические обломки версий пакетов и конфигураци й , которые невозможно достоверно воспроизвести. Такую схему иногда называют моделью системного администрирования снежинок, потому что не суrnествует двух похожих друг на друга систем. Более эффективный подход — управление конфигурацией. Он фиксирует :желаемое со­ стояние в виде кода. Затем изменения и обновления можно отслеживать с течением време­ ни в системе контроля версий, со:щающей контрольный :журнал и точку отсчета. Код также выступает в качестве неофициальной документации по структуре сети. Л юбой администра­ тор или разработчи к может прочитать код, чтобы определить, как настроена система. Когда все серверы орган изации находятся под управлением конфигурации, систе­ ма С М эффективно действует как база данн ых о ресурсах, а также как це нтр сетевого управления и контрол я . С истем ы С М также предлагают функции «ор кестровки » , кото­ рые позволяют удал е н но осуществл ять изменения и выполнять специальные команды. Вы можете нацелиться на группы хостов, и ме на которых соответствуют определ е н н ы м ш аблонам или переме н н ы е конфигурации которых соответствуют заданному набору значен и й . Управляемые кл иенты сообщают информацию о себе в це нтрал ьную базу дан ных для анализа и мониторинга. В бол ьшинстве случаев код управления конфигурацией испол ьзует декларативную, а не процедурную идиому. В место написани я сценариев, которые сообщают систе м е , каки е измен е н ия н ужно внести, в ы описы ваете состояние, которого хотите достичь. Затем с истема управления конфигурацией использует собственную логику для настрой­ ки целевых систем по мере необходимости. В конечном счете работа систе м ы С М заключается в применении ряда специфика­ ций конфигураци и , например операц и й , к отдельной машине. Операции различаются по сте пе н и детали зации, но они обычно достаточно круп ные, чтобы соответствовать элем е нтам, которые могут чаще других отображаться в с писке дел системного адм и н и ­ стратора: создать учетную запись пользователя , установить пакет програм м ного обеспе­ чения и т.д. Для полной настройки подсистем ы , такой как база дан ных, может потре­ боваться от 5 до 20 операций . П ол н ая конфигурация тол ько что загруженной систем ы может повлечь з а собой десятки или сотни операций.

23.2. ОПАСНОСТИ УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ Управление конфигурацией — это значительное улучшение по сравнению с специ­ альным подходом , но не вол шебная палочка. Для адми н ис траторов имеет бол ьшее зна­ чение несколько острых проблем , о которых нужно знать заранее. Хотя все основные с истем ы СМ используют аналогичные концептуальные модел и , о н и описывают эти модели с помощью разных лекс и конов. К сожалению, терм иноло­ гия , испол ьзуемая конкретной системой С М , часто ориентируется на маркетин г, а не на максимальную ясность.

Глава 2 3 . Управление конфигурацией

849

Результатом является отсутствие согласован н ости и стандартизации среди с исте м . Большинство администраторов будут сталкиваться с нескольки м и системами СМ на про­ тяжении всей своей карьеры и будут развивать предпочтения, полученн ые на основе этого опыта. К сожалению, знание одной системы напрямую не переносится на другую. По мере роста орган изации требуется и нфраструктура, н еобходимая для поддержки своей систе м ы управления конфигурацией . Для орган изации с нескольким и тысячами серверов нужно нескол ько систе м , п редназначен н ы х для выпол не н ия рабочих н агру­ зок С М . Для создания таких систем необходим ы расходы на аппаратные ресурсы и по­ стоян ное обслуживание. Внедрение СМ-систем может быть одним из основных проектов. Для того чтобы организация пол ностью испол ьзовала управление конфи гураци е й , необходим определ е н н ы й уровен ь оперативной зрелости и строгости . Как тол ько хост оказы вается под управлением систе м ы С М , его нельзя изменять вручную, иначе система немедлен но перейдет в состояние систем ы снежинок. 1 Хотя некоторые систе м ы СМ легче осваивать, чем другие , все о н и известны тем , что имеют крутую кри вую обуч е н и я , особе н но для адм и нистраторов, которым не хватает опыта в автоматизации . Если вы соответствуете этому описанию, подумайте о том , что­ бы пройти практику в лаборатори и виртуальных машин , оттачивая свои навыки, прежде чем заниматься производствен ной сетью.

23.3. ЭЛЕМЕНТЫ УП РАВЛЕНИЯ КОНФИГУРАЦИЕЙ В этом разделе м ы рассмотрим компоненты систе м ы С М и концепции, испол ьзуе­ м ые для ее н астройки на более высоком уровне детализации. Затем , начиная с разде­ ла 2 3 . 4, м ы изуч и м четыре из н аиболее часто испол ьзуе м ы х с исте м С М : AnsiЬe , Sal t , Puppet и Chef. В место того чтобы при н имать какую-либо терм инологию кон кретной систе м ы С М , м ы испол ьзуем сам ы й яс н ы й и наиболее понят н ы й терм и н , кото р ы й с могл и н айти для каждой кон цеп ц и и. В табл . 2 3 . 2 при водится соответствие м ежду нашей лекс и кой и терминологией четырех систем С М , перечислен н ых выше. Если вы уже знакомы с од­ ной из этих систем С М , рекомендуем обратиться к дан ной таблице при чте н и и приве­ денного н иже материала.

Опера ции и параметры М ы уже рассматривал и кон цепцию операций , которые представл я ют собой мелко­ масштабные действия и проверки , используе м ые системой С М для достижен и я опре­ деленного состоян и я . Каждая система С М содержит большой н абор поддержи вае м ы х операций, который увеличивается с появлением каждой новой версии. Вот нескол ько примеров операций , которые все систе м ы С М могут в ыполнять без предварительной подготовки: •

создавать или удалять учетную запись пользователя либо устанавл ивать ее атрибуты;

копировать файлы в настраиваемую систему или из нее;

1 Мы н еоднократно стал к и вались с ситуация м и , в которых лен ивые или торопли вые адми н истра­ торы вручную обновляли хост, управляе м ы й конфигурацией , и делали свои модификаци и неизме­ няем ы м и , тем самым переопределяя ожидаемое состоян ие и не позволяя системе СМ применять будущие модификац и и . Это приводит к большой путанице , потому что коллеги адми н истратора не с могут быстро понять, почему ожидаемая конфигурация не при меняется к дан ному хосту. В одном случае это вызвало большой перерыв в обслужи ван и и .

часть lV. Эксплvатация

850 • • •

синхронизировать содержимое каталога; визуал изировать шаблон конфигурационного файла;

добаалять новую строку в файле конфигурации ; перезапускать службу;

добаалять задан ие cron или тай мер systemd;

запускать произвол ьную команду систе мной оболочки;

создавать новый экзе м пляр облачного сервера;

создавать или удалять учетную запись базы дан ных;

определять параметры работы базы данн ых;

выполнять операции в репозитори и Git.

Это всего лишь выборка; в большинстве систем С М определ е н ы сотн и операц и й , в том ч исле м н огие, которые выпол н я ют поте н циально сложн ые специальн ые опера­ ц и и , такие как настрой ка кон кретных баз данн ых , среды выпол н е н и я или даже части оборудования. Если операции кажутся подозрител ьно похожим и на команды оболочк и , ваша и н ­ туиция вас не подводит. Это сценар и и , обычно написан ные на языке реализаци и самой с исте м ы СМ и использующие стандартн ые и н струменты и библ иоте к и с исте м ы . Во м ногих случаях они автоматически запус кают стандартные команды оболочки как часть их реализации . Так же , как в командах UN[X можно указать ряд параметров, большинству операций можно передать параметры . Например, операци и упрааления пакетам и передаются па­ раметр ы , которые определяют имя пакета, версию и должен ли пакет быть установлен или удал е н . П араметры меняются в зависимости о т операц и и . Для удобства и м обыч н о присва­ и ваются стандартн ые значен и я , которые подходят дл я наиболее распространенн ы х слу­ чаев использования. С истемы С М позволяют использовать значения переменных (см. следующий раздел) для определения параметров. О н и также могут сами определ ить значения параметров в соответстви и со средой , в которой развернута с истема, например в сети , в которой и нсталл ирована с истема, в зависимости от того, присутствует ли конкретное свойство конфигурации ил и совпадает ли название хоста, на котором и нсталлирована с истема, с данн ы м регулярным выражением. Корректная операция н е должна зависеть от хоста или хостов, к которым в конеч ном итоге она может быть применена. Ее реализация должна быть относительно универсаль­ ной и н е зависящей от операционной систе м ы . Операц и и , привязанные к конкретн ы м системам , выполняются на более высоком уровне иерархии упрааления конфигурацией. Нес мотря н а то что с исте м ы С М сосредоточе н ы на де кларативной конф и гура­ ц и и , операции должны в конечном счете вы пол н ятьс я , как и л юбая другая команда. Исполнение имеет начало и конец. Операция может завершиться успехом или неудаче й . О н а должна возвращать свое состоян и е вызывающей среде. Однако операц и и отли ч аются от тип ич н ых команд U N IX нескол ьки м и важ н ы м и аспектам и. •

Бол ь ш и н ство операц и й предназначен ы для м ногократного и безопасного при­ мене н и я . Заимствуя тер м и н из линейной алгебры , это с войство иногда назы вают идемпотентностью. Операции знают, когда они изменяют фактическое состоян ие с истемы.

Глава 2 3 . Управление конфигурацией •

851

Операци и знают, когда необходимо измен ить состоян ие с исте м ы . Если текущая конфигурация уже соответствует спецификации, операция завершается без каких­ либо действи й . Операции сообщают о своих резул ьтатах системе С М . И х дан н ы е отчета содержат бол ьше информаци и , чем простой код завершения в стиле UN IX, и могут помочь в отладке . Операции должны быть кросс- платформен н ы м и . Обычно они определяют огра­ н ич е н н ы й набор фун кци й , которые я вля ются общим и для всех поддерживаемых платформ , и интерпретируют запросы в соответствии с локал ьной системой.

Н екоторые операции не могут быть сделаны идем потентн ы м и без небол ьшой помо­ щ и адм и н истратора, которы й знает бол ьше об этом контексте. Например, если опера­ ция запускает выпол н е н ие последовател ьности команд U N IX, то с истема С М не и меет прямого способа узнать, какой эффект она произвела на с истему. Кроме того, существует возможность п исать собствен н ы е пол ьзовател ьские опера­ ции. Это всего л и ш ь сценарии, и система СМ обычно обеспечивает гладки й способ и н ­ теграции пользовательских и стандартных операци й .

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

Перемен н ые обычно могут быть определен ы в нескольких местах и контекстах в базе конфи гураци и . Каждое определение имеет область видимости. Ти п ы области види мости варьи­ руются в зависимости от с исте м ы С М и могут охваты вать одну маш и ну, группу маши н или определенный набор операций. Несколько областе й могут быть акти вны в л юбом задан ном контексте . Области могут быть вложе н н ы м и , но чаще они просто взаимодействуют. Поскол ьку в нескол ьких областях могут определяться значения для одной и той же переменной, требуется некоторая форма разрешения конфл и ктов. В некоторых с исте мах значения объединяются , но в большинстве испол ьзуются правила при­ оритета ил и порядок выбора основного значения.

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

Ф а кты Систе м ы С М исследуют каждый кл иент конфигурации для определения описатель­ н ых фактов, таких как I Р-адрес ос новного сетевого интерфейса и тип операционной си­ сте м ы . Зате м эта информация становится доступной из базы конфигурации через значе­ н ия переменн ых. Как и в любой другой переменной, эти значения могут ис пол ьзоваться для определения значений параметров или для расш ирения шаблонов.

852

Часть lV. Эксплуатация

Для определ е н ия всех фактов, связан н ы х с конкретной системой, может потребо­ ваться н екоторое врем я . П оэтому систе м ы СМ обычно кеш ируют факты , и не обяза­ тельно перестраивают кеш при каждом запуске . Если вы обнаружите , что в кон кретном потоке конфигурации встречаются устаревшие дан ные конфигурации , вам может потре­ боваться явно аннулировать кеш . В с е с исте м ы С М позволяют целевым маш инам добавлять знач е н ия в базу дан н ы х фактов л ибо путем включе н ия статического файла деклараци й , либо путем запуска спе­ циал ьного кода н а целевой маши н е . Эта фун кция полезна как для рас ширен и я типов и н формации , к которой можно получ ить доступ через базу данн ых фактов, так и для перемещения информации о статической конфигурации на клиентские ком пьютеры. Рекомендации на стороне клиента могут быть особенно полезны для управления об­ лач н ы м и и виртуал ьн ы м и серверам и . Вы просто назначаете маркеры уровня облачности ( например, теги ЕС2 ) , когда создается экземпляр, а затем система управления конфигура­ цией может загрузить соответствующую конфигурацию по этим маркерам . Однако имейте в виду последствия этого подхода для безопасности: клиент контролирует факты, которые он сообщает, поэтому убедитесь, что скомпрометирован н ы й клиент не может испол ьзо­ вать систему управления конфигурацией для получения дополнительн ых привилегий . В зависимости от с исте м ы С М вы можете вы йти з а рам ки с воего локального кон ­ те кста с помощью анал иза окружения переме нных или фактов. Помимо доступа к и н ­ формации конфигураци и для текущего хоста , в ы также можете иметь доступ к дан н ы м для других хостов и л и даже для анализа состоян и я самой базы конфигурации. Это по­ лезная фун кция для координации распределен ной системы, такой как кластер серверов.

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

Привязки П ривязки завершают базовую конфигурационн ую модель, связывая кон кретные на­ боры операци й с конкретн ы м и хостам и ил и груп пами хостов. В ы также м ожете связы­ вать операции с динам ическим набором клиентов, которы й определяется знач е н и е м факта или перемен ной . Системы С М также могут определять групп ы хостов, просмат­ ривая информацию в локал ьной системе управлен и я ресурсами ил и вызывая удаленную процедуру согласно интерфейсу API . В дополнение к основной роли связывания, привязки в большинстве систем СМ так­ же действуют как переменные области . Эта фун кция позволяет настраи вать поведение на­ значаемых операций , определяя или настраивая значения переменн ых для целевых кли ­ е нтов. Дан н ы й хост может соответствовать критериям для множества разн ых привязок. Например, хост может находиться в определенной подсети, управляться определ е н н ы м

Глава 23. Управление конфигурацией

853

отделом или выпол нять явно назначен ную рол ь ( например, веб-сервер Apache). Система СМ уч итывает все эти факторы и активирует операции, связа н н ые с каждой привязкой. П осле того как вы н астроили привязки для хоста, вы можете вызвать меха н изм » на­ строить все » с исте м ы верхнего уровня ваш ей системы С М , чтобы система СМ иденти­ фици ровала все операц и и , которые должн ы вы пол н яться н а целевом хосте , и вы пол ­ нить и х п о порядку.

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

Среды Часто бывает полезно разделить клиенты , управляемые конфигурацие й , на несколько » м иров » , таких как традицион н ые категории разработки , тестирования и производства. Крупн ые инсталл я ции могут создавать е ще более тон кие различия для поддержки таких процессов, как постепенное («ступенчатое» ) внедрен ие нового кода в производство. Эти разные м и р ы , » среды » , известны как внутри, так и вне конте кста управл е н ия конфигурацией . Кажется , это единствен н ый терм и н , с которым согласн ы все системы упрам е н и я конфигурацией . П р и правильной реал изации среды — это не просто группы клиентов. Это допол н и ­ тел ьная ось изменения , которая может пом иять н а нескол ько аспе ктов конфигураци и . Например, среды разработки и производства могут вкл ючать веб-серверы и серверы баз дан н ых, но детали того, как эти роли определе н ы , могут различаться в разн ых средах. Например, для базы дан н ых и веб-сервера обычно испол ьзуется один и тот же ком ­ п ьютер в среде разработки . Однако производствен н ая среда обычно им еет нес кол ько серверов каждого типа. П роизводствен ная среда также может определять типы серверов, которых нет в среде разработки, н апример те серверы , которые выпол няют баланс иров­ ку нагрузки или действуют как прокси -серверы в дем илитаризованной зон е . Система окружающе й с реды обы чно расс матри вается к а к с вое го рода кон вейер дл я кода кон ф и гураци и . В качестве м ы сл е н н ого эксперимента можно себе п редста­ вить, что фикс ированные группы клиентов испол ьзуют среды разработки , тестирования и производства. Поскольку данн ая база конфигурации проверена, она распространяется от одной среды к друго й , обеспечивая должную проверку изме н е н и й до того , как о н и достигнут важне й ш их производствен н ых систе м . В большинстве систем С М разн ые среды — это разные верс и и одной и той ж е кон ­ фигураци и . Если в ы являетесь пользователем G it , сч итайте и х тегами в репозитори и Git: тег разработки указывает на самую последнюю версию базы конфигурации , а производ­ стве н н ы й тег может указывать на фиксацию состоян и я , которая была сделана н есколько недел ь назад. Теги продви гаются вперед по мере того, как выпуски проходят через ста­ дии тестирова н ия и развертыван ия.

Часть lV. Эксnлvатация

854

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

26.

Учет и регистрация кл иентов П ос кол ьку систе м ы С М о nределя ют м ножество с n особов раздел е н и я кл и е нтов на категор и и , общи й nарк м аш и н nод уnравлением конфигурации должен быть четко оnределен. Реестр управляемых хостов может храниться в обыч ном файле или в соответ­ ствующей реляционной базе дан н ых. В некоторых случаях он может даже быть nолно­ стью динам и ч н ы м . Точ ный механизм, nосредством которого код конфигурации распределяется , анализи­ руется и вы nол няется, зависит от систем С М . Большинство систем на самом деле nредо­ ставляют несколько вариантов в этом отношении. Укажем несколько общих nодходов. •

Н а каждом клиенте неnрерывно работает демон , который загружает код конфигу­ рации с назначен ного сервера СМ ( или rpyn n ы серверов). Це нтрал ьн ы й сервер С М передает дан ные конфи гурации каждому кл иенту. Этот процесс может выnол няться no регулярному рас n исан и ю ил и может быть и н и ци­ ирован адми н истраторам и . Каждый управляе мый хост заnускает кл иент, который nериодически nросы nается , считывает дан н ы е конфигурации из локал ьного клона базы конфигурации и при­ меняет соответствующую конфигурацию к себе . Централ ьного сервера конфигу­ рации н ет.

Конфигурацион ная информация является закрытой и часто включает в себя такие се креты , как nарол и . Для защиты этих данных, во всех систе мах СМ оnределяется сnо­ собы ауте нтификации кл иентов и серверов, а также алгоритм ы ш ифрования конфиде н­ циал ьной информаци и . Ч тобы добавить новый кл и е н т в среду уnравления конфи гурацией достаточ но только и нсталл ировать соответствующее клиентское nрограмм ное обеспечение. Есл и среда на­ строена на поддержку автоматической начальной загрузки , новый клиент может автома­ тически связаться с сервером конфигураци и , nройти аутентификацию и ин ициировать nроцесс настройки. Механизмы инициализации, сnецифичные для о nерационной систе­ м ы , обыч но заnускают эту цеnочку событий nри nервом заnуске клиента. Этот nоток nо­ казан на рис. 23. 1 .

Первая загрузка нового клиента

role = web environment = production

Клиент начинает свою работу и запускает агента в виде фонового процесса

Клиент загружает и инсталлирует агента

Агент СМ автоматически аутентифицируется и регистрируется на сервере СМ

Агент СМ применяет список привязок

Сервер идентифицирует привязки для производственного веб-сервера

Рис. 23. 1. Процесс инициализации нового клие11та , управляемого СМ

Глава 23. Управление конфигурацией

855

2 3 .4. СРАВНЕНИЕ ПОПУЛЯРНЫХ СИСТЕМ СМ В настоящее вре м я четыре основных и грока владеют р ы н ком общего управления конфигурацией в системах U N I X и Linux: AnsiЫe , Salt , Puppet и Chef. В табл . 2 3 . 1 при­ ведена общая информация об этих пакетах. Таблица 23. 1 . Основные системы управления конфигурацией Яз ыки и форматы

Демоны

С и стем а

Веб-сайт

Реализация

Конфи гурация

Ша блон

Сервер

Клиент

AnsiЫe

a n s i Ы e . com

Python

YAML

Jinja

Нет

Нет

Salt

s a l t s t a c k . com

Python

YAML

Jinja

Puppet

puppe t . c om

Ruby

Настра иваемая

ERB•

П о выбору П о выбору

П о выбору П о выбору

Chef

c he f . i o

Ruby

Ruby

ERB

П о выбору

Да

• ERB (embedded Ruby) является основным синтаксисом для встраивания кода Ruby в шаблоны .

Все эти пакеты относ ител ьно новые. Сам ы й стары й , Puppet, дебютировал в 2005 г. О н по- прежн ему прете ндует на самую бол ьшую дол ю на р ы н ке , в знач ительной сте ­ пени из-за свое го ран него старта. Пакет Chef б ыл вы пущен в 2009 r. , Salt в 20 1 1 г. и AnsiЫe в 20 1 2 r. Общая категория программного обеспечения для управления конфигурацией была впервые разработана в виде систе м ы C FEngine Марка Берджесса ( Mark Bergess) в 1 993 r. C F Engine по- прежнему существует и продолжает активно развиваться , но бол ьшая часть ее пользовател ьс кой базы была завое вана более новы м и систе мам и . Для пол учения те­ кущей информации с м . c feng i n e . с от. Компания M icrosoft имеет собствен ное решение С М в виде PowerSl1ell Desired Stat e Configuration. Хотя эта система относится к м иру Windows и в первую очередь предна­ значена для настройки кл иентов Windows, M icrosoft также опубл и ковала расш ирения для настройки систем Linux. Стоит отметить, что все четыре с истем ы , перечисл е н н ы е в табл . 2 3 . 1 , также могут настраивать клиентов Windows. В ряде проектов основное внимание уделяется кон кретным подобластям управле ния конфигурацией , в частности , внедрению новой системы ( например, СоЬЫеr) и разверты­ ван и ю программного обеспечения ( например, Fabric и Capistrano). Общее предложе н и е этих систем закл ючается в том , что, более тщательно моделируя кон кретную пробле мную область, они могут обеспечить более простой и целенаправленный набор функций. В зависи м ости от своих потребностей вы можете обнаружить (или не обнаружить) , что эти специализированные системы обеспечивают разумную норму прибьт и от ваш их и н вестиций в обучение. Общие систе м ы управления конфигурацией , подобн ые описан­ ным в табл. 2 3 . 1 , не вполне подходят для всех возможн ых действий. Систе м ы , приведен н ые в табл . 2 3 . 1 , работают практически с любым типом современ­ ных U N IХ-совместим ых кл иентских маши н , хотя всегда есть граница поддержки. Пакет Chef и меет скром ное преимущество в совместимости и поддержи вает даже операцион ­ ную систему AIX. —

Ш Дополн ительную информацию о контей нерах см. в главе 25 . Поддержка операцион ной систе м ы на стороне сервера конфигурации (дл я тех си­ сте м , которые ис пол ьзуют сервер конфигураци и) более огран ичена. Например, пакет Chef требует для своего сервера и нсталляции операцио н н ых систем RH EL или Ubuntu.

Часть lV. Эксплуатация

856

Контейнерные версии сервера могут работать везде , поэтому их использова н ие не я в ­ ляется настолько серьезным препятствие м , как это может показаться на первый взгляд.

Терминология В табл . 2 3 . 2 показан ы терм и н ы , испол ьзуемые в каждой из рассматр и ваем ы х нами систем С М для объектов, указанных в разделе «Элементы управления конфигурацией » . Таблица 23 . 2 . Управление конфигурацией Rosetta Stone AnsiЫe

Наw термин

О перация Тип опера�ии Спи сок операций П араметр П ривязка

Salt

Puppet

Chef

С остояние сJ)ун кц� я . . . . . . . Состояния П араметр Главный файл

Ре сурс Ресурс Тип ресурса , �роfЗСi�,це р . �рОfЗСiЙде р Класс , манифест Рецепт С войство, юрибут Атрибут Класси фикация, объявление С писок исполняемых рецептов Мастер С ервер Управление С ерверный хает М астер Ми ньон Агент, узел Узел Хо ст Кл иентский хает в злов г уппа уз нтская руппа па ппа и Роль Г … . Гр �о у l(л � ру .. . . . … �р� Переменная П еременная П араметр , переменная П еременная Атрибут Фап Фа п Фап Автоматиче с кий Уведомления Уведомление Уведомление Реквизит Уведомление одписка остояние к и П одписка П С . ()!5р�!5о:гч � … … …. ()!)р�оо:гч� одуль ормула оль Пакет К нига ре цептов Ф Р М GitHub ница у алактика пакетов епозиторий К Супермаркет Р Г з Задача . .. fvloдy� ь Задач и П араметр С ценарий (книга)

Бизнес — модел и Все продукты, которые мы обсуждаем , являются пакетами модели freemium. Это оз­ начает, что базовые систе м ы бесплатны и доступн ы по л и цензии с открытым исходным кодо м . Однако каждая такая система поддерживается со сторон ы отдел ьной организа­ ции, которая продает услуги по поддержке, консалтин гу и допол нительные пакеты. Теоретически у поставщиков есть потен циал ьн ая мотивация не раскрывать исходны й код полезных функци й , чтобы сти м улировать допол н ительные продажи . Однако в об­ ласти управления конфигурацией этот эффект н е был очевидны м . Версия программ ного обеспече н ия с открытым исходным кодом я вляется полнофункциональной и более чем достаточной для большинства организаций . Допол нительные услуги в основном представляют интерес для крупных органи заций. Если ваша организация попадает в эту категорию, вы можете оцен ить системы управле­ ния конфигураци е й в отноше н и и функциональности и ценообразования предложен и й с полным набором стеков. Основными преимуществами являются, как правило, поддерж­ ка, и ндивидуальная разработка, обучение, графические интерфейсы , отчеты и решения для мониторинга. В этой книге м ы обсуждаем только основные, бесплатные версии.

А рхитектурн ые пара метры Теоретически с исте м ы С М н е требуют серверов. П рограммное обеспечен ие может работать только на с конфигурированн ых ком пьютерах. Скопируйте базу конфигурации

Глава 2 3 . Управление конфигурацией

857

на кажды й целевой хост и просто запустите команду, чтобы сказать: » Я здесь, н астройте меня в соответствии с этими спецификациям и » . На практике приятно не беспокоиться о деталях получения и нформаци и о конфи­ rураци и , в ыталк и ваемой кл иентам и выполняемой и м и . Систе м ы СМ всегда создают некоторые условия для централизованного управл е н ия , даже если главн ы й ком пьютер определяется как » где бы вы ни вошли , вы имеете клон базы конфигурации » . Пакет AnsiЬe н е испол ьзует демоны вообще ( кроме s shd) , чем о н и привлекает с воей простотой . Выполнение конфигурации происходит, когда админ истратор ( ил и задание cron) на сервере запускает команду ansiЫe-playbook. Команда ansiЫe-playbook вы пол н яет соответствующие удал е н н ы е команды по протоколу S S H , не оставляя сле ­ дов с воего п р исутствия н а кли е нтской м а ш и н е посл е завер ш е н и я кон ф и гура ц и и . Единстве н н ы м и требован и я м и для кл иентских ком пьютеров я вляются их доступность по протоколу S S H и установленная версия Python 2 . 2 Пакеты Salt , Puppet и Chef вкл ючают в себя к а к серверн ы е , так и клиентские демо­ ны. В ти пичных сценариях развертывания демоны запускаются с обеих сторон отноше­ ний, и это среда, которую вы увидите в большинстве докуме нтации . Можно запус кать каждый из этих пакетов без сервера, но эта конфигурация менее распространена. Заман ч иво предположить, что с исте м ы С М с демонами должн ы быть более тяже ­ л ы м и и сложн ы м и , чем те , у кого их нет (т. е . AnsiЬe) . Однако это не обязател ьно так. В системах Salt и Puppet демоны я вляются стимулятора м и и катали заторам и . О н и по­ лезн ы , но н еобязател ьн ы , и они не изменяют фундаментал ьную архитектуру систе м ы , хотя и позволя ют использовать н е которые допол нительные фун кци и . Есл и хотите , в ы можете запус кать эти системы без демонов и коп ировать базу конфигурации вруч ную. У с исте м ы Salt даже есть S S Н — режи м , которы й работает а н ал о г и ч н о AnsiЫe . Уч иты вая это, зачем вам куча допол нительных демонов? По нес кольким причинам. •

Эта схема работает быстрее. Разработч ики пакета AnsiЬe упорно трудятся , чтобы преодолеть ограничение производительности, налагаемое протоколом SSH и отсут­ ствием на стороне клиента кеш ирования, но он по-прежнему заметно более мед­ ленный, чем Salt. Когда вы ч итаете книrу о систем ном админ истрирован и и , десять секунд кажутся незначительными. В разгар устранения сбоя эта задержка кажется бесконечной , особенно когда ее испытывают десятки или сотн и клиентов. Н е которые фун кции не могут существовать без цен трал ьной коорд и н а ц и и . Например, система Salt позволяет клиентам уведомлять сервер конфигурации о со­ бытиях, таких как переполнение диска. Затем вы можете реагировать на эти собы­ тия с помощью обыч ных средств управления конфигурацией. Наличие центральной точки подключения облегчает различ ные функции обмена дан н ы м и между средами. Тол ько демон на стороне сервера действител ьно я вляется поте н циальным источ ­ н и ком адм и н истративной сложности . С исте м ы С М работают, чтобы застав ить клиент загружать операцию онлайн, независимо от того, задействован л и демон . Наличие активных агентов как на клие нте , так и на сервере открывает м ножество архитектурных возможностей , недоступных в односторонних конфигурациях.

Что касается архитектуры, то система Chef отличается от остальных с истем управления конфиrурациям и тем , что ее серверный демон является элементом верхнего уровня в кон­ цептуал ьной модел и. Системы Salt и Puppet служат для конфигурирования данных непо28 зависи мости от системы вам может понадобиться оди н или д ва дополн ительных модуля на язы­ ке Pyt hon. Например, Fedora требует пакет python-dnf.

Часть lV. Эксплуатация

858

средствен но из обычных текстовых файлов на диске ; для внесения изменений вы должны просто отреда кти ровать фа йл Напротив , сервер Chef является непрозрачн ы м и автори­ тетн ым источн и ком информации о конфигурации. И зменения должны быть загружен ы н а сервер с помощью команды knife или о н и не будут доступ н ы для клиентов. (Тем н е менее даже систе ма Chef имеет режим работы без сервера в форме команды chef-solo. ) М ы перечислил и выше преимущества серверных систем вовсе не для того, чтобы спо­ собствовать их повсеместному внедрению, а просто для того, чтобы обозначить основную л и н и ю раздела среди систе м С М , которая проходит между системой Chef и всем и осталь­ н ы м и . Системы AnsiЫe, Salt и Puppet имеют одинаковую, умеренную степень сложности . Система Chef требует знач ител ьно больших ин вестиций для обслужи вания и освое н и я , особенно когда в смесь добавляется обширная линейка допол нител ьных модулей. Из-за своей бессерверной модели система AnsiЫe часто упом инается как » простой ва­ риант» для управле н ия конфигурацией. Но на самом деле основн ые архитектуры Salt and Puppet не менее доступн ы . 3 Не п ере водите их в категори ю дополн ительных вариантов. Обратное также верно: система AnsiЫe больш е , чем просто приукраше н ная стартовая система для н е о п ы т н ы х с и сте м н ы х адми н истраторов. Это вполне приемлемый вариант для сложных организаций, хотя ее н изкая производительность в этом контексте стано­ вится е ще бол е е очевидно й . .

Параметр ы я з ык а Систем ы AnsiЫe и Salt написаны на язы ке Python. Системы Puppet и Chef написаны на языке Ruby. Н о , кроме с исте м ы Chef, эта информация , вероятно , не так актуал ьна, чем может показаться на п ер в ы й взгляд. В типич ной конфигурац и и с истем AnsiЫe или Salt код Python н и где н е поя вляется. Обе э т и с и сте м ы в качестве ос н о в ного язы ка конфигурации испол ьзуют YA M L (ал ь­ тернативный с интаксис для выражен и я представления объектов JavaScript , или J S ON ) . YAM L — это п росто структу р и рова н н ые дан н ы е , а н е код, поэтому о н и н е и м е ют соб­ стве н ного поведе н и я , отл и ч ного от и нтерпретации дан н ых, назначе н н ых систе м о й управл е н и я кон ф и гура ц ие й . Вот простой

пример кода систе м ы Salt , в котором подключается и запус кается служ­

ба S S H . s s h . s e rve r . r u n s s h : s e rv i c e : — n ame :

s shd

— runn i n g — еnаЫе :

t rue

Чтобы сдел ать файл ы УА М L более динамически выразительны м и , систе м ы AnsiЬle и Salt до п олн я ют их систе м о й шаблонов J i nja2 в качестве препроцессора.4 Систе ма J i nja и меет свои корн и в языке Pytl1011 , но это н е просто оболочка Python. П р и испол ьзова­ н ии она ведет себя как с истема шаблонов, а не настоящий язык програ м мирован ия.

‘ Можно было бы при вести убедител ьн ы й аргумент в пользу того, что система Salt я вляется самой п ростой системой среди всех, есл и не обращать внимания на ее передовые средства и нескол ько своеобразную доку м ентаци ю. 4Справедли вости ради от метим , что систем а Salt на самом деле не за висит от формата и препро­ цессора, а также а втомат и ч е с к и поддержи вает несколько конвейеров ввода (вкл ючая исход н ы й Pythoп ) . Однако отклонение от проторен ного пути J i nja и YAM L означает отказ от документаци и и изоляцию от остального м и р а . Вероятно, это решение лучше всего отложить на будущее , пока вы не освоите систему Salt .

Глава 23. Управление конфигурацией

859

Даже система Salt , которая в большей степени полагается на Jinja, чем AnsiЫe , предосте­ регает от помещен ия излишней логики в код Jinja. Суть в том , что , есл и вы не п и шете собстве н н ы е тип ы операций или не использу­ ете явные вставки кода на Python , вы не столкнетесь с бол ьш и м количеством кода на Python в пакетах AnsiЫe и Salt.5 ( Расш ирение систе м ы С М с помощью вашего собствен ­ ного кода на самом деле может быть довольно легким и весьма полез н ы м . ) В качестве с воих основных систем конфигурации систе м ы Puppet и Chef используют предметно-ориентированные языки на основе Ruby. Версия языка в системе Chef очень по­ хожа на аналог управления конфигурацией на языке Rails из мира веб-разработки. Иначе говоря , он бьm расширен нескольки м и концепциями , предназначен н ы м и для упрощения управлен ия конфигурацией, но по-прежнему является узнаваемым Ruby. Например: s e rv i c e ‘ s shd ‘ do s upp o r t s : r e s t a r t = > t ru e , : s t a t u s = > t ru e a c t i on [ : еnаЫ е , : s t a r t ] end

Больш инство задач управления конфигурацией могут быть реш е н ы без углубления в язык Ruby, но при необходим ости вам доступна вся мощь этого языка. В ы оцените эту скрытую глубину е ще бол ьш е , когда станете лучше разбираться в языке Ruby и с и ­ стем е Chef. В отл и ч ие от этого , разработч и к и систе м ы Puppet довол ьно м н ого п оработали над концептуальной независимостью от языка Ruby и использовали е го тол ько как уро­ вен ь реализации. Хотя язык систем ы Puppet » под капотом» остается языком Ruby и до­ пускает вставку кода на языке Ruby, он и меет с вою собствен ную структуру, которая бо­ лее сродни декларативной системе, такой как YAM L, чем языку програм мирован ия . s e rv i c e { » ssh» : e n s u r e => » r unning » , еnаЫе => » t ru e «

П о нашему мнению, архитектура систе м ы Puppet не предоставляет админ истраторам н и каких преимуществ. В место того чтобы позволить вам испол ьзовать язык Ruby, систе­ ма Puppet просто определяет свой собствен н ы й изолирован н ы й м ир .

Варианты уп ра вления зависимостями Н езависимо от того , как ваша система управления конфигурацией структурирует свои дан н ы е , рабочи й список для дан ного клиента в конечном итоге с водится к набо­ ру операций для выполнения клиентом. Некоторые из этих операций зависят от поряд­ ка испол н е н и я , а некоторые — нет. Например, рассмотрим следующие задачи систе м ы АпsiЫе для создан ия учетной записи пользователя w w w , которая может испол ьзоваться для владения файлам и веб-приложения. — name : E n s u re t h a t www g roup e x i s t s g r oup : n ame=www s t a t e = p r e s ent

1Джон Корбет (John CorЬet) , оди н и з наших технических рецензентов, согласен с тем , что эти си­ стем ы не демонстрируют м ного кода на языке Python пока с итуация н е станет ужасной . «В этот момент, — добавляет он , — знакомство с трассировкой Python и представлениями структуры дан ­ н ы х очен ь помогает» . …

Часть lV. Эксплvатация

860 — n ame : E n s u r e t h a t www u s e r e x i s t s u s e r : n ame =www group=www s t a t e=pre s e n t c r e a t e home=no

М ы хоти м , чтобы пользователь www имел собственную выделенную группу, также на­ зьr ваемую www. П ол ьзовательск и й модуль AnsiЫe не создает групп ы автоматически, по­ этому м ы должны сделать это на отдел ьном этапе . И создание груп п ы должно предше ­ ствовать создан и ю учетной зап иси www ; было бы ошибкой указывать несуществующую группу при создании пользователя . Систе ма AnsiЫ e вы пол н яет операци и в том порядке , в котором о н и представл е ­ н ы в конфигураци и , поэтому этот фрагмент конфигурации работает просто отл и ч но. Система Сhеf тоже работает таким образо м , отчасти потому, что гораздо сложнее изм е ­ н ить код, ч е м данн ые . Даже есл и бы это было н еобходимо, система Chef н е могла бы надежно разделить ваш код на куски и создать сборки по своему усмотрен и ю . Напротив , с исте м ы Puppet и Salt позволяют я в н о объя влять зависимости. Например, в системе Salt эквивалентн ы й набор состоя н и й будет иметь следующий вид. www- u s e r : user . present : — n ame : www — g i d : www — c r e a t e home : f a l s e — r e qu i r e : — www-gr oup www — g r oup : g r oup . pr e s e n t : — n ame : www

Здесь для создан и я драматического эффе кта м ы и н вертировал и порядок операци й . Но из-за объявления r e qu i r e операции выпол н я ются в правильном порядке незави­ симо от того, как они отображаются в исходном файле. Следующая команда применяет описанную выше конфигурацию: $ sudo salt test- sys tem s tate . apply order- test

t e s t — s y s t em : ID: Fun c t i on : N ame : Re s u l t : Comme n t : Started : Du r a t i on : Change s :

www — g r oup g roup . p r e s e n t www T rue Group www is p r e s en t and up t o d a t e

ID: Fun c t i on : Name : Re s u l t : C omme n t : Started : Dura t i on : Change s :

www — u s e r u s e r . p r e s e nt www T rue U s e r www is p r e s e n t and up t o d a t e

2 3 : 3 0 : 39 . 825839 3 . 1 8 3 ms

23 : 30 : 39 . 829218 2 7 . 4 3 5 ms

S umma r y f o r t e s t — s y s t em

Глава 2 3 . Уп равление конфигурацией

861

Succe e de d : 2 Fa i l e d : О Total s t a t e s run :

2

П араметр r e qu i r e может быть добавле н к любой операции ( «состоян и ю » в систе­ ме Salt) , чтобы гарантировать, что именованные предусловия выпол н я ются до текущей операци и . Система Salt определяет несколько типов отноше н и й зависимости , и декла­ рации могут появляться по обе сторон ы от отношения . Систем а Puppet работает аналогично. Она также помогает облегчить сложности при объявлении зависимостей , в ыводя их автоматически в типичных ситуациях. Например, пользовательская конфигурация, которая называет определенную группу, автоматически становится зависимой от ресурса, которы й настраивает эту группу. Прекрасно! Итак . . . Зачем явно объявлять свои зависимости, когда порядок н астройки кажется естестве н н ы м и легким? По- видимому, м ногие адми н истраторы задавали этот вопрос, так как систе м ы Salt и Puppet перешли к гибридной модели зависи мосте й , в которой по­ рядок представления и меет знач е н ие . Тем не менее это всего лишь фактор внутри дан ­ ного файла конфигурации; зависи мости м ежду файлами должны быть объявлены явно. Основное преимущество декларирован ия зависимостей закл ючается в том , что он делает конфигурации более устойчивым и и явными. Система СМ не обязана прерывать процесс н астройки при первых признаках неисправности , поскол ьку знает, какие по­ следующие операции могут быть затронуты сбоем . Она может прервать одн у цепочку за­ висимосте й , позволяя другим продолжать функционирование. Это приятно, но, на наш взгляд, все же не оправдывает допол н ительной работы по объявлению зависимостей. Теоретически система С М , которая знает информацию о зависимостях, может распа­ раллеливать выполнение независ и м ых цепей управления на конкретном хосте . Однако ни Salt , ни Puppet не п ытаются соверш ить этот подвиг.

О бщие комментарии п о поводу систему Chef М ы видели разверты вание основных пакетов С М в организациях разных размеров, и все они проявляют тенден цию к росту э нтропии. Советы по орга низации этих паке­ тов приведе н ы в разделе 2 3 . 5 . Тем не менее фундаментальное правило гласит: избегайте сложности , которая не приносит пользы вашей среде . На практике это означает, что вам нужно четко понимать, применять систему Chef или нет. Систем а Chef оперирует крупн ы м и масштабами. Ч тобы получить максималь­ ную отдачу от нее, вы должны иметь: • •

• •

сотни или тысячи ком пьютеров в управлении конфигурацие й ; адм и нистративный персонал с неравномерными привилегиями и опытом (система внутренних разрешений Chef и н есколько интерфейсов здесь весьма полезны ) ; специальную систему отчетов, жалоб и соблюдения нормативных требований; терпение , н еобходимое для обуч е н ия новых членов команды, н е имеющих опыта работы с с истемой Chef. Конечно, вы можете свободно работать с системой Chef на отдельной машине. Никто не запрещает! Но вам все равно придется нести зна­ ч ительные накладные расходы на м н огие функции уровня предприятия , которые в ы не используете. Они заш иты в архитектуру и докуме нтацию.

Нам нравится система Chef. Эта полная , надежная и масштабируемая систем а луч ш е , чем ее кон куренты . Но в глубине душ и м ы признае м , что это просто еще одна система управления конфигурацией , которая выполняет те же основные функци и , что и AnsiЬe ,

862

Часть lV. Эксплуатация

Salt и Puppet . Держите с истему Chef на примете и не поддавайтесь соблазну внедрить ее только потому, что «она самая мощная » ( ил и потому, что «она испол ьзует язык Ruby» , если на то пошло) . М ы обнаружил и , что при влечение новичков к работе с систе мой Chef может стать серьезной проблемой, особен но для тех , кто не и меет опыта управления конфигураци ­ ей. Эта система требует от м ы шления разработчи ка бол ьше, чем друrие систе м ы . Здесь будет полезе н предварительн ы й опыт в области программирования. Концепция порядка следования атрибутов в системе Chef я вляется мощной , но так­ же может оказаться источн и ком разочарования. Своеобразная комби нация кул инарн ых тер м и нов и и нтер н ет — м е мов раздражает и не я вляется и нформати вной. Разре ш е н и е зависимостей между кул и нарны м и кни гами может оказаться сложн ы м ; иногда проис­ ходит разрыв зависи м остей между стар ы м и и новы м и версиями, и тогда во всех ваш и х системах возникают проблем ы , если вы забыл и привязать все ваш и зависимости к опре­ делен ной верс и и .

Общие комментарии по поводу системы Puppet С истема Puppet — старей шая из четырех основных систем СМ и единстве нная , име­ ющая большую и нсталлированную базу. У нее м ного пользователей, множество встроен ­ ных модулей и бесплатный веб-и нтерфейс. Те м не менее она довольно быстро уступает свою долю р ы н ка более поздни м кон курентам. В качестве прочного середня ч ка систе ма Puppet находится под давл е н и е м с обоих кон цов р ы н ка. Она и звестна узки м и места м и на стороне сервера, которые вызы вают пробл е м ы при управлении тысячами хостов, а за последние пару лет нес кол ько круп­ ных ком па н и й , испол ьзовавш и х систему Puppet , отказались от нее ( наиболее п убл и ч ­ н ы м был случай компании Lyft , которая перешла на Salt ) . В н а ш и дн и такие масштаб­ н ые сценари и , похоже , луч ше обрабатываются с помощью м ногоуровневой сети Chef или Salt. В н и ше небольших ком пан ий систе м ы AnsiЬle и Salt создают серьезную кон куре н­ цию с воим и относительно н изким и барьерами для входа. Как уже говорилось, система Puppet н е является сложной . Однако она несет некоторы й исторический багаж, кото­ рый , как правило, мешает новичкам . Например, в ядро Puppet встроено относител ьно небольшое количество операций. Для дополнения набора базовых конфигураций боль­ ш и нству организаций придется искать модул и , предоставленные пользователями. П о нашему субъективному впечатлен и ю , с истема Puppet пережила нескол ько фаль­ стартов на ран ней стадии своего проектирования и развития . Хотя разработчи ки с исте­ мы Puppet интенсивно работал и над исправлением этих недостатков, история и обрат­ ная совместимость — неизбежн ые спутники текущего продукта. С итуаци ю усложнило то, что система Puppet превратила золотое сокровище, язык Ruby, в кусок угл я , которы м является язык конфигурации Puppet . Вероятно, это был о разум ное реш е н и е в 2005 г. , когда будущее языка Ruby было неяс н ы м , а каркас Rails еще не появился на сцене и н е завоевал популярность. В наши дни язык конфигурации Puppet п росто кажется абсурдны м . Н и одна и з эти х проблем н е является непреодол и м ы м пре пятствие м , н о у систе м ы Puppet , похоже, н е т ясного и убедительного пре и м ущества, которое могло бы уравно­ весить ее недостатки. По наш и м данн ы м , за последние несколько лет не появилось н и одного сравнительного обзора, рекомендующего систему Puppet .

Глава 2 3 . Управление конфигурацией

863

Конечно, есл и вы унаследовали существующую и н сталл я ц и ю с и стем ы Puppet, нет необходимости н ач и н ать искать ее н е м едле нную зам е н у Систем а Puppet р аботае т от­ лично; различия между этими системами в основном я вл я ются вопросом стиля и допол ­ нительных пре имуществ. .

Общие комментарии по поводу систем AnsiЫe и Salt AnsiЫe и Salt это хорошие систе м ы , и м ы рекомендуем один из этих вариантов для большинства организаций. М ы более подробно рассмотрим обе эти с исте м ы в разделах » В веде н и е в с истем у AnsiЫe » и » Введе н ие в систему Salt » . В каждом из этих разделов рассматри вается с и н ­ таксис конфигурации систе м ы и общий стиль повседневного и с п ол ьз ова ния AnsiЫe и Salt выглядят обманчиво похожим и вне ш не гла вн ы м образом потому, что они по умолчанию используют YAM L и J inj a в качестве своих форм ато в Однако под ка­ потом они совершенно разные. Соответствен но, мы отложим срав н е н и е с истем AnsiЫe и Salt , пока не обсудим их более подробно. Однако, прежде чем изучить сами систе м ы , кратко обсудим формат YAM L. —

.

,

.

Ода УА М L Как упоминалось ранее, формат YAM L я вляется п росто ал ьтернатив н ы м си нтакси­ сом для формата J S O N . Например, формат YAM L для с и сте м ы AnsiЬle6 — n ame : I n s t a l l cpdf on c l oud s e rve r s h o s t s : c l oud b e c ome : yes tas ks : — n ame : I n s t a l l ОСАМL p a c kages p a c kage : n ame = { { i t em } } s t a t e= p r e s e n t wi th i t ems : — gma ke — ocaml — o c aml — opam

так отображается в формат J SON : [{

» n ame » : » I n s t a l l cpdf оп cl oud s e rve r s » , » h o s t s » : 1 1 c l o ud 11 , » b e come » : » y e s » , «tasks» : [ { » n ame » : » I n s t a l l ОСАМL p a c k a ge s » , » p a c kage » : { » name » : » { { i t em } } » , » s tate » : «present » , }’

» w i t h_i t ems » : [ » gma ke » , » o c aml » , » o c aml — opam» ] }] }]

В м ире J S O N списки обрамля ются квадратными с кобка м и , а хе ш и — ф и гурны м и . Двоеточие отделяет хэш- ключ от его значен и я . Эти ра:щел ител и могут появляться и в 6 Теоретически документ в формате YAM L должен начинаться с трех тире в п ервой строке , и доку­ ментация AnsiЫe часто следует этому соглашению. Однако эта начальная строка документа YAM L обычный рудимент. Насколько нам известно, ее можно безоп ас н о исключ ить во всех случаях.

864

Часть lV. Эксплvатация

формате YAM L, но YAM L, помимо этого, понимает отступы для указан ия структуры , как в языке Python. Синтаксис YAM L отмечает элементы в сп иске префиксом в виде тире. Найдите время , чтобы проверить, что вы действител ьно понял и , как приведе н н ы й в ы ш е пример YA M L отображается в формат JSON , потому что систе м ы AnsiЫe и Salt на самом деле основаны на формате JSON . YAM L — это всего лишь сокращение. Далее мы рассмотр и м с истему АпsiЫе, поскольку ее версия YAM L более с воеобразна, но бол ь­ ш инство общих утвержде ний относится и к системе Salt. 7 Очевидно, версия YAM L более ч итабел ьна, чем версия JSON . П роблема закл ючается не в формате YAM L как таковом, а с корее в поп ытке выразить сложные систем ы управ­ ления конфигурацией в форме JSON . Формат YAM L хорош для представления простых структур дан ных, но это не и нстру­ мент, которы й хорошо масштабируется до произвольной сложности. Когда в модели по­ являются изъя н ы , они должн ы подвергаться множеству специальных исправлений. В приведенном выше примере уже содержится такое исправление. Вы заметил и это? p a c kage : name= ( ( i t em } } s t a t e=p r e s e n t

Н е обращайте в н и м а н и я на часть { { i t e m ) ) ; это просто рас ш и р е н и е J i nja. Проблема кроется в синтаксисе имя= зна чение, который на самом деле я вляется просто нестандартным сокращением для определения подхеша. package : name : ( ( i t em } } state : present

Или нет? На самом деле нет, потому что система AnsiЫe не допускает хеш-значе ния, которые нач инаются с расш ире н ия Jinja. Это выражение Jinja теперь должно вкл ючать в себя кавыч ки: p a c ka g e : name : » ( ( i t e m } } » state : present

А что есл и операция описывается в виде аргумента «свободной формы»? —

n ame : C r y f o r help s h e l l : e cho » P l e a s e , s i r , I j u s t want t h e s yn t a x t o Ье c on s i s t e n t » args : warn : n o

Визуально это выглядит не так уж плохо. Н о подумайте о том , что на самом деле происходит: s he l l — это тип операци и , а w a r n — параметр операции типа s he l l , так же как s t a t e — это параметр операции pa c ka g e в предыдущем примере. Итак, что там делает допол нител ьн ы й словарь a rg s ? Дело в том , что операции типа s he l l обыч но передается в качестве основного аргу­ мента сложная строка (для запуска команды оболоч ки), поэтому она была сделана спе­ циальн ы м ти пом операции , которой передается именно строка, а не хеш . Словарь a r g s н а самом деле я вляется свойством оболочки объекта задачи , а не операцией типа s he l l .

‘ Опять же , п р и верженцы системы Salt будут возражать, что Salt нел ьзя крити ковать за формат YAM L и язык Jinja, потому что у нее нет реальн ых завис и мостей от этих систе м . Вы можете и с ­ пользовать л юбую из нескол ьких ал ьтернатив. Все верно. В т о же время это очен ь похоже н а с и ­ туацию, когда вы не хотите нести ответственность з а правительство страны, потому что в ы за него не голосовали .

Глава 2 3 . Управление конфигурацией

865

Его содержимое тайно загружается в операци ю s h e l l от вашего и м е н и , чтобы выпол­ н ить всю работу. Нет проблем ; сохран яйте спокойствие и продолжайте. Но эта пута н и ца проявляется уже в относительно простом примере . Проблема не в этом кон кретном сценарии. Это постоян н ая смесь ограничени й , двус­ мысленностей и ком промиссов, которые необходимы для принудительного преобразо­ вани я дан н ых конфигурации в формат J SON . П ередается ли этот конкретный аргумент операции? Состоян и ю? Привязке? П оскольку иерархия JSON довол ьно большая , ответ редко бывает очевиде н . Посмотрите е ще раз на раздел I n s t a l l c p d f o n c l o u d s e rve r s в приведен ном выше примере . Очевидно ли, что ключевое слово w i t h i t ems должно стоять на том же уровне , что и pa c ka g e , а н е на том же уровн е , что и n ame и s t a t e ( которые на самом деле логически н иже p a c kage)? Возможно нет. Основополагающий зам ысел формата YAM L заслужи вает похвал ы : используйте су­ ществующий формат, которы й уже знают люди, и представляйте и нформацию о кон ­ фигураци и как данные вместо кода. Тем не менее эти систе м ы и м е ют с интаксические изъя н ы , которые, вероятно, не будут устранены в реальном языке программ ирования. 8 _

23.5. ВВЕДЕНИЕ в СИСТЕМУ ANSIBLE Систем а AnsiЬ!e н е и меет серверного де мона и н е устанавл ивает н а кл ие нтских ком пьютерах н икакого программного обеспечен и я . Таким образом , н а самом деле это всего л и ш ь набор команд (в первую очередь, ansiЫe-playbo o k , an s iЫ e — vaul t и ansiЫe), которые необходимо инсталлировать в любой с истеме, из которой вы хоти­ те управл ять клиентами . W Дополнительную информацию о репозитории EPEL с м . в разделе 7 . 5 . Стандартн ые пакеты уровня операцион ной с исте м ы ш ироко доступн ы для AnsiЫe , хотя и мена пакетов варьируются от с исте м ы к системе. В с истемах R H E L и CentOS н е ­ обходимо убедиться, что в серверн ых системах в кл ю ч е н репозитори й E P E L. К а к и в большинстве случаев, пакеты, специфичные для операцио нной с исте м ы , часто оказы­ ваются несколько устаревшими по отношению к основному коду. Если в ы не планируе­ те отказаться от управления пакетами, систему АпsiЬ!е легко установить из репозитория GitHub (a n s i Ы e / a n s i Ы e ) или с помощью команды pip. 9 П о умолча н и ю осн о в н ы м файлом конфи гураци и AnsiЫe я вл яется файл / e tc / ansiЫe/ ansiЫe . cfg. ( Как и дл я большинства устанавл и ваемых пакетов, в с истеме Free B S D каталог ansiЫe перемещен в каталог /usr/ local /etc . ) Файл ansiЫe . cfg по умолчани ю является коротким и просты м . Еди нстве н ное изменение, которое мы ре­ коме ндуе м , — добавить следующие строки в его конец. 1 0 8 Н есмотря на слабость формата YAM L, испол ьзуемого в системах управления конфигурацией, его спецификация н а самом деле довольно дл и н ная. Фактически она дли н нее специфи кации всего языка програ м мирования Go. ; П рограм м а pip это менеджер пакетов для я з ы ка Python. Попробуйте в ы п олн ить команду pip ins tall ansiЫe, чтобы загрузить последнюю версию из репозитория PyP I ( Python Package l ndex ) . Возможно, вам понадобится сначала установить программу pip с помощью ваше й системы управления дистрибутивами п а кетов. 1 0Л юбопытно, что в файле an s iЫe . cfg, а также в нескольких других файлах конфи гура ц и и AnsiЫe, используется форм ат ini , а не YAM L. М ы не знаем при ч и н ы этого я влен ия . —

.

часть lV. Эксплvатация

866

[ s s h_conne c t i on ] p i p e l i n ing t ru e =

Эти строки включают кон вейерную обработку — фун кцию S S H , которая знач итель­ но повышает производител ьность. Кон вейерная обработка требует, чтобы команда sudo на кл ие нтах не настраивалась на использование и нтерактивных тер м и налов; такое по­ ведение програм м ы установлено по умолчан ию. m Запуск програм м ы sudo без терминала управления описан в разделе 3 . 2 . Есл и дан н ы е конфигурации сохранены в файле /etc/ansiЫe, то вы дол ж н ы ис­ пол ьзо вать программу sudo для внесения измене н и й . При этом вы привязываете себя к одному конкретному серверу. Кроме того, вы можете легко настроить AnsiЫe для ис­ пол ьзования вашей собственной учетной записи. Сервер просто запускает оболоч ку ssh дл я доступа к други м системам , поэтому привилегии пользователя r o o t не нуж н ы , есл и вам не нужно запускать привилегированные команды на стороне сервера. К счастью , с истема AnsiЬe упрощает объединение систе м н ы х и л и ч н ы х конф и гу­ раци й . Не удаля йте общесисте м н ую конфигурацию; просто затен ите е е , создав файл -1 . ansiЫe . cfg, и укажите в нем расположе ние вашего каталога ресурсов и ролей. [ d e f au l t s ] inve n t o r y ro l e s_p a t h

= =

. /hos t s . / roles

Параметр i n ve n t o r y это сп исок кл иентских систе м , а r o l e s это па кеты , аб­ страгирующие разл ичные аспекты конфигурации кл иента. В бл ижайшее вре мя мы вер­ немся к обоим эти м темам. Здесь м ы определяем оба местоположения как относител ьн ые п ути, которые пред­ полагают, что вы будете испол ьзовать команду cd для перехода в каталог, содержащий вашу коп и ю базы конфигурации , и что вы будете следовать указа н н ы м соглашениям об име нах. Если вы предпоч итаете использовать абсол ютные пути , то учтите , что систе­ ма AnsiЫe также пон имает обозначение — , испол ьзуемое оболочкой для рабоч их катало­ гов пользователе й . (Систе ма AnsiЫe позволяет применять символ — почти везде .) —

При мер испол ьзова ния системы AnsiЫe П режде ч е м углубиться в детал и, м ы сначала рассмотрим небол ьшой при мер, демон­ стрирующий нескол ько основн ых операций AnsiЫe. В следующе м с п ис ке шагов мы с начал а установим и настрои м програ м м у sudo в новой системе (так как она может потребоваться , например, при работе с с исте мой Free B S D , в которой по умолчанию программа sudo не установлена). 1 . Установите пакет sudo. 2. Скопируйте стандартн ы й файл sudoers с сервера и установите е го локал ьно. 3. Убедитесь, что файлу sudoers назначены соответствующие права доступа и вла­ дельцы. 4. Создайте группу U N IX с именем sudo. 5. Добавьте все учетн ые записи системных адм инистраторов на локал ьном ком п ью­ тере в группу sudo. Эти шаги реализует приведе н н ы й н иже код AnsiЬle. Поскольку этот код предназна­ чен для иллюстрации нескольких свойств систем ы AnsiЫe , его не следует считать харак­ терн ы м примером .

Глава 2 3 . Управление конфигурацией

867

— n ame : I n s t a l l s udo p a c kage pac kage : name = s udo s t a t e=pre s e n t — name : I n s t a l l s udoe r s f i l e t emp l a t e : de s t : » ( [ s udoe r s_p a t h } ) » s r c : sudoe r s . j 2 owne r : root gr oup : whe e l mode : 0 6 4 0 — name : C r e a t e sudo g r oup g r oup : name = s udo s t a te=p r e s e n t — name : G e t c u r r e n t l i s t o f u s e rn ame s s h e l l : » c u t — d : — f l / e t c / p a s s wd » r e gi s t e r : u s e r l i s t — name : Add admin i s t ra t o r s t o t h e s udo group u s e r : n ame= ( ( i t em } } group s = s udo append= t rue wi t h_ i t ems : » [ ( admi n s } } » when : » ( ( i t em i n u s e r l i s t . s t dout_l i n e s } } «

Операторы обрабатываются по порядку, так же , как и в сценарии оболоч ки. В ы р а ж е н и я , з а кл ю ч е н н ы е в д в о й н ы е ф и гу р н ы е с ко б к и ( н а п р и м е р , { { a drni n s } } ) , я вляются расшире н ия м и переме н н ых. Система AnsiЫe и нтерпол и ­ рует факты аналоги ч н ы м образом . Такая гибкость управл е н и я параметрам и я вляется общей характеристикой систем управления конфигурацие й , и это одно из их основных преимуществ перед обычн ы м и сце нария м и . Вы определяете общую процедуру в одном месте , а параметры конфигурации — в другом. Затем с истема С М с водит воедино гло­ бал ьную спецификацию и гарантирует, что соответствующие параметры будут примене­ н ы к каждому целевому хосту. Файл sudoers . j 2 я вл яется ш аблоном Jinja2, который рас ш иряется , чтобы стать файлом sudoers на целевой маши н е . Ш аблон может состоять из статичес кого текста или может иметь внутрен н юю логику и собстве н н ые переменные. Шаблоны обычно хранятся вместе с конфигурация м и в том же репозитории G it , что позволяет совершать все сразу при испол ьзован ии конфигураций. Н ет необходимости поддерживать отдельный файловый сервер, из которого можно ско п ировать шаблон ы. Система управления конфигурацией использует мя инсталляции шаблонов существую­ щий доступ к целевому хосту, поэтому управление учетными дан н ы м и необходимо на­ страивать только один раз. Мы срезал и пару острых углов. П ол ьзовател ьс кий м одул ь АпsiЫ е , испол ьзуе м ы й здесь м я доба вл е н и я учетн ых записей с исте м н ых адм и н и страторов в U N IХ- группу s u d o , обычно гарантирует, что указан ная учетная зап ись существует, и создает учетную зап ись, если ее ранее не было. В дан ном случае мы хотим воздействовать тол ько на уже существующие учетные зап иси, поэтому вынужден ы вруч ную проверять наличие каж­ дой учетной записи, прежде чем разреш ить пользовател ю изменять ее . 1 1 «

«

1 1 8 типичном сценарии система управления конфигурацией отвечает за настройку учетных зап и ­ с е й администраторов, а также доступ к программе sudo . В специфи кациях конфигурации для обе­ и х фун к ци й , с корее всего, будет указана ссылка на одну и ту же перемен ную a dm i n s , и поэтому конфл и кт невозможен , так что нет необходи мости проверять каждое имя учетной записи.

часть lV. Эксплvатация

868

В конфи гурации вы пол н я ется команда оболоч к и cu t — d : — f l / e tc / p a s swd для получения списка существующих учетн ых записей и присваиван ия е го переменной u s e r l i s t . По сути это похоже на строку сценария облочки sh u s e r l i s t= $ ( cu t — d : — f l / e t c / p a s s wd )

Каждая учетная зап и с ь, у каза н ная в пере м е н ной a d m i n s (w i t h _ i t e m s : { { adm i n s } } ) обрабатывается отдел ьно. В свою очередь, имя те кущей обрабаты вае­ мой учетной записи присваивается перемен ной i t em. ( И мя переменой i t em это просто соглашение AnsiЫe, в конфи гурации оно нигде не задается.) Дпя каждой учетной записи, присутствующей в выводе команды cut (директива when ) , вызывается директива u s e r . М ы н е показал и е щ е нескол ько допол н ител ьн ых аспектов, привязывающих эту кон ­ фигурацию к определ е н н о м у н абору целевых хостов и сообщающих систе м е AnsiЫ e , чтоб ы измене н и я б ы л и внесе н ы о т и м е н и пол ьзователя r o o t . Когда м ы акти вируем эту привязку ( путем выполнения команды ansiЫe-playbook example . yml) , с исте ма AnsiЫe начи нает работать и пытается настроить н ескол ько целевых хостов одноврем е н ­ но. Есл и какая -либо операция не удалась, система AnsiЬle сообщает о б ош ибке и пере­ стает работать на том хосте , где была обнаружена ошибка. Другие хосты могут продол ­ жать работу до тех пор, пока она вся не будет выполнена. «

«

,

Настройк а кл иента Дпя упрааления конфигурацией каждого клиента необходимо им еть три вещи: •

доступ к протоколу SS H ;

разрешение н а доступ к sudo 1 2 ;

интерпретатор языка Python 2.

Если клиент я аляется облачным сервером Linux, он может быть доступен системе AnsiЬle автоматически. Такие системы, как Free BSD, в которых не }{:таноалены по умолчанию sudo или интерпретатор Python , могут нуждаться в немного более тон кой настройке, но вы мо­ жете вы полнить часть работы в процессе начальной загрузки с помощью системы AnsiЬle и операций r a w , которая запускает команды удаленно, без привычной оболочки Python. Кроме того, вы можете просто написать собственный сценарий начальной загрузки. П р и настрой ке кл иентов AnsiЬle необходимо сделать выбор из нескол ьких вар иан ­ тов. Мы предлагаем разум н ы й план выбора в разделе » П араметры доступа в систе м е AnsiЫe » , но пока давайте п редположим , что в ы создал и на кл иентс кой маш и н е выде­ л е н ного пол ьзователя a n s i Ы e , что соответствующи й S S Н — кл юч находится в ваш е м стандартном наборе и что вы готовы ввести пароль sudo вруч ную. Клиенты не п редставл я ют себя с исте ме AnsiЬle , поэтом у вам нужно добавить их в с писок хостов AnsiЫe . По умолчан и ю этот список хранится в отдельном файле с име­ н е м /etc/ansiЫe/hosts. Одной из приятных особен ностей с исте м ы AnsiЬle яаляется то, что вы можете замен ить любой текстовый конфигурационн ы й файл каталогом с тем же и мене м . Система AnsiЫe затем объеди няет содержи мое файлов, содержащихся в ка­ талоге. Эта функция полезна для структурирования вашей базы конфигураци и , но также яаляется способом вхлючения динамической информации : если кон кретны й файл яаля —

1 2 Система АпsiЫе фактически не требует доступа к программе sudo . Это необходимо, только есл и вы хотите вы полн ять при вилегированные операци и .

Глава 2 3. Управление конфигурацией

869

ется исполняем ы м , AnsiЫe запускает его и перехватывает результаты вывода, а не ч итает файл напрямую. 1 3 Эта возможность агрегации настолько полезна и так часто ис пол ьзуется , что м ы ре­ коме ндуем обходить этап обработки больш инства файлов конфигурации и переходить непосредствен но к каталогам. Например, мы можем определ ить кл иент систе м ы AnsiЫe, добавив следующую строку в файл /etc/ansiЬle/ho s t s / static (или в — / ho s t s / static в личной конфигурации): new- c l i e n t . e x amp l e . com an s i Ы e_u s e r= a n s i Ы e

В системе FreeBSD и нтерпретатор Python устанавливается в необычное ме­ сто, поэтому системе AnsiЫe необходимо сообщить следующую информацию. f r e e b s d . e x amp l e . c om a n s i Ы e_pyt hon_i n t e rp r e t e r = / u s r / l oc a l / b i n /python a n s i Ы e u s e r= a n s i Ы e

В с е это должно быть записано в одной строке файла hosts. ( Н иже м ы покажем луч ­ ш и й с пособ задать значения этих переменных, но дан н ы й м етод является просто обоб­ щен и е м той же идеи . ) Чтобы п роверить подключение к новому хосту, в ыпол н ите операцию s e t u p , которая возвращает каталог фактов клиента. $ ansiЬle new-client . example . com -m setup new- c l i e n t . ex amp l e . c om 1 SUCC E S S => { » a n s i Ы e_ f a c t s » : { » an s i Ы e_al l_i pv4_addr e s s e s » : » 1 72 . 31 . 25 . 123″

] ,

И мя s e t u p кажется нам неудач н ы м , поскольку я вная настрой ка не требуется . Если хотите , можно перейти непосредствен но к действительн ы м операциям конфигураци и . Кроме того, в ы можете запускать операцию s e tup столько раз, сколько будет н еобходи­ мо для просмотра каталога фактов клиента. Убедитесь, что эскалация привилегий с помощью программ ы sudo также работает правильно. $ ansiЫe new-client . example . com — а whoami — -become — -ask -become-pas s SUDO p a s sword : new- c l i e n t . e x amp l e . com 1 SUCC E S S 1 rc=O >> root

Здесь операция c oпuna n d , которая запускает команды оболоч ки, задается по умолча­ нию. М ы могли бы явно написать -m command с эквивалентными результатами. Флаг — а вводит параметры операции ; в данном случае это фактическая команда, которая должна быть выполнена. П араметр B e c ome , прин ятый для эскалации привилегий , и меет странное назван ие в систем е AnsiЫe; с точки зрен ия систе м ы вы становитесь (become ) други м пол ьзова­ телем . По умолчани ю эти м другим пол ьзователем является пользовател ь r o o t , но вы можете указать другой вариант с помощью флага -u. К сожалению, вам нужно я вно ука­ зать в командной строке системы AnsiЫe специальный флаг, чтобы она запросила у вас

1 ‘ Н а самом деле система AnsiЫe делает еще больше. Она полностью игнорирует определе н н ые типы файлов, например файлы . ini . Таким образом, вы можете н е только добавлять их в сцена­ рии, но и создавать файлы конфигурации для сценариев.

Часть lV. Эксnлvатация

870

парол ь sudo ( это делается с помощью опции — -ask-Ьecoшe-pass ) . причем это делается независимо от того, запраши вает удален ная система парол ь или нет.

Груп п ы клиентов Группы также можно определить в каталоге ho sts, хотя синтаксис при этом может стать неудобн ы м . c l i e n t — f ou r . e x amp l e . com [ we b s e rv e r s ] c l i en t -one . examp l e . c om c l i e n t — t wo . e xamp l e . com [ db s e rve r s ] c l i e n t — one . e x amp l e . c om c l i e n t — t h re e . e x ampl e . c om

Если это выглядит не так уж плохо, то только потому, что м ы обошли основные про­ блем ные области . Формат ini является те кстовы м , поэтому н еобходимы н е которые трюки , если вы хотите определить иерархические групп ы или добавить дополне ния не­ посредствен но в файл hosts (например, присвоить переменн ые для груп п ы ) . Однако эти фун кции на самом деле не так важн ы на практи ке . Обратите в н и ма­ ние: нам пришлось указать хост c l i e n t — f o u r в верхне й части файла , потому что он не вкл ючен в какие-л ибо груп п ы . М ы не можем просто добавить этот хост в конец файла hosts, поскольку это сделает хост c l i e n t — fo u r чле ном группы db s e rve r s , даже есл и бы мы добавил и пустую строку в качестве разделителя. Эrо еще одна причина, почему каталоги конфигурации являются полезными. На прак­ тике м ы , вероятно, захотим поместить каждое определение группы в отдел ьн ый файл . Система AnsiЫe позволяет свободно смешивать имена клиентов и групп в командных стро­ ках и в базе конфигурации. Н и один из н их никак специально не выделяется , и оба могут быть подвергнуты подстановке. Совместимость с регулярным выражением также доступна ШJЯ обеих категорий име н ; просто укажите в начале шаблона префикс — . Существует также набор алгебр нотации ШJЯ разных объединений когорт кл иентов. Например, в следующей команде используется выраже н ие подстановки ШJЯ выбора групп ы web s e rve r s . В ней применяется операция p i n g к каждому члену этой групп ы . .

$ ansiЫe ‘ weh* ‘ -m pinq

c l i ent — one . examp l e . c om 1 SUCC E S S » changed » : f a l s e , » p i n g » : » pong «

=

> {

c l i e n t — two . examp l e . c om 1 SUCC E S S » changed » : f al s e , » p i n g » : » pong «

=

> {

П рисва ивание переменных Как м ы видели ранее, значен ия перемен н ых можно присваи вать в файлах и н вента­ ризации. Но это очен ь грубы й прие м ; не делайте этого. Каждый хост и груп па могут иметь собствен ную коллекцию определ е н и й пере­ менных в формате YAM L. По умолчан ию эти определения хранятся в каталогах /etc/ ans iЬle/host_vars и /etc/ansiЫe/group_vars в файлах, названных по имени хо-

Глава 23. Управление конфигурацией

871

ста ил и груп п ы . Есл и хотите , вы можете испол ьзовать суффи кс yml : с истема AnsiЫe найдет соответствующие файл ы в л юбом случае. Как и в других конфигурациях AnsiЫe, эти файл ы могут быть преобразованы в ката­ логи , есл и вы хотите добавить допол нительную структуру или сценарии. Система AnsiЫe выпол няет обычную процедуру игнорирован ия файлов конфигураци и , запуска сценари­ ев и объедине н и я всех резул ьтатов в окончател ьн ый пакет. Систе ма AnsiЫe автоматически определяет группу a l l . Как и другие груп п ы , гpyn r1a a l l может иметь собствен н ые групповые переменные. Например, если вы стандартизи­ руете использование учетных зап исей клиентов с именем a n s i Ы e для управлен ия кон ­ фигурацией , это хороший повод, чтобы задать глобал ьную конфи гурацию ( например, в каталоге group_vars/all /basics ) : .

an s i Ы e u s e r : an s i Ы e

Если дл я переменной существует несколько объявлений значен ия , система AnsiЫe вы­ бирает окончательное значе ние в соответствии с правилами приоритета , а не по порядку объяаления. В настоящее время система AnsiЫe имеет 14 различных категорий приоритетов, но важны м моментом в этом случае яаляется то, что переменные хоста перекрывают пере­ менные группы. Конфл икты между перекрывающимися группам и решаются случай н ы м образом , что может п р и вести к непоследовател ьному по веде н и ю и сложной отладке . П о пытайтесь структурировать объявления переменных, чтобы не было возможности п ерекрытия .

Динамические и выч исляемые груп п ы кл иентов Систе ма группировки AnsiЫe действител ьно проя вляет себя , когда в действие всту­ пают динам ические сценар и и . Например, сценарии динамической и н ве нтар и зац и и , испол ьзуе м ые с поставщикам и облач н ых вычисл е н и й , н е просто выводят с писок всех доступ н ых серверов. О н и также разделяют и перемещают эти серверы в специал ьн ы е груп п ы в соответствии с метадан н ы м и из облака. Например, служба ЕС2 ком пании Amazon позволяет назначать произвол ьн ые те r·и для каждого экзем пляра. Вы можете назначить тег w e b — s e rve r каждому экзе м пл я ру, которому н ужен сте к N G I NX, и тег d b s e rve r — каждому экзе м пл я ру, которому н уж­ на с истема PostgreSQL. В результате сценар и й динамической и н вентаризаци и ес2 ру создаст группы с и менам и t a g_ we b s e rve r и t a g_ db s e rve r . Эти груп п ы могут и м еть собствен н ые групповые переме н н ые и могут быть названы в привязках ( » плей-л истах » ) , как и л юбая другая группа. Ситуация становится более сложной , когда дело касается груп пировки кл иентов по критерия м , внутре н н и м по отнош е н и ю к с исте ме AnsiЬe, таким как значения фа к­ тов. Вы не можете сделать это напрямую. Вместо этого вы можете ис пол ьзовать целевые наборы сценариев (playbooks) для более ш и роких групп ( например, a l l ) и применять условн ые выражения к отдел ьным операция м , которые, когда соответствующие условия не применяются , пропускают операцию. Например, следующий набор и нструкций гарантирует, что файл / etc/ rc . conf со­ держит строку для настройки имени хоста на каждом клиенте систе м ы Free B S D . .

— name : S e t h o s tn ame a t s t a r t up on F r e e B S D s y s t ems hos ts : a l l t a s ks : — l inein f i l e : dest : /etc/rc . conf l i ne : h o s tname = » { { h o s tname ) } «

Часть lV. Эксплvатация

872 r e g e x p : л h o s t name when : a n s i Ы e_o s_fami l y == » Fr e e B S D «

( Если последняя строка выгл ядит так, как будто о н а нуждается в двойных фигурных скобках, значит ваш инсти н кт вас не подводит. На самом деле это всего л и ш ь н е много синтаксического сахара AnsiЫe , позволя ющего поддерживать конфигурацию в поряд­ ке . Спецификации w h e n всегда я вл я ются выраже н ия м и Jinja, поэтому систем а AnsiЫe окружает их содержимое двойн ы м и фигур н ы м и скобками автоматически. Эта фун кция полезна, но это всего л и ш ь одно из довол ьно обш ирного с писка отклоне н и й в синтак­ сическом анализе формата YAM L в системе AnsiЬ e . ) В этом примере к каждому хосту в и н ве нтарном пере ч н е применяется операци я l i n e i n f i l e . Однако благодаря спецификации w h e n на самом деле эту операцию в ы ­ пол н я ют только хосты под управлением систе м ы Free B S D . Этот подход работает отлич­ но, но он не превращает хосты Free B S D в настоящую групп у. Н апример, они не могут иметь нормал ьную запись group vars, хотя вы можете и митировать этот эффект с по­ мощью некоторых трюков. Структурно предпочтительной , но нем ного более м ногословной альтерн ативой яв­ ляется испол ьзование операции g r o u p_b y , которая вы полн яется локал ьно и класси ­ ф и цирует хосты в соответств и и с произвол ь н ы м значен и е м кл юча, для которого в ы назначаете шаблон : _

— name : Gr oup h o s t s Ьу OS t ype hosts : all tasks : — group_b y : k e y= { { a n s i Ы e_os_f ami l y } } — n ame : S e t h o s t name a t s t a r t u p оп Fr e e B S D s y s t ems host s : FreeBSD tasks : — lineinfile : de s t : / e t c / r c . c o n f l i n e : h o s t n ame= » { { h o s t n ame } } » r e g e x p : л h o s t name

Основной план аналоги че н , н о классификация происходит в отдельном сценарии (тер м и н AnsiЫe для того , что мы называем с вязыван и е м ) . Затем мы нач инаем новый сценар и й , чтобы указать другой набор целевых хостов, н а этот раз испол ьзуя группу Free B S D , определенную для нас в первом сценар и и . Преимущество испол ьзования операции g r o u p b y заключается в том , что м ы вы­ пол няем классификацию только оди н раз. После этого м ы можем назначить л юбое ко­ л ичество задач из второго сценария, будуч и увере н н ы м и в том , что м ы нацелены только на предполагаемых клиентов. _

Списки задач В систе ме AnsiЫe операц и и назы ваются задачам и , а н абор задач , перечисле н н ы х в отдельном файл е , называется списком задач. Как и остал ьн ые части конфигурац и и AnsiЫe, з а небольшим исключен ием , списки задач имеют формат YAM L, поэтому фай ­ л ы имеют суффикс . yml . Связыван ие с писков задач с кон кретными хостами выполняется на объектах более высокого уровн я , называе м ых файлами сценариев (playbooks ) , которые будут описан ы чуть н иже. Теперь давайте сосредоточимся на самих операциях и не будем беспокоиться о том , как они применяются к конкретному хосту.

Глава 23. Управление конфигурацией

873

В качестве примера м ы снова рассмотрим пример установки sudo с н е много и н ы м фокусом и реализацией. На этот раз м ы создаем учетны е записи адми нистратора с н уля и назначаем каждой записи собствен н ую группу U N IX с тем же именем. Затем мы соз­ даем файл sudoers , в котором явно перечислены адм и нистраторы (вместо того, чтобы просто назначать привилегии группе sudo U N IX). 1 4 Для управления этим и операциям и необходи м ы некоторы е входные данн ы е : в част­ ности , рас положен ие файла sudoers , а также имена и лоrи н ы адм и н истраторов. М ы должн ы поместить эту и нформацию в отдел ьн ы й файл пере м е н ной , с кажем , group vars/all/admins . yml .

_

s udoe r s_pa t h : / e t c / s udoe r s a dmi n s : — { u s e rn ame : mann y , f u l l name : Manny C a l ave r a } — { u s e rname : moe , f u l l name : Мое Mone y }

Значе ние a dm i n s это масс и в хеш е й ; м ы перебираем все элементы этого масси ва для создания списка всех учетных записей. Вот как выглядит пол н ы й с п исок задач. —

— name : I n s t a l l s udo p a c kage p a c kage : n ame = s udo s t a t e=p r e s e n t — name : C r e a t e p e r s on a l g r oups f o r a dmi n s g r oup : name= { { i t em . u s e rname 1 ) w i t h_i t ems : » { { admi n s 1 1 » — n ame : C r e a t e admin a c count s user : name : » { { i t em . u s e rname } } » c omme n t : » { { i t em . f u l l name } } » group : » { { i tem . u s e rn ame } } » group s : whe e l wi th_ i t ems : » { { admi n s 1 } » — n ame : I n s t a l l s u d o e r s f i l e t e mp l a t e : de s t : » { { s udoe r s_pa t h } } » s r c : t emp l a t e s / s udo e r s . j 2 owne r : root g r oup : whe e l mode : 0 6 0 0

С точки зрения форматов YAM L и JSON задач и образуют список. Каждое тире в ле­ вом поле начинает новую задачу, которая представлена хеше м . В этом примере каждая задача и м еет поле n a m e , которое описывает ее фун кцию на англ и йском языке. Названия с формальной точки зрения необязательны, но есл и вы их не включите , то с исте ма AnsiЬe будет оче н ь мало сообщать о том , что она делает при запуске конфигурации ( кроме вы вода имен модулей: пакета, груп п ы и т.д.) . Каждая задача должна иметь среди своих ключей и м я точно одного операцион ного модуля. Значен ие этого ключа само по себе является хешем, в котором указа н ы параме­ тры операци и . Параметрам , которы м явно не задан ы значения, назначаются значения по умолчанию. 1 4Файл задачи ил и состояния обычно должен и меть четко определен н ы й домен и четкую цел ь, по­ этому дан н ы й при мер я вляется разновидностью беспорядка. М ы выбрали эти операц и и , чтобы п роилл юстри ровать не которые общие момент ы , а не как пример правильной базовой структуры конфи гурации .

Часть lV. Эксплvатация

874 Обозначение — name : I n s t a l l s udo p a c k a g e p a c k a g e : name = s udo s t a t e =p r e s e n t

я вляется расш ирением формата YAM L в системе AnsiЬe , которое по существу эквива­ лентно следующему коду: — name : I n s t a l l s udo package pac kage :

name : s udo state : present

У таких операци й , как s h e l l , есть одна особен ность — аргументы в свободном виде, но мы не будем переделы вать этот код (см. раздел » Ода YAM I..: ‘ ) . Одностроч н ы й формат не только более ком пактен , но также позволяет устанамивать параметр ы , значения которых предстамя ют собой выражения Jinja без кавычек, как вид­ но из задачи, которая создает персональные групп ы для администраторов. В нормальном синтаксисе выражение Jinja не может поямяться в начале значения, если все значение не указано в кавыч ках. Испол ьзован ие кавычек совершенно безвредно, но добамяет визу­ альный шум . Несмотря на внешний вид, кавычки не превращают значение в строку. Теперь м ы готовы оп исать не которые из наиболее примечател ьных аспектов этого примера списка задач в следующих разделах.

П а раметры состоя ния В системе AnsiЫe операционные модули часто могут вы полнять несколько различ ­ ных задач в зависимости от состоян ия , которое вы запраши ваете. Например, для модуля p a c k a g e состоян ие s t a t e = p r e s e n t инсталлирует пакет, s t a t e=a b s e n t удаляет пакет, а s t a t e = l a t e s t гарантирует, что пакет и нсталлирован и обномен. Операции часто и щут разные наборы параметров в :зависимости от вызываемого состояния. В н е кото р ы х случ а я х ( н а п р и м е р , к о гда м одул ь s е r v i с е с состоя н и е м s t a t e = r e s t a r t e d перезапускает демон) эта модель нем ного отклоняется от того , что обыч но пони мают как «состоя н и е » , но в целом она работает хорошо. Состояние может быть пропуще но ( ка к показан о здесь при создании групп ы s ud o ) , и в этом случае оно принимает значение по умолчанию, обычно что-то положител ьное и рас ширяющее воз­ можности, например p r e s e n t , c on f i gu r e d или runn i n g .

Итера ция Ключевое слово w i t h i t ems — это итерацион ная конструкци я , которая повторяет задачу для каждого элеме нта , к которому она относится. Н иже приведена еще одна ко­ пия двух задач в нашем примере, использующих ключевое слово w i th i t ems . — name : C r e a t e p e r s on a l g r oups f o r a dm i n s g roup : name = { { i t em . u s e rname } ) w i t h _ i t ems : 11 ( { a dmi n s } } 11 — n ame : C r e a t e a dmin accoun t s user : n ame : 11 { ( i t em . u s e r n ame 1 } » c omment : 11 ( ( i t em . f u l l n ame } } g r oup : » ( ( i t em . u s e r name } ) » g r oups : whe e l wi t h_i t e ms : 1 1 ( ( a dmi n s } } «

Глава 2 3. Управление конфигурацией

875

Обратите внимание на то, что wi t h i tems является атрибутом задачи, а не операцией, выполняемой задачей. При каждом прохождении через цикл система AnsiЫe устанавли­ вает значение элемента i t em равны м одному из элементов, взятому из параметра w i t h _ i t ems . В нашем случае м ы присвоили переменной a dmi n s список хешей, поэтому пере­ менная i t em всегда является хешем. Обозначение i t em . u s e rname является сокращен ием выражения i t em [ ‘ u s e rname ‘ ] . Исполъ.зуйте тот вариант, которы й в ы предпочитаете. Каждая из этих задач перебирает все эле менты масс и ва a dm i n s по отдельности . За оди н п роход создаются груп п ы U N IX, а за другой — учетн ы е записи пол ьзовател е й . Хотя в системе АпsiЫе определен механизм групп ировки задач (называе м ы й блоком ) . в этой конструкции. к со.жалению, не поддерживается ключевое слово wi th i t em s . Есл и в а м действител ьно ну.жен эффе кт одного цикла, в котором последовател ьно выполняется нескол ько задач , вы можете добиться этого, переместив тело цикла в от­ дел ьн ы й файл и вкл ючив его в основной сп исок задач. _

— i n c l u d e : sudo — s ub t a s k s . yml w i t h_i t ems : { { admi n s 1 1 » «

Ключевое слово wi t h i t ems — это не единственная разновидность цикла, доступная в системе AnsiЫe. Существуют так.же формы циклов, предназначенные для итерации по хе­ шам (называемые «словарями» в языке Python), спискам файлов и шаблонам подстановок. _

В за имодействие с Jinja Документация AnsiЫe не оче н ь кон кретна в отнош е н и и взаимоде йствия форма­ та YAM L и шаблонов J i nja, но важно понять детал и . Как показывают конструкции . подобн ы е w i t h i t em s , J i nja — это не п росто препроцессор , которы й п р и м е няется к файлу, прежде Ч ем он будет передан механизму YAM L ( как в случае с с истемой Salt) . Фактически система AnsiЫe вы пол няет синтаксический разбор формата YAM L, остав­ ляя нетронут ы м и выраже н ия м и Jinja. Затем препроцессор Jinja разворач и вает каждое строковое значение непосредствен но перед е го испол ьзованием. На каждой итерации параметры повторных операций вычисляются заново. П репро цессор Jinja имеет собствен н ы е структуры управле ния, вкл ючая цикл ы и ус ­ ловные выражения. Однако они по своей сути несовмести м ы с архитектурой отложе н ­ н ы х в ы ч исл ений в системе AnsiЫe и поэтому не разреш е н ы в УАМ L-файлах с исте м ы AnsiЫe ( хотя их можно испол ьзовать в ш аблонах ) . П ростые конструкции , такие как when и wi th i t ems , это не только декорации для эквивалентных шаблонов Jinja. Они представляют собой совершенно другой подход к структурированию конфигурации . —

В изуал изация шаблона Система AnsiЫe использует язык шаблонов Jinja2 как для добавления динамических фун кций в файл ы YAM L, так и для создания шаблонов для файлов конфигурации, уста­ новл е н н ы х модулем t e mp l a t e . В следующем примере мы испол ьзуем шаблон для на­ стройки файла sudoers . Н и.же снова приведены определения переменных для справки . sudo e r s_p a t h : / e t c / s u doe r s admi n s : — { u s e rname : mann y , f u l l n ame : Manny C a l avera — { u s e rname : moe , fu l l name : Мое Mon e y )

Код задачи и меет следующи й вид. — name : I n s t a l l s u d o e r s f i l e t empl a t e :

Часть lV. Эксплvатация

876 de s t : » { { s udoer s_p a t h } ) » s r c : temp l a t e s / s udoer s . j 2 owne r : r o o t g r oup : whe e l mode : 0 6 0 0

Файл sudoer s . j 2 представл я ет собой сочетан ие п ростого текста и кода J i nja2 дл я динам ических сущностей . Например, вот схематический пример, который дает при­ вилегии » sudo ALL» каждому адм и н истратору. D e f a u l t s env_keep += » НОМЕ » { % f o r a dmin i n admi n s % } { { a dm i n } } ALL= ( AL L ) ALL { % endfor % }

Цикл for, закл юченный в с кобки { % % } , представляет собой синтаксис Jinja2 . К со­ жалению, здесь нельзя использовать отступы , как в реальном языке программирования , потому что это приведет к тому, что они появятся в выводе шаблона. Расшире н н ая версия выглядит так. D e f a u l t s env_ke e p += » НОМЕ » manny ALL= ( AL L ) ALL ALL= ( AL L ) ALL

тое

Обратите внимание на то, что переменные автоматически передаются в шаблон ы . И х значения доступн ы для файлов конфигурации с точно такими же именами, которые ис­ пользуются для их определения; здесь нет ни префикса, н и допол нительной иерархии . Автоматически обнаруженные переменные фактов также находятся в пространстве имен верхнего уровня, но для предотвращения потен циальных конфликтов имен они начина­ ются с префикса a n s i Ы e М одуль AnsiЫe для установки статичес ких файлов называется с о р у . Однако вы мо­ жете обрабатывать все файлы конфигурации как шаблон ы , даже если их содержимое изначал ьно состоит из статического текста. Затем вы можете добавлять настройки без необходимости внесен и я изм е н е н и й в код конфигураци и ; просто отредактируйте ша­ бло н . Используйте м одуль с о р у для двоичных и статических файлов, которые н икогда не нуждаются в расшире н и и , таких как открытые кл ючи. _.

Привязки : сценарии и файл ы сцена риев Привязки — это механизм, посредством которого задачи ассоциируются с наборами клиентских м аш и н . Объект привязки AnsiЫe назы вается сценарием (play). Вот простой пример. — n ame : Make sure NG I NX is i n s t a l l e d o n web s e rve r s h o s t s : web s e rve r s t a s ks : — p a c kage : name=nginx s t a t e =p r e s e n t

П одобно тому, как несколько задач можно объедин ить для форм ирования спис ка за­ н есколько сценариев образуют файл сценариев (playbook) . Как и в других системах, основными элементами привязки являются наборы хостов и задач . Однако система AnsiЬJe позволяет указать несколько дополн ител ьных опций на уровне сценария . О н и перечислены в табл . 2 3 . 3 .

дач ,

Глава 2 3 . Управление конфигурацией

877

Таблица 23.3. Элементы сценария AnsiЫe Фо рмат s t ring

Имя для вывода н а печать при выполнении сценария, можно опустить

hos t s

l i s t , s tring

Клиентские системы, на которых выполняются связанные задачи и роли

vars

hash

Значения переменных для установки в области видимости сценария

vars f i l e s

list

Файлы для чтения значений переменных

КnlОЧ

name

Ч то определяет

become *

s t rings

Эскалация привилегий (например, sudo, см. ниже)

tags

list

Категории для выборочного исполнения (см . ниже )

tasks

list

Выполняемые операции; могут включать отдельные файлы

handl e r s

list

Операции, выполняемые в ответ на уведомление ( no t i f y )

role s

list

Привязки ( роли ) для вызова для этих хостов; см. ниже

Сам ы м и важн ы м и в этой табл ице я вля ются элементы, связанные с пере м е н н ы м и , причем не стол ько потому, что они появляются в самих сценариях, а потому, что о н и доступны практически везде , даже п р и выполнении операции i n c l ud e . Система AnsiЫe может активировать оди н и тот же сп исок задач ил и набор сценариев с нова и с нова с разл и ч н ы м и наборам и значений переменных. Это очень похоже на определение фун к­ ции (например, » создать учетную запись пользователя » ) , которая потом вызы вается с разл и ч н ы м и наборами аргументов. Система AnsiЫe формализует эту систему с помощью реализации пакетов (называем ых «роля м и » ) , которые м ы обсуждаем далее. Роль — это мощн ый инструмент, но по существу это всего лишь набор стандартизован н ых условностей , поэтому их легко понять. Вот простой сценарий , демонстрирующий использование обработчиков. — n ame : Upd a t e cow- c l i c k e r web арр ho s t s : c l i c ke r a , c l i c k e rb tasks : — n ame : r s ync арр f i l e s t o / s rv s ynchroni z e : mode : p u l l s r c : web — repo : — s i t e s / c ow- c l i c k e r de s t : / s rv / cow- c l i c ke r not i f y : r e s t a r t nginx handle r s : — n ame : r e s t a r t n g i n x s e rv i c e : n ame=nginx s t a t e = r e s t a r t e d

Этот с ценарий работает на хостах c l i c ke r a и c l i c ke r b . О н коп ирует файл ы из централ ьного (локал ьного) репозитория, выполняя команду rsync ( испол ьзуя модул ь s y n c h ro n i z e ) , а затем переза гружает веб-сервер N G I NX, есл и были сделаны какие­ либо обновления. Когда задача со специфи кацией noti f y вносит изменения в систему, система AnsiЫe запускает обработч и к запрошенного имени. Сам и обработч ики — это просто задачи , но они объявлены в отдельном разделе сценария. Основной еди н и цей исполнения в систе ме AnsiЬe я вляются файл ы сценариев. Они запускаются с помощью команды ansiЫe-playbook. $ ansiЬle-playbook global . yml — — ask- sudo -pass

Система AnsiЫe обрабатывает нес кол ько хостов, выполняя задачу за задачей . Когда она читает файл сценариев, каждая задача выпол н яется параллельно на целевых хостах.

Часть lV. Эксплуатация

878

П осле того как каждый хост завершит задачу, система АпsiЫе начинает следующую за­ дачу. По умолчани ю система АпsiЫе запускает задачи одновременно на пяти хостах, но существует возможность установить другой предел с помощью флага -f. При отладке ч асто бывает полезно вкл ючить аргумент -vvvv для увеличения объема вывода отладочной информации . Вы увидите точ ные команды, которые вы полня ются на удаленной системе, и реакцию системы на н их.

Рол и Как м ы п исал и в общих чертах, привязки ( это наш терм и н ) я вляются механ измом упаковки, определ е н н ы м с истемой С М , которы й облегчает повторное и совместное ис­ пользование фрагментов конфигураци и. В с истем е АпsiЫе пакеты назва н ы ролями , и о н и на самом деле не что иное, как структурирован ная система операций i n c l u d e и правил приоритета пере м е н н ых. О н и позвол я ют легко помещать определения перемен н ых, с п иски задач и шаблон ы , связан ­ н ые с конфигурацией, в оди н каталог, что делает их доступн ы м и для повторного и со­ вместного использования. Каждая рол ь — это подкаталог каталога roles , который обычно н аходится на верх­ нем уровне базы конфигураци и . Вы также можете добавить каталоги ролей для всей ор­ ганизаци и , установив переменную r o l e pa t h в файле ansiЫe . cfg, как было показано выше. Все известн ые каталоги ролей п росматриваются всякий раз, когда вы вкл ючаете роль в файл сценариев. Каталоги ролей могут иметь подкаталоги , показанные в табл . 23.4. Таблица 23.4. Подкаталоги ролей AnsiЫe П одкатало г defaul ts vars

tasks handlers files templates meta

Содержание

Значения по умолчанию для переопределяемых переменных Определения переменных (не переопределяемые, но могут ссылаться на переопределения) Список задач (наборы операций) Операци и , которые реагируют на уведомления Файлы данных (обычно используемые в качестве источника для операции сору ) Шаблоны, которые должны обрабатываться препроцессором Jiпja перед установкой Список запускаемых пакетов, необходимых для запуска конкретного пакета

Рол и вызываются с помощью файлов сценариев и н и как инач е . Система АпsiЬе ищет файл main . yml в каждом из подкаталогов рол и . Есл и он существует, содержимое автоматически включается в л юбой файл сценариев, которы й вызывает роль. Например, файл сценариев — name : S e t u p cow- c l i c k e r арр t h roughout E a s t r e g i on ho s t s : web- s e r ve r s — e a s t ro l e s : — cow- c l i c k e r

примерно эквиваленте н следующему. — name : S e t up cow- c l i c k e r арр t h r oughout E a s t r e g i on h o s t s : web — s e rve r s — e a s t va r s f i l e s : — r ol e s / c ow- c l i c k e r / d e f a u l t s /ma i n . yml — r ol e s / c ow- c l i c ke r / va r s /mai n . yml tasks :

глава 2 3 . Управление конфигурацией

879

— i n c l ude : r o l e s / cow- c l i c ke r / t a s k s /main . yml handl e r s : — i n c l ude : r o l e s / cow- c l i c ke r /handl e r s /ma i n . yml

Однако значен и я переменных из папки defaul t не п е рео предел я ют значения, кото­ рые уже был и установлен ы . Кроме того, система AnsiЫe уп ро щает обращение к файлам из каталогов files и template s , а также включает все рол и , у п о м я н утые в качестве за­ висимостей в файле meta/main . yml . Файл ы , отличные от main . yml , и гнорируются с и стем о й роле й поэтому вы можете разбить конфигурацию на л юбые части и просто включить эти части в файл main . yml . Система AnsiЫe позволяет передавать н абор значе н и й пере м е н н ых в ко н кр ет н ы й эк­ земпляр рол и . При этом роль начи нает действовать как с вое го рода параметризова нная функция. Н апример, в ы можете определить пакет, котор ы й испол ьзуется дл я разверты­ вания приложен и я Rails. В ы можете вызвать этот пакет н е с кол ь ко раз в файле сценари­ ев, при каждом вызове предоставляя параметры для нового п р ил оже н ия . ,

— name : I n s t a l l UL SAН Ra i l s a p p s ho s t s : u l s a h — s e rv e r rol e s : — { r o l e : r a i l s_app , app_name : u l s a h — reviews ) — { r o l e : r a i l s_app , app_name : admi n — c om )

В этом при мере роль r a i l s а р р , вероятно, будет зависеть от рол и n g i n x ил и како­ го-либо другого веб-сервера, поэтому нет н еобходи м ости у п о м и нать р ол ь в еб сер в е р а явно. Если вы хотите настроить установку веб-сервера, вы можете просто вкл ючить со­ ответствующие значения переменн ых в вызов ra i l s app, и эти знач е н и я будут распро­ _ страняться в н из. Репозитори й открытой рол и AnsiЫe находится на сайте g a l a x y . a n s i Ы e . c om . Вы можете искать роли с помощью команды ansiЫe-galaxy, но л уч ш е использовать ука­ занный веб-сайт. Он позволяет сортировать роли по рейти н гу ил и количеству загрузок и ле гко переходить в репозитори й Git Hub, где размещен фактический код для каждой роли. Для наиболее распространенн ы х сценариев обыч н о досту п н о н ес коль ко рол е й , поэтому стоит изучить код, чтобы определить, какая верс и я будет наилуч ш и м образом удовлетворять ваши потребности. П осле того как в ы решились на реал изацию рол и , скоп ируйте файл ы в каталог role s , выпол н и в команду ansiЫe-galaxy instal l . Н а п р и м е р , так. _

$ ans iЫe-qalaxy ins tall ANXS . pos tgresql

down l oa d i n g r o l e ‘ po s t g r e s ql ‘ , owned Ьу ANX S down l oa d i n g r o l e f r om h t t p s : / / g i t hub . com/ANX S /p o s t g r e s q l / v l . 4 . 0 . t a r . g z e x t r a c t i n g ANX S . p o s t gr e s ql t o / e t c / a n s i Ы e / r o l e s /ANX S . po s t g r e s ql ANX S . po s t gr e s ql w a s i n s t a l l e d s u c c e s s fu l l y

Рекоменда ции по структури рова н ию базы конфигур а ции

Большинство баз конфигурации организованы иерархическ и . И наче говоря , различ­ ные части конфигураци и загружаются в главн ы й файл сценариев, кото р ы й у правляет глобал ьны м состоянием. Тем не менее можно определить файлы с ц е н ар и е в для с пеци ­ альн ых задач , не связан ных с глобальной схемой. Старайтесь хранить списки задач и обработчи ков за п редел а м и файлов с це нариев. Поместите их в отдельн ые файлы и интерполируйте с помощью операции i n c l ud e . Эта структура обеспечивает четкое разделение между при в яз ка м и и п оведе н ие м , а также в ы —

Часть lV. Эксплvатация

880

рав н и вает приоритеты всех задач. Кроме того, хорош и м стилем я вляется пол н ы й отказ от самостоятельных с писков задач и стандартизация ролей. И но гда рекомендуется, чтобы оди н файл сценариев охватывал все задачи , отн осящи­ еся к каждой логическ и определенной группе хостов. Н апример, все роли и задачи , от­ носящиеся к веб-серверам, должны быть включен ы в оди н файл сценариев webserver . yml . Такой подход позвол яет избежать репл и кации групп хостов и обеспечивает четкий фокус управления для каждой групп ы хостов. С другой сторон ы , следование этому правилу означает, что у вас нет прямого с пособа запуска ч асти глобальной конфигурации даже для отладки. С истем а AnsiЫe может вы­ пол нять только файл ы сценариев; в ней нет простой команды, которая запускает опре­ дел е н н ы й с писок задач на данном комп ьютере. Официал ь н ы м решением этой проб­ л е м ы я вляется тегирование, которое отлично работает, но требует н екоторой настройки. Вы можете включить поле t a g s в л юбую задачу или перед любой задачей , чтобы класси­ фицировать ее. Чтобы указать подм ножество тегов, которые вы хотите запустить, в ко­ мандной строке испол ьзуйте опцию -t команды ans iЫ e -playbook. В большинстве сценариев отладки следует также испол ьзовать параметр -1, чтобы ограничить выполне­ ние указа н н ым тестовым хостом. П рисваивайте теги на как можно более высоком уровне иерархии конфигурации . При нормальных обстоятельствах у вас н е должно возникнуть соблазна н азначать теги для от­ дельных задач. ( Если вы это сделаете, это может быть признаком того, что конкретн ы й список задач должен быть разделен на части. ) Вместо этого добавьте теги в специфика­ цию inc l ude или r o l e , которые в ключают в себя определенный список задач или ролей в конфигурации. После этого теги будут распространен ы на все включен н ые задачи . Кроме того, вы можете просто с нуля создавать файлы сценариев, которые запускают части базы конфигурации на тестовом хосте . Н астрой ка этих файлов сценариев — н е ­ сложная работа, к а к и назначен ие тегов в целом.

Па раметры доступа в системе AnsiЫe Система AnsiЫe нуждается в доступе к службе S S H и програм ме sudo на каждой кли ­ е нтской маш и н е . Это кажется п ростым и естествен н ы м д о тех пор , пока вы н е учтете , что система управления конфигурацией содержит мастер-ключи для всей орган изаци и . Трудно обеспечить более высокую безопасн ость с истем н а базе демонов, чем безопас­ ность учетной записи r o o t на сервере конфигурации, но при продуман ном план ирова­ н и и система AnsiЫe может решить эту задачу. Для простоты луч ше всего испол ьзовать S S Н-доступ через выделен ную учетную за­ пись, например a n s i Ы e , которая имеет одно и то же имя на каждом кл иенте. Эта учет­ ная запись должна испол ьзовать простую оболочку и иметь м и нимал ьн ы й файл конфи­ гураци и , имя которого начинается с точки. На облачных серверах вы можете использовать стандартную учетную запись начальной загрузки (например, e c 2 — u s e r на ЕС2) для управления со сторон ы AnsiЫe. Просто убеди­ тесь, что после первоначальной настройки учетная запись была правильно заблокирована и не разрешает, например, выполнение команды зu для пользователя root без пароля. У вас есть определен н ая гибкость в выборе фактической схе м ы с исте м ы безопасно­ сти. Но имейте в виду следующее. •

Системе AnsiЫe требуется один мандат ( пароль или закрытый кл юч) дл я доступа к удаленной с истеме и другой — для повышения привилегий с помощью програм ­ м ы sudo. Правильные принципы безопасности предполагают, что это разные маи-

глава 2 3 . Управление конфигурацией

881

даты . Еди н ы й скомпрометирова н н ы й мандат не должен предоставлять злоумы ш ­ лен н и ку доступ к учетной записи r o o t целевой машины. 1 5 •

Если оба мандата хранятся в одном и том же месте с оди наковой формой защиты ( шифровани е , права доступа к файлам) , они фактически представля ют собой еди­ н ы й мандат. М андаты можно повторно использовать на ком пьютерах, которые я вляются одно­ рангов ы м и хостами (например, веб-серверам и на ферме серверов) , но не должно быть возможности испол ьзовать мандаты на одном сервере для доступа к более важному или даже совершенно другому серверу. Система AnsiЫe и меет прозрач ную поддержку заш ифрован н ых дан н ы х с по­ мощью команды ans iЫe -vaul t , но только есл и дан н ы е содержатся в файле YAM L или ini. .

Адм и н истраторы могут запоминать всего несколько паролей.

Неразумно требовать более одного пароля для данной операции.

Организации вырабатывают собстве н н ые правила, но м ы предлагаем следующую си­ стем у в качестве надежного и удобного ориентира. • Доступ к службе S S H контрол ируется парами ключе й , которые испол ьзуются тол ько системой AnsiЫe. •

Доступ к службе SSH по паролю запрешен в клиентских системах ( путем установ­ к и параметра P a s s w o r dAu t h e n t i c a t i o n равн ы м no в файле /etc/ s sh/ s shd_ config) . Закрытые ключи S S H должны быть защищен ы парольной фразой (устанавли вает­ ся с помощью команды ssh-keygen -р) . Все личные ключи должны иметь одну и ту же парольную фразу. Закрытые ключи S S H должн ы храниться в и звестном месте на главной машине AnsiЫe . О н и не должн ы храниться в базе конфигурац и и , и адм и н истраторы н е должны копировать их в другое место.

Учетные записи на удаленных маш инах для с исте м ы AnsiЫe должны и меть слу­ чайн ы е парол и U N IX, которые указы ваются в базе конфигур ац и и в зашифро­ ванном виде . Все они зашифрован ы одн о й и той же парольной фразо й , но она должна отличаться от парольной фразы , используемой для закрытых кл ючей S S H . В а м нужно будет добавить код AnsiЫe , чтобы убедиться , что п равил ьные парол и используются правильными клиентскими хостами. В этой схеме оба набора мандатов ш ифруются, что делает их устойчивыми к простым наруше н ия м прав доступа к файлам . Этот слой косвенности также позволяет легко из­ менять основные фразы, не изменяя основн ые ключи . Адм и н истраторы должны помн ить только две фразы: парольную фразу, которая пре­ доставляет доступ к секретным ключам SS H , и пароль хра н илища AnsiЫe , которы й по­ зволяет с истеме расшифровывать пароли sudo , специфичн ые для хоста (а также л юбую другую конфиденциал ьную и нформацию, включенную в вашу конфигурационную базу).

«В некоторых организациях создаются клиентски е учет н ые записи для систем ы АпsiЫе с опцией NOPAS SWD в файле sudoer s , так что Д11Я этой учетной зап и с и Д11Я запуска программ ы sudo не тре­ буется пароль. Это ужасн о небезопасная конфи гурация. Если вы не можете заставить себя ввести парол ь, то по край н е й мере установите модуль аге нта РАМ S S H и потребуйте переадресова н н ы й S S Н -ключ Дll Я доступа к sudo . Дополнительную и нформац и ю о РАМ см. в разделе 1 7 . 3 .

Часть lV. Эксплуатация

882

Есл и вам нужны более специфичн ы е права доступа адм и н истратора (что впол н е ве ­ роятно), вы можете заш ифровать нескол ько наборов мандатов с помощью разн ых па­ рол ьн ых фраз. Есл и эти наборы имеют мноrо общего ( в отличие от непересекающихся ) , то каждому адм и н истратору не нужно будет пом нить более двух парол ьных фраз. В этой с исте ме предполагается, что адм и н истраторы будут ис пол ьзовать команду s sh-agent дпя управлен ия доступом к закрытым кл ючам . Все ключи могут быть акти­ вированы с помощью одной команды ssh-add, а пароль SSH необходимо вводить тол ь­ ко оди н раз за сеанс. Для работы с системой, отл и ч ной от обычного мастера AnsiЫe , адм и н истраторы могут ис пол ьзовать опцию S S H F o r w a rdAg e n t дп я тун н ел и рования кл ючей до маш и н ы , на которой выполняется работа. Вся другая и нформация о безопас­ ности включена в саму конфи гурацион ную базу. Ш Более подробную информацию о команде ssh-aqent см. в разделе 27 . 7 . Команда s sh-agent и пересылка кл ючей я вляются настолько же безопас н ы м и , как и маш и н ы , на которых они запускаются. ( На самом деле это нем ного не так: аналогич ­ но про грамме sudo с периодом отсроч ки он и настолько ж е безопас н ы , как и ваша л и ч ­ н а я уч етная запись. ) Однако р и с к смягчается огран иче н и я м и по вре мени и контексту. Ис пол ьзуйте аргумент -t в командах ssh-agent ил и s sh-add, чтобы ограничить вре мя действия активирован н ых ключей и разорвать соединения, которые имеют доступ к пе­ реадресован н ы м кл ючам , когда вы бол ьше их н е испол ьзуете. Есл и возможно, закрытые кл юч и н икогда не должны развертываться в кл иентских системах. Есл и клие нтам н ужен привилегирован н ы й доступ к контрол ируе м ы м ресур­ сам ( например, клонировать контрол ируе м ы й репозитори й Git), ис пользуйте прокс и ­ функции, встроен н ые в S S H и AnsiЫe , ил и команду ssh-agent дпя временного доступа к закрыты м ключам кл иента без их копирования. П о какой-то причи н е система AnsiЬle в настоя щее время не может распознавать за­ ш ифрованные файл ы в базе конфигурации и п редпагать ввести парольную фразу дпя их де ш ифровки. Чтобы заставить с истему сделать это , укажите аргумент — — a sk-vau l t ­ p a s s в командах ansiЫe-playbook и ans iЬle. Существует также опция — -vaul t ­ pas sword — f i l e дпя н е интерактивного испол ьзова н и я , н о , конечно ж е , это с н ижает безопасность. Есл и вы реш ите использовать файл парол е й , он должен быть доступен тол ько дпя выделенной учетной записи системы AnsiЬle.

23 .6. ВВЕДЕНИЕ в СИСТЕМУ SALT Систему Salt часто называют SaltStack или Salt Open. Эти терми н ы по существу взаи­ мозаменяемы . Н азвание ее поставщика SaltStack, и поэтому название SaltStack испол ь­ зуется как общий термин для обозначения пол ной л и нейки продуктов, включающей не­ которые допол нительные корпоративные модул и , которые мы не обсуждаем в этой книге. Тем не менее многие л юди называют систему с открытым исходным кодом SaltStack. Salt Open — это н едавно поя вившееся название, которое обозначает тол ько ком по­ не нты с открытым исходным кодом Salt. Но в настоящее время это название , похоже , не ис пользуется нигде вне сайта s a l t s t a c k . com. Система Salt Stack поддерживает собстве н н ы й ре позитори й пакетов н а сайте r e p o s a l t s t a c k . c om , в котором разме щаются обновл е н н ые пакеты дл я каждой с исте м ы управления пакетами Linux. И нструкции п о добавле н и ю ре позитория к ваш ей конфи гу­ рации смотрите на веб-сайте. Н екоторые дистрибутивы включают свободно распростра­ няемые пакеты, но лучше всего пере йти непосредствен н о к источни ку. —

.

Глава 23. Управление конфигурацией

883

Вам понадобится установить пакет salt-master на главном сервере конфигурации (мастер-сервер). Если у вас есть какие-либо договора с облач н ы м и провайдерами , также установите пакет salt-cloud. Он объединяет множество облачных провайдеров в стан­ дартны й и нтерфейс и упрощает п роцесс создания новых облачн ых серверов, управля­ емых системой Salt. Этот пакет по существу похож на собствен ные инструменты CLI для облачных п ровайдеров, но обрабаты вает маш и н ы как на слоях Salt , так и на обла­ ках. Новые маш и н ы автоматически загружаются , регистрируются и санкционируются . Удаленные маш и н ы удаляются из с исте м ы Salt, а также из облака провайдера . Система SaltStack не поддерживает репозитори й пакетов для операцион ­ ной с истемы FreeBS D , но это поддерживае мая в Free B S D платформа. Веб­ установщик распознает систему Free B S D : $ curl -L https : / /boots trap . salts tack . com $ sudo sh / tmp / saltЬoot — Р -м

/ tmp/ s al tЬoot

П о умолчан ию веб- установщик устанавл ивает клиентское програ м м ное обеспече­ ние, а также главны й сервер. Если вы этого не хотите , укажите аргумент -N в команде saltЬoot. Ш Допол нительную и нформацию о контейнерах см. в главе 25. Фа йл ы конфигурации Salt размещены в каталоге / etc/ sal t, как на главном сервере, так и на клиентах (миньонах). Теоретически возможно запустить демон сервера от имени непривилегированного пользователя, но для этого требуется вручную задать права досту­ па для множества системных каталогов, с которыми будет взаимодействовать система Salt. Если вы хотите идти по этой дороге, вам, вероятно, лучше использовать контейнерную вер­ сию сервера или записать конфигурацию в предварительно сохраненном образе машины. Система Salt имеет простую систему управления доступом , которую можно настроить, чтобы позволить непривилегированн ы м пользователям инициировать операции Salt на ми­ ньонах. Тем не менее вы должны будете выполнить вручную настройку прав доступа, ана­ логичную той, которая требуется для работы от имени непривилегированного пользователя. Учитывая, что мастер имеет прямой доступ ко всем миньонам от имени суперпользователя roo t , мы считаем эту функцию довольно сомнительной с точки зрения безопасности. Если вы ее используете, внимательно следите за предоставляемыми правами доступа. Система Salt п оддержи вает разделение между файлам и конфигурации , в которых устанавл и ваются значения пере м е н н ых (базовые эле м енты (pillars) ) и файлами кон ­ фигураци и , в которых определя ются операции (состояния (states) ) . Различие проходит вплоть до верхнего уровня : вы должны установить разные м естоположения для этих ие­ рархий файлов конфигурации. Они обе по умолчанию находятся в каталоге / s rv, чему соответствуют следующие записи в файле /etc/salt/master: f i l e r o ot s : base : — /srv/salt p i l l a r_root s : bas e : — / s rv / p i l l a r

Здесь b a s e это требуемая общая среда, поверх которой могут быть добавлены до­ пол нительные среды ( например, deve l opme n t ) . Определения переменных находятся в корне / srv /pillar, а все остальное находится в каталоге / srv / sal t . —

884

часть lV. Эксплvатация

Обратите вн имание на то, что сам и пути явля ются элементами сп иска, так как о н и и меют префикс в виде тире . Вы можете вкл юч ить несколько каталогов, что позволяет демону sal t-master передавать объединен ное представление перечисле нных каталогов м и н ьонам . Это полезная функция при создании большой базы конфигурац и и , так как она позволяет вам добавлять структуру, которую система Salt не смогла бы понять само­ стоятельно. Как правило, база конфигурации управляется как еди н ы й репозиторий Git, который вкл ючает в себя подкаталоги salt и pillar. Это не подходит мя стандартной схе м ы , принятой п о умолчанию, поскольку означает, что каталог / s rv будет корнем репозито­ рия; рассмотрите возможность перемещения всего уровня в каталог / s rv/ sal t / s a l t и /srv/ salt/pi llar. Документация систе м ы Salt н е оче н ь хорошо объясняет, почему базовые элементы и состоя н и я должны быть пол ностью разделе н ы , но на самом деле это разл ичие я вл я ­ ется це нтральным мя ее архитектур ы . Демон s a l t-master не обращает н и малейшего внимания на файл ы состоян и й ; он просто делает их доступн ыми мя м и ньонов, которые несут ответственность за синтаксический разбор и выполнение этих файлов. Базовые элементы — совсем другое дело. Они обрабаты ваются мастером и рас­ простран яются среди м и н ьонов в виде еди ной ун ифи цированной и ерархии в формате JSON . Каждый м и н ьо н видит разные представлен ия базовых элементов, но ни оди н из н их не может видеть механизм реал изации этих предстаме н и й . Частично это мера безопас ности: система Salt дает сильную гарантию, что м и н ьоны не могут получить доступ к базовым элементам друг друга. Это также обеспеч и вает раз­ деление источн и ков дан ных, так как динамическое содержание базовых элементов всег­ да происходит от мастера. Это обеспечивает хорошую взаимодопол няемость с зернами (термин системы Salt мя фактов) , которые происходят от м и н ьонов. W Дополнительную и нформаци ю о сетевых брандмауэрах см. в разделе 27. 7 . Коммуникацион ная ш и н а системы Salt использует ТС Р- порты 4505 и 4506 на сер­ вере . Убедитесь, что эти порты доступ н ы через л юбые брандмауэры ил и фильтры паке­ тов, которые находятся между сервером и потенциальн ыми кл иентами . Сам и кл иенты не при н и мают сетевые подключения , поэтому этот шаг необходимо выпол н ить тол ько один раз мя сервера. Впервые исследуя систему Salt, вы можете обнаружить, что она будет более информа­ тивной, если ее запустить с помощью команды sal t-master -1 deЬug в окне тер м и ­ н ал а , а не в качестве системной службы. Это заставляет демон system-master работать на переднем плане и вы водить на экран информацию о действиях в ком муни кационной шине с исте м ы Salt по мере их появлен и я .

Настрой ка миньонов Как и на главной сторон е , у вас есть выбор собстве н н ы х пакетов из репозитория SaltStack или универсального сценария начальной загрузки. Ре позиторий вряд ли стоит загружать данн ы м и о м и н ьонах, поэтому мы ре комендуем следующее . $ curl -о / tmp/sal tЬoot -sL https : / /boots trap . salts tack . com $ sudo sh / tmp/ saltЬoot — Р

Сценарий начал ьной загрузки работает в л юбой поддерживаемой системе. В систе ­ м ах без утилиты curl утилиты wget и fe tch также работают нормально. Кон кретные

Глава 23. Управление конфигурацией

885

сценарии инсталл я ции и исходн ый код представлены в ре позитори и s a l t s t a c k / s a l t ­ boot s t rap н а сайте GitHub. 1 6 W Дополн ительную и нформацию о службе DNS см. в главе 1 6 .

По умолчан ию демон sal t-DU.nion пытается зарегистрироваться на главной машине под именем s a l t . (Эта система » вол шебного и м е н и » была впервые популяризирована в системе Puppet.) Вы можете испол ьзовать систему D N S для правил ьного преобразова­ ния имени или явно задать главную машину в файле /etc/salt/minion ( /usr/local/ etc/salt/minion в системе Free B S D ) : ma s t e r : s a l t . e x amp l e . c om

П ерезагрузите демон salt-minion после изменения этого файла (обыч но для этого испол ьзуется команда service sal t_minion res tart; учтите , что здесь применяется подчеркиван ие, а не дефис) . Демон salt-master при н имает ре гистрацию клие нтов с любой случайной маш и н ы , которая имеет к нему доступ, но вы должны с а м и одобрить каждый кл иент с помощью команды salt-key на главном сервере конфи гурации до того, как он станет активн ы м . $ sudo salt-key -1 unaccepted Unac c e p t e d K e y s : new- c l i e n t . e x amp l e . com # Если в с е хорошо , одо бри т е в с е ожида ющи е клю чи

$ sudo salt-key — уА T h e f ol l ow i n g k e y s a r e going t o Ье a c c e p t e d : Un a c c e p t e d K e y s : new- c l i e n t . e x amp l e . com Кеу for mi n i on new- c l i e n t . examp l e . com a c c e p t e d .

Теперь вы можете проверить подключение со стороны сервера с помощью модуля t e s t . $ sudo sal t new-client . example . com tes t . pinq new- c l i e n t . e x amp l e . com : T ru e

В этом при мере строка new-cl ient . example . com напом инает имя хоста, но на са­ мом деле это не так. Это обычный иде нтифи катор Salt для маши н ы , т. е. строка, которая по умолчанию соответствует имени хоста, но она может быть изменена по вашему жела­ нию в файле кл иента /etc/ sal t/DU.nion. ma s t e r : s a l t . e x amp l e . com i d : n e w — c l i e n t . e x amp l e . com

Идентификатор ы и l Р-адреса не имеют н и чего общего друг с друго м . Например, даже есл и строка 5 2 . 24 . 1 4 9 . 1 9 1 фактически соответствовала l Р-адресу клиента , ее нел ьзя непосредстве нно указы вать в качестве цел и в параметрах команд системы Salt: 1 7 $ sudo salt 5 2 . 2 4 . 1 4 9 . 1 9 1 tes t . pinq No mi n i ons ma t c h e d t h e t a r g e t . No command wa s s e n t , no j i d w a s a s s i gn e d . ERROR : No r e t u r n r e c e ived 1 •для произ водстве н н ы х с и сте м , запускае м ы х а втомати чески , необход и м о м и н и м и з и ровать возде йствие вне ш н и х событ и й , загрузив локал ьно ке ш и рован ную верс и ю сценария загрузки . Инсталл и руйте определен ную верс и ю клиента Salt из локал ьного кеша или предварител ьно за гру­ зите его в образ маш и н ы . Запустите загрузоч н ы й с ценари й с параметром -h, чтобы прос мотреть все параметр ы , которые он поддержи вает. 1 7 Разумеется , вы можете выпол н ить сопоставление на основе I Р-адресов. П росто это должно быть сделано явно. Подробности см. ниже.

Часть lV. Эксnлvатация

886

Привязка значения переменной к миньону Как м ы видел и в разделе , посвя щенном настройке сервера, у системы Salt есть от­ дельн ые иерархии файловой с исте м ы для привязок состоя н и й и привязок значе н и й к перемен н ы м (базовые элементы). В корне каждой из этих иерархий каталогов нахо­ дится файл top . s l s , который с вязывает груп пы м и н ьонов с файлами внутри дерева. У двух файлов top . s l s испол ьзуется оди н и тот же формат. ( Расш ирение . s l s — это стандартное расширение Salt для файлов YAM L. ) В качестве примера приведем схему простой базы конфигурации Salt , в которой су­ ществуют корн и sal t и pillar.

[�

$ tree /srv/ salt / s rv / s a l t sa l t

t op . s l s h o s t name . s l s boo t s t r ap . s l s s s hd . s l s base l ine . s l s pillar

t op . s l s b a s e l i ne . s l s web s e r ve r . s l s f reebsd . s l s

2 directories ,

9 files

Чтобы привя зать перем е н н ы е , определ е н н ые в файлах p i l l a r / b a s e l i n e . s l s и pillar/ freebsd . s l s , к нашему клиенту, м ы могли б ы включить следующие строки в файл pillar/ top . s l s . base : new- c l i en t . e x amp l e . c om : — basel ine — freebsd

Как и в файле ma ster , ba s e это обязательная общая среда , которая может быть переопределена в более сложных настройках. Подробнее об этом с м . н иже в разделе » Среды » . Некоторые из тех ж е значений пере ме н н ых можно определ ить в файлах basel ine . sls и freeЬsd . s l s . Для скалярных значени й и массивов действующи м источн иком яв­ ляется тот, который последним указан в файле top . s l s . Н апример, есл и м и н ьон связывается с одн им файлом переменн ых, которы й вы гля­ дит так: —

a dm i n- u s e r s : mann y : uid : 7 2 4 moe : uid : 7 4 0

и другим , которы й выглядит так: a dm i n — u s e r s : j ac k : uid : 1 0 0 4

то система Salt объединяет две версии.

Глава 2 3 . Управление конфигурацией

887

Базовые элементы, представленные миньонам , выглядят так: admi n — u s e r s : mann y : uid : 7 2 4 mo e : uid : 7 4 0 J ac k : uid : 1 0 0 4

Сопоста вление ми н ьонов В приведе н ном выше сценари и мы хотим примен ить файл basel ine . s l s ко все м без искл ючения клиентам , а файл freebsd . sls к о всем кл иентам , на которых рабо­ тает операцион ная система Free B S D . Вот как м ы можем это сделать с помощью шабло­ нов выбора в файле pillar/ top . s l s . —

base : ‘ * . e x amp l e . сот ‘ : — b a s e l ine ‘ [email protected] o s : FreeBSD ‘ : — f reebsd

Звездочка соответствует всем иде нтифи каторам клиентов в доме н е e x amp l e . сот. Можно было просто испол ьзовать здесь обозначение ‘ * ‘ но м ы хотели подчеркнуть, что это шаблон подстановки . П рефикс G @ зап рашивает совпаде н и е значе н и й зере н . П роверяе мое зерно назы вается o s , а искомое значение Free B S D . Здесь также допу­ скается ис пол ьзование шаблонов подстановки . Было бы проще нап исать соответствующее выражение для Free B S D так: ,

‘ os : FreeBSD ‘ : — ma t c h : g r a i n — freebsd

Выбор зависит от вас , но с и м вол @ я в н о рас ш иряет сложные вы раже н и я , содержа­ щие круглые скобки и логические операции. В табл . 23.5 переч ислен ы наиболее расп ро­ страненные виды сопоставления, хотя некоторые из них был и опуще н ы . Таблица 23 . 5 . Типы сопоставления миньонов Код

Цель

Тип

Сопоставление:

Пример

ID

g l ob

g l ob

Е

ID

regex

pcre

E @ ( nw l wc ) — l i n k — d +

ID

list

list

L @ h o s t a , ho s tb , h o s t c 6

G

grain

g l ob

grain

G @ doma i n : * . e x ampl e . c om

Е

grain

regex

grain pcre

E @ v i r t ua l : ( x e n l VMW a r e )

I

pillar

glob

pillar

I @ s c a l i n g_t yp e : a u t o s c a l e

J

pillar

regex

p i l l a r_p c r e

J @ s e rve r — c l a s s : ( we b l d a t a b a s e )

s

I Р — адре с

С I DR-бл о к i p c i d r

[email protected] . 2 4 . 9/20

compound

c ompound

n o t G @ o s f ami l y : R e d H a t

1

c ompound

* . c l ou d . e x amp l e . c om

• это значение по умолчанию. Код соответствия не нужен ( и л и определен) . 6 0братите внимание на отсутствие пробелов; отдельные выражения не могут их содержать. ‘ Коды используются для обозначения отдельных терминов.

Часть lV. Эксплvатация

888

Есл и табл . 2 3 . 5 показал ас ь вам сложно й , не пере.жи вайте ; это просто варианты . Реал ьн ые селекторы гораздо бол ьше похожи на наш и простые примеры . Есл и вам интересно, с какими значениями зерен ил и базовых элеме нтов можно вы­ пол нять сопоставление, их легко узнать. П росто испол ьзуйте команду $ sudo salt минь он grains . i tems

ил и $ sudo salt минь он pillar . i tems

получения полн ого списка. Вы можете определить име нован ные группы в файле /etc/sal t/master. Они на­ зываются группами у311 о в (пodegroups) и полезны Дl! Я перемеще н ия сложн ы х селе кторов групп из файлов top . s l s . Тем не менее он и не являются исти н н ы м механ измом груп­ пировк и , а так.же способом именования шаблонов Д/J Я повторного испол ьзования. В ре­ зультате их поведение выглядит немного стран н ы м . Они могут быть определе н ы тол ь­ ко в терминах селе кторов типа c ompound (а н е , например, простым спис ком клиентов, есл и вы испол ьзуете спецификацию L @ ) и вы должны использовать явное сопоставле­ ние с типом групп ы узлов с помощью директивы match. Глобальной сокращенной фор­ м ы записи не существует.

Дl!Я

,

Состоя ния системы Salt Операции в системе Salt называются состояниями (states) . Как и в систе м е AnsiЬl e , они определены в формате YAM L, и на самом деле выглядят отдален но похожи ми на за­ дач и AnsiЫe . Однако их внутре н нее устройство совершенно разное. Вы можете вкл ю ­ ч ить серию определений состоян ий в файл s l s . Состоян ия привязаны к конкретным миньонам в файле top . s l s , который находится в корневой части ветви sal t базы конфи гурации. Эrот файл выглядит и работает точно так же, как файл top . sls Дl!Я привязок переменных; см. примеры , приведенные выше. Взгляните на следующую Sаlt- версию примера, который м ы испол ьзовали Дl! Я иллю­ страции с истемы AnsiЫe: м ы и нсталл ируем программу sudo и создаем соответствующую группу sudo , в которую мы добавляе м адм ин истраторов, у которых должны быть при­ вилегии sudo. Затем мы создаем группу учетных записей администратора, каждая из ко­ торых имеет собствен ную группу UN IX с тем же именем. Н аконец, м ы копируем файл sudoers из базы конфигураци и . К а к это часто б ывает, м ы можем испол ьзовать точ но такой ж е файл пере м е н н ы х Дl! Я с истем Salt , который м ы испол ьзовали Д/J Я AnsiЫe : .

sudoe r s_p a t h : / e t c / sudoe r s a dm i n s : — ( u s e rn ame : manny , f u l l name : Manny C a l a ve r a } — ( u s e rname : тое , f u l l name : Мое Mon e y }

Ч тобы эти определения были доступны все м м и н ьонам , м ы помещаем их в базу кон ­ фигурации в файле pillar/example . s l s и добавляем привязку в файл top . s l s . base : 1

* ‘ :

— e x amp l e

Вот Sаlt- версия этих операций . i n s t a l l — sudo-pac kage : p kg . i n s t a l l e d :

Глава 2 3 . Управление конфигурацией

889

— n ame : s u d o — r e f r e s h : true c r e a t e — s u d o — g r oup : g r oup . p r e s e n t : — n ame : s ud o { % f o r a dmi n i n p i l l a r . admi n s % ) c r e a t e — g r oup- { { a dmin . u s e rname ) ) : g r oup . p r e s en t : — n ame : { { admin . u s e rname ) ) c r e a t e — u s e r — { { admi n . u s e rname ) ) : user . present : — n ame : { { admi n . us e rname ) ) — g i d : { { a dm i n . u s e rname ) ) — g r oups : [ whee l , s u d o ] — f u l l n ame : { { a dmi n . f u l l name ) ) { % endfor % ) i n s t a l l — s udo e r s — f i l e : f i l e . ma n a g e d : — n ame : { { p i l l a r . s udoe r s_p a t h ) } — s ou r c e : s a l t : / / f i l e s / s udoe r s — u s e r : root — g roup : wh e e l — mode : ‘ 0 6 0 0 ‘

В этой версии показа н ы операции в их максимал ьно канон ической форме для более простого сравнения с эквивалентн ым спис ком задач AnsiЬe , которы й был рассмотрен ранее . Мы можем внести нескол ько дополн ител ьных изменений для улучшения приме­ ра, но с начала целесообразно рассмотреть эту более длин ную версию.

Система Salt и п реп роцессор Jinja П ервое , что нужно отметить, это т о , что данн ы й файл содержит цикл Jinja, ограни­ чен н ы й с и м волами { % и % } . Эти разделители похожи на { { и } } , за исключением того, что { % и % } не возвращают значе ния. Содержимое цикла интерпол ируется в файл YAM L столько раз, сколько раз выполняется цикл. W Общую информацию о языке Python см . в разделе 7 . 5 . В препроцессоре Jinja испол ьзуется синтаксис, подобн ы й си нтаксису языка Python. Однако в формате YAM L уже предусмотрен ы отступы в файле s l s , поэтому в препро­ цессоре J i nja вынуждено определ е н ы маркеры завершения блоков, такие как e n d f o r . В програм мах н а языке Python блоки обычно определя ются с помощью отступов. В базовой схеме УАМ L систе м ы Salt определена тол ько элементарная конструкция итераций (см . комме нтар и и по поводу директивы n a m e в разделе » Параметры и име­ на»). Условн ые и н адежн ые конструкции итерактивного выпол н ен ия должн ы предо­ ста вляться препроцессором Jinja ил и любым языком шаблонов, через которы й прого­ няется файл s l s . ( На самом деле система Salt тоже не анал изирует формат YAM L. Она просто пропус кает конфигурацион н ые файлы через вьщеле н н ы й кон вейер и получает конеч н ы й вывод в формате JSON , который должен быть полностью литерал ьн ы м . ) .

.

Часть lV. Эксплvатация

890

С одной сторо н ы , этот подход ясе н . Там нет кон цептуал ьной двус м ыслен ности в от­ ноше н и и того, что происходит, и ле гко прос мотреть расшире н н ы й файл . s l s , чтобы убедиться , что он соответствует ваш и м цел я м . С другой сторо н ы , это означает, что вы будете ис пол ьзовать пре процессор Jinja дл я обеспечения л юбой логи ки , необходимой для ваш е й конфигурации. Смешение кода шаблонов и формата YAM L может стать за­ трудн ительн ы м . Это нем ного похоже на написание логики веб-приложения с испол ьзо­ ван ием только НТМ L-шаблонов. Несколько эмп ирических правил могут помоч ь сохран ить конфигурацию Salt . Во­ первых, у с исте м ы Salt есть пригодные для испол ьзован ия и четко определен н ые меха­ н измы для реал изации зам ещения значений переменных. Испол ьзуйте их, чтобы сохра­ н ить как можно больше конфигурации в области дан н ых, а не в коде . Во м ногих примерах в документации Sat используются условн ые конструкции пре­ процессора Jinja, в то время как они не я вляются луч ш и м решением . 1 м Следующий файл s l s позволяет устано вит ь веб-сервер Apache, которы й имеет разные имена пакетов в разных дистрибутивах: .

# apache — p k g . s l s

apache : pkg . instal led : { % i f g r a i n s [ ‘ o s ‘ ] == ‘ RedHat ‘ % ) — n ame : h t tpd { % e l i f g r a i n s [ ‘ o s ‘ ] = = ‘ Ubun t u ‘ % ) — n ame : apache2 { % endi f % )

Этот вариант можно было бы более элегантно описать с помощью базового элеме нта ( pillars) : # apache-pkg . s l s

{ { p i l l a r [ ‘ apache -p kg ‘ ]

)):

pkg . installed # p i l l a r / t op . s l s base : ‘*’ : — d e f au l t s ‘ G @ o s : Ubuntu ‘ : — ubunt u # p i l l a r / de f aul t s . s l s apache — p k g : h t tpd # p i l l a r / ubuntu . s l s apache — p k g : apach e 2

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

1 к с правеД11 и вости ради укаже м , что ‘ЭТИ

при меры , как правило, предназначен ы Дl!Я иллюстраu и и полной корректности .

спеuифичных моментов и не стремятся к

Глава 2 3 . Управление конфигурацией

891

{ % s e t p kg_name ‘ h t tpd ‘ % 1 ‘ Ubuntu ‘ % 1 { % i f grains [ ‘ os ‘ ] { % s e t p k g_name = ‘ ap a c h e 2 ‘ % ) { % endi f % ) =

==

{ { p kg_name ) ) : pkg . installed :

Это по крайней мере позволяет отделить логику Jinja от фактической конфигураци и . Есл и вы вы нужден ы с м е ш и вать логику препроцессора J i nja с форм атом YAM L, поду­ майте , можете ли вы разбить некоторые сегменты YAM L на отдельные файл ы . Затем вы можете интерпол ировать эти сегменты по мере необходимости . И с нова идея состоит в том , чтобы просто отдел ить код и YAM L, а не чередовать их. Для н етривиал ьн ых выч ислен и й м ожно пол ностью отказаться от формата YAM L и зам е н ить е го ч истым языком Python или применить оди н и з предметной-ориентиро­ ванных языков, основанных на языке Python , который по умолчани ю использует систе­ ма Salt . Для получения допол н ительной и нформации с м . докуме нтацию Salt о ренде ­ ринге ( renderers).

Идентифи каторы состоя ний и зависимости Вернемся к нашему при меру sudo . Напомним еще раз е го первые два состояния. i n s t a l l — s ud o — p a c k a g e : pkg . installed : — name : sudo — r e f r e s h : t r ue c r e a t e — s u do — g r oup : g r oup . p r e s en t : — n ame : s u d o

Ле гко видеть, что отдел ьные состоя ния ямяются эле ментам и не сп иска ( как в систе­ ме AnsiЬle), а хеша. Хе ш — кл юч для каждого состоя ния — это произвольная строка, на­ зы ваемая идентификатором . Как обычно, идентификаторы должны быть уникальн ы м и . иначе возн икнут коллизии. Но подождите! П отен циал ьная область колл изий — это не только этот кон кретн ы й файл , н о и вся кл иентская конфи гурация. Идентификаторы состоян ий должны быть глобально ун икал ьн ы м и , потому что с истема Salt в конечном итоге собирает все дан н ые вместе в оди н бол ьшой хеш . Это довольно необычн ы й хеш , потому что о н сохраняет порядок ключей. В стандарт­ ном хеше при перечислении ключи поямяются в случайном порядке. Система Salt ра­ ботает именно так. В результате все завис имости между состояниями должны были быть объя вл е н ы явно. В настоя щее вре мя хе ш сохраняет порядок предста м е н и я по умол ­ чан ию, хотя это все равно можно переопредел ить, если объя м е н ы я вн ые зависимости (ил и если это поведе ние откл ючено в файле master) . Тем не менее есть е ще одна хитрость. П ри отсутствии других ограниче н и й порядок вы пол нения соответствует исходны м файлам s l s . Однако систем а Salt по- прежнему полагает, что состояния не логически зависят друг от друга, если вы н е утверждаете об­ ратное . Если состояние не выполняется , система Salt отмечает ошибку, но затем продол­ жает и запускает следующее состояние. Для того чтобы зависи мое состоя ние не запускалось, если е го предшестве н ники за­ вершил ись неудачей , можете объявить это явно. Например, так. .

Часть lV. Эксплуатация

892 c r e a t e — s udo — g r oup : g r oup . p r e s e п t : — пате : s udo — r e q ui r e : — i п s t a l l — s ud o — p a c k a g e

В этой конфигурации система Salt не будет пытаться создать группу s u d o , если пакет s u d o не будет успешно установлен. Реквизиты также вступают в действие при упорядоче н и и состоя н и й из нескол ьких файлов. В отличие от системы AnsiЫe, система Salt н е и нтерполирует содержи мое фай­ ла i n c l u d e в точ ке , где был обнаружен вызов. О н а п росто добавл яет файл в сп исок для чтения. Если несколько файлов пытаются вкл ючить оди н и тот же источн и к , в по­ следней сборке все еще будет только одн а коп ия источн ика. а порядок состояний может быть не так и м , как вы ожидали . Выполнение по порядку гарантируется тол ько в фай ­ л е ; если какие-л ибо состояния зависят о т внешне определенных операций , они должн ы объявлять явные реквизиты . Механ изм реквизитов также испол ьзуется для достиже ния эффе кта , аналогичного уведомлениям в системе AnsiЫe. Н ескол ько ал ьтернатив спецификации r e qu i re явля­ ются си нтаксически взаи мозаменяе м ы м и , но подразумевают тон кие оттенки поведения. Одн а из н их , w a t c h , особен но полезна, потому что позволяет выпол нять определенные действия , когда другое состояние вносит изменения в систему. Например, в следующей конфи гурации устанавли вается часовой пояс систе м ы и ар­ гументы , которые должны быть переда н ы де мону ntpd при запуске. Эта конфи гурация все гда гарантирует, что демон ntpd будет запущен и настроен для запус ка во время за­ грузки. Кроме того, она перезапускает ntpd, если обновляется либо с исте м н ы й часовой пояс, либо флаги ntpd. s e t — t i тe z oпe : t iтe z oп e . s y s t eт : — пате : Ame r i c a / Lo s_Aпge l e s s e t -пtpd-opt s : auge a s . chaпge : 1 9 — c o п t e x t : / f i l e s / e t c / r c . c oп f — l e п s : s h e l l va r s . l п s — chaпge s : — s e t пtpd_ f l a g s ‘ » — g » ‘ 2 0 пtpd : s e rv i c e . ruппiпg : — епаЫ е : t r u e — wat ch : — s e t — п t p d — op t s — s e t — t iтe z oпe

Функции состоя ния и выполнения В файле s l s имена, которые указываются непосредствен но под идентификаторам и состоян ия , я вля ются операция м и , которые должны выпол няться эти м и состоя н и я м и . В нашем примере есть две операци и p kg . i n s t a l l ed и g roup . p r e s e n t . .

19Augeas — это инструм ент, который пони мает множество разных форматов файлов и облегчает ав­ томатические изменен ия. 2»Как видно из этой строки , использование кавычек в формате YA M L может быть тон ким делом .

Глава 2 3 . Уп равление конфигурацией

893

В и менах этих операций включе н ы и м я модуля и и м я фун кции. Взятые в месте они примерно аналогичн ы имени модуля в с истеме AnsiЬJe, допол н е н н ы м значен ие м состо­ я н и я . Например, в системе AnsiЫe испол ьзуется пакет н ы й модуль со спецификацией s t a t e = p r e s e n t для установки пакетов, тогда как в системе Salt используется специ­ альная функция p kg . i n s t a l l e d в модуле p k g . В системе Salt сделано м ногое , чтобы отделить функции для целевых с истем ( »функ­ ции выпол н е н и я » ) от тех, которые идем потентно обеспечи вают определен ную конфи­ гурацию ( » функции состоя н и я » ) . Фун кции состоя н и я обы ч н о вызывают связа н н ы е с н и м и функции выполнения , когда и м необходимо внести изменен ия . Общая идея заключается в том , что в файлах . sls указываются только функции состоя­ ния, а в командных строках должны указываться только функции выполнения. Система Salt слишком примитивно применяет эти правила, что иногда приводит к путанице. Функции состоян и я и выполнения находятся в разных модулях Python, но связанные модули обыч н о имеют одно и то же и м я . Например, есть как модуль состояния часово­ го пояса, так и модуль выполнения часового пояса. Однако не может быть перекрытия имен функций м ежду этим и двумя модул ями , поскол ьку это создавало бы двусм ыслен­ ность. Конечн ы м результатом я вляется то, что для установки ч асового пояса из файла . sls вы должны использовать модуль t ime z o n e . s ys t em: s e t — t ime z o n e : t ime z on e . s y s t em : — n ame : Ame r i c a / L o s _An ge l e s

Однако, чтобы установить часовую зону м ин ьона и з командной строки , необходимо испол ьзовать модуль t ime z o n e . set z on e : $ sudo s a l t minion time zone . set_zone America/Los_Angeles

Если вы обратитесь к документаци и , то н а йдете описание двух половин модуля t i me z o n e в разн ых разделах руководства. Также не всегда ясно, как определить тип функции по ее поведению. Н апример, функция gi t . con f i g_ s e t , которая устанавлива­ ет параметр ы репозитория Git, я вляется функцией состоян и я , а s t a t e . a p p l y , которая идем потентно задает конфигураци и , я вляется функцией выполнения . В конечном счете вы просто должн ы знать фун кции и контексты, к которы м о н и прин адл ежат. Если в а м нужно в ызвать функцию из » н е правильного» контекста , что и ногда необходимо, вы можете испол ьзовать функции адаптера modu l e . r u n ( запуска­ ет функцию выполнения из конте кста состоян ия) и s t a t e . s i ng l e (запус кает функцию состо я н и я из конте кста выпол н е н и я ) . Например, адаптирован н ы е вызовы фун кций для задания часового пояса имеют следующий в ид: s e t — t ime z o n e : modul e . run : — name : t ime z one . s e t z on e — t ime z o n e : Ame r i c a / L o s_An ge l e s и

# salt minion state . s ingle time zone . sys tem name=America/Los_Angeles

Параметры и имена Еще раз приведем первые два состоян и я нашего примера. i n s t a l l — s u d o -p a c k a g e : p kg . i n s t a l l e d :

Часть lV. Эксплvатация

894 — n ame : s udo — r e f r e s h : t ru e create- sudo-group : g r o up . p r e s e nt : — n ame : s udo

П осле отступа под названием каждой операции (т.е. конструкцией модуль . функция) указы вается ее с писок параметров . В системе AnsiЫe параметры для операции образуют оди н бол ьшой хеш . Система Salt хочет, чтобы они были списком, причем каждая зап ись была предварена тире . Более конкретно, системе Sa t н ужен сп исок хеш е й , хотя в каж­ дом хеше обычно есть только оди н ключ. Большинство списков параметров содержат параметр с именем n ame , которы й явля­ ется стандартной меткой «того, что эта операция настраивает» . В качестве альтернативы вы можете указать сп исок целей в параметре с именем name s . Например: c r e a t e — g r o up s : group . p r e s e n t : — name s : — sudo — rvrn

Если вы задаете параметр n a me s , то с истема Salt повторно запус кает операци ю не­ сколько раз, подставляя оди н эле мент из списка name s вместо значения параметра n ame на каждом проходе. Это механический процесс , и сама операция не знает об итерации . Эта операция выполняется на этапе выполнен ия ( а не синтакс ического анал иза) и напо­ м инает конструкцию wi th i t ems в системе AnsiЫe . Но поскольку операция рас шире­ н ия Jinja уже завершена, у с исте м ы нет возможности форм ировать значения других па­ раметров на основе параметра name. Если вам н ужно настроить несколько параметров, игнорируйте параметр n ame s и просто повторяйте цикл Jinja. В н е кото р ы х оп е р а ц и я х м огут и с п ол ьзоваться сразу н ес кол ько аргум е н то в . Например, операция p k g . i n s t a l l e d может сразу передать нескол ько и ме н пакетов в базовый диспетчер пакетов операционной систе м ы , что может быть полезно для повы­ шения эффективности или распознавания зависимости. Поскол ьку система Salt скры­ вает итерацию на основе параметра name s , в подобных операциях н ужно испол ьзовать отдельное и м я параметра для в ы пол н е н ия пакетн ых операций . Например, состоя ния _

i n s t a l l — p a c k a ge s : pkg . installed : — name s : [ s udo , c u r l ]

и i n s t a l l — p a c k a ge s : pkg . installed : — p k g s : [ sudo , c u r l ]

инсталлируют программ ы sudo и curl . Первая версия делает это в двух отдельных опе­ рациях, а вторая — в одной . М ы подчеркиваем этот, казалось б ы , незначитель н ый моме нт, потому что пара­ метр n ame s легко испол ьзовать ошибочно. Поскольку процесс механический , итерация на основе параметра n ame s работает даже для тех операций , в которых н е используется параметр n a me . При просмотре журнала систе м ы Salt вы увидите , что несколько запу­ сков были успе ш но выполн е н ы , но целевая система почему-то по- прежнему не настро­ ена должны м образом, и нужно понять, что происходит.

Глава 2 3 . Управление конфигурацией

895

Есл и вы н е указываете я вно параметр n ame для состоя н и я , с истема Salt коп ирует в его поле идентификатор состояния. Вы можете использовать это поведение для упро­ щения определения состоян и й . Н апример, c r e a t e — s udo — g r oup : g r oup . p r e s e n t : — narne : s udo

становится sudo : g roup . p r e s e n t

и даже sudo : g r oup . p r e s e n t

Формат YAM L не допускает испол ьзование хеш — кл юч е й без значе н и й , поэтому те­ перь, когда фун кция g roup . present больше н е и меет перечисл е н н ы х параметров, хеш­ ключ долже н стать простой строкой , а не хеш — ключом со списком параметров в каче­ стве значения. Это хорошо! Система Salt проверяет это явно. Л акон ич н ы й стил ь более четки й , чем дли н н ы й . Отдельное поле идентификатора может теоретически служить комментарием ил и объяснением , но больши н ство иден ­ тификаторов, встречающихся в реал ьности, просто описывают поведение, которое уже очевидно. Если вы хотите добавить комм ентар и и , сделайте это. У лаконичной фор м ы есть потен ц иальная проблема: поскольку идентификаторы состоян ия должны быть гло­ бал ьно уникальн ы м и , короткие идентификаторы общих систе м н ы х объектов становятся более уязвим ы м и дл я коллизи й . Система Salt обнаружи вает и сообщает о конфли ктах , поэтом у это скорее досадная , чем серьезная п роблема. Но если вы пишете форм улу Salt с намере н ием повторно использовать ее в нескольких конфигурационн ы х базах или со­ бираетесь подел иться ею с сообществом Salt , придержи вайтесь иде нтификаторов , кото­ рые с меньшей вероятностью испытают коллизию. Система Salt позволяет включать несколько операций в одно состоя ние. Поскольку две приведе н н ы е выше операции содержат общее поле n a me , мы м ожем объеди н ить их в одно состояние без н еобходимости указывать в каких-либо состоя ниях поле name явно. Тем н е менее есть еще одн а ловушка YAM L: sudo : p kg . i n s t a l l e d : — r e f re s h : t rue g r oup . p r e s e n t : [ ]

Значение ключа s u d o те перь должно быть хешем; причем к этому хешу не должна добавляться строка g roup . p r e s e n t . Соответствен но, теперь мы должн ы рассматривать g r o u p . p r e s e n t как хеш — ключ и предоставлять явн ы й сп исок параметров в качестве значен и я , хотя этот список пуст. Это утверждение остается с праведл и в ы м , даже если м ы отброс и м параметр r e f r e s h из p kg . i n s t a l l e d : sudo : p kg . i n s t a l l e d : g r o up . p r e s e n t :

[) [)

Так же , как м ы свернули эти два состоян и я , м ы можем свернуть наши два состоян и я , которые управляют учетными записям и пользователей. Та к и м образом , бол ее аккурат­ ная версия списка состоян и й имеет следующий вид. sudo : p kg . i n s t a l l e d : g roup . p r e s e n t :

[] [)

Часть lV. Эксплуатация

896 { % for a dmin i n p i l l a r . a dmin s % } { { a dmin . us e r name } } : g r ou p . p r e s en t : [ ] u se r . p r e sent : — g i d : { { a dm i n . u s e r name } } — g r o up s : [ whe e l , s u d o ] — f u l l n ame : { { admi n . f u l l n ame } ) { % endfor % } { { p i l l a r . s u d o e r s_p a t h } ) : f i l e . ma n a g e d : — s ou r c e : s a l t : / / f i l e s / s udo e r s — u se r : root — g roup : whe e l — mode : ‘ 0 6 0 0 ‘

Привя зка состоя н и й к ми н ьонам О привязках состоя н ий в с исте ме Salt не так м ного можно сказать. Они работают точно так же, как привязки базовых элементов. В корн е вой иерарх и и состояния есть файл top . s l s , в котором задаются соответствия групп м и н ьонов файлам состоян и я . Приведем схематический пример. base : ‘*’ : — b o o t s t r ap — s itebase ‘ [email protected] o s : Ubuntu ‘ : — ubuntu ‘ G @ we b s e rve r ‘ : — nginx — webapps

В этой конфигурации ко всем хостам применяются состоян и я из файлов boots trap . s l s и s i tebase . s l s из корн я иерархи и состоя н и й . В системах Ubuntu также существу­ ет файл uЬuntu . s l s , поэтому веб-серверы (т. е . м и н ьо н ы с эле ментом верхнего уровня webs e rve r в своих базах данных о зернах) запускают состояния для настрой ки N G I NX и локальных веб-приложе н и й . П орядок в файле top . s l s соответствует общему порядку выпол н е н и я на каждом м и н ьоне . Но, как обычно, я вная и нформация о зависимостях в состоя н иях переопреде­ ляет порядок, принятый по умолчанию.

Состо ян ия высокого уровня С истема Salt относится к привязкам в файле top . s l s как к состоя н и я м высокого уровня м и н ьона. 2 1 Вы активируете состояние высокого уровня, приказывая м и н ьону за­ пустить функцию s t a t e . a pp l y без аргументов: $ sudo salt

.lfJIRЬOИ

s tate . apply

2 1 Существует поте н циальная тер м и нологическая п утан и ц а в том , что в с и стеме Salt также исп ользуется терм и н «состоян и е в ысокого уровня » (h ighstate) для обозн ач е н и я » разобранн ого и собранного JSON -дepeвa состоян ий » , которое затем переходит в «состоя ние н изкого уровн я » (lowstate) — J SON — дepe вa, которое п редставляет собой входн ые да н н ы е н и з кого уровн я для механизма вы п олнения.

Глава 2 3 . Управление конфигурацией

897

Функция s t a t e . h i g h s t a t e эквивалентна фун кц и и s t a t e . a p p l y без аргументов. Обе формы ш ироко используются. В частности , п р и отладке определ е н и й новых состоян и й вам может потребоватьс я , чтобы м и н ьон запус кал только оди н файл состоян ия . Это легко достигается с помощью функции s t a t e . a pp l y: $ sudo salt

HJUIЪOH

s tate . apply файл_состоянх.я

Не указывайте суффикс . sls в имени файла состоян ия ; система Salt добавит его само­ стоятельно. Также имейте в виду, что путь к файлу состояния не имеет ничего общего с ва­ шим текущим каталогом . Он всегда и нтерпретируется относительно корня состояния, как определено в файле конфигурации миньона. В любом случае эта команда не переопределяет состояние высокого уровня миньона; она просто запускает указанный файл состояния. В команде sal t можно указать несколько флагов для ориентации на разл и ч н ы е групп ы м и н ьонов, но проще всего запомн ить флаг -с для типа c omp o u n d и использо­ вать одно из сокраще н и й из табл . 23.5. Например, чтобы перевести все м и н ьоны Red Hat в состояние высокого уров н я , вы­ пол н ите следующую команду: $ sudo salt -с [email protected] os : RedHat s tate . hiqhs tate По умолчанию в типе сопоставления используется подстановка идентификатора, по­ этому команда $ sudo salt ‘ * ‘ s tate . hiqhs tate

представляет собой команду для » проверки всей конфигурации для сайта » . В соответствии с моделью в ы полнения Salt , ориентированной н а м и н ьоны , все па­ раллельные процессы выпол нения нач и наются одновременно, а м и н ьон ы не сообщают об этом до тех пор, пока они не завершил и свой процесс. Команда sal t выводит резуль­ таты работы каждого м и н ьона сразу же после и х получ е н и я . Невозможно отображать промежуточные результаты во врем я выполнения файла состоян ия . Если у вас м ного м и ньонов или сложная база конфигураци и , результаты п о умолча­ нию команды sal t могут быть довольно объе м н ы м и , потом у что она сообщает о каж­ дой операци и , выполняемой каждым м и н ьоном . Добавьте параметр — — state-output= mixed, чтобы умен ьшить этот вывод до одной строки для успешных операций и не вы­ зы вать н и каких измене н и й . Параметр — — s tate -verbose=fal se пол н остью подавляет вывод для операций без измене н и й , но систе ма Salt по-прежнему в ыводит заголовок и сводку для каждого м и н ьона.

Фор мулы Sa lt В системе Salt пакеты (bundles) н азы ваются формулами. П одобно рол и в системе AnsiЬle , это всего л и ш ь каталог файлов, хотя формул ы Salt имеют в н е ш н ю ю оболочку, которая также содержит некоторые метаданные и информ ац и ю о верс и и . В реал ьном испол ьзовани и вам просто н ужен внутре н н и й каталог форм ул. Каталоги форм ул входят в оди н из кор н е й каталогов sal t , определен н ы х в фай ­ ле mas te r . П р и желани и можно создать корен ь тол ько для формул . Формул ы иногда включают в себя пример базовых элементов, но вы сам и должны их инсталлировать. Система Salt ничего не делает для поддержки формул , за исключением того, что если вы указываете каталог в файле top . sls или испол ьзуете операци ю i n c l ud e , система Salt ищет файл ini t . yml в этом каталоге и и нтерпретирует его. Это соглашение обеспечивает понятны й путь по умолчанию в формуле. Во многие формулы также включены автоном­ н ые состояния, на которые вы можете ссылаться, указав как каталог, так и имя файла.

Часть lV. Эксплvатация

898

Н и что в с истеме Salt не может быть включено в конфигурацию более одного раза , это относится и к формулам . Вы можете сделать нес колько запросов на вкл ючен и е , но все о н и будут объедине н ы . В резул ьтате формулы н е могут быть создан ы нескол ько раз no образу и nодоби ю ролей в системе AnsiЫe. В л юбом случае это не и меет значения , nоскол ьку в систе ме Salt не определен н и ­ какой другой сnособ передачи параметров в формулу, кроме как путем ввода знач е н и й пере м е н н ых в базовом элементе . ( Выражения Jinja могут устанавливать значения пере ­ менных, н о эти параметры существуют только в конте ксте текущего файла.) Чтобы смо­ дел ировать эффект вызова формул ы повторно, вы можете предоставить данные базового эл емента в виде с п ис ка ил и хеша, чтобы формула могла выполнять итерацию самосто­ ятельно. Однако формула должна быть я вно наn исана с учетом этой структуры . Вы не можете навязать это постфактум . Центральным репозиторием Salt для предложен и й , внесенных сообществом , в насто­ я щее врем я я вл яется тол ько G it H ub. И щите формул ы Salt по и м е н и s a l t — f o rmu l a s . Каждая формула nредставляет собой отдельн ый прое кт.

Среды Ш Дополнител ьную информаци ю о средах с м . в разделе 26. 1 . С истема Salt nредпр и н имает усил ия в направл е н и и я вной поддержки сред (наnри­ мер , разделе н ие сред разработок , тестирова н и я и производства) . К сожал е н и ю , воз­ можности ее сред нескол ько своеобразн ы , и они не сопоставляются nрямо с наиболее рас nространен н ы м и практически м и случая м и реал ьного м ира. Можно получ ить среду и работать с небол ьш и м количеством определ е н и й и шаблонами Jinja , а потом обнару­ жить, что на практике м ногие организации просто вытас кивают и запускают отдел ьн ые главные серверы для каждой среды. Это хорошо соответствует стандартам безопасности и согласован ности, которые требуют разделения сред на сетевом уровне. Как м ы видел и ранее, в файле /etc/sal t/ma s ter указываются разл и ч н ы е места. где может храниться информация о конфигурации . О н также связывает среду с каждым набором путей . f i l e r o ot s : base : — / s rv / s a l t p i l l a r _ roo t s : base : — / s rv /p i l l a r

Здесь / srv/salt и / s rv/pillar это корневые каталоги состоя ния и базового эле­ ме нта с именем ba s e . Для простоты м ы не будем упоминать н иже о базовых элементах; уnрамение окружающей средой работает одинаково для обеих ветвей базы конфигурации. В сайтах с более чем одной средой обычно добавляется допол нител ьный слой в ие­ рархию каталога конфигурации , чтобы отразить этот факт. —

file roots : base : — / s rv / b a s e / s a l t devel opmen t : — / s rv / d e v e l opme n t / s a l t p r oduc t i on : — / s rv / p r oduc t i o n / s a l t

(Очевидно, что у этого прим ера н ет тестовой среды . Н е п ытайтесь делать это дома!)

глава 2 3 . Управление конфигурацией

899

В среде может быть указано нескол ько корневых каталогов. Если их нескол ько, сер­ вер прозрач но объединяет их содержимое. Однако каждая среда в ыпол няет отдельное слия н и е , и конечные результаты остаются разделен н ы м и . Внутри файлов top . sls ( привязки, которые связывают м и н ьоны с конкретн ы м и со­ стояниями и файлами столбцов) ключи верхнего уровня всегда являются именами окру­ жения. До сих пор мы видел и только примеры, в которых испол ьзовалась базовая среда, но, конечно, в этом месте может использоваться любая подходящая среда. Например, так. ba s e : — global deve l opme n t : ‘ * — d ev ‘ : — web s e rve r — da t a b a s e produc t i o n : ‘ * we b * — p r od ‘ : — we b s e rve r ‘ * db * — p r o d ‘ : — databas e

Точ н ы й и м порт внешнего вида среды в файл top . s l s зависит от того, как в ы на­ строили с истему Salt . Во всех случаях среды должны быть определены в основном фай­ ле; файл ы top н е могут создавать новые среды. Кроме того, файлы состоя н и й должн ы исходить из контекста среды , в котором он и упоминаются. По умолчанию система Salt н е связывает м и н ьоны с какой-либо кон кретной средой , а м и н ьонам могут быть присвоен ы состоян ия из л юбой ил и всех сред в файле top . s l s . В приведен ном в ы ш е фрагменте , например, все м и н ьон ы запускают состоян ие global . sls из базовой среды . В зависимости от их идентифи каторов отдел ьные м и н ьоны могут также получать состоян ия из среды производства или разработки.22 Докуме нтация Salt поощряет этот с пособ настрой к и окружения , но у нас есть не­ которые оговорк и . Одна из потен циальных проблем закл ючается в том , что м и н ьон ы выводят элементы конфигурации из нескольких сред. Вы не можете отследить источни­ ки произвольной конфигурации м и н ьона до одной кон кретной среды в определ е н н ы й момент времен и , потому что у каждого м и н ьона есть несколько родителе й . Эг о различие важно, потому что одна базовая среда должна совместно испол ьзовать­ ся всем и другим и средам и . Какой она должна быть? Версией базовой среды для разра­ ботки’? П роизводствен ной версией? Полностью отдел ьной и многоуровневой базой кон ­ фигурации? Когда именно вы должн ы перенести базовую среду на н овую версию? Кром е того, существуют допол н ител ьн ые сложности , скрывающиеся за сценой . Каждая среда представляет собой пол ноце н ную иерархию конфигураци и Salt , поэто­ му теоретически она может иметь собстве н н ы й файл top . s l s . Кажды й из этих файлов top . sls теоретически может относ иться к нескольким средам . Стал киваяс ь с такой ситуацие й , система Salt пытается объеди н ить все файл ы top в одну сложную фрагментарную конфигурацию.23 Среды могут требовать выпол н е н ия 21 Когда вы устанавли ваете идентифи катор м и н ьона в соответствии с шаблоном разработки или nроизводства. вы функционально связываете его с соответст вующей с ре дой . Однако сама система Salt не делает я вной ассоциаци и , no край ней мере не в этой конфи гураци и . 21Слия ние n роисходит на уровне YAML. хотя было бы лучше надеяться, что несколько файлов top не будут п ытаться назначать состояния одному и тому же шаблону соответствия в той же среде . Есл и они это сделают, некоторые состоя ния будут nроиrнорирова н ы .

часть lV. Эксплvатация

900

других состоя н и й , которы м и он и не владе ют, не контрол ируют и не знают о них ничего. Это было бы ужасно, если бы это не было так глупо. Н е понятно, какие сценари и использования эта архитектура пытается сделать возмож­ н ы м и . Хотя слияние файлов top — это поведение, принятое по умол чанию, документа­ ция постоянно предостерегает вас от этого. Вместо этого вам рекомендуется для управле­ н ия всем и средами назначить оди н файл top . sls, скорее всего, в спецификации ba s e . Однако, есл и в ы это сделаете , вскоре станет очевидно, что между этим » внеш н и м » файлом top и остальными средами существует некоторое организационное противоре ­ чие. Файл top я вляется неотьемлемой частью конфигурации среды , поэтому состояния и файл ы top обычно разрабатываются совместно; изменение одного часто требует изме­ нений в другом. Создавая отдельный файл top , вы должны по существу разделить каж­ дую среду на две части , которые необходимо си нхронизировать вруч ную. Кроме того . главн ы й файл top должен быть общим , синхронизированным и совместим ы м со всем и другим и средами. Например, если вы организовы ваете тестовую среду для производства, вы должны убедиться , что главн ы й файл top . s l s н астроен так , чтобы отражать пра­ вильные настройки для конкретной версии нового выпуска. В качестве альтернати вы можно подключ ить м и н ьоны к заданной среде , установи в значение переменной envi r onmen t в файле /etc/sal t/minion на мин ьоне или вклю­ чив флаг s a l t e nv= cpeдa в командные строки системы Salt. В этом режиме м и н ьон ви­ дит тол ько файл top . s l s с воей назначен ной среды . В этом файле top е го представле­ ние также ограничено запися м и , которые отображаются в этой среде . Например, маш ина, прикрепленная к среде разработки , может видеть файл top . s l s из предыдущего примера в сл едующей сокращен ной форме (есл и предположить, что файл top . s l s был найден в корне дерева разработки). deve l opme n t : ‘ * -dev ‘ : — w e b s e rv e r — d a t ab a s e

Этот режи м работы нем ного ближе к тради ционной кон цепции сред ы , ч е м приня­ тый по умолчан ию. Здесь не может возн и кнуть непреднамеренная перекрестная ком му­ н и кация между среда м и , что ограничивает возможность непреднамерен ного поведения. Также преимуществом я вляется то, что по мере продвижен ия кон кретной версии базы конфи гурации через цепочку окруже ния разл и ч н ые части файла top . s l s автоматиче­ ски применяются к клиентам . Основ н ы м н едостатком я вл я ется то , что вы теряете с пособность учитывать части конфигураци и , общие для более чем одной среды . Н ет н и какого встроен ного способа «видеть» вне контекста текущей среды, поэтому элементы базовой конфигурации долж­ ны быть репл ицированы в каждую среду. Файл top . s l s из предыдущего примера, переписа н н ы й для работы в контексте это­ го подхода, будет выглядеть примерно так. deve l opme n t : ‘ * ‘ : — global ‘ * -dev ‘ : — web s e rv e r — databa se p r od u c t i on : ‘ * 1 : — g l ob a l

Глава 2 3 . Управление конфигурацией

901

‘ * web * -p r o d ‘ : — web s e rv e r ‘ * db * -p r od ‘ : — d a t ab a s e

Базовая среда сама по себе ямяется руди ме нтарной , поэтому мы искл юч ил и ее из файла top . s l s и скопировал и прежнее содержимое этого кл юча н е посредстве н н о в среды разработки и производства. И мейте в виду, что мы сейчас работаем в мире, где каждое дерево среды имеет свой собствен н ы й файл top . s l s . В этом примере м ы предполагаем , что файл top . sls в обе­ их средах я мяется оди наковы м , поэтому одно и то же содержимое поя вится в обе их ко­ пиях top . s l s . Конечно, ручное воспроизведе ние элементов общей конфигурации внутри каждой среды подвержено ош ибкам. Лучшим вариантом ямяется определение общей конфигу­ рации как макроса J i nja, чтобы он мог повторяться автоматичес ки. { % ma c r o b a s e l i n e ( ) % } ‘* : — g l ob a l { % e n dma c r o % } 1

deve l opme n t : { { basel ine ( ) } } ‘ * — de v ‘ : — webs e rve r — d a t aba s e p r oduct i o n : { { basel ine ( ) } } ‘ * we b * — p rod ‘ : — web s e rv e r ‘ * db * — p r od ‘ : — databas e

В этом сценар и и м ы предполагаем , что все м и н ьон ы привяза н ы к определ е н н ы м среда м , поэтому теперь м ы можем потенциально удал ить индикаторы среды и з иденти­ фикаторов м и н ьонов. Тем не менее целесообразно сохранить их для безопасности . П робл е м а в том , что м и н ьо н ы контрол ируют с вои собстве н н ые настройки сред ы . Например, если м и н ьон в среде разработки был скомпрометирован , он м о г б ы объявить себя производствен н ы м сервером и потен циал ьно получить доступ к кл ючам и конфи­ гурац ия м , используе м ы м в п роизводстве н ной среде. 24 ( Это, пожалуй, одна из прич и н , п о которой документация п о системе Salt проя вляет определен ную осторожность в ре­ комендациях по закреплению окружающей среды . ) Н астрой ка конфи гура ции кон кретной среды с учетом к а к параметров сред ы , так и идентификаторов м и н ьонов защищает от этой разновидности атак. Если м и н ьо н из­ меняет свой идентификатор, главн ы й сервер бол ьше не рас познает его как одобре н н ы й клиент и и гнорирует д о тех пор , пока администратор н е утвердит это измене н ие с по­ мощью команды sal t-key. Если вы предпочитаете не испол ьзовать иде нтификаторы таким образом , альтерна­ тивой я мяется использование данных базовых элементов для пере крестной проверки. 24Проблема заключается не в состоян и и конфи гурации, так как мин ьоны имеют свободн ы й доступ ко всем файлам состоя н и я . Она связана с дан н ы м и базовых эле ментов, которые собираются на главной стороне и обычно должны быть защище н ы .

902

Часть lV. Эксплvатация

Независимо от того, что вы делаете , вы не можете nросто отказаться от суфф и кса и nре­ вратить ‘ * -dev ‘ в ‘ * ‘ , nотому что в общей части конфигурации уже исnользуется суффи кс ‘ * ‘ в качестве ключа. Повторяющиеся шаблоны в среде — это нарушен ие правил YAM L. При отладке среды вы обнаружите , что нескол ько фун кций выполнения оказывают­ ся особенно nолезны м и . Ф ун кция c o n f i g . g e t вы водит значение, которое исnол ьзует определенный м и н ьон (или н абор м и н ьонов) для nараметра конфигурации. $ sudo salt new- client-dev config . get environment new- c l i e n t — de v : d e v e l opme n t

Здесь м ы види м , что м и н ьон с иде нтифи катором n e w — c l i e n t — de v б ы л nри вязан к среде разработки , так же как и е го идентификатор. Чтобы узнать, как выгл ядит кон ­ фигурация top . s l s с точки зре ния м и н ьона, исnол ьзуйте фун кцию s ta t e . s how t op . _

$ sudo s a l t new- client-dev s tate . show_top

n e w — c l i e n t — de v :

d e v e l opme n t : — g l ob a l — we b s e rv e r — database

Н а выходе отображаются только т е состоя н и я , которые активны и выбра н ы дл я це­ левого м и н ьона. Други м и слова м и , они я вляются состоян и я м и , которые будут вы nол ­ нятьс я , если вы nрименяете фун кцию s t a t e . h i gh s t a t e к этому м и н ьону. Обратите внимание на то, что все отображаемые состояния nостуnают из среды раз­ работки. П оскольку м и н ьон закрепл е н , это будет nроисходить все гда.

Документация Документация систе м ы Salt ( d o c s . s a l t s t a c k . com) , вероятно, заслуживает восхи­ щен и я , но тол ько nосле nериода разочарова ния. Основная проблема заключается в том , что тем ы расположен ы на н ескол ьких вложен н ых слоях, но заголовки в двух верхних слоях н е обязател ьно указывают н а то, что вы найдете на третьем слое. Например, в раз­ деле «Архитектура» нет информации об архитектуре Salt (на самом деле в нем реч ь идет о многосерверных развертываниях). Н екоторые из наиболее полезных справоч ных материалов находятся в разделах, ко­ торые организованы как сценарии или учебные пособия. Последовательное чте н ие ино­ гда может вызы вать у систе м н ых адм и н истраторов пол ное разочарование: те м ы под­ н и маются циклически и закрываются без nолного описания. Краткий момент ясности л и ш ь nодчеркивает тяжесть вашего состоян и я . П одскажем не которые ориентиры. • Верхн и й раздел Using Salt представляет собой обзор кон цеп ц и й , а бол ьшая часть раздела Conjiguration Management помечена как учебное пособие. Из-за их форма­ тов эти раздел ы выгл ядят как допол нительные материал ы . Н о это неправда; они в значител ьной степени я вляются основной докуме нтацией для материала, кото­ рый они охватывают. Не n ропустите их. • Наил учшая справоч ная информация находится под ссьш кой System Reference в раз­ деле Conjiguration Management. М ногие вещи здесь не важны при nервом чте н и и , но разделы Нighstate data structure definitions, Requisites and other g/obal state arguments и Тhе top file особенно полезно n роч итать. ( Раздел Тор file также я вляется автори ­ тетной документацией по среда м . )

Глава 23. Управление конфигурацией •

903

Документы , которые вы будете использовать наиболее часто, описывающие фу нк­ ции состоян и я и выполнения , скрыты под ссыл кой Salt Modu/e Reference и зама­ скирова н ы среди 19 других типов модулей, которые в основном и нтересуют раз­ работчиков модулей. Отметьте для себя раздел ы Full list о/ builtin state modu/es и Full list о/ builtin execution modules.

2 3 . 7 . (РАВНЕНИЕ СИСТЕМ

ANSIBLE и SALT

Нам нравятся как AnsiЫe, так и Salt. Однако каждая из этих систе м имеет некотор ые особенности , и м ы рекомендуе м их для разных сред. В приведе н н ых н иже разделах мы проком ме нтируем несколько факторов, которые следует уч иты вать при выборе между ними.

Гибкость развертыва н ия и масштабируемость

Систе ма Salt охваты вает более ш ирок и й диапазон условий разверты ван и я , ч е м AnsiЫe. О н а достаточ но простая , так что вы можете ис пол ьзовать е е для управления од­ н и м сервером , но система Salt масштабируется без усили й и практически без о rрани•1 е ­ н и й . Есл и вы хотите изучить одну систему, которая охваты вает максимально широкий диапазон вариантов использования, Salt хороший выбор. Ч астично это с вязано с те м , что архитектура систе м ы Sat предъя вляет относител ьно небольшие требования к главному серверу. М и н ьоны получают свои и нструкци и и не сообщают о н их до тех пор , пока они не будут в ы пол н е н ы , при этом вся и н формация о состоя н и и будет сообщена сразу. М и н ьон ы вызы вают сервер для пол уч е н и я дан н ы х конфигурации , н о , пом имо выдачи дан н ых о базовых элементах, с а м сервер выпол н яет относительно небольш ие вычисления. Как только ваша организация перерастет размеры одноrо главною сервера системы Salt , вы можете преобразовать свою инфраструктуру в многоуровневую ил и реruшцированную схему сервера. М ы не рассматриваем эти варианты в дан ной книге, но их легко настроить. Крупные развертывания я вляются сравн ительно слабым местом для системы AnsiЫe . О н вкл ючает часть фун кций , которые помогут вам внедрить многоуровневые сервер н ы е систем ы , но переход к этой модели не так прозрачен , к а к в Salt. Система AnsiЫe на порядок медлен нее , чем Sat, и из-за своей архитектуры она долж­ на обрабатывать клиенты партиями. Однако большинство серверов могут обрабаты вать гораздо больше , чем пять одновременных клиентов по умолчан ию. Вы также можете и.з­ мен ить страте ги ю выполнения AnsiЬle , чтобы клие нты не держал ис ь в строгом порядке друг с другом. Даже настроен ная система AnsiЫe не будет прибл ижаться к скорости с и ­ стемы Salt , но о н а лучше, чем можно было бы наивно ожидать. —

Встроенные модули и расш иряемость Разработч и ки програм м н ого обес печения для управле н ия конф и гурацией и н о гда пытаются срав н и вать количество типов операци й , которые разл и ч н ые с исте м ы под­ держи вают автоматически . Однако эти сравнения трудно осуществить корректно из- за ос новополагающих структурн ы х разл и ч и й . Например, фун кции , которые распростра ­ ня ются по нескол ьким модулям в системе AnsiЫe, могут быть сосредоточе н ы в одном модул е в систе ме Salt Атомарная операция в одной системе может соответствовать не­ скол ьким операциям в другой.

904

Часть lV. Эксплvатация

В настоящее время систе м ы Salt и AnsiЫe примерно сопоставим ы в этом отнош е н и и . В допол н е н ие к обш ирн ы м стандартным библиоте кам , обе с исте м ы и меют структуру мя внедрения модулей , написанн ы х сообществом разработчи ков, в ядро или легкодо­ ступ н ы й допол н ительн ы й п акет. В л юбом случае , общее количество модулей не и меет значе н и я почти так же , как охват систем и программ ного обеспечени я , которые факти­ чески используются в вашей организации. Все систем ы С М полностью управляют базо­ в ы м и операциям и , но по мере глубокого погружения в н их вы будете обнаруживать все новые и сильно различающиеся возможности. Вероятно, вы в кон е ч ном итоге захотите решить часть задач , мя которы х в ваш е й системе С М не существует готового реш е н и я . К счастью, систе м ы Salt и AnsiЫe легко рас ш иряются с помощью собствен ного кода Python. Учтите эту рас ш иряемость на ран­ ней стадии и при н еобходимости используйте ее.

Безопасность Как указано в разделе ‘» П араметры доступа в системе AnsiЫe» , ее можно сделать прак­ тически сколь угодно безопасной. Единстве н н ы й предел безопасности — ваша собствен ­ ная готовность заново набирать пароли и справляться с бюрократией безопасности . Систе м а хра н е н ия дан н ы х AnsiЫe позволяет хран ить данн ы е конфигурации в за­ ш ифрован ном формате . Это на самом деле довольно большое достижен и е , означающее , что н и сервер AnsiЫe , н и база конфигурации не должны быть особен но безопас н ы м и . ( М одульная архитектура Salt, вероятно, позволяет легко добавить эту фун кцию, н о она не входит в первоначальный компле кт поставки.) Напротив, система Salt может быть л и ш ь настол ько же безопасной, насколько без­ опасной я вляется учетная запись r o o t на главном сервере . Хотя сам главн ы й демон прост в настройке, сервер, на котором он запускается , должен получать самую сил ьн ую защиту в ваше й органи заци и . В идеале мастер должен быть машиной ил и виртуал ьн ы м сервером, специально предназнач е н н ы м м я этой задачи . На практике адми нистраторы н е н авидят сл и ш ком навязчивые п ротоколы безопас­ ности , также как и все остальные пользователи . Большинство реальных объектов AnsiЫe и м е ют относител ьно слабую защиту. П одобн о тому, как с истем а AnsiЫe м ожет быть с коль угодно сил ьн о защи щенной , ее также можно сделать с коль угодно небезопас ­ ной. Даже если вы попытаетесь полностью защитить систему AnsiЫe , возможно, вам н е удастся сохранить этот подход, к а к только рост ваше й организаци и достигнет того м о ­ м ента, когда управление конфигурацией может выполняться путем ввода команд в окне тер м инала администратором . Например, л юбое задание планировщика cron может тре­ бовать от адми нистратора ввода пароля. Работа над этим ограничением неизбежно при­ водит к с н иже н и ю безопасности до уровня учетной зап иси r o o t . Суть безопасности заключается в том , что система AnsiЫe дает в а м больше к а к по­ лезных, так и вредных возможностей . Она допускает более гибкое управление уровня м и безопасности , но это н е обязательно означает, что о н а более безопасна. Л юбая с истем а подходит мя средней организации. Учитывайте ваши собствен н ые потребности и огра­ ничен ия при оце н ке этих систем.

Разное Некоторые дополнител ьные сильные и слабые сторон ы систем AnsiЫe и Salt приве­ ден ы в табл . 23.6 и 2 3 . 7 .

Глава 2 3 . Управление конфигурацией

905

Таблица 23 . 6 . Преимущества и недостатки системы AnsiЫe Недостатки

Преимущества

Требуется только SSH и Pythoп; нет демонов

Очень медленно работает

Четкая и краткая документация

Требует мощного сервера; труднее масштабировать

Встроенные циклы и условные обозначения, мини­ мальный Jiпja

Множество файлов с одинаков ыми именами

Отлично работает от имени непривилегированного пользователя

Специфический синтаксис YAM L

Операции могут использовать выходные данные друг друга

Ясное и гибкое использование конфигурационных каталогов.

Высокая безо п асность; возможность шифрования

Много разных областей видимосn.1 переменных

Роли могут создаваться несколько раз

Отсутствие демонов означает меньшее количество возможностей

Более крупная база пользователей, чем у системы Salt Нет реальной поддержки сред Таблица 23. 7. Преимущества и недостатки системы Salt Недостатки

Преимущества

Быстро работает

Зависит от Jiпja

Проще, чем АпsiЫе

Странно организованная документация

Гибкие, непротиворечивые привязки

Плохая поддержка непривилегированных пользователей

Интегрированная поддержка облачных серверов

Формулы не могут быть включены более одного раза

Краткий синтаксис конфигурации

Нет встроенного решения для шифрования

Многоуровневые серверные развертывани я

Нет доступа к результатам операций

Контроль структурированных событий

Минимальная поддержка стандартных значений переменных

Журналы выполнения легко экспортируются

Требуются явные объявления зависимостей

Исключительно модульная

Исключительно модульная

2 3 .8. РЕКОМЕНДАЦИИ Если вы работаете н ад программ н ы м проектом , то можете обнаружить, что м н огие пробл е м ы , с вя за н н ы е с с исте м а м и управл е н и я конфи гурацией , характер н ы для раз­ работки п рогра м м . Среда разработки и м еет м н ого схожих характер истик : несколь ко платфор м , н есколько верс и й продукта , полученных из одной и той же кодовой базы , несколько типов сборок и конфигураци й и развертывание с помощью последовательных этапов разработки, тестирования и производства. Это слож н ы е вопрос ы , а среды разработк и — это всего л и ш ь и н струм е н т ы . Разработчики испол ьзуют множество допол нител ьн ы х элементов управл е н ия — руко­ водящие принципы разработки , принципы п роектирова н и я , стандарты кодирования , внутрен н юю документацию и четкие архитектурные границы, среди прочего — ограни­ чение с кольжения по направлен и ю к э нтропии. К сожален и ю , адми н истраторы часто блуждают по территории управления конфигу­ рацией без надлежащего набора инструментов разработчи ка. На первый взгляд управле-

906

Часть lV. Эксплvатация

н и е конфигурацией кажется обманч и во простым , как нем ного более общий и сложный способ подходить к рутинным задачам сценариев. Поставщики систем управления кон ­ фиrурацией стараются усилить это впечатление. Их веб-сайты по леrкости и изяществу можно сравн ить с пес н я м и с и ре н ; на каждом из н их есть учебное пособие, в котором показано, как развернуть веб-сервер, выпол н и в всего десять строк кода конфиrурации . Н а самом деле край пропасти может быть ближе , ч е м кажется , особен но коrда н е ­ сколько администраторов вносят вклад в одну и ту ж е конфигурационную базу с течением времени. Реальные характеристики даже для одноrо целевого сервера выполняются сотня­ ми строк кода, разделен н ых на несколько разных фун кциональных ролей. Без координа­ ции леrко превратить систему С М в путаницу конфл иктующего или параллельного кода. Рекомендации зависят от систе м ы управления конфигурацией и среды, но для боль­ ш инства ситуаций применяется несколько правил. •

Держите базу конфигураций под управлением систе м ы контроля верс и й . Это не столько полезная рекомендация, с колько базовое требование корректности С М ­ с исте м ы . Система Git н е только отслеживает изменения и истори ю изменени й , но и решает м ноrие механ ические п робл е м ы , связанные с коорди нацией проектов через админ истративные границы. Базы конфигураций по своей сути иерархич н ы , по крайней мере в лоrическом с м ысле . Не которые стандарты п р и м е н я ются во всех орrан изациях, н е которые при м е н и м ы к каждому серверу в определенном отделе или реrионе, а некоторые относятся к кон кретны м хостам . Кроме тоrо, вам , скорее всеrо , понадобится воз­ можность в определен н ых случаях делать искл ючения. В зависимости от операций вашей орrани зации вам также может потребоваться поддержка нескольких неза­ висимых иерархий. Планируйте всю эту структуру заранее и рассмотрите , как в ы можете управлять сценариями, в которых разные rруппы управля ют разными ч астя м и базы конфи­ гурации . По крайней м ере соrлашения для классификации хостов (например, эк­ зем пляры ЕС2 , хосты, подкл юче н н ы е к И нтернету, серверы баз дан ных) должны быть с координ ированы по всей орrанизации и последовательно соблюдаться. Систе м ы С М позволя ют хранить разл и ч н ые части базы конфигурации в разн ых каталоrах или хранил и щах. Однако эта структура обеспечивает н ебольшую фак­ тическую выrоду и усложняет повседневную работу по н астройке. Мы ре ком е н ­ дуем испол ьзовать одн у бол ьшую и нтегр и рова н н ую конфи rурацион н ую базу. Управлен ие иерархие й и координацию следует осуществлять на уровне G it . Конфиденциальные данные (ключи, пароли) н е должн ы попадать в систему кон ­ троля верс и й , если о н и не зашифрова н ы даже в локал ь н ы х репозиториях кода. Система G it , в частности , н е предназначена для обеспечения безопасности. Ваша система СМ может иметь встроенные функции ш ифрования, но если нет, создайте свои собстве н н ые . П ос кольку сервер конфигурации и меет доступ к учетной записи r o o t н а м ноrих других хостах, о н явля ется одн и м и з наиболее концентрирова н н ы х источн и ков р иска для безопасности вашей орrанизации . Разум но выделить с пециальный сер­ вер для этой рол и , которы й должен получить самую строrую защиту. Кон ф и rураци и дол ж н ы вы пол няться без сообще н и й о побоч н ы х эффе ктах . Сце н ар и и и команды оболочки обы ч н о являются самы м и круп н ы м и точ ками преткновения. Ознаком ьтес ь с документацией вашей систе м ы СМ для получения

Глава 23. Управление конфигурацией

907

консул ьтаций по этой теме, так как это одна из наиболее частых п роблем , с кото­ рой сталкиваются пользователи . •

Н е выпол н яйте тести рование на производствен н ых серверах. Н о в ыпол няйте те ­ сты! Легко развернуть тестовую систему в облаке или в среде Vagrant. Система Chef даже предлагает продуман ную с истему тестирования и разработки в виде среды Kitchen. Убедитесь, что ваша тестовая система соответствует ваш и м реал ьн ы м си­ стемам и что в не й испол ьзуются одн и и те же образы маш и н ы и конфигурация сети.

Ознако м ьтесь с кодом допол н ител ь н ы х па кетов, которые вы получаете из от­ крытых репозиториев. Дело н е в том , что эти источн и к и чем -то подозрител ьн ы ; просто системы и соглашения сильно различаются. В о м ногих случаях вы обнару­ жите , что требуется несколько локал ьн ы х настроек. Если вы можете обойти дис­ петчер пакетов С М и клонировать пакеты напрямую из репозитори я Git , вы мо­ жете легко пере йти на более поздние верс и и без потери настроек.

Безжалостно разделя йте конфи гураци и . Кажды й файл должен и м еть четкую и единую цел ь. ( Пол ьзователи системы AnsiЫe могут выбрать текстовый редактор, который хорошо сочетается с 50 различными файлам и , все с именем main . yml . )

Управляемые конфигурацией серверы должн ы управляться на 1 00 % . И наче гово­ ря , не должно быть и намека на адми н истративную работу, которая была выпол ­ нена вруч ную и которую н и кто не знает, как реплицировать. Эта проблема воз­ н и кает, прежде всего, при перемеще н и и существующих серверов под управление конфигурацие й . 25

Не позволяйте себе или вашей команде » временно откл ючать» с истему С М на хо­ сте ил и испол ьзовать руч ной метод переопредел е н ия систе м ы С М ( например, установку неизменяемого атрибута в файле конфигураци и , которы й обычно на­ ходится под контролем системы С М ) . Эти изменения неизбежно забываются , воз­ н икают беспорядки или сбои.

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

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

В гибких облачных средах, где выч исл ител ьная мощность добавл яется в ответ на запрос в реальном времени, вре м я , которое требуется для загрузки нового хоста с помощью системы управления конфи гурацией , может быть мучительно м едлен —

н п ри п реобразова н и и существующего сервера «снеж и н ка» в уnраален и е конфи гурацией может оказаться полез н ы м клони ровать исходную систему для испол ьзован ия в качестве основы для сравне н и я . Можно также вы полнить нес колько ци клов упраален и я конфи гурацией и тестирова ­ н и я , чтобы учесть все особенности систе м ы .

Часть lV. Эксплvатация

908

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

Если в ы используете н астройку конфигурации для установки параметров конфи­ гурации для приложен и я , убедитесь, что этот этап в ы полняется н а ранней стадии процесса начальной загрузки, чтобы приложение стало работать быстрее. Для ди­ намически м ас штабируе м ых хостов мы п ытаемся ограничить вре м я выпол н е н ия систем СМ до м енее 60 с. Как адми нистратор , работающий с системой СМ, вьщел ите большую часть своего врем е н и на создание кода С М , тестирование измен е н и й в репрезентативном на­ боре систе м , передачу обновлен и й в репозитори й и внесение поэтапных изме не ­ н и й в ваше й организации. Чтобы быть наиболее эффективн ы м , вы должны совер­ шенствовать этот процесс , затрач и вая врем я на изуч е н ие луч ш и х рекомендаций и приемов дл я ваш е й системы.

2 3 .9. Л ИТЕРАТУРА •

CowIE , JoN . Customizing Chef· Getting the Most Out о/ Your Infrastructure Automation . Sebastopol , СА: O ‘ Reilly Media, 20 1 4 .

FRANK, FELIX, AND M ARТJ N ALFKE. Puppet 4 Essentials (2nd Edition) . Birrningham , U K: Packt PuЫishing, 20 1 5.

G E ERLING, JEFF. Ansiьte for DevOps: Server and conflguration management for humans. St. Louis, М О : Midwestem Мае , LLC, 20 1 5 . Эта книга ориентирована на основные противоречивые спор ы , но она в кл ючает в себя также н екоторы е полезные ма­ териалы об объединении с исте м ы AnsiЫe с конкретными системам и , такими как Y.igrant , Docker и Jenkins.

Hocнsт E I N , LoR J N . Ansiьte: Ир and Running (2nd Edition) . Sebastopol , СА: O ‘ Reilly Media, 20 1 7 . П одобн о к н и ге Ansiьte for DevOps, эта к н и га охватывает как ос но­ вы AnsiЫe , так и взаимодействия с общ и м и средам и , так и м и как Vagrant и ЕС2 . Н екоторые основные моменты включают в себя более крупную примерную кон ­ фигурацию, главу о написании собствен н ы х модулей AnsiЫe и советы п о отладке.

MoRRI S , KIEF. Infrastructure as Code: Managing Servers iп the Cloud. Sebastopol, СА: O ‘ Reilly Media, 20 1 6 . Эта книга содержит несколько специфических особен н остей управления конфигурацией как таковой, н о она помогает понять, как управление конфигурацией внедряется в более крупную схему DevOps и структурирован ное адми нистрирование.

SEBENIK, C RAIG , AND Тномдs Ндтсн . Salt Essentials. Sebastopol , СА: O ‘ Re i l ly Media, 20 1 5 . Это короткая и довольно схематич ная книга, которая из.лагает основы с исте­ мы Salt. Это не стил ь книги, которы й мы обычно рекомендуе м , но, учитывая нео­ бычность официал ьной документации, это поте нциально полезная ссыл ка для тех, кто ищет «альтернативное мнение » .

TAYLOR, М 1 sснА, AND SЕтн VARGo. Learning Chef» А Guide to Conflguration Management and Automation. Sebastopol , СА: O’ Reilly Media, 20 1 3.

UPНILL, Тномдs, AND JoнN ARU N DEL. Puppet Cookbook (Зrd Edition) . B i rmingham , U K: Packt PuЫishing, 20 1 5 .

глава

24

Вир туализация

Виртуализа ция серверов позволяет одновременно запускать нескол ько экзем пляров операцион ной систем ы на одном физическом оборудован ии. П рограмм ное обеспечение виртуализации управляет ресурсами центрального процессора, памяти и устройств вво­ да-вы вода, динамически рас пределяя их испол ьзование среди нескол ьких » гостевых» операционных систем и разрешая возникающие при этом конфл и кты. С точ ки зре ния пользователя виртуальны й сервер выглядит как полноце н н ы й физический сервер. W Дополнительную информацию о контейнерах см. в главе 25. Эта концепция отделения аппаратных средств от операционной систе м ы дает м ного­ численные выгоды . В иртуализированн ые серверы более гибкие, чем их физические ана­ логи. Они допус кают перенос и могут управляться программ но. Основное оборудование используется более эффективно, поскольку оно может обслуживать несколько гостевых операцион ных систем одновременно. И есл и этого недостаточно, технология виртуали­ зации испол ьзуется как в облач ных вычислениях, так и в контейнерах. Реал изации виртуал и зации изм е н ились с года м и , но основные концепции не новы для отрасли . Фирма I BM ( Big Blue) еще в кон це 1 960-х rr. ис пол ьзовала систему вирту­ альн ых маш и н на своих больших Э В М ( мэйнфреймах) , исследуя кон цепции разделения време н и . Те же самые подходы испол ьзовались в период буйного расцвета мейнфреймов в 1 970-х гг. до возн и кновения кл иент-серверноrо бума 1 980-х гг. , когда сложность реа­ лизации виртуал изации на основе архитектуры l ntel х86 привела к короткому периоду относител ьного затишья .

91 0

Часть lV. Эксплуатация

Посто я н н о расту щ и й размер серверн ых ферм вызвал и нтерес к виртуал и за ц и и для соврем е н н ы х с истем . VМware и друrие поставщики р е ш и л и проблем ы , связанные с процессорами х86 , и упростили автоматическое предоставление операционных систе м . В конечном итоге эти средства привели к росту с истем управления в иртуальны м и сер­ верами , подключен н ы м и к И нтернету и в ыделяющим ися по мере необходимости. Все это создало и н фраструктуру, которую мы теперь называем облачн ы м и вычисле н и я м и . Совсем недавно достижения в области в иртуализации на уровне операционной систем ы открыли новую эру абстракции операционных систем в виде контейнеров. В этой главе мы начнем с разъясн е н и я тер м и нов и понятий , необходим ы х для по­ нимания виртуализаци и для с истем U N IX и Linux. Затем мы опишем ведущи е реше н ия для виртуализаци и , используемые в н аши х примерах операцион н ых систе м .

24. 1 . ВИРТУАЛЬНЫЙ ЖАРГОН Терминология , испол ьзуемая дл я описани я виртуализации , несколько непрозрачна, в основном из-за того, как эволюционировала технология . Конкурирующие продавцы работали независи м о друг от друга без испол ьзовани я стандартов, что приводило к по­ я влению множества двусмысленных выражений и акронимов. 1 Чтобы еще бол ь ш е запутать п робл е м у, сама » ви ртуал изация » я вл яется перегру­ жен н ы м тер м и н о м , которы й описывает бол ьш е , чем п р иведе н н ы й выше с це н а р и й , в которо м гостевые операцион ные с исте м ы работают в контексте в иртуал и зован ного оборудовани я . В иртуализация н а уровне операцио н н ых систе м , обычно называемая контейнер изацией , — это связан н ы й , но другой набор средств, который стал столь же вездесущи м , как и в иртуализация серверов. Тем , кто н е имеет практического опыта ис­ пользования этих технологий , часто бывает трудно понять разл и ч и я . Мы срав н и ваем эти два подхода далее в этом разделе .

Гипервизоры Гипервизор (также известны й как монитор виртуальной машины) представляет собой программ н ы й уровен ь, который посредничает между в иртуал ь н ы м и маш и н а м и (VM ) и базовы м оборудовани е м , на котором они работают. Гипервизоры отвечают за совмест­ ное использование с истемных ресурсов среди гостевых операционн ы х с исте м , которые и зол ирова н ы друг от друга и которые получают доступ к оборудован и ю исключител ьно через гипервизор. Гостевые операционн ы е с исте м ы независи м ы , поэтом у о н и не должн ы быть оди на­ ковым и . Например, CentOS может работать вместе с Free B S D и Wi n dows. П р и м ера м и гипервизоров я вл яются VMware E S X , XenServer и Free BS D bhyve. В иртуальная машина на базе ядра Linux ( КУМ) преобразует ядро Linux в гипервизор.

полная виртуализация Первые гипервизоры полностью эмул ировали базовое оборудование, определяя вирту­ альные подстановки для всех основных вычислительных ресурсов: жестких дисков, сете­ вых устройств, устройств управления прерываниями, материнских плат, BIOS и т.д. В этом режим е , называемом полной виртуализацией , гостевые операционные с истемы запускают’ Здесь приходит в голову закон Конвея ( Conway): «Орга н и заци и , которые п роектируют систе м ы, вынужден ы создавать проекты, которые я вляются коп и я м и коммуникационных структур этих ор­ ганизаци й » .

Глава 24. Виртуализация

91 1

ся без каких-либо изменений, что существенно сн ижает их с корость работы , потому что гипервизор должен постоян но выполнять преобразование между реальным оборудовани­ ем ком пьютера и виртуал ьн ым оборудованием гостевых операцион ных систем. Имитация всего персонал ьного компьютера — сложная задача. Больши нство гиперви­ зоров, которые предлагают полную виртуализацию, отделя ют задачу поддержки несколь­ ких сред (виртуал изации) от задачи имитации оборудования в каждой среде (эмуляция). Наиболее распростране н н ы м пакетом эмуляции , ис пол ьзуе м ы м в этих с истемах, яв­ ляется прое кт с открыты м исходным кодом под названием Q E M U . Более подробную информацию вы можете найти на сайте q emu . o r g , но в бол ьш и н стве случае в эмулятор не требует пристал ьного вн имания со сторон ы админ истраторов.

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

Апп аратная виртуализация В 2004 и 2005 гг. ком пании l ntel и AM D представили фун кции процессора ( l ntel VГ и AM D-V) , которые способствовали виртуализации на платформе х86. Эти расширения позволяли реализовать «аппаратную виртуализаци ю » , также известную как «ускорен н ая виртуализация». В этой схеме процессор и контроллер памяти виртуализируются с помо­ щью аппаратного обеспечения, хотя и под управлением гипервизора. Производительность такой системы очень хорошая , и гостевые операцион ные системы не должны знать, что они работают на виртуал ьном процессоре . В наши дн и виртуал изация с помощью аппа­ ратного обеспечения является основным трендом. Хотя центральный процессор является основной точкой сопри косновения между аппарат­ ным обеспечением и гостевыми операционными системами, это всего лишь один из компо­ нентов системы. Гипервизор все еще нужен в некотором роде для предстамения или эмуля­ ции остальной части аппаратного обеспечения системы. Для этой задачи можно использовать полную виртуализацию или паравиртуализацию. В некоторых случаях используется сочетание подходов; это зависит от степени «осведомленности» гостевой системы о виртуализации.

Паравир mуализованные драйверы Одно большое преимущество аппаратной виртуал изации за кл ючается в том , что она в знач ител ьной степени огра н и ч и вает необходи мость поддержки паравиртуал изации на уровне драйверов устройств. Все операционные систе м ы позволяют добавлять допол­ нител ьные драйверы , поэтому настрой ка гостевой с истемы с паравиртуал и зован н ы м и дискам и , видеокартам и и сетевыми интерфейсами т а к ж е проста, как установка соот­ ветствующих драйверов. Драйверы знают » секретн ы й протокол » , который позволяет им испол ьзовать фун кции поддержки паравиртуализации ги пернизора, а гостевая операци­ он ная система остается н е в курсе дела. Н ескол ько досадных аспе ктов архите ктуры персональн ы х ком п ьютеров , таких как контроллер преры ван и й и ресурсы B I O S , не попадают в кате гори ю процессоров или драйверов устройств. В прошлом преобладающим был подход, который закл юч ал ­ с я в том , чтобы реал изовать эти оставш иеся компоне нты посредством пол ной вирту-

Часть lV. Эксплvатация

91 2

ал изаци и . Например, режим Н УМ Xen (ап паратная виртуал ьная маши на) объеди няет поддержку расш ире н и й виртуал изации на уровне процессора с коп и е й эмулятора П К Q E M U . Режи м РУНУМ ( ParaYi rtualized НУМ ) добавляет к этой схеме парави ртуал и­ зированные драй веры в гостевых операционных систе мах, что знач ител ьно сокращает объе м пол ной виртуал изации, необходи м ы й для поддержания работы систе м ы . Тем не менее гипервизору по-прежнему нужна акти вная копия Q E M U для каждой виртуальной маш и н ы , чтобы она могла покрывать возможности и цел и , не затрон утые паравиртуал и ­ зова н н ы м и драй вера м и .

Современная виртуализа ц ия В самых последних верс иях Xe n и других гипервизоров бол ее ил и менее устранена необходимость в эмуляции устаре вшего оборудова н и я . Вместо этого он и полагаются на фун кции виртуализации на уровне процессора , паравиртуал изова н н ые драйверы го­ стевой операцион ной систем ы и нескол ько допол н ител ьн ых разделов паравиртуал изо­ ван ного кода в гостевых ядрах. Xen называет этот режим РУН ( ParaYirtual ized Hardware), и он считается близким к идеал ьной комби наци и , которая дает оптимальную произво­ дител ьность, но выдви гает м и нимал ьно возможные требования к гостевым ядрам . Н а практи ке ил и п р и чте н и и документации в ы можете стол кнуться с любым из ва­ рианто в виртуал и за ц и и , описа н н ы х вы ш е . Однако не стоит запом и н ать ка кую-л ибо кон кретную терминологи ю или сл ишком беспокоиться о виртуал изацион ных режимах. Границы между эти м и режи мами являются нечетки ми , и в гипервизоре обычно реализо­ ван ы луч ш и е варианты для дан ной гостевой операцион ной систе м ы . Есл и вы обновите с вое програ м м ное обеспечение, то автоматически получ ите вы году от последн их улуч­ ш е н и й . Еди нствен ной причиной выбора чего-л ибо, кроме режи ма работы по умолча­ нию, я вляется поддержка старого оборудован ия или устаревших ги первизоров.

Типы zипервизоров Во многих с правоч н ых материалах сделаны несколько сомнительн ые различия между гипервизорам и «типа 1 » и «типа 2 » . Гипервизор типа 1 работает непосредственно на аппа­ ратном обеспечении без поддержки операционной системы, и по этой причине его иногда называют ап паратным ил и маш и н но-зависимым гипервизором. Ги первизоры типа 2 это приложе н ия для пользовательского пространства, которые работают поверх другой операционной системы общего назначения. Эти две модел и показаны на рис. 24. 1 . —

Тип 1

Гостевая ОС

Гостевая ОС

Тип 2

Гостевая ОС

Гипервизор типа 1 Память ЦП I/O Аппаратное обеспечение

Гостевая ОС

Гостевая ОС

Гостевая ОС

Гипервизор типа 2 ОС хоста Память ЦП I/O Аппаратное обеспечение

Рис. 24. 1. Сравнение гипервизоров типа 1 и 2

Глава 24. Виртуализация

91 3

Гипервизоры VMware ESXi и Xe n S e rve r расс матри ваются как т и п 1 , а Free B S D bhyve — как т и п 2 . Аналогично пакеты виртуал изаци и , ориентирова н н ые н а рабочую станцию, такие как Virtual Box и VMware Workstatioп от компан и и Oracle, также отн осят­ ся к типу 2. Это правда, что систе м ы типа 1 и 2 отличаются друг от друга, н о разгран иче н ие не всегда такое четкое . Например, гипервизор КУМ представляет собой модуль ядра Linux, которы й предоставляет виртуал ьн ым маши нам прямой доступ к фун кция м виртуал иза­ ции процессора. Дифферен циация между типам и гипервизоров и меет с корее акаде м и ­ ческое , чем практическое значение.

Динамическая миграция В иртуал ьные маш и н ы могут переме щаться м е жд у гипервизорам и , работающ и м и на разных физических устройствах, в реал ьном времен и , в некотор ых случаях без пере­ рывов в обслуживан ии ил и потери связи. Эта фун кция называется динамической мигра ­ цией. Ее се крет закл ючается в переносе памяти между исход н ы м и и целевыми хостами. Ги первизор коп и рует изменения из источ н и ка в п ун кт н азначен и я , и как тол ько па­ мять становится идентичной , м и грация завершается. Динам ическая м и грация полезна для балансировки нагрузки в системах высокой досту пности, аварийного восстановл е ­ н ия , обслужи вания серверов и обще й гибкости систе м ы .

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

К онтейнеризация Виртуал изация н а уровне операционной системы, или конте й н еризация , — это дру­ гой подход к изоляции, в котором не используется ги первизор. Вместо этого испол ьзу­ ются функции ядра, которые позволяют изолировать процессы от остальной с исте м ы . Каждый контейнер процесса (container, ил и jai l ) имеет персонал ьную корневую файло­ вую систему и пространство имен процессов. П роцессы , содержащиеся в контейнере, совместно используют ядро и другие службы хост-систе м ы , но он и н е могут обращаться к файлам или ресурсам за пределами своих конте й неров. Эта архитектура проилл юстри­ рована на рис. 24. 2 . Ш Дополнительную и нформацию о контей нерах см. в главе 25. Поскол ьку для контей неризации не требуется виртуал и зация, накладн ые расходы на ресурсы для виртуал изации на уровне операционной систе м ы н и зки . Бол ьш инство реал изаций предлагают почти естествен ную производител ьность. Однако этот ти п вир-

Часть lV. Эксплуатация

914

туал иза ц и и искл ючает испол ьзован и е нескол ьких операцион ных систе м , пос кол ьку ядро хоста испол ьзуется всем и контейнерам и . 2 При мерами реал изации контейнеров я в­ ля ются контейнеры LXC и Docker в систе ме Linux, а также Jail в системе Free B S D .

Хост-процессы пользовательского пространства

Процессы в контейнерах Процессы в контейнерах Процессы в контейнерах

Ядро хост-системы I/O Память ЦП Аппаратное обеспечение Рис. 24.2. Контеiшеризация

Л е гко пере путать конте йнеры с виртуал ьным и машинам и . Оба определя ют перено­ с и м ые изолированные среды исполнения, и оба выглядят и действуют как полноце н н ые операцион ные систе м ы с корневыми файловы м и системами и запуще н н ы м и п роцесса­ м и . Однако их реал и зация совершенно различна. И сти нная виртуал ьная машина и м еет ядро операцион ной систе м ы , процесс и н и ци ­ ал изаци и , драй веры для взаимодействия с оборудован ием и полные атрибуты операци­ онной систем ы U N IX. С другой сторон ы , контей нер я вл яется п росто фасадом опера­ ционной с исте м ы . Он испол ьзует стратеги и , оп исан ные выше , чтобы дать отдельн ы м процессам подходящую среду испол н е н и я . В табл . 2 4 . илл юстри руются н е которые практические различия между этими конце п циями. Таблица 24. 1 . Сравнение виртуальных машин и контейнеров Виртуальная маwина

Контейнер

Полнофункциональная операционная система, которая совместно использует базовое оборудо­ вание с помощью гипервизора

Отдельная груп па процессов, управляемых совместно используемым ядром

Требуется полная процедура начальной загруз­ ки для инициализации ; начи нает работу через 1 — 2 минуты . . Долговр еменные

Процессы запускаются непосредственно ядром; не требуется начальная загрузка; начинает работу менее 1 . .. …. . . . . . . . . Часто заменяемые

. .. …… … …

. . . . . . . .. . . . . .

..

Имеет один или несколько виртуальных дисков, выделенных гипервизором Размер образа измеряется в гигабайтах

Образ файловой системы представляет собой много ­ уровневую структуру, оп ределенную контейнером

Не больше нескольких десятков на каждый физи­ ческий хост

Большое количество на каждый виртуальный или фи ­ зический хост

Полная изоляция гостевых операционных систем

Ядро операционной системы и службы совместно ис-

Несколько независимых операционных систем, работающих одновременно

В контейнере должно использоваться то же ядро , что и на хосте ( версии операционных систем могут раз­ личаться )

· · · — — — — — — — — — — · — — — — · — — — — — · — — · — · · — — · · · ·

·•

Размер образа измеряется в мегабайтах

. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . • . . . . . . . . .

2Это не совс е м та к . Урове н ь эмул я u и и L i п u x неров L i п ux н а хостах Fгee B S D .

о

с и стеме

Fгee B S D допус кает и с п ол ьзова н и е конте й ­

Глава 24. Виртуализация

91 5

Об ы ч н о конте й н е р ы ис пол ьзуются в соч ета н и и с в иртуал ь н ы м и м а ш и на м и . Виртуальн ые машины — луч ш и й способ разделить физические серверы н а управляемые части. Затем вы можете запус кать п риложен ия в контей нерах на виртуальн ых машинах для достиже ния оптимальной плотности систе м ы (эту п роцедуру иногда называют » упа­ ковкой контейнера» (Ьin packing) . Архитектура контей неров на виртуальной машине яв­ ляется стандартной для контейнеризованных приложе н и й , которые должн ы запускаться в общедоступных облачн ых средах. В остал ьной части этой главы м ы сосредоточ имся на настоя щ е й виртуал изац и и . Более подробно контейнеризация описана в главе 2 5 .

24. 2 .

ВиРТУАлиздция с помощ ь ю системы L1Nux

Ведущими проектами с открыты м кодом по виртуал изации с исте м ы Linux я вляют­ ся две платформ ы : Xen и КУМ . Платформа Xen теперь я вляется частью прое кта Liпux Foundation и испол ьзуется для реал и зации крупнейших открытых облач ных платформ , в том ч исле Web Services ком п а н и и Amazon и Soft Laye r компан и и I B M . Платформа KVM — виртуальная машина, интегрированная в ядро с исте м ы Linux. Систе м ы Xen и KVM продемонстрировали свою стабильность на примере м ногих пром ышленных и н ­ сталляций в крупных орган изациях.

П латформа Xen Изначально Linuх-ориентированная платформа Xen была разработана Я ном П раттом ( lan Pratt) как иссл едовател ьский проект Кембриджского у н и верс итета ( Unive rsity of Cambridge) . Со временем она стала мощной платформой для виртуал изаци и , которая благодаря п роизводительности , безопасности и дешевизне о казалась способной кон ку­ рировать даже с ком мерческими гигантам и . Накладн ые расходы, связан ные с эксплуатацией паравиртуальноrо гипервизора вир­ туальной машины Хеп , составляют 0 , 1 -3 , 5 % , что намного меньше, чем у пол ностью виртуализованных платформ . П оскольку гипервизор Xen является програм мой с откры­ тым исходн ы м кодом , существует м ножество средств с разн ы м и уровнями поддержки ее функционал ьных возможностей . Исходный код платформы Xen можно загрузить на сайте xenpro j e c t . o r g . Кроме того, она входит во многие дистрибутивны е пакеты Linux. Xen — это автономный гипервизор, которы й функционирует непосредствен но на фи­ зическом аппаратном обеспечен ии. Работающая виртуальная машина называется доме­ ном. Всегда существует по край ней мере оди н домен, который называется нулевым ( ил и dom O ) . Н улевой домен и м еет пол н ы й доступ к ап паратному обеспеч е н и ю , управляет другим и доменами , в нем запускаются драйверы всех устройств. Непривилегированные дом е н ы называются domu. В домене d o m O обыч н о запускается дистри бути в Linux. Он в ы глядит, как и все остальные дистрибутивы систе м ы Linux, но вкл ючает демон ы , средства и библ иоте к и , которые допол н я ют архитектуру Xen и обеспеч и вают взаимодействие между доменами domU , d omO и гипервизором. Гипервизор отвечает за распределение времени централ ьного процессора и управле­ ние памятью для все й систе м ы в целом . Он также управляет все м и доменам и , включая domO . Однако следует заметить, что работа самого гипервизора контрол ируется и управ­ ляется из доме на d omO . Как все запутанно! Наиболее и нтересные части домена domO для системы Linux перечислены в табл . 24.2.

Часть lV. Эксплуатация

91 6

В каждом конфигурацион ном файле гостевого домена, который находится в каталоге / etc/xen указываются виртуальные ресурсы , доступные для домена domu, включая диско­ вые устройства, процессор, память и сетевые интерфейсы . Каждый домен domU имеет от­ дельн ы й файл конфигурации . Формат является гибким и дает администраторам хороший контроль над огра ничен иями, применяем ыми к каждой гостевой системе. Если символ и ­ ческая ссьmка на файл конфи гурации d omU добавляется в подкаталог auto , эта гостевая операционная система автоматически запускается во время начальной загрузки . Табnица 24 . 2 . Компоненты nnатформы Xen П уть

Назначение

/etc/xen

К аталог основной конфигурации Конфигураци онные файлы гостевой о п ерационной системы для автоматического за ­ пуска во время начальной загрузки Вс п омогательные сценарии , создающие сетевые интерфейсы и т. д. Файлы журналов платформы Хеп Средство для уп равления гостевым доменом на платформе Хеп

auto scripts /var/ log/xen /us r / sЬin/xl

И нсталля ция гостевой операцион ной системы на платформе Xen Создан ие гостевого сервера и его запуск на платформе Xen состоит из нескольких этапов. Для упрощения этой процедуры м ы рекомендуем испол ьзовать программу virt­ manager (vi r t -ma nag e r . o r g ) . П рограмма virt-manager изначально бьmа частью про­ екта системы Red Hat, но в настоя щее время ее код стал открытым и доступн ы м для боль­ ш и н ства дистрибутивов Linux. В него входит утилита virt- i n s ta l l , запускаемая из командной строки для и нсталляции операционной системы. Она может использовать раз­ личные источ ники для инсталляции ОС, например устройства сетевой файловой системы SMB или N FS, физические CD- или DVD- приводы или U RL НТТР-ресурса. Диски гостевых доменов обычно хранятся в виртуальных блочных устройствах (VBD) в домене d om O . VBD можно подключ ить к вьщелен ному ресурсу, например физическому диску или логическому тому. Кроме того, это может бьrrь файл Loop Back, также известный как УВD-файл , созданный с помощью команды dd. Выделенный диск ил и том обеспечи ­ вают более высокую производительность, н о файлы — более гибкий инструмент, которы м можно упрамять с помощью обычн ых команд Linux (таких как mv и ер) в домене d om O . VВD-файлы это разреженные файлы, которые увеличиваются п о мере необходимости. Есл и в с истеме нет проблем с производительностью, VBD с файловой поддержкой , как правило, я вляется луч ш и м выбором. Существует п ростой процесс переноса У В D ­ файлов н а выделен н ы й диск на случай, если вы передумаете . Н апример, и нсталляция гостевого домена может быть выполнена с помощью следу­ юще й команды . —

$ sudo virt-install -n chef -f /vm/ chef . img -1 http : / /example . com/myos -r 5 1 2 — -nographics

Это типич н ы й гостевой доме н на платформе Xen с именем c h e f , дисковы м устрой ­ ством V B D , размещен н ы м в каталоге /vm/chef . img, и средой инсталляции, пол уч е н ­ н о й с помощью протокола Н ТТ Р. Этот экземпляр имеет 5 1 2 двоичн ых М ибибайт ( M i B) оперативной памяти и не испол ьзует во время инсталляции графическую поддержку Х Windows. Утил ита virt-install загружает файл ы , необходимые для начала и нсталля ­ ци и , а затем запус кает процесс инсталлятора.

Глава 24. Виртуализация

91 7

Вы увидите пустой экран и пройдете через все стандартн ые этапы и нсталл я ции с исте ­ мы Liпux в текстовом режиме, вкл ючая конфигурирование сети и выбор пакета. После инсталляции гостевой домен перезагружается и готов к использованию. Для отсоединения от гостевой консоли и возвращения в домен domO нажмите . Несмотря на то что в дан ном примере испол ьзуется текстовая инсталляция , возмож­ на также графическая поддержка этоrо процесса с помощью с исте м ы Virtual Network Computing (VN C ) . Конфигурация домена хранится в файле /etc/xen/ chef. Этот файл в ы глядит сле ­ дующим образом. name = » ch e f » uuid = » a 8 5 e 2 0 f 4 — d l l b — d 4 f 7 — 1 4 2 9 — 7 3 3 9Ы d 0 d 0 5 1 » maxmem = 5 1 2 memo r y = 5 1 2 vcpu s = 1 boot l oa d e r = » / u s r / b i n / p y g r ub » on_powe r o f f = » de s t r o y » on reboot = » re s t a rt » on c r a s h = » r e s t a r t » vfb = [ ] di s k = [ » t ap : a i o : / vm / c he f . ds k , xvda , w » vi f = [ «mac= 0 0 : 1 6 : 3 e : l e : 5 7 : 7 9 , b r i d g e = x e nb r 0 «

Как в идим , по умолчанию сетевой интерфейс настрое н на мостовой режим . В нашем случае устройство VB D представляет собой » блоч н ы й » файл , обеспеч и вающий более высокую производительность, чем стандартный Loop Back файл . Файл образа диска, до­ пускающий зап ись, предоставлен гостевой ОС под именем /dev/xvda. Утилита xl удобна для ежедне вного управления виртуальн ы м и ма ш и на м и , напри­ мер для их запуска и остановки , подключения к их консол я м и исследования текущего состоян и я . Н иже м ы выводим с писок запуще н н ых гостевых доменов, после чего под­ кл ючаемся к консол и маш и н ы c h e f домена d omU . Идентификатор ы присваиваются в порядке возрастания по мере создания госте вых доменов. П р и перезагрузке хоста их нумерация сбрасывается. $ sudo xl l i s t Mem ( Mi B ) ID Name 2 502 о Doma i n — 0 19 512 che f $ sudo xl console 1 9

VCPUs 2

State r——

ь—-

T ime ( s ) 397 . 2 12 . 8

Для того чтобы измен ить конфи гурацию госте вого домена (например, подкл ючить другой диск ил и перевести сеть из мостового режима в режи м N AT) , необходимо от­ редактировать гостевой конфигурацион н ы й файл в каталоге /etc/xen и перезагрузить гостевую с истему.

П латформа KVM КУМ ( Kemel-based Virtual Machine) это средство пол ной виртуал изации, вкл юча­ емое по умолчан и ю в больш инство дистрибутивов систе м ы Linux. Н еобходим ы м усло­ вием его применения я вляется наличие рас ширений це нтрального процессора I ntel УТ и AM D-V для поддержки виртуализаци и . В типичных с це нариях установки для реал и ­ заци и полностью виртуал ьной систе м ы аппаратного обеспечения ис пол ьзуется Q EM U . Хотя эта с исте ма изначально была предназначена для Li11ux, ее можно перенести в си­ стему Free B S D в виде загружаемого модуля ядра. —

Часть lV. Эксплуатация

91 8

П ос кольку в систем е КУМ по умолчан и ю реал изован режим полной виртуали за­ ц и и , поддерживаем ы й на уровне аппаратного обеспечен и я це нтрал ьного процессора, под ее управлен и е м могут работать м н огие гостевые операцион н ы е с исте м ы , вкл ю­ чая Windows. Существуют драйверы паравиртуал и зован ной сетевой пл аты Etherne t , диска и графической карты дл я систем Linux, Free B S D и Wi ndows. И х испол ьзование не обязательно, но рекомендуется для повышения производительности. Н а платформе КУМ ядро операцион н ой с истем ы Linux фун кционирует как гипер­ визор; управл е н и е памятью и диспетчеризаци я выпол ня ются с помощью ядра хоста, а гостевые маш и н ы представля ют собой обы ч н ые процесс ы Linux. Этот уникал ьн ы й подход к виртуализации сул ит огромные преимущества. Например, сложность, порож­ дае мая м ногояде р н ы м и процессорам и , устраняется с помощью ядра систе м ы , и для их поддержки не требуется в носить н икаких изменений в гипервизор. Команды Linux, на­ пример top, p s и k i l l , управляют виртуал ьн ы м и маш инами так, будто они явля ются обычным и процессами. Инте грация с системой Linux является безупречной.

Инсталля ция гостевой операцион ной системы на платформе KVM и ее испол ьзова ние Н есмотря на то что технологии , лежащие в основе платформ Xen и КУМ , принципи­ ально отличаются друг от друга, и н струменты, и нсталлирующие гостевые операционные с исте м ы и управляющие ими, похожи друг на друга. Как и на платформе Xen, для созда­ ния новых гостевых систем по технологии КУМ можно использовать програм му virt­ install , а дл я управления ими — команду virsh. Флаги , передаваемые програм м е virt-instal l , могут немного отличаться от фла­ гов , ис пользуе м ы х при инсталляции платформ ы Xen . Например, флаг — — hvm означа­ ет, что для в иртуализации гостевой систе м ы должно использоваться аппаратное обе­ спечени е , а не паравиртуализация. Кром е того, аргумент — — connect гарантирует, что по умолчани ю будет выбран правильны й гипервизор, потому что утил ита virt-install поддерживает несколько гипервизоров. В заключ е н и е , чтобы получить выгоду от воз­ можностей платформ ы КУМ , рекомендуется использовать аргуме н т — -accelerate. Следовательно, пример пол ной команды для инсталл и рования гостевого сервера Ubuntu с диска СО- ROM должен выглядеть следующим образом. $ sudo virt- install — — connect qemu : / / / sys tem

n UЬuntuYakkety -r 5 1 2 -f �/uЬuntu-Yakkety . img -s 12 -с /dev/dvd — — o s — type l inux — -accelerate — -hvm — -vnc W o u l d you l i ke t o е n а Ы е g r ap h i c s s uppo r t ? ( ye s or по ) —

Е сли дистрибутивн ы й DУD-диск для систе м ы Ubuntu вставлен в дисковод, эта ко­ манда запус кает процесс и нсталляции и сохраняет гостевую систему в файле — /uЬuntu­ Yaketty . img, позволяя увел и ч и вать его размер до 1 2 Гбайт. П оскол ьку мы не указали ни флаг — -nographics, ни флаг — -vnc, утилита virt-install с прашивает, включать л и поддержку графики. Утил ита virsh запускает собственную оболочку, которая вы пол няет команды . Для того чтобы открыть эту оболоч ку, н аберите команду virsh — — connect qemu : / / / sys tem. Следующая серия команд демонстрирует н екоторые основные фун кциональ­ ные возможности утилиты virsh. Для того чтобы увидеть полн ы й сп исок этих команд, наберите команду help в оболочке или просмотрите справочную страницу. $ sudo virsh — -connect qemu : / / / system v i r s h # l i s t — -all State Id N ame

Глава 24. Виртуализация

3 7

91 9

Ubun t u Y a k ke t y C e n t OS W i n dow s 2 0 1 6 S e rv e r

running runn i n g shut o f f

vi r s h # s tart Windows 2 0 1 6 Server Doma i n Windows S e rv e r s t a r t e d vi r s h # shutdown CentOS Doma i n C e n t O S i s b e i n g s h u t down vi r s h # qui t

24.3 . СИСТЕМА

FREEBSD BHYVE

В верс и ю Free B S D 1 0 . 0 была включена относительно новая с истем а в иртуал иза­ ции — bhyve . Она может запус кать гостевые операцион ные с исте м ы B S D , Linux и даже Windows. Однако она работает с ограниченн ы м н абором а ппаратных средств и у нее от­ сутствуют некоторые основные функции , существующие в других реализациях. Учитывая бол ьшое количество платформ в иртуализации на рынке, которые уже п од­ держи вают систему Free BS D , не понятно, почему усилия bhyve н ачались, когда они уже появил ись. Если вы не разрабатываете собствен н ую платформу, требующую встроенной виртуал изаци и Free B S D , м ы рекомендуем в ыбрать другое решен и е , пока этот проект не созреет.

24.4. КОМПАНИЯ

VMWARE

Ком пания VМware я вляется крупнейшим и гроком в и ндустри и виртуал изации и пер­ вым поставщиком , которы й разрабаты вает технологии для в иртуали за ц и и требо ва­ тел ьной платформ ы х86 . Ком пания VMware является коммерческим предприятием . но некоторые из ее продуктов бесплатны . Все они заслуживают в н иман и я при выборе тех­ нологии виртуализаци и всего сайта. Основны м продуктом , представляющим и нтерес для администраторов U N IX и Lin u x , является ESXi 3 , который представляет собой простой гипервизор дл я архитектуры l пtel х86. Гипервизор ESXi является бесплатны м , но н екоторые полезные фун кции ограниче­ ны платны м и лицензиям и . В допол нение к гипервизору ESXi компания VMware п редлагает несколько мощны х , продвинутых продуктов , которые облегчают централ изованное развертывание и управ­ ление в иртуальны м и маш и н а м и . У них также есть самая зрелая технология динамиче­ ской м и граци и , которую м ы уже видели . Одн ако углубленное осве щение полного н а ­ бора продуктов VWware выходит за рамки этой главы .

24.5 .

ГипеРви зоР V1RTUAL8ox

Virtual Вox — это кросс- платформе н н ы й гипервизор второго типа. Он выполняет, ве­ роятно, достаточ но хорошую виртуализаци ю гостевых систем , используе м ы х , как п ра­ вило, частн ы м и л и цам и . Он популярен среди разработчи ков и конечных пол ьзовате1 Аббревиатура ESXi рас ш ифровы вается к а к » Elasic Sky Х, i ntegrated » . Даже н е п ытайтесь понять, что это знач ит.

Часть lV. Эксплvатация

920

л е й , поскольку я вляется бесплат н ы м , просты м в установке , простым в ис пол ьзова н и и и часто упрощает создание и управление тестовы м и среда м и . Его производител ьность и ап паратная поддержка я вляются слабым и . Гипервизор Virtual Box обыч но не подходит для виртуал и зации производствен н ых систе м .4 История гипервизора Vi rtual Box дл и н ная и запутанная . Он начинался как коммерче­ ский продукт компании l nnotek Gmb H , но был вы пущен как проект с открытым кодом , прежде чем компания l nnotek была приобрете на ком панией Sun M icrosystems в 2008 r. П осле того как ком пания Oracl e поглотила Sun в 20 1 0 r. , п родукт был пере и м е н ован в Oracl e УМ Vi rtual Box. Гипервизор Vi rtual Box существует и сегодня (доступен по л и це н ­ зии Open Source G P Lv2) и продолжает активно развиваться ком пани е й Oracle. Гипервизор Virtual Box работает в системах Li nux, Free B S D , Wi ndows, macOS и Solaris. Ком п а н ия O racle не публи кует и не поддерживает верс и ю для хоста Free B S D , н о е го можно установить из набора портов. Поддерживаемые гостевые операционные систе м ы включают Windows, Linux и Free B S D . П о умолча н и ю виртуальные маш и н ы контролируются с помощью графического ин­ терфейса Vi rtual Box. Если вы заинтересова н ы в запуске виртуальных маш и н в систе м е , которая н е допускает графический и нтерфейс, изучите гипервизор VBox H eadless , ин­ струмент командной строки дл я Vi rt ual Box. В ы м ожете с качать програм м у Virt ual Box и узнать больше о ней на сайте v i r t u a l box . o r g .

24.6. П РОГРАММА

PACKER

Packer (packer . io) , широко признанный проект с открытым исходн ы м кодом ком ­ пан ии HashiCorp, я вляется инструментом для создания образов виртуальной машины из файла спецификац и и . О н может создавать образы для различных платформ виртуал и ­ зации и облач ных платформ . Внедрение Packe r в рабочи й п роцесс позволяет вам не за­ ботиться о платформе виртуализаци и . Вы можете легко создать с вой н астрое н н ы й образ для л юбой платформ ы , которую вы испол ьзуете в определенный день. Чтобы создать образ, програм м а Packer запускает экземпляр и з исходного образа по вашему выбору. Затем он н астраи вает экзем пляр, запуская с це н ари и ил и вызывая другие указан н ы е вам и этапы . Н аконец, он сохраняет коп ию состоя ния виртуал ьной маш ины в качестве нового образа. Этот процесс особен н о полезен для поддержки » и нфраструктуры как кода » для управления серверами. В место тоrо чтобы вручную применять изменения к образам , вы изменяете шаблон , который описывает образ в абстрактных терм инах. Зате м вы записы­ ваете спецификацию в репозитори й , как традицион н ы й исходный код. Этот метод обе­ спечивает превосходную прозрачность, повторяемость и обратимость. Это также создает четкий контрол ьн ы й журнал . Конфи гурации Packer — это файл ы J S O N . Больши нство адми н истраторов соглас н ы с тем , что JSON представляет собой плохой выбор формата, поскольку он , как известно, придирч ив к кавыч кам и запятым и не допускает комментариев. Есл и повезет, компания HashiCorp скоро преобразует Packer в свой улучшен н ы й настраиваем ы й формат конфи­ гурации , но до тех пор вам придется редактировать файлы в формате JSON .

4 Веб-сайт Vi rtual Вox утверждает, что это п рофесс ионал ьное ре ш е н и е , которое л и це н зи руется дr1я испол ьзова н и я на предприятиях. На самом деле это может быть сп раведr1 и во в отноше н и и операционных систем Oracle, которые являются еди нстве н ными заранее созданными виртуальн ы ­ ми машинами.

Глава 24. Виртуализация

921

В шаблоне «сборщики» определя ют, к а к создать образ, а » поставщики » позвол я ют настроить и установить п рограм м ное обес печение для образа. Существуют сборщики, созда н н ы е комп а н и я м и AWS , G C P, D igita!Ocean, VМware, Virtual Вox и Vagrant и м но­ гими другим и . П оставщики могут быть сценар и ями оболочк и , реце птур н ы м и книга м и Chef, ролями AnsiЫe или другим и и нструментами управления конфигурацией. В приведе нном н иже шаблоне , cus tom_ami . j son, показано использова н ие сборщи­ ка ama z o n — e b s компании AWS и поставщика s he l l . «bui lders » : [ ( » t ype » : » ama z o n — e b s » , » ac c e s s k e y » : » AK I A I OS FODNN 7 EXAМPL E » » s e c r e t_ke y » : » wJ a l rXUtnFEM I / K 7 MDENG / b P x R f i C YEXAМPLEKE Y » , » r e g i on » : » u s -we s t — 2 » , » s o u r c e ami » : » am i — d 4 4 0 a б e 7 » , » i n s t a n c e_t yp e » : » t 2 . me d i um » , » s s h u s e rname » : » ubuntu » , » s s h_t ime out » : » Sm » , » s ubn e t_i d » : » subne t — e f 6 7 9 3 8 a » , » vp c_i d » : » vрс — 5 1 бЬ 8 9 3 4 » , » a s s o c i a t e_puЬ l i c_i p_a d d r e s s » : t ru e , » ami_v i r t u a l i z a t i on_t yp e » : » hvm » , » ami d e s c r i p t i on » : » UL SAH АМ I » , » ami_name » : » UL SAHS E » , » tags » : ( » Name » : » U L SAH S E Demo АМ I » } }] » p r ovi s i one r s » : ( » t ype » : » s h e l l » , » s ourc e » : » cu s tomi z e ami . s h » /

/

Как л юбому и нструменту командной строки нужны определенные параметры для за­ пуска экзе м пляра, сборщику a ma z on — e b s н ужны такие данн ы е , как м андаты API , тип экзем пляра, исходн ы й и нтерфейс AM I , н а котором основывается новый образ, и под­ сеть УРС, в которой должен располагаться экзе м пляр. Для выпол не н ия этап а поставки программа Packer испол ьзует службу S S H , поэтому мы должн ы убедиться, что экзе м пля­ ру назначен общедоступн ы й I Р-адрес. В этом примере сборщиком является сценарий оболочки под названием c u s t omi z e ami . s h . Программа Packer копирует сценарий в удаленную систем у с помощью команды scp и запускает его. В этом сценарии нет ничего особен ного; он может делать все, что вы обычно делаете. Например, он может добавлять новых пользователей , загружать и настраи­ вать программное обеспечение или выполнять шаги по укреплению системы безопасности. Чтобы создать интерфейс AM I , выпол ните команду packer bui ld: $ packer build cus tom_ami . j son

Ком анда packer bui ld отмечает каждый шаг процесса сборки на консол и . Сборщик ama z o n — e b s выполняет следующие этапы. 1 . Автом атически создает пару ключей и группу безопасности . 2.

Запус кает экзе м пляр и ждет, пока он станет доступн ы м в сети.

часть lV. Эксплуатация

922

3. Испол ьзует утил иты scp и s sh для выполнения запрошен н ых этапов и н ициал и заци и. 4.

Создает AM I , вызы вая инте рфейс ЕС2 Create lmage API.

5 . Очи щает память, прекращая работу экзе м пляра. Если все работает правил ьно , програм м а Packer выводит идентифи катор AM I , как тол ько он будет доступен для испол ьзования . Если во время сборки возн и кает пробле­ ма, програм ма Packer выводит сообще ние с ошибкой пурпурного цвета и выходит из си­ сте м ы после очистки памяти . П ри испол ьзовании арrумента -debug в команде packer build систе ма будет при­ останавл и ваться на каждом этапе, чтобы вы могл и устран ить пробл е м ы . В ы также мо­ жете использовать сборщик n u l l для исправления любых ош ибок, чтобы не запускать экзе м пляр каждый раз при поп ытке запустить сборку.

24.7. ПРОГРАММА VAGRANT Програм ма Vagrant также разработан а ком панией H ashiCorp. Она я вл яется оболоч­ кой для платформ виртуализаци и , таких как VMware , Vi rtual Box и Docker. Однако сама по себе она не является платформой виртуал изации. П роrрамма Vagrant упрощает поставку и настройку виртуал ьной среды . Ее задача быстро и легко создать перенос и м ы е , предварительно сконфигурированные среды раз­ работки , которые тесно связа н ы с производствен н ы м и среда м и . Эта фун кционал ьная возможность позволяет разработчи кам писать и тестировать код с м и н имальн ы м вмеша­ тельством со стороны системных администраторов или груп пы эксплуатаци и . Можно (но не обязательно) испол ьзовать програм м у Vagrant в сочетании с програм ­ м о й Packer. Например, вы можете стандартизировать базовый образ, которы й в ы ис­ пользуете для своих производстве н н ых платформ , с помощью програм мы Packer, а зате м распростран ить сборку Vagrant этого образа среди разработч и ков. Разработч ики могут развернуть экзе м пляр образа на своем ноутбуке или облачном провайдере по своему вы­ бору с любы м и необходи м ы м и настройка м и . Этот метод уравновеш и вает потребность в централизованном управлении производстве н н ы м и образам и с потребностям и разра­ ботчиков в доступе к аналогичной среде , которую они моrут контрол ировать напрямую.

24.8. ЛИТЕРАТУРА •

Веб-сайт v i r t u a l i z a t i o n . i n f o я вляется отлич н ы м источн и ком те кущих ново­ стей, тенденций и сплетен в области виртуал изации и облачных вычислен и й .

Нлsн 1 м ото , М пс н F. 1 .1″ Vagrant: Up a n d Running: Create a n d Manage Virtua /ized Devefopment Environments. Sebastopol , СА: O’ Reilly Media, 20 1 3 .

KusNпs кv, DлN . Virtuafization: А Manager’s Guide: Вig Picture о/ the Who, What, and Where о/ Virtuafization. Sebastopol , СА: O ‘ Reilly M edia, 20 1 1 .

МлскЕУ, Т1 м , AN D J . К. В Е N Ш 1ст. XenServer Administration Handbook: Practical Recipes for Success/uf Depfoyments. Sebastopol , СА: O ‘ Reily Media, 20 1 6.

SENTH I L , N лп1л N . VirtuafBox at Warp Speed: Virtuafization with Virtua!Box. Seattle , WA: Amazon Digital Services, 20 1 5 .

TROY, RYA N , AND Mл’l»П IEW H E L M K E . VMware Cookbook: А Real- Worfd Guide to E/fective VMware Use, 2nd Edition . Sebastopol , СА: O’ Reilly Media, 20 1 2 .

Глава

25

контейнеры

Н е м ногие технологии вызвал и стол ько вол н е н и й и шумихи в последние годы , как скромный контейнер, взрыв популярности которого совпал с выпуском проекта с откры­ тым исходным кодом Docker в 20 1 3 r. Контейнеры предстааляют особы й интерес для си­ сте м н ых адми нистраторов, поскольку они стандартизируют упаковку програм м ного обе ­ спечения, реализуя цель, которая долrое время считалась практически недостижимой. Для того чтобы проилл юстрировать полезность контейнеров, рассмотр и м типич ное неб- приложение, разработан ное на л юбом современ ном языке ил и с помощью каркаса. Для установки и запуска приложения н еобходимы следующие и нгредиенты : •

код для приложения и его правильная конфигурация ;

десятки библиотек и других зависимостей , совместимых с конкретны м и версиями ;

и нтерпретатор ( например, Python или Ruby) или среда выполнения (J RE) для вы­ полнения кода, также связа н н ые с кон кретны м и версия м и ; локал изац и и , такие как учетные записи пол ьзователей, настройки среды и служ­ бы, предостааляемые операционной системой.

В ти пичной орган изаци и испол ьзуются десятки и даже сотни таких приложе н и й . П оддержание еди нообразия в каждой из этих областей п р и разверты ван и и нескольких приложе н и й я вля ется постоя н ной проблемой даже при испол ьзован и и и н струментов, обсуждаем ы х в главах 2 3 и 26. Н есовместим ы е зависи мост и , требуе м ы е отдельн ы м и приложе н и я м и , при водят к недогрузке систе м , поскол ьку он и не могут ис пол ьзовать­ ся совместно. Кроме того, в орган изациях, где разработчики программного обеспече ния и системные адм ин истраторы фун кционально разделены, н еобходи ма тщательная коор-

Часть lV. Эксплvатация

924

динаци я , потому что не всегда легко определить, кто н есет ответственность за кон крет­ ные части операционной среды . Образ конте йнера упрощает дело, упаковывая приложение и е го вспомогател ьн ые средства в стандартн ы й перенос и м ы й файл . Л юбой хост с совместимой средой выпол­ нения может создать контейнер, используя его образ в качестве шаблона. Десятки или сотни контейнеров могут работать одновременно без конфл иктов. Как правило, размер образов составляет не более нескол ьких соте н мегабайтов, поэтому их можно копиро­ вать между с истемам и . Эта легкость переноса приложе н и й , возможно, является ос нов­ ной причиной популярности контейнеров. В дан ной главе основное внимание уделяется платформе Dockeг. И м я Dockeг опи­ с ы вает меха н изм, с ы грав ш и й це нтрал ьную рол ь в ш и роком призн а н и и конте йнеров, а платформа Dockeг это то, с чем вы, скорее всего, столкнетесь как систе м н ы й адм и ­ н истратор. Компан ия Dockeг, Inc. предлагает несколько продуктов, связанных с контей­ нерам и , но м ы ограничиваем наше обсуждение основ н ы м контейн ерн ы м механ измом и менеджером кл астеров Swann. Существует нескол ько жизнеспособ н ых ал ьтернативных контейнерных механизмов. Наиболее пол н ы м я вляется механ изм гkt дл я систе м ы СогеОS. О н имеет более ясную модель процесса, чем платформа Dockeг, и более безопасную конфигурацию по умол ­ чан ию. Механизм гkt хорошо сочетается с с истемой оркестровки Kubernetes. Утил ита sys temd- nspawn из проекта sys temd я вляется вариантом облегч е н н ы х конте й н еров. Она и меет меньше возможностей , чем Dockeг или гkt , но в некоторых случаях это может быть полезны м . Утил ита гkt взаимодействует с systemd-nspawn при настрой ке п рост­ ранств имен контейнеров. —

2 5 . 1 . ОСНОВНЫЕ КОН ЦЕПЦИИ Б ыструю эволюцию контейнеров до высокой степени изя щества можно объясн ить скорее правильны м согласован ием разных механ измов, чем появлен ием какой-либо од­ ной технологии. Контейнеры — это сочетание м ногочисленных существующих фун кций ядра, приемов работы с файловой системой и сетевых трюков. Контейнерный механизм это программное обеспечение для управления, которое объединяет все это в одно целое. П о сути, конте йнер представляет собой изол ирован ную группу процессов, которые о граниче н ы частной корн е вой файловой системой и пространством и м е н п роцессов. Содержащиеся процессы совместно испол ьзуют ядро и другие службы хост-систе м ы , но по умолчан и ю о н и не могут получить доступ к файлам или систе м н ы м ресурсам за пределами своего контейнера. П р иложения , которые запускаются внутри конте й нера, н е знают о своем контейнерном состоян и и и не требуют модификации. П осле того как вы прочитаете следующие разделы , вам должно стать ясно, что в кон ­ тейнерах нет ничего загадочн ого. Фактич ески о н и ос нованы на н е которых средствах U N I X и Linux, которые существуют уже много лет. Описание различий между контейне­ рам и и виртуальными машинами приведено в главе 24.

Поддержка ядра В контейнерном механ изме используется несколько средств ядра, которые н еобходи­ м ы для и золяции п роцессов. • Пространства имен изол и руют контей нерные процесс ы с точки зре н и я нескол ь­ ких фун кций операционной систе м ы , вкл ючая монтирован ие файловой систе м ы ,

Глава 25. Контейнеры

925

управление процессами и сетевое взаимодействие. Например, простран ство имен команды mount отображает процесс ы с помощью индивидуал ьного представле­ ния иерархии файловой систе м ы . 1 Конте й неры могут работать на разных уровнях и нте граци и с операцион ной системой хоста в зависимости от того, как эти про­ странства имен был и настроен ы . •

Контрольные группы огран ичивают испол ьзован и е систе м н ых ресурсов и опреде­ ляют приоритетность одн их процессов над друтим и . Контрольные группы препят­ ствуют контейнерам, выходя щим из-под контроля, использовать всю память и все доступ ное врем я централ ьного процессора.

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

Разработка этих фун кций частично происходила в рамках проекта Liпux Containers, LXC , котор ы й начался в компан и и Googl e в 2006 г. П роект LXC б ыл основой Borg , внутрен н е й платформы виртуализа ц и и Google . С исте ма виртуал изац и и LXC предо­ ставляет исход н ы е фун кции и и н струм е нты , н еобход и м ы е для создан и я и запуска Linuх — конте й неров, но сделать это с помощью более чем 30 утил ит командной строки и конфигурационных файлов довольно сложно. П ервые несколько выпусков платформы Docker был и по сути удоб н ы м и для пол ьзователя упаковка м и , которые упрощал и ис­ пол ьзование систе м ы LXC. Те перь платформа Docker базируется на улуч ш е н ной и стандартизован н ой сре­ де дл я запус ка контейнеров containerd. Она также полагается на пространства имен Li nux, контрол ьные груп п ы и возможности и зол ировать конте й н е р ы . П одробн е е о б этом можете прочесть на сайте c on t a i n e r d . i o .

Образы Образ контей нера похож на шаблон для контей н ера. Образы ис пользуют точ ку мон ­ тирова н и я объеди н е н ной файловой систе м ы ( union filesystem) , обеспеч и вающую вы­ сокую производительность и переносимость. Это позволяет испол ьзовать перекрытия нескол ьких файловых систе м для создания единой согласованной иерархии . 2 Образы конте йнеров представля ют собой объединенные файловые систе м ы , которые организо­ ван ы по образу и подоби ю корневой файловой системы типич ного дистрибутива Linux. Структура каталога и рас положе н и е би нарных файлов, библ иоте к и поддерживаю­ щих файлов соответствуют стандартным спецификаци я м иерархи и файловой с исте м ы Linux. Для использован ия в качестве основы для образов контей неров был и разработа­ ны специал изированные дистрибутивы Linux. Для создания контейнера на платформа Docker используется объединенная файловая система U nion FS, предназначенная только для чте н ия и записан ная в образе , к которой добавляется уровен ь чтения-зап иси , обновляе м ы й в контейнере. Когда контейнерные процессы изменяют файловую с истему, их изменения прозрачно сохраняются на уровне 1 Это аналоги чно систем ному вызову chroot, котор ый необратимо устанавл ивает види м ый про­ цессу корневой каталог и тем сам ы м откл ючает доступ к файлам и каталогам хоста , расположен ­ н ы м выше уровня chroot . 2 С м . статью «А brief l1 i story of u n ion mounts» на сайте LWN . n e t , а также , напри мер, l w n . n e t /

Art i c l e s / 3 9 6 0 2 О .

Часть lV. Эксплуатация

926

чтения-записи . База остается неизмен ной. Это назы вается стратегией копирования при записи. Во м ногих ко нте й н ерах могут испол ьзоваться одн и и те же неизм е н н ые базовые уров н и , что повы шает эффе кти вность хранения и сокращает время запуска. Эта схема изображена на рис. 2 5 . 1 .

Контейнер из базового образа

Контейнер из базового образа

Контейнер из базового образа

Уровень чтения-записи файловой системы

Уровень чтения-записи файловой системы

Уровень чтения-записи файловой системы

Слой 2 Слой 1

Только для чтения

Слой 0 Базовый образ Рис. 25. 1. Платформа Docker и обьединенная файловая система

Сеть П о умолч а н и ю дЛЯ подкл юче н и я конте й н еров к сети испол ьзуется сете вое п ро­ странство имен и мост внутри хоста. В этой конфигурации контейнеры имеют частные I Р-адреса, н едоступные за пределами хоста . П р и этом хост и грает рол ь упрощен ного I Р-маршрутизатора и проксирует трафик между внеш н и м миром и контейнерам и . Эта архитектура позволяет адм и н истраторам контрол ировать. какие порты контей нера от­ крыты для внешнего м ира. Также можно отказаться от схе м ы адресации частного контейнера и представить все конте йнеры непосредственно в сети. Это называется сетевым режимом хоста и означа­ ет, что конте йнер и меет неограниче н н ы й доступ к сетевому сте ку хоста. В некоторых ситуациях это может быть полезн ы м , но также представляет угрозу безопас ности , по­ скол ьку конте й нер не пол ностью изол ирован . Для получения допол н ительной и нформации обратитесь к разделу » Dockeг» .

2 5 . 2 . ДОКЕР: МЕХАНИЗМ С ОТКРЫТЫ М ИСХОДНЫ М КОДОМ Основной продукт ком пан и и Docke r, I пс . — кл иент-серверное приложе ние, кото­ рое создает контейнеры и управляет и м и . Механ изм контей нера Docker, нап исан н ы й на языке G o , явл яется в высокой степени модульным. П одкл ючае м ы м хра н ил и щем, се­ тевы м и и нтерфейса м и и другим и функция м и управляют отдел ьные проекты . С ком пан ией Docker, I пс. связа н ы определ е н н ы е пробл е м ы . Ее и нструме нты , как правило, разрабатываются настол ько быстро, что новые версии иногда несовместимы с существующ и м и развертыва н ия м и . Не которые орган изации опасаются , что исполь­ зование платформ ы Docke r приведет к при вязке к одному производител ю. И , как и в случае с л юбой новой технологией, контейнеры порождают сложность и требуют под­ робного изучения.

Глава 2 5 . Контейнеры

927

Для того чтобы противостоять свои м недоброжелател я м , ком пания Docker, l nc. стала одн им из основателей консорциума Open Container l 11 i t i at ive , цел ью которого я вляется руководство развитием конте й н ер н ы х технолог и й в здоро1юм кон куре нтном направ­ лен и и , которое способствует стандартам и сотрудничеству. В ы можете об этом узнать больше на сайте o p e n c on t a i n e r s . o r g . Для того чтоб ы облегч ить развитие сообщества среды выпол н е н ия Docker, в 20 1 7 r. ком пан ия Dосkег ос новала проект МоЬу и внедрила в него основной репозитори й Docker Git ( подробнее с м . на са йте тobyp r o j e c t . o r g ) . Наше обсужден ие платформы Docker ос новано на верс и и 1 . 1 3 . 1 . Она поддерживает исключ ител ьно быстр ые те мпы развития , а текущие фун кции постоя н но изме н я ются . М ы сосредоточ и мся н а ос новах. н о обя зател ьно допол н ите наше оп исан ие справоч­ ным материалом с сайта d o c s . doc ke r . с от. Вы также можете поработать с песоч н и цей на сайте p l a y — w i t h -т o b y . с от и лабораторной средой Doc ker на сайте l a b s . p l a y ­ w i t h — d o c k e r . c oт.

Базовая архитектура П р иложение docker — это запускаемая команда, которая обрабаты вает все задач и управления для системы Docker. П роцесс dockerd — это резидентн ы й процесс демона, которы й реал изует операции с контей нера м и и образа м и . Кома нда docker может за­ пускаться в той же системе, что и dockerd, и с вязы оаться с н и м через сокеты домена UN IX ил и взаимодействовать с dockerd с удален ного хоста с помощ ью протокола ТС Р. Эта архитектура изображена на рис. 2 5 . 2 .

Операционная система хоста Экземпляры Ubuntu FreeBSD

Контейнеры

Локальные образы

Управляет

Кеширует

dockerd Загружает и выгружает образы

Управляет с помощью сети или локального сокета домена

docker

Ubuntu

Debian

FreeBSD

Реестр образов Docker Рис. 25.2. Архитектура платформы /Jocker

Демон dockerd владеет все й и нфраструктурой , необходимой мя запуска конте йне­ ров. Он создает виртуал ьную сеть и поддержи вает каталог дан н ых, в котором хранятся контейнеры и образы (по умолч а н и ю в каталоге /var / l iЬ/docker). Он отве чает так­ же за создание контейнеров, вызы вая соответствующие систе м н ые вызовы , настраи вая

Часть lV. Эксплvатация

928

объедин е н н ы е файловые с истем ы и исполняющие процессы . Короче говор я , это про­ гра м мное обеспечение для управления конте йнерами . Администраторы взаимодействуют с демоном dockerd через командную строку, за­ пус кая подкоманды команды docker. Например, вы можете создать контейнер с помо­ щью команды docker run или просмотреть и нформацию о сервере с помощью коман­ ды docker info. Н екоторые часто используемые подкоманды приведены в табл. 2 5 . 1 . Таблица 25 . 1 . Часто используемые подкоманды команды docker Подкоманда

Предназнач ен ие

docker info docker ps docker version docker rm

Отображает сводную информацию о демоне Отображает запущенные контейнеры Отображает обширную информацию о версии сервера и клиента Удаляет контейнер Удаляет образ Отображает локальные образы Отображает конфигурацию контейнера (данные в формате JSON ) Отображает стандартный вывод из контейнера Выполняет команду в существующем контейнере Запускает новый контейнер Загружает образы из удаленного реестра или загружает образы в удаленный реестр Запускает или останавливает существующий контейнер Отображает состояние контейнерного процесса

docker rmi docker images

docker inspect docker logs docker ехес docker run docker pull/push docker start/ stop docker top

Образ является шаблоном для контейнера. В него включены файл ы , от которых зависят процессы , выполняемые в экзе м пляре контейнера, такие как библиотеки , двоичные фай­ лы операционной системы и приложения. В качестве удобн ых базовых образов можно ис­ пользовать дистрибугивы Linux, поскольку они определяют пол ноцен ную рабочую среду. Однако образ не обязательно должен основываться на дистрибугиве Linux. Исходным мо­ жет быть пустой образ, предназначенный для создания других, более практич ных образов. Конте йнер испол ьзует шаблон образа в качестве основы для выпол н е н и я . Когда демон dockerd запус кает контейнер , он создает уровен ь файловой систе м ы с возмож­ ностью записи, которы й отделе н от исходного образа. Контейнер может ч итать л юбые файлы и другие м етадан н ы е , хранящиеся в образе , но л юбые зап иси огра н и ч и ваются собствен н ы м уровнем чтения- записи контейнера. Реестр образов представляет собой централизован ный набор образов. Демон dockerd связывается с реестра м и п р и в ы п ол н е н и и команд docker pu l l и docker pu s h . Стандартн ы м реестро м , используе м ы м п о умолчанию, я вляется Docker Hub, в котором хранятся образы для м ногих популярных приложен и й . Бол ьш инство стандартных дист­ рибуrивов Linux также опубли кова н ы в в иде образов Docker. В ы м ожете запустить собствен н ы й реестр или добавить с вои образы в частные ре­ естр ы , размещен н ые на Docker H ub. Л юбая система, на которой запущена платформ а Docker, м ожет и звлекать образы из реестра, если сервер реестра доступен через сеть.

И нсталл яция Платформа Docker работает в операцион н ы х с истемах Linux, M acO S , Wi ndows и Free B S D , но Linux является флагманской системой. Поддержка Free B S D считается экспериментальной. Посетите сайт d o c ke r . с от , чтобы в ыбрать способ и н сталл я ц и и , который наил уч шим образом соответствует вашей среде .

Глава 25. Контейнеры

929

Пользователи , принадлежащие rруппе d o c ke r , могут управлять демоном Docker через свой сокет, что фактически дает этим пользователям права пользователя r oo t . Это зна­ чительный риск дЛ Я безопасности, поэтому м ы предпаrаем использовать проrрамму sudo дЛЯ контроля доступа к командам docker, а не добавлять пользователей в rруппу doc k e r . В приведенных н иже примерах мы запускаем команду docker в качестве пользователя roo t . В процессе и нсталл яци и де мон Docker может и н е запуститься сразу. Если он н е стартовал , запустите ero с помощью обыч ной системы ini t. Например, в операционной системе CentOS выполн ите команду sudo systemctl s tart docker.

Настрой ка кл иента Е сл и вы подкл ючаетесь к локал ьному демону dockerd и принадпежите к гру п ­ пе d o c ke r ил и имеете права sudo, т о настрой ка клиента н е требуется . Кл иент docker по умолчан и ю подключается к демону dockerd через локал ьн ы й сокет. Вы можете из­ менить стандартное поведение кл иента через переменные среды. Для того чтобы подкл юч иться к удален ному де мону dockerd, установите перемен­ ную окружения DOCKE R H O S T . Обычный Н ТГ Р-порт дЛ Я демона 2375, а дЛЯ версии с поддержкой TLS 2376. Н апример: _

$ export DOCКER_HOST=tcp : / / 1 0 . 0 . 0 . 1 0 : 2 3 7 6

Всеrда испол ьзуйте TLS дЛЯ связи с удален н ы м и демонами. Есл и вы испол ьзуете от­ крыты й протокол Н ТГ Р, с те м же ус пехом вы можете с вободно раздавать права пользо­ вателя r o o t все м , кто находится в вашей сети . Дополн ител ьн ые сведе н ия о конфигура­ ции Docker TLS можно найти в разделе 25.3. М ы также предпаrаем включить функцию Docker Content Trust: $ export DOCКER_CONТENT_TRUST=l

Эта фун кция проверяет целостность и автора образов Docker. Включение этой фун к­ ции н е позволяет клиентам извлекать образы , которым они не доверяют. Если вы запускаете команду docker с помощью проrраммы sudo , то вы можете за­ претить sudo очищать переменн ые среды с помощью флага -Е . Вы также можете ука­ зать список сохраняемых переменных среды , установив значение переменной env keep в файле /etc/ sudoers . Например, _

De f au l t s e n v_ k e e p

+

=

» DOCKE R_C ON T ENT_TRU S T «

М етодики работы с контей нерами Для того чтобы шаблона. В образе пуска програ м м . В хранили ща Docker

создать контейнер, необходим образ дЛЯ испол ьзования в качестве есть все бинарные фа йл ы файловой с исте м ы , необходим ы е дЛ Я за­ новой и н сталляции Docker образов нет. Ч тобы заrрузить образы из Hub, используйте команду docker pul l . 3

# docker pull deЬian U s i n g de f a u l t t a g : l a t e s t l a t e s t : P u l l i n g f r om l i b r a r y / de Ы a n f 5 0 f 9 5 2 4 5 1 3 f : Down l oad comp l e t e d 8 b d 0 6 5 7 b 2 5 f : Down l oad comp l e t e D i ge s t : s h a 2 5 6 : e 7 d 3 8 b 3 5 1 7 5 4 8 a l c 7 1 e 4 l b f f e 9 c 8 ae б d б . . . S t a t u s : Down l o a d e d newe r ima g e f o r d e Ы an : l a t e s t

JCo списком доступ ных образов можно ознакомиться на стран и це hub . d o c ke r . с о т .

Часть lV. Эксплуатация

930

Ш естнадцатерич ные строки относятся к уровням объединен ной файловой систе м ы . Если оди н и тот ж е урове н ь испол ьзуется более чем в одном образе , платформе Docker нужна только одна его коп ия. М ы не запраш ивали определенны й те г или версию образа Deblan , поэтому Docker по умолчани ю загрузил тег новейшего образа . С п исок локал ь н ы х загруже н н ы х образов можно вы вести с помощью команды docker image. # docker imaqes RE POS I T ORY TAG latest ulJUn t u ubuntu wily ubuntu t ru s t y ubuntu 15 . 04 7 centos latest ceпtos j essie deЬian latest deЬi a n

I МAGE I D 0 7 c 8 6 1 67 cdc4 b 5 e 0 9 e 0 cd 0 5 2 97434d46f197 dlb55 fd07 600 d0e7 f8 1ca65c d0e7 f 8 1 ca 6 5 c f50 f952 4 5 1 3 f f50f952 4 5 1 3 f

C REAT E D 2 we e k s a g o 5 days ago 5 days ago 8 we e k s a g o 2 wee k s a g o 2 we e k s a g o 3 we e k s a g o 3 we e k s a g o

S I ZE 187 . 9 136 . 1 187 . 9 131 . 3 196 . 6 196. 6 125 . 1 125 . 1

мв мв мв мв мв мв мв мв

Н а этом ком пьютере имеются образы для нескол ьких дистрибути вов Li nux, вкл ючая тол ько что загруже н н ы й образ Deblan . Одному и тому же образу можно назначить нес­ кол ько тегов. Обратите в н и мание на то , что de Ь i a n : j e s s i e и d e Ь i a n : l a t e s t имеют оди н и тот же идентификатор образа; это два разных имени для одного и того же образа . И мея образ, оче н ь ле гко запустить базовый контейнер: # docker run deЬian /Ьin/echo » Hello World» Hell o World

Ч то сейчас произошло ‘! Система Docker создала контейнер из базового образа Deblan и выпол н ила команду /Ьin/ echo » He l l o Wor l d » внутри н е го.4 Контейнер переста­ ет работать, коrда команда завершает работу: в дан ном случае сразу после завершения команды echo. Есл и образ Deblan ранее не существовал локально, то демон поп ытает­ ся автоматически загрузить е го перед запуском команды . М ы н е указали тег, поэтому по умолчани ю б ыл использован новей ши й образ. Для запуска и нтеракти вной оболоч ки команде docker run нужно передать флаги — i и t Следующая команда запускает оболочку bash внутри контейнера и подключает к ней кан ал ы ввода- вы вода вне ш н е й оболоч к и . М ы также назначаем конте й неру и м я хоста, что полезно для е го идентификаци и в журналах. ( В проти вном случае м ы увиди м в сообщен иях журнала случай н ый идентификатор контей нера). —

.

b e п @ h o s t $ sudo docker run — -hos tname deЬian -it deЬian /Ьin/bash r o o t @ de Ы a n : / # ls run s rv tmp var proc lib64 mn t Ыn dev horne root sЫn sys usr opt medi a boot e t c lib r o o t @ de Ы a n : / # ps aux ТТУ S TAT Т I МЕ RSS S TART VSZ %МЕМ PID USER % C PU 1 9 : 02 0 : 00 Ss 0 . 4 20236 1884 ? 1 0.5 root 0 . 2 1 7 4 92 1 1 4 4 ? R+ 1 9 : 02 0 : 00 О.О 7 root r o o t @ de Ы a n : / # uname -r 3 . 1 0 . 0 — 3 2 7 . 1 0 . 1 . e l 7 . x 8 6 64 r o o t @ de Ь i a n : / # e x i t exit be n @ h o s t $ uname — r З . 1 0 . 0 -327 . 1 0 . 1 . е17 . х8 6 64

СОММАN D /Ьin/bash ps aux

4Это команда echo и з прое кта G N U . Н е пуrайте е е с командой echo , встрое нной в больш и нство оболочек U N IX, хотя обе команды делают одно и то же .

Глава 2 5. Контейнеры

931

В с е это уди вител ьно nохоже на орга н и зацию достуnа к в иртуальной маш и н е . Существует nол ноцен ная корневая файловая система, н о дерево nроцессов выглядит nочти nусты м . Команда /Ьin/bash и м еет P I D равный , nотому что эту команду nлат­ форма Doc k er заnустила в контей нере nервой . Резул ьтат команды unaшe -r одинаков как внутри, так и снаружи контейнера. Это условие вы nолн яется всегда; мы указываем на это как наnом инание о том , что ядро я в­ ляется общ и м . П роцессы в контей нерах не могут видеть другие nроцесс ы , заnущен н ые в с исте м е , из-за изол ированного nространства P I D. Те м не менее nроцессы на хосте могут видеть контей нерные nроцессы . Иденти ф и катор P I D nроцесса, видим ый из контей нера, отли­ чается от P I D, который виден из хоста. Для реальной работы необходимы долговеч н ые контейнеры, которые работают в фо­ новом режиме и nринимают nодключения no сети. Следующая команда заnускает в фоно­ вом режиме ( -d) контейнер с именем ng i n x , который соЗдается из официального образа NG I NX. М ы nрокладываем туннель с nорта 80 на хосте в тот же nорт в контейнере: # docker run -р 8 0 : 8 0 — -hostname nginx — -name nginx -d nginx UnaЫe to f i n d image ‘ ng i nx : l a t e s t ‘ l o ca l l y l a t e s t : Pul l i n g f r om l i b r a r y /n g i n x fdd 5 d7 8 2 7 f 3 3 : Al r e ady e x i s t s a 3 e d 9 5 c a e b 0 2 : Pul l c omp l e t e e 0 4 4 8 8 adab3 9 : Pul l c omp l e t e 2 a f 7 6 4 8 6 f 8 b 8 : Pul l c omp l e t e D i ge s t : s h a 2 5 6 : a 2 3 4 ab 6 4 f 6 8 9 3b 9 a l 3 8 l l f 2 c 8 l b 4 6 c f ac 8 8 5 cЫ 4 1 dc f 4 e 2 7 5 e d 3 са 1 8 4 92аЬ4 е 4 S t a t u s : Down l o a d e d newe r image f o r n g i nx : l a t e s t O cc 3 6b 0 e б l b 5 a 8 2 1 1 4 3 2 ac f l 9 8 c 3 9 f 7 Ы d f 8 6 4 a 8 1 3 2 a 2 e 6 9 6d f 5 5 e d 9 2 7 d 4 2 c l d

У нас не было локал ьного образа n g i n x , nоэтом у nлатформе Doc k e r n р и шлос ь за­ грузить е го из реестра . Как только образ был загружен , nлатформа Doc k e r заnустила контейнер и вы вела его иденти ф и катор — ун икальную ш естнадцатеричную строку, со­ стоящую ИЗ 65 С И М ВОЛОВ. Команда docker ps отображает краткий отчет о заnущенных контейнерах: # docker ps

IМAGE nginx

C OMМAND » ng i n x — g ‘ da emon o f f «

STAT U S Up 2 minut e s

PORT S 0 . 0 . 0 . 0 : 8 0 — > 8 0 / t cp

М ы не указал и демону docker , что именно нужно заnускать в конте й нере , nоэто­ му он no умолчани ю испол ьзовал команду, которая была указана при создании образа. Вывод показывает, что этой командой я вляется команда nginx -g ‘ daemon off ‘ ко­ торая запускает nginx как процесс передне го плана, а не как фоновый демон . В кон ­ те й нере нет демона ini t для управления процессам и , и есл и запустить сервер nginx как демон, контей нер будет запущен , но сразу же заверше н , когда процесс nginx будет разветвлен и перейдет в фоновый режим. Бол ьш инство демонов сервера поддержи вают специал ьн ый флаг командной строки , которы й заставляет их запускаться на переднем nлане. Если ваше программное обесnе­ чение не может работать на nередн ем nлане или если вам нужно заnустить нескол ько nроцессов в контейнере, вы можете назнач ить систему уnравления процессам и , такую как supervisord, в качестве уnрощенной команды ini t для конте й нера. Есл и сервер N G I N X работает в контейнере, а nорт 80 хоста был отображен на nорт 80 контейн ера, то мы може м выnол н ить Н ТТР-заnрос к контей неру с nомощью npo,

Часть lV. Эксплvатация

932

граммы curl . По умолчан ию сервер N G I NX возвратит стандартную целе вую страницу в формате НТМ L. ho s t $ curl localhost < ! DOC T Y P E html> < h tml >

< t i t l e >W e l c ome t o n g i n x ! < / t i t l e >

М ы м оже м испол ьзовать ком а нду docker l o g s для прос м отра канала S TDOUT конте й н ера, в которы й в нашем случае вы водится журнал доступа к серверу N G I N X. Еди нствен н ы м трафиком является наш запрос к программе curl: # docker logs nginx 1 7 2 . 1 7 . 0 . 1 — — [ 2 4 /Feb / 2 0 1 7 : 1 9 : 1 2 : 2 4 + 0 0 0 0 ] » — » » cur l / 7 . 2 9 . 0 » » — «

» GET / НТТР / 1 . 1 » 2 0 0 6 1 2

М ы также можем и спол ьзовать команду docker logs — f , чтобы получить поток вы вода конте йнера в реал ьном вре м е н и , точ но так же , как команда tail -f позволяет увидеть вы вод из постоя нно увел ичивающегося файла журнала. Кома нда d o c k e r е х е с создает н о в ы й процесс в существующе м конте й н е р е . Например, чтобы устранять неполадки, м ы могл и б ы запустить интерактивную оболоч ­ к у в контейнере: # docker ехес — ti nqinx bash r o o t @ ng i n x : / # apt-get update & & apt-get -у install procps r o o t @ ng i n x : / # ps ах PID ТТУ S TAT T I ME COMМAN D 1 ? Ss 0 : 00 n g i n x : ma s t e r p r o c e s s n g i n x — g daemon o f f ; 7 ? S 0 : 00 n g i nx : wo r k e r p r o c e s s 8 ? Ss 0 : 00 bash 21 ? R+ 0 : 00 p s ах

Образы конте й неров настолько малы, насколько это возможно, и часто в н их отсутству­ ют общие утилиты управления. В приведенной выше последовательности команд мы сна­ чала обновил и общий индексный файл пакетной системы, а затем инсталл и ровали из нее программу ps, которая является частью пакета procps. В списке процессов показан главн ый де мон nginx, рабоч ий демон nginx и оболочка Ьавh. Когда мы выходим из оболоч к и , создан ной с помощью команды docker ехе с , контейнер продолжает работать. Есл и процесс с идентифи катором PI D 1 завершит свою работу, когда оболочка еще активна, работа конте йнера будет прекраще на, и наша обо­ лочка также завершит работу. М ы можем остановить и запустить контейнер. # docker s top nginx nginx # docker p s I МAGE СОММАN D STAT U S # docker start nginx # docker ps I МAGE СОММАN D STAT U S n g i n x » ng i n x — g ‘ da emon o f f «

PORT S

PORT S Up 2 minu t e s 0 . 0 . 0 . 0 : 8 0 — > 8 0 / t cp

Команда docker в tart запускает контей нер с тем и же аргумента м и , которые был и переданы при создании контейнера с помощью команды docker run. Когда конте й неры прекращают работу, они остаются в с истеме в состоян и и покоя . Вы можете увидеть сп исок всех контей неров , в том ч исле остановл е н н ых, с помощью

Глава 25. Контейнеры

933

команды docker p s — а . Хранение ненужны х старых контей неров н е представляет осо­ бой опасност и , но считается плох им стил ем и может при вести к конфл и ктам при по­ вторном испол ьзовани и имен контейнеров. Закончив работу с конте йнером , мы можем остановить и удалить е го: # docker s top nginx && docker

rm

nginx

Команда docker run — — rm запускает контейнер и автоматически удаля ет е го при выходе , но это работает только для контейнеров, в котор ых не запуще н ы де мон ы с по­ мощью флага -d.

Тома Уровни файловой системы для большинства конте й неров состоят из статического кода приложения , библ иотек и других с истемных или вспомогател ьных файлов. Уровень фай­ ловой системы чте н ия -записи позволяет контейнерам производить локальные модифика­ ции. Однако большая зависимость от объеди ненной файлово й систем ы не является луч ­ ш и м решением дл я приложений с интенсивным использованием дан н ых, таких как базы данных. Для таких приложен ий в платформе Doc k er используется понятие тома. Том (volume) представляет собой независимый, доступн ый для записи каталог в кон ­ тейнере , которы й поддерживается отдельно от объединен ной файлово й с исте м ы . Если контей нер удал е н , то дан ные в томе сохраняются и могут быть досту п н ы из хоста. Том а также могут быть рас пределены между нескол ькими контейнерам и . М ы добавляем том в контейнер с помощью аргумента — v команды docker: # docker

run

-v /data

rm

— -hostname wеЬ — -name wеЬ -d nginx

Если каталог /data уже существует в контейнере, все найден н ые там файлы коп иру­ ются в том . Найти том на хосте можно с помощью команды docker inspect. # docker inspect — f ‘ { { j son . Mounts } } ‘ wеЬ «Mount s » :

[

» Name » : » 8 f 0 2 6 e bb 9 c 0 cd a 2 7 4 4 l fЬ7 fd2 7 5 с 8 е 7 6 7 6 8 5 f 2 6 0 . . . f 5 f d l 9 3 9 8 2 3 5 5 8 » , » S o u r c e » : » / va r / l iЬ / do c ke r / v o l ume s / 8 f 0 2 6ebb 9 c O cda . . . 9 3 8 2 3 5 5 8 /_d a t a » , » De s t i n a t i on » : » / d a t a » , » D r i ve r » : » l oca l » , » Mode » : » » , » RW » : t ru e , » P ropaga t i on » :

Подкоманда inspect возвращает подробную и нформацию; м ы применили фильтр , чтобы на экран выводились только смонтированные тома. Е сли контейнер пре кратил работу или е го нужно удалить, мы може м найти том данных в исходном каталоге на хо­ сте . И мя бол ьше похоже на иде нтифи катор, но оно пригодится , если нам нужно будет идентифицировать том позже. Для в ы вода с п и с ка доступных томов в систе м е на самом высоком уровне сл едует выпол н ить команду docker volume l s . Платформа Doc k er также поддерживает механ изм монтирования привязок, который монтирует тома на хосте и в контей нерах одновремен но. Например, м ы можем смонти­ ровать привязку /mnt/data хоста на каталог /data в контейнере с помощью следующе й команды: # docker run -v /mnt/data : /data — — rm — -name wеЬ -d nginx

Часть lV. Эксплvатация

934

Когда контейнер записывает данные в каталог /data, изменения также отображают­ ся в каталоге /mnt/data хоста. Дll я томов, с монтированных оп исанн ы м выше образом , система Doc k er не коп ирует существующие файл ы из смонтированного каталога контейнера в том . Как и в случае с традицион н ы м монтированием файловой систе м ы , содержи мое тома заменяет исход­ ное содержимое смонтированного каталога в контейнере. Л р и запус ке конте йнеров в облаке м ы предпагае м комби н и ро вать монтирование при вязок с хране н и е м блоков, предпагаем ы м облач н ы м и провайдера м и . Например, тома Elastic Bloc k Storage службы AWS я вля ются отл ич н ы м и резерв н ы м и хран или щам и дпя монтирования привязки Doc k e r. У них есть встроен н ые средства дпя создания м гно­ венных с н им ков и они могут перемещаться между экзе м плярами Е С2. Они также могут быть скопированы между хостам и , что позволяет другим системам проще получать дан ­ ные контейнера. Вы можете испол ьзовать собстве нные средства создан ия с н и м ков E B S дпя создан ия простой систе м ы резервного копирования.

Контейнеры да нных Одн и м из полезных проектных реше н и й , которое возникло из реального оп ыта, я в ­ ляется конте йнер, предназначен н ы й тол ько дпя дан ных. Е го цел ь — сохранить конфи­ гурацию тома для других контей неров, чтобы эти конте йнеры можно было легко пере­ запустить и заменить. Создайте контей нер дан ных, используя либо обычн ы й том , л ибо том . с монтирован­ ный с привязкой на хосте . Конте йнер дан ных при этом никогда не запускается. # docker create -v /шnt/data : /data — -name nqinx-data nqinx

Теперь вы можете испол ьзовать том контейнера дан н ых в контей нере , где запускает­ ся сервер nginx: # docker run — -volUD1e s -from nqinx-data -р 8 0 : 8 0 — -name wеЬ -d nqinx

Контейнер web имеет доступ на чте н ие и зап ись к тому /data, которы й на самом деле я вляется контейнером дан н ых с и м е н е м nginx-data. Контейнер web может быть перезапуще н , удале н или замен е н , но пока при его запуске указан параметр — -volume s ­ from, файлы в каталоге /data будут оставаться неизме н н ы м и . no правде говоря, идея объединения сохраняемых дан ных с контейнерами немного не соответствует принятым стандартам. Контейнеры должн ы создаваться и удаляться неза­ медпительно в ответ на вне ш н ие события. Идеальным решением является наличие парка идентичных серверов, на которых запущен демон dockerd, причем контейнеры могут быть размещены на л юбом из серверов. Однако, когда вы добавляете сохраняемые тома данн ых, контейнер становится привязанным к определенному серверу. Как бы нам ни хотелось жить в идеальном м ире, многим приложениям периодически нужны сохраняемые данные.

Сети Docker Как обсуждалось выше в разделе » Сеть » , существует нескол ько способов подключе­ ния контей неров к сети . Во вре м я установки система Doc k er создает три стандартных сетевых опции. Вывести их можно с помощью команды docker network l s . # docker network ls NАМЕ NETWORK I D b r i dge 65 1 4 е 7 1 0 8 5 0 8

DRIVER b r i dg e

Глава 2 5 . Контейнеры

l a 7 2 c l e 4 b2 3 0 e0f4e 608c92c

935

null host

none host

В стандартном реж и м е моста ( о п ц и я

b r i dge)

конте й н е р ы находятс я в частной сети

с п ростра нством и м е н , рас положе н н ы м в п р еделах хоста. М ост соед и няет сеть хоста с пространством и м е н конте й неров. Когда вы создаете конте й н е р и назначаете е м у порт хоста с помощью ко манды docker run -р, систе м а

Doc ker

создает п ра в ила iptaЬ le s ,

котор ы е марш рутизируют траф и к от общего и нтерфе йса хоста к и нтерфейсу конте й н е ра в сети моста .

W Дополн ител ьную информацию о команде П р и ис пол ьзова н и и о п ц и и

iptaЫes с м .

в разделе 1 3 . 1 4.

h o s t не и с п ол ьзуется отдел ьное п рост ранство с ете в ы х

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

h o s t , н о эта кон ф и гура ц и я

также м ожет п р и вести к конфл и ктам портов и други м п робле мам . Сете вая о п ц и я

n o n e указы вает, что с и сте м а Docker не дол ж н а п р ед п р и н и мать н и ка ­

ких ш а гов дл я н астрой ки сети . О н а предназнач е н а для слож н ы х с ц е н а р и е в ис пол ьзова ­ н и я , которые и м е ют с пе ц и ал ь н ы е требова н и я к сети. Дл я в ы бора опции сети конте й н ера п ередайте аргум е н т — -net кома нде docker .

Пространства имен и мостовая сеть Linux, соеди н я ющая два сегме нта сети. Во вре м я и н сталля ­ создает н а хосте мост, называе м ы й doc ke r O . Систе м а Docker выбирает п ространство и м е н 1 Р-адресов для дал ьней сторон ы моста , которое по е е М ост — это фун кция ядра

ц и и с исте м а

Docker автоматически

расчетам в р я д л и войдет в кон фл и кт с л ю б ы м и друг и м и сетя м и , досту п н ы м и из хоста. Каждо му кон те й н еру предоставл я ется в и ртуал ь н ы й сетевой и нтерфе йс с п ростран ство:v� и м е н , которы й и м еет I Р-адрес в пределах м остового сете вого диапазона. Ал гор итм в ы бора адресов практиче н , н о не идеал е н . В ва ш е й сети могут быть марш ­ рут ы , которые не видн ы с хоста . Есл и п рои зойдет колл и з и я , хост бол ьше н е с может по­ лучить доступ к удал е н н о й сети с перекр ы ва ю щ и мся адрес н ы м п ростра нством . н о с мо ­ ж е т пол у ч и т ь доступ к л о кал ьн ы м конте й н е ра м . Есл и в ы оказал и с ь в такой с и туашш ил и ва м н уж н о изм е н ить адре с н ое п ространство м оста по како й -л и бо другой п р и ч и н е , и с п ол ьзуйте аргум е н т — — f i xed-cidr де мона dockerd. П ростра нства и м е н в сети за висят от в и ртуал ьн ы х и н терфе йсов, стра н н ы х кон стру к ­ ц и й , создавае м ы х пара м и . где од на сторо н а находится в п ространстве и м е н хоста , а дру­ гая — в конте й н е ре .

Та к и м образо м , пото к и дан н ы х , входя щ и е на од н о м ко н це п а р ы

и вы ходя щ и е н а другом , соеди н я ют конте й н е р с хосто м . В бол ь ш и нстве случае в конте й ­ н е р и м еет тол ько одн у такую пару. Эту кон це п ц и ю илл юстр ирует р и с .

Контейнер #1 eth0: 172.17.42.13

veth9722da1

Контейнер #2 eth0: 172.17.42.19

veth63aed12

25.3.

Операционная система хоста

docker0 172.17.42.1

enp0s3 10.0.2.15

Рис. 25.З. Мостовая сеть платформы Docker

Внешняя сеть

936

Часть lV. Эксплvатация

Одна половина каждой пары видна из сетевого стека хоста . Например, н иже п ред­ ста влены види м ые и нтерфейсы на хосте CentOS с одн им запуще н н ы м конте й н ером . c e n t o s $ ip addr show 2 : e n p 0 s 3 : < B ROADCAST , MULT I CA S T , U P , LOWER_ U P > rntu 1 5 0 0 qdi s c p f i fo_ f a s t s tate UP qlen 1 0 0 0 l ink/ether 0 8 : 0 0 : 2 7 : c3 : 3 6 : f 0 brd ff : f f : f f : f f : f f : f f i n e t 1 0 . 0 . 2 . 1 5 / 2 4 b r d 1 0 . 0 . 2 . 2 5 5 s c ope g l ob a l dyn arni c e np 0 s 3 va l i d_l f t 7 1 3 6 8 s e c p r e f e r r e d_l f t 7 1 3 6 8 s e c i ne t 6 f e 8 0 : : a 0 0 : 2 7 f f : f e c 3 : 3 6 f 0 / 6 4 s c ope l i n k va l i d_l f t f o r eve r p r e f e r r e d_ l f t f o reve r 3 : doc ke r O : < B ROADCAST , MULT I CAST , U P , LOWER_U P> rntu 1 5 0 0 qdi s c n o q u e u e state UP l in k / e ther 0 2 : 4 2 : d4 : 3 0 : 5 9 : 2 4 brd f f : f f : f f : f f : f f : f f i n e t 1 7 2 . 1 7 . 4 2 . 1 / 1 6 s c ope g l ob a l doc ke r O v a l i d_l f t f o r e v e r p r e f e r r e d_ l f t f o r e v e r i ne t 6 f e 8 0 : : 4 2 : d 4 f f : f e 3 0 : 5 9 2 4 / 6 4 s c ope l i n k v a l i d_l f t f o r e v e r p r e f e r r e d_l f t f o reve r 5 3 : v e t h 5 8 4 a 0 2 l @ i f 5 2 : < BROADCAST , MULT I CAST , U P , LOWER_U P > rntu 1 5 0 0 qdi s c n o q u e u e rna s t e r doc k e r O s t a t e U P l i n k / e t h e r d 6 : 3 9 : a 7 : bd : b f : eb b r d f f : f f : f f : f f : f f : f f l i n k- n e t n s i d О i ne t 6 f e B O : : d 4 3 9 : a 7 f f : febd : b f e Ь / 6 4 s cope l i n k va l i d_l f t f o r eve r p r e f e r r e d_l f t f o re v e r

В этом л исти н ге показан основной и н терфе йс хоста e n p O s З , а также в иртуал ь­ н ы й мост Ethernet с и нтерфейсом do c ke r O , в котором испол ьзуется сеть 1 72 . 1 7 . 42 . 0/ 1 6. И нтерфейс v e t h — это сторона хоста в в иртуальной паре и нтерфейсов, соединяющей контейнер с мостовой сетью. Сторона контей нера мостовой пары не видна с хоста без отображен и я н изкоуров­ невых деталей сетевого стека. Эта невидимость я вляется лишь побоч н ы м эффе ктом ра­ боты сетевых пространств имен . Однако мы м ожем обнаружить интерфейс, отобрази в информацию самом конте й н ере. # docker inspect — f ‘ { { j son . NetworkSettinqs . Networks . Ьridqe } } ‘ nqinx » b r i d ge » : { «Gateway » : » 1 7 2 . 1 7 . 4 2 . 1 » , » I PAdd r e s s » : » 1 7 2 . 1 7 . 4 2 . 1 3 » , » I P P r e f i x L en » : 1 6 , «MacAdd r e s s » : » 0 2 : 4 2 : ас : 1 1 : 0 0 : 0 3 «

l Р- адрес контей н ера — 1 72 . 1 7 . 4 2 . 1 3 , а е го стандарт н ы й шлюз — и нтерфейс м оста d o c k e r O . (Эта мостовая пара изображен а на рис. 25 . 3 . ) В кон ф и гурации моста, п р и ­ нятой по умолчанию, в с е конте й неры могут с вязы ваться друг с друго м , потому что все о н и находятся в одной и той же виртуальной сети . Однако вы можете создать допол н и ­ тельные пространства и м е н в сети , чтобы изолировать контейнеры друг о т друга. Таким образом , в ы можете обслуживать н ескол ько изол ирова н н ы х сред и з одного и того же набора экзе м пляров конте йнера.

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

Глава 25. контейнеры

937

на отдел ьных хостах, могут марш рутизировать трафик друr к другу через частное сетевое адрес ное пространство. Технология Virtual eXtensiЫe LAN (VXLAN ) , описанная в спец­ ификации R FC7 348 , представляет собой одну с истему, которая может быть объединена с контей нерам и для реализац и и рас ш и ре н н ых сетевых возможностей . За дополн ител ь­ ной информацией обратитесь к докуме нтации по сетя м Docker.

Драй веры хранилищ Систе м ы U N IX и Linux предлагают нескол ько способов реализации объединен ной файловой с исте м ы . Платформа Docker н е зависит от этих способов реал изац и и и про­ пускает все операци и с файловой системой через выбран н ы й вам и драй вер хра н ил и ща. Дра й ве р хра н ил и ща настрое н как часть параметров зап ус ка демона докеров. Ваш выбор механ изма хран е н ия и меет важные последствия для производительности и ста­ бильност и , особе нно в производстве н н ых средах, поддерживающих м ногие контейнеры. Те кущ и й набор драйверов приведен в табл . 25.2. Таблица 2 5 . 2 . Драйверы хранилищ Docker Драй ве р au f s

Описание и комментарии

Повторная реализация оригинальной файловой системы UnionFS Оригинальный механизм хранения Docker По умолчанию предусмотрен в системах DeЬian и Ubuntu В настоящее время устарел, поскольку не является час»ТЪЮ ядра основной линейки семей­ ства Unux

Ьtrfs

…………………………………

Использует файловую систему Btrfs с копированием при записи (см. раздел 20. 1 3) Стабилен и включен в основное ядро Linux Использование на платформе Docker предусмотрено лишь в некоторых дистрибутивах и но­ сит экспериментальный характер ·- · — — — ·

__ , _

— —

.

devicemapp e r По умолчанию предусмотрен в системе RHEL/CentOS 6

Настоятельно рекомендуется режим прямого доступа LVМ, но требуется настройка Имеет историю ошибок Требует изучения документации devicemapp e r для платформы Docker ·-··

ove r l a y

— — —

_,_ » __ » _ _ ..

Основан на файловой системе OverlayFS Считается заменой файловой системы AuFS Предусмотрен по умолчанию в системе CentOS 7, если загружен модуль ядра overlay

vfs

Не настоящая объединенная файловая система Медленный, но стабильный, подходит для некоторых производственных сред Хорошо подходит для доказательства концепции или в качестве тестового стенда

z fs

……….. .. .

.. …… ………..

Использует файловую систему с поддержкой копирования при записи ZFS (см. раздел 20. 1 2) По умолчанию предусмотрен для системы FreeBSD Считается экспериментальным в системе Linux

Драйвер YFS по существу делает н е возможн ы м испол ьзован ие объедин е н ной фай ­ ловой с исте м ы . Система Docker создает полную коп и ю образа для каждого конте й нера, что приводит к увел ич е н и ю испол ьзования дискового пространства и вре м е н и запус ка конте й н ера. Однако эта реал изация п роста и надежна. Если ваш сценарий испол ьзова-

938

Часть lV. Эксплуатация

н ия включает долrожи вущие контейнеры , виртуал ьная файловая система YFS я вляется надежн ым выбором. Одн ако мы н икоrда не видели орrанизаци й , в которых бы исполь­ зовались такие файловые систе м ы в производствен н ы х приложе н и ях. Btrfs и Z FS также н е я вл я ются исти н н ы м и объеди н е н н ы м и файлов ы м и систе ма­ ми. Тем н е менее они эффе кти в н о и н адежно реал изуют оверл е и , п отому что изна­ чал ь н о поддержи вают кло н и ро ва н и е файлово й с исте м ы через ко п и рова н и е п р и за­ п и с и . Поддержка платформ ы Docker мя файловых с истем Btrfs и ZFS в н астоя щее вре мя оrраничена нескол ьк и м и конкрет н ы м и дистр ибутивам и Linux (а также Free B S D для Z FS) , но это перспекти вные варианты . Чем м е н ьше атрибутов файловой с исте м ы , характерных м я контей нерной систе м ы , т е м луч ше . Выбор драйвера хранил и ща — это тон кая тема. Если вы ил и кто-то и з вашей коман­ ды не знает одну и з этих файлоных с истем в совершенстве , м ы рекоме ндуем придержи ­ ваться файловой с исте м ы , которая предусмотрена в вашем дистрибутиве по умолчанию. Допол нительную и нформацию с м . в докуме нтаци и о драйверах хранения на платформе Docker.

Изменен ие парамет р о в настройки демона dockerd Вам н е и збежно п р идется и з м е н ить н е котор ы е н астро й к и д е м о н а d o c k e r d . П араметры настро й к и в кл ючают механизм хран е н и я , параметры D N S и базовый ката­ лоr, в котором хранятся образы и метаданные. Для того чтобы просмотреть пол н ы й спи­ сок аргу м е нто в , запустите команду dockerd -h. В ы м ожете у в идеть те кущую ко н ф и rура ц и ю де м о н а с п о м о щ ь ю к о м а н д ы docker info. c e nt o s # docker info C o n t a i ne r s : 6 Runn i n g : О P au s e d : О S t oppe d : 6 I mag e s : 9 S e rve r Ve r s i on : 1 . 1 0 . З S t o r a g e D r i ve r : ove r l a y B a c k i n g Fi l e s y s t em : x f s Logging D r i ve r : j s on — f i l e P l u g in s : Vol ume : l o c a l N e t w o r k : b r i dge n u l l h o s t K e r n e l Ve r s i on : З . 1 0 . О — 3 2 7 . 1 0 . 1 . е 1 7 . х 8 6 6 4 Ope r a t i n g S y s t em : C e n t O S L i n u x 7 ( C o r e ) OSType : l i nux Arch i t e c t u r e : х 8 6 6 4

Это хороши й способ проверки тоrо , что все сдел а н н ы е вами н астро й к и всту п ил и в силу. W Дополн ительную и нформацию об изменении модул ьных файлов с помощью утил иты systemctl см . в главе 2.

Управление демонам и , вкл ючая изменение параметров запуска на платформе Docker, аналоrич но управле н и ю в с истеме ini t. Например, в дистр ибутиве , испол ьзующем де­ мон sys temd, следующая команда редактирует модул ь службы Docker для установки драй вера хран илища, не п редус мотренноrо по умолчан и ю , набора DNS -cepвepoв и спе­ циальноrо адресноrо п ространства мя мостовой сети :

Глава 25. Контейнеры

939

$ systemctl edi t docker [ S e rv i c e ] Exe c S t a r t = Exe c S t a r t = / u s r / b i n / d o c k e r da emon — D — — s t o r a g e — d r i v e r ove r l a y — — d n s 8 . 8 . 8 . 8 — — d n s 8 . 8 . 4 . 4 — -b i p 1 7 2 . 1 8 . 0 . 0 / 1 9

Второе выраже н и е E x e c S t a r t = н е я вляется ош ибкой. Это выражен и е , характерное для утил иты system.d, сбрасы вает настройки , при н ятые по умолчанию, гарантируя , что новое определение испол ьзуется точно так, как показано. После изменен ия параметров нужно перезаrрузить демон с помощью утилиты system.ctl и проверить измен е н и я . c e n t o s $ sudo sys temctl res tart docker cent o s $ sudo sys temctl s tatus docker doc ke r . s e rv i c e L o a d e d : l oaded ( / e t c / s y s t emd / s y s t em / d o c ke r . s e rvi c e ; s t a t i c ; vendo r p r e s e t : d i s a Ы e d ) D r o p — I n : / e t c / s y s t emd / s y s t em / d o c ke r . s e rv i c e . d 1 — — — — ove r r i de . con f A c t i v e : a c t i ve ( r unn i n g ) s i n c e W e d 2 0 1 6 — 0 3 — 0 9 2 3 : 1 4 : 5 6 UTC ; 1 2 s a g o Main P I D : 4 3 2 8 ( d o c ke r ) CGroup : / s y s t em . s l i c e / d o c ke r . s e rv i c e 1 — — — — 4 3 2 8 / u s r /b i n / d o c k e r d aemon — D — — s t o r a g e — d r ive r ove r l a y — -dns 8 . 8 . 8 . 8 — -dns 8 . 8 . 4 . 4 — -bip 1 7 2 . 1 8 . 0 . 0 / 1 9

В операционн ых с истемах, ис пользующих с истему и н и циал изаци и ups tart, пара­ метры демона необходимо изме нять в файле /etc/default/docker. Для более старых систем с и н ициализацией в стиле SysV испол ьзуйте файл /etc/ sysconfig/docker. П о умол ч а н и ю демон dockerd п росл уш и вает сокет дом е н а U N I X / v a r / run / docke r . s o c k , кото р ы й и с пол ьзуется дл я подкл юч е н ия утил и т ы d o c ke r . Чтоб ы де м о н п рослуш и вал защ и ще н н ы й сокет н а ос нове T L S , и с п ол ьзуйте параметр -Н tcp : / / О . О . О . О : 2 3 7 6 . Более подробную и нформацию по настро й ке TLS с м . в раз­ деле 2 5 . 3 .

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

Выбор базового образа П е р ед с озда н и е м п ол ьзовател ьс к о го образа в ы б е р и т е п одход я щ у ю базу. Эмпиричес кое правило для базовых образов таково: чем м е н ь ш е размер, тем луч ш е . База должна содержать тол ько то, что необходимо для запуска ваш е го програм м ного обеспече н и я , и н и ч е го больше. М н огие офи циал ьн ы е образы ос н о ва н ы н а дистрибут и в е под н азван и е м Alpine Linux, который зан и мает менее 5 М байт, но он может и меть библ иотеч ную н есовме —

часть lV. Эксплvатация

940

сти мость с н е которы м и приложе н ия м и . Образ Ubuntu зан и м ает бол ьш е 1 8 8 Мбайт, но по сравн е н и ю с типичной установкой сервера его можно считать довольн о ком пактн ы м . Возможно, вы сможете найти базовый образ, в котором уже настрое н ы ком поненты сре­ ды выпол н е н и я вашего приложения. Стандартные базовые образы существуют для наи­ более распростра н ен н ы х языков, сред в ы пол н е н ия и платформ приложе н и й . Тщательно исследуйте свой базовый образ, прежде чем при н имать окончател ьное ре­ шение. Изучите файл Dockerfile вашего базового образа (см. следующий раздел) и лю­ бые неочевидн ые зависимости , чтобы избежать сюрпризов. Базовые образы могут и меть неожида н н ы е требования ил и включать уязви м ы е верс и и програ м м ного обеспечения. В н екоторых случаях вам может потребоваться скопировать файл Dockerfile базового образа и перестроить е го в соответствии со свои м и потребностям и . Когда д е м о н dockerd загружает образ, он загружает тол ько т е уровн и , которых у н е го еще нет. Если все ва ш и п р иложе н ия используют одну и ту же базу, для загрузки демона требуется м е н ьш е дан н ы х , и при первом запуске конте й н еры запус каются бы­ стрее.

Сборка из файла Docker:Eile Dockerfi le это рецепт для сборки образа. Он содержит ряд инструкций и ко­ манд оболочки. Команда docker Ьuild считывает файл Dockerfile, последовател ьно выпол няет и н струкц и и в нем и ф и ксирует результат как образ. П роекты по разработке программного обеспече н и я , использующие файл Dockerfile, обычно хранят его в кор­ н е вом каталоге хра н ил и ща G it , чтобы облегч ить создание новых образов, содержащих это программ ное обеспечение. Первая инструкция в файле Dockerfile указы вает образ, котор ы й будет испол ьзо­ ваться в качестве базы . Каждая последующая и н струкция совершает переход на новый уровень, который в с вою очередь испол ьзуется в качестве базы для следующей команд ы . Каждый уровень включает тол ько изменения предьщущего уровн я . Общая файловая с и ­ стема объединяет уровни для создания корн е вой файловой систе м ы контей нера. Вот как в ы глядит файл Dockerfile, который создает офи циал ьн ы й образ N G I NX для систе м ы Deblan .5 —

FROM deb i an : j e s s i e МAI NTAI N E R N G I NX Doc k e r M a i n t a i n e r s » d o c k e r -ma i n t @ ng i n x . c om» ENV NG I NX VERS I ON 1 . 1 0 . 3 — 1 — j e s s i e _ RUN a p t — g e t upda t e & & a p t — g e t i n s t a l l — у c a — c e r t i f i c a t e s n g i n x � $ ( NG I NX_VERS I ON } & & rm — r f / va r / l i Ь / ap t / l i s t s / * # f o rw a r d r e qu e s t and e r r o r l o g s t o doc ke r l o g c o l l e c t o r RUN l n — s f / d e v / s tdout /va r / l og / n g i n x / a c c e s s . l og & & l n — s f / d ev / s t d e r r / va r / l og / n g i nx / e r r o r . l o g EXPOSE 8 0 4 4 3 CMD [ » n g i nx » , » — g » , » da emon o f f ; » ]

Сервер NG I NX использует в качестве базы образ d e Ь i a n : j e s s i e . После объя влен ия контактов групп ы поддержки продукта (maintainer) в файле устанавл и вается перемен ная среды (NG I NX _VERS I ON ) , которая становится доступной для всех последующих и нструк­ ц и й в файле Dockerfile, а также для л юбого процесса, который выпол няется внутри конте й н ера после сборки и создания экзем пляра образа. Бол ьш ую часть работы по и н ­ сталляции сервера NG I NX из репозитория пакетов вы пол няет первая и нструкция RUN. � пример взят из проекта g i t hub . c om / n g i nx i n c / do c ke r — n g i nx и немного упрощен .

Глава 2 5 . контейнеры

941

По умолчанию сервер NG I NX отправляет данн ые журнала в файл /var/log/nginx/ access . log, но по соглашению, принятому для контейнеров, сообщения должн ы выво­ диться в поток S T DOU T . Поэтому в последней команде RUN груп па поддержки продукта создала символическую ссыл ку для перенаправления журнала доступа в поток S T DOUT . Аналогично ошибки перенаправляются в поток контей нера . Команда E X P O S E сообщает демону dockerd, какие порты прослуш и вает контей нер. Ис пол ьзуемые порты могут быть переопределены во время запуска контей нера с помо­ щью команды docker run с параметром -р. Последняя инструкция в файле Dockerfi le сервера N G I N X это команда, кото­ рую долже н выполн ить демон dockerd при запуске контейнера. В этом случае контей­ нер запускает двоичны й файл nginx как процесс передне го плана. Краткое описание и н струкци й и з файла D o c k e r f i l e п р и ведено в табл . 2 5 . 3 . Справочное руководство на d o c s . doc ke r . с от я вляется официальной документацией. —

Таблица 25.З. Сокращенный список инструкций из файла Dockerfile Инструкция

Описание

ADD

Копирует файлы с хоста сборки в образ•

ARG

Устанавли вает переменные, которые можно использовать во время сборки , но не в конечном образе; не предназначена для закрытой информации

CMD

Устанавливает команды по умолчанию для выполнения в контейнере

СОРУ

Аналогична команде ADD, но только для файлов и каталогов

ENV

Устанавливает переменные среды , доступные для всех последующих инструкций сборки и контейнеров, порожденных этим образом

ЕХ POS Е

Сообщает демону dockerd о сетевых портах, открытых в контейнере

FROM

Устанавливает базовый образ ; эта инструкция должна быть первой

LABEL

Устанавливает теги образов, отображаемые с помощью команды docker inspect

RUN

Выполняет команды и сохраняет результат в образе

S T OP S I GNAL

Задает сигнал , который отправляется в процесс для его остановки по команде docker s top; по умолчанию S I G K I L L Задает имя учетной записи для использования при запуске контейнера и выполнении лю­ бых последующих инструкций по сборке —

U S ER VOLUME

Назначает том для хранения постоянных данных

WORK D I R

Задает стандартный рабочий каталог для последующих инструкци й.

‘ Источником может быть файл, каталог, архив tar или удаленный ресурс, заданный U RL.

Сборка произво дного образа из файла Dockerfile Для создания производного образа сервера NG I N X можно испол ьзовать очень про­ стой файл Dockerfile , в котором добавлен пользовательски й вариант файла index . html , заменяющего значение по умолчанию. $ cat index . html < ! DOC T Y P E h tml > < t i t l e >UL SAH i n d e x . html f i l e < / t i t l e > А s impl e D o c k e r image , b r ought t o y o u Ьу ULSAH . < /p> $ cat Dockerfi le FROM n g i n x # A d d а n e w i nd e x . h tml t o t h e documen t r o o t A D D i nd e x . h tml / u s r / s h a r e / n g i n x / h tml /

Часть lV. Эксплуатация

942

Есл и не принимать во вни мание пол ьзовательский вариант файла index . html , наш новы й образ будет иденти чны м базовому. Вот как создается измене н н ы й образ. # docker build — t nqinx : ulsah S t ep 1 : FROM n g i n x — — — > f d 1 9 5 2 4 4 1 5 dc S t ep 2 : ADD i n d e x . html / u s r / s h a r e / n g i n x / h tml / —> c0c25eaf74 1 5 Removi n g i n t e rme d i a t e c on t a i n e r 0 4 cc 3 2 7 8 fdb4 S u c c e s s f u l l y bui l t c 0 c 2 5 e a f 7 4 1 5

Для создания образа с именем n g i nx и тегом u l s a h испол ьзуется команда docker build с параметрам и -t nginx : u l s ah , чтобы отлич ить его от офи циал ьного образа сервера NG I NX. Конеч ная точка сообщает команде docker build, где можно найти фа йл Dockerfile ( в данном случае в текущем каталоге ) . Теперь м ы можем запустить образ и прос мотреть работу нашего измененного файла index . html : # docker run -р 8 0 : 8 0 — -name nqinx-ulsah -d nqinx : ulsah $ curl localhost < ! DOC T Y P E html > < t i t l e > U LS AH i n d e x . html f i l e < / t i t l e > А s impl e Doc k e r image , b rought t o y o u Ь у U LSAH . < / p >

М ы можем убедиться , что наш образ указан среди локальных образов, выпол н и в ко­ манду docker images . # docker iшaqes 1 qrep ulsah I МAGE I D REPOS I T ORY TAG c 0 c2 5 e a f 7 4 1 5 nginx u l s ah

C REATE D З minu t e s a g o

SIZE 1 3 4 . 6 мв

Ч тобы удалить образы , выпол н ите команду docker rmi . Вы не можете удал ить об­ раз, пока не остановите и не удалите все контейнеры, которые е го испол ьзуют. # docker ps qrep nqinx : ulsah S TAТU S I МAGE СОММАND U p 3 7 s e conds n g i nx : u l s a h » ng i n x — g ‘ da emon o f f » # docker s top nqinx-ulsah & & docker rm nqinx-ulsah n g i nx — u l s a h n g i nx — u l s ah # docker rmi nqinx : ulsah

PORTS 0 . 0 . 0 . 0 : 8 0 — > 8 0 / t cp

Обе команды — docker s top и docker rm — повторя ют название испол ьзуемого контейнера, в резул ьтате чего строка «nginx-ulsah » выводится дважды.

Реестры Реестр — это и ндекс образов платформы Doc k e r, к которому демон dockerd может получить доступ через протокол НТТР. Когда запраш и вается образ, не существующий на локальном диске , демон dockerd извлекает е го из реестра. Образы загружаются в ре­ естр с помощью команды docker push. Хотя операции с образа м и и н и ци и руются ко­ мандой docker, только демон dockerd фактически взаимодействует с реестрам и . Doc k e r Hub — это общедоступная служба реестра, п оддержи вае мая компан и е й Doc k e r, I nc. О н а содержит образы для многих дистрибутивов и проектов с открытым ис­ ходн ы м кодом , вкл ючая все рассматриваемые нам и примеры Linux-cиcтeм . Целостность этих официал ьн ы х образов проверя ется с помощью с исте м ы доверенного конте нта , гарантируя те м сам ы м , что загружаем ы й образ предоставляется поставщиком , ч ье имя

Глава 2 5 . Контейнеры

943

находится н а этикетке. Вы также м ожете публи ковать собствен н ы е о б р аз ы в реестре Docker H ub Д11 Я других пользователей . Л юбой пользователь может загружать общедоступные образы из реестра Docker Hub, но, имея подписку, вы также можете создавать частные репозитории. Получи в платную учетную запись на сайте hub . doc ke r . com, войдите в систему из командной строки с помощью ко­ манды docker login Д11 Я доступа к персональному реестру, чтобы получить возможность загружать и выгружать собствен н ые пользовательские обр азы Вы также можете запускать сборку образов всякий раз, когда в репозитори и GitHub рир уетс я фиксация. Служба Doc k e r H ub — н е еди нстве н н ы й реестр , п оддержи в а ю щ и й п од п и с ку Существуют и другие : q u a y . i o , Artifactory, Google Container Registry и Amaz o n ЕС2 Container Registry. Docker Hub — это щедры й источ н и к образов Д11 Я крупной экосисте м ы . Кром е того, он постепенно становится реестром по умолчан ию, есл и вам н е нужно нечто более не­ обычное. Например, команда .

.

# docker pull debian : j es s ie

сначала ищет локал ьную коп и ю образа. Если образ не доступен локально, следующей остановко й я вляется Docker H ub. Вы можете указать демону docker использовать дру­ гой реестр, включив имя хоста или U RL-aдpec в специфи кацию образа: # docker pull regis try . admin . com/debian : j essie

Аналогично при создании образа Д11 Я зан есения в пол ьзовател ьский реестр вы долж­ ны указать его U R L-aдpec и пройти аутентификацию перед загрузкой . # docker tag deЬian : j essie regi s try . admin . com/debian : j e s s ie # docker login https : / /regi stry . admin . com U s e rn ame : ben P a s s w o r d : # docker push regis try . admin . com/debian : j essie

С истема Docker сохраняет дан н ы е регистрации в файл е , хранящемся в вашем до­ машн е м каталоге под названием dockercfg, поэтому вам н е н ужно с нова входить в систему при следующем взаимодействии с персональным реестром. Исходя из соображе н и й , связан ных с производительностью или безопасностью, вы можете испол ьзовать собстве н н ы й реестр образов. Прое к т реестра относится к откры­ тому исходному коду (gi t h u b . c om/ do c ke r / d i s t r ibut i o n) , а простой реестр легко за­ пускается как контейнер. 6 .

# docker run -d -р 5 0 0 0 : 5 0 0 0 — -name regi s try regi s try : 2

Служба реестра теперь запущена на порту 5000. Вы можете извлечь и з него искомый образ, указав его имя. # docker pull localhost : 5 0 0 0 / deЬian : j es s ie

В реестре реализованы два метода аутентификации: t o ke n и h t p a s swd. Метод t o ke n делегирует аутентифи каци ю в н е ш н е м у провайдеру, ч то, вероятно, потребует специаль­ ных усили й с вашей сторон ы . М етод h t p a s swd проще и допус кает базовую ауте нтифи­ кацию НТТР для доступа к реестру. Кром е того , вы можете настроить прокси-сервер (например, N G I NX) Д11 Я обработки аутентификации. Все гда запус кайте реестр с под­ держкой протокола TLS. ‘Тег registry : 2 отличает реестр последнего поколения от п редыдущей верс и и , которая реализ ует и нтерфейс AP I , несовмести м ы й с текущи ми верси я м и п л атф ор м ы Doc ker.

Часть lV. Эксплуатация

944

Стандартная конфигурация персонал ьного реестра не подходит для крупномасштаб­ ного развертыва н и я . Для испол ьзован ия в п роизводстве н ной среде н ужно учесть ряд требован и й , связа н н ы х с п ространством для хран е н и я , требованиям и к ауте нтификации и авторизации , к стира н и ю образов и другим и задачам и обслуживан и я . По м ере рас ши рения контейнерной среды в а ш реестр будет затоплен новы м и обра­ зам и . Для пользователе й , работающих в облаке , одн и м из возможных способов хра н е ­ ния всех этих дан н ых я м я ются объектные хранилища, такие как Amazon SЗ или Google Cloud Storage. Реестр поддерживает обе службы . Е щ е луч ш е перенаправить с вои фун кции реестра в реестр ы , встрое н н ы е в выбра н ­ ную вам и облачную платформу, и одн о й п роблемой станет м е н ьш е . О б е ком п а н и и , Google и Amazon , предостамяют услуги упрамяемого реестра контей неров. Вы платите за хранение и сетевой трафик, н еобход и м ы й для загрузки и вы грузки образов.

25.3.

КОНТЕЙНЕРЫ НА ПРАКТИКЕ

Как тол ько вы освоите общие п р и н ц и п ы работы с конте йнерами , вы обнаружите , что в контейнеризован ном м ире к адми н истративны м фун кция м и необходимо подхо­ дить по-другому. Например, как вы упрамяете файлами журналов для конте й н е р н ы х приложе н и й ? Каковы требования безопасности? Как устран ить ошибки? В приведен ном н иже с п ис ке содержатся э м п и р и ческие п равила, которые помогут вам адаmироваться к жизни внутри конте й н ера. •

Есл и вашему приложе н и ю необходимо выпол н ить заплан ирован ное зада н и е , не зап ускайте планировщик cron в контей н ере. Для того чтоб ы создать расписание для короткоживущего контейнера, который запускает зада н и е и завершает с вою работу, ис пол ьзуйте демон cron на хосте ( ил и тай м е р sys temd ) . Конте й н е р ы предназначены для одноразового использвания. Вам необходимо войти в с истему и проверить, что делает процесс? Н е запус кайте демона s shd в контейнере. П одкл юч итесь к хосту с помощью команды ssh, а за­ тем используйте команду docker ехес, чтобы открыть и нтерактивную оболоч ку. П о возможности настройте с вое программ ное обеспечение так , чтобы оно полу­ чало и нформацию о конфигурации из пере м е н н ых окруже н и я . В ы можете пере­ давать перемен н ы е окружен и я в конте й н е р ы с помощью команды docker run и аргумента -е клю ч= зна чение. Или установите сразу несколько пере м е н н ы х о кружен ия из отдел ьного файла с помощью параметра -env-file имя_ фа йла . И гнорируйте рас пространенное м н е н и е , утверждающее , что в контей нере должен существовать только оди н процесс. Это вздор. Рас пределяйте процессы по отдел ь­ н ы м контей н ерам только тогда, когда это целесообразно. Н апример, обычно реко­ мендуется запус кать приложен ие и его сервер базы дан н ых в отдельных контейне­ рах, поскольку они разделен ы четкими архитектур н ы м и гран и цами . Однако ничего страшного, если в конте йнере есть несколько процессов. Руководствуйтесь здравым смыслом. Сосредоточ ьтесь н а автоматическом созда н и и конте й н еров дл я ваш е й среды . Напиш ите сценарии для создан ия образов и их загрузки в реестр ы . Убедитесь, что процедуры развертывания программного обеспечения вкл ючают замену контейне­ ров, а н е обномение их на месте. Избегайте обслуживания конте йн еров. Есл и вы вруч ную загружаете конте й н е р , чтобы исправить что-то, выясн ите , в чем проблема, устран ите ее н а образе , а затем

Глава 25. контейнеры

94 5

заме ните конте й н ер. Немедленно обновите инструм е нт автоматизации , есл и это н еобходимо. •

Стол к н улись с трудностям и ? Задавайте вопрос ы , испол ьзуя с писок рассылки пользователе й Docker Slack Community или I RС-канал Jtdoc ke r в сети f re e n o d e .

Все , что необходимо для работы приложения, должно быть доступно в его контейне­ ре : файловая система, доступ к сети и фун кциональные средства ядра. Единстве н н ы м и процессами , которые запускаются в конте й нере, являются те , которые запускаете вы. Для контей неров нетипично запускать обычные системные службы , такие как cron, rsyslogd и sshd, хотя это, безусловно, возможно. Эти обязан ности лучше всего оставить для хоста операционной системы. Если эти службы вам нужны именно в контейнере, еще раз ис­ следуйте свою проблему и попытайтесь найти более удобн ы й для контей неров способ.

В едение журнала Для в ывода диаrностических сообще н и й в приложен ия х U N I X и Linux традиционно используется система Syslog (теперь демон rsyslogd} . Система Syslog выпол няет филь­ траци ю сообще н и й в журналах, а также их сортировку и м аршрутизацию в удал е н н ы е систе м ы . В некоторых приложен иях система Syslog не испол ьзуется , и вместо этого со­ общения записываются непосредствен но в файлы журнала. Система Syslog не запускается в контейнерах. В место этого систем а Docker собирает диагн остические сообщения с помощью специальных драйверов веден ия журнала. Для этого контейнерные процессы должны записывать сообщен и я только в поток S T DOUT , а ошибки — только в поток ST DERR. Система Docker собирает эти сообщен ия и отправля­ ет их в указанн ый пункт назначения. Если ваше программ ное обеспеч е н ие поддерживает ведение журнала только с помо­ щью файлов, примените тот же метод, что и в примере с сервером NG I NX, приведе н ­ ном выше: п р и сборке образа создайте символические ссылк и из файлов журнала в по­ токи /dev/stdout и /dev/stderr. Система Docker пересылает журнальные записи , которые она получает, выбираемому драйверу ведения журнала. В табл. 25.4 переч ислены н екоторые и з наиболее распростра­ ненных и полезных драйверов ведения журнала. Таблица 25.4. Драйве р ы ведения жур нала в системе Docker Драйвер

Предназначение

j s on — f i l e

Заносит журнальные записи в формате JSON в каталог данных демона ( по умолчанию)•

syslog

Зано с ит журнальные запи с и в место, указанное системой Syslog6

j ou r n a l d

Заносит записи в журнал sys temd»

gel f

Зано сит журнальные записи в расширенном формате Graylog

aws l o g s

Заносит журнальные записи в службу AWS CloudWatch

gcp l o g s

Заносит записи в службу Google Cloud Loggiпg

none

Н е ведет журналы

» Журнальные зап и с и , х р ан я щи еся таки м образ ом, доступны для просмотра с помощью команды docker logs . 6 Поддерживает протоколы UDP, ТСР и ТСР+TLS.

П ри использован и и драй веров j s o n — f i l e или j ou r n a l d вы можете получить до­ ступ к дан н ы м журнала из командной строки с помощью команды docker logs i d_ к онтейнер а .

946

Часть lV. Эксплуатация

Стандарт н ы й драйвер ведения журнала для демона dockerd устанавл ивается с по­ мощью параметра командной строки —log-driver. Вы также можете назначить драй­ вер веден ия журнала во вре м я запуска контей н ера с помощью команды docker run — — logging-driver. Н е которым драйверам можно передать допол н ительные парам ет­ ры . Напр и м ер , параметр — — log-opt ма к с -ра змер настраи вает ротацию журнал ь н ы х файлов для драй вера j s o n — f i l e . Испол ьзуйте этот параметр, чтобы н е за полнять диск жур нал ьн ы м и файлам и . Подробная и нформация содержится в документац и и по веде­ н и ю журнала в системе Docker.

Советы по безопасности Безопасность контейнеров зависит от процессов , выпол няемых внутри контейнеров, которые н е могут получ ить доступ к файлам , процессам и други м ресурсам вне их пе­ соч н ицы. Уязвимости , позволяющие злоумы шле н н и кам вырваться из конте й неров, из­ вестн ы как атаки на прорыв (breakout attac k ) , — это серьез н ые , но редкие атаки. Код, лежащий в основе изол я ц и и конте й н еров, был вкл ючен в ядро Linux по край ней мере с 2008 г. ; он зрел ы й и стабил ьн ы й . Как и в случае с н езащище н н ы м и ил и виртуал и зо­ ван н ы м и систе м ам и , н ебезопас н ы е конфи гурации я вляются гораздо более вероятн ы м источн и ком ком пром етац и и , ч е м уязвимости на изолирующем уровне. Платформа Docker поддерживает и нтерес н ы й список известн ых програ м м ных уязви ­ мостей , которые могут смягчаться путем конте й н еризации (см. сайт d o c s . d o c ke r . сот/ e n g i ne / s e c u r i ty / no n — eve n t s ) .

Ограничьте доступ к демону П режде всеrо защитите демон dockerd. П ос кол ьку dockerd обязател ьно работает с повышен н ы м и привил е гиям и , л юбой пользовател ь, и м еющий доступ к этому демону, может легко получить пол н ы й привил егирова н н ы й доступ к хосту. Этот риск демонстрирует следующая последовател ьн ость команд. $ id u i d= l O O l ( be n ) g i d = l O O l ( be n ) g r o u p s = l O O l ( b e n ) , 9 9 2 ( do c ke r ) # docker run — — rm -v / : /host — t — i deЬian bash root @ e 5 l a e 8 6 c 5 f 7 b : / # cd /host r o ot @ e 5 1 a e 8 6 c 5 f 7 b : /h o s t # l s test s rv proc run bin dev home l i b 6 4 mn t tmp sЬin root sys boot e t c lib me d i a opt

usr va r

Эти сообще н ия показывают, что л юбой пол ьзователь в групп е d o c k e r может под­ кл ючить корн е вую файловую систему хоста к конте й н еру и получ ить пол н ы й контрол ь над ее содержи м ы м . Это все го л и ш ь оди н из м ногих возмож н ы х с пособов повыш е н ия при вилегий с помощью платформ ы Docker. Если по умол чан и ю для связи с демоном вы испол ьзуете сокет домена U N IX, добавь­ те тол ько довере н н ы х пользователе й в группу d o c k e r, которая и м е ет доступ к со кету. Еще луч ш е контрол ировать доступ с помощью програ м м ы sudo.

Используйте ТLS М ы говорили об этом раньше и повторим еще раз: есл и де мон dockerd должен быть доступ е н удал е н н о по сети (запущен с параметром -Н), н еобходи м о испол ьзовать про­ токол TLS дл я ш ифрования сетевых сообще н и й и вза и м ной ауте нтифи каци и кл иента и сервера.

Глава 25. контейнеры

947

W Дополнительную информацию о протоколе TLS см. в разделе 27.б. Н астройка TLS предполагает наличие авторитетного органа, выдающего сертификаты для демона dockerd и клиентов. После инсталляции пары кл ючей и центра сертификации подключение протокола TLS для docker и dockerd просто сводится к указанию правиль­ ных аргументов коман д ной строки. Основные параметры перечислены в табл. 25.5. Таблица 2 5 . 5 . Арrументы TLS, общие для проrраммы docker и демона dockerd Арrумент

Значение ипи арrумент

Требуется аутентификация

tlsve r ify

— — tlscert•

Путь к подписанному сертификату

— — tlskey»

Путь к закрытому ключу

— -tlscacert•

Путь к сертификату доверенного органа

• Необязательный а гумент. По умолчанию находится в каталоге / . docker / { cert , key , са ) pem. р �

.

Успеш ное использование протокола TLS зависит от зрелости процессов управления сертификатами. В ыдача сертифи катов, ан нулирован ие и истечение срока их действия вот некоторые из вопросов, которые требуют внимания. В основном — это бремя адм и­ нистратора, ответственного за безопасность.

В ыполняйте процессы от имени непривилегированного пользователя П роцессы в конте йнерах должн ы вы пол н яться от и м е н и н е п р ивилегирован ного пользователя , как это происходит в пол нофун кционал ьной операцион ной с истеме. Эта практика о гран ичивает способность злоум ы шле н н и ков орган изовы вать атаки на про­ рыв. Когда вы создаете файл Dockerfile, испол ьзуйте инструкцию U S E R дЛ Я запуска будущих команд на образе под учетной зап исью с указан н ы м именем пользователя .

Используйте корневую файловую систему в режим е только для чтения Для того чтобы допол н ител ьно ограничить использование контей неров, вы можете задать команду docker run — — read-only, тем самы м огран ичивая контейнер рам ками корневой файловой систе м ы , доступной только для чтения. Это решение хорошо подхо­ дит для служб без состоя н ия , которы м н икогда и н ичего не нужно записывать. Вы также можете с монтировать том для чтения-записи, который ваш процесс может изменять, но оставить корневую файловую систему только для чтения.

Ограничивайте во3можности W Дополнительную и нформацию о возможностях Liпux см. в разделе 3 . 3 . В ядре Linux определ е н ы 40 отдел ьных возможносте й , которые могут быть назна­ чен ы процессам . П о умолчан и ю контей неры Docker и м е ют бол ьшой набор возможно­ стей из этого списка. Вы можете вкл юч ить еще бол ьшее подм ножество возможностей , запустив контейнер с флагом — -privileged. Однако этот параметр отключает м ногие преи мущества изоляции при использовании платформ ы Docker. Вы можете настроить определенные возможности, доступн ые для контей нерных процессов , с помощью аргу­ ментов — -cap-add и — -cap-drop: i docker

run

— -cap-drop SEТUID — — cap-drop SETGID deЬian : j es sie

Вы также можете удал ить все привилегии и добавить обратно те, которые вам нужны: i docker

run

— — cap-drop ALL — — cap-add NET_RAW deЬian : j es s ie

948

Часть lV. Эксплуатация

Защищайте образы Функция доверия в системе Docker позволяет проверять подr1 и нность и целостность образов в реестре . И здатель образа подписывает его се крет н ы м ключом , а реестр п рове­ ряет его с помощью соответствующего открытого кл юча. Этот процесс гарантирует, что образ был создан ожидае м ы м автором . Вы можете испол ьзовать доверительное содер ­ жи мое дr1я подп исывания собстве н н ых образов ил и дr1я проверки образов в удал е н ном реестре . Эта фун кция доступна в хранил и ще Docker H ub и в некоторы х н езавис и м ы х реестрах, таких как Artifactory. К сожал е н и ю , бол ь ш ая часть содержи мого в хран ил и ще Dockeг Hub я вл яется н е ­ подписанной и должна считаться н е надежной . Н а самом деле бол ь ш и нство образо в в Docker H ub н и когда не исправляются , не обновляются и не п роверя ются каки м -л ибо образом . Отсутствие надлежащей це п и довер и я , ассо ц и и рова н ной со м ноги м и образа м и Docker, я вляется показателем жалкого состоя н и я безопас ности в И нтернете в целом . Обычно пакеты програм м ного обеспече н и я зависят от сторо н н и х б и бл иотек , которые мало ил и вообще не заботятся о достоверности заложен ного в них содержимого. В неко­ торых хран ил и щах програм м ного обеспече н и я нет криптографических подп исей вооб­ ще. Также часто можно встретить статьи , авторы которых активно поощря ют откл юче ­ н ие проверки. Ответствен н ы е системные адми н и страторы должны оче н ь подозрительно относиться к неизвестн ы м и ненадежн ы м ре позиториям программного обеспеч е н и я .

Отладка и устранение неполадок Конте й н е р ы п р и н осят с собой особе н н о отвратител ьное усложн е н и е и без того м утн ых методов отладки. Когда приложе н и е заключается в контейнер, с и м птом ы это­ го я вле ния становятся более сложн ы м и , а и х исходные причи н ы становятся более за­ гадочн ы м и . М ногие приложе н и я м о гут работать без измене н и й внутри конте й н ера, но в не котор ых с итуациях могут вести себя п о-другому. В ы также можете столк н уться с о ш и б ками внутр и самой систе м ы Docker. Этот раздел поможет вам ориентироваться в этих мутных водах. О ш ибки обычно проя вля ются в журнальных файлах, поэтому с н и х и н ужно начать поиск проблем ы . Испол ьзуйте рекомендаци и из раздела » Веде н ие журнал а » , чтобы на­ строить ведение журнала для конте й н еров и все гда просматри вайте жур н ал ы при воз­ н икнове н и и пробл е м . Если у вас возникл и пробл е м ы с запуще н н ы м конте й н ером , что­ бы открыть его интерактивную оболоч ку, попробуйте выпол н ить команду # docker ехес — ti имя_ кон тейнер а bash

В это й оболоч ке вы можете попытаться вос произвести пробл е м у, проверить файло­ вую с истему на наличие ош ибок и выявить проблемы в конфигураци и . Если вы в идите ошибки, связа н н ые с демоном doc:kerd, ил и если у вас возн и кл и пробл е м ы с его запус­ ком , выпол н ите поиск в списке проблем по адресу gi t h ub . corn/rnoby /rnoby . Вы може­ те найти других коллег, которые стол кнул ись с такой же проблемой , и , наверняка, оди н из н и х сможет предr1ожить потен циал ьное исправление ил и обходное реш е н и е . Система Docker не стирает образы ил и контейнеры автоматически. Если пренебречь эти м обстоятельством, такие остатки могут занять чрезмерный объем дискового простран ­ ства. Есл и рабочая нагрузка ваш е го контейнера предсказуе ма, настройте задание c:ron дr1я удаления ненужного материала, выпол н и в в нем команды doc:ker sys tem prune и doc:ker image prune.

Глава 25. Контейнеры

949

С этой же п роблемой с вязана е щ е одна досадная особе н ность — » заброш е н н ы е » том а , н екогда п р и кр е пл е н н ые к ко нте й н е ру, которы й б ы л удал е н . Тома н е зависят от конте й неров, поэтому л юбые файл ы внутри них будут продолжать зан имать дисковое пространство до тех пор, пока эти тома не будут ун ичтоже н ы . Для удал е н ия потеря н н ы х томов можно испол ьзовать следующие команды. # docker volume ls -f danqling=true # Получа ем списо к з а брошенных томов # docker volume rm $ ( docker volume ls qf danqling=true ) # Уда ляем их —

Базовые образы , от которых зависят созда н н ы е вам и образы , могут и м еть и н струк­ цию VOLUМE в с воем файле Dockerfile. Есл и вы не обратите на это в н и ман ие, то мо­ жете пол уч ить перепол н е н и е диска после запуска нескол ьких контей н еров и з этого образа. Для того чтобы вывести список томов, связан н ы х с конте й н ером , выпол н ите команду docker inspect: # docker inspect — f ‘ { { . Volumes } } ‘ имя_ кон т ейнера

2 5 .4. СОЗДАНИЕ И УПРАВЛЕНИЕ КОНТЕЙНЕРНЫМИ КЛАСТЕРАМИ Одн и м из величайших достижен и й контейнеризации я вляется перспектива совмест­ ного размещения м ногих приложен и й на одном и том же хосте. Это позволяет избежать взаимозависимостей и конфл и ктов и тем сам ы м обеспечить более эффекти вное ис пол ь­ зование серверов. Это привлекател ьная перспектива, но демон Docker отвечает тол ько за отдельные контей неры , а не за более ш ироки й вопрос о том , как запускать м ножество конте й неров на распределе н н ых хостах в конфигурации с высокой доступностью. Все инструменты управл е н ия конфи гурацией , та кие как Chef, Puppet , AnsiЫe и Salt , поддержи вают с исте м у Docker. О н и могут гара нти ровать, что на хостах запускаются определе н н ые наборы контейнеров с объя вл е н н ы м и конфигурация м и . О н и также под­ держивают создание образов, интерфейс ы реестра , управление сетью и томами , а также другие задач и , с вяза н н ы е с конте йнерам и . Эти инструме нты це нтрал изуют и стандар­ тизуют конфигурацию контей н еров , но н е решают проблему развертывания м ножества конте й н еров в сети серверов. ( Обратите внимание на то, что , хотя с исте м ы управл е н и я конфи гура ц и е й п олезны для разл и ч н ы х задач , связа н н ы х с конте й н ером , в а м редко придется использовать управление конфи гурацией внутри конте йнеров. ) Для разверт ы вания контей неров в масштабах все й сети вам н еобходимо програ м м ­ н о е обеспечен и е для совместной работы конте й н еров, также известное как планирование контейнеров или программное обеспечение для управления контейнерами. Для обработки бол ьшого количества контейнеров доступно м н ожество открытого и ком м ерческого и н ­ струментария . Такие и н струменты и ме ют решающее значен ие для запуска контей неров в производствен ном масштабе. Чтобы понять, как работают эти с исте м ы , подумайте о серверах в сети как о ферме вычисл ител ь н ы х мощносте й . Кажды й хост фер м ы предлагает план ировщик для про­ цессора, памяти , д и с ко в и сете в ы х ресурсо в . Когда пла н иров щ и к получает зап рос на запус к конте й н ера ( ил и набора конте й н еров) , он п о м е щает конте й н е р н а хост, у которого есть достаточ н ы е запас н ые ресурсы для удовлетворе н ия потребносте й кон ­ те й н ера. П ос кол ьку план иров щ и к зн ает, где был и разм е щ е н ы ко нте й н е р ы , он также может помочь в марш рутиза ц и и сете в ы х запросов на п равил ь н ы е хосты в кластере . Адм и н истраторы взаимодействуют с системой управл е н и я конте й н е рам и , а не с ка­ ким-л ибо отдел ьн ы м механ измом конте й н ера . Эта архите ктура показана на рис. 2 5 . 4 .

Часть lV. Эксплуатация

950

Агент

Контейнер

Планировщик контейнера

Механизм контейнеров

Контейнер

Управление

Узлы

Контейнер Контейнер

Сетка маршрутизации

Административное управление

Входящий запрос

Рис. 25.4. Типичная архитектура пла11ировщика ко11тей11еров

Систе м ы управления контейнера м и предоставля ют несколько полезных фун кци й . •

Ал горит м ы пла н и рования выбирают луч ш и й хост в с вете запро ш е н н ы х ресурсов задан и я и испол ьзован ия кластера. Например, задание с высоки м и требова н и я м и к пропускной с пособности сети может быть размещено на хосте с сете в ы м и нтер­ фейсом 1 0 Гбит/с. Формал ьн ые и нтерфе йсы A P I позволя ют програ м м а м отправлять зада н и я в кла­ стер, откры вая возможности для и нтеграци и с вне ш н и м и и нструм ентами . Это по­ зволяет л егко испол ьзовать с исте м ы управления контейнера м и в сочета н и и с с и ­ сте м а м и C l/C D для упроще н и я развертыва н и я програм м ного обеспечен и я . Размещение конте й неров может удовлетворить потребности конфигураций с в ы ­ с о к о й досту п н остью. Н а п р и м е р , может потребоваться запустить п р иложе н и е на узлах кластера , рас положе нного в нескол ьких разных географических регионах. В с истему встроен мониторинг работоспособности . Система м ожет пре кратить ра­ боту и перен ести н е исправн ые рабоч и е м еста, а также перенаправить зада н и я из неисправных узлов кластера. Существует возможность ле гко добавлять или удалять выч исл ител ьную е м кость. Есл и ва ш а в ы ч исл ител ьная ф е р м а не рас пола гает достаточ н ы м и ресурса м и дл я удовлетворен и я с п роса, в ы м ожете просто добавить другой узел . Эта возмож­ н ость особен н о хорошо подходит для облач н ы х сред. С исте м а управл е н и я конте й нером м ожет взаи м одействовать с балансировщи ком нагрузки для м арш рутизации сетевого трафи ка от вне ш н их кл и ентов. Это сред­ ство устраняет слож н ы й адм и н истрат и в н ы й процесс руч ной настройки доступа к сети в конте й н еризованных приложе н иях.

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

глава 25. контейнеры

951

Краткий обзор п рограммного обеспечения для уп ра вления контейнерами Н есмотря на с вою относ ител ьную молодость, и нструменты упраме н ия контей н е ра­ м и , которые м ы обсуждаем н иже , я вляются зрел ы м и и могут считаться промышле н н ы ­ м и . Фактически м ногие из них уже испол ьзуются н а производстве в крупномасштабных технологических ком паниях. Бол ь ш инство из н их представляют собой программ ное обеспече н ие с открытым ис­ ходн ы м кодом и и м е ют знач ительн ые сообщества пол ьзовател е й . Основываясь на по­ следних тенден циях, м ы ожидаем существен ного развития в этой области в ближай ш ие годы. В следующих разделах мы расскажем о функциональных возможностях и особен ­ ностях наиболее ш и роко используе м ы х систе м . М ы также упомя н е м их точ ки интегра­ ции и типичн ые сценарии ис пол ьзования.

Ku bernetes Назва н и е Kubernetes и н о гда сокращается до » k8s» , потому что между первой бук­ вой k и послед н е й буквой s стоят восе м ь букв. Так н азы вается п рое кт, котор ы й стал л идером в области управления контей нерами . Он разработан ком п а н и е й Google и б ыл запуще н частью из тех же разработч и ков, которые работал и над прое ктом Borg , менед­ жером внутре н н е го кластера Google . Kubernetes был выпущен в качестве проекта с от­ крытым исход н ы м кодом в 20 1 4 г. и те перь и м еет более тыся ч и акти вн ых участн и ков. Он имеет бол ь ш и нство фун кциональных возможносте й и сам ы й быстры й ц и кл разра­ ботки л юбой систе м ы , о которой мы знае м . Про грамм ное обеспече н ие Kubernetes состоит из нескол ьких отдел ьных служб, кото­ рые объединя ются для формировани я кластера. К е го ос нов н ы м строител ь н ы м блокам относятся следующие ком поненты . •

Сервер A P I для запросов оператора

Планировщик для размещения задач

Менеджер контроллеров для отслеживан ия состоя ния кластера

Kubelet — агент, который работает на всех узлах кластера

Служба cAdvisor для мон итори н га показателе й контей н еров

П рокс и -сервер для маршрутизац и и входя щих запросов в соответствующ и й ко н ­ тейнер

Для обес печ е н ия высокой доступности первые три эле м е нта в этом с писке выпол ­ ня ются н а нескол ьких главных серверах ( которые могут при необходимости выполн ять дво й н ы е обязан ности как узл ы кластера). П роцессы Kubelet и cAdvi sor зап ускаются на каждом узл е , обрабаты вают запросы от менеджера контроллеров и сообщают стат и ­ сти ку о состоя н и и своих задач . В Kubernetes конте й н еры размещаются в в иде модул я , содержаще го оди н и л и н е ­ скол ько контейнеров. В с е контейнеры в модуле обязательно размещаются на одном узле кластера. Каждому модул ю присваивается у н и кальн ы й 1 Р-адрес н а уровне кластера , и он пол учает метку для целей идентификации и размеще н и я . М одул и н е предназнач е н ы для дол говремен ного испол ьзования . Есл и узел прекра­ щает работу, контроллер план ирует перенос модуля на другой узел с новы м I Р-адресом. По этой прич ине нел ьзя использовать адрес модуля как дол говремен ное и м я .

952

Часть lV. Эксплуатация

Службы предстамяют собой коJUJекции связан ных модулей с адресом , который никог­ да не изменяется. Если модуль внутри службы прекращает существование или не проходит проверку работоспособности, служба удаляет этот модуль из ротации. Можно также исполь­ зовать встроенный DNS-cepвep для назначения службам распознаваемых имен. Систем а Kubernetes и нтегрировала поддержку дл я обнаружен и я служб , упрамения кл юча м и , развертывания и автоматического масштабирования модулей. Она и меет под­ кл ючае м ы е сетевые опции для поддержки оверл е й н ы х сетей контей н ера. Она может поддерживать приложен и я с фиксацией состоя ния путем переноса томов между узла­ ми кластера по мере необходимости . Ее инструмент командной строки под названием kubectl я м я ется одни м из самых и нтуитивно понятн ых, с которыми м ы когда-л ибо работал и . Короче говоря , он и меет набор гораздо более сложных фун кций , чем те , что мы включил и в этот коротки й раздел . Хотя систе ма Kubernetes обладает сам ым активным и деятельным сообществом и ос­ нащена сам ы м и передовы м и фун кци я м и , эти преимущества компенсируются крутой кривой обучен ия. Н едавние верс и и упростили процесс освоения для новичков, но пол­ ноцен ное , тон ко настрое н ное развертыван ие системы KuЬernetes — занятие не для роб­ ких. Разверты вание промышлен н ы х верс и й k8s с вязано с большой адм и н истративной и оперативной нагрузкой. Н а основе с истем ы Kubernetes реализована служба Google Container Engine — одна из самых удобн ых дл я команд, которые хотят использовать контейнерные рабоч ие на­ грузки без эксплуатационных издержек упрамения кластерами.

Mesos и Ma rathon M esos — проект совершенно другоrо рода. Он был задуман в Кал и форнийском ун и­ верситете в Беркл и около 2 0 0 9 г. как ун и версал ь н ы й менеджер кластера. О н быстро п робился в Twitter, где теперь работает на тысячах узлов. Сегодня M esos ямяется при­ оритетным проектом от орган изации Apache Foundation и может похвастаться большим количеством корпоративных пользователей. Основ н ы м и кон цептуал ьн ы м и объектам и в Mesos я вля ются мастера, агенты и кар­ касы . М астер — это посредн и к между агентами и каркасами . М астера ретрансл ируют предложе н и я с исте м н ых ресурсов от агентов к каркасам . Есл и у каркаса есть задача для выпол н е н и я , он выбирает предложение и отдает мастеру приказ выпол н ить задачу. Мастер отпрамяет дан н ые задачи агенту. Marathon — это каркас систе м ы M esos, которы й развертывает конте йнеры и управ­ ляет и м и . Он вкл ючает крас и в ы й пол ьзовател ьский интерфейс для управления прило­ жен и я м и и простой интерфейс R ESTful A P I . Чтобы запустить приложе н и е , вы п ишете определен ие запроса в формате J SON и отправляете ero в M arathon через A P I ил и пол ь­ зовател ьский и нтерфейс. П оскольку это внеш н и й каркас структур ы , его разверты ван и е я вляется гибким . Для удобства Marathon может работать на том ж е узле , что и мастер, или же запускаться извне . Поддержка нескол ьких сосуществующих каркасов — сам ый главн ый отличител ьн ы й признак систе м ы M esos. Apache Spark, и нструмент обработки больших дан н ых , и Apache Cassandra , база дан ных NoSQL, предлагают каркас ы Mesos, что позволяет использо ­ вать аге нты Mesos как узлы в кластере Spark или Cassandra. Каркас Chronos предназна­ чен дл я план ирования задани й , скорее, как версия cron, которая работает в кластере , а не а отдел ьной машине. Возможность запуска такоrо количества каркасов на одном и том же наборе узлов я мяется удобной функциональной возможностью и помогает вы­ работать еди н ы й и централ и зованн ы й опыт для адми н истраторов.

Глава 25. Контейнеры

953

В отличие о т с исте м ы Kubemetes, M esos не поставляется с готовым набором функ­ ций. Например, балансировка нагрузки и маршрутизация трафи ка я вля ются подклю­ чае м ы м и опция м и , которые зависят от вашего выбора. В ы можете выбрать и нструмент Marathon-lb, которы й реал изует эту услугу, или же испол ьзовать друто й . Например, м ы ус п е ш н о и с п ол ьзовал и и нструме нты Consul и HAProxy ком п а н и и HashiCorp . Проектирование и внедрение точного решения остается в качестве упражнения для ад­ министратора. Изучение систем Kubemetes и Mesos требуют определенных усили й . Для координа­ ции кластеров система M esos и большинство ее каркасов полагаются на службу Apache Zookeeper. Ею довольно сложно управл ять, к тому же стало известно о нескольких слож­ ных случаях сбоев. Кроме того, кластер Mesos с высокой доступностью требует м и н и мум трех узлов, что может быть обременительны м дл я некоторы х организаций .

М енеджер Docker Swarm Чтобы не отставать, разработчики платформ ы Docker п редложили Swarm , менеджер контей нерного кластера, встроен н ы й непосредствен н о в систему Docker. Н ы нешняя реал изация менеджера Swarm появилась в 20 1 6 г. как ответ на растушую популярность Mesos, Kubemetes и других кластерн ых менеджеров, в которых испол ьзовались контейне­ ры Docker. Оркестровка контейнеров теперь я вляется основны м приоритетом компании Docker, lnc. Запустить с истему Swarm легче, чем Mesos или Kubemetes. Л юбой узел кластера, на котором запущена система Docker, может присоедин иться к системе Swarm как рабочи й узел, и любой рабочи й узел также может быть менеджером. Н ет необходимости запускать отдельные узлы в качестве мастеров.7 Для запуска системы Swarm достаточно выпол нить простую команды docker swarm ini t. Нет допол нительных процессов для управления и настройки, и нет состояния для отслеживания. Все работает прямо из коробки. Для запуска служб в системе Swarm можно использовать знакомые команды docker (как в с истеме Kubemetes для работы с коллекциям и контейнеров). Вы объявляете состо­ яние, которое хотите достичь ( например, » мое веб-приложен ие должно быть запущено на трех контейнерах»), а система Swarm планирует выполнение задач в кластере. Она автома­ тически обрабатывает состояния отказа и в ыполняет обновление без простоя. У систе м ы Swarm есть встроенный балансировщик нагрузки , которы й автоматически настраивается при добавлении ил и удалении контейнеров. Платформа балансировки Swarm не такая полнофункциональная , как инструменты NGI N X или HAProxy, но, с другой стороны, она не требует н и какого внимания со стороны с исте мных администраторов. По умолчан и ю с истема Swarm обеспечи вает безопасность систе м ы Docker. Все со­ единения между узлами в с истеме Swarm зашифрованы по протоколу TLS, и со сторон ы адми н истратора н и какой настройки н е требуется. Это бол ьш ое преимущество с исте м ы Swarm перед кон курентами .

Контейнерная служба AWS ЕС 2 И нфраструктура AWS п редлагает ECS , службу управл е н и я контей н ера м и , предна­ значен ную для экземпляров ЕС2 (естественных виртуальных серверов AWS) . В манере , напоми нающей многие службы Amazon, и нфраструктура AWS с начала выпустила служ’Строго говоря , это верно и для систе м ы KuЬernetes и Mesos, н о мы обнаружили , что обьlчной практи кой в конфи гурациях с высокой доступ ностью является отделение мастеров от агентов.

Часть lV. Эксплуатация

9 54

бу ECS с м и н и мал ьной фун кционал ьностью, но со временем улуч ш ила ее. Служба ECS стала п ре крас н ы м выбором д;1я организаци й , которые уже вложили средства в инфра­ структуру AWS и хотят придерживаться режи ма E-Z. ECS — это » почти упрамяемая » служба. Ком поненты кластерного менеджера управ­ ля ются и н фраструктурой AWS . П ол ьзователи запускают экзе м пляры ЕС2, на которых установлены с исте ма Docker и а ге н т ECS . Агент подкл ючается к централ ьному API ECS и регистрирует доступн ост ь е го ресурсов. Ч тобы вы пол н ить задачу в вашем кластере ECS , отправьте определение задаLI И в формате J SON через A P I . Затем ECS назначит за­ дачу на одном из ваш и х узлов кластера. П оскол ьку служба я вл яется » почти управляемой » , порог д;1я входа н изкий . Вы мо­ жете начать работу с ECS все го за нескол ько м и н ут. Служба хорошо масштабируется по м е н ьш е й мере до сотен узлов и тысяч одновременных задач . Служба EC S взаимодействует с другим и службами AWS . Например, балансировка на­ грузки м ежду нескол ьк и м и задача м и вместе с обнаружением необходимых служб обра­ батывается службой Application Load Balancer. Вы можете добавить ресурс в свой кластер ECS , вос пол ьзовавшись автоматическим масштабированием службы ЕС2. Она также и нте гри рована со службам и l d ent i t y и Access Manager и нфраструктуры AWS, что поз­ воляет п редоставлять разре ш е н ия д;1я задач вашего контейнера с цел ью взаимодействия с другими службам и . Одной из наиболее проработа н н ы х частей E C S я вляется встрое н н ы й реестр образов Docker. Вы можете загружать образы Docker в реестр Е С2 Container Registry, где он и хра­ н ятся и становятся доступн ы м и л юбому клиенту Docker, независимо от того, работает он со службой ECS ил и нет. Есл и вы испол ьзуете контейнеры в и нфраструктуре AWS , ис­ п ользуйте реестр контей неров в той же области , что и ваш и экземпляры. Так вы достиг­ нете ropa3110 большей надежности и производительности , чем с л юбым другим реестром . П ол ьзовател ьс к и й и нтерфе йс ECS , хотя и функционал ьн ы й , но ему присущи огра­ ничения других и нтерфе й сов AWS. И н струмент AWS C L I имеет пол н ую поддержку API ECS. Для управл е н и я п р иложен ия м и в службе ECS м ы рекомендуе м обратиться к сто­ ронн и м инструментам с открыты м исходным кодом , таки м как Empire (g i t h ub . c o m / remind l O l / emp i re ) ил и Convox ( convox . c om).

2 5 . 5 . Л ИТЕРАТУРА •

• •

DocкER, I N c . Ojficial Docker Documentation. do c s . do c ke r . com. Платформа Docker и меет хорошую документацию. Она я вляется исчерпывающей и, как правило, ак­ туальной.

S F. д N КА N Е . Docker Up & Running. Sebastopol , СА: O ‘ Reilly Media, 20 1 5. В этой книге основное внимание уделяется испол ьзовани ю конте й ­ неров Docker в производствен ных средах.

М лтт н 1 л s , КлR t . , дND

М о uлт , A D R I A N . Using Docker: Developing and Deploying software with Con tainers. Sebastopol , СА: O ‘ Re i l ly Media, 20 1 6 . Эта кн и га охваты вает те м ы от базового до продвинутого и вкл ючает в себя м ножество примеров. TLJ RN B U L L , J лм Е s .

The Docker Book. www . doc ke rboo k . сот.

Блоr Container Solutions на сайте con t a i n e r — s o l u t i o n s . com / Ь l o g содержит тех­ н ические советы , рекомендаци и и интервью с экспертами по контей нерам .

Глава

26

Непрерывная интеграция и доставка

Еще nримерно десять лет назад об новлен и е nрограмм ного обеспечения было труд­ н ы м и дол гим делом. В nроцессе выnус ка обычно исnол ьзовались сnециальн ы е , кустар­ н ые сценарии, которые вызывались в загадочном nорядке и соnровождались устаревшей и н еn ол ной документацией . Тестирован и е — есл и оно вообще существовало — вы­ nол н ялос ь груn nой контроля качества, которая была дал е ка от цикла разработки и ча­ сто ста новилась серьезн ым n ре nятствием для nоставки кода конечному nотребител ю. Адм и нистраторы , разработчики и руководител и nроектов были вынужде н ы nлан ировать м ительные nроцедуры на nоследних этаnах выnуска обновлений для те кущих nол ьзова­ телей. Перебои в обслуживан и и часто nланировались за нескол ько недель. Уч иты вая этот сом нител ьн ы й конте кст, неуди вител ьно, что некоторые оче н ь ум ные л юди усердно работал и над улуч ш е н ием ситуаци и . В конце концов там , где одн и видят только nроблем ы , другие видят возможность. Одн и м из наиболее мудрых сnециал истов в этой области я вляется Мартин Фаулер ( M artin Fowler) , оракул индустри и nрограмм ного обес nече ния и главн ый науч н ы й со­ трудн и к вл иятел ьной консалти н говой ком nании ThoughtW:>rks. В nрони цательной статье ( g o o . g l / Y 2 l i s I ) Фаулер оnисывает н еnрерывную и нтеграци ю (Continuous I ntegration) как » n рактику разработки nрограмм ного обесnече н и я , в которой чле н ы команды часто интегрируют свою работу» , тем самым устраняя одну из главных nроблем в работе nро­ грам м н оrо обес nече н и я : утом ител ьную задачу согласован ия фрагментов кода , которые отдалил ись друг от друга в течение длител ьного nериода независи мой разработки. В на-

956

Часть lV. Эксплvатация

стоящее время практи ка непрерывной и нтеграции стала обще принятой среди разработ­ ч и ков программного обеспечения. Верши ной достижений в рамках этого подхода стала непрерывная доставка (Continuous Delivery) , которая похожа на кон цепцию непрерывной и нтеграции, но направлена на до­ стижение другой цел и : надежное развертыван ие обновленного программного обеспечен ия в уже фун кционирующих с истемах. Непрерывная доставка подразумевает небольшие из­ менения в информацион ной и нфраструктуре. Если что-то выходит из строя (т.е. появля­ ется регресс) , этот подход позволяет легко изол ировать и решить проблему, потому что изменен ия между версиями мал ы . В крайних случаях некоторые орган изации стремятся разворачи вать новый код для пользователей нескол ько раз в ден ь. О шибки и насущные проблемы безопасности можно решить в течение часов, а не дней или недель. Сочетан ие концепций непрерывной интеграции и непрерывной доставки (далее обо­ значается как C I/CD) охваты вает и н струменты и процессы , необходимые для облегче­ ния частого , постепенного обновлен ия п рограм много обеспечения и конфигурации . W Дополнител ьную и нформацию о методологии DevOps см. в разделе 3 1 . 1 . Кон цепция C l /C D является основой методологии DevOps. Это подход, объединяю­ щий как специалистов, которые занимаются разработкой, так и специалистов, которые осуществл я ют экс плуатацию п рогра м м ного обеспеч е н и я . Это такой же бизнес-акт и в , к а к и техн ические и нноваци и . П осл е внедрен ия концепция C l / C D становится основой и нформацион ной политики организаци и , поскольку она определяет логику и структуру процессов выпуска , которые ранее был и хаотич н ы м и . С исте м н ы е адм и н истраторы зан имают централ ьное место в разработке , внедре н и и и постоян ном обслуживан и и с истем C l/CD. Адми нистраторы устанавл ивают, н астраи ­ ва ют и управляют инструментами , которые выполняют функцию C l/CD. Они н есут от­ ветственность за то, чтобы п роцессы сборки программ ного обеспечен ия были быстрыми и надежн ы м и . Тестирование является важным элементом C l/C D. Администраторы н е могут писать те­ сты (хотя иногда они это делают!) , но они несут ответственность за настройку и нфраструк­ туры и систе м , на которых выпол няются тесты. Возможно, самое главное , что именно си­ стемные адми нистраторы отвечают за развертывание, т.е. компонент доставки C l/CD . Эффе кти вн ая систе ма C I/CD реал изуется не с помощью оди ноч ного и нструм е н ­ та, а н а основе ком плексного п рограммного обеспече н и я , которое работает в ун исон , форм ируя связанную среду. Существуют разнообразные средства с открытым исходн ы м кодом и коммерческие и нструменты для координаци и разл и ч н ых элементов C l/C D . Эти и нструме нты координации полагаются н а другие пакеты программ ного обеспеч е ­ ния для выпол н е н ия фактической работы (например, ком п иля ция кода или настрой ка серверов в определен ной конфи гурации). Действительно, существует так много вариан ­ тов, что первоначал ьное знакомство с концепцией C l/CD может быть ошеломл я ющ и м . Кром е всего прочего, н едавнее широкое распростран е н ие разнообразн ых инструментов в этой области свидетельствует о растущем значен и и C I/C D для отрасли . В этой главе м ы попытаемся сориентироваться в лабиринте концепц и й , терминоло­ гии и инструментов C I/CD . М ы освещаем основы кон вейера C I/C D , разл и ч н ые типы тестирования и их релевантность кон цепции C l/C D , практику параллел ьной работы не­ с кольких сред и некоторые из наиболее популярных и нструментов с открытым исход­ н ым кодом . В конце главы мы рассмотри м пример кон вейера C l/C D , в котором исполь­ зуются н е которые из самых популярных и нструме нтов. П рочитав эту главу, вы начнете понимать принципы и методы, на которых основана мощная и гибкая система C I/C D.

Глава 26. Непрерывная интеграция и доставка

957

26. 1 . ОСНОВНЫЕ КОНЦЕПЦИИ М ногие тер ми н ы , относящиеся к C l/C D , звучат оди наково и и ме ют перекрывающи­ еся значения. Итак, давайте сначала рассмотри м различия между непрерывной и нтегра­ цией , доставкой и развертыванием. •

Непрерывная интеграция (continuous integration CI) — это п роцесс совместной работы с общей кодовой базой , сли я н ие разрозненных изменени й кода в систему контроля верси й и автоматическое создание и тестирование сборок. —

Непрерывная доставка (continuous delivery СО) — это процесс автоматического разверты вани я сборок в н епроизводствен ных средах после завершения процесса непрерывной интеграции. —

Непрерывное развертывание (continuous deployment) завершает цикл путем развер­ тывания в функцион ирующих системах, которые обсл уживают реальных пользо­ вателей без какого-либо вмешательства оператора.

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

П рин ци п ы и п рактика Гибкость би з н ес а я вл я ется одн и м и з кл ючевых п р е имуществ подхода C I/ C D . Непрерывное развертывание облегчает выпус к проверен ных фун кций на производстве в течен ие нескольких м и нут или часов вместо недел ь или месяцев. П оскол ьку каждое изм е н е н ие собирается, тестируется и развертывается немедлен но , разница м ежду вер­ сиям и становится намного меньше. Это с нижает риск развертывания и помогает сузить круг причин возможных н еполадок. В место того чтобы орган изов ывать н ебольшое ко­ личество развертывани й в год после внесения бол ьшого количества и зм е н ен и й , вы мо­ жете выпус кать новый код несколько раз в неделю или даже в день. Подход Cl/CD стимулирует выпускать новый фун кционал больше и чаще . Эта цель достижима только тогда, когда разработчики пишут, отлаживают и фиксируют в общем хранил и ще небольшие фрагменты кода. Чтобы реализовать непрерывную и нтеграцию, разработч и ка м необходимо проводить фиксацию изменен и й кода н е реже одного раза в ден ь после проведения локал ьных тестов. Для систе м н ых адми нистраторов процессы CI/CD значител ьно сокращают вре м я , затрачи ваемое на подготовку и реализац и ю выпусков. О н и также сокращают время от­ ладки , если при развертывани и возни кают неизбежн ые проблемы. Нем ного на свете бо­ лее приятны х занятий , чем набл юдение за выпус ком новой функции на производстве без вмешательства человека. В следующих разделах описа н ы н екоторые основные пра­ вила, которые следует учитывать при разработке процессов CI/CD.

958

Часть lV. Эксплvатация

Использовать ко нтроль версий Вес ь код следует отслеживать в с исте ме контроля версий. Мы рекомендуем с исте му G it , но есть много вариантов. Само собой разумеется, что большинство команд разра­ ботчи ков программного обеспечен и я испол ьзуют систему контроля версий. В орган изациях, которые приняли на вооружен и е кон цепцию и нфраструктуры как кода ( с м . раздел » Подход C l/C D на практике » ) , вы можете отслеживать и н фраструк­ турный код вместе с ваши м и приложениями. Вы даже можете хранить документы и на­ стройки конфигурации в системе контроля версий. Убедитесь, что контроль версий является еди нстве н н ы м источн иком исти н ы . Ничто не должно управляться вручную или без фиксации записи.

Собирайт е оди н раз, развертывайте часто Кон вейер C I/C D нач и н ается со сборки. С этого моме нта резул ьтат сборки («арте­ факт») испол ьзуется для тестирован и я и развертыван ия. Еди нствен н ы й способ подтвер­ дить, что кон кретная сборка готова к производству, — п ропустить дан ную сборку через все тесты. Разверн ите оди н и тот же артефакт по крайней м ере в одной или двух средах, которые как можно луч ше соответствуют целевой производственной платформе.

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

Собирайте каждую фиксаци ю в процессе интеграции И нтеграция объединяет изменения , сделанные нескол ьким и разработчиками ил и ко­ мандами разработчиков. П родукт представляет собой составную кодовую базу, которая включает в себя все обновления. И нтеграция не должна случай н ы м образом преры вать работу разработч и ков и заставлять их помещать фрагме нты кода в основную кодовую базу; это вер н ы й путь к катастрофе . Отдел ьные разработчики несут ответствен н ость за управление собствен н ы м потоком разработки. Когда они будут готовы , он и должны на­ чать процесс и нтеграци и . И нтеграции должны происходить как можно чаще. И нтеграции выпол н я ются через с истему контроля верс и й исходного кода. Рабоч и й процесс может быть разн ы м . Ответствен ность з а сли я н ие своей работы с основной веткой проекта (t ru nk ) могут нести отдельные разработчи к и , ил и же назнач е н н ы й на­ блюдател ь за выпусками может одновременно инте гри ровать работу сразу нескол ьких разработчиков или команд. П роцесс слияния может быть в значительной сте п е н и авто­ матизирова н , но все гда существует возможность конфл и кта между двумя наборами из­ мене н и й . Такая ситуация требует вмешател ьства человека. Идея непрерывной инте грации заключается в том , что л юбая фиксация в и нтеграци­ онной ветке с исте м ы контроля версий должна автоматически запус кать процесс сборки . » И нтеграционная ветка» важна, потому что контроль версий исходного кода служит н е ­ с кольким целям. П о м и м о того, что он является средством сотрудничества и интеграции, он также полезен как с истема резервного копировани я , как контрольная точка для неза­ вершенного производства и как с истема, которая позволяет разработчи кам работать с не­ скол ькими обновл е н ия м и , сохраняя при этом изменения, с вязан ные с этим и обновле­ ниями , логически раздельн ыми. Таким образом, тол ько фиксация резул ьтата и нтеграци и должна приводить к запуску процесса сборки.

Глава 26. Непрерывная интеграция и доставка

959

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

Разд еляйте ответственност ь Есл и что-то пойдет не так, кон вейер необходимо исправить. Н икакой новы й код н е может быть внедрен до тех пор, пока предыдущая проблема не будет решена. Это экви­ валентно остановке сбороч ной л и н и и на производстве . Вся команда обязана исправить сборку, п режде чем возобновить работу по разработке . Подход C I/C D не должен быть таи нствен ной системой , которая работает в фоновом режиме и и ногда отправляет электронную почту, если что-то идет не так, как ожидалось. Кажд ы й чле н команды должен и меть доступ к и н терфейсу CI/CD для п рос мотра па­ нелей монитор и н га и журналов. В некоторых орга н изациях создаются юмористические виджет ы , такие как светильн ики RG B, которые служат визуальным и ндикатором теку­ щего состоя н и я конвейера.

Собира йте быстро, исправляйте быстро П одход C I/C D предназначен для обеспечения как можно более б ыстрой обратной связи , в идеале в теч е н и е нескол ьких м инут после фиксации кода в с истеме контроля верси й исходного кода. Этот быстр ы й откли к гара н ти руе т что разработч и к и обратят внимание на результат. Есл и сборка заверш ится неудаче й , разработчики, скорее всего , смогут быстро решить проблему, потому что изменения , которые они только что внесл и , еще с вежи в и х памяти . Медлен н ы е процессы сборки контрпродукт и в н ы . Стрем итес ь устранять лишние и трудоем кие этапы. Убедитесь, что ваша с истема сборки и меет доста­ точно агентов и что агенты имеют достаточн ы е систе м н ые ресурсы для быстрой сборки. ,

Аудит и проверка Часть систе м ы Cl/CD вкл ючает подробную истори ю каждого в ы пус ка п ро гра м м н ого обеспече н и я , вкл ючая его переход от разработки к производству. Эта возможность от­ слежива н и я может быть полезна для обеспече ния ра з в е рты в а н и я тол ько авторизова н ­ н ы х сборок. П араметры и временные рамки событий , свя за н н ые с каждой средой, могут быть неопровержимо подтвержден ы .

Сред ы П р иложе н ия не работают изолированно. О н и зависят от внеш н и х ресурсов, таких как базы данн ых, прокси-серверы, сетевые файловые систе м ы , зап и с и D N S , удаленные интерфейсы НТТР АР!, другие приложения и внешние сетевые службы . Среда выполне­ ния включает все эти ресурсы и все остальное , что необходимо для п риложен и я , чтобы оно м огло работать. Создание и поддержание такой среды является объектом значитель­ ного административного внимания. Бол ь ш и н ство орга н и заций работают как м и н имум в трех средах, перечисл е н н ы х здесь в порядке возраста н ия важности. •

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

960

Часть IV. Эксплуатация

нами или конечн ы м и пользователя м и . В контексте C l/C D среда разработки может создаваться и разрушаться несколько раз в день. •

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

Типичная система C l/C D последовательно продвигает програм м ное обеспечен ие че­ рез каждую из этих сред, отфильтровывая ошибки и дефекты программного обеспечения на этом пути. Вы можете с увере нностью развернуть приложение в производствен ной сре­ де, потому что знаете, что изменения уже были протестированы в двух других средах. Паритет сред я вляется предметом некоторой сложности дr1я системных админ истрато­ ров. Цель непроизводствен ных, ил и » н ижних » . сред заключается в подготовке и анал изе изменений всех типов до перехода на стадию производства. Существенные различия меж­ ду средами могут привести к непредвиден ной несовместимости , которая в конечном итоге может вызвать ухудшение производительности, простои или даже разрушение дан ных. Например, представьте , что среда разработки и промежуточ ного тестирования под­ верглась обновл е н и ю операционной с исте м ы , но в производстве н ной среде все еще работает ее более старая верс и я . П ришло врем я для развертывания п рограм м ного обе­ спечен и я . Н овое программное обеспечение тщательно проверено на стадиях разработки и тестирования и, похоже, работает нормально. Однако во время развертыван ия в про­ изводствен ной среде становится очевидной неожидан ная несовместимость, поскол ьку в старой версии определен ной библ иоте ки отсутствует фун кционал ьная возможность, испол ьзуемая в новом коде. Этот сценарий довольно распростране н , и это одна из прич и н , по которой систе м ­ н ы е адми н и страторы должны проя влять бдител ьность в отноше н и и с и нхронизации сред. Ч е м бл иже производственная среда к среде более н изкого уровн я , тем выше ваш и шансы на поддержан ие высокой доступности и доставки программ ного обеспече н и я . Запуск нескольких сред на полную мощность может быть дорогостоящим и трудоем ­ ким . Поскольку производствен ная среда обслуживает гораздо бол ьше пользователей, чем среды более н изкого уровня, в этой среде обычно необходимо запускать больше дорогих систем. Наборы данных на производстве , как правило, крупнее , поэтому выделенное под него дисковое пространство и мощности сервера пропорционально увеличиваются. Даже такой тип различий между средам и может вызвать непредвиденные проблемы. Н еправил ьная конфигурация балансировки нагрузки , которая не имеет значе ния в сре­ дах разработки и тестирования, может выявить дефект. Ил и запрос базы дан н ых, кото­ рый быстро запус кается в средах разработки и тестирования, может оказаться намного медленнее при применен и и к данн ы м производстве н ного масштаба. Совместимость производствен ных мощностей в средах более низкого уровня — сложная проблема. Стремитесь иметь хотя бы одну среду более низкого уровня, у которой есть избы­ точность там же, где она есть в производственной среде (например, несколько неб-серверов,

Глава 26. Непрерывная интеграция и доставка

961

полностью реruшцированные базы данных и соответствующие стратегии перехода на другой ресурс в случае отказа Дll Я л юбых кластерных систем). Это нормально Дll Я промежуточных серверов меньшего размера, хотя любые тесты, которые вы запускаете Д/IЯ проверки произ­ водительности, не будут отражать реальные производственные показатели. Для достижения наилучших результатов наборы дан н ых в средах более низкого уров­ ня должн ы быть схож и м и по размеру и содержанию с объемами дан н ы х в производ­ ствен ной среде . Одн а из стратегий — создавать по ночам снимки всех соответствующих производствен н ы х данн ых и копировать их в среду более н изкого уровн я . Для обес пече­ ния соблюдения и обеспечения наД11 е жащей ги гиен ы безопасности конфиден циальные пользовател ьские данные должны быть сделаны анон и м н ы м и до того , как они будут ис­ пол ьзован ы таким образом . Для действительно масс ивных наборов дан ных, которые не­ целесообразно копировать, и м портируйте меньш и й , но все еще знач и м ы й образец. Н есмотря на все ваш и усил ия , среда более н изкого уровня н и когда не будет похожа на п роизводстве н н ую среду. Н екоторые параметры конфи гурации (такие как учетн ые дан н ые, U RL-aдpeca, адреса и имена хостов) будут отличаться . Испол ьзуйте управление конфигурацией Дll Я отслеживания этих элементов конфигурации между средами. Когда система C l/CD запускает развертывание, проконсультируйтесь с ваш и м авторитетн ы м источн и ком, чтобы найти соответствующую конфигурацию Д/IЯ этой среды , и убедитесь, что все среды развернуты оди наково.

Флаги функци й Флаг функции включает ил и откл ючает функцию приложения в зависимости от зна­ ч е н и я параметра конфигураци и . Разработч ики могут создавать подде ржку фл агов фун кций в своем программном обеспечении. Вы можете испол ьзовать флаги функций Дll Я включен ия определ е н н ых фун кций в определенных средах. Например, вы можете вкл юч ить некоторую функцию в тестовой среде , оставив ее откл юченной в производствен ной среде до тех пор , пока она не будет пол ностью про­ тестирована и готова Дll Я широкого использования . В качестве при мера рассмотри м приложение Дll Я электрон ной торговл и с корзиной покупок. Руководство хочет запустить рекламную кампан ию, требующую внесе ния в код некоторых изменений. Команда разработчиков может создать эту фун кцию и внедрить ее авансом во все три среды, но включить ее только в средах разработки и тестирования. Когда руководство будет готово проводить рекламн ые акци и , Дll Я включения этой фун к­ ции нужно просто изменить параметры конфигурации с низки м уровнем риска, а не де­ лать выпуск новой версии програм м ного обеспечения. Есл и фун кция содержит ошибку, ее ле гко отключ ить без обновления программ ного обеспечения.

26.2. КОНВЕЙЕРЫ Кон вейер C l/C D представляет собой последовател ьность шагов, назы вае м ых этапа­ ми. Каждый этап — это по существу сценарий, котор ы й выполняет задач и , специфи ч ­ н ые для вашего програм м ного проекта. На базовом уровне кон вейер C l/C D выпол няет следующие функции. •

Надежная сборка и упаковка программ ного обеспечения.

Выполнение ряда автоматических тестов Дll Я поиска ошибок конфи гураци и .

Разверты ван ие кода в одной или нескольких средах, вкл ючая производствен ную.

962

Часть lV. Эксплvатация

На р и с . 26. показа н ы эта п ы п ростого ( н о впол н е зрел ого) кон в е й е ра C l / C D .

Фиксация

Плохая сборка

Плохая сборка СБОЙ

СБОЙ Сборка

Плохая сборка

Развертывание на стадии разработки

Тесты

Тесты

Откат

СБОЙ Развертывание на стадии тестирования

Тесты

СБОЙ Развертывание на стадии производства

Текущие тесты

Зрелость Рис. 26. 1. Конвейер Cl/CD В сл едую щ и х разделах эти три этапа о п исан ы боле е подроб н о .

П роцесс сборки Сборка — это м о м е н тал ь н ы й с н и м о к текущего состоя н и я п рограм м н о го проекта.

Это , как п ра в ил о , первый этап л юбого кон в е й е ра C l /C D , возможно , после эта п а ана­

л и за кода , н а котором п р о исходит ко н трол и ро ва н и е качества кода и поиск у гроз без­ опас н ости . Этап сборки преобразует код в и н сталл ируе м у ю часть п р о гра м м н ого обес п е ­ ч е н и я . Сборка может быть и н и ц и ирована ф и кс а ц и е й в ветке и нте гра ц и и р е п озитор и я кода л ибо в ы пол н ятьс я по р е гул я р н о м у рас п исан и ю ил и по требова н и ю . Кажд ы й з а п ус к ко н ве й е ра н ач и н ается со сборк и , н о н е каждая сборка дос т и гает п р о и з водства . П осле того как п р о и зойдет тестирова н и е , сборка ста н е т » кандидато м на в ы п ус к » . Есл и кандидат на в ы п ус к факти ч е с к и разверты вается дл я работы в произ­ водстве н н ой среде , о н стано вится » вы пуском » . Есл и в ы в ы пол н яете н е п р е р ы вное раз­ верты ван и е , кажд ы й кандидат н а в ы пус к также я вл яется вы п ус ко м . Эти кате гор и и п ро­ и.1л юстр и рова н ы н а рис. 26. 2 .

Сборки

Каждый раз при изменении кода

Кандидаты на выпуск После прохождения всех тестов

Выпуски

Развертывание для производства

Рис. 26. 2. Сборки, кандидаты 11а выпуск и выпуски Точ н ое соде ржа н и е эта пов п роцесса сборки за висят от я з ы ка и п ро гра м м н о го обе­ с пе ч е н и я . Для п ро гра м м н а я з ы ках С , С + + ил и Go п роцесс сборки п редста вляет собой ком п ил я ц и ю , часто и н и ц и и ро ва н н у ю ко м а ндой make , которая п р и водит к и с п ол н я е ­ мому двоич н о м у коду. Д л я я з ы ко в , котор ы е н е требуют ком п ил я ц и и , так и х ка к Python ил �1 Ruby, эта п сбо р к и м ожет вкл ючать упаковку п рое кта со все м и соответству ю щ и м и за в и с и мостя м и и ресурса м и , в кл ю ч ая библ иоте к и , образ ы , шаблон ы и фа йл ы разметки . Н е которые сборки м огут в кл ю чать тол ько и зм е н е н ия кон ф и гура ц и и .

Глава 26. Непрерывная интеграция и доставка

963

Резул ьтатом этапа сборки я вл яется » артефакт сборки » . Характер этого артефак­ та зависит от програм м ного обеспечения и конфигурации остальной части конвейера. В табл. 26. 1 перечислены некоторые из распространенных типов артефактов. Независимо от формата, артефакт является основой для развертывания в остальной части кон вейера. Таблица 26 . 1 . Распространенные типы артефактов сборки Предназначение

Тмn

Файл j ar или .

.

war

Архив Java или архив веб-приложений Java

Статический двоичный файл

Статически скомпилированные программы, обычно на языках С или Go

Файл rpm или dеЬ

Пакеты про граммного обеспечения для операционных систем Red Hat или Deblan

.

.

Пакет pip или пакет qem Образ контейнера Образ машины Файл . ехе

Упакованные приложения Python или Ruby П риложения, выполняемые на платформе Docker Виртуальные серверы, особенно для открытых или закрытых облаков Исполняемый файл Windows

Артефакты сборки сохраня ются в хран ил и ще артефактов. Ти п ре позитория зави­ сит от типа артефакта. В с воем простейшем случае ре позитори й может быть каталогом на удал е н ном сервере , доступ н ы м через S FТ P или N FS . Это также может быть репо­ зиторий yum или А РТ, репозиторий образов Docker ил и хранилище объектов в облаке , такое как AWS SЗ. Репозиторий должен быть доступен для всех систе м , которые должны загружать и инсталлировать артефакт во время развертыван ия.

Тестирование Н а каждом этапе кон вейера C l/CD выполняются тесты, чтобы выявлять ош ибоч ный код и плохие сборки, чтобы код, который дошел до эта па производства, не имел дефек­ тов ( ил и по крайней мере был как можно более надежн ым). Основой этого процесса яв­ ляется тестирование. Это порождает доверие к тому, что выпус к готов к разверты ванию. Есл и сборка н е п роходит какой-л ибо тест, оставш иеся эта п ы кон вейера не и м е ют см ысла. Команда разработчи ков должна определить, почему сборка не удалас ь, и ре­ шить основную проблему. nоскольку сборки создаются для каждой фиксации кода, лег­ ко изолировать проблему до последне й фиксаци и . Чем меньше строк кода изменяется между сборками , тем легче изолировать проблему. Неудач и не все гда с вязаны с ошибками программного обес пече н и я . Они могут воз­ никать из-за проблем с сетью или ош ибок инфраструктуры , требующих адми н истратив­ ного вн и мания . Если приложение зависит от внеш них ресурсов , таких как сторонние API , сбои могут возникать во внешнем ресурсе . Одни тесты могут в ыпол няться изол и — . рованно, но для других тестов требуется та же и нфраструктура и дан н ые , которые будут присутствовать в производственной версии. Рассмотрите возможность добавления каждого из следующих типов тестов в кон вей ­ ер C l/C D. •

Анализ статического кода позволяет выя вить синтаксические ошибки , дублирова­ н ия , нарушен ия правил кодирования, проблемы с безопасностью или чрезмерной сложностью. Эти проверки выполняются быстро и не требуют выполнения факти­ ческого кода. Модульные тесты , написанн ые тем и же разработч иками , которые пишут код прило­ же ния, отражают представление разработч ика о том , как должен фун кционировать

964

Часть lV. Эксплуатация

код. Цел ь состоит в проверке ввода и вывода каждого метода и фун кции (модуля) в коде . » Покрытие кода» — это (иногда вводя щий в заблуждение) показатель, кото­ рый описывает, какая часть кода подвергается модульному тестирован ию. 1 Тесты интеграции — это м одульные тесты, которые выпол н я ются после запус ка приложен ия в его предполагаемой среде исполнения. Эти тесты запускают прило­ жен и е с его базовым и каркасам и и внеш н и м и зависи мостя м и , таким и как внеш­ ние A P I , базы дан ных, очереди и ке ш и .

Приемочные тесты отражают точ ку зрения пол ьзователя . Для веб-програ м м этот этап может включать дистан цион ное управление загрузкой страниц браузера с по­ мощью таких инструментов, как Selen ium . Для мобил ьного п рогра м м ного обе ­ спечения артефакт сборки может поступать на ферму устройств, которая запуска­ ет приложение на разных мобильн ых устройствах. Разл и ч н ы е браузеры и версии делают приемоч н ые испытан ия слож н ы м и для созда н ия , но в кон це кон цов эти тесты имеют знач имые резул ьтаты . Тесты производительности предназначены для поиска проблем производительно­ сти , связан ных с последни м кодом . Чтобы выявить узкие места, эти так называем ые стресс-тесты должны выпол н ить приложение в идеальном клоне вашей производ­ стве н ной среды с реал ьн ы м поведением трафика. Такие и нструменты, как J Meter или Gatling, могут моделировать тысячи одновременных пользователей, взаимодей­ ствующих с приложен ием в запрограмм ированном шаблоне . Чтобы пол уч ить мак­ симальную отдачу от тестирования производител ьности , убедитесь, что у вас уста­ новлены контрол ьн ые и графические средства. Эти и нструме нты проясняют как типичную производительность приложения, так и его поведение в новой сборке. Инфраструктурные тесты идут рука об руку с програ м м ной облач ной и н фра­ структурой . Если вы создаете временную облач ную и нфраструктуру как часть кон ­ вейера C I/C D , вы можете написать тестовые пр имеры, чтобы п роверить правил ь­ ную конфигурацию и работу самой и нфраструктур ы. Успешно л и работает система управления конфигурацией’? Выполняются ли тол ько ожидаем ые демон ы? Один из и нтересн ых инструментов в этой области — Serve rspec ( s e rv e r s pe c . o r g ) .

m Допол н ительную и н ф о р м а ц и ю о с и стемах м о н и то р и н га и граф и ч е с ких с и стемах см . в главе 28.

В зависимости от характеристик ваш его проекта некоторые тесты могут оказаться важ­ нее других. Например, программное обеспечение, которое реализует интерфейс REST API , не нуждается в приемочных тестах с применением браузера. Вместо этого вы, скорее всего, сосредоточитесь на тестах интеграции. С другой стороны, для программного обеспечения интернет-магазина обязател ьно требуется проверка в браузере всех важных пользователь­ ских маршрутов (каталог, страницы продукта, корзина, оформление заказа). Рассмотрите потребности своего проекта и соответствующим образом выполните тестирование. Рабочие процессы не обязател ьно должн ы быть линейными. На самом деле, поскольку одна из целей заключается в том , чтобы как можно быстрее получ ить обратную связь, ре­ комендуется проводить как можно больше тестов паралл ельно. Но имейте в виду, что одни тесты могут зависеть от резул ьтатов других тестов; некоторые могут потенциально мешать друг друrу. (В идеале тесты не должны иметь перекрестных зависимостей.) 1 Код, которы й трудно тестировать, скорее все го, и меет дефекты . У вашего кода может быть 8 5 % покрытия кода ( что довольно много по отраслевым стандартам ) , но есл и сам ый сложн ы й код не п ротестирован , ошибки могут быть пропуще н ы . Одно ли шь покрытие кода н е ямяется аде кватной мерой качества кода.

Глава 26. Непрерывная интеграция и доставка

965

Избегайте соблазна и гнорировать ил и недооце н и вать неудач ные тесты . И н огда воз­ никает привыч ка с н исходительно относиться к н е которым причинам сбоя , сч итая их безвред н ы м и или н е важн ы м и , и подавлять тест. Однако такой образ м ысле й опасен и может привести к менее надежной системе тестирован ия. И мейте в виду золотое пра­ вило C l/C D: исправлен ие неисправного кон вейера является главным приоритетом . Чтобы укрепить этот принцип , сделайте почти невозможн ым игнорирование неудач ­ ных тестов. Обязательно установите техн ическое требование с помощью програ м м но­ го обеспечения C l/CD: развертывание в производствен ной среде не может произойти , если есть какие-л ибо неудач ные тесты.

Развертыва ние Разверты ван ие — это процесс установки п рограм м ного обес печения и подготов­ ки его для использования в среде сервера. Спе цифика того, как это делается, зависит от набора технологий. Система разверты ван и я должна пони мать, как извлечь артефакт сборки ( например, из репозитория пакетов ил и реестра образов контей неров) , как уста­ новить е го на сервере и какие шаги настройки необход и м ы , есл и таковые и м е ются . Развертывание завершаетс я , когда новая версия програм м ного обеспечения запущена, а старая версия откл ючена. Развертывание может быть очень просты м , как , например, обновл е н ие некоторых файлов HTM L на диске . П ри этом не требуется перезагрузка сервера или е го дал ьней­ шая настройка! Однако для бол ьш инства случаев развертыван ие включает по крайней мере установку пакета и перезапуск приложе ния. Ком плексное развертывание крупно­ масштабного прил ожен и я в производстве н ной среде может вкл ючать в себя установку кода на нескол ьких серверах при одновременном обработке трафи ка в реальном време­ ни без приостановки обслуживания. Системные адм и н истраторы играют важную роль в процессе разверты вания. Обыч но они отвечают за создание сценариев разверты ва н и я , мон иторинг важ н ых инди каторов работоспособности приложе н и й во врем я развертывания и обес печ е н и е соответствия потребностей и нфраструктуры и конфигурации други м членам команды. В следующем с п ис ке оп исано нескол ько возможных способов разверты ван ия про­ грамм ного обеспечения. •

Запустите базовый сценарий оболочки, который вызывает программу s sh для вхо­ да в систему, загрузки и установки артефакта сборки , а затем перезапускает при­ ложение. Эти типы сценариев обычно разрабатываются самостоятельно и не вы­ ходят за рам ки небол ьшого количества систе м . Испол ьзуйте и нструмент управления конфигурацией для орган изации процесса и нсталляции с помощью управляемого набора систе м . Эта стратегия более орга­ низована и масштабируема, чем использование сценариев оболочки. Больши нство систем управления конфигурацией не предназначены специально для облегчения развертыван и я , хотя они могут испол ьзоваться для этой цел и . Если артефакт сборки представляет собой образ контей нера, и приложение запуска­ ется на платформе управления контей нером , такой как Kubernetes, Docker Swarm ил и AWS EC S , разверты вание может быть не бол ее чем быстры м вызовом A P I дл я диспетчера контейнеров. Служба контейнера самостоятельно управляет осталь­ ной частью процесса развертыван ия (см. раздел » Контейнеры и подХод Cl/CD»). Существует нескол ько проектов с открыты м исходны м кодом , которые позволяют стандартизировать и упростить разверты ван ие. Capistrano ( c ap i s t r a n o r b . c om) —

966

Часть lV. Экспл уатация

это инструмент развертывания на основе языка Ruby, который расш иряет систе му Rake Ruby для запуска команд на удал е н н ы х с истемах. Fabric ( f a Ь f i l e . o r g ) это аналоги ч н ы й и н струмент, написанн ы й на языке Python. Эти и нструменты , предназначе н н ые для разработч и ков, в основном служат для создания сценариев оболочки . —

Развертыван ие п рогра м много обес печ е н и я — это хорошо изуч е н ная проблема дл я поль:ювателей п убличных облаков. Большинство облачных экосистем включа­ ют в себя как инте грированные, так и сторонние службы развертывания, которые могут испол ьзоваться из кон вейера C l/C D, например Google Deployment Manager, AWS Code Deploy и Heroku .

Примените технологию развертывания к арсеналу технологий вашей организации с уче­ том ее потребностей. Если у вас простая среда с нескольки м и серверами и небольшое ко­ личество приложений, то может быть уместным использование инструмента управления конфигурацией . В организациях с бол ьшим количеством серверов, распределен н ых между центрами обработки данных, требуется специализированное средство развертывания. Тер м и н неизменяемое развертывание (immutaЫe deployment) означает п р и н ц и п , со­ гласно которому серверы н и когда не должн ы изменяться после их и н ициал изаци и . Чтобы развернуть новую верс и ю , инструментари й C l /C D создает совершенно новые серверы с обновлен н ы м артефактом сборки , включе н н ы м в образ. В этой модели сер­ веры считаются одноразовым и и времен н ы м и . Эта стратегия ос нована на программиру­ емой и нфраструктуре , такой как открытое ил и закрытое облако, где экзе м пляры могут быть распредел е н ы через вызов и нтерфейса A P I . Некоторые из круп н е й ш их пользовате­ лей открытого облака применяют неизменяемые варианты развертывания. В разделе » Подход C l/C D на практи ке » м ы расс мотр и м пр и м е р неизменяе мого развертыван ия , в котором используется и нструмент Terraform от компании HashiCorp для создания и обновления и нфраструктуры .

Методы развертыва н ия с нулевым временем п ростоя В некоторых организациях службы должн ы продолжать работать даже во вре мя их об­ новления или повторноrо развертывания либо потому, что из-за сбоя возн икает неприем­ лемый риск (в области здравоохранения или государственных услуг) или это может при­ вести к знач ительн ым финансовым затратам ( в области крупной эле ктрон ной торговли или финансовых услуг). Обновление программного обеспечения в реальном времени без прерывания обслуживан ия — это высший пилотаж в сфере развертывания программ ного обеспечения и одновременно источник большого беспокойства и трудностей. Одн и м и з расп ростране н н ых с пособов достижен ия выпуска с н ул е в ы м вре м е н е м п ростоя я вляется » си не-зеленое » развертыван и е . Кон цепция проста: запустите новое программ ное обеспечение в резервной системе ( ил и наборе систе м ) , выпол н ите тесты , чтобы подтвердить е го фун кционал ьность, а затем перекл юч ите трафик из реал ьной си­ сте м ы в резервную после завершен ия тестов. Эта стратегия работает особен н о хорошо, когда трафик проксируется через баланси­ ровщик нагрузки . Реальные системы обрабатывают все пол ьзовател ьские соеди н е н и я , пока готовятся резервные систе м ы . В подходя щий момент можно добавить в баланси­ ровщик нагрузки резервные системы и удалить предыдущие систе м ы . Развертывание за­ вершено, когда все старые систе м ы находятся вне ротации и все тра н закци и , которые они обрабаты вают, завершил ись. m Дополнительную информацию о баланси ровщиках нагрузки см. в разделе 1 9 . 2 .

Глава 26. Непрерывная интеграция и доставка

967

Плавное развертывание (rolling deployment) обновляет существующие системы поэтап­ но, изменяя программное обеспечение в одной системе за оди н раз. Каждая с истема уда­ ляется из балансировщика нагрузки , обновляется, а затем добавляется обратно в ротацию для обработки пользовательского трафика. Такой тип развертыван ия может вызвать проб­ лем ы , если приложение не допускает существования двух разных версий одновременно. Стратеги и с и н е -зел е ного и плавного разверты ван ия можно совм естить с подхо ­ дом , который назы вается » канарееч н ы м » , по аналоги и с канарей кой в угольной шахте. Сначала вы направляете небольшой объем трафи ка в одну систему (или небол ьшой про­ цент с исте м ) , которая запускает новую версию. Есл и у новой верс и и есть п роблем ы , вы ее отключаете и исправляете проблему, оказывая влияние только на нескольких пол ьзо­ вателе й . Конечно, канарееч н ы м с истемам н ужна точная телеметрия и мон иторинг, что­ бы вы могл и вовремя определить, не появил ись ли новые проблем ы .

26.3 .

JENКINS: СЕРВЕР АВТОМАТИЗАЦИИ С ОТКРЫТЫ М ИСХОДНЫМ КОДОМ

Jenkins это сервер автоматизаци и , написан н ы й на языке Java. Это, безусловно, са­ мое популярное программ ное обеспече н и е , испол ьзуемое для реал изации подхода C I / C D. Благодаря ш и рокому внедре н и ю и обширной э косистеме подкл ючаемых модул ей Jenkins хорошо подходит для разл ичных вариантов испол ьзования. Сервер Jenkins несложно запустить в конте йнере Docker: —

$ docker run -р 8 0 8 0 : 8 0 8 0 — -name j enkins j enkinsci / j enkins

П осле запус ка контейнера вы можете получить доступ к пол ьзовательскому и нтер­ фейсу Jenkins в веб-браузере через порт 8080. Начальный парол ь адм и н истратора будет указан в сообще ниях, выводи мых контейнером . На практике вам нужно немеш1е нно из­ менить этот парол ь! Для изучения ос нов подойдет конфигурация с одн им контейнеро м , но в производ­ ственных средах, скорее всего, потребуется более надежное решение. На странице загруз­ ки сервера Jenkins ( j e n k i n s . i o / down load) есть инструкци и по и нсталляции, которые м ы н е будем здесь повторять. Обратитесь к этим документам дл я и нсталляции сервера в опе­ рационных системах Linux и Free B S D . Ком пания Cloud Bees, создател ь сервера Jenkins, также предлагает версию с высокой доступностью под названием Jenkins Enterprise . У сервера J e n k i ns есть подключае м ые модул и дл я каждой м ысл и м о й зада ч и . Испол ьзуйте подключае м ые модули для выполнения сборок в разн ых типах агентов, от­ правки уведомлений, координации вы пусков и выполнения запланированных задан ий. П одключае м ые модул и взаи модействуют с и нструментами с открытым исходн ым ко­ дом и со всем и основными облачн ы м и платформам и и вне ш н и м и поставщи кам и SaaS . Именно подключаемые модул и обеспечивают сверхспособности серверу Jenkins. Большинство настрое к Jenkins выпол н я ются через неб-и нтерфейс, и, проявляя Ш ­ лосердие к вашему в н и м а н и ю , м ы не пытае мся оп исать все нюансы пол ьзовател ьс кого интерфейса. Вместо этого мы представляем ос новы работы сервера J e пkins и некоторые из его наиболее важн ых особенностей.

Основные кон цепции сервера Jenki ns По сути , Jenkins это координ и рующий сервер, который с вязывает ряд инструм е н ­ тов в цепочку, или , испол ьзуя терминологию C I/C D , кон вейер. Сервер Jenkins явля ется организатором и посредн и ком ; вся фа ктическая работа зависит от внешних служб , та-

Ча сть lV. Эксплуатация

968

ких как репозитории исходного кода, ком п илятор ы , и нструменты сборки, средств тес­ тирования и систем развертыван ия. Задание (job) для сервера Jenkins, ил и проект, — это коллекция связан н ых этапов. Создание проекта — это задача первостепен ной важности для новой инсталляци и . Вы можете связать этапы проекта, чтобы они выполнялись последовательно или параллель­ но. Вы можете даже настроить условн ые этап ы , которые делают разные вещи в зависи­ мости от результатов предыдущих этапов. Кажды й п рое кт должен быть подключен к ре позиторию исходного кода. У серве­ ра Jenkins есть собстве н ная поддержка почти каждой с исте м ы контроля верс и й : G i t , Subve rsion , Mercurial и даже таких древних систе м , как C VS . Существуют также подклю­ чаемые модули и нтеграции для более высокоуровневых служб контроля верс и й , таких как G it Hub, Git l…ab и Bit Bucket . Вам нужно будет предоставить серверу Jenkins соответ­ ствующие учетные дан ные, чтобы он мог загружать код из вашего репозитория. » Контекст сборки » (build context) это текущи й рабочи й каталог систе м ы Jenkins. в котором выпол н яется сборка. Исходн ы й код копируется в конте кст сборк и вместе с любы м и поддерживающим и файлам и , которые необходим ы для сборки . П одкл юч и в сервер Jenkins к репозитори ю контроля верс и й , вы сможете создать триг­ гер сборки . Это сигнал для сервера Jenkins скопировать текущи й исходн ый код и н ачать процесс сборки. Сервер Jenkins может опрос ить исходн ы й ре позиторий в поисках но­ вых фиксаций , и коrда он ее найдет — ин ициировать сборку. О н также может запускать сборку по расписанию или запускаться с помощью веб-триггера, которы й поддержива­ ется репозиторием Git Hub. П осле настройки трипера создайте этапы сборки, т.е. кон кретн ые задачи , которые будут создавать сборку. Этапы моrут быть специфич н ы м и для кода или универсал ьн ыми сценариями оболочки. Например, проекты Java обычно создаются с помощью и нструмен­ та Maven. Подключаем ы й модуль Jenkins поддерживает Maven напрямую, поэтому вы мо­ жете просто добавить этап сборки Maven. Для проекта, написанного на языке С, первый этап сборки может быть просто сценарием оболоч ки , которы й запускает команду make. Остал ьные этапы сборки зависят от целей вашего проекта. Наиболее распространен­ ные сборки включают этапы , которые и н ициируют задачи тестирован и я , обсуждаемые выше в разделе «Тестирование » . Вам может понадобиться этап для создания произвол ь­ ного артефакта сборки , такого как архи в tar, пакет оп ерацион ной с исте м ы или образ контей нера. Вы также можете вкл ючить этапы, которые и н ициируют уведомле н и я ад­ м и н истратора, предпринимают действия , связан ные с развертыван и е м , или коорди ни­ руются с помощью внешних инструментов. Для проекта C l/C D этапы сборки могут охватывать все этапы кон вейера: создавать код, запус кать тесты , загружать артефакт в репозитори й и запус кать развертыван ие. Кажд ы й этап кон ве й ера явля ется все го л и ш ь этапом сборки в рам ках проекта Jenkins. И нтерфейс Jenkins представляет собой обзор состоян и я каждого этапа. поэтому легко увидеть, что происходит в конвейере . Организации, в которых есть мноrо приложен и й , должн ы иметь отдел ьные проекты Jenkins для каждого приложения. Каждый проект будет иметь отдел ьны й ре позиторий кода и этапы сборки. Система Jenkins требует для запуска сборки в л юбом из своих про­ е ктов наличия всех и нструментов и зависимостей. Н апример, если вы настроили проект на языке Java и проект на языке С, ваша система Jenkins должна и меть доступ как к ин­ струменту Maven, так и к команде make. П роекты моrут зависеть от других проектов. Используйте это в своих интересах, струк­ турируя проекты как общие, наследуемые шаблон ы. Например, если у вас есть множество приложений, которые построен ы по-разному, но развернуты оди наково (например, как —

Глава 26. Непрерывная интеграция и доставка

969

контейнеры , запущен н ые на кластере серверов), вы можете сщдать общий проект «развер­ тывания» . которы й упраRЛяет общим этапом развертывания. Оrдельные проекты приложе­ ний мoryr выполнять проект развертывания, тем самым устраняя шаг избыточной сборки.

Расп ределенн ые сборки В тех средах , где поддержи ваются десятки приложе н и й , прич е м каждое со своим и зависимостя ми и этапами сборки, ле гко непреднамеренно создать кон фл и кты зависи­ мостей и узкие места, поскол ьку сразу запускается сл иш ком м ного кон вейеров. Чтобы ком пенсировать это, сервер Jenkins позволяет вам перейти в распределен ную архитек­ туру сборки. В этом режиме работы испол ьзуется » м астер сборки » , центральная систе­ ма, которая отслеживает все проекты и их текущее состоя ние, а также «агенты сборки » , которые выпол н я ют фактические этапы сборки для проекта. Если вы часто используете сервер Jenkins, то довольно быстро перейдете к этой конфигурации. Аrенты сборки запускаются на хостах, которые отделены от мастера сборки. Мастер сер­ вера Jenkins подключается к подчиненным системам (обычно через протокол SSH ) , чтобы запустить процесс агента и добавить метки , которые документируют возможности подчи ­ ненных систем. Например, в ы можете отличить своих агентов, поддерживающих язык Java, от ваших же агентов с поддержкой языка С, применяя соответствующие метки. Для дости­ жения наилучших резул ьтатов запускайте агенты в конте йнерах, удаленн ых виртуал ьн ых машинах или временн ых облач ных средах, которые масштабируются и возвращаются в ис­ ходное состояние по требованию. Если у вас есть кластер контейнеров, вы можете исполь­ зовать подключаемые модули Jenkins для запуска агентов в кластере через систему упраRЛе­ ния контейнерами.

Кон вейер ка к код До сих пор мы описал и процесс создания проектов Jenkins, объединяя отдельные этапы сборки в веб-интерфейсе. Это сам ы й быстрый способ начать работу с сервером Jenkins, но с точ ки зрен ия и нфраструктуры это нем ного непрозрач но. Код — в дан ном контексте им является содержимое каждого этапа сборки — управляется сервером Jenkins. Вы не можете проверять этапы сборки в репозитории кода с помощью графического и н ­ струмента, и если в ы потеряете сервер Jenkins, у вас не будет простого способа его заме­ нить; вам нужно будет восстановить свои проекты из недавней резервной копии. Во второй версии сервера Jenkins введена новая основная функция, называемая Pipeine, которая обеспечивает первоклассную поддержку кон вейеров C l/CD. В кон вейере Jenkins этапы проекта кодируются в декларативном стиле, специфичном для предметно-ориенти­ рован ного языка, который основан на языке программ ирования Groovy. Вы можете пере­ дать код Jenkins, назы ваемый Jenkinsfile, вместе с кодом , связанным с кон вейером. Следующий код Jenkinsfile де монстрирует базовый цикл сборки — тестирова­ ния — развертывания. pipeline { a g e n t any s tages { s t a g e ( ‘ Bu i l d ‘ ) s t ep s { s h ‘ ma k e ‘

s t age ( ‘ Te s t ‘ ) s teps {

Часть lV. Эксплуатация

970 sh ‘ rna k e t e s t ‘ s t a ge ( ‘ D e p l o y ‘ ) steps { s h ‘ de p l o y . s h ‘

Выраже н ие a g e n t a n y и нструктирует сервер Je nkins подготовить рабочую область для этого конвейера на л юбом доступном агенте сборки. 2 Этапы сборки , тестирования и развертывания соответствуют кон цептуальным этапам конвейера Cl/C D. В нашем приме­ ре каждый этап имеет один шаг, который вызывает оболочку (sh) для выполнения команды. На этапе развертыван и я вы пол н яется собствен н ы й сценари й deploy . sh, который обрабаты вает все разверт ы ва н и е , включая копирование артефакта сборки (сге н ериро­ ван ного н а этапе B u i l d ) на набор серверов и перезапуск серверн ых процессов. На прак­ тике развертывание обычно дел ится на несколько этапов, чтобы обеспечить лучшую ви­ димость и контрол ь н ад пол н ы м п роцессом .

26.4. Подход Cl/CD НА ПРАКТИКЕ Теперь м ы переЙдем к искусствен ному примеру, чтобы проиллюстрировать представ­ ленные нами кон цепции. Мы придумал и простое приложение UlsahGo, нам ного более основательное , чем все , что вам может понадобиться для управления в реал ьном мире. Оно полностью автономное и н е и меет зависимостей от других приложе н и й . Наш пример вкл ючает следующие элементы: • неб-приложен ие UlsahGo с одной небольшой фун кцией ; • модул ьн ые тесты для приложе н и я ; •

• • •

образ виртуал ьной ма ш и н ы для облачной инфраструктуры DigitaOcean , которая содержит приложе н и е ; односерверную среду разработки , создаваемую п о требованию; м ногосерверную среду с балансировкой нагрузки, создаваемую по требованию; кон вейер C l/CD, которы й соедин яет все эти части вместе .

В этом примере м ы испол ьзуе м несколько популярных и нструме нтов и служб: • • •

Git H ub как репозитори й кода; виртуальные маш и н ы D igi t a Ocean и балансировщики нагрузки ; упаковщи к Hashi Corp для обес п е че н ия образа дл я облачной и нфраструктур ы DigitaOcea n ;

инструмент Te rraform от H a s hiCorp для создания среды развертывания ;

сервер Jenkins для управлен ия кон вейером C l/C D .

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

2 Рабочая обл асть — это синон и м ко н текста сборки : место на локал ьном диске агента, в котором содержатся все фа йл ы , необходимые для сборки, вкл ючая исходн ы й код и завис и мости . Каждая сборка и меет частное рабочее п ространство.

Глава 26. Непрерывная интеграция и доставка

971

На рис. 26. 1 показаны первые несколько этапов примерного кон ве йера. На диаграм­ ме показан опрос конвейеров G it H ub в поисках новых фиксаций в проект UlsahGo. Когда фиксация наЙдена, сервер Jenkins запускает блок тестирования. Если тесты проходят, сервер Jenkins строит двоичный файл . Есл и двоичная сборка успешно завершена, конвейер про­ должает создавать артефакт развертывания — образ машины DigitaIOcean, который вкл юча­ ет двоичный файл. Есл и какой-либо из этапов не работает, конвейер сообщает об ошибке.

Репозиторий UlsahGo GitHub

Модульные тесты провалены

Ошибка

Сборка образа провалена

Этап сборки провален Сборка Модульные Просмотр двоичного тесты файла фиксаций Найдена Модульные Сборка UlsahGo тесты фиксация прошла пройдены успешно Конвейер Jenkins

Сборка образа DigitalOcean

Продолжение на этапе развертывания

Рис. 26. З. Демонстрационный конвейер (часть первая)

Подробное описание этапов развертывания приводится н иже , но сначал а м ы долж­ ны рассмотреть начал ьн ые этапы.

Тривиал ьное ве б — приложение UlsahGo П риложение из нашего при мера предстамяет собой веб-службу с одной фун кцией. Оно возвращает сп исок, авторов, связан ных с указанным изданием этой книги , в формате J SON . Например, следующий запрос отображает имена авторов указан ного издан ия. $ curl ul sahgo . admin . com/ ?edi tion=S { » au t h o r s » : [ » Ev i » , » Garth » , » T rent » , «Ben » , » Da n «

] ‘ » numЬe r » : 5

При обработке этого запроса мы должн ы выпол нить простую проверку корректности получен н ых данн ых, чтобы убедиться , что пол ьзователи не сл ишком умекаются, напри­ мер запраш ивая не правдоподобн ые номера изданий. $ cu r l -vs ulsahgo . admin . com/?edi tion=б < Н Т Т Р / 1 . 1 4 0 4 Not Found < C o n t e n t -Type : appl i c a t i on / j s on » e r r o r » : » б t h e d i t i o n i s inva l i d . «

Наше приложе ние имеет также спе циал ьную точ ку входа для проверки работоспо­ собности. П роверка работос пособности — это простой способ для мон иторинга систем, чтобы с прос ить приложе ние: » П ривет, все хорошо? » $ curl ulsahgo . admin . com/heal thy {

972

Часть lV. Эксплvатация

» he a l t h y » : » t r ue «

Разработчи ки обычно тесно сотрудн ичают с адм ин истраторами в процессе со:щания этапов сборки и тестирова н ия кон ве йера C l/CD. В данном случае , поскол ьку приложе­ ние нап исано на языке Go, мы можем испол ьзовать стандартн ые инструменты Go (go build и go test) в нашем кон вейере.

Модул ьное тести рова ние U l sa hGo М одульные тесты — это первый тестовый набор для запуска, поскольку о н и работают на уровне исходного кода. Модульные тесты проверяют функции и методы приложения с максимально возможной детализацией. Для большинства языков программирования соз­ даны тестовые каркасы, в которых реализована встроен ная поддержка модульных тестов. Давайте проанализируем оди н модульный тест для UlsahGo. Рассмотри м следующую фун кцию. func o r d i n a l ( n i n t ) s t r i n g { suf fix : = «th» switch n { case 1 : «st» suf fix case 2 : «nd» suf fix case 3 : suf fix » rd» r e t u r n s t r c o nv . I t o a ( n ) + s u f f i x

Этой функции в качестве входного параметра передается целое число , а она определя ­ ет соответствующее порядковое выражение. Н апример, если фун кци и передан аргумент, равный 1 , то она возвращает строку » l s t » . П рограмма UlsahGo использует эту функцию для форматирования текста в сообщении об ошибке для недопустимых номеров изданий книг. М одульные тесты п ытаются доказать, что при произвольных входных данных фун к­ ция все гда возвращает ожидаем ы й резул ьтат. Вот модульный тест, которы й выпол няет эту функцию. func T e s t O r d i n a l ( t * t e s t i ng . T ) ord : = ordinal ( l ) ехр : = » l s t » i f o r d ! = ехр { t . E r r o r ( » e x pe c t e d % s , g o t % s » , е хр , o r d ) ord = ordinal ( l O ) ехр = » l O t h » if ord != ехр { t . E r r o r ( » expected % s , got % s » , ехр , ord )

Этот модул ьн ы й тест запус кает фун кцию для двух значен и й — 1 и 1 0 — и подтверж­ дает, что фактический ответ соответствует ожиданию. 3 Мы можем запус кать тесты через встроен ную систему тестирования Go. 18 фун кции ordinal ( ) реализовано три особых случая и оди н общий . nри запуске полного на­ бора модул ьных тестов должна быть вы пол нена каждая из возможных веток кода.

глава 26. Непрерывная интеграция и доставка

$ go tes t PAS S o k g i t hub . c om / b wh a l e y / u l s ahgo

973

О . ООбs

Если какая-то часть приложе н ия в будущем изменится — например, если в функцию o rd i n a l ( ) будут добавлены обновления — тесты сообщат о л юбом расхожден и и с ожи­ дае м ы м выходн ы м значен и е м . За обновл е н ие модул ьных тестов отвечают разработчи ­ к и , поскол ьку именно о н и вносят изменения в код. Опытные разработчики сразу п ишут код, который легко тестировать. О н и нацеле н ы на пол ное покрытие тестами каждого метода и функции.

З накомство с кон вейером Jenkins Pipeline Подготовив к поставке код и модульные тесты, сделайте первы й ш а г на пути освое­ ния C l/C D — настройте проект на сервере Jenkins. Через процесс вас проведет графи­ ческий пользовательский интерфейс. Н иже при водятся варианты , которые м ы выбрали . •

Н аш новый проект назы вается Pipeline. Он определен кодом , а н е традицион н ы м проектом в свободном стиле с этапами сборки , которые в основном определяются элементам и пол ьзовательского и нтерфейса. Мы хотим отслеживать наш конвейер вместе с репозиторием исходного кода в фай­ ле Jenkinsfile, поэтому м ы выбираем для определения Pipel i ne пункт Pipeline script from SCM.

М ы запускаем сборку путе м опроса G it H ub в поисках фиксац и и . М ы добавл я ­ е м учет н ы е дан н ы е , чтобы сервер J e nkins мог получ ить доступ к репозитор и ю UsahGo и настроиться на опрос Git H ub в поисках изменений каждые пять м и н ут.

Начал ьная настрой ка зан имает всего нескол ько секунд. В реал ьной жизн и м ы ис­ пол ьзовал и бы веб-триггер G it H ub, чтобы уведом ить сервер Jenkins о том , что н овая фиксация доступна, и избежать опроса, тем сам ы м избавляя G it H ub от н енужных об­ раще н и й к е го и нтерфейсу A P I . С помощью этой настройки сервер Jenkins выпол няет конвейер, описанн ы й в файле Jenkinsfile в репозитории вся кий раз, когда в Git H ub появляется новая фиксация. Теперь давайте рассмотрим структуру репозитория . В нашем проекте м ы реш ил и объ­ един ить C I/CD и код приложения в одном репозитории, при этом все файл ы , связанные с C l/CD , хранятся в подкаталоге pipeline . Репозитори й U lsahGo представле н следую­ щим образом. $ tree ulsahgo u l s a �.qo p i pe l i n e

,Te n k i n s f i l e

� L

pac k e r p r o v 1· s � o п e r . s h

u l sahgo . ё son . u l s a г.go . s e r v i c e

p r· o du c t i o n

fL

t f p r o o . s :O

u l s a !l g o . :: :

t es t i n q

[

tf

c: e s t i ng . s ‘°’ _ u l sahgo . t :

u l sahgo . go u l s ahgo t e s t . go _

974

Часть lV. Эксплvатация

И нте гр ированная структура хорошо работает для небол ьшого прое кта , подобного этому. Jenkins, Packer, Terraform и другие инструменты могут искать с вои файл ы кон ­ фигураци и в подкаталоге конвейера. И зменение кон ве йера развертывания выполняется путем простого обновления репозитория . Для более сложных сред, в которых несколько прое ктов имеют общую и нфраструктуру, рекомендуем использовать вьщелен н ы й репо­ зиторий и нфраструктуры . П осле настройки и нфраструктуры прое кта можно выпол н ить фиксацию в репозито­ рии нашего первого файла Jenkinsfile. Первым шагом в любом конвейере является получение исходного кода. Вот пол н ы й сценарий конвейера Jenkinsfile, который де­ лает именно это. p i p e l i ne { agent any s t a ge s { s t ag e ( ‘ Ch e c kout ‘ ) steps { c h e c kout s cm

Строка c h e c ko u t s cm дает указание серверу Jenkins получ ить исходны й код из с и ­ сте м ы управления конфигурацией п рограм много обеспечения (это о б щ и й отрасле вой терм и н для с истем контроля версий). П осле опроса репозитория G it Hub сервером J e nkins и завершения этапа получения исходного кода м ы можем перейти к настро й ке этапов тестирован ия и сборки. Наш проект Go н е имеет внешних зависимостей . Единствен н ы м требованием для создания и тестирования нашего кода я вляется двоичн ы й исполняемый файл go. Мы уже устано­ вили систему Jenkins (с помощью команды apt-get -у install golang-go) , поэтому нам нужно только добавить этапы тестирования и сборки в файл Jenkinsfi l se: s t age ( ‘ Un i t t e s t s ‘ ) steps { s h ‘ go t e s t ‘

s t age ( ‘ Bu i l d ‘ ) s teps { s h ‘ go bui l d ‘

После того как м ы зафиксируе м изменения в хранилище , систе ма Jenkins обнаружит новую фиксацию и запустит кон вейер. Зате м система Jenkins ге нерирует ч итабел ьную запись журнала, подтверждая , что она сделала это. Ma r 3 0 , 2 0 1 7 4 : 3 5 : 0 0 РМ h u d s o n . t r i gg e r s . SCMT r i gg e r $ Runne r run I N FO : SCM change s d e t e c t e d i n U l s ahGo . T r i g g e r i n g # 4 Ma r 3 0 , 2 0 1 7 4 : 3 5 : 1 1 РМ o r g . j e n k i n s c i . p l u g i n s . wo r k f l ow . j ob . Wo r k f l owRun finis h I N FO : U l s ahGo # 4 c omp l e t e d : S U CC E S S

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

Глава 26. Непрерывная интеграция и доставка

975

устранять сбои сборки. проверяя консольный вывод, которы й находится в деталях сбор­ ки. Он представляет собой содержан ие потока ST DOUT , которое выводится на экран лю­ бой частью сборки. Н иже приведен фрагмент резул ьтатов вы вода команд go teв t и go build в ходе ра­ боты кон ве йера. [ P ip e l i n e ) s t age [ P i p e l i n e ) { ( Un i t T e s t s ) [ Pipel ine ] sh [ Ul s ahGo ) Run n i n g s h e l l s c r i p t + go test PAS S ok _ / va r / j e n k i n s home /wo r k s p a c e / U l s ahGo [ Pipel ine ) } [ P i pe l i n e ) / / s t a ge [ Pi pe l i n e ) s t a ge [ P i p e l i n e ) { ( Bu i l d ) [ Pipeline ) sh [ Ul s ahGo ) Run n i n g s h e l l s c r i p t + g o bui l d [ Pi p e l i n e ) ) [ P i pe l i n e ) / / s t age [ Pipel ine ) } [ P i p e l i n e ) / / node [ P i p e l i n e ) End of P i p e l i n e Fi n i s h e d : S U C C E S S

О . ООбs

Обычно определить причину неудач ной сборки можно, просмотре в журнал . И щ ите сообще ния об ошибках, которые идентифицируют неудавшийся шаг. Вы также можете добавить собственные сообщения в журнал , чтобы предоставлять подсказки о состоян и и систе м ы , такие как значения переменных ил и содержимое сценария в данной точ ке вы­ полнения. Испол ьзование отладочной печати — это старая традиция п рограмм истов. Результатом нашей сборки является оди н двоичный файл ul вahgo , который содержит все наше приложение. (Это, кстати, одно из основных пре имуществ програм м на языке Go, и одна из прич и н , почему язык Go популярен у с исте м н ы х администраторов: с его помощью легко создавать статические двоич ные файл ы , которые выполняются в несколь­ ких архитектурах и не имеют внеш н их зависимостей. Установка приложения на языке Go часто бывает простой и сводится к его копирован ию в нужн ы й каталог системы.)

Созда ние образа Digita lOcea n Те перь, когда файл ulsahgo готов к поставке , мы создадим образ виртуал ьной ма­ ш и н ы дл я облака DigitaIOcean. Мы н ач инаем с простого образа U buntu 1 6 .04, устанав­ ливаем последние обновления, а затем устанавл иваем програ м м у ulвahgo. П олуче н н ы й образ становится артефактом развертывания для остальных этапов конвейера. m Если вы н е знакомы с упаковщиком packe r , к отор ы й создает образ в и ртуал ьной маши ны, перед продолжением обратитесь к разделу 24. 6 . Упаковщик packer сч иты вает конфигурацию свое го образа из шаблона , который имеет два основных раздела: ) сборщики , которые взаимодействуют с удал е н н ы м и ин­ терфе йсами API для создания маш и н и образов, и 2 ) вс помогател ьн ы е устройства, кото­ рые запускают настраиваемые этапы настрой ки. В шаблоне для нашего образа UlsahGo указан тол ько оди н сборщик.

Часть lV. Эксплvатация

976

«builder s » : [ { » t yp e » : » d i g i t a l o c e an » , » ap i_ t o k e n » : » r j 8 Fs rM I 1 7 vq T l B 8 qqBn 9 f 7 x Qe d J k k Z J7 cqJcB 1 0 5 nm0 6 i h z » , » r e g i on ‘ ‘ : » s f o 2 » , » s i z e » : » 5 1 2mЬ » , » image » : » ubuntu — 1 6 — 0 4 — x 6 4 » , » s n a p s h o t n ame » : » u l s ahgo — l a t e s t » , » s s h u s e rname » : » r o o t » }]

Помимо других деталей , относящихся к конкретному провайдеру, сборщик сообщает упаковщику packer, какая платформа испол ьзуется для создан ия образа и как аутенти­ фицироваться в интерфейсе A P I . Для этого он выпол няет следующие три подготови­ тельных этапа. » p rovi s i on e r s » : [ { » t yp e » : » f i l e » , » s ou r c e » : » u l s ah g o » , » d e s t i n a t i on » : » / tmp / u l s ah g o » } { » t yp e » : » f i l e » , » s ou r c e » : » p i p e l i n e / p a c ke r / u l s ah g o . s e rv i c e » , » de s t in a t i o n » : » / e t c / s y s te md / s y s t e m / u l s ah g o . s e rvi c e » } { » t yp e » : » s he l l » , » s c r i pt » : » p ip e l i n e / p a c k e r / p rovi s i on e r . s h » .

.

m Дополнительную информаци ю о модульных файлах sys temd с м . в разделе 2 . 7 . Первые д в а подготовител ьных этапа и н и ци ализации добавл я ют файлы к образу. Первый файл — это само прил оже н ие u l s ahgo , которое загружается в каталог / tmp для последующего использования. Второй файл — это подкл ючае м ы й файл sys temd, который управляет службой. На последнем подготовительном этапе запускается собствен н ы й сценарий оболочки в удал е нной системе. Сценарий provisioner . sh обновляет систему, а затем настраива­ ет приложение. # ! / u s r /b i n / e n v b a s h app=ul s ah g o # Обно ви м ОС и д о б а в им уче т ную з а п и с ь поль з о в а т е л я a p t — g e t upd a t e & & apt — g e t — у upgrade / u s r / sb i n / u s e radd — s / u s r / s b i n / n o l o g i n $ арр # С оздадим р а бочий к а т ал о г и с к о пируем в н е г о приложе ние m kd i r / o p t / $ app & & c hown $ арр / o p t / $ app ер / tmp / $ app / op t / $ app / $ app ch own $ арр / o p t / $ ap p / $ ap p && chmod 7 0 0 / op t / $ app / $ app # Разрешим р а б о т у модуля s y s t emd s y s t emct l е n а Ы е $ арр

Кроме сценариев оболочки , утилита packer позволяет испол ьзовать н а подготови­ тельных этапах все популярные инструменты управл е н и я конфигурацией. Она может вызывать Puppet , Chef, AnsiЫe или Salt , чтобы настроить ваши образы более структури­ рованн ы м и масштабируе м ы м способом.

Глава 26. Непрерывная интеграция и доставка

977

Наконец, м ы можем добавить этап создания образа в наш файл Jenkinsfile. stage ( ‘ Bu i l d i ma g e ‘ ) { steps ( s h ‘ p a c k e r bu i l d p i p e l i n e / p a c ke r / u l s ahgo . j s on > p a c ke r . t x t ‘ s h ‘ g r ep I D : p a c ke r . t x t 1 g r e p — Е — о ‘ ( 0 — 9 ] { 8 } ‘ > do_ima g e . t x t ‘

На первом шаге вызы вается программа packer и сохраняется резул ьтат ее выво­ да в файле packer . txt в рабочем каталоге сборки. 8 кон це этого вывода содержится иде нтифи катор нового образа. = = > d i g i t a l oc e a n : G r a c e f u l l y s hu t t i ng down drop l e t . . .

> digital ocean : Creating snapshot : u l s ahgo- l a t e s t = = > d i g i t a l oc e a n : W a i t i n g f o r s n a p s h o t t o c omp l e t e . . . ==> d i g i t a l oc e a n : De s t r o y i n g d r op l e t . . . > d i g i t a l o c e a n : De l e t i n g temp o r a r y s s h k e y . . . Bui l d ‘ di g i t a l oc e a n ‘ f i n i s h e d . ==> Builds fini shed . The a r t i f a c t s o f succe s s ful bui lds a r e : — — > d i g i t a l oc e a n : А s n a p s h o t w a s c r e a t e d : ( I D : 2 3 8 3 8 5 4 0 ) ==

==

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

Обеспечение ед и ной системы тестирова ния Итак, у нас есть процесс н е прер ывного в ы пол н е н ия модульных тестов, созда н и я приложе н и я и образа виртуал ьной маш и н ы в качестве артефакта сборки. Остал ьные этапы сборки сосредоточен ы на этапе развертывания артефакта и его тестирования в ре­ ал ьн ых условиях. На рис. 26.4 представлено п родол же н ие рис. 26. 3 .

Готовый к запуску образ

Создание дроплета провалено Создание отдельного дроплета DigitalOcean

Ошибка

Тесты провалены

Неправильная конфигурация

Тестирование дроnлета

Создание среды со сбалансированной нагрузкой

Тесты провалены

Тестирование балансировщика нагрузки

Конвейер Jenkins Рис. 26. 4. Демонстрационный конвейер (часть вторая)

Для создания и управлен ия инфраструктурой UlsahGo мы реш или использовать утил и ­ ту terraform, еще один инструмент ком пании Hasl1iCorp. Утилита terraform считывает свою конфигурацию из так называемых » планов» J SОN — подобных файлов конфи гураци и , в которых описывается желаемая конфигурация инфраструктуры . Зате м она создает об­ лачные ресурсы , описан ные в плане, путем создания соответствующей серии вызовов A P I . Утилита terraform поддерживает десятки облач ных провайдеров и широкий спектр служб. Следующая конфигурация terraform, задан ная в файле ulsahgo . tf, подготавл ива­ ет отдельн ый дроплет DigitalOcean, запускающий образ, который мы создал и на преды ­ дущем этапе кон вейера.

Часть lV. Эксплуатация

9 78 va r i aЫ e » do_t o ke n » 1 1 va r i aЫ e » s s h_ f i n g e rp r i n t » 1 1 va r i aЫ e » do_ima g e » 1 1

provide r » di g i t a l o c e a n » 1 t o ke n = » $ 1 va r . do_t o ke n ) «

r e s ou r c e » d i g i t a l o c e an_drop l e t » » u l s ah g o — l a t e s t » 1 image = » $ { v a r . do_image l » n ame = » u l s a h g o — l a t e s t » r e g i on » s f o2 » s i z e = » 5 1 2mb » s s h_ k e y s = [ » $ { va r . s s h f i n g e r p r i n t l » J =

Большинство этих дире кти в самооче видн ы : используйте службу Digital Oceaп в ка­ честве п ровайдера, вы пол н ите аутентификацию с предоставл е н н ы м токеном и создайте дроплет в области s f о2 из указан ного идентифи катора образа. В шаблоне Packe r, представлен ном в ыш е, мы непосредствен н о ввел и в конфигура­ цию упаковщика такие параметры , как токе н АР! . Одна (большая ! ) п роблема с эти м подходом заключается в том , что ключ А Р ! сохран яется в репозитор и и исходного кода, даже есл и он предположител ьно я вляется секретн ы м . Этот ключ дает доступ к интер­ фейсу АР! провайдера облачн ых вычисл е н и й и, следовательно, будет опасен в н е пра­ вильных руках. Сохранение секретов в системе контроле версий — это антишаблон без­ опас ности по причи нам , которые мы более подробно описывали в разделе 7 . 8 . В этом примере м ы вместо этого считы ваем параметры в виде переме н н ых. Эти три пере м е н н ые перечислен ы н иже . •

Токен D igita!Oceaп АР! .

Отпечаток кл юча S S H , которому будет разрешен доступ к дроплету.

Идентификатор образа для новой с исте м ы , который м ы зап исали на предыдущем этапе кон ве йера.

С истема J eпkiпs может хран ить такие секреты , как токе н АР ! , в своем «хра н ил ище у•1етных дан ных» — заш ифрованной области , предназначен ной и м е н но для таких кон ­ фиден ц иальных дан н ых. Кон вейер может сч итывать значе н ия из хран ил ища учетных дан ных и сохранять их в виде пере м е н н ых среды. Затем значения становятся доступны­ м и по всему кон вейеру без сохранения в с истеме контроля версий. Вот как м ы сделал и это в файле Jenkinsfile. pipe line 1 e nvi r onme nt 1 DO TOKEN c r e d e n t i a l s ( ‘ do — t o ke n ‘ ) S S H_ F I NGERP R I N T = c r e d e n t i a l s ( ‘ s s h — f i n g e r p r i n t ‘ ) =

Н апом н и м , что м ы сохра н или идентификатор образа маши н ы D igita!Oceaп в файле . txt, который находится в области сборки. Нам нужен этот идентифи катор на нашем новом этапе конве йера, которы й создает фактический дроллет Digita!Oceaп . Код для нового этапа просто запускает сценарий из репозитори я проекта.

do_image

s t a g e ( ‘ C r e a t e d r op l e t ‘ ) { s teps { s h ‘ ba s h p i p e l ine / t e s t i ng / t f t e s t i ng . s h ‘

Глава 26. Непрерывная интеграция и доставка

979

Намного проще и удобнее хран ить код сложных сценариев отдельно от остал ьной части кон вейера, как мы и сделали. Файл tf_tes ting . sh содержит следующие строки. ер d o_ ima g e . tx t p i p e l i n e / t e s t i n g cd p i p e l i ne / t e s t i n g t e r ra f o rm a pp l y -va r d o_ ima g e= » $ ( < d o_ima g e . t x t ) » -va r d o_t o ken= » $ { DO_TOKEN } » -va r s sh _ f i ng e r p r i n t= » $ { S SH _ F I NGERPR I N T } » t e r r a f o rm s h ow t e r r a fo rm . t f s t a t e 1 g r ep i pv 4 _addre s s 1 awk » { p r i n t $ 3 ) » > . . / . . /do _ i p . t x t

Этот сценарий копирует файл с сохране н н ы м идентифи катором образа в о вре ме н­ ный каталог pipeline / te s ting, а затем запускает утилиту terraform из этого ката­ лога. Утилита terraform и щет файлы в текущем каталоге с расширением . tf, поэтому нам не нужно явно указывать файл плана. ( Это тот же сам ы й файл ulsahgo . tf, кото­ рый мы рассматривал и выше. ) Необходимо сделать нес колько пояснени й . •

Перемен н ые среды 00 _ TOKEN и S S H _ F I N G E R P R I N T доступны ДЛ Я л юбых команд оболочки в конвейере . Раздел e n v i r o nme n t , показа н н ы й выше, может появлять­ ся л ибо на уровне общего кон ве йера, л ибо на определ е н ном этапе в зависи мости от требуемой области видимости . Команда $ ( < d o_ i m a g e . t x t ) считы вает содержимое идентификатора образа DigitalOcean из текстового файла, сохранен ного на п редыдущем этапе. Последняя строка сценария tf testing . sh проверяет дроплет, созданный утили ­ той terraform, получает e ro I Р-адрес и сохраняет адрес в текстовый файл дл я ис­ пользования на следующем этапе. Файл terraform . tfs tate представляет собой сн имок состояния систе м ы , сделан н ы й утилитой terraform. Именно так утилита terraform отслежи вает ресурсы .

Как и утилита packer, утилита terraform отправляет системные сообщен ия н а стра­ ницу консоли Jenkins. Вот фрагменты из вывода команды apply terraform. [ P i p e l i n e ] { ( C r e a t e d r op l e t ) [ Pipeline ] s h [ Ul sahGo ] Runn i n g s he l l s c r i p t d i g i t a l o c e a n _d r op l e t . u l s ah g o — l a t e s t : C r e a t i ng . . . di s k : = > » < c ompu t e d > » => » 2 3 8 8 8 0 4 7 » ima ge : => » < c ompu t e d> » ipv4 _addre s s : i p v 4_addre s s _p r i va t e : => » < c ompu t e d > » => » u l s ahgo — l a t e s t » name : => » s fo 2 » r e g i on : = > » t rue » re s i z e di s k : => » 5 1 2mЬ » size : => » 1 » s s h_ k e y s . # : => » * * * * » ssh keys . 0 : sta tus : = > » < compu t e d > » d i g i t a l o c e a n _ d r op l e t . u l s a hgo- l a t e s t : S t i l l c r e a t i n g . . . ( l O s di g i t a l oc e a n d r o p l e t . u l s ahgo- l a t e s t : S t i l l c r e a t i n g . . . ( 2 0 s d i g i t a l o c e a n = d r op l e t . u l s ah go — l a t e s t : S t i l l c r e a t i n g . . . ( 3 0 s d i g i t a l o c e an_d ropl e t . u l s a hg o — l a t e s t : C r e a t i on comp l e t e ( I D : App l y c ompl e t e ! Re s ou r ce s : 1 adde d , О change d , О de s t r o ye d .

e l ap s e d ) e l ap s e d ) e l ap s e d ) 4 4 4 8 6 63 1 )

Когда эта стадия завершается, дроплет вкл ючается и запускает приложение U l sahGo.

Часть lV. Эксплvатация

980

Тести рова н ие дро п лета Теперь у нас появилась уверен ность в том , что код является работоспособным, потому что он прошел этап модульного тестирования . Однако нам также необходимо убедиться , что он успешно работает как часть дроплета DigitalOcean. Тестирование на этом уровне считает­ ся формой теста и нтеграции. Мы хотим, чтобы тесты и нтеграции выпол нялись каждый раз при создании нового образа, поэтому мы добавляем новый этап в файл Jenkinsfile. s t ag e ( ‘ T e s t and de s t r o y the d r op l e t ‘ ) { s teps { sh ‘ ‘ ‘ # ! /Ьin/bash -1 c u r l — D — — v $ ( < do ip . t x t ) : 8 0 0 0 / ? e di t i on = S curl — D — v $ ( < do = i p . t x t ) : 8 0 0 0 / ? e d i t i on= б t e r r a f o rm d e s t roy — f o r c e ‘ ‘ —

g r e p » НТ Т Р / 1 . 1 2 0 0 » g r e p » НТ Т Р / 1 . 1 4 0 4 «

И ногда тупой и тяжелы й предмет является правил ьн ы м инструментом дл я работ ы . Эта пара команд curl посылает запрос н а ш е м у п риложе н и ю ul shago на удал е н н ы й порт дроплета 8000 , которы й испол ьзуется в программе u l s ahgo по умолчан и ю . М ы проверяем , что запрос для пятого издания возвращает Н ТТР- код 200 (ус пех) и что за­ п рос для шестого издания возвращает код НТТР 404 (сбой). Мы знае м , что ожидаем этих конкретных кодов состоян и я только из-за нашего знакомства с приложением. П о заверш е н и и тестов м ы уничтожаем дроплет, потому что он бол ьш е н е н уже н . Дроплет создается , тестируется и уничтожается п р и каждом запуске конвейера.

Развертыва ние п риложе ния U lsahGo на паре дроплетов и балансировщи ке на грузки Конечной задачей конвейера является развертывание приложения в нашей ( макетной) производственной среде, которая состоит из двух дроплетов DigitalOcean и балансировщи ­ ка нагрузки. Еще раз подчеркнем , что Terrafonn прекрасно справляется с задачей . М ы можем повторно ис пользовать конфигурацию из файла плана terraform с од­ н и м дроплетом. Нам все еще нужн ы одн и и те же переменные и ресурс дроплета. На этот раз добави м второй ресурс дроплета. r e s ou r c e » di g i t a l o c e an_d r op l e t » » u l s ah g o — b » » u l s ahgo -b » n ame size » 5 1 2 mЬ » image » $ { va r . do_image ) » s s h_ k e y s [ » $ { va r . s s h f i n g e r p r i n t ) » ] » s fo 2 » r e g i on

Мы также добавляем ресурс балансировщика нагрузки. r e s ou r c e » d i g i t a l o c e a n_ l o a db a l a nc e r » » p uЫ i c » { n ame «ul sahgo-l b » r e g i on » s fo 2 » =

=

f o rw a r d i n g_ru l e { e n t r y_ p o r t 80 e n t r y_p r o t o c o l » h t tp » t a r g e t_po r t 8000 t a r g e t_p r o t o c o l «http» =

=

=

=

Глава 26. Непрерывная интеграция и доставка

981

h e a l t h c he c k { port = 8 0 0 0 protocol «http» path = » /healthy» =

d r op l e t_i d s [ » $ { d i g i t a l oc e a n d r op l e t . u l s ahgo — a . i d ) » , » $ { d i g i t a l o c e a n =d r o p l e t . u l s a h g o — b . i d } » =

Балансировщик нагрузки прослуши вает порт 80 и передает запросы каждому дропле­ ту на порт 8000, которы й п рослуш ивает програм ма u l s ahgo . Мы указы вае м баланси­ ровщику н агрузки , чтобы он испол ьзовал конеч ную точку /heal thy и подтвердил , что все коп и и службы работают. Балансировщик нагрузки добавляет дроплет в ротацию, если он получает код состояния 200 , когда запраш и вает эту конечную точку. Теперь м ы можем добавить конфигурацию для производстве н ной среды в качестве нового этапа в кон вейере . s t a g e { 1 C r e a t e LB 1 } { steps 1 s h 1 ba s h p i p e l i n e /produ c t i on / t f_p r od . s h 1

Этап балансировки нагрузки более ил и менее идентичен стад и и одиночного экзе м ­ пляра. Даже вне ш н и й сценарий почти такой же , поэтому здесь м ы опускаем е го содер­ жимое. Мы могл и бы легко реорган изовать эти сценарии так, чтобы одна версия обраба ­ тывала обе среды , но на дан н ы й момент мы сохранил и сценарии отдел ьно. Мы также можем добавить этап тестирования , на этот раз работающий с I Р-адресом балансировщика нагрузки . s t ag e ( 1 Te s t l o a d b a l a n c e r 1 } s t ep s 1 sh 1 1 ‘ # ! /bin/bash -1 c u r l — D — — v — s $ ( < do_l b_i p . t x t ) / ? e d i t i o n = 5 c u r l — D — — v — s $ ( 1 0 . 0 . 2 . 2 : 5 4 8 3 4

Выяс н и в идентификатор P I D , с помощью команды p s можно идентифицировать кон кретный п роцесс. Если дан н ая служба не н ужна, остановите ее и убедитесь, что она н е будет заново стартовать во врем я загрузк и систе м ы . Если утилита l sof н едоступна, используйте команды fuser или netstat — р . m Допол н ительную и нформацию о процессах, выполняемых во время загрузки систе м ы , см. в главе 2 .

Ограничьте общий охват вашей системы. Чем меньше пакетов, тем меньше уязвимостей. В целом отрасль начинает решать эту проблему, уменьшая количество пакетов, включен ­ ных в стандартную установку. Некоторые специализированные дистрибутивы, такие как CoreOS, доводят это до крайности и вынуЖДают почти все пакеты работать в контейнере.

Удаленная регистра ция событий W Дополнительную информацию о протоколе Syslog с м . в главе 1 0 . Служба Syslog напрааляет регистрационную и н формацию в файл ы , списки пол ьзо­ вателе й и другие хосты сети. Попробуйте настроить хост, отвечающи й за безопасность, так, чтобы он действовал как центральная регистрационная машина, анализирующая получ ен н ые события и в ыпол няющая соответствующие действия. Един ы й централизо­ ванн ы й регистратор событий м ожет получать сообщения от разных устройств и пред­ упреждать адми н истраторов о важных событиях. Удале н ная регистрация также предот­ вращает перезапись или очистку регистрационных файлов во взлом ан н ых системах. Большинство систем поставл яется с конфигураци е й , в котором служба Syslog вклю­ чена по умолчани ю , н о дл я вкл юч е н ия удаленной регистрации необходимо выпол нить допол нительную настройку.

Глава 27. Безопасность

993

Резервные коп и и Регул ярное резервное копирование я вляется важной частью с исте м ы безопасности любой сети. Оно входит в так называемую триаду CIA и относится к категори и «доступ ­ ность» . Убедитесь, что все части системы регулярно коп ируются и что эта и н формация хранится в надежном месте (желательно за пределам и сети орган изации). Есл и произой­ дет серьезный инцидент, с вязан н ы й с безопасностью сети , вы с можете воспол ьзоваться надежн ы м источн и ком и нформации и восстановить работу. Резервное коп ирование само по себе также может создавать угрозу безопасн ост и . Защитите свои резервн ые копи и , огран ичив и поставив под контрол ь доступ к файлам резервных копи й , а также обеспечьте их ш ифрование.

Ви русы и черви Систе м ы U N I X и Linux и м е ют и ммун итет о т вирусов. Существует всего нес колько вирусов (большинство из н и х носит ч исто академический характер) , которые могут за­ разить с исте м ы U N IX и Linux, но н и оди н из н их не с пособен нанести серьезн ы й урон , в отличие от среды Windows, где это стало частым я вл е н и е м . Те м н е м е н ее этот факт не сн ижает озабочен ности поставщиков антивирус н ых програм м — разумеется , есл и в ы покупаете их продукт п о специал ьной с н иженной цене. Точ ная причина отсутствия вредонос н ых программ неясна. Н е которые утверждают, что система U N IX просто зан и мает сли ш ком незнач ител ьную долю р ы н ка настольных систем и поэтому не интересует авторов вирусов. Другие н астаивают на том , что среда с контролем доступа, существующая в с истеме U N IX, ограничивает размер урона от са­ морасп ространяющихся червей или вирусов. Последний аргумент заслуживает внимания. Поскольку в с истеме U N IX ограничен до­ ступ по записи к испол няемы м модулям на файловом уровне, непривилегированные поль­ зователи не могут инфицировать остальную среду. Если код вируса был запущен не от име­ ни суперпол ьзователя, его вред будет существенно ограниче н . Следовательно, не н ужно использовать учетную запись root для повседневной деятельности. Ком ментарии по этому поводу см. в разделе 3.2. W Дополнительную и нформацию о сканировании содержи мого электронных сообще н и й с м . в главе 1 8 .

Ка к н и странно, одна из прич и н внедре ния антивирус ного програ м м ного обеспече­ ния н а се рверах U N IX стре мление защитить работающие под управл е н ием Windows ком п ьюте р ы , существующие в ваш е й сети , от Wi ndоws-орие нти рован н ы х вирусов . Почтовый сервер может сканировать входя щую электрон ную почту н а вирус ы , а файло­ вый сервер в поис ках » инфекци и » может сканировать общие файл ы . Однако это реш е ­ н ие должно быть допол н ител ьн ы м по отноше н и ю к антивирусной защите настольн ых систем , а не основ н ы м . П рограмма ClamAV, написан ная Томашем Коймом (Tomasz Koj m ) , — это популяр­ ная свободно распространяемая антивирусная программа дл я с истем U N IX и Linux. Она ш ироко ис пользуется в качестве пол ноце н ного антивирусного программного обеспече­ ния, которое хранит сигнатуры тысяч вирусов. Н овейшую версию этой программы мож­ но загрузить с сайта c l amav . n e t . Конечно, можно утверждать, что антивирусное программное обеспечение само п о себе является контрпродуктивным. Его показатели обнаружения и профилактики я вляются посредствен н ы м и , а стоимость л и цензи рован ия и управления я вляется обре мен итель-

994

Часть lV. Эксплуатация

ной . Сл и ш ком часто антивирусное программное обеспечение нарушает другие аспек­ ты систе м ы , в резул ьтате чего возникают различные проблемы техн ической поддержки. Н е которые сбои даже был и вызваны атаками на саму антивирусную и нфраструктуру. Н едавние верси и систе м ы Microsoft Windows вкл ючают базовый антивирус н ы й и н ­ струмент под названием Windows Defender. Это н е самы й быстрый способ обнаружен ия новых форм вредоносного п рограмм ного обеспечения, но он эффе кти ве н и редко вме­ ш ивается в друrие аспекты системы.

Руткиты Умел ые хакеры п ытаются с кр ывать свои следы и избегать разоблач е н и я . Часто он и рассч итывают продолжить использован ие вашей системы для нелеrального распростра­ нен ия программного обеспечения, зондирования других сетей или запус ка атаки п роти в других с исте м . Дл я того чтобы оставаться незамече н н ы м и , о н и часто испол ьзуют так на­ зываем ые «руткиты » ( » rootkits»). Печал ьно известная фирма Sony вкл ючала элеме нты , подобные руткиту, в программ ное обеспечение для защиты от копирован ия , поме щае­ мое на м иллион ы музыкальных ком пакт-дисков. Руткиты — это програм м ы и заплатки , скрывающие важную систе м ную и н фор­ мацию , например процесс , диск или сетевую активность. О н и и м е ют м н о го обл и ч и й и разную степен ь сложности — о т простых замен приложе н ия ( например, взломанные верс и и утилит l s и ps) до модулей ядра, которые практически невозможно выявить. Для эффективного монитор и н га систем ы и выявлен и я внедрен н ых руткитов суще­ ствует спе циал ьное програм мн ое обес печени е , например O S S EC. Разработан ы также средства контроля целостности файлов, такие как AI D E для Linux, которые предупреж­ дают о н еожиданно и зм е н е н н ых файлах. Кроме того, разработан ы сценарии распозна­ вания руткитов (такие как chkrootkit, c h k r o o t k i t . o rg ) , сканирующие с истему в по­ исках известных руткитов. Н есмотря н а существование программ , позволяющих систе м н ы м адм и н истраторам удал ять руткиты из взломан н ых систе м , вре м я , которое они вынужде н ы затрач ивать на оч истку с исте м , можно было бы сэкономить, сохран и в дан н ы е , переформатировав диск и начав работу с нуля. Большинство совреме н н ых руткитов знают о существован и и програ м м для их удален ия и п ытаются оказывать этому сопротивление.

Фил ьт рация пакетов Если вы подключаете с истему к сети, имеющей доступ к И нтер нету, в ы должны уста­ новить между с истемой и внеш н и м м иром маршрутизатор с возможностью фильтрации пакетов или межсетевой экран (брандмауэр) . Фильтр пакетов должен передавать только трафик, предназна че н н ы й для тех служб , которые вы с пециально хотите предоставить пользователя м из внешнего м ира. Ограничение открытости ваш их систем дл я внешнего м и ра — это первая л и н и я защиты. М ногие систе м ы не обязательно должны быть до­ ступны из открытого сегмента И нтернета. Кроме специализированн ых средств, типа межсетевого экрана, работающих на и н ­ тернет-шл юзе, вы можете удвоить защиту с помощью пакетн ых фил ьтров, работающих на кон кретном хосте , таких как ipfw для системы Free B S D и iptaЬles ( ил и ufw) для систе м Linux. Определите , какие службы запускаются на хосте , и откры вайте порты только дл я этих служб. В н екоторых случаях вы также можете определить, какие адреса отправителя пакетов разреш е н ы для подключе н и я к каждому порту. Для большинства с истем требуется открыть всего несколько портов.

Глава 27 . Безопасность

995

Если ваш и с исте м ы находятся в облаке , вы можете испол ьзовать групп ы безопасно­ сти , а н е физические брандмауэры . При разработке правил группы безопасности будьте как можно более внимательными к детал я м . П одумайте о добавлен и и правил для фил ь­ траци и исходящих пакетов, чтобы ограничить возможность злоум ышл ен н и ка совершать исходящие подключе н и я с ваших хостов. W Дополнительную и нформацию по этой теме см. в разделе 1 3. 1 5 , посвященном облачным платформам.

Пароли и многофакторная аутентифика ция М ы — п росто л юди, подчиняющиеся простым правилам . Вот одно из н их: у каждой учетной записи должен быть пароль, который нелегко угадать. П равила, устанавл и ва­ ющие определ е нную сложность п арол я , могут создавать обыч н ы м пол ьзователя м н е ­ которые неудобства , но они должны существовать по ряду прич и н . Л е гко угадываемые пароли я вл я ются одни м из основных источн и ков компрометации . Одной из наших л юбимых тенденций последн их лет является распространение под­ держки систем м ногофакторной аутентификации (multifactor autentication — M FA) . Эти схемы подтверждают вашу личность как тем , что вы знаете (пароль или кодовую фразу), так и тем, что у вас есть, например физическое устройство, обычно мобильный телефон . Почти л юбой и нтерфе йс может быть защищен с помощью M FA — от учетн ых записей оболочки U N IX до бан ковских счетов. Поддержка M FA — это легкая и большая победа в области безопасности. По разн ы м причинам механизм M FA те перь я вляется абсол ют н ы м м и н и мал ь н ы м требован ием дл я л юбого и нтерн ет-портала, которы й предоставляет доступ к адми н и ­ стративн ы м при вилегия м . Он вкл ючает в себя VРN -тун нел и , S S Н -доступ и адм и н и ­ стратив н ые и нтерфейсы для веб-приложен и й . М ожно утверждать, что однофакторная (тол ько с помощью пароля) аутентификация неприемлема для любой аутентификации пол ьзователя , но вы должны как минимум обес печить защиту всех адм и н истративных интерфе йсов с помощью механ изма M FA. К счастью, сейчас доступн ы отличные облач­ н ые службы M FA, такие как Google Authenticator и Duo ( duo . com).

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

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

Часть lV. Эксплуатация

996

Уровен ь безопасности определяется уязви мостью самого слабого зве н а в цепоч ке. Если у вас есть безопасная сетевая и с истемная и нфраструктура, но прил ожен и е , рабо­ тающее в этой инфраструктуре , обеспечивает доступ к конфиден циальны м дан н ы м без пароля (например), вы выиграли битву, но проиграли войну. Тестирова н и е н а прон и к н о ве н и е я вл яется плохо о предел е н н о й д ис ц и пл и н о й . М ногие компан и и , которые рекламируют свои услуги п о тестирова н и ю приложе н и й н а проникновение, в основном «мухл ю ют». Голл ивудские сцен ы с подростками, с идя щ и м и в подвалах без око н , заполненных терм иналам и эпохи 1 980-х годов , н е так уж и неточ­ н ы . П оэтому будьте всегда на чеку! К счастью, проект Open Web Application Security ( OWAS P) п убл и кует и нформацию об общих уязвимостях, найде н н ых в приложениях, и м етодах зондирования приложе­ н и й для выявления этих проблем. Наша рекоме ндация: обратитес ь к профессионал ьной компани и , которая специализируется на тестировани и приложен и й на проникнове н и е , и выполняйте этот тест при первом запуске приложения, а также периодически на про­ тяжении всего срока его службы . Убедитесь, что сотрудни к и компан и и придерживаются методологии OWASP.

2 7 4 ПАРОЛ И И УЧ ЕТНЫ Е ЗАПИСИ ПОЛ ЬЗОВАТЕЛЕЙ .

.

Кроме обес печения привилегированного доступа с о сторон ы И нтернета с помощью м ногофакторной аутентификац и и важн о безопас но выбирать и управлять парол я м и . В м ире sudo личные пароли админ истраторов так ж е важ н ы , к а к и пароли root. Более того: чем чаще испол ьзуется пароль, тем больше возможностей для е го ком прометаци и с помощью методов, отл ич н ых от деш ифрования методом прямого п еребора. С узкоспециальной точк и зрения наиболее безопасный пароль заданной длины состо­ ит из случайной последовател ьности букв, знаков препинания и цифр. Годы пропаганды и придирчивые форм ы проверки паролей на веб-сайтах убедили большинство л юде й , что это именно тот вид пароля , которы й они должны использовать. Но, конечно, они н икогда так не поступают, если тол ько не используют хранил и ще паролей для их запоминан и я . Случайные пароли просто непрактичн ы для фиксации в памяти при дл и нах, необходимых для противодействия атакам прямым перебором ( 1 2 символов ил и бол ьше). W Дополнител ьную информацию о взломе паролей см . в разделе 27.5. П ос кольку безопасность паролей увеличи вается экспон е н циально с дли н о й , луч ш е всего испол ьзовать оче н ь дли н н ы й парол ь (» кодовую фразу » ) , который вряд л и появит­ ся в другом месте , но е го легко запом нить. Для пущей надежности можно сделать пред­ намеренную опечатку или орфографическую ошибку, но общая идея закл ючается в том , чтобы использовать большую длину пароля и при этом не напрягать память. Например, отличная кодовая фраза — » шесть гостей выпил и отраменн ое вино Эви » . ( Ил и по крайней мере так бьmо до тех пор, пока она не появилас ь в этой книге.) Это прав­ да, несмотря на то, что пароль состоит в основном из простых, строчных, грамматически правил ьных слов и при этом слова логически связаны и грамматически упорядочены. Другая ос н о в н ая кон це п ц и я , которую должн ы уч итывать все адм и н истраторы и пол ьзователи , закл ючается в том , что ни одна кодовая фраза н икогда не должна ис­ пользоваться более чем дл я одной цел и . Сл и ш ком часто происходят крупн ы е взломы и имена пользователей с паролями оказываются рас крытым и . Если эти и мена пользова­ телей и пароли испол ьзовались в других местах, все эти учетн ые зап иси теперь подвер ­ гаются рис ку. Н икогда не испол ьзуйте один и тот ж е п ароль для разн ых целей (напри­ мер, в банковском л ич ном кабинете и социальных сетях).

Глава 27. Безопасность

997

Изменен ие п а роля Изменение паролей суперпол ьзователя root и адми н истраторов должно происходить: •

не реже одного раза в шесть меся цев;

каждый раз, когда кто-то, у кого есть доступ к ним, покидает вашу орган изацию;

вся кий раз, когда вы сомневаетес ь в безопасности.

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

Х ра нилища и депоненты па рол ей Часто говорят, что парол и » н и когда не должны записываться » , но, возможно, точнее был о бы сказать, что они н икогда не должны оставаться доступ н ы м и для л юде й , кото­ рые не имеют на это права. Как заметил эксперт по безопасности Брюс Ш найер ( Bruce Schneier) , клочок бумаги в кошел ьке адм и н истратора относ ител ьно безо пасен по срав­ нению с больш инством форм интернет-хранил и ща. Хран ил и ще паролей представляет собой часть програм м ного обеспечения (или со­ четание програм м ного и аппаратного обеспеч е н и я ) , в котором парол и для ваш е й орга­ н изации находятся в большей безопасности , чем после ответа на вопрос » Хотите , чтобы Windows запо м н ила этот парол ь для вас?» Хра н илище паролей стало практически необходим ы м вследствие нес кольких обсто­ ятельств. •

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

Систе м ы управления пароля м и стал и более популяр н ы м и в свете законодател ьства С ША, которое наложило дополн ительные требования к таким секторам , как правитель­ ство, финансы и здравоохран е н и е . В не котор ых случаях это законодател ьство требует м ногофакторной аутентификаци и . Хранил ища паролей также являются отличным решением дл я компаний, предоставляю­ щих услуги системного администрирования, которые должн ы безопасно и прозрач но управ­ лять паролями не только к собствен ным машинам, но и к комп ьютерам своих клиентов. Парол и хранятся в хранилищах паролей в заш ифрован ном виде. Как правило, каждый пользовател ь имеет отдел ьн ый пароль для доступа к хранил и щу. ( Есл и вы сч итал и , что ваши парольные муки уже закончил ись, то теперь у вас есть еще больше паролей для от­ слеживания и беспокойства!)

998

Часть lV. Эксплvатация

Доступн ы м ногие реал изации хранили щ паролей. Бесплатные хранил ища для част­ н ых лиц (например, Kee Pass) локально хранят парол и , предоставляют доступ к базе дан ­ н ы х паролей п о принципу » все или н ичего» и не требуют регистраци и . Устройства, под­ ходящие для огромных предприятий (например, CyberArk ) , могут стоить десятки тысяч долларов. Абонентная плата взимается л ибо в зависимости от коли чества пользовател е й , либо о т количества хранящихся паролей. М ы особенно л юбим хранилище паролей l Password компании Agile Bits ( l p a s s w o r d . com). Хранилище l Password появилось из м ира массового рынка , поэтому оно в ключает в себя тщательно отлаженные кросс-платформенные интерфе йсы и взаимодействие с обыч­ н ы м и веб-браузерами . Хранили ще l Password имеет » командный » уровень, расширяющий фундамент управления персональными паролями в области организационных секретов. Еще одн ой превосходной с истемой я вляется хра н ил и ще Secret Serve r компан и и Thycotic ( t h y c o t i c . c om). Эта с истема основана на браузере и была разработана с нуля для удовлетворения потребностей организаци й . Она включает расширенные фун кции управления и аудита наряду с контролем доступа на основе ролей (см . раздел 3.4) и мел­ комасштабных разрешений. Одна и з полезных функци й , которую нужно искать в с истеме управления парол я ­ м и , — это вариант «разбить стекло» , назван н ы й так в ч есть устройств пожарной сигна­ лизации отеля , на которых написано, что в случае чрезвычайной с итуации в ы должны разбить стекло и нажать на бол ьшую красную кнопку. В данном случае » разбить стекло» означает получение парол я , к которому вы обычно н е и меете доступа, при этом гром ­ кие сигналы тревоги пересылаются другим администраторам. Это хорош и й компромисс между расчетл и в ы м обменом парол я м и (нормал ьная передовая практика) и реал ия м и аварийного пожаротушения. Пл охое управление паролями приводит к общему ослаблению системы безопасности. По умолчани ю допуск в систему определяется содержимым файлов / etc/passwd и / etc/ shadow ( ил и файла /etc/master . pas swd в системе Free B S D ) , поэтому данные файл ы я вляются первой линией защиты системы от злоумышленников. Они должны быть тща­ тельно сохранены и свободны от ошибок, угроз безопасности и исторического багажа. W Дополнительную информацию о файле passwd см. в разделе 8 . 2 . Система U N I X позволяет пол ьзователям выбирать собственные парол и , и , хотя это оче н ь удобно, данн ая возможность порождает много проблем, связанных с безопасно­ стью. Ком ментари и в начал е раздела 27.4 также относятся и к паролям пользователе й . Важно регулярно (желательно ежедневно) проверять, что каждая учетная запись име­ ет пароль. Записи в файле /etc/ shadow, в которых описываются псевдопол ьзователи , такие как демо н ы , которые владеют файлами , н о н е должны входить в систему, должны и меть звездоч ку или воскл и цательный знак в поле своего зашифрованного пароля. Эти символы не соответствуют н икакому паролю и, таким образом, не позволяют использо­ вать учетную запись дл я входа в систему. В организациях, использующих централизован ную схему аутентифи кации, такую как LDAP или Active Diгectory, применяется такая же логика. Требуйте испол ьзовать слож­ н ы е пароли и блокируйте учетн ые записи после нескольких неудачн ых попыток входа в систему.

Уста рева н ие па ролей В большинстве систе м , испол ьзующих теневые парол и , можно реализовать механизм так называемого устаре ван ия парол е й , при котором пол ьзователей заставля ют перио-

Глава 27 . Безопасность

999

дически менять пароли . На первый взгл яд, это хорошая иде я , однако ее практическая реализация влечет за собой определен ные проблемы. Н е всякому пользовател ю по душе периодически ме нять парол ь, поскол ьку это сопряжено с запом инанием нового парол я . Обычно для парол я выбирается простое слово, которое легко вводится и запоминаетс я , и , когда приходит врем я заме н ы , м ногие пол ьзователи , не желая себя утруждать, сно­ ва выбирают предыдущи й парол ь. Таким образом, дискредитируется сама идея . Модул и РАМ могут помоч ь выбрать сил ьные парол и , чтобы избежать описан ной выше с итуации (см . раздел 1 7. 3 ) . В системе Linux процессом устаревания паролей управляет программа chage. С ее помощью адм и н истраторы могут задавать м и н и мал ьное и максимал ьное время, которое проходит до момента изменен ия пароля ; дату истече н ия сро­ ка действия парол я ; кол и чество дней до наступления даты истечения срока действия пароля, когда следует заблаговременно предупредить пользователя ; количество дней бездействия пол ьзователя , после истечения которых учетная запись автоматически блокируются; и другие параметры. Приведен ная ниже команда задает м и н и мал ьное количество дней между изменен и я м и пароля равн ы м 2 , а максимальное количество дней равным 90, дату истечения срока действия пароля равной 3 1 и юля 20 1 7 года, а также то, что пол ьзователя сле­ дует предупредить об истечен и и срока действия пароля за 14 дней. l i nu x $ sudo chage -m 2 -м 90 -Е 2 0 1 7 — 0 7 — 3 1 -W 1 4 ben

В с исте ме Free B S D устаре ван и е м паролей управляет команда pw. П р и ­ веден ная н иже команда задает срок действия парол я , равный 9 0 дня м , и дату истечен ия срока действия пароля — 25 сентября 20 1 7 года. f r e e b s d $ sudo pw user mod trent -р 2 0 1 7 — 0 9 — 2 5

90

Гру п п овые и совместно ис п ол ьзуемые учетные за п иси О пасно, если уч етная запись используется нескол ьким и л юдьми . Груп повые учетн ые зап иси (например, gue s t и demo) п редставля ют собой удобн ую лазей ку для ха керов, поэтому они зап реше н ы во многих сетях федерал ьн ы м и законами , таки м и как H l PAA. Не допускайте этого в своей сети . Однако техн ические средства не м огут предотвратить совместное испол ьзование учетных зап исей разн ы м и пол ьзователя м и путе м сообщения паролей, поэтому в дан ном вопросе лучше всего вести разъяснител ьную работу.

Пол ьзовател ьские оболочки Теоретически можно установить в качестве оболоч ки дл я пользовател ьской учетной за­ писи л юбую программу, вкл ючая пользовател ьс кий сценарий. На п рактике применение оболочек, отличающихся от стандартных, таких как bash и tcsh , весьма опасно. Е ще опаснее беспарольн ые учетн ые запис и , оболоч кой которых я вляется сце нарий. Есл и у вас возн и кнет соблазн создать такую учетную запись, примен ите вместо пароля ключи S S H .

Привилегированные учетн ые за п иси Единстве н ная отл ич ител ьная ч ерта пол ьзователя r o o t состоит в том , что е г о U l D раве н О. П оскольку в файле /etc/pas swd может быть нескол ько зап исей с таки м иде н­ тифи катором , существует и нескол ько способов входа в систему в качестве суперпол ь­ зователя root.

1 000

Часть lV. Эксплуатация

Оди н из с пособов, который хакер ы , получи в доступ к командной оболочке от и м е н и пол ьзователя root, ш и роко применяют для открытия «черного хода» , — редакти рова­ ние файла /etc/pas swd. П оскол ьку такие команды , как who и w, работают с регистра­ цион н ы м и м е не м , храня щ и мся в файле u tmp , а не с идентификатором пользователя , зарегистрировавшегося в командной оболочке, о н и н е в состоян и и разоблачить хакера, которы й выглядит как рядовой пол ьзователь, хотя на самом деле зарегистрирован в си­ стеме в качестве суперпол ьзователя с U I D равным О. Не допускайте удал е н н ы е подкл юче н и я суперпол ьзовател е й , даже через стандарт­ ную учетную запись root. Для того чтобы это запретить, следует с помощью оболоч­ ки OpenS S H установить в файле / e t c / s s h / s shd_conf i g парам етр кон ф и гураци и P e rmi t Ro o t Lo g i n рав н ы м N o . Благодаря программе sudo (см. раздел 3 . 2 ) необходимость подключаться к систем е в качестве суперпол ьзователя root, даже с системной консол и , возни кает редко.

2 7 . 5 . ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ЗАЩИТЫ Для реш е н и я задач , упо м и навш ихся в предыдущи х разделах, можно испол ьзовать свободно распространяемые программы. Н иже будут рассмотрен ы наиболее и нтересные из них.

Кома нда nmap: ска нирование сетевых портов Эта команда я вляется сканером сетевых портов. Ее основное н азначен ие — проверка указа н н ых ком пьютеров на п редмет того, какие ТСР- и U DР-порты на них прослуш и ва­ ются серверн ы м и программ а м и . 2 За большинством сетевых служб закреплен ы » извест­ н ы е » порты , поэтому такая информация позволяет узнать, какие про грамм ы выпол н я ­ ются на ком пьютере. Запуск команды nmap — отл и ч н ы й способ узнать, как в ы глядит с исте м а в глазах того, кто п ытается ее взломать. В качестве примера приведем отчет, выданный этой ко­ мандой на самом обычном , относительно незащищенном компьютере. ubun t u $ nmap -sT uЬuntu . booklaЬ . atrus t . com S t a r t i n g Nmap 7 . 4 0 ( h t tp : / / i n s e cu r e . o r g } at 2 0 1 7 — 0 3 — 0 1 1 2 : 3 1 M S T I n t e re s t i n g p o r t s on ubuntu . bo o k l ab . a t ru s t . com ( 1 9 2 . 1 6 8 . 2 0 . 2 5 ) : N o t s h own : 1 6 9 1 c l o s e d p o r t s PORT S TAT E S E RV I C E 2 5 / t cp open smtp open http 8 0 / t cp rpcbind open 1 1 1 /tcp open netbios — s sn 1 3 9 /tcp mi c r o s o f t -d s open 4 4 5 / t cp 3 3 0 6 / t cp open mysql Nmap f i n i s h e d : 1 I P addr e s s ( 1 h o s t up } s c anned i n 0 . 1 8 6 s e conds

Аргумент -sт сообщает ком а нде nmap о н еобходимости подклю читься к каждом у ТСР- порту на указан ном хосте . 3 Как только соедин е н ие устанавл и вается , команда nmap 2 Как объяс н ялос ь в разделе 1 3 . 3 , порт — это н умерованный канал взаимодействия . I Р-адрес иде н­ тифи цирует весь ком пьютер, а комбинация I Р-адреса и номера порта определяет кон кретны й сер­ вер или сетевое соединение. 3 На самом деле по умолчанию проверяются только при вилегированн ые ( их номера меньше 1 024) и » известные » порты. С помощью опции -р можно явно задать диапазон сканирован ия.

Глава 27. Безопасность

1 001

немедл е н н о откл ючаетс я , что не очен ь корректно, зато безболезне н н о для правил ьно написанного сетевого сервера. Как следует из примера, на хосте u b u n t u выпол н я ются две служб ы , я вля ющиеся тради цион н ы м и источ никами проблем для безопасности систе м ы : portmap ( rp c Ь i n d ) и почтовый сервер ( s m t p ) . Это наиболее вероятн ые места дл я атаки хакеров на этапе предварител ьного сбора и нформации об атакуемом хосте. Столбец S TATE (состояние) содержит запись open (открыт) для портов, с которы м и связаны сервер ы , closed (закрыт) для портов, с которы м и не с вяза н ни оди н сервер, запись unfiltered ( нефил ьтруемый) для портов, пребывающих в н еизвестном состоя­ нии , и запись filtered (фил ьтруем ы й ) для портов, доступ к которы м невозможен из-за наличия брандмауэра. Утилита nmap классифицирует порты как unfiltered только при АСК-сканировании. Вот, например, резул ьтат за проса к более защищенному ком мерче­ скому неб-серверу s e cu r e . b o o k l a b . а t ru s t . с от. ubun t u $ nmap — sт secure . booklaЬ . atrust . com S t a r t i n g Nmap 7 . 4 0 ( h t tp : / / i n s e c u r e . o r g ) at 2 0 1 7 — 0 3 — 0 1 1 2 : 4 2 MST I n t e r e s t i n g p o r t s on s e cu r e . b o o k l ab . a t r u s t . c om ( 1 9 2 . 1 6 8 . 2 0 . 3 5 ) : N o t s ho wn : 1 6 9 1 c l o s ed p o r t s PORT S TATE S E RV I C E 2 5 / t cp open smtp http open 8 0 / t cp Nmap f i n i s he d : 1 I P addre s s ( 1 h o s t up ) s c anned i n 0 . 1 4 3 s e c on d s

В дан ном случае очевидно, что комп ьютер сконфигурирован на обработку эле ктрон­ ной почты по протоколу SMTP и работу с сервером НТТР. Брандмауэр блокирует доступ к остал ьным портам. П о м и мо стандартного опроса ТС Р- и U D Р- портов, команда nmap с п особна про­ верять порты » по-хакерс ки » , не устан авл ивая с ними реал ьного соеди нения. В бол ь­ ш инстве случаев посылаются пакеты , которые похожи на пакеты из уже и ме ющегося ТС Р-соединения (т.е. не пакеты установки соедин е н и я ) , а затем проверяются получ е н ­ н ые в ответ диагностические пакеты . Таким способом можно обойти брандмауэр или программу мон итори н га сети, которая контрол ирует появле ние с канеров портов. Если в вашей организации имеется брандмауэр (см. раздел 27 . 7) , н е поленитесь п роверить е го в разн ых режи мах сканирования. Команда nmap обладает м агической способностью угады вать, какая операционная система установлена на удален ном хосте. Это делается путем анал и за деталей реализа­ ции стека TC P/ I P. Чтобы проверить работу команды nmap в этом режим е , воспол ьзуй ­ тесь параметром -о, например. ubun t u $ sudo nmap — sV -О secure . booklaЬ . atrus t . com S t a r t i n g Nmap 7 . 4 0 ( h t tp : / / i n s e c u r e . o r g ) at 2 0 0 9 — 1 1 1 1 2 : 4 4 MST I nt e r e s t i n g p o r t s on s e cu r e . boo k l ab . a t ru s t . c om ( 1 9 2 . 1 6 8 . 2 0 . 3 5 ) : N o t s hown : 1 6 9 1 c l o s ed p o r t s VERS I ON S E RV I C E PORT S TATE 2 5 / t cp open smtp P o s t f i x smtpd 8 0 / t cp open http l i gh t tp d 1 . 4 . 1 3 D e v i c e t yp e : g e n e r a l p u r p o s e Runn i n g : L i nux 2 . 4 . Х 1 2 . 5 . Х 1 2 . 6 . Х OS d e t a i l s : L i n u x 2 . 6 . 1 6 — 2 . 6 . 2 4 Nmap f i n i s h e d : 1 I P addre s s ( 1 h o s t up ) s c anned i n 8 . 0 9 5 s e c o n d s

Часть lV. Эксплvатация

1 002

Эта возможность может оказаться весьма полезной при анализе состоян и я локаль­ ной сети. К сожал е н и ю , она же я вляется рабоч и м инструментом хакеров, которые могут определить тип атаки на основании известн ых слабых мест кон кретн ых операцион н ых с истем или серверов. Не забывайте та кже , что бол ьши нство адм и н истраторов н е при ветствуют попыток с канирования сети и выяснения ее слабых мест, какими бы благородными ни бьm и мо­ тивы. Н икогда не запускайте ком а нду nmap в чужой сети без разреш е н ия сетевого адм и ­ н истратора.

Nessus: сетев о й с канер н ового п околения В 1 998 году Ре но Дерезон ( Re naud D e raison) вы пустил и н терес н ы й пакет N essus, в котором реал изуются м ногие фун кциональн ые возможности сканера. О н использует более 3 1 000 надстроек для проверки локальных и удаленных дефектов. Несмотря на то что эта программа и меет закрыты й код и я вляется ком мерческим продукто м , она с во­ бодно ра с п ро страняе тс я и для нее регулярно появля ются новые надстрой к и . Это наи­ более широко распространенн ы й и пол н ы й из доступных с канеров. П рогра м м а Nessus это сетевой сканер, который н ичему не доверяет. Вместо того чтобы предполагать, к п р и меру, будто все веб-серверы работают через порт 80, он и щет веб-серверы на л юбом порту, а затем анал изирует их слабые места. П рограмма не дове­ ряет даже номеру верс и и , о котором сообщает сам сервер , проверяя все известные сла­ бы е м еста, чтобы понять, наскол ько уязвим сервер. Для первого запуска програ м м ы N essus требуется потратить немало усили й ( н еобхо­ димо установить м ного пакетов, которые не входят в стандартный дистрибутив) , но ко­ нечн ы й результат того стоит. Система Nessus состоит из клиента и сервера. Сервер и гра­ ет рол ь базы данн ых, а кл иент отвечает за графический пользовательск и й и нтерфейс. Серверы и клиенты могут работать на платформах UNIX или Windows. Одни м из главных преимуществ програ м м ы N essus я вляется ее модульная структу­ ра, позволяющая сторонним разработч икам добавлять собствен н ые модули проверки . Благодаря активности сообщества ее пол ьзователе й эта программа с может быть полез­ ной дол гое вр ем я —

.

Metasploit: п р о грамма для выявления п о п ыток п роникновения П роверка про никновения это выявление попыток проникновения в ком п ьютер­ ную сеть с разре ш е н и я владел ьца с целью обнаруже ния слабых мест в ее системе без­ опасности Metasploit это программ н ы й пакет с открытым исходным кодом, написан­ ный на языке Ruby, который автоматизирует данн ы й процесс. Программ а Metasploit контрол ируется американской охран ной компанией Rapid7, но е е п роект Git Hub соде рж и т сотн и участ н и ков. M etasploit включает базу дан н ы х сотен готовых програ м м по испол ьзован и ю известн ых уязвим ых мест п рограммного обесп е ­ ч е н и я . Те , у кого есть желание и умени е , могут добавить в базу дан н ых настраиваем ы е допол нительные модул и Metasploit использует следую щи й основной рабочий процесс. —

.

.

1 . Скан ирует удал е нн ые систе м ы , чтобы узнать и нформацию о н их. 2 . Выбирает и в ыпол н яет п ро грам м ы дл я испол ьзования уязвимых мест в соответ­ стви и с найде н ной и нформацией. 3. Если произошло проникновение, использует поставляемые программ н ые средства для откл ючения с ком прометированной системы и переходит к другим хостам в уда­ ле нно й сети.

Глава 27. Безопасность

1 003

4. Формирует отчеты для докуме нтирования результатов. 5 . Очищает и возвращает все внесенные в удален ную систему изменения в исходное состоя н ие . П ро гра м м а M etasploit им еет н е с кол ько и н терфейсов: командную строку, веб­ интерфейс и полноценный графический пользовательский интерфейс. Выберите формат, который вам больше всего нравится; все он и имеют эквивалентную фун кциональность. Узнайте бол ьше на сайте me t a s p l o i t . с от.

Lynis: встроен н ый аудит безопасности Есл и вам когда-л ибо приходилось искать дырки в стенах старого деревян ного сарая , наверняка вы сначала проходил и по е го наружному периметру и искали больш и е , зия­ ющие отверстия . Сетевые средства сканирова н ия уязвимостей , такие как Nessus, дают вам подобное п редставление о профиле безопасности систе м ы . И сследование стен из­ нутри сарая в солнеч н ы й и яс ный ден ь позволяет выявить оче н ь малые отверстия в них. П оэтому чтобы получить такой же уровен ь проверки систе м ы , вам нужно программное средство, наподобие Lyпis, которое запус кается в самой системе. Н есмотря на свое неудач ное н азвани е , эта утилита проверк и систе м ы безопасности выпол няет как разовые, так и плановые проверки состоя ния конфигураци и с исте м ы , примененных заплаток и м е р по усилени ю безопасности. Эта программа с открыты м ис­ ходны м кодом работает в системах Linux и Free B S D и выполняет сотни автоматических проверок уязвимостей. Утилиту Lynis можно загрузить по адресу c i s o f y . c om / l yn i s .

Joh n t h e Ripper: средство для выя вления слабых паролей Один из способов пресечь испол ьзование плохих паролей закл ючается в том , что­ бы самостоятел ьно взломать парол ь и заставить пол ьзователя выбрать другой. John the Ripper это сложная программа, разработанная компанией Solar Designer, которая ре ­ ализует разные алгоритмы взлома паролей в виде единого инструме нта. Она заменила программу crack, которая была описана в предыдущем издани и книги. Н есмотря на то что в большинстве систем испол ьзуется файл теневых паролей, что­ бы с крыть заш ифрова н н ые п арол и от публ и к и , целесообразно проверять, что парол и пол ьзователей я вляются устойчивы м и ко взлому.4 Знание п ароля п ол ьзователя может оказаться полезны м , потому что люди предпочитают все время испол ьзовать оди н и тот же пароль. Единстве н н ы й парол ь может обеспечить доступ к другой с истеме, расшиф­ ровать файл ы , храня щиеся в рабочем катал оге , и открыть доступ к финансовым счетам в сети веб. ( Н е стоит и говорить, что использовать парол ь таким с пособом оче н ь глупо. Однако н и кто не хочет запоминать десять разных паролей . ) Н есмотря на свою внутрен н юю сложность, программа J o h n t h e Ripper весьма проста в испол ьзова н и и . Достаточ но просто нацел ить программу j ohn на файл , подлежащий взлому, чаще всего /etc/ shadow, и произойдет чудо. —

$ sudo . / j ohn /etc/ shadow Loaded 2 5 p a s s w o r d h a s h e s w i t h 2 5 d i f f e r e n t s a l t s ( Fr e e B S D MD5 [ 3 2 / 3 2 ] ) p a s s w o r d ( j smi t h ) badp a s s ( t j on e s )

В этом примере из те невого файла были сч итан ы 25 у н и кал ьн ы х парол е й . П осле взлома парол я программа John вы водит е го на экран и сохраняет в файл j ohn . po t. •особенно это относится к паролям системн ых адми н истраторов, и меющи х при вилеги и sudo.

1 004

Часть lV. Эксплvатация

Этот вы вод содержит парол ь в левом столбце и ре гистрацион ное и м я пол ьзователя в с кобках в правом столбце . Для просмотра паролей после завершения работы програм­ мы j ohn следует выпол н ить ту же самую команду с аргументом — show. На момент выпуска русского издания книги самой новой версией програм м ы John t he Ripper была версия 1 . 9 . 0 . Она доступна н а сайте o p e n w a l 1 . com/ j o h n . Поскол ьку вывод програ м м ы содержит взломанные парол и , его следует тшательно охранять и уда­ лить сразу же после н ахождения слабых паролей пользователей. Как и для большинства других методов мон иторинга безопасности , перед взломом паролей с помошью програм м ы John the Ripper необходимо получить одобрение руко­ водства.

Bro: п рограммная система для распозна ва ния вторжения в сеть Система с открытым исходным кодом B ro предназначена для распознавания вторже­ ний в сеть (network intrusion detection system — N I DS). Она выпол няет монитор и н г сети и следит за подозрительной активностью. Эта система была написана Верном Паксоном (Vern Paxson) и доступна на сайте b r o . o r g . Система Bro проверяет весь трафик, поступающий в сеть и исходящий из нее. О н а мо­ жет функционировать в пассивном режиме, генерируя предупреждения о подозрительной активности , или в активном режиме, в котором она пресекает враждебные действия. Оба режима, скорее всего, потребуют внесения изменений в конфигурацию вашей сети. В отличие от других систем N I DS, система Bro отслеживает потоки трафика, а не просто сопоставляет образцы внутри отдельных пакетов. Это значит, что система Bro может рас­ познавать подозрительную активность, основываясь на информации о том , кто с кем гово­ рит, даже не сравн ивая н и каких строк или шаблонов. Например, система Bro может решать следующие задачи . •

• •

Распознавать систе м ы , и спользующие » мостик и » ( » stepping stones » ) , определяя корреляцию м ежду входящим и исходящим трафиками. Распознавать сервер, имеющий и н сталлирован ную лазейку, путем слежен и я за не­ ожидан н ы м и исходящ и м и соедине н ия м и , следующим и сразу же после входящего соединения. Распознавать протоколы , выполняемые на нестандартных портах. Сообщать о правильно угаданных паролях (и игнорировать неправильные предпо­ ложения).

Н екоторые из этих функционал ьных возможностей требуют существен н ых систем­ н ы х ресурсов, но с истем а B ro и меет поддержку кл астеризаци и , облегчающую управле­ ние группами машин , распознающих вторжение. Система B ro и меет слож н ы й язык конфигураци и , требующий значител ьного опыта кодирования. К сожал е н и ю , в системе не предусмотрен ы параметры стандартной кон ­ ф игураци и , которые можно было бы легко испол ьзовать новичкам . Для большинства с истем требуется выпол н ить довольно прил и ч н ы й уровен ь настроек. С исте м а до н екоторой сте п е н и поддержи вается Группой сетевых исследова н и й М е ждународного и нститута компьютерн ы х н аук ( N etworking Research G roup of the I nternational Computer Science l nstitute ( IC S I ) ) , но в бол ьшей степени она поддерживает­ ся сообществом ее пользователей. Если вы и щете готовую коммерческую систему N I DS , то, вероятно , будете разочарованы системой Bro. Одн ако о н а может делать то, что н е доступно коммерческим системам N I DS , и может служить допол н е н ие м и л и заменой ком мерческого продукта.

Глава 27. Безопасность

1 005

Snort: популярная программная система для распознавания п роникновения в сеть Система с открытым кодом Snort п редназначена для предотвращения и распозна­ ван ия несан кцион и рован ного прон икнове н ия в сеть; написана М арти Реш е м ( Marty Roesch) и в настоящее вре мя поддерживается ком мерческой ком пан ией Cisco ( s n o r t . o r g ) . О н а де-факто стала стандартом для кустарн ы х с истем N I DS , а также основной для м ногих коммерческих реализаций с истем N I DS с «управляе м ы м и услугами » . Сама по себе система Snort распространяется как пакет с открытым кодом . Однако ком пания Cisco взи мает плату за подписку на доступ к нове й ш и м п равилам рас позна­ ван ия . Бол ьшое количество платформ , созданных сторон н и м и производителями , включают в себя ил и экспортируют с истему Snort , причем н е которые из этих проектов явля ют­ ся програм мами с открытым кодом . Ярким п р имером я вляется проект Aanval ( a anva l . com) , собирающий данные от м ногочисле н н ых датчиков с исте м ы Snort на веб-консоль. Система Snort перехватывает пакеты из сетевого кабеля и сравнивает их с н аборами правил , которые называются сигнатурами. Когда с истема Snort распознает событие , ко­ торое представляет и нтерес, она может предупредить систе м н ого адм и нистратора или установить контакт с сетевым устройством и , помимо прочего, заблокировать н ежела­ тел ьн ы й трафик. Нес мотря на то что с истема Bro намного мощ нее , с истема Snort намного проще и легч е конфи гурируется , благодаря чему я вляется удачн ы м выбором для стартовой платформ ы N I DS.

OSSEC: система для распознавания вторжения в сеть на уровне хоста С истема O S S EC это свободно распространяемое программное обеспеч е н и е , до­ ступное в виде открытого исходного кода по л и цензии G N U ( General PuЫic License ) . О н а обеспечивает следующие фун кциональные возможности . —

Распознаван ие руткитов.

П роверка целостности файловой с исте м ы .

Анал из регистрационных файлов.

Выдача с игналов по рас писанию.

Акти вные реакци и .

С истема OSSEC работает в заданной операционной с истеме и отслеживает е е актив­ ность. Она может выдавать сигнал ы ил и предприн имать действия , предусмотренные на­ бором правил , которые устанавливает пользователь. Например, система OSSEC может вы­ пол нять мон иторинг операционных систем, чтобы выявить добавление неавторизованных файлов и отправить по электронной почте уведомление, похожее на приведен ное н иже. Subj e c t : O S S E C N ot i fi c a t ion — c o u r t e s y — Al e r t l ev e l 7 D a t e : Fr i , 0 3 Feb 2 0 1 7 1 4 : 5 3 : 0 4 — 0 7 0 0 From : O S S E C H I DS o s s e cm @ c o u r t e s y . a t ru s t . com Т о : < c o u r t e s y — admi n @ a t ru s t . com> OS S EC H I D S N o t i f i c a t i on . 2 0 1 7 Feb 0 3 1 4 : 5 2 : 5 2

1 006

Часть lV. Эксплуатация

Re c e i v e d F r om : c ou r t e s y — > s y s ch e c k Ru l e : 5 5 4 f i r e d ( l e ve l 7 ) — > » Fi l e added t o t h e s y s t em . » P o r t i on o f t h e l og ( s ) : New file ‘ / cou r t e s y /h t t p d / b a r k i ng s e a l . c om / h tml /wp ­ cont e n t / u p l o a d s / 2 0 1 0 / 0 1 / hb i rd . j pg ‘ added t o t h e f i l e s ys t em . — — EN D OF NOT I F I CAT I ON

Таким образо м , систем а O S S EC работает круглосуточно, следя за операционной с и ­ сте мой . М ы рекомендуем запускать OSSEC на каждом производствен ном компьютере.

Основные принципы системы OSSEC Система OSSEC состоит из двух основных ком понентов: менеджера (сервера) и аген­ тов (клиентов) . В сети нужен один менеджер, которы й необходимо инсталл и ровать пер­ вым. Менеджер хран ит базу данн ы х для проверки целостности файловой систе м ы , реги­ страционные :журнал ы , события , декодер ы , основные варианты конфигурации , а также записи об аудите систе м ы для все й сети. Менеджер может подключаться к любому аген­ ту O S S EC , независимо от его операционной с исте м ы . Менеджер также может отслежи­ вать работу о пределенных устройств, которые не имеют специального агента O S S EC . Агенты работают в с истемах, которые подвергаются монитори нгу, и сообщают и н ­ формацию м е неджеру. О н и имеют маленькую зону обслуживания и оперируют н еболь­ шим объемом привилеги й . Большую часть конфигурации агент получает от менеджера. Соединение между сервером и агентом зашифровано и аутентифицировано. Для каждо­ го агента менеджер должен создать отдельный кл юч аутентификации . Система O S S EC классифицирует серьезность сигналов по уровн я м о т О д о 1 5 ; ч исло 1 5 соответствует высшему уровню опасности.

Инсталляция системь1 OSSEC П акеты систе м ы O S S EC для основных дистрибутивов операционных систем доступ ­ н ы на сайте o s s e c . g i thub . i o . Сначала следует выполнить инсталляцию сервера OSSEC в предназначен ной дл я это­ го операционной системе, а затем инсталляцию агента во всех остальных с истемах, ко­ торы е будут предметом мон итори н га. Сценарий и нсталл я ц и и тоже задает несколько допол нительных вопросов, например , по какому адресу посылать уведомления и какие модули мониторинга следует подключить. После завершения инсталляции запустите систем у OSS ЕС с помощью следующей команды. s e rve r $ sudo /var/ ossec/bin/ossec- control start

Затем зарегистрируйте каждый агент у менеджера. Н аходясь на сервере , выполн ите следующую команду. s e rve r $ sudo /var/ossec/bin/manaqe_aqents

Вы увидите меню, которое будет выглядеть примерно так. **************************************** * OS S EC H I DS v2 . 8 Age n t manage r . * The f o l l ow i n g op t i ons a r e avai l aЫ e : ****************************************

Глава 27. Безопасность

1 007

( А ) dd an a g e n t ( А ) . ( E ) x t r a c t k e y f o r an a g e n t ( Е ) . ( L ) i s t a l r e a d y added a g e n t s ( L ) . ( R ) emove an a g e n t ( R ) . (Q) uit . Choo s e y o u r a c t i o n : A , E , L , R or Q :

Выберите пункт А, чтобы добавить агент, а затем н абер и те имя и I Р адре с этого аген­ та. Затем выберите пункт Е и извлеките кл юч агента. Вот как это выгл ядит. —

Ava i l aЫ e a g e n t s : I D : 0 0 1 , Name : l i nu x c l i e n t l , I P : 1 9 2 . 1 6 8 . 7 4 . 3 Provide the I D o f the agent t o e x t r a c t the k e y ( o r ‘ q ‘ t o qui t ) : 0 0 1 Ag e n t k e y i n f o rma t i on f o r ‘ 0 0 1 ‘ i s : MDAy I GxpbnV 4 Y 2 xp ZW 5 0MSAx OT i uMT Y 4 L j c 0 L j Mg Z j k 4 Y j My Y z l kMj g 5 МWJlMT

В закл ючение подкл юч итесь к удален ной аге нтской систе м е и запустите в ней ко­ манду manage_agents. a g e n t $ sudo /var/ossec/bin/manage_agents

Н аходяс ь на комп ьютере клие нта, вы увидите меню с другим и пункта м и

.

**************************************** * O S S EC H I D S v2 . 8 Agent man a g e r . * T h e f o l l ow i n g o p t i o n s a r e ava i l aЫ e : **************************************** ( I ) mp o r t k e y f r om t h e s e rv e r ( I ) . (Q) uit . Choo s e y o u r a c t i o n : I or Q :

Выберите пункт I , а затем вырежьте и вставьте кл юч , которы й был извлечен ранее. Добавив агент, заново запустите сервер O S S EC. П овтор ите процесс генерирования клю­ ча, е го извл е ч е н ие и и нсталл я ц и ю для каждого аге нта, с котор ы м хотите установить связь.

Конфигурация систем ы OSSEC П осле и нсталля ции и зап ус ка систе м ы O S S EC ва м следует н астроить ее так, чтобы она выдавала достаточ н ы й объем информаци и , но не сл и шком бол ьшой. Бол ьшая часть конфигурации хран ится на сервере в файле /var/os eea/eta/oe eec . conf. Это ХМ L­ подобн ы й файл , которы й подробно проком ментирова н и 1шол не поняте н , хотя и содер­ жит десятки параметров. Чаще всего необходимо конфигурировать с писок файлов, которые следует игнори­ ровать при п роверке целостности ( нал и ч ия измене н и й ) файла . Н а п р и м ер если у вас есть приложе н и е , зап ис ы вающее с вой регистрацио н н ы й фа й л в каталог /var / log/ au s tomapp . log, вы можете добавить следующую строку в ра зд ел < s y s c h e c k > этого файла. ,

< i gn o r e > /va r / l og / c u s t omapp . l o g < / i g n o r e > < / s y s ch e c k>

П осле того как внесете эти изме н е н и я и заново за пус т ите сервер OSS EC , с истема OSSEC прекратит выдавать сообщения при каждом изменен и и ре гистрационного фай­ ла. М ногие параметры конфигураци и систе м ы O S S EC оп исан ы на странице h t t p : / / www . o s s e c . n e t / d o c s /ma nu a l /mon i t o r i n g / i ndex . html # c on f i gu r a t i on — op t i o n s .

часть IV. Эксплуатация

1 008

Для того чтобы запустить и настроить л юбую систему H I D S , требуется затратить м ного вре м е н и и усил и й . Но через несколько н едель вы отфильтруете шум , и с истема станет выдавать ценную и нформацию об изменяющихся условиях в ваше м окруже н и и .

Fail2Ba n: система отражения ата ки методом перебора Fail2 Ban — это сценар и й н а языке Python, которы й контроли рует файл ы журнала, такие как /var/ log/auth . log и /var/ log/apache2 /error . log. О н ищет подозри ­ тельные событи я , такие как нес колько неудач ных попыток входа в систему и л и запро­ сы к необычно дл и н н ы м U RL-aдpecaм . Затем Fail2Ban при н и м ает меры для устранения угрозы . Например, о н может вре м е н н о блокировать сетевой трафик с определ е нного I Р-адреса или отправлять электрон ную почту в группу реагирова н и я на и н циде нты . Узн айте больше на сайте f a i l 2 b a n . o r g .

27 6 Основы КРИПТОГРАФИИ .

.

Большинство программ разработано с учетом безопасности , и это подразумевает ис­ пользование криптографи и в больших масштабах. Стандарты и правила безопасности подразумевают выбор криптографических алгоритмов и типа дан ных, которые должн ы быть защище н ы кри птографически. Почти во всех современных сетевых протоколах ис­ пользуются криптографические методы дл я обеспечения безопас ности. Короче говоря , кри птография — это столп комп ьютерной безопасн ости , и с исте м н ы е адм и н истраторы сталкиваются с ней каждый день. Следовательно, желательно знать ее основы . В криптографи и п р и м е н я ются м атем атические методы для защиты с исте м связи . Кри птографический ал горитм , называе м ы й шифром , представляет собой набор мате ма­ тических операц и й , предпри нятых для защиты сообщения . Такие ал горитмы разрабаты­ ваются коллективами экспертов, представляющим и акаде м ически е , правител ьствен н ы е и и сследовательские организации в о все м м ире. Принятие нового ал горитма — длитель­ н ы й и утомительный процесс. К тому вре м е н и , когда он добирается к массам , он уже тщательно проверен. Ш ифрова н и е — это п роцесс испол ьзования шифра для преобразования текстовых сообщ е н ий в нечитае м ы й заш ифрова н н ы й текст. Расшифровка — это обратная сторо­ на этого процесса. Кри птографические сообщен и я (зашифрова н н ы й текст) имеют н е ­ сколько полезных с войств. 5 •

• •

Конфиденциальность: сообщен и е не м ожет прочитать н и кто, кроме предполагае­ м ых получателей. Целостность: н е возможно изменить содержимое сообщен и я без обнаружения. Невозможность отказа от авторства: подл и нность сообщен и я м ожет быть про­ верена.

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

Глава 27. Безопасность

1 009

фические секрет ы , что делает такие ал горит м ы слаб ы м и . П оэтому защ ита ваш их се­ кретов и выбор хорошо продуман ного, легко обновляемого программ ного обес печения лля криптографи и имеют первостепен ное значен ие . У кри птографов есть традиционн ые и м е н а лля трех субъектов, которые участвуют в простом обмене сообщен иями: Ал иса и Боб, которые хотят общаться в конфиденциаль­ ном режиме, и Мэллори , злоум ышлен н и ца, которая хочет выведать их секреты , нарушить их общение ил и вьщать себя за другое лицо. Мы будем придерживаться этого соглашения. В следующих подразделах представлены несколько криптографических при м итивов, связанные с н и м и ш ифры и некоторые общие варианты использования каждого из них.

Крипто графия с симметрич н ыми кл ючами Криптографию с сим метрич н ы м и кл ючами и ногда называют обычной, или класси­ ческой криптографией, потому что иде и , лежащие в ее основе , существуют уже давно. Приведем пример. В этом случае Алиса и Боб должны и м еть общий секретный ключ , которы й они бу­ дут использовать лля ш ифрования и расш ифровки сообще н и й . П еред эти м о н и должн ы как и м то образом тай н о получ ить этот ключ , ил и обменяться и м . Есл и о н и оба знают секретный ключ , о н и могут его испол ьзовать столько раз, с колько пожелают. В дан ном случае М эллори сможет прочитать ( или подделать) сообщен и е толь ко если у н ее также есть секретны й кл юч . С и м метр и ч н ы е ключи относ ител ьно эффект и в н ы с точк и зре н ия ис пол ьзова н и я централ ьного процессора и размера заш ифрова н н ых сообще н и й . В резул ьтате с и м м е ­ тричная криптография часто испол ьзуется в приложе н иях, где н еобход и м ы эффектив­ ное ш ифрован ие и расш ифровка. Однако необходимость предварительного распростра­ нения общего секретного ключа является серьез н ы м препятствием во м ногих случаях использования этого метода ш ифрования. AES (Adva n c e d E n c rypt ion Standard } , стандарт рас ш и ре н н о го ш и фрован и я Национального и нститута стандартов и технологий С Ш А ( N ational l nstitute of Standards and Technology — N I ST) , является , пожалуй, наиболее широко используемым ал горитмом с симметричн ы м и кл ючами . Также доступ н ы варианты Twofish и е го предшествен ника Blowfish, разработанн ые криптографом и экспертом по безопасности Брюсом Ш найером ( Bruce Schneier). Эти алгоритмы играют определенную роль в обеспече н и и безопасности каждого сетевого протокола, вкл ючая S S H , TLS, I Psec VPN , PG P и м ногие другие.

К риптография с открытым кл ючом Серьезн ы м препятствием лля использован и и криптографии с с и мметрич н ы м и кл ю­ чами я вляется необходи мость в предварительном и безопасном получ е н и и сторонами этого самого секретного кл юча. Единстве н н ы й способ сделать это с пол ной безопасно­ стью — встретиться лично без свидетелей, что я вляется серьезным неудобством . На про­ тяже н и и веков это требован ие ограничивало практическую полезность криптографии. И зобретен ие в 1 970-х годах криптографии с откр ытым ключом , решающей эту пробле­ му, было необычайным прорывом. Схема работает следующим образом . Алиса генерирует пару ключе й . Закрытый кл юч остается секретн ы м , но открытый кл юч может быть ш ироко известен . Боб также генери­ рует пару кл ючей и публ икует свой открыты й кл юч. Когда Ал иса хочет отправить Бобу сообщен ие , она ш ифрует его с помощью открытого ключа Боба. Боб , который и меет за­ крытый кл юч , я вляется единстве н н ы м , кто может расшифровать сообще н ие .

1 01 0

Часть lV. Эксплvатация

Боб

Алиса

Открытое сообщение

Шифрование открытым ключом Боба

Зашифрованное сообщение

Расшифровка закрытым ключом Боба

Открытое сообщение

Рис. 27. /. Отправка сообщения . зашифрова11ного с использова11ием криптографии с открыт ым ключом

П ри отnравке сообщения Ал иса также может nодn исать е го своим се кретн ы м кл ю­ чом. Тогда Боб сможет исnол ьзовать nодnись Ал исы и ее открытый ключ для nодтверж­ де н и я nодл и н н ости этого сообще н и я . Дан н ы й n роцесс , уnроще н н ы й здесь DЛ Я ясности , называется цифровой подписью. Он nозволяет доказать, что именно Ал иса, а не М эллори, отnравила nолуче н ное сообще ние. П ервой nублично достуnной криnтосистемой с открытым кл ючом был метод обмена кл юча ми Диффи-Хеллмана- М еркла ( Diffie-Hellmann-Merkle) . Вскоре nосле этого из­ вестной командой, состоящей из Рона Ривеста ( Ron Rivest) , Ади Шам ира (Adi Shami r) и Л еонарда Адл емана ( Leonard Adleman ) , была разработана кри nтосисте ма с открыты м кл ючом nод названием RSA. Эти методы и были nоложен ы в ос нову современной сетевой безоnасности . Ш ифры с открытым ключом , также называе м ы е асимметрич11ыми шифрам и , ос но­ вываются на мате матической концеnции односторон н их фун кций с nотай н ы м входом (t rapdoor funct ion) , знач е н и е котор ых ле гко выч исл ить, но восстановить ал горитм их работы сложно и дорого. Н е высокая с корость работы ас и м м етрич н ых ш ифров обы ч н о дел ает их неnракти ч н ы м и для шифрован и я больших объемов дан ных. Поэтому о н и ч а ­ сто сочетаются с с и м м етрич н ы м и ш и фрам и , чтобы реал изовать nреи мущества обоих. Открытые ключ и nрименяются дл я установки сеанса связи и обмена секретн ы м симме­ трич н ы м ключом , которы й далее исnол ьзуется для ш ифрован ия текущего сеанса обм е на дан н ы м и .

И нфраструктура с открытым кл ючом Орган изация надежного , заслуживающе го доверия сnособа ре гистрации и расnро­ странения открытых кл юче й — сложное дело. Есл и Ал иса хочет отn равить Бобу лич ное сообще н и е , она должна быть уверена, что имеющийся у нее открытый кл юч Боба на са­ мом дел е n р и над.лежит е м у, а не М эллор и . П роверка nодл и н н ости открытых кл ючей в и нтернет-масштабе — грандиозная nроблема. Одной из основных кон цеnци й , реал изованных в nрограмме PG Р, я вляется так назы­ вае мая сеть доверия . Это сеть организаци й , которые доверяют друг другу в разной сте nе­ ни. Следуя косве н н ы м цеnочкам доверия вне вашей личной сети , вы можете установить, что откр ытый кл юч заслужи вает доверия с разумной сте n е н ью увере н н ости . К сожал е ­ н и ю . и нтерес ш и рокой обществен н ости к участию в nодписан ии кл юче й и кул ьтивиро­ ва н и ю сети криnтодрузей был , скажем так, довол ьно дал е к от энтузиазма. о че м свиде­ тел ьствует канувшая в лету поnулярность PG Р. В и нфрастру ктуре с открытым кл ючом , испол ьзуе мой для реал изации протокола TLS в И нтернете , п роблема доверия ре ш е н а за счет nривлечения третьей сторон ы . на­ зы вае мой Це нтром сертификации (Cenificate Aut hority — СА) . которая может пору-

Глава 27 . Безопасность

1 01 1

читься за достоверность открытых кл юч е й . Ал иса и Боб могут н е знать друг друга, но оба они довер я ют СА и знают открытый кл юч СА. Центр сертифи кации подп ис ы ва­ ет сертификаты дл я открытых ключей Ал исы и Боба собствен н ы м закрытым кл ючом . Затем Алиса и Боб мoryr проверить поруч ительство СА, чтобы убедиться , что кл юч и являются подл и н н ы м и . Сертификаты крупн ы х центров сертифи кации , таких как GeoTrust и Ve riSign , по­ ставляются с дистрибуrи вам и операционн ы х с исте м . Коrда кл ие нт нач и нает заш ифро­ ванн ы й сеанс, он видит, что сертификат партнера был подписан авторитетны м органом , уже указан н ы м в надежном локальном хра н ил и ще клиента. Следовательно, кл иент мо­ жет доверять подписи Центра сертифи каци и и открытому кл ючу партнера. Эта схема изображена на рис. 27.2. 1. Администратор посылает запрос на подписание сертификата

CA

6. Клиент сверяет подпись с образцом из надежного локальВеб-сервер 5. Сервер возвращает ного хранилища

Центр сертификации

2. CA возвращает пописанный сертификат

открытый сертификат

3. Администратор инсталлирует подписанный сертификат и 4. Клиент запрашивает закрытый ключ на сервер открытый сертификат

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

Пользователь

Рис. 2 7. 2. Инфраструктура с открытым ключом для Интернета

Орга н ы сертифи каци и взи мают плату за подп исан и е сертификатов, цена которых устанавливается в соответств и и с и х репуrацией , рыноч н ы м и условия м и и различ н ы м и характеристиками сертификата. Н екоторые варианты, например т а к назы ваемые уни ­ версмь11ые сертификаты для всех поддоменов или расширенные сертификаты подлинности с более строгой проверкой фона для запрашивающе го лица, являются более дороги м и . В этой с исте м е Центр сертификации обладает пол н ы м доверие м . Первоначал ьн о существовало всего н ес кол ько довере н н ы х це нтров сертификации , но с о вре м е н е м и х стало значительно больше. Совре ме н н ые настольные и мобил ьные операцио н н ы е с и ­ сте м ы п о умолчан и ю доверяют сотня м сертификатов. П оэтому сам и центры сертифи­ кац и и я вл я ются объектами высокой це н н ости для злоум ышле н н иков, которые хотели б ы испол ьзовать их закрытый ключ для подп иса н ия сертифи катов собстве н ной раз­ работки . Есл и Центр сертифи кации взломан , вся с истема доверия оказывается скомпромети­ рованной. И звестно, что н екоторые центры сертификаци и был и скомпрометированы злоум ы шлен н и ка м и , а в других ш и роко обсуждаемых случаях стало известно, что цент­ ры сертификации пошл и на сговор с правительствам и . Мы рекомендуем читателя м тща­ тельно выбирать центры сертифи кации при покупке услуг по подписке сертификатов. В 20 1 6 году была запущена бесплатная служба Let’s Encrypt , спонсируемая так и м и орга н и заци я м и , к а к Elect ronic Frontier Foundation, Mozilla Foundat ion, Cisco Systems, юридическая ш кола Stanford и Linux Foundation, которая выпускает сертификаты через автоматизированную с истему. К кон цу 20 1 6 года эта служба выдала более 24 м илл ио­ нов сертифи катов. Учиты вая широко известн ые проблем ы , связанн ы е с ком мерчески­ м и центрами сертификаци и , мы рекомендуем Let’s Encrypt как » возможно безопас ную» беспл атную альтернативу.

1 01 2

Часть lV. Эксплvатация

Вы можете легко орган изовать собствен н ы й центр сертификации с помощью п рото­ кола OpenS S L, и мпортировать сертификат в надежное хранилище в с воей организаци и , а затем в ыдавать сертифи каты от и м е н и этого органа. Это обычная практика защиты служб во внутрен н е й сети, где организация и меет пол н ы й контроль над хранилищем до­ веренных сертификатов. Более подробно дан ная и нформация и зложена ниже. Органи зации должн ы проявлять осторожность, при н имая реш е н и е о внедрен и и соб­ стве н н ы х сертификатов на вы пускае м ых компанией машинах. Если у вас нет такой же строгой и проверен ной систе м ы безопасности, как у профессиональны х центров сер­ тификации , в ы можете легко создать уязвимость в ваше й среде. В резул ьтате , есл и в ы работаете в организации , которая устанавл ивает собствен н ы й сертификат в н адежном хранил и ще своих компьютеров, возн икает подозрен и е , что ваш а собствен ная безопас ­ ность может быть скомпрометирована.

П ротокол за щиты тра нспортного уровня TLS В протоколе TLS (Transport Layer Security) испол ьзуется кри птография с откр ыты м ключом и инфраструктура с открыты м и кл ючами для защиты сообщен и й между хостами сети . Это преем н и к протокола S S L ( Secure Sockets Layer, ил и уровен ь защищен н ых соке­ тов). Как п равило, аббревиатуры S S L и TLS используются как синон и м ы , хотя протокол S S L устарел и объявлен вышедши м из употребления. Протокол TLS в сочетани и с Н ТТ Р известен к а к Н ТТРS. П ротокол TLS работает н а отдельном уров н е , которы й служит оберткой ТС Р ­ соеди нения. Он обеспечивает только безопасность соединения и не участвует в транзак­ ции НТТР. Благодаря этой аккуратной архитектуре протокол TLS м ожет защищать н е тол ько НТТР, но и другие протоколы , такие как SMTP. Как только клиент и сервер установил и защи щен ное соеди нение через TLS , содер ­ жимое обм е н а , включая U RL-aдpec и все заголовки , защищено с помощью ш ифро­ ван и я . Злоумы шл е нн и к может определить только хост и порт, поскол ьку эти дан н ы е видны в и н капсул ируемых пакетах протокола ТСР. В модели O S I T L S находится где-то между уровня м и 4 и 7. Хотя типичн ы м сценарием испол ьзования я вляется односторон нее ш ифрование TLS, в котором клиент ратифицирует сервер, все чаще используется двухсторонн и й протокол TLS , и ногда называем ы й протоколом взаимной аутентификации. В этой схеме кл иент дол­ жен предоставить серверу сертификат, подтверждающий его собствен ную личность. Это, например, похоже на то, как клиенты Netflix (телеприставки и все остальное, которое пе­ редает видео из Netflix) аутентифицируются в интерфейсе API Netflix. Последняя версия TLS и меет номер 1 . 2 . Отключите все верс и и S S L вместе с TLS вер­ сии 1 .0 и з-за и звестн ых уязвимостей . Версия TLS 1 . 3 активно развивается и содержит существе н н ые изменен и я , которые будут и меть значительные последствия для некото­ рых отраслей.6

К ри птографи чески е хеш — фун кции Хеш -функция обрабатывает входные дан ные любой дл и н ы и генерирует небольшое значение фикс ированной дл и н ы , которое каки м-то образом получается из этих дан н ых. Выходное значение называется по-разному: хеш -знач е н и е , просто хеш , с водка, дайд» П редставитель сектора финансовых услуг попытался повлиять на техническое решение в списке рассыл ки разработч и ков TLS, но опоздал на два года. Озабоченность была отвергнута (см. поток эл ектро н н ых сообщен и й на сайте g o o . g l / uAEw PN ) .

глава 27. Безопасность

1 01 3

жест, контрол ьная сумма ил и отпечаток пал ьца. Хеш — фун кции детермин ирова н ы , по­ этому, есл и вы выч исляете н екоторую хеш -фун кцию для заданного входного значения, вы все гда будет получать оди н и тот же резул ьтат. П ос кол ьку хеш и и ме ют фиксированную длину, существует тол ько конечное ч исло возможн ых выходных значен и й . Например, 8-битн ый хеш и меет только 2s (то есть 256) возможных выходн ых значе н и й . Поэтому для некоторых входных значе н и й неми нуемо генерируется одн о и то же значение хеш-функци и . Это событие называется колл изи­ ей. Более дл и н н ые знач е н ия хеша умен ьшают частоту колл изи й , но н икогда не могут полностью их устран ить. В программ ном обеспече н и и испол ьзуются сотни разл и ч н ых хеш -фун кци й , но под­ м ножество, известное как криптографические хеш -функци и , представляет особый и н ­ терес для с исте м н ых адм и н истраторов и математиков. В этом конте ксте слово » крип­ тографическая » означает «действительно хорошая » . Эти хеш-функции имеют почти все необходимые с войства , которые требуются от хеш -фун кции. •

Запутанность. Каждый бит хеш -значения зависит от каждого бита входных дан­ ных. В среднем изменение одного бита входных данн ы х должно привести к изме­ нению 50% битов хеш-значения . Псевдослучайность. Х е ш — знач е н и я должн ы быть неотл и ч и м ы м и от случа й н ы х дан н ых. Конеч но, хеш -значения не я вляются случай н ы м и ; о н и ге нерируются де­ тер м и н ированно и воспроизводятся по входн ым дан н ы м . Однако они все равно должны быть похожи на случайн ые дан ные: они не должн ы и м еть обнаруживае­ мой внутренней структуры, я вной зависимости от входных дан н ых и должны про­ ходить все известн ые статистические тесты на случайность. Необратимость. При задан ном хеш -значении должно быть невозможно вычислить другое входное значение, которое сгенерирует то же самое знач е н ие хеш -функции.

И м ея достаточ но качествен н ы й ал горитм хеш ирования и достаточно дл и н ное хеш ­ значение, м ы може м быть увере н ы , что два входных значения, которые генерируют одно и то же значение хеш-функции, фактически являются идентич ными. Конечно, это невоз­ можно доказать теоретически, потому что все хеш и имеют комизии. Тем не менее это мож­ но сделать для любого желаемого уровня статистического доказательства, увеличивая длину хеш-значения. С помощью криптографических хе шей проверяется целостность дан н ых. Они могут подтвердить, что данн ы й файл конфигурации или двоич ный код утилиты не бьm изменен , или что сообщение, подписанное корреспондентом электрон ной почты, н е было модифи ­ цировано в пути. Например, чтобы убедиться , что в системах Free BS D и Linux использу­ ются иде нтичн ые файлы конфигурации sshd_config, мы можем ис пол ьзовать следую­ щие команды. f r e e b s d $ sha2 5 6 /etc/ ssh/s shd_config S HA2 5 6 ( / e t c / s s h / s s hd_con f i g ) 3 e f 2 d 9 5 0 9 9 3 6 3 d . . . 8 c l 4 f 6 3 c 5b 9 f 7 4 l e a 8 d 5 =

l i nux $ sha2 5 б swв /etc / s sh/s shd_confiq 3 e f 2 d 9 5 0 9 9 3 6 3 d . . . 8 c l 4 f 6 3 c 5b 9 f 7 4 l e a 8 d 5 / e t c / s s h / s shd_c on f i g

Здесь м ы опустил и часть хеш — значен и й . Как обыч но для больши нства случаев ис­ пользован ия , выходные значения приведе н ы в шестнадцатеричной с истеме сч исле н и я . Н о имейте в виду, что фактические значе н ия хеша — это всего лишь совокупности дво­ ичных битов и эти дан н ые могут быть представлены нескольким и способами.

1 01 4

Часть lV. Эксплуатация

Существует множество криптографических алгоритмов хеш ирования , но еди нствен ­ ными, рекомендуемыми для общего использования на данном этапе, являются семейства SНА — 2 и SНА-3 (Secure Hash Algorithm), которые бьши выбраны и нстИ1уrом N I ST после детального анализа. 7 Для каждого из этих алгоритмов существуют варианты с раз н ы м и дл и на м и хеш ­ значений. Например, S HA3-5 1 2 п редстааляет собой алгоритм S HA- 3 , сконфигурирован­ ный для ген ерации 5 1 2-битового хеш-значения. Алгоритм S HA без номера версии, напри­ мер S HA-256, всегда относится к члену семейства SHA-2. Другой распространен н ы й криптографический ал горитм хе ш и рован и я , M D5 , по­ прежне м у ш ироко поддерживается криптографическим программ н ы м обесп еч е н и е м . Однако известно, что он уязвим для искусствен н ых коллизи й , когда несколько входных данных дают одно и то же значение хеш -функции. Хотя M D5 больше н е считается безо­ пас н ы м для испол ьзования в криптографии, он по-прежнему я вляется хорошо упрааля ­ емой хеш -функци е й и теоретически подходит для использования в приложениях с н из­ кой степенью защиты. Но зачем такие сложности’? Просто используйте S HA. В проектах с открытым исходны м кодом часто п убликуются хеш и файлов, которые распространяются среди сообщества пользователей. Например, в проекте OpenS S H рас­ простран яются сигнатуры P G P tаr-архивов для проверки, которые вычисляются с по­ мощью криптографических хеш-функций. Чтобы проверить подлинность и целостность получ е нных файлов, нужно выч ислить их хеш-значение и сравнить с опубликованным значением хеша. Тем сам ы м гарантируется, что вы получил и пол ную и немодифициро­ ван ную копию и без ошибок в битах. Хеш -функции также испол ьзуются в качестве ком понента кодов аутентификации сообще н и й , или кодов МАС (message authenticat ion code ) . Значение хеш а внутри кода МАС подписывается закрытым кл ючом . В процесс проверки с начала верифицируется подл и н ность самого МАС ( путем его расш и фровки с помощью соответствующего от­ крытого ключа) и целостн ости содержимого (путем вычисления хеш а е го содержимого). Схе м ы МАС часто и грают важную рол ь в обеспечении безопасности веб-приложе ний.

Генера ция случа й н ых ч исел Криптографическим системам нужен источн и к случайных чисел , из которых можно генерировать ключи . Но для ал горитмов нехарактерно случай ное и непредсказуемое по­ ведение. Ч то делать’? Золотым стандартом для генерации случайн ых ч исел я ал я ются дан н ы е , полученные из физически случайных процессов, таких как радиоактивный расп ад и радиочастот­ н ы й шум от ядра галактик и . Такие источн и ки реально существуют: с м . сайт r a ndom . o r g для доступа к некоторым фактическим случайн ы м дан н ы м и получения объяснения того, как это происходит. Это и нтересно, но, к сожал е н и ю , не очень полезно дл я по­ вседневной кри птограф и и . Для генерации последовател ьносте й случай н ы х дан н ых в традицио н н ых ге нераторах псевдослучайных ч исел используются м етоды , аналогич ­ ные методам хеш -функци й . Однако этот процесс детерм и нирован. Если вы знаете вну­ треннее состояние генератора случайн ых ч исел , вы можете точно воспроизвести после­ довательность его вывода. Следовател ьно, это плохой вариант для криптографии . Если вы генерируете случ а й н ы й 2048-битовый ключ , вам требуется 2048 случ ай н ы х б итов , а н е 1 28 бит состоян ия генератора ч исел , на основе которых алгоритм ически бьши полу­ чены эти 2048 бит. 7Алгори тм S HA- 1 бьи с комп рометирован и больше не должен и с пользоваться .

Глава 27. Безопасность

1 01 5

К счастью, разработчики ядра систем U N JX приложили немало усил и й для фиксаци и тонких изменений в поведении системы и использования и х в качестве источников случай­ ных ч исел . Для этой цели используются любые подходящие данные, начиная с временных меток получения сетевых пакетов, и заканчивая моментами времени возни кновения ап­ паратных преры ван ий от таких слабо предсказуемых устройств, как дисковые накопител и. Даже в среде виртуальных и облачных серверов все еще достаточно энтропии, чтобы сгене­ рировать достаточно случайные ч исла. Данные со всех этих источ н и ков поступают во вторичный генератор псевдослучай н ых чисел , который гарантирует, что выходной поток случайных данных будет и меть коррект­ ные статистические свойства. Эrот поток данных затем предоставляется для использования через драйвер устройства. В системах Linux и Free BSD он представлен как /dev/random и / dev/urandom. О случайных числах необходимо знать два факта. •

Все , что работает в пол ьзовательском пространстве , не может кон курировать с ка­ чеством генератора случай н ых ч исел ядра. Н и когда не позволяйте криптографиче­ скому программ ному обес печен и ю генерировать собствен н ые случайные дан н ы е ; всегда убедитесь, что он испол ьзует случайные дан н ые из файлов устройств /dev/ random или /dev/urandom. Бол ьш и нство програм м делают это по умолчан и ю . Выбор файла /dev/ random или /dev/urandom я вляется п редметом спора, и , к со­ жал е н и ю , аргументы носят сл и ш ком тонкий и математичес к и й характер, чтобы обобщить их здесь. Короткий вариант ответа закл ючается в том , что устройство /dev/random в с истеме Linux может вообще не ге нерировать дан н ы е , есл и ядро распознает, что с истема не накапливает достаточную энтропию. Л ибо изучите этот вопрос и сознательно выбирайте одну из сторон , либо просто испол ьзуйте устрой ­ ство /dev/urandom и не беспокойтесь о б этой проблеме. Большинство экспертов, похоже , рекоме ндуют последн и й вариант. Пол ьзователи систе м ы Free B S D осво­ бождаются от п роблемы выбора, поскольку файлы устройств /dev/ random и /dev/ urandom в ядре иденти ч ны.

Выбор кри птографического п рограммного обеспечения Есть вес кие основан и я очен ь подозрител ьно относиться к о все м у програм м н о м у обеспече н и ю с истем безопасности и особен но к пакетам, которые предоставля ют кри п ­ тографические услуrи . П о слухам , правител ьства больших и вл и я тел ьных государств п ытались оказать вл ияние на разработчи ков еще н а этапе проектирова н ия кри птогра­ фических протоколов и ал горитмов. Можно предположить, что нес кол ько хорошо фи­ нанс ируе м ых групп стремятся с компрометировать л юбой криптографичес к и й п рое кт, который и меет шансы на успех. Те м н е менее мы доверяем программному обес печен и ю с открытым исходн ым кодом больше, ч е м закрытому. Такие п рое кты , к а к Ope n S S L , имеют бол ьшую истори ю серьезн ых уязвимосте й , но эти пробл е м ы б ы л и обнаруже н ы , смягчен ы и х последствия и опубл и кованы резул ьтаты ис правл е н и й на профил ьном от­ крытом форуме. История проекта и исходный код изучаются тысячами людей. Н и когда не применяйте доморощен ные кри птографические программы! П росто ис­ пол ьзуйте готовые библиоте ки п равил ьно, хотя это и не все гда п росто! Заказа н н ы е на стороне кри птосистемы обреч ены на уязвимость.

Часть lV. Эксплvатация

1 01 6

К о ман да open s s l Команда open s s l это м ногоуровневый ТLS- и н струм е н т адм и н и стратора. В ы можете испол ьзовать его для генераци и пар открытого-закрытого ключа, шифрования и дешифрова н ия файлов, изучен ия кри птографических свойств удал е н н ых с исте м , соз­ дан и я собствен ных центров сертификации , преобразования файловых форматов и м но­ жества других криптографических операций . —

Подготовка кл юче й и сертификатов Одн о й и з н а и более распростран е н н ых адм и н истрат и в н ы х фун к ц и й команды openssl я вляется подготовка сертификатов для их подписания в центре сертификаци и . Начнем с создания 2048-битового закрытого ключа: $ openssl genrsa -out admin . com . key 2 0 4 8

Используйте закрытый ключ для создания запроса на подпись сертификата. При этом команда openssl запросит метаданные в виде отличительных имен (Disti nguished Name, DN) для включен ия в запрос . Эту информацию также можно у казать в файле ответов, чтобы не вводить ее каждый раз вручную из командной строки , как показано н иже. $ openssl req -new — sha2 5 6 -key admin . com . key -out admin . com . csr Coun t r y Name ( 2 l e t t e r code ) [ AU ] : US S t a t e or P r ov i n c e N ame ( fu l l n ame ) [ S ome — S t a t e ] : Oregon L o c a l i t y Name ( e g , c i t y ) [ ] : Portland O r g a n i z a t i on N ame ( e g , c omp a n y ) [ I n t e r n e t W i d g i t s P t y L t d ] : ULSAНSE O r g a n i z a t i on a l U n i t Name ( e g , s e c t i on ) [ ] : Crypto divi sion C ommon N ame ( e . g . s e rv e r FQDN or YOUR name ) [ ] : server . admin . com

Отправьте содержимое файла admin . com . csr в центр сертификации , который вы­ пол н ит п роцесс проверки, в резул ьтате которого будет подтвержден о , что в ы связан ы с доменом , для которого получаете сертификат. П роцесс верификаци и обычно выпол ­ н я ется путем отправки сообще н ия по электронной почте на оди н из адресов в этом дом е н е . П осле этого вам возвращается подписан н ы й сертификат. Затем вы м ожете ис­ пользовать файл admin . com . key и сертификат, подписа н н ы й центром сертификаци и , в конфигурации вашего веб-сервера. В бол ь ш ин ство из этих полей можно ввести произвол ь н ы й текст, но пол е общего и м е н и Common Name и меет важное значе н и е . Оно должно соответствовать и м е н и под­ домена, которы й вы хотите обслуживать. Есл и , например, вы хотите работать через TLS с сайтом www . admin . com, укажите его доменное имя в поле Common Name. В этом поле вы можете указать несколько и м е н для одного сертификата или с и м вол подстановки , которы й соответствует все м именам в поддомене: например * . admin . com. После того как вы получите сертификат, вы можете изучить его свойства. Н иже приве­ ден ы некоторые сведе н ия об универсальном сертификате для поддомена * . google . сот. $ openssl х5 0 9 -noout — text — in google . com . pem d e p t h = 2 / C =U S / O= G e oT r u s t I n c . / CN=GeoT r u s t G l ob a l СА S i gn a t u r e A l g o r i t hm : s h a 2 5 6Wi t h RSAEn c r yp t i on I s s u e r : C=U S , O=Go o g l e I n c , CN=Goog l e I n t e rn e t Au t h o r i t y G2 Val i di t y N o t B e f o r e : D e c 1 5 1 3 : 4 8 : 2 7 2 0 1 6 GMT N o t A f t e r : Ma r 9 1 3 : 3 5 : 0 0 2 0 1 7 GMT Subj e c t : C=U S , ST=C a l i f o r ni a , L=Moun t a i n V i e w , O=Go o g l e I n c , CN= * . googl e . c om

Глава 2 7. Безопасность

1 01 7

Срок действия этого сертификата — с 1 5 декабря 2 0 1 6 года по 9 марта 2 0 1 7 года. Кл иенты . которые подключаются к сайту после истечен и я этого временного и нтервала, будут видеть сообщение о том , что сертификат бол ьше н едействител е н . Отслеживание срока действия сертификата и своевременное его обновление обычно я вля ется обязан­ ностью систе много адми н истратора.

Отладка TLS-cea н ca с сервером Используйте команду openssl s_client для изучения подробностей ТLS-соединения с удаленным сервером. Эrа информация может оказаться весьма полезной при отладке веб­ серверов, и меющих проблемы с сертификатами. Например, для про верки свойств TLS до­ мена google . com необходимо выполнить приведенную н иже команду (ее вывод сокращен для краткости). $ openssl s_client — connect google . com : 4 4 3 N e w , T L Sv l / S S Lv 3 , C i ph e r i s AES 1 2 8 — S HA S e rve r puЫ i c k e y i s 2 0 4 8 b i t S e c u r e Re n e g o t i a t i o n I S s uppo r t e d C omp re s s i on : NONE E x p a n s i on : NONE SSL-Se s s ion : TLSvl P r o t oc o l AE S 1 2 8 — S НA Cipher 4 F7 2 DC 5 6 EE 4 E 8 0 5 6 8 F7 E O E F 9 F 5 9 C 8 D7 8 5 5 C 8 7 F3 6 6 B 4 9 B F 1 D 9 8 0 8 . . . S e s s ion- I D S e s s i o n — I D- c t x 0 9 5 C 6 D B A F 9 B 6 B 8 1 E 3 E 1 6BA 0 5 C O C 9AC FAC D 7 2 E F3 3 3 5A 3 2 B 8 6 F 3 D 3 . . . Ma s t e r — K e y None Key-Arg 1 4 8 4 1 6322 0 S t a r t T ime 3 0 0 ( sec) T ime out Ve r i f y return code : О ( o k )

В ы можете испол ьзовать команду open s s l s_client, чтобы проверить, какие вер­ сии протокола TLS поддержи ваются сервером (см. также команду open s s l s_server, которая зап ус кает уни версал ьн ы й T LS-cepвep). Это может пригодиться для тестирова­ ния и отладки клиентов.

PG P: довольно хорошая конфиден циал ьность П а кет P G P ( Pretty G ood Privacy) , н а п и с а н н ы й Ф и л о м Ц и м м ер м а н о м ( Ph i l Zimmermann), содержит криптографические утил иты , п редназнач е н н ые в ос новном дл я обеспече н и я безопасности систем эле ктронной почты. О н испол ьзуется дл я ш и фрова­ ния дан н ы х , генерирования сигнатур и проверки источн и ков происхожден и я файлов и сообщен и й . m Более подробная информация о защите электронной почты приведена в разделе 1 8 .4. Пакет PG P и меет интересную историю, которая включает в себя судебные иски , кри­ минальные расследования и приватизацию фрагментов исходного пакета PG P. Недавно пакет PG Р был подверrнут жесткой критике за то, что он раскрывал сли ш ком м ного ме­ тадан н ых в своих наиболее распространен н ы х режимах испол ьзования. Афи ш ирование среди прочего длины сообщен и я , е го получателе й , а также испол ьзование незаш ифро­ ван ного хран ил и ща для черновиков — все это слабые м еста , которые могут быть ис-

Часть lV. Эксплvатация

1 01 8

пользован ы злоум ы шленн и ка м и , особе нно субъектами национал ьн ых государстве н н ых структур, обладающи м и огром н ы м и ресурсам и . Тем не менее, использование PG P по­ прежнему предпочтительнее, чем обмен открытым и сообщениям и . В н астоящее вре мя формат файла и протоколы PG Р стандартизованы организаци­ е й I ET F под именем Ope n PG P, и уже существует несколько реал изаций предложенного стандарта . П роект G N U обеспеч и вает превосходную, свободную и ш ироко применяе­ мую реал изацию под н азванием G n u PG , которую можно найти по адресу g n u p g . o r g . Для ясности м ы будем назы вать эту систему просто PG P, даже если ее отдел ьные реали ­ зации имеют другие назван ия. Вероятно, PGP — наиболее популярная криптографическая программа. К сожале­ нию, для того чтобы работать с ней в системе U N IX/Linux, нужно б ыть специалистом в области криптографии. Пакет PG P может оказаться полезн ы м , но мы н е рекоменду­ ем заставлять пользователей работать с н и м из-за нетривиал ьности процесса обучения. Гораздо удобнее использовать Windows-вepcию PG P, чем команду pgp с ее м ногочислен­ ными режим а м и работы . П рогра м м ные пакеты , распространяемые через И нтерн ет, часто содержат файл сиг­ натуры PG Р, подтверждающ и й их подл и н ность и целостность. Но проверить эти сигна­ туры не так-то легко л юдя м , не я вляющимся фанатиками PG P. Н е потому, что п роцесс проверки сложен , а потому, что при использовани и PG P истин ная безопасность дости­ гается только путем создания персональной коллекции открытых ключей тех л юде й , ко­ торы е был и проверен ы напря мую. Загрузка дистри бутива вместе с открытым кл ючом и файлом с игнатуры безопасна примерно в той же сте пе н и , что и загрузка самого дис­ трибутива без них. Не которые почтовые кл иенты имеют надстройки, обеспечивающие простой графи­ ческий пользовательск и й и нтерфейс дл я расш ифровки входящих и шифрова н и я исхо­ дящих сообщен и й . П ол ьзовател и браузера Google Chrome могут и нсталл ировать рас ш и ­ рени е , ориентирова нное н а конеч ного пользовател я , поддерживающее PG Р дл я почты Gmail.

Kerberos: ун ифицир о ванн ы й подход к сетевой безопасности Систе м а Ke rberos, разработан ная в М ассачусетсском технологическо м и нституте ( M IT) , ориентирована на решение задач , связанных с обеспечен ие м безопасности ком ­ п ьютерн ых сете й . Ke rberos это система аутентифи кац и и , предоставляющая » гара н ­ тию» того, что пользовател и и служебные програм м ы действител ьно я вл яются тем и , за кого себя выдают. Н и каких допол нительн ых проверок и ш ифрова н и я передаваем ых дан н ых н е предусмотрено. И сп ол ьзуя с и м метр и ч н у ю и аси м м етри ч н ую кри птографию , п ротокол Ke rbe ros создает вложе н н ы е н аборы идентификаторов, называемых билетами или мандатами. М андаты передаются по сети с целью подтвержден ия личности пол ьзователя и предо­ ставл е н и я ему доступ а к сете11 ы м службам . В каждой орган и зац и и , где используется Kerberos, долже н выдел яться хотя бы оди н физически защищен н ы й ком пьютер, назы ­ вае м ы й сервером аутеитификации, для запуска демона Kerberos. Этот демон выдает ман­ даты пользователям и служебн ы м программам, требующим аутентифи кац и и , на основа­ н и и предъявляемых и м и «удосто11ерени й » , в частности паролей. П о сут и , п ротокол Kerberos улучшает традиционную схему парольной защиты все ­ го двумя способа м и : пароли н икогда н е п ередаются по сети в незаш ифрован ном в иде , —

Глава 27. Безопасность

1 01 9

и пользователи избавляются от необходимости м ногократно вводить пароли. Все это по­ зволяет создать благоприятную среду парольной защиты сетевых служб. Сообщество пол ьзователе й Kerberos может похвастаться одн и м и з сам ы х толко­ вых и оригинал ь н ы х докуме нто в , посвя щ е н н ы х кри птосисте ма м , — » Designing an Authentication System: а Dialogue in Four Scene » ( П роектирование систем ы аутентифика­ ции: диалог в четырех актах) Билла Брайанта ( Bill Bryant) . Его будет и нтересно почитать любому, кто интересуется темой криптографии . Документ можно найти по адресу: web . rni t . e du / ke r b e r o s / www / di a l o g u e . h trnl . Л учше использовать Kerberos, чем вообще отказаться от средств защиты . К сожале­ нию, KerЬeros нел ьзя назвать пол ностью безопасной системой , а ее и нсталляция и за­ пус к — не самое приятное занятие. В то же время она не заменяет собой другие меры безопасности , описанн ые в дан ной главе . К сожалению (хотя , возможно, вполне предсказуемо) , система KerЬeros, распростра­ няемая как часть службы Active Directory с исте м ы Windows, испол ьзует запатентован­ ные, н едокументирова н н ы е рас ш и ре н и я . Как следствие, она плохо взаи модействует с традицион ной версией систе м ы , в основу которой положен код М IТ. К счастью, демон sssd позволяет системам U N IX и Linux взаимодействовать с версией систе м ы Kerberos для службы Active D i rectory. Более подробную информацию о службе каталогов можно найти в разделе 1 7. 3 .

27 7 .

.

СИСТЕМА SSH

Система S S H ( Secure S He l l , ил и защ и ще н н ая командная оболочка) , разработан ная Тату Юлё н е ном (Tatu У1 nen) , я вляется протоколом для удал е н н ого входа в с исте м у и обеспечения сетевых усл уг в ненадежной сети. Возможности S S H вкл ючают в себя удал е нное выпол н е н ие команд, доступ к командной оболочке , передачу файлов , пере­ адресац и ю портов , услуги сетевого п рокси и даже ту н нел ирован ие VP N . Это незаме­ нимый и нструме нт, настоя щий швейцарский армейский нож для с исте м н ых адми н и ­ страторов. S S H — это протокол типа кл и е нт-сервер, в котором испол ьзуется кри птография для аутентификаци и , а также обеспечения конфиденциал ьности и целостности сообще­ н и й , передавае мых между двумя хоста м и . Он поддержи вает алгоритмическую rибкость и позволяет обновлять и заменять основные криптографические протоколы по мере раз­ вития отрасли . Система S S H докуме нтируется как группа связанных протоколов в RFC 4250-4256. В этом разделе м ы обсудим OpenSS H , реализацию SSH с открытым исходн ы м кодом , которая вкл ючена и активирована п о умолчанию почти в каждой версии U N IX и Linux. Мы также упом я н е м нескол ько ал ьтернати вных реш е н и й для предпри и м ч и вых и н е ­ предвзятых л юдей.

Основы OpenSSH Набор программ OpenSSH бьm разработан в рамках проекта Open B S D в 1 999 году и с тех пор поддерживается этой организацией. П рограмм н ы й пакет состоит из нескол ьких команд: •

ssh

sshd

клиент;

демон сервера ;

Часть lV. Эксплvатация

1 020 •

ssh-keygen — команда для генерации пар открытых-закрытых ключе й ;

ssh-add и s sh-agent — утилиты для управления ключами аутентификац и и ;

ssh-keyscan — для извлечения открытых ключе й с серверов;

sftp- server — серверный процесс для передачи файлов через протокол S FТP;

sftp и scp — утилиты для передачи файлов.

В наиболее распространенном сценарии использования клиент устанавл ивает соеди­ нение с сервером , аутентифицирует себя и впоследстви и запускает оболочку для выпол­ нения команд. Методы аутентификации согласовываются в соответствии со взаимной поддержкой и предпочтениями клиента и сервера. М ногие пользователи могут входить в с истем у одновременно. Для каждого пользователя назначается псевдотерминал , вход и выход которого подключаются к удален ной системе. Чтобы инициировать этот процесс , пользователь вызывает команду ssh, указывая в ее параметрах удаленный хост в качестве первого аргумента: $ s sh server . aclmin . com

Команда s sh пытается установить ТС Р-соединение через порт 2 2 , стандартн ый S S Н ­ порт, назначен н ы й реестром IANA. После установки соединения сервер отправляет свой открытый ключ для проверки. Если сервер еще не известен и не вызывает доверия, ко­ манда ssh запрашивает у пользователя подтверждение сервера, представляя хеш откры­ того ключа сервера, называемого ключевым отпечатком . T h e a u t h e nt i c i t y o f h o s t ‘ s e rve r . admin . c om ‘ c an ‘ t Ье e s t aЫ i s he d . ECDSA k e y f i n g e r p r i n t i s S HA2 5 6 : quLdFoX B I 60p U 6 HwnUy / K 5 0 cR9UuU . Are y o u s u r e you want to c on t i nu e conne c t i ng ( ye s / no ) ?

Цель состоит в том , чтобы адми н истратор сервера мог заранее передать пол ьзова­ тел я м ключ хоста. Затем пользователь сможет сравн ить информацию, получен ную им от адми н истратора, с отпечатком сервера, выведенным при первом подключении. Если они совпадают, то подлинность хоста будет доказана. Как только пользователь примет ключ , к файлу » / . ssh/ known_hosts для будущего использования добавляется его отпечаток. Команда ssh не будет упоминать ключ серве­ ра еще раз, если ключ не изменится. В противном случае s sh выведет предупреждающее сообщение о том , что личность сервера изменилась. На п р а к т и к е эта п р о цедура в е р и ф и к а ц и и с е р в е р а о б ы ч н о и гн о р и р уетс я . Администраторы редко посылают ключ хоста пользователям , и пользователи слепо при­ н имают ключ хоста без проверки. Этот процесс штамповки новых ключей хоста под­ вергает пользователей атакам » человек посредине » . К счастью, этот процесс может быть автоматизирован и оптимизирован. Мы обсудим проблему проверки ключа хоста с по­ мощью протокола S S H FP немного н иже. П осле того как кл юч хоста был принят, сервер указывает методы проверки подл и н ­ ности, которые он поддерживает. П акет программ Open S S H реал изует в с е м етоды, опи­ санн ые в документах RFC S S H , вкл ючая простую аутентификацию по парол ю U N IX, доверен ные хосты , открытые кл юч и , G S SA P I для и нтеграции с протоколом Kerberos и гибкую схему запрос-ответ для поддержки подключаемых м одулей аутентификации и одноразовых паролей. Из них наиболее часто используется аутентификация с откры­ тым ключом , которая рекомендуется для большинства организаци й . Она обеспечивает луч ш и й баланс между безопасностью и удобством . Мы более подробно обсудим исполь­ зование открытых ключей для аутентификации через S S H немного н иже .

Глава 27. Безопасность

1 021

Команды s s h и s shd могут быть настроен ы мя разных потребностей и видов без­ опасности. Файлы конфигурации находятся в каталоге /etc / s sh, которы й я вляется не­ характерно стандартным местом среди всех разновидностей U N IX и Linux. В табл . 2 7 . 1 перечислены файл ы , находящиеся в этом каталоге . Таблица 2 7 . 1 . Файлы конфигурации в каталоге / etc/ s sh Файл

Разреwени11

Содержимое

ssh_config

0644

Конфигурация клиента для всего сайта

sshd_config

0644

Конфигурация сервера

moduli

0644

О сновные номера и генераторы для обмена ключами D H

*_key

0600

Закрытые ключи для каждого алгоритма, поддерживаемого сервером

*_key . puЬ

0644

Открытый ключ , соответствующий каждому закрытому ключу

Кроме каталога / e tc / s sh , пакет п рогра м м Ope n S S H ис пол ьзует каталог � ! . s sh мя хранения открытых и закрытых кл ючей , переопределения конфигурации каждого клиента и для нескол ьких других цел е й . Каталог � / . ssh игнорируетс я , если е го разре­ шения не равн ы 0 7 0 0 . Пакет Ope n S S H имеет заслуживающий уваже н и я , хотя и не безупреч н ы й послуж­ ной сп исок уязви м ы х м ест систе м ы безопасности. Согласн о базе дан н ы х СУЕ ( c v e . mi t r e . o r g ) , в ран н их версиях было обнаружено н ес кол ько критических уязвимосте й . Последняя из н их была задокументирована в 2006 году. Ч асто появляются сообщен и я о случаях отказа в обслуживан и и и испол ьзования уязвимостей , но бол ьш инство из них считается неопасн ы м и . Те м не ме нее было бы разумно обновлять пакеты Ope n S S H в рам ках вашего регулярного графика обновле н и й .

Клиент s sh Начало работы с командой s s h я вляется просты м , но ее сила и ун иверсал ьность проявля ются в м ногоч исле н н ых вариантах. С помощью конфигурации можно выбрать криптографические ал горитм ы и ш ифры , создать удобные псевдонимы хостов, настро­ ить переадресацию портов и м ногое другое . Основной си нтаксис: ssh [ опции ]

[ имя_ пользова теля@ ] хо с т [ команда )

Например, чтобы проверить зан и маемое каталогом /var / log дисковое простран ­ ство, можно выполнить команду $ s sh server . admin . com » df -h /var/ log»

Если вы укажете кома нду, то утил ита ssh аутентифицирует себя н а хосте , выполнит эту команду и выйдет, не открывая интеракти вную оболочку. Если вы не укажете имя_ польз о в а теля, то утил ита s sh использует ваше локал ьное имя пользователя на удален­ ном хосте. Утилита s sh считывает глобальные параметры конфигурации из файла /etc/ s sh/ ssh_config и обрабатывает допол н ительные параметры и переопределения мя каждо­ го пол ьзователя из файла � / . ssh/config. В табл . 27.2 перечислены некоторые из наи­ более интерес н ых параметров, которые вы можете указать в этих файлах. Мы обсудим эти варианты более подробно ниже в данной главе.

Часть lV. Эксплvатация

1 02 2 Таблица 27.2. Параметры конфиrурацми клиента s sh Вариант

Значение

По умолч анию

AddKeysToAge n t

Автоматически добавлять ключи к команде ssh-aqent

no

Conn e c t T ime out

Время ожидания подключения в секундах

Cont r o lMa s t e r

Разрешить мультиплексирование соединения

Варьируется no

Dynami c Fo rward

Настройка прокси-сервера SOCKS4 или SOCKS5

Forwa r dAge n t

Включить пересылку s sh-aqent

Host

Маркер для нового псевдонима хоста

I de n t i t y Fi l e

Путь к закрытому ключу аутентификации

�! . ssh/id_rsa6

Port

Порт для подключения

22

Reque s tTTY

Укажите, требуется ли устройство ТТУ

auto

S e rve rAl ive i nt e rval

Выполнять периодическое зондирование подключения к серверу

о ( отключено)

а

no

S t r i c t H o s t Ke yChe c k i n g Требовать ( y e s ) или игнорировать (no) ключи хоста

ask

значение п о умолчанию зависит о т стандартных значений протокола ТСР, установленных в ядре , мы к системе сильно различаются. 6 Точное имя зависит от алгоритма аутентификации. По умолчанию все ключи начинаются с id_.

которые о т систе­

Когда утилита s s h собирает окончательную конфигурацию, аргументы команд­ ной строки имеют п риоритет над элемента м и , указанными в файле / . s sh / config. Глобальная конфигурация, установленная в файле /etc / s sh/ s sh_config, имеет наи­ меньший приоритет. Утилита s sh отправляет текущее имя пользователя в качестве имени входа, если дру­ гое значение не указано. Вы можете указать другое имя пользователя с помощью флага -1 или синтаксиса @ : …

$ ssh — 1 hsolo server . admin . coш $ ssh [email protected] server . adшin . coш

Параметры клиента, для которых не предус мотрены отдел ьные аргуме нты , переда­ ваемые утилите s sh, все таки могут быть установлены из командной строки с помощью флага -о. Например, в ы можете отключить проверку хоста на для сервера: $ ssh

S trictHos tкeyChecking=no server . admin . coш

Флаг -v выводит отладочные сообщен и я . Укажите е го нескол ько раз (макс и м ум три ) , чтобы увеличить степень детализации. Этот флаг неоцен им при отладке п роблем с аутентификацией . Для удобства утилита s sh возвращает код завершен ия выполнения удаленной ко­ манды. Используйте эту возможность для выявления ошибочных ситуаций при вызове утилиты s sh из сценариев. Чтобы ознакомиться с доступными параметрами и функция м и , обратитесь к спра­ вочн ы м страни цам man s sh и man s sh_config. Для получения краткой информации запустите команду s sh -h.

Аутентифи к а ция с помощью открытого ключ а Протокол OpenSSH ( и протокол S S H в целом ) может испол ьзовать кри птографию с открытым ключом дл я аутентификации пользователей на удал е н ных системах. Как пользователь, вы сначала должн ы создать пару открытый-закрытый ключ . П осле этого

Глава 27 . Безопасность

1 02 3

вы должн ы каким-то образом передать свой открытый кл ю ч ад м и н истратору удален ного сервера, который добавит е го на сервере в файл » / . ••h/authori zed key s . Затем вы _ можете войти на удал е н н ы й сервер, выпол н и в команду • •h с удал е н н ы м имене м поль­ зователя и своим соответствующим закрытым кл ючом . $ s sh -i � / . s sh/ id_ecdsa [email protected] server . admin . dom

Для создания пары кл ючей испол ьзуйте утил иту s sh-keygen. В ы можете у казать , ка­ кой кри птографический ал горитм испол ьзовать, а также дл и ну кл юча в битах и другие характеристики. Например, для создания пары ключей EC DSA с 384 -б ито в ы м размером эллиптической кривой можно выпол н ить следующую команду. $ s sh-keygen — t ecdsa -Ь 3 8 4 Gene r a t i ng puЫ i c / p r i v a t e e c d s a k e y p a i r . Ent e r f i l e i n which t o s ave t h e k e y ( / home / b e n / . s s h / i d_e cd s a ) : < r e t u r n > En t e r p a s s p h r a s e ( emp t y f o r no p a s s p h r a s e ) : < r e t u rn > En t e r s ame p a s sp h r a s e a g a i n : < r e tu r n > Y o u r i d e n t i f i c a t i on h a s b e e n s aved i n / h ome / b e n / , s s h / i d_ e c d s a . Y o u r puЫ i c k e y h a s b e e n s a v e d i n / h ome / b e n / . s s h / i d _ e c d э a . pub . The k e y f i n g e r p r i n t i s : SHA2 5 6 : VRh б r a U fpn 3 Y dt Мm7 GURЫ o y f c p / npbwh smv s d r l h K 4 b e n

Открытый ключ ( » / . ssh/id ecdsa . puЬ) и файл ы с закрыт ы м кл юч ом ( / . ssh/id ecdsa) я вляются текстовым фа Йл ами в формате ASC l l с коди ров к ой base64. Н и ко гда не делитесь л и ч н ы м ключом! Утил ита s sh-keygen прав и л ь но устанавл и вает права доступа к файлам , содержащим открытый и закрытый кл юч и , к а к 0644 и 0600 соотве тс тве н н о . В этом примере ис пол ьзуется алгор итм EC DSA, но та кж е можно п р и м е н ять п араметр -t rsa с дл иной кл юча 2048 ил и 4096 бит. Утил ита s s h — keygen за праш и вает необязател ьную кодо вую фразу для ш и фрова­ н и я закрытого кл юча. Есл и вы испол ьзуете кодовую фразу, вы должн ы будете ввести ее для де ш ифрования кл юча, прежде чем утил ита s s h с м ожет е го п роч итать. Кодовая фраза улуч ш ает безопас ность, пос кол ьку процесс аутентифи кации получает допол н и ­ тел ь н ы й этап проверки: вы должн ы и м еть файл кл юча и знат ь кодовую фразу, которая расш ифровывает е го , прежде чем вы сможете аутентифицироваться . М ы предлагаем установить кодовую фразу для вс е х п р и в и л е г и ро ва н н ы х учетн ы х за­ писей (т. е . тех, у кого есть привилегии на запуск sudo). Есл и вам необходимо испол ьзо­ вать кл юч без кодовой фразы для акти визации автоматического п роцесса аутентифика­ ции , огран ичьте пол номочия соответствующей учетно й зап и с и сервера. Есл и вы адм и н истратор сервера и вам нужно добавить откр ы т ы й кл юч дл я нового пользователя , вы пол н ите следующие действия . «

1 . Убедитесь, что у пол ьзователя есть активная учетная зап и с ь с корректной с исте м н о й оболочкой. 2 . Получ ите копию открытого кл юча пол ьзователя от с а м о го п ол ьзо вател я . 3. Создайте пользовател ьский каталог . s sh с разре ш е н и я м и 0700. 4. Добавьте откр ытый кл юч в файл — п о л ь з о в а т е л ь / . s s h / a uth o r i z e d_k ey s и установите разре шения для этого файла 0600. Например, если открыты й ключ пол ьзователя h s o l o б ыл сохра н е н в файле / tmp/ hsolo . puЬ, процесс будет выглядеть так. $ grep hsolo /etc/pas swd h s o l o : х : 5 0 3 : 5 0 3 : Han S o l o : /home / h s o l o : / b i n / b a s h

1 024

Часть lV. Эксплуатация

$ шkdir -р -hsolo/ . s sh & & chmod 0700 -hsolo/ . ssh $ cat / tmp/hsolo . puЬ >> -hsolo/ . ssh/authorized_keys $ chmod 0 60 0 -hsolo/ . ssh/authori zed_keys

Если вам нужно проделать эти действия более одного раза , то вполне разумно соз­ дать специал ь н ы й сценарий дл я выполнения дан ной процедуры . С исте м ы управления конфигурация м и , такие как AnsiЫe и Chef, очень хорошо справляются с этой задаче й .

Де м о н s sh-agent Демон s sh-agent кеширует деш ифрованные закрытые ключи. Для этого вы должн ы загрузить с вои личные ключи в агент, после чего утил ита s sh сможет автоматически их испол ьзовать при подключе н и и к новым серверам , что упрощает процесс подкл ючения. И спользуйте команду s sh-add для загрузки нового ключа. Если для ключа требуется кодовая фраза, вам будет предложено ее ввести. Чтобы отобразить текущие загружен н ые ключи, запустите команду s sh-agent -1. $ ssh-add — / . ssh/id_ecdsa En t e r p a s s ph r a s e f o r — / . s s h / i d_e c d s a : < кодов а я фра з а > I de n t i t y adde d : — / . s s h / i d_e c d s a ( — / . s sh / i d_e c d s a ) $ ssh-add — 1 3 8 4 S HA2 5 6 : V R Ы o y f c p / npbwh s mv s d r l h K 4 — / . s s h / i d_e c d s a ( EC D S A )

В ы можете одновременно активировать сразу несколько ключей. Для удаления клю ­ ча используется команда s sh-add -d путь, а для очистки всех загруженных ключей команда s sh-add -D. Как ни стран но, чтобы удал ить закрытый ключ и з агента, открыты й ключ должен находиться в том же каталоге и и меть то же имя файла, но с расширением . рuЬ. Есл и открытый ключ недоступе н , вы можете получить запутанное сообщен и е о том , что ключ не существует. $ s sh-add -d — / . ssh/id_ecdsa B a d k e y f i l e / h ome /ben / . s s h / i d_e c d s a : No s u c h f i l e or di r e c t o r y

В ы можете легко исправить эту проблему, извлекая открытый кл юч с помощью ути­ л иты s sh-keygen и сохранив е го с ожидаемым именем файла. (Это извлечен ие возмож­ но, потом у что файл закрытого кл юча содержит коп и ю открытого ключа, а также за­ крытый ключ. ) $ key=/home/Ьen/ . ssh/ id_ecdsa $ s sh-keyqen -yf $key > $key . puЬ En t e r p a s s p h ra s e : < кодо в а я фра з а >

Утилита s sh-agent еще более полезна, когда вы испол ьзуете ее возможность пере­ сыл к и ключей агентов, что делает загружен н ые ключи доступн ы м и для удален н ых хо­ стов, в то время как вы входите в с истему через оболочку ssh. Вы м ожете испол ьзовать эту функцию для перехода с одного сервера на другой без копирования вашего закрыто­ го кл юча на удаленные систем ы (рис. 2 7 . 3 ) . Чтобы акти визиро вать возможность пересылки ключа агента, добавьте параметр Fo rwa rdAg e n t ye s в свой файл — / . ssh . config или используйте команду s sh -А. Испол ьзуйте пересылку кл ючей только на серверах, которы м вы доверяете. Л юбой , кто контролирует сервер, на которы й выполняется пересылка, может действовать от ва­ шего и м е н и и п олучить доступ к удаленным системам . Он не сможет читать ваш и лич­ ные ключи н апрямую, но сможет использовать любые ключи, которые доступн ы через агент пересылки.

Глава 27. Безопасность

1 02 5

Сервер перехода

Клиент

Private servers

он же бастионный мост Соединение SSH с пересылкой ключа агента

Запускаем ssh-agent

Соединяемся отсюда с закрытыми серверами без копирования ключей

Рис. 2 7. З. Пересылка ключа агента с nоА1ощью утилиты ssh-agen t

Псевдонимы хостов в файле — / . s sh/ config В ы , н есо м н е н н о , стол кнетесь с м н ожеством разл и ч н ы х конфи гура ц и й оболоч к и S S H , есл и будете взаимоде йствовать с бол ьш и м кол ичеством серверов ил и управлять и м и . Чтобы упростить вашу жизнь, файл — / . ssh/config позволяет настраи вать псев­ дон имы и переопределять параметры отдел ьных хостов. Н а пр и м е р , расс мотр и м две с исте м ы . П е рвая — это веб-сервер с I Р- адресом 5 4 . 8 4 . 2 5 3 . 1 5 3 , где демон s shd просл уш и вает порт 2222. Допустим , что ваш е имя пол ьзователя на этом сервере — han , и у вас есть закрыты й кл юч дл я аутентифи каци и . Друго й сервер d e Ь i a n . a dm i n . сот, где ваш е и мя пол ьзователя — hsolo. В ы предпо­ ч итаете полностью откл ючать аутентификаци ю по парол ю , но сервер Deblan требует ее. Чтобы подкл юч иться к этим серверам из командной строки , вы можете испол ьзовать команды с таки м и параметрами. —

$ s sh -1 han р 2 2 2 2 — i /home/han/ . s sh/id_ecdsa 5 4 . 8 4 . 2 53 . 1 5 3 $ s sh -1 hsolo debian . admin . com —

В дан ном случае в настрой ках ваш его кл ие нта луч ш е всего выкл юч ить ауте нтифи ­ каци ю по парол ю (она вкл ючена по умол чан и ю ) , потому что каждый раз вводить в ко­ мандной строке параметр — о PasswordAuthentication=no сли ш ком обре мен ител ьно. Следующие настройки из файла — / . s sh/config задают псевдонимы для этих хостов и допол н ител ьно позвол я ют откл ючать ауте нтификацию по парол ю по умолчани ю. P a s s wo r dAut h e n t i c a t i on no H o s t web H o s t Name 5 4 . 8 4 . 2 5 3 . 1 5 3 U s e r han I de n t i t y F i l e / h ome / h an / . s s h / i d e c d s a Fo rwa r dAge n t y e s Port 2 2 2 2 H o s t deЬian H o s tname deЬ i a n . admi n . com User hsolo P a s s wo rdAu t h e n t i c a t ion ye s

Теперь вы можете ис пол ьзовать гораздо бол ее простые команды s sh web и s s h deЬian дл я доступа к эти м хостам. Кл и е нт сч иты вает псевдо н и м ы и автоматически устанавл и вает параметры для каждой систем ы . Утил ита ssh также пони мает некоторые базовые шаблон ы для сопоставления хостов. Н апример, так.

часть lV. Эксплvатация

1 02 6 Ho s t * S e rv e rAl i ve i n t e rv a l 3 0m S e rve rAl i ve C ountMax 1 Host 1 7 2 . 2 0 . * U s e r l u ke

В этом примере утил ита s sh разорвет соединение с любым из серверов, есл и оно не будет активно более 30 м и н . Она также использует имя пол ьзователя luke при подкл ю­ ч е н и и к хостам в сети 1 72 . 20/ 1 6. П се вдони м ы хостов — это оче н ь мощное средство, особен но есл и они испол ьзуются в сочетании с другим и возможностя ми протокола OpenSS H .

М ул ьтиплекси рова ние соеди нения Co n t r o lMa s t e r — отличная возможность утилиты ssh, которая позволяет мул ьти­ пле ксировать соединения, что значительно повы шает скорость работы протокола S S H п о ка налам глобальной сети . Есл и эта возможность включена, т о первое подключен и е к хосту создает сокет, который затем можно испол ьзовать повторно. При последующих подкл ючен иях будет испол ьзоваться этот общий сокет, но для них требуется выпол н ить отдел ьн ы й процесс аутентификации. Для в кл юч е н и я м ул ьт и п л е кс и ро ва н и я задайте параметры C o n t r o l M a s t e r , C o n t ro l Pa t h и C o n t r o l Pe r s i s t в директиве H o s t определения псевдонима, как по­ казано н иже Ho s t web H o s t Name 5 4 . 8 4 . 2 5 3 . 1 5 3 U s e r han Port 2 2 2 2 Cont rolMa s t e r a u t o Cont r o l P a t h — / . s s h / cm_s o c ke t / % r @ % h : % p C on t r o l Pe r s i s t 3 0m

П араметр Co n t ro l Ma s t e r a u t o активирует эту фун кцию, а C o n t r o l P a t h создает сокет в указанном месте . Параметр ы подстановки , которые могут использоваться в име­ н и файла Con t ro l Pa t h , описаны на справочной странице man s sh_confiq. В данном случае файл называется в соответствии с именем пользователя удаленного хоста, е го I Р­ адресом и номером порта. При подкл ючен и и к этому хосту будет создан приведе н н ы й н иже сокет. $ ls -1 / . ssh/cm_socket/ s r w — — — — — — — 1 b e n ben О �

Jan

2

15 : 22

[email protected] 5 4 . 8 4 . 2 5 3 . 1 5 3 : 2 2

Такой ш аблон гарантирует у н и кал ьное и м я файла для каждого сокета. П араметр C o n t r o l P e r s i s t сохраняет сокет в течен и е указан ного периода врем е н и , даже есл и первое (главное) соединение будет разорвано. Вся н астрой ка зай м ет у вас 30 с. П осле этого сделайте пожертвова н и е в фонд Open B S D , чтобы поблагодарить их за внедре ние мул ьтиплексирован ия и эконом ию ва­ шего времени.

П роброс портов Еще одной полезной вспомогател ьной фун кцией протокола S S H является его спо­ собность безопас но тун нел ировать ТС Р-соедин ен и я через заш ифрова н н ы й канал , тем сам ы м обеспечивая возможность подключ е н ия к удал е н н ы м хоста м , которые сч итаются

Глава 27 . Безопасность

1 02 7

небезопас н ы м и ил и защищены брандмауэрами. На рис. 27.4 показано ти пичное испол ь­ зование туннеля S S H и поясняется, как это работает.

Chrome ssh

Случайный порт

Сервер SSH

Случайный порт

Порт 8000

Порт 22

БРАНДМАУЭР

Внешняя система

Сторона Интернета

sshd

Случайный порт

Веб-сервер

Сторона предприятия

httpd

Порт 80

Рис. 2 7 .4. SSН-туннель для протокола Н ТТР

В этом случае удале н н ы й пол ьзовател ь, допуст и м , Ал иса, хочет установить Н ТТР­ соединение с веб-сервером в сети предприятия. Доступ к этому хосту ил и порту 80 бло­ кируется брандмауэром , но, имея доступ к S S H , Ал иса может маршрутизировать соеди­ нение через S S H -cepвep. Чтобы настроить эту возможность , Ал иса входит в систе м у н а удал е н ном S S H ­ cepвepe с помощью утил иты s sh. П р и этом в командной строке s sh она указывает про­ и звол ьн ы й (но кон кретн ы й , в нашем случае 8000) локал ь н ы й порт, дан н ы е с которого утил ита s sh должна перенаправлять через защи ще н н ы й тун нел ь на порт 80 удаленного веб-сервера. $ s sh -L 8 0 0 0 : weЬserver : 8 0 server . admin . com

Все порты отправителя в этом примере поме•1ены как случайные, так как программы сами выбирают произвольный порт, из которого можно иници ировать соединения. Чтобы получить доступ к веб-серверу предприятия, Ал иса теперь может подкл юч ить­ ся с помощью браузера к порту 8000 своего ком п ьютера. М естн ый демон s shd примет это соеди н е н и е и перенаправит траф ик Ал исы по существующе м у S S Н -соеди н е н и ю к удал е н ному демону s shd. В свою очередь, удал е н н ы й де мон s shd перенаправит дан ­ н ы е Ал исы н а порт 8 0 веб-сервера. Разумеется , тун нел и , подобные эти м , могут стать преднамере н н ы м и ил и непред­ н а м е ре н н ы м и л азе й ка м и . И с пол ьзуйте тун н ел и с осторож ностью, а также след и ­ те за несанкцион ирован н ы м испол ьзован и е м это й возможности пол ьзовател я м и . В ы можете откл юч ить проброс портов в де моне s shd, задав параметр конфи гурации A l l owTCPFo rwa rd i n g no.

Демон s shd: сервер OpenSSH Демон сервера OpenSS H , s shd, прослуш и вает порт 22 ( по умолчан и ю) дл я соединений с клиентами . Его файл конфигурации, /etc/ ssh/ sshd_config, может похвастаться м но­ жеством опций, некоторые из них вам , возможно, потребуется настроить самостоятельно.

1 028

часть lV. Эксплvатация

Демон s shd работает от имен и пользователя root. Он создает непривилегированный дочерний процесс для каждого подключен ного клиента с тем и же правами, что и подклю­ чаемый пол ьзователь. Есл и вы внос ите измен ения в файл s shd_config, то можете при­ нудительно перезагрузить демон sshd, отправив сигнал НUР родительс кому процессу. $ sudo kill -HUP $ ( sudo cat /var/run/ s shd . pid)

В систем е Li nux вы также м ожете запустить команду sudo s y s temct l reload sshd. Изменения вступают в с ил у для новых подкл юче н и й . Существующие соеди нения не преры ваются и продолжают испол ьзовать свои предыдущие настройки. В следующем примере файла s shd_config содержит некоторые типичные парамет­ ры, настрое н н ые ради поиска баланса между безопасностью сервера и удобством поль­ зователя . # Задайте i n e t для поддержки толь к о про т о к ола I Pv 4 или # in e t б для поддержки т ол ь ко протокола I Pv б Addr e s s Fami l y а п у # П о з воляе т р е г и с трир о в а т ь с я толь ко ука з анным поль з о в а т елям и группам . # Д о в ол ь но же с т ки е о гранич ения . После добавления /удаления поль з о в а телей # т р е буе т с я пере з а грузка Al l owUs e r s f o o b a r h s o l o Al l owGroup s a dmi n s # Т С Р — п ер е н а п р а вление оче н ь удобн о , н о о н о може т б ыть н е бе з опасно Al l owT c p F o rwa r d i n g yes # Ото бража е т с о общение пер ед аутен тификацией поль з о в а т е л я . # Оч е н ь важно в случ а е испол ь з о в а н и я особых пр а в овых норм или с облюдения # о г о в ор е нных з а р а н е е т р е б о в аний Bann e r / e t c /banne r # Мы предпочи т а ем р а з р е ши т ь т ол ь ко аутентификацию с помощь ю о т крыт о г о ключ а C h a l l e n g e Re s p on s eAut h e n t i c a t i on n o P a s s w o r dAu t h e n t i c a t i on no RSAAu t h eп t i c a t i on no G S SAPIAuth e n t i c a t i on n o H o s t b a s e dAut h e n t i c a t i o n n o Pub k e yAu t h e n t i c a t i on y e s # От ключ а т ь н е а кти вных кли е н т о в ч е р е з 5 ми н . C l i e n tAlive i n t e rval 3 0 0 C l i e ntAl iveC ountMax 1 # Испол ь з о в а т ь сжа тие в с е гда Comp r e s s i o n ye s # Не разре ш а т ь удале нным х о с там пробрасы в а т ь порты G a t eway P o r t s no # Фиксир о в а т ь в журнале неудачные попытки р е г и с тра ции LogLeve l VERBOS E # М ы уме н ь шили заданное по умолчанию значение с 6 до З MaxAu t hT r i e s З # Не р а зр е ша т ь п ол ь з о в а т елю r o o t напр ямую подключ а т ь с я к с и с теме # ( з а с т а вл я ем исполь з о в а т ь к оманду s udo ) P e rm i t Ro o t L o g i n no

Глава 27. Безопасность

1 02 9

# Запр е ща ем п ол ь з о в а т е л ям ус т а н а вли в а т ь с в о и параме тры окруже ния # в ф айле a u t ho r i z e d_ k e y s Pe rmi t U s e rEnvi r onme n t n o # Испол ь з о в а т ь в о зможн о с т ь » a u t h » д л я с о о бщений s y s l o g S y s l o g F a c i l i t y AUT H # Аннулир о в а т ь с е а н с с в я з и в случ а е п о тери Т С Р — с ое дин ения T C P K e e pAl i ve n o # Н е р а з р е ш а т ь п е р е н а пр а вление данных с и с т емы Х Wi ndow , е сли в в а ш е й # с и с т еме не испол ь зу е т с я э т а графич е с к а я оболочка X l l Fo rw a r d i n g n o

М ы рекомендуе м вам я в н о указывать приемлемые шифры и алгоритмы обмена кл ю­ чам и . Мы не указываем здесь детал и , потому что имена довольно дл и н н ые и в л юбом случае постоя нно м е н я ются . Следуйте инструкция м по настрой ке Ope n S S H от ком па­ нии Mozilla, которые можно найти на сайте goo . g 1 /Xxgx 7 H ( глубокая ссыл ка на w i k i . mo z i l l a . o r g ) .

П роверка кл юча хоста с помощью зап иси SSH F P Напом н и м , что кл юч и хоста сервера S S H обычно и гнорируются админ истраторам и и пользователя м и сервера. Облачные экземпляры усугубляют проблему, потому что даже адм и нистратор не знает кл юч хоста до входа в систем у. К счастью, для решения этой проблемы была создана запись D N S , известная как S S H F P. П редпос ыл ка закл ючается в том , что ключ сервера хран ится как зап ись D N S . Когда клиент подключается к неиз­ вестной системе, SSH просматривает зап ись SSH FP, чтобы проверить кл юч сервера, а н е просить пользователя проверить его. Утилита s shfp, доступ ная из g i t h ub . c om / x e l e r a n c e / s s h fp , генерирует записи ресурсов DNS S S H F P л ибо путем скан ирован ия удал е н ного сервера (флаг — s ) , л ибо путем разбора ранее принятого кл юча из файла known_hos ts (флаг -k; как и преды ­ дущ и й флаг испол ьзуется по умолча н и ю ) . Разумеется , л юбой из вариантов п редпола­ гает, что источ н и к кл юча правил ьн ы й . Например, следующая кома нда создает В N D­ совместимую запись S S H F P для s e rve r . a dmi n . с от. $ sshfp server . adllli n . com s e rve r . a dmi n . com I N S SH F P 1 1 9 4 a2 6 2 7 8 e e 7 1 3 a 3 7 f бa 7 8 1 1 0 f l a d 9bd . . . s e rve r . a dmi n . com I N S S H F P 2 1 7 c f7 2 d 0 2 e 3 d 3 f a 9 4 7 7 1 2 b c 5 6 f d 0 e 0 a 3 i . . .

Добавьте эти за п и с и в файл зон ы дом е н а ( н е заб ы вайте о коротких и м е н ах и $ 0R I G I N ) , перезагрузите зону и испол ьзуйте утил иту dig для проверки кл юча. $ dig server . admin . com . IN SSHFP 1 grep SSHFP ; < < > > D i G 9 . 5 . 1 Р 2 < < > > s e rv e r . admin . c om . IN S S H F P ; s e r ve r . a dmi n . c om . I N S S H FP s e rve r . admin . c om . 38400 IN S SH F P 1 1 9 4 a 2 6 2 7 8 e e 7 1 3 a 3 7 f б a 7 8 1 1 0 f . . s e rve r . admin . com . 3 8 4 0 0 I N S SH F P 2 1 7 c f 7 2 d 0 2 e 3 d 3 f a 9 4 7 7 1 2 b c 5 6 f . . —

. .

П о умолчан и ю утил ита s s h не обращается к зап ися м S S H F P. Добавьте пара­ метр V e r i f yH o s t Ke y DN S в файл / e tc/ s s h / s sh_ con f i g , чтобы включ ить эту про­ верку. Как и больш инство опций клие нта SS H , вы также можете передать параметры -о VerifyHostкeyDNS=yes в командной строке ssh при первом доступе к новой системе.

Часть lV. Эксплуатация

1 030

Вы можете автоматизировать этот процесс , создав запись SS H FP в сценариях и н и ­ циал изации сервера. И спользуйте динамический D N S или A P I ваш е го л юбимого про­ вайдера D N S для создания записи .

Передача файлов Ope n S S H и м еет две утилиты для передачи файлов: s cp и s ftp. На сторон е сервера демон s shd запускает отдельн ы й процесс под названием s ftp- server для обработки передачи файлов. П ротокол SFТ P не и меет отношен и я к старому и небезопасному про­ токолу передачи файлов FТР. Вы можете испол ьзовать утил иту scp для копирования файлов из ваш е й систе м ы на удале н н ы й хост, с удаленного хоста в вашу систему ил и между удаленн ы м и хостами. Синтаксис напоминает команду е р с н екоторыми дополнениями для обозначения хо­ стов и имен пользователей. —

$ s cp . /file server . admin . com : $ scp server . admin . com : file . / file $ s cp serverl . admin . com : file server2 . admincom : fi le

Утил и та s f tp и меет и н терактив н ы й характер и похожа на традицион н ы й FТР­ клиент. Существуют также графические и нтерфейсы S FТ P для бол ьш инства настольных операционных с исте м .

А л ьтернативы для безопасного входа в систе му В бол ьш инстве с истем и сетей для безопасного удаленного доступа испол ьзуется па­ кет OpenSSH , но это н е единстве н н ы й выбор. D ropbear это реал изация S S H , в которой особое в н и мание уделено сохранению компактности. Она ком п ил ируется в статически связанн ую бинарную верси ю размером 1 1 0 Ки Б, идеально подходящую для маршрутизаторов потребител ьского класса и других встроен н ых устройств. Она обладает таким и фун кция м и (как и пакет Open S S H ) , как ау­ тентификация с помощью открытого ключа и проброс портов аге нта. Сервер Teleport компании G ravitational еще оди н альтернативный SSH-cepвep, кото­ рый предлагает несколько преимуществ. Его модель аутентификации основана на истече­ нии срока действия сертификатов, что устраняет проблему распространения и настройки открытых ключей пользователей. Среди впечатляющих функций сервера Teleport до­ пол нительный журнал аудита для каждого подключения и отл ичная система совместной работы , которая дает возможность нескольким пользователям совместно испол ьзовать сеанс. По сравнению с системой OpenSS H , Teleport относительно новый и еще не про­ веренный сервер, но до сих пор в нем не было обнаружено н и каких уязвимых мест. М ы предполагае м , что компания G ravitational сохран ит стремительные тем п ы развития. Оболочка M osh , разработанная блестящей командой в Массачусетском технологи­ ческом институте, я вляется заменой оболочки S S H . В отличие от S S H , оболочка M osh работает с заш ифрованн ы м и и аутентифицирован н ы м и дейтаграммами U D P. Она пред­ назначена для повы ш е н ия с корости работы по WАN-соед и н е н и я м и для роум и н га . Например, вы м ожете возобновлять соединение, если вы переходите с одного I Р-адреса на другой или есл и ваше соединение разрывается. Впервые выпуще н ная в 20 1 2 году, оболочка Mosh и меет гораздо более короткую историю, чем OpenS S H , но за первые н е ­ с колько л е т в ней не было обнаружено никаких уязвим ы х мест с точки зрения безопас­ ности . Как и Dropbear, она используется гораздо реже, чем OpenSS H . —

Глава 27 . Безопасность

1 031

2 7 .8. БРАНДМАУЭРЫ П о м и мо защиты отдел ьных ком пьютеров, можно предп р инять меры дпя обес пече­ ния безопасности на сетевом уровне. Основны м и нструментом сетевой защиты я вляется брандмауэр, физическое устройство или часть програм м ного обеспечения, не допус ка­ ющие н ежелательн ые пакеты в с исте м ы или сети . Брандмауэры в н астоящее время ис­ пол ьзуются всюду. Их можно обнаружить как в настольных ком п ьютерах и серверах, так и в маршрутизаторах и корпоративном сетевом оборудовани и .

Брандмауэры, фил ьтрующие пакеты Брандмауэр , фил ьтрующий пакеты , ограни ч и вает виды трафика, проходя щего ч е ­ р е з и н тернет- шл юз ( ил и через внутре н н и й шлюз, раздел я ю щ и й дом е н ы в п ределах орган изаци и ) , ос новываяс ь на информац и и , извлеченной из заголовков п акетов. Это напоминает прохожде н ие тамож н и , когда вы на свое м автомобиле пересекаете гран и ­ цу. Админ истратор указы вает, какие целевые адреса, номера портов и типы протоколов я вля ются допустим ы м и , а брандмауэр просто отбрас ывает (в н екоторых случаях также регистрирует) все пакеты , которые не соответствуют зада н н ы м критерия м . В системах семейства Linux фильтрация пакетов осуществляется с помощью утил иты iptaЬles (и ее более удобного в испол ьзовании аналога ufw) , а в с истем е Fгee B S D с помощью команды ipfw. П одробно они рассматриваются в разделе 1 3 . 1 4. Н ес мотря на то что эти инструменты с пособ н ы вы пол н ять сложную ф ил ьтраци ю и знач ител ьно повышают степень безопасности , в целом м ы разочарован ы испол ьзова­ н ие м с истем U N IX и Linux в качестве сетевых марш рутизаторов и особенно в качестве корпорати вных маршрутизаторов , и грающих роль брандмауэров. Сложность у н и вер­ сальных систем сн ижает их защищен ность и н адежность по сравн е н и ю со специал ь­ н ы м и устройствами. Для защиты корпоративных сете й лучше при м е н я ть специальные брандмауэры , например устройства компани и Check Point и Cisco. —

П ринципы фильтра ции служб Большинству » известных» служб назначается сетевой порт в файле /etc/ services ил и его с исте мно-зависимом экви вале нте. Демо н ы , которые реал изуют соответствую­ щие службы, прослуш и вают порты, ожидая поступл е н ия запросов на подключение со сторон ы удаленных компьютеров. В основном такие порты я вля ются » привилегирован ­ н ы м и » . Это значит, что и х номера находятся в диапазоне от 1 до 1 02 3 и что порты могут испол ьзоваться тол ько процессам и , работающими от и м е н и пол ьзователя root. Порты с номерами 1 024 и выше я вляются непривилегированн ы м и . Ф ил ьтрация на уровне служб ос нована на предположен и и , что кл иент (комп ью­ тер , и н и ц иирующи й соединение по протоколу ТС Р ил и U D P) будет испол ьзовать не­ при вилегирова н н ы й порт дпя установл е н ия соедин е н ия с при вилегирова н н ы м порто� сервера. Например, есл и вы хотите разреш ить тол ько входя щие НТТР-соедин е н ия для ком пьютера с адресом 1 92 . 1 08 . 2 1 . 200, то следует создать фил ьтр , которы й позвол ит на­ правлять ТС Р- пакеты только на порт 80 и отправлять ТС Р- пакеты с этого адреса че­ рез л юбой порт. � Способ создания такого фильтра будет зависеть от типа испол ьзуемого маршрутизатора.

» П орт 80

это стандартн ы й порт протокола НТТР. оп ределенн ый

в

файле /etc/ services.

1 03 2

Часть lV. Эксплуатация

В современных организациях, которые заботятся о безопасности , испол ьзуется двух­ ступе нчатая фильтрация. Оди н фильтр в этой схеме подкл ючен к И нтернету как шлюз, а второй н аходится между эти м шлюзом и остал ьной частью локальной сети. Идея со­ стоит в том , чтобы сконцентр ировать все входящие подключения со стороны И нтернета только на комп ьютерах, расположенных между эти м и двумя фильтрами . Если эти про­ межуточн ые ком пьютеры адм и н истративно отделе н ы от остал ьной части сет и , по­ я вляется возможность реали зовать разл ич н ые службы И нтернета с меньш и м риском . Ч астично защищенная сеть обычно называется «демилитаризованной зоной» ( DM Z ) . Н аиболее безопасным способом использования фильтрации пакетов является настрой­ ка первоначальной конфигурации, которая не позволяет н и каких входящих соединений. Затем можно постепенно ослабить фильтрацию, выяснив полезные службы , которые не работают, и перенеся все службы , доступные из И нтернета, в дем илитаризованую зону.

Бра ндмауэры , осуществля ющие и нспекцию па кетов с отслежива нием состоя н ия соединен ий В основе инспекции пакетов с отслеживанием состоян и я соединений лежит кон ­ цеп ц и я , которую можно описать с помощью следующего примера. Представьте себе , что вы и щете террориста в переполнен ном аэропорту, внимательно прислуш и ваясь ко всем разговорам, происходящ и м вокруг вас , и понимая их содержание (на всех язы­ ках). Брандмауэры , осуществляющие инспекцию пакетов с отслежи ван ием состояния соединений (statefu l inspection firewalls) , п роверяют весь трафик, проходящий через них, и сравнивают e ro с текущей сетевой активностью в ожидан ии события , которое «долж­ но» произойти. Например, если в пакетах, обмениваемых в рамках видеопоследовател ьности по про­ токолу Н . 32 3 , указан порт, которы й впоследствии должен использоваться дпя обмена дан н ы м и , то брандмауэр должен проверить, что обмен данн ы м и происходит именно че­ рез этот порт. Попытки удаленного хоста соединиться с другим и портами заранее сч ита­ ются фальшивыми и должны пресекаться. Так что же на самом деле предпагают разработчи к и под в идом инспекции пакетов с учетом состоян и я протокола. Их продукты либо осуществляют монитор и н г ограни ­ чен ного количества соеди н е н и й или протоколов, л ибо распознают конкретн ы й н абор » неблагоприятных» с итуаци й . В этом нет ничего плохого. Очевидно , что из л юбой тех­ нологи и , с пособной распознавать аномал и и трафика , можно извлечь п ол ьзу. Однако в данном случае важно помн ить, что все эти обещан ия преимущественно я вляются лишь реклам н ы м ходом .

Наскол ько безопасны брандмауэры Фильтрация пакетов не должна быть основ н ы м средством защиты о т хакеров. Это всего лишь оди н из ком понентов, которы й заслуживает тщательного рассмотрен ия при создании м ногоуровневой систе м ы безопасности. П р и наличии брандмауэра порой соз­ дается ложное впечатление, будто уровень безопасности является исключительно высо­ ким. Есл и , доверившись брандмауэру, ослабить бдительность на других » рубежах» , это отрицательно с кажется на защищенности всей вашей сети . Каждый ком пьютер н еобходимо защ ищать и ндивидуал ьно и ре гулярно п роверять с помощью таких средств, как Bro , Snort , N map, Nessus и O S S EC. Следует также обучать пол ьзователе й правилам безопасной работы в системе. В противном случае вы просто создадите внешне устойчивую, но крайне запутанную внутри систему.

Глава 27. Безопасность

1 03 3

В идеале локальные пользователи должны и меть возможность подключаться к л юбой службе И н тернета, но доступ к локальным службам со стороны и нтернет-хостов должен быть огран ичен дем илитаризованной зоной. Например, к серверу архивов может быть разрешен S FТР-доступ, а к почтовому серверу, получающему входящую почту, — доступ только по протоколу S MTP. Для того чтобы интернет-канал работал с максимальной эффективностью, советуем все же обратить основное внимание на удобство работы и доступность. В конце кон цов, сеть становится безопасной благодаря бдительности систе м ного адм и н истратора, а не благодаря брандмауэру.

2 7 9 ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ (VPN) .

.

В просте йшем виде виртуал ьная частная сеть (Virtual Private Networks — VPN ) это с пециал ьн ы й тип сете вого соеди н е н и я , эмул ирующе rо непосредствен ное подкл юче­ ние удален ной сети , даже если в действительности она находится за тысячу километров и скрыта за м ножеством маршрутизаторов. Для повышения безопасности соедин е н ие не тол ько подвергается аутентификации в том ил и и ном в иде (обычно с использование м общего «секретного кл юча » , например кодовой фразы) , но е ще и ш ифруется. Эrо на­ зывается защищенным туннелем. П р и веде м п р и м е р с итуа ци и , в которой сеть VPN оказы вается о ч е н ь кста­ ти. Предположи м , ком пания и меет офисы в нескол ьких городах: Ч и каго , Боулдере и Майами . Есл и каждый офис подкл ючен к локал ьному провайдеру И нтернета, то по­ средством виртуальных частных сетей компания может п розрачн ы м образом ( и , главное , вес ьма безопас но) соедин ить все офисы через такую ненадежную сеть, как И нтернет. Разумеется , такого же результата м ожно достичь и за счет покуп ки выдел е н н ых каналов связи , но это обойдется гораздо дороже . В качестве еще одного примера можно взять ком панию, служащие которой подкл ю­ чаются к сети предприятия из дому. Наличие виртуал ьных частны х сетей позвол ит слу­ жащим пользоваться преимуществами с воих в ысокоскоростн ых и н едорогих домаш них каналов в И нтернет, и в то же время работать так, будто они н епосредствен н о подкл ю­ чены к корпоративной сети . Благодаря удобству и популярности такого подхода м ногие компани и стали п редла­ rать реш е н и я , связан ные с сетью VPN . Функции поддержки VPN могут быть реал изова­ ны в маршрутизаторе , в операцион ной системе и даже в специализирова нном сетевом устройстве . Если позволяет бюджет, рассмотрите ком мерческие предложе н и я , в избытке имеющиеся на рынке . Если ж е вы ограничены в средствах , обратитесь к пакету SS H , которы й позволяет орган изовать защище нные туннели путем проброса портов (раздел 27.7). —

Туннел и I Psec Те , кого и нтересует н адежное и н едорогое ре шение в области VPN , соответствую­ щее стандартам I ETF, должн ы обратить внимание на протокол J Psec ( J ntemet Protocol Security — механизм защиты протокола I P) . И значально он был реали зован для прото­ кола 1 Pv6, но теперь доступен также и для 1 Pv 4. I Psec это одобре нная орга ни зацией 1 ETF с истема аутентификации и шифрова н ия соединен и й . П рактически все серьезные поставщики VРN -систем оснащают свои п родукты по крайней мере режимом совмести­ мости с I Psec. С исте м ы Linux и Free BS D содержат поддержку технологи и I PSec , встро­ енную в ядро. —

Часть lV. Эксплvатация

1 034

Для аутентификации и ш ифрования механизм I PSec использует сильные криптогра­ ф ические ал горитм ы . Ауте н ти ф и кация гарантирует, что пакеты приходят от легального отправителя и по дороге не был и искаже н ы , а шифрование предотвращает несанкцио­ н ированн ы й просмотр содержимого пакета. В тун н ел ьном режи м е систе ма ш и фрует заголовок транспортн ого уров н я , содержа­ щ и й номера портов отправителя и получател я . К сожал е н и ю , этот механизм напря­ мую конфл иктует со способом работы больши нства брандмауэров . П о этой п р и ч и не в больши нстве современных реал изаций по умолчан и ю используют транспортный ре ­ жим , в котором шифруется только содержимое пакетов (т. е . передаваем ы е дан н ые ) . Существует одна тонкость, связан ная с тун неля м и I Psec и параметром M T U пере­ давае м ых пакетов. Важно уб ед ит ься в том , что пакет, заш ифрованный средствами I Psec, н е подвергается фрагментации при прохожден и и тунн еля. Для этого может потребовать­ ся с н изить знач е н ие MTU для сетевых интерфейсов, расположен н ых п еред тун нелем (обычно подходит значен ие 1 400 байт). Подробнее о параметре M T U расс казывалось в разделе 1 3 . 2 .

Та к л и уж нуж н ы виртуа л ьные частн ые сети К сожалению, у в иртуал ьных частных сете й есть и недостатки. О н и позволя ют орга­ низовать достаточно надежный тун нель через ненадежный канал связи между двумя ко­ нечными точ кам и , но о н и , как правило, не защищают сами конечные хосты . Например, если создать тун нель VPN между корпоративной сетью и домашн и м компьютером пре­ зидента ком пан и и , то можно ненароком открыть удобную лазейку дл я 1 5-летнего вун ­ деркинда, по ночам наведы вающегося в пап и н кабинет. Хорошо, если он испол ьзует эту возможность л и ш ь для и гр по сети с одноклассн и ками . А есл и нет? Отсюда вывод: соедин е н и я , устанавл и ваем ы е через тун нели VPN , следует рассма­ тривать как вне ш н ие и предоста влять и м допол нительные привил е ги и л и ш ь в случае крайн е й н еобходимости , тщател ьно взвеси в все за и против . Можно добавить в свод правил безопасности , п р ин ятый в организаци и , специальный пун кт, касающийся ра­ боты в сети VPN .

2 7 1 0 СЕРТИФИ КАТЫ И СТАНДАРТЫ .

.

Если содержание этой главы ошеломило вас , не беспокойтесь. Ком пьютерная без­ опасность — сложная и необъятная тема, которой посвящен ы бесчисленные книги, веб­ сайты и журналы. К счастью, для оценки и орган изации существующей информации б ыло сделано немало. Существуют десятки стандартов и сертификаци й , и разумный ад­ м и нистратор должен их знать.

Сертифи к аты Круп н ые корпорации часто нанимают постоян н ых сотрудников, работа которых за­ ключается в защите и нфор м а ц и и . Для того чтобы поддерживать высокую степень ком ­ петентности в этой области , эти профессионал ы посещают тре н ин ги и получают серти­ фикаты. Если вам придется работать с некоторыми из этих сертификатов, приготовьтесь запом нить массу аббревиатур. Од н и м из наиболее ш и роко п ризнан ных сертификатов я вляется C I SS P ( Certified lnformation Systems Security Professional сертифицированный специалист по безопас­ ности и нфо рмац ион н ы х систе м ) . Этот сертификат выдается орган и зацией ( I SC)2, пол-

Глава 27. Безопасность

1 03 5

ное название которой звуч ит так : l nternatioпal lnformation Systems Security Certification Consortium , или Международный консорциум по сертификации безопасности информа­ ционных систем ( попробуйте произнести это в десять раз быстрее! ) . Одной из главных особен ностей сертификата C I SS P я вляется представление организац и и ( ISC)2 об «об­ щей совокупности знани й » ( «common body of knowledge — С В К) , которая по существу представл яет собой сам ые эффекти вные методы работы в области и н формационной безопасности. Ком плекс С В К охваты вает законодательство, криптографию, аутентифи­ кацию, физическую безопасность и м ногое другое. Это невероятно авторитетны й серти­ фикат в среде специалистов по безопасности. Н едостатком сертификата C I SS P является излишняя ш ирота охвата и , как следствие, недостаток глуби н ы знан и й . В ком плекс СВК входит м ного те м , которые необходимо и зучить за короткое время! Для того чтобы реш ить эту проблему, орга н и зация ( I SC)2 создала специал ьные програм м ы C I S S P, посвященные архитектуре , технике и управле­ н и ю . Эти специализирова н н ые сертификаты придают глуби н у более общем у сертифи­ кату C I S S P. Институт системного администрирования , сетей и безопасности (System Administration, Networking, and Security l nstitute — SANS l nstitute) в 1 999 году создал н абор сертификатов GloЬal l nformatioп Assuraпce Certification, или Глобальная сертификация информационно­ го обеспечения (G IAC). Три дюжины разных экзаменов охватывают всю область инфор­ мационной безопасности тестами, разделенными на пять категорий. Сертификаты ранжи ­ руются по сложности — от умеренного уровня G I S F с двумя экзаменами до экспертного уровня G S E с 23-часовым экзаменом . Экзамены на получение сертификата G S E печально известны как самые трудные в дан ной и ндустрии. М ногие экзамены нацелены на техни ­ ческое вопросы и требуют довольно большого опыта работы. В закл юч ен и е упомян е м мандат сертифи цированного аудитора и н формацион н ы х систем (Certified lпformation Systems Auditor — C I SA) , представляющий собой сертифи ­ кат с пециалиста по аудиту и процессам , связанн ы м с информационной безопасностью. Курс обуч е н ия дл я получения этого сертифи ката сосредоточен на бизнес — п ро цессах, процедурах, мон итори н ге и других вопросах управления. Н екоторы е специалисты счи­ тают сертификат C I SA п ромежуточн ы м и приемлем ы м для сотрудни ков, занимающихся безопасностью в организациях. Одн и м из преимуществ этого сертифи ката является то, что для е го получения достаточно сдать только оди н экзамен . Н есмотря на т о что сертификаты выдаются и ндивидуал ьно, их признан ие в деловой среде невозможно отрицать. В настоя щее вре м я все больше компани й сч итают сертифи­ кат признаком эксперта. М ногие ком пани и предлагают таки м сотрудн икам более высо­ кую зарплату и продвигают их по карьерной лестнице. Если вы реш ил и получить серти­ фи кат, убедите вашу орган изацию, чтобы она оплатила ваше обучение.

Стандарты безопасности Возрастающая роль информационных систем привела к появлению законов и указов правительства, регулирующих вопросы защиты конфиден циальной и нформации. М ногие законодательные акты С ША, такие как H I PAA, FIS MA9, N E RC C I P и SarЬanes-Oxley Act (SOX) , содержат разделы , посвяще н н ые и нформацион ной безопасности. Н есмотря на то что иногда удовлетворен ие этих требован и й связано с больш и м и затратами, они привлек­ ли внимание к важным аспектам технологии , которые ранее игнорировались.

»The Federal l nfonnation Sec u rity Management Ас! of 2002.

часть lV. Эксплvатация

1 036

W Допол н ител ьную и н ф о р м а ц и ю о п р о м ы ш л е н н ы х и зако н одател ь н ы х стандартах, влияющих на информационные технологии , с м . в разделе 3 1 .7.

К сожалению, эти законодательные акты содержат м ножество юридических терм и­ нов, которые иногда трудно понять. Большинство из них не содержит н и каких указаний н а то , как удовлетворить сформ ул и рован н ы е требования. По этой прич и н е , дл я того ч тобы помочь адм и н истраторам выпол нить требова н и я закона, были разработа н ы стандарты . Эти стандарты н е являются законодательны м и актами, но следование этим стандартам обычно обеспечивает согласование с законами . П оскольку сразу всем стан­ дартам соответствовать затруднительно, луч ше всего сначала пол ностью реал и зовать какой-то один из них.

ISO 2700 1 :20 1 3 Стандарт I SO/I EC 2 700 1 {бывш и й I SO 1 7799) я вляетс я , вероятно, сам ы м ш иро­ ко призна н н ы м в мире. В первые он был введен в 1 995 году как британский стандарт. Тогда он содержал 34 страницы и 1 1 разделов, которые охватывал и ш ирокий круг вопро­ сов — от пол итических до вопросов физической безопасности и управления доступом . Каждый раздел и м ел цел и , специфич н ы е требован и я и рекомендации оптимал ьн ы х практических решений. Этот документ стоит около 200 долл . Требования н е носят технический характер и могут быть выпол н е н ы л юбой орга­ н изаци е й самы м эффект и в н ы м способом . С другой сторон ы , ис пол ьзован и е общих слов оставляло у читателя ощущен ие сл и шком большой гибкости . Критики жалова­ л ис ь на то , что недостаток специфики оставляет орган изаци и незащи щен н ы м и перед атаками . Тем н е менее этот стандарт я вляется одни м из наиболее ценных документов в обла­ сти и нформационной безопас ности. Он создал мост над пропастью, пролегавшей между вопросами управления и техническими проблемам и , и помог обе и м сторонам м и н и м и ­ зировать риск.

РС/ DSS Стандарт Payment Card I ndustry Data Security Standard ( P C I DSS) и меет совершенно другую природу. Он возн и к вследствие возрастающей потребности повысить безопас ­ ность обработки платежн ых карт после ряда драм атических событий . Например , в 20 1 3 году правительство США обнаружило утечку информации о 1 60 м иллионах платежных карт, выпуще н н ых по л и цензии Visa, вкл ючая JC Penney. Это было круп н е й ш и м кибер­ преступлением в истори и США. По некоторы м оценкам ущерб от него составил более 300 млн долл . Стандарт P C I D S S является резул ьтатом совместных ус и л и й ком п а н и й Visa и M asterCard , хотя в данн ы й момент он поддерживается только ком панией Visa. В от­ личие от стандарта ISO 2700 1 , он находится в свободном доступе. Этот стандарт пол но­ стью сфокус ирован на защите данных о владельцах платежных карт и имеет 1 2 разделов, определяющих требован ия к этой защите. Пос кольку стандарт PC I D SS посвящен обработке платежн ых карт, он н е я вляется универсальным и не подходит для бизнеса, не имеющего дела с платеж н ы м и карта м и . Однако компан и и , собирающие данные о платежных картах, обязаны строго следовать этому стандарту, чтобы избежать крупных штрафов и возможного уголовного преследо­ вания. Этот документ находится на сайте pc i s e c u r i t y s t a nda rds . o r g .

глава 27. Безопасность

1 03 7

Документы NIST 800 Сотрудники организации National l nstitute of Standards and Technology ( N I ST) разра­ ботал и ряд документов под названием Special PuЫication ( S P) 800, в которых изложили резул ьтаты своих исследован и й , рекоме ндаци и и другую и н формац и ю , посвя ще н ную ком п ьютерной безопасн ости. Эти докуме нты часто испол ьзуются для оце н ки соответ­ ствия организа ц и й , и м е ющих дело с правительстве н ной и н формацией, требова н и я м федерал ьного закона С Ш А о б управл е н и и и н фор мацио н ной безопас ностью ( Federal I nforrnation Security Management Act) . Это открытые и доступные стандарты . Они имеют превосходное содержание и ш ироко применяются в пром ышлен ности. Серия SP 800 содержит более 1 00 документов. Все они доступ н ы на сайте c s r c . n i s t . gov / p uЫ i c a t i o n s / Pub s S P s . h tml . Документы , с которых целесообразно начи­ нать изуч е н ие стандартов, перечислены в табл. 2 7 . 3 . Таблица 2 7 3 Рекомендуемые публикации и з серии N IST SP 800 .

.

Номер

Название

800- 1 2

Ап

800- 1 4

Generally Accepted Principles and Practices for Securing lnformation Technology Systems

800-34 R 1

Contingency Planning Guide for lnformation Technology Systems

800-39

Managing Risk from l nformation Systems: An Organizational Perspective

lntroduction to Computer Security: The NIST Handbook

800-53 R4

Recommended Security Controls for Federal l nformation Systems and Organizations

800- 1 23

Guide to General Server Security

Станд арт Соттоп Criteria Документ Common C riteria for I nforrnation Technology Security Evaluation ( известн ы й под н азва н и е м » Common Criteria» ) это стандарт, по котором у о це н и вают уровен ь безопасности продукции и н формацион ных технологий. Эти рекомендации был и уста­ новл е н ы м еждународны м ком итетом , состоящ и м из представителей разн ых ком пан и й и отраслей промы шленности . Для ознакомления с этим документом и сертифицирован­ ными продуктам и посетите сайт commo n c r i t e r i a p o r t a l . o r g . —

OWASP Open Web Application Security Project ( OWASP) это н е ком м ерческая всем и рная орга н и зация , зан и мающаяся пов ы ш е н и е м безопасности п р и кл адного програ м м ного обеспече н ия . Она хорошо известна благодаря свое му спис ку » top 1 О » , посвящен ному рискам веб-приложен и й и предназначенному для повышения бдительности разработ­ чиков. Текущую версию этого списка и массу других материалов можно найти на сайте owa s p . o r g . —

C/S: Center for lnternet Security У це нтра C I S отличные ресурс ы для админ истраторов. Возможно, наиболее цен н ы ­ м и я вля ются контрольные показател и C I S , сбор н и к техн ических ре ком е ндаций п о на­ строй ке для обес печен и я безопасности операцион н ых систе м . В ы можете найти тесты для каждой из рассмотре н н ых в книге систем UN IX и Linux. В C I S также есть ори е н ­ т и р ы дл я поставщиков облач н ы х вычислен и й , мобил ьных устройств , програ м м ного обеспечения для настольных ком пьютеров , сетевых устройств и т.д. Подробнее читайте на сайте c i s e c u r i t y . o r g .

Часть lV. Эксплуатация

1 038

27.1 1 . Источники ИНФОРМАЦИИ по ВОПРОСАМ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ В б итве за безопасность с исте м ы половина успеха — знан ие современных разрабо­ ток в этой области . Если система оказалась взломанной, это вряд л и стало следствием применения технологической новинки. Скорее всего, маленькая бреш ь в броне систе м ы ш ироко обсуждалась в какой- н ибудь телеконференции или группе новостей.

Сервер Secu rityFocus.com и сп иски рассылки BugTraq и OSS Сервер S e c u r i t yFoc u s . с от специал изируется на сборе новостей и различной и н ­ формации по вопросам безопасности. В новостях п убли куются как общие обзоры , так и статьи , п ос вящен н ы е кон кретны м проблемам . Есть также обширная библиотека по­ лезных документов, удобно отсортированных по тематике. Програ м м н ы й архив сервера содержит инструментальные средства для м н ожества операцион ных с исте м . Программы снабжаются аннотациями и пользовательскими рей­ тингами . Это наиболее глобальный и исчерп ы вающий из известных нам архивов подоб­ ного рода. С писок рассьmки BugTraq — это форум для обсужден ия проблем безопасности и путей их устранения. Для того чтобы подписаться на него, посетите страницу s e cu r i t y f o c u s . c om / a r c h i v e . Объем информаци и , рассьmаем ы й по списку, может оказаться довольно значительным, и отношение «сигнал-шум» довольно плохое. Н а веб-сайте также хранится база данных с отчетами о рассмотрен н ых на форуме BugTraq проблемах. Список рассьm ки OSS (openwa l l . com/ l i s t s / o s s — s e c u r i t y) превосходны й ис­ точ н и к новостей из м ира разработчи ков п рограм много обеспечения с открытым исход­ н ы м кодом , связанных с безопасностью. —

Блог Брюса Ш найера Блог Брюса Ш найера ( B ruce Schneier) , посвящен н ый вопросам безопасност и , я вля­ ется цен н ы м и иногда увле кательны м источн и ком информаци и о ком пьютерной без­ опасности и криптографии. Кроме того, Ш найер я вляется автором ш ироко известн ых книг Прикладная криптография и Secrets and Lies. Информацию с e ro блога можно по­ лучать в виде ежемесячного бюллетеня под названи е м G rypto-G ram . Более п одробную информацию в ы найдете на сайте s c h ne i e r . c om / c r yp r o — g ram . html .

Отчет компании Verizon Data Breach l nvestigations Этот ежегодный отчет заполнен статистикой о причинах и источ н и ках наруше н и й защиты данных. В выпуске 20 1 6 года на основе анал иза 3 1 4 1 и н цидента б ыло сделано предположен и е , что около 80% наруш е н и й защиты данных я вляются финансово моти­ вированн ы м и . Ш пионаж находится на дале ком втором м есте. В этой публ и кации также классифицируются атаки, наблюдаемые на практике .

И нститут SAN S SAN S ( Syste m Administ ration, Networking , and Security l nstitute — И нститут систе м ­ ного и сетевого адми нистрирования и проблем безопасности) — это профессионал ьная организация, которая с понсирует конференции и обучающие семинары , посвященные

глава 2 7 . Безопасность

1 03 9

вопросам безопасности, а также публ икует различную и нформацию по данной темати­ ке . Ее сайт s a n s . org является цен н ы м информационн ы м ресурсом , занимающим про­ межуточное положен ие между сайтами SecurityFocus и С Е R’Г; он н е столь исчерпываю­ щий, как первый, но и н е такой скудный, как второй . Орган и зация SAN S рассылает по электро н ной по ч те ряд еже н едел ьных и ежем е ­ сяч н ы х бюллетен е й , н а которые можно подписаться н а ее веб-сайте . Ежен едел ьные N ewsBites являются информати вн ы м и , но ежемесячные обзоры похоже , содержат м ного шаблонной и н формации . Н и оди н из них не я вляется прекрас н ы м источн и ком ново­ стей из области безопасности .

И нфор м а цион н ые ресурсы отдельных дистри бутивов Проблемы, касающиеся безопасности, очен ь влияют на репутацию, поэтому поставщи­ операционных систем остро заинтересованы в том, чтобы помочь пользователям сделать свои систем ы безопасными. М ногие крупные поставщики ведут собствен ные списки рас­ сылки и публикуют в них бюллетен и по вопросам безопасности. Эrа же информация часто доступна и на веб-сайтах. Не редкость, когда защитные «заплаты» распространяются бес­ платно, даже если поставщики обычно взимают плату за программную поддержку. В И нтернете есть веб- порталы , например S e c u r i t y Fo c u s . com, на которых содер­ жится информация, касающаяся кон кретных производителей, и и ме ются ссылки н а по­ следние офи ц иал ьн ые пресс-рел изы . ки

Разработчики с исте м ы U buntu поддержи ва ют список рассылки . посвящен­ ный вопросам безопасности, по адресу: h t t p s : / / l i s t s . ubun t u . c om/ma i l ma n / l i s t i n f o /ubunt u — s e c u r i t y — announce

RHEL

Объя вления о продуктах ком пан и и Red Hat , связа н н ых с безопасн остью , рассылаются по с писку » Enterprise watch » , которы й расположен по адресу: h t t p s : / / redha t . c om/ma i lman / l i s t i n f o / e n t e rp r i s e — wa t c h — l i s t

Несмотря на то что советы по безопасности систе м ы CentOS почти всегда повторяют советы по безопасности систем ы Red Hat , вероятно, и меет смысл подписаться на ее рассылку по адресу: h t t p s : / / l i s t s . ce n t o s . o r g / p i p e rma i l / c e n t o s — ann oun c e /

Разработчики систем ы FreeBSD организовали активную группу по безопас­ ности со списком рассылки, расположен н ы м по адресу: h t t p s : / / l i s t s . f r e e b s d . o r g /mai lman / l i s t i n f o / f r e e b s d — s e c u r i t y

Другие списки рассылки и веб — сайты Перечислен н ые выше контактные адреса — л и ш ь небол ьшая часть интернет-ресур­ сов по вопросам безопасности . Учитывая объем имеющейся сегодн я и нформации , а так­ же скорость, с которой появляются и исчезают различные ресурсы , мы посч итали целе­ сообразным указать несколько » метаресурсов » . Хорошей стартовой площадкой я вляется веб-сайт l i n ux s e c u r i t y . com, н а котором каждый де н ь размещается нескол ько сообщен и й по вопросам безопасности с исте м ы Linux. О н также содержит постоян но обновляющуюся коллекц и ю советов по вопросам безопасности систем ы Linux, регистрирует происходящие события и поддерживает ра­ боту групп пол ьзователей.

Часть lV. Эксплуатация

1 040

( I N ) S EC U RE — это свободно распространяемый журнал , содержащи й и нформацию о совреме н н ых тенде нциях, а также и нтервью с вьщающимися специал истами в области безопасн ости. Правда, н е которые статьи в этом журнале следует ч итать с долей н едо­ верия — убедитесь, что их авторы не зан и м аются беззастенчивой рекламой с воей про­ дукци и . Linux �ekle N ews — это с и мпатичн ы й источн и к информации о ядре, безопасности , дистрибутивных пакетах и других вопросах. Раздел , посвященн ы й п роблемам безопас ­ ности, н аходится по адресу l wn . ne t / s e c u r i t y.

2 7 1 2 Что НУЖНО ДЕЛАТЬ в СЛУЧАЕ АТАКИ НА СЕРВЕР .

.

П режде всего, не пан и куйте! Скорее всего, к моменту обнаружен ия взлома большая часть ущерба уже нанесена. Возможно, хакер » гулял » по системе нескол ько н едель или даже месяцев. Вероятность того, что вам удалось выявить факт взлома , происшедше го всего час назад, близка к н улю. В с вете этого мудрая сова приказывает сделать глубокий вдох и н ачать тщател ьно проду м ы вать стратегию устранения взлома. Старайтесь не вспугнуть злоумышленника, во всеуслы шание зая вляя о происш ествии или вы полняя действия, которые могут на­ сторожить того, кто наблюдал за деятельностью орга низаци и на п ротяже н и и несколь­ ких недель. П одсказка: в этот момент н е плохо в ы пол н ить резервное коп ирова н ие . Надеемся , это н е удивит нарушителя?!l0 Стоит также напо м нить самому себе о том , что согласно исследова н и я м в 60% и н ­ цидентов, связа н н ы х с наруше н и е м безопасности , присутствовал » вн утре н н и й враг » . Н е и зучи в всех фактов , старайтесь н е посвящать в проблему л и ш н и х л юде й , к е м б ы они н и был и . Приведем коротки й план , которы й поможет адм и нистратору пережить кризис. Эoran 1 : не паникуйте. Во м ногих случаях проблема обнаруживается только спу­ стя какое-то время. Еще оди н -два часа ил и дня уже ничего н е решают. Однако имеет значение реакция н а событие — паническая или рациональная. Часто в резул ьтате возникшей пани к и ситуаци я только усугубля ется уничтожением важной и н форма­ ции , которая позволяет выявить нарушителя. Этап 2 : опредеJIИте адекватную реаIСЦИJО. Н и кому не в ыгодно раздувать ин­ ц иден т. Будьте благоразумн ы . Реш ите , кто и з персонала будет участвовать в реше­ нии возник шей пробл е м ы и какие ресурсы п р и этом должны быть задействован ы . Остал ьн ые будут помогать осуществлять » вынос тела» , когда все закончится . Этап З : соберите BCID в озио•ную инфориаЦИJD. П роверьте учетные и жур ­ н ал ь н ы е файл ы . Попытайтесь определ ить, где первонач ал ьн о произошел взлом . В ыполн ите резервное коп ирова н и е всех с исте м . Убедитесь в том , что резе р в ­ н ы е с м е н н ы е накопители физически защищены о т зап и с и , есл и вы помещаете и х в устройство для чтения. Этап 4 : оцените нанесенный ущерб . Определите , какая важная информация (есл и таковая и меется) » покинула» компан и ю , и выработайте подходящую страте­ гию с мягчен и я возможных последстви й . Оцените степень будущего риска.

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

Глава 27. Безопасность

1 04 1

Этап 5 : въr.церНИ’l’е шнур. Если это необходимо и возможно, отключите » взломан ­ н ы е » ком п ьютеры от сети . П ерекройте обнаруженные «дыры » . Организация C E RT предлагает инструкции по обнаружению взлома. Этот документ находится по адресу: c e r t . o r g / t e ch_t i p s / w i n — UN I X — s y s t em_comp romi s e . html

Этап б : разработайте стратеI’ИID восстановления . Соберите тол ковых л ю­ дей и обсудите план восстановления. Не занос ите е го в ком п ьютер. Сосредоточ ьтесь на том , чтобы потуш ить » пожар » и свести ущерб к м и н и м уму. И збегайте обви н е н и й в чей-л ибо адрес и л и нагнетания обстановки. Н е забывайте о психологическом уда­ ре, который могут испытать пользовател и . Пользовател и по своей природе доверяют други м л юдям , поэтому вопи ющее нарушение доверия часто заставляет м ногих лю­ дей замкнуться в себе . Этап 7 : сообщите о своем nпане. Расскажите пользователя м и управляющему персоналу о последствиях взлома, возможн ых будущих проблемах и предварител ь­ ной стратегии восстановления. Будьте честны и откровен н ы . И н циденты, с вязанные с безопасностью, являются н еотьемлемой частью совреме н н ых сете й. Это не отраже­ н ие ваших с пособносте й как системного адм и н истратора или чего-то другого, чего можно было бы стыдиться. Открытое признан ие возникшей проблемы 90% побе­ ды , если при этом вы демонстрируете , что у вас есть план выхода из с итуаци и. —

Этап 8 : воnпотите план в жизнь . Вы знаете свои систе м ы и сети луч ш е , чем кто бы то н и было. Доверьтесь плану и своему чутью. Посоветуйтесь с коллегами из других организаци й (луч ше всего с те м и , кто вас оче н ь хорошо знает) , чтобы убе­ диться в правил ьности выбранного направления. Этап 9 : сообщите об ИIЩИденте в соответств}’IОШ)lе орrаны. Есл и в и н ци ­ де нте участвовал » вн е ш н и й и грок», сообщите о б этом случае в организацию C E RT на горячую л и н и ю (4 1 2 ) 2 6 8 — 5 800, л ибо по эле ктрон ной почте ce r t @ ce r t . o r g . П редоставьте и м как можно больше и нформации.

Стандартная форма для отчета н аходится на веб-сайте c e r t . o r g . Н иже при веден с писок того, что желател ьно включить в отчет. •

И мена, модели » взломанн ых» ком пьютеров, а также установлен н ые на них операцион ные систе м ы .

Сп исок » заплат » , которые были установлены в с истеме на момент и н циде нта.

Список учетных записей, подвергшихся нападению.

И мена и I Р-адреса всех удаленных комп ьютеров , вовлече н н ых в и н цидент.

Контактная и нформация , если известн ы адми нистраторы удал е н н ых систем.

Соответствующие журнал ьные зап иси

и

дан н ые аудита.

Есл и есть подозре н и е , что вам и обнаруже на ранее н е и звестная проблема в про­ грамм ном обеспеч е н и и , следует также сообщить об этом ком пан ии-разработч ику.

27 •

.

1 3 Л ИТЕРАТУРА .

DvкsтRA, Jоs 1лн . Essential Cybersecurity Science: Build, Test, and Evaluate Secure Systems. Sebastopol , СА: O’ Reilly Media, 20 1 6 . FRAs E R ,

В . , Editor. RFC2 1 96: Site Security Handbook. tfc-editor.org, 1 997.

1 04 2

часть lV. Эксплvатация

GлRFI N KEL, S 1 м soN , G E N E S PAFFORD, AN D ALAN ScнwлRтz. Practical UNIX and lnternet Security (Зrd Edition) . Sebastopol , СА: O ‘ Reilly M edia, 2003.

KERBY, FRED, ЕТ AL. SANS lntrusion Detection and Response FAQ. SAN S . 2009 . s a n s . o r g / re s o u r c e s / i d f a q

Lvo N , GoRDON » FvoooR » . Nmap Ne twork Scanning: The Ofjicial Nmap Project Guide to Network Discovery and Security Scanning. Nmap Project , 2009 . К н и га о том , как ис­ пользовать программу nmap, написан ная ее создателе м .

R1sт1c, IvлN. Bulletproof SSL and ТLS: Understanding and Deploying SSL/ТLS and РК/ to Secure Servers and Web Applications. London, U K: Feisty Duck, 20 1 4.

Scн N EIER, BRtJCE. Liars and Outliers: EnaЬ/ing the Trust that Society Needs to Thrive. New York, NY: Wiley, 20 1 2.

ТномРsоN , K E N . Rejlections оп Trusting Trust in АСМ Turing Award Lectures: The First Twenty Years 1966- 1 985. Readi ng, МА: АСМ Press (Addison-Wesley) , 1 987.

Глава

28

Мониторинг

Стремление к постоянному мониторин rу ямяетс я отличительной характеристикой про­ фессионального системного адм и н истратора. Неопытн ые системные администраторы часто остамя ют системы неконтролируемыми и допускают обнаружение сбоев пользователями , когда разочарованный, сердитый сотрудник вызывает службу поддержки , поскольку н е мо­ жет вы полн ить постаменную задачу. И ногда групп ы администраторов создают платформу мониторинга, но отключают уведомления о сбоях в нерабочее время, чтобы лишний раз не расстраи ваться. В обоих случаях начинается rушение пожаров и имитация бурной деятель­ ности . Такие подходы негативно мияют на предприятие, усложняют усилия по восстанов­ лению его работы и портят репутацию системных администраторов. П рофесс ионал ьн ы е с истем н ы е адм и н и страторы вос пр и н и м ают мон итори н г ка к с вою рел и гию. Каждая система, прежде чем нач нет работать, добавляется на платфор­ му мон итор и н га, а затем регулярно проверяется и настраи вается с помощью м ногочис­ л е н н ых тестов. П оказател и и тенден ции оце н и ваются профилактичес к и , чтобы выявить проблемы до того, как они помияют на пользователей ил и поставят дан н ые под угрозу. Возможно, вы сл ышал и о том , что системы трансляции потокового видео выдают те­ леметрическую информацию так часто, что скорее произойдет отключение службы, чем сбой мон итор и н га. Без мон иторинга он и бы в л юбом случае не знал и , что происходит. М етодика упреждающе го мон иторин га (вм есте со связа н н ы м и с ней и нструментами) делает вас супергероем . Вы луч ш е пон и м аете с вое программ ное обеспече н и е и прило­ жени я , устраняете небольшие п роблем ы , прежде чем они нач нут накапл и ваться в ката­ строф ическую лави ну сбое в, и более эффективно находите ошибки, слабые места и по —

Часть lV. Эксплуатация

1 044

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

28. 1 . ОБЗОР МОНИТОРИН ГА Цел ь мониторинга — обеспеч ить правил ьное фун кционирование IТ-инфраструктуры , а также организовать сбор данных для управления и планирован ия в доступной и понят­ ной форме. П росто, не так л и’? Но это абстрактное описание носит сли ш ком общи й ха­ рактер. Реал ь н ы е системы мон итори н га разл и чаются по все м возможн ы м измере н и я м , но все они имеют одну и ту же базовую структуру. • •

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

Реальные системы мониторинга варьируются от три виал ьно п ростых до чрезвычай но сложных. Например, следующ и й сценарий на я зы ке Perl вкл ючает все перечислен н ые выше элементы. # ! / u s r / b i n / e nv p e r l $ l oa davg

=

( sp l i t / ( s , ] + / ,

‘ up t i me ‘ ) ( l O ] ;

# Если з а грузка больше 5 , уведомим сисадмина if ( $ l o adavg > 5 . 0 ) { s y s t e m ‘ ma i l — s » За грузка сервер а очень высока я . » d a n @ admi n . com < / d e v / n ul l ‘

Сценарий запус кает команду uptime для оце н ки средне й загрузки систе м ы . Есл и одноминутная средняя загрузка больше 5 , команда отправляет адм и нистратору сообще ­ н ие . Дан ные, оце н ка, реакция. В прошлом модные систе м ы мон итор и н га состояли из коллекций таких сценарие в , которые запус кались планировщиком cron и управлял и моде мом дл я отправки сообще ­ н и й на пейджеры с исте м н ых адм инистраторов. Сегодня у вас есть нескол ько вариантов на каждом этапе мон итори н га. Конечно, вы все равно можете писать и нди видуал ьные сценарии мон иторинга и за­ пускать их из план ировщика cron. Есл и это действител ьно все , что вам нужно, все м и силами стрем итесь к максимальной простоте. Однако, если в ы отвечаете н е за оди н ил и два сервера, этого упрощен ного подхода обыч но недостаточ но. В следующих разделах более подробно рассматриваются этапы кон вейерного подхода.

Инструментарий Ш ирокий спектр данных, которые могут оказаться полезными дл я вашей организации , включает показатели :эффе ктивности (время реакции , :эффе ктивность использования, ско-

Глава 28. Мониторинг

1 04 5

рость передачи ) , показатели доступности (доступность и врем я безотказной работы) , ем­ кость, изменения состояния, записи в журнале и даже бизнес-показатели, такие как сумма среднестатистической корзины покупок или коэффициент переходов по кликам. Поскол ьку все , что можно было бы сделать на ком п ьютере, потен ц иально может быть связано с мон иторингом, систем ы мон иторинга обычно являются агностическим и п о отнош е н и ю к источн и ка м дан н ых. О н и часто приходят с о встроен ной поддержкой разл и ч н ы х входных да н н ых. Даже источн и к и дан н ых, которые не и меют прямой под­ держки , обыч но м огут быть подключены с помощью нескольких строк кода адаптера ил и отдельного шлюза данн ых, такого как StatsD (см. раздел 28.4). Если вам приходится собирать сли ш ком бол ьшое количество данных, самой важной частью проектирования систе м ы сбора дан н ых становится выбор н аиболее важных по­ казателей и игнорирование ненужных. Избегайте сбора дан ных, которые не и меют чет­ кой и полезной цел и . Сбор данных переносит нагрузку как на систему мониторинга, так и на контрол ируемые объекты. Л и шн ие дан н ые также затмевают показател и , которые действительно важны , топя их в море шума. К сожалению, часто бывает непросто отличить полезн ые дан н ые от шлака. Вы долж­ ны постоянно пересматривать то, что контролируется , и переосмысли вать, как эти дан ­ н ы е будут использоваться в течение все го времени работы систем ы .

Ти п ы дан н ых На самом высоком уровне дан ные мон итори н га могут быть сгруппирован ы в три об­ щие категори и . •

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

События , которые часто при нимают форму записей в файле журнала или уведом­ лен и й , поступающих из подсисте м . Эти событи я , иногда называемые показате­ лями на основе шаблонов, могут указы вать на то, что произошло изменен ие состо­ я н и я , воз н и кла тревога или выполнено определенное действие. События могут обрабаты ваться дЛЯ форм ирования числовых показателе й (например, сум ма ил и скорость) или и н и ци ировать реакцию систе м ы монитори н га напрямую. 1

Совокупные и обобщенные исторические тенденции, которые часто представляют со­ бой временные ряды показателей в реальном времени. Они позволяют анализиро­ вать и визуализировать изменения, происходящие с течением вре мен и .

Ввод и обработка Бол ьш и нство с истем мон итори н га вращаются вокруг це нтральной платформы мо­ н итори н га, которая прини мает данные из контрол ируе м ых с исте м , в ыпол няет соответ1 Многие из дан н ых , собранных програ м м н ы м обеспечен ием для монитор и н га приложени й , по­ падают в категори ю «событие » ; иногда они также и меют кол и чествен н ы й характер. Взаимосвязи между события м и (напри м ер, «пол ьзователь п росмотрел стран и цу Н а стр о й к и , но затем отменил ввод, не измени в ничего» ) часто помогают исследовать ситуацию. Платформ ы мон иторин га обще­ го назначения, как правило, не очен ь хоро ш и для таких перекрестных ссылок , и это я вляется од­ ной из причин того, что м ониторинг п риложе н и й я вляется отдел ьной категорией .

1 046

Часть lV. Эксплvатация

ствующую обработку и применяет админ истративные правила для определения того, что должно произойти в ответ. П латформ ы первого покол е н и я , такие как N agios и l c i nga, был и сосредоточены на обнаружен и и возн икающих проблем и реагировании. Эти систем ы в свое врем я были револ юцион н ы м и и привели нас в современный м ир мон итори н га. Тем не менее со вре­ м е не м стало понятно, что все дан н ые монитор и н га я вляются дан н ы м и временных ря­ дов. Если значения не изменяются , вы не будете их контроли ровать. Очевидно, что необходим подход, более сильно ориентированный на данные. Однако дан н ые мониторинга обычно настолько объемные, что вы не можете просто сбрасы вать все это в традицион ную базу дан ных и позволять ей накапл и ватьс я . Это верн ы й путь к с н ижен и ю производительности и переполнению дисков. Современный подход — организация монитори н га на основе хран или ща дан н ых, ко­ торое специализируется на обработке временных рядов. В течение начального периода хранятся все дан ные, но по мере возрастания их объема происходит их агрегирование с учетом ограничений, связанн ых с хранением . Например, хранилище может сберегать дан н ые за час работы с точностью до одной секунды, за неделю — до одной м инуты и за год — до часа. И сторические дан н ы е полезн ы н е тол ько для презе нта ц и й , н о и для сравнен и я . Например, превы шает л и текущи й показатель сетевой ошибки, равный 2 5 % , его среднее значение за определенный период?

Уведо мления Создав с истему мон иторинга, внимательно изучите , что делать с результатами мони ­ торин га. Основным приоритетом обычно является уведомлен ие адми нистраторов и раз­ работчи ков о проблеме, которая требует внимания. Уведомл е н ия должн ы побуждать к действию. Структурируйте свою с истему мон ито­ ринга, чтобы каждый , кто получ ит дан ное уведомле ние , поте н циально мог что-то сде­ лать в ответ, даже если его действие будет чем-то общим, например, » проверить позже , чтобы убедиться, что меры приняты » . Уведомления, которые я вляются ч исто и нформа­ цион н ы м и , персонал обычно и гнорирует. В большинстве случаев уведомле н ия не должн ы ограничиваться электрон ной поч ­ той, чтобы быть оптимально эффективными. Для критических проблем проще и эффек­ тивнее всего посылать S М S-уведомлен ия (т. е . текстовые сообщения) на сотовые телефо­ ны адми нистраторов. Получатели могут устанавливать с вои м елодии звонка и громкость телефона, чтобы проснуться посреди ноч и , если это необходимо. Уведомлен ия также должн ы быть и нтегрирован ы с реализацией модел и ChatOps вашей командо й . М е н е е критические уведомле н и я ( н ап р и м е р , состоян и е зада н и й , неудачн ы е попытки регистрации в системе и и н формацион н ы е уведомления) можно отправл ять в оди н ил и несколько чатов, чтобы заинтересова н н ы е сторон ы могл и ак­ ти вно пол учать подмножества предупрежден и й , которые для них могут представлять и нтерес. W Допол нительную информацию о модели ChatOps см. в разделе З 1 . 1 . Пом и мо этих основных каналов, существует масса других возможностей . Например, в центре обработки дан н ых или в центре сетевых оп ерац и й для и ндикации состояния может оказаться полезной светодиодная система освещения, меняющая цвета в зависи­ мости от состоян ия с исте м ы . Другие варианты реагирования на ситуаци и , выя влен н ые с истемами монитори н га, включают следующее .

глава 28. Мониторинг

1 04 7

Автоматизированные действия , такие как сброс базы дан н ых или ротация журналов.

Вызов адм и нистратора по телефону.

Отправка данных на доску объявлений для общего доступа.

Хранение данн ых в базе дан н ых временных рядов для последующего анал иза.

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

Контрольные панел и и пользовательские и нтерфейсы П оми мо предупрежден и я о явно исключительных обстоятельствах, одной из основ­ ных целей мон итор и н га является представление состоян ия окружающей среды в более четком и понятном виде по сравнению с необработанн ы м и дан н ы м и . Такие представл е ­ ния назы ваются контрольными панелями (dashЬoaгds) . Контрол ьные панел и разрабаты ваются адм и н истраторам и или другими сторонам и , интересующимися кон кретны м и аспектами окружающей среды. Они используют разл ич­ ные методы для преобразования необработанных дан ных в информацион ную графику. Во-первых, контрольные панели и збирательны в том , что о н и представля ют. О н и концентрируются на наиболее важных показателях для данной предметной облас т и , которые указы вают на общую работоспособность или производительность. Во-втор ых, они дают контекстные подс казки о значимости и происхожден и и дан н ых, которые по­ казаны на панел и . Например, проблемные показатели и состоя н ия обыч но отобража ют­ ся крас н ы м цвето м , а ос новные показатели изображаются с помощью крупн ы х шриф­ тов. Отношения между значен ия м и показываются посредством группировки. В-третьих, контрольные панели отображают серию дан ных в виде диаграм м , что позволяет легко и х оце н и вать с первого взгляда. Конечно, бол ьшинство собранных дан н ых н икогда не появится на контрольной па­ нел и . Кроме того, желател ьно, чтобы ваша с истем а мон итор и н га и м ела обобщен н ы й и нтерфе йс, который облегчает исследование и изменение схе м ы дан ных, позволяет де­ лать произвол ьн ые запросы к базе дан ных и строить диагра м м ы произвол ьн о опреде ­ л е н н ых последовател ьностей дан ных » на лету » .

28.2. КУЛЬТУРА МОНИТОРИНГА Эта глава в ос новном посвя щена и нструментам мон итор и н га , н о не менее важной является кул ьтура монитор и н га. Начиная изуч е н ие монитори н га, и мейте в виду сл еду­ ющие принципы. •

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

Часть lV. Эксплvатация

1 048 •

Монитор и н г явл яется обязател ьным. В планах работы каждого систе м ного адми­ н истратора, разработч ика, сотрудни ка эксплуатационного отдела, руководителя и менеджера проекта должны быть предусмотрены меры по монитори н гу.

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

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

П равильно реал и зованн ы й мониторинг положительно влияет на качество жизни . Ч еткая схема мониторинга освобождает вас от бремени беспокойства о том , в ка­ ком состоян и и находятся ваши системы, и дает другим возможность поддерживать вас. Без мон итори н га и соответствующей документаци и вы по существу работаете в авральном режиме 24 х 7 х 365 .

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

28.3. ПЛАТФОРМЫ МОНИТОРИ НГА Если вы планируете контроли ровать несколько систем и более чем несколько пока­ зател е й , стоит потратить н екоторое вре м я на развертыван ие платформ ы монитори н га полного обслуживан ия. Это систе м ы общего назначения, которые собирают дан н ые из нескол ьких источников, облегчают отображение и обобщение информации о состоян и и систем и устанавливают стандартн ый способ определения действий и предупрежден и й . Хорошей новостью я вляется т о , что существует м н ожество вариантов. Плохая но­ вость закл ючается в том , ч то одной совер ш е н ной платформ ы п о ка н е существует. В ыбрав оди н из доступных вариантов, рассмотрите следующие проблемы. •

Гибкость сбора данных. Все платформы могут получать данные из разных источни­ ков. Однако это не означает, что все платформ ы эквивалентны в этом отношении. Рассмотрите источники данных, которые вы хотите использовать. Вам н ужно бу­ дет ч итать данн ые из базы дан ных S Q L? Из записей D N S? От НТТР-соединения?

Качество пользовательского интерфейса. М н огие системы предлагают настраивае­ мые графические интерфейсы или веб-интерфейсы. Сегодня в большинстве хоро­ шо продаваемых пакетов испол ьзуются шаблоны J SON для представления данных. Пользовательский и нтерфейс — это не просто очередной мар кетин говый ход; вам нужен интерфейс, которы й отображает и нформацию четко, просто и понятно. Вам нужны разные пользовательские интерфейсы для разных групп в вашей организации?

Стоимость. Н е которы е ком мерческие пакеты управл е н ия имеют высокую цену. М ногие корпорации считают престижны м , что их сеть управляется высококаче-

глава 28. мониторинг

1 049

стве н ной коммерческой системой. Есл и это н е так важно для вашей организации, рассмотрите бесплатные варианты , такие как Zabblx, Sensu , Cacti и lcinga. •

Автоматическое обнаружение. М ногие систе м ы предлагают » исследовать» вашу сеть. Благодаря сочетанию широковещательных сообще н и й , запросов SN M P, по­ иска в табли це ARP и DNS-запросов, они идентифицируют все локальн ые хосты и устройства. Все реализации исследования, которые мы видели , работают очень хо­ рошо, но в сложных системах и с истемах с большим количеством брандмауэров, их точ ность будет н иже. Функции отчетности. М ногие продукты могут отправлять опове ще н и я по элек­ тронной почте , взаи модействовать с моделью ChatOps, отправлять текстовые со­ общен ия и автоматически генерировать билеты для популярных с исте м отслежи­ ван ия неисправносте й . Убедитесь, что выбран ная вами платформа обеспечивает гибкую отчетность. Кто знает, с каким и электро н н ы м и устройствами вы столкне­ тесь через н есколько лет?

Платформы реал ьного времени с открытым ис ход н ым код о м Хотя платформы , рассмотрен н ые в этом разделе — Nagios, lci nga и Sensu Соге , — де­ лают всего понем ножку, они известн ы своей способностью обрабаты вать мгнове н н ы е ( ил и пороговые) показател и. У этих систем есть с вои сторо н н и к и , но как инструменты мон итори н га первого по­ кол е н ия они постепенно уступают системам временных рядов , о которых мы уже гово­ рил и выше. Начиная с нул я , лучше всего выбирать с исте м ы времен ных рядов.

платформы Nagios и lcinga Платформы Nagios и lcinga специализируются на вьщаче уведомлений об ошибках в ре­ жиме реального времени. Несмотря на то что они не помогают вам определить, насколько увеличилось использование вашей полосы пропускания в течение последнего месяца, они могут выследить момент, когда ваш веб-сервер перестанет отвечать на запросы. Платформ ы Nagios и lcinga первоначал ьно был и ветка м и одного дерева исходного кода, но современная версия lcinga 2 была полностью переписана. Тем не менее она по­ прежнему совместима с платформой Nagios во м ногих отноше н иях. Обе с исте м ы вкл ючают в себя м н ожество сценариев для мон итор и н га всех видов и объе мов, а также обширные возможности монитор и н га S N M P. Возможно, их самая большая сила — модул ьная и тон кая с истема настройки , которая позволяет вам п исать собствен н ые сценарии для мон иторинга любых м ыслимых показателе й . В ы можете состря пать на скорую руку новые мон иторы на языках Perl , Р Н Р, Python ил и даже С, если страдаете и зл и ш н и м самомн е н ие м ил и мазохизмом. М ногие стандарт­ ные методы уведомления уже реал изованы в виде электрон ной почты , веб-отчетов, тек­ стовых сообщен и й и т.д. Кроме того, как и при мониторин ге допол н ительных модул е й , н есложно создать собствен н ые сценарии уведомл е н и й и действий. Платформы Nagios и lcinga работают хорошо для сете й , состоящих из менее чем тыся­ ч и хостов и устройств. Они легко настраиваются и расш иряются и включают в себя такие мощные функции , как резервирование, удаленный мониторинг и эскалация уведомле ний. Если вы развертываете новую и нфраструктуру мониторинга с нул я , м ы рекомендуем lcinga 2, а не Nagios. Его кодовая база, как правило, более ясная , что хорошо способствует росту ч исла поклонн и ков и поддержки сообщества. С фун кциональной точки зре н ия его

1 050

Часть lV. Эксплуатация

пользовательский интерфейс более простой и быстрый, и он способен автоматически об­ новлять служебн ые зависимости , которые мoryr быть необходимы в сложных средах. платформа Sensu

Sensu — это самодостаточная система мон иторинга, которая доступн а как в верси и с откр ытым исходны м кодом (Se nsu Core ) , так и с платны м и , ком мерчески поддержи­ вае м ы м и н адс трой ка м и . Она имеет ультрасоврем е н н ы й и нтерфейс и может запус кать л ю б ы е устарев ш ие допол н ительные модули N agios, Icinga ил и Zabblx. Эта платформа была р азр аботана для замены N agios , поэтому совместимость с до­ пол н ител ьн ы м и модулям и является одной из самых привлекательн ых функций. Система Sensu по з воля е т легко использовать уведомл е н ия Logstash и Slack, а п роцесс ее и нстал ­ ляции очен ь п росто й .

Платформы времен ны х рядов с открытым исходн ым кодом Обнаружение и реагирование на текуШие проблемы — всего лишь один из аспектов мо­ н иторинга. Ч асто не менее важно знать, как значения меняются со временем и как они со­ относятся с др уги ми значениями. Чтобы удовлетворить эти потребности, бьmи разработан ы четыре популярные платформ ы временных рядов: Graphite, Prometheus, I nfluxDB и Munin. В эти х с истемах на первом плане и в центре внимания всей экосистем ы мониторин ­ г а находится база данн ы х . О н и отличаются своей степенью полноты в качестве авто­ номн ы х систем монитор и н га и в целом я вляются более модульн ы м и , чем традицион ные с и ст е м ы , такие как lcinga. В о з м о жно, вам понадобятся допол н ительные компоне нты для создан и я пол ной п латфо р м ы мониторинга. платформа Graphite

П л а тф орм а G гap h ite была, возмож н о , аван гардом нового покол е н и я платформ дл я м о н ит ори н га вре м е н н ых рядов. П о своей сути это гибкая база дан н ы х вре ­ м е н н ы х рядов с просты м в ис пол ьзова н и и языком запросов . П р и ч иной движе н ия # mo n i t o r i n g l ove и огро м н ого вли я н и я , которое платформ а G raphite оказывает на пользовател ьс ки е инте рфе й с ы , я вляется то, как она агрегирует и суммирует показате ­ л и . Она начала переход от еже м и нутного мониторинга к посекундному. Как в ы может е догадаться из назван ия , платформа G raphite включает в себя функ­ ции графического ото б р ажен и я для веб-визуализации. Однако этот аспект пакета не­ с коль к о затмил пакет G rafana. В наши дни система G raphite луч ш е известна благодаря другим ее ком понентам — Carbon и Whisper, которые составляют основу системы управ­ ления да н н ы м и . С исте м у G raphite мож н о комб и н и ровать с другим и и н струм ентам и для создания масштабируемой, распределен н о й , кластерной среды мониторинга , способной погло­ щать и публ и ковать сотни тысяч показателе й . На рис. 2 8 . 1 показана структурная схема такой р е али за ции . платформа Proтetheus

Нашей любимой платформой временного ряда сегодня является Prometheus. Это ком­ пле кс ная пл атформ а , которая включает и нтегрированные компоненты сбора, трендов и оповеще н и й . Ее ком поненты ориентированы как на системных адми нистраторов, так и на разработчи ков, что делает ее отличным выбором для методики DevOps. Однако она не допускает кластеризацию, т.е. не подходит для систем, требующих высокой доступности.

Глава 28. Мониторинг

1 051

Серверы UNIX и Linux collectd

collectd

collectd

collectd

carbon-relay (Graphite)

Graphite

Graphite

collectd

Показатели

Graphite

carbon-relay

carbon-relay

carbon-relay

Whisper

Whisper

Whisper

carbon-webapp

carbon-webapp

carbon-webapp

Балансировщик нагрузки Grafana SQLite

Apache httpd

Веб-подключения пользователей и администраторов

Рис. 28. 1. Кластерная архитектура платформы Graphite

Платформа lnfluxDB l nflux D B — чрезвычай но удобная для разработчи ков платформа монитори н га вре ­ м е н ных рядов, поддерживающая ш ирокий спектр языков програ м м и ровани я . Подобно G raphite , платфор ма l nflux D B — это всего л и ш ь механизм управл е н и я базой дан н ых вре м е н н ых рядов. Чтобы сформировать пол н ую с истему монитори н га, вкл ючающую в себя такие фун кци и , как оповещен и е , вам необходимо допол н ить пакет с помощью внешних ком понентов, таких как G rafana. Фун кции управления дан н ы м и lnflux D B намного богаче , чем переч ислен н ые выше альтернати вы . Однако допол н ительные функции l nflux D B также добавл я ют н екоторую н ежелательную сложность для ти пич н ых установок. Платформа l nflux D B и м еет нескол ько проблем ную истори ю ошибок и н есовмести­ мостей . Тем н е менее текущая версия выгл ядит стабильной и , вероятно, я вл яется луч ­ шей ал ьтернативой G raphite, есл и вы ищете автономную с истему управления дан н ы м и .

Платформа Munin Исторически платформа Munin пользовалась популярностью, особен но в Скандинавии. Он построена на интеллектуал ьной архитектуре, в которой допол нительные модули мя сбо­ ра данн ых не только предоставляют дан н ые , но и сообщают системе, как они должн ы быть представлены. Несмотря на то что Munin по-прежнему отлично подходит для использова­ н ия , для новых развертываний следует рассматривать более совреме н н ые решения, такие как Prometheus. В некоторых случаях Munin по-прежнему является полезным инструментом для мониторин га кон кретных приложений; см. ра:щел 28.7.

Часть lV. Эксплуатация

1 052

Платф ор м ы визуал изации д а н н ых с открыты м исходн ым кодо м Два основн ых варианта создания панелей мон итори н га и диаграмм — графические функци и , встроен н ые в платформу Graphite и более новый пакет G rafana . Платформа Graphite может извлекать дан н ые для визуал изации из хран ил ищ, отлич­ н ых от Whisper (собствен н ы й ком понент хранения дан ных в пакете G raphite) , но это не всегда я вляется простым решением . В качестве пакета, не зависящего от базы дан н ы х , G rafana отл и ч н о с п равляется с вне ш н и м и хра н ил и щами дан ных, включая все перечислен ное в предыдущем разделе. По последн и м подсчетам обеспечена поддержка 30 разных хран ил и щ . Первоначал ьно пакет Grafana задумывался как поп ытка улуч ш ить графику для платформы G raphite , так что с н и м вполне комфортно работать в среде Graphite. Обе платформ ы , G raphite и G rafana, имеют графический и нтерфе йс, напоминающий контрольную панель, которая может генерировать представления, облегчающие анал и з и удобн ы е для руководства. В ы можете испол ьзовать и х , чтобы отображать что-л и бо от н изкоуровневых системных показателей до показателей бизнес-уровн я . Пол ьзователи обычно отдают п редпочтение G rafana за превосходн ый и нтерфейс и более красивые гра­ фики. Пример контрольной панел и G rafana показан на рис. 28.2.

Рис. 28.2. Пример контрольной панели Grafana

Ко мм ерческие п латф ор м ы м он иторин га Сотни компани й продают программ ное обеспечение для мон итори н га, а новые кон ­ куре нты выходят на р ы нок каждую неделю. Если вы ищете ком мерческое решение, в ы должны по крайней мере рассмотреть варианты , перечисленные в табл . 28. 1 . Н езависимо от того , находятся л и их системы в облаке , на ги первизоре центра обра­ ботки дан ных или в с истемной стойке, больши нству предприятий не следует создавать собствен н ые средства монитор и н га. Аутсорси н г деш е вл е и н адежнее. Следовательно, если вам н ужен н абор инструментов для мон итори н га общего набора п риложе н и й ил и серверов, рассмотрите платформ ы Datadog, Librato, Signa!Fx или Sysdig Cloud.

Глава 28. Мониторинг

1 053

Таблица 2 8 . 1 . Популярные платформы коммерческого мониторинга Платформа

URL

Комментарии

Datadog

d a t a d o g h q . c om

Облачная платформа мониторинга приложений Огромный список поддерживаемых систем, приложений и служб

Librato

l i b r a t o . com

Система Plug апd Play с готовыми дополнительными модулями с от­ крытым исходным кодом

Moпitus

mon i t u s . ne t

Мониторинг платформы электронной коммерции

Piпgdom

p i n gdom . com

Платформа мониторинга SaaS•

SigпalFx

s i gn a l f x . c om

Платформа SaaS с длинным списком облачных интеграций

SolarWiпds

s o l a rw i n d s . c om

Платформа для сетевого мониторинга

Sysdig Cloud

s y s d i g . c om

Специальность: мониторинг и оповещение системы Docker П ростота корреляции событий между службами

Zeпoss

z e no s s . c om

Н евероятно сложная альтернатива l ciпga

‘ Не требуется установка программного обеспечения. Хорошо подходит только для веб-приложений.

При исследован и и платформ коммерческого мон итори н га сначала обратите в н и ма­ н ие на цену. Но не забудьте также изуч ить эксплуатацион ные детал и . •

Нас колько ле гко систе ма мон итори н га может б ы т ь в н едре н а в вашу систему управления конфигурацией? Как в системе мон иторинга разверты ваются новые допол н ител ьн ые модул и ил и модули проверок для ваш их хостов? Их выталкивают ил и вытяги вают? Хорошо ли система монитори н га сочетается с существующей платформой уведом­ л е н и й , если таковая имеется? Обеспечи вает л и ваша среда тип внеш него подключени я , необходим ы й дл я облач­ ного мониторинга?

Это все го л и ш ь часть вопросов, которые в ы должн ы задавать при исследова н и и платформ . В кон це концов, луч шая платформа для ва шей организации — это та , кото­ рая ле гко настраивается, соответствует вашему бюджету и легко прин и мается ваш и м и пол ьзовател я м и .

Размещен н ые платформы мон иторинга Есл и вы не заи нтересованы в настройке и обслуживани и собстве н н ы х средств мо­ н иторинга сет и , вы можете рассмотреть размещен ное (облачное ) реш е н и е . Существует м н ожество бес платн ых и ком мерческих опци й , но популярн ы м я вляется StatusCake ( s t a t u s c a ke . c om). Возможность внешнего провайдера видеть внутрен н ие детали вашей сети ограничена, но размещенные варианты хорошо подходят для проверки работоспо­ собности служб и неб-сайтов, ориентированных на широкую аудитори ю пользователей. Хости н г — п ровайдер с исте м ы мон итори н га может также ос вободить вас от о гра­ н и ч е н и й , наклады вае м ы х для обыч н ы х каналов в И нтернет, которы м и пол ьзуются в вашей орган изаци и . Если для передачи уведомлен и й из внутре н не й систе м ы мон ито­ р и н га вы испол ьзуете сеть своего хостинг-провайдера , как это в конеч ном итоге про­ исходит в бол ьш и нстве орга н и заци й , вы м ожете убедиться , что эта сеть сама контро­ л и руется и управляетс я , чтобы ее персонал смог оперативно отреагировать в случае возн и кнове н и я пробл е м .

Часть lV. Эксплуатация

1 0 54

28.4.

СБОР ДАННЫХ

В предыдущих разделах были рассмотрен ы разл и ч н ы е пакеты, которы е могут слу­ жить ядром с исте м ы монитор и н га сети. Однако выбор и развертыван и е одной из этих систем — это только первая часть процесса настройки. Теперь вы должны убедиться, что данные и события, которые в ы хотите отслеживать, доступн ы для центральной платфор­ мы мониторинга. Детали этого и нструме нтального процесса зависят от с исте м , которые вы хотите контроли ровать, и от философи и ваше й платформ ы мон итори н га. Во многих случаях вам н ужно написать несколько простых с це нарие в дл я преобразовани я и н формации о состояни и систе м ы в форм у, которую может понять ваша платформа мон итори н га. Н е которы е платфор м ы , такие как Icinga, поставляются с ш и роким набором допол н и­ тельны х модулей, которые собирают стандартные показатели из типичн ых контрол иру­ е м ых систе м . Другие , такие как G raphite и l nflux D B , не создают специальных возмож­ ностей для ввода дан н ых вообще и должн ы б ыть допол н е н ы и нтерфейсом , который выполняет эту роль. В следующих разделах м ы сначала рассмотри м статическую платформу для сбо­ ра дан н ых обще го н азначе н и я , а затем изу ч и м н е котор ы е и н стру м е нты и методы для управления типич н ы м и контролируе м ы м и с истемам и .

StatsD: п ротокол передач и общих да нных Демон StatsD был написан инженера м и компан и и Etsy как с пособ отслеживать все и вся в пределах их собствен ной среды . Это прокси-сервер на основе протокола U D P, сбрас ы вающий л юбые данн ые , которые вы вводите в него, на платформу мон итор и н га для анал иза, расчета и отображения. Преимущество StatD — е го способность принимать и выпол н ять вычисления произвольных статистических показателей . Демон StatsD ком па н и и Etsy б ыл написан для среды Node .js. Н о в наш и дн и имя » StatsD » относится с корее к протоколу, ч е м к л юбому и з м ногих пакетов программно­ го обеспечени я , которы е е го реал изуют. ( Правда, даже версия Etsy н е я вляется ори г и ­ нальной, в ее основу б ы л положен п роект с аналогичн ы м назван и е м на сайте Flickr. ) Реал изац и и Stat s D были н а п иса н ы на разных языках, но здесь м ы сосредоточили с ь на верс и и , выпущенной компанией Etsy. Для работы де мона Stats D требуется среда Node.j s , поэтом у перед установкой StatsD убедитесь, что Node .js была установлена и настроена соответствующи м образо м . Реализация Etsy не включена в больш инство репозиториев пакетов поставщиков опера­ ционных систе м , хотя другие верс и и StatsD часто в н их есть. П оэтому убедитесь, что вы не путаете их. П роще всего клонировать версию Etsy прямо из G it H ub: $ git clone https : / /githuЬ . com/etsy/ s tatsd

Демон StatsD н евероятно модульный и может подавать входные дан н ы е на множе­ ство серверов сбора данных и клиентов. Давайте рассмотри м простой пример, в котором дл я сбора данн ых используется G raphite. Чтобы обеспечить правильную связь G raphite и StatsD, в ы должны измен ить ком ­ понент хран ен и я Carbon систе м ы G raphite . Измените файл / e t c / c a r b o n / s t o r a g e ­ s chema s . c o n f и добавьте в него приведенный н иже раздел : [ s tat s ] p a t t e rn = л s t a t s . * r e t e n t i on s 1 0 s : l 2 h , lmi n : 7 d , 1 0m i n : l y =

Глава 28. Мониторинг

1 05 5

Эта конфигурация сообщает компоненту Carbon хран ить данн ы е , пол уч е н н ые в те­ чение 1 2 часов с и нтервалом в 10 с. Ком понент Carbon сум м ирует устаревшие дан н ы е с и нтервалом в 1 м и н . и сохраняет эту итоговую ин формаци ю е щ е 7 дней. Аналогично данные с 1 0- м инутной детал изацией сохраняются в течение все го года. В этих вариантах нет ничего волшебного; вам необходимо определить, что подходит для потребностей ва­ шей орган изации в хранении и собираемых данных. Точ ное определ е н и е того , что означает сум м иро в ать вре м ен н ые ряд ы , зависит от типа данн ых. Например, если вы подсчитываете сетевые ошибки, в ы , вероятно , хоти­ те сумм ировать, складывая значения. Если вы смотрите на показатели , представляющие загрузку системы или процент ее использовани я , вы, вероятно, захотите узнать и х сред­ ние значения. Вам также может потребоваться указать подходящие с пособы обработки отсутствующих данных. Эти политики указаны в файле /etc/carbon/ s torage -aggregation . conf. Если у вас еще нет рабочей инсталляции G raphite , вы можете использовать пример конфигу­ рации G raphite в качестве отправной точки: «

«

/usr/ share/doc/qraphite- carbon/examples / s toraqe — a99re9ation . conf . example

Н иже приведен ы некоторые разумные стандартные значен ия для включения в файл storage -aggregation . conf. [ mi n ] p a t t e rn = . l owe r $ x Fi l e s Fa c t o r = 0 . 1 a g g r e g a t i onMe t h o d

min

[ ma x ] p a t t e rn = . uppe r ( _ d + ) ? $ x Fi l e s Fa c t o r = 0 . 1 a g g r e ga t i onMe t h o d max =

[ s um] p a t t e rn = . s um$ x Fi l e s Fa c t o r = О a g g r e g a t i onMe t h o d

s um

[ c oun t ] p a t t e rn = . coun t $ x Fi l e s Fa c t o r = О a g g r e ga t i onMe thod

s um

[ count_l e g a c y ] p a t t e rn = л s t a t s c o u n t s . * x Fi l e s Fa c t o r О a g g r e g a t i onMe t h o d = s um =

[ de f a u l t_ave r a g e ] p a t t e rn = . * x Fi l e s Fa c t o r = 0 . 3 a g g r e ga t i onMe t h o d

=

ave r a g e

Обратите вниман ие: в каждом разделе конфигурации указано регулярное выражение pa t t e r n , с помощью которого сопоставляются имена рядов дан н ых. Раздел ы сч итыва­ ются по порядку, и первый подходящий раздел становится управляющим спецификато­ ром для каждой серии данных. Например, серия с и м е нем s amp l e . count будет соответ-

часть lV. Эксплvатация

1 056

ствовать шаблону дпя раздела [ co u n t ] . Знач е н ия будут свернуты путем суммирования точек данн ых ( a g g r e g a t i onMe thod = s um). Параметр xFi l e s Fa c t o r определяет минимальное количество выборок, необходимых дпя значительного сокр ащен ия вашей метрики. Он выражается как ч исло от О до 1 , пред­ ставл яющее процент н енулевых значений, которые должны сушествовать на более дета­ лизированном уровне, чтобы уровен ь свертки и мел н енулевое значение. Так, установка x F i l e s Fa c t o r дпя [ mi n ] и [ max ] в приведенном выше примере составляет 1 0% , поэтому даже одно значение данных будет соответствовать этому критерию, учитывая наши на­ стройки в файле s torage — s chema . conf . По умолчанию это значен ие равно 50%. Если эти параметры задан ы непродуманно, вы получите неточн ые или отсутствующие данн ые! М ы можем отправить н екоторые тестовые дан н ые демону Stat D с помощью систем ы Netcat (команда nc ) : $ echo » sample . count : l l c » 1 nc -u -wO statsd . admin . com 8 12 5

Эта команда поме щает значен и е 1 в качестве показателя подсч ета ( как указано в параметре с) в набор данных s ampl e . c o u n t . П акет поступает н а порт 8 1 25 на сайте s t a t s d . a dm i n . с от ; этот порт демон s tatsd прослуш ивает по умолчанию. Есл и наш н абор дан ных отображается н а контрольной панел и G raphit e , вы готовы собирать все виды данных монитори н га с помощью одного из м ногих клиентов Stat D. Н а страни це wiki S tatsDGitнuЬ ( g i thub . com/ e t s y / s t a t s d /wi k i ) приведе н с писок клиентов, ко­ торые могут общаться с помощью протокола StatsD. Или можете написать собствен н ы й! П ротокол прост и е го возможности бесконеч н ы .

Сбор дан н ы х из вывода ко манды Л юбую информацию, полученную из командной строки , можно отслеживать на ва­ ш е й платформе монитори н га. Все , что н ужно, — написать нескол ько строк сценар ного кода, чтобы извлечь и нтересующие вас фрагменты данных и перевести их в формат, ко­ торы й может принять ваша платформа мониторин га. Например, команда uptime выводит время непрерывной работы систе м ы , количе­ ство зарегистрирован н ых пользователей и среднюю загрузку систе м ы за последние 1 , 5 и 1 5 мин. $ uptime 0 7 : 1 1 : 5 0 up 2 2 d a y s ,

1 0 : 1 3 , 2 u s e r s , l o a d ave rage : 1 . 2 0 ,

1 . 41,

1 . 88

Ч еловек может проанал изировать этот вывод с первого взгляда и увидеть, что теку­ щее среднее значение загрузки систе м ы равно 1 ,20. Если вы хотите написать сценарий , чтобы регулярно проверять это значение или передавать е го другому процессу монито­ ринга, н ужно использовать команды обработки текста дпя вьщелен и я требуемого значе­ ния: $ uptime 1 perl -anF ‘ [ s , ] + ‘

‘ print $F [ 1 0 ] ‘

1 . 20

Здесь м ы испол ьзуем язык Perl дп я разделения вывода везде, где есть последователь­ н ость пробелов и запятых , и выводим содержимое десятого поля (среднее значение загрузки за одну м и н уту). Готово! Хотя в бол ьш инстве предметных областей язык Perl вытесняется современными языками , такими как Python и Ruby, он все еще остается ос­ н ов н ы м средством обработки текстовых строк. Вероятно, не стоит изучать Perl исклю­ ч ительно дпя этих целей, но е го способность формул ировать сложные текстовые преоб­ разования в виде однострочных команд очень пригодится.

Глава 28. Мониторинг

1 057

Мы можем легко развернуть этот одностроч н ы й сценарий в короткий код, которы й определяет среднюю загрузку сервера и отправляет е е демону Stat D. # ! /usr /bin /env perl use Ne t : : S t a t s d ; u s e S y s : : Ho s t name ; $ N e t : : S t a t s d : : HO S T = ‘ s t a t s d . a dmi n . corn ‘ ; $ l oadavg = ( s p l i t / [ s , ] + / , ‘ up t i me ‘ ) [ 1 0 ] ; N e t : : S t a t s d : : g a u g e ( ho s tnarne . ‘ . l oadAve r a g e ‘ = > $ 1 oadavg ) ;

Сравните этот код сценария с однострочной тестовой ком а ндой на предыдуще й странице и однострочн ы м кодом обработки вы вода команды uptime . Здесь язык Pe rl должен запус кать команду uptime и обрабатывать ее вывод как строку, так что эта часть выгл ядит несколько иначе, чем ее одностроч н ы й эквивалент. (В одностроч ном варианте мы испол ьзовал и режим автоматического разбиен ия строк в языке Perl . ) Вместо испол ьзования утил иты пс дл я сетевой передачи дан н ы х де мону Stat D м ы применяем простую оболочку Stat D, которую скачал и из архива С РА№. Это предпочти ­ тел ьн ы й подход; библиотеки более надежн ы , чем специальные сценари и , и их испол ь­ зован ие проясняет назначен ие кода. М ногие команды могут генерировать более одного формата вывода. П роверьте спра­ вочную стран ицу команды , чтобы узнать, какие параметры доступн ы , прежде чем пытать­ ся анализировать ее вывод. С одни м и форматам и гораздо легче работать, чем с другим и . Ряд команд поддерживают выходной формат, который с пециально облегчает разбор. У других есть настраиваемые систем ы вы вода, в которых можно запросить тол ько н е ­ обходимые поля. Еще оди н распростране н н ы й вариант — это флаг, который подавляет описательные строки заголовка на выходе .

2 8 . 5 . МОНИТОРИНГ СЕТЕЙ Во м ногих организациях мон итор и н г состоя н ия сети традиционно остается основ­ ной задаче й , для ре шения которой приходится окунаться в более ш ирокий мир разно­ образн ы х систем мон иторинга и контрольных панеле й . Поэтому е го мы и рассмотрим более подробно. В последующих разделах также описывается мон итор и н г операцион ­ н ых систе м , приложе н и й , служб и систем безопасности. Основ н ы м элементом сетевого мон итори н га я вляется тестовое зондирован ие сети с помощью эхо-запросов (пetwork piпg) с помощью так называе м ых I С М Р- пакетов. Более подробно техн ические детали рассматриваются в разделе 1 3 . 1 2 , вместе с команда­ ми ping и ping б , которые и н и ци ируют эхо-запросы из командной строки. Кон цепция проста: вы отправляете пакет эхо-запроса другому хосту сети , а реализация протокола I P этого хоста возвращает вам пакет в ответ. Если вы получаете ответ на свой запрос , то знаете , что все сетевые шлюзы и устройства, которые находятся между вам и и целевым хостом, работают. Вы также знаете , что целевой хост включен и что его ядро операцион ной систе м ы запущено и работает. Однако, поскол ьку эхо-запрос обрабаты­ вается стеком протокола TC P/I P, он не гарантирует получение информации о состоя н и и программ ного обеспечения более высокого уровня , которое может выпол няться на целе­ вом хосте . 2 Лол ная архи вная сеть языка Perl , cpan . o r g .

1 0 58

Часть lV. Эксплуатация

Эхо-запросы не создают больших нагрузок на сеть, поэтому их можно отправлять до­ статочно часто; скаже м , каждые десять секунд. Продумайте свою стратегию эхо-запросов, чтобы она охватывала все важные шлюзы и сети. Имейте в виду, что если эхо-запрос не может пройти через шлюз, то никакая система мониторинга н икогда не получит ответных данных, сигнализирующих о сбое в работе целевого хоста. Поэтому по крайней мере один набор эхо-запросов должен исходить из самого центрального узла мониторинга. Сетевые шл юзы не обязан ы отвечать на пакеты эхо-запросов, поэтому эхо-запросы могут быть отброше н ы перегружен н ы м шл юзом . Даже в правильно фун кционирующей сети время от време н и происходит потеря пакетов. Следовательно, не стоит тревожиться при первых признаках не приятносте й . И меет см ысл собирать дан н ы е об эхо-запросах в виде двоичных записей событий ( прошел-не прошел) и сводить их к совокуп ным по­ казателя м потери пакетов в процентах в течен ие более долгих периодов. Вам также может показаться и нтересн ы м измерить пропускную способность между двумя точками сети . Это можно сделать с помощью программы i Perf; с м . раздел 1 3 . 1 3. В большинстве сетевых устройств поддерживается простой протокол сетевого управ­ ления SN M P ( S imple Network Management Protocol ) , представляющий собой пром ы ш ­ л е н н ы й стандарт дл я име нован ия и сбора оперативных дан ных. Хотя S N M P ушел да­ леко за пределы своих сетевых корней, мы сч итае м его устаревшим для других цел е й , кроме базового сетевого мониторинга. SN M P — довольно бол ьшая тема, поэтому мы откладываем дал ьн е й шее обсужден ие этого вопроса. Дополнительную информацию с м . в разделе 28.9.

28.6. МОНИТОРИНГ СИСТЕМ Поскол ьку ядро управляет централ ь н ы м процессором с исте м ы , памятью, вводом ­ вы 11одом и перифе р и й н ы м и устройства м и , большая ч асть и нтерес ной и нформации о состоян и и с исте м н ого уровн я , которую в ы , возможно, захотите контрол ировать, на­ ходится где -то внутри ядра. Н езависимо от того , следите ли вы за кон кретной с исте ­ мой в ручном режи ме или настраи ваете автоматическую платформу монитор инга, вам нужны правильные инструменты для извлечения и отображен ия и н формации о состо­ я н и и систе м ы . В бол ь ш инстве ядер определ е н ы формальные канал ы , через которые такая и нформация экспортируется во вне ш н и й мир. К сожален ию, ядра похожи на другие типы програм много обеспечения; средства вы­ я вления ошибок, инструменты и функции отладки часто запаздывают. Хотя в последнее время с итуация я вно улучш илась, определение и пон имание точ ного параметра, кото­ рый вы хотите контрол ировать, может быть сложн ы м, а иногда и невозможным делом . Кон кретное значение часто можно получить нескол ьким и с пособа м и . Например, в случае усредне н н ых значе н и й загрузки систе м ы вы можете считы вать знач е н и я не­ пос редствен но из фа йла /proc/ l oadavg в системах Linux ил и с помощью команды sysctl -n vm . loadavg в системе Fгee B S D . Средние значения загрузки с истем ы также включаются в выходные данн ые команд uptime , w, sar и top (хотя для неинтерактив­ ноrо использования команда top — неудачн ы й выбор). Как правило, эти команды пред­ ставляют собой самый простой и эффективный доступ к значен иям , полученным непо­ средственно из ядра системы через sysctl или /proc. m Дополнител ьную информацию о файловой системе /proc см. в разделе 1 1 .4. Мон итор и н говые платформ ы , такие как Nagios и lciпga, вкл ючают богатый набор допол нительных модулей для мон итори н га, разработанных сообществом , которые вы можете испол ьзовать для получен ия доступа к контрол ируе м ы м элементам . Они также

глава 28. мониторинг

1 05 9

часто я вля ются п росто сценар ия м и , которые запус кают команды и анализируют полу­ ченный результат, н о уже протестирова н ы и отлажен ы и часто работают на нескол ьких платформах. Если вы не можете найти дополнительный модуль, который дает и нтересу­ ющее вас значен и е , вы можете написать собственный.

Ко м а нды дл я м ониторинга систем В табл . 2 8 . 2 перечислен ы несколько команд, которые обычно испол ьзуются при мо­ н итор и н ге. М н огие из этих команд дают совершенно раз н ы е результаты в зависимости от указан ных вам и параметров командной строки , поэтому для уточнения и нформации обратитесь к справочн ы м страницам man. Таблица 28.2. Команды , которые возвращают часто контролируемые параметры Команда

Доступная информация

м

Свободно е и занято е дисково е пространство и инде к с ны е де с крипторы Разм е ры каталогов Объе м сво бодн о й , занятой и вирrуальной памяти (файла подкачки) Производите льность диска и пропускная способность Открыты е файлы и с ете вы е порты Использовани е каждого проце ссора на многопроце ссорных систе мах Статистика процесса, проце ссора и памяти

du free iostat lsof 111p s tat vms tat

Команда sar (system activity report) — это команда для извлеч е н и я дан н ы х из ко­ м андной строки , так с казать, » ш вейцарс кий арм е йский нож» в обл асти мон итор и н га деятельности систе м . Эта команда и м еет оче н ь сложную историю, которая уходит кор­ н я м и в с истему System V U N IX, разработан ную в 1 9 80-х годах. 3 Основное в н и м ание в этой команде было направлено на ее реализацию в самых разных с истемах, что повы­ шает мобил ьность как сценариев, так и систе м н ых администраторов. К сожалению, она больше не поддерживается системах B S D . Пример, п р иведен н ы й н иже , запраш и вает отчеты каждые д в е секунды в тече н и е одной м инуты (т. е . 30 отчетов) . Аргумент D E V — это ключевое слово, а не заглуш ка для имени устройства или и нтерфейса. $ sar -n 17 : 50 : 43 17 : 50 : 45 1 7 : 50 : 45 1 7 : 50 : 45

DEV 2 30 I FAC E rxpc k / s t x pc k / s r x b y t / s t x b y t / s r x cmp / s t x cmp / s rxmc s t / s lc 3 . 61 3 . 61 2 63 . 4 0 2 63 . 4 0 0 . 00 0 . 00 0, 00 ethO 18 . 56 1 1 . 8 6 1 3 64 . 4 3 1 4 9 4 . 3 3 0 . 00 0 . 00 0 . 52 ethl 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00

Этот п р и м ер был выпол н е н на Linuх — м а ш и н е с двумя сетевы м и и н терфейсам и . Выход включает в себя как м гновенные, так и средние знач е н и я испол ьзования и нтер­ фейса в еди н ицах байтов и пакетов. Второй интерфейс (ethl) явно не испол ьзуется.

Сборщик обобщенных системн ых дан н ых collectd По мере эволюции работы по с истем ному админ истрированию она прошла путь от анализа дан н ы х в отдел ьных системах до управл е н ия больши м и набора м и виртуализи­ рованных экзе м пл яров. При этом используемые простые инструменты ком андной стро1 С истемных адми н и страторов старой ш колы часто распоз нают по с вободному владе н и ю коман ­ дой sar.

1 060

часть lV. Эксплуатация

ки начали создавать м ного сложностей в сфере монитори н га. Хотя написание сценариев для сбора и анал иза параметров обеспечи вает утилитарность и определенную гибкость, поддержание согласованности этой кодовой базы в нескольких с исте м ах быстро ста­ новится хлопот н ы м делом . Современные и нструменты, такие как col lectd, sysdig и dtrace , предЛагают более масштабируе мый подход к сбору дан н ы х этого типа. Сбор систе м ной статистики должен быть непрерывны м процессом , а решение U N IX дЛЯ текущей задачи — создать демон мя его обработки . Для этого рекомендуем исполь­ зовать col lectd, демон дr1я сбора систе мной статистики. Этот популярн ы й и зрел ый инструмент работает как в системе Linux, так и в системе Free BSD. Как правило, демон col lectd запускается в локальной системе, собирает по­ казатели через определенные и нтервал ы времени и сохраняет полученные значения. В ы также можете н астроить демон collectd дr1я запус ка в режиме клиент-сервер, где оди н или несколько экзем пляров collectd объединяют данн ые из групп ы других серверов. Спецификация собираемых показателей и мест назначен и я , в которых они сохраня­ ются , я вляется гибкой; доступны более 1 00 допол н ительных модулей , соответствующих сам ы м разным потребностям . П осле запуска демона collectd e ro дан ные могут быть запроше н ы платформой ( н апример, lcinga или Nagios) дr1я м гнове нного монитори н га или перенаправлены на платформу (например , G raphite или l nfluxD B) дr1я анал иза вре­ менных рядов. П ример файла конфигураци и демона collectd показан ниже . # # / e t c / c o l l e c t d / c o l l e c t d . c on f H o s t narne c l i e n t l . a drn i n . c orn FQDN L o o kup f a l s e I n t e rva l 3 0 LoadPlugin s y s l og < Plugin s y s l og> L o gLeve l i n f o < / Pl ugin> LoadPlugin cpu LoadPlugin df LoadPlugin di s k LoadPlugin inte r face LoadPlugin l oad L o a d P l u g i n rnerno r y LoadPlugin proce s s e s LoadPlugin r rdtool < Plugin rrdtool > D a t a D i r » / va r / l i Ь / c o l l e c t d / r r d » < / P l ug i n >

Эта базовая конфи гурация собирает множество интересных статистических данных с исте м ы каждые 30 с и записывает файл ы данных, совместимые с R R Dtool , в каталог /var / lib/ col lectd/ rrd.

Ут ил иты sysdig и dtrace: трассировки выпол нения Программ ы sysdig ( Linux) и dtrace ( BS D) обесп е ч и вают всесторо н н и й анал из активности ядра и пол ьзователя . О н и вкл ючают компоненты , котор ые помещаются в самое ядро, отображая не только глубинные параметры ядра, но и системные вызовы

Глава 28. мониторинг

1 061

д11 я каждого процесса и другие статистические дан ные о производительности. Эти ути ­ л иты и ногда называют «Wiгeshark д11 я ядра и процессов» . W Дополн ительную информацию о программе Wireshark см. в разделе 1 З . 1 2 . Обе эти утил иты я вл я ются сложн ы м и . Однако они заслужи вают внимания. И х из­ учен ие на досуге позвол ит вам освоить новые потрясающие возможности и обеспечить ваш высоки й рейтин г в среде с исте м н ы х админ истраторов. m Дополнительную информацию о системе Docker и контейнерах см. в главе 25. И нструме н т sysdig я вл яется ко нте й нером , поэтому он обес печи вает искл юч и ­ тельную видимость в средах, где используются и нструменты , такие как Docker и LXC . П рограмма sysdig рас п ространяется как утил ита с откр ытым исходн ы м кодом , и ее можно сочетать с други м и утил ита м и мон итор и н га, так и м и как N agios или l c i nga . Разработчики также пред11 аrают коммерческу ю сл ужбу мон итори н га ( Sysdig Cloud ) , ко­ торая обладает полной возможностью монитори н га и оповещения.

28.7. МОНИТОРИНГ ПРИЛОЖЕНИЙ Н а вер ш и н е пирам иды п рогра м м ного обес пече ния находится с вятой Граал ь — мо­ н итори н г приложе н и й . Этот ти п мон итори н га определе н довол ьно нечетко, но общая идея закл ючается в том , что он п ытается проверить состоян ие и производительность от­ дел ьн ых частей програ м м ного обеспечен ия , а не систем или сетей в целом . Во м ногих случаях мониторин г приложе н и й может достигать этих с истем и следить за их фун кци­ он ированием. Чтобы убедитьс я , что вы следите за правил ьн ы м и объектам и , вам нужн ы бизнес­ консул ьтанты и разработчики, которые могут рассказать вам бол ьш е о своих и нтересах и проблемах. Например, есл и у вас есть веб-сайт, которы й работает на основе LAM Р, вы, вероятно, захотите контролировать время загрузки стран ицы , выя вить критические ошибки Р Н Р, сохран ить эту и нформацию в базе данных MySQ L и отследить конкретн ые проблем ы , такие как чрезмерные попытки подкл юче ния. Хотя мон иторинг этого уровня может быть слож н ы м , в дан ной области он выглядит особе нно привлекательным. П редставьте себе мон иторинг (и красоч ный вывод на кон ­ трол ьную панель G rafana) дан ных о количестве виджетов, проданных за последни й час , ил и среднем периоде времен и , в течение которого товар остается в корзине покупок. Есл и вы п роде монстрируете разработч и кам приложе н и й и владел ьцам процессов этот уровен ь функционал ьности , то немед11 е нно получите заказ на допол н ител ьн ый мон ито­ рин г и даже можете получить помощь в его реал изации. В конце кон цов, этот уровен ь мон итори н rа становится бесце н н ы м д11 я бизнеса, и в ы нач и наете рассматри ваться как чемпион по мониторингу, метрикам и анализу дан н ых. Мониторинг уровня приложен и й может дать допол н ительное представление о других событиях в вашей среде . Например , есл и продажи виджета быстро снизятся, это может свидетельствовать о том , что одна из реклам ных сетей недоступ на.

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

Часть lV. Эксплvатация

1 062

ной форме, сложность реал изация этого кон вейера может варьироваться от тривиальной

ДО ВЫСОКОЙ.

Журн ал ы обычн о лучше все го анализировать с помощью ком пл ексной систем ы агре­ гации , предназначен ной для этой цел и . Такие систе м ы рассматривались в разделе 1 0.6. Хотя эти с исте м ы ориентированы прежде всего на централизацию журнальных дан н ых и упрощен и е поиска и просмотра, большинство систем агрегации также поддерживают функции порога, тревоги и отчетности . Если вам нужен автоматический анализ систе м н ых журналов дл я нескольких кон ­ кретных целе й и вы н е хотите связы ваться с более общи м и реше н и я м и дл я управл е ­ н ия журналам и , м ы рекомендуем несколько утилит м е н ьшего масштаба — l ogwatch и O S S EC. П рограмма logwatch это гибки й , пакетно-ориентирован н ы й а грегатор журналов. Его основное предназначение — создавать ежедневн ые с водк и событий , регистрируе ­ м ы х в журналах. Вы можете запускать программу logwatch чаще, чем оди н раз в день, но о н н е предназначен дл я монитори н га в реальном вре м е н и . Дл я этого в ы , вероят­ но, захотите взглянуть н а программу OSS EC , которая рассматривалась в разделе 2 7 . 5 . Программа O S S EC рекламируется как средство обеспечения безопасности с исте м ы , н о ее архитектура я вл яется достаточно обще й , что также можно использовать для других видов мониторинга. —

Su pervisor + Munin : п ростой вариант для некоторых п редметн ых областей Уни версальная платформа, такая как lcinga или Prometheus, может быть избыточной для ваших нужд ил и вашей среды. Что делать, если вы заинтересован ы только в мониторин­ ге одного конкретного процесса приложения и не хотите устанамивать полноценную плат­ форму мониторинга? Рассмотрите возможность объединения программ Munin и Supervisor. Они просты в установке, требуют лишь небольшой настройки и хорошо работают вместе. Про грамма Supervisor и ее серверн ы й процесс supervisord помогают отслеживать процессы и генерировать события или уведомления , когда процессы закан чивают рабо­ ту или вызывают искл ючение. Система похожа по духу на программу Upsta rt или на де­ мон systemd в части управления процессами. Ка к упоми налос ь выше, Munin я вляется общей платформой мониторин га с особыми с ил ьны м и сторонами в мониторинге приложен и й . Она написана на Perl и требует, чтобы агент, называемый узлом Munin, работал на всех системах, которые вы хотите контроли ­ ровать. Н астройка нового узла проста: установите пакет munin-node и отредактируйте файл munin-node . conf, чтобы указать в нем главную машину. Программа Munin по умолчани ю создает графики R RDtool на основе собранных дан ­ н ы х , поэтом у о н а является хорошим средством для получ е н ия н екоторой графической информации без сложных приготовле н и й . В месте с програм мой M unin распростран я ­ ются более 300 подключае м ых модулей и около 200 других доступн ы в виде библ иотек. Вероятно, вы можете найти существующий подключае м ы й модуль, соответствующий ва­ ш и м потребностям . Если нет, легко написать новый сценарий для пакета munin-node.

Комм ерческие средства мониторинга приложений Если ввести в поисковую с истему Google слова «appl ication monitori ng tool » ( » сред­ ство мон итори н га приложе н и й » ) , вы обнаружите м н ожество стра н и ц с ком мерчески-

Глава 28. мониторинг

1 063

ми nредложе н и я м и . Но сначала вам nридется продраться через м ножество сообще н и й о мон итори н ге nроизводител ьности nриложе н и й (АРМ ) . Вы увидите м ного ссылок на м етодологию DevOps. Это не случайно: мон итор и н г nриложе н и й и А Р М я вляются ключевы ми принциnами DevOps. Они предоставля ют ко­ л ичественные nоказатели , которые команды могут исnол ьзовать для определ е н ия того, какие области стека будут наиболее nолезны для усили й no nовышен и ю nроизводител ь­ ности и стабильности. W Дополнительную информацию о методологии DevOps см . в разделе З 1 . 1 . М ы с ч ита е м , что ком n а н и и N e w Re l i c ( n e w r e l i с . c o m ) и App D y na m ics ( a p p d y n a m i c s . c om) я вл я ются л идерами в этой области . Возможности этих с истем во м ногих отношен иях nерекрываютс я , но App Dynamics обычно нацел и вается больше на ре шение «nолного сте ка » . в то вре мя как New Relic бол ьше зани мается nрофил иро­ ванием nоведе н ия внутри самого nрикладного уровня. Н езависи мо от того, как вы контрол ируете свои nриложе н и я , крайн е важно, чтобы кома нда разработч и ков участвовала в этом процессе . О н и nомогут обес nеч ить м о н и ­ торинг всех важных nоказателей. Тесное сотрудничество n o мон иторингу способствует взаимосвязи между командами и устраняет дублирован ие.

2 8 .8. МОНИТОРИНГ БЕЗОПАСНОСТИ Мон итор и н г безопас ности — это отдел ьн ы й м ир. Эту область экс nлуатацио н ной nрактики и ногда назы вают оnерация м и no обеспечен и ю безоnасност и , ил и SecOps. Для мон итори н га безоnас ности среды могут быть привлече н ы десятки и нструм е н ­ тов с открытым исходным кодо м , а также коммерческих инструментов и служб. Третьи сторон ы , и ногда назы вае мые управляемыми поставщиками услуг безопасности (managed security service providers — M S S P ) , nредоставл я ют услуги сторо н н и х n оставщиков.4 Н есмотря на все эти варианты , нарушения безоnасности все еще ш ироко расnростране­ н ы и часто остаются незамеченными в течение нескольких месяцев ил и лет. Возможно, самое важное , что нужно знать о мон итори н ге безопас ности , — что н е ­ достаточ но nросто установить автоматизирова н н ы й инструмент или службу. В ы обяза ­ ны внедрить ком nлексную nрограмму обесnечения безоnасности , которая вкл ючает, как м и н имум , стандарты для nоведения nол ьзователей , хране н ия дан н ы х и nроцедур реаги ­ рования на и н циденты. Этой теме nосвящена глава 27. В ваш е й автоматизированной страте гии неnрерывного мон иторинга должны быть две фун кци и no обесnечен и ю безоnасности : проверка целостности систе м ы и обнару­ же н ие вторжен и й .

П роверка целостности системы П роверка целостности с исте м ы (часто называемая мон итори н го м целостности фа й ­ л о в и л и F I M ( fi l e i ntegrity monitoring) ) — это сравн е н и е текущего состоя н ия систе м ы с базо в ы м состоя н и е м . Ч аще всего эта проверка срав н и вает соде ржи м ое с исте м н ы х файлов (ядро, исnолняемые команды, файл ы конфи гураци и ) с криптоrрафически на-

•всегда существует соблазн отдать операции по обеспечению безопасности на аугсорсинr. В этом слу­ чае обеспечение безопасности вашей среды становится чужой проблемой . Но подумайте об этом так: стоит ли платить кому-то, чтобы тот присматривал за вашим кошельком, лежащи м на столе с 10 ООО других кошельков на оживленной железнодорожной стан ции’! Если да, то M S S P вам подходит!

Часть lV. Эксплуатация

1 064

дежной контрол ьной суммой , такой как S НА-5 1 2 . 5 Если значение контрольной сумм ы файла в текущей системе отл ичается от знач е н ия базовой верс и и , с исте м н ы й адми н и ­ стратор получает уведомление. Разумеется, необходимо учитывать регулярные меропри­ ятия по техническому обслуживанию, такие как запланированн ые изменения, обновле­ ния и исправления ; не все изменения являются подозрительными . Наиболее распростране н н ы м и платформами F I M я вляются Tripwire и O S S EC ; по­ следняя более подроб но описы вается в разделе 2 7 . 5 . Версия A I D E дп я Linux также вкл ючает мон иторинг целостности файлов, но, к сожалению, в версии дпя Fre e B S D этот компонент отсутствует. Чем проще — тем лучше. Отличная м и н имал ьная версия F I M утилита mtree , ко­ торая входит в поставку системы Free B SD и недавно бьmа перенесена в с истему Linux. Утилита mtree простой способ отслеживать изменения состояния файла и его содер­ жимого, которы й легко встраивается в ваши сценарии мониторинга. Н иже при веден пример простейшего сценария, испол ьзующего утилиту mtree. —

11 ! / Ь i n / b a s h i f [ $ 11 — e q О ] ; t h e n e c h o » mt r e e — c h e c k . s h [ -b v ] » create b a s e line » e c h o » -Ь e c h o » -v = ve r i f y a g a i n s t b a s e l i n e » exit fi 11 11 значение ключ а КЕУ= 9 3 9 4 8 7 6 4 6 8 1 4 6 4 11 # к а т ал о г для хр а н е н и я б а з ов о г о с о с т о яния D I R= / u s r / l oc a l / l i b / mt r e e — che c k if [ $1 = » -Ь » ] ; then rm — r f $ D I R /mt r e e — * cd $ D I R mt r e e -с — К s h a 5 1 2 — s $ КЕУ -р / s Ь i n > mt r e e s Ь i n fi i f [ $ 1 = » -v » ] ; t h e n cd $ D I R mt r e e — s $ КЕ У -р / s Ь i n < mt r e e s Ь i n 1 ma i l — s ‘» h o s t name ‘ mt r e e i n t e g r i t y c he c k » d a n @ a dmi n . com fi

С помощью флага — Ь этот сценарий создает и сохраняет базовое состояние. П р и по­ вторном запуске с флагом v он сравнивает текущее содержимое каталога / sЬin с базо­ вым состоянием. Как и во м ногих аспектах системного администрирования, создание платформ ы F I M и управление е ю с течением врем е н и являются совершенно раз н ы м и проблем ам и . Вам понадобится определ е н н ы й процесс , чтобы поддержи вать данн ы е F I M и реагировать на п редупрежден и я F I M . М ы предпагаем загружать и нформацию с платформы F I M в вашу и нфраструктуру монитори н га и оповещения, чтобы она н е отодвигалась в сторо­ ну и не игнорировалась. —

5Лриемле мые алгоритмы хеш и рования со временем меняются . Например, ал горитм M D5 больше не считается криптоrрафически защи щенным и в дальнейшем не долже н использоваться .

Глава 28. Мониторинг

1 06 5

Контрол ь обнаружения вторжен ий И с п ол ьзуются две рас простран е н н ые фор м ы с исте м обнаруже н ия вторже н и й (int rusion detection systems — I DS ) : на основе хоста ( host-based I DS — Н I DS) и н а ос нове сети (network-based I DS — N I DS). Системы N I DS исследуют трафик, п роходящий ч ерез сеть, и п ытаются иде нтифи цировать н еожида н н ые или подозрител ьные шаблоны е го поведе ни я . Наиболее распространенная система N I DS основан а на с истеме Snort и под­ робно освещена в разделе 27.5. Систе м ы H I DS работают как набор процессов, выполняемых в каждой системе. Как правило, они ведут таблицы, в которых записана разная и нформация, в частности сетевые соеди нения, моменты изменения файлов и контрольные сум м ы , журнал ы демонов и при­ ложе н и й , факты использования повы ш е н н ых при вилегий и другие моменты , которые могут сигнал изировать о работе средств, предназначенных для предоставления н есанкци­ онированного доступа к системе (так называемые руткиты) . Системы H I DS не являются универсальн ым решением для обеспечения безопасности , но это цен н ы й ком понент ком­ плексного подхода. Двумя наиболее популярными платформами H I DS с открытым исходным кодом явля­ ются O S S EC (Open Source S ECU RE) и AI D E (Advanced l nt rusion Detection Environment). По нашему опыту, OSSEC — лучший выбор. Хотя AI D E хорошая платформа F I M в си­ стеме Linux, платформа OSSEC имеет более широкий набор функций. Ее можно даже ис­ пользовать в режиме клиент-сервер, который поддерживают не- UN IХ-клиенты, такие как M icrosoft Windows и различные устройства сетевой и нфраструктуры . Подобно предупрежден и я м F I M , дан н ые H I DS полезн ы , тол ько если и м уделя ется внимание. H I DS — это не подсистема, работающая по принципу » установил и забьш » . Вы обяза н ы интегрировать предупрежден ия H I DS и ва ш у общую систему мониторинга. Н а иболее эффективная стратегия , которую м ы нашли для решен ия этой п робл е м ы , автоматическое открытие билетов на оповеще н и я H I DS в вашей с истеме вьщач и биле­ тов. Затем вы можете добавить контрол ьную проверку, которая предупреждает о любых н еобработанных билетах Н I DS. —

2 8.9.

S N M P: ПРОСТОЙ ПРОТОКОЛ СЕТЕВОГО УПРАВЛЕНИЯ

М н ого лет назад сете вая и ндустрия реш ила, что бьшо бы полезно создать стандарт­ н ы й протокол сбора дан ных монитори н га. В результате возни к протокол Simple Network Management Protocol , также известный как SN M P. Н ес мотря н а с вое название, протокол SN M P н а самом деле довольно слож ный. Он определяет иерархическое пространство и мен дан ных управления и методы для чте н ия и записи этих данных на каждом сетевом устройстве . П ротокол SN M P также определяет с пособ управления серверами и устройствами ( «агентами » ) для отправки уведомлений о событиях ( «ловушек») на станции управле ния. Прежде чем м ы углуби мся в тай н ы протокола SN M P, следует отметить, что с вязан ная с н и м тер м инология — одна из самых неудач ных в м ире сетей . Во м ногих случаях стан­ дартные названия кон цепций и объектов в протоколе S N M P акти вно уводят вас от по­ н имания того, что происходит. Те м не менее сам протокол прост; бол ьшая ч асть сложности S N M P лежит выше уровня протокола в соглашениях о построен и и пространства имен и ненужного вычур­ ного словаря , который окружает S N M P как защитная оболоч ка. Если н е сли ш ком м ного думать о его внутре ннем устройстве , протокол SN M P прост в испол ьзо ва н и и .

Часть lV. Эксплуатация

1 066

П ротокол S N M P был разработан для реал изации в специал из ирова нном сетевом оборудован и и , таком как марш рутизаторы , в контексте которых он остается вполне приемл е м ы м . Позднее S N M P расширился , включив мониторинг серверов и настольных с истем , но его пригодность для этой цели всегда вызывала сомнения. Сегодня доступны гораздо более эффективные альтернативы ( например, collectd, с м . выше). М ы предла гае м испол ьз овать SNMP в качестве протокола сбора дан н ы х н изкого уровня для использования с устройствами специал ьного назначен и я , которые не под­ держивают н иче го л и ш него. Получайте данн ые из мира SN M P как м ожно быстрее и пе­ реходите к платформе монитор и н га общего назнач е н ия для их хранен ия и обработки. S N M P может быть и нтересн ы м объектом экскурси и , но вы не захотите там жить!

Организаци я п р ото кола S N M P Дан н ые SN M P орган и зован ы в виде стандартизован ной иерарх и и . И ерархия и м е ­ нован и я состоит из т а к назы вае м ы х » баз управля ющей и н формации » ( Managem e nt Infoпnation Bases — M I B) структурированных текстовых файлов, которые описывают данн ы е , доступные через S N M P. Базы M I B содержат описания конкретных перемен ­ н ых, на которые ссылаются имена, называемые объектными идентификаторами ( 0 1 0)6• Все текущи е устройства , поддерживающие протокол S N M P, поддерживают структуру для M I B — 11 , определе н ную в с пе цификаци и R FC 1 2 1 3 . Однако кажды й производитель оборудования может рас ш ирить M I B , чтобы добавить больше дан н ых и показателе й , и часто пользуется этой возможностью. Идентификаторы 0 1 0 существуют в иерархическом пространстве имен , где узлы ну­ м еруются , а не называются . Однако для удобства ссылок узлы также и м е ют обыч ные текстовые имена. Разделителем для компонентов пути я вляется точка. Например, 0 1 0 , которы й указывает на врем я бе зотказной работы устройства, l . 3.6. l . 2 . l . l . 3 . Этот 0 1 0 также м ожет быть представлен в виде имен и , понятного для человека (хотя и н е всегда понятного без дополн ител ьного описания): —

i s o . o r g . d o d . i n t e r n e t . mgmt . mi b — 2 . s y s t em . s y s Up T i me

В табл . 2 8 . 3 п редставлена выбор ка 0 1 0 -узлов, которые могут быть и нтерес н ы для мониторин га доступности сети . Таблица 28.З. Избранные идентификаторы O I D и з базы M I B — 1 1

«

OIDa

Тиn

Соде ржани е

s y s t em . s y s D e s c r

Строка

Системная информация: производитель, модель, тип опера­ ционной системы и т.д.

i n t e r f a c e s . i f NumЬ e r

Целое число Количество сетевых интерфейсов

i nt e r fa c e s . i fT a Ы e

Та блица

Таблица инфобитов о каждом интерфейсе

i p . i p F o rwa r d i n g

Целое число Равно 1 , если система является шлюзом; в противном случае 2

i p . i pAdd r T a Ы e

Таблица

i cmp . i cmp i n Re d i r e c t s

Целое число Количество полученных переадресаций ICMP

Таблица данных I Р-адресации (маски и т.д. )

i cmp . i cmp i nE c h o s

Ц елое число Количество полученных эхо-запросов

t cp . t cp i nE r r s

Целое число Количество полученных ошибок протокола ТСР

Относительно i s o . o r g . dod . i n t e rn e t . mgmt . mi b — 2 .

Глава 28. Мониторинг

1 067

В дополнение к универсально поддерживаемой базе М I В- 1 1 существуют базы М I В для различных типов аппаратных интерфейсов и протоколов, отдельн ых производителей оборудования, различных реализаций сервера snmpd и конкретных аппаратных продуктов. База M I B — это всего л и ш ь схема для управления дан н ы м и об и менах. Чтобы быть полезной, база M I B должна сопровождаться агентским кодом , которы й вы полняет ото­ бражен ие между п ространством имен SN M P и фактически м состоян ие м устройства. Агент SN M P, работающий в системах U N IX, Liпux или Windows, и меет встроен н ую поддержку баз M I B- 1 1. Бол ьш инство из н их моrут быть рас ш ирены дл я поддержки допол­ нительных M I B и для взаимодействия со сценариями, которые выполняют фактическую работу по извлечению и хранению связанных данн ых M I B. Вы увидите м ного программ­ ного обеспечения , которое осталось от ушедшей эпохи , когда протокол SNM P бьm в моде. Но все это дым без огня; в настоящее врем я вы не должны запускать SN М Р-агент в си­ стеме U N IX, за исключение м , возможно, случая , когда он должен отвечать на основные запросы о настройке сети .

Операци и п ротокола SNMP Существуют только четыре основные операции SN M P: g e t , g e t — ne x t , s e t и t rap. О перации g e t и set это основн ые операци и для чтения и записи данных на узел , определ е н н ы й идентификатором O I D. Операция g e t — n e x t выпол ня ет обход иерархии M I B и ч итает содержимое таблиц. Операция t ra p — это незапрашиваемое асинхронное уведомлен ие от сервера (агента) клиенту (менеджеру) , которое сообщает о возникнове н и и и нтересного события или си­ туаци и . Определены нескол ько стандартных уведомлений, в том ч исле уведомления «Я только что включился » , отчеты об отказе или восстановлении сетевого соединения , а так­ же анонсы о различных проблемах маршрутизации и аутентификации . М еханизм , с по­ мощью которого определяются адресаты сообщений t rap, зависит от реализации агента. Поскол ьку сообщен и я SN M P моrут изменять информацию о конфигураци и , необ­ ходим какой-то механизм защиты . В простейшей версии защиты протокола S N M P ис­ пользуется кон цепция «общей строки » (community string) , которая на самом деле пред­ ставляет собой просто ужасно запутан ное название парол я . Обычно есть одна общая строка доступа только для чте н ия и другая — для записи. 7 В наши дни и м еет с мысл уста­ новить и нфраструктуру управления S N M PvЗ , позволяющую повысить систему защиты дан ных за счет авторизации и контроля доступа для отдельных пользователей. —

N et- SNMP: средства для серверов В с истемах Linux и Free B S D наиболее распростране н н ы й пакет, реализующий прото­ кол SN M P, называется Net-SN M P. Он включает в себя агент (snmpd) , н екоторые утили­ ты командной строки, сервер для приема уведомл ен ий t rap и даже библиотеку дл я раз­ работки приложе н и й , поддерживаюших протокол SN M P. В наши дни пакет Net- SN M P в первую очередь представляет интерес из-за его команд и библиотек, а не его агента. Он был перенесен на м ножество раз н ых U N IХ- подобных систе м , поэтому действует как согласован ная платформа, поверх которой можно п исать сценарии. Поэтому в большинстве дистрибутивов агент Net-S N M P просто вынесен в от­ дел ьны й пакет, что облегчает отдел ьную инсталляцию только команд и библиотек. В систе мах Deblan и Ubuntu пакеты Net-SN M P называются snmp и snmpd. Команды инсталл ируются так: apt-get install snmp.

Часть lV. Эксплуатация

1 068

RHEL

� �

В систе мах Red H at и CentOS аналогичн ые пакеты называются net — snmp и net-snmp-tools. Команды инсталлируются так:ушu install net- snmp­ tools. В системе Linux и нформация о конфигурации хранится в каталоге / etc/ snmp; обратите внимание на файл snmpd . conf и каталог snmp . d в этом месте. Выполн ите команду systemctl start snmpd, чтобы запустить демон агента . В системе Fre e B S O все вкл ючено в оди н пакет: pkg install net — snmp. И нформация о конфигураци и хран ится в каталоге в / u s r / l oca l / etc/ snmp , которы й вам придется создать вручную. В ы можете запустить аге нт вручн ую вместе со службой snmpd или установить значение snmpd_enaЫe = » YE S » в файле /etc/rc . conf , чтобы запустить ero во время загрузки с исте м ы .

Во всех систе мах, где необходимо запустить агент SN M P, вам необходимо убедиться, что порт 1 62 протокола U O P не заблокирован брандмауэром . Команды , которые входят в пакет N e t — S N M P, м огут ознаком ить вас с п ротоко­ лом S N M P. Они также отл и ч н о п одходят для одн ократных п роверок определ е н н ы х идентификаторов O I D . Наиболее часто используем ые средства перечислены в табл. 28.4. Таблица 28.4. Средства командной строки в пакете Net·SNMP Команда

Назначение

snmpdelta

Мониторинг изменений SN МР-переменных во времени

snmpdf

Мониторинг дискового пространства на удаленном хаете через протокол SNMP

snmpqet

Возвращает значение SNМР-переменной от агента

snmpqetnext

Получает следующую переменную в последовательности

snmpset

Устанавливает SN МР-переменную на агенте

snmptaЫe

Получает таблицу переменных SNMP

snmptrans late Ищет и описывает идентификаторы OID в иерархии MIB smnptrap

Генерирует предупреждение об уведомлении t r ар

snmpwalk

Выполняет обход базы MIB, начи ная с определенного идентификатора OID

Для базовых проверок SN M P обычн о используется некоторая комбинация команд snmpget и snmpdelta. Другие программ ы полезны , когда вы хотите найти новые иден­ тификаторы 010 для мониторинга с помощью вашего средства управления , принятого в вашей организации. Например , команда snmpwalk запускается с указанного иденти­ фикатором 0 1 0 м еста (или по умолчан и ю с начала базы M IB ) и повторно выполняет команды g e t — n e x t , посылая вызовы агенту. Эта процедура выдает пол н ы й с писок до­ ступных идентификаторов 0 1 0 и связанных с н и м и значений. Например, вот усеченный пример результатов применения команды snmpwalk к хо­ сту tuva систе м ы Linux. Общая строка » secret81 З communi ty» , а флаг -vl означает простую аутентификацию. —

$ snmpwalk — с secret8 1 3community -vl tuva S NMPv2 — MI B : : s y s D e s c r . 0 = S T R I N G : Linux tuva . a t ru s t . c om 2 . 6 . 9 — 1 1 . EL smp # 1 SNMPv2 -MI B : : s y s Up T ime . O = T i me t i c k s : ( 1 4 4 2 ) 0 : 0 0 : 1 4 . 4 2 SNMPv2 -MI B : : s y s N ame . O = S T RI N G : t uva . a t ru s t . c om

Глава 28. Мониторинг

I F-M I B : I F- MI B : I F-MI B : I F-MI B : I F- M I B : I F-MI B : I F- MI B : I F-MI B : I F- MI B : I F- M I B : I F- M I B : I F- MI B : I F-MI B : I F- M I B : I F-MI B :

1 06 9

S T R I NG : l o : i fDe s c r . l S T R I NG : e t h O : i fDe s c r . 2 S T R I NG : e t h l : i fDescr . 3 I N T EGER : s o f tw a r e L oopba c k ( 2 4 ) : i fType . l : i fT yp e . 2 = I N T EGER : e t h e rne tC sma c d ( 6 ) : i fT yp e . 3 I NTEGER : e t h e r n e t C sma c d ( 6 ) STRING : : i f P h y sAddre s s . l : i f P h ysAddr e s s . 2 = S T R I NG : 0 : 1 1 : 4 3 : d 9 : l e : f 5 : i f P h y sAddr e s s . 3 S T R I NG : 0 : 1 1 : 4 3 : d 9 : l e : f 6 : i f l nOc t e t s . l Counte r 3 2 : 2 6 0 5 6 1 3 5 1 4 : i f l nO c t e t s . 2 Coun t e r 3 2 : 1 5 4 3 1 0 5 6 5 4 : i f l nO c t e t s . 3 = Count e r 3 2 : 4 6 3 1 2 3 4 5 Counte r 3 2 : 3 8 9 5 3 6 1 5 6 : i f l nU c a s t P k t s . l C ount e r 3 2 : 8 9 2 9 5 9 2 6 5 : i f i nU c a s t P kt s . 2 Counte r32 : 7 7 1 2 3 2 5 : i f l nU c a s t P kt s . 3 =

=

=

В этом примере общая информация о систем е сопровождается статистикой сетевых интерфейсов хоста: loO , ethO и ethl. В зависимости от баз M I B, поддерживаемых аге н ­ том , которы м вы управляете , пол н ы й дам п может содержать д о сотен строк. Фактически пол ная инсталляция в с истеме U buntu, настрое нной для обслуживан ия каждой базы М 1 В, выводит более 1 2 ООО строк! Есл и вы п росмотрите базы M I B8 для последн е й верс и и Net — SN M P в систе м е Ubunt u , т о увидите , что средн ий з а пять м и н ут показател ь загрузки с исте м ы равен 1 . 3 .6. 1 . 4. 1 . 2 02 1 . 1 0. 1 . 3 . 2 . Есл и вам интересно увидеть пяти м и н утную загрузку систе м ы для локал ьного хоста, для которого задана общая строка » puЬlic » , вы должн ы вы пол­ н ить команду: $ snmpqet -v 2с -с puЬlic localhost . 1 . З . б . 1 . 4 . 1 . 2 0 2 1 . 1 0 . 1 . 3 . 2 i s o . 3 . 6 . 1 . 4 . 1 . 2 0 2 1 . 1 0 . 1 . 3 . 2 = S T R I NG : » 0 . 0 8 «

М ногие полезные модули SN M P, связанные с языкам и Perl , Ruby и Python, доступны из соответствующих репозиториев модулей эти х языков. Хотя вы можете в своих сцена­ риях непосредстве нно указы вать команды пакета Net-SN M P, проще и легче испол ьзо­ вать встрое нные модул и , которые уже написаны для ваше го языка програм мирования.

28. 1 о. Советы и РЕКОМЕНДАЦИИ по МОНИТОРИНГУ На протяжении м ногих лет мы выработали нескол ько советов о том , как макс и м изи­ ровать эффективность мон иторинга. Н иже изложены основн ые идеи . •

Избегайте в ы горания систе м н ы х адм и н истраторов , проводя щих мон итор и н г. Убедитес ь, что системные админ истраторы , получающие уведомления во внеуроч­ ное вре м я , регулярно отдыхают. Эта цель лучше всего дости гается с помощью си­ стемы ротации , в которой в течение одного дня ил и недели звон ки адресуются ко­ манде из двух или более челове к, а затем наступает очередь следующей команды . Н еспособность прислушаться к этим советам при водит к поя влению ворчл и вых системных админ истраторов, которые ненавидят свою работу.

Определ ите , какие обстоятельства действительно требуют внимания 24 часа в сут­ ки 7 дней в недел ю, и убедитесь, что эта информация четко передается ваше й группе мон итори н га, дежурн ы м командам, а также кл иентам ил и бизнес- подраз-

«Зайдите на сайт mibdepo t .

с от

или установите пакет snmp-mibs-downloader.

Часть lV. Экс пл у атация

1 070

дел е н и я м , работу которых вы поддержи ваете . Сам факт, что вы контрол ируете что-то, не означает, что адм и н истраторы должны собираться в 3 : 30 утра, если не­ которое значение в ыходит за рамки допусти мого. Многие проблемы следует ре­ шать в обычное рабочее время. •

Устраняйте шум монитори н га. Если генерируются ложн ые срабатывания или уве­ домления для некритических служб, установите время, чтобы остановить и испра­ вить их. В противном случае, как в истори и о мал ьчике, которы й постоян н о кричал о волках, все уведомления в конечном итоге не получат необходимоrо внимания. Создавайте рабочи е журнал ы регистраци и для всего. Л юбая обычная процедура перезапуска, сброса или исправления должна быть задокументирована в фор м е , которая позволяет с исте мному адми н истратору, который н е знаком с данной с и ­ стемой, предпри н ять соответствующие действи я . Если такой документации нет, пробл е м ы станут хрон ически м и , повысится вероятность ош и бок и для борьбы с чрезвычай н ы м и с итуаци ям и п р идется н аправл ять дополнител ьны й персонал . Для поддержки такого типа докуме нтации отлично подходит с истема Wiki. Контролируйте платформу мониторинга. Это станет очевидн ы м после того, как в ы пропустите критический сбой из-за в ыхода из строя платформ ы мониторинга. Учитесь на наших ошибках и убедитесь, что за вами тоже кто-то наблюдает. Пропустили сбой ком понента из-за того, что он не контрол ировался? Добавьте е го в систему монитори н га и в следующий раз вы вовремя распознаете проблему. Наконец, и , возможно, самое главное : н и сервер, н и служба не должны включать­ ся в производствен ную цепочку без предварительного добавления в систему мони­ тори н га. Исключен и й здесь быть не может!

28. 1 1 . ЛИТЕРАТУРА •

Н Еснт, JлмЕs. Rethinking Monitoring/or Container Operations. Отличная и нформация о стратегии и философии монитори н га контейнеров. С этой книгой можно озна­ комиться по адресу

h t tp : / / thenews t a c k . i o /mon i t o r i ng — re s e t — co nt a i ne r s / •

TuRNBULL,

DIXo N JлsoN . Monitoring with Graphite: Tracking Dynamic Нost and App/ication Metrics at Sca/e. Sebastopol , СА: O ‘ Reilly Media, 20 1 7 . ,

JлмЕs. The Art о/ Monitoring. Seattle , WA: Amazoп D igital Services, 20 1 6.

глава

29

Анализ производитель ности

Анализ производительности и ее настрой ку часто отн ос я т к м а ги ч ес кой стороне си­ стем ного администрирования. Конечно же, магии зде сь н и какой нет, а сл едует говорить о с и мбиозе науки и искусства. » Научная » часть вкл ючает т щател ьн ое п роведе н ие ко­ л ичестве н н ых измерений и применение научного подхода С оставля ю щая » искусства» связана с необходимостью сохранять баланс ресурсов на ра з ум ном уровне , поскольку оптим изация для одного приложен ия или пользователя может от р и ц атель н о повл иять на другие приложения или на других пол ьзователей. Как это часто бы вает в жи з н и , не­ возможно сделать счастливыми всех сразу. В блогосфере бытует м нение, что сегодня пробле м ы прои з водител ьност и кардиналь­ но отличаются от аналогичных проблем предьщущих дес ятил е тий Н о это не совсем так. Да, систе м ы стали гораздо сложнее, но определяющие фактор ы прои з водител ьности и высокоуровневые абстракции , используемые для ее и з мерен и я и управления , не ме­ няются . К сожалению, повышение производител ьности с истем с ил ьно коррел ирует со способностью соответствующего сообщества создавать новые приложения которые по­ глощают все доступные ресурсы . В последние годы допол нительную сложность со зд ае т м но гоуровневая абстракция, которая часто располагается между серверам и и физи ч ес кой ин фраструктурой облака. Ч асто невозможно точно знать, какое оборудование обеспечивает хранение или выпол­ нение циклов центрального процессора на ваш е м сервере . М агия и проблема облачных технологий — это два аспекта одн о го и того же вида. Н есмотря на распространенное мнение, вы не може т е и гнорировать вопросы прои з во.

.

,

1 07 2

Часть lV. Эксплvатация

дительности только потому, что ваш и серверы я вляются виртуал ьн ы м и . Фактически мо­ дели б илли н rа , испол ьзуе м ые провайдерами облаков, создают еще более прямую с вязь между производительностью и затратам и н а сервер. Знать, как измерять и оце н и вать производительность, стало более важны м , чем когда-либо. В этой главе основное внимание уделяется производительности с исте м , которые ис­ пользуются в качестве серверов. Н астольные систем ы ( и н оутбуки) обычно н е испыты­ вают тех же проблем с производительностью, что и серверы. Ответ н а вопрос о том , как повысить производительность на настольном ком п ьютере , почти всегда сводится к со­ вету обновить аппаратное обеспечение. П ользователя м н равится этот ответ, потому что благодаря ему они чаще п ол учают новые интересн ые системы.

29. 1 . П РИНЦИ П Ы НАСТРОЙКИ ПРОИЗВОДИТЕЛЬНОСТИ Одни м из аспектов , отл ичающих U N IX и Linux от других популярных операцион ных систе м , я вляется объем дан ных, которы е они предоставл я ют о с воих внутрен н их опера­ циях. Детальная и нформация доступна буквально по каждому уровню с исте м ы , благода­ ря чему адми нистраторы моrут настраивать различные параметры именно так, как нуж­ но. Если установить источн и к проблем с производительностью н и как не удается , всегда можно просм отреть исход н ы й код. П о эти м причинам U N IX и Linux часто считаются наиболее подходящими операционн ы м и с истемами для пользователе й , которых особен­ но беспокоит тема производительности . Даже при этих условиях настрой ка производительности не я вляется простой задачей. Как пользователи , так и адм и нистраторы часто думают, что если бы они владел и н уж­ н ы м и » магическ им и » приемами , их систе м ы работали бы в два раза быстрее. Однако так бывает оче н ь редко. Одн и м и з наиболее распростране н н ых заблужден и й я вляется убежден и е в том , что для настройки производительности н ужно и з м е нить знач е н и е пере м е н н ых ядра, ко­ торы е отвечают за управл ен и е с истемой стран и ч ного обмена и буфе р ны м и пула м и . В наш и д н и ядра основн ы х дистри бути вов изначал ьн о н астрое н ы на достиже н ие раз­ у м н о й ( хотя и не оптимал ьн о й ) производи тел ьности при разл и ч н ых уровнях загру­ же н н ости. Если п о пытатьс я оптим изировать систем у по какому-то кон кретному по­ казателю про изводительности ( например, по степ ени испол ьзован ия буферов ) , весьма вероятно , что поведен и е систем ы ухудшится в отноше н и и других показателе й и режи­ мов работы. Наиболее сложные вопросы производительности часто с вя зан ы с приложе н и я м и , а н е операционн ы м и с истемами . В этой главе будет рассказываться о том , как можно настроить производительность на уровне систе м ы ; возможность рассказать о настройке производительности на уровне пр иложен и й мы оставили другим . Как системному адми­ н истратору, вам н еобходимо помнить о том , что разработчики — тоже люди. ( Сколько раз вы говорили или думали , что проблема кроется в сети?) Так и разработчики прило­ жен и й тоже часто предполагают, что все проблемы воз н икают в подсистемах, за которые отвечает кто-то другой. При таком уровне сложности современных приложе н и й некоторые проблемы можно реш ить только посредством сотрудничества их разработчи ков, с исте м н ых адми н истра­ торов, проектировщиков серверов, адми н истраторов баз дан н ых, адм и н истраторов си­ стем хранения данн ы х и архитекторов сети. В этой главе мы поможем вам определить, какие дан н ы е следует предъявить эти м специалиста м , чтобы они с могл и решить про­ бле м ы производительности (если в действительности эти проблемы лежат в их области).

Глава 29. Анализ производительности

1 07 3

Такой подход гораздо эффективнее, чем просто сказать: » Все выглядит прекрасно, это не моя проблема» . В л юбом случае н и когда не доверя йте пол ностью том у, что пи шут в И нтернете . Какие тол ько аргументы не приводятся в дискуссиях о производител ьности систем! При этом сторонники всевозможных теорий не обладают, как правило, ни знан ия м и , н и дис­ ц и пл иной, ни времене м , необходим ы м и для проведе н ия достовер н ых экспериментов. Ш и рокая поддержка пользователе й еще н ичего не значит, ибо каждое глупое предложе­ ние очень часто сопровождается хором восторженных комментариев: «Я увел ичил раз­ мер кеш-буфера в десять раз, как он предложил , и систем а заработала гораздо, гораздо быстрее! » Да уж, конечно! Н иже перечислены ряд правил , которы м и следует пользоваться. •

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

В главе 2 8 рассказывалось о некоторых средствах анализа тенденций, которые так­ же подходят для мон иторинга производительности .

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

Н е перегружайте умышленно свои систем ы и л и свою сеть. Ядро создает для каж­ дого процесса илл юзию бесконеч ности ресурсов. Но как тол ько в дело вступают все 1 00% ресурсов систе м ы , операцион ной системе приходится работать оче н ь напряженно. Н а поддержку илл юзи и расходуется ощутимая доля самих ресурсов. В результате выполнение процессов замедляется .

Как в физике элементарных части ц, чем больше дан ных вы собираете с помощью утил ит мон итор и н га с исте м ы , те м бол ьшее влияние вы оказываете на исследу­ емую с исте му. Для набл юде ния за системой луч ш е всего полагаться на простые инструменты , которые работают в фоновом режиме ( например, sar или vmstat) . Есл и они обнаружат что-то существен ное , то для более глубокого анализа можете воспол ьзоваться и другими инструмента м и .

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

Всегда продумы вайте план отката на случай , есл и ваш и изме нения на самом дел е ухудшат работу с истемы.

29.2. СПОСОБЫ ПОВЫШЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ Н иже перечисл е н ы кон кретные действия, которые можно выпол н ить, чтобы улуч ­ ш ить производительность. •

Убедитесь в том , что память доступ на в достаточном объеме. В следующем раз­ деле вы увидите , что объем памяти оче н ь сил ьно вл ияет на производител ьность. Устройства памяти сегодня стоят довол ьно н едорого , так что обычно оснастить по максимуму любой ком п ьютер, от которого требуется высокая производител ь-

1 074

Часть lV. Эксплуатация

ность, — не проблема. Если ваш сервер работает в облаке, то измен ить объем па­ мяти , в ыдел е н н ы й его экзе м пляру, обыч но оче н ь легко (хотя часто он связан с други м и выделяе м ы м и ресурсами в полном профиле систе м ы ) . •

Там , где это возможно, л иквидируйте зависимость систем хранения данн ы х о т ме­ хан ических устройств. В настоящее время широко доступн ы твердотельные диски (soid state dis k d rive — S S D ) , которые могут обеспечить быстрый рост производи ­ тел ьности, поскольку для них не требуется физическое вращение дискоа для счи ­ тывания б итов и н формац и и . SS D-диск и легко устанавл и ваются в место «старых добрых» дисковых накопителей.

Если U N I X- или Linux-cиcтeмa используется в качестве веб-сервера или сетевого сервера приложений, можно попробовать распределить трафик между н ескольки­ м и ком пьютерам и с помощью какого-н ибудь (физического или виртуал ьного) ба­ лансировщика н агрузки . Эти устройства распределяют нагрузку согласно одному из нескол ьких выбираемых пользователем алгоритмов типа » м и н имал ьное время откли ка» ил и » цикл ический ал горитм обслуживания». Кроме того, балансировщики нагрузки добавляют полезную избыточность на слу­ чай перегрузки сервера. О н и просто необходим ы , если ваш сервер вынужде н об­ рабатывать неожидан ные всплески трафика.

Тщательно проверяйте конфигурацию систе м ы и отдельн ых приложений. М ногие приложе н ия могут резко увел ич ить производител ьность, есл и их правильно на­ строить (распределить данн ые между дисками, не осуществлять динамический по­ иск имен в D N S , запустить допол н ительные экземпляры сервера и т.д. ) .

Устраните проблемы, связан ные с использованием ресурсов. П роблемы могут соз­ даваться как » реальн ы м и заданиями » (одновременный запуск сл и ш ком большого количества серверов, неэффективные методы программирован ия, выполнение па­ кетов задан и й с завыш е н н ы м приоритето м , запуск ресурсоем к их програм м в не­ подходящее время) , так и самой системой ( ненужные демоны ) .

Органи зуйте жесткие диски и файловые системы так, чтобы нагрузка на них была равномерной , и тем сам ы м макси мально повысьте пропускную способность ка­ налов ввода-вы вода. При нал и ч и и специфических приложе н и й , таких как базы данных, можно попробовать использовать какую- н ибудь модную м ногодисковую технологию вроде RA I D для оптимизации процессов обмена дан н ы м и . За реко­ м е ндациями следует обращаться к разработчику базы дан н ых . Для систем Linux нужно удостовериться в том , что для диска выбран самый подходящий из доступ­ ных в Linнx планировщик ввода-вывода (детали см. в разделе 29.6). Обратите внимание на то, что разные приложен ия и систе м ы управления базами дан н ых ведут себя по-разному при размещении на нескольких дисках. Технология RA I D существует в нескольких вариантах, поэтому следует потратить время и вы­ ясн ить, какой из них луч ш е всего подходит для дан ного конкретного случая (есл и вообще подходит) .

Проведите мониторинг сети и убедитесь в том , что она не перегружена трафиком и что количество ошибок в ней минимально. Очень м ного такой полезной и нфор­ мации о сети можно собрать с помощью команды net8 tat ( Free BS D) и 88 ( Linux).

Определите ситуац и и , в которых с истема соверш е нно не соответствует предъяв­ ляемым к ней требованиям . Н ел ьзя настроить производительность без учета таких с итуаций.

Глава 29. Анализ производительности

1 07 5

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

29.3 . ФАКТОРЫ, ВЛИЯЮЩИЕ НА ПРОИЗВОДИТЕЛЬНОСТЬ П роизводительность системы во многом определяется базовы м и характеристи ка м и с истемных ресурсов и эффективностью и х распределения и совместного испол ьзования. О пределение термина ресурс весьма рас пл ывчато. Оно может подразуме вать даже такие компоненты , как кеш содержимого регистров центрального п роцессора и эле менты таб­ л и ц ы адресов контроллера памяти. Однако в п ервом п риближе н и и серьезное влияние на производительность оказывают только четыре фактора: •

время испол ьзова н и я централ ьного процессора и е го захваче н н ые ц и кл ы ( с м . н иже) ; память;

пропускная с пособность дисковой подсистем ы ввода- вывода;

пропускная способность сетевой подсисте м ы ввода-вывода.

Если после запус ка активных процессов остал ись с вободн ые ресурсы , можно с ч и ­ тать, что производител ьность системы я вляется удовлетворител ьной. Когда ресурсов не хватает, п роцессы становятся в очередь. П роцесс, не имеющий не­ медленного доступа к н еобходим ы м ресурсам , должен ждать, ничего при этом н е делая. Вре м я , затрачи ваемое на ожидание ресурсов, — оди н из основных показателей ухудше­ ния п роизводительности. Самы й простой с точки зре н ия учета ресурс — испол ьзование центрального процес­ сора. В распоряже н и и системы всегда и меется примерно одна и та же часть его мощно­ сти . Теоретически эта вел ич и на составляет все 1 00% циклов центрального процессора , но » накладные расходы » и другие причины приводят к сниже н и ю этого показателя при­ мерно до 95%. Для процесса, зан имающего более 90% времени це нтрального процессо­ ра, ограничивающим фактором я вляется его быстродействие. Такой процесс потребляет большую часть вычислительных мощностей систе м ы . М ногие считают, что быстродействие центрального п роцессора — основной фактор, вл ияющий на общую п роизводительность систе м ы . П ри наличии неограниче н н ых объ­ емов всех остальных ресурсов или для определенных типов приложен и й (например, про­ грамм численного моделирования) быстродействие централ ьного процессора (ил и кол и ­ чество ядер) действительно играет роль. Н о в повседневной жизн и этот показатель значит относител ьно мало. Н астоя щ и м узк и м местом я вл яется кан ал обм е н а дан н ы м и с жестки м диском . Жесткие диски представл я ют собой механ ические с исте м ы , поэтому на поиск нужного блока, выборку е го содержи мого и акти визацию ожидающего его п роцесса уходят де­ сятки м иллисекунд. Задержки такого порядка отодвигают на второй план все остальные факторы ухудшения п роизводительности. Каждое обращение к диску вызывает приоста­ новку активного процесса «стоимостью» нес кол ько м иллионов и н струкций централ ь-

часть lV. Эксплvатация

1 076

ного процессора. Эту проблему можно реш ить, например, с помощью твердотельных дисковых накопителей. Благодаря испол ьзованию виртуал ьной памяти с корость дискового обмена может быть непосредственно связана с объемом имеющейся памяти, есл и потребность в физи­ ческой памяти превышает ее реальный объем . Ситуаци и , в которых физической памяти становится недостаточно, часто приводят к необходимости записы вать содержимое ее страниц на диск, чтобы эти страницы можно было освободить и испол ьзовать для дру­ гой цел и . Это означает, что обращение к памяти по с воей с корости п рибл ижается к ра­ боте с диско м . Избегайте таких ловуш е к , есл и характер исти к и производител ьности имеют дл я вас большое значение; побеспокойтесь о том , чтобы каждая система и мела достаточно физической памяти. Пропускная способ ность сети подвержен а п р и мерно тем же о гран и ч е н и я м , что и скорость дискового обмена. Ее ухудшение связано со всевозможными задержками . Но возникающие проблем ы охватывают целые сообщества пол ьзователей , а не отдельные комп ьютеры. Кром е того, сети восприимчивы к проблемам аппаратного обеспечения и перегрузкам серверов.

29.4. ЗАХВАЧЕННЫЕ ЦИКЛЫ ЦЕНТРАЛЬНОГО ПРОЦЕССОРА Облач н ы е технологии ( и , как правило, виртуал изаци я ) обещают, что ваш сервер всегда будет иметь необходи мые ему ресурсы . На самом деле большая часть этой щедро­ сти — иллюзия. Даже в крупномасштабной в иртуальной среде борьба за ресурсы может оказать заметное влиян ие на производител ьность виртуального сервера. Центральный процессор — это наиболее часто используе м ы й ресурс. Существует два способа, с помощью которых можно захватить циклы процессора на вашей виртуальной маш и не. •

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

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

Хотя захват процессора может произойти в л юбой операцион ной системе, работаю­ щей на в иртуализованной платформ е , система Linux позволяет выявить этот факт с по­ мощью показателя s t (stolen захвачен) в командах top, vmstat и mps tat. Вот пример использован ия команды top: —

t op 1 8 : 3 6 : 4 2 up 3 d a y s , 1 8 : 0 3 , 1 u s e r , l o ad ave r a g e : 3 . 4 0 , 2 . 2 5 , 2 . 0 8 T a s k s : 2 1 8 t o t a l , 4 runn i n g , 2 1 7 s l e ep i n g , О s t opp e d , О z o mЬ i e % Cpu : 4 1 . 6 u s , 4 2 . 2 s y , О . О ni , О . О i d , О . О wa , О . О h i , О . О s i , 1 6 . 2 s t —

Глава 29. Анализ производительности

1 077

В этом при мере в 1 6, 2 % случаев система готова , но не м ожет работать, потому что процессор отвл е кается от в иртуал ьной маш и н ы ги первизором . Вре м я , потрач е н н ое на ожида н и е , н е п осредствен но пере водится в с н иже н и е пропус кной способност и . В н и м ател ьно следите з а этим показател ем на виртуал ьных серверах, чтобы гарантиро­ вать, что ваш и рабоч ие нагрузки не будут непреднамеренно испытывать дефицит про­ цессора.

2 9 . 5 . КАК АНАЛИЗИРОВАТЬ ПРОБЛЕМЫ ПРОИЗВОДИТЕЛЬНОСТИ В сложн о й с исте м е неле гко выдел ить и м е н но п робл е м ы производител ьн ости . Систе м н ые адм и н истраторы часто получают невразумител ьные отчеты о проблемах, ко­ торые содержат эмоциональные оп исан ия кон кретн ых случае в или сложных ситуаций ( например, » веб-сервер застопорился из-за всех этих проклятых АJАХ-вызовов» . » ) . Вы, конечно, должны обратить внимание на эту информацию, но не вос при н имайте ее как достоверную и надежную; п роводите собствен ное исследование. Строгая и п розрачная научная методика поможет вам сделать п равил ьные выводы , которым ваш и сотрудн ики и вы сами можете доверять. Науч н ы й подход позвол ит дру­ гим оцен ить ваши резул ьтаты, повысит доверие к вашей работе и увел ичит вероятность того, что предлагае мые вами изменения смогут реально реш ить проблему. Применение науч ного подхода не означает, что вы должн ы собирать все релевантные дан н ые сам и . Весьма полезной бывает и » внешняя » информация. Не стоит тратить часы на изучен ие вопросов, ответы на которые можно ле гко почерпнуть из разделов FAQ ( Fгequently Asked Questions — часто задаваемые вопросы). М ы предлагаем вам выпол н ить следующие пять действий. 1 . Сформулируйте вопрос. П оставьте кон кретн ый вопрос в определен ной фун кцио­ нал ьной области л ибо сформул ируйте предварител ьное закл юче н ие или рекомен­ дацию, которую вы обдумал и . Будьте точ н ы , говоря о технологиях, ком поне нтах и альтернативах, которые вы предлагаете рассмотреть, и резул ьтатах, которые мо­ гут быть достигнуты . 2. Соберите и классифицируйте факты. П роведите систематичес кий поиск в доку­ ментац и и , базах знан и й , известных вам изданиях, блогах, техн ических описан и ­ я х , н а форумах и прочих информационн ых ресурсах с цел ью выявления вне ш н их фактов, имеющих отношение к вашему вопросу. В собствен н ых системах зафик­ сируйте телеметрические дан н ые и (по возможности ил и необходи мости) ос на­ стите и нструментал ьн ы м и средствам и кон кретные и нтересующие вас области в с исте ме ил и отдел ьных приложен иях. 3 . Критически оцените данные. П росмотрите кажды й источ н и к дан н ых на предмет релевантности и критически оце ните его с точ ки зре н ия достоверности . Выдел ите кл ючевые дан ные и обратите вн и мание на качество источ н и ков и нформации. 4. Подытожьте данные вербально и графически. Представьте сведе н и я , взятые из не­ с кол ьких источ н и ков, в словесной ( вербальной ) и по возможности графической форме. Дан н ы е , кажущиеся сом н ительн ы м и при выраже н и и в ч исловой форме, могут оказаться убедител ьн ыми в виде диаграммы. 5. Сформулируйте заключение. Представьте свои выводы в лаконич ной форме (как от­ вет на поставленный вами же вопрос). П оставьте оценку, чтобы обозначить уровень с ил ы или слабости доказательств, которые поддерживают ваш и заключения.

Часть lV. Эксплvатация

1 078

29.6. П РОВЕРКА ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ Хватит общих советов — пора рассмотреть н екоторые кон кретные и нструме нты и » зоны и нтереса». П режде чем переходить к измере н ия м , необходимо знать, что имен­ но вы хотите получить.

И н вента ризуйте свое оборудова ние Начните с оценки своего оборудования, особенно централ ьного процессора и ресур­ сов памяти. И нвентаризация поможет вам и нтерпретировать дан н ы е , представленные с помощью других инструме нтов, а также построить реалистичные ожидания касательно верхних границ производительности. В системах Linux и м е н н о в файловой системе /proc стоит искать ответ на воп рос, какое с точки зрения вашей операционной с истемы вы использу­ ете оборудовани е (более детальную информацию об аппаратуре можно най­ ти в каталоге / sy s ; см. раздел 1 1 . 3 ) . Н е которые ключевые файл ы переч ис­ лены в табл. 29. 1 . Общую информацию о файловой с истеме /proc можно найти в разделе 4.6. Таблица 29 . 1 . Источники информации об оборудовании в системах Linux Файл

Содержимое

/proc/cpuinfo

Тип и описание центрального процессора

/proc/meminfo

Размер памяти и коэффициент загрузки

/proc/disks tats

Дисковые устройства и статистика их использования

Четыре строки в файле /proc/cpuinfo помогут вам идентифицировать централь­ ный процессор в с истеме: vendo r id, cpu fami l y , mode l и mode l n ame . Н екоторые из этих значен и й непонятны , поэтому луч ш е всего узнать о н их в и нтерактивной с правоч­ ной с истеме. Точ ная и н формаци я , содержащаяся в файле /pro c / cpuinfo, зависит от с истемы и процессора. Рассмотри м типичный пример содержимого этого файла. $ cat /proc/ cpuinfo О p r o ee s s o r vendor i d G e n и i n e l nt e l ери f ami l y 6 15 mod e l I n t e l ( R ) X e on ( R ) C P UE 5 3 1 0 mod e l n ame s tepping 11 ери MHz 1 60 0 . 0 0 3 4 0 9 6 кв eaehe s i z e phy s i ea l i d о ер и e o r e s 2 siЬlings 2

@ l . 6 0 GH z

Этот файл содержит по одной записи для каждого процессорного ядра, видимого опе­ рационной с истемой. Кон кретные дан н ые незначительно вар ьируются в зависимости от верси и ядра. Значение поля p r o c e s s o r уни кально идентифицирует ядро. Значения поля p h y s i c a l id я вляются ун и кал ьн ы м и для каждого физического сокета на печат-

Глава 29. Анализ производительности

1 079

ной плате , а значения core i d (не показано в приведе нном выше примере) уни кал ьны м я ядра в физическом сокете. Ядра, которые поддерживают гиперпотоковый режи м ра­ боты (дубл ирование контекстов ЦП без дублирован ия других характеристик обработки), идентифицируются значением h t в поле f l a g s (также не показано в приведен ном вы ш е примере). Если в системе действител ьно реализован гиперпотоковый режим работы, поле s i Ы i n g s мя каждого ядра показывает, сколько контекстов доступно на данном ядре. Существует еще одна команда, которая позволяет получить и нформацию об аппарат­ ных характеристиках вашего ком пьютера. Речь идет о команде dmidecode. Она выводит содержимое системной таблицы D M I ( Desktop Management I nterface — интерфейс управ­ ления настол ьн ы м и системам и) , также известной под именем S M B IOS. Самой полезной опцией этой команды является t тип (допустимые типы представлены в табл . 29. 2). —

Таблица 29 . 2 . Значения типов для команды dmidecode -t Значение

Описание

1

Система

2

Материнская плата

3

Корпус

4

Процессор

7

Кеш -память

8

Разъемы портов

9

Системные разъемы

11

ОЕМ-строки

12

Опции системной конфигурации

13

Язык BIOS

16

Массив физической памяти

17

Устройство памяти

19

Отображаемый адрес массива памяти

32

Загрузка системы

38

I РМ l -устройство

В следующем примере демонстрируется получение типичной и н формаци и. $ sudo dmidecode — t 4 # drni d e c ode 2 . 1 1 SMB I OS 2 . 2 p r e s e n t . H a n d l e О х 0 0 0 4 , DMI t ype 4 , 3 2 b y t e s . P r o c e s s o r I n f o rma t i on S o c k e t De s i gna t i on : PGA 3 7 0 Туре : C e n t r a l P r o c e s s o r Fami l y : C e l e ron Manu f a c t u r e r : G e n u i n e i n t e l I D : 65 0 6 00 0 0 FF F9 8 3 0 1 S i g n a t u r e : Т ур е О , F ami l y 6 , Mode l 6 , S t ep p i n g 5

Биты информации о сетевой конфи гурации разбросан ы » по всей системе » . Л уч ш и м источ н и ком информации о I P- и МАС-адресам м я каждого сконфигурирован ного и н ­ терфейса служат ком анды i f c o n f i g — а ( Free BS D) и i p а ( Linux).

Часть lV. Эксплуатация

1 080

Сбор да н н ых о п роизводител ьности П рограм м ы анал иза производительности в большинстве своем сообщают о том , что происходит в с истеме в данный момент времен и . Но следует учесть, что структура и ха­ рактер загрузки систе м ы меняются в течение дня. Поэтому до принятия мер обязатель­ но проведите всесторонний анализ данн ых , касающихся производител ьности. Истинная производ ительность выясняется тол ько после длительного (месяц или даже бол ьш е) н аблюдения за системой. Особенно важно собирать дан ные в периоды п и ковой загру­ женности систе м ы . Ограничения на использовани е ресурсов и ошибки в конфигура­ ции системы часто выявляются только в таких условиях. Допол нительную информацию о сборе и анал изе данных см. в главе 2 8 .

А на л из испо л ьзова ния централ ьного процессора Обычно собирают три в ида дан ных о центральном процессоре : общий показател ь использован и я , показатели средней загруженности и потребление ресурсов отдельны­ м и процессами . Первая характеристика определяет, я вляется л и быстродействие самого процессора узким место м . Показател и средней загруженности дают возможность оце­ н ить общую производительность систе м ы . Дан ные, касающиеся отдельных процессов, позволяют выявить наиболее ресурсоем кие процессы . Сводную и н формацию выдает команда vm s tat. Ей передается два аргумента: вре­ мя ( в секундах), в течение которого н еобходимо наблюдать за с истемой для получения каждой строки выходной информ ац и и , и необходимое количество отчетов. Если не ука­ зать ч исло отчетов, команда будет выполняться до тех пор, пока пользователь не нажмет комбинацию клави ш < Ctrl + C > . Рассмотри м пример. $ vmstat 5 5 p r o c s — — — — — — — — — — -memo r y — — — — — — — — r ь s wp d f ree bu f f c a c h e 1 о 820 2 606356 428776 487 092 1 о 820 2570324 428812 510196 1 о 820 2539028 428852 535636 1 о 820 2472340 428920 581588 3 о 820 2 4 4 0 2 7 6 4 2 8 9 60 605728

— s wap si so

о о о о о

о о о о о

—i o- Ьi Ьо 4 7 4 1 65 4 61 3 1 1 5099 13 4536 10 4818 21

— s y s t em- in cs 1 0 63 4 8 5 7 1054 4732 1057 52 1 9 1056 4686 1060 4943

— — — — c pu — — — u s s y i d wa 25 1 73 о 25 1 74 о 90 1 9 о 87 3 10 о 20 3 77 о

Несмотря на то что содержимое этих столбцов может не совпадать в разных с исте­ мах, статистические данные показателей испол ьзования центрального процессора прак­ тически н е разл и чаются среди платформ . П ол ьзовательское время , с исте м ное время (время ядра) , врем я простоя и время ожидан ия для каналов ввода-вывода ( 1/0) показа­ ны в столбцах u s , s y , i d и wa соответственно. Большие ч исла в столбце us обычно оз­ начают активные вычислен и я , а в столбце sy он и свидетел ьствуют о том , что процессы осуществляют очен ь м ного систем ных вызовов или выполняют операции ввода-вывода. Выработан ное нами за м ногие rоды эмпирическое правило для серверов общего на­ знач е н и я , справедли вое для бол ьш и н ства систе м , гласит следующее : систем а должна тратить п р имерно 50% рабочего вре м е н и на обслуживание пол ьзовател ьских запросов и стол ько же на с исте м н ые запрос ы . Общее время простоя не должно быть нулевы м . Если сервер выделяется под одно-единствен ное приложение, интенсивно испол ьзую­ щее центральный процессор, то большая часть времени должна тратиться на обработку пользовательских запросов. В столбце cs показано число переключений контекста за данн ы й период, т. е . с коль­ ко раз ядро переключало процессы . В столбце i n отображается ч исло прерыван и й , ге-

Глава 29. Анализ производительности

1 081

нерируе м ых аппарат н ы м и устройства м и ил и ком понентам и ядра. Сли ш ком бол ьш и е значе н и я в э т и х столбцах свидетел ьствуют о н е правил ьно работающем аппаратном устройстве. Остал ьн ые столбцы важн ы дл я анал иза испол ьзова н и я памяти и жесткого диска, о чем будет рассказываться н иже в этой главе. Дол говре м е н н ые измере н и я средних показателе й , характеризующих работу цент­ рал ьного процессора, позвол я ют определить, достаточн о л и е го ресурсов дл я нормаль­ ной работы систе м ы . Если процессор регулярно часть времени простаивает, значит, есть запас по тактовой частоте . В этом случае увел ич е н ие быстродействия процессора нена­ много улуч ш ит общую производительность системы , хотя может и ускорить выполнен ие отдел ьных операций. Как видно из показанного примера, централ ьны й процессор постоя нно перекл юча­ ется из режима и нтенсивного испол ьзования в режим полного бездействия и обратно. П оэтому необходимо набл юдать за показателя м и , соответствующим и обоим режимам , и вы водить среднее за определ е н н ы й период времени. Ч е м м е н ьш е и нтер вал набл юде­ н и я , тем н иже достоверность оценок. В мул ьтипроцессорных системах команды вроде vm.stat сообщают средние значе­ ния по все м процессорам. В системе Linux существует команда mpstat, которая выдает отчет по каждом у процессору. С помощью флага — Р можно выбрать один кон крет н ы й процессор. Этой командой удобно пользоваться при отладке програ м м , п оддерживаю­ щих с и м м етричную м ногопроцессорную обработку. И нтересно также узнать, наскол ь­ ко систе ма эффективно ( ил и неэффективно) работает с нескол ьки м и процессора м и . Рассмотрим пример отображения состояния каждого из четырех п роцессоров. l i nux $ шpstat — Р ALL 0 8 : 1 3 : 3 8 РМ CPU % u s e r % n i c e о 1 . 02 0 . 00 0 8 : 1 3 : 3 8 РМ 1 0 . 2 8 0 . 00 0 8 : 1 3 : 3 8 РМ 2 0 . 42 0 . 00 0 8 : 1 3 : 3 8 РМ 3 0 . 38 0 . 00 0 8 : 1 3 : 3 8 РМ

% s y s % i owa i t 1 . 29 0 . 49 о.71 0 . 22 1 . 32 0 . 36 0 . 30 0 . 94

% i r q % soft 0 . 04 0 . 38 0 . 00 0 . 01 0 . 00 0 . 05 0 . 0 1 0 . 05

% idle 96 . 79 98 . 7 6 97 . 84 98 . 32

i nt r / s 473 . 93 232 . 8 6 2 93 . 85 2 95 . 02

Централ ьн ы й п роцессор однопол ьзовател ьской рабоч е й ста н ц и и обыч н о проста­ и вает бол ьшую часть вре м е н и . Когда запрашивается прокрутка содержимого окна или обновляется веб-стран и ца , централ ьн ы й процессор с правляется с этой операцией за считан н ые доли секунды . В такой с итуации долгосроч н ы й средни й показатель исполь­ зования централ ьного процессора практически л ишен смысла. Еще одн и м статистически м показателем , полезны м для оценки и нтенсивности ис­ пол ьзован ия систе м ы , является показатель «средняя загружен ность» , которы й п редстав­ ляет собой среднее количество выпол н яемых процессов. Он дает достаточное представ­ ление о том , сколько процессов требуют свою долю процессорного времени. Узнать его значе ние можно с помощью команды uptime. $ uptime l l : l O am up 3 4 d a y s ,

1 8 : 4 2 , 5 u s e r s , l o a d ave r a g e : 0 . 9 5 , 0 . 3 8 ,

0 . 31

Эта команда выдает три значен ия , которые соответствуют средней загружен ности за пять, десять и пятнадцать м и нут. Как правило, чем выше средняя загруженность, тем важнее общая производител ьность систе м ы . Есл и выпол няется всего л и ш ь оди н п ро­ цесс, то он обычно ограничен одн и м ресурсом ( це нтрал ь н ы м процессором ил и п ро­ пускной способностью дискового канала ввода-вывода). П и ковы й спрос на этот ресурс и становится определя ющим фактором производительности . Когда в системе одновременно работает несколько п роцессов, нагрузка распределя ­ ется более равномерно. Есл и все работающие процессы потребл я ют ресурсы централь-

1 082

Часть lV. Эксплvатация

ного процессора, диска и памяти , то зависимость производительности с истем ы от огра­ н ич е н н ых возможностей какого-то одного ресурса сн ижается . В такой ситуации гораздо важнее следить за средн и м и показателя м и загружен ности , в частности за общим време­ нем испол ьзования центрального процессора.

m Дополнительную и нформацию о приоритетах см . в разделе 4 . 2 . Показатель средней загруженности отлично подходит Д/I Я повседневного контроля сис­ темы. Если известен показатель работающей системы и он находится в диапазоне, характер­ ном для перегрузки, значит, следует искать внешний источник проблемы (это может быть, к примеру, сеть) . В противном случае нужно проверить процессы самой системы. Еще оди н способ контроля над использованием централ ьного процессора — посмо­ треть, какую часть его времени отн имает каждый процесс с помощью команды ps -aux. Зачастую в и нтенс ивно экс плуатируемой системе минимум 70% времени работы цент­ рального процессора отнимается одним-двумя процессами. Запуск таких процессов в дру­ гое время суток или сниже н ие их п риоритетов позволит высвободить ресурсы Ц П ДII Я вы­ полнения других процессов.

W Подробнее об утилите top рассказывалось в разделе 4 . 4 . П рекрасной ал ьтернативой команде ps я вляется утилита top. Она вьщает примерно ту же и нформацию, что и ps, но в «живом » , постоян н о обновляемом формате , позволя­ ющем набл юдать за измен е н ием состояния системы во времени . 1

Уп ра вление пам я т ь ю в системе В U N IX- и Li nux-cиcтe мax память орган изована в виде блоков, называем ы х стра­ ницам и , размер которых составля ет 4 Ки Б или больше. Когда процессы запрашивают

у операционной с исте м ы память, ядро выделяет им виртуальные страницы. Каждой та­ кой странице соответствует н астоящее физическое хран илище, такое как операти вное запоми нающее устройство ил и «резервное запоминающее устройство» на жестком дис­ ке. (Резервное запоминающее устройство обычно представляет собой просто простран ­ ство в области подкач ки, но дл я страниц, которые содержат код испол няемой програм­ мы, резервное запом инающее устройство — это самы й настоя щий исполняемый файл . Аналогично резервное запоми нающее устройство Д/IЯ н екоторых файлов дан ных может представлять собой сами файл ы . ) Информация о связях между виртуал ь н ы м и и реаль­ н ы м и страницами хран ится в табл ице страниц. Ядро способно эффективно обслуживать запросы процессов, выделяя ДII Я них столь­ ко памяти , с кол ько им нужно. Это реал изуется за счет дополнения области подкач ки к реальной оперативной памяти . Поскольку Д/I Я работы процессов требуется, чтобы их виртуал ьн ы е страницы находил ись в реал ьной памяти , ядру постоян н о приходится пе­ ремещать страницы между оперативной памятью и областью подкачки. Такие операции н азываются страни чным обменом (paging ) . 2 Ядро старается управлять памятью так , чтобы стран и ц ы , к которым недавно об­ ращались, хранились в физической памяти , а менее акти вные страницы выгружались н а диск. Этот ал горитм известен под н азванием L R U ( least recently used — заме ще н ие ‘ Утилита top требует довольно м н ого систе м н ых ресурсов, поэтому пол ьзуйтесь ею в разумных пределах . 2 Когда-то и м ела м есто иная оп ераuия, именуе мая подкачкой (или свопингом ) , посредством которой все стран ицы н екоторого процесса одновременно переписывались на диск. Теперь же во всех слу­ чаях обязательно используется странич н ы й обмен (paging) .

Глава 29. Анализ производительности

1 083

наименее испол ьзуемых элементов) , поскольку те страни ц ы , к которым долго н и кто не обращался , перемещаются на диск. В проч е м , отслеживать все обращени я к стр ан ицам было бы сл и ш ко м накладно для ядра, поэтому оно использует страничный кеш-буфер, анализ содержимого которого и позволяет принять решение о том , какие и ме н но страницы оставить в памяти . Точн ы й ал горитм этого механизма зависит о т конкретной с исте м ы , но везде действует примерно один аковы й при н ц и п . Такой вариант гораздо проще в реал и зации , чем LRU-с истема, а результаты дает почти такие же . В случае нехватки памяти ядро пытается определить, какие страницы из » неактив­ ного» с писка давно н е испол ьзовались. Если при последнем обращен и и такие страницы модифицировал ись процессом , ядро считает их » гря зн ы м и » ; они обязательно должны быть выгруже н ы на диск, прежде чем зан и маемая и м и память будет повторн о испол ь­ зована. Все остал ьные страни ц ы реальной памяти считаются «ч истым и » и могут быть назначены другому процессу. Когда выполняется обращен ие к странице из » н еактивного » списка, ядро возвраща­ ет ссылку на нее в табли цу страниц, обнуляет ее » возраст» и п ереводит страницу из » не­ активного » списка в «актив н ы й» . Если при этом изменяются адреса страниц реальной памяти, то страницы, выгруженные на диск, должны быть сначала прочитаны с диска, прежде чем их можно будет активизировать. Когда п роцесс обращается к неактивной с транице , находящейся в памяти , происходит программный сбой (это так называемая » мягкая ошибка» , или «soft fault » ) . В случае обращения к нерезидентной (выгруженной) странице и меет место аппаратный сбой (так н азываемая «жесткая ошибка» , » hard fault» ) . Друrими словами , при возн икнове н и и ошибки второго типа ( в отличие о т первого) тре ­ буется прочитать страницу с диска. Я дро старается прогнозировать потребности приложе н и й в памяти , поэтом у опе­ раци и выделения и выгрузки страни ц не обязательно взаимосвяза н ы . Цель систе м ы обеспечить нал ичие достаточного объема с вободной памяти , чтобы процессам не при ­ ходилос ь ждать выгрузки страниц всякий раз, когда и м нужна свободная память. Если в периоды сильной загружен ности с исте м ы страни чный обме н резко возрастает, и меет с мысл купить допол нител ьную память. Можно измен ить значен и е » коэффициента подкачки » ( /proc/sys /vm/ swappine s s ) и тем самы м дать ядру подсказку о том , при каком проценте с вободной памяти следует начинать активную выгрузку страниц. Если уста­ новить это значение равн ы м нулю, то выгрузка стран и ц на диск начнется только когда закончится с вободная память. При значен и и этого параметра 1 00 , все страни ц ы будут автоматически вытесняться на диск. По умолча­ нию дл я этого параметра устанавливается значение 60, т.е . в ы грузка стра­ н и ц начнется , когда процент использования основной памяти достигнет 40 ( 1 00-60=40) . Если у вас возникает желани е изменить этот параметр, значит, возможно, пришла пора увел и ч ить объем оперативной памяти . Если ядру не хватает как физической памяти , так и области подкач ки , это означа­ ет, что виртуальная память исчерпана. В данной с итуации включается режим » прину­ дительного уни чтожения » . Чтобы освободить память, с исте м е приходится уничтожать целые процессы . И хотя выбираются наименее важные для систем ы п роцессы , все равно это очень неприятная процедура, ведь значительная часть ресурсов системы тратится не на полезную работу, а на управление памятью.

Часть lV. Эксплvатация

1 084

А нал из использова ния памяти И нтенсивность операций с памятью количественно представляется двумя показателями: общим объемом задействованной виртуальной памяти и текущи м коэффициентом стра­ н ичного обмена. Первый показатель характеризует общую потребность в памяти, а второй указывает на то, какая доля этой памяти активно используется. Задача администратора за­ ключается в снижении и нтенсивности использования или увеличении объема памяти до тех пор, пока не будет достигнут приемлемый уровень страничного обмена. Страничны й об­ мен — процесс неизбежный, поэтому не пытайтесь полностью избавиться от него. Для того чтобы определить размер текущей области подкачки в системе Linux, вы­ полн ите команду swapon — s . l i n u x $ swapon — s Т ур е Fi l e name / d e v / hdЫ p a r t i t i on / de v / h d a 2 p a r t i t i on

Used

Size 4 0 9 6532 4 0 9 6564

о о

Priority -1 -2

При выполнении команды swapon значения выводятся в килобайтах. Значения раз­ меров, выводимые эти м и командами , не включают содержимое памяти ядра, поэтому вам придется вычислить общий объем виртуальной памяти самостоятельно. VМ = о б ъ е м о п е р а т и в н ой памя т и + исполь зуемый о б ъ ем о бл а с т и подкачки

В системе Free BSD вывод статистических показателей страничного обмена, полученных с помощью команды vmstat, выглядит так. f r e e b s d $ vms tat 5 5 page p r o c s memo r y re flt fre r Ь w avm о 97 о о о 4 12М 1 . BG 1 о 2 о о 4 1 2М 1 . BG о о 2 о о 4 12М 1 . BG о о 1 о о 4 12М 1 . BG о о о о о 4 12М 1 . BG

pi 1

о о о о

ро

о о о о о

fr 200 о 7 о 7 о 6 о 7

f a ul t s di s k in s r da O c d O 51 6 о о о 5 о о 4 о о о 4 о о о о 6 о о

sy 359 27 25 25 26

И з этого примера удалена и нформация об испол ьзовании центрального процессора. Под заголовком p r o c s показано кол ичество процессов, готовых к немедленному в ы ­ полнению, заблокированн ых в ожидан и и завершения операции ввода-вывода, а также готовых к выполнению, но вытесненных на диск. Если значение в столбце w когда — н и ­ будь станет отличным о т нуля, это будет означать, что объем систе мной памяти н е соот­ ветствует текущей загрузке. Столбцы, объединенные под общим заголовком memo ry, содержат дан ные об актив­ ной в иртуал ьной памяти ( a vm) и свободной виртуальной памяти ( f re ) . Столбц ы , объ­ еди н е н н ы е под общи м заголовком p a g e , содержат данн ы е об стран и чном обмене. Во всех этих столбцах представлены средние значения: количество в секунду (табл . 29.3). Таблица 2 9 . З . Описание статистических показателей , выводимых командой V111s tat Столбец

Описание п оказателя

flt

Общее количество страничны х сбоев Количество восстановленны х страниц, т.е . возвращенных из списка неиспол ьзуемых Объем подкачанных страниц в килобайтах Объем выгруженных страниц в килобайтах Объем списка неиспол ьзуемы х страниц в килобайтах Количество страниц, обработанных по алгоритму часов

re pi ро fr sr

глава 29. Анализ производительности

1 08 5

В с исте мах L i n u x статистические показатели , получае м ы е с п о м о щ ь ю команды vms t a t , могут иметь приведе н н ый н иже вид. l i nu x $ vms tat 5 5 p r o c s — — — — — — — — memo r y — — — — — — — — — — s wap — — — — i o — r Ь swpd f r e e b u f f c a c h e s i s o Ьi Ьо о 66488 40328 597972 5 о о о 252 45 о 66364 4 0 3 3 6 5 97972 о о о о о 37 о 66364 40344 597972 о о о 5 о о о о о 3 о о о 66364 40352 597972 о 66364 40360 597972 о о о 21 о о

— s y s t em in cs 1042 278 1009 264 1011 252 1020 311 1 0 67 507

— — — — — cpu — — — — — u s s y i d wa s t 3 4 93 1 о о 1 98 о о 1 1 98 о о 1 1 98 о о 1 3 96 о о

В с исте м е Free B S D кол и ч ество процессов , rотовых к н е медл е н н ому выпол н е н и ю и заблокирова н н ы х в ожида н и и ввода — в ы вода , вы водится под заrоловком p r o c s . Статистические показател и стра н ич ноrо обмена оrра н и ч е н ы двумя столбцам и : s i и s o , котор ые представля ют количество подкачан н ых и выrруже н н ы х стра н и ц соот­ ветстве н но. Кажущиеся несоответствия между столбцами бол ьшей частью иллюзорн ы . В одн их столбцах указывается ч исло стран иц, в друrих — объем в килобайтах. Все значения я вля­ ются окруrл е н н ы м и средн и м и вел ичинами. Более тоrо, одн и из них — средн ие скаляр­ ных вел и ч и н , а друrие — средние изменений. С помощью полей si и s o можно оцен ить и нтенсивность страничноrо обмена в си­ стеме. Операция заrрузки ( поле s i ) н е обязательно означает, что из области подкач ки восстанавли вается стран ица. Это может быть исполняемый код, постранично заrружа­ е м ый из файловой систе м ы , ил и копия стран ицы, создаваемая в режим е дублирования при зап иси . Оба случая впол не типич н ы и не обязател ьно означают нехватку памяти. С друrой сторон ы , операция вы rрузки ( поле s o) всеrда означает принудительное вытесне­ ние страниц с дан н ы м и ядром . Система, в которой не прерывно происходят операции в ы rрузк и , скорее всеrо, вы­ иrрает от добавления памяти . Если же это случается лишь врем я от времени и не вызы­ вает жалоб со стороны пользователей , то можно н е беспокоиться. В остальных случаях дальнейший анализ будет зависеть от тоrо, что нужно сделать — оптимизировать систе­ му для интерактивноrо режима ( например, как рабочую станцию) или сконфи rуриро­ вать ее для одновременной работы пользователей ( например, как сервер приложен ий).

А нал из операций обмена с диском П роизводительность жесткоrо диска можно контрол ировать с помощью команды iostat. Как и vmstat, эта команда подцерживает допол н ительные арrументы, задающие интервал времени в секундах между моментами выдачи статистических данных за истек­ ший период и число повторений. Команда iostat выдает также сведе н ия об испол ьзова­ нии центральноrо процессора. Приведем небольшой пример для системы Linux. l i nu x $ ios tat Devi c e : sda dm- 0 dm- 1 dm- 2

tps 0.41 0 . 39 0 . 02 0 . 01

kB_r e a d / s 8 . 20 7 . 87 0 . 03 0 . 23

kB_w r t n / s 1 . 39 1 . 27 0 . 04 О . Об

k B read 810865 778168 3220 22828

kB w r t n 137476 12577 6 3964 5 65 2

И н формация о каждом жестком диске размещается в столбцах t p s , kB r e a d / s . kB _w r t n / s , kB r e a d и kB w r t n : объем пересылок за секунду, количество килобайтов,

часть lV. Эксплvатация

1 086

считываем ы х за секунду, ч исло килобайтов, записываемых за секунду, общее количество считанн ых килобайтов и общее ч исло записанн ы х килобайтов. Время, затрачи ваемое на поиск блока, — основной фактор, влияющий на п}Юизводи­ тельность жесткого диска. В первом приближе н и и скорость вращен и я дис ка и быстро­ действие ш и н ы , к которой он подкл ючен , не имеют особого значен и я . Совре м е н н ые диски могут пересылать сотни мегабайтов данных в секунду, есл и эти данные считыва­ ются из смежных секторов. Вместе с тем количество операций поиска составляет от 1 00 до 300 в секунду. Есл и после каждой операции поиска будет читаться один — единствен ­ н ы й сектор, легко подсчитать, что в таком режиме задействуется менее 5% макс ималь­ ной пропускной способности канала обмена дан н ы м и с диском. Твердотельные диски и меют большое преимущество перед своим и механ ическим и предшестве н н иками , по­ скольку и х производительность не связана со скоростью вращения пластин и перемеще­ ниями головок. Независимо от того , какой в ид дисков вы испол ьзуете S S D или механические , для достиже н и я м а кс и м ал ьн о й производител ьности н еобходимо помещать файло­ вые систе м ы , которые применяются одновременно, на разн ые дис ки. Хотя тип ш и н ы и драйверы устройств вли я ют на степень эффективности, больши нство ком пьютеров могут работать с нескол ьк и м и диска м и параллельно, что знач ительно повышает про­ пускную способность дисковой подсистем ы . Например, дан н ые и журнальные файл ы веб-сервера и м еет с мысл размещать на разных дисках. Особенно важно распределить область подкачки между нескол ьк и м и диска м и , если это возможно, поскольку страничный обмен обычно замедляет работу систем ы в целом. М ногие систе м ы позволяют создавать как выделенные разделы подкачки, так и файлы подкачки, записываемые в обычную файловую с истему. —

W Подробнее о командах lsof и fuser см. в разделе 5 . 2 . Команда l sof, которая выводит список открытых файлов, и команда fuser, которая перечисляет П}Юцессы , использующие файловую систему, могут оказаться весьма полез­ н ы м и дл я выявления пробл е м , связанных со скоростью выпол н е н и я операци й обмена с диско м . Эти команды отображают взаимодействия м ежду процессам и и файловым и с истем а м и и могут указать на н е предусмотрен н ы е вами взаимосвязи. Например, есл и некоторое приложен ие записывает свой журнальн ы й файл на то ж е усТ}Юйство, кото}Юе используется для веден и я журналов регистрации базы данн ых, то в результате этот диск может стать «узким м естом » систе м ы .

Утил ита f io: а нал из п роизводител ьности дис ковой подсистемы Утилита fio ( g i t hub . com / axbo e / f i o ) доступна как для систем ы Linux, так и для си­ стем ы FreeBSD. Используйте ее для проверки производительности подсистем ы хранения дан н ых. Это особен но полезно в больших средах, где развертываются общие ресурсы хра­ нения (такие как сеть хранения данных). Если вы оказываетесь в ситуации , когда скорость работы систе м ы хранения дан н ых я вляется проблемой, часто бывает полезно определ ить следующие количественные показатели . •

П ропускная с пособность при выпол н е н и и операций в вода — в ы вода в се кунду ( IO PS) (чтение, запись и смесь) .

Средняя задержка (чтение и запись) .

Максимальная задержка ( макс и мальные значен и я задержек при чте н и и и записи).

Глава 29. Анализ производительности

1 087

Как часть дистрибутива fio в подкаталог examples в кл юче н ы файл ы конфигурации ( . fio) для типичных тестов. Рассмотри м пример просто го теста чтения -записи. $ fio read-write . fio Re a dW r i t e Te s t : ( g = O ) : rw= rw , b s = 4 K- 4 K / 4 К — 4 К / 4 К — 4 К , e n g= p o s i x a i o , d e p t h = l fio-2 . 1 8 Starting 1 thread Job s : 1 ( f= l ) : [ М ] ( 1 0 0 . 0 % done ] [ 1 1 0 . 3МВ / 1 1 2 . 1 МВ / 0 КВ / s ] ( 2 2 . l K / 2 8 . 4 К / 0 i op s ] [ e t a O O m : O O s ] r e a d : i o= l 0 2 4 . 7MB , bw= 9 1 3 2 6 KB / s , i op s = 2 0 6 0 1 , r u n t = 9 2 1 3ms e c s l a t ( u s e c ) : mi n= O , max = 7 3 , avg= 2 . 3 0 , s t dev= 0 . 2 3 c l a t ( u s e c ) : mi n= O , max = 2 2 1 4 , avg=2 0 . 3 0 , s t dev= l O l . 2 0 l a t ( u s e c ) : min= 5 , max=2 1 1 6 , avg= 2 2 . 2 1 , s t dev= l O l . 2 1 clat percentiles ( u s e c ) : 1 l . O O th= [ 4 ] , 5 . 0 0 t h = [ 6 ] , 1 0 . 0 0 th= [ 7 ] , 2 0 , 0 0 t h = [ 7 ] , 1 3 0 . 0 0 th= [ 6 ] , 4 0 . 0 0 th= [ 7 ] , 5 0 . 0 0 th= [ 7 ] , 6 0 . 0 0 t h = [ 7 ] , 1 7 0 . 0 0 th= [ 8 ] , 8 0 . 0 0 t h = [ 8 ] , 9 0 . 0 0 th= [ 8 ] , 9 5 . 0 0 t h= [ 1 0 ] , 1 9 9 . 0 0 t h= [ 6 6 8 ] , 9 9 . 5 0 th= [ 1 0 9 6 ] , 9 9 . 9 0 t h = [ 1 2 0 8 ] , 9 9 . 9 5 t h = [ 1 2 0 8 ] , 1 9 9 . 9 9 th= [ 1 2 5 6 ] READ : i o= l 0 2 4 . 7MB , a g g r b= 9 1 3 2 6K B / s , minb= 9 1 3 2 6 B / s , maxb = 9 1 3 2 6 K B / s , mi n t = 1 0 6 7 1 ms e c , max t = l 0 6 7 1 ms e c W R I T E : i o = l 0 2 3 . 4 MB , a g g r b= 9 8 2 0 2 KB / s , minb = 9 8 2 0 2 K B / s , maxb= 9 8 2 0 2 KB / s , mi n t= 1 0 6 7 1 ms e c , ma x t = 1 0 6 7 l ms e c

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

Кома нда s ar: сбор статистических да н н ы х и генерирование отчетов по ним Команда sar — предназначенный для монитори н га производительности инстр умент, которы й » проверен време н е м » (эта команда поя вил ась е ще во вре мена АТ&Т U N IX) на системах UN I X и Linux и все еще остается актуал ьн ы м , несмотря на испол ьзование устаревшего синтаксиса командной строки. На первый взгляд может показаться, что команда sar отображает ту же информа­ цию, что и команды vmstat и iostat. Однако имеется одно оче нь важное отличие: sar «умеет» предоставлять отчеты как по стары м (накопл е н н ы м ) , так и текущи м данн ы м . W Пакет Linux, который содержит команду

sar,

называется aya atat.

Если н е указаны кон кретные параметры, команда sar предоставляет отчет о том , как централ ь н ы й процессор испол ьзовался в течение то го или и ного дня кажды е 1 0 м и н . , нач и ная с полуноч и . Получение такого набора накопл е н н ы х дан н ых делает возможным сценарий sal , который является частью пакета sar и требует указания и нтервала време­ ни, через которы й он долже н запускаться из демона aron. Все дан н ы е , которые собира­ ет команда sar, она сохраняет в бинарном формате в каталоге /var/ log. l i nux $ sar L i n u x 4 . 4 . 0 — 6 6 — g e n e r i c ( nue rbul l ) 0 3 / 1 9 / 1 7 — х В б 6 4 — ( 4 C PU ) % idle 1 9 : 1 0 : 0 1 C P U % u s e r % n i c e % s y s t em % i owa i t % s t e a l 0 . 00 0 . 01 1 9 : 12 : 0 1 all 0 . 02 0 . 00 9 9 . 97 0 . 00 0 . 00 0 . 01 9 9 . 98 1 9 : 14 : 0 1 all 0 . 01 0 . 00 0 . 00

Часть lV. Эксплуатация

1 088

П ом и мо и нформации о центральном процессоре, команда sar также может предо­ ставлять отчеты по показателя м дисковой и сетевой активности . Команда sar d ото­ бражает сводку данных об активности диска за сегодняшний день, sar -n DEV стати­ стические данные о сетевом и нтерфейсе , а sar -А всю доступную информацию. Команда sar и меет некоторые огра н и ч е н и я и потому хорош о подходит тол ько для б ыстрого пол уч е н и я кратких накопленных с веде н и й . Тем , кто решил всерьез за­ н яться монитори н гом производительности , л уч ш е установить специальную платформу с возможностями сбора коллекций дан н ых и представления их в виде графиков, такую как платформа G rafana. —

W Подробнее о платформе Grafaпa см. в разделе 28 . 3 .

Выбор пла н и ровщика ввода — вывода в системах Linux В системах Linux испол ьзуется алгоритм план ирования подсисте м ы ввода­ вывода, которы й выступает в рол и «арбитра» между соревнующ и м ися за дисковый ввод-вывод процессам и . Он опти мизирует порядок и время за­ просов для обеспечения наилучшей возможной производительности подси­ сте м ы ввода-вывода для дан ного приложен и я или ситуаци и . В текущую версию ядра Linux встроен ы т р и разных алгоритма планирования. •

Comletely Fair Queui ng. Этот алгор итм испол ьзуется по умолчан и ю и обычно яв­ л яется наиболее подХодящим вариантом для серверов общего назначения. Он ста­ рается равномерно предоставлять доступ к подсистеме ввода-вывода. ( Во всяком случае этот ал горитм заслужи вает награды за маркетин г: кто с кажет » нет» совер­ шенно справедливому планировщи ку?) Deadline. Этот алгоритм «старается» сводить к минимуму время задержки для каж­ дого запроса. Он изменяет порядок запросов для повышения производительности. NOO P. Этот ал горитм реализует п ростую очередь типа F I FO ( First ln, First Out

первым приш ел , первым обслужен ) . О н предполагает, что запросы к подсистеме ввода-вывода уже были ( ил и еще будут) опти м и зированы ил и п ереупорядочены драй вером или устройством ( каковым вполне может быть какой-нибудь контрол­ лер со встроенной логико й ) . Он может быть н аиболее подходя щ и м вариантом в н екоторых SAN-cpeдax и дл я S S D-устройств (так как у этих устройств нет пере­ м е н ной задержки считывания дан н ых). П росмотреть или настроить алгоритм для конкретного устройства можно с помощью файла / sys /Ьlock/ диcк/queue / s cheduler. Актив н ы й планировщик указывается в квадратных с кобках. $ cat / sys/Ыock/sda/queue / scheduler noop deadl i n e [ c fq ] $ sudo s h — с «echo noop > / sys/Ыock/ sda/queue/ s cheduler » $ cat / sys/Ыock/sda/queue / scheduler [ noop ] d e a d l i n e c fq

Определив, какой из этих ал горитмов планирования я вляется наиболее подходящим дл я дан ной среды ( что может потребовать проверки всех планировщи ков), возможно, вам удастся улучш ить производительность подсистемы ввода-вывода. W Дополнительную информацию о загрузчике GRUB см. в разделе 2 . 3 .

Глава 29. Анализ производительности

1 089

К сожал е н и ю , ал горитм план ирования не сохраняется при перезагрузке систе м ы , есл и он был установлен таким образом . Вы можете установить е го для всех устройств во время загрузки с помощью перемен ной ядра е lеvаtоr=алгоритм. Эта конфигурация обыч но устанавл ивается в файле конфигурации загрузч ика G RUB gruЬ . conf .

П ро г рамма perf: уни версал ьн ый п рофил и ровщик системы Linux Ядро Linux версии 2 . 6 и в ы ш е включает интерфейс p e r f_eve n t s , которы й обеспечивает доступ на уровне пол ьзователя к потоку событий , связанных с производительностью ядра. Команда perf это мощн ы й интегрирован­ ный систе м н ый профил ировщик, который считывает и анализирует инфор­ мацию из этого потока. Можно профил ировать все ком поненты с исте м ы : аппаратное обеспечени е, модули ядра , само ядро , совместно испол ьзуе м ы е библ иотеки и приложения. —

Ч тобы начать работу с командой perf , вам нужно будет установить пол н ы й набор пакетов l inux- too l s . $ sudo apt-qet ins tall linux- tools — common linux- tools-qeneric linux- tools — ‘ uname -r ·

После того как вы установил и програм м ное обес печение, ознаком ьтесь с его руко­ водством на сайте goo . g l / f 8 8rnt , в котором при веде н ы примеры и с ценарии использо­ ван ия. (Это глубокая ссылка на сайт pe r f . w i k i . k e r ne l . o r g . ) Сам ы й легкий путь начать работу не погружаясь в чтение документации — попробо­ вать выпол н ить команду perf top. которая выводит на экран данн ы е об использовании централ ьного процессора в стиле команды top. Конечно, простой пример, приведе н ­ н ы й н иже , дает только самое поверхностное представление о команде perf. $ sudo perf top S amp l e s : 1 6 1 К o f event ‘ cpu- c l o c k ‘ , Event count ( ap p r ox . ) : 2 1 6 9 5 4 3 2 4 2 6 S ymЬ o l Ove r h e a d S h a r e d Ob j e c t [ k ] O x 0 0 0 0 7 f f f 8 1 8 3d3b5 [ ke rn e l ] 4 . 63% 2 . 15% [ ke rn e l ] [ k ] finish task switch [ ke r ne l ] [ k ] e n t r y_S Y S CALL_ 6 4_a f t e r_swap g s 2 . 04% [ k ] s t r 2 h a s hb u f _s i gn e d [ ke rn e l ] 2 . 03% [ ke rn e l ] 2 . 00% [ k ] h a l f m d 4 t r a n s f o rm find [ . ] Ох0000 0 0 0 0 0 0 0 1 6а0 1 1 . 44% [ k ] e x t 4 h t r e e s t o re d i r e n t 1 . 4 1% [ ke rne l ] 1 .21% libc-2 . 2 3 . s o [ . ] s t rlen 1 . 19% [ ke r ne l ] [ k ] _d_l o o kup _ rcu [ . ] Ox000000000001 69f0 1 . 14% find 1 . 12% [ k ] c o p y_ u s e r_gene r i c_un ro l l e d [ ke rne l ] [ ke rn e l ] 1 . 06% [ k ] kfree [ k ] _raw_s p i n_l o c k 1 . 0 6% [ ke r n e l ] [ . ] Ox000000000001 69fa find 1 . 03% 1 . 01% find [ . ] Ох000000000001 6а05 0 . 8 6% f i nd [ . ] f t s read kma l l oc [ ke rn e l ] [k] 0 . 73% 0 . 7 1% [ ke rn e l ] [ k ] e x t 4 r e addi r [ . ] ma l l o c l ibc-2 . 2 3 . so 0 . 69% libc-2 . 2 3 . so [ . ] fcntl 0 . 65% e x t 4 c h e c k_d i r_e n t r y [ k] [ ke r ne l ] 0 . 64% —

Часть lV. Эксплvатация

1 090

В столбце Ove r h e a d показан процент време н и , в течение которого процессор выпол­ н ял соответствующую функцию. В столбце S h a red Obj e c t указан компонент ( н апри­ мер, ядро) , совместно испол ьзуемая библ иотека ил и процесс, в котором находится эта фун кция, а в столбце S ymb o l — и м я функции (в тех случаях, когда и нформация о сим­ волах н е была удалена).

29.7. П ОМОГИТЕ!

Мой СЕРВЕР ТОРМОЗИТ!

В предыдущих разделах речь шла в основном о мероприятиях, которые позволяют до­ биться средней производительности системы. Для ее повышения требуется корректиро­ вать параметры конфигурации или модернизировать аппаратное обеспечение системы. Одн ако даже правильно сконфигурированные систе м ы иногда работают медленнее обычного. К счастью, нерегулярные пробл е м ы обычно легко диагностируются. В боль­ ш и нстве случаев о н и создаются » ненасытн ы м » процессом , который потребляет так м ного ресурсов процессора, жесткого диска или сетевой подс истем ы , что остал ьные процессы буквально останавливаются. И ногда процесс намеренно захваты вает ресурсы , чтобы замедлить работу с исте м ы или сети. Это называется атакой типа «отказ в обслу­ жи ван и и » . П ер в ы й шаг в диагностирова н и и пробл е м ы — запус к команд p s auxww и л и top дл я в ы я вл е н и я я в н о н еуправл я е м ых процессов. Л юбой процесс , отн имающий более 5 0 % вре м е н и центр ал ь ного процессора, можно с бол ьшой долей вероятности с ч и ­ тат ь н е н ор м альн ы м . Есл и стол ь непомерную дол ю ресурсов центрального процессо­ ра н е получает ни один процесс , посмотрите , сколько п роцессов пол учают м и н и мум по 1 0 % . Если и х больше двух-трех ( н е сч итая самой команды ps), средняя загруже н ­ ность с исте м ы , с корее всего, будет оч е н ь высокой . Такая с итуация сама по себе я в ­ л я ется п р и ч и н о й н изкой производител ьност и . П роверьте средн юю загруже н н ость с исте м ы с помощью команды uptime , а зате м в ы пол н ите ком анду vms tat или top , чтоб ы узнать, простаи вает л и когда- н ибудь процессор. Если кон куренции за право испол ьзован ия центрального процессора не н аблюдает­ ся, вы полн ите команду vmstat, чтобы посмотреть, какова интенсивность страничного обмена. Следует обращать внимание на все операции обмена с диском: м ножество опе­ рац ий выгрузки могут означать сопер н ичество за память, а наличие дискового трафика в отсутствие стран ичного обмена говорит о том , что какой -то процесс монополизировал диск, непрерывно читая и записывая файлы . Н ел ьзя н е посредстве н но сопоставить дисковые операци и с в ы пол н я ю щ и м и и х процесса м и , но с помощью команды p s можно сузить круг » подозре вае м ых » . Л юбой процесс , работающий с диском , должен отн и мать какую-то часть вре м е н и Ц П . Как правил о , всегда можно сделать обос нованное предположе ние о том , какой кон кретно ю активных процессов захватил ресурсы . 3 Для проверки с воей теори и н а практи ке вы­ пол н ите ком анду kill — STOP. Предположи м , процесс-виновник найде н . Что с н и м делать дальше? Как правило, ничего. Н е которые операции действительно требуют м ного ресурсов и неизбежно за1 J>анее признакам и этого служил и большой размер области данных процесса, размещенной в вир­ туальной па мяти , л и бо неестественно большой объем зани маемой процессом физичес кой памя­ ти , но появление совместно испол ьзуемых библиотек сделало эти показатели не столь полезны м и . Команда ps не умеет отделять общесисте м н ые совместно испол ьзуемые библиотеки от адресного пространства отде.1ьных процессов . Кажется , что многие процесс ы зан и мают десятки мегабайтов физической памяти , хотя на самом деле это не так.

Глава 29. Анализ п роизводительности

1 091

медляют работу систем ы, но это вовсе н е означает, что они незако н н ы . Однако с помо­ щью команды renice можно изменить приоритет процесса, для которого ограничиваю­ щим фактором я вляется быстродействие центрального процессора. И ногда правил ьная настройка приложе ния может привести к значител ьному сн иже ­ н и ю потреблен ия ресурсов. Этот эффект особенно заметен в сетевых серверных про­ граммах, например в веб-приложе ниях. В системе Liпux существует удобн ы й и нструме нт для работы с процессам и , которые со:щают значительную нагрузку на диск, — команда ionice. Эта ко­ манда устанавливает класс план ирования ввода-вывода процесса; по крайней мере оди н из доступн ых классов должен поддерживать числовые приоритеты ввода-вывода, которые также могут быть установлены с помощью команды ionice. Наиболее полезны м вариантом для запом инания является команда i onice с 3 -р p i d, позволяющая указан ному процессу выпол нять опе­ рации ввода-вывода только в том случае , если на это не претендуют другие процессы . —

Ядро позволяет процессу ограничи вать объем потребляемой и м сам и м физической памяти при помощи систе м ного вызова setrl imit.4 Эта возможность также доступна в системной оболочке в виде встроен ной команды ulimit (limits в системе F ree B S D ) . Например, команда $ uliшit -ш 3 2 0 0 0 0 0 0

ограничивает испол ьзован ие физической памяти для всех последующих пользовател ь­ ских команд тридцатью двумя мегабайтами. Ее действие примерно эквивалентно дей ­ ствию команды renice в отношении процессов, огран ичивающим фактором для кото­ рых я вляется объем памяти . Есл и н еуправл я е м ый процесс не является источн и ком с н ижен и я производител ь­ н ости . н ужно проанализировать две другие возможн ые прич и н ы . П ервая — переrрузка сети. М ногие програ м м ы настол ько тесно связаны с сетью, что иногда трудно понять, где реч ь идет о производительности систе м ы , а где — о производител ьности сети . В некоторых случаях проблем ы , связан н ые с перегрузкой сети , выявить сложно, по­ тому что они возн икают и исчезают оче нь быстро. Например, есл и на всех комп ьютерах сети каждый ден ь в определенное время с помощью демона cron запускается какая -то сете вая программа. то в сети может возн икать кратковрем е н н ы й , но серьезный затор. Все ком пьютеры » зависнут » секунд на пять, после чего ситуация нормализуется. Вторая причина — задержки, связанные с работой серверов. U N IX — и Liпuх-системы постоя н но обращаются к удал е н н ы м серверам N F S , Ke rbe ros, D N S и т. п . Есл и сервер не работает или какая-то иная проблема при вела к тому, что связь с ним стала ненадеж­ ной, это ощущают на себе все клиентские систе м ы . П редположим , что в инте нсивно экс плуатируе мой системе какой-то процесс каждые несколько се кунд вызы вает библиотеч ную фун кцию gethos tent. Есл и сбой в работе D N S заставляет эту фун кцию тратить на с вое выполнение две се кунды , будет заметно общее снижен ие производител ьности систе м ы . На уди вление, бол ьшое ч исло проблем с производител ьностью серверов связано с не правил ьной конфигурацией прямою и об­ ратного поис ка в D N S . 4 Более тон кое управление ресурсами может быть дости гнуто посредством С К R М -функций (Class­ based Kerпel Resource M a пage meпt управле н и е ресурсам и ядра на ба зе классов) ; с м . c k rm . s o u r c e f o r g e . ne t . —

часть lV. Эксплvатация

1 09 2

29.8. Л ИТЕРАТУРА 1 wn

DREPPER U LR I C H . What Every Programmer Should Know about Memory. Art i c l e s / 2 5 0 9 6 7 .

EzoLт Рн 1 ш r G . Optimizing Linux Pe!formance. Upper Saddle River, N J : Prentice На\ PTR, 2005.

GREGG, B R E N DA N . Systems Performance: Enterprise and the Cloud. Upper Saddle River, NJ : Prentice На\ PTR, 20 1 3 .

KozюL, РRАвнлт, AN D Q ш N CEY Ko z ю L. Нigh Pe!formance Parallel 1/0. London : C RC Press, 20 1 4.

. net/

Глава

30

ц ентры обраб отки данных

Надежность службы зависит от надежности работы центра обработки дан н ых, кото­ рый ее обеспеч ивает. 1 Для специалистов, имеющих практический опыт, это очевидно. Сторонники облач ных вычислен и й и ногда, по- видимому, подразумевают, что обла­ ко может вол шебны м образом разбить цеп и , соеди няющие физический и виртуал ьн ы й м ир ы . Однако, хотя облачные провайдеры предлагают множество услуг, которые помо­ гают повысить устойчи вость и доступность, кажды й облач н ы й ресурс в конечном итоге живет где-то в физической реальности . Пониман ие того, где на самом деле находятся ваш и дан ные, я В11 я ется важной частью работы систе м ного адм и н истратора. Есл и вы участвуете в выборе сторо н н их облач ных провайдеров, оцените поставщиков и их возможности кол ичествен но. В ы также може ­ те оказаться в положен и и , когда безопасность, суверен итет дан ных ил и пол итические пробл е м ы диктуют необходимость создания и обслужи ван ия собстве н ного центра об­ работки дан н ых. Центр обработки дан ных состоит из следующих компоне нтов. •

Физически безопасное и защищенное место.

Стойки с комп ьютерам и, сетевым оборудованием и дискам и .

Система энергос набжения (ос новная и резервная ) , достаточ н ая для работы всех размещенных устройств.

1 По край н е й мере в п е рвом п р и бл иже н и и . Разум еется , мож н о рас предел ить службу м ежду нескольким и це нтра м и обработки дан н ых, те м сам ы м огран и чи в вл и я н ие сбоя в каком -л ибо и з центров.

Часть lV. Эксплуатация

1 094 •

Система охлажден и я для поддержки требуе мого тем пературного режима работы устройств.

Сетевые соеди н е н и я внутри центра и с внеш н и м м и ром ( корпоративная сеть, партнеры , поставщики оборудования, И нтернет).

Техн ический персонал , поддерживающий работу оборудования и инфраструктуры.

Некоторые аспекты центров обработки данн ых, такие как их физическое расположе­ ние, систе м ы электропитания и охлаждения, традиционно разрабатывались и поддержи­ вал ис ь техническим персоналом объекта. Тем не менее стремительн ые тем п ы развития IТ-технологий и все более высокие требования к н едопустимости простоев стимулируют тесное сотрудничество между сотрудниками IТ-подразделений и техническим персона­ лом при планировании и эксплуатации центров обработки данн ых .

3 0. 1 .

Стойки

Времена традицион н ых центров обработки данн ы х с фальшпол ам и , в которых ка­ бели эле ктропита н и я , с истем а охлажден и я , сетевые соедине ния и телефон н ы е л и н и и спрята н ы под полом , прошли . Сможете л и в ы обнаружить кабель, которы й теряется в подпольном лабиринте? Наш опыт подсказывает, что все это выглядит красиво толь­ ко на картинке, а на самом деле комната с » классическим» фал ьшполом — это просто с крытая » крысиная нора » . Сегодн я фал ьш полы используются только для того, чтобы скрыть эле ктрические кабели , распредел ить охлажден н ы й воздух и больше ни для чего. Сетевые кабели (и м едный, и оптоволоконн ы й ) должны проходить по верхним направ­ ляющим коробам.2 В специал изированн ых центрах обработки дан ных размещение оборудования в стой­ ках (а не, скаже м , на столах или на полу) — еди нстве н н ы й профессиональный выбор с точки зрения обслуживания. В луч ш их схемах расположен ия запоминающих устройств используются стойки, связанные друг с другом через верхние направляющие короба, по которым проходят кабел и . Этот подход обеспечивает в ысокую технологичность без по­ тери возможности для сопровождения. Лучшие верхние направляющие короба для кабелей, насколько нам известно, произ­ водятся компанией Chatsworth Products ( c h a t s w o r t h . c om). Использова н ие стандартн ых 1 9 -дюймовых монорельсовых телеком мун и кацион н ых стоек позвол яет создавать бло­ ки серверов, м о нтируемых на полках или в стойках. Две смежные 1 9-дюймовые тел е ­ коммун и кационн ы е стойки создают высокотехнологичную разновидность «традицио н ­ ной » стойки дл я ситуаций, в которых вы вынужден ы располагать в соседних стойках оборудовани е , ориентированное относительно передне й и задней панелей. Компания Chatsworth поставляет стойк и , короба дл я кабеле й и всякие приспособл е н ия для и х укладки и маркировки, а также оборудован и е , н еобходимое для и х монтажа в ваш е м зда н и и . П ос кол ьку кабели располагаются в доступн ых коробах, их легко отслежи вать и содержать в порядке .

30.2. ЭЛЕКТРОПИТАНИЕ Компьютерное оборудование требует стабильного и бесперебойного электропитания. Для этого центр обработки дан ных должен иметь следующие ком поненты. 2 Провода электропитани я в настоящее время также проходят по наружным кана.лам .

Глава 30. Центры обработки данных

1 095

Источники бесперебойноrо электропитания (UPS) обеспечива ют пита н и е , ко 1’да обыч н ы й стационарн ы й источ н и к п итания (например, ком м ерческая эле ктро­ сеть) становится недоступ н ы м . В зависимости от размера и мощности источ н и ки бесперебойного электропитания могут обеспечивать работу оборудования на про­ тяже н и и от нескольких м и нут до нескольких часов. Они н е могут самостоятел ьно поддерживать работу устройств в случае длительного отключения внешнего элек­ тропитания. Автономные резервные электроrенераторы. Если ком мерческая сеть эле ктропитания н едоступна, автоном ные резервные эле ктрогенераторы могут обес печ ить дол го ­ времен ную работу оборудования. Генераторы обычно заправля ются дизельным то­ пли вом , сжиже н н ы м ил и природны м газом и могут поддерживать работу систе м ы до тех пор , пока имеется топл и во. Обыч но принято хран ить н а месте запас топ,1 и ­ в а как м и н имум н а 7 2 часа работы и организовать покупку топл и ва у нескол ьких поставщиков. Резервные фазы электропитания. В некоторых местах существует возможность под­ кл ючить оборудован ие к нескольки м фазам электропитания ( возможно, от разн ых поставщиков) .

m П роцедуры выкл ючения и перезагрузки системы описаны в разделе 2 . 9 . Во всех случаях серверы и сетевая и нфраструктура должны оснащаться источ н и ка­ ми бесперебой ного эле ктропитания. Качествен н ые устройства U PS имеют интерфейсы Ethernet или USB, позволяющие подключать их к ком пьютеру, которы й они обеспечива­ ют эле ктричеством , ил и к це нтрализован ной системе слежения, с пособной обеспеч ить быстрое реагирова н и е . Такие соеди н е н и я позволяют пересылать на ком п ьютеры или операторам сообщения об отказе с исте м ы электропитания и требова н и я выпол н ить ак­ куратное выключение ком пьютеров, пока не разрядились батареи. Устройства U PS имеют разные размеры и мощности , но даже самое бол ьшое из н и х не может служить долговре м е н н ы м источн иком электроп итан ия. Есл и ваше оборудова­ ние должно работать от автоном ного источ н и ка п итания дольше, чем может выдержать U PS, вам нужно подкл ючить к системе автоном н ы й резервный эле ктрогенератор. Существует ш ирокий выбор резервн ых генераторов, мощность которых колеблет­ ся от 5 до 2500 к Вт. Золотым стандартом я вл яется семе йство генераторов ком пан и и Cumm i ns Onan ( powe r . cummi n s . com) . Бол ьш инство орган изаци й выбирает дизел ьн ы й ге нератор. Если в ы работаете в холодном климате , примите меры , чтобы генератор был заправлен «зимней солярко й » , ил и зам е н ите ее авиацио н н ы м топли вом J et А- 1 , чтобы предотвратить гелеобразование. Дизельное топл иво является химически стабил ьн ы м , но со вре менем в нем могут заводиться водоросл и . П оэтому, если вы план ируете хран ить дизел ьное топливо долгое время, добавьте в него альгицид. Ге нераторы и обслужи вающая их и нфраструктура — довольно дорогое удовол ьствие , но в не которых ситуациях они могут сэконом ить вам де н ьги . Если вы планируете уста­ новить резервный ге нератор, то ваш е устройство U PS должно быть достаточно мощн ы м , чтобы после выключения электропитан ия в ы успел и запустить резервн ы й генератор. Если вы испол ьзуете устройства U PS ил и генераторы , чрезвычайно важно периоди­ чес ки их тестировать. М ы рекоме ндуем тестировать все ком поненты резервной систе ­ мы электропитания каждые полгода. Кроме того, вы (ил и производител ь оборудован и я ) должны выпол нять регламентные работы н а этом оборудовании как м и н и мум раз в r·од.

Часть lV. Эксплуатация

1 096

Требования к электроснабжению стоек Планировани е электросн абжен и я центра обработки дан н ых — одн а из наиболее сложных задач . Как правило, возможность создать новый центр обработки дан н ы х или значительно перестроить существующий возникает каждые десять лет, поэтом у, обдумы­ вая с истему электроснабжен и я , важно заглянуть далеко в будущее. Бол ьш инство архитекторов дп я вычисл е н ия мощности , необходимой в перспективе дпя обеспечен и я работы це нтра обработки данн ых , склонн ы умножать е го площадь в кв. футах на некий загадочн ы й поправочн ы й коэффициент. В реальных с итуациях этот подход не эффективе н , потому что сам по себе размер центра обработки данн ы х н есет мало и нформации о типе оборудован и я , которое в нем будет работать. М ы рекомендуем испол ьзовать м одел ь энергопотребл е н ия в расчете на сто й ку и не обращать в н имания н а площадь пола. Традиционно центр ы обработки дан н ы х п рое ктировал ись так , чтобы на каждую стойку приходилось от 1 , 5 до 3 к Вт мощности . В настоящее время производители стал и упаковывать серверы в стоечные корпуса типа 1 U и создавать шасси лезви й н ы х серве­ ров, в которых размещаются более 20 лезв и й , поэтому мощность, необходимая дп я п и ­ тани я всей стойки соврем е н ного электронного оборудовани я , резко возросла. Одно из возможных реш е н и й проблем ы , связанной с плотностью упаковки оборудо­ вания и ростом при этом потребляемой мощности , — размещать в каждой стойке толь­ ко необходимое количество серверов типа 1 U, оставляя остальную часть стойки пустой. Н есмотря на то что эта технология устраняет н еобходимость обеспечения дополн итель­ ной мощности дпя стойки , она п р иводит к чрезмерному растрачиван и ю места. Л уч ш е разработать реалисти ч н ы й проект обеспеч е н ия мощ ности, которая м ожет понадобиться дпя каждой стойки , и подумать, где ее взять. Требовани я к мощности у разного оборудования разл и ч н ы е , поэтому трудно пред­ с казать, какая мощность понадобится в будуще м . Целесообразн о создать с исте м у с раз н ы м и уровн я м и потребления мощности , в которой н а каждом уровне в с е стойки получают одинаковую мощность. Эта схема полезна не только дпя удовлетворе н и я по­ требностей текущи х моделей, но и дпя планирован ия будущего использования. Ряд фак­ торов , которые следует учитывать при определе н и и уровне й потребляемой мощност и , перечислены в табл . 30. 1 . Таблица 30. 1 . Оценки уровня мощности для стоек в центре обработки данных Уровень мощности

кВт/стойка

Н евероятно высокая плотность или специальные требования

40

Сверхвысокая плотность

25

Очень высокая плотность ( например, лезвийные серверы)

20

Высокая плотность (например , серверы 1 U)

16

Системы хранения данных

12

Сетевые коммутаторы

8

Обычная плотность

6

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

Глава 30. Центры обработки данных

1 097

Киловольт-амп ер или киловатт Одна из основных причин непонимания между специал истами по и нформационн ы м технология м , тех н и ками и инже нерам и -электрикам и закл ючается в том , что в каждой из эти х групп используются разные един ицы измере н и я м ощност и . В ы ходная мощ­ ность, которую может обеспечить устройство U PS , обычно измеряется в киловол ьт-ам­ перах ( к ВА) . Однако инженеры, обслуживающие ком пьютерное оборудован ие, и элек­ трики, обеспечивающие работу центра обработки дан н ых, обычно выражают мощность в ваттах ( Вт) ил и киловаттах ( к Вт). Возможно, вы помните из курса физики, что ватт вол ьт х ам пер. К сожалению, ваш ш кольный учител ь забыл напомнить, что ватт — это векторн ая величина, в формул у которой для выч исления мощности перемен ного тока, кроме напряже н ия ( вольт) и силы тока (апмер) , входит еще так наз ы вае м ы й » коэффи­ циент мощности» (power factor) . Если вы разрабатываете кон ве йерную л и н и ю по разливу п и ва на п ивоварен ном заво­ де , в которой используется много двигателей переменного тока и другого тяжелого обо­ рудования, то пропустите этот раздел и наймите квал ифицированного инженера, который вычислит коэффициент мощности для вашей установки. При работе с современным ком­ пьютерн ы м оборудованием вы можете схитрить и использовать константу. Для » прибли­ зительного» преобразован ия к ВА в к Вт можно использовать следующие формулы. =

=

к ВА

=

к Вт / 0,85

И наконец, оце н и вая суммар н ы е мощности , н еобходим ы е дл я центра обработки дан н ых ( ил и дл я вычисл е н и я выходной мощности устройства U PS ) , следует измерить реал ьную потребляемую мощность, а не полагаться на значен и я , указа н н ы е п роизво­ дителем оборудования на этикетке устройства, на которой обычно указываются макс и ­ мальн ые значения потребления. Ш Дополнительные советы по измерению потребляемой мощности см . в разделе 30.З.

Э нерzоэ ффективность Энергоэффе ктивность стала попул я р н ы м показателе м для о це н ки э кс плуатации центров обработки данн ых. П ром ышлен ность стандартизировал а простой коэффи ц и ­ ент, извест н ы й как эффекти вность испол ьзован и я энерги и ( power usage effectiveness P U E) , выражающий общую эффективность центра. P U E Общая мощность, потребляемая предприятие м / / Общая мощность, потребляемая IТ-оборудованием =

Гипотетически идеальный центр обработки данн ых должен и меть показатель PUE, равный 1 ,0; иначе говоря , он будет потреблять ровно столько энерги и , с колько необходи­ мо для работы IТ-оборудован ия, без накладных расходов. Конечно, эта цель недостижима на практике. Оборудование генерирует тепло, которое необходимо отводить, сотрудникам требуется освещение и другие условия для комфортной работы и т.д. Чем выше значение P U E , тем меньше энергоэффективность (и выше стоимость) центров обработки дан ных. Совре м е н н ые центры обработки дан н ы х , которые я вля ются достаточно энергоэф­ фективн ы м и , обычно имеют коэффициент P U E, рав н ы й 1 ,4 ил и менее. Для с правк и , центр ы обработки дан ных еще десять л е т назад обычно имел и коэфф и циенты P U E в ди­ а пазоне 2,0-3,0. Ком пания Google , которая сделал а акцент на энергоэффективность, ре гулярно публ и кует свои коэффицие нты PUE, а с 20 1 6 года она достигла в с воих цен­ трах обработки дан н ых среднего значения P U E , равного 1 , 1 2.

Часть lV. Эксплvатация

1 098

И змерение В ы м оже т е судить тол ько о том , что и меет кол ичестве н н ы й показател ь, получ е н ­ н ы й в резул ьтате и з м е ре н и я . Есл и в ы серьезно относ итесь к энергоэффе ктивност и , важно понять, какие устройства потребляют больше всего энерги и . Хотя коэффициент P U E дает общее предста вле н и е об объем е энерги и , потребляемой сверх IТ-ресурсов, он о ч е н ь м ал о говорит о энергоэффективности реал ьн ы х серверов. (Фактически за­ мена серверов на более энергоэффективные модел и увел ичит коэффи циент P U E , а не уменьшит е го . ) Адм и н и стратору це нтра об р аботки дан н ых следует выбрать ком поненты , которые испол ьзуют м и н и мал ьное коли чество энерги и . Одной из очевидных технологий я вля­ ется и з м ере н ие потребл е н и я э не р ги и на уровне отсека, стойки и устройства. Выберите или создайте центры обработки дан н ы х , которые могут легко предоставить наиболее важные да н н ы е .

Стоимость Когда-то стои мость эл е к т ро э н ергии была более ил и менее оди наковой дл я це нт­ ров обработки дан н ых в разн ых местах. В наши дни и ндустрия облач ных вычисле ний (Amazon, Google , Microsoft и др. ) заставляет проектировщиков центров обработки дан­ ных учитывать их потен циальную экономичес кую эффекти вность в любом уголке м ира. Одной из усп е ш н ы х страте гий бы ло размещение круп н ых це нтров обработки дан н ых вблизи источн и ков н едорогой электроэнерги и , таких как гидроэлектростанции. П р и н и мая решен ие о том , следует ли запускать собстве н н ы й центр обработки дан­ н ых , обязательно уч итывайте стоимость электроэнергии в вашей местности. Скорее все­ го, у круп н ых ко мпа н и й б уде т естествен ное преимущество в стоимости таких (и других) услуг. Ш и рокая доступность высокоскоростных оптических каналов передачи данных и их невысокая стоимость уже не ставят во главу угла поиск ближайшего центра обра­ ботки дан ных рядом с ваш и м местом работы.

Удаленное упра вление В ы м ожет е оказаться в с и туа ц и и , в которой необходимо регулярно включать и вы­ кл ючать се р ве р из-за о ш и бок в работе ядра ил и оборудова ния. Кроме того, возможно, в вашем це н тр е обр аботки дан н ых установле н ы серверы , которые работают под управ­ л е н и е м другой операцион ной сис тем ы а не Linux. В этом случае также часто возн и­ кает необходимость их регулярного в кл ючен ия и вы кл юче ния. В л юбом случае следует р ас смотр еть возможность и н стал л я ции систе м ы , позволяющей выпол н ять эти операции в удален ном р ежи м е Разумн ы м решением я вляется выбор продукции ком пан ии American Power Conversion (АРС ) . Продукция MasterSwitch похожа на линейку устройств бесперебойного п итания, за исключе н ие м того, что е ю мо жно управлять с веб-браузера с помощью встроен ного п орта Ethemet. ,

.

30.3. ОХЛАЖДЕНИЕ и ОКРУЖАЮЩАЯ СРЕДА Как и л юди , ком п ьютер ы луч ш е и дол ьше работают в бла гоприятной среде . Поддержка безопасной те мпературы — основное условие их благополучной работы.

Глава 30. центры обработки данных

1 099

Американская ассоциация и нженеров по отоплению, охлажде н и ю и кондициониро­ ван и ю воздуха (American Society of H eati ng, Refrigerating and Air-conditioning Engineers AS H RAE) традиционно рекомендует поддерживать тем пературу воздуха в центрах обра­ ботки дан ных ( и змеряемую на воздухозаборн и ках серверов) от 20 до 25 ·с. П оддерживая попытки организаций сократить потребление электроэнерги и , ассоциация AS H RA E вы­ пустила в 20 1 2 году новые рекомендаци и , согласно которы м тем пературу воздуха следует поддерживать в диапазоне от 1 8 до 27 ·с. Несмотря на то что этот диапазон кажется не­ обычайно ш ироким , он предполагает, что современное оборудование способно работать в ш и роком диапазоне тем ператур.

Оцен ка нагрузки на систе му охла ждения П оддержка требуемой тем пературы в помеще н и и н ачинается с точ ной оце н ки на­ грузки на систему охлаждения. Традицион ные модели охлаждения в центрах обработки да н н ых , взятые из учеб н и ков (даже и з к н и г, нап исанн ы х в 1 990-х годах) , могут на по­ рядки отл ичаться от сегодн я ш н и х реал и й , связа н н ы х с фун кционированием высоко­ упакованных шасс и , содержащих лезвийные сервера. По этой причи н е м ы рекомендуем перепроверять оценки нагрузки на систему охлаждения, полученные ваши м и инженера­ ми по отоплению, охлаждению и кондициониро вани ю воздуха ( HVAC) . В ы должны проверить тепловую нагрузку, которую оказывают следующие компоненты. •

Крыша, стены и окна (от и нженеров HVAC) .

Электронное оборудование.

Осветител ьная арматура.

Операторы (л юди).

Из этих факторов тол ько первый отн ос ится к ком п ете н ц и и и нженеров H VAC . Конечно, он и могут оце н ить и остал ьные факторы , но вы обязаны провести собствен ­ н ые вычисления. Оцен ите расхожден и я между ваш и м и оце н ками и оцен ками , получен ­ н ы м и инже нерами HVAC, и дайте исчерпывающее объяснение.

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

Электронное оборудование Для тоrо чтобы определить тепловую нагрузку, которую оказывают ваши серверы (и другое эле ктронное оборудование) , следует определить потребляемую серверами мощ­ ность. С практической точки зре ния вся входя щая эле ктрическая энергия в кон це кон ­ цов превращается в тепловую. Как и при план ировании мощностей по электропитанию, непосредственное измерение потребляемой мощности, безусловно, является лучшим способом получить эту информа­ цию. Вам может помочь дружелюбный сосед-электрик ил и же вы можете купить недорогой прибор и сделать это сами . Самым популярным устройством является КШ А Wcitt от ком па­ нии РЗ по цене около 20 долл . , но он ограничен небольшими нагрузками ( 1 5 ампер), кото­ рые подключаются к стандартной розетке. Для больш их нагрузок или нестандартн ых разъ­ емов используйте такие амперметры, как Fluke 902 (также известный как «токовые клещи»).

часть lV. Эксплуатация

1 1 00

Бол ьш ая часть оборудован ия характеризуется максимал ьной потребляемой мощно­ стью, измерен ной в ваттах. Однако типичное потребл е н и е , как правило, знач ител ьно мен ьше максимал ьного. Расход мощности можно преобразовать в стандартную еди н и цу кол ичества те пла BTU H ( B ritish The rmal Unit per hour — количество британских тепловых един и ц в час ) , умножив е го на коэффициент 3 ,4 1 2 ВТU Н/Вт. Н а п р и м е р , есл и вы хотите построить це нтр обработки дан н ых, в котором будет 25 серверов, потребля ющих по 450 Вт каж­ дый , то вычисления будут выглядеть следующим образом. 25 серверов х 450 Вт/сервер х 3 ,4 1 2 ВТU Н/Вт 38 385 BTU H . =

О светител ьная арматура Как и в случае эле ктрон ного оборудования, оцен ить тепловую нагрузку от освети­ тел ьного оборудования можно по расходу мощности. Как правило, в офисах в качестве осветительной арматуры используются 40-ваттн ые люминесцентн ые лам п ы . Есл и в ва­ шем новом центре обработки дан ных шесть таких светильников ( по 4 ламп ы в каждом), то вычисления будут выглядеть следующи м образом. 6 ламп х 1 60 Вт/светильн и к

х

3 ,4 1 2 ВТU Н/Вт

=

3276 BTU H .

Операторы И ногда л юдя м необходимо войти в цен тр обработки дан н ы х , чтобы выпол н ить какие-то действи я . Предположи м , что каждый входя щий человек создает тепловую на­ грузку вел и ч иной 300 BTU H . Допустим , что одновре менно в центр обработки дан н ы х м о гут войти четыре человека. 4 человека х 300 ВТU Н/чел 1 200 BTU H . =

Общая тепл овая нагрузка Вычисл и в тепловую нагрузку дл я каждого ком понента, просум м и руйте и х и опреде­ л ите общую тепловую нагрузку. В нашем примере мы п редполагал и , что инженер HVAC оце н ил тепловую нагрузку от крыш и , стен и окон равной 20000 BT U H . 20000 BTU H дл я крыш и , стен и окон 38385 BTU H для серверов и другого электрон ного оборудовани я 3 2 7 6 BTU H для осветительной арматуры 1 200 BTU H для операторов 6286 1 BT U H всего П роизводител ьность систем охлаждения обыч но измеряется в тон нах охлажде н и я . Для того чтобы преобразовать един ицы BTU H в тон н ы охлажде н ия , необходимо поде ­ лить результат на 1 2000 ВТU Н/т. Кроме того, следует допустить по край ней м ере 50%­ н ы й коэффициент ухудше н и я , чтобы учесть ош ибки и будущи й рост систе м ы . 6268 1 BTU H х 1 т / ( 1 2000 BTU H ) х 1 ,5

=

7 , 86 тон н охлаждения

П роверьте , насколько ваши оце н ки расходятся с оце н ками инже неров H VAC.

Глава 30. Центры обработки данных

1 1 01

Те п лые и холодные отсеки Вы можете резко уме ньшить трудности, связанные с охлажде нием центра обработки дан н ых, nроанализировав схему его устройства. Самой эффективной страте гией я вляет­ ся разделение центра на теnлые и холодные отсеки. П о м е щ е н и я , которые и м е ют фал ьш n ол и охлаждаются тради цион н ы м и C RAC (computer room air conditioner — кондиционеры воздуха в ком nьютерных комнатах) , ча­ сто с n роектированы так, что холодн ы й воздух nроходит nод nолом , nодн имается через отверстия в nерфорирован ном nолу, охлаждает оборудован ие, а зате м уже в нагретом состоя н и и nодн и мается к nотолку и всас ывается отводя щ и м и воздуховодам и . Обычно стойки и nерфорирован н ые nл итки nола рас nределяются no центру обработки дан ных «случайно » , и в резул ьтате обесnеч и вается относител ьно равномерное расnредел е н и е тем nературы . Вследствие этого среда становится комфортной для человека, но не оnти­ мальной для ком n ьютеров. Л уч ш е было бы чередовать теnлые и холодные отсе ки, разделяя их стойкам и . В хо­ лодн ых отсе ках находятся nерфорирова н н ы е nлитки nола, а в теnл ы х — нет. Стойки следует рас nоложить так , чтобы оборудование втя гивало воздух из холодного отсека, а отдавало — в те nл ы й . Таким образо м , сторо ны вы nус ка воздуха двух смеж н ых стоек должн ы расnолагаться бок о бок. Эта схема изображена на рис. 30. 1 . Эта схема оnтим изирует nоток воздуха так, чтобы воздуховоды серверов всегда втя ­ ги вал и холодн ы й , а не те nл ы й воздух , вышедш и й из систе м ы охлажден и я соседн е го сервера. П р и nравильном воnлоще н и и страте гия чередующихся отсеков nозволяет соз­ дать за метно холодные и заметно теnл ые отсеки . Эффе ктивность с исте м ы охлаждения можно оце н ить с nомощью и нфракрасного термометра ( nирометра) , который я вляется незаменимым инструментом совре менного системного адми н истратора. Это устройство стоит около 1 00 долл. ( наnример, Fl u ke 62) и nостоя н н о измеряет тем nературу л юбого nредм ета, на которы й вы его нацел ите на расстоян и и до 2 метров. Тол ько не доставайте его в баре!

Холодный отсек

Горячий отсек

Холодный отсек

Горячий отсек

Рис. 30. 1. Холодные и теплые отсеки с фальшполом

Есл и вам нужно развести кабеля nод nолом , nрокладывайте кабел и nитания nод хо­ лодн ыми отсекам и , а сете вые — nод теnл ы м и . В nомеще н иях б е з фальш nола могут исnол ьзоваться междуряд н ые охлаждающие устройства , наnример фирм ы АРС ( а р е . c om) . Эти небольшие nлоские устройства nо­ ме щаются между стойками. Принциn работы этой схемы nоказан на рис. 30. 2.

Часть lV. Эксплvатация

Стойка

Стойка

Стойка

Устройство охлаждения

Стойка

Устройство охлаждения

Стойка

Устройство охлаждения

1 1 02

Стойка

Стойка

Стойка

Стойка

Устройство охлаждения

Стойка

Устройство охлаждения

Оболочка отсека Hot aisle теплого containment Стойка

Стойка

Рис. 30.2. Холодные и теплые отсеки с междурядными охлаждающими устройствами

Устройства C RAC и м еждурядные устройства охлаждения должны иметь возмож­ ность отводить тепло за предел ы центра обработки данных. Это требование обычно удовлетворяется за счет циркуляции охлаждающей жидкости ( например, охлажденной воды , хладагента Puron/ R4 1 0A или R22 ) , которая отводит теruю во внешнюю среду. М ы н е показали н а рис. 30. 1 и 30.2 циркуляцию охлаждающей жидкости , чтобы н е загро­ мождать рисун к и , но в больши нстве проектов охлаждения они обязательно испол ьзу­ ются.

Влажность В соответствии с рекомендациям и 20 1 2 AS H RAE влажность воздуха в центре обра­ ботки дан ных должна быть в пределах 8-60%. Если влажность воздуха сли ш ком низкая , возн и кают п роблемы из-за статического эле ктричества. Проведен ное недавно исследо­ вание показало, что существует небольшая эксruJуатационная разница между 8% и пре­ дыдущим стандартом в 25%, поэтому м и н и мал ьн ы й стандарт влажности был скорректи ­ рован соответствующим образом . Если влажность сли ш ком высокая , конденсат воды может создать нежелательную проводимость на печатных платах, вызвать короткое замы кание и окисление контаков. В зависимости от географического расположен ия может возн икнуть необходимость увлажнения или осушения среды центра обработки данных, чтобы поддерживать требу­ емый уровень влажности.

М он итори нг окружа ющей среды Если вы обеспечиваете работу чрезвычайно важного вычислительного оборудования , необходимо следить за температурой ( и другим и факторами окружающей среды , таким и как шум и потребляемая мощность) в центре обработки дан н ых, когда в ы там отсутству­ ете . Вы будете оче н ь огорч е н ы , придя на работу в понедел ьн и к и обнаружив расплав­ ленный пластик на полу центра обработки данн ых. К счастью, существуют автоматические мониторы , которые могут следить за состо­ янием окружающей среды в ваше отсутствие. М ы сами используем и рекомендуем вам

Глава 30. Центры обработки данных

1 1 03

продукцию семе йства Sensaphone. Эти недорогие устройства для мон итор и н га следят за так и м и показател я м и, как те мпература, шум и потр ебляе м ая мощность, и звонят вам по телефону или отправля ют сообще ние на веб-сайт, если воз н и кают п робл е м ы .

3 0.4. УРОВНИ НАДЕЖНОСТИ ЦЕНТРОВ

ОБРАБОТКИ ДАННЫХ

И ссл едованием вопросов, связанных с управлен и е м це нтра м и обработки дан н ых , зан и м ается п ромышлен ная группа U ptime l nstitut e . Е е сотрудники ра зра ботал и четы­ рехуровневую систему классификации надежности центров обработки дан н ых, которая представлена в табл . 30.2. В этой табл ице обознач е н ие N означает, что в рас поряже н и и центра есть достаточно ресурсов (устройств U PS , генераторов) , чтобы обеспеч ить нор ­ мальную работу. Обозначение N+ 1 означает, что у ц е н тра есть одна запасная еди н и ца оборудован и я ; 2N — что у каждого устройства есть дубл ирующее обор удо ва н и е . Таблица 3 0 . 2 . Система классификации , преД11 оженная промыw11енной группой Uptime lnstitute Генератор UPS

Источник электропитания

HVAC

Коэффициент доступности, %

1

Нет

N

Один

N

99,67 1

2

N

N+ t •

Один

Уровен ь

N+ I

3

N+ I

N+ t •

Два (с возможностью переключения )

N+ I

4

2N

2N

Два ( работающих одновременно)

2N

99,741 99,982 99,995

ас зап асными компонентами .

Центр ы , относя щиеся к высшему уровн ю надежност и , должн ы быть раздел е н ы на отсеки, чтобы сбой с истем электропитания или охлажде ния в одной из груп п ы с и ­ стем не приводил к отказу другой. Коэффициент испол ьзования, равный 99,67 1 %, на первый взгляд может выглядеть привле кательн ы м , но это значит, что в тече ние года систе ма будет находиться в нерабо­ чем состоя нии примерно 29 часов. Коэффициент испол ьзован ия, равный 99,995 % , озна­ чает, что система может не работать 26 минут в год. Разумеетс я , н и какое кол и чество резе р в н ы х и сто ч н и к о в эле ктро п итан и я ил и устройств охлажде ния не спасет систе му, есл и она пл охо управляется ил и неправил ь­ но спроектирована. Це нтр обработки данных — это основной стр уктур н ый элемент, но е го недостаточ но для обеспечения работы всей орга н и зации с точ ки зре н и я конечного пользователя . Стандарт ы работос пособности с исте м , разработа н н ы е гру п п о й U p t i m e J nst itute ( включая сертифи кацию п роектов, конструкций и этапов эксплуата ци и ) , можно н а й ­ ти на ее веб-сайте u p t ime i n s t i t u t e . o r g . В некото р ы х случаях ор га н изаци и ис п ол ь­ зуют концепцию этих уровней, не выплач и вая з н ач и тельн ы х средств за сертификацию Uptime l nstitute. Важным я вляется не сертификат в рамоч ке , а испол ьзован ие общей лексики и методологи и оценки для сравнения центров дан н ых.

3 0 . 5 . БЕЗОПАСНОСТЬ ЦЕНТРОВ О Б РА Б ОТКИ

ДАННЫХ

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

1 1 04

Часть lV. Эксплvатация

что вы внимательно учли все возможные угрозы , как естественные ( например, пожар, на­ воднение, землетрясение) , так и искусственные (например, происки конкурентов и пре­ ступн и ков) . М ногоуровневый подход к безопасности — лучший способ гарантировать, что одна ошибка или сбой не приведут к катастрофическому результату.

Местонахожд ение П о возможности центры обработки дан н ых не должны располагаться в районах, под­ верженных л ес н ы м пожара м , торнадо, ураганам , землетрясениям или наводнениям. По аналоги ч н ы м пр и ч и на м ре комендуется избегать техноге н н ы х опасных зон , таких как аэропорты, автострады , нефтеперерабатывающие заводы и нефтебазы. Поскольку центр обработки данных, которы й вы выбираете (ил и создаете) , вероят­ но, будет ваши м домом в течение дл ительного времени, стоит потратить некоторое вре­ мя на изучение доступн ых данных о рисках при выборе места для его расположения. Геологическая служба США ( u s g s . g ov) п убли кует статистические данные , такие как вероятность землетрясени я , а организация Uptime I nstitute создает сложную карту рис­ ков, связанных с выбором места для расположен ия центров обработки данн ых.

Пери м етр Чтобы снизить риск целенаправленной атаки , центр обработки данн ых долже н быть окружен ограждением, находящимся на расстоян и и не менее 8 метров (25 футов) от зда­ н и я со всех сторо н . Доступ к внутр е н н е й части периметра огражде н ия должен кон­ тролироваться охранн и ко м или м ногофакторной системой п ропусков (бейдж-систем ы доступа) . Транспортн ые средства, которы м разреш е н въезд на территорию центра об­ работки данных, не дол жн ы находиться ближе 8 метров к зданию. Непрер ы в н ы й видеомон итор и н г долже н охваты вать 1 00 % вн е ш н е го пер и м етра , включая все ворота, подъездные пути доступа, автостоянки и кры ш и . Здания не должны и меть вывесок. Н и какая вывеска не должна указывать, кому при­ надлежит здание, или упоминать, что в нем находится центр обработки дан н ых.

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

Глава 30. Центры обработки данных

1 1 05

Доступ к стой ке Большие центры обработки данн ых часто сдаются в аре нду третьим сторона м . Этот подход экономически оправдан , но он несет дополнительную ответствен ность за орга­ н изац и ю защиты каждой стойки (или отсека стое к). Это еще оди н случай , когда необ­ ходима м ногофакторная система контроля доступа (например, устройство чтения карт памяти и считыватель отпечатков пал ьцев) , чтобы гарантировать, что только авторизо­ ван н ы е сторон ы и м е ют доступ к вашему оборудован и ю . Каждая сто й ка также должна иметь и ндивидуальную систему видеонабл юде ния.

3 0.6. ИНСТРУМЕНТЫ Эффективный систе м н ы й адм и нистратор — это хорошо оснаще н н ы й систе м н ы й ад­ м и н истратор . И меть набор специальных инструментов важно для м и н и м изации време­ н и простоя в случае отказа оборудования. В табл. 30. 3 перечислены некоторые и нстру­ менты , которые следует вкл ючать в такой набор. Таблица 30.З. И нструментальный н абор системного администратора Универсальные инструменты

Комплект шестигранных ключей (ключей Аллена)

Шариковый молоток, 1 50-200 грамм

Ножницы

Нож электрика или складной нож

Н ебольшой светодиодный фонарик

Крестообразная отвертка: №О, №1 и №2

Набор торцевых шестигранных ключей

Плоскогубцы и круглогубцы

Искатель скрытой проводки

Отвертка под шлиц: 1 /8″, 3/ 1 6″ и 5/ 1 6″

Набор звездообразных ключей Torx

Миниатюрные часовые отвертки

Миниатюрный пинцет · · · · · — ‘ ‘ . ‘ ‘ ..

..

.

.

.

Специальные компьютерные инструменты

Цифровой мультиметр ( DM M )

Кабельная стяжка (и их аналоги на » липучках»)

Инфракрасный термометр

Набор винтов для ремонта П К

Щипцы RJ-45

Портативный сетевой анализатор/ноутбук

Терминаторы SСSl -устройств

Запасные коммутационные шнуры RJ-45 катего­ рий 5 и 6А (как прямые, так и перекрещенные)

Запасной кабель питания

Запасные разъемы RJ-45 для обжима кабелей

Заземляющий браслет для статического электричества Клещи для снятия изоляции (со встроенным ин­ струментом для резки провода) Разное

Ватные палочки

Телескопический магнитный уловитель

Мобильный телефон

Комплект первой помощи , включающий ибупро­ фен и парацетамол

Изоляционная лента

Номера домашних и служебных телефонов со­ трудн иков

Баллон со сжатым воздухом

Список контактов для срочной связи в случае опасной ситуации •

Зеркальце дантиста

Шесть банок пива (как минимум )

•с номерами контрактов на обслуживание.

Часть lV. Эксплvатация

1 1 06

30.7. Л ИТЕРАТУРА •

AS H RA E l nc . ASHRA E 2008 Environmental Guidelines for Datacom Equipment. Atlanta, GA: AS H RAE, lnc. , 2008. Разнообразную полезную и нформацию и стандарты , связан н ые с энергоэффек­ тивностью, можно найти на веб-сайте Це нтра э кспертизы энергоэффе ктивно­ сти в це нтрах обработки дан ных (Center of Expe rtise for Energy Efficiency in Data Centers) по адресу d a t a c e n t e r s . l Ы . gov.

Telecommunications Jnfrastructure Standardfor Data Centers. AN S l/ТIA/ E IA 942 .

Глава

31

Метод ология, политика и стратегии

За последн ие четыре десятилетия рол ь и нформацион ных технологий в бизнесе и по­ вседневной жизн и резко измен илась. Трудно представить мир без м гновен ного удовлет­ ворен ия поиска в И нтернете . В те ч е н и е бол ьш е й части этого п е р и ода п р еоблада ю щ е й философие й I Т ­ м е неджме н та б ы л о повыш е н ие стабил ьности з а с ч е т м и н и м иза ц и и измен е н и й . В о м ногих случаях сотни или тысяч и пол ьзователе й зависел и о т одн о й систе м ы . Есл и происходил сбо й , оборудован ие часто должно было быть отправлено на ремонт, ил и требовалось врем я простоя для переустановки програ м много обеспечения и восста­ новл е н и я состоян и я . IТ- команды жил и в страхе , что что-то сломается и что он и не смогут это исправить. Стратегия м и н и м изаци и измен е н и й имеет н ежелатель н ы е п обочн ые эффе кты . 1 Т -отделы часто застревал и в п рошлом и н е соответствовал и потребностя м бизнеса. Накапли вался «технический долг» в виде систем и приложе н и й , отчаян но нуждающих­ ся в обновлении или замене , которых все боялись касаться , опасаясь что-то сломать. IТ­ сотрудники стали предметом шуток и наименее популярны м и л юдьми повсеместно от залов для заседаний советов директоров до праздн ичных вечеринок. К счастью, эти времена позади. Появл е н ие облачной и нфраструктур ы , виртуал и ­ зац и и , средств автоматизации и ш и рокополосной с в я з и знач ител ьно сократило п о ­ требность в одиноч н ых с исте мах. Такие серверы был и зам е н е н ы арм и я м и клонов, которые управл я ются как батал ьон ы . В свою очередь, эти технические фа кторы по­ звол или разработать философию обслужива н и я , известную как DevOps, которая по-

Часть lV. Эксплуатация

1 1 08

з вол яет I Т-орган и за ц и я м у п равлять изм е н е н и я м и , а н е сопрот и вляться и м . И мя DevOps — это слово- гибр ид , состоя щее из слов development (разработка) и operations (эксплуатация) , — назван ий двух традицион ных дисципл и н , которые оно объединяет. П-орган изация — это больше, чем груп па техн ических специал истов, которые на­ страи вают точ ки доступа к Wi — Fi и ком п ьютеры. Со стратегической точ ки зрения П­ подразделение — это группа л юдей и ролей, которые используют технологии для уско­ рен и я работы и достижения целей ком пании. Н икогда не забывайте о золотом правиле систе м ного адм и нистрирован ия : предприятиям нужно управлять П-деятел ьностью, а не наоборот. В этой главе мы обсудим нетехн и ческие ас пекты работы ус пешной П-орган изации , которая испол ьзует методологи ю DevOps в качестве с вое й всеобъемлющей схе м ы . Большинство тем и иде й , п редставл е н н ых в этой главе , н е являются спе цифически м и для какой -либо кон кретной среды. О н и применяются в равной сте п е н и к систе м ному адм и н истратору с частич ной занятостью ил и к бол ьшой груп п е п рофессионалов, ра­ ботающих пол н ы й рабоч и й де нь. П одоб но свежим овощам , они полезн ы , независ имо от того , насколько бол ьшой обед вы готовите .

3 1 . 1 . ВЕЛИКАЯ ЕДИ НАЯ ТЕОРИЯ : DEV0PS С истем ное администрирование и другие эксплуатацио н н ые роли в сфере 1 Т тради­ ционно отделя ются от таких областе й , как разработка приложе н и й и управление про­ ектами . Теория заключалась в том , что разработчи ки приложений были спе циал истами, которые продвигали продукты с новыми фун кциями и улучшениями . Тем временем ста­ бильная и устойч ивая к изменениям эксплуатацион ная группа обесп е чи вала непрерыв­ ное управление производствен ной средой. Такое соглаше ние обычно создает колоссал ь­ н ы й внутре н н и й конфл и кт и в конеч ном итоге не отвечает потребностя м бизнеса и его клиентов.

Рис. З 1. 1. С любезного разрешения Дэйва Рота (Dave Roth)

Глава 3 1 . Методология, политика и стратегии

1 1 09

П одход DevOps объединяет разработч и ков (програ м мистов , прикладных анал ити­ ков, владел ьцев приложе н и й , менеджеров проектов) с IТ- персоналом по эксплуатации (с исте м н ы м и и сете вы м и админ истраторам и . контролерами безопасности , персоналом дата- центра, адм ин истраторам и баз дан н ых). Эта философия базируется на убежде н и и , что совместная работа членов еди ной команды разрушает барьеры, умен ьшает частоту выяснения отношений и дает луч ш ие резул ьтаты . На рис. 3 1 . 2 приведены некотор ые из ос новн ых концепций DevOps.

DevOps — это не …

Человек

Окружение

DevOps — это …

Инструмент

Должность

Команда

Методология

Рис. 3 1 . 2. Что такое DevOps

DevOps — относител ьно новая кон це п ция в области управления I Т-организация м и . В начале 2000-х гг. произошл и изменения в области разработки, которая перешла о т ка­ с кадной схе м ы циклов выпус ков к гибким подходам , которые отл ичались итерати вной разработкой . Эта схема увел ичила скорость, с которой могл и быть создан ы продукт ы . фун кции и исправления, но развертыван ие этих улучшений часто останавл ивалос ь, по­ с кол ьку экспл уатацион ная сторона не была готова дви гаться та к быстро , как сторона разработки. Объеди нение разработч иков и эксплуатацион н ых групп позвол ило всем ра­ ботать в одном и том же темпе, и появилась методология DevOps.

DevOps

это CLAMS

П р и н ц и п ы м етодол о г и и DevOps н а и бол ее л е гко о п и с ы ваются аббре виатурой C LA M S : Culture ( Кул ьтура) , Lean ( Рационал ьность) , Automat ion (Автом атизация ) , M easurement ( И змерения) и Sharing (Совместная работа) .

Культура В конечном счете , ос новной движущей силой л юбой ус пеш ной ком анды я вля ются л юди, поэтому культурные аспекты DevOps являются сам ы м и важны м и . Хотя методоло­ гия DevOps имеет собстве н н ы й набор кул ьтурных советов и приемов, главная задача заставить всех работать вместе и сосредоточиться на общей цели. В м етодол о г и и DevOps все работают вм есте , чтобы поддержи вать об щ и й биз­ нес -драй вер ( продукт, цел ь, сообщество и т.д.) на всех этапах е го жизн е н ного цикла. Достиже н и е этой цел и может в кон ечном итоге потребовать изм е н е н и й в структуре отчетности (бол ьше нет изол ирован н ых груп п по разработке приложе н и й ) , штатного рас п исания и даже должностных обя занносте й. В наши дн и хорошие систе м н ые адм и-

Часть lV. Эксплуатация

1110

н истраторы иногда п ишут код (часто сценарии автоматизации или развертывания), а хо­ рошие разработчи ки приложений регулярно проверяют показатели п роизводител ьности и нфраструктуры и управляют ими. П еречисл и м некоторые типичные особенности культуры DevOps. •

И разработчики ( Dev) , и сотрудники отдела эксплуатации ( Ops) работают непре­ рывно (24/7) , одновременно ( «сообщения получают все «) и несут ответственность за всю среду. Это правило обладает прекрас н ы м побочн ы м эффектом , который со­ стоит в том , что причины неполадок могут быть устранены в любом месте , где бы он и не возникал и . 1 Н икакое приложе н ие или служба не могут запус каться без автоматического те­ стирован и я и мониторинга как на уровне систе м ы , так и на уровне приложений. Это правило ф и ксирует функциональность и создает контракт между Dev и Ops. Аналогично Dev и Ops должны заранее одобрять все запуски. Все производствен н ы е среды зеркально отражаются в одинаковых средах разра­ ботки . Это п равило создает основу для тестирования и уме ньшает количество про­ изводственных сбоев. Команды Dev регулярно проводят обзоры кода, на которые приглашаются член ы команды Ops. Архитектура и фун кциональность кода бол ьш е н е я вляются фун к­ ц ия м и команды Dev. Аналогично команда Ops проводит регулярн ые обзоры и н ­ фраструктуры , в которых участвуют члены команды Dev. О н и должны знать и вли­ ять на решения, касающиеся базовой инфраструктуры. Команды Dev и Ops проводят регулярные совместн ые совещания. В целом встре­ чи должны б ыть с ведены к м и н и муму, но совместные собрания служат полезным средством коммун и кации . Ч ле н ы команд Dev и Ops должн ы находиться в общем чате , посвя щенном об­ сужден и ю как стратегических (архитектура, направление, размер ) , так и эксплу­ атационных вопросов. Этот канал связи часто называют ChatOps, и для его под­ держки доступны несколько замечательных платформ, в частности H ipChat , Slack, MatterMost и Zulip.

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

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

‘ П р и мерно первые шесть н едел ь такая модел ь работы вызывает болез н е н н ые ощу е ия . З ате щ н м о н и внезапно п рекращаются , поверьте нам.

Глава 31 . Методология, политика и стратегии

1111

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

А втоматизация Автоматизация — это наиболее общепризнан н ы й аспект DevOps. Два золотых правила автоматизации гласят: •

есл и вам нужно выпол н ить задачу более двух раз, ее следует автоматизировать;

не автоматизируйте то, чего вы не пон и маете .

Автоматизация приносит много пре и муществ. •

• •

Она препятствует тому, чтобы сотрудники завязл и в рутин е . И нтеллектуал ьная мощь и творческий поте н циал персонала могут быть ис пользован ы для реше н ия новых и более сложных задач . Она снижает риск человеческих ош ибок. Она выражает и нфраструктуру в виде кода, позволяя отслежи вать верс и и и ре­ зультаты. Она способствует эвол ю ц и и , а также с н ижает риск. Есл и изменения потерпели неудачу, легко (ну, теоретически) выпол нить автоматический откат. Она облегчает испол ьзова н ие в иртуальных ил и облачных ресурсов для обес пече­ н и я масштабирован ия и избыточности . Нужно бол ьше ресурсов’? Добавьте нем но­ го. Н ужно меньше ресурсов? Удал ите л и шнее.

Важную роль в автоматизации играют и нструменты. Такие с исте м ы , как АпsiЬе , Salt , Puppet и Chef (с м . главу 23), — это передн и й край и центр. Инструменты непрерывной инте граци и , такие как Jenkins и ВаmЬоо (см . раздел 26. 3 ) , помогают управлять повторя ­ е м ы м и или запускаем ы м и задачам и. Н и зкоуровневые задач и и нфрастру ктуры автомати­ зируют утилиты для упаковки и выпуска, такие как Packer и Terraform. В зависимости от испол ьзуемой среды вам может понадобиться один из этих и нстру­ ме нтов, несколько ил и даже все . Новые инструменты и усовершенствования разрабаты­ ваются быстро, поэтому сосредоточьтесь на поиске инструмента, подходящего для кон ­ кретной фун кции ил и процесса, который вы автоматизируете , и н е пытайтесь сначала выбирать инструме нт, а затем выяснять проблем ы , которые он решает. П ереоце н и вать набор инструм ентов необходимо каждый год ил и два. Ваша стратегия автоматизации должна включать по крайней мере следующие элементы. •

Автоматическая настройка новых машин: это не просто установка операцион н о й с исте м ы . Она также в кл ючает в себя все дополн ительное програм м ное обеспече­ ние и локал ьную конфигурацию, необходим ые для запуска м а ш и н ы . Ваша ор1·а­ низация неизбежно будет поддерживать более одного типа конфигураци и , поэто­ му с самого начала включ ите в свои планы нес колько типов ком п ьютеров. Автоматическое управление конфиrурацией: изменения конфигурации должны в1ю­ диться в базу конфигурации и автоматически применяться ко всем м а ш инам од­ ного и того же типа. Это правило помогает поддержи вать целостность среды . Автоматическое продвижение кода. Распространен ие новых фун кций из среды раз­ работки в тестовую среду и из тестовой среды в производстве н н ую должно б ыть автоматизировано. Само тестирован ие должно быть автоматизировано, с четки м и критерия м и оце н ки и продвижен и я по службе.

Часть lV. Эксплvатация

1112 •

Систематическое исправление и обновление существующих маши н . Когда станет ясна п робл е м а с установкой и спол ьзуемой сред ы , вам н ужен стандарти зова н ­ н ы й и простой с пособ развертыван ия обновлен и й для всех затронутых маш и н . П оскол ьку серверы могут быть не в ключены постоя н но (даже есл и предполага ­ ется прот и воположное ) , при запуске обновл е н и я ваша схема внесе н и я измене­ н и й должна правильно обрабаты вать маш и н ы , которые находятся в в ы кл юч е н ­ ном состоя н и и .

В ы можете проверять обновления в о врем я загрузки ил и п о расписа н и ю ; допол н и ­ тел ьную и нформацию с м . в разделе 4.9.

Измерения Возможность м асштабирования виртуальной ил и облачной и нфраструктуры (см. гла­ ву 9) подтолкнула мир приборов и измерен и й к новым высотам. W Дополнительную информаци ю о мон иторинге см. в главе 2 8 . Сегодня ш н и й золотой стандарт — это сбор субсекундных измерен и й во всех службах (бизнес, приложения, базы данных, подсистемы, серверы , сеть и т.д.) . Эти усилия поддержи­ вают некоторые инструменты DevOps, такие как Graphite, Grafana, ELK (стек Elasticsearch + + Logstash + Кibana) , а также JUJатформы мониторинга, такие как lcinga и Zenoss. Однако и меть данн ы е измерен и й и делать что-то полезное — это две разные вещ и . Опытн ы й отдел DevOps гарантирует, что метрики из окружающей среды будут доступ­ ными и признавае м ы м и всем и заи нтересован н ы м и сторонами ( как внутри, так и за пре­ делами П-орган изации ) . DevOps устанавли вает ном инальные цели для каждой метрики и преследует л юбые аномал и и , чтобы определить их причину.

Совместная работа В основе успеха методологи и DevOps лежат совместная работа и совместное раз­ витие возможносте й . Персонал следует поощрять и сти м ул ировать дел иться с воей работой как в н утри орган и зац и и (с помощью презентаци й , лекций , материалов, по­ казател ьных в ыступл е н и й команд, учебных стате й в в и к и -систе м е и т.д. ) , так и вне ее (ис пол ьзуя се м и н ар ы , публ и каци и , конфере н ц и и ) . Эти мероприятия ус ил и вают взрывной эффект м етодологи и за предел а м и локал ьной рабочей груп п ы и помогают каждому уч иться и расти .

Сис те мное админис т рирование в ми ре DevOps Систе м н ые адми н и страторы всегда был и главн ы м и и уни версал ь н ы м и действую­ щим и л и ца м и в м ире п ; и это остается в силе под более ш ироким зонтиком DevOps. Систе м н ы й адми нистратор контрол ирует с исте м ы и инфраструктуру, как правило, при­ н и мая на себя основную ответствен ность за следующие области . • •

Создан ие, настройка, автоматизация и развертывание систем ной и нфраструктуры. Обеспечение безопасности, исправления и обновления эксJUJуатационной систе­ мы и основных подсистем. Развертыван ие, поддержка и внедрение технологий DevOps для непрерывной и н ­ те грации, непрерывного развертыван ия , мон иторинга, измере ния, контейнериза­ ции, виртуализации и и нсталляции JUJатформ ChatOps.

Глава 3 1 . методология, политика и стратегии

1113

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

Реагирование на пользовательские ресурсы ил и запросы на расшире н ие.

Устранение проблем с системами и и нфраструктурой по мере их возникновения.

Планирование будущего рас ш ирения систем , и нфраструктуры и возможностей .

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

• •

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

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

3 1 .2.

Системы УПРАВЛ ЕНИЯ БИЛЕТАМИ и ЗАДАЧАМИ

В ос нове каждой действующей П-групп ы лежит система управления билетам и и за­ дачам и . Как и для всех элементов методологии DevOps, наличие одной с истем ы бил е ­ тов , которая охватывает в с е IТ-дисципл и н ы , имеет решающее знач е н ие . В частности, запрос ы на улуч ше н и е , управление вы пус ком и отслеживан ие ошибок п рограм м н ого обеспечения должны быть частью одной и той же систе м ы . Хорошая билетная с истем а помогает сотруд н и ка м избегать двух н аиболее распро­ стране н н ых ловушек рабочего процесса: •

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

Общие функции билетн ых систем Билетная систем а принимает запросы через разл и ч н ые и нтерфейсы ( наиболее рас ­ простране н н ы м и я вл я ются электрон н ая почта и И нтернет) и отслеживают и х от по­ ступл е н и я до реш е н и я . М е н еджер ы могут н азначать билеты груп пам или отдельным сотруд н и кам . Сотрудники могут запра ш и вать с истему, чтобы увидеть очередь билетов, ожидающих выполнения. и , возможно, выполнить некоторы е из них. Пользователи м о­ гут узнавать состояние с воих запросов и выяснять, кто над н и м и работает. М е н еджер ы могут извлекать информацию высокого уровня , в ч астности:

Часть lV. Эксплуатация

1114 •

коли чество открытых билетов;

среднее время закрытия билета;

производител ьность сотрудников;

процент невыпол ненных билетов;

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

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

Владел е ц бил ета Работа может быть совместной, но, по нашему оп ыту, ответствен ность меньше под­ дается распредел е н и ю . У каждой задачи должен быть оди н , четко оп редел е н н ы й вла­ делец. Этот человек не долже н быть руководителе м или менеджеро м , а просто кем -то, желающим действовать в качестве координатора, — кем-то, кто хочет с казать: «Я беру на себя ответстве н ность за то, чтобы эта задача была решена» . Важн ы м побоч н ы м эфф е ктом этого подхода я вляется то, что благодаря е м у стано­ вится я с н ы м , кто и что реал изовал или кто и какие изменения внес . Эта прозрач ность очен ь важна, если вы хотите понять, почему что-то было сделано определ е н н ы м обра­ зом или почему что-то неожиданно работает по-другому или больше не работает. Если возни кают пробл емы , ответственного за задачу не следует приравн ивать к коз­ лу отпущен ия . Есл и ваша организация определяет ответственность как виновность, вы можете обнаружить, что кол ичество доступны х владельцев билетов быстро сократится . Ваша цель при назначении владельца б илета — просто устран ить двус мыслен ность в от­ ношен ии того, кто долже н решать каждую проблему. Н е наказывайте сотрудников за п росьбу о помощи. С точ к и зрен и я клиента , хорошая систе ма назначен и я — та, которая направляет пробл е м ы человеку, имеющему бол ьшой объем знани й и способному быстро и пол но­ стью решить эти проблем ы . Однако с управл е нческой точки зре н и я , зада н и я иногда должны быть сложн ы м и , чтобы сотрудники продолжали расти и учиться в процессе вы­ пол н е н ия с воей работы. Ва ша задача состоит в поиске такого баланса между сильны-

Глава 31 . Методология, политика и стратегии

1115

м и сторонам и сотрудн и ков и необходимостью решать сложные задачи , чтобы при этом были довольны и клиенты, и сотрудники. Большие задачи могут быть л юбы м и , вплоть до полномасштабных проектов разра­ ботки програ м м ного обеспеч е н и я . Эти задач и могут потребовать испол ьзования фор­ м ал ьных и нструментов упрамения проектами и разработки програ м много обеспечен ия. М ы не описы ваем эти инструменты здесь; тем не менее он и важ н ы и их н е следует упу­ с кать из виду. И ногда с исте м н ы е адм и н истраторы знают, что нужно вы пол нить определенн ую за­ дачу, но он и этого не делают, потому что задача им неприятна. Систе м н ы й адми н истра­ тор , которы й укажет на эту забытую, неназначе нную или н епопулярную задачу, с корее все го , и получит эту задачу как свое задан ие. Эта с итуация создает конфл и кт и нтере­ сов, потому что она побуЖДает с истемных адми н истраторов сохранять молчание в таких с итуациях. Н е допус кайте , чтобы это происходило в вашей организаци и ; дайте ваши м с исте м н ы м адми н истраторам возможность прояснить проблемы. В ы можете разреш ить им откры вать билеты , не назначая мадел ьца ил и не связы вая себя с проблемой , или мо­ жете создать псе вдоним адреса эле ктронной почты, по которому могут быть адресованы пробл е м ы .

Восприятие пол ьзователями билетн ых систем П олучение быстрого ответа от реал ьного человека ямяется критическим фактором , определяющим удометворен ность клиентов, даже есл и персонал ь н ы й ответ содержит не больше и нформац и и , чем автоматизирова н н ы й . В большинстве случаев гораздо важ­ нее сообщить зая вителю , что билет был просмотрен реальн ы м человеком , чем устранить проблему немедп е н но. Пол ьзователи понимают, что адм и н истраторы получают м н ого запросов , и он и готовы ждать вашего внимания настолько дол го, наскол ько они сочтут это с праведпивым и разумн ы м . Но они не хотят, чтобы их и гнорировал и . Механ изм , посредством которого пол ьзователи отпрамяют билеты, мияет на их вос­ приятие с истемы. Убедитесь, что вы понимаете культуру своей организации и предпочте­ н ия пользователей. Они хотят веб-интерфейс? П ользовательское приложение? Псевдоним адреса электронной почты? Может быть, они хотят звонить только по телефону! Также важно, чтобы адм и нистраторы нашл и время убедиться , что они правильно по­ н имают запросы пользователей. Этот момент кажется очевидн ы м , н о вспом н ите послед­ н ие пять раз, когда вы отпрамяли сообщен ие по электрон ной почте в службу поддерж­ ки клиентов или техн ической поддержки. Думае м , что было по крайней м ере несколько случаев , когда ответ, казалось, не и м ел н и какого отношен ия к вашему вопросу, — н е потому, что эти ком пан и и б ы л и особенно неком петентн ы , а потому, что подробно раз­ бирать проблем ы , указанные в бил ете , сложнее , чем кажется. Как тол ько вы проч итаете достаточ но бол ьшую ч асть билета, ч тобы понять, о ч е м спра ш и вает кл иент, остальная часть билета покажется вам пустыми словам и . Боритесь с этим ! Клиенты злятс я , когда узнают, что билет дошел до адресата, но запрос был не­ верно и стол кова н и е го н еобходимо повторн о отправить ил и перерегистрировать. Возникает зам кнуты й круг. Билеты часто расплывчаты ил и неточ н ы , потому что у зая в ителя нет технического оп ыта , необходимого дпя описания пробл е м ы , как это бьшо бы с систе м н ы м адми н и ­ стратором. Однако это не мешает пользователям делать собствен н ы е догадки о причи­ нах неполадок. И ногда эти догадки совершенно правил ьн ы , а и ногда вы должны снача­ ла рас ш ифровать билет, чтобы выяснить, что думает пользователь о проблеме, а затем проследить за ходом мысл и пользовател я , чтобы понять основную п роблему.

Часть lV. Эксплvатация

1116

Типовые билетн ые системы В следующих табли цах приведе н ы характеристи ки нескольких известн ых билетн ых ком ­ с исте м . В табл. 3 1 . 1 указаны систе м ы с открытым исходным кодом , а в табл. 3 1 . 2 мерческие системы. В табл. 3 1 . 2 показан ы некоторые комм ерческие ал ьтернативы для управления запро­ сами . Поскольку веб-сайты для коммерческих предложен и й в основном содержат мар­ кетин говую и нформацию, такие детали , как язык реализаци и и интерфейс, н е указа н ы . —

Таблица 3 1 . 1 . Билетные системы с открытым исходным кодом Имя

Ввод•

Язык

База данных6

DouЫe Choco Latte

w

РНР

МР

g i t hub . c om / g n u e d c l / dc l man t i s Ь t . o r g

Веб-сайт

Mantis

WE

РНР

м

OTRS

WE

Perl

DMOP

otrs . org

RT: Request Tracker

WE

Perl

м

b e s t p r a c t i c a l . c om

OSTicket

WE

РНР

м

o s t i c ke t . c om

Bugzilla

WE

Perl

МОР

b ug z i l l a . o r g

» Типы ввода: W — веб, Е — электронная почта. 0 Баэа дан ных: О — DB2, М — MySQL, О — Oracle, Р

PostgreSQL.

Таблица З 1 . 2. Коммерческие билетные системы Имя

Масштаб

Веб-сайт

ЕМС lonix ( l nfra)

Огромный

i n f r a c o r p . c om/ s o l u t i on s

Н ЕАТ

Средний

t i comix . c om

Jira

Л юбой

a t l a s s i a n . c om

Remedy (теперь ВМС)

Огромный

r e me d y . c om

ServiceDesk

Огромный

c a . com / u s / s e rvi c e — d e s k . a s p x

ServiceNow

Л юбой

s e r v i c e n ow . c om

Средний

t r a c k i t . com

Track-lt!

Некоторые коммерческие предложен ия настолько слож н ы , что для их эксплуатаци и , настрой к и и поддержания работоспособности нужн ы оди н или два специал ьн о н азна­ ченных сотрудника. Другие (такие как Jira и Service Now) доступн ы в виде » программно­ го обеспечения как услуги » .

Диспетчеризация билетов Во м ногих билетных системах, одна из которых ш ироко известна, нерешенной оста­ лась такая проблема: несколько сотрудни ков не могут эффективно разделять свое вни­ ман ие между задачами , над которы м и они работают прямо сейчас, и очередны м и за­ просам и , особен н о если запросы поступают по электронной почте в лич н ы й почтовый ящик. Мы экспериментировали с двумя решениями этой проблемы. Н а ш а первая поп ытка заключалась в том , чтобы назначить полов и ну гру п п ы с и ­ сте м н ых адми н истраторов дневной смены на обслуживан и е запросов. В о время смены дежур н ы й должен был попытаться ответить на как можно больше входящих запросов . Н едостаток этого подхода закл ючался в том , что н е все с исте м н ы е адм и н истраторы

Глава 3 1 . Методология, политика и стратегии

1117

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

3 1 . 3 . ПОДДЕРЖКА ЛОКАЛЬНОЙ ДОКУМЕНТАЦИИ Так же , как бол ь ш и нство л юде й пони м ают пользу для здоровья от физических упражнен и й и свежих овоще й , каждый ценит хорошую документацию , но и меет туман­ ное п редставл е н ие о том , насколько это важно. К сожал е н и ю , это не обязательно оз­ начает, что некто должен п исать или обновлять докуме нтац и ю просто так. Почему м ы должны об этом заботиться , правда? •

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

Локальная документация должна храниться в четко определенном м есте , таком как внутре н н яя вики-систем а ил и сторон н я я служба, такая как Google D rive. П осле того как вы убедите своих адм ин истраторов докуме нтировать конфигурации и м етоды адми­ н истрирова н и я , важно также защитить эту документацию. Злоумы шлен н и к может на-

Часть lV. Экс плуатация

1118

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

И нфраструктура ка к код Другая важная форма документации называется » и нфраструктура как код » . Она мо­ жет принимать различные фор м ы , но чаще всего рассматривается в виде определений конфи гурации (таких как модули Puppets ил и сценарии AnsiЫ e ) , которые затем могут храниться и отслеживаться в с истеме контроля версий, такой как Git. Система и ее из­ м е н е н ия хорошо докум ентирова н ы в файлах конфигурац и и , и среда может быть по­ строена и сопоставлена со стандартом на регулярной основе . Такой подход гарантиру­ ет, что документация и окружающая среда всегда соответствуют стандарту и актуальны , тем самы м решая наиболее распростран е н н ую проблему традиционной документации . Дополн ительную информацию см. в главе 2 3 .

Ста нда рты докум ента ци и Если в ы должн ы документировать элементы вручную, наш опыт показывает, что са­ м ы й простой и эффективны й способ веден ия документации — стандартизация на осно­ ве коротких и легких документах. В место написания руководства по управлению систе­ мой для ваш е й орга низации напишите м ного одностраничных документов, каждый из которых охватывает одну тему. Начните с большой картин ы , а затем разбивайте ее на куски, содержащие дополнитель­ ную информацию. Если вам нужно углубиться в подробности, напишите допол н ител ьный документ на одну страницу, в котором основное внимание будет уделено особенно сложным шагам. Такой подход и меет ряд преимуществ. •

• •

• •

Возможно, высшее руководство заинтересовано только в общей настрой ке вашей среды. Это все, что нужно, чтобы отвечать на вопросы сверху или вести управлен­ ческую дискуссию. Н е раскрывайте сли ш ком м ного деталей , иначе вы просто под­ толкнете с воего босса вмешаться в них. То же самое справедливо для кл иентов. Новый сотрудник или кто-то, кто прин имает новые обязанности в ваше й органи­ зации, нуждается в обзоре и нфраструктуры , чтобы стать продуктивн ы м . Нехорошо хорон ить таких людей под грудой информации . Эффективнее использовать нужный документ, чем просматривать большой. В ы можете и ндексировать страни ц ы ; чтобы их было легко найти . Ч е м мен ьш е врем е н и адми нистраторам приходится тратить на поиск и нформации, т е м л уч ш е . Л е гче поддерживать текущую документацию, когда в ы можете это сделать, обно­ вив только одн у страницу.

Этот последни й момент особенно важе н . П оддержание документации в актуальном состоян и и является огромной проблемой ; когда времени мало, документацие й жертву­ ют в первую очередь. Мы обнаружили , что несколько конкретных подходов позволя ют облегчить документирование.

Глава 31 . Методология, политика и стратегии

1119

Во-первых, укажите , что документаци я будет краткой актуальной и н еотшл иф о ­ ван ной. Переходите к самой сути. И нформация долж на быть эффективной. Н ичто так не отталкивает от докуме нтирова н и я , как перспект и ва написа н и я д иссертаци и по те­ ори и проектирования. Попросите сли ш ко м м ного до к у м е нта ци и , и вы , возможно, н е получите н ич е го. Расс мотрите возможность разраб отк и п ростой фор м ы или шабло­ н а для ваш и х с исте м н ых адм и нистраторов . Стандартная структур а помогает избежать » воды» и ориентирует систе м н ых адми нистраторов на изложение кон кретной и нфор м а ­ ц и и , а не общих рассужден и й . Во-вторых, внедряйте документацию в процессы . Ком м е нтарии в файлах конфигура­ ции я вляются одни м и из лучш их документов для всех. Они всегда уместны там , где они вам н ужны , и их сохранение практически н е требует вре м е н и . Бол ь ш и нство стандарт­ н ы х файлов конфигурации позволяют оставлять комментарии, и даже те , котор ы е н е особого хорошо прокомментирован ы , часто могут сл уж ит ь источн иком допол нительной и н формации. Л окально созда н н ы е и н струменты могут требовать документацию как часть ста н ­ дартной информации о конфигураци и . Например, и н стру мент которы й настра и вает но­ вый компьютер , может потребовать и нформацию о владельце ком п ьютера, его м естопо­ ложе н и и , состоян и и поддержки и ф инансовые данн ые даже если эти факты не имеют прямого отношения к конфигураци и программ ного обеспеч е н и я устройства. Документаци я не должна создавать избыточности и нфор м а ци и Например, если в ы поддержи ваете общи й список систем для всех ком п ьютеров, не должно быть другого места, где эта и нформация обновляется вручную. Дел а ть обновлен и я в нескольких ме­ стах — это н е только пустая трата времен и , но и выс ока я вероятность того, что со вре­ менем проявятся несоответствия . Если эта и нформация требуется в друтих контекстах и файлах конфигураци и , напишите сценарий , которы й получает ее от мастера конфигу­ рац и и или обновляет. Если вы не можете полностью устранить избыточность, по край­ ней мере должно быть понятно, какой источ н и к я вл я ется авторитет н ы м . Кроме того, нап и шите инструменты , чтобы уловить несоответствия , возможно, регулярно запуская их через план ировщи к cron. ,

,

,

.

m Дополн ительную и нформацию о план ировщи ке cron см. в разделе 4.9. П оя вление таких и нструментов, как вики , блоги и друтие просты е систе м ы управ­ ления знан и я м и , знач ительно облегчило отслеживание П-документаци и . Создайте хра­ н ил и ще , где все ваши документы могут быть найден ы и обновлены. Однако не забудьте сохран ить его ор ганизованность. Одна страница вики-с исте м ы с 200 дочерн ими стра­ н и цами в одном с писке сл и ш ком громоздкая и сложная в испол ьзовании. Не забудьте включ ить фун кцию поиска, чтобы получить максим альную отдачу от ваше й с и стем ы .

3 1 .4. РАЗДЕЛЕНИЕ ОКРУЖАЮЩЕЙ СРЕДЫ Организации , которые создают и разворач и вают собственное програ м м ное обеспе­ чен и е , н уждаются в отдельных средах разработки , тестирования и производства, чтобы вы пуски можно было передавать в общее пользован ие с помощью структурированно­ го п роцесса . 2 Отдельн ы е , но иде нтич н ы е ; убедитесь, что при обновлен и и с истем раз­ работки изме н е н и я распространя ются также на тест о в ы е и производствен н ы е среды . Разумеется , сами настройки конфигураци и должн ы подч и н яться тому же типу структу2 80 м ногих случ аях это утвержден ие относится та кже к ор га н изац и я м , в которых запущено готовое комплексное програ ммное обеспечение, та кое к а к ERP или фи нансовые с и сте м ы .

1 1 20

Часть lV. Эксплvатация

рированного управления выпус ко м , что и код. » Изменения конфигураци и » в кл ючают все: от исправления операцион н ы х систем до обновл е н и й приложе н и й и адми нистра­ тивных измен е н и й . Исторически сложилось так , что стандартная практика защищает производственную среду путем разделения ролей на п ротяжен и и всего процесса продвижен ия . Например, разработчи к и , обладающие права м и адм ин истратора в среде разработки , — это не те л юд и , у которых есть п р ив ил е ги и адми н истратора и продвиже н и я в других средах. Существовало опасение, что недовольный разработчик, имеющий разрешения на продви­ жен ие кода, мог бы вставлять вредоносный код на стадии разработки, а затем продвигать его в производствен ную среду. Если одобрение дистрибутива и продвижен ие осуществля­ ют разные л юди, им необходимо будет сговориться или одновременно сделать ошибки, чтобы проблемы могл и попасть в производственные с истемы. К сожале н и ю , ожидаем ы е выгоды от таких драконовских мер редко достигаются. У людей , продвигающих код, часто нет навыков или времени для пересмотра изменен и й кода на уровн е , которы й фактически выявил бы злонамеренный фрагмент. Вместо того чтобы помогать, с истема создает ложное чувство защиты , вводит ненужные контрольно­ пропускные пункты и тратит ресурсы . В эпоху методологии DevOps эта проблема решается по-другому. В место отдельных ролей п редпочтительным подходом я вляется отслеживан ие всех изме н е н и й » как кода» в репозитори и ( н апример, Git) , которы й и меет неизм е н я е м ы й контрол ьн ы й журнал . Л юбые н ежелательные изменения можно п роследить вплоть до конкретного человека, который их представил , поэтом у строгое разделение ролей не нужно. Поскол ьку изме­ нения конфигурации применяются автоматическим с пособом в каждой среде , идентич­ ные изменения могут быть выполнены в более н и зких средах (например, разработки или тестирования) до того, как о н и будут продвинуты в производство, чтобы гарантировать, что непредвиденные последствия не проявятся . Если проблемы обнаружен ы , возвраще­ н и е в исходное состоян и е происходит настолько же просто, как выявление проблемной фиксации и ее временный обход. В идеал ьном м ире ни разработчики, ни сотрудн ики отдела эксплуатации не должны иметь адми н истративных привилегий в производственной среде . Вместо этого все изме­ нения должн ы выпол няться с помощью автоматизирован ного отслеживаемого процес ­ са, которы й имеет собственные при вилегии . Несмотря на то что это достойная и весьма желанная цель, наш опыт заключается в том , что для большинства организаци й это еще не реал ьно. Работайте над этой утопической идеей , но не попадитесь в ловуш ку.

3 1 . 5 . ВоссТАНОВЛЕНИЕ ПОСЛЕ АВАРИ Й Работа о р га н и за ц и и зави с и т от фун к ц ио н и рован и я и нфор м а ц и о н н о й сред ы . Систе м н ы й адми нистратор отвечает не только з а повседневные операц и и , но и з а нали­ ч ие плана действи й на случай возникновения различных экстрен н ых ситуаци й , по край­ ней м ере тех, которые можно предв идеть. П одготовка к таким масштаб н ы м проблемам вл ияет как на общи й план работы, так и на с пособ выполнения повседневных операций. В этом разделе м ы рассмотр и м разные виды аварий, данные, которые н еобходимо вос­ становить, а также важные элементы планов по возобновлению работы.

Оцен ка рисков Прежде ч е м завершить разработку плана восстановления после авар и й , целесообраз­ но оценить степень риска , чтобы понять, каким и активам и вы располагаете, каким ри-

Глава 31 . Методология, политика и стратегии

1 1 21

с кам подвергаетесь и как можно смягчить последствия аварии. Специальн ы й документ N I ST 800-30 детал изирует обш ирный процесс оце н ки степени риска. Вы можете загру­ зить его с сайта n i s t . gov. В ходе оце н ки степени риска необходимо составить с писок поте н циальных угроз , от которых вы хотите защититься. Угрозы не я вляются оди наковы м и , и вам , возможно, понадобится нескол ько разл и ч н ы х планов, чтоб ы покрыть пол н ы й спектр возможно­ стей. В качестве примера перечислим угрозы общего характера. •

Злонамеренные пользователи , как внутре нние, так и внешн ие3

Наводнения

Пожары

Землетрясения

Ураган ы и торнадо

Магнитные бури и броски электроп итания

Перебои в эле ктропитан и и , короткие и долгосрочные

Чрезвычайно высокая тем пература или отказ охлаждающего оборудования

Сбой в работе телекоммун и кацион ного оборудован и я провайдера ил и облачной систе м ы

Отказы аппаратн ых средств ( » завис ш ие » серверы , «сгоревшие» жесткие диски)

Действия террористов

Зомби апокал и псис

Отказы сетевых устройств ( маршрутизаторов, коммутаторов, кабелей).

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

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

Планирова н ие мероприяти й по восстановлен ию Все больше орган изаций проектируют свои критические систе м ы так , чтоб ы мож­ но было автоматически перекл ючаться на резервные серверы в случае возни кновен ия пробл е м . Это пре крас ная иде я , есл и простои в работе служб не допус каются . Те м не менее не становитесь жертвой веры в то , что зеркал ирование ваш и х дан н ых отме няет н еобходи мость в их резервном копирова н и и . Даже есл и ваш и центры обработки дан —

1 П ри ч иной около полов и н ы наруше н и й в области безопасности я вляются действия внутрен н и х п ол ьзователей . В больш и н стве организаци й неправильные действия внутре н н и х пол ьзователей остаются наиболее вероятны м и причинами сбоев.

Часть lV. Эксплvатация

1 1 22

н ы х расположе н ы достаточ но далеко, вы впол н е м ожете потерять в н и х все дан н ы е . 4 J-l e забудьте вкл юч ить резервное коп ирован ие дан ных в с в о й план по борьбе с аварий­ ными с итуация м и . m Облач ные выч исления описаны в главе 9 . Облачн ы е выч ислен и я — еще оди н ресурс мя борьбы с о стихи й н ы м и бедствия м и , которы й становится все более популяр н ы м . Благодаря таки м службам , как ЕС2 компа­ н и и Amazon, вы можете настроить удален н ы й сайт и запустить его за несколько м инут без н еобходимости платить за специализирова н н ы е аппаратн ые средства. Вы платите только за то , что используете . В план по восстановлен ию после аварийных ситуаций должн ы быть вкл юче н ы пере­ ч ислен ные н иже разделы (составлено на основе стандарта авари й ного восстановления N I ST 800- 34) . • •

Введение — цель и предмет документа. Понятие операций — описание систе м ы , цели восстановления, классификация и н ­ формац и и , порядок преемственности, обязанности . Уведомление и активация н и й , активация плана.

процедуры уведомления, процедуры оцен ки поврежде ­

Восстановление последовательность событий и процедур, требуе м ых для восста­ новления работоспособности потерян н ых систе м . —

Возврат к нормальному функционированию — параллел ьная обработка, тестирова­ ние восстановленной системы, возвращение к нормальному функционированию, отмена введен ного авар и й ного плана.

Мы п р и в ы кл и испол ьзовать сеть для общен и я и доступа к документам . Однако эти средства м огут стать н едоступн ы м и или оказаться под угрозой после и н цидента. Поэтому сохраняйте локально все соответствующие контакты и процедуры . Вы должны знать, где можно получить свежие резервные копи и своих данных и как использовать их независ имо от сетевых дан ных. Во всех сценариях восстановлен ия вам понадобится доступ и к автономн ы м , и к ин­ терактив н ы м коп и я м важн ых данн ых. И нтерактивные коп и и по возможности должны быть сохранен ы на отдельном компьютере , на котором есть богаты й набор инструмен­ тов , настроен ная ключевая среда мя с истемного адм и н истрирова н и я , запущен соб­ стве н н ы й сервер и м е н , пол н ы й локал ьн ы й файл /etc/hosts, подключение к принтеру и нет н и каких зависимостей от ресурсов , расположен н ых на других ком пьютерах. Н иже приведен список полезных данн ых мя хране н ия в среде восстановл е н ия при аварийных с итуациях. •

Схема процедуры восстановления: кому звонить, что сказать

Номера телефонов сервисного центра и кл иентов

Ключевые местные номера телефонов: полиция, пожарные, сотрудники, начальник

И нформация мя входа в облачн ы й сервис

Н абор резервных коп и й дан ных и график их создания

Карты сети

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

Глава 31 . методология , политика и стратегии

Регистрацион н ы е номера п ро гра м м ного обеспече н и я , л и ц е н зион н ы е дан н ы е и пароли Коп и и и нсталл яцион ных пакетов п рограмм ного обес печен и я ( могут хран иться в формате I SO) Копии инструкций по эксплуатации ваш их с исте м

Контактная и нформация поставщика оборудования

Адм ин истративные пароли

1 1 23

Данн ые о конфиrурациях аппаратного и программного обеспечен и я : версии опе­ рационных систе м , пакеты обновлен и й , таблицы разделов дисков и т. п . И нструкции о порядке запус ка систе м , работоспособность которых должна быть восстановлена в первую очередь

П одбор персонала на случа й аварии Н ужно заблаговре м е н н о решить вопрос о том , кто будет с правляться с ситуацией в случае , если произойдет авария. Следует составить план действий и зап исать номера телефонов тех, кому надлежит звонить в такой с итуации. Мы пользуе мся н ебольшой ла­ м и н ированной карточкой, на которой мелким ш рифтом напечата н ы все важные имена и номера телефонов: она оче н ь удобна, потому что легко помещается в бумажн ик. Л уч ше всего назначать ответствен н ы м одного из с исте м н ых адми н истраторов, а не IТ-руководителя (обычно он плохо подходит дл я этой роли). Ответстве н н ы м в случае а варии должен быть кто-то, кто пользуется а вторитетом и не боится при н и мать трудные решения при нал и ч и и м и н и мального количества и н ­ формации ( н аподобие ре ш е н и я откл юч ить о т сети весь отдел цел и ко м ) . Способность принимать такие решения , уведомлять о них понятн ы м образом и фактически руково­ дить персоналом во время кризиса, пожалуй, важнее теоретических знаний о системном и сетевом управлении. При составлении плана аварийных м ероприятий обычно предполагается , что адми ­ н истративный персонал будет на месте , когда произойдет авария , и сумеет справиться с с итуацией. К сожален и ю , л юди и ногда болеют, уходят на курсы пов ы ш е н ия к вал и ­ фикации, уезжают в отпуск, а в тяжелые времена вообще могут даже становиться край­ не н едружелюбн ы м и . П оэтому стоит заранее продумать, где можно будет быстро найти допол н ительную помощь. ( Если система н е сл и ш ком устойч и ва , а персонал неопыте н , то недостаточное количество адми н истраторов уже само п о себе я вляется аварийной си­ туацией . ) Одн им и з решений может быть договорен н ость с какой- н ибудь местной консул ьта­ цион ной компанией или университетом , где всегда есть талантл ивые и готовые помочь адм и нистраторы . Конечно, есл и у них когда-нибудь возн икнут пробл е м ы , тогда вы тоже должн ы будете оказать им необходимую помощь. Но самое главное — это не работать на пределе : найм ите достаточн ое кол ичество адм и нистраторов и не требуйте , чтобы он и работал и по 1 2 часов в сутки .

П роблемы с безопасностью Об обес п е ч е н и и безопас н ости систе м ы п одроб н о расс казы валось в гл аве 2 7 . Однако здесь тоже стоит коснуться этой тем ы , потому что вопросы безопас ности вл и —

1 1 24

Часть lV. Эксплvатация

я ют на м ногие из в ы пол н я е м ых систе м н ы м адм и н и стратором задач . Н и оди н ас пект стратегии управления орга низации не должен разрабатываться без учета безопасности . В главе 27 по боль шей части рассказы валось о способах предотвращения пробл е м с безопасностью. Однако продум ыван ие с пособов восстановле н ия с исте м ы после про­ и с ш едшего из-за связа н н ых с безопасностью пробл е м и н циде нта я вл я ется не м е н е е важн ы м . Взлом веб-сайта относится к ч ислу наиболее серьезных нарушений систе м ы безопас ­ ности. Для с истем ного адм и н истратора , работающего в ком пан и и , которая занимается предоставлением услуг веб-хостин га, такой и нцидент может превратиться в н астоящую катастрофу, особен н о есл и речь идет о сайтах, и спол ьзующих дан н ы е о пластиковых картах пользователей. При этом будет поступать лавина телефон н ых звонков от кл и е н ­ тов , средств массовой и н формаци и , УI Р- кл ие нтов ком пан и и , которые тол ько что ус ­ л ышал и о произошедше м взломе в новостях. Кто будет отвечать на эти звонки? Ч то он должен говорить’? Кто будет глав н ы м ‘? Кто что будет делать? Тем систе м н ы м админ и ­ страторам , которые работают в оче н ь популярных компаниях, обязательно следует про­ думать такой сценарий, подготов ить подходящие ответы и план действ и й и, возможно, даже провести тренировочную проверку, чтобы отработать детал и . Для сайтов , которые и м е ют дело с данн ы м и о платежных картах, всегда предусма­ триваются п равила поведен ия в случае взлома с целью кражи и нформ ац и и . Поэтому систе м н ый администратор обязательно должен привлечь к планирован и ю м ероприятий на случай проблем с безопасностью сотрудников юридического отдела с воей организа­ ции и позаботиться о нал и чи и номеров телефонов и имен л юде й , которы м следует зво­ н ить во время кризиса. Когда в новостях объявля ют, что такой-то веб-сайт был атакован хакерами , возни ка­ ет ситуация, напоминающая авари ю на дороге : все бросаются пос м отреть, что же про­ изошло, и в результате и нтернет-трафик сильно возрастает, н ередко настолько сильно, что все , что адм и н истраторам наконец-то с таки м трудом удалось восстановить, сно­ ва может оказаться под угрозой. П оэтому, есл и веб-сайт н е рассчитан на 2 5 -процент­ ное (или более высокое) п и ковое увеличение трафика, следует позаботиться о наличии устройств вырав н и ва н и я нагрузки, которые будут просто направл ять превышающие норму запросы на специал ьн ы й сервер, а тот будет возвращать стран ицу со следующим сообщением: » И зв и н ите, сервер сли ш ком загружен и поэтому в дан н ы й момент н е мо­ жет обработать ваш запрос » . Разумеется , хорошо продуманн ы й заранее план по возоб­ новл е н и ю работы , в кл ючающий автоматическое масштабирование в облаке (см. главу 9), позволит избежать такой ситуаци и . Разработайте подробное руководство по действия м в чрезвычайных с итуациях, чтобы исключить непродуктивную работу при устранении проблем с безопасностью. Более под­ робно об этом шла речь в разделе 27 . 1 2.

3 1 .6. И НСТРУКЦИИ И ПРОЦЕДУРЫ И счерпывающие инструкции и процедуры, касающиеся информационных техноло­ гий , служат основой для работы современных орган изаци й . И нструкции устанавли вают нормы для пользователе й и администраторов и способствуют согласован ной работе всех вовлече н н ых в нее сотрудни ков. Все чаще инструкции требуют подтвержден и я в форме подписи или другого доказательства, что пользовател ь согл асился их собл юдать. Хотя это может показаться чрезмерн ы м формализмом , такое подтверждение представляет со­ бой действительно отл и ч н ы й с пособ защитить адм и н истраторов.

Глава 31 . методология, политика и стратегии

1 1 25

Хоро ш и м ос н о ва н и е м дл я разработк и и нструк ц и й я вл я ется стандарт I SO/I EC 2700 1 : 20 1 3 . Он сочетает общую стратегию в области и нформацион ных технологий с дру­ ги м и важн ы м и элеме нтами , такими как и нформационная безопасн ость и рол ь отдела кадров. В следующих разделах мы обсудим стандарт J SO/I EC 2700 1 : 20 1 3 и выдви н е м на первый план не которые из е го самых важных и полезных элеме нтов.

Р азл ич ие между инструкциями и п роцедурами И н струкции и процедуры — это разные категори и , н о их часто путают, и и ногда они даже испол ьзуются как с и нон и м ы , что вызывает п ута н и цу. Для того чтобы п равильно пон имать их сущность, расс мотрим следующие аспекты. •

И н струкц и и — это документы , устан а вл ивающие требова н и я ил и правила. Требова н ия обычно определя ются на относител ьно высоком уровне. П р и мером инструкции можно сч итать требова н и е , чтобы и н кре ментные резервные ко п и и создавались ежедневно, а полные резервные копировании — каждую неделю. П роцедуры — это документы, описывающие п роцесс в ы пол н е н и я требова н и й ил и правил . Например, процедура, связанная с о п исан ной в ы ш е инструкци е й , могла бы быть сформул ирована примерно так: » Ин крементн ые резервные копи и выпол н я ются с помощью программы Backup Ехес , инсталл ированной н а сервере backups O l » . «

Это разл и ч и е важно, потому что инструкции н е должн ы измен яться оч е н ь часто. О н и могут пересматри ваться ежегодно и, возможно, в н и х поменяется оди н или два раз­ дела. С другой сторо н ы , процедуры уточ няются не прерывно, поскол ьку постоян н о из­ меняется архитектура, систе м ы и конфи гурации . Н екоторые стратегические решения ди ктуются програм м н ы м обеспечением, которое вы испол ьзуете , ил и инструкция м и вне ш н их груп п , например и нтер нет- провайдерами. Есл и н еобходимо защитить конфиден циал ьн ы е дан н ы е пол ьзователе й , некоторые и н ­ струкции составля ются в категорич ной форме. М ы называем эти инструкции » не под­ лежащими обсужде н и ю » . В частности , м ы полагае м , ч то I Р-адресам и , и м е н а м и хостов, идентифи каторам и пол ьзовател е й , иде нтификатора м и груп п и именами пол ьзователе й н еобходимо управ­ лять централ изова н но. Некоторые организации (транснационал ь н ы е корпорации , на­ пример) являются сли ш ком больши м и , чтобы осуществить эту политику, но есл и вы мо­ жете реал изовать ее, то централ изован ное управл е н ие сделает все намного проще. М ы знаем ком панию, которая реализует политику це нтрализованного управлен и я для 35 ты­ сяч пользователей и 1 00 тысяч ком пьютеров. Таким образо м , порог, после которого ор­ ган изация становится сли ш ком круп ной для це нтрал изован ного управл е н и я , долже н быть довол ьно высоким . Другие важные проблемы имеют более ш ирокую сферу вл и я н и я , ч е м ваша локал ьная группа систе м н ых адм и нистраторов. •

Борьба со взломами с исте м ы безопасности

Управление экспортом файловой системы

Критерии выбора паролей

Удаление регистрацион ных зап исей

Материал , защище н н ы й авторским правом (например, М Р3 и DVD)

П рограмм ное пиратство

Часть lV. Эксплvатация

1 1 26

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

Информационная политика безопасности

Соглашения о возможности подкл ючен и я посторо н н их организаций

Пол итика управления активам и

И н формационная система классификации данных

Пол итика безопасности сотрудни ков

Физическая политика безопасности

Пол итика управления доступом

Стандарты безопасности для разработки и обслуживания новых с истем

Пол итика управления и нцидентами

Управл е н ие непрерывностью бизнеса (авар и йное восстановление)

Стандарты хране н ия данн ых

Защита конфиден циальности

Политика соответствия установленным требованиям закона

П роцедуры П роцедуры в форме контрольн ых списков или рецептов могут формализовать суще­ ствующую практику. О н и полезны и для новых системных администраторов, и для опыт­ ных л юдей. Еще лучше п роцедуры, которые содержат выполняемые сценарии или отра­ жаются в и нструментах упрамен ия конфигурацие й , таких как AnsiЬe, Puppet или Chef. В долгосрочной перспективе большинство процедур должны быть автоматизированы. У стандартных процедур есть несколько пре и муществ. •

Рутин н ые операции всегда выполняются единообразно

Контрольные списки уменьшают вероятность ошибок или забытых операци й

По рецепту систе м н ый адми нистратор работает быстрее

Изменения самодокументируются

П исьмен н ые процедуры обеспечи вают измер и мый стандарт корректности

Вот часть общих задач , для которых можно сформ ул ировать процедуры . •

Подключен ие компьютера

Добамение пользователя

Конфигурирован ие локального ком пьютера

Настройка процедур резервного копирования для нового ком п ьютера

Защита нового ком пьютера

Удаление старого ком пьютера

Повторн ы й запуск сложных ком понентов программ ного обеспечен и я

Глава 31 . Методология, политика и стратегии

Перезагрузка веб-серверов, которые не отвечают на запросы ил и » зависли «

Обновлен ие операционной систе м ы

Установка исправлений

Установка пакета прикладных программ

Обновление наиболее важн ых программ

Резервное коп ирование и восстановление файлов

1 1 27

Удаление старых резервн ых копи й

Аварийный останов системы ( всех ком пьютеров ; кроме самых важных; и т.д. )

М но г и е вопросы н а ходя тс я в н е п осредстве н но й с в я з и пол и т и к и п роцеду р . Например: •

Кто из сотрудников может иметь учетную запись в вашей сети?

Что происходит, когда они увольня ются’?

Такие вопросы следует строго регламентировать, чтобы не стать жертвой известной уловки четырехлетн их детей : » Мама не разре шила, надо спросить у пап ы ! «

3 1 .7. (ОГЛАШЕНИЯ О КАЧЕСТВЕ ОКАЗЫВАЕМЫХ УСЛУГ Для того чтобы отдел информацион ных технологий ус пешно с правлялся со сво и м и обязанностя м и , стараясь угождать пользователя м и удовлетворяя потребности предпри­ ятия , все детал и необходимо согласовать и зафиксировать в договоре о качестве оказы ва­ е м ых услуг. Хороший договор предусматри вает соответствующи й урове н ь обслуживан ия и я вляется докуме нтом , на который можно ссылаться в проблемных с итуациях. ( Однако пом н ите, что отдел информационных технологий помогает, а не мешает пол ьзователям!) Когда что-то выходит из строя , пол ьзователи хотят знать, когда это будет исправле­ но. И х не и нтересует, какой жесткий диск или ген ератор сломал ись и почему; оставьте эту и нформацию для с воих админ истративных отчетов. С точ к и зре н и я пол ьзователя , н и какие новости не я вл я ются хорош и м и . С исте ма ил и работает, или нет, и в последнем случае н е имеет знач е н ия , почему. Макс имал ьное удовольствие наш и кл ие нты получают, есл и они даже не замечают, что мы сушествуем! Грустно, но факт. Соглашен ие о качестве оказывае м ых услуг помогает пом ирить конечных пол ьзовате ­ лей и техн ический персонал . Хорошо написан ное соглашение учитывает каждую проб­ лему, упомянутую в следующих разделах.

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

Электрон ная почта

Чаты

И нтернет и неб-доступ

Файловые серверы

Часть lV. Эксплvатация

1 1 28 •

Бизнес-приложения

Аутентификация

В договоре также должн ы быть определены стандарты, которых будет придерживать­ ся отдел информацион н ых технологий . Например, раздел о доступности услуг должен определять часы работы , согласованные окна обслуживания и время , в течение которо­ го будет доступен техн ический персонал , чтобы обеспеч ить интерактивную поддержку. Одна организация м огла бы реш ить, что регулярная поддержка должна быть доступна с 8 :00 до 1 8 : 00 в будн ие дн и , а чрезвычайная поддержка — круглосуточно. Другая орга­ н изация могла бы реш ить, что нуждается в стандартной интерактивной поддержке , до­ ступной всегда. П редставим список проблем , которые следует рассмотреть, документируя ваш и стан дарты. •

Вре мя откл и ка

Обслуживание (и вре мя откл и ка) в течение выходных и неуроч ных часов

П осеще ния на дому (поддержка для домаш них ком пьютеров)

Специальное (ун и кал ьное или патентован ное) аппаратное обес печение

П ол итика модернизации (устаревшие аппаратные средства, програм мное обеспечение и т.д. )

Поддерживаемые операционные системы

Поддерживаемые облачные платформы

Стандартн ые конфигурации

Хран е н ие дан н ых

П рограм м ное обеспечение специал ьного назначения

Рассматри вая стандарты услуг, имейте в виду, что м ногие пользовател и захотят само­ стоятельно настроить с вою среду (или даже с вои с исте м ы ) , есл и не будет установлено программное обеспечение, чтобы это предотвратить. Стереотипный ответ на эти попыт­ ки — запретить всем пол ьзователя м осуществлять любые модификации. Это упрощает работу отдела и н формацион ных технологи й , но не всегда я вляется лучшей стратегией для все й орган изации. Укажите эту проблему в своем соглашении о качестве оказываемых услуг и попытай­ тесь стандартизировать ее решение на нескольких определенных конфигурациях. И наче ваше стремление к облегчению обслуживания и быстрому росту в рамках всей организа­ ции встретят серьезные препятствия . Поощря йте с воих творческих сотрудников предла­ гать модификации, в которых они нуждаются, и будьте заботливы и щедры, учиты вая их предложен и я в своих стандартных конфигурациях. Если вы не сделаете этого, то ваш и пол ьзователи будут упорно нарушать ваш и правила.

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

Глава 3 1 . Методология, политика и стратегии

Важность услуги мя всей орган изаци и

Влияние на безопасность (было л и нарушение правил безопасн ости? )

Оплаче н н ы й или оговорен н ы й урове н ь сервисного обслуживания

Количество задействова н н ых пользователей

Важность л юбого релевантного крайнего срока

С кандальность задействованных пользователей ( «скрипучие колеса» )

1 1 29

Важность задействова н н ых пол ьзователе й (это дело тон кое , н о буде м честн ы м и : у некоторых л юдей в вашей организации есть больше авторитета, ч е м у других).

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

М ного л юдей не могут работать успешно

Оди н человек не может работать успешно

Запрос ы на усовершенствования

Если два или больше запросов имеют высший п риоритет и они не могут выпол нять­ ся параллел ьно, мы делаем выбор, основы ваяс ь на серьезности проблемы (например, неработающая электрон ная почта доставляет неудобства почти все м , тогда как времен ­ ное отсутствие неб-службы могло бы помешать только нескольким л юдя м ) . Очереди с более низкими приоритетами обыч но обрабаты ваются по принципу F I FO .

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

П роцент или количество проектов, законче н н ых воврем я и в пределах бюджета Процент или количество выпол н е н н ых пун ктов соглашения о качестве оказывае­ мых услуг П роцент продолжител ьности работы с исте м ы ( например, электрон ная почта доступ на через службу Q в теч е н ие 99,92% времени)

П роцент или ч исло билетов, проблема которых бьmа удометворительно решена

Среднее время решения проблемы, описанной в билете

Проце нт или кол ичество нарушений системы безопасности , обработа н н ых соглас­ но устаноменной процедуре

3 1 .8. СООТВЕТСТВИЕ ЗАКОНАМ И СТАНДАРТАМ П-аудит и управление в настоящее врем я являются очень популярными. И нструкции и квазистандарты мя спе цификации , проведен ия измере н и й и сертификации соответ­ ствия законам породили множество аббревиатур: SOX, IТI L, С О В П и I SO 2700 1 , и это

Часть lV. Экспл уатация

1 1 30

только часть из н их. К сожалению, эта смесь букв оставляет у систе м н ых адми н истрато­ ров неприятн ы й осадок, поэтому сейчас ощущается недостаток програм м ного обес пече­ н и я , п редназначенного дnя реал изации всех средств управле н ия , необходимых дnя обе­ спечения соответствия с де йстоующим законодательством. Н е которые из ос новных рекомендател ьных стандартов , руководя щих при н ципов, пром ышленных кон цепци й и законодательных требова н и й , которые могут касаться си­ сте м н ых адми н истраторов, переч ислен ы н иже. Законодательные требования я вля ются в знач ительной степени специфи ч н ы м и дnя Соединен н ых Штатов Америки. Обычно стандарты определяются типом организации или обрабатываемых дан н ых. Организаци и , находя щиеся вне юрисдикции С ША, должн ы сами выясн ить, какие регу­ ляторные правила распространяются на них. •

CJI S ( И нформационные системы уголовного судопроизводства) -стандарт, отно­ с я щ и йся к организа ци я м , которые отслежи вают кр и м и н ал ьную и нформацию и пол ьзуются базами дан н ых Ф Б Р. Его требования могут быть найден ы на стран и ­ ц е f Ь i . g ov / hq / c j i s d / c j i s . htm. COBIT — рекомендации дnя информацион ного управления, основа н ного на пе­ редовом п ро м ы шл е н н о м опыте . Они разработан ы совместно Ассоциаци е й ау­ дита и управл е н и я и н формацион н ы м и систе м а м и ( Systems Audit and Control Asso c i a t i o n — I SACA) и И н ститутом и н фо р м а ц и о н н о го у п р а вл е н и я ( I Т Governance l nstutute — ПG I ) ; с м . детал и на сайте i s a c a . o r g . Задача рекоме н ­ даций CO B IT состоит о том , чтобы » исследовать, разви вать, предавать гласности и продвигать авторитетн ы й , современ н ы й , международный набор общепринятых целей уnравления информацион н ы м и технология м и дnя ежедне вного использова­ ния менеджерами и аудиторам и . «

Первая редакция этих ре коме ндаци й бьша выпущена в 1 996 году, се йчас действует версия 5 . 0 , издан ная в 20 1 2 году. П оследняя версия разрабаты валас ь под с ил ьн ы м влиянием требований закона Сарбейнза-Оксли (Sarbanes-Oxley). О н а включает 3 7 целей высокого уровня , которые разделены на пять категори й : согласование, пла­ нирование и организация (Align , Plan, and Organize — АРО), создание, приобрете ­ н ие и реал изация ( Bu i l d , Acquire , and l mplement — BAI ) , поставка, обслуживание и поддержка ( Deliver, Service , and Support — DSS) , мон итор и н г, оценка и доступ ( Monitor, Evaluate, and Access — М ЕА) , а также оценка, управление и мон иторинг ( Eval uate Direct , and Monitor — E D M ) . ,

СОРРА (Chldren’s Onllne Prlvacy Protection Act — Закон о защите конфиде н циаль­ ной информации о детях в Интернете); регул ирует работу организац и й , которые собирают ил и хранят и нформацию о детях, не достигших 1 3 лет. Для сбора опре­ деленной информаци и необходимо разреш е н и е родителе й ; с м . детал и на сайте f t c . g ov. Rlghts and Privacy Act Закон о правах се мьи на образо­ вание и неприкосновен ность частной жизни); относ ится ко всем учрежде н и я м , яв­ ляющимся получател я м и федерал ьной помощи , которой уnравляет м и н истерство образован и я . Этот закон защищает и нформацию о студентах и предоставляет сту­ дентам определ е н н ые п рава относительно их дан ных; см. детали на сайте e d . g ov. FERPA (Family Educatlonal

FI S МA ( Federal Information Security Management Act — Закон об управл е н и и ин­ формационной безопасностью в федерал ьном правительстве); относится ко всем правительствен н ы м учрежде н ия м и подрядчи кам правительстве н н ых учрежден и й . Это бол ьшой и довол ьно неопредел е н н ы й набор требовани й , которые нацелены

Глава 31 . Методология, политика и стратегии

1 1 31

на согласование со множеством публ и каций об информационной безопасн ости , выпуще н н ых и нститутом N I ST, Национал ь н ы м и н ститутом по стандартизации и технологии ( N ational l nstitute of Standards and Technology) . Н езависимо от того, подпадает ваш а организация под мандат F I S МA ил и нет, документы N I ST заслу­ живают внимания; см. n i s t . g ov. •

Концепция Safe HarЬor (правило безо пасной rаванн) Федеральной комисси и по тор­ rовле США (FfC) представляет собой мост между подходам и С Ш А и Европейского Союза к законодательству, защищающе му частную жизнь, и о пределяет способ, с помощью которого американские организации могут взаимодействовать с ев­ ропейскими ком пания м и , чтобы продемонстрировать защиту своей и н формации ; cм. export . g ov / s a f e h a r b o r . Закон Jрэмма-Л ича-Блайли (Gramm-Leach-Bliley Act — GLBA) регули рует исполь­ зова н и е фи нансовы м и учрежде н и я м и конфиден ц иал ьной и нформации потре­ бителей. Если вы задавались вопросом , почему бан к и , выпускающие платежные карты , брокеры и страховщики забрасы вали вас уведомл е н и я м и о конфиде нци­ ал ьности , то это следствие закона Грэм ма-Л ича-Блайл и ; см. детали на сайте f t c . g o v . В н астоя щее вре мя самая пол ная и нформация по закону Грэм ма-Л ича­ Блайл и находится в разделе Тips & Advice этого сайта. В качестве глубокой ссылки можно использовать сокращение g o o . g 1 /vv2 О 1 1 . Закон H I PAA (Health lnsurance PortaЬility and AccountaЬility Act — Закон об отчет­ ности и безопасности медицинского страхования) относится к организациям , ко­ торые передают или хранят защищен ную медицинскую и нформацию ( иначе Р Н I ) . Это ш ирок и й стандарт, которы й был первоначально предназначен дл я борьбы с растратами , мошенн ичеством и злоупотреблениями в области здравоохранения и медицинского страхования, но теперь он испол ьзуется для того , чтобы измерить качество и улучш ить безопасность и нформации о здоровье ; с м . h h s . g ov / o c r / p r iv a c y / index . html . ISO 2700 1 :20 1 3 и I S O 27002:20 1 3 это рекомендательная ( и и н формативная) колле кция п ередового опыта, связанного с безопасностью органи заций , использу­ ющих информационные технологии ; см. i s o . o r g . —

C I P (Critical Infrastructure Protection) семейство стандартов, разработанных кор­ порацией North American Electric Reliabllity Corporation ( N E RC) , которые способ­ ствуют защите и нфраструктурных с истем , таких как электроснабжение, телефон ­ ные л и н и и и фи нансовые сети , от стихийных бедстви й и терроризма. В полном соответстви и с учебной илл юстрацией н ицшеанского понятия «жажды власти» оказывается , что большая часть экономики попадает в оди н и з 1 7 секторов » кри­ тических инфраструктур и кл ючевых ресурсов» (C l/KR) и поэтому очень нужда­ ется в стандартах C I P. Организаци и , попадающие в эти сектора , должн ы оценить с вои с истемы и защи щать их соответствующим образо м ; с м . n e r c . с от. —

Стандарт PCI DSS ( Payment Card lndustry data Security Standard — Стандарт за­ щиты и нформации в индустри и платежных карт) был создан консорциумом пла­ теж н ых брендов, вкл ючая American Express, D iscover, M asterCard , J C B и Visa. Он охватывает вопросы управления дан н ы м и о платежной карте и относится к л юбой орган изаци и , которая принимает платежи по пластиковой карте. Стандарт и меет два варианта: самооце н ку для небольших организаций и вне ш н и й аудит для орга­ низаций , которые обрабаты вают м ного сделок; см. p c i s e c u r i t y s t a n d a r d s . o r· g .

1 1 32 •

Часть lV. Эксплvатация

П равила Red Flags Rules Федеральной Ком исси и по торговле С ША требуют, чтобы любо й , кто расш иряет кредит на потребителей (т. е . л юбая орган изаци я , которая отс ылает счета) , осуществл ял формальную программу, предотвращающую и обна­ руживающую «хищение персональных данных». Правила требуют, чтобы эмите н ­ т ы кредитов разработал и эвр истические правила для того, чтобы идентифициро­ вать подозрительные ман и пуляции со счетами . Для выяснения деталей наберите фразу » red flag» в поисковой строке на сайте f t c . gov. Библиотека I nformation Technology Infrastructure Library (IТI L) в 1 990-х и 2000-х годах стала фактическим стандартом для организаци й , и щущих пол ноцен ное ре ­ шение для управления и нформацион н ы м и услугами. Во м ногих круп ных орга н и ­ зациях была развернута формал ьная программа IТI L, дополнен ная назначен и я м и менеджеров проекта для каждого процесса , м е н едже ров, управл я ющих м е н ед ­ жерам и проектов, а также систе мой отчетности дл я менеджеров , управл я ющих менеджерам и проектов. В бол ьш и нстве случаев резул ьтаты н е был и благоприят­ н ы м и . Зацикленность на процессах в сочета н и и с раздел е н и е м фун кций при вел к н еразре ш и м ы м П-конфл и ктам . Эта бюрократическая цепоч ка создала возмож­ ности для небол ьшого кол ичества стартапов, получ ивших возможность забрать долю р ы н ка у хорошо зарекомендовавш их себя ком пан и й , в резул ьтате чего м но­ гие П-специалисты остал ись без работы. Мы надеемся , что увидел и последний из IТI L. Н екоторые говорят, что DevOps — это методология против IТI L. Раздел 1Т General Controls (IТG C) в законе Сарбейнэа-Оксли ( SOX) , последн и й п о расположению, но не по важности, относится ко всем акционерным обществам и разработан , чтобы защитить акционеров от бухгалтерских о шибок и мошен н и ­ ческих методов; см. s e c . g ov / ru l e s / f i na l / 3 3 — 8 1 2 4 . h tm.

Н екоторые из этих стандартов содержат хорошие рекомендации даже для орган иза­ ц и й , которые не обязаны придерживаться их. Вероятно, стоит просмотреть некоторые из н их, чтобы понять, содержат л и они какие-л ибо рекомендаци и , которые вы , возмож­ но, захотите принять. Если у вас нет других ограниче н и й , проверьте N E RC C I P и N I ST 800- 5 3 ; о н и я вляются наш и м и фаворитами в отноше н и и тщательности и при менимости к широкому кругу с итуаци й . Н ациональны й институт стандартов и технологии ( N I ST) издает множество стандар­ тов, полезных для администраторов и технологов. Н екоторые из популярных стандартов упомянуты н иже , но если вам скуч но и вы и щете стандарты , можете зайти на е го веб­ сайт. В ы н е будете разочарованы. Стандарт NJST 800-53 (Рекомендуемые средства управления системами безопасности для федеральных информационных систем и организаций) описы вает, как оце н ить без­ опасность и н формацион н ых систе м . Есл и ваша орга н изация разработала внутрен нее приложе н и е , которое хран ит конфиде н циал ьную и нформацию, этот ста ндарт может помочь вам удостовериться , что вы действител ьно защитил и ее. Однако остерегайтесь: процедура согласования со стандартом N I ST 800-53 н е для слабонервных. Вы, вероят­ но, столкнетесь с докуме нтом объемом около 1 00 стра н и ц со м н ожеством м уч ител ь­ ных детал е й . 5 Стандарт NJST 800-34 (Принципы планирования на случай непредвиденных ситуаций для информационных систем) я вляется библ и е й авар и й ного восстановл е н и я , разрабо­ тан ной орган изаци е й N I SТ. Он предназнач е н для правительствен н ы х учрежде н и й , н о 5 Если вы план и руете сотрудн ичество с правительственными учреждениями С Ш А. от вас могут по­ требовать соответствия стандарту N I ST 800-5 3 , хотите вы этого ил и нет» .

Глава 31 . Методология, политика и стратегии

1 1 33

л юбая орган изация может извлечь из него в ыгоду. Следование стандарту план ирования N I ST 800-34 требует времени , но это вынуждает вас ответить на такие важные вопросы, как: » Какие с истемы являются самы м и важн ы м и? » , » Скол ько времени м ы можем обой­ тись без этих с исте м ? » и » Как м ы собираемся восстанавл иваться, есл и наш основной центр обработки дан н ых потерян ? «

3 1 .9. П РАВОВЫ Е ВОПРОСЫ П равительство США и некоторые штаты издал и законы о преступл е ниях в области ком пьютерной техники. На федерал ьном уровне с начала 1 990-х годов существовало два закона, а теперь их стало бол ьше. •

Федерал ьн ы й Закон о конфиде н циал ьности связи ( Electгonic Communicat ions Privacy Act) . З а к о н о ком п ьютерном мош е н н и честве и ком п ьютерн ы х злоупотребл е н ия х ( Computer Fraud and Abuse Act) .

Закон о комп ьютерных кражах (No Electronic Theft Act ) .

Закон о б авторских правах ( Digital M illenium Copyright Act) .

Закон о конфиде нциал ьности электронной почты (The Emai Privacy Act)

Закон о кибербезопасности 20 1 5 года (Cybersecurity Act of 20 1 5) .

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

Конфиденциальность Частную жизнь всегда было трудно скрыть, но с развитием И нтернета она подвер­ гается еще бол ьш е й опасности, чем когда-либо. М едицинская документация н еодно­ кратно раскрывалась с помощью плохо защище н н ых систе м , украден н ых ноутбуков и магн итн ых лент с резервн ы м и коп ия м и дан ных, которые н аходил ись не в положен ­ н о м м есте . Базы дан н ых , содержащие номера пластиковых карт, все гда подвергал ись атака м . Веб-сайты , предлагающие антивирусн ое программ н ое обес пече н и е , фактиче­ ски сам и устанавл и вают програ м м ы — ш п ион ы . П оддельная электро н ная почта посту­ пает почти ежедневно в виде фиктивных п исем от ваше го банка, в которых утвержда­ ется , что у вас воз н и кл и пробл е м ы с ваш и м счетом и требуется, чтобы вы п роверил и с вои учетн ые дан н ы е .6 Технические меры не могут защитить от этих видов атак, потому что они направлены на самую уязвимую часть вашего сайта: его пользователей. Поэтому л учшей е го защитой я вляется база хорошо обученных пользователей . В первом приближе н и и м ожно сказать, что в н и каком законно посланном сообщен и и электронной почты или на веб-сайте н и ­ когда не будет перечисленных ниже вещей.

» Об ычно внимател ь ное изучен и е электронной очты оказывает, что данные будут от п равлены ка п ­ п кому — н ибуд ь хакеру из Восточной Е вро п ы или Аз и и , а не в ваш банк. Этот ти п атаки называется ф и ш ингом.

Часть lV. Эксплvатация

1 1 34 •

Поздравлений с тем , что вы в ы и грали приз

Запросов на » подтверждение» персонал ьных данных учетной записи или паролей

Требовани й о пересылке куда-либо фрагментов сообщен ия электронной почты

Указаний на установку программ ного обеспечения, которое вы не искали и не за­ праши вал и в я вном виде

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

Реал изация пол итики безопасности Файлы с истем ного журнала могут легко доказать вам , что человек Х сделал плохо че­ ловеку У, но для суда это всего лишь слова. Защитите себя п исьменн ы м и заявле н и я м и . Файлы системного журнала как правило содержат отметки времени, которые полезны , н о их не всегда при н имают в качестве доказательства, если на ваше м комп ьютере с исте м ­ н о е врем я не с инхронизировано с эталоном посредством протокола N T P ( Network Тtme Protocol). Л уч ш е все го создать собствен ную пол итику безопас ности и довести ее до с веде­ н и я пол ьзователе й вашего сайта, чтобы затем можно было пресл едовать наруш ите­ лей в судебном порядке . Она должна содержать утвержден и е : » Н есанкционирован ное и спол ьзован и е в ы числи тел ьных с истем м ожет повл е ч ь н е тол ько н аруше н и е орга­ н изаци о н н о й полит и к и , н о и наруш е н и е законов ш тата и федерал ьн ых законов. Несанкционирован ное использование — это преступление, которое может повлечь уго­ ловное наказан ие и гражданско- правовые санкции ; оно будет преследоваться в право­ вом порядке в полном объе м е » . М ы советуе м показывать заставку, которая сообщит пользователям о ваших правилах контроля. Можно написать что-то вроде такого: «Действие может отслеживаться и фик­ сироваться в случае реального или предполагаемого нарушения правил безопасности» . Можно гарантировать, что пользователи увидят ваше уведомление, п о крайн е й м ере оди н раз, есл и вы включ ите его в файлы запуска, которые вы предоставляете новым пользователям . Если в ы требуете, чтобы все попытки входа в систему через п ротокол SSH регистрировалось (а вы должны это требовать!) , укажите соответствующие парамет­ ры конфигурации в файле /etc/ ssh/ sshd_config, чтобы при запуске клиент протоко­ ла S S H всегда показывал заставку. Убедитесь, что, пользуясь своими учетными записям и , пользователи соблюдают вашу письменную пол итику безопасности. Объясните , где они могут получить дополн ительные копи и документов пол итики и опубли куйте основные документы н а соответствующей веб-странице. Также включ ите в нее информаци ю о том , что будет в случае несоблюден ия этих правил (вплоть до удаления учетной записи и т.д.). Более важно, чтобы вы добросо­ вестно уведом ил и пользователе й об их обязанностях, а не просто составил и юридически грамотное заявление. Кроме заставки, целесообразно сделать так, чтобы пол ьзователи в явном в иде под­ п исали соглашение о пол ити ке безопасности , прежде чем получ ить доступ к ваши м си­ стемам. Это соглашение о приемлемом использован и и должно быть разработано в со­ трудничестве с ваш и м юридическим отделом. Если у вас н ет подписанн ых соглашений

глава 31 . Методология, политика и стратегии

1 1 35

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

Контроль — это ответственность П оставщики услуг (п ровайдеры И нтернета, облач н ы х вычисл е н и й и т. п . ) обыч н о следуют правилам пол ьзования сетью (appropriate use policy AU P) , которые диктуют стоя щие над н и м и провайдеры и которые я вл яются обязател ьн ы м и для их кл и ентов. Так и м образо м , вся ответствен ность за действия клиентов ложится на сам их кл иентов, а н е на провайдеров. Целью такой стратегии я вляется защита провайдеров от ответ­ стве н н ости за рассьшку спама и прочие н езакон ные действи я , например хранение пол ь­ зователя м и на своих ком п ьютерах незаконного ил и защищен ного авторск и м и правами матер иала. В каждом штате и каждой стране имеются свои зако н ы на этот счет. Ваш и правила должн ы я вно запрещать пол ьзователя м испол ьзовать ресурсы ком ­ пан и и для незаконной деятел ьности. Однако на самом деле этого н едостаточн о — в ы также должн ы дисципл и н ировать пользователей , обнаружи в, что они осуществляют н е ­ закон н ые действия. Орган изации , которые знают о незакон н ых действиях, но н е при­ н и мают меры для их пресе ч е н и я , сч итаются соучастни кам и и могут преследоваться по закону. Нет ничего хуже несобл юдаемых или проти воречащих друг другу правил , как с практической, так и юридической точ ки зрения. Из-за риска стать соучастником незаконных действи й пол ьзователя некоторые орга­ н изации ограничивают данн ы е , которые они регистр ируют, отрезок времен и , в течение которого сохраняются файлы систе м ного журнала, и объе м и нформации о файлах с и ­ сте м ного журнала, хранящейся в виде резервных копий. Некоторые пакеты п рограмм помогают выполнять эти правила, устанавли вая уровн и ре гистрации. Это позволяет си­ сте м н ы м адм и н истраторам устранять проблем ы , не вторгаяс ь в частную жизн ь пол ьзо­ вателей. Тем не менее всегда следует знать, какой вид ре гистрации требуется по местны м законам ил и по л юбым регул ирующим стандартам , которые распространя ются на вашу орган изацию. —

Л ицензии на п рограммное обеспечение М ногие компани и оплач ивают меньшее кол ичество коп и й про грамм , чем испол ьзу­ ют на самом дел е . Есл и об этом становится известно, ком пания теряет гораздо бол ь­ ше, чем сэкономила на приобретении недостающего ч исла лицензий. Другие компан ии получают де монстрацион ную верс и ю дорогого пакета и взлам ы вают ее ( м е н я ют дату на ком п ьютере , где -то находят и вводят л и цензион н ы й кл юч и та к дале е ) , чтобы па­ кет продолжал работать по исте ч е н и и демонстрацион ного срока. Как систе м н ы й ад­ м и н истратор должен реагировать на предложения нарушить л и це н зион ное соглашение и установить нелицензион ные коп и и программ ы на допол н ител ьные ком п ьютеры? Что он должен делать, есл и обнаружи вается , что на обслужи вае м ы х им ком п ьютерах работа­ ет п иратское программ ное обеспечение’? И как быть с условно-бесплатн ы м и программа­ м и , за которые так н и когда и не заплатил и’?

Часть lV. Эксплvатация

1 1 36

Это оче н ь сложн ы й вопрос. К сожал е н и ю , н ачал ьство не всегда поддерживает ад­ м инистратора, предлагающего удалить н ел и цензионн ые копи и п рограмм либо оплатить их. А ведь ч асто и м е н но систе м н ы й адми н истратор подписывает л и цензионное согла­ шени е , требующее удалить демонстрационные копи и после определе нной даты, тогда как решение их не удалять принимает руководитель. Нам и звестно несколько случае в , когда непосредствен н ы й начал ьн и к систе м ного адм и нистратора п редлагал ему » н е раскач и вать лодку» . Тогда адм и н истраторы написа­ ли докладную вышестоящему руководству, в которой указали коли чество лицензиро­ ван н ых и используе м ы х коп и й , а также процитировали л и це н зион ное соглаш е н и е . В одном случае подход сработал , и уволен был непосредствен н ы й начал ь н и к систе м ного адм и н истратора. Во втором случае уволиться п р и шлось систе м ному адм и н истратору, потому что даже вышестоящее руководство отказалось действовать по закону. Ч то бы в ы ни делали в такой с итуации , обязательно делайте это в письм е нном виде . Требуйте , чтобы ответы предоставлялись в п исьм е н ном виде , а есл и н е получ ится , документи­ руйте получ е н н ы е и нструкци и в в иде коротких служебн ых записок и отп равляйте их ответственному л ицу.

3 1 . 1 0. ОРГАНИЗАЦИИ, КОНФЕРЕНЦИИ И ДРУГИЕ РЕСУРСЫ М ногие групп ы поддержки с истем UNIX и Linux — и общего характера, и конкрет­ ных производителей — помогают устанавл ивать контакты с другим и л юдьми , использу­ ющим и то же програ м мное обеспечение. В табл . 3 1 . 3 приведен коротки й с п исок таких орган изаций , хотя большинство национал ь н ых и региональн ых групп в этой табли це не упомянуто. Таблица 31 . З . Орrанизации, ориентированные на системных администраторов систем UNIX и Unux

«

Название

Описание

FSF

Free Software Fouпdatioп — фонд свободного программного обеспечения, спонсор GNU

USENIX

Группа пользователей UN IX/LI N UX, обсуждающих технические вопросы•

LOPSA

League of Professioпal System Admiпistrators — лига профессиональных системных администраторов

SANS

Спонсор конференций по системному администрированию и безопасности

SAGE-AU

Австралийская гильдия системных администраторов; проводит ежегодные конфе­ ренции в Австралии

Liпux Fouпdatioп

Некоммерческий консорциум, ориентированный на стимулирование роста системы Liпux

LiпuxFest NorthWest

Новая и очень содержательная конференция

Хорошо известная организация, создавшая специальную группу участников конференций LISA, которая была рас­

пущена в 20 1 6 г.

Орга низация FSF ( Free Software Foundation — фонд с вободного програм м ного обе­ спечен и я ) я вляется спонсором проекта G N U ( G N U — аббревиатура от » G N U is Not Unix» ; так называется проект по свободному распространен и ю програ м много обеспече­ ния) . Под словосочетанием «свободное программное обеспечение» в н азва н и и этой ор­ гани зации подразумевается программн ое обеспечение, которое не и меет почти н и каких

Глава 31 . Методология, политика и стратегии

1 1 37

огран иче н и й в испол ьзова н и и , а не беспл атное программное обеспечен и е . Также орга­ н изация F S F я вляется автором л и це нзии G P L , которая распространяется на большую часть систем U N IX и Linux. Орган и заци я U S E N IX, представля ющая собой союз пол ьзователе й Linux, U N IX и других операционных систем с открыты м исходны м кодом , каждый год проводит одну общую конфере н ц и ю и несколько специал изирован н ых ( небол ьш их) . Конфере нция Annua Technical Confe rence (АТС) , на которой обсуждаются разнообразные тем ы , свя­ зан н ы е с системами U N IX и Linux, представл яет собой отличное место для укрепления с вязе й с сообществом. Л и га профессиональных систе м н ы х адм и н истраторов ( League of Professional System Administ rators — LO PSA) и меет сложную и запутан ную историю. Изначально она была создана орган изацией U S EN I X и бьu�а предназначена для объединения систе м н ых орга­ н изаторов в отдел ьную группу SAG E. К сожал е н и ю , отношения между организациями LO PSA и USEN IX не сложились, и они стал и существовать раздельно. В настоящее вре м я л и га LO PSA орган изовы вает учебные и образовател ьные про­ грамм ы по систем ному управле н и ю сетя м и , такие как System Administrator Appreciation Day (Де н ь системного адми н истратора) в последн юю пятни цу и юля. Традицион н ы м по­ дарком на этот праздник сч итается бутылка виски. И н ст итут SAN S п р о водит ко нфере н ци и и с е м и нары по во п росам безопас н о ­ сти , а также у п равляет отдел ьной уч е б н о й програ м мой по сертифи кац и и G l obal l nformat ion Assurance Cen ification ( G I AC ) . В рам ках этой п рогра м м ы гил ьдия выдает сертифи каты по разн ы м направл е н иям , та ким как с исте м ное адм и н истр ирова н и е , п рогра м м и ро ван и е , устран е н и е сбоев и сетевая кри м и нал истика (с м . и н фор м а ц и ю н а сайте g i a c . o r g ) . Существует м ножество групп пользователей U N IX, Linux и других открытых систе м . Одн и из н и х связа н ы с орган изацией U S EN IX, а другие нет. Локальные групп ы обычно п роводят регулярные встречи и рабочие семинары с м естн ы м и или приезж и м и лекто­ рами и часто орган изовывают бан кеты до или после мероприятия. Это хороши й способ поддерживать контакты с систе м н ы м и адм и н истраторам и в своем регионе .

3 1 . 1 1 . Л ИТЕРАТУРА •

BRooкs , FREDERICK Р. , J R. The Mythical Man-Month: Essays оп So/tware Engineering (2nd Edition) . Reading, МА: Addison-Wesley, 1 995.

К1 м , G E N E , KEVIN BEHR, AND G EORGE SPAFFORD. The Phoenix Project: А Novel About IT, DevOps, and Helping Your Business Win (Revised Edition) . Scottsdale , AZ: 1Т Revoution Press, 20 1 4.

Кl м , G EN E , ЕТ AL. The DevOps Handbook: How to Create World-Class Agility, Reliabllity, and Security in Technology Organizations. Scottsdale, AZ: 1Т Revoution Press, 20 1 6.

L1 мoNcE L L 1 , Тномлs А. Тiте Management /or System Administrators. Sebastopol , СА: O ‘ Reily M edia, 2005.

• •

Млсн 1лvЕ1_L1, N iccoш. Тhе Prince. 1 5 1 3 . Доступен на сайте g u t e nbe rg . o r g .

Morris, Kief. ln/rastructure a s Code: Managing Servers in the C/oud. Sebastopol , СА: O ‘ Reily Media, 20 1 6. Эта к н и га представляет собой хорошо нап исанн ы й и под­ роб н ы й обзор методологии DevOps, а также крупномас штаб н ых и нструме нтов для адм и н истрирования систе м ы в облаке. Он включает в себя нескол ько специ-

1 1 38

Часть lV. Экс плvатация

фических особен ностей управления конфигурацией как таково й , но это полезно для понимания того, как управление конфигурацией входит в более круп ную схе­ му DevOps и структурирован ное админ истрирование. •

Сайт i t l . n i s t . gov я вляется целевой странице й для лаборатори и и н формацион­ ных технологий N I ST и содержит множество и н формации о стандартах. Веб-сайт Electronic Fron tier Founda tion , e f f . o r g , я вля ется отл и ч н ы м м естом для поиска ком м ентариев по актуальн ы м вопросам конфиденциальности , крипто­ графи и и законодательства. Его всегда интересно читать. И нститут SAN S размещает коллекцию шаблонов политики безопасности по адре ­ су s a n s . o r g / r e s o u r c e s / p o l i c i e s .

Краткая история системного администрирования Из записок доктора Питера Салуса (Peter Н. Salиs), историка, занимающегося вопросами развития технологий

В современную эпоху больш инство людей имеют хотя бы минимальное предстамение о задачах, решаемых с исте м н ы м и администраторами: они должны неуста н но заботиться об удометворении потребностей пользователей и организаций, а также заниматься про­ ектированием и реализацией устойчивой к ошибкам вычислительной среды, стараясь при этом поражать своих клиентов эффективными решен иям и . Несмотря на то что системные администраторы часто считаются н изкооплачиваем ы м и и недооценен н ы м и , большинство пол ьзователе й могут хотя бы назвать имя своего м естного с исте м ного адми н истратора причем во м ногих случаях гораздо быстрее, чем имя начальника их начальн и ка. Но так было не всегда. За последн ие 50 лет (и в течение более ч е м 30-летней исто­ рии этой кн иги) роль систе м ного адми н истратора постепенно эвол юционировала вместе с операционными системам и U N IX и Liпux. Полное постижение предназначения систем­ ного адми нистратора потребует пон и мания того, каким путем м ы пришли к нынеш нему состоянию, а также понимания ряда исторических факторов, которые сформировали наш ландшафт. Итак, окинем взглядом несколько чудесных десятилетий . Присоединяйтесь!

Р асс вет ко мпь ютер из а ц ии: с истемн ые оп ерато р ы ( 1 952- 1 960) Первый серийн ы й ком мерческий ком п ьютер, I B M 70 1 , был в ы п уще н в 1 95 2 году. До н е го все ком п ьютеры вы пускал ись в еди н и ч н ы х экзем плярах. В 1 954 году модерн и ­ зирован ная версия I BM 70 1 была анонсирована как I B M 704. О н а и м ела оперативную память на магн итных сердечниках объемом 4 096 слов и вкл ючала три и ндексных реги­ стра. Этот комп ьютер использовал 36-разрядн ые слова (в отл ич ие от 1 8-разрядных слов у I B M 70 1 ) и выполнял арифметические операции с плавающей запятой. О н работал со с коростью 40 ООО и нструкций в секунду.

1 1 40

Краткая история системного администрирования

Однако ком п ьютер I B M 704 был несовм ести м с I B M 70 1 . Н есмотря на то что его поставки должны был и начаться к концу 1 955 года, операторы ( п редшестве н н ики со­ вре м е н н ы х с исте м н ых адм и н истраторов) восе мнадцати существующих ком п ьютеров I B M 70 1 уже нервничал и : как им пережить эту » модерн изацию» и на какие еще подво­ дные кам н и они могут наткнуться? Что касается самой ком пан и и I В М , то ее спе циал исты не и мел и решения проблемы модернизации и совмести мости . В августе 1 952 года дл я пол ьзователе й I B M 70 1 компа­ н ия провела курсы повышения квалификаци и , но учебн иков не выпустила. Не которые слушател и этих курсов продолжал и неформал ьно встречаться и обсуждать с вой опыт ис пол ьзования систе м ы . Ком пания I B M поощряла встреч и операторов , поскол ьку со­ вместное рассмотрен ие проблем помогало общи м и усил и я м и найти и х реш е н и е . I B M финансировала встреч и операторов и предоставила и х участн и кам доступ к библ иотеке , вкл ючающей 300 комп ьютерных программ . Эта группа по обмену и н формацией , имену­ е мая S HARE, все еще существует (вот уже более 60-ти лет!) 1 •

От узкой специал иза ции к работе в режиме разделен ия времен и ( 1 96 1 — 1 969) П ервые образцы ком п ьютерного оборудован ия были достаточ но громоздким и и чрез­ вычайно дорогим и . Это наводило покупателей на м ысл ь о том , что их ком пьютерные систе м ы предназначен ы для реш е н ия одной-единствен ной кон кретной задач и : тол ько достаточ но круп ная и кон кретная задача могла оправдать дороговизну и громоздкость та­ кого ком п ьютера. Если ком пьютер был инструментом специального назначения (наподобие пилы), то пер­ сонал, который обслужи вал компьютер, можно назвать операторами такой » пилы » . К пер­ вым системным операторам относились скорее как к «тем, кто пилит древесину» , чем как к «тем, кто обеспечи вает все необходимое Дll Я строительства здания » . Переход от систем­ ного оператора к систем ному адм инистратору начался тогда, когда ком пьютеры преврати­ л ись в универсальные (м ногоцелевые) инструменты. Основной причиной изменения точки зрения на компьютер стало то, что его начал и использовать в режиме разделения времени. Джон М аккарти (John McCarthy) начал подумывать о режи ме разделе н и я вре мени в средине 1 950-х годов. Изначально это бьuю только в Массачусетсском технологическом институте ( М IТ) в 1 96 1 — 1 962 годах, когда Джон Маккарти , Джек Де н н ис (Jack Dennis) и Фернандо Корбато ( Femando CorЬato) начали серьезно говорить о том , что нужно раз­ реш ить » каждому пол ьзователю ком п ьютера вести себя так, будто он единстве н н ы й его пол ьзователь» . В 1 964 году м п: General Electric и Ве1 Labs объеди н ил и свои усил ия по созда н и ю прое кта по построе н и ю п рете н циозной систе м ы , работающей в режи м е раздел е н и я вре м е н и . Эта с истема получила назван ие M ultics ( Multiplexed l nforrnation и Computi ng Seivice). П ять лет спустя проект M ultics превысил бюджет и безнадежно отстал от графи ­ ка работ. В резул ьтате ком пания Bell Labs вышла из проекта.

Рожден ие U N IX ( 1 969- 1 973) Отказ компан и и Bell Labs от участия в проекте Multics оставил нескольких научных работников в М юррей Хилл (штат Н ью-Джерси) без работы. Трое из н их — Кен Том псон ( Ken Thompson), Руд Кенедей ( Rudd Canaday) и Ден н ис Ритчи ( Dennis Ritchie) — заи н 1 Несмотря на то что группа S HARE изначально спонси ровалась производителя м и вычислител ьной техн и ки , в настоя щее время она я вляется независи мой организацией .

Краткая история системного администрирования

1 1 41

тересовались некоторыми аспектами проекта M ultics, но не были в восторге от размера и сложности этой системы. Они не раз собирались вместе, чтобы обсудить принципы про­ е ктирования компьютерн ых систем. Компания Labs запустила с истему M ultics на своем компьютере G E-645, и Кен Томпсон продолжил работу над этим проектом «шутки ради . » Дуг Макилрой ( Doug Mcllroy) , руководитель этой групп ы , сказал: » Система Multics впер­ вые заработала именно :щесь. Вдохнуть в нее жизнь удалось трем наш и м сотрудн икам » . Летом 1 969 года Томпсон н а месяц стал холостяком , пока его жена, Бон ни, взяв их го­ довалою сына, уехала повидать родственников на западное побережье. Томпсон вспоминал: «Я выделил по неделе на операционную систему, интерпретатор команд, редактор и ассем ­ блер . . . И вс е эти компоненты б ыл и полностью переписаны в форме, которая придавала им вид операционной системы (с набором известных утилит, ассемблером, редактором , интер­ претатором команд), которая практически полностью была самодостаточной и для своей работы больше не требовала G ECOS2 . Пo сути все это сделал один человек за один месяц». Стив Борн ( Steve Вoume), пришедши й работать в Bell Labs в следующем rоду, так опи­ с ы вал «заброше н н ы й » ком пьютер PD P- 7 , которым воспол ьзовал ись Ритч и и Том псон: » В P D P- 7 бьт и тол ько ассемблер и загрузч ик. На этом ком пьютере мог работать лишь оди н пользователь. Среда еще «отдавала сыростью» , хотя части одн опол ьзовател ьской систе м ы U N IX уже были » на подходе » . . . И вот бьти написаны ассемблер и зачаточное ядро операцион ной систе м ы , которые еще требовал и испол ьзования кросс-ассе мблера для трансляции п рогра м м ы в с истеме G ECOS и работы на маш и н е P D P- 7 . Название U N I C S ( U N iplexed Information апd Computing Service) для » новорожден ной » операци ­ онной систе м ы придумал заядлы й остряк П итер Нейман ( Peter N eu mann) в 1 970 году» . П ервоначально U N IX бьта однополъзовательской системой , отсюда, по-видимому, и на­ мек на » уреза н н ы й вариант Multics» . И хотя некоторыми аспектами система U N I C S/ U N IX все же обязана своей предшестве н н и це Multics, у н их, по словам Ден ниса Ритч и , бьти «серьезные различия». » М ы бьти немного подавлены большим ментал итетом с исте м ы , — сказал он. — Кен хотел создать что-то простое. Вероятно, из-за того, что наши возможности был и тогда до­ вольно невелики. М ы могл и получить доступ только к небольшим ком пьютерам, кото­ рые н и как нел ьзя было сравнить с тем и фантастическими аппаратн ы м и средства м и , на которых работал M ultics. Поэтому U N IX нельзя назвать ответным ударом, направленным против Multics . . . Операционная система M ultics больше не существовала для нас , но нам н равилось ощуще н и е и нтерактивной работы на ком п ьютере , которое она предлагала пользователю. У Кена бьти некоторые идеи по со:щанию новой систем ы . . . И хотя Mult ics повлияла на подходы к реализации U N IX, это влияние не было определяющи м » . » И грушечная » с истема Кена и Де нн иса недол го оставалась » простой » . К 1 97 1 году в ч исло ее пользовательских команд входил и следующие: as (ассемблер) , cal ( простая утилита-кале ндарь) , cat (конкатенация и вывод) , chdir (изменение рабочеrо каталога) , chmod (изме н е н и е режима), chown (изменение владел ьца ) , cm.p (срав н е н ие двух фай ­ лов) , ер ( копирован ие файла) , date , d c ( кал ькулятор) , du (отчет о б испол ьзова н и и дис­ кового пространства) , ed (редактор) и еще два десятка других команд. Большинством из этих команд все пол ьзуются и по сей день. К феврал ю 1 97 3 года можно было говорить о существован и и 16 и нсталляций U N IX, а также о двух бол ьших нововведе ниях. Первое связано с » новы м » языком програм­ м ирования С , основан н ы м на языке В , который сам представлял собой » урезан ную» верс и ю я з ы ка BC P L ( Basic Comblned Programming Language ) , созданного М артином Ричардсом ( M artin Richards) . Второе нововведе ние — понятие канала. ••

2G ECOS (Geпeral Electric Com pre heпsive Operatiпg System) — операционная система, разработан н ая компанией Ge neral E lectric в 1 962 r.

1 1 42

Краткая история системного администрирования

Канал , попросту говоря , — это стандартн ы й с пособ связи выходных дан ных одной програ м м ы с вход н ы м и дан н ы м и другой. Среда Dartmouth Тime- Sharing System и м ела файл ы связи , которые предвосхитили кан ал ы , но их испол ьзование было гораздо бо­ лее узким . Идея каналов ( как обобще н ного средства передачи дан н ых) была предло­ жена Дугом Макилроем , а реал изована — Ке ном Том псоном благодаря настойчивости Макилроя . ( » Это был оди н из нем ногочисленных случаев, когда я, по сути , осуществлял адм и нистрати вное управление над U N IX» , — сказал Дуг. ) «Легко сказать: cat — в grep — в » . и л и who — в cat — в grep и так далее, — как­ то заметил М акилрой. — Это легко сказать, и было ясно с самого начала, что именно это вы и хотел и бы сделать. Но еще существуют все эти параметры » . И время от време­ н и я говорил : » Как бы нам сделать что-то вроде этого?» И вот в один прекрас н ы й ден ь я пришел с с и нтаксисом дл я командного языка, которы й разви вался вместе с конвейер­ ной пересылкой данных, и Кен с казал : » Я готов сделать это!»» Применив множество вариантов, Том псон обновил все U N IХ- п рограм м ы за одну ночь. Это было настоящее начало власти U N IX, возникшее не из отдел ьных программ , а и з взаимосвязей между ними. Теперь у U N IX бьши собственные язык и основополагаю­ щие принципы: • • •

пишем програм м ы , которые бы выпол няли одну задачу, но вы пол нял и ее хорошо; пишем п рограмм ы , которые бы работали вместе; пишем программы , которые обрабатывали бы текстовые поток и как универсаль­ н ы й интерфейс.

Итак, можно было говорить о «рожден и и » операцион ной с исте м ы общего назначе­ н и я с разделением време н и , но пока лишь в » н едрах » фирмы Ве1 Labs. ОС U N IX обе ­ щала простое и незаметное разделение ком п ьютерных ресурсов между проектами, груп ­ пам и и орган изация м и . Но прежде чем этот ун иверсал ьн ый и нструмент стал достоя нием всего м ира, он должен был вырваться из собственной кол ыбели и » разм ножиться » .

U N IX ста новится знамен итой ( 1 97 4- 1 990) В октябре 1 97 3 года м еждународная науч но-образовател ьная Ассоциация по в ы ­ ч ислительной тех н и ке (Assoc iation fог Com put ing Machi nery — АС М ) провела сим по­ зиум на тему » П ри н ц и п ы построе н и я операцио н н ых с исте м » ( Symposium on Operating Systems Pri nciples — S O S P) в аудитори и Центра исследова н и й Уотсона ( Т. J . Watson Research Center) компани и I B M в Й орктаун Хайте (Yorktown Heights) , штат Нью- Й орк. Кен и Ден н ис в оди н пре крас н ы й осе н н и й де н ь поехал и в Дол и н у JУдзона ( Hudson Valley) , чтобы представить на рассмотрение с вой доклад. (Том псон сделал н астоящую презе нтацию.) В зале было около 200 человек, и доклад произвел фурор. Ш есть месяцев спустя количество инсталляций U N IX утроилось. Когда этот доклад был опубли кован в и юл ьском ( 1 974) выпуске журнала Communications of the АСМ, реак­ ция ч итателе й была просто ошеломляюще й . Науч но-исследовател ьс кие лаборатории и университеты увидели в разделяемых U N IХ-системах потен циальное решение пробле­ м ы их постоя н но возрастающих потребностей в компьютерных ресурсах. В соответств и и с положе н ия м и антимонопол ьного соглашен и я 1 95 8 года , подпи­ санного корпорацией АТ&Т ( из недр которой выделилась фирма Bell Labs) с федерал ь­ н ы м правител ьство м , ее деятельность бьша весьма ограничена: она не и мела право за­ ниматься рекламой, продажей и сопровожде нием ком п ьютерных продуктов. Ком пания Bell Labs должна бьша давать разрешение на испол ьзование другими свое й технологи и . Тем не менее система U N IX завоевала популярность в м ире , особен н о среди телефон-

Краткая история системного администрирования

1 1 43

ных компан и й . Отвечая на м ногочисленные просьбы , Кен Том псон стал распространять коп ии исходного кода U N IX, и, по леге нде , каждый пакет включал его личную записку, подп исанную » love , ken» (с л юбовью, Кен ) . Одн и м из тех, кто получ ил копи ю систе м ы о т Кен а , был профессор Роберт Фабри ( Robert Fabry) Калифорнийского университета в Бер кл и . Так, к я н варю 1 974 года зерно Be rkeley U N IX попало в плодородную почву. Другие уче ные, работающие в области компьютерных н аук, также проявил и и нтерес к UN IX. В 1 976 году Джон Лайонс (John Lions), преподаватель факультета компьютерн ых наук в Университете Нового Южного Уэльса в Австрал и и , опубликовал подробн ые ком ­ ментари и относительно ядра версии Vб. Эта работа стала первым серьезным пакетом до­ кументаци и по системе UN I X и помогла другим понять и развить работу Кена и Ден н иса. Студенты Калифорнийского ун иверситета в Беркли поработали над версией U N IX, по­ лучен ной из Bell Labs, и изменил и ее так, чтобы она отвечала их требованиям. Первый лен­ точный дистрибугив программы Беркли ( l st Berkeley Software Distribution — l BSD) содержал систему Pascal для U nix и текстовый редактор vi для ком пьютера PDP- 1 1 . Этот дистриб}тив подготовил асп ирант Билл Джой ( Bill Joy) . Второй выпуск (28SD) вышел в следующе м году, а третий (ЗBSD) в качестве первого дистрибутива программ ы Беркли для мини-компью­ тера VAX, выпускаемого корпорацией D EC, увидел свет в конце 1 979 года. В 1 980 году профессор Роберт Фабри закл ючил контракт с упраВJJ е н ием перспекти в­ ных исследовател ьс ких программ в области оборон ы ( Defense Advanced Research Project Age ncy — DAR PA) на продолже н ие разработки с исте м ы UN IX. Резул ьтатом этого со­ глашения стало образован ие в Беркл и исследовательс кой группы по ком пьютерн ым с и ­ стемам (Computer Systems Research G roup — C S RG ) . В конце следующего года вышла четвертая версия с исте м ы — 4 B S D . Она приобрела довольно ш и рокую популярность, в основном потому, что это была еди нствен н ая версия U N IX, которая работала на D EC VAX 1 1 /750, весьма распростран е н ной в то время ком пьютерной платформе. Еще одно крупное усовершенствование, отл ичавшее выпус к 4 B S D , состояло в испол ьзова н и и со­ кетов TCP/ I P, обобщен ной сетевой абстракци и , которая в будущем породила И н тернет и сейчас ис пользуется м ноги м и совре м е н н ы м и операцион н ы м и системам и . К середине 1 980-х годов в большинстве круп ных ун и верситетов и науч но-исследовател ьских и нсти ­ тутов была устаноВJJ е на хотя б ы одна система U N IX. В фе врале 1 982 года Билл Джой ос новал ком па н и ю Sun M i c rosystems (сейчас это ч асть ком пан и и Oracle America) и положил в основу операцион н о й с исте м ы SunOS изобретенную и м систему 4 . 2 B S D . В 1 983 году по реш е н и ю суда началась ликвидация корпорации АТ&Т, и одн и м непредвиде н н ы м побоч н ы м эффе ктом этой л и квидации было то, что АТ&Т отн ы н е моrла с вободно продавать систему U N I X как програ м м н ы й продукт. В результате увидела свет версия АТ&Т U N IX System У общеизвестная , хотя и нескол ько неудобная ком мерческая реализация системы U N IX. Те перь, когда Berkeley, АТ&Т, Sun и другие дистри бути в ы U N I X стал и досту п н ы для ш и рокого круга организаци й , был заложен фундамент дл я общей ком п ьютерной инфраструктур ы , построе н ной на технологии U N IX. Систему, которую испол ьзовал и в области астроном и и для вычисления звездных расстоян и й , можно было успешно при­ ме нять в математи ке для вычислен и я множеств Мандельброта. И та же с истема одно­ временно обеспеч ивала доставку эле ктрон ной почты для все го уни верситета. —

Э ра системн ых администраторов УпраВJJ е ние ком пьютерн ы м и системами общего назначен и я требовало другого уров­ н я знан и й , чем двадцать л ет назад. Ушл и в прошлое дни , когда с истем н ы й оператор обслужи вал еди н ствен ную ком п ьютерную систему, предназнач е н н у ю для выпол н е н и я

1 1 44

Краткая история системного администрирования

специал изирован ной задачи. Систе м н ы й адми н истратор в начале 1 980-х годов стал на­ стоя щим » хозяином положе н ия » , которы й знает, как настроить систе му U N IX, чтобы она удовлетворяла требованиям самых разных приложен и й и пользователей. Поскольку с истема U N IX была весьма популярной в университетах и м ножество сту­ дентов горело желанием овладеть новейшими технологиями, именно университеты лиди­ ровал и в создании организованных групп системных администраторов. Такие учебные за­ ведения, как Университет Пердью, Университет штата Юта, Университет штата Колорадо, Университет штата М эриленд и Уни верситет штата Н ью- Й орк ( S U N Y) в r. Буффало, ста­ ли «рассадниками » специалистов в области системного адми нистрирования. Кроме того, с исте м н ые адми н истраторы разработали собствен н ы е процесс ы , стан­ дарты , инструкции и инструменты (например, sudo). Большинство из этих продуктов родилось из н еобходимости , пос кольку без н их с истем ы работал и нестабил ьно , что , естествен но, вызы вало недовольство пользователей. Эви Немет ( Evi Nemeth) приобрела известность как » мать системного админ истриро­ вания » тем , что приглашала на работу в качестве с исте м н ых адм инистраторов студе нтов старш их курсов И нженерного колледЖа ( Engi neering College) при Ун иверситете штата Колорадо. Ее бл изкие с вязи с сотрудниками Калифорн ийского университета в Беркл и , Ун иверситета штата Юта и SUNY в r. Буффало позвол ил и создать сообщество экспертов по вопросам систе м ного адми нистрирования, которые делились советами и инструмента­ м и . Ее команду часто называли munchkins, т.е . » переработчики информации » или » рабы Эви » . Член ы этой команды посещал и различные конференции (в том числе и спонсиру­ емые организацией U S EN IX) и работали там в качестве служебного персонала в обмен на возможность получать информацию, излагаемую участниками этих конференций. Уже стало ясно, что систе м н ые адм и н и страторы должны были стать » мастера м и на все руки » . В 1 980-х годах обычное утро с истемного адм и н истратора могло начаться с испол ьзования инструмента для накрутки провода для поч и н ки поврежден ного пере­ кл ючателя на задней панел и м и н и — компьютера VAX. Днем он мог зан иматься очищени­ ем лазерного принтера первого покол е н ия от рассыпавшегося тонера. Его обеде н н ы й перерыв мог быть потрачен н а помощь какому- нибудь студенту отладить новый драйвер ядра, а вечерние часы могли быть заполнены записью и нформации на архивные ленты и уговорам и пользователе й почистить свои персональные каталоги , чтобы освободить пространство в файловой с истеме. Систе м н ы й администратор был , без преувеличения , бескомпром иссным ан гелом — хранителем , который должен был решить л юбую проблему. 1 980-е годы можно было назвать временем ненадежного оборудования. Центральные процессоры был и сделан ы не из одной кремниевой м икросхе м ы , а и з нескольких сотен чипов, каждый из которых мог в л юбую минуту отказать. И именно с исте м н ы й адм и н и ­ стратор должен бьт быстро отыскать неисправный элемент и заменить его работающим . К сожал е н и ю , в т о врем я почтовая служба Federal Express еще не работала, и поэтом у элементы для заме н ы н ужно бьто находить сам и м , что зачастую бьто очень непросто. Однажды наш л юбим ы й комп ьютер VAX 1 1 /780 перестал работать, в результате чего весь университет остался без эле ктрон ной почты . М ы знал и , что н едалеко от нас есть фирма, которая собирала компьютеры VAX, предназначенные «для науч ных исследова­ н и й » для отправки в Советский Союз (то бьто время » холодной вой н ы » ) . Практически без вся кой надежды на успех мы заявились на склад с большой суммой нал и ч н ых в кар­ мане , и после часа переговоров мы все-таки получили н еобходимую печатную плату. Кое- кто отметил , что в то время в Боулдере (штат Колорадо) было легче достать нарко­ тики , чем запчасти к VAX.

Краткая история системного администрирования

1 1 45

Документация по системному администрированию и обучение По мере того как отдельные ком пьютерные специалисты стал и считать себя систе м ­ н ы ми адм и н истраторами — и причем стало ясно, что такая специализация может обе­ спечить достойную жизнь, — потребности в докуме нтации и соответствующем обуче­ нии ощутимо возросл и . » Идя навстречу пожелан и я м трудящихся » , Тим О ‘ Рейлли (lim O ‘ Reilly) и его команда (именуемая ранее O ‘Reil/y and Associates, а теперь O’Reilly Media) начал и публ иковать докуме нтацию по систе м е U N IX, написан ную п росты м языком и основанную на реальном оп ыте. В качестве посредн ика межличностного взаимодействия ассоциация USEN IX провела свою первую конференцию, посвященную системному администрированию, в 1 987 году. Эта конферен ция ( Large l пstallatioп System Admiпistratioп — LISA) охватила, в основном , западное побережье . Три года спустя был учрежден институт SAN S ( SysAdmiп, Audit , N etwork, Security) для удовлетворения потребностей специалистов восточного побережья . В настоя щее время конференции LISA и SAN S обслуживают всю территорию США и до сих пор на достаточно высоком уровне. В 1 989 году мы опубликовали первое издание этой книги , имевшей тогда название UN/X System Administration Handbook. Она бьта быстро раскуплена, в основном, из-за отсутствия альтернативы. В то время наш издатель бьт настолько далек от систем ы U N IX, что в их ре­ дакции все вхожден ия строки «etc » бьти заменен ы строкой «апd so оп» , в результате чего появились такие имена файлов, как /and so on/passwd. Мы воспользовались создавшей­ ся ситуацией , чтобы взять под полный контроль все содержимое книги от корки до корки , и сейчас, надо признать, наш издатель стал более осведомленным в вопросах UN IX. Наше 20-летнее сотрудничество с этим издателем дало пищу для других интересных историй, но мы их опустим , дабы не испортить наши вполне дружеские отношения.

U N IX при смерти . Рождение Linux ( 1 99 1 — 1 995) К концу 1 990 года казалось, что U N IX стрем ительно движется к м и ровому господ­ ству. Бесспорно, именно эту операцион ную систему выбирали как для ведения бизнеса ( например, Тасо Bell и Mc Donald ‘s), так и для исследовательских и науч н ых расчетов. Группа C S RG (Computer Systems Research G roup — исследовател ьс кая группа по ком ­ п ьюте р н ы м системам) в Беркл и , состоя щая и з Кирка Маккузи ка ( Кi rk Mc Kusick) , Майка Карелса ( M ike Karels) , Кейта Бостика ( Keith Bostic) и многих других, как раз вы­ пустила версию 4. 3 BSD- Reпo, основанную на выпуске 4.3, в которую была добавлена поддержка для процессора C C I Power 6/32 (с кодовым именем «Tahoe » ) . Ком мерческие выпуски U N IX (например, SuпOS) также пользовались успехом , ко­ тор ы й , отчасти , им обеспечили появл е н и е И нтернета и первые шаги в направл е н и и электронной торговл и . Оборудование персонал ьного ком пьютера стало предметом ш и­ рокого потребления. Оно уже бьто относ ительно надеж н ы м , недорогим и обеспеч и ва­ ло довольно высокую производител ьность. И хотя версии систе м ы U N IX, запускаемые на персонал ьн ых ком пьютерах, действител ьно существовал и , все они был и ком мерче­ с ки м и , причем с закрытым исходным кодом . Н азрела с итуация дл я поя вл е н ия U N IX для персонал ьн ых компьютерах с открыты м исходным кодом. В 1 99 1 году груп па разработчи ков, трудив шихся над выпусками BSD, — Дон н Сил и ( Donп Seeley) , Майк Кареле, Билл Джолитц ( ВШ Jolitz) и Трент Р. Хей н (Trent R. Hein) вместе с другими при верженцами B S D основали компани ю Berkeley Software Design, l nc. ( B S D I ) . Под руководством Роба Колстада ( Rob Kolstad) компания B S D I предоставляла испол н я е м ые файл ы и исход н ы й код для пол н остью фун кционал ьной ком мерческой версии BSD U N IX на персональных ком п ьютерах. Среди прочего, этот проект доказал ,

Краткая история системного администрирования

1 1 46

что для создания массовых производствен н ых сред можно испол ьзовать недорогие пер­ сонал ьн ые ком пьюте р ы . Ком пан ия B S D I продемонстрировала взр ы воподобн ы й рост прибыл и на заре развития И нтернета, поскольку именно ее операцион ную систе му вы­ бирали первые провайдеры услуг Интернета ( l ntemet service providers I S P) . П ытаяс ь с но ва уп рятать джи н на, который выскочил из бутыл ки в 1 97 3 году, кор­ порация АТ&Т в 1 992 году начала судебн ый процесс против ком пан и и B S D I и членов правл е н ия у н иверс итета Кал ифорн и и ( Regents of the U n ive rsity of Califomia) , зая вив о коп ировании кода и воровстве производствен н ых секретов. Юристам компани и АТ&Т потребовалось более двух лет, чтобы идентифицировать проблем н ы й код. В результате судебного разбирательства из кода B S D было удалено три файла (из более чем 1 8 000). К сожалению, этот двухлетн и й период неопределен ности оказал негати вное воздей ­ ствие н а весь м и р U N I X , операцион ную систему B S D и подобные е й н е — В S D-верс и и . М ногие ком пан и и перешли на ис пол ьзование M icrosoft Wi ndows, испугавшись, что о н и могут оказаться в о власти ком пан и и АТ&Т, которая практически » задуш ила в объяти­ ях» свое дитя . К тому времен и , когда ды м сраже н и й развеялся , оказалось, что ком па­ нии B S D I и C S RG «смертел ьно ране н ы » . Эра BSD подходила к концу. Тем временем Л инус Торвал ьдс ( Linus Torvalds) , студент колледжа в Хельсинки, наи гравш ись с Minix свободной U niх- подобной м икроядерной операцион ной системой, распространяе мой по л ице нзии B S D , начал п исать собствен ную систему- клон U N I X 3 • К 1 992 году по­ я вилось м н ожество дистрибути вов Linux ( вкл ючая SuSE и Yggdrasil Linux) . В 1 994 году м ир узнал о создании систем Red Hat и Linux Pro. Феноменальн ы й успех Liпux основан на м ногих факторах. Мощная поддержка всех, кому понравилась эта систе м а, и обш ирный сп исок програм м из архива G N U сделал и Liпux неуязвимой с исте мой. Она прекрасно работает в любых производственных средах, и поговаривают, что на основе Linux можно построить более надежную и более произ­ водител ьную с исте му, чем на ос нове л юбой другой операционной систе м ы . И нтерес но также отметить, что отчасти своим успехом Linux обязана блестя щей возможности, пре ­ доставленной ей действиями компани и АТ&Т против B S D I и университета Кал ифорнии в Беркл и . Тот неуместн ы й судебн ы й процесс всел ил страх в сердца приверже н цев U N IX прямо на заре электронной торговли и в начале эры Интернета. Но не все л и равно теперь? Главное , что в резул ьтате всех этих перипетий осталась огром ная потребность в с исте м н ых адм и н истраторах. Багаж знан и й и опыт, накопл е н ­ н ы й систе м н ы м и админ истраторами при обслуживани и систем U N I X, полностью п р и ­ м е н и м ы к Linux, и большинство » U N IХ-лоцманов» заботл иво продолжали вести с воих пользователей через бурн ые моря 1 990-х. Возьм ите себе на заметку: хороший систе м н ый администратор должен оставаться спокойным во врем я л юбого шторма. —

М ир Wi ndows ( 1 996- 1 999) В 1 993 году ком пан ия M icrosoft выпустила ОС Windows NТ. Эта «серверная » версия Wi ndows, которая имела популярный пользовательский и нтерфейс, имела значител ьн ый эффект, причем как раз тогда, когда корпорация АТ&Т старалась убедить всех в том , что она больше никому не позволит обманы вать себя в лицензионных вопросах. Как следствие, м ногие организаци и приняли Wi ndows в качестве предпочтительной платформ ы для со­ вместных вычислений. Это был конец 1 990-х. Вне всякого сомнения, платформа Microsoft прошла долгий путь развития , и Дll Я некоторых организаций это был наилучший выбор. 30С M i nix была разработана Эндрю Таненбаумом (Andrew S. Tanenba u m ) , п рофессором Амстер­ дамского свободного университета.

Краткая история системного администрирования

1 1 47

К сожалению, сначала админ истраторы U N IX, Linux и Windows и спользовали в сво­ ей работе кон курентн ые подходы , соперничая за » место под сол н це м » путем п ротиво­ поставления аргументов из реклам ы п и ва: «отличный вкус» против » меньшего объема»4• М ногие адми н истраторы систем U N IX и Linux начал и сроч но изучать Windows, убеж­ ден н ые в том , что в проти вном случае и м придется » положить зубы на пол ку» . А на го­ ризонте уже показалась Windows 2000. С прибл ижен ие м » м иллениума» будущее U N IX выглядело все более м рач н ы м .

Расцвет UNIX и Linux (2000-2009) С приходом И нтернета все старал ись понять, что » настоящее » , а что — всего л и ш ь мираж. Когда страсти «от новизн ы » нем ного уле глись, стало я с н о , что многие органи­ зац и и с усп е ш н ы м и техническими стратегия м и испол ьзовали U N IX или Li nux вместе с Wi ndows, а не только что-то одно. Кон курентной войны больше не было. Оцен ки экспертов, испол ьзующих методи ку определения суммарной стоимости вла­ дения (соотноше н ия це ны-качества , total cost of ownership — ТСО ) , показали , что этот показатель для сервера Linux был знач ительно н иже аналогич ного показателя для сер­ вера Windows. П осле экономического кризиса 2008 r. показател ь ТСО стал еще важнее. М ир снова разворач и вается лицом в версиям операцион н ых с истем U N IX и Linux с от­ крыты м кодом .

Системы U N IX и Linux в гипермасштаби руемом обла ке (20 1 О- настоящее время ) Варианты Linux и U N IХ для персональных компьютеров, такие как Free BSD, продолжа­ ют расширять свою долю на рынке , при этом Linux — единственная операционная система, доля рынка которой растет на серверах. Кстати, текущая полномасштабная операционная система компании Арре под названием macOS, также является вариантом U N IX.5 Знач ител ьная часть недавнего роста р ыночной дол и операцион н ы х с истем U N IX и Linux объясняется виртуализацией и облачн ы м и вычислениями. Более подробную и н ­ формацию о б этих технологиях с м . в главах 9 и 24. Возможность создания виртуал ьной и нфраструктуры (и цел ых виртуал ьных це н ­ тров обработки дан н ых) путем использования вызовов A P I коре н н ы м образом изме­ н ила тенденции. Ушла в п рошлое эпоха ручного управле ния физическими серверам и . Масштабирование инфраструктуры больше не требует закупок новых серверов в короб­ ках. Благодаря таким службам , как Google G C P, Amazon AWS и Microsoft Azure , насту­ п ила эпоха гипермасштабируемого облака. Стандартизация, инструменты и автоматиза­ ция — это не просто новинки, а неотьемлемые атрибуты каждой вычислительной среды . Сегодня грамотное управление парками серверов требует обш ирн ых знан ий и навы­ ков. С исте м н ые адм и н истраторы должны быть дисципл и нированн ы м и профессионала­ м и . О н и должны знать, как создавать и масштабировать и нфраструктуру, как работать совместно со сверстн иками в среде DevOps, как программировать простые сценарии ав­ томатизации и мониторинга и как сохранять спокойствие , когда одновременно выходит из строя тысяча серверов. 6 •Для ясности : в Windows де йствительно «меньше объема » . sдаже с мартфоны i Phone компании Apple можно назвать кузенами U N IX, а операцион ная система Aпdroid компании Google основана на ядре Liпux. 60дно не изменилось: виски по-преж нему остается луч ш и м другом многих системных администра ­ торов.

Краткая история системного администрирования

1 1 48

З автра ш н ий ден ь U N IX и Li nux Куда м ы направляемся дал ьше? Экономная модул ьная паради гма, которая так хо­ рошо служила в сфере U N IX последние нескол ько десятилет и й , также я вляется од­ ной из основополагающих технологий И нтернета вещей ( loT) . П о дан н ы м И нститута Брукингса ( B rookings l nstitution) , к 2020 г. будет существовать 50 м илл иардов небольших распределенных устройств, образующих И нтернет вещей (см. b r oo k . g s / 2 bNwbya ) . Заманчиво думать о б этих устройствах так же , к а к м ы думал и о несетевых бытовых приборах (например, тостерах ил и блендерах) прошл ых лет: подключ ите их, испол ьзуйте в теч е н ие нескольких лет и , если он и сломаются, выбросьте их на свалку.7 И м не нужно управление ил и услуги системного администратора, не так ли? Н а самом деле н ичто не могло быть дальше от истин ы . М ногие из этих устройств об­ рабатывают конфиде н циальные дан ные (например, звуковые, передаваемые из м и кро­ фона в ваше й гостиной) или выполняют критически важн ые фун кци и , такие как управ­ ление температурой вашего дома. Н е которые из этих устройств запускают встрое нное программное обеспечение, по­ лучен ное из м ира OSS. Но независ и мо от того, что находится внутри сам и х устройств, бол ьшинство из них отч итывается перед материнским кораблем , находящимся в облаке , которое работает, вы уже догадались, под управлением систем U N I X ил и Linux. На ран ­ них, захватн ических этапах развития рынка м ногие устройства уже были развернуты без особого внимания к вопросам безопасности или будущих экологических последстви й . И н тернет вещей не ограничивается потребител ьск и м рынком. Совре м е н н ые ком ­ мерческие здания пронизаны сетевым и устройства м и и датч и кам и , например для ос ­ веще н и я , вентиля ции и отопле н и я , обеспечения физической безопасности и видеона­ блюдения. Эти устройства часто появляются в сети без координации с I Т-отделами ил и подразделения м и информационной безопасности. Затем о них забы вают без какого-л и ­ бо плана постоя нного управления, исправления ил и мон итори н га. Размер не и м еет значе н и я , когда дело доходит до сетевых систе м . С исте м н ы м ад­ м и н истраторам необходимо защи щать безопасность, производител ьность и доступ­ ность устройств И нтернета вещей ( и их поддерживающей инфраструктуры) независимо от размера, местоположения или функции. Системные адм и н истраторы заботятся о целостности ком п ьютерной и нфраструкту­ ры, решают сложнейшие проблемы эффе ктивности и масштабируемости с истем и снаб­ жают квалифицирован н ы м и рекомендаци я м и в области компьютерных технологий как рядовых пользователей, так и руководителей организаци й . М ы с истемные адми нистраторы! Без нас — н и как!

Л итература •

Мскus1ск,

MARSHALL К1Rк, КЕпн Воsп с , М 1снАЕL J. l

                    ЭВИ НЕМЕТ, ГАРТ СНАЙДЕР, ТРЕНТ ХЕИН, БЭН УЭЙЛИ
при участии Терри Морреале, Нала Мак-Клейна, Рона Якима, Дэвида Швайкерта и Тоби Отикера
4-Е ИЗДАНИЕ
UNIX и LINUX
РУКОВОДСТВО
СИСТЕМНОГО
АДМИНИСТРАТОРА

UNIX AND LINUX SYSTEM ADMINISTRATION HANDBOOK Fourth Edition Evi Nemeth Garth Snyder Trent R. Hein Ben Whaley with Terry Morreale, Ned McClain, Ron Jachim, David Schweikert, and Tobi Oetiker • • PRENTICE HALL Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York - Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney - Tokyo • Singapore • Mexico City
UNIX И LINUX РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА 4-е издание Эви Немет Гарт Снайдер Трент Хейн Бэн Уэйли при участии Терри Морреале, Нэда Макклейна, Рона Якима, Дэвида Швайкерта и Тоби Отикера Москва • Санкт-Петербург • Киев 2012
£>DJS. JZ.?/ J.ZU-U1O.Z./ J H50 УДК 681.3.07 Издательский дом “Вильямс” Зав. редакцией С.Н. Тригуб Перевод с английского докт. физ.-мат. наук ДА. Илюшина и Н.М. Ручко Под редакцией докт. физ.-мат. наук Д А. Илюшина По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу: info@williamspublishing.com, http://www.williamspublishing.com Немет, Эви, Снайдер, Гарт, Хейн, Трент, Уэйли, Бэн. Н50 Unix и Linux: руководство системного администратора, 4-е изд. : Пер. с англ. — М.: ООО “И.Д. Вильямс”, 2012. — 1312 с.: ил. — Парал. тит. англ. ISBN 978-5-8459-1740-9 (рус.) ББК 32.973.26-018.2.75 Все названия программных продуктов являются зарегистрированными торговыми марками соответ- ствующих фирм. Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фото- копирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Prentice Hall, Inc. Authorized translation from the English language edition published by Prentice Hall, Inc., Copyright © 2011 Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, elec- tronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Red Hat Enterprise Linux and the Red Hat SHADOWMAN logo are registered trademarks of Red Hat Inc., and such trademarks are used with permission. Ubuntu is a registered trademark of Canonical Limited, and is used with permission. SUSE and openSUSE are registered trademarks of Novell Inc. in the United States and other countries. Oracle Solaris and OpenSolaris are registered trademarks of Oracle and/or its affiliates. All rights reserved. HP-UX is a registered trademark of Hewlett-Packard Company. (HP-UX®) AIX is a trademark of IBM Corp., registered in the U.S. and other countries. Russian language edition published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2012 Научно-популярное издание Эви Немет, Ihpr Снайдер, Т^ент Хейн, Бэн Уэйли Unix и Linux: руководство системного администратора 4-е издание Литературный редактор ЕД. Давидян Верстка М.А. Удалов Художественный редактор В.Г. Павлютин Корректор Л. А. Гордиенко Подписано в печать 07.12.2011. Формат 70x100/16. Гарнитура limes. Печать офсетная. Усл. печ. л. 105,78. Уч.-изд. л. 96,3. Тираж 1000 экз. Заказ № 27034. Отпечатано по технологии CtP в ОАО “Первая Образцовая типография”, обособленное подразделение “Печатный двор”. 197110, Санкт-Петербург, Чкаловский пр., 15. ООО “И. Д. Вильямс”, 127055, г. Москва, ул. Лесная, д. 43, стр. 1 SBN 978-5-8459-1740-9 (рус.) © Издательский дом “Вильямс”, 2012 SBN 978-0-13-148005-6 (англ.) © Pearson Education, Inc., 2011
Оглавление Часть I. Основы администрирования 41 Глава 1. С чего начать 43 Глава 2. Сценарии и командная оболочка 70 Глава 3. Запуск и останов системы 119 Глава 4. Управление доступом: сила привилегий 145 Глава 5. Управление процессами 163 Глава 6. Файловая система 184 Глава 7. Добавление новых пользователей 218 Глава 8. Дисковая память 252 Глава 9. Периодические процессы 330 Глава 10. Резервное копирование 339 Глава 11. Система Syslog и журнальные файлы 388 Глава 12. Управление программным обеспечением и конфигурацией 412 Глава 13. Драйверы и ядро 464 Часть II. Работа в сетях 493 Глава 14. Сети TCP/IP 495 Глава 15. Маршрутизация 558 Глава 16. Сетевые аппаратные средства 577 Глава 17. Система доменных имен 597 Глава 18. Сетевой протокол Network File System 735 Глава 19. Совместное использование системных файлов 764 Глава 20. Электронная почта 787 Глава 21. Управление сетями 907 Глава 22. Безопасность 943 Глава 23. Веб-хостинг 1001 Часть III. Разное 1025 Глава 24. Виртуализация 1027 Глава 25. Система X Window System 1055 Глава 26. Печать 1076 Глава 27. Центры обработки данных 1129 Глава 28. Экологичные информационные технологии 1141 Глава 29. Анализ производительности 1157 Глава 30. Взаимодействие с системой Windows 1180 Глава 31. Последовательные устройства и терминалы 1208 Глава 32. Управление, стратегия и политика 1228 Краткая история системного администрирования 1278 В защиту AIX 1288 Предметный указатель 1291
Содержание Об авторах 34 О соавторах 35 Предисловие 3° Введение 3^ Благодарности 3^ Часть I. Основы администрирования 41 Глава 1. С чего начать 43 1.1. Основные задачи системного администратора 44 Инициализация пользователей 44 Подключение и удаление аппаратных средств 44 Резервное копирование 45 Инсталляция и обновление программ 45 Мониторинг системы 45 Поиск неисправностей 45 Ведение локальной документации 46 Слежение за безопасностью системы 46 Оказание помощи пользователям 46 1.2. Что необходимо знать 46 1.3. Взаимосвязь систем Linux и UNIX 48 1.4. Дистрибутивы Linux 49 1.5. Примеры систем, используемых в этой книге 51 Примеры Linux-дистрибутивов 51 Примеры UNIX-дистрибутивов 53 1.6. Административные средства конкретных систем 54 1.7. Типографские особенности книги 54 1.8. Единицы измерения 55 1.9. Использование справочных страниц и другой оперативной документации 56 Организация справочных страниц интерактивного руководства 56 Команда man: чтение страниц интерактивного руководства 57 Хранение страниц интерактивного руководства 58 GNU-система Texinfo 58 1.10. Другие виды официальной документации 59 Руководства по конкретным системам 59 Документация по конкретным пакетам 60 Книги 60 Документы RFC и другие интернет-ресурсы 60 Проект документации по Linux 60 1.11. Другие источники информации 61 1.12. Как инсталлировать программное обеспечение 62 Определение факта инсталляции программного обеспечения 63 Добавление новых программ 64 Сборка программного обеспечения из исходного кода 66 (1.13. Издержки профессии 67 ! 1.14. Рекомендуемая литература 67 ; Системное администрирование 68
Содержание 7 Основной инструментарий 68 1.15. Упражнения 69 Глава 2. Сценарии и командная оболочка 70 2.1. Основы работы с командной оболочки 71 Редактирование команд 71 Каналы и перенаправление потоков 72 Использование переменных и кавычек 73 Команды общих фильтров 74 2.2. Написание bash-сценариев 78 От команд к сценариям 79 Организация ввода и вывода данных 81 Функции и аргументы командной строки 82 Область видимости переменных 84 Поток управления 84 Циклы 86 Массивы и арифметика 88 2.3. Регулярные выражения 89 Процесс сопоставления 90 Литеральные символы 91 Специальные символы 91 Примеры использования регулярных выражений 92 Захваты 93 Жадность, леность и катастрофический поиск с возвратом 94 2.4. Программирование на языке Perl 96 Переменные и массивы 97 Массив и строковые литералы 97 Вызовы функций 98 Преобразования типов в выражениях 98 Раскрытие строк и устранение неоднозначности при ссылках на переменные 99 Хеши 99 Ссылки и их самооживление 101 Регулярные выражения в Perl 101 Ввод и вывод данных 102 Поток управления ЮЗ Прием входных данных и проверка их достоверности 105 Использование языка Perl в качестве фильтра 106 Модули расширения для Peri 107 2.5. Создание сценариев на языке PYTHON 108 Быстрое погружение в языковую среду Python 109 Объекты, строки, числа, списки, словари, кортежи и файлы 111 Пример контроля входных данных 112 Циклы ИЗ 2.6. Передовой опыт создания сценариев 115 2.7. Рекомендуемая литература 117 Основы работы в командной оболочке и написание сценариев в среде bash 117 Регулярные выражения 117 Написание сценариев на языке Perl 117 Написание сценариев на языке Python 117 2-8. Упражнения 118
8 Содержание Глава 3. Запуск и останов системы 119 3.1. Начальная загрузка 119 Главное — активизировать командную оболочку 120 Этапы загрузки 120 Инициализация ядра 121 Конфигурирование аппаратных средств 121 Создание процессов ядра 121 Действия оператора (только в режиме восстановления) 122 Выполнение сценариев запуска системы 123 Завершение процесса загрузки 123 3.2. Загрузка системы на персональном компьютере 124 3.3. GRUB: универсальный загрузчик 125 Параметры ядра 126 Мультисистемная загрузка 127 3.4. Загрузка в однопользовательском режиме 128 Однопользовательский режим при использовании GRUB 128 Однопользовательский режим в архитектуре SPARC 128 Однопользовательский режим на рабочих станциях HP-UX 129 Однопользовательский режим в системах AIX 129 3.5. Работа со сценариями запуска системы 129 Демон init и его уровни выполнения 130 Обзор сценариев запуска 131 Сценарии запуска в системах Red Hat 133 Сценарии запуска в системах SUSE 135 Сценарии запуска Ubuntu и демон Upstart 136 Сценарии запуска в системах HP-UX 137 Запуск систем AIX 138 3.6. Загрузка систем SOLARIS 139 Механизм управления службами в системе Solaris 139 Прекрасный новый мир: загрузка с помощью механизма SMF 142 3.7. Перезагрузка и останов системы 142 Команда shutdown: корректный способ останова системы 143 Команды halt и reboot: более простой способ останова 144 3.8. Упражнения 144 Глава 4. Управление доступом: сила привилегий 145 4.1. Традиционные методы управления доступом в системах UNIX 146 Управление доступом в файловой системе 146 Владение процессом 147 Учетная запись суперпользователя 147 Использование битов “setuid” и “setgid” 148 4.2. Современная организация управления доступом 149 Управление доступом на основе ролей 150 SELinux: Linux-системы с улучшенной безопасностью 151 Возможности POSIX (Linux) 151 Подключаемые модули аутентификации 152 Сетевой протокол криптографической аутентификации Kerberos 152 Списки управления доступом 152 4.3. Управление доступом в реальном мире 153
Содержание 9 Пароль суперпользователя 153 Регистрация под именем root 155 Команда su: замена идентификатора пользователя 155 Утилита sudo: ограниченный вариант команды su 156 Хранилища паролей и их депонирование 159 4.4. О псевдопользователях 160 4.5. Упражнения 161 Глава 5. Управление процессами 163 5.1. Атрибуты процесса 163 Идентификатор процесса (PID) 164 Идентификатор родительского процесса (PPID) 164 Идентификатор пользователя (UID) и текущий идентификатор пользователя (EUID) 165 Идентификатор группы (GID) и текущий идентификатор группы (EGID) 165 Приоритет и фактор уступчивости 166 Управляющий терминал 166 5.2. Жизненный цикл процесса 166 5.3. Сигналы 167 5.4. Отправка сигналов: команда kill 170 5.5. Состояния процесса 171 5.6. Изменение приоритета выполнения: команды nice и renice 172 5.7. Текущий контроль процессов: команда ps 173 5.8. Динамический мониторинг процессов с помощью команд top, prstat и topas 177 5.9. Файловая система /ргос 178 5.10. Отслеживание сигналов и системных вызовов: команды strace, truss и tusc 179 5.11. Процессы, вышедшие из-под контроля 181 5.12. Рекомендуемая литература 182 5.13. Упражнения 182 Глава 6. Файловая система 184 6.1. Имена файлов и каталогов 186 Абсолютные и относительные пути 186 Использование пробелов в именах файлов 186 6.2. Монтирование и демонтирование файловой системы 187 6.3. Организация файловой системы 189 6.4. Типы файлов 192 Обычные файлы 193 Каталоги 193 Файлы символьных и блочных устройств 194 Локальные сокеты 195 Именованные каналы 195 Символические ссылки 195 6.5. Атрибуть! файлов 196 Биты режима 196 Биты setuid и setgid 197 Дополнительный бит 198 Команда 1s: просмотр атрибутов файла 198 Команда chmod: изменение прав доступа 200
10 Содержание Команды chown и chgrp: смена владельца и группы 201 Команда umask: задание стандартных прав доступа 202 Дополнительные флаги в системе Linux 202 6.6. Списки контроля доступа 203 Краткий обзор развития UNIX-списков ACL 204 Реализация списков ACL 205 Системная поддержка списков ACL 205 Обзор POSIXACL 206 Списки NFSv4 ACL 210 6.7. Упражнения 216 Глава 7. Добавление новых пользователей 218 7.1. Файл /etc/passwd 219 Регистрационное имя 220 Зашифрованный пароль 223 Идентификатор пользователя 224 Идентификатор группы по умолчанию 225 Поле GECOS 226 Домашний каталог 226 Регистрационная оболочка 226 7.2. Файлы /etc/shadow и /etc/security/passwd 227 6.3. Файл /etc/group 230 7.4. Подключение пользователей: основные действия 232 Редактирование файлов passwd и group 233 Задание пароля 233 Создание домашнего каталога пользователя и инсталляция конфигурационных файлов 233 Установка прав доступа и прав собственности 235 Назначение каталога для электронной почты 235 Конфигурирование ролей и административных привилегий 235 Заключительные действия 236 7.5. Добавление пользователей с помощью программы useradd 236 Команда useradd в системе Ubuntu 237 Команда useradd в системе SUSE 238 Команда useradd в системе Red Hat 238 Команда useradd в системе Solaris 239 Команда useradd в системе HP-UX 240 Команда useradd в системе AIX 240 Пример использования команды useradd 242 7.6. Добавление пользователей “пакетом” с помощью команды newusers (Linux) 243 7.7. Удаление пользователей 243 7.6. Отключение учетной записи 245 7.9. Управление учетными записями системными средствами 246 7.10. Уменьшение риска с помощью РАМ 247 7.11. Централизация управления учетными записями 247 Протокол LDAP и служба Active Directory 247 Системы “единого входа” 248 Системы управления учетными данными 249 7.12. Рекомендуемая литература 250
Содержание 11 7.13. Упражнения 250 Глава 8. Дисковая память 252 8.1. Добавление диска 253 Инструкции для системы Linux 253 Инструкции для системы Solaris 254 Инструкции для системы HP-UX 254 Инструкции для системы AIX 255 8.2. Аппаратное обеспечение дисковой памяти 255 Жесткие диски 256 Флеш-диски 258 8.3. Интерфейсы устройств хранения данных 259 Интерфейс РАТА 261 Интерфейсы SATA 262 Параллельный интерфейс SCSI 262 Последовательный интерфейс SCSI 265 Что лучше: SCSI или SATA? 265 8.4. Программное обеспечение накопителей 266 8.5. Присоединение и низкоуровневое управление накопителями 269 Верификация инсталляции на уровне аппаратного обеспечения 269 Файлы накопителя 270 Форматирование и плохое управление блоками 273 Безопасное стирание дисков АТА 274 Команда hdparm: параметры диска и интерфейса (Linux) 275 Мониторинг жесткого диска с помощью стандарта SMART 276 8.6. Разбиение диска 278 Традиционное разбиение 279 Разбиение диска в стиле системы Windows 281 GPT: таблица разделов GUID 281 Разбиение дисков в системе Linux 282 Разбиение дисков в системе Solaris 283 Разбиение дисков в системе HP-UX 283 8.7. RAID: избыточные массивы недорогих дисков 283 Программная и аппаратная реализации системы RAID 284 Уровни системы RAID 284 Восстановление диска после сбоя 287 Недостатки конфигурации RAID 5 288 Команда mdadm: программное обеспечение RAID в системе Linux 289 8.8. Управление логическими томами 292 Реализации управления логическими томами 292 Управление логическими томами в системе Linux 294 Управление логическими томами в системе HP-UX 298 Управление логическими томами в системе AIX 300 8.9. Файловые системы 301 Файловые системы Linux: семейство ext 302 Файловые системы HP-UX: VxFS и HFS 303 Файловая система JFS2 в операционной системе AIX 303 Терминология файловой системы 303 Полиморфизм файловых систем 304 F Команда mkfs: форматирование файловых систем 305
12 Содержание Команда fsck: проверка и исправление файловых систем 305 Монтирование файловой системы 306 Настройка автоматического монтирования 307 Монтирование USB-накопителя 310 Включение подкачки 310 8.10. Файловая система ZFS: все проблемы решены 311 Архитектура ZFS 311 Пример: добавление диска в системе Solaris 312 Файловые системы и свойства 313 Наследование свойств 314 Одна файловая система на пользователя 315 Мгновенные копии и клоны 316 Неразмеченные логические тома 318 Распределение файловой системы между NFS, CIFS и SCSI 318 Управление пулом хранения 319 8.11. Сеть хранения данных 320 Сети SAN 322 Протокол iSCSI: интерфейс SCSI на основе протокола IP 323 Загрузка с тома iSCSI 324 Специфика инициаторов iSCSI от разных производителей 324 8.12. Упражнения 328 Глава 9. Периодические процессы 330 9.1. Демон сгоп: системный планировщик 330 9.2. Формат crontab-файлов 331 9.3. Управление crontab-файлами 333 9.4. Использование версии демона Vixie-cron 334 9.5. Стандартные применения демона сгоп 335 Простые напоминания 335 Чистка файловой системы 336 Распространение конфигурационных файлов по сети 337 Ротация журнальных файлов 338 9.6. Упражнения 338 Глава 10. Резервное копирование 339 10.1. Принципы резервного копирования 340 Создавайте резервные копии на центральном компьютере 340 Маркируйте носители 340 Правильно выбирайте периодичность резервного копирования 341 Будьте осмотрительны при выборе архивируемых файловых систем 341 Старайтесь умещать каждодневные архивы на одном носителе 342 Храните носители вне рабочего помещения 342 Защищайте резервные копии 343 Активность файловой системы во время создания архива должна быть низкой 343 Проверяйте состояние своих носителей 344 Определите жизненный цикл носителя 345 Компонуйте данные с учетом резервного копирования 346 Будьте готовы к худшему 346 10.2. Устройства и носители, используемые для резервного копирования 347 Оптические носители: CD_R/RW, DVD±R/RW, DVD RAM и Blu-ray 347
содержание 15 Переносные и съемные жесткие диски Магнитные ленты Малые лентопротяжные устройства: 8-миллиметровые и DDS/DAT Устройства DLT/S-DLT Устройства AIT и SAIT Устройства VXA/VXA-X Устройства LTO Системы с автоматической загрузкой носителей (автозагрузчики, ленточные массивы и библиотеки) Жесткие диски Интернет и службы облачного резервирования данных Типы носителей Что покупать Ю.З. Экономия пространства и времени с помощью инкрементного архивирования Простая схема Умеренная схема 10.4. Команда dump: настройка режима резервирования Архивирование файловых систем Команда restore: восстановление файлов из резервных копий Восстановление файловых систем Восстановление системы на новом оборудовании 10.5. Архивирование и восстановление при модификации операционной системы 10.6. Другие архиваторы Команда tar упаковка файлов Команда dd: манипулирование битами Резервирование файловых систем ZFS 10.7. Запись нескольких архивов на одну ленту 10.8. Программа Bacula Модель, используемая программой Bacula Настройка программы Bacula Установка базы данных и демонов Bacula Конфигурирование демонов Bacula Разделы конфигурации Конфигурирование демона управления: файл bacula-dir.conf Конфигурирование демона хранения: файл bacula-sd.conf Конфигурирование консоли: файл bconsole.conf Установка и конфигурирование демона управления файлами клиента Запуск демонов Bacula Добавление носителей в пулы Выполнение архивирования вручную Выполнение задания восстановления Архивирование клиентов Windows Мониторинг конфигураций программы Bacula Советы по использованию программы Bacula Альтернатива программе Bacula 10-9. Коммерческие системы резервного копирования ADSM/TSM Veritas NetBackup EMC NetWbrker Прочие программы 348 349 349 349 350 350 351 351 351 352 352 353 354 355 355 356 356 359 363 363 363 364 365 366 367 367 369 369 370 371 372 375 377 377 378 378 378 379 382 382 383 383 384 384 385 385 386
14 Содержание 10.10. Рекомендуемая литература 386 10.11. Упражнения 386 Глава 11. Система Syslog и журнальные файлы 388 11.1. Обнаружение файлов регистрации 389 Специальные журнальные файлы 390 Особенности систем 392 11.2. Syslog: система регистрации событий 393 Архитектура системы Syslog 394 Конфигурирование демона syslogd 394 Примеры конфигурационных файлов 398 Отладка системы Syslog 400 Альтернатива системе Syslog 400 Журнальная регистрация на уровне ядра и на этапе начальной загрузки 401 11.3. Регистрация сообщений и обработка ошибок в системе AIX 402 Конфигурация системы Syslog в среде AIX 404 11.4. Утилита logrotate: управление журнальными файлами 405 11.5. Поиск полезной информации в журнальных файлах 407 11.6. Методы обработки журнальных файлов 408 11.7. Упражнения 410 Глава 12. Управление программным обеспечением и конфигурацией 412 12.1. Инсталляция систем Linux и OpenSolaris 413 Загрузка по сети на персональном компьютере 413 Конфигурирование протокола РХЕ в Linux 414 Дистанционная загрузка на специализированных компьютерах 414 Использование Kickstart — автоматизированного инсталлятора Red Hat Enterprise Linux 415 Использование AutoYaST: автоматизированный инсталлятор SUSE 417 Автоматизированная инсталляция систем Ubuntu 418 12.2. Инсталляция Solaris 420 Сетевые инсталляции с помощью JumpStart 421 Сетевые инсталляции с помощью автоматизированного инсталлятора 425 12.3. Инсталляция HP-UX 426 Автоматизация инсталляций Ignite-UX 429 12.4. Инсталляция системы AIX с помощью сетевого менеджера инсталляции 429 12.5. Управление пакетами 430 12.6. Управление Linux-пакетами 431 Команда rpm: управление пакетами RPM 432 Команда dpkg: управление пакетами .deb в системе Ubuntu 433 12.7. Использование высокоуровневых систем управления пакетами в Linux 434 Хранилища пакетов 435 Служба Red Hat Network 436 APT: усовершенствованное средство управления пакетами 437 Конфигурирование apt-get 438 Создание локального зеркала хранилища 439 Автоматизация работы утилиты apt-get 440 Система yum: управление выпусками для RPM 441 Система управления пакетами Zypper для SUSE: теперь еще более мощная! 441
Содержание 15 12.8. Управление пакетами для систем UNIX 442 Управление пакетами в Solaris 443 Управление пакетами в HP-UX 444 Управление программами в AIX 446 12.9. Управление изменениями 446 Создание резервных файлов 447 Формальные системы управления изменениями 447 Система Subversion 448 Система Git 450 12.10. Локализация и конфигурирование программного обеспечения 454 Организация локализации 454 Тестирование 456 Локальная компиляция 456 Распространение локализаций 457 12.11. Использование средств управления конфигурацией 458 Утилита cfengine: компьютерная иммунная система 458 LCFG: крупномасштабная система конфигурирования 459 Template Tree 2: помощник cfengine 459 DMTF/CIM: общая информационная модель 460 12.12. Организация совместного использования программ через nfs 460 Пространства имен пакетов 461 Управление зависимостями 462 Сценарии упаковщика 462 12.13. Рекомендуемая литература 463 12.14. Упражнения 463 Глава 13. Драйверы и ядро 464 13.1. Адаптация ядра 465 13.2. Драйверы и файлы устройств 466 Файлы и номера устройств 467 Создание файлов устройств 468 Соглашения об именовании устройств 469 Сравнение пользовательских ядер с загружаемыми модулями 469 13.3. Конфигурирование ядра Linux 470 Конфигурирование параметров ядра linux 470 Сборка ядра Linux 472 Не чините то, что еще не поломано 472 Конфигурирование параметров ядра 472 Компиляция ядра 47 3 Добавление драйвера устройства в Linux 474 13.4. Конфигурирование ядра Solaris 475 Пространство ядра Solaris 476 Конфигурирование ядра с помощью файла /etc/system 477 Добавление в систему Solaris драйверов устройств 478 Отладка Solaris-конфигурации 478 13.5. Конфигурирование ядра HP-UX 480 13.6. Управление ядром AIX 480 Администратор объектных данных 481 Настройка ядра 482 13.7. Загружаемые модули ядра 483
16 Содержание Загружаемые модули ядра в Linux 483 Загружаемые модули ядра в Solaris 485 13.8. Linux-менеджер устройств udev — полезно и приятно 486 Файловая система sysfs: доступ к “сердцу” устройств в Linux 486 Исследование устройств с помощью команды udevadm 487 Создание правил и постоянных имен 488 13.9. Рекомендуемая литература 491 13.10. Упражнения 492 Часть II. Работа в сетях 493 Глава 14. Сети ТСРДР 495 14.1. Система TCP/IP и Интернет 495 Кто сегодня управляет Интернетом 496 Сетевые стандарты и документация 497 14.2. Дорожная карта сети 498 Версии IPv4 и IPv6 499 Пакеты и их инкапсуляция 500 Стандарты формирования фреймов Ethernet 501 14.3. Адресация пакетов 502 Аппаратная адресация (МАС) 502 IP-адресация 503 “Адресация” имен машин 504 Порты 504 Типы адресов 504 14.4. IP-адреса 505 Классы адресов в протоколе IPv4 505 Подсети 506 Трюки и инструменты для арифметических вычислений, связанных с подсетями 507 CIDR: протокол бесклассовой междоменной маршрутизации 508 Выделение адресов 509 Частные адреса и система NAT 510 Адресация в стандарте IPv6 511 14.5. Маршрутизация 513 Таблицы маршрутизации 513 Директивы переадресации протокола ICMP 515 14.6. ARP: протокол преобразования адресов 515 14.7. DHCP: протокол динамического конфигурирования узлов 516 Программное обеспечение DHCP 517 Схема работы DHCP 518 Программное обеспечение DHCP, созданное организацией ISC 518 14.8. Вопросы безопасности 520 Перенаправление IP-пакетов 520 Директивы переадресации протокола ICMP 520 Маршрутизация “от источника” 520 Широковещательные ICMP-пакеты и другие виды направленных широковещательных сообщений 521 Подмена IP-адресов 521 Встроенные брандмауэры 522 Виртуальные частные сети 522
Содержание 17 14.9. PPP: протокол двухточечного соединения 523 14.10. Основы конфигурирования сети 524 Присвоение сетевых имен и IP-адресов 525 Команда ifconfig: конфигурирование сетевых интерфейсов 526 Параметры сетевого оборудования 528 Команда route: конфигурирование статических маршрутов 529 Конфигурирование DNS 530 14.11. Сетевое конфигурирование в различных системах 531 14.12. Сетевое конфигурирование в системе Linux 532 Демон NetworkManager 532 Сетевое конфигурирование в системе Ubuntu 533 Сетевое конфигурирование в системе SUSE 534 Сетевое конфигурирование в системе Red Hat 535 Настройка сетевого оборудования в системе Linux 536 Опции протокола Linux TCP/IP 537 Переменные ядра, связанные с безопасностью 540 Система Linux NAT и фильтрация пакетов 540 14.13. Работа в сети под управлением системы Solaris 541 Основная сетевая конфигурация системы Solaris 541 Примеры конфигураций системы Solaris 543 Конфигурирование протокола DHCP в системе Solaris 544 Команда ndd: протокол TCP/IP и настройка интерфейса в системе Solaris 545 Безопасность в системе Solaris 546 Брандмауэры и фильтрация в системе Solaris 546 Механизм NAT в системе Solaris 547 Особенности сетевого конфигурирования 548 14.14. Работа в сети под управлением системы HP-UX 548 Базовое конфигурирование сетей в системе HP-UX 548 Примеры конфигураций в системе HP-UX 549 Конфигурирование протокола DHCP в системе HP-UX 551 Динамическое переконфигурирование и настройка в системе HP-UX 551 14.15. Работа в сети под управлением системы AIX 553 Команда по: настройка сетевых параметров в системе AIX 555 14.16. Рекомендуемая литература 555 14.17. Упражнения 557 Кгава 15. Маршрутизация $58 15.1. Подробнее о маршрутизации пакетов 555 15.2. Демоны и протоколы маршрутизации 561 Дистанционно-векторные протоколы 562 Топологические протоколы 563 Метрики стоимости 563 Внутренние и внешние протоколы 564 15.3. Основные протоколы маршрутизации 564 Протоколы RIP и RIPng 565 Протокол OSPF 566 Протокол EIGRP 566 IS-IS: протокол маршрутизации между промежуточными системами 567 Протоколы RDP и NDP 567 Протокол BGP 567
18 Содержание 15.4. Выбор стратегии маршрутизации 567 15.5. Демоны маршрутизации 569 Демон route: устаревшая реализация в протоколе RIP 569 Демон gated: первый многопротокольный демон маршрутизации 570 Пакет Quagga: основной демон маршрутизации 570 Демон ramd: многопротокольная система маршрутизации для HP-UX 571 Маршрутизатор XORP 571 Специфика поставщиков 572 15.6. Маршрутизаторы Cisco 572 15.7. Рекомендуемая литература 575 15.8. Упражнения 576 Глава 16. Сетевые аппаратные средства 577 16.1. Технология Ethernet: сетевая панацея 578 Как работает Ethernet 579 Топология Ethernet 580 Неэкранированная витая пара 580 Оптическое волокно 582 Соединение и расширение сетей Ethernet 583 16.2. Беспроводной стандарт: локальная сеть для кочевников 587 Беспроводные коммутаторы и облегченные точки беспроводного доступа 589 16.3. DSL и кабельные модемы: “последняя миля” 589 16.4. Тестирование и отладка сетей 590 16.5. Прокладка кабелей 591 Неэкранированная витая пара 591 Офисные точки подключения 591 Стандарты кабельных систем 592 16.6. Проектирование сетей 593 Структура сети и архитектура здания 593 Расширение сетей 594 Перегрузка 594 Обслуживание и документирование 594 16.7. Управление сетью 594 16.8. Рекомендуемые поставщики 595 Кабели и разъемные соединения 595 Тестовые приборы 596 Маршрутизаторы/коммутаторы 596 16.9. Рекомендуемая литература 596 16.10. Упражнения 596 Глава 17. Система доменных имен 597 17.1. Основные задачи системы DNS 598 Управление системой DNS 599 17.2. Как работает система DNS 599 Записи о ресурсах 600 Делегирование 600 Кеширование и эффективность 601 Неоднозначные ответы 602 17.3. DNS для нетерпеливых: подключение нового компьютера 602
содержание 19 Добавление новой машины в систему DNS Настройка конфигурации клиента DNS 602 605 17.4. Серверы имен 607 Авторитетные и кеширующие серверы 608 Рекурсивные и нерекурсивные серверы 609 17.5. Пространство имен DNS 610 Регистрация домена второго уровня 611 Создание собственных поддоменов 612 17.6. Разработка собственной среды DNS 612 Управление пространством имен 612 Авторитетные серверы 613 Кеширующие серверы 614 Требования к аппаратному обеспечению 614 Безопасность 615 Итоги 615 17.7. Что нового в системе DNS 616 17.8. База данных DNS 618 Команды в файлах зон 619 Записи о ресурсах 620 Запись SOA 623 Записи NS Записи А 625 6М Записи PTR 626 Записи MX 627 Записи CNAME 628 Специальное применение записей CNAME 629 Записи SRV 630 Записи TXT 632 Записи ресурсов IPv6 632 Записи SPF 633 Записи DKIM и ADSP 635 Записи о ресурсах SSHFP 638 Записи о ресурсах DNSSEC 639 Связующие записи: связи между зонами 639 17.9. Программное обеспечение системы BIND 641 Определение версии 641 Компоненты системы BIND 643 Файлы конфигурации 643 Инструкция include 645 Инструкция options 646 Инструкция acl 652 Инструкция key (TSIG) 653 Инструкция trusted-keys 653 Инструкция server 654 Инструкция masters 655 Инструкция logging 655 Инструкция statistics 655 Инструкция zone 656 Инструкция controls для команды rdnc 659 Расщепление DNS и инструкция view 660
20 Содержание 17.10. Примеры конфигурации системы BIND 661 Зона локального узла 662 Небольшая компания, предоставляющая консалтинговые услуги в области безопасности 663 Консорциум The Internet Systems Consortium (isc.org) 666 17.11. Программное обеспечение NSD/Unbound 668 Инсталляция и конфигурирование системы NSD 668 Пример конфигурации системы NSD 670 Запуск демона nsd 675 Инсталляция и конфигурирование сервера Unbound 676 17.12. Обновление файлов зон 682 Передача зоны 683 Динамические обновления в системе BIND 684 17.13. Вопросы безопасности 686 Еще раз о списках управления доступом в сервере BIND 687 Открытые распознаватели 688 Работа в виртуальном окружении chroot 689 Безопасные межсерверные взаимодействия посредством технологий TSIG и TKEY689 Настройка технологии TSIG для сервера BIND 690 Механизм TSIG на сервере NSD 692 Технология DNSSEC 692 Правила протокола DNSSEC 696 Записи о ресурсах DNSSEC 697 Настройка протокола DNSSEC 698 Генерирование пар ключей 699 Подписание зоны 701 Цепочка доверия в протоколе DNSSEC 704 Сервер DLV: динамическая проверка доменов 705 Смена ключей DNSSEC 706 Инструменты DNSSEC 707 Отладка протокола DNSSEC 709 17.14. Microsoft и DNS 711 17.15. Тестирование и отладка 711 Журнальная регистрация в пакете BIND 712 Журнальная регистрация в пакетах NSD и Unbound 717 Управляющие программы сервера имен 718 Сбор статистических данных 720 Отладка с помощью команды dig 721 Некорректное делегирование 722 Инструменты для проверки корректности системы DNS 723 Производительность системы 725 17.16. Специфика различных дистрибутивов 725 Специфика системы Linux 726 Специфика системы Solaris 728 Специфика системы HP-UX 729 Специфика системы AIX 730 17.17. Рекомендуемая литература 731 Списки рассылки и новостные группы 731 Книги и другая документация 731 Ресурсы в Интернете 732
содержание 21 Документы RFC 732 17.18. Упражнения 733 Diaea 18. Сетевой протокол Network File System 735 18.1. Введение в протокол NFS 735 Проблемы, связанные с состоянием 736 Проблемы производительности 736 Безопасность 736 18.2. Серверная часть NFS 737 Версии и история протокола 737 Транспортные протоколы 738 Состояние 738 Экспорт файловой системы 738 Блокировка файлов 739 Вопросы безопасности 740 Идентифицирующее отображение в версии 4 741 Учетные записи root и nobody 742 Производительность версии 4 743 Дисковые квоты 743 18.3. Серверная часть протокола NFS 744 Команда share и файл dfstab (Solaris, HP-UX) 745 Команда exports и файл exports (Linux, AIX) 747 Файл exports в системе AIX 747 Файл exports в системе Linux 748 Демон nfsd: обслуживание файлов 750 18.4. Клиентская часть протокола NFS 751 Монтирование файловых систем NFS на этапе начальной загрузки 753 Ограничения на выбор порта 754 18.5 Идентифицирующее отображение в протоколе NFS 4 755 18.6. Команда nfsstat: отображение статистики NFS 755 18.7. Специализированные файловые серверы NFS 756 18.8. Автоматическое монтирование 757 Таблицы косвенных назначений 758 Таблицы прямых назначений 759 Главные таблицы 759 Исполняемые таблицы 760 Видимость демона automount 760 Реплицированные файловые системы и демон automount 761 Автоматическое монтирование (V3; все, кроме Linux) 761 Специфика системы Linux 762 18.9. Рекомендуемая литература 762 18.10. Упражнения 763 йава 19. Совместное использование системных файлов 764 19.1. Предмет совместного использования 765 19.2. Копирование файлов 766 Использование сервера NFS 766 Сравнение модели принудительной рассылки с моделью рассылки по запросу 767 Утилита rdist: принудительная рассылка файлов 767
22 Содержание Утилита rsync: более безопасная рассылка файлов 770 Рассылка файлов по запросу 772 19.3. LDAP: упрощенный протокол доступа к каталогам 773 Структура данных LDAP 774 Особенности LDAP 775 Документация и спецификации LDAP 776 OpenLDAP: традиционный LDAP-сервер с открытым исходным кодом 776 389 Directory Server: альтернативный LDAP-сервер с открытым исходным кодом 777 LDAP вместо /etc/passwd и /etc/group 778 Создание LDAP-запросов 779 LDAP и безопасность 780 19.4. NIS: сетевая информационная служба 781 Модель NIS 781 Схема работы NIS 782 Безопасность NIS 784 19.5. Задание приоритетов для источников административной информации 784 Демон nscd: кеширование результатов поиска 785 19.6. Рекомендуемая литература 786 19.7. Упражнения 786 Глава 20. Электронная почта 787 20.1. Системы электронной почты 788 Пользовательские агенты 789 Агенты представления 790 Транспортные агенты 791 Локальные агенты доставки 791 Хранилища сообщений 792 Агенты доступа 792 Так много компонентов, так мало времени 793 20.2. Структура почтового сообщения 793 Заголовки почтовых сообщений 793 20.3. Протокол SMTP 795 Вы прислали мне привет 796 Коды ошибок протокола SMTP 797 Аутентификация SMTP 797 20.4. Принципы организации электронной почты 798 Почтовые серверы 799 20.5. Почтовые псевдонимы 802 Загрузка списков рассылки из файла 804 Направление почты в файл 804 Направление почты в программу 805 Примеры псевдонимов 805 Хешированная база данных псевдонимов 806 Списки рассылки и программы для работы с ними 806 Программы для работы со списками рассылки 806 20.6. Сканирование содержимого: спам и вредоносные программы 807 Спам 808 Подделки * 809 Конфиденциальность сообщений 809 Фильтрация спама 809
Содержание 23 Когда следует фильтровать 810 “Серые” списки/DCC 810 Программа SpamAssassin 811 Черные списки 812 Белые списки 812 Фильтрация почты 813 Технология SPF и спецификации Sender ID 813 Системы DomainKeys, DKIM и ADSP 814 Функциональные возможности транспортных агентов по борьбе со спамом 815 Программа MailScanner 815 Интерфейс amavisd-new 816 Проверка эффективности сканирования с помощью транспортных агентов 819 20.7. Конфигурация электронной почты 820 20.8. Почтовый агент sendmail 821 Файл переключения 822 Запуск программы sendmail 823 Почтовые очереди 824 20.9. Конфигурация программы sendmail 825 Препроцессор т4 825 Фрагменты конфигурации программы sendmail 8 26 Конфигурационный файл, построенный на основе эталонного файла с расширением .тс 827 20.10. Примитивы конфигурации программы sendmail 828 Таблицы и базы данных 828 Обобщенные макросы и функциональные возможности 829 Конфигурация клиентов 835 Параметры конфигурации 835 Средства программы sendmail для борьбы со спамом 837 Ретрансляция 838 Дроссели, скорость и ограничения на количество соединений 840 Конфигурирование почтовых фильтров в программе sendmail 841 Соединение сканера amavisd и программы sendmail 842 20.11. Безопасность и программа sendmail 843 Владельцы файлов 843 Права доступа 844 Безопасная пересылка почты в файлы и программы 845 Опции безопасности 846 Выполнение программы sendmail в виртуальном каталоге (для настоящих параноиков) 847 Отражение атак типа “отказ от обслуживания” 847 SASL: простой протокол аутентификации и защиты 848 TLS: безопасность транспортного уровня 848 20.12. Производительность программы sendmail 849 Режимы доставки 849 Группы очередей и разбивка конвертов 849 Обработчики очередей 850 Контроль средней загруженности 850 Обработка недоставленных сообщений 850 Настройка ядра г 851 20.13. Сбор статистических данных, тестирование и отладка 853
24 Содержание Мониторинг очереди 853 Журнальная регистрация 854 20.14. Почтовый агент Exim 855 Инсталляция почтового сервера EXIM 856 Загрузка почтового сервера Exim 857 Утилиты почтового сервера Exim 858 Язык конфигурации программы Exim 859 Файл конфигурации программы Exim 859 Глобальные параметры 861 Сканирование содержимого на этапе применения списков управления доступом 866 Аутентификаторы 867 Маршрутизаторы 868 Маршрутизатор accept 869 Маршрутизатор dnslookup 870 Транспортные механизмы 872 Конфигурация retry 873 Конфигурация перезаписи 873 Функция локального сканирования 873 Сочетание программ amavisd и Exim 873 Регистрация 4 874 Отладка 875 20.15. Почтовый агент Postfix 876 Архитектура системы Postfix 876 Безопасность 878 Команды и документация системы Postfix 878 Конфигурация системы Postfix 879 Виртуальные домены 883 Управление доступом 885 Борьба со спамом и вирусами 888 Фильтрация содержимого с помощью программы amavisd 89.0 Отладка 891 20.16. Конфигурация механизма DKIM 893 Технология DKIM: DomainKeys Identified Mail 893 Почтовые фильтры DKIM 894 Конфигурация DKIM в программе amavisd-new 896 Технология DKIM в системе sendmail 897 Технология DKIM в системе Exim 898 Технология DKIM в системе Postfix 900 20.17. Интегрированные почтовые системы 900 20.18. Рекомендуемая литература 901 Общие вопросы по борьбе со спамом 901 Литература по программе sendmail 902 Литература о системе Exim 902 Литература о системе 902 Документы RFC 903 20.19. Упражнения 903 Упражнения, связанные с программой sendmail 904 Упражнения, связанные с системой Exim 905 Упражнения, связанные с системой Postfix 905
Содержание 25 Глава 21. Управление сетями 907 21.1. Поиск неисправностей в сетях 908 21.2. Команда ping: проверка доступности компьютера 909 21.3. Инструмент SmokePing: сбор статистики в работе команды ping во времени 911 21.4. Команда traceroute: трассировка IP-пакетов 912 21.5. Команда netstat: получение информации о состоянии сети 915 Контроль состояния сетевых соединений 915 Отслеживание состояния сетевых соединений 917 Идентификация прослушивающих сетевых служб 918 Проверка таблицы маршрутизации 919 Просмотр статистических данных функционирования различных сетевых протоколов 919 21.6. Проверка функционирования интерфейса в реальном времени 921 21.7. Анализаторы пакетов 922 Утилита tcpdump: стандартный анализатор 923 Утилиты Wireshark и TShark: усовершенствованный вариант tcpdump 924 21.8. Служба Netalizr Института ICSI 926 21.9. Протоколы управления сетями 926 21.10. SNMP: простой протокол управления сетями 928 Структура протокола SNMP 928 Операции протокола SNMP 930 RMON: база MIB для дистанционного мониторинга 930 21.11. Агент NET-SNMP 931 21.12. Программы управления сетями 932 Команды пакета NET-SNMP 932 Сбор и накопление данных протокола SNMP 933 Nagios: событийная служба мониторинга 934 Совершенный пакет для мониторинга: поиски продолжаются 935 Коммерческие системы сетевого управления 936 21.13. Протокол NetFlow: мониторинг соединений 937 Мониторинг данных протокола NetFlow с помощью утилит nfdump и NfSen 937 Настройка протокола NetFlow для маршрутизатора Cisco router 939 21.14. Рекомендуемая литература 940 21.15. Упражнения 941 Глава 22. Безопасность 943 22.1. Безопасна ли система UNIX 944 22.2. Слабые места в системе защиты 945 Человеческий фактор 945 Ошибки в программах 946 Ошибки конфигурации 947 22.3. Ключевые аспекты безопасности 947 Программные “заплаты” 948 Ненужные службы 948 Удаленная регистрация событий 949 Резервные копии 949 Вирусы и черви 949 Троянские программы * 950 Руткиты 951
26 Содержание Фильтрация пакетов 951 Пароли 951 Бдительность 951 Общие принципы защиты 952 22.4. Пароли и учетные записи пользователей 952 Устаревание паролей 953 Групповые и совместно используемые учетные записи 954 Пользовательские оболочки 954 Привилегированные учетные записи 954 22.5. Модули РАМ: украшение или чудо аутентификации 954 Системная поддержка для моделей РАМ 955 Конфигурация модулей РАМ 955 Подробный пример конфигурации системы Linux 958 22.6. Программы с установленным битом SETUID 959 22.7. Эффективное использование команды chroot 960 22.8. Инструментальные средства защиты 961 Команда пшар: сканирование сетевых портов 961 Nessus: сетевой сканер следующего поколения 962 John the Ripper: средство для выявления слабых паролей 963 Команда hosts_access: управление доступом к узлу 964 Вго: программная система для распознавания вторжения в сеть 964 Snort: популярная программная система для распознавания проникновения в сеть 965 OSSEC: система для распознавания вторжения в сеть на уровне узла 966 22.9. Мандатное управление доступом 969 Система Linux с усиленной системой безопасности (SELinux) 969 22.10. Системы криптографической защиты 970 Kerberos: унифицированный подход к сетевой безопасности 971 PGP: высокая конфиденциальность 972 SSH: безопасная оболочка 972 Пакет Stunnel 976 22.11. Брандмауэры 978 Брандмауэры, фильтрующие пакеты 979 Принципы фильтрации служб 979 Брандмауэры, осуществляющие инспекцию пакетов с отслеживанием состояния соединений 980 Насколько безопасны брандмауэры 981 22.12. Особенности брандмауэров в системе Linux 981 Правила, цепочки и таблицы 982 Целевые директивы для правил 982 Настройка команды iptables в качестве брандмауэра 983 Полный пример 983 22.13. Модуль IPFilter для систем UNIX 985 22.14. Виртуальные частные сети 988 Туннели IPSEC 989 Так ли уж нужны виртуальные частные сети 989 22.15. Сертификация и стандарты 989 Сертификации v 990 Стандарты безопасности 991 22.16. Источники информации по вопросам обеспечения безопасности 993
Содержание 27 Организация CERT 993 Сервер SecurityFocus.com и список рассылки BugTraq 994 Блог Брюса Шнайера 994 Организация SANS 994 Информационные ресурсы отдельных дистрибутивов 995 Другие списки рассылки и веб-сайты 996 22.17. Что нужно делать в случае атаки на сервер 996 22.18. Рекомендуемая литература 998 22.19. Упражнения 999 Глава 23. Веб-хостинг 1001 23.1. Основы веб-хостинга 1001 Обнаружение ресурсов в сети веб 1002 Унифицированные указатели ресурсов 1002 Принцип работы HTTP 1003 Генерирование содержимого “на лету” 1004 Серверы приложений 1005 Распределение нагрузки 1006 23.2. Инсталляция НТТР-сервера 1008 Выбор сервера 1008 Инсталляция сервера Apache 1009 Конфигурирование сервера Apache 1010 Запуск сервера Apache 1011 Анализ регистрационных файлов 1011 Высокопроизводительный хостинг 1011 23.3. Виртуальные интерфейсы 1012 Конфигурирование виртуальных интерфейсов 1013 Передача серверу Apache информации о виртуальном интерфейсе 1015 23.4. Протокол Secure Sockets Layes 1016 Генерирование файла Certificate Signing Request 1016 Конфигурация веб-сервера Apache для использования протокола SSL 1018 23.5. Кеширование и прокси-серверы 1018 Использование кеша Squid и прокси-сервера 1019 Инсталляция сервера Squid 1020 Настройка обратного прокси с помощью веб-сервера Apache 1020 23.6. Расширение возможностей 1022 Облачные вычисления 1022 Хостинг совместного размещения серверов 1022 Сети для распределения контента 1023 23.7. Упражнения 1023 Насть Hi. Разное 1025 Глава 24. Виртуализация 1027 24.1. Виртуальный жаргон 1028 Полная виртуализация 1029 Паравиртуализация 1029 Виртуализация на основе операционной системы 1030 Естественная виртуализация * 1031 Облачные вычисления 1031
28 Содержание Динамическая миграция 1032 Сравнение технологий виртуализации 1032 24.2. Преимущества виртуализации 1032 24.3. Практичный подход 1033 24.4. Виртуализация с помощью системы linux 1035 Введение в платформу Хеп 1035 Основы платформы Хеп 1036 Инсталляция гостя на платформе Хеп с помощью программы virt-install 1037 Динамическая миграция на платформе Хеп 1038 Платформа KVM 1039 Инсталляция платформы KVM и ее использование 1040 24.5. Зоны и контейнеры системы solans 1042 24.6. Разделы рабочей нагрузки в системе AIX 1045 24.7. Программное обеспечение Integrity Virtual Machines в системе HP-UX 1047 Создание и инсталляция виртуальных машин 1047 24.8. VMware: операционная система со своими собственными правами 1049 24.9. Веб-службы компании Amazon 1049 24.10. Рекомендуемая литература 1054 24.11. Упражнения 1054 Глава 25. Система X Window System 1055 25.1. Диспетчер дисплеев 1057 25.2. Процесс запуска Х-приложения 1058 Переменная окружения DISPLAY 1059 Аутентификация клиентов 1060 Перенаправление соединений с помощью протокола SSH 1061 25.3. Конфигурирование Х-сервера 1063 Раздел Device 1065 Раздел Monitor 1065 Раздел Screen 1066 Раздел InputDevice 1066 Раздел ServerLayout 1068 Утилита xrandr: конфигуратор Х-сервера 1068 Установка режима ядра 1069 25.4. Устранение неполадок и отладка Х-сервера 1070 Специальные комбинации клавиш в системе X 1070 Когда с Х-сервером творится что-то неладное 1070 25.5. Краткое замечание о настольных средах 1072 KDE 1073 GNOME 1073 Что лучше: GNOME или KDE? 1074 25.6. Рекомендуемая литература 1074 25.7. Упражнения < 1074 Глава 26. Печать 1076 26.1. Архитектура системы печати 1077 Основные системы печати 1077 Очереди печати 1078 26.2. Система печати CUPS 1078
Содержание 29 Интерфейсы для системы печати 1078 Очередь на печать 1079 Множество принтеров 1080 Экземпляры принтеров 1080 Сетевая печать 1080 Фильтры 1081 Управление сервером CUPS 1082 Настройка сетевого сервера печати 1083 Автоматическое конфигурирование принтера 1083 Конфигурирование сетевых принтеров 1084 Примеры конфигурирования принтеров 1084 Создание класса принтеров 1085 Отключение принтера 1085 Другие связанные с конфигурированием задачи 1086 26.3. Печать в настольных системах 1087 Документы kprinter: printing 1088 Konqueror и печать 1088 26.4. Система печати System V 1089 Обзо р 1089 Пункты назначения и классы 1090 Краткое описание команды 1р 1090 Команды Ipsched и Ipshut: начало и конец печати 1091 Команда Ipadmin: конфигурирование среды печати 1091 Примеры использования команды Ipadmin 1094 Команда Ipstat: получение информации о состоянии системы печати 1094 Команда cancel: удаление заданий печати 1095 Команды accept и reject: управление очередью печати 1095 Команды enable и disable: управление печатью 1096 Команда Ipmove: перемещение заданий ~ 1096 Интерфейсные программы 1096 Что делать, если система печати вышла из строя 1097 26.5. Печать BSD и AIX 1098 Обзор архитектуры системы BSD 1098 Управление средой печати 1099 Демон Ipd: буферизация заданий на печать 1100 Команда 1рг: выдача заданий на печать 11 ® Команда Ipq: просмотр очереди печати 1100 Команда Iprm: удаление заданий на печать 1101 Команда 1рс: внесение административных изменений 1101 Файл /etc/printcap 1103 Переменные файла printcap 1104 26.6. Долгая странная история 1108 История печати и появления систем печати 1108 Разнообразие принтеров 1109 Основные программы печати 1110 2«.8. Языки принтеров 1111 PostScript 1112 PCL 1П2 pdf шз XPS 1113
30 Содержание PJL 1114 Драйверы принтеров и как они обрабатывают PDL-языки 1114 26.9. Файлы PPD 1115 26.10. Форматы бумаги 1116 26.11. Практические советы 1118 Выбор принтера 1118 GDI-принтеры 1119 Двусторонняя печать 1119 Другие аксессуары для принтера 1120 Принтеры с последовательным и параллельным интерфейсом 1120 Сетевые принтеры 1121 Другие советы 1121 26.12. Советы по выявлению проблем 1124 Повторный запуск демона печати 1125 Регистрационные журналы 1125 Проблемы с прямой печатью 1125 Проблемы с печатью в сети 1126 Проблемы с распространением 1127 26.13. Рекомендуемая литература 1127 26.14. Упражнения 1127 Глава 27. Центры обработки данных 1129 27.1. Уровни надежности центров обработки данных 1130 27.2. Терморегуляция 1131 Теплые и холодные отсеки 1133 Влажность 1134 Мониторинг окружающей среды 1135 27.3. Электропитание 1135 Требования к электроснабжению стоек 1136 Удаленное управление 1137 27.4. Стойки 1138 27.5. Инструменты 1138 27.6. Рекомендованная литература 1139 27.7. Упражнения 1139 Глава 28. Экологичные информационные технологии 1141 28.1. Введение в экологичные информационные технологии 1142 28.2. Экологическая пирамида 1144 28.3. Стратегии разработки экологичных информационных технологий: центр обработки данных 1144 Консолидация приложений 1145 Консолидация серверов 1146 Сеть S AN 1147 Серверная виртуализация 1147 Только самые необходимые серверы 1148 Использование детализированных данных и планирование потребления 1148 Конфигурация серверов, оптимизированная по потреблению энергии 1148 Облачные вычисления 1150 Свободное охлаждение 1150
содержание_______________________________________________________________ Эффективное охлаждение центра обработки данных 1151 Режим ограниченной функциональности во время простоя 1151 Продление срока эксплуатации оборудования 1151 Более высокая температура в центре обработки данных 1152 Энергосберегающее оборудование 1152 28 4 Экологические информационные стратегии: рабочее место пользователя 1153 28 5 Компании, поддерживающие экологичные информационные технологии 1154 28.6. Упражнения 1155 Глава 29. Анализ производительности 1157 29.1 • Способы повышения производительности 1159 29.2. Факторы, влияющие на производительность 1160 29.3. Как анализировать проблемы производительности 1161 29.4. Проверка производительности системы 1162 Инвентаризуйте свое оборудование 1162 Сбор данных о производительности 1166 Анализ использования центрального процессора 1166 Управление памятью в системе 1168 Анализ использования памяти 1170 Анализ операций обмена с диском 1172 Утилита xdd: анализ производительности дисковой подсистемы 1174 Команда sar: сбор статистических данных и генерирование отчетов по ним 1174 nmon и nmon_analyser: мониторинг производительности в системе AIX 1175 Выбор Lmux-планировщика ввода-выЙОда 1175 Программа oprofile: универсальный профилировщик системы Linux 1176 29.5. Помогите! Моя система почти остановилась! 1177 29.6. Рекомендуемая литература 1178 29.7. Упражнения 1179 Глава 30. Взаимодействие с системой Windows 1180 30.1. Вход в систему UNIX из Windows 1180 30.2. Получение доступа к удаленным настольным средам 1181 Запуск сервера X Server на компьютере Windows 1182 VNC: система виртуальных сетей 1183 Протокол RDP в системе Windows 1184 30.3. Запуск системы Windows и Windows-приложений 1184 Двухвариантная загрузка и почему ею не стоит пользоваться 1185 Альтернативы Microsoft Office 1185 30 S Использование утилит командной строки в системе Windows 1186 ’ овместимость Windows со стандартами электронной почты и веб 1187 овместное использование файлов при помощи Samba и CIFS 1187 ЬашЬа: сервер CIFS для UNIX 1188 Установка Samba 1189 Кодирование имен файлов 4190 Аутентификация пользователей 1191 овместное использование основных файлов 1191 Фупповые ресурсы 1192 Розрачная переадресация при помощи MS DFS 1193 Рограмма smbclient: простой клиент CIFS 1194
32 Содержание 30.7. Совместное использование принтеров при помощи Samba 1195 Установка драйвера принтера из системы Windows 1197 Инсталляция принтера из командной строки 1197 30.8. Отладка сервера Samba 1198 30.9. Аутентификация службы Active Directory 1200 Подготовка к интеграции службы Active Directory 1201 Конфигурирование протокола Kerberos для интеграции службы Active Directory 1202 Программа Samba как член домена Active Directory 1203 Конфигурация системы РАМ 1205 Альтернатива демону winbind 1206 30.10. Рекомендуемая литература 1206 30.11. Упражнения 1206 Глава 31. Последовательные устройства и терминалы 1208 31.1. Стандарт RS-232C 1209 31.2. Альтернативные разъемные соединения 1211 Разъем DB-9 1211 Разъем RJ-45 1212 31.3. Аппаратная и программная несущие 1213 31.4. Аппаратный контроль передачи данных 1213 31.5. Файлы последовательных устройств 1214 31.6. Команда setserial: передача драйверу параметров последовательного порта в системе Linux 1215 31.7. Псевдотерминалы 1216 31.8. Конфигурирование терминалов 1216 Процедура регистрации в системе 1217 Файл /etc/ttytype 1218 Файл /etc/gettytab 1218 Файл /etc/gettydefs 1219 Файл /etc/inittab 1219 Демон Upstart в системе Ubuntu 1221 31.9. Специальные символы и драйвер терминала 1222 31.10. Команда stty: задание параметров терминала 1223 31.11. Команда tset: автоматическое задание параметров терминала 1224 31.12. Как справиться с “зависшим” терминалом 1225 31.13. Отладка последовательной линии 1225 31.14. Соединение с консолями последовательных устройств 1226 31.15. Упражнения 1227 Глава 32. Управление, стратегия и политика 1228 32.1. Цель информационных технологий 1228 Составление сметы и расходование средств 1229 Стратегия в области информационных технологий 1230 Соглашения о качестве оказываемых услуг 1231 32.2. Информационная структура организации 1235 Основы: система отслеживания запросов и управления задачами 1235 Общие функции систем отслеживания запросов 1236 Владение запросом 1237 Система отслеживания запросов с точки зрения пользователей 1238
Содержание 55 Типичные диагностические системы 1238 Распределение сообщений о неполадках 1239 Перечень навыков 1240 Управление временем 1241 32.3. Служба поддержки 1241 Диапазон услуг 1241 Доступность службы поддержки 1242 Зависимость от службы поддержки 1242 32.4. Архитектура предприятия 1242 Процессы должны быть воспроизводимыми 1243 Сохранение отладочных данных 1243 Осознание важности документации 1244 Настройка и кодирование 1244 Содержание системы в чистоте 1244 32.5. Операции 1244 Время простоев должно быть минимальным 1245 Документирование зависимостей 1245 Переналадка или списывание старого оборудования 1245 Поддержка локальной документации 1246 Разделение окружающей среды 1250 Автоматизируйте, автоматизируйте, автоматизируйте! 1250 32.6. Управление 1251 32.7. Инструкции и процедуры 1260 Различие между инструкциями и процедурами 1260 Эффективные инструкции 1261 Процедуры 1261 32.8. Восстановление после аварий 1262 Оценка рисков 1262 Борьба со стихийными бедствиями 1263 Подбор персонала на случай аварии 1264 Электропитание и кондиционирование 1265 Сетевая избыточность 1266 Проблемы с безопасностью 1267 32.9. Соответствие законам и стандартам 1267 Библиотека ITIL: Information Technology Infrastructure Library 1270 NIST: Национальный Институт стандартов и технологии 1270 32.10. Правовые вопросы 1271 Конфиденциальность 1271 Реализация стратегии 1272 Контроль — это ответственность 1273 11 Л114611311**на программное обеспечение 1273 1 о рганизации» конференции и другие ресурсы 1274 ’ ек°мендуемая литература 1276 •^•13. Упражнения 1276 Краткая история системного администрирования 1278 В защиту AIX 1288 Предметный указатель 1291
Об авторах Эви Немет уволилась с факультета вычислительной техники Университета штата Колорадо и в настоящее время бороздит просто- ры Тихого океана на своей 40-футовой яхте “Wonderland” (“Страна чудес”). Это — ее последнее издание, невозможно быть в курсе со- временных “сисадминовских игрушек”, стоя на якоре в каком-то райском уголке с пакетом EMail Connection для радиосвязи со ско- ростью 30 бод. sailingevi@gmail.com Гарт Снайдер работал в компаниях NeXT и Sun и получил сте- пень бакалавра электротехники в колледже Суортмор, штат Пенсильвания, а также ученую степень в Университете Рочестера, штат Нью-Йорк. garth@garthsnyder.com Т^ент Р. Хейн — один из основателей компании Applied Trust Engineering, которая разрабатывает средства защиты и анализа про- изводительности сетей. Трент получил степень бакалавра вычисли- тельной техники в Университете штата Колорадо. trent@atrust.com Бен Уэйли — руководитель отдела архитектуры предприятий (Enterprise Architecture) в компании Applied Trust Engineering, которая занимается консалтингом в области информационных технологий (г. Боулдер, штат Колорадо). В 2004 году он получил диплом бака- лавра по специальности “Вычислительная техника” в Университете штата Колорадо. ben@atrust.com
О соавторах Терри Морреале (Terry Morreale) — старший инженер и руководитель отдела по об- служиванию клиентов в Applied Trust. Она получила диплом по специальности “Вычислительная техника” в Университете штата Колорадо, а также имеет следую- щие сертификаты: CISSP, GIAC Gold Certified Incident Handler и ITILv3 Foundations. Свободное от работы время Терри посвящает заботе о двух своих детях, чтению и бегу. Нэд Мак-Клейн (Ned McClain) (ned@atrust. com) — один из основателей и руково- дитель технического отдела в Applied Trust Engineering. Он помогает клиентам разного уровня в вопросах архитектуры и эксплуатации систем. Работает над решением проблем производительности, бесперебойности и безопасности работы систем. Но особенно его интересует область системного администрирования. Нэд получил диплом по специаль- ности “Вычислительная техника” в техническом колледже при Корнеллском универси- тете и имеет сертификаты CISSP, МСР и ITIL. Нэд регулярно обновляет содержимое своего блога (arkingseal. com). Рон Яким (Ron Jachim) получил степень магистра в Университете Уэйна в Детройте (штат Мичиган), где в настоящее время читает лекции в качестве адъюнкт-профессора. В течение 20 лет он набирался опыта по использованию систем UNIX как в процессе преподавания, так и работая в Ford Motor Company. Он сочетает навыки администри- рования с пристрастием к поиску решений по созданию эластичных инфраструктур, включающих тысячи серверов, и к повышению производительности глобальных при- ложений. Дэвид Швайкерт (David Schweikert) работает менеджером по продукции в Open Systems AG (Швейцария) — организации, предоставляющей услуги по обеспечению безопасности систем. Его команда отвечает за управление конфигурированием и мониторинг более чем 1 500 серверов UNIX в более чем 100 странах. Девид является разработчиком про- ектов с открытым кодом Mailgraph (инструментальное средство для визуализации стати- стики электронной почты) и Postgrey (реализация Postfix); см. david. schweikert. ch. Тоби Отикер (Tobi Oetiker) — инженер-электрик по образованию и системный адми- нистратор по призванию. В течение десяти лет он работал в швейцарском федеральном технологическом институте (Swiss Federal Institute of Technology), где создал роскош- ную UNIX-среду для студентов и персонала. С 2006 года Тоби трудится в собственной компании OETIKER+ PARTNER AG, где занимается поддержкой UNIX-серверов для промышленных клиентов, совершенствует свои любимые проекты с открытым кодом ( RTG™, RRDtool и Smoke Ping) и применяет этот инструментарий для решения про- лем своих клиентов. В ноябре 2006 года Тоби получил престижную награду (SAGE utstanding Achievement Award) за работу над пакетами MRTG и RRDtool; см. tobi. oetiker.ch.
Предисловие Двадцать семь лет назад, т.е. в 1983 году, я написал, пожалуй, первое руководство по системному администрированию для операционной системы UNIX. Меня пригласили в Массачусетсскую компанию (Massachusetts Computer Company — MASSCOMP), спе- циализирующуюся на UNIX-машинах, для написания документации. Завершив озна- ченную в контракте работу над руководством по графическому программированию, я прикидывал, к чему бы еще мне можно было здесь приложить свои силы. “При возник- новении системных проблем мы всегда обращаемся к Тому Тейкшейре, — сказал я. — А что делать нашим клиентам?” Ответ не заставил себя ждать: “Нам просто позарез нужно практическое руковод- ство”. И вскоре я снова работал, но на этот раз должен был извлечь максимум полезной информации из головы Тома Тейкшейры и перенести ее на бумагу. В результате получилась книга, в которой были описаны такие основные понятия, как суперпользователь, добавление учетной записи, управление разрешениями, резерви- рование и восстановление, организация сети с помощью протокола UUCP и пр. Книга была ориентирована на System V, одну из двух главных (на то время) разновидностей UNIX (другой была Berkeley UNIX). В конечном счете я вполне справился с поставленной передо мной задачей — до- был ценную информацию от Тома и других членов немногочисленной (на то время) ка- сты элитных системных администраторов. И когда в 1989 году увидела свет книга UNIX System Administration Handbook (USAH), у меня уже не было сомнений в том, что это ав- торитетное руководство — “библия” в своем роде — получило заслуженное признание, и неудивительно: ведь оно вышло непосредственно из-под пера (то бишь клавиатуры) истинных мастеров своего дела. К тому времени О’Рейли стал издателем. Узнав, что многие мои клиенты (в сфере написания технической документации) перешли на UNIX, я начал сохранять права на написанные мною руководства, чтобы можно было перепродавать их другим компа- ниям. В конце 1985 года мы представили наши первые книги, которые уже не лицен- зировались для компаний, а находились в открытой продаже. Сначала мы выпускали небольшие книги, посвященные таким отдельным темам, как vi, sed и awk, termcap и terminfo, или протоколу UUCP. Мы называли их “Nutshell Handbooks” (“Справочники в двух словах” — Примеч. ред.), поскольку хотели охватить все темы и собрать их под одной “оболочкой”. В действительности мы ничего не знали об издательском деле. Наши книги не имели ни корешков (они сшивались скобками), ни предметных указателей, ни ISBN (междуна- родный стандартный номер книги). Мы продавали их по почте, а не через книжные ма- газины. Но мало-помалу мы осваивали эту сферу деятельности и в конце концов стали конкурировать с известными издателями компьютерных книг. Любимая для нас тема — общие методы администрирования UNIX, но до недавних пор мы не брались за нее. И вот почему. Я — сторонник удовлетворения возникших потребностей без конкуренции с кем-либо ради этого. И было абсолютно ясно, что по означенной теме уже есть не просто хорошая, а ВЕЛИКОЛЕПНАЯ книга! Я не видел ни необходимости соперничать с такой всеобъемлющей книгой, ни возможности добиться успеха в этом направлении. Но со временем, когда наш бизнес стал на ноги и мы вышли на рынок компьютер- ных книг, стало понятно, что конкуренция действительно может способствовать рас- ширению рынка. Люди, как правило, видя одну книгу, воспринимают ее как нечто исключительное. Если же им на глаза попадается несколько книг по одной теме, то, как говорил певец Арло Гатри (Arlo Guthrie), “они могут подумать, что это движение”.
Предисловие 37 Кроме того, в первом издании USAH авторы четко взяли курс на BSD-ориентированные системы (BSD UNIX), и мы подумали, что осталась свободной ниша для книги с укло- ном в сторону System V. В 1991 году мы выпустили в свет собственную книгу по системному администриро- ванию UNIX, а именно ЛЕДееп Frisch, Essential System Administration, Как автор, редактор и издатель, я никогда не придавал большого значения кон- куренции — за исключением нескольких случаев. И это один из таких случаев. UNIX System Administration Handbook — это одна из немногих книг, на которые мы равняемся. Могли бы мы сделать так же хорошо? Могли бы мы сделать еще лучше? Подобно дуэли Мэджика Джонсона и Ларри Берда в NBA, соперничество выявляет лучшее, что есть в нас. Ну вот, опять! Четвертое издание? Элин не мешало бы вернуться к работе!:-) Тим О’Рейли июнь 2010 г.
Введение Когда мы писали первое издание этой книги в средине 1980-х, нам очень хотелось сравнить нашу рукопись с другими книгами по системному администрированию. К на- шему удивлению, мы отыскали только три. Теперь же вы можете выбирать из сотен книг. Назовем преимущества нашего издания. • Эта книга является практическим руководством, в котором мы делимся с читате- лями нашим коллективным опытом системного администрирования и предлагаем рекомендации, которые выдержали испытание временем. Она содержит множе- ство практических примеров и советов. • Здесь не говорится о том, как использовать UNIX или Linux в домашних услови- ях. Мы описываем применение операционных систем в коммерческих компаниях, правительственных учреждениях, университетах. • В книге подробно излагаются вопросы, связанные с работой UNIX- и Linux-сис- тем в сетях. Это самый трудный аспект системного администрирования, и имен- но здесь наша помощь, как нам кажется, будет для читателей наиболее полезной. • В этом руководстве рассмотрены основные варианты UNIX и Linux. Структура книги Книга разбита на три части — “Основы администрирования”, “Работа в сети” и “Разное”. В части I, “Основы администрирования”, приводится общий обзор систем UNIX и Linux с точки зрения системного администратора. В главах этой части представлены основные сведения и описаны методики, необходимые для управления автономной системой. В этой части описаны протоколы, используемые в UNIX-системах, а также способы построения, расширения и администрирования сетей и интернет-серверов. Здесь же рассматривается высокоуровневое сетевое программное обеспечение. Среди изучаемых тем можно выделить систему доменных имен (DNS), сетевую файловую си- стему (NFS), систему электронной почты и инструменты сетевого управления. В части II, “Работа в сети”, описываются протоколы, используемые в системах UNIX, а также способы настройки, расширения и эксплуатации сетей и серверов, с выходом в Интернет. Кроме того, в ней рассматривается высокоуровневое сетевое программное обеспечение, а также система доменных имен, сетевая файловая система, электронная почта и управление сетью. В части III, “Разное”, содержит разнообразную вспомогательную информацию. В некоторых главах обсуждаются дополнительные функциональные возможности, такие как поддержка виртуализации серверов. В других главах даются рекомендации по самым разным темам: от экологического аспекта до принципов функционирования групп системного администрирования. В конце каждой главы приводится набор практических заданий. Каждому упражне- нию дана оценка уровня сложности, причем учитывается как сложность самой задачи, так и время, затрачиваемое на ее выполнение. Упражнения соответствуют четырем уровням сложности. звездочки отсутствуют Простое задание, не требующее особых усилий ★ Более сложное или трудоемкое задание, для которого может потребоваться лабораторная работа ★★ Наиболее сложное или трудоемкое задание, требующее лабора- торной работы
Введение 39 Курсовые проекты (лишь в нескольких главах) Для выполнения некоторых упражнений требуется доступ к системе с правами су- перпользователя. Иногда нужно получить предварительное разрешение у системного ад- министратора локальной сети. Подобные случаи оговариваются в задании. Наши помощники Мы признательны Неду Мак-Клейну (Ned McClain), Девиду Швайкерту (David Schweikert) и Тоби Отикеру (Tobi Oetiker) за их вклад в создание книги. В написании этого издания принимали участие Терри Морреале (Terry Morreale) и Рон Яким (Ron Jachim). Их глубокие знания в самых разных областях существенно обогатили материал книги. Информация для контактов Свои предложения и комментарии присылайте по адресу: ulsah@book. admin. com. Мы действительно отвечаем на большинство писем, но, пожалуйста, будьте терпели- вы. Иногда проходит несколько дней, прежде чем у кого-то из нас появляется возмож- ность ответить на письмо. Для того чтобы просмотреть список выявленных на данный момент опечаток, а также другую свежую информацию по книге, посетите наш веб-сайт www.admin.com. Надеемся, что книга вам понравится, и желаем удачи в системном администриро- вании. Эви Немет Гарт Снайдер Трент Р. Хейн Бен Уэйли июнь 2010 г. Благодарности Множество людей внесли ценный вклад в работу над книгой. Кто-то из них выпол- нял научное редактирование или предлагал интересные примеры, кто-то оказывал мо- ральную поддержку. И все они заслуживают особой благодарности. Рон Айтчисон Питер Хааг Джереми С. Рид (Ron Aitchison) (Peter Haag) (Jeremy С. Reed) Эрик Олмен Брайан Хелви Энди Рудов (Eric Allman) (Bryan Helvey) (Andy RudofI) Клей Бензигер Матийс Меккинг Михаил Синатра (Clay Baenziger) (Matthijs Mekking) (Michael Sinatra) Адам Богз Рэндалл Манро П<$ль Викси (Adam Boggs) (Randall Munroe) (Paul Vixie) Том Кристиансен Эрик Остервейл Уотер Вийнгаардс (Tom Christiansen) Дэн Фостер (Пап Foster) Стив Гэд (Steve Gaede) (Eric Osterweil) Фил Пеннок (Phil Pennock) Уильям Путнем (William Putnam) (Wouter Wijngaards)
40 Введение Наш редактор из Prentice Hall, Марк Тауб (Mark Taub), заслуживает не только благо- дарности, но и награды за то, что мужественно выдерживал капризы авторов. Он был бесконечно терпелив к нам и сделал все возможное, чтобы заставить нас сосредоточить- ся на повышении качества материала. Нам очень повезло с рецензентами. Особенно хотелось бы отметить Джонатана Корбета (Jonathan Corbet) и Пэта Парсигьяна (Pat Parseghian) не только за их деликат- ные и подробные замечания, но и за их готовность вновь погрузиться в работу над буду- щими изданиями. Мэри Лу Hop (Mary Lou Nohr) проделала огромную работу по оформлению настоя- щего издания. Мы высоко ценим ее усилия. Потрясающие рисунки и обложка для этого издания придуманы и выполнены Лизой Хани (Lisa Haney). С ее портфолио можно ознакомиться на сайте lisahaney.com. Линда Григолейт (Linda Grigoleit), Терри Хоффман (Terry Hoffman) и Джон Саливан (John Sullivan) оказали нам неоценимую помощь в переговорах с сетевой службой IBM, в результате чего мы получили необходимое оборудование для оценки качества нашей работы. Благодарим также компанию Applied Trust (appliedtrust.com), руководство ко- торой позволило использовать свои лабораторные площади и оказывало всяческую материально-техническую поддержку. К сожалению, нам не удалось достичь соглашения, которое позволило бы нам пу- блично выразить признание одному из наших выдающихся авторов. Тем не менее его вклад в проект был нами высоко оценен, и мы посылаем ему этот перевертень, который, несомненно, станет украшением его коллекции: “A man, a plan, a canoe, pasta, Hero’s rajahs, a coloratura, maps, snipe, percale, macaroni, a gag, a banana bag, a tan, a tag, a banana bag again (or a camel), a crepe, pins, Spam, a rut, a Rolo, cash, ajar, sore hats, a peon, a canal — Panama!” От издательства Вы, читатель этой книги, и есть главный ее критик. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес. Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумаж- ное или электронное письмо либо просто посетить наш Web-сервер и оставить свои за- мечания там. Одним словом, любым удобным для вас способом дайте нам знать, нра- вится ли вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более интересными для вас. Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязатель- но учтем его при отборе и подготовке к изданию последующих книг. Наши координаты: E-mail: info@williamspublishing.com WWW: http: //www.williamspublishing.com Адреса для писем из: России: 127055, г. Москва, ул. Лесная, д. 43, стр. 1 Украины: 03150, Киев, а/я 152
ЧАСТЬ I Основы администрирования

Глава 1 С чего начать В настоящее время в море информации по UNIX и Linux можно утонуть, поэтому мы решили с помощью этой книги проложить свой курс и удовлетворить потребности именно системных администраторов, заняв тем самым вполне конкретную нишу в эко- системе разного рода справочных страниц (man pages), блогов, журналов, книг и прочих справочных материалов. Во-первых, это — руководство, в котором рассматриваются различные компонен- ты основных систем администрирования и принципы их совместной работы. Во мно- гих случаях, когда нам приходилось выбирать между разными реализациями некоторой идеи, мы описывали преимущества и недостатки основных вариантов. Во-вторых, это — краткий справочник, в котором собрано все, что необходимо знать Для выполнения задач общего характера в различных версиях UNIX- и Linux-систем. Например, команда ps, отображающая статус текущих процессов, поддерживает более 80 ключей (опций) командной строки в системах Linux. Но всего несколько комбина- ций ключей удовлетворяют 99% нужд системного администратора (см. раздел 5.7). Наконец, в этой книге делается акцент на администрировании корпоративных сер- веров и сетей, т.е. на серьезной теме системного администрирования. Несложно устано- вить операционную систему на отдельном компьютере, гораздо труднее поддерживать Устойчивую работу виртуализированной сетевой^ при больших нагрузках, сбоях в Работе дисков и умышленных атаках. Поэтому мй^щсываем методы и практические способы, которые позволят вам “поднимать” “уйавшие” сети, а также выбирать реше- ния, которые останутся актуальными при расширении и усложнении вашего сайта и из- менении его гетерогенности. Мы не претендуем на абсолютную степень объективности в решении перечисленных Выше задач, поэтому по ходу изложения Постарались максимально ясно пояснить свои
44 Часть I. Основы администрирования субъективные взгляды и предпочтения. Особенность системного администрирования заключается в том, что опытные администраторы могут иметь совершенно разные пред- ставления о правилах и процедурах управления системами. Читателям придется само- стоятельно решать, какой именно материал и в какой степени соответствует той среде, в которой они работают. 1.1. Основные задачи системного администратора CQ Подробнее о написании сценариев рассказывается в главе 2. В Википедии в статье “системный администратор” представлено довольно полное описание функций, которые, как общепринято считать, должен выполнять системный администратор. В английской версии этой статьи проводится четкое разграничение по- нятий администрирования и разработки программ, но мы знаем не понаслышке, сколь- ко времени профессиональные администраторы отдают написанию сценариев (scripts). Сам по себе этот факт не превращает системных администраторов в разработчиков, но это означает, что им необходимо иметь практически такие же аналитические способно- сти и знания в области архитектуры компьютерных сетей. В этом разделе перечислены задачи, обычно возлагаемые на системного администра- тора. Совсем не обязательно, чтобы эти функции выполнял один человек. Во многих организациях работа поручается команде специалистов. В любом случае необходим хотя бы один человек, который понимал бы все поставленные задачи и обеспечивал их кор- ректное выполнение другими людьми. Инициализация пользователей CQ Подробнее о добавлении новых пользователей рассказывается в главе 7. В круг обязанностей системного администратора входит создание учетных записей для новых пользователей, удаление учетных записей тех пользователей, которые уже не рабо- тают в системе, и решение всех проблем, возникающих во время “системной жизни” сво- их подопечных (например, “подсказка” забытых паролей). Процесс управления записями можно автоматизировать, но ряд решений, связанных с включением в систему нового пользователя (место размещения его начального каталога, компьютер, на котором должна создаваться учетная запись, и так далее), должен принимать только администратор. Если необходимо прекратить доступ пользователя к системе, его учетная запись должна быть аннулирована. Все файлы, относящиеся к этому пользователю, необходи- мо удалить, чтобы они не занимали место на диске. Подключение и удаление аппаратных средств CQ Дополнительная информация по данной теме приведена в главах 8,13 и 26. В случае приобретения новых аппаратных средств или подключения уже имеющихся устройств к другому компьютеру, нужно переконфигурировать систему таким образом, чтобы она распознавала и активизировала эти устройства. Изменение конфигурации может быть как простой задачей (например, подключение принтера), так и более слож- ной (например, подключение жесткого диска). Теперь, когда в сферу корпоративной обработки данных прочно вошло понятие вир- туализации, конфигурация технических средств может усложниться как никогда ранее. Инсталляция устройств может занимать несколько уровней стека виртуализации, и си-
Глава 1. С чего начать 45 стемному администратору приходится вырабатывать новые стратегии, которые позволят безопасно и качественно использовать общие аппаратные средства. резервное копирование Ш Подробнее о резервном копировании рассказывается в главе 10. Резервное копирование является, наверное, одной из наиболее важных задач систем- ного администратора, которая, к сожалению, чаще всего игнорируется или выполняет- ся спустя рукава. Процедура резервного копирования довольно утомительна и занимает много времени, но осуществлять ее необходимо. Этот процесс можно автоматизировать или поручить подчиненным, но все равно системный администратор обязан убедиться в том, что резервное копирование выполнено правильно и по графику (а с полученного носителя можно восстановить данные). Инсталляция и обновление программ Ш Подробнее об утилитах работы с программами рассказывается в главе 12. После приобретения нового программного обеспечения его нужно инсталлировать и протестировать, часто в нескольких операционных системах и на различном оборудова- нии. Если программы работают нормально, пользователям необходимо сообщить об их наличии и местонахождении. Выпускаемые пакеты обновлений для исправления оши- бок и устранения брешей в системе безопасности должны без проблем устанавливаться в локальных системах. Локальные программы и административные сценарии следует соответствующим об- разом упаковать и организовать в виде, обеспечивающем совместимость с процедурами обновления, используемыми в системах вашего сайта. Новые версии ваших программ- ных продуктов, прежде чем использовать их во всем узле сети, необходимо представлять для тестирования. V Мониторинг системы Крупные системы требуют неусыпного контроля. Не стоит надеяться, что пользова- тели всегда сами будут сообщать вам о затруднениях (если, конечно, они не столкнутся по-настоящему с серьезными проблемами). Обычно пользователи идут по пути наи- меньшего сопротивления, полагая, что на решение проблемы у них уйдет меньше вре- мени, чем на ее описание и сообщение о ее возникновении. Существует множество обязательных ежедневных операций, а именно: проверка правильности функционирования электронной почты и веб-служб; просмотр журналь- ных файлов на предмет наличия ранних признаков неисправностей; контроль над под- ключением локальных сетей; контроль доступности системных ресурсов (в частности, проверка наличия свободного места на диске). Все эти рутинные операции прекрасно поддаются автоматизации, да и множество готовых систем мониторинга могут помочь системным администраторам в решении этой задачи. Поиск неисправностей Сбои систем неизбежны. Задача администратора — диагностировать сбои в системе и в случае необходимости вызвать специалистов. Как правило, найти неисправность бы- вает намного сложнее, чем устранить ее. *
46 Часть I. Основы администрирования Ведение локальной документации Ш Рекомендации, касающиеся ведения документации, даны в разделе 32.5. При настройке конфигурации системы под конкретные требования очень скоро об- наруживается, что она значительно отличается от базовой конфигурации, которая опи- сана в документации. А поскольку за реализацию этих настроек отвечает системный ад- министратор, он должен документировать все изменения. Администратор должен также вести учет обслуживания всех аппаратных средств, регистрировать состояние резервных копий, документировать разводку сетевых кабелей и локальные правила работы в системе. Слежение за безопасностью системы Ш Вопросы безопасности рассматриваются в главе 22. Системный администратор отвечает за реализацию стратегии защиты и должен пе- риодически проверять, не нарушена ли безопасность системы. В системах с низким уровнем безопасности эта процедура может быть сведена к нескольким элементарным проверкам на предмет несанкционированного доступа. В системах с высоким уровнем безопасности обычно применяется сложная сеть ловушек и программ контроля. Оказание помощи пользователям О необходимости оказания помощи пользователям в решении различных проблем редко упоминается в должностной инструкции системного администратора, хотя вы- полнение подобного рода обязанностей “съедает” большую часть его рабочего времени. Системных администраторов терроризируют самыми разными вопросами, начиная от “Вчера моя программа работала, а сегодня нет! Что вы поменяли?” до “Я пролила кофе на клавиатуру! Нужно ли теперь полить ее водой, чтобы смыть кофе?”. В большинстве случаев ваша реакция на все эти “сигналы тревоги” гораздо больше влияет на вашу оценку как администратора, чем реальные технические навыки, которы- ми, возможно, вы обладаете. Вы можете либо роптать на несправедливость такого поло- жения вещей, либо радоваться тому, что успешным решением одной-единственной про- блемы вы можете заслужить такую же благосклонность сотрудников (или начальства), как и пятичасовой отладкой в ночное время. Выбирайте! 1.2. Что НЕОБХОДИМО ЗНАТЬ Мы предполагаем, что у читателей есть определенный опыт работы с Linux или UNIX. В частности, необходимо иметь общее представление о системе с точки зрения пользователя, поскольку мы не будем на этом останавливаться. Книги, перечисленные в разделе 1.14, помогут заложить необходимый фундамент знаний. Даже в дни композитных оконных 3D-менеджеров (например, Compiz Fusion) GUI- инструменты для UNIX- и Linux-систем остаются довольно простыми по сравнению с навороченными базовыми программами. На практике большинство задач администри- рования по-прежнему решается путем редактирования конфигурационных файлов и на- писания сценариев, поэтому читатели должны быть знакомы как с оболочкой команд- ной строки, так и с каким-нибудь текстовым редактором. Ваш редактор может иметь графический интерфейс (как у gedit) или работать в сре- де интерпретации командной строки (как vi или emacs). Такие текстовые процессоры,
Глава 1. С чего начать 47 как Microsoft Word и OpenOffice Writer, кардинально отличаются от упомянутых тек- стовых редакторов и практически бесполезны для решения задач администрирования. Командные редакторы имеют неоспоримое преимущество, поскольку они могут преодо- левать простые SSH-соединения и работать на слабых системах, которые отказываются выполнять начальную загрузку; поэтому в оконных системах нет никакой необходимо- сти. Кроме того, они действуют гораздо быстрее маленьких проворных редакторов, ко- торые часто создают администраторы. Рекомендуем изучить редактор vi (или его версию vim). Он является стандартным для всех UNIX- и Linux-систем и, хотя выглядит несколько “бледным” на фоне более мощ- ных программ (в частности, emacs), абсолютно пригоден для работы. Нам также нра- вится GNU-редактор nano, который прост и прекрасно подходит новичкам, к тому же он оснащен экранными подсказками. Остерегайтесь нестандартных редакторов. Если отдать предпочтение одному из них, очень быстро надоест устанавливать его в каждой новой системе. Одним из важнейших инструментов системного администратора являются сценарии для автоматизации основных задач. Примеры такого рода сценариев приводятся на про- тяжении всей книги. Для того чтобы стать профессионалом, необходимо научиться чи- тать и модифицировать сценарии, написанные на языке интерпретатора sh (в Linux его эквивалент — интерпретатор bash). Ш Подробнее о написании сценариев рассказывается в главе 2. Для новых проектов мы рекомендуем применять язык Perl или Python. Как язык программирования Perl несколько необычен, однако содержит много средств, необхо- димых администраторам. В качестве учебника по этому языку советуем прочесть книгу Ларри Уолла Programming Perl; она также представляет собой образец профессиональ- ного технического руководства. Библиографическое описание этой книги приведено в разделе 1.14. Многие администраторы предпочитают иметь дело с языком Python. В определенном смысле это более элегантный язык, чем Perl, и его сценарии обычно легче читать и со- провождать. (Вот что сказал по этому поводу бывший сотрудник издательства Amazon Стив Йег: “Python уже давно стал пристанищем для тех, кто, наконец, принял крас- ную пилюлю и освободился от Perl-матрицы”.) Статьи, посвященные сравнению языка Python с другими языками (включая Perl), можно найти по следующему адресу: www. Python.org/doc/Comparisons.html. В большинство дистрибутивов сейчас входит Ruby переводе с англ, “рубин”) — перспективный язык программирования, в котором соз^нена мощность языка Perl и который при этом освобожден от его синтаксических “подводных камне#”. Но главное то, что он обладает современными объектно-ориентированными свойствами. Ruby еще Не стал для системных администраторов традиционным языком написания сценариев, но, по всей вероятности, станет таковым в ближайшие несколько лет. Мы рекомендуем также изучить expect, который представляет собой скорее интер- фейс для управления интерактивными программами, а не язык программирования. По сУти, это эффективная интегрирующая технология, которая может заменить традицион- ный процесс написания сценариев. Освоить expect можно достаточно быстро. Все самое важное, что необходимо знать о написании сценариев на языках bash, Perl и Python, можно почерпнуть в главе 2. В ней также рассматриваются регулярные выра- жения (шаблоны, задающие правило поиска) и некоторые идиомы оболочки, полезные 4ля системных администраторов.
48 Часть I. Основы администрирования 1.3. Взаимосвязь систем Linux и UNIX Ш Подробнее об истории Linux и UNIX читайте в разделе “Краткая история системного ад- министрирования”. В этой книге описываются как UNIX-, так и Linux-системы ввиду их схожести. Однако употребление названий Linux и UNIX в одном предложении чем-то сродни хож- дению по политическому минному полю или зыбучим пескам. Тем не менее мы возьмем на себя смелость максимально лаконично и объективно изложить ряд фактов. Однако, поскольку отношения между системами UNIX и Linux, мягко говоря, носят запутанный характер, мы не можем обойти молчанием создавшуюся ситуацию и возьмем на себя смелость максимально лаконично и объективно изложить ряд фактов. Linux — измененная и усовершенствованная реализация ядра операционной системы UNIX. Она соответствует стандарту POSIX, работает на различных аппаратных платфор- мах и совместима с большинством существующих приложений UNIX. Отличие от мно- жества других (но не всех) вариантов UNIX заключается в том, что Linux — бесплатная операционная система с открытым исходным кодом, разрабатываемая коллективными усилиями тысяч энтузиастов и организаций. Вместе с тем, операционная система Linux содержит ряд технических усовершенствований, которые отсутствуют в UNIX, и поэто- му представляет собой нечто большее, чем простой клон UNIX. В то же время тради-; ционные производители UNIX не перестают заниматься усовершенствованием своих продуктов, что говорит о наличии областей, в которых коммерческие UNIX-системы превосходят Linux-системы. 1 Linux совершенно законно может считаться отдельным программным продуктом, ко- торый уже неправильно называть “UNIX” или версией “UNIX”. В то же время было бы ошибкой настаивать на том, что Linux — совсем “не UNIX”. Если ваше творение ходит как утка и крякает как утка, то, скорее всего, вы изобрели утку. Раскольники нашлись даже в самом лагере Linux. Часто утверждают, и отчасти это справедливо, что ссылаться на дистрибутивы Linux просто как на “Linux” — значит не признавать труд разработчиков, вложенный в утилиты, выполняющиеся вне ядра (ко- торые, по сути, составляют подавляющее большинство программ в средней системе). К сожалению, альтернативная версия, которую наиболее часто предлагают, — “GNU/ Linux” — обременена собственным политическим багажом и официально поддержива- ется только дистрибутивом Debian. В статье Википедии “Спор об именовании GNU/ Linux” приведены аргументы обеих сторон1. Интересно отметить факт уже преобладаю- щего использования открытых программных средств в большинстве UNIX-систем, но ни для одной из них, насколько нам известно, пока не предложено использовать назва- ние “GNU/UNIX.2 Программы, написанные для Linux, являются UNIX-программами. Во многом бла- годаря проекту GNU наиболее значительные программные компоненты, составляющие основу UNIX-систем, разрабатываются теперь в соответствии с принципом открыто- 1 Поскольку Википедия содержит информацию о Linux, а значит, она должна часто ссылать- ся на соответствующую статью, эта дискуссия имеет большое значение для самой Википедии. Рекомендуется также ознакомиться с содержимым вкладки Discussion для упомянутой статьи Википедии. 2 В конце концов. “GNU — не UNIX”!
Глава 1. С чего начать 49 сти исходного кода.3 Один и тот же код может выполняться как в Linux, так и в любой другой однотипной среде. Веб-серверу Apache, к примеру, все равно, где работать: Linux или Solaris. С позиции коммерческих приложений и большинства программ админи- стрирования Linux — это просто одна из наиболее поддерживаемых и самых доступных разновидностей UNIX. Следует заметить, что Linux — не единственная свободно доступная UNIX-подобная операционная система. OpenSolaris также имеет открытый исходный код, хотя ее строго оговоренные сроки лицензирования кажутся подозрительными для некоторых борцов за чистоту проектов с открытым кодом. Системы FreeBSD, NetBSD и OpenBSD, являю- щиеся потомками BSD UNIX, имеют своих пылких сторонников. Эти операционные системы сопоставимы с Linux по функциональным возможностям и надежности, хотя и не пользуются такой популярностью у сторонних разработчиков программного обе- спечения. Как UNIX-, так и Linux-системы уже многие годы эффективно функционируют в промышленных условиях.4 Здесь выбор между ними должен делаться исходя из органи- зации пакетирования, поддержки и корпоративных традиций, а не из реальных разли- чий в качестве или современности. В этой книге слово “Linux”, как правило, относится к дистрибутивам Linux, а не к традиционным версиям UNIX. Но слово “UNIX” здесь употребляется не всегда в одном и том же значении, и иногда мы применяем его к атрибутам, используемым всеми про- изводными от UNIX системами, включая Linux (например, “разрешения UNIX-файла”). Если описываемые детали касаются как UNIX, так и Linux-систем, то во избежание двусмысленности мы обычно так и пишем: “UNIX и Linux”. 1.4. Дистрибутивы Linux Все дистрибутивы основаны на едином семействе ядер, однако набор служебных программ, дополняющих ядро, может существенно варьироваться. Дистрибутивы раз- личаются по своему назначению, наличию служб поддержки и степени популярности. В настоящее время существуют сотни независимых дистрибутивов Linux, но мы счита- ем, что дистрибутивы из семейств Debian, Red Hat и SUSE будут доминировать в произ- водственных средах еще как минимум в течение ближайших пяти лет. В целом между дистрибутивами Linux нет огромных различий. Остается загадкой: за- чем столько? Причем отличительными свойствами каждого из них являются “простота инсталляции” и “внушительная библиотека nporpaMWgg^средств”. Нет-нет да и про- скакивает мысль о том, что кто-то просто испытывает уд^ЙЖ^орение от выпуска новых Дистрибутивов Linux. На удивление, многие другие (более компактные) дистрибутивы так же конкурен- тоспособны по возможностям настройки. Все значительные дистрибутивы (в том числе 3 Некоторые наши технические рецензенты не соглашались с тем, что мы, как им казалось, связывали GNU с созданием самого открытого в мире программного обеспечения. Отнюдь нет! Однако участники проекта GNU определенно сделали больше, чем любая другая группа для рас- пространения идеи открытого программного обеспечения как социальной инициативы и система- тизации ^прекращающегося спора о сроках лицензирования и взаимодействии между открытыми и неоткрытыми программными продуктами. 4 Под “производственной” средой мы понимаем среду, которую организация использует для выполнения реальных задач (в отличие от использования для тестирования, исследований или Разработки).
50 Часть I. Основы администрирования и второго яруса) включают относительно безболезненную процедуру инсталляции, из- ящную среду, реализующую концепцию рабочего стола, и форму управления пакетиро- ванием. Кроме того, большинство дистрибутивов позволяет выполнять загрузку с DVD- диска, что удобно для отладки и ознакомления с новым продуктом. Поскольку эта книга сфокусирована на управлении крупномасштабными Linux- системами, мы больше склоняемся к дистрибутивам наподобие Red Hat, которые предусматривают управление сетями. Одни дистрибутивы создавались в расчете на про- мышленное применение, другие — нет. Какой-нибудь дополнительный программный компонент системы промышленного уровня, на первый взгляд малозначительный, в действительности существенно упрощает администрирование. Принимая решение в пользу того или иного дистрибутива, обращайте внимание не только на его функциональные возможности, но и на то, как будет протекать сотрудни- чество вашей организации и поставщика дистрибутива в ближайшие годы. Задайте себе ряд важных вопросов. • Будет ли дистрибутив существовать в ближайшие пять лет? • Будут ли оперативно устраняться бреши в системе защиты? • Будут ли оперативно выпускаться новые версии программных продуктов? • Будет ли оказана помощь в решении возникших проблем? Под этим углом зрения некоторые чрезвычайно интересные, компактные дистрибу- тивы уже не кажутся столь привлекательными. Но не стоит сбрасывать их со счетов: на- пример такая компания, как E*Trade, работает в системе Gentoo Linux. Наиболее жизнеспособные дистрибутивы не обязательно имеют корпоративный ста- тус. Например, мы ожидаем, что система Debian Linux (простите, Debian GNU/Linux!) просуществует довольно долго, несмотря на то что Debian — это не коммерческая ком- пания, она ничего не продает и не предлагает сервисного обслуживания. Несмотря на то что Debian не входит в число широко используемых дистрибутивов, эта система из- влекает пользу из группы спонсоров и огромной популярности дистрибутива Ubuntu, который основан на системе Debian. Наиболее популярные дистрибутивы общего назначения перечислены в табл. 1.1. Таблица 1.1. Наиболее популярные дистрибутивы Linux общего назначения Дистрибутив Веб-узел - Комментарии ,. CentOS centos.org Бесплатный аналог Red Hat Enterprise Linux Debian debian.org Популярный некоммерческий дистрибутив Fedora fedoraproj ect.org Вариант Red Hat Linux, предназначенный для использо- вания отдельными пользователями Gentoo gentoo.org Оптимизированный дистрибутив, предназначенный для самостоятельной компиляции Linux Mint linuxmint.com Компактный дистрибутив, основанный на Ubuntu Mandriva mandriva.com Один из наиболее дружественных по отношению к поль- зователю дистрибутивов openSUSE opensuse.org Бесплатный аналог SUSE Linux Enterprise Oracle Enterprise Linux oracle.com Версия RHEL, поддерживаемая системой Oracle PCLinuxOS pclinuxos.com Ответвление от Mandriva, ориентированное на KDE Red Flag redflag-linux.com Ведущий дистрибутив в Китае, подобный Red Hat
Глава 1. С чего начать 51 Окончание табл. 1.1 Дистрибутив Веб-узел Комментарии Red Hat Enterprise redhat. com Коммерческий дистрибутив Red Hat, отличающийся вы- сокой надежностью Slackware SUSE Linux Enterprise slackware. com Один из старейших дистрибутивов novel 1. com/linux Многоязыковой дистрибутив, особенно популярен в Европе Ubuntu ubuntu. com Доработанная версия Debian Обновляемый перечень дистрибутивов Linux (в том числе и не англоязычных) можно найти по следующим адресам: linux.org/dist, lwn.net/Distributions и distrowatch.com. 1.5. Примеры систем, используемых в этой книге В этой книге мы остановились на трех популярных дистрибутивах Linux и трех вер- сиях UNIX: Ubuntu Linux, openSUSE, Red Hat Enterprise Linux, Solaris, HP-UX и AIX. Они представляют собой срез рынка корпоративных систем и охватывают большинство инсталляций в крупных организациях. Приведенная в книге информация относится, как правило, ко всем упомянутым выше дистрибутивам, если нет специальных уточнений. Подробности, касающиеся кон- кретного дистрибутива, помечаются значком поставщика. ЙЭ Ubuntu® 9.10 “Karmic Koala” soians openSUSE® 11.2 Red Hat® Enterprise Linux® 5.5 Solaris™ 11 and OpenSolaris™ 2009.06 HP-UX® lli v3 AIX® 6.1 Эти значки использованы с разрешения их владельцев. Следует заметить, что разра- ботчики приведенных дистрибутивов не рецензировали эту книгу. Подробнее о каждой Из Упомянутых систем описано в следующих разделах. Примеры Linux-дистрибутивов 81 Информация, относящаяся именно к Linux-системам, но не к какому-то кон- кретному дистрибутиву, отмечается логотипом с изображением талисмана Linux — пингвина Такса (Тих). ©Дистрибутивы Ubuntu сохраняют идеологическую направленность на разра- ботку членами сообщества пользователей и разработчиков и открытый доступ,
52 Часть I. Основы администрирования поэтому вопрос о том, какие части дистрибутива бесплатны или разрешены для дальнейшего распространения, даже не возникает. Ubuntu в настоящее время финансируется за счет благотворительных пожертвований южноафри- канского предпринимателя Мака Шаттлворта (Mark Shuttleworth). Ubuntu основан на дистрибутиве Debian и использует его систему пакетирования. Он выпускается в двух основных вариантах: Desktop Edition и Server Edition. В сущности, они идентичны, но ядро Server Edition предварительно настроено для использования на сервере и не инсталлирует графический интерфейс (GUI) или такие GUI-приложения, как OpenOffice. Компания SUSE, которая теперь является одним из подразделений корпора- 6 " " ции Novell, пошла по пути Red Hat и начала распространять два связанных дистрибутива: openSUSE, который содержит только бесплатное программное обеспечение, и платный SUSE Linux Enterprise, который включает средства формальной поддержки и предоставляет несколько дополнительных возмож- ностей. Эта книга не содержит никакой информации, характерной для того или иного дистрибутива SUSE, поэтому мы называем их всех просто “SUSE”. В течение более десяти последних лет Red Hat занимает ведущее положение среди вариантов Linux, и его дистрибутивы наиболее популярны в Северной Америке. В 2003 году первоначальный дистрибутив Red Hat Linux был разде- лен на серию версий, ориентированных на производственные среды, которые получили название Red Hat Enterprise Linux (в этой книге мы иногда употре- бляем аббревиатуру RHEL), и на версии, разрабатываемые в рамках проекта с привлечением всех членов сообщества пользователей и разработчиков, кото- рый получил название Fedora. Это разделение было обусловлено рядом техни- ческих, экономических, логических и юридических причин. Сначала эти дистрибутивы были схожими, но за последние пять лет Fedora претерпе- ла значительные изменения, и теперь эти две системы не синхронизированы. RHEL от- личается высоким уровнем поддержки и стабильностью, но ее по существу невозможно использовать, не приобретя лицензию в компании Red Hat. Проект CentOS (centos. org) концентрирует исходный код, который компания Red Hat обязана распространять в соответствии с различными лицензионными соглашения- ми (наиболее значимой является общедоступная лицензия GNU), и комплектует их в законченный дистрибутив, который во многом подобен дистрибутиву Red Hat Enterprise Linux, но доступен бесплатно. Этот дистрибутив лишен торговой марки компании Red Hat и не содержит некоторых запатентованных программных средств, но в остальном аналогичен платной версии. CentOS стремится к полной совместимости с RHEL, как по двоичному коду, так и по степени исправления ошибок. Этот дистрибутив — прекрасный выбор для тех сайтов, которые стремятся развернуть крупномасштабную производственную систему, не платя при этом “десятину” компа- нии Red Hat. Возможен также смешанный подход: сетевые серверы могут работать под управлением Red Hat Enterprise Linux, используя при этом преимущества, предостав- ляемые прекрасным уровнем поддержки со стороны Red Hat, а рабочие станции могут функционировать под управлением CentOS. Такой подход обеспечивает оптимизацию с точки зрения риска и поддержки, в то же время сводя к минимуму затраты и сложность администрирования.
Глава 1. С чего начать 53 Примеры UNIX-дистрибутивов Solaris — операционная система, построенная на основе System V и “оброс- SOiariS шая” множеством расширений. Разработана компанией Sun Microsystems, ко- торая ныне принадлежит корпорации Oracle.5 Изначально Sun UNIX (так эта система называлась в средине 80-х гг.) — потомок Berkeley UNIX, но в резуль- тате корпоративного партнерства Sun и AT&T в системе была изменена кодо- вая основа. Solaris работает на различных аппаратных платформах, в частно- сти на Intel х86 и SPARC. Под “крышей” компании Sun систему Solaris можно было свободно загружать и ис- пользовать. Но корпорация Oracle изменила условия лицензирования, и теперь для за- гружаемых версий устанавливается бесплатный пробный период (90 дней). Наличие же OpenSolaris (свободно распространяемой версии Solaris с открытым исходным кодом) явно усугубляет сложившуюся ситуацию. На момент написания книги (средина 2010 г.) планы Oracle в отношении Solaris и OpenSolaris были неясны. Выпуск системы Solaris 11, очень похожей на систему OpenSolaris, ожидался уже в 2010 году. В этой книге, употребляя слово “Solaris”, мы имеем в виду смешанную си- стему, основанную на выпусках Solaris 10 и OpenSolaris (все данные получены от нашей разветвленной сети сильно засекреченных шпионов, действующих в недрах Oracle). В оп- ределенных случаях при необходимости мы конкретно указываем названия Solaris 10 или OpenSolaris. ОЛ Система HP-UX основана на System V и привязана к аппаратным платформам Hewlett-Packard. По исходному коду она ближе к родительскому генеалогиче- скому древу, чем Solaris илиА1Х, но HP сохранила темп ведения разработок в мире операционных систем и расширила круг собственных усовершенство- ваний. Теперь, когда HP начала поддержку и Linux-систем, будущее HP-UX несколько затуманено. • AIX — операционная система компании IBM, изначально построенЙйЙРна базе BSD 4.2 (Berkeley UNIX), но уже в версии AIX 4 (1994 г.) большинство ее компонентов перешло в System V. В настоящее время систему AIX “отнесло” довольно далеко от обоих источников. В целом, у нас создалось впечатление, что перекрестное опыление от других систем характерно для AIX в меньшей степени, чем для большинства вариантов UNIX. Вместе с тем мы считаем, что эта система попала под “дьявольское” влияние некоторых мэйн- Фреймовых и среднего класса (AS/400) операционных систем IBM, от которых она уна- следовала такие компоненты, как Object Data Manager (см. раздел 13.6), команды кон- фигурации (вместо файлов конфигурации) и административный интерфейс SMIT. Со временем эта система, возможно, станет более самобытной. Интересно отметить, что в последние десять дет IBM демонстрирует ОС-инва- риантный (т.е. независимый от операционной системы) подход к маркетингу своих лппаратных средств. IBM, продолжая разработку и продвижение AIX, также заинтере- сована в сотрудничестве с Red Hat и Novell, чтобы убедиться в устойчивой работе их Дистрибутивов Linux на оборудовании IBM. Посмотрим, как этот подход проявит себя в будущем. 5 Подробнее о системах BSD, System V и истории возникновения UNIX читайте в разделе Краткая история системного администрирования”.
54 часть I. Основы администрирование 1.6. Административные средства конкретных систем Современные системы включают графические средства и панели управления (та- кие, как YaST2 в SUSE и SMIT в IBM), упрощающие конфигурирование и администри- рование определенных компонентов системы. Эти средства очень удобны, особенно администраторам-новичкам, но они недостаточно полно отражают возможности базо- вого программного обеспечения. В этой книге мы описываем низкоуровневые механизмы, а не высокоуровневые инструментальные средства. На то есть ряд причин. Во-первых, графические средства зачастую являются платными или по крайней мере зависят от используемой системы. В результате то, что на низком уровне является одинаковым для всех систем, начинает казаться хаотичным и непостоянным. Во-вторых, мы считаем, что для системного адми- нистратора важно четко знать, как работает система. Когда в системе происходит сбой, графические утилиты не всегда помогают найти и устранить проблему. Наконец, конфи- гурировать систему на низком уровне обычно удобнее: так быстрее и надежнее, больше возможностей для манипуляции, легче писать сценарии. 1.7. Типографские особенности книги Имена файлов, команды и аргументы команд, которые следует набирать на клавиа- туре без изменений, даны полужирным шрифтом. Аргументы, вместо которых следует подставлять конкретные значения, даны курсивом. Например, в команде ср файл каталог предполагается, что аргумент файл следует заменить именем реального файла, а аргу- мент каталог — именем реального каталога. Результаты работы команд, а также фрагменты сценариев и файлов конфигурации даны моноширинным шрифтом. Комментарии к интерактивным сеансам иногда даются курсивом, например: % grep Bob /pub/phonelist # Найти номер телефона Боба Bob Knowles 555-2834 Bob Smith 555-2311 При описании синтаксиса команд мы, как правило, используем те же обозначения, что и в интерактивном руководстве: • текст, заключенный в квадратные скобки (“[” и является необязательным; • текст, после которого стоит многоточие (“...”), можно повторять; • фигурные скобки (“{” и “}”) указывают на то, что необходимо выбрать один из элементов, разделенных вертикальной чертой (“|”)- Например, спецификации bork [—х] {on|off} имя_файла... соответствует любая из следующих команд: bork on /etc/passwd bork -x off /etc/passwd /etc/termcap bork off /usr/lib/tmac В выражениях с шаблонами поиска используются следующие метасимволы: • звездочка (*) обозначает нуль или более символов; • знак вопроса (?) обозначает один символ;
Клава 1. с чего начать 55 • тильда (~) обозначает начальный каталог текущего пользователя6 *; • выражение -пользователь обозначает начальный каталог указанного пользователя. Например, иногда мы обозначаем каталоги, где хранятся сценарии запуска (etc/ rc*. d, etc/rc*. d и т.д.), сокращенным шаблоном etc/rc*.d. 1.8. Единицы ИЗМЕРЕНИЯ Такие метрические приставки, как кило-, мега- и гига-, определяются показателями степени числа 10 (например, один мегагерц составляет тысячу килогерц или миллион герц). Эти приставки “позаимствованы” и для компьютерных типов данных, но с ис- пользованием степеней числа 2. Например, один “мегабайт” памяти составляет 220 или 1 048 576 байт. Ассоциация твердотельных технологий (Solid State Technology Association) Объединенного инженерного совета по электронным устройствам (Joint Electronic Device Engineering Council — JEDEC) даже превратила эти “позаимствованные” едини- цы измерения в такой официальный стандарт, как Standard 100В.01, который признает их степенями двойки (не без некоторых натяжек). Пытаясь восстановить справедливость (или внести ясность), Международная элек- тротехническая комиссия (International Electrotechnical Commission — IEC) определила ряд числовых приставок, основанных именно на степенях числа 2: киби- (kibi-), меби- (mebi-), гиби- (gibi-) и так далее с аббревиатурами КиБ (Ki), МиБ (Mi) и ГиБ (Gi) соот- ветственно. С вводом этих единиц измерения ликвидируется двузначность, но их только начинают использовать. Поэтому привычный набор кило-, мега- и гига-префиксов все еще в ходу (в обоих значениях: десятичном и двоичном). Определить конкретное значение можно по контексту. Объем ОЗУ всегда измеряет- ся в степенях двойки, но пропускная способность сети — в степенях числа 10. Размер дисков их производители обычно указывают в десятичных единицах, а размер блоков и страниц — в двоичных. В этой книге мы используем единицы измерения МЭК (IEC) для степеней двойки и метрические — для степеней числа 10. Метрические единицы измерения мы применяем также для приблизительных значений и в тех случаях, когда точное основание степени неясно, недокументировано или его невозможно определить. В командах файлов кон- фигурации output и in мы оставляем исходные значения и указатели единиц измере- ний. Для обозначения бита служит буква Ь, а для байта — буква В. Некоторые примеры интерпретации единиц измерения приведены в табл. 1.2. Таблица 1.2. Примеры интерпретации единиц измерения Пример Описание возможного варианта_____________________________ J ;~ 56 кбит/с (kb/s) Скорость передачи данных по последовательной линии связи, равная 56 000 бит в секунду 1 Кбайт (кВ) Размер файла, равный 1000 байт 4 Кибайт (KiB) Общий размер страниц полупроводникового диска (SSD) 4 096 байт 8 Кбайт (КВ) Размер памяти — не используется в этой книге (см. описание ниже) 100 Мбайт (МВ) Ограничение по размеру файла (неоднозначность, понимается по контексту) номиналь- но составляет 108 байт 6 В дистрибутиве Solaris 10 в качестве стандартной оболочки для пользователя root использует- ся оригинальная оболочка Bourne, которая (что удивительно) не воспринимает метасимвол ~ или Поль зов а тель.
56 Часть I. Основы администрирования Окончание табл. 1.2 Пример Описание возможного варианта 100 Мбайт (МВ) Размер раздела диска (понимается по контексту) номинально составляет 108 байт, воз- можно, 99 999 744 байт3 1 Гибайт (GiB) Размер ОЗУ, в точности равный 1 073 741 824 байт6 1 Пбит/с (Gb/s) Скорость передачи информации в сети Ethernet составляет 1 гигабит в секунду (1 000 000 000 бит в секунду) 1 Тбайт (ТВ) Объем жесткого диска составляет 1 терабайт (один триллион байт), или 1 000 000 000 000 байт аЧисло 108 округлено в меньшую сторону до ближайшего целого, кратного размеру 512-байтового блока диска. 6 По заявлению компании Microsoft, этого недостаточно для функционирования 64-разрядной версии Windows 7. Аббревиатура К, как в случае “8 Кбайт (КВ)”, не является частью стандарта. Это компьютерная адаптация метрической аббревиатуры к (обозначение приставки кило-), которая означает 1 024 в отличие от 1 000. Но поскольку в аббревиатурах для многих ме- трических приставок уже используется прописная буква, стала возникать путаница при новом и исходном использовании буквы К в качестве множителя 1 000. В дистрибутиве Ubuntu Linux реализуется героическая попытка внести здравый смысл в этот вопрос и ликвидировать противоречивость (подробнее см. wiki.ubuntu. сот/ UnitsPolicy). 1.9. Использование справочных страниц И ДРУГОЙ ОПЕРАТИВНОЙ ДОКУМЕНТАЦИИ Справочные страницы онлайн-руководства (так называемые man-страницы, по- скольку их можно просмотреть с помощью команды man) составляют традиционную “интерактивную” документацию (хотя, конечно, в настоящее время практически вся до- кументация в той или иной мере является интерактивной). Эти материалы в основном инсталлируются вместе с системой, а справочной страницы отдельных программ — вме- сте с соответствующим пакетом. Интерактивное руководство содержит краткое описание отдельных команд, драйве- ров, форматов файлов и библиотечных функций. В них не найти ответа на общие во- просы, например, “Как инсталлировать новое устройство?” или “Почему моя система работает так медленно?”. Для получения ответов на подобные вопросы обращайтесь к руководствам по администрированию систем соответствующих производителей (см. раз- дел 1.10) или, если вопрос касается систем Linux, к документам, находящимся в ведении проекта Linux Documentation Project (LDP). Организация справочных страниц интерактивного руководства Во всех системах справочные страницы обычно делятся на разделы, при этом воз- можны небольшие вариации на тему принципов такого разделения. Основная схема разделения, используемая в наших примерах систем, показана в табл. 1.3.
•лава 1. с чего начать 57 Таблица 1.3. Разделы справочных страниц Unux Solaris HP-UX AIX Содержание '• -— ~ r... * 1 1 1 1 Команды пользовательского уровня и приложения 2 2 2 2 Системные вызовы и коды ошибок ядра 3 3 3 3 Библиотечные функции 4 7 7 4 Драйверы устройств и сетевые протоколы 5 4 4 5 Стандартные форматы файлов 6 6 — 6 Игры и демонстрационные программы 7 5 5 7 Различные файлы и документы 8 1m 1m 8 Команды системного администрирования 9 9 - - Внутренние интерфейсы и спецификации ядра — - 9 - Общая информация по HP-UX Некоторые разделы делятся на подразделы. Например, подраздел Зс руководства по Solaris содержит страницы с информацией о библиотеке стандартных С-функций систе- мы. В некоторых системах раздел 8 остается пустым, а описание команд, относящихся к системному администрированию, как правило, содержится в разделе 1. Игры и демон- страционные программы во многих системах уже удалены из раздела 6. Раздел руко- водства под названием “1” (прописная буква от “L”) зачастую отводится для локальных справочных страниц. Точная структура разделов не так уж важна, поскольку команда man находит соответ- ствующую страницу в большинстве случаев. При этом в нескольких разделах может быть одно и то же имя, и вот тут важно указать нужный вам раздел. Например, passwd — это и команда, и файл конфигурации, поэтому соответствующие статьи есть как в разделе 1, так и разделе 4 или 5. Команда man: чтение страниц интерактивного руководства Команда man заголовок форматирует конкретную страницу интерактивного руко- водства и выводит ее на терминал пользователя посредством more, less или другой про- граммы постраничной разбивки, которая задана в переменной среда PAGER. Аргумент заголовок — это, как правило, имя команды, устройства или файла, о которых необхо- димо получить справочную информацию. Поиск по разделам руководства осуществля- ется в порядке возрастания номеров, хотя разделы, посвященные описанию команд (1,8 и 6), обычно просматриваются в первую очередь. Команда man раздел заголовок вызывает справочную страницу из указанного раздела. Так, в большинстве систем команда man sync вызывает справочную страницу ДДя команды sync, а команда man 2 sync — для системного вызова sync. _ В системе Solaris необходимо перед номером раздела использовать флаг -з, bOiaHS например man -s 2 sync. Команда man -k ключевое слово или apropos ключевое^ слов о выводит список равочных страниц, в строке пояснений к которым имеется указанное ключевое слово. % man -k translate dca ” С0РУ and translate object files е text (3) - translate message
58 Часть I. Основы администрирования tr (1) - translate or delete characters snmptranslate (1) - translate SNMP OID values into more useful information tr (lp) - translate characters База данных ключевых слов может устаревать. При добавлении новых справочных страниц к системе вам, возможно, придется перестроить (перекомпоновать) этот файл с помощью команд mandb (Ubuntu, SUSE), makewhatis (Red Hat) или catman -w (Solaris, HP-UX, AIX). Хранение страниц интерактивного руководства Неформатированная информация для справочных страниц (входные данные коман- ды nroff) обычно хранится в подкаталогах каталога /usr/share/man. В целях эконо- мии места на диске системы Linux сжимают страницы с помощью утилиты gzip (ко- манда man может очень быстро разархивировать их). Команда man поддерживает кеш отформатированных страниц в каталогах /var/cache/man или /usr/share/man, если соответствующие каталоги доступны для записи, но эти операции рискованны с точки зрения безопасности. В большинстве систем предварительное форматирование справоч- ных страниц выполняется однократно во время инсталляции (см. команду catman) или не выполняется совсем. В дополнение к традиционной команде nroff система Solaris воспринимает soiaris справочные страницы, отформатированные с использованием обобщенного языка разметки SGML. SGML-страницы имеют собственные каталоги раздела в каталоге /usr/share/man. Команда man ищет страницы в ряде каталогов. В Linux-системах выяснить путь поис- ка позволяет команда manpath. Результат ее работы (в системе Ubuntu) обычно таков. ubuntu$ manpath /usг/local/man:/usr/local/share/man:/usr/share/man Эта установка хранится в переменной среды MANPATH, и в случае необходимости ее, можно изменить. export MANPATH=/home/share/localman:/usr/share/man Некоторые системы позволяют установить общесистемный параметр пути поиска для справочных страниц, который может оказаться полезным в случае, если вам придет- ся поддерживать параллельное дерево справочных страниц, например, сгенерированных кроссплатформенным менеджером пакетов OpenPKG. Но если вы хотите распростра- нять локальную документацию в виде справочных страниц, проще всего использовать стандартный системный механизм пакетирования и выложить справочных страницы в стандартные справочные каталоги. Подробнее об этом написано в главе 12. CNU-система Texinfo Системы Linux включают дополнительный вариант интерактивных справочных стра- ниц, именуемый Texinfo. Система Texinfo была изобретена энтузиастами проекта GNU после того, как выяснилось, что команда nroff, применяемая для форматирования справочных страниц, является собственностью AT&T. Теперь то же самое делает GNU- команда groff, так что проблема утратила актуальность, хотя Texinfo все еще бродит как зомби в поисках человеческих мозгов.
глава 1. С чего начать_____________________________________________________59 Несмотря на то что использование системы Texinfo, казалось бы, постепенно сходит на нет, некоторые GNU-пакеты требуют, чтобы документация к ним была представлена именно в формате Texinfo. Чтобы обойти встроенную навигационную систему Texinfo, перенаправьте поток вывода команды info посредством команды less. Но есть и приятный момент. Пакеты, документируемые с помощью системы Texinfo, обычно инсталлируют страницы-заглушки, в которых сообщается о том, что инфор- мацию о соответствующем пакете можно получить, вызвав команду info. Таким обра- зом можно продолжать пользоваться командой man, обращаясь к команде info лишь в случае необходимости. Команда info info выдает справку по запутанной системе Texinfo. 1.10. Другие виды официальной документации Справочные страницы — это лишь малая часть официальной документации. Остальная, в основном, рассеяна в веб-пространстве. Руководства по конкретным системам Одни производители систем ведут собственные онлайн-проекты по подготовке доку- ментации, другие выпускают полезные руководства в виде объемных книг. В настоящее время нужное руководство быстрее найти в Интернете, чем в форме печатного издания. Объем и качество документации бывают разными, но большинство производителей вы- пускает, по меньшей мере, руководство по администрированию и инсталляции системы. Где найти документацию по каждому из наших примеров систем, показано в табл. 1.4. • Безусловно, нельзя не выделить компанию IBM, которая выпускает множе- ство толстых книг по различным темам администрирования систем. Вы мо- жете купить их или даже бесплатно скачать на свой компьютер. Но, к сожале- нию, многие документы от IBM отстают на одну или две версии от текущего выпуска AIX. Таблица 1.4. Где найти документацию от производителей операционных систем Система URL - Ubuntu help.ubuntu.com Наиболее дружественная к пользователю; см. раздел “server guide” SUSE novell.com/documentation Материал по администрированию собран в разделе “reference guide” RHEL redhat.com/docs В основном, документы по расширениям системы Red Hat Solaris docs.sun.com Громадный каталог материалов HP-UX docs.hp.com Книги, технические описания и руководства AIX www.redbooks.ibm.com ibm.com/support Многочисленные книги в формате PDF Доступ к комментариям, разделам FAQs и пр. В “соревнованиях” по созданию документации система Red Hat, к сожале- нию, отстает от лидеров. Большая часть выпускаемых документов касается не общих вопросов администрирования Linux-систем, а собственных систем с дополнительными позитивными характеристиками.
60 Часть I. Основы администрирования Документация по конкретным пакетам Большинство важнейших программных пакетов в мире UNIX и Linux поддержива- ют отдельные лица или такие сторонние организации, как Internet Systems Consortium и Apache Software Foundation. Сотрудники этих групп пишут собственную документацию, качество которой часто оставляет желать лучшего. При этом существуют и такие пре- красно выполненные документы, как Version Control with Subversion от svnbook. red- bean . com (оказывается, надо знать, где искать!). Производители систем UNIX и дистрибуторы систем Linux всегда включают в свои пакеты соответствующие справочные страницы. К сожалению, многие из них старают- ся сэкономить на документации другого типа, главным образом, ввиду отсутствия стан- дартного места для ее представления (см. /usr/share/doc). Всегда имеет смысл по- сетить веб-сайт первоисточника программного продукта и поинтересоваться наличием дополнительных материалов и доступа к ним. В число дополнительных документов входят: технические отчеты (техническое опи- сание), проектные обоснования и трактовки конкретных тем. Эти дополнительные материалы зачастую не ограничиваются простым описанием команд и могут включать самоучители и другие разделы. Многие программные пакеты, помимо справочных стра- ниц, содержат и статьи по соответствующим темам. Например, после вызова справочной страницы для редактора vi вам будет предложено не только ознакомиться с аргументами командной строки, но и перейти к разделу, из которого вы узнаете, как в действитель- ности отредактировать файл. Книги К самым лучшим источникам информации для системных администраторов в книж- ном мире (в дополнение к этой книге :-), конечно) можно отнести серию книг Тима О’Рейли (Tim O’Reilly). Начало этой серии было положено более 20 лет назад книгой UNIX in a Nutshell. Теперь же практически всем важным подсистемам UNIX и Linux (и даже командам) посвящены ее отдельные тома. Эта серия также включает книги по Интернету, Windows и другим темам, не связанным с UNIX. Все эти книги имеют при- емлемую цену, своевременны и ориентированы на конкретную аудиторию. Тим О’Рейли, заинтересовавшись движением, основанным на принципе открыто- го исходного кода, регулярно проводит конференции (OSCON) по этой и другим зло- бодневным темам. Конференции OSCON проводятся дважды в год (по одной в США и Европе). Подробнее см. на сайте oreilly.com. Документы RFC и другие интернет-ресурсы Документы из серии RFC (Request for Comments — запрос на комментарий) опи- сывают протоколы и процедуры, используемые в Интернете. Большинство из этих до- кументов достаточно детализированы и специализированы, но некоторые написаны в виде обзоров. Информации, которую они содержат, вполне можно доверять, и она во многом оказывается полезной для системных администраторов. Более полное описание этих документов можно найти в разделе 14.1. Проект документации по Linux Для систем Linux существует и такой источник справочной информации, как проект Linux Documentation Project (LDP), доступный на веб-сайте tldp. org. Этот сайт пред-
Глава 1. С чего начать 61 ставляет собой центральное хранилище разного рода информации, посвященной Linux: от FAQ (часто задаваемые вопросы) до объемных руководств. Здесь же концентрируются результаты усилий по переводу документации на различные языки. К сожалению, многие LDP-документы практически не обновляются, поэтому быстро устаревают. Всегда обращайте внимание на дату публикации документа, так как по ней можно судить об актуальности информации. 1.11. Другие источники информации Источники информации, рассмотренные в предыдущем разделе, можно охарактери- зовать как самые надежные, но вряд ли это последнее слово в документации по UNIX и Linux. В Интернете же можно найти многочисленные блоги, дискуссионные форумы и новостные веб-каналы и получить с их помощью самую “свежую” информацию. Как и следовало ожидать, система Google стала лучшим другом системного админи- стратора. Именно к Google многие администраторы обращаются за консультацией, если вопрос не касается спецификации конкретной команды или формата файла (но и в этом случае Google обязательно поможет). Возьмите себе за правило (если не хотите впустую терять время и репутацию) при возникновении затруднений выносить свои вопросы на онлайн-форумы, ссылающиеся при ответах на Google.7 Невозможно перечислить все полезные интернет-источники информации по Linux, поэтому упомянем лишь важнейшие из них (табл. 1.5). Можем порекомендовать еще один забавный и полезный ресурс. Это страница “Ro- setta Stone” (розеттский камень) Брюса Гамильтона (Bruce Hamilton), доступная по адресу bhami. com/rosetta. html. Она содержит указатели на команды и утилиты, применяемые для решения основных административных задач в различных операционных системах. Если вы работаете в Linux-системе, не стесняйтесь обращаться к UNIX-ресурсам об- щего назначения. Большая часть информации в них напрямую применима к Linux. Таблица 1.5. Веб-ресурсы, посвященные системному администрированию Веб-сайт Описание blogs.sun.com Огромная коллекция технических статей, посвященных, в основном, Solaris cpan.org Заслуживающая доверия коллекция Perl-модулей freshmeat.net Большой каталог программ для Linux и UNIX kernel.org Официальный веб-сайт разработчиков ядрзД&цх linux.com Unux-форум, прекрасный сайт для новичков Unux. org Неофициальное хранилище информации по Unux linux.slashdot.org Огромный архив новейшей справочной технической информации по Unux linuxhq.com Хранилище информации по ядру и “заплат” к нему lwn.net Сборник материалов по Linux и программам с открытым исходным кодом l*er com Агрегатор новинок по Linux r°otvg.net Сайт, ориентированный на системы AIX с множеством ссылок и форумов securityfocus.com Хранилище информации по общим вопросам компьютерной безопасности serverfault.com Совместно редактируемая база данных вопросов от системных администра- торов Или, в худшем случае, ссылающиеся на Google через lmgtfy.com.
62 Часть I. Основы администрирования Окончание табл. 1.5 Веб-сайт Описание ServerFiles.com Каталог сетевых программных и аппаратных средств slashdot.org Хранилище новейшей справочной технической информации по различным темам solariscentral.org Открытый блог с новостями и статьями по Solaris sun.com/bigadmin Сайт, содержащий информацию по администрированию Sun-систем sunhelp.org Прекрасная коллекция Sun-материалов ugu.com Сайт “Вселенная гуру UNIX” (UNIX Guru Universe) с информацией для систем- ных администраторов а Сейчас его поддерживает Linux Foundation — некоммерческий консорциум развития Linux. 1.12. Как инсталлировать программное обеспечение Подготовка к работе программного обеспечения подробно рассматривается в гла- ве 12. Но ддя самых нетерпеливых мы прямо здесь расскажем о том, как выяснить, что уже установлено в вашей системе, и как получить новое программное обеспечение и ин- сталлировать его. В современных операционных системах программное обеспечение разделено на па- кеты, которые можно инсталлировать независимо друг от друга. При стандартной уста- новке системы используется группа “стартовых” пакетов, которую можно при необхо- димости расширить. Добавочные программные продукты зачастую предоставляются также в виде пред- варительно скомпилированных пакетов, но далеко не во всех системах. Большая часть программного обеспечения создается независимыми группами разработчиков, выпуска- ющих программы в виде исходных кодов. Репозитории пакетов затем берут исходные коды, компилируют их в соответствии с особенностями конкретной системы и вклю- чают в пакеты полученные бинарные файлы. Как правило, намного проще инсталли- ровать бинарную версию пакета, предназначенную для данной системы, чем искать и компилировать исходный код. Однако нужно учитывать, что иногда создатели пакетов на один-два выпуска отстают от текущей версии системы. Если в двух системах используется один и тот же формат обработки пакетов, то это еще не означает, что пакеты обеих систем будут взаимозаменяемыми. Например, в си- стемах Red Hat и SUSE применяется формат RPM, однако структура их файловых си- стем неодинакова. Рекомендуется всегда пользоваться пакетами, созданными для кон- кретной системы. В известных Linux-дистрибутивах предусмотрены отлаженные системы управления пакетами, которые включают средства доступа к репозиториям программных продук- тов и поиска их в Интернете. Дистрибуторы активно поддерживают эти репозитории от имени сообщества, которое они представляют, поэтому у администраторов Linux-систем редко возникает необходимость выходить за рамки стандартного менеджера пакетов. Другими словами, жизнь прекрасна! При этом UNIX-системы демонстрируют больше неопределенности по части управ- ления пакетами. Solaris, HP-UX и AIX предоставляют соответствующие программные средства работы с пакетами, которые функционируют на уровне отдельных машин. Однако производители этих систем не поддерживают репозитории продуктов с откры-
Глава 1. С чего начать 63 тым исходным кодом, и поэтому пользователям, в основном, приходится заниматься самообслуживанием.8 К сожалению, одним из главных звеньев цепочки, которая свя- зывает систему пакетирования в одно целое, является метод ссылки одних пакетов на другие, позволяющий выразить информацию о взаимной зависимости и совместимости. Без центральной координации вся эта экосистема может быстро развалиться на отдель- ные части. Действительность демонстрирует совершенно разные результаты. Дистрибутив Solaris предлагает добавочную систему (pkgutil от blastwave. org), которая предоставляет простую инсталляцию программного обеспечения из интернет-репозитория, во многом подобную системам, содержащимся на Linux-дистрибутивах. Система HP-UX содержит прекрасный интернет-репозиторий в форме HP-UX Porting и Archiving Centre (hpux. connect. org. uk), но пакеты должны быть загружены вручную и по отдельности. Что касается AIX, то пока трудно говорить о возможности использования предварительно скомпонованного программного обеспечения для этой системы. Администраторы без доступа к предварительно скомпонованным бинарным верси- ям пакетов должны инсталлировать системы по-старому, т.е. загрузить архив исходного кода tar, а затем вручную сконфигурировать, скомпилировать и инсталлировать систему. Иногда этот процесс проходит гладко, а иногда может превратиться в кошмар: все зави- сит от используемого программного обеспечения и конкретной операционной системы. В этой книге мы предполагаем, что дополнительное программное обеспечение уже установлено, и не собираемся мучить вас шаблонными инструкциями по инсталляции каждого пакета. При необходимости мы будем указывать точные названия пакетов для выполнения конкретного проекта. Однако большей частью мы не будем повторять ин- струкции по инсталляции, поскольку они практически идентичны для всех пакетов. Определение факта инсталляции программного обеспечения По ряду причин иногда нелегко определить, какой программный пакет содержит нужный компонент. Для того чтобы выяснить, “прописан” ли важный для вас бинарный файл в строке поиска, лучше использовать команду which (а не действовать на пакет- ном уровне). Например, следующая команда сообщает о том, что компилятор GNU С инсталлирован на данном компьютере. aix$ which gcc /opt/pware/bin/gcc Если команда which не помогла, воспользуйтесь командой whereis, которая ведет поиск в системных каталогах без учета строки поиска. Другой вариант — это чрезвы- чайно удобная команда locate, которая просматривает предварительно скомпилиро- ванный индекс файловой системы в поиске имен файлов, соответствующих заданному шаблону. Команда locate входит в состав GNU-пакета findutils, который по умол- чанию включен в большинство систем Linux, но для UNIX его необходимо инсталлиро- вать вручную. С помощью команды locate можно искать не только программы или пакеты, но Файлы любых типов. Например, если не известно точно, где искать файл заголовков signal.h (в нем содержатся определения сигналов Linux), попробуйте поступить так. Репо ^аЗРаб°ТЧИКИ OpenS°laris не предлагают систему управления пакетами и интернет- зиторий. Хотя этих средств нет в Solaris 10, ими предполагается оснастить Solaris 11.
64 Часть I. Основы администрирований ubuntu$ locate signal.h /usr/include/signal.h /usr/include/asm/signal.h /usr/include/asm-generic/signal.h /usr/include/linux/signal.h База данных команды locate периодически обновляется командой updatedb, кото- рая запускается демоном cron. Следовательно, результаты работы команды locate не всегда отражают последние изменения в системе. Ш Подробнее об управлении пакетами рассказывается в главе 12. Если известно имя искомого пакета, воспользуйтесь системными утилитами обра- ботки пакетов, которые непосредственно проверят наличие пакета. Например, в систе- мах Red Hat или SUSE следующая команда определяет наличие интерпретатора языка Python (и его инсталлированной версии): redhat$ rpm -q python python-2.4.3-21.el5 Добавление новых программ Если возникнет необходимость инсталлировать дополнительное программное обе- спечение, вам, прежде всего, нужно определить каноническое имя соответствующего программного пакета. Например, вам следует преобразовать ваше желание “хочу ин- сталлировать locate” в версию “нужно инсталлировать пакет findutils” или пере- вести намерение “инсталлировать named” в вариант “инсталлировать BIND”. В этом вам поможет множество веб-индексов, эффективно работающих при указании конкретной системы, особенно при использовании Google. Например, при введении в поле поиска “команда locate” вас направят точно по адресу. Если вы работаете в системе UNIX, ука- жите также имя операционной системы. Если вам известно имя нужной утилиты, можете загрузить и инсталлировать ее. В Linux и Solaris полная установка обычно состоит в использовании одной команды, по- скольку в этих системах уже инсталлирована утилита pkgutil. Для HP-UX и AIX вам придется загрузить либо предварительно собранный бинарный пакет, либо исходный код проекта. В последнем случае попробуйте с помощью Google найти официальную веб-страницу проекта и загрузить оттуда его исходный код. Следующие примеры демонстрируют инсталляцию утилиты wget для каждой си- стемы, взятой в этой книге в качестве примера. Эта GNU-утилита, которая превращает сетевую загрузку файлов (поддерживающую протоколы HTTP и FTP) в элементарную команду, очень полезна для выполнения сценариев. Утилита wget инсталлируется по умолчанию в каждом из рассматриваемых здесь примеров систем Linux; при этом от- метим, что представленные ниже команды можно использовать как во время начальной инсталляции, так и при последующих обновлениях системы. ®В системе Ubuntu используется программа для установки, обновления и удале- ния программных пакетов в операционных системах Debian (Advanced Package Tool - APT). ubuntu# apt-get install wget Reading package lists... Done Building dependency tree Reading state information... Done
Глава 1. С чего начать 65 wget is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Вот как выглядит версия SUSE. suse# yast —install wget <runs in a terminal-based UI> Вариант инсталляции в системе Red Hat. redhat# yum install wget Loaded plugins: fastestmirror Parsing package install arguments Package wget-1.10.2-7.el5.i386 is already installed and latest version Nothing to do В системе Solaris инсталляция выполняется с помощью уже установленной soians утилиты pkutil (для получения инструкций по данной установке см. сайт blastwave. org). Solaris# /opt/csw/bin/pkgutil —install wget cmultiple pages of output as seven packages are installed> [КЯ Для системы HP-UX мы нашли на сайте hpux. connect. org. uk соответству- ющий бинарный пакет и загрузили его в каталог /tnp. Команды распаковки и инсталляции в этом случае выглядят так. hpux# gunzip /tmp/wget-1.11.4-hppa-ll. 31.depot.gz hpux# swinstall -s /tmp/wget-1.11.4-hppa-ll. 31. depot wget ======= 05/27/09 13:01:31 EDT BEGIN swinstall SESSION (non-interactive) (jobid=hpuxl1-0030) * Session started for user "root@hpuxll". * Beginning Selection * Target connection succeeded for "hpuxll:/". * Source: /tmp/wget-1.11.4-hppa-ll.31.depot * Targets: hpuxll:/ * Software selections: wget.wget-RUN,r=l.11.4,a=HP-UX_B./800 * Selection succeeded. * Beginning Analysis and Execution * Analysis and Execution succeeded. Пакет depot (в строке с командой swinstall) должен быть задан как полный путь, начинающийся косой чертой “/”; в противном случае команда swinstall попытается найти нужный файл в сети. Утилита wget при завершении инсталляции сообщает ко- манде swinstall, какой пакет надо загрузить из файла depot. К сожалению, этот процесс инсталляции в действительности не так прост, как может показаться на первый взгляд. Инсталлируемая версия утилиты wget на самом деле не будет работать, поскольку некоторые библиотеки, от которых она зависит, не инсталли- рованы. hPux$ wget http://samba.org/samba/docs/Samba3-HOWTO.pdf /usr/lib/dld.si: Can't open shared library: /usr/local/lib/libcrypto.si /usr/lib/dld.si: No such file or directory
66 Часть I. Основы администрирования [HP ARIES32] : Core file for 32 bit РА-RISC application [HP ARIES32]: /usr/local/bin/wget saved to /tmp/соге.wget. Утилита swinstall обладает встроенным механизмом управления зависимостями, но его возможности, к сожалению, не распространяются на интернет-репозитории. Прочитайте “паспортные данные” утилиты swinstall и инсталлируйте все необходи- мые для нее пакеты (в данном случае — еще шесть). Сборка программного обеспечения из исходного кода Фактически существует, по крайней мере, один бинарный пакет wget, доступный для AIX в формате RPM. Поиск в Google при заданной строке “aix wget грш” вполне оправдает ваши надежды. После загрузки вам останется выполнить совсем простую ко- манду инсталляции. aix# rpm —install wget-1.11.4-1.aix5.l.ppc.rpm В целях иллюстрации построим AIX-версию пакета wget на основе оригинального исходного кода. Прежде всего, нам нужно найти этот код, но это не проблема: первый же результат, предложенный системой Google для заданной строки поиска “wget”, направит нас пря- мо на страницу GNU-проекта, которая содержит нужные ссылки. После загрузки теку- щей версии в каталог /trap мы распаковываем ее, задаем конфигурацию, компонуем и инсталлируем. aix# cd /top; gunzip wget-1.11.4.tar.gz aix# tar xfp wget-1.11.4.tar aix# cd wget-1.11.4 aix# ./configure —disable-ssl —disable-nls # См. комментарии ниже configure: configuring for GNU Wget 1.11.4 checking build system type... rs6000-ibm-aix config.status: creating src/config.h config.status: executing default commands generating po/POTFILES from ./ро/POTFILES.in creating po/Makefile aix# make <несколько страниц компиляционных сообщений> aix# make install <o странице выходных сообщений> Приведенную последовательность команд инсталляции configure/make/make install обычно применяют для большинства UNIX- и Linux-утилит во всех системах, но, безусловно, при наличии инсталлированной среды разработки и программ, состав- ляющих заданный пакет. При этом будет не лишним прочитать файлы INSTALL или README, сопровождающие данный пакет. В данном случае использование ключей —disable-ssl и —disable-nls в ко- манде configure позволяет опустить некоторые wget-функции, входящие в состав би- блиотек, которые не были инсталлированы (при обслуживании реальной системы вам,* возможно, захочется включить в инсталляцию опущенные здесь части пакета). Чтобы узнать все опции процесса конфигурации, используйте команду configure —help. Обратите внимание на полезную опцию - -pref ±х=каталог команды configure, которая позволит вам поместить программное обеспечение не в каталог /usr/local, а в более подходящий для вас каталог.
Глава 1. С чего начать 67 1.13. Издержки профессии Системные администраторы — настоящие “многостаночники”. Они часто имеют дру- гую работу, просто их попросили присмотреть за несколькими компьютерами “на сторо- не”. Если вы один из таких людей, подумайте, к чему в конце концов это может привести. Чем больше вы будете знать о своей системе, тем больше пользователи будут зави- сеть от вас. Сети неуклонно разрастаются, и вы будете вынуждены тратить все больше и больше времени на выполнение функций администратора. Вскоре окажется, что вы — единственный человек во всей организации, который знает, как решить ряд важнейших проблем. Если коллеги стали считать вас локальным системным администратором, от этой роли уже трудно отказаться. Мы знаем нескольких людей, которым пришлось поменять место работы, чтобы избавиться от дополнительной нагрузки. Поскольку круг обязан- ностей системного администратора четко очертить нельзя, от вас, скорее всего, потре- буют, чтобы вы были не только штатным администратором, но и штатным инженером, писателем, а также специалистом по психоанализу. Практика показывает, что некоторые администраторы, ставшие таковыми волей об- стоятельств (а не по “велению души”), стараются избежать потока просьб о помощи, демонстрируя раздражение и плохо выполняя свои обязанности.9 Не стоит придерживаться такого подхода, так как вы будете плохо выглядеть в гла- зах окружающих и у вас могут возникнуть дополнительные проблемы. Вместо этого мы предлагаем просто фиксировать время, затрачиваемое на системное администрирова- ние. Ведите работу на должном уровне и собирайте доказательства, которые можно бу- дет использовать, когда вы попросите начальника освободить вас от обязанностей адми- нистратора. В большинстве организаций для того, чтобы добиться замены, приходится упрашивать руководство полгода, а то и год, так что учитывайте это в своих планах. С другой стороны, может оказаться, что системное администрирование вам нравится и вы хотите стать штатным администратором. В этом случае проблем с поиском рабо- ты у вас не будет. К сожалению, сама работа от этого не станет легче. О политических аспектах системного администрирования рассказывается в главе 32. 1.14. Рекомендуемая литература • Robbins Arnold. UNIX in a Nutshell (4th Edition). Sebastopol, CA: O’Reilly Media, 2008. • Siever Ellen, Aaron Weber and Stephen Figgins. Linux in a Nutshell (5th Edition). Sebastopol, CA: O’Reilly Media, 2006. • Gancarz Mike. Linux and the Unix Philosophy. Boston: Digital Press, 2003. • Salus Peter H. The Daemon, the GNU & the Penguin: How Free and Open Software is Changing the World. Reed Media Services, 2008. В настоящее время эта захватывающая история развития программного обеспече- ния с открытым исходным кодом, исследованная наиболее известным историком UNIX, переводится в цифровую форму на сайте groklaw. com в соответствии с ли- цензией Creative Commons (Сообщество представителей творческих профессий). 9 Обозначенная тенденция с любовью и черным юмором описана в рассказах Синона Травальи (Simon Travaglia Bastard Operator from Hell на сайте bof h. ntk. net в разделе BOFH.).
68 Часть I. Основы администрирования URL-адрес самой книги достаточно длинный; попытайтесь найти действующую ссылку на сайте groklaw.com или проверьте следующий сокращенный вариант: tinyurl.com/d6u7j. • Raymond Eric S. The Cathedral & The Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol, CA: O’Reilly Media, 2001. Системное администрирование • Limoncelli Thomas A., Christina J. Hogan and Strata R. Chalup. The Practice of System and Network Administration (Second Edition). Reading, MA: Addison-Wesley, 2008. Это прекрасная книга, описывающая политические и процедурные аспекты си- стемного администрирования. Авторы ведут блог по системному администрирова- нию (everythingsysadmin. com). • Frisch ЛПееп. Essential System Administration (3rd Edition). Sebastopol, CA: O’Reilly Media, 2002. Это классическое универсальное руководство по администрированию систем UNIX, которое, к сожалению, уже несколько устарело. Надеемся, что его новая версия уже в работе! Основной инструментарий • Robbins Arnold, Elbert Hannah and Linda Lamb. Learning the vi and Vim Editors. Sebastopol, CA: O’Reilly Media, 2008. • Powers Shelly, Jerry Peek, Tim O’reilly and Mike Loukides. UNIX Power Tools (3rd Edition) . Sebastopol, CA: O’Reilly Media, 2003. • Michael Randal K. Mastering UNIX Shell Scripting: BASH, Bourne, and Korn Shell Scripting for Programmers, System Administrators, and UNIX Gurus. Indianapolis, IN: Wiley Publishing, Inc., 2008. • Robbins Arnold and Nelson H. F. Beebe. Classic Shell Scripting. Sebastopol, CA: O’Reilly Media, 2005. • Wall Larry, Tom Christiansen and Jon Orwant. Programming Perl (3rd Edition). Cambridge, MA: O’Reilly Media, 2000. • Christiansen Tom and Nathan Torkington. Perl Cookbook (2nd Edition). Sebastopol, CA: O’Reilly Media, 2003. • Blank-Edelman David N. Automating System Administration with Perl (2nd Edition). Sebastopol, CA: O’Reilly Media, 2009. • Pilgrim Mark. Dive Into Python. Berkeley, CA: Apress, 2004. К этой книге есть свободный веб-доступ по адресу: diveintopython.org. • Flanagan David and Yukihiro Matsumoto. The Ruby Programming Language. Sebastopol, CA: O’Reilly Media, 2008. Эта книга, имеющая оптимистический подзаголовок Everything You Need to Know (Все, что вам необходимо знать), к сожалению, написана несколько суховато. Но она подкупает полнотой описания языка Ruby (версии 1.9) с богатством деталей, которые могут быть известны лишь создателюязыка. Это самая лучшая книга для тех, кто уже владеет (на практическом уровне) языками Perl или Python.
Глава 1. С чего начать 69 1.15. Упражнения 1.1. Какую команду нужно ввести, чтобы получить информацию о драйвере терминала tty (а не о команде tty)? Как прочитать соответствующую страницу документа- ции, хранящуюся в каталоге /usr/local/share/man? 1.2. Определяет ли общий конфигурационный файл поведение команды man в ва- шей системе? Какие строки нужно в него добавить, чтобы локальные материалы хранились в каталоге /doc/man? Как организовать каталог /doc/man, чтобы его структура соответствовала иерархии справочных страниц? 1.3. Как в настоящее время протекает разработка ядра Linux? Каковы наиболее акту- альные вопросы? Какие организации играют в этом процессе ключевую роль? Кто руководит проектом? 1.4. ★Изучите возможности нескольких систем UNIX и Linux и порекомендуйте опе- рационную систему для каждого из перечисленных ниже случаев. Аргументируйте свой выбор. а) домашний компьютер пользователя б) университетская компьютерная лаборатория в) корпоративный веб-сервер д) серверный кластер, обеспечивающий работу базы данных для судоходной ком- пании 1.5. ★Предположим, вы обнаружили, что определенное свойство демона httpd серве- ра Apache работает не так, как описано в документации к Ubuntu. а) что нужно сделать перед тем, как сообщать об ошибке? б) если вы решили, что это действительно ошибка, то кого нужно уведомить и каким способом? в) какую информацию необходимо включить в отчет об ошибке? 1.6. ★★Системы Linux серьезно заявили о себе в производственных средах. Обречены ли UNIX-системы? Почему?
Глава Сценарии и командная оболочка Настоящие системные администраторы пишут сценарии. Сценарии позволяют стан- дартизировать и автоматизировать выполнение рутинных операций по администрирова- нию систем, тем самым освобождая столь ценное время администраторов для решения? более важных и более интересных задач. В известном смысле сценарии — это докумен- тирование действий в виде официального перечня команд, необходимых для выполне- ния конкретной задачи. Сценарии бывают самыми разными: от очень простых, которые инкапсулируют всего несколько статических команд, до значительных программных проектов, управляющих конфигурациями хостов и административной информацией всего узла. В этой книге нас, главным образом, интересуют небольшие повседневные сценарные проекты, с ко- торыми обычно имеют дело системные администраторы, поэтому мы не будем подроб- но останавливаться на функциях поддержки (например, отслеживание ошибок и оценка проекта), необходимых для более крупных проектов. При написании административных сценариев следует делать акцент на эффектив- ности работы программиста и ясности кода, а не на производительности вычисли- тельных средств. Не может служить оправданием для небрежно написанного сценария время его выполнения, т.е. не так уж важно, выполняется он за полсекунды или за две. Удивительно, но оптимизация слабо оправдывает затраты, даже в случае сценариев, ко- торые регулярно выполняются демоном cron. В течение долгого времени стандартный язык написания административных сцена- риев определялся командной оболочкой. В большинстве систем используется оболочка bash (“2toume-again” sAell — “возрожденная” оболочка Борна), но в ряде систем UNIX
Глава 2. Сценарии и командная оболочка 71 все еще работают sh (оригинальная оболочка Борна) и ksh (оболочка Корна). Сценарии оболочки обычно применяются для выполнения таких несложных задач, как автоматиза- ция последовательности команд или сборка нескольких фильтров для обработки данных. Командная оболочка всегда доступна, поэтому ее сценарии отличаются относитель- ной переносимостью и независимостью, в отличие от вызываемых ими команд. Пока вы будете выбирать оболочку, она может выбрать вас: большинство сред включает объеми- стое дополнение уже существующих sh-сценариев, с которыми администраторам часто приходится знакомиться, разбираться и заниматься их настройкой. При написании более сложных сценариев желательно использовать такие языки про- граммирования, как Perl или Python, поскольку они оба хорошо подходят для выполне- ния административной работы. Эти языки (по сравнению с командной оболочкой) во- брали в себя такие мощные достижения в области создания языков программирования последних двух десятилетий и оснащены такими возможностями по части обработки текстов (столь бесценные для системных администраторов), что оболочке sh остается лишь “рыдать от стыда где-то в уголке”. Основной недостаток языков Perl и Python состоит в отсутствии четкости в установке их сред, особенно в случае, если вы начинаете использовать библиотеки с откомпилиро- ванными компонентами от сторонних производителей. Командная оболочка не страдает такой проблемой, поскольку не имеет модульной структуры и не содержит сторонних библиотек. В этой главе дается краткий обзор языковых инструментов написания сценариев bash, Perl и Python, а также регулярных выражений. 2.1. Основы РАБОТЫ КОМАНДНОЙ ОБОЛОЧКИ Прежде чем обсуждать написание сценариев оболочки, рассмотрим некоторые базо- вые команды и синтаксис языка командной оболочки. Материал этого раздела актуален для всех основных оболочек sh-семейства (включающего оболочки bash и ksh, но не csh или tcsh), вне зависимости от используемой вами платформы. Опробуйте формы, с которыми вы пока еще не знакомы, и не бойтесь экспериментировать! Редактирование команд Мы наблюдали, как многие редактируют командные строки с помощью клавиш управления курсором. Вы ведь так не поступаете в своем текстовом редакторе, верно? Все основные команды редактора emacs доступны при редактировании уже выпол- ненного ряда команд (т.е. “предыстории”). Нажав комбинацию клавиш <Ctrl+E>, вы переместитесь в конец строки, а с помощью комбинации клавиш <Ctrt+A> — в начало. Нажатие комбинации клавиш <Ctrl+P> позволяет вернуться к предыдущим комавдви*» вызвать их для редактирования. С помощью комбинации клавиш <Ctrl+R> вы сможете шаг за шагом “прокрутить” свою “предысторию” и найти старые команды. Если вы предпочитаете использовать редактор vi, переключите свою командную оболочку в режим vi. $ set -о vi В режиме vi редактирование является модальным, но вы начинаете работать в ре- жиме ввода команд. Для того чтобы выйти из режима ввода, нажмите вначале клайй- шу <Esc>, а затем клавишу <i>, чтобы вернуться в него. В режиме редактирования на- жатие клавиши <w> переместит вас вперед на одно слово; использование комбинаций
72 Часть I. Основы администрирования клавиш <f+X> позволит найти следующий символ “X” в строке и т.д. “Прогуляться” по командам, зафиксированным в “предыстории”, можно с помощью клавиш <Esc> и <к>. Решили вернуться в режим emacs-редактирования? Выполните эту команду. $ set -о emacs Каналы и перенаправление потоков Каждому процессу доступны по меньшей мере три информационных канала: “стан- дартный ввод” (STDIN), “стандартный вывод” (STDOUT) и “стандартная ошибка” (STDERR). Эти каналы устанавливаются ядром системы “от имени процесса”, и поэ- тому сам процесс не обязательно знает их направленность. Они, например, могут быть связаны с окном терминала, файлом, подключением к сети или с каналом, принадлежа- щим к другому процессу. Для систем UNIX используется унифицированная модель ввода-вывода, в которой каждому каналу присваивается целое число, именуемое файловым дескриптором. Точное число (номер), назначаемое каналу, обычно не имеет значения, но каналам STDIN, STDOUT и STDERR гарантированно соответствуют файловые дескрипторы 0, 1 и 2 со- ответственно, чтобы обеспечить безопасное обращение к ним по номерам. В контексте интерактивного окна терминала канал STDIN обычно считывает данные с клавиатуры, а оба канала STDOUT и STDERR записывают свои выходные данные на экран. Большинство команд принимает входные данные из канала STDIN. Выходная ин- формация записывается ими в канал STDOUT, а сообщения об ошибках — в канал STDERR. Это соглашение позволяет объединять команды подобно строительным бло- кам для организации конвейерной обработки данных. Командная оболочка интерпретирует символы и “»” как инструкции по изменению направления передаваемых командой данных в файл или принимаемых данных из файла. Символ “<” связывает канал STDIN с содержимым некоторого суще- ствующего файла. Символы “>” и “»” перенаправляют поток STDOUT; причем символ “>” используется для замены содержимого файла, а “»” — для добавления данных в его конец. Например, команда $ echo "Это тестовое сообщение." > /tmp/mymessage сохраняет одну строку в файле /tmp/mymessage (при необходимости файл будет соз- дан). Следующая команда отправляет содержимое этого файла по электронной почте пользователю johndoe. $ mail -s "Mail test" johndoe < /tmp/mymessage Для того чтобы перенаправить потоки STDOUT и STDERR в одно и то же место, ис- пользуйте символ “>&”. Для того чтобы перенаправить только поток STDERR, исполь- зуйте вариант “2>”. На примере команды find можно показать, почему важно обрабатывать потоки STDOUT и STDERR отдельно. Дело в том, что она формирует выходные данные по обо- им каналам, особенно в случае ее выполнения непривилегированным пользователем. Например, при выполнении команды $ find / -name core обычно генерируется так много сообщений об ошибках “permission denied” (отсутствие прав доступа), что настоящие результаты поиска теряются в “шуме”. Чтобы отбросить все сообщения об ошибках, можно использовать такой вариант. $ find / -name core 2> /dev/null
Глава 2. Сценарии и командная оболочка 73 В этой версии команды find только настоящие совпадения (где пользователь имеет разрешение на чтение родительского каталога) выводятся в окно терминала. Чтобы со- хранить список совпадающих путей в файле, выполните такую команду. $ find / -name core > /trap/corefiles 2> /dev/null Эта командная строка отправляет совпадающие пути в файл /tmp/corefiles, от- брасывая все ошибки и ничего не посылая в окно терминала. Для того чтобы связать канал STDOUT одной команды с каналом STDIN другой, ис- пользуйте символ “ | ”. Вот два примера. $ ps -ef | grep httpd $ cut -d: -f7 < /etc/passwd | sort -u В первом примере выполняется команда ps, генерирующая список процессов, из которого при “проходе” через команду grep выбираются строки, содержащие слово “httpd”. Результат выполнения команды grep никуда больше не перенаправляется, поэ- тому совпадающие строки попадают в окно терминала. Во втором примере команда cut выбирает из файла /etc/passwd пути к оболоч- ке каждого пользователя. Список оболочек затем отправляется через команду sort -и, чтобы сформировать отсортированный список уникальных значений. Для того чтобы последующая команда выполнялась только в случае успешного вы- полнения предыдущей, можно разделить эти команды символом Например, ко- мандная строка $ Ipr /tmp/t2 && rm /tmp/t2 удалит файл /tmp/t2 тогда и только тогда, когда она успешно дождется очередаьна печать. В данном случае успех выполнения команды 1рг будет зафиксирован при по- лучении кода завершения, равного нулю. Использование для этой цели символу озна- чающего операцию “логическое И”, может сбить с толку тех, кто в других язЫ^ЙПро- граммирования использовал вычисления в сокращенной форме записи. ЕсЛИ кому-то это непонятно, не стоит слишком долго здесь застревать; а просто примите это как иди- ому командной оболочки. И наоборот, символ “ | | ” обеспечит выполнение следующей команды только в том случае, если предыдущая команда не выполнится (т.е. сгенерирует ненулевое значение кода завершения). Для того чтобы разбить команду на несколько строк, для наглядности отделяя тем самым код обработки ошибок от остальной части командного конвейера, можно ис- пользовать в сценариях обратную косую черту. ср —preserve —recursive /etc/* /spare/backup I I echo "Did NOT make backup" Для получения обратного эффекта, т.е. объединения нескольких команд в одной строке, можно использовать в качестве разделителя точку с запятой. Использование переменных и кавычек В операциях присваивания имена переменных никак не маркируются, но предваря- ются знаком доллара при ссылке на их значения. $ etcdir='/etc’ $ echo $etcdir /etc
74 Часть I. Основы администрирования Не ставьте до и после знака равенства (=) пробелы, в противном случае оболочка ошибочно примет имя вашей переменной за имя команды. При ссылке на переменную можно заключить ее имя в фигурные скобки, чтобы син- таксический анализатор (да и сам человек) не сомневался в том, где заканчивается имя переменной и начинается другой текст; например, используйте запись ${etcdir} вме- сто $etcdir. Обычно без фигурных скобок можно обойтись, но они могут оказаться по- лезными в случае, если вам понадобится раскрывать переменные в строках с двойными кавычками. Часто нужно сделать так, чтобы после значения переменной стояли буквы или знаки препинания. $ echo "Saved ${rev}th version of mdadm.conf.” Saved 8th version of mdadm.conf. Для имен переменных командной оболочки не существует стандартного соглашения, но обычно предполагается, что имена, полностью написанные прописными буквами, принадлежат переменным среды или переменным, считанным из файлов глобальной конфигурации. И чаще всего все буквы в именах локальных переменных — строчные, а отдельные их компоненты разделяются символами подчеркивания. Вообще имена пе- ременных чувствительны к регистру букв. Переменные среды автоматически импортируются в пространство имен оболочки bash, поэтому их можно устанавливать и считывать с использованием стандартного синтаксиса. Для того чтобы перевести переменную оболочки в ранг переменной среды, используйте команду export имя_переменной. Команды для переменных среды, ко- торые вы хотите установить во время регистрации (при входе в систему), должны быть включены в ваш файл ~/.profile или -/ .bash profile. Другие переменные среды, такие как PWD (для хранения имени текущего рабочего каталога), автоматически созда- ются командной оболочкой. Командная оболочка интерпретирует строки, заключенные в одинарные и двойные кавычки, почти одинаково. Различие состоит в том, что строки в двойных кавычках служат субъектами для универсализации файловых имен (замены реальных символов в имени и расширении файла универсальными, т.е. такими метасимволами, как и “?”) и для раскрытия переменных (замены переменных их значениями). $ mylang="Pennsylvania Dutch” $ echo "I speak ${mylang}." I speak Pennsylvania Dutch. $ echo 'I speak ${inylang}. ’ I speak ${mylang}. Обратные апострофы (также известные как обратные галочки, левые кавычки, ле- вые одиночные кавычки или открывающие кавычки) интерпретируются аналогично двойным кавычкам, но несут при этом дополнительную нагрузку. Эта нагрузка состоит в интерпретации содержимого такой строки, как команды оболочки, выполнении этой команды и замене строки результатом выполнения этой команды. $ echo "There are 'wc -1 /etc/passwd4 lines in the passwd file." There are 28 lines in the passwd file. Команды общих фильтров Любые корректные команды, которые считывают входные данные из канала STDIN и записывают результаты в канал STDOUT, могут быть использованы в качестве филь- тра (т.е. компонента конвейера) для обработки данных. В этом разделе мы кратко рас-
Глава 2. Сценарии и командная оболочка 75 смотрим некоторые из часто используемых команд фильтрации (хотя их полный список практически бесконечен). Команды фильтрации отличаются настолько сильным “кол- лективизмом”, что порой даже трудно продемонстрировать их идивидуальное исполь- зование. Большая часть команд фильтрации принимает в командной строке одно или не- сколько имен файлов. И только в том случае, если вы не можете задать соответствую- щие файлы, указывайте в качестве источника считываемой информации стандартный входной поток. Команда cut: разбивка строк на поля Команда cut выводит выбранные части входных строк. Чаще всего эта команда используется для извлечения полей (ограниченных некоторыми разделителями), как в приведенном выше примере, который для удобства читателей повторим еще раз. $ cut -d: -f7 < /etc/passwd | sort -u Команда cut также может возвращать сегменты, определенные границами столбцов текста. В качестве стандартного разделителя служит символ <ТаЬ>, но с помощью ключа -d разделители можно изменить. Ключ -f позволяет указать, какие поля нужно вклю- чить в результат. Еще один пример использования команды cut показан в разделе, посвященном ко- манде uniq (см. ниже). Команда sort: сортировка строк Команда sort сортирует входные строки. Звучит просто, да? Хотя на самом деле не все так безоблачно: существуют потенциальные нюансы, связанные с точно заданными частями сортируемых строк (т.е. с использованием сортировочного ключа) и порядком сортировки. Наиболее распространенные варианты применения этой команды показа- ны в табл. 2.1, в отношении же остальных случаев обратитесь к соответствующей шап- странице. Таблица 2.1. Ключи команды sort .................................... -ь -f -к Игнорировать ведущие пробельные символы Сортировать независимо от регистра букв Указать столбцы, которые формируют сортировочный ключ -п Сравнивать поля как целые числа -г Изменить порядок сортировки на противоположный -t Установить разделитель полей (по умолчанию — пробельный символ) -и Выводить только уникальные записи На примерах приведенных ниже команд демонстрируется различие между число- вой и лексикографической сортировкой (последняя действует по умолчанию). В обеих командах используются ключи -t: и -кЗ, 3 для сортировки файла /etc/group пегего третьему полю (в качестве разделителя используется двоеточие), содержащему иденти- фикатор (ID) группы. Первая команда реализует числовую сортировку, а вторая — лек- сикографическую (в алфавитном порядке).
76 Часть I. Основы администрирования $ sort -t: -к3,3 -n /etc/group1 root:x:0: bin:x:1:daemon daemon:x:2: $ sort -t: -k3,3 /etc/group root:x:0: bin:x:1:daemon users:x:100: Команда uniq: вывод уникальных строк Команда uniq по существу подобна команде sort -и, но у нее есть некоторые по- лезные ключи, которые команда sort не эмулирует. Так, ключ -с используется для под- счета количества экземпляров каждой строки, ключ -d — для отображения только строк, имеющих дубликаты, а ключ -и — для отображения только строк, не имеющих дубли- каты. При этом входные данные должны быть предварительно отсортированы, обычно путем “пропускания” через команду sort. Например, по результатам выполнения следующей команды видно, что у 20 пользо- вателей поле login shell (стартовая оболочка) содержит значение /bin/bash и у 12 — /bin/false. (Последний результат характерен либо для псевдопользователей, либо для пользователей, учетные записи которых были заблокированы.) $ cut -d: -f7 /etc/passwd | sort | uniq -с 20 /bin/bash 12 /bin/false Команда wc: подсчет строк, слов и символов Подсчет количества строк, слов и символов в файле — еще одна распространенная операция, удобным средством реализации которой и является команда wc (word count). Выполненная без каких-либо ключей, она выведет все три результата подсчета. $ wc /etc/passwd 32 77 2003 /etc/passwd В контексте написания сценариев команду wc часто применяют только с одним из ключей (-1, -w или -с), чтобы результат ее выполнения состоял из одного числа. Эту форму чаще всего можно встретить внутри обратных апострофов, и тогда результат мо- жет быть сохранен или использован по назначению. Команда tee: копирование входного потока в два места Командный конвейер, как правило, действует прямолинейно, но зачастую полез- но распараллелить поток данных, т.е. “перехватить” его и отправить копию в файл или- окно терминала. Это можно сделать с помощью команды tee, которая отправляет свой стандартный входной поток как в стандартный выходной канал, так и в файл, указан- ный в командной строке. Представьте действие этой команды в виде тройника в трубо- проводе (перев. с англ, tee — тройник). 1 Команда sort принимает спецификацию ключа -кЗ (вместо -Jk3,3), но в этом случае вы, скорее всего, не получите ожидаемого результата. Без завершающего номера поля сортировочный ключ продолжится до конца строки.
Глава 2. Сценарии и командная оболочка 77 Устройство /dev/tty можно считать синонимом для текущего терминала. Например, команда $ find / -name core | tee /dev/tty | wc -1 выводит найденные путевые имена файлов core и результат подсчета их количества. Часто работа конвейера с командой tee, выводящей результаты и в файл, и в окно терминала (для проверки), занимает много времени. Вы можете понаблюдать за первы- ми результатами, чтобы убедиться в том, что все работает как надо, а затем смело уходи- те: ведь результаты же сохранятся в файле. Команды head и tail: чтение файла с начала или с конца Просмотр строк с начала или конца файла — обычная административная операция. Команды head и tail отображают по умолчанию десять строк, но вы можете использо- вать ключ, задающий желаемое количество строк. Для интерактивного использования команда head уже несколько устарела, и вместо нее (в этом контексте) часто используется команда less, которая разбивает файлы для отображения по страницам. Но команду head можно успешно применять в сценариях и с другой целью. С командой tail используется ключ -f, который чрезвычайно полезен для системных администраторов. Вместо немедленного завершения (после вывода тре- буемого количества строк) команда tail -f ожидает “прибытия” новых строк, которые (как только они появятся “на горизонте”) будут добавлены в конец файла, а затем выве- дены по назначению, что очень удобно для мониторинга журналов регистрации. Однако следует иметь в виду, что программа, которая реализует запись данных в файл, может буферизировать свои выходные данные. Даже если строки будут добавляться регулярно (с точки зрения логики), они могут стать видимыми только фрагментами объемом 1 или 4 Кбайт (KiB).2 Для остановки процесса мониторинга нажмите комбинацию клавиш <Ctrl+C>. Команда grep: поиск текста При выполнении команды grep по мере просмотра входного текста выводятся стро- ки, которые совпадают с заданным образцом (шаблоном). Свое название эта команда получила “в наследство” от команды д/regular_expression/p) из старого (и ныне действующего) редактора ed, используемого в самых первых версиях UNIX. “Регулярные выражения” (regular expressions) — это шабло®^ предназначенные для поиска совпадающего с ними текста и написанные на стаяй^^ИЙм языке шаблонов. Они представляют собой универсальный стандарт, используемый большинством про- грамм при поиске по совпадению с шаблоном, хотя и с небольшими различиями в реа- лизациях. Странное имя команды уходит своими корнями в оригинальные изыскания соответствующих разделов теории вычислений. Более детально синтаксис регулярных выражений рассматривается в разделе 2.3. Подобно большинству фильтров, команда grep имеет множество ключей. Например, ключ -с позволяет выводить количество совпавших строк, ключ -i служит дл%игнори- Рования регистра букв при сопоставлении, а ключ -v предназначен для вывода отли- чающихся (а не совпавших) строк. Очень полезным является ключ -1 (прописная бук- Ва “L”), который заставляет команду grep выводить только имена файлов, содержащие совпавшие с шаблоном строки, а не все совпавшие строки. Например, выполнение команды 2 О единицах измерения см. в разделе 1.8 главы 1. *
78 Часть I. Основы администрирования $ sudo grep -1 mdadm /var/log/* /var/log/auth.log /var/log/syslog.0 демонстрирует, что записи с именем утилиты mdadm нашлись в двух различных файлах системных журналов. Команду grep можно считать классической реализацией базового механизма ис- пользования регулярных выражений, но в некоторых версиях предлагается выбор других диалектов. Например, Linux-команда grep -р служит для поиска выражений в стиле языка Perl, хотя в справочных страницах можно найти неопределенное предупреждение о том, что такой вариант носит “экспериментальный характер”. Для полной уверенно- сти в своих сценариях просто используйте язык Perl или Python. 2.2. Написание bash-сценариев Командный арсенал оболочки bash позволяет успешно писать простые сценарии (без этого средства автоматизации системным администраторам пришлось бы вручную вводить команды в командную строку). Ваше мастерство в использовании командных строк вы должны воплотить в искусстве создания bash-сценариев (и наоборот), что по- может вам извлечь максимальную пользу из времени, потраченного на изучение обо- лочки bash. Но когда окажется, что ваш bash-сценарий превысил в объеме сотню строк или вам потребовались средства, которыми bash не обладает, это будет означать, что настало время переходить к языку Perl или Python. В среде bash комментарии начинаются со знака # и продолжаются до конца строки. Как и в командной строке, вы можете разбить одну логическую строку на несколько физических строк, обозначив переход на новую строку символом обратной косой чер- ты (). И, наоборот, можно поместить на одной строке несколько операторов, разделив их точкой с запятой. Сценарий для оболочки bash может состоять только из последовательности команд- ных строк. Например, следующий сценарий helloworld просто выполняет команду echo. #!/bin/bash echo "Hello, world!" Первая строка содержит “банальный” описательный оператор, который сообщает, что данный текстовый файл является сценарием, предназначенным для интерпретации командной оболочкой /bin/bash. При принятии решения о том, как выполнить этот файл, ядро отыщет соответствующий синтаксис. С точки зрения оболочки, “стремящей- ся” выполнить этот сценарий, первая строка представляет собой просто комментарий. Если бы оболочка находилась в другом каталоге, вам пришлось бы отредактировать эту строку. Для того чтобы подготовить этот файл к выполнению, достаточно установить его бит, “отвечающий” за выполнение (см. раздел 6.5). $ chmod +х helloworld $ . /helloworld3 Hello, world! 3 Если ваша оболочка понимает команду helloworld без префикса . /, это означает, что в ва- шем пути поиска указан текущий каталог (.). И это плохо, поскольку дает другим пользователям возможность устраивать для вас “ловушки” в надежде, что вы будете пытаться выполнить опреде- ленные команды при переходе к каталогу, в котором они имеют доступ для записи.
Глава 2. Сценарии и командная оболочка 79 Можно также непосредственно запустить (активизировать) оболочку в качестве ин- терпретатора сценария. $ bash helloworld Hello, world! $ source helloworld Hello, world! Первая команда выполнит сценарий helloworld в новом экземпляре оболочки bash, а вторая — заставит вашу начальную оболочку прочитать содержимое файла, а затем выполнить его. Второй вариант полезен в случае, когда сценарий устанавдива- ет переменные среды или выполняет другие операции настройки, применимые толь- ко к текущей оболочке. Обычно этот вариант используется при написании сценариев, включающих содержимое файла конфигурации, написанного в виде ряда присваиваний значений bash-переменным.4 Ш Подробнее о битах разрешения (доступа) можно прочитать в разделе 6.5. Если вы пришли сюда из мира Windows, то вам привычно использовать понятие рас- ширения файла, по которому можно судить о типе файла, а также о том, можно ли его выполнить. В мире UNIX и Linux признак того, может ли файл быть выполнен (и если да, то кем), содержится в специальных битах полномочий. При желании вы можете на- делить свои bash-сценарии суффиксом . sh, который бы напоминал вам об их типе, но тогда при выполнении соответствующей команды вам придется вводить суффикс . sh, поскольку UNIX не интерпретирует расширения специальным образом. От команд к сценариям Прежде чем переходить к особенностям написания bash-сценариев, остановимся на методике этого процесса. Многие пишут bash-сценарии так же, как Perl- или Python- сценарии, т.е. используя какой-нибудь текстовый редактор. Но все же удобнее рассма- тривать в качестве интерактивной среды разработки сценариев режим с приглашением на ввод команды. Предположим, например, что у вас есть журналы регистрации, именованные с суф- фиксами .log и .LOG и разбросанные по всей иерархической системе каталогов. Допустим также, что вы хотите изменить эти суффиксы, приведя их к “прописному” виду. Прежде всего, попытаемся отыскать все эти файлы. $ find . -name ’ * *log ’ •do-not-touch/important.log admin.com-log/ foo.log genius/spew.log leather_flog Так, похоже на то, что нам надо включить в шаблон точку и игнорировать при поис- ке каталоги. Нажмите комбинацию клавиш <Ctrl+P>, чтобы вернуть команду в команд- НУ1° строку, а затем модифицируйте ее. $ find . -type f -name '*.log ’ •do-not-touch/important.log foo.log 4 Синонимом для команды source служит команда “с точкой” (dot-команда), например • helloworlcL м
80 Часть I. Основы администрирования genius/spew.log Ну вот, это уже выглядит лучше. Правда, каталог .do-not-touch (т.е. “не трогать”) вызывает смутное чувство опасности; но мы можем избавиться от этого неприятного хо- лодка. $ find . -type f -name '*.log ' | grep -v .do-not-touch foo.log genius/spew.log Теперь все в порядке: мы получили абсолютно точный список файлов, которые долж- ны быть переименованы. Попробуем сгенерировать несколько новых имен. $ find . -type f -name '*.log ’ | grep -v .do-not-touch | while read fname > do > echo mv $ fname $ {fname/. log/. LOG/} > done mv foo.log foo.LOG mv genius/spew.log genius/spew.LOG Да, это именно те команды, которые позволят переименовать нужные файлы. А как мы это делаем в реальности? Мы могли бы снова вызвать уже выполненную команду и отредактировать команду echo, чтобы заставить оболочку bash выполнять команды mv, а не просто выводить их. Ведь передача команд в отдельную копию оболочки bash — более надежный вариант работы, который к тому же требует меньшего объема редакти- рования. Нажав комбинацию клавиш <Ctrl+P>, мы обнаруживаем, что оболочка bash забот- ливо свернула наш мини-сценарий в одну-единственную строку. К этой “уплотненной” командной строке мы просто добавляем канал, передающий наши выходные данные ко- манде bash -х. $ find . -type f -name '*.log ' | grep -v .do-not-touch | while read fname; do echo mv $ fname ${fname/.log/.LOG/}; done | bash -x + mv foo.log foo.LOG + mv genius/spew.log genius/spew.LOG Ключ -x команды bash обеспечивает вывод каждой команды перед ее выполнением. Теперь мы завершили переименование файлов, но нам хотелось бы сохранить этот сценарий, чтобы можно было использовать его снова. Встроенная в bash команда fc по своему действию во многом аналогична нажатию комбинации клавиш <Ctrl+P>, но вместо возврата последней команды в командную строку она передает команду в задан- ный вами редактор. Добавьте в свой файл строку идентификационного комментария, поместите сохраненный файл в приемлемый для вас каталог (например, -/bin или / usr/local/bin), сделайте файл исполняемым, и вы получите настоящий сценарий. Итак, подытожим^ • Разрабатывайте сценарий (или его часть) в виде конвейера команд, причем поша- гово и в режиме выполнения командных строк. • Пересылайте результат в стандартный выходной поток, проверяя правильность ра- боты используемых вами команд. • На каждом этапе используйте буфер ранее выполненных команд для их появления в командной строке и инструменты редактирования — для их модификации.
Глава 2. Сценарии и командная оболочка 81 • Пока вы получаете неправильные результаты, можно считать, что вы, по сути, ни- чего не сделали, и до тех пор, пока команды не заработают так, как надо, ничего (из уже сделанного) не надо удалять. • Если результат выглядит правильным, выполните команды на реальном примере, чтобы убедиться, что все получилось так, как ожидалось. • Используйте команду f с, чтобы зафиксировать свою работу в редакторе, оформи- те ее соответствующим образом и сохраните. В приведенном выше примере мы вывели командные строки, а затем направили их в подоболочку для выполнения. Этот метод не является универсально применимым, но часто оказывается полезным. В качестве альтернативного варианта можно фиксировать результаты, перенаправляя их в файл. Терпеливо добивайтесь получения нужных резуль- татов, и пока вы не увидите их, не выполняйте никаких потенциально деструктивных действий. Организация ввода и вывода данных Команда echo не отличается интеллектуальностью, но зато проста в применении. Для получения большего контроля над выводом данных используйте команду printf. Она не очень удобна, поскольку предполагает, что вы должны в явном виде указывать в нужных для вас местах символы перехода на новую строку (п), но позволяет использо- вать символ табуляции и другие средства форматирования результата. Сравните резуль- таты выполнения следующих двух команд. $ echo ”taatbbtccn" taatbbtccn $ printf "taatbbtccn" аа bb сс В некоторых системах работа команд echo и printf поддерживается на уровне ОС (обычно соответствующие им исполняемые файлы хранятся в каталогах /bin и /usr/ bin соответственно). Хотя эти команды и встроенные в оболочку утилиты в целом по- добны, они могут иметь незначительные отличия, и особенно это касается команды printf. Вы можете либо придерживаться bash-синтаксиса, либо вызывайте “внеш- нюю” команду printf, указывая ее полный путь. Для того чтобы сформировать для пользователя приглашение ввести данные, можно использовать команду read. # !/bin/bash echo -п ’’Введите свое имя: ’’ read user_name if [ -n "$user_name" ]; then echo ’’Привет $user_name!’’ exit 0 else echo ”Вы не назвали свое имя!” exit 1 fi Ключ -п в команде echo подавляет привычный переход на новую строку, но здесь была бы кстати команда printf. Мы еще рассмотрим вкратце синтаксис оператора if, Но его действие здесь, с нашей точки зрения, очевидно. Ключ -п в операторе if обе-
82 Часть I. Основы администрирования спечит значение истины, если его строковый аргумент не окажется нулевым. Вот как выглядит результат выполнения этого сценария. $ sh readexanple Введите свое имя: Ron Привет Ron! Функции и аргументы командной строки Аргументы командной строки служат для сценария переменными с числовыми име- нами: $1 — первый аргумент командной строки, $2 — второй и т.д. Аргумент $0 содер- жит имя, по которому был вызван сценарий, например . /bin/example. sh, т.е. это не фиксированное значение. Переменная $# содержит количество переданных аргументов командной строки, а переменная $ * — все эти аргументы. Ни одна из этих переменных не учитывает ар- гумент $0. При вызове сценария с некорректными аргументами или вообще без них должно быть выведено короткое сообщение с напоминанием о том, как следует использовать данный сценарий. Приведенный ниже сценарий, принимающий два аргумента, прове- ряет, являются ли оба эти аргумента каталогами, и, убедившись в этом, отображает их. Если аргументы оказываются недопустимыми, сценарий выводит сообщение о его пра- вильном использовании и завершается с ненулевым значением кода возврата. Если про- грамма, вызвавшая этот сценарий, проверит код возврата, она будет “знать”, что этот сценарий не удалось выполнить корректно. # !/bin/bash function show_usage { echo ’’Использование: $0 source_dir dest_dir" exit 1 } # Основная программа начинается здесь if [ $# -ne 2 ]; then show_usage else # Существуют два аргумента if [ -d $1 ]; then source_dir=$l else echo ’Недопустимый каталог-источник’ show_usage fi if [ -d $2 ] ; then dest_dir=$2 else echo ’Недопустимый каталог-приемник’ show_us>tge fi fi printf "Каталог-источник: ${source_dir}n" printf "Каталог-приемник: ${dest_dir}n"
Глава 2. Сценарии и командная оболочка 83 Для вывода сообщения о правильном использовании данного сценария мы создали отдельную функцию show usage. Если бы позже этот сценарий был модифицирован и стал бы принимать дополнительные аргументы, это сообщение нужно было бы изме- нить только в одном месте.5 $ mkdir ааа ЬЬЬ $ sh showusage ааа ЬЬЬ Каталог-источник: ааа Каталог-приемник: ЬЬЬ $ sh showusage foo bar Недопустимый каталог-источник Использование: showusage source_dir dest_dir Аргументы bash-функций обрабатываются практически так же, как аргументы ко- мандной строки: $1 — первый аргумент командной строки, $2 — второй и т.д. Как вид- но из приведенного выше примера, аргумент $0 содержит имя сценария. Для того чтобы сделать предыдущий пример более устойчивым к ошибкам, мы могли бы заставить функцию show usage принимать в качестве аргумента код ошибки. Это позволило бы конкретизировать код возврата для каждого типа отказа. Реализация этой идеи показана в следующем фрагменте программы. function show_usage { echo "Использование: $0 source_dir dest_dir" if [ $# -eq 0 ]; then exit 99 # Выход с любым ненулевым кодом возврата else exit $1 fi } В этой версии функции добавляется анализ наличия аргументов. Внутри функции переменная $# сообщает, сколько аргументов было ей передано. Сценарий завершится с кодом возврата 99, если при его вызове не было передано никаких аргументов. Но при передаче конкретного значения, например, такого, как show_usage 5 сценарий завершится с этим кодом после вывода сообщения об использовании сцена- рия. (Переменная $ ? содержит статус завершения последней выполненной команды, независимо от того, была ли она использована в сценарии или в командной строке.) Между функциями и командами в оболочке bash существует строгая аналогия. Вы можете определить полезные функции в своем файле ~/.bash_profile, а затем ис- пользовать их в командной строке как команды. Например, если ваш узел стандартизи- ровал в сети порт 7988 для протокола SSH (в форме “безопасность через сокрытие”), вы можете определить в своем файле */ .bashjprofile функцию ssh, чтобы быть уверен- ным в том, что она всегда будет запускаться (как команда) с ключом -р 7988. function ssh { /usr/bin/ssh -р 7988 $* рия Тратите внимание на то, что сообщения об ошибках и сообщение об использовании сцена- fi ст Направляются в стандартный поток вывода данных. Разве не логичнее было бы направить их не n^apTHbI^ канал вывода ошибок? В действительности это было бы корректнее, но поскольку редполагается использовать этот сценарий в качестве фильтра, канал вывода данных здесь не Уж и важен.
84 Часть I. Основы администрирования Подобно многим командным оболочкам, bash обладает механизмом псевдонимов (alias), который может репродуцировать этот ограниченный пример в еще более ла- коничном виде, тем не менее функции остаются более универсальным и более мощным средством. Поэтому забудьте о псевдонимах и просто используйте функции. Область видимости переменных Переменные в рамках сценария имеют глобальный статус, но функции могут соз- давать собственные локальные переменные с помощью объявления local. Рассмотрим следующий код. #’/bin/bash function localizer { echo "==> В функции localizer начальное значение а равно '$а' ” local а echo ’’==> После объявления local значение а стало равным ' $а' ’’ a="localizer version" echo "==> При выходе из функции localizer значение а равно '$а' " } a="test" echo "До вызова функции localizer значение а равно '$а' " localizer echo "После вызова функции localizer значение а равно ' $а'" По приведенным ниже результатам выполнения сценария scope test. sh видно, что локальная версия переменной $а внутри функции localizer “забивает” глобальную переменную $а. Глобальная переменная $а видна в функции localizer до тех пор, пока не встретится объявление local, т.е. по сути, объявление local работает как ко- манда, которая в момент выполнения создает локальную переменную. $ sh scopetest.sh До вызова функции localizer значение а равно ’test' ==> В функции localizer начальное значение а равно ’test’ ==> После объявления local значение а стало равным ' ’ ==> При выходе из функции localizer значение а равно 'localizer version' После вызова функции localizer значение а равно 'test' Поток управления Выше в этой главе мы уже рассмотрели несколько конструкций if-then и if-then- else (они работают вполне ожидаемым образом). Терминатором (признаком конца) длЙ. оператора if служит оператор f i. Для образования цепочки if-операторов можно ис- пользовать ключевое слово elif, означающее “else if”. if [ $base -eq 1 ] && [ $dm -eq 1 ]; then installDMB^se elif [ $base -ne 1 ] && [ $dm -eq 1 ]; then installBase elif [ $base -eq 1 ] && [ $dm -ne 1 ]; then installDM else echo ’==> Installing nothing' fi
Глава 2. Сценарии и командная оболочка 85 Как и специальный [ ] -синтаксис для выполнения операций сравнения, так и “клю- чеподобные” имена операторов целочисленного сравнения (например -eq) уходят “на- следственными корнями” в использование утилиты /bin/test из ранней командной оболочки Стивена Борна. В действительности квадратные скобки — это не что иное, как условное обозначение вызова утилиты test; они не являются частью оператора if.6 В табл. 2.2 собраны bash-операторы сравнения для чисел и строк. В отличие от Perl, в bash используются текстовые операторы для чисел и символические операторы для строк. Таблица 2.2. Элементарные bash-операторы сравнения Строки'' X = У х -eq У х равно у X != у х -пе У х не равно у X < У х -It У х меньше у X <= У х -1е У х меньше или равно у X > У х -gt У х больше у X >= У х -де У х больше или равно у -п X - х не равно значению null -z X - х равно значению null В оболочке bash предусмотрены возможности оценки свойств файлов (снова-таки как освобождение от наследства /bin/test). Некоторые из операторов тестирования и сравнения файлов приведены в табл. 2.3. Таблица 2.3. Некоторые bash-операторы оценки свойств файлов Оператор -d файл Файл файл существует и является каталогом -е файл Файл файл существует ~f файл Файл файл существует и является обычным -г файл У вас есть право доступа для чтения файла ~s файл Файл файл существует и он — не пустой -w файл У вас есть право доступа для записи в файл Файл1 -nt файл 2 Файл файл1 новее, чем файл2 файл! -ot файл2 Файл файл1 старше, чем файл2 Несмотря на всю полезность формы elif, зачастую лучше (с точки зрения ясности программного кода) использовать case-структуру выбора варианта. Ниже показан ее синтаксис на примере функции, которая централизирует процесс регистрации сообще- ний для сценария. Конкретные варианты описываются закрывающими скобками после каждого условия и двумя точками с запятой, завершающими блок операторов, который Должен быть выполнен при реализации заданного условия. Оператор case завершается ключевым словом esac. 6 Сейчас эти операции встроены в оболочку и уже не запускают на выполнение утилиту /Ып/ test.
86 Часть I. Основы администрирования # Уровень протоколирования устанавливается в глобальной # переменной LOG_LEVEL. Возможные варианты перечислены в порядке # от самого строгого до наименее строгого: Error, Warning, Info и Debug. function logMsg { me s s age_leve1=$1 message_itself=$2 if [ $message_level -le $LOG_LEVEL ]; then case $message_level in 0) message_level_text="Error” ;; 1) message_level_text=’’Warning” ; ; 2) message_level_text=”Info" ;; 3) message_level_text=”Debug’’ ;; *) message_level_text=’’Other’’ esac echo ’’$ {message_level_text}: $message_itself’’ fi } Эта функция иллюстрирует общепринятую парадигму “уровня регистрации” (log level), используемую многими приложениями административного характера. Код это- го сценария позволяет генерировать сообщения на различных уровнях детализации, но действительно регистрируются или отрабатываются только те из них, которые “прохо- дят” глобально устанавливаемый порог $LOG_LEVEL. Чтобы прояснить важность каждо- го сообщения, его текст предваряется меткой, описывающей соответствующий уровень регистрации. Циклы Конструкция for...in предназначена для упрощения выполнения некоторых дей- ствий для группы значений или файлов, особенно при универсализации файловых имен, т.е. замене реальных символов в имени и расширении универсальными (например и “?”) с целью формирования целых списков имен файлов. Шаблон * . sh в при- веденном ниже цикле for позволяет обработать целый список совпадающих с ним (ша- блоном) имен файлов из текущего каталога. Оператор for, проходя по этому списку, по очереди присваивает имя каждого файла переменной $file. #!/bin/bash suf fix=BACKUP—'date +%Y%m%d-%H%M' for script in *.sh; do newname="$script.$suffix" echo ’’Copying $script to $newname...’’ cp $script $newname done Результат выполнения этого сценария таков. $ sh forexainple Copying rhel.sh to rhel.sh.BACKUP—20091210-1708... Copying sles.sh to sles.sh.BACKUP—20091210-1708... В раскрытии имени файла здесь нет ничего магического; все работает в точном соот- ветствии с тем, как написано в командной строке. Другими словами, сначала имя файла
Глава 2. Сценарии и командная оболочка раскрывается (т.е. шаблон заменяется существующим именем), а затем уж обрабатывает- ся интерпретатором в развернутом виде.7 С таким же успехом вы могли бы ввести имена файла статически, как показано в этой командной строке. for script in rhel.sh sles.sh; do В действительности любой список имен, содержащих пробельные символы (включая содержимое переменной), обрабатывается как объект циклической конструкции f or...in. Оболочке bash также присуща близость к циклу for из традиционных языков про- граммирования, в которых задается стартовое выражение, инкрементация и условие окончания цикла. for ( ( i=0 ; i < $CPU_COUNT ; i++ )) ; do CPU_LIST=’’$CPU_LIST $i" done На примере следующего сценария иллюстрируется bash-цикл while, который часто применяется для обработки аргументов командной строки и чтения строк файла. #!/bin/bash exec 0<$1 counter=l while read line; do echo "$counter: $line” $((counter++)) done Вот как выглядит результат выполнения этого сценария. ubuntu $ sh whileexainple /etc/passwd 1: root:x:0:0:Superuser:/root:/bin/bash 2: bin:x:l:l:bin:/bin:/bin/bash 3: daemon:x:2:2:Daemon:/sbin:/bin/bash В этом сценарии есть интересные особенности. Оператор ехес переопределяет стан- дартный выходной поток сценария так, чтобы входные данные считывались из файлов, имена которых должны определяться в соответствии с первым аргументом командной строки.8 Если окажется, что такой файл не существует, данный сценарий сгенерирует ошибку. Оператор read в конструкции while на самом деле является встроенным в оболоч- ку, но действует подобно внешней команде. Внешние команды можно также помещать в конструкцию while. Цикл while в такой форме завершится тогда, когда внешняя ко- манда возвратит ненулевое значение кода завершения. Выражение $ ((counter++)) выглядит несколько странно. Обозначение $ ((...)) го- ворит о вычислении выражения. Кроме того, оно делает необязательным использова- ние символа $ для обозначения имен переменных. Удвоенный знак “плюс” (++) — это оператор постинкремента, знакомый, например, по языку С. Он возвращает значение 7 Точнее, небольшая доля магии в раскрытии имен файлов здесь все же имеет место и состоит в поддержке понятия атомарности каждого имени файла. Имена файлов, которые включают про- белы, пройдут этот цикл for в один проход. 8 В зависимости от вызова, оператор ехес также может иметь и такое значение: “остановить этот сценарий и передать управление другому сценарию или выражению”. В этом состоит еще °дна странность оболочки: доступ к обеим упомянутым здесь функциям реализуется через один * и тот же оператор.
88 Часть I. Основы администрирования переменной, с которой он связан, но также имеет побочный эффект, который состоит в приращении значения этой переменной. Выражения $((...)) работают в контексте двойных кавычек, поэтому тело рассмо- тренного выше цикла можно свернуть до одной строки. while read line; do echo ’’$ ((counter++)) : $line" done Массивы и арифметика Сложные структуры данных и вычисления нельзя отнести к сильной стороне обо- лочки bash. Но, по крайней мере, вы можете надеяться на использование массивов и арифметических операций. Все bash-переменные представляют собой строковые значения, поэтому оболочка bash не делает различия в присваиваниях между числом 1 и символьной строкой “1”. Различие лежит в использовании переменных. Следующий код иллюстрирует это раз- личие. #!/bin/bash а=1 Ь=$((2)) с=$а+$Ь d=$(($a+$b)) echo "$а + $b - $с Ь(знак плюс как строковый литерал)” echo ”$а + $b = $d Ь(знак плюс как арифметическое сложение)" При выполнении этого сценария получим такой результат. 14-2 = 1+2 (знак плюс как строковый литерал) 1+2=3 (знак плюс как арифметическое сложение) Обратите внимание на то, что знак “плюс” в присваивании переменной $с не рабо- тает как оператор конкатенации для строк. Он остается всего лишь литеральным симво- лом, и посему эта строка эквивалентна следующей. с="$а+$Ь" Для того чтобы добиться вычисления, необходимо заключить выражение в двойные скобки: $((...)), как показано выше в присваивании переменной $d. Но даже эта мера предосторожности не позволяет получить в переменной $d числового значения; это зна- чение по-прежнему хранится в виде строки “3”. В оболочке bash реализован обычный ассортимент операторов: арифметических, ло- гических и отношений (подробнее см. соответствующие тап-страницы). Массивы в командной оболочке bash могут показаться немного странными объек- тами (да они и используются не очень часто). Тем не менее при необходимости их мож- но применять. Литеральные массивы ограничиваются круглыми скобками, а отдельные элементы разделяются пробельными символами. Для включения литеральных пробелов в элемент можно использовать кавычки. example=(aa 'bb сс' dd) Для доступа к отдельным элементам массива используйте выражение $ {имя_ массива [индекс] }. Индексация начинается с нуля. Такие индексы, как и
Глава 2. Сценарии и командная оболочка 89 относятся к массиву в целом, а специальные конструкции ${#имя_массива [*] } и $ {#имя_массива [@] } возвращают количество элементов в массиве. Не спутайте эти выражения с конструкцией $ {#имя_массива} — и хотя эта форма кажется более логич- ной, но в действительности она содержит указатель на первый элемент массива (эквива- лент для $ {#имя_массива [ 0 ] }). Можно подумать, что выражение $example [ 1 ] должно служить однозначной ссыл- кой на второй элемент массива, но оболочка bash интерпретирует эту строку так: $example (обозначение ссылки на $example [ 0 ]) плюс литеральная строка [ 1 ]. Отсю- да вывод: ссылаясь на переменные массива, всегда используйте фигурные скобки каких-либо исключений). Рассмотрим сценарий, который иллюстрирует некоторые особенности bash-мас- сивов и подводные камни, на которые можно наткнуться при управлении ими. #!/bin/bash example=(aa 'bb сс' dd) example[3]=ee echo ’’example [@] = $ {example [0]}’’ echo "Массив example содержит ${#example[@]} элементов" for elt in ’’${example [@] }’’; do echo ’’ Элемент = $elt" done Вот как выглядит результат выполнения этого сценария. $ sh arrays example[0] = аа bb сс dd ее Массив example содержит 4 элемента Элемент = аа Элемент = bb сс Элемент = dd Элемент = ее Этот пример кажется простым, но лишь потому, что мы организовали его “хорошее поведение”. Но если потерять бдительность, вы можете попасть в ловушку. Например, сценарий с заменой for-строки вариантом for elt in $ {example [@] }; do (т.е. без кавычек, в которых заключено выражение массива) также работает, но вместо четырех элементов он выведет пять: аа, bb, сс, dd и ее. Важно помнить, что все bash-переменные все равно остаются строками, поэтому работа с массивами — в некотором роде иллюзия. В тонкостях, связанных с тем, когда и как строки разбиваются на элементы, можно утонуть. Для того чтобы не рисковать, лучше используйте язык Perl или Python. Настойчивые читатели, желающие разобраться в нюансах, могут с помощью Google обратиться к руководству Менделя Купера (Mendel Cooper) Advanced Bash-Scripting Guide. 2.3. Регулярные выражения Регулярные выражения поддерживаются большинством современных языков, хотя одни языки “принимают их ближе к сердцу”, чем другие. Они также используются в та- ких UNIX-командах, как grep и vi. Регулярные выражения настолько распространены,
90 Часть I. Основы администрирования что их название в оригинальной литературе часто сокращали до слова “regex” (regular expressions). О том, как использовать их немалые возможности, написаны уже целые книги и неудивительно, что они стали объектом исследования многочисленных доктор- ских диссертаций. Сопоставление имен файлов и их раскрытие, выполненное оболочкой в процессе интерпретации таких командных строк, как wc -1 * .pl, не является формой сопо- ставления с регулярным выражением. Это совсем другая система, именуемая “универса- лизацией файловых имен с помощью оболочки” (shell globbing), в которой используется другой, причем более простой, синтаксис. Регулярные выражения — очень мощный инструмент, но они не могут распознавать все возможные грамматики. Их самый большой недостаток состоит в том, что они не в состоянии различать вложенные ограничители. Например, невозможно написать ре- гулярное выражение, которое распознает допустимые арифметические выражения для ситуации, когда для группирования членов выражения разрешено использовать круглые скобки. Регулярные выражения в мощности и совершенстве достигли кульминации в язы- ке Perl. Функции сопоставления шаблонов в Perl настолько тщательно разработаны, что в действительности не совсем правильно называть их реализацией регулярных выра- жений. Шаблоны Perl могут включать вложенные разделители, они могут распознавать палиндромы (перевертни или перевертыши) и сопоставляться, например, с произволь- ной строкой букв “А”, за которыми последует такое же количество букв “Б”, — словом, пойдут в ход всевозможные вариации на тему регулярных выражений. При этом в Perl можно обрабатывать и довольно примитивные регулярные выражения. Язык сопоставления Perl-шаблонов остается промышленным мерилом качества, и он принят на вооружение во многих других языках и инструментах. Библиотека Филиппа Гейзела (Philip Hazel) PCRE (Perl-compatible regular expression) несколько упрощает для разработчиков включение этого языка в проекты. Сами по себе регулярные выражения не являются частью языка написания сцена- риев, но они настолько полезны, что заслуживают подробного рассмотрения в любом обсуждении “сценарной” темы, а уж тем более в этом разделе.9 Здесь мы рассматриваем их в базовой форме с учетом некоторых Perl-нюансов. Процесс сопоставления Код, который использует регулярное выражение, пытается сопоставить одну задан- ную текстовую строку с одним заданным шаблоном. Сопоставляемая текстовая строка может иметь очень большой размер и содержать встроенные символы перехода на но- вую строку. Зачастую регулярное выражение удобно использовать для сопоставления с содержимым целого файла или HTML-документа. Для того чтобы обнаружитель совпадений мог доложить о благоприятном исходе, шаблон поиска должен целиком совпасть с непрерывной областью исследуемого тек- ста. При этом шаблон может совпасть в любом месте исследуемого текста. После об- наружения успешного совпадения вычислитель возвращает текст совпадения вместе со 9 Известный знаток Perl, Том Кристиансен (Tom Christiansen) сказал: “Я не знаю, что такое язык написания сценариев, но я согласен с тем, что регулярные выражения нельзя отнести ни к процедурным, ни к функциональным языкам. Скорее, это язык, основанный на логике, или декларативный язык, относящийся к группе языков, в которую также входят Prolog и Makefile. И формы Бэкуса-Наура (BFS). Его также можно назвать языком, основанным на системе правил. Лично я предпочитаю называть подобные языки декларативными”.
Глава 2. Сценарии и командная оболочка 91 списком совпадений для любых частей (подразделов) шаблона, ограниченных специ- альным образом. Литеральные символы В общем случае символы регулярного выражения при сопоставлении должны соот- ветствовать самим себе. Так, шаблон I am the walrus совпадает со строкой “I am the walrus” и только с этой строкой. Поскольку совпадение может быть обнаружено в любом месте исследуемого текста, этот шаблон может дйт£> успешный результат совпадения со строкой “I am the egg man. I am the walrus. Koo koo ka-choo!” При этом реальное совпадение ограничено фрагментом “I am the walrus”. Процесс сопоставления чувствителен к регистру букв. Специальные символы В табл. 2.4 собраны значения некоторых распространенных специальных символов, которые могут использоваться в регулярных выражениях (вообще, этих специальных символов гораздо больше). Таблица 2.4. Распространенные специальные символы регулярных выражений Совпадает с любым символом [ chars ] Совпадает с любым символом из заданного набора [л chars ] Совпадает с любым символом не из заданного набора Л Совпадает с началом строки $ Совпадает с концом строки w Совпадает с любым алфавитно-цифровым символом (аналогично набору [A-Za-z0-9_]) s Совпадает с любым пробельным символом (аналогично набору [ ftnr])a d Совпадает с любой цифрой (аналогично набору [ 0 - 9 ]) I Совпадает с элементом либо слева, либо справа (ехрг) Ограничивает область действия, группирует элементы, позволяя формировать группы совпадений с “захватом” и без “захвата” ? Позволяет одно повторение (или ни одного) предшествующего элемента * Позволяет множество повторений (или ни одного) предшествующего элемента + Позволяет одно или больше повторений предшествующего элемента Iп) Ровно п повторений предшествующего элемента {min, } не менее min повторений (обратите внимание на запятую) {min, шах} Любое число (от min до max) повторений а пробел, символ прогона страницы, табуляции, новой строки или возврата каретки. Многие такие специальные конструкции, как + и |, оказывают влияние на сопо- ставление подстрок слева или справа. В общем случае подстроку может составлять один символ, или “подшаблон”, заключенный в круглые скобки, или класс символов, заклю- ченный в квадратные скобки. Однако для символа “ | ” подстрока распространяется нео-
92 Часть I. Основы администрирования граниченно как влево, так и вправо. Если вы хотите ограничить область действия верти- кальной черты, заключите ее и обе подстроки в их собственный набор круглых скобок. Например, шаблон I am the (walrus | egg man). даст совпадение либо со строкой “I am the walrus.”, либо со строкой “I am the egg man.”. Этот пример демонстрирует также способ “экранирования” специальных символов (в данном случае точки) с помощью обратной косой черты (). Шаблон (I am the (walrus|egg man). ?){1,2} совпадет с любой из следующих строк. • I am the walrus. • I am the egg man. • I am the walrus. I am the egg man. • I am the egg man. I am the walrus. К сожалению, он также даст совпадение со строкой “I am the egg man. I am the egg man.”. (И какой в этом смысл?) Важнее то, что приведенный выше шаблон также со- впадет со строкой “I am the walrus. I am the egg man. I am the walrus.”, хотя количество повторений явно ограничено числом два. Дело в том, что шаблон не обязательно дол- жен совпадать полностью с исследуемым текстом. В данном случае после обнаружения совпадений этого регулярного выражения с двумя предложениями дальнейшее его со- поставление прекратилось с объявлением об успешном завершении. После выполнения условия, заданного в регулярном выражении, уже не важно, что в данном тексте есть еще одно совпадение с шаблоном. Часто метасимвол регулярного выражения “*” (квантификатор, равный нулю или больше нуля) путают с символом используемым командной оболочкой для уни- версализации файловых имен. В системе регулярных выражений используйте метасим- вол “*” в случае, если для совпадения приемлема любая последовательность символов (включая их отсутствие). Примеры использования регулярных выражений В Соединенных Штатах почтовые индексы (zip-коды) имеют либо пять цифр, либо пять цифр с последующим тире и еще четырьмя цифрами. При создании регулярного выражения для zip-кода необходимо обеспечить сопоставление пятизначного номера. Следующее регулярное выражение отвечает всем этим требованиям. Ad{5}$ Символы “Л” и “$” сопоставляются с началом и концом обрабатываемого текста, не соответствуя при этом реальным символам в тексте; они представляют собой “утверж- дения нулевой длины” (т.е. это не символы, а лишь “позиции” в тексте). Эти симво- лы гарантируют, что только те текстовые строки, которые состоят ровно из пяти цифр, должны совпадать с регулярным выражением (строки большей длины не должны давать совпадения). Сочетание символов d обеспечивает совпадение с цифрой, а квантифика- тор {5} выражает требование совпадения ровно пяти цифр. Для того чтобы можно было выявить либо пятизначный почтовый индекс, либо рас- ширенный zip-код (zip+4), добавим в качестве необязательной части тире и четыре до- полнительные цифры. Ad{5}(-d{4})?$
Глава 2. Сценарии и командная оболочка 95 Круглые скобки объединяют в группу тире и дополнительные цифры, чтобы они счи- тались одной необязательной единицей. Например, это регулярное выражение не даст совпадения с пятизначным почтовым индексом, за которым следует “голое” тире (без последующих цифр). Если тире существует, также должно существовать четырехзначное расширение, в противном случае совпадение зафиксировано не будет. Классический пример использования регулярного выражения демонстрирует сле- дующее выражение. М[ои]'?ат+[ае]г ([АЕае]1[- ])?[GKQ]h?[аеи]+([dtz][dhz]?)+af[iy] Оно дает совпадения со многими вариантами произношения имени ныне покойного лидера Ливии Муаммара Каддафи (Moammar Gadhafi), например, с такими, как: (ВВС); (Associated Press); (Al-Jazeera); (U.S. Department of State). • Muammar al- Kaddafi • Moammar Gadhafi • Muammar al-Qadhafi • Mu’ammar Al-Qadhafi Вы понимаете, почему каждый из приведенных вариантов успешно совпал с шабло- ном? Приведенное выше регулярное выражение также иллюстрирует, насколько быстро могут быть достигнуты пределы удобочитаемости. Многие системы регулярных выра- жений (включая используемую в Perl) поддерживают опцию х, которая игнорирует ли- теральные пробельные символы в шаблоне и легитимизирует комментарии, разрешая “растягивать” шаблон и располагать его на нескольких строках. Затем вы можете ис- пользовать пробельные символы для выделения логических групп и “прояснения отно- шений” между ними подобно тому, как это делается в процедурных языках. М [ои] '? а т+ [ае] s # # # # # # Имя: Mu'ammar, Moamar и т.д. Пробельный символ; здесь нельзя использовать литеральный пробел Группа для необязательного префикса-фамилии Al, El, al или el Тире или пробел [АЕае] 1 [-s] [GKQ] h? [aeu]+ ( [dtz] [dhz]? # # # Начальный fteici фамилии: Kha, Qua и т.д. Группа для согласных в начале 2-го слога dd, dh и т.д. af [iy] Такой способ описания регулярного выражения, вероятно, слегка облегчит понима- ние, но все же и он в состоянии замучить потенциальных читателей. Поэтому лучше использовать иерархический подход и строить множество небольших сопоставлений вместо попытки описать все возможные ситуации в одном огромном регулярном вы- ражении. Захваты В случае, если совпадение происходит, каждый набор круглых скобок становится “группой захвата”, которая фиксирует реально совпавший текст. То, как именно эти элементы становятся доступными для вас, зависит от конкретной реализации и контек- ста. В Perl доступ к результатам можно получить в виде списка или последовательности пронумерованных переменных.
94 Часть I. Основы администрирования Поскольку круглые скобки могут быть вложенными, как узнать, чему соответствует каждое совпадение? Ответ простой: совпадения выстраиваются в результате в том же по- рядке, в котором располагаются открывающие скобки. Количество “захватов” равно ко- личеству открывающих скобок, независимо от роли (или ее отсутствия), которую играла каждая взятая в скобки группа в реальном совпадении. Если взятая в скобки группа не используется (например, при сопоставлении регулярного выражения Ми (') ?ammar со строкой “Muammar”), соответствующий “захват” будет пустым. Если обнаружится несколько совпадений группы, в качестве результата возвращается содержимое только последнего совпадения. Например, при шаблоне (I am the (walrus|egg man). ?){1,2} и таком варианте обрабатываемого текста I am the egg man. I am the walrus. существует два результата (по одному для каждого набора круглых скобок). I am the walrus. Walrus Обратите внимание на то, что обе захваченные группы в действительности совпали дважды. Но был захвачен только последний текст, совпавший с каждым набором кру- глых скобок. Жадность, леность и катастрофический поиск с возвратом Регулярные выражения сопоставляются слева направо. Если каждый компонент шаблона перед переходом к следующему компоненту стремится “захватить” макси- мально возможную строку, то такая характеристика поведения называется жадностью (greediness). Если обработчик регулярных выражений (анализатор) достигает состояния, из ко- торого сопоставление выполнить уже невозможно, он немного “откатывается” назад от кандидата на совпадение и заставляет одного из “жадных” компонентов отказаться от части текста. Например, рассмотрим регулярное выражение а*аа применительно к входному тексту “аааааа”. Вначале анализатор присваивает весь входной текст компоненту а*, поскольку он (т.е. а*) является “жадным”. Когда окажется, что больше букв “а” не осталось, анализа- тор перейдет к поиску совпадений со следующим компонентом регулярного выражения. Но поскольку им является а и во входном тексте больше нет ничего, что можно было бы сопоставить с а, пора делать “откат”. Компонент а* вынужден отказаться от одной из букв “а”, с которыми уже было зафиксировано совпадение. Теперь анализатор может сопоставлять компонент а*а, но он по-прежнему не мо- жет это сделать для последней буквы “а” в шаблоне. Поэтому он снова откатывается и “отнимает” вторую букву “а” из “добычи” компонента а*. На этот раз вторая и третья буквы “а” в шаблоне имеют буквы “а” для фиксации совпадения, и на этом обработка текста завершена. Этот простой пример иллюстрирует некоторые важные общие момен- ты. Прежде всего, “жадное” сопоставление с “откатами” делает использование таких простых шаблонов, как <img. *></tr>, дорогим удовольствием при обработке целых
Глава 2. Сценарии и командная оболочка 95 файлов.10 Действие порции . * начинается с сопоставления всего содержимого от первой найденной подстроки <img до конца входного текста, и только благодаря повторным откатам область поиска сузится, чтобы “подобраться” к локальным тегам. Более того, порция ></tr>, с которой связан этот шаблон, — это последнее возмож- ное допустимое вхождение искомого элемента во входном тексте, что, наверняка, совсем не отвечает вашим намерениям. Вероятно, вы хотели отыскать совпадение с подстро- кой <img>, за которой следует тег </tr>. Тогда лучше переписать этот шаблон в виде <img[A>] *></tr>, что позволит распространить совпадение с начальными групповы- ми символами только до конца текущего тега благодаря явно заданной невозможности пересечь границу, обозначенную правой угловой скобкой. Можно также использовать “ленивые” (в противоположность “жадным”) оператор- ные выражения: *? вместо * и +? вместо +. Эти варианты квантификаторов ограничи- вают количество вхождений искомых символов во входном тексте до минимально воз- можного. Во многих ситуациях эти операторы работают эффективнее и дают результаты, более близкие к желаемым, чем “жадные” варианты. Однако обратите внимание на то, что “ленивые” квантификаторы (в отличие от “жадных”) могут давать различные совпадения; разница состоит не просто в исполь- зуемой реализации. В нашем HTML-примере “ленивый” шаблон выглядел бы так: <img. * ?></tr>. Но даже в этом случае элемент . * ? мог бы стать причиной внесения в результат ненужных нам символов “>”, поскольку следующим после тега <img> может быть не тег </tr>. А такой результат вас, скорее всего, не устроит. Шаблоны с несколькими секциями групповых символов могут “спровоцировать” анализатор регулярных выражений на экспоненциальное поведение, особенно в слу- чае, если порции текста могут совпадать с несколькими шаблонными выражениями, и тем более в случае, если искомый текст в действительности не соответствует шаблону. Эта ситуация не является такой уж необычной, как может показаться, главным образом тогда, когда шаблон сопоставляется с HTML-кодом. Очень часто вам придется искать конкретные теги, за которыми следуют другие теги, возможно, разделенные третьими тегами, и так далее, одним словом, вам придется создавать задание, которое потребует, чтобы анализатор проверил массу возможных комбинаций. Большой специалист в области регулярных выражений Ян Гойвертс (Jan Goyvaerts) называет этот эффект катастрофическим откатом (catastrophic backtracking) и описы- вает его в своем блоге (за подробностями и некоторыми удачными решениями обращай- тесь по адресу: regular-expressions.info/catastrophic.html). Из всего сказанного выше можно сделать такие выводы. • Если вы можете организовать построчное сопоставление шаблона, а не пофай- ловое (т.е. с просмотром сразу всего файла), значит, вы значительно уменьшаете риск получения, мягко говоря, низкой производительности. • Несмотря на то что регулярные выражения являются “жадными” по умолчанию, вам, скорее всего, такие не нужны. Используйте “ленивые” операторы. 10 Несмотря на то что в этом разделе в качестве примеров обрабатываемого текста показаны фрагменты HTML-кода, регулярные выражения — не самый подходящий инструмент в данном случае (что не преминули отметить и наши рецензенты). Языки Perl и Python имеют прекрасные расширения, которые анализируют HTML-документы надлежащим образом. Вы можете получить доступ к интересующим вас порциям с помощью Xpath-селекгоров. Подробнее о модульных репо- зиториях соответствующих языков можно узнать, обратившись к странице Википедии, посвящен- ной языку запросов Xpath (XML Path Language).
96 Часть I. Основы администрирования • Все экземпляры специальных символов “. * ” по своему существу подозрительны и должны быть тщательно исследованы. 2.4. Программирование на языке Perl Язык Perl, созданный Ларри Уоллом (Larry Wall), был первым из самых популярных языков написания сценариев. Он предлагает чрезвычайно больше возможностей, чем bash, а написанные на нем программы (если они написаны хорошо) довольно просты для понимания. Поскольку в языке Perl не предусмотрена обязательность соблюдения раз- работчиками стилистических правил создания кода, читабельность Perl-кода зависит от их дисциплинированности. Не без основания Perl называют языком “только для записи”. Здесь описывается версия Perl 5, которая была стандартом в течение последнего деся- тилетия. Версия Perl 6 все еще находится в стадии разработки. Подробнее можно узнать на сайте perl 6. org. Языки Perl и Python (см. раздел 2.5) больше подходят для работы в области системного администрирования, чем такие традиционные языки программиро- вания, как С, C++, C# и Java. Их отличает большая эффективность: при лаконичности кода и менее мучительном процессе отладки, а также без компиляционной “волокиты” они могут продемонстрировать большие возможности. Выбор языка обычно зависит от личных предпочтений или стандартов, используемых вашим работодателем. Как Perl, так и Python предлагают библиотеки модулей и языковые расширения. По популярности язык Perl “старше”, чем Python, поэтому его предложения “вылились” в довольно длинный список возможностей. Но при решении каждодневных задач системного администрирования библиотеки поддержки обоих языков практически эквивалентны. Для языка Perl характерен следующий девиз: “Достичь цель можно несколькими путями”. Поэтому имейте в виду, что в большинстве примеров, описанных в этом разделе, существуют и другие (помимо приведенного здесь) способы выполнения поставленной задачи. Операторы Perl разделяются точкой с запятой.11 Комментарии начинаются знаком # и продолжаются до конца строки. Блоки операторов заключаются в фигурные скобки. Вот пример простой программы “Привет, мир!”. #!/usr/bin/perl print "Привет, мир!п"; Как и для bash-программ, вы должны либо изменить права доступа (chmod +х) для исполняемого файла, либо непосредственно вызвать Рег1-интерпретатор. $ chmod +х helloworld $ ./helloworld Привет, мир! Строки в Perl-сценарии не являются командами оболочки (они представляют собой Perl-код). В отличие от командной оболочки bash, которая позволяет объединить неко- торую последовательность команд в сценарий, Perl не “видит дальше своего носа”, если ему не дать соответствующего указания. Тем не менее Perl обеспечивает действие многих таких же соглашений, которые действуют в оболочке bash, например использование об- ратных апострофов, заключающих в себя некоторую команду, для перехвата результата выполнения этой команды. 11 Поскольку знаки “точка с запятой” являются разделителями, а не ограничителями (терми- наторами), последнюю точку с запятой в блоке ставить необязательно.
Глава 2. Сценарии и командная оболочка 97 Переменные и массивы В Perl используются три базовых типа данных: скаляры (т.е. такие унитарные значе- ния, как числа и строки), массивы и хеши (известные также как ассоциативные масси- вы). Тип переменной всегда очевиден, поскольку он “встроен” в имя переменной: ска- лярные переменные начинаются знаком “$”, переменные массивов — символом и хеш-переменные — знаком “%”. В Perl понятия “список” и “массив” часто взаимозаменяемы, но, пожалуй, коррек- тнее сказать, что список — это некоторая последовательность значений, а массив — это переменная, которая может содержать такой список. Отдельные элементы массива явля- ются скалярами, поэтому, подобно обычным скалярным переменным, их имена начина- ются со знака “$”. Индексация массивов начинается с нуля, а индекс самого последнего элемента в массиве @а определяется значением $#а. Чтобы получить размер массива, достаточно добавить к этому значению единицу. Массив @ARGV содержит аргументы командной строки сценария. Его можно исполь- зовать подобно любому другому массиву. Пример использования массивов демонстрирует следующий сценарий. #!/usr/bin/perl @items = ("носки", "туфли", "шорты"); printf "Есть %d вида одежды.n", $#items +1; print "Наденьте ${items[2]} первыми, затем ", join(" и ", @items[0,1]), ”.п"; Результат выполнения этого сценария таков. $ perl clothes Есть 3 вида одежды. Наденьте шорты первыми, затем носки и туфли. В этих нескольких строках сценария есть много интересного. Рискуя отвлечь ваше внимание, мы все же включаем в каждый наш Perl-пример несколько распространен- ных идиом, разъясняя сложные моменты в тексте, следующем за примером. Если вы внимательно прочитаете все пояснения к примерам (не пугайтесь, они короткие!), то к концу этой главы приобретете практические знания в использовании большинства рас- пространенных Perl-конструкций. Массив и строковые литералы В этом примере обратите внимание, прежде всего, на то, что набор круглых ско- бок (...) создает список литералов. Отдельными элементами этого списка являются строки (которые разделяются запятыми). Созданный список присваивается перемен- ной @items. В языке Perl нет жесткого требования заключать все строки в кавычки. В конкретном случае начальное присваивание значения переменной @i terns с тем же успехом работает и без кавычек. @items = (носки, туфли, шорты); Такие строки без кавычек называются в Perl “голыми словами” (barewords), и они интерпретируются таковыми в качестве “последнего средства”. Это значит, что, если для некоторого объекта невозможно найти смысловую нагрузку, Perl пытается интерпрети- ровать его как строку. В некоторых случаях это имеет смысл, если сохранится читабель- ность кода. Однако наш пример не относится к таким случаям. Даже если вы сами пред-
98 Часть I. Основы администрирования почитаете всегда заключать строки в кавычки, будьте готовы к тому, что вам придется “разгадывать” намерения других программистов, разбираясь в их “голословном” коде. В Perl существует еще один способ инициализировать этот массив. Он состоит в ис- пользовании оператора qw (#uote words — т.е. брать слова в кавычки). Это, по сути, фор- ма заключения строки в кавычки, которая предоставляет вам право самим выбирать раз- делители (как и во многих других случаях использования кавычек в Perl). Форма @items = qw (носки туфли шорты) ; является самой традиционной, но при этом может ввести в заблуждение, поскольку часть после оператора qw — уже не список. В действительности это строка, разделенная пробельными символами для формирования списка. Версия @items = qw[носки туфли шорты]; тоже работает и, пожалуй, точнее передает смысл происходящего. Обратите внимание на то, что запятых здесь нет, поскольку их нагрузку “взял на себя” оператор qw. Вызовы функций Оба варианта — print и printf — принимают произвольное количество аргумен- тов, которые разделяются запятыми. Но вот вы видите join (...). Не напоминает ли вам это вызов функции? Чем же “этот j oin” отличается от print и printf? По сути, ничем, print, printf и join — это обычные функции. Perl позволяет опу- скать круглые скобки в вызовах функций, если эта “экономия” не послужит причиной неоднозначности, поэтому обе формы приемлемы. В приведенной выше print-строке форма записи со скобками (join (...)) используется для явного отделения аргументов, передаваемых функции join, от аргументов, передаваемых функции print. Выражение @items [0,1] должно дать “списочный” результат, поскольку оно на- чинается с символа “@”. В действительности это выражение означает “кусочек масси- ва” (или подмассив), а список индексов 0,1 перечисляет индексы элементов исходного массива, которые должны быть включены в упомянутый “кусочек”. Здесь Perl прини- мает диапазон значений, как и в эквивалентном выражении @items [ 0.. 1 ]. Здесь так- же было бы допустимо использовать одиночный числовой индекс: например, выраже- ние @items [0] означало бы список, содержащий один скаляр, т.е. строку “носки”, что в данном случае было бы эквивалентно литералу ("носки”). Массивы в вызовах функций автоматически раскрываются, поэтому в выражении join(" и ”, @items[0,1]) функция join получает три строковых аргумента: " и ”, "носки" и "туфли". Она конкатенирует свой второй и последующие аргументы, вставляя между каждой парой копию первого аргумента. В результате получаем “носки и туфли”. Преобразования типов в выражениях В printf-строке при вычислении выражения $#items + 1 получим число 3. По определению выражение $#items содержит числовое значение, но это не дает основа- ния считать, что выражение $#items + 1 предполагает выполнение арифметического действия; смешанный вариант "2" + 1 работает так же. “Магия” кроется в операто- ре “+”, который всегда подразумевает арифметику, т.е. он преобразует свои аргументы в числа и генерирует числовой результат. Аналогично ему оператор “точка” (.), назна- чение которого — конкатенировать строки, преобразует свои операнды “по контексту”, т.е. при вычислении выражения "2" . (12 ** 2) получим в результате “2144”.
Глава 2. Сценарии и командная оболочка eg Раскрытие строк и устранение неоднозначности при ссылках на переменные Как и в командной оболочке bash, строки, заключенные в двойные кавычки, явля- ются объектами для раскрытия переменных. Так же, как и в bash, вы можете заключить имена переменных в фигурные скобки, чтобы при необходимости устранить неодно- значность, как в выражении $ {items [2]}. (В данном случае фигурные скобки исполь- зуются только для иллюстрации; на самом деле они не нужны.) Символ “$” информиру- ет о том, что результат вычисления выражения должен быть скалярным. Переменная® items определяет массив, но его любой элемент в отдельности — это скаляр, исейфД^г отражен в соглашениях о присваивании имен переменным. Хеши Хеш (также именуемый ассоциативным массивом или хеш-массивом) представляет набор пар “ключ/значение”. Хеш можно представить себе как массив, индексы.которо- го (ключи) являются произвольными скалярными значениями, т.е. они необязательно должны быть числами. Но на практике в качестве ключей используются именно числа и строки. Имена хеш-переменных начинаются с символа “%” (например, %myhash), но их от- дельными значениями являются скаляры, поэтому для работы с хеш-массивами нужно, как и в обычных массивах, использовать префикс разыменования “$”. Индексация обо- значается фигурными скобками, а не квадратными, например $myhash {’ гоп ’}. Для системных администраторов хеши — это очень важный инструмент, который вы будете использовать практически в каждом сценарии. В приведенном ниже коде мы считываем содержимое файла, анализируем его в соответствии с правилами, задан- ными структурой файла /etc/passwd, и формируем хеш с именем %names_by_uid. Значением каждого элемента в хеше становится имя пользователя, связанное с иденти- фикатором UID. #!/usr/bin/perl while ($_ = <>) { ($name, $pw, $uid, $gid, $gecos, $path, $sh) - split /:/; $names_by_uid{$uid} = $name; } %uids_by_name = reverse %names_by_uid; print ”$names_by_uid{0} is $names_by_uid{0}n"; print "$uids_by_name{'root'} is $uids_by_name{'roof}n"; Как и в предыдущем примере сценария, мы “начинили” эти программные строки некоторыми новыми понятиями. Прежде чем рассматривать анонсированные нюансы, ознакомьтесь с результатом работы этого сценария. $ perl hashexainple /etc/passwd $names_by_uid{0} is root $uids_by_name{'roof } is 0 В каждом проходе цикла while ($_ = о) считывается одна входная строка, кото- рая присваивается переменной $_ (напомним: значение всего оператора присваивания, как в языке С, определяется значением его правой части). При достижении конца вход-
100 Часть I. Основы администрирования ного потока, оператор о возвратит значение “Ложь”, что послужит причиной заверше- ния цикла. Интерпретируя оператор <>, Perl проверяет командную строку, чтобы узнать, указа- ны ли там какие-нибудь имена файлов. Если вы не забыли это сделать, Perl открывает каждый файл по очереди и “прогоняет” его содержимое через цикл. Если вы не назвали ни одного файла в командной строке, Perl возьмет входные данные для циклической об- работки из стандартного входного канала. Внутри цикла указанные в скобках переменные получают значения, возвращаемые функцией split, которая “разрезает” входную строку, используя регулярное выраже- ние, переданное ей в качестве разделителя полей. Здесь наш шаблон ограничивается слешами (символами “/”), действие которых подобно двойным кавычкам. Мы могли бы с таким же успехом написать split ': ’ или split ": Строка, которую функция split должна разбить на подстроки в позициях сопо- ставления с двоеточиями, нигде явно не задана. Если второй аргумент функции split, т.е. подлежащая разбиению строка, опущен, Perl предполагает, что вы хотите разбить на подстроки значение $_. Яснее не бывает! По правде говоря, иногда можно опустить даже шаблон — в этом случае разбиение строки производится по пробельному символу, при этом начальные пробелы в каждой подстроке игнорируются. Но и это еще не все. Даже исходное присваивание переменной $_ в первой строке цикла необязательно. Если просто написать так: while (о) {, то Perl автоматически сохранит каждую входную строку в переменной $_. Можно об- рабатывать строки без создания явной ссылки на переменную, в которой они будут со- храняться. Использование переменной $_ в качестве операнда, действующего по умол- чанию, — распространенная практика, и Perl позволяет такие “вольности” везде, где это имеет смысл. Во множественном присваивании, которое “захватывает” содержимое каждого поля passwd, наличие списка в левой части ($name, $pw, $uid, $gid, $gecos, $path, $sh) = split /:/; создает для функции split “контекст списка”, что предписывает ей возвращать в ре- зультате список всех полей. Если бы в присваивании участвовала скалярная переменная, например $n_fields = split функция split “переключилась” бы на “скалярный контекст” и вернула бы только ко- личество обнаруженных полей. Пользовательские функции также могут отличать скаля- ры от списочного контекста с помощью функции wantarray. Она возвращает значение “Истина” в контексте списка, “Ложь” — в контексте скаляра и неопределенное значе- ние — в void-контексте (для пустых типов данных). Строка %uids_by_name = reverse %names_by_uid; также заслуживает внимания. Хеш в контексте списка (здесь в качестве аргумента функ- ции reverse) приводится к списку в форме (keyl, valuel, кеу2, value2, ...). Функция reverse меняет порядок следования элементов в списке на обратный: (valueNf keyN, valuel, keyl). Наконец, присваивание хеш-переменной %uids_by_name преобразует этот список в вариант (keylr valuelf ...), создавая тем самым перестановочный индекс.
Глава 2. Сценарии и командная оболочка 101 Ссылки и их самооживление Обозначенная в заголовке тема относится к более сложным, но мы посчитали себя не вправе обойти ее молчанием. По крайней мере, мы должны изложить здесь основные положения. Массивы и хеши могут хранить скалярные значения, но не исключено, что вам понадобится сохранить в них другие массивы и хеши. Например, возвращаясь к на- шему предыдущему примеру анализа файла /etc/passwd, вы могли бы сохранить все поля каждой строки passwd в хеше, индексируемом значением идентификатора UID. Если нельзя хранить массивы и хеши, то можно хранить ссылки (указатели) на мас- сивы и хеши, которые сами по себе являются скалярами. Чтобы создать ссылку на мас- сив или хеш, необходимо предварить имя соответствующей переменной обратной косой чертой (например, @аггау) или использовать литеральный синтаксис ссылок на мас- сив или на хеш. Например, наш цикл passwd-анализа мог выглядеть так. while (о) { $array_ref = [ split /:/ ]; $passwd_by_uid{$array_ref->[2]} = $array_ref; } Квадратные скобки возвращают ссылку на массив, содеращий результаты работы функции split. Выражение $array_ref-> [2] ссылается на поле UID (это третий член массива, адресуемого переменной $array_ref). Выражение $array_ref [2 ] здесь не работает, поскольку мы не определили массив @array_ref; $array_ref и @array_ref — это разные переменные. Хуже того, вы не получите сообщение об ошибке, если ошибочно использовали здесь выражение $аг- ray ref [2], поскольку @array_ref — это абсолютно легитимное имя для массива; вы ведь не присваивали ему никаких значений. Отсутствие предупреждающих сообщений может показаться проблемой, но это, возможно, одно из лучших качеств Perl, именуемое самооживлением (autovivification). Поскольку имена переменных и синтаксис использования ссылок всегда делают доволь- но ясной структуру данных, к которой вы пытаетесь получить доступ, вам не придется создавать промежуточные структуры данных вручную. Достаточно организовать при- сваивание на самом низком уровне, и промежуточные структуры возникают автомати- чески. Например, используя только один оператор присваивания, можно создать хеш ссылок на массивы, в качестве содержимого которых будут выступать ссылки на хеши. Регулярные выражения в Perl Регулярные выражения в Perl используются путем “привязки” строк к операциям над регулярными выражениями, а именно с помощью оператора связывания =~. Например, при выполнении кода if ($text =~ m/ab+c/) { проверяется, совпадает ли строка, хранимая в переменной $text, с регулярным выраже- нием ab+c. Для выполнения действий по умолчанию над строкой, в которой хранится результат предыдущей операции, т.е. $_, можно просто опустить имя переменной и опе- ратор связывания. На самом деле можно опустить и оператор гл, поскольку эта операция по умолчанию приводит к совпадению. if (/ab+c/) { Подстановки работают аналогично.
102 Часть I. Основы администрирования $text =~ s/etc./and so on/g; # Замена текста в строке $text, ИЛИ s/etc./and so on/g; # Применительно к переменной $_ Мы вставили здесь модификатор д, чтобы заменить не просто первый экземпляр подстроки “etc.” вместе с подстрокой “and so on”, а все найденные экземпляры. Помимо модификатора g (который применяется для поиска множественных совпадений), часто используются и другие: модификатор i, чтобы игнорировать регистр букв; модифика- тор s, чтобы “нацелить” точку (.) на совпадение с символами новой строки; и моди- фикатор ш, чтобы с помощью маркеров “л” и “$” искать совпадения в начале и конце отдельных строк, а не только в начале и конце обрабатываемого текста. Для того чтобы обратить ваше внимание на другие важные нюансы, рассмотрим сле- дующий сценарий. #’/usr/bin/perl $names = "huey dewey louie"; $regex = ’ (w+)s+(w+)s+(w+) ' ; if ($names =- m/$regex/) { print "1-ое имя $1.п2-ое имя $2.n3-e имя $3.п"; $names =~ s/$regex/2 1/; print "Новые имена "${names}".п"; } else { print qq{"$names” не совпадает с "$regex".п}; } Вот как выглядит результат выполнения этого сценария. $ perl testregex 1-ое имд huey. 2-ое имя dewey. 3-е имя louie. Новые имена "dewey huey". Этот пример показывает, что символы // позволяют раскрыть переменные, т.е. регу- лярное выражение необязательно должно быть фиксированной строкой. Обратите внима- ние на оператор qq — это еще одно имя для оператора заключения в двойные кавычки. После реализации совпадения или подстановки переменные $1, $2 и так далее со- относятся с содержимым круглых скобок в регулярном выражении. Содержимое этих переменных также доступно в самом процессе замены, в контексте которого они “име- нуются” как 1, 2 и т.д. Ввод и вывод данных Открывая файл для чтения или записи, вы определяете так называемый дескриптор файла, чтобы идентифицировать соответствующий канал. В приведенном ниже при- мере переменная INFILE служит дескриптором для файла /etc/passwd, а переменная OUTFILE — дескриптором, связанным с файлом /tmp/passwd. Используемое в цикле while условие <INFILE> аналогично рассмотренному выше выражению о, но имеет свою специфику, связанную с данным конкретным дескриптором файла. Здесь считыва- ются строки из файла с дескриптором infile до тех пор, пока не обнаружится конец файла, что и остановит работу цикла while. Каждая строка размещается в переменной $_.
Глава 2. Сценарии и командная оболочка 103 #!/usr/bin/perl open(INFILE, "</etc/passwd") or die "He удается открыть /etc/passwd"; open(OUTFILE, ">/tmp/passwd") or die "He удается открыть /tmp/passwd"; while (<INFILE>) { ($name, $pw, $uid, $gid, $gecos, $path, $sh) - split /:/; print OUTFILE "$uidt$namen"; } Функция open возвратит значение “Истина”, если файл успешно откроется, тем са- мым “замкнув” (т.е. сделав необязательным) вычисление частей die, поскольку резуль- тат вычисления всего выражения уже не изменится. Perl-оператор or подобен оператору I | (который также есть в Perl), но с более низким приоритетом. Оператор or в общем случае предпочтительнее, если вы хотите подчеркнуть, что прежде, чем Perl переключит “свое внимание” на последствия неудачного исхода операции, должны быть выполнены все действия, указанные в левой части выражения. Синтаксис Perl для задания способа использования каждого файла (для чтения, запи- си или добавления в конец) отражает возможности, заложенные в командной оболочке. Кроме того, использование таких имен файлов, как ”/bin/df | ”, позволит открывать входные или выходные каналы связи с командами оболочки. Поток управления В приведенном ниже примере представлена Perl-версия уже знакомого вам bash- сценария, в котором проверялась достоверность аргументов командной строки (для сравнения можете вернуться к разделу “Функции и аргументы командной строки” этой главы). Обратите внимание на то, что Perl-конструкция if не оснащена ни ключевым словом then, ни каким-либо признаком завершения — блок операторов здесь просто заключен в фигурные скобки. Для того чтобы обеспечить выполнение любого отдельного оператора при соблюде- нии некоторого условия, вы можете добавлять постфиксный вариант оператора if (или его обратную версию unless). #!/usr/bin/perl sub show_usage { print shift, "n" if scalar(@_) ; print "Применение: $0 source_dir dest_dirn"; exit scalar (@_) ? shift : 1; } if (@ARGV != 2) { show_usage; } else { # Существует два аргумента ($source_dir, $dest_dir) = @ARGV; show_usage "Недопустимый каталог-источник" unless -d $source_dir; -d $dest_dir or show usage "Недопустимый каталог-приемник"; } Здесь две строки, которые используют унарный Perl-оператор -d для проверки суще- ствования каталогов $source_dir и $dest_dir, эквивалентны. Вторая форма (с опера- тором -d в начале строки) предпочтительнее, поскольку утверждение используется в на- чале строки, где оно заметнее всего. Однако применение оператора or, обозначающего в противном случае”, несколько сомнительно; и многих, кому приходится разбираться, в чужом коде, это сбивает с толку.
104 Часть I. Основы администрирования Переменная массива в скалярном контексте (заданном оператором scalar в данном примере) возвращает количество элементов в массиве. Это значение на единицу превы- шает значение $#аггау (как всегда, в Perl предусмотрено несколько способов получе- ния одного и того же результата). Функции в Perl принимают аргументы в массив с именем Обычной практикой считается в Perl получать доступ к ним с помощью оператора shift, который удаляет первый элемент массива аргументов и возвращает его значение. Эта версия функции show usage принимает необязательное сообщение об ошибке для вывода на печать. Если вы предоставляете сообщение об ошибке, то можете также предоставить специфический код выхода. Тернарный оператор ? г оценивает свой пер- вый аргумент; если оценка даст значение “Истина”, то результатом всего выражения станет значение второго аргумента, в противном случае — третьего. Как и в среде bash, Perl имеет специальное условие “else if ”, но его ключевым сло- вом является elsif, а не elif. (Для тех, кто использует оба языка, эти забавные пустя- ковые различия либо заострят их ум, либо — наоборот.) Как показано в табл. 2.5, Perl-операторы сравнения не совпадают с аналогичными операторами в оболочке bash: строки используют текстуальные операторы, а числа — традиционную алгебраическую запись. Сравните эту таблицу с табл. 2.2. Таблица 2.5. Элементарные Perl-операторы сравнения и У/ Йстина,если х eq У х = у х равно у х пе У х != у х не равно у х It У х < у х меньше у х 1е У х <= у х меньше или равно у х gt У X > у х больше у х де У X >= у х больше или равно у В Perl у вас есть все операторы тестирования файлов, показанные в табл. 2.3, за ис- ключением операторов -nt и -ot, которые доступны только в среде bash. Подобно оболочку bash, язык Perl предоставляет два типа цикла for. При использо- вании более распространенной формы цикла for обеспечивается выполнение итераций с проходом по всем элементам явно заданного списка аргументов. Например, в приве- денном ниже коде перебираются по очереди элементы списка названий животных (ani- mals) и выводятся по одному на строке. @animals = qw(lions tigers bears); foreach $animal (@animals) { print ”$animal n" ; } Также вы вправе использовать цикл for в стиле языка С. for ($counter=l; $counter <= 10; $counter++) { printf ”$counter ”; } Хотя мы продемонстрировали применение циклов с разными ключевыми словами — for и foreach, на самом деле в обоих случаях работает одно и то же ключевое слово, т.е. в Perl вы можете использовать любую форму, которая кажется вам предпочтительнее.
Глава 2. Сценарии и командная оболочка 105 В версиях языка Perl до 5.10 (2007 г.) не было явно определенных операторов case или switch, но, как уже подчеркивалось не раз, один результат можно получить не- сколькими путями. В дополнение к очевидному, но громоздкому варианту каскадирова- ния операторов if, можно прибегнуть к еще одному способу использования оператора for, в котором главное — установить переменную $_, сравнить ее с нужными значе- ниями и после выполнения соответствующих действий обеспечить выход из контекста (с помощью оператора last). for ($ARGV[0]) { т/Лwebsphere/ && do { m/Atomcat/ && do { m/Ageronimo/ && do { print "Инсталляция для print "Инсталляция для print "Инсталляция для websphereXn"; last; }; tomcatXn" ; last; }; geronimoXn"; last; }; print "Предоставлен недопустимый вариант.n"; exit 1; } Здесь регулярные выражения по очереди сравниваются с аргументом, сохраненным в переменной $_. При неуспешном результате сравнения в левой части операции && правая часть уже не вычисляется и управление передается следующему оператору. Если же происходит совпадение с некоторым регулярным выражением, выполняется соответ- ствующий ему блок do, после чего остается лишь “красиво уйти”. Немедленный выход из блока for обеспечивают операторы last. Прием входных данных и проверка их достоверности В приведенном ниже сценарии объединены многие уже рассмотренные нами кон- струкции Perl, включая использование подпрограммы, нескольких постфиксных опера- торов if и цикла for. Сама программа — это просто “обертка”, в которую “завернута” основная функция get_string, обеспечивающая проверку достоверности входных дан- ных. Эта функция приглашает пользователя ввести строку, удаляет замыкающий символ новой строки и проверяет, не является ли введенная строка нулевой. После приема ну- левой строки пользователю предлагается повторить ввод, но после трех неудачных по- пыток сценарий “умоет руки”. # !/usr/bin/perl $maxatt = 3; # Максимальное число попыток ввести корректные данные sub get_string { my ($prompt, $response) = shift; # Пытаемся прочитать входную строку до $maxatt раз for (my $attempts = 0; $attempts < $maxatt; $attempts++) { print "Пожалуйста, попытайтесь еще раз.Хп" if $attempts; print "$prompt: "; $response = readline(*STDIN); chomp($response); return $response if $response; } die "Слишком много неудачных попыток ввести данные"; } # Прием имен с помощью функции get_string и перевод в прописные буквы $fname = uc get_string "Имя";
106 Часть I. Основы администрирования $lname = uc get_string "Фамилия"; printf "Полное имя: $fname $lnamen"; Результат выполнения этого сценария таков. $ perl validate Имя: John Ball Фамилия: Park Полное имя: JOHN BALL PARK Функция get string и цикл for иллюстрируют использование оператора ту в соз- дании переменных локальной области видимости. По умолчанию все переменные в Perl являются глобальными. Список локальных переменных для функции get string ини- циализируется с помощью одного скаляра, получаемого из массива аргументов функ- ции. Переменные в списке инициализации, которые не имеют надлежащего значения (в данном случае это переменная $response), остаются неопределенными. Значение * STDIN, переданное функции чтения строк, имеет “всеядный” тип type- glob, который считается слабым местом в языковом проектировании. Из соображений самосохранения, лучше не ломайте голову над тем, что он (этот тип) в действительно- сти означает. Возможно, вас удовлетворит такое короткое пояснение: в Perl дескрип- торы файлов не относятся к типам данных “первого класса”, поэтому в общем случае для передачи их функциям в качестве аргументов необходимо перед их именами ставить символ “звездочка”. В присваиваниях для переменных $fname и $lname обе функции uс (convert to uppercase — означает преобразовать в прописные буквы) и get string вызываются без использования круглых скобок. Поскольку в данном случае функциям передается один- единственный аргумент, здесь нет никакой неоднозначности, а потому “экономия” ни- как не навредила. Использование языка Perl в качестве фильтра Язык Perl можно использовать без сценария — просто введя отдельные выражения в командную строку. Это позволяет быстро выполнить преобразования текста и “объя- вить” устаревшими такие программы фильтрации, как sed, awk и tr. Ключ командной строки -ре дает возможность циклически обработать поток STDIN, вычислить простое выражение в каждой строке и вывести результат. Например, команда ubuntu$ perl -ре ' s#/bin/sh$#/bin/bash#' /etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/bash заменяет текст /bin/sh в конце строк файла /etc/passwd текстом /bin/bash, выводя трансформированный файл passwd в поток STDOUT. Возможно, вы привыкли к тому, что оператор подстановки текста использует в качестве разделителей слеши (например, s/foo/bar/), но Perl позволяет применять любой символ. Здесь как искомый текст, так и текст замены содержат слеши, поэтому в данном случае в качестве разделителя проще использовать символ Предпочитая парные разделители, вы должны применять их в количестве четырех вместо “обычных” трех, например s (foo) (bar). Perl-ключ -а устанавливает режим автоматического разбиения, в котором входные строки разбиваются на поля, сохраняемые в массиве @F. Разделителем полей по умол- чанию служит пробел, но с помощью ключа -F вы можете установить другой шаблон разделителя.
Глава 2. Сценарии и командная оболочка Режим авторазбиения удобно использовать вместе с ключом -р или его вариантом запрещения автовывода -п. Например, в приведенных ниже строках используется ва- риант команды perl -апе, чтобы отформатировать результат работы двух вариантов команды df. В третьей строке выполняется команда join, которая объединяет два на- бора полей в поле Filesystem, создавая составную таблицу, включающую поля, “вы- тащенные” из обеих версий результата команды df. suse$ df -h | perl -ane 'print join("t", @F[0..4]), "n'" > tmpl suse$ df -i | perl -ane 'print join("t", @F[0,l,4J), "n"' > tmp2 suse$ join tmpl tmp2 Filesystem Size Used Avail Use% Inodes IUse% /dev/hda3 3.0G 1.9G 931M 68% 393216 27% udev 126M 172K 12 6M 1% 32086 2% /dev/hdal 92M 26M 61M 30% 24096 1% /dev/hda6 479M 8.1M 446M 2% 126976 1% Вариант сценария без временных файлов выглядит следующим образом. #!/usr/bin/perl for (split(/n/, 'df-h')) { @F - split; $h_part{$F[0] } = [ @F[0..4] ]; } for (split(/n/, ’df -i’) { @F = split; print join("t", @{$h_part{$F[0]}}, $F[1], $F[4]), "n"; } Истинно бесстрашные программисты могут использовать ключ -i вместе с ключом -ре, чтобы редактировать файлы “прямо по месту”: Perl считывает содержимое фай- лов, передает их строки на редактирование и сохраняет результаты в исходных файлах. Вместе с ключом -i можно предоставить шаблон, который укажет, как именно резер- вировать оригинальную версию каждого файла. Например, вариант -i.bak позволит сохранить резервную копию файла passwd в виде файла passwd.bak. Но будьте осто- рожны — если вы не предоставите образец резервирования, резервная копия не будет создана совсем. Обратите внимание на то, что ключ -i и предоставляемый вами суф- фикс не разделяются пробелом. Модули расширения для Perl Всеобъемлющая сеть архивов Perl (Comprehensive Perl Archive Network — CPAN) — это обширное хранилище пользовательских Perl-библиотек (cpan. org). Инсталляция новых модулей значительно облегчается командой cpan, которая действует во многом подобно открытому консольному менеджеру yum или менеджеру управления пакетами APT, “специализирующимся” на модулях Perl. Если вы работаете в системе Linux, по- интересуйтесь, есть ли в вашем дистрибутиве модуль, который вы собираетесь использо- вать в качестве стандартного средства, — намного проще инсталлировать однажды пакет системного уровня, а затем позволить системе самой периодически заботиться о соб- ственных обновлениях. Если в системе нет команды cpan, можно “пойти другим путем” и попытаться вы- полнить команду perl -MCPAN -е shell.
108 Часть I. Основы администрирования $ sudo perl -MCPAN -e shell cpan shell — CPAN exploration and modules installation (vl.9205) ReadLine support available (maybe install Bundle::CPAN or Bundle::CPANxxl?) cpan[1]> install Class::Date CPAN: Storable loaded ok (v2.18) CPAN: LWP::UserAgent loaded ok (v5.819) CPAN: Time::HiRes loaded ok (vl.9711) ... several more pages of status updates ... Можно посоветовать пользователям инсталлировать модули Perl в их домашние ка- талоги для личного применения, но этот процесс не совсем простой. В масштабе всей системы рекомендуем инсталлировать модули (с открытым кодом) сторонних произво- дителей из архива CPAN. Эти модули Perl (их создателей можно идентифицировать по имени) не опаснее других программных продуктов с открытым кодом. Многие модули Perl используют компоненты, написанные на языке С (что способ- ствует повышению производительности). Инсталляция включает компиляцию этих сег- ментов, поэтому для работы вам необходимо иметь полную среду разработки, содержа- щую С-компилятор и полный набор библиотек. Как и во многих других языках, самой распространенной ошибкой в Perl-программах считается повторная реализация средств, которые уже реализованы в модулях расширения.12 При решении любой задачи на языке Perl возьмите себе за правило пер- вым делом обращаться к архиву CPAN. Так вы сэкономите на времени разработки и от- ладки. 2.5. Создание сценариев на языке PYTHON По мере усложнения и увеличения в объеме программных проектов становятся оче- видными преимущества объектно-ориентированного проектирования и реализации. Языку Perl явно не хватало объектно-ориентированного “буксира” в течение почти пяти лет, и хотя разработчики изо всех сил “налегали на весла”, чтобы как-то удержаться на плаву, Perl-версия объектно-ориентированного программирования все еще оставляет желать лучшего. Этот раздел посвящен языку Python (версии 2). Версия Python 3 пока находится в ра- боте и, по всей вероятности, будет выпущена после выхода этой книги. Но, в отличие от Perl 6, она будет значительно усовершенствована. Разработчикам с сильной подготовкой в области объектно-ориентированного про- граммирования обычно нравятся Python и Ruby — языки написания сценариев с рез- ко выраженным объектно-ориентированным уклоном. Создается такое впечатление, что язык Python в данный момент находится на нисходящей части кривой восприятия, поэтому его распространение — относительно простое направление деятельности для 12 Вот что по этому поводу думает разработчик UNIX Том Кристиансен (Tom Christiansen): “В принципе, это правильно, но я бы выбрал другого кандидата. Претендентом на звание “самой распространенной ошибки в программах” я бы назвал тенденцию, состоящую в том, что програм- мы, как правило, никогда не переписываются. Если вы когда-то писали сочинение, то знаете, на- сколько сильно могут отличаться его начальный и конечный варианты. Так и в программировании. Вероятно, вы слышали такое высказывание: ‘Никогда не останавливайся на опытном образце’. Другими словами, очень печально, что люди, затратив силы на создание какой-то программы, почему-то никогда не переделывают ее, чтобы улучшить ее ясность и повысить эффективность”.
Глава 2. Сценарии и командная оболочка 109 менеджмента. Некоторые операционные системы, включая OpenSolaris, инвестируют значительные средства в развитие Python-возможностей по написанию сценариев. Язык Ruby, наоборот, по-прежнему ассоциируется, главным образом, с веб-разработкой и ред- ко используется для сценариев общего назначения. Язык Python был создан Гуидо ван Россумом (Guido van Rossum). По сравнению с Perl, здесь проще процесс кодирования, а сам код читабельнее. Python отличается про- стым для понимания синтаксисом даже для тех, кто сам не разрабатывал код. Если вам трудно запомнить детали использования операторов сравнения, вы оцените унифициро- ванный подход, реализованнный в языке Python. Что касается системных администра- торов, то они считают весьма полезными дополнительные типы данных, предлагаемые языком Python. Если Python еще не инсталлирован в вашей системе, просмотрите список доступных пакетов, предлагаемых вашим поставщиком. Если с этим у вас возникнут проблемы, вы можете получить исходный код Python с сайта python. org. Здесь также вы найдете мо- дули расширений, разработанные сторонними производителями. Для того чтобы получить более подробное введение в язык Python, чем представлен- ное здесь, начните с книги Марка Пилгрима (Mark Pilgrim) Dive Into Python. Ее можно прочитать и бесплатно загрузить на сайте diveintopython. org (или купить в печатном виде от издательства Apress). Полный список предлагаемой литературы по обсуждаемой теме приведен в разделе 2.7. Быстрое погружение в языковую среду Python Как обычно, начнем с вывода сообщения “Привет, мир!”. Как видите, его Python- версия практически идентична Peri-варианту. #!/usr/bin/python print "Привет, мир!" Для выполнения этой программы установите “исполнительный” бит или вызовите напрямую интерпретатор языка Python. $ chmod +х helloworld $ ./helloworld Привет, мир! В этой программе не иллюстрируется самое “возмутительное” отступление Python от традиций, к которым мы так привыкли в программировании. В языке Python не исполь- зуются ни скобки (фигурные и квадратные), ни специальные ключевые слова (begin и end), ограничивающие блоки. Операторы на одном и том же уровне отступа автомати- чески формируют блоки. Конкретный стиль отступов (пробелы или табуляция, глубина отступа) не имеет значения. Формирование блоков в Python прекрасно показано на сле- дующем примере, в котором используется оператор if-then-else. #!/usr/bin/python import sys a = sys.argvfl] if a == ”1": print ’а равно одному' print 'Это все еще ветвь then оператора if. ' 5 else:
110 Часть I. Основы администрирования print 'а равно', а print 'Это все еще ветвь else оператора if. ' print 'А это уже за границей оператора if. ' В третьей строке программы импортируется модуль sys, который содержит массив argv. Обе ветви then и else оператора if имеют по две строки, и все они “отмечены” отступом одинакового уровня. Последний оператор print “выпадает” из контекста опе- ратора if. Как и в языке Perl, Python-оператор print принимает произвольное количе- ство аргументов. Но, в отличие от Perl, Python-оператор print вставляет пробел между каждой парой аргументов и автоматически “приправляет свое блюдо” символом новой строки. Вы можете подавить разделитель строк, включив дополнительную запятую в ко- нец строки print; кроме того, null-аргумент предписывает оператору print не выво- дить символ новой строки. Двоеточие в конце строки обычно служит признаком того, что за ней (этой строкой) следует блок, состоящий из строк с отступами. $ python blockexample 1 а равно одному Это все еще ветвь then оператора if. А это уже за границей оператора if. $ python blockexanqple 2 а равно 2 Это все еще ветвь else оператора if. А это уже за границей оператора if. Соглашение о Python-отступах ограничивает наши возможности в форматировании кода, но зато дает выигрыш в том, что программы, написанные разными программи- стами, выглядят практически одинаково. Это соглашение также означает, что для про- граммистов отпадает необходимость “сдабривать” код знаками “точка с запятой” для завершения операторов. Комментарии начинаются с символа # и продолжаются до конца строки (точно так же, как в оболочке bash и языке Perl). Длинную строку можно разбить на части с помощью символа “”, помещенного В конце. В этом случае имеет значение только отступ первой строки. При желании можете использовать отступы и в остальных строках-продолжениях (частях разбитой длинной строки). Строки с несбалансированными скобками (круглыми, квадратными или фигур- ными) автоматически сигнализируют о продолжении строки даже при отсутствии сим- вола “”, но вы можете вставить этот символ, чтобы прояснить структуру вашего кода. При выполнении некоторых операций вырезки и вставки символы табуляции пре- образуются в пробелы, что может иметь для вас неожиданные последствия. Поэтому следуйте золотому правилу: никогда не смешивайте символы табуляции и пробелы; для создания отступов используйте либо табуляцию, либо пробелы. Работа многих про- граммных продуктов основана на традиционном предположении, что символ табуляции соответствует интервалу, состоящему из восьми пробелов, что на практике “выливается” в слишком большие отступы для получения читабельного кода. Большая часть Python- сообщества предпочитает использовать пробелы и 4-символьные отступы. Если вы захотите кардинально решить проблему отступов, то, “идя навстречу вашим пожеланиям”, многие текстовые редакторы включают средства, которые помогают со- хранить в здравии вашу психику, либо запрещая символы табуляции (в пользу пробе- лов), либо отображая эти “конкурирующие” символы по-разному. В качестве послед-
Глава 2. Сценарии и командная оболочка 111 него средства можете переводить символы табуляции в пробелы с помощью команды expand или использовать команду perl -ре для замены табуляции строкой символов, которая лучше видна. Объекты, строки, числа, списки, словари, кортежи и файлы Все типы данных в языке Python являются объектами, и это придает им больше силы и гибкости, чем в языке Perl. В языке Python списки заключаются в квадратные скобки (а не в круглые). Индек- сация массивов начинается с нуля (это один из немногочисленных принципов, который не меняется для всех трех “сценарных” языков, рассматриваемых в этой главе). “Новым словом” в языке Python прозвучали “кортежи,” которые, по сути, представ- ляют собой неизменяемые списки. Кортежи работают быстрее, чем массивы, и оказыва- ются весьма полезными для представления данных, которые должны быть немодифици- рованными. Синтаксис для кортежей такой же, как для списков, за исключением того, что разделителями у них служат круглые скобки (а не квадратные). Поскольку запись (thing) похожа на простое алгебраическое выражение, кортежи, содержащие только один элемент, должны иметь дополнительную запятую, которая не оставит у вас сомне- ний, с чем именно вы имеете дело, — (thing, ). Рассмотрите пример использования некоторых основных типов данных в языке Python. #!/usr/bin/python name = ’Gwen* rating = 10 characters = [ 'ГубкаБоб', ’Патрик', 'Сквидвард’ ] elements = ( 'литий', 'углерод', 'бор' ) print "Имя:Ь%зпРейтинг:t%d" % (name, rating) print "Герои:t%s" % characters print "Элементы:t%s" % (elements, ) Вот как выглядит результат выполнения этого примера. $ python objects Имя: Gwen Рейтинг: 10 Герои: ['ГубкаБоб', 'Патрик', 'Сквидвард'] Элементы: ('литий', 'углерод', 'бор') Переменные в языке Python не отмечаются синтаксически и не объявляются с указа- нием типа, но объекты, на которые они ссылаются, имеют базовый тип. В большинстве случаев язык Python автоматически не преобразует типы за вас, но это могут сделать отдельные функции или операторы. Например, вы не можете сцепить строку и число (с помощью оператора “+”) без явного преобразования числа в его строковое представ- ление. Однако операторы форматирования приводят объекты любого типа к строковому виду. Каждый объект имеет строковое представление. Действие оператора строкового форматирования “%” во многом подобно действию Функции sprintf из языков С или Perl, но его можно использовать везде, где может находиться строка. Это бинарный оператор, в левой части которого стоит строка, а
112 Часть I. Основы администрирования правой — вставляемые значения. Если вставляемых значений несколько, они должны быть представлены в виде кортежа. Словарь в языке Python — это то же самое, что хеш в языке Perl, т.е. список пар “ключ/значение”. Словарные литералы заключаются в фигурные скобки, а элементы, составляющие пару “ключ/значение”, отделяются друг от друга двоеточием. #!/usr/bin/python ordinal = { 1 : 'первый’, 2 : 'второй’, 3 : ’третий' } print "Массив ordinal содержит", ordinal print "Значением ordinal для ключа 1 является", ordinal[1] На практике Python-словари во многом подобны массивам, за исключением того, что “словарные” индексы (ключи) могут быть объектами, отличными от целых чисел. $ python dictionary Массив ordinal содержит {1: ’первый’, 2: 'второй', 3: 'третий'} Значением ordinal для ключа 1 является первый В языке Python файлы открываются как объекты с помощью соответствующих ме- тодов. Метод readline, вполне оправдывая свое имя, считывает одну строку. При вы- полнении приведенного ниже примера считываются (и выводятся) две строки из файла /etc/passwd. #!/usr/bin/python f = open('/etc/passwd', 'r') print f.readline(), print f.readline() , f .close () $ python fileio at:x:25:25:Batch jobs daemon:/var/spool/atjobs:/bin/true bin:x:1:1:bin:/bin:/bin/true Замыкающие запятые в операторах print используются для подавления символов новой строки, поскольку каждая строка и так уже включает этот символ, считанный из исходного файла. Пример контроля входных данных Приведенный ниже сценарий — это Python-версия уже знакомой нам программы проверки допустимости входных данных. В этом сценарии демонстрируется использова- ние подпрограмм и аргументов командной строки, а также некоторых других “питониз- мов” (от англ. Python — питон). #!/usr/bin/python import sys import os def show_usage(message, code - 1) : print message print "%s: source_dir dest_dir" % sys.argv[0] sys.exit(code) if len(sys.argv) != 3: show_usage("Нужно передать 2 аргумента; вы передали %d" % (len(sys.argv) - 1)) elif not os.path.isdir(sys.argvfl]):
Глава 2. Сценарии и командная оболочка 113 show_usage (’’Недопустимый каталог-источник”) elif not os .path, isdir (sys .argv[2]) : show_usage("Недопустимый каталог-приемник") source, dest - sys.argv[l:3] print "Каталогом-источником является", source print "Каталогом-приемником является", dest В дополнение к импортированию модуля sys, мы также импортируем модуль os (чтобы получить доступ к утилите os .path, isdir). Обратите внимание на то, что ко- манда import не позволяет вам “фамильярничать” с содержимым импортируемых мо- дулей при доступе к любым определенным в них символам, т.е. вы не освобождаетесь от необходимости использовать полные имена, которые начинаются с имени модуля. Определение подпрограммы show usage предполагает использование значения по умолчанию для кода завершения на случай, если вызывающий оператор не передаст этот аргумент в явном виде. Поскольку все типы данных являются объектами, аргумен- ты функции передаются по ссылке. Первый элемент массива sys. argv (в позиции 0) содержит имя сценария, поэтому длина массива на единицу больше, чем количество реально переданных аргументов ко- мандной строки. Запись sys. argv [ 1: 3J означает только часть массива. Удивительно, но часть (подмассив) не включает элйййгг, расположенный на дальнем конце заданно- го диапазона, поэтому рассматрйЙЙеЙ&я часть массива содержит только элементы sys. argv [ 1 ] и sys. argv [ 2 ]. Чтобы включить в подмассив второй и последующие аргумен- ты командной строки, можно использовать выражение say sys. argv [ 1: ]. Подобно оболочке bash и языку Perl, в языке Python предусмотрено специальное условие “else if ”, которому соответствует ключевое слово elif. В языке Python нет оператора-переключателя (switch) для передачи управления на различные ветви (case) в зависимости от результата сравнения аргумента с заданными значениями. Параллельное присваивание значений переменным source и dest несколько отли- чается от Perl-версии тем, что самих этих переменных нет в списке. Язык Python позво- ляет параллельные присваивания в любой форме. В языке Python используются одинаковые операторы сравнения для числовых и стро- ковых значений. Оператор сравнения “ !=” означает “не равно”. Обратите внимание на то, что в языке Python унарного оператора “! ” нет; используйте вместо него оператор not. Булевы операторы and и or выполняют булевы операции (что вполне ожидаемо), но они не возвращают булевы значения: результатом всегда является значение одного из операндов. Циклы В приведенном ниже фрагменте используется конструкция for...in, обеспечивающая выполнение итераций в диапазоне от 1 до 10. for counter in range (1, 10): print counter, Как и в подмассиве из предыдущего примера, правый конец указанного диапазона на самом деле не включается, поэтому результат содержит только числа от 1 до 9. 1 2 3 4 5 6 7 8 9
114 Часть I. Основы администрирования Цикл for в этой форме существует только в языке Python, причем он обладает таки- ми сильными свойствами, которые существенно отличают его от циклов for в других языках. • В синтаксисе цикла нет никаких специальных требований в отношении числовых диапазонов. Итерационную Python-модель может поддерживать практически лю- бой объект. Так, вы можете организовать выполнение итераций по строке (посим- вольно), списку, файлу (по символам, строкам или блокам), подмассиву и т.д. • Итераторы могут возвращать несколько значений, и вы можете использовать не- сколько переменных цикла. Присваивание в начале каждой итерации работает по- добно обычным множественным Python-присваиваниям. • Оба цикла for и while могут иметь в конце оператор else, который выполняется только в том случае, если цикл завершается нормально (в противоположность вы- ходу из цикла посредством оператора break). Это свойство на первый взгляд мо- жет показаться нелогичным, но оно позволяет реализовать довольно элегантные решения для выполнения определенных действий при заданных условиях. В приведенном ниже примере сценарий принимает в командной строке регулярное выражение и сопоставляет его со списком имен карликов (из сказки “Белоснежка и семь гномов”) и цветов их костюмов. Первое совпадение выводится в виде сообщения о том, какого цвета костюм у такого-то карлика, причем те части текста, которые совпали с регулярным выражением, содержат знаки подчеркивания. #!/usr/bin/python import sys import re suits = { 'Bashful':'red', 'Sneezy':'green', 'Doc'blue', 'Dopey':'orange', 'Grumpy':'yellow', 'Happytaupe', 'Sleepy':'puce' } pattern = re.compile("(%s)" % sys.argv[l]) for dwarf, color in suits.items(): if pattern.search(dwarf) or pattern.search(color): print "%s's dwarf suit is %s." % (pattern.sub(r"_l_", dwarf), pattern.sub(r"_l_", color)) break else: print "No dwarves or dwarf suits matched the pattern." Вот как выглядят результаты выполнения этого сценария. $ python dwarf search ' [aeiou] {2}' Sn_ee_zy's dwarf suit is gr_ee_n. $ python dwarf sear ch go No dwarves or dwarf suits matched the pattern. Присваивание переменной suits демонстрирует Python-синтаксис для кодирования литеральных словарей. Метод suits. items () работает как итератор для пар “ключ/ значение” — обратите внимание на то, что на каждой итерации мы извлекаем как имя карлика, так и цвет костюма. Если хотите, чтобы итерация происходила только по клю- чам, можете использовать такой вариант организации цикла: for dwarf in suits.
Глава 2. Сценарии и командная оболочка 115 Python реализует обработку регулярного выражения посредством его модуля ге. Никакие правила работы с регулярными выражениями не встроены в сам язык, поэтому их обработка в Python более громоздкая, чем в Perl. Здесь сначала выбирается регуляр- ное выражение pattern из первого аргумента командной строки, заключенного в кру- глые скобки, чтобы сформировать “группу захвата”. Затем проверяются и модифицируются строки с помощью методов search и sub объекта регулярного выражения. Можно также использовать вызов соответствующих функций (например, re. search), передав регулярное выражение в качестве первого ар- гумента. Выражение 1 в строке подстановки представляет собой обратную ссылку на содержимое первой “группы захвата”. 2.6. Передовой опыт создания сценариев Несмотря на то что фрагменты программ в этой главе снабжены некоторыми ком- ментариями и сообщениями о правильном применении сценариев (поскольку мы хоте- ли обратить ваше внимание на кое-какие нюансы), хотелось бы, чтобы реальные сцена- рии были еще лучше. Существует множество книг о написании качественных программ, но все же будет не лишним изложить здесь некоторые основные рекомендации по на- писанию сценариев. • При запуске с неадекватными аргументами сценарий должен вывести сообщение о его корректном применении и завершиться. Можно также реализовать возмож- ность получения справочной информации (—help). • Проверяйте входные данные и выходные значения на корректность. Прежде чем выполнять команду rm -rf (удаление указанных имен файлов из каталога), хоро- шо было бы, чтобы сценарий сначала удостоверился, что полученный в результате путь будет соответствовать ожидаемому образцу. Такие двойные предосторожности (и средства языка, которые позволяют их реализовать) иногда оказываются весьма полезными. • Сценарий должен возвращать надлежащий код завершения: нуль — в слу- чае успешного выполнения и ненулевое значение — при неудачном исходе. Необязательно сопровождать каждый вид отказа уникальным кодом завершения, однако следует поинтересоваться, какая информация была бы полезной для вы- зывающих процедур. • Используйте соответствующие соглашения о присвоении имен для переменных, сценариев и подпрограмм. Приведите в соответствие соглашения, действующие в языке, в остальной части кодовой основы вашего узлами, что самое важное, других переменных и функциях, определенных в текущем проекте. Используйте принцип смешанного регистра букв или знаки подчеркивания, чтобы сделать читабельны- ми длинные имена.13 • Для переменных используйте имена, которые отражают хранимые в них значения, но старайтесь все же давать имена покороче. Например, переменную для хранения количества входных строк можно, конечно, назвать number of lines of input, но уж очень оно длинное, и его лучше заменить так: n lines. 13 Имена самих сценариев также имеют большое значение. В этом контексте “в роли” пробе- лов дефисы предпочтительнее, чем знаки подчеркивания (например, system-config-printer).
116 Часть I. Основы администрирования • Разработайте руководство по стилю, чтобы вы и ваши коллеги могли писать код, используя одни и те же соглашения. Такое руководство облегчит вам понимание кода, написанного другими программистами, а им — написанного вами. • Начинайте каждый сценарий с блока комментария, в котором будет сказано, что делает данный сценарий и какие параметры он принимает. Не забудьте указать свое имя и текущую дату. Если сценарий требует, чтобы в системе были инсталли- рованы нестандартные инструменты, библиотеки или модули, обязательно пере- числите их. • Комментируйте свой код, используя такую степень детализации, какую посчитае- те полезной, с учетом временного “отхода” от этого кода и с последующим воз- вратом к нему через месяц или два. Имеет смысл также комментировать выбор алгоритма, причины неиспользования более очевидного способа кодирования, необычные пути в коде, все “трудные места”, возникшие в период разработки. Не загромождайте код бесполезными комментариями; отнеситесь к написанию ком- ментариев с точки зрения потенциального читателя: пишите лаконично, грамотно и “по делу”. • Комментарии кода лучше всего применять к целым блокам или функциям. Комментарии, которые описывают назначение переменной, следует вставлять вместе с объявлением этой переменной или при ее первом использовании. • Лучше запускать сценарии от имени суперпользователя root. Не устанавливайте для них атрибут setuid, поскольку такие сценарии довольно трудно сделать со- вершенно безопасными. Для того чтобы реализовать надлежащие стратегии управ- ления контролем доступа, используйте команду sudo. • В оболочке bash используйте ключ -х, чтобы отобразить команды, прежде чем они будут выполнены, и ключ -п, чтобы проверить синтаксис команд без их вы- полнения. • Используйте Perl-ключ -w, который предупредит вас о подозрительном поведе- нии, например об использовании переменных до установки их значений. Вы мо- жете использовать этот ключ в “описательной” строке или “внедрить” его в текст программы с помощью директивы use warnings. • Выполняя Python-сценарий, вы находитесь в режиме отладки, если явно не от- ключите его с помощью аргумента -0 в командной строке. Это означает, что еще до вывода диагностических выходных данных вы можете протестировать специ- альную переменную______debug___. Том Кристиансен (Tom Christiansen) предлагает следующие пять золотых правил для генерирования полезных сообщений об ошибках. • Сообщения об ошибках должны направляться в канал STDERR, а не STDOUT. • Включайте в сообщение об ошибке имя программы. • Указывайте виновника (имя функции или операции) ошибочного действия. • Если к сбою приводит системный вызов, включите строку реггог ($ ! в языке Perl). • Если код завершения некоторой операции не равен нулю, обеспечьте выход из программы. В среде Perl несложно следовать всем этим пяти правилам. die "can't open $filename: $!";
Глава 2. Сценарии и командная оболочка 117 2.7. Рекомендуемая литература • Brooks, Frederick Р. JR. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley, 1995. Основы работы в командной оболочке и написание сценариев в среде bash • Albing, Carl, JP Vossen and Cameron Newham. Bash Cookbook. Sebastopol, CA: O’Reilly Media, 2007. • Kemighan, Brian W. and Rob Pike. The UNIX Programming Environment. Englewood Cliffs, NJ: Prentice-Hall, 1984. • Newham, Cameron and Bill Rosenblatt. Learning the bash Shell (3rd Edition). Sebastopol, CA: O’Reilly Media, 2005. • Powers, Shelley, Jerry Peek, Tim O’reilly and Mike Loukides. Unix Power Tools, (3rd Edition), Sebastopol, CA: O’Reilly Media, 2002. Регулярные выражения • Friedl, Jeffrey. Mastering Regular Expressions (3rd Edition), Sebastopol, CA: O’Reilly Media, 2006. • Goyvaerts, Jan and Steven Levithan. Regular Expressions Cookbook. Sebastopol, CA: O’Reilly Media, 2009. Написание сценариев на языке Perl • Wall, Larry, Tom Christiansen and Jon Orwant. Programming Perl (3rd Edition), Sebastopol, CA: O’Reilly Media, 2000. • Schwartz, Randal L., Tom Phoenix and Brian D Foy. Learning Perl (5th Edition), Sebastopol, CA: O’Reilly Media, 2008. • Blank-Edelman, David. Automating System Administration with Perl, Sebastopol, CA: O’ReiUy Media, 2009. • Christiansen Tom and Nathan Torkington. Perl Cookbook (2nd Edition). Sebastopol, CA: O’ReiUy Media, 2003. Написание сценариев на языке Python • Beazley, David M. Python Essential Reference (4th Edition), Reading, MA: Addison- Wesley, 2009. • Gift, Noah and Jeremy M. Jones. Python for Unix and Linux System Administrators, Sebastopol, CA: O’ReiUy Media, 2008. • Martelli, Alex, Anna Martelli Ravenscroft and David Ascher. Python Cookbook (2nd Edition), Sebastopol, CA: O’ReiUy Media, 2005. • Pilgrim, Mark. Dive Into Python. Berkeley, CA: Apress, 2004. К этой книге можно также получить бесплатный доступ на веб-сайте diveintopython.org.
118 Часть I. Основы администрирования 2.8. Упражнения 2.1 UNIX позволяет в именах файлов использовать пробелы. Как найти файлы, имена которых содержат пробелы? Как удалить такие файлы? Можно ли рассчитывать на встроенные в оболочку bash и языки Perl и Python средства обработки пробелов в именах файлов или нужно самим предпринимать специальные меры предосторож- ности? Перечислите основные правила написания сценариев. 2.2. Напишите простой bash-сценарий (или два сценария) для резервирования и вос- становления вашей системы. 2.3 Используя регулярные выражения, напишите Perl- или Python-сценарий для анали- за даты в форме, генерируемой командой date (например, Tue Oct 20 18:09:33 PDT 2009), и определения ее корректности (например, чтобы не “прошло” несу- ществующее 30 февраля). Существует ли готовая библиотека или готовый модуль, который позволит вам сделать это одной строкой кода? Если да, то поясните, как инсталлировать их, и перепишите свой сценарий с их использованием. 2.4. Напишите сценарий, который перечисляет пользователей системы и группы, ис- пользуя файлы /etc/passwd и /etc/group (или их эквиваленты в сетевых базах данных). Для каждого пользователя выведите его идентификатор (UID) и группы, членом которых он является. 2.5. Усовершенствуйте подпрограмму get string (см. подраздел “Прием входных данных и проверка их достоверности” раздела 2.4 этой главы) так, чтобы она при- нимала только целые числа. Новая версия подпрограммы должна принимать три параметра: строку-приглашение, нижний предел и верхний предел допустимых це- лых чисел. 2.6. Найдите недокументированный сценарий, который используется в вашей среде. Прочитайте его и убедитесь, что понимаете его. Добавьте комментарии и напишите man-страницу для этого сценария. 2.7. ★ Напишите сценарий, который отображает короткую (длиной в одну страницу) суммарную сводку данных о состоянии оборудования по одной из следующих ка- тегорий: ЦП, память, диск или сеть. Ваш сценарий с помощью системных команд и файлов должен создать легко воспринимаемую инструментальную панель, кото- рая содержала бы максимально возможный объем информации. 2.8. ★ Создайте управляемый в режиме меню интерфейс, который упрощает выбор ключей командной строки для команд top, sar или инструмента анализа произво- дительности. 2.9. ★ Напишите сценарий для тестирования возможности сетевого соединения на сервере и служб обратных потоков, от которых она зависит (например, служба до- менных имен — DNS, файловая служба, протокол LDAP или другая каталоговая служба). В случае обнаружения каких-либо проблем обеспечьте отправку вам со- общения по электронной почте или текстового сообщения.
Глава Запуск и останов системы Как и практически все операции в UNIX, процедуры включения/выключения систе- мы превратились в тщательно спроектированные процессы, которые учитывают мно- жество возможных непредвиденных ситуаций. Как администраторы мы рассматриваем сложности процесса загрузки во многих аспектах, чтобы предотвратить потенциальные проблемы и устранить возникшие. Эффективный системный администратор, прежде всего, “зрит в корень”. Процесс начальной загрузки системы всегда был достаточно сложным, но все же он был несколько проще в те дни, когда изготовители определяли буквально все аспекты аппаратного и программного обеспечения. Теперь, когда Linux и Solaris управляют ап- паратным обеспечением персональных компьютеров, процедура загрузки должна вы- полняться по их правилам. При этом приходится иметь дело с множеством возможных конфигураций. Несмотря на то что в этой главе мы обсуждаем процедуру загрузки для всех рассматриваемых нами операционных систем, все же больше внимания уделяется версиям UNIX, ориентированным на персональные компьютеры, чем “стационарным” системам. Хотя эта глава в книге — одна из первых, в ней мы иногда оперируем понятиями, которые подробно рассматриваются лишь через несколько сотен страниц. Поэтому ре- комендуем также прочесть главы 6 и 13. 3.1. Начальная загрузка Под начальной загрузкой (bootstrapping), понимается запуск системы при включении питания. Поскольку обычные средства операционной системы на данном этапе еще не- доступны, система должна “самозагрузиться”, в буквальном смысле “обслужить себя
120 Часть I. Основы администрирования самостоятельно”. В ходе этого процесса ядро системы загружается в память и активи- зируется. Затем выполняется ряд инициализационных задач, после чего система готова к обслуживанию пользователей. Начальная загрузка — это период особой уязвимости системы. Ошибки в конфи- гурации, сбои в работе или отсутствие нужного оборудования, повреждения файловых систем могут помешать компьютеру нормально начать работу. Настройка режимов за- грузки часто является одной из первых задач, которую приходится решать администра- тору в новой системе, особенно при добавлении нового оборудования. К несчастью, эта задача — одна из наиболее сложных, и для ее решения необходимо хорошо знать многие другие аспекты системы. Когда включается питание, запускается на выполнение загрузочный код, хранящий- ся на постоянном запоминающем устройстве. Он должен запустить ядро. Ядро опраши- вает состояние аппаратных устройств, а затем запускает демон init, идентификатор ко- торого всегда равен 1. Прежде чем система полностью загрузится, должны быть проверены и смонтирова- ны файловые системы и запущены системные демоны. Соответствующие процедуры реализуются с помощью сценариев интерпретатора команд, которые последовательно запускаются демоном init. Конкретная структура сценариев и способ их выполнения зависят от системы. Все эти вопросы будут рассмотрены в данной главе. Главное — активизировать командную оболочку При нормальной работе системы сами выполняют начальную загрузку в автономном режиме, после чего к ним могут получить удаленный доступ администраторы и пользова- тели. Однако администраторам необходимо иметь инструмент восстановления системы в случае, если неожиданный отказ дисковода или какая-нибудь проблема конфигурации помешает системе нормально выполнить процесс начальной загрузки. Системы UNIX (вместо загрузки “по полной программе”) могут ограничиться только самым необходи- мым, а именно активизацией командной оболочки на системной консоли. Этот вариант называют входом системы в так называемый “однопользовательский режим”, режим вос- становления или профилактический режим — все эти термины в этой главе взаимозаме- няемы. Однопользовательский режим не позволяет выполнять сетевые операции, а для использования системной консоли вам нужно иметь физический доступ к ней. В большинстве систем для входа в однопользовательский режим во время начальной загрузки необходимо передать ядру в командной строке определенный параметр. Если система уже загружена и работает, вы можете перевести ее в однопользовательский ре- жим с помощью команды shutdown или telinit. Этапы загрузки Типичная процедура начальной загрузки состоит из шести отдельных этапов: • считывание начального загрузчика с главной загрузочной записи; • загрузка и инициализация ядра; • обнаружение и конфигурирование устройств; • создание процессов ядра; • вмешательство администратора (только в однопользовательском режиме); • выполнение системных сценариев запуска.
Глава 3. Запуск и останов системы 121 Почти все этапы не требуют интерактивного контроля со стороны администратора. Ведь администраторы имеют возможность управлять загрузкой системы, редактируя файлы конфигурации для сценариев запуска системы или изменяя аргументы, переда- ваемые загрузчиком ядру. Инициализация ядра CQ Подробнее о ядре рассказывается в главе 13. Ядро представляет собой программу, и в качестве первой задачи начальной загруз- ки выполняется запись этой программы в память для последующего выполнения. Имя файлу ядра дает его изготовитель, но по традиции оно называется /unix или /vmunix. В Linux-системах ядро обычно получает путевое имя в виде вариации на тему /boot/ vmlinuz. В большинстве систем загрузка осуществляется в два этапа. Сначала в память ком- пьютера с диска считывается (с помощью кода, записанного на постоянном запоми- нающем устройстве) небольшая программа начальной загрузки (именуемая начальным загрузчиком), которая затем выполняет собственно загрузку ядра. Эта процедура совер- шается вне UNIX-домена и поэтому не стандартизирована среди систем. Ядро выполняет тесты, позволяющие определить, сколько памяти имеется в распоря- жении системы. Часть внутренних структур ядра имеет фиксированный размер, поэтому ядро резервирует определенный объем физической памяти для самого себя. Эта память недоступна пользовательским процессам. Ядро выдает на консоль сообщение об общем объеме физической памяти и объеме памяти, доступной пользовательским процессам. Конфигурирование аппаратных средств Одна из первых задач ядра — исследование компонентов аппаратного обеспечения. В процессе тестирования различных системных шин и инвентаризации оборудования ядро выводит на консоль краткую информацию о каждом обнаруженном устройстве. Во многих случаях ядро загружает драйверы устройств как независимые модули ядра. Для систем, ориентированных на персональные компьютеры, дистрибутивы включают ядро, которое способно работать в большинстве аппаратных конфигураций компьютеров, тре- буя при этом минимальной настройки или же вообще обходясь без нее. Процесс конфигурации аппаратного обеспечения должен быть относительно про- зрачным для администраторов, особенно в среде Linux. Готовые ядра имеют модульную структуру и автоматически обнаруживают большую часть устройств. Тем не менее вы можете встретить нераспознанные устройства. О том, как справиться с конфигурацией драйверов вручную, прочитайте в главе 13. Создание процессов ядра После завершения этапа базовой инициализации ядро создает в области памяти, вы- деленной для пользовательских программ, несколько “самовыполняющихся” процес- сов. Это происходит “в обход” стандартного системного механизма fork (описан в раз- деле 5.2). Количество таких процессов зависит от операционной системы, хотя демон init всегда имеет идентификатор процесса (PID), равный 1. Большинство систем UNIX ис- пользует sched в качестве процесса с идентификатором 0.
122 Часть I. Основы администрирования В Linux процесс с идентификатором PID, равным 0, отсутствует. Демон init работает в сопровождении с различными обработчиками памяти и сигналов ядра, в том числе с теми, которые представлены в табл. 3.1. Все эти процессы имеют идентификаторы с низкими номерами, а их имена в листингах коман- ды ps заключены в квадратные скобки (например, [kacpid]). Иногда имена процессов могут содержать в конце символ косой черты и цифру, как, напри- мер, [kblockd/0 ]. Число указывает процессор, на котором выполняется дан- ный процесс. Эта информация может быть полезна при настройке многопро- цессорной системы. Таблица 3.1. Некоторые наиболее часто встречающиеся процессы ядра в Linux-системах Процесс kjournald kswapd ksoftirqd Записывает обновления журнала на диска Выполняет подкачку процессов при недостаточном объеме физической памяти Обрабатывает мягкие прерывания, если ими нельзя заняться во время переключения контекста khubd Выполняет конфигурирование USB-устройств а Для каждой смонтированной файловой системы ext3 или ext4 существует один процесс k joumald. Из этих процессов только init является полноценным пользовательским процес- сом; остальные фактически представляют собой части ядра, которые были сделаны про- цессами из концептуальных соображений. Системы UNIX создают подобные процессы ядра, но поскольку эти процессы ото- бражают особенности конкретной реализации ядра, никакие имена или функции не могут быть одинаковыми для разных систем. К счастью, администраторам никогда не приходится взаимодействовать с этими процессами напрямую. После создания этих процессов ядро больше не принимает участия в процедуре на* чальной загрузки системы. К этому моменту, однако, еще не создан ни один из процес* сов, управляющих базовыми операциями (например, регистрацией пользователей в си* стеме), и большинство демонов не запущено. Обо всем этом позаботится (в некоторых случаях косвенно) демон init. Действия оператора (только в режиме восстановления) Ш Подробнее об учетной записи root рассказывается в главе 4. Если систему нужно запустить в режиме восстановления, оператор устанавливает в командной строке специальный флаг, а ядро передает эту информацию демону init в качестве уведомления о запуске. Во время однопользовательской загрузки вы должны получить приглашение ввести пароль пользователя root. Если он введен правильно, за- пускается интерпретатор команд с правами суперпользователя. Можно не задавать па- роль, а просто нажать комбинацию клавиш <Ctrl+D>, после чего загрузка продолжится в многопользовательском режиме (подробнее см. раздел 3.4). СЗ Подробнее о файловых системах и их монтировании речь пойдет в главе 6. В однопользовательском режиме команды выполняются почти так же, как и в пол- ностью загруженной системе. Однако иногда монтируется только корневой раздел. Для того чтобы можно было использовать программы, находящиеся вне каталогов /bin, / sbin или /etc, необходимо вручную смонтировать остальные файловые системы.
Глава 3. Запуск и останов системы Во многих однопользовательских средах корневой каталог файловой системы мон- тируется в режиме только для чтения. Если каталог /etc является частью корневой файловой системы (обычная ситуация), редактирование многих файлов конфигурации будет невозможно? Чтобы выйти из положения, придется начать однопользовательский сеанс с повторного монтирования каталога / в режиме чтения/записи. Нужное действие в Linux-системах выполняет следующая команда. # mount -о rw,remount / В большинстве других систем вы можете выполнить команду mount /, чтобы реали- зовать обращение к файлу f stab или vfstab и выяснить, как должна быть смонтирова- на файловая система. В системе Red Hat загрузка в однопользовательском режиме выполняется не- сколько активнее, нежели обычно. До того момента, когда на экран будет вы- ведено приглашение интерпретатора команд, этот дистрибутив попытается смонтировать все локальные файловые системы. Хотя на первый взгляд такой подход кажется удобным, но при использовании недостаточно продуманной файловой системы он может порождать проблемы. Команда f sck, которая проверяет и восстанавливает поврежденные файловые систе- мы, обычно выполняется в ходе автоматической загрузки. Если система запускается в однопользовательском режиме, команду fsck придется вводить вручную. Подробнее эта команда описана в разделе 8.9. Когда интерпретатор команд однопользовательского режима завершит свою работу, система продолжит загрузку в нормальном режиме. Выполнение сценариев запуска системы В тот момент, когда система сможет выполнять сценарии запуска, ее уже можно на- звать UNIX. Это еще не полностью загруженная система, но “загадочных” этапов про- цесса загрузки больше не осталось. Файлы сценариев представляют собой обычные ко- мандные файлы, которые выбираются и запускаются демоном init по сложному, но, в общем-то, понятному алгоритму. Точное местонахождение, содержимое и организация сценариев запуска заслужива- ют отдельного изучения. Подробнее об этом рассказывается в разделе 3.6. Краткий курс написания сценариев можно пройти, изучив материал главы 2. Завершение процесса загрузки Ш Подробнее процесс регистрации в системе описан в разделе 31.8. После выполнения сценариев инициализации система полностью готова к работе. Такие системные демоны, как DNS- и SMTP-серверы, принимают и обслуживают под- ключения. Не забывайте о том, что демон init продолжает играть важную роль даже по завершении начальной загрузки. У демона init есть один однопользовательский и несколько многопользовательских Уровней выполнения”, определяющих, какие ресурсы системы будут доступны пользо- вателю. Уровни выполнения рассматриваются в разделе 3.5. 1 Например, однопользовательский режим используется для восстановления утраченного паро- ля суперпользователя. Эта операция требует модификации файла /etc/shadow.
124 Часть I. Основы администрирования 3.2. Загрузка системы на персональном компьютере До этого момента описывалась общая схема начальной загрузки. Теперь некоторые наиболее важные (и сложные) ее этапы необходимо рассмотреть подробнее, проанали- зировав особенности функционирования Intel-систем. Загрузка системы на персональном компьютере — это многоступенчатый процесс. Когда включается компьютер, начинает выполняться код, записанный на постоянном запоминающем устройстве. Точное его местонахождение и структура зависят от типа оборудования. В компьютерах, созданных специально для UNIX или другой коммерче- ской операционной системы, код “прошивается” разработчиком, который заранее за- дает алгоритм подключения устройств, базовой инициализации сети и распознавания локальных файловых систем. Это очень удобно для системного администратора. Ему достаточно ввести лишь имя нового файла ядра, а код постоянного запоминающего устройства автоматически обнаружит и прочитает этот файл. На персональных компьютерах код начальной загрузки представлен в виде базовой подсистемы ввода-вывода — BIOS (Basic Input/Output System), которая чрезвычайно упрощена в сравнении с фирменным кодом UNIX-станций. В действительности в си- стеме BIOS есть несколько уровней кода: для самого компьютера, для видеоплаты, для SCSI-адаптера, если таковой имеется, и иногда для других периферийных устройств вроде сетевых плат. Встроенному коду BIOS известно об устройствах, расположенных на материнской плате, в частности о IDE- и SATA-контроллерах (и жестких дисках), плате сетевого адап- тера, измерителе мощности и температуры, контроллере клавиатуры, последовательных и параллельных портах. SCSI-адаптеры знают только об устройствах, подключенных не- посредственно к ним. К счастью, за последние несколько лет сложные взаимодействия, необходимые для обеспечения совместной работы этих устройств, были стандартизова- ны и теперь почти не требуют вмешательства оператора. В режиме конфигурирования можно выбрать, с какого устройства требуется загру- жаться. Обычно последовательность загрузки задается в виде правила, например: “сна- чала — DVD, затем — “флешка” (USB drive), в последнюю очередь — жесткий диск”. Распространенным вариантом также считается сетевая загрузка с помощью среды РХЕ (см. раздел 12.1). Когда компьютер определил, с какого устройства следует загружаться, считывается его (устройства) первый блок. Этот сегмент (512 байт) называется главной загрузочной записью (master boot record — MBR). В ней хранится программа, которая сообщает ком- пьютеру о том, в каком разделе диска расположена программа вторичной загрузки (за- грузчик операционной системы). Дополнительная информация о разделах дисков на персональных компьютерах и главной загрузочной записи приведена в главе 8. Стандартная программа, находящаяся в главной загрузочной записи, дает компью- теру указание извлечь загрузчик операционной системы из первого раздела диска. В не- которых системах поддерживаются более сложные программы, которые могут работать с несколькими операционными системами и ядрами. Найдя раздел, с которого будет вы- полняться загрузка системы, программа главной загрузочной записи пытается запустить загрузочную программу, связанную с этим разделом. В случае успеха этой программе передаются полномочия по дальнейшей загрузке ядра.
Глава 3. Запуск и останов системы 125 3.3. GRUB: УНИВЕРСАЛЬНЫЙ ЗАГРУЗЧИК Программа GRUB (GRand Unified Boot loader), разработанная в рамках проекта GNU, используется как стандартный загрузчик в большинстве UNIX- и Linux-систем, оснащенных процессорами Intel. GRUB поставляется в составе многих дистрибутивов Linux и Solaris (с архитектурой х86) начиная с версии 10. Задача GRUB — выбрать из предварительно подготовленного списка ядро и загрузить его с опциями, заданными ад- министратором. Существует две ветви развития GRUB: оригинальная, официально именуемая “GRUB Legacy”, и более новая — GRUB 2. Название “GRUB 2” может ввести в за- блуждение, поскольку выпуски GRUB 2 в действительности имеют номера версий 1 и 2; Все наши примеры систем в настоящее время используют исходный вариант — GRUB Legacy, и именно эта версия описывается в данной книге. Версия GRUB 2 в концепту- альном плане подобна исходной, но отличается синтаксисом файла конфигурации. По умолчанию GRUB читает параметры загрузки из файла /boot/grub/menu.lst или /boot/grub/grub. conf. Считывание содержимого файла конфигурации проис- ходит в период запуска (что само по себе уже впечатляет), и это позволяет реализовать динамические изменения при каждой загрузке системы. Файлы menu. Ist и grub. conf отличаются незначительно, но имеют аналогичный синтаксис. Системы Red Hat ис- пользуют файл grub.conf, a Solaris, SUSE и Ubuntu — файл menu. 1st. Вот образец файла grub. conf. default==0 timeout=10 splashimage=(hdO,0)/boot/grub/splash.xpm.gz title Red Hat Enterprise Linux Server (2.6.18-92.1.10.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.1.10.el5 ro root=LABEL=/ В этом примере конфигурируется единственная операционная система, которая бу- дет загружена автоматически (default=0), если в течение 10 секунд с клавиатуры не поступят никакие данные (timeout=10). Корневая файловая система для конфигурации “Red Hat Enterprise Linux Server” находится в разделе (hdO, 0), что для GRUB означает обращение к первому разделу первого жесткого диска системы (нумерация “первый раз- дел” и “первый диск”определяется в BIOS). Программа GRUB загрузит ядро из файла /vmlinuz-2.6.18-92.1.10. е15, а затем выведет начальный образ экрана, хранящийся в файле /boot/grub/splash.xpm.gz. Путь поиска ядра указывается относительно раздела загрузки, который обычно монти- руется в каталоге /boot. Программа GRUB поддерживает мощный интерфейс командной строки и ряд функ- ций, которые позволяют редактировать записи файла конфигурации в ходе загрузки. Для того чтобы перейти в режим командной строки, в окне загрузки GRUB необходимо ввести команду с. Из командной строки можно загружать операционные системы, не от- раженные в файле grub. conf, выводить на экран информацию о системе и выполнять простейшую проверку файловой системы. Загрузчик предоставляет также ряд функций, подобных функциям интерпретатора команд, в том числе — функции завершения не полностью введенных команд и перемещения курсора. Любые действия, которые могут быть выполнены с помощью файла grub. conf, могут быть выполнены и посредством командной строки загрузчика GRUB.
126 Часть I. Основы администрирования Нажатие клавиши <ТаЬ> позволяет вывести на экран краткий список доступных ко- манд. Некоторые из наиболее полезных команд перечислены в табл. 3.2. Таблица3.2. Параметрыкомандной строки GRUB Команда reboot Мягкая перезагрузка системы find Поиск файла во всех смонтированных логических разделах root Указание корневого устройства (логического раздела) kernel Загрузка ядра с корневого устройства help Вывод интерактивной справки по команде boot Загрузка системы с указанного образа ядра Для получения подробной информации о загрузчике GRUB и его параметрах ко- мандной строки обратитесь к официальному руководству: gnu.org/software/grub/ manual. Параметры ядра Программа загрузчика GRUB позволяет передавать ядру параметры командной стро- ки. Как правило, эти параметры изменяют значения параметров ядра, вынуждают его опросить конкретные устройства, указывают путь поиска демона in it или назнача- ют конкретное корневое устройство. Несколько примеров этих параметров приведены в табл. 3.3. Таблица 3.3. Примеры параметров ядра времени загрузки Параметр As A A A'A-. • 'AASfc acpi=off Отключает компоненты Advanced Configuration (усовершенствованный интерфейс конфигурации) и Power Interface (интерфейс управления питанием) ini t=/bin/bash Заставляет ядро запускать только интерпретатор bash; используется при восста- новлении системы в случае сбоев root=/dev/foo Сообщает ядру о том, что корневым является устройство /dev/foo single Задает режим однопользовательской загрузки (только для Linux. Используйте ключ -sb системах Solaris — он предназначен для администраторов, знакомых со стандартом OpenBoot в других CPU-архитектурах) Параметры ядра, отредактированные во время загрузки, не сохраняются. Чтобы со- хранить изменения на будущие перезагрузки, отредактируйте строку kernel в файле grub. conf или menu. 1st. Ядро Linux постоянно совершенствуется с помощью заплат, повышающих уровень безопасности, исправлений ошибок и новых функций. Но, в отличие от других про- граммных пакетов, старые версии ядра обычно не заменяются новыми. Новые ядра ин- сталлируются наряду со старыми, чтобы в случае возникновения проблемы вы могли тут же вернуться к старому ядру. Это соглашение помогает администраторам отказаться от модернизации, если заплата ядра разрушает их систему. По прошествии некоторого вре- мени загрузочные меню GRUB заполняются различными версиями ядра. Обычно вы- бор версии ядра по умолчанию не представляет опасности, но если окажется, что ваша система не загружается после добавления заплаты, позаботьтесь о возможности выбора другого ядра.
Глава 3. Запуск и останов системы 127 Мультисистемная загрузка Поскольку на одном персональном компьютере может быть установлено несколько операционных систем, привычной является ситуация, когда компьютер загружается в мультисистемном режиме. Для этого загрузчик должен быть правильно сконфигуриро- ван, чтобы распознать имеющиеся на локальных дисках операционные системы. В сле- дующих разделах мы опишем некоторые проблемные блоки мультисистемной загрузки, а затем рассмотрим конкретные примеры конфигурации. В каждом разделе диска может храниться собственный вторичный загрузчик, одна- ко загрузочный диск должен иметь только одну главную загрузочную запись. Поэтому необходимо решить, какой загрузчик будет “главным”. Как правило, выбор диктуется особенностями имеющихся операционных систем. Для Intel-ориентированных UNIX- и Linux-систем лучше всего в качестве главного загрузчика выбрать GRUB. При двух- вариантной загрузке Windows-системы всегда используйте загрузчик GRUB (а не за- грузчик Windows). Конфигурирование загрузчика GRUB для выполнения мультисистемной загрузки во многом аналогично конфигурированию загрузки только одной операционной системы. Прежде чем вносить изменения в файл grub.conf или menu. 1st, нужно установить желаемые операционные системы. Записанные в файле grub. conf параметры конфигурации для загрузки операцион- ной системы Windows отличаются от параметров для загрузки UNIX или Linux. title Windows ХР rootnoverify (hd0,0) chainloader +1 Параметр chainloader загружает утилиту начальной загрузки из указанного ме- ста (в данном случае из сектора 1 первого раздела первого IDE-диска). Параметр rootnoverify предотвращает попытки загрузчика GRUB выполнить монтирование указанного раздела. Ниже приведен полный текст файла grub, conf для случая, когда система Windows ХР загружается (по умолчанию) из первого раздела, Red Hat Enterprise Linux — из второго. default=0 timeout=5 splashimage=(hdO,2)/boot/grub/splash.xpm.gz hiddenmenu title Windows XP rootnoverify (hd0,0) chainloader +1 title Red Hat root (hdO,l) kernel /vmlinuz Тот факт, что загрузчик GRUB решает многие потенциальные проблемы мультиси- стемной загрузки, в действительности не смягчает наш врожденный скептицизм в от- ношении мультисистемных конфигураций. Дополнительно об этом можно прочитать в разделе 30.3.
128 Часть I. Основы администрирования 3.4. Загрузка в однопользовательском режиме То, как начинается процесс загрузки, зависит от конкретной системы. Системы с не Intel-процессорами используют специально разработанные программы загрузки, в то время как на персональных компьютерах, в основном, загрузчики стандартизированы (благодаря GRUB). Однопользовательский режим при использовании GRUB Для того чтобы выполнить загрузку в однопользовательском режиме при использо- вании загрузчика GRUB, не нужно применять опции командной строки. Авторы этого загрузчика пришли к выводу, что параметры начальной загрузки должны легко подда- ваться изменению и что клавиша <а> — вполне подходящее средство для решения этой задачи. Когда откроется экран начальной загрузки GRUB, выделите нужное ядро и на- жмите клавишу <а>, чтобы дополнить опции начальной загрузки. Для того чтобы обе- спечить загрузку в однопользовательском режиме, добавьте флаг single (или -s в си- стеме Solaris) в конец существующих опций ядра. Пример типичной конфигурации мог бы выглядеть следующим образом. grub append> го root=LABEL=/ rhgb quiet single Однопользовательский режим в архитектуре SPARC Для того чтобы прервать процедуру загрузки и войти в среду OpenBoot PROM SOLariS на Sun-оборудовании, нажмите одновременно клавиши <Ы> и <а>. На со- временных Sun-клавиатурах клавиша <L1> иногда имеет надпись “STOP”. Для того чтобы выполнить загрузку в однопользовательском режиме из среды OpenBoot PROM, вы можете ввести команду boot -s. Для загрузки альтернативного ядра под управлением Solaris, как правило, нужно ввести полное Solaris-имя устройства и файла. Имя Solaris-устройства — это длинная странного вида строка символов, которую можно увидеть, введя команду Is -1 для файла /dev. % Is -1 /dev/rdsk/cOtOdOsO Irwxrwxrwx 1 root root 55 Jan 15 1998 /dev/rdsk/cOtOdOsO -> ../../devices/sbus@lf,0/SUNW,fas@e,8800000/sd@0,0:a,raw Для того чтобы загрузить ядро, хранимое в виде файла /kernel/backup на том же диске, введите следующую команду в режиме монитора OpenBoot PROM. boot /devices/sbus@lf,0/SUNW,fas@ef 8800000/sd@0,0:a,raw/kernel/backup Некоторые полезные команды, которые можно ввести из Sun-среды OpenBoot PROM, кратко описаны в табл. 3.4. Таблица 3.4. Некоторые PROM-команды для выполнения на Sun-оборудовании boot /path_to_kernel Загружает альтернативное ядро boot -s Загружает систему в однопользовательском режиме boot -г Распознает ядро и определяет наличие новых устройств boot -а /etc/system.bak Принуждает ядро читать файл /etc/system.bak вместо /etc/system probe-scsi Отображает список всех подключенных SCSI-устройств
Глава 3. Запуск и останов системы 12» Однопользовательский режим на рабочих станциях HP-UX KSt ПроцедУРа загрузки в однопользовательском режиме на рабочих станциях: HP-UX зависит от типа машины. Следующий пример взят с рабочей станции: HP 9000/735. Сначала прервите процесс загрузки после соответствующего напоминания. Получив; приглашение на ввод команд, введите команду boot pri isl. Эта команда сгенери- рует следующее приглашение, которое позволит вам загрузить систему в однопользова- тельском режиме. Это приглашение должно выглядеть примерно так. ISL> prompt: Следующая команда выбирает ядро и загружает систему в однопользовательском ре- жиме. ISL> prompt: hpux -iS /stand/vmunix Однопользовательский режим в системах AIX В системах AIX однопользовательский режим называется “профилактиче- ским”. Для его установки, если система еще не загружена, достаточно выбрать соответствующий пункт из меню загрузки. Если система уже загружена, ис- пользуйте команду telinit S. 3.5. Работа со сценариями запуска системы После выхода из однопользовательского режима (или — при стандартной загрузке — по завершении работы интерпретатора команд, запущенного с правами суперпользо- вателя) демон init выполняет сценарии запуска системы. Они являются сценариями интерпретатора sh (на самом деле bash), а их местонахождение, содержимое и органи- зация зависят от изготовителя системы. В большинстве систем используется подход, в котором сценарии нумеруются и вы- полняются по порядку. Сценарии хранятся в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rcO. d, /etc/rcl. d и т.д. Такая организация совершенно ясна, и поскольку сценарии выполняются по порядку, система может обеспечивать со- ответствующие зависимости между службами. Эти “пусковые” сценарии как запускают службы, так и останавливают их, поэтому такая архитектура также позволяет надлежа- щим образом остановить систему. Ниже приведен перечень задач, которые часто выполняются этими сценариями. • Задание имени компьютера • Установка часового пояса • Проверка дисков с помощью команды f sck • Монтирование дисков систем • Удаление старых файлов из каталога /tinp • Конфигурирование сетевых интерфейсов • Запуск демонов и сетевых служб
130 Часть I. Основы администрирования Сценарии запуска обычно довольно многословны и выводят подробную информа- цию о выполняемых ими задачах. Это может оказать существенную помощь при отладке сценариев или поиске причин зависания системы в процессе загрузки. Администраторам не следует заниматься модификацией сценариев запуска. Те сцена- рии, которые принимают данные конфигурации, читают их в форме отдельного файла конфигурации (специфичного для конкретного узла). Вы можете модифицировать вспо- могательный сценарий конфигурации и должны быть уверены, что он не будет переза- писан обновлениями. Сценарии процесса init используются в определенной степени всеми шестью опе- рационными системами, которые рассматриваются здесь в качестве примеров. Процесс запуска системы Solaris 10 был полностью переработан (см. раздел 3.6). Ubuntu исполь- зует “версию” процесса init, известную как Upstart, но мы все же рассмотрим ее в этом разделе, поскольку она имеет сходство с традиционным процессом init. В следующих разделах мы сначала представим общие принципы системы, а затем опишем индивидуальные особенности каждой системы. Демон init и его уровни выполнения Демон init — это первый процесс, который выполняется после завершения загруз- ки системы, и во многих отношениях он считается самым важным. Его идентификаци- онный номер (PID) всегда равен 1, и сам он является базовым для всех пользователь- ских и почти для всех системных процессов. Реализации демона init незначительно различаются в разных системах. Этот демон определяет по меньшей мере семь уровней выполнения, на каждом из которых должен выполняться конкретный набор системных служб. Точное определение каждого уровня в разных системах имеет свои особенности, но следующая информация справедлива для всех систем. • Уровень 0 означает, что система полностью прекратила работу. • Уровень 1 и S означает однопользовательский режим. • Уровни 2—5 предназначены для поддержки работы в сети. • Уровень 6 определяет этап перезагрузки системы. Уровни 0 и 6 характерны тем, что система не может на них оставаться. Если она на них переходит, то в качестве побочного эффекта происходит завершение рабо- ты или перезагрузка. В большинстве случаев система по умолчанию находится на уров- не 2 или 3. В Linux уровень 5 используется регистрационными процессами X Windows. Уровень 4 используется редко. Однопользовательскому режиму традиционно соответствовал уровень 1. На нем за- прещены все сетевые сеансы и процессы удаленной регистрации, а в системе выпол- няется минимальный набор программ. Но поскольку в этом режиме доступ к системе осуществляется с правами суперпользователя, администраторам необходимо, чтобы при загрузке система запрашивала ввод пароля. Для этой цели был введен уровень S: здесь создается отдельный процесс, отображаю- щий приглашение ввести пароль. В Solaris и AIX уровень S означает, что однопользова- тельский режим “в действии”, но в Linux уровень S носит переходный характер и завер- шается сразу после ввода пароля. Создается впечатление, что уровней выполнения больше, чем нужно. Обычно это объясняется тем, что в телефонном коммутаторе 7 уровней, поэтому считалось, что
Глава 3. Запуск и останов системы 131 в UNIX-системе должно быть как минимум столько же. В действительности в системах Linux и АЕХ поддерживается до десяти уровней, хотя большинство уровней не опреде- лено. В стандартной конфигурации системы AIX значимым является только уровень 2. Уровни 0 и 1 зарезервированы для операционной системы, а уровни 3—9 открыты для использования администраторами. В файле /etc/inittab содержатся параметры, определяющие, что должен делать демон init на каждом уровне. Формат файла зависит от системы, но основная идея со- стоит в том, что в нем задаются команды, которые должны быть выполнены (или про- должить выполнение), когда система переходит на конкретный уровень. В процессе загрузки демон init последовательно продвигается от уровня 0 к уровню по умолчанию, заданному в файле /etc/inittab. Чтобы осуществить переход между соседними уровнями, демон выполняет команды из этого файла. Аналогичные дей- ствия, только в обратном порядке, происходят при останове системы. Команда telinit позволяет изменить уровень выполнения демона init, когда система полностью функциональна. Например, команда telinit 3 переводит демон init на уровень 3. Самым полезным аргументом команды telinit является -q, кото- рый предписывает init перечитать файл /etc/inittab. К сожалению, структура файла inittab несколько недоработана и недостаточно хо- рошо согласуется с реальным механизмом запуска и остановки служб в системах UNIX. Для того чтобы сделать этот файл более эффективным, в демоне init реализован до- полнительный, абстрактный, уровень. Он представлен в виде команды, которая исходит из файла inittab и осуществляет смену уровней. Эта команда, в свою очередь, запуска- ет сценарии из каталога, зависящего от целевого уровня. Они-то и переводят систему в новое состояние. • Этот дополнительный уровень не до конца разработан в системах AIX. По- этому управление службами в системах AIX определяется только содержимым файла inittab. Кроме того, AIX-сценарии запуска немного отличаются от соответствующих сценариев в других системах. Большинство современных дистрибутивов Linux по умолчанию выполняет загруз- ку на уровень 5, что может быть не подходящим для систем, которым не требуется за- пускать дисплейный сервер (в среде X Window System). Изменение используемого по умолчанию уровня выполнения не представляет сложности. Следующая строка из файла inittab компьютера, работающего под управлением системы SUSE, определяет уро- вень 5 выполнения в качестве используемого по умолчанию. id:5:initdefault: Системным администраторам обычно не приходится работать непосредственно с файлом /etc/inittab, так как существующие сценарии подходят для большинства случаев. Далее в главе мы практически не будем упоминать об этом файле и взаимодей- ствии демона init со сценариями запуска системы. Просто, когда мы говорим о том, что демон init выполняет такой-то сценарий, нужно понимать следующее: связь со сценарием может быть косвенной. Обзор сценариев запуска Основные копии сценариев запуска хранятся в каталоге /etc/init.d. Каждый сце- нарий отвечает за запуск одного демона или определенной подсистемы. Сценариям можно передавать аргументы start и stop, которые означают, что соответствующая
132 Часть I. Основы администрирования служба должна быть запущена либо остановлена. Большинство сценариев понимает также аргумент restart, который эквивалентен связке stop+start. Обладая правами системного администратора, можно вручную запускать или останавливать нужные служ- бы, вызывая соответствующий сценарий из каталога init.d и передавая ему требуемый аргумент. Ниже показан несложный сценарий, позволяющий запускать, останавливать и пере- запускать демон sshd. # !/bin/sh test -f /usr/bin/sshd | I exit 0 case "$1" in start) echo -n "Starting sshd: sshd" /usr/sbin/sshd echo "." r r stop) echo -n "Stopping sshd: sshd" kill 'cat /var/run/sshd.pid' echo "." г г restart) echo -n "Stopping sshd: sshd" kill 'cat /var/run/sshd.pid' echo "." echo -n "Starting sshd: sshd" /usr/sbin/sshd echo "." *) echo "Usage: /etc/init.d/sshd start|stop|restart" exit 1 r r esac Сценарии каталога /etc/init.d способны запускать и останавливать отдельные службы, но, чтобы перейти на требуемый уровень, главный управляющий сценарий, выполняемый демоном init, должен получить дополнительную информацию о том, какие сценарии и с какими аргументами нужно запустить. Управляющий сценарий не просматривает непосредственно каталог init.d, а обращается к каталогу гсуровень.d, где уровень — это номер требуемого уровня выполнения, на который осуществляется переход (rcO. d, rcl. d и т.д.). В каталогах хсуровень.& обычно содержатся символические ссылки на сценарии каталога init.d. Имена ссылок начинаются с префикса S или к, за которым следует номер и имя службы, управляемой сценарием (например, S34named). Если демон init переходит на более высокий уровень, он выполняет все сценарии с префиксом S (“start” — запуск) в порядке возрастания номеров, причем каждому сце- нарию передается аргумент start. Когда осуществляется переход на более низкий уро- вень, запускаются сценарии с префиксом К (“А1П” — уничтожить) в порядке убывания номеров, и всем им передается аргумент stop. Эта схема позволяет администраторам очень точно управлять порядком запуска служб. Например, запуск сценария sshd до запуска сетевых интерфейсов лишен смысла. Хотя в системе Red Hat и сеть, и сценарий sshd выполняются на уровне 3, сценарию
Глава 3. Запуск и останов системы 133 network присваивается порядковый номер 10, а сценарию sshd — 55. Поэтому можно не сомневаться, что сценарий network будет запущен раньше. При добавлении новых служб необходимо учитывать подобные взаимосвязи. Чтобы сообщить системе, когда следует запускать тот или иной демон, нужно создать символическую ссылку в соответствующем каталоге. Например, следующие команды информируют систему о том, что демон печати cupsd должен быть запущен на уровне 2 и остановлен при завершении работы системы. # In —s /etc/init.d/cups /etc/rc2.d/S80cups # In -s /etc/init.d/cups /etc/rcO.d/K80cups Первая ссылка свидетельствует о том, что сценарий запуска /etc/init.d/cups дол- жен быть выполнен одним из последних при переходе на уровень 2 и ему должен быть передан аргумент start. Вторая ссылка сообщает, что в процессе завершения работы системы сценарий /etc/init.d/cups должен быть запущен относительно рано, при- чем с аргументом stop. В некоторых системах процессы останова и перезагрузки тракту- ются по-разному, поэтому необходимо также создать символическую ссылку в каталоге /etc/гсб .d, чтобы обеспечить корректный останов демона при перезагрузке системы. Сценарии запуска в системах Red Hat Сценарии запуска в дистрибутивах Linux сильно отличаются друг от друга. В основу сценариев Red Hat положен подход, реализованный в демоне init, причем в некоторых строках разобраться довольно трудно. На каждом уровне выполнения демон init вызывает сценарий /etc/rc.d/rc, пе- редавая ему номер уровня в качестве аргумента. Этот сценарий может выполняться как в обычном режиме, так и в режиме подтверждения, когда перед выполнением каждого сценария выдается запрос. Сценарии запуска хранят файлы блокировок в каталоге /var/lock/subsys. Наличие файла блокировок (с таким же именем, как у сценария запуска) служит признаком того, что данная служба уже “занята”. Сценарии запуска создают файлы блокировок при вы- даче команды start и удаляют их при выполнении команды stop. В системах Red Hat управлять службами можно с помощью команды chkconf ig. Эта команда добавляет или удаляет сценарии запуска из системы, управляет уровнями вы- полнения, на которых они работают, и выводит уровни, для которых сконфигурирован сценарий. Для получения информации о применении этого простого и удобного сред- ства можно использовать команду man chkconf ig. В Red Hat также предусмотрен сценарий /etc/rc.d/rc.local (не каталог), кото- рый запускается во время загрузки. Этот последний сценарий, выполняемый как часть процесса загрузки, позволяет добавлять нюансы, характерные для конкретного узла или для выполнения задач после загрузки. Когда появится сообщение “Welcome to Red Hat Enterprise Linux”, можно нажать клавишу <i>, чтобы продолжить загрузку в режиме подтверждения. Однако подтверж- дение о нажатии клавиши не отображается. Система продолжит монтировать локальные файловые системы, активизировать разделы подкачки, загружать таблицы клавиш и ве- сти поиск модулей ядра. Только после перехода на уровень 3 система начнет выдавать запросы на подтверждение. Режимы интерактивной и однопользовательской загрузки начинаются в одной и той же точке. Если в процессе загрузки возникли серьезные проблемы и этой точки достичь невозможно, воспользуйтесь для загрузки DVD-диском или устройством USB (флешкой).
134 Часть I. Основы администрирования Можно передать ядру параметр init=/bin/sh, чтобы заставить его вызвать интер- претатор команд однопользовательского режима еще до того, как будет запущен демон init2. В этом случае все действия по запуску системы придется осуществлять вручную, включая выполнение команды f sck и монтирование локальных файловых систем. Повлиять на процесс начальной загрузки в Red Hat можно путем модификации кон- фигурационных файлов, находящихся в каталоге /etc/sysconfig. Назначение элемен- тов этого каталога описано в табл. 3.5. Таблица 3.5. Файлы и подкаталоги каталога /etc/sysconfig в Red Hat Файл/подкаталог clock Задает тип системных часов (почти всегда UTC)а console Загадочный каталог, который всегда пуст crond Перечисляет аргументы, передаваемые демону cron il8n Содержит региональные установки системы (форматы представления даты/вре- мени, языки и т.д.) init Определяет способ отображения сообщений, поступающих от сценариев запуска системы keyboard Задает тип клавиатуры (используйте идентификатор “us” для стандартной 101-клавишной клавиатуры) mouse Задает тип мыши; используется системой X и программой gpm network Задает глобальные сетевые опции (имя компьютера, шлюз, переадресация и т.д.) network-scripts Каталог, содержащий вспомогательные сценарии и сетевые конфигурационные файлы sendmail Задает параметры программы sendmail а При использовании мультисистемной загрузки совершенно непонятно, какой часовой пояс следует уста- навливать для системных часов. Для некоторых элементов списка необходимы дополнительные пояснения. Файл network содержит адрес шлюза, имя хоста и другие важные установки, кото- рые действуют по умолчанию и применяются ко всем сетевым интерфейсам. Каталог network-scripts содержит вспомогательные файлы, связанные с конфи- гурацией сети. Единственное, что может потребоваться в нем изменить, — это файлы с именами ifcfg-интерфейс. Например, файл network-scripts/ifcfg-ethO хранит параметры конфигурации интерфейса ethO, в частности его IP-адрес и сетевые опции. Подробнее конфигурирование сетевых интерфейсов рассматривается в разделе 14.10. Файл sendmail содержит две переменные: DAEMON и QUEUE. Если переменная DAEMON равна значению yes, система запустит программу sendmail в режиме демона (-bd) в процессе начальной загрузки. Переменная QUEUE информирует программу sendmail о том, каков интервал обработки очереди почтовых сообщений (-д). Стандартная уста- новка — 1 час. 2 Однажды в нашей системе был поврежден файл, содержащий таблицу клавиш, и поскольку система Red Hat загружала этот файл даже в однопользовательском режиме, переход в этот ре- жим не позволял решить проблему. Передача параметра init=/bin/sh оказалась единственным безопасным способом загрузить систему и исправить ошибку. Этот прием эффективен и в других
Глава 3. Запуск и останов системы 135 Сценарии запуска в системах SUSE Сценарии запуска систем SUSE подобны сценариям Red Hat, по крайней ме- 6"’’ ре, по части общей организации. Эти сценарии не только четко организова- ны, но надежны и хорошо документированы. Стоит сказать спасибо разработ- чикам, которые отвечают за эту часть операционной системы. Как и в системе Red Hat, на каждом уровне выполнения демон init вызывает сце- нарий /etc/rc. d/rc, передавая ему номер уровня в качестве аргумента. Сценарии дан- ного пакета хранятся в каталоге /etc/init.d, а их файлы конфигурации — в каталоге / etc/sysconf ig. Прекрасное краткое описание процесса запуска системы SUSE можно найти в файле /etc/init.d/README. Хотя файлы конфигурации запуска как системы SUSE, так и Red Hat собраны в ка- талоге /etc/sysconf ig, конкретные файлы внутри этого каталога в значительной мере различны. (В частности, в целом файлы SUSE сопровождаются достаточно подробными комментариями.) Необходимые параметры вызываются посредством установки пере- менных среды интерпретатора, к которым затем обращаются сценарии, хранящиеся в каталоге /etc/init.d. Некоторые подсистемы требуют более подробного конфигу- рирования. Такие системы, нуждающиеся в нескольких файлах конфигурации, имеют приватные подкаталоги вроде sysconfig/network. Файл windowmanager — типичный пример файла, хранящегося в каталоге sysconfig. # # Path: Desktop/Window manager # # Type: string(gnome,startkde,startkde3,startxfce4,twm) # # Default: kde # # Config: profiles,kde,susewm # Здесь можно установить стандартный оконный менеджер (kde, fvwm, ...) # Эти изменения требуют перерегистрации DE F AULT_WM="gnome” # # Type: yesno # # Default: yes # инсталляция расширения SuSE для новых пользователей # (тема и дополнительные функции) INSTALL_DESKTOP_EXTENSIONS=,’yes’' # # Path: Desktop # # Description: стандартный вид курсора мыши # # Type: string # # Default: # Название вида курсора мыши для системы XII. Возможные изображения # можно найти в каталоге /usr/share/icons/ X_MOUSE_CURSOR=" DMZ" KDE_USE_IPV6="ye s"
136 Часть I. Основы администрирования Каждой переменной предшествует информация о конфигурации, считываемая утилитой YaST3, и подробное описание назначения переменной. Например, в файле windowmanager переменная DEFAULT_WM определяет диспетчер окна рабочего стола, используемый системой X. Пакет SUSE содержит также команду chkconf ig, которая позволяет управлять сце- нариями запуска системы. Она коренным образом отличается от версии, предоставляе- мой системой Red Hat, но также является эффективным средством управления сцена- риями. Сценарии запуска Ubuntu и демон Upstart ©Начиная с выпуска “Feisty Fawn” в начале 2007 года, в системах Ubuntu тради- ционный демон init был заменен службой начальной загрузки на основе со- бытий Upstart, которая используется и некоторыми другими дистрибутивами Linux. Служба Upstart обрабатывает переходы из одного состояния системы в другое (например, при изменении состава оборудования) более элегантно, чем это делает демон init. Кроме того, Upstart значительно сокращает время загрузки. Служба Upstart организует запуск и останов других служб и задач в ответ на такие события системы, как добавление устройства или отключение сетевого диска. Из сооб- ражений совместимости служба Upstart также эмулирует традиционные уровни выпол- нения демона init. Но сценарии запуска и останова обрабатываются несколько не так, как при использовании демона init. Демон Upstart использует файлы определения заданий из каталога /etc/event.d (а не файл inittab). Задание в концептуальном плане подобно сценарию загрузки, т.е. оно выполняет некоторую последовательность команд, а затем возвращает управление демону Upstart. Коллекция заданий в системе Ubuntu выглядит так. ubuntu$ Is /etc/event.d control-alt-delete last-good-boot logd rcO rcl rc2 rc3 rc4 rc5 rc6 rc-default rcS rcS-sulogin sulogin ttyl tty2 tty3 tty4 tty5 tty6 Co временем все больше сценариев загрузки будут преобразованы в Upstart-задания, а пока для загрузки системы демон Upstart использует сценарии эмуляции уровней вы- полнения. Например, сценарий гс2 (в виде файла /etc/rc2 .d/rc) выполняет все сце- нарии запуска для уровня 2. Из-за необходимости поддержки этой совместимости Ubuntu-администраторы долж- ны использовать Ubuntu-команду update-rc. d для обслуживания ссылок на сценарии запуска в рамках rc-каталогов. Вот как выглядит синтаксис этой команды. update-rc.d служба { start | stop } последовательность уровней . Команда update-rc.d принимает в качестве аргументов порядковый номер (имеет- ся в виду порядок выполнения сценариев загрузки) и нужные уровни выполнения. Для обозначения конца списка уровней используется символ точки. Службы, которые при смене уровня стартуют позже, должны останавливаться рань- ше при выходе системы с данного уровня. Например, если сервер печати CUPS во время загрузки запускается с порядковым значением 80, он должен остановиться приблизи- 3 YaST — специализированная утилита графической конфигурации SUSE, которая управляет многими аспектами этой системы.
Глава 3. Запуск и останов системы 137 тельно с номером 20, т.е. поближе к началу процесса останова. Команда update-rc.d, добавляющая соответствующие ссылки, должна иметь такой вид. ubuntu$ sudo update-rc.d cups start 80 2 3 4 5 . stop 20 S 1 6 . Adding system startup for /etc/init.d/cups ... /etc/rcl.d/K20cups -> ../init.d/cups /etc/гсб.d/K20cups -> ../init.d/cups /etc/rcS.d/K20cups -> ../init.d/cups /etc/rc2.d/S80cups -> ../init.d/cups /etc/гсЗ.d/S80cups -> ../init.d/cups /etc/rc4.d/S80cups -> ../init.d/cups /etc/rc5.d/S80cups -> ../init.d/cups Эта команда добавляет “стартовые” экземпляры сценариев с порядковым номе- ром 80 на уровнях выполнения 2—5, а также — “финишные” экземпляры с порядковым номером 20 на уровнях S, 1 и 6. Устанавливаемый по умолчанию уровень управляется двумя telinit-строками в файле /etc/event. d/rc-default. Изменить уровень выполнения можно, отредак- тиров файл rc-default в любом текстовом редакторе. Демон Upstart также управляет логинами на терминалах, используя задания с tty*- именами. Сценарии запуска в системах HP-UX В системах HP-UX сценарии запуска хранятся в каталоге /sbin/init .d. Каталоги уровней выполнения также хранятся в каталоге /sbin. Файлы кон- фигурации, связанные со сценариями запуска, обычно “прописаны” в ката- логе /etc/rc. conf ig. d. Их имена соответствуют именам сценариев запуска, хранимых в каталоге /sbin/init.d. Например, сценарий /sbin/init.d/ SnmpMaster получает информацию о конфигурации системы из файла /etc/ rc. config. d/SnmpMaster, а реально вызывается демоном init посредством ссылок /sbin/rc2 .d/S560SnmpMaster и /sbin/rcl .d/K440SnmpMaster. Система HP-UX сохраняет результаты выполнения сценариев запуска в файле /etc/ rc. log. В случае неудачного завершения одного из сценариев запуска просмотрите со- держимое файла /etc/rc. log, чтобы узнать, содержит ли он какие-либо релевантные сообщения об ошибках или подсказки относительно источника проблемы. Это сохране- ние результатов выполнения сценария запуска — самая полезная и замечательная функ- ция, которую, к тому же, просто реализовать. Удивительно, что другие разработчики си- стем не ухватились за эту идею. Файлы конфигурации, хранимые в каталоге /etc/rc.config.d, местами могут вво- дить в заблуждение, и это притом, что они в целом снабжены неплохими комментария- ми. Назначение некоторых чаще всего модифицируемых файлов описано в табл. 3.6. Для большинства этих файлов вполне подходят стандартные установки. Наиболее часто вам придется работать с такими файлами, как netconf, netdaemons и, возможно, nddconf. Таблица 3.6. Конфигурационные файлы HP-UX из каталога /etc/rc. config. d______ Jfefoibi Назначение____________ SnmpMaster Включает или отключает поддержку протокола SNMP Другие параметры, связанные с протоколом SNMP _____
138 Часть I. Основы администрирования Окончание табл. 3.6 Файлы acct auditing cde clean* hpetherconf Ip mailservs Включает или отключает подсистему учета процессов; см. acct (1М) Управляет работой подсистемы аудита; см. audsys и audevent Содержит настройки CDE (Common Desktop Environment — Единая настольная среда) Управляет операциями очистки, выполняемыми на этапе загрузки Конфигурирует Ethernet-интерфейсы; см. lanadmin Включает или отключает подсистему буферизации печати Запускает утилиту sendmail или задает почтовый сервер nameservs nddconf netconf netdaemons nettl nfsconf sshd Конфигурирует или запускает демон службы имен Задает параметры ядра, устанавливаемые на этапе загрузки с помощью демона ndd Задает параметры конфигурации сети (1 P-адрес и т.п.) Указывает на то, какие сетевые демоны следует запустить Конфигурирует подсистемы сетевой трассировки и регистрации3 Задает параметры NFS (Network File System — Сетевая файловая система) Конфигурирует параметры демона ssh vt Запускает демон vtdaemon; зависит от ptydaemon xfs Включает и отключает сервис шрифтов X Windows аСм. nettle(1М), nettlconf (1М) и nettlgen.conf (4) Запуск систем AIX еВ системах AIX используется более “прямолинейный” подход (по сравнению с другими описываемыми здесь системами) к процессу загрузки. Во время за- пуска система AIX выполняет сценарий /sbin/rc.boot, который написан на . языке, интерпретируемом командной оболочкой ksh. Сценарий rc.boot (его код отличается скудными комментариями) выполняется в три этапа: • инициализация системного оборудования; • монтирование системных файлов; • выполнение демона /etc/init, который обрабатывает записи файла /etc/ inittab. Система AIX в большей степени полагается на содержимое файла /etc/inittab, чем другие члены семейства UNIX-подобных систем. Демон init читает по очереди строки файла inittab и выполняет их. В некоторых случаях файл inittab запуска- ет демоны напрямую. Например, при выполнении следующей строки запускается или перезапускается демон cron на уровнях выполнения 2-9. cron:23456789:respawn:/usr/sbin/cron Другие строки файла inittab содержат последовательность команд. Например, bsh- сценарий /etc/rc. tcpip запускает на выполнение сетевые демоны. rctcpip-.23456789: wait: /etc/rc. tcpip > /dev/console 2>&1 # Start TCP/IP daemons
Глава 3. Запуск и останов системы 139 Здесь результат выполнения сценария rc. tcpip передается системной консоли. Демон init ожидает завершения этого сценария, а уж потом переходит к обработке сле- дующей строки файла. Л Для управления файлом inittab в системе AIX предусмотрены четыре простые ко- манды: mkitab, chi tab, Isitab и rmitab. Эти команды позволяют добавлять записи в файл, изменять их, выводить в виде списка и удалять из файла. Мы не понимаем, в чем состоит их преимущество, и предпочитаем редактировать файл inittab с помощью какого-нибудь текстового редактора (например, vi). 3.6. Загрузка систем SOLARIS С помощью механизма управления службами SMF (Service Management Facility) компания Sun модернизировала процесс загрузки для систем Solaris 10 и OpenSolaris. Механизм SMF обеспечивает комплексный и принципиально новый подход к управле- нию службами в системах UNIX. Его уникальность состоит в надстройке нового логиче- ского уровня над службами, который управляет зависимостями между ними и автомати- чески обрабатывает ошибки в данных конфигурации и программные сбои. Механизм SMF в значительной степени изменяет процедуру загрузки систе- мы. Традиционная схема работы демона init и его rc-сценариев уходит в прошлое. Разработчики Sun заявляют, что современные приложения и их взаимозависимости ста- ли слишком сложными для стандартной схемы управления ими. И они отчасти правы. С другой стороны, стандартная архитектура гораздо проще, и мы даже диву даемся, как Linux и другим популярным операционным системам удавалось работать при старой ор- ганизации. Прежде чем рассматривать процесс загрузки системы, опишем в общих чертах меха- низм SMF. Механизм управления службами в системе Solaris Sun определяет службу как “средство предоставления приложениям некоторого спи- ска возможностей и других служб, локальных и удаленных”. С нашей точки зрения, служба — это аналог демона: веб-сервер, системный регистратор syslogd или даже init. Любая служба в системе может быть представлена несколькими экземплярами. Например, вы могли бы запустить на выполнение несколько почтовых серверов с раз- личными конфигурационными данными и IP-адресами. Кроме того, службу можно определить как коллекцию других служб. Это свойство позволяет SMF взять на себя роль традиционных уровней выполнения демона init. Каждый экземпляр службы уникальным образом определяется FMRI-идентифи- катором (fault management resource zdentifier — идентификатор управляемого ресурса в системе управления сбоями). Например, следующие эквивалентные FMRI-иденти- фикаторы ссылаются на службу ssh. svc:/network/ssh:default network/ssh:default Служба ssh принадлежит категории network, и данный конкретный FMRI-иден- тиФикатор описывает стандартный экземпляр. В SMF определено несколько кате- горий, например application, device, network и system. Специальная категория mi lestone инкапсулирует концепцию уровней выполнения.
140 Часть I. Основы администрирования Экземпляр службы в каждый момент времени может находиться в одном из воз- можных семи состояний. Узнать состояние службы можно с помощью команды svcs. Чтобы получить полный список служб, определенных в системе, используйте команду svcs -а. Если опустить флаг -а, вы увидите только те службы, которые выполняются в данный момент. Команду svcs можно использовать и для отдельно взятой службы. Например, следующая команда проверяет состояние службы ssh. solaris$ svcs -1 svc:/network/ssh:default fmri svc:/network/ssh:default name SSH server enabled true state online. next_state none state_time Mon Jul 13 15:56:19 2009 logfile /var/svc/log/network-ssh:default.log restarter svc:/system/svc/restarter:default contract id 65 dependency dependency dependency dependency dependency dependency dependency require_all/none svc:/system/filesystem/local (online) optional_all/none svc:/system/filesystem/autofs (online) require_all/none svc:/network/loopback (online) require_all/none svc:/network/physical (online) require_all/none svc:/system/cryptosvc (online) require_all/none svc:/system/utmp (online) require_all/restart file://localhost/etc/ssh/sshd_config (online) В этой командной строке используется полный FMRI-идентификатор (в отличие от сокращенного), но поскольку существует только один экземпляр этой службы, можно было бы ограничиться более лаконичной командой svcs -1 ssh. Состояние службы может принимать одно из следующих значений: • online — запуск разрешен, экземпляр службы успешно работает; • disabled — запуск запрещен; экземпляр службы не запущен; • degraded — запуск разрешен, но работа происходит с ограниченной функцио- нальностью; • legacy run — служба работает; некоторые унаследованные (от предыдущих вер- сий системы) службы не подлежат управлению через SMF, однако их работу мож- но наблюдать стандартными для SMF средствами; это состояние возможно только для унаследованных служб; • uninitialized — в этом состоянии находятся все службы до того, как их конфи- гурация будет считана из репозитория; • maintenance — экземпляр службы аварийно завершился и не может быть запу- щен заново без вмешательства администратора; • offline — запуск разрешен, но экземпляр службы еще не запущен или нет воз- можности его запустить из-за ожидания “неудовлетворенной зависимости” или по другой причине. В дополнение к текущему состоянию службы, команда svcs -1 позволяет узнать ме- стоположение журнала регистрации службы, ее зависимости и другие важные данные. С помощью зависимостей описываются взаимосвязи (различной сложности) между службами. Это средство, по сути, заменяет систему пронумерованных сценариев запу- ска, используемую традиционным демоном init, в котором сценарий с префиксом S20 должен выполняться раньше сценария с префиксом S90.
Глава 3. Запуск и останов системы 141 Из приведенного выше примера видно, что служба SSH использует элементы локаль- ных файловых систем, сетевые интерфейсы, службы cryptosvc и utmp, а также файл sshd_config. Средство автоматического монтирования файловых систем autofs от- мечено как имеющее необязательную зависимость. Это означает, что служба SSH будет выполняться в случае, если автомонтировщик не работает (по намерению администра- тора) или если он нормально работает. Команда svcadm изменяет состояние службы. Чтобы запретить запуск сервера SSH (не пытайтесь делать это удаленно!), используйте такую команду. solaris$ sudo svcadm disable ssh В этом примере используется сокращенный FMRI-идентификатор для сервера SSH, так как он уникальный. Такой запрет является устойчивым изменением; для временного же запрещения запуска службы SSH используйте команду svcsadm -t. В системе SMF службы конфигурируются на основе XML-файлов, именуемых ма- нифестами и профилями. Манифест содержит полное описание всех свойств службы (зависимостей и инструкций для ее запуска и останова). Файлы манифестов хранятся в каталоге /var/svc/manifest. Каждый экземпляр службы имеет собственный файл манифеста. Строки exec_method в файле манифеста обычно указывают на сценарии, которые запускают или останавливают службы, т.е. во многом подобно тому, как используются сценарии в системе init.d. Например, процесс запуска для демона SSH определяется в файле /var/svc/manifest/ssh.xml следующим образом. <exec_method type=’method' name='start’ exec='/lib/svc/method/sshd start' timeout_seconds=’60’/> Сценарий /lib/svc/method/sshd, на который здесь содержится ссылка, является sh-сценарием, запускающим службу sshd. Все это подозрительно напоминает сцена- рий, который когда-то хранился в каталоге /etc/rc.d, — чем больше мы изменяем жизнь, тем больше она остается прежней. Файл профиля службы определяет, разрешено ли запускать данный экземпляр или запрещено. Профили хранятся в каталоге /var/svc/profile. Постоянные данные о конфигурации для служб в действительности хранятся в виде файла SQLite-базы данных /etc/svc/repository .db. Таким образом, вам необяза- тельно непосредственно модифицировать содержимое XML-файлов. Вместо этого вы можете управлять манифестами и профилями с помощью команды svccfg. Для управ- ления службами, находящимися под контролем демона inetd, используйте команду ^netadm. Для получения дополнительной информации о командах svccfg, inetadm и svc. conf igd обратитесь к соответствующим тап-сТрДНицам. Одной из самых интересных особенностей механизма SMF является использование так называемых “пускателей” (restarters), которые составляют часть разрекламирован- ной в Solaris технологии “прогнозируемого самовосстановления”. В результате анализа тщательно определенной системы зависимостей механизм SMF может предположитель- Но определить причину сбоя службы и при необходимости перезапустить ее. Причиной отказа службы может служить ошибка в программном обеспечении, сбой в работе оборудования, проблема с зависимым элементом или даже ошибка администратора, оозначенный в SMF процесс “пускателей”, тесно связанный с ядром, автоматически выполняет действия, необходимые для восстановления.
142 Часть I. Основы администрирования Прекрасный новый мир: загрузка с помощью механизма SMF Начальная стадия загрузки в системе Solaris 10 (или более поздней версии) подобна обычному процессу самозагрузки. Загрузка в архитектуре SPARC несколько отличает- ся от загрузки в Intel-системах, но общий принцип состоит в том, что низкоуровневая встроенная программа (PROM для SPARC, BIOS для Intel) считывает загрузочную за- пись, которая загружает ядро операционной системы. Ядро просматривает каталог /etc/system в поиске загружаемых модулей ядра, за- тем активизирует демон init, который немедленно запускает процесс svc.startd. Этот процесс является главным SMF-пускателем, который отвечает за процессы запуска в порядке следования зависимостей, определенных в репозитории конфигурации SMF. К сожалению, система уровней выполнения и init-сценарии из предыдущих вер- сий Solaris не совсем “похоронены”. Некоторые службы (например, те, которые в ре- зультатах выполнения команды svcs -а демонстрируют состояние legacy-run) по- прежнему опираются на сценарии, хранимые в каталоге /etc/rc.d. Это значит, что коллизия между SMF-службами и традиционными уровнями выполнения оставила мас- су “осколков”. Для того чтобы не “пораниться” об их острые края, следует иметь в виду следующие моменты. • Службы в состоянии legacy_run были запущены из сценария гс. • Solaris определяет восемь уровней выполнения. Подробнее см. man-страницу для демона init. • Чтобы изменить уровни выполнения, используйте команду init п, где п — но- вый уровень выполнения. Не пытайтесь использовать механизм SMF для изме- нения служб, что, по мнению разработчиков Sun, “может вызвать неожиданное поведение”. • Демон init управляется с помощью содержимого файла /etc/inittab (практи- чески как в Linux). 3.7. Перезагрузка и останов системы Традиционные UNIX- и Linux-системы были очень требовательны в отношении про- цедуры выключения. Современные системы более терпимы (особенно если речь идет о высоконадежной файловой системе), но все же лучше корректно завершать работу, если это возможно. Неправильное выключение компьютера может привести к появлению трудно обнаруживаемых, неочевидных ошибок, а иногда и к полному краху системы. Базы данных (которые не прекращают свою работу корректно) “славятся” проблемами разрушения данных и их целостности.4 Перезагрузка системы на персональном компьютере — средство решения почти всех проблем. Проблемы, возникающие в Linux, как правило, скрытые и сложные, поэтому перезагрузка дает ожидаемый результат гораздо реже, чем в других системах. Если вы модифицируете один из сценариев запуска системы или вносите в систему существенные изменения, то нужно перезагрузиться хотя бы для того, чтобы проверить, успешно ли функционирует система после вашего вмешательства. Если какая-либо про- 4 Теоретически базы данных должны быть особенно устойчивыми к такой форме разрушения, но наш опыт свидетельствует об обратном.
Глава 3. Запуск и останов системы 143 блема не проявится в течение нескольких ближайших недель, впоследствии вы вряд ли вспомните подробности последних изменений. Команда shutdown: корректный способ останова системы Команда shutdown — самый безопасный и корректный способ остановить или пере- загрузить систему либо вернуться в однопользовательский режим. Она переносит нас во времена использования систем, работающих в режиме разделения времени, поэтому такой подход порой кажется анахроничным на настольных компьютерах. К сожалению, почти все изготовители систем решили приложить “свою руку” к ар- гументам команды shutdown. Мы рассмотрим эту команду в общих чертах, а затем об- судим ее синтаксис и аргументы, используемые на каждой платформе. Можно дать команде shutdown указание делать паузу перед остановом системы. Во время ожидания команда посылает зарегистрированным пользователям через постепен- но укорачивающиеся промежутки времени сообщения, предупреждая о приближаю- щемся событии. По умолчанию в сообщениях говорится о том, что система заканчивает работу, и указывается время до момента останова. При желании администратор может добавить собственное короткое сообщение, в котором поясняется, почему система оста- навливается и сколько примерно времени придется подождать, прежде чем снова можно будет войти в систему. После выполнения команды shutdown пользователи будут ли- шены возможности входа в систему, но они будут видеть сообщение, предусмотренное администратором. С помощью команды shutdown (в большинстве ее версий) можно указать, что должна сделать система после выполнения команды: остановиться, перейти в однопользователь- ский режим или перезагрузиться. Можно также задать, должна ли после перезагрузки выполняться принудительная проверка дисков с помощью команды f sck. В современ- ных системах с объемными дисками полное выполнение команды f sck может занять много времени; и эту проверку можно пропустить. (Большинство систем автоматически пропускает эту проверку, если файловые системы были корректно демонтированы.) В табл. 3.7 приведены аргументы команды shutdown в разных системах. Таблица 3.7. Множество “ликов” команды shutdown Система Путь Linux /shin/shutdown time -r -h - -f6 Solaris /usr/shin/shutdown -gsecs -i6 -iO -iS - HP-UX /etc/shutdown secs -r -h — AIX /shin/shutdown +time -r -h -m - * R — перезагрузка, Н — останов, S — вход в однопользовательский режим, F — пропуск команды f sck. Системы Red Hat и SUSE, но не Ubuntu. Например, следующая Linux-команда напоминает пользователям о запланированной процедуре сервисного обслуживания и отключает систему в 9:30 утра. $ sudo shutdown -h 09:30 "Going down for scheduled maintenance. Expected downtime is 1 hour." Можно также задать относительное время отключения. Например, приведенная ниже команда запустит процесс выключения через 15 минут: $ sudo shutdown -h +15 "Going down for emergency disk repair."
144 Часть I. Основы администрирования Команды halt и reboot: более простой способ останова Команда halt выполняет все основные операции, необходимые для останова систе- мы. Обычно она вызывается командой shutdown -h, но может применяться и сама по себе. Команда регистрирует в журнальном файле факт останова, уничтожает несуще- ственные процессы, выполняет системный вызов sync, дожидается завершения опера- ций записи на диск, а затем прекращает работу ядра. При наличии опции -п системный вызов sync подавляется. Команда halt -п ис- пользуется после восстановления корневого раздела командой f sck, чтобы ядро не мог- ло затереть исправления старыми версиями раздела, хранящимися в кеше. Команда reboot почти идентична команде halt. Разница лишь в том, что система перезагружается, а не останавливается. Режим перезагрузки вызывается также командой shutdown -г. 3.8. Упражнения 3.1. Можно ли UNIX- или Linux-системы выключать нажатием кнопки питания на корпусе компьютера? А что скажете насчет выключения вилки компьютера из ро- зетки на стене? Поясните свой ответ. Постарайтесь определить вероятность полу- чения отрицательного ответа на поставленные вопросы с помощью Интернета. 3.2. Используйте опции командной строки загрузчика GRUB для загрузки ядра, ин- формация о котором отсутствует в файле grub. conf. 3.3. Ж Объясните концепцию уровней выполнения. Перечислите уровни выполнения, существующие в одной из ваших локальных систем, и кратко опишите каждый из них. Чем отличаются концепции уровней выполнения в Ubuntu и других дистри- бутивах Linux? 3.4. ★ Напишите сценарий, предназначенный для запуска некоего сетевого демона /usr/local/sbin/foo. Покажите, как организовать автоматический запуск сце- нария на этапе начальной загрузки системы. 3.5. ★★★ Если система находится на уровне выполнения 3 и вводится команда telinit 1, какие действия предпримет демон init? Каким будет конечный ре- зультат? 3.6. Нарисуйте схему, показывающую очередность запуска демонов в вашей си- стеме. 3.7. Опишите последовательность действий, необходимых для инсталляции на одном компьютере операционных систем Linux и Windows. Используйте програм- му GRUB.
Глава Управление доступом: сила привилегий Управление доступом к ресурсам относится к сфере, которая активно исследуется в наши дни и долгое время была одной из самых проблемных в проектировании опе- рационных систем. Для отдельных пользователей операционные системы определяют учетные записи, которые позволяют выполнять множество операций: редактирование текстовых файлов, регистрация на удаленных компьютерах, установка имени главно- го узла, инсталляция новых программ и т.д. Систему управления доступом можно рас- сматривать как черный ящик, который (на входе) принимает потенциальные действия (пары “пользователь/операция”) и выдает (на выходе) решения в зависимости от допу- стимости каждого действия. В системах UNIX и Linux не существует единого черного ящика, который реализу- ет управление доступом. В действительности здесь можно говорить о целом хранилище черных ящиков — и это хранилище “съедает” память. В данной главе мы сначала вер- немся к истокам UNIX (чтобы понять, как сложилась нынешняя ситуация с управлени- ем доступом), а затем рассмотрим современные системы управления доступом в UNIX и Linux (как в теории, так и на практике), после чего остановимся на инструментах, ко- торые помогают сделать администрирование сферы управления доступом (и особенно в части, связанной с привилегиями всемогущего суперпользователя) относительно без- болезненным. О том, как предотвратить несанкционированный доступ на уровне суперпользовате- ля, Рассказывается в главе 22. В главе 32 описываются административные аспекты этого Процесса.
146 Часть I. Основы администрирования 4.1. Традиционные методы управления доступом в системах UNIX Даже в первых и самых простых версиях UNIX никогда не было единого “центра” управления доступом. Тем не менее существовали общие правила, которые оказывали влияние на проектирование систем. • Объекты (например, файлы и процессы) имеют владельцев. Владельцы обладают обширным (но необязательно неограниченным) контролем над своими объектами. • Вы являетесь владельцами новых объектов, создаваемых вами. • Пользователь root с особыми правами, известный как суперпользователь, может действовать как владелец любого объекта в системе. • Только суперпользователь может выполнять административные операции особого значения. В системах UNIX единого черного ящика, управляющего доступом, не существует, поскольку код, который принимает решения в этой области, рассредоточен по всей си- стеме. Одни системные вызовы (например, settimeofday) ограничены пользователем root (при выполнении таких системных вызовов просто проверяется “личность” теку- щего пользователя, и, если он окажется не суперпользователем, операция отвергается). Другие системные вызовы (например, kill) реализуют различные вычисления, которые требуют как соответствия владельцу, так и обеспечения специальных условий для супер- пользователя. Наконец, файловая система реализует собственную систему управления доступом, причем эта система сложнее любой другой, реализованной в ядре. Например, только файловая система использует принцип UNIX-групп для управления доступом. Ш Подробнее о файлах устройств рассказывается в разделе 6.4. Усложнение ситуации привело к переплетению ядра и файловой системы. Например, вы управляете большинством устройств и передаете им информацию посредством фай- лов, которые представляют их в каталоге /dev. Поскольку эти файлы устройств явля- ются объектами файловой системы, они используются и в ее семантике управления до- ступом. Управление доступом в файловой системе Каждый файл в традиционной модели UNIX-подобных систем принадлежит владель- цу и группе, иногда именуемой “групповым владельцем”. Владелец файла имеет особую привилегию, недоступную другим пользователям системы: ему разрешено менять права доступа к файлу. В частности, владелец может задать права доступа так, что никто, кроме него, не сможет обращаться к файлу1. Мы еще вернемся к теме прав доступа в главе 6. Ш Подробнее о группах написано в разделе 7.1. Владельцем файла всегда является один человек, тогда как в группу владельцев могут входить несколько пользователей. По традиции информация о группах хранилась в фай- ле /etc/group, но теперь ее чаще хранят на сетевом сервере NIS или LDAP. Подробнее эти вопросы рассматриваются в главе 19. 1 В действительности права доступа можно установить такими строгими, что даже владелец файла не сможет им и воспользоваться.
Глава 4. Управление доступом: сила привилегий 147 Владелец файла должен определить, какие операции могут выполнять над файлом члены группы. Такая схема допускает совместное использование файлов членами одной группы. Например, мы применяем группу для управления доступом к файлам исходного кода веб-сайта www. admin. com Узнать идентификаторы владельцев файла можно с помощью команды Is -1 имя файла. Например: aix$ Is -1 /home/garth/todo - rw----- 1 garth staff 1258 Jun 4 18:15 /home/garth/todo Файлом владеет пользователь garth, а группа, которой он принадлежит, называется staff. Буквы и дефисы в первом столбце означают права доступа к файлу (подробнее см. раздел 6.5). CQ Подробнее о файле /etc/passwd можно прочитать в разделе 7.1, а о файле /etc/ group — в разделе 7.3. Ядро и файловая система отслеживают не текстовые имена владельцев и групп, а их идентификаторы. В самом общем случае идентификаторы пользователей (сокра- щенно UID — User ID) и соответствующие им имена хранятся в файле /etc/passwd, а идентификаторы и названия групп (GID — group ID) находятся в файле /etc/group. Текстовые эквиваленты идентификаторов UID и GID определяются исключительно для удобства пользователей. Для того чтобы команда вроде 1s могла вывести информацию о владельце файла в удобочитаемом виде, она должна просмотреть базу данных иденти- фикаторов и найти в ней нужные имена. Владение процессом Владелец может посылать процессу сигналы (описываются в разделе 5.3), а также по- нижать его приоритет. С процессами связано несколько идентификаторов: реальный, текущий и сохраненный идентификатор пользователя; реальный, текущий и сохранен- ный идентификатор группы, а в системе Linux — “идентификатор пользователя файло- вой системы”, который используется только для определения прав доступа к файлам. Вообще говоря, реальные номера применяются для учета использования системных ре- сурсов, а текущие — для указания прав доступа. В большинстве случаев реальные и те- кущие идентификаторы совпадают. Сохраненные идентификаторы не оказывают никакого непосредственного влияния. Они позволяют программам “приберегать” неактивные идентификаторы для последую- щего использования, тем самым способствуя расчетливому применению расширенных полномочий. Вообще говоря, идентификатор пользователя файловой системы — это особенность реализации сетевой файловой системы (Network File System — NFS), и обычно он совпадает с текущим идентификатором пользователя. Ш Подробнее о системе NFS написано в разделе 18.1. Учетная запись суперпользователя Учетная запись root в UNIX принадлежит “всесильному” пользователю-админи- стратору, известному как суперпользователь, хотя его настоящее имя — “root”. Определяющей характеристикой учетной записи суперпользователя является значе- ние UID, равное нулю. Ничто не запрещает менять имя этой учетной записи или созда-
148 Часть I. Основы администрирования вать другую запись с нулевым идентификатором, но такие действия ни к чему хороше- му не приведут. Их следствием будет возникновение новых брешей в системе защиты, а также растерянность и гнев других администраторов, которым придется разбираться с особенностями конфигурирования такой системы. Традиционная система UNIX позволяет суперпользователю (т.е. всякому процессу, текущий идентификатор пользователя которого равен нулю) выполнять над файлом или процессом любую допустимую операцию2. Вот примеры операций, доступных лишь суперпользователю: • изменение корневого каталога процесса с помощью команды chroot; • создание файлов устройств; • установка системных часов; • увеличение лимитов использования ресурсов и повышение приоритетов процессов; • задание сетевого имени компьютера; • конфигурирование сетевых интерфейсов; • открытие привилегированных сетевых портов (номера которых меньше 1024); • останов системы. Процессы суперпользователя обладают способностью изменять свои идентифи- каторы. Один из таких процессов — программа login и ее графические эквиваленты, которые отображают на экране приглашение ввести пароль при входе в систему. Если введенные пароль и имя пользователя правильны, программа заменяет свои иденти- фикаторы соответствующими идентификаторами указанного пользователя и запускает интерпретатор команд. После того как процесс суперпользователя, сменив владельца, станет обычным пользовательским процессом, восстановить свое предыдущее привиле- гированное состояние он уже не сможет. Использование битов “setuid" и "setgid” Традиционная система управления доступом в UNIX дополнена системой смены полномочий, которая реализуется ядром в сотрудничестве с файловой системой. Более детально эта система описана в разделе 6.5, но, если кратко, то эта система позволяет выполнять специально подготовленные файлы с использованием привилегий более вы- сокого уровня (обычно это привилегии суперпользователя). Этот механизм разрешает разработчикам и администраторам создавать условия для непривилегированных пользо- вателей, при которых они могут выполнять привилегированные операции. Дело в том, что существует два специальных бита, устанавливаемых в маске прав доступа к файлу: “setuid” (Set User ID — бит смены идентификатора пользователя) и “setgid” (Set Group ID — бит смены идентификатора группы). Если запускается испол- няемый файл, у которого установлен один из этих битов, то текущими идентификато- рами создаваемого процесса становятся идентификаторы владельца файла, а не иден- тификаторы пользователя, запустившего программу. Смена полномочий действительна только на время работы программы. Например, пользователи должны иметь возможность изменять свои пароли. Но по- скольку пароли хранятся в защищенном файле /etc/shadow, пользователям нужно использовать команду passwd с полномочиями setuid, чтобы “усилить” свои права 2 Следует подчеркнуть важность слова “допустимую”. Некоторые операции (например, запуск файла, для которого не установлен бит выполнения) запрещены даже суперпользователю.
Глава 4. Управление доступом: сила привилегий 149 доступа. Команда passwd проверяет, кто ее выполняет, и, в зависимости от результата, настраивает свое поведение соответствующим образом, поэтому обычные пользователи могут менять только собственные пароли, а суперпользователь — любые. (Это, между прочим, еще один пример “специального случая” в UNIX-системе управления досту- пом — правила “встроены” в код команды passwd.) 4.2. Современная организация управления доступом В предыдущем разделе были рассмотрены практически все основные принципы по- строения традиционной UNIX-модели. Несмотря на то что систему управления досту- пом можно описать буквально двумя страницами, она выдержала проверку временем благодаря своей простоте, предсказуемости и способности удовлетворять большинство требований, предъявляемых к управлению доступом на среднестатистическом узле. Все UNIX- и Linux-версии продолжают поддерживать эту модель, которая широко исполь- зуется в наши дни. И если не считать разделы нашей книги, в которых уделяется вни- мание некоторым специальным альтернативным вариантам, мы предполагаем, что вы используете именно традиционную модель. Тем не менее мы не можем не упомянуть очевидные недостатки этой модели. • С точки зрения безопасности, суперпользователь представляет единственную учет- ную запись, которая может являться причиной потенциального отказа системы. Если суперпользователь дискредитирует себя, может нарушиться целостность всей системы. Взломщик в этом случае может нанести системе колоссальный вред. • Единственный способ разделить специальные привилегии суперпользователя со- стоит в написании setuid-программ. К сожалению, как показывает непрекра- щающийся интернет-поток обновлений средств защиты систем, довольно трудно написать по-настоящему безопасное программное обеспечение. К тому же, вам не следует писать программы, назначение которых можно было бы выразить такими словами: “Хотелось бы, чтобы эти три пользователя могли выполнять задачи ре- зервирования на файловом сервере”. • Модель безопасности не является достаточно прочной для использования в сети. Ни один компьютер, к которому непривилегированный пользователь имеет фи- зический доступ, не может гарантировать, что он точно представляет принадлеж- ность выполняемых процессов. Кто может утверждать, что такой-то пользователь не переформатировал диск и не инсталлировал собственную копию Windows или Linux со своими UID? • Во многих средах с высокими требованиями к защите системы действуют согла- шения, которые просто не могут быть реализованы с использованием традицион- ных UNIX-систем безопасности. Например, согласно государственным стандартам США компьютерные системы должны запрещать привилегированным пользовате- лям (например, тем, кто относится к высшей категории допуска) публиковать до- кументы особой важности на более низком уровне безопасности. Традиционная же организация безопасности в UNIX зависит от доброй воли и профессиональ- ных навыков отдельных пользователей. • Поскольку многие правила, связанные с управлением доступа, встроены в код от- дельных команд и демонов, невозможно переопределить поведение системы, не модифицируя исходный код и не перекомпилируя программы. Но это реально не практикуется.
150 Часть I. Основы администрирования • Для отслеживания действий пользователей предусмотрена минимальная поддерж- ка. Вы можете легко узнать, к каким группам принадлежит тот или иной пользо- ватель, но вы не в состоянии точно определить, какие действия разрешены поль- зователю членством в этих группах. Из-за этих недостатков UNIX- и Linux-системы многократно претерпевали различ- ные изменения. Их цель — усовершенствовать различные аспекты подсистемы управ- ления доступом и сделать UNIX-системы более пригодными для сайтов с высокими требованиями к безопасности. Одни корректирующие технологии, такие как РАМ (под- робнее чуть ниже), в настоящее время имеют практически универсальную подцержку. Другие системные расширения можно назвать уникальными. Самые популярные из них рассмотрим в следующем разделе. Управление доступом на основе ролей Управление доступом на основе ролей (role-Z>ased access control — RBAC) — теорети- ческая модель, формализованная в 1992 г. Дэвидом Ферраильо (David Ferraiolo) и Риком Куном (Rick Kuhn). В основе этой модели лежит идея добавления уровня косвенности в механизм управления доступом. Вместо того чтобы назначать полномочия непосред- ственно пользователям, они назначаются промежуточным конструкциям, именуемым “ролями”, а роли, в свою очередь, назначаются пользователям. Для того чтобы принять решение по управлению доступом, специальная библиотека перечисляет роли текущего пользователя и узнает, имеет ли хотя бы одна из этих ролей соответствующие полномочия. Между ролями и UNIX-группами можно заметить некоторое сходство, и нет единого мнения насчет того, отличаются ли эти конструкции по сути. На практике роли оказы- ваются более полезными, чем группы, поскольку системы, в которых они реализованы, разрешают использовать их вне контекста файловой системы. Роли могут также иметь иерархические взаимоотношения друг с другом, что значительно упрощает администри- рование. Например, вы могли бы определить роль “старшего администратора”, который имеет все полномочия “администратора”, а также дополнительные полномочия X, Y и Z. Модель RBAC позволяет на практике реализовать управление большими коллекция- ми возможных полномочий. Большая часть усилий тратится на иерархическое опреде- ление роли, но это делается один раз за проект. Повседневное же администрирование пользователей в этом случае упрощается. Следовательно, системы, которые поддержи- вают модель RBAC, обычно пользуются ее преимуществами для “расщепления” могу- щества суперпользователя на множество различных фрагментов, которые могут назна- чаться пользователям по отдельности. В системах Solaris для реализации ролей используются группы (/etc/group), SOiariS авторизации (/etc/security/auth_attr), профили (/etc/security/prof_ attr), а также связывания между пользователями, авторизациями и профиля- ми (/etc/user_attr). Авторизации имеют такие имена, как Solaris. admin. dis king г, Solaris. admin .pa tchmgr и Solaris .admin, printer. Многие авторизации имеют также специальный уровень структуризации . read или .write. В файле auth_attr определено 158 авторизаций. Для управления ролями в Solaris предусмотрены такие команды, как roleadd, rolemod и гoledel. Со времени выхода сборки 99 OpenSolaris в мае 2008 года Solaris-система RBAC вела себя достаточно устойчиво и позволяла работать без учетной записи root.
Глава 4. Управление доступом: сила привилегий 151 133 В среде HP-UX для определения “мелкоструктурированных” root-привилегий также используются авторизации, которые затем назначаются ролям, связан- ным с отдельными пользователями и группами. Авторизациям даются имена вроде hpux. admin.process. kill, hpux. admin. network. config и hpux. admin.device.install. В файле /etc/rbac/auths определено 137 авто- ризаций. Для управления авторизациями используются команды roleadm, authadm, cmdprivadm, privrun и privedit. В системах AIX используются роли с такими именами: DomainAdmin, BackupRe store, AccountAdmin, Sys Con fig и SecPolicy. Авторизации здесь имеют примерно такой же уровень структуризации, как в Solaris или HP-UX. Вот, например, как звучат в среде AIX имена авторизаций: aix.device, aix. proc, aix. fs .manage.export и aix. system, config. cron. В AIX-инстру- менте SMIT (“правая рука” системного администратора) роли связываются с экранами результатов выполнения команд. Пользователи здесь могут “играть” до восьми ролей сразу. Примеры основанных на ролях AIX-команд: mkrole, chrole, rmrole, rolelist и swrole. SELinux: Linux-системы с улучшенной безопасностью Д Операционная система SELinux (как проект) был разработан Агентством на- циональной безопасности США (АНБ), но с конца 2000 года был передан раз- работчикам открытого кода. Система SELinux включена в состав ядра Linux (с версии 2.6) и поэтому в настоящее время доступна в большинстве дистри- бутивов (но часто в не совсем дееспособном состоянии). SELinux — это реализация системы принудительного управления доступом доступа (mandatory access control — МАС), в которой все привилегии назначаются администра- торами. В среде МАС пользователи не могут делегировать свои права и не могут устанав- ливать параметры контроля доступа на объекты, которыми они (пользователи) владеют. И поэтому такая операционная система подходит больше для узлов со специальными требованиями3. Систему SELinux можно также использовать для контроля доступа на основе ролей, хотя это не главная цель системы. Подробнее см. раздел 22.9. Возможности POSIX (Linux) Д Системы Linux — даже те, которые не используют SELinux-расширения — те- оретически позволяют распределять привилегии учетной записи суперпоИзй- вателя по “возможностям” в соответствии со стандартом POSIX. Кроме того, спецификации характеристик можно назначить исполняемым программам, а затем программы при выполнении будут запрашивать заданные характери- стики. По сути, это — форма выполнения setuid-команд с нижним уровнем риска. 3 Вот отзыв одного из технических рецензентов: “Это была не самоцель. В действительности средние узлы, на которых выполняется базовая служба DNS/web/email, лучше всего работают именно в среде SELinux. Если же вы решаете какие-то неординарные задачи, все может закон- читься очень печально, и вам придется отключить эту систему. В настоящее время SELinux ведет себя гораздо лучше. Но я все же ее отключаю...”.
152 Часть I. Основы администрирования По различным причинам, в том числе из-за проблем, присущих текущей реализации, эта функция оказалась не столь полезной или ценной для системных администраторов, как ожидалось вначале. Подробнее эти возможности рассмотрены в разделе 20.14. Подключаемые модули аутентификации Подключаемые модули аутентификации (Pluggable Authentication Modules — РАМ) образуют технологию аутентификации, а не технологию управления доступом. Другими словами, технология РАМ призвана искать ответ не на вопрос: “Имеет ли право поль- зователь X выполнить операцию Y?”, а на вопрос: “Как узнать, что это действительно пользователь X?” Технология РАМ — это важное звено в цепи управления доступом в большинстве систем. Раньше пароли пользователей проверялись с помощью содержимого файла /etc/ shadow (или его сетевого эквивалента) в момент регистрации, чтобы можно было уста- новить соответствующий UID-идентификатор для командной оболочки пользователя или оконной системы. В этом случае программы, выполняемые пользователем, вынуж- дены были принимать указанный UID на веру. В современном мире сетей, криптогра- фии и устройств биометрической идентификации нужна более гибкая и открытая систе- ма. Поэтому и появилась технология РАМ. Технология РАМ — это набор разделяемых библиотек, которые позволяют интегри- ровать различные низкоуровневые методы аутентификации. Администраторы указывают те методы аутентификации, которые (с их точки зрения) должна использовать система в соответствующих контекстах. Программы, которые собираются аутентифицировать пользователя, просто вызывают систему РАМ, а не реализуют собственные формы ау- тентификации. Система РАМ, в свою очередь, вызывает специальную библиотеку аутен- тификации, заданную системным администратором. Подробнее о системе РАМ можно прочитать в разделе 22.4. Сетевой протокол криптографической аутентификации Kerberos Подобно РАМ, протокол Kerberos призван решать проблемы аутентификации, а не управления доступом. (Он назван в честь трехголового пса, который защищал вход в цар- ство Аида, — Цербера, или Кербера.) Но если РАМ можно назвать структурной оболоч- кой аутентификации, то Kerberos — это конкретный метод аутентификации. Реализация Kerberos использует проверенный (сторонний) сервер для выполнения задач аутентификации в масштабах всей сети. Вместо самоаутентификации на своем компьютере вы предоставляете свои мандаты (билеты) Kerberos-службе, а она выдает вам криптографические мандаты, которые вы можете презентовать другим службам как под- тверждение вашей идентичности. Больше о протоколе Kerberos написано в разделе 22.10. Списки управления доступом Управление доступом к файловой системе — важнейшая часть систем UNIX и Linux, и поэтому ее совершенствование составляет первоочередную цель разработчиков этих систем. Особое внимание было уделено поддержке списков доступа к файлам и ката- логам (access control Zists — ACL) как обобщению традиционной модели привилегий пользователя/группы/“всех остальных”, устанавливаемых сразу для нескольких пользо- вателей и групп. Списки ACL являются частью реализации файловой системы, поэтому
Глава 4. Управление доступом: сила привилегий 153 их поддержку в явном виде должна обеспечивать используемая вами файловая система. К счастью, в настоящее время практически все файловые системы UNIX и Linux под- держивают ACL-списки в той или иной форме. Ш Подробнее об NFS написано в главе 18. Поддержка ACL-списков в общем случае реализуется в двух формах: в виде проекта стандарта POSIX, который (хоть и без формального подтверждения) получил широкое признание, и системы, стандартизированной протоколом NFSv4, который базируется на ACL-списках Microsoft Windows. Оба стандарта ACL более детально описаны в раз- деле 6.6. 4.3. Управление доступом в реальном мире Несмотря на наличие описанных выше превосходных возможностей операционных систем, в большинстве узлов для задач системного администрирования по-прежнему используется учетная запись суперпользователя. Многие жалобы на традиционную си- стему имеют реальную почву, но и альтернативным вариантам присущи серьезные про- блемы. Поэтому особое значение приобретают такие дополнительные программные ин- струменты, как sudo (подробнее чуть ниже), которые в некоторой степени позволяют преодолеть разрыв между критериями простоты использования и безопасности. Часто для принятия решений в особых обстоятельствах используются возможности POSIX или средства управления доступом на основе ролей (например, когда необхо- димо разрешить переустановку принтера или демона каждому, кто работает в конкрет- ном отделе), в то время как при решении каждодневных задач ваша административная команда продолжает полагаться на утилиту sudo и учетную запись суперпользователя. В некоторых случаях (например, если это оговорено в контракте) для узлов необходимо использовать такие мощные и “ударопрочные” системы, как SELinux. Поскольку доступ с правами суперпользователя является обязательным условием системного администрирования и центральной точкой для безопасности систем, очень важно правильно пользоваться правами и обязанностями учетной записи root. Пароль суперпользователя Если вы используете процедуры и инструменты, описанные в этой главе, вероят- но, будете удивлены, как в действительности используется пароль суперпользователя. В большинстве случаев администраторам не нужно знать его вообще. Тем не менее для учетной записи root пароль необходим. Он должен быть секрет- ным и в то же время запоминающимся, чтобы вы могли им воспользоваться (т.е. не забыть) даже через большие интервалы времени. Для “запоминания” паролей можно использовать какой-нибудь хранитель паролей или систему депонирования паролей (см. ниже в этой главе). Ш Подробнее о взломе паролей читайте в разделе 22.8. Самой важной характеристикой хорошего пароля является его длина. Пароль поль- зователя root должен состоять как минимум из восьми символов, так как даже семи- символьные пароли взламываются достаточно легко. В системах, где применяются па- роли DES (Data Encryption Standard — стандарт шифрования данных), задавать более Длинный пароль не имеет смысла, потому что обрабатываются только первые восемь
154 Часть I. Основы администрирования символов. В начале главы 7 рассказывается о том, как разрешить использование систем шифрования MD5 или Blowfish, которые позволяют паролям иметь большую длину. Теоретически наиболее безопасный пароль состоит из случайного набора букв, зна- ков препинания и цифр. Такой пароль, однако, тяжело запомнить и, как правило, неу- добно вводить, поэтому, если системный администратор записывает пароль на бумажке или вводит его слишком медленно, об оптимальном уровне безопасности системы гово- рить не приходится. Сегодня наиболее широкое распространение получил подход, заключающийся в вы- боре пароля по принципу “шокирующего абсурда”. Этот принцип был определен Грейди Уордом (Grady Ward) в ранней версии списка часто задаваемых вопросов (FAQ), посвя- щенного выбору идентификационной фразы по системе PGP (Pretty Good Privacy). Принцип “шокирующего абсурда”заключается в составлении короткой фразы (или пред- ложения), которая лишена смысла и в то же время вызывает шок у пользователя в дан- ной социальной среде. То есть она должна содержать совершенно неприличные или ра- систские высказывания либо состоять из абсолютно бессвязных выражений. Применять такой подход не предосудительно, поскольку подразумевается, что пароль никогда не станет известен людям, чьи чувства могут быть им оскорблены). Маловероятно, чтобы такой пароль был повторен кем-то еще, ведь он уникален по своей сути. При этом он легко запоминается, потому что имеет яркую эмоциональную окра- ску. Сдержанный пример «шокирующего абсурда» выглядит так: «Моллюски отгрызли мои гарцующие гениталии». Любой читатель без труда придумает гораздо более шоки- рующие фразы. В системах, которые поддерживают пароли произвольной длины, вы можете исполь- зовать в качестве пароля всю абсурдную фразу. Можно также преобразовать эту фразу в пароль, записав только вторые буквы каждого слова или применив какое-нибудь другое легко запоминающееся преобразование. Безопасность пароля значительно возрастет, если включить в него цифры, знаки препинания и прописные буквы. Если ваш узел включает сотни компьютеров, то нужно ли вам готовить сотни root- паролей? Это зависит от среды и толерантности к риску, но, скорее всего, нет. Практика показывает, что для компьютеров-клонов (например, настольных АРМ) вполне подой- дет один и тот же root-пароль. При этом серверам следует подбирать уникальные паро- ли. Все важные части сети и инфраструктура, обеспечивающая маршрутизацию, должны быть защищены по отдельности. Потрудитесь точно записать, какие компьютеры совместно используют root-пароль. Важно также иметь структурированный способ изменения root-паролей для таких ком- пьютеров. Небрежность в этом вопросе напрямую связана с большим риском наруше- ния безопасности и головной болью администраторов. Пароль суперпользователя следует менять в следующих случаях: • минимум каждые три месяца; • всякий раз, когда кто-либо, знающий пароль, увольняется из организации; • когда, по вашему мнению, безопасности системы что-то угрожает. Часто говорят, что пароли никогда не следует записывать, однако эту мысль следует выразить точнее: пароли никогда не должны быть доступными для случайных людей. 4 Данный список FAQ был написан для отдельных пользователей системы PGP. В контексте системного администрирования вам следует учесть потенциальные возможности для нападения. Как бы восприняли ваш вариант “шокирующего абсурда” присяжные, которым, не дай бог, при- дется рассматривать ваше дело о сексуальных домогательствах?
Глава 4. Управление доступом: сила привилегий 155 Пароли суперпользователя и другие важные пароли лучше записывать в зашифрованном виде, чтобы администраторы могли воспользоваться ими при крайней необходимости. (Подробнее чуть ниже.) регистрация под именем root Поскольку суперпользователь является таким же членом системы, как и остальные пользователи, можно войти в систему непосредственно под именем root. Однако ока- зывается, что это довольно неудачное решение. Во-первых, не будет сделано никаких записей о том, какие операции выполнял суперпользователь. Согласитесь, не очень приятно обнаружить, что вчера ночью в 3:00 вы что-то поменяли, но никак не можете вспомнить, что именно. Еще хуже, если такой доступ был несанкционированным и не- обходимо выяснить, какой ущерб системе нанес нарушитель. Во-вторых, сценарий реги- страции суперпользователя не предполагает сбора дополнительной идентифицирующей информации. Когда под именем root в систему могут входить несколько пользователей, не существует способа определить, кто именно и когда это делал. Вследствие упомянутых причин в большинстве систем регистрация под именем root может быть запрещена на терминалах, в оконных системах и по сети, т.е. везде, кроме системной консоли5. Мы рекомендуем следовать этой схеме. О том, как реализовать эту политику в конкретной системе, читайте в разделе 22.4. Команда su: замена идентификатора пользователя Лучше получать доступ к учетной записи root с помощью команды su. Будучи вы- званной без аргументов, она выдает приглашение на ввод пароля суперпользователя, а затем запускает интерпретатор команд с правами пользователя root. Интерпретатор будет выполняться в привилегированном режиме, пока не завершит работу (при нажа- тии комбинации клавиш <Ctrl+D> или по команде exit). Команда su не фиксирует действия, производимые в среде интерпретатора, но добавляет запись в журнальный файл с указанием, кто и когда вошел в систему под именем суперпользователя. Команда su способна также подставлять вместо имени root имена других пользова- телей. Иногда единственный способ помочь пользователю в решении проблемы — вой- ти с помощью команды su в его среду и разобраться в происходящем, так сказать, “на месте”. Зная чей-либо пароль, можно непосредственно зарегистрироваться в системе под его именем, введя команду su имя_пользователя. В ответ будет выдан запрос на ввод па- роля. При использовании в качестве ключа команды su дефиса (-) интерпретатор пере- йдет в режим регистрации. Точная реализация этого режима зависит от конкретного ин- терпретатора команд, но обычно в этом режиме меняются количество и имена файлов запуска, считываемых интерпретатором. Например, в режиме регистрации интерпрета- тор bash считывает файл ~/ .bash_profile, а вне этого режима — файл ~/ .bashrc. При диагностике проблем конкретного пользователя режим регистрации позволяет мак- симально точно воспроизвести среду, в которой он работал. В одних системах пароль root позволяет регистрироваться с помощью команд su или login под любым именем. В других нужно сначала стать суперпользователем, вос- 5 Система Ubuntu Linux пошла еще дальше. По умолчанию система не содержит никакого дей- ствующего пароля для учетной записи root, и в ней необходимо использовать команду sudo, под- робно описанную в последующих абзацах этого раздела.
156 Часть I. Основы администрирования пользовавшись в явном виде командой su, а затем с помощью этой же команды перейти в другую учетную запись. В таком случае вводить пароль не потребуется. Рекомендуем взять за правило при вводе команды указывать полное имя, например /bin/su или /usr/bin/su, а не просто su. Это послужит определенной защитой от тех программ с именем su, которые преднамеренно были прописаны в переменной среды path злоумышленником, намеревавшимся собрать хороший “урожай” паролей6. В некоторых системах, чтобы использовать команду su, необходимо быть членом группы wheel. Команду su в значительной степени может заменить утилита sudo (см. следующий раздел), саму же команду su лучше всего оставить для крайних (аварийных) случаев. Утилита sudo: ограниченный вариант команды su Без организации управления доступом на основе ролей (RBAC) или такой системы, как SELinux, трудно предоставить кому-то право выполнять конкретную администра- тивную операцию (например, создавать резервные копии), не предоставив возможность свободно работать в системе. Если же учетная запись root доступна группе администра- торов, то вы и понятия не будете иметь о том, кто ею пользуется и что он при этом делает. Чаще всего для получения прав суперпользователя применяется утилита sudo. Она работает во всех рассматриваемых нами системах, а ее исходный код можно получить на веб-сайте sudo.ws. В системе Solaris предусмотрена команда pfexec, предоставляющая возмож- SOiariS ности, подобные возможностям программы sudo, которая реализована на базе собственной системы RBAC. Утилита sudo в качестве аргумента принимает командную строку, которая подлежит выполнению от имени root-пользователя (или другого уполномоченного пользовате- ля). Утилита обращается к файлу /etc/sudoers, где содержится список пользователей, имеющих разрешение на ее выполнение, и перечень команд, которые они могут вводить на конкретном компьютере. Если запрашиваемая команда разрешена, утилита sudo приглашает пользователя ввести его собственный пароль и выполняет команду от имени суперпользователя. Далее утилита sudo позволяет, не вводя пароль, выполнять другие команды, но толь- ко до тех пор, пока не наступит пятиминутный период бездействия (его продолжитель- ность можно менять). Такая мера служит защитой от тех привилегированных пользова- телей, которые оставляют свои терминалы без присмотра. Ш Подробнее о syslog читайте в главе 11. Утилита sudo ведет журнал, где регистрируются выполненные команды, компьюте- ры, на которых они выполнялись, и вызвавшие их пользователи, а также каталоги, из которых запускались команды, и время их вызова. Эта информация может направляться в системный журнальный файл syslog или сохраняться в любом другом файле по усмо- трению пользователя. Мы рекомендуем направлять ее на защищенный центральный компьютер. 6 По аналогичной причине настоятельно рекомендуем не включать запись “. ” (текущий ката- лог) в переменную path интерпретатора команд. Несмотря на очевидное удобство, подобная кон- фигурация приводит к тому, что можно непреднамеренно запустить “специальную” версию какой- нибудь системной команды, которую злоумышленник оставил в качестве приманки. Пользователю root следует быть бдительным вдвойне.
Глава 4. Управление доступом: сила привилегий 157 Строка журнального файла, содержащая данные о пользователе randy, который вы- полнил команду sudo /bin/cat etc/sudoers, может выглядеть следующим образом. Dec 7 10:57:19 tigger sudo: randy: TTY=ttypO ; PWD=/tigger/users/randy; USER=root ; COMMAND=/bin/cat /etc/sudoers Существует единая версия файла /etc/sudoers, которая используется на всех ком- пьютерах. Сам файл выглядит примерно так. # Define aliases for machines in CS & Physics departments Host_Alias CS = tigger, anchor, piper, moet, sigi Host_Alias PHYSICS = eprince, pprince, icarus # Define collections of commands Cmnd_Alias DUMP = /sbin/dump, /sbin/restore Cmnd_Alias PRINTING - /usr/sbin/lpc, /usr/bin/lprm Cmnd_Alias SHELLS = /bin/sh, /bin/tcsh, /bin/bash, /bin/ksh, /bin/bsh # Permissions mark, ed PHYSICS = ALL herb CS = /usr/sbin/tcpdump : PHYSICS = (operator) DUMP lynda ALL = (ALL) ALL, ’SHELLS %wheel ALL, ! PHYSICS = NOPASSWD: PRINTING Первые пять строк (не считая комментариев) определяют набор компьютеров и ко- манд, на которые имеются ссылки в спецификациях прав доступа. Списки элементов можно включать в спецификации в полном виде, но работать с псевдонимами проще, к тому же они делают файл /etc/sudoers понятнее и в него легче вносить изменения. Разрешается также создавать псевдонимы для различных групп пользователей. В каждую спецификацию прав доступа включается информация о следующем: • пользователях, к которым относится запись; • компьютерах, на которых пользователям разрешено выполнять соответствующие действия; • командах, которые могут выполняться указанными пользователями; • пользователях, от имени которых могут выполняться команды. Первая строка спецификаций применяется к пользователям mark и ed, которые ре- гистрируются в системе на компьютерах группы PHYSICS (eprince, pprince и icarus). Встроенный псевдоним ALL разрешает им вводить любые команды. Поскольку допол- нительный список пользователей в скобках не указан, утилита sudo будет выполнять команды только от имени суперпользователя. Пользователь herb может запускать утилиту tcpdump на компьютерах группы CS, а также выполнять команды резервного копирования на компьютерах группы PHYSICS. Обратите внимание, однако, что вторая группа команд получит привилегии не пользо- вателя root, а пользователя operator. Реальная команда, которую пришлось бы ввести пользователю herb, выглядит примерно так. ubuntu$ sudo -u operator /usr/sbin/dump Ou /dev/sdal Пользователь lynda имеет право выполнять команды от имени любого пользователя на любом компьютере, но он не может запускать большинство распространенных ин- терпретаторов команд. Означает ли это, что он не может получить доступ к интерпрета- тору? Конечно, нет. aix$ ср -р /bin/sh /txnp/sh aix$ sudo /txnp/sh
158 Часть I. Основы администрирования Вообще говоря, попытка разрешить “все команды, кроме...” обречена на провал, по крайней мере, с технической точки зрения. Тем не менее имеет смысл использовать по- добную форму спецификации, так как это послужит хотя бы напоминанием о том, что вызывать интерпретатор команд в режиме суперпользователя не рекомендуется. В последней строке пользователям группы wheel разрешается выполнять команды печати 1рс и Iprm от имени суперпользователя на всех компьютерах, за исключением eprince, pprince и icarus. Более того, от пользователей не требуется вводить пароль. Обратите внимание на то, что команды в файле /etc/sudoers приводятся с указа- нием полного имени, чтобы пользователи не могли выполнять свои собственные про- граммы и сценарии от имени суперпользователя. Разрешается также указывать допу- стимые аргументы команд (в приведенных выше примерах это не показано). В целом возможности файла sudoers очень велики, а рассмотренная конфигурация иллюстри- рует лишь основные из них. • В системах AIX полезно включать в раздел Defaults файла sudoers следую- щую строку. Defaults env_keep - "ODMDIR" Наличие этой строки не позволит утилите sudo удалить переменную среды ODMDIR, которая указывает многим административным командам на специальную базу объек- тов ODM (Object Data Manager), в которой хранится значительная часть параметров ОС AIX, например список поддерживаемых и сконфигурированных устройств, информация о драйверах и пр. Для модификации файла /etc/sudoers предназначена специальная команда visudo, которая проверяет, не редактируется ли файл кем-то посторонним, затем открывает его в редакторе, а перед инсталляцией файла выполняет синтаксический контроль. Послед- ний этап особенно важен, поскольку ошибка в файле /etc/sudoers может не позво- лить повторно вызвать утилиту sudo для исправления файла. Использование утилиты sudo имеет следующие преимущества. • Благодаря регистрации команд значительно повышается степень административ- ного контроля над системой • Операторы могут выполнять специальные задачи, не имея неограниченных при- вилегий • Настоящий пароль суперпользователя могут знать всего один-два человека7 • Вызывать утилиту sudo быстрее, чем выполнять команду su или входить в систе- му под именем root • Пользователя можно лишить привилегий, не меняя пароль суперпользователя • Ведется список всех пользователей с правами пользователя root • Меньше вероятность того, что интерпретатор команд, запущенный суперпользо- вателем, будет оставлен без присмотра • Управлять доступом ко всей сети можно с помощью одного файла Ш Дополнительную информацию о взломе паролей можно найти в разделе 22.8. Утилита sudo имеет и недостатки. Самый большой из них заключается в том, что любая брешь в системе защиты того или иного привилегированного пользователя экви- 7 Или даже никто, если вы используете один из проверенных вариантов системы хранения па- ролей Password Vault.
Глава 4. Управление доступом: сила привилегий 159 валентна нарушению безопасности самой учетной записи root. Противостоять этому нелегко. Можно лишь предупредить тех, кто имеет право выполнять утилиту sudo, о не- обходимости максимально защищать свои учетные записи. Можно также регулярно за- пускать какой-нибудь программный взломщик паролей, проверяя “стойкость” паролей привилегированных пользователей. Другой недостаток — возможность обмануть утилиту sudo с помощью таких уловок, как временный выход в интерпретатор команд из разрешенной программы либо выпол- нение команд sudo sh или sudo su, если они допустимы. Во многих версиях систем UNIX утилита sudo (как способ разделения привилегий суперпользователя) является лучшим инструментом для встроенных систем управления доступом на основе ролей (RBAC). И вот почему. • Вы можете точно определить, как именно будут разделены привилегии суперполь- зователя. Ваш вариант может отличаться в ту или иную сторону от предлагаемого встроенной системой RBAC. • Простота конфигурации — общепризнанный факт (в основном, это касается уста- новки, обслуживания и понимания происходящего). • Псевдонимы утилиты sudo для групп компьютеров, пользователей и команд функ- ционально подобны ролям в системе RBAC. • Утилита sudo выполняется во всех системах UNIX и Linux. Вам не нужно беспо- коиться об использовании различных систем RBAC на разных платформах. • Вы можете совместно использовать единственный на весь узел файл конфигурации. • Вы получаете бесплатную возможность высококачественного процесса регистра- ции в системе. Основной недостаток sudo-ориентированного управления доступом состоит в том, что система остается уязвимой в случае, если будет нарушена защита учетной записи суперпользователя. Хранилища паролей и их депонирование В пятистах милях на север от материковой части Норвегии, на одном из гористых островов архипелага Шпицберген, был вырыт огромный “погреб” — всемирный банк- хранилище посадочного материала всех существующих в мире сельскохозяйственных растений на случай планетарной катастрофы. Системным администраторам не нужно такое большое и холодное (на Шпицбергене вечная мерзлота как никак) спецхранилище для паролей, но какое-то хранилище им все же нужно иметь. Хранилище паролей может быть реализовано в виде некоторого программного (или программно-аппаратного) комплекса, который сохраняет пароли для конкретной орга- низации более безопасным способом, чем тот, что предлагает Windows (например, с по- мощью флажка “Запомнить ваш пароль?”). Некоторые разработки сделали хранилище паролей почти необходимостью. • Пароли теперь нужны не только для входа в системы компьютеров, но и для до- ступа к определенным веб-страницам, для задания конфигурации сетевых марш- рутизаторов и брандмауэров, а также для администрирования удаленных служб • Возросла необходимость для сильных (т.е. “не очень запоминающихся”) паролей, ведь слабые пароли легко взламываются
160 Часть I. Основы администрирования • Существуют правила, которые требуют доступа к определенным данным, отыски- ваемым для одного-единственного пользователя, — без применения таких “об- щих” регистрационных имен, как root Системы управления паролями возникли после того, как в Сенате США был заре- гистрирован законопроект “Акт о кибербезопасности 2009” (Cybersecurity Act of 2009), который предлагает значительно расширить полномочия федеральных властей в сфере безопасности компьютерных сетей. Этот законопроект (в случае его принятия) может существенно повлиять на структуру и саму суть современного Интернета, поскольку ав- торы законопроекта предлагают решать вопросы идентифицируемости и безопасности на государственном уровне с учетом особенностей различных производственных секто- ров. В некоторых случаях этот законопроект требует двухфакторной аутентификации, например пароль или парольная фраза плюс обмен сообщениями “вызов/ответ” (для проверки правильности реакции пользователя на непредсказуемый запрос системы). Хранилища паролей — это большое подспорье для компаний, которые должны безопас- но и прозрачно управлять паролями не только собственных компьютеров, но и компью- теров своих клиентов. В настоящее время доступно несколько программ для хранения паролей. Среди них программа KeePass — бесплатный, легкий и удобный в работе менеджер паролей с от- крытым исходным кодом, предназначенный для отдельных пользователей. Программа KeePass хранит пароли локально, предоставляет категорический (все или ничего) до- ступ к базе данных паролей, не выполняя при этом входа в систему. Продукты, предна- значенные для крупных корпораций (например, от компании Cyber-Ark), могут стоить десятки тысяч долларов. Многие коммерческие предложения ориентированы либо на удовлетворение специальных требований пользователя, либо просто на количество за- поминаемых паролей. Мы используем собственную веб-ориентированную систему, которая имеет несколь- ко ценных функций. Одна их них (наша любимая) называется “разбить стекло” (по ана- логии с надписью на противопожарном оборудовании в отелях: “в случае крайней не- обходимости разбить стекло и дернуть за большую красную ручку”). В нашем случае “разбить стекло” означает получить пароль, к которому обычно нет доступа. В случае аварии вы можете взять на себя ответственность и запросить пароль. Система предоставит список системных администраторов и зарегистрирует все действия, совершаемые вами с помощью “аварийного” пароля. “Разрулив” ситуацию, вы должны изменить пароль и поместить в хранилище новый пароль. “Низкотехнологичный” способ реализации депонирования паролей “позаимство- ван” у полиции, которая для хранения вещественных доказательств, собранных на месте преступления, использует специальные пронумерованные пакеты. Такие пакеты можно найти с помощью Интернета. До тех пор пока пакет не открыт, вы точно знаете, что ни- кто не получил доступа к паролю, хранящемуся внутри него. 4.4. О ПСЕВДОПОЛЬЗОВАТЕЛЯХ Только пользователь root имеет для ядра Linux особый статус. Есть, однако, еще не- сколько псевдопользовательских учетных записей, которые применяются для системных целей. Эти фиктивные учетные записи можно идентифицировать по значениям UID, которые обычно меньше 100. Как правило, учетные записи с UID меньше 10 принадле- жат системе, а значения UID от 10 до 100 отведены для псевдопользователей, связанных со специальными программами.
Глава 4. Управление доступом: сила привилегий 161 Пароли этих псевдопользователей в файле /etc/shadow обычно заменяют звездоч- кой, чтобы нельзя было войти в систему под служебным именем. Чтобы защититься от средств атаки на основе дистанционного входа в систему (когда вместо паролей исполь- зуются файлы SSH-ключей), укажите в качестве командных интерпретаторов (вместо /bin/bash или /bin/sh) вариант /bin/false или /bin/nologin. Файлы и процессы, которые являются частью операционной системы, но не должны принадлежать пользователю root, иногда передаются во владение пользователям bin или daemon. Считается, что это поможет избежать риска, связанного с действиями от имени суперпользователя. Однако ввиду неубедительности подобной аргументации в современных системах используется просто учетная запись root. В некоторых системах пользователь sys владеет специальными файлами (образами памяти ядра), которые хранятся в каталоге /dev. Доступ к этим файлам имеют лишь не- многие программы, и все они изменяют текущий идентификатор пользователя на sys. Иногда вместо пользователя sys создается группа kmem или sys. Ш Дополнительную информацию об учетной записи nobody можно найти в конце разде- ла 18.2. Сетевая файловая система — NFS (Network File System) — использует учетную запись nobody для представления суперпользователей в других системах. Чтобы лишить супер- пользователей их исключительных прав, излишних в данном контексте, NFS должна на время сеанса удаленного доступа заменить нулевой идентификатор чем-то другим. Этой цели как раз и служит учетная запись nobody. В среде сервера NFSv4 эта учетная за- пись также применяется для удаленных пользователей, которые не имеют допустимые локальные учетные записи. Пользователю nobody не нужны специальные права доступа, и он не должен владеть никакими файлами. Если бы ему принадлежали какие-то файлы, то над ними получили бы контроль суперпользователи, регистрирующиеся в удаленных системах. Традиционно пользователю nobody соответствовал идентификатор -1 или -2, и это соглашение по-прежнему соблюдается в ядре Linux, где идентификатор этого пользова- теля равен 65534 (16-битовый беззнаковый эквивалент -2). В других дистрибутивах про- сто выбирается маленькое значение идентификатора (например, в Red Hat используется значение, равное 99), что при использовании 32-битовых идентификаторов пользовате- лей более оправдано. В системах Solaris применяется значение идентификатора 60001, которое, по крайней мере, легко запомнить. Единственный недостаток переопределения nobody-идентификатора состоит в том, что, судя по всему, команда exportfs не обращает внимания на файл passwd, поэтому с помощью опции anonuid ей нужно явно указывать о необходимости использования другого идентификатора для пользователя nobody. 4.5. Упражнения 4.1. Воспользуйтесь командой find с флагом -perm, чтобы найти в своей системе пять файлов с установленным битом “setuid”. Объясните, почему каждая из команд не сможет правильно функционировать без этого бита. 4.2. Создайте две записи в файле конфигурации sudoers. а) первая запись разрешает пользователям matt и lisa конфигурировать прин- тер, очищать его очередь и перезапускать демоны печати на компьютере printserver
162 Часть I. Основы администрирования б) вторая запись позволяет пользователям drew, smithgr и jimlane удалять за- дания и перезагружать компьютеры в студенческой лаборатории 4.3. Составьте три фразы по принципу “шокирующего абсурда”, а затем пропустите их через утилиту md5sum и сравните результаты. Не безопаснее ли использовать паро- ли в формате MD5 (учитывая достижения технологии шифрования)? Почему? 4.4. ★ Опишите последовательность команд, позволяющих модифицировать чужой пароль, и покажите, как “замести следы”. Предполагается, что доступ к учетной записи root имеется только через утилиту sudo (разрешены все команды, кроме интерпретаторов и su). 4.5. * Инсталлируйте утилиту sudo, которая будет направлять вам по электронной почте сообщения о попытках несанкционированного доступа. Используйте ее для проверки записей, созданных в упражнении 4.2, и убедитесь в том, что ути- лита правильно регистрирует сообщения в Syslog. (Необходим доступ с правами суперпользователя; возможно, понадобится также модифицировать файл /etc/ syslog. conf.) 4.6. Ж В системе Solaris, HP-UX или AIX создайте RBAC-роль, которая бы позволя- ла монтировать и демонтировать файловые системы. Назначьте на эту роль двух пользователей. (Необходим доступ с правами суперпользователя.) а) какие действия необходимо выполнить для этого? Можете ли вы ограничить список разрешенных операций для определенных файловых систем или типов файловых систем? б) переопределите свое решение в виде sudo-конфигурации. Оно сложнее, чем RBAC-решение, или проще? Можете ли вы ограничить список разрешенных операций для определенных файловых систем или типов файловых систем?
глава Управление процессами Процесс — это абстракция, используемая в операционных системах UNIX и Linux для описания выполняющейся программы. Процесс представляет собой системный объ- ект, посредством которого можно контролировать обращения программы к памяти, цен- тральному процессору и ресурсам ввода-вывода. Концепция, согласно которой как можно больше работы должно выполняться в кон- тексте процессов, а не в ядре, является частью философии UNIX. Системные и пользо- вательские процессы подчиняются одним и тем же правилам, благодарящему управле- ние ими осуществляется с помощью единого набора команд. 5.1. Атрибуты процесса Процесс состоит из адресного пространства и набора структур данных, содержащих- ся внутри ядра. Адресное пространство представляет собой совокупность страниц памя- ти1, которые были выделены ядром для выполнения процесса. В него загружается код процесса и используемые им библиотеки функций, а также переменные, содержимое стеков и различная вспомогательная информация, необходимая ядру во время работы процесса. Поскольку в системах UNIX и Linux поддерживается концепция виртуальной памяти, страницы адресного пространства процесса в конкретный момент времени мо- гут находиться либо в физической памяти, либо в разделе подкачки, т.е. на диске. В структурах данных ядра хранится всевозможная информация о каждом процессе. К наиболее важным относятся следующие сведения: • таблица распределения памяти; • текущий статус (неактивен, приостановлен, выполняется и т.п.); 1 Страницы — это базовые блоки памяти, размер которых составляет от 1 до 8 Кбайт.
164 Часть I. Основы администрирования • приоритет; • информация об используемых ресурсах; • информация о файлах и сетевых портах, открытых процессом; • маска сигналов (запись о том, какие сигналы блокируются); • имя владельца процесса. Поток выполнения, обычно именуемый просто потоком, представляет собой резуль- тат разветвления в выполнении процесса. Поток наследует многие атрибуты своего про- цесса (например, адресное пространство процесса), причем в рамках одного процесса могут выполняться одновременно (параллельно) сразу несколько потоков — такая мо- дель выполнения получила название многопоточности (multithreading). В старых однопроцессорных системах параллельное выполнение моделируется (точ- нее, имитируется) ядром, но в мультиядерных и многопроцессорных архитектурах по- токи могут выполняться одновременно в различных ядрах. Такие многопоточные прило- жения, как BIND и Apache, извлекают максимальную пользу из мультиядерных систем, поскольку эти приложения могут отрабатывать несколько запросов одновременно. Все наши примеры операционных систем поддерживают многопоточный режим. Многие характеристики процесса непосредственно влияют на его выполнение. В част- ности, имеет значение, сколько времени выделяется ему центральным процессором, к каким файлам он имеет доступ и т.д. В следующих подразделах рассмотрим наиболее интересные с точки зрения системного администратора характеристики процессов. Они поддерживаются во всех версиях систем UNIX и Linux. Идентификатор процесса (PID) Ядро назначает каждому процессу уникальный идентификатор2. Большинство команд и системных вызовов, работающих с процессами, требует указания конкретного иден- тификатора, чтобы был ясен контекст операции. Идентификаторы присваиваются по порядку по мере создания процессов. Идентификатор родительского процесса (PPID) Ни в UNIX, ни в Linux нет системного вызова, который бы инициировал новый про- цесс для выполнения конкретной программы. Для того чтобы породить новый процесс, существующий процесс должен клонировать сам себя. Клон может заменить выполняе- мую программу другой. В операции клонирования исходный процесс называют родительским, а его клон — дочерним. Помимо собственного идентификатора, каждый дочерний процесс имеет ат- рибут PPID (Parent Process ID), который совпадает с идентификатором породившего его родительского процесса3. Идентификатор родительского процесса — весьма полезная информация, если при- ходится иметь дело с неизвестным (и, возможно, нестандартно ведущим себя) процес- 2 Как отмечено нашим рецензентом Джоном Корбетом (Jon Corbet), в ядре Linux 2.6.24 пред- ставлены пространства имен процессов, которые позволяют существовать одновременно несколь- ким процессам с одинаковыми идентификаторами PID. Это свойство реализовано для поддержки виртуализации на основе контейнеров. 3 По крайней мере, первоначально. Если родительский процесс по какой-то причине заверша- ется раньше потомка, демон init (процесс с номером 1) подставляет себя на место предка (под- робности описаны в разделе 5.2).
Глава 5. Управление процессами 165 сом. Отслеживание истоков процесса может облегчить понимание его назначения и зна- чимости. Идентификатор пользователя (UID) и текущий идентификатор пользователя (EUID) Ш Дополнительная информация об идентификаторах пользователя приведена в разде- ле 7.1. UID (User ID) — это идентификатор пользователя, создавшего данный процесс, точнее, копия значения UID родительского процесса. Менять атрибуты процесса могут только его создатель (владелец) и суперпользователь. EUID (Effective User ID) — это текущий пользовательский идентификатор процесса, предназначенный для того, чтобы определить, к каким ресурсам и файлам у процесса есть право доступа в данный момент. У большинства процессов значения UID и EUID одинаковы. Исключение составляют программы, у которых установлен бит смены иден- тификатора пользователя (setuid). Зачем нужны два идентификатора? Просто имеет смысл разграничить понятия пер- сонификации и прав доступа. К тому же программы с установленным битом setuid не всегда выполняются с расширенными привилегиями. В большинстве систем значение EU1D можно устанавливать, чтобы предоставлять процессу дополнительные полномо- чия, и сбрасывать, чтобы отбирать их. В большинстве систем хранится начальный идентификатор, т.е. копия значения EUID, который имел процесс в начальной точке. Если процесс не удалит сохраненный идентификатор, его можно будет использовать в качестве реального или текущего иден- тификатора. Благодаря этому “консервативно” написанная программа с установленным битом setuid может большую часть времени работать с обычными привилегиями, пере- ходя в режим расширенных привилегий лишь в определенные моменты. В системе Linux есть еще и нестандартный параметр FSUID, определяющий возмож- ности работы с файловой системой, но вне ядра он используется редко и не переносится на другие системы UNIX. Идентификатор группы (GID) и текущий идентификатор группы (EGID) Q Дополнительная информация о группах приведена в разделе 7.1. GID (Group ID) — это идентификатор группы, к которой принадлежит владелец про- цесса. Текущий идентификатор группы (Effective Group ID — EGID) связан с атрибутом GID так же, как значение EUID связано с UID, т.е. они будут отличаться в случае про- граммы, у которой установлен бит смены идентификатора группы (setgid). В ядре на- значение сохраненного GID аналогично назначению сохраненного атрибута UID. В значительной степени атрибут GID процесса является рудиментарным. С точки зрения определения прав доступа процесс одновременно может относиться к несколь- ким группам. Список групп хранится отдельно от значений GID и EGID. При анализе прав доступа проверяется текущий идентификатор и дополнительный список групп, но не значение GID. Если пользователь пытается получить доступ к какому-либо ресурсу, весь список проверяется на предмет того, принадлежит ли пользователь к группе, чле- нам которой разрешается использовать данный ресурс.
166 Часть I. Основы администрирования Атрибут GID используется только при создании процессом новых файлов. В зависи- мости от установленных прав доступа в данной файловой системе новые файлы могут принимать атрибут GID создающего их процесса. Подробнее эти вопросы рассмотрены в разделе 6.5. Приоритет и фактор уступчивости Приоритет процесса определяет, какую долю времени центрального процессора по- лучает программа. Ядро применяет динамический алгоритм вычисления приоритетов, учитывающий, сколько времени центрального процессора уже использовал процесс и сколько времени он ожидает своей очереди. Кроме того, учитывается заданный админи- стратором так называемый фактор уступчивости (устанавливается с помощью команды nice), который определяет, в какой степени программа может “делиться” процессором с другими программами. Подробнее этот механизм рассматривается в разделе 5.6. л Для улучшения поддержки приложений с небольшой временной задерж- /jb кой в системе Linux в традиционную модель планирования задач UNIX до- бавлены “классы планирования”. В настоящее время существует три класса планирования, причем каждый процесс относится только к одному из них. К сожалению, классы реального времени пока не находят широкого при- менения, а их поддержка из командной строки оставляет желать лучшего. Все системные процессы используют традиционный планировщик, ориен- тированный на применение фактора уступчивости, который мы и рассма- триваем в этой книге. Более подробную информацию по вопросам, связан- ным с планированием в реальном времени, можно найти на веб-сайте www. realtimelinuxfoundation.org. Управляющий терминал С большинством процессов, не являющихся демонами, связан управляющий терми- нал, который определяет базовую конфигурацию стандартных каналов ввода, вывода и ошибок. Когда пользователь запускает какую-либо программу в интерпретаторе, его терминал, как правило, становится управляющим терминалом процесса. От управляю- щего терминала зависит также распределение сигналов, о чем пойдет речь в разделе 5.3. 5.2. Жизненный цикл процесса Для создания нового процесса существующий процесс, как правило, клонирует сам себя с помощью системного вызова fork. В результате формируется копия исходного процесса, имеющая лишь некоторые отличия. В частности, новому процессу присваива- ется собственный идентификатор, и учет ресурсов ведется для него независимо от предка. Системный вызов fork имеет уникальное свойство: он возвращает два разных зна- чения. В дочернем процессе это будет 0, а в родительском — идентификатор процесса- потомка. Поскольку в остальном процессы идентичны, они должны проверять результат вызова, чтобы определить, какую роль следует играть в дальнейшем. После завершения системного вызова fork дочерний процесс обычно запускает но- вую программу с помощью одного из системных вызовов семейства ехес4. Все вызовы этого семейства выполняют приблизительно одинаковые действия: они замещают сег- 4 В действительности все они, кроме одного, являются библиотечными функциями.
Глава 5. Управление процессами 167 мент кода процесса и устанавливают сегменты памяти в исходное состояние. Формы вызовов ехес различаются только способами указания аргументов командной строки и переменных среды, передаваемых новой программе. Ш Подробная информация о начальной загрузке и демоне init приведена в главе 3. Когда система загружается, ядро самостоятельно запускает несколько процессов. Наи- более важный из них — это демон init, идентификатор которого всегда равен 1. Демон init отвечает за выполнение сценариев запуска системы, хотя характер его действий неодинаков в UNIX и Linux. Все процессы, кроме тех, что создаются ядром, являются потомками демона init. Демон init играет и другую важную роль в управлении процессами. Завершающийся процесс вызывает функцию _exit, чтобы уведомить ядро о своей готовности прекратить работу. В качестве параметра функции _exit передается код завершения — целое число, обозначающее причину останова процесса. Нулевой код свидетельствует об успешном завершении процесса. Ядро системы требует, чтобы, прежде чем процесс окончательно исчезнет, его удале- ние было подтверждено родительским процессом с помощью системного вызова wait. Этот вызов возвращает код завершения потомка (или сообщает о причине его уничто- жения, если завершение не было естественным) и, в случае необходимости, статистику использования ресурсов. Описанный механизм работает нормально, если родительский процесс завершается позже порожденных им процессов и выполняет системные вызовы wait для их уни- чтожения. Если же родительский процесс завершается раньше срока, то ядро “понима- ет”, что вызова wait не последует, и переназначает все “осиротевшие” процессы демону init. Он берет их под свой контроль, осуществляя для каждого из них вызов wait. 5.3. Сигналы Сигналы — это запросы на прерывание, реализуемые на уровне процессов. Опреде- лено свыше тридцати различных сигналов, и они находят самое разное применение. • Сигналы могут посылаться между процессами как средство коммуникации. • Сигналы могут посылаться драйвером терминала для уничтожения или приоста- новки процессов, когда пользователь нажимает специальные комбинации клавиш, такие как <Ctrl+C> или <Ctrl+Z>5. • Сигналы могут посылаться в самых разных целях пользователем или администра- тором с помощью команды kill. • Сигналы могут посылаться ядром, когда процесс выполняет нелегальную инструк- цию, например деление на нуль. • Сигналы могут посылаться ядром для уведомления процесса о “представляющем интерес” событии, таком как прекращение дочернего процесса или доступность данных в канале ввода-вывода. Ш Дамп памяти — это файл, содержащий образ памяти процесса. Его можно использовать для отладки. 5 Функции, связанные с этими комбинациями клавиш, могут назначаться другим клавишам помощью команды stty, но на практике такое встречается очень редко. В этой главе мы под- разумеваем, что с данными клавишами связаны их стандартные функции.
168 Часть I. Основы администрирования Когда поступает сигнал, возможен один из двух вариантов развития событий. Если процесс назначил сигналу подпрограмму обработки, то после вызова ей предоставляется информация о контексте, в котором был сгенерирован сигнал. В противном случае ядро выполняет от имени процесса действия, заданные по умолчанию. Эти действия зависят от сигнала. Многие сигналы приводят к завершению процесса, а в некоторых случаях при этом еще и создается дамп памяти. Процедура вызова обработчика называется перехватом сигнала. Когда выполнение обработчика завершается, процесс возобновляется с той точки, где был получен сигнал. Для того чтобы определенные сигналы не поступали в программу, нужно задать их игнорирование или блокирование. Игнорируемый сигнал просто пропускается и не вли- яет на работу процесса. Блокируемый сигнал ставится в очередь на обработку, но ядро не требует от процесса никаких действий до явного разблокирования сигнала. Обработчик вызывается для разблокированного сигнала только один раз, даже если в течение перио- да блокировки поступило несколько аналогичных сигналов. В табл. 5.1 перечислены сигналы, которые должны быть известны любому системно- му администратору. Традиционно имена сигналов записываются прописными буквами. Иногда к именам добавляется префикс SIG (например, SIGHUP). Таблица 5.1. Сигналы, которые должен знать каждый администратор8 № Имя Описание Реакция по умолчанию Перехваты- вается? Блоки- руется? Дамп памяти? 1 HUP Отбой Завершение Да Да Нет 2 INT Прерывание Завершение Да Да Нет 3 QUIT Выход Завершение Да Да Да 9 KILL Уничтожение Завершение Нет Нет Нет _б BUS Ошибка на шине Завершение Да Да Да 11 SEGV Ошибка сегментации Завершение Да Да Да 15 TERM Запрос на завершение Завершение Да Да Нет _б STOP Останов Останов Нет Нет Нет _ б TSTP Сигнал останова, посылаемый с клавиатуры Останов Да Да Нет _ б CONT Продолжение после останова Игнорируется Да Нет Нет _ б WINCH Изменение окна Игнорируется Да Да Нет _б USR1 Определяется пользователем Завершение Да Да Нет _б USR2 Определяется пользователем Завершение Да Да Нет а Список названий сигналов и номеров также можно получить с помощью встроенной в bash команды kill -1. 6 Зависит от используемой системы. Подробнее см. файл /usr/include/signal .h или man-страницы интерактивного руководства для системного вызова signal (). Существуют и другие сигналы, не показанные в табл. 5.1; большинство из них сооб- щает о всяких загадочных ошибках, например “неверная инструкция”. По умолчанию такие сигналы, как правило, приводят к завершению программы и созданию дампа па- мяти. Перехват и блокирование сигналов обычно разрешены, так как есть достаточно “умные” программы, устраняющие последствия ошибок.
Глава 5. Управление процессами 169 Сигналы BUS и SEGV также посылаются при возникновении ошибок. Мы включили их в таблицу, поскольку они чрезвычайно распространены: обычно программа аварийно завершается именно из-за них. Сами по себе эти сигналы не имеют диагностической ценности. Они лишь указывают на факт неправильного обращения к памяти6. Сигналы KILL и STOP нельзя ни перехватить, ни заблокировать, ни проигнориро- вать. Сигнал KILL приводит к уничтожению процесса, которому он посылается, а сиг- нал STOP приостанавливает выполнение процесса до получения сигнала CONT. Сигнал CONT можно перехватить и проигнорировать, но нельзя заблокировать. Сигнал TSTP представляет собой более “гибкую” версию сигнала STOP. Проще всего описать его как запрос на останов. Он генерируется драйвером терминала при нажатии пользователем комбинации клавиш <Ctrl+Z>. Программы, перехватывающие этот сиг- нал, обычно выполняют операции очистки, а затем посылают сами себе сигнал STOP. С другой стороны, программы могут игнорировать сигнал TSTP, чтобы их нельзя было остановить командой с клавиатуры. Эмуляторы терминалов посылают сигнал WINCH, когда происходит изменение их конфигурационных параметров (например, числа строк на виртуальном терминале). Это позволяет программам, которые взаимодействуют с эмуляторами, таким как текстовые редакторы, автоматически переконфигурировать себя в ответ на изменения. Если размер окна не удается правильно изменить, убедитесь в том, что сигнал WINCH генерируется и корректно обрабатывается7. Хотя назначение сигналов KILL, INT, TERM, HUP и QUIT может показаться одинако- вым, в действительности они совершенно различны. • Сигнал KILL не блокируется и приводит к безусловному завершению процесса на уровне ядра. По сути, процесс не успевает даже принять этот сигнал. • Сигнал INT посылается драйвером терминала при нажатии пользователем комби- нации клавиш <Ctrl+C> и служит запросом на завершение текущей операции. Перехватив этот сигнал, простые программы должны завершить работу или позво- лить уничтожить себя стандартному обработчику сигнала. Программы, в которых есть интерактивный режим командной строки, должны прекратить текущую опе- рацию, выполнить очистку и снова перейти в режим ожидания. • Сигнал TERM представляет собой запрос на завершение программы. Предполага- ется, что процесс, получивший этот сигнал, осуществляет очистку и завершается. • У сигнала HUP есть две распространенные интерпретации. Во-первых, многие де- моны воспринимают его как команду сброса. Если демон способен повторно про- честь свой конфигурационный файл и адаптироваться к изменениям без переза- пуска, сигнал HUP позволяет менять его поведение. 6 Точнее говоря, ошибки на шине возникают в результате нарушения различных требований синхронизации или использования бессмысленных адресов. Нарушения правил сегментирования представляют собой нарушения правил защиты, например к ним относятся попытки выполнить запись в части адресного пространства, доступной только для чтения. На практике это может оказаться не такой уж простой задачей. И эмулятор терминала (на- пример, xterm), и драйвер терминала, и команды пользовательского уровня — все они могут вно- сить свой вклад в распространение сигнала SIGWINCH. Распространенные проблемы — отправка сигнала только фоновому процессу терминала (а не всем связанным с ним процессам) без рас- сылки по сети уведомления об изменении размера удаленным компьютерам. Такие протоколы, как ELnet и SSH, явным образом распознают изменения размера локального терминала и передают ЭТУ информацию удаленному узлу. Более простые протоколы (например, протоколы прямого по- Слсдовательного подключения) лишены этой возможности.
170 Часть I. Основы администрирования • Во-вторых, этот сигнал иногда генерируется драйвером терминала при попытке уничтожить связанные с терминалом процессы. В основном это поведение сохра- нилось со времен использования проводных соединений терминалов и модемов. Отсюда и название “отбой”. • Интерпретаторы семейства csh (tcsh и другие) обычно делают фоновые процес- сы невосприимчивыми к сигналу HUP, чтобы они могли продолжать свою работу, даже когда пользователь выходит из системы. Пользователи интерпретаторов се- мейства sh (ksh, bash и так далее) могут эмулировать такое поведение с помощью команды nohup. • Сигнал QUIT напоминает сигнал TERM, за исключением того, что по умолчанию стандартный обработчик создает дамп памяти. Сигналы USR1 и USR2 не имеют стандартного назначения. Ими можно пользовать- ся в различных целях. Например, веб-сервер Apache интерпретирует сигнал USR1 как запрос на перезапуск. 5.4. Отправка сигналов: команда kill Команду kill чаще всего используют для уничтожения процессов. Эта команда мо- жет послать процессу любой сигнал, но по умолчанию это сигнал TERM. Команду kill могут выполнять как рядовые пользователи (для своих собственных процессов), так и суперпользователь (для любого процесса). Она имеет следующий синтаксис: kill [-сигнал] идентификатор, где сигнал — это номер или символическое имя посыпаемого сигнала (см. табл. 5.1), а идентификатор — номер искомого процесса. Команда kill без номера сигнала не гарантирует, что процесс будет уничтожен, по- скольку сигнал TERM можно перехватывать, блокировать и игнорировать. Команда kill -9 идентификатор “гарантированно” уничтожает процесс, так как сигнал с номером 9 (KILL) не пере- хватывается. Используйте команду kill -9 только в случае, если “вежливый” запрос на завершение программы не был выполнен. Мы написали слово “гарантированно” в кавычках, так как иногда процессы переходят в такое состояние, в котором их нель- зя завершить даже таким способом (обычно это связано с блокировкой ввода-вывода, например, при остановке жесткого диска). Единственный выход в такой ситуации — перезагрузка. Команда killall выполняет различные функции в системах UNIX и Linux. В Linux команда killall уничтожает процессы, заданные именем. Например, следующая ко- манда уничтожает все процессы веб-сервера Apache. ubuntu$ sudo killall httpd Стандартная UNIX-команда killall, предусмотренная в дистрибутивах Solaris, HP- UX и AIX, не принимает параметры и просто уничтожает все процессы текущего поль- зователя. Ее выполнение от имени суперпользователя приведет к уничтожению процес- са init и выключению компьютера. Ух! Команды pgrep и pkill в системах Solaris, HP-UX и Linux (но не в AIX) осущест- вляют поиск процессов, заданных именами (или другими атрибутами). Команда pgrep выводит идентификаторы процессов, удовлетворяющих заданному в командной строке критерию, а команда pkill посылает найденным процессам сигнал. Например, следую-
Глава 5. Управление процессами 171 щая команда посылает сигнал TERM всем процессам, выполняемым от имени пользова- теля ben. $ sudo pkill -u ben 5.5. Состояния ПРОЦЕССА Факт существования процесса не дает ему автоматически права на получение досту- па к центральному процессору. Необходимо помнить о четырех состояниях выполнения процесса (табл. 5.2). Таблица 5.2. Состояния процесса Состояние £ Выполнение Ожидание Зомби Останов Процесс можно выполнять Процесс ждет выделения ресурса Процесс пытается завершиться Процесс приостановлен (не имеет разрешения на выполнение) Выполняемый процесс получил все необходимые ресурсы и ждет, пока системный планировщик предоставит ему доступ к центральному процессору. Если процесс осу- ществляет системный вызов, который нельзя завершить немедленно (например, чтение части файла), ядро переводит его в состояние ожидания. Ожидающий процесс ждет наступления определенного события. Интерактивные ин- терпретаторы команд и системные демоны проводят в этом состоянии большую часть времени, ожидая поступления данных с терминала или из сетевого соединения. По- скольку ожидающий процесс фактически блокирован, доступ к центральному процессо- ру будет предоставлен ему только в случае получения сигнала или ответа на один из его запросов ввода-вывода. Некоторые операции переводят процесс в состояние непрерывного ожидания. Обыч- но это состояние является временным и не отображается в выводе команды ps, о чем свидетельствует флаг D в столбце STAT (см. табл. 5.4). Однако некоторые нестандарт- ные ситуации могут приводить к сохранению этого состояния надолго. Наиболее рас- пространенная причина возникновения такой ситуации — наличие проблем сервера в файловой системе NFS, смонтированной с применением параметра “hard”. Поскольку процессы в состоянии непрерывного ожидания не могут быть активизированы даже для реакции на сигнал, их нельзя уничтожить. Для того чтобы избавиться от них, необходи- мо устранить породившую их проблему или перезагрузить систему. Зомби — это процесс, который закончил выполняться, но информация об этом еще не поступила родительскому процессу. При обнаружении зомби с помощью команды ps проверьте их атрибуты PPID, чтобы выяснить происхождение этих процессов. Остановленному процессу временно запрещено выполняться. Процессы останавли- ваются при получении сигнала STOP или TSTP и возобновляют работу по сигналу CONT. Это состояние аналогично ожиданию, но выход из него возможен только с помощью дру- гого процесса.
172 Часть I. Основы администрирования 5.6. Изменение приоритета выполнения: КОМАНДЫ NICE И RENICE Фактор “уступчивости” — это число, по которому ядро определяет свою политику в отношении процессов, конкурирующих за право доступа к центральному процессору. Чем выше фактор уступчивости, тем ниже приоритет процесса и наоборот, отсюда и на- звание термина. Низкое или отрицательное значение означает использование высокого приоритета: процесс ведет себя не слишком уступчиво. Диапазон допустимых значений фактора уступчивости зависит от используемой си- стемы, и обычно он лежит в пределах от -20 до +19. В некоторых системах используется диапазон такого же размера, но со смещением в область неотрицательных чисел (как правило, от 0 до 39). Диапазоны допустимых значений фактора уступчивости, исполь- зуемые в наших примерах систем, приведены в табл. 5.3. Несмотря на числовые различия, все системы обрабатывают значения фактора уступ- чивости практически одинаково. Если пользователь не предпринимает специальных мер, дочерний процесс наследует приоритет своего родительского процесса. Владелец процесса может увеличить фактор уступчивости, но не может уменьшить его, даже что- бы вернуться к стандартному значению. Это не позволяет процессам с низким приори- тетом порождать высокоприоритетных потомков. Суперпользователь может устанавли- вать произвольные значения фактора уступчивости. В настоящее время администраторам редко приходится определять приоритеты вруч- ную. Когда операционные системы работали на маломощных компьютерах 70—80 гг., на производительность больше всего влияло то, какой процесс занимал основную часть времени центрального процессора. Сегодня, когда на рабочих столах стоят намного бо- лее быстродействующие компьютеры, системный планировщик, как правило, обслужи- вает все процессы весьма оперативно. Добавление классов планирования предоставляет разработчикам дополнительные средства управления в тех случаях, когда важна быстрая ответная реакция. К сожалению, уровень производительности подсистемы ввода-вывода растет не так стремительно, как быстродействие центральных процессоров, поэтому жесткие диски стали основным узким местом в большинстве операционных систем. Фактор уступчи- вости никак не влияет на подсистемы управления памятью и вводом-выводом, поэтому даже низкоприоритетный процесс способен монополизировать эти ресурсы или захва- тить непропорционально большую их часть. Фактор уступчивости можно установить при создании процесса. Это делается с по- мощью команды nice. Команда renice позволяет изменять приоритет выполняемого процесса. Первая из этих команд принимает в качестве аргумента строку запуска про- цесса, а вторая — идентификатор процесса либо имя пользователя. Приведем примеры. $ nice -п 5 ~/bin/longtask // Понижаем приоритет (увеличиваем // фактор уступчивости) на 5 $ sudo renice -5 8829 // Задаем фактор уступчивости равным -5 $ sudo renice 5 -u boggs // Задаем фактор уступчивости процессов // пользователя ’’boggs" равным 5 К сожалению, в системах по-разному реализован способ установки желаемого при- оритета; более того, даже в рамках одной и той же системы не согласованы механизмы действия команд nice и renice. Одни команды требуют указания относительного зна- чения фактора уступчивости, а другие — абсолютного, В одних командах нужно перед
Глава 5. Управление процессами 173 значением фактора уступчивости ставить дефис, в других требуется флаг -п, а третьи “довольствуются” просто числовым значением. Существует также версия команды nice, встроенная в интерпретатор csh и ряд дру- гих популярных интерпретаторов (но не в bash). Если не указать полное имя команды, будет вызвана именно встроенная версия, а не системная. Это многих сбивает с толку, так как синтаксис команд различен: встроенная версия требует, чтобы изменение прио- ритета записывалось в формате +инкр или -декр, а системная версия ожидает флаг -п, за которым следует значение приращения8. Все эти вариации и разбросы приведены в табл. 5.3. Элемент приор для среды, в ко- торой вызывается команда nice или renice, означает абсолютное значение фактора уступ- чивости, а инкр — относительное. Везде, где указывается значение -инкр или -декр, для ввода отрицательных значений можно использовать два дефиса (например —10). Знаки “плюс” в команде nice обязательны только для интерпретатора команд; в осталь- ных случаях они игнорируются. Таблица 5.3. Как выражаются приоритеты в различных версиях команд nice и renice Система Диапазон ОС-команда nice Команда nice в csh Linux 20-19 -инкр ИЛИ -п инкр +инкр ИЛИ -инкр приор Solaris 0-39 -инкр ИЛИ -п инкр +инкр ИЛИ -инкр инкр или —п инкр HP-UX 0-39 -приор ИЛИ —п приор +инкр ИЛИ -инкр -п приор* AIX 20-19 - инкр И Л И - п инкр +инкр ИЛИ -инкр —п инкр а Используется абсолютное значение приоритета, но к заданному значению добавляется число 20. Самый распространенный из высокоприоритетных процессов в современных си- стемах — ntpd, демон тактовой синхронизации. Поскольку для него быстрый доступ к центральному процессору имеет очень большое значение, этому демону обычно назна- чается фактор уступчивости, на 12 позиций ниже стандартного уровня. Если какой-либо процесс займет столько времени центрального процессора, что по- казатель средней загруженности системы достигнет отметки 65, то перед выполнением команд, необходимых для исследования этой проблемы, понадобится запустить с помо- щью команды nice высокоприоритетный интерпретатор. В противном случае выполне- ние даже простейших команд может быть затруднено. 5.7. Текущий контроль процессов: команда ps Команда ps — основной инструмент, которым системный администратор пользуется для текущего контроля процессов. Версии этой команды различаются аргументами и выходным форматом, но, по сути, выдают одну и ту же информацию. В основном, различие в верси- ях — это следствие разных путей развития систем UNIX. Кроме того, поставщики систем могут настраивать эту команду с учетом конфигурации системы, так как она тесно связана с Ос°бенностями обработки процессов в ядре и поэтому часто отражает изменения в ядре. С помощью команды ps можно получить информацию об идентификаторах, прио- ритете и управляющем терминале того или иного процесса. Она также позволяет выяс- нить, какой объем памяти использует процесс, сколько времени центрального процес- с°ра заняло его выполнение, каково его текущее состояние (выполняется, остановлен, 8 Хуже того, системная версия команды интерпретирует строку nice -5 как положительное РИращение, а встроенная версия интерпретирует эту же строку как отрицательное приращение.
174 Часть I. Основы администрирования простаивает и т.д.). Процессы-зомби в листинге команды обозначаются как <exiting> или <defunct>. Команда ps стремительно усложнилась за последние несколько лет. Некоторые по- ставщики бросили попытки стандартизировать выходной формат этой команды и сде- лали ее полностью конфигурируемой. Проведя небольшую настройку, можно получить практически любые требуемые результаты. В Linux команда ps является настоящим ха- мелеоном и понимает наборы опций из ряда других систем. Имеется также специальная переменная среды, с помощью которой можно выбрать нужный набор. Не пугайтесь всех этих сложностей: пусть они будут кошмаром разработчиков ядра, а не системных администраторов! Для повседневной работы достаточно знать лишь не- сколько наиболее важных опций команды ps. Получить список всех процессов, выполняющихся в системах Linux и AIX, можно с помощью команды ps aux. Ключ а используется для отображения всех процессов, х — для отображения процессов, отсоединенных от термина- ла, а ключ и обеспечивает фильтрование по имени или идентификатору поль- зователя, который запустил программу. Ниже показаны результаты работы команды ps aux в системе Red Hat (результат работы той же команды для си- стемы AIX имеет небольшие отличия). redhat$ ps aux USER PID %CPU % MEM VSZ RSS TTY STAT TIME COMMAND root 1 0.1 0.2 3356 560 ? S 0:00 init [5] root 2 0 0 0 0 2 SN 0:00 [ksoftirqd/0] root 3 0 0 0 0 2 S< 0:00 [events/0] root 4 0 0 0 0 2 s< 0:00 [khelper] root 5 0 0 0 0 2 s< 0:00 [kacpid] root 18 0 0 0 0 2 s< 0:00[kblockd/0] root 28 0 0 0 0 2 s 0:00 [pdflush] root 196 0 0 0 0 2 s 0:00 [kjournald] root 1050 0 0.1 2652 448 2 S<s 0:00 udevd root 1472 0 0.3 3048 1008 2 S<s 0:00 /sbin/dhclient -1 root 1646 0 0.3 3012 1012 2 S<s 0:00 /sbin/dhclient -1 root 1733 0 0 0 0 2 S 0:00 [kjournald] root 2124 0 0.3 3004 1008 2 Ss 0:00 /sbin/dhclient -1 root 2182 0 0.2 2264 596 2 Ss 0:00 syslogd -m 0 root 2186 0 0.1 2952 484 2 Ss 0:00 klogd -x rpc 2207 0 0.2 2824 580 2 Ss 0:00 portmap rpcuser 2227 0 0.2 2100 760 2 Ss 0:00 rpc.statd root 2260 0 0.4 5668 1084 2 Ss 0:00 rpc.idmapd root 2336 0 0.2 3268 556 2 Ss 0:00 /usr/sbin/acpid root 2348 0 0.8 9100 2108 2 Ss 0:00 cupsd root 2384 0 0.6 4080 1660 2 Ss 0:00 /usr/sbin/sshd root 2399 0 0.3 2780 828 2 Ss 0:00 xinetd -stayalive root 2419 0 1.1 7776 3004 2 Ss 0:00 sendmail: accept Команды, имена которых заключены в квадратные скобки, в действительности яв- ляются не командами, а потоками ядра, запланированными в качестве процессов. Опи- сание полей приведено в табл. 5.4. Еще один полезный набор аргументов команды ps для систем Linux и AIX — lax, предоставляющий дополнительную техническую информацию. Ключи а и х описаны вы-
Глава 5. Управление процессами 175 ше (отображают все процессы), а ключ 1 означает выбор “длинного” формата вывода данных. Команда ps lax выполняется быстрее, чем команда ps aux, так как не со- поставляет идентификаторы процессов с именами пользователей. Это может оказаться весьма важным фактором, если система уже перегружена каким-то процессом. Таблица 5.4. Пояснения к выходной информации команды ps aux Поле____5^__ user Имя владельца процесса pid Идентификатор процесса %cpu Доля времени центрального процессора (в процентах), выделенная процессу %мем Часть реальной памяти (в процентах), используемая процессом vsz Виртуальный размер процесса RSS Размер резидентного набора (количество страниц памяти) tty Идентификатор управляющего терминала stat Текущий статус процесса: R — выполняется D — ожидает записи на диск S — неактивен (< 20 с) т — приостановлен z — зомби Дополнительные флаги: w — процесс выгружен на диск < — процесс имеет повышенный приоритет N — процесс имеет пониженный приоритет L — некоторые страницы блокированы в оперативной памяти s — процесс является лидером сеанса тIME Количество времени центрального процессора, затраченное на выполнение процесса command имя и аргументы командыа Программы могут модифицировать эту информацию, так что она не всегда точно представляет реальную командную строку. Ниже в сокращенном виде показаны результаты работы команды ps lax. Обратите внимание на дополнительные поля PPID (идентификатор родительского процесса), NI (фактор уступчивости) и WCHAN (ресурс, которого ожидает процесс). redhat$ ps lax F UID PID PPID PRI NI vsz RSS WCHAN STAT TIME COMMAND 4 0 1 0 16 0 3356 560 select S 0:00 init [5] 1 0 2 1 34 19 0 0 ksofti SN 0:00 [ksoftirqd/0 1 0 3 1 5 -10 0 0 worker S< 0:00 [events/0] 1 0 4 3 5 -10 0 0 worker s< 0:00 [khelper] 5 0 2186 1 16 0 2952 484 syslog Ss 0:00 klogd -x 5 32 2207 1 15 0 2824 580 - Ss 0:00 portmap 5 29 2227 1 18 0 2100 760 select Ss 0:00 rpc.statd 1 0 2260 1 16 0 5668 1084 - Ss 0:00 rpc.idmapd 1 0 2336 1 21 0 3268 556 select Ss 0:00 acpid 5 0 2384 1 17 0 4080 1660 select Ss 0:00 sshd 1 0 2399 1 15 0 2780 828 select Ss 0:00 xinetd -sta 5 0 2419 1 16 0 7776 3004 select Ss 0:00 sendmail: a
176 Часть I. Основы администрирования В системах Solaris и HP-UX удобно использовать команду ps -ef. Ключ е по- зволяет выбрать все процессы, а ключ f устанавливает выходной формат. (Ко- манда ps -ef работает и в системах AIX и Linux — обратите внимание на ис- soiaris пользование дефиса.) solaris$ ps -ef UID PID PPID C STIME TTY TIME COMD root 0 0 80 Dec 21 9 0:02 sched root 1 0 2 Dec 21 ? 4:32 /etc/init- root 2 0 8 Dec 21 9 0:00 pageout root 171 1 80 Dec 21 9 0:02 /usr/lib/sendmail-bd trent 8482 8444 35 14:34:10 pts/7 0:00 ps-ef trent 8444 8442 203 14:32:50 pts/7 0:01 -csh Описание полей (как результата выполнения команды ps -ef) приведено в табл. 5.5. Таблица 5.5. Пояснения к выходной информации команды ps -ef Поле Содержимое UID Идентификатор пользователя PID Идентификатор процесса PPID Идентификатор родительского процесса C Информация об использовании/планировании времени центрального процессора STIME Время запуска процесса TIME Количество времени центрального процессора, затраченное на выполнение процесса TTY Терминал COMMAND Имя и аргументы команды Подобно команде ps lax в системах Linux и AIX, команда ps -elf выводит допол- нительные данные по системам Solaris и HP-UX. % ps -elf F S UID PID PPID CPU! ADDR SZ WCHAN TIME COMD 19 T root 0 0 80 0 SY f00c2fd8 0 0:02 sched 8 S root 1 0 65 1 20 ff26a800 88 ff2632c8 4:32 init- 8 S root 142 1 41 1 20 ff2e8000 176 f00cb69 0:00 syslogd Чтобы результаты поместились на странице, поля STIME и TTY были опущены; они идентичны полям, сгенерированным командой ps -ef. Описание полей приведено в табл. 5.6. Таблица 5.6. Пояснения к выходной информации команды ps -elf Поле Содержимое F Флаги процесса (зависят от системы — редко полезны для системных администраторов) S Статус процесса: о — выполняется R — готов к выполнению z — зомби s — неактивен (ожидает событие) т — приостановлен или отслеживается D — полностью неактивен (обычно диск)
Глава 5. Управление процессами 177 Окончание табл. 5.6 Поле Содержимое_________________________________________________________________ с Информация об использовании/планировании времени центрального процессора Р Запланированный приоритет (внутренний для ядра, отличный от значения фактора “уступчивости”) NI Значение фактора “уступчивости”или sy для системных процессов addr Адрес процесса sz Размер (в страницах) процесса в основной памяти wchan Адрес объекта, которого ожидает процесс 5.8. Динамический мониторинг процессов С ПОМОЩЬЮ КОМАНД TOP, PRSTAT И TOPAS Команда ps позволяет сделать только разовый, моментальный, “снимок” системы, но получить полную картину всего происходящего в ней довольно сложно. Для этого служит свободно распространяемая утилита top, которая работает во многих системах, регулярно обновляя сводку активных процессов и используемых ими ресурсов. В AIX эквивалентную функцию выполняет утилита topas, а в Solaris — prstat . Рассмотрим пример. ubuntu$ top top - 16:37:08 up 1:42, 2 users, load average: 0.01, 0.02, 0.06 Tasks: 76 total, 1 running, 74 sleeping, 1 stopped, 0 zombie Cpu(s): 1.1% us, 6.3% sy, 0.6% ni, 88.6% id, 2.1% wa, 0.1% hi, 1.3% si Mem: 256044k total, 254980k used, 1064k free, 15944k buffers Swap: 524280k total, 0k used, 524280k free, 153192k cached PID USER PR NI VIRT RES SHR s %CPU %MEM TIME+ COMMAND 3175 root 15 0 35436 12m 4896 s 4.0 5.2 01:41.9 X 3421 root 25 10 29916 15m 9808 s 2.0 6.2 01:10.5 rhn-applet-gui 1 root 16 0 3356 560 480 s 0.0 0.2 00:00.9 init 2 root 34 19 0 0 0 s 0.0 0 00:00.0 ksoftirqd/0 3 root 5 -10 0 0 0 s 0.0 0 00:00.7 events/0 4 root 5 -10 0 0 0 s 0.0 0 00:00.0 khelper 5 root 15 -10 0 0 0 s 0.0 0 00:00.0 kacpid 18 root 5 -10 0 0 0 s 0.0 0 00:00.0 kblockd/0 28 root 15 0 0 0 0 s 0.0 0 00:00.0 pdflush 29 root 15 0 0 0 0 s 0.0 0 00:00.3 pdflush 31 root 13 -10 0 0 0 s 0.0 0 00:00.0 aio/0 19 root 15 0 0 0 0 s 0.0 0 00:00.0 khubd 30 root 15 0 0 0 3 s 0.0 0 00:00.2 kswapdO 187 root 6 -10 0 0 0 s 0 0 00:00.0 kmirrord/0 196 root 15 0 0 0 0 s 0 0 00:01.3 kjournald По умолчанию эта информация обновляется каждые десять секунд. Наиболее актив- ные процессы отображаются первыми. Команда top позволяет также посылать процес- сам сигналы и использовать команду renice, чтобы пользователь мог наблюдать за тем, как его действия влияют на общее состояние системы.
178 Часть I. Основы администрирования Пользователь root может запустить команду top с опцией -q, чтобы обеспечить ей максимально возможный приоритет. Это очень удобно, если нужно обнаружить про- цесс, который существенно замедлил работу системы. 5.9. Файловая система /proc Версии команд ps и top, используемые в Linux, считывают информацию о состоя- нии процессов из каталога /ргос — псевдофайловой системы, в которой ядро помещает большой объем интересной информации о состоянии системы. Несмотря на имя /ргос (и имя базового типа файловой системы — “ргос”), хранящаяся в этом каталоге инфор- мация не ограничивается одними лишь процессами — здесь хранится вся информация о состоянии и статистические сведения, генерируемые ядром. Некоторые параметры можно даже изменять, записывая новые значения в соответствующий файл каталога /ргос, — ряд примеров приведен в разделе 13.3. Хотя некоторую информацию проще получать с помощью таких интерфейсных ко- манд, как vmstat и ps, некоторую менее популярную информацию придется считывать непосредственно из каталога /ргос. Поэтому имеет смысл просмотреть его, чтобы озна- комиться со всеми помещенными в него файлами. Команда man ргос позволяет озна- комиться с рядом полезных советов и приемов. Поскольку ядро создает содержимое файлов каталога /ргос на лету (во время их счи- тывания), большинство из них выглядят пустыми при их открытии с помощью команды Is -1. Для просмотра действительного содержимого этих файлов придется прибегнуть к командам cat или more. Но будьте осторожны: некоторые файлы содержат двоичные данные либо ссылаются на двоичные данные, непосредственный просмотр которых мо- жет поставить в тупик эмулятор терминала. Информация, относящаяся к конкретным процессам, распределена по подкаталогам, названным по идентификаторам процессов. Например, каталог /ргос/1 всегда содер- жит информацию о демоне init. Наиболее полезные файлы с информацией о процес- сах перечислены в табл. 5.7. Таблица 5.7. Файлы с информацией о процессах каталога /ргос __________ (нумерованные подкаталоги) Файл Содержимое ; ? - л / 4 ' ‘ ........... - cmd Команда или программа, выполняемая процессом cmdlinea Полная командная строка процесса (разделенная нулями) cwd Символьная ссылка на текущий каталог процесса environ Переменные среды процесса (разделенные нулями) ехе Символьная ссылка на файл, который должен выполняться f d Подкаталог, содержащий ссылки на дескрипторы каждого открытого файла maps Информация отображения памяти (сегменты совместного использования, библиотеки и т.п.) root Символьная ссылка на корневой каталог процесса (определенный командой chroot) stat Информация об общем состоянии процесса (для ее получения лучше всего использовать команду ps) statm Информация об использовании памяти а Может быть недоступна, если запись информации о процессе выполняется из памяти.
Глава 5. Управление процессами 179 Отдельные компоненты внутри файлов cmdline и environ разделены символами нуля, а не символами перевода строки. Для того чтобы их содержимое было более чита- бельным, его можно фильтровать с помощью команды tr "00" "п". В подкаталоге fd открытые файлы представлены символьными ссылками. Дескрип- торы файлов, которые связаны с каналами или сетевыми сокетами, не имеют связанных с ними имен файлов. Вместо этого в качестве целевой ссылки ядро предоставляет обоб- щенное описание. Файл maps полезен при определении библиотек, с которыми связана или от которых зависит та или иная программа. • В системах Solaris и AIX также используется файловая система на основе ка- талога /ргос, но она не включает дополнительные данные о состоянии си- стемы и статистические сведения, генерируемые ядром (как в Linux). Группа SOLdriS инструментов, именуемая утилитами ргос, отображает некоторую полезную информацию о выполнении процессов. Например, команда procsig в AIX и ее Solaris-эквивалент psig выводят список сигналов для заданного процесса (сигнальные действия и обработчики сигналов). Самые полезные утилиты ргос и их функции приведены в табл. 5.8. Таблица 5.8. Команды чтения /ргос-информации в системах AIX и Solaris ЖЖ2 77"— pored [pid | pid] proccred [pid] Выводит/устанавливает реальный, текущий и со- храненный идентификаторы pldd [-F] [pid | pid] procldd [pid] Отображает библиотеки, связанные с процессом (подобно idd) psig [pid] procsig [pid] Перечисляет сигнальные действия и обработчики pfiles [pid] procfiles [pid] Выводит открытые файлы pwdx [pid] procwdx [pid] Выводит текущий рабочий каталог pwait [pid] procwait [pid] Ожидает завершения процесса а В Solaris некоторые proc-утилиты (это, в основном, инструменты отладки) принимают в качестве входных данных файл core. В системе HP-UX не используется файловая система /ргос или ее эквива- лент. 5.10. Отслеживание сигналов и системных вызовов: команды strace, truss и tusc Иногда определение действий, действительно выполняемых данным процессом, мо- жет быть затруднительным. Умозаключение приходится делать на основе косвенных дан- ных, полученных от файловой системы и с помощью таких средств, как программа ps. Linux позволяет непосредственно следить за процессом с помощью команды strace, которая отображает каждый системный вызов, выполняемый процессом, и каждый по- лучаемый им сигнал. Аналогичной командой для систем Solaris и AIX является команда truss. В HP-UX эквивалентом служит команда tusc, при этом утилиту tusc необходи- мо инсталлировать отдельно.
180 Часть I. Основы администрирования Эту команду можно даже связать с выполняемым процессом, последить за ним в те- чение некоторого времени, а затем отключиться от процесса, не прерывая его9. Хотя системные вызовы выполняются на сравнительно низком уровне абстракции, обыч- но вывод команды s trace позволяет получить достаточно полную информацию об ак- тивности процесса. Например, следующий журнал был получен в результате выполне- ния команды strace применительно к активной копии команды top. redhat$ sudo strace -p 5810 gettimeofday( {1116193814, 213881}, {300, 0} ) =0 open (’’/proc”, O_RDONLY | O_NONBLOCK | O_LARGEFILE | O_DIRECTORY) = 7 fstat64(7, {st_mode=S_IFDIR|0555, st_size=0, ...} ) =0 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 getdents64(7, /* 36 entries */, 1024) = 1016 getdents64(7, /* 39 entries */, 1024) = 1016 stat64("/proc/1”, {st_mode=S_IFDIR|0555, st_size=0, ...} ) =0 open("/proc/l/stat", O_RDONLY) = 8 read(8, "1 (init) S 0 0 0 0 -1 4194560 73’’..., 1023) = 191 close(8) . = 0 Команда s trace не только отображает имя каждого системного вызова, выполнен- ного процессом, но и раскрывает аргументы и отображает результирующий код, возвра- щенный ядром. Команда strace снабжена флагами, которые описаны в соответствующей man-стра- нице. Например, флаг -f используется для разветвленных процессов, и его полезно при- менять для отслеживания демонов (например, httpd), которые порождают множество дочерних процессов. Опция -е позволяет отображать только файловые операции, что особенно удобно для определения местоположения “неуловимых” файлов конфигурации. В этом примере команда top начинает свою работу с проверки текущего значения времени. Затем она открывает каталог /ргос и считывает его содержимое, тем самым получая список процессов, выполняемых в текущий момент. Команда top обраща- ется к статической копии каталога, представляющей процесс init, а затем открывает /ргос/1/stat, чтобы прочесть информацию о состоянии этого процесса. Вот даже более простой пример (применительно к команде date) использования ко- манды truss в системе Solaris. solaris$ truss date time() = 1242507670 brk(0x00024D30) = 0 brk(0x00026D30) = 0 open("/usr/share/lib/zoneinfo/US/Mountain”, O_RDONLY) = 3 fstat64 (3, OxFFBFFAFO) = 0 read(3, ’’ T Z i f”. ., 877) = 877 close(3) = 0 ioctl(l, TCGETA, 0xFFBFFA94) = 0 fstat64(l, 0xFFBFF9B0) = 0 write(1, ” S a t May 16 1’’.., 29) = 29 Sat May 16 14:56:46 MDT 2009 _exit (0) 9 По крайней мере, как правило. Команда strace может прерывать системные вызовы. В этих :лучаях отслеживаемый процесс должен быть подготовлен для повторного запуска этих вызовов. Гаково стандартное правило выполнения программ в среде UNIX, но оно не всегда соблюдается.
Глава 5. Управление процессами 181 Здесь после вывода информации о распределении памяти и библиотечных зависимо- стях (не показана), команда date использует системный вызов time для считывания си- стемного времени, открывает файл, соответствующий часовому поясу для определения нужного смещения, и выводит отметку даты и времени с помощью системного вызова write. 5.11. Процессы, вышедшие из-под контроля Ш Об обработке неуправляемых процессов рассказывается также в разделе 29.5. Неуправляемые процессы бывают двух видов: пользовательские, потребляющие слиш- ком много системных ресурсов (например, времени центрального процессора или диско- вого пространства), и системные, которые внезапно выходят из-под контроля и начи- нают вести себя непредсказуемо. Процесс первого вида может быть вполне работоспо- собным, просто он некорректно обращается с ресурсами. В то же время системные про- цессы всегда должны подчиняться определенным правилам. Процессы, занимающие слишком много времени центрального процессора, можно выявить, проанализировав результаты работы команды ps или top. Если очевидно, что пользовательский процесс потребляет больше ресурсов, чем ему действительно необхо- димо, его нужно исследовать. Кроме того, полезно выяснить номер процесса, ожидаю- щего выполнения. Используйте команду uptime, которая (помимо текущего времени и времени, отработанного системой) показывает число пользователей в системе и сред- нюю загруженность системы за последние 1, 5 и 15 минут. Прежде чем принимать к проблемному процессу серьезные меры, необходимо по- нять, какие действия он (этот процесс) старается выполнить. Это стоит сделать по двум причинам. Во-первых, процесс может быть вполне законным и действительно важным для пользователя. Нельзя же уничтожать процесс только из-за того, что он занимает много времени центрального процессора. Во-вторых, процесс может нести угрозу си- стеме и выполнять разрушительные действия. В этом случае нужно точно узнать, что он натворил (например, взломал пароли), и устранить повреждения. Процессы, которые используют значительный объем физической оперативной памя- ти, могут существенно снижать производительность системы. Размер памяти, занимае- мый процессами, можно проверить с помощью команды top. Столбец VIRT содержит информацию об общем объеме виртуальной памяти, зарезервированной каждым про- цессом, а столбец RES — информацию о части этой памяти, которая в текущий момент времени записана в конкретные страницы памяти (“резидентный набор”). В системах Linux приложения, которые используют видеокарту (например, сервер X), получают незаслуженное обвинение”, поскольку видеопамять включается в подсчет объема ис- пользуемой памяти. Оба значения могут отражать ресурсы совместного использования, такие как библи- отеки, что теоретически может приводить к неправильной оценке реальной ситуации. Более точная информация о памяти, потребляемой процессом, содержится в столбце dATa, который по умолчанию не отображается. Для того чтобы добавить этот столбец к информации, отображаемой командой top, после ее запуска нажмите клавишу <f> и выберите столбец DATA из списка. Отображаемое в этом столбце значение представляет °бъем памяти, занимаемый сегментами данных и стека каждого процесса, поэтому оно сРавнительно специфично для отдельных процессов (оно представляет собой остаток Деления на объем сегментов памяти совместного использования). По нему можно су-
182 Часть I. Основы администрирования дить как об относительном увеличении объема используемой памяти, так и об абсолют- ном ее объеме. Результаты работы неуправляемых процессов могут заполнить всю файловую систему и вызвать, таким образом, бесчисленные проблемы. При переполнении файловой си- стемы на экран выдается множество сообщений, и попытки записать что-либо на диск тоже повлекут за собой появление сообщений об ошибках. Первое, что нужно сделать в подобной ситуации, — определить, какая именно фай- ловая система заполнена и каким файлом она заполняется в данный момент. Об ис- пользовании файловой системы можно узнать с помощью команды df -к. В выходных данных этой команды поищите файловую систему, которая заполнена на 100% или бо- лее10. Для того чтобы понять, какой каталог занимает самую большую область памяти, используйте команду du для идентифицированной файловой системы. Повторяйте вы- полнение команды du до тех пор, пока не выявите самые большие файлы. Если вы не можете определить, какие процессы используют эти файлы, попробуйте получить боль- ше информации с помощью команд fuser и Isof (подробнее об этих командах см. раз- дел 6.2). Можно приостановить все подозрительные процессы, пока не обнаружится источник проблем. Выявив “нарушителя”, удалите все созданные им файлы и не забудьте возоб- новить “дисциплинированные” процессы. В случае, если некоторый файл содержит по- лезные или очень важные данные, было бы разумно сжать его с помощью утилиты gzip и переименовать. 5.12. Рекомендуемая литература • Bovet Daniel Р. and Marko Cesati. Understanding the Linux Kernel (3rd Edition). Sebas- topol, CA: O’Reilly Media, 2006. • Mckusick, Marshall Kirk and George V. Neville-Neil. The Design and Implementation of the FreeBSD Operating System. Reading, MA: Addison-Wesley Professional, 2004. • Роберт Лав. Разработка ядра Linux, 2-е изд. (пер. с англ.: ИД “Вильямс”, 2006 г.). 5.13. Упражнения 5.1. Объясните, какая связь существует между значением UID исполняемого файла и реальным и текущим идентификаторами выполняемого процесса. Каково назна- чение текущего идентификатора процесса, помимо контроля доступа к файлам? 5.2. Предположим, что кто-то из пользователей системы запустил длительный и ресур- соемкий процесс. а) как можно было бы распознать процесс, который узурпирует ресурсы? б) вы подозреваете, что этот процесс необходим пользователю и не должен быть уничтожен. С помощью каких команд можно приостановить процесс на время проверки? в) впоследствии выясняется, что процесс запущен начальником и должен быть 10 В большинстве реализаций файловых систем часть всей памяти (около 5%) резервируется “на всякий случай”, но процессы, выполняемые от имени суперпользователя, могут “вторгаться на эту территорию”, в результате чего отчеты могут содержать показатели использования памяти, превышающие 100%.
Глава 5. Управление процессами 35 продолжен. С помощью каких команд можно возобновить выполнение задания? г) теперь предположим, что процесс должен быть уничтожен. Какой сигнал нуж- но ему послать и почему? Что если необходимо гарантированно уничтожить процесс? 5.3. Найдите программу, в которой существует “утечка памяти” (при необходимости напишите собственную программу). Проследите за работой программы с помощью команды ps или top, обращая внимание на показатели использования памяти. 5.4. ★ Напишите простой Perl-сценарий обработки вывода команды ps для определе- ния суммы значений в столбцах VSZ и RSS для процесса, выполняющегося в си- стеме. Как эти показатели соотносятся с реальным объемом физической памяти и размером раздела подкачки?
глава Файловая система Ответьте, не раздумывая, на вопрос: что из перечисленного ниже можно считать эле- ментами файловой системы? • Процессы • Аудиоустройства • Структуры данных ядра и параметры настройки • Каналы межзадачного взаимодействия Если речь идет о системах UNIX или Linux, ответ будет таков: все перечисленное выше. Ну и, конечно же, в файловую систему входят собственно файлы1. Хотя основным назначением файловой системы является упорядочение хранимых ресурсов системы (т.е. файлов), программистам не хотелось каждый раз заново изобре- тать колесо при управлении объектами других типов. Очень часто оказывалось удобным представлять такие объекты в виде элементов файловой системы. Подобный унифи- цированный подход имеет как преимущества (единый программный интерфейс, лег- кий доступ из интерпретатора команд), так и недостатки (реализация файловых систем по методу доктора Франкенштейна), но независимо от того, нравится он вам или нет, именно такой подход применяется в UNIX (а значит, и в Linux). Файловую систему можно представить состоящей из четырех основных компо- нентов: • пространство имен — методы именования объектов и организации их в виде еди- ной иерархии; 1 Точнее говоря, эти элементы представлены внутри файловой системы. В большинстве случаев файловая система служит “местом встречи” клиентов с драйверами и серверами, которые им тре- буются.
Глава 6. Файловая система 185 • API2 — набор системных вызовов для перемещения между объектами и управле- ния ими; • модель безопасности — схема защиты, сокрытия и совместного использования объектов; • реализация — программный код, который связывает логические модели с диско- вой подсистемой. £ Э Сетевая файловая система, NFS, рассматривается в главе 18. В современных ядрах систем определен абстрактный интерфейс, позволяющий рабо- тать с различными файловыми системами. Одни части файлового дерева обрабатываются традиционной дисковой подсистемой, другие — управляются специальными драйверами ядра. Например, за работу файловых систем — как сетевых (Network File System — NFS), так и общих межсетевых (Common Internet File System — CIFS), — отвечает драйвер, ко- торый перенаправляет запросы серверу, расположенному на другом компьютере. К сожалению, концептуальные границы нечетко очерчены, поэтому имеется слиш- ком много “особых” случаев. К примеру, файлы устройств позволяют программам взаи- модействовать с драйверами ядра. Они не являются файлами данных, но обрабатывают- ся файловой системой, а их характеристики записываются на диск. Еще одним усложняющим (но, в конечном счете, полезным) фактором является то, что ядро поддерживает несколько типов дисковых файловых систем. Среди наиболее перспективных на данный момент файловых систем можно назвать ext3 и ext4, которые во многих дистрибутивах являются базовыми, а также ReiserFS, JFS компании IBM, ZFS компании Sun, VxFS компании Veritas. К этому списку можно добавить и Btrfs — новую свободную файловую систему, все еще разрабатываемую при поддержке компании Oracle. Есть много реализаций файловых систем с другой семантикой, таких как FAT и NTFS (используются в Microsoft Windows) и 9660 (применяется на компакт-дисках). Linux поддерживает больше файловых систем, чем любая другая разновидность UNIX. Столь широкий выбор упрощает обмен файлами с другими системами. Организация файловой системы — очень обширная тема, которую мы рассмотрим с нескольких точек зрения. В этой главе рассказывается, где обычно хранятся файлы, и описываются характеристики файлов, а также рассматриваются ключевые команды, по- зволяющие задавать атрибуты файлов. В главе 8 структура файловой системы описыва- ется на более низком уровне. В главе 18 рассматриваются средства совместного доступа к файлам, столь часто используемые в системе Linux. Средства совместного доступа к файлам в системе Microsoft Windows рассматриваются в главе 30. При столь большом разнообразии реализаций файловых систем может показаться странным, что данная глава посвящена всего лишь одной файловой системе. Однако на отдельных реализациях можно специально не останавливаться, поскольку в боль- шинстве современных файловых систем либо предприняты попытки обеспечить более эффективное и надежное применение традиционных функциональных возможностей, либо дополнительные функциональные возможности реализованы в качестве отдель- ного слоя, работающего поверх семантики стандартной файловой системы (некоторые Файловые системы реализуют оба направления). Как бы то ни было, слишком много программных пакетов ориентировано на описанную в этой главе модель, чтобы ею мож- но пренебречь. 2 Интерфейс прикладных программ (Application Programming Interface — API) — общий термин Дла описания набора подпрограмм, организованных в виде библиотеки или совокупности библио- Тек и доступных программистам.
186 Часть I. Основы администрирования 6.1. Имена файлов и каталогов Файловая система — это единая иерархическая структура, которая начинается с ка- талога / и разветвляется, охватывая произвольное число подкаталогов. Каталог само- го верхнего уровня называется корневым. Эта моноиерархическая система отличается от используемой в Windows, где применяется понятие пространства имен, основанное на принципе деления диска на разделы. Абсолютные и относительные пути Цепочка имен каталогов, через которые необходимо пройти для доступа к заданному файлу, вместе с именем этого файла образуют путь к файлу. Путь может быть абсо- лютным (например, /tmp/foo) или относительным (например, book4/filesystem). Последние интерпретируются начиная с текущего каталога. Возможно, многие считают, что текущий каталог задается интерпретатором команд. На самом деле текущий каталог есть у каждого процесса. (Большинство процессов никогда не изменяет свои рабочие ката- логи, и поэтому они просто наследуют текущий каталог процесса, который их запустил.) Термины имя файла и путь в той или иной степени являются взаимозаменяемыми (по крайней мере, так они трактуются в данной книге). Соответственно, имя файла бы- вает полным (абсолютный путь) или сокращенным (относительный путь). Файловое де- рево может иметь произвольную глубину, однако каждый компонент имени файла дол- жен состоять не более чем из 255 символов. Существует также ограничение на длину пути, который вы можете передавать ядру в качестве аргумента системного вызова (4095 байт в Linux и 1023 байт в более старых системах). Для того чтобы получить доступ к файлу, полное имя которого превышает эти ограничения, необходимо с помощью команды cd перейти в промежуточный ката- лог, а затем воспользоваться сокращенным именем. Использование пробелов в именах файлов На имена файлов и каталогов не налагаются никакие ограничения, за исключением того, что длина имени не должна превышать заданный предел и в имя нельзя включать символы косой черты и нулевые символы. В частности, допускаются имена, содержа- щие пробелы. К сожалению, по давней традиции аргументы командной строки в систе- ме UNIX разделяются пробелами, поэтому старые программы интерпретируют пробелы в именах файлов как признак конца одного имени и начала другого. Первоначально пробелы в именах файлов применялись в основном в файловых си- стемах, используемых на компьютерах Мас и PC, но теперь они проникли и в культуру UNIX и их можно встретить в некоторых стандартных программных пакетах. По этому поводу не может быть двух мнений: административные сценарии должны быть готовы к обработке пробелов в именах файлов (не говоря уже об апострофах, звездочках и других “опасных” знаках препинания). В интерпретаторе команд и его сценариях имена с пробелами необходимо просто за- ключать в двойные кавычки. Например, команда $ less "Му excellent file.txt" будет воспринята как попытка передать программе less единый аргумент Му excellent file. txt. Отдельные пробелы можно также предварять символом обратной косой чер- ты. Функция завершения имен файлов, предоставляемая современными интерпретато- рами (обычно она связана с клавишей <ТаЪ>), позволяет это делать автоматически.
Глава 6. Файловая система 187 При написании сценариев полезным инструментом является опция -printO коман- ды find. В сочетании с опцией -0 команды xargs эта опция позволяет сочетанию ко- манд f ind/xargs работать правильно независимо от наличия пробелов в именах фай- лов. Например, команда $ find /home -type f -size +1M -printO | xargs -0 Is -1 выводит длинный ls-список всех файлов, хранящихся в логическом разделе /home, раз- мер которых превышает один мегабайт. КЛ К сожалению, система HP-UX поддерживает команду find -printO, а не xargs -0. Система AIX не поддерживает ни один из этих вариантов. Но • в любой системе вы можете инсталлировать GNU-пакет findutils, чтобы получить текущие версии команд find и xargs. (В качестве альтернативного варианта вместо команды xargs можно использовать опцию -ехес команды find, хотя она работает менее эффективно.) 6.2. Монтирование и демонтирование ФАЙЛОВОЙ СИСТЕМЫ Файловое дерево формируется из отдельных частей, называемых файловыми систе- мами, каждая из которых содержит корневой каталог и список его подкаталогов и фай- лов. Термин “файловая система” имеет, по сути, два значения. С одной стороны, это составная часть файлового дерева, а с другой — все файловое дерево и алгоритмы, с по- мощью которых ядро управляет им. Как правило, значение термина становится ясным из контекста. Большинство файловых систем представляет собой разделы диска или логические то- ма с памятью на дисках, но, как уже было сказано, файловая система может принять об- лик всего, что подчиняется определенным функциональным правилам, — сетевых фай- ловых систем, компонентов ядра, резидентных дисков и т.д. В Linux и Solaris есть даже оригинальная файловая система, позволяющая монтировать отдельные файлы, как если бы они были физическими устройствами. Это очень удобно для разработки образов фай- ловых систем, поскольку отпадает необходимость в перераспределении дисковой памяти. В большинстве случаев файловые системы присоединяются к файловому дереву с по- мощью команды mount3. Эта команда связывает каталог существующего файлового дере- ва, называемый точкой монтирования, с корневым каталогом новой файловой системы. На время монтирования доступ к прежнему содержтаюму точки монтирования становится не- возможным. Впрочем, в большинстве случаев точка монтирования — это пустой каталог. Например, команда $ sudo mount /dev/sda4 /users монтирует на устройстве /dev/hda4 файловую систему /users. По окончании монтиро- вания можно с помощью команды Is /users просмотреть содержимое файловой системы. 3 Мы говорим “в большинстве случаев”, поскольку в файловой системе ZFS (в Solaris) принят несколько другой подход к монтированию и демонтированию, не говоря уже о других аспектах администрирования файловых систем. Возможно, читатели ожидали придирчивых комментариев относительно непозволительной несовместимости в этой части систем, но структура ZFS пред- ставляет собой значительное усовершенствование, и мы с нетерпением ожидаем того дня, когда °но будет взято на вооружение другими системами. Между тем мы считаем своим долгом описы- вать файловую систему ZFS несколько обособленно. Подробнее см. раздел 8.10.
188 Часть I. Основы администрирования Список смонтированных пользователями файловых систем хранится в файле /etc/ fstab, /etc/vfstab (Solaris) или /etc/filesystems (AIX). Благодаря этому возмож- ны автоматическая проверка (с помощью команды f sck) и монтирование (с помощью команды mount) файловых систем на этапе начальной загрузки, а также выполнение коротких команд наподобие mount /usr (точное местонахождение монтируемой фай- ловой системы ищется в файле /etc/f stab). Информация, содержащаяся в этом фай- ле, служит документацией к схеме расположения файловых систем на диске. Подробнее файл fstab описан в разделе 8.9. Файловые системы демонтируются командой umount. “Занятую” файловую систему демонтировать невозможно. В ней не должно быть ни открытых файлов, ни выполняю- щихся процессов с их текущими каталогами. Если демонтируемая файловая система со- держит исполняемые программы, они не должны быть запущены. д В системе Linux предусмотрена возможность “ленивого” демонтирования (с по- мощью команды umount -1), которая удаляет файловую систему из иерархии имен, но в действительности не демонтирует ее до тех пор, пока все существу- ющие файловые ссылки не будут закрыты. Полезность этой опции достаточно спорна. Во-первых, нет никакой гарантии, что существующие ссылки когда- либо будут закрыты сами по себе, кроме того, “наполовину демонтированное” состояние файловой системы может нарушать семантическую целостность для использующих ее программ. Они могут выполнять операции чтения и записи с существующими дескрипторами файлов, но не могут открывать но- вые файлы или выполнять какие-либо другие операции файловой системы. Команда umount -f предназначена для “насильственного” демонтирования заня- той файловой системы и поддерживается во всех рассмотренных нами системах. Однако не стоит использовать ее в системах, не использующих NFS. Кроме того, она может не применяться к определенным типам файловых систем (например, для таких, как систе- мы ext3 или ext4, которые ведут системные журналы). Вместо использования команды umount -f, когда оказывается, что файловая си- стема, которую вы пытаетесь демонтировать, занята, запустите команду fuser, чтобы узнать, какие процессы работают с файловой системой. Команда fuser -с точка_ монтирования выводит идентификаторы всех процессов, обращающихся к файлам или каталогам указанной файловой системы, а также ряд буквенных кодов, которые отобра- жают природу этой активности. $ fuser -с /usr /usr: 157tm 315ctom 474tom 5049tom 84tm 496ctom 490tm 16938c 16902ctm 358ctom 484tm Буквенные коды зависят от конкретной системы. Назначение кодов ниже описано в табл. 6.1, но детали обычно не имеют большого значения; главное для нас — идентифи- каторы процессов (PID). Таблица 6.1. Коды команды fuser -с Коды Значение f ,о Процесс открыл файл для чтения или записи с В файловой системе находится текущий каталог процесса e,t Процесс в данный момент выполняет программу г В файловой системе находится корневой каталог процесса (задается с помощью команды chroot) m,s Процесс отображает в памяти файл или совместно используемую библиотеку
Глава 6. Файловая система 189 Для того чтобы в точности определить, что собой представляют эти процессы, вызови- те команду ps, передав ей список идентификаторов, о которых сообщила команда fuser. ps -fp ’’157 315 5049” UID PID PPID C STIME TTY TIME CMD root 5049 490 0 Oct 14 ? 0:00 /usr/bin/Xll/xdm root 157 1 0 Jun 27 ? 5:26 /usr/sbin/named Ip 315 1 0 Jun 27 ? 0:00 /usr/lib/lpsched Список идентификаторов взят в кавычки, чтобы интерпретатор передал его команде ps как один аргумент. В системах Linux можно избежать необходимости задания идентификаторов (PID) в команде ps, выполнив команду fuser с флагом -v. Этот вариант коман- ды генерирует более читабельный результат, который включает имя команды. $ fuser -cv /usr USER PID ACCESS COMMAND /usr root 444 .. . .m atd root 499 .. . .m sshd root 520 ... .m Ipd Буквенные коды в столбце ACCESS такие же, как в результате выполнения команды fuser -с. Более удачной альтернативой команде fuser является утилита Isof. Утилита Isof — более сложная программа, чем fuser, и, соответственно, результаты ее работы более со- держательны. Она доступна на сайте people. f reebsd. org/~abe и работает во всех на- ших примерах систем. ДВ LicncTeMenux сценарии, предназначеШШ£.для поиска конкретной инфор- мации об использовании файловых систем процессами, располагают возмож- ностью непосредственного чтения файлов, хранящихся в каталоге /ргос. Од- нако команда Isof -F, форматирующая вывод команды Isof для облегчения синтаксического анализа, — более простое и переносимое решение: Для за- проса только той информации, которая действительно необходима, следует использовать дополнительные флаги командной строки. 6.3. Организация файловой системы Файловые системы в UNIX никогда не были хорошо организованы. Одновременно используется много разных, несовместимых соглашений об именовании файлов. Во многих случаях файлы группируются по выполняемым функциям, независимо от того, как часто они изменяются. Это затрудняет обновление операционной системы. Напри- мер, каталог /etc содержит ряд файлов, которые никогда не меняются, а также полно- стью локальные файлы. Как определить, какие файлы нельзя трогать при обновлении системы? Это нужно просто знать... Несмотря на некоторые нововведения, как, например, каталог /var (в качестве ме- ста хранения системных данных), файлы систем UNIX и Linux все еще недостаточно Упорядочены. Впрочем, для всего находится место. Особенно важно не менять стандарт- ИУ10 структуру файлового дерева, поскольку программные пакеты и их инсталляционные
190 Часть I. Основы администрирования утилиты часто ищут те или иные файлы в строго определенных каталогах. А если вы по- пробуете усовершенствовать стандартную структуру, можете столкнуться с проблемами. Ш О конфигурировании ядра рассказывается в главе 13. Корневая файловая система содержит корневой каталог и минимальный набор фай- лов и подкаталогов. Файл ядра находится в недрах корневой файловой системы, но не имеет стандартного имени или точного местоположения; в Solaris это даже не один файл, а, скорее, набор компонентов. Частью корневой файловой системы являются также каталог /etc для критических системных файлов и файлов конфигурации, каталоги /sbin и /bin — для важных ути- лит и иногда каталог /tmp — для временных файлов. Каталог /dev — это обычно ре- альный каталог, который включен в корневую файловую систему, но он (частично или полностью) может перекрываться другими файловыми системами, если ваша система виртуализировала поддержку своих устройств. (Подробнее см. в разделе 13.2.) Одни системы хранят совместно используемые библиотечные файлы и прочие важ- ные программы (например, препроцессор языка С) в каталоге /lib. Другие переместили эти элементы в каталог /usr/lib, оставив для каталога /lib роль символьной ссылки. Ш В разделе 8.6 приводятся аргументы в пользу того, зачем разбивать диск на разделы, и рассказывается, как именно это следует делать. Огромное значение имеют также каталоги /usr и /var. В первом хранится большин- ство стандартных программ и другие полезные компоненты, в частности интерактивная документация и библиотеки. Совсем не обязательно, чтобы каталог /usr был отдельной файловой системой, однако для удобства администрирования его, как правило, монти- руют именно так. Для того чтобы система могла загрузиться в многопользовательском режиме, необходимы оба каталога — /usr и /var. В каталоге /var содержатся буферные каталоги, журнальные файлы, учетная инфор- мация и прочие компоненты, специфичные для каждого компьютера. Поскольку при возникновении проблем журнальные файлы быстро разрастаются, рекомендуется поме- щать каталог /var в отдельную файловую систему. Домашние каталоги пользователей чаще всего хранятся в отдельной файловой си- стеме, которая обычно монтируется в корневом каталоге. Отдельные файловые системы можно использовать и для хранения больших информационных массивов, например би- блиотек исходных кодов программ и баз данных. Наиболее важные стандартные каталоги перечислены в табл. 6.2. Во многих системах man-страница hier (man-страница файловой системы в Solaris) содержит общие рекомендации по формированию файловой системы. Но не стоит ожи- дать, что реальная система во всех отношениях согласует свои действия с “генеральным планом”. Для получения полезной информации по данной теме советуем также обра- титься к странице Википедии “UNIX directory structure” (Структура каталогов UNIX). JS При написании стандарта Filesystem Hierarchy Standard для систем Linux (pathname. com/fhs) предпринимается попытка систематизировать и уни- фицировать стандартные каталоги, а также пояснить их назначение. Это пре- красный информационный ресурс, с которым можно сверяться при возник- новении вопросов, куда инсталлировать тот или иной компонент. Дополнительные соображения, касающиеся иерархии локальных каталогов, приве- дены в разделе 12.10.
Глава 6. Файловая система 191 Таблица 6.2. Стандартные каталоги и их содержимое Каталог OC« ‘ Содержимое* ", /bin Bee Команды операционной системы ядра6 /boot LS Ядро и файлы для его загрузки /dev Bee Файлы устройств: дисков, принтеров, псевдотерминалов и т.д. /etc Bee Важные файлы запуска и конфигурации системы /home Bee Стандартные домашние каталоги пользователей /kernel S Компоненты ядра /lib Bee Библиотеки, совместно используемые библиотеки и компоненты компилято- ра языка С /media LS Точки монтирования файловых систем на съемных носителях /mnt LSA Временные точки монтирования /opt Bee Программные пакеты необязательных приложений (которые пока не находят широкого применения) /proc LSA Информация о всех выполняющихся процессах /root LS Домашний каталог суперпользователя (часто просто /) /sbin Bee Команды, необходимые для обеспечения минимальной работоспособности системы8 /stand H Автономные утилиты, средства диагностики и форматирования дисков /tmp Bee Временные файлы, которые могут удаляться при перезагрузке /usr Bee Иерархия дополнительных файлов и программ /usr/bin Bee Большинство команд и исполняемых файлов /usr/include Bee Файлы заголовков, предназначенные для компиляции С-программ /usr/lib Bee Библиотеки и вспомогательные файлы для стандартных программ /usr/lib64 L 64-разрядные библиотеки для 64-разрядных дистрибутивов Linux /usr/local Bee Локальные программы (программы, создаваемые или устанавливаемые ло- кальным пользователем); отражает структуру каталога /usr /usr/sbin Bee Менее важные команды системного администрирования /usr/share Bee Элементы, общие для различных систем /usr/share/man Bee Страницы интерактивной документации /usr/src LSA Исходные коды нелокальных программных пакетов (не находит широкого применения) /usr/tmp Bee Дополнительный каталог для временных файлов, которые могут сохраняться при перезагрузке /var Bee Системные данные и конфигурационные файлы /var/adm Bee Разное: журнальные файлы, записи об инсталляции системы, администра- тивные компоненты /var/log LSA Системные журнальные файлы /var/spool Bee Буферные каталоги для принтеров, электронной почты и т.д. /var/tmp Bee Каталог для временного хранения файлов (после перезагрузки файлы не ис- чезают) “ L = Unux, S = Solaris, Н = HP-UX, А = AIX. в В системах HP-UX и AIX каталог /bin служит символьной ссылкой на каталог /usr/bin. отличительная особенность команд в каталоге /sbin обычно состоит в том, что они связаны со “стати- ческими” версиями системных библиотек и, следовательно, не имеют много зависимостей от других ча- стей системы.
192 Часть I. Основы администрирования 6.4. Типы ФАЙЛОВ В большинстве реализаций файловых систем определены семь типов файлов: • обычные файлы; • каталоги; • файлы байт-ориентированных (символьных) устройств; • файлы блочно-ориентированных (блочных) устройств; • локальные сокеты; • именованные каналы (реализующие принцип обслуживания FIFO (First in First Out, т.е. “первым поступил — первым обслужен”); • символические ссылки. Даже если разработчики добавляют в файловую систему что-нибудь новое и необыч- ное (например, информацию о процессах в каталог /ргос), им приходится маскировать это под файлы стандартных типов. Определить тип существующего файла можно с помощью команды Is -Id. Первый символ в строке вывода обозначает тип объекта. В следующем примере выдается инфор- мация о каталоге /usr/include. $ Is -Id /usr/include drwxr-xr-x 27 root root 4096 Jul 15 20:57 /usr/include Возможные коды для представления различных типов файлов перечислены в табл. 6.3. Таблица 6.3.Кодирование типов файлов в листинге команды 1s Тип файла Символ Создается командой Удаляется командой Обычный файл - Редакторы, ср и др. rm Каталог d mkdir rmdir, rm -r Файл символьного устройства с inknod rm Файл блочного устройства b mknod rm Локальный сокет S socket(2) rm Именованный канал Р mknod rm Символическая ссылка 1 In -s rm Как видно из табл. 6.3, команда rm является универсальным средством удаления фай- лов. Но как удалить файл, имя которого, скажем, -f? В большинстве файловых систем это абсолютно корректное имя, но команда rm -f не сделает то, что нужно, поскольку выражение -f будет воспринято как флаг команды. Выйти из положения можно, либо указав более полное имя (например, ./-f), либо воспользовавшись специальным аргу- ментом —, который сообщит команде rm о том, что остальная часть командной строки представляет собой имя файла, а не список аргументов: rm — -f. Похожая проблема возникает с файлами, в именах которых присутствуют управляю- щие символы, поскольку такие имена трудно или вообще невозможно воспроизвести с помощью клавиатуры. В подобной ситуации нужно воспользоваться метасимволами интерпретатора команд, чтобы задавать не имя целиком, а лишь его шаблон. Указывайте также опцию -i, чтобы команда rm требовала подтвердить удаление каждого файла. Это позволит не удалить нужные файлы, соответствующие шаблону. Вот как, к примеру, можно удалить файл с оригинальным именем foo<Ctrl+D>bar.
Глава 6. Файловая система $ 1S foo?bar foose kde-root $ rm -i foo* rm: remove ’foo04bar'? у rm: remove ’foose’? n Команда Is отображает вместо управляющего символа знак вопроса, что иногда сбивает с толку4. Если забыть, что символ “?” тоже является подстановочным знаком интерпретатора, и попытаться выполнить команду rm foo?bar, можно удалить более одного файла (правда, не в данном примере). Ценность флага -i очень велика! Если имена файлов совсем уж сложно набирать, прибегните к последнему средству. rm -i * Еще одна возможность удаления файлов с причудливыми именами — использование другого интерфейса файловой системы, такого как режим представления каталогов ин- терпретатора emacs или визуального средства, подобного Nautilus. Обычные файлы Обычный файл — это просто последовательность байтов. Файловые системы не на- лагают ограничения на его структуру. Текстовые документы, файлы данных, программ- ные файлы, библиотеки функций и многое другое — все это хранится в обычных фай- лах. К их содержимому возможен как последовательный, так и прямой доступ. Каталоги Каталог хранит именованные ссылки на другие файлы. Он создается командой mkdir и удаляется (при условии, что он пуст) командой rmdir. Непустые каталоги можно уда- лить командой rm -г. Специальные ссылки “. ” и “.. ” обозначают сам каталрг и его родительский каталог соответственно. Такие ссылки нельзя удалить. Посколькукорневой каталог находит- ся на вершине иерархии, ссылка “.. ” в нем эквивалентна ссылке “. ”. Имя файла в действительности хранится в родительском каталоге, а не в самом фай- ле. На файл можно ссылаться из нескольких каталогов одновременно и даже из несколь- ких элементов одного и того же каталога, причем у всех ссылок могут быть разные име- на. Это создает иллюзию того, что файл одновременно присутствует в разных каталогах. Эти дополнительные “жесткие” (фиксированные) ссылки (которые следует отличать от символических, или “мягких”) можно считать синонимами для исходных файлов, и с точки зрения файловой системы все ссылки на файл эквивалентны. Файловая система подсчитывает количество ссылок на каждый файл и при удалении файла не освобождает блоки данных до тех пор, пока не будет удалена последняя ссылка на него. Ссылки не могут указывать на файл, находящийся в другой файловой системе. Жесткие ссылки создаются командой In и удаляются командой rm. Синтаксис ко- манды In легко запомнить, поскольку она является “зеркальным отражением” команды ср. Команда ср oldfile newfile создает копию файла oldfile с именем newfile, а команда In newfile oldfile преобразует имя newfile в дополнительную ссылку на файл oldfile. 4 Команда Is -b отображает специальные символы в виде восьмеричных значений, что может пригодиться, если их нужно отдельно идентифицировать. Так символ <Ctrl+A> отображается как “1” (01 в восьмеричной системе), <Ctrl+B> — как “2” и т.д.
194 Часть I. Основы администрирования Жесткие ссылки можно создавать не только на файлы, но и на каталоги, но это де- лается довольно редко. Для того чтобы узнать, сколько ссылок существует на данный файл, используйте команду Is -1. (См. пример использования команды 1s в разделе 6.5.) Важно понимать, что жесткие ссылки не являются особым типом файлов, просто файловая система позволяет создавать несколько ссылок на один файл. Не только со- держимое, но и атрибуты файла, в частности, права доступа и идентификатор владельца, являются общими для всех ссылок. Файлы символьных и блочных устройств Ш Устройства и драйверы более подробно рассматриваются в главе 13. Файлы устройств позволяют программам получать доступ к аппаратным средствам и периферийному оборудованию системы. Ядро включает (или загружает) специальные программы (драйверы), которые во всех деталях “знают”, как взаимодействовать с каж- дым из имеющихся устройств, поэтому само ядро может оставаться относительно аб- страктным и независимым от оборудования. Драйверы устройств образуют стандартный коммуникационный интерфейс, кото- рый воспринимается пользователем как совокупность обычных файлов. Получив за- прос к файлу символьного или блочного устройства, файловая система передает этот запрос соответствующему драйверу. Важно отличать файлы устройств от драйверов этих устройств. Файлы сами по себе не являются драйверами. Их можно рассматривать как шлюзы, через которые драйвер принимает запросы. Файлы символьных устройств позволяют связанным с ними драйверам выполнять соб- ственную буферизацию ввода-вывода. Файлы блочных устройств обрабатываются драй- верами, которые осуществляют ввод-вывод большими порциями, а буферизацию вы- полняет ядро. В прошлом некоторые типы аппаратных средств могли быть представлены файлами любого типа, но в современных системах такая конфигурация встречается редко. Файлы устройств характеризуются двумя номерами: старшим и младшим. Старший номер устройства позволяет ядру определить, к какому драйверу относится файл, а младший номер, как правило, идентифицирует конкретное физическое устройство. На- пример, старший номер устройства 4 в Linux соответствует драйверу последовательного порта. Таким образом, первый последовательный порт (/dev/ttyO) будет иметь стар- ший номер 4 и младший номер 0. Драйверы могут интерпретировать переданные им младшие номера устройств как угодно. Например, драйверы накопителей на магнитных лентах с помощью этого номе- ра определяют, необходимо ли перемотать ленту после закрытия файла устройства. В далеком прошлом /dev играл роль общего каталога, а файлы устройств, которые в нем хранились, создавались с помощью команды mknod и удалялись командой rm. Стандартизировать работу по созданию файлов устройств помогал сценарий с именем MAKEDEV. К сожалению, эта “сырая” система плохо справлялась с безбрежным морем драйве- ров и типов устройств, которые появились в последние десятиления. Кроме того, она способствовала возникновению разного рода потенциальных конфигурационных несты- ковок: например, файлы устройств ссылались на несуществующие устройства, устрой- ства оказывались недоступными, поскольку они не имели файлов устройств, и т.д. В наши дни в большинстве систем реализована некоторая форма автоматического управления файлами устройств, которая позволяет системе играть более активную роль в конфигурировании собственных файлов устройств. Например, в Solaris каталоги /dev и /devices полностью виртуализированы. В дистрибутивах Linux каталог /dev являет-
Глава 6. Файловая система 195 ся стандартным, но управлением файлами внутри него занимается демон udevd. (Демон udevd создает и удаляет файлы устройств в ответ на изменения в оборудовании, о кото- рых сообщает ядро.) Подробнее о методах решения этой задачи в разных системах на- писано в главе 13. Локальные сокеты Установленные посредством сокетов соединения позволяют процессам взаимодей- ствовать, не подвергаясь влиянию других процессов. В системе UNIX поддерживается несколько видов сокетов, использование которых, как правило, предполагает наличие сети. Локальные сокеты доступны только на локальном компьютере, и обращение к ним осуществляется через специальные объекты файловой системы, а не через сетевые пор- ты. Иногда такие сокеты называют UNIX-сокетами. CQ Подробнее о системе Syslog рассказывается в главе 11. Несмотря на то что другие процессы распознают файлы сокетов как элементы ка- талога, только процессы, между которыми установлено соответствующее соединение, могут осуществлять над файлом сокета операции чтения и записи. В качестве примеров стандартных средств, использующих локальные сокеты, можно назвать системы X Win- dow и Syslog. Локальные сокеты создаются с помощью системного вызова socket. Когда с обеих сторон соединение закрыто, сокет можно удалить командой rm или с помощью систем- ного вызова unlink. Именованные каналы Подобно локальным сокетам, именованные каналы обеспечивают взаимодействие двух процессов, выполняемых на одном компьютере. Такие каналы еще называют фай- лами FIFO (First In, First Out — “первым поступил, первым обслужен”). Они создаются командой mknod и удаляются командой rm. Как и в случае локальных сокетов, реальные экземпляры именованных каналов весь- ма немногочисленны и нечасто встречаются. Они редко требуют административного вмешательства5. Именованные каналы и локальные сокеты имеют практически одинаковое назначе- ние, а их обоюдное существование сложилось исторически. Если бы системы UNIX и Linux разрабатывались в наши дни, то об этих средствах взаимодействия вопрос бы не стоял; сейчас их заменили бы сетевые сокеты. Символические ссылки Символическая, или “мягкая”, ссылка позволяет вместо имени файла указывать его псевдоним. Столкнувшись при поиске файла с символической ссылкой, ядро извлекает хранящееся в ней имя. Разница между жесткими и символическими ссылками состоит в том, что жесткая ссылка является прямой, т.е. указывает непосредственно на индексный дескриптор файла, тогда как символическая ссылка указывает на файл по имени. Файл, адресуемый символической ссылкой, и сама ссылка представляют собой разные объек- ты файловой системы. 5 По словам нашего рецензента, “программа Nagios (см. раздел 21.12) использует именованные каналы, и иногда ей необходима помощь”.
196 Часть I. Основы администрирования Символические ссылки создаются командой In -s и удаляются командой rm. Они могут содержать произвольное имя, т.е. разрешается указывать на файлы, хранящиеся в других файловых системах, и даже на несуществующие файлы. Иногда несколько сим- волических ссылок образуют петлю. Символическая ссылка может хранить как полное, так и сокращенное имя файла. Например, команда $ sudo In -s archived/secure /var/log/secure посредством относительного пути связывает имя /var/log/secure с именем /var /log/archived/secure. Как видно из следующего результата выполнения команды 1s, полученная символическая ссылка будет содержать строку “archived/secure”. $ Is -1 /var/log/secure Irwxrwxrwx 1 root root 18 2009-07-05 12:54 /var/log/secure -> archived/secure6 Каталог /var/log можно переместить куда угодно, но символическая ссылка оста- нется корректной. Часто ошибочно думают, будто первый аргумент команды In -s должен преобразо- вываться с учетом текущего каталога. На самом деле он не раскрывается командой In (как имя файла), а просто записывается в виде литеральной строки, которая становится объектом символической ссылки. 6.5. Атрибуты файлов В традиционной модели файловой системы UNIX и Linux каждому файлу соответ- ствует набор из девяти битов режима. Они определяют, какие пользователи имеют правое читать файл, записывать в него данные или запускать его на выполнение. Вместе с дру- гими тремя битами, которые в основном влияют на работу исполняемых файлов, этот набор образует код, или режим, доступа к файлу. Двенадцать битов режима хранятся вместе с четырьмя дополнительными битами, оп- ределяющими тип файла. Эти четыре бита устанавливаются при создании файла и не подлежат изменению. Биты режима могут изменяться владельцем файла или суперполь- зователем с помощью команды chmod (“change mode” — изменить режим). Просмотр значений этих битов осуществляется с помощью команды Is -1 (или Is -Id в случае каталога). Пример приведен далее в этой главе. Биты режима Девять битов режима определяют, кто и какие операции может выполнять над фай- лом. Традиционная система UNIX не позволяет устанавливать режим на уровне отдель- ного пользователя (хотя теперь списки управления доступом поддерживаются во всех основных системах). Подробнее это описано в разделе 6.6. Вместо этого три различ- ных набора битов определяют права доступа, предоставляемые владельцу файла, чле- нам группы, которой принадлежит файл, и прочим пользователям (в таком порядке). Каждый набор состоит из трех битов: бита чтения, записи и выполнения. 6 Права доступа к файлу, отображаемые командой 1s для символической ссылки Irwxrwxrwx, представляют собой фиктивные значения. Права на создание, удаление или разрешение ссылки управляются содержащим ее каталогом, в то время как права чтения, записи или выполнения для файла, указываемого ссылкой, предоставляются собственными правами целевого файла. Следо- вательно, символическая ссылка не нуждается (и не обладает) ни в какой собственной информа- ции о правах доступа.
Глава 6. Файловая система 197 Код доступа удобно записывать в виде восьмеричного числа, так как каждая цифра в нем представляется тремя битами. Три старших бита (в коде доступа им соответствуют восьмеричные значения 400, 200 и 100) служат для управления доступом к файлу его владельца. Вторые три бита (40, 20 и 10) задают доступ для членов группы. Последние три бита (4, 2 и 1) определяют доступ к файлу остальных пользователей. Старший бит каждой триады — это бит чтения, средний — бит записи, младший — бит выполнения. Каждый пользователь попадает только в одну из категорий прав доступа. В случае неоднозначности выбираются самые строгие права. Например, права владельца файла всегда определяются триадой битов владельца и никогда — битами группы. Возможна ситуация, когда другие пользователи имеют больше прав, чем владелец, но такая конфи- гурация используется редко. Для обычного файла бит чтения означает возможность открывать и читать файл. Бит записи позволяет изменять содержимое файла, в том числе полностью очищать его. Правом удаления и переименования файла управляют биты, заданные для его родитель- ского каталога, поскольку именно там хранится имя файла. Установкой бита выполнения задается разрешение запускать файл. Существует два типа исполняемых файлов: бинарные файлы, которые выполняются непосредственно центральным процессором, и сценарии, обрабатываемые интерпретатором команд или какой-нибудь другой аналогичной программой. В соответствии с принятыми соглаше- ниями, сценарии начинаются со строки примерно такого вида. #! /usr/bin/perl Здесь задается соответствующий интерпретатор. Текстовые исполняемые файлы, в кото- рых не указан конкретный интерпретатор, считаются сценариями bash или sh7. Будучи установленным для каталога, бит выполнения (в этом контексте его часто на- зывают битом поиска) разрешает переходить в каталог или проходить через него при до- ступе к файлу, но без получения списка содержимого каталога. Последнее (т.е. получе- ние списка) становится возможным, если для каталога задана комбинация битов чтения и выполнения. Комбинация битов записи и выполнения позволяет создавать, удалять и переименовывать файлы в данном каталоге. Традиционную девятибитовую модель режимов способны усложнить и переопреде- лить многие такие расширения, как списки управления доступом (см. раздел 6.6), систе- ма SELinux, т.е. Linux с улучшенной безопасностью (см. раздел 22.9), и “бонусные” биты режимов, определяемые отдельными файловыми системами (см. последний подраздел данного раздела). Если окажется, что вы не можете объяснить поведение своей фай- ловой системы, проверьте, оказывает ли на нее влияние один из перечисленных выше факторов. Биты setuid и setgid Биты, которым в коде доступа соответствуют восьмеричные значения 4000 и 2000, — это биты смены идентификатора пользователя (setuid) и идентификатора группы (setgid). Если эти биты установлены для исполняемых файлов, они позволяют про- граммам получать доступ к файлам и процессам, которые при прочих обстоятельствах недоступны пользователю, выполняющему эти программы. Подробнее этот механизм был описан в разделе 4.1. 7 Когда файл начинается с символов # /, он в первую очередь обрабатывается ядром. Но если интерпретатор команд не указан или указан неправильно, ядро откажется выполнять файл. В этом случае текущий интерпретатор предпримет вторую попытку, попытавшись выполнить сценарий в интерпретаторе sh.
198 Часть I. Основы администрирования Если бит setgid установлен для каталога, то создаваемые в нем файлы будут при- нимать идентификатор группы каталога, а не группы, в которую входит владелец фай- ла. Это упрощает пользователям, принадлежащим к одной группе, совместный доступ к каталогам. Следует также учитывать, что для исполняемого файла бит setgid имеет другое значение. Бит setgid можно устанавливать для файлов, не являющихся исполняемыми. Тем самым запрашивается специальный режим блокирования файлов при их открытии. Правда, нам не известны случаи использования этой возможности. Дополнительный бит Бит, которому в коде доступа соответствует восьмеричное значение 1000, называется дополнительным (sticky bit). В первых UNIX-системах дополнительный бит запрещал вы- грузку программ из памяти. Сегодня он утратил свое значение и, попросту, игнорируется. Если дополнительный бит установлен для каталога, то файловая система позволит удалять и переименовывать его файлы только владельцу каталога, владельцу файла или суперпользователю. Иметь одно лишь право записи в каталог недостаточно. Такая мера позволяет несколько лучше защитить каталоги вроде /tmp. Системы Solaris и HP-UX менее строги в обработке дополнительных катало- soians гов: вы можете удалить файл в дополнительном каталоге, если у вас есть на КСа него право записи (даже если вы не являетесь его владельцем). В этом дей- ствительно есть здравый смысл, но об этом отличительном нюансе не стоит забывать. Команда Is: просмотр атрибутов файла Файловая система хранит для каждого файла около сорока информационных по- лей; большая часть из них используется самой файловой системой. Администратора, в основном, интересует количество жестких ссылок, владелец, группа, код доступа, время последнего обращения и последней модификации, размер и тип файла. Всю эту инфор- мацию можно получить с помощью команды Is -1 (или команды Is -Id в случае ката- лога; без флага -d команда 1s перечисляет содержимое каталога). Для каждого файла хранится также время последнего изменения атрибутов. Тради- ционное название этого поля (“crime” от “change time” — время изменения) многих вво- дит в заблуждение, так как они полагают, что это время создания файла. На самом деле здесь зафиксировано время последнего изменения одного из атрибутов файла (владелец, код доступа и так далее), но не его содержимого. Рассмотрим пример. $ Is -1 /bin/gzip -rwxr-xr-x 3 root root 62100 May 28 2010 /bin/gzip В первом поле задается тип файла и режим доступа к нему. Поскольку первый сим- вол — дефис, значит, перед нами обычный файл (см. табл. 6.3). Следующие девять символов — это три набора битов режима. Порядок наборов та- ков: владелец, группа, другие пользователи. В листинге команды 1s биты режима пред- ставляются буквами г, w и х (чтение, запись и выполнение). В показанном примере вла- делец имеет все права доступа к файлу, а остальные пользователи — только право на чтение и выполнение.
Глава 6. Файловая система 199 Если бы был установлен бит setuid, то вместо буквы х, обозначающей право вла- дельца на выполнение, стояла бы буква s. В случае бита setgid вместо буквы х для группы тоже была бы указана буква s. Последний бит режима (право выполнения для других пользователей) представляется буквой t, когда для файла задан sticky-бит. Если бит setuid/setgid или sticky-бит установлен, а надлежащий бит выполнения — нет, эти биты представляются символами S и т, что указывает на игнорирование данных атрибутов вследствие ошибки. Второе поле листинга представляет собой счетчик ссылок на файл. В данном случае здесь стоит цифра 3, свидетельствующая о том, что /bin/gzip — одно из трех имен файла (два других — /bin/gunzip и /bin/zcat). Каждый раз при создании жесткой ссылки на файл этот счетчик увеличивается на единицу. Символические ссылки в счет- чике не учитываются. Любой каталог имеет минимум две жесткие ссылки: из родительского каталога и из специального файла “. ” внутри самого каталога. Следующие два поля определяют владельца и группу файла. В данном примере файл принадлежит пользователю root и одноименной группе. В действительности ядро хра- нит эти данные не в строковом виде, а в виде идентификаторов. Если символьные вер- сии идентификаторов определить невозможно, в этих полях будут отображаться числа. Так происходит, когда запись пользователя или группы была удалена из файла, соот- ветственно, /etc/passwd или /etc/group. Не исключено также, что возникла ошибка в базе данных NIS или LDAP (описана в главе 19), если она используется. В следующем поле отображается размер файла в байтах. Рассматриваемый файл име- ет размер 62100 байт. Далее указана дата последней модификации файла: 28 мая 2010 г. В последнем поле листинга приведено имя файла: /bin/gzip. Для файла устройства команда 1s выдает несколько иную информацию. $ Is -1 /dev/ttyO crw-rw---1 root root 4, 0 Jun 11 20:41 /dev/ttyO Большинство полей те же, но вместо размера в байтах показаны старший и младший номера устройства. Имя /dev/ttyO относится в данной системе (Red Hat) к первой виртуальной консоли, управляемой драйвером устройства 4 (драйвер терминала). При поиске жестких ссылок может пригодиться команда Is -i, отображающая для каждого файла номер его индексного дескриптора. Не вдаваясь в детали реализации файловой системы, скажем, что этот номер представляет собой индекс таблицы, в ко- торой перечислены все файлы системы. Именно на индексные дескрипторы ссылают- ся файловые записи каталогов. Жесткие ссылки, указывающие на один и тот же файл, будут иметь одинаковый номер. Для того чтобы составить представление о “паутине” ссылок, воспользуйтесь командой Is -li для определения числа ссылок и номера ин- дексного дескриптора какого-нибудь файла, а затем поищите его “двойников” с помо- щью команды find8. Другими важными опциями команды 1s являются -а, отображающая все записи в каталоге (даже те файлы, имена которых начинаются с точки), -t, выполняющая сорти- ровку файлов по времени изменения (или -tr, осуществляющая сортировку в обратном хронологическом порядке), -F, отображающая имена файлов с выделением ййталогов и исполняемых файлов, -R, выводящая рекурсивный список, и -h, которая отображает размеры файлов в удобной для человеческого восприятия форме (например, 8К или 53М). 8 Выполните команду find точка монтирования -xdev -inum индексный— де скрип- — А.
200 Часть I. Основы администрирования Команда chmod: изменение прав доступа Код доступа к файлу можно изменить с помощью команды chmod. Такое право есть лишь у владельца файла и пользователя root. В первых UNIX-системах код доступа задавался в виде восьмеричного числа. В современных версиях поддерживается также система мнемонических обозначений. Первый способ удобнее для системного админи- стратора, но при этом можно задать только абсолютное значение кода доступа. В случае использования мнемонического синтаксиса разрешается сбрасывать и устанавливать от- дельные биты режима. Первым аргументом команды chmod является спецификация прав доступа. Второй и последующий аргументы — это имена файлов, права доступа к которым подлежат измене- нию. При использовании восьмеричной формы записи первая цифра относится к владель- цу, вторая — к группе, а третья — к другим пользователям. Если необходимо задать биты setuid/setgid или дополнительный бит, следует указывать не три, а четыре восьмерич- ные цифры: первая цифра в этом случае будет соответствовать трем специальным битам. В табл. 6.4 показано восемь возможных комбинаций для каждого трехбитового набо- ра, где символы г, w и х обозначают право чтения, записи и выполнения соответственно. Таблица 6.4. Коды доступа в команде chmod Двоичное Режим . доступа Восьмеричное Двоичное Режим < доступа ' л число число 0 ООО — 4 100 г— 1 001 —X 5 101 г-х 2 010 -w- 6 110 rw- 3 011 -wx 7 111 rwx Например, команда chmod 711 myprog предоставляет владельцу все права, а осталь- ным пользователям — только право выполнения9. При использовании мнемонического синтаксиса вы объединяете множество испол- нителей (и — пользователь, g — группа или о — другой) с оператором (+ — добавить, ---удалить и = — присвоить) и набором прав доступа. Более подробное описание мне- монического синтаксиса можно найти на man-странице команды chmod, но синтаксис всегда лучше изучать на примерах. В табл. 6.5 приведено несколько примеров мнемони- ческих спецификаций. Таблица 6,5, Примеры мнемонических спецификаций команды chmod 1шйи^|щций Назначение ~J : ” —' ' ' ! ......'........>.......... .....'....,... ....... - u+w Владельцу файла дополнительно дается право записи ug=rw,o=r Владельцу и членам группы дается право чтения/записи, остальным пользователям — право чтения а-х У всех пользователей отбирается право выполнения ug=srx,o= Владельцу и членам группы дается право чтения/выполнения, устанавливаются также биты SUID и SGID; остальным пользователям запрещается доступ к файлу g=u Членам группы предоставляются такие же права, что и владельцу 9 Если файл myprog является сценарием интерпретатора команд, должно быть задано также право чтения для остальных пользователей. Файлы сценариев, запускаемые интерпретатором, от- крываются и читаются в текстовом виде, а бинарные файлы выполняются непосредственно ядром, поэтому для них не нужно задавать право чтения.
Глава 6. Файловая система 201 Символ u (“wser”) обозначает владельца файла, g (“group”) — группу, о (“others”) — других пользователей, a (“oil”) — всех пользователей. В системах Linux и OpenSolaris у существующего файла можно “заимство- soians вать” права доступа. Например, при выполнении команды Д chmod —reference=f ilea f ileb код доступа для файла f ileb будет уста- новлен таким же, как у файла f ilea. При наличии опции -R команда chmod будет рекурсивно обновлять права доступа ко всем файлам указанного каталога и его подкаталогов. Здесь удобнее всего придержи- ваться мнемонического синтаксиса, чтобы менялись только те биты, которые заданы явно. Например, команда $ chmod -R g+w mydir добавляет групповое право записи к каталогу mydir и его содержимому, не затрагивая остальные права. При установке битов выполнения будьте осторожны с выполнением команды chmod -R. Ведь применительно к каталогу и файлу бит выполнения интерпретируется по-разному. Поэтому вряд ли реальный результат выполнения команды chmod -R а-х будет соответствовать ожидаемому вами. Команды chown и chgrp: смена владельца и группы Команды chown и chgrp предназначены для изменения владельца файла и группы соответственно. Синтаксис этих команд подобен синтаксису команды chmod, за ис- ключением того, что первый аргумент содержит нового владельца или группу соот- ветственно. Для того чтобы изменить группу файла, необходимо либо быть владельцем файла и входить в назначаемую группу, либо быть пользователем root. Правила изменения вла- дельца в целом усложнились и зависят от конкретной системы. В большинстве систем предусмотрены средства настройки поведения команды chown в зависимости от выпол- няемого процесса. Как и команда chmod, команды chown и chgrp имеют флаг -R, который задает смену владельца или группы не только самого каталога, но и всех его подкаталогов и файлов. Например, последовательность команд $ sudo chown -R matt ^matt/res tore $ sudo chgrp -R staff ~matt/restore можно применить для восстановления из резервной копии владельца и группы файлов Для пользователя matt. Если вы устанавливаете домашний (исходный) каталог пользо- вателя, не следует пытаться выполнять команду chown для файлов, имена которых на- чинаются с точки. $ sudo chown -R matt ~matt/. * Дело в том, что указанному шаблону соответствует также файл ~matt/. ., поэтому бу- дет изменен владелец родительского каталога и, возможно, домашних каталогов других пользователей. Команда chown может изменить владельца файла и группу одновременно с помощью такого синтаксиса. chown пользователь:группа файл ...
202 Часть I. Основы администрирования Например: $ sudo chown -R matt:staff -matt/restore В системах Linux и Solaris этот синтаксис позволяет опустить либо элемент soians пользователь, либо элемент группа, что делает команду chgrp ненужной. Л Если вы включите в синтаксис команды двоеточие, но не укажете элемент /А группа, в команде chown будет использована стандартная группа пользова- теля. Команда umask: задание стандартных прав доступа Встроенная команда umask позволяет менять стандартный режим доступа к созда- ваемым файлам. Каждый процесс имеет собственный атрибут umask; встроенная в ин- терпретатор команда umask устанавливает собственное значение umask, которое затем наследуется выполняемыми вами командами. Значение umask задается в виде трехзначного восьмеричного числа, которое соот- ветствует аннулируемым правам доступа. При создании файла код доступа к нему уста- навливается равным разнице между величиной, которую запрашивает создающая файл программа, и значением umask. В табл. 6.6 перечислены возможные комбинации битов режима для команды umask. Таблица 6.6. Схема кодирования значения umask еричное Двоичное число ' '--Ж Режим доступа ?» . А...-л4Ж 0 000 rwx 4 100 -wx 1 001 rw- 5 101 -W- 2 010 r-x 6 110 —х 3 011 г— 7 111 — Например, команда umask 027 предоставляет все права владельцу файла, запрещает читать файл членам группы и не дает никаких прав другим пользователям. Стандартное значение umask равно, как правило, 022, т.е. право модификации файла предоставляет- ся только его владельцу. CQ О стандартных конфигурационных сценариях речь идет в главе 7. Нельзя заставить пользователей придерживаться конкретного значения umask, так как они в любой момент могут изменить его. Можно, однако, задать стандартное значе- ние umask в тех копиях файла .profile, которые предоставляются новым пользовате- лям системы. Дополнительные флаги в системе Linux В файловых системах ext2, ext3 и ext4 определен ряд вспомогательных флагов, ус- танавливая которые можно запрашивать особые режимы обработки файлов (здесь важ- но подчеркнуть слово “запрашивать”, поскольку многие флаги еще не реализованы). Например, один флаг делает файл доступным только для дополнения, а другой — недо- ступным для изменения и удаления. В связи с тем что эти флаги являются специфической особенностью файловых си- стем серии ext*, в Linux для их просмотра и изменения предназначены специальные
Глава 6. Файловая система 203 команды Isattr и chattr. В табл. 6.7 перечислены действительно реализованные фла- ги (в настоящее время в интерактивной документации описаны только около половины этих флагов). Таблица 6.7. Дополнительные флаги файловых систем ext2 и ext3 'флаг Назначение 7 7 ^'7Ж^7,. 7}^77‘7 : ~ 7,; А Никогда не обновлять время доступа (в целях повышения производительности) а Разрешить запись в файл только в режиме добавления (может устанавливаться лишь суперполь- зователем) D Включить режим синхронной записи изменений каталога d Не создавать резервные копии (команда dump будет игнорировать такой файл) i Сделать файл неизменяемым и неудаляемым (может устанавливаться лишь суперпользователем) S Включить режим синхронной записи изменений (буферизация отсутствует) Не вполне ясно, имеют ли остальные флаги, за исключением d, практическую цен- ность. Флаги а и i изначально задумывались как дополнительное средство защиты си- стемы от хакеров и злонамеренных программ. К сожалению, они лишь мешают работе полезных программ, отпугивая только тех хакеров, которые не знают о существовании команды chattr -ia. Исследования показали, что эти флаги чаще используются.сами- ми хакерами, чем для защиты от них. Особого внимания заслуживают флаги S и D. Поскольку при внесении измене- ний они заставляют немедленно записывать на диск все страницы памяти, связанные с файлом или каталогом, может показаться, будто это служит дополнительной защитой данных на случай сбоя. На самом же деле порядок выполнения операций, связанных с синхронными обновлениями, весьма необычен и, как стало известно, мешает рабо- те команды f sck. В результате процедура восстановления поврежденной файловой си- стемы усложняется, вместо того чтобы стать более надежной. Обычно лучше использо- вать возможность ведения журнала файловой системы, поддерживаемую ext3 и ext4. Опция j может вызвать запись в журнал информации об определенных файлах (правда, за счет некоторого снижения производительности системы). 6.6. Списки КОНТРОЛЯ ДОСТУПА Традиционная девятибитовая система контроля доступа (access control system — ACL) “владелец/группа/другие” позволяет решать большинство задач администрирования. Хотя ей присущи явные ограничения, она хорошо согласуется с традициями (кое-кто может сказать “с прошлыми традициями”) простоты и предсказуемости UNIX. Практически все другие операционные системы используют значительно более сложный метод управления доступом к файлам: списки управления доступом или ACL. Каждому файлу или каталогу может соответствовать список ACL, в котором перечис- лены правила установки прав доступа к данному файлу или каталогу. Каждое правило в списке ACL называется записью управления доступом (access control entry — АСЕ). В общем, запись контроля доступа идентифицирует пользователя или группу, к кото- рой она применяется, и определяет набор привилегий, которыми наделяются эти поль- зователи. Списки ACL не имеют фиксированной длины и могут содержать определения пРав множества пользователей или групп. Большинство операционных систем ограни-
204 Часть I. Основы администрирования чивает длину отдельного списка ACL, но это ограничение может быть довольно слабым (обычно 32 записи), которое достигается не часто. Более сложные системы позволяют администраторам указывать частичные наборы прав или отрицательные права, а некоторые из систем поддерживают наследование, ко- торое позволяет определять права доступа для передачи их вновь создаваемым элемен- там файловых систем. Конечно, системы ACL предоставляют больше возможностей, чем традиционная мо- дель UNIX, но они и сложнее ее на порядок как для администраторов, так и для разра- ботчиков программ. Используйте их с большой осторожностью. Они не только сложнее в использовании, но и могут порождать проблемы при использовании в сочетании с “не имеющими понятия” об ACL-списках системами резервного копирования, узлами NFS и даже такими простыми программами, как текстовые редакторы. Списки ACL тяготеют к беспорядку, и поэтому со временем они становятся непри- годными для управления. Краткий обзор развития UNIX-списков ACL В следующих разделах рассмотрим различные системы ACL, которые поддерживаются в UNIX и Linux, а также наборы команд, предназначенные для управления ими. Но сна- чала необходимо ответить на вопрос: “Как эти списки ACL превратились в катастрофу?” Обычно объект рассматривается как история политики, денег и ветвлений. В дан- ном случае базовое понимание истории помогает наложить на реальность некоторую структуру. Подкомитет POSIX впервые начал работать над ACL для UNIX в средине 1990-х годов. В первом приближении модель POSIX ACL просто расширила традиционную UNIX-систему прав доступа (rwx), чтобы удовлетворить потребности в привилегиях раз- личных пользователей и групп. К сожалению, проект POSIX не стал официальным стандартом, и рабочая группа бы- ла расформирована в 1998 году. Тем не менее некоторые компании реализовали системы POSIX ACL “на свой вкус”. Нашлись и такие компании, которые создали собственные системы ACL. Но поскольку в этой области лидер четко не обозначился, все реализации выглядели по-разному. Тем временем для систем UNIX и Linux стало практически нормой использовать файловые системы совместно с Windows, которая имеет собственные ACL-соглашения. Здесь напряжение в нашей истории возрастает, поскольку Windows создает множество функций, которых нет ни в традиционной модели UNIX, ни в ее эквиваленте POSIX ACL. Кроме того, списки ACL в системе Windows семантически более сложные; напри- мер, они позволяют использовать отрицательные права (записи с “отказом” в правах) и предусматривают усложненную схему наследования. СЗ Подробнее об NFS написано в главе 18. Архитекторы-разработчики версии 4 протокола NFS — стандартного UNIX-прото- кола по совместному использованию файлов — стремились включить в свое детище си- стемы ACL как элемент первостепенной важности. Из-за “разногласий” между UNIX и Windows и несовместимости между реализациями UNIX ACL стало очевидно, что на стороне соединения NFSv4 могут оказаться системы совершенно разных типов. Все они могут понимать “язык” NFSv4 ACL, POSIX ACL, Windows ACL или совсем не понимать системы ACL. Стандарт NFSv4 должен иметь возможность взаимодействовать с различ- ными мирами без особых сюрпризов и проблем с безопасностью.
Глава 6. Файловая система 205 В таких условиях неудивительно, что системы NFSv4 ACL являются, по сути, объеди- нением всех ранее существовавших систем. Они представляют собой строгое супермно- жество систем POSIX ACL, поэтому любая система POSIX ACL может быть представлена как NFSv4 ACL без потери информации. В то же время системы NFSv4 ACL обеспечи- вают все биты прав доступа, которые предусмотрены в системах Windows, а также имеют большинство семантических свойств Windows. Реализация списков ACL Теоретически ответственность за поддержку и функционирование систем ACL мож- но было бы переложить на ряд других компонентов операционной системы. Системы ACL могли бы быть реализованы ядром от имени всех файловых систем, отдельными файловыми системами или, может быть, такими высокоуровневыми программами, как серверы NFS и CIFS. На практике только файловые системы могут реализовать списки ACL ясно, надежно и с приемлемой производительностью. Следовательно, поддержка ACL зависит от опе- рационной системы (ОС) и файловой системы. Файловая система, которая поддержива- ет списки ACL в одной ОС, может не поддерживать их в другой или может предусматри- вать несколько другую реализацию, поддерживаемую другими командами. В UNIX стандартные системные вызовы, которые обеспечивают управление файла- ми (open, read, unlink и пр.), не создают никаких возможностей для поддержки ACL. Тем не менее они продолжают прекрасно работать в системах со списками ACL благода- ря тому, что базовые файловые системы выполняют собственные действия по контролю прав доступа. Операции, которые не разрешены релевантной системой ACL, просто не выполняются и возвращают общий код ошибки в виде “отсутствия прав доступа”. ACL-ориентированные программы для чтения или установки файловых списков ACL используют отдельный системный вызов или библиотечную утилиту. Если в операцион- ную систему добавляется ACL-поддержка, то обычно модернизируются такие распро- страненные утилиты, как 1s и ср, чтобы обеспечить хотя бы минимальную поддержку ACL (например, с помощью команды ср -р, которая должна хранить списки ACL, если таковые имеются). Кроме того, система должна добавлять новые команды или команд- ные расширения, которые бы разрешили пользователям читать и устанавливать списки ACL из командной строки. К сожалению, эти команды не стандартизированы в опера- ционных системах. Поскольку реализации списков ACL зависят от конкретной файловой системы и опе- рационные системы поддерживают несколько реализаций файловых систем, во многих системах предусматривается поддержка нескольких типов списков ACL. Даже отдельно взятая файловая система может предложить несколько вариантов ACL, как в системе JFS2 (IBM). Если возможно использование нескольких систем ACL, команды по управ- лению ими могут быть одинаковыми или различными — все зависит от конкретной си- стемы. Системная поддержка списков ACL Рассмотрим особенности поддержки списков ACL в разных системах UNIX и Linux, поскольку трудно описать эту область общими словами. • На момент написания этого раздела (2010 г.) POSIX-ориентированные ACL-сис- темы играют ведущую роль по реализации и использованию, но NFSv4 ACL про- грессируют особенно быстро и, по всей вероятности, станут стандартом де-факто.
206 Часть I. Основы администрирования В настоящее время только системы ZFS (компания Sun) и JFS2 (IBM) обладают собственной поддержкой NFS4v4 ACL. « В Linux ACL-списки в POSIX-стиле поддерживаются файловыми системами /> ReiserFS, XFS, JFS, Btrfs и семейством ext*. Обычно они отключены по умол- чанию, но с помощью команды mount с опцией -о acl их можно включить. Управлять записями POSEX ACL позволяют команды getfacl и setfacl. Системы Solaris поддерживают POSIX ACL на основе более старой файловой soians системы UFS и NFSv4 ACL на базе системы ZFS. Версии Solaris-команд 1s и chmod модифицированы для отображения и редактирования обоих типов спи- сков ACL10. В системе Solaris предусмотрены команды setfacl и getfacl, ко- торые отчасти подобны используемым в дистрибутивах Linux, но в действитель- ности они служат только для совместимости и работают лишь для POSIX ACL. ГГЯ В операционной системе HP-UX разработана собственная подсистема ACL для собственной файловой системы HFS (High-performance File System — вы- сокопроизводительная файловая система). Когда компания HP приняла VxFS (Veritas) в качестве своей главной файловой системы, она также включила под- держку ACL в стиле POSEX11. К сожалению, эти две системы ACL управля- ются различными наборами команд. Система HFS в настоящее время не име- ет большого практического значения, но команды HFS ACL остаются в си- ле для совместимости. В этой книге системы HFS ACL не рассматриваются. • В АЕХ файловая система JFS2 поддерживает собственную систему ACL, извест- ную как AIXC. Как и AIX 5.3.0, система JFS2 также поддерживает списки ACL в стиле NFSv4. В AIX используются одинаковые команды (aclget, aclput и acledit) для управления обоими типами списков ACL, а для упрощения пе- рехода из одного формата в другой используется утилита aclconvert. В этой книге системы AIXC не рассматриваются. Обзор POSIX ACL Списки POSIX ACL поддерживаются во многих файловых системах Linux и в порте файловой системы VxFS (компания HP-UX), именуемой JFS. Они также присутствуют в системе Solaris только для файловой системы UFS. Списки POSIX ACL Linux представляют собой практически простое расширение стандартной 9-битовой UNIX-модели прав доступа. Система поддерживает только права чтения, записи и выполнения. Такие дополнительные атрибуты, как setuid- и допол- нительные биты, обрабатываются исключительно традиционными битами определения режима. Списки ACL позволяют устанавливать биты rwx независимо для любой комбинации пользователей и групп. Возможный вид отдельных записей в ACL приведен в табл. 6.8. 10 Убедитесь, что в вашей переменной среды PATH путь /bin указан перед путем /usr/gnu /bin, что позволит вам получить именно Solaris-версии команд 2s и chown, а не GNU-версии. 11 Для того чтобы дезориентировать своих клиентов и держать их в покорном неведении, ком- пания HP использует стратегию “похищения” имен существующих файловых систем, применив их к запатентованным продуктам. Например, файловая система HFS компании HP была названа так специально, чтобы ее можно было легко спутать с файловой системой Hierarchical File System компании Apple, также именуемой HFS. Компания HP для своего порта VxFS выбирает название “JFS”, чтобы пользователям было трудно отличить его от имени JFS, которое выбрала компания IBM для собственной файловой системы.
Глава 6. Файловая система Таблица 6.8. Записи, которые могут встретиться в списке управления доступом Формат : 4 user::права_до ступа user:: rw- владельца файла user: имя_ поль зов а теля: права- доступа group::прав а_ доступа user: trent: rw- конкретного пользователя group:: r-х группы, которая владеет файлом group:имя_группы: права_доступа other::права_доступа mask::права_доступа group: staff: rw- конкретной группы other:: - - всех других пользователей mask:: rwx для всех, кроме владельца и других пользователей® а Иногда маски не совсем понятны; пояснения к ним даны далее в этом разделе. Пользователей и группы можно задавать именами или идентификаторами UID/GID. Точное число записей, которое может содержать список ACL, зависит от реализации файловой системы и колеблется от 25 в XFS до практически неограниченного значения в файловых системах ReiserFS и JFS. Файловые системы ext* допускают использование до 32 записей, что, вероятно, вполне оправдано с точки зрения обеспечения возможно- сти управления списком. Взаимодействие между традиционными режимами и списками ACL При использовании ACL файлы сохраняют свои исходные биты режима, но при этом автоматически поддерживается целостность атрибутов, и два набора прав доступа не мо- гут вступить в конфликт. Ниже приведен пример (используется синтаксис Linux-команд) автоматического обновления записей ACL в ответ на изменения, выполненные “старой” командой chmod. $ touch /tmp/example $ Is -1 /tmp/example -rw-rw-r— 1 garth garth 0 Jun 14 15:57 /tmp/example $ getfacl /tmp/example getfacl: Removing leading '/' from absolute path names # file: tmp/example # owner: garth # group: garth user::rw- group::rw- other::r— $ chmod 640 /tmp/example $ getfacl —omit-header /tmp/example user::rw- group::r— other::--- Эта принудительная целостность атрибутов позволяет более старым программам, ко- торые даже не подозревают о существовании ACL, достаточно успешно работать в ис- пользующей эти списки среде. Однако существует и определенная проблема. Несмотря на то что ACL-запись group:: в приведенном примере вроде и отслеживает средний набор традиционных битов режима, это не всегда так. Для того чтобы понять, в чем здесь дело, предположите, что унаследованная про- грамма очищает биты разрешения записи во всех трех наборах прав традиционного ре-
208 Часть I. Основы администрирования жима (например, chmod ugo-w файл). Понятно, что целью выполнения этой команды является запрет выполнения записи в файле кем-либо. Но что произойдет, если резуль- тирующий список ACL выглядит следующим образом? user::г— group::г— group:staff:rw- other::г— С точки зрения унаследованной программы файл выглядит неизменяемым, хотя в действительности он доступен для записи для любого члена группы staff. Подобная ситуация нежелательна. Для снижения вероятности недоразумений приняты следующие правила. • По определению записи user:: и other:: списка ACL идентичны битам режима “владелец” и “другие” традиционного режима файла. Изменение режима ведет к изменению соответствующих записей ACL и наоборот. • Во всех случаях эффективными правами доступа, предоставляемыми владельцу файла и пользователям, которые не указаны как-либо иначе, являются те, кото- рые указаны в соответствующих записях user:: и other:: списка ACL. • Если файл не имеет явно определенного списка ACL или имеет ACL, который состоит только из одной записи user: :, одной записи group: : и одной запи- си other: :, эти записи идентичны трем наборам традиционных битов режима. Именно такой случай продемонстрирован в приведенном выше примере примене- ния команды getfacl. (Подобный ACL называют минимальным, и он не требует действительной реализации в виде логически отдельного ACL.) • В более сложных списках ACL традиционные биты режима соответствуют специ- альной записи ACL, называемой “маской”, а не записи group: :. Маска ограни- чивает доступ так, что ACL может предоставлять права всем названым пользовате- лям, всем названым группам и группе, заданной по умолчанию. Иначе говоря, маска определяет верхний предел прав доступа, которые система ACL может присваивать отдельным группам и пользователям. Концептуально эта маска ана- логична команде umask, за исключением того, что маска ACL действует всегда и указы- вает предоставленные, а не отобранные права. Записи ACL для названых пользователей, названых групп и группы, заданной по умолчанию, могут содержать права доступа, от- сутствующие в маске, но ядро будет просто их игнорировать. В результате традиционные биты режима не в состоянии уменьшить права, глобаль- но предоставленные списком ACL. Более того, удаление бита из части группы традици- онного режима ведет к удалению соответствующего бита в маске ACL и, следовательно, к лишению этих прав всех пользователей, кроме владельца файла и тех, кто относится к категории “другие”. При расширении списка ACL, приведенного в предыдущем примере, для включения в него записей конкретного пользователя и группы команда setfacl автоматически определяет соответствующую маску. $ Is -1 /tmp/example -rw-r-----1 garth garth 0 Jun 14 15:57 /tmp/example $ setfacl -m user: :r,user: trent :rw, group: admin :rw /txnp/example $ Is -1 /tmp/example -r—rw-----+ 1 garth garth 0 Jun 14 15:57 /tmp/example $ getfacl —omit-header /txnp/example
Глава 6. Файловая система 209 J user::г— user:trent:rw- group::r— group:admin:rw- mask::rw- other::-- Как видите, Linux-версия команды setfacl генерирует маску, которая позволяет вступить в действие всем правам, предоставленным в списке ACL. Для определения ма- ски вручную нужно включить ее в список записей ACL, переданный команде setfacl, либо использовать опцию -п, чтобы помешать ее повторному генерированию командой setfacl. (В системе Solaris команда setfacl по умолчанию не пересчитывает запись с маской; поэтому для ее повторного генерирования используйте флаг -г.) Обратите внимание на то, что в результате выполнения второй команды Is -1 (после команды setfacl) в конце режима файла выводится знак “+”, означающий, что с ним те- перь связан реальный список ACL. Первая команда Is -1 не выводит знак “+”, посколь- ку на данный момент список ACL является “минимальным”. Другими словами, он пол- ностью описан 9-битовым режимом, и поэтому нет необходимости хранить его отдельно. Следует иметь в виду, что применение традиционной команды chmod для манипу- лирования правами доступа группы в файле, связанном с ACL, сказывается только на маске. Продолжим рассмотрение предыдущего примера. $ chmod 770 /tmp/example $ Is -1 /tmp/example -rwxrwx--+ 1 garth staff 0 Jun 14 15:57 /tmp/example $ getfacl —omit-header /tmp/example user::rwx user:trent:rw- group::r— group:admin:rw- mask::rwx other::-- В данном случае результат выполнения команды 1s вводит в заблуждение. Несмотря на обширные права, предоставленные группе, ни один из ее членов в действительно- сти не обладает правами выполнения файла на одном лишь основании принадлежности к группе. Для того чтобы предоставить это право, придется отредактировать список ACL вручную. Определение прав доступа При попытке получения процессом доступа к файлу эффективный UID сравнива- ется с UID владельца файла. Если они совпадают, права доступа определяются правами user:: в списке ACL. В противном случае, при наличии соответствия записи конкрет- ного пользователя в ACL, права определяются этой записью и маской ACL. При отсут- ствии подходящей записи конкретного пользователя файловая система пытается найти подходящую запись группы, предоставляющую запрошенные права. Эти записи также обрабатываются в сочетании с маской ACL. При отсутствии подходящей записи права Доступа определяются записью other::. Наследование списка ACL Кроме типов записей, перечисленных в табл. 6.8, списки ACL каталогов могут содер- жать записи, определенные “по умолчанию”, которые передаются спискам ACL новых
210 Часть I. Основы администрирования файлов и подкаталогов внутри них. Подкаталоги получают свои записи как в форме за- писей активного ACL, так и в форме записей, заданных по умолчанию. Следовательно, исходные заданные по умолчанию записи могут со временем распространяться по не- скольким уровням иерархии каталогов. Связь между родительским и дочерними ACL не сохраняется при копировании за- данных по умолчанию записей. Изменения в заданных по умолчанию записях родитель- ского каталога не отражаются в списках ACL существующих подкаталогов. Списки NFSv4 ACL В этом разделе рассмотрим характеристики списков NFSv4 ACL и синтаксис Solaris- команд, используемых для их установки и просмотра. Система AIX также поддерживает списки NFSv4 ACL, но для работы с ними использует другие команды (aclget, aclput, acledit и пр.). Не останавливаясь на деталях синтаксиса конкретного набора команд, сосредоточимся на теоретической основе, не зависящей от системы. Понимая основные принципы, нетрудно будет освоить соответствующие команды в интересующей вас си- стеме. С точки зрения структуры, списки NFSv4 ACL аналогичны спискам ACL в системе Windows. Основное различие между ними состоит в спецификации категории, к которой относится запись контроля прав доступа. В списках ACL обеих систем запись хранится в виде строки. Для списков Windows ACL эта строка обычно содержит идентификатор защиты Windows (Windows security identi- fier — SID), в то время как NFSv4-cTpoKa, как правило, имеет такой формат: user: имя_ пользователя или group: имя_группы. Она также может иметь один из специальных маркеров: owner®, group® или everyone®. В действительности эти “специальные” за- писи можно считать самыми популярными, поскольку они связаны с битами режима доступа, установленными для каждого файла. Такие системы, как Samba, которые разделяют файлы между системами UNIX и Win- dows, должны обеспечивать определенный способ преобразования данных между Win- dows и NFSv4. Модель прав доступа систем Windows и NFSv4 отличается большей детализацией по сравнению с традиционной UNIX-моделью “чтение-запись-выполнение”. Рассмотрим ее основные отличительные черты. • В системе NFSv4 разрешение на создание файлов в каталоге отличается от разре- шения создавать подкаталоги. • В системе NFSv4 предусмотрен отдельный бит разрешения на “добавление”. • В системе NFSv4 предусмотрены отдельные биты разрешения на чтение и запись для данных, файловых атрибутов, расширенных атрибутов и ACL. • В системе NFSv4 реализовано управление возможностью пользователей менять владельца файла посредством стандартной системы ACL. В традиционной моде- ли UNIX возможность менять владельца файла обычно имеет только суперполь- зователь. В табл. 6.9 приведены различные разрешения (права доступа), которые могут назна- чаться в системе NFSv4, а также однобуквенные коды, используемые для их представле- ния, и имена, отображаемые и принимаемые Solaris-командами 1s и chmod.
Глава 6. Файловая система 211 Таблица 6.9. Права доступа к файлам в системе NFSv4 Код Имя Права доступа *' ~ ‘‘ ~ Г read_data list_directory Чтение данных (для файла) или получение содержимого каталога (для каталога) W write_data add_file Запись данных (для файла) или создание файла (для каталога) р append_data add_subdirectory Добавление данных (для файла) или создание подкаталога (для каталога) R read_xattr Чтение именованных (“расширенных”) атрибутов W write_xattr Запись именованных (“расширенных”) атрибутов X execute Выполнение файла как программы D delete_child Удаление дочернего объекта в каталоге а read_attributes Чтение нерасширенных атрибутов А write_attributes Запись нерасширенных атрибутов d delete Удаление с read_acl Чтение списка управления доступом С write_acl Запись списка управления доступом о write_owner Изменение владельца S synchronize Синхронное завершение записи Некоторые права доступа имеют несколько имен, поскольку они представлены оди- наковым значением флага, но интерпретируются по-разному для файлов и каталогов. Этот вид перегрузки, вероятно, вам знаком из традиционных UNIX-систем управления доступом. (Например, код х в традиционной системе означает право на выполнение обычного файла и “транзитное” разрешение применительно к каталогу.) Несмотря на то что в NFSv4 модель прав доступа достаточно детализирована, от- дельные разрешения должны быть очевидны, т.е. не должны требовать дополнительных разъяснений. Разрешение “synchronize” позволяет клиенту указать, что модификации файла должны быть синхронизированы, т.е. вызовы, связанные с записью данных, не должны завершиться до тех пор, пока данные не будут реально сохранены на диске. Расширенный атрибут — это именованная часть данных, которая сохраняется вместе с файлом. Большинство современных файловых систем поддерживает такие атрибуты, хотя они пока не нашли широкого применения. В настоящее время расширенные атри- буты, в основном, используются для сохранения самих списков ACL. Однако модель прав доступа в NFSv4 предусматривает обработку списков ACL отдельно от других рас- ширенных атрибутов. Объекты NFSv4, для которых можно задавать права доступа В дополнение к обычным спецификаторам user •. имя_пользователя или group: ИМя^гРУппы9 в системе NFSv4 определено еще несколько объектов, которые могут быть Указаны в списке ACL. Самыми важными из них являются owner@, group® и everyone®, которые связаны с традиционными категориями в 9-битовой модели прав доступа. В системе NFSv4 спецификация (RFC3530) определяет еще несколько таких специ- альных объектов, как dialup® и batch®. С точки зрения системы UNIX все они немно- го странные. Насколько нам известно, их назначение — способствовать совместимости с Windows.
212 Часть I. Основы администрирования Система NFSv4 отличается от POSIX по ряду признаков. Прежде всего, тем, что NFSv4 не имеет стандартного объекта, используемого по умолчанию для управления ACL- наследованием. Вместо этого любая отдельная запись управления доступом (АСЕ) мо- жет быть помечена как передающаяся по наследству (см. ниже раздел “Наследование списков ACL”). Кроме того, система NFSv4 не использует маску для согласования прав доступа, заданных в режиме файла с помощью списка ACL. Режим, необходимый для согласования с параметрами, задаваемыми для owner@, group@ и everyone@, а также файловые системы, которые реализуют списки NFSv4 ACLs, должны сохранять эту со- вместимость при обновлении режима либо списка ACL. Определение прав доступа В системе POSEX ACL файловая система пытается сопоставить идентификатор поль- зователя с одной, но самой важной записью управления доступом. Эта запись (АСЕ) за- тем предоставляет полный набор управляющих прав для доступа к файлу. Система NFSv4 отличается тем, что АСЕ может задавать только частичный набор прав. Каждая запись NFSv4 АСЕ либо разрешает, либо запрещает доступ. Запись дей- ствует больше как маска, чем официальная спецификация всех возможных прав12. К лю- бой конкретной ситуации можно применить несколько записей АСЕ. Принимая решение о том, разрешать ли выполнение конкретной операции, фай- ловая система считывает список ACL и обрабатывает записи АСЕ до тех пор, пока все затребованные права не будут разрешены или какое-то затребованное право не будет отклонено. При этом рассматриваются только те записи АСЕ, строки которых соответ- ствуют текущему идентификатору пользователя. Файловая система может “пройти” список NFSv4 ACL до конца, не получив опреде- ленного ответа на запрос прав доступа. В этом случае стандарт NFSv4 считает получен- ный результат неопределенным, однако большинство существующих реализаций выбе- рут доступ с отказом, во-первых, потому, что такое соглашение используется в системе Windows, и, во-вторых, потому, что это — единственный вариант, который имеет смысл. Наследование списка ACL Подобно спискам POSIX ACL, списки NFSv4 ACL позволяют созданным объектам наследовать записи управления доступом от включающего их каталога. Однако система NFSv4 при небольшом выигрыше в возможностях гораздо более запутана по сравнению с POSIX. И вот почему. • Любая запись может быть отмечена как наследуемая. Признаки наследования для создаваемых подкаталогов (disinherit или d) и создаваемых файлов (file_ inherit или f) устанавливаются по отдельности. • Можно применять различные записи управления доступом для новых файлов и новых каталогов путем создания отдельных записей управления доступом в ро- дительском каталоге с соответствующими признаками. Можно также применить одну запись АСЕ ко всем новым дочерним записям (любого типа) за счет включе- ния обоих флагов d и f. 12 Помимо записей “разрешения” и “отказа”, спецификация NFSv4 также позволяет использо- вать записи “аудита” и “аварийного сигнала”, которые не оказывают влияния на вычисления прав, но являются потенциально полезными для контроля регистрации и безопасности. Точное значение этих записей зависит от конкретной реализации.
Глава 6. Файловая система 213 • С точки зрения определения прав доступа, записи управления доступом оказы- вают одинаковое влияние на родительский (исходный) каталог независимо от того, наследуемый он или нет. Если вы хотите применить запись к дочернему, но не к родительскому каталогу, включите для соответствующей записи АСЕ флаг inherit_only (i). • Новые подкаталоги обычно наследуют две копии каждой записи АСЕ: с отключен- ными флагами наследования (применяется к самому подкаталогу) и с включенным флагом inherit only (устанавливает новый подкаталог для распространения своих передаваемых по наследству записей АСЕ). Вы можете подавить создание этой второй записи АСЕ включением флага no_propagate (п) для копии записи АСЕ родительского каталога. Конечный результат состоит в том, что запись АСЕ распространяется только на прямых потомков исходного каталога. • Не путайте распространение записей управления доступом с настоящим наследо- ванием. Установка связанного с наследованием флага для записи АСЕ просто оз- начает, что данная запись АСЕ будет скопирована в новые записи. Она не создает никаких постоянных отношений между родителем и его потомком. Если вы позже измените записи АСЕ для родительского каталога, дочерние каталоги при этом не будут обновлены. Различные флаги наследования приведены в табл. 6.10. Таблица 6.10. Флаги наследования в системе NFSv4 АСЕ Код имя; f file_inherit d disinherit i inherit_only n no_propagate Распространение записи АСЕ на создаваемые файлы Распространение записи АСЕ на создаваемые подкаталоги Распространение, но не применение к текущему каталогу Распространение на новые подкаталоги, но не на их потомков Использование списков NFSv4 ACL в системе Solaris В системе Solaris поддержка списков ACL интегрирована в команды 1s и soians chmod, что является простым расширением обычных функций этих команд. Таким удачным способом поддерживаются как POSIX-, так и NFSv4-cnncKH ACL, но здесь мы демонстрируем только примеры NFSv4-cnncKOB. Конкрет- ные детали чтения или установки списков ACL зависят от используемой фай- ловой системы. При выполнении команды Is -v отображается ACL-информация для объектов фай- ловой системы. Как и в случае использования флага -1, вы должны включить флаг -d, если хотите получить список ACL для каталога; в противном случае команда Is -v ото- бразит список ACL каждого потомка каталога. Рассмотрим следующий простой (!) пример. Solaris $ mkdir /var/tmp/example solaris$ Is -dv /var/tmp/example drwxr-xr-x 2 garth staff 2 Jan 11 07:19 /var/tmp/example 0:owner@::deny 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 2:group@:add_file/write_data/add_subdirectory/append_data:deny
214 Часть I. Основы администрирования 3:group@:list_directory/read_data/execute:allow 4:everyone®:add_file/write_data/add_subdirectory/append_data/write_xattr /write_attributes/writfe_acl/write_owner:deny 5:everyone®:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow Может показаться, что создаваемый каталог получает сложный список ACL, но на самом деле это не так: список ACL — всего лишь 9-битовый код режима, отображаемый в первой строке результата, преобразуемого в формат списка ACL. Совсем не обязательно для файловой системы хранить реальный список ACL, поскольку список ACL и режим доступа эквивалентны. (Такие списки ACL получили название “тривиальных”.) Если бы каталог имел реальный список ACL, команда 1s, чтобы обозначить наличие списка ACL, отображала бы биты режима со знаком “+” в конце (например, drwxr-xr-x+). Каждое нумерованное выражение представляет одну запись управления доступом. Вот как выглядит ее формат. индекс: объект:права_доступа: флаги_наследования: тип Числа поля индекс добавляются командой 1s для порядка и не являются частью ре- ального списка ACL. Их можно использовать в последующих командах chmod для иден- тификации специальной записи АСЕ, подлежащей замене или удалению. Поле объект может занимать одно из таких ключевых слов, как owner®, group®, everyone®, или элемент в такой форме: user: имя__пользователя либо group :имя_ группы. Поле тип в записи АСЕ задает один из двух возможных вариантов: allow, т.е. “раз- решить”, или deny, т.е. “отказать”. Теоретически возможно использование вариантов alarm (аварийный сигнал) и audit (аудит), но в ZFS эти возможности не реализованы. Оба поля права_доступа и флаги_наследования представляют собой списки оп- ций, разделенные слешами. Удивительно, но команда 1s опускает поле флаги_насле- дования (и одно из двоеточий), если все эти флаги отключены, но это не касается поля права_доступа. Еще больше добавляет “тумана” тот факт, что команда 1s отображает сразу несколь- ко имен для таких битов прав доступа, как г (чтение данных/содержимого каталога), * w (запись данных/добавление файла) и р (добавление данных /подкаталога), как если бы они были отдельными элементами прав доступа. В действительности они передают файловые и каталоговые интерпретации одних и тех же битов и всегда представляют ' “объединенное” наличие или отсутствие конкретной привилегии. Эти индивидуальные особенности (с учетом использования в качестве разделителя символа двоеточия в рамках поля объект) усложняют сценариям анализ результата вы- полнения команды Is -V. Если вам необходимо организовать программную обработку списков ACL, поищите сначала библиотеку, например, такую, как модуль Solaris::ACL Perl из архива документации и программного обеспечения CPAN (Comprehensive Perl Archive Network), который существенно упростит этот процесс. В крайнем случае можно использовать результат выполнения команды Is -V (см. ее описание ниже), поскольку этот формат более подходит для анализа. С помощью команды Is -V можно получить табличное представление записей спи- ска ACL. В этом случае права доступа отображаются их однобуквенными кодами, как показано в табл. 6.9. Для каждой записи управления доступом отображены все возмож- ные биты. “Отключенные” права представлены прочерками (подобно тому, как коман- да 1s отображает традиционный режим файла).
Глава 6. Файловая система 215 Solaris $ Is -dV /var/tmp/example drwxr-xr-x 2 garth staff 2 Jan 11 07:19 /var/tmp/example owner@: --------------:-------:deny owner® : rwxp---A-W-Co-:-----: allow group® : -w-p----------:-------:deny group®: r-x-----------:-----: allow everyone® : -w-p---A-W-Co-:------: deny everyone®: r-x----a-R-c—s:------:allow Взаимодействие между списками ACL и традиционными режимами Рассмотрим некоторые аспекты преобразования режимов в списки ACL. Во-первых, обратите внимание на то, что записи group® и everyone® в приведенном выше гейме- ре отличаются друг от друга, несмотря на то что соответствующие части в коде режима (r-х) совпадают. И это не потому, что правила преобразования различны для категорий group® и everyone®; все дело в том, что определенные права доступа невозможно ре- ально экстраполировать из традиционного режима. Эти “неустановленные” биты прав доступа принимают стандартные значения благо- даря дополнениям только к записям АСЕ категории everyone®. Права доступа write_ xattr, write attributes, write_acl и write_owner всегда означают запрещенный доступ, а права read_xattr, read_attributes, read_acl и synchronize всегда раз- решены. Если вы “выведите” эти права из набора everyone®, то увидите, что оставшие- ся записи АСЕ для категории everyone® такие же, как для категории group®. Безусловно, эти “совместимые” права применяются только к тривиальным спискам ACL. Редактируя напрямую список ACL, вы можете установить биты в любой комбинации. Режим и список ACL должны оставаться совместимыми, поэтому при корректиро- вании одного из этих вариантов другой обновляется автоматически. Файловая система ZFS успешно определяет соответствующий режим для заданного списка ACL, но ее ал- горитм для генерирования и обновления списков ACL в ответ на изменения режимов остается рудиментарным. Результаты с функциональной точки зрения нельзя назвать некорректными, но они зачастую излишне детализированы, нечитабельны и с трудом поддаются интерпретации. В частности, для категорий owner®, group® и everyone® система может сгенерировать несколько наборов записей (и притом противоречивых), которые будут зависеть от порядка вычисления. Возьмите себе за правило никогда не трогать режим файла или каталога после при- менения списка ACL. В самом худшем случае с помощью команды chmod А- файл уда- лите список ACL и начните все заново. Модифицирование списков NFSv4 ACL в системе Solaris Поскольку файловая система ZFS усиливает соответствие между режимом файла и ее списком ACL, все файлы имеют по крайней мере тривиальный список ACL. (виртуаль- ный или нет). Следовательно, изменения списка ACL всегда являются обновлениями. Изменения списка ACL выполняйте с помощью команды chmod. Ее основной синтак- сис такой же, как всегда. chmod [-R] ас1_операция файл ... В табл. 6.11 приведены различные типы ACL-операций, “понимаемых” командой chmod. К сожалению, не существует ACL-аналога для инкрементного варианта команды chmod, символического синтаксиса для управления традиционными режимами. Невоз- можно добавить или удалить из записи АСЕ индивидуальные права доступа — вам при- дется заменить запись полностью.
216 Часть I. Основы администрирования Таблица 6.11. ACL-операции, принимаемые Solaris-командой chmod Операция J А- Заменяет весь список ACL его тривиальной версией, “взятой” из режима Аиндекс- Удаляет одну запись управления доступом в заданной позиции А-асе Удаляет заданную запись управления доступом в любой позиции Аиндекс=асе [, асе...] Заменяет целиком одну или несколько записей управления доступом А+асе Добавляет запись управления доступом в начало списка ACL Аиндекс+асе [, асе...] Добавляет записи управления доступом перед записью, отмеченной задан- ным значением индекс Числа поля индекс (см. табл. 6.11) показаны выше на примере команды Is -v. Это числа, которыми по порядку, начиная с нуля, нумеруются записи управления доступом. Вы можете закодировать поля асе либо именами, либо однобуквенными кодами прав доступа. Например, команда solaris$ chmod A+user:ben:С:allow /var/tmp/example предоставляет пользователю ben право редактировать список ACL для каталога /var/ txnp/example. Помните, что определение доступа — это итеративный процесс, который выполня- ется по всему списку ACL, поэтому пользователь ben сохраняет все права, которые он имел при использовании предыдущей версии списка ACL. Новая запись управления до- ступом помещается в начало списка ACL (с нулевым индексом), поэтому команда Solaris $ chmod АО- /var/tmp/example удаляет только что добавленную запись АСЕ и возвращает список ACL в исходное со- стояние. 6.7. Упражнения 6.1. Что такое атрибут umask? Задайте такое значение атрибута umask, которое запре- щало бы членам группы и рядовым пользователям доступ к создаваемым файлам. 6.2. В чем разница между жесткими и символическими ссылками? Когда предпочти- тельнее использовать ссылки того или иного типа? 6.3. ★ Какие действия необходимо выполнить в вашей системе для автоматического монтирования NTFS-раздела с локального жесткого диска? Какой будет наиболее подходящая точка монтирования для такого раздела в соответствии с соглашения- ми, действующими в вашей системе и используемыми на вашем узле? 6.4. ★ При инсталляции новой системы важно разбить жесткий диск на разделы та- ким образом, чтобы для каждой файловой системы (/var, /usr и так далее) было достаточно свободного места. Предположим, в дистрибутиве Foobar Linux исполь- зуются следующие установки: / 2 Гбайт; /var 100 Мбайт; /boot 100 Мбайт; < раздел подкачки> 2 Гбайт; /usr оставшееся свободное место.
Глава 6. Файловая система 217 6.5. Какие проблемы при такой конфигурации могут возникнуть на интенсивно экс- плуатируемом сервере? 6.6. ★ Почему рекомендуется помещать некоторые разделы (в частности, /var, /home и раздел подкачки) на отдельные диски, чтобы отделить их от файлов данных и программ? А как насчет каталога /tmp? Приведите аргументы по каждой из пе- речисленных файловых систем. 6.7. ★ Напишите сценарий, который находит все жесткие ссылки в системе. 6.8. ★ Какими командами реализуются перечисленные ниже действия? а) предоставьте владельцу файла README право чтения/записи, а остальным поль- зователям — только право чтения б) установите для файла бит setuid, не меняя текущие права доступа (и даже не просматривая их) в) отобразите содержимое текущего каталога, отсортировав список по дате по- следней модификации, причем файлы, которые редактировались последними, должны стоять в конце списка г) поменяйте группу файла shared с “user” на “friends” 6.9. ★ По соглашению каталог / tmp доступен для всех пользователей, которых забо- тит создание в нем файлов. Что мешает одному пользователю читать временные файлы другого пользователя или удалять их? Что должно удержать рассерженного пользователя от заполнения каталога / tmp ненужными файлами? Каковы были бы последствия такой атаки?
Глава добавление новых пользователей Подключение новых пользователей и удаление старых — рутинная задача в большин- стве систем. Выполнение этих задач не представляет особой сложности, но достаточно трудоемко. Большинство администраторов создают различные средства автоматизации этого процесса, а затем поручают выполнение реальной работы своему заместителю или оператору. В наши дни мы являемся свидетелями возвращения эпохи централизованных сер- веров с сотнями учетных записей, которые теперь используются наряду с распределен- ными серверами, предназначенными для обслуживания всего нескольких пользовате- лей. Администраторы должны глубоко понимать подсистему учета пользователей, чтобы уметь настраивать работу сетевых служб и надлежащим образом конфигурировать ло- кальные учетные записи. Зачастую управление учетными записями в серверах являет- ся всего лишь небольшой частью общей задачи по инициализации учетных записей для всего предприятия. Современным производственным средам необходимо иметь не просто средство до- бавления пользователей на заданные компьютеры, а инструмент для управления пользо- вателями и их бесчисленными учетными записями и паролями в вычислительной среде, т.е. систему управления учетной информацией (Identity Management System). Широко используются такие службы управления каталогами, как Active Directory (Microsoft), OpenLDAP и Fedora Directory Server, поэтому мы подробно рассмотрим, как эти системы влияют на решение задач управления учетными записями. (Как обычно, “близорукие” инструменты Microsoft плохо взаимодействуют с другими без помощи службы Active Directory. Увы!)
Глава 7. Добавление новых пользователей 219 Потребности некоторых узлов могут расширить возможности даже таких систем. Мы не намерены подробно останавливаться на коммерческих системах управления учет- ной информацией, но все же отметим несколько заслуживающих внимания вариантов. К ним, вероятно, стоит присмотреться получше, особенно в случае очень большого узла, в котором требуется соответствие определенным законам, например, HIPAA или Сарбейнза-Оксли (в США). См. раздел 7.11. Правильное управление учетными записями является залогом безопасности системы. Редко используемые учетные записи становятся главными мишенями атак злоумышлен- ников, как и те записи, пароли к которым легко подобрать. Даже если для подключения и удаления пользователей применяются автоматизированные системные утилиты, важно понимать, какие при этом происходят изменения в системе. Поэтому мы начинаем наш разговор об управлении учетными записями с рассмотрения неструктурированных фай- лов, которые необходимо модифицировать для добавления пользователей на компьютер. Затем рассмотрим автоматизированные средства, поставляемые со всеми описыва- емыми здесь примерами операционных систем, а также файлы конфигурации, управ- ляющие их поведением. Вызывает некоторое недоумение то, что во всех наших при- мерах систем инструменты управления пользователями называются useradd, userdel и usermod, хотя эти утилиты не одинаковы. (Кроме того, в системе AIX соответствие имен достигается за счет заключения в оболочку ее “родных” программ mkuser, rmuser и chuser с помощью специальных сценариев.) Стандартная команда useradd работает вполне хорошо и удовлетворяет потребно- стям большинства организаций. К сожалению, этого нельзя сказать о команде userdel. Кроме того, для добавления и удаления пользователей во многих системах исполь* зуются простые GUI-инструменты, хотя эти средства обычно не реализуют пакетный режим или усовершенствованную локализацию. Они достаточно просты, и мы считаем нецелесообразным подробно их описывать, но предоставим ссылки на документацию по каждой системе. В этой главе сосредоточимся на добавлении и удалении пользователей. Многие темы, связанные с управлением учетными записями, описаны в других главах (здесь вы найде- те соответствующие ссылки). • Подключаемые модули аутентификации (Pluggable authentication modules — РАМ) — набор библиотек, предназначенных для создания сильных паролей; опи- сан в главе 22 (см. раздел 22.5). • Хранилища паролей описаны в главе 4 (см. раздел 4.3). • О таких службах управления каталогами, как NIS и OpenLDAP, рассказывается в главе 19 (см. раздел 19.3). Отдельные комментарии по использованию службы Active Directory можно найти в главе 30 (см. раздел 30.9). • Наконец, вопросы стратегии и методики управления являются основными темами главы 32. В следующих трех разделах речь пойдет об основных файлах, используемых в систе- ме управления пользователями. 7.1. Файл /etc/passwd Файл /etc/passwd содержит список пользователей, которые известны системе. Его можно расширить или заменить службой управления каталогами, поэтому его можно считать полным и заслуживающим доверия только в автономных системах.
220 Часть I. Основы администрирования В процессе регистрации пользователя система обращается к файлу /etc/passwd в поисках идентификатора пользователя и его домашнего каталога. Каждая строка файла описывает одного пользователя и содержит семь следующих полей, разделенных двое- точиями: • регистрационное имя; • шифрованный пароль или “заполнитель” пароля (вопросы применения шифро- ванных паролей описаны далее в этом разделе); • идентификатор пользователя; • идентификатор группы по умолчанию; • поле GECOS (полное имя, номер офиса, рабочий и домашний телефоны); • домашний каталог; • регистрационная оболочка. Вот примеры правильно составленных записей файла /etc/passwd. root:х:0:0:The System,,х6096, :/:/bin/sh j1:!:100:0:Jim Lane,ECOT8-3,,:/staff/jl:/bin/sh dotty:x:101:20: :/home/dotty:/bin/tcsh Шифрованные пароли занимают второе поле, но их уже нельзя считать безопасны- ми: современные быстрые компьютеры позволяют взламывать такие пароли за считан* ные минуты. Все версии UNIX и Linux в настоящее время скрывают шифрованные па- роли, помещая их в отдельный файл, недоступный для чтения. В системах Linux, Solaris и HP-UX файл passwd в поле шифрованного пароля содержит элемент х, а в системе AIX — элемент ! или * (в системах AIX заполнитель блокирует учетную запись). В системах Linux, Solaris и HP-UX зашифрованные пароли хранятся в файле /etc/ shadow, а в системе AIX — в файле /etc/security/passwd. Форматы этих файлов раз- личны. Ш Подробнее о файле nsswitch. conf рассказывается в разделе 19.5. Если пользовательские учетные записи подлежат совместному использованию по- средством таких служб управления каталогами, как NIS или LDAP, вы можете увидеть специальные записи в файле passwd, которые начинаются с символа “+” или Эти записи сообщают системе, как интегрировать данные службы управления каталога- ми в содержимое файла /etc/passwd. Эта интеграция также может быть реализована в файле /etc/nsswitch. conf (в системе AIX это файл /etc/nscontrol. conf). В следующих разделах рассмотрим поля файла /etc/passwd более детально. Регистрационное имя Ш Подробнее о СУБД NIS можно прочитать в разделе 19.3. Регистрационные имена (называемые также именами пользователей) должны быть уникальными и, в зависимости от системы, могут иметь ограничения на длину и на- бор символов. Правила построения регистрационных имен для разных систем приведе- ны в табл. 7.1. Пользовательские имена не могут содержать двоеточия и символы новой строки, поскольку эти символы применяются в качестве разделителей полей и записей соответственно. Если у вас используется база данных NIS или NIS+, длина имени огра- ничена восемью символами независимо от операционной системы.
'лава 7. Добавление новых пользователей 221 Таблица 7.1. Правила формирования регистрационных имен Система Дймн* Набор символов Первый СИМВОЛ Linux 32а a-z0-9_- a-z_ Некоторые дистрибутивы не столь строгие Solaris 8® A-Za-z0-9+. A-Za-z Должна быть хотя бы одна строчная буква HP-UX 8 A-Za-z0-9_ A-Za-z AIX 8B POSIX; не используются пробелы, кавычки и # , = / ? Не использу- ются Все буквы не должны быть прописными; не используется пароль“с!еТаи1Г или “ALL” 1 Несмотря на то что система Linux позволяет использовать 32 символа, унаследованное программное обе- спечение (например, программы top и rsh) принимает имена, состоящие только из 8 (или еще меньшего мела) символов. 5 Это число должно увеличиться. 3 В систему AIX 5.3 (и в более поздние версии) могут быть внесены изменения; см. ниже. Изначально в системах UNIX допустимый диапазон ограничивался алфавитно- цифровыми символами, а длина имени не должна была превышать 8 символов. По- скольку правила в различных системах, как правило, разные, рекомендуется придер- живаться наиболее строгих ограничений. Это дает возможность избежать конфликтов со старыми программами, а также использовать одно и то же регистрационное имя на любом компьютере. Считается повсеместно приемлемой комбинация из восьми (или меньше) строчных букв, цифр и символов подчеркивания. Регистрационные имена могут включать как строчные, так и прописные буквы. Однако документ RFC822 призывает не обращать внимания на регистр букв в адресах электронной почты. Смешение регистров в именах не приводит к возникновению про- блем, но имена, состоящие из строчных букв, считаются традиционными, к тому же их проще вводить. Проблемы обязательно возникнут при использовании почтовой службы, если, например, такие регистрационные имена, как john и John, будут принадлежать различным людям. Следует выбирать такие регистрационные имена, которые легко запомнить, поэтому имя, состоящее из случайной последовательности букв, является не самым удачным ва- риантом. Избегайте также кличек и прозвищ, даже если они допустимы в вашей органи- зации: имена типа DarkLord или QTPie часто включаются в адреса электронной почты (например, перед частью адреса @hotmail. com), так что не забывайте о самоуважении. Поскольку регистрационные имена часто используются в адресах электронной по- чты, полезно определить стандартную процедуру их формирования. Пользователям должна быть предоставлена возможность делать обоснованные предположения о реги- страционных именах друг друга. Имена, фамилии, инициалы и сочетания этих элемен- тов — вот приемлемые варианты для схем формирования имен. Любая жестко заданная схема в конечном счете приводит к появлению дубликатов или слишком длинных имен, поэтому иногда придется делать исключения. Выберите стандартный способ разрешения конфликтов, добавив, например, в конец имени циф- ру. В случае появления длинного имени можно использовать предоставляемую почтовой системой функцию определения псевдонимов, чтобы задать две версии одного и того же имени, по крайней мере, для электронной почты. В крупных организациях в адресах электронной почты часто используются полные имена (например, John. Q. PublicGmysite. com), благодаря чему регистрационные имена скрываются от внешнего мира. Это прекрасная идея, но, чтобы облегчить работу
222 Часть I. Основы администрирования администраторам, необходимо установить четкое и понятное соответствие между реги- страционными именами и реальными именами пользователей. Регистрационные имена должны быть уникальными в двух отношениях. Во-первых, необходимо, чтобы имя пользователя на всех компьютерах было одинаковым. Это удоб- но как самому пользователю, так и администратору. Во-вторых, регистрационное имя всегда должно относиться к одному и тому же лицу. Некоторые команды (например, ssh) можно настроить так, чтобы они аутентифициро- вали удаленных пользователей по регистрационным именам. Даже если адреса scott@ boulder. Colorado. edu и scott@refuge. Colorado. edu относятся к разным пользо- вателям, то в случае неправильной настройки учетных записей (со слабыми средствами защиты) оба пользователя могут при определенных обстоятельствах получить доступ к файлам друг друга, не вводя пароль. Опыт также показывает, что дублирующиеся имена сбивают с толку пользователей почтовых систем. Почтовая система различает, кому именно принадлежат имена, однако пользователи часто посылают письма не по тому адресу. CQ Почтовые псевдонимы подробно рассматриваются в разделе 20.5. Если в организации имеется глобальный файл почтовых псевдонимов, то все новые регистрационные имена должны отличаться от псевдонимов, присутствующих в этом файле. В противном случае почта будет доставляться не новому пользователю, а пользо- вателю с соответствующим псевдонимом. ©Система AIX позволяет изменить максимальную длину регистрационного имени с помощью команды chdev. Релевантное устройство в этом слу- чае называется sysO. Для получения списка стандартных атрибутов устрой- ства выполните команду Isattr -D -1 sysO. Среди них есть атрибут тах_ logname, который “отвечает” за максимальную длину регистрационных имен. Следующая команда позволит вам получить информацию только об одном этом атрибуте. aix$ Isattr -El sysO -a max_logname max_logname 9 Maximum login name length at boot time True Для того чтобы изменить значение максимальной длины имени, используйте следу- ющие команды. Изменения вступят в силу после следующей перезагрузки системы1. aix$ sudo su - aix# chdev -1 sysO -a max__logname=16 Стандартная максимальная длина имени равна девяти символам, но AIX-специ- фикация длины определяется размером буфера и поэтому должна учитывать наличие нулевого символа в качестве признака завершения строки. Следовательно, реальный стандартный максимум составляет восемь символов, а наша команда chdev устанавли- вает его равным 15 символам. Система AIX поддерживает мультибайтовые символы (для азиатских языков, напри- мер), но рекомендует не использовать их. В качестве альтернативного варианта для соз- дания имен файлов предлагается использовать переносимый POSIX-набор символов. ’ Сначала мы не смогли реализовать эти действия из-за использования программы sudo (см. раздел 4.3), ведь переменные среды, установленные командой sudo, обычно отличаются от описанных выше. Поэтому сначала необходимо выполнить команду sudo su -, а затем изменить значение атрибута. В новых версиях программы sudo (1.70 или более поздние) предусмотрен флаг -1 для корректного выхода из такой ситуации.
Глава 7. Добавление новых пользователей 223 Зашифрованный пароль Современные системы помещают в файл /etc/passwd некий заполнитель для за- шифрованного пароля, а затем во время первой регистрации предлагают пользователю ввести реальный пароль. Они также поддерживают ряд схем шифрования (помимо стан- дартного UNIX-алгоритма crypt). Зашифрованный пароль необходим для идентифика- ции формы шифрования, используемой для его генерирования. Наши примеры систем поддерживают разнообразные алгоритмы шифрования: традиционный crypt (постро- енный на базе DES), MD5, Blowfish и итеративная версия MD5, унаследованная от про- екта веб-сервера Apache. Длина пароля — это еще один важный атрибут, который часто определяется алго- ритмом шифрования. В табл. 7.2 приведены стандартные максимальные и минимальные значения длины паролей, а также системы шифрования, доступные в наших примерах систем. В некоторых системах разрешается вводить пароли произвольной длины, которые затем “молча” усекаются до действующего максимума длины (показанного в таблице). Таблица 7.2. Алгоритмы шифрования паролей и предельные значения длины паролей Система Минимум Максиму»*' М^йи... .' -2ЯЖ Linux 5 8 crypt, MD5, Blowfish3 /etc/login.defs Solaris 6 8б crypt, MD5, Blowfish, SHA256 /etc/security/policy.conf /etc/security/crypt. conf HP-UX 6В 8 crypt /usr/includfe/limits.hr AIX 0 8 crypt, MD5 (BSD), Apache Параметр для команды passwd а Blowfish — стандартный алгоритм в системах SUSE и openSUSE; большинство других систем использует алгоритм MD5. 6 Максимальная длина зависит от выбранного алгоритма. в Суперпользователь может установить пароль пользователя любой длины. г Этот файл содержит много конструкций #ifdef и поэтому его трудно прочитать и понять. Если вы решили не пользоваться системными средствами добавления пользовате- лей и для создания новой учетной записи вручную редактировать файл /etc/passwd (конечно же, с помощью редактора vipw — см. раздел 7.4), поставьте звездочку (*) или символ “х” в поле зашифрованного пароля. Звездочка воспрепятствует несанкциони- рованному использованию учетной записи до установки реального пароля. Никогда не оставляйте это поле пустым, иначе безопасность системы окажется под серьезной Угрозой, поскольку для доступа к такой учетной записи пароль не требуется. С криптографической точки зрения, алгоритм MD5 лишь немногим более устойчив, чем предыдущий стандарт DES (используемый алгоритмом crypt), зато в нем допуска- ются пароли произвольной длины. Чем длиннее пароли, тем они надежнее. Алгоритм MD5 не лишен некоторых криптографических недостатков, но вряд ли какая-нибудь за- шита может устоять против подбора пароля методом грубой силы. Сильными алгорит- мами считаются SHA256 и Blowfish. Некоторые советы по выбору паролей можно найти в разделе 22.4. Зашифрованные пароли имеют постоянную длину (34 символа в случае MD5 и 13 символов в случае DES) независимо от длины исходного пароля. Пароли шифруют- ся с добавлением случайной “примеси”, чтобы одному исходному паролю соответство- вало много зашифрованных форм. Таким образом, факт выбора пользователями оди- наковых паролей не может быть выявлен путем просмотра зашифрованных паролей.
224 Часть I. Основы администрирования Пароли MD5 легко распознать, так как они всегда начинаются с последовательности “$1$” или “$md5$”2. Пароли Blowfish начинаются с последовательности “$2а$”, а паро- ли SHA256 — с последовательности “$5$”. В системе SUSE для новых паролей в качестве стандарта принят алгортм ши- фрования Blowfish (использует префикс “$2а$”). оО В настоящее время система OpenSolaris перешла на стандарт SHA256 (с пре- фиксом хотя предыдущие версии этой системы использовали по умол- чанию алгоритм MD5. Идентификатор пользователя Идентификатор пользователя (UID) — это, как правило, 32-битовое целое число без знака, которое идентифицирует пользователя в системе. Регистрационные имена используются для удобства пользователей, а идентификаторы UID применяются (вну- тренне) программными средствами и файловой системой. Но для обеспечения совме- стимости со старыми системами рекомендуем, чтобы значение самого старшего иден- тификатора по возможности не превышало 32767 (наибольшее 16-битовое целое число со знаком). CQ Описание учетной записи суперпользователя можно найти в разделе 4.1. По определению пользователь root имеет идентификатор (UID) 0. В большинстве систем есть также псевдопользователи bin и daemon, что позволяет им быть владель- цами команд и файлов конфигурации. Как правило, такие псевдоимена помещаются в начало файла /etc/passwd, и им назначаются маленькие идентификаторы, а также фиктивный интерпретатор команд (например, /bin/false). Это не позволит кому- либо зарегистрироваться под такими псевдоименами. Чтобы зарезервировать побольше номеров для неперсонифицированных пользователей, рекомендуем присваивать реаль- ным пользователям идентификаторы, начиная с номера 500 или выше. (Желаемый диа- пазон для новых идентификаторов можно указать в файлах конфигурации для утилиты useradd.) Ш Подробнее о “пустой” учетной записи (nobody account) написано в конце раздела 18.2. Предусмотрен еще один специальный идентификатор, именуемый псевдопользо- вателем (nobody), которому обычно назначаются такие значения, как —1 или —2 (эти значения, представленные в виде целых без знака для установки поля UID, оказываются максимально большими идентификаторами). Регистрационное имя псевдопользователя используется в случае, если суперпользователь на одном компьютере пытается получить доступ к файлам, смонтированным (посредством системы NFS) с другого компьютера, который не доверяет первому. Нежелательно создавать более одной учетной записи с идентификатором 0. Может показаться удобным иметь несколько суперпользовательских записей с разными ин- терпретаторами команд и паролями, но в действительности это лишь создает дополни- тельные бреши в системе защиты и приводит к ненужным трудностям. Если несколь- ким пользователям необходимо быть администраторами, пусть они применяют утилиту sudo. 2 Последовательность “$1$” представляет собой своего рода маркер для алгоритма BSD MD5; компания Sun использует собственную реализацию MD5 с маркировочной последовательностью “$md5$”.
Глава 7. Добавление новых пользователей 225 Избегайте повторного использования идентификаторов, даже идентификаторов тех пользователей, которые уволились из организации и учетные записи которых были уда- лены. Такая мера предосторожности позволит избежать путаницы, если файлы впослед- ствии будут восстанавливаться из резервных копий, где пользователи могут быть иден- тифицированы по номерам, а не по регистрационным именам. Идентификаторы должны быть уникальными в пределах всей организации, т.е. кон- кретный идентификатор должен соответствовать одному и тому же регистрационному имени и физическому лицу на каждом компьютере. Если уникальность идентификато- ров нарушена, то в такой системе, как NFS, появятся проблемы безопасности; кроме того, это может привести в замешательство пользователей, переходящих из одной рабо- чей группы в другую. Трудно соблюдать уникальность идентификаторов, когда группы компьютеров нахо- дятся в административном подчинении разных лиц и даже организаций. Это проблема как техническая, так и концептуальная. Лучшим ее решением является создание цен- тральной базы данных или сервера каталогов, содержащих для каждого пользователя уникальную запись. Проще всего назначить каждой группе в пределах организации от- дельный диапазон идентификаторов и позволить распоряжаться им по своему усмотре- нию. В результате решится вопрос с уникальностью пользовательских идентификаторов, но останется проблема уникальности регистрационных имен. Популярным средством управления идентификаторами пользователей становится также база данных LDAP. Она кратко описана в этой главе (см. раздел 7.11), а более под- робно — в главе 19. Идентификатор группы по умолчанию Как и идентификатор пользователя (UID), идентиф^йЖГор группы (GID) является 32-битовым целым числом. Идентификатор 0 зарезервирован для группы с именем root или system. Как и в случае идентификаторов пользователей, системы используют не- сколько предопределенных групп для собственных нужд, так сказать для служебного пользования. Увы, в этом вопросе согласованности среди коллег-производителей систем не наблюдается. Например, группа bin имеет идентификатор GID, равный 1, в системах Red Hat и SUSE и GID, равный 2, — в системах Ubuntu, Solaris, HP-UX и AIX. В те далекие времена, когда компьютеры были еще дорогим удовольствием, группы были полезны для выполнения вычислений, но так, чтобы использованное вами дис- ковое пространство, секунды центрального процессора и минуты процесса регистрации оплачивал соответствующий отдел. В наши дни группы используются, в основном, для организации совместного доступа к файлам. Ш О каталогах с установленным битом setgid рассказывалось в разделе 6.5. Группы определяются в файле /etc/group, а поле идентификатора группы в файле /etc/passwd задает стандартный (“эффективный”) идентификатор на момент реги- страции пользователя в системе. Этот идентификатор не играет особой роли при опре- делении прав доступа; он используется лишь при создании новых файлов и каталогов. Новые файлы обычно включаются в эффективную группу своего владельца, но если вы хотите разделять файлы с другими участниками проектной группы, не забудьте вручную изменить для этих файлов владельца группы. При этом следует иметь в виду, что если у каталогов установлен бит set gid (02000) или файловая система смонтирована с опцией grpid, новые файлы вкл^Ьчаются в груп- пу родительского каталога.
226 Часть I. Основы администрирования Поле GECOS Это поле, в основном, используется для хранения персональной информации о каж- дом пользователе. Оно не имеет четко определенного синтаксиса. В принципе структура поля GECOS может быть произвольной, но команда finger интерпретирует разделен- ные запятыми элементы поля в следующем порядке: • полное имя (часто используется только это поле); • номер офиса и здания; • рабочий телефон; • домашний телефон. Ш О базе данных LDAP можно почитать в разделе 19.3. С помощью команды chfn можно изменять информацию, содержащуюся в поле GECOS3. Эта команда используется для ведения и обновления списка телефонных но- меров, но ею часто злоупотребляют: например, пользователь может изменить инфор- мацию так, что она станет нецензурной или некорректной. Некоторые системы можно сконфигурировать, установив определенные ограничения, а именно указать, какие поля может модифицировать команда chfn. Администраторы сетей большинства универси- тетских городков совсем отключают команду chfn. Во многих системах команда chfn “понимает” только файл /etc/passwd, поэтому, если для управления регистрационной информацией вы используете базу данных LDAP или какую-либо иную службу управле- ния каталогами, команда chfn может не работать вовсе. еВ системе AIX для команды chfn предусмотрен флаг -R модуль, который по- зволяет загрузить заданный модуль для выполнения реального обновления. Доступные модули находятся в каталоге /usr/lib/security. Среди них на- ходится модуль, отвечающий за функционирование службы LDAP. Домашний каталог Войдя в систему, пользователь попадает в свой домашний каталог. Следует иметь в виду, что если домашние каталоги смонтированы вне файловой системы, то в случае проблем с сервером или с самой сетью они могут оказаться недоступными. Если на момент регистрации этот каталог отсутствует, выводится сообщение вроде “no home directory” (домашний каталог отсутствует)4 и пользовательские данные помещаются в каталог /. Если в файле /etc/login.defs системы Linux в качестве значения поля DEFAULT HOME, в котором задается домашний каталог по умолчанию, указано значение по, продолжение регистрации пользователя будет невозможно. Регистрационная оболочка В качестве регистрационной оболочки, как правило, задается интерпретатор команд, например /bin/sh или /bin/csh, но в принципе это может быть любая программа. 3 Исключение составляет система Solaris, где команды chfn нет. Суперпользователь может из- менить информацию о пользователе с помощью команды passwd -g. 4 Это сообщение появляется при регистрации в системе через консоль или терминал, но не через экранный диспетчер, такой как xdm, gdm или kdm. В последнем случае пользователь вообще будет немедленно выведен из системы, поскольку программа-диспетчер не сможет осуществить запись в нужный каталог (например, ~/ .gnome).
Глава 7. Добавление новых пользователей 227 По умолчанию для систем UNIX используется интерпретатор sh, для систем Linux и Solaris — интерпретатор bash (GNU-версия sh), а для AIX — интерпретатор ksh (Adm s/zell). В Linux имена sh и csh являются всего лишь ссылками на bash и tcsh (усовер- шенствованный С-интерпретатор с командами редактирования) соответственно. В некоторых системах пользователи могут менять интерпретатор с помощью коман- ды chsh, но, подобно chfn, эта команда может не работать, если для управления ре- гистрационной информацией вы используете базу данных LDAP или какую-либо иную службу управления каталогами. Если вы используете файл /etc/passwd, системный ад- министратор всегда может заменить интерпретатор пользователя, отредактировав файл passwd с помощью программы vipw. Д Система Linux поддерживает команду chsh и варианты замены интерпрета- торов, перечисленные в файле /etc/shells. В системе SUSE этот список является обязательным для соблюдения, а в Red Hat в случае выбора неза- регистрированного интерпретатора будет лишь выдано предупреждение. При добавлении записей в файл /etc/shells убедитесь в том, что они содержат полные пути, поскольку команда chsh и другие программы работают только с полностью заданными именами файлов. ®В системах AIX пользователи могут заменить свои интерпретаторы с помощью команды chsh и длинного списка вариантов замены5. Файл /etc/security/ login. cfg содержит список проверенных интерпретаторов. Файл /etc/ shells включает лишь подмножество этого списка и используется только FTP-демоном in. f tpd. Многие из интерпретаторов, указанных в длинном списке, представляют собой жесткие ссылки на одни и те же двоичные файлы. HanpHM^,_sh,Jkjsh, rksh, psh и tsh (в каталогах /bin и /usr/bin) — это, по сути, одна и та же программа, которая изменяет свое поведение в зависимости от своего имени. Как и в случае с командой chfn, команда chsh принима- ет флаг -R модуль для предоставления базы данных LDAP и других служб управления каталогами. В системе Solaris только суперпользователь может заменить интерпретатор SOiariS пользователя (с помощью команды passwd -е). Список разрешенных ин- терпретаторов содержится в файле /etc/shells (который не существует по умолчанию, несмотря на наличие его man-страницы). 7.2. Файлы /etc/shadow и /etc/security/passwd Файл скрытых (теневых) паролей доступен для чтения только суперпользователю и предназначен для хранения зашифрованных паролей подальше от любопытных глаз. В нем также содержится учетная информация, которая отсутствует в исходном файле /etc/passwd. В настоящее время механизм скрытых паролей используется по умолча- нию практически во всех системах. В IBM-системах файл, в котором хранятся зашифрованные пароли, называется /etc/security/passwd, в других системах для этой цели используется файл /etc 5 Используйте команду chsec для замены файлов в каталоге /etc/security, вместо того что- бы редактировать их напрямую.
228 Часть I. Основы администрирования /shadow. Эти файлы различаются по формату. Сначала рассмотрим содержимое файла /etc/shadow. Файл shadow не включает в себя файл passwd, и последний не генерируется автома- тически при изменении файла shadow. Оба файла необходимо хранить независимо друг от друга (или использовать команду наподобие useradd для автоматического управле- ния файлами). Как и /etc/passwd, файл /etc/shadow содержит одну строку для каж- дого пользователя. Каждая строка состоит из 9 полей, разделенных двоеточиями: • регистрационное имя; • зашифрованный пароль; • дата последнего изменения пароля; • минимальное число дней между изменениями пароля; • максимальное число дней между изменениями пароля; • количество дней до истечения срока действия пароля, когда выдается предупре- ждение; • количество дней по истечении срока действия пароля, когда учетная запись анну- лируется (в Linux); количество дней до автоматического аннулирования учетной записи (в Solaris/HP-UX); • срок действия учетной записи; • зарезервированное поле, которое в настоящее время всегда пустое (за исключени- ем Solaris). Лишь первые два поля обязательно должны быть заполнены. Поля дат в файле /etc/ shadow задаются в виде числа дней (а не секунд), прошедших с 1-го января 1970 года, что не является стандартным способом вычисления времени в системах UNIX и Linux. При этом вы можете преобразовать секунды в дни с помощью такой команды. solaris$ expr 'date +%s' / 864006 Типичная запись выглядит так. millert:$md5$em5J8hL$a$iQ3pXe0sakdRaRFyy7Ppj. : 14469:0:180:14 : : : Вот более подробное описание каждого поля. • Регистрационное имя берется из файла /etc/passwd. Оно связывает записи фай- лов passwd и shadow. • Зашифрованный пароль идентичен тому, который ранее хранился в файле /etc/ passwd; отображается фиктивный пароль Solaris MD5. • Третье поле содержит дату последнего изменения пользователем своего пароля. • Это поле обычно заполняется командой passwd. • В четвертом поле задано количество дней, спустя которые пользователь сможет снова изменить пароль. Это не позволяет пользователям немедленно возвращать- ся к привычным паролям после их обязательного изменения. Такая возможность кажется нам опасной, если в течение указанного времени будет обнаружено на- рушение безопасности системы. Поэтому мы рекомендуем устанавливать данное поле равным нулю. • В пятом поле задано максимальное число дней между двумя изменениями паро- ля. С помощью этой установки администраторы заставляют пользователей менять 6 В сутках содержится 86 400 секунд: 60 х 60 х 24.
Глава 7. Добавление новых пользователей 229 свои пароли (подробнее механизм устаревания паролей описан в разделе 22.4). В системе Linux максимальное время жизни пароля определяется суммой значе- ний данного и седьмого (льготный период) полей. • В шестом поле задано количество дней, оставшихся до момента устаревания паро- ля, когда программа login должна предупреждать пользователя о необходимости сменить пароль. • Системы Solaris и HP-UX отличаются от системы Linux их интерпретацией седь- мого поля. В системе Linux седьмое поле определяет, через сколько дней после устаревания пароля отменяется учетная запись. В системах Solaris/HP-UX ситуация такова. Если пользователь не зарегистриро- вался в течение определенного числа дней, заданных в седьмом поле, учетная за- пись блокируется. Неиспользуемые учетные записи — любимая мишень хакеров, и здесь предусмотрена возможность объявить такие учетные записи устарелыми (“off the market”). Однако она действует только в том случае, если пользователь “прописан” в файле /var/adm/lastlog; те же пользователи, которые ни разу не зарегистрировались, автоматически не блокируются. Следовательно, эта функция реально не работает в сетевой среде, поскольку каждый узел имеет собственный файл lastlog. • В восьмом поле задана дата отмены учетной записи. По прошествии этой даты пользователь не сможет зарегистрироваться в системе, пока администратор не сбросит значение поля. Если поле оставлено пустым, учетная запись всегда будет активной. В системе Linux, чтобы установить поле даты истечения срока, можно использо- вать команду usermod (даты здесь должны быть в формате гггг-мм-чч). В системе Solaris команда usermod также вычисляет дни, прошедшие с 1-го января 1970 года. Даты здесь принимаются примерно в 30 форматах, которые заданы в файле /etc/ datemsk, но, увы, не в Linux-формате гггг-мм-чч. • В системах Linux и HP-UX девятое поле зарезервировано на будущее, но в систе- ме Solaris последние четыре бита используются для подсчета неудачных попыток регистрации. Теперь, когда назначение полей понятно, вернемся к рассмотренному выше примеру, millert:$md5$em5J8hL$a$iQ3pXe0sakdRaRFyy7Ppj. : 14469:0:180:14: : : В этой записи говорится о том, что пользователь millert последний раз менял свой пароль 13 августа 2009 года. Следующий раз пароль должен быть изменен через 180 дней. За две недели до этого пользователь начнет получать предупреждения о необходимости сменить пароль. Учетная запись не имеет срока действия. В системах Solaris, HP-UX и Linux с помощью утилиты pwconv можно согласовать содержимое файлов shadow и passwd. В Linux большинство параметров файла shadow берется из стандартных установок файла /etc/login. def s. Суперпользователь в системе Solaris может использовать команду passwd soiaris -f имя_пользователя, чтобы заставить пользователя изменить его (или ее) пароль во время следующей регистрации. Это средство полезно в том случае, если вы регулярно запускаете утилиту crack для выявления неудачных (не- надежных) паролей. (В Linux тот же самый флаг -f позволяет пользователям изменить информацию о себе.)
230 Часть I. Основы администрирования еВ системе AIX не используется термин “теневые пароли”, но на практике их идея успешно реализована. Зашифрованные AIX-пароли хранятся в файле /etc/security/passwd, причем их формат совершенно отличается от фор- мата файла /etc/passwd. Рассмотрим пример из исходной инсталляции си- стемы AIX, где в качестве стандартного алгоритма генерирования паролей ис- пользуется crypt7. trent: password = ulO.0aYxRx4qI lastupdate = 1224876639 flags = ADMCHG evi: password = PiIr2qOPabZ.Q lastupdate = 1235785246 flags = Формат должен быть самоочевиден. Здесь записи разделяются одной или нескольки- ми пустыми строками. Этот же формат используется для большинства AJX-файлов кон- фигурации в каталоге /etc/security при использовании имени пользователя, общего для любого управляемого или регистрируемого объекта. В системе AIX предусмотрено множество возможностей для управления всеми аспек- тами процесса регистрации (включая генерирование паролей). В некоторых случаях ре- зультат зависит от конкретного пользователя и порта (при управлении портами TTY, на которых может зарегистрироваться данный пользователь). Более подробную информа- цию можно получить, просмотрев комментарии в файлах /etc/security/login. cfg и /etc/security/user. Удобно также использовать команду pwdadm, которая дозволяет заставить пользователя изменить его пароль при следующей регистрации. 7.3. Файл /etc/group Файл /etc/group содержит имена UNIX-групп и списки членов каждой группы. Вот как выглядит фрагмент файла group из системы AIX. system: ! :0:root,pconsole,esaadmin staff: ! :1: ipsec,esaadmin,trent,ben,garth,evi bin: ! :2:root,bin sys:!:3:root,bin,sys adm: 1 :4:bin,adm nobody: ! : 4294967294:nobody,Ipd Каждая строка представляет одну группу и содержит следующие четыре поля: • имя группы; • зашифрованный пароль или заполнитель; • идентификатор группы; • список членов, разделенный запятыми (пробелов быть не должно). Как и в файле /etc/passwd, поля разделяются двоеточиями. Длина имени группы не должна превышать 8 символов из соображений совместимости, хотя во многих си- стемах такого ограничения нет. Несмотря на наличие поля пароля (с помощью кото- 7 Для новых версий дистрибутивов AIX первым в списке задач первоочередной важности не- обходимо поставить переход к более сильному алгоритму шифрования.
Глава 7. Добавление новых пользователей 231 рого пользователи могут присоединиться к группе, выполнив команду newgrp) пароль задается редко8. Пароль можно установить с помощью команды gpasswd; а его зашиф- рованная форма сохранится в файле /etc/gshadow. Групповые пароли используются довольно редко. Имена групп и их идентификаторы должны быть одинаковыми на всех компьютерах, получающих совместный доступ к файлам через систему NFS. Этого трудно достичь в гетерогенной среде, поскольку в разных операционных системах используются разные идентификаторы для одних и тех же групп. Мы считаем, что по умолчанию пользователь не должен регистрироваться как член системной группы. В некоторых системах групповое право собственности использу- ется вместе с битами прав доступа для управления характером выполнения команд. Противоречия в использовании групповых идентификаторов в различных системах соз- дают проблемы при обслуживании узлов, а именно при обновлении и инсталляции про- граммных продуктов. Если в файле /etc/passwd пользователь объявлен членом определенной группы, а в файле /etc/group — нет, пользователь все равно включается в группу. На этапе реги- страции членство в группе проверяется по обоим файлам, но лучше все же согласовы- вать их содержимое. В некоторых системах ограничивается количество групп, к которым может принад- лежать пользователь. В качестве предельного значения обычно используется число 8, но в Solaris оно сейчас равно 16, в HP-UX — 20, а в AIX и Linux ограничений нет вообще. Для того чтобы избежать конфликтов, связанных с идентификаторами стандартных групп, рекомендуем выбирать идентификаторы локальных групп начиная со значе- ния 500. Согласно традиции UNIX, новые пользователи добавляются в группу, название ко- торой отражает их категорию, например “students” или “finance”. Однако следует учи- тывать, что подобная традиция повышает вероятность доступа пользователей к файлам друг друга из-за неаккуратной установки прав. Чтобы этого избежать, рекомендуем соз- давать для каждого пользователя уникальную группу. Лучше всего выбирать одинаковое имя для пользователя и группы. Можно также выбрать одинаковый номер пользователя и группы. Утилита useradd всех выбранных в качестве примеров дистрибутивов Linux, за ис- ключением SUSE, по умолчанию помещает пользователей в персональные группы. Системы семейства UNIX по умолчанию помещают всех новых пользователей в одну и ту же группу, но их утилиты useradd также можно сконфигурировать на поддержку персональных групп. В такую персональную группу должен входить лишь сам пользователь. Если нужно позволить другим пользователям совместно работать с файлами посредством группового владения, создайте для этих целей отдельную группу. Идея персональных групп состо- ит не в том, чтобы запретить механизм группового доступа как таковой, а в том, чтобы создать более строгую стандартную группу для каждого пользователя и предотвратить случайный коллективный доступ к файлам. Этой цели можно также достичь с помощью команды umask (см. раздел 6.5). В системах Linux, Solaris и HP-UX поддерживаются команды, которые создают, мо- дифицируют и удаляют группы: groupadd, groupmod, groupde 1. В системе AIX вам для 8 Для того чтобы установить групповой пароль в системе Solaris, необходимо выполнить ко- манду passwd, а также команды вырезки и вставки пароля в файл /etc/дхоир. Здесь не использу- ется файл /etc/gshadow или его эквивалент.
232 Часть I. Основы администрирования этого придется модифицировать файл /etc/group с помощью текстового редактора. Но для проверки синтаксиса в этом файле предусмотрена команда grpck. 7.4. Подключение пользователей: основные действия Прежде чем создавать учетную запись для нового пользователя в правительственном учреждении, учебном заведении или в крупной коммерческой компании, крайне важно заставить его подписать соглашение о правилах работы в системе. (Как?! У вас нет та- кого соглашения? Немедленно прочтите материал в разделе 32.7, чтобы узнать, для чего оно нужно и как его составлять.) У пользователей нет веских причин подписывать такое соглашение, поэтому в инте- ресах администратора убедить их сделать это, чтобы иметь рычаги влияния. После того как учетная запись создана, добиться подписи будет трудно, так что лучше получить ее заранее. Процесс подключения нового пользователя состоит из ряда этапов, определяемых системными требованиями; два связаны с формированием пользовательской среды, а еще несколько этапов может понадобиться для целей системного администрирования. • Обязательные этапы: • добиться, чтобы пользователь подписал соглашение о правилах работы в си- стеме; • отредактировать файлы passwd и shadow с целью создания учетной записи пользователя; • добавить запись нового пользователя в файл /etc/group (в действительности это не необходимо, а желательно); • задать пароль; • создать для нового пользователя домашний каталог, назначив его владельца с помощью команды chown и задав режим доступа с помощью команды chmod; • сконфигурировать роли и права доступа (если вы используете RBAC; см. чуть ниже). • Пользовательские этапы: • скопировать в домашний каталог пользователя стандартные конфигурацион- ные сценарии; • создать каталог электронной почты и настроить почтовые псевдонимы. • Административные этапы: • проверить правильность создания учетной записи; • добавить контактную информацию о пользователе, а также сведения о статусе учетной записи в административную базу данных. Для выполнения этого списка действий необходимо иметь сценарий или утилиту, и, к счастью, во всех наших примерах систем предусмотрена таковая в форме команды useradd. Все описываемые операции по добавлению пользователей необходимо выполнять с правами суперпользователя. В системе AIX вы должны иметь привилегии UserAdmin. Именно в этом случае наступает звездный час для использования утилиты sudo. Об ути- лите sudo рассказывалось в разделе 4.3.
Глава 7. Добавление новых пользователей 233 Редактирование файлов passwd и group Если вам придется добавлять пользователя вручную, используйте команду vipw, что- бы отредактировать файлы passwd и shadow. По умолчанию выбирается редактор vi, но эту установку можно изменить, задав новое значение переменной среды EDITOR. Более важно то, что команда vipw блокирует редактируемый файл, позволяя только одному пользователю редактировать его. Это не допускает никаких конфликтов между действиями разных пользователей. В системах Solaris и Red Hat команда vipw (после редактирования файла passwd) автоматически интересуется желанием пользователя редактировать файл shadow. В си- стемах SUSE и Ubuntu для этого используйте команду vipw -s. В системах HP-UX и AIX рекомендуется не редактировать файл password вруч- ную — с помощью команды vipw или без нее (в системе AIX соответствующая утилита даже не инсталлирована). Здесь лучше использовать утилиту user add или специальные инструменты системных администраторов sxnh и SMIT соответственно. Утилита useradd рассматривается в разделе 7.5. Если новый пользователь должен стать членом нескольких групп, а не просто одной группы, заданной по умолчанию в файле passwd, вам необходимо отредактировать файл /etc/group и добавить регистрационное имя пользователя во все дополнитель- ные группы. Задание пароля 03 Правила выбора удачных паролей приведены в разделе 4.3. Никогда не оставляйте без пароля новую учетную запись или запись с доступом к ин- терпретатору команд. Определенная сложность работы с паролями может быть связана с файлами конфигурации (см. разделы в конце этой главы, чтобы узнать, какие именно файлы и переменные применяются в ваших операционных системах). Установите па- роль для нового пользователя с помощью следующей команды. $ sudo пароль новое_имя_пользователя Вам будет предложено ввести реальный пароль. В некоторых автоматизированных системах при добавлении новых пользователей необязательно вводить начальный па- роль. Задание пароля в таких случаях происходит при первой регистрации. Несмотря на удобство, этот вариант приводит к образованию огромной дыры в системе безопасно- сти; тот, кто может угадать новые регистрационные имена (или узнать их в файле /etc/ passwd), может выполнить “пиратские” действия по отношению к учетным записям, прежде чем соответствующие пользователи получат возможность зарегистрироваться. Создание домашнего каталога пользователя и инсталляция конфигурационных файлов Вы можете создать домашний каталог пользователя с помощью простой команды ®kdir. Вам также понадобится установить права владения на новый каталог и права до- ступа к нему, но лучше всего сделать это после инсталляции локальных конфигурацион- ных файлов. Имена таких файлов традиционно начинаются с точки и заканчиваются суффиксом гс (сокращение от “run command” — команда запуска) — “отголосок” операционной системы CTSS. Предшествующая точка заставляет команду 1s не включать эти файлы
234 Часть I. Основы администрирования в листинги каталогов, если только не указана опция -а. Мы рекомендуем предоставлять стандартные файлы запуска для всех интерпретаторов команд, которые популярны в ва- ших системах, чтобы пользователи по умолчанию продолжали работать в корректной среде даже при смене командной оболочки. Наиболее часто встречающиеся конфигура- ционные файлы перечислены в табл. 7.3. Таблица 7.3. Распространенные конфигурационные файлы ^Команда Имя файла Применение sh .profile Установка пути поиска, типа терминала и среды basha .bashrc .bash_jorofile Установка типа терминала (если это необходимо) Установка опций программ biff и mesg Установка переменных среды Установка псевдонимов команд Установка пути поиска Установка атрибута umask для управления правами доступа Установка переменной cdpath для поиска имен файлов Установка переменных PS1 (строка приглашения) и histcontrol csh/tcsh .login .cshrc Аналог файла . cshrc для интерпретатора csh Аналог файла . login для интерпретатора csh vi/vim .exrc/.vimrc Установка опций редакторов vi/vim emacs .emacs Установка опций редактора emacs и функциональная привязка его клавиш mail/mailx .mailrc Задание персональных почтовых псевдонимов Установка параметров оригинального почтового UNIX-клиента GNOME .gconf .gconfpath Среда GNOME: конфигурация среды пользователя посредством команды gconf Путь для дополнительного варианта конфигурации среды пользова- теля посредством команды gconf KDE . kde/ Среда KDE: каталог файлов конфигурации а Интерпретатор bash также читает файл .profile или /etc/profile в эмуляции оболочки команд sh. Образцы файлов запуска традиционно хранятся в каталоге /etc/skel (Linux, Solaris, HP-UX) или /etc (все системы). Система AIX, как всегда отличаясь от других, исполь- зует для этого каталог /etc/security. Если вы будете редактировать примеры конфи- гурационных файлов, каталог /usr/local/etc/skel — самое удачное место для хра- нения модифицированных копий. Система Linux также хранит важные детали файлов запуска в каталоге /etc/profile. d, в который “заглядывают” интерпретаторы команд, чтобы отыскать указатели на параметры вывода результатов команды 1s (чтобы сделать их нечитабельными на темном фоне) или путь к исполняемым Kerberos-файлам. В зависимости от интерпретатора, в каталоге /etc могут содержаться системные конфигурационные файлы, обрабатываемые раньше пользовательских. Например, ин- терпретатор bash читает файл /etc/profile до начала обработки файла */ .profile и ~/ .bashjprofile. В эти файлы стоит помещать стандартные установки, необходимые для функционирования вашего узла, но следует иметь в виду, что пользователи могут пе- реопределять свои установки в собственных конфигурационных файлах. Информацию о других интерпретаторах можно найти в документации (см. соответствующие man- страницы).
Глава 7. Добавление новых пользователей 235 Не забудьте задать разумное значение umask (рекомендуем 077, 027 или 022, в зави- симости от “дружелюбности” среды и размеров организации). Если вы не используете индивидуальные группы, рекомендуем установить для umask значение 077, поскольку оно предоставляет владельцу полный доступ, а для группы и вообще для всех осталь- ных — никакого доступа. Подробнее о umask см. раздел 6.5. Конфигурационные файлы и каталоги, перечисленные для настольных сред GNOME и KDE, представляют собой лишь вершину айсберга. Утилита gconf предназначена для хранения предпочтений в выборе приложений для программ под управлением GNOME (подобно тому, как это реализовано в системном реестре Windows). Установка прав доступа и прав собственности После установки домашнего каталога переходите к пользователю и убедитесь, что он имеет соответствующие права доступа. Команда $ sudo chown -R новыи_пользователь: новая_группа ~новый_пользователь должна надлежащим образом установить права собственности. Обратите внимание на невозможность использования команды $ sudo chown новый_пользователь: новая_группа ~новый_пользователь/ .★ применительно к файлам, имена которых начинаются с точки, поскольку новый_ пользователь станет владельцем не только собственных файлов, но и родительского каталога “.. ” (например, /home). Это распространенная и опасная ошибка. Назначение каталога для электронной почты Пользователи зачастую предпочитают получать почту на одном компьютере. Эта схе- ма часто реализуется с помощью записи в файле глобальных псевдонимов /etc/mail/ aliases или установки параметра userDB программы sendmail на центральном почто- вом сервере. Об электронной почте можно прочитать в главе 20. Конфигурирование ролей и административных привилегий Управление доступом на основе ролей (role-based access control — RBAC) позволя- ет “подогнать” системные права к отдельным пользователям и обеспечивается на мно- гих наших примерах систем. Политика RBAC не является традиционной частью моде- ли управления доступом UNIX или Linux, но если на вашем узле она используется, то конфигурация ролей должна быть частью процесса добавления пользователей. Модель RBAC подробно описана в разделе 4.2. Ш Подробнее о SOX и GLBA написано в главе 32. Принятые в США законы Сарбейнза-Оксли (Sarbanes-Oxley Act) и Грэма-Лич- Блайли (Gramm-Leach-Bliley Act), предназначенные, в частности, для защиты инфор- мации заказчика, полученной или используемой финансовыми организациями США, от кражи, неавторизованного доступа или злоупотребления, усложнили многие аспекты системного администрирования в корпоративной сфере, включая управление пользо- вателями. Поэтому использование ролей может быть вашим единственным жизнеспо- собным вариантом, позволяющим выполнить некоторые требования, устанавливаемые законами SOX/GLBA.
236 Часть I. Основы администрирования Заключительные действия Для того чтобы удостовериться, что новая учетная запись сконфигурирована надле- жащим образом, завершите сеанс работы (т.е. выйдите из системы), а затем снова вой- дите в систему под именем нового пользователя и выполните следующие команды. $ pwd /* для проверки домашнего каталога */ $ Is -la / * для проверки владельца/группы файлов конфигурации */ Вам необходимо уведомить новых пользователей об их регистрационных именах и начальных паролях. Многие узлы отправляют эту информацию по электронной по- чте, но из соображений безопасности это не приветствуется. Делайте это при личном контакте или по телефону. Но если вам приходится добавлять сразу 500 новичков на университетские компьютеры CS-1, переложите эту задачу на преподавателей! Именно в это время стоит напомнить пользователям о пользе ознакомления с дополнительной документацией на предмет местных обычаев, если таковые имеют место. CQ Подробнее о заключении контрактов с пользователями можно прочитать в разде- ле 32.10. Если на вашем узле требуется, чтобы пользователи подписывали соответствующее соглашение, убедитесь в реализации этого действия до создания их учетных записей. Такая проверка предотвратит возможные упущения и усилит правовую основу санкций, которые, возможно, вам придется позже применить. Напомните новым пользователям о необходимости немедленного изменения их па- ролей. При желании это можно обеспечить путем установки действия паролей в течение некоторого короткого времени. Еще один вариант состоит в создании сценария, кото- рый бы проверял новых пользователей и удостоверялся в том, что их зашифрованные пароли в файле shadow были изменены9. Если вы знаете пользователей лично, то в та- кой среде относительно несложно проследить, кто использует систему и с какой целью. Но если в подчинении администратора большой и часто меняющийся штат пользова- телей, необходим более формальный способ контроля учетных записей. Ведение базы данных с контактной информацией и сведениями о статусе учетных записей поможет, в случае необходимости, легко выяснить, кто есть кто и зачем тому или иному пользова- телю понадобилась учетная запись. 7.5. Добавление пользователей С ПОМОЩЬЮ ПРОГРАММЫ USERADD Во всех системах программа useradd реализует одну и ту же базовую процедуру, опи- санную выше. Но ее можно сконфигурировать под конкретную среду. Поскольку в каж- дой системе имеются свои представления о том, что именно следует настраивать, где следует реализовать настройки и каково должно быть стандартное поведение, мы опи- сываем эти подробности в соответствующих разделах. В табл. 7.4 приведены команды и файлы конфигурации, имеющие отношение к управлению пользователями. Все рассматриваемые нами системы имеют “джентль- менские” наборы команд для управления пользователями (как правило, к ним относят- 9 Поскольку один и тот же пароль может иметь множество зашифрованных представлений, этот метод проверяет только сам факт изменения пользователем своего пароля, а не то, что пароль реально был заменен другим паролем.
Глава 7. Добавление новых пользователей 237 ся команды useradd, usermod и userdel). Поскольку все эти команды сконфигуриро- ваны одинаково, рассмотрим только команду useradd и дополним ее запись другими командами, в зависимости от конкретной системы. Обратите внимание на то, что, несмотря на одинаковое имя (useradd), сами утили- ты реализованы в разных системах по-разному. Таблица 7.4. Команды и файлы конфигурации для управления пользователями Система Команды Конфигурационные файлы Комментарии - Ubuntu useradd adduser /etc/login.defs /etc/default/useradd /etc/adduser.conf Более дружественная Perl-версия SUSE useradd /etc/login.defs /etc/default/useradd /etc/default/passwd /usr/sbin/useradd.local /usr/sbin/userdel.local /usr/sbin/userdel-pre.local /usr/sbin/userdel-post.local Для локальных настроек Для локальных настроек Для локальных настроек Для локальных настроек Red Hat useradd /etc/login.defs /etc/default/useradd Solaris useradd /etc/default/{login tpasswd} /etc/security/policy.conf HP-UX useradd smh /etc/default/useradd /etc/default/security GUI-инструмент, также именуемый sam AIX useradd inkuser chuser rmuser SMIT /etc/security/user /etc/security/login.cfg /etc/security/mkuser.defaults Вызывается useradd Вызывается usermod Вызывается userdel GUI-инструмент а В старых системах AIX этот файл находится в каталоге /usr/lib/security. Команда useradd в системе Ubuntu В системе Ubuntu предусмотрено два способа добавления пользователей: adduser и useradd. Команда adduser представляет собой Perl-оболочку для команды useradd, что увеличивает ее “коэффициент полезного действия”, позволяя создавать домашние каталоги, копировать файлы конфигурации и пр. Команда adduser конфигурируется в файле /etc/adduser. conf по таким направ- лениям: • правила размещения домашних каталогов: по группе, по имени пользователя и пр.; • установки прав доступа для новых домашних каталогов; • диапазоны индивидуальных и групповых идентификаторов (UID и GID) для си- стемных и общих пользователей; • возможность создания индивидуальной группы для каждого пользователя; • дисковые квоты (к сожалению, с использованием только типа Boolean);
238 Часть I. Основы администрирования • сопоставление имен пользователей и имен групп с заданными регулярными вы- ражениями. Другие типы параметров команды useradd (такие, как правила создания паролей) устанавливаются как параметры, передаваемые модулю РАМ, который выполняет регу- лярную аутентификацию паролей. О подключаемых модулях аутентификации (Pluggable Authentication Modules — РАМ) можно прочитать в разделе 22.5. У команды adduser есть “близнец” addgroup и “кузины” deluser и delgroup. Команда useradd в системе SUSE В системе SUSE с помощью команды useradd по умолчанию не создается до- ™ * машний каталог для нового пользователя и не копируются конфигурационные файлы. Эти дополнения придется “заказать” с помощью флага -т. (Файлы за- пуска находятся в каталоге /etc/skel.) Команда useradd не создает и почто- вый файл спулинга для новых пользователей. Кроме того, SUSE-команда useradd не создает пользовательские группы; по умол- чанию идентификатор группы (GID) в файле passwd задается с помощью переменной GROUP в файле /etc/default/useradd. Новые пользователи также добавляются в группы, задаваемые переменной GROUPS. По умолчанию это группы video и dialout, они предоставляют доступ к системному буферу кадров и программам, обеспечивающим работу с сетью по коммутируемым телефонным каналам (pppd). Для того чтобы компенсировать эти недостатки, SUSE-команда useradd вызывает bash-сценарий /usr/sbin/useradd. local, в который можно добавить нужные вам настройки. Файл /etc/login.defs в SUSE управляет следующими аспектами: • разрешать ли регистрацию, если домашний каталог пользователя не существует; • степень устойчивости (задержка и блокировка) для неудачных попыток реги- страции; • местоположение “сообщения дня” и файлов ttytype (ввод с терминала); • ограничения на использование chsh и chfn; • контроль за сроками действия паролей; • диапазоны системных, пользовательских и групповых идентификаторов; • правила формирования допустимых имен пользователей и групп; • пользовательские значения umask (по умолчанию оно равно 022); • локальные сценарии, которые “монтируются” в команды useradd и userdel; Различные параметры и их значения достаточно полно описаны в man-странице для файла login. def s и комментариях в самом файле. Команда useradd в системе Red Hat Программа useradd в системе Red Hat Enterprise Linux принимает параметры конфигурации из файла /etc/login.defs, в котором хранятся результаты решения таких задач, как контроль устаревших паролей, алгоритмы шифро- вания, почтовые файлы спулинга и диапазоны идентификаторов UID/GID. Назначение различных параметров разъясняется с помощью комментариев, содержащихся в этом файле.
Глава 7. Добавление новых пользователей 239 С помощью команды useradd -D можно отобразить значения, которые исполь- зуются командой useradd для регистрации новых пользователей по умолчанию. Эти стандартные значения устанавливаются в файле /etc/default/useradd. В системе Red Hat новые пользователи включаются в собственные индивидуальные группы. В файле passwd символ “х” используется в качестве заполнителя пароля, а в файле shadow сим- вол “!! ” работает как код, который запрещает регистрацию и требует, чтобы системный администратор установил пароль для нового пользователя. По умолчанию используется алгоритм шифрования MD5. Домашний каталог нового пользователя заполняется кон- фигурационными файлами, “взятыми” из каталога /etc/skel. Команда useradd в системе Solaris В системе Solaris одна часть стандартных параметров, связанных с регистраци- soians онными именами и паролями, хранится в каталогах /etc/default/login и /etc/def ault/passwd; другая — встроена в саму команду useradd. Команда useradd -D позволяет отобразить стандартные значения некоторых параме- тров. Используя дополнительные флаги, эти стандартные значения можно восстановить. Формат файлов default/login и default/passwd подобен формату Linux-файла login.defs в том, что пустые строки и строки, начинающиеся с символа игнори- руются, а каждая строка, не являющаяся комментарием, назначает переменной некото- рое значение. Однако синтаксические строки NAME=значение И NAME Спробельный символ> значение не эквивалентны. Файл /etc/default/passwd позволяет управлять следующими параметрами: • минимальная длина пароля; • срок действия пароля; • необходимая степень сложности пароля; • контроль взломанных паролей. Файл /etc/default/login позволяет управлять следующими аспектами: • часовой пояс; • предельные значения размеров файлов, которые может создавать пользователь; • может ли суперпользователь регистрироваться только на консоли; • для каждого ли пользователя требуется пароль; • обработка неудачных попыток регистрации; • начальный путь поиска пользователя; • стандартное значение umask для пользователя (по умолчанию устанавливается равным 022); • протоколировать ли действия суперпользователя и неудачные попытки регистра- ции посредством утилиты syslog. Файлы /etc/security/policy, conf и /etc/security/crypt. conf определяют алгоритмы шифрования, которые можно использовать для паролей.
240 Часть I. Основы администрирования Команда useradd в системе HP-UX По умолчанию HP-UX-команда useradd не позволяет создавать домашние ЛЗЕЛ каталоги или включать пользователя в индивидуальную группу. Однако с по- мощью опции -т домашние каталоги можно создавать, а также заполнять их файлами запуска из каталога /etc/skel. Параметры конфигурации для команды useradd устанавливаются в файлах /etc/ default/useradd и /etc/default/security, причем файл useradd принимает па- раметры в стиле Linux (NAME <пробел> значение), а файл security — в стиле Solaris (ЫАМЕ=значение). Синтаксис должен быть ясен по другим записям в каждом файле, но если вы примените неправильный формат, переменная, которую вы попытаетесь уста- новить, будет молча проигнорирована. Никакие сообщения о синтаксических ошибках при этом не генерируются. Файл /etc/default/useradd управляет следующими опциями: • стандартная группа и командная оболочка; • корень дерева домашнего каталога; • истечение срока действия учетной записи; • создавать ли домашние каталоги; • разрешать ли дублированные идентификаторы пользователя. Файл /etc/default/security содержит дополнительные параметры конфигура- ции, и некоторые из них имеют отношение к управлению пользователями: • разрешать ли регистрационные имена с опущенным домашним каталогом; • разрешать ли нулевые (пустые) пароли; • минимальная длина пароля; • обработка неудачных попыток регистрации; • обработка неактивных учетных записей; • стандартное значение umask для новых пользователей (по умолчанию 027). По именам переменных в этом файле несложно понять их назначение. Команда useradd в системе AIX • В системе AIX программа useradd представляет собой всего лишь ksh-обо- лочку для команды mkuser. Подобным образом команда usermod вызывает программу chuser, а команда userdel — программу rmuser. Для этих ко- манд имеются соответствующие man-страницы, которые можно найти по их исходным именам. Файлы конфигурации, управляющие многочисленными аспектами регистрационных имен и паролей, хранятся в каталоге /etc/security. Существует три файла: login, cfg, user и mkuser. default. В первых двух файлах символ используется в каче- стве символа комментария; а третий файл комментариев не имеет. Эти файлы организо- ваны с использованием следующей формы. метка: атрибут - значение сл едующий_ а трибут = зна чение следующая_метка : атрибут = значение
Глава 7. Добавление новых пользователей 241 Например, в файле /etc/security/user элементы метка представляют собой имена пользователей (или слово default), а список возможных атрибутов приведен в табл. 7.5. Таблица 7.5. Опции управления учетными записями пользователей в файле /etc/security/user (AIX) Опция ; . Д; •• account_locked Булев Блокирует регистрационное имя, если равен true admin Булев Предоставляет права администратора, если равен true authl Список методов Основной метод аутентификации auth2 Список методов Второстепенный метод аутентификации dictionlist Имена файлов Словари, которые должны включать пароли expires Дата Дата истечения срока действия учетной записи пользователя histexpire Недели Период, когда пользователь не может повторно использовать пароль histsize Число Количество предыдущих значений пароля, которое не может быть повторно использовано ogin Булев Можно зарегистрировать? Подходит для таких регистрационных имен, bin oginretries Число Количество попыток регистрации до блокирования учетной записи ogintimes Временной диа- пазон Временные границы, когда пользователь может зарегистриро- ваться maxexpired Недели Льготный период для недействительных паролей maxrepeats Число Количество раз, которое символ может появиться в пароле minage, maxage Недели Минимальный и максимальный “возраст” пароля minalpha Число Минимальное количество буквенных символов в пароле mindiff Символы Количество символов старого пароля, разрешенных в новом па- роле minlen Число Минимальная длина пароля (не устанавливайте его равным 0) minother Число Минимальное количество небуквенных символов в пароле pwdchecks Имена файлов Функции, вызываемые для проверки безопасности паролей pwdwarntime Дни Льготный период для предупреждения пользователя об изменении пароля rlogin Булев Может ли использовать протокол rlogin или telnet для данной учетной записи? su Булев Могут ли другие пользователи использовать su для данной учет- ной записи? ttys Список устройств Терминалы, с которых данный пользователь может регистриро- ваться __ umask Восьмеричный Стандартные права доступа для файлов, созданных пользователем Ну и ну, что за список! В комментариях файла указываются значения по умолчанию, которые вполне корректны для инсталляции с низким уровнем безопасности. Мы реко- мендуем некоторые параметры изменить: • значение umask с 022 на 077;
242 Часть I. Основы администрирования • значение loginretries с 0 (неограниченное) на небольшое целое, скажем, чис- ло 5; • значение minlen с 0 (нет пароля) на хотя бы число 6 или 7; • значение expires с 0 (никогда) на год (только в случае, если у вас есть инстру- мент периодического обновления дат истечения срока для действительных поль- зователей). £□ Подробнее о РАМ рассказывается в разделе 22.5. К сожалению, это лишь один из файлов конфигурации, который управляет процес- сом регистрации нового пользователя. Файл /etc/security/login.cfg содержит па- раметры управления дефектными регистрационными именами (время задержки между приглашениями ввести имя и пароль, количество дефектных регистрационных имен, разрешаемых до блокирования учетной записи, длительность блокирования учетной записи, время ее восстановления и прочее), значения моментов времени, когда реги- страционные имена разрешаются, вид запроса на ввод пароля пользователя, список действующих интерпретаторов команд, максимально допустимое количество одновре- менных регистраций, длительность времени ожидания пароля пользователя, тип авто- ризации регистрационного имени (т.е. где бы вы задали РАМ10, если бы должны были его использовать) и алгоритм шифрования паролей (по умолчанию crypt). Кроме того, чтобы запутать вас еще больше, некоторые параметры задаются в двух файлах, иногда с одинаковыми именами (например, logintimes), а иногда — с разными (loginretries и logindisable). Наверное, чтобы жизнь медом не казалась! Команда useradd в системе AIX не имеет опции -D, которая отображает стандартные значения для новых пользователей. Она помещает новых пользователей в одну группу ц не создает домашние каталоги, если не был указан флаг -т (в этом случае выполняется копирование данных в файл .profile из каталога /etc/security). Пример использования команды useradd Для того чтобы создать в системе Linux новую учетную запись “hilbert” стандартны- ми системными средствами, можно просто выполнить следующую команду. $ sudo useradd hilbert При выполнении этой команды будет создана следующая запись в файле /eta /passwd. hilbert:х:1005:20: :/home/hilbert:/bin/sh Команда useradd блокирует учетную запись, помещая символ “х” в поле пароля^ Чтобы сделать учетную запись используемой, ей необходимо назначить реальный пароль. Рассмотрим более реалистичный пример. Мы хотим, чтобы основной группой поль- зователя hilbert была faculty и чтобы он был добавлен в группу famous. Для этого переопределим стандартное местоположение домашнего каталога и интерпретатор, а также велим команде useradd создать домашний каталог (если таковой еще не создан). $ sudo useradd -с "David Hilbert" -d /home/math/hilbert -g faculty -G famous -m -s /bin/tcsh hilbert Эта команда создает следующую запись passwd. hilbert:х:1005:30:David Hilbert:/home/math/hilbert:/bin/tcsh 10 PAM — подключаемые модули аутентификации — относительно недавнее дополнение к си- стеме AIX, которое должно быть полностью функциональным в версии 5.3 и более поздних.
Глава 7. Добавление новых пользователей 243 Назначенный идентификатор (UID) оказывается больше наибольшего идентифика- тора в системе, и соответствующая запись имеет следующий вид. hilbert: ! :14322:0:99999:7:0: : В файлах passwd и shadow используются разные символы-заполнители пароля, ко- торые зависят от конкретной операционной системы. Команда useradd также добавит пользователя hilbert в соответствующую группу (в файле /etc/group), создаст ката- лог /home/math/hilbert и заполнит его файлами из каталога /etc/skel. 7.6. Добавление пользователей "пакетом” С ПОМОЩЬЮ КОМАНДЫ NEWUSERS (LlNUX) ДПри выполнении Linux-команды newusers одновременно создается несколь- ко учетных записей из содержимого подготовленного текстового файла. Это не вполне формальный способ, но им удобно пользоваться в случае, если нужно добавить много пользователей сразу, например при создании учетных записей для учебной группы. Команда newusers в качестве аргумента полу- чает входной файл, состоящий из строк, подобно файлу /etc/passwd, за ис- ключением того, что его поле пароля содержит начальный пароль, заданный открытым текстом. Поэтому хорошо подумайте о защите такого файла. Команда newusers принимает связанные со сроком действия пароля параметры, установленные в файле /etc/login.defs, но не копирует стандартные конфигураци- онные файлы, как это делает команда useradd. Единственный файл, который предо- ставляется в этом случае, — файл .xauth. В университетских системах действительно важно применять “пакетный” сценарий adduser, который использует список студентов из данных регистрации для генерирова- ния входной информации для команды newusers. Для этого необходимо иметь имена пользователей, подготовленные в соответствии с локальными правилами при гарантии их уникальности (на локальном уровне), а также метод случайного генерирования па- ролей при увеличивающихся значениях идентификаторов пользователей и Щупловых идентификаторов для каждого студента. Возможно, вам лучше написать собственную оболочку для команды useradd на языке Perl или Python, чем пытаться приспособить свои нужды к тому, что предлагает команда newusers. 7.7. Удаление пользователей Когда пользователь покидает организацию, его учетная запись и файлы должны быть Удалены из системы. Эта процедура включает удаление всех ссылок на регистрационное имя, которые были введены вручную или с помощью команды useradd. При ручном Удалении учетной записи последовательность операций будет примерно такой: • удалить записи пользователя из локальных баз данных и телефонных списков; • удалить пользовательские псевдонимы из файла aliases либо организовать пере- направление поступающих ему сообщений; • удалить пользовательские задания из crontab-файла, из очереди команды at, а также из заданий на печать; • уничтожить пользовательские процессы, которые еще выполняются;
244 Часть I. Основы администрирования • удалить записи пользователя из файлов passwd, shadow11, group и gshadow; • удалить домашний каталог пользователя; • удалить почтовый каталог пользователя; • удалить записи в совместно используемых календарях, системах бронирования но- меров и пр. • удалить или преобразовать права владения любыми списками рассылки, исполь- зуемыми удаленным пользователем. Перед тем как удалять домашний каталог пользователя, необходимо переместить из него в другие каталоги все файлы, которые нужны остальным пользователям. Поскольку не всегда можно с уверенностью сказать, какие файлы понадобятся, а какие — нет, луч- ше предварительно скопировать пользовательские домашний и почтовый каталоги на какой-то носитель. После удаления учетной записи пользователя убедитесь, что в системе не осталось файлов с его идентификатором. Чтобы узнать точный путь к этим файлам, восполь- зуйтесь командой find с аргументом -nouser. Поскольку команда find может вести поиск на сетевых серверах, проверяйте файловые системы по отдельности, задавая оп- цию -xdev. $ sudo find filesystem -xdev -nouser Прекращение выполнения процессов удаленного пользователя может оказаться про- блематичным в распределенной среде. Совместно используемые календари и системы бронирования номеров могут иметь еще работающие элементы (сгенерированные бо- лее несуществующим пользователем), которые внезапно “осиротели” и должны быть удалены. Возможно, в вашей системе найдутся и другие места, подлежащие “зачистке”. Имеет смысл составить собственный список, может быть, в форме соответствующего сценария. Если в организации за пользователями закреплены отдельные рабочие станции, эффективнее всего переинсталлировать систему, прежде чем предоставлять ее новому пользователю. Но не забудьте сбросить на системный жесткий диск локальные файлы, которые могут понадобиться в будущем. Каждая система из наших примеров имеет команду userdel, которая автоматизиру- ет процесс удаления пользователя. Если она не отвечает вашим высоким требованиям, можете дополнить ее функциональные возможности предоставлением ей расширенного списка мест хранения данных о пользователях. ®В системе Ubuntu команда deluser представляет собой Perl-сценарий, ко- торый вызывает обычную команду userdel, аннулируя все деяния команды adduser. При этом вызывается сценарий deluser.local, если таковой су- ществует, чтобы реализовать несложную операцию локализации. Файл кон- фигурации /etc/deluser. conf позволяет установить следующие опции: • удалять ли домашний и почтовый каталоги пользователя; • резервировать ли файлы пользователя и куда поместить резервные копии; • удалять ли все файлы, которыми владел пользователь; • удалять ли группу, если в данный момент она не имеет членов. 11 В системе AIX /etc/security/{passwd,group}.
Глава 7. Добавление новых пользователей 245 Система SUSE поддерживает набор префиксных и постфиксных сценари- • " ™ ев, а также сценарий userdel. local, который помогает команде userdel (и вам), вооружая соответствующие программные инструменты знаниями о ваших местных особенностях. Сконфигурируйте соответствующие параме- тры в файле /etc/login.defs. В системе Red Hat предусмотрен сценарий userdel. local, но не предусмо- трены префиксные и постфиксные сценарии для автоматизации операций по резервированию файлов пользователя, подлежащего удалению. В системах Solaris и AIX есть дополнительные “тайники”, в которых утаи- SOLSriS вается информация о пользователях. В основном, это файлы, обеспечиваю- щие управление ролями и классами авторизации. Следовательно, команды userdel этих систем имеют более длинный “список действий” по удалению всех ссылок на удаляемого пользователя. Например, в дополнение к файлам /etc/passwd и /etc/group, Solaris-команда userdel обновляет файлы /etc/shadow, /etc/project и /etc/user_attr. В систе- ме AIX команда userdel обновляет содержимое следующих файлов в каталоге /etc/ security: user, user.roles, lastlog, environ, audit/config, limits, passwd и group. От Solaris не следует ожидать образцового исполнения: ее команда userdel оставляет тестовое регистрационное имя с профилем, сконфигурированным в базе дан- ных user_attr, которую необходимо “привести в порядок”. KCV в системе HP-UX команда userdel лишена “интеллекта”, т.е. вполне зауряд- но ликвидирует изменения, внесенные командой useradd. Она обновляет со- держимое только файлов passwd, shadow и group. 7.7. Отключение учетной записи Иногда нужно временно отключить учетную запись пользователя. Проще всего сде- лать это, поставив звездочку (*) или какой-то другой символ в поле зашифрованного пароля в файле /etc/security/passwd (AIX) или /etc/shadow. Эта мера препятству- ет большинству типов доступа, управляемых паролем, поскольку дешифровка больше не может привести к получению какого-либо приемлемого пароля. Однако такие команды, как ssh, которые не всегда проверяют системные пароли, могут продолжать работать. ДВо всех дистрибутивах Linux, рассматриваемых нами в качестве примеров, ко- манды usermod -L пользователь и usermod -U пользователь позволяют легко соответственно блокировать и разблокировать пароли. Флаг -L просто помещает символ “! ” перед зашифрованным паролем в файле /etc/shadow, а флаг -и удаляет его. Суперпользователь в системе Solaris может заблокировать учетную запись с по- soians мощью команды passwd ~ 1 locfin имя9 заставить пользователя изменить па роль с помощью флага -f или разблокировать учетную запись с помощью фла- га -и. При блокировке учетной записи в поле пароля (в файле /etc/shadow) добавляются символы *LK*. Они также представляют собой значение, уста- навливаемое командой useradd для новых пользователей. ЕЯ Система HP-UX поддерживает только зашифрованные с помощью crypt па- роли. Символ никогда не может принадлежать полю пароля, сгенериро-
246 Часть I. Основы администрирования ванного системой crypt, поэтому добавление символа к зашифрованно- му паролю не позволит пользователю войти в систему. • В системе AIX, если поле пароля в файле /etc/passwd содержит символ “*” вместо символа “ ’ учетная запись блокируется. AIX-команда pwdadm может заставить пользователя изменить пароль или заблокировать учетную запись, чтобы только администратор мог изменить пароль. К сожалению, модификация пароля пользователя просто приводит к блокированию регистрационных имен. При этом пользователь не уведомляется о блокировке паро- ля и не получает разъяснений, почему его учетная запись больше не работает. Альтер- нативный способ блокировать регистрационные имена состоит в замене интерпретато- ра команд пользователя программой, которая выдает сообщение, поясняющее, почему учетная запись отключена, и содержащее инструкции по исправлению ситуации. Затем программа завершается, завершая сеанс регистрации. Этот метод имеет как преимущества, так и недостатки. Те формы доступа, которые проверяют пароли, но не обращают внимания на интерпретатор команд, не будут забло- кированы. Многие демоны, предоставляющие доступ к системе без регистрации (напри- мер, ftpd), проверяют, упомянут ли интерпретатор пользователя в файле /etc/shells. Если он там не указан, вход в систему будет запрещен (именно это нам и требуется). К сожалению, этот метод нельзя назвать универсальным. Поэтому, если для блокирова- ния учетных записей вы решите модифицировать интерпретатор команд, вам придется провести дополнительные исследования своей системы. Кроме того, поясняющее сообщение нельзя увидеть, если пользователь пытается за- регистрироваться в системе в оконной среде или посредством эмулятора терминала, ко- торый не позволяет увидеть сообщения после выхода из системы. По умолчанию программа sendmail не доставляет почту тем пользователям, чьи ин- терпретаторы не указаны в файле /etc/shells. Как правило, не рекомендуется вмеши- ваться в доставку почты, даже если получатель не может прочитать ее немедленно. Для того чтобы “обмануть” программу sendmail, добавьте в файл /etc/shells ложный интерпретатор с именем /SENDMAIL/ANY/SHELL (конечно, это может вызвать нежела- тельные побочные эффекты). 7.9. Управление учетными записями СИСТЕМНЫМИ СРЕДСТВАМИ Системы HP-UX и АЕХ предоставляют комплексные инструментарии системного администрирования, в которые заложены “знания”, как управлять пользователями, по крайней мере, на базовом уровне. В системе AIX это интерфейс SMIT (System Mana- gement Interface Tool), а в HP-UX — интерфейс, который сейчас называется smh (Sys- tem Management Homepage). В более ранних версиях HP-UX этот инструмент носил на- звание sam (System Administration Manager). Все эти инструменты используют экраны для добавления пользователей и управления ими, с применением либо оконного (GUI), либо терминального интерфейса на базе библиотеки curses. Если вы — начинающий системный администратор или уже опытный специалист, но осваивающий новую опера- ционную систему, эти инструменты — как раз то, с чего вам нужно начать для решения многих рутинных задач системного администрирования.
Глава 7. Добавление новых пользователей 247 AIX-инструмент smithy отличается удобной функциональностью. Нажав клавишу <F6>, вы увидите команду (с возможными параметрами), предлагаемую для выполне- ния. Этот инструмент регистрирует все действия и хранит файл сценария с командами, выполняемыми от вашего имени. Он может послужить хорошим подспорьем в изучении особенностей системы AIX. Если вы работаете в системе HP-UX, то, вероятно, вам по- нравится инструмент sinh, который оснащен односимвольными клавиатурными коман- дами, принимаемыми его интерфейсом curses. Эти команды отображаются на каждой странице меню, и поэтому вы сможете быстро с ними познакомиться. 7.10. Уменьшение риска с помощью РАМ Подключаемые модули аутентификации (Pluggable Authentication Modules — РАМ) подробно описаны в разделе 22.5. В них сосредоточено управление системными сред- ствами аутентификации посредством стандартных библиотечных утилит, чтобы такие программы, как login, sudo, passwd и su, не должны были предоставлять собственный код аутентификации. Модули РАМ уменьшают риск, присущий отдельно взятым про- граммным продуктам, позволяют администраторам устанавливать политики безопасно- сти, действующие в рамках всего узла сети, а также определяют простой способ добавле- ния в систему новых методов аутентификации. Добавление и удаление учетных записей пользователей не предусматривает измене- ние конфигурации модулей РАМ, но используемые для этих целей инструменты долж- ны действовать по правилам РАМ и в соответствии с требованиями РАМ. Кроме того, многие параметры конфигурации РАМ подобны тем, которые используются командами useradd или usermod. Если вы измените какой-нибудь параметр (как описано ниже в этой главе), а команда useradd, казалось бы, не обратит на это внимания, проверьте, не аннулировала системная конфигурация РАМ ваше новое значение. 7.11. Централизация управления учетными записями В средних и крупных корпорациях всех типов (академических, частных или госу- дарственных) важно использовать определенную форму централизованного управления учетными записями. Каждый пользователь должен иметь в узле уникальное, удобное и безопасное регистрационное имя, идентификатор (UID) и пароль. Администраторам нужна централизованная система, которая бы немедленно обеспечивала повсеместное распространение изменений (например, аннулирование конкретной учетной записи). Такая централизация может быть достигнута различными способами, большинство из которых (включая систему Active Directory компании Microsoft) в той или иной степе- ни (от бесплатных инсталляций с открытым исходным кодом до дорогих коммерческих систем) использует упрощенный протокол доступа к сетевым каталогам (Lightweight Directory Access Protocol — LDAP). Протокол LDAP и служба Active Directory Ш Подробнее о протоколе LDAP и его реализациях рассказывается в разделе 19.3. Протокол LDAP представляет собой обобщенный репозиторий (наподобие базы дан- Ных)> который может хранить данные, связанные с управлением пользователями, а так- Же другие типы данных. Он использует иерархическую модель “клиент/сервер”, которая поддерживает несколько серверов и несколько одновременно работающих клиентов.
248 Часть I. Основы администрирования Одно из самых больших преимуществ LDAP как общеузлового репозитория для реги- страционных данных состоит в том, что он может обеспечить в системах уникальность идентификаторов UID и GID. Кроме того, он хорошо стыкуется с Windows, хотя обрат- ное утверждение справедливо лишь в самой малой степени. Служба Active Directory использует протоколы LDAP и Kerberos (сетевой протокол аутентификации) и может управлять множеством типов данных, включая данные поль- зователей. Она ведет себя несколько “эгоистично”, навязывая “свою линию” при взаи- модействии с UNIX- или Linux-репозиториями LDAP Если вам нужна единая система аутентификации для узла, который включает Windows-компьютеры, а также UNIX- и Linux-системы, то, возможно, проще всего позволить службе Active Directory использо- вать ваши UNIX-базы данных LDAP в качестве вспомогательных серверов. Для реализации такой конфигурации вам понадобится служба Active Directory и Microsoft-службы для UNIX (Services for UNIX) или такая коммерческая интеграцион- ная платформа Active Directory, как Quest Authentication Services (ранее именуемая Vin- tela Authorization Services). Система Virtual Directory (Sun) может состыковать несколько различных систем авторизации/аутентификации. Все наши примеры систем поддерживают LDAP как встроенный компонент, хотя иногда лишь на стороне клиента (например, это касается системы HP-UX). Протокол LDAP для выполнения задач аутентификации часто связывается с модулями РАМ. Протокол LDAP — это, по сути, база данных, поэтому хранимая там информация должна быть построена по определенной схеме. Под схемами в данном случае пони- маются XML-файлы, имена полей в которых должны отвечать релевантным форматам RFC (Request for Comments — запрос комментариев, т.е. документ из серии пронуме- рованных информационных документов Интернета), в основном RFC2307 для данных управления пользователями. Подробнее написано в главе 19. Системы “единого входа” Системы с однократной идентификацией пользователей (single sign-on — SSO) уравновешивают удобства пользователя с проблемами безопасности. Их основная идея состоит в том, чтобы пользователь, один раз зарегистрировавшись (в ответ на соответ- ствующее приглашение, в веб-странице или в окне Windows), мог затем переходить, к примеру, из одного раздела в другой без повторной аутентификации. Другими словами, пользователь получает аутентификационный мандат (обычно в неявном виде, чтобы не требовалось больше никакого активного управления), который затем можно использо- вать для доступа к другим компьютерам и приложениям. Пользователь должен помнить только одну последовательность (а не много), состоящую из регистрационного имени и пароля. Эта схема позволяет усложнять мандаты (поскольку пользователю не нужно помнить о них и вообще иметь с ними дело), которые теоретически повышают степень сложно- сти. Однако влияние скомпрометированной учетной записи в этом случае усиливается, поскольку одно регистрационное имя предоставляет взломщику доступ сразу к несколь- ким компьютерам и приложениям. Системы SSO переносят “арену действий” из на- стольного компьютера (пока вы спокойно регистрировались) в зону особой уязвимости. Кроме того, узким местом системы становится сервер аутентификации. Если он “упа- дет”, вся работа организации остановится. Несмотря на то что в основе системы SSO лежит простая идея, она предполагает большую внутреннюю сложность, поскольку различные приложения и компьютеры,
Глава 7. Добавление новых пользователей 249 к которым пользователь хотел получить доступ, должны понимать процесс аутентифи- кации и SSO-мандаты. В некоторых системах SSO мандатами пользователей управляет протокол Kerberos (подробнее он описан в разделе 22.10). Существует ряд систем SSO с открытым исходным кодом: • JOSSO, сервер SSO с открытым исходным кодом, написанный на языке Java; • служба CAS (Central Authentication Service), созданная Йельским университетом (на языке Java); • продукт Likewise Open, средство интеграции, которое заставляет службу Microsoft Active Directory хорошо работать с системами Linux и UNIX. Существуют также коммерческие системы, большинство из которых интегрировано с семействами программных продуктов, предназначенными для управления учетными данными (о них пойдет речь в следующем разделе). Системы управления учетными данными Управление учетными данными (identity management) — это последний писк моды в области управления пользователями. Если говорить проще, то этот термин означает идентификацию пользователей конкретной системы, аутентифицирование их лично- стей и предоставление привилегий на основе этих аутентифицированных личностей. Стандартизация этой деятельности проводится такими организациями, как World Wide Web Consortium и The Open Group. Коммерческие системы управления учетными данными сочетают несколько клю- чевых концепций UNIX в виде графического интерфейса, “приправленного” терми- нами из сферы маркетинга. Основным элементом для всех этих систем является база- данных, которая содержит информацию, связанную с аутентификацией и авторизацией пользователей, часто хранимую в формате LDAP. Управление реализуется на базе таких понятий, как группы UNIX, а ограниченные административные права усиливаются по- средством таких утилит, как sudo. Большинство таких систем было разработано с целью урегулирования требований, диктуемых с точки зрения возможности идентификации, использования контрольных записей и слежения за ними. Создано много коммерческих систем в этой сфере, например: Identity Management (Oracle), Sun Identity Management Suite12, Courion, Avatier Identity Management Suite (AIMS) и BMC Identity Management Suite. Оценивая системы управления учетными дан- ными, ищите следующие функции: • генерирование глобальных уникальных идентификаторов пользователей; • возможность создания, изменения и удаления пользовательских учетных записей в организации на оборудовании и операционных системах всех типов; • безопасный веб-интерфейс для управления, доступного как изнутри, так и снару- жи организации; • возможность простого отображения имен всех пользователей, которые имеют определенный набор привилегий; • простой способ узнать все права, предоставленные конкретному пользователю; • возможность разрешить пользователям изменять (и восстанавливать) собственные пароли при соблюдении правил выбора сильных паролей; 12 Теперь, когда компания Oracle купила Sun, не ясно, выживет ли эта система как продукт по- сле завершения процесса поглощения.
250 Часть I. Основы администрирования • возможность для пользователей менять их пароли глобально в одной операции; • механизм организации действий; например, многоуровневые одобрения до того, как пользователь получит определенные права; • возможность согласования с базами данных кадров для автоматического удаления доступа для служащих, которые уволены или сокращены; • регистрация с перестраиваемой конфигурацией всех изменений и действий адми- нистратора; • реконфигурируемые отчеты на основе регистрационных данных (по пользователю, по дате и пр.); • управление доступом на основе ролей, включая инициализацию учетных записей пользователей с использованием ролевого принципа; • интерфейс, при использовании которого наем менеджеров может потребовать, чтобы учетные записи предоставлялись в соответствии с ролью; • исключения для предоставления прав на основе ролей, включая организацию дей- ствий для рассмотрения исключений. Рассмотрите также, как реализована система с точки зрения того, какие в действи- тельности выполняются аутентификации и авторизации. Требуется ли системе повсе- местная инсталляция пользовательских агентов или возможно самостоятельное согласо- вание с базовыми системами? 7.12. Рекомендуемая литература “The Complete Buyer's Guide for Identity Management. ”// Sun Microsystems white paper, 2008, sun.systemnews.com/articl'es/12 9/4/sec/20930. 7.13. Упражнения ; 7.1. Как определить стандартную группу, в которую входит пользователь? Как изме- нить ее? 7.2. Объясните разницу между следующими значениями umask: 077, 027, 022 и 755/ Как сделать одно из этих значений стандартной общесистемной установкой дл^ новых пользователей? Можно ли заставить пользователей придерживаться одного и того же значения umask? 7.3. Каково назначение файла скрытых паролей? 7.4. ★ Определите, какую систему аутентификации использует программа login в ва- шей системе. Если это модуль РАМ, определите, какие другие программы в систе- ме также используют РАМ. 7.5. ★ Перечислите действия, которые необходимо выполнить для добавления поль- зователя в систему без помощи команды useradd. Какие действия дополнительно необходимы в вашей организации? 7.6. ★ Разработайте схему выбора пользовательских имен для вашей организации. Какие правила устанавливает данная схема? Как обеспечить уникальность имен? Есть ли недостатки у этой схемы? Как происходит удаление пользователей?
Глава 7. Добавление новых пользователей 7.7. ★★ Возьмите список имен (например, из телефонного справочника) зуйте его в качестве входной информации для сценария, генерирующегс ционные имена в соответствии с разработанной выше схемой. Скольк записей удалось получить до возникновения конфликта? Сколько во< фликтов возникло? На основании полученных результатов дайте оценку бора пользовательских имен и предложите улучшения к ней. 7.8. Напишите сценарий проверки файла /etc/passwd, выполняющие ленные ниже действия (для осуществления второго и последнего пунк потребоваться доступ с правами суперпользователя): а) поиск записей с идентификатором пользователя, равным нулю; б) поиск записей без пароля (требуется файл /etc/shadow); в) поиск группы записей с одинаковыми идентификаторами пользо! г) поиск записей с одинаковыми регистрационными именами; д) поиск записей, для которых не установлен срок действия (требуеа etc/shadow). f ' 7.9. Напишите модуль РАМ для выполнения аутентификации тг рирования случайного PIN-кода, отправляемого на мобильный телефс вателя в качестве SMS-сообщения, с последующим приглашением bi PIN-код для подтверждения. Инсталлируйте свой модуль и сконфигур) в стеке РАМ-регистрации для получения двухфакторного процесса aj кации.
Глава 8 Дисковая память Дисковая память системы UNIX все больше напоминает фрагменты огромной го- ловоломки, которые можно соединять друг с другом, создавая бесчисленное множество вариантов конфигурации. Что желаете собрать? Истребитель? Самосвал? Современней- ший вертолет с воздушными подушками безопасности и приборами ночного видения? Традиционные жесткие диски остаются доминирующим средством для создания ин- терактивных хранилищ данных, но при создании высокопроизводительных приложений они все чаще объединяются с флеш-дисками (solid state drive — SSD). Для всего этого аппаратного обеспечения разработаны программные компоненты, играющие роль по- средников между устройствами для хранения данных и файловой иерархией, которую видит пользователь. К этим компонентам относятся драйверы устройств, соглашения о разделении дисков, реализации массивов дисков (RAID), менеджеры логических томов, системы виртуализации дисков в сети и реализации самих файловых систем. В главе обсуждаются административные проблемы и решения, возникающие на каж- дом из этих уровней. Мы начнем с простых инструкций, позволяющих добавить базовый диск в каждую из рассматриваемых операционных систем. Затем опишем технологии, лежащие в основе современного аппаратного обеспечения для дисковой памяти, и рас- смотрим общую архитектуру программного обеспечения для дисковой памяти. Затем мы опишем проблемы, связанные с дисковой памятью, начиная с низкоуровневого форма- тирования и заканчивая файловой системой. По ходу изложения рассмотрим вопросы, связанные с логическим разделением дисков, системами RAID, менеджерами логических томов и системами для реализации сетей хранения данных (storage area network — SAN). Несмотря на то что все производители используют стандартизованное дисковое обо- рудование, в области программного обеспечения наблюдается огромное разнообразие. Соответственно, в главе рассматривается множество особенностей, присущих отд ель-
глава 8. Дисковая память 253 ным производителям. Мы старались достаточно подробно описать каждую систему, чтобы читатели могли хотя бы идентифицировать команды и системы, которые они ис- пользуют, и найти соответствующую документацию. 8.1. Добавление диска Прежде чем погрузимся в многостраничное повествование об архитектуре и теории дисковых систем, рассмотрим самый обычный сценарий: мы хотим инсталлировать жесткий диск и сделать его доступным посредством файловом системы. В этом сцена- рии нет ничего особенного: нет никакого массива RAID, все пространство диска нахо- дится на одном логическом томе, а тип файловой системы выбирается по умолчанию. На первом этапе присоединим диск и повторно загрузим систему. Некоторые си- стемы допускают подключение дисков без перезагрузки, но мы не будем рассматривать этот случай. Кроме того, конкретные инструкции могут изменяться в зависимости от операционной системы. Независимо от операционной системы, в которой вы работаете, очень важно пра- вильно идентифицировать и форматировать дисковое устройство. Вновь добавленному диску не всегда соответствует файл устройства с самым большим порядковым номером. В некоторых системах добавление нового диска может изменить имена существующих дисков. Дважды проверьте идентичность нового диска, проверив его производителя, раз- мер и номер модели, прежде чем начнете выполнять потенциально опасные операции. Инструкции для системы Linux Д Выполните команду sudo fdisk -1, чтобы увидеть список системных дисков и идентифицировать новое устройство. Затем запустите любую утилиту для логического разбиения дисков и создания таблицы разделов для данного уст- ройства. Для устройств 2ТВ и ниже инсталлируйте таблицу разделов MBR для системы Windows. Проще всего это сделать с помощью утилиты cfdi.sk, но для этой цели можно также использовать утилиты fdisk, sfdisk, parted или gparted. Более крупные диски требуют использования таблицы раз- делов GPT, поэтому их следует разбивать на логические разделы с помощью утилиты parted или ее интерфейса gparted в среде GNOME. Программу gparted использовать намного проще, но она, как правило, не инсталлиру- ется по умолчанию. Поместите все дисковое пространство в один раздел “неформатированного” типа. Не инсталлируйте файловую систему. Запомните логическое имя устройства в новом раз- иении, прежде чем запускать утилиту разбиения диска; допустим, что она называется 'dev/sdcl. ^атем выполните следующую последовательность команд, выбирая подходящие име- ^У1111 тома (vgname), логического тома (volname) и точки монтирования (mount- 1пч, например homevg, home или /home. $ 8udo pvcreate /dev/sdcl #Готовимся использовать w/LVM $ Sudo vgcreate vgname /dev/sdcl #Создаем группу тома $ Su^° Ivcreate -1 100%FREE -n volname vgname #Создаем логический том $ U ° “t ext4 /dev/vgname/volname #Создаем файловую систему $ 0° ^dir mountpoint #Создаем точку монтирования /etc/fstab #3адаем опции монтирования
254 Часть I. Основы администрирования Откройте файл /etc/fstab, скопируйте строку, соответствующую существующей файловой системе, и уточните ее. Монтируемым устройством должен быть диск /dev /vgname/volname. Если ваш существующий файл f stab идентифицирует тома по стан- дарту UUID, замените пункт UUID=xxx файлом устройства; для томов LVM идентифика- ция по стандарту UUID не нужна. В заключение выполните команду sudo mount mountpoint, чтобы смонтировать файловую систему. Более подробную информацию о файлах устройств для дисков в системе Linux мож- но найти в разделе 8.5. Информация о разбиении диска на логические разделы приведе- на в разделе 8.6, а о менеджере логических томов — в разделе 8.8. Семейство файловых систем ext4 обсуждается в разделе 8.9. Инструкции для системы Solaris Выполните команду sudo foxmat и проверьте меню, состоящее из имен из- soiaris вестных дисков, чтобы выяснить имя нового устройства. Допустим, что оно называется c9t0d0. Нажмите комбинацию клавиш <Ctrl+C>, чтобы отменить выполнение этой команды. Выполните команду zpool create имя_пула c9t0d0. Выберите простое имя пула, например home или extra. Система ZFS создаст новую файловую систему и смонтирует ее в каталоге /имя__пула. Более подробно дисковые устройства описаны в разделе 8.5. Обзор системы ZFS при- веден в разделе 8.10. Инструкции для системы HP-UX ®ыполните команду sudo ioscan -fNn -Cdisk, чтобы идентифицировать файлы устройств для нового диска. Допустим, что они называются /dev/disk /disk4 и /dev/rdisk/disk4. Затем выполните следующую последовательность команд, выбирая подходящие име- на для групп тома (vgname), логического тома (volname) и точки монтирования (mount- point), например homevg, home или /home. $ sudo pvcreate /dev/rdisk/disk4 #Готовимся использовать w/LVM $ sudo vgcreate vgname /dev/disk/disk4 #Создаем группу тома $ vgdisplay vgname Free PE freespace #0тметьте это значение $ sudo Ivcreate -1 freespace -n volname vgname #Создаем логический том $ sudo mkfs /dev/vgname/volname #Создаем файловую систему $ sudo mkdir mounpoint #Создаем точку монтирования $ sudo vi /etc/fstab #3адаем опции монтирования Откройте файл /etc/fstab, скопируйте строку, соответствующую существующей файловой системе, и уточните ее. Монтируемым устройством должен быть диск /dev /vgname/volname. В заключение выполните команду sudo mount mountpoint, чтобы смонтировать файловую систему. Более подробную информацию о файлах устройств для дисков в системе HP-UX мож- но найти в разделе 8.5. Информация о разбиении диска на логические разделы приведе- на в разделе 8.6. Файловая система VxFS обсуждается в разделе 8.9.
Слава 8. Дисковая память 255 Инструкции для системы AIX Выполните команду Isdev -С -с disk, чтобы увидеть список известных дисков в системе. Затем выполните команду Ispv, чтобы увидеть, какие ди- ски уже настроены для управления томами. Устройство, которое есть в пер- вом списке, но не во втором, и есть ваш новый диск. Допустим, что он назы- вается hdiskl. Затем выполните следующую последовательность команд, выбирая подходящие име- на для групп тома (vgname), логического тома (volname) и точки монтирования (mount- point), например homevg, home или /home. $ sudo mkvg -у vgname hdiskl #Создаем группу тома $ Isvg vgname #Отмечает значение freespace MAX LVs: 256 FREE PPs: 325 (freespace, Мб) $ sudo crfs -v jfs2 -g vgname -m mountpoint -a size=freespaceM $ sudo mkdir mounpoint $ sudo mount mounpoint Более подробную информацию о файлах устройств для дисков в системе AIX можно найти в разделе 8.5. Информация о разбиении диска на логические разделы в системе AIX приведена в разделе 8.6. Файловая система JFS2 обсуждается в разделе 8.9. 8.2. Аппаратное обеспечение дисковой памяти Даже сегодня в мире Интернета есть лишь несколько способов хранения компьютер- ных данных: жесткие диски, флеш-память, магнитные ленты и оптические устройства. Последние две технологии имеют существенные ограничения, которые не позволяют рассматривать их в качестве средства для создания базовой файловой системы. Однако они по-прежнему широко используются для резервного копирования и организации хранения данных с автоматически устанавливаемыми носителями (“near-line” storage), поскольку в этих ситуациях мгновенный доступ и возможность повторной записи не яв- ляются главными факторами. Ш Обзор современных технологий, основанных на использовании магнитных лент, приведен в разделе 10.2. После 40 лет развития технологии жестких дисков разработчики систем наконец-то получили реальную альтернативу — флеш-диски (SSD). Эти устройства предлагают дру- гой набор функциональных возможностей, которые отличаются от возможностей жест- ких дисков и которые в ближайшие годы окажут сильное влияние на архитектуру баз дан- ных, файловых и операционных систем. о то же время традиционные жесткие диски продолжают резко увеличивать свою ем- кость. Двадцать лет назад жесткий диск емкостью 60 Мбайт стоил одну тысячу долла- ров. В настоящее время существует широкий выбор жестких дисков емкостью 1 Тбайт, оторые стоят около 80 долл. Это означает, что за те же деньги можно в 200 тысяч раз етеличить емкость дисковой памяти, а объем памяти каждые 1,15 года вдвое превыша- За^е стоимость. Этот показатель почти в два раза превышает скорость, предсказанную мас°Н°М В этот же период последовательная пропускная способность устройств сового производства увеличилась с 500 Кбайт/с до 100 Мбайт/с, что составляет всего
256 Часть I. Основы администрирования лишь 200-кратное увеличение. В то же время организация прямого доступа к памяти по- прежнему стоит дорого. В общем, “с этих пор по-новому остается все по-старому”. В последние годы появилась третья, гибридная, категория жестких дисков с больши- ми буферами флеш-памяти, которые пока не вышли на уровень массового производ- ства. Пока неизвестно, по каким причинам это не произошло: техническим, производ- ственным или рыночным. Они могут появиться на рынке, но их потенциальное влияние на состояние дел пока остается неясным. Размеры дисков указываются в гигабайтах, которые составляют миллиарды байтов, в отличие от памяти, объем которой указывается в двоичных гигабайтах, которые равны 230 байт (1 073 741 824 байт). Разница составляет около 7%. При оценке и сравнении ем- кости дисков и устройств памяти об этом следует помнить. CQ Более подробная информация о стандартных единицах измерения приведена в разде- ле 1.8. Жесткие и флеш-диски довольно похожи друг на друга, поэтому они где-то взаимо- заменяемы, по крайней мере на уровне аппаратного обеспечения. Они используют оди- наковые интерфейсы аппаратного обеспечения и интерфейсные протоколы. Однако они имеют разные параметры, которые приведены в табл. 8.1. Таблица 8.1. Максимальные размеры передаваемых блоков в сетях различных типов Характеристики ' ЖЙЙёДИски Объем Терабайты Гигабайты Время прямого доступа 8мс 0,25 мс Последовательное считывание 100 Мбайт/с 250 Мбайт/с Случайное считывание 2 Мбайт/с 250 Мбайт/с Стоимость 0,10 долл./Пбайт 3 долл./Пбайт Надежность Средняя Неизвестна Ограничения записи Нет Да В следующих разделах мы рассмотрим эти технологии более подробно. Жесткие диски Обычный жесткий диск состоит из нескольких вращающихся пластин, покрытых магнитным слоем. Считывание и запись данных осуществляются с помощью маленьких скользящих головок, смонтированных на металлическом рычаге, который перемещает их вперед и назад. Головки расположены близко к поверхности пластин, но не при- касаются к ним. Считывание с пластины осуществляется быстро; оно сводится к механическому пере- мещению головки в требуемый сектор. В то же время существует два источника задержки. Рычаг, на котором расположены головки, должен резко перескакивать на соответ- ствующую дорожку. Время, которое требуется для этого, называется задержкой поиска (seek delay). Затем система должна подождать, пока требуемый сектор не окажется под головкой при вращении пластины. Время, которое требуется для этого, называется вре- менем ожидания (rotational latency). Если последовательность операций чтения органи- зована оптимально, то диски могут передавать данные со скоростью до десятков мега- байтов в секунду, но скорость прямого доступа в лучшем случае составляет несколько мегабайтов в секунду.
g дисковая память 257 Совокупность дорожек на разных пластинах, которые находятся на одинаковом тоянии от оси вращения, называется цилиндром. Данные, расположенные на ци- Р*0 лое можно считывать, не перемещая рычаг. Несмотря на то что головки работают ЛИ вычайно быстро, они перемещаются намного медленнее, чем вращается диск. Сле- ЧРвательно, любой доступ к диску, не требующий перемещения головки в новую пози- цию, будет выполняться быстрее. Со временем скорость вращения пластин увеличилась. В настоящее время стан- дартная скорость вращения на дисках массового производства, ориентированных на высокую скорость доступа, составляет 7 200 оборотов в минуту (RPM — revolutions per minute), а лучшие диски достигают скорости 10 и 15 тысяч оборотов в минуту. Более высокая скорость вращения уменьшает время ожидания и увеличивает пропускную спо- собность при передаче данных, но при этом диски нагреваются. Жесткие диски часто выходят из строя. В 2007 году подразделение Google Labs, изу- чив 100 тыс. дисков, удивило техническое сообщество сообщением, что средний ежегод- ный процент отказов (annual failure rate — AFR) жестких дисков, проработавших более двух лет, превышает 6%, что намного больше показателя, предсказанного производи- телями на основе экстраполяции результатов краткосрочных тестирований. Поведение дисков можно описать так: несколько месяцев риска “детской смертности”, два года безупречной работы, а затем ежегодный процент отказов взлетает до 6—8%. В целом, ве- роятность пятилетнего “выживания” жестких дисков в исследовании компании Google не превышает 75%. Интересно, что компания Google не нашла корреляции между процентом отказов и двумя факторами внешней среды, которые ранее считались важными, — температурный режим работы и активность диска. Полный отчет можно найти по адресу: tinyurl. com/fail-pdf. Отказы дисков, как правило, связаны с повреждением либо поверхности пластин (сбойные блоки), либо механических компонентов. Программно-аппаратные средства и интерфейсы аппаратных устройств после сбоя обычно остаются работоспособными, поэтому существует возможность выяснить детали происшедшего сбоя (см. раздел 8.5). Надежность диска производители обычно измеряют с помощью среднего времени между двумя сбоями (mean time between failures — MTBF), которое измеряется часами. Обычно значение показателя MTBF у промышленного диска составляет 1,2 млн часов. Однако этот показатель носит статистический характер и означает, что конкретный диск проработает 140 лет до первого сбоя. Показатель MTBF является обратным по отношению к показателю AFR, вычислен- ному для установившегося режима работы диска, т.е. после включения в систему, но до износа. Показатель MTBF, указываемый производителями и равный 1,2 млн часов, со- ответствует показателю AFR, равному 0,7% в год. Это значение почти (но не совсем) совпадает с показателем, выявленным компанией Google (1-2%) на протяжении первых Двух лет работы их тестовых дисков. Возможно, показатель MTBF, указываемый производителями, точен, но он получен на основе преднамеренного подбора данных о самом благополучном периоде работы Дисков. Следовательно, этот показатель можно считать лишь верхней границей надеж- ности, но его нельзя использовать для прогнозирования фактического процента отказов Долгосрочной перспективе. Основываясь на приведенных выше данных, следует раз- елить показатель MTBF, объявленный производителями, на 7,5 или перейти к более Мистичным методам выявления частоты отказов за пять лет.
258 Часть I. Основы администрирования Жесткие диски представляют собой товар. Одна модель может оказаться лучше дру- гой, имея одинаковые скорость вращения, интерфейс аппаратного обеспечения и уро- вень надежности. В настоящее время существуют специализированные лаборатории, которые проводят сравнительный анализ конкурирующих дисков. Флеш-диски Флеш-диски (SSD) распределяют операции считывания и записи по группам ячеек памяти, каждая из которых по отдельности медленнее, чем современные жесткие диски. Однако, благодаря параллельной работе, диски SSD в целом соответствуют ширине по- лосы пропускания традиционных дисков и даже превосходят ее. Огромное преимуще- ство флеш-дисков в том, что они продолжают хорошо работать даже тогда, когда проис- ходит прямой доступ к данным для чтения или записи. Эта особенность является очень привлекательной в реальных условиях. Производители дисковой памяти любят приводить скорость последовательной пере- дачи данных для своей продукции, поскольку эти числа впечатляюще высокие. Однако для традиционных жестких дисков этот показатель практически не связан с пропускной способностью, наблюдаемой при чтении и записи с прямым доступом. Например, ско- рость последовательной передачи данных высокопроизводительных дисковых устройств компании Western Digital может достигать 120 Мбайт/с, но их скорость прямого досту- па составляет примерно 2 Мбайт/с. В противоположность этому, современные диски SSD производства компании Intel обеспечивают скорость передачи данных, равную 30 Мбайт/с в обоих режимах работы. Тем не менее эта производительность достигается дорогой ценой. Накопители SSD не только дороже в перерасчете на гигабайт, чем жесткие диски, но и порождают новые сложности и неопределенности. Каждая страница флеш-памяти на диске SSD (в современных дисках ее размер ра- вен четырем двоичным килобайтам) может быть перезаписана ограниченное количество раз (обычно 100 тысяч, в зависимости от использованной технологии). Для того что- бы ограничить износ страницы, программное обеспечение дисков SSD ведет таблицы отображений и распределяет записи по всем страницам накопителя. Эти отображения остаются скрытыми от операционной системы, которая рассматривает накопитель как последовательный ряд блоков. Такой накопитель можно считать виртуальной памятью. Еще одна сложность заключается в том, что страницы флеш-памяти должны быть очищены, прежде чем использовать их для перезаписи. Очистка представляет собой от- дельную операцию, которая выполняется медленнее, чем сама запись. Кроме того, не- возможно очистить отдельные страницы — кластеры или смежные страницы (как пра- вило, они составляют 128 или 512 Кибибайт). Если пул заранее очищенных записей исчерпан, то производительность записи на SSD-накопитель может значительно сни- зиться и устройство должно восстановить страницы на лету, чтобы продолжить запись. Перестроить буфер очищенных страниц труднее, чем кажется, потому что файловые системы обычно не отмечают и не очищают блоки данных, которые больше не исполь- зуются. Накопитель не знает, что файловая система считает данный блок свободным; он знает только, что кто-то когда-то записал в него данные для хранения. Для того чтобы SSD-накопитель мог поддерживать работу кеша очищенных страниц (а значит, обеспечи- вать высокую производительность записи), файловая система должна иметь возможность сообщать SSD-накопителю, что определенные страницы больше не нужны. Этой воз- можностью обладают только файловые системы ext64 и NTFS в операционной системе
гияна 8. Дисковая память__________________________________________ 259 Windows 7. Однако, учитывая огромный интерес к SSD-накопителям, можно не сомне- ваться, что и другие файловые системы в ближайшем будущем внедрят этот механизм. Дополнительной сложностью является выравнивание. Размер стандартного блока на иске равен 512 байт, но этот размер слишком мал для того, чтобы файловая система могла эффективно с ним работать.’ Файловые системы управляют кластерами, размеры которых колеблются от одного до восьми двоичных килобайтов, а слой трансляции ото- бражает кластеры файловой системы в дисковые блоки для чтения и записи. На жестком диске нет различия между началом и концом кластеров. Однако, по- скольку SSD-накопители могут читать и записывать данные только на страницах раз- мером четыре двоичных килобайта (несмотря на эмуляцию традиционных 512-байтовых блоков), границы кластеров и страниц на SSD-накопителе должны совпадать. Неже- лательно, чтобы логический кластер размером четыре двоичных килобайта начинался в средине одного физического кластера на SSD-накопителе и заканчивался в средине следующего. В этом случае SSD-накопитель может дважды считать и записать данные стольких физических страниц, сколько помещается в заданном количестве логических кластеров. Поскольку файловые системы отсчитывают свои кластеры начиная с того места, куда их записал накопитель, проблему выравнивания можно было бы решить путем выравни- вания разделов дисков по границам, начинающимся с байта, номер которого представ- ляет степень двойки. Эти разделы больше, чем размер SSD-накопителя или страницы файловой системы (например, 64 двоичных килобайта). К сожалению, схема разбиения диска Windows MBR, которую система Linux унаследовала, не выполняет такое выравни- вание автоматически. Проверьте диапазоны блоков, которые вы получили при разбие- нии диска, и убедитесь, что они выровнены, помня, что сама схема MBR занимает один блок. (Система Windows 7 выравнивает разделы для SSD-накопителей по умолчанию.) Теоретические лимиты перезаписи флеш-памяти, вероятно, меньше, чем казалось вначале. Исходя из простых арифметических соображений, можно понять, что при по- токе данных на скорости 100 Мбайт/с и объеме SSD-накопителя, равном 150 Гбайт, ли- мит перезаписей будет исчерпан за четыре года непрерывной работы. Однако более об- щие вопросы долгосрочной надежности SSD-накопителей еще не изучены. Флеш-диски представляют собой еще незрелый продукт и могут преподносить сюрпризы. Контроллеры, используемые внутри SSD-накопителей, быстро развиваются и в на- стоящее время сильно различаются по производительности. В результате рынок должен прийти к какой-то одной стандартной архитектуре этих устройств, но на это уйдет еще один или два года. В более короткой перспективе при покупке таких устройств следует проявлять осторожность. 20п^ТаТЬЯ ^нанда Шимпи (Anand Shimpi) о технологии SSD, появившаяся в марте 9 года, представляет собой превосходное описание преимуществ и недостатков этой технологии. Ее можно найти по адресу tinyurl. com/dexnbt. 8.3. Интерфейсы устройств хранения данных в настоящее время существует лишь несколько наиболее распространенных стандар- в интерфейса. Если система поддерживает несколько разных интерфейсов, следует ис- к ЛЬз°вать тот, который наилучшим образом удовлетворяет требования, предъявляемые скорости, надежности, мобильности и стоимости. * байтовый стандарт для жестких дисков постепенно выходит из употребления; см. Iwn. /Articles/377895.
260 Часть I. Основы администрирования • Интерфейс АТА (Advanced Technology Attachment), ранее известный под названи- ем IDE, был разработан как простой и недорогой интерфейс для персональных компьютеров. Вначале он был назван Integrated Drive Electronics, потому что кон- троллер устройства находился в той же коробке, что и пластины диска, а для обе- спечения взаимодействия между компьютером и дисками применялся протокол относительно высокого уровня. В настоящее время так работают все жесткие ди- ски, но в то время это было новшеством. Традиционный параллельный интерфейс АТА (РАТА) связывал диски с материн- ской платой с помощью ленточного кабеля, имеющего 40 или 80 жил. Этот тип дисков устарел, но все еще установлен на огромном количестве компьютеров. Диски с интерфейсом РАТА часто маркируются как IDE, чтобы отличить их от устройств SATA, которые будут описаны ниже, но на самом деле они являются устройствами АТА. Диски РАТА имеют умеренную скорость, большую память и невероятно низкую стоимость. • Последовательный интерфейс АТА (SATA) является наследником интерфейса РАТА. Кроме поддержки более высокой скорости передачи данных (в настоящее время она составляет 6 Гбайт), интерфейс SATA упрощает соединение с помощью более аккуратных и длинных кабелей. Интерфейс SATA имеет собственную под- держку замены дисков без перезагрузки системы (hot-swapping) и (необязательно) поддерживает создание очереди команд. Эти две функциональные возможности превратили интерфейс АТА в перспективную альтернативу устройствам SCSI на серверах. • Несмотря на то что интерфейс SCSI в настоящее время уже не так популярен, как раньше, он остается одним из наиболее широко распространенных дисковых ин- терфейсов. Он имеет несколько разновидностей, которые все, без исключения, поддерживают работу нескольких дисков на одной шине, а также разные уровни скорости и способы связи. Более подробно устройства SCSI описаны ниже. Производители накопителей памяти обычно используют интерфейсы SCSI в са- мых быстрых и надежных устройствах. Эти устройства стоят дороже, но это объяс- няется особенностями накопителей, а не интерфейса. • Fibre Channel — это последовательный интерфейс, популярный в промышленно- сти благодаря широкой полосе пропускания и большому количеству накопителей, которые он может соединять одновременно. Устройства Fibre Channel соединяются с помощью волоконно-оптических или коаксиальных медных кабелей. Скорость их работы колеблется от 1 до 40 Гбайт/с, в зависимости от версии протокола. Как правило, топология этих устройств представляет собой кольцо, которое на- зывается Fibre Channel Arbitrated Loops (FC-AL), или фабрику (коммутируемые сети — Примеч. ред.) с коммутаторами Fibre Channel. Интерфейс Fibre Channel поддерживает несколько разных протоколов, включая SCSI и даже IP. Устройства идентифицируются по “зашитым” восьмибайтовым идентификаторам (“World Wide Name”), напоминающим адреса Ethernet MAC. • Последовательные интерфейсы Universal Serial Bus (USB) и FireWire (IEEE 1394) стали популярными средствами соединения внешних жестких дисков. В настоя- щее время скорость их работы составляет 480 Мбайт/с для USB и 800 Мбайт/с для Firewire. Обе системы являются слишком медленными для того, чтобы принимать быстрые потоки данных с диска на полной скорости. Прогнозируемые изменения
глаВа 8. Дисковая память 261 обоих стандартов предусматривают более высокую скорость передачи данных (до 5 Гбайт/с для USB 3.0). В жестких дисках никогда не используются интерфейсы USB или FireWire. Вместо этого в дисковые модули, подсоединенные к этим портам, встраиваются конвер- торы SATA. Интерфейсы АТА и SCSI до сих пор доминируют среди накопителей, поэтому только ИХ мы обсудим подробно. Интерфейс РАТА Интерфейс РАТА (Parallel Advanced Technology Attachment), называемый также IDE, задумывался как простой и недорогой. Его чаще всего можно найти в дешевых персо- нальных компьютерах. Оригинальный интерфейс IDE стал популярен в конце 1980-х годов. Последующие версии протокола, кульминацией которых стала версия АТА-7 (известная также как Ultra АТА/133), включали в себя дополнительно режимы прямого доступа к памяти (DMA), свойства plug-and-play, адресацию логических блоков (LBA), управление электропитанием, возможности самоконтроля и скорость работы шины до 133 Мбайт/с. С момента появления интерфейса АТА-4 стандарт АТА объединился с про- токолом АТА Packet Interface (ATAPI), допускавшим присоединение к шине IDE диско- водов CD-ROM и лентопротяжных устройств. Разъем РАТА имеет 40 контактов, соединяющих накопитель с интерфейсной пла- той посредством грубого ленточного кабеля. Стандарты АТА, появившиеся после Ultra DMA/66, использовали кабель с 80 жилами, большим количеством заземляющих кон- тактов и вследствие этого с более низким уровнем электрических помех. Более изящ- ные кабели, допускающие скручивание ленты в толстую кабельную муфту, позволяют сделать шасси компактнее и улучшают воздухообмен. Кабель питания для накопителей РАТА использует массивный четырехконтактный штепсель Molex. Если кабель и/или накопитель не имеют ключа, то следует убедиться, что контакт 1 на накопителе входит в контакт 1 в гнезде интерфейса. Контакт 1 обычно обозначается маленькой цифрой “1” на одной стороне разъема. Если он не помечен, то его можно найти по следующему правилу: первый контакт ближе всего к разъему питания. Первый контакт на ленточном кабеле обычно маркируется красным цветом. Если вы не видите красной полосы на краю ленточного кабеля, то сделайте так, чтобы первый контакт ка- беля был соединен с первым контактом разъема, и пометьте кабель красным маркером. Большинство персональных компьютеров имеет две шины РАТА, к каждой из ко- торых присоединены два накопителя. Если к шине РАТА присоединено больше одно- го накопителя, вы должны назначить один из них главным, а другой — подчиненным, еремычка “выбора кабеля” на современных накопителях (обычно предусматриваемая по умолчанию) позволяет накопителям самим выбирать, какой из них будет главным, какой подчиненным. Иногда этот механизм работает неправильно. Тогда необходимо явно назначить главный и подчиненный накопители. лавный накопитель не имеет никаких преимуществ по производительности. Неко- Р*?е из стаРых накопителей РАТА не могут быть подчиненными, поэтому возникают дый ЛеМы’ которые решаются перестановкой ролей. Если же и это не помогает, то каж- накопитель РАТА следует поместить на отдельную шину. м азРешение конфликтов между главным и подчиненным накопителями на шине РАТА Hav 0Казаться относительно медленным, поэтому по возможности следует размещать °пители РАТА на отдельных шинах.
262 Часть I. Основы администрирования Интерфейсы SATA По мере возрастания скорости передачи данных для накопителей РАТА, недостатки этого стандарта становились все более очевидными. Электромагнитная интерференция и другие электрические проблемы снижали надежность работы накопителей на больших скоростях. Для решения этой проблемы были изобретены последовательные интерфей- сы АТА и SATA. В настоящее время они являются доминирующими среди устройств для хранения данных. Интерфейс SATA сгладил многие недостатки интерфейса РАТА. Он повысил ско- рость передачи данных (потенциально до 750 Мбайт/с и 6 Гбайт/с в перспективе) и реа- лизовал отличный механизм для проверки ошибок. Этот стандарт поддерживает замену накопителя без перезагрузки системы, создание очереди команд и многие другие сред- ства для повышения производительности. Интерфейс SATA отменил необходимость на- значать главный и подчиненный накопители, поскольку к каждому каналу подключен только один накопитель. Интерфейс SATA преодолел ограничение, связанное с использованием 18-дюмовых кабелей в интерфейсе РАТА, и ввел новые стандарты для кабелей питания и информа- ционных кабелей, состоящих из 7 и 15 жил соответственно.2 Эти кабели намного гибче и проще в работе, чем их ленточные предшественники, — больше нет необходимости из- гибать и скручивать кабели, чтобы подсоединить несколько накопителей на один ка- бель. Тем не менее похоже, что новый стандарт более чувствителен к качеству материала, чем старые ленточные кабели интерфейса РАТА. Мы видели несколько дешевых кабелей SATA, которые при попытке их использования приводили к отказу материнской платы.3 Кабели SATA легко входят в разъемы, но так же легко из них выпадают. Существуют кабели с фиксаторами, но они имеют как преимущества, так и недостатки. На материн- ских платах, в которых разъемы SATA упакованы по шесть или восемь штук, может ока- заться трудно высвободить фиксирующие разъемы без помощи тонких клещей. Интерфейс SATA ввел в действие новый стандарт кабелей под названием eSATA. С точ- ки зрения электрических свойств, эти кабели аналогичны кабелям SATA, но их разъемы немного отличаются. Вы можете добавить порт eSATA в систему, имеющую только вну- тренние разъемы SATA, инсталлировав недорогой конвертер. С внешними модулями, содержащими несколько накопителей, имеющих только один порт eSATA, следует быть осторожными — некоторые из них являются интеллекту- альными устройствами (RAID) и требуют оригинальные драйверы. (Эти драйверы редко поддерживают системы UNIX или Linux.) Другие модули не имеют сложной логики и содержат встроенный переходник для порта SATA. В принципе они допускают исполь- зование системы UNIX, но поскольку не все адаптеры ведущего контроллера SATA под- держивают расширение порта, следует уделить особое внимание вопросам совмести- мости. Модули с несколькими портами eSATA — по одному на накопитель — всегда являются безопасными. Параллельный интерфейс SCSI Интерфейс SCSI (Small Computer System Interface) определяет обобщенный кон- вейер данных, который можно использовать для любых периферических устройств. В прошлом он использовался для подсоединения дисков, лентопротяжных устройств, 2 Это правильно: по некоторым причинам кабель питания сложнее, чем информационный. 3 В США превосходным поставщиком качественных и дешевых кабелей SATA является сайт monoprice.com.
Глава 8. Дисковая память 263 сканеров и принтеров, но сейчас в большинстве случаев производители этих устройств отказались от интерфейса SCSI в пользу интерфейса USB. После 1986 года, когда был принят стандарт ANSI под названием SCSI-1, появилось много разновидностей интерфейса SCSI. Традиционный интерфейс SCSI использует от 8 до 16 жил. К сожалению, в названиях разновидностей параллельного интерфейса SCSI нет ни- какого смысла. Термины “fast”, “wide” и “ultra” вводились для того, чтобы подчеркнуть значительные преимущества интерфейса SCSI, но сейчас эти функциональные возмож- ности стали стандартными, и эти эпитеты исчезли из названий. Несмотря на свое на- звание, интерфейс Ultra SCSI на самом деле обеспечивает скорость передачи данных 20 Мбайт/с, что в настоящее время уже не является мечтой, но за ним последовали Ultra2, Ultra3, Ultra-320 и Ultra-640 SCSI. Для тех, кому интересно, приведем регулярное вы- ражение, соответствующее всевозможным разновидностям параллельного интерфейса SCSI. (Fast(-Wide)?|Ultra(( Wide)?|2 (Wide )?|3|-320|-640)?) SCSI|SCSI-[ 1 -3] Использовалось также множество разных разъемов. Они зависели от версии интер- фейса SCSI, типа соединения (внутреннее или внешнее) и количества бит пересылае- мых данных. На рис. 8.1 показаны некоторые из них. Каждый разъем показан спереди, как будто вы смотрите на них прямо. Centronics 50 контактов, SCSI-1/2, внешний Ленточный разъем (гнездо) 50 контактов, SCSI-1/2, внутренний Mini-micro, он же HD50 50 контактов, SCSI-2, внешний Wide mini-micro, он же HD68 68 контактов, SCSI-2/3, внутр/внеш SCA-2 80 контактов, SCSI-3, внутренний Рис. 8.1. Параллельные разъемы SCSI (вид спереди, все со штекерами, за исключе- нием указанного отдельно) В настоящее время продолжен выпуск только разъема SCA-2, имеющего 80 контак- тов, включая контакты питания и шины. Каждый конец шины SCSI должен иметь согласующий резистор (terminating resistor), называемый терминатором. Этот резистор поглощает сигналы, достигающие конца шины, и предотвращает отражение шума обратно в шину. Терминаторы бывают разны- ми — от небольших внешних разъемов, которые вставляются в обычный порт, до акку- ратных пакетов резисторов, встроенных в монтажные платы устройства. Большинство ^временных устройств предусматривает автоматическое отключение согласующего ре- зистора при подключении к разъему кабеля.
264 Часть I. Основы администрирования Если на вашей шине SCSI возникают проблемы, которые кажутся случайными, сна- чала проверьте согласующие резисторы на обоих концах шины. Неправильная работа согласующих резисторов является одной из основных проблем в старых системах SCSI, а ошибки, которые при этом возникают, могут быть нераспознанными и перемежающи- мися. Параллельные шины SCSI используют гирляндную цепь, так что большинство внешних устройств имеет два порта SCSI.4 Эти порты идентичны и взаимозаменяемы — любой из них может быть входом. Внутренние устройства SCSI (включая устройства с разъемами SCA-2) присоединяются к ленточному кабелю, поэтому для устройства ну- жен только один порт. Каждое устройство имеет SCSI-адрес, или “целевой номер”, отличающий его от дру- гих устройств, присоединенных к шине. Отсчет целевых номеров начинается с нуля и заканчивается семью или пятнадцатью, в зависимости от вида шины — узкой или широ- кой. Сам контроллер SCSI также рассматривается как устройство и обычно имеет номер 7. Целевые номера других устройств должны быть уникальными. Типичная ошибка воз- никает, когда пользователи забывают, что контроллер SCSI имеет свой целевой номер, и присваивают устройству тот же целевой номер. Если вам повезет, то устройство будет иметь внешний манипулятор, с помощью которого можно задать целевой номер. Еще одним распространенным способом установки целевых номеров являются переключа- тели DIP и перемычки. Если неясно, как установить целевой номер на устройстве, пои- щите справочное руководство в Интернете. Интерфейс SCSI поддерживает разновидность частичной адресации, которая исполь- зует “номера логических модулей”. Каждое целевое устройство может иметь внутри себя несколько логических модулей. Например, можно представить себе массив накопителей с несколькими дисками, но с одним контроллером SCSI. Если устройство SCSI имеет только один логический модуль, то он обычно по умолчанию устанавливается равным нулю. Использование логических номеров обычно ограничивается большими массивами накопителей. Если вы услышите выражение “номер модуля SCSI”, то должны предпо- ложить, что на самом деле речь идет о целевом номере, пока не доказано обратное. Системному администратору, работающему с аппаратным обеспечением SCSI, следу- ет помнить о следующем. • Не беспокойтесь о точных версиях SCSI, которые поддерживает устройство; смо- трите на разъемы. Если два устройства SCSI имеют одинаковые разъемы, значит, они совместимы. Однако это еще не значит, что они могут обеспечить одинаковую скорость работы. Передача данных будет происходить со скоростью, на которой работает более медленное устройство. • Даже если разъемы отличаются друг от друга, устройства все равно могут быть со- вмещены с помощью адаптера, если их разъемы имеют одинаковое количество контактов. • Многие старые рабочие станции имеют внутренние устройства SCSI, такие как лентопротяжные механизмы и дисководы гибких дисков. Перед тем как переза- грузить систему, после добавления нового устройства, проверьте список текущих устройств. 4 “Гирляндная цепь” — это общепринятое название, но оно может ввести в заблуждение. Параллельный интерфейс SCSI физически представляет собой цепь, а с электротехнической точ- ки зрения — это отдельная шина.
Глава 8. Дисковая память 265 • Добавив новое устройство SCSI, проверьте список устройств, выдаваемый ядром при перезагрузке, чтобы убедиться, что все в порядке. Большинство драйверов SCSI не распознает ситуации, в которых несколько устройств имеют одинаковые SCSI-адреса (это недопустимо). Конфликт SCSI-адресов порождает неправильное поведение системы. • Если вы наблюдаете ненадежную работу системы, проверьте, не возник ли кон- фликт целевых номеров, а также проверьте согласующие резисторы на шине. • Помните, что ваш контроллер SCSI использует один из SCSI-адресов. Последовательный интерфейс SCSI Аналогично устройствам РАТА, параллельному интерфейсу SCSI соответствует по- следовательный интерфейс SCSI (Serial Attached SCSI — SAS), являющийся аналогом интерфейса SATA. С точки зрения аппаратного обеспечения интерфейс SAS улучшает практически все аспекты традиционного параллельного интерфейса SCSI. • Сцепленные шины устарели. Подобно интерфейсу SATA, интерфейс SAS пред- ставляет собой позиционную систему (point-to-point system). Интерфейс SAS по- зволяет использовать расширители (expanders) для присоединения нескольких устройств к одному порту компьютера. Они напоминают мультипликаторы порта SATA, но в то время как поддержка мультипликаторов иногда реализуется, а ино- гда нет, расширители поддерживаются всегда. • Интерфейс SAS не использует терминаторы. • Целевые номера устройств SCSI больше не используются. Вместо этого каждое уст- ройство SAS имеет назначенное производителем 64-битовое имя World Wide Name (WWN), характерное для оптико-волоконных полей. Они аналогичны адресам Ethernet МАС. • Количество устройств на шине SCSI (фактически, “домен SAS”) больше не огра- ничено восемью или шестнадцатью. К шине можно присоединять до 16 384 уст- ройств. Интерфейс SAS в настоящее время функционирует на скорости 3 Гбайт/с, но ско- рость вскоре планируется довести до 6 Гбайт/с, а в 2012 году — до 12 Гбайт/с. Что лучше: SCSI или SATA? В прошлом интерфейс SCSI был очевидным выбором для серверных приложений. Он обеспечивал максимально широкую полосу пропускания, выборочное выполнение команд (что эквивалентно созданию очередей помеченных команд), меньшую загрузку Центрального процессора, более простое обслуживание большого количества накопите- лей и доступ к самым современным дискам. После появления интерфейса SATA интерфейс SCSI больше не обеспечивает от- дачу от вложенных средств. Устройства SATA сравнимы с эквивалентными дисками SCSI практически в каждой категории (а иногда даже превосходят их). В то же время и Устройства SATA, и интерфейсы, и кабели, используемые для их соединения, дешевле и более распространены. Впрочем, интерфейс SCSI по-прежнему имеет несколько “козырей”. • Производители продолжают использовать разделение SATA/SCSI для стратифика- ции рынка накопителей. Для того чтобы обосновать высокие цены, самые быстро-
266 Часть I. Основы администрирования действующие и надежные накопители по-прежнему поставляются только с интер- фейсами SCSI. • Интерфейс SATA ограничен глубиной очереди, вмещающей 32 незавершенные операции. Интерфейс SCSI может обслуживать тысячи операций. • Интерфейс SAS может обслуживать много накопителей (сотни и тысячи) с помо- щью одного компьютера. Однако следует иметь в виду, что все эти устройства ис- пользуют один и тот же канал связи с этим компьютером; вы по-прежнему огра- ничены общей шириной полосы пропускания, составляющей 3 Гбайт/с. Споры об интерфейсах SAS и SATA могут в конце концов оказаться бессмысленны- ми, поскольку стандарт SAS включает поддержку устройств SATA. Разъемы SAS и SATA достаточно похожи друг на друга, чтобы одна кабельная укладка могла работать с любым типом. На логическом уровне команды интерфейса SATA просто туннелируются через шину SASA. Это сходство является удивительным техническим достижением, но экономиче- ское обоснование для него менее очевидно. Расходы на инсталляцию интерфейса SAS, в основном, относятся к адаптеру компьютера, кабельной укладке и инфраструктуре; накопители SAS сами по себе не слишком дорогие. Однажды вложив средства в уста- новку интерфейса SAS, вы будете вынуждены придерживаться его до конца. (С другой стороны, возможно, умеренная стоимость накопителей SAS является результатом того, что их легко заменить накопителями SATA.) 8.4. Программное обеспечение накопителей Если вам когда-нибудь приходилось подсоединять диск и система Windows спраши- вала вас, не желаете ли вы его отформатировать, вы могли поразиться тому, насколько сложным является управление накопителями в системах UNIX и Linux. Почему же оно такое сложное? Для начала отметим, что на некоторых системах вы можете зарегистрироваться на системном компьютере, присоединить к нему накопитель USB и работать практически так же, как в системе Windows. Вы получите возможность выполнить простую процедуру установки накопителя для хранения персональных данных. Если это все, что вам нужно, то все в порядке. Как обычно, в этой книге нас интересуют промышленные системы хранения данных: файловые системы, доступ к которым имеет множество пользователей (локальных и удаленных) и которые в то же время являются надежными, высокопроизводительными, допускающими простое резервирование и обновление. Такие системы требуют немного больше осторожности, и системы UNIX и Linux дают для этого достаточно оснований. Типичный набор компонентов программного обеспечения, обеспечивающих взаимо- действие между накопителем и его пользователями, приведен на рис. 8.2. Архитектура, показанная на рис. 8.2, относится к системе Linux, но и другие операционные системы обладают аналогичными возможностями, хотя и не обязательно в точно таком же виде. Стрелки на рис. 8.2 означают “могут быть построены из”. Например, файловая си- стема Linux может быть создана на основе раздела, массива RAID или логического тома. Создание стека модулей, соединяющих каждый накопитель с его окончательным при- ложением, является одной из задач администратора. Внимательный читатель заметит, что этот граф имеет цикл, а в реальных конфигу- рациях циклов не бывает. Система Linux допускает создание стеков из массивов RAID
Глава 8. дисковая память 267 0 логических томов в любом порядке, но ни один из компонентов не может использо- ваться больше одного раза (хотя с технической точки зрения это возможно). Файловые системы, области подкачки, хранение в базе данных | ---- ------------------------------------------.........................у.-.......,ийнВ yin iinni.iinw Логические томы | Разделы Массивы RAID Группы томов I ..I"; < * * ........♦ 1 пт— Накопители Рис, 8.2, Уровни управления накопителем Рассмотрим фрагменты рис. 8.2. • Накопитель (storage device) — это все, что напоминает диск. Это может быть жест- кий диск, флеш-накопитель, диск SSD, внешний массив RAID, реализованный в виде аппаратного обеспечения, и даже сетевая служба, обеспечивающая доступ к удаленному устройству на уровне блока. Конкретный вид оборудования значения не имеет, поскольку устройство допускает прямой доступ, обрабатывает блочный ввод-вывод и представлено файлом устройства. • Раздел (partition) — это фрагмент накопителя, имеющий фиксированный размер. Каждый раздел имеет собственный файл устройства и действует как независимый накопитель. Для обеспечения эффективности разделы создаются с помощью того же драйвера, который используется для управления устройством. Большинство схем разделения занимает несколько блоков в начале накопителя для записи диа- пазонов блоков, которые занимает каждый раздел. Разделение диска постепенно становится исчезающей функциональной возмож- ностью. Системы Linux и Solaris сохранили ее для обеспечения совместимости с дисками, разделенными на разделы с помощью системы Windows. Системы HP- UX и AIX практически отказались от разделения дисков в пользу управления логи- ческими томами, но в системах HP-UX, основанных на микропроцессоре Itanium, разделение дисков остается обязательным. • Массив RAID (избыточный массив недорогих и независимых дисков) объединя- ет многочисленные накопители в одно виртуальное устройство. В зависимости от настройки этого массива, эта конфигурация может повысить производительность (путем чтения и записи дисков в параллельном режиме) или надежность (путем дублирования и проверки данных с контролем четности на всех дисках) или оба этих показателя. Как следует из названия, массив RAID обычно интерпретируется как совокуп- ность обычных дисков, но современные реализации позволяют использовать в ка- честве компонента этого массива все, что функционирует как диск. • Группы томов и логические тома ассоциируются с менеджерами логических то- мов (LVM — logical volume manager). Эти системы объединяют физические устройства и формируют пул накопителей, которые называются группами томов.
268 Часть I. Основы администрирования Администратор может разделить этот пул на логические тома почти так же, как диски разбиваются на разделы. Например, диск объемом 750 Гбайт и диск объе- мом 250 Гбайт можно объединить в группу томов объемом 1 Тбайт, а затем разбить на два логических тома по 500 Гбайт. По крайней мере, один том будет содержать блоки данных, относящиеся к обоим жестким дискам. Поскольку менеджер логических дисков добавляет уровень косвенной адресации между логическими и физическими блоками, он может зафиксировать логиче- ское состояние тома, просто сделав копии таблицы отображений. Следовательно, менеджеры логических томов часто обеспечивают возможность “мгновенных ко- пий”. Затем том связывается с новыми блоками, и менеджер LVM сохраняет ста- рую и новую таблицы отображений. Разумеется, менеджер LVM должен хранить как исходный образ, так и все модифицированные блоки, поэтому в конце концов он исчерпает память, если мгновенные копии никогда не удаляются. • Файловая система служит посредником между набором блоков, представленных разделом, массивом RAID, логическим блоком и стандартным интерфейсом фай- ловой системы, ожидаемым программами: путями вроде /var/spool/mail, типа- ми файлов системы UNIX, разрешениями системы UNIX и т.п. Файловая систе- ма решает, где и как хранится содержимое файлов, как представить пространство имен и организовать поиск на диске, а также как избежать сбоя (и восстанавли- ваться после него). Большая часть накопителя является частью файловой системы, но область подкач- ки и хранение в базе данных могут быть потенциально чуть более эффективными без “помощи” от файловой системы. Ядро или база данных навязывают накопите- лю свою собственную структуру, делая файловую систему излишней. Если вы считаете, что эта система содержит слишком много маленьких компонентов, которые просто реализуют один блочный накопитель через другой, то совершенно пра- вы. В последнее время наблюдается тенденция в сторону консолидации этих компонен- тов, чтобы повысить эффективность и устранить дублирование. Хотя менеджеры логи- ческих томов изначально не функционировали как контроллеры RAID, большинство из них воплотили некоторые функциональные возможности массивов RAID (в частности, распределение данных и мониторинг). Как только администраторы получили удобные средства управления логическими томами, разделы также исчезли. В настоящее время на передовом крае находятся системы, объединяющие файловую систему, контроллер RAID и систему LVM в один интегрированный пакет. Ярким при- мером является файловая система ZFS, но и файловая система Btrfs для Linux предна- значена для решения аналогичных задач. Система ZFS описывается в разделе 8.10. Большинство установок относительно просты. На рис. 8.3 показана традицион- ная схема разбиения диска, которую можно найти на многих дисках в системе Linux. (Загрузочный диск не показан.) Если подставить вместо разделов логические тома, то установка станет похожей на инсталляцию других систем. В следующих разделах мы детальнее рассмотрим этапы, из которых состоят фазы конфигурирования носителей, — контроль устройств, разбиение, RAID, управление ло- гическим томом и инсталляция файловой системы. В заключение мы опишем систему ZFS и сети хранения данных.
Глава 8. Дисковая память 269 Уровень файловой системы Уровень раздела Физический уровень Рис. 8.3. Традиционная схема разбиения диска (имена устройств в системе Linux) 8.5. Присоединение и низкоуровневое УПРАВЛЕНИЕ НАКОПИТЕЛЯМИ Способ присоединения диска к системе зависит от используемого интерфейса. Ос- тальное определяется монтажными кронштейнами и кабелями. К счастью, разъемы SAS и SATA хорошо защищены. При работе с параллельным интерфейсом SCSI необходимо перепроверить, что оба конца шины SCSI имеют терминаторы, длина кабеля не превышает максимально до- пустимую и новый целевой номер SCSI не конфликтует с контроллером или другим устройством, присоединенным к шине. Даже если интерфейсы допускают подключение без перезагрузки системы (“горячее” подключение), все же безопаснее выключить систему перед тем, как вносить измене- ния в аппаратное обеспечение. Некоторые старые системы, такие как AIX, устанавлива- ют конфигурацию устройств только во время загрузки, поэтому “горячее” подключение аппаратного обеспечения может не сразу вступить в силу на уровне операционной систе- мы. При работе с интерфейсами SATA, “горячее” подключение зависит от реализации. Некоторые адаптеры компьютеров не поддерживают эту функциональную возможность. Верификация инсталляции на уровне аппаратного обеспечения После инсталляции нового диска следует убедиться, что система знает о его суще- ствовании на самом низком из возможных уровней. Для персональных компьютеров это несложно: система BIOS показывает диски IDE и STAT, а большинство микросхем SCSI имеет собственный экран настроек, который вызывается перед загрузкой системы. Для других типов аппаратного обеспечения может потребоваться перезагрузка систе- мы и проверка результатов диагностики, выполняемой ядром. Например, одна из про- веренных нами систем вывела на экран следующие сообщения для старого диска SCSI, присоединенного к адаптеру SCSI BusLogic. scsiO: BusLogic ВТ-948 scsi: 1 host. vendor: SEAGATE Model: ST446452W Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsiO, channel 0, id 3, lun 3 scsiO: Target 3: Queue Depth 28, Asynchronous SCSI device sda: hdwr sector=512 bytes. Sectors=91923356 [44884 MB] [44,8 GB]
270 Часть I. Основы администрирований Эту информацию можно обнаружить в файлах системного журнала после загрузки системы. Более подробно обработка сообщений, выдаваемых ядром при загрузке, опи- сывается в разделе 11.2. Файлы накопителя Вновь добавленный диск представляется файлами накопителя в каталоге /dev. Все рассмотренные нами системы создают такие файлы автоматически, но систем- ный администратор по-прежнему обязан знать, где искать файлы накопителя и какие из них соответствуют новому устройству. Форматирование неправильного накопителя — это прямой путь к катастрофе. В табл. 8.2 приведены соглашения об именах дисков, принятые в рассматриваемых операционных системах. Вместо демонстрации абстракт- ного шаблона, по которому дискам присваиваются имена, в табл. 8.2 приводится ти- пичный пример выбора имени первого диска в системе. Таблица 8.2. Стандарты именования дисков Система Блочноеустройство Устройство Раздел Linux /dev/sda не используется /dev/sda 1 Solaris /dev/dsk/c0t0d0s2 /dev/rdsk/c0t0d0s2 /dev/dsk/cOtOdOsO HP-UX а /dev/disk/diskO /dev/rdisk/diskO /dev/disk/disk0_p1 6 AIX /dev/hdiskO /dev/rhdiskO а Для сохранения совместимости система HP-UX использует также имена устройств, принятые в системе Solaris. 6 Только для системы на процессоре Itanium; остальные системы не имеют разделов. Столбцы, соответствующие блокам и устройствам, содержат пути к диску в целом, а столбец, соответствующий разделу, демонстрирует путь к конкретному разделу. Дисковые накопители для системы Linux ДИмена дисков в системе Linux присваиваются ядром последовательно при нумерации разных интерфейсов и устройств, существующих в системе. При добавлении нового диска имя старого может измениться. Фактически даже перезагрузка системы может вызвать изменение имен.5 Никогда не вносите изменения, не идентифицировав диск, с которым работаете, даже в устойчи- вой системе. Система Linux предлагает несколько способов решения этой проблемы. Подкаталоги каталога /dev/disk содержат характеристики дисков, например их идентификаци- онный номер, присвоенный производителем, или информацию о разъеме. Эти имена устройств (которые на самом деле представляют собой обычные ссылки на /dev/sd*) являются постоянными, но они длинные и громоздкие. На уровне файловых систем и массивов дисков система Linux использует уникальные строки, которые персистентно идентифицируют объект. Во многих случаях эти длинные строки скрыты, так что вам не придется работать с ними непосредственно. 5 Для того чтобы решить эту проблему, система Linux использует идентификаторы UUID из файла /etc/f stab, а не имена устройств (см. раздел 8.9).
Глава 8. Дисковая память 271 Система Linux не хранит файлы для отдельных накопителей или разделов дисков, поэтому следует указывать блочные устройства, когда необходимо сослаться на отдель- ное устройство. Команда parted -1 перечисляет размеры, таблицы разделов, номера моделей и про- изводителей каждого диска, существующего в системе. дисковые накопители для системы Solaris Система Solaris присваивает дискам имена, подобные /dev/ [г] dsk/cWtXdYsZ, soiaris где W — номер контроллера, X — целевой номер SCSI, Y — номер логического модуля SCSI (или номер LUN, который практически всегда равен 0), a Z — номер раздела (сектора). Здесь существует множество тонкостей: накопители АТА называются cWdYsZ (без пункта t), а диски могут иметь как ряд раз- делов в стиле DOS, обозначаемых как pZ, так и сектора в стиле Solaris, обо- значаемые как sZ. Эти файлы устройств на самом деле представляют собой всего лишь символические ссылки в дереве /devices, в котором размещены реальные файлы устройств. В целом, система Solaris предприняла попытку обеспечить постоянство имен устройств, даже при изменении аппаратного обеспечения. Как только диску присвоено определенное имя, он будет найден под этим именем в любой момент в будущем, если вы не измените кон- троллеры или целевые номера SCSI. По соглашению сектор 2 соответствует полному, не разбитому на разделы диску. В отличие от системы Linux, система Solaris создает файлы устройства для каждого сек- тора и раздела, независимо от того, существуют ли они на самом деле. Система Solaris также поддерживает перекрывающиеся разделы, но это просто безумная идея. С таким же успехом компания Oracle могла бы поставлять системы Solaris вместе с заряженным пистолетом в нагрузку. В системе Solaris “горячее” подключение должно работать хорошо. Когда вы добав- ляете новый диск, команда devf sadmd должны распознать его и создать соответствую- щие файлы устройств. При необходимости эту команду можно выполнить вручную. Дисковые накопители для системы HP-UX ЕЗ Традиционно система HP-UX заимствовала правила именования дисков у си- стемы Solaris, которая записывает в каталогах много информации об аппарат- ном устройстве. Однако в версии HP-UX Hi v3 эти каталоги были исключе- ны и предпочтение было отдано гибким адресам, имеющим вид /dev/disk/ diskl. Такие пути являются более устойчивыми и не заполняются деталями, относящимися к конфигурации системного аппаратного обеспечения. Прежде чем загружать систему UNIX, от монитора PROM можно получить листинг системных устройств SCSI. К сожалению, точный способ выдачи этого листинга зави- сит от компьютера. После загрузки можно получить список дисков, выполнив команду ioscan. $ sudo ioscan -fNn -C disk Class I H/W Path Driver S/W State H/W TypeDescription disk 3 64000/0xfa00/0x0 esdisk CLAIMED DEVICE TEACDV-28E-B /dev/disk/disk3 /dev/rdisk/disk3 disk 4 64000/0xfa00/0xl esdisk CLAIMED DEVICE HP 73.4GMAS3735NC /dev/disk/disk4 /dev/rdisk/disk4
272 Часть I. Основы /dev/disk/disk4_pl /dev/rdisk/disk4_pl /dev/disk/disk4_p2 /dev/rdisk/disk4_p2 /dev/disk/disk4_p3 /dev/rdisk/disk4_p3 disk 5 64000/0xfa00/0x2 esdisk CLAIMED DEVICE HP 73.4GMAS3735NC /dev/disk/disk5 /dev/rdisk/disk5 /dev/disk/disk5_pl /dev/rdisk/disk5_pl /dev/disk/disk5_p2 /dev/rdisk/disk5_p2 /dev/disk/disk5_p3 /dev/rdisk/disk5_p3 В каталогах /dsk и /rdsk все еще используются имена дисков старого стиля, при желании их можно использовать, по крайней мере, пока. Для того чтобы уви- деть соответствие между имена в старом и новом стилях, следует выполнить команду ioscan -m dsf. hp-ux$ ioscan -m dsf Persistent DSF6 Legacy DSF(s) /dev/rdisk/disk3 /dev/rdisk/disk4 /dev/rdisk/disk4_pl /dev/rdisk/disk4_p2 Zdev/rdisk/disk4_p3 /dev/rdisk/disk5 /dev/rdisk/disk5_pl /dev/rdisk/disk5_p2 /dev/rdisk/disk5_p3 /dev/rdsk/cOtOdO Zdev/rdsk/c2tld0 /dev/rdsk/c2tld0sl /dev/rdsk/c2tld0s2 Zdev/rdsk/c2tld0s3 /dev/rdsk/c2tld0 /dev/rdsk/c2tld0sl /dev/rdsk/c2tld0s2 /dev/rdsk/c2tld0s3 Обратите внимание на то, что разделы теперь обозначаются буквой р, а не s, как в системе Solaris (“s” означает “slice” — сектор). В отличие от системы Solaris, для пред- ставления целых дисков система HP-UX использует такие имена, как disk3 без суф- фикса раздела. В системе Solaris раздел 2 соответствует целому диску, а в системе HP- UX — это просто другой раздел. Система, из которой взят данный пример, основана на процессоре Itanium и поэто- му имеет разделы дисков. Другие системы HP-UX вместо разбиения дисков используют управление логическими томами. Дисковые накопители для системы AIX • Пути /dev/hdisk и /dev/rhdisk являются очень простыми. К сожалению, при изменении конфигурации аппаратного обеспечения имена дисков изме- няются. Однако большинство дисков в системе AIX управляется менеджера- ми логических томов, поэтому имена устройств не имеют большого значения. Включая диск в группу томов, менеджер логического тома записывает на него уникальный идентификатор. Эти метки позволяют системе автоматически классифицировать диски, так что изменения в именах устройств не имеют та- ких последствий, как в других системах. Для того чтобы увидеть список дисков, инсталлированных в системе, следует выпол- нить команду Isdev -С -с disk. 6 DSF - device special file (специальный файл устройства).
Глава 8. Дисковая память 273 Форматирование и плохое управление блоками Все жесткие диски поступают отформатированными, причем фабричное форматиро- вание не хуже любого другого. Лучше избегать низкоуровневого форматирования, если это не диктуется крайней необходимостью. В общем, никогда не следует форматировать заново новые диски. Если на диске обнаруживаются ошибки чтения или записи, сначала необходимо про- верить кабели, терминаторы и адресацию. Каждый из них может вызвать симптомы, по- хожие на существование плохих блоков. Если после проверки вы все еще уверены, что на диске есть дефект, лучше заменить его сразу на новый диск, а не ждать много часов, пока он отформатируется, в надежде, что проблемы исчезну сами по себе. В процессе форматирования происходит запись адресов и времениых отметок на пластинах, для того чтобы установить размеры каждого сектора. Кроме того, обнаружи- ваются плохие блоки и дефекты покрытия, препятствующие надежному чтению или за- писи. Все современные блоки имеют встроенные механизмы управления плохими бло- ками, поэтому ни вам, ни драйверу не следует беспокоиться об управлении дефектами. Для этой цели встроенные программы накопителя хранят в резервной области адреса хороших блоков. Плохие блоки, проявившиеся после форматирования диска, могут обрабатываться автоматически, но могут и не обрабатываться. Если программа накопителя полагает, что эти блоки можно восстановить надежным образом, то вновь выявленный дефект может быть исправлен на лету, а данные записаны в новое место. При выявлении более се- рьезных или менее очевидных ошибок, накопитель прекращает выполнение операций чтений или записи и сообщает об ошибке операционной системе компьютера. Диски АТА обычно не предназначены для форматирования за пределами фабрики. Однако вы можете получить информацию о программном обеспечении для формати- рования дисков от его производителей, как правило, для системы Windows. Убедитесь, что программное обеспечение предназначено именно для того накопителя, который вы собираетесь форматировать, и точно следуйте инструкциям производителя.7 Диски SCSI форматируются сами по стандартной команде, поступающей от ком- пьютера. Процедура отправки этой команды зависит от системы. На персональных компьютерах часто существует возможность посылать эту команду из системы BIOS контроллера SCSI. Для того чтобы отдать команду на форматирование диска SCSI от имени операционной системы, следует выполнить команду sg_format в системе Linux, format — в системе Solaris и mediainit — в системе HP-UX. Для проверки целостности диска существуют разнообразные утилиты, которые вы- полняют запись данных в случайно выбранные области и считывают их оттуда. Тщатель- ные тесты занимают много времени и, к сожалению, имеют небольшое прогностическое значение. Если вы подозреваете, что диск испорчен, и можете его просто заменить (или заказать новый в течение часа), то эти тесты можно проигнорировать. В противном слу- чае запустите тест на ночь. Не беспокойтесь об “изнашивании” диска вследствие из- быточного или агрессивного тестирования. Промышленные диски предназначены для постоянной работы. 7 С другой стороны, если накопитель емкостью 1 Тбайт стоит 80 долл., зачем беспокоиться?
274 Часть I. Основы администрировани. Безопасное стирание дисков АТА Начиная с 2000 года диски РАТА и АТА реализуют команду “безопасного стирания”, которая переписывает все данные на диске, используя метод, разработанный произво- дителями для защиты от несанкционированного извлечения информации. Безопасное стирание сертифицировано Национальным институтом стандартов и технологии (NIST) и в большинстве случаев вполне удовлетворяет пользователей. По классификации Министерства обороны США, оно одобрено к использованию на уровне конфиденци- альности ниже, чем “секретно”. Зачем вообще нужна такая функциональная возможность? Во-первых, файловые системы сами ничего не стирают, поэтому команды вроде rm -rf * оставляют данные, находящиеся на диске, нетронутыми и допускают их восстановление с помощью специ- альных программ. При ликвидации дисков об этом очень важно помнить, чтобы конфи- денциальная информация попала в мусоросборник, а не на аукцион eBay. Во-вторых, даже неавтоматическая запись каждого сектора на диске может оставлять магнитные следы, которые злоумышленник может выявить в лаборатории. Безопасное стирание переписывает данные столько раз, сколько нужно для того, чтобы уничтожить побочные сигналы. Остаточные магнитные сигналы для большинства организаций не составляют большой проблемы, но всегда полезно знать, что вы защищены от разглаше- ния конфиденциальных данных организации. В заключение, безопасное стирание делает накопители SSD абсолютно пустыми. Это позволяет повысить их производительность в ситуациях, в которых нельзя использовать команду TRIM в стандарте АТА (команду для стирания блока) либо потому, что файло- вая система, используемая на накопителе SSD, не способна ее выполнить, либо потому, что накопитель SSD присоединен через адаптер компьютера или интерфейс RAID, ко- торые не пропускают команду TRIM. К сожалению, поддержка команды безопасного стирания диска в системе UNIX остается слабой. С этой точки зрения для очистки накопителей их лучше переключить в систему Windows или Linux. Программное обеспечение операционной системы DOS можно найти на сайте исследовательской группы Center of Magnetic Recording Research tinyurl. com/2xoqqw. Утилита MHDD также поддерживает безопасное стирание с по- мощью команды fasterase (см. сайт tinyurl. com/2g6r98). В системе Linux можно использовать команду hdparm. $ sudo hdparm —user-master u -security-set-pass password /dev/sda8 $ sudo hdparm —user-master u -security-set-erase password /dev/sda Команда безопасного стирания в стандарте АТА не имеет аналогов в стандарте SCSI, но команда “форматировать модуль” в стандарте SCSI, описанная выше, представляется вполне разумной альтернативой. Другой возможностью является обнуление секторов с помощью команды dd if=/dev/zero ъ£=накопитель bs=8k. Многие системы имеют утилиту shred, которая выполняет безопасное стирание от- дельных файлов. К сожалению, ее работа основана на предположении, что блоки фай- лов могут быть перезаписаны на том же месте. Однако во многих ситуациях это условие не выполняется (в частности, это относится к любым файловым системам на любых на- копителях SSD, любым логическим томам, имеющим механизм мгновенных копий, и, 8 Команда безопасного стирания в стандарте АТА защищена паролем, для того чтобы затруд- нить к ней доступ. Следовательно, перед ее вызовом необходимо ввести пароль. Впрочем, не стоит его записывать, вы можете установить его заново, когда захотите. В этом случае блокировка нако- пителя никакой опасности не несет.
Глава 8. Дисковая память 275 возможно, ко всей файловой системе ZFS), поэтому полезность универсальной утилиты shred вызывает сомнения. Для очистки всей дисковой системы на персональном компьютере существует про- грамма Darik’s Boot and Nuke (dban.org). Этот инструмент запускается со своего за- грузочного диска, поэтому он не используется каждый день. Тем не менее он довольно удобен для вывода из эксплуатации старого аппаратного обеспечения. Команда hdparm: параметры диска и интерфейса (Linux) ДВ системе Linux команда hdparm имеет немного больше возможностей, чем команды безопасного стирания. Обычно она используется для взаимодействия со встроенными программами жестких дисков SATA, IDE и SAS. Помимо прочего, команда hdparm может устанавливать настройки электропитания накопителя, включать или отключать подавление шумов, устанавливать флаг “только для чтения” и распечатывать информацию о накопителе. Некоторые из этих опций относятся и к накопителям SCSI (в современных ядрах систе- мы Linux). Синтаксис этой команды выглядит следующим образом. hdparm [параметры] накопитель Источники параметров доступны, но большинство из них интересно только для раз- работчиков драйверов и ядер. Параметры, представляющие интерес для администрато- ров, приведены в табл. 8.3. Таблица 8.3. Параметры команды hdparm, полезные для системных администраторов Параметр -la -M значение -S значение Выдает много идентифицирующей информации и данных о состоянии накопителя Устанавливает акустические параметры Устанавливает временную задержку для режима ожидания (замедление вращения) -у -С -т t Немедленно переводит накопитель в режим ожидания Посылает запросы о текущем состоянии системы управления электропитанием накопителя Быстро тестирует полосу пропускания интерфейса (без реального чтения диска) Быстро тестирует скорость считывания данных с пластины в компьютер Это прописная буква I, как в слове India. Для того чтобы проверить, что каждое устройство работает в максимально быстром режиме DMA, следует использовать команду hdparm -I. Команда hdparm перечисля- ет все поддерживаемые модели дисков и помечает их текущий режим звездочкой, как показано в примере, приведенном ниже. linux$ sudo hdparm -I /dev/sdf /dev/sdf ATA device, with non-removable media Model number: WDC WD1001FALS-00J7B0 Serial Number: Firmware Revision: WD-WMATV0998277 05.00K05 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
276 Часть I. Основы администрирования" Capabilities: LBA, IORDY (can be disabled) Queue depth: 32 Standby timer values: spec’d by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current =16 Recommended acoustic management value: 128, current value: 254 DMA: mdmaO mdmal mdma2 udmaO udmal udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pioO piol pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120 ns Во всех современных системах оптимальный режим DMA устанавливается по умол- чанию. Если это не так, проверьте систему BIOS и журналы ядра для поиска информа- ции, которая поможет понять причины. Многие накопители предлагают управление акустическим режимом, позволяя за- медлять движение считывающих головок и уменьшать громкость тиканья и звуковых импульсов. Накопители, поддерживающие такую возможность, обычно поставляют- ся с уже включенным механизмом управления акустическим режимом, но это иногда не важно для накопителей, установленных в серверной комнате. Для того чтобы отклю- чить эту возможность, следует выполнить команду hdparm -М 254. Большая часть электроэнергии, потребляемой накопителем, расходуется на враще- ние пластин. Если ваши диски используются редко и вы имеете возможность установить задержку на 20 с или управлять повторным запуском двигателя дисков, выполните ко- манду hdparm -S, чтобы включить возможность внутреннего управления электропита- нием дисков. Аргумент -S задает время простоя, после которого накопитель переходит в режим ожидания и отключает двигатель. Эта величина занимает один байт, поэтому кодирование представляет собой нелинейную задачу. Например, значения от 1 до 240 умножаются на 5 секунд, а значения от 241 до 251 — на 30 минут. В ходе выполнения ко- манда hdparm демонстрирует свою интерпретацию этого значения. Его проще угадать, подобрать и повторить, чем определить, точно следуя правилам кодирования. Команда hdparm предусматривает простой тест производительности накопителя, позволяющий оценить влияние изменений конфигурации. Параметр -Т означает счи- тывание данных из кеша накопителя и выдачу скорости передачи данных по шине, не зависящую от пропускной способности физических устройств накопителя. Параметр -t означает считывание с пластин. Как и следовало ожидать, считывание с пластин проис- ходит намного медленнее. $ sudo /shin/hdparm -Tt /dev/hdb /dev/sdf: Timing cached reads: 2092 MB in 2.00 seconds = 1046.41 MB/sec Timing buffered disk reads: 304 MB in 3.00 seconds = 101.30 MB/sec Скорость, равная 100 Мбайт/с, близка к максимальному пределу современных на- копителей емкостью 1 Тбайт, так что эти результаты (и информация, приведенная выше при иллюстрации команды hdparm -1) подтверждают, что накопитель настроен пра- вильно. Мониторинг жесткого диска с помощью стандарта SMART Жесткие диски представляют собой отказоустойчивые системы, использующие ко- дирование с исправлением ошибок, и встроенные программы с развитой логикой для
Глава 8. Дисковая память 277 сокрытия своих недостатков от операционной системы компьютера. В некоторых слу- чаях жесткие диски сообщают операционной системе о неисправимой ошибке только после многочисленных попыток исправить ее. Было бы хорошо заранее распознавать такие ошибки, пока не разразился кризис. Устройства АТА, включая накопители SATA, реализуют подробную форму отчетов о состоянии накопителя, которая иногда позволяет предсказать сбой. Этот стандарт под названием SMART (“self-monitoring, analysis, and reporting technology”) предусматривает более 50 параметров, которые может анализировать компьютер. Ссылаясь на исследование дисков, проведенное компанией Google (см. раздел 8.11), часто утверждают, что данные стандарта SMART не могут предсказать отказ накопителя. Это не совсем так. На самом деле компания Google обнаружила, что четыре параметра стандарта SMART обладают высокой прогнозной точностью, но сам сбой невозможно предотвратить с помощью изменения настроек стандарта SMART. Среди накопителей, давших сбой, 56% не содержали изменений в этих четырех параметрах. С другой сто- роны, мы считаем, что предсказание сбоя у более половины дисков является неплохим результатом! Четырьмя чувствительными параметрами стандарта SMART являются количество ошибок сканирования (scan error count), количество повторного распределения памяти (reallocation count), количество автономного повторного распределения памяти (off-line reallocation count) и количество секторов “с испытательным сроком” (number of sectors “of probation”). Все эти значения должны быть равны нулю. Ненулевые значения этих параметров повышают вероятность отказа в течение 60 дней в 39, 14, 21 и 16 раз соот- ветственно. Для того чтобы извлечь пользу из параметров стандарта SMART, необходимо иметь специальное программное обеспечение, которое опрашивает накопители и прогнози- рует вероятность сбоя. К сожалению, стандарты отчетов варьируются в зависимости от производителей накопителей, поэтому декодирование параметров не всегда является простой задачей. Большинство мониторов SMART накапливают основные параметры, а затем ищут внезапные изменения в неблагоприятном направлении, вместо того что- бы интерпретировать их абсолютные величины. (В соответствии с отчетом компании Google, учет этих “мягких” параметров стандарта SMART в дополнение к “большой чет- верке” позволяет предсказать 64% сбоев.) Стандартным программным обеспечением стандарта SMART для контроля нако- пителей в системах UNIX и Linux является пакет smartmontool с сайта smartmontool. sourceforge. net. В системах SUSE и Red Hat он инсталлируется по умолчанию; в си- стеме Ubuntu для его инсталляции необходимо выполнить команду apt-get install smartmontools. Для того чтобы запустить этот пакет в системе Solaris, его необходимо скомпилировать из исходного кода. Пакет smartmontool состоит из демона smartd, который постоянно следит за на- копителями, и команды smartctl, которую можно использовать для выполнения ин- терактивных запросов или сценариев. Демон имеет один конфигурационный файл, как правило, /etc/smartd.conf, содержащий подробные комментарии и много примеров. Накопители SCSI имеют собственную систему отчетов о нестандартном состоя- нии, но, к сожалению, они менее подробные, чем отчеты системы SMART. Пакет smartmontools пытается включить накопители SCSI в свою схему, но прогнозируемая значимость данных стандарта SCSI является мнее ясной.
278 Часть I. Основы администрирования 8.6. Разбиение диска Разбиение логического тома и управление им — это два способа разделения диска (или совокупности дисков в случае менеджера LVM) на отдельные части определенного объема. Все рассматриваемые нами операционные системы поддерживают управление логическими томами, но только Linux, Solaris и иногда HP-UX допускают традиционное разбиение. Каждый раздел можно отдать под контроль менеджера логических томов, но сам логический том разделить нельзя. Разбиение — это самый низкий уровень управление дисками. В системе Solaris разбиение необходимо, но по существу носит рудиментар- soiaris ный характер; система ZFS скрывает его так хорошо, что пользователь может об этом даже не догадываться. В этом разделе приведена общая информа- ция, которая может оказаться полезной для администратора системы Solaris, но поскольку с процедурной точки зрения система Solaris резко отличается от систем Linux, HP-UX и AIX, читатель может сразу перейти к разделу 8.10. (Впрочем, читая этот раздел дальше, вы узнаете, что команда zpool create новый_пул новый_накопитель решает большую часть проблем, связанных с конфигурацией.) И разбиение диска, и логические тома облегчают резервное копирование, предот- вращая незаконный захват пользователями дискового пространства и потенциальные повреждения от программ, вышедших из-под контроля. Все системы имеют корневой “раздел”, содержащий большинство данных о конфигурации локального компьютера. Теоретически, для того чтобы перевести систему в однопользовательский режим работы, достаточно одного корневого раздела. Различные подкаталоги (самые распространенные из них — /var, /usr, /Ьпр, /share и /home) можно разделять на более подробные раз- делы или тома. Большинство систем имеет, по крайней мере, одну область подкачки. Мнения о наилучшем способе разбиения диска по умолчанию разделяются. Рас- смотрим некоторые из них. • Целесообразно иметь резервный корневой накопитель, который можно загрузить в ситуации, когда с обычным корневым разделом что-то не так. В идеале резервный корневой раздел и обычный корневой раздел (root device) должны существовать на разных дисках, чтобы иметь возможность защищаться от проблем, связанных с ап- паратным обеспечением и повреждениями. Однако даже если резервный корневой раздел находится на том же диске, все равно он имеет определенную ценность.9 • Проверьте, можете ли вы загружаться с резервного корневого раздела. Эта проце- дура зачастую нетривиальна. Возможно, во время загрузки вам понадобится пере- дать специальные аргументы для ядра или внести минимальные изменения в кон- фигурацию альтернативного корневого раздела, чтобы все работало гладко. Поскольку корневой раздел часто дублируется, он должен быть достаточно неболь- шим, чтобы две его копии не потребляли неразумно большой объем дискового про- странства. Это основная причина, по которой каталог /usr часто представляет собой отдельный том; он содержит большинство системных библиотек и данных. 9 Системы Solaris и HP-UX имеют даже файловые системы “динамического корневого диска”, облегчающие эксплуатацию нескольких корней. См. справочные страницы, посвященные коман- дам beadm или lucreate в системе Solaris и drd в системе HP-UX.
Глава 8. Дисковая память 279 Размещение каталога / tmp в отдельной файловой системе ограничивает размеры временных файлов и позволяет их не восстанавливать. Некоторые системы для повы- шения производительности используют для хранения каталога /tmp файловую систему, расположенную в оперативной памяти. Файловые системы, расположенные в оператив- ной памяти, поддерживаются областью подкачки, поэтому они хорошо работают в боль- шинстве ситуаций. Поскольку файлы системного журнала хранятся в каталоге /var, целесообразно, чтобы каталог /var представлял собой отдельный раздел диска. Если каталог /var хра- нится в маленьком корневом разделе, то легко переполнить этот раздел и вызвать оста- новку машины. Пользовательские рабочие каталоги полезно размещать в отдельном разделе или ка- талоге. В этом случае, даже если корневой раздел будет поврежден или разрушен, поль- зовательские данные с высокой вероятностью останутся целыми. И наоборот, система сможет продолжать работу, даже если ошибочный пользовательский сценарий перепол- нит каталог /home. Разделение области подкачки между несколькими физическими дисками повышает производительность работы. Этот метод работает и по отношению к файловым систе- мам; размещайте интенсивно используемые файловые системы на разных дисках. Эта тема освещается в разделе 29.4. Добавляя модули памяти в компьютер, увеличьте область подкачки. Более подробно виртуальная память описывается в разделе 29.4. Резервное копирование раздела можно упростить, если весь раздел заполняет один фрагмент памяти надиске (см. раздел 10.1). Старайтесь разделять быстро изменяющуюся информацию на кластеры, размещен- ные в нескольких разделах, которые часто подвергаются резервному копированию. Традиционное разбиение Системы, допускающие разбиение, реализуют его, записывая “метку” в начало дис- ка, чтобы определить диапазон блоков, включенных в каждый раздел. Подробности этой процедуры могут варьироваться; метка часто может существовать одновременно с другой установочной информацией (например, загрузочным блоком) и часто содержит дополнительную информацию, например имя или уникальный идентификатор всего диска. В системе Windows эта метка называется MBR (master boot record — главная за- грузочная запись). Драйвер устройства, представляющий диск, считывает эту метку и использует таблицу разбиения диска для вычисления физического местоположения каждого раздела. Как пра- вило, каждому разделу соответствует один или два файла устройства (для блочного устрой- ства и для устройства посимвольного ввода-вывода; в системе Linux есть только блочные Устройства). Кроме того, отдельный набор файлов устройств представляет диск в целом. В системе Solaris разделы называются секторами (“slices”). Точнее, они на- soians зываются секторами, если реализованы с помощью метки в стиле системы Solaris, и разделами, если реализованы с помощью метки MBR в стиле си- стемы Windows. Сектор 2 содержит все пространство диска, иллюстрируя не- сколько устрашающий факт, что один блок диска может принадлежать не- скольким секторам одновременно. Возможно, слово “сектор” было выбрано потому, что “раздел” предполагает простое разбиение, а секторы могут пере- крываться. В остальных ситуациях эти термины являются синонимами.
280 Часть I. Основы администрирования Несмотря на всеобщую доступность менеджером логических томов, в некоторых си- туациях необходимо или желательно традиционное разбиение. • На персональных компьютерах загрузочный диск может иметь таблицу разбиения. Большинство систем предпочитает разбиение с помощью метки MBR (см. далее раздел “Разбиение диска в стиле системы Windows”), но системы на процессоре Itanium требуют разбиения с помощью таблицы GPT (см. ниже). Диски с данны- ми могут оставаться неразделенными. CQ Более подробно двойственная загрузка системы Windows описывается в разделе 3.3. • Инсталлирование меток MBR делает диск понятным для системы Windows, даже если содержание его отдельных разделов остается недоступным. Если вы хотите взаимодействовать с системой Windows (например, посредством двойственной за- грузки), необходимо инсталлировать метки Windows MBR. Однако даже если вы не собираетесь делать что-нибудь подобное, иногда целесообразно учесть повсе- местную распространенность системы Windows и вероятность того, что ваш диск в один прекрасный день может вступить с ней в контакт. • Текущие версии системы Windows являются хорошо продуманными и никогда не записывают данные на диск, который они не могут расшифровать. Однако они определенно могут предложить эти действия администратору, который на них за- регистрируется. На соответствующем диалоговом окне даже есть полезная кнопка “ОК, преврати этот диск в кашу!”.10 Ничего плохого не произойдет, пока кто-то не сделает ошибку, но обеспечение безопасности — это структурный и организаци- онный процесс. • Разделы занимают точно определенное место на диске и гарантируют локальность ссылок. Логические тома этого не обеспечивают (по крайней мере, по умолча- нию). В большинстве случаев это не имеет большого значения. Однако поиск в смежных областях выполняется быстрее, нежели поиск в отдаленных ячейках, и пропускная способность внешних цилиндров диска (т.е. цилиндров, содержащих блоки с наименьшими номерами) может превосходить пропускную способность внутренних цилиндров на 30% и более.11 Для ситуаций, в которых требуется вы- сокая производительность, разбиение диска можно использовать для достижения дополнительного выигрыша. (Для восстановления потерянной гибкости всегда можно применить управление логическими томами внутри раздела.) • Системы RAID (см. раздел 8.7) используют диски или разделы одинакового объ- ема. Хотя конкретная реализация системы RAID может допускать диски разных объемов, вероятно, она будет использовать только те диапазоны блоков, которые являются общими для всех дисков. Вместо того чтобы терять избыточное про- странство, его можно изолировать в отдельном разделе. Однако в этом случае сле- дует предусмотреть запасной раздел для редко используемых данных, иначе такое разбиение снизит производительность работы массива RAID. 10 Хорошо, хорошо. Возможно, на ней написано просто “Форматировать” или “ОК”, но это именно то, что на ней должно быть написано. 11 Использование только внешних цилиндров диска для повышения производительности на- зывается “коротким рабочим ходом” (short stroking). Здесь ходом называется перемещение головки диска.
Глава 8. Дисковая память 281 Разбиение диска в стиле системы Windows Метка Windows MBR занимает один блок диска размером 512 байт; большую часть этого блока занимает код загрузки. Оставшегося места достаточно для определения только четырех разделов. Эти разделы называются первичными, потому что они опреде- ляются непосредственно в метке MBR. Один из первичных разделов можно определить как “расширенный”. Это значит, что он содержит собственную вспомогательную таблицу разделов. Расширенный раз- дел _ это обычный раздел, который занимает определенное место на физическом диске. Вспомогательная таблица разделов хранится в начале данных, относящихся к разделу. Разделы, создаваемые внутри расширенного раздела, называются вторичными. Они являются частью расширенного раздела. Запомните следующие эмпирические правила установки дисков, разбитых в стиле системы Windows. Первое из них является настоящим правилом. Остальные относятся к работе с системами BIOS, загрузочными блоками или операционными системами. • На диске может существовать только один расширенный раздел. • Расширенный раздел должен быть последним разделом, определенным в метке MBR; после него нельзя определять никаких первичных разделов. • В некоторых старых операционных системах вторичные разделы нежелательны. Для того чтобы избежать неприятностей, инсталлируйте операционную систему в первичном разделе. Схема разбиения дисков в системе Windows позволяет пометить один из разделов как “активный”. Загрузчики ищут активный раздел и пытаются загрузить операционную си- стему из него. Кроме того, каждый раздел имеет однобайтовый атрибут типа, который обозна- чает содержимое раздела. Как правило, эти коды представляют либо типы файловой системы, либо операционные системы. Эти коды не присваиваются централизован- но, но со временем были приняты определенные соглашения. Они сформулированы Андрисом Э. Брауэром (Andries Е. Brouwer) на сайте tinyurl. com/part-types. Команда MS-DOS, осуществляющая разбиение жесткого диска, называется fdisk. Большинство операционных систем, поддерживающих разбиение в стиле системы Windows, унаследовали это имя для обозначения своих собственных команд разбиения, но они очень разнообразны. Сама система Windows от нее отказалась: ее современная версия инструмента для разбиения диска называется diskpart. Кроме того, система Windows имеет графический пользовательский интерфейс для разбиения дисков, кото- рый доступен благодаря утилите Disk Management из консоли управления штс. Не имеет значения, с помощью какой операционной системы вы разбили диск на разделы — Windows или какой-то другой. Окончательный результат будет таким же. GPT: таблица разделов CUID Проект компании Intel по созданию расширяемого микропрограммного интерфейса (extensible firmware interface — EFI) был направлен на замену неустойчивых соглашений, касающихся систем BIOS персональных компьютеров, более современной и функцио- нальной архитектурой.12 Несмотря на то что системы, полноценно использующие рас- Проект EFI недавно был переименован в UEFI. Буква U означает “unified” (универсальный), от проект поддерживается многими производителями. Однако название EFI употребляется ац1е. По существу, названия UEFI и EFI являются синонимами.
282 Часть I. Основы администрирования ширяемый микропрограммный интерфейс, в настоящее время являются редкостью, схема разбиения EFI получила широкое распространение среди операционных систем. Основная причина этого заключается в том, что метка MBR не поддерживает диски, объем которых больше 2 Тбайт. Поскольку диски объемом 2Тбайт стали широко доступ- ными, эту проблему нужно срочно решать. Схема разделения EFI, известная как “таблица разделов GUID”, или GPT, устраняет очевидные недостатки метки MBR. Она определяет только один тип разбиения, а самих разделов может быть сколько угодно. Каждый раздел имеет тип, определенный 16-бай- товым идентификатором (глобально уникальным ID, или GUID), который не требует централизованного управления. Следует подчеркнуть, что таблица GPT сохраняет простейшую совместимость с си- стемами, использующими метку MBR, записывая метку MBR в первый блок таблицы разделов. Эта “ложная” метка MBR позволяет диску выглядеть так, будто он содержит только один раздел MBD (по крайней мере, в пределах до 2 Тбайт). Само по себе это не имеет значения, но присутствие “ложной” метки MBR защищает диск от переформати- рования простыми системами. Версии системы Windows, начиная с версии Vista, открыли эру дисков GPT для хра- нения данных, но только системы, поддерживающие расширяемый микропрограммный интерфейс, могут загружаться с этих дисков. Система Linux и ее загрузчик GRUB про- двинулись дальше: они поддерживают диски GPT, с которых могут загружаться любые системы. Системы Mac OS, основанные на процессорах компании Intel, поддерживают обе схемы разбиения EFI и GPT. Система Solaris понимает схему разбиения GPT, а си- стема ZFS использует ее по умолчанию. Однако загрузочные диски системы Solaris не могут использовать разбиение GPT. Несмотря на то что разбиение GPT хорошо принято ядрами операционных систем, ее поддержка среди утилит управления дисками остается эпизодической. Разбиение GPT остается форматом “далекого будущего”. В настоящее время нет разумных причин для его использования на дисках, которые этого не требуют (т.е. на дисках объемом до 2 Тбайт). Разбиение дисков в системе Linux Д Системы семейства Linux предусматривают несколько вариантов разбиения дисков. В них основным средством для разбиения дисков является команда fdisk. Инструмент для разбиения дисков в системе GNU запускается из ко- мандной строки, понимает несколько форматов меток (включая метки систе- мы Solaris), может перемещать разделы и изменять их размеры, а также просто создавать и удалять их. Его версия с графическим пользовательским интер- фейсом под названием gparted запускается в среде GNOME. Другой возмож- ностью является утилита cfdisk, представляющая собой прекрасную альтер- нативу команде fdisk, использующую терминалы. Утилиты parted и gparted теоретически могут изменять размеры некоторых типов файловых систем вместе с разделами, которые они содержат, но на домашней странице соответствующего проекта эта функциональная возможность названа “дефектной и не- надежной”. Утилиты, предназначенные для файловых систем, лучше выполняют их на- стройку, но, к сожалению, утилита parted не имеет команды “изменить размер раздела, но не файловой системы”. Если это необходимо, следует использовать утилиту fdisk.
Глава 8. Дисковая память 283 В целом, мы рекомендуем использовать утилиту gparted, а не parted. Обе утилиты просты, но gparted позволяет задавать размеры разделов, а не начало и конец диапа- зона блоков. Для разбиения загрузочного диска лучше всего использовать графические инсталляторы из дистрибутивных пакетов, так как они обычно предлагают разбиение, которое является оптимальным для данного дистрибутива. Разбиение дисков в системе Solaris Файловая система ZFS автоматически помечает диски, применяя таблицу SOiariS разделов GPT. Однако разбить диски на разделы можно и вручную, исполь- зуя команду format. В операционных системах х86 можно также применять команду fdisk. Оба инструмента предусматривают работу с меню и являются относительно простыми. Команда format предоставляет пользователю удобный список дисков, в то время как команда fdisk требует указать диск в командной строке. К счастью, утилита format имеет команду fdisk, запускающую ее как подпроцесс, поэтому утилиту format можно рассматривать как оболочку, позволяющую найти требуемый диск. Система Solaris допускает три схемы разбиения дисков: Windows MBR, GPT и старые таблицы разбиения Solaris, известные как SMI. Для загрузочных дисков следует исполь- зовать схемы MBR или SMI, в зависимости от аппаратного обеспечения и версии систе- мы, Solaris или OpenSolaris. Пока, вероятно, лучше придерживаться этих правил для всех дисков объемом до 2 Тбайт, разбиваемых на разделы вручную. Разбиение дисков в системе HP-UX Операционная система HP применяет разбиение только для загрузочных дис- ков компьютеров на процессорах Itanium (Integrity), требующих использова- ния таблицы GPT и разбиения загрузочного диска с помощью интерфейса EFI. Команда idisk распечатывает и создает таблицы разделов. Она не ра- ботает в интерактивном режиме, а просто считывает план разбиения из файла или со стандартного средства ввода и использует его для создания таблицы разделов. Спецификации команды idisk очень просты. Первая строка содержит только коли- чество создаваемых разделов. Каждая следующая строка содержит тип разбиения (EFI, HPUX, HPDUMP или HPSP для подкачки), символ пробела и спецификацию объема, например 128 Мбайт или 100%. Если используются проценты, то они интерпретируются по отношению к пространству на накопителе, оставшемуся после выделения памяти Для предыдущих разделов. 8.7. RAID: избыточные массивы недорогих дисков Даже при резервном копировании последствия сбоя диска на сервере могут быть раз- рушительными. RAID (redundant arrays of inexpensive disks — избыточные массивы не- дорогих дисков) — это система, распределяющая или дублирующая данные с помощью многочисленных дисков.13 Система RAID не только помогает избежать потери данных, бь Аббревиатуру RAID иногда расшифровывают как “redundant arrays of independent disks” (“из- гг°чнЬ1е массивы независимых дисков”). Оба варианта с исторической точки зрения являются правильными.
284 Часть I. Основы администрирования но и минимизирует время простоя, связанного с отказом аппаратуры (часто сводя его к нулю), и потенциально повышает производительность. Систему RAID можно реализовать с помощью специального оборудования, благо- даря которому операционная система интерпретирует группу жестких дисков как один составной накопитель. Кроме того, ее можно реализовать так, чтобы операционная си- стема просто считывала или записывала данные на жестких дисках по правилам систе- мы RAID. Программная и аппаратная реализации системы RAID Поскольку диски сами по себе являются узким местом в реализации системы RAID, нет причин предполагать, что аппаратная реализация системы RAID всегда будет рабо- тать быстрее, чем оперативная. В прошлом аппаратная система RAID была доминирующей по двум причинам: из-за недостатка программной поддержки (отсутствие прямой поддержки со стороны опера-;; ционных систем) и способности аппаратного обеспечения буферизовать записи в форме некой энергонезависимой памяти. Последнее свойство, упомянутое выше, повышает производительность, поскольку^ записи заполняются мгновенно. Кроме того, оно защищает диск от потенциального/ повреждения, которое получило название “RAID 5 write hole”. Этот эффект описыва-' ется ниже. Однако будьте осторожны: многие широко распространенные “микросхем^ RAID” для персональных компьютеров вообще не имеют энергонезависимой памяти; на* самом деле они представляют собой хорошо известный интерфейс SATA с элементами' встроенного программного обеспечения RAID. Реализации системы RAID на материи^ ских платах персональных компьютеров также относятся к этой категории. В таких слу- чаях лучше вообще отказаться от возможностей RAID в системах Linux или OpenSolarfe. Недавно произошел сбой контроллера диска на важном промышленном сервере. Несмотря на то что данные были скопированы на нескольких физических накопителях, неисправный контроллер RAID разрушил данные на всех дисках. В результате пришлось более двух месяцев долго и нудно восстанавливать магнитную ленту, пока сервер не был восстановлен полностью. Для управления средой RAID восстановленный сервер теперь использует программное обеспечение ядра, тем самым исключая возможность нового сбоя контроллера RAID. Уровни системы RAID Система RAID может выполнять две основные операции. Во-первых, она может по- высить производительность, “разбросав” данные по многим накопителям и позволив нескольким дискам одновременно передавать или получать поток данных. Во-вторых, она может реплицировать данные по многим накопителям, уменьшая риск, связанный со сбоем одного диска. Репликация может осуществляться в двух видах: зеркальное отражение (mirroring), при котором блоки данных побитово репродуцируются на нескольких накопителях, и схемы четности (parity schemes), в которых один или несколько накопителей содержат контрольную сумму для проверки ошибок на остальных накопителях. Зеркальное отра- жение быстрее, но занимает много места на диске. Схемы четности более экономно ис- пользуют дисковую память, но работают медленнее. Система RAID традиционно описывается в терминах “уровней”, определяющих кон- кретные детали параллелизма и избыточности. Возможно, этот термин является неудач-
Глава 8. Дисковая память 285 ным, потому что более высокий уровень не обязательно оказывается лучшим. Уровни — это просто разные конфигурации; вы можете использовать любой из них. На рисунках, приведенных ниже, числа обозначают магнитные ленты, а буквы а, b и с — блоки данных на этих лентах. Блоки, помеченные буквами р и q, являются блоками четности. • “Линейный режим”, известный также как JBOD (just a bunch of disks — просто группа дисков), нельзя даже назвать реальным уровнем системы RAID. Его реа- лизует каждый контроллер RAID. В режиме JBOD адресные блоки нескольких на- копителей конкатенируются, образуя один большой виртуальный накопитель. Это не обеспечивает ни избыточности данных, ни повышения производительности. В настоящее время функциональная возможность JBOD лучше обеспечивается с помощью менеджера логических томов, а не контроллера RAID. • Уровень RAID 0 используется только для повышения производительности. Он объединяет два или более накопителей одинаковых размеров, но, вместо их объ- единения последовательно один за другим, он распределяет данные между диска- ми, входящими в пул. Операции последовательного чтения и записи в этом случае оказываются распределенными между несколькими дисками, что снижает время записи и доступа к диску. RAID О Обратите внимание на то, что надежность уровня 0 ниже, чем надежность отдель- ных дисков. Вероятность отказа массива из двух дисков в течение года примерно в два раза выше, чем у отдельного диска, и т.д. • Уровень RAID 1 известен как “зеркальное отражение”. Записи дублируются од- новременно на нескольких дисках. Эта схема замедляет процесс записи по срав- нению с записью данных на отдельный диск. Однако она обеспечивает скорость считывания, сравнимую с уровнем RAID 0, потому что чтение можно распреде- лять между несколькими дублирующими накопителями. RAID1 • Уровни RAID 1+0 и 0+1 представляют собой группы зеркал или зеркала групп. С логической точки зрения они представляют собой сочетание уровней RAID 0 и RAID 1, но многие контроллеры и программы обеспечивают их непосредственную поддержку. Цель обоих режимов ~ одновременно достичь производительности Уровня RAID 0 и избыточности уровня RAID 1.
286 Часть I. Основы администрирования RAID 1+0: Группа зеркал • Уровень RAID 5 распределяет и данные, и информацию о четности, добавляя из- быточность и одновременно повышая производительность чтения. Кроме того, уровень RAID 5 более эффективно использует дисковое пространство, чем уро- вень RAID 1. Если массив состоит из N накопителей (требуется не менее трех), то N-1 из них могут хранить данные. Следовательно, эффективность использования дисковой памяти на уровне RAID 5 превышает 67%, в то время как зеркальное от- ражение не может превысить 50%. RAID 5 • Уровень RAID 6 аналогичен уровню RAID 5 с двумя дисками четности. Массив RAID 6 может сохранить работоспособность при полном отказе двух накопителей без потери данных. Уровни RAID 2, 3 и 4 хотя и определены, но используются редко. Менеджеры логи- ческих томов обычно могут и распределять данные (RAID 0), и осуществлять зеркальное отражение (RAID 1).
Глава 8. Дисковая память 287 Для обычных конфигураций распределения и зеркального отражения система Linux предоставляет выбор: использовать специальную систему RAID (напри- мер, команду md; см. ниже) или менеджер логического диска. Подход LVM, вероятно, является более гибким, хотя команда md может оказаться немного более предсказуемой. Если у вас есть возможность использовать команду md, вы можете продолжать использовать механизм LVM для управления простран- ством на томе RAID. Для уровней RAID 5 и RAID 6 вы должны использовать команду md. файловая система ZFS в операционной системе Solaris осуществляет и рас- soians пределение данных, и зеркальное отражение, и конфигурации, аналогичные уровням RAID 5 и RAID 6, как будто система RAID, менеджер логического тома и файловая система объединились в одно целое. Архитектура ZFS поме- щает зеркальное отражение и организацию проверки четности на самый низ- кий уровень, в то же время автоматически выполняя распределение данных среди накопителей, входящих в пул (уровень этой конфигурации на единицу выше). Это прекрасный способ реализации таких возможностей, поскольку он сохраняет ясность конфигурации RAID. Более подробно система ZFS опи- сывается в разделе 8.10. Управление логическим томом расширяет поддержку конфигурации RAID со сторо- ны операционных систем HP-UX и AIX. (Компания HP даже предлагает приобретать средства для зеркального отражения отдельно, хотя в некоторых промышленных кон- фигурациях она включена изначально.) Если вы хотите иметь систему, основанную на проверке четности, вам понадобится дополнительное аппаратное обеспечение. В то же время система AIX поставляется с интегрированными инструментами для управления аппаратным обеспечением RAID; см раздел Disk Array under Devices справочной систе- мы SMIT. Восстановление диска после сбоя Исследование причин отказов дисков, проведенное компанией Google, свидетель- ствует о том, что в большинстве промышленных компаний необходимо обеспечивать избыточность хранения информации на диске. При ежегодном уровне отказов, равном 8%, вашей организации потребуется около 150 жестких дисков только для того, чтобы снизить этот показатель до одного сбоя в месяц. Режимы IBOD и RAID 0 ничем не могут помочь, когда возникает проблема с про- граммным обеспечением, — необходимо выполнять резервное копирование. Другие конфигурации RAID при сбое отмечают вышедшие из строя диски как неисправные. С точки зрения клиентов массивы RAID продолжают нормально функционировать, хотя и на более низком уровне производительности. Неисправные диски необходимо как можно быстрее заменить новыми, чтобы вос- становить избыточность массива. Массив RAID 5 или двухдисковый массив RAID 1 мо- жет только смягчить последствия отказа отдельного накопителя. Как только один сбой произошел, массив подвергается опасности второго сбоя. Процедура замены диска очень простая. Следует заменить неисправный диск дру- гим диском, имеющим такой же или больший объем памяти, а затем сообщить системе RAID о том, что старый диск был заменен новым. После этого последует продолжитель- ный период, в течение которого информация о четности будет переписана на новый, чистый, диск. Часто эту операцию выполняют в ночное время. В течение этого периода
288 Часть I. Основы администрирования массив остается доступным для клиентов, но производительность, скорее всего, будет очень низкой. Для того чтобы ограничить время простоя и уменьшить уязвимость массива при вто- ром сбое, большинство систем RAID позволяет назначать один или несколько дисков на роль “горячего резерва”. Когда возникает сбой, неисправный диск автоматически за- меняется резервным и немедленно начинается процесс повторной синхронизации мас- сива. Если в массиве предусмотрены диски “горячего резерва”, то их, разумеется, также следует использовать. Недостатки конфигурации RAID 5 RAID 5 — популярная конфигурация, но у нее есть ряд недостатков. Все, что будет сказано ниже, относится и к конфигурации RAID 6, но для простоты мы ограничим об- суждение системой RAID 5. Ш Общие рекомендации по резервированию системы см. в главе 10. Во-первых, что следует особо подчеркнуть, конфигурация RAID 5 не отменяет регу- лярное автономное резервирование. Она защищает систему лишь от сбоя диска, и все. Она не защищает систему ни от случайного удаления файлов, ни от сбоев контроллера, ложного срабатывания, хакеров и других опасностей. Во-вторых, конфигурация RAID 5 не отличается высокой производительностью. Она записывает блоки данных на N-1 диск, а блоки четности — на N-й диск.14 После записи случайного блока должны быть обновлены, по крайней мере, один блок данных и один блок четности данных для указанной последовательности дисков. Более того, система RAID не знает, что именно должен содержать новый блок четности, пока не прочитает старый блок четности и старые данные. Следовательно, каждая запись в случайно вы- бранное место состоит из четырех операций: двух операций считывания и двух опера- ций записи. (Если реализация обладает развитой логикой, то последовательные записи могут оказаться намного эффективнее.) И наконец, конфигурация RAID 5 уязвима к повреждениям при определенных об- стоятельствах. Ее последовательное обновление данных о четности является более эф- фективным, чем чтение всей последовательности дисков и повторное вычисление ее четности на основе исходных данных. С другой стороны, это значит, что данные о чет- ности больше нигде не вычисляются и не хранятся. Если будет нарушена синхрониза- ция какого-нибудь блока в последовательности дисков с блоком четности, этот факт в нормальном режиме никак не проявится; операции считывания блоков данных по- прежнему будут возвращать правильные данные. Эта проблема выяснится только при сбое диска. Блок четности, вероятно, будет перезаписан много раз, пока не проявится исходная десинхронизация. Следовательно, реконструированный блок данных на запасном диске будет состоять, по существу, из случайных данных. Эта разновидность десинхронизации между блоками данных и четности не един- ственная проблема. Дисковые накопители не являются трансакционными устройства- ми. Без дополнительного уровня защиты сложно гарантировать, что на разных дисках будут правильно обновлены либо два блока, либо ни одного. Для искажения синхронно- 14 Данные о четности распределяются между всеми накопителями массива; каждая полоса име- ет свою информацию о четности, которая хранится на отдельном диске. Поскольку в массиве нет специального диска для хранения информации о четности, маловероятно, что любой отдельный диск может затормозить работу системы.
Глава 8. Дисковая память 289 сти между блоком данных и блоком четности достаточно, чтобы произошел сбой, отказ электропитания или разрыв связи в неподходящий момент. Эта проблема известна под названием “дыра записи” RAID 5 (RAID 5 “write hole”). Она является объектом пристального изучения в течение последних пяти лет. Одним из полезных ресурсов, посвященных борьбе с RAID 5 (Battle Against Any Raid Five — BAARF), является сайт baarf. org, содержащий ссылки на статьи, посвященные этому вопросу. Вы сами должны решить, действительно ли это важная проблема или искус- ственно раздута. (Мы склоняемся к тому, что она является важной.) Авторы файловой системы ZFS в операционной системе Solaris утверждают, <тго, бла- годаря переменной длине последовательности дисков в системе ZFS, она защйщена от проблемы “дыры записи RAID 5”. Кстати, это одна из причин, по которой авторы на- звали свою реализацию системы RAID в ZFS именем RAID-Z, а не RAID 5, хотя на практике эти концепции похожи. Еще одним потенциальным решением является “чистка” (“scrubbing”), которая со- стоит из поочередной проверки блоков четности во время простоя массива. Многие реа- лизации системы RAID имеют ту или иную функцию очистки. Команда mdadm: программное обеспечение RAID в системе Linux Стандартная реализация программного обеспечения RAID для системы Linux назы- вается md, драйвер “нескольких дисков” (“multiple disks” driver). Его внешний интер- фейс обеспечивает команда mdadm. Драйвер md поддерживает все конфигурации RAID, перечисленные выше, а также RAID 4. Более ранняя система под названием raidtools больше не используется. Следующий сценарий выполняет конфигурацию массива RAID 5, состоящего из трех идентичных жестких дисков объемом 500 Гбайт. Несмотря на то что драйвер md может использовать в качестве компонентов необработанные диски, мы предпочитаем снаб- дить каждый диск таблицей разделов, поэтому начинаем с запуска утилиты gparted, создающей таблицу разделов MBR на каждом диске (утилита gparted предпочтает соз- давать таблицы разделов в стиле “msdos”), и выделения всего дискового пространства одному разделу типа “неформатированный” (к сожалению, именно так это бывает в дей- ствительности). Совершенно не обязательно задавать тип раздела, но это будет полезной информацией для тех, кто станет просматривать таблицу разделов позднее. Кроме того, существует битовый флаг “raid”, который можно установить на разделе, хотя с помощью утилиты gparted сделать это довольно сложно: вы должны создать раздел, выполнить не- законченные операции, а затем вернуться в новый раздел и отредактировать его флаги. Следующая команда создает массив RAID 5 из наших трех разделов SCSI. linux$ sudo mdadm —create /dev/mdO —level=5 —raid-devices=3 /dev/sdbl /dev/sdcl /dev/sddl mdadm: array /dev/mdO started. Виртуальный файл /ргос/mdstat всегда содержит краткое описание состояния драйвера md, а также состояния всех массивов RAID, существующих в системе. Он осо- бенно полезен для анализа файла /ргос/mdstat после добавления нового диска или замены неисправного. (Рекомендуем запомнить команду cat /ргос/mdstat.) linux$ cat /ргос/mdstat Personalities : [linear] [multipath] [raidO] [raidl] [raid6] [raid5] [raid4] IraidlO]
290 Часть I. Основы администрирования mdO : active raid5 sddl[3] sdcl[l] sdbl[O] 1023404544 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_] ...........................] recovery = 0.1% (672640/511702272) finish=75.9min speed=112106K/sec unused devices: <none> Драйвер md не следит за тем, какой блок в массиве был использован, поэтому он должен вручную синхронизировать все блоки четности с их соответствующими блоками данных. Драйвер md вызывает операцию “recovery”, потому что, по существу, она совпа- дает с процедурой, использованной для замены неисправного диска. Для больших мас- сивов она может выполняться несколько часов. В файле /var/log/messages также записаны полезные сообщения. mdO:RAID5 conf printout: --- rd:3 wd:2 disk 0, o:l, dev:sdbl disk 1, o:l, dev:sdcl disk 2, o:l, dev:sddl md: recovery of RAID array mdO md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using max available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. md: using 128k window, over a total of 511702272 blocks. Команда первоначального создания также предназначена для “активирования” мас- сива (т.е. для приведения его в состояние, пригодное для использования), но при после- дующих загрузках может понадобиться активировать массив отдельно, как правило, за рамками сценария загрузки. Системы Red Hat и SUSE имеют простые сценарии загруз- ки для массивов RAID, а система Ubuntu активирует эти массивы по умолчанию. Формально, команда mdadm не требует наличия файла конфигурации, но если он есть, она его использует (как правило, это файл /etc/mdadm.conf). Мы настоятельно реко- мендуем использовать файл конфигурации. Он документирует конфигурацию системы RAID стандартным образом, позволяя администратору просмотреть информацию при возникновении проблемы. В качестве альтернативы использованию файла конфигура- ции можно задавать конфигурацию в командной строке при каждой активации массива. Команда mdadm —detail —scan записывает текущие настройки системы RAID в файл конфигурации. К сожалению, конфигурация, которую она записывает в файл, является неполной. Для получения полной конфигурации необходимо выполнить сле- дующие команды. linux$ sudo sh -с 'echo DEVICE /dev/sdbl /dev/sdcl /dev/sddl > /etc/mdadm.conf' linux$ sudo sh -c 'mdadm —detail —scan » /etc/mdadm.conf' linux$ cat /etc/mdadm.conf DEVICE /dev/sdbl /dev/sdcl /dev/sddl ARRAY /dev/mdO level=raid5 num-devices=3 metadata=00.90 spares=l UUID=f18070c5:e2b6aal8:e368bf24:bd0fce41 Теперь команда mdadm может читать этот файл при загрузке или закрытии, чтобы легко управлять массивом. Для того чтобы активировать массив с помощью вновь соз- данного файла /etc/mdadm.conf, можно выполнить следующую команду. $ sudo mdadm -As /dev/mdO Для того чтобы остановить массив вручную, можно выполнить такую команду. $ sudo mdadm -S /dev/mdO
Глава 8. Дисковая память 291 Создав файл mdadm.conf, распечатайте его и передайте на сервер. Если что-то прои- зойдет, восстановить компоненты массива RAID бывает сложно. Команда mdadm имеет режим -monitor, в котором она выполняется постоянно как демон и сообщает по электронной почте о проблемах, возникших в массиве RAID. Используйте эту возможность! Для того чтобы ее настроить, добавьте строку MAILADDR в свой файл mdadm. conf, чтобы указать адресата, которому следует отправлять предупре- ждения, и настройте демон монитора так, чтобы он запускался во время загрузки. Рас- смотренные нами дистрибутивные пакеты операционных систем содержали первичный сценарий, реализующий эту задачу, но имена и процедуры могут немного отличаться. ubuntu$ sudo update-rc.d mdadm enable suse$ sudo chkconfig -s mdadmd on redhat$ sudo chkconfig mdmonitor on Что произойдет, если диск действительно выйдет из строя? Попробуем разобрать- ся! Команда mdadm предоставляет нам прекрасную возможность сымитировать сбой- ный диск. $ sudo mdadm /dev/mdO -f /dev/sdcl mdadm: set /dev/sdcl faulty in /dev/mdO $ sudo tail /var/log/messages May 30 16:14:55 harp kernel: raid5: Disk failure on sdc, disabling device. Operation continuing on 2 devices kernel: RAID5 conf printout: kernel: -- rd:3 wd:2 fd:l kernel: disk 0, o:l, dev:sdbl kernel: disk 1, o:0, dev:sdcl kernel: disk 2, o:l, dev:sddl kernel: RAID5 conf printout: kernel: -- rd:3 wd:2 fd:l kernel: disk 0, o:l, dev:sdbl kernel: disk 2, o:l, dev:sddl $ cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raidO] [raidl] [raidlO] mdO : active raid5 sdbl[0] sddl[2] sdcl[3] (F) 1023404544 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U] unused devices: <none> Поскольку RAID 5 представляет собой избыточную конфигурацию, массив продол- жает функционировать в режиме деградации, так что пользователи могут не заметить возникшей проблемы. Для того чтобы удалить накопители из конфигурации RAID, выполните команду mdadm -г. $ sudo mdadm /dev/mdO -г /dev/sdcl mdadm: hot removed /dev/sdcl Как только диск будет логически удален, вы можете остановить систему и заменить накопитель. Аппаратное обеспечение, допускающее “горячую замену”, позволяет про- изводить замену дисков без остановки системы и ее перезагрузки. Если компонентами массива RAID являются необработанные диски, вы должны за- менить их только идентичными дисками. Компоненты, имеющие разделы, можно заме-
292 Часть I. Основы администрирования нить любым разделом такого же размера, хотя, с точки зрения соответствия полос про- пускания, лучше, если аппаратное обепечение дисков является одинаковым. (Если ваша конфигурация RAID построена на основе разделов, вы должны запустить утилиту раз- биения диска и правильно определить разделы, прежде чем добавлять диск в массив.) В нашем примере сбой всего лишь смоделирован, поэтому мы можем добавить на- копитель обратно в массив, не заменяя никакого аппаратного обеспечения. $ sudo mdadm /dev/mdO -a /dev/sdcl mdadm: hot added /dev/sdcl Драйвер md немедленно начнет перестраивать массив. Как обычно, за выполнением этой процедуры вы можете следить с помощью файла /ргос/mdstat. Перестройка мо- жет идти часами, так что учтите этот факт, составляя план по восстановлению системы после сбоя. 8.8. Управление логическими томами Представьте себе ситуацию, в которой вы не знаете, насколько большим должен быть раздел. Через шесть месяцев после создания раздела выясняется, что он слишком боль- шой, а в соседнем разделе недостаточно памяти... Знакомо? Менеджер логического тома позволяет вам динамически перераспределить память между переполненным разделом и разделом, испытывающим нехватку памяти. Управление логическими томами, по существу, является максимально эффективной и абстрактной версией процедуры разделения диска. Оно группирует отдельные накопят тели в “группу томов”. Блоки в группе томов могут быть затем выделены “логическим томам”, которые представлены файлами блочных устройств и функционируют как раз- делы диска. Однако логические тома являются более гибкими и мощными, чем разделы дисков. Перечислим некоторые операции, которые можно выполнять с помощью менеджера тома. • Перемещение логических томов между несколькими физическими устройствами. • Увеличение и уменьшение логических томов на лету. • Копирование при записи “моментальных снимков” логических томов. • Замена накопителей без прекращения работы. • Создание зеркал или дисковой последовательности на логических томах. Компоненты логического тома можно объединить в одно целое разными способами. При конкатенации физические блоки устройств объединяются вместе путем их после- довательного расположения друг за другом. При создании последовательности дисков компоненты чередуются так, чтобы соседние виртуальные блоки действительно распре- делялись по нескольким физическим дискам. При устранении узких мест, связанных с отдельными дисками, создание последовательности дисков часто позволяет расширить полосу пропускания и снизить время простоя. Реализации управления логическими томами Почти все рассмотренные нами операционные системы поддерживали управление логическими томами. За исключением системы Solaris с ее файловой системой ZFS, все системы похожи друг на друга.
Глава 8. Дисковая память 293 Кроме файловой системы ZFS, операционная система Solaris поддерживает предыду- щую версию менеджера управления системными дисками под названием Solaris ХЫшпе Manager или Solstice DiskSuite. Этот менеджер томов по-прежнему поддерживается, но для инсталляции новых версий требуется использование файловой системы ZFS. Менеджер логических томов (logical volume manager — LVM) в системе Linux, кото- рый называется LVM2, по существу, представляет собой клон менеджера логических то- мов системы HP-UX, который в свою очередь основан на программном обеспечении Veritas. Команды в этих двух системах практически идентичны, но мы покажем вариан- ты для обеих систем, поскольку вспомогательные команды все же немного отличаются друг от друга. Система AIX основана на тех же абстракциях, но использует другой син- таксис команд. Параллели между этими системами приведены в табл. 8.4. Таблица 8.4. Сравнение команд LVM Операция Linux HP-UX AIX Физический том Создать pvcreate pvcreate - Инспектировать pvdisplay pvdisplay Ispv Изменить pvchange pvchange chpv Проверить pvck pvck — Группа томов Создать vgcreate vgcreate mkvg Изменить vgchange vgchange chvg Расширить vgextend vgextend extendvg Инспектировать vgdisplay vgdisplay Isvg Проверить vgck — - Enable vgscan vgscan varyonvg Логический том Создать Ivcreate Ivcreate mklv Изменить Ivchange Ivchange chlv Изменить объем Ivresize Ivextend, Ivreduce extendlv Инспектировать Ivdisplay Ivdisplay Islv Кроме команд, работающих с группами томов и логическими томами, в табл. 8.4 так- же показана совокупность команд, относящихся к “физическим томам”. Физический том — это накопитель, к которому применяется метка LVM; применение этой мет- ки является первым этапом использования устройства с помощью менеджера логиче- ских томов. Для применения этой метки системы Linux и HP-UX используют команду pvcreate, а в системе AIX эту задачу автоматически выполняет команда mkvg. Кроме регистрационной информации, эта метка содержит уникальный идентификатор, позво- ляющий однозначно распознавать накопитель. Физический том”— неудачный термин, потому что физические тома не должны иметь прямого соответствия с физическими устройствами. Они могут быть дисками, но °Ни могут быть и разделами дисков, и массивами RAID. Для менеджера логических то- ов это не имеет значения.
294 Часть I. Основы администрирования Управление логическими томами в системе Linux Менеджером логических томов в системе Linux (LVM2) можно управлять с по- мощью либо большой группы простых команд (приведенных в табл. 8.4), либо одной команды Ivm и ее многочисленных подкоманд. Все эти опции име- ют одно и то же назначение; фактически отдельные команды действительно прямо обращаются к команде Ivm, которая проверяет, как ее вызвали, чтобы знать, как реагировать. Хорошим описанием этой системы и ее инструментов является справочная страница man Ivm. Процесс настройки менеджера логических томов в системе Linux состоит из несколь- ких этапов. • Создание (на самом деле, определение) и инициализация физических томов. • Добавление физических томов в группу томов. • Создание логических томов по группе томов. Команды LVM начинаются с буквы, определяющей уровень абстракции, на котором они действуют: команды с префиксом pv манипулируют физическими томами, vg — группами томов, a lv — логическими дисками. Команды, имеющие префикс Ivm (на- пример, Ivmchange), оперируют системой в целом. В следующем примере мы установили устройство /dev/mdO RAID 5, созданное ра- нее, для использования менеджером логических томов и создания логического тома. Поскольку создание последовательности дисков и избыточность обеспечиваются базо- вой конфигурацией RAID, мы не будем использовать соответствующие возможности менеджера LVM2, хотя они существуют. $ sudo pvcreate /dev/mdO Physical volume "/dev/mdO" successfully created Наше физическое устройство теперь готово для добавления в группу томов. $ sudo vgcreate DEMO /dev/mdO Volume group "DEMO” successfully created Несмотря на то что в этом примере используется только одно физическое устройство, мы, разумеется, могли добавить дополнительные накопители. В данном случае было бы странным добавлять еще один массив RAID 5, поскольку частичная избыточность не принесет никакой выгоды. Имя DEMO было выбрано произвольным образом. Для проверки наших действий используем команду vgdisplay. $ sudo vgdisplay DEMO -- Volume group --- VG Name System Format Metadata Areas Metadata Sequence No VG Access VG Status MAX LV Cur LV Open LV Max Cur Act DEMO ID lvm2 1 1 read/write resizable 0 0 0 0 1 1 pv PV PV
Глава 8. Дисковая память 295 VG Size PE Size Total PE Alloc РЕ / Size Free РЕ / Size VG UUID 975.99 GB 4.00 MB 249854 0/0 249854 / 975.99 GB NtbRLu-RqiQ-3Urt-iQZn-vEvJ-uOTh-FVYKWF Аббревиатура “PE” обозначает физический блок — единицы памяти, на которые раз- деляется группа томов. На последних этапах создается логический том в группе DEMO, а затем создается файловая система внутри этого тома. Мы создаем логический том размером 100 Гбайт. $ sudo Ivcreate -L 100G -n webl DEMO Logical volume ’’webl'’ created Большинство интересных возможностей менеджера LVM2 относится к уровню логи- ческого тома. В частности, они включают в себя возможности создания последователь- ности дисков, зеркал и смежного размещения. Теперь к логическому тому можно обращаться по имени /dev/DEMO/webl. Мы об- судим файловые системы в разделе 8.9, а пока кратко опишем создание стандартной файловой системы для демонстрации некоторых особенностей работы менеджера LVM. $ sudo mkfs /dev/DEMO/webl $ sudo mkdir /mnt/webl $ sudo mount /dev/DEMO/webl /mnt/webl Мгновенные копии тома Вы можете создать копию при записи любого логического тома LVM2, независимо от того, содержит он файловую систему или нет. Это свойство удобно для создания стати- ческого образа файловой системы, предназначенного для резервного копирования, но, в отличие от мгновенных копий системы ZFS, мгновенные снимки LVM2, к сожалению, не очень полезны для контроля версий. Проблема заключается в том, что логические тома имеют фиксированный размер. Когда создается логический том, пространство на диске выделяется из группы томов. Копирование при записи изначально не потребляет дисковую память, но при модифи- кации блоков менеджер тома должен найти место для хранения как старой, так и новой версии. При создании мгновенных копий это пространство, необходимое для модифи- цированных блоков, должно резервироваться, причем, как и любой том LVM, выделен- ная память должна иметь фиксированный размер. При этом не имеет значения, что модифицируется — оригинальный том или его мгновенная копия (которая по умолчанию должна записываться). В любом случае затра- ты на дублирование блоков перекладываются на мгновенные копии. Выделение памяти для мгновенных копий можно сократить за счет активности тома, играющего роль ис- точника данных, во время простоя мгновенных копий. Если объем памяти, выделенный для мгновенной копии, не совпадает с объемом памяти, выделенным для тома, образ которого копируется, возможен выход за преде- лы памяти, выделенной для мгновенной копии. Намного хуже, чем кажется, поскольку менеджер томов не сможет обеспечить хранение согласованного образа мгновенной ко- пии; потребуется дополнительная память только лишь для хранения самой копии. В ре- зультате выхода за пределы выделенного пространства менеджер LVM прекращает под- держивать мгновенные копии, и они безвозвратно повреждаются.
296 Часть I. Основы администрирования Итак, как показывает практика, мгновенные копии должны быть либо краткосроч- ными, либо такими же большими, как их источники. Эти аргументы свидетельствуют в пользу “многочисленных дешевых виртуальных копий.” Для того чтобы создать том /dev/DEMO/webl-snap как мгновенную копию тома /dev/DEMO/webl, можно использовать следующую команду. $ sudo Ivcreate -L 100G -s -n webl-snap DEMO/webl Обратите внимание на то, что мгновенная копия имеет самостоятельное имя, а ее источник должен быть задан как группа_томов/том. Теоретически том /mnt/webl сначала необходимо демонтировать, чтобы гаранти- ровать согласованность файловой системы. На практике система ext4 защищена от по- вреждения, хотя существует вероятность потерять самые свежие изменения блоков дан- ных. Это идеальный компромисс для мгновенных копий, используемых при резервном копировании. Для того чтобы проверить состояние мгновенных копий, следует выпонить команду Ivdisplay. Если она сообщает, что мгновенная копия “не активна”, это значит, что она вышла за пределы выделенного пространства и должна быть удалена, поскольку с такой мгновенной копией практически ничего сделать нельзя. Резервирование файловых систем Переполнение файловых систем происходит чаще, чем сбои дисков, и одно из пре- имуществ логических томов заключается в том, что манипулировать ими гораздо легче, чем жесткими разделами. Мы сталкивались с разными ситуациями: от хранения личных;, файлов MP3 на сервере до департаментов, компьютеры которых переполнены почтовым мусором. Менеджер логических дисков ничего не знает о содержимом своих томов, но изме- нять размеры необходимо на уровне как тома, так и файловой системы. Порядок за- висит от конкретной операции. При уменьшении размера следует работать с файловой системой, а при увеличении — с томом. Это правило запоминать не стоит: просто сле- дуйте здравому смыслу. Предположим, что в нашем примере том /mnt/webl увеличился больше, чем пред- полагалось, и ему нужно дополнительно 10 Гбайт дисковой памяти. Сначала проверим группу томов, чтобы убедиться, что дополнительное место существует. $ sudo vgdisplay DEMO --- Volume group - VG Name DEMO System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 18 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 975.99 GB PE Size 4.00 MB Total PE 249854
Глава 8. Дисковая память 297 Alloc РЕ / Size_____________51200 / 200.00 GB_______________________ Р Free РЕ / Size 198654 / 775.99 GB VG UUID NtbRLu-RqiQ-3Urt-iQZn-vEvJ-uOTh-FVYKWF Итак, есть много свободной дисковой памяти, поэтому мы должны демонтировать файловую систему и использовать команду Ivresize, чтобы добавить место на логиче- ском томе. $ sudo umount /mnt/webl $ sudo Ivchange -an DEMO/webl $ sudo Ivresize -L +10G DEMO/webl $ sudo Ivchange -ay DEMO/webl Extending logical volume webl to 110.00 GB Logical volume webl successfully resized Команды Ivchange необходимы для того, чтобы деактивировать том, изменить его объем, а потом вновь активировать. Эта часть необходима только потому, что существует копия тома webl из предыдущего примера. После изменения объема копия “увидат” дополнительные 10 Гбайт, но поскольку файловая система содержит только 100 Мбайт, копию можно по-прежнему использовать. Теперь мы можем изменить объем файловой системы с помощью команды resize2f s. (Цифра 2 взята из имени оригинальной файловой системы ext2, но команда поддерживает все версии этой файловой системы.) Поскольку команда resize2fs мо- жет определять объем новой файловой системы по тому, нам не обязательно указывать новый объем явным образом. Это необходимо только при уменьшении размера файло- вой системы. $ sudo resize2fs /dev/DEMO/webl resize2fs 1.41.9 (22-Aug-2009) Please run ’e2fsck -f /dev/DEMO/webl' first. Ой! Команда resize2fs вынуждает дважды проверять согласованность файловой системы до изменения объема. $ sudo e2fsck -f /dev/DEMO/webl e2fsck 1.41.9 (22-Aug-2009) Pass 1: Checking inodes, blocks, and sizes /dev/DEMO/webl: 6432/6553600 files (0.1% non-contiguous), 473045/26214400 blocks $ sudo resize2fs /dev/DEMO/webl resize2fs 1.41.9 (22-Aug-2009) Resizing the filesystem on /dev/DEMO/webl to 28835840 (4k) blocks. The filesystem on /dev/DEMO/webl is now 28835840 blocks long. Ну вот! Проверка информации, которая выводится командой df, снова показывает изменения. $ sudo mount /dev/DEMO/webl /mnt/webl $ df -h /mnt/webl Filesystem Size Used Avail Use% Mounted on /dev/mapper/DEMO-web 1109G 188M 103G 1% /mnt/webl
298 Часть I. Основы администрирования Управление логическими томами в системе HP-UX в системе HP-UX 10.20 существует полноценный менеджер логических томов. ЛЗЕЛ это прекрасное дополнение, особенно если учесть, что в прошлом система HP-UX вообще не поддерживала концепции разбиения дисков. Менеджер то- мов называется LVM, так же как в системе Linux, хотя версия системы HP-UX является совершенно самостоятельной. (На самом деле это программное обе- спечение компании feritas...) В качестве простого примера посмотрим, как конфигурировать жесткий диск объе- мом 75 Гбайт с помощью менеджера LVM. По сравнению с ранее рассмотренным при- мером, относящимся к системе Linux, новая процедура выглядит знакомой. Есть не- сколько незначительных отличий, но в целом процесс тот же. Команда pvcreate идентифицирует физические тома. $ sudo pvcreate /dev/rdisk/disk4 Creating "/etc/lvmtab_p”. Physical volume "/dev/rdisk/disk4" has been successfully created. Если диск будет использоваться как загрузочный, добавьте в команду pvcreate оп- цию -В, чтобы зарезервировать пространство для загрузочного блока, а затем запустите команду mkboot, чтобы инсталлировать его. Определив диск как физический том, добавьте его в новую группу томов с помощью команды vgcreate. Для групп томов существует два формата метаданных — версии 1.0 и 2.0. Номер версии задается с помощью опции -V при создании группы томов; вер- сия 1.0 задается по умолчанию. Версия 2.0 предусматривает более высокие пределы для объема, но не может использоваться для загрузочных накопителей или для замены то- мов. Даже метаданные версии 1.0 имеют щедрые лимиты, поэтому она используется в большинстве случаев. Точные пределы можно увидеть с помощью команды Ivmadm. Для примера посмотрим на пределы, предусмотренные для версии 1.0. $ sudo Ivmadm -t -V 1.0 --- LVM Limits --- VG Version 1.0 Max VG Size (Tbytes) 510 Max LV Size (Tbytes) 16 Max PV Size (Tbytes) 2 Max VGs 256 Max LVs 255 Max PVs 255 Max Mirrors 2 Max Stripes 255 Max Stripe Size (Kbytes) 32768 Max LXs per LV 65535 Max PXs per PV 65535 Max Extent Size (Mbytes) 256 Добавить дополнительные диски в группу томов можно с помощью команды vgextend, но в данном примере группа томов содержит только один диск. $ sudo vgcreate vgOl /dev/disk/disk4 Increased the number of physical extents per physical volume to 17501. Volume group ”/dev/vg01" has been successfully created. Volume Group configuration for /dev/vg01 has been saved in Ietc/lvmconf/vgOl.con
Глава 8. Дисковая память 299 Добавив диски в подходящую группу томов, пул дискового пространства, относя- щийся к данной группе томов, можно снова разбить на логические тома. Новый логи- ческий том создает команда Ivcreate. Объем тома в мегабайтах задается опцией -L, а в терминах логических диапазонов (как правило, 4 двоичных мегабайта) — с помощью флага -1. Размеры, заданные с помощью двоичных мегабайтов, округляются до ближай- шего целого числа, кратного размеру логического диапазона. Для доступа к объему свободного пространства, оставшегося в группе томов, необ- ходимо выполнить команду vgdisplay имя_группы_томов как корневую. Результаты содержат размер данного логического диапазона и количество свободных логических диапазонов. $ sudo Ivcreate -L 25000 -n webl vgOl Logical volume ”/dev/vg01/webl" has been successfully created with character device "/dev/vgOl/rwebl". Logical volume "/dev/vgOl/webl" has been successfully extended. Volume Group configuration for /dev/vgOl has been saved in /etc/lvmconf/vgOl.conf Приведенная выше команда создает логический том объемом 25 Гбайт С Име- нем webl. Создав логические тома, можно верифицировать их, выполнив команду vgdisplay -v /dev/имя_группы_томов и проверив их размеры, и убедиться, что они установлены правильно. В большинстве сценариев после этого можно создать файловую систему /dev/vgOl/ webl и смонтировать ее во время загрузки. Детали изложены в разделе 8.9. Еще одним распространенным способом создания логического тома является выпол- нение команды Ivcreate, которая создает том нулевого объема, и команды Ivextend, чтобы добавить в этот том дополнительную память. Таким образом можно точно ука- зать, какие физические тома в группе томов должны образовывать логический том. Если память выделяется с помощью команды Ivcreate (как в приведенном выше примере), она просто использует свободные логические диапазоны из любых доступных физиче- ских томов в группе томов. Это удобно во многих ситуациях. Как и в системе Linux, создание последовательности дисков (striping), которая в сис- теме HP-UX называется “распределенным выделением памяти”, а также создание зер- кал происходят на уровне логического тома. Эту операцию можно выполнить при соз- дании логического тома с помощью команды Ivcreate или позднее с помощью ко- манды Ivchange. В противоположность системе Linux, менеджер логических томов не позволяет делать мгновенные копии. Однако временные копии доступны как свойство файловой системы VxFS в рамках операционной системы HP-UX. Если вы планируете использовать логический том как загрузочный, менять накопите- ли или хранить снимки памяти ядра системы, должны указать непрерывную область па- мяти и отключить некорректные блоки с помощью опций -С и -г команды Ivcreate.15 # Ivcreate -С у -г n -L 1500 -n root vgOl Logical volume "/dev/vgOl/root” has been successfully created with character device "/dev/vg01/rroot". 15 Для того чтобы удовлетворить требования системы HP-UX, необходимо сначала создать том подкачки, так чтобы первые два двоичных гигабайта физического диска и загрузочный том были Расположены на первом логическом томе. Создание корневого тома объемом 1,5 Гбайт и тома под- качки объемом 500 Мбайт в приведенном примере выполнялось именно из-за упомянутых ограни- чений. Корневой раздел может иметь больше памяти, чем указано здесь, но загрузочный и корне- Вой тома должны быть разными. Подробности можно найти на справочной странице для команды ^loboot.
300 Часть I. Основы администрирования Logical volume ’’/dev/vgOl/root" has been successfully extended. Volume Group configuration for /dev/vgOl has been saved in /etc/lvmconf/vgOl.conf # Ivcreate -С у -r n -L 500 -n swap vgOl Logical volume "/dev/vgOl/swap" has been successfully created with character device "/dev/vgOl/rswap". Затем необходимо выполнить команду Ivlnboot, чтобы уведомить систему о новом корневом томе и томе подкачки. Более подробную информацию о процедурах для томов загрузки, подкачки и создания снимков памяти можно найти на справочной странице Ivlnboot. Управление логическими томами в системе AIX е Набор команд менеджера логических томов в системе AIX отличается от на- боров команд менеджеров томов в системах Linux и HP-UX, но его базовая архитектура и подход являются аналогичными. Существует одна тонкость: система AIX вызывает объекты, которые известны как “диапазоны” (т.е. еди- ницы памяти в группе томов). Поскольку эти сущности обычно называются разделами, которых на самом деле в системе AIX не существует, никаких про- тиворечий не возникает. Однако пользователи других систем должны учиты- вать сложившуюся терминологию. По отношению к физическим томам, группам томов и логическим томам термино- логия системы AIX является стандартной. Интерфейс SMIT для управления логически- ми томами предусматривает практически полный набор функций, но, кроме них, можно использовать команды, перечисленные в табл. 8.4. Следующие четыре команды создают группу томов с именем webvg, логический том с именем webl и файловую систему JFS2 в томе webl. Затем файловая система монтируется в томе /mnt/webl. $ sudo mkvg -у webvg hdiskl webvg $ sudo crfs -v jfs2 -g webvg -m /mnt/webl -a size=25G File system created successfully. 26213396 kilobytes total disk space. New File System size is 52428800 $ sudo mkdir /mnt/webl $ sudo mount /mnt/webl Система AIX не требует использования меток дисков для включения их в физические тома. Команды mkvg и extendvg автоматически наносят метки на диски в процессе ин- дукции. Отметим, что команда mkvg получает имя накопителя, а не путь к дисковому накопителю. Логический том и файловую систему можно создать на разных этапах (с помощью команд mklv и mkfs соответственно), но команда crfs выполняет обе эти задачи, а также обновляет файл /etc/filesystems. Точное имя логического тома, содержащего файловую систему, создается в рамках сценария crfs, но его можно определить, про- верив файл /etc/filesystems или выполнив команду mount. (С другой стороны, если возникнут проблемы, будет трудно расшифровать файловые системы на томах, имею- щих обобщенные имена.) Если команда mklv выполняется непосредственно, можно не только задать имя на- копителя по своему выбору, но и указать разные параметры менеджера томов, например
Глава 8. Дисковая память 501 конфигурации для создания последовательности дисков или зеркал. Мгновенные копии реализуются посредством файловой системы JFS2, а не менеджера томов. 8.9. Файловые системы Даже после разбиения жесткого диска на разделы или логические тома он еще не готов хранить файлы. Для этого необходимо реализовать все абстракции и функции, описанные в главе 6, в терминах блоков. Они реализуются кодом, который называется файловой системой и требует дополнительных затрат ресурсов и данных. Первым стандартом файловой системы, получившим широкое распространение сре- ди систем UNIX, стала система Berkeley Fast File System, реализованная Мак-Кьюзиком и его соавторами (McKusick et al.) в 1980-х годах. С некоторыми поправками она в кон- це концов стала известна как UNIX File System (UFS) и заложила основы для разработ- ки других файловых систем, включая семейство файловых систем ext в системе Linufc, UFS в системе Solaris и JFS компании IBM. В ранних версиях операционных систем реализация файловой системы была встрое* на в ядро, но вскоре стало ясно, что поддержка многочисленных типов файловьвЙи- стем является важной целью. Разработчики систем UNIX создали хорошо определенный интерфейс ядра, позволявший одновременно активировать ИЙЙйолько типов файловых систем. Кроме того, базовое аппаратное обеспечение была ябстрагировано с помощью интерфейса файловой системы, так что файловые системы видели примерно такой же интерфейс для накопителей, что и другие программы системы UNIX, имеющие доступ к дискам через файлы устройств в каталоге /dev. Изначально поддержка нескольких типов файловых систем объяснялась необходимо- стью поддерживать системы NFS и файловые системы для сменных носителей. Однако как только шлюз был открыт, началась эра поисков; многие группы стали работать над улучшением файловых систем. Некоторые из этих файловых систем были предназначе- ны для конкретных операционных систем, а другие (например, ReiserFS) не были связа- ны ни с какими определенными операционными системами. Если бы у вас было право выбора файловых систем, разве должны вы исследовать раз- ные варианты и выбирать “лучший”? Конечно, нет, если только вы не работаете с дан- ными, предназначенными для очень специфичного приложения. Практически во всех ситуациях лучше работать с решениями, принятыми в системе по умолчанию. Именно это, вероятно, предполагается разработчиками документации и административных ин- струментов для операционных систем. Не подвергаются сомнению только несколько функциональных возможностей. • Высокая производительность. • Устойчивость к отказам и перебоям электропитания без повреждения файловой системы. • Способность работать с дисками и файловыми системами, которые являются до- статочно большими для того, чтобы удовлетворить потребности пользователей. К счастью, решения, принятые по умолчанию в современных файловых системах, Уже соответствуют этим требованиям. Любое улучшение, которое можно ожидать от из- менения файловых систем, будет незначительным и, в лучшем случае, зависящим от контекста. В следующих разделах мы обсудим файловые системы, реализованные по умолчанию в системах Linux, HP-UX и AIX. Файловая система ZFS, используемая в операционной
302 Часть I. Основы администрирования системе Solaris, управляется особым образом и заслуживает описания в отдельном раз- деле (см. раздел 8.10). Файловые системы Linux: семейство ext Д “Вторая расширенная файловая система” (“second extended filesystem”), по- лучившая название ext2, долгое время была основным стандартом в систе- ме Linux. Она была разработана и реализована Реми Кардом (Remy Card), Теодором Тс’о (Theodore Ts’o) и Стивеном Твиди (Stephen Tweedie). Помимо того, что код файловой системы ext2 был написан специально для систе- мы Linux, с функциональной точки зрения он похож на файловую систему Berkeley Fast File System. Файловая система ext3 расширяла возможности журналирования (journaling), кото- рые имелись в существовавшем коде ext2, и представляла собой концептуально простую модификацию, резко повышавшую надежность. Еще более интересным является то, что расширения в файловой системе ext3 были реализованы без изменения фундамен- тальной структуры файловой системы ext2. Фактически вы можете монтировать фай- ловую систему ext3 так, будто это файловая система ext2, просто без дополнительных возможностей журналирования. Файловая система ext3 резервирует область памяти на диске для журнала. Журнал размещается на диске так, будто он представляет собой обычный файл в корневом раз- деле файловой системы и не является отдельным структурным компонентом. При выполнении операции с файловой системой требуемые модификации сначала записываются в журнал. Когда обновление журнала завершено, в него вносится “запись о фиксации” (“commit record”), чтобы отметить конец вводимых данных. Только затем происходит модификация обычной файловой системы. Если в процессе обновления происходит сбой, файловая система использует журнал для реконструкции полностью согласованной файловой системы.16 Журналирование уменьшает время, необходимое для проверки согласованности файловой системы (см. раздел, посвященный команде fsck), примерно на одну секунду в расчете на одну файловую систему. После сбоя аппаратного обеспечения определенно- го типа состояние файловой системы ext3 можно практически мгновенно восстановить. Файловая система ext4 представляет собой определенное улучшение своих предшест- венников. Она расширяет пределы максимально допустимой памяти, увеличивает про- изводительность некоторых операций и позволяет использовать для выделения памяти не отдельные блоки диска, а “логические диапазоны” (“extents”). Дисковый формат вполне совместим с файловыми системами ext2 и ext3 и допускает их монтирование в виде файловой системы ext4. Более того, если не используются логические диапазоны, то файловые системы ext4 могут монтироваться так, будто они являются файловыми си- стемами ext3. При работе в операционной системе Linux с ядром 2.6.28 рекомендуется использо- вать файловую систему ext4, а не предыдущие версии.17 В системах Ubuntu и SUSE она используется по умолчанию, а система Red Hat сохраняет файловую систему ext3. 16 В большинстве случаев в журнал заносятся только метаданные. Реальные данные хранятся непосредственно в файловой системе. Однако это можно изменить с помощью опции data ко- манды mount. Подробности можно найти на справочной странице, посвященной команде mount. 17 Некоторые утверждают, что требование использовать файловую систему ext4 в ядре 2.6.28 яв- |Дяется преждевременным. Тем не менее текущая версия этой файловой системы является надежной.
Глава 8. Дисковая память 303 В существующую файловую систему ext2 легко добавить журнал, тем самым рас- ширив ее возможности до систем ext3 или ext4 (благодаря обратной совместимости, от- личия между ними трудно уловимы). Для этого достаточно просто выполнить команду tune2fs с опцией - j. # tune2fs -j /dev/hda4 После этого, возможно, потребуется модификация некоторой записи в файле /etc/ fstab, чтобы заменить строки ext4 строками ext2 (информация о файле fstab при- водится далее). Файловые системы HP-UX: VxFS и HFS КЛ Файловая система VxFS является основной в операционной системе HP-UX. Она основана на файловой системе, изначально разработанной компанией Veritas Software, которая в настоящее время стала частью компании Symantec. Поскольку она содержит журнал, ее иногда называют JFS (Journaled File System — журналируемая файловая система). Тем не менее не следует путать ее с файловой системой JFS2 в операционной системе AIX; это разные фай- ловые системы. Файловая система VxFS — уникальное явление среди файловых систем. Ойа отлича- ется тем, что поддерживает кластеризацию, т.е. одновременную модификацию со сторо- ны многих независимых компьютеров. Этот вид операции связан с определенным сни- жением производительности, поскольку файловая система выполняет дополнительные действия, чтобы обеспечить согласованность кеша среди компьютеров. По умолчанию функциональные возможности кластеризации отключены; для того чтобы их включить, необходимо использовать опцию -о cluster команды mount Ранее основной файловой системой в системе HP-UX считалась HFS, которая была основана на файловой системе UNIX File System. В настоящее время она устарела, хотя и поддерживается до сих пор. Файловая система JFS2 в операционной системе AIX • Еще одной файловой системой, ведущей свое происхождение от системы Berkeley Fast File System, является JFS2. Буква J означает “журналируемая” (“journaled”), хотя система JFS2 имеет и другие особенности. Например, логи- ческие разделы, динамическое размещение индексных дескрипторов (inodes) и использование структуры дерева В+ для хранения элементов каталога. Кроме того, файловая система JFS2 интересна тем, что она доступна по лицензии GNU General Public License и работает в операционной системе Linux тоже. Терминология файловой системы Благодаря своему родству с файловыми системами UFS, многие файловые системы используют общую описательную терминологию. Реализации базовых объектов часто изменяются, но термины по-прежнему широко употребляются системными администра- торами как обозначения фундаментальных понятий. Например, индексные дескрипто- ры (“inodes”) — это записи фиксированной длины в таблице, каждый элемент которой хранит информацию об отдельном файле. Ранее они заносились в эту таблицу в момент создания файловой системы, но в настоящее время некоторые файловые системы созда-
304 Часть I. Основы администрирования ют их динамически при необходимости. В любом случае индексный дескриптор обычно имеет идентификационный номер, который можно увидеть с помощью команды Is -i. Индексные дескрипторы указывают на элементы каталога. При создании жесткой ссылки на существующий файл создается новый элемент каталога, но не новый индекс- ный дескриптор. В системах с заранее размещенными индексными дескрипторами необходимо зара- нее решить, сколько их следует создать. Поскольку невозможно предсказать, сколько их понадобится в будущем, команды создания файловой системы используют эмпириче- скую формулу, основанную на объеме тома и среднем размере файлов. Если вы плани- руете хранить огромное количество маленьких файлов, это число следует увеличить. Суперблок (superblock) — это запись, описывающая характеристики файловой систе- мы. Она содержит информацию о длине блока диска, размере и местоположении та- блиц индексных дескрипторов, карту блоков и информацию о их использовании, раз- мер групп блоков и некоторые другие важные параметры файловой системы. Поскольку повреждение суперблока может привести к потере очень важной информации, его не- сколько копий хранятся в разных местах. Для повышения производительности файловые системы кешируют блоки диска. Кешировать можно все блоки диска, включая суперблоки, блоки индексных дескрипто- ров и информацию о каталоге. Кеши обычно не допускают “сквозной записи” (“write- through”), поэтому может возникнуть задержка между моментом, когда приложение считает, что блок записан, и моментом, в который блок действительно записывается на диск. Приложения могут требовать от файла более предсказуемого поведения, но в этом случае пропускная способность снизится. Системный вызов sync направляет модифицированные блоки в место их постоянно- го хранения на диске, стараясь моментально обеспечить полную согласованность дис- ковой файловой системы. Это периодическое сохранение минимизирует потерю дан- ных, которая может произойти при сбое из-за многочисленных несохраненных блоков. Файловые системы могут самостоятельно выполнять синхронизацию своего расписания или предоставить это операционной системе. Современные файловые системы имеют механизм журналирования, минимизирующий или исключающий возможность повреж- дения их структуры при сбое, поэтому частота синхронизации должна зависеть от того, сколько блоков могут оказаться потерянными при сбое. В файловой системе карта дисковых блоков — это таблица содержащихся в ней сво- бодных блоков. При записи новых файлов система изучает эту карту, чтобы найти эф- фективную схему хранения. Записи об использовании блоков содержат важную инфор- мацию об уже используемых блоках. В файловых системах, поддерживающих логические разделы, эта информация может быть значительно сложнее, чем обычная битовая карта, которая применялась в старых файловых системах. Полиморфизм файловых систем Файловая система — это программное обеспечение, состоящее из многочисленных компонентов. Одна ее часть находится в ядре (или же в пользовательском пространстве системы Linux; наберите в поисковой машине google аббревиатуру FUSE) и реализует основные операции, связанные с трансляцией прикладного интерфейса стандартной файловой системы в операции чтения и записи блоков диска. Другие части состоят из пользовательских команд для форматирования новых томов, проверки целостности файловой системы и выполнения других специальных операций, связанных с формати- рованием.
Глава 8. Дисковая память 305 Ранее стандартные пользовательские команды знали о файловой системе, которую использовала операционная система, и просто реализовали требуемые функциональные возможности. Команда mkfs создавала новые файловые системы, команда f sck устра- няла проблемы, а команда mount, в основном, просто вызывала системные функции. Современные файловые системы являются более модульными, поэтому эти команды те- перь вызывают реализации утилит, связанных с файловой системой. Точный способ реализации зависит от операционной системы. Например, операци- онная система Linux помещает отдельные команды с именами mkfs. имя_файловой__си- стемы, fsck .имя файловой системы и так далее в обычные каталоги, предназначен- ные для системных команд. (Эти команды можно также выполнить непосредственно, но такие ситуации возникают редко.) Система AIX имеет переключатель /etc/vfg, в который записываются метаданные для файловых систем (не следует его путать с пере- ключателем /etc/vfstab в системе Solaris, который эквивалентен файлам fstab йли filesystems в других системах; впрочем, в системе ZFS он не нужен). Команда mkfs: форматирование файловых систем Для создания новой файловой системы следует выполнить следующую команду. mkfs [-Т тип_файловой_системы ] [-о опции] накопитель По умолчанию тип_файловой_системы может быть жестко закодирован в упаков- щике или задан в файле /etc/default/fs. Допустимые опции зависят от конкретной файловой системы, но использовать их приходится редко. Система Linux использует флаг -t, а не -Т, игнорирует флаг -о и не имеет файлов устройств, непосредственно со- ответствующих накопителям. Система AIX использует флаг -V, а не -Т. е Команда erf s в системе AIX может выделять новый логический том, созда- вать файловую систему на нем и обновлять файл /etc/filesystems за один шаг. Кроме того, можно либо включить возможность создания мгновенных копий в фай- ловых системах, которые допускают эту операцию (JFS2 и VxFS), либо разместить жур- нал файловой системы на отдельном диске. Вторая возможность в соответствующих си- туациях может обеспечить резкий прирост производительности. Команда fsck: проверка и исправление файловых систем Из-за буферизации блока и того факта, что накопители на самом деле не являются трансакционными устройствами, структуры данных на файловых системах могут стать рассогласованными. Если эти проблемы не удается быстро устранить, то это превратит- ся в лавину. Вначале это повреждение исправлялось с помощью вызова команды fsck (“filesystem consistency check”; читается как “FS check” или “fisk”), которая тщательно проверяла все стРУктуры данных и просматривала дерево выделения для каждого файла. Она исполь- зовала набор эвристических правил, описывающих возможный внешний вид файловой системы после повреждения, в разные моменты времени в процессе ее обновления. Оригинальная схема fsck работала удивительно хорошо, но поскольку она преду- сматривала чтение всех данных с диска, для больших дисков процедура могла занимать несколько часов. Одно из первых решений этой задачи было основано на концепции чистого бита файловой системы”, который устанавливался в суперблоке, когда систе- ма Демонтировалась некорректно. При повторной загрузке системы можно было уви-
306 Часть I. Основы администрирования деть чистый бит и таким образом узнать, что проверку с помощью команды f sck можно пропустить. В настоящее время журналы файловой системы позволяют команде f sck сосредото- чить свое внимание на том, что произошло во время сбоя. Команда f sck может просто восстановить предыдущее согласованное состояние файловой системы. Как правило, диски обрабатываются командой f sck автоматически во время загруз- ки, если они перечислены в системных файлах /etc/fstab, /etc/vfstab или /etc/ filesystems. Файлы fstab и vfstab содержат поля, заполненные последовательно- стью команд f sck, которые обычно используются для параллельного распределения проверок файловой системы. Однако в настоящее время команда f sck выполняется так быстро, что для нее имеет значение только один фактор — чтобы корневая файловая система проверялась первой. Команду f sck можно запустить вручную, чтобы выполнить глубокую проверку, ко- торая была характерна для ее первых версий, но для этого потребуется время. Л Семейство файловых систем ext в операционной системе Linux может бьгп^ настроено так, чтобы выполнять повторную проверку после демонтирований г определенное количество раз или по истечении определенного периода вре- > мени, даже если все демонтированные файловые системы были “чистыми”. Это полезная процедура, и в большинстве ситуаций приемлемым является значение, задаваемое по умолчанию (около 20 монтирований). Однако если ! файловые системы монтируются часто, как это происходит в настольных ра- бочих станциях, то даже эта частота выполнения команды f sck может стать* чрезмерной. Для того чтобы увеличить интервал времени до 50 монтирований, следует использовать команду tune2f s. $ sudo /sbin/tune2fs -с 50 /dev/sda3 tune2fs 1.41.9 (22-Aug-2009) Setting maximal mount count to 50 Если файловая система повреждена и команда f sck не может восстановить ее авто- матически, то не следует с ней экспериментировать, пока не создан надежный резерв* Лучшая политика страхования — применить ко всему диску команду dd и создать ре- зервный файл или диск. Большинство файловых систем создает каталог lost+found в корневом разделе каж- дой файловой системы, где команда f sck может хранить файлы, для которых невоз- можно определить родительский каталог. Каталог lost+found имеет дополнительное пространство, чтобы команда fsck могла хранить “осиротевшие” файлы, не создавая дополнительных каталогов в нестабильной файловой системе. Не удаляйте этот каталог.1’ Поскольку имя, присвоенное файлу, записывается только в родительском ката- логе, имена “осиротевших” файлов недоступны, и файлы, хранящиеся в каталоге lost+found, именуются по названиям их индексных дескрипторов. Однако таблица ин- дексных дескрипторов содержит идентификаторы UID владельца файла, что позволяет легко возвращать файл его владельцу. Монтирование файловой системы Файловую систему необходимо смонтировать до того, как она станет видимой для процессов. Точкой монтирования для файловой системы может быть любой каталог, но 18 В некоторых системах для восстановления этого каталога после удаления используется ко- манда mklost+f ound.
Глава 8. Дисковая память 307 файлы и подкаталоги, которые расположены ниже этой точки в иерархии, останутся не- доступными, пока файловая система не будет смонтирована в этой точке. Более подроб- ную информацию можно найти в разделе 6.2. После инсталляции нового диска необходимо смонтировать новые файловые систе- мы вручную, чтобы убедиться, что все работает правильно. Например, команда $ sudo mount /dev/sdal /mnt/temp монтирует файловую систему в разделе, представленном файлом устройства /dev/sdla (имена устройств зависят от операционной системы), в каталоге /mnt, который является традиционным для временных точек монтирования. Размер файловой системы можно проверить с помощью команды df. В приведен- ном ниже примере флаг -h системы Linux используется для выдачи результатов в понят- ном для человека виде. К сожалению, большинство системных значений, заданных по умолчанию для команды df, относятся к бесполезным сущностям, таким как “дисковые блоки”, но есть флаг, заставляющий команду df выдавать конкретную информацию, на- пример двоичные кило- или гигабайты. $ df -h /mnt/webl Filesystem Size Used Available Use% Mounted on /dev/mapper-DEMO-webl 109G 188M 103G 1% /mnt/webl Настройка автоматическо^йМ^рования Обычно требуется конфигурировать операционную систему так, чтобы монтировать локальные файловые системы на этапе загрузки. Файл конфигурации в каталоге /etc содержит имена устройств и точки монтирования всех системных дисков (среди прочей информации). В большинстве систем этот файл называется /etc/fstab (сокращение от “filesystem table”), но в системах Solaris и AIX он был реструктурирован и переименован: /etc/vfstab в системе Solaris и /etc/filesystems в системе AIX. Ссылаясь на эти три файла, мы используем в книге обобщенный термин “каталог файловой системы”. По умолчанию файловые системы ZFS монтируют себя автоматически и не SOiariS требуют записей из файла vfstab. Однако это поведение можно изменить, задав свойства файловой системы ZFS. Области подкачки и точки монтиро- вания нефайловых систем должны по-прежнему указываться в файле vfstab. Команды mount, umount, swapon и fsck читают каталог файловой системы, поэтому желательно, чтобы представленные в этом каталоге данные были правильными и полны- ми. Команды mount и umount используют этот каталог, чтобы выяснить, что мы хотим, указывая в командной строке только имя раздела или точку монтирования. Например, при конфигурации команды f stab в системе Linux, приведенной далее, команда $ sudo mount /media/cdromO эквивалентна следующей команде. $ sudo mount -t udf -о user,noauto,exec,utf8 /dev/scdO /media/cdromO Команда mount -а монтирует все регулярные файловые системы, перечисленные в каталоге файловой системы; обычно эта команда выполняется в рамках сценария за- пуска на этапе загрузки.19 Флаги -t, -F и -v (-t — в системе Linux, -F — в системах Solaris и HP-UX и -v — в системе AIX) в сочетании с аргументом тип_файловой_си- 19 Опция noauto команды momit исключает указанную файловую систему из процесса авто- матического монтирования с помощью команды mount -а.
308 Часть I. Основы администрирования стемы ограничивают операции над файловой системой определенного типа. Например, команда $ sudo mount -at ext4 монтирует все локальные файловые системы ext4. Команда mount читает файл fstab последовательно. Следовательно, файловые системы, смонтированные под другими файловыми си- стемами, должны следовать за своими родительскими разделами, указанными в файле fstab. Например, строка для файла /var/log должна следовать за строкой /var, если /var — отдельная файловая система. Команда umount, предназначенная для демонтирования файловых систем, имеет аналогичный синтаксис. Файловую систему, которую некий процесс использует в ка- честве своего текущего каталога или которая содержит открытый файл, демонтировать нельзя. Существуют команды, позволяющие идентифицировать процессы, препятству- ющие попыткам выполнить команду umount; см. раздел 6.2. Файл fstab в системе HP-UX встречается во всех операционных системах. Рассмот- рим его записи о системе, имеющей только одну группу томов. # Device Mount point Type Options Seq /dev/vg00/lvol3 / vxf s delaylog 0 1 /dev/vgOO/lvoll /stand vxfs tranflush 0 1 /dev/vg00/lvol4 /tmp vxfs delaylog 0 2 /dev/vg00/lvol5 /home vxfs delaylog 0 2 /dev/vg00/lvol6 /opt vxfs delaylog 0 2 /dev/vg00/lvol7 /usr vxfs delaylog 0 2 /dev/vg00/lvol8 /var vxfs delaylog 0 2 Каждая строка содержит шесть полей, разделенных пробелами, и описывает отдель- ную файловую систему. Для повышения читабельности поля обычно выравниваются, но в принципе это не требуется. Ш Более подробно система NSF описана в главе 18. Первое поле содержит имя устройства. Файл fstab может содержать точки монтиро- вания из удаленных систем. В этом случае первое поле содержит путь NFS. Обозначение server'./export означает каталог /export на машине с именем server. Второе поле задает точку монтирования, а третье — тип файловой системы. Точное название типа, идентифицирующего локальные файловые системы, зависит от конкрет- ной машины. Четвертое поле задает опции команды mount, которые должны применяться по умолчанию. Существует множество возможностей; опции, общие для всех типов фай- ловых систем, можно найти на справочной странице для команды mount. Отдельные файловые системы обычно имеют собственные опции. Все приведенные выше опции относятся к файловой системе VxFS. Например, опция delaylog снижает уровень чита- бельности, но повышает скорость выполнения команды. Более подробную информацию об этой и других опциях монтирования файловой системы VxFS можно найти на спра- вочной странице mount_yxfs. Пятое и шестое поля являются рудиментарными. Предположительно они задавали “частоту создания копии” и параметр управления параллельным выполнением команд fsck. Ни одна из этих возможностей в современных системах не актуальна. Ниже приводятся примеры файла fstab из системы Ubuntu. Общий формат тот же, но системы семейства Linux часто имеют разные особенности.
Глава 8. Дисковая память 309 ргос /ргос proc defaults О О UUID=a8e3...8f8а / ext4 errors=remount-ro О 1 UUID=13e9...b8d2 none swap sw О О /dev/scdO /media/cdromO udf,iso9660 user,noauto,exec,utf8 О 0 /dev/scdl /media/cdroml udf,iso9660 user,noauto,exec,utf8 О 0 /dev/fdO /media/floppyO auto rw,user,noauto,exec,utf8 О 0 Первая строка относится к файловой системе /ргос, которая фактически представ- лена драйвером ядра и не имеет вспомогательного запоминающего устройства. Уст- ройство ргос, указанное в первом столбце, просто занимает место. Вторая и третья строки для идентификации томов используют идентификаторы раз- делов (идентификаторы UUID, которые мы сократили, чтобы не снизить читабельность текста), а не имена устройств. Эта альтернатива полезна для систем семейства Linux, поскольку имена устройств для разделов диска являются нестабильными; добавление или удаление диска может вызвать изменение имен всех дисков (например, с /dev/sdbl на /dev/sdcl). Идентификатор UUID связан только с содержанием раздела. Это позволяет отследить раздел, если ой не был скрыт. Отметим, что это соглашение работает также и для раздела подкачки, 6для корневого раздела. Последние три строки конфигурируют поддержку дисководов CD-ROM и гибких дисков. Опция noauto предотвращает попытки системы монтировать эти устройства во время загрузки. (Если носители не вставлены, то попытки монтирования завершатся сбоем и затормозят процесс загрузки.) Опция user назначает владельцем всех файлов, записанных на сменные носители, пользователя, который их монтировал. В системах семейства Solaris формат файла /etc/vfstab был немного изме- soians нен, и некоторые поля находятся на других местах, по сравнению с системами Linux и HP-UX. Однако данные по-прежнему выводятся в виде таблицы и легко читаются без дешиф- ровки. Отличительные особенности формата файла vfstab заключаются в том, что он имеет отдельный столбец “device to f sck” и отдельный столбец “mount at boot”. еФайл /etc/filesystems в системе AIX организован как ряд списков свойств, напоминающих YAML или JSON, хотя его формат может немного ва- рьироваться. Рассмотрим пример конфигурации для одной файловой системы. /opt: dev = /dev/hdlOopt vfs = jfs2 log = /dev/hd8 mount = true check = true vol = /opt free = false Этот формат позволяет ассоциировать с каждой файловой системой произвольные свойства, так что параметры ее типа можно легко записать в каталоге filesystems. Система AIX автоматически поддерживает этот файл, когда пользователь выполняет Дисковые операции посредством интерфейса SMIT, но можно легко редактировать этот файл непосредственно.
310 Часть I. Основы администрирования Монтирование USB-накопителя Гибкие диски окончательно ушли в прошлое. Их место заняли удобные, быстрые и забавные USB-накопители. Применение этих устройств весьма разнообразно: напри- мер, персональные флешки, цифровые видеокамеры, устройства iPod и крупные внеш- ние диски. Большинство из них поддерживается системами семейства UNIX в качестве накопителей данных. В прошлом для управления USB-накопителями приходилось прибегать к специ- альным трюкам. Однако в настоящее время, когда операционные системы реализуют управление динамическими устройствами в качестве фундаментального требования, USB-накопители представляют собой просто еще один тип накопителей, которые по- являются и исчезают без предупреждения. С точки зрения управления, с USB-накопителями связаны следующие проблемы. • Ядро должно распознавать устройство и назначать ему файл устройства. • Необходимо выяснять, какие назначения были сделаны. Первый этап обычно выполняется автоматически, но в системах есть команды (на- пример, команда cfgmgr в системе AIX), которые можно выполнять непосредственно. Как только файл устройства назначен, можно использовать стандартные процедуры, описанные в разделе 8.5. Дополнительную информацию об управлении динамическими устройствами можно найти в главе 13. Включение подкачки Как правило, в качестве области подкачки используются разделы или логические тома, а не структурированные файловые системы. Вместо использования файловой си- стемы для слежения за содержимым области подкачки, ядро поддерживает собственное упрощенное отображение блоков памяти в блоки области подкачки. В некоторых системах можно выполнять подкачку с помощью файла из раздела фай- ловой системы. В старых операционных системах эта конфигурация может работать медленнее, чем при использовании специального раздела, но в редких случаях это быва- ет очень удобным. В любом случае менеджеры логических томов исключают большин- ство причин, по которым вам может понадобиться использовать файл подкачки, а не том подкачки. Ш Информацию о разделении области подкачки можно найти в разделе 29.3. Чем больше область подкачки, которую вы используете, тем больше виртуальной па- мяти могут занимать ваши процессы. Максимальная производительность виртуальной памяти достигается, когда область подкачки разделена между несколькими накопите- лями. Разумеется, лучше всего вообще не использовать подкачку; если вам необходимо оптимизировать производительность подкачки, лучше подумайте об увеличении опера- тивной памяти. Л В системах семейства Linux области подкачки должны инициализироваться с 1Л помощью команды mkswap, получающей в качестве аргумента имя накопите- ля, на котором располагается том подкачки. Вы можете самостоятельно назначить накопитель в качестве инструмента подкачки с помощью команды swapon накопитель в большинстве систем или команды swap -а накопитель в системе Solaris. Однако в большинстве случаев предпочтительнее, чтобы
Глава 8. Дисковая память 311 эта функция автоматически выполнялась на этапе загрузки. За исключением системы AIX, существует возможность перечислять области подкачки в обычном каталоге фай- ловой системы (fstab или vfstab), указав swap в качестве их типа. В системе AIX этот список хранится в отдельном файле с именем /etc/swapspaces. Для того чтобы просмотреть текущую конфигурацию подкачки, следует выполнить команды swapon -sb системах семейства Linux, swap -s — в системах Solaris и AIX и swapinfo — в системе HP-UX. В системах семейства AIX с помощью команды mkps можно создать логический том, предназначенный для подкачки, добавить его в файл /etc/swapspaces и приступить к его использованию. Эта команда вызывается из интерфейса SMIT. 8.10. Файловая система ZFS: все проблемы решены Система ZFS появилась в 2005 году как компонент операционной системы OpenSo- laris и быстро оказалась составной частью системы Solaris 10 и различных дистрибутив- ных пакетов, основанных на лицензии BSD. В 2008 году она уже могла использоваться как корневая файловая система и с тех пор стала основным выбором для операционной системы Solaris. Несмотря на то что система ZFS обычно называется файловой, на самом деле она представляет собой глобальный механизм управлений хранением данных, который включает в себя функции менеджера логических томбв и контроллера RAID. Кроме того, он заново определяет многие аспекты управления хранением данных, делая их проще, легче и более логичными. Несмотря на то что текущая версия системы ZFS име- ет несколько ограничений, большинство из них относится к категории “еще не реали- зовано”, а не “невозможно по архитектурным причинам”. Преимущества интегрирован- ного подхода, реализованного в системе ZFS, очевидны. Даже если вы еще не знакомы с системой ZFS, мы уверены, что она вам понравится. Мы почти не сомневаемся, что эта система будет широко распространена в течение следующих десяти лет. Остается неясным лишь, как долго придется ждать реализации аналогичных функций в других системах. Несмотря на то что файловая система ZFS является открытым программным обеспечением, условия ее текущей лицензии запрещают включение в ядро Linux. Проект файловой системы Btrfs компании Oracle (“В-tree file system”, официальное название “butter FS,” хотя это и вызывает ассоциации с выражением “butter face”20) пы- тается воспроизвести многие из достижений системы ZFS на платформе Linux. Эта фай- ловая система уже включена в текущие ядра систем семейства Linux для предваритель- ных испытаний. Пользователи систем Ubuntu и SUSE могут экспериментировать с ней, инсталлировав пакеты btrfs-tools или btrfsprogs соответственно. Однако файловая система Btrfs еще не готова к промышленному выпуску, и поскольку компания Oracle стала частью компании Sun, будущее систем Btrfs и ZFS остается неопределенным. Архитектура ZFS На рис. 8.4 схематично изображены основные объекты системы ZFS и их взаимос- вязи. Пул системы ZFS аналогичен группе томов в других системах с механизмами управ- ления логическими томами. Каждый пул состоит из виртуальных устройств, представ- 20 “Butter face” на сленге означает “девушка с красивой фигурой, но некрасивым лицом”. — Примеч. ред.
312 Часть I. Основы администрирования ляющих собой накопители (диски, разделы, устройства SAN и так далее), группы зеркал или массивов RAID. Рис. 8.4. Архитектура ZFS Массив ZFS RAID по существу похож на массив RAID 5 тем, что он использует одно или несколько устройств четности для обеспечения избыточности массива. Однако в системе ZFS эта схема называется RAID-Z и использует последовательности дисков переменных объемов, чтобы исключить появление “дыры записи RAID 5”. Все опера- ции записи в пул хранения распределяются по виртуальным устройствам пула, поэтому пул, содержащий только отдельные накопители, по существу, представляет собой схему RAID 0, хотя накопители в этой конфигурации не обязаны иметь одинаковые объемы. К сожалению, текущая версия массива ZFS RAID имеет недостатки. Например, в ней невозможно ни добавить новые устройства в массив после того, как он был опреде- лен, ни удалить устройство ZFS. Как и в большинстве реализаций массива RAID, на- копители в нем должны иметь одинаковые объемы; вы можете заставить систему ZFS принять накопители переменных объемов, но общий размер массива будет определяться по наименьшему объему накопителя. Для того чтобы эффективно использовать диски переменных объемов в сочетании со схемой ZFS RAID, необходимо заренее разбить ди- ски на разделы и определить оставшиеся области в качестве отдельных устройств. Несмотря на то что существует возможность передать неразделенные диски под управ- ление файловой системы ZFS, она скрытно записывает на них таблицу разделов, похожую на GPT, и выделяет все дисковое пространство на каждом диске их первым разделам. Большая часть работы по настройке системы ZFS и управлению ею выполняется по- средством двух команд: zpool и zf s. Команда zpool используется для создания пулов хранения и управления ими, а команда zf s предназначена для создания сущностей, возникших из пула, в основном файловых систем и томов, используемых в качестве об- ласти подкачки и баз данных, и управления ими. Пример: добавление диска в системе Solaris Прежде чем погрузиться в детали системы ZFS, рассмотрим небольшой пример. Допустим, что мы добавили новый диск в систему Solaris и он получил имя /dev/ dsk/c8dl. (Для того чтобы определить требуемое устройство, следует выполнить коман-
Глава 8. Дисковая память 313 ду sudo format. Команда format выведет меню системных дисков, из которого можно выбрать нужный диск, а затем нужно нажать комбинацию клавиш <Ctrl+C>.) На первом этапе необходимо пометить диск и добавить его в новый пул хранения. Solaris? sudo zpool create Homo c8dl На втором этапе ..., ну, на самом деле второго этапа нет. Система ZFS помечает диск, создает пул “demo”, корневую файловую систему внутри этого пула и монтирует эту файловую систему как /demo за один этап. Файловая система будет демонтирована ав- томатически при загрузке системы. solaris$ Is -a /demo Пример был бы еще более впечатляющим, если бы мы могли просто добавить новый диск в существующий пул хранения корневого диска, который по умолчанию называет- ся “грооГ. (Эта команда могла бы выглядеть так: sudo zpool add rpool c8dl.) К со- жалению, корневой пул может содержать только одно виртуальное устройство. Тем не менее остальные пулы допускают безболезненное расширение. Файловые системы и свойства С помощью системы ZFS очень удобно автоматически создавать файловую систему в новом пуле хранения, потому что такие файловые системы не занимают какой-то кон- кретный объем памяти. Все файловые системы, существующие в пуле, могут занимать доступное пулу пространство. В отличие от традиционных файловых систем, которые не зависят друг от друга, фай- ловые системы ZFS являются иерархическими. Существует несколько способов взаимо- действия файловых систем со своими родительскими и дочерними файловыми система- ми. Новая файловая система создается с помощью команды zfs create. solaris$ sudo zfs create demo/new__fs Solaris? zfs list -r demo NAME USED AVAIL REFER MOUNTPOINT demo 100K 488G 21K /demo demo/new_fs 19K 488G 19K /demo/new_fs Файл -г в команде zfs list означает, что она рекурсивно применяется ко всем до- черним файловым системам. Большинство остальных подкоманд zfs также понимает флаг -г. Еще более полезно то, что система ZFS автоматически монтирует новую фай- ловую систему сразу после ее создания. Для того чтобы имитировать традиционные файловые системы, имеющие фиксиро- ванный размер, к свойствам файловой системы можно добавить параметры reservation (объем дисковой памяти, зарезервированный для пула хранения и предназначенный для использования файловой системой) и quota. Эта настройка является ключевой в управ- лении системой ZFS и представляет собой определенную смену парадигмы для админи- страторов, работающих с другими системами. Для примера зададим оба значения рав- ными 1 Гбайт. solaris$ sudo zfs set reservation=lg demo/new_fs Solaris? sudo zfs set quota=lg demo/new_fs Solaris? zfs list -r demo NAME USED avail refer mountpoint demo 1.00G 487G 21K /demo demo/new_fs 19K 1024M 19K /demo/new_fs
314 Часть I. Основы администрирования Новое значение параметра quota отражается в столбце AVAIL для файловой системы /demo/new f s. Значение параметра reservation показано в столбце USED для фай- ловой системы /demo. Это объясняется тем, что резерв для файловых систем, дочерних по отношению к системе /demo, уже учтен в ее размере.21 Изменения этих значений отражаются только на учетных записях. Единственное из- менение, которое действительно касается пула хранения, — это изменение одного или двух блоков для записи новых параметров. Ни один процесс не запускается, чтобы от- форматировать один гигабайт дискового пространства, зарезервированного для фай- ловой системы /demo/new_fs. Большинство операций ZFS, включая создание нового пула хранения и новых файловых систем, выполняется так же легко. Используя иерархическую систему управления дисковым пространством, можно лег- ко группировать несколько файловых систем, чтобы гарантировать, что их общий объем не превысит заданного порога; нет необходимости задавать этот порог для каждой фай- ловой системы отдельно. Параметры quota и reservation следует задавать так, чтобы они правильно ими- тировали традиционную файловую систему фиксированного размера.22 Сам по себе па- раметр reservation просто гарантирует, что файловая система будет иметь достаточно дисковой памяти, чтобы достичь по крайней мере указанного размера. Параметр quota ограничивает размер файловой системы без гарантии, что она будет иметь этот объем памяти для своего увеличения; другой объем может занять все свободное пространство пула, не оставив места для расширения файловой системы /demo/new_f s. С другой стороны, в реальной жизни существует очень мало причин для такой на- стройки файловой системы. Эти свойства следует использовать только для демонстра- ции возможностей системы учета памяти в ZFS и чтобы подчеркнуть, что система ZFS при необходимости может быть совместимой с традиционной моделью. Наследование свойств Многие свойства естественным образом наследуются дочерними файловыми систе- мами. Например, если мы хотим смонтировать корень пула файловой системы demo в каталоге /opt/demo, а не /demo, можно просто задать соответствующий параметр mountpoint. solaris$ sudo zfs set mountpoint=/opt/demo demo solaris$ zfs list -r demo NAME USED AVAIL REFER MOUNTPOINT demo 1.00G 487G 21K /optf demo/new_fs 19K 1024M 19K /opt/demo/new_fs solaris$ Is /opt/demo new fs 21 Столбец REFER содержит объем данных в активной копии каждой файловой системы. Файловые системы /demo и /demo/new_fs имеют близкие значения значений REFER, посколь- ку обе они пустые, а не потому что между ними существует какая-то связь. 22 Параметры reservation и quota учитывают весь объем дисковой памяти, занимаемый файловой системой, включая пространство, занятое мгновенными копиями. Если вы хотите огра- ничить размер только активной копии файловой системы, следует использовать параметры ге- freservation и ref quota. Префикс ref означает “объем данных, на которые ссылается фай- ловая система”. Именно это значение показано в столбце REFER в результатах работы команды zfs list.
Глава 8. Дисковая память 315 Параметр mountpoint автоматически демонтирует файловые системы, а изменение точки монтирования влияет на дочерние файловые системы предсказуемым и очевид- ным образом. Обычные правила, касающиеся файловой системы, тем не менее, остают- ся в силе (см. раздел 6.2). Для того чтобы увидеть действительное значение конкретного свойства, использу- ется команда zfs get, а команда zf s get all выводит список значений всех параме- тров. Столбец SOURCE содержит информацию, объясняющую, почему каждое свойство имеет конкретное значение: слово local означает, что свойство было задано явно, а косая черта — что свойство предназначено только для чтения. Если значение свойства унаследовано от родительской файловой системы, то в столбце SOURCE будут указаны детали того наследования. solaris$ zfs get all demo/new fs solaris$ zfs get all demo/new fs NAME PROPERTY VALUE SOURCE demo/new_fs type filesystem - demo/new_fs creation Wed Mar 17 17:57 2010 - demo/new_fs used 19K - demo/new_fs available 1024M - demo/new_fs referenced 19K - demo/new_fs compressratio l.OOx - demo/new_fs mounted yes - demo/new_fs quota IG local demo/new_fs reservation IG local demo/new_fs mountpoint / op t / demo / ne w_f s inherited from demo ... <остальные строки, всего около 40> Внимательные читатели могут заметить, что свойства available и referenced по- дозрительно похожи на столбцы AVAIL и REFER, которые выводятся на печать коман- дой zfs list. Фактически команда zfs list — это просто другой способ вывести на печать свойства файловой системы. Если бы выше мы привели полный список результа- тов, полученных с помощью команды zfs get, то среди них были бы и использованные свойства. Для того чтобы указать, какие именно свойства нас интересуют, их можно ука- зать с помощью опции -о команды zfs list. Поскольку нет никакого смысла задавать явно значения свойств used и других свойств, связанных с объемом, эти свойства предназначаются только для чтения. Если конкретные правила вычисления значения свойства used вас по каким-то причинам не устраивают, возможно, следует использовать другие свойства, такие как usedbychildren и usedbysnapshots, чтобы увидеть, как расходуется дисковая память. Полный список свойств можно найти в справочном руководстве администратора системы ZFS. Для собственного использования и создания локальных сценариев можно задавать дополнительные, нестандартные свойства файловых систем. Процесс их задания ничем не отличается от задания стандартных свойств. Имена пользовательских свойств долж- ны содержать двоеточие, чтобы отличать их от стандартных свойств. Одна файловая система на пользователя Поскольку файловые системы не расходуют дисковую память и не требуют время на свое создание, их оптимальное количество скорее ближе к “много”, чем к “мало”. Если рабочие каталоги пользователей находятся в пуле хранения системы ZFS, рекомендуется создать отдельный рабочий каталог для отдельной файловой системы. Существует не- сколько причин для такого соглашения.
316 Часть I. Основы администрирования • Если необходимо задать квоты использования диска, то естественно в качестве единицы измерения применять рабочие каталоги. Квоты можно установить как для файловых систем для индивидуальных пользователей, так и для файловых си- стем, содержащих всех пользователей. • Мгновенные копии соответствуют отдельным файловым системам. Если каждый рабочий каталог пользователя представляет собой отдельную файловую систему, то пользователь может получить доступ к старым мгновенным копиям с помощью каталога ~ /. zf s.23 Одно это сэкономит администратору много времени, посколь- ку это значит, что пользователи могут самостоятельно обслуживать свои потреб- ности в восстановлении файлов. • Система ZFS позволяет делегировать разрешение выполнять разные операции, та- кие как поиск мгновенных копий и откат системы в предыдущее состояние. При желании можно передать пользователям контроль над этими операциями, кото- рые выполняются в их собственных каталогах. В этой книге мы не будем описы- вать детали механизма управления разрешениями в системе ZFS; их можно найти в справочнике ZFS Administration Guide. Мгновенные копии и клоны Система ZFS организована по принципу копирования при записи. Вместо переза- писывания блоков на месте, система ZFS выделяет новые блоки и обновляет указате- ли. Этот подход делает систему ZFS устойчивой к повреждениям, поскольку при сбоях или отказе электропитания и операции никогда не останутся выполненными наполо- вину. Корневой блок либо будет обновлен, либо нет; в любом случае файловая система останется согласованной (хотя некоторые недавно внесенные изменения могут быть отменены). Как и менеджер логических томов, система ZFS обеспечивает копирование при за- писи на пользовательском уровне, разрешая создавать мгновенные копии. Однако есть важное отличие: мгновенные копии системы ZFS реализуются для файловых систем, а не для логических томов, поэтому они имеют произвольную глубину детализации. Система Solaris с огромным успехом использует эту функциональную возможность в приложении Time Slider для интерфейса GNOME. Аналогично приложению Time Machine в системе Mac OS, приложение Time Slider — это комбинация назначенных заданий, создающих мгновенные копии и управляющих ими через регулярные интервалы времени, и пользо- вательского интерфейса, который позволяет найти старые версии файлов. Мгновенную копию можно создать с помощью командной строки zfs snapshot. Например, следующая последовательность команд иллюстрирует создание мгновенной копии, ее использование с помощью каталога zfs/snapshot и возвращение файловой системы в предыдущее состояние. solaris$ sudo touch /opt/demo/new_fs/now_you__seejtne Solaris? Is /opt/demo/new_fs now_you_see_me Solaris? sudo zfs snapshot demo/new_fs@snapl Solaris? sudo rm /opt/demo/new_fs/now_you__see_me solans? Is /opt/demo/new_fs 23 Этот каталог по умолчанию является скрытым; он не появляется среди результатов работы команды 1s -а. Его можно сделать видимым с помощью команды zfs set snapdir=visible фаЦло^я_система.
Глава 8. Дисковая память 317 solaris$ Is /opt/demo/new__fs/. zfs/snapshot/snapl now_you_see_me solaris$ sudo zfs rollback demo/new__fs@snapl solaris$ Is /opt/demo/new_fs now_you_see_me Каждой мгновенной копии в момент ее создания можно присвоить имя. Полная спецификация мгновенной копии обычно записывается в виде файловая_система@ мгновеннаякопия. Для рекурсивного создания мгновенных копий используется команда zfs snapshot -г. Ее эффект эквивалентен выполнению команды zfs snapshot над каждым объектом по отдельности: каждый подкомпонент получает собственную мгно- венную копию. Все мгновенные копии имеют одинаковые имена, но с логической точки зрения они отличаются друг от друга. Мгновенные копии в системе ZFS предназначены только для чтения, и хотя они имеют определенные свойства, все же не являются файловыми системами в подлинном смысле. Однако вы можете инициировать мгновенную копию как полноценную и до- пускающую запись файловую систему, “клонировав” ее. Solaris$ sudo zfs clone demo/new_fs@snapl demo/subclone solaris$ Is /opt/demo/subclone now_you_see_me Solaris $ sudo touch /opt/demo/subclone/and_me_too solaris$ Is /opt/demo/subclone and_me_too now_you_see_me Мгновенная копия, которая стала оригиналом для клона, остается нетронутой и предназначается только для чтения. Однако новая файловая система (в нашем примере, demo/subclone) сохраняет связь как с мгновенной копией, так и с файловой системой, на которой она основана, и ни одну из них нельзя удалить, пока существует клон. Операция клонирования применяется относительно редко, но это единственный спо- соб создать новую ветвь на дереве эволюции файловой системы. Операция zfs rollback, продемонстрированная выше, может только восстановить файловую систему в состоя- нии, соответствующем самой последней по времени мгновенной копии, поэтому при ее использовании вы будете вынуждены постоянно удалять (zfs destroy) все мгновенные копии, сделанные за время, прошедшее после создания мгновенной копии, к которой хотите вернуться. Клонирование позволяет вам вернуться в прошлое без потери измене- ний, внесенных недавно. Предположим, вы обнаружили дыру в системе безопасности, возникшую в течение прошедшей недели. Для обеспечения безопасности вы захотите вернуть файловую систе- му в состояние, в котором она находилась неделю назад, чтобы быть уверенным, что она не содержит лазеек, оставленных хакерами. В то же время вы не хотите потерять резуль- таты работы за последнюю неделю или данные для аналитического отчета. Решением этой проблемы является клонирование мгновенной копии, сделанной неделю назад, в виде новой файловой системы, применение команды zfs rename к старой файловой системе и команды zfs rename — к клону, заменяющему исходную файловую систему. Полезно также применить к клону команду zfs promote; эта операция инвертирует отношения между клоном и оригиналом файловой системы. После активации основная файловая система имеет доступ ко всем старым мгновенным копиям файловой системы, а старая файловая система становится “клонированным” ответвлением.
318 Часть I. Основы администрирования Неразмеченные логические тома Области подкачки и неразмеченные области для хранения создаются с помощью ко- манды zfs create, точно так же как создаются файловые системы. Аргумент -V раз- мер заставляет команду zfs обрабатывать новый объект как неразмеченный логический том, а не файловую систему. Параметр размер может использовать общую единицу из- мерения, например 128m. Поскольку том не содержит файловую систему, он не монтируется; вместо этого он демонстрируется в каталогах /dev/zvol/dsk и /dev/zvol/rdsk, и ссылаться на него можно так, будто он представляет собой жесткий диск или раздел. Система ZFS отражает иерархическую структуру пула хранения в этих каталогах, поэтому команда sudo zfc create -V 128m demo/swap создает том подкачки размером 128 Мбайт, раз- мещенный в каталоге /dev/zvol/dsk/demo/swap. Мгновенные копии неразмеченных томов можно создавать точно так же, как мгно- венные копии файловых систем, но поскольку в данном случае нет иерархии файловой системы, в которой размещается каталог . zf s/snapshot, мгновенные копии оказыва- ются в том же самом каталоге, что их исходные тома. Клоны функционируют точно так, как ожидается. По умолчанию неразмеченные тома получают резерв дисковой памяти, равный его указанному объему. Можно уменьшить резерв или отказаться от него вообще, но в этом случае попытки записи на том могут вызвать ошибку “out of space”. Клиенты неразме- ченных томов могут не справиться с такими ошибками. Распределение файловой системы между NFS, CIFS и SCSI Система ZFS не только переопределяет много аспектов управления традиционны- ми файловыми системами, но и изменяет способ распределения файловой системы по сети. В частности, можно задать свойство sharenfs или sharesmb файловой системы равным on и сделать ее доступной с помощью протокола NFS или встроенного сервера CIFS операционной системы Solaris. Более подробно протокол NFS описан в главе 18, а сервер CIFS — в разделе 30.6. Если оставить эти свойства равными off, то это не значит, что файловая система не станет общедоступной; просто пользователю придется использовать специальные ин- струменты для экспорта, например утилиты sharemgr, share и unshare, а не функцио- нальные возможности системы ZFS. Свойства sharenf s и sharesmb могут принимать не только значения on и off. Если задать другое значение, то это будет означать, что вы хотите обеспечить совместное использование файловой системы, и это значение будет передаваться с помощью команды zfs share в виде аргументов командной строки. Аналогично свойство shareiscsi=on, примененное, к неразмеченному тому, делает его доступным в рамках протокола iSCSI. Более подробно о протоколе рассказывается в разделе 8.10. По умолчанию все свойства share* являются наследуемыми. Если вы делаете фай- ловую систему /home совместно используемой в рамках протокола NFS, например, то автоматически становятся доступными все рабочие каталоги, расположенные в ней, даже если они были определены как самостоятельные файловые системы. Разумеется, это поведение можно отменить, задав явно параметр sharenf s=no для каждой вложен- ной файловой системы. Для доступа к спискам управления доступом система ZFS использует стандарт NFSv4. Нюансы этого стандарта обсуждаются в главе 6. Подводя итог, скажем лишь, что
Глава 8. Дисковая память 319 система ZFS обеспечивает прекрасную поддержку списков управления доступом для клиентов как системы Windows, так и протокола NFS. Управление пулом хранения Рассмотрев свойства системы ZFS, относящиеся к файловой системе и уровню “блок-клиент”, исследуем ее пулы хранения. До сих пор мы использовали пул с именем “demo”, который создали на отдельном диске. Команда zpool list выводит на печать следующие результаты. solaris$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT demo 496G 240K 496G 0% ONLINE rpool 748G 23.78G 724G 3% ONLINE Пул с именем rpool содержит загружаемую корневую файловую систему. На загру- жаемые пулы в настоящее время наложено несколько ограничений: они могут содержать только одно виртуальное устройство, и это устройство должно быть либо зеркальным массивом, либо отдельным диском; оно не может быть массивом RAID. Если устрой- ство является диском, то оно не может иметь таблицы разделов GPT. Команда zpool status добавляет несколько деталей о виртуальных устройствах, из которых состоит пул хранения, и сообщает об их текущем состоянии. solaris$ zpool status demo pool: demo state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM demo ONLINE 0 0 0 c8dl ONLINE 00 0 Оставим пул dw «создадим нечто более сложное. Мы присоединили к нашей системе пять накопителей SCSI емкостью 500 Гбайт. Сначала создадим пул с именем “топзСе^^оопержащий три из этих накопителя, в кон- фигурации RAID-Z с одним разрядом контроля четности (single-parity configuration). solaris$ sudo zpool destroy demo solaris$ sudo zpool create monster raidzl c9t0d0 c9tld0 c9t2d0 solaris$ zfs list monster NAME USED AVAIL REFER MOUNTPOINT monster 91.2K 981G 25.3K /monster Система ZFS также распознает схемы raidz2 и raidz3 для конфигурации с двумя и тремя разрядами контроля четности. Минимальное количество дисков всегда на едини- цу больше, чем количество устройств контроля четности. В данном случае один из трех накопителей предназначен для контроля четности, поэтому для файловой системы до- ступен примерно один терабайт памяти. Для иллюстрации добавим оставшиеся два накопителя, сконфигурированных как зеркало. Solaris$ sudo zpool add monster mirror c9t3d0 c9t4d0 invalid vdev specification use ’-f’ to override the following errors: mismatched replication level: pool uses raidz and new vdev is mirror solaris$ sudo zpool add -f monster mirror c9t3d0 c9t4d0
320 Часть I. Основы администрирования Команда zpool сначала “спотыкается” на этой конфигурации, потому что эти два виртуальных устройства имеют разные схемы избыточности. Данная конфигурация ра- ботает хорошо, поскольку оба виртуальных устройства обладают определенной избыточ- ностью. В реальных условиях не следует смешивать виртуальные устройства, обладаю- щие и не обладающие избыточностью, поскольку невозможно предсказать, какие блоки на каких устройствах будут находиться; частичная избыточность здесь бесполезна. solaris$ zpool status monster pool: monster state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM monster ONLINE 0 0 0 raidzl ONLINE 0 0 0 c9t0d0 ONLINE 0 0 0 c9tld0 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 mirror ONLINE 000 c9t3d0 ONLINE 000 c9t4d0 ONLINE 000 Система ZFS распределяет записи между всеми виртуальными устройствами пула. Как показано в этом примере, если виртуальные устройства имеют одинаковые объемы, это не обязательно.24 Однако компоненты внутри избыточной группы должны иметь одинаковые размеры. Если это условие не выполняется, то каждый компонент будет иметь минимальный размер. При использовании нескольких простых дисков в пуле хра- нения важную роль играет конфигурация RAID 0. Дополнительные виртуальные устройства можно добавить в пул в любое время. Однако существующие данные не будут перераспределены, чтобы не потерять преиму- щества параллелизма. К сожалению, в настоящее время невозможно добавлять допол- нительные устройства в существующий массив RAID или зеркало. Система ZFS имеет особенно хорошую реализацию кеширования чтения, которое обеспечивает эффективное использование накопителей SSD. Для того чтобы установить эту конфигурацию, достаточно просто добавить накопители SSDs в пул хранения как виртуальные устройства типа cache. Система кеширования использует алгоритм адап- тивной замены, разработанный компанией IBM, который эффективнее обычного алго- ритма кеширования LRU (least recently used — наиболее давно использовавшийся). Ей известна частота обращения к блокам и момент времени, когда они использовались в последний раз, поэтому чтение больших файлов не предполагает разрушения кеша. Горячее резервирование реализуется с помощью виртуальных устройств типа spare. Один и тот же диск можно добавлять в несколько пулов хранения; диск из пула, кото- рый первый даст сбой, объявляется резервным. 8.11. Сеть хранения данных Существует несколько способов присоединить ресурсы хранения к сети. В главе 18 описывается традиционный протокол NFS для системы UNIX, применяемый для со- 24 В данном примере диски имеют одинаковые объемы, а виртуальные устройства нет (1 Тбайт против 500 Гбайт).
Глава 8. Дисковая память 321 вместного использования файлов. Система Windows имеет аналогичный протокол, из- вестный как CIFS или SMB. Основной реализацией протокола CIFS для систем UNIX и Linux является протокол Samba; подробно описан в разделе 30.6. Протоколы NFS и CIFS — примеры систем для “сетевого хранилища” (NAS). Они относятся к высокоуровневым протоколам, а их основные операции сводятся к таким действиям, как “открыть файл X и послать мне первые 4 двоичных килобайта данных” или “настроить список управления доступом для файла Y, как указано в запросе”. Эти протоколы хорошо работают в файловых системах, где многие клиенты хотят читать или записывать одновременно. Сеть хранения данных (SAN) — это низкоуровневая система для абстрагированйя операций хранения, при котором сетевое хранилище напоминает локальный жесткий диск. Операции SAN состоят, в основном, из инструкций чтения или записи конкретных дисковых “блоков” (хотя, разумеется, адресация этих блоков сервером определенным образом делается виртуальной). Если клиент хочет использовать сеть SAN для хранения файловой системы, он должен обеспечить собственную реализацию файловой системы* С другой стороны, тома SAN также можно использовать для хранения областей подюН* ки или других данных, не обязательно имеющих структуру файловой системы. За исключением файловой системы VxFS в операционной системе HP, основные файловые системы не предназначены для работы с многочисленными клиентами, не знающими о существовании друг друга (по крайней мере, не на уровне неразмеченных блоков диска).25 Следовательно, хранилище SAN обычно не рассматривают как способ совместного использования файлов. На самом деле оно представляет собой средство для замены локальных жестких дисков централизованными ресурсами хранения. Зачем это нужно? Перечислим несколько причин. • Каждый клиент имеет возможность получить преимущество благодаря использо- ванию сложного хранилища, оптимизированного по производительности, устой- чивого к сбоям и допускающего восстановление данных. • Повышается эффективность использования, поскольку каждый клиент имеет именно столько места для хранения, сколько ему требуется. Несмотря на то что объем памяти на виртуальных дисках фиксирован, он не ограничен стандартными размерами физических жестких дисков. Кроме того, блоки виртуальных дисков, которые клиент никогда не записывал, на самом деле на сервере не хранятся. • В то же время система SAN обеспечивает большую гибкость и простоту перекон- фигурации. “Модернизацию жесткого диска” теперь можно выполнить с помо- щью одной-двух команд, посланных из терминального окна администратора. • Методы обнаружения дублированных блоков могут снизить стоимость хранения одинаковых файлов на нескольких компьютерах. • Стратегия резервного копирования для предприятия может быть унифицирована посредством точного копирования резервных блоков на сервере SAN. В некото- рых ситуациях каждый клиент получает доступ к расширенным возможностям 25 Хотелось бы высказать свою точку зрения. На самом деле существует много таких файловых систем, которые называются кластерными (или кластеризованными). Для обеспечения кластери- зации необходимо применять специальные алгоритмы блокировки и синхронизации, поэтому кла- стеризованные системы, как правило, работают медленнее, чем стандартные файловые системы на локальных дисках. Файловая система VxFS может работать в кластеризованном и некластеризо- ванном режимах, поэтому она подходит для любых ситуаций.
322 Часть I. Основы администрирования мгновенного копирования, характерным для менеджеров логических томов, неза- висимо от операционной системы или используемой файловой системы. Производительность всегда интересует системных администраторов, но, не зная кон- кретной реализации, трудно делать общие выводы о влиянии сетей SAN на произво- дительность ввода-вывода на сервере. Сети порождают скрытые затраты и ограничения пропускной способности, которых нет у локальных дисков. Даже при наличии сложного коммутирующего оборудования, сети представляют собой лишь наполовину совместно используемые ресурсы, которые зависят от пропускной способности линий связи между клиентами. К преимуществам сетей SAN следует отнести тот факт, что крупные серве- ры SAN могут быть объединены в группы с памятью и кешами SSD. Они используют первоклассные компоненты и разделяют физический ввод-вывод между многими дис- ками. В общем, правильно реализованная сеть SAN работает значительно быстрее, чем локальное хранилище. Однако все это обходится недешево. Такое аппаратное обеспечение относится к ка- тегории специализированного промышленного оборудования, поэтому вы сразу можете забыть о цене 80 долл, за диск из магазина электроники. Основными игроками на рынке SAN являются компании EMC, NetApp, HP, IBM и, как ни странно, Dell. Сети SAN Поскольку основным фактором, влияющим на производительность сетевого хране- ния, является сеть, серьезные компании обычно закладывают в основу своей инфра- структуры оптоволоконные кабели. Типичная скорость передачи данных по таким кабелям колеблется от 4 до 8 Гбайт/с, в противоположность скорости передачи данных в проводных сетях Ethernet, в которых она составляет 1 Гбайт/с. Однако сети Ethernet представляют собой быстро растущий сегмент ранка. Этому есть несколько причин. Две главные причины заключаются в том, что появились недорогие варианты технологии Ethernet со скоростью 10 Гбайт/с и по- стоянно усиливается роль виртуальных серверов; системы виртуализации обычно лучше поддерживают технологию Ethernet, чем оптоволоконные кабели. Разумеется, свою роль играет то, что системы, основанные на технологии Ethernet, не требуют инсталляции до- рогой вспомогательной физической сетевой инфраструктуры. Функциональные возможности SAN на основе технологии Ethernet можно реализо- вать с помощью нескольких протоколов обмена данными. Общим свойством этих про- токолов является возможность эмуляции конкретного аппаратного интерфейса, кото- рый многие системы уже понимают. Основным протоколом является iSCSI, представляющий системе виртуальный нако- питель так, будто он присоединен к локальной шине SCSI. Кроме него, используются протоколы ATA-over-Ethernet (АоЕ) и Fibre-Channel-over-Ethemet (FCoE). Эти протоко- лы ориентированы на технологию Ethernet (а значит, ограничены географическими фак- торами), в то время как протокол iSCSI работает на основе протокола IP. В настоящее время протокол iSCSI занимает около 20% рынка SAN, настоящие технологии оптово- локонной связи — около 60%, а остальные решения — оставшиеся 20%. Детали реализации оптоволоконной инфраструктуры выходят за пределы нашей книги, поэтому мы рассмотрим подробно только протокол iSCSI. С точки зрения опера- ционной системы компьютера, оптоволоконные накопители SAN обычно выглядят как ряд дисков SCSI, которыми можно соответственно управлять.
Глава 8. Дисковая память 323 Протокол iSCSI: интерфейс SCSI на основе протокола IP Протокол iSCSI позволяет реализовать сетевое хранение на основе существующего недорогого сетевого аппаратного обеспечения, не используя специальную оптоволокон- ную сеть и дорогие адаптеры оптоволоконных шин. Серверы SAN в этом случае станут узкоспециализированными системами, но при этом появится возможность воспользо- ваться преимуществами общедоступного аппаратного обеспечения. Используя традиционную терминологию накопителей SCSI, можно сказать, что про- токол iSCSI ссылается на сервер, который создает виртуальные диски, доступные через сеть в качестве “цели” iSCSI. Клиент, монтирующий эти диски, называется “инициа- тором”. Это важно, если вспомнить, что именно клиент инициирует команды SCSI, а сервер отвечает на них. Компоненты программного обеспечения, реализующего цель, и инициатор, рас- положенные на обоих концах связи iSCSI, отделены друг от друга. Все современные операционные системы содержат в себе инициатор, хотя часто он представляет собой необязательный компонент. Кроме того, большинство систем имеет также стандартную реализацию цели. Протокол iSCSI формально определен в документе RFC3720. В отличие от боль- шинства документов RFC, эта спецификация состоит из нескольких сотен страниц, в основном из-за сложности базового протокола SCSI. В большинстве случаев управление протоколом iSCSI является простым, если только для структурного управления и рас- познавания ресурсов хранения не используется необязательная служба Internet Storage Name Service (iSNS). Протокол iSNS, определенный в документе RFC4171, представляет собой адаптацию протоколов управления и раскрытия оптоволоконной связи для про- токола IP, поэтому он представляет интерес для организаций, желающих использовать и оптоволоконную инфрастуктуру, и протокол iSCSI. В отсутствие службы iSNS достаточно просто указать инициатору на соответствую- щий сервер, задать имя устройства iSCSI, к которому необходимо получить доступ, а также имя пользователя и пароль для аутентификации. По умолчанию аутентификация, iSCSI использует протокол Challenge Handshake Authentication Protocol (CHAP), который изначально предназначался для протокола Point-to-Point Protocol (PPP) (см. документ RFC 1994), так что пароли через сеть не передаются открытым текстом. При желании инициатор может аутентифицировать цель, используя второй распределенный ключ. Протокол iSCSI можно выполнять поверх протокола IPsec, хотя это и не требуется. Если вы не используете туннель IPsec, то блоки данных не шифруются. В соответствии с документом RFC3720, соединения, не использующие протокол IPsec, должны использо- вать ключи CHAP длиной не менее 12 символов. Цели и ициниаторы имеют имена iSCSI, причем для них определено несколько схем именования. Наиболее широко используются имена iSCSI Qualified Names (IQNs), име- ющие несколько странный формат. iqn.yyyy-mm.reversed_DNS_domain:arbitrary_name В большинстве ситуаций все, что предшествует двоеточию, является фиксированным (т.е. нерелевантным) префиксом, характеризующим сайт. Вы можете реализовать соб- ственную схему именования для фрагмента абстрактное_имя имени IQN. Месяц и год (шт и уууу), уточняющие домен DNS, указываются для того, чтобы обеспечить защиту от возможного изменения домена. Для этого следует использовать оригинальную дату регистрации DNS. Реальное имя выглядит следующим образом. iqn.1995-08.com.example:disk54.db.engr
324 Часть I. Основы администрирования Несмотря на специфичный формат имени IQN, префикс, отражающий реальный до- мен DNS или дату его возникновения, никакой роли не играет. В большинстве реализа- ций протокола iSCSI по умолчанию в качестве имени IQN используется имя поставщи- ка, и все работает прекрасно. Не требуется даже, чтобы имена IQN, взаимодействующие друг с другом, имели совпадающие префиксы. Загрузка с тома iSCSI Если вы собираетесь размещать в сетевом хранилище SAN важные данные, то не было бы разумным вообще отказаться от использования локальных жестких дисков? Вы можете не только отказаться от специальных процедур, необходимых для управления локальными дисками, но и позволить администраторам “заменять” загрузочные нако- пители простыми незагрузочными накопителями, осуществлять постоянную модерни- зацию и обеспечивать альтернативные конфигурации загрузки, включая даже системы Windows. К сожалению, использование тома iSCSI в качестве загрузочного накопителя не по- лучило широкой поддержки. По крайней мере, эта функциональная возможность не реализуется непосредственно и не стала одной из основных. Разные проекты Linux пы- тались ее реализовать, но все эти реализации были жестко привязаны к конкретному аппаратному обеспечению и конкретному программному обеспечению для инициато- ра протокола iSCSI, так что ни один из проектов загрузки протокола iSCSI не взаимо- действует с доминирующим в настоящее время программным обеспечением OpeniSCSI для инициатора. Аналогично поддержка загрузки протокола iSCSI в системах Solaris и OpenSolaris пока находится на стадии разработки, но окончательного промышленного решения пока нет. Единственным исключением является система AIX, которая уже давно и хорошо поддерживает протокол iSCSI. Версии AIX 5.3 и более поздние, работающие на аппарат- ном обеспечении POWER, обеспечивают полную поддержку загрузки протокола iSCSI поверх протокола IPv4. Специфика инициаторов iSCSI от разных производителей ДБыло, по крайней мере, четыре реализации инициатора протокола iSCSI для системы Linux. Некоторые из них сошли с арены, а остальные объединились. Единственным выжившим в конкурентной борьбе стал протокол Open-iSCSI, который является стандартным инициатором, включенным во все дистрибу- тивы рассмотренных нами операционных систем семейства Linux distributions. Для того чтобы его установить и запустить, инсталлируйте пакет open-scsi в системах Ubuntu и SUSE или пакет iscsi-initiator-utils в системе Red Hat. Домашняя страница проекта расположена по адресу open-iscsi. org, но документа- цию там искать не следует. Похоже, что, кроме справочных страниц для команд iscsid и iscsiadm, представляющих собой описание реализации и интерфейса системы, ни- какой документации больше нет. К сожалению, административная модель для системы Open-iSCSI лучше всего описывается словом “креативная”. В системе Open-iSCSI “узел” — это цель протокола iSCSI, т.е. сущность с именем IQN. Система Open-iSCSI ведет базу данных, содержащую информацию об известных ей узлах, которые расположены в иерархии ниже каталога /etc/iscsi/nodes. В этом дереве хранятся параметры конфигурации для отдельных узлов. Значения по умолча-
Глава 8. Дисковая память 325 нию задаются в файле etc/iscsi/iscsid.conf, но иногда они копируются во вновь определенные узлы, так что их функционирование нельзя назвать полностью предска- зуемым. Процесс установки параметров целей очень неприятен; команда iscsiadm по- стоянно вынуждает вас изменять по одному параметру за один раз и задавать имя IQN и сервер в каждой командной строке. Ситуацию спасает лишь то, что файл iscsid. conf и все файлы базы данных явля- ются обычными редактируемыми текстовыми файлами. Следовательно, целесообразно использовать команду iscsiadm для модификации немногочисленных параметров и из- бегать ее при внесении многочисленных изменений. Для того чтобы настроить систему на выполнение простой статической операции с одним именем пользователя и паролем для всех целей iSCSI, сначала необходимо от- редактировать файл iscsid. conf и убедиться, что следующие строки набраны так, как показано ниже. node.startup = automatic node.session.auth.authmethod = CHAP node.session.auth.username = chap_name node.session.auth.password = chap_password Мы привели эти строки вместе, но на самом деле в файле они расположены в раз- ных местах. Этот файл содержит много комментариев и много опций конфигурации. Убедитесь, что они не дублируют друг друга. Затем сориентируйте команду iscsiadm на целевой сервер и предоставьте ей воз- можность создать записи для каждой цели, распознанной при чтении каталога сервера. В данном примере мы сконфигурировали цель с именем test на основе сервера с име- нем iserver. ubuntu $ sudo iscsiadm -m discovery -t st -p iserver 192.168.0.75:3260,1 iqn.1994-11.com.admin:test Для каждой цели команда iscsiadm создает подкаталог в каталоге /etc/iscsi/ nodes. Если существуют цели, с которыми вы не хотите работать, то просто примените к их каталогам конфигурации команду rm -rf. Если сервер предлагает много целей, а вас итересует только одна, то воспользуйтесь следующими командами. ubuntu $ sudo iscsiadm -m node -о new -p iserver -T iqn.1994-11.com.admin:test New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default] iserver,3260,-1 iqn.1994-11.com.admin:test] added Как ни странно, эти два метода дают одинаковые результаты, создавая при этом раз- ные иерархии каталогов внутри каталога /etc/iscsi/nodes. Какую бы версию вы ни применили, проверьте текстовые файлы, существующие в иерархии, чтобы убедиться в правильности их параметров конфигурации. Если вы зашли в цель самостоятельно, возможно, вам придется самому задать свой- ство node. startup равным automatic. Затем вы можете соединиться с удаленными целями с помощью команды iscsiadm *m node -1. ubuntu$ sudo iscsiadm -m node -1 Logging in to [iface: default, target: iqn.1994-11.com.admin:test, portal: 192.168.0.75,3260] Login to [iface: default, target: iqn.1994-11.com.admin:test, portal: 192.168.0.75,3260]: successful
326 Часть I. Основы администрирования Для того чтобы проверить, видит ли система дополнительный диск, можно выпол- нить команду fdisk -1. (Файлы устройств для дисков iSCSI disks называются точно так же, как и любые другие диски named SCSI.) Если вы настроили файлы конфигурации так, как указано выше, то соединения будут автоматически восстановлены во время за- грузки. Для целевой службы iSCSI в системах семейства Linux предпочтительной реали- зацией является пакет iSCSI Enterprise Target, размещенный по адресу iscsitarget. sourceforge. net. Обычно он доступен для загрузки под именем iscsitarget. Система Solaris содержит пакеты цели и инициатора; оба они являются необя- soians зательными. Все пакеты, связанные с протоколом iSCSI, в своих именах со- держат слово “iscsi”. Находясь на стороне инициатора, инсталлируйте пакет SUNWiscsi, а затем выполните перезагрузку системы. Конфигурационного файла для этого пакета не существует; вся конфигурация соз- дается командой iscsiadm, имеющей довольно странный синтаксис. Четыре главные операции (add, modify, list и remove) можно применить к разнообразным аспектам конфигурации инициатора. Основная конфигурация инициатора и соединение с целе- вым сервером iserver осуществляются с помощью следующих строк. solaris$ sudo iscsiadm modify initiator-node -a CHAP -H testclient solaris$ sudo iscsiadm modify initiator-node -C Enter secret: <password for testclient> Re-enter secret: <password for testclient> solaris$ sudo iscsiadm modify discovery -s enable solaris$ sudo iscsiadm add static-config iqn. 1994-11.com.admin: test,iserver Solaris$ sudo iscsiadm list target -S Target: iqn.1994-11.com.admin:test Alias: - TPGT: 1 ISID: 4000002a0000 Connections: 1 LUN: 0 Vendor: IET Product: VIRTUAL-DISK OS Device Name: /dev/rdsk/cl0t3d0s2 Теперь можно задать конфигурацию диска обычным способом (например, выполнив команду zpool create iscsi cl0t3d0). Первая команда задает для инициатора режим аутентификации CHAP, а имя пользо- вателя задает равным testclient. Опция -С задает пароль; эту опцию нельзя комбини- ровать с другими. Кроме того, при желании можно задавать имя и пароль индивидуаль- но для каждой цели. Команда modify discovery позволяет использовать статически сконфигурирован- ные цели, а команда add задает сервер и имя конкретной цели. Все эти конфигурации сохраняются во время перезагрузок. Для обслуживания целей iSCSI в других системах необходимо инсталлировать пакет SUNWiscsitgt. Его механизм управления на стороне инициатора структурирован так же, но команда имеет имя iscsitadm, а не iscsiadm. ТКЯ Для использования протокола iSCSI в системах семейства HP-UX, необхо- димо загрузить программное обеспечение для инициатора протокола iSCSI с сайта software. hp. com и инсталлировать с помощью инструмента Software
Глава 8. Дисковая память 327 Distributor. При этом требуется перестройка и перезагрузка ядра. К счастью, система является хорошо документированной и сопровождается справочным руководством HP-UX iSCSI Software Initiator Support Guide, которое можно за- грузить с сайта docs. hp. com. В большинстве случаев конфигурацию инициатора можно задать с помощью коман- ды iscsiutil, инсталлированной в каталоге /opt/iscsi/bin. Для задания имени IQN инициатора применяется команда iscsiutil -1 UMxiqn, для задания глобального пользовательского имени для алгоритма аутентификации CHAP используется комаэда iscsiutil -u -N пользователь (ее также можно применять к отдельным серверам или отдельным целям), а для задания глобального пароля для алгоритма аутентификации CHAP — команда iscsiutil -u -И пароль. Затем можно добавить цели на конкретном сервере с помощью команды iscsiutil -а -I сервер. Для того чтобы активировать серверное соединение и создать виртуаль- ный дисковый накопитель, следует выполнить команду ioscan -NH 64000. Состояние системы проверяется с помощью команды iscsiutil -р -о. е Инициатор протокола iSCSI в системе AIX уже инсталлирован и готов к ис- пользованию. В типичном для системы AIX стиле большинство конфигура- ций реализуется с помощью системных баз данных ODM. Устройство iscsiO представляет конфигурацию инициатора в целом, а индивидуальные целевые устройства можно определить с помощью записей ODM или в текстовых фай- лах конфигурации в каталоге /etc/iscsi. Текстовые файлы конфигурации, на первый взгляд, более надежны. Система AIX не различает имя IQN инициатора и его пользовательское имя CHAP. Имя IQN задается на устройстве iscsiO, следовательно, на каждом сервере необходимо использовать одно и то же пользовательское имя CHAP. Для того чтобы получить воз- можность быстро изменять конфигурацию, сначала необходимо присвоить имени IQN соответствующее значение. aix$ sudo chdev -1 iscsiO -a initiat©r_name='iqn. 1994-11 .com. admin: client’ В данном примере мы использовали пользовательское имя CHAP, которое отлича- лось от своих аналогов в других системах, поскольку “testclient”, с формальной точки зрения, не является корректным именем IQN для инициатора (хотя на самом деле оно также прекрасно подходит). В файл /etc/iscsi/targets добавим следующую запись. iserver 3260 iqn.1994-11.com.admin:test "пароль-chap" Параметр 3260 — это Стандартный порт сервера для протокола iSCSI; мы вклю- чили его только потому, что этот порт предусмотрен форматом файла. Для того что- бы активировать новый диск iSCSI, необходимо всего лишь выполнить команду cfgmgr -1 iscsiO. Команда cfgmgr не выводит никаких подтверждений, но убедиться в том, что новое устройство появилось, можно, просмотрев каталог /dev (в нашем при- мере новый диск имеет имя /dev/hdisk2) или выполнив команду smitty devices, перейдя в категорию Fixed Disk и просмотрев элементы списка. Вероятно, второй вари- ант более безопасный, поскольку команда smitty явно демонстрирует, что диск hdisk2 является томом iSCSI. Для того чтобы отсоединить устройство iSCSI, необходимо не только отредактиро- вать файл конфигурации и перезагрузить его с помощью команды cfgmgr, но и удалить диск из списка Fixed Disk команды smitty.
328 Часть I. Основы администрирования 8.12. Упражнения 8.1. Укажите, на что должен обратить особое внимание системный администратор при разработке архитектуры хранилища для каждого приложения. а) сервер, на котором будут храниться рабочие каталоги около 200 пользователей б) область подкачки для основного DNS сервера организации в) хранилище для большого потока спама г) крупная база данных InnoDB (MySQL) 8.2. Менеджеры логических томов — мощные механизмы, но их иногда трудно по- нять. Поэкспериментируйте с добавлением, удалением дисков, входящих в груп- пу томов, и изменением их размеров. Покажите, как удалить устройство из одной группы томов и доьбавить его в другой. Что делать, если необходимо переместить логический том из одной группы томов в другую? 8.3. ★Используя информацию, опубликованную в Интернете, укажите накопители SCSI и SATA с наивысшей производительностью. Учитывают ли тестовые про- граммы, используемые для оценки этих накопителей, что они могут применяться в качестве загрузочного диска на занятом сервере? Какие дополнительные расходы вы готовы нести, чтобы приобрести накопители SCSI, и какой прирост произво- дительности вы хотите получить за эти деньги? 8.4. ★ Добавьте в вашу систему диск и настройте раздел или логический том на но- вом диске как резервный корневой раздел. Убедитесь, что вы можете запустить- ся с резервного корневого раздела и что система после этого работает нормально. Проследите по журналу все действия, которые необходимо выполнить, чтобы ре- шить поставленную задачу. Возможно, вам поможет команда script. (Она требует прав суперпользователя.) 8.5. ★ Что такое суперблок и для чего он нужен? Посмотрите на определение струк- туры суперблока в системе ext4 в заголовочных файлах ядра и обсудите, что пред- ставляют собой поля в этой структуре. 8.6. ★★ Используя команду mdadm и ее опцию -f, смоделируйте сбойный диск в мас- сиве RAID в системе Linux. Удалите этот диск из массива и добавьте обратно. Как выглядит диск /ргос/mdstat на каждом из этих этапов? 8.7. ★★ Какие поля хранятся в индексном дескрипторе на файловой системе ext4? Перечислите содержимое индексного дескриптора, которое хранится в файле / etc/motd. Где хранится имя этого файла? (Вам могут, помочь команды hexdump и Is -i.) 8.8. ★★ Проверьте содержимое каждого файла каталога с помощью программ od или hexdump. Каждая запись переменной длины представляет собой файл в заданном каталоге. Просмотрите дисковую структуру каталога и объясните каждое поле, ис- пользуя в качестве примера реальный файл каталога. Затем загляните в каталог lost+found используемой вами файловой системы. Почему там так много имен, если каталог lost+found пуст? 8.9. ★★★★★ Напишите программу, которая отображает содержимое файлов /etc/ motd и /etc/magic. Но не обращайтесь к файлам напрямую: откройте файл устройства, соответствующий корневому разделу, и воспользуйтесь системны- ми вызовами seek и read для поиска нужных блоков данных. Файл /etc/motd
ша 8. Дисковая память 329 обычно невелик и содержит только “информационные” блоки. При работе с фай- лом /etc/magic, скорее всего, потребуется анализировать “ссылочные” блоки. (Если нет, выберите текстовый файл побольше.) Подсказка: Найдя в системных файлах заголовков описание структуры индексного дескриптора, убедитесь, что это дескриптор, хранящийся на диске, а не в ядре. (Необходим доступ с правами суперпользователя.)
Глава Периодические процессы Ключ к устойчивости и надежности систем лежит в автоматизации выполняемых в ней задач и успешном написании сценариев. Например, программа adduser может подключать новых пользователей быстрее, чем это сделает администратор вручную, причем с гораздо меньшей вероятностью ошибки. Практически любую задачу можно за- программировать в сценариях интерпретатора команд либо на языках Perl или Python. В некоторых случаях желательно, чтобы сценарий или команда выполнялись без вмешательства оператора. Можно, в частности, сделать так, чтобы сценарий проверял (скажем, каждые полчаса), как работают сетевые маршрутизаторы и мосты, и при обна- ружении проблем посылал администратору сообщение по электронной почте1. 9.1. Демон cron: системный планировщик Демон cron — это стандартный инструмент для периодического выполнения ко- манд. Он запускается на этапе начальной загрузки системы и выполняется до тех пор, пока система не будет выключена. Демон cron читает файлы конфигурации, содержащие списки командных строк и расписание их вызова. Командные строки обрабатываются интерпретатором sh, поэто- му почти все, что можно делать в данном интерпретаторе вручную, разрешается перепо- ручать демону cron2. Файл конфигурации демона cron называется crontab (сокращение от “cron table” — таблица демона cron). Пользовательские cron tab-файлы хранятся в каталоге /var /spool/cron. Для каждого пользователя создается не более одного такого файла: один 1 Многие организации идут еще дальше: в них сценарий отправляет текстовое сообщение на телефон администратора, уведомляя его о возникновении проблем. Подробнее читайте в главе 21. 2 Можно настроить демон cron на использование других интерпретаторов.
Глава 9. Периодические процессы 331 для суперпользователя (root), один для пользователя jsmith и т.д. В качестве имени файла выбирается регистрационное имя пользователя, которому он принадлежит, и на основании этого имени демон cron выясняет, какое значение UID нужно использовать при выполнении команд, содержащихся в файле. Команда crontab передает crontab- файлы в каталог /var/spool/cron и из него. Несмотря на различия в конкретных реализациях, все версии демона cron стремятся минимизировать время, затрачиваемое на синтаксический анализ файлов конфигурации и выполнение вычислений. Команда crontab помогает поддерживать эффективность работы демона cron, уведомляя его об изменениях crontab-файлов. Следовательно, вы не должны редактировать crontab-файлы сами, поскольку это может привести к тому, что демон cron не заметит ваших изменений. Если возникнет ситуация, когда cron, ка- залось бы, “не замечает” модификацию своих crontab-файлов, воспользуйтесь сигна- лом отбоя (HUP), который в большинстве систем заставляет его повторно прочитать их. Ш Подробнее о системе syslog написано в главе 11. Демон cron обычно выполняет свою работу “молча”, но в большинстве версий может вестись файл регистрации (как правило, это файл /var/cron/log или /var/ adm/cron/log), в котором отражаются все выполняемые команды и время их запуска (см. табл. 9.2). В одних системах при создании файла регистрации автоматически включается режим регистрации, а при удалении этого файла регистрация выключается. В других системах режим регистрации задается в файле конфигурации. Кроме того, демон cron может пользоваться услугами системы syslog. Файл регистрации быстро увеличивается в раз- мерах и редко приносит пользу; лучше не включать регистрацию вообще, если только вы не занимаетесь устранением какой-то конкретной проблемы. 9.2. Формат crontab-файлов Все crontab-файлы в системе имеют одинаковый формат. Комментарии начинают- ся со знака решетки в первой позиции строки. Каждая строка, не являющаяся коммен- тарием, содержит шесть полей и представляет одну команду. минута час день месяц день_недели команда Первые пять полей (минута, час, день, месяц и день_недели) содержат информа- цию о времени запуска команды. Они отделяются друг от друга пробелами, но в поле команда пробел выполняет свою обычную функцию разделителя аргументов. Описание этих полей приведено в табл. 9.1. Таблица 9.1. Спецификации времени в crontab-файле Поле Описание минута Минута часа от Одо 59 час Час дня от0до23 День День месяца от 1 до 31 месяц Месяц года от 1 до 12 Д^нь^недели День недели от 0 до 6 (0 = воскресенье) каждое поле времени может содержать следующее: • звездочку, которая обозначает любую цифру;
332 Часть I. Основы администрирования^ • целое число, трактуемое буквально; • два разделенных дефисом целых числа, задающих диапазон значений; • диапазон, за которым стоит косая черта и значение шага, например 1-10/2 (толь- ко для Linux); • целые числа или диапазоны, разделенные запятыми (искомое время соответствует любому из указанных значений). Например, строка 45 10 * * 1-5 означает “10 часов 45 минут, с понедельника по пятницу”. Совет: никогда не ставьте звездочку в первое поле, иначе команда будет выполняться каждую минуту. С полями денъ_недели и день сопряжена потенциальная двусмысленность, кото- рую необходимо учитывать. День можно рассматривать как день недели и число месяца. Если указаны оба поля, то искомому дню достаточно удовлетворять одному из этих тре- бований, чтобы пройти отбор. Например, спецификация 0,30 * 13 * 5 означает “каждые полчаса по пятницам и каждые полчаса тринадцатого числа месяца”, но не “каждые полчаса в пятницу, 13-го”. Поле команда содержит командную строку, выполняемую интерпретатором sh. Это может быть любая допустимая команда интерпретатора (брать ее в кавычки не нужно)» Считается, что поле команда продолжается до конца строки и может содержать пробе- лы и символы табуляции. Несмотря на то что интерпретатор sh включен в выполнение команды, он не дей- ствует как экземпляр интерпретатора, запускаемый при входе пользователя в систему (login shell), и поэтому не считывает содержимое файлов ~/ .profile или ~/ .bash_ profile. В результате переменные среды указанной команды могут быть установлены несколько не так, как вы ожидали. Если вам кажется, что команда, выполняемая из оболочки, работает прекрасно, но “глючит” при вводе в файл crontab, значит, по всей вероятности, виновата среда. При необходимости можно всегда “обернуть” команду в сценарий, который устанавливает соответствующие переменные среды. Знак процента (%) используется вместо символа новой строки в поле команда. В ре- альную команду включается только текст до первого знака процента, а остальные стро- ки передаются команде в качестве стандартного входного потока. Приведем несколько примеров допустимых команд crontab-файла. echo The time is now 'date' > /dev/console mail -s Reminder evi@anchor % Don't forget to write your chapters. cd /etc; /bin/mail -s "Password file" evi < passwd А теперь рассмотрим полные примеры записей. 30 2 * * 1 (cd /home/joe/project; make) Эта строка будет активизироваться в 2:30 по понедельникам. Она инициирует выпол- нение утилиты make в каталоге /home/joe/project. Такую запись можно использовать для запуска длительного процесса компиляции в то время, когда в системе не работа- ют другие пользователи. Вся выходная информация, выдаваемая командами crontab- файла, обычно посылается по электронной почте “владельцу” файла3. 3 Пользователю, от имени которого создан файл. Фактическим владельцем cron tab-файлов в общем случае является пользователь root.
глава 9. Периодические процессы 353 2Q 1 * * * find /tmp -atime +3 -type f -exec rm -f { } Эта строка будет активизироваться каждый день в 1:20. Соответствующая команда удаляет из каталога /tmp все файлы, к которым за последние 3 дня никто не обращался. 55 23 * * 0-3,6 /staff/trent/bin/checkservers Эта строка запускает сценарий checkservers в 23:55 каждый день, кроме четверга и пятницы. Демон cron не пытается компенсировать пропуск команд, время выполнения кото- рых прошло, пока система не работала. Однако демоны cron в системах Linux и HP-UX вполне адекватно реагируют на небольшие смещения времени, связанные с переходами на летнее время и обратно. Другие версии демона cron могут пропустить команды или выполнить их дважды, если эти команды были назначены как раз на переходный период (например, обычно между 1:00 и 3:00 в США)4. .л 9.3. Управление crontab-файлами Команда cron tab имя_ файла инсталлирует указанный cron tab-файл, заменяя его предыдущую версию, если таковая имеется. Команда crontab -е проверяет копию crontab-файла текущего пользователя, загружает ее в текстовый редактор (указанный в переменной среды EDITOR) для последующего изменения, а затем повторно записыва- ет файл в системный каталог. Команда cron tab -1 отображает содержимое crontab- файла, а команда crontab -г удаляет этот файл. Пользователю root разрешается задавать аргумент имя_пользователя, чтобы мож- но было просматривать или редактировать crontab-файлы других пользователей. На- пример, команда crontab -г j smith удаляет cron tab-файл, принадлежащий пользо- вателю jsmith, а команда crontab -е j smith редактирует этот файл. В системе Linux разрешается использование обоих аргументов имя_пользователя и имя_файла в одной команде, поэтому для устранения неоднозначности аргументу имя_пользователя дол- жен предшествовать флаг -и (например, cron tab -u j smith crontab. new). Будучи вызванными без аргументов, большинство версий команды crontab будут пытаться прочитать crontab-файл из своего стандартного входного потока. Если этот режим был активизирован случайно, не пытайтесь выйти из него, нажимая комбина- цию клавиш <Ctrl+D>, так как весь crontab-файл будет удален. Необходимо нажать <Ctrl+C>. В Linux для того, чтобы команда crontab обратилась к своему стандартно- му входному потоку, в качестве аргумента имя_ файла ей необходимо передать дефис. Коротко и ясно! Два файла конфигурации cron. deny и cron. allow содержат информацию о том, кому из пользователей разрешено предоставлять crontab-файлы. В разных системах эти файлы расположены в разных каталогах (см. табл. 9.2). Если файл cron. allow существует, то он содержит список пользователей, имеющих доступ к демону cron (по одному имени в строке). Пользователи, которые в списке от- сутствуют, не имеют права выполнять команду cron tab. Если файла cron. allow нет, ли из наших помощников зафиксировал случай, когда демон cron потреблял 100% време- час^еН^)аЛЬН0Г0 пРоцессоРа’ поскольку системная дата была установлена неправильно. Локальный местн°И Пояс имел отрицательное смещение относительно всемирного времени (GMT), поэтому “сбит°е BpeNJ? после вычисления давало отрицательную величину, и, как следствие, cron был ЧовкаС Т0лку”* В большинстве систем “бортовые” часы оснащены батарейками, поэтому переуста- зедя часов ~ не такое уж необычное явление, как могло бы показаться. Нестабильность показа- времени — распространенный симптом “севшей” или “садящейся” батарейки.
334 Часть I. Основы администрирования проверяется файл cron. deny. Он также содержит список пользователей, но с противо- положным назначением: доступ разрешен всем, кроме лиц, указанных в списке. Таблица 9.2. Файлы и каталоги демона cron в различных системах Система Каталог файлов allow и deny Журнальный файл Linux /etc Все пользователи Используется система syslog Solaris /etc/cron.d Все пользователи /var/cron/log HP-UX /usr/lib/cron Только root /var/adxn/cron/log AIX /var/adm/cron Все пользователи /var/adm/cron/log Если нет ни одного из этих файлов, то, значит, нет единого правила для всех: в од- них системах всем пользователям по умолчанию разрешается создавать crontab-файлы, а в других на это имеет право только пользователь root. На практике стартовый файл cron. allow или cron. deny часто включается в стандартную инсталляцию операцион- ной системы, поэтому вопрос о crontab-поведении без файлов конфигурации остается спорным. Среди наших примеров систем только в HP-UX по умолчанию блокирует- ся доступ к crontab-файлам для непривилегированных пользователей. Необходимо подчеркнуть, что права доступа регулируются командой crontab, а не демоном cron. Если пользователь найдет способ обходным путем поместить в системный каталог свой cron tab-файл, демон cron будет благополучно выполнять указанные в нем команды. Система Solaris в этом смысле ведет себя несколько по-другому. Ее демон sotans cron удостоверяется в том, что учетная запись пользователя не заблокирова- на значением *LK* в файле /etc/shadow. Если окажется, что проверяемая учетная запись все же заблокирована, демон cron не выполнит задания этого пользователя. Важно предотвратить выполнение заданий, подготовленных за- блокированными пользователями (причем не имеет значения, как они были заблокированы: случайно или намеренно). Если вы хотите, чтобы пользова- тель имел действующую учетную запись с точки зрения демона cron, но не действующий пароль, выполните команду passwd -N пользователь. 9.4. Использование версии демона Vixie-cron Версия демона cron, включенная в дистрибутивы Linux (в том числе и наши три при- мера), обычно именуется как ISC Cron или vixie-cron; последнее название обязано имени автора Пола Викси (Paul Vixie). Эта версия представляет собой осовремененный вариант, который предоставляет дополнительные функции при меньшей неразберихе. Основное отличие нового варианта состоит в том, что, в дополнение к поиску поль- зовательских cron tab-файлов, версия vixie-cron также подчиняется системным cron tab-записям, хранящимся в файле /etc/crontab и каталоге /etc/cron.d. Эти файлы имеют формат, который несколько отличается от формата пользовательских crontab-файлов тем, что они позволяют выполнение команд, выданных произвольным пользователем. Дополнительное поле имя_пользова теля стоит перед названием коман- ды. Поле имя_пользователя не представлено в обычных crontab-файлах, поскольку имя crontab-файла предоставляет ту же информацию (даже в системах Linux). Демон cron точно так же интерпретирует записи из файла /etc/crontab и каталога /etc/cron. d. В общем файл /etc/crontab предназначен для системных администра- торов, которые поддерживают его вручную, в то время как каталог /etc/cron.d играет
Глава 9. Периодические процессы 335 роль хранилища, куда пакеты программ могут инсталлировать любые crontab-файлы, которые им могут понадобиться. Файлы, хранимые в каталоге /etc/cron.d, называют- ся (согласно действующему соглашению) по именам пакетов, которые их инсталлируют, но демона cron не заботит исполнение этого соглашения. Временные диапазоны в crontab-файлах версии vixie-cron могут включать любое значение шага. Например, ряд 0, 3, 6, 9, 12, 15, 18 кратко можно записать в виде 0—18/3. Вы можете также использовать трехбуквенное мнемоническое обозначение для назва- ний месяцев и дней, но не в сочетании с диапазонами. Насколько нам известно, эта функция работает только с английскими названиями. В crontab-файле версии Vixie- cron можно задавать переменные среды и их значения. Подробнее см. тап-страницу для cron tab (5). Посредством системы syslog демон vixie-cron регистрирует свои действия, ис- пользуя уровень “cron”, при том, что большинство сообщений представлено на уровне “info”. Стандартные конфигурации системы syslog отправляют cron-данные регистра- ционного характера в его собственный файл. По непонятным причинам демон cron в системе Red Hat был переименован в crond. Но это все тот же демон vixie-cron, который все мы знаем и любим. 9.5. Стандартные применения демона cron Существует ряд стандартных задач, решать которые удобнее всего с помощью де- мона cron. Соответственно, большинство записей crontab-файла пользователя root служит именно этим целям. В данном разделе рассмотрим подобные задачи и элементы crontab-файла, обеспечивающие их реализацию. Системы часто поставляются с готовыми crontab-файлами. Если необходимо от- ключить стандартные записи, превратите их в комментарии, вставив в начало каждой строки знак решетки (#). Не удаляйте сами записи, возможно, они еще пригодятся. Помимо файлов каталога /etc/cron.d, в дистрибутивах Linux есть также crontab- файлы, организующие запуск сценариев в ряде заранее известных каталогов. Это по- зволяет программам добавлять собственные периодические задания, не редактируя crontab-файлы. Например, сценарии, помещаемые в каталог /etc/cron. daily, запу- скаются раз в день, а сценарии каталога /etc/cron.weekly — раз в неделю. Вы можете также помещать файлы в эти каталоги вручную. Многие организации сталкиваются с незначительными, но повторяющимися сете- выми проблемами из-за того, что администраторы сконфигурировали демон cron для выполнения одной и той же команды на сотнях компьютеров в одно и то же время. Синхронизация часов всех компьютеров посредством протокола NTP еще больше усугу- бляет проблему. Эту проблему легко устранить с помощью сценария выполнения команд со случайной задержкой или путем настройки файла конфигурации, однако она может с трудом поддаваться диагностированию, поскольку ее признаки быстро полностью ис- чезают. Простые напоминания Не желая оставить Google Calendar без дела, демон cron тем не менее может вполне °казаться полезным для организации простых напоминаний: о днях рождения, ожидае- Мом времени (например, времени платежа), периодически повторяющихся задачах и пр.
336 Часть I. Основы администрирования Это особенно полезно в случае, когда процесс напоминания необходимо интегрировать с другими доморощенными программами. Следующая crontab-запись реализует простое почтовое напоминание. (Приведенные строки в действительности представляют собой одну длинную строку.) 30 4 25 * * /usr/bin/mail -s "Time to do the TPS reports" owen@atrust.com%TPS reports are due at the end of the month! Get busy!%%Sincerely,%cron Обратите внимание на то, что символ “%” используется как для отделения команды от входного текста, так и для обозначения конца строки в этом тексте. Эта запись одно- кратно отправляет электронную почту 25-го числа каждого месяца. Чистка файловой системы В любой системе есть ненужные файлы (естественно, речь идет не о системных файлах). Например, при аварийном завершении программы ядро создает файл (обыч- но он называется core, core.pid или prograт. core), содержащий образ адресного пространства программы. Такие файлы используются разработчиками программного обеспечения, но для администраторов это бесполезная трата дискового пространства. Пользователи часто вообще не знают о назначении core-файлов, поэтому предпочита- ют не брать на себя ответственность за их удаление5. Ш NFS рассматривается в главе 18. Еще один источник лишних файлов — это NFSv3 (Network File System — сетевая файловая система). Серверы NFSv3 сохраняют файлы, которые уничтожены в локаль- ной системе, но продолжают использоваться удаленным компьютером. В большинстве реализаций таким файлам присваиваются имена вида . nf sxxx, где ххх — числовой код. Иногда об этих файлах забывают и оставляют их на диске, думая, что они удалены. Многие программы создают в каталоге /tmp или /var/tmp временные файлы, кото- рые по той или иной причине не удаляются. Некоторые программы, особенно текстовые редакторы, делают резервные копии каждого файла, с которым они работают. Частичное решение проблемы файлового “мусора” состоит в регулярном (каждую ночь) восстановлении свободного дискового пространства. В современных системах обычно имеются встроенные средства подобной очистки, поэтому необходимо убедить^ ся в том, что они соответствуют потребностям организации. Во всех показанных ниже примерах для удаления ненужных файлов применяется ко- манда find. find I -xdev -type f ' (’ -name core -o name 'core. [0-9]*' -o name '*.core' ') ' -atime +7 -exec rm -f { } ';' Эта команда удаляет файлы с именем core, которые не использовались в течение не- дели. Аргумент -xdev гарантирует, что команда find будет выполнена только в преде- лах корневой файловой системы, что очень важно в сетях, где возможно монтирование множества файловых систем6. Если необходимо очистить несколько файловых систем, 5 Многие ядра систем можно сконфигурировать так, чтобы дампы памяти помещались в от- дельный каталог или вообще не генерировались. Загляните в руководство, используя в Linux ко- манду man core или в Solaris команду man coreadnt 6 Не все версии команды find поддерживают аргумент -xdev. В некоторых системах он на- зывается —х.
Глава 9. Периодические процессы 337 задайте для каждой из них свою команду (помните, что каталог /var часто является от- дельной файловой системой). Аргумент -type f имеет большое значение, поскольку исходный код ядра Linux со- держит каталог с именем core, удаление которого весьма нежелательно, не так ли? find / -xdev -atime +3 ’ (’ -name '#*’ -о -name ’ -о -name '*.СКР’ -о -name ' ’ -о -name ' .nfs* ’ ') ’ -exec rm -f { } '; ’ Эта команда удаляет неиспользуемые в течение трех дней файлы, имена которых на- чинаются с префикса #, .# или .nfs ^ибо заканчиваются расширением * или .СКР. Это типичные признаки временных и резервных файлов различных текстовых редакторов. CQ Подробнее об опциях команды mount написано в разделе 6.2. В целях повышения производительности некоторые администраторы используют опцию noatime команды mount, чтобы предотвратить хранение файловой системой временных меток момента обращения к файлам. Подобная конфигурация помешает ра- боте обеих приведенных выше команд find, поскольку файлы будут казаться такими, к каким не было обращений, даже если они недавно были активными. К сожалению, в случае ошибки команда удаляет файлы. Поэтому, прежде чем использовать приведенные команды, убедитесь, что система поддерживает временные метки доступа к файлам. cd /tmp; find . ! -name . ! -name lost+found -type d -mtime +3 -exec /bin/rm -rf { } ’; ’ Эта команда рекурсивно удаляет все подкаталоги каталога /tmp, не модифицируе- мые в течение трех дней. В большинстве систем обычные файлы в каталоге /tmp удаля- ются сценариями запуска системы, но в некоторых системах подкаталоги не удаляют- ся. Если существует каталог lost+found, то он не включается в число удаляемых. Это важно, если каталог /tmp является отдельной файловой системой. Подробнее о каталоге lost+found рассказывалось в разделе 8.9. Если в системе применяется одна из перечисленных выше команд, следует заранее уведомить пользователей о том, какими принципами руководствуется администратор при чистке файловой системы. Распространение конфигурационных файлов по сети Ш Подробнее о распространении конфигурационных файлов по сети рассказывается в гла- ве 19. При сетевом администрировании во многих случаях удобно пользоваться единой версией конфигурационных файлов, например базой почтовых псевдонимов. Обычно базовый механизм совместного использования ресурсов представляет собой некоторую форму опроса или периодического распространения ресурсов, что делает эту задачу иде- альной для демона cron. Основные версии этих файлов можно распространять по сети каждую ночь с помощью утилиты rsync, rdist. Иногда необходима последующая обработка файлов. Например, если в файле sendmail.cf не задана опция AutoRebuildAliases, может потребоваться, чтобы пользователь выполнял команду newaliases для преобразования текстового файла почтовых псевдонимов в хешированный формат, используемый программой sendmail. Может понадобиться и загрузка файлов в административную базу данных, например
338 Часть I. Основы администрирования Ротация журнальных файлов Системы по-разному относятся к управлению своими журнальными файлами по умолчанию, поэтому вам, возможно, стоит изменить стандартные установки в этой об- ласти, чтобы согласовать их с вашими локальными стратегиями. Под “ротацией” жур- нального файла понимают разделение его на сегменты по размеру и дате с сохранением при этом нескольких старых версий каждого журнального файла постоянно доступны- ми. Поскольку ротация представляет собой периодически повторяющееся событие, ко- торое можно выполнять по расписанию, такую процедуру лучше всего планировать с помощью демона cron. Подробнее о ротации рассказывается в главе 11. 9.6. Упражнения 9.1. Локальный пользователь системы стал злоупотреблять своим правом создания crontab-файлов, периодически запуская ресурсоемкие задания. Вы несколько раз безуспешно просили его прекратить это делать и теперь вынуждены лишить его соответствующих привилегий. Перечислите действия, которые необходимо пред- принять для того, чтобы удалить текущий crontab-файл пользователя и запретить ему впредь создавать такие файлы. 9.2. Придумайте три задания, которые требуется запускать регулярно (те, что были приведены в главе, не использовать). Составьте cron tab-записи для каждого за- дания и укажите, в какие файлы их необходимо поместить. 9.3. Найдите crontab-файлы в своей системе и выберите из них три записи. Опишите, когда активизируется каждая из них, что она делает и зачем, по вашему мнению, она нужна. (Необходим доступ с правами суперпользователя.) 9.4. ★ Напишите сценарий, который синхронизирует ваши конфигурационные фай- лы (*/. [a-z]*) между всеми компьютерами, на которых у вас есть учетная запись. Сделайте так, чтобы этот сценарий регулярно запускался демоном cron. (Можно ли просто копировать все файлы, имена которых начинаются с точки? Как вы по- ступите с каталогами? Нужно ли создавать резервные копии файлов, заменяемых на целевом компьютере, перед их перезаписью?)
Глава Резервное копирование В большинстве коммерческих организаций информация, хранящаяся в КОМПЬ^Р'_ ном виде, стоит дороже самих компьютеров. Кроме того, ее гораздо труднее вос^ вить. Защита этой информации является одной из наиболее важных (и, к сожалению, самых трудоемких) задач системного администратора. Потерять важную информацию можно как угодно. К порче файлов данных приводят ошибки в программном обеспечении. Пользователи случайно удаляют то, ^ем ботали всю жизнь. Хакеры и обозленные служащие стирают жесткие диски. Сбои в ап- паратных средствах и стихийные бедствия выводят из строя целые машинные зал, • Резервные копии позволяют администратору восстанавливать фа овую (или любую ее часть) в том состоянии, в каком она находилась на момент после копирования. Резервное копирование должно осуществляться тщательно и ст^ графику. Кроме того, устройства резервного копирования и сами носители должн лярно проверяться на предмет корректной работы. а1птиу не- регулярность выполнения процедур резервирования данных, о еспечив лостность резервных копий, является важным элементом корпоративной страз • Ответственные руководители должны четко понимать, какой цели служат а ных и как они должны эксплуатироваться. Для университетской компьютерно тории потерять результаты работы за один день не так страшно, как для торг пании, регулярно принимающей заказы от десятков или сотен клиентов. Начнем эту главу с описания общих принципов резервного копирования, п ознакомимся с наиболее распространенными устройствами создания резервных к° их носителями (их преимуществами, недостатками, ценами на них). Затем речь о планировании процедуры резервного копирования и об особенностях ра оты лярных утилит diMnp и restore.
340 Часть I. Основы администрирования Далее будут рассмотрены некоторые дополнительные команды резервного копиро- вания и архивирования и даны пояснения, в каких ситуациях предпочтительнее та или иная команда. В завершение главы читатели познакомятся с бесплатным пакетом сете- вого резервного копирования Bacula и некоторыми другими свободно предоставляемы- ми и коммерческими вариантами. 10.1. Принципы резервного копирования Прежде чем приступить к подробному рассмотрению резервного копирования, мы хотели бы поделиться с читателями опытом, который приобрели за долгие годы прак- тической работы (иногда эти знания давались очень тяжело). Ни один из предлагае- мых советов не является абсолютной истиной, но чем чаще вы будете им следовать, тем спокойнее будут протекать процессы резервного копирования данных и их вос- становления. Создавайте резервные копии на центральном компьютере Многие специализированные утилиты позволяют создавать резервные копии по сети. Производительность процесса несколько ухудшается, но это компенсируется легкостью администрирования. Если вы управляете только несколькими серверами, то проще все- го выполнять сценарий на центральном компьютере, который запускает утилиту dump (посредством интерпретатора ssh) на всех компьютерах, где необходимо провести ре- зервное копирование. Если у вас много серверов, мы рекомендуем использовать пакет программ (коммерческий или бесплатный), автоматизирующий этот процесс. Все ар- хивы должны помещаться на одно устройство резервного копирования (в режиме без перемотки, естественно). Если размер системы слишком велик и одного сервера недостаточно, все равно сле- дует пытаться сделать систему резервного копирования как можно более централизован- ной. Это упростит администрирование и позволит восстанавливать данные на альтерна- тивных серверах. Часто на сервере можно установить несколько устройств резервного копирования, и это не повлияет на его производительность. Архивы, созданные с помощью утилиты dump, можно восстановить только на ком- пьютерах с таким же порядком следования байтов, как у ведущего узла (и в большинстве случаев только на компьютерах с такой же операционной системой). Для решения зада- чи, связанной с простой перестановкой байтов, можно использовать программу dd, но она не устранит проблемы несовместимости различных версий утилиты dump. Если вы резервируете большие объемы данных по сети, пропускная способность ко- торой вызывает сомнения, рассмотрите как вариант создание выделенной локальной сети (LAN), предназначенной для передачи резервируемых данных. Многие организа- ции уже оценили эффективность такого подхода, позволяющего преодолевать узкие ме- ста в сетях. Маркируйте носители Маркируйте носители с резервными копиями системы максимально разборчиво и полно — неподписанная лента, по существу, бесполезна. Маркируйте каждый носитель уникальным образом в соответствии с его содержимым. На коробку следует нанести подробную информацию, включающую, например, список файловых систем, дату соз- дания архивов, формат резервирования, точный синтаксис команд, с помощью которых
Глава 10. Резервное копирование 341 они были созданы, и другие сведения, необходимые для восстановления архива без об- ращения к документации. Существуют бесплатные и коммерческие программы создания наклеек для различ- ных носителей. Советуем приобрести одну из них, дабы избавиться от ненужной голов- ной боли. Например, изготовители наклеек, предназначенных для печати на лазерных принтерах, обычно поставляют с ними и шаблоны для генерирования наклеек. Еще лучше приобрести специализированный принтер наклеек. Такие принтеры недорогие и прекрасно работают. Ваша автоматизированная система архивирования должна регистрировать имя каж- дой файловой системы, которую она заархивировала. Если вы захотите восстановить не- который файл, то хорошо организованная регистрация позволит вам быстро перейти к нужной файловой системе. При этом очень важно зафиксировать порядок размещения файловых систем на магнитной ленте или кассете. По возможности приобретите механизм автоматической смены носителя или на- копитель на магнитной ленте (НМЛ), который считывает штрих-коды. Тогда вы будете уверены, что ваши электронные метки магнитной ленты всегда будут совпадать с физи- ческими. Правильно выбирайте периодичность резервного копирования Чем чаще выполняется резервное копирование, тем меньше данных будет потеряно в случае сбоя системы. Процесс резервного копирования, однако, достаточно трудо- емкий и ресурсоемкий. Системный администратор должен обеспечить приемлемую целостность данных при разумном уровне затрат времени и средств. В общем можно сказать, что расходы увеличиваются по мере использования средств восстановления с более мелкой модульностью. В интенсивно эксплуатируемых системах наиболее удобный вариант — создавать ре- зервные копии домашних каталогов пользователей каждый рабочий день. В системах, которые используются менее интенсивно или в которых данные изменяются не столь часто, можно делать копии несколько раз в неделю. В маленькой системе с одним поль- зователем достаточно делать резервную копию раз в неделю. В целом, периодичность определяется объемом данных, которые могут быть утеряны с момента последнего соз- дания резервной копии. Будьте осмотрительны при выборе архивируемых файловых систем Файловые системы, которые изменяются редко, не нужно архивировать столь же ча- сто, как домашние каталоги пользователей. Еслйв файловой системе изменяется лишь несколько файлов (например, файл /etc/passwd в корневой системе), их можно каж- дый день копировать в другой раздел, резервные копии которого создаются регулярно. Если каталог /tmp является отдельной файловой системой, то архивировать его не нужно. Он не содержит ничего существенного, поэтому нет оснований сохранять его. Если это вам кажется очевидным, то вас можно только поздравить (чего не скажешь о многих других организациях и их сотрудниках). '
342 Часть I. Основы администрирования Старайтесь умещать каждодневные архивы на одном носителе Ш Демон cron подробно описан в главе 9. Было бы прекрасно иметь возможность создавать ежедневные резервные копии всех пользовательских файловых систем на одной ленте. Впрочем, при наличии устройств большой емкости, таких как накопители DLT, AIT и ЕГО, это вполне реально, но не каждая организация решится приобрести столь дорогие устройства. По мере того как привычки пользователей изменяются, а удаленный обмен данными становится все бо- лее популярным, “подходящий” временной интервал резервного копирования сокраща- ется. Все больше и больше сетевых служб должно быть задействовано в течение суток, а на резервирование больших объемов данных тратится много времени. Еще одна существенная проблема — быстрое увеличение дискового пространства, связанное со снижением цен на жесткие диски. Теперь вряд ли удастся найти настоль- ный компьютер фабричной сборки, имеющий меньше 250 Гбайт дискового простран- ства. Зачем очищать диски и устанавливать квоты, когда с помощью небольшого капи- таловложения можно безболезненно решить проблему? К сожалению, слишком часто объем сетевых хранилищ данных делает полное резервирование невозможным. Утилиты резервирования прекрасно справляются с архивированием файловых систем на нескольких носителях. Но если архив занимает много резервных носителей (напри- мер, кассет), об их смене должен заботиться оператор или специальный робот, причем все носители должны быть снабжены наклейками, что впоследствии обеспечит нор- мальный процесс восстановления. Если у вас нет веской причины создавать большую файловую систему, то лучше не делайте этого. Если ежедневные архивы невозможно разместить на одной ленте, есть несколько ре- шений: • купите ленточное устройство более высокой емкости; • купите автозагрузчик или ленточную библиотеку, чтобы можно было вставлять не- сколько носителей в одно устройство; • измените периодичность создания резервных копий; • используйте несколько устройств резервного копирования. Храните носители вне рабочего помещения Прежде всего, вы должны всегда иметь автономную копию своих данных, т.е. защи- щенную копию, которая не будет храниться вместе с оригиналом на жестком диске того же компьютера. Настоящее резервирование не заменят никакие моментальные снимки и дисковые массивы (RAID arrays)! В большинстве организаций резервные копии хранят вне рабочего помещения во из- бежание их порчи вместе с основными данными в случае пожара или стихийного бед- ствия. Фраза “вне рабочего помещения” означает как сейф в банке, так и полку в доме у президента компании. Фирмы, специализирующиеся на безопасном хранении резерв- ных носителей, обеспечивают для них надлежащий температурный режим и гарантиру- ют их сохранность. Всегда следует выбирать фирму, пользующуюся хорошей репутацией. Существует множество фирм, специализирующихся на хранении данных, которые обе- спечивают передачу данных по сети, но хранят их в надежном месте.
Глава 10. Резервное копирование 343 Выбор внешнего хранилища определяется тем, как часто нужно восстанавливать файлы и какие потери времени при этом допустимы. В некоторых организациях создают по две резервные копии в день на разных носителях: одна остается в рабочем помеще- нии, а вторую сразу же выносят1. Защищайте резервные копии Дэн Гир (Dan Geer), специалист по вопросам безопасности, однажды сказал: “Что делает резервная копия? Гарантированно нарушает права доступа к файлам на расстоя- нии”. Ни больше, ни меньше! Защищайте свои резервные носители. Один из способов защиты — шифрование ре- зервного носителя. Это сравнительно простой процесс, который тем не менее требует соблюдения таких стандартов обеспечения защиты, как PCI DSS (Payment Card Industry Data Security Standard — стандарт защиты информации в индустрии платежных карт, раз- работанный международными платежными системами Visa и MasterCard). Существует множество утилит резервного копирования, которые облегчают жизнь системному ад- министратору. Вместе с тем, вам следует обеспечить сохранность и целостность ключей шифрования, а также их доступность при возникновении аварийных ситуаций. Резервные носители необходимо защищать и на физическом уровне. Носители нуж- но хранить не просто вне помещения, а под замком, ключ от которого надежно спрятан. Если соответствующие услуги предоставляет коммерческая компания, она должна га- рантировать конфиденциальность лент. Некоторые компании настолько заботятся о сохранности резервных копий, что даже создают их дубликаты. Активность файловой системы во время создания архива должна быть низкой Снятие резервных копий лучше проводить в периоды низкой активности систе- мы, потому что изменения файлов могут привести к ошибкам в работе команды dump. Архивы следует создавать, когда в системе работает мало пользователей (ночью или в выходные дни). Чтобы автоматизировать этот процесс, устанавливайте свои резервные носители каждый день перед уходом домой и позвольте демону cron выполнять эту ра- боту за вас. В этом случае архивирование будет происходить при минимальной вероят- ности изменения файлов, а сам процесс архивирования будет оказывать на пользовате- лей минимальное влияние. В наши дни практически невозможно выполнить резервное копирование при полном отсутствии каких-либо дисковых операций. Пользователям зачастую нужен постоянный и круглосуточный доступ к системе, службы работают сутки напролет, а для резервирова- ния баз данных необходимо использовать специальные процедуры. В большинстве случа- ев работу баз данных нужно временно приостанавливать или переводить в специальный “ослабленный” режим (с ухудшенными характеристиками), чтобы утилиты резервно- го копирования могли аккуратно собирать данные в определенное время суток. Узлы с большими объемами данных могут и не “выдержать” время простоя, необходимое для выполнения традиционных операций резервирования их базы данных. В такие дни оста- 1 Крупная финансовая компания, размещавшаяся во Всемирном торговом центре, хранила свои “внешние” резервные копии одним или двумя этажами ниже своих офисных помещений. Когда здание подверглось первой же террористической атаке, резервные ленты (как и сами компьютеры) были уничтожены. Поэтому “внешнее” хранилище должно быть действительно внешним.
344 Часть I. Основы администрирования ется только один способ обеспечить архивирование данных в отсутствие дисковой актив- ности — сначала создавать “снимок”, т.е. копию состояния каждого объекта (snapshot). СЭ О сетях хранения данных (storage area network — SAN) рассказывается в разделе 8.11. В большинстве контроллеров SAN (и во всех наших примерах операционных систем) предусмотрен тот или иной способ создания “снимка” файловой системы. Это средство позволяет относительно безопасно создавать резервные копии любой активной фай- ловой системы (даже при открытых файлах). В Linux “снимки” создаются с помощью менеджера логических томов (см. раздел 8.8), а в остальных примерах операционных си- стем — посредством файловой системы. “Снимки” можно создавать практически мгновенно благодаря “интеллектуальной” схеме копирования при записи. В процессе создания “снимка” на самом деле никакие данные не копируются и не перемещаются. Если “снимок” существует, то изменения, вносимые в файловую систему, записываются в новые области диска. В этом случае можно поддерживать два (или больше) образа при минимальном использовании допол- нительной памяти. Концептуально создание “снимков” можно сравнить с инкремент- ным резервным копированием, различие только в уровне процесса: не на уровне бло- ков, а на уровне файловой системы. В этом контексте “снимки” представляют собой основное средство создания “реаль- ных” резервных копий файловой системы. Но они никогда не заменяют автономные ре- зервные копии. “Снимки” позволяют упростить резервирование баз данных, поскольку для создания “снимка” работу базы данных необходимо приостановить лишь на секунду. Позже, используя “снимок”, можно выполнить более медленный процесс резервирова- ния на магнитную ленту, никоим образом не мешая базе данных обслуживать запросы. Проверяйте состояние своих носителей Известно немало ужасных историй о системных администраторах, которые не заме- чали проблем, связанных с созданием архивов, до тех пор, пока в системе не происходил серьезный сбой. Важными задачами администратора являются непрерывный контроль над соблюдением установленного порядка резервного копирования и проверка качества его выполнения. Ошибка со стороны оператора приводит к повреждению большего чис- ла архивов, чем любая другая ошибка. На первом этапе проверки следует заставить программу резервного копирования по окончании работы повторно прочесть все ленты2. Неплохо также просмотреть ленты на предмет наличия ожидаемого количества файлов. В идеале должна быть проконтроли- рована каждая лента, но это едва ли практически возможно в крупной организации, где каждый день задействуются сотни лент. Благоразумнее в подобной ситуации осущест- влять выборочную проверку. Ш Более подробно команда restore рассматривается в разделе 10.4. Часто имеет смысл создать таблицу содержимого каждой файловой системы (для этого можно использовать команду restore -t утилиты dump) и сохранить результат (в виде списков) на диске. Полученные списки нужно называть так, чтобы их имена от- ражали связь с соответствующими лентами, например okra:usr. Jan. 13. База данных с такими записями помогает быстро определить, на каком носителе находится пропав- ший файл. Для этого достаточно выполнить команду grep с именем файла в качестве аргумента и выбрать самый последний его экземпляр. 2 Чтобы сравнить содержимое ленты с исходным деревом каталогов, в GNU-версиях можно использовать команду restore -С.
Глава 10. Резервное копирование 345 Успешное чтение таблицы содержимого свидетельствует о том, что архив создан нор- мально и что в случае необходимости наверняка можно будет восстановить файлы с но- сителя. Пробное восстановление файла, выбранного случайным образом, послужит еще более надежным доказательством возможности восстановления данных с этого носителя3. Периодически следует выполнять восстановление с произвольно выбранного резерв- ного носителя, чтобы убедиться в том, что оно по-прежнему возможно. Иногда стоит читать файлы со старых резервных лент (месячной и даже годичной давности)4, ведь у накопителей временами нарушается центровка, и они утрачивают способность читать ими же записанные ленты. Некоторые компании выполняют восстановление старых но- сителей, но их услуги стоят достаточно дорого. Еще один вид проверки — попробовать восстановить данные с носителя в другой ап- паратной среде. Если машинный зал сгорит, пользы от осознания того, что резервную копию можно было бы прочитать на расплавившемся накопителе, будет мало. В про- шлом цифровые аудиокассеты особенно часто страдали от этой проблемы, но теперь технология усовершенствована и носители стали значительно более надежными. Определите жизненный цикл носителя Срок службы всех носителей ограничен. Их можно и нужно использовать повтор- но, но не забывайте о предельном сроке эксплуатации, определяемом изготовителем носителя. Как правило, этот срок задается в виде количества проходов, которые спо- собна выдержать лента. Каждая такая операция, как архивирование, восстановление и команда mt f sf (перемотка на один файл вперед), представляет собой один проход. Неленточные носители обладают значительно более длительным сроком службы, кото- рый иногда выражают средним временем до отказа (mean-time-to-failure — MTTF), но в любом случае все аппаратные средства и носители имеют ограниченный срок службы. Поэтому имеет смысл оценивать его не в реальных годах, а с точки зрения продолжи- тельности жизни, например, собаки. Но прежде чем выбрасывать старые ленты, не забудьте стереть с них всю информа- цию или же сделать ее недоступной для считывания. В этом может помочь устройство для размагничивания магнитной ленты (большой электромагнит), но его следует дер- жать вдали от компьютеров и активных носителей. Разрезание или вытягивание лен- ты из кассеты — не слишком надежная защита данных, поскольку ленту сравнительно легко склеить или намотать заново. Компании, специализирующиеся на уничтожении документов, за сравнительно невысокую плату предоставляют услуги по уничтожению магнитных лент. Если в качестве резервных носителей вы используете жесткие диски, помните, что службы восстановления дисков стоят меньше тысячи долларов. И прежде чем с вашими дисками случится нечто непоправимое, подумайте заранее о средствах, обеспечивающих безопасное удаление (см. раздел 8.5), или о команде SCSI-форматирования. 3 Команда restore -t читает только таблицу содержимого архива, хранящуюся в начале лен- ты. При реальном восстановлении конкретного файла проверяется более крупная область носителя. 4 К пользователям, которые просят восстановить случайно удаленные файлы, полезно отно- ситься как к коллегам, которые просто помогают вам выполнить выборочный контроль вашей си- стемы архивации, а не как к источнику раздражения, не способному даже позаботиться о сохран- ности своих файлов. Позитивное отношение к пользователям делает вашу работу более приятной как для вас самих, так и для системы в целом (поскольку такие ситуации увеличивают количество выборочных проверок).
346 Часть I. Основы администрирования Компонуйте данные с учетом резервного копирования Когда есть столь дешевые и надежные дисковые устройства, возникает соблазн от- казаться от архивирования всех имеющихся данных, сосредоточив усилия лишь на критически важных файлах, тем более что многие системы заполняются практически бесконтрольно. Но если разумно распланировать схему дискового хранения, то можно существенно упростить процесс резервного копирования. Начать необходимо с оценки потребностей. • С данными каких типов придется иметь дело? • Как часто будут изменяться данные различных типов? • Насколько часто нужно выполнять резервное копирование, чтобы возможные по- тери причинили минимальный ущерб? • Какие сетевые и административные ограничения должны быть определены для данных? Используя эту информацию, следует продумать схему хранения данных с учетом ре- зервного копирования и возможного расширения системы в будущем. Лучше размещать каталоги проектов и домашние каталоги пользователей на выделенных файловых серве- рах, что упростит управление данными и позволит гарантировать их безопасность. С появлением убедительных решений по созданию образов системы зачастую проще заново сгенерировать сломанную систему, чем диагностировать неисправности и вос- станавливать поврежденные или недостающие файлы. Одни администраторы конфигу- рируют рабочие станции пользователей в расчете на сохранение всех данных на цен- трализованном сервере. Другие управляют группами серверов, которые характеризуются почти идентичными конфигурациями и данными (такими, как содержимое веб-сайтов занятости). В такой среде не разумно резервировать объемные массивы однотипных си- стем. Однако те, кто “поведен” на безопасности систем, настаивают на интенсивном создании резервных копий, чтобы в случае аварии данные всегда были доступны для судебного исследования. Будьте готовы к худшему После разработки схемы резервного копирования изучите самый худший сценарий: система полностью уничтожена. Определите, сколько информации будет потеряно и сколько времени уйдет на восстановление системы (включая время на закупку нового оборудования). Затем посмотрите, удовлетворяют ли вас полученные результаты. Более формальные организации для информации на конкретных серверах или фай- ловых системах часто определяют такие характеристики, как допустимое время восста- новления (Recovery Time Objective — RTO) и допустимый уровень восстановления (Reco- very Point Objective — RPO). С помощью этих значений можно обеспечить полноценное управление системой. Показатель RTO представляет собой максимальное время, которое бизнес может “вытерпеть” в ожидании восстановления после возникновения аварийной ситуации. Обычно для пользовательских данных значения RTO лежат в пределах от нескольких часов до нескольких дней, а для рабочих серверов — от нескольких секунд до несколь- ких часов. Показатель RPO означает, какая по давности резервная копия требуется для вос- становления данных, поврежденных по определенной причине (т.е. за какой срок вы
Глава 10. Резервное копирование 347 готовы потерять данные). Это значение влияет на уровень, на котором должны сохра- няться резервные копии. В зависимости от того, как часто изменяется набор данных и насколько он важен, значение RPO может колебаться от недель до часов и даже секунд. Очевидно, что резервные копии на магнитной ленте не могут удовлетворять требова- ниям, выраженным близкими к нулю значениями RPO, и поэтому такие требования обычно предполагают наличие больших инвестиций и специализированных устройств хранения данных, расположенных в нескольких информационных центрах. Несмотря на то что процесс определения этих показателей может показаться не- сколько произвольным, он все же позволяет “владельцам” данных и техническому персоналу одинаково понимать задачу сохранности данных. Этот процесс требует урав- новешивания стоимости и затрат в зависимости от конкретных требований бизнеса к восстанавливаемости. Это трудная, но важная задача, которую необходимо решать. 10.2. Устройства и носители, используемые ДЛЯ РЕЗЕРВНОГО КОПИРОВАНИЯ Поскольку многие неисправности могут приводить к одновременному выходу из строя сразу нескольких аппаратных устройств, резервные копии следует помещать на съемные носители. Поэтому важно создавать автономные резервные копии, которые не мог бы повредить ни один “самый сердитый” системный администратор. Например, копирование содержимого одного жесткого диска на другой на одном и том же компьютере или в одном и том же центре обработки данных, конечно, лучше, чем ничего, но оно обеспечивает весьма незначительный уровень защиты на случай от- каза сервера. Хотя компании, организующие резервное копирование через Интернет, становятся все более популярными, все же большинство резервных копий хранится ло- кально. В следующих подразделах описываются различные виды носителей для хранения ре- зервных копий. Они перечислены в порядке возрастания емкости. Производители устройств резервного копирования любят указывать емкость, оттал- киваясь от объема сжатых данных, оптимистично предполагая коэффициент сжатия 2:1 или выше. Ниже мы будем приводить реальное число байтов, которое физически можно записать на тот или иной носитель без учета сжатия. Коэффициент сжатия влияет также на пропускную способность устройства. Если на- копитель позволяет записывать данные на ленту со скоростью 1 Мбайт/с, а производи- тель заявляет о коэффициенте 2:1, то пропускная способность волшебным образом воз- растает до 2 Мбайт/с. Как и в случае емкости, мы проигнорируем рекламную скорость записи и будем учитывать реальные показатели. Оптические носители: CD-R/RW, DVD±R/RW, DVD-RAM и Blu-ray При цене около 30 центов за штуку, диски CD и DVD хорошо подходят для резерв- ного копирования небольших, изолированных систем. Емкость компакт-дисков CD со- ставляет около 700 Мбайт, а дисков DVD — около 4,7 Гбайт. Емкость двухслойных DVD Доходит до 8,5 Гбайт. Дисководы с возможностью записи на эти носители выпускаются для всех стандарт- ных шин (SCSI, IDE, USB, SATA и другие) и во многих случаях настолько дешевы, что,
348 Часть I. Основы администрирования по существу, на их стоимость можно не обращать внимание. Теперь, когда цены CD и DVD практически сравнялись, нет никаких причин использовать CD, а не DVD (если, конечно, не учитывать, что устройства чтения CD все еще более распространены). Запись на оптические носители осуществляется фотохимическим способом посред- ством лазерного луча. Хотя достоверных данных нет, считается, что оптические носи- тели долговечнее, чем магнитные. Однако даже диски с однократной записью (CD-R, DVD-R и DVD+R) уступают по долговечности фабричным (штампованным) компакт- дискам CD и DVD. Современные записывающие приводы DVD не уступают по скорости ленточным на- копителям (а некоторые даже и превосходят их). Версии DVD-R и DVD+R предназна- чены для одноразовой записи. Носители DVD-RW, DVD+RW и DVD-RAM допускают многократную запись. Система DVD-RAM имеет встроенные средства обработки дефек- тов и поэтому более надежна, чем другие типы носителей. В то же время эти носители значительно дороже остальных. По прогнозам изготовителей потенциальный срок службы этих носителей при пра- вильном их хранении должен составлять сотни лет. Изготовители рекомендуют хранить диски в отдельных коробках при постоянной температуре в диапазоне 41—68°F (5о-20°С) и относительной влажности 30—50% в защищенном от прямых солнечных лучей месте. Для маркировки дисков следует использовать только водорастворимые маркеры. Веро- ятно, в общем случае более реальным можно считать срок службы, равный 1—5 годам. Как показывают многочисленные исследования, выполненные независимыми экс- пертами, надежность оптических носителей, в основном, определяется фирмой-изгото- вителем. Это как раз тот случай, когда приобретение первоклассных носителей полно- стью окупается. К сожалению, даже изделия одного и того же изготовителя различаются по качеству. Недавно на рынке оптических носителей появились диски типа Blu-Ray, различны^ версии которых позволяют хранить 25—100 Гбайт данных. Их высокая емкость обеспе- чивается более короткой длиной волны (405 нм) лазера, используемого для чтения и за- писи (отсюда и название этого типа носителей “blue” — голубой). Поскольку цена на эти носители падает, технология Blu-Ray обещает стать хорошим решением для резерв- ного копирования. Переносные и съемные жесткие диски Внешние накопители, подключаемые через порты USB 2.0 или eSATA, распростра- нены повсеместно. Обычно в качестве основного устройства хранения используется toi или иной жесткий диск, но флеш-память (вездесущие “портативные диски”) находи? все большее распространение. Емкости этих устройств варьируются от менее 250 Гбайп до 2 Тбайт и более. В настоящее время используются также полупроводниковые (твер- дотельные) диски (Solid state drives — SSD), в основе которых лежит флеш-память емко- стью до 160 Гбайт. В настоящее время максимальная емкость устройств флеш-памяти встречающихся на рынке, составляет около 64 Гбайт. В основном, долговечность устройств флеш-памяти определяется числом циклов за- писи. Предположительно устройства среднего класса рассчитаны на 100 000 циклов. Основным ограничением устройств, используемых в качестве резервных носителей является то, что они обычно работают в реальном масштабе времени и поэтому весьма чувствительны к скачкам напряжения, перегреву и злонамеренным манипуляциям поль- зователей. Для того чтобы жесткие диски эффективно работали резервными носителя
Глава 10. Резервное копирование 349 ми, они должны быть вручную размонтированы или отсоединены от сервера. Съемные устройства облегчают эту задачу. Специализированные “безленточные” системы резер- вирования, которые используют диски для эмулирования автономной природы ленточ- ных устройств, также присутствуют на рынке. Магнитные ленты Многие виды носителей информации сохраняют данные за счет специального ори- ентирования магнитных частиц. Такие носители подвержены разрушительной силе со стороны электрических и магнитных полей. Поэтому вы должны остерегаться таких ис- точников магнитного поля, как акустические колонки, трансформаторы, источники пи- тания, неэкранированные электродвигатели, дисковые вентиляторы и ЭЛТ-мониторы, а также длительного воздействия фонового излучения Земли. Все магнитные ленты рано или поздно (спустя годы) становятся нечитабельными. Большинство ленточных носителей прослужат верой и правдой по крайней мере три года, но если вы планируете хранить свои данные больше трех лет, должны использовать носитель, который сертифицирован для более долгого хранения информации, или пе- риодически переписывать данные на другие носители. Малые лентопротяжные устройства: 8-миллиметровые и DDS/DAT Различные варианты лентопротяжных устройств, как 8-миллиметровых, так и рабо- тающих в стандарте DDS (Digital Data Storage — цифровое хранение данных) и DAT (Digital Audio Таре — цифровая аудиолента), образуют дешевый сегмент рынка ленточ- ных накопителей. Еще не так давно наибольшей популярностью пользовались 8-мил- лиметровые лентопротяжные устройства компании Exabyte, но в них наблюдалась тен- денция к нарушению центровки каждые 6—12 месяцев, что вело к необходимости их регулировки в ремонтной мастерской. Часто лентопротяжный механизм растягивал лен- ты, и они становились нечитаемыми. Емкость этих лент, равная 2-7 Гбайт, делает их малопригодными для резервирования даже современных настольных систем, не говоря уже о серверах. Накопители DDS/DAT — это устройства, в которых запись данных осуществляется на 4-миллиметровую ленту методом спиральной развертки (наклонно-строчная запись). В действительности DAT-устройства относятся к стандарту DDS, но это непринципи- альное различие. Исходный формат обеспечивал емкость около 2 Гбайт, но в следующих версиях стандарта DDS емкость существенно возросла. Последняя версия (DAT 160) по- зволяет хранить до 80 Гбайт данных при скорости их передачи, равной 6,9 Мбайт/с. По заявлениям изготовителей ленты должны выдерживать до 100 циклов резервной записи, а их срок службы составляет до 10 лет. Устройства DLT/S-DLT Устройства DLT/S-DLT (Digital Linear Tape/Super Digital Linear Tape) представляют основную разновидность носителей резервного копирования. Они надежны и позволяют хранить большие объемы данных. Их родоначальниками являются кассетные накопите- ли ТК-50 и ТК-70 компании DEC. Впоследствии компания DEC продала технологию Фирме Quantum, которая увеличила скорость записи и емкость носителей и снизила на Них Цены. В 2002 году Quantum приобрела лицензию на телеологию Super DLT, разрабо-
350 Часть I. Основы администрирования тайную компанией Benchmark Storage Innovations. При использовании этой технологии записывающая головка наклоняется вперед и назад, что позволяет снизить перекрест- ные искажения между соседними дорожками. В настоящее время компания Quantum предлагает две серии устройств: одна ориен- тирована на достижение максимальной производительности, а вторая — на максималь- ную емкость. Пользователь имеет возможность выбрать то, что ему наиболее подходит. Емкости ленты варьируются от 800 Гбайт в устройствах серии DLT-4 до 160 Гбайт в устройствах DLT-4 серии повышенной емкости при скоростях передачи данных 60 и 10 Мбайт/с соответственно. По заявлениям производителей ленты прослужат от 20 до 30 лет. Но будут ли к тому времени существовать устройства, способные их про- честь? Много ли вам известно устройств чтения 9-дорожечных лент, которые до сих пор функционируют? Недостатком технологии S-DLT является цена носителей, которая достигает 90— 100 долларов (для 800-гигабайтовых лент). Для какой-нибудь инвестиционной компа- нии с Уолл-стрит это, может быть, нормальная цена, но для университета она несколько высоковата. Устройства AIT и SAIT Технология AIT (Advanced Intelligent Таре — усовершенствованная лента со встроен- ной логикой) — это линия усовершенствованных устройств записи на 8-миллиметровую ленту, выпускаемых компанией Sony. В 1996 году компания отказалась от поддержки устройств Exabyte и представила собственный стандарт AIT-1, в котором также исполь- зовался метод наклонно-строчной записи (спиральная развертка), но емкость накопите- лей была в два раза выше. В настоящее время Sony предлагает версию AIT-4 (с емкостью кассеты 200 Гбайт при максимальной скорости передачи 24 Мбайт/с) и свою последнюю разработку AIT-5 (с удвоенной емкостью кассеты при той же максимальной скорости передачи). Предлагаемые компанией Sony устройства SAIT половинной высоты используют бо- лее широкий носитель и обладают большей емкостью, чем AIT. Ленты SAIT позволяют хранить до 500 Гбайт данных при скорости их передачи 30 Мбайт/с. Эти устройства наи- более популярны в качестве ленточных библиотек. В AIT- и SAIT-устройствах используются ленты АМЕ (Advanced Metal Evaporated — усовершенствованная технология напыления металла) с большим сроком эксплуатации. В ленточных картриджах имеется встроенное ЭСППЗУ (электрически стираемое про- граммируемое ПЗУ), содержащее микрокод носителя, но для использования этого ми- крокода требуется программная поддержка. Цена устройств и лент сопоставима с ценой DLT-аналогов. Устройства VXA/VXA-X В 2006 году компания Tandberg Data купила технологии УХА и УХА-Х, разработан- ные компанией Exabyte. В лентопротяжных устройствах УХА использована технология, которая в компании Exabyte получила название пакетной технологии передачи дан- ных. В устройствах УХА-Х по-прежнему используются ленты АМЕ производства ком- пании Sony. Емкость устройств серии У возрастает с появлением носителей более вы- сокой емкости. Заявленная емкость устройств серий УХА и X колеблется в диапазоне 33—160 Гбайт при скорости передачи 24 Мбайт/с.
Глава 10. Резервное копирование 351 Устройства LTO Открытый стандарт ленты с линейной записью (Linear Tape-Open — LTO) был раз- работан компаниями IBM, HP и Quantum в качестве альтернативы запатентованному! формату DLT Последняя версия этого формата, LTO-4, позволяет хранить 800 Гбайт данных при скорости передачи 120 Мбайт/с. Предполагаемый срок эксплуатации лент LTO — 30 лет, но они чувствительны к влиянию магнитных полей. Устройства предыду- щего поколения (LTO-3) продаются гораздо дешевле, что вполне ожидаемо, и при этом они вполне пригодны для использования во многих средах. Цена картриджей формата LTO-3 (емкостью 400 Гбайт) составляет около $25, а формата LTO-4 — $40. Системы с автоматической загрузкой носителей (автозагрузчики, ленточные массивы и библиотеки) Стоимость современных жестких дисков столь мала, что многие организации могут позволить себе использовать диски огромной емкости. Поэтому для резервного копиро- вания всех имеющихся данных иногда требуется несколько лент, даже если емкость каж- дой из них составляет 800 Гбайт. В таких случаях можно порекомендовать приобрести автозагрузчик, ленточный массив или библиотеку. Автозагрузчик — это простое устройство для автоматической смены лент, используе- мое со стандартным накопителем. Он оснащен съемным магазином, в который помеща- ются ленты. Заполненная лента изымается из накопителя и заменяется пустой лентой, которую автозагрузчик берет из магазина. В магазинах автозагрузчиков обычно помеща- ется до десяти лент. Ленточный массив — это устройство, которое автоматически меняет съемные но- сители в нескольких накопителях. Выпускаются массивы для различных типов носите- лей. Часто они поставляются вместе со специальными программами создания резерв- ных копий, которые манипулируют устройством смены носителей. Такие программные продукты выпускаются, в частности, компаниями Storage Technology (теперь это часть Oracle) и Sony. Ленточные библиотеки (также известные как библиотекари с автоподачей картрид- жей) — это устройства для хранения огромных (терабайтовых) объемов данных. Они представляют собой аппаратные комплексы размером со шкаф, в которых имеется ма- нипулятор типа “рука”, обслуживающий многочисленные полки с ленточными носи- телями или оптическими приводами. Несложно догадаться, что эти устройства очень дороги как при покупке, так и в обслуживании, ведь им требуется специальное электро- питание, помещение и особый режим вентиляции. Как правило, вместе с библиотекой заказываются услуги оператора, который отвеча- ет за установку и наладку комплекса. С библиотекой поставляется также программный пакет, управляющий ее работой. Ведущими производителями ленточных библиотек яв- ляются компании Storage Technology (Oracle), Spectra Logic и HP. Жесткие диски Стремительное снижение стоимости жестких дисков делает их вполне достойными кандидатами на роль устройств резервного копирования. И хотя мы не рекомендуем ко- пировать один диск на другой на том же самом компьютере, можно создавать резервные копии по сети; их стоимость при этом будет очень невелика, а времени, требуемого для постановления больших наборов данных, уйдет достаточно мало.
352 Часть I. Основы администрирования Конечно, емкость жесткого диска ограничена, и со временем он будет занят полно- стью. Однако резервные копии на жестких дисках — прекрасное средство защиты от случайного удаления файлов. Когда есть вчерашний образ диска, доступный по сети че- рез NFS или CIFS, пользователи получают возможность исправлять свои ошибки без вмешательства администратора. Помните, что оперативная память, как правило, недостаточно защищена от злонаме- ренных взломщиков или отказов оборудования информационных центров. Если вы не можете сохранять свои резервные копии автономно, то, по крайней мере, подумайте об их географической диверсификации. Интернет и службы облачного резервирования данных В последнее время поставщики услуг начали предлагать решения, обеспечивающие сохранение данных в Интернете. Вместо использования хранилища в собственном ин- формационном центре, вы арендуете хранилище у так называемого облачного постав- щика услуг (cloud provider). Этот подход не только обеспечивает доступ по запросу к хранилищу практически неограниченного размера, но и предоставляет простой способ сохранения данных в нескольких географических местах. Цены на услуги интернет-служб хранения информации составляют от 10 центов за гигабайт в месяц и возрастают по мере добавления функциональных возможностей. Например, некоторые провайдеры позволяют выбрать количество сохраняемых резерв- ных копий данных. Такая оплата по факту потребления позволяет вам выбрать уровень надежности, соответствующий вашим данным и бюджету. Интернет-резервирование действует только в случае, если ваше интернет-соединение достаточно быстрое для передачи копий изменений в течение ночи (т.е. без погрязания в “реальном” трафике). Если в вашей организации обрабатываются очень большие объ- емы данных, то вряд ли вы сможете резервировать их с помощью Интернета. Но для небольших организаций “облачное” резервирование может оказаться идеальным реше- нием, поскольку оно не требует никакой предоплаты и покупки оборудования. Однако следует помнить, что любые данные, передаваемые через Интернет или сохраняемые в “облачных” копиях, должны быть зашифрованы. Типы носителей Как мы видим, существует множество возможностей. В табл. 10.1 приведены харак- теристики рассмотренных выше носителей и соответствующих им устройств. Таблица 10.1. Сравнительные характеристики носителей, применяемых для резервного копирования Носитель ©ЙИИКЯЙг f Пбайт b-МйВВеО* ? r liMWyWBCTpJf Щянк- далл. s ~ ' -— CD-R 0,7 7 15 0,15 0,21 Нет Да CD-RW 0,7 4 20 0,3 0,42 Да Да DVD±R 4,7 30 30 0,3 0,06 Нет Да DVD+R DLB 8.5 30 30 1 0,12 Нет Да DVD±RW 4,7 10 30 0,4 0,09 Да Да
Глава 10. Резервное копирование 353 Окончание табл. 10.1 Носитель Емкость®, Гбайт Скорость*, мбайт/с Цена ПИЛМЛ. доли. . нм*ь-':'В<мй!чиге -У Blu-ray 25 30 100 3 0,12 Нет Да DDS-4 (4 мм) 20 30 100 5 0,25 Да Нет DLT/S-DLT 160 16 500 10 0,06 Да Нет DLT-S4 800 60 2500 100 0,13 Да Нет А1Т-4(8мм) 200 24 1200 40 0,2 Да Нет AIT-5 400 24 2500 50 0,13 Да Нет VXA-320 160 12 800 60 0,38 Да Нет LT0-3 400 80 200 25 0,06 Да Нет LT0-4 800 120 1600 40 0,05 Да Нет а Емкость и скорость указаны без учета сжатия данных. 6 Допускает произвольный доступ к любому фрагменту данных. в Двухслойный. Что покупать В табл. 10.1 достаточно точно отражено состояние рынка оборудования для вы- полнения резервного копирования. Все устройства резервного копирования работают достаточно хорошо, и среди систем одной ценовой категории обычно трудно отдать какой-либо предпочтение. Покупайте устройство, которое отвечает требованиям вашей организации и имеет приемлемую цену. Если вы разрабатываете новое оборудование, убедитесь в том, что оно поддерживается вашей операционной системой и программны- ми средствами резервирования данных. Несмотря на то что цена и емкость носителя — важные факторы, не менее важно учесть и пропускную способность. Со скоростными носителями приятнее иметь дело, но вы должны внимательно отнестись к покупке накопителя на магнитной ленте, чтобы он не перегружал сервер. Если сервер не в состоянии передавать данные на накопитель с приемлемой скоростью, нужно останавливать процесс записи на накопитель на время, пока сервер его не “догонит”. Конечно, низкие скорости никого не могут устроить, но и слишком высокие тоже вам ни к чему. Выбирайте резервный носитель в соответствии с объемами ваших данных. Нет смыс- ла тратить деньги на устройства DLT-S4, если вам необходимо защищать лишь несколь- ко сотен гигабайт данных. Ваш накопитель в этом случае будет оставаться полупустым. Оптические носители, устройства DDS и LTO лучше всего подходят для небольших рабочих групп и отдельных компьютеров, в которых установлены диски высокой емко- сти. Начальная цена этих систем относительно умеренна, а их носители широко рас- пространены, к тому же за каждым стандартом стоит целый ряд производителей. Все системы обладают достаточным быстродействием, что позволяет архивировать большие объемы данных за разумное время. Устройства DLT, AIT и ЕГО имеют сопоставимые характеристики. Трудно сделать вы- бор в пользу одной из этих технологий, тем более что ситуация может измениться с по- явлением новых спецификаций и моделей устройств. Все эти форматы тщательно про-
354 Часть I. Основы администрирования думаны и могут быть успешно интегрированы в любую систему — будь то среда учебно- го заведения или среда крупной коммерческой организации. В следующих разделах базовый термин “лента” используется в качестве универсаль- ного обозначения носителей, выбранных для резервного копирования. Примеры команд, выполняющих резервное копирование, даются в контексте ленточных накопителей. 10.3. Экономия ПРОСТРАНСТВА И ВРЕМЕНИ С ПОМОЩЬЮ ИНКРЕМЕНТНОГО АРХИВИРОВАНИЯ Почти все инструменты резервирования поддерживают, по крайней мере, два раз- ных вида архивирования: полное резервное (страховое) копирование и инкрементное. Полное копирование включает все содержимое файловой системы, а инкрементное — только файлы, которые были изменены с момента предыдущего резервирования. Инкре- ментное резервное копирование способствует минимизации объема ленточного накопи- теля и пропускной способности сети, требуемых для ежедневного создания резервных копий. Поскольку большинство файлов никогда не меняется, даже в простейшей схеме инкрементного архивирования многие файлы не включаются в ежедневный архив. Многие инструменты резервирования поддерживают дополнительные виды архиви- рования (помимо основных процедур выполнения полного и инкрементного резервного копирования). Стоит отметить, что все эти дополнения являются более сложными ва- риациями на тему инкрементного копирования. Единственный способ уменьшить объ- ем резервируемых данных — воспользоваться тем, что многие данные уже сохранены на какой-нибудь архивной ленте. Существуют программы резервирования, которые распознают идентичные копии данных, даже если они находятся в различных файлах на различных компьютерах. При этом гарантируется, что на ленту записывается только одна копия данных. Эта функция называется дедупликацией (разделение на несколько частей), и она может быть очень полезной для ограничения размера резервных копий. Выбор схемы зависит от следующих факторов: • активность файловых систем; • емкость устройства резервного копирования; • необходимая степень избыточности; • число лент, которые нужно приобрести. При создании архива ему присваивается номер уровня (целое число от 0 до 9). В ар- хив уровня N копируются все файлы, которые изменились с момента создания послед- него архива уровня ниже N. В архив нулевого уровня включается вся файловая система. В режиме инкрементного архивирования файловую систему можно вернуть в то состоя- ние, в котором она находилась в момент последнего резервного копирования, хотя для этого может потребоваться восстановление файлов из нескольких лент5. Ранее команда dump поддерживала уровни 0—9, но более новые ее версии поддер- живают тысячи уровней архивирования. При введении дополнительных уровней не- большое число регулярно изменяющихся файлов разбивается на более мелкие сегменты. Сложная схема резервного копирования обеспечивает следующие преимущества: 5 Большинство версий команды dmzg> не отслеживает, какие файлы были удалены с момента создания архива. При восстановлении информации из инкрементных резервных копий удаленные файлы снова появятся в системе.
Глава 10. Резервное копирование 355 • данные будут архивироваться чаще, что позволит снизить возможные потери; • ежедневно будет использоваться меньшее число лент (или же все поместится на одну ленту); • в целях защиты от ошибок будет создаваться несколько копий каждого файла; • пропускная способность сети и время, необходимое для резервирования, суще- ственно сокращаются. Эти преимущества необходимо соизмерить со сложностью, связанной с поддержкой системы и восстановлением файлов. Мы опишем несколько возможных схем и приве- дем аргументы в пользу каждой из них. Иногда можно использовать эти схемы без из- менений, а иногда приходится разрабатывать совершенно другие схемы. Простая схема Если общий размер дискового пространства меньше емкости ленты, можно пред- ложить простой график архивирования. Архивы нулевого уровня каждой файловой си- стемы должны создаваться ежедневно. Используйте многократно один набор лент, но через каждые Адней (где А определяется потребностями организации) откладывайте ленты навсегда. Стоимость такой схемы составит (365/7V) * (цена ленты) в год. При соз- дании очередного архива нельзя использовать предыдущую ленту. Лучше осуществлять ротацию лент, чтобы в случае уничтожения одного из архивов можно было восстановить архив предыдущего дня. Подобная схема обеспечивает высокую избыточность и значительно упрощает вос- становление данных. Она хорошо подходит для организации, имеющей много денег, но очень занятого (или неопытного) администратора. С точки зрения надежности и удоб- ства это идеальная схема. От нее не следует отступать без особой на то причины (напри- мер, в целях экономии лент или снижения трудоемкости). Умеренная схема В большинстве организаций придерживаются более разумного подхода: выделяется по одной ленте на каждый день недели, каждую неделю месяца (понадобится пять таких лент) и каждый месяц года. Ежедневно создается дневной архив девятого уровня, еже- недельно — недельный архив пятого уровня, ежемесячно — месячный архив третьего уровня. Архив нулевого уровня нужно создавать всякий раз, когда инкрементные копии становятся слишком большими для одной ленты. Чаще всего это происходит с лентами месячного архива. В любом случае архивирование нулевого уровня необходимо прово- дить хотя бы раз в год. Выбор уровней 3, 5 и 9 сделан произвольно. С таким же успехом можно использо- вать уровни 1, 2 и 3, но интервалы между ними дают определенную свободу для маневра на случай, если впоследствии потребуется добавить еще один уровень. (В других про- граммах резервирования вместо уровней, выраженных числами, используются подходы, определяемые такими терминами, как полное, дифференциальное и инкрементное ар- хивирование.) Такой график требует наличия двадцати четырех основных лент, а также какого-то количества лент для архивов нулевого уровня. Общее число необходимых лент невели- ко, но и избыточность невысока.
356 Часть I. Основы администрирования 10.4. Команда dump: настройка РЕЖИМА РЕЗЕРВИРОВАНИЯ Самые распространенные программные средства создания резервных копий и вос- становления данных — команды dump и restore. Они существуют уже длительное вре- мя и хорошо изучены. В большинстве организаций команды dump и restore использу- ются автоматизированными системами резервного копирования. Д Наличие команд dump и restore в системе зависит от того, какие опции были заданы при установке Linux, поэтому не исключено, что их придется инстал- лировать явно. Для каждой системы существует специальный программный пакет, упрощающий процедуру установки. Текущая версия ядра системы Red Hat во время установки предлагает установить административный пакет, кото- рый включает в себя команду dump. В системах Solaris команды dump и restore называются uf sdump и uf srestore SOiariS соответственно. Команда dump существует, но она не связана с резервирова- нием данных. Как можно понять из названий этих команд, uf s-команды рабо- тают только со старыми файловыми системами UFS; они не работают в файло- вых системах ZFS. О вариантах ZFS-резервирования написано в разделе 10.6. Команда uf sdump принимает те же флаги и аргументы, что и традиционная коман- да dump в других системах, но обрабатывает аргументы по-другому. Команда uf sdump ожидает приема всех флагов, содержащихся в первом аргументе, и требует, чтобы аргу- менты флагов следовали в определенном порядке. Например, в случае, когда большин- ство команд принимает последовательность аргументов-а 5 -Ь -с 10, Solaris-команда uf sdump примет такую последовательность: abc 5 10. Предполагается, что команда uf sdump используется только в немонтируемых файло- вых системах. Если вам нужно выполнить резервирование активной файловой системы, запустите сначала Solaris-команду f ssnap, а затем для получения “снимка” системы вы- полните команду uf sdump. • В системе AIX команда dump называется backup, хотя команда restore со- хранила прежнее имя restore. Команда dump существует, но она не связана с резервированием данных. Для простоты мы будем называть команды резервирования “общими” именами dump и restore, отображая их традиционные флаги командной строки. Несмотря на другие названия в некоторых системах, эти команды функционируют аналогичным образом. Учитывая важность надежного архивирования, имеет смысл проверить назначение фла- гов в man-страницах на компьютере, данные которого вы резервируете; поскольку мно- гие изготовители имеют обыкновение изменять значение хотя бы одного флага. Архивирование файловых систем Команда dump формирует перечень файлов, которые модифицировались с момента предыдущего архивирования, а затем упаковывает эти файлы в один большой архив, подлежащий записи на внешнее устройство. Команда dump обладает рядом преиму- ществ, по сравнению с другими утилитами, описанными в этой главе. • Резервные копии могут быть записаны на несколько лент.
Глава 10. Резервное копирование 357 • Можно выполнять резервное копирование и восстановление файлов любого типа (даже файлов устройств). • Права доступа, информация о владельцах и даты модификации файлов сохраняются. • Обеспечивается правильная обработка файлов с “дырами”6. • Резервное копирование может выполняться в инкрементном режиме (на ленту за- писываются только модифицированные версии файлов). GNU-версия команды tar, используемая в Linux, также реализует все эти возмож- ности, но средства инкрементного архивирования у команды dump лучше. К сожалению, так сложилось, что версия команды tar, входящая в состав большин- ства основных UNIX-систем, не обладает перечисленными выше особенностями GNU- версии. Если с резервными копиями нужно работать не только в Linux, но и в других UNIX-системах, то у команды dump нет конкурентов. Она одинаково ведет себя на раз- ных платформах, поэтому нет смысла осваивать две команды, когда достаточно одной. Команда dump предоставляет меньше возможностей, но команда tar разборчива! ДВ системах Linux команда dump поддерживает файловые системы в расширен- ном составе. Возможно, для поддержки других файловых систем вам придется загрузить и инсталлировать другие версии команды dump. Команда dump понимает структуру исходных файловых систем и непосредственно читает таблицы индексных дескрипторов, чтобы определить, какие файлы подлежат ар- хивированию. Такое знание файловой системы делает команду dump весьма эффектив- ной, но вместе с тем налагает на нее определенные ограничения7. 03 Подробная информация об NFS приведена в главе 18. Одно из ограничений заключается в том, что каждая файловая система должна ар- хивироваться в индивидуальном порядке. Другое ограничение: разрешается копировать только файловые системы локального компьютера, а файловую систему NFS, смонти- рованную по сети, архивировать нельзя. Тем не менее можно создать резервную копию локальной файловой системы на удаленном ленточном накопителе8. Еще одна приятная особенность команды dump связана с тем, что она не обращает внимания на длину имен файлов. Иерархии каталогов могут быть произвольно глубоки- ми, и длинные составные имена обрабатываются корректно. Первым аргументом команды dump должен быть уровень архива. Для того чтобы оп- ределить, насколько давно создавался последний архив, команда dump проверяет файл /etc/dumpdates. Флаг -и заставляет команду по завершении копирования автомати- чески обновить файл /etc/dumpdates. При этом регистрируются дата, уровень архива и имя файловой системы. Если флаг -и ни разу не использовался, всем архивам будет присваиваться уровень 0, поскольку факт предыдущего резервного копирования файло- 6 “Дыры” — это блоки, которые никогда не содержали данных. Если открыть файл и записать в него один байт, а затем переместить указатель текущей позиции на 1 Мбайт вперед и записать еще один байт, то полученный “разреженный” файл будет занимать всего два дисковых блока, хотя его логический размер гораздо больше. Много “дыр” обычно содержат файлы, созданные в СУБД Berkeley DB или ndbm. Команда dusp требует доступа к неструктурированным разделам диска. Каждый, кому раз- решено выполнять резервное копирование, может, приложив определенные усилия, прочесть все файлы в системе. Унаследованные системы для создания резервной копии системы на удаленном ленточном накопителе могут использовать отдельную команду rdump. Современные версии команды dump принимают аргумент -f имя_узла:ленточное_устройство.
358 Часть I. Основы администрирования вой системы нигде не отражался. Если имя файловой системы изменилось, можно от- редактировать файл /etc/dumpdates вручную. Щ О номерах устройств рассказывается в разделе 13.2. Свою выходную информацию команда dump посылает на устройство, заданное по умолчанию. Как правило, это основной ленточный накопитель. Для указания друго- го устройства необходимо использовать флаг -f. Когда на одну ленту помещается не- сколько архивов, задайте имя ленточного устройства, не поддерживающего режим об- ратной перемотки (т.е. укажите файл устройства, который не вызывает перемотку ленты по окончании записи, — для большинства ленточных устройств такой файл создается наряду со стандартным)9. Прочитайте man-страницу, посвященную вашему ленточному устройству, чтобы определить точное имя соответствующего файла. В табл. 10.2 приведе- но несколько советов для наших четырех примеров систем. Таблица 10.2. Файлы устройств для стандартного ленточного накопителя SCSI Система ,Ч- 1 1 ',1 «.‘."‘"к" С перемоткой .111141 1. N И1 |Щ1и Без перемотки Linux /dev/stO /dev/nstO Solaris /dev/nut/0 /dev/rmt/0n HP-UX /dev/rmt/0m /dev/rmt/Omn AIX /dev/rmtO /dev/rmtO. 1 Если случайно выбран файл устройства с обратной перемоткой, все закончится со- хранением только последней заархивированной файловой системы. Поскольку команда dump не проверяет, перемотана лента в начало или нет, эта ошибка не повлечет за собой других ошибок и станет очевидной лишь при попытке восстановить файлы. Чтобы заархивировать удаленную систему, удаленное устройство нужно задать в фор- мате имя_компьютера устройство. $ sudo dump -Ou -f anchor:/dev/nstO /spare Права доступа к удаленному ленточному устройству определяются посредством ка- нала SSH. Подробнее о SSH рассказывается в разделе 22.10. Раньше команде dump нужно было указывать точную длину ленты, чтобы запись пре- кращалась при достижении конца ленты. Современные накопители самостоятельно об- наруживают конец ленты и сообщают об этом команде dump, которая перематывает лен- ту в начало, выталкивает носитель из устройства и запрашивает новую ленту. Поскольку применение различных аппаратных алгоритмов сжатия не позволяет определить длину ленты на основании емкости носителя, лучше ориентироваться на сигнал конца ленты (EOT-End Of Таре). Все версии команды dump воспринимают опции -d и -s, которые задают плотность записи информации на магнитную ленту (tape density) в байтах на дюйм и длину ленты в футах соответственно. Чуть более чувствительные версии позволяют указывать размеры в килобайтах (с помощью опции -В). Для версий, которые “не понимают” эти опции, для выражения желаемых размеров вам придется предварительно произвести некоторые арифметические вычисления. Например, предположим, что вы хотите создать архив уровня 5 файловой системы /work на ленточном накопителе DDS-4 (DAT), собственная емкость которого состав- 9 Для всех файлов ленточного устройства задан один и тот же старший номер устройства. Младший номер устройства сообщает драйверу о наличии особых свойств (режим обратной пере- мотки, режим перестановки байтов и т.д.).
Глава 10. Резервное копирование 359 ляет 20 Гбайт (при обычной емкости сжатых данных около 40 Гбайт). DAT-устройства могут сообщать о конце ленты (EOT), поэтому нам нужно “обмануть” команду dump и установить размер ленты равным значению, намного превышающему 40 Гбайт, ска- жем, 50 Гбайт. Тем самым мы “выжмем” около 60 000 футов при плотности 6 250 байт на дюйм. # dump -5u -s 60000 -d 6250 DUMP: Date of this level DUMP: Date of last level DUMP: Dumping /dev/hda2 DUMP: mapping (Pass I) DUMP: mapping (Pass II) DUMP: estimated 18750003 -f /dev/nstO /work 5 dump: Wed Nov 18 14:28:05 2009 0 dump: Sun Nov 15 21:11:05 2009 (/work) to /dev/nstO [regular files] [directories] tape blocks on .23 tape(s) За флагами -5u следуют параметры -s (размер: 60 000 футов), -d (плотность. 6 250 байт на дюйм) и -f (файл устройства: /dev/nstO). В конце указывается обязатель- ный аргумент: имя файловой системы (/work). Одни версии (таких большинство) ко- манды dump позволяют задавать файловую систему с помощью ее точки монтирования, как в приведенном выше примере. Другие требуют указывать исходный файл устройства. Последняя строка результатов выполнения приведенной выше команды подтвержда- ет, что команда dump не будет пытаться менять ленты по собственной инициативе, по- скольку она “считает”, что для данного архива понадобится только около четверти лен- ты. Хорошо, если количество ожидаемых лент больше 1, так как заданный размер ленты больше реального. Команда dump достигнет реального конца ленты (EOT) раньше, чем она достигнет собственного вычисленного предела. Команда restore: восстановление файлов из резервных копий Команда, восстанавливающая данные с резервных лент, называется restore. Вначале рассмотрим восстановление отдельных файлов (или небольших групп файлов), а затем — файловых систем целиком. Обычно используется динамически связанная команда restore, поэтому для успеш- ной работы вам нужен доступ к библиотекам системы. Построение статически связанной версии команды restore потребует дополнительных усилий, но упростит восстановле- ние системы после аварии, поскольку в этом случае команда совершенно автономна. Первое, что нужно сделать, узнав о пропаже файла, — выяснить, на каких лентах есть его версии. Чаще всего пользователи просят найти самую последнюю версию файла, но так бывает не всегда. Например, пользователь, потерявший файл из-за случайного ко- пирования поверх него другого файла, будет искать ту версию, которая существовала до этой неприятности. Желательно, чтобы пользователи сообщали не только о том, какие файлы пропали, но и когда они пропали и когда модифицировались последний раз. Если не ведутся оперативные таблицы архивов, придется монтировать ленты одну за другой и пытаться восстанавливать пропавшие файлы, пока не будет найдена нужная лента. Если пользователь помнит примерную дату последнего изменения файла, можно с достаточной степенью вероятности предположить, на какой ленте он находится. Определив ленты, с которых будет производиться восстановление, создайте времен- ный каталог, к примеру, /var/restore, где будет сформирована большая иерархия под- каталогов, и перейдите в него с помощью команды cd. Команда restore обычно созда- ет каталоги, ведущие к файлу, прежде чем восстанавливать его. Не используйте для этих
360 Часть I. Основы администрирования целей каталог /tmp: в случае системного сбоя и последующей перезагрузки содержимое каталога может быть стерто. У команды restore много опций. Самые важные из них-------i, которая позволяет восстанавливать отдельные файлы и каталоги в интерактивном режиме, и -г, задающая полное восстановление всей файловой системы. Опция -х запрашивает автоматическое восстановление указанных файлов — будьте осторожны, чтобы не затереть существую- щие файлы. Команда restore -i читает с ленты таблицу содержимого, а затем позволяет пере- мещаться по архиву, как по обычному дереву каталогов, с помощью команд Is, cd и pwd. Найдя файл, который нужно восстановить, выполните команду add имя_файла. Когда все необходимые файлы выбраны, скопируйте их с ленты командой extract. Ш Команда mt описана в разделе 10.7. Если на одной ленте находится много архивов, то перед выполнением команды restore необходимо перемотать ленту на соответствующий архив с помощью команды mt. Не забудьте выбрать файл устройства без режима обратной перемотки! Например, для восстановления файла /users/janet/iamlost с удаленного лен- точного накопителя необходимо задать показанную ниже последовательность команд. Предполагается, что нужная лента найдена и смонтирована в точке tapehost:/dev/ ns to, а файловая система, содержащая начальный каталог пользователя janet, — чет- вертая на ленте. # mkdir /var/restore # cd /var/restore $ sudo mkdir /var/restore $ cd /var/restore $ sudo ssh tapehost mt -f /dev/nstO fsf 3 $ sudo restore -i -f tapehost:/dev/nstO restore> Is janet/ garth/ lost+found/ lynda/ restore> cd janet restore> Is afile bfile cfile iamlost restore> add iamlost restore> Is10 afile bfile cfile iamlost* restore> extract You have not read any volumes yet. Unless you know which volume your files are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for ’.'? [yn] n Ленточные тома нумеруются с единицы, а не с нуля, поэтому для архива, который умещается на одной ленте, нужно указать значение 1. Спрашивая, следует ли задать имя владельца и режим доступа, команда restore “интересуется”, должен ли текущий ката- лог соответствовать корневому каталогу ленты. Обычно в этом нет необходимости, если только не восстанавливается вся файловая система целиком. После того как команда restore завершит работу, передайте извлеченный файл пользователю janet. 10 Звездочка рядом с именем iamlost означает, что этот файл помечен для восстановления.
Глава 10. Резервное копирование 361 $ cd /var/restore $ Is janet iamlost $ Is *janet afile bfile cfile $ sudo cp -p janet/iamlost -janet/iamlost. restored $ sudo chown janet -janet/iamlost.restored $ sudo chgrp staff -janet/iamlost.restored $ cd /; sudo rm -rf /var/restore $ mail janet Your file iamlost has been restored as requested and has been placed in /users/janet/iamlost.restored. Your name, Humble System Administrator Некоторые администраторы восстанавливают файлы в специальный каталог и дают пользователям возможность самостоятельно копировать их в свои каталоги. В этом слу- чае необходимо обеспечить защиту файлов, назначив им соответствующих владельцев и нужные права доступа. Не забывайте очищать этот каталог, чтобы файлы не “засоряли” систему. Если вы сначала сохранили резервную копию на удаленном ленточном накопителе и не можете из нее восстановить файлы локально, попробуйте читать ленту на том же удаленном компьютере, где она записывалась. Команда restore -i — самый простой способ восстановления нескольких файлов или каталогов из архива. Но она не будет работать, если ленту нельзя перематывать по одной записи назад (такая проблема существует у некоторых накопителей на 8-милли- метровых лентах). В таком случае попробуйте использовать команду restore -х. Она требует указания полного имени восстанавливаемого файла (относительно корневого каталога архива) в командной строке. Следующая группа команд повторяет показанный выше пример. $ sudo mkdir /var/restore $ cd /var/restore $ sudo ssh tapehost mt -f /dev/nstO fsf 3 $ sudo restore -x -f tapehost:/dev/nstO ./janet/iamlost Восстановление файловых систем Есть счастливчики, которым никогда не приходилось после серьезного сбоя восста- навливать всю файловую систему. Другим везет меньше. Прежде чем пытаться восста- навливать файловую систему, убедитесь, что проблема, которая привела к ее разруше- нию, устранена. Глупо часами перематывать ленты лишь для того, чтобы тут же потерять файловую систему еще раз. Перед началом процедуры восстановления нужно создать и смонтировать целевую файловую систему. О том, как это делается, подробно рассказывалось в главе 8. Далее перейдите в каталог монтирования новой файловой системы, вставьте в накопитель пер- вую ленту самого последнего архива нулевого уровня и введите restore -г. Команда restore будет сама подсказывать, когда нужно вставить следующую ленту. Восстановив архив нулевого уровня, повторяйте процедуру для инкрементных архивов в том порядке, в каком они создавались. Поскольку всегда существует определенная из- быточность, то, как правило, нет необходимости восстанавливать все инкрементные ар- хивы. Вот примерная последовательность действий.
362 Часть I. Основы администрирования • Шаг 1: восстановите самый последний архив нулевого уровня. • Шаг 2: восстановите тот из оставшихся архивов, у которого наименьший уровень; если на данном уровне было создано несколько архивов, восстановите новейший из них. • Шаг 3: если это оказался самый последний архив, процедуру можно считать за- вершенной. • Шаг 4: в противном случае вернитесь к шагу 2. Приведем несколько примеров архивных последовательностей. Восстанавливать нужно только те архивы, номера которых выделены полужирным шрифтом. 0 0 0 0 0 0 0 5 5 5 5 0 3 2 5 4 5 099599399599 0 3 5 9 3 5 9 Давайте проанализируем все используемые команды. Например, если последним был создан ежемесячный архив, а перед ним создавался ежегодный архив нулевого уровня (см. раздел “Умеренная схема” выше), то для восстановления файловой системы /home, находящейся в логическом томе /dev/vg01/lvol5, понадобятся следующие команды. $ sudo mkfs /dev/vg01/lvo!5 $ sudo mount /dev/vg01/lvol5 /home $ cd /home /* Монтируем первую ленту архива уровня 0 для каталога /home. * / $ sudo restore -г /* Монтируем ленты, запрашиваемые командой restore. */ /* Монтируем первую ленту ежемесячного архива уровня 3. */ $ sudo restore -г Если на одной резервной ленте находится несколько файловых систем, то перед об- ращением к команде restore необходимо с помощью команды mt перемотать ленту на нужную файловую систему. Команда mt описана в разделе 10.7. Приведенная последовательность команд позволит восстановить файловую систему в том состоянии, в котором она находилась, когда был создан архив третьего уровня, с одной особенностью: заодно будут “воскрешены” все удаленные с тех пор файлы. Эта проблема особенно неприятна, когда восстанавливается активная файловая система или диск практически заполнен. Не исключено, что во втором случае команда restore за- вершится неудачно11. Восстановление системы на новом оборудовании При отказе всей системы вы должны выполнить то, что называется “восстановлени- ем системы с нуля”. Прежде чем выполнить описанные выше пошаговые действия по восстановлению файловой системы, вам, как минимум, необходимо сделать следующее: • обеспечить оборудование замены; • инсталлировать свежую копию операционной системы; • инсталлировать утилиты резервирования (такие, как dump и restore); 11 Говорят, что некоторые версии команд dung? и restore отслеживают “судьбу” удаляемых файлов. Будем надеяться, что это справедливо и для систем Solaris и Linux.
Глава 10. Резервное копирование 363 • сконфигурировать локальное ленточное устройство или доступ к ленточному сер- веру. После этого можно переходить к процессу восстановления. 10.5. Архивирование и восстановление при МОДИФИКАЦИИ ОПЕРАЦИОННОЙ СИСТЕМЫ В процессе обновления операционной системы необходимо путем создания архива нулевого уровня получить резервные копии всех файловых систем, причем иногда их приходится сразу восстанавливать. Последнее требуется лишь в том случае, если в но- вой ОС используется другой формат файловой системы или изменяется структура раз- делов диска. В то же время резервное копирование нужно обязательно предусматривать как меру предосторожности на случай проблем, которые могут возникнуть в процессе модификации. Кроме того, наличие полного комплекта резервных копий даст возмож- ность переинсталлировать старую операционную систему, если новая версия не подой- дет. К счастью, благодаря применению систем последовательного обновления, исполь- зуемых в большинстве современных дистрибутивов, эти ленты вряд ли потребуются. Не забудьте сделать резервную копию всей системы и разделов пользователей. В за- висимости от вашего пути обновления, вы можете выбрать восстановление только поль- зовательских данных и системно-зависимых файлов, которые расположены в корневой файловой системе или в таких /usr-каталогах, как /etc/passwd, /etc/shadow или I usr/local. Это довольно трудная задача, ибо организация каталогов, принятая в UNIX, приводит к перемешиванию файлов, созданных на компьютере, с файлами, входящими в системный дистрибутив. Сразу после завершения модификации нужно еще раз создать полный набор архивов нулевого уровня. Процедуры модернизации, принятые в большинстве операционных систем, предполагают установку даты модификации системных файлов по времени их создания производителем системы, а не по текущему времени. Это означает, что в слу- чае сбоя инкрементные архивы, которые были созданы относительно архива нулевого уровня, записанного до модернизации, окажутся недостаточными для восстановления системы в модернизированном состоянии. 10.6. Другие архиваторы Команда dump является наиболее эффективным средством архивирования файловых систем, хотя это не единственная команда, которую можно использовать для записи файлов на ленты. Команды tar и dd тоже умеют перемещать файлы с одного носителя на другой. Команда tar: упаковка файлов Команда tar объединяет несколько файлов или каталогов в один файл, часто запи- сываемый прямо на ленту. Это удобный инструмент создания резервных копий файлов, которые предполагается восстанавливать в ближайшем будущем. Например, если у вас есть несколько старых файлов, а в системе мало места на диске, вы можете воспользо- ваться командой tar и перенести эти файлы на ленту, после чего удалить их с диска. Команда tar хорошо подходит для перемещения дерева каталогов, особенно если файлы копируются от имени пользователя root. Команда tar сохраняет информацию о
364 Часть I. Основы администрирования принадлежности объектов и времени их создания, но только если это указано в ее пара- метрах. Например, команда sudo tar -cf - исходный_каталог | ( cd целевой_каталог ; sudo tar -xpf - ) создает копию дерева исходного каталога в целевом каталоге. В аргументе целевой_ каталог следует избегать использования символов “.. ”, поскольку символьные ссылки и команды автоматического монтирования могут трактовать эту последовательность не- сколько иначе. Нам доводилось сталкиваться с подобной ситуацией. По умолчанию большинство версий команды tar не выполняет интерпретацию символьных ссылок, но может делать это по указанию. Имеет смысл обратиться к man- странице этой команды, чтобы уточнить использование флага, который изменяется при переходе от системы к системе. Самый большой недостаток команды tar состоит в том, что ее версии, не соответствующие лицензии GNU, не позволяют использовать несколь- ко ленточных томов. Если данные, которые вы хотите архивировать, не помещаются на одной ленте, вам, возможно, нужно обновить свою версию команды tar. Для некоторых версий команды tar (не GNU) характерна еще одна проблема: длина имени файла по умолчанию ограничена 100 символами. Это не позволяет использовать команду для архивирования глубоких иерархий каталогов. Если в Linux создаются tar- архивы, которыми предполагается делиться с пользователями других систем, помните о том, что обладатели стандартной команды tar могут не суметь прочитать их12. Опция -Ь команды tar позволяет задать коэффициент объединения блоков, кото- рый должен учитываться при записи информации на ленту. Этот коэффициент указыва- ется в виде числа 512-байтовых фрагментов и определяет, какой объем данных команда помещает во внутренний буфер перед выполнением записи. Некоторые DAT-устройства начинают работать некорректно, если используется нестандартный коэффициент объе- динения, тогда как другие накопители его игнорируют. В ряде систем при определенных значениях коэффициента объединения блоков про- изводительность работы с лентой повышается. Оптимальный коэффициент зависит от конкретного компьютера и ленточного накопителя, хотя во многих случаях разница в быстродействии незаметна. Если есть сомнения, задайте коэффициент 20. Команда tar заполняет “дыры” в файлах и плохо справляется с наличием ошибок на лентах13. Команда dd: манипулирование битами Команда dd предназначена для копирования и преобразования файлов. При отсут- ствии иных указаний команда просто копирует информацию из входного файла в вы- ходной. Если пользователь принес ленту, которая была записана не в UNIX, использова- ние команды dd может оказаться единственным способом ее прочитать. Одним из первоначальных применений команды dd было создание копии всей фай- ловой системы. Сегодня есть более эффективный вариант: создать с помощью команды mkf s целевую файловую систему, а затем выполнить команду dump, соединив ее кана- лом с командой restore. При неправильном использовании команда dd может иска- жать информацию о структуре разделов. Она копирует файловые системы только между разделами одинакового размера. 12 GNU-реализация в качестве одного из файлов архива включает таблицу привязки файлов по их именам. Пользователи стандартной команды tar могут извлечь содержимое архива и восстано- вить его вручную, но, конечно, этот процесс довольно утомительный. 13 GNU-версия команды tar обрабатывает “дыры” только в том случае, если при создании ис- ходного архива была указана опция -S.
Главою. Резервное копирование 365 Команду dd можно также применять для создания копий магнитных лент. При нали- чии двух ленточных накопителей (к примеру, /dev/stO и /dev/stl) используйте сле- дующую команду. $ dd if=/dev/stO of=/dev/stl cbs=16b Если есть только один накопитель (/dev/stO), введите такую последовательность. $ dd if=/dev/stO of=tfile cbs=16b /* Меняем ленты */ $ dd if=tfile of=/dev/stO cbs=16b $ rm tfile Конечно, когда имеется всего один накопитель, на диске должно быть достаточно места для сохранения образа ленты. Команда dd также является популярным инструментом у судебных специалистов. По- скольку команда dd создает побитовую (подлинную) копию тома, ее можно использо- вать для дублирования свидетельских показаний с последующим применением в суде. Резервирование файловых систем ZFS Ш Общее представление о файловых системах ZFS можно получить в разделе 8.10. Файловая система ZFS, первоначально разработанная для Solaris, включает инте- грированные средства управления логическими томами и может функционировать как RAID-контроллер. Во многих отношениях это мечта системного администратора, но ре- зервирование представляет собой некоторую смесь. ZFS упрощает создание снимков файловой системы. Старые версии файловой си- стемы доступны через каталог . zfs, расположенный в корневом каталоге, поэтому пользователи могут легко восстанавливать собственные файлы из прошлых снимков без участия администратора. С точки зрения оперативного управления версиями ZFS заслу- живает “золотой звезды”. Однако снимки, сохраняемые на том же носителе в качестве активной файловой си- стемы, не должны быть вашей единственной стратегией резервирования. Это мнение “разделяет” и ZFS: она включает прекрасное средство zfs send, которое переводит снимок файловой системы в линейный поток. Вы можете сохранить этот поток в файле или перенаправить его в удаленную систему. Этот поток можно записать на магнитную ленту. Вы можете даже переслать этот поток в удаленный процесс zfs receive, чтобы реплицировать файловую систему на другом компьютере (даже со всеми ее снимками и предысторией состояний системы). При желании процесс zfs send может выделить между двумя снимками лишь инкрементные изменения. За эту функцию мы даем еще одну золотую звезду”, а еще одну — за то, что полная документация ZFS занимает только одну-две страницы (см. man-страницу для zfs). Нельзя не сказать и о ложке дегтя в бочке меда: процесс zfs receive работает толь- ко с полными файловыми системами. Чтобы восстановить несколько файлов из набора Упорядоченных образов zfs send, придется восстановить все систему целиком, а за- тем выбрать из нее желаемые файлы. Будем надеяться, что у вас есть море времени и свободного места на диске и что данный ленточный накопитель не требуется для других Целей. Однако у нас есть аргументы, которые могут компенсировать этот недостаток. айловые системы ZFS характеризуются “легким весом”, поэтому вы можете создавать их в большом количестве. Восстановление всего содержимого из каталога /home может показаться вам тяжелым случаем, но восстановление из каталога /home/ned — вполне
366 Часть I. Основы администрирования приемлемо14. Важнее то, что оперативная ZFS-система снимков устраняет 95% случаев, в которых вам обычно приходилось обращаться к архивной ленте. Оперативные снимки системы не заменяют архивных лент или не сокращают часто- ту, с которой эти ленты должны записываться. Однако снимки действительно уменьша- ют частоту считывания этих лент. 10.7. Запись нескольких архивов на одну ленту Магнитная лента фактически содержит одну длинную строку данных. Но очень часто возникает необходимость поместить на ленту несколько архивов, поэтому ленточные накопители и их драйверы на логическом уровне реализуют более сложную структуру хранения. Когда команда dump (или ее аналог) записывает поток байтов на ленту, а за- тем закрывает файл устройства, на ленту автоматически помещается маркер конца фай- ла (EOF — end of file). Этот маркер отделяет один поток от другого. При извлечении по- тока данных чтение автоматически прекращается в случае обнаружения маркера EOF. Чтобы перемотать ленту для записи определенного потока, используется команда mt. Она очень удобна при размещении на одной ленте нескольких архивов. Кроме того, ее сообщения об ошибках — одни из самых интересных среди утилит UNIX. Базовый фор- мат команды таков. mt [-f имя_ленты] инструкция [счетчик] Аргумент инструкция может иметь множество значений. От платформы к платфор- ме они меняются, поэтому мы рассмотрим лишь те варианты, которые важны для созда- ния резервных копий и их восстановления. rew offl Перемотать ленту к началу. Перевести ленту в автономный режим. В большинстве накопителей это приводит к перемотке ленты в начало и выталкиванию ее из приемни- ка. Сценарии архивирования применяют эту инструкцию для извлече- ния ленты по окончании операции, что должно свидетельствовать об успешном ее завершении. status Вывести информацию о текущем состоянии ленточного накопителя (вставлена ли лента и т.д.). fsf [счетчик] Перемотать ленту вперед. Если аргумент счетчик отсутствует, лента перематывается на один файл. Если указан числовой аргумент, лента перематывается на соответствующее количество файлов. Эту инструк- цию можно использовать для перехода к нужной файловой системе на ленте, содержащей несколько архивов. bsf [счетчик] Перемотать ленту назад на указанное число файлов. Точная интерпре- тация инструкции зависит от типа накопителя и его драйвера. Иногда текущий файл учитывается, иногда — нет. В некоторых случаях эта ин- струкция не делает ничего (и не сообщает об этом). Если лента пере- мотана слишком далеко, лучше всего ввести инструкцию mt tew и на- чать сначала. 14 Применяя вариант zfs send -R для файловой системы /home и ее потомков, помните, что пока нет способа восстановливать только содержимое каталога /home/ned; вам придется восста- навливать все содержимое каталога /home. Как администратору, вам, вероятно, не захочется пла- нировать резервное копирование для каждого домашнего каталога.
ГлаваЮ. Резервное копирование 367 Для рзнакомления с перечнем всех поддерживаемых команд обратитесь к man-стра- нице команды mt. Те, кому повезло иметь в своем распоряжении роботизированную ленточную би- блиотеку, могут воспользоваться пакетом mtx, который представляет собой улучшенную версию команды mt и позволяет манипулировать устройством смены лент. Мы приме- няли его для автоматизированного управления лентами в библиотеке картриджей Dell PowerVault LTO-3. Устройства смены лент со считывателями штрихового кода отобража- ют даже метки магнитных лент, сканируемые с помощью mtx-интерфейса. 10.8. Программа Bacula Bacula — это программа резервного копирования систем “клиент/сервер” на уров- не организации, которая управляет резервным копированием, восстановлением и про- веркой целостности файлов по сети. Компоненты сервера Bacula работают в системах Linux, Solaris и FreeBSD. Клиентская часть программы Bacula может выполнять резерв- ное копирование других операционных систем, включая Microsoft Windows. В предыдущем издании этой книги в качестве некоммерческого средства резервного копирования мы рекомендовали использовать программу Amanda. Информацию о ней можно найти в предыдущем издании этой книги или по адресу amanda. org. Ниже приведены аргументы в пользу выбора программы Bacula. • Имеет модульную структуру. • Позволяет выполнять резервное копирование файловых систем UNDC, Linux, Windows и Mac OS. • В качестве вспомогательной системы управления базой данных поддерживает MySQL, PostgreSQL и SQLite. • Поддерживает простую в использовании, управляемую с помощью меню консоль командной строки. • Ее исходный код соответствует лицензии программного обеспечения с открытым исходным кодом. • Ее резервные копии могут быть записаны на несколько ленточных томов. • Серверы этой программы могут работать на нескольких платформах. • Для каждого копируемого файла программа может создавать сигнатуры SHA1 или MD5. • Программа позволяет шифрование как сетевого трафика, так и данных, хранимых на ленте. • Программа может копировать файлы, размер которых превышает 2 Гбайт. • Поддерживает ленточные библиотеки и устройства автоматической замены лент. • До и после выполнения задач резервного копирования может выполнять сценарии и команды. • Осуществляет централизованное управление резервным копированием для всей сети. Модель, используемая программой Bacula Для того чтобы использовать программу Bacula, необходимо понимать работу ее ос- новных компонентов. Общая архитектура системы Bacula показана на рис. 10.1.
368 Часть I. Основы администрирования Рис. 10.1. Компоненты системы Bacula и их взаимосвязь Демон управления Bacula — это демон, который координирует операции резервного копирования, восстановления и проверки. Передача заданий резервного копирования или восстановления демону управления осуществляется посредством консоли Bacula. Демон управления может также запрашивать демон хранения или демоны файловой службы, размещенные на компьютерах клиентов. Обмен данными с демоном управления выполняется посредством консоли Bacula, которая может функционировать в качестве графического интерфейса пользователя GNOME, MS Windows либо в качестве средства командной строки. Консоль может быть запущена на любом компьютере, а не только на том, где действует демон управления. Демон хранения — компонент системы Bacula, который выполняет чтение и запись лент и других носителей резервного копирования. Эта служба должна быть запущена на компьютере, к которому подключено ленточное устройство или устройство хранения, используемое для хранения резервных копий. Но ее установка на том же сервере, на ко- тором установлен демон управления, не обязательна (хотя и допускается). Демон управления файлами действует в каждой системе, файлы которой требуется копировать. Во время выполнения заданий резервного копирования реализации этого демона каждой из поддерживаемых операционных систем отправляют демону хранения данные и атрибуты соответствующих файлов. Последний компонент системы Bacula — каталог, представляющий собой реляцион- ную базу данных, в которой Bacula хранит информацию о каждом копируемом файле и томе. Он позволяет программе Bacula быстро и эффективно выполнять восстановление, поскольку ретроспективная информация о всех операциях резервного копирования до- ступна в оперативном режиме; программе известно, какие тома с резервными копиями требуются для восстановления конкретного набора файлов, еще до того, как она вы- полнит чтение хотя бы одной ленты. В настоящее время Bacula поддерживает три базы данных: MySQL, PostgreSQL и SQLite. Базе данных каталога не обязательно размещаться на том же сервере, на котором установлен демон управления. Дополнительный, необязательный, компонент — Bacula Rescue CD-ROM (аварий- ный компакт-диск Bacula). Он представляет собой отдельно загружаемый пакет, кото- рый создает индивидуальные загрузочные компакт-диски восстановления систем Linux с нуля. Эти компакт-диски содержат статически скомпонованную копию демона фай- лов системы и специальный сценарий интерпретатора с информацией о конфигурации
Глава 10. Резервное копирование 36! дисков системы, ядра и сетевых интерфейсов. При возникновении фатального сбоя си стемы Linux ее компакт-диски аварийного восстановления позволят выполнить загруз ку системы, разбиение диска на логические разделы и подключение демона управление Bacula для полного восстановления системы по сети. Настройка программы Bacula Из-за сложности программы Bacula, связанной с поддержкой расширенного набор; функций и модульной структурой, существует множество способов настройки схемы ре зервного копирования в рамках той или иной организации. В этом разделе рассмотри* основные особенности конфигурации Bacula. В общем случае для запуска системы Bacula требуется выполнение пяти шагов: • установка поддерживаемой внешней базы данных и демонов Bacula; • конфигурирование демонов Bacula; • установка и конфигурирование демонов управления файлами клиентов; • запуск демонов Bacula; • добавление носителей в пул носителей с помощью консоли Bacula; • выполнение тестового резервирования и восстановления. Мы рассмотрим минимальный вариант настройки системы, состоящей из сервера г одного или нескольких клиентов. На компьютерах-клиентах установлен только демог управления файлами. Остальные четыре компонента системы Bacula (демон управления демон хранения, каталог и консоль) действуют на сервере. В более обширных среда? рекомендуется распределять серверные Bacula-компоненты среди нескольких компью- теров, но система с минимальной конфигурацией прекрасно работает с точки зренш резервного копирования на нескольких десятках систем. Установка базы данных и демонов Bacula Важно использовать одну и ту же версию версию программы Bacula в каждой систе- ме. Раньше некоторые версии были несовместимы друг с другом. Прежде чем установить систему Bacula, необходимо установить базу данных для хра- нения ее каталога. Для узлов, выполняющих резервное копирование всего несколькю систем, база данных SQLite предоставляет самый простой вариант инсталляции. Если вы резервируете больше систем, рекомендуется использовать более масштабируемую базу данных. Наш опыт использования MySQL в этой роли был положительным, и мь предполагаем использование MySQL в следующих примерах. Стабильность и надежность — обязательные требования к платформе резервногс копирования, поэтому сразу после установки базы данных рекомендуем загрузить с веб-сайта Bacula и установить самую последнюю стабильную версию исходного кода Подробные пошаговые инструкции по установке программы приведены в каталоге docs пакета с исходным кодом. Документацию в форматах HTML и PDF можно также найти по адресу bacula. org. Там же приведены полезные учебники и руководства для раз- работчиков. После распаковки исходного кода необходимо выполнить команду • /configure —with-mysql, затем команды make для компиляции двоичных файлов и make install, чтобы за- кончить инсталляцию.
370 Часть I. Основы администрирования По завершении установки программы Bacula необходимо создать базу данных MySQL и таблицы данных внутри нее. Bacula включает три сценария интерпретатора, которые подготавливают MySQL к сохранению каталога. Сценарий grant_mysql__privileges устанавливает соответствующие MySQL-разрешения для пользователя Bacula. Сценарий create_mysql_database создает базу данных Bacula, и, наконец, сценарий make_ mysql—tables заполняет эту базу данных требуемыми таблицами. Аналогичные сцена- рии включены для баз данных PostgreSQL и SQLite. Сценарии предварительного созда- ния баз данных можно найти в каталоге src/cats дистрибутива, содержащего исходный код программы Bacula. Bacula сохраняет элемент таблицы для каждого файла, резервируемого из каждого клиента, поэтому ваш сервер базы данных должен иметь значительный объем памяти и дискового пространства. Таблицы базы данных для сети среднего размера могут лег- ко вырасти до миллионов записей. Используя MySQL, вам следует сосредоточиться, по крайней мере, на ресурсах, определенных в файле my-large.cnf, включенном в дис- трибутив. Если вы обнаружите, что ваша база данных каталога выросла так, что вот-вот может стать неуправляемой, вы всегда можете настроить второй экземпляр MySQL и ис- пользовать отдельные каталоги для различных групп клиентов. Конфигурирование демонов Bacula После настройки базы данных, предназначенной для хранения каталога, вы должны сконфигурировать еще четыре компонента Bacula. По умолчанию все файлы конфигу- рации расположены в каталоге /etc/bacula. Bacula имеет отдельный файл конфигура* ции для каждого компонента. В табл. 10.3 перечислены имена файлов и компьютеры, на которых должен находиться каждый файл конфигурации. Таблица 10.3. Имена файлов конфигурации Bacula (в каталоге /etc/bacula) Компонент Демон управления bacula-dir.conf Сервер, который запускает демон управления Демон хранения bacula-sd.conf Каждый сервер, который содержит демон хранения Демон файлов bacula-fd.conf Каждый клиент, который будет создавать архивы Консоль (пульт) управления bconsole.conf Каждый компьютер, используемый в качестве пуль- та управления Может показаться неразумной необходимость независимо конфигурировать каждый компонент программы Bacula при наличии единственного сервера, но такое модульное проектирование позволяет программе Bacula очень хорошо масштабироваться. Сервер ленточного накопителя работает на полную мощность? Добавьте второй сервер с соб- ственным демоном хранения. Хотите сбрасывать резервные копии в сторонний ком- пьютер? Инсталлируйте демон хранения на том сервере. Нужно заархивировать данные новых клиентов? Установите и сконфигурируйте демоны файлов этих клиентов. У вас появился новый администратор по вопросам резервирования? Инталлируйте консоль (пульт) управления на его (или ее) компьютере. Файлы конфигурации — это текстовые файлы, предназначенные для чтения чело- веком. Образцы файлов конфигурации, включенные в дистрибутив Bacula, хорошо до- кументированы и могут послужить прекрасной стартовой площадкой для типичной кон- фигурации.
Глава *10. Резервное копирование 371 Прежде чем приступить к подробному описанию процесса установки, необходимо дать определение ряду основных терминов, используемых в системе Bacula. • “Задания” — это фундаментальные составляющие активности программы Bacula. Существует две их разновидности: архивирование и восстановление. Здание вклю- чает такие элементы: клиент, набор файлов, пул памяти и схему. • “Пулы” — это группы физических носителей, на которых хранятся задания. Напри- мер, мы будем использовать два пула — для полных архивов и для инкрементных. • “Наборы файлов” — это списки файловых систем и отдельных файлов. Наборы файлов могут быть явно включены в задания архивирования или восстановления либо исключены из них. • “Сообщения” — это информация о состоянии демонов и заданий (фактически журнальные записи), которой обмениваются демоны. Они могут также переда- ваться по электронной почте или записываться в файлы журналов. Мы не будем рассматривать все возможные параметры конфигурирования. Вместо этого в начале каждого раздела приведем общий обзор файла конфигурации, а затем подробнее остановимся на некоторых параметрах, которые, по нашему мнению, наи- более полезны или трудны для понимания. Разделы конфигурации Файлы конфигурации Bacula состоят из разделов, обычно именуемых “ресурсами”. Раздел каждого ресурса заключен в фигурные скобки. Некоторые ресурсы входят в не- сколько файлов конфигурации. Во всех файлах конфигурирования программы Bacula комментарии начинаются с символа #. Все четыре файла конфигурации содержат ресурс Director. # Пример файла конфигурации демона управления Bacula, /etc/bacula-dir.conf Director { Name = bull-dir # a canonical name for our Bacula director DIRport = 9101 Query File = ’’/etc/bacula/query.sql” Working Directory = "/var/Bacula/working" Pid Directory = ”/var/run” Maximum Concurrent Jobs = 1 Password = "zHpScUnHN9" Messages = Standard } Ресурс Director фактически служит истоком всех компонентов Bacula. Его параме- тры определяют имя и основы поведения демона управления. Они определяют комму- никационный порт, через который остальные демоны осуществляют обмен данными с демоном управления, каталог, в котором он хранит свои временные файлы, и количе- ство заданий, которые демон управления может выполнять. Пароли разбросаны по всем файлам конфигурации Bacula, и все они имеют разные Цели. На рис. 10.2 показано, как должны соотноситься пароли на разных компьютерах в Разных файлах конфигурации. Несмотря на то что пароли записываются в файлах конфигурации открытым (неза- ифрованным) текстом, они никогда не передаются по сети в такой форме. данном примере и демон управления, и консоль расположены на одном компьюте- ем не менее пароль должен присутствовать в обоих файлах конфигурации.
372 Часть I. Основы администрирования Рис. 10.2. Пароли в файлах конфигурации Bacula Все демоны управления, Хранения и файлов имеют ресурс Messages, который со- общает программе Bacula, как обрабатывать специальные типы сообщений, сгенериро- ванные каждым Bacula-демоном. В типичной конфигурации демоны хранения и файлов отправляют свои сообщения демону управления. Messages { Name = Standard director = bull-dir = all } В файле конфигурации демона управления ресурс Messages более сложный. Сле- дующий код предписывает программе Bacula сохранять сообщения в журнале регистра- ции и отправлять их по электронной почте. Messages { Name = Standard mailcommand = "/sbin/bsmtp -h localhost -f "(Bacula) bacula@admin.com" -s V’Bacula: %t %e of %c %1" %r” operatorcommand = "/sbin/bsmtp -h localhost -f "(Bacula) bacula@admin.com" -s V'Bacula: Intervention needed for %j” %r" mail - backups-admins@admin.com - all, ! skipped operator = backups-tapeadmins@admin.com = mount console = all, ! skipped, !saved append = "/var/log/bacula.log" ~ all, !skipped } Вы можете определить несколько ресурсов Messages для демона управления, а затем назначить их на специальные задания в ресурсах Job. Этот тип ресурса характеризуется перестраиваемой конфигурацией; полный список переменных и команд можно найти во встроенной оперативно доступной документации. Конфигурирование демона управления: файл bacula-dir.conf Файл bacula-dir.conf — самый сложный файл конфигурации Bacula. Помимо описанных выше ресурсов Director и Messages, он требует минимум семь типов опре-
Глава 10. Резервное копирование 373 делений ресурсов: Catalog, Storage, Pool, Schedule, Client, FileSet и Job. Здесь мы проиллюстрируем определение каждого ресурса небольшим примером, но вы начи- найте создание собственных файлов конфигурации с редактирования файлов-образцов, включенных в состав Bacula. Ресурсы каталогов Ресурс Catalog указывает программе Bacula на базу данных конкретного каталога. Он включает имя каталога (чтобы вы могли определить несколько каталогов), имя базы данных и мандат базы данных. Catalog { Name = MYSQL dbname = "bacula"; dbuser = "bacula"; cibpassword = "9p6NLm6CnQ" } Ресурсы хранения Ресурс Storage описывает, как общаться с конкретным демоном хранения, который в свою очередь несет ответственность за согласование с его локальными устройствами резервирования. Ресурсы хранения являются аппаратно-независимыми; демон хране- ния имеет собственный файл конфигурации, который описывает оборудование более детально. Storage { Name = TL4000 Address = bull SDPort = 9103 Password = "jiKkrZuEOO" Device = TL4000 Autochanger = yes Maximum Concurrent Jobs = 2 Media Type - LTO-3 > Ресурсы накопителей Ресурс Pool группирует устройства резервирования (обычно это ленты) в наборы, которые используются специальными заданиями резервирования. Эта операция может быть полезной для отделения лент, которые служат для стороннего хранения архивов, от лент, которые используются для еженощных инкрементных архивов. Каждый нако- питель назначается одному ресурсу Pool, поэтому нетрудно обеспечить автоматическую рециркуляцию лент разных наборов. Pool { Name = Full_Pool Pool Type = Backup Recycle - yes AutoPrune = yes Storage = TL4000 Volume Retention =365 days } Ресурсы схем резервирования -3 * Ресурсы Shedule определяют временные таблицы (расписания) заданий архивирова- ния. Обязательными являются только параметры, задающие имя, дату и время, но, как
374 Часть I. Основы администрирования видно из следующего примера, вы можете вставлять дополнительные значения. Эти зна- чения переопределяют стандартные параметры, указанные в спецификации ресурса Job. В данном случае полные архивирования выполняются в 20:10 по первым вторникам каждого месяца, а инкрементные архивирования (использующие другой ленточный на- копитель) — еженедельно в 20:10 во все дни с четверга по понедельник. Schedule { Name = "Nightly” Run = Level=Full Pool=FullPool 1st tue at 20:10 Run = Level=Incremental Pool=IncrementalPool wed-mon at 20:10 } Ресурсы клиентов Ресурсы Client определяют компьютеры, файлы которых должны быть архивиро- ваны. Каждый ресурс имеет уникальное имя, IP-адрес и пароль. Для каждого клиента требуется отдельный ресурс. Также необходимо указать каталог для сохранения мета- данных резервирования. Параметры File Retention и Job Retention определяют длительность хранения в каталоге записей файлов и заданий для данного клиента. Если параметр AutoPrune установлен, дата истечения срока хранения удаляется из каталога. Эта опция влияет только на записи в каталоге, но не реальные файлы, хранящиеся на архивных лентах. Рециркуляция лент конфигурируется в ресурсе Pool. Client { Name = harp Address = 192.168.1.28 FDPort = 9102 Catalog = MYSQL Password = "TbEpJqrcqy” } Ресурсы файловых наборов Ресурс FilSet определяет файлы и каталоги, которые должны быть либо включены в задания архивирования, либо исключены из них. Если у вас нет систем с идентичны- ми схемами разбиения, вам, скорее всего, для каждого клиента необходимо использо- вать свой файловый набор. Ресурсы могут определять несколько параметров Include и Exclude и индивидуальные параметры Options, задаваемые в виде регулярных выраже- ний. По умолчанию программа Bacula рекурсивно архивирует каталоги, но не включает в задание архивирования несколько логических разделов. Все логические разделы, кото- рые нужно архивировать, должны быть указаны в отдельном параметре File. В приведенном ниже примере используем такие дополнительные параметры, как compression (для сжатия данных перед их записью на ленту) и signature (для вычис- ления хеш-значения для каждого архивируемой файла). Эти параметры увеличивают загрузку процессора во время архивирования, но могут сэкономить емкость накопите- лей или при возникновении подозрения о нарушении безопасности позволяют иденти- фицировать файлы, которые были модифицированы. FileSet { Name = ’’harp" Include { Options { signature^SHAl compression=GZIP
Гвава Ю. Резервное копирование 375 } File = ”/” File = ’’/boot" File = "/var" } Exclude = { /proc /tmp /.journal /.fsck } } Ресурсы заданий Ресурс Job определяет предельные характеристики конкретного задания архивиро- вания посредством связывания воедино ресурсов Client, FileSet, Storage, Pool и Schedule. В общем случае для каждого клиента создается одно определение Job, хотя вы можете легко установить несколько заданий, если хотите архивировать различные файловые наборы (ресурсы FileSets) с различной частотой. При желании для установки стандартных значений параметров для всех заданий ар- хивирования можно предоставить ресурс JobDef s. Использование этого ресурса позво- лит упростить данные конфигурации, относящиеся к каждому заданию. Job { Name = "Harp" JobDefs = Defaultjob Level = Full Write Bootstrap = "/bacula/bootstraps/harp.bsr" Client = harp FileSet' ® harp Pool =* FuM^pol Increiaental*Sackup Pool = Incremental_Pool Schedule = "Nightly" Prefer Mounted Volumes = no Max Run Time = 36QQQ } Файл “самозагрузки” — это специальный текстовый файл (создаваемый програм- мой Bacula), который содержит информацию о файлах, подлежащих восстановлению. Список файлов начальной загрузки содержит перечень файлов и томов, которые требу- ются для выполнения задания восстановления и чрезвычайно полезны для восстановле- ния системы с нуля. Наличие этих файлов начальной загрузки не обязательно, но весьма желательно. Файлы “самозагрузки” создаются во время операций восстановления или резервиро- вания, если вы определили параметр Write Bootstrap для данного задания. Параметр Write Bootstrap указывает программе Bacula, куда записывать информацию о началь- ной загрузке, которая будет использована во время восстановления. Файлы “самоза- грузки” перезаписываются в процессе полного архивирования и дописываются во время инкрементного архивирования. Конфигурирование демона хранения: файл bacula-sd.conf Демоны хранения принимают данные от демонов управления файлами и переда- ют их на реальный носитель хранения (и в обратном направлении при восстановле- нии). В файле bacula-sd.conf необходимо определить ресурсы Storage, Device и Autochanger, не говоря уже о ресурсах Messages и Director. Ниже приведен полный пример файла конфигурации.
376 Часть I. Основы администрирования Ресурс Director Ресурс Director управляет тем, какие управляющие устройства разрешены для кон- такта с демоном хранения. Пароль в ресурсе Storage файла bacula-dir. conf должен соответствовать паролю в ресурсе Director файла bacula-sd. conf. Director { Name = bull-dir Password = "jiKkrZuEOO" } Ресурсы Storage Ресурс Storage сравнительно прост. Он определяет ряд основных рабочих параме- тров, таких как сетевой порт демона и рабочий каталог. Storage { Name = bull-sd SDPort = 9103 WorkingDirectory = "/var/bacula/working” Pid Directory = "/var/run” Maximum Concurrent Jobs = 2 } Ресурсы Device Каждое устройство архивирования получает собственное определение ресурса Device. Этот ресурс характеризует физическое устройство архивирования, будь то магнитная лен- та, оптический накопитель или оперативная память. В состав характеристик входит тип устройства, производительность и данные о механизме автоматической смены носителя для устройств, которые управляются таким механизмом смены или роботом. В приведенном ниже примере определяется накопитель LTO-3 (Linear Tape-Open) с автоматической сменой лент. Обратите внимание на то, что файл устройства /dev/nstO соответствует устройству без перемотки, которое требуется практически во всех ситуа- циях. Параметр Name определяет символическое имя, которое используется для связы- вания накопителя с соответствующим ресурсом Autochanger. Параметр Name также по- зволяет запомнить, какую единицу оборудования описывает данный ресурс. Параметр AlwaysOpen указывает о необходимости сохранения устройства в открытом состоянии, если только администратор специально не потребует его размонтирования. Этот параметр экономит время и уберегает ленту от дополнительных нагрузок, посколь- ку исключает выполнение команд перемотки и позиционирования между заданиями. Device { Name = TL4000-Drive0 Media Type = LTO-3 Archive Device = /dev/nstO AutomaticMount = yes AlwaysOpen = yes RemovableMedia = yes RandomAccess = no Autochanger = yes }
Глава 10. Резервное копирование ресурсы Autochanger Необязательное определение ресурса Autochanger требуется только в случае, если вы — счастливый обладатель механизма смены носителя. Он связывает устройства хра- нения данных с механизмом автоматической смены носителя и определяет команду, ко- торая обеспечивает смену лент. Autochanger { Name = TL4000 Device = TL4000-Drive0,TL4000-Drivel Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/changer } Конфигурирование консоли: файл bconsole.conf Программа консоли служит для обмена данными с демоном управления при плани- ровании заданий, проверки их состояния или восстановления данных. Файл bconsole. conf указывает консоли, как следует осуществлять обмен данными с демоном управле- ния Bacula. Параметры в этом файле должны соответствовать параметрам, определен- ным в ресурсе Director файла конфигурации демона управления (bacula-dir.conf), за исключением параметра Address. # Файл конфигурации консоли, bconsole.conf Director { Name = bull-dir DIRport = 9101 Address = bull Password = "zHpScUnHN9" } Установка и конфигурирование демона управления файлами клиента Демон управления файлами клиентов архивирования обменивается данными с де- моном хранения во время выполнения заданий архивирования и восстановления. Он должен быть установлен и сконфигурирован на каждом компьютере, файлы которого нужно архивировать с помощью программы Bacula. Программа Bacula распространяется в двоичной форме и подходит для многих плат- форм, включая Windows и различные версии Linux. В системах UNIX установку демона можно выполнить, копируя исходное дерево Bacula на каждый компьютер клиента и вы- полняя команду . /configure —enable-client-only. Затем необходимо выполнить команды make и make install. Вы можете жестко закодировать стандартные значения Для многих параметров демона файлов во время конфигурации, но поддержка будет легче, если вы просто перечислите их в своем файле bacula-fd. conf. По умолчанию Двоичные файлы инсталлируются в каталог /sbin, а файлы конфигурации — в каталог / etc /bacula. После установки демона файлов сконфигурируйте его, отредактировав файл bacula- fd. conf, который разделен на три части. Первая часть включает ресурс Director, ко- торый сообщает демону файлов, какое устройство управления разрешается использо- вать для планирования операций архивирования для данного клиента. Ресурс Director также включает параметр Password, который должен совпадать с паролем, указанным
378 Часть I. Основы администрирования в ресурсе Client собственного файла конфигурации демона управления. Вторая часть файла bacula-fd. conf представляет собой ресурс FileDaemon, который определяет имена клиентов и задает порт, прослушиваемый демоном управления файлами на пред- мет команд от демона управления. Последний компонент программы — ресурс Messages (см. раздел “Разделы конфи- гурации” выше в этой главе), который определяет, как должны быть обработаны локаль- ные сообщения. Запуск демонов Bacula После того как демоны сервера установлены, а клиент сконфигурирован, необходи- мо запустить демоны с помощью сценария запуска, размещенного в каталоге установки сервера (. /bacula start). Эта же команда используется на каждом клиентском ком- пьютере для запуска демона управления файлами. Сценарий запуска программы bacula должен быть сконфигурирован для выполне- ния во время начальной загрузки. Может ли это быть сделано за вас или нет — зависит от вашей системы и метода инсталляции. О том, как запускать службы во время загруз- ки системы, показано на примерах систем в главе 3. После того как демоны Bacula запущены, программу консоли (bconsole в каталоге установки) можно использовать для проверки их состояния, добавления носителей в пулы и для выполнения заданий архивирования и восстановления. Программу bconsole мож- но запускать с любого компьютера, если она корректно установлена и сконфигурирована. $ sudo ./bconsole Connecting to Director bull:9101 1000 OK: bull-dir Version: 2.4.4 (23 December 2009) Enter a period to cancel a command. Для ознакомления с полным списком поддерживаемых ею команд используйте ко- манду help консоли. Добавление носителей в пулы Прежде чем выполнять задания архивирования, необходимо пометить ленту и вклю- чить ее в пулы носителей, определенные в файле конфигурации демона управления. Чтобы записать программную “метку” на пустую ленту и назначить ее пулу Bacula, не- обходимо использовать команду label консоли. Всегда сопоставляйте свою метку Bacula с физической меткой на вашей ленте. Если у вас есть механизм автоматической смены носителя, который поддерживает штрихко- ды, вы можете использовать команду label barcode, чтобы автоматически помечать любые пустые ленты читабельными значениями с их этикеток со штриховым кодом. Для проверки того, что лента была добавлена в нужный пул и помечена как допу- скающая добавление данных, следует использовать команду list media. Выполнение архивирования вручную Чтобы выполнить архивирование вручную, необходимо использовать команду run консоли. Эта команда не требует никаких аргументов. При ее выполнении консоль ото- бражает все задания, определенные в файле конфигурации демона управления. Любые па- раметры команды run можно изменять, следуя подсказкам, подобным меню, на консоли.
Глава 10. Резервное копирование 379 Приведенный ниже пример демонстрирует выполнение вручную полной архивации файлов сервера harp с использованием стандартных параметров, указанных в файлах конфигурации. * run harp Run Backup job JobName: harp Level: Full Client: harp FileSet: harp Pool: FullPool Storage: SureStore When: 2009-10-08 10:56:41 Priority: 10 OK to run? (yes/mod/no): yes Run command submitted. После успешной передачи задания архивирования демону управления его состояние можно отслеживать с помощью команды status консоли. Для систематичного получе- ния информации обо всех обновлениях при ее поступлении можно использовать также команду messages консоли. В зависимости от настройки ресурсов Messages системы, подробный итоговый отчет может отправляться также администратору системы Bacula. Выполнение задания восстановления Для того чтобы восстановить файлы, необходимо запустить консоль и выполнить ко- манду restore. Как и команда run, команда restore выбирается из меню. Ее выпол- нение начинается с вывода информации о том, какие задания должны быть прочитаны для восстановления целевых файлов. Команда restore предоставляет несколько ме- тодов указания необжщимых идентификаторов заданий. После того как набор заданий выбран, из них можно файяы, которые нужно восстановить. * restore То select the Joblds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of coima separated Joblds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Find the Joblds of the most recent backup for a client 10: Find the Joblds for a backup for a client before a specified time 11: Enter a list of directories to restore for found Joblds 12: Cancel Select item: (1-12): Вероятно, три наиболее полезных запроса — “Select the most recent backup for a client” (Выберите самую последнюю резервную копию клиента) (№5), “Select backup for a client before a specified time” (Выберите резервную копию клиента до заданного времени) (#6) и “List Jobs where a given File is saved” (Перечислите задания, содержащие данный файл) (№2). Первые две опции предоставляют оболочку для выбранных файлов, по аналогии с командой restore -х. Последняя опция пригодится тем рассеянным пользователям, которые не в состоянии запомнить точное местонахождение случайно удаленного фай-
380 Часть I. Основы администрирования ла. Еще одна полезная команда — опция №4, “Enter SQL list command” (Введите SQL- команду), которая позволяет вводить любой надлежащим образом сформатированный SQL-запрос. С помощью этой опции можно находить идентификаторы заданий. (Безу- словно, вам должна быть известна логическая структура используемой базы данных.) Предположим, что пользователю необходимо скопировать свой восстановленный сценарий pw_expire.pl. Однако он не помнит, в каком именно каталоге хранился этот файл. Кроме того, пользователю желательно восстановить файлы в каталог /tmp на ис- ходном компьютере. Многих системных администраторов подобный запрос может по- вергнуть в шоковое состояние, но для администратора Bacula выполнение этой задачи не представляет никакой сложности. (К сожалению, формат вывода результатов поис- ка, используемый программой Bacula, столь подробен, что нам пришлось максимально уменьшить масштаб выводимой информации.) * restore То select the Joblds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved Select item: (1-12) : 2 Defined Clients: 1: bull 2: harp Select the Client (1-12): 2 Enter Filename (no path): pw_expire.pl I Jobld | Name I StartTime | JobType... +-------+-------------------------------------+----------------------+-------- I 4484 | /home/jim/development/pw_expire.pl | 2009-11-03 20:11:35 | B... I 4251 | /home/jim/development/pw_expire.pl | 2009-10-21 18:03:01 | B... I 4006 | /home/jim/development/pw_expire.pl | 2009-10-06 20:10:02 | B... +-------+-------------------------------------------------+------------------- Из списка экземпляров файла pw_expire.pl, созданного программой Bacula, мы видим несколько недавних резервных копий и соответствующие им идентификаторы за- даний. Затем программа Bacula возвращает нас к меню восстановления, где можно ис- пользовать опцию №3 (“Enter job IDs” (Введите идентификаторы заданий)), чтобы вы- брать нужное задание. Select item: (1-12) : 3 Enter Jobld(s) , comma separated, to restore: 4484 You have selected the following Jobld: 4484 Building directory tree for Jobld 4484 ... 1 Job, 779, 470 files You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $ cd /home/jim/development cwd is: /home/jim/development $ dir -rwxr-xr-x 1 jim atrust 923 2009-10-25 12:05:43 /home/jim/development/pw_exp...
Глава 10. Резервное копирование 381 $ mark pw_expire.pl 1 files marked. $ done Хотя в этом примере и не показано, но иногда программа Bacula отображает иденти- фикационные номера заданий с запятой (4,484). Вы должны опускать запятую при по- вторном вводе. В противном случае программа интерпретировала бы это значение как список идентификаторов заданий, разделенных запятыми. Bootstrap records written to /var/bacula/working/restore.bsr The restore job will require the following Volumes: 000879L3 1 file selected to be restored. Defined Clients: 1: bull 2: harp Select the Client (1-2) : 2 Затем программа записывает файл начальной загрузки, который она будет использо- вать для выполнения восстановления, отображает имена необходимых ей ленточных то- мов и предлагает выбрать клиентский компьютер, на котором нужно восстановить фай- лы. В данном примере восстановление было выполнено на исходном компьютере harp. Run Restore Job JobName: RestoreFiles Bootstrap: /bacula/bacula/working/jf-dir.restore.4.bsr Where: /var/restore Replace: always FileSet: Full Set Backup Client: harp Restore Client: harp Storage2 ЬТОЗгТыиМЮ When: 2009-11-23 15:13:05 Catalog: MYSQL Priority: 10 OK to run? (yes/mod/no) : Перед выполнением данного конкретного задания мы хотим изменить параметры, заданные по умолчанию. В частности, в соответствии с пожеланием пользователя нам нужно изменить место назначения этого восстановления на /Ьпр. OK to run? (yes/mod/no) : mod Parameters to modify: 1: Level 2: Storage 3: Job 4: FileSet 5: Restore Client 6: When 7: Priority 8: Bootstrap 9: Where 10: File Relocation 11: Replace 12: Jobld Select parameter to modify (1-12): 9
382 Часть I. Основы администрирования Please enter path prefix for restore (/ for none): /trap Run Restore job JobName: RestoreFiles Bootstrap: /var/Bacula/working/restore.bsr Where: /tmp , g OK to run? (yes/mod/no) : yes Run command submitted. Restore command done. После внесения изменений мы передаем задание демону управления, который его выполняет. Затем можно воспользоваться командой messages для просмотра журнала выполнения задания. Архивирование клиентов Windows Вы можете загрузить предварительно созданные двоичные файлы для клиентов Win- dows из файла bacula. org. Программа Bacula прекрасно справляется с резервировани- ем Windows-файлов данных, но ей приходится выполнить дополнительное действие для создания надежной копии системы Windows уровня 0. К сожалению, программа Bacula не имеет никакого понятия о системном реестре Windows или состоянии системы; она также не понимает блокирования открытых файлов в Windows. Как минимум, вам сле- дует сконфигурировать сценарий предварительного выполнения, который бы запускал встроенную в Windows функцию восстановления системы (System Restore). Эта функция создает локальную копию состояния системы, а программа Bacula затем получит теку- щее состояние системы в заархивированной форме. Чтобы корректно собрать забло- кированные файлы, вам, возможно, стоит использовать Windows-службу фонового ко- пирования тома (Volume Shadow Copy Service — VSS). Просмотрите каталог examples в исходном дереве программы Bacula на предмет дру- гих Windows-ориентированных предложений. Например, вы найдете интеллектуальный сценарий, который может “осчастливить” клиента обновлениями Windows-демона уп- равления файлами посредством встроенной Bacula-системы восстановления. Wndows- клиент в последней версии программы Bacula поддерживает не только клиенты Windows 7 и 64-битовые клиенты, но и (пока в качестве эксперимента) архивы Microsoft Exchange. Мониторинг конфигураций программы Bacula Системное администрирование требует бдительности, и создание резервных копий — не исключение. Если в процессе создания резервных копий возникнет сбой, который не будет быстро устранен, важные данные будут стопроцентно утеряны. Задания Bacula создают отчет, который направляется, согласно ресурсу Message, в файл конфигурации демона управления. Отчет содержит основную информацию об использованных томах, размере и количестве заархивированных файлов и о любых воз- никших ошибках. Как правило, он предоставляет достаточный объем информации для решения любых не очень серьезных проблем. Рекомендуем задать такую конфигурацию, чтобы важные сообщения приходили на ваш ящик входящих сообщений электронной почты или на ваш пейджер. Команду status консоли можно использовать для запроса различной информации о демонах Bacula. Следующий вывод содержит информацию о запланированных, выпол- няющихся и прерванных заданиях. Команда messages — простой способ обзора недав- них записей журнала.
Глава 10. Резервное копирование 383 Программа Bacula включает плагин Nagios, который упрощает интеграцию архивов в существующую инфраструктуру мониторинга. Общую информацию о плагине Nagios можно получить из раздела 21.12. Советы по использованию программы Bacula Две наиболее часто встречающиеся проблемы — невозможность запуска демонов управления файлами клиентов и неспособность демонов хранения обнаружить какие- либо ленточные тома, доступные для добавления данных. В приведенном ниже приме- ре демон управления сообщает, что задание архивирования было прервано с фатальной ошибкой вследствие невозможности осуществления обмена данными с демоном управ- ления файлами компьютера harp. Сообщение об этой ошибке может многократно по- вторяться в конце итогового отчета. SD termination status: Waiting on FD Termination: *** Backup Error *** 11-Nov 21:06 bull-dir Jobld 259: Warning: bsock.c:123 Could not connect to Client: harp on 192.168.1.3:9102. ERR=Connection refused Retrying ... 11-Nov 21:31 bull-dir Jobld 259: Warning: bsock.c:123 Could not connect to Client: harp on 192.168.1.3:9102. ERR=Connection refused В следующем примере демон хранения сообщает, что для запрошенного задания ар- хивирования отсутствуют доступные ленточные тома соответствующего пула. Проблему можно устранить, либо добавив в пул новый том, либо очистив и повторно используя существующий том. Задание не нужно запускать снова — программа Bacula должна про- должить его выполнение, если только оно не будет прервано явно. 06-Мау 23:01 bull-sd Jobld 1545: Job Southernfur.2009-05-06_19.03.00.07 waiting. Cannot find any appendable volumes. Please use the "label" command to create a new Volume for: Storage: "TL4000-Drive0" (/dev/nstO) Pool: Full_Pool Media type: LTO-3 Для того чтобы ознакомиться с более подробной информацией о действиях, выпол- няемых демонами, их можно вынудить отсылать отладочную информацию на консоль, добавив опцию -dnnn к команде запуска. Например, можно использовать такую команду. $ sudo ./bacula start -dlOO Значение nnn представляет уровень отладки. Типичные значения лежат в диапазоне от 50 до 200. Чем выше это значение, тем больший объем информации отображает коман- да. Отладку можно также активизировать из консоли с помощью команды setdebug. Альтернатива программе Bacula В Интернете доступно несколько других бесплатных или условно бесплатных паке- тов резервного копирования. Следующие пакеты заслуживают особого внимания, хотя они все еще находятся в состоянии активной разработки. • Amanda: очень популярная и проверенная система, которая выполняет архивиро- вание файлов систем UNIX и Linux на одном ленточном устройстве. См. ananda. org.
384 Часть I. Основы администрирования • rsync: бесплатная утилита, входящая в состав многих пакетов Linux (работает на всех наших примерах систем). Она может выполнять синхронизацию файлов с одного компьютера на другой и ее можно использовать совместно с SSH для безопасной передачи данных по Интернету. Утилита rsync настолько интеллек- туальна, что передает по сети только различия в файлах, что говорит о ее высокой эффективности. Дополнительная информация о программе rsync приведена в разделе 19.2. Обратите внимание на то, что одной утилиты rsync обычно не до- статочно для архивов, поскольку она не сохраняет несколько копий. И не создает автономных архивов. • star: более производительная реализация программы tar. Эта программа входит в состав Linux и всех типов систем UNIX. • Mondo Rescue: утилита, которая выполняет архивирование файлов систем Linux на CD-R, DVD-R, ленту или жесткий диск. Этот пакет особенно удобен, если необхо- димо выполнить восстановление в системе, в которой нет какого-либо программ- ного обеспечения. Подробнее о нем можно узнать по адресу: mondorescue. org. 10.9. Коммерческие системы резервного копирования Нам бы хотелось, чтобы UNIX была единственной операционной системой в мире, но, к сожалению, это не так. Анализируя различные коммерческие системы резервного копирования, необходимо учитывать их способность взаимодействовать с другими опе- рационными системами, которые используются в организации. Большинство современ- ных продуктов позволяет включать рабочие станции UNIX, Windows и Mac OS в схему резервного копирования. Следует также учитывать наличие массивов хранилищ и фай- ловых серверов, работающих не под управлением UNIX. Защищать от сбоев нужно также портативные компьютеры пользователей и другие компьютеры, которые не имеют постоянного подключения к сети. Коммерческая про- грамма должна правильно обрабатывать ситуации, когда архивируются идентичные файлы с каждого портативного компьютера. В конце концов, сколько резервных копий файла command. com вам нужно? Поскольку система Bacula идеально подходит для наших потребностей, мы не при- обрели богатого опыта работы с другими коммерческими пакетами. Мы опросили не- скольких знакомых администраторов из коммерческих организаций на предмет их впе- чатлений от систем, которыми они пользуются. Ниже приведены их комментарии. ADSM/TSM Пакет ADSM, разработанный компанией IBM, впоследствии был приобретен компа- нией Tivoli. Сегодня он носит название TSM (Tivoli Storage Manager — диспетчер систем хранения компании Tivoli), хотя права собственности снова отошли к IBM, и представ- ляет собой систему управления данными, поддерживающую также резервное копирова- ние. Дополнительную информацию можно найти на веб-сайте ibm.com/tivoli. Преимущества • принадлежность компании IBM; • удачная ценовая политика; • низкий процент сбоев; ,
Глава 10. Резервное копирование 385 • использование дисковых кеш-буферов, что удобно при работе с низкоскоростны- ми клиентами; • поддержка клиентов Windows; • великолепная документация (за отдельную плату). Недостатки • плохой графический интерфейс; • каждые два файла занимают 1 Кбайт в базе данных; • сложность системы постоянно возрастает. Veritas NetBackup В 2005 году произошло слияние компаний feritas и Symantec. Объединенная компания продает системы резервного копирования для различных платформ. Информацию о них можно получить на веб-сайте Symantec. com. NetBackup — продукт, предназначенный для обеспечения резервного копирования и восстановления данных в средних и крупных гетерогенных сетях, но небольшие фирмы могут обойтись системой BackupExec. Преимущества • неплохой графический интерфейс; • взаимодействие с высокоскоростными выделенными каналами связи с системой хранения данных (архитектура “сервер-хранилище данных”) и файловыми серве- рами NetApp; • инсталляция по методу принудительной рассылки в UNIX и Windows; • возможность записи лент в формате GNU-версии команды tar; • централизованная база данных, но поддерживается и распределенное резервное копирование. Недостатки • ряд программных ошибок; • неудачная ценовая политика; • пресловутые слабые места системы безопасности. EMC Networker Американская компания-монстр ЕМС — мировой лидер на рынке продуктов, услуг и решений для хранения информации и управления ею — приобрела Legato NetWbrker в 2003 году. В то время feritas и Legato были ведущими компаниями в области резервного копирования в вычислительных сетях масштаба предприятия. Преимущества • удачная ценовая политика; • сервисное программное обеспечение может работать на всех наших примерах платформ; • поддержка различных клиент-платформ; • комплексное восстановление системы с нуля. Недостаток ? существенное перекрытие по продуктам ЕМС.
386 Часть I. Основы администрирования Прочие программы Уже упоминавшийся Кертис Престон, автор книги по резервному копированию, вы- шедшей в издательстве O’Reilly, ведет очень полезную веб-страницу backupcentral. com, посвященную данной тематике (программы зеркального дублирования дисков, ра- боты с файловыми системами, удаленного резервного копирования, внешнего хранения данных и др.). 10.10. Рекомендуемая литература Preston W. Curtis. Backup & Recovery: Inexpensive Backup Solutions for Open Systems. Sebastopol, CA: O’Reilly Media, 2007. 10.11. Упражнения 10.1. Проанализируйте процедуру резервного копирования, применяемую в вашей компании или организации. На каком компьютере (или компьютерах, если их не- сколько) выполняется резервное копирование? Какие типы накопителей исполь- зуются? Где хранятся ленты? Можно ли улучшить существующую схему? 10.2. Какие действия необходимо предпринять для восстановления файлов в системе Bacula? Как найти нужную ленту? 10.3. ★ Укажите действия, которые необходимо осуществить для выполнения трех за- прошенных операций восстановления при наличии следующего вывода команд df и /etc/dumpdates. Аргументируйте свое решение. Примите, что запрос на вос- становления датируется 18 января. 10.4. Вот результаты выполнения команды df на сайте khaya. cs. Colorado. edu. /dev/hda8 256194 81103 161863 33% / /dev/hdal 21929 4918 15879 24% /boot /dev/hda6 3571696 24336 3365924 1% /local /dev/hdalO 131734 5797 119135 5% /tmp /dev/hda5 1815580 1113348 610004 65% /usr /dev/hda7 256194 17013 225953 7% /var 10.5. А вот содержимое файла /etc/dumpdates на khaya. cs. Colorado. edu. /dev/hda8 2 Sun Jan 17 22:59:23 2010 /dev/hda6 3 Sun Jan 17 22:51:51 2010 /dev/hda7 3 Sun Jan 17 22:50:24 2010 /dev/hda5 9 Sun Jan 17 22:46:25 2010 /dev/hda5 1 Tue Jan 12 22:45:42 2010 /dev/hda7 0 Tue Jan 12 23:14:47 2010 /dev/hda6 1 Tue Jan 12 23:14:32 2010 /dev/hda8 1 Tue Jan 12 23:14:17 2010 /dev/hda6 0 Sun Jan 10 22:47:31 2010 /dev/hdal 1 Fri Jan 8 22:16:05 2010 /dev/hda7 1 Thu Jan 7 22:08:09 2010 /dev/hdal 4 Sun Jan 3 22:51:53 2010 /dev/hda7 2 Thu Dec 24 22:53:52 2009 /dev/hda5 0 Tue Nov 3 , 22:46:21 2009 /dev/hdal 0 Mon Sep 21 22:46:29 2009
Глава 10. Резервное копирование 387 /dev/hda8 0 Mon Aug 24 23:01:24 2009 /dev/hdal 3 Wed Jul 29 22:52:20 2009 /dev/hda6 2 Wed Jul 29 23:01:32 2009 а) “Пожалуйста, восстановите весь мой домашний каталог (/usr/home /elements) в том состоянии, в котором он был несколько дней назад. Похоже, что я потерял всю кодовую базу своего проекта.” б) “Я случайно выполнил команду sudo rm -rf /* на своем компьютере khaya. Не могли бы Вы восстановить все файловые системы из последних резервных копий?” в) “Все мои МРЗ-файлы, которые я скачивал из BitTorrent в течение более меся- ца, пропали. Они хранились в каталоге /tmp/яарЗ/. Не могли бы Вы восстано- вить их?” 10.6. ★ Разработайте схему резервного копирования для описанных ниже сценари- ев. Предполагается, что каждый компьютер оснащен жестким диском емкостью 400 Гбайт и домашние каталоги пользователей хранятся локально. Выберите устройство резервного копирования, оптимальное по соотношению стоимости и трудоемкости эксплуатации. Аргументируйте свой выбор. а) научно-исследовательский центр с 50 компьютерами. На каждом компьютере хранится множество важных и часто изменяемых данных б) небольшая компания, занимающаяся выпуском программного обеспечения и располагающая десятью компьютерами. Исходные коды хранятся на сервере, емкость жесткого диска которого составляет 4 Тбайт. Разрабатываемые исхо- дные коды постоянно меняются в течение дня, а домашние каталоги пользова- телей меняются редко. Стоимость системы резервного копирования не играет особой роли, зато крайне важна безопасность данных в) домашняя сеть с двумя компьютерами. Здесь основной фактор — это цена, а пользователи — не системные администраторы 10.7. ★ Разработайте стратегию восстановления архивов для каждого из трех сценариев, перечисленных в упражнении 10.4. 10.8. ★ Напишите операторы конфигурирования Bacula, которые реализуют план архи- вирования, разработанный для упражнения 10.4. 10.9. ★ Опишите действия, которые нужно было бы предпринять для выполнения ко- манды dump для удаленного накопителя на магнитной ленте по безопасному тун- нелю SSH.
Глава 11 Система Syslog и журнальные файлы Системные демоны, ядро, утилиты и службы — все они генерируют журнальные дан- ные, которые регистрируются и попадают на далеко не безразмерные диски. “Срок по- лезной службы” большинства данных ограничен, поэтому их приходится группировать, сжимать, архивировать и, наконец, удалять. Доступом и данными аудита необходимо управлять точно в соответствии с регулятивными правилами хранения информации или политикой безопасности, принятой для вашего узла. Опытные администраторы стараются без промедления просматривать журналы реги- страции. Системные журналы зачастую содержат важную информацию, которая может помочь в решении досадных проблем с конфигурацией. Если отказывается запускаться какой-нибудь демон или застарелая ошибка продолжает “ставить палки в колеса” загру- жающейся системе, первым делом проверьте журналы регистрации. Ранее в UNIX были предприняты попытки использовать интегрированную систему регистрации событий syslog, но можно сказать, что результаты в лучшем случае имели переменчивый успех. Несмотря на то что демон syslogd все еще считается “главным героем” в области регистрации, множество приложений, сетевых демонов, сценариев запуска и другие члены “комитета бдительности” используют собственные журналы ре- гистрации “специального вида”. Следствием такого беззакония стало появление журна- лов, которые существенно отличались от “подобных себе” среди разновидностей UNIX и даже дистрибутивов Linux. В большинстве случаев регистрируемое событие перехватывается в виде одной стро- ки текста, которая включает время и дату, тип и степень серьезности события, а также любые другие релевантные детали. Различные компоненты сообщения могут разделяться
Глава 11. Система Syslog и журнальные файлы 389 пробелами, символами табуляции или знаками пунктуации (в зависимости от специфи- ки файла). Поскольку большинство журналов регистрации представляет собой текстовые фай- лы их можно просматривать или анализировать такими стандартными инструментами, как cat, grep, tail и Perl. Многие современные системы также включают средства управления журналами регистрации, которые выполняют ротацию, сжатие и управле- ние журналами регистрации (ежедневно или еженедельно). Системные журналы, управляемые системой syslog, обычно содержат события от не- скольких источников. Например, “жалобы” от ядра и сетевого демона могут соседство- вать друг с другом. На узлах, которые содержат централизованный сервер регистрации, события от нескольких узлов можно группировать и обрабатывать вместе. Следующий фрагмент отображает типичные события от централизованного сервера регистрации. Dec 18 15:12:42 avl8.cs.colorado.edu sbatchd[495]: sbatchd/main: ls_info() failed: LIM is down; try later; trying ... Dec 18 15:14:28 proxy-l.cs.colorado.edu pop-proxy[27283]: Connection from 128.138.198.84 Dec 18 15:14:30 mroe.cs.colorado.edu pingem[271] : maltese- office.cs.colorado.edu has not answered 42 times Dec 18 15:15:05 schwarz.cs.colorado.edu vmunix: Multiple softerrors: Seen 100 Corrected Softerrors from SIMM J0201 Dec 18 15:15:16 coyote.cs.colorado.edu PAM_unix[17405]: (sshd) session closed !fdr user trent Dec 18 15:15:48 proxy-l.cs.colorado.edu pop-proxy[27285]: Connection from 12.^2.209.183 Dec IB 15x15:50 avl8.cs.col6rado.edu last message repeated 100 times Ш Доролниши?ная информация о РАМ приведена в разделе 22.5. Этот пример содержит записи от нескольких различных узлов (av!8, proxy-1, mroe, schwarz и coyote), а также от таких программ, как sbatchd, pop-proxy, pingea, и библи- отеки подключаемых модулей аугентификации (Pluggable Authentication Modules — РАМ). Важность использододод хорошо определенной межузловой стратегии регистрации событий значител№е1ОДОДОДЮ]ед»щу с принятием таких формальных ИТ-стандартов, как COBIT (свод правая по управлению и контролю ИТ) и ISO 27002, а также с вы- работкой отраслевых норм. В наши дни для действий, связанных с регистрацией собы- тий, эти внешние стандарты могут потребовать от вас поддержки централизованного корпоративного хранилища с использованием отметок времени, предоставляемых по- средством протокола NTP, и строгого соблюдения расписания. Некоторые стратегии мы обсудим ниже в этой главе. 11.1. Обнаружение файлов регистрации UNIX-системы часто критикуют за несогласованный подход к управлению журналь- ной регистрацией, и эта критика вполне справедлива. Посмотрите на содержимое катало- га файлов регистрации — вы обязательно найдете файлы с такими именами, как maillog, ftp.log и, возможно, IpNet, Ipd-errs или console_log. Помимо произвольных ®<ен, файлы регистрации часто разбросаны по разным каталогам и файловым системам, о умолчанию большинство этих файлов хранится в каталоге /var/adm или /var/log.
390 Часть I. Основы администрирования Системы Linux в этом плане — гораздо более интеллектуальные, хотя в каждом дис- трибутиве журнальные файлы и названы, и распределяются по каталогам по-разному. В основном, Linux-приложения записывают журнальную информацию в файлы, нахо- дящиеся в каталоге /var/log. В табл. 11.1 представлена информация о наиболее часто используемых журнальных файлах демонстрационных дистрибутивов. Указаны, в частности, следующие сведения: • журнальные файлы, подлежащие архивированию или другой обработке; • программа, создающая каждый из этих файлов; • информация о том, где задается имя файла; • периодичность удаления устаревшей информации, которая считается приемлемой; • системы (из числа демонстрационных), в которых используется каждый из этих файлов; • описание содержимого файлов. Имена файлов в табл. 11.1 даны относительно каталогов /var/adm, /var/log или / var/log/syslog, если не указано иное. Журнальные файлы обычно принадлежат пользователю root, хотя соглашения о вла- дельцах и режимах доступа к этим файлам неодинаковы в разных системах. В некоторых случаях менее привилегированный демон (такой, как httpd или mysqld) может потре- бовать доступ для записи, а затем задать ее владельца и режим работы соответственно. Вам, возможно, для просмотра важных журнальных файлов, которые имеют строгие разрешения доступа, придется использовать команду sudo. В качестве альтернативы для журнальных файлов, которые не содержат важные системные данные, можно изменить разрешения доступа и позволить “всеобщее” чтение. Мы обычно рекомендуем послед- ний вариант применять для файлов регистрации, которые вам нужно просматривать ре- гулярно (например, журналы регистрации Apache в каталоге /var/log/httpd). Следует отметить, что многие журнальные файлы из числа перечисленных в табл. 11.1 контролируются системой Syslog, но стандартная ее конфигурация сильно зависит о» системы. Если бы файл /etc/syslog. conf был более согласованным, управление жур- нальными файлами велось бы примерно одинаково во всех операционных системах. Журнальные файлы могут очень быстро увеличиваться в размере, особенно это каса- ется файлов для службы электронной почты, веб- и DNS-серверов. Неконтролируемый файл регистрации может заполнить весь диск и тем самым “положить систему”. Поэтому мы предпочитаем использовать отдельный раздел для самых “зашумленных” и занятых журнальных файлов. В системах Linux отдают предпочтение каталогам /var или /var/ log. Соглашения в других системах отличаются друг от друга. Специальные журнальные файлы Большинство журнальных файлов — это обычные текстовые файлы, в которые запи- сываются сообщения о “важных” событиях. Но некоторые файлы из числа перечислен- ных в табл. 11.1 имеют совершенно другое назначение. Файл wtmp (иногда wtnpx) содержит записи о том, когда пользователи входили в си- стему и выходили из нее, а также когда система выключалась или перезагружалась. Это довольно простой файл (новые записи просто добавляются в конец), тем не менее, он хранится в бинарном виде. Расшифровать содержимое файла можно с помощью коман- ды last.
Глава 11. Система Syslog и журнальные файлы 391 £3 Подробнее о разреженных файлах см. сноску в разделе 10.4. В файле lastlog регистрируется время последнего входа в систему каждого поль- зователя. Это разреженный бинарный файл, записи которого индексируются по иден- тификатору пользователя (UID). Размер файла будет меньше, если назначать иденти- фикаторы по порядку, хотя вряд ли об этом стоит сильно беспокоиться. Файл lastlog не должен участвовать в цикле ротации, поскольку его размер в большинстве случаев остается неизменным. Таблица 11.1. Журнальные файлы Файл Программа Место* Частота* Системы* -- - - Л~ acpid acpid Ф 64k RZ События, связанные с питанием auth.log sudo и др.6 S м и Авторизационные сообщения apache2/* httpd (версия 2) ф д ZU Журналы HTTP-сервера Apache (вер- сия 2) apt* APT ф м и Программы для установки про- граммных пакетов boot.log Сценарии запуска системы ф* м R Выходная информация сценариев запуска boot.msg Ядро в - Z Образ буфера сообщений ядра cron, cron/log cron S н RAH Сведения о выполнении и об ошиб- ках демона cron cups/* CUPS ф н ZRU Сообщения, связанные с печатью (CUPS) daemon.log Различные S н и Все сообщения средств демона debug Различные S д и Отладочные сообщения dmesg Ядро в — RU Образ буфера сообщений ядра dpkg.log dpkg ф м и Журнал управления пакетом faillogr login н н RZU Сообщения о неудачных попытках регистрации в системе httpd/* httpd ф д R Журналы HTTP-сервера Apache (в каталоге /etc) kern.log Ядро S н и Все сообщения средств ядра lastlog login в - RZ Время последней регистрации в си- стеме каждого пользователя (бинар- ный файл) mail* Связанные с эле- ктронной почтой S н Все Все сообщения средств электронной почты messages Различные S н RZUS Это основной системный журналь- ный файл rpmpkgs cron.daily в д R Список установленных RPM-пакетов samba/* smbd и др. ф н - Samba (совместное использование файлов в системах Windows/CIFS) secure Sill sshd и др. S м R Конфиденциальные авторизацион- ные сообщения SU ф - SAH Учет удачных и неудачных попыток использования команды su
392 Часть I. Основы администрирования Окончание табл. 11.1 Файл Программа Место* Частота» Системы* Содержимое/назначение syslog* Различные S н SUH Это основной системный журналь- ный файл warn Различные s н Z Все сообщения уровня предупре- ждений/ошибок wpars/* wpar Ф - А События загрузочных разделов wtmp login в м Все Сообщения о регистрации в системе (бинарный файл) хеп/* Хеп Ф 1m RZU Информация от монитора виртуаль- ных машин Хеп Xorg.n.log Xorg Ф Н RS Сообщения об ошибках сервера X Windows yum. log yum Ф М R Журнал управления пакетом а В столбцах “Место”, “Частота” и “Системы” используются следующие обозначения: S — Syslog, В — встро- енное имя, Ф — конфигурационный файл, Д — ежедневно, Н — еженедельно, М — ежемесячно, MV[km] = размер в килобайтах или мегабайтах, Z — SUSE, R — Red Hat и CentOS, S — Solaris, H — HP-UX, A — AIX. 6 Команды passwd, login и shutdown тоже записывают информацию в журнал авторизации, который хра- нится в каталоге /var/adm. в В действительности сообщения направляются в систему Syslog, но название средства и уровень важности задаются в файле /etc/initlog. conf. г Двоичный файл, который должен быть прочитан с помощью утилиты faillog. Назначение файла utmp — попытаться сохранить запись каждого пользователя, кото- рый регистрируется в данный момент. Иногда это выполняется неправильно: например, если оболочка была разрушена несоответствующим сигналом, а родительская оболочка не восстановлена надлежащим образом. Файл utmp, как правило, доступен для “всеоб- щей” записи. Особенности систем Поставщики, казалось бы, прячут журнальные файлы где-то на диске. Многие из них можно найти посредством розыскных мероприятий, проводимых на базе файлов конфигурации демонов и файла конфигурации syslog. В этом разделе мы “прольем свет” на некоторые скрытые журнальные файлы, оставленные поставщиками в “темных углах и закоулках”. Дистрибутивы Linux заслуживают приз за самый простой вариант управления регистрацией событий. Журналы регистрации получают понятные имена и последовательно сохраняются в каталоге /var/log. Все наши примеры дис- трибутивов также включают превосходную утилиту logrotate, предназна- ченную для выполнения ротации и усечения этих журналов, а также управле- ния ими. Новые программные пакеты могут вставлять файл конфигурации в каталог /etc/logrotate.d в соответствии со стратегией управления этими журналами регистрации. Утилита logrotate подробно описана ниже в этой главе (см. раздел 11.4).
Глава 11. Система Syslog и журнальные файлы 593 И наоборот, система Solaris отличается самой неорганизованной коллекцией SOiariS журналов регистрации. Но использование каталога /var/log облегчит вашу работу. Вот несколько полезных ссылок. • /var/log/* • /var/cron/log • /var/lp/logs/* • /var/saf/—log • /var/saf/z smon/log • /var/svc/log • /var/adm/* Из демона cron вы можете запускать поддерживаемый поставщиками сценарий /usr/ lib/newsyslog для выполнения ротации основных журналов регистрации /var/adm/ messages и /var/log/syslog. В системе HP-UX журналы регистрации хранятся в каталоге /var/adm. Здесь также находится множество странных и даже загадочных файлов, которые не являются журналами регистрации, поэтому будьте бдительны. Файл nettl. LOGO 0 0 предназначен для управления сетью и ведения статистики (см. man- страницу nettl). По умолчанию регистрационные записи, формируемые си- стемой Syslog, попадают в каталог /var/adm/syslog. 11.2. Syslog: система регистрации событий Syslog — это полнофункциональная система регистрации событий, написанная Эри- ком Оллманом (Eric Allman). Она выполняет две важные функции: освобождает програм- мистов от утомительной механической работы по ведению журнальных файлов и пере- дает управление журнальной регистрацией в руки администраторов. До появления си- стемы Syslog каждая программа сама выбирала схему регистрации событий, а у систем- ных администраторов не было возможности контролировать, какая информация и где именно сохраняется. Система Syslog отличается высокой гибкостью. Она позволяет сортировать сообще- ния по источникам и уровню важности и направлять их в различные пункты назначе- ния: в журнальные файлы, на терминалы пользователей и даже на другие компьютеры. Одной из самых ценных особенностей этой системы является ее способность централи- зовать процедуру регистрации событий в сети. Ф Система Syslog была давно принята “на вооружение” основными версиями UNIX и Linux (за исключение системы AIX). Система AIX включает демон syslog и библиотечные программы, но не обеспечивает никакой стандартной конфигурации системы Syslog и использует собственный демон для форми- рования отчетов об ошибках (подробнее см. раздел 11.3 ниже в этой главе). Поскольку система Syslog столь широко применяется программными расши- рениями, мы считаем, что глубокое понимание системы Syslog важно и для администраторов AIX.
394 Часть I. Основы администрирования Архитектура системы Syslog Система Syslog состоит из трех компонентов: • syslogd — демон журнальной регистрации (его конфигурационный файл называ- ется /etc/syslog.conf); • openlog (), syslog (), closelog () — библиотечные функции, которые передают сообщения демону syslogd; • logger — команда пользовательского уровня, которая принимает регистрацион- ные сообщения от интерпретатора команд. Ш Сигналы описаны в разделе 5.3. Демон syslogd запускается на этапе начальной загрузки системы и работает непре- рывно. Его работой нельзя управлять посредством демона inetd. Программы, взаимо- действующие с системой Syslog, записывают журнальные сообщения (путем вызова би- блиотечной функции syslog ()) в специальный файл /dev/log, который представляет собой UNIX-сокет. Демон syslogd читает сообщения из этого файла, сверяется со сво- им конфигурационным файлом и пересылает сообщения адресатам. По сигналу “отбой” (HUP, сигнал 1) демон syslogd закрывает свои журнальные фай- лы, перечитывает конфигурационный файл и вновь переходит в режим непрерывной регистрации сообщений. Если файл syslog. conf изменился, нужно послать демону syslogd сигнал HUP, иначе изменения не вступят в силу. Сигнал ТЕРМ приводит к за- вершению работы демона. Демон syslogd записывает свой идентификатор процесса (PID) в каталог /var/run (в системе AIX для этого используется каталог /etc). Это облегчает передачу демону сиг- налов из сценариев. Например, следующая команда посылает демону сигнал отбоя. solaris$ sudo kill -HUP '/bin/cat /var/run/syslogd.pid' Попытки выполнить сжатие или ротацию журнального файла, который был открыт демоном syslogd для записи, приводят к непредсказуемым последствиям. О выполне- нии ротации журнальных файлов с помощью утилиты logrotate можно прочитать в раз- деле 11.4. Предпочтительный метод перезапуска утилиты syslogd в системе АЕХ — использо- вание команды refresh. aix$ sudo refresh -s syslogd Команда refresh контактирует с контроллером системных ресурсов (System Resour- ce Controller), который управляет различными подсистемами, в том числе и подсистема- ми регистрации. Подробнее см. man-страницу refresh. Конфигурирование демона syslogd Поведение демона syslogdзависит от содержимого файла /etc/syslog.conf. Это текстовый файл относительно простого формата. Пустые строки, а также строки, начина- ющиеся с символа решетки (#), игнорируются. Базовый синтаксис записей файла таков. селектор <ТаЬ> действие Например, строка mail.info /var/log/maillog обеспечивает сохранение сообщений, поступающих от почтовой системы, в файле /var/ log/maillog. Поля селектор и действие должны разделяться одним или двумя сим-
Глава 11. Система Syslog и журнальные файлы 395 волами табуляции. Пробелы в большинстве версий не работают и скрывают ошибки, которые потом довольно трудно отследить. Такие ошибки легко появляются в результате операций вырезки и вставки, выполняемых с помощью мыши. Селектор указывает программу (“средство”), которая посылает журнальное сооб- щение, и уровень важности этого сообщения. Формат селектора выглядит следующим образом. средство.уровень Названия средств и уровней важности следует выбирать из стандартного списка зна- чений; программы не могут самостоятельно составлять такие списки. Есть средства, определенные для ядра, для основных групп утилит и для локальных программ. Все ос- тальное проходит под общим названием user (т.е. пользователь). Селекторы могут содержать ключевые слова * и попе, которые обозначают “все” и “ничего” соответственно. В селекторе разрешается через запятые перечислять группу средств. Допускается также разделение самих селекторов с помощью точки с запятой. В общем случае селекторы объединяются методом логического сложения, т.е. указан- ное действие будет выполняться для сообщения, соответствующего любому селектору. Селектор уровня попе означает исключение перечисленных в нем средств, независимо от того, что указано в остальных селекторах этой же строки. Приведем несколько примеров селекторов. средство.уровень средство!, средство2.уровень средство!.уровень!;средство2.уровень2 ★.уровень ★. уровень ; шюхое_средство .попе действие действие действие действие действие В табл. 11.2 перечислены допустимые названия средств. В настоящее время опреде- лено 21 средство. Таблица 11.2. Названия средств Syslog i * A1 1 . АГ" -J'AW ',11/ * Все средства, кроме mark auth authpriv cron daemon ftp kem localO-7 ipr mail mark news 8yslog user Uucp Команды, связанные с безопасностью и авторизацией Конфиденциальные авторизационные сообщения Демон cron Системные демоны Демон f tpd Ядро Восемь разновидностей локальных сообщений Система спулинга построчной печати Система sendmail и другие почтовые программы Метки времени, генерируемые через одинаковые промежутки Система телеконференций Usenet (устаревшее средство) Внутренние сообщения демона syslogd Пользовательские процессы (это установка по умолчанию, если не указано иное) Устаревшее средство, которое в последних версиях системы игнорируется
396 Часть I. Основы администрирования Не воспринимайте слишком серьезно различие между syslog-сообщениями типа auth и authpriv. В действительности все авторизационные сообщения являются кон- фиденциальными, и ни одно из них не должно быть открытым для всеобщего доступа. Демон syslogd сам генерирует сообщения с метками времени, которые регистри- руются, если в файле syslog.conf для них указан селектор со средством mark. Метки времени помогают точно определить, когда произошел сбой, к примеру “между 3:00 и 3:20 утра”, а не просто “сегодня ночью”. Это необходимо при устранении проблем, воз- никающих регулярно. В табл. 11.3 перечислены уровни важности, существующие в системе Syslog (в поряд- ке убывания важности). Таблица 11.3. Уровни важности сообщений Syslog Уровень Приблизительное значение emerg alert Экстренные сообщения Срочные сообщения crit Критические состояния err Другие ошибочные состояния warning notice info debug Предупреждения Необычные события, которые заслуживают внимания Информационные сообщения Отладочные сообщения Уровень сообщения определяет его важность. Границы между различными уровнями несколько размыты. Существует четкое различие между событиями, заслуживающими внимания, и предупреждениями (а также между предупреждениями и сообщениями об ошибках), но трудно однозначно разграничить значения уровней alert и crit. В файле syslog.conf уровни обозначают минимальную важность, которую со- общение должно иметь для того, чтобы быть зарегистрированным. Например, сообще- ние почтовой системы, имеющее уровень важности warning, будет соответствовать селектору mail. warning, а также селекторам mail. info, mail. notice, mail. debug, *. warning, *. notice, *. info и *. debug. Если в файле syslog. conf указано, что со- общения mail. info должны регистрироваться в файле, то сообщения mail .warning тоже будут направляться в этот файл. В Linux-версиях системы Syslog перед названиями уровней могут ставиться симво- лы = и !, означающие “только этот уровень” и “за исключением этого и более высоких уровней” соответственно (табл. 11.4). Таблица 11.4. Примеры использования квалификаторов уровня в файле syslog.conf CeaeKtop ________________ Назначение __________________________- ;___________jSl mail. info Выбор почтовых сообщений уровня info и выше mail. =infо Выбор почтовых сообщений только уровня info mail. info ;mail.»err Выбор почтовых сообщений уровней info, notice и warning mail. debug ;mail.! ^warning Выбор почтовых сообщений любого уровня, кроме warning Поле действие определяет способ обработки сообщения. Возможные варианты пе- речислены в табл. 11.5. *
11. система Syslog и журнальные файлы 597 Таблица 11.5. Действия системы Syslog '• — - - ‘ ПЯМИЧИЯВ , - . имя_ файла Дописать сообщение в указанный файл на локальном компьютере @имя_узла Переслать сообщение демону syslogd, выполняющемуся на компьютере с ука- занным именем @тр_адрес Переслать сообщение демону syslogd на компьютере с указанным IP-адресом | файЛ—FIFO Записать сообщение в указанный именованный канал® поль зова тель 1, пользова тель2,... Вывести сообщение на экраны терминалов указанных пользователей, если они за- регистрированы в системе Вывести сообщение на экраны всех зарегистрированных пользователей а Для получения дополнительной информации введите команду info mkfifo (только для Linux-версий syslogd). Если в качестве действия задано имя файла (или имя файла FIFO), то это должно быть полное имя. При отсутствии указанного файла в системе Linux демон syslogd создает его в процессе записи первого сообщения. В других системах заданный файл должен уже существовать — демон syslogd не будет его создавать. В дистрибутивах Linux перед именем файла можно ставить дефис, чтобы по- сле записи каждого сообщения не осуществлялся системный вызов sync. Синхронизация помогает сохранить как можно больше журнальной информа- ции в случае сбоя системы, но она достаточно накладна с точки зрения произ- водительности системы. Естественно, мы рекомендуем включать дефисы (тем самым запрещая синхронизацию). Удаляйте дефисы только временно, пока занимаетесь изучением проблемы, которая является причиной аварийного со- стояния ядра. Если указывается не IP-адрес, а имя узла, оно должно быть известно одной из служб преобразования имен, например DNS или NIS. В системе Solaris реализация syslog выполняет файл syslog.conf через ма- soiaris кропроцессор предварительной обработки ш4. Обратитесь к тап-страницам и, не жалея, используйте кавычки, чтобы записи конфигурации выражали ва- ши намерения. Например, вы должны заключать в кавычки все ключевые сло- ва ш4 и все выражения, которые содержат запятую. Вот как выглядит типич- ная запись в стиле гп4. auth.notice ifdef('LOGHOST', '/var/log/authlog', @loghost') Обратите внимание на то, что используемые кавычки представляют собой одиноч- ные “обратные апострофы”. Приведенная выше строка направляет сообщения в файл / var/l°9/authlog, если значение LOGHOST не определено. В противном случае сообще- ния направляются в компьютер loghost. В т4 операторы if def очень мощные; они позволяют системным администраторам создавать один файл syslog. conf, который может быть использован на всех компьютерах. Хотя в селекторе можно указывать сразу несколько средств и уровней, выполнение нескольких действий не предусмотрено. Для того чтобы послать сообщение в два разных места (например, в локальный файл и на центральный регистрационный узел), нужно включить в конфигурационный файл две строки с одинаковыми селекторами.
398 Часть I. Основы администрирования Поскольку сообщения системы Syslog могут использоваться для организации атак типа “отказ от обслуживания”, демон syslogd в большинстве дистрибутивов Linux от- кажется принимать сообщения от других компьютеров, если только он не был запущен с флагом -г. По умолчанию демон также отказывается выступать в роли внешнего дис- петчера сообщений: сообщения, поступающие от сетевого узла, не могут быть пересла- ны на другой узел. Флаг -h отменяет такое поведение. Если нужно, чтобы эти опции были всегда включены, модифицируйте соответствующим образом сценарий запуска syslog. В RHEL конфигурацию syslog необходимо отредактировать в /etc/sysconfig /syslog. Примеры конфигурационных файлов Поскольку понять содержимое файла syslog.conf несложно, мы не станем подроб- но анализировать конфигурационные файлы наших демонстрационных дистрибутивов. Гораздо полезнее будет рассмотреть некоторые распространенные схемы журнальной регистрации. Ниже приведены примеры трех файлов syslog.conf, которые соответствуют ав- тономному компьютеру, используемому в небольшой сети, клиентскому компьютеру в крупной сети и центральному регистрационному узлу этой же сети. Последний на- зывается netloghost1. Автономный компьютер Ниже показана базовая конфигурация для автономного компьютера. # Файл syslog.conf для небольшой сети или автономной системы. # Экстренные сообщения направляются всем зарегистрированным пользователям. *.emerg2 * # важные сообщения * .warning;daemon,auth.info;user.none /var/log/messages # ошибки принтера Ipr.debug /var/log/lpd-errs В первой не являющейся комментарием строке организуется вывод экстренных со- общений на экраны терминалов всех пользователей, зарегистрированных в данный мо- мент в системе. В качестве примера можно привести сообщения, выдаваемые командой shutdown перед выключением системы. Вторая значащая строка обеспечивает запись важных сообщений в файл /var/log/ messages. Уровень info ниже уровня warning, поэтому выражение daemon, auth. info включает дополнительную регистрацию сообщений, поступающих от команд passwd и su, а также от всех демонов. Третья строка предназначена для записи сообщений об ошибках принтера в файл /var/log/lpd-errs. Сетевой регистрационный клиент Как показано в следующем примере, клиентский компьютер обычно пересылает важные сообщения на центральный регистрационный узел. 1 Точнее, netlogbost — один из псевдонимов узла. Наличие псевдонима позволяет заменять регистрационный узел с минимальными затратами на переконфигурирование системы. Псевдоним можно добавить в файл /etc/hosts или задать с помощью записи СИАМЕ в базе данных DNS. Подробнее о записях СИАМЕ рассказывается в разделе 17.8. 2 Если пользователи оконной системы X не выполняют программу xconsole, они не получат эти сообщения.
Глав? 11. система Syslog и журнальные файлы 599 # Файл syslog.conf для клиентских компьютеров # Экстренные сообщения направляются всем зарегистрированным пользователям. * .emerg;user.none * # важные сообщения пересылаются на центральный компьютер. * ,warning;lpr,locall.none Qnetloghost daemon,auth.info @netloghost # Сообщения от локальных программ отправляются на центральный компьютер. 1оса12.info;1оса17.debug Qnetloghost # Сообщения об ошибках принтера хранятся локально. Ipr.debug /var/log/lpd-errs # Сообщения утилиты sudo регистрируются от имени средства 1оса12. # Сохраняем их копии. 1оса12.info /var/log/sudo.log # Сообщения ядра также хранятся локально. kern.info /var/log/kern.log В такой конфигурации локально хранится не очень много информации. Если компью- тер netloghost выключен или недоступен, регистрационные сообщения будут безвоз- вратно утеряны. На этот случай можно создавать локальные копии важных сообщений. В системе, где инсталлирован большой объем локального программного обеспече- ния, неоправданно много сообщений будет регистрироваться от имени средства user на уровне emerg. В показанном примере такая ситуация заведомо исключается благодаря выражению user .попе в первой значащей строке. 03 Подробнее об утилите sudo рассказывалось в разделе 4.3. Вторая и третья значащие строки служат для пересылки всех важных сообщений на центральный регистрационный сервер; исключение составляют сообщения подсисте- мы печати и университетской (локальной) системы доступа по магнитным карточкам. В четвертой строке организуется отправка локальной журнальной информации также на центральный компьютер. Последние три строки обеспечивают сохранение локальных копий сообщений об ошибках принтера, журнальных сообщений утилиты sudo и со- общений ядра. Центральный регистрационный узел Ниже показана конфигурация компьютера netloghost — центрального защищенно- го регистрационного узла сети среднего размера, включающей около 7000 компьютеров. # Файл syslog.conf для главного регистрационного узла. # Экстренные сообщения направляются на консоль и в журнальный файл, # дополняемые метками времени. *.emerg /dev/console * .err;kern,mark.debug;auth.notice /dev/console * .err;kern,mark.debug;user.none /var/log/console.log auth.notice /var/log/console.log # Сообщения, не являющиеся экстренными, # записываются в обычные журнальные файлы. *.err;user.none;kern.debug /var/log/messages daemon,auth.notice;mail.crit /var/log/messages lpr.debug /var/log/lpd-errs mail.debug /var/log/mail.log # В следующих строках обрабатываются сообщения локальных программ # авторизации, таких как sudo и npasswd. Iocal2.debug /var/log/sudo.log
400 Часть I. Основы администрирования 1оса12.alert auth.info # другие локальные программы localO.info local4.notice local6.debug local7.debug /var/log/sudo-errs.log /var/log/auth.log /var/adm/nbl.log /var/admlog/da.log /var/adm/annex-isn.log /var/admlog/tcp.log # локальные сообщения (стандартное правило обработки сообщений, # для которых не задано средство) user.info /var/admlog/user.log Сообщения, поступающие от локальных программ и демонов syslogd по сети, за- писываются в журнальные файлы. В некоторых случаях выходная информация каждого средства помещается в отдельный файл. Центральный регистрационный компьютер генерирует метки времени для каждого получаемого сообщения. Это время не всегда совпадает со временем отправки сообще- ния. Если в систему входят компьютеры, расположенные в разных часовых поясах, или системные часы не синхронизированы, информация о времени окажется недостоверной. Отладка системы Syslog Команда logger позволяет выдавать журнальные сообщения в сценариях интерпре- татора команд. Кроме того, эту команду можно использовать для проверки изменений в конфигурационном файле демона syslogd. Например, если в файл была добавлена строка 1оса15.warning /tmp/evi.log и нужно убедиться в том, что она действительна, введите такую команду. hp-ux$ logger -р locals.warning "test message” Строка, содержащая фразу “test message” (тестовое сообщение), должна быть записана в файл /tmp/evi. log. Если этого не произошло, то, возможно, вы забыли создать файл evi. log, предоставить соответствующие права доступа к этому файлу или послать демо- ну syslogd сигнал отбоя. А, может быть, вы использовали пробелы вместо табуляции? Альтернатива системе Syslog Хотя система Syslog — проверенное средство регистрации событий в системах UNIX и Linux, в попытках устранения ряда ее недостатков были разработаны несколько аль- тернативных систем. Одна из них — Syslog-ng (“Syslog, next generation” — Syslog сле- дующего поколения) — теперь по умолчанию используется в системах SUSE. С точки зрения конфигурирования, она достаточно сильно отличается от Syslog, и мы не станем подробно ее описывать в этой книге. Если захотите ее использовать в системе, отличной от SUSE, она доступна по адресу: balabit. com. Система Syslog-ng предоставляет дополнительные возможности конфигурирования, фильтрования, в зависимости от содержимого сообщений, обеспечения целостности со- общений и улучшенную поддержку ограничений брандмауэра при пересылке сообще- ний по сети. Система SDSC Secure Syslog (разработанная в центре суперкомпьютеров в Сан-Диего) известна также как высокопроизводительная система Syslog. Реализуя спецификации RFC3195 (Reliable Delivery for syslog), она предоставляет “признаваемую судебными ор- ганами” систему аудита событий. Ее разработка выполнялась специально для организаций
Глава 11. система Syslog и журнальные файлы 401 с высоким сетевым трафиком, и система содержит множество компонентов оптимиза- ции производительности. Ее исходный код можно загрузить из сайта SourceForge: sourceforge.net/projects/sdscsyslog. Система Rsyslog — еще одна мощная альтернатива следующего поколения — вклю- чается в стандартные поставки ряда популярных дистрибутивов Linux (в том числе Fedora 8). Rsyslog позиционирует себя как расширенный модуль syslogd для систем Linux и Unix, обладающий продвинутой многопоточностью и акцентированный на без- опасности и надежности. Rsyslog поддерживает удаленную передачу логов на другой сер- вер посредством TCP (в отличие от протокола UDP, используемого оригинальным демо- ном syslog) и может взаимодействовать с протоколом защищенных сокетов SSL (Secure Sockets Layer), использование которого в некоторых системах может быть выдвинуто в качестве обязательного условия по регулятивным причинам. Через подключаемые рас- ширения Rsyslog даже может записывать системные логи сразу в базу данных (MySQL, Posrgres SQL, Oracle и множество других), а не только в файл. Rsyslog — оптимальное решение, функционально превосходящее свои аналоги и легко осваиваемое новичками. Больше о возможностях Rsyslog можно узнать на сайте rsyslog.com. Журнальная регистрация на уровне ядра и на этапе начальной загрузки Д Ядро и сценарии запуска системы представляют собой немалую проблему с точ- ки зрения журнальной регистрации. В первом случае проблема заключается в том, чтобы средства регистрации событий, происходящих на этапе началь- ной загрузки и в ядре, не зависели от типа файловой системы и ее органи- зации. Во втором случае трудность состоит в последовательной регистрации событий, происходящих в сценариях, а не в системных демонах или других программах, — их сообщения должны регистрироваться на другом уровне. Необходимо также избежать ненужного дублирования записей в сценариях и переадресации их вывода. Первая из описанных проблем решается путем создания внутреннего буфера огра- ниченного размера, куда ядро заносит свои журнальные сообщения. Этот буфер доста- точно велик для того, чтобы вместить сообщения обо всех действиях, предпринимаемых ядром на этапе начальной загрузки. Когда система полностью загрузится, пользователь- ский процесс сможет получить доступ к журнальному буферу ядра и скопировать его содержимое в нужное место. Обычно для этого запускается команда dmesg, результаты работы которой даже содержат сообщения, которые были сгенерированы до запуска де- мона init. Сообщения, генерируемые ядром в процессе работы, обрабатываются демоном klogd. С функциональной точки зрения он расширяет возможности команды dmesg. Демон может или просто создать образ журнального буфера ядра и завершить работу, или дина- мически извлекать сообщения из буфера по мере их появления, записывая их в файл или передавая системе Syslog. По умолчанию демон работает во втором режиме. Его сообще- ния обрабатываются системой Syslog в соответствии с установками для средства “kern” (обычно они записываются в каталог /var/log/messages или /var/log/syslog). В наших демонстрационных дистрибутивах сценарии запуска не используют флаг -с команды dmesg при создании начального образа журнального буфера, вследствие чего содержимое буфера читается, но не сбрасывается. Когда демон klogd запускается, он
402 Часть I. Основы администрирования находит в буфере те же сообщения, которые прочла команда dmesg, и передает их систе- ме Sysiog. По этой причине некоторые сообщения появляются не только в файле dmesg или boot .msg, но и в основном syslog-файле системы. Другой важный момент, связанный с журнальной регистрацией на уровне ядра, ка- сается правильного управления системной консолью. Важно, чтобы по ходу загрузки системы вся выводимая информация попадала на консоль. С другой стороны, когда си- стема загрузилась и начала выполняться, консольные сообщения больше раздражают, нежели помогают, особенно если консоль используется для регистрации в системе. Команда dmesg и демон klogd позволяют указывать в командной строке уровень важности консольных сообщений ядра. ubuntu$ sudo dmesg -n 2 Сообщения уровня 7 наиболее информативны и включают отладочную информа- цию. К первому уровню относятся только сообщения о фатальных ошибках системы (чем ниже уровень, тем выше важность сообщений). Все сообщения, выдаваемые ядром, продолжают поступать в журнальный буфер (а также в систему Syslog) независимо от того, направляются они на консоль или нет. В каталог /ргос/sys ядро помещает также ряд управляющих файлов, которые по- зволяют отсекать повторяющиеся журнальные сообщения. Механизм настройки пара- метров ядра подробнее описан в подразделе 13.3. Специальными управляющими файла- ми являются /proc/sys/kernel/printk_ratelimit, в котором указан минимальный интервал времени в секундах между записываемыми сообщениями ядра после активи- зирования “заглушки” (по умолчанию это значение равно 5), и /proc/sys/kernel/ printk_ratelimit_burst, в котором указано количество групповых сообщений, вы- зывающее активизирование заглушки (значение по умолчанию — 10). Эти параметры носят лишь рекомендательный характер и поэтому не обеспечивают абсолютной гаран- тии полного перекрытия потока излишних сообщений. Кроме того, они применяются только к сообщениям, созданным в ядре с помощью функции printk_ratelimit (). К сожалению, журнальная регистрация на уровне сценариев запуска системы контро- лируется не так хорошо, как на уровне ядра. В Red Hat Enterprise Linux имеется команда initlog, которая перехватыва- ет сообщения, выдаваемые командами сценариев, и направляет их в систему Syslog. К сожалению, эту команду приходится явно указывать в сценариях, что повышает их сложность. В конечном итоге журнальные сообщения попадают в файл /var/log/boot. log. В других наших дистрибутивах вообще не делаются попытки перехватывать сообще- ния сценариев запуска. Часть информации регистрируется отдельными командами и де- монами, но основная ее часть остается “незамеченной”. 11.3. Регистрация сообщений и обработка ОШИБОК В СИСТЕМЕ AIX ®В системе AIX управление журналами регистрации отличается от других систем UNIX. Несмотря на наличие системы Syslog в стандартной поставке, она не сконфигурирована. При формировании отчета о системных ошибках AIX опи- рается на демон errdemon, который предназначен для обработки системных диагностических сообщений (таких, как уведомления о сбоях оборудования
Глава 11. Система Syslog и журнальные файлы 403 или всей файловой системы), но не для обработки регистрирующих сообще- ний для отдельных демонов. Таким образом, предусмотрительный системный администратор воспользуется мудростью демона errdemon для ADC-диагно- стики и возможностями правильно сконфигурированной системы Syslog для управления журналами регистрации централизированных приложений. Демон errdemon запускается при начальной загрузке системы в каталоге /etc/rc. bootc и читает события, связанные с ошибками, из специального файла /dev/error. Как ядро, так и некоторые пользовательские AIX-приложения записывают данные об ошибках в этот файл в соответствии с предопределенными шаблонами из каталога /dev /adm/ras/errtmplt. Демон errdemon сравнивает новые записи с шаблонами и за- писывает результат в двоичном формате в файл /var/adm/ras/errlog. Система AIX любит двоичные форматы! Файл errlog — циркулярный, поэтому, когда файл достигает своего максимального размера (1 Мбайт по умолчанию), на место первого события записывается новое. Кроме того, демон errdemon буферизирует события, которые еще не были записаны в журнал регистрации. Можно просмотреть или изменить настройки, запустив непосредственно демон /usr/lib/errdemon. Детали инициирования работы демона можно узнать на со- ответствующей man-странице. Поскольку файл errlog — не текстовый, для чтения его содержимого вы можете ис- пользовать другой инструмент errpt. Без аргументов утилита errpt напечатает в сокра- щенной форме список всех событий, записанных в журнале регистрации. Для получе- ния более подробного варианта того же списка добавьте аргумент -а. Вот как выглядит пример записи из нашей системы AIX. aix$ errpt -а LABEL: DMPCHK_NOSPACE IDENTIFIER: F89FB899 Date/Time: Sat Mar 21 15:00:01 MST 2009 Sequence Number: 224 Machine Id: 0001A4C4D700 Node Id: ibm Class: Type: WPAR: 0 PEND Global Resource Name: dumpcheck Description The copy directory is too small. Probable Causes There is not enough free space in the file system containing the copy irectory to accommodate the dump. Recommended Actions Increase the size of that file system. detail Data File system name /var/adm/ras
404 Часть I. Основы администрирования Current free space in kb 108476 Current estimated dump size in kb 197836 Это конкретное событие означает, что системный дамп не поместится в заданной файловой системе приемника. Большинство меток разделов не требует дополнительных разъяснений, но за дополнительной информацией по errpt вам стоит все же обратить- ся к соответствующей шап-странице. Несмотря на то что демон errdemon представляет собой полезный источник данных о регистрации событий в автономной системе AIX, его использование может противо- речить получившей более широкое определение стратегии регистрирования событий на уровне предприятия. Вам, возможно, придется написать сценарий для перехвата собы- тий демона errdemon в формате системы Syslog или перенаправлять их для централи- зованного архивирования. Кроме того, из оперативной IBM-документации вы можете узнать, как отправлять отчеты об ошибках в систему Syslog через менеджер ODM (Object Data Manager). Возможно, вам придется удалять записи из журналов регистрации ошибок, и для этой цели специалисты из IBM предусмотрели команду errclear. Эта команда удаляет все сообщения по истечении количества дней, заданного в качестве аргумента. Например, при выполнении команды errclear 7 будут удалены сообщения об ошибках, с момен- та регистрации которых прошло более одной недели. Чтобы стереть все сообщения об ошибках, выполните команду errclear 0, а чтобы стереть заданное сообщение — команду errclear - j идентификатор 0. Конфигурация системы Syslog в среде AIX По умолчанию AIX-файл syslog. conf содержит длинный список комментариев и не имеет никаких анализируемых конфигурационных данных. Системный админи- стратор вправе сам принять решение о конфигурировании системы Syslog в соответ- ствии с настройками в других системах. Всегда не такая, как все, система AIX предоставляет свое средство циркуляции реги- страционной информации в рамках демона syslogd. Журналы регистрации могут под- вергаться циркуляции через регулярные интервалы времени или по достижении ими за- данного размера. Их можно сжимать и архивировать в определенных каталогах. И хотя мы ценим эти функциональные возможности, они не могут управлять файлами, которые находятся вне контроля системы Syslog (например, журналы регистрации, генерируемые приложениями, которые “ничего не знают” о системе Syslog). Чтобы реализовать всесто- роннее управление журналами регистрации, вам, возможно, придется сочетать средства ротации демона syslogd с одним из инструментов, описываемых ниже в этой главе. Для воспроизведения конфигурации системы Syslog в стиле Linux присоедините сле- дующие строки к концу файла /etc/syslog.conf и выполните команду refresh -s syslogd. Не забудьте использовать символы табуляции вместо пробелов и создать каж- дый файл заранее. mail.debug user.debug kern.debug syslog.debug daemon.debug /var/log/mail /var/log/user /var/log/kern /var/log/messages /var/log/daemon
Ошва 11. Система Syslog и журнальные файлы 405 auth.debug /var/log/secure 1оса12.debug /var/log/sudo Вы задаете ротацию журналов регистрации в файле syslog.conf путем присоеди- нения опции rotate к концу строки конфигурации. Журналы регистрации могут под- вергаться ротации по достижении заданного размера файла или по истечении заданного интервала времени (временного инкремента). Если вы установите ограничение как по размеру, так и по времени, демон syslogd выполнит ротацию файла при реализации любого критерия. Более того, файлы могут быть сжаты или заархивированы с переносом в новый каталог. Возможные опции перечислены в табл. 11.6. Таблица 11.6. Опции ротации AIX-журналов регистрации, задаваемые в файле syslog. conf -...........'............ ‘Л 1 rotate Означает, что заданный файл должен быть подвергнут ротации size W[km]a files N Выполняет ротацию, когда файл достигает заданного размера6 Сохраняет заданное количество версий в ротации time W[hdwmy]B compress archive позиция Выполняет ротацию после истечения заданного интервала времени6 Сжимает файл после ротации с помощью команды compress Перемещает файл после ротации в заданную позицию а к — килобайты, m — мегабайты. 6 Между элементом N и единицами измерения не должно быть пробелов. Например, 3m — правильная за- пись, а 3 ш—нет. 8 h — чеод d—дни, w — недели, m — месяцы, у — годы. Найример, вот несколько строк файла конфигурации syslog. conf из предыдущего примера, который был расширен опциями ротации. # Rotate at 500MB, keep 4 files mail.debug /var/log/mail rotate size 500m files 4 # Rotate after 1 week, keep 10 files, compress the file user.debug /var/log/user rotate files 10 time lw compress # Rotate after 100KB or 2 months, whichever occurs first, keeping 4 files kern.debug /var/log/kern rotate size 100k files 4 time 2m # Keep 1 year of weekly logs, compress the file, move the file to /logs syslog.debug /var/log/messages rotate files 52 time lw compress archive /logs 11.4. Утилита locrotate: управление ЖУРНАЛЬНЫМИ ФАЙЛАМИ Прекрасная утилита logrotate реализует различные схемы управления журнальны- ми файлами и является частью всех рассматриваемых нами дистрибутивов Linux. Она также выполняется в системах Solaris, HP-UX и AIX, но для этого вам придется ее ин- сталлировать. Мы отдаем предпочтение утилите logrotate, а не пакету logadm, кото- рый входит в поставку системы Solaris. ^^Конфигурационный файл утилиты logrotate состоит из набора спецификаций для фУПй журнальных файлов, которыми следует управлять. Параметры, определенные вне
406 Часть I. Основы администрирования какой-либо спецификации (например, errors, rotate и weekly в показанном ниже примере), являются глобальными. Их можно переопределять для конкретного журналь- ного файла, а также указывать несколько раз в различных частях файла, меняя стандарт- ные установки. Ниже представлен несколько искусственный пример такого файла. # Глобальные параметры errors errors@book.admin.com rotate 5 weekly # Определения и параметры ротации журнальных файлов /var/log/messages { postrotate /bin/kill -HUP 'cat /var/run/syslogd.pid' endscript } /var/log/samba/*.log { notifempty copytruncate sharedscripts postrotate /bin/kill -HUP 'cat /var/lock/samba/*.pid' endscript } В этой конфигурации раз в неделю осуществляется ротация файла /var/log /messages. Сохраняются пять последовательных версий файла, а демон syslogd уве- домляется о каждом шаге ротации. Журнальные файлы системы Samba (их может быть несколько) также подвергаются ротации каждую неделю, но вместо того чтобы последо- вательно перемещать файлы, а затем создавать новый начальный файл, сценарий после- довательно копирует журнальные файлы, усекая первый. Сигнал HUP посылается демо- нам Samba только после того, как произойдет ротация всех журнальных файлов. В табл. 11.7 перечислены наиболее полезные параметры файла logrotate. conf. Таблица 11.7. Параметры файла logrotate. conf Опция Нмнммй ’. ".' ‘ ' Й compress daily, weekly, monthly Сжимать все версии журнального файла, кроме текущей Осуществлять ротацию журнальных файлов ежедневно, еженедельно или ежемесячно delaycompress endscript errors почтовый_адрес missingok notifempty olddir каталог postrotate Сжимать все версии журнального файла, кроме текущей и предыдущей Этот параметр помечает конец блоков prerotate и postrotate Направлять сообщения об ошибках по указанному адресу Не выдавать предупреждений об отсутствии журнального файла Не осуществлять ротацию журнального файла, если он пуст Помещать старые версии журнального файла в указанный каталог Этот параметр помечает начало блока команд, выполняемых после рота- ции журнального файла prerotate Этот параметр помечает нгщало блока команд, выполняемых перед рота- цией журнального файла
Глава 11. Система Syslog и журнальные файлы 407 Окончание табл. 11.7 Опция . rotate п Включать в цикл ротации указанное число версий журнального файла sharedscripts Запускать сценарии один раз для всей группы журнальных файлов size=nopor Выполнять ротацию, если размер журнального файла превышает порого- вую величину (например, 100 Кбайт, 4 Мбайт) Утилита logrotate обычно запускается демоном cron раз в день. Ее стандартный конфигурационный файл называется /etc/logrotate.conf, но в командной строке можно указывать сразу несколько файлов (или каталогов, содержащих конфигурацион- ные файлы). Эта особенность широко используется в дистрибутивах Linux, в которых каталог /etc/logrotate.d определен как стандартное место хранения конфигураци- онных файлов утилиты logrotate. Программные пакеты, поддерживающие эту утили- ту (а таковых немало), при инсталляции выбирают схему журнальной регистрации, что существенно упрощает их администрирование. Кроме утилиты logrotate, дистрибутив Ubuntu включает также более простую про- грамму savelog, которая управляет ротацией отдельных файлов. Она проще утилиты logrotate и не использует конфигурационный файл (да и не нуждается в нем). В не- которых пакетах предпочтение отдается собственным конфигурациям, создаваемым с по- мощью утилиты savelog, а не определенным утилитой logrotate. 11.5. Поиск ПОЛЕЗНОЙ ИНФОРМАЦИИ В ЖУРНАЛЬНЫХ ФАЙЛАХ Система Syslog прекрасно подходит для сортировки и маршрутизации журнальных сообщений, но в результате все равно получается большой набор журнальных файлов. Они могут содержать много важной информации, но иногда ее не так просто найти. Не- обходимо дополнительное программное обеспечение для анализа журнальных файлов и поиска в них нужных сообщений. В этом сегменте рынка предлагается много бесплатных продуктов, и большинство из них работает примерно одинаково: программа сканирует недавние записи журналь- ного файла, сравнивает их с регулярными выражениями из базы данных и обрабатывает важные сообщения. Различия между программами проявляются в степени гибкости и размере готовых баз данных с шаблонами. Двумя наиболее распространенными программами обработки журнальных файлов являются утилиты swatch и logcheck. Их можно загрузить из сайта sourceforge. net (программа logcheck распространяется в составе пакета sentrytools: source forge. net/projects/sentrytools). Утилита swatch представляет собой Perl-сценарий, работающий в соответствии с Директивами конфигурационного файла. Синтаксис этого файла достаточно гибок, так как позволяет выполнять все поддерживаемые в языке Perl операции сравнения с ша- блонами. Утилита swatch может обработать конфигурационный файл за один вызов, но обычно она выполняется в фоновом режиме, отслеживая новые сообщения по мере их поступления, подобно команде tail -f. Недостатком является то, что конфигурацион- ный файл, по сути, нужно создавать с нуля. Утилита не “знает” об особенностях работы системы и о том, какие журнальные сообщения в ней генерируются.
408 Часть I. Основы администрирования Утилита logcheck — более простой сценарий интерпретатора sh. В дистрибутив входит также программа на языке С, которая помогает утилите запоминать текущую по- зицию в журнальном файле. Благодаря этому у сообщения меньше шансов пройти неза- меченным на этапе загрузки или останова системы. Утилита может запускаться перио- дически с помощью демона cron, а не выполняться постоянно. С утилитой logcheck поставляются базы шаблонов для нескольких версий UNIX и Linux. Даже если в самой утилите нет особой надобности, стоит просмотреть эти базы данных, так как в них могут содержаться очень интересные и полезные шаблоны. Недостаток этих утилит заключается в том, что за раз они обрабатывают только один журнальный файл. Если система Syslog направляет сообщения одновременно в несколь- ко файлов, приходится дублировать некоторые из сообщений в каком-нибудь централь- ном файле, который часто обнуляется, а затем передавать его на последующую обра- ботку одному из сценариев. Это проще, чем организовывать сложную сеть сценариев, управляющих несколькими журнальными файлами. Централизованная система ведения и анализа журналов регистрации Splunk (splunk. com) объединяет регистрационные и статусные сообщения от многих разных источни- ков в одну базу данных сообщений, доступную для поиска. Базовая версия этой системы распространяется бесплатно. Утилита SEC (Simple Event Correlator — простой коррелятор событий) представляет собой иной тип средства управления журнальными файлами. Она является сценарием Perl, который считывает строки из файлов, именованных каналов или из стандартного ввода и преобразует их в различные классы “входных событий”, сравнивая их с регуляр- ными выражениями. Затем в соответствии с правилами, определенными в конфигура- ции, программа преобразует входные события в такие выходные события, как выполне- ние конкретного сценария или передача сообщения указанному каналу или файлу. Дистрибутив SEC с подробной man-страницей и множеством примеров доступен по адресу: kodu.neti.ee/~risto/sec. Дополнительные примеры доступны на веб-сайте. Пакет SEC не является “полностью готовой к использованию” утилитой, как рассмо- тренные выше программы, но он может послужить хорошей отправной точкой для соз- дания специализированного средства анализа журнальных данных. Независимо от того, какая программа используется для сканирования журнальных файлов, есть ряд общих закономерностей. • Большинство сообщений, связанных с безопасностью, должно просматриваться немедленно. Важно отслеживать неудачные попытки входа в систему, равно как и неудачные вызовы команд su и sudo, чтобы предотвратить возможный взлом системы, пока еще не поздно. Если кто-то просто неправильно ввел свой пароль (как чаще всего бывает), то оперативное предложение помощи произведет хоро- шее впечатление и повысит репутацию системного администратора. • Сообщения о нехватке места на диске должны помечаться и немедленно обраба- тываться. Когда диск переполнен, работать с ним невозможно. • Многократно повторяемые события заслуживают внимания, хотя бы в профилак- тических целях. 11.6. Методы обработки журнальных файлов За прошедшие годы регистрационные события вышли из области системного ад- министрирования и превратились в сложнорешаемые проблемы в сфере управления
Глава 11. Система Syslog и журнальные файлы 40$ событиями на уровне предприятий. Обработка событий, связанных с безопасностью* стандарты информационных технологий и законодательные акты могут потребовать це- лостного и систематического подхода к управлению данными регистрации. Данные журналов регистрации от одной системы создают относительно небольшую нагрузку на устройства хранения, но ведение централизованного журнала регистрации событий от сотен серверов и десятков приложений — совсем другая история. В основ- ном, благодаря критически важной природе веб-служб, журналы регистрации, создаваем мые приложениями и демонами, по значимости вышли на уровень журналов регистра?* ции, генерируемых операционными системами. Разрабатывая стратегию обработки журнальных файлов, ответьте на следующие во- просы. • Сколько систем и приложений вы предполагаете использовать? • Инфраструктура хранения информации какого типа вам доступна? • Как долго вы собираетесь хранить журналы регистрации? • Какого типа события являются для вас значимыми? Ответы на эти вопросы зависят от требований, предъявляемых к бизнесу, и от при- меняемых вами стандартов или нормативных документов. Например, один стандарт от Совета по стандартам безопасности индустрии платежных карт (Payment Card Industry Security Standards Council — PCI SSC) требует, чтобы журналы регистрации хранились на носителе с простым доступом к данным (например, это может быть локально мон- тируемый жесткий диск) в течение трех месяцев и архивировались для долговременного хранения в течение, по крайней мере, одного года. Кроме того, этот же стандарт вклю- чает конкретные требования к типам используемых данных. Как бы вы ни ответили на предложенные выше вопросы, обязательно соберите вход- ную информацию из отделов по соблюдению правил и информационной безопасности, если таковые существуют в вашей организации. Системы UNIX и UNIX-приложения предусматривают использование легко конфи- гурируемых параметров регистрации и аудита. В зависимости от объемов использова- ния, возможно, вам придется сократить словесное наполнение журналов регистрации. И наоборот, какое-нибудь очень важное приложение может потребовать дополнитель- ных данных событийного характера. Для большинства приложений обычно рассматри- вают, как минимум, сбор следующей информации: • имя пользователя или его идентификатор (ID); • результат обработки события (успешная или нет); • адрес источника для сетевых событий; • дата и время (из такого официального источника, как NTP); • оповещение о добавлении, изменении или удалении важных данных; • подробные данные о событии. Большинство современных систем имеет тенденцию к использованию централизи- рованного подхода к накоплению и анализу журнальных файлов. Такая централизация имеет ряд преимуществ: упрощенные требования к хранению информации, более про- стые схемы автоматизированного анализа и предупреждений, а также усовершенство- ванная система безопасности. Кроме того, копирование событий в центральную систему способствует улучшению целостности журналов регистрации, поскольку она менее уяз- вима для взломщиков.
410 Часть I. Основы администрирования Ш Дополнительная информация о RAID приведена в разделе 8.7. Сервер регистрации должен работать в соответствии с тщательно разработанной стратегией хранения информации. Например, журналы регистрации могут храниться в локальном RAID-массиве в течение 30 дней, в локально монтируемой сети устройств хранения данных (Storage Area Network — SAN) — еще в течение года и, наконец, по- сле архивирования — на лентах для включения в ротацию резервных копий на уровне предприятия — еще в течение трех лет. Требования к хранению данных могут со време- нем меняться, и реализация может легко и успешно адаптироваться к изменению этих условий. Доступ к централизированным серверам регистрации должен быть ограничен си- стемными администраторами высокого уровня, программами и персоналом, задейство- ванным в решении вопросов безопасности и адресной совместимости. В рамках органи- заций эти системы обычно не играют главную роль при принятии ежедневных решений за рамками удовлетворения требований к возможности проведения аудита, поэтому ад- министраторы приложений, конечные пользователи и служба технической поддержки не имеют доступа к ним. Доступ к регистрационным файлам на центральных серверах должен регистрироваться отдельно. Организация централизированной регистрации требует определенных усилий, и в не- больших системах она может не продемонстрировать преимущества от использования сети. Для обеспечения централизации мы предлагаем в качестве разумной пороговой величины использовать двадцать серверов. При меньшем количестве необходимо га- рантировать, что журналы регистрации подвергаются надлежащей ротации и архивиро- ванию с частотой, достаточной для того, чтобы избежать заполнения диска. Включите регистрационные файлы в решение по мониторингу, чтобы вы были извещены в случае, если некоторый журнал регистрации перестанет увеличиваться в размере. 11.7. Упражнения 11.1. Зачем хранить старые журнальные файлы? 11.2. В чем разница между файлами lastlog и wtmp? Какой должна быть схема рота- ции для каждого из них? 11.3. Проанализируйте следующую запись файла syslog. conf: *.notice;kern.debug;Ipr.info;mail.crit;news.err /var/log/messages Есть ли в ней смысл? 11.4. Поищите в журнальных файлах записи от службы SSH. Какие события регистри- руются при успешной попытке входа в систему? А при неудачной попытке? Какие действия следовало бы предпринять для увеличения словесного наполнения про- цесса регистрации демона SSH? 11.5. Многие стандарты и нормативные документы в индустрии информационных тех- нологий налагают определенные требования, связанные с регистрацией или ау- дитом. Выберите один из таких стандартов и рассмотрите варианты настройки конфигурации системы Syslog для достижения соответствия выдвигаемым требо- ваниям. 11.6. ★ Где расположен журнал начальной загрузки на вашем Linux-компьютере? В чем трудности журнальной регистрации на этапе начальной загрузки? Как эти труд- ности решаются демоном klogd?
Глава 11. Система Syslog и журнальные файлы 411 11.7. ★ Проанализируйте схему журнальной регистрации, используемую в вашей ор- ганизации, включая схему ротации журнальных файлов. Сколько дискового про- странства отведено для журнальных файлов? Насколько долго хранятся журналь- ные файлы? Можно ли заранее предсказать ситуации, когда используемых схем окажется недостаточно? Какое решение можно порекомендовать? (Необходим до- ступ с правами суперпользователя.) 11.8. ★ Некоторые журнальные сообщения являются чрезвычайно важными и должны немедленно просматриваться системным администратором. Что можно предпри- нять для того, чтобы это произошло как можно скорее?
Глава 12 Управление программным обеспечением и конфигурацией Инсталляция программных средств, их конфигурирование и управление ими — ос- новные обязанности системных администраторов. Они отвечают на запросы пользовате- лей инсталлировать и сконфигурировать программы, усовершенствовать средства защи- ты их данных и устранить прорехи в системе безопасности, а также управляют переходом к новым версиям программ, которые, с одной стороны, предлагают новые возможности, а, с другой стороны, чреваты проблемами несовместимости. Администраторам обычно приходится выполнять перечисленные ниже задачи: • осуществлять автоматизированную инсталляцию операционной системы на груп- пу компьютеров; • выполнять настройку операционных систем в локальных средах; • следить за выходом “заплат” и своевременно обновлять с их помощью систему и приложения; • управлять добавочными программными пакетами. Процесс конфигурирования готового дистрибутива или программного пакета, на- правленный на удовлетворение всех ваших потребностей (и не допускающий наруше- ния локальных условий защиты, размещения файлов и топологии сети), часто называют “локализацией”. В этой главе рассматриваются методики, которые позволяют упростить инсталляцию программного обеспечения, в том числе в крупных системах. Мы также рассмотрим процедуру инсталляции для каждого из наших примеров операционных си- стем, включая некоторые возможности автоматизации, использующие распространен- ные инструменты (предназначенные для конкретной платформы).
Глава 12. Управление программным обеспечением и конфигурацией 415 12.1. Инсталляция систем Linux и OpenSolaris Процедура инсталляции всех современных дистрибутивов Linux довольно проста. Для OpenSolaris действует множество таких же соглашений, так что процесс инсталля- ции этой системы практически не отличается от установки Linux, особенно на персо- нальные компьютеры. Обычно для инсталляции необходимо загрузиться с DVD-диска, ответить на ряд во^ просов, по выбору сконфигурировав разделы диска, и указать программе-инсталлятору, какие программные пакеты нужно установить. Такие системы, как Ubuntu и OpenSolaris, включают опцию “live”, которая позволяет запускать операционную систему, не инстал- лируя ее в действительности на локальный диск. Это очень полезная особенность упо- мянутых систем, но в наши дни она стала практически стандартной функцией большин- ства дистрибутивов. Инсталляция базовой операционной системы с локального носителя представляет со- бой довольно тривиальную операцию благодаря GUI-приложениям, которые “проведут” вас через все этапы этого процесса. В табл. 12.1 перечислены указатели на подробные инструкции по инсталляции для каждого из наших примеров дистрибутивов. Таблица 12.1. Документация по инсталляции для систем Linux и OpenSolaris J ..""-... 11111 11 111111 . " ч1 w Диетрибугиа Red Hat Enterprise Linux redhat. com/docs/manuals/enterprise SUSE en.opensuse.org/Installation Ubuntu help. ubuntu. com/community/ Installation OpenSolaris die • sun. com/osol/docs/content/dev/getstart Загрузка по сети на персональном компьютере Любой, кому придется инсталлировать систему сразу на несколько компьютеров, столкнется с недостатками инсталляции в интерактивном режиме. Это большие затра- ты времени, “предрасположенность” к ошибкам и скучная необходимость повторения стандартного процесса инсталляции на сотнях систем. Свести к минимуму “ошибки че- ловеческого фактора” можно благодаря контрольному списку локализации, хотя даже его использование не сможет полностью защитить от всевозможных ошибок. Для того чтобы ослабить воздействие перечисленных выше факторов, большинство систем включает возможности инсталляции по сети, которые упрощают проведение крупномасштабных установочных мероприятий. В самых распространенных методах для загрузки системы без использования физического носителя используются сетевые протоколы DHCP и TFTP, после чего из сетевого сервера извлекаются файлы инсталля- ции через протоколы HTTP, NFS или FTP. Сетевые варианты инсталляции подходят для узлов с количеством систем более десяти. Предзагрузочная среда выполнения (Preboot execution Environment — РХЕ), предна- значенная для загрузки компьютеров с помощью сетевой карты без использования жест- ких дисков, стала стандартом (разработанным фирмой Intel), который позволяет загру- жать системы через сетевой интерфейс. Стандарт РХЕ действует подобно миниатюрной операционной системе, размещенной в схеме ПЗУ на вашей сетевой плате. Он пред- лагает системе BIOS использовать его сетевые особенности посредством стандартизиро- ванного API. При таком взаимодействии один загрузчик может загружать по сети one-
414 Часть I. Основы администрирования рационную систему на любом персональном компьютере, понимающем стандарт РХЕ, не устанавливая при этом какие-либо специальные драйвера для каждой сетевой платы. Ш Более подробно о DHCP можно почитать в разделе 14.7. Внешняя (сетевая) часть протокола РХЕ не содержит никаких сложностей и подоб- на процедурам загрузки по сети, используемым в других архитектурах. Компьютер осу- ществляет широковещательную рассылку специального DHCP-запроса с установленным РХЕ-флагом, а DHCP-сервер или прокси-сервер возвращает DHCP-пакет, содержащий значения РХЕ-параметров (имя загрузочного сервера плюс имя загрузочного файла). Клиент получает от сервера свой загрузочный файл по протоколу TFTP (возможно ис- пользование многоадресной версии этого протокола), после чего запускает его. Конфигурирование протокола РХЕ в Linux Существует несколько загрузочных систем на основе РХЕ, однако самой безотказной в настоящее время является система PXELINUX, разработанная Питером Анвином (Н. Peter Anvin). Она является частью комплекта загрузчиков SYSLINUX, разработанного им же, который может пригодиться на все случаи жизни. Домашняя страница этой системы расположена по адресу syslinux.zytor.com. PXELINUX содержит загрузочный файл, который инсталлируется в каталог tf tpboot сервера и загружается на загружаемый ПК во время работы РХЕ. ПК выполняет загру- зочный файл и загружает его конфигурацию с сервера; конфигурация определяет, какое ядро необходимо использовать. Эта цепочка событий может быть выполнена без вашего вмешательства; как вариант, можно создать специальное меню загрузки. PXELINUX использует для своих загрузок РХЕ API и поэтому не зависит от аппарат- ной части в течение всего процесса загрузки. Более того, она может загружать не только Linux, но и другие операционные системы, а также может загружать устаревшие обра- зы дискет, если вы используете ядро MEMDISK, которое тоже входит в состав пакета SYSLINUX. На стороне сервера лучше всего использовать DHCP-сервер организации ISC (Internet Systems Consortium’s). См. также материал на сайтах netboot.me и boot, kernel.org. Дистанционная загрузка на специализированных компьютерах РХЕ — это протокол компании Intel, и его применение ограничено платформами IA- 32 и IA-64. На других платформах применяются иные методы загрузки по сети, которые почти всегда более элегантные, чем протокол РХЕ. Интересно, что сейчас, когда Linux часто инсталлируется на компьютеры с архитектурой, отличной от Intel, многие из “спе- циализированных” UNIX-систем теперь имеют вариант, при котором по сети загружает- ся Linux, а не “родная” операционная система. Компьютеры SPARC и большинство систем PowerPC используют программу Open Firmware, которую легко загрузить по сети (достаточно ввести команду boot net). Системы IBM и HP также оснащены средствами загрузки по сети, но конкретные процедуры в большой степени зависят от программных пакетов Network Installation Manager (менеджер сетевой инсталляции) и Ignite-UX соответственно. Мы рассмотрим эти инструменты ниже, но только в контексте инсталляции операционных систем. За подробностями сетевой инсталляции обратитесь к документации компаний IBM и HP.
Глава 12. Управление программным обеспечением и конфигурацией 415 Использование Kickstart — автоматизированного инсталлятора Red Hat Enterprise Linux Kickstart — это утилита, предназначенная для автоматической инсталляции программного обеспечения Red Hat. Она представляет собой интерфейс к стан- дартному инсталлятору Red Hat — программе Anaconda — и зависит как от вер- сии дистрибутива, так и от имеющихся пакетов RPM. Утилита Kickstart до- статочно гибкая и автоматически распознает аппаратное обеспечение системы. Создание файла конфигурации для утилиты Kickstart Работа утилиты Kickstart контролируется конфигурационным файлом, который обычно называется ks. cf g. Формат этого файла довольно прост. Для тех, кто не любит работать с текстовыми файлами, существует графическая утилита system-config-kickstart, упрощающая настройку конфигурационного файла. Файл ks. cf g можно также очень легко генерировать программным путем. Предпо- ложим, что на серверах и клиентах необходимо инсталлировать разные наборы паке- тов; предположим также, что у вас есть два офиса и вам нужно, чтобы система была настроена в них по-разному. Тогда следует написать небольшой Perl-сценарий, который с помощью соответствующих параметров будет генерировать конфигурационные файлы для серверов и клиентов каждого офиса. В случае изменения набора пакетов достаточно будет отредактировать Perl-сценарий, а не многочисленные конфигурационные файлы. Бывают также ситуации, когда для каждого компьютера нужен свой конфигурационный файл. Тогда тем более необходимо автоматизировать создание таких файлов. Конфигурационный файл утилиты Kickstart состоит из трех упорядоченных частей. Первая из них — это раздел команд, где задаются такие установки, как язык, раскладка кла- виатуры и часовой пояс. Здесь же с помощью параметра url задается источник, из которого загружается дистрибутив (в показанном ниже примере это компьютер installserver). text lang en_US # Язык, используемый в процессе инсталляции... langsupport en_US # ... и на этапе выполнения. keyboard us # Американская раскладка клавиатуры. timezone —utc America/EST # Аргумент —utc означает, что часы # синхронизируются по Гринвичу mouse rootpw —iscrypted $l$NaCl$X5jRlREy9DqNTCXjHpO75/ reboot # Перезагрузка после инсталляции. # Это почти всегда необходимо. bootloader —location=mbr # Стандартный загрузчик инсталлируется # в главную загрузочную запись. install # Новая система инсталлируется, # а не обновляется. url —url http://installserver/redhat clearpart —all -initlabel # Удаляются все существующие разделы part / —fstype ext3 —size 4096 part swap —size 1024 part /var —fstype ext3 -size 1 —grow network —bootproto dhcp auth —useshadow —enablemd5 firewall —disabled xconfig —defaultdesktop=GNOME —startxonboot —resolution 1280x1024 —depth 24
416 Часть I. Основы администрирования По умолчанию утилита Kickstart работает в графическом режиме, что препятствует ее автоматическому запуску. Ключевое слово text в начале файла исправляет данную ситуацию. Параметр rootpw задает пароль суперпользователя на новом компьютере. По умол- чанию пароль указывается в текстовом виде, что создает проблему с точки зрения без- опасности. Всегда пользуйтесь опцией —iscrypted, чтобы задать зашифрованный па- роль. Для зашифрованного пароля прекрасно работают записи паролей из файла /etc /shadow либо вы можете попробовать утилиту /sbin/grub-md5-crypt в уже постро- енной системе. Директивы clearpart и part задают список разделов с указанием их размеров. С по- мощью опции —grow можно отвести всю оставшуюся область жесткого диска под один из разделов. Так можно облегчить подгонку систем с разными размерами жестких дис- ков. Такие усовершенствованные опции разбиения на разделы, как использование ме- неджера логических томов (Logical Volume Manager — LVM), поддерживаются утилитой Kickstart, но не инструментом system-config-kickstart. Обратитесь к встроенной в систему Red Hat оперативно-доступной документации за полным списком параметров форматирования дисков. Во втором разделе файла приведен список инсталлируемых пакетов, начинающий- ся с директивы %packages. В списке могут быть указаны отдельные пакеты, коллекции (например, @ GNOME) либо запись @ Everything, обозначающая весь имеющийся на- бор пакетов. В первом случае задается лишь имя пакета, без номера версии и расшире- ния . rpm. Приведем пример. %packages @ Networked Workstation @ X Window System @ GNOME mylocalpackage В третьем разделе конфигурационного файла указывается произвольный набор ко- манд интерпретатора, которые подлежат выполнению утилитой Kickstart. Существует два возможных набора команд. Один из них начинается с директивы %рге и содержит команды, выполняемые перед началом инсталляции. Команды, выполняемые по завер- шении инсталляции, помечаются директивой %post. В обоих случаях возможности си- стемы по распознаванию имен компьютеров ограничены, так что лучше пользоваться IP-адресами. Кроме того, команды второго набора выполняются в среде с измененным корневым каталогом, поэтому они не имеют доступа к инсталляционному носителю. Создание сервера Kickstart Утилита Kickstart ожидает, что ее инсталляционные файлы расположены так же, как и на инсталляционном компакт-диске. На сервере ее пакеты должны находиться в ката- логе RedHat/RPMS. В этот каталог разрешается добавлять собственные пакеты. Но есть ряд нюансов, о которых следует помнить. Главная особенность заключается в том, что, получив команду инсталлировать все па- кеты (запись @ Everything в разделе пакетов файла ks. cfg), утилита сначала устанав- ливает базовые пакеты, а затем — пользовательские, причем в алфавитном порядке. Если какой-то пользовательский пакет зависит от других пакетов, не входящих в базовый на- бор, назовите его наподобие zzmypackage. rpm, чтобы он инсталлировался последним. Если не требуется инсталлировать все пакеты, укажите нужные в разделе %packages файла ks. cfg либо добавьте их в одну или несколько коллекций. Коллекции обознача-
Глава 12. Управление программным обеспечением и конфигурацией ются записями вида @ GNOME и представляют собой предопределенные наборы пакетов, компоненты которых перечислены в файле RedHat/base/comps на сервере. К сожалев нию, формат этого файла плохо документирован. Коллекции задаются в строках, кото- рые начинаются с цифры 0 или 1; единица указывает на то, что коллекция выбрана по умолчанию. Менять стандартные коллекции нежелательно. Мы рекомендуем оставить их в том виде, в котором они определены в Red Hat, и указывать дополнительные паке- ты непосредственно в файле ks. cfg. Задание пользовательского конфигурационного файла После создания конфигурационного файла необходимо заставить утилиту Kickstart использовать его. Это можно сделать несколькими способами. Официальный способ — загрузиться с DVD-диска и запросить инсталляцию Kickstart, введя linux ks в строке приглашения prompt:. Если не указать дополнительных аргументов, система опреде- лит свой сетевой адрес по протоколу DHCP. Затем она узнает имя загрузочного DHCP- сервера и загрузочного файла, попытается смонтировать серверный каталог через NFS и установит загрузочный файл в качестве конфигурационного. При отсутствии сведений о загрузочном файле система будет искать файл /kickstart/ 1Р_адрес_узла-к1скзЬагЬ. Другой способ задания конфигурационного файла заключается в указании пути к не- му в виде аргумента опции ks. Здесь есть несколько возможных вариантов. Команда boot: linux ks=http:сервер:/path заставляет утилиту Kickstart загрузить конфигурационный файл по протоколу HTTP, а не через NFS. Аргумент ks=f loppy заставляет утилиту искать файл ks. cfg на локаль- ном гибком диске. Для того чтобы вообще не использовать загрузочный носитель, вам нужно научиться работать с протоколом РХЕ. Подробно о нем речь шла в начале этой главы. Использование AutoYaST: автоматизированный инсталлятор SUSE YaST2 — это универсальная утилита инсталляции и конфигурирования SUSE. Она имеет привлекательный графический интерфейс и очень удобна в исполь- зовании при инсталляции одной системы. Ее автоматизированный эквива- лент, AutoYaST, можно назвать самой мощной инсталляционной программой из всех дистрибутивов, описанных в этой книге. Подробную документацию можно загрузить с адреса suse. com/~ug/autoyast_doc. SUSE разбивает процесс автоматической инсталляции на три фазы: подготовка, ин- сталляция, конфигурирование. Первоначальная подготовка выполняется с помощью модуля AutoYaST (YaST2). suse$ /sbin/yast2 autoyast Этот модуль помогает указать детали требуемой установки. Результатом выполнения этого модуля является управляющий XML-файл, который сообщает инсталлятору о спо- собе конфигурирования системы SUSE; структура файла описана в интерактивном до- кументе, упомянутом выше. Процесс конфигурирования можно ускорить. Модуль AutoYaST может читать кон- фигурационные файлы Kickstart, помогая модернизировать “устаревшие” системы. Если вам понадобится продублировать конфигурацию на компьютере, на котором вы рабо- таете в настоящий момент, то на этот случай тоже есть вариант автоматизации.
418 Часть I. Основы администрирования Для того чтобы произвести инсталляцию, вам понадобится следующее: • сервер DHCP с той же маской подсети, что и компьютер, на котором вы плани- руете выполнить инсталляцию; • инсталляционный сервер SUSE или хранилище пакетов; • сервер, на котором будет размещена информация о конфигурации, необходимая для инсталляции. Последний из этих серверов может предоставить конфигурационные файлы по одно- му из протоколов, предлагаемых вам на выбор, — HTTP, NFS или TFTP. При обычной установке нужно создать управляющий файл для каждого компьютера, на котором вы планируете произвести инсталляцию. AutoYaST использует IP-адрес кли- ента, чтобы определить, какой управляющий файл следует использовать. Этот подход не будет эффективным, если нужно произвести инсталляцию на ряде компьютеров, немно- го отличающихся друг от друга. С помощью системы правил можно создавать более сложные инсталляции. На осно- вании таких характеристик системы, как размер диска, идентификатор компьютера или доступность PCMCIA, разные управляющие файлы подгоняются под искомую систему. Содержимое всех выбранных управляющих файлов объединяется, причем в случае воз- никновения конфликтов содержимое последнего управляющего файла перекрывает со- держимое предыдущего файла. (Управляющий файл не должен определять все аспекты конфигурации системы, поэтому такое объединение имеет смысл.) Управляющие файлы могут также определять “классы” компьютеров на основе их имен или диапазонов IP-адресов. Каждый класс может иметь связанный с ним вспомо- гательный управляющий файл. Компьютеры могут не относиться к классам, могут от- носиться к одному классу или к множеству классов, а их конфигурации будут включать содержимое всех управляющих файлов соответствующего класса. Благодаря объединению содержимого множества управляющих файлов, структура AutoYaST позволяет определять сложные установки с минимальной избыточностью. Человеку трудно воспринимать то, что написано в управляющем XML-файле, зато про- цесс может с легкостью не только читать эти файлы, но и редактировать их с помощью обычных доступных средств обработки XML-данных. Автоматизированная инсталляция систем Ubuntu ©Инсталлятор Debian (он называется debian-installer) рекомендуется исполь- зовать в качестве варианта “предварительной” автоматизированной инстал- ляции системы Ubuntu. Как и в случае Kickstart, файл предварительной кон- фигурации отвечает на вопросы, задаваемые инсталлятором. При выполнении “предварительной” инсталляции нельзя использовать существующие разделы диска: в этом случае либо задействуется существующее свободное простран- ство, либо выполняется перераспределение всего диска. Все интерактивные части инсталлятора Debian используют утилиту debconf, что- бы решить, какие вопросы нужно ставить и какие ответы использовать по умолчанию. Предоставив утилите debconf базу данных с заранее сформулированными вопросами, вы можете полностью автоматизировать работу инсталлятора. Вы можете или сгенери- ровать базу данных вручную (она представляет собой обычный текстовый файл), или выполнить интерактивную инсталляцию на тестовой системе, а затем передать свои от- веты утилите debconf с помощью следующих команд.
Глава 12. Управление программным обеспечением и конфигурацией 4W ubuntu$ sudo debconf-get-selections —installer > preseed.cfg ubuntu$ sudo debconf-get-selections » preseed.cfg Создайте конфигурационный файл, который будет доступен по сети, и передайте его в ядро во время инсталляции с помощью следующего аргумента ядра. preseed/url=http://host/path/to/preseed Синаксис “предынсталляционного” файла, обычно именуемого preseed.cfg, до- вольно прост и во многом сходен с Red Hat-файлом ks. cfg. Следующий пример пред- ставлен в сокращенном виде. d-i debian-installer/locale string en_US d-i console-setup/ask_detect boolean false d-i console-setup/layoutcode string us d-i netcfg/choose_interface select auto d-i netcfg/get_hostname string unassigned-hostname d-i netcfg/get_domain string unassigned-domain d-i netcfg/wireless_wep string d-i partman-auto/disk string /dev/sda d-i partman-auto/method string Ivm d-i partman-auto/choose_recipe select atomic d-i passwd/user-fullname string Daffy Duck d-i passwd/username string dduck d-i passwd/user-password-crypted password $l$/mkq9/$G//i6tN.x6670.951VSM/ d-i user-setup/encrypt-home boolean false tasksei tasksel/first multiselect ubuntu-desktop d-i grub-installer/only_debian boolean true d-i grub-installer/with_other_os boolean true d-i finish-install/reboot_in_progress note xserver-xorg xserver-xorg/autodetect_monitor boolean true Ряд опций в этом листинге просто запрещают диалоги, которые обычно требуют взаимодействия с пользователем. Например, опция ask_detect запрещает выбор рас- кладки клавиатуры. Аналогично опция wireless_wep предотвращает вопросы о ключах WEP (Wireless Encryption Protocol — протокол шифрования в беспроводной связи). Такая конфигурация старается идентифицировать сетевой интерфейс, который в дей- ствительности подключен к сети (choose_interfасе select auto) и получает се- тевую информацию через протокол динамического конфигурирования узла DHCP. Предполагается, что значения системного имени главного компьютера и домена предо- ставляются протоколом DHCP и не переопределяются. Наличие partman-строк свидетельствует о том, что для сегментирования дисковой памяти используется пакет partman-auto. Если система имеет несколько дисков, то Для инсталляции вы должны указать нужный диск. В противном случае (т.е. для един- ственного диска) используется значение /dev/sda. Предлагается несколько “рецептов” сегментирования дисковой памяти: • вариант atomic помещает все системные файлы в один раздел; • вариант home создает отдельный раздел для каталога /home; • вариант multi создает отдельные разделы для каталогов /home, /usr, /var и /tmp. Вы можете создавать пользователей посредством ряда директив passwd. Как в слу- чае Kickstart-конфигурации, мы настоятельно рекомендуем использование хеширован-
420 Часть I. Основы администрирования ных МВ5-значений паролей. Файлы предварительной инсталляции часто хранятся на HTTP-серверах и могут быть обнаружены любопытными пользователями. (Безусловно, МВ5-пароль постоянно является Объектом для грубых силовых атак.) Опция выбора задачи (tasksei) позволяет указать тип подлежащей инсталляции Ubuntu-системы из предложенных вариантов: standard, ubuntu-desktop, dns-server, lamp-server, kubuntu-desktop, edubuntu-desktop и xubuntu-desktop. Представленный выше пример файла предварительной инсталляции взят из доку- ментации по инсталляции системы Ubuntu, доступной по адресу: help.ubuntu.com. Руководство содержит полную документацию по синтаксису и применению файла пред- варительной инсталляции. Несмотря на то что происхождение системы Ubuntu не связано с “родословной” Red Hat, на ее собственный базовый инсталлятор “привита” совместимость с управляющими Kickstart-файлами. Кроме того, Ubuntu включает утилиту system-config-kickstart для создания этих файлов. В инсталляторе Kickstart для системы Ubuntu опускается ряд важных функций, которые поддерживаются Red Hat-инсталлятором Anaconda (напри- мер, LVM и конфигурация брандмауэра). Если у вас нет веской причины для выбора Kickstart, мы все же рекомендуем использовать инсталлятор Debian. 12.2. Инсталляция Solaris Подобно многим поставщикам аппаратных средств, компания Sun вводит новые серверы с предварительно инсталлированной системой Solaris. Администратору нужно лишь ответить на несколько коротких вопросов и перезагрузить сервер, и операционная система будет готова для локализации. С годами мы оценили эту функцию предвари- тельной инсталляции, поскольку инсталлятор Solaris мы считали отвратительным. Но команда OpenSolaris, можно сказать, “одумалась”, и ее новый инсталлятор (первона- чально названный “Caiman”) заслуживает уважения. В настоящее время для инсталляции Solaris предлагается “живой” компакт-диск, ко- торый предоставляет возможность “опробовать перед покупкой”, подобную реализован- ной в системе Ubuntu. Процесс инсталляции системы чрезвычайно прост и перед уста- новкой на локальный диск предусматривает ответы всего на несколько вопросов. Как и в мире Linux, администраторам Solaris нужен способ реализовать множество инсталляций систем по сети. Подобно своим Linux-ориентированным “собратьям”, си- стемы Solaris, построенные на базе процессоров Intel, для помощи в сетевой загрузке могут использовать серверы РХЕ. Системы с процессорами SPARC используют ППЗУ OpenBoot PROM, также известное под именем ОВР. К ОВР обычно можно получить доступ с помощью комбинации клавиш <STOP+A> (на клавиатуре Sun). Посредством соответствующих команд ОВР позволяет идентифицировать оборудование и выполнить его диагностику, выявить сбойные ситуации, а также передать процесс загрузки более интеллектуальному начальному загрузчику, подобно тому как действует BIOS в системах Intel. При этом ОВР отличается большим количеством функций (по сравнению с боль- шинством PC BIOS), включающих встроенную поддержку загрузки системы по сети. Средство сетевой загрузки через протокол DHCP или RARP получает IP-адрес, а затем загружает ядро через протокол TFTP. Загруженное для автоматизированной ин- сталляции, ядро подключается к серверу HTTP или монтирует общую сетевую файло- вую систему (NFS) для загрузки соответствующего образа системы и запускает процесс инсталляции. Solaris предлагает два метода автоматической сетевой инсталляции:
Глава 12. Управление программным обеспечением и конфигурацией 424 • JumpStart — традиционная служба инсталлятора, разработанная компанией Sun; • Automated Installer — служба замены, используемая системой OpenSolaris. JumpStart — старое средство инсталляции, которое сначала появилось в Solaris 2.6 и может быть использовано во всех версиях, вплоть до Solaris 10. Подобно большинству методов автоматической инсталляции, служба JumpStart использует файлы предопреде- ленных ответов и выбор клиента на основе правил, что автоматически обеспечивает вы- бор инсталляции. Самый большой недостаток JumpStart — слабая масштабируемость. Каждого клиента нужно добавлять в сервер вручную для инсталляции посредством МАС-адреса. В файлах конфигурации задаются типы инсталляции, значения конфигурации и другие параме- тры для каждого клиента в отдельности. Это усиливает возможности администраторов (в частности, увеличивает гибкость в управлении), но такие файлы конфигурации стано- вятся очень громоздкими в среде с сотнями или тысячами систем. Служба Automated Installer (Al) — это новинка. Основные цели ее разработки — улуч- шить масштабируемость и возможности конфигурации. AI уходит корнями в JumpStart, но дистанцируется частично благодаря использованию новой терминологии. Пока пи- сались эти строки, служба AI оставалась все еще в процессе разработки, но ее можно считать практически готовой для использования в коммерческих целях. Больше всего ограничений AI имеет для последних версий системы OpenSolaris и в настоящее время не работает на всех традиционных версиях Solaris. Сетевые инсталляции с помощью JumpStart Исходной целью службы JumpStart было просто разрешить инсталляцию Solaris по сети, но у нее есть все возможности и для автоматической инсталляции. Через некото- рое время в компании Sun поняли, что автоматизированные инсталляции требуют более тонкого управления, поэтому и были добавлены расширенные средства, которые сейчас продублированы в Custom JumpStart. Автоматизированная сетевая инсталляция Custom JumpStart включает несколько компонентов. • Сервер инсталляции, который принимает инсталляционный носитель. Один сер- вер инсталляции может обслуживать носители для нескольких типов инсталля- ции, например различных версий системы Solaris, или поддерживать несколько платформ. • Сервер начальной загрузки, который помогает клиентам выполнять начальную за- грузку и направляет их на серверы инсталляции. Сервер начальной загрузки не- обходим лишь в случае, если система клиента и сервер инсталляции находятся в различных подсетях. • Ряд файлов, которые идентифицируют клиентов, отвечают на вопросы по конфи- гурации и выбирают пакеты. • NFS- или HTTP-сервер, который использует пакеты, файлы инсталляции и ин- формацию о конфигурации. Компоненты на стороне сервера могут размещаться на одном и том же компьюте- ре. Серверы не зависят от версии инсталлируемой системы и используемой платформы. Например, сервер загрузки и инсталляции для SPARC-ориентированной системы Sola- ris 9 может предложить услуги по инсталляции для клиентов х86 Solaris 10. Поскольку параметры сетевой загрузки могут быть включены в DHCP-ответы, вы можете использовать DHCP-сервер в качестве альтернативы для специализированного
422 Часть I. Основы администрирования сервера начальной загрузки JumpStart. Возможно, протокол DHCP является более при- емлемым вариантом для систем х86, которые используют РХЕ-загрузку, и для клиент- ских систем, расположенных в разных подсетях по отношению к серверу инсталляции. Здесь мы рассмотрим только случай расположения клиента и сервера в одной подсети (за подробностями обращайтесь по адресу: docs. sun.com/doc/817-5504). Установка сервера инсталляции довольно проста. Инструменты установки можно найти на компакт- или DVD-диске Solaris. Вставьте Solaris-носитель в дисковод сервера инсталляции и выполните следующие команды, чтобы сконфигурировать простой сер- вер инсталляции. solaris$ sudo mkdir -р / jumps tar t/s 10 spare solaris$ cd /cdrom/cdrom0/s0/Solaris_10/Tools solaris$ sudo . /setup_install_server /jumpstart/slOsparc Здесь мы переносим SPARC-файлы инсталляции в каталог /jumpstart/siOsparc сервера инсталляции. Сценарий setup_install_server копирует эти файлы и добав- ляет соответствующие “ловушки” для сетевых инсталляций. Если в вашем распоряже- нии есть только компакт-диски, то для копирования их содержимого на сервер исполь- зуйте команду add_to_install_server. Задачи автоматизированной инсталляции конфигурируют несколько файлов: • файл rules идентифицирует клиентов и назначает профили инсталляции; • отдельные файлы профилей задают схему разделов диска, инсталлируемые пакеты и прочие системные данные; • файл sysidefg предоставляет предварительно сконфигурированные ответы на вопросы инсталляции; • сценарии оболочки могут выполняться до и после процесса инсталляции (по не- обходимости). Когда клиент запрашивает сетевую инсталляцию, JumpStart использует файл rules, чтобы идентифицировать клиента в соответствии с такими атрибутами, как имя узла клиента, подсеть или модель. Если атрибуты совпадают, JumpStart считывает содержи- мое соответствующего профиля, отвечает на вопросы инсталляции с помощью файла sysidefg и выполняет пользовательские сценарии до и после инсталляции. Первый шаг в создании JumpStart-конфйгурации состоит в создании каталога для хранения всех файлов конфигурации. solaris$ sudo mkdir -m 755 /jumpstart/config Этот каталог должен быть открыт для совместного пользования через протокол NFS или HTTP, чтобы клиенты могли получить к нему доступ. Например, для протокола NFS добавьте строку share -F nfs /jumpstart в файл /etc/dfs/dfstab и выполните команду shareall, чтобы инициализировать службу NFS. Синаксис файла rules простой, но мощный. Системы могут быть идентифициро- ваны по сети, имени узла, модели, имени домена или по многим другим атрибутам1. В следующем файле rules указывается один профиль для систем в сети 192.168.10.0, а другой — для систем SPARC, которые оснащены 2—4 Гбайт памяти. 1 Для того чтобы получить доступ к Sun-руководству, которое содержит подробные сведения о файле rules и файлах профилей, используйте Google-pecypc, задав в строке поиска текст “Custom JumpStart and Advanced Installations”.
Глава 12. Управление программным обеспечением и конфигурацией 423 network 192.168.10.0 - profile_a - arch spare && memsize 2048-4096 begin profile_b end В этом примере сети нет пользовательских сценариев, но используется профиль ин- сталляции prof ile__а. В другом примере применяются сценарии begin и end, а такхи. профильный файл prof ile_b. Файлы профилей также просты. Файловые системы и типы инсталляции задаются с помощью ключевых слов (их очень много). Вот как может выглядеть пример профиле install_type initial_install ' ‘ system_type standalone partitioning default filesys any 512 swap # Задаем размер /swap cluster SUNWCpall Процесс инсталляции типа initial—install начинается с чистого списка, в про- тивоположность выполнению модернизации. Этот профиль использует стандартную схему сегментирования дисковой памяти. Строка cluster SUNWCpall идентифицирует “группу инсталляции” пакетов; в данном случае это доступные Solaris-пакеты. Файл sysidefg, который предварительно конфигурирует другие аспекты инсталля- ции, состоит из строк следующего формата. Ключев ое_ слов о=зна чение Ключевые слова не различаются по прописным и строчным буквам и, за исключе- нием ключевого слова network-interface, могут употребляться лишь один раз. Если ключевое слово используется несколько раз, учитывается только его первый экземпляр. Некоторые ключевые слова зависят от других и могут заключаться в фигурные скоб- ки. Такие зависимые ключевые слова не могут быть использованы, если не задано соот- ветствующее родительское (независимое) ключевое слово. Независимые ключевые слова перечислены в табл. 12.2. О зависимых ключевых словах можно узнать, обратившись к man-странице, посвященной файлу sysidefg. Таблица 12.2. Независимые ключевые слова для JumpStart-файла sysidefg Ключевое слово *|гоздао1ф£йеляет -.Л-- keyboard name—service network—interface nfs 4—domain rootjaassword security-policy service-profile system-locale terminal timeserver timezone Раскладка клавиатуры и язык Конфигурация службы имен для NIS, DNS или LDAP Информация о подключении к сети: имя узла, IP-адрес и т.д. Домен, предназначенный для NFS версии 4 Зашифрованный пароль пользователя root Сетевой протокол аутентификации Kerberos Доступные сетевые службы Язык системы Тип терминала Сетевой сервер даты и времени Часовой пояс системы В качестве альтернативы для файла sysidefg можно использовать ограниченный набор параметров предварительной конфигурации, которые задаются через протокол DHCP или с помощью такой сетевой службы, как DNS. Однако мы рекомендуем ис- пользовать файл sysidefg, поскольку альтернативный вариант позволяет задать огра- ниченный набор параметров.
424 Часть I. Основы администрирования В следующем примере файла sysidcfg конфигурируется система sake, которая имеет один сетевой интерфейс. keyboard=US-English system_locale=en_US timezone=US/Mountain terminal=sun-cmd timeserver=time.nist.gov name service=DNS {domain_name=solaris.booklab.atrust.com name_server=192.168.2.10 search=atrust.com,booklab.atrust.com} nfs4_domain=dynamic root_password=m4QP0WNY network_interface=elOOOgO {hostname=sake default_route=192.168.10.254 ip_address=192.168.10.15 netmask=255.255.255.0} Если вы передаете один и тот же файл sysidcfg нескольким клиентам, 1Р-адрес, безусловно, позволит различать системы. Для того чтобы принудительно сконфигури- ровать сетевой интерфейс при первой загрузке системы, вы можете не включать эти данные в файл. Или же, чтобы получить сетевой адрес от протокола динамической кон- фигурации узла DHCP (вместо статического его назначения), используйте следующую строку. network_interface=elOOOgO {dhcp} После формирования файлов rules, sysidcfg и ваших профилей скопируйте их в каталог /jumpstart/config и выполните Sun-утилиту check, которая проверит до- стоверность конфигурации. Использование сценария check, который должен быть за- пущен из каталога config, обязательно: он создает файл rules. ok, удостоверяющий для JumpStart, что представленные файлы синтаксически приемлемы. Не опускайте этот этап — в противном случае JumpStart не будет работать. solaris$ sudo ср /jumpstart/sl0sparc/Solaris__10/Misc/jumpstart_sample/check I jumpstart/config Solaris $ sudo ./check Validating rules. . . Validating profile profile_A... The custom JumpStart configuration is ok. В конце процесса конфигурации ваш каталог / jumpstart/config должен выглядеть примерно так. solaris$ Is -1 -rwxr-xr-x 1 root root 52152 Aug 23 19:42 check -rw-r—r— 1 root root 413 Aug 23 19:29 profile_a -rw-r—r— 1 root root 48 Aug 23 19:13 rules -rw-r—r— 1 root root 62 Aug 23 19:43 rules.ok -rw-r—r— 1 root root 314 Aug 23 17:35 sysidcfg Каждого устанавливаемого клиента необходимо добавить на сервер инсталляции че- рез JumpStart; это двухступенчатый процесс. Во-первых, добавьте МАС-адрес клиента в файл сервера /etc/ethers. Во-вторых, выполните утилиту add_install_client, что- бы добавить клиента в базу данных конфигурации, как показано в следующих строках. Solaris $ cd / jumps tart/sl0sparc/Solaris_l 0/Tools solaris$ sudo . /add__install__client -c server:/jumpstart sake sun4v
Глава 12. Управление программным обеспечением и конфигурацией 425 В данном случае клиент с именем sake будет использовать для инсталляции JumpStart NFS на хост-сервере. Реальный процесс сетевой инсталляции для клиента вы начнете после ОВР-приглашения. ok boot net - install В этом непростом процессе предусмотрена возможность проведения пользователь- ских и гибких инсталляций при участии определенных интеллектуальных ресурсов. Сетевые инсталляции с помощью автоматизированного инсталлятора О О Разработчики системы OpenSolaris оценили сложность службы JumpStart и ре- шили создать новое средство установки OpenSolaris. Этот инструмент, Auto- mated Installer (AI), воспроизводит стиль JumpStart, но позволяет справиться с определенными сложностями благодаря удобной утилите installadm. В са- мой простой форме инсталляцию сервера можно выполнить с помощью одной команды. Все файлы, которые вам нужно запустить посредством утилиты AI, собраны в пакете SUNWinstalladm-tools. Любой AI-сервер предлагает одну или несколько “служб инсталляции”, каждая из которых представляет вариант инсталляции операционной системы, определяемый клиентами во время начальной загрузки посредством многоадресной службы доменных имен DNS. Различные службы могут удовлетворять разным инсталляционным потреб- ностям (например, одна служба предназначена для веб-серверов, специально адаптиро- ванных к конкретной среде, а другая — для серверов баз данных). Установив местоположение инсталлятора, клиент отыскивает конфигурацию, или манифест, который отвечает его системному описанию. Клиент выполняет инсталляцию с помощью данных из файлов манифеста. Никакой конфигурации клиента не требуется, хотя при необходимости возможны пользовательские инсталляции клиентов. AI-инсталляция сервера связывает все необходимые части воедино в удобный пакет, включающий службы DHCP и TFTP. Перед добавлением их в сеть обязательно согла- суйте свои действия с вашим администратором сети. Неявно утилита AI создает три XML-отформатированных файла $йнифеста. • AI-файл манифеста содержит данные о сегментировании дис^бвой памяти и орга- низации пакетов (подобен профильному файлу JumpStart). • SC-файл манифеста содержит информацию о конфигураций системы (часовой пояс и учетные записи) — во многом так же, как JumpStart-фаЙЛг sysidefg. • Файл критериев сопоставляет два других файла манифеста с устройствами клиен- тов, подобно тому как это делает файл rules в службе JumpStart. Если вы считаете, что использование языка XML напрягает вас интеллектуально, мо- жете вручную отредактировать манифесты и создать пользовательские конфигурации. Обычно достаточно лишь запустить утилиту installadm для добавления, удаления, раз- решения, запрещения и перечисления новых инсталляционных служб, а также для соз- дания пользовательских конфигураций клиентов. Например, следующая команда installadm создает новую инсталляционную службу, которую вы можете использовать для инсталляции клиента. В данном примере в каче- стве источника инсталляции используется ISO-образ системы OpenSolaris выпуска 0906. Опция -с 10 вынуждает сервер DHCP обеспечить до 10 динамических адресов, начи- ная с 192.168.1.200. Образ инсталляции копируется в каталог /export/ins tall.
426 Часть I. Основы администрирования solaris$ sudo installadm create-service -s ~/osol-0906-x86.iso -i 192.168.1.200 -c 10 /export/install Setting up the target image at /export/install ... Warning: Using default manifest </usr/share/auto_install/default.xml> Registering the service _install_service_46501._OSInstall._tcp.local Creating DHCP Server Created DHCP configuration file. Created dhcptab. Added ’’Locale" macro to dhcptab. Added server macro to dhcptab - opensolaris. DHCP server started. dhtadm: Unable to signal the daemon to reload the dhcptab Added network macro to dhcptab - 192.168.1.0. Created network table. adding tftp to Zetc/inetd.conf Converting /etc/inetd.conf copying boot file to Ztftpboot/pxegrub.I86PC.OpenSolaris-1 Service discovery fallback mechanism set up Для того чтобы инсталлировать клиента, выполните сетевую загрузку обычным спо- собом. Сервер использует предопределенные правила для отыскания образа, загрузки его на сторону клиента и выполнения инсталляции. Автоматизированный инсталлятор (Automated Installer) изменяется довольно быстро. После инсталляции пакета обратитесь за информацией о текущем его состоянии по адресу: /usr/share/doc/auto_install/index.html. 12.3. Инсталляция HP-UX Как сервер-ориентированная операционная система, предназначенная, в ос- новном, исключительно для крупных приложений, которые требуют большого объема ответственной работы, система HP-UX не заботится о предоставлении перспективного процесса инсталляции следующего поколения. Ее программ- ное обеспечение инсталляции с текстовым интерфейсом можно назвать прак- тическим руководством, которое просто проведет вас через основные опции конфигурации: сегментирование дисковой памяти, установка сетевых параме- тров, инсталляция программ. Для узлов системы, которые требуют сетевых и автоматизированных инсталляций, до- ступна HP-опция Ignite-UX. Инсталлятор Ignite-UX может установить по сети несколько систем HP-UX одновременно. Клиенты РА-RISC выполняют загрузку с помощью про- токола начальной самозагрузки ВООТР (Bootstrap Protocol), а системы Itanium использу- ют протокол DHCP. Вы можете сконфигурировать несколько программных репозиториев. Например, пакеты инсталляции могут быть предоставлены из одного хранилища, “запла- ты” — из другого, а пакеты приложений — из третьего. В качестве бонуса Ignite-UX также включает службу, которая восстанавливает конфигурацию компьютера из недавнего образа. Для установки Ignite-UX необходимо выполнить следующие действия. • Инсталлируйте программное обеспечение Ignite-UX и пакеты HP-UX на сервере. • Сконфигурируйте Ignite-UX с предложением соответствующих вариантов инстал- ляции. • Разрешите использовать такие зависимости служб Ignite-UX, как NFS и ВООТР. • Добавьте в сервер МАС-клиент и IP-адреса.
Глава 12. Управление программным обеспечением и конфигурацией 427 После конфигурации сервера вы можете добавить в системы клиентов опцию на- чальной загрузки (через HP-менеджер загрузки EFI Boot Manager), чтобы заставить их инсталлировать систему HP-UX из сервера Ignite-UX. В качестве альтернативного вари- анта для систем, которые уже работают под управлением HP-UX, вы можете использо- вать команду bootsys, чтобы “перенести” инсталляцию с сервера на сторону клиента. В наших примерах систем Ignite-UX устанавливается заранее, но если в вашей си- стеме его нет, попробуйте выполнить команду swinstall -s /dvdrom Ignite-UX. Здесь /dvdrom означает точку монтирования для DVD-диска, который содержит носи- тель операцонной системы, или “операционную среду” в терминологии HP. Результаты инсталляции выражаются в виде ряда инсталлированных пакетов, и некоторые из них перечислены ниже. hp-ux$ sudo swlist Ignite-UX # Ignite-UX Ignite-UX.BOOT-COMMON-IA Ignite-UX.BOOT-COMMON-PA Ignite-UX.BOOT-KRN-11-11 Ignite-UX.BOOT-KRN-11-23 Ignite-UX.BOOT-KRN-11-31 Ignite-UX.BOOT-SERVICES C.7.5.142 C.7.5.142 C.7.5.142 C.7.5.142 C.7.5.142 C.7.5.142 C.7.5.142 HP-UX System Installation Services Boot Components for IPF clients Boot Components for РА-RISC clients Boot Kernel for B.ll.ll clients Boot Kernel for B.11.23 clients Boot Kernel for B.11.31 clients Boot Services for Installations Файлы конфигурации и двоичные файлы Ignite-UX разбросаны случайным образом по всей файловой системе. Самые важные компоненты перечислены в табл. 12.3. Таблица 12.3. Важные двоичные файлы, каталоги и файлы конфигурации, используемые Ignite-UX Имя файла j /etc/bootptab /etc/opt/ignite/instl_boottab / opt/ignite/bin/bootsys Действует как незашифрованная “база данных” для bootpd Регистрирует IP-адреса для загрузки клиентов PA-RISC Обновляет клиентов, которые уже работают под управлением HP-UX / opt/ignite/bin/make_conf ig Создает файл с данными о конфигурации с помощью инсталля- / opt/ignite/bin/make_depots ционного хранилища Создает инсталляционные хранилища на основе некоторых ис- ходных носителей source media / opt/ignite/bin/manage_index /opt/ignite/lbin/setup_server Добавляет хранилище в индекс Ignite-UX Совместно использует каталог /var/opt/ignite/client^ через протокол NFS /var/opt/ignite/clients /var/opt/ignite/data /var/opt/ignite/INDEX Сохраняет файлы конфигурации клиентов (dir) Традиционно использовался для хранилищ инсталляции (dir) Индексирует все хранилища инсталляции, известные Ignite-UX Команда make__depots извлекает пакеты инсталляции и устанавливает их в качестве хранилища операционной среды для инсталляции на стороне клиентов. После создания хранилища выполните команду make__config, чтобы прочитать содержимое хранилища и создать файл конфигурации, который его описывает. Конфигурация становится из- вестной для Ignite-UX посредством выполнения команды manage_index, которая до- бавляет конфигурации в файл INDEX. Ниже приведен пример последовательности ко- манд для версии 1 li v3.
428 Часть I. Основы администрирования hp-ux$ cd /opt/ignite/bin hp-ux$ sudo ./make_depots -s /dev/dsk/c2t2d0 - d /var/opt/ignite/depots/Rel_B. 11.31/oe_media hp-ux$ sudo ./make__config -s /var/opt/ignite/depots/Rel__B. 11.31/core__media - c /var/opt/ignite/data/Rel_B. 11.31/oe_media__cfg hp-ux$ sudo ./manage__index -n "HP-UX B.11.31 Default” -c "Hi v3" hp-ux$ sudo . /manage_index -a - f /var/opt/ignite/data/Rel_B.11.31/oe__xnedia__cfg -c "Hi v3" Прежде чем сервер смогут использовать клиенты, вы должны разрешить протокол ВООТР и совместно используемый каталог clients. Отдельные клиенты должны до- бавляться в файл instl_boottab или bootptab, в зависимости от типа компьютеров, РА-RISC или Itanium. Для совместного использования каталога config посредством файловой системы NFS достаточно выполнить сценарий /opt/ignite/lbin/setup_ server. Эта команда неявно создает совместно используемый NFS-ресурс в каталоге /etc/dfs/sharetab. Вы можете включить протокол ВООТР, “раскомментировав” строку bootps в файле /etc/inetd. conf. А затем предложите сценарию inetd перечитать конфигурацию, за- пустив его на выполнение с ключом -с: /usr/sbin/inetd -с. Прежде чем служба Ignite-UX будет предлагать клиенту службы инсталляции, обыч- но распознают клиента по МАС-адресу. Но чтобы облегчить вашу ношу как админи- стратора, мы рекомендуем использовать HP-понятие “анонимных клиентов”, которые не связаны ни с какими конкретными МАС-адресами. Системы РА-RISC и Itanium опираются на различные механизмы начальной загрузки, и эти две службы конфигурируются несколько по-разному. Для того чтобы сконфигури- ровать службы начальной загрузки Ignite-UX для систем РА-RISC, отредактируйте файл /etc/opt/ignite/instl_boottab. Строки в этом файле имеют следующий формат. 1Р_адрес:МАС_адрес:дата_и_время__последнего_использования [ : reserve ] Поле 1Р_адрес назначает IP-адрес для нового клиента для использования во вре- мя доступа к службам инсталляции. Необязательное поле МАС_адрес идентифицирует компьютер клиента; если вы его опустите, указанный IP-адрес может использовать лю- бой клиент (однако обратите внимание на взаимосвязь с ключевым словом reserve). Третье поле используется и поддерживается службой Ignite-UX; поэтому оставьте его пу- стым в случае добавления новвых элементов. Если в последнем столбце представлено ключевое слово reserve, IP-адрес резерви- руется для использования клиентом, чей МАС-адрес указан во втором поле. Если слово reserve не задано, второе поле просто отображает последний МАС-адрес, который ис- пользовал заданный 1Р-адрес. Файлы /etc/bootptab и /etc/dhcptab, используемые для начальной загрузки си- стем Itanium, имеют совсем другой формат. Эти файлы хорошо прокомментированы и проиллюстрированы многочисленными примерами, которые мы не считаем нужным здесь повторять. (Обратите внимание на то, что в системах HP-UX единственный де- мон, bootpd, обслуживает запросы, поступаемые как от ВООТР, так и от DHCP.) Метод загрузки через протокол DHCP предпочтительнее для систем Itanium, поскольку он мо- жет предоставлять услуги анонимным клиентам. Просмотрите комментарии в файлах /etc/bootptab и /etc/dhcpv6tab. Если вы уже сконфигурировали сервер Ignite-UX так, как описано выше, клиенты смогут выпол- нять загрузку с него по сети. На стороне клиента прервите обычный процесс загрузки, войдите в менеджер загрузки EFI Boot Manager и добавьте сетевое устройство. Клиент запросит IP-адрес, а сервер Ignite-UX ответит и начнет инсталляцию.
Глава 12. Управление программным обеспечением и конфигурацией 429 Этот метод работает лучше всего для систем, которые совместно используют подсеть с сервером Ignite-UX. Для конфигураций, в которых клиент не включен в подсеть этого сервера, система HP перечисляет ряд опций в руководстве Ignite-UX Administration Guide. Автоматизация инсталляций Ignite-UX Конфигурация сетевой загрузки Ignite-UX — это необходимое условие для автомати- зированной инсталляции, однако конфигурирование Ignite-UX без задания подробных данных автоматической загрузки приводит к интерактивной инсталляции. Кроме того, Ignite-UX может следующее: • использовать конфигурацию, сохраненную от предыдущей инсталляции, для авто- матизации будущих инсталляций; • опираться на файлы конфигурации, которые могут быть установлены для каждого клиента, для нужных версий или просто по желанию администратора; • задавать стандартные значения для некоторых параметров конфигурации (напри- мер, DNS-серверы) и использовать другие значения для выбора во время интерак- тивной инсталляции. Файлы автоматизированной инсталляции размещаются в каталоге /opt/ignite /data, а несколько примеров и образцы конфигураций включены в пакет инсталляции Ignite-UX. Поэтому вам лучше всего начать с просмотра подкаталогов release и example. 12.4. Инсталляция системы AIX с помощью СЕТЕВОГО МЕНЕДЖЕРА ИНСТАЛЛЯЦИИ ©Сетевой менеджер инсталляции (Network Installation Manager — NIM) — это AIX-ответ инсталляторам Kickstart, JumpStart и Ignite-UX. Версии NIM, начиная c AIX 5.3, могут также инсталлировать системы Linux. “Главный” NIM-сервер инсталлирует клиентов от одного или нескольких образов ин- сталляции, где под клиентом может подразумеваться автономный компьютер, “пустая” (т.е. без диска и данных) рабочая станция или рабочий раздел диска.2 Инсталляции опираются на использование протоколов TFTP, NFS и DHCP или ВООТР, почти как в других системах.3 Сетевой менеджер инсталляции NIM включен в стандартный носитель инсталляции AIX. Все NIM-среды имеют, по крайней мере, один “сервер ресурсов”, который предла- гает клиентам некоторый набор программ. Этот сервер и “главный” NIM-сервер могут использовать одну систему или разные. Для улучшения качества процесса инсталляции среды, которые имеют сложные сетевые топологии или географически разделены, долж- ны использовать локализованные серверы ресурсов. Существует три способа конфигурации NIM: • путем использования веб-ориентированного системного менеджера; 2 Бездисковый клиент не имеет жесткого диска для локальных файловых систем и для хране- ния данных использует сетевые службы. Клиент без данных имеет только локальное пространство Для свопинга и, возможно, файловые системы /tmp и /home. 3 Поскольку все поставщики используют приблизительно одни и те же протоколы и архитек- туры, то было бы хорошо, если бы они скооперировались и создали одну стандартную систему инсталляции, не правда ли? :-)
430 Часть I. Основы администрирование • с помощью “быстрых” путей (с минимальным временем распространения) emit nim или smit eznim; • из командной строки с помощью утилиты nim. Мы считаем, что SMIT (System Manager Interface Tool — интерфейсные средства администратора системы) — самый быстрый и самый удобный интерфейс для конфи- гурирования NIM-среды. Версия “EZ” охватывает большинство часто выполняемых таких NIM-задач, как быстрая настройка главного сервера, обновление, резервирова- ние или реинсталляция существующих клиентов и конфигурирование новых клиентов. Полнофункциональная версия smit nim несколько усложнена из-за использования EZ NIM, но зато содержит некоторые дополнительные возможности конфигурации, напри- мер, позволяя включать пользовательские программные пакеты и более гибкие средства управления инсталлированными клиентами. Если вы настаиваете на выполнении операций из командной строки, тогда лучше всего начать с утилиты nim_master_setup. (В действительности SMIT-варианты EZ- NIM для конфигурирования главного сервера просто вызывают утилиту nim_master_ setup с заданными параметрами.) Эта утилита инициализирует файловые системы для программных NIM-ресурсов, создает необходимые файлы конфигурации и копирует образец файла конфигурации клиента, который вы можете отредактировать для своих локальных клиентов. Самый распространенный вариант использования утилиты — nim_master_setup -а device=/dev/cdO, где /dev/cdO — устройство, которое содержит носитель инсталля- ции для соответствующей версии системы AIX. В отличие от большинства других систем инсталляции, описанных в этой главе, главный NIM-сервер может инсталлировать вы- пуски AIX только того же (или более раннего) уровня модификации: например, сервер версии AIX 5.2 не может инсталлировать системы версии AIX 6.1. Самые полезные NIM-ориентированные утилиты командной строки перечислены в табл. 12.4. Таблица 12.4. NIM-ориентированные утилиты командной строки nimjnas ter__se tup nim_update_all nim__clients_setup Инсталлирует и конфигурирует главный NIM-сервер Обновляет ресурсы инсталляции и клиентов Определяет новых клиентов и инициализирует инсталляцию операционной системы nim__master__re cover nim nimclient Восстанавливает главную NIM-базу данных на новом сервере Множество функций: конфигурирует ресурсы, определяет клиентов и т.д. Извлекает ресурсы (например, обновления) из сервера (запускает на стороне клиентов) 12.5. Управление пакетами Все варианты UNIX и Linux включают какую-нибудь систему управления пакета- ми, которая помогает управлять конфигурацией. Традиционно пакеты использовались для распространения программного обеспечения, однако их можно применять также для распространения конфигурационных файлов и административных данных. Пакеты имеют ряд преимуществ по сравнению с неструктурированными архивами . tar.gz.
Глава 12. Управление программным обеспечением и конфигурацией 431 Наверное, важнее всего то, что процесс инсталляции пакета протекает как одна транзак- ция: при возникновении ошибки инсталляцию можно прервать или повторить. Пакетные инсталляторы обычно знают о конфигурационных файлах и, как правило, не перезаписывают локальные настройки, выполненные системным администратором. Они или создают резервные копии изменяемых файлов, или предлагают образцы кон- фигурационных файлов под другими именами (например, pkg. conf. rpmnew). Если по- сле инсталляции пакета в системе обнаруживаются нарушения, то, теоретически, можно все восстановить в прежнее состояние. Естественно, то, что написано в теории, не всег- да проходит на практике, поэтому делать это в производственной системе нужно лишь после проверки установки на тестовой системе. Системы управления пакетами “понимают” внутрипакетные зависимости, что по- зволяет разработчикам пакетов быть уверенными в правильной инсталляции не только самих приложений, но и всех библиотек и вспомогательных файлов, от которых они за- висят. Следует иметь в виду, что не все системы управления пакетами в полной мере справляются с внутрипакетными зависимостями: одни — лучше, другие — хуже. В ходе инсталляции пакета могут также выполняться различные сценарии, поэтому иногда они могут сделать гораздо больше, чем просто выгрузить новые файлы. С помощью пакетов удобно распространять изменения локальных настроек. Можно создать пакет, который в процессе инсталляции соберет сведения о компьютере (или получит их из локальной базы данных) и на их основе модифицирует конфигурацион- ные файлы. В виде пакетов можно рассылать локальное ПО вместе со вспомогатель- ными файлами и даже сторонние приложения, первоначально имевшие другой формат. Пакетам можно присваивать версии, с тем чтобы при инсталляции новой версии пакета автоматически обновлялись зависящие от него компоненты. Можно также использовать механизм зависимостей для создания групп пакетов. На- пример, можно создать такой пакет, который сам по себе ничего не инсталлирует, но от него зависит много других “заплат”. Появление новой версии пакета приводит к авто- матической установке всех этих “заплат” за один раз. 12.6. Управление Linux-пакетами В системах Linux широко распространены два формата пакетов. В Red Hat, SUSE и большинстве других дистрибутивов применяется диспетчер пакетов RPM (Red Hat Package Manager). В Ubuntu используются пакеты отдельного формата . deb (названно- го “в честь” дистрибутива Debian, на основе которого был создан дистрибутив Ubuntu). Оба формата функционально идентичны. Преобразование из формата в формат можно произвести без каких-либо трудностей с помощью утилиты alien (kitenet.net/programs/alien). Ей ничего не известно о программах данного пакета, поэтому если содержимое еще не совместимо с вашим дис- трибутивом, alien не поможет. Вообще, лучше всего использовать “родной” механизм Упаковки, используемый в вашем дистрибутиве. Системы упаковки RPM и . deb теперь работают в виде двухуровневых средств уп- равления конфигурацией. На нижнем уровне находятся средства, которые инсталлиру- ют, деинсталлируют и запрашивают пакеты: rpm для RPM и dpkg для . deb. Над этими командами находятся системы, которые знают, как нужно производить поиск пакетов в Интернете, анализировать зависимости между пакетами и модернизи- ровать все пакеты в системе. Система yum (Yellowdog Updater, Modified) работает с систе- мой RPM. Система Red Hat Network работает для Red Hat Enterprise Linux и использует
432 Часть I. Основы администрирования RPM. Система Advanced Package Tool (APT) первоначально была создана для работы с пакетами . deb, а сейчас она может работать также с пакетами RPM. Ниже будет дан обзор низкоуровневых команд rpm и dpkg. В разделе 12.7 поговорим о комплексных системах обновления. Команда rpm: управление пакетами RPM Команда rpm инсталлирует, проверяет и запрашивает состояние пакетов. Когда-то она еще и создавала пакеты, однако сейчас эта функция отведена команде rpmbuild. Тем не менее опции rpm по-прежнему имеют сложные взаимодействия и вместе могут использоваться только в некоторых комбинациях. Воспринимать утилиту rpm нужно так, будто это несколько разных команд с одним и тем же именем. Режим, который вы выбираете для работы rpm (например, -i или -д), определяет, к каким функциям этой утилиты вы хотите обратиться. Команда rpm —help перечислит все опции, разбивая их по режимам. Если вам часто приходится иметь дело с пакетами RPM, нужно будет внимательно прочесть главную страницу. Обычно используются опции -i (install), -U (upgrade), -e (erase) и -q (query). По- следняя опция является довольно сложной в том плане, что она служит для включения остальных опций; чтобы изложить определенный вопрос, вам нужно предоставить до- полнительный флаг командной строки. Например, команда rpm -да отображает список всех пакетов, инсталлированных в системе. Давайте рассмотрим небольшой пример. Предположим, требуется инсталлировать новую версию пакета OpenSSH, поскольку опубликован бюллетень, в котором сообща- ется о том, что в предыдущей версии выявлена брешь. После того как пакет загружен на локальный компьютер, для его инсталляции достаточно ввести команду rpm -U. redhat$ sudo rpm -U openssh-2.9p2-12.i386. rpm error: failed dependencies: openssh = 2.9p2-7 is needed by openssh-askpass-2.9p2-7 openssh = 2.9p2-7 is needed by openssh-askpass-gnome-2.9p2-7 openssh = 2.9p2-7 is needed by openssh-clients-2.9p2-7 openssh = 2.9p2-7 is needed by openssh-server-2.9p2-7 Гм... Похоже, не все так просто! Как видите, инсталлированная в настоящий момент версия 2.9р2-7 связана с рядом других пакетов. Команда rpm не позволяет обновить па- кет OpenSSH, так как это изменение затрагивает другие пакеты. Этот тип конфликта встречается постоянно, поэтому лучше разрабатывать такие системы, как АТР и yum. В реальном мире мы вряд ли пытались бы распутывать зависимости вручную, однако в качестве примера сделаем это для утилиты rpm. Можно прибегнуть к принудительному обновлению с помощью опции —force, но это вряд ли оправдано. Информация о зависимостях присутствует здесь для того, чтобы сэкономить ваше время и избавить вас от лишних проблем, а не для того, чтобы запу- тать вас. Для любого системного администратора нет ничего хуже, чем нарушение рабо- ты SSH в дистанционной системе. Вместо этого мы будем использовать обновленные версии пакетов зависимостей. Ес- ли бы мы были находчивыми, то перед модернизацией могли бы определить, что ос- тальные пакеты зависят от OpenSSH. redhat$ rpm -q —whatrequires openssh openssh-askpass-2.9p2-7 openssh-askpass-gnome-2.9p2-7 openssh-clients-2.9p2-7 openssh-server-2.9p2-7
глава 12. Управление программным обеспечением и конфигурацией 433 Теперь предположим, что обновленные копии необходимых пакетов получены. Можно инсталлировать их последовательно, но команда rpm все берет на себя. Доста- точно указать список пакетов в командной строке, и команда rpm отсортирует их в соот- ветствии с имеющимися зависимостями. redhat$ sudo rpm -U openssh-* Проверим результат. redhat$ rpm -q openssh openssh-2.9p2-12 Все получилось! Обратите внимание на тот факт, что rpm понимает, о каком пакете идет речь, даже если не указывать полное имя или версию пакета. Команда dpkg: управление пакетами .deb в системе Ubuntu ®В Debian аналогом команды rpm является команда dpkg. К полезным ее оп- циям относятся —install, —remove, а -1 перечисляет пакеты, инсталлиро- ванные в системе. Обратите внимание на то, что команда dpkg —install, выполненная в отношении пакета, уже находящегося в системе, перед инстал- ляцией удаляет предыдущую версию пакета. С помощью команды dpkg -1 | grep пакет легко определить, инсталлирован ли уже указанный пакет. Например, чтобы отыскать HTTP-сервер, выполните следующую команду. ubuntu$ dpkg -1 | grep -i http ii lighttpd 1.4.13-9ubuntu4 A fast webserver with minimal memory footpri В результате будет найдена программа lighttpd — облегченный веб-сервер (пре- красный открытый исходник). Начальные буквы ii означают, что заданная программа уже инсталлирована. Предположим, группа, занимающаяся вопросами безопасности системы Ubuntu, вы- пустила “заплату” к редактору nvi. После загрузки “заплаты” нужно выполнить команду dpkg для ее установки. Из показанного ниже примера видно, что эта команда гораздо более многословна, чем rpm, и сообщает о том, что именно она делает. ubuntu$ sudo dpkg —install ./nvi_l.79-16a.l_i386.deb (Reading database ... 24368 files and directories currently installed.) Preparing to replace nvi 1.79-14 (using ./nvi_l.79-16a.I_i386.deb) ... Unpacking replacement nvi ... Setting up nvi (1.79-16a.l) ... Checking available versions of ex, updating links in /etc/alternatives ... (You may modify the symlinks there yourself if desired - see 'man In' .) Leaving ex (/usr/bin/ex) pointing to /usr/bin/nex. Leaving ex.l.gz (/usr/share/man/manl/ex.1.gz) pointing to /usr/share/man/manl/nex.1.gz. Теперь можно ввести команду dpkg -1, чтобы узнать, все ли прошло нормально. Флаг -1 допускает наличие шаблона поиска, благодаря чему можно получить информа- цию только по редактору nvi.
434 / Часть I. Основы администрирований ubuntu$ dpkg -1 nvi Desired=Unknown/Install/Remove/Purge |Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-instailed |/Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:uppercase=bad) ||/Name Version Description i i nvi 1.79-16a.l 4.4BSD re-implementation of vi. Инсталляция завершилась успешно. 12.7. Использование высокоуровневых систем УПРАВЛЕНИЯ ПАКЕТАМИ В LlNUX Системы управления пакетами, такие как APT и yum, а также Red Hat Network, ста- вят перед собой следующие задачи: • упростить определение местонахождения и загрузку пакетов; • автоматизировать процесс обновления или модернизации систем; • способствовать управлению зависимостей между пакетами. Понятно, что, помимо команд, на стороне клиентов эти системы должны выполнять множество других функций. Все они требуют, чтобы компании, обеспечивающие под- держку дистрибутивов, организовывали свои предложения в согласованном порядке, чтобы клиенты могли иметь доступ к их ПО осознанно. Так как ни один поставщик не в состоянии предложить программы для Linux “на лю- бой вкус”, любая система допускает существование множества хранилищ программного обеспечения. Хранилища могут быть локальными по отношению к вашей сети, поэтому эти системы предлагают первоклассную базу, чтобы вы могли создать собственную си- стему внутреннего распределения. Служба Red Hat Network неразрывно связана с дистрибутивом Red Hat Enterprise Linux. Это коммерческая служба, пользование которой стоит денег, зато она обладает привлекательным интерфейсом и более мощными возмож- ностями в плане автоматизации, чем APT и yum. Служба Red Hat Network — это “отполированная” открытая версия дорогостоящего Red Hat-сервера Satellite Server. Клиент может ссылаться на хранилища yum и APT, и эта воз- можность позволяет таким дистрибутивам, как CentOS, адаптировать клиент- ский графический интерфейс под нестандартное использование. APT документирована гораздо лучше, чем Red Hat Network, и к тому же бесплатна. Она также является более гибкой в плане настройки. APT разрабатывалась для Debian и dpkg, но была расширена и теперь может работать с RPM. Доступными являются все версии, работающие со всеми нашими примерами дистрибутивов. На данный момент система APT более других подходит на роль универсального стандарта для распростра- нения программного обеспечения. Программа yum — это аналог APT, предназначенный для RPM. yum является также стандартным администратором пакетов для Red Hat Enterprise Linux версии 5, хотя мо- жет работать в любой системе, основанной на RPM, при условии что вы сможете указать ей хранилища, имеющие соответствующий формат. Нам нравится APT, и мы считаем, что это разумный выбор, если нужно настроить собственную автоматизированную сеть распределения пакетов. Более подробно об этом
Глава 12. Управление программным обеспечением и конфигурацией 435 можно прочитать в разделе “Создание локального зеркала хранилища” далее в этой гла- ве. Но в большинстве случаев безопаснее всего использовать систему управления паке- тами, которая входит в состав выбранного вами дистрибутива. В SUSE реализована собственная система управления пакетами на основе пакетов RPM (известная как ZYpp) с интерфейсом командной строки (именуемым Zypper). В до- полнение к обычным функциям (конфигурация репозитория, инсталляция пакета и за- просы статуса), Zypper прекрасно зарекомендовал себя в реализации анализа зависимо- стей. Версия Zypper 1.0 вышла в составе openSUSE 11.1. Подробнее о Zypper см. ниже в этой главе. Хранилища пакетов Дистрибуторы Linux поддерживают хранилища программного обеспечения, которые работают совместно с выбранными ими системами управления пакетами. Конфигура- ция, выбираемая по умолчанию для системы управления пакетами, обычно указывает на один или несколько хорошо известных веб- или FTP-серверов, находящихся под управлением дистрибьюторов. Однако из этого факта нельзя сразу понять, что может содержаться в таких храни- лищах. Должны ли они включать только наборы пакетов, принятых в качестве офици- альных, основных, версий? Официальные версии плюс текущие обновления системы защиты? Современные версии всех пакетов, которые существовали в официальных вы- пусках? Полезные программы сторонних производителей, которые официально не под- держиваются дистрибьютором? Исходный код? Бинарные файлы для многочисленных архитектур аппаратных средств? Если вы запускаете apt-get upgrade, yum upgrade или zypper dup, чтобы обновить систему, что именно под этим подразумевается? Вообще, системы управления пакетами должны отвечать на все эти вопросы и об- легчать организациям выбор специфических профилей, которые они хотят включить в их “мир программного обеспечения”. Следующие концепции помогут структурировать этот процесс. “Выпуск” (release) — это самосогласованное отображение “вселенной” пакета. Прежде чем наступила эпоха Интернета, именованные выпуски операционных систем были более или менее постоянными и были связаны с одним определенным моментом времени; “заплаты” системы защиты создавались отдельно. В наши дни выпуск пред- ставляет собой более расплывчатое понятие. Выпуски выходят во время обновления па- кетов. Некоторые выпуски, такие как Red Hat Enterprise Linux, предназначены специ- ально для того, чтобы задержать выходы новых версий; по умолчанию в них включаются только обновления защиты. Остальные выпуски, такие как бета-версии, меняются часто и существенно. Однако во всех случаях выпуск является базовой линией, трендом, или той мерой, “до которой я хочу обновить свою систему”. “Компонент” (component) — подборка программ в рамках выпуска. Дистрибутивы имеют различные отличия, однако общим является отличие между основным программ- ным обеспечением, предлагаемым дистрибьютором, и дополнительным программным обеспечением, предлагаемым энтузиастами. Другое отличие, присущее миру Linux, кро- ется между свободными частями открытого исходного кода выпуска и частями, связан- ными с некоторым соглашением о коммерческом использовании. Отдельного внимания со стороны администратора заслуживают минимально актив- ные компоненты, которые включают только исправления в системе защиты. Некоторые
436 Часть I. Основы администрирования/ выпуски позволяют комбинировать компонент защиты с постоянным базовым компо- нентом для создания относительно стабильной версии дистрибутива. “Архитектура” (architecture) — это специфический класс аппаратных средств (обо- рудования). Предполагается, что компьютеры, относящиеся к некоторому классу архи- тектуры, будут иметь одинаковые характеристики, позволяющие запускать на них оди- наковые исполняемые файлы. Архитектуры являются специфическими экземплярами выпусков (например, “Ubuntu Karmic Koala for x86_64”). Так как компоненты являются подразделениями выпусков, для каждого из них существует соответствующий экзем- пляр, характерный для данной архитектуры. Индивидуальные пакеты являются элементами, составляющими компоненты, а сле- довательно, и выпуски. Пакеты обычно являются специфическими для архитектуры и выходят в виде версии, не зависящей от главного выпуска и остальных пакетов. Соот- ветствие между пакетами и выпусками является неявным в том плане, как производится настройка сетевого хранилища. Существование компонентов, которые не поддерживаются дистрибьютором (напри- мер, “universe” и “multiverse” для Ubuntu), поднимает вопрос о том, как эти компоненты относятся к основному выпуску ОС. Можно ли о них говорить как о настоящих “компо- нентах” специфического выпуска иди же они представляют собой нечто другое? С точки зрения управления пакетами ответ прост: “universe” — это настоящий компонент. Они связаны со специфическим выпуском и выходят вместе с ним. Разделение управления интересно с точки зрения администрирования, но не влияет на системы управления па- кетами. Служба Red Hat Network После того как система Red Hat перестала входить в группу “потребитель- ских товаров” Linux, Red Hat Network стала платформой для управления си- стемой для Red Hat Enterprise Linux. Подписываясь на нее, вы приобретаете право доступа к Red Hat Network. В простейшем виде служба Red Hat Network представляет собой популярный веб-портал и список рассылки. В этом смыс- ле она мало чем отличается от тех служб уведомления о “заплатах”, которые уже много лет эксплуатируются различными поставщиками UNIX-систем. Дополнительные возможности открываются лишь при условии, что вы готовы за них заплатить. Информацию и текущие расценки можно узнать на сайте rhn.redhat.com. Служба Red Hat Network предлагает веб-ориентированный интерфейс для загрузки новых пакетов (можно также работать в режиме командной строки). Начиная с версии Red Hat Enterprise 5, в качестве интерфейса командной строки (Command Line Inter- face — CLI) используется yum (до этого времени использовался громоздкий и проблем- ный инструмент, именуемый up2date), который даже позволяет загружать и инстал- лировать пакеты без вмешательства человека. После того как вы зарегистрируетесь, система будет получать все необходимые “заплаты” в автоматическом режиме. Недостатком такого подхода является то, что решения об обновлении системы при- нимаются за вас. Определите для себя, в какой степени следует доверять разработчикам Red Hat (а также тех программ, которые они предлагают в виде пакетов). Разумным компромиссом будет выделение одного из компьютеров в качестве сервера автоматических обновлений. Периодически можно создавать образы серверной системы и проверять, в какой степени они подходят для внутреннего распространения.
Глава 12. Управление программным обеспечением и конфигурацией 437 APT: усовершенствованное средство управления пакетами APT (Advanced Packaging Tool) — это одна из зрелых систем управления пакетами. С помощью всего лишь одной команды apt-get можно модернизировать всю систему и программное обеспечение; также с ее помощью (как и с помощью Red Hat Network) можно постоянно сохранять ваши “коробочные” версии современными без вмешатель- ства со стороны человека. Первое правило, которого следует придерживаться при использовании утилиты apt- get в Ubuntu (это касается всех средств управления пакетами этой системы), требует игнорировать утилиту dselect, являющуюся клиентской надстройкой системы. Речь не идет о том, что утилита dselect плохая, просто ее интерфейс неудачен и может напу- гать новичка. В документации вы можете найти рекомендации в пользу использования dselect, тем не менее не принимайте их во внимание и используйте APT. В случае типичной инсталляции Ubuntu, которая загружается с одного из стандарт- ных “зеркал”, узнать список доступных пакетов можно на веб-сайте packages. ubuntu. com. Этот веб-сайт имеет удобную поисковую систему. Если же создается внутренний сервер APT (см. раздел “Создание локального зеркала хранилища” ниже в этой главе), то, конечно, администратор сам знает, какие пакеты доступны, и может сформировать их список. Дистрибутивы обычно имеют пустые пакеты, которые существуют для того, чтобы формировать списки зависимых пакетов. Утилита apt-get автоматически загружает и инсталлирует зависимые пакеты, благодаря чему можно легко устанавливать или об- новлять блоки пакетов. Например, инсталлируя пакет gnome-desktop-environment, можно быть уверенным в том, что установлено все необходимое для пользовательского интерфейса GNOME. Если файл /etc/apt/sources. list (см. его подробное описание ниже в этой главе) настроен, а имя необходимого пакета известно, то осталось лишь выполнить команду apt-get update, чтобы обновить информацию о пакетах. После этого от имени при- вилегированного пользователя нужно ввести команду apt-get install имя__пакета, которая, собственно, и осуществит инсталляцию пакета. Эта же команда обновит пакет, если он уже инсталлирован. Предположим, требуется установить новую версию пакета sudo, в котором устранена очередная брешь. Сначала не помешает выполнить команду apt-get update. ubuntu $ sudo apt-get update Get: 1 http://http.us.debian.org stable/main Packages [824kB] Get:2 http://non-us.debian.org stable/non-US/main Release [102B] Теперь можно приступить к получению пакета. Обратите внимание на то, что мы ис- пользуем команду sudo в процессе инсталляции нового пакета sudo — утилита apt-get способна обновлять даже те пакеты, которые в настоящий момент используются. ubuntu$ sudo apt-get install sudo Reading Package Lists... Done Building Dependency Tree... Done 1 packages upgraded, 0 newly installed, 0 to remove and 191 not upgraded. Need to get 0B/122kB of archives. After unpacking 131kB will be used. (Reading database ... 24359 files and directories currently installed.) Preparing to replace sudo 1.6.1-1 (using .../sudo_l.6.9pl0-lubuntu3.4_i386.deb)
438 Часть I. Основы администрирования Unpacking replacement sudo .. . Setting up sudo (1.6.2p2-2) ... Installing new version of config file /etc/pam.d/sudo ... Конфигурирование apt-get Сконфигурировать утилиту apt-get несложно. Хорошие инструкции можно найти в документации по управлению пакетами в* системе Ubuntu по адресу: help. ubuntu. сот/community/AptGet/Howto Самый важный конфигурационный файл утилиты называется /etc/apt/sources, list. В нем сообщается, где искать пакеты. В каждой строке файла указывается следую- щее. • Тип пакета. В настоящее время это deb или deb-src для пакетов в стиле Debian либо rpm или rpm-src — для RPM. • URL-адрес файла, компакт-диска, сервера HTTP или FTP, где находятся пакеты. • “Дистрибутив” (на самом деле — название выпуска), если нужно работать с не- сколькими версиями пакета. Дистрибьюторы используют его для главных выпу- сков, однако вы можете использовать его для других целей, если вам нужны вну- тренние системы распространения. • Необязательный список компонентов, т.е. категорий пакетов в рамках дистрибу- тива. • Стандартная конфигурация вполне приемлема, если только не нужно создавать собственное хранилище пакетов. Исходные пакеты загружаются при использова- нии строк, начинающихся с deb-src. Работая в системе Ubuntu, вы почти наверняка захотите включить в нее компонент “universe”, который предоставляет доступ к открытым программным средствам большо- го (по объему) мира Linux. Пакеты “multiverse” включают такие неоткрытые исходные тексты, как некоторые утилиты и компоненты VMware. В процессе редактирования файла sources.list вам следует перенастроить от- дельные записи для указания адреса “зеркала”, задав более близко расположен- ный сервер. Полный список “зеркал” Ubuntu находится по адресу: launchpad.net/ ubuntu/+archivemirrors. Это динамический (и длинный) список зеркал, который регулярно изменяется, поэтому обязательно отслеживайте изменения между выпусками. Убедитесь, что в качестве источника указан элемент security.ubuntu.com, и тогда вы точно получите доступ к самым последним “заплатам”, связанным с мерами по укре- плению безопасности. Пример файла /etc/apt/sources. list В показанном ниже примере в качестве источника пакетов для загрузки “основных” компонентов Ubuntu используется адрес us. archive. ubuntu. com (эти компоненты полностью поддерживаются командой разработчиков Ubuntu). Кроме того, этот список (sources. list) включает неподдерживаемые (но с открытым исходным кодом) пакеты “universe” и небесплатные неподдерживаемые пакеты в компоненте “multiverse”. В каж- дом компоненте также предусмотрено хранилище для обновлений, т.е. пакетов с исправ- ленными ошибками. Наконец, последние шесть строк предназначены для обновлений, связанных с безопасностью. # Общий формат: тип URL-адрес дистрибутив [компоненты] deb http://us.archive.ubuntu.com/ubuntu/ karmic main restricted
Глава 12. Управление программным обеспечением и конфигурацией 439 deb-src http://us.archive.ubuntu.com/ubuntu/ karmic main restricted deb http://us.archive.ubuntu.com/ubuntu/ karmic-updates main restricted deb-src http://us.archive.ubuntu.com/ubuntu/ karmic-updates main restricted deb http://us.archive.ubuntu.com/ubuntu/ karmic universe deb-src http://us.archive.ubuntu.com/ubuntu/ karmic universe deb http://us.archive.ubuntu.com/ubuntu/ karmic-updates universe deb-src http://us.archive.ubuntu.com/ubuntu/ karmic-updates universe deb http://us.archive.ubuntu.com/ubuntu/ karmic multiverse deb-src http://us.archive.ubuntu.com/ubuntu/ karmic multiverse deb http://us.archive.ubuntu.com/ubuntu/ karmic-updates multiverse deb-src http://us.archive.ubuntu.com/ubuntu/ karmic-updates multiverse deb http://security.ubuntu.com/ubuntu karmic-security main restricted deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted deb http://security.ubuntu.com/ubuntu karmic-security universe deb-src http://security.ubuntu.com/ubuntu karmic-security universe deb http://security.ubuntu.com/ubuntu karmic-security multiverse deb-src http://security.ubuntu.com/ubuntu karmic-security multiverse Поля дистрибутив и компоненты помогают утилите apt-get ориентироваться в ие- рархии файловой системы хранилища Ubuntu, которая характеризуется стандартизиро- ванным размещением. Корневой дистрибутив для каждого выпуска может быть помечен как intrepid (смелый), jaunty (стильный) или karmic (кармический). Доступными компонентами обычно являются main, universe, multiverse и restricted. Если вас устраивает наличие неподдерживаемых (и с ограниченной лицензией в случае multiverse) программ в вашей среде, добавьте хранилища universe и multiverse. Создание локального зеркала хранилища Если планируется применять утилиту apt-get для большого числа компьютеров, то потребуется локальное кеширование пакетов — загружать копии всех пакетов для каж- дого компьютера было бы неразумно. Совсем не трудно сконфигурировать зеркало хра- нилища, которое было бы удобным для локального администрирования. От вас требует- ся лишь отслеживать обновления с помощью “заплат”, связанных с безопасностью^^. Лучше всего и удобно для такой работы использовать пакет apt-mirror, кото^^ доступен на сайте apt-mirror. sourceforge. net. Вы можете также инсталлировать пакет из компонента universe с помощью команды sudo apt-get install apt- mirror. После инсталляции пакета apt-mirror в каталоге /etc/apt вы найдете файл mirror. list. Это “теневая” версия sources. list, но она используется только как ис- точник для зеркального отображения операций. По умолчанию mirror. list содержит все хранилища для запуска версии Ubuntu. Для того чтобы в действительности воспроизвести хранилища в mirror. list, до- статочно запустить на выполнение apt-mirror. ubuntu $ sudo apt-mirror Downloading 57 index files using 20 threads... Begin time: Sat Aug 29 18:53:44 2009 [20]... [19]... [18]... [17]... [16]... [15]... [14]... По умолчанию пакет apt-mirror помещает свои копии хранилища в каталог /var/ spool/apt-mirror. Можно закомментировать set base_path в mirror. list, но не забудьте создать в новом корневом каталоге зеркала подкаталоги mirror, skel и var.
I Часть I. Основы администрирования Пакету apt-mirror требуется много времени для первого прохода, поскольку ему приходится отображать множество гигабайтов данных (на данный момент приблизи- тельно 40 Гбайт для выпуска Ubuntu). Последующие проходы протекают быстрее и должны быть реализованы автоматически (из демона cron). Для того чтобы избавиться от уже устаревших файлов, можете запустить сценарий clean. sh из подкаталога var своего зеркала. Для того чтобы приступить к использованию своего зеркала, воспользуйтесь (с по- мощью своего любимого веб-сервера) базовым каталогом через протокол HTTP. Мы лю- бим использовать символические ссылки на веб-корень. Вот пример. In -s /var/spool/apt-mirror/us.archive.ubuntu.com/ubuntu /var/www/ubuntu Для того чтобы заставить клиентов использовать свое локальное зеркало, отредакти- руйте файлы sources. list так, как если бы выбрали нелокальное зеркало. Автоматизация работы утилиты apt-get Утилиту apt-get можно запускать по графику с помощью демона cron. Даже если пакеты не инсталлируются автоматически, полезно регулярно выполнять команду apt- get update, чтобы следить за обновлениями сводных файлов. Команда apt-get dist-upgrade загрузит и инсталлирует новые версии любых па- кетов, имеющихся на локальном компьютере. Флаг dist-upgrade эквивалентен флагу upgrade, но включает более точную обработку зависимостей. Флаг dist-upgrade мо- жет удалить пакеты, которые утилита посчитает несовместимыми с модернизированной системой, так что к этому нужно быть готовым. Можно даже позволить компьютерам выполнять обновления в автоматическом ре- жиме. Для этого предназначена опция -yes, при наличии которой на любой вопрос, задаваемый утилитой apt-get, будет выдано оптимистичное “Да!”. Имейте в виду, что некоторые обновления (например, пакеты ядра) могут не вступать в силу до тех пор, пока система не будет перезагружена. Обычно не рекомендуется автоматически загружать обновления непосредственно с “зеркал” дистрибутивов. Другое дело, когда имеются внутренние серверы APT и система управления версиями. Следующий маленький сценарий позволит клиенту поддерживать синхронизацию с сервером APT. #!Zbin/sh apt-get update apt-get -yes dist-upgrade Этот сценарий может запускаться демоном cron (см. главу 9) каждую ночь. Можно также создать ссылки на него в сценариях запуска системы (см. главу 3), чтобы обновле- ния выполнялись на этапе начальной загрузки. Если процедуры обновления запускаются на большом числе компьютеров, необхо- димо распределить их по времени, чтобы не перегрузить сеть. Это можно сделать с по- мощью небольшого Perl-сценария, приведенного в разделе 19.2. Если вы не вполне доверяете источнику пакетов, можно автоматически загружать их, но не инсталлировать. Это позволяет делать опция —download-only утилиты apt- get. Просмотрите полученные пакеты и определите сами, какие из них инсталлиро- вать. Загруженные пакеты находятся в каталоге /var/cache/apt, который со време- нем может серьезно разрастись. Удаляйте неиспользуемые файлы командой apt-get autoclean.
Глава 12. Управление программным обеспечением и конфигурацией 441 Система yum: управление выпусками для RPM Система yum (Yellowdog Updater, Modified) представляет собой администратор мета- пакетов, основанный на RPM4. Называть yum клоном apt-get, пожалуй, неправильно, однако в плане тематики и реализации она очень похожа на apt-get, но на практике проще и медленнее. Yum — это официальная система управления пакетами для Red Hat Enterprise Linux; она предварительно устанавливается и на многих других дистрибутивах. При необходимости самую последнюю версию yum можно получить из хранилища па- кетов вашего дистрибутива. Как и в случае с apt-get, команда на стороне сервера (yum-arch) компилирует базу данных заголовочной информации из большого набора пакетов (нередко из цело- го выпуска). После этого база данных заголовков совместно используется пакетами по- средством протоколов HTTP или FTP. Клиенты используют команду yum для выбора и инсталляции пакетов; yum выявляет ограничения зависимостей и выполняет дополни- тельные действия, необходимые для завершения процесса инсталляции требуемых паке- тов. Если запрошенный пакет зависит от других пакетов, yum загружает и инсталлирует и эти пакеты. Подобие между apt-get и yum расширяется на опции командной строки, которые понятны им обоим. Например, yum install foo загружает и инсталлирует самую све- жую версию пакета foo (и его зависимости, если это необходимо). Однако существует, как минимум, одно “предательское” отличие: apt-get update обновляет кеш инфор- мации о пакетах apt-get, a yum update — каждый пакет в системе (аналогично коман- де apt-get update). Более того, есть еще команда yum upgrade, которая делает то же, что и yum update, но устаревшими приемами. Команда yum не рассматривает частичные имена пакетов, если не включить символы универсализации оболочки (такие, как ♦ и ?). Например, yum update 'perl*' обнов- ляет все пакеты, имена которых начинаются с “perl”. Не забывайте заключать символы универсализации в кавычки, чтобы избежать возникновения ошибок. В отличие от apt-^get, yum во время запуска по умолчанию сверяет информацию о пакетах, хранящуюся в кеше, с содержимым сетевого хранилища. Для того чтобы от- менить этот процесс, используйте опцию -С, в результате чего yum makecache будет обновлять локальный кеш (на это уйдет некоторое время). К сожалению, опции -С не- достаточно, чтобы повысить производительность медлительной yum. Конфигурационным файлом yum является /etc/yum. conf. Он включает общие оп- ции и указатели на хранилища пакетов. Можно активизировать одновременно множе- ство хранилищ; каждое хранилище может быть связано с множеством URL-адресов. Система управления пакетами Zypper для SIISE: теперь еще более мощная! После многих лет довольно вялого управления пакетами системы SUSE стали пред- лагать оптимальный инструмент в форме Zypper, полнофункционального диспетчера пакетов следующего поколения, созданного на базе RPM. Из всех описанных здесь ин- струментов Zypper предоставляет наиболее гибкие и мощные возможности для инстал- ляции, удаления и запроса пакетов. Это также единственная утилита, которая включает Управление хранилищами из командной строки. 4 Yum Fish Bait не следует путать с Live Prey Technology (LPT), yum3x.com.
442 Часть I. Основы администрирования Освоить этот инструмент будет нетрудно для тех, кто знаком с утилитой apt-get или yum. Основные команды Zypper представлены в табл. 12.5. Таблица 12.5. Команды2уррег Команда__________МШвчемкг * < г j--____ zypper addrepo uri Добавляет хранилище в рабочий комплект zypper di st-upgrade Обновляет систему, обеспечивая соответствие текущему выпуску дистри- бутива zypper info пакеты Отображает информацию о пакетах zypper install пакеты Загружает и инсталлирует пакеты zypper list-updates Перечисляет все обновленные пакеты в хранилище zypper modifyrepo uri Модифицирует свойства хранилища zypper refresh Обновляет метаданные хранилища в локальном кеше zypper remove пакеты Демонтирует пакеты zypper repos Перечисляет хранилища в текущем рабочем комплекте zypper search строка Выполняет поиск пакетов с совпадающими именами zypper shell (или sh) Запускает интерактивный сеанс zypper zypper update Инсталлирует обновленные версии текущих пакетов В приведенном ниже примере мы использовали команду zypper sh, чтобы открыть оболочку Zypper для непосредственного ввода команд. suse$ zypper sh zypper> repos I Enabled I Refresh # 1 Alias I Name 1 I openSUSE 11.1-0 I openSUSE 11.1-0 I Yes I No 2 1 repo-debug I openSUSE-11.1-Debug I No I Yes 3 I repo-non-oss I openSUSE-11.1-Non-Oss I Yes | Yes 4 1 repo-oss I openSUSE-11.1-Oss I Yes I Yes 5 1 repo-source I openSUSE-11.1-Source I No I Yes 6 1 repo-update I openSUSE-11.1-Update | Yes 1 Yes Вместо выполнения команды zypper refresh вручную для поддержания данных пакетов на современном уровне, вы могли бы разрешить автоматическое обновление с помощью команды zypper -f. Файлы конфигурации Zypper, включая конфигурацию программных хранилищ, на- ходятся в каталоге /etc/zypp. Большинству администраторов нет необходимости ис- пользовать эти файлы, но при возникновении такой необходимости вы должны знать, что эти файлы снабжены подробными комментариями и могут оказаться весьма полез- ными. 12.8. Управление пакетами для систем UNIX Инсталляция программного обеспечения и управление пакетами — это та область, в которой Linux имеет явное преимущество перед традиционными операционными систе- мами UNIX. Инсталлирование, модернизация и поиск программ в системе Linux стали практически тривиальными задачами для конечного пользователя или администратора.
Глава 12. Управление программным обеспечением и конфигурацией 443 Поисковые средства стали очень мощными, сообщества пользователей очень большими, а количество активных разработчиков исчисляется в тысячах. В отличие от Linux, системы UNIX оставляют администраторам гораздо меньше па- кетов для выбора и имеют хуже организованный контроль над существующими пакета- ми. В этом разделе мы рассмотрим программы управления пакетами, которые больше всего используются в каждом из наших примеров систем UNIX. Управление пакетами в Solaris С момента выхода SunOS 2.0 в системах Solaris пакетированием традиционно soiaris занималась версия SVR4 (System V Release 4) с некоторыми инкрементными усовершенствованиями, которые сохранили “хромоту” системного уровня на протяжении почти двадцати лет. К сожалению, версия SVR4 остается дефект- ной в таких областях, как управление зависимостями, практичность, поддерж- ка новых технологий (например, ZFS) и сетевых хранилищ. Для OpenSolaris разработчики решили “списать” старую систему и создать совершенно новую. В настоящее время система OpenSolaris использует кроссплатформенную систему управления пакетами (Image Packaging System — IPS), которую можно определить как огромный шаг вперед по сравнению SVR4. В качестве ключевой архитектурной детали она включает сетевые хранилища. В дополнение к стандартным функциям управления пакетами, система предлагает инструменты, предназначенные для разработчиков паке- тов и упрощающие создание и централизацию пакетов. Система IPS также обеспечивает обратную совместимость с унаследованными 8УК4-пакетами. На данный момент можно утверждать, что IPS-пакеты заметно неоднородны в таких форматах, как . deb или RPM. IPS-пакет — это не один файл, который вы могли бы легко скопировать в системах. Пакет, скорее, представляет собой коллекцию файлов, зависи- мостей и других данных, которые необходимо обслуживать из хранилища посредством IPS-демона pkg.depotd. Система IPS все еще остается в состоянии разработки, и более готовый к употреблению формат обещают представить буквально “на днях”. Команда pkg используется для выполнения большинства операций IPS: инсталля- ции, удаления, поиска, запроса статуса и т.д. Кроме того, она позволяет управлять хра- нилищами, хотя в pkg-документации и синтаксисе команд их называют “издателями” (publishers)5. Все эти команды — pkg install, pkg uninstall, pkg search и pkg info — выполняют ожидаемые функции. Команда pkg image-update подобна APT- команде dist-upgrade: она обновляет все инсталлированные пакеты до уровня самых последних доступных версий. По умолчанию хранилище выпусков OpenSolaris является стандартным издателем. В настоящее время он содержит приблизительно 1 700 пакетов6. solaris$ pkg publisher PUBLISHER TYPE STATUS URI opensolaris.org (preferred) origin online http://pkg.opensolaris.org/rele... Подробнее о системе IPS можно узнать, заглянув в man-страницы для -s5 pkg, а для получения информации о команде pkg см. man-страницы для pkg. 5 Команда разработчиков различает понятия “хранилище” (repository) и “издатель” (publisher), Но здесь мы будем считать их эквивалентными. 6 Сравните с более чем 30 000 в Ubuntu Karmic Koala.
444 Часть I. Основы администрирования Управление пакетами в HP-UX КЯ Система управления пакетами в HP, формально именуемая как Software Distri- ЛЗЕЛ butor (SD), предложила пользователям HP-UX надежную систему управле- ния пакетами уже начиная с версии 10. Это серьезный инструмент с набором функций, которые наверняка приведут любого системного администратора в состояние эйфории от эмоционального возбуждения. • Большинство средств предлагает режимы (графический и “из командной строки”), зависящие от способа вызова. • Программами можно управлять в удаленных системах посредством демона swagentd, который запускается во время загрузки и общается с системой через пользовательский протокол данных UDP либо через протокол TCP7. • Хранилища программ могут быть расположены на локальном носителе или в се- тевых каталогах. • Браузер заданий (job browser) позволяет администраторам отслеживать состояния инсталляций удаленных систем в режиме реального времени. Ряд исполняемых файлов, имена которых начинаются с sw (это, в основном, well), составляет комплект инструментальных средств SD (Software Distributor). Отдельные его утилиты и их функции перечислены в табл. 12.6. Таблица 12.6. Список команд, реализованных в Software Distributor Команда install-sd - Реинсталлирует систему Software Distributor system sd Даа Управляет удаленными заданиями: создание, диспетчеризация, мониторинг swacl - Конфигурирует опции безопасности SD swask - Выполняет интерактивные сценарии инсталляции swconfig - Конфигурирует (или реконфигурирует) инсталлированные программы swcopy Да Копирует пакеты в хранилище для будущей инсталляции swinstall Да Инсталлирует пакеты программ из хранилища swjob - Альтернатива команде sd в виде командной строки swlist Да Перечисляет инсталлированные программы или программы, расположенные в хранилище swmodify - Модифицирует каталог программ, инсталлированных в системе6 swpackage - Создает новые пакеты программ swreg - Регистрирует хранилище программ swremove Да Удаляет пакеты из системы или хранилища swverify - Подтверждает целостность инсталлированного программного обеспечения swagentd - Действует как командный агент SD (запускается во время загрузки) a Эта утилита оснащена только графическим интерфейсом (GUI) и не имеет командной строки. Эквивалентом командной строки является swjob. 6 Назывется также базой данных инсталлированных продуктов или IPD. 7 В действительности демон swagentd вызывает процесс swagent, но он прозрачен, т.е. не за- метен для пользователя.
Глава 12. Управление программным обеспечением и конфигурацией 445 Большинство команд SD поддерживает специальный флаг -х, который модифициру- ет стандартные опции применительно к данному инструменту. Например, среди опций команды swinstall есть такие: allow__incompatible (разрешает инсталляцию пакета, предназначенного для другой архитектуры) и autoreboot (при необходимости пере- загружает систему после инсталляции). Полный список опций каждой утилиты пред- ставлен на соответствующей man-странице или в файле /usr/lib/sw/sys.defaults. Более удивительно то, что в файле ~/. swdefaults могут быть сконфигурированы стан- дартные настройки для каждого пользователя. Чаще всего используется команда swinstall, особенно теми администраторами, которые усердно инсталлируют “заплаты безопасности” сразу после их выхода в свет. Команда swinstall -i запускает интерактивную инсталляцию. Графический интер- фейс (GUI) активизируется в случае, если используется система X; в противном случае вы будете использовать текстовый интерфейс. К сожалению, система HP-UX не имеет удобного оперативного хранилища программ, из которого вы могли бы легко инсталлировать “заплаты”. Однако утилита Й^-UX Soft- ware Assistant позволяет анализировать систему с использованием ссылки на Предостав- ляемый системой HP каталог “заплат”, загружает соответствующие “заплаты* и создает программное хранилище, из которого вы можете брать “заплаты” и ими “латать дыры” в системе с помощью команды swinstall. Рассмотрим несколько примеров. Для того чтобы инсталлировать “заплату безопас- ности” PHKL—40197 из NFS-хранилища программ на узле hpux.booklab, мы должны выполнить такую команду. hp-ux$ sudo swinstall -s hpux.booklab:/hpux/patches PHKL__40197 Команда swinstall выполняет конфигурационные Сценарии автоматически во вре- мя инсталляции. Если вам позже понадобится реконфигурировать какой-нибудь пакет, используйте команду swconf ig. Команда swconf ig настраивает программный пакет для локальной системы (например, создавая модификации для файла в каталоге /etd или изменяя разрешения (права доступа) на использование каталога). Для того чтобы реконфигурировать пакет sudo, мы предлагаем выполнить следующую команду. hp-ux$ sudo swconfig -х reconfigure=true sudo Для того чтобы удалить этот пакет, мы бы выполнили команду swremove sudo. Команда swverify исследует пакет и выполняет проверку целостности его основных компонентов. Используйте команду swverify, чтобы устранить такие проблемы, как наличие испорченных файлов настроек или недостающие каталоги. Команда swlist покажет вам программы, инсталлированные в системе или доступ- ные в хранилище. Интерактивный интерфейс, как правило, удобнее для операций по- иска, но посмотрите, насколько просто можно с помощью командной строки получить список Java-пакетов в нашем примере системы HP-UX. hp-ux$ sudo swlist 'Java*’ # Инициализация... # Контактирование с целевым объектом "hpuxll"... # Целевой объект: hpuxll:/ # Javal5JDK 1.5.0.11.00 Java 1.5 JDK for HP-UX Javal5JDK.Jdkl5 1.5.0.11.00 Java 1.5 JDK Javal5JDK.Jrel5 1.5.0.11.00 Java 1.5 JRE # Javal5JRE 1.5.0.11.00 Java 1.5 JRE for HP-UX Javal5JRE.Jrel5 1.5.0.11.00 Java 1.5 JRE Операция удаления — мощная функция системы Software Distributor. Инструменты удаления позволяют системным администраторам записывать программы на удаленные
446 Часть I. Основы администрирования системы (по желанию это может быть сделано по заранее определенному расписанию). Большинство команд поддерживает удаленные операции, а некоторые из них (напри- мер, swinstall) поддерживают их в виде графического интерфейса пользователя (GUI). Операции удаления выполняются с помощью вызовов удаленных процедур (Remote Procedure Call — RPC), а безопасность контролируется с помощью списков управления доступом. Подробнее о конфигурировании удаленных операций см. man 5 sd. Управление программами в AIX ® Большинство поставщиков систем UNIX, по крайней мере, попытались со- хранить связь с Linux в области управления программными продуктами, но корпорация IBM решила выбрать для системы AIX стиль “каменного века” (т.е. периода господства ламповых ЭВМ). В большинстве случаев реко- мендуется использовать “быструю” SMIT-команду (или fastpath-команду8) install_software (System Manager Interface Tool — интерфейсные сред- ства администратора системы), которая неявно вызывает команду installp. Fastpath-команда smit easy_install — еще один вариант, который требует меньшего количества нажатий клавиш, чем команда install_sof tware. Команда installp обрабатывает пакетный IBM-формат (Backup File Format, или .bff), а также более старую версию формата RPM, используемую во многих системах Linux. К сожалению, в команде installp отсутствует множество функций, которые “испорченные” администраторы привыкли воспринимать как само собой разумеющее- ся. Речь идет об инсталляции пакетов из сетевого хранилища и даже запросе пакета. При добавлении пакетов в системы AIX мы всегда используем один из вариантов: smit ins tai l_s of tware или smit easy_install. AIX-команда Islpp выводит список инсталлированных программных пакетов, ко- торые IBM называет “наборами файлов” (filesets). Команда Islpp -I» перечислит все программные продукты в системе — с таким же успехом вы можете использовать и fastpath-команду smit list_installed_sw. Инсталлированные программные продук- ты имеют коды состояния и типа, которые означают условия и происхождение каждого пакета соответственно. Состояние может быть выражено одним из следующих кодовых вариантов: applied (принятый), broken (испорченный), committed (зафиксирован- ный), locked (заблокированный), obsolete (устарелый) или inconsistent (несо- вместимый). Тип определяется таким набором кодовых вариантов: fileset, product, component, feature, RPM или fix. 12.9. Управление изменениями Ошибки — неизменный аспект нашей жизни. Следовательно, очень важно отсле- живать производимые вами изменения в конфигурации, чтобы в случае возникновения ошибок, вызванных этими изменениями, можно было без труда вернуться к надежной конфигурации. В этом разделе мы рассмотрим некоторые распространенные способы управления изменениями на уровне отдельных файлов. Вам остается лишь выбрать средства, которые будут совпадать с вашими потребностями и степенью сложности ва- шей организации. 8 Под fastpath-командой подразумевается команда smit с параметром fast path, который по- зволяет сэкономить время выполнения за счет непосредственного перехода к нужному (для вашей задачи) меню или диалоговому окну с обходом меню верхнего уровня. — Примеч. перев.
Глава 12. Управление программным обеспечением и конфигурацией 447 Создание резервных файлов Эта команда, возможно, покажется вам знакомой. $ ср bigfile.conf bigfile.bak Вы увидели в этой команде что-то позорное? Ну да, ведь настоящие системные ад- министраторы делают гораздо более сложное? В действительности можно многое сказать в пользу этого вида импровизированно- го резервирования. Резервные файлы просто создавать, легко сравнивать (с помощью команды dif f), и потом они создают контрольный след, по крайней мере, резервные файлы могут быть упорядочены по времени модификации. Они не требуют никакого дополнительного программного обеспечения и не допускают, чтобы кто-либо оставил систему резервного копирования в неоднозначном состоянии. Но мы предлагаем свои варианты подхода к этой теме. Лучше всего переместить (с помощью команды mv) исходный файл куда-нибудь под другим именем, а затем ско- пировать его обратно, присвоив ему прежнее имя. С помощью опции -р команды ср можно сохранить настройки атрибутов файла. Эта процедура сохраняет время модифи- кации исходного файла и обрабатывает случаи, когда активныйпроцесс имеет открытую ссылку на исходный файл. Будет еще лучше, если вы добавите короткий аплет-сценарий (scriptlet), подобный представленному ниже, в свой файл ~/ .bash__profile Или */ .profile. Он определя- ет “команду” backup (в действительности функцию bash), которая “собирает” имя ре- зервного файла, причем без вашего участия. function backup () { newname=$l.'date +%Y%m%d.%H%M.bak'; mv $1 $newname; echo "Backed up $1 to $newname."; cp -p $newname $1; } Вот пример. $ backup hello.py Backed up hello.py to hello.py.20091030.1612.bak. В имени файла кодируется дата и время резервирования и время последней модифи- кации файла. Обе эти составляющие информации потенциально полезны. Данный сце- нарий кодирует время в таком виде, чтобы скомпонованные имена файлов позволяли корректно сортировать резервные файлы по дате. Системы, которые регулярно резервируются на магнитную ленту, могут только выи- грать от создания резервных файлов вручную. Восстановление из резервного файла всег- да происходит быстрее и легче, чем с ленты; более того, вручную созданные резервные копии сохраняют дополнительный уровень предыстории, т.е. записей действий пользо- вателя или системы. Формальные системы управления изменениями Следующий уровень сложности и устойчивости занимают формальные системы Управления изменениями, которые представляют собой пакеты программ, отслеживаю- щих, архивирующих и обеспечивающих доступ к множеству версий файлов. Эти пакеты первоначально использовались при разработке программного обеспечения, однако они будут полезными и для системных администраторов.
448 Часть I. Основы администрирования Системы управления изменениями позволяют решить несколько проблем. Самое главное, они обеспечивают организованный доступ к отслеживанию истории изменений в файле, благодаря чему любые изменения можно понять исходя из контекста, а также можно восстанавливать ранние версии файлов. Связанные группы файлов могут вме- сте входить в одну версию, при этом будут учтены все зависимости. Наконец, системы управления изменениями координируют работу множества редакторов, поэтому вряд ли возникнет ситуация, когда чьи-то изменения будут навсегда утеряны9 и несовместимые изменения, производимые в нескольких редакторах, окажутся одновременно активными. В течение нескольких последних лет наблюдался бум в области систем управления версиями с открытым исходным кодом, причем доступные варианты имели между со- бой серьезные отличия. Среди новых систем лидирующими являются Arch, Mercurial и Bazaar-NG. Распределенная система управления версиями файлов Git, разработанная создателем Linux Линусом Торвальдсом (Linus Torvalds), сразу получила поддержку в со- обществе продуктов с открытым исходным кодом и сейчас используется для управле- ния разработкой исходного кода ядра Linux. Проверенная временем система Subversion (представитель предыдущего поколения) по-прежнему находит широкое применение и предлагает пользователям знаменитый графический интерфейс Windows. Можно воспользоваться также и некоторыми коммерческими системами управле- ния изменениями. С какой-нибудь одной из них вы, наверное, уже имели дело, если вам приходилось работать в отделе разработки, и вы пытались адаптировать ее к вашим административным данным. Однако с ними нужно быть очень осторожным; наш опыт подсказывает, что коммерческие системы обычно крайне сложны для использования в системном администрировании. Самыми популярными системами в настоящее время являются Subversion и Git. Каждая из них хорошо зарекомендовала себя в области системного администрирования, но у системы Git есть преимущество, которое заключается в том, что она создает новые хранилища с помощью быстрой и простой операции. О других преимуществах системы Git см. веб-сайт Скотта Чакона (Scott Chacon) whygitisbetterthanx.com. Система Subversion В модели Subversion центральный сервер или каталог действует как официальное хранилище проекта. По умолчанию сервер Subversion является модулем в веб-сервере Apache, что удобно для распределенной разработки программ, но не удобно для адми- нистрирования. К счастью, почитатели Subversion предлагают другой тип сервера в виде демона svnserve. Этот демон можно запускать из домашнего каталога, эксперимен- тируя с системой Subversion, однако в производственных целях он должен иметь свою учетную запись пользователя и запускаться из inetd. Настроить хранилище несложно. Например, ниже показан пример создания нового хранилища Subversion, называемого admin # cd /home/svn # mkdir repositories # cd repositories # svnadmin create admin # chmod 700 admin 9 Предположим, например, что системные администраторы Алиса и Боб оба редактируют один и тот же файл, и каждый из них вносит в файл некоторые изменения. Алиса первая сохранила файл. Когда Боб сохранил свою копию файла, он перезаписал версию Алисы. Если Алиса закроет редактор, ее изменения будут полностью утрачены и не смогут быть восстановлены.
Глава 12. Управление программным обеспечением и конфигурацией 449 Если заглянуть в каталог admin, то в нем вы сможете найти хорошо организованную структуру хранилища, включая файл README. Конфигурационный файл svnserve. conf можно найти в подкаталоге conf. Этот файл сообщает демону сервера о том, как йужно предоставлять доступ к новому каталогу. Ниже показан пример конфигурации, подходя- щей для административных файлов. [general] anon-access = none auth-access = write password-db = passwd realm = The Sysadmin Repository Так как одной из целей, стоящих перед разработчиками Subversion, было создание условий для совместной работы пользователей из разных организаций, в этой системе есть модель управления доступом, которая отделена от модели в операционной системе. Файл passwd (в том же каталоге) содержит список пользователей и их пароли (в откры- том тексте!). Использование открытого текста нельзя отнести к достоинствам; с другой стороны, смягчающим обстоятельством является то, что пароли никогда не передаются по сети. Кроме того, пароли никогда не вводятся пользователями по памяти, поэтому можно присваивать многосимвольные пароли, длина которых выбирается случайным образом. Как следствие, такие пароли должны быть безопасными. Взгляните на следую- щий пример. [users] tobi = Ikadslfkjasdljkhe8938uhau7623rhkdfndf evi = 09uqalkhlkasdgfprghkjhsdfjj83yyouhfuhe fritz - kd939hjahkjaj3hkuyasdfaadfk3ijdkjhf Естественно, разрешения на файл passwd нужно устанавливать отдельно. Все что осталось — это запустить сервер в отдельном хранилище. # svnserve —daemon —root /home/svn/repositories Будучи непривилегированным пользователем, вы можете сейчас выписать архив admin из любого места в сети. $ svn checkout —username tobi svn://server.atrust.com/admin checkout Authentication realm: <svn://server.atrust.com:3690> The Sysadmin Repository Password for 'tobi': <password> Когда вы введете пароль первый раз, система Subversion создает его копию в каталоге . subversion, который она создает в вашем домашнем каталоге. Для того чтобы доба- вить или удалить файлы из локальной копии проекта, используйте команду svn. $ cd checkout $ vi foo.c $ svn add foo.c Когда все будет готово, нужно зафиксировать изменения в хранилище. $ svn commit -m "Initial checkin; added foo.c" Перечислять измененные файлы, которые вы хотите зафиксировать, не нужно, хотя при желании это можно сделать; команда svn разберется с этим сама. Если опустить опцию -т, команда svn запустит редактор, в котором вы сможете отредактировать со- общение о фиксации. Для того чтобы получить самые последние обновления из хранилища, запустите svn update внутри проекта. Subversion выполняет операцию по объединению любых фай-
450 Часть I. Основы администрирования лов, которые были изменены как в вашей локальной копии проекта, так и в главном хранилище. Файлы с неразрешимыми конфликтами маркируются как “conflicted”, и Subversion не разрешит регистрировать их до тех пор, пока вы не устраните проблемы и не сообщите системе, что конфликты были разрешены. $ svn resolved foo.с Если вы хотите узнать, кто производил изменения и какие строки в файле были из- менены, спросите об этом систему Subversion. $ svn blame bar.с Эта команда печатает снабженную ссылками версию файла, которая показывает, когда и кем была изменена строка последний раз. (Оптимисты, а также те, кто терпим к чужим ошибкам, могут использовать синоним svn praise.) Кроме того, можно без труда узнать о различиях относительно некоторой даты или версии. Например, если вы хотите узнать, что было изменено в файле foo. с начиная с 4 июля 2010 года, вам по- может следующая команда. $ svn diff -г ”{2010-07-04}’’ foo.с Последнюю версию системы Subversion можно загрузить на сайте subversion, tigris. org. Стандартной документацией является книга Version Control with Subversion, опубликованная в издательстве O’Reilly. Полный текст этой книги доступен в интерак- тивном режиме на сайте svnbook. red-bean. com. Subversion имеет также знаменитый интерфейс Windows, именуемый TortoiseSVN (зайдите на сайт tortoisesvn.tigris.org). Мы использовали его для управления ис- ходными файлами для этой книги. Система Git Характерной особенностью системы Git является то, что она не имеет центрального хранилища. Вместо регистрации конкретной версии файлов некоторого проекта вы про- сто копируете хранилище (включая всю его историю) и уносите его с собой, подобно тому как рак-отшельник перемещается со своим панцирем. Ваши обращения к храни- лищу представляют собой локальные операции, поэтому они выполняются быстро, и вам не приходится беспокоиться о соединении с центральным сервером. Git использует интеллектуальную систему сжатия данных, чтобы уменьшить стои- мость хранения всей истории, и в большинстве случаев эта система достаточно эффек- тивна. Зачастую рабочие требования на область памяти оказываются даже ниже, чем при использовании Subversion. Git прекрасно подходит для разработчиков, поскольку они могут накапливать свой исходный код в ноутбуке и работать без подключения к сети, используя при этом все преимущества системы управления изменениями. Когда же подходит время совмещать работу многих разработчиков, их изменения могут быть объединены из разных копий хранилища любым способом, подходящим для вашей организации. Всегда можно вер- нуть две копии хранилища к их общему предшествующему состоянию, вне зависимости от того, сколько изменений и итераций было выполнено после разделения. Смешанная стратегия копирования и ветвления, реализованная в Git, не очень-то соответствует контексту системного администрирования, но ее использование локаль- ного хранилища можно считать большим шагом вперед по отношению к системным ад- министраторам (точнее сказать, большим шагом назад, но в хорошем смысле). Системы управления изменениями предыдущего поколения (например, RCS и CVS) хотя и ис-
Глава 12. Управление программным обеспечением и конфигурацией 451 пользовали локальные хранилища, но не могли координировать совместную деятель- ность, обрабатывать объединение изменений и независимую разработку. Сейчас мы прошли полный цикл и очутились в точке, в которой помещение файлов под “надзор” управления версиями является быстрой, простой, локальной операцией. Все современ- ные Git-функции обеспечения совместной работы доступны для использования в соот- ветствующих ситуациях. Прежде чем начать работу с системой Git, укажите свое имя и адрес электронной почты. $ git config —global user.name "John Q. Ulsah" $ git config —global user.email "ulsab@book.admin.com" Для того чтобы отслеживать обычные изменения, вносимые в файлы конфигурации, как правило, используются хранилища, которые никогда не дублируются, и, следова- тельно, никогда не возникает необходимость в их согласовании или объединении. Это соглашение делает использование системы Git очень простым, но поскольку действия будут совершаться от имени пользователя root, важно позаботиться, чтобы все потен- циальные субъекты деяния указали свои имена и адреса электронной почты, как было показано выше. (Git использует ваши персональные данные для записей в журнале, даже когда вы запускаете эту систему через команду sudo.) Для того чтобы создать хранилище, которое охватывает каталог /etc, вам^следует выполнить эти команды. $ cd /etc $ sudo git init Initialized empty Git repository in /etc/.git/ $ sudo git add . $ sudo git commit -m "Initial commit" Created initial commit ed25c29: Initial commit 2538 files changed, 259122 insertions(+), 0 deletions (-) create mode 100644 .java/.systemPrefs/.system.lock create mode 100644 .java/.systemPrefs/.systemRootModFile В приведенной выше последовательности команда git init создает инфраструктуру хранилища в каталоге /etc/ .git. Команда gife^dSR помещает каталог /etc и все его содержимое в Git-список “стадийности”, который представляет собой список файлов, подлежащих использованию в следующей операции git commit. Флаг -m команды git commit включает зарегистрированное сообщение в командной строке. Если вы оставите его, команда git откроет редактор, с помощью которого вы сможете построить это за- регистрированное сообщение. Давайте сделаем изменение и внесем его в хранилище. $ sudo vi mdadm/mdadm.conf $ sudo git commit mdadm/mdadm.conf -m "Added spare to svr4west array" Created commit 901bd39: Added spare to svr4west array 1 files changed, 1 insertions(+), 0 deletions(-) Присваивание имен модифицированным файлам в строке команды git commit иг- норирует обычное использование в Git области “стадийности” и создает модификацию, которая включает только изменения, внесенные в названые файлы. Существующая об- ласть “стадийности” остается неизменной, и Git игнорирует все остальные файлы, кото- рые, возможно, были модифицированы.
452 Часть I. Основы администрирования Если некоторое изменение коснулось нескольких файлов, у вас есть два варианта действий. Если вы точно знаете, какие файлы были изменены, можете всегда перечис- лить их в командной строке, как показано выше. Если вам лень это делать, можете вы- полнить команду git commit -а, чтобы заставить Git добавить все модифицированные файлы в области “стадийности” до выполнения операции. Однако последний вариант имеет два подводных камня. Во-первых, могут существовать модифицированные файлы, которые не связаны с вашими изменениями. Например, файл /etc/mtab в системах Linux поддерживается системой, поэтому он может изменяться даже при отсутствии конфигурационных из- менений. Позволяя этому файлу участвовать в commit-наборах, вы “нарываетесь” на проблемы в будущем, поскольку он (файл) не является реальной составляющей ваших текущих изменений. Если вам позже придется возвращать свои изменения к предше- ствующему состоянию, будет ошибкой “откатывать” назад и файл mtab. Во-вторых, команда git commit -а проверяет на наличие изменений только те фай- лы, которые находятся “во власти” системы управления изменениями в данный момент. Новые файлы такой “заботой” охвачены не будут. Для того чтобы избежать этих “неувязок”, выполните команду git status и оце- ните ситуацию вручную. Эта команда информирует вас о новых, модифицированных и “поэтапных” файлах одновременно. Например, предположим, что мы отредактировали файл /etc/mdadm/mdadm.conf (как в предыдущем примере), а также инсталлировали новый системный демон foobard, конфигурация которого содержится в файле /etc/ foobard/foobard. conf. Тогда Git представит следующую информацию10. $ sudo git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: mdadm/mdadm.conf # modified: mtab # modified: passwd #Untracked files: # (use "git add <file>..." to include in what will be committed) # # foobard/ no changes added to commit (use "git add" and/or "git commit -a") Имя файла foobard.conf здесь не указано, поскольку Git не “видит” содержимое каталога foobard, который содержит его. Мы видим, что оба файла mtab и passwd имеют неожиданные изменения. Изменения в файле mtab определенно фиктивны, но изменения в файл passwd могли быть внесены. Возможно, сценарий инсталляции для foobard создал специальную учетную запись либо кто-нибудь отредактировал файл passwd и забыл внести изменения в хранилище. Для того чтобы прояснить ситуацию, можно выполнить команду git diff passwd и узнать о реальных изменениях, внесенных в файл passwd. Предположим, что в данном случае изменения в файле passwd не были связаны с нашими недавними действиями. Следовательно, нам имеет смысл зарегистрировать эти изменения отдельно от только что сделанных. 10 Даже если эта команда не вносит никаких изменений, тем не менее она должна быть выпол- нена от имени пользователя root, поскольку она создает заблокированные файлы в каталоге . git.
Глава 12. Управление программным обеспечением и конфигурацией $ sudo git commit passwd -m "Checking in existing passwd changes" > Created commit 6f7853c: Checking in existing passwd changes 1 files changed, 1 insertions(+), 0 deletions(-) Мы можем заставить Git игнорировать файл mtab раз и навсегда, но для этого не- обходимо выполнить два действия. Во-первых, “удалим” файл mtab из текущего образа хранилища. $ sudo git rm —cached mtab rm 'mtab’ Опция —cached предотвращает реальное удаление файла mtab, поэтому не выбра- сывайте ее! По существу, мы переводим операцию виртуального удаления файла в Git- область “стадийности”. Git будет вести себя так, как если бы мы удалили файл с помо- щью команды rm. Во-вторых, удаление файла mtab из Git-вселенной предполагает его добавление в Git-список файлов, которые будут игнорироваться в будущем. Это реализуется посред- ством создания или редактирования файла .gitignore. $ sudo sh -с "echo mtab » .gitignore"11 Наконец, мы должны выполнить все оставшиеся изменения. $ sudo git add . $ sudo git commit -m "Installed foobard; added RAID spare" Created commit 32978e6: Installed foobard; added RAID spare 4 files changed, 3 insertions(+), 1 deletion(-) create mode 100644 .gitignore create mode 100644 foobard/foobard.conf delete mode 100644 mtab Обратите внимание на то, что файл .gitignore сам становится частью управляе- мого набора файлов. Было бы неплохо файлы, которые уже находятся под управлением этой системы, повторно добавить в такой набор, поэтому команда git add . — это простой способ выразить следующее желание: “Хочу, чтобы новый образ хранилища вы- глядел так же, как текущий каталог”. В данной ситуации вы могшбы просто выполнить команду git commit -а, поскольку она не затронет ни файл foobard. conf, ни файл .gitignore (эти файлы “слишком свежие” для управляющего Git-механизма и должны быть добавлены в круг управления в явном виде). Стараясь заставить вас подумать, что система Git управляет не только содержимым файлов, но и правами доступа к ним, при добавлении новых файлов в хранилище она отображает режимные коды файлов. Но это не так: Git не отслеживает ни режимы, ни владельцев, ни время модификации. Если вы используете Git для возврата изменений в системных файлах, дважды убедитесь в том, что их атрибуты остались правильными. Отсюда делаем вывод, что вы не можете рассчитывать на использование Git, если пред- полагаете “с нуля” восстанавливать сложные файловые иерархии в ситуациях, когда для вас важна информация о принадлежности ресурсов и правах доступа на них. Использовать Git для базового управления изменениями ненамного труднее, чем создавать резервные копии вручную. Однако трудно требовать от всей вашей команды администраторов быстрого обслуживания системы и при этом пребывать в уверенности, что она (система) используется надлежащим образом. 11 Вызов команды sh в явном виде заставляет выполнить оператор перенаправления в контек- сте корневой оболочки (root shell). Если бы мы просто ввели команду echo mtab » . gitignore, интерпретатор попытался бы открыть файл .gitignore до выполнения команды sudo.
454 Часть I. Основы администрирования 12.10. Локализация и конфигурирование ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Адаптация компьютеров к вашей локальной среде является одним из основных зада- ний системного администрирования: вы должны сообщить системе обо всех принтерах, доступных в сети, запустить специальный демон лицензирования, добавить задачу cron, очищающую каталог /scratch один раз в неделю, интегрировать поддержку для специ- ального сканера и т.п. Для выполнения этих задач нужен структурированный и воспро- изводимый способ. Вам нужно помнить о следующем. • У пользователей нет привилегий системного администратора. Необходимость в них в ходе выполнения обычных операций вызывает подозрение и наверняка свиде- тельствует о том, что кто-то имеет злой умысел. • У пользователей нет намерений причинить вред системе. Вы должны организо- вать защиту системы таким образом, чтобы она была защищена от неумышленных ошибок и не передавала “первому встречному” привилегии системного админи- стратора. • Прежде чем наказывать пользователей, изредка делающих что-то не так, нужно провести с ними беседу. На неумелые действия администратора пользователи за- частую реагируют неадекватно. Следовательно, если ваши действия мешают поль- зователям работать, то это свидетельствует о проблемах в архитектуре. • Старайтесь ориентироваться на заказчика. Беседуйте с пользователями и поста- райтесь узнать, какие задачи для них являются сложными. Попытайтесь сделать эти задачи гораздо проще. • Ваши предпочтения — только ваши, и ничьи более. Пользователи должны иметь собственные предпочтения. По мере возможности такие варианты нужно предла- гать всегда и везде. • Если ваши решения, принимаемые в административных целях, влияют на способ- ность пользователей обучаться системе, постарайтесь их изменить. Расскажите о них пользователям. • Постоянно обновляйте вашу локальную документацию и делайте ее легкодоступ- ной. Более подробно об этом можно прочитать в разделе 32.5. Организация локализации Когда в организации тысяча компьютеров с различными конфигурациями, админи- стратор вынужден тратить большую часть времени на выяснение причин того, почему такая-то проблема возникла только на этом компьютере. Думаете, решением проблемы будет унификация всех конфигураций? Не спешите с выводами! Ограничения, суще- ствующие в реальном мире, а также различные нужды ваших пользователей делают это невозможным. Между администрированием “многочисленных” и “бесчисленных” конфигураций есть разница. Важно разделить вашу установку на управляемые части. Вы увидите, что одни части локализации применяются ко всем управляемым компьютерам, другие — только к некоторым из них, а третьи — только к отдельным компьютерам.
Глава 12. Управление программным обеспечением и конфигурацией 455 Помимо выполнения инсталляций с “чистого листа”, вам придется также постоянно загружать и инсталлировать обновления. Следует иметь в виду, что на разных компьюте- рах установлены различные сроки действия и предъявляются разные требования к ста- бильности и периоду работоспособности. Предусмотрительный системный администратор никогда не станет развертывать но- вые выпуски программного обеспечения на всех компьютерах сразу. Наоборот, нужно делать это с учетом нужд каждой группы и потратить некоторое время на выявление проблем на самых ранних этапах, чтобы не допустить серьезного повреждения системы. Важные серверы нельзя обновлять до тех пор, пока не будет уверенности в надежности производимых изменений, и “избегайте пятниц”, если вы не готовы проводить долгие выходные перед монитором12. Однако в процессе проектирования системы локализации следует убедиться в том, что все исходные данные хранятся в системе управления изменениями. Так вы сможете всегда знать, какие изменения были тщательно проверены и готовы к развертыванию. Кроме того, это позволит вам идентифицировать пользователя, являющегося автором проблематичных изменений. Чем больше человек вовлечено в этот процесс, тем более важным является последнее утверждение. Свои преимущества есть и у разделения базового выпуска ОС и выпуска локализа- ции. В зависимости от того, какую степень стабильности необходимо достичь в вашей среде, вы можете использовать второстепенные локальные выпуски только для того, чтобы устранить ошибки. Наш опыт подсказывает, что добавление новых функций не- большими порциями приводит к более стабильному выполнению операций, чем при постановке изменений в очередь на следующие крупные выпуски, что сразу же снизит качество обслуживания. Часто имеет смысл определять максимальное количество “выпусков”, с которыми вы хотите работать в любой момент времени. Некоторые администраторы придерживаются мнения, что если программное обеспечение работает надежно, то ничего изменять в нем не нужно. Они полагают, что не имеющая под собой почвы модернизация систем стоит времени и денег и что “передовой выпуск” слишком часто означает “выпуск с множе- ством ошибок”. Те же, кто вооружается этими принципами на практике, должны быть готовы к тому, что активные выпуски придется коллекционировать во вместительном каталоге. В отличие от них, активные пользователи ссылаются на присущую выпускам слож- ность и трудность в осмыслении (не говоря уже об управлении) случайной коллекции выпусков, вышедших много лет тому назад. Их козырем являются “заплаты” системы защиты, которые должны обычно применяться универсальным образом и в строгом по- рядке. Инсталлировать “заплаты” в устаревших версиях операционной системы часто бывает просто невозможно, поэтому администраторы сталкиваются с выбором: не ин- сталлировать обновления на некоторые компьютеры или полностью переходить на но- вые внутренние выпуски. Это не сулит ничего хорошего. Ни одна из этих перспектив не является доказуемо верной, хотя мы стараемся при- держиваться мнения, что лучше использовать ограниченное количество выпусков. Лучше выполнять модернизацию по вашему собственному плану, чем руководствоваться чьим-то планом. 12 Вероятным исключением из этого правила являются “заплаты” системы защиты. Нужно ста- раться закрывать все бреши в защите сразу же после их выявления. С другой стороны, “заплаты” системы защиты могут сами вызвать ошибки в работе системы.
456 Часть I. Основы администрирования Тестирование Важно протестировать изменения, пока их еще можно отменить. По меньшей мере, это означает тестирование собственных настроек. Но в той же степени это касается и системного программного обеспечения. Один известный поставщик UNIX однажды выпустил “заплату”, которая, будучи примененной определенным образом, выполняла команду rm -rf /. Представьте последствия установки такой “заплаты” во всей орга- низации без предварительного тестирования. Тестирование особенно полезно, когда применяются средства, способные автомати- чески устанавливать “заплаты” (как большинство систем управления пакетами, рассмо- тренных в этой главе). Не стоит подключать компьютеры, ответственные за выполнение ключевых задач, к службе обновления, спонсируемой поставщиком. Постарайтесь под- ключить к этой службе простой компьютер и уже с него распространяйте изменения на остальные компьютеры в вашей организации. Не допускайте производство обновлений во время проверки, иначе они могут раньше времени проникнуть в вашу производствен- ную систему. CQ О выявлении проблем речь пойдет в разделе 32.2. Если вы предвидите, что заранее запланированное обновление или изменение может вызвать у пользователей некоторые проблемы, уведомьте их о ваших планах и позвольте им связаться с вами, если у них возникнут какие-либо трудности. Позаботьтесь о том, чтобы пользователи имели возможность оперативно сообщать о замеченных ошибках. В транснациональной компании можно подключить к тестированию иностранные офисы. Участие пользователей из других стран особенно важно в случае многоязыковых систем. Если никто в американском офисе не говорит по-японски, необходимо связать- ся с офисом в Токио и попросить их проверить все, что касается поддержки раскладки кандзи (kanji). Вообще, на удивление, большое число системных параметров зависит от региональных особенностей. К примеру, при тестировании систем печати имеет смысл проверять, что произойдет, если задать иной размер бумаги. Ведь в разных странах мо- жет использоваться офисная бумага разного формата. Локальная компиляция Давным-давно, когда существовало множество аппаратных платформ UNIX, про- граммы обычно распространялись в виде архивов исходных текстов. Как правило, это были файлы с расширением . tar. Z, которые нужно было разархивировать с помощью команды uncompress, а потом скомпилировать. Затем программу требовалось инстал- лировать в соответствующий каталог, например /usr/local. Сегодня, в эпоху систем управления пакетами, все меньше программ инсталлируется подобным образом. Задачи администраторов тоже сильно упростились, так как в пакетах указано, куда их инстал- лировать. Несмотря на простоту управления пакетами, многие предпочитают самостоятель- но компилировать программы13. Это позволяет лучше контролировать параметры ком- пиляции. Фанатики могут даже изучить исходный код, чтобы быть уверенными в его безопасности. Кому-то это кажется важным, но мы считаем, что если у вас нет времени и достаточного опыта для анализа каждой из 20 000 строк приложения, то такая мера предосторожности приносит минимальную пользу. 13 Для этой цели можно воспользоваться дистрибутивом Gentoo Linux, который можно пере- компилировать с “чистого листа”.
Глава 12. Управление программным обеспечением и конфигурацией 457 Далеко не все программы выпускаются в виде пакетов для всех дистрибутивов Linux и UNIX, поэтому вам наверняка придется столкнуться с программами, которые необ- ходимо скомпилировать и инсталлировать вручную, особенно если речь идет о 32-раз- рядных компьютерах на платформе Intel. В организации, разрабатывающей собственное программное обеспечение, необходимо также решить, куда его инсталлировать. Исторически сложилось так, что локальные программы чаще всего помещают в ката- лог /usr/local, и это соглашение до сих пор широко распространено. Применяемый в UNIX/Linux стандарт FHS (Filesystem Hierarchy Standard — стандарт иерархии файловой системы) определяет, что после начальной инсталляции операционной системы каталог /usr/local должен присутствовать и быть пустым. Каталог /usr/local хоть и традиционный, но управлять им не всегда легко. Его способ организации (исполняемые файлы помещаются в подкаталог /usr/local/bin, man-страницы — в подкаталог /usr/local/man и так далее) таков, что возникает ряд проблем: трудно инсталлировать несколько версий одной и той же программы, подката- логи сильно разрастаются, сложно поддерживать несколько платформ и т.д. Распространение локализаций Система локализации в вашей организации должна справляться как с исходной инсталляцией, так и с последующими обновлениями. Особую сложность могут пред- ставлять обновления. Основным в этом вопросе является достижение эффективности, поскольку нет смысла повторять всю локализацию с самого начала, чтобы обновить разрешения для одного файла. Несмотря на то что этот процесс производится автома- тически, модель с повторной сборкой с “чистого листа” делает обновление дорогим и длительным во времени процессом. Простой и масштабируемый способ организации локализации заключается в под- держке файлов в структуре дерева, которая напоминает файловую систему производ- ственного компьютера. Специальный инсталляционный сценарий может скопировать дерево на искомый компьютер и выполнить все необходимые дополнительные действия по редактированию. Такой тип установки имеет несколько преимуществ. Вы можете поддерживать столько деревьев локализации, сколько необходимо для реализации вашей локальной администра- тивной схемы. Некоторые деревья будут альтернативными, причем каждый компьютер по- лучит только один доступный вариант. Остальные деревья будут использоваться в качестве оверлеев — их можно будет копировать поверх уже существующих деревьев. Деревья лока- лизации могут перезаписывать файлы, если это будет необходимо, или могут полностью за- менить их структуру. Каждое дерево, которое потенциально инсталлируется независимым образом, должно быть представлено в отдельном проекте управления изменениями. Подход с использованием деревьев-оверлеев позволяет внести гибкость в реализа- цию. Если вы используете систему упаковки для распространения ваших локальных на- строек, то оверлеи можно просто реализовать в независимых пакетах. Можно добавить в пакет соответствующие сценарии настройки и задать их таким образом, чтобы они за- пускались как часть процесса инсталляции. Еще одна хорошая идея с реализацией заключается в использовании утилиты rsync, которая согласовывает искомые компьютеры с деревьями-оверлеями. Утилита rsync ко- пирует только те файлы, которые являются устаревшими, поэтому она может быть эффек- тивной для распространения инкрементных изменений. Такого поведения трудно добить- ся с помощью одной лишь системы упаковки. Утилита rsync описана в разделе 19.2.
458 Часть I. Основы администрирования 12.11. Использование средств УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ Системы локализации обычно являются “доморощенными”. Частично это объясня- ется тем, что все организации отличаются друг от друга и каждая имеет свои особенно- сти. Однако большой вклад вносит также синдром “придуманного не здесь” (not invented here). Возможно, отсутствие господствующего инструмента с открытым исходным кодом для управления конфигурацией заставляет нас смотреть на эту проблему как на такую, которая выходит за рамки стандартизированных средств. Тем не менее такие средства существуют и стоят того, чтобы вы обратили на них вни- мание. В следующих разделах будут рассмотрены распространенные системы в порядке их популярности и схожести. Утилита cfengine: компьютерная иммунная система Одной из наиболее известных утилит локализации является утилита cfengine, раз- работанная Марком Бургессом (Mark Burgess). Она была представлена как “компьютер- ная иммунная система”, выполняющая свои операции на основе модели, в соответствии с которой выбирается способ конфигурирования системы. В случае расхождений между моделью и реальностью, cfengine выполняет определенные действия, направленные на то, чтобы привести систему в соответствие. Благодаря этой модели, утилита cfengine действительно является полезной для постоянной поддержки конфигурации. Утилита cfengine умеет создавать резервные копии файлов, которые она модифи- цирует, и может хранить специальный журнал своих изменений. Ее можно запускать в режиме “бездействие”, в котором она описывает изменения, которые она может произ- вести, в действительности не реализуя их. С помощью специального языка утилиты cfengine можно описать способ конфигу- рирования компьютеров. Это можно сделать, например, так: “Файл xyz должен суще- ствовать в каталоге /etc, иметь права доступа 644 и принадлежать суперпользователю”. Можно написать правила в зависимости от содержимого отдельных файлов. Например, можно определить, что файл /etc/hosts должен содержать строку “router 192.168.0.1”. Утилита cfengine добавит эту строку, если она будет отсутствовать. Язык конфигурации утилиты cfengine позволяет формулировать индивидуальные правила в зависимости от таких факторов, как имя компьютера, тип операционной си- стемы или маска подсети. Эта особенность облегчает написание одного конфигурацион- ного файла, который удовлетворит нужды всех компьютеров, находящихся в зоне вашей административной ответственности. Ниже показан простой пример из мира UNIX. В нем проверяется, является ли /bin символической ссылкой на /usr/bin в компьютерах Sun, производится дополнитель- ная проверка ссылок в старых “коробочных” версиях OSF и удаление из каталога /var/ scratch любых файлов, “возраст” которых превышает семь дней. control: actionsequence = ( links tidy ) links: sun4:: /bin -> /usr/bin # другие ссылки osf::
Глава 12. Управление программным обеспечением и конфигурацией 459 # некоторые специальные osf-ссылки tidy: /var/scratch pattern=* age=7 recurse=inf На домашней странице утилиты cfengine (cfengine. org) можно найти ее описание. LCFG: крупномасштабная система конфигурирования LCFG первоначально была разработана Полом Андерсоном (Paul Anderson) в уни- верситете Эдинбурга (Edinburgh University) в 1993 году. Последний вариант этой систе- мы известен под именем LCFG(ng); она стала популярна среди многочисленных поль- зователей за пределами этого университета. LCFG первоначально предназначалась для управления большими установками Solaris или Linux. Веб-сайт этой системы находится по адресу lefд. огд. Как и cfengine, LCFG имеет специализированный язык конфигураций. Конфи- гурации всех управляемых компьютеров хранятся на центральном сервере в виде под- борки главных конфигурационных файлов. На основе этих файлов LCFG генерирует специализированные XML-файлы, описывающие конфигурацию каждого управляемого компьютера. Демон центрального сервера наблюдает за изменениями, происходящими в главных конфигурационных файлах, и генерирует необходимые XML-файлы. XML-файлы публикуются на внутреннем веб-сервере, из которого клиенты могут из- влекать свои собственные конфигурации. Клиенты используют разнообразные сценарии компонентов для своего конфигурирования в соответствии с XML-образцами. Template Tree 2: помощник cfengine Система Template Tree 2 была создана в Швейцарском федеральном технологическом институте (Swiss Federal Institute of Technology — ETH) Тобиасом Оэтикером (Tobias Oetiker). Она построена на основе компонентов и управляется центральной конфигура- цией. Ее изюминка заключается в возможности использовать двухуровневый подход в определении конфигурации организации. Кроме того, она может работать с перемещен- ными корневыми каталогами на бездисковых компьютерах. На нижнем уровне система состоит из множества “пакетов с функциональными особенностями”. Такой пакет представляет собой коллекцию файлов, сопровождаемых МЕТА-файлом, который описывает, как эти файлы должны быть инсталлированы в иско- мой системе. В качестве функциональной особенности может быть что угодно, начиная от сетевой конфигурации и заканчивая последней версией OpenSSH. Функциональные особенности могут предлагать конфигурируемые параметры, которые можно задавать в главном конфигурационном файле. На верхнем уровне конфигурации представлен главный конфигурационный файл организации, в котором функции собраны вместе и который связывает их с компьюте- рами или группами компьютеров. На этом уровне вы должны определить значения для свободных конфигурационных параметров, предлагаемых каждой функцией. Например, одним из параметров для почтового сервера может быть имя почтового домена. Template Tree 2 комбинирует информацию из главного конфигурационного фай- ла и МЕТА-файлов отдельных функций для генерирования конфигурационного файла cfengine для всей организации. Так как каждая функция должна содержать докумен- тацию о ее назначении и использовании, Template Tree 2 может также генерировать со- ставную документацию.
460 Часть I. Основы администрирования DMTF/CIM: общая информационная модель Группа Distributed Management Task Force (DMTF — группа распределенного управ- ления), насчитывающая, по их собственному признанию, более 3000 активных членов, с 1992 года работает над общей информационной моделью (Common Information Model — CIM), пытаясь разработать стандарты для объектно-ориентированной, межплатформен- ной системы управления. Как утверждает группа DMTF, CIM — это “схема управления..., предназначенная для установления общей концептуальной структуры на уровне фундаментальной топологии по отношению как к классификации и ассоциации, так и к базовому набору классов, ориентированных на установление общей структуры для описания управляемой среды”. Или что-то в этом роде. Членами DMTF являются все основные производители, начиная от Microsoft и за- канчивая Sun. К сожалению, предложенные ими стандарты показывают, что эти фир- мы в совершенстве овладели искусством сбивать с толку и вводить модные словечки. Фирмам, принимающим участие в этом проекте и имеющим солидную репутацию, не к лицу демонстрировать свою привычку стандартизировать все подряд, без разбору. Стандарты сосредоточены вокруг XML и объектной ориентации. Однако нам пока что приходится видеть основанный на них удобный продукт. Во всем этом безобразии есть один светлый момент: благодаря усилиям DMTF по- ставщики вынуждены предоставлять для своих систем, основанных на открытом стан- дарте, интерфейсы конфигурации, доступные программным образом. Для сред UNIX и Linux в этом нет ничего нового, однако и DMTF не является детищем UNIX. Членами DMTF являются Cisco, Microsoft, Symantec и многие другие компании, имеющие не- богатый опыт в обеспечении удобных способов написания сценариев для своих систем. Если бы эти продукты получили API-конфигурации, то это было бы здорово, даже если бы реализация была несовершенной. 12.12. Организация совместного ИСПОЛЬЗОВАНИЯ ПРОГРАММ ЧЕРЕЗ NFS Где следует инсталлировать дополнительное программное обеспечение: на отдель- ных клиентах или на центральном файловом сервере, на котором его можно совместно использовать через NFS? Если речь идет о Linux, то ответ будет такой: “на клиентах”. Однако NFS позволяет выполнять обновления гораздо быстрее (обновить десяток сер- веров NFS будет гораздо быстрее и надежнее, чем 1000 клиентов) и экономить место на дисках клиентов (это не важно для тех, кто живет в мире терабайтовых дисков). На самом деле вопрос сводится к сравнению управляемости и надежности. Доступ на основе сетевой файловой системы с каждым днем становится более централизованным и простым в управлении; с его помощью варианты устранения ошибок и новые пакеты становятся сразу же доступными на всех клиентах. Однако работа по сети может вестись медленнее, чем при доступе к локальному диску. Кроме того, в модели с сетевым сер- вером появляется зависимость от сети и файлового сервера, не только потому, что она добавляет потенциальные места сбоев, но и потому также, что она требует, чтобы кли- енты и серверы согласовывали свои действия относительно таких вопросов, как доступ к общим библиотекам и версии этих библиотек. Недостатком является то, что эти би- блиотеки программ NFS представляют собой продвинутую технологию администриро-
Глава 12. Управление программным обеспечением и конфигурацией 461 вания и должны быть опробованы только в тех средах, в которых координация действий производится из центра. Вообще, в сетях, состоящих из однородных систем, большая часть преимуществ до- стигается за счет совместно используемых хранилищ программного обеспечения. Если ваша организация стандартизировала операционную систему и эта система имеет удоб- ные функциональные средства для управления пакетами, то вам, наверное, лучше всего будет отказаться от использования родной системы. Пространства имен пакетов В традиционной системе UNIX содержимое новых пакетов распределяется по мно- жеству каталогов. Библиотеки поступают в каталог /usr/lib, бинарные файлы — в ка- талог /usr/bin, документация — в каталог /usr/share/docs и т.д. Linux наследует эти свойства в той или иной мере, хотя стандарт Filesystem Hierarchy Standard (Стандарт ие- рархии файловой системы) помогает сделать размещение предсказуемым. (Подробные сведения о FHS можно узнать на сайте pathname. com/fhs.) Преимущество этого соглашения состоит в том, что файлы оказываются в хорошо зна- комых местах. Например, если переменная окружения PATH указывает на каталог /usr /bin и другие стандартные бинарные библиотеки, то новые программы будут доступны сразу же после инсталляции. Недостатком является то, что источники файлов должны быть явным образом от- слежены (средствами системы управления пакетами) и что разрозненные файлы трудно использовать совместно по сети. К счастью, системные администраторы могут выйти из затруднения благодаря пространствам имен пакетов. Суть этой схемы заключается в том, чтобы инсталлировать каждый пакет в его соб- ственный отдельный корневой каталог. Например, вы можете инсталлировать gimp в каталог /tools/graphics/gimp, а бинарные файлы — в каталог /tools/graphics /gimp/bin/gimp. Вы можете создать заново единый бинарный каталог для вашей кол- лекции утилит, поместив символические ссылки в каталог, такой как /tools/bin, на- пример. /tools/bin/gimp -> /tools/graphics/gimp/bin/gimp Пользователи могут добавить каталог /tools/bin в свои переменные РАТЙ, чтобы иметь возможность пользоваться всеми общими утилитами. Определять структуру каталога /tools можно разными способами. Иерархический подход (например, /tools/graphics, /tools/editors и так далее) облегчает обзор и повышает производительность. В соглашение о назначении имен можно включить вер- сию программы, архитектуру оборудования, операционную систему или инициалы от- ветственных пользователей, чтобы одним набором утилит могли пользоваться многие типы клиентов. Например, пользователи Solaris могут включить в свои переменные PATH ссылку /tools/sun4/bin, а пользователи Ubuntu — ссылку /tools/ubuntu/bin. Когда вы инсталлируете новую версию основной утилиты, то старые версии жела- тельно хранить как можно дольше, особенно если пользователи подолгу работают в про- ектах, в которых используется данная утилита. В идеале, новые версии утилит должны быть совместимыми со старыми файлами данных и программным обеспечением, однако на практике иногда встречается обратное. Неплохо заставить пользователей разобраться с конфигурацией и получить доступ к старой версии пакета, но неприятно просто пре- рвать их работу и вынудить иметь дело с последствиями.
462 Часть I. Основы администрирования Управление зависимостями Некоторые пакеты зависят от библиотек или других программных пакетов. Когда вы инсталлируете программное обеспечение локальным образом посредством систем управления пакетами, то для решения этих проблем вы получите всестороннюю по- мощь. Однако когда вы будете создавать собственное сетевое хранилище программ для своей организации, вам придется решать эти проблемы самостоятельно. Если вы управляете библиотеками таким же образом, как и приложениями, можете компилировать утилиты для использования библиотек из общего каталога /tools. Так вы сможете хранить активными одновременно множество версий одной библиотеки. Поскольку зависимые приложения связаны со специфическими версиями библиотеки, установка будет работать стабильно даже после выпуска новых версий библиотеки. Не- достатком является то, что этот тип установки может быть довольно сложным, чтобы его использовать и обслуживать в течение продолжительного периода времени. Старайтесь не создавать ссылки на локальный каталог /tools/lib, содержащий ссылки с обобщенными именами на общие библиотеки. Если вы измените ссылки, у вас могут возникнуть неожиданные проблемы, трудно поддающиеся диагностике. Системы с совместно используемыми библиотеками призваны избавить администраторов от не- которых возможных трудностей, однако в сложных установках лучше не рисковать. Действия, необходимые для того, чтобы компоновщик использовал конкретную вер- сию совместно используемой библиотеки, могут отличаться в разных системах. В Linux вы можете задать переменную окружения LD_LIBRARY_PATH или использовать оп- цию -R компоновщика. Сценарии упаковщика К сожалению, совместимость на уровне библиотек — это полдела. То обстоятельство, что утилиты вызывают одна другую напрямую, порождает другую возможность возник- новения конфликтов. Например, предположим, что утилита f оо часто использует ути- литу bar. После обновления версии bar, используемой по умолчанию, может оказаться, । что утилита f оо неожиданно перестала работать. В этом случае вы можете прийти к вы- ; воду, что fоо зависит от некоторого поведенческого аспекта bar, который уже не под- держивается (или, по крайней мере, не поддерживается по умолчанию). Если ваше хранилище программного обеспечения поддерживает множество версий (например, /tools/util/bar-1.0 и /tools/util/bar-2.0), вы можете устранить эту проблему, переместив исходную версию утилиты f оо в fоо. real и заменив ее неболь- шим сценарием упаковщика. # !/bin/sh # make sure the program finds any files co-packaged with it # first even if it does not use an explicit path. PATH=/tools/util/bar-l.0/bin:$PATH export PATH exec /tools/util/foo-1.0/bin/foo.real Теперь утилита foo будет запускаться с помощью специальной переменной окруже- ния PATH, и она будет вызывать старую версию утилиты bar, а не новую. Упаковщики представляют собой превосходные инструменты, которые могут не толь- • ко справляться с зависимостями между пакетами, но и решать такие задачи, как защита, зависимость от архитектуры или операционной системы и отслеживание использования. | В некоторых организациях упаковывают все совместно используемые библиотеки.
Глава 12. Управление программным обеспечением и конфигурацией 463 12.13. Рекомендуемая литература • Intel Corporation and SystemSoft. Preboot Execution Environment (PXE) Specification, v. 2.7, 1999. pix.net/software/pxeboot/archive/pxespec.pdf • PXELinux Questions, syslinux. zytor. com/wiki/index. php/PXELINUX • Rodin, Josip. Debian New Maintainers' Guide, debian. org/doc/maint-guide. Этот документ содержит хорошую информацию о пакетах формата . deb. • Silva, Gustavo Noronha. APT HOWTO, debian. org/doc/manuals/apt-how to • Hohndel, Dirk and Fabian Hershell. Automated Installation of Linux Systems Using YaST. usenix.org/events/lisa99/full_papers/hohndel/hohndel_html • Stuckelberg, Marc Vuileumier and David Clerc. Linux Remote-Boot mini-HOWTO: Con- figuring Remote-Boot Workstations with Linux, DOS, Windows 95/98 and Windows NT, 1999. tldp. org/HOWTO/Remote-Boot. html • The Red Hat Enterprise Linux System Administration Guide, redhat. com/docs • Wachsmann, Alf. How to Install Red Hat Linux via PXE and Kickstart, stanford.edu /~alf w/PXE-Kicks tart/PXE-Kicks tart. html • Burgess, Mark. “Cfengine: A Site Configuration Engine.” USENIX Computing Systems, vol. 8, No 3, 1995. cfengine.org • HPIgnite-UXAdministration Guide, docs.hp.com/en/5992-5309/5992-5309. pdf • NIMfrom A to Z. www.redbooks. ibm. com/redbooks/pdfs/sg247296 .pdf. Это полное руководство по использованию сетевого менеджера инсталляции (Network Installation Manager). • Solaris Advanced Installation Guide, docs. sun. com/app/docs/doc/802-5740 12.14. Упражнения 12.1. Опишите различия между программами Kickstart, JumpStart и Ignite-UX. Назовите преимущества и недостатки каждой из них. 12.2. Инсталлируйте Subversion из сайта subversion. tigris. org. Установите snvserve и создайте хранилище. Как можно открыть хранилище, чтобы оно использовалось из любого места в сети при поддержке надлежащего уровня безопасности? 12.3. Выясните, как организовано хранение локального программного обеспечения в ва- шей организации. Легко ли масштабируется такая система? Удобно ли с ней рабо- тать? Аргументируйте свои ответы. 12.4. Назовите самые важные особенности системы управления конфигурацией. Что вы можете сказать о защите распределения конфигурационных файлов по сети? 12.5. ★★ Сконфигурируйте какой-нибудь сетевой инсталлятор по своему усмотрению и установите новую систему с локального сервера. Перечислите действия, которые пришлось предпринять для этого. Какие возникли трудности? Какие слабые места с точки зрения масштабируемости были вами замечены при работе с выбранным инсталлятором?
Глава 13 драйверы и ядро Ядро — это часть операционной системы, которая организует доступ к аппаратным средствам через абстрактный высокоуровневый программный интерфейс. Ядро отвечает за реализацию многих концепций, которые пользователями и программами пользова- тельского уровня принимаются как нечто само собой разумеющееся. В частности, на базе низкоуровневых аппаратных возможностей ядро реализует следующие элементы операционной системы Linux: • процессы (защита адресных пространств, разделение времени и ресурсов процес- сора); • сигналы и семафоры; • виртуальную память (подкачка, страничный обмен, отображение виртуальных адресов в физической памяти); • файловую систему (файлы, каталоги, пространство имен); • общий ввод-вывод (специализированное оборудование, клавиатура, мышь, USB); • межзадачное взаимодействие (каналы и сетевые соединения). Ядро содержит драйверы устройств, которые организуют взаимодействие с отдель- ными элементами аппаратного уровня; остальная часть ядра, в основном, не зависит от внешних устройств. Взаимосвязь ядра и драйверов устройств аналогична связи между ядром и процессами пользовательского уровня. Когда процесс просит ядро “прочесть первые 64 байт файла /etc/passwd”, оно (ядро или, вернее, драйвер файловой си- стемы) транслирует эту просьбу в команду драйвера устройства, например “выбрать блок 3348 из устройства 3”. Драйвер представляет эту команду в виде последовательно- сти двоичных кодов, которые записываются в управляющие регистры устройства.
Глава 13. Драйверы и ядро____________________________________________465 Ядро написано преимущественно на языке С, хотя в некоторых случаях используется язык ассемблера, что позволяет вызывать специализированные функции устройств, не- доступные через обычные директивы компилятора. Одно из преимуществ Linux и других сред с открытым исходным кодом заключается в том, что доступность исходного кода ядра позволяет легко, если это слово здесь во- обще применимо, писать собственные драйверы устройств и модули ядра. На заре Linux умение писать такие программные компоненты было необходимым, поскольку для эф- фективного администрирования операционной системы требовалось адаптировать ее к конкретной аппаратной среде. Разрабатывать программы без специальных знаний для разновидностей системы UNIX еще труднее. (Выражаем благодарность компании IBM за прекрасную документацию по разработке драйверов (и не только драйверов).) К счастью, администраторам не приходится копаться в коде ядра. Считается, что подобной деятельностью должны заниматься разработчики ядра и драйверов, а адми- нистраторам следует сосредоточивать усилия на организации работы пользователей. Администраторы могут настраивать ядро и добавлять существующие модули, как описа- но в данной главе, но им не обязательно проходить курс программирования на языке С или языке ассемблера. (Это не всегда справедливо.) 13.1. Адаптация ядра Все платформы UNIX, описанные в этой книге, используют монолитные ядра, в ко- торых вся операционная система работает в пространстве ядра, т.е. в разделе памяти, зарезервированном для привилегированных функций операционной системы. В моно- литном ядре такие службы, как драйверы устройств, взаимодействие процессов, вир* туальная память и планирование (диспетчеризация), выполняются в одном и том же адресном пространстве. Такой подход идет вразрез с архитектурой “микроядра”, в ко- торой многие из перечисленных служб выполняются в пользовательском (непривилеги- рованном) режиме (т.е. в виде регулярных процессов). Преимущества и недостатки этих двух архитектур горячо обсуждались годами, но большинство разработчиков ядра согла- шаются с тем, что оба подхода заслуживают внимания. По сути, Linux также представляет собой монолитное ядро, но оно всегда позволяет использовать драйверы пространства пользователя для многих устройств. Такие проек- ты, как Gelato, UIO, FUSE и FUSD, предоставляют интерфейсы с устройствами в про- странстве пользователя. Тем не менее большинство драйверов все еще реализовано в режиме ядра (защищенном режиме работы процессора), большей частью, по причинам быстродействия. Современные монолитные ядра поддерживают загрузку модулей по запросу, поэтому вы можете включать драйверы устройств и другие функции ядра по необходимости без пересоздания ядра и перезагрузки системы. Драйверы, файловые системы и новые си- стемные вызовы реализованы в большинстве случаев как модули. Память, используемая модулем, выделяется и освобождается по мере загрузки кода или его удаления, что осо- бенно полезно для встроенных систем с ограниченной памятью, поскольку разработчи- ки могут настроить ядро на возможность удаления ненужных устройств. Ядро может узнать о системном оборудовании различными способами. Самый про- стой — предоставление ядру явной информации об устройствах, которые необходимо найти (или в отношении которых можно сделать вид, будто их не существует, как иногда бывает). Некоторые ядра самостоятельно ищут устройства либо на этапе начальной за- грузки, либо динамически в процессе работы системы. Последний метод наиболее часто
466 Часть I. Основы администрирования применяется для современных USB-устройств: карт памяти, цифровых камер, принте- ров и пр. Linux предоставляет поддержку широкого множества таких устройств. Системы AIX и HP-UX обеспечивают весьма ограниченную поддержку, a Solaris занимает, можно сказать, промежуточное положение. В табл. 13.1 указано местоположение каталога построения ядра и стандартное назва- ние инсталлированного ядра в каждом из наших примеров систем. Таблица 13.1. Каталоги построения и названия ядер Система Linux /usr/src/linux /vmlinuz или /boot/vmlinuz Solaris _a /platform/hardware-class-name/unix HP-UX /stand /s tand/vmunix AIX _б /usr/lib/boot/unix а Администраторы редко занимаются построением ядер Solaris, но когда это случается, они создают произ- вольный каталог построения. 6 Ядро системы AIX никогда не перестраивается, даже при добавлении новых модулей и устройств. 13.2. Драйверы и файлы устройств Драйвер устройства — это программа, которая организует взаимодействие системы с аппаратным компонентом определенного типа. Драйвер играет роль переводчика ко* манд конкретного устройства на “язык” API-функций ядра. Благодаря наличию драйвер- ров обеспечивается приемлемый уровень независимости ядра от внешних устройств. В большинстве случаев драйверы устройств являются компонентами ядра, а не полы- зовательскими процессами. Тем не менее доступ к драйверу возможен как из ядра, так, и со стороны команд пользовательского уровня. Для последних создаются специальные - файлы устройств, хранящиеся в каталоге /dev. Ядро преобразует операции, выполняв* мые над этими файлами, в вызовы функций драйвера. Учитывая темпы появления новых устройств, практически невозможно выпускать основные дистрибутивы операционных систем, в которых интегрирована поддержка всех новинок. Поэтому нередко приходится самостоятельно добавлять в систему новые драйверы. В каждой системе можно инсталлировать только “свои” драйверы, причем зачастую только те, которые разработаны специально для конкретной версии ядра. Драйверы для других операционных систем (например, Windows) работать не будут. Об этом следует помнить, покупая новое оборудование1. Кроме того, различные устройства в различной степени совместимы с дистрибутивами Linux и при работе в ее среде могут предостав- лять различные функциональные возможности. Поэтому, выбирая оборудование, следу- ет учитывать опыт его применения в других организациях. Изготовители оборудования обращают все больше внимания на рынки UNIX и Linux и иногда создают UNIX- и Linux-версии драйверов. Если повезет, к устройству будут прилагаться и драйвер, и инструкции по его инсталляции. Но с наибольшей вероятно- стью нужный драйвер можно найти на каком-нибудь неофициальном веб-сайте. Как бы то ни было, ниже мы опишем, что происходит в системе при добавлении в нее драйвера устройства. 1 Проект NDISwrapper для некоторых сетевых устройств позволяет использовать драйверы ; Windows под управлением Linux. Подробнее см. sourceforge.net/projects/ndiswrapper.
Глава 13. Драйверы и ядро 467 Файлы и номера устройств Для многих устройств в каталоге /dev имеются соответствующие специальные фай- лы; исключение в современных операционных системах составляют лишь сетевые уст- ройства. Сложные серверы могут поддерживать сотни различных устройств. Solaris с эти- ми сложностями прекрасно справляется за счет использования отдельного подкаталога /dev для каждого типа устройства: жесткого диска, компакт-диска, терминала и т.д. С каждым файлом связаны старший и младший номера устройства. Посредством этих номеров ядро преобразует обращения к файлу устройства в вызовы нужного драйвера. Старший номер устройства обозначает драйвер, за которым закреплен данный файл (другими словами, он определяет тип устройства). Младший номер устройства обыч- но указывает на то, к какому конкретно устройству данного типа следует обращаться. Младший номер иногда называют номером модуля. Узнать номера устройств позволяет команда Is -1. linux$ Is -1 /dev/sda brw-rw---- 1 root disk 8, 0 Jul 13 01:38 /dev/sda В этом примере выдана информация о первом SCSI-диске. Его старший номер ра- вен 8, а младший — 0. Младший номер иногда используется драйвером для выбора или активизации опре- деленных функций (характеристик) устройства. Например, накопителю на магнитной ленте может соответствовать два файла в каталоге /dev, один из которых при закрытии будет автоматически обеспечивать обратную перемотку, а второй — нет. Драйвер волен интерпретировать младший номер устройства по своему усмотрению. Особенности ра- боты драйвера можно узнать на соответствующей шап-странице. Файлы устройств бывают двух типов: блочно-ориентированные (блочные) и байт- ориентированные (символьные). Чтение из блочного устройства и запись в него осу- ществляются по одному блоку за раз (блок — это группа байтов, размер которой обычно кратен 512), тогда как чтение из символьного устройства и запись в него происходят в побайтовом режиме. Диски и магнитные ленты “ведут двойную жизнь”, а терминалы и принтеры — нет. Драйверы устройств предоставляют стандартный интерфейс с ядром. Каждый драйвер оснащен процедурами для выполнения некоторых или всех перечис- ленных ниже функций. attach close dump ioctl psize read receive reset strategy timeout transmit write open select probe stop Определенные системные функции удобно реализовывать, используя драйвер устрой- ства, даже если связанное с ним устройство не существует. Такие фантомные устройства называют псевдоустройствами. Например, пользователю, зарегистрировавшемуся в си- стеме по сети, назначается псевдотерминал (PTY), который с точки зрения высокоуров- невого программного обеспечения ничем не отличается от обычного последовательного порта. Благодаря такому подходу программы, написанные в эпоху алфавитно-цифровых терминалов, могут функционировать в мире окон и сетей. Вот еще примеры псевдоу- стройств: /dev/zero, /dev/null и /dev/random. Когда программа выполняет операцию над файлом устройства, ядро перехватывает обращение к файлу, ищет в таблице переходов соответствующую функцию и передает Управление соответствующей части драйвера. Для выполнения необычных операций, не имеющих прямых аналогов в модели файловой системы (например, выталкивание дис- кеты из дисковода), используется системный вызов ioctl, который передает пользова- тельскую команду непосредственно драйверу.
468 Часть I. Основы администрирования Создание файлов устройств Файлы устройств можно создавать вручную с помощью команды mknod, которая имеет следующий синтаксис. mknod имя_файла тип старший младший, где имя_ файла — это создаваемый файл устройства, тип — тип устройства (с — в случае символьного устройства и b — в случае блочного), а старший и младший — старший и младший номера устройства соответственно. Если вручную создаете файл устройства, драйвер которого уже имеется в ядре, просмотрите соответствующую этому драйверу шап-страницу и найдите указанные в ней старший и младший номера. jB Под управлением Linux система udev динамически управляет созданием и Zjb удалением файлов устройств в соответствии с реальным наличием (или отсут- ствием) устройств. Демон udevd слушает (т.е. ожидает) сообщения, исходя- щие от ядра, относительно изменений в статусе устройств. На основе данных о конфигурации, хранимых в каталогах /etc/udev и /lib/udev, демон udevd может предпринять множество действий при обнаружении устройства или его отсоединении. По умолчанию он просто создает файлы устройств в каталоге /dev. Подробно система udev описана в разделе 13.8. в системах Solaris каталог /dev в действительности состоит из символических soiaris ссылок на файлы, хранящиеся в каталоге /devices, который представля- ет собой отдельную файловую систему. Файловая система устройств (Device File System — devfs) управляет файлами устройств, содержащихся в каталоге /devices. Эти файлы создаются автоматически во время начальной загруз- ки системы демоном devfsadmd, который продолжает выполняться после загрузки системы для обработки уведомлений об обновлениях, поступающих от ядра. Администраторы могут использовать демон devf sadm для настройки этого процесса, но большинство администраторов не испытывают необходи- мости в его использовании. ЕД Ядро системы HP-UX создает файлы устройств во время загрузки системы. Если новое устройство присоединяется позже, администратор должен соз- давать файлы устройства вручную с помощью команд mksf, insf и mknod. Кроме того, утилита smh включает ограниченный интерфейс для просмотра информации об устройствах. • В системе AIX во время загрузки системы выполняется команда cfgmgr для конфигурирования устройств и инсталляции драйверов для устройств, которые прежде отсутствовали. Она выводит предупреждения относительно устройств, для которых программное обеспечение или драйверы не установлены. После обнаружения устройства система AIX запоминает его, поместив идентифика- тор в Object Data Manager, который мы рассмотрим в разделе 13.6. Команда cfgmgr создает файлы в каталоге /dev для устройств, которые успешно обна- ружены и инициализированы. Если в системе присутствуют описанные выше средства автоматизации (создающие файлы устройств), системным администраторам, использующим текущие версии UNIX и Linux, никогда не приходится вручную управлять файлами устройств с помощью ко- манды mknod.
Глава 13. Драйверы и ядро 469 Соглашения об именовании устройств Соглашения об именовании устройств — это нечто весьма неопределенное. Во мно- гих случаях применяется древняя методика, которую использовали еще при работе на компьютерах PDP-11 фирмы DEC. Для устройств, имеющих как блочную, так и символьную идентичности, имя устрой- ства с посимвольным вводом-выводом обычно начинается с буквы “г” (от англ. raw). Сравните, например, имена /dev/daO и /dev/rdaO. Альтернативное соглашение пред- лагает хранить файлы “символьных” устройств в подкаталоге, имя которого начинается с буквы “г” (сравните, например, имена /dev/dsk/dks0d3s0 и /dev/rdsk/dks0d3s0). Однако буква “г” не всегда означает использование исходного, или необработанного, файла устройства (raw device file). CQ Подробнее о последовательных портах рассказывается в главе 31. Имена файлов последовательных портов обычно состоят из префикса tty и последо- вательности букв, обозначающих конкретный интерфейс, к которому подключен порт. Иногда для терминала имеется несколько файлов устройств. Дополнительные файлы предназначены для поддержки альтернативных методов управления потоками и прото- колов блокировки. Имена накопителей на магнитной ленте часто включают не только ссылку на сам накопитель, но и указание на то, перематывается ли лента после закрытия устройства. У каждого изготовителя свой алгоритм действий. Соглашения об именовании устройств для файлов, которые представляют жесткие диски и SSD (Solid-State Disk — полупроводниковые диски), в большинстве систем до- вольно сложны. Подробнее см. раздел 8.5. Сравнение пользовательских ядер с загружаемыми модулями При инсталляции системы создается базовое ядро, которое рассчитано на запуск большинства приложений в большинстве аппаратных сред. В эту конфигурацию вхо- дит множество различных драйверов устройств и дополнительных пакетов. Кроме того, некоторые драйверы можно динамически вставлять в работающее ядро. В Linux систе- ма udev может также в реальном времени управлять такими изменениями, как вставка USB-устройства. Существуют различные “идеологические” направления на предмет того, должны ли промышленные серверы иметь ядра, построенные по специальному заказу. Несмотря на некоторый потенциальный выигрыш в производительности, особенно во встроенных системах, не использующих большой объем памяти, выбор между наложением заплат и обновлением системы обычно является решающим фактором при принятии решений. Если не существует серьезной необходимости выжимать из системы “последние соки” по части производительности, мы рекомендуем использовать ядро из ассортимента по- ставщика. Когда дело касается поддержки ядра, умный администратор обычно ведет себя как самый ленивый. Используйте везде, где только возможно, динамические модули. Избе- гайте строить ядра на заказ, если в этом нет большой необходимости. В системах Linux большинство USB-устройств можно подключать без какого бы то ни было вмешатель- ства администратора.
470 Часть I. Основы администрирования 13.3. Конфигурирование ядра Linux Д Существует четыре основных метода конфигурирования ядра Linux: • модификация настраиваемых (динамических) параметров ядра; • повторное создание ядра (компиляция исходных файлов ядра с возможны- ми модификациями и дополнениями); • динамическая загрузка новых драйверов и модулей в существующее ядро; • передача ядру директив на этапе начальной загрузки или GRUB (подробнее об этом рассказывалось в разделе 3.2). Каждый из перечисленных методов имеет свою область применения. Проще всего настраивать параметры ядра. Именно так обычно и поступают. Компиляция ядра — наи- более сложный метод, и к нему прибегают реже всего. Но любой метод вполне можно освоить, это лишь вопрос практики. Конфигурирование параметров ядра linux Многие модули и драйверы ядра разрабатывались с учетом того, что все в системе подвержено изменению. Для повышения гибкости были созданы специальные инфор- мационные каналы, которые позволяют системному администратору динамически кор- ректировать различные параметры, определяющие размеры внутренних таблиц ядра й его поведение в конкретных ситуациях. Все эти каналы расположены в файловой си- стеме /ргос (также называемой procfs), которая представляет собой интерфейс между ядром и приложениями пользовательского уровня. Часто большие приложения пользо- вательского уровня (особенно такие приложения “инфраструктуры”, как базы данных) требуют настройки параметров ядра. Специальные файлы в каталоге /ргос/sys позволяют просматривать и динамически из* менять значения параметров ядра. Они напоминают стандартные файлы Linux, но на самом деле являются “шлюзами” к ядру. Если в одном из файлов есть значение, которое требуется изменить, можно попытаться осуществить запись в этот файл. К сожалению, не все фай- лы доступны для записи (независимо от прав доступа), а объем имеющейся документации оставляет желать лучшего. Информацию о некоторых значениях и их назначении можно получить в подкаталоге Docunentation/syscnt каталога с исходным кодом ядра. Например, чтобы изменить максимальное число файлов, которые одновременно мо- гут быть открыты в системе, выполните такие действия. linux$ cat /ргос/sys/fs/file-max 34916 linux$ sudo sh -c "echo 32768 > /proc/sys/fs/file-max" Co временем вырабатывается привычка к столь нетрадиционному способу взаимо- действия с ядром, тем более что он очень удобен. Но сразу предупредим: изменения не сохраняются при перезагрузке. В табл. 13.2 перечислены некоторые обычно настраиваемые параметры. В разных ди- стрибутивах значения, действующие по умолчанию, варьируются в широких пределах. Более надежный способ модификации тех же параметров в большинстве систем реа- лизован в виде команды sysctl. Она либо берет значения переменных из командной строки, либо читает список пар переменная=значение из файла. По умолчанию файл /etc/sysctl. conf, в котором заданы начальные (пользовательские) значения параме- тров, считывается на этапе начальной загрузки.
Глава 13. Драйверы и ядро 471 Таблица 13.2. Файлы каталога /proc/sys, содержащие некоторые настраиваемые параметры ядра Ката- лог" Файл/ладаметр Наз»шче^м»^нта₽1т . j? autoeject Автоматически выталкивает компакт-диск при размонтировании дисково- да CD-ROM F file-max Задает максимальное число открытых файлов. В системе, которой при- ходится работать с большим количеством файлов, можно попытаться увеличить это значение до 16384 F inode-max Задает максимальное число открытых индексных дескрипторов в одном процессе. Этот параметр полезен при создании приложения, которое от- крывает десятки тысяч дескрипторов файлов К Ctrl-alt-del Перезагружает при нажатии комбинации клавиш <Ctrl+Alt+Del>. Применение этого параметра может диктоваться личными предпочтения- ми или соображениями повышения уровня безопасности незащищенных серверных консолей К printk ratelimit Минимальный интервал между сообщениями ядра, в секундах К printk__ ratelimit__burst Устанавливает количество последовательных сообщений, которые долж- ны быть получены, прежде чем значение минимального интервала между сообщениями printk действительно вступит в действие К shmmax Задает максимальный размер совместно используемой памяти N conf/default/ rp_filter Включает проверку маршрута к исходному файлу. Этот механизм проти- водействия имитации соединений вынуждает ядро не обращать внимания на пакеты, полученные по “невозможным” маршрутам N icmp_echo_ ignore__all Задает игнорирование ICMP-запросов, если равен 1 N icmp_echo_ ignore^ broadcasts Задает игнорирование широковещательных ICMP-запросов, если ра- вен 1. Практически во всех ситуациях целесообразно устанавливать это значение равным 1 N ip_forward Разрешает перенаправление IP-пакетов, если равен 1. Если же компью- тер Linux используется в качестве маршрутизатора, это значение необхо- димо устанавливать равным 1 N ip__local_port_ range Определяет диапазон локальных портов, выделяемый во время конфи- гурирования соединения. Для того чтобы повысить производительность серверов, которые инициируют много исходящих соединений, диапазон этого параметра следует расширить до 1024-65000 N tcp__f in_timeout Определяет интервал ожидания (в секундах) заключительного пакета FIN. Для того чтобы повысить производительность серверов, через которые проходит большой объем трафика, следует устанавливать более низкое значение (порядка 20) N tcp_syncookies Защищает от атак волнового распространения пакетов SYN. Этот пара- метр необходимо включать при наличии подозрения о наличии атак отка- за от обслуживания (DOS). а F — /ргос/sys/fs, N — /proc/sys/net/ipv4, К — /proc/sys/kernel, С — /proc/sys/dev/cdram Например, команда linux$ sudo sysctl net.ipv4.ip_forward=0 отключает перенаправление IP-пакетов. (В качестве альтернативного варианта вы може- те просто отредактировать файл /etc/sysctl.conf вручную.) Обратите внимание на
472 Часть I. Основы администрирования то, что символы косой черты в имени файла, хранящегося в структуре каталога /ргос /sys, заменяются точками. Сборка ядра Linux Операционная система Linux развивается столь быстрыми темпами, что рано или поздно ее ядро приходится компилировать заново. Постоянно появляются новые “за- платы” к ядру, драйверы устройств и новые функции. Все это вызывает противоречивые чувства. С одной стороны, удобно иметь под рукой всегда “самое новое и свежее”, а с другой — стремление идти в ногу со временем требует постоянных усилий и значи- тельных затрат времени. Кроме того, если вы используете “стабильную” версию, сборка собственного ядра вряд ли потребуется. Первоначально в Linux была принята схема нумерации ядер, со- гласно которой вторая часть номера версии указывает на то, является ядро стабильным (четный номер) или находится в стадии разработки (нечетный номер). Например, ядро версии 2.6.6 — стабильное, в отличие от ядра версии 2.7.4. В настоящее время эта схема нумерации соблюдается не всегда. Поэтому за официальной информацией по этому во- просу лучше обратиться на сайт kernel. org. Этот сайт является также наилучшим ис- точником исходного кода ядра Linux на тот случай, если конкретный дистрибутив (или его поставщик) не вызывает доверия. Не чините то, что еще не поломано Хороший системный администратор тщательно взвешивает все за и против, плани- руя обновление ядра. Конечно, самая последняя версия — это всегда модно, но является ли она столь же стабильной, что и текущая версия? Нельзя ли подождать до конца ме- сяца, когда будет инсталлироваться целая группа “заплат”? Важно, чтобы желание быть “на гребне волны” не шло вразрез с интересами пользователей. Возьмите за правило устанавливать обновления и заплаты, только когда планируемая выгода (обычно определяемая на основе критериев надежности и производительности) окупит усилия и время, затрачиваемые на инсталляцию. Если выгоду оценить затруд- нительно, это верный признак того, что с обновлением можно подождать. (Безусловно, заплаты, связанные с безопасностью, следует инсталлировать без промедления.) Конфигурирование параметров ядра В данной главе мы используем строку путь_к_исходным_текстам_ядра в каче- стве шаблона любого каталога, который выбран для хранения исходного кода ядра. Большинство дистрибутивов инсталлируют исходные файлы ядра в каталог /usr/src. В любом случае, чтобы можно было создавать ядро системы, должен быть инсталлиро- ван пакет его исходных кодов. Об инсталляции пакетов рассказывается в разделе 12.4. Весь процесс сосредоточен вокруг файла . config, находящегося в каталоге исхо- дных кодов ядра. В данном файле приведена вся информация, касающаяся конфигури- рования ядра, но его формат очень труден для понимания. Для выяснения смысла раз- личных параметров воспользуйтесь пособием по параметрам конфигурирования ядра, приведенным в файле путь_к_исходным_ текстам_ядра/Documenta tion/Conf igure. help. Для того чтобы не редактировать файл . config напрямую, в Linux предусмотрено несколько целевых модулей утилиты make, реализующих различные интерфейсы кон-
Глава 13. Драйверы и ядро 473 фигурирования ядра. Если в системе инсталлирована оболочка KDE, то удобнее всего воспользоваться командой make xconf ig. Аналогично, если вы используете оболочку GNOME, вероятно, лучше всего использовать команду make gconfig. Эти команды отображают окно конфигурации, в котором можно выбрать драйверы устройств, добав- ляемые к ядру (или компилируемые в качестве загружаемых модулей). В отсутствие графической среды на помощь придет команда make menuconfig, ра- ботающая на основе библиотеки curses. Наконец, есть старая команда make config, которая выводит запрос на изменение каждого конфигурационного параметра и не по- зволяет изменять ранее установленные значения. Мы рекомендуем пользоваться коман- дой make xconfig или make gconfig, если используемая среда их поддерживает, и ко- мандой make menuconfig — в противном случае. Применения команды make config лучше избегать (как самой негибкой и самой трудоемкой). При переносе конфигурации существующего ядра в новую версию ядра (или фай- ловую систему) можно использовать команду make oldconf ig для считывания ранее использовавшегося файла . config и определения только тех параметров, которые из- менились или являются новыми. Все эти команды довольно просты, так как их действие сводится к установке нужных опций. Тем не менее они мало подходят для ситуации, когда нужно поддерживать не- сколько версий ядра для различных платформ или аппаратных конфигураций. В любом случае генерируется файл . config, имеющий примерно такой вид. # Automatically generated make config: don't edit # Code maturity level options CONFIG_EXPERIMENTAL=y # Processor type and features t CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M686=y CONFIG_X8 6_WP_WORKS_OK=y CONFIG_X8 6_INVLPG=y CONFIG_X8 6_BSWAP=y CONFIG_X8 6_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y Как видите, содержимое файла не слишком понятно. Не дается никаких поясне- ний относительно того, что означают параметры CONFIG—*. По сути, каждая строка CONFIG—* указывает на активизацию того или иного параметра ядра. Значение у гово- рит о том, что соответствующий компонент компилируется вместе с ядром; значение m означает, что компонент станет загружаемым модулем. Не все компоненты можно сконфигурировать в виде модулей. Сведений об этом в файле . config нет, поэтому нужно самостоятельно покопаться в документации. Не так- то легко узнать и назначение параметров CONFIG—*. Компиляция ядра Формирование файла . config — самый важный этап конфигурирования ядра Linux, но нужно выполнить еще ряд действий, прежде чем будет получено готовое ядро.
474 Часть I. Основы администрирования Схема всего процесса такова: • перейти в каталог верхнего уровня, содержащий исходные коды ядра; • выполнить команду make xconfig, make gconf ig или make menuconfig; • выполнить команду make dep (не требуется для ядер версии 2.6.x и более поздних); • выполнить команду make clean; • выполнить команду make; • выполнить команду make modules_install; • скопировать файл arch/i386/boot/bzlmage под именем /boot/vmlinuz; • скопировать файл arch/i386/boot/System.map под именем /boot/Sys tern, тар; • отредактировать файл /etc/lilo.conf (LILO) или /boot/grub/grub.conf (GRUB) и добавить в него конфигурационные параметры для нового ядра. Выполнять команду make clean не всегда нужно, но удаление всего лишнего позво- лит избежать множества проблем. Добавление драйвера устройства в Linux В Linux драйверы устройств распространяются в одной из трех форм: • “заплаты” к конкретной версии ядра; • загружаемого модуля; • инсталляционного сценария или пакета, устанавливающего соответствующие “за- платы”. Наиболее распространенная форма — инсталляционный сценарий или пакет. Если вам повезло и вы располагаете таким сценарием или пакетом для нового устройства, до- статочно выполнить стандартную процедуру установки новой программы. В большинстве случае установку “заплаты” для конкретной версии ядра можно вы- полнить с помощью следующей команды. linux # cd путь_к_исходным_текстам_ядра ; patch -pl < файл_заплаты Если ни один из этих вариантов неприменим, вам, скорее всего, придется вручную интегрировать драйвер нового устройства в дерево каталогов исходного кода ядра. Ниже мы рассмотрим, как вручную добавить к ядру драйвер некоего вымышленного сетево- го устройства “snarf”. В действительности в Linux этот процесс достаточно утомителен, особенно по сравнению с некоторыми другими версиями UNIX. В подкаталоге drivers дерева файлов исходного кода ядра найдите подкаталог, со- ответствующий типу добавляемого устройства. Вот как выглядит список существующих подкаталогов. linux$ Is -F путъ_к_исходным__текстам_ядра/ асогп/ char/ i2c/ Makefile net/ s390/ telephony/ acpi/ dio/ ide/ md/ nubus/ sbus/ usb/ atm/ f c4/ ieeel394/ media/ parport/ scsi/ video/ block/ gsc/ input/ message/ pci/ sgi/ zorro/ bluetooth/ hil/ isdn/ misc/ pcmcia/ sound/ cdrom/ hotplug/ macintosh/ mtd/ pnp/ tc/ Чаще всего драйверы добавляются в каталоги block, char, net, scsi, sound и usb. В них хранятся драйверы блочных устройств (например, IDE-дисков), символьных устройств (например, последовательных портов), сетевых устройств, SCSI-плат, звуко-
Глава 13. Драйверы и ядро 475 вых плат и USB-устройств соответственно. В других каталогах находятся, в частности, драйверы для самих шин (pci, nubus и zorro); маловероятно, чтобы потребовалось до- бавлять в них файлы. Некоторые каталоги содержат платформенно-зависимые драйверы (macintosh, s390, acorn). Поскольку наше устройство “snarf ’ является сетевым, мы поместим его драйвер в ка- талог drivers/net. Потребуется модифицировать следующие файлы: • drivers/net/Makef ile, чтобы драйвер мог быть скомпилирован; • drivers/net/Kconf ig, чтобы имя устройства появилось в списке конфигурируе- мых параметров. После помещения файлов с расширениями .си .h в каталог drivers/net/snarf нужно добавить запись о драйвере в файл drivers/net/Makefile. Вот эта строка (она располагается ближе к концу файла). obj-$ (CONFIGJSNARF_DEV) += snarf/ Эта строка добавляет драйвер (хранящийся в каталоге snarf/) в процесс компиля- ции ядра. Когда запись добавлена в файл Makefile, нужно убедиться в том, что устройство будет доступно для конфигурирования при настройке ядра. Все сетевые устройства долж- ны быть перечислены в файле drivers/net/Kconf ig. В нашем случае требуется записать в него приведенные ниже строки, чтобы драйвер был добавлен либо как загружаемый мо- дуль, либо как часть ядра (в соответствии с тем, что было заявлено в файле Makefile). config SNARF_DEV tristate ’Snarf device support' Первый компонент, следующий за ключевым словом config, — имя конфигураци- онного макроса, которое должно совпадать с компонентом, следующим за ключевым словом CONFIG в файле Makefile. Ключевое слово tristate означает, что драйвер мо- жет стать загружаемым модулем. Если это не соответствует действительности, вместо tristate необходимо указать ключевое слово bool. Следующим элементом инструк- ции является строка, которая будет отображаться в окне конфигурации. Это может быть произвольный текст, но он должен идентифицировать конфигурируемое устройство. Как при компиляции в ядро нового драйвера устройства указать ядру, что оно должно использовать новый драйвер? В версиях ядра, предшествовавших версии 2.6, эта задача была весьма трудоемкой и требовала знаний в области программирования. Недавние ар- хитектурные изменения, внесенные в модель драйверов устройств, позволяют драйверам стандартным образом связывать себя с ядром. Подробное описание этого процесса выходит за рамки данной книги, но в резуль- тате драйверы устройств, созданные для версии 2.6 (и последующих), выполняют свою регистрацию с помощью макроса MODULE_DEVICE_TABLE. Этот макрос создает соответ- ствующие скрытые связи, чтобы такие утилиты, Kaxmodprobe (описывается ниже в раз- деле 13.7), могли активизировать новые устройства в ядре. 13.4. Конфигурирование ядра Solaris .^>4^ Во время загрузки ядро Solaris исследует устройства и инициализирует драйвер soiaris для каждого найденного устройства. Оно широко использует загружаемые мо- дули и загружает код только для тех устройств, которые реально присутствуют в системе, если нет причин для других действий.
476 Часть I. Основы администрирования В зависимости от вашей точки зрения, такая автоматическая конфигурация делает конфигурирование пользовательского ядра в большей или меньшей степени необходи- мостью в Solaris, по сравнению с другими системами. В идеальном мире ядро должно корректно идентифицировать свою аппаратную среду 100% времени. К сожалению, не- надежное, нестандартное или просто проблемное оборудование (или драйверы) может подчас превратить эти блага цивилизации в источник мучений. Поэтому имеет смысл рассмотреть, как выполнить пользовательскую конфигурацию ядра Solaris и возникнет ли когда-либо необходимость это делать. Пространство ядра Solaris Для того чтобы сделать загрузку модулей по запросу корректной, система Solaris опи- рается на организацию конкретных каталогов. Система Solaris работает в предположе- нии, что определенные каталоги находятся в определенных местах, и эти каталоги долж- ны содержать конкретные типы модулей: • /kernel — общие модули для компьютеров, которые совместно используют на- бор команд; • /platform/имя_платформы/к&хп&1 — модули, специфичные для одного типа компьютеров (например, Sun Fire Т200); • /platform/имя_класса_оборудования/kernel — модули, специфичные для одного класса оборудования (например, все компьютеры sun4u); • /usr/kernel — аналогично каталогу /kernel. Элементы имя_платформы и имя_класса_оборудования можно определить с по- мощью команд uname -i и uname -m соответственно. Рассмотрим пример. solaris$ uname -i SUNW,Sun-Fire-T200 solaris$ uname -m sun4v Во время загрузки Solaris, чтобы найти ядро, проверяет путь /platform/имя_ платформы/kernel: /kernel: /usr/kernel Сначала находятся файлы с именами unix, а затем — файлы с именами genunix. Genunix — это обобщенное ядро, которое представляет независимую от платформы часть базового ядра. Каждый из перечисленных выше каталогов может содержать несколько стандартных подкаталогов, приведенных в табл. 13.3. Поскольку эти подкаталоги могут существовать внутри любых каталогов ядра, для обозначения любого или всех каталогов ядра мы ис- пользуем обобщенное имя ЯДРО. Таблица 13.3. Подкаталоги каталогов ядра Solaris —----— ... и . , ни и-. ! ill ii. . г — Подкаталог Его содержимое . . а drv Загружаемые файлы объектов для драйверов устройств. Файлы конфигурации, которые перечисляют тестовые адреса для каждого устройства Загружаемые файлы объектов для смешанных программ ядра сРи Специальный ЦПУ-модуль для UltraSPARC strmod Модули STREAMS
Глава 13. Драйверы и ядро 477 Окончание табл, 13.3 ...... 'L I 11 1 I > t' Г '.J1 L PI- .4 д I J * '^ВД' 1 И'^нму^ Подкаталог Егосодержимое , . ,.Л;. sparcv9 fs 64-разрядное ядро Модули ядра, связанные с файловой системой exec sched Модули для декодирования существующих форматов Планировщики операционной системы sys genunix unix Загружаемые системные вызовы Обобщенное платформенно-независимое ядро Базовое ядро конкретной платформы Обычно не приходится изменять какие бы то ни было файлы в этих каталогах, если не нужно инсталлировать драйвер нового устройства. У этого правила может быть одно исключение в виде файлов . conf в каталоге ЯДРО/drv, которые задают параметры кон- фигурации конкретных устройств. Однако необходимость изменять их возникает редко, и в действительности вы будете это делать только в случае, если есть соответствующее предписание от производителя устройства. Конфигурирование ядра с помощью файла /etc/system В системе Solaris файл /etc/system служит в качестве основного файла конфигура- ции для ядра. В табл. 13.4 перечислены директивы и переменные, которые могут быть включены в этот файл. Директивы — это самостоятельные ключевые слова; перемен- ным же должны быть присвоены значения с помощью директивы set. Таблица 13.4. Директивы и переменные, используемые в файле /etc/system Имя Тип" ’ Wee»^‘-J:; л ГХ: -'s: rootfs D Задает тип файловой системы корневого раздела rootdev D Задает местоположение корневого раздела forceload D Задает драйверы (“модули”), которые должны быть загружены exclude D Задает модули, которые не должны быть загружены moddir D Задает новый путь к модулям set D Устанавливает переменные настройки ядра (например, maxusers) maxusers V Управляет размерами таблицы и другими параметрами pt_cnt V Устанавливает количество доступных псевдотерминалов (PTY) max_nproc V Устанавливает максимальное количество процессов maxuprc V Устанавливает максимальное количество пользовательских процессов а D — директива, V — переменная Обращение к файлу /etc/system происходит во время загрузки, и если его содержи- мое будет искажено, то система больше не загрузится. Команда boot -а позволяет указать Резервную копию файла /etc/system, если вы создали таковую. (Если у вас нет резерв- ной копии, а существующий оригинал не работает, можете использовать файл /dev/null.) Рассмотрим пример файла /etc/system для простого ядра. rootfs:ufs rootdev:/sbus@l,f8000000/esp@0,800000/sd@3, 0:a
478 Часть I. Основы администрирования Этими строками определяется, что корневая файловая система будет иметь тип UFS (UNIX File System) и что она будет раниться в дисковом разделе sd3a. Синтаксис, ис- пользуемый для задания корневого устройства, идентичен используемому Sun-монито- ром openprom. На разных платформах он разный, поэтому обратитесь к соответствую- щему руководству по работе с аппаратурой или используйте символические ссылки в /dev, которые преобразуют “странные” имена в понятные. Команда Is -1, заданная после ссылки, покажет ее точное длинное имя. moddir: /platform/SUNW,Sun-Fire-T200/kernel:/platform/sun4v/kernel: /kernel:/usr/kernel Эта строка (физически занимающая две строки) задает путь поиска для загружаемых модулей. Это значение предлагается man-страницей ядра, но оно не действует по умол- чанию, поэтому вы должны задать его в явном виде. exclude: lofs forceload: drv/sd Первая строка исключает зацикленную файловую систему из ядра, а вторая прину- дительно обеспечивает загрузку общего драйвера SCSI (sd). set maxusers=64 Эта строка надлежащим образом изменяет размеры таблиц ядра для 64 параллельных регистрационных имен. Добавление в систему Solaris драйверов устройств Solaris-драйверы обычно распространяются как пакеты. Для добавления драйвера устройства в систему используйте утилиту pkgadd. Если драйверы не распространяются как пакеты или добавление пакета завершилось неудачно, обычно тогда драйверы до- бавляют вручную, поскольку все они реализованы как загружаемые модули ядра. Solaris-драйверы почти всегда распространяются как объектные файлы, а не в виде исходного кода, как это принято в системах Linux. В этом примере мы добавляем в Solaris устройство “snarf”. Его драйвер должен быть представлен, как минимум, дву- мя файлами: snarf. о (собственно драйвер) и snarf. conf (файл конфигурации). Оба должны находиться в каталоге /platform/4uname -m' /kernel/drv. После копирования конфигурационный файл можно отредактировать, чтобы задать параметры конкретного устройства. Обычно этого делать не требуется, но иногда неко- торые параметры доступны для “тонкой” настройки. После копирования файлов нужно загрузить модуль. Модули подключаются к рабо- тающему ядру командой add_drv (подробнее о загружаемых модулях речь пойдет ниже в этой главе). В нашем случае команда имеет вид add_drv snarf. Вот и все! Более про- стую процедуру трудно себе представить. Отладка Solaris-конфигурации Поскольку Solaris формирует свой “взгляд на мир” на лету, отладка проблемного компьютера может вызвать трудности. К счастью, Solaris предоставляет ряд инструмен- тов, которые отображают текущую конфигурацию компьютера. Команда prtconf позволяет вывести общую конфигурацию компьютера, включая тип устройства, номер модели, объем памяти и некоторую информацию о сконфигу- рированных аппаратных устройствах. Строки, которые описывают устройства (драй-
Глава 13. Драйверы и ядро 479 веры), имеют отступы, чтобы обозначить существующие зависимости. Удобная опция prtconf -D отображает имя драйвера для каждого устройства. Как видно из следующего фрагмента результатов выполнения команды prtconf, не- сколько строк содержат текст “driver not attached” (драйвер не присоединен). Это сооб- щение может иметь несколько значений: нет драйвера для устройства, устройство скон- фигурировано, но не присоединено к системе или устройство не используется и драйвер не загружен. solaris$ sudo prtconf System Configuration: Sun Microsystems i86pc Memory size: 580 Megabytes System Peripherals (Software Nodes): i86pc scsi_vhci, instance #0 isa, instance #0 i8042, instance #0 keyboard, instance #0 mouse, instance #0 Ip, instance #0 (driver not attached) asy, instance #0 (driver not attached) asy, instance #1 (driver not attached) fdc, instance #0 fd, instance #0 (driver not attached) pit_beep, instance #0 Команда prtconf -D показывает, какие драйверы загружены в каталог /etc/system. solaris$ sudo prtconf -D System Configuration: Sun Microsystems i86pc Memory size: 580 Megabytes System Peripherals (Software Nodes): i86pc (driver name: rootnex) scsi_vhci, instance #0 (driver name: scsi_vhci) isa, instance #0 (driver name: isa) i8042, instance #0 (driver name: i8042) keyboard, instance #0 (driver name: kb8042) mouse, instance #0 (driver name: mouse8042) Ip, instance #0 (driver name: ecpp) asy, instance #0 (driver name: asy) asy, instance #1 (driver name: asy) fdc, instance #0 (driver name: fdc) fd, instance #0 (driver name: fd) pit_beep, instance #0 (driver name: pit_beep) Команда sysdef, помимо информации, выдаваемой командой prtconf, также пере- числяет драйверы псевдоустройств, настраиваемые параметры ядра и имена файлов за- гружаемых модулей. Если вы модифицируете стандартное ядро для важного компьюте- ра, включите в его документацию вывод команды sysdef. Команда modinfo сообщает информацию о динамически загружаемых модулях. Solaris (среди прочего) динамически загружает драйверы устройств, модули STREAMS и драйверы файловых систем. Не удивляйтесь, если результат выполнения команды modinfo будет содержать более 200 элементов. Больше информации о команде modinfo вы найдете в разделе 13.7.
480 Часть I. Основы администрирования 13.5. Конфигурирование ядра HP-UX КЯ Ядро HP-UX — самое монолитное среди наших примеров операционных си- стем, и для него предпочтительнее загружать большинство модулей статиче- ски. Его файл конфигурации отличается сложностью и беспорядочностью. К счастью, HP предоставляет удобное средство конфигурации kcweb, которое в случае доступности X Windows и браузера работает с графическим интерфей- сом; в противном случае используется режим командной строки. Для того чтобы установить режим командной строки, используйте команду kcweb -t. HP-UX считывает параметры конфигурации ядра (модули и настраиваемые значе- ния) из файла /stand/system. Этот файл управляется утилитой kcweb и другими ин- струментами, и администраторы не должны модифицировать его напрямую. Модули и параметры конфигурации могут быть статическими или динамическими. Для изменения статического значения или инсталляции статического модуля необходи- мо перестраивать ядро и перезагружать систему. Динамические модули загружаются и выгружаются по мере их использования, не требуя перезагрузки системы. Подобным образом динамически настраиваемые значения немедленно вступают в силу. Список наиболее полезных настраиваемых свойств ядра HP-UX приведен в табл. 13.5. Таблица 13.5. Настраиваемые значения конфигурации ядра HP-UX Переменная Тип умолчанию -vZ-. <•; maxfiles_lim Динамическая 4096 Жесткое ограничение на количество открытых файлов для процесса maxfiles Статическая 2048 Мягкое ограничение на количество открытых файлов для процесса maxuprc Динамическая 256 Максимальное количество пользовательских процессов nproc Динамическая 4200 Максимальное количество процессов nflocks Динамическая 4096 Максимальное количество блокировок файлов ninode Статическая 8192 Максимальное количество открытых индексных де- скрипторов (inodes) npty Статическая 60 Максимальное количество псевдотерминалов (РТУ) nstrtel Статическая 60 Максимальное количество устройств, находящихся в сеансе сетевого теледоступа (telnet) nkthread Динамическая 8416 Максимальное количество потоков ядра Если необходимо внести изменения в статические модули или статические настраи- ваемые значения, утилита kcweb автоматически выполняет команду mk_kernel для по- строения нового ядра. Новое ядро вступает в силу после следующей перезагрузки системы. 13.6. Управление ядром AIX • Ядро AIX никогда не требует перестройки. Новые устройства конфигуриру- ются динамически посредством черного IBM-ящика, известного как админи- стратор объектных данных (Object Data Manager — ODM). Это довольно за- гадочная структура. Многие параметры, которые обычно можно настраивать
Глава 13. Драйверы и ядро 481 в других ядрах (например установки совместно используемой памяти), совсем не поддаются настройке в системе AIX. Они самостоятельно управляются ядром. Другие реконфигурируемые параметры управляются последовательно- стью шести команд настройки. Администратор объектных данных Вместо хранения данных о конфигурации устройств в текстовых файлах или сцена- риях, AIX собирает их в ODM-базе данных атрибутов/значений. Еще один связующий слой соединяет эти списки свойств с конкретными устройствами (экземплярами драй- веров) и связывает эти драйверы с данными о конфигурации. Цель AIX состоит в поддержке сохраняемости данных, необходимых для конфигури- рования устройств. Вместо возможности конфигурировать устройства “на лету” (напри- мер, с помощью команд if config или ndd) и параллельной системы файлов конфигу- рации и сценариев для выполнения конфигурации во время загрузки, в AIX реализована попытка унифицировать эти функции, чтобы большинство изменений в устройствах происходило автоматически во время перезагрузки системы. Но если бы вы “приняли красную пилюлю” и заглянули на происходящее внутри системы, сложность механизма вас бы могла испугать. Эта система имеет больше то- чек входа, чем традиционная система UNIX, а взаимодействие между компонентами не всегда очевидно. Вот как выглядит структура различных слоев этой системы. • Администратор объектных данных (ODM) представляет собой хранилище конфи- гурации, подобное системному реестру в Microsoft Windows. В действительности оно еще сложнее, чем реестр Windows, поскольку реализует идею объектных схем и экземпляров, а не просто произвольные списки свойств. • Программы получают доступ к ODM через библиотечные подпрограммы, ншвытак- же можете работать с базой данных ODM с помощью команд odmadd, odmcreate, odmdrop, odmshow, odmget, odmchange и odxndelete2. • Семейство команд chdev, Isdev, Isattr, mkdev, rmdev, Is conn и 1 sparent пре- образует ODM-данные конфигурации в информацию для конкретных устройств. В действительности AIX-команда chdev подобна Solaris- и HP-UX-команде ndd (см. раздел 14.13), но по умолчанию chdev записывает ваши изменения как в ре- альный драйвер, так и в ODM-базу данных конфигурации. Даже обычные параме- тры (такие, как имя хоста системы и детали статической маршрутизации) хранятся как атрибуты устройств (под устройством в данном случае понимается экземпляр “интернет-драйвера”). • Несколько административных утилит обеспечивают внешние интерфейсы для се- мейства команды chdev. Например, команда mktcpip ведет себя подобно посто- янной команде ifconf ig, которая преобразует свои аргументы в последователь- ность вызовов команды chdev в сетевых интерфейсах, оказывая влияние как на 2 Дэн Фостер (Dan Foster), один из наших рецензентов, прокомментировал это так: “Управлять базой данных ODM напрямую с помощью odm-команд не рекомендуется, если вы точно не знаете, что именно делаете. Эти команды не выполняют никакого контроля ошибок в данных, которые вы модифицируете, тогда как обычные сЬ-/шк-/гт-средства проверяют достоверность данных до внесения изменений. Эти odxn-команды можно сравнить с заряженным автоматом Калашникова (АК-47) без предохранительного механизма: одно неосторожное прикосновение — и несколько ав- томатных очередей тут же будет выпущено в несчастную цель”.
482 Часть I. Основы администрирования активную, так и на сохраненную конфигурации. (А вы подумали, что ее синтаксис отражает синтаксис команды ifconfig? Вы подумали неправильно.) • ODM — это средство пользовательского уровня, поэтому драйверы не получают к нему непосредственный доступ. Как и в случае с традиционной конфигурацией на базе текстовых файлов, некоторые программы должны считывать ODM-koh- фигурации во время загрузки и записывать соответствующие значения в работаю- щие драйверы. К счастью, большинству администраторов не нужно погружаться в сложности ODM благодаря SMIT (System Manager Interface Tool — интерфейсные средства администрато- ра системы) и таким инструментам более высокого уровня, как mktcpip. Одной обязательной утилитой для управления AIX-устройствами является команда cfgmgr. Выполняйте ее без аргументов от имени суперпользователя после добавления в систему нового оборудования, и это новое оборудование чудесным образом будет распо- знано и станет доступным для использования (ну, как правило, так и происходит). Если же драйверы устройств еще не загружены в базу данных ODM, команда cfgmgr любезно предложит вам пакет для инсталляции из инсталляционных средств AIX. Подробнее о команде cfgmgr можно узнать из соответствующей шап-страницы. Настройка ядра В системе AIX имеется шесть категорий настраиваемых значений и предусмотре- но шесть соответствующих команд для их настройки. Большинство значений связано с оптимизацией рабочих характеристик. Назначение каждой из этих команд описано в табл. 13.6. Отталкиваясь от стандартного соглашения AIX, эти команды используют об- щий синаксис. Параметрами можно также управлять посредством интерфейса SMIT, а именно после “магического заклинания” smit tuning. Подробнее о каждой команде можно узнать из соответствующей шап-страницы. Таблица 13.6. Команды установки настраиваемых параметров ядра в системе AIX драйва, vmo Виртуальная память Минимальное количество свободных страниц ioo Ввод-вывод Асинхронное поведение при вводе-выводе. Конфигурирование JFS2 schedo Планирование про- цессов Временные интервалы, выделяемые процессам, и свойства процессов. Управление виртуальными процессами no Сеть 1Р-пересылка. Размеры буферов TCP- и UDP-сокетов. Значения времен существования пакетов nfso NFS Поддержка формата UTF-8. Поддержка делегирования. Максимальное количество соединений NFS raso Надежность Всего несколько параметров, ни один из которых не представляет ____________большую ценность для администраторов__________________ Эти команды просты в применении. Например, чтобы разрешить IP-форвардирова- ние, выполните следующую команду. aix$ sudo по -о ipforwarding=l
Глава 13. Драйверы и ядро 483 ioooor Для того чтобы получить список всех доступных для настройки параметров подсистемы ввода-вывода, введите такую команду. aix$ sudo ioo -а Для того чтобы гарантировать, что ваши изменения сохранятся после перезагрузки, добавьте к любой из перечисленных выше команд флаг -г. 13.7. Загружаемые модули ядра Загружаемые модули ядра в настоящее время являются общим фактором практиче- ски для всех версий UNIX. Каждый из наших примеров систем в той или иной форме реализует возможность динамической загрузки. Благодаря наличию загружаемых модулей, появляется возможность подключать и отключать драйверы устройств и другие компоненты ядра непосредственно в процессе работы системы. Это значительно облегчает инсталляцию драйверов, поскольку испол- няемый код ядра не нужно менять. Кроме того, уменьшается размер ядра, так как не- нужные драйверы просто не загружаются. Загружаемые драйверы очень удобны, но они не обеспечивают стопроцентную без- опасность. При каждой загрузке и выгрузке модуля существует риск нарушить работо- способность ядра. Поэтому во избежание нарушения работы системы не используйте непроверенные модули. Подобно другим аспектам управления устройствами и драйверами, реализация за- гружаемых модулей зависит от операционной системы. В следующих разделах описаны команды для систем Solaris и Linux, которые поддерживают больше устройств и предо- ставляют администраторам больше возможностей по конфигурированию, чем в других наших примерах систем. Загружаемые модули ядра в Linux Д Система Linux сложнее и одновременно проще системы Solaris в области обра- ботки загружаемых модулей ядра, по крайней мере с точки зрения системного администратора. В Linux почти все программные компоненты можно сделать загружаемыми модулями. Исключение составляет драйвер устройства, на котором расположена корневая файловая система, а также драйвер мыши PS/2. Загружаемые модули обычно хранятся в каталоге /lib/modules/версия, где послед- няя часть имени — это версия ядра Linux, сообщаемая командой uname -г. Получить список загруженных в данный момент модулей можно с помощью команды Ismod. redhat$ sudo /sbin/lsmod Module Size Used by ipmi_devintf 13064 2 ipmi_si 36648 1 ipmi_msghandler 31848 2 ipmi_devintf,ipmi_si iptable_filter 6721 0 ip_tables 21441 1 iptable_filter Как видно из списка, в системе установлены модули интеллектуального интерфейса управления платформой (Intelligent Platform Management Interface — IPMI) и брандмауэр ip tables.
484 Часть I. Основы администрирования Приведем пример загрузки вручную модуля ядра snarf, который был установлен в предыдущем разделе. redhat$ sudo insmod /путь/куда/snarf.ко Загружаемым модулям ядра можно также передавать конфигурационные параметры. redhat$ sudo insmod /путь/куда/snarf .ко io=0xXXX irq=X После того как модуль вручную добавлен к ядру, удалить его можно только по явному запросу или при перезагрузке системы. Для удаления нашего модуля подойдет команда xmmod snarf. Команду rmmod можно использовать в любой момент времени, но она будет рабо- тать, только если число действующих ссылок на модуль (это число указано в столбце Used by (Используется) результата выполнения команды Ismod) равно 0. Модули ядра Linux могут загружаться полуавтоматически с помощью команды modprobe, которая является оболочкой команды insmod и распознает межмодульные зависимости, параметры модулей, процедуры инсталляции и выгрузки. Эта команда просматривает файл /etc/modprobe.conf, чтобы узнать правила обработки каждого модуля. Можно динамически создать файл /etc/modprobe. conf, соответствующий текущей конфигурации ядра, выполнив команду modprobe -с. Эта команда генерирует длинный файл, который выглядит примерно так. #This file was generated by: modprobe -c path [pcmcia] =/lib/modules/pref erred path [pcmcia] =/lib/modules/default path [pcmcia] =/lib/modules/2.6.6 path[misc]=/lib/modules/2.6.6 # Aliases alias block-major-1 rd alias block-major-2 floppy alias char-major-4 serial alias char-major-5 serial alias char-major-6 Ip alias dos msdos alias plipO plip alias pppO ppp options ne io=x0340 irq=9 Инструкции path указывают на то, где находится конкретный модуль. Можно моди- фицировать или добавлять записи данного типа, если нужно хранить модули в нестан- дартных каталогах. Инструкция alias обеспечивает привязку старших номеров блочных устройств, старших номеров символьных устройств, файловых систем, сетевых устройств и сетевых протоколов к соответствующим модулям. Строки с ключевым словом options не генерируются динамически, но администра- тор должен добавить их вручную. Они задают параметры, передаваемые модулю при за-
Глава 13. Драйверы и ядро 485 грузке. Например, в следующей строке модулю устройства “snarf” сообщается его адрес ввода-вывода и вектор прерываний3. options snarf io=0xXXX irq=X Команда modprobe понимает также инструкции install и remove. С их помощью указываются команды, которые выполняются, когда соответствующий модуль подклю- чается к работающему ядру или отключается от него. Загружаемые модули ядра в Solaris В Solaris практически каждый элемент системы представляет собой загружае- SOLSriS мый модуль. Команда modinfo выводит список загруженных на данный мо- мент модулей. Результат выполнения этой команды выглядит так. solaris$ modinfo Id Loadaddr Size Info Rev Modu1eName 1 ff07e000 3ba0 1 1 specfs (filesystem for specfs) 2 ff086000 1340 - 1 swapgeneric (root/swap config) 3 ff082000 la56 1 1 TS (time sharing sched class) 4 ff084000 4 9c - 1 TS_DPTBL (Timesharing dispatch) 5 ff095000 15248 2 1 ufs (filesystem for ufs) 6 ff0b8000 20e0 1 1 rootnex (sun4c root nexus) 7 ff084a00 170 57 1 options (options driver) 8 ff08dc00 2f4 62 1 dma (Direct Memory Access) 9 ff08c000 968 59 1 sbus (SBus nexus driver) В нашей системе Solaris список содержал более 80 строк. Многие элементы, Kdtb- рые в других системах UNIX (например, локальной файловой системе UFS) включейы в ядро, в Solaris представляют собой загружаемые драйверы. Такая организация должна упрощать сторонним фирмам написание пакетов, которые можно легко и безшовно ин- тегрировать в ядро (по крайней мере, теоретически). Как описано выше в этой главе, вы можете добавить в конфигурацию ядра Linux лю- бой драйвер с помощью команды add_drv. Эта команда позволяет загрузить драйвер в ядро и создать соответствующие ссылки на устройства (все эти ссылки пересоздаются при каждой загрузке ядра). После выполнения команды add_drv добавленный драйвер остается частью системы до тех пор, пока вы не удалите его. Вы можете выгружать драй- веры вручную с помощью команды rem_drv. Добавив драйвер с помощью команды add_drv, имеет смысл также выполнить ко- манду drvconf ig. Эта команда переконфигурирует каталог /devices и добавит любые файлы, необходимые для только что загруженного драйвера. Загружаемые модули, которые не доступны посредством файлов устройств, можно загружать и выгружать с помощью команд modload и modunload соответственно. 3 Если система установлена на нестандартном персональном компьютере, то довольно сложно подобрать такую конфигурацию, в которой векторы прерываний и адреса ввода-вывода не пере- крываются. Для того чтобы узнать текущую конфигурацию системы, нужно просмотреть содержи- мое файлов /ргос/interrupts и /proc/ioports. Как правило, для современного оборудования ПК всех основных типов перекрытие векторов прерываний и адресов ввода-вывода не создает осо- бых проблем.
486 Часть I. Основы администрирования 13.8. Linux-менеджер устройств udev — полезно и ПРИЯТНО Файлы устройств в течение многих лет представляли для администраторов серьезную проблему. Когда системы поддерживали лишь несколько типов устройств, обслужива- ние файлов устройств вручную было вполне приемлемым. Но по мере увеличения ко- личества доступных устройств файловая система /dev загромождается, зачастую “обро- стая” файлами, не относящимися к текущей системе. Система Red Hat Enterprise Linux версии 3 включала более 18 000 файлов устройств, по одному для каждого возможного устройства, которое потенциально могло быть подключено к системе! Создание статиче- ских файлов устройств быстро становится крупной проблемой, создающей для систем- ного администратора тупиковую ситуацию. USB, FireWire, PCMCIA и другие интерфейсы с устройствами привносят дополни- тельные трудности. Например, если пользователь подключается к двум внешним жест- ким дискам, то для системы было бы удобно распознавать и автоматически монтировать каждый драйвер с постоянным именем устройства. В идеале драйвер, который в ис- ходном положении распознается под именем /dev/sda, должен оставаться доступным под тем же именем (/dev/sda), несмотря на периодические отключения и безотноси- тельно к активности других устройств и шин (каналов). Наличие таких динамических устройств, как камеры, принтеры, сканеры и другие типы съемных носителей данных, наводит дополнительную “тень на плетень” и более усложняет проблему постоянной идентичности. Элегантное решение этих проблем пришло в виде менеджера устройств udev, пред- ставляющего собой реализованную в пространстве пользователя (а не внутри ядра) си- стему управления устройствами, которая информирует приложения конечного пользо- вателя об устройствах при их подключении или отключении. Менеджер устройств udev опирается на описанную ниже систему sysf s, которая позволяет узнать, что происходит с системными устройствами. Он использует ряд специальных правил для понимания со- ответствующих соглашений о назначении имен. Менеджер udev автоматически поддер- живает файлы устройств в каталоге /dev ( причем при минимальном их разрушении). Только те устройства, которые доступны в системе в данный момент, имеют файлы в каталоге /dev. Администраторам Linux следует понимать, как работает системное правило менедже- ра udev, и знать, как использовать команду udevadm. Но прежде чем углубляться в эти детали, рассмотрим сначала базовую технологию sysf s. Файловая система sysfs: доступ к "сердцу" устройств в Linux Виртуальная файловая система sysfs (была добавлена в ядро Linux в версии 2.6) предоставляет хорошо организованную и подробную информацию обо всех доступных устройствах, их конфигурациях и состоянии. Доступ к драйверу возможен как из ядра, так и со стороны команд пользовательского уровня. Для выяснения всей информации об устройстве (используемом им прерывании IRQ, количестве блоков, поставленных в очередь на запись контроллером диска, и т.п.) мож- но исследовать каталог /sys, в котором обычно монтируется система sysfs. Один из основополагающих принципов формирования этой файловой системы состоит в том,
Глава 13. Драйверы и ядро 487 что каждый файл в каталоге /sys должен представлять только один атрибут связанно- го с ним устройства. Это соглашение обеспечивает определенное структурирование в остальном хаотичного набора данных. В табл. 13.7 перечислены каталоги, включенные в корневой каталог /sys, каждый из которых является подсистемой, регистрируемой с помощью sysf s. Состав этих катало- гов зависит от дистрибутива. Таблица 13.7. Подкаталоги каталога /sys Каталог Описание ’ : С /., ~ block bus class Информация о блочных устройствах (например, о жестких дисках) Шины, известные ядру: PCI-E, SCSI, USB и др. Дерево, организованное функциональными типами устройств, например звуковые и графи- ческие карты, устройства ввода и сетевые интерфейсы dev devices firmware Информация об устройствах, разделенная между символьными и блочными устройствами Корректное представление (с точки зрения наследственности) всех обнаруженных устройств Интерфейсы с такими зависимыми от платформы подсистемами, как ACPI fs kernel module Каталог для хранения некоторых (но не всех) файловых систем, известных ядру Значение таких внутренних характеристик ядра, как кеш и виртуальная память Динамические модули, загруженные ядром power Некоторые сведения о состоянии производительности системы (обычно не используется) Первоначально информация о конфигурации устройств, если таковая существовала, хранилась в файловой системе /ргос. Хотя информация о процессах и ядре, связанная со временем выполнения, и в дальнейшем будет храниться в каталоге /ргос, предпо- лагается, что со временем вся информация об устройствах будет перемещена в каталог /sys. Исследование устройств с помощью команды udevadm Команда udevadm запрашивает информацию об устройствах, инициализиру- ет события, управляет демоном udevd и отслеживает события менеджера udev и ядра. Системные администраторы используют ее, в основном, для создания и тестирования правил, которые описываются в следующем разделе. Команда udevadm в качестве своего первого аргумента ожидает одну из шести ко- манд: info, trigger, settle, control, monitor или test. Особый интерес для систем- ных администраторов представляют две команды: info, которая выводит информацию, зависящую от конкретного устройства, и control, которая запускает и останавливает работу менеджера устройств udev или заставляет его перезагрузить свои файлы правил. Команда monitor отображает события по мере того, как они происходят в системе. Следующая команда отображает все udev-атрибуты для устройства sdb. Здесь резуль- тат выполнения команды представлен в усеченном виде, но в действительности он со- держит список всех родительских устройств (например, шины USB), которые в дереве Устройств являются предками устройства sdb. linux$ udevadm info -a -n sdb looking at device ’/devices/pciOOOO:00/0000:00:11.0/0000:02:03.O/usbl/l-l/ 1-1:1.0/host6/target6:0:0/6:0:0:0/block/sdb': KERNEL=="sdb"
488 Часть I. Основы администрирования SUBSYSTEM=="block" DR1VER=="" ATTR{range}=="16" ATTR{ext_range}=="2 5 6" ATTR{removable}=="!" ATTR{ro}=="0" ATTR{size}=="1974271" ATTR{capab i1i tу}=="5 3" ATTR{stat}==" 71 12 0 592 986 1561 860 872" 0 1 1 Все пути в результате выполнения команды udevadm (например, /devices /pciOOOO: 00/...) даны относительно каталога /sys. Этот результат отформатирован так, чтобы вы могли при построении правил обра- щаться к менеджеру udev. Например, если бы запись ATTR{size}=="1974271" была уникальной для этого устройства, вы могли бы скопировать этот фрагмент в правило в качестве идентифицирующего критерия. Узнать дополнительные возможности и синтаксис команды udevadm вы сможете, об- ратившись к ее man-странице. Создание правил и постоянных имен Менеджер устройств udev опирается на набор правил, определяющих возможности управления устройствами и присваивания им имен. Стандартные правила хранятся в каталоге /lib/udev/rules .d, а локальные — в каталоге /etc/udev/rules .d. Вам не нужно редактировать или удалять стандартные правила — их можно игнорировать или переопределить путем создания нового файла стандартных правил с прежним именем в пользовательском каталоге правил. Главным файлом конфигурации для менеджера udev является файл /etc/udev /udev. conf. Файлы udev. conf в наших примерах дистрибутивов содержат только ком- ментарии, за исключением одной строки, которая позволяет выполнять регистрацию ошибок. Жаль, но из-за политических разногласий между дистрибьюторами и разработчика- ми совместная деятельность дистрибьюторов на ниве создания правил оставляет желать лучшего. Многие имена файлов в каталоге стандартных правил не меняются при пере- ходе от дистрибутива к дистрибутиву, в то время как содержимое этих файлов претерпе- вает существенные изменения. Файлы правил именуются в соответствии с шаблоном пп-описание, rules, где пп — обычно двузначное число. Файлы обрабатываются в лексическом порядке, поэто- му меньшие числа обрабатываются первыми. Файлы из двух каталогов правил объеди- няются до того, как демон менеджера udev, udevd, проанализирует их. Суффикс . rules обязателен — без него файлы игнорируются. Правила задаются в таком формате. условие, [условие, ...] назначение [,назначение ...] Здесь элемент условие определяет ситуации, в которых должно применяться данное правило. Каждое выражение условия состоит из ключа, знака операции и значения. Например, в качестве потенциального компонента правила может использоваться усло- вие ATTR{size}="1974271" (см. пример выше), отбирающее все устройства, атрибут size которых в точности равен значению 1 974 271.
Глава 13. Драйверы и ядро 489 Большинство ключей, участвующих в задании условия, связаны со свойствами устройств (которые демон udevd получает из файловой системы /sys), но есть и такие ключи, которые относятся к другим контекстно-зависимым атрибутам, таким как обра- батываемая операция (например, добавление устройства или его удаление из системы). Все элементы условие должны сопоставляться в порядке активизации правила. Ключи, воспринимаемые менеджером устройств udev, представлены в табл. 13.8. Таблица 13.8. Ключи, воспринимаемые менеджером устройств udev ACTION Сопоставляется с типом события, например добавление или удаление DEVPATH Сопоставляется с конкретным путем устройства KERNEL8 Сопоставляется с именем ядра для устройства SUBSYSTEM8 Сопоставляется с конкретной подсистемой DRIVER3 Сопоставляется с драйвером, используемым устройством ATTR{имя файла}3 Сопоставляется с sysf s-значениями устройства; имя файла — это листок в де- реве sysf s, который соответствует конкретному атрибуту ENV{ключ} Сопоставляется со значением переменной среды TEST{omask} Проверяет факт существования файла; элемент omask необязателен PROGRAM Выполняет внешнюю команду; условие считается выполненным, если код завер- шения команды равен 0 RESULT Сопоставляется с результатом последнего вызова посредством ключа PROGRAM а Возможна также смешанная версия. Выполняется поиск пути устройства, который совпадает с заданным значением. В правилах сопоставления элементы назначение задают действия, которые должен предпринять демон udevd, чтобы обработать событие. Формат этих элементов подобен формату элементов условие. Самым важным ключом элемента назначение является ключ NAME, который означает, каким именем менеджер udev должен назвать устройство. Необязательный ключ SYMLINK создает символическую ссылку на устройство через путь, заданный в каталоге /dev. Рассмотрим совместную работу этих компонентов на примере флеш-памяти USB. Предположим, что мы хотим сделать имя этого устройства постоянным и обеспечить автоматическое его монтирование и размонтирование. Вставим нашу флеш-память и посмотрим, как ядро может идентифицировать ее. Возможны два пути. Выполнив команду Isusb, мы можем исследовать шину USB на- прямую. ubuntu$ Isusb Bus 001 Device 007: ID 1307:0163 Transcend, Inc. USB Flash Drive Bus 001 Device 001: ID ld6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID ld6b:0001 Linux Foundation 1.1 root hub В качестве альтернативного варианта можем проверить записи в журнале, представ- ленные в файле /var/log/messages. В нашем случае устройство оставляет простран- ную контрольную запись. Aug 9 19:50:03 ubuntu kernel: [42689.253554] scsi 8:0:0:0: Direct-Access Utl63 USB2FlashStorage 0.00 PQ: 0 ANSI: 2 Aug 9 19:50:03 ubuntu kernel: [42689.292226] sd 8:0:0:0: [sdb] 1974271 512- byte hardware sectors: (1.01 GB/963 MiB)
490 Часть I. Основы администрирования Aug 9 19:50:03 ubuntu kernel: [42689.304749] sd 8:0:0:0: [sdb] 1974271 512- byte hardware sectors: (1.01 GB/963 MiB) Aug 9 19:50:03 ubuntu kernel: [42689.307182] sdb: sdbl Aug 9 19:50:03 ubuntu kernel: [42689.427785] sd 8:0:0:0: [sdb] Attached SCSI removable disk Aug 9 19:50:03 ubuntu kernel: [42689.428405] sd 8:0:0:0: Attached scsi generic sg3 type 0 Представленные выше зарегистрированные сообщения означают, что устройство было распознано как sdb, и это позволяет нам просто идентифицировать устройство в файловой системе /sys. Теперь мы можем просмотреть файловую систему /sys с помо- щью команды udevadm и поискать фрагменты правил, которые служат характеристикой устройства и могут использоваться в правилах менеджера udev. ubuntu $ udevadm info -a -p /block/sdb/sdbl looking at device '/devices/pciOOOO:00/0000:00:11.0/0000:02:03.0/usbl/l-l/ 1-1:1.0/host30/target30:0:0/30:0:0:0/block/sdb/sdbl': KERNEL=="sdbl" SUBSYSTEM=="block" DRIVER=="" ATTR(partition}=="1" ATTR{start}=="63" ATTR{size}=="1974208" ATTR{ stat }==" 71 792 1857 808 0 0 0 0 0 512 808" looking at parent device ’/devices/pciOOOO:00/0000:00:11.0/0000:02:03.0/ usbl/1-1/1-1:1.0/host30/target30: 0:0/30:0:0:0/block/sdb': KERNELS=="sdb" SUBSYSTEMS=="block" DRIVERS=="" ATTRS{scsi_level}=="3" ATTRS(vendor}=="Utl63 " ATTRS(model}=="USB2FlashStorage" Результат выполнения команды udevadm отображает возможности совпадений с за- данными значениями. Одна из них — поле size, которое, вероятно, является уникаль- ным для данного устройства. Но если бы размер раздела изменился, устройство не было бы распознано. Мы можем также использовать сочетание двух значений: соглашение ядра о назначении имен в виде sd с дополнительной буквой и содержимое атрибута мо- дели USB2Flashstorage. При создании правил для данного конкретного устройства флеш-памяти еще одним вариантом мог бы послужить регистрационный (серийный) номер устройства (здесь он не отображен). Поместим наши правила для этого устройства в файл /etc/udev/rules. d/10-local. rules. Поскольку мы собираемся “убить сразу несколько зайцев”, нужно создать ряд правил. Прежде всего, мы должны позаботиться о создании символических ссылок на устрой- ство в каталоге /dev. Следующее правило для идентификации устройства использует наши знания о ключах условий ATTRS и KERNEL, почерпнутых из команды udevadm. ATTRS{model}=="USB2FlashStorage", KERNEL=="sd[a-z]1", SYMLINK+="ate- flash%n"
Глава 13. Драйверы и ядро 491 Когда наше правило срабатывает, демон udevd устанавливает значение /dev/ate- f lashN в качестве символической ссылки на устройство. В действительности мы не ожидаем в системе появления более одного такого устройства. Если обнаружится не- сколько копий устройства, они получат уникальные имена в каталоге /dev, но точные имена зависят от порядка вставки устройств в систему. Затем мы используем ключ ACTION для выполнения ряда команд всякий раз, ког- да устройство будет появляться на шине USB. Ключ элемента назначение RUN позво- ляет создавать соответствующий каталог точки монтирования и монтировать там наше устройство. ACTION=="add", ATTRS{model}=="USB2FlashStorage", KERNEL=="sd[a-z]1", RUN+="/bin/mkdir -p /mnt/ate-flash%n” ACTION=="add", ATTRS{model}=="USB2FlashStorage", KERNEL=="sd[a-z]1", PROGRAM=="/lib/udev/vol_id -t %N", RESULT=="vfat", RUN+="/bin/mount -t vfat /dev/%k /mnt/ate-flash%n" Ключи PROGRAM и RUN выглядят похожими, но напомним, что PROGRAM — это ключ условия, который активен во время фазы выбора правила, тогда как RUN — это ключ назначения, который является частью действий, инициированных правилом. Второе правило с помощью опции -t vfat в команде mount еще до операции монтирования проверяет, что флеш-память содержит файловую систему Windows. Аналогичные правила после удаления устройства из системы позволяют выполнить очистительно-восстановительные операции. ACTION=="remove", ATTRS{model}=="USB2FlashStorage", KERNEL=="sd[a-z]1", RUN+="/bin/umount -1 /mnt/ate-flash%n" ACTI0N=="remove", ATTRS{model}=="USB2FlashStorage", KERNEL=="sd[a-z]1", RUN+="/bin/rmdir /mnt/ate-flash%n" Теперь, когда правила подготовлены, мы должны уведомить демон udevd о наших изменениях. Команда control, используемая в качестве аргумента команды udevadm, — одна из немногих, которые требуют полномочий суперпользователя. ubuntu$ sudo udevadm control —reload-rules Опечатки молча игнорируются после перезагрузки, даже с использованием флага —debug, поэтому не забудьте дважды проверить синтаксис своих правил. Вот и все! Теперь, когда флеш-память вставляется в разъем USB-порта, демон udevd создает символическую ссылку /dev/ate-f lashl и монтирует устройство /mnt/ate- flashl. ubuntu$ Is -1 /dev/ate* Irwxrwxrwx 1 root root 4 2009-08-09 21:22 /dev/ate-flashl -> sdbl ubuntu $ mount | grep at /dev/sdbl on /mnt/ate-flashl type vfat (rw) 13.9. Рекомендуемая литература • Bovet, Daniel P. and Marco Cesati. Understanding the Linux Kernel (3rd Edition). Seba- stopol, CA: O’Reilly Media, 2006. • Corbet, Jonathan, et al. Linux Device Drivers (3rd Edition). Sebastopol, CA: O’Reilly Media, 2005. Эта книга доступна также по адресу: lwn.net/Kernel/LDD3.
492 Часть I. Основы администрирования • Love, Robert. Linux Kernel Development (2nd Edition). Indianapolis, IN: Novell Press, 2005. (Роберт Лав. Разработка ядра Linux, 2-е издание. ИД “Вильямс”, 2006 г.) • McDougall, Richard and Jim Mauro. Solaris Internals: Solaris 10 and Open-Solaris Kernel Architecture (2nd Edition). Upper Saddle River, NJ: Prentice Hall PTR, 2006. 13.10. Упражнения 13.1. Опишите, что делает ядро. Объясните разницу между загрузкой драйвера в каче- стве модуля и его статической компиляцией в ядро. 13.2. Процесс в системе HP-UX завершился аварийным отказом и выдал странное со- общение об ошибке: “слишком много открытых файлов: права доступа к файлам отрицают доступ сервера”. Что могло стать причиной такой ошибки? Какие изме- нения необходимо внести, чтобы решить проблему? 13.3. ★ Предлагают ли системы AIX загружаемые модули ядра? Как разработчик дол- жен добавить в ядро AIX поддержку новой файловой системы или новых систем- ных вызовов? Когда могут потребоваться такие функции? 13.4. ★ Вы недорого купили Ethemet-плату для портативного компьютера, которая по- зволяет подключаться к сети через параллельный порт. Какие действия необхо- димо предпринять, чтобы операционная система Linux распознала новую плату? Нужно ли встроить поддержку платы непосредственно в ядро или ее следует реа- лизовать в виде модуля? Почему? (Вопрос на засыпку: если ваша почасовая ставка составляет $80, во сколько обойдется установка этой “дешевой” платы?) 13.5. ★★ Настройте ядро с помощью команды make xconfig или make menuconfig и создайте исполняемый образ ядра. Инсталлируйте ядро и перезагрузите систему. Включите выполнение команды dmesg на этапе инициализации системы и срав- ните результаты, выдаваемые старым и новым ядрами. (Необходим доступ с пра- вами суперпользователя.)
ЧАСТЬ II Работа в сети

Глава 14 Сети TCP/IP Трудно переоценить важность сетей в современном компьютерном мире, хотя мно- гие все же пытаются это сделать. Во многих организациях — возможно, даже в большин- стве из них — компьютеры используются, в первую очередь, для работы в веб и доступа к электронной почте. По оценкам сайта internetworldstat. com, к средине 2010 года в Интернете работало более 1,5 млрд пользователей, что составляет более 21% населения Земли. В Северной Америке внедрение Интернета уже достигло 75%. TCP/IP — это сетевая система (networking system), лежащая в основе Интернета. Сис- тема TCP/IP не зависит ни от аппаратного обеспечения, ни от операционной системы, поэтому все устройства, использующие протоколы TCP/IP, могут обмениваться данны- ми (“взаимодействовать”), несмотря на различия. Система TCP/IP работает в сетях любого размера и любой топологии, независимо от того, соединены они с внешним миром или нет. В этой главе протоколы TCP/IP рассма- триваются в политическом и техническом аспектах, связанных с Интернетом, но изоли- рованные сети на уровне протоколов TCP/IP очень похожи друг на друга. 14.1. Система TCP/IP и Интернет История системы TCP/IP тесно связана с историей Интернета и уходит корнями на несколько десятилетий назад. Популярность Интернета во многом обусловлена элегант- ностью и гибкостью системы TCP/IP, а также тем, что это открытое и некоммерческое семейство протоколов. В свою очередь, широкое распространение системы TCP/IP именно в Интернете позволило этому семейству одержать верх над несколькими конку- рирующими семействами, популярными в свое время по политическим или коммерче- ским причинам.
496 Часть II. Работа в сети Прародительницей Интернета была сеть ARPANET, организованная в 1969 году Министерством обороны США. К концу 1980-х годов эта сеть перестала быть научно- исследовательской и наступила эра коммерческого Интернета. В настоящее время Ин- тернет представляет собой совокупность частных сетей, принадлежащих провайдерам интернет-услуг (ISP — internet service provider) и соединяющихся в так называемых “точ- ках обмена трафиком” (peering center). Кто сегодня управляет Интернетом Проектирование Интернета и его протоколов всегда осуществлялось на коопера- тивных и открытых началах, но его точная структура изменялась по мере того, как Ин- тернет превращался в инструмент открытого пользования и движущую силу мировой экономики. В настоящее время управление Интернетом разделено на административ- ное, техническое и политическое, но границы между этими функциями часто размыты. Основными действующими лицами в управлении Интернетом являются следующие ор- ганизации. • ICANN (Internet Corporation for Assigned Names and Numbers — Корпорация по на- значению имен и адресов в Интернете). Эта группа с наибольшим правом может быть названа ответственной за Интернет. Только она обладает всеми реальными полномочиями. Корпорация ICANN контролирует выделение адресов и доменных имен в Интернете, а также другие аспекты его деятельности, например номера про- токольных портов. Эта организация, основанная как некоммерческая корпорация, расположена в Калифорнии и действует в рамках меморандума по взаимопонима- нии с Министерством торговли США (www. icann. org). • ISOC (Internet Society — Сообщество пользователей Интернета) — открытая член- ская организация, представляющая интересы пользователей Интернета. Несмотря на то что эта организация преследует образовательные и политические цели, она широко известна как прикрытие для технического развития Интернет. В частно- сти, организация ISOC является головной организацией по отношению к проблем- ной группе проектирования Интернета (ietf. org), контролирующей всю техни- ческую работу. ISOC является международной некоммерческой организацией. Ее офисы расположены в Вашингтоне, округ Колумбия, и Женеве (www. isoc. org). • IETF (Internet Engineering Task Force — Проблемная группа проектирования Ин- тернета) — эта организация отвечает за разработку и публикацию технических стандартов Интернета, являясь открытым форумом, принять участие в котором может любой желающий (www. ietf. org). • IGF (Internet Governance Forum) — это организация, созданная Организацией Объединенных Наций относительно недавно, в 2005 году, чтобы предоставить воз- можность для проведения международных и политических дискуссий, посвящен- ных Интернету. Она проводит ежегодные конференции, но ее роль со временем постепенно возрастает, поскольку правительства разных стран пытаются устано- вить более жесткий контроль за Интернетом (intgovforum.org). Среди перечисленных организаций наибольшая ответственность лежит на ICANN: она выступает в качестве руководящего органа Интернета, исправляя ошибки, допущен- ные в прошлом, и продумывая пути дальнейшего развития Интернета с учетом потреб- ностей пользователей, правительств и бизнеса.
Глава 14. Сети TCP/IP 497 Сетевые стандарты и документация Если вы не уснули сразу после того, как прочитали название этого раздела, значит, выпили несколько чашек кофе. Тем не менее, умение разбираться в технической доку- ментации, выпускаемой руководящими органами Интернета, чрезвычайно важно для сетевых администраторов, и при этом это не так уж и скучно, как кажется на первый взгляд. Техническая деятельность сообщества пользователей Интернета находит отражение в серии документов, известных как RFC (Request For Comments — запрос коммента- риев). В формате документов RFC публикуются стандарты протоколов, предлагаемые нововведения, а также информационные бюллетени. Получая сначала статус черновых проектов (Internet Draft), после бурных дебатов в телеконференциях и на форумах IETF они либо отвергаются, либо получают официальный статус. Свое мнение по поводу предлагаемого стандарта может высказать любой участник обсуждения. Иногда доку- мент RFC представляет собой не стандартизацию протоколов Интернета, а всего лишь констатацию или объяснение некоторых аспектов современной практики. Документы RFC имеют порядковые номера. На сегодняшний день их более 5600. У каждого документа есть описательное название (например, Algorithms for Synchronizing Network Clocks — алгоритмы сетевой синхронизации часов), но, во избежание неодно- значности, на документы чаще всего ссылаются по номерам. Будучи опубликованным, документ RFC никогда не меняется. Изменения и дополнения публикуются в виде но- вых документов с собственными номерами. Обновление может либо дополнять и разъяс- нять документ RFC, либо полностью его заменять. Существует множество источников, распространяющих документы RFC, но сайт tfc-editor. org является центральным диспетчерским пунктом и всегда содержит са- мую свежую информацию. Прежде чем тратить время на чтение документа RFC, вы- ясните его статус на сайте tf c-editor. org; возможно, этот документ уже не содержит наиболее актуальную информацию. Процесс публикации стандартов Интернета подробно описан в документе RFC2026. Другой полезный метадокумент — RFC5540, 40 Years of RFCs (40 лет существования до- кументов RFC). В нем описаны культурные и технические аспекты публикации доку- ментов RFC. Пусть читателей не пугает обилие технических подробностей в документах RFC. В большинстве из них содержатся вводные описания, резюме и толкования, которые будут полезны системным администраторам. Некоторые документы специально напи- саны в виде обзора или общего введения. Чтение документов RFC — это, возможно, не самый простой способ разобраться в той или иной теме, но это авторитетный, лаконич- ный и бесплатный источник информации. Не все документы RFC написаны сухим техническим языком. Встречаются докумен- ты развлекательного содержания (часть из них опубликована первого апреля), среди ко- торых нам особенно нравятся следующие: • RFC 1149 — A Standard for the Transmission of IP Datagrams on Avian Carriers (стандарт передачи датаграмм с помощью птиц)1; • RFC 1925 — The Twelve Networking Truths (12 сетевых истин); 1 Группа энтузиастов системы Linux из города Берген в Норвегии, называющая себя BLUG (Bergen Linux User Group), действительно реализовала протокол CPIP (Carrier Pigeon Internet Pro- tocol — межсетевой протокол голубиной почты) в соответствии с документом RFC1149. Детали см. на их веб-сайте по адресу: blug.linux.no/rfcll49.
498 Часть II. Работа в сети • RFC3251 — Electricity over IP (передача электричества по протоколу IP); • RFC3514 — The Security Flag in the IPv4 Header (защитный флажок в заголовке про- токола IPv4). • RFC4041 — Requirements for Morality Section in Routing Area Drafts (моральный кодекс маршрутизатора). Помимо собственных порядковых номеров, документам RFC могут назначаться но- мера серий FYI (For Your Information — к вашему сведению), ВСР (Best Current Practi- ce — лучший существующий подход) и STD (Standard — стандарт). Перечисленные се- рии являются подмножествами серии RFC, группирующими документы по важности или назначению. Документы FYI — это вводные или информационные материалы, предназначенные для широкой аудитории. Как правило, именно с них лучше всего начинать изучать не- знакомую тему. К сожалению, эта серия в последнее время стала иссякать и сейчас со- временных документов FYI очень немного. Документы ВСР описывают рекомендуемые процедуры для администраторов веб- сайтов в Интернете. Они содержат административные предписания и представляют большую ценность для системных администраторов. Документы STD содержат описания протоколов Интернета, прошедших процедуру проверки и тестирования в IETF и формально принятых в качестве стандартов. Нумерация документов в рамках серий RFC, FYI, STD и ВСР ведется раздельно, по- этому один документ может иметь несколько номеров. Например, документ RFC1713, Tools for DNS Debugging (инструменты для отладки системы DNS) известен также под номером FYI127. 14.2. Дорожная карта сети Завершив краткий обзор, давайте подробнее рассмотрим, что собой представляют протоколы TCP/IP. TCP/IP — это семейство сетевых протоколов, ориентированных на совместную работу. В состав семейства входит несколько компонентов: • IP (Internet Protocol — межсетевой протокол) обеспечивает передачу пакетов дан- ных с одного компьютера на другой (RFC791); • ICMP (Internet Control Message Protocol — протокол управляющих сообщений в Интернете) отвечает за различные виды низкоуровневой поддержки протокола IP, включая сообщения об ошибках, вспомогательные маршрутизирующие запро- сы и отладочные сообщения (RFC792); • ARP (Address Resolution Protocol — протокол преобразования адресов) обеспечи- вает трансляцию IP-адресов в аппаратные адреса (RFC826)2; • UDP (User Datagram Protocol — протокол передачи датаграмм пользователя) обе- спечивает непроверяемую одностороннюю доставку данных (RFC768); • TCP (Transmission Control Protocol — протокол управления передачей) обеспечи- вает надежный дуплексный канал связи между процессами на двух компьютерах с возможностью управления потоками и контроля ошибок (RFC793). 2 Мы немного грешим против истины, утверждая, что протокол ARP входит в семейство TCP/IP. На самом деле он вполне может использоваться вместе с другими семействами протоколов. Просто этот протокол является неотъемлемой частью стека TCP/IP в большинстве локальных сетей.
Плава 14. Сети TCP/IP 499 Эти протоколы образуют иерархию, или стек, в котором протокол верхнего уровня использует протокол нижележащего уровня. Систему TCP/IP обычно описывают в виде пятиуровневой структуры (рис. 14.1), но реальная система TCP/IP содержит только три из этих уровней. Уровень приложений Транспортный уровень Сетевой уровень > Канальный уровень Физический уровень arp I SSH, FTP, HTTP I TCP I IP ' ARP, драйверыустройств Медный провод, оптоволокно, радиоволны .......... DNS.Hatos "гэг:::1 UDP traceroute Рис. 14.1. Семейство TCP/IP Версии IPv4 и IPv6 В течение последних трех десятилетий широкое распространение получила четвертая версия протокола TCP/IP, известная также под именем IPv4. Она использует четырех- байтовые IP-адреса. Современная версия, IPv6, расширила адресное пространство до 16 байт, а также учла опыт использования версии IPv4. В нее не были включены воз- можности протокола IPv4, которые оказались не очень нужными. Это позволило уско- рить работу протокола и облегчило его реализацию. Кроме того, версия IPv6 объединила системы безопасности и аутентификации в рамках одного базового протокола. Все современные операционные системы и многие сетевые устройства уже поддер- живают протокол IPv6. Однако в реальности степень активного использования прото- кола IPv6 остается практически нулевой.3 Опыт показывает, что администраторам луч- ше было бы отложить использование протокола IPv6 на как можно более долгий срок. В конце концов все будут вынуждены перейти на протокол IPv6, но на это потребуется еще несколько лет. В то же время этот переход не настолько далек, чтобы не учитывать его при покупке новых сетевых устройств. Приобретая новое оборудование, настаивайте на том, чтобы оно поддерживало протокол IPv6. Разработка протокола IPv6 была в большой степени мотивирована беспокойством о том, что адресное пространство протокола IPv4 практически исчерпано. Это действи- тельно так: прогнозы показывают, что современная система выделения адресов в про- токоле IPv4 примерно в 2011 году испытает коллапс. (См. сайт ipv4.potaroo.net, который обновляется ежедневно.) И все же адаптация протокола IPv6 в Интернете в ближайшее время не предвидится. Более вероятно, что организации ISP и ICANN (точнее, их филиал IANA (Internet Assigned Numbers Authority — Администрация адресного пространства Интернета)) предпримут временные меры по усилению господства протокола Iv4 в течение несколь- 3 Компания Google на конференции RIPE 57г которая проходила в октябре 2008 года, отмети- ла, что степень внедрения версии IPv6 (не возможности ее поддержки, а реального использования) равна 0,24%. Нет ни одной страны, в которой степень внедрения версии IPv6 превысила бы 0,76%.
500 Часть II. Работа в сети ких следующих лет. Мы ожидаем увеличения степени использования протокола IPv6 в Интернете, но, за исключением крупных провайдеров интернет-услуг, академических сайтов и универсальных провайдеров вроде компании Google, протокол IPv6 в ближай- шем будущем не повлияет на работу большинства системных администраторов. Дефицит адресов в рамках протокола IPv4 особенно остро ощущается за пределами США, поэтому там протокол IPv6 ожидает более теплый прием. В США резкому росту внедрения протокола IPv6 может способствовать потрясающее приложение: новое поко- ление мобильных телефонов, отображающих адрес IPv6 в телефонный номер. (Системы голосовой связи через Интернет также получат выгоду от более тесного соответствия телефонных номеров и адресов IPv6.) В книге мы сосредоточились на протоколе IPv4, поскольку именно он является основной версией протокола TCP/IP. Все, что касается версии IPv6, мы выделяем явным образом. К счастью для системных администраторов, версии IPv4 и IPv6 очень похожи. Если вы знаете протокол IPv4, то вы знаете большую часть того, что вам следует знать о протоколе IPv6. Основное различие между этими версиями заключается в том, что они используют разные схемы адресации. В версии IPv6 использовано несколько новых кон- цепций адресации и несколько новых обозначений. Вот и все. Пакеты и их инкапсуляция Система TCP/IP располагает средствами поддержки целого ряда физических сетей и транспортных систем, включая технологии Ethernet, Token Ring, MPLS (Multiprotocol Label Switching), беспроводную технологию Ethernet, а также системы с последователь- ными соединениями. Управление аппаратными устройствами осуществляется на каналь^ ном уровне архитектуры TCP/IP, а протоколам более высоких уровней неизвестно, кам" именно используются аппаратные средства. Данные передаются по сети в виде пакетов, которые имеют максимальный размер, определяемый ограничениями канального уровня. Каждый пакет состоит из заголовка и полезного содержимого. Заголовок содержит сведения о том, откуда прибыл пакет и куда он направляется. В него могут также включаться контрольные суммы, информа- ция, характерная для конкретного протокола, и другие инструкции, касающиеся обра- ботки пакета. Полезное содержимое — это данные, подлежащие пересылке. Название базового блока передачи данных зависит от уровня протокола. На каналь- ном уровне это кадр, или фрейм, в протоколе IP — пакет, а в протоколе TCP — сегмент. Мы будем придерживаться универсального термина “пакет”. Готовящийся к отправке пакет передается вниз по стеку протоколов, и каждый про- токол добавляет в него собственный заголовок. Сформированный пакет одного прото- кола становится полезным содержимым пакета, генерируемого следующим протоколом. Эта операция называется инкапсуляцией. На принимающей стороне инкапсулированные пакеты восстанавливаются в обратном порядке при прохождении вверх по стеку. Например, датаграмма (пакет UDP), передаваемая по сети Ethernet, упакована в трех различных “конвертах”. В среде Ethernet она “вкладывается” в простой физический фрейм, заголовок которого содержит сведения об аппаратных адресах отправителя и ближайшего получателя, длине фрейма и его контрольной сумме (CRC). Полезным содержимым Ethemet-фрейма является IP-пакет. Полезное содержимое IP-пакета — это UDP-пакет, и, наконец, полезное содержимое UDP-пакета состоит из собственно дан- ных, подлежащих передаче. Компоненты такого пакета изображены на рис. 14.2.
Глава 14. Сети TCP/IP 501 Заголовок Ethernet Заголовок IPv4 Заголовок UDP 8 байт Данные приложения Ethernet CRC 14 байт 20 байт 100 байт 4 байт UDP пакет (108 байт) IPv4 пакет (128 байт) Ethernet фрейм (146 байт) Рис. 14.2. Стандартный сетевой пакет4 Стандарты формирования фреймов Ethernet На канальном уровне добавляются заголовки к пакетам и вставляются разделители между ними. Заголовки содержат информацию об адресах канального уровня и кон- трольные суммы, а разделители позволяют принимающей стороне понять, где закан- чивается один пакет и начинается другой. Процесс добавления вспомогательных битов называется формированием фреймов или кадровой разбивкой. На самом деле канальный уровень разделен на две части: МАС (подуровень Media Access Control) и LLC (подуровень Link Layer Control). Подуровень MAC работает с ау- диовизуальной информацией и передает пакеты по проводам. Подуровень LLC форми- рует фреймы. В настоящее время существует единственный стандарт формирования фреймов по тех- нологии Ethernet: DIX Ethernet II. Кроме того, по историческим причинам используется еще несколько стандартов, основанных на стандарте IEEE 802.2, особенно в сетях Novell. Максимальный размер передаваемого блока Размер сетевых пакетов ограничивается как характеристиками аппаратных средств, так и требованиями протоколов. Например, объем полезного содержимого стандартного Ethemet-фрейма не может превышать 1500 байт. Предельный размер пакета устанавли- вается на канальном уровне и называется максимальной единицей передачи (Maximum Transfer Unit, MTU). Стандартные значения параметра MTU для разных видов сетей приведены в табл. 14.1. Таблица 14.1. Максимальные размеры передаваемых блоков в сетях различных типов Типсетевого соединения Ж., й s. А Ethernet FDDI Token Ring Модемное PPP-соединение 1500 байт (1492 в спецификации 802.2) 4470 байт (4352 для IP/FDDI) Конфигурируетсяа Конфигурируется, обычно 512 или 576 байт Двухточечные каналы ГВС (Т1, ТЗ) Конфигурируется, обычно 1500 или 4500 байт а Распространенные значения таковы: 552,1064,2088,4508 и 8232. Иногда выбирается значение 1500 для совме- стимости с Ethernet. 4 К примеру, в документах RFC, описывающих протоколы, часто используется термин “октет” (octet) вместо “байт” (byte).
502 Часть II. Работа в сети В семействе TCP/IP протокол IP отвечает за разбивку пакета на такие фрагменты, чтобы их размер соответствовал требованиям конкретного сетевого соединения. Если пакет проходит через несколько сетей, в одной из них параметр MTU может оказать- ся меньшим, чем в исходной сети. В этом случае маршрутизатор, пересылающий пакет в сеть с меньшим значением MTU, подвергнет пакет дальнейшей фрагментации. фрагментация “на лету” нежелательна в условиях сильной загруженности маршрути- заторов. В протоколе IPv6 эта возможность устранена. Пакеты по-прежнему могут фраг- ментироваться, но эту задачу должен выполнять вызывающий хост. Отправитель может обнаружить канал, способный пропустить пакет с наименьшим показателем MTU, установив на пакете флаг “не фрагментировать”. Если пакет до- стигнет промежуточного маршрутизатора, который не способен его пропустить, этот маршрутизатор вернет отправителю сообщение об ошибке ICMP. Пакет ICMP содержит показатель MTU сети, требующей пакеты меньшего размера, и этот показатель затем становится ориентировочным размером для пакетов, отправляемых по данному адресу. В протоколе TCP путь MTU определяется автоматически, даже в версии IPv4. Про- токол UDP такой возможности не имеет и перекладывает дополнительную работу на уровень IP. Иногда проблема фрагментации оказывается достаточно коварной. Несмотря на то что выявление пути MTU должно автоматически разрешить конфликты, иногда ад- министратор должен вмешаться. Например, в виртуальной частной сети с туннельной структурой необходимо проверять размер пакетов, проходящих через туннель. Обычно их начальный размер — 1500 байт, но когда к ним добавляется туннельный заголовок, * размер пакетов становится равным примерно 1540 байт и уже требуется фрагментация. Уменьшение максимального размера передаваемого блока позволяет избежать фрагмен- тации и повысить производительность туннельной сети. Просмотрите справочную стра- ницу команды if conf ig, чтобы узнать, как настроить параметр MTU сетевой платы. 14.3. Адресация пакетов Подобно письмам и сообщениям электронной почты, сетевые пакеты могут достичь ’ пункта назначения только при наличии правильного адреса. В системе TCP/IP исполь- зуется сочетание нескольких схем адресации. • Адреса MAC (media access control) для использования в сетевом оборудовании. • Сетевые адреса протоколов IPv4 и IPv6 для использования в программном обе- спечении. • Имена компьютеров для использования пользователями. Аппаратная адресация (МАС) Каждый сетевой интерфейс компьютера имеет один МАС-адрес канального уров- ня, который отличает его от других компьютеров в физической сети, а также один или несколько IP-адресов, идентифицирующих интерфейс в глобальной сети Интернета. Последнее утверждение стоит повторить: IP-адрес идентифицирует сетевые интерфейсы, а не машины. (Для пользователей это различие не имеет значения, но администраторы должны об этом знать.) Самый нижний уровень адресации задается сетевыми аппаратными средствами. Например, Ethemet-устройствам в процессе изготовления назначаются уникальные
Глава 14. Сети TCP/IP 503 шестибайтовые аппаратные адреса. Эти адреса традиционно записываются в виде ряда двухцифровых шестнадцатеричных байтов, разделенных двоеточиями, например 00:50:8D:9A:3B:DF. Сетевые платы Token Ring также имеют шестибайтовые адреса. В некоторых сетях с двухточечным соединением (например, в PPP-сетях) аппаратные адреса вообще не нуж- ны: адрес пункта назначения указывается непосредственно при установке соединения. Шестибайтовый Ethemet-адрес разбивается на две части: первые три байта опреде- ляют изготовителя устройства, а последние три — выступают в качестве уникального серийного номера, назначаемого изготовителем. Системные администраторы могут вы- яснить марку устройства, вызывающего проблемы в сети, поискав трехбайтовый иденти- фикатор соответствующих пакетов в таблице идентификаторов изготовителей. Текущая таблица доступна по адресу http://www.iana.org/assignments/ethernet-numbers. Трехбайтовые коды на самом деле представляют собой идентификаторы OUI (Orga- nizationally Unique Identifier — уникальный идентификатор организации), присваивае- мые организацией IEEE, поэтому их можно найти непосредственно в базе данных IEEE по адресу http://standards.ieee.org/regauth/oui. Разумеется, отношения между производителями микросхем, компонентов и систе- мы носят сложный характер, поэтому идентификатор изготовителя, закодированный в МАС-адресе, может ввести пользователя в заблуждение. Теоретически, аппаратные адреса Ethernet должны назначаться на постояйЙЙЙ основе и оставаться неизменными. К сожалению, некоторые сетевые платы допуска- ют программное задание аппаратных адресов. Это удобно при замене испорченных компьютеров или сетевых карт, МАС-адрес которых менять по тем или иным причи- нам нежелательно (например, если его фильтруют все ваши коммутаторы, если вагЙ DHCP-сервер выдает адреса на основе МАС-адресов или МАС-адрес был использоваЙ как лицензионный ключ для программного обеспечения). Фальсифицируемые МАС- адреса могут также оказаться полезными, если вам необходимо проникнуть в беспро- водную сеть, использующую механизм управления доступом на основе МАС-адресов. Однако, чтобы не усложнять ситуацию, мы рекомендуем сохранять уникальность МАС- адресов. IP-адресация На следующем, более высоком, уровне используется Интернет-адресация (чаще на- зываемая IP-адресацией). IP-адреса глобально уникальны5 и аппаратно независимы. Соответствие между IP-адресами и аппаратными адресами устанавливается на ка- нальном уровне модели TCP/IP. В сетях, поддерживающих широковещательный режим (т.е. в сетях, позволяющих адресовать пакеты “всем компьютерам данного физического сегмента”), протокол ARP обеспечивает автоматическую привязку адресов без вмеша- тельства системного администратора. В протоколе IPv6 МАС-адреса интерфейсов мож- В принципе IP-адреса идентифицируют конкретный и уникальный пункт назначения. Днако в особых случаях ситуация усложняется. Механизм NAT (Network Adrresses Translation — Реобразование сетевых адресов) использует IP-адреса интерфейсов для того, чтобы обработать с й ИК На нескольких машинах. Пространство частных IP-адресов присваивает адреса нескольким Дйтам, которые могут использовать их одновременно, поскольку они не видимы в Интернете, адресация в методе Anycast распределяет один и тот же адрес среди нескольких машин.
504 Часть II. Работа в сети но использовать как часть IP-адресов, благодаря чему преобразование IP-адресов в ап- паратные адреса становится практически автоматическим. СЭ Подробнее о протоколе ARP рассказывается в разделе 14.6. “Адресация" имен машин Поскольку IP-адреса представляют собой длинные, на первый взгляд, случайные чис- ла, запоминать их трудно. Операционные системы позволяют закреплять за IP-адресом одно или несколько текстовых имен, чтобы вместо 128.9.160.27 пользователь мог ввести “rfc-editor.org”. В системах UNIX и Linux это отображение можно осуществить с помо- щью статического файла (/etc/hosts), базы данных LDAP и, наконец, DNS (Domain Name System) — глобальной системы доменных имен. Следует помнить о том, что имя компьютера — это лишь сокращенный способ записи IP-адреса, и он относится к сете- вому интерфейсу, а не компьютеру. 03 Подробнее о глобальной системе DNS рассказывается в главе 17. Порты IP-адреса идентифицируют сетевые интерфейсы компьютера, но они недостаточно конкретны для идентификации отдельных процессов и служб, многие из которых могут активно использоваться в сети одновременно. Протоколы TCP и UDP расширяют кон- цепцию IP-адресов, вводя понятие порта. Порт представляет собой 16-разрядное число, добавляемое к IP-адресу и указывающее конкретный канал взаимодействия. Всем стан- дартным службам, в частности электронной почте, FTP и HTTP, назначаются “хорошо известные” порты, которые определены в файле /etc/services.6 Для того чтобы пре- дотвратить попытки посторонних процессов замаскироваться под стандартные службы, системы UNIX предоставляют доступ к портам с номерами до 1024 только процессам пользователя root. (Взаимодействовать с сервером через порты с небольшими номера- ми может кто угодно; ограничение распространяется лишь на программы, прослуши- вающие этот порт.) Типы адресов В протоколе IP поддерживается несколько типов адресов, некоторые из которых имеют эквиваленты на канальном уровне. • Направленные (unicast) — адреса, которые обозначают отдельный сетевой интер- фейс. • Групповые (multicast) — адреса, идентифицирующие группу узлов. • Широковещательные (broadcast) — адреса, обозначающие все узлы локальной сети. • Альтернативные (anycast) — адреса, обозначающие любой из группы узлов. Режим группового вещания используется, к примеру, в видеоконференциях, где одна и та же последовательность пакетов посылается всем участникам конференции. Прото- кол IGMP (Internet Group Management Protocol — протокол управления группами узлов Интернета) отвечает за управление совокупностями узлов, идентифицируемыми как один обобщенный адресат. 6 Полный список присвоенных портов можно найти на веб-странице iana. org/assignments/ port-numbers.
Глава 14. Сети TCP/IP 505 Групповые адреса в настоящее время в Интернете практически не используются. Тем не менее они были использованы в протоколе IPv6, в котором широковещательные адре- са, по существу, представляют собой специализированную форму групповой адресации. Альтернативные адреса обеспечивают балансирование нагрузки на канальный уро- вень сети, разрешая доставлять пакеты в ближайший из нескольких пунктов назначения в смысле сетевой маршрутизации. Можно было ожидать, что эти адреса будут напоми- нать групповые, но фактически они больше похожи на направленные адреса. Большинство деталей механизма альтернативных адресов скрыто на уровне маршру- тизации, а не на уровне протокола IP. Благодаря альтернативной адресации произошло реальное ослабление традиционных требований, чтобы IP-адреса однозначно иденти- фицировали пункт назначения. С формальной точки зрения, альтернативная реализация предназначена для протокола IPv6, но аналогичный трюк можно осуществить и в про- токоле IPv4, например, так, как это сделано для корневых серверов имен DNS. 14.4. IP-адреса За исключением групповых адресов, адреса Интернета состоят из двух частей: сетевой и машинной. Сетевая часть идентифицирует логическую сеть, к которой относится адрес, а машинная — узел этой сети. В протоколе IPv4 адреса состоят из четырех байтов, а гра- ница между сетевой и машинной частями устанавливается административно. В протоко- ле IPv6 адреса состоят из 16 байт, а сетевая и машинная части всегда состоят из 8 байт. В протоколе IPv4 адреса записываются в виде группы десятичных чисел (по одному на каждый байт), разделенных точками, например 209.85.171.147. Самый левый байт — старший; он всегда относится к сетевой части адреса. Если первым байтом адреса является число 127, то оно обозначает интерфейс обрат- ной связи (“loopback network”) — фиктивную сеть, не имеющую реального аппаратного интерфейса и состоящую из одного компьютера. Адрес 127.0.0.1 всегда ссылается на текущий компьютер. Ему соответствует символическое имя “localhost”. (Это еще одно небольшое нарушение требования уникальности IP-адресов, поскольку каждый компью- тер интерпретирует адрес 127.0.0.1 как адрес другого компьютера, хотя этим компью- тером является он сам.) Адреса в протоколе IPv6 и их текстовые эквиваленты являются немного более слож- ными. Они будут рассмотрены далее в подразделе “Адресация в протоколе IPv6”. IP-адрес и другие параметры сетевого интерфейса задаются командой if conf ig. Она описывается в разделе 14.10. Классы адресов в протоколе IPv4 Исторически IP-адреса группировались в классы, которые определялись на осно- вании первых битов самого левого байта. Классы отличались распределением байтов адреса между сетевой и машинной частями. Современные маршрутизаторы используют явные маски для задания сетевой части адреса, причем компоненты адреса могут раз- деляться не обязательно по границе байтов. Тем не менее традиционные классы все еще используются по умолчанию, если не предоставлена явная маска. Классы А, В и С обозначают обычные IP-адреса, а классы D и Е применяются при групповой адресации и в исследовательских целях. В табл. 14.2 представлены характери- стики каждого класса адресов. Сетевая часть адреса помечена буквой С, а машинная — буквой М.
506 Часть II. Работа в сети Таблица 14.2. Классы IP-адресов Класс А 1-126 С.М.М.М Самые первые сети или адреса, зарезервированные для Министерства обороны США В 128-191 С.С.М.М Крупные организации, обычно с подсетями; адреса данного класса почти полностью заняты С 192-223 С.С.С.М Небольшие организации; адреса данного класса получить легко, они выделяются целыми блоками D 224-239 — Групповые адреса; не назначаются на постоянной основе Е 240-255 — Экспериментальные адреса а Значение 0 не используется в качестве первого байта обычных IP-адресов. Значение 127 зарезервировано для адресов обратной связи. В редких случаях в состав локальной сети входит более ста компьютеров. По этой причине полезность адресов класса А или В (которые допускают наличие в одной сети, соответственно, 16777214 и 65534 узлов) весьма сомнительна. К примеру, 127 адресов класса А занимают половину доступного адресного пространства. Кто же знал, что адресное пространство протокола IPv4 станет таким ценным! Подсети Для того чтобы эффективнее использовать адреса, определенную долю машинной части адреса можно “одолжить” для расширения сетевой части, явно указав четырехбай- товую маску подсети (“subnet mask”), или сетевую маску (“netmask”), в которой едини- цы соответствуют сетевой части, а нули — машинной. Единицы должны занимать левую часть маски и следовать одна за другой без разрывов. Сетевая часть должна занимать не менее восьми битов, а машинная — не менее двух битов. Следовательно, маска подсети в соответствии с протоколом IPv6 допускает только 22 возможных значения. Например, четыре байта адреса класса В обычно интерпретируются как С.С.М.М. Следовательно, неявная маска подсети класса В в десятичной системе выглядит как 255.255.0.0. Однако адрес с маской 255.255.0.0 можно интерпретировать как С.С.С.М. ; Использование такой маски превращает одну сеть класса В в 256 разных подсетей, по- добных сетям класса С, т.е. в каждую из них может входить 254 компьютера. Маски подсети, как и любой сетевой интерфейс, задаются с помощью команды J if config. По умолчанию команда if config использует класс адреса для того, чтобы" выяснить, какие биты относятся к сетевой части. Если задается явная маска, то эта функ- ция просто отменяется. 03 Подробнее о команде if config рассказывается в разделе 14.10. Сетевые маски, не оканчивающиеся на границе байта, труднее декодировать. Они обычно записываются в виде суффикса /XX, где XX — число битов в сетевой части адре- са (длина маски). Такую запись иногда называют нотацией CIDR (Classless Inter-Do- main Routing — протокол бесклассовой междоменной маршрутизации). Например, адрес 128.138.243.0/26 обозначает первую из четырех сетей с общим компонентом адреса 128.138.243. В трех других сетях последний байт адреса равен 64, 128 и 192. Сетевая ма- ска, связанная с этими сетями, имеет вид 255.255.255.192 или OxFFFFFFCO. В двоичном представлении это 26 единиц с последующими шестью нулями (рис. 14.3).
Глава 14. Сети TCP/IP 507 Двоичная сетевая маска IP-адрес Десятичная сетевая маска Шестнадцатеричная сетевая маска 1111 11»f . till 1111 1111 1111 Рис. 14.3. Структура маски подсети в разных системах счисления В сети с маской /26 для нумерации узлов отводится шесть битов (32 — 26 = 6). Таким образом, появляется возможность задать 64 адреса (26 = 64). В действительности допуска- ется использовать лишь 62 адреса, поскольку адреса, полностью состоящие из нулей или единиц, зарезервированы (для самой сети и широковещательного режима соответственно). В нашем примере старшие два бита последнего байта адреса могут принимать значе- ния 00,01, 10и 11.Таким образом, сеть 128.138.243.0/24 может быть разделена на четыре сети /26: • 128.138.243.0/26 (0 - 00000000); • 128.138.243.64/26 (64-01000000); • 128.138.243.128/26 (128 - 10000000); • 128.138.243.192/26 (192 - 11000000). Выделенные полужирным шрифтом биты последнего байта каждого адреса относят- ся к сетевой части. Трюки и инструменты для арифметических вычислений, связанных с подсетями Манипулировать всеми этими битами в уме трудно, но есть ряд приемов, позволяю- щих упростить вычисления. Число узлов в сети и значение последнего байта сетевой ма- ски в сумме всегда дают 256. последний байт сетевой маски = 256 — размер сети Так, в рассмотренном выше случае формула даст результат 256 — 64 = 192, где 192 — последний байт маски. Другое правило гласит о том, что значение последнего байта фак- тического адреса сети (не сетевой маски) должно нацело делиться на число узлов сети. В рассматриваемом примере последние байты равны 0, 64, 128 и 192 — каждое из этих чисел делится нацело на 64.7 Имея только IP-адрес (допустим, 128.138.243.100), невозможно сказать, каким будет адрес сети и широковещательный адрес. В табл. 14.3 представлены возможные вариан- ты для масок /16 (выбирается по умолчанию для адресов класса В), /24 и /26 (наиболее приемлемая длина, если имеющееся адресное пространство невелико). Таблица 14.3. Пример расшифровки IP-адреса IP-адрес 128.138.243.100/16 255.255.0.0 128.138.0.0 128.138.255.255 128.138.243.100/24 255.255.255.0 128.138.243.0 128.138.243.255 128.138.243.100/26 255.255.255.192 128.138.243.64 128.138.243.127 7 Разумеется, нуль делится на любое число.
508 Часть IL Работа в сети Сетевой (все нули в машинной части) и широковещательный (все единицы в машин- ной части) адреса сокращают число узлов в каждой локальной сети на 2, поэтому в са- мой маленькой сети формально должно быть 4 узла: два реальных, соединенных напря- мую, и два фиктивных (сетевой и широковещательный). Для того чтобы создать такую сеть, необходимо отвести два бита под машинную часть адреса, т.е. суффикс адреса будет /30, а сетевая маска — 255.255.255.252 или OxFFFFFFFC. Но есть еще сеть с маской /31, которая трактуется как особый случай (RFC3021): у нее нет сетевого и широковещатель- ного адресов, а оба оставшихся адреса используются для идентификации узлов. Маска такой сети равна 255.255.255.254. Кришан Джодис (Krischan Jodies) написал полезную программу под названием IP Cal- culator (она доступна по адресу jodies. de/ipcalc), позволяющую выполнять арифмети- ческие операции над двоичными, шестнадцатеричными числами и масками. Программа IP Calculator делает все, что требуется пользователю при работе с сетевыми адресами и маска- ми подсети, а также широковещательными адресами и т.п. Кроме того, существует архив формата tar для версии калькулятора ipcalc, которая запускается из командной строки. ®В операционной системе Ubuntu программу ipcalc можно установить с по- мощью команды apt-get. Ниже приведен образец работы программы ipcalc (формат вывода для наглядности немного изменен). Address: 24.8.175.69 00110000.00001000.10101111.01000101 Netmask: 255.255.255.0 = 24 11111111.11111111.11111111.00000000 Wildcard: 0.0.0.255 00000000.00000000.00000000.11111111 Network: 24.8.175.0/24 00011000.00010000.10101111.00000000 (Class A) Broadcast: 24.8.175.255 00011000.00010000.10101111.11111111 HostMin: 24.8.175.1 00011000.00010000.10101111.00000001 HostMax: 24.8.175.254 00011000.00010000.10101111.11111110 Эти результаты позволяют не только просто и понятно представить адреса, но и “ко- пировать и вставлять” версии. Очень полезная программа. В операционной системе Red Hat имеется утилита, тоже называющаяся ipcalc, но она довольно неуклюжа и в большинстве случаев предполагает, что 1Р-ад- реса относятся к классу, предусмотренному по умолчанию. Если этот калькулятор вам по каким-то причинам не подойдет, можно воспользо- ваться стандартной утилитой Ьс, поскольку она может выполнять арифметические опе- рации в любой системе счисления. Установите основания систем счисления для ввода и вывода, используя директивы ibase и obase. Сначала выполните директиву obase, в противном случае ее результат будет интерпретироваться в зависимости от нового основания системы счисления, установленной директивой ibase. CIDR: протокол бесклассовой междоменной маршрутизации Как и подсети, прямым расширением которых он является, протокол CIDR основан на использовании явной маски подсети, определяющей границу между сетевой и ма- шинной частями адреса. Но, в отличие от подсетей, протокол CIDR допускает, чтобы сетевая часть была меньше, чем того требует класс адреса. Благодаря укороченной маске возникает эффект объединения нескольких сетей для облегчения маршрутизации. По этой причине протокол CIDR иногда называют протоколом формирования суперсетей.
Глава 14. Сети TCP/IP 509 Протокол CIDR упрощает информацию о маршрутизации и устанавливает иерархию в этом процессе. Несмотря на то что протокол CIDR задумывался как временная мера для облегчения маршрутизации в рамках протокола IPv6, он оказался достаточно мощ- ным средством для решения проблемы роста Интернета, возникшей в последнее деся- тилетие. Предположим, организации предоставлен блок из восьми адресов класса С, про- нумерованных последовательно от 192.144.0.0 до 192.144.7.0 (в нотации CIDR — 192.144.0.0/21). Внутри самой организации адреса могут распределяться так: • 1 сеть с длиной маски 21 — 2046 узлов, сетевая маска 255.255.224.0; • 8 сетей с длиной маски 24 — 254 узла в каждой, сетевая маска 255.255.255.0; • 16 сетей с длиной маски 25 — 126 узлов в каждой, сетевая маска 255.255.255.128; • 32 сети с длиной маски 26 — 62 узла в каждой, сетевая маска 255.255.255.192 и т.д. Ценность протокола CIDR заключается в том, что для перечисленных адресов не обязательно иметь 32, 16 или даже 8 записей в таблице маршрутизации. Ведь все они ссылаются на узлы одной и той же организации, поэтому пакеты предварительно нужно доставлять в общий приемный пункт. В таблицу маршрутизации достаточно внести за- пись 199.144.0.0/21. Протокол CIDR позволяет даже выделять фрагменты адресных про- странств классов А и В, благодаря чему увеличивается число доступных адресов. Внутри сети допускается смешение подсетей с разной длиной маски, если только они не перекрывают друг друга. Это называется формированием подсетей перемен- ного размера. Например, интернет-провайдер, которому выделена адресная область 193.144.0.0/21, может создать группу сетей /30 для коммутируемых PPP-клиентов, не- сколько сетей /24 — для крупных клиентов и ряд сетей /27 — для более мелких компаний. Все узлы конкретной сети должны конфигурироваться с помощью одной сетевой ма- ски. Нельзя для одного узла задать длину маски 24, а для другого — 25. Выделение адресов Формально назначаются лишь адреса сетей. Организации должны самостоятельно определять номера компьютеров и закреплять за ними IP-адреса. Деление на подсети также осуществляется произвольно. Организация ICANN в административном порядке делегировала полномочия по распределению адресов трем региональным организациям, которые предоставляют бло- ки адресов интернет-провайдерам в рамках своих регионов (табл. 14.4). Провайдеры, в свою очередь, выделяют адреса отдельным клиентам. Только крупные провайдеры могут напрямую посылать запросы в один из регистров, спонсируемых организацией ICAAN. Таблица 14.4. Региональные реестры IP-адресов Организация ARIN arin.net Северная часть Карибских островов APNIC apnic.net Азия и Океания, включая Австралию и Новую Зеландию AfriNIC adrinic.net Африка LACNIC lacnic.net Центральная и Южная Америка, часть Карибских островов __RIPE NCC ripe.net Европа и прилегающие регионы Делегирование полномочий от организации ICANN к региональным регистрам обе- спечивает должную агрегацию адресов в таблицах маршрутизации магистральных сетей.
510 Часть II. Работа в сети Клиенты, получившие адреса от своего провайдера, не обязаны иметь маршрутные за- писи в магистральных серверах. Достаточно одной записи, ссылающейся на провайдера. Частные адреса и система NAT Другое временное решение проблемы сокращающегося адресного пространства про- токола IPv4 заключается в использовании частных областей IP-адресов, описанных в документе RFC1918. Частные адреса используются только внутри сайта и никогда не демонстрируются в Интернете (по крайней мере, непреднамеренно). Преобразование частных адресов в адреса, выделенные интернет-провайдером, осуществляется погра- ничным маршрутизатором. Документ RFC1918 определяет, что одна сеть класса А, 16 сетей класса В и 256 сетей класса С резервируются для частного использования и никогда не выделяются глобаль- но. В табл. 14.5 показаны диапазоны частных адресов (каждый диапазон представлен в более короткой нотации протокола CIDR). Из перечисленных диапазонов организа- ции могут выбирать для себя сети нужного размера. Таблица 14.5. IP-адреса, зарезервированные для частного использования Класс ДиапазонСЮЙ А 10.0.0.0 10.255.255.255 10.0.0.0/8 В 172.16.0.0 172.31.255.255 172.16.0.0/12 С 192.168.0.0 192.168.255.255 192.168.0.0/16 Изначально идея состояла в том, чтобы узлы могли самостоятельно выбирать класс адресов из указанных возможностей, чтобы правильно определить свой размер. Однако в настоящее время протокол CIDR и подсети стали универсальным инструментом, по- этому для всех новых частных сетей целесообразнее всего использовать адреса класса А (разумеется, с подсетями). Для того чтобы узлы, использующие частные адреса, могли получать доступ в Ин- тернет, на пограничном маршрутизаторе организации должна выполняться система NAT (Network Address Translation — трансляция сетевых адресов). Эта система перехватыва- ет пакеты и заменяет в них адрес отправителя реальным внешним IP-адресом. Может также происходить замена номера исходного порта. Система хранит таблицу преобразо- ваний между внутренними и внешними адресами/портами, чтобы ответные пакеты до- ставлялись нужному адресату. Благодаря нумерации портов, появляется возможность подключить несколько исхо- дящих соединений к общему IP-адресу, чтобы внутренние узлы совместно использовали одинаковый внешний IP-адрес. Иногда в организации достаточно иметь один “настоя- щий” внешний адрес. Например, эта конфигурация по умолчанию установлена в боль- шинстве популярных маршрутизаторов, использующих кабель и модемы DSL. Узел, использующий систему NAT, запрашивает адреса у провайдера, но большин- ство адресов теперь используется для внутрисистемных привязок и не назначается от- дельным компьютерам. Если узел позднее захочет сменить провайдера, потребуется лишь изменить конфигурацию пограничного маршрутизатора и его системы NAT, но не самих компьютеров. Существует возможность заставить операционные системы UNIX или Linux выпол- нять функции NAT, хотя во многих организациях предпочитают делегировать эти обя-
Глава 14. Сети TCP/IP 511 занности маршрутизаторам или устройствам подключения к сети.8 Вопросы, связанные с конкретными поставщиками, мы обсудим в этой главе позднее. Неправильная конфигурация системы NAT может привести к тому, что пакеты с част- ными адресами начнут проникать в Интернет. Они могут достичь узла назначения, но ответные пакеты не будут получены. Организация CAIDA9, замеряющая трафик маги- стральных сетей, сообщает о том, что 0,1—0,2% пакетов, проходящих по магистрали, имеют либо частные адреса, либо неправильные контрольные суммы. На первый взгляд показатель кажется незначительным, но на самом деле это приводит к тому, что каж- дую минуту в сети циркулируют тысячи пакетов. Информацию по статистике Интернета и средствам измерения производительности глобальной сети можно получить на веб- узле www.caida.org. Одной из особенностей системы NAT является то, что узел Интернета не может на- прямую подключиться к внутренним машинам организации. Для того чтобы преодолеть это ограничение, в некоторых реализациях системы NAT разрешается создавать тунне- ли, которые поддерживают прямые соединения с выбранными узлами.10 Еще одна проблема заключается в том, что некоторые приложения встраивают IP-адреса в информационную часть пакетов. Такие приложения не могут нормально ра- ботать совместно с NAT. К ним относятся определенные протоколы маршрутизации, программы потоковой доставки данных и ряд FTP-команд. Система NAT иногда также отключает виртуальные частные сети (VPN — virtual private network). Система NAT скрывает внутреннюю структуру сети. Это может показаться преиму- ществом с точки зрения безопасности, но специалисты считают, что на самом деле си- стема NAT не обеспечивает должную безопасность и уж во всяком случае не устраняет потребность в брандмауэре. Кроме того, она препятствует попыткам оценить размеры и топологию Интернета. См. документ RFC4864, Local Network Protection for IPv6, содер- жащий полезную информацию о реальных и мнимых преимуществах системы NAT и протокола IPv4. Адресация в стандарте IPv6 В IPv6 адрес имеет длину 128 бит. Изначально столь длинные адреса вводились для того, чтобы решить проблему сокращающегося адресного пространства IPv4. Сегодня они служат также целям маршрутизации и локализации ссылок. Адреса в протоколе IPv4 никогда не были географически сгруппированы подобно тому, как это имеет место в случае телефонных номеров или почтовых индексов. Теперь, с появлением протокола CIDR, IP-адреса стали группироваться в кластеры. (Разумеется, прилагательное “географический” относится к пространству маршрутизации, а не к фи- зическим координатам.) Протокол CIDR оказался настолько удачным с технической 8 Разумеется, многие маршрутизаторы в настоящее время могут запускать встроенные ядра системы Linux. Но даже в этом случае их изначальные системы остаются более эффективными и безопасными, чем универсальные компьютеры, которые также пересылают пакеты. 9 CAIDA (Cooperative Association for Internet Data Analysis — совместная ассоциация по анали- зу данных в сети Internet) находится в Центре суперкомпьютеров, который расположен в здании Калифорнийского университета в Сан-Диего (www.caida.org). 10 Многие маршрутизаторы поддерживают также стандарты Universal Plug and Play (UPnP), про- двигаемые компанией Microsoft. Эти стандарты позволяют внутренним машинам устанавливать собственные динамические туннели NAT. В зависимости от точки зрения пользователя, это может оказаться как удачным решением, так и угрозой безопасности. При желании эту функциональную возможность маршрутизатора легко отключить.
512 Часть II. Работа в сети точки зрения, что иерархические переприсваивания сетевых адресов вошли в стандарт IPv6. Интернет-провайдер, действующий по протоколу IPv6, присваивает вам пре- фиксный адрес, который просто приписывается перед локальной частью вашего адреса, обычно перед адресом пограничного маршрутизатора. Граница между сетевой и машинной частями адреса в протоколе IPv6 зафиксирована на отметке /64, поэтому не может возникнуть никаких недоразумений, связанных с тем, насколько длинной является сетевая часть в адресе “на самом деле”. Иначе говоря, в протоколе IPv6 больше нет настоящих подсетей, хотя термин “подсеть” сохранился как синоним “локальной сети”. Несмотря на то что сетевые номера всегда имеют длину 64 бит, маршрутизаторы могут не обращать внимания на все 64 бит в процессе принятия решения. Они могут направлять пакеты на основе анализа префиксов, точно так же как это делается в протоколе CIDR. Первая схема, описанная в документе RFC2374, предусматривала четыре стандар- тизованных уровня разделения внутри сетевой части адреса в протоколе IPv6. Однако опыт эксплуатации показал, что интернет-провайдеры могут успешно управлять разде- лением свои собственных адресов по протоколу IPv4, поэтому первоначальный план в документе RFC3587 был отменен. В настоящее время интернет-провайдеры могут сво- бодно устанавливать границы между частями адресов. Идентификатор узла, состоящий из 64 бит, потенциально может быть выведен из 48-битовых адресов МАС интерфейсов аппаратного обеспечения.11 В протоколе IPv6 МАС-адреса видны на уровне протокола IP, что имеет как поло- жительные, так и отрицательные стороны. Положительный момент заключается в том, что конфигурация адресов узла может быть полностью автоматической. Отрицательный аспект состоит в том, что в первой половине МАС-адреса кодируются тип и модель се- тевой платы, что облегчает задачу хакерам. Однако разработчики стандарта IPv6 указали на то, что использование МАС-адресов не является обязательным. Они также предло- жили схемы включения случайного идентификатора в локальную часть адреса. Перечислим несколько полезных источников информации, касающейся протоко- ла IPv6. • ipv6tf. org — информационный портал, посвященный протоколу IPv6 • ipv6.org — часто задаваемые вопросы и техническая информация • www. ipv6forum. com — форум приверженцев протокола IPv6 • RFC3587 — документ IPv6 Global Unicast Address Format • RFC4291 — документ IP Version 6 Addressing Architecture Были предложены разные схемы перехода с версии IPv4 на IPv6, включая использо- вание системы NAT, чтобы прятать адреса IPv6 при передаче пакетов по туннелю через существующие сети IPv4. В настоящее время чаще всего используются туннельные си- стемы 6to4 и Teredo. Вторая система, которая была названа в честь семейства шашелей, буравящих древесину, может использоваться на устройствах, работающих под управле- нием системы NAT. 11 Точнее говоря, в средину добавляется адрес МАС с двумя байтами OxFFFE, дополненны- ми одним битом (шестым битом первого байта, считая слева и начиная с нуля); см. документ RFC4921. Стандарт, регулирующий преобразование 48-битовых адресов МАС в 64-битовые номера интернет-провайдеров, называется EUI-64.
Глава 14. Сети TCP/IP 513 14.5. Маршрутизация Маршрутизация — это процесс направления пакета по лабиринту сетей, находящих- ся между отправителем и получателем. В системе TCP/IP маршрутизация происходит примерно так, как путешественник, первый раз посетивший страну, находит нужный ему дом, задавая вопросы местным жителям. Первый человек, с которым он заговорит, возможно, укажет ему нужный город. Войдя в город, путешественник спросит другого человека, и тот расскажет, как попасть на нужную улицу. В конце концов наш путеше- ственник подойдет достаточно близко к конечному пункту своих странствий, чтобы кто- нибудь указал ему дом, который он ищет. Маршрутная информация в системе TCP/IP имеет форму правил (маршрутов), на- пример: “Для того чтобы достичь сети А, посылайте пакеты через компьютер С”. Часто существует и стандартный маршрут. В нем объясняется, что нужно делать с пакетами, предназначенными для отправки в сеть, маршрут к которой не указан явным образом. Данные маршрутизации хранятся в одной из таблиц ядра. Каждый элемент этой та- блицы содержит несколько параметров, включая сетевую маску (раньше это поле было опциональным, но теперь оно обязательно, если стандартная сетевая маска неверна). Для направления пакета по заданному адресу ядро подбирает наиболее конкретный маршрут (т.е. тот, где самая длинная маска). Если ни один из маршрутов (в том числе стандартный) не подходит, то отправителю возвращается ICMP-сообщение вида “net- work unreachable” (сеть недоступна). Слово “маршрутизация” широко употребляется в двух различных смыслах: • процедура поиска сетевого адреса в специальной таблице для передачи пакета в пункт его назначения; • процесс построения этой таблицы. Ниже мы рассмотрим, как осуществляется переадресация пакетов и как вручную доба* вить или удалить маршрут. Более сложные вопросы, связанные с работой протоколов марш- рутизации, создающих и обслуживающих маршрутные таблицы, освещаются в главе 15. Таблицы маршрутизации Таблицу маршрутизации можно просмотреть с помощью команды netstat -г. Ко- манда netstat -rn запрещает поиск доменных имен в системе DNS, вследствие чего все адреса будут представлены в числовом виде. Команда netstat подробно описыва- ется в разделе 21.5, здесь же мы дадим небольшой пример, чтобы у читателей сложилось представление о том, что такое маршруты. % netstat -rn Kernel IP routing table Destination Genmask Gateway Fl MSS Iface 132.236.227.0 255.255.255.0 132.236.227.93 U 1500 ethO default 0.0.0.0 132.236.227.1 UG 1500 ethO 132.236.212.0 255.255.255.192 132.236.212.1 U 1500 ethl 132.236.220.64 255.255.255.192 132.236.212.6 UG 1500 ethl 127.0.0.1 255.255.255.255 127.0.0.1 U 3584 lo В рассматриваемой системе есть два сетевых интерфейса: 132.236.227.93 (ethO) — в сети 132.236.227.0/24 и 132.236.212.1 (ethl) - в сети 132.236.212.0/26.
514 Часть IL Работа в сети Поле destination обычно содержит адрес сети. В поле gateway отображается адрес локального сетевого интерфейса или соседнего узла; в ядре системы Linux для вызова шлюза, установленного по умолчанию, в поле gateway может быть записан адрес О.О.О.О. Например, четвертый маршрут указывает, что для достижения сети 132.236.220.64/26 пакеты следует посылать в шлюз 132.236.212.6 через интерфейс ethl. Вторая запись со- держит описание стандартного маршрута. Пакеты, не адресованные явно ни в одну из трех указанных сетей (или самому компьютеру), будут направлены в стандартный шлюз 132.236.227.1. Компьютеры могут посылать пакеты только тем шлюзам, которые физически под- ключены к той же сети. Локальные компьютеры могут перемещать пакеты только на один шаг в направлении пункта назначения, поэтому в него бессмысленно включать информацию о шлюзах, не являющихся смежными в таблице локальной маршрутиза- ции. Каждый шлюз, через который проходит пакет, принимает следующее решение о его перемещении, анализируя собственную таблицу локальной маршрутизации.12 Вести таблицы маршрутизации можно статически, динамически или комбинирован- ным способом. Статический маршрут задается в явном виде с помощью команды route. Он должен оставаться в таблице маршрутизации в течение всего времени работы систе- мы. Во многих случаях такие маршруты задаются на этапе начальной загрузки с помо- щью одного из сценариев запуска системы. Например, команды route add -net 132.236.220.64 netmask 255.255.255.192 gw 132.236.212.6 ethl route add default gw 132.236.227.1 ethO добавляют, соответственно, четвертый и второй маршруты из числа тех, что отобра- жаются выше командой netstat -rn (первый и третий маршруты добавляются коман- дой ifconfig при конфигурировании интерфейсов ethO и ethl). Ш Полное описание команды route см. в разделе 14.10. Последний маршрут также добавляется на этапе начальной загрузки. Он определя- ет псевдоустройство, называемое интерфейсом обратной связи (loopback interface). Это устройство препятствует пакетам, которые компьютер посылает сам себе, выходить в сеть. Вместо этого они напрямую переносятся из выходной сетевой очереди ядра во входную очередь. В относительно стабильной локальной сети статическая маршрутизация является до- 1 статочно эффективным решением. Эта система проста в управлении и надежна в экс- плуатации, но требует знания системным администратором топологии сети на момент начальной загрузки, а также того, чтобы эта топология в периоды между загрузками не изменялась. Большинство компьютеров локальной сети имеет единственный выход во внешний мир, поэтому маршрутизация осуществляется очень просто: достаточно на этапе начальной загрузки добавить стандартный маршрут. Компьютер может получить стандартный марш- рут вместе со своим IP-адресом у сервера DHCP (этот протокол описан в разделе 14.7). В сетях с более сложной топологией требуется динамическая маршрутизация. Она осуществляется процессом-демоном, который ведет и модифицирует таблицу маршру- тизации. Демоны маршрутизации, “обитающие” на различных компьютерах, взаимо- действуют друг с другом с целью определения топологии сети и решения вопроса о том, как добраться до удаленных адресатов. Существует несколько таких демонов. Подробно они будут рассмотрены в главе 15. 12 Маршрутизация IP-источника является исключением из этого правила; см. раздел 14.8.
Глава 14. Сети TCP/IP 515 директивы переадресации протокола ICMP Несмотря на то что протокол IP не предусматривает средств управления маршрутной информацией, в нем имеется механизм контроля нарушений: директивы переадресации протокола ICMP. Если маршрутизатор направляет пакет компьютеру, находящемуся в той же сети, из которой этот пакет был получен, то что-то работает неправильно. Поскольку от- правитель, маршрутизатор и маршрутизатор следующего перехода находятся в одной сети, то пакет можно послать не через два перехода, а через один. Маршрутизатор делает вывод о том, что таблицы маршрутизации отправителя являются неточными или неполными. В этой ситуации маршрутизатор может уведомить отправителя о проблеме с помощью переадресующего ICMP-пакета. В таком пакете сообщается следующее: “Не нужно по- сылать мне пакеты для узла ххх; их следует адресовать узлу у у у”. Теоретически, получив директиву переадресации, отправитель может обновить свою таблицу маршрутизации, чтобы следующие пакеты, г^дназначенные данному адресату, шли по более прямому пути. На практике переадресация не подразумевает этапа аутен- тификации и поэтому не может считаться доверенной. Маршрутизатор может цроиг- норировать полученную команду перенаправить трафик в другое место, но чащ© всего системы UNIX и Linux пытаются это сделать по умолчанию. В таких ситуациях необхо- димо уточнить возможные источники команд переадресации в своей сети и отключить их, если они могут создать проблемы. ДВ Linux допустимость ICMP-директив определяется элементом adttept_ redirects файловой системы /ргос. О том, как проверять й устанавливать этот и подобные ему параметры, рассказывается в разделе 14.14. Для того чтобы отключить маршрутизацию по протоколу ICMP, в системе Solaris SOiariS следует использовать команду ndd -set /dev/ip ip ip_ignore_redirect 1. Несмотря на то что система HP-UX также использует команду ndd для управ- ления стеком протокола IP, в этой реализации протокола нет возможности игнорировать переадресацию по протоколу ICMP. Однако есть возможЙёВть удалить команды переадресации из таблицы маршрутизации через <З^Ййу, выполнив следующую команду. ndd -set /dev/ip ip__ire__redirect__interval 1000 Некоторые версии системы HP-UX позволяют задавать этот параметр равным не меньше 5 или 60 секунд (сам параметр выражается в миллисекундах), но в системе HP- UX есть возможность задавать еще меньше значения. • Для того чтобы отменить ICNP-переадресацию в системе AIX, необходимо вы- полнить команду по -р -о ipignoreredirects=l. Опция -1 делает эту за- мену постоянной; при временном тестировании эту опцию следует отключить. Более подробная информация приведена в разделе 14.15. 14.6. ARP: протокол преобразования адресов Ш Протокол ARP определен в документе RFC826. Несмотря на то что IP-адреса являются аппаратно-независимыми, для фактической передачи данных на канальном уровне должны применяться аппаратные адреса13. ARP 13 Это не касается двухточечных соединений, где получатель иногда подразумевается неявно.
516 Часть IL Работа в сети (Address Resolution Protocol — протокол преобразования адресов) определяет, какой ап- паратный адрес связан с тем или иным IP-адресом. Этот протокол можно применять в сетях любых типов, которые поддерживают широковещательный режим, но чаще всего его рассматривают в контексте сетей Ethernet. Когда компьютер А хочет послать пакет компьютеру Б, находящемуся в том же Ethemet-сегменте, он использует протокол ARP для нахождения аппаратного адреса Б. Если же компьютер Б расположен в другой сети, то компьютер А с помощью подсисте- мы маршрутизации определяет IP-адрес маршрутизатора следующего перехода, а затем с помощью протокола ARP выясняет аппаратный адрес этого маршрутизатора. Так как в ARP применяются широковещательные пакеты, которые не могут выйти за пределы локальной сети14, этот протокол позволяет находить только адреса устройств, непосред- ственно подключенных к той же сети. Каждый компьютер хранит в памяти специальную таблицу, называемую кешем ARP. Кеш содержит результаты последних ARP-запросов. В нормальных условиях многие адреса, необходимые компьютеру, выявляются вскоре после начальной загрузки, поэто- му протокол ARP мало влияет на загруженность сети. Протокол ARP функционирует путем широковещательной рассылки пакетов пример- но следующего содержания: “Знает ли кто-нибудь аппаратный адрес для 128.138.116.4?” Устройство, которое разыскивают, узнает свой IP-адрес и посылает ответ: “Да, это IP-адрес одного из моих сетевых интерфейсов, соответствующий Ethernet-адрес — 8:0:20:0:fb:6a”. Исходный запрос включает IP- и Ethernet-адрес запрашивающей стороны, благодаря чему разыскиваемое устройство может ответить, не посылая собственный ARP-запрос. Это позволяет обоим компьютерам узнать адреса друг друга за один сеанс обмена па- кетами. Другие компьютеры, “слышавшие” исходное широковещательное сообщение, посланное инициатором запроса, тоже могут записать информацию о его адресах. Команда агр изучает и обрабатывает содержимое кеша ARP. Обычно она использу- ется для добавления и удаления записей, но может также очищать всю таблицу и ото- бражать ее. В частности, команда агр -а отображает содержимое кеша. Формат вывода может варьироваться. Команда агр, как правило, применяется в целях отладки и при работе со специаль- ным оборудованием. Например, если два узла сети имеют одинаковый IP-адрес, то на одном из них запись в ARP-таблице будет правильной, а на другом — нет. С помощью команды агр можно найти узел-нарушитель. 14.7. DHCP: протокол динамического КОНФИГУРИРОВАНИЯ УЗЛОВ Ш Протокол DHCP определен в документах RFC2131 и 2132. Когда вы добавляете устройство или компьютер в сеть, то обычно получаете свой IP- адрес в локальной сети, настраиваете соответствующий маршрутизатор, заданный по умолчанию, и присоединяетесь к локальному серверу DNS. Все это за вас может сделать протокол DHCP (Dynamic Host Configuration Protocol — протокол динамического кон- фигурирования узлов). 14 Маршрутизатор можно сконфигурировать так, чтобы он пропускал широковещательные па- кеты в другие сети, но это, в принципе, неудачная идея. Необходимость пропускать широкове- щательные пакеты является признаком неблагополучия в работе сети или неудачной архитектуры сервера.
Глава 14. Сети TCP/IP 517 Протокол DHCP дает возможность клиенту взять сетевые и административные пара- метры “в аренду” у центрального сервера, отвечающего за их распространение. Принцип аренды особенно удобен для персональных компьютеров, которые выключены, когда на них никто не работает, и интернет-провайдеров, чьи клиенты подключаются по комму- тируемым линиям. К “арендуемым” параметрам относятся следующие: • IP-адреса и сетевые маски; • адреса шлюзов (стандартные маршруты); • адреса DNS-серверов; • имена компьютеров, на которых выполняется система Syslog; • адреса серверов WINS, Х-серверов шрифтов, прокси-серверов и NTP-серверов; • адреса серверов ТЕТР (для получения файла начальной загрузки) и десятки других (см. RFC2132). • Экзотические параметры редко используются на практике. Периодически клиенты должны повторно обращаться к DHCP-серверу с целью продления срока аренды. Если этого не делать, аренда рано или поздно закончится. DHCP-сервер будет тогда волен предоставить адрес (или иной арендованный параметр) другому клиенту. Срок аренды конфигурируется, но обычно он достаточно велик (дб не- скольких дней). Даже если вы хотите, чтобы каждый узел имел собственный постоянный IP-адрес, про- токол DHCP может значительно сэкономить ваши время и усилия. Когда сервер DHCP сконфигурирован и запущен, клиенты почти автоматически определяют параметры се- тевой конфигурации на этапе начальной загрузки, и никакой путаницы не возникает. Программное обеспечение DHCP Организация ISC (Internet Software Consortium — консорциум разработчиков ПЙЙ- граммного обеспечения для Интернета) поддерживаеТпре красный открытый источник информации о протоколе DHCP. В настоящее время широко используются версии паке- та IVS 2, 3 и 4, которые прекрасно выполняют основные функции. Версия 3 поддержи- вает резервное копирование серверов DHCP, а версия 4 — протокол IPv6. Сервер, кли- ент и агента ретрансляции (agent relay) можно загрузить с веб-сайта ics. org. Все основные дистрибутивы системы Linux используют ту или иную версию пакета ISC, хотя его серверную часть, возможно, придется устанавливать явно. В системе Red Hat эта серверная часть называется dhcp, в системе Ubuntu — dhcp3-server, а в системе SUSE — dhcp-server. Другие системы часто имеют собственные реализации протокола DHCP. К сожале- нию, к этой категории относятся и все экземпляры системы UNIX. Мы рекомендуем не вмешиваться в клиентскую часть протокола DHCP, поскольку эта часть кода относительно проста и поставляется заранее сконфигурированной и готовой к использованию. Изменение клиентской части протокола DHCP — непростая задача. Однако если вам необходимо запустить DHCP-сервер, мы рекомендуем использовать пакет ISC, а не пакеты конкретных поставщиков. В обычной гетерогенной среде проце- дура администрирования сильно упростится, если будет применяться единая стандарт- ная реализация протокола DHCP. Пакет ISC — это надежное, открытое решение, без проблем инсталлируемое в большинстве систем UNIX.
518 Часть II. Работа в сети В следующих подразделах мы вкратце рассмотрим особенности протокола DHCP, инсталляцию сервера ISC, реализующего этот протокол, а также конфигурирование DHCP-клиентов. Схема работы DHCP Протокол DHCP — это расширение протокола ВООТР, который был придуман для того, чтобы бездисковые UNIX-станции могли загружаться по сети. Протокол DHCP не ограничивается этими параметрами, вводя понятие “аренды”. DHCP-клиент начинает диалог с DHCP-сервером, посылая широковещательное со- общение вида “помогите мне узнать, кто я”15. Если в локальной сети есть DHCP-сервер, он договаривается с клиентом об аренде IP-адреса и других сетевых параметров (сетевая маска, адреса сервера имен и стандартного шлюза). Если же такого сервера нет, то серверы других подсетей могут получить первоначальное широковещательное сообщение через осо- бую часть программного обеспечения DHCP, которая называется агентом ретрансляции. По истечении половины срока аренды клиент должен ее продлить. Сервер обязан отслеживать адреса, предоставленные в аренду, и сохранять эту информацию при пе- резагрузке. Предполагается, что клиенты делают то же самое, хотя это не обязательно. Благодаря этому достигается максимальная стабилизация сетевой конфигурации. Тео- ретически, все программное обеспечение должно быть готово к мгновенному измене- нию сетевой конфигурации, но большая часть программного обеспечения по-прежнему необоснованно допускает, что сеть остается неизменной. Программное обеспечение DHCP, созданное организацией ISC Демон сервера ISC называется dhcpd, а его файл конфигурации — dhcpd.conf. Обычно этот файл находится в каталоге /etc или /etc/dhcp3. Формат файла конфигу- рации довольно хрупкий; стоит только пропустить двоеточие, как вы получите запутан- ное и бесполезное сообщение об ошибке. Для настройки нового DHCP-сервера необходимо также создать пустой файл базы данных. Проверьте резюме в конце справочной страницы о демоне dhcpd, чтобы опре- делить правильное место для лицензионного файла вашей системы. Обычно оно нахо- дится где-то под каталогом /var. Для заполнения файла dhcpd.conf потребуется следующая информация: • адреса подсетей, для которых демон dhcpd должен управлять IP-адресами, и диа- пазоны выделяемых адресов; • список статических адресов, которые вы хотите создать, а также аппаратные МАС- адреса получателей; • начальный и максимальный сроки аренды в секундах; • остальные параметры, которые сервер должен передавать DHCP-клиентам: сете- вая маска, стандартный маршрут, домен DNS, адреса серверов имен и т.д. На справочной странице (man page), посвященной демону dhcpd, дан обзор процес- са конфигурации. Точный синтаксис конфигурационного файла описан на справочной 15 Клиенты инициируют обмен информацией с DHCP-сервером, используя обобщенный ши- роковещательный адрес. В этот момент клиенты еще не знают маски своих подсетей и, следова- тельно, не могут использовать широковещательный адрес подсети.
Глава 14. Сети TCP/IP 519 странице файла dhcpd. conf. Кроме того, следует убедиться, что демон dhcpd автома- тически запускается на этапе начальной загрузки системы (см. главу 3). Если система не выполняет эту операцию автоматически, полезно сделать запуск демона условным, осуществляемым при наличии файла dhcpd.conf. Ниже показан пример файла dhcpd. conf, взятого из Linux-системы с двумя сетевы- ми интерфейсами: внутренним и внешним, подключенным к Интернету. На компьютере выполняется система NAT для трансляции адресов внутренней сети, которой предостав- ляются десять IP-адресов. Файл содержит пустую запись для внешнего интерфейса (обя- зательна) и запись host для одного компьютера, которому нужен фиксированный адрес. # глобальные параметры option domain-name ”synack.net”; option domain-name-servers gw.synack.net; option subnet-mask 255.255.255.0; default-lease-time 600; max-lease-time 7200; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.51 192.168.1.60; option broadcast-address 192.168.1.255; option routers gw.synack.net; } subnet 209.180.251.0 netmask 255.255.255.0 { } host gandalf { hardware ethernet 08:00:07:12:34:56; fixed-address gandalf.synack.net; } Ш Более подробная информация о системе DNS приведена в главе 17. Если вы не назначаете статические адреса, как это сделано выше, необходгйй‘&про- анализировать, как ваша DHCP-конфигурация будет взаимодействовать с СЙЪ^емой DNS. Проще всего присвоить каждому динамически выделяемому адресу обпШ имя (например, dhcpl. synack. net) и разрешить, чтобы имена отдельных компьютеров из- менялись вместе с IP-адресами. В качестве альтернативы можно сконфигурировать де- мон dhcpd так, чтобы он обновлял базу данных DNS при выделении очередного адреса. Динамические обновления — сложное решение, но оно позволяет сохранять имена ком- пьютеров неизменными. Агентом ретрансляции в протоколе DHCP, реализованном организацией ISC, яв- ляется отдельный демон dhcrelay. Это простая программа, не имеющая собственно- го файла конфигурации, хотя дистрибутивы системы Linux часто добавляют средства инсталляции, передающие соответствующие аргументы командной строки для вашего сайта. Агент dhcrelay прослушивает запросы DHCP в локальной сети и передает их на Указанные вами удаленные серверы DHCP. Это удобно и для централизации управления службами DHCP, и для облегчения резервного копирования серверов DHCP. Клиент протокола DHCP по версии организации ISC также не имеет конфигурации. Он хранит файл состояний для каждого соединения в каталогах /var/lib/dhcp или /var/lib/dhclient. Имена файлов совпадают с именами интерфейсов, которые они
520 Часть II. Работа в сети описывают. Например, файл dhclient-ethO. leases может содержать все сетевые па- раметры, которые клиент dhclient установил для интерфейса ethO. 14.8. Вопросы безопасности Теме безопасности посвящена глава 22, но ряд вопросов, касающихся IP-сетей, за- служивает отдельного упоминания. В этом разделе рассмотрим сетевые механизмы, ко- торые традиционно вызывают проблемы безопасности, и опишем пути решения этих проблем. Детали функционирования систем, приводимых в качестве примера, очень отличаются друг о друга (как и методы их изменения), поэтому они описываются в от- дельных подразделах. Перенаправление IP-пакетов Если в UNIX- или Linux-системе разрешено перенаправление IP-пакетов, то ком- пьютер может выступать в качестве маршрутизатора. Иначе говоря, он может принимать пакеты от третьей стороны, поступающие на его сетевой интерфейс, сравнивать их со шлюзом или пунктом назначения и передавать по сети. Если ваша система не имеет несколько сетевых интерфейсов и не предназначена для функционирования в роли маршрутизатора, эту функцию рекомендуется отключить. Узлы, перенаправляющие пакеты, часто оказываются вовлеченными в атаки на системы безопасности, будучи вынужденными выдавать внешние пакеты за свои собственные. Эта уловка позволяет пакетам злоумышленников обходить сетевые сканеры и фильтры. Лучше всего, чтобы узел использовал несколько сетевых интерфейсов для своего соб- ственного трафика и не пересылал посторонние пакеты. Директивы переадресации протокола ICMP С помощью переадресующих ICMP-пакетов можно злонамеренно менять направле- ние трафика и редактировать таблицы маршрутизации. Большинство операционных си- стем по умолчанию принимает эти пакеты и следует содержащимся в них инструкциям. Но, согласитесь, вряд ли можно назвать приемлемой ситуацию, когда на несколько ча- сов весь трафик организации перенаправляется конкуренту, особенно если в это время выполняется резервное копирование. Мы рекомендуем так конфигурировать маршрути- заторы (или системы, играющие роль маршрутизаторов), чтобы переадресующие ICMP- пакеты игнорировались и, возможно, фиксировались в журнальном файле. Маршрутизация "от источника” Механизм маршрутизации “от источника” в протоколе IP позволяет отправителю явно указать последовательность шлюзов, через которые должен пройти пакет на пути к получателю. При этом отключается алгоритм поиска следующего перехода, выполняе- мый на каждом шлюзе для определения того, куда нужно послать пакет. Маршрутизация “от источника” была частью исходной спецификации протокола IP и служила для целей тестирования. Но она создает проблему с точки зрения безо- пасности, ведь пакеты часто фильтруются в зависимости от того, откуда они прибыли. Злоумышленник может так подобрать маршрут, что пакет будет казаться прибывшим из внутренней сети, а не из Интернета, поэтому брандмауэр его пропустит. Мы рекоменду- ем не принимать и не перенаправлять доставленные подобным образом пакеты.
Глава 14. Сети TCP/IP 521 Широковещательные ICMP-пакеты и другие виды направленных широковещательных сообщений Пакеты команды ping, несущие в себе широковещательный адрес сети (а не кон- кретного узла), обычно доставляются всем узлам сети. Такие пакеты применяются в ата- ках типа “отказ от обслуживания”, например в так называемых атаках “smurf” (по на- званию программы, в которой они впервые были применены). Широковещательные ICMP-пакеты являются “направленными” в том смысле, что они посылаются по широковещательному адресу конкретной удаленной сети. Стандартные подходы к обработке таких пакетов постепенно меняются. Например, в операционной системе Cisco IOS 11.x и более ранних версий по умолчанию осущест- влялась переадресация направленных широковещательных пакетов, но в версиях 12.0 и выше этого уже нет. Обычно можно настроить стек TCP/IP так, чтобы широковеща- тельные пакеты, приходящие из других сетей, игнорировались, но, поскольку это нужно сделать для каждого сетевого интерфейса, подобная задача является весьма нетривиаль- ной в крупной организации. Подмена IP-адресов Исходный адрес IP-пакета обычно заполняется функциями сетевых библиотек и пред- ставляет собой адрес узла, с которого был отправлен пакет. Но если программа, создающая пакет, работает с низкоуровневым IP-сокетом, она может подставить любой исхфЙйяй адрес, какой пожелает. Это называется подменой IP-адресов и обычно ассоцив^&тся с попытками взлома сети. В этой схеме жертвой часто становится компьютер, идйнти- фицируемый по поддельному IP-адресу (если он действительно существует). Сообщения об ошибках и ответные пакеты могут переполнить и вывести из строя сеть жертвы. Поддельные IP-адреса следует запрещать на пограничном маршрутизаторе, блокируя отправляемые пакеты, исходные адреса которых не находятся в подконтрольном диапа- зоне. Это особенно важно в университетских сетях, где студенты любят эксперименти- ровать и часто подобным образом срывают свою злость. В то же время, если в локальной сети используются адреса из частного диапазона, то фильтрации могут подвергаться пакеты с частными адресами, пытающиеся “проско- чить” в Интернет. Ответ на такие пакеты никогда не будет получен из-за отсутствия со- ответствующих маршрутов в магистральной сети. Их появление свидетельствует о том, что в системе имеется внутренняя ошибка конфигурации. Нужно также защищаться от хакеров, подделывающих исходные адреса внешних па- кетов, вследствие чего брандмауэр начинает считать, будто они поступили из локальной сети. Помочь этому может эвристический метод, названный как “одноадресная транс- ляция по обратному пути ” (unicast reverse path forwarding — uRPF). В этом случае IP- шлюзы будут отвергать все пакеты, удовлетворяющие следующему условию: интерфейс, через который пришел пакет, не совпадает с тем интерфейсом, через который пакет уй- дет, если его исходный адрес будет равен целевому адресу. Для проверки источника се- тевых пакетов этот метод использует обычную таблицу IP-маршрутизации. Метод uRPF применяется не только в специализированных маршрутизаторах, но и в ядре системы Linux, в которой этот режим включен по умолчанию. Если ваш сайт имеет несколько выходов в Интернет, целесообразно разделить внеш- ние маршруты на исходящие и входящие. В этом случае следует отключить режим uRPF, чтобы протокол маршрутизации работал правильно. Если же выход в Интернет только один, безопаснее включить режим uRF.
522 Часть II. Работа в сети Встроенные брандмауэры Как правило, соединение вашей локальной сети с внешним миром и управление тра- фиком в соответствии с правилами сайта, осуществляют сетевые фильтры пакетов или брандмауэры (firewalls). К сожалению, компания Microsoft извратила представление о том, как должен работать брандмауэр, на примере своих систем Windows, печально из- вестных своей уязвимостью. Несколько последних выпусков системы Windows содержа- ли свои собственные брандмауэры и “громко возмущались”, когда пользователь пытал- ся их отключить. Все системы, которые мы используем в качестве примеров, содержат программное обеспечение для фильтрации пакетов, но отсюда не следует, что каждой UNIX- или Linux-машине нужен отдельный брандмауэр. Это не так. Механизмы фильтрации паке- тов, встроенные в эти системы, позволяют этим машинам выполнять функции сетевых шлюзов. Однако мы не рекомендуем использовать рабочую станцию как брандмауэр. Даже самая совершенная операционная система слишком сложна, чтобы быть надежной. Специальное программное обеспечение более предсказуемое и более надежное, даже если оно тайно использует систему Linux. Даже сложное программное обеспечение, предлагаемое, например, компанией Check Point (чьи программы выполняются на узлах под управлением операционных систем UNIX, Linux и Windows), уступает в надежности межсетевым экранам серии Adaptive Security Appliance компании Cisco, хотя имеет почти такую же цену! Более подробное обсуждение брандмауэров содержится в разделе 22.11. Виртуальные частные сети Многим организациям, имеющим офисы в различных частях света, хотелось бы, что- бы все эти офисы были соединены одной большой частной сетью. К сожалению, стои- мость аренды трансконтинентальных и даже транснациональных линий связи делает это нереальным. Таким организациям приходится использовать Интернет в качестве “част- ного” канала, организуя серию защищенных, зашифрованных “туннелей” между офиса- ми. Сетевые конгломераты подобного рода называются виртуальными частными сетями (virtual private network — VPN). Возможности виртуальных частных сетей необходимы также сотрудникам, которые должны соединяться с офисом из дома или находятся в поездке. Система VPN не реша- ет всех вопросов, связанных с безопасностью и данным специальным соединением, но во многих отношениях она вполне безопасна. СЗ О протоколе IPsec рассказывается в разделе 22.14. В ряде частных сетей используется протокол IPsec, который в 1998 году был стандар- тизирован организацией IETF в качестве низкоуровневого приложения к протоколу IP. В других сетях, таких как OpenVPN, система безопасности VPN реализуется на основе протокола TCP с помощью криптографического протокола Transport Layer Security (TSL), который ранее был известен под названием Secure Sockets Layer (SSL). Протокол TSL ожидает своей очереди на стандартизацию в организации IETF, хотя он все еще не при- нят окончательно. Существует масса запатентованных реализаций систем VPN. Эти системы не взаимо- действуют ни друг с другом, ни со стандартизованными системами VPN, но это нельзя считать недостатком, если все конечные точки сети находятся под контролем.
Глава 14. Сети TCP/IP 523 С этой точки зрения системы VPN, основанные на протоколе TLS, являются лидера- ми. Они также безопасны, как и протокол IPsec, но намного проще. Свободная реализа- ция в виде OpenVN также не наносит никакого вреда. (К сожалению, эта система пока не работает под управлением операционных систем HP-UX и AIX.) Для поддержки пользователей, работающих дома или в поездке, стало общеприня- тым использование небольшого компонента Java или ActiveX, загружаемого через их веб- браузеры. Эти компоненты устанавливают соединение VPN с сетью предприятия. Этот механизм удобен для пользователей, но следует учесть, что браузеры сильно отличаются друг от друга: некоторые из них реализуют службу VPN с помощью псевдосетевого ин- терфейса, а другие используют только специальные порты. Впрочем, веб-браузеры по- следней категории намного малочисленнее, чем знаменитые веб-прокси. Пожалуйста, проверьте, что вы правильно понимаете технологию, на которо>осно- ваны применяемые решения, и не ожидайте невозможного. Истинная служба VPN (т.е. полноценное IP-соединение через сетевой интерфейс) требует наличия административ- ных привилегий и инсталляции программного обеспечения на клиентской машине, не- зависимо от того, какая операционная система на ней установлена: Windows или UNIX. Кроме того, следует проверить совместимость браузера, поскольку механизм, применяем мый при реализации систем VPN с помощью одного браузера, часто не поддерживается другим. 14.9. РРР: протокол двухточечного соединения Протокол РРР определен в документе RFC 1331. PPP (Point-to-Point Protocol — протокол двухточечного соединения) представляет базовый канал связи в виде интерфейса виртуальной сети. Однако поскольку базовый канал может не иметь свойств реальной сети, связь ограничена двумя узлами, располо- женными на концах соединения, т.е. виртуальная сеть состоит из двух узлов. Протокол РРР по-разному используется как в самых медленных, так и в самых быстрых IP- соединениях, но по разным причинам. В асинхронной форме протокол РРР широко известен как протокол, обеспечиваю- щий выход в Интернет по телефонным и последовательным каналам. Эти каналы не предназначены для работы с пакетами, поэтому за кодирование и декодирование сете- вых пакетов, передаваемых в поток однородных данных, отвечает драйвер РРР. Он до- бавляет к пакетам заголовки канального уровня и маркеры-разграничители. В синхронной форме протокол РРР представляет собой протокол инкапсуляции пакетов, используемый в высокоскоростных соединениях, на обоих концах которых установлены мощные маршрутизаторы. Протокол РРР широко применяется для реали- зации DSL и кабельных модемов при оказании услуг по широкополосному доступу в Интернет. Во втором случае протокол РРР не только превращает базовую сетевую си- стему (например, ATM (Asynchronous Transfer Mode — асинхронный способ передачи Данных) в технологии DSL (Digital Subscriber Line — цифровая абонентская линия)) в форму, подходящую для работы с протоколами IP, но и осуществляет аутентификацию и управлением доступом в рамках самого соединения. Неким сюрреалистическим обра- зом протокол РРР позволяет реализовать семантику, подобную технологии Ethernet, на основе реальной технологии Ethernet. Эта конфигурация известна под названием “РРР over Ethernet” или РРРоЕ. Поскольку протокол РРР был разработан группой, он представляет собой протокол инкапсуляции “всего на свете и кухонной мойки”. Помимо спецификации установки,
524 Часть II. Работа в сети наладки и демонтажа соединения, протокол РРР осуществляет проверку ошибок, аутен- тификацию, шифрование и сжатие. Эти функциональные возможности позволяют адап- тировать его к любым ситуациям. Протокол РРР, реализующий сетевые технологии на основе телефонных каналов, когда-то представлял большой интерес для системных администраторов, работающих с операционными системами UNIX или Linux, но быстрое распространение широко- полосных сетей сделало телефонные конфигурации практически ненужными. В то же время протокол РРР был широко внедрен в разнообразные специальные сетевые устройства. В настоящее время главной областью применения протокола РРР является обеспечение соединений с помощью сотовых модемов. 14.10. Основы КОНФИГУРИРОВАНИЯ СЕТИ Процесс подключения нового компьютера к существующей локальной сети состоит всего из нескольких этапов, но каждая система делает это по-своему. Системы обычно предоставляют графический пользовательский интерфейс, позволяющий настроить ба- зовую сетевую конфигурацию, но в более сложных (или автоматизированных) сценари- ях инсталляции может понадобиться отредактировать файл конфигурации вручную. Прежде чем подключать компьютер к сети, где есть выход в Интернет, его нужно ос- настить средствами защиты (см. главу 22), чтобы ненароком не привлечь в локальную сеть хакеров. Основные этапы подключения компьютера. • Назначение компьютеру уникального IP-адреса и сетевого имени • Настройка компьютера на конфигурирование своих сетевых интерфейсов в про- цессе начальной загрузки • Задание стандартного маршрута и, возможно, других параметров маршрутизации • Настройка DNS-сервера, чтобы к компьютеру можно было получать доступ через Интернет Если в сети используется сервер DHCP (Dynamic Host Configuration Protocol — про- токол динамического конфигурирования узлов), он возьмет на себя перечисленные выше обязанности. Инсталляция новой операционной системы обычно настраивает свою конфигурацию через протокол DHCP, поэтому новые машины могут вообще не по- требовать определения сетевой конфигурации. Общая информация о протоколе DHCP приведена в разделе 14.7. После внесения любого изменения, которое может повлиять на загрузку операци- онной системы, следует выполнить ее перезагрузку, чтобы проверить, что машина была подключена правильно. Через полгода, когда произойдет сбой питания и машина от- кажется загрузиться, будет сложно вспомнить, какие изменения вызвали эти проблемы (см. также главу 21). Процесс проектирования и инсталляции физической сети описан в главе 16. Если вы имеете дело с существующей сетью и в общих чертах знаете, как она организована, то, наверное, читать о физических аспектах сетей имеет смысл только в том случае, когда планируется расширение действующей сети. В этом разделе мы рассмотрим разные команды и проблемы, связанные с ручной на- стройкой конфигурации сети. Этого вполне достаточно для применения к любой версии систем UNIX или Linux. В разделах, посвященных конкретным версиям операционных
Глава 14. Сети TCP/IP 525 систем, мы обсудим особенности, которые отличают эти системы от систем UNIX и Linux и друг от друга. Просматривая базовую конфигурацию сети любой машины, полезно протестировать соединение с помощью базовых инструментов, таких как утилиты ping и tUbuntuoute. Эти инструменты описаны в главе 21 (более подробная информация приведена в раз- деле 21.2). Присвоение сетевых имен и IP-адресов Существует множество теорий о том, как лучше всего определить соответствие между именами компьютеров и IP-адресами в локальной сети: с помощью файла hosts, про- токола LDAP, системы DNS или комбинации этих средств. С одной стороны, возни- кают конфликтующие цели, такие как возможность масштабирования, согласованность и удобство эксплуатации, а с другой — системы, достаточно гибкие, чтобы позволить загрузку и функционирование компьютеров, когда не все службы доступны. Управление этими факторами описывается в разделе 19.5. CQ Система DNS описывается в главе 17. Еще один важный аспект, который следует учитывать, — возможность изменения адресов в будущем. Если вы не используете частные адреса RFC 1918 (см. раздед/Й.4), то ваши IP-адреса могут быть изменены при переключении на нового интернет- провайдера. Это довольно неприятная процедура, если администратор должен Лично посетить каждый компьютер и вручную сконфигурировать его. Чтобы не усложнять себе жизнь, указывайте в конфигурационных файлах сетевые имена, а привязки к IP-адресам храните только в базе данных DNS и файлах конфигурации DHCP. Использование файла /etc/hosts — старейший и простейший способ преобразова- ния сетевых имен в IP-адреса. Каждая строка файла начинается с IP-адреса и содержит различные символьные имена, под которыми известен адрес. Ниже показан пример со- держимого файла /etc/hosts для узла lollipop. 127.0.0.1 192.108.21.48 192.108.21.254 192.108.21.1 192.225.33.5 localhost lollipop.xor.com lollipop loghost chimchim-gw.xor.com chimchim-gw ns.xor.com ns licenses.xor.com license-server Минимальный вариант этого файла должен содержать первые две строки. Чаще все- го в первой записи файла определяется узел localhost. Кроме того, в этом файле могут быть записаны 1Ру6-адреса. Поскольку файл /etc/hosts содержит лишь локальные адреса привязки и должен находиться на каждой клиентской системе, лучше всего зарезервировать его для ото- бражений, требующихся при загрузке (т.е. для адресов самого узла и маршрутизатора, заданного по умолчанию, а также для имен серверов). Для поиска остальных локальных и глобальных адресов лучше использовать систему DNS или протокол LDAP. Иногда в файле /etc/hosts хранятся записи, о которых не следует “знать” другим компьютерам и которых нет в DNS.16 Команда hostname назначает компьютеру сетевое имя. Она обычно вызывается на этапе начальной загрузки из сценариев запуска системы, которые запрашивают назнача- емое имя из конфигурационного файла. (Естественно, все поставщики систем называют 16 Для этой цели можно также использовать разделенную конфигурацию системы DNS (см. раз- дел 17.9).
526 Часть II. Работа в сети этот файл по-разному. Информация о конкретных системах приведена в разделе 14.11.) В большинстве современных систем компьютеру назначается полностью определен- ное доменное имя, т.е. оно включает как имя узла, так и имя домена DNS, например anchor.cs.Colorado.edu. СЭ Более подробная информация о протоколе LDAP приведена в разделе 19.3. В небольшой организации вполне можно выделять IP-адреса и сетевые имена вруч- ную. Когда же в организации множество сетей и разнородных административных групп, лучше придерживаться принципа централизации. Об уникальности динамически назна- чаемых сетевых параметров заботится сервер DHCP. В некоторых организациях сетевы- ми именами и IP-адресами управляют с помощью баз данных LDAP. Команда ifconfig: конфигурирование сетевых интерфейсов Команда ifconfig используется для подключения и отключения сетевого интер- фейса, а также задания его IP-адреса, маски подсети, других опций и параметров. Она обычно выполняется на этапе начальной загрузки. Аргументы командной строки берут- ся из конфигурационного файла, но могут применяться и для внесения изменений в ра- ботающую систему. Будьте осторожны при модификации удаленной системы, так как не всегда есть возможность оперативно исправить ошибки. В большинстве случаев команда ifconfig имеет следующий формат. ifconfig интерфейс [семейство] адрес опции .. . Например, команда ifconfig ethO 128.138.240.1 netmask 255.255.255.0 up задает 1Ру5-адрес и сетевую маску, связанную с интерфейсом ethO, и приводит интер- фейс в состояние готовности. Параметр интерфейс обозначает аппаратный интерфейс, к которому применяется команда. Обычно он представляет собой двух- или трехсимвольное имя, за которым следует число, но в системе Solaris этот параметр может быть длиннее. Наиболее распро- страненные имена — ieO, 1е0, lei, InO, enO, weO, qeO, nmeO, ethO и lanO. В системе Linux интерфейс обратной связи называется 1о, а в системах Solaris, HP-АХ и AIX — 1о0. В большинстве систем команда ifconfig -а перечисляет сетевые интерфейсы си- стемы и их текущие установки. В системе HP-UX для этой цели используется команда netstat -i. В системе Solaris необходимо сначала “присоединить” сетевые интерфейсы soiaris с помощью команды ifconfig интерфейс plumb и лишь затем настраивать конфигурации и выводить на экран с помощью команды ifgonf ig -а. Параметр семейство сообщает команде ifconfig, какой именно протокол (“семей- ство адресов”) вы хотите конфигурировать. Вы можете установить несколько протоко- лов для одного интерфейса и использовать их одновременно, но конфигурировать их необходимо по отдельности. Основными опциями являются inet для протокола IPv4 и inet6 — для протокола IPv6. По умолчанию используется параметр inet. Система Linux поддерживает также множество унаследованных протоколов, таких как AppleTalk и NoveU IPX. Параметр адрес задает IP-адрес интерфейса. Имя узла также допускается в качестве адресного параметра, но на этапе загрузки по имени узла должен определяться его адрес.
Глава 14. Сети TCP/IP 527 Для основного машинного интерфейса это значит, что имя узла должно находиться в локальном файле hosts, поскольку другие методы разрешения имен зависят от инициа- лизированной сети. Ключевое слово up указывает на активизацию интерфейса, а ключевое слово down — на его отключение. Когда команда if conf ig назначает интерфейсу IP-адрес, как в опи- санном выше примере, ключевое слово up подразумевается неявно и может быть опущено. Команда if conf ig понимает множество опций. Мы рассмотрим лишь самые основ- ные. Как всегда, детали, касающиеся конкретной системы, можно узнать на страницах интерактивного руководства. Все опции имеют символические имена. Некоторые опции требуют аргументов, которые должны следовать сразу за названием опции через пробел. Опция netmask задает маску подсети для данного интерфейса. Эта опция обязатель- на, если подсеть формируется не на основании класса адреса (А, В или С). Маску можно указывать в точечной нотации либо в виде четырехбайтового шестнадцатеричного чис- ла, начинающегося с префикса Ох. В любом случае единичные биты являются частью номера сети, а нулевые биты — частью номера узла. Опция broadcast задает широковещательный IP-адрес интерфейса в шестнадцате- ричной или точечной записи. По умолчанию в широковещательном адресе все биты ма- шинной части равны единице. В приведенном выше примере использования команды ifconfig автоматически конфигурируется широковещательный адрес 192.168.1.255. В качестве широковещательного адреса можно использовать любой IP-адрес, допу- стимый в сети, к которой подключен компьютер. В некоторых организациях широкове- щательный адрес специально выбран нестандартным для предотвращения сетевых ат$^ основанных на широковещательной команде ping. Однако это рискованно и, вероятно, излишне. Сбой при конфигурации каждого широковещательного адреса компьютера может вызвать широковещательный шторм, в ходе которого пакеты будут блуждать от машины к машине, пока не будет исчерпано время TTL (Time to live — время жизни Па- кета данных в протоколе IP. — Примеч. ред.)17 Лучший способ избежать проблем с широковещательными запросами состоит в том, чтобы запретить пограничному маршрутизатору перенаправлять их, а отдельным узлам — отвечать на них. В главе 22 будет рассказано о том, как реализовать подобные ограничения. Система Solaris интегрирует команду ifconfig с клиентским демоном про- soiaris токола DHCP. Команда ifconfig интерфейс dhcp конфигурирует именован- ный интерфейс с помощью параметров, арендованных у локального DHCP- сервера, затем запускает программу dhcpagent, чтобы управлять этими параметрами в течение долгого времени. Другие системы используют команду ifconfig независимо от протокола DHCP, при этом программное обеспече- ние DHCP функционирует на отдельном уровне. 17 Широковещательный шторм (broadcast storm) возникает из-за того, что для транспорта паке- тов должен использоваться один и тот же широковещательный адрес, независимо от того, какой адрес установлен. Например, машина X считает, что широковещательный адрес равен А1, а маши- на Y считает, что он равен А2. Если машина X посылает пакет по адресу А1, то машина Y получит пакет (поскольку адрес назначения на уровне соединения — это широковещательный адрес), затем Увидит, что этот пакет предназначен ни ей, ни широковещательному адресу (поскольку машина Y полагает, что широковещательный адрес равен А2), и может возвратить этот пакет обратно в сеть. Если обе машины находятся в состоянии машины Y, то пакет будет циркулировать в сети, пока не закончится его время жизни. Широковещательные штормы могут разрушить полосу пропускания, особенно в больших коммутируемых сетях.
528 Часть II. Работа в сети Кроме того, с помощью команды if conf ig интерфейс можно получить конфигура- цию отдельного интерфейса. solaris$ ifconfig elOOOgO elOOOgO: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.10.10 netmask ffffffOO broadcast 192.168.10.255 redhat$ ifconfig elOOOgO ethO Link encap:Ethernet HWaddr 00:02:B3:19:C8:86 inet addr:192.168.1.13 Beast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric:1 RX packets:206983 errors:0 dropped:0 overruns:0 frame:0 TX packets:218292 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:? Base address:Oxef00 Отсутствие коллизий в интерфейсе Ethernet во втором примере может указывать на слабо загруженную сеть или, что более вероятно, на коммутируемую сеть. В сети обще- го доступа (организованной с помощью концентраторов, а не коммутаторов) этот по- казатель должен быть ниже уровня 5% от числа отправленных пакетов. Большое число коллизий свидетельствует о загруженности сети, которую, возможно, требуется разбить на подсети или перевести на коммутируемую инфраструктуру. Теперь, когда мы рассмотрели процедуру ручного конфигурирования сетевого ин- терфейса, осталось выяснить, как задавать параметры команды ifconfig на этапе на- чальной загрузки системы. Кроме того, требуется убедиться в том, что новые значения введены правильно. Для этого необходимо отредактировать один или несколько конфи- гурационных файлов. Информация, касающаяся конкретных систем, приведена далее в этой главе. И еще одно замечание по поводу команды ifconfig: вы можете назначать интерфей- су несколько адресов, используя “интерфейсы виртуальной сети” или “1Р-псевдонимы” (IP-aliases). Администраторы могут делать это для того, чтобы позволить одной машине служить хостом для нескольких веб-сайтов (см. раздел 23.3). Параметры сетевого оборудования Довольно часто сетевое устройство имеет настраиваемые параметры, зависящие от типа передающей среды. Чрезвычайно распространенный пример — современные платы Ethernet, которые могут поддерживать скорость передачи 10, 100, 1000 и даже 10000 Мбит/с как в полудуплексном, так и в дуплексном режимах. Большинство уст- ройств по умолчанию находится в режиме автоматического согласования, когда обе сто- роны — сетевая плата и вышестоящее устройство (обычно порт коммутатора) — пыта- ются угадать параметры друг друга. По историческим причинам, процедура автоматического согласования была разра- ботана так, что она напоминает попытку вставить ключ в замочную скважину с завя- занными глазами. Следствием неудачного согласования является высокий коэффициент потери пакетов (особенно больших пакетов). Если в сети начинают происходить загадочные потери пакетов, в первую очередь от- ключите везде режим автоматического согласования. Зафиксируйте скорость и режимы работы сетевых интерфейсов как на серверах, так и на портах коммутатора, к которым они подключены. Автоматическое согласование удобно в динамических сетях организа- ций, где многие сотрудники имеют портативные компьютеры, и совершенно не нужно для статически подключенных компьютеров.
Глава 14. Сети TCP/IP 529 Точный метод, с помощью которого задаются параметры автоматического согласова- ния, меняется от системы к системе. Обсуждение этих вопросов мы начнем в разделе 14.11. Команда route: конфигурирование статических маршрутов Команда route определяет статические маршруты — явно заданные элементы табли- цы маршрутизации, которые обычно не меняются даже в тех случаях, когда запускается демон маршрутизации. При подключении нового компьютера к локальной сети доста- точно указать стандартный маршрут. Маршрутизация рассматривается нами в этой главе и следующей. И хотя информа- ция по основам маршрутизации и команде route приведена здесь, полезно прочитать также несколько первых разделов главы 15. Маршрутизация осуществляется на сетевом уровне. Когда приходит пакет, предназна- ченный для другого узла, его целевой IP-адрес сравнивается с записями в таблице маршру- тизации ядра. При совпадении (хотя бы частичном) с каким-нибудь маршрутом в таблице пакет направляется по IP-адресу следующего шлюза, связанного с данным маршрутом. Но есть два особых случая. Во-первых, пакет может быть адресован компьютеру, включенному в ту же сеть, что и узел-отправитель. В этом случае адрес следующего шлю- за соответствует одному из интерфейсов локального компьютера, и пакет посылает- ся прямо в пункт назначения. Маршруты такого типа добавляются командой ifconfig при конфигурировании интерфейса. Во-вторых, может вообще не оказаться маршрута, совпадающего с адресом пункта назначения. В этом случае применяется маршрут по умолчанию, если таковой имеется, иначе отправителю посылается ICMP-сообщение “network unreachable” (сеть недоступ- на) или “host unreachable” (узел недоступен). Многие локальные сети имеют единственный выход во внешний мир, поэтому им требуется только один маршрут, указывающий на этот выход. В магистральной сети Ин- тернета нет стандартных маршрутов — это конец пути. Каждая команда route добавляет или удаляет один маршрут. К сожалению, команда route — это одна из немногих команд системы UNIX, которые одинаково работают во всех системах, но в каждой из них имеют свой синтаксис. Прототип команды route вы- глядит следующим образом. # route add -net 192.168.45.128/25 zulu-gw.atrust.net Эта команда добавляет маршрут в сеть 192.168.45.128/25 через шлюз маршрутизато- ра zulu-gw. atrust. net, который должен быть либо соседним узлом, либо одним из локальных интерфейсов узла. (Система Linux требует указывать имя gw перед адресом шлюза.) Естественно, маршрутизатор должен уметь преобразовывать имя zulu-gw. atrust. net в IP-адрес. Если ваш DNS-сервер находится на другой стороне шлюза, ис- пользуйте числовой 1Р-адрес! Л Система Linux в качестве пункта назначения для маршрута допускает исполь- зование имени интерфейса (например, ethO). Это эквивалентно указанию пер- вичного IP-адреса интерфейса в качестве адреса шлюза. Иначе говоря, 1-стек пытается осуществить непосредственную доставку на этот интерфейс, а не перенаправлять пакет на отдельный шлюз. Адреса шлюзов на этом маршруте в результатах работы команды netstat -г выглядят как О.О.О.О. Для того чтобы увидеть, где именно проходит маршрут, необходимо поискать в столбце Iface имя интерфейса.
530 Часть II. Работа в сети Сети назначения традиционно задаются отдельными IP-адресами и сетевыми ма- сками, но в настоящее время все версии команды route, за исключением ее версии в системе HP-UX, понимают обозначения CIDR (например, 128.138.176.0/20). Система обозначений CIDR яснее, и пользователю остается лишь побеспокоиться о некоторых вопросах синтаксиса, зависящего от системы. Даже система Linux допускает обозначе- ния CIDR, хотя в справочной системе на странице, посвященной команде route, об этом ничего не сказано. В системе Solaris есть остроумная опция -р для команды route, которая позво- soians ляет сохранить изменения даже после перезагрузки. Кроме таблицы маршру- тизации, принадлежащей ядру, изменения записываются в файл /etc/inet/ static_routes и хранятся там в момент загрузки. Перечислим еще несколько приемов. • Если вы хотите увидеть имена, а не числа, то для того, чтобы проверить суще- ствующие маршруты, используйте команды netstat -nr или netstat -г. Числа часто удобнее при отладке, поскольку имя может быть искажено. Пример работы команды netstat приведен в разделе 14.5. • Для указания стандартного маршрута системы используйте ключевое слово default вместо адреса или сетевого имени. • Для того чтобы удалить записи из таблицы маршрутизации, используйте команды route delete или route del. • Для инициализации таблицы маршрутизации и начала работы в системе UNIX ис- пользуйте команды route -f или route flush. • Маршруты в протоколе IPv6 задаются так же, как и маршруты в протоколе IPv4. Для того чтобы указать команде route, что используется адресное пространство протокола IPv6, необходимо использовать опции -inet6 или -A inet6. • Файл /etc/networks задает преобразование имен в сетевые номера, аналогич- но тому как файл hosts отображает имена узлов в IP-адреса. Такие команды, как route, ожидающие сетевой номер, могут принимать имя, если оно указано в фай- ле networks. Сетевые имена можно также перечислить в базах данных NIS или DNS (см. документ RFC1101). • Для установки маршрута, специфичного для заданного IP-адреса, можно исполь- зовать команду route add -host. По существу, эта команда аналогична заданию маршрута с маской 255.255.255.255, но при этом он отдельно отмечается в таблице маршрутизации. Конфигурирование DNS Для того чтобы сконфигурировать компьютер в качестве DNS-клиента, достаточно отредактировать файл /etc/resolv.conf. DNS-служба при этом, строго говоря, не нужна (см. раздел 19.5), но трудно представить себе ситуацию, в которой без нее можно было бы вообще обойтись. Файл /etc/resolv.conf содержит список DNS-доменов, просматриваемых при анализе неполных имен (например, “anchor” вместо anchor.cs.colorado.edu), и список IP-адресов серверов имен, в которых осуществляется поиск имен. Ниже показан пример этого файла; подробнее о нем рассказывается в разделе 17.3.
Глава 14. Сети TCP/IP 531 search cs.colorado.edu colorado.edu nameserver 128.138.242.1 nameserver 128.138.243.151 nameserver 192.108.21.1 Первым должен быть приведен “ближайший” стабильный сервер имен, так как он опрашивается в первую очередь. Всего можно задать три записи nameserver. Жела- тельно указывать более одного сервера. Период тайм-аута DNS-запроса к конкретному серверу имен достаточно велик, поэтому, если первый сервер не отвечает, пользовате- ли это заметят. Если локальный узел получает адреса своих DNS-служб через протокол DHCP, то клиентское программное обеспечение протокола DHCP записывает адреса, полученные в аренду, в файл resolv.conf. Поскольку конфигурация DHCP в боль- шинстве систем задана по умолчанию, обычно нет необходимости редактировать файл resolv.conf самостоятельно, если DHCP-сервер настроен корректно. Многие сайты используют реализацию DNS-сервера Active Directory, созданную ком- панией Miscosoft. Она прекрасно работает с файлом resolv.conf в системах UNIX и Linux, и нет никакой необходимости придумывать что-либо другое. 14.11. Сетевое конфигурирование В РАЗЛИЧНЫХ СИСТЕМАХ В ранних версиях систем UNIX настройка сетевой конфигурации осуществлялась пу- тем редактирования сценариев системной загрузки и непосредственного изменения со- держащихся в них команд. Современные системы содержат сценарии, доступные только для чтения; они охватывают множество сценариев конфигурирования и осуществляют выбор, основываясь на повторном использовании информации, содержащейся в других системных файлах, или на данных, содержащихся в файлах конфигурации. Несмотря на то что разделение конфигурации и реализации — хорошая идея, каждая система осуществляет ее немного иначе, чем другая. Формат и способы использования файлов /etc/hosts и /etc/resolv.conf в системах UNIX и Linux довольно хорошо согласованы, но этого нельзя со всей определенностью сказать обо всех системах. Многие системы обеспечивают графический пользовательский интерфейс дая вы- полнения основных задач, связанных с конфигурированием, однако соответствие между визуальным интерфейсом и файлами конфигурации часто остается неясным. Кроме того, графический пользовательский интерфейс часто игнорирует сложные варианты конфигурации и остается довольно неудобным для удаленного и автоматизированного администрирования. В следующих разделах мы раскритикуем некоторые варианты кон- фигурирования, опишем то, что происходит за кулисами, и раскроем детали сетевого конфигурирования для каждой из популярных операционных систем. В частности, мы рассмотрим следующие вопросы. • Основная конфигурация • Конфигурация DHC-клиента • Динамическое конфигурирование и настройка • Безопасность, брандмауэры, фильтрация и конфигурация NAT • Трюки Однако в каждом разделе не обязательно обсуждать все операционные системы.
532 Часть и. Работа в сети Следует иметь в виду, что в большинстве случаев сетевое конфигурирование осущест- вляется в момент загрузки, поэтому эта тема частично перекрывается с информацией, представленной в главе 3. 14.12. Сетевое конфигурирование в системе Linux Д Система Linux — одна из систем, в которых новые сетевые функциональные возможности реализуются в первую очередь. Семейство систем Linux иногда изменяется настолько быстро, что теряет возможность взаимодействия с осталь- ной сетевой инфраструктурой. Например, реализация в системе Linux явного уведомления о перегруженности (explicit cogestion notification — ECN), опи- санного в документе RFC2481, противоречит некорректным установкам, за- данным по умолчанию в устаревшем брандмауэре компании Cisco, что вызы- вает удаление всех пакетов, содержащих набор битов ECN. Разработчики системы Linux любят чинить ее на скорую руку и часто реализуют функциональные возможности и алгоритмы, пока не имеющие принятых стандартов. Примером этого является включение сменных алгоритмов контроля за перегрузкой в ядро системы Linux версии 2.6.13. Некоторые функциональные возможности предусма- тривают варианты для сетей с потерями (lossy networks), высокоскоростных глобальных вычислительных сетей (wide area network — WAN) с большими потерями пакетов, спут- никовыми связями и т.д. Стандартный механизм “гепо”, реализованный в протоколе TCP (медленный старт, избегание перегрузок, быстрая повторная пересылка и быстрое восстановление), по-прежнему используется по умолчанию, но в конкретной среде мо- жет оказаться более приемлемым другой вариант. После внесения любых изменений в файл, управляющий сетевой конфигурацией в момент загрузки, необходимо либо перезагрузить систему, либо отключить сетевой ин- терфейс, а затем снова включить его, чтобы изменения вступили в силу. В большинстве систем Linux для этой цели можно использовать команды if down интерфейс или if up интерфейс, хотя их реализации не являются идентичными. (В системе SUSE команды ifup и ifdown выполняются, только если работа в сети не находится под управлением демона NetworkManager.) Демон NetworkManager Поддержка работы в мобильной сети, осуществляемая в системе Linux, некоторое вре- мя была довольно неорганизованной, пока в 2004 году не появился демон NetworkManager. Он состоит из службы, предназначенной для непрерывного функционирования, а так- же приложения для работы с областью уведомлений, позволяющего конфигурировать индивидуальные сетевые интерфейсы. Кроме разнообразных проводных сетей, демон NetworkManager поддерживает также работу беспроводных сетей, систем беспроводного широкополосного доступа и частных виртуальных сетей (VPN). Он постоянно осущест- вляет оценку доступных сетей и переключает службу на “предпочтительные” сети, как только те становятся доступными. Наиболее предпочтительными являются проводные сети, за ними следуют обычные беспроводные сети. Все это довольно сильно изменило сетевую конфигурацию системы Linux. Помимо того, что она стала более изменчивой по сравнению с традиционной статической кон- фигурацией, теперь она запускается и управляется пользователем, а не системным ад- министратором. Демон NetworkManager широко внедрен в дистрибутивы систем Linux,
Глава 14. Сети TCP/IP 533 включая все экземпляры, рассматриваемые в книге, но для того чтобы избежать нару- шения существующих сценариев и настроек, он обычно предусматривается как “парал- лельная вселенная” в дополнение к традиционной сетевой конфигурации, которая ис- пользовалась в прошлом. Система SUSE предлагает сделать выбор между миром демона NetworkManager и уста- ревшей конфигурацией, управляемой посредством программного пакета YaST. Система Ubuntu запускает демона NetworkManager по умолчанию, сохраняя при этом статически конфигурируемые сетевые интерфейсы за пределами демона NetworkManager. Система Red Hat Enterprise Linux вообще не запускает демона NetworkManager по умолчанию. Демон NetworkManager, в основном, используется в ноутбуках, поскольку их се- тевое окружение может часто изменяться. Для серверов и настольных систем демон NetworkManager не обязателен и фактически может даже усложнять администрирова- ние. В этом окружении он должен игнорироваться или отключаться. Сетевое конфигурирование в системе Ubuntu ®Как показано в табл. 14.6, система Ubuntu задает конфигурацию сети в файлах /etc/hostname/ и /etc/network/interfaces, а справочная информация записана в файле /etc/network/options. Таблица 14.6. Сетевая конфигурация системы Ubuntu, записанная в каталоге /etc Файл • ' ;~ hostname Имя компьютера network/interfaces IP-адрес, сетевая маска, стандартный маршрут Имя компьютера задается в файле /etc/hostname/. Имя, записанное в этом файле, должно быть полностью квалифицированным; оно используется в самых разных кон- текстах, некоторые из которых требуют полной квалификации. IP-адрес, сетевая маска и стандартный шлюз задаются в файле /etc/network /interfaces. Каждый интерфейс задается строкой, начинающейся с ключевого слова i face. За этой строкой могут следовать строки, задающие дополнительные параметры. Рассмотрим пример. auto lo ethO iface lo inet loopback iface eyhO inet static address 192.168.1.102 netmask 255.255.255.0 gateway 192.168.1.254 Команды ifup и ifdown читают этот файл и, соответственно, подключают или от- ключают интерфейсы, вызывая низкоуровневые команды (например, ifconfig) с соот- ветствующими параметрами. Строка auto задает интерфейсы, которые должны вклю- чаться при загрузке или при выполнении команды ifup -а. Ключевое слово inet в строке iface определяет семейство адресов наподобие ifconfig. Ключевое слово static обозначает способ описания интерфейса и указывает на то, что IP-адрес и сетевая маска интерфейса ethO будут заданы непосредственно. Для статических интерфейсов строки address и netmask являются обязательными. В пер- вых версиях ядра Linux необходимо было указывать также адрес сети, но современные Ядра “умнее” и могут самостоятельно определить его на основании IP-адреса и маски. В строке gateway определяется адрес стандартного шлюза.
534 Часть и. Работа в сети Сетевое конфигурирование в системе SUSE Система SUSE осуществляет выбор между демоном NetworkManager и тради- ционной системой конфигурирования. Выбор происходит в пакете YaST; вы можете также использовать графический пользовательский интерфейс паке- та YaST. Здесь будем предполагать, что используется традиционная система. Кроме конфигурирования сетевых интерфейсов, пакет YaST обеспечивает не- посредственные пользовательские интерфейсы для ввода файла /etc/hosts, статических маршрутов и конфигурации DNS. Описание файлов конфигура- ции приведено в табл. 14.7. Таблица 14.7. Сетевые конфигурационные файлы SuSE из каталога /etc/sysconf ig/network 1 " Файл •.-•i-z.' ... ifcfg-интерфейс ifroute-интерфейс routes config Имя компьютера, IP-адрес, сетевая маска и др. Определение маршрута, связанного с интерфейсом Стандартный маршрут, статические маршруты Множество переменных, которые используются относительно редко За исключением параметров DNS и имени компьютера, система SUSE устанавливает большинство сетевых опций в файлах ltatg-интерфейс, находящихся в каталоге /etc /sysconfig/network. Каждому интерфейсу в системе должен соответствовать отдель- ный файл. Кроме IP-адресов, шлюза и информации о широкополосном доступе для интер- фейса, файлы ifcfg-* могут содержать другие сетевые настройки. В качестве приме- ра можно открыть файл ifcfg. template, в котором содержатся ясные комментарии о возможных параметрах. Рассмотрим пример, содержащий наши комментарии. BOOTPROTO='static' #Подразумевается статический IP-адрес IPADDR='192.168.1.4/24' #/24 определяет переменные NETWORK и NETMASK NAME='AMD PCnet - Fast 79C971' #Используется для запуска #и остановки интерфейса STARTMODE=’auto' #3апускается автоматически во время загрузки USERCONTROL='по' #Отключает управление со стороны графического #пользовательского интерфейса kinternet/cinternet Глобальная статическая информация о маршрутизации в системе SUSE (включая стандартный маршрут) хранится в файле route. Каждая строка в этом файле напоми- нает команду route с пропущенными необязательными именами и содержит информа- цию о пункте назначения, шлюзе, сетевой маске, интерфейсе и других необязательных параметрах, которые должны храниться в таблице маршрутизации и предназначаются для демонов маршрутизации. Файл route для компьютера, конфигурация которого по- казана выше и который имеет только один стандартный маршрут, содержит следующую строку. default 192.168.1.254 - - Маршруты, являющиеся уникальными для каждого конкретного интерфейса, хра- нятся в файле if route-интерфейс, в котором номенклатура компонента интерфейс со- впадает с номенклатурой файлов ifcfg-*. Содержимое этих файлов имеет тот же фор- мат, что и содержимое файла route.
Глава 14. Сети TCP/IP 535 Сетевое конфигурирование в системе Red Hat Графический пользовательский интерфейс для сетевой конфигурации системы Red Hat называется system-config-network; он также доступен из меню System->Admi- nistration под именем Network. Этот инструмент обеспечивает простой пользовательский интерфейс для конфигурирования индивидуальных сетевых интерфейсов и статических маршрутов. Он также имеет панели для установки туннелей IPsec, конфигурирования системы DNS и добавления записей в файл /etc/hosts. Файлы конфигурации, которые можно редактировать с помощью графического поль- зовательского интерфейса, перечислены в табл. 14.8. Таблица 14.8. Сетевые конфигурационные файлы SuSE из каталога /etc/sysconfig/network Файл , network Имя компьютера, стандартный маршрут static-routes Статические маршруты network-scripts/ifcfg-ifname Параметры интерфейсов: IP-адреса, сетевые маски и т.д. Имя компьютера записывается в файл /etc/sysconfug/network, который также содержит имя домена DNS и информацию о стандартном шлюзе. Например, ниже приведено содержимое файла network для компьютера с един- ственным интерфейсом Ethernet. NETWORKING=yes NETW0RKING_IPV6=no HOSTNAME=redhat.toadranch.com DOMAINNAME=toadranch.com ### необязательное поле GATEWAY=192.168.1.254 Данные, связанные с интерфейсом, хранятся в файле /etc/sysconfig/network- scripts/ifcfg-i fname, где параметр i fname — имя сетевого интерфейса. Эти файлы конфигурации задают IP-адрес, сетевую маску, сеть и широковещательный адрес для каждого интерфейса. Они также содержат строку, указывающую, должен ли интерфейс включаться в момент загрузки. Типичный компьютер имеет файлы для интерфейса Ethernet (ethO) и интерфейс об- ратной связи (1о). Рассмотрим пример. Обычно в системе присутствуют файлы для Ethemet-платы (ethO) и интерфейса об- ратной связи (1о). Вот каким будет содержимое файлов ifcfg-ifcfg-ethO и ifcfg-lo Для узла redhat. toadranch. com, описанного выше в файле network. DEVICE=ethO IPADDRS92.168.1.13 NETMASK=255.255.255.0 NETWORKS92.168.1.0 BROADCASTS 92.168.1.255 ONBOOT=yes И devices© IPADDRS27.0.0.1 NETMASK=255.0.0.0 NETWORKS27.0.0.0 BROADCASTS27.255.255.255
536 Часть II. Работа в сети ONBOOT=yes NAME=loopback Настройки интерфейса ethO на основе протокола DHCP выглядят еще проще. DEVICE=ethO BOOTROTO=dhcp ONBOOT=yes После изменения информации о конфигурации в файле /etc/sysconfig следует выполнить команду if down if пате, а затем ifup if пате, где if пате — имя соответ- ствующего интерфейса. Для одновременной конфигурации нескольких интерфейсов можно использовать команду service network restart, которая перезагружает сеть. (На самом деле эта команда представляет собой упрощенный способ вызова утилиты /etc/rc.d/init.d/network, которая вызывается в момент загрузки с аргументом start.) Сценарии запуска Red Hat также могут конфигурировать статические маршруты. Любой маршрут, внесенный в файл /etc/sysconfig/static-routes, добавляется в таблицу маршрутизации на этапе начальной загрузки. Записи этого файла содержат ар- гументы для команды route add, хотя и в смешанном порядке (интерфейс указан пер- вым, а не последним). ethO net 130.225.204.48 netmask 255.255.255.248 gw 130.225.204.49 ethl net 192.38.8.0 netmask 255.255.255.224 gw 192.38.8.129 Интерфейс указывается первым, но на самом деле он перемещается в конец команд- ной строки route, устанавливая связь маршрута с конкретным интерфейсом. (Этот же прием используется в графических пользовательских интерфейсах, где маршруты кон- фигурируются как часть настройки каждого интерфейса.) Оставшаяся часть строки со- держит аргументы команды route. Пример команды static-routes, приведенный выше, генерирует следующие команды. route add -net 130.225.204.48 netmask 255.255.255.248 gw 130.225.204.49 ethO route add -net 192.38.8.0 netmask 255.255.255.224 gw 192.38.8.129 ethl Ядра современных систем семейства Linux не используют параметр metric команды route, но позволяют вводить его в таблицу маршрутизации для использования демона- 5 ми маршрутизации. Настройка сетевого оборудования в системе Linux Команда ethtool запрашивает и устанавливает параметры сетевого интерфейса, ха- рактерные для среды, например скорость связи и дуплекс. Она представляет собой заме- ну старой команды mii-tool, но в некоторых системах используются обе команды. Запросить состояние интерфейса можно, просто назвав его имя. Например, интер- фейс ethO (типичная сетевая карта на материнской плате персонального компьютера), описанный ниже, допускает автонастройку и в настоящий момент работает на предель- ной скорости. ubuntu# ethtool ethO Settings for ethO: Supported ports: [ TP Mil ] Supported link modes: lObaseT/Half lObaseT/Full lOObaseT/Half lOObaseT/Full lOOObaseT/Half lOOObaseT/Full Supports auto-negotiation: Yes
Глава 14. Сети TCP/IP 537 Advertises link modes: lObaseT/Half 100baseT/Half lOOObaseT/Half Advertises auto-negotiation: Yes Speed: lOOOMb/s Duplex: Full Port: Mil PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes lObaseT/Full lOObaseT/Full lOOObaseT/Full Для того чтобы перевести этот интерфейс в полнодуплексный режим на скорости 100 Мбит/с, используется следующая команда. ubuntu# ethtool -s ethO speed 100 duplex full Если вы пытаетесь определить, надежна ли автонастройка в вашей среде, то может оказаться полезной команда ethtool -г. Она вызывает мгновенную перенастройку па- раметров связи. Еще одним полезным вариантом является опция -к, которая показывает, какая из задач, связанных с протоколом, была назначена сетевому интерфейсу, а не выполняется ядром. Большинство интерфейсов может вычислять контрольные суммы, а также вы- полнять сегментацию. Если вы сомневаетесь, что сетевой интерфейс надежно выпол- няет эти задания, то лучше их отключить. Для включения и отключения этих функций используется команда ethtool -К в сочетании с другими опциями. (Опция -к демон- стрирует текущее состояние, а опция -К устанавливает его.) Любые изменения, сделанные с помощью команды ethtool, являются временны- ми. Если вы хотите, чтобы они стали постоянными, то следует убедиться, что команда ethtool выполняется как часть конфигурации сетевого интерфейса. Для этого лучше всего сделать ее частью конфигурации каждого интерфейса; если просто выполнять какие-то команды ethtool во время загрузки, то ваша конфигурация не будет правиль- но учитывать случаи, когда интерфейсы запускаются вновь без перезагрузки системы. Работая с системой Red Hat, можно включить в файл конфигурации интер- фейса, расположенный в каталоге /etc/sysconfig/network-scripts, стро- ку ETHTOOL_OPTS=line. В качестве аргумента команда ifup передает коман- де ethtool целую строку. Система SUSE выполняет команду ethtool аналогично системе Red Hat, но опция называется ETHTOOL OPTIONS и файлы конфигурации каждого интер- фейса хранятся в каталоге /etc/sysconf ig/network. В системе Ubuntu команду ethtool можно выполнить в рамках сценария post-up, заданного в конфигурации интерфейса в каталоге /etc/network/ interfaces. Опции протокола Linux TCP/IP Система Linux помещает представление каждой настраиваемой переменной ядра в виртуальную файловую систему /ргос. Сетевые переменные находятся в каталоге /ргос/
538 Часть II. Работа в сети sys/net/ipv4. Приведем для иллюстрации сокращенный список наиболее интересных из них. ubuntu$ cd /proc/sys/net/ipv4; Is -F t cp_n o_me t r i c s_s a ve conf/ tcp_congestion_control tcp_orphan_retries icmp_echo_ignore_all tcp_dma_copybreak tcp_reordering icmp_echo_ignore_broadcast tcp_dsack tcp_retrans_collapse tcp_ecn tcp_retriesl icmp_ratelimit tck_fack tcp_retries2 icmp_ratemask tcp_fin_timeout tcp_rfcl337 i gmp__max_membe r s h ip s tcp_frto tcp_rmem igmp_max_msf tcp_frto_response tcp_sack inet_peer_gc_maxtime tcp_keepa1ive_intvl .. . i ne t_pee r_g c_mi n t ime tcp_keepalive_probes tcp_stdurg inet_peer_maxttl t cp_keepa1ive_t ime tcp_synack_retries inet_peer_minttl tcp_low_latency tcp_syncookies inet_peer_threshold tcp_max_orphans tcp_syn_retries ip_de f au11_111 tcp_max_ssthresh t cp_t ime s t amp s ip_default_ttl tcp_max_syn_backlog ... ip_forward t cp_max_t w_bu c ke t s udp_mem ... tcp_mem udp_rmem_min neigh/ t cp_mo de r a t e_r cvbu f udp_wmem_min route/ tcp_mtu_probing Многие переменные, имена которых содержат слова rate и шах, используются для противодействия DoS-атакам (denial of service attacks). Подкаталог conf содержит пе- ременные, устанавливаемые для каждого интерфейса. Он содержит подкаталоги all и default и отдельный подкаталог для каждого интерфейса (включая интерфейсы loopback). Каждый подкаталог содержит один и тот же набор файлов. ubuntu$ cd conf/default; Is -F accept_redirects disable_policy promote_secondaries accept_redirects disable_xfrm proxy_arp arp_accept force_igmp_version rp_filter arp_announce forwarding secure_redirects arp_filter log_martians send_redirects arp_ignore mc_forwarding shared_media bootp_relay medium_id tag Например, если изменить переменную в подкаталоге conf/ethO, то это изменение будет относиться только к данному интерфейсу. Если изменить значение в каталоге conf/all, то можно ожидать, что соответствующее изменение произойдет во всех су- ществующих интерфейсах, но не факт, что это произойдет на самом деле. Для каждой переменной существуют собственные правила принятия изменений с помощью каталога all. Некоторые изменения применяются к существующим значениям по правилу OR, некоторые — по правилу AND, а остальные — по правилам МАХ и MIN. Кроме ис- ходного кода ядра, этот процесс больше не описан ни в одном документе, поэтому таких неопределенных ситуаций лучше всего избегать, ограничивая изменения отдельными интерфейсами. Если изменить переменную в каталоге conf/default, то новое значение будет отно- ситься ко всем интерфейсам, которые будут конфигурироваться позднее. С другой сто- роны, лучше всего использовать значения, принятые по умолчанию, лишь для справки;
Глава 14. Сети TCP/IP 539 это позволит восстановить нормальное функционирование системы в случае неудачного конфигурирования. Каталог /proc/sys/net/ipv4/neigh содержит также подкаталоги для каждого ин- терфейса. Файлы в каждом из этих подкаталогов управляют ARP-таблицей и выявлением “соседей” данного интерфейса по протоколу IPv6. Приведем список этих переменных; переменные, имена которых начинаются с букв gc (garbage collection — сборка мусора), определяют, каким образом устаревают и аннулируются записи в ARP-таблице. ubuntu$ cd neigh/default; Is -F anycast_delay gc_stale_time proxy_delay app_solicit gc_threshl proxy_qlen base_reachable_time gc_thresh2 retranS—time bade_reachable_time_ms gc_thresh3 retrans_time_ms delay_first_probe_time locktime ucast_solicit gc_interval mcast_solicit unres_qlen Для того чтобы увидеть значение переменной, следует применить команду echo к Со- ответствующему имени файла. Например, команда ubuntu# cat icmp__echo__ignore_broadcast О показывает, что значение этой переменной равно нулю, т.е. широковещательная про- верка связи не игнорируется. Для того чтобы установить это значение равным единице (и тем самым предотвратить атаку DoS типа Smurf), следует выполнить команду ubuntu# sudo sh -с "echo 1 > icmp_echo_ignore_broadcasts"18 в каталоге /ргос/sys/net. Обычно вы зарегистрированы в той же сети, которую пытаетесь настроить, поэто- му будьте осторожны! Вы можете так запутать настройки, что придется перегружать си- стему с консоли, а это может оказаться неудобным, если система, например, находится в Пойнт-Барроу, штат Аляска, и за окном январь. Прежде чем даже просто подумать о настройке головного компьютера (production machine), проведите тестирование на своей настольной системе. Для того чтобы указанные изменения стали постоянными (или, говоря точнее, что- бы они восстанавливались при каждой перезагрузке системы), добавьте сосхйЁМетвую- щие переменные в каталог /etc/sysctl. conf, который считывается командой sysctl во время загрузки. Формат файла sysctl.conf выглядит так: переменная=значение, а не echo value > variable, как это принято в оболочке при изменении переменно вручную. Именами переменных являются относительные пути к каталогу /ргос/зуй; кроме того, если хотите, можно использовать точки, а не косые черты. Например, каж- дая из строк net.ipv4.ip_forward=0 net/ipv4/ip_forward=0 в файле /etc/sysctl/conf отключает пересылку IP-пакетов на заданный хост. Некоторые подкаталоги каталога /ргос документированы лечше, чем другие. Лучше всего обратиться к разделу 7 справочной системы протокола. Например, команда 18 Если попытаться выполнить эту команду в форме sudo echo 1 > icmp_echo_ignore^ broadcasts, то будет сгенерировано сообщение “в разрешении отказано”, потому что ваша обо- лочка пытается открыть выходной файл до выполнения команды sudo. Вы же хотите применить команду sudo как к команде echo, так и к перенаправлению. Следовательно, вы должны создать корневую подоболочку (root subshell), в которой необходимо выполнять всю команду целиком.
540 Часть II. Работа в сети man 7 icmp документирует четыре из шести возможных вариантов. (При этом необхо- димо, чтобы справочные страницы о ядре системы Linux были инсталлированы заранее.) Кроме того, полезные комментарии можно найти в файле ip_sysctl. txt, находя- щемся в дистрибутивах исходного кода ядра. Если исходный код ядра не инсталлирован, то отправьте в поисковую систему запрос ip-sysctl-txt. Переменные ядра, связанные с безопасностью В табл. 14.9 описано стандартное поведение Linux-систем в отношении различных сетевых методик обеспечения безопасности. Все они кратко рассмотрены выше. Мы ре- комендуем установить соответствующие параметры так, чтобы система не отвечала на широковещательные ICMP-запросы, не подчинялась директивам переадресации и не принимала пакеты, маршрутизируемые “от источника”. Таблица 14.9. Режимы безопасности в системе Linux, заданные по умолчанию функциональная ' - -‘ ВОЗМОЖНОСТЬ - ? Пересылка IP-пакетов Отключена Включена ipjorward для всей системы conf/интерфейс/forwarding для каж- дого интерфейсаа Переадресующие Принимаются Игнорируются conf/wHrep(/)ewc/accept_redirects ICMP-пакеты Маршрутизация “от источника” Переменная Переменная conf/MHrep</)eMc/accept_source_route Широковещательное тестиро- Игнорируется Игнорируется icmp_echo_ignore_broadcasts вание а В качестве параметра интерфейс может быть задано имя конкретного интерфейса или ключевое слово all. Система Linux NAT и фильтрация пакетов В системе Linux традиционно реализуется лишь отдельная разновидность системы NAT (Network Address Translation — трансляция сетевых адресов), называемая PAT (Port Address Translation — трансляция адресов портов). В ней не используется диапазон част- ных адресов, как в истинной системе NAT, а все соединения коммутируются по одному адресу. Впрочем, с практической точки зрения это не имеет особого значения. Утилита iptables реализует не только систему NAT, но и фильтрацию пакетов. В ранних версиях системы Linux эта функциональная возможность была относительно запутанной, но утилита iptables позволила намного точнее отделить систему NAT от фильтрации пакетов. Фильтрации пакетов посвящен раздел 22.11. Если система NAT используется для обеспечения доступа в Интернет с локальных компьютеров, то при ее работе необходимо использовать полный набор фильтров брандмауэра. Тот факт, что “система NAT не осу- ществляет реальную маршрутизацию” не делает шлюз Linux NAT более безопасным, чем маршрутизатор Linux. Для краткости мы опишем только реальную конфигурацию систе- мы NAT, однако следует помнить, что это лишь малая часть полной конфигурации. Для того чтобы осуществлялось IP-маскирование, нужно включить перенаправление IP-пакетов и скомпилировать ядро, задав переменную ядра в каталоге /proc/sys/net /ipv4/ip_forward равной 1. Кроме того, необходимо вставить соответствующие мо- дули ядра.
Глава 14. Сети TCP/IP 541 ubuntu $ sudo /sbin/modprobe iptable_nat ubuntu$ sudo /sbin/modprobe iptable_conn track ubuntu $ sudo /sbin/modprobe iptable__conntrack_ftp Существует много других модулей, обслуживающих соединения; их более полный список можно найти в подкаталоге /lib/modules. Команда iptables для маршрутизации пакетов с помощью системы NAT имеет сле- дующий вид. sudo iptables -t -nat -A -POSTROUTING -0 ethl -j SNAT -to 63.173.189.1 В данном примере интерфейсом для связи с Интернетом является интерфейс ethO. Он не появляется в этой командной строке непосредственно. Вместо него в командной строке используется его IP-адрес в качестве аргумента —to. Интерфейс ethl связан с внутренней сетью. Оказывается, все пакеты, направляемые от интернет-хостов во внутреннюю сеть имеют IP-адрес интерфейса ethO. Хост, выполняющий систему NAT, получает входные пакеты, ищет их настоящие адреса, заменяет эти адреса соответствующими адресами внутренней сети и “отпускает их с миром”. 14.13. Работа в сети под управлением системы Solaris У4*/ Система Solaris поставляется с огромным набором сценариев запуска. На SOiariS одной презентации мы выиграли отрывной календарь системного админи- стратора, в котором на каждой странице были помещены тривиальные вопро- сы. Вопрос для 1 января звучал так: “Назовите все файлы, которые следует открыть, если вы хотите изменить имя компьютера и IP-адрес машины, на которой выполняется система Solaris”. Ответ состоял из имен шести файлов. Такая модульность представляет собой эксцентричную крайность. Однако^ вернемся к сетевой конфигурации системы Solaris. Основная сетевая конфигурация системы Solaris Система Solaris одну часть файлов сетевой конфигурации прячет в каталоге /etc, а другую — в каталоге /etc/inet. Многие из них дублируются посредством таинствен- ных символьных связей, благодаря которым реальные файлы могут находиться в катало- ге /etc/inet, а связи — в каталоге /etc. Для того чтобы задать имя компьютера, введите его в файл /etc/nodename. Изме- нение вступит в силу при перезагрузке компьютера. Некоторые сайты используют ко- роткое имя компьютера, в то время как другие — полностью квалифицированное до- менное имя. Ш Информация о переключении службы имен приводится в разделе 19.5. Имя файла /etc/defaultdomain означает, что его можно использовать только в Данном домене DNS, но на самом деле он задает доменное имя NIS или NIS+. Домен DNS задается в каталоге /etc/resolv.conf, как обычно. Для определения порядка, в котором производится просмотр имен компьютеров в базе данных /etc/hosts и в службах NIS, NIS+ и DNS, система Solaris использует файл /etc/nsswitch. conf. Для того чтобы не усложнять загрузку, рекомендуем сначала про-
542 Часть II. Работа в сети сматривать файл hosts, а затем службу DNS. Строка в файле nsswitch.conf должна выглядеть следующим образом. hosts: files dns Эта конфигурация задается по умолчанию, если компьютер получает адреса от DNS- серверов с помощью протокола DHCP. Использование сетей в системе Solaris происходит либо в традиционном режиме, либо в режиме “Network Auto-Magic” (NWAM), в котором работа в сети управляется автономно демоном nwamd. Режим NWAM прекрасно подходит для рабочих станций, но он предусматривает ограниченные возможности для конфигурирования и допускает только один активный интерфейс в каждый момент времени. Дальнейшее описание от- носится к традиционному режиму. Для того чтобы увидеть, какой режим работы сети установлен, следует выполнить ко- манду svcs svc: /network/physical. В файле конфигурации должно быть две строки: для режима NWAM и для традиционного режима (“по умолчанию”). Для переключения конфигурации необходимо выполнить команду svcadm. Например, следующие команды изменяют режим работы системы с NWAM на традиционный. solaris$ svcs svc:/network/physical STATE STIME FMRI disabled Mar_31 svc:/network/physical:default online Mar_31 svc:/network/physical:nwam Solaris$ sudo svcadm disable svc:/network/physical:nwam Solaris $ sudo svcadm enable svc:/network/physical: def auld Система Solaris конфигурирует IP-адрес для каждого сетевого интерфейса с помощью файла /etc/hostname. интерфейс, интерфейс — это обычное имя интерфейса. Эти файлы могут содержать либо имя компьютера, которое записано в файле hosts, либо IP-адрес. Значение, записанное в файле hostname. интерфейс, используется как параметр адрес команды ifconfig, поэтому безопаснее всего использовать адрес, даже несмотря на то, что имя файла конфигурации подразумевает, что используется имя компьютера. В файл hostname. интерфейс можно также записать любые специальные опции ко- манды ifconfig. Эти опции должны находиться в той же строке, что и имя компьютера или его IP-адрес; все это порождает длинную командную строку ifconfig. Сценарии запуска пытаются выяснить IP-адреса всех интерфейсов, используя не соответствующие файлы hostname, а протокол DHCP.19 В исходной поставке загрузочные файлы системы Solaris содержат опции netmask* и broadcast* команды ifconfig. Плюсы означают, что маску подсети, по которой определяется широковещательный адрес, следует искать в файле /etc/netmasks. Этот файл содержит сетевые номера и соответствующие им значения масок подсетей. В этом файле должна быть представлена любая сеть, которая разделяется на подсети иначе, чем сети класса А, В или С. Рассмотрим пример файла netmasks. # CS Department network masks database # Network netmask # ===== ======= # 1 28.138.0.0 255.255.255.192 # default for dept. # 19 Сетевые интерфейсы в системе Solaris должны находиться в пределах области видимости ко- манды ifconfig plumb, чтобы сделать их доступными. При ручном конфигурировании эту команду, возможно, придется выполнять самостоятельно.
Глава 14. Сети TCP/IP 543 128.138.192.64 255.255.255.192 # drag 128.138.192.192 255.255.255.192 # csops 128.138.193.0 255.255.255.224 # berg 128.138.193.32 255.255.255.224 # database 128.138.193.0 255.255.255.192 # slip В первой строке задается стандартная маска /26 для адреса 128.138.0.0 класса В, ко- торая затем заменяется конкретными масками, отличающимися от стандартной. Здесь перечислены все сети, даже те, которые используют стандартную маску и поэтому могут не указываться. В системах, из которых был взят этот пример, файл netmasks хранится на центральном узле и распределяется по всем остальным машинам. Ни на одном от- дельно взятом компьютере нет интерфейсов для всех этих сетей. В предыдущих версиях системы Solaris сетевые сценарии загрузки были записа- ны в файлах каталога /etc/unit.d (преимущественно в файлах rootusr, inetinit, sysid.net и inetsvc). В версии Solaris 10 способ управления загрузочными файлами и системными службами был коренным образом пересмотрен. Сценарии были перерабо- таны и теперь хранятся в каталоге /lib/sve/method. Обзор механизма Service Manage- ment Facility в системе Solaris содержится в разделе 3.6. Если существует файл /etc/defaultrouter, то предполагается, что он содержит идентификатор (который, в свою очередь, может представлять собой имя машины или адрес) стандартного шлюза и дальнейшее конфигурирование маршрутов не выполняет- ся. Как обычно, предпочтительнее указывать адреса; если же задано имя, то для него должна существовать запись в файле /etc/hosts или на сервере DNS в локальной сети. Если стандартный шлюз не указан, то система Solaris пытается запустить демон routed (который на самом деле называется in. routed), но в системе Solaris 10 и бо- лее поздних версиях необходимо запустить демон routed явным образом с помощью команды sveadm enable routing/route. Для определения текущего состояния служб используется команда sves route. Будь осторожны! Если машина имеет несколько интерфейсов или существует файл /etc/gateways, то демон routed запускается в режиме сервера (“болтливом”). Как правило, это не соответствует желаниям пользователей. Для того чтобы предотвратить “верещание”, можно установить флаг “бесшумного” режима. Solaris# sveefg -s routing/route:default setprop routing/quiet_mode = true Примеры конфигураций системы Solaris Рассмотрим несколько команд, необходимых для подключения сетевого интерфейса в системе Solaris и добавления маршрута к стандартному шлюзу. Solaris $ sudo ifconfig elOOOgO plumb solaris$ sudo ifconfig elOOOgO 192.108.21.48 netmask 255.255.255.0 up solaris$ sudo route add default 192.108.21.254 Следующие примеры демонстрируют, как выяснить статус сетевого интерфейса и содержимое таблиц маршрутизации. Команды, вызываемые с помощью утилиты sudo, должны запускаться как корневые (root). Последний пример иллюстрирует особенность команды route в системе Solaris, отсутствующую в других архитектурах: аргумент get позволяет получить информацию о следующем переходе на пути к пункту назначения. Рассмотрим несколько вариантов, отформатированных так, чтобы их было удобно читать. solaris$ ifconfig -а 110: flags=2001000849<UP,LOOPBACK,RUNNING, MULTICAST,IPv4,VIRTUAL>
544 Часть II. Работа в сети mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 elOOOgO: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.108.21.48 netmask ffffffOO broadcast 192.108.21.255 solaris$ sudo ifconfig elOOOgO elOOOgO: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.108.21.48 netmask ffffffOO broadcast 192.108.21.255 ether 0:14:4f:e:e6:1c Обратите внимание: когда команда ifconfig запускается как корневая, она выводит аппаратный адрес интерфейса, а когда ее выполняет пользователь, она этого не делает. solaris% netstat -nr Routing Table: Ipv4 Destination Gateway Flags Ref Use Interface default 192.108.21.254 UG 1 9959 192.108.21.0 192.108.21.48 U 1 4985 elOOOgO 127.0.0.1 127.0.0.0 UH 1 107 loO solaris$ sudo route get google.com route to: gw-in-f100.google.com destination: default mask: default gateway: 192.108.21.254 interface: elOOOgO flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire 0 0 0 0 0 0 1500 0 Конфигурирование протокола DHCP в системе Solaris В системе Solaris существует DHCP-клиент, и она заслуживает награду за самую про-^ стую и разумную процедуру конфигурирования этого клиента. 1 solaris$ sudo ifconfig интерфейс dhcp } Это действительно работает! Команда inconfig вызывает программу dhcpagent*' чтобы получить параметры интерфейса от сервера DHCP и конфигурировать этот ин- терфейс в соответствии с ними. В командной строке ifconfig можно указывать разные опции, чтобы задать интерфейс первичным, установить тайм-аут, увеличить срок аренды параметров или вывести состояние интерфейса. Для того чтобы аннулировать конфигу* рацию DHCP-клиента вручную, необходимо выполнить следующую команду. solaris$ sudo ifconfig интерфейс drop Все это прекрасно, но иногда необходимо автоматически опрашивать сервер DHCP на этапе начальной загрузки. Это можно сделать, вообще не указав никаких файлов конфигурации для интерфейса (тем самым полагаясь на автоматическое конфигуриро- вание, как в программе NetworkManager в системе Linux) либо создав файл /etc/dhcp. интерфейс в дополнение к файлу /etc/hostname. интерфейс. Если хотите, можете за- писать в файл dhcp. интерфейс дополнительные опции, которые будут переданы ко- манде ifconfig. Для того чтобы интерфейс можно было активизировать, должен, как и раньше, суще- ствовать файл hostname. интерфейс, хотя его можно оставить пустым. Если этот файл не пуст, то сценарии загрузки сначала статически конфигурируют интерфейс, используя содержимое этого файла, а затем изменят его конфигурацию с помощью сервера DHCP.
Глава 14. Сети TCP/IP 5$5 Программа dhpagent управляет интерфейсом в соответствии с протоколом DHCR Кроме выполнения других задач, она согласовывает с сервером продление срока аренды и отмену арендованных параметров, когда они уже не нужны. Если конфигурация ин- терфейса, который был настроен с помощью DHCP-сервера, впоследствии изменяемся вручную, то программа dhpagent прекращает им управлять. Программа dhcpagent собирает параметры, арендованные у DHCP-сервера (стан- дартный маршрут, домен, имена серверов и так далее), но не влияет на большинство из них напрямую. Вместо этого она делает их доступными с помощью команды dhcpinfo. Сценарии управления службами обращаются к команде dhcpinf о за разной информа- цией, которая используется в качестве аргументов команды route, записывается в файл resolv. conf и т.д. Программа dhcpagent направляет ошибки в системный журнал с помощью демона и ранжирует информацию по приоритетам. Вывести содержание системного журнала при заданном уровне отладки можно с помощью флага -d. Для того чтобы увидеть конфигурацию конкретного интерфейса, можно просмо- треть файлы в каталоге /etc/dhcp. Однако существование файла интерфейс .dhc еще не означает, что программа dhcpagent в настоящее время управляет данным интерфей- сом, — срок аренды мог закончиться. Команда ndd: протокол TCP/IP и настройка интерфейса в системе Solaris Команда ndd в системе Solaris позволяет изменить конфигурацию стека протоколов TCP/IP в выполняющейся системе. Возможно, “изменить конфигурацию” — слишком сильное выражение. На самом деле каждый модуль предоставляет доступ к своим пара- метрам для проверки и, в некоторых случаях, для уточнения “на ходу”. Основная синтаксическая конструкция этой команды выглядит следующим образом: ndd [-set] устройство ? | переменная [значение] Если указан аргумент ? (его следует защитить от оболочки символом ?), то команда ndd возвращает список переменных, распознаваемых драйвером указанного устройства. Если задать имя переменной, то команда ndd вернет ее значение. Если же использовать флаг -set и задать значение, то оно будет присвоено указанной переменной, К сожалению, на справочной странице, посвященной команде ndd, не перечисляют- ся все возможные имена устройств и ничего не говорится о том, что для доступа к одним устройствам (например, ip и hme) команда ndd должна выполняться как корневая, а для доступа к другим (например, tcp и udp) — нет. Табл. 14.10 представляет собой краткую шпаргалку по работе с командой ndd. Таблица 14,10. Устройства, с которыми может работать команда ndd в системе Solaris Устройство /dev/tcp Переменные протокола TCP tcp_* /dev/udp Переменные протокола UDP udp_* /dev/jp Переменные протокола IP ip_* e ip6_* /dev/icmp Переменные протокола ICMP icmp_* /dev/rawip Идентично устройству /dev/icmp icmp_* /dev/arp Переменные протокола ARP arp*
546 Часть II. Работа в сети Связанные с интерфейсами имена переменных в категории /dev/ip управляют пе- ренаправлением (IP-forwarding) на конкретные сетевые интерфейсы. Например, пере- менная elOOOgO : ip_forwarding управляет перенаправлением на интерфейс /dev/ elOOOgO. Наряду с ней существует и глобальная переменная ip forwarding. Если у вас есть доступ к машине HP-UX, выполните команду ndd с флагом -h (для получения справки), и вы увидите имена устройств, переменных и назначение каждой переменной. Многие имена переменных в системах HP-UX и Solaris совпадают, поэтому можно ограничиться минимальной man-страницей, посвященной команде ndd. С помощью команды ndd можно также устанавливать такие опции, связанные с ин- терфейсами, как скорость связи, автосогласование и поддержка jumbo-пакетов. Для это- го необходимо применить команду ndd непосредственно к файлу устройства, связанно- го с интерфейсом (например, /dev/elOOOgO). К сожалению, способ, которым система Solaris реализует эту возможность, делает имена параметров конфигурации зависимыми от конкретного драйвера, поэтому не существует универсального рецепта, например, для фиксации скорости работы сетевого интерфейса на уровне 100 Мбит/с. Для того чтобы изменить скорость, необходимо идентифицировать соответствующие переменные, задающие “производительность” (обычно они называются *_сар), и от- ключить их (установить равными нулю). Кроме того, следует отключить переменную *autoneg_cap. Например, следующий сценарий устанавливает с помощью переменной /dev/elOOOgO полнодуплексный режим и скорость, равную 100 Мбит/с. #!/bin/sh ndd -set /dev/elOOOgO adv_autoneg_cap 0 ndd -set /dev/elOOOgO adv_1000fdx__cap 0 ndd -set /dev/elOOOgO adv_100fdx_cap 1 ndd -set /dev/elOOOgO adv_100hdx_cap 0 ndd -set /dev/elOOOgO adv_10fdx_cap 0 ndd -set /dev/elOOOgO adv_10hdx_cap 0 Безопасность в системе Solaris В табл. 14.11 описано поведение системы Solaris в некоторых щекотливых ситуаци- ях, касающихся безопасной работы в сети. Краткое описание этих ситуаций приведено в разделе 14.8. Большинство этих настроек можно изменить с помощью команды ndd. Таблица 14.11. Поведение системы Solaris, связанное с сетевой безопасностью Перенаправление IP-пакетов Запрещено Переадресующие ICMP-пакеты По ситуации Направленная маршрутизация Игнорируется Широковещательные ping-пакеты (ответ) Разрешено Широковещательные ping-пакеты (перена- Запрещено правление) ip_forwarding Не может изменятьсяа ip_forward_src_routed ip_respond_to_echo_broadcast ip_forward_directed_broadcast а Можно модифицировать только время существования. Брандмауэры и фильтрация в системе Solaris Как уже говорилось, не следует использовать системы UNIX, Linux или Windows в качестве брандмауэра или шлюза NAT. Для этого лучше использовать специальное ап-
Глава 14. Сети TCP/IP 547 паратное обеспечение. В системе Solaris этому правилу следовать легче, поскольку в нее вообще не входит никакое программное обеспечение для фильтрации. Тем не менее в большинство дистрибутивов сейчас включается свободно распространяемое программ- ное обеспечение IPFilter, созданное Дарреном Ридом (Darren Reed). Оно представляет собой хороший выбор для фильтрации IP-пакетов в системе Solaris. Пакет IPFilter реализует фильтрацию IP-пакетов и прозрачное перенаправление пор- тов. Он представляет собой открытое, свободно распространяемое программное обеспе- чение и работает на компьютерах, имеющих архитектуру SPARC или Intel. Пакет IPFilter содержит утилиты ipf (для конфигурирования брандмаэура), ipfstat (для распечатки инсталлированных правил фильтрации) и ipnat (для реализации механизма NAT). Детали функционирования пакета IPFilter приведены в разделе 22.13, а пока обсудим функциональные возможности механизма NAT, которыми обладает пакет IPFilter. Механизм NAT в системе Solaris Для того чтобы механизм NAT заработал, вы должны сообщить ядру внутренние и внешние адреса, а также диапазон портов, которые будут использоваться для расшире- ния адресного пространства. Обсуждение общих принципов механизма NAT и способов перехода из частного в публичное адресное пространство содержится в разделе 14.4. Для настройки механизма NAT необходимо указать правила для команды ipnat. Эти правила аналогичны правилам, установленным для утилиты ipf при реализации паке- та фильтрации. Однако следует быть осторожным: как и правила ipf, правила ipnat упорядочены, но в обратном порядке. Просто будьте внимательными: выбирается первое применимое правило, а не последнее. Ниже приведено несколько правил ipnat. Для того чтобы привести их в действие во время загрузки, они записаны в файле /etc/ipf/ipnat.conf. map ethl 192.168.1.0/24 -> 128.138.198.0/26 portmap tcp/udp 20000:65000 map ethl 192.168.1.0/24 -> 128.138.198.0/26 Мы предположили, что ethl — это наш интерфейс для выхода в Интернет и что наша внутренняя сеть пронумерована как частное адресное пространство класса С. Эти правила отображают адреса сети /24 в адреса сети /26. Поскольку сеть /26 может вме- стить в себя только четверть машин, которые могут поместиться в сети /24, потенци- ально возможно, что адреса назначения могут выйти за пределы этой конфигурации. Однако пункт portmap расширяет диапазон адресов, разрешая использовать каждый из 45 тыс. разных портов. Первое правило, сформулированное выше, охватывает весь трафик по протоколам TCP и UDP, но не учитывает протокол ICMP, поскольку этот протокол неиспользует концепцию порта. Второе правило перехватывает ICMP-сообщения и пытается отпра- вить их назад на правильную машину. Если ядро не может однозначно определить адре- сата конкретного ICM-сообщения, оно посылает его как широковещательный пакет; машины, которые получат его вне контекста, могут его просто игнорировать. На своем домашнем компьютере вы можете иметь только один IP-адрес, который присвоен вам вашим ISP- или DHCP-сервером. Если вашему компьютеру присвоен статический IP-адрес, то в строке тар просто присвойте в качестве целевой сети пункт назначения /32 и задайте достаточно широкий диапазон портов, чтобы удовлетворить потребности всех ваших локальных машин. Если при каждом соединении вы получае- те новый динамический адрес, то в строке тар следует указать пункт назначения 0/32. Это позволит утилите ipnat считывать адрес непосредственно с сетевого интерфейса.
548 Часть II. Работа в сети В качестве примера приведем строку, которую можно использовать для единственного динамически присваиваемого адреса. map ethl 192.168.1.0/24 -> 0/32 portmap tcp/ip 20000:65000 Для проверки этой конфигурации выполните следующую команду. solaris$ sudo ipnat -CF -f /etc/ipf/ipnat.config Эти опции сначала отменяют все существующие правила, а затем загружают полный набор правил из файла /etc/ipf/ipnat. conf. Особенности сетевого конфигурирования Результат выполнения команды ifconfig -а зависит от того, выполняется ли она как корневая команда или как команда пользователя. В первом случае, помимо IP-адре- сов и параметров, отображаются также адреса Ethernet канального уровня. Система Solaris разрешает менять адреса канального уровня (МАС-адреса) сетевого интерфейса с помощью команды ifconfig и семейства адресов ether. Эта возмож- ность может оказаться полезной, если вам необходимо проникнуть в беспроводную сеть с ограниченными МАС-адресами. 14.14. Работа в сети под управлением системы HP-UX ESI Конфигурирование операционной системы HP-UX не вызывает трудностей: все параметры конфигурации хранятся в файле /etc/rc. config. d/netconf. Значения параметров из этого файла (а также других файлов в каталоге rc.config.d) считываются в переменные окружения на этапе загрузки и ис- пользуются сценарием /sbin/rn. Файл netconf содержит многочисленные комментарии, которые сообщают вам, что именно должно быть записано в ту или иную переменную и для чего. Базовое конфигурирование сетей в системе HP-UX Для того чтобы назначить.машине имя и сконфигурировать ее первый сетевой ин- терфейс, отредактируйте файл netconf, присвоив значения следующим переменным. HOSTNAME INTERFACE_NAME[0) IP_ADDRESS[0] SUBNET_MASK[0] Например: HOSTNAME=disaster INTERFACE_NAME[0]=1ап0 IP_ADDRESS[0]=192.108.21.99 SUBNET_MASK[0]=255.255.255.0 Второй интерфейс будет иметь индекс 1. О его наличии свидетельствует значение переменной net_cards, равное 2.
Глава 14. Сети TCP/IP 549 Файл netconf содержит также переменные для конфигурирования статических маршрутов и запуска демона маршрутизации. Для того чтобы задать стандартный марш- рут, необходимо задать значения следующих переменных. ROUTE-DESTINATION[0]=default ROUTE_MASK[0]="" ROUTE_GATEWAY[0)=192.108.21.254 ROUTE_COUNT[0]=l Переменная ROUTE_MASK необходима для сети, в которой маска подсети отличает- ся от стандартной маски, используемой в данном классе адресов. Переменная ROUTE COUNT должна равняться нулю, если в качестве шлюза используется локальный компью~ тер, и единице, если шлюз расположен на удаленной машине. Параметры остальных статических маршрутов задаются в переменных ROUTE_* с индексами [1], [2] и т.д. Эти значения передаются непосредственно команде route. Например, переменной ROUTE_ destination можно присвоить ключевое слово default, как показано выше, а также выражения net адрес сетпи или host адрес машины. В системе HP-UX используется демон gated, а не routed. Для использования де- мона gated необходимо задать переменную GATED равной 1, а в массив GATED ARGS за- писать список аргументов, передаваемых демону при его выполнении. Подробнее демон gated описывается в главе 15. Много полезной информации содержится на справочной странице, посвященной маршрутизации (man routing). Многие поля в файле netconf могут содержать либо имя компьютера, либо 1Р-адрес. Если указано имя компьютера, то оно обязательно должно присутствовать в файле /etc/hosts. На этапе загрузки система HP-UX просматривает только файл /etc/hosts и не использует никаких других поисковых механизмов. В этом файле сначала должны перечисляться полностью квалифицированные доменные имена, затем короткие имена и псевдонимы. В системе HP-UX используется команда lanscan, с помощью которой можно полу- чить информацию о сетевых интерфейсах, существующих в компьютере. В данной ситу- ации работает команда ifconfig интерфейс, а не ifconfig -а. Имена сетевых интер- фейсов начинаются с префикса “Ian” или “snap”. Префикс “1ап” обозначает канальный уровень Ethernet, а префикс “snap” — спецификацию IEEE 802.3. Первый интерфейс обозначается как 1ап0, второй — lanl и т.д. В системе HP-UX, как и в системе Solaris, принята концепция “подключения” ин- терфейсов. Однако все интерфейсы “подключаются” автоматически, когда команда ifconfig назначает им IP-адреса. SMH — это системная административная утилита системы HP-UX, значительно об- легчающая управление системой UNIX. Она оснащена меню и может использоваться Для конфигурирования сетевых интерфейсов, а также выполнения многих других адми- нистративных задач. Примеры конфигураций в системе HP-UX Для того чтобы вручную подключить сетевой интерфейс в системе HP-UX и задать стандартный маршрут, нужно выполнить команды следующего вида. hp-ux$ sudo ifconfig lanO 192.108.21.99 netmask OxffffffOO hp-ux$ sudo route add default 192.108.21.254 l20 20 В версии HP-UX поле для счетчика переходов не требуется; если оно явно не указано, то по Умолчанию равно нулю. В предыдущих версиях поле для счетчика было обязательным.
550 Часть II. Работа в сети Команда lanscan выводит список сетевых интерфейсов, существующих в системе, и параметры драйверов, которые ими управляют. Команда lanscan -v отображает чуть больше информации. Ниже показан ряд примеров, слегка измененных так, чтобы по- меститься на странице. Поле МАС со значением ETHER означает, что устройство должно называться 1ап0, а не snapO. Команда ifconfig подтверждает, что это соответствует дей- ствительности. $ lanscan Hardware Station Crd Hdw Net-Int NM MAC HP-DLPI DLPI Path Address In# State NamePPA ID Type Support Mjr# 8/0/20/0 0x001 0 UP lanO snapO 1 ETHER Yes 130 $ ifconfig lanO lanO: flags=843<UP, BROADCAST, RUNNING, MULTICAST inet 192.108. 21.99 netmask ffffffOO broadcast 192.108.21.255 $ ifconfig snapO ifconfig: no such interface Команда netstat -i отображает имена сетевых интерфейсов, а команда netstat -nr выводит таблицы маршрутизации. $ netstat -i Name Mtu Network Address Ipkts Opkts lanO 1500 192.108.21. 0 disaster. , xor.com 6047 3648 loO 4136 127.0.0.0 localhost.xor.com 231 231 $ netstat -nr Routing tables Dest/Netmask Gateway Flags Refs Use Int Pmtu 127.0.0.1 127.0.0 UH 0 231 loO 4136 192.108.21.99 192.108.21 .99 UH 8 lanO 4136 192.108.21.0 192.108.21 .99 U 2 0 lanO 1500 127.0.0.0 127.0.0.1 U 0 0 loO 4136 default 192.108.21 .254 UG 0 0 lanO 1500 Программа lanadmin отображает статистику сетевого трафика для каждого обнару- женного интерфейса. С ее помощью можно управлять интерфейсами и следить за их ра- ботой. Эта программа оснащена меню, облегчающим доступ к требуемой информации. Ниже показан пример, в котором демонстрируются данные об интерфейсе 1ап0. % lanadmin LOCAL AREA NETWORK ONLINE ADMINISTRATION, Version 1.0 Copyright 1994 Hewlett Packard Company. All rights are reserved. Test Selection mode. Ian = LAN Interface Administration menu - Display this menu quit = Terminate the Administration terse = Do not display command menu verbose = Display command menu Enter command: lan LAN Interface test mode. LAN Interface PPA Number = 0 clear = Clear statistics registers
Глава 14. Сети TCP/IP 551 display = Display LAN Interface status/statistics end = End LAN Interface Admin., go up 1 level menu = Display this menu ppa = PPA Number of the LAN Interface quit = Terminate the Admin, return to shell reset = Reset LAN Interface, execute selftest specific = Go to Driver specific menu Enter command: display LAN INTERFACE STATUS DISPLAY Thu, Mar 2,2000 00:41:24 PPA Number Description Type (value) MTU Size Speed Station Address Administration Status (value) Operation Status (value) = 0 = lanO Intel PCI Pro 10/100Tx Server Adapter = ethernet-csmacd(6) = 1500 = 100000000 = 0x00306eea9237 = up(l) = up(l) Inbound Unicast Packets Inbound Non-Unicast Packets = 45691 = 2630 Deferred Transmissions Late Collisions Excessive Collisions = 0 = 0 = 0 Конфигурирование протокола DHCP в системе HP-UX Как и в случае других параметров сетевой конфигурации, включить протокол DHCP на этапе загрузки можно, задав переменные в файле /etc/rc.config.d/netconf. В данном случае переменные хранятся в массиве DHCP ENABLE: индекс [0] означает пер- вый интерфейс, индекс [1] — второй и т.д. Например, запись DHCP_ENABLE[С]=1 переводит первый интерфейс в режим DHCP. Интерфейс получит свой IP-адрес, маску подсети и другие сетевые параметры от DHCP-сервера, расположенного в локальной сети. Если задать переменную равной нулю, то протокол DHCP будет отключен; в этом случае вам придется назначать интерфейсу статический адрес в файле netconf. Если запись dhcp_enable отсутствует, считается, что соответствующая переменная по умол- чанию равна единице. Основную задачу по взаимодействию с DHCP-сервером выполняет сценарий /sbin/ autojparms. Программа dhcpdb2conf записывает параметры DHCP, записанные сце- нарием auto_parms в файл netconf, из которого извлекается конфигурационная ин- формация на этапе загрузки. Динамическое переконфигурирование и настройка в системе HP-UX Как и в системе Solaris, для настройки различных сетевых параметров (более 100) в системе HP-UX можно применять команду ndd. В интерактивном режиме команда ndd
552 Часть II. Работа в сети меняет значения “на ходу”. Для того чтобы изменения стали постоянными, следует до- бавить их в файл /etc/rc. config .d/nddconf, который считывается на этапе загрузки. Ш Более подробно команда ndd описана в разделе 14.13. В системе HP-UX довольно полезной является опция -h (вызов справки) команды ndd. Если не указаны дополнительные аргументы, то команда ndd -h выводит список всех настраиваемых параметров. Если указано имя переменной, то команда ndd -h ото- бражает информацию о назначении переменной, а также о ее минимальном и макси- мальном значениях и значении, задаваемом по умолчанию. Рассмотрим пример. $ ndd -h | grep source ip_forward_src_routed - Controls forwarding of source routed packets $ ndd -h ip__forward_src_routed ip_forward_src_routed: Set to 1 to forward source-routed packets; set to 0 to disable forwarding. If disabled, an ICMP Destination Unreachable message is sent to the sender of source- routed packets needing to be forwarded. [0,1] Default: 1 Вывод результатов выполнения команды ndd свидетельствует о том, что в данной версии HP-UX по умолчанию поддерживается направленная маршрутизация пакетов. Это может быть требованием ядра, но фактически файл /etc/rc/conf ig. d/nddconfig позволяет отключить эту возможность. TRANSPORT_NАМЕ [2 ] =ip NDD—NAME[2]=ip_forward_scr_routed NDD_VALUE[2]=0 Двойки в этих записях означают, что в файле nddconfig задается значение третьей из десяти возможных переменных. Если вы захотите изменить следующую переменную* то будет достаточно скопировать эти три строки и заменить индекс 2 на 3. К сожалению, с помощью файла nddconf можно задать только десять параметров. Для того чтобы просмотреть и модифицировать значение переменной ip forward^ src_routed, воспользуемся командами ndd -get и ndd -set (их синтаксическая кон- струкция слегка отличается от принятой в системе Solaris). $ ndd -get /dev/ip ip_forward_src__routed 0 $ sudo ndd -set /dev/ip ip__forward__src—routed 1 $ ndd -get /dev/ip ip__forward__src__routed 1 Безопасность, брандмауэры, фильтрация и система NAT В табл. 14.12 описано стандартное поведение системы HP-UX в ситуациях, связанных с безопасностью работы в сети. Краткое описание последствий этого поведения приве- дено в разделе 14.8. Большинство настроек можно изменить с помощью команды ndd. Таблица 14.12. Поведение системы HP-UX, связанное с сетевой безопасностью_________ ^функциональная возможность По умолчанию Управлениесп<^ ДЙ Перенаправление IP-пакетов Динамическоеа Устанавливает параметр ip_f orwarding; 0 — отключить, 1 — включить, 2 — динамический режим Переадресующие ICMP-пакеты По ситуации6 Для того чтобы отключить эту возможность, устанавливает параметр ip ire redirect interval равным 0
Глава 14. Сети TCP/IP 553 Окончание табл. 14.12 Направленная маршрутизация Игнорируется Для того чтобы включить эту возможность, уста- навливает параметр ip_forward_src_routed равным 1 Широковещательные ping-пакеты Игнорируется (перенаправление) Широковещательные ping-пакеты Блокируется (ответ) Устанавливает параметр ip_forward_directed_broadcast Устанавливает параметр ip respond to echo broadcast а Если параметр больше единицы, то интерфейс включен, иначе — выключен. 6 Записи о перенаправлении по умолчанию хранятся до пяти минут. Как и система Solaris, система HP-UX включает в себя пакет IPFilter для фильтра- ции и реализации механизма NAT, разработанный Дарреном Ридом. Этот пакет описан в разделах 14.13 и 22.13. В системе HP-UX пакет IPFilter ничем не отличается от своего аналога в системе Solaris, хотя система HP-UX конфигурирует его при загрузке несколь- ко иначе. Вместо использования команды svcadm для подключения пакета IPFilter, в системе HP-UX следует редактировать файл /etc/rc.config.d/ipconfig и вклю- чить требуемые опции. Файлы конфигурации для утилит ipf и ipnat должны находить- ся в каталоге /etc/opt/ipf, а не /etc/ipf. Версия демона inetd в системе HP-UX содержит встроенные функции работы с протоколом TCP, которые можно конфигурировать посредством файла /var/adm/ inetd.sec. Если вас интересует, как именно система HP-UX может оказаться незащищенной, прочитайте статью Кевина Стивса (Kevin Steves) о действиях, которые необходимо пред- принять, чтобы превратить систему HP-UX 11 в крепость, стоящую на входе в незащи- щенную сеть: tynyurl. com/5sf fy2. Этот документ немного устарел (он опубликован в 2002 г.), но в нем прекрасно описаны все функциональные возможности, предостав- ляемые системой HP-UX, которые следует отключить, если вы хотите защитить свой компьютер в открытой среде Интернета. Мы бы хотели, чтобы появились аналогичные документы, посвященные другим операционным системам. 14.15. Работа в сети под управлением системы AIX • Вместо того чтобы хранить информацию о сетевой конфигурации в тексто- вых файлах или сценариях, система AIX скрывает ее в базе данных атрибутов и значений Object Data Manager (ODM). Ассоциацию этих списков свойств с конкретными устройствами (на самом деле, с экземплярами устройств) и связывание драйверов с информацией о конфигурации осуществляет другой слой. В общих чертах база данных Object Data Manager описана в разделе 13.6. Ее общая схема довольно сложная. Кроме того, она обеспечивает доступ к сетевой конфигурации разных уровнях. В табл. 14.13 приведено несколько команд системы AIX для зада- ния сетевых адресов интерфейсов. В основном, они отличаются тем, что влияют либо на конфигурацию во время выполнения системы, либо на конфигурацию во время загруз- ки, либо на обе конфигурации.
554 Часть II. Работа в сети Таблица 14.13. Восемь способов задания IP-адресов интерфейса в системе AIX Команда ' /Л*'/' Действует ли на текущую конфигурацию? Действуетли . наконфигурацию загрузки? smitty mktcpip (и заполняет форму) Да Да mktcpip -i епЗ -а 192.168.0.1 Да Да chdev -1 епЗ -a netaddr=192.168.0.1 Да Да chdev -1 епЗ -a netaddr=192.168.0.1 -Р Нет Да chdev -1 епЗ -a netaddr=192.168.0.1 -Т Да Нет ifconfig епЗ inet 192.168.0.1 Да Нет odmchange -о CuAt -q’name=en3 AND attribute=netaddr'<configa Нет Да echo ’Hey! I set the network address!’ Нет Нет а Команда odmchange требует на вход список атрибутов. Задать их значения в командной строке невоз- можно. Точнее говоря, команда mktcpip делает немного больше, чем обычная установка па- раметров конфигурации, — она также запускает сценарий rc.tcpip для запуска соот- ветствующего сетевого демона. Для настройки сетевой конфигурации существует довольно полный набор инстру- ментов под названием SMIT, который вы можете и должны использовать в большин- стве случаев. Опции конфигурации протокола TCP/IP можно найти в пункте меню Communications Applications and Services. Большинство системных администраторов никогда не испытывают необходимости углубляться ниже уровня chdev/lsattr. Однако этот уровень может оказаться полезным для просмотра списка важных параметров конфигурации устройства. Например, следую- щий запрос демонстрирует конфигурируемые параметры для сетевого интерфейса епЗ. aix$ Isattr -Н -Е -1 епЗ attribute value description settable alias4 IPv4 Alias including Subnet Mask True alias6 IPv6 Alias including Prefix Length True а гр on Address Resolution Protocol (ARP) True authority Authrozed Users True broadcast 192.168.10.255 Broadcast Address True mtu 1500 Maximum IP Packet Size True netaddr 192.168.10.11 Internet Address True netaddr6 IPv6 Internet Address True netmask 255.255.255.0 Subnet Mask True prefixlen Prefix Lenght for IPv6 Address True remmtu 576 Max. Packet Size for REMOTE Nets True security none Security Level True state up Current Interface Status True tcp_mssdflt Set TCP Maximum Segment Size True tcp_nodelay Enable/Disable TCP_NODELAY Option True tcp_recvspace Set Socket Buffer Space for Receiving True tcp_sendspace Set Socket Buffer Space for Sending True Флаг -Н позволяет выводить столбцы с заголовками, флаг -Е запрашивает текущие (“настоящие”, в отличие от заданных по умолчанию) значения, а флаг -I идентифици- рует тестируемое устройство. Многие устройства, которыми можно управлять с помощью
Глава 14. Сети TCP/IP 555 команды chdev и других команд, не перечислены в каталоге /dev. Для того чтобы уви- деть полный список устройств, выполните команду Isdev -С. Для того чтобы задать значение, используйте команду chdev. Например, для того чтобы задать значение MTU для интерфейса епЗ больше 1450, выполните следующую команду. aix$ sudo chdev -1 епЗ mtu=1450 Команда по: настройка сетевых параметров в системе AIX Система AIX разделяет системные опции протокола TCP/IP на отдельные непере- секающиеся и постоянные пары “атрибут/значение”, доступ к которым обеспечивает команда по, а не chdev. (Отличие заключается в том, что команда по предназначена для конфигурирования системы, а команда chdev — для конфигурирования конкретных драйверов или устройств.) Для того чтобы увидеть полный список всех доступных переменных (в настоящее время их больше 125), выполните команду по -а. Некоторые переменные, относящиеся к безопасности, перечислены в табл. 14.14. Таблица 14.14. Переменные для настройки системы AIX, связанные с протоколами TCP/IP и безопасностью 11 j1 111 'j Командаr bcastping directed_broadcast ipforwarding ipignoreredirects ipsrcrouteforward ipsrcrouterecv ipsrcroutesend Разрешает ответ на широковещательные ping-пакеты 0 Разрешает перенаправление широковещательных пакетов 0 Разрешает перенаправление IP-пакетов 0 Игнорирует перенаправляющие ICMP-пакеты 0а Разрешает отправлять IP-пакеты с заданным маршрутом 1а Разрешает принимать IP-пакеты с заданным маршрутом 0 Блокирует IP-пакеты с заданным маршрутом 1 а Изменять не рекомендуется. Для того чтобы установить переменную, используйте следующую команду. по -р -о переменная=значение Например, для того чтобы предотвратить перенаправление пакетов с заданным маршрутом стеком протоколов TCP/IP, выполните следующую команду. aix$ sudo no -р ipsfcrouteforward=0 Опция -р вводит изменения в действие как немедленно, так и после перезагрузки. 14.16. Рекомендуемая литература • Stevens W. Richard. TCP/IP Illustrated, Volume One: The Protocols. Reading, MA: Addison-Wesley, 1994. • Wright Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume Two: The Implemen- tation. Reading, MA: Addison-Xtesley, 1995.
556 Часть II. Работа в сети Эти два тома являются прекрасным исчерпывающим руководством по протоколам TCP/IP, хотя уже немного устарели. • Stevens W. Richard. UNIX Network Programming, Upper Saddle River, NJ: Prentice Hall, 1990. • Stevens W. Richard. UNIX Network Programming, volume 1: The Sockets Networking API (3rd Edition). Upper Saddle River, NJ: Prentice Hall, 2003. • Stevens W. Richard. UNIX Network Programming, volume 2: Interprocess Communications (2nd edition) Upper Saddle River, NJ: Prentice Hall, 1998. Эти книги являются библиями для студентов, изучающих сетевое программиро- вание. В первом издании описан только интерфейс сокетов Беркли. В третьем из- дании рассмотрены также интерфейс STREAMS и стандарт IPv6. Все три издания написаны в четком и понятном стиле Рича Стивенза. • Tanenbaum Andrew. Computer Networks (4th Edition). Upper Saddle River, NJ: Prentice Hall PTR, 1996. Эта книга по-прежнему является классическим учебником по сетям. Она содержит подробнейшее описание физического и канального уровней стека сетевых прото- колов. Предыдущие издания были ориентированы на протоколы ISO, но в послед- нем издании описана современная структура сети Интернет. • Salus Peter Н. Casting the Net, From ARPANET to INTERNET and Beyond. Reading, MA Addison-Wesley, 1995. Это захватывающая история о том, как сеть ARPANET превратилась в Интернет. Книга написана историком, который многие годы общался с профессионалами UNIX, поэтому кажется, будто ее писал один из них! • Comer Douglas. Internetworking with TCP/IP, vol. 1: Principles, Protocols, and Archi- tectures, 4th Edition. Upper Saddle River, NJ: Prentice Hall, 200021. Книги Дугласа Камера долгое время считались эталонными справочниками по протоколам TCP/IP. Новое издание содержит описание современных сетевых тех- нологий, а также всех протоколов семейства TCP/IP. Оно предназначено в каче- стве учебного пособия для студентов и является хорошим источником справочно- го материала. • Hunt Craig. TCP/IP Network Administration (3rd Edition). Sebastopol, CA: O’Reilly & Associates, 2002. Эта книга ориентирована на администраторов UNIX-систем. Половина книги по- священа протоколам TCP/IP, а остальной материал касается средств UNIX более высокого уровня, таких как электронная почта и удаленный доступ. • Farrel Adrian. The Internet and Its Protocols: A Comparative Approach. San-Francisco, CA: Morgan Kaufmann Publishers, 2004. • Kozierak Charles M. The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference. San-Francisco, CA: No Starch Press, 2005. Превосходное собрание документов об истории Интернета и его разнообразных технологиях можно найти на веб-сайте isoc. org/internet/history. 21 Дуглас Э. Камер. Сети TCP/IP, т. 1: Принципы, протоколы и структура, 4-е изд. — ИД “Вильямс”, 2002. — Примеч. ред.
Глава 14. Сети TCP/IP 557 14.17. Упражнения 14.1. Почему прием директив переадресации протокола ICMP может привести к не- санкционированному доступу в сеть? 14.2. Что такое значение MTU сетевого канала? Что произойдет, если это значение бу- дет слишком большим? А слишком низким? 14.3. ★ Сеть 134.122.0.0/16 разбита на подсети с длиной маски 19. а) сколько будет подсетей /19? Перечислите их. Каковы их сетевые маски? б) сколько узлов может быть в каждой подсети? в) определите, какой подсети принадлежит адрес 134.122.67.124? г) каким будет широковещательный адрес каждой подсети? 14.4. ★ С узла 128.138.2.4 в сети 128.138.2.0/24 нужно послать пакет узлу 128.138.129.12 в сети 128.138.129.0/24. Предполагается, что • узел 128.138.2.4 имеет стандартный шлюз 128.138.2.1; • узел 128.138.2.4 только что загрузился и еще не отправлял и не принимал па- кеты; • все остальные компьютеры сети работают уже долгое время; • маршрутизатор 128.138.2.1 имеет прямое соединение с узлом 128.138.129.1, ко- торый является шлюзом в подсеть 128.138.129.0/24. а) перечислите все этапы отправки пакета. Покажите исходные и целевые МАС- и IP-адреса передаваемых пакетов. б) если бы адрес сети был 128.138.0.0/16, изменился бы ответ? Если да, то каким бы он был? в) если бы сеть 128.138.2.0 имела маску /26, а не /24, изменился бы ответ? Если да, то каким бы он был? 14.5. ★ Срок аренды параметров задается на сервере DHCP. Допустим, что количество IP-адресов превышает количество потенциальных клиентов. Можете ли вы прод- лить срок аренды на как можно дольше (например, на несколько недель)? Почему да или почему нет? Что можно сказать о других параметрах протокола DHCP? 14.6. ★★ Как учесть рассмотренные в этой главе проблемы безопасности в только что инсталлированной Linux-системе? Проверьте, все ли проблемы решены в Linux- системах вашей компьютерной лаборатории. (Необходим доступ с правами поль- зователя root.) 14.7. Аж Какие действия необходимо предпринять для подключения нового компью- тера к сети в вашей лаборатории? В ответе используйте параметры конкретной среды. Предполагается, что на новом компьютере уже установлена операционная система Linux. 14.8. ★★ Приведите текст конфигурационного файла DHCP-сервера, который выде- ляет адреса в диапазоне 128.138.192.[ 1 -55]. Задайте срок аренды равным двум ча- сам и сделайте так, чтобы узел с МАС-адресом 00:10:5А:С7:4В:89 всегда получал IP- адрес 128.138.192.55.
Глава 15 Маршрутизация Управление потоками данных — непростая задача. В главе 14 вкратце рассказывалось о перенаправлении IP-пакетов. В настоящей главе мы подробнее изучим этот процесс и познакомимся с различными сетевыми протоколами, благодаря которым маршрутизато- ры автоматически находят наиболее эффективные маршруты. Эти протоколы принима- ют на себя основную нагрузку по управлению таблицами маршрутизации, существенно упрощая задачу администраторам. Они также позволяют быстро перенаправлять трафик в случае выхода из строя маршрутизатора или сетевого сегмента. Важно отличать реальное перенаправление IP-пакетов от управления таблицей марш- рутизации, хотя в обоих случаях употребляют один и тот же термин — “маршрутизация”. Перенаправление пакетов — простая процедура, тогда как вычисление маршрутов про- исходит по довольно запутанному алгоритму. Мы познакомимся только с одноадресной маршрутизацией, так как при многоадресной (когда пакеты направляются группе под- писчиков) возникает ряд новых проблем, рассмотреть которые, учитывая объем книги, не представляется возможным. Для того чтобы составить правильное представление о маршрутизации, в большин- стве случаев достаточно информации, изложенной в главе 14 “Сети TCP/IP”. Если се- тевая инфраструктура уже налажена, можно просто задать единственный статический маршрут (как описано в разделе 14.5 “Маршрутизация”) и все готово — у вас есть ин-? формация обо всем Интернете. Если же вы стремитесь справиться с сетью, имеющей сложную топологию, или используете операционные системы UNIX или Linux как часть своей сетевой инфраструктуры, тогда эта глава о протоколах и инструментах динамиче- ской маршрутизации окажется полезной для вас. В основе маршрутизации лежит принцип нахождения “следующего перехода”. В лю- бой конкретной точке требуется определить только следующий узел или маршрутизатор,
глава л 5. Маршрутизация 559 куда будет отправлен пакет на пути к пункту назначения. Это в корне отличается от многих старых протоколов, где перед отправкой пакета в сеть требовалось задать точный его маршрут (принцип маршрутизации “от источника”)1. 15.1. Подробнее о маршрутизации пакетов Прежде чем приступать к изучению алгоритмов маршрутизации, рассмотрим под- робнее, как используются таблицы маршрутизации. Предположим, сеть имеет тополо- гию, изображенную на рис. 15.1. Маршрутизатор R1 соединяет две сети, а маршрутизатор R2 — одну из этих сетей с внешним миром. Пока будем считать, что R1 и R2 — универсальные компьютеры, а не специализированные маршрутизаторы. (Во всех приводимых примерах предполагается использование операционной системы Linux и протокола IPv4, но в системе UNIX и в протоколе IPv6 используются похожие команды и принципы.) Посмотрим, как выгля- дят таблицы маршрутизации и некоторые конкретные сценарии перенаправления паке- тов. Таблица узла А выглядит следующим образом. А% netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 199.165.145.0 0.0.0.0 255.255.255.0 U 00 0 ethO 127.0.0.0 0.0.0.0 255.0.0.0 U 00 0 lo °.0.0.0 199.165.145.24 0.0.0.0 UG 00 0 ethO СЗ Более подробная информация о команде ifconfig приведена в разделе 14.9. Узел А имеет самую простую конфигурацию среди всех четырех компьютеров. Первые Два маршрута описывают собственные сетевые интерфейсы узла. Они необходимы, что- бы пакеты, направляемые непосредственно в подключенные сети, не маршрутизирова- лись особым образом. Устройство ethO — это Ethemet-интерфейс узла А, а 1о — интер- фейс обратной связи (виртуальный сетевой интерфейс, эмулируемый ядром). Обычно такие записи автоматически добавляются командой ifconfig при конфигурировании сетевого интерфейса. Некоторые системы интерпретируют “маршрут обратной связи” как узловой марш- рут к конкретному IP-адресу, а не ко всей сети. Поскольку 127.0.0.1 — это единственный 1 Теоретически IP-пакеты также можно отправлять, выполняя маршрутизацию от источника, Но Зто почти никогда не делается. Из соображений безопасности, подобный режим чаще всего не- доступен.
560 Часть II. Работав сети IP-адрес, существующий в сети обратной связи, по существу, неважно, как именно он определен. Единственные изменения, которые можно заметить в таблице маршрутиза- ции, заключаются в том, что в столбце Destination вместо адреса 127.0.0.0 будет стоять адрес 127.0.0.1, а в столбце Flags — буква Н. Ш Сетевые маски обсуждаются в разделе 14.4. Между узловым и сетевым маршрутами нет принципиальной разницы. Когда ядро операционной системы просматривает таблицу маршрутизации, они интерпретируются совершенно одинаково; единственное различие состоит в том, что они имеют разную длину неявной маски. Стандартный маршрут узла А задает перенаправление всех пакетов, не адресованных интерфейсу обратной связи или сети 195.165.145, на маршрутизатор R1, адрес которого в данной сети — 199.165.145.24. Флаг G указывает на то, что данный маршрут ведет к шлю- зу, а не к одному из локальных интерфейсов узла А. Шлюзы должны находиться на рас- стоянии одного перехода. 03 Различным типам адресации посвящен раздел 14.3. Предположим теперь, что узел А посылает пакет узлу В с адресом 199.165.146.4. IP- подсистема ищет маршрут к сети 199.165.146 и, не найдя такового, отправляет пакет по стандартному маршруту, т.е. маршрутизатору R1. На рис. 15.2 приведена структура па- кета, проходящего по сети Ethernet (в заголовке Ethernet указаны МАС-адреса соответ- ствующих интерфейсов компьютеров А и R1 в сети 145). От: А Кому: R1 Тип: IP От: 199.165.145.17 Кому: 199.165.146.4 Tun:UDP U001010U010101110101011Q1I0101 01110110110111010100010100100010 OlQllMlOllOlOlOlOJOOUlOlOlOOOO Рис. 15.2. Ethemet-пакет Целевой аппаратный Ethernet-адрес соответствует маршрутизатору R1, но 1Р-пакет, скрытый в Ethemet-фрейме, не содержит никаких упоминаний о маршрутизаторе. Когда маршрутизатор просматривает поступивший пакет, он обнаруживает, что не является его получателем. Тогда он обращается к собственной таблице маршрутизации, чтобы узнать, как переслать пакет узлу В, не переписывая его IP-заголовок (необходимо, чтобы отпра- вителем пакета оставался узел А). Таблица маршрутизации узла R1 выглядит следующим образом. Rl% netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 199.165.145.0 0.0.0.0 255.255.255.0 U 0 0 0 ethO 199.165.146.0 0.0.0.0 255.255.255.0 U 0 0 0 ethl 0.0.0.0 199.165.146.3 0.0.0.0 UG 0 0 0 ethl
Глава 15. Маршрутизация 56$ Она Почти аналогична таблице узла А, за исключением того, что здесь присутству- ет два физических сетевых интерфейса. Стандартный маршрут в данном случае ведет к узлу R2, пЬскольку через него осуществляется выход в Интернет. Пакеты, адресованные любой из сетей 199.165, доставляются напрямую. Подобно узлу А, узел В имеет один реальный сетевой интерфейс. Но для корректного функционирования ему необходим дополнительный маршрут, поскольку узел имеет пря- мое соединение сразу с двумя маршрутизаторами. Трафик сети 199.165.145 должен прохо- дить через узел R1, а весь остальной трафик — направляться в Интернет через узел R2. В% netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 u 0 0 0 lo 199.165.145.0 199.165.146.1 255.255.255.0 и 0 0 0 ethO 199.165.146.0 0.0.0.0 255.255.255.0 и 0 0 0 ethO 0.0.0.0 199.165.146.3 0.0.0.0 UG 0 0 0 ethO CQ Описание протокола ICMP приведено в разделе 14.5. Как и узел А, узел В можно сконфигурировать так, чтобы изначально он “знал” толь- ко об одном шлюзе, полагаясь на помощь директив переадресации протокола ICMP для устранения избыточных переходов. Ниже показан пример начальной конфигурации. В% netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 00 0 lo 199.165.146.0 0.0.0.0 255.255.255.0 U 00 0 ethO 0.0.0.0 199.165.146.3 0.0.0.0 UG 00 0 ethO Теперь, если узел В посылает пакет узлу А (199.165.145.17), прямой маршрут найден не будет, и пакет отправится на узел R2. Поскольку узел R2 является маршрутизатором, он имеет полную информацию о состоянии сети и, следовательно, “знает” о роли узла R1, куда и будет послан пакет. Кроме того, маршрутизатор R2 обнаружит, что узлы R1 и В находятся в одной сети, поэтому он дополнительно направит узлу В ICMP-сообщение, в соответствии с которым узел В добавит в свою таблицу маршрутизации прямой марш- рут к узлу А. 199.165.145.17 199.165.146.1 255.255.255.255 UGHD 00 0 ethO Благодаря этому маршруту весь трафик, адресованный узлу А, начнет идти непосред- ственно через маршрутизатор R1. Однако это изменение не затрагивает трафик к другим узлам в сети 145. Для них нужно получить отдельные директивы от маршрутизатора R2. Некоторые администраторы выбирают для своих систем директивы переадресации про- токола ICMP в качестве основного “протокола” маршрутизации, думая, что подобный под- ход обеспечит большую динамичность. К сожалению, системы и маршрутизаторы осущест- вляют перенаправление по-разному. Некоторые хранят эти директивы постоянно. Другие Удаляют их из таблицы маршрутизации через относительно короткое время (5—15 минут). Третьи вообще игнорируют их, что, вероятно, правильно с точки зрения безопасности. 15.2. Демоны и протоколы маршрутизации В простейших сетях, подобно той, которая представлена на рис. 15.1, целесообразно настраивать маршрутизацию вручную. Однако с определенного момента сети становят-
562 Часть II. Работа в сети ся слишком сложными для подобного администрирования. Вместо того чтобы явно со- общать каждому компьютеру, как находить другие компьютеры и сети, лучше заставить сами компьютеры искать эту информацию. Данная задача возлагается на протоколы маршрутизации и демоны, которые их реализуют. Основное преимущество протоколов маршрутизации над системами статической маршрутизации заключается в том, что они позволяют быстро адаптироваться к изме- нениям в топологии сети. Когда пропадает канал связи, демоны быстро находят альтер- нативные маршруты, если они существуют, и сообщают о них в сети, связанные с этим каналом. Демоны маршрутизации собирают информацию из трех источников: конфигураци- онных файлов, существующих таблиц маршрутизации и “родственных” демонов других систем. Собранные данные объединяются, и вычисляется оптимальный набор маршру- тов, после чего новые маршруты записываются в системную таблицу (и при необходимо- сти посылаются другим системам посредством протоколов маршрутизации). Состояние сети время от времени меняется, поэтому демоны должны периодически опрашивать друг друга, чтобы убедиться в актуальности имеющейся у них информации. Конкретный алгоритм вычисления маршрутов зависит от протоколов. Последние бывают двух типов: дистанционно-векторные и топологические. Дистанционно-векторные протоколы В основе дистанционно-векторных протоколов лежит следующая идея: если маршру- тизатор X находится в пяти переходах от сети Y и является моим соседом, то я нахожусь в шести переходах от данной сети. Демон, работающий по такому протоколу, объявля- ет о том, как далеко, по его расчетам, расположены известные ему сети. Если сосед- ние демоны не “знают” более коротких маршрутов к этим сетям, они помечают данный компьютер как оптимальный шлюз. В противном случае они просто игнорируют этот анонс. Предполагается, что со временем таблицы маршрутизации придут в стабильное состояние. Это довольно красивая идея, и если бы все работало так, как задумано, маршрути- зация существенно упростилась бы. К сожалению, описанный алгоритм не лучшим об- разом справляется с изменениями топологии.2 Иногда стабилизация таблиц вообще не наступает вследствие возникновения бесконечных циклов (например, маршрутизатор X получает информацию от маршрутизатора Y и посылает ее маршрутизатору Z, кото- рый возвращает ее маршрутизатору Y). На практике приходится вводить сложные эв- ристические правила или задавать ограничения. К примеру, в протоколе RIP (Routing Information Protocol — протокол маршрутной информации) считается, что любая сеть, находящаяся на расстоянии более пятнадцати переходов, недоступна. Даже в обычных ситуациях может потребоваться слишком много циклов обновлений, прежде чем все маршрутизаторы перейдут в стабильное состояние. Следовательно, чтобы не превысить допустимые пределы, необходимо сделать периоды обновлений короткими, а это, в свою очередь, ведет к тому, что дистанционно-векторные протоколы оказываются слишком “словоохотливыми”. Например, протокол RIP требует, чтобы маршрутизаторы осуществляли широковещательную рассылку всей имеющейся у них информации каж- дые 30 секунд. В протоколе EIGRP обновления анонсируются каждые 90 секунд. 2 Проблема заключается в том, что изменения топологии могут приводить к удлинению суще- ствующих маршрутов. Некоторые дистанционно-векторные протоколы, например EIGRP, хранят информацию о всех возможных маршрутах, чтобы на крайний случай был “план отступления”. Впрочем, конкретные детали не так уж важны.
Глава 15. Маршрутизация 563 В противоположность этому в протоколе BGP (Border Gateway Protocol — протокол пограничного шлюза) вся таблица посылается один раз, после чего изменения распро- страняются по мере возникновения. Такая оптимизация позволяет существенно снизить “переговорный” трафик (большей частью, ненужный). В табл. 15.1 перечислены дистанционно-векторные протоколы, широко используе- мые в настоящее время. Таблица 15.1. Распространенные дистанционно-векторные протоколы маршрутизации Аббре- виатура Полное название ” ’’ ''Л.: . ч‘ '.’'j*? - S -»f"л RIP Routing Information Protocol (протокол маршрутной ин- формации) Локальные сети RIPng Routing Information Protocol (протокол маршрутной ин- формации), следующее поколение Локальные сети с протоколом IPv6 EIGRPа Enhanced Interior Gateway Routing Protocol (улучшенный протокол маршрутизации внутреннего шлюза) Глобальные сети, корпоративные локальные сети BGP Border Gateway Protocol (протокол пограничного шлюза) Магистральные сети Интернета а Протокол EIGRP является собственностью компании Cisco. Топологические протоколы В топологических протоколах, или протоколах состояния канала, информация рассыла- ется в относительно необработанном виде. Записи выглядят примерно так: “Маршр^ратор X является смежным по отношению к маршрутизатору Y, и канал функционирует”. Полный набор таких записей образует карту сетевых связей, на основании которой каждый марш- рутизатор может сформировать собственную таблицу. Основное преимущество тополоЙ^^ ских протоколов, по сравнению с дистанционно-векторными, заключается в способного® быстро стабилизировать таблицы маршрутизации в случае непредвиденного сбоя. К из- держкам относится необходимость хранения полной карты соединений на каждом узле, для чего требуются дополнительные процессорные мощности и память. Поскольку процесс общения между маршрутизаторами не является частью собствен- но алгоритма вычисления маршрутов, появляется возможность реализовать топологи- ческие протоколы так, чтобы не возникало циклов. ШдаШййя в топологической базе данных распространяются по сети очень быстро, не перетр^^ни канал, ни централь- ный процессор. Топологические протоколы сложнее дистанционно-векторных, зато они позволяют ре- ализовать такие технологии, как маршрутизация на основании запрашиваемого типа об- служивания (поле TOS IP-пакета) и поддержка нескольких маршрутов к одному адресату. Распространение получили только два топологических протокола: OSPF и IS-IS. Несмотря на то что протокол IS-IS был реализован в широких масштабах, он не так ча- сто используется, и мы не рекомендуем его для использования в новых сетях. Дополни- тельные комментарии, касающиеся протокола IS-IS, приведены в этом разделе далее. Метрики стоимости Для того чтобы протокол маршрутизации мог определить, какой путь к заданной сети является кратчайшим, необходимо прежде всего выяснить, что значит “кратчайший”. Это путь с наименьшим числом переходов? С наименьшей задержкой? С наименьшими финансовыми затратами?
564 Часть II. Работа в сети Для целей маршрутизации качество канала связи определяется числом, называемым метрикой стоимости. Путем сложения метрик отдельных отрезков пути вычисляется общая стоимость маршрута. В простейших системах каждому каналу назначается стои- мость 1, и в результате метрикой маршрута становится число переходов. Но любой из перечисленных выше критериев может являться метрикой стоимости. Эксперты в области сетей долго и упорно трудились над тем, чтобы определение такого понятия, как метрика стоимости, было максимально гибким, а некоторые со- временные протоколы даже позволяют использовать разные метрики для разных видов сетевого трафика. Тем не менее в 99% случаев на все это можно не обращать внимания. Для большинства систем вполне подойдут стандартные метрики. Бывают ситуации, когда кратчайший физический маршрут к адресату не должен быть выбран по умолчанию из административных соображений. В таких случаях можно ис- кусственно завысить метрики критических каналов. Всю остальную работу предоставьте демонам. Внутренние и внешние протоколы Автономная система — это группа сетей, находящихся под административным или политическим контролем одного юридического лица. Такое определение довольно рас- плывчато. Реальные автономные системы могут представлять собой как глобальные корпоративные сети, так и сети университетов или даже отдельных факультетов. Все зависит от того, как осуществляется маршрутизация. Сейчас наблюдается тенденция к укрупнению автономных систем. Это упрощает администрирование и повышает эф- фективность маршрутизации. Маршрутизация внутри автономной системы отличается от маршрутизации между такими системами. Протоколы второго типа (внешние, или протоколы внешних шлю-, зов) должны управлять множеством маршрутов к различным сетям и учитывать тот факт, что соседние маршрутизаторы находятся под контролем других людей. Внешние пропь колы не раскрывают топологию автономной системы, поэтому в определенном смыслу их можно рассматривать как второй уровень маршрутизации, на котором соединяются группы сетей, а не отдельные компьютеры или кабели. На практике небольшим и среднего размера организациям редко требуется внешний протокол, если только они не подключены к нескольким провайдерам одновременно.. При наличии нескольких провайдеров традиционное разделение на локальный домен и домен Интернета нарушается, поскольку маршрутизаторам приходится определять, какой маршрут в Интернете лучше всего подходит для конкретного адреса. (Это не означает, что каждый маршрутизатор должен знать всю необходимую информацию. Большинство узлов может направлять свои пакеты внутреннему шлюзу, хранящему необходимые сведения.) Поскольку внешние протоколы не сильно отличаются от своих внутренних аналогов, в этой главе мы сосредоточим внимание на внутренних протоколах и демонах, которые их поддерживают. Если ваш сайт поддерживает внешний протокол, обратитесь к литера- турным источниками, ссылки на которые приведены в конце главы. 15.3. Основные протоколы маршрутизации В этом разделе мы познакомимся с основными внутренними протоколами маршру- тизации, узнаем их преимущества и недостатки.
глава 15. маршрутизация 565 Протоколы RIP и RIPng RIP (Routing Information Protocol — протокол маршрутной информации) — это старый протокол компании Xerox, адаптированный для IP-сетей. Его IP-версия была описана примерно в 1988 году в документе RFC 1058. Существует три версии этого про- токола: RIPvl, RIPv2 и RIPng только для протокола IPv6 (ng (next generation) означает “следующее поколение”). Все версии этого протокола представляют собой простые дистанционно-векторные протоколы, метрикой стоимости в которых является количество переходов. Поскольку протокол RIP разрабатывался в те времена, когда отдельные компьютеры были доро- гими, а сети маленькими, в версии RIPvl предполагается, что все узлы, находящиеся на расстоянии пятнадцати и более переходов, недоступны. В более поздних версиях это ограничение не было снято, чтобы стимулировать администраторов сложных сетей пе- реходить на более сложные протоколы маршрутизации. Ш Информация о бесклассовой адресации, известной под именем CIDR, приведена в раз- деле 14.4. Протокол RIPv2 — это улучшенная версия протокола RIP, в которой вместе с адресом следующего перехода передается сетевая маска. Это упрощает управление сетями, где есть подсети и применяется протокол CIDR, по сравнению с протоколом RIPvl. В нем была также предпринята невнятная попытка усилить безопасность протокола RIP. Протокол RIPv2 можно выполнять в режиме совместимости. Это позволяет сохра- нить большинство его новых функциональных возможностей, не отказываясь от по- лучателей, использующих простой протокол RIP. Во многих аспектах протокол RIPv2 идентичен исходному протоколу и отдавать предпочтение следует именно ему. Ш Детали протокола IPv6 приведены в разделе 14.2. Протокол RIPng представляет собой переформулирование протокола RIP в терминах протокола IPv6. Он может использоваться только в рамках протокола IPv6, в то время как протокол RIPv2 — только в рамках протокола IPv4. Если вы хотите использовать как протокол IPv4, так и протокол IPv6 вместе с протоколом RIP, то RIP и RIPng необходи- мо выполнять как отдельные протоколы. Несмотря на то что протокол RIP известен своим расточительным использованием широковещательного режима, он весьма эффективен при частых изменениях сети, а также в тех случаях, когда топология удаленных сетей неизвестна. Однако после сбоя канала он может замедлить стабилизацию системы. Сначала исследователи были уверены, что появление более сложных протоколов маршрутизации, таких как OSPF, сделает протокол RIP устаревшим. Тем не менее про- токол RIP продолжает использоваться, потому что он простой, легкий в реализации и не требует сложного конфигурирования. Таким образом, слухи о смерти протокола RIP оказались слишком преувеличенными. Протокол RIP широко используется на платформах, не использующих операцион- ную систему UNIX. Многие устройства, включая сетевые принтеры и сетевые управляе- мые SNMP-компоненты, способны принимать RIP-сообщения, узнавая о возможных сетевых шлюзах. Кроме того, почти во всех версиях систем UNIX и Linux в той или иной форме существует клиент протокола RIP. Таким образом, протокол RIP считается “наименьшим общим знаменателем” протоколов маршрутизации. Как правило, он при- меняется для маршрутизации в пределах локальной сети, тогда как глобальную маршру- тизацию осуществляют более мощные протоколы.
566 Часть II. Работа в сети Некоторые сайты запускают пассивных демонов протокола RIP (обычно демон routed или ripd из пакета Quagga), которые ожидают сообщений об изменениях в сети, не осу- ществляют широковещательную рассылку собственной информации. Реальные вы- числения маршрутов выполняются с помощью более производительных протоколов, таких как OSPF (см. следующий раздел). Протокол RIP используется только как меха- низм распространения. Протокол OSPF OSPF (Shortest Path First Open — открытый протокол первоочередного обнаруже- ния кратчайших маршрутов) является самым популярным топологическим протоко- лом. Термин “первоочередное обнаружение кратчайших маршрутов” (shortest path first) означает специальный математический алгоритм, по которому вычисляются маршруты; термин “открытый” (open) — синоним слова “непатентованный”. Основная версия про- токола OSPF (версия 2) определена в документе RFC2328, а расширенная версия прото- кола OSPF, поддерживающая протокол IPv6 (версия 3), — в документе RFC5340. Первая версия протокола OSPF устарела и сейчас не используется. OSPF — протокол промышленного уровня, который эффективно функционирует в крупных сетях со сложной топологией. По сравнению с протоколом RIP, он имеет ряд преимуществ, включая возможность управления несколькими маршрутами, ведущими к одному адресату, и возможность разделения сети на сегменты (“области”), которые бу- дут делиться друг с другом только высокоуровневыми данными маршрутизации. Сам про- токол очень сложный, поэтому имеет смысл использовать его только в крупных систе- мах, где важна эффективность маршрутизации. Для эффективного использования про- токола OSPF необходимо, чтобы ваша схема адресации имела иерархический характер. В спецификации протокола OSPF не навязывается конкретная метрика стоимости. По умолчанию в реализации этого протокола компанией Cisco в качестве метрики ис- пользуется пропускная способность сети. Протокол EICRP EIGRP (Enhanced Interior Gateway Routing Protocol — протокол маршрутизации вну- тренних шлюзов) — это патентованный протокол маршрутизации, используемый толь- ко маршрутизаторами компании Cisco. Протокол IGRP был разработан для устранения некоторых недостатков протокола RIP еще в те времена, когда не было такого надеж- ного стандарта, как протокол OSPF. Протокол IGRP был отклонен в пользу протоко- ла EIGRP, который допускает произвольные сетевые маски CIDR. Протоколы IGRP и EIGPR конфигурируются одинаково, несмотря на различия в их организации. Протокол EIGRP поддерживает протокол IPv6, но в нем, как и во всех других про- токолах маршрутизации, адресные пространства IPv6 и IPv4 конфигурируются отдельно и существуют как параллельные домены маршрутизации. Протокол EIGRP является дистанционно-векторным, но он спроектирован так, что- бы избежать проблем зацикливания и медленной стабилизации, свойственных другим протоколам данного класса. В этом смысле протокол EIGRP считается образцом. Для большинства применений протоколы EIGRP и OSPF обеспечивают равные функцио- нальные возможности.
Глава 15. Маршрутизация 567 IS—IS: протокол маршрутизации между промежуточными системами Протокол IS-IS (Intra-domain Intermediate System to Intermediate System Routing Pro- tocol) является ответом на протокол OSPF со стороны организации ISO. Первоначально он предназначался для маршрутизации в рамках сетевых протоколов OSI, но впослед- ствии был расширен для поддержки 1Р-маршрутизации. Оба протокола — IS-IS и OSPF — создавались в начале 90-х годов, когда протоколы организации ISO преднамеренно хранились в тайне. Благодаря усилиям со стороны ор- ганизации IETF, протокол IS-IS получил видимость законности, но со временем стал все сильнее уступать в популярности протоколу OSPF и сегодня используется редко. В на- стоящее время из-за множества ненужных функциональных особенностей, заложенных в него организацией ISO, лучше его избегать. Протоколы RDP и NDP Протокол RDP (Router Doscoveiy Protocol — протокол обнаружения маршрутизаторов) использует ICMP-сообщения, посылаемые по групповому IP-адресу 224.0.0.1, для распро- странения информации о других маршрутизаторах в сети. К сожалению, не все маршрути- заторы в настоящее время рассылают такие сообщения, и не все компьютеры могут их при- нимать. Остается надеяться, что когда-нибудь этот протокол станет более популярным. Ш Информация о протоколе ARP приведена в разделе 14.6. Протокол NDP (Neighbor Discovery Protocol — протокол обнаружения соседнего узла), основанный на протоколе IPv6, объединяет функциональные возможности про- токолов RDP и ARP (Address Resolution Protocol — протокол разрешения адреса), ис- пользуемых для отображения адресов IPv4 в адреса аппаратных устройств в локальных сетях. Поскольку этот протокол является основным компонентом протокола IPv6, он используется там, где используется протокол IPv6, и протоколы маршрутизации в рам- ках протокола IPv6 основаны именно на нем. Протокол BGP Протокол BGP (Border Gateway Protocol — протокол пограничной маршрутизации) является протоколом внешней маршрутизации, т.е. он управляет трафиком между ав- тономными системами, а не между отдельными сетями. Существовало несколько попу- лярных протоколов внешней маршрутизации, но протокол BGP пережил их всех. В настоящее время BGP является стандартным протоколом, используемым для ма- гистральной маршрутизации в Интернете. В средине 2010 года таблица маршрутизации Интернета содержала около 320 тыс. префиксов. Совершенно очевидно, что это мас- штаб, при котором магистральная маршрутизация существенно отличается от локальной. 15.4. Выбор стратегии маршрутизации Существует четыре уровня сложности, характеризующих процесс управления марш- рутизацией в сети: • отсутствие маршрутизации как таковой; • только статическая маршрутизация;
568 Часть II. Работа в сети • преимущественно статическая маршрутизация, но клиенты принимают RIP- обновления; • динамическая маршрутизация. Общая топология сети существенно влияет на маршрутизацию каждого конкретно- го сегмента. В различных сетях могут требоваться совершенно разные уровни поддерж- ки маршрутизации. При выборе стратегии следует руководствоваться перечисленными ниже эмпирическими правилами. • Автономная сеть не нуждается в маршрутизации. • Если из сети есть только один выход во внешний мир, клиенты сети (нешлюзовые узлы) должны иметь стандартный статический маршрут к этому шлюзу. Никакой другой конфигурации не требуется, кроме как на самом шлюзе. • Можно задать явный статический маршрут к шлюзу, ведущему в небольшую груп- пу сетей, и стандартный маршрут к шлюзу, ведущему во внешний мир. Однако динамическая маршрутизация предпочтительнее, если до нужной сети можно до- браться разными маршрутами. • Если сети пересекают государственные или административные границы, следует использовать динамическую маршрутизацию, даже если сложность сетей этого не требует. • Протокол RIP отлично работает и широко используется. Не отказывайтесь от него просто потому, что он имеет репутацию устаревшего протокола. • Проблема протокола RIP заключается в том, что его невозможно масштабировать до бесконечности. Расширение сети рано или поздно приведет к отказу от него. Из-за этого протокол RIP считается промежуточным протоколом с узкой обла- стью применения. Эта область ограничена с одной стороны сетями, которые явля- ются слишком простыми, чтобы применять в них какой-либо протокол маршру- * тизации, а с другой стороны — сетями, которые являются слишком сложными для ; протокола RIP. Если вы планируете расширять свою сеть, то было бы целесообраз- ? но игнорировать протокол RIP вообще. • Даже если протокол RIP не соответствует вашей стратегии глобальной маршру-) тизации, он остается хорошим способом распределения маршрутов к концевым 5 узлам. Однако его не следует применять без особой надобности: системы в сети, j имеющей только один шлюз, никогда не требуют динамического обновления. < • Протоколы EIGRP и OSPF имеют одинаковые функциональные возможности, но j протокол EIGRP является собственностью компании Cisco. Компания Cisco дела- > ет прекрасные и оптимальные по соотношению “цена-качество” маршрутизаторы; : тем не менее стандартизация протокола EIGRP ограничивает ваши возможности будущего расширения. Маршрутизаторы, подключенные к магистрали Интернета, должны использовать протокол BGP. Обычно большинство маршрутизаторов имеет только один вход и, сле- довательно, для них достаточно задать простой статический стандартный маршрут. Для организации среднего размера с относительно стабильной локальной структу- рой, где есть выход в другую сеть, подойдет сочетание статической и динамической маршрутизаций. Маршрутизаторы локальной сети, которые не являются шлюзами во внешние сети, могут использовать статическую маршрутизацию, направляя все неиз- вестные пакеты стандартной машине, способной общаться с внешним миром и выпол- нять динамическую маршрутизацию.
глава 15. Маршрутизация 569 Сеть, управлять которой по такой схеме было бы слишком сложно, должна основы- ваться на динамической маршрутизации. В концевых сетях (leaf nets) по-прежнему мож- но использовать стандартные статические маршруты, но компьютеры в сетях с более чем одним маршрутизатором должны запускать демон routed в пассивном режиме. 15.5. Демоны маршрутизации Мы не рекомендуем использовать системы UNIX и Linux в качестве маршрутизато- ров в производственных сетях. Специализированные маршрутизаторы проще, надежнее, безопаснее и более быстродействующие (даже если они скрытно запускают ядро системы Linux). Иначе говоря, очень хорошо иметь возможность организовать новую подсеть, ис- пользуя всего лишь сетевую карту стоимостью 15 долл, и коммутатор за 40 долл. Это впол- не разумный подход к организации разреженных, тестовых и вспомогательных сетей. Системы, действующие как шлюзы в таких подсетях, не требуют дополнительных инструментов для управления их собственными таблицами маршрутизации. Статические маршруты вполне адекватны как для машин, используемых в качестве шлюзов, так и для машин, представляющих собой узлы самой подсети. Однако если вы хотите, чтобы ваша подсеть была доступной для других сетей в вашей организации, вам необходимо сооб- щить о ее существовании и идентифицировать маршрутизатор, к которому будут при- вязаны пакеты, посылаемые данной подсети. Обычно для этого на шлюзе запускается демон маршрутизации. Системы UNIX и Linux могут участвовать в большинстве протоколов маршрутизации с помощью различных демонов маршрутизации. Важным исключением из этого правила является протокол EIGRP, который, насколько нам известно, не имеет широко доступ- ной реализации в системах UNIX и Linux. Поскольку демоны маршрутизации редко реализуются в производственных систе- мах, мы не будем подробно описывать их использование и конфигурацию. Тем не менее в следующих разделах мы приведем краткое описание типичных программ и укажем, где искать детали конфигурации. Демон route: устаревшая реализация в протоколе RIP Долгое время демон routed был стандартным демоном маршрутизации, и его до сих пор включают в дистрибутивы некоторых систем. Демон routed понимает только протокол RIP и при этом плохо: даже поддержка версии RIPv2 не поправила ситуацию. Демон routed не понимает протокол RIPng, реализация которого основана на совре- менных демонах, таких как Quagga и ramd в системе HP-UX. Демон routed целесообразно использовать в пассивном режиме (-q), в котором он принимает сообщения об обновлениях маршрутов, но не осуществляет широковещатель- ную рассылку собственных сообщений. Кроме указания опций в командной строке, демон routed не требует конфигурирования. Он представляет собой дешевый и простой способ получения сообщений об обновлениях маршрутов без сложного конфигурирования. Демон заносит обнаруженные маршруты в таблицу ядра. Все маршруты долж- ны анонсироваться, как минимум, каждые четыре минуты, иначе они будут удалены. Правда, демон route помнит, какие маршруты он добавлял, и не удаляет статические маршруты, заданные с помощью команды route. СЭ Команда route описана в разделе 14.9.
570 Часть II. Работа в сети демон gated: первый многопротокольный демон маршрутизации Демон gated — элегантная и легко доступная программа маршрутизации, позволяю- щая одновременно использовать несколько протоколов маршрутизации. Он предостав- ляет администратору полный контроль над анонсированными маршрутами, широкове- щательными адресами, правилами безопасности и метриками стоимости. Демон gated разрешает нескольким протоколам использовать одни и те же маршруты, позволяя тем самым создавать шлюзы между автономными областями, в которых приняты разные си- стемы маршрутизации. Наконец, демон gated имеет один из самых удобных командных интерфейсов и форматов файлов конфигурации среди всего административного про- граммного обеспечения. Увы, демон gated мертв (или, по крайней мере, при смерти), хотя память о нем еще живет в выпусках систем HP-UX 3.5.9 и AIX 6.0, которые вообще медленно реагируют на происходящие изменения. Демон gated представляет собой поучительный пример риска, с которым связаны попытки разрабатывать открытое программное обеспечение. Он задумывался как сво- бодно распространяемая программа, но в 1992 году был приватизирован и переделан консорциумом по разработке программ; в результате его обновления стали доступными только членам этого консорциума. В конце концов консорциум был расформирован, и права на коммерческую версию демона gated несколько раз “меняли” владельцев. Тем временем открытые проекты Zebra и Quagga вытеснили демон gated и сами стали играть ведущие роли в области открытых пакетов маршрутизации. В настоящее время демон gated угас и как коммерческий продукт, и как открытый проект. Печальный ко- нец полезного и хорошо спроектированного пакета. Пакет Quagga: основной демон маршрутизации Quagga (quagga. net) — это опытно-конструкторское подразделение проекта Zebra, выполняемого в рамках проекта GNU. Проект Zebra был запущен Кунихиро Ишигуро (Kunihiro Ishiguro) и Йошинари Йошикава (Yoshinari Yoshikawa) для реализации много- протокольной маршрутизации с помощью коллекции независимых демонов, а не одного монолитного приложения. В реальной жизни квагга (quagga) — это исчезнувший подвид зебры, которая была последний раз сфотографирована в 1870 году. Но его цифровая ре- инкарнация Quagga выжила, а проект Zebra закрылся. В настоящее время пакет Quagga реализует все протоколы RIP (все версии), OSPF (версии 2 и 3), BGP и IS-IS. Он выполняется в системах Linux, Solaris и разных вариан- тах системы BSD. В системе Solaris и версиях системы Linux, имеющихся в нашем рас- поряжении, пакет Quagga либо инсталлирован по умолчанию, либо доступен в качестве вспомогательного пакета, который можно загрузить из стандартного системного репози- тория программного обеспечения. В пакете Quagga демон zebra играет роль информационного центра для маршрути- зации. Он управляет взаимодействием между таблицей маршрутизации ядра и демона- ми, соответствующими отдельным протоколам маршрутизации (ripd, ripngd, ospfd, ospf 6d, bgpd и isisd). Кроме того, он управляет потоками информации о маршрутах, которыми обмениваются протоколы. Каждый демон имеет свой собственный конфигу- рационный файл в каталоге /etc/quagga. Для того чтобы послать запрос или изменить конфигурацию, можно соединиться с любым из демонов Quagga с помощью интерфейса командной строки (vtysh в системе
Глава 15. Маршрутизация 57а soians Linux и quaggaadm в системе Solaris). Командный язык разработан так, чтобы он был понятен пользователям операционной системы IOS компании Cisco; дополнительные детали можно найти в разделе 15.6, посвященном маршрутизаторам Cisco. Как и в си- стеме IOS, для того чтобы войти в режим “суперпользователя”, необходимо выполнить команду enable, для того чтобы ввести команды конфигурирования, необходимо вы- полнить команду config term, а для того чтобы сохранить изменения конфигурации в файле конфигурации демона, необходимо выполнить команду write. Официальная документация доступна на сайте quagga. net в виде файлов в форма- тах HTML и PDF. Несмотря на свою полноту, эта документация содержит, в основном, удобный каталог опций, а не общий обзор системы. Более практичную документацию можно найти на сайте wiki. quagga.net. Здесь находятся подробно прокомментиро- ванные примеры файлов конфигурации, ответы на часто задаваемые вопросы и советы. Несмотря на то что файлы конфигурации имеют простой формат, необходимо знать протокол, конфигурацию которого вы настраиваете, а также понимать, что означают те или иные опции. Список рекомендованной литературы по этому вопросу приведен в конце главы. Системы Solaris и Red Hat содержат в каталоге /ets/quagga/ кол- лекцию полезных примеров файла конфигурации для разных демо- нов Quagga. Демон ramd: многопротокольная система маршрутизации для HP-UX Система HP-UX содержит набор демонов маршрутизации, которые по своей архитектуре напоминают демонов Zebra и Quagga. Мы не знаем, можно ли объяснить эту схожесть подражанием, конвергентной эволюцией или, воз- можно, ранним ответвлением от основного кода проекта Zebra. В любом случае эта схожесть носит лишь поверхностный характер. Важным различи- ем является то, что система HP поддерживает только протокол IPv6 и протоколы внеш- ней маршрутизации (RIPng, BGP и IS-IS), но вообще не поддерживает протокол OSPF. Кроме того, язык конфигурации отличается от базового, а управляющая утилита (rdc, в отличие от утилит vtysh или quaggaadm пакета Quagga) принимает аргументы только из командной строки; она не имеет независимой интерфейсной оболочки. Эта подсистема системы HP называется Route Administration Manager Daemon, а ее демон ramd играет ту же роль, какую в пакете Quagga играет демон zebra. Как и в па- кете Quagga, демоны, соответствующие разным протоколам, называются ripngd, isisd и bgpd. Маршрутизатор XORP Проект XORP (extensible Open Router Platform — расширяемая платформа маршрути- зации с открытым кодом) был открыт примерно в то же время, что и проект Zebra, но его цели были более универсальными. Вместо маршрутизации, проект XORP был нацелен на эмулирование всех функций заданного маршрутизатора, включая фильтрацию пакетов и управление трафиком. Информация об этом проекте хранится на сайте xorp. org. Интересный аспект платформы XORP заключается в том, что она не только функци- онирует в разных операционных системах (Linux, разных версиях BSD, Mac OS X и Win- dows Server 2003), но и может запускаться непосредственно с “живого” компакт-диска (т.е. непосредственно с компакт-диска, без инсталляции на жесткий диск. — Примеч.
572 Часть II. Работа в сети ред.) на персональном компьютере. Этот “живой” компакт-диск (live CD) скрытно осно- ван на системе Linux, но он прошел долгую эволюцию и позволяет превращать типич- ный персональный компьютер в специализированное устройство для маршрутизации. Специфика поставщиков в Пакет Quagga — это лучшее программное обеспечение для маршрутизации в /А системе Linux. Все доступные нам дистрибутивы либо инсталлировали его по умолчанию, либо позволяли загружать его из репозитория. Пакет Quagga на- столько распространен, что большинство дистрибутивов больше не содержит демон routed. Даже в тех дистрибутивах, в которых он есть, содержится его устаревшая версия, не поддерживающая протокол RIPv2. Система Solaris содержит функционал routed (который на самом деле назы- soians вается in. routed), понимающий протокол RIPv2. Она также содержит пакет Quagga, поэтому вы можете выбирать. Для любой маршрутизации в рамках протокола IPv6 необходимо использовать пакет Quagga. Функционал in. routed представляет собой механизм маршрутизации, заданный по умолчанию. Он начинает работать автоматически в момент загрузки системы, если в каталоге /etc/defaultrouter пользователь не задал свой собственный шлюз сети. Система Solaris продолжает поддерживать демон поиска маршрутов (router discovery dae- mon) in. rdisc, что довольно странно, поскольку его функциональными возможностя- ми теперь обладает демон in. routed. fXfft Базовая подсистема маршрутизации ramd в системе HP-UX рассматривалась выше. Кроме того, система HP содержит также копию демона gated 3.5.9, которая является довольно старой и не поддерживает протокол IPv6. Если вы хотите управлять маршрутизацией одновременно в рамках протоколов IPv4 и IPv6 в системе HP-UX, то для протокола IPv4 следует использовать демон gated, а для протокола IPv6 — демон ramd. К сожалению, пакет Quagga в на- стоящее время в системе HP-UX не работает. ®В системе AIX есть три демона маршрутизации: gated v6.0, routed, понима- ющий только протокол RIPvl, и ndpd-router, представляющий собой реа- лизацию протоколов RIPng и NDP. Кроме того, демон gated в системе AIX понимает протокол RIPng. Однако если вы хотите использовать демон gated для маршрутизации в рамках протокола IPv6, необходимо запустить оба демо- на: gated и ndpd-router. Детали описаны в документации. 15.6. Маршрутизаторы Cisco Маршрутизаторы, выпускаемые компанией Cisco Systems, Inc., сегодня являются стандартом де-факто на рынке интернет-маршрутизаторов. Захватив более 60% рынка, компания Cisco добилась широкой известности своих продуктов, к тому же есть много специалистов, умеющих работать с этими устройствами. Раньше в качестве маршрутиза- торов часто приходилось использовать UNIX-системы с несколькими сетевыми интер- фейсами. Сегодня специализированные маршрутизаторы размещены в коммутационных шкафах и над подвесными потолками, где сходятся сетевые кабели. Большинство маршрутизаторов Cisco работает под управлением операционной сис- темы Cisco IOS, которая является собственностью компании и не имеет отношения к си-
Глава 15. Маршрутизация 579 '*Г стеме UNIX. У нее достаточно большой набор команд: полная бумажная документация занимает на полке почти полтора метра. Мы никогда не смогли бы полностью описать здесь эту операционную систему, но все же постараемся дать о ней основные сведения. По умолчанию в системе IOS определены два уровня доступа (пользовательский и при- вилегированный), каждый из которых включает механизм парольной защиты. По умол- чанию к маршрутизатору Cisco можно получить доступ на пользовательском уровне, вос- пользовавшись утилитой telnet. Вы получите приглашение на ввод пароля. $ telnet acme-gw.acme.com3 Connected to acme-gw.acme.com. Escape character is ,Л] ' . User Access Verification Password: После ввода правильного пароля появится приглашение интерпретатора ЕХЕС. ч acme-gw.acme.com> С этого момента можно начинать вводить команды, например show interfaces для отображения списка сетевых интерфейсов маршрутизатора или show ? для получения справки по возможным параметрам. Для того чтобы перейти в привилегированный режим, введите команду enable, а при последующем запросе — привилегированный пароль. Признаком привилегирован- ного режима является наличие символа ‘#’ в конце строки приглашения. acme-gw.acme.com# Будьте осторожны! В данном режиме можно делать все что угодно, включая удаление конфигурационной информации и даже самой операционной системы. Если сомневае- тесь, обратитесь к справочным руководствам по системе Cisco или одной из исчерпы- вающих книг, выпускаемых издательством Cisco Press. Команда show running позволяет узнать текущие динамические параметры маршру- тизатора, а по команде show config отображаются текущие неизменяемые параметры. В большинстве случаев оба набора данных идентичны. Вот типичная конфигурация. acme-gw. acme, с om# show running Current configuration: version 12.1 hostname acme-gw enable secret xxxxxxxx ip subnet-zero interface EthernetO description Acme internal network ip address 192.108.21.254 255.255.255.0 no ip directed-broadcast interface Ethernetl description Acme backbone network ip address 192.225.33.254 255.255.255.0 no ip directed-broadcast ip classless line con 0 3 Современные версии системы IOS поддерживают разные методы доступа, включая SSH. Ра- зумеется, утилита telnet очень опасна. Если ваша организация уже использует маршрутизаторы Cisco, свяжитесь с системным администратором и выясните, какие методы можно использовать.
574 Часть II. Работа в сети transport input none line aux 0 transport input telnet line vty 0 4 password xxxxxxxx login end Модифицировать конфигурацию маршрутизатора можно разными способами. Ком- пания Cisco предлагает графические утилиты, работающие в некоторых версиях UNIX/ Linux и Windows, но опытные сетевые администраторы никогда ими не пользуются. Их самый мощный “инструмент” — командная строка. Кроме того, с помощью команды scp можно загрузить с маршрутизатора его конфигурационный файл и отредактировать в лю- бимом текстовом редакторе, после чего снова записать файл в память маршрутизатора. Для того чтобы отредактировать конфигурационный файл в режиме командной стро- ки, введите команду config term. acme-gw.acme.com# config term Enter configuration commands, one per line. End with CNTL/Z. acme-gw(config)# Теперь можно вводить конфигурационные команды в том виде, в котором их будет отображать команда show running. Например, если требуется изменить IP-адрес ин- терфейса Ether net 0, введите следующее. interface EthernetO ip address 192.225.40.253 255.255.255.0 По окончании ввода конфигурационных команд нажмите <Ctrl+Z>, чтобы вернуть- ся к обычной командной строке. Если все прошло успешно, сохраните новую конфигу- рацию в постоянной памяти посредством команды write mem. Приведем несколько советов, касающихся эффективной работы с маршрутизаторами Cisco. • Присвойте маршрутизатору имя с помощью команды hostname. Это позволит из- бежать несчастных случаев, связанных с изменением конфигурации не того марш- рутизатора. Заданное имя всегда будет отображаться в командной строке. • Всегда храните резервную копию конфигурационного файла маршрутизатора. С помощью команд scp или tf tp можно каждую ночь пересылать текущую кон- фигурацию в другую систему на хранение. • Зачастую существует возможность хранить копию конфигурации в энергонезависи- мой памяти NVRAM или на переносном флеш-накопителе. Не пренебрегайте этим! • Сконфигурировав маршрутизатор для SSH-доступа, отключите протокол Telnet совсем. • Контролируйте доступ к командной строке маршрутизатора, создавая списки до- ступа для каждого порта VTY (аналогичен порту PTY в UNIX-системе). Это не по- зволит посторонним пользователям “взломать” маршрутизатор. • Управляйте трафиком между сетями (по возможности, и во внешний мир тоже), создавая списки доступа для каждого интерфейса. Более подробная информация приведена в разделе 22.11.
Глава 15. Маршрутизация • Физически ограничивайте доступ к маршрутизаторам. Ведь если у злоумышленни- ка будет физический доступ к устройству, он легко сможет изменить пароль вилегированного режима. Если у вас несколько маршрутизаторов и несколько сотрудников, отвечающих за их работу, воспользуйтесь утилитой RANCID, которую можно загрузить с сайта shruberry.net. Название RANCID (игра слов: rancid — негодный, — Примеч. ред.) го- ворит само за себя, но у этой программы есть одно преимущество: она регистрируемая на ваших маршрутизаторах каждую ночь и получает их файлы конфигурации. Затем она сравнивает эти файлы и сообщает вам об их изменениях. Кроме того, она автоматически передает файлы конфигурации системе управления версиями (см. раздел 12.9). 15.7. Рекомендуемая литература • Perlman Radia. Interconnections: Bridges, Routers, Switches, and Interworking Protocols (2nd Edition), Reading, MA: Addison-Wiley, 2000. Это выдающаяся книга в данной области. Если вы решили купить только одну кни- гу по основе работы в сетях, покупайте ее. Кроме того, не упускайте шанса “завис- нуть” с Радией — она очень веселая и обладает удивительно большими знаниями. • Dooley Kevin and Ian J. Brown. Cisco IOS Cookbook (2nd Edition), Sebastopol, CA: O’Reilly Media, 2007. • Doyle Jeff and Jennifer Carroll. Routing ТС/IP, Volume I (2nd Edition). Indianapolis, IN: Cisco Press, 2005. • Doyle Jeff and Jennifer Carroll. Routing ТС/IP, Volume II. Indianapolis, IN: Cisco Press, 2001. Это двухтомное издание представляет собой глубоко продуманное введение в про- токолы маршрутизации и не ориентировано на какую-то конкретную реализацию. Том I посвящен внутренним протоколам, а том II — внешним протокола, системе NAT и многоадресной маршрутизации. • Halabi Sam and Danny McPherson. Internet Routing Architectures, Second Edition, Cisco Press. 2000. • В этой книге основной акцент делается на BGP. • Huitema Christian. Routing in the Internet, Second Edition, Prentice Hall, 2000. Эта книга представляет собой отличное введение в маршрутизацию для начинаю- щих. В ней описано большинство используемых сегодня протоколов маршрутиза- ции, а также рассматривается ряд сложных тем, например групповое вещание. Есть много документов RFC, посвященных маршрутизации. Основные из них пере- числены в табл. 15.2. Таблица 15.2. Документы RFC, посвященные маршрутизации RFC 1075 Distance Vector Multicast Routing Protocol Waitzman et al. 1256 ICMP Router Discovery Messages Deering 1724 RIP Version 2 MIB Extension Malkin, Baker 2080 Ring for IPv6 Malkin, Minnear
576 Часть II. Работа в сети Окончание табл. 15.2 RFC ',/4 'Г/?г Авторы 2328 OSPF Version 2 Moy 2453 RIP Version 2 Malkin 4271 A Border Gateway Protocol 4 (BGP-4) Rekhter, Li, et al. 4552 Authentication/Confidentiality for OSPFv3 Gupta, Melam 4822 RIPv2 Cryprographic Authentication Arkinson, Fanto 4861 Neighbor Discovery for IPv6 Narten et al. 5175 IPv6 Router Advertisement Flags Option Haberman, Hinden 5308 Routing IPv6 with IS-IS Hopps 5340 OSPF for IPv6 Coltun et al. 5643 Management Information Base for OSFv3 Joyal, NManral, et al. 15.8. Упражнения 15.1. Изучите возможности команды route в Linux и составьте краткое описание ее ра- боты. Как с помощью этой команды сделать следующее: а) добавить стандартный маршрут к шлюзу 128.138.129.1 через интерфейс ethl? б) удалить маршрут 128.138.129.1? в) определить, каким образом был добавлен маршрут: с помощью демона, напри- мер gated, или директивы переадресации протокола ICMP (ту же информа- цию можно получить, анализируя вывод команды netstat -гп)? 15.2. Сравните статический и динамический способы маршрутизации, укажите преиму- щества и недостатки каждого способа. Опишите ситуации, для которых подходит тот или иной вид маршрутизации, и объясните почему. 15.3. ★ Команда netstat -rn сообщает показанные ниже результаты. Опишите каж- дый маршрут и нарисуйте общую схему сети. Какая сеть — 10.0.0.0 или 10.1.1.0 — “ближе” к Интернету? Как появился каждый из маршрутов? Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 40 0 0 ethl 10.1.1.0 0.0.0.0 255.255.255.0 U 40 0 0 ethO 0.0.0.0 10.0.0.1 0.0.0.0 UG 40 0 0 ethl 15.4. 15.5. Определите стратегию маршрутизации в вашей системе. Какие протоколы используются? Какие компьютеры подключены к Интернету? Воспользуйтесь утилитой tcpdump для просмотра маршрутных обновлений, курсирующих в ло- кальной сети, и командой traceroute — для выхода за пределы локальной сети. (Необходим корневой доступ.) 'АтЛг Если бы вы были интернет-провайдером среднего размера, предоставляющим услуги коммутируемого доступа и виртуального хостинга, какую конфигурацию системы маршрутизации вы бы использовали? Убедитесь в том, что учитываются не только шлюзы между интернет-магистралью и вашей сетью, но и любые вну- тренние маршрутизаторы. Нарисуйте схему маршрутизации в сети.
Глава Сетевые аппаратные средства Пользуетесь ли вы поисковой машиной Google с помощью своего мобильного теле- фона1, выполняете ли интерактивные банковские операции или получаете видео^рон- ки с помощью программы Skype от своих кузин из Бельгии, практически все в мире в настоящее время обрабатывается в цифровой форме. Перемещение данных из одного места в другое на уме почти у всех. В основе всего этого сумасшествия лежит фантасти- ческое сетевое оборудование и, как вы уже догадались, множество разнообразных про- грамм, созданных в недрах системы UNIX. Крупномасштабная передача пакетов данных на основе технологии UNIX вошла в жизнь очень многих людей. Многие сетевые технологии продвигались в течение долгих лет, но в результате по- явился очевидный победитель: Ethernet. Сегодня технологию Ethernet можно встретить всюду: от игровых приставок до холодильников. Глубокое понимание принципов работы этой системы чрезвычайно важно для успешной работы системного администратора. Совершенно очевидно, что быстродействие и надежность сетей непосредственно влияют на результаты деятельности компаний. Однако в настоящее время сетевые тех- нологии настолько вездесущи, что состояние сети может повлиять на возможность взаи- модействия между людьми, например возможность делать телефонные звонки. Плохая организация сети — это личная и профессиональная неудача, которая может иметь ката- строфические социальные последствия. Кроме того, устранение этих недостатков порой обходится очень дорого. Успешное создание сети зависит от, по крайней мере, четырех важнейших факторов, а именно: • разработки разумной структуры сети; • выбора высококачественного оборудования; 1 Знаете ли вы, что на телефонах iPhone установлена встроенная система UNIX?
578 Часть II. Работа в сети • правильной инсталляции и документирования; • компетентной эксплуатации и сопровождения. В этой главе рассматриваются принципы, инсталляция и функционирование се- тей Ethernet. Мы также кратко опишем такие устаревшие технологии, как DSL (Digital Subscriber Line), которые обычно предстают перед конечными пользователями в обли- ке — сюрприз! — технологии Ethernet. 16.1. Технология Ethernet: сетевая панацея Захватив более 95% мирового рынка локальных сетей (LAN — Local Area Network), технология Ethernet в самых разных формах проявляется почти всюду. Разработку стан- дарта Ethernet начал Боб Меткалф (Bob Metcalfe) из Массачусетсского технологического института в рамках своей кандидатской диссертации, но в настоящее время она описана во многих стандартах IEEE. В первоначальной спецификации Ethernet была определена скорость передачи дан- ных 3 Мбит/с (мегабита в секунду), но почти сразу же она выросла до 10 Мбит/с. Как только в 1994 году была закончена работа над стандартом, предусматривавшим скорость 100 Мбит/с, стало ясно, что технология Ethernet будет лишь эволюционировать, а не вы- тесняться новой технологией. Это вызвало гонку технологий, в ходе которой произво- дители старались создать все более быстродействующую версию Ethernet, и это сорев- нование еще не закончено. Основные этапы эволюции различных стандартов Ethernet приведены в табл. 16.12. Таблица 16.1. Эволюция Ethernet Год Скорость , ,ц ц.. 1973 3 Мбит/с Xerox Ethernet - ? Коаксиальный кабель 1980 10 Мбит/с Ethernet 1 — 500 м Коаксиальный кабель RG-11 1982 10 Мбит/с DIX Ethernet (Ethernet II) - 500 m Коаксиальный кабель RG-11 1985 10 Мбит/с 10Base5 (“Thicknet”) 802.3 500 m Коаксиальный кабель RG-11 1985 10 Мбит/с 10Base2 (“Thinnet”) 802.3 180 m Коаксиальный кабель RG-58 1989 10 Мбит/с 10BaseT 802.3 100 m Медный кабель НВПа категории 3 1993 10 Мбит/с WBaseF 802.3 2 km 25 km ММ6 оптоволокно ОМ оптоволокно 1994 100 Мбит/с 100BaseTX(“Fast Ethernet") 802.3U 100 м Медный кабель НВП категории 5 1994 100 Мбит/с 100BaseFX 802.3U 2 km 20 km ММ оптоволокно ОМ оптоволокно 1998 1 Пбит/с 1000BaseSX 802.3z 260 м 550 m ММ оптоволокно (62,5 мкм) ММ оптоволокно (50 мкм) 1998 1 Гбит/с WOOBaseLX 802.3z 440 m 550 м 3 km ММ оптоволокно (62,5 мкм) ММ оптоволокно (50 мкм) ОМ оптоволокно 2 Мы не упомянули несколько стандартов, которым не удалось завоевать популярность, в част- чости 100BaseT4 и lOOBaseVG-AnyLAN.
Глава 16. Сетевые аппаратные средства 579 Окончание табл. 16.1 Год Скорость Название стандарта 1998 1 Пбит/с ЮООВазеСХ 802.3z 25 м Двухпроводный экранированный кабель 1999 1 Пбит/с 1000BaseT (“Gigabit Ethernet”) 802.3ab 100 м Медный кабель НВП категорий 5Еи6 2002 10 Пбит/с 10Gbase-SR 802.3ae 300 м ММ оптоволокно 10Gbase-LR 10 км ОМ оптоволокно 10Gbase-ER 802.3aq 40 км ОМ оптоволокно 10Gbase-ZR 80 км ОМ оптоволокно 2006 10 Пбит/с 10Gbase-T(“10Gig”) 802.3an 100 м ВП категории 6а, 7, НВП катего- рии 7а 2009 40 Пбит/с 40Gbase-CR4 P802.3ba Юм Медный кабель НВП 40Gbase-SR4 100 м ММ оптоволокно 2012В 1 Тбит/с TBD TBD TBD CWDM оптоволокно 2015а ЮТбит/с TBD TBD TBD DWDM оптоволокно а НВП — неэкранированная витая пара, ВП — витая пара. 6 ММ — многомодовое, ОМ — одномодовое. в Промышленный проект. Как работает Ethernet Технологию Ethernet можно представить в виде великосветского раута, на котором гости (компьютеры) не перебивают друг друга, а ждут паузы в разговоре (отсутствия трафика в сетевом кабеле), чтобы заговорить. Если два гостя начинают говорить одно- временно (т.е. возникает конфликт), оба они останавливаются, извиняются друг перед другом, ждут немного, а затем один из них начинает говорить снова. В технической терминологии такая схема называется CSMA/CD (Carrier Sense Multiple Access with Collision Detection — множественный доступ с контролем несущей и обнаружением конфликтов). Смысл этого названия заключается в следующем: • контроль несущей — можно определить, занят ли канал; • множественный доступ — кто угодно может передавать сообщения; • обнаружение конфликтов — передающая система “знает”, когда она “перебивает” кого-нибудь. Фактическая задержка при обнаружении конфликтов является случайной. Это по- зволяет избежать такого развития событий, при котором два компьютера одновремен- но передают сообщения в сеть, обнаруживают коллизию, ждут некоторое время, а затем синхронно возобновляют передачу, переполняя, таким образом, сеть конфликтами. В настоящее время важность соглашений CSMA/CD осознали даже приверженцы коммутаторов, которые обычно ограничивают количество узлов в домене, в кагором происходят коллизии, до двух. (Если продолжить аналогию с великосветским раутом, можно описать этот вариант как ситуацию, в которой два собеседника, как в старом кино, чопорно сидят на противоположных концах длинного обеденного стола.)
580 Часть II. Работа в сети Топология Ethernet С точки зрения топологии, сеть Ethernet представляет собой разветвляющуюся шину, но без петель. У пакета есть только один путь следования между любыми двумя узлами, расположенными в одной сети. В сети Ethernet могут передаваться пакеты трех типов: однонаправленные, групповые и широковещательные. Пакеты первого типа адресованы одному узлу, второго — группе узлов, третьего — всем узлам сегмента. Широковещательный домен — это совокупность узлов, которые принимают паке- ты, направляемые по аппаратному широковещательному адресу. В каждом логическом сегменте сети Ethernet существует только один широковещательный домен. В ранних стандартах Ethernet и средствах передачи (например, 10Base5) понятия физического и логического сегментов были тождественными, поскольку все пакеты передавались по одному большому кабелю, в который втыкались сетевые интерфейсы компьютеров3. С появлением современных коммутаторов логические сегменты стали включать в себя множество (десятки и даже сотни) физических сегментов, к которым подключе- но всего два устройства: порт коммутатора и компьютер. Коммутаторы отвечают за до- ставку групповых и однонаправленных пакетов в физический сегмент, где расположен нужный адресат (адресаты); широковещательные пакеты направляются во все сетевые порты логического сегмента. Логический сегмент может состоять из физических сегментов, имеющих разную ско- рость передачи данных (10 Мбит/с, 100 Мбит/с, 1 Гбит/с или 10 Гбит/с). Следовательно, коммутаторы должны иметь средства буферизации и синхронизации для предотвраще- ния возможных конфликтов. Неэкранированная витая пара Неэкранированная витая пара (НВП) — самая популярная среда передачи данных в сетях Ethernet. Она основана на звездообразной топологии и обладает рядом преиму- ществ по сравнению с другими средами: • применяется недорогой, недефицитный медный кабель (иногда можно использо- вать готовую телефонную проводку); • соединение на основе НВП гораздо проще смонтировать и наладить, чем соеди- нение на основе коаксиального кабеля или оптического волокна, к тому же легко подобрать нужную длину кабеля; • используются дешевые, надежные и удобные в эксплуатации разъемы RJ-45; • все соединения функционируют независимо друг от друга, поэтому дефект кабель- ной системы в одном соединении не повлияет на другие компьютеры сети. Общая схема сети на основе НВП изображена на рис. 16.1. Провода, используемые в современных локальных вычислительных сетях на основе неэкранированной витой пары, обычно подразделяют на восемь категорий. Эта си- стема оценки параметров была впервые введена компанией Anixter, крупным постав- щиком кабельной продукции, и впоследствии стандартизирована организацией TIA (Telecommunications Industry Association — ассоциация телекоммуникационной промыш- ленности). Сегодня выделяются категории 1—7 и промежуточные категории 5е и 6а. 3 Мы не шутим! Подключение нового компьютера к сети предполагало прокалывание отвер- стия в изоляции кабеля с помощью специального соединителя, называемого “зуб вампира”, кото- рый позволял добраться до центрального проводника. Этот соединитель затем зажимался винтами.
Глава 16. Сетевые аппаратные средства 581 Рис. 16.1. Схема сети на основе НВП Организация ISO (International Organization for Standartization — Международная ор- ганизация по стандартизации) тоже подключилась к процессу стандартизации кабелей и предложила собственную классификацию, которая почти в точности повторяет класси- фикацию TIA. Например, кабель категории 5 в системе TIA эквивалентен кабелю класса D в системе ISO. Для наглядности в табл. 16.2 подытожены ключевые различия между основными современными стандартами кабелей. Эта таблица поможет вам произвести впечатление на своих друзей во время вечеринки. Таблица 16.2. Характеристики кабелей НВП Ширина полосы МГц 100 100 250 500 600 1000 Затухание ДБ 24 24 21,7 18,4 20,8 60 NEXT ДБ 27,1 30,1 39,9 59 62,1 60,4 ELFEXT ДБ 17 17,4 23,2 43,1 46,0 35,1 Затухание отраженного сигнала (обратная потеря) ДБ 8 10 12 32 14,1 61,93 Задержка распространения сигнала нс 548 548 548 548 504 534 а NEXT (Near-end crosstalk) — ослабление перекрестной помехи на ближнем конце. ELFEXT (Equal level far-end crosstalk) — ослабление равноуровневой перекрестной помехи на дальнем конце. 6 Включая дополнительные спецификации TIA TSB 95 и ISO FDAM 2. На практике кабели категорий 1 и 2 годятся только для передачи звуковых сигналов. Кабель категории 3 является стандартом для самых медленных локальных сетей: lOBaseT со скоростью передачи 10 Мбит/с. Кабель категории 4 ни для чего конкретного не пред- назначен. Кабель категории 5 поддерживает работу на скорости 100 Мбит/с. Кабели категорий Е, 6 и 6а поддерживают скорость передачи 1 Гбит/с и в настоящее время используются в качестве стандарта. Кабель категории 6а лучше всего подходит для организации новых сетей, поскольку он особенно устойчив к помехам, возникающим из-за использования старых стандартов передачи сигналов (например, lOBaseT). При прокладке кабелей ка- тегорий 5 и 5е были зафиксированы определенные проблемы. Кабели категорий 7 и 7а предназначены для передачи данных со скоростью 10 Гбит/с. Для соединений lOBaseT требуются две пары проводов категории 3, причем длина КажДой линии передачи ограничена 100 метрами. В соединениях lOOBaseTX предельная
582 Часть II. Работа в сети длина та же, но используются две пары проводов категории 5. Соединение lOOOBaseTX требует четырех пар проводов категорий 5е или 6/6а. Аналогично соединение lOGBase- ТХ требует четырех пар проводов категорий 6а, 7 или 7а. Ш Подробнее о прокладке кабелей рассказывается в разделе 16.5. Стандарты lOOOBaseTX и 10GBase-TX предназначены для передачи данных по мно- гим парам проводов. Они используют многожильные кабели для передачи данных по линии связи, которые выполняют ее быстрее, чем это может осуществить любая отдель- ная пара проводов. Существуют провода с поливинилхлоридной и тефлоновой изоляцией. Выбор изо- ляции диктуется средой, в которой будут проложены кабели. В замкнутых помещениях, связанных с вентиляционной системой здания, обычно требуется тефлоновая изоляция4. Поливинилхлоридная изоляция дешевле и проще в эксплуатации. 03 Информация о стандарте RS-232 приведена в разделе 31.1. Подключая четырехпарный НВП-кабель к коммутационным панелям и настенным розеткам RJ-45, придерживайтесь стандарта разводки TIA/EIA-568A. Этот стандарт, со- вместимый с другими вариантами RJ-45 (например, RS-232), позволяет избежать оши- бок при разводке концов кабеля, независимо от того, есть ли свободный доступ к парам. Требования стандарта отражены в табл. 16.3. Таблица 16.3. Стандарт TIA/EIA-568A для подключения четырехпарного НВП-кабеля к розетке RJ-45 Пара Контакты разъема 1 Белый/Синий 5/4 2 Белый/Оранжевый 3/6 3 Белый/Зеленый 1/2 4 Белый/Коричневый 7/8 Имеющаяся в здании проводка может не подходить для прокладки сетей, в зависи- мости от того, как и когда она прокладывалась. В 1980-х годах многие старые здания были переоснащены новыми кабелями. К сожалению, эти кабели обычно не поддержи- вают скорость передачи данных выше 100 Мбит/с. Оптическое волокно Оптическое волокно используется в тех ситуациях, когда использование медного , кабеля по тем или иным причинам неприемлемо. Оптическое волокно передает сигнал быстрее, чем медный провод. Кроме того, оно является более устойчивым к электриче- ским помехам, что в некоторых приложениях очень важно. Там, где оптическое волокно не является абсолютно необходимым, обычно выбирают медный кабель, поскольку он дешевле и с ним легче работать. Оптическое волокно бывает “многомодовым” и “одномодовым”. Многомодовое оп- тическое волокно обычно используется в зданиях или комплексах зданий. Оно толще, чем одномодовое, и может проводить несколько лучей света; это свойство позволяет ис- пользовать менее дорогую электронику (например, в качестве источника света можно использовать светодиоды). 4 Конкретную информацию можно получить у пожарного инспектора или ответственного за пожарную безопасность.
Глава 16. Сетевые аппаратные средства 583 Одномодовое оптическое волокно часто используется в магистральных приложениях, например, для прокладки линий связи между городами и регионами. Оно может прово- дить только один световой луч и требует дорогой прецизионной электроники в конеч- ных точках. Стандарт TIA-598C рекомендует цветовую кодировку оптического волокна, пред- ставленную в табл. 16.4. Следует помнить основное правило: все элементы должны соот- ветствовать друг другу. Оптическое волокно, соединяющее конечные точки, оптические кабели перекрестной коммутации и электронные приборы, установленные в конечных точках, должны иметь один и тот же тип и размер. Обратите внимание на то, что кабели ОМ1 и ОМ2 не являются взаимозаменяемыми, хотя и окрашены в один и тот же оран- жевый цвет — проверьте размеры, указанные на кабелях, чтобы убедиться, что они со- ответствуют друг другу. Если вы нарушите это правило, то вам будет сложно обеспечить изоляцию в конечных точках. Таблица 16.4. Атрибуты стандартных оптических волокон Количество мед Название ISO ’ Диаметр сердечника, мкм Много 0М1 62,5 125 Оранжевый Много 0М2 50 125 Оранжевый Много ОМЗ 50* 125 Голубой Одна 0S1 8-10 125 Желтый На концах оптических волокон используются разъемы более чем 30 типов, и нет ни четких правил, ни принципов, регламентирующих их выбор. В каждой конкретной си- туации на выбор того или иного типа разъема влияют поставщики оборудования или параметры оптического волокна, уже проложенного внутри здания. Соединение и расширение сетей Ethernet Сети Ethernet можно соединять с помощью устройств нескольких типов. На выбор устройств, описанных ниже, влияет их стоимость, причем более дешевые устройства описаны в первую очередь. Чем сложнее логические правила, по которым устройства перемещают биты из одной сети в другую, тем больше аппаратного и встроенного про- граммного обеспечения необходимо и тем более дорогой становится сеть. Концентраторы Концентраторы (hub) иногда еще называют повторителями (repeators). Это активные устройства, используемые для соединения сегментов сетей Ethernet на физическом уров- не. Им требуется внешний источник питания. Выступая в качестве повторителя, концентратор ретранслирует Ethemet-фреймы, но никак не интерпретирует их. Он “не имеет представления” ни о том, куда направляются пакеты, ни о том, какой протокол они используют. За исключением экзотических си- туаций, концентраторы больше не должны использоваться в промышленных сетях, и мы не советуем их использовать даже в домашних сетях. (Почему? Потому что коммутаторы (switches) значительно эффективнее используют полосу пропускания частот в сети и в на- стоящее время стоят недорого.) И Сетевые уровни рассматриваются в разделе 14.2.
584 Часть II. Работа в сети Коммутаторы Коммутатор соединяет сети Ethernet на канальном уровне. Его назначение — объеди- нить две физические сети так, чтобы они выглядели как одна большая физическая сеть. В настоящее время коммутаторы являются промышленным стандартом для соединения устройств Ethernet. Коммутаторы принимают, регенерируют и ретранслируют пакеты на аппаратном уровне. Они используют алгоритм динамического обучения. Они запоминают, какие ис- ходные адреса поступают с одного порта, а какие — с другого. Пакет переходит из одно- го порта в другой только при необходимости. Первоначально пересылаются все пакеты, но через несколько секунд, когда коммутатор изучит расположение большинства узлов сети, запускается механизм фильтрации. Поскольку между сетями пересылаются не все пакеты, каждый сегмент кабеля менее загружен, чем в случае, когда все компьютеры подключены к одному кабелю. А если учесть, что основной трафик имеет тенденцию к локализации, то увеличение реальной пропускной способности может оказаться заметным. Кроме того, коммутатор не влияет на логическую модель сети, поэтому его установка требует лишь незначительного вме- шательства со стороны администратора. Если сеть имеет петли, коммутатор может безнадежно запутаться, потому что паке- ты, посылаемые одним компьютером, окажутся сразу на двух (или более) портах ком- мутатора. В одной сети Ethernet петлей не бывает, но после объединения нескольких таких сетей с помощью маршрутизаторов и коммутаторов топология изменится, вслед- ствие чего может образоваться несколько путей к одному узлу. Некоторые коммутаторы решают эту проблему путем резервирования альтернативных маршрутов на тот случай* если основной маршрут станет недоступным. Они упрощают топологию видимой ими сети, отсекая дублирующиеся пути до тех пор, пока в оставшихся сегментах не окажется только по одному маршруту к каждому узлу сети. Другие коммутаторы создают между сетями двойные каналы и переключают трафик по циклическому принципу. Коммутаторы должны просматривать каждый пакет, определяя, нужно ли его пере- сылать в другой сегмент. Производительность этих устройств обычно измеряют как скоростью просмотра пакетов, так и скоростью их пересылки. Многие поставщики не указывают в диаграммах производительности коммутаторов размеры протестированных пакетов, поэтому реальная производительность может быть ниже объявленной. Несмотря на то что быстродействие коммутаторов Ethernet все время растет, эффек- тивно использовать их можно при объединении в один логический сегмент не более сотни компьютеров. В крупных коммутируемых сетях часто возникают проблемы напо- добие “широковещательных штормов”, поскольку широковещательный трафик должен проходить через все порты. Для решения этой проблемы нужно изолировать широко- вещательный трафик между коммутируемыми сегментами посредством маршрутизатора (создавая тем самым более одного логического Ethemet-сегмента). Выбор коммутатора может представлять определенную трудность. В этом сегменте рынка очень высокая конкуренция, следствием которой являются многочисленные ре- кламные заявления, не всегда подтверждаемые на практике. Поэтому не стоит особо до- верять данным, которые приводятся поставщиками; лучше прислушаться к советам не- зависимых экспертов (просмотрите тесты, приводимые в журналах). В последние годы нередко случалось так, что чей-то продукт оказывался “лучшим” в течение нескольких месяцев, а затем, после попыток внесения улучшений, его производительность или на- дежность падала ниже критической отметки.
Глава 16. Сетевые аппаратные средства 585 В любом случае убедитесь, что скорость объединительной панели коммутатора явля- ется достаточной. У хорошо спроектированного коммутатора эта скорость должна пре- вышать сумму скоростей всех его портов. Коммутаторы, позволяющие создавать виртуальные локальные сети В крупных организациях можно использовать коммутаторы, позволяющие разбивать их порты (программным путем) на группы, называемые виртуальными локальными се- тями (VLAN — Virtual Local Area Network). Виртуальная локальная сеть — это группа портов, принадлежащая к одному логическому сегменту, как если бы порты были соеди- нены со своим собственным выделенным коммутатором. Подобное секционирование позволяет повысить степень изоляции трафика, что полезно с точки зрения как безопас- ности, так и производительности. Трафиком между виртуальными локальными сетями управляет маршрутизатор или, в некоторых случаях, модуль маршрутизации или уровень программной маршрутизации самого коммутатора. Расширение этой системы, называемое “транкингом виртуальной локальной сети” (один из примеров реализации — протокол IEEE 802.1Q), позволяет раз- ным коммутаторам обслуживать порты одной логической виртуальной локальной сети. Маршрутизаторы Маршрутизаторы (известные также как “коммутаторы третьего уровня”) направля- ют трафик на третьем сетевом уровне модели OSI. Маршрутизаторы доставляют пакеты адресатам на основании информации, хранящейся в TCP/IP-заголовках. Помимо просто- го перемещения пакетов, маршрутизаторы могут также выполнять ряд особых функций, например фильтрацию пакетов (в соответствии с правилами безопасности), разделение трафика по приоритетам (в соответствии с заданным качеством обслуживания) и обнару- жение общей сетевой топологии. Алгоритмы маршрутизации рассматриваются в главе 15. Конфигурация маршрутизаторов бывает фиксированной или модульной. Устройства первого типа содержат сетевые интерфейсы, установленные в заводских условиях. Они обычно подходят для специализированных применений. Например, маршрутизатор с интерфейсами Т1 и Ethernet может оказаться удобным, когда нужно подключить не- большую компанию к Интернету. Модульные маршрутизаторы имеют слотовую или шинную архитектуру, а интерфей- сы к ним добавляются пользователями. Как правило, это более дорогие устройства, но зато они гибче в эксплуатации. В зависимости от необходимой надежности и ожидаемого трафика, специализиро- ванный маршрутизатор может оказаться как дороже, так и дешевле системы UNIX или Linux, сконфигурированной в качестве маршрутизатора. Однако специализированное Устройство, как правило, демонстрирует более высокую производительность и надеж- ность. Это та область сетевого проектирования, где лучше заранее вложить чуть больше Денег, чем потом иметь головную боль. Автосогласование С появлением разных стандартов Ethernet возникла необходимость, чтобы устройства могли идентифицировать конфигурацию своих соседей и согласовывать с ними свои на- стРойки. Например, сеть не будет работать, если на одной стороне соединения она ра- ботает со скоростью 1 Гбит/с, а на другой — со скоростью 10 Гбит/с. Для выявления и Решения этой проблемы организацией IEEE был разработан стандарт автосогласования Ethernet. В одних случаях он работает, а в других применяется неправильно и лишь усу- губляет проблему.
586 Часть II. Работа в сети Следует запомнить два золотых правила автосогласования. • Вы обязаны использовать автосогласование всех интерфейсов, работающих на ско- рости 1 Гбит/с и выше. Этого требует стандарт. • Если интерфейсы ограничены скоростями 100 Мбит/с и ниже, необходимо либо конфигурировать оба конца соединения, либо вручную настроить скорость и ду- плекс (половинный или полный) обеих сторон. Если в режиме автосогласования настроить только одну сторону соединения, то в большинстве случаев она не смо- жет выяснить, какую конфигурацию имеет другая сторона. В результате конфигу- рация станет несогласованной и производительность упадет. Для того чтобы выяснить, как задать стратегию автосогласования интерфейсов, про- читайте специальные разделы главы 14, начиная с раздела 14.11. Передача электропитания по сетям Ethernet Технология передачи питания по сетям Ethernet (РоЕ — Power on Ethernet) основана на передаче электропитания по той же неэкранированной витой паре (UTP Ethernet), по которой передается сигнал Ethernet. Эта технология регламентируется стандартом IEEE 802.3af. Это особенно удобно для систем связи, обеспечивающих передачу речевого сигнала по сети Интернет (VoIP — Voice over IP), или пунктов доступа к системе беспро- водной связи (мы указали только два примера, но список можно продолжить), в которых требуется как мощность тока, так и сетевое соединение. По мощности тока, системы РоЕ разделяются на четыре класса в диапазоне от 3,84 до 12,95 ватт. Промышленность, которая никогда не останавливается на достигнутом, уже работает над новым стандартом (802.3at), предусматривающим более высокую мощ- ность тока (более 60 ватт). Будет ли этого достаточно, чтобы подключить духовку Easy- Bake к сетевому порту в конференц-зале?5 Технология РоЁ порождает два обстоятельства, о которых должен знать системный администратор. • Вы должны знать о существовании устройств РоЕ в вашей инфраструктуре, чтобы правильно спланировать доступ к портам коммутаторов, поддерживающих техно- логию РоЕ. Эти порты дороже, чем порты, не поддерживающие технологию РоЕ. • Вычисляя расход электроэнергии на обслуживание коммуникационных шка- фов, содержащих коммутаторы РоЕ, следует учитывать мощность устройств РоЕ. Обратите внимание на то, что вы не должны планировать тот же самый расход электроэнергии на дополнительное охлаждение коммуникационных шкафов, по- скольку большая часть тепла, выделяемого из-за потребления мощности РоЕ, рас- сеивается за пределами шкафа (обычно по офису). Гигантские пакеты Технология Ethernet стандартизована для типичного пакета размером 1 500 байт (вме- сте с фреймом — 1 518 байт). Это значение было выбрано давно, когда сети были мед- ленными и память для буферов была дефицитной. В настоящее время пакеты размером 1 500 байт выглядят крохотными в контексте гигабитных сетей Ethernet. Поскольку с каж- 5 К сожалению, выяснилось, что в духовках Easy-Ваке используется электрическая лампа мощ- ностью 100 ватт (правда, в некоторых моделях для освещения используются нагревательные элемен- ты). Это вызывает сомнения по поводу совместимости этих моделей со стандартом IEEE 802.3at. Для интересующихся этим вопросом: да, существует возможность загрузить небольшую систему Linux через порт сети РоЕ. Найти специальное оборудование для этого мы предоставляем читателям.
Глава 16. Сетевые аппаратные средства 587 дым пакетом связаны накладные расходы и определенное время задержки, производи- тельность сети можно повысить, если допустить более крупные размеры пакетов. К сожалению, стандарты IEEE для разных типов сетей Ethernet запрещают использо- вание крупных пакетов по соображениям совместимости сетей. Однако поскольку ско- рость магистрального трафика часто во много раз превышает установленный предел, не- стандартные большие пакеты Ethernet в современных сетях перестали быть редкостью. Подстрекаемые нетерпеливыми потребителями, производители сетевого оборудования негласно бойкотируют стандарт IEEE и обеспечивают поддержку крупных фреймов в своей гигабитной продукции. Для использования так называемых гигантских пакетов (jumbo frames) необходимо лишь повысить максимально возможный размер пакета (MTU — maximal transmission unit) в интерфейсах сети. Повышение производительности зависит от вида трафика, но наибольший выигрыш достигается для крупномасштабных перемещений по протоколу TCP (например, в файловых службах NFSv4 или CIFS). Ожидается, что умеренное, но заметное повышение производительности должно составить примерно 10%. Тем не менее следует отметить следующее. • Поддерживать и использовать гигантские пакеты должно все сетевое оборудова- ние в подсетях, включая коммутаторы и маршрутизаторы. Их нельзя смешивать и подгонять. • Поскольку гигантские пакеты являются нестандартными, обычно их необходи- мо разрешать явным образом. Устройства могут принимать гигантские пакеты по умолчанию, но, вероятнее всего, они не будут их генерировать. • Поскольку гигантские пакеты представляют собой незаконное явление, не суще- ствует консенсуса, насколько большими они могут или должны быть. Типичной величиной является 9 000 бит или 9 018 вместе с фреймом. Необходимо проверить, какой максимальный размер пакета может принять ваше устройство. Пакеты раз- мером больше 9 Кбайт иногда называют сверхгигантскими, но это экзотическое название вас пугать не должно. Чем больше размер, тем лучше, по крайней мере в диапазоне до 64 Кбайт. • Гигантские пакеты могут существовать только во внутренних сетях. Интернет не передает такие пакеты. Мы одобряем использование гигантских пакетов в гигабитных сетях Ethernet, но только там, где это легко и безопасно (например, в сложных промышленных средах их использовать вряд ли стоит). Будьте готовы к дополнительной отладке, если что-то пой- дет не так, как надо. Лучше всего развернуть новую сеть, задав максимально возможный размер пакета по умолчанию, а позднее, когда надежность сети будет проверена, изме- нить эти настройки и разрешить гигантские пакеты. 16.2. Беспроводной стандарт: локальная СЕТЬ ДЛЯ КОЧЕВНИКОВ Беспроводные сети состоят из беспроводных точек доступа (WAP — Wireless Access Points) и клиентов беспроводной сети. Точки WAP могут соединяться традиционными проводными сетями (обычная конфигурация) или с другими точками WAP без исполь- зования проводов (конфигурация известна под названием “беспроводная сеть”). Точки WAP обычно оснащаются специальным оборудованием, состоящим из одного или нескольких радиоприемников и встроенной операционной системы, которая часто
588 Часть II. Работа в сети представляет собой усеченный вариант системы Linux. Одна точка WAP может обеспечить доступ для многих клиентов, но их количество ограничено. Обычно одна точка промыш- ленной сети одновременно обслуживает не более восьми клиентов. Любое устройство, дей- ствующее с помощью беспроводного стандарта, поддерживается точкой WAP как клиент. Распространенными стандартами беспроводных сетей в настоящее время являются IEEE 802.11g и 802.1 In. Стандарт IEEE 802.11g работает на частоте 2,4 ГГц и обеспечи- вает доступ к локальной сети со скоростью, достигающей 54 Мбит/с. Радиус действия одной точки доступа колеблется от 100 м до 40 км, в зависимости от оборудования и физических особенностей местности. Стандарт 802.1 In обеспечивает скорость до 600 Мбит/с6 и может использовать диа- пазоны частот как 5 ГГц, так и 2,4 ГГц (при этом рекомендуется использовать диапазон 5 ГГц). Радиус действия точки доступа в стандарте IEEE 802.1 In в два раза больше, чем в стандарте IEEE 802.11g. В настоящее время стандарт IEEE 802.11g и его предшественник IEEE 802.11b ис- пользуются повсеместно. Трансиверы недороги и встроены в большинство ноутбуков. Кроме того, платы расширения также стоят недорого и легко устанавливаются в любой персональный компьютер. Для того чтобы сконфигурировать устройство с системой Linux в качестве точки до- ступа по стандарту 802.Ha/b/g, необходимы соответствующее оборудование и драйвер. Поскольку большинство плат беспроводной связи по-прежнему предназначается для системы Microsoft Windows, на заводе могут не установить драйверы для системы Linux. Прекрасным выбором для организации отдельной станции беспроводной связи в до- машних условиях или в офисе, работающей по стандарту 802.1 lb/g, является точка до- ступа Airport Express компании Apple. Она напоминает блок питания, который стоит недорого (около 99 долл.) и имеет много функций.7 Другим вариантом является приоб- ретение коммерческого устройства беспроводного доступа, работающего под управлени- ем усеченной версии системы Linux (например, Open WRT). Более подробную информа- цию можно найти на сайте openwrt. com. Точки беспроводного доступа выпускают десятки производителей. Их можно купить в интернет-магазинах и даже в бакалейных лавках. Но, как говорится, “скупой платит дваж- ды”. Дешевая точка доступа (в пределах 50 долл.), скорее всего, будет плохо работать при передаче больших файлов или при одновременном обслуживании нескольких клиентов. Отладка беспроводных сетей напоминает шаманство. Решая проблемы, вы должны учитывать множество факторов. Если вы разворачиваете беспроводную сеть промыш- ленного масштаба, то, вероятно, стоит приобрести средства для анализа беспроводных сетей. Мы настоятельно рекомендуем использовать инструменты анализа, выпускаемые компанией AirMagnet. Безопасность беспроводных сетей Традиционно безопасность беспроводных сетей очень низкая. Существует протокол WEP (Wired Equivalent Privacy), применяемый в сетях 802.11b и для шифрования паке- тов, передаваемых с помощью радиоволн. К сожалению, в современной версии стандар- 6 Скорость 600 Мбит/с в стандарте 802.1 In является, скорее, теоретической. На практике поло- са пропускания в окрестности точки WAP при оптимальной конфигурации может обеспечить ско- рость передачи данных не более 400 Мбит/с. Это объясняется различием между теоретическими и практическими возможностями оборудования и среды. В беспроводных сетях всякое бывает! 7 Фактически она также обеспечивает беспроводное соединение для воспроизведения музыки с вашего персонального компьютера или ноутбука.
Глава 16. Сетевые аппаратные средства 589 та была обнаружена фатальная проектная недоработка, которая делает его практически бесполезным. Посторонний человек, находящийся за пределами здания, может полу- чить прямой доступ к сети и остаться незамеченным. Тем не менее недавно появившиеся стандарты Wi-Fi Protected Access (WPA) возроди- ли доверие к безопасности беспроводных сетей. В настоящее время во всех новых ин- сталляциях должны использоваться стандарты WPA (в частности, стандарт WPA2), а не WEP. Без применения стандарта WPA2 беспроводные сети должны считаться полностью незащищенными и не должны использоваться за пределами предприятия. Даже дома не используйте стандарт WEP! Для того чтобы запомнить, что стандарт WEP является незащищенным, а стандарт WPA — безопасным, просто расшифруйте аббревиатуру WAP (Wired Equivalent Privacy — облегченный протокол беспроводных точек доступа). Это название точно отражает суть дела; протокол WEP обеспечивает такую защиту, как проводная сеть, допускающая не- посредственное подключение посторонних лиц. (Иначе говоря, никакой защиты — по крайне мере, на уровне IP.) Беспроводные коммутаторы и облегченные точки беспроводного доступа Аналогично тому, как концентраторы Ethernet доросли до уровня коммутаторов Ethernet, беспроводная продукция эволюционирует и постепенно достигает уровня крупных предприятий. Большое количество поставщиков (таких, как компания Cisco) в настоящее время производят “беспроводные коммутаторы”, работающие в сочета- нии с комплектами точек доступа, развернутых в зданиях. Теоретически можно развер- нуть кучу недорогих точек доступа, а затем централизованно управлять ими с помощью “умного” беспроводного коммутатора. Такой коммутатор хранит информацию о конфи- гурации стандарта WAP и обеспечивает удобную аутентификацию и роуминг. Эту функ- циональную возможность обеспечивает протокол LWAPP (Leightweight Wireless Access Point Protocol — облегченный протокол беспроводных точек доступа). Если вам нужен повсеместный беспроводной доступ в среднем или крупном пред- приятии, то определенно стоит потратить время на изучение продукции из этой катего- рии. Эта продукция не только сокращает время, затрачиваемое на управление, но и по- зволяет контролировать качество беспроводной связи, предоставляемой пользователям. Существует один изящный прием: можно развернуть сеть по стандарту 802.1 lg/п в своем здании, а затем использовать ее для голосовой связи между сотрудниками через Интернет. Это напоминает бесплатную сотовую сеть! 16.3. DSL и кабельные модемы: "последняя миля”8 Для крупных компаний не составляет особого труда перемещать большие объемы данных. Такие технологии, как Tl, ТЗ, SONET, MPLS и Frame Relay, реализуют доста- точно простые каналы обмена данными. Но они не подходят для подключения к сети в домашних условиях. Их стоимость слишком высока, да и не всегда доступно соответ- ствующее оборудование. В технологии DSL (Digital Subscriber Line — цифровая абонентская линия) использу- ется обычный медный телефонный провод, по которому передаются данные со скоро- 8 “Последняя миля” (last mile) — это кабельная линия связи между абонентом и телефонной компанией. — Примеч. ред.
590 Часть II. Работа в сети стью до 24 Мбит/с (правда, для типичного DSL-соединения этот показатель находится в диапазоне от 256 Кбит/с до 5 Мбит/с). В большинстве домов есть телефонная проводка, что делает данную технологию очень удобной для телефонных компаний. Со стороны пользователя DSL-линия заканчивается в устройстве, работающем подобно маршрути- затору TCP/IP. К нему подключаются локальные Ethemet-устройства. В отличие от обычных телефонных линий и ISDN-соединений, требующих “дозва- ниваться” до абонента, DSL — это выделенная линия, в которой постоянно есть связь. Это делает технологию DSL еще более привлекательной, поскольку отсутствуют задерж- ки, связанные с начальным конфигурированием и дозвоном. Существует несколько разновидностей технологии DSL, поэтому название техноло- гии часто приводят в виде xDSL, где х — префикс разновидности, например: А (асимме- тричная), S (симметричная), Н (высокоскоростная), RA (с адаптируемой скоростью) и I (DSL-Ha-ISDN). Последний вариант особенно полезен для удаленных от офиса рабо- чих мест, если скорость передачи данных должна быть выше, чем в обычной технологии DSL. Конкретный вариант реализации и доступная скорость передачи зависят от обо- рудования, установленного в центральном офисе или у интернет-провайдера. Подключение к сети сотен миллионов домашних пользователей — заветная мечта многих компаний. Здесь замешаны большие деньги. Технология DSL основана на суще- ствующей инфраструктуре телефонных линий, инвестиции в которую позволили опера- торам местной связи (ILEC — Incumbent Local Exchanges Carriers) извлекать сказочные прибыли, пока мимо них проносилась сетевая революция 80-х—90-х гг. Компании кабельного телевидения, развивающие собственную оптоволоконную инфраструктуру, предлагают высокоскоростные (хоть и асимметричные) решения для пользователей. В индустрии кабельных модемов не так давно начался процесс стандар- тизации протоколов передачи данных, и сегодня рекламируется стандарт DOCSIS (Data Over Cable Service Interface Specification — спецификация интерфейса передачи данных по кабельным линиям). Он определяет технические характеристики как кабельных мо- демов, так и оборудования компании, предоставляющей соответствующие услуги, и по- зволяет взаимодействовать устройствам различных производителей. Если сравнивать DSL и кабельную технологию, то выигрыш в конкурентной борьбе достанется тому, что обеспечит более высокую частоту передачи данных в конкретную точку по более низкой цене. Хорошие новости для потребителей в том, что это вынуждает компании инвестировать средства в инфраструктуру для обслуживания жилых районов. 16.4. Тестирование и отладка сетей Основной причиной широкомасштабного перехода к стандарту Ethernet (и к другим технологиям, основанным на использовании неэкранированной витой пары) явилась простота отладки сети. Поскольку эти сети можно проверять посегментно, аппаратные проблемы часто решаются в считанные секунды. Ключ к отладке сети — ее разбивка на сегменты и тестирование каждого из них до тех пор, пока не будет обнаружена неисправность. Загадочные лампочки на коммутато- рах и концентраторах (обозначающие, к примеру, состояние канала и наличие трафика пакетов) помогают быстро выявить источник проблемы. Для того чтобы эти индикаторы работали так, как вы хотите, следует руководствоваться первоклассной документацией. Как всегда, важно иметь под рукой нужные инструменты, чтобы выполнить работу правильно и без проволочек. На рынке предлагаются средства сетевой отладки двух ти- пов (правда, наблюдается тенденция к их объединению).
Глава 16. Сетевые аппаратные средства 591 Устройство первого типа — ручной кабельный тестер. Он измеряет электрические характеристики кабеля, включая его длину (для этого применяется особая технология, называемая рефлектометрией во временной области). Такие устройства способны вы- являть простейшие проблемы, например разрыв или неправильную разводку кабеля. Нашим любимым инструментом тестирования локальных сетей является устройство Fluke LanMeter. Это универсальный анализатор, способный даже посылать эхо-пакеты протокола ICMP. Профессиональные варианты этого оборудования описаны на спе- циальном сайте. Для телекоммуникационных сетей WAN лучше всего подходит тестер Т-BERD, выпускаемый компанией JDSU (jdsu.com). Средства отладки второго типа — это анализаторы сетевых пакетов. Они просматри- вают сетевые пакеты на предмет наличия ошибок протоколов, неправильной конфи- гурации и прочего беспорядка. Эти анализаторы работают на уровне каналов, а не на электрическом уровне, поэтому они не могут распознавать проблемы, связанные с фи- зическими повреждениями кабелей или электропитанием. Существуют профессиональные анализаторы сетевых пакетов, но мы нашли сво- бодно распространяемую программу Wireshark (wireshark.org), которая может вы- полняться на полнофункциональном ноутбуке. Именно ее можно считать наилучпщм выбором.9 Более подробная информация об анализаторах сетевых пакетов приведена в разделе 21.7. 16.5. Прокладка кабелей Если вы занялись прокладкой кабелей в здании, то самый ценный совет, которыймы можем вам дать, звучит так: “Делайте все правильно с первого раза”. Это не та обладь, в которой можно скупиться или халтурить. Покупая качественные материалы, выбирая компетентного подрядчика для прокладки кабелей и инсталлируя дополнительные разъ- емы (отводы), вы избегаете многолетних мучений. Неэкранированная витая пара Кабель категории 6а имеет наилучшее соотношение цены и производительности на современном рынке. Его стандартный вариант — четыре пары проводов под одной обо- лочкой, что подходит для большинства соединений, включая RS-232 и гигабитные линии. Спецификации кабеля категории 6а требуют, чтобы скрутка провода заканчивалась в точке контакта. Для того чтобы обеспечить это требование, необходимы специальное обучение и оконечное оборудование. При этом необходимо использовать настенные ро- зетки и коммутационные панели категории 6а. Самые хорошие отзывы заслужила про- дукция компании Siemon (www. siemon. com). Офисные точки подключения Одной точки подключения на офис явно недостаточно. Сколько же нужно — две или четыре? Мы рекомендуем четыре, обосновывая это следующими причинами. • Их можно использовать просто для подключения телефонов. • Их можно применять для подключения портативных или демонстрационных компьютеров. 9 Как и многие популярные программы, программа Wireshark часто подвергается атакам хаке- ров. Убедитесь, что вы используете самую последнюю версию.
592 Часть II. Работа в сети • Стоимость материалов составляет, как правило, всего 5—10% от общей стоимости прокладки сети. • Как правило, все предполагаемые оценки следует умножать на два. • Гораздо дешевле проложить весь кабель сразу, чем делать это поэтапно. • Если порты работают медленно, то люди обычно добавляют коммутаторы с че- тырьмя или восемью портами, купленные в ближайшем специализированном ма- газине, а потом жалуются на форумах на низкую скорость соединения. При прокладке кабеля в здании можно установить дополнительные розетки в кори- дорах, конференц-залах, столовых, туалетных комнатах и на потолках (для точек бес- проводного доступа). Однако не забывайте о безопасности и размещайте открыто предо- ставляемые порты на “гостевой” виртуальной локальной сети, не допуская посторонних к своим внутренним сетевым ресурсам. Стандарты кабельных систем Необходимость обеспечения всех видов деятельности внутри современных зданий обусловливает потребность в крупной и сложной кабельной инфраструктуре. Заглянув в обычный коммутационный шкаф, вы будете потрясены, увидев его стенки, сплошь покрытые непомеченными проводами одного цвета. С целью улучшения оперативного контроля и стандартизации кабельных систем зда- ний, в феврале 1993 года организация TIA опубликовала административный стандарт на телекоммуникационную инфраструктуру коммерческих зданий (TIA/EIA-606). Этот стандарт устанавливает требования и принципы идентификации и документирования телекоммуникационной инфраструктуры. Он касается следующих аспектов: • оконечной аппаратуры; • кабелей; • прокладки кабелей; • расстояний между элементами оборудования; • цветовой маркировки; • символических обозначений стандартных компонентов. В частности, определены стандартные цвета маркировки проводов (табл. 16.5). Таблица 16.5. Таблица цветовой маркировки по стандарту TIA/EIA-606 'З^адйвчного усфЬЙпа ЙС Граничное Оранжевый 150С Центральная телефонная станция Сетевые соединения Зеленый 353С Также применяется для вспомогательных электросетей Общее оборудование6 Фиолетовый 264С Основное оборудование коммутации и пере- дачи данных Магистраль первого уровня Белый — Кабели Магистраль второго уровня Серый 422С Кабели Станция Синий 291С Горизонтальные кабели Магистраль между зданиями Коричневый 465С Кампусные кабели Разное Желтый 101С Служебные и сигнальные линии
глава 16. Сетевые аппаратные средства 593 Окончание табл, 16.5 Ключевые телефонные системы Красный_184С —_____________________________ а в соответствии с цветовой моделью Pantone. о Офисные АТС, компьютеры, локальные сети, мультиплексоры и т.д. 16.6. Проектирование сетей В этом разделе рассматриваются вопросы, связанные с логическим и физическим проектированием сетей среднего размера. Представленные здесь идеи подходят для не- скольких сотен узлов, но неприменимы ни для трех, ни для нескольких тысяч компью- теров, включенных в одну сеть. Также предполагается, что работа будет начата с нуля. Основной объем работ по проектированию сети состоит из определения: • типов сред передачи; • топологии и способов прокладки кабелей; • системы концентраторов, коммутаторов и маршрутизаторов. . Еще один ключевой вопрос проектирования сети связан с управлением перегрузкой. Например, файловые протоколы NFS и CIFS очень сильно загружают сеть, поэтому та- кие файловые системы нежелательно подключать по магистральному кабелю. Ниже анализируются аспекты, которые необходимо учитывать при проектировании сети. Структура сети и архитектура здания Структуру сети проще изменить, чем архитектуру здания, но обе они должны нор- мально сосуществовать. Если вам крупно повезло, т.е. представилась возможность про- ектировать сеть до постройки здания, будьте щедрым. К сожалению, в большинстве слу- чаев здание и отдел технического обслуживания компании на момент проектирования сети уже существуют и налагают жесткие ограничения на структуру сети. В готовых зданиях сеть должна адаптироваться к архитектуре, а не противостоять ей. В современных зданиях, помимо высоковольтной электропроводки, водо- и газопрово- дов, иногда имеются каналы для прокладки кабелей. Часто монтируются подвесные по- толки — настоящий подарок для тех, кто прокладывает сеть. Во многих университетских городках существуют туннели, которые облегчают создание сетей. Необходимо следить за целостностью брандмауэров10. При прокладке кабеля через брандмауэр отверстие должно соответствовать диаметру кабеля и заполняться негорю- чим веществом. Выбирая кабель, учитывайте наличие приточной вентиляции. Если узнают, что вы нарушили правила пожарной безопасности, вас могут оштрафовать и за- ставить устранить недостатки, даже если для этого придется проложить заново всю сеть. Логическая структура сети должна соответствовать физическим ограничениям зда- ний, в которых она будет функционировать. Приступая к проектированию, помните, что можно найти логически красивое решение, а затем вдруг обнаружить, что реализо- вать его физически сложно или вообще невозможно. 10 Речь идет о брандмауэрах в виде бетонных, кирпичных или огнеупорных стен, которые пре- пятствуют распространению огня по всему зданию. Значительно отличаясь от сетевых брандмауэ- ров, они не менее важны.
594 Часть II. Работа в сети Расширение сетей Прогнозировать потребности на десять лет вперед очень сложно, особенно в области вычислительной техники и сетей. Поэтому, проектируя сеть, всегда следует учитывать перспективы ее расширения и увеличения пропускной способности. Прокладывая ка- бель, особенно в труднодоступных местах, протягивайте в три-четыре раза больше пар, чем нужно. Помните: основная часть стоимости прокладки сети приходится на оплату труда, а не на материалы. Даже если волоконно-оптические линии не планируется использовать немедленно, разумно будет все же проложить немного оптического волокна, особенно если известно, что впоследствии протянуть его будет гораздо труднее. Прокладывайте и многомодовый, и одномодовый кабели. Как правило, нужным оказывается как раз тот кабель, который не проложен. Перегрузка Сеть — как цепь: ее качество определяется самым слабым или самым медленным звеном. Производительность Ethernet, как и многих других сетевых технологий, при уве- личении нагрузки падает. Активно эксплуатируемые коммутаторы, нестыкующиеся интерфейсы, низкоско- ростные каналы связи ~ все это может привести к перегрузке. Эффективный способ борьбы с ней заключается в локализации трафика путем создания подсетей и установки маршрутизаторов. Подсети можно использовать и для изоляции компьютеров, задей- ствованных в отдельных экспериментах. Трудно проводить эксперимент на нескольких компьютерах, если нет надежного способа изолировать их физически и логически от остальной части сети. Обслуживание и документирование Опыт показывает, что удобство обслуживания сети напрямую зависит от качества до- кументации на нее. Точная, полная, своевременно корректируемая документация абсо- лютно необходима. Кабели следует маркировать во всех точках подключения. Рекомендуем вкладывать копии местных монтажных схем в коммутационные шкафы, чтобы при всех изменения^ эти экземпляры можно было откорректировать на месте. Каждые несколько недель не- ’ обходимо переносить все корректировки в электронную базу данных. Стыки между крупными системами в виде коммутаторов или маршрутизаторов могут упростить отладку, поскольку позволяют изолировать части сети и отлаживать их по от- дельности. Полезно также разграничивать административные области. 16.7. Управление сетью Если необходимо обеспечить нормальную работу сети, одни функции управления следует централизовать, другие — распределить, а третьи — оставить на локальном уров- не. Требуется сформулировать и согласовать обоснованные “правила поведения добро- порядочных граждан”. Типичная крупномасштабная среда включает в себя: • магистральную сеть, соединяющую здания;
Глава 16. Сетевые аппаратные средства 595 • сети подразделений, подключенные к магистрали; • подсети рабочих групп в рамках подразделения; • соединения с внешним миром (например, с Интернетом или периферийными фи- лиалами). При проектировании и реализации сетей следует предусматривать централизованные контроль, ответственность, сопровождение и финансирование. Поскольку подразделе- ния, как правило, стремятся свести к минимуму собственные расходы, быстро растет число сетей с централизованной оплатой каждого соединения. Вот основные объекты централизованного управления: • структура сети, в том числе принципы использования подсетей, маршрутизаторов, коммутаторов и т.д.; • магистральный кабель, в том числе подключения к нему; • IP-адреса и имена компьютеров, доменные имена; • используемые протоколы (требуется обеспечить их взаимодействие); • правила доступа в Интернет. Имена доменов, IP-адреса и сетевые имена компьютеров в определенном смысле уже находятся под централизованным контролем таких организаций, как ARIN (American Registry for Internet Numbers) и ICANN, но координация использования этих элементов на локальном уровне также необходима. Центральный орган управления имеет общее представление о сети, ее структуру, производительности и перспективах роста. Он может позволить себе иметь собственное контрольное оборудование (и обслуживающий его персонал) и следить за нормальной работой магистральной сети. Центральный орган может настоять на правильном выборе структуры сети, даже если для этого придется заставить подразделение купить маршру- тизатор и создать подсеть для подключения к магистрали. Такое решение иногда необ- ходимо для того, чтобы новое соединение не навредило работе существующей сети. Если в сети работают разнородные компьютеры, операционные системы и протоко- лы, обязательно нужно иметь “высокоинтеллектуальный” маршрутизатор (например, компании Cisco), который будет служить шлюзом между сетями. 16.8. Рекомендуемые поставщики Занимаясь более 20 лет инсталляцией сетей по всему миру, мы не раз обжигались на продуктах, которые не соответствовали спецификациям, имели завышенную цену, неправильно указанные характеристики или как-то иначе не оправдывали ожидания. Ниже приведен список поставщиков, которым мы доверяем и услугами которых реко- мендуем пользоваться. Кабели и разъемные соединения АМР (подразделение Tyco) Anixter (800) 522-6752 (800) 264-9837 amp.com anixter.com Belden Cable Newark Electronics (800)235-3361 (800)463-9275 (765)983-5200 newark.com belden.com Black Box Corporation blackbox.com The Siemon Company (860) 945-4395 siemon.com
596 Часть II. Работа в сети Тестовые приборы Fluke JDSU- (800) 443-5853 (866) 228-3762 fluke.com jdsu.com Маршрутизаторы/коммутаторы Cisco Systems Juniper Network (415) 326-1941 (408) 745-2000 www.cisco.com juniper.com Siemon (800) 945-4395 siemon.com 16.9. Рекомендуемая литература • Barnett David, Groth David and Jim McBee. Cabling: The Complete Guide to Network Wiring (3rd edition). San Francisco: Sybex, 2004. • Seifert Rich. Gigabit Ethernet: Technology and Applications for High Speed LANs. Reading, MA: Addison-Wesley, 1998. • ANSI/TIA/EIA-568-A. Commercial Building Telecommunications Cabling Standard, и ANSI/TIA/EIA-606, Administration Standard for the Telecommunications Infrastructure of Commercial Buildings. Это стандарты телекоммуникационной промышленности для построения кабель- ных систем зданий. К сожалению, они доступны не бесплатно. Посетите веб-сайт www.tiaonline.org. • Spurgeon Charles. Guide to Ethernet', ethermanage. com/ethernet. 16.10. Упражнения 16.1. Сегодня для прокладки компьютерных сетей в офисных зданиях чаще всего ис- пользуется неэкранированная витая пара. Для поддержки таких сетей требует- ся определенное сочетание концентраторов и коммутаторов. Во многих случаях устройства обоих типов оказываются взаимозаменяемыми. Перечислите преиму- щества и недостатки этих устройств. 16.2. ★ Нарисуйте схему воображаемой сети, соединяющей компьютер вашей лаборато- рии с узлом Amazon.com. Покажите компоненты локальных, общегородских и гло- бальных сетей и перечислите технологии, применяемые на каждом уровне. Укажите, где могут использоваться концентраторы, коммутаторы и маршрутизаторы. 16.3. ★ Исследуйте протокол Temporal Key Integrity Protocol из семейства WPA2. Объясните его преимущества перед протоколом WEP и назовите атаки, которые он может предотвратить. 16.4. && ТТСР — средство измерения производительности протоколов TCP и UDP. Инсталлируйте пакет на двух компьютерах и замерьте производительность соеди- нения между ними. Что происходит с пропускной способностью сети при измене- нии размеров сетевых буферов? Как полученные результаты согласуются с теоре- тической пропускной способностью физической среды?
Глава 17 Система доменных имен К Интернету подключено огромное множество компьютеров. Как управлять ими, ес- ли они расположены в разных странах и принадлежат разным сетям и административ- ным группам? Этой цели служат два элемента глобальной сетевой инфраструктуры: си- стема доменных имен (Domain Name System, DNS), которая отслеживает информацию об именах и адресах компьютеров, и система маршрутизации в Интернете, контроли- рующая соединения между компьютерами. Система доменных имен предназначена для нескольких целей, но основная из них — преобразование имен компьютеров в IP-адреса и наоборот. Пользователям и програм- мам пользовательского уровня удобнее ссылаться на компьютеры по именам, но низко- уровневое сетевое программное обеспечение понимает только числовые адреса. Система DNS играет роль промежуточного связующего звена. Она также важна для маршрутиза- ции электронной почты и организации доступа к веб-серверам. Система DNS представляет собой распределенную базу данных. Термин “распределен- ная” означает, что сведения о компьютерах хранятся на серверах, которые автоматичес- ки вступают в контакт друг с другом, запрашивая данные и обмениваясь информацией. СЗ Информация о документах RFC изложена в разделе 14.1. Система DNS описана в ряде документов RFC, последний из которых имеет номер 108. Существует несколько реализаций этой системы, которые отличаются друг от дру- га по функциональным возможностям, целям и степени соответствия документам RFC. Доли рынка, занимаемые этими реализациями, приведены в табл. 17.1. В главе содержится общая информация о системе DNS и рутинных действиях систем- ного администратора, связанных с реализациями серверов имен BIND, NSD и Unbound. Приведенные примеры относятся к серверам BIND 9.7, NSD 3.2.4 и Unbbound 1.4.1.
598 Часть II. Работа в сети Таблица 17.1. Некоторые распространенные реализации системы DNS Название BIND ISC isc.org 80,3% Авторизация или кеширование Microsoft DNS Microsoft microsoft.com 15,4% Мириады уведомлений о статических IP-адресах djbdns6 Dan Bernstein tinydns.org 2,6% Не соответствует некоторым докумен- там RFC PowerDNS PowerDNS BV powerdns.com 0,7% Только авторизация NSD8 NLnet Labs nlnetlabs.nl <0,1% Только авторизация, очень быстрая Unbound NLnet Labs unbound.net - Только кеширование, быстрое а Доля рынка в соответствии с июльским обзором Internet Domain Survey 2009 года, размещенным на сайте ics.org. 6 Известна также под названием tinydns в качестве компонента пакета djbdns. 8 Задумывалась для корневых серверов и серверов домена верхнего уровня; в настоящее время использу- ется повсеместно. Может возникнуть вопрос, зачем вообще описывать здесь серверы NSD и Unbound, если их рыночная доля такая маленькая. На это есть три причины. • Для того чтобы развернуть действительно надежную среду DNS, необходимо, чтобы не все серверы работали на одном и том же программном обеспечении. Успешная атака на систему DNS вашего сайта отключит вас от Интернета. Раз- нообразие программного и аппаратного обеспечения, а также средств, обеспечи- вающих связность сети, является ключевым фактором выживания в Интернете. Добавьте к этому географическое расположение и опыт системного администрато- ра, и вы будете в прекрасной форме. • Серверы NSD и Undound работают намного быстрее, чем BIND. • И наконец, среди всех реализаций серверов имен только BIND и NSD/Unbound реализуют систему DNSSEC — криптографическое расширение системы DNS. В настоящее время многие сайты (возможно, большинство) не используют ни сер- вер BIND, ни сервер NSD/Unbound, предпочитая службу Active Directory компании Microsoft. Эта служба кратко описана в разделе 30.9. 17.1. Основные задачи системы DNS Система DNS определяет следующее: • иерархическое пространство имен компьютеров и IP-адресов; • таблицу имен и адресов компьютеров, реализованную в виде распределенной базы данных; • “распознаватель” — клиентскую библиотеку функций, осуществляющих запросы к базе данных DNS; • усовершенствованные средства маршрутизации и аутентификацию отправителей сообщений электронной почты; • механизм поиска служб в сети; • протокол обмена информацией об именах.
Глава 17. Система доменных имен 599 DNS — это клиент-серверная система. Серверы (называемые серверами имен) загру- жают данные из клиентских DNS-файлов в память и пользуются ими при ответах на запросы как от внутренних клиентов, так и от внешних компьютеров. Все компьютеры, подключенные к сети, должны быть клиентами системы DNS, но лишь некоторые из них обязаны быть серверами имен. Управление системой DNS В небольшой организации (несколько узлов в одной сети) можно запустить сервер на одном из компьютеров или попросить интернет-провайдера предоставить услуги DNS. Организация среднего размера с несколькими подсетями должна иметь несколько серверов DNS, чтобы сократить время выполнения запросов и повысить общую надеж- ность сети. Очень большая организация может разделить свой домен на поддомены и запустить в каждом из них несколько серверов. Прямое преобразование DNS связывает имя компьютера с IP-адресом. Обратное преобразование ставит в соответствие этому адресу имя компьютера. Прямые и обрат- ные преобразования по возможности должны осуществляться в одном месте. Некоторые провайдеры с удовольствием отдают контроль над прямым преобразованием, но отказы- ваются делать то же самое в отношении обратного преобразования. Подобное разделе- ние обязанностей ведет к проблемам синхронизации. В разделе 17.8 описан элегантный прием, позволяющий управлять делегированием даже крошечных фрагментов адресного пространства. Домены DNS должны обслуживаться как минимум двумя серверами, хотя рекомен- дуется использовать три сервера, расположенных в разных местах. Чаще всего один из этих серверов назначается главным (первичным), на котором хранится копия данных домена. Остальные серверы являются резервными (вторичными). Они загружают ин- формацию из главного сервера организации. Некоторые организации управляют только главным сервером, а серверы провайдера являются резервными. После того как система сконфигурирована, серверы провайдера автоматически загружают информацию из главного сервера организации. Изменения в конфигурации DNS отражаются на резервных серверах без вмешательства администра- торов любой из сторон. Кроме того, часто все службы DNS реализуют за пределами организации, полагаясь на разнообразие компаний, их надежность и географическое распределение. Не размещайте все серверы DNS в одной сети. Если по какой-то причине она ока- жется недоступной, пользователи других сетей не смогут работать. Распределите серверы DNS так, чтобы функционирование системы не зависело от единственного звена. При правильном конфигурировании DNS становится высоконадежной системой. 17.2. Как работает система DNS Каждый компьютер, пользующийся услугами службы DNS, является либо клиен- том этой системы, либо одновременно и клиентом, и сервером. Читатели, которые не планируют запускать серверы DNS, следующие несколько разделов могут пропустить, перейдя сразу к разделу 17.3. Отметим, однако, что приведенная информация позволит глубже понять принципы работы системы доменных имен.
600 Часть II. Работа в сети Записи о ресурсах Каждая организация поддерживает один или несколько фрагментов распределенной базы данных, лежащей в основе всемирной системы DNS. Ваш фрагмент данных со- стоит из текстовых файлов, содержащих записи о каждом компьютере вашей сети; эти записи называются “записями о ресурсах”. Каждая запись представляет собой отдель- ную строку, состоящую из имени (обычно имени компьютера), типа записи и некото- рых значений. Поле имени можно не указывать, если его значение совпадает с именем в предыдущей строке. Например, строки nubark IN А 63.173.189.1 IN MX 10 mailserver.atrust.com. в файле “прямого преобразования” (с именем atrust.com) и строка 1 IN PTR nubark.atrust.com. в файле “обратного преобразования” (с именем 63.173.189.rev) связывают сайт nubark.atrust.com с IP-адресом 63.173.189.1. Запись MX перенаправляет сообщение электронной почты, адресованное на эту машину, на компьютер mailserver. atrust. com. Записи о ресурсах — это универсальный язык системы DNS. Они не зависят от фай- лов конфигурации, управляющих операциями, которые выполняются на любой реали- зации данного сервера DNS. Все они являются фрагментами данных, циркулирующих внутри системы DNS, и кешируются в разных местах. Делегирование Все серверы имен считывают имена корневых серверов из локальных файлов конфи- гурации или содержат их в своем коде. Корневые серверы “знают” о доменах com, org, edu, f i, de и других доменах верхнего уровня. Эта цепочка продолжается дальше: сервер домена edu “знает” о домене colorado.edu, berkely.edu, сервер домена сот “знает” о домене admin. com и т.д. Каждая зона может делегировать полномочия по управлению своими поддоменами другим серверам. Рассмотрим реальный пример. Предположим, требуется узнать адрес узла vangogh. cs.berkeley.edu, находясь на узле lair.cs.colorado.edu. Компьютер lair про- сит локальный сервер имен, ns. cs. Colorado. edu, найти ответ на этот вопрос. После- дующие события представлены на рис. 17.1. 'Рекурсивные j' Рис. 17.1. Обработка запроса в DNS
Глава 17. Система доменных имен 601 Числа возле стрелок определяют порядок событий, а буквы — тип транзакции (за- прос, ответ или ссылка). Предполагается, что никакие из требуемых данных предвари- тельно не кешировались, за исключением имен и IP-адресов серверов корневого домена. Локальный сервер имен не “знает” адреса компьютера vangogh. Более того, ему ничего не известно о доменах cs.berkeley.edu, berkeley.edu и даже edu. Он “зна- ет” лишь некоторые серверы корневого домена, запрашивает корневой домен об узле vangogh. cs. berkeley. edu и получает ссылку на серверы в домене edu. Локальный сервер имен является рекурсивным. Если ответ на запрос содержит ссыл- ку на другой сервер, то локальный сервер повторно направляет запрос новому серверу. Он продолжает этот процесс, пока не найдет требуемый сервер. В нашем примере локальный сервер имен посылает запрос серверу домена edu (как всегда, запрашивая компьютер vangogh. cs. berkeley. edu) и получает ссылку на неза- висимые серверы домена berkeley. edu. Затем локальный сервер повторяет запрос, на- правляя его в домен berkeley. edu. Если сервер университета Беркли не содержит ответ в кеше, он вернет ссылку на домен cs.berkeley.edu. Сервер этого домена компетентен в отношении запрашиваемой информации и возвращает адрес компьютера vangogh. По окончании процедуры в кеше сервера ns . cs . Colorado. edu окажется адрес компьютера vangogh. В кеше будут также находиться списки серверов доменов edu, berkeley.edu и cs.berkeley.edu. Детали процедуры запроса можно выяснить с помощью утилит dig +trace или drill -Т.1 Кеширование и эффективность Кеширование повышает эффективность поиска: кешированный ответ выдается поч- ти мгновенно и обычно точен, так как адресно-именные соответствия меняются редко. Ответ хранится в течение периода времени, называемого TTL (time to live), продолжи- тельность которого задается владельцем искомой записи. Большинство запросов каса- ется локальных компьютеров и обслуживается быстро. Повышению эффективности не- вольно содействуют и сами пользователи, так как многие запросы повторяются. Обычно записи о ресурсах вашей организации должны использовать период TTL, продолжительность которого, как правило, лежит в диапазоне от одного часа до одно- го дня. Чем дольше период TTL, тем меньше трафик сети, потребляемый интернет- клиентами, получающими свежие копии записи. Если у вас есть специальная служба, загрузка которой сбалансирована между логи- ческими подсетями (этот процесс называется “балансированием загрузки глобального сервера”), вы можете потребовать, чтобы поставщик услуг, выполняющий балансиро- вание загрузки, выбрал более короткую продолжительность TTL, например десять се- кунд или одну минуту. (Короткий период TTL позволяет балансировщику загрузки бы- стро реагировать на бездействие серверов и атаки на основе отказа в обслуживании.) Система с короткими периодами TTL продолжает работать корректно, но ваши серверы имен должны работать в более интенсивном режиме. В примере, описанном выше, про- должительность периодов TTL была установлена так: на корневых серверах —- 42 дня, в домене edu — два дня, в домене berkeley. edu — два дня и один день — для сайта vangough.cs.berkeley.edu. Это разумные величины. Если вы планируете крупную перенумерацию, то можете сделать периоды TTL короче, чем раньше. 1 Утилиты dig и drill — это инструменты системы DNS; утилита dig входит в дистрибутив- ный набор сервера BIND, а утилита drill разработана группой NLnet Labs.
602 Часть II. Работа в сети Серверы DNS также реализуют негативное кеширование. Иначе говоря, они помнят, в каких ситуациях запрос остался без ответа, и не повторяют его, пока не истечет период TTL для негативного кеширования. Ответы при негативном кешировании сохраняются в следующих ситуациях. • Нет узла или домена, соответствующего запрашиваемому имени. • Данные запрашиваемого типа для данного узла не существуют. • Запрашиваемый сервер не отвечает. • Сервер недоступен из-за проблем в сети. Сервер BIND кеширует данные в двух первых ситуациях, а сервер Unbound — во всех четырех. Количество повторений негативного кеширования можно задавать в любой реализации. Неоднозначные ответы Сервер имен в ответ на запрос часто получает несколько записей. Например, при по- пытке узнать адрес сервера имен корневого домена можно получить список, содержа- щий все 13 корневых серверов. Большинство серверов имен возвращает ответы в слу- чайном порядке, выполняя примитивный вид балансирования загрузки. Можно достичь балансирования загрузки своих серверов, закрепив одно имя за не- сколькими IP-адресами (которые в реальности соответствуют разным компьютерам). WWW IN A 192.168.0.1 IN A 192.168.0.2 IN A 192.168.0.3 Интенсивно эксплуатируемые веб-серверы, такие как Yahoo! и Google, в действи- тельности не являются одним компьютером. Они просто известны под одним доменным именем в DNS. 17.3. DNS для нетерпеливых: подключение НОВОГО КОМПЬЮТЕРА Прежде чем погружаться в детали функционирования DNS, ответим на наиболее ча- сто задаваемые вопросы. • Как подключить новый компьютер к сети, где уже используется сервер имен? • Как указать в конфигурации, что новый компьютер является клиентом системы DNS? Ниже приводится алгоритм, в котором не определяются и не объясняются никакие термины и который, возможно, не точно соответствует правилам и процедурам систем- ного администрирования, принятым в вашей организации. Отнеситесь к нему с осторож- ностью и изучите документ RFC1912 Common DNS Operational and Configuration Errors. Добавление новой машины в систему DNS Если ваша сеть настроена на использование протокола DHCP (Dynamic Host Con- figuration Protocol), то вы можете вообще не выполнять никаких действий для конфигу- рирования системы DNS. При подключении нового компьютера сервер DHCP ин- формирует его о серверах DNS, которым он должен посылать запросы. Отображение
Глава 17. Система доменных имен 603 “имя-адрес” для использования компьютера во внешнем мире обычно задается при на- стройке конфигурации сервера DHCP, и оно автоматически вводится с помощью средств динамического обновления системы DNS. В сетях, не использующих протокол DHCP, для обновления конфигурации системы DNS необходимо выполнить следующий алгоритм, в ходе которого происходит копиро- вание и редактирование записей об аналогичном компьютере. Этап 1. Выберите для нового компьютера свободные сетевое имя и IP-адрес, согла- совав их с системным администратором или интернет-провайдером. Этап 2. Найдите похожий компьютер в той же подсети. Мы воспользуемся записями этого компьютера в качестве модели для новых записей. В нашем примере мы исполь- зуем в качестве модели компьютер с именем templatehost. example. com в подсети 208.77.188.0/24. Этап 3. Зарегистрируйтесь на компьютере, который является главным сервером имен. Если вы не знаете, какая машина является главным сервером, то для его идентифика- ции вы можете использовать команду dig (dig SOA имя_домена). (Если утилита dig не инсталлирована, можно использовать утилиту drill.) Этап 4а (для организаций, использующих серверы BIND). • Найдите файл конфигурации; как правило, это файл /etc/named. conf. • Найдите в инструкции options файла named, conf строку directory, где сооб- щается о местонахождении зонных файлов в системе (см. раздел 17.9). В этих фай- лах хранятся реальные имена и IP-адреса компьютеров. • Найдите в инструкциях zone имена файлов зон прямого и обратного преобразова- ний для сети, к которой принадлежит новый IP-адрес (см. раздел 17.9). • Проверьте по инструкциям zone, действительно ли данный сервер является глав- ным сервером домена (имеет тип master, а не slave или какой-то другой тип). Если это не так, вы зашли в другую систему! Инструкция в зоне прямого преоб- разования в файле /etc/named. conf должна выглядеть примерно следующим об- разом. zone "example.com” { type master; file "имя_ файла"; Инструкция в зоне обратного преобразования должна выглядеть примерно так. zone "188.77.208.in-addr.arpa'’ { type master; file "имя_файла"; zone "example.com" { type master; file "имя—файла"; Этап 46 (для организаций, использующих серверы NSD). • Найдите файл конфигурации сервера NSD /etc/nsd/nsd. conf. • Найдите инструкцию zone, соответствующую вашему домену в файле nsd. conf (каждая зона идентифицируется ключевым словом name). • Проверьте, действительно ли данный сервер является главным сервером домена! Инструкция в зоне, соответствующей вашему домену, будет содержать предложение
604 Часть II. Работа в сети provide-xfг. Если она содержит предложение request-xf г, то это вторичный сервер данной зоны и вы находитесь на неправильном компьютере. Инструкция в зоне прямого преобразования должна выглядеть примерно следующим образом. zone: name: example.com zonefile: /var/nsd/prinary/example.com; provide-xfr: ip-адрес tsig.key.name notify: ip-адрес NOKEY Инструкция в зоне обратного преобразования должна выглядеть примерно так. zone: name: 188.77.208.in-addr.arpa zonefile: /var/nsd/prinary/188.77.208.in-addr.arpa provide-xfr: ip-адрес tsig.key.name notify: ip-адрес NOKEY • Запишите имена файлов, указанных как аргументы после ключевого слова zonefile в зонах прямого и обратного преобразований. Этап 5. Перейдите в каталог файлов зон и отредактируйте файл зоны прямого пре- образования. Найдите записи, соответствующие компьютеру-прототипу. Они будут вы- глядеть примерно так. templatehost IN А 128.138.243.100 IN MX 10 mail-hub IN MX 20 templatehost Ваша версия может не содержать строк MX, которые используются для маршрутиза- ции почты. Кроме того, ваши зонные файлы могут не содержать спецификатор IN (по умолчанию) или использовать прописные буквы. Этап 6. Скопируйте эти записи и модифицируйте их должным образом для нового:^ компьютера. Записи зонного файла могут быть отсортированы по именам компьютеров, поэтому следуйте принятым соглашениям. , , Этап 7. Измените порядковый номер записи SOA, расположенной в начале файла (это первый из пяти числовых параметров записи). Порядковый номер может только во- зрастать. Прибавьте к нему единицу, если порядковые номера выбираются произвольно, или запишите в это поле текущую дату, если в системе используется такое соглашение2. Этап 8. Отредактируйте запись, соответствующую компьютеру-прототипу, чтобы она приняла следующий вид. 100 IN PTR templatehost.example.com. Скопируйте измененную запись. Обратите внимание на последнюю точку после име- ни компьютера; не забудьте о ней. Если в файле зоны обратного преобразования приводится не только последний байт IP-адреса узла, то числа нужно вводить в обратном порядке. Например, запись 100.188 IN PTR templatehost.my.domain. соответствует IP-адресу 208.77.188.100 (здесь зона обратного преобразования относится к домену 77.208 . in-addr .arpa, а не 188.77.208 . in-addr. arpa). Этап 9. Обновите порядковый номер в записи SOA в зоне обратного преобразования, как описано на этапе 7. 2 Соглашение о датах предусматривает двузначное количество изменений, например в течение дня вы можете сделать до 99 изменений.
Глава 17. Система доменных имен 605 Этап 10а. Если вы работаете с сервером BIND и ленитесь, то выполните команду ndc reload. Если сервер занят, вы можете перезагрузить только домены (или представления), которые вы изменили. $ sudo mdc reload зона_прямого_преобразования $ sudo mdc reload зона_обратного_преобразования Этап 106. Если вы используете сервер NSD, выполните команду nsdc reload, а за- тем nsdc restart. Этап 11. Проверьте конфигурацию с помощью команды dig (описана в разде- ле 17.15). Попробуйте также выполнить команды ping или traceroute, задав имя но- вого компьютера, даже если он еще не сконфигурирован. Сообщение “host unknown” (неизвестный узел) свидетельствует о наличии ошибки. Сообщение “host not responding” (узел не отвечает) означает, что все в порядке. Чаще всего системные администраторы совершают ошибки, забыв о следующем: • обновить порядковый номер (этапы 7 и 9); • перезапустить сервер имен (этап 10); • добавить точку в конец доменного имени в записи PTR в зоне обратного преоб- разования (этап 8). Настройка конфигурации клиента DNS У каждого компьютера, подключенного к сети, должен быть клиент, представляю- щий собой сервер имен. Конфигурация клиентской части системы DNS задается в фай- ле /etc/resolv.conf, в котором перечисляются DNS-серверы, которым можно посы- лать запросы, когда пользователь пытается преобразовать имя компьютера в 1Р-ад®ес (например, запрашивает веб-страницу, посылает сообщение по электронной почте или использует Интернет).3 Если ваш компьютер получает свой IP-адрес и сетевые параметры от DHCP-сервера, то файл /etc/resolv.conf должен заполняться автоматически. В противном случае его нужно редактировать вручную. Формат записей файла имеет следующий вид. search имя_домена ... option имя_опции nameserver IP-адрес Может быть указано от одного до трех серверов имен. Рассмотрим пример. search atrust.com booklab.atrust.com nameserver 63.173.189.1 ; nsl nameserver 174.129.219.225 ; ns2 Для файла resolv.conf никогда не вводилось понятие комментариев. Они поддер- живаются лишь в том смысле, что любой нераспознанный элемент файла игнорируется. Комментарии вполне безопасны в конце директивы name serve г, поскольку анализатор файла ищет лишь IP-адрес, игнорируя остальную часть строки. Тем не менее, в директи- ве search их лучше не использовать, так как она может содержать несколько аргументов. В строке search приведен список доменов, которые следует опрашивать, если имя компьютера определено не полностью. Например, когда пользователь вводит команду ssh coraline, то распознаватель дополняет имя первым доменом в списке (в рассмо- 3 В системе Windows клиентская часть системы DNS настраивается с помощью панели конфи- гурации протокола TCP/IP для каждой сетевой платы. Точное содержание этой процедуры зависит °т версии системы Windows.
606 Часть II. Работа в сети тренном выше примере — at rust. com), после чего ищет узел coral ine. a trust. com. Если это имя не найдено, делается попытка найти узел coraline .booklab. at rust. com. Количество доменов, которые можно задать в директиве search, зависит от спец- ифики распознавателя; большинство из них допускает от шести до восьми доменов, при этом предельное количество символов равно 256. Серверы имен, указанные в файле resolv. conf, должны разрешать вашему компью- теру посылать запросы и обязаны давать на них полные ответы (т.е. быть рекурсивны- ми), а не отсылать вас на другие серверы имен. Серверы имен опрашиваются по порядку. Если первый сервер отвечает на запрос, другие серверы игнорируются. Если возникает проблема, то по истечении времени, отведенного для ответа на запрос, он переадресует- ся следующему серверу. Все серверы опрашиваются по очереди, до четырех раз каждый. С каждой неудачей тайм-аут увеличивается. По умолчанию интервал тайм-аута задается равным пяти секундам, что для нетерпеливых пользователей кажется вечностью. Инструкция options может изменять интервал тайм-аута, количество попыток и поведение по умолчанию при выборе перечисленных серверов имен. Доступные опции этой инструкции зависят от реализации библиотеки распознавателя. Ниже описан пакет libbind для системы ISC. Эта информация относится ко всем системам, кроме HP- UX. Чаще всего имя ближайшего сервера указывается первым в строке nameservers, но если вы хотите сбалансировать загрузку между одинаково компетентными серверами, следует использовать опцию rotation. Например, инструкция options rotate timeout:2 attepmts:2 обращается к перечисленным серверам имен по очереди, ожидает ответа две секунды и запрашивает каждый сервер не более двух раз. Система HP-UX не полностью поддерживает инструкцию options, описан- ную выше. В этой системе продолжительность тайм-аута и количество попы- ток запроса задаются непосредственно в файле resolv. conf. retrans продолжительность_тайм-аута_в_миллисекундах retry количество_попыток Большинство распознавателей позволяют включать в список не более трех серверов; имен. Если указать больше, то “лишние” серверы будут по умолчанию проигнорирова-* ны. Правила, установленные по умолчанию, приведены в табл. 17.2. ' Таблица 17.2. Правила, установленные по умолчанию для файла /etc/resolv.conf Система Максимальное кол-во серверов имен 111 ' ' V- 111 U Максимальная длина поисковойстроки Тайм-аут, с. Попытки -Ц Linuxs 3 6 доменов, 256 символов 5 2 Solaris 3 6 доменов, 256 символов 5 2 HP-UX 3 6 доменов, 256 символов 5 4 AIX 3 6 доменов, 1024 символа 5 2 Если компьютер сам является сервером имен, то он должен быть указан первым в собственном файле resolv.conf. Если в файле не указан ни один сервер имен, то компьютер считается рабочей станцией. Файл resolv. conf также распознает директиву domain, представляющую собой альтернативу директиве search; она задает единственный домен, который должен до- бавляться к не полностью квалифицированным именам. Это устаревшая форма; мы
Глава 17. Система доменных имен 607 рекомендуем заменить директиву domain директивой search везде, где она встречает- ся. Эти директивы взаимно исключают друг друга, поэтому использовать можно только одну из них. Если вы невольно использовали обе эти директивы одновременно, то вы- полняться будет только последняя. Если файл /etc/resolv.conf отсутствует, то для того, чтобы решить, как распознать имя и извлечь из имени компьютера, которое должно быть пол- ностью квалифицированным, имя домена, заданное по умолчанию, система AIX использует файл /etc/netsvc. conf. Система AIX хранит образец файла resolv.conf в виде файла /usr/lpp/tcpip/samples/resolv.conf, кото- рый можно скопировать. Поскольку добавлять множество строк в текстовый файл довольно неудобно, в системе AIX предусмотрена команда namerslv, обеспечивающая интерфейс для добавления, удаления и изменения серверов имен в файле resolv.conf. Но это еще не все! Вы также можете использо- вать команды mknamsv, rmnamsv, chnamsv и Isnamsv в качестве интерфейсов высокого уровня для команды namerslv. (Разумеется, системный админи- стратор не должен разбираться во всех сложных интерфейсах, поэтому вам, вероятно, понадобится графический пользовательский интерфейс; попробуй- те выполнить команду smitty resolv.conf.) После того как файл /etc/resolv.conf будет сконфигурирован, система станет ис- пользовать в качестве сервера имен сервер DNS, поскольку этот сервер не был отклю- чен в файле, назначающем приоритеты источникам административных данных (/etc/ nsswitch. conf или /etc/netsvc. conf в системе AIX; см. раздел 19.5). После конфигурирования файла /etc/resolv.conf вы должны иметь возможность ссылаться на другие машины по именам, а не по IP-адресам. Попробуйте выполнить команду ping имя_компьютера. Если вы пытаетесь найти другой локальный компью- тер и команда просто зависает, попытайтесь сослаться на его IP-адрес. Если этот прием сработал, значит, в вашей конфигурации DNS есть проблема. Проверьте, правильно ли записаны IP-адреса серверов имен в файле /etc/resolv и позволяют ли серверы, на которые ссылаетесь, посылать запросы из вашей сети (см. раздел 17.9). Ответить на эти вопросы позволит утилита dig, выполненная на работающем компьютере. 17.4. Серверы имен Сервер имен выполняет несколько рутинных операций. • Отвечает на запросы об именах и IP-адресах компьютеров. • Посылает запросы локальным и удаленным компьютерам от имени своих пользо- вателей. • Кеширует ответы на запросы, для того чтобы ускорить ответы на них в следующий раз. • Пересылает данные между серверами имен, чтобы обеспечить их синхронизацию. Серверы имен работают с зонами, которые представляют собой домен без поддоменов. Часто термин “домен” употребляется как синоним термина “зона”, даже в этой книге. Серверы NSD/Unbound разделяют функции, обеспечивающие ответы на запросы о ваших узлах (компетенция сервера NSD), и функции, связанные с посылкой запросов ° Других доменах от имени ваших пользователей (компетенция сервера Unbound). Это Разумно.
608 Часть II. Работа в сети Серверы имен работают в нескольких разных режимах, поэтому дать их точное опре- деление нелегко. Ситуация усложняется еще и тем, что один и тот же сервер может вы- полнять неодинаковые функции в разных зонах. В табл. 17.3 перечислены прилагатель- ные, употребляемые при описании серверов имен. Таблица 17.3. Классификация серверов имен Типседора ? авторитетный (authoritative) Официальный представитель зоны главный (master) Основное хранилище данных зоны; берет информацию из дискового файла подчиненный (slave) Копирует данные с главного сервера усеченный (stub) Напоминает подчиненный сервер, но копирует данные только о серверах имен (записи NS) внутренний (distribution) Сервер, доступный только в пределах домена (также называется невидимым сервером) неавторитетныйа (nonauthoritative) Отвечает на запросы, пользуясь данными из кеша; не “знает”, являются ли эти данные корректными кеширующий (caching) Кеширует данные, полученные от предыдущих запросов; обычно не имеет локальных зон переадресующий (forwarder) Выполняет запросы от имени многих клиентов; формирует большой кеш рекурсивный (recursive) Осуществляет запросы от имени клиента до тех пор, пока не будет найден ответ нерекурсивный (nonrecursive) Отсылает клиента к другому серверу, если не может получить ответ на запрос а Строго говоря, атрибут “неавторитетный” относится к ответу на DNS-запрос, а не к самому серверу. Серверы имен систематизируются на основании источника данных (авторитетный, кеширующий, главный, подчиненный), типа хранимых данных (усеченный), пути рас- пространения запроса (переадресующий), типа выдаваемого ответа (рекурсивный, не* рекурсивный) и, наконец, доступности сервера (внутренний). В следующих подразделах конкретизируются наиболее важные из этих различий; об остальных различиях пойдет речь в других разделах главы. Авторитетные и кеширующие серверы Главный, подчиненный и кеширующий серверы различаются только двумя характе- ристиками: откуда поступают данные и авторитетен ли сервер для домена. Сервер BIND может относиться ко всем трем типам, сервер NCD — только к главному или подчинен- ному, а сервер Unbound — только к кеширующему. В каждой зоне есть один главный сервер имен.4 На нем хранится официальная копия данных зоны (в файле на диске). Системный администратор модифицирует информа- цию, касающуюся зоны, редактируя файлы главного сервера. Подчиненный сервер копирует свои данные с главного сервера посредством опера- ции, называемой передачей зоны (zone transfer). В зоне должен быть как минимум один подчиненный сервер. Усеченный сервер — особый вид подчиненного сервера, загружа- ющий с главного сервера только записи NS (описания серверов имен). О том, зачем соз- 4 Некоторые организации используют несколько главных серверов или вообще обходятся без них; мы описываем вариант, в котором существует один главный сервер.
Глава 17. Система доменных имен 609 дается такой сервер, пойдет речь в разделе 17.9. Один и тот же компьютер может быть главным сервером для одних зон и подчиненным — для других. Ш О передаче зоны рассказывается в разделе 17.12. Кеширующий сервер имен загружает адреса серверов корневого домена из конфигу- рационного файла и накапливает остальные данные, кешируя ответы на выдаваемые им запросы. Собственных данных у кеширующего сервера нет, и он не является авторитет- ным ни для одной зоны (за исключением, возможно, зоны локального компьютера). Гарантируется5, что авторитетный ответ сервера имен является точным; неавторитетт ный ответ может быть устаревшим. Тем не менее очень многие неавторитетные ответы оказываются совершенно корректными. Главные и подчиненные серверы авторитетны для своих зон, но не для кешированной информации о других доменах. По правде го- воря, даже авторитетные ответы могут быть неточными, если системный администратор изменил данные главного сервера (например, обновил порядковый номер зоны) и забыл передать их подчиненным серверам. Серверы имен должны находиться на надежных и безопасных компьютерах, имею- щих небольшое количество пользователей и подключенных к источнику бесперебойного питания. Требуется наличие хотя бы одного подчиненного сервера. В идеале подчинен- ных серверов имен должно быть минимум два, причем один из них — вне организации. Подчиненные серверы на местах должны быть включены в разные сети и в разные цепи электроснабжения. Если служба имен вдруг перестанет функционировать, пользователи не смогут нормально работать в сети. Кеширующие серверы неавторитетны, зато позволяют сократить объем DNS-трафика во внутренней сети и уменьшить время, затрачиваемое на выполнение DNS-запросов. В большинстве организаций DNS-запросы от настольных компьютеров обычно прохо- дят через кеширующий сервер. Более крупные организации должны использовать не- сколько кеширующих серверов. С точки зрения безопасности и общей надежности системы DNS желательно разде- лить функции, связанные с обслуживанием ваших авторитетных данных. Рекурсивные и нерекурсивные серверы Серверы имен бывают рекурсивными и нерекурсивными. Если у нерекурсивного сервера есть адрес, оставшийся в кеше от одного из предыдущих запросов, или он явля- ется авторитетным для домена, к которому относится запрашиваемое имя, то он даст со- ответствующий ответ. В противном случае он вернет отсылку на авторитетные серверы Другого домена, которые с большей вероятностью ответят на запрос. Клиенты нерекур- сивного сервера должны быть готовы принимать отсылки и обрабатывать их. У нерекурсивных серверов обычно есть веские причины не выполнять дополнительную работу. Например, все корневые серверы и серверы доменов верхнего уровня являются не- рекурсивными, поскольку им приходится обрабатывать десятки тысяч запросов в секунду. Рекурсивный сервер возвращает только реальные ответы или сообщения об ошибках. Он сам отслеживает отсылки, освобождая от этой обязанности клиента. Базовая проце- дура анализа запроса, по сути, остается неизменной. Из соображений безопасности, серверы имен организации, доступные извне, всегда Должны быть нерекурсивными. Рекурсивные серверы имен, которые видны извне, мо- гут стать объектом для атаки. 5 Здесь слово “гарантируется” означает, что ответ придет от базы данных, находящейся в па- мяти авторитетного сервера, а не от кеша случайного неавторитетного сервера.
610 Часть II. Работа в сети Библиотечные функции распознавания имен не понимают отсылок. Любой локаль- ный сервер имен, указанный в файле resolv. conf клиента, должен быть рекурсивным. При отслеживании отсылок возникает побочный эффект: в кеше сервера имен нака- пливается информация о промежуточных доменах. При работе в локальной сети от это- го обычно только польза, поскольку в последующих операциях поиска, инициируемых компьютерами этой сети, можно будет пользоваться результатами предыдущих запросов. С другой стороны, сервер домена верхнего уровня (такого, как сот или edu) не должен хранить информацию, запрашиваемую компьютером, который находится на несколько уровней ниже. Серверы имен генерируют отсылки на иерархической основе. Если сервер, к приме- ру, не сможет узнать адрес узла lair. cs. Colorado. edu, он выдаст отсылки к серверам доменов cs. Colorado. edu, Colorado. edu, edu или корневого домена. Отсылка долж- на включать адреса серверов того домена, на который она указывает, поэтому выбор до- мена не случаен: сервер должен ссылаться на домен, серверы которого ему известны. Как правило, возвращается отсылка на наиболее полный из известных доменов. В на- шем примере в первую очередь были бы выданы адреса серверов домена cs. Colorado. edu, при условии что они известны. Если этот домен неизвестен, но известен домен Colorado. edu, были бы выданы адреса его серверов имен, и т.д. Сервер имен предварительно наполняет свой кеш содержимым файла “подсказок”, в котором перечислены серверы корневого домена. Благодаря этому всегда можно сделать отсылку, даже если она гласит: “Спроси у корневого сервера”. 17.5. Пространство имен DNS Это пространство имен представляет собой дерево с двумя основными ветвями, соот- ветствующими прямым и обратным преобразованиям. Прямые преобразования ставят в соответствие именам компьютеров их IP-адреса, а обратные преобразования отобража- ют IP-адреса в имена компьютеров. Каждое полностью определенное имя компьютера (например, nubark. atrust. com) — это узел дерева на ветви прямых преобразований, а каждый IP-адрес — это узел дерева на ветви обратных преобразований. Уровни дерева разделяются точками; корнем дерева является точка. Полностью определенное имя компьютера можно рассматривать как некое обо- значение, в котором “самая важная часть” находится справа. Например, имя nubarк. atrust. com означает, что компьютер nubark находится в поддереве atrust, а поддере- во atrust — в поддереве com. С другой стороны, в IP-адресе “самая важная часть” на- ходится слева. Например, адрес 128.138.243.100 означает, что узел 100 находится в под- сети 243, которая является частью сети 128.138. Для того чтобы система DNS могла работать с данными обоих видов, ветвь IP-адре- сов в пространстве имен инвертируется, т.е. октеты IP-адресов записываются в обрат- ном порядке. Например, если узел “nubark. atrust. com. ” имеет адрес 63.173.189.1, то соответствующий узел на ветви прямых преобразований в дереве имеет имя “nubark. atrust. com. ”, а узел на ветви обратных преобразований имеет имя “1.189.173.63. in-addr. агра. ”6. Эти имена завершаются точкой, аналогично тому как полные имена файлов начинаются с косой черты. Полностью определенное доменное имя (FQDN — Fully Qualified Domain Name) — это полный путь к объекту в системе DNS, включая последнюю точку. Например, полно- 6 Часть имени in-addr. агра представляет собой фиксированный суффикс.
Глава 17. Система доменных имен 611 стью определенное имя узла nubark в домене atrust. com записывается как “nubark. at rust. com. ”. Домен (domain) — это поддерево дерева имен DNS. Например, домен atrust.com содержит узел atrust. com и все поддомены и дочерние узлы узла atrust. com. В про- тивоположность домену, зона — это домен без поддоменов, которые были делегированы другим серверам имен. Если домен atrust. com далее разделить на поддомены engineering, marketing и booklab, то он будет содержать четыре зоны: исходную зону atrust. com, а также зоны engineering.atrust.com, marketing.atrust.com и booklab.atrust.com. Зона atrust. com содержит все узлы, находящиеся в домене atrust. com, за исключе- нием узлов, относящихся к зонам engineering. atrust. com, marketing. atrust. com и booklab.atrust.com. Имена серверов ассоциируются с зонами, а не доменами. Проверив систему DNS, пользователь может выяснить, что заданное имя (например, booklab.atrust.com) идентифицирует поддомен, а не узел. Поддомены имеют записи серверов имен (NS), связанные с ними. Изначально имена доменов состояли из букв, чисел и косых черт, причем каждый компонент (метка) не мог содержать более 63 символов, а полностью определенное до- менное имя (FQDN) — более 256 символов. Имена FQDN не чувствительны к регистру, но обычно записываются с помощью строчных букв. Ограничения на доменные имена были ослаблены в документе RFC2181. Продолжающаяся интернационализация доменных имен оказывает влияние на эти правила. В результате ограничения на длину полностью определенных доменных имен были ослаблены. Кроме того, допускается использование символов, не принадлежащих латинскому алфавиту и представленных с помощью метода кодирования Рипу08^по- хожего на стандарт Unicode, но все же отличающегося от него деталями реализации. Существует два типа доменов верхнего уровня: национальные домены верхнего уров- ня (ccTLD — country code top-level domain) и общие домены верхнего уровня (gTLD — generic top level domain). Организация ICANN (International Corporation for Assigned Names and Numbers) управляет проектом регистрации имен в доменах gTLD, таких как com, net и огд, с помощью аккредитованных агентств. На момент написания книги у вас есть выбор из 1 000 регистраторов и 21 домен gTLD, в которых можно зарегистри- роваться. Точную информацию можно найти на сайте icann.org. В настоящее время корпорация ICANN работает наддааданием большого количества новых общих доменов верхнего уровня. Для регистрации имени в домене ccTLD, зайдите на веб-страницу организации IANA (Internet Assigned Numbers Authority) iana. org/cctld и найдите регистр соответствую- щей страны. Регистрация домена второго уровня Для того чтобы зарегистрировать домен второго уровня, необходимо подать заявку В администрацию соответствующего домена верхнего уровня. Для того чтобы заполнить бланки регистрации, необходимо назначить ответственного технического специалиста и ответственного администратора, а также выбрать хотя бы два компьютера, которые будут серверами домена. Кроме того, необходимо выбрать доменное имя, никем не за- нятое. Стоимость регистрации зависит от агентства, но в настоящее время она относи- тельно небольшая.
612 Часть II. Работа в сети Создание собственных поддоменов Процедура создания поддомена аналогична той, что используется при регистрации домена второго уровня, только центральная администрация теперь находится в пределах самой организации. Этот процесс предусматривает следующие этапы. • Выбор имени, уникального в пределах организации. • Назначение двух или более компьютеров серверами нового домена.7 • Согласование действий с администратором родительского домена. Прежде чем передавать полномочия, администратор родительского домена должен убедиться в том, что серверы имен дочернего домена сконфигурированы и работают правильно. В противном случае произойдет то, что называется некорректное делегирова- нием, и вы получите по электронной почте неприятное сообщение с требованием испра- вить ошибку (подробнее об этом рассказывается в разделе 17.15). 17.6. Разработка собственной среды DNS На разработку надежной и эффективной системы DNS для своего окружения влияет множество факторов: каков, например, размер вашей организации, используете ли вы частные IP-адреса в своей локальной сети в соответствии с документом RFC1918, про- токол DHCP и службу Active Directory, применяете ли вы маршрутизацию или коммута- цию своей внутренней сети, где расположен брандмауэр по отношению к вашим DNS- серверам. Полезно разделить эту проблему на три части. • Управление иерархией пространства имен: поддоменами, многократными уровня- ми и т.д. • Поставка авторитетных данных о вашей организации во внешний мир. • Преобразование имен для пользователей. Управление пространством имен Если ваша организация небольшая и независимая, использование поддоменов не яв- ляется ни необходимым, ни желательным, если ваше руководство не требует этого по каким-то причинам, не имеющим технической природы. С другой стороны, в организа- циях среднего размера с несколькими независимыми группами системного администри- рования поддомены могут уменьшить потребность во взаимодействии на уровне органи- зации. (Чаще всего поддомены выделяются по географическому или организационному принципу.) В крупной организации трудно обеспечивать уникальность имен и поэтому необходимы поддомены, возможно даже многоуровневые. Недавно в системе DNS были определены зонные записи (SPF и DKIM/ADSP), с по- мощью которых можно запрещать другим организациям штамповать почтовые сообще- ния, якобы исходящие из вашего домена. Для оптимального использования этой функ- циональной возможности, возможно, потребуется определить поддомен, ориентируясь на конфиденциальность информации, отправляемой по электронной почте. Более под- робно эта процедура описана в разделе 17.8. Создание поддоменов требует взаимодействия между системными администраторами, отвечающими за родительский и подчиненный домены. При организации и настройке ------------- W 7 С технической точки зрения, поскольку вы сами устанавливаете правила для своего поддо- мена, может быть один сервер или несколько.
Глава 17. Система доменных имен 613 поддомена следует запомнить, с кем вы должны вступить в контакт, если захотите доба- вить, изменить или удалить серверы. Убедитесь, что ваш брандмауэр не блокирует доступ к серверам поддомена, если вы хотите, чтобы поддомен был доступен для внешнего мира. Если вы используете поддомены для управления вашим пространством имен, раз в неделю запускайте утилиту doc (domain obscenity control — контроль корректности до- мена) с помощью программы cron, чтобы убедиться, что делегирование остается син- хронным и вы случайно не выполнили неправильного делегирования. Описание утили- ты doc и некоторых других инструментов, поддерживающих работоспособность системы DNS, изложено в разделе 17.13. Авторитетные серверы Спецификации системы DNS требуют, чтобы в каждом домене было, по крайней мере, два авторитетных сервера. Главный и подчиненный серверы являются авторитет- ными, а кеширующие серверы и заглушки — нет. В идеале организация имеет несколько авторитетных серверов, по одному на каждую отдельную сеть и цепь электропитания. Многие организации поддерживают работу внешних авторитетных серверов, которые часто располагаются у их интернет-провайдеров. Если ваш провайдер не предоставляет таких услуг, вы можете воспользоваться ими у провайдера DNS-службы или договорить- ся с местной фирмой (желательно не с конкурентом) или университетом. Несколько лет назад компания Microsoft попалась на нарушении правила, касаю- щегося разделения сетей. Все три их авторитетных сервера находились в одной и той же подсети, и когда маршрутизатор, соединяющий эту подсеть с Интернетом, дал сбой, серверы стали недоступны. Через два часа, по истечении срока действия записей в кеше, сайт microsoft. com и все его другие домены отключились от Интернета. Количество запросов к именам, связанным с компанией Microsoft, на корневых серверах достигло 25% общей нагрузки (10 тыс. запросов в секунду), хотя эта величина обычно равнялась 0,000001%. Решение проблемы заняло несколько дней. Когда страсти улеглись, компания Microsoft исправила маршрутизатор и передала свою службу DNS внешней организации. Авторитетные серверы поддерживают синхронизацию данных с помощью зонных пере- дач (zone transfers). Для аутентификации и управления переносом зон от главного сервера к подчиненным следует использовать ключи протокола TSIG (transaction signature — под- пись транзакции). Описание конфигурации протокола TSIG приводится в разделе 17.13. Иногда ответы, выдаваемые вашими авторитетными серверами по запросу, зависят от того, кто посылал запрос. Запрос, поступивший из внешнего мира, может иметь один ответ, а тот же самый запрос, поступивший изнутри организации, может иметь другой (более полный) ответ. Эта конфигурация называется “разделением DNS” (“split DNS”) и осуществляется на зонном уровне, а не на уровне сервера имен. Каждая версия зоны называется “представлением”, по аналогии с инструкцией view, с помощью которой задается ее конфигурация в конфигурационном файле сервера BIND. Для внешних пользователей данные имеют одно представление, а для внутрен- них — другое. Эта функциональная возможность широко используется для маскировки внутренних машин от шпионов и для гарантии того, что машины, использующие част- ные IP-адреса в соответствии с документом RFC1918, не раскрывают их в Интернете. Отладка представления представляет собой довольно сложную процедуру, но широкие возможности регистрации, существующие в сервере BIND, в сочетании с правильным использованием команды dig могут помочь. Некоторые подсказки приведены в раз- деле 17.15.
614 Часть II. Работа в сети Сервер NSD не поддерживает представления и разделение DNS. Однако вы можете имитировать эту функциональную возможность, запустив два экземпляра сервера NSD с разными конфигурациями. (Разумеется, вы можете это сделать и с сервером BIND.) Кеширующие серверы Рекурсивные кеширующие серверы отвечают на запросы локальных пользователей относительно сайтов, расположенных в Интернете. Каждый компьютер на вашем сайте должен иметь доступ к локальному кеширующему серверу. Некоторые организации используют иерархию, в которой одна или несколько ма- шин играют роль механизма продвижения данных, через который локальные кеширую- щие серверы подсети передают свои запросы. В связи с этим такие машины создают наполненный кеш, доступный для всего сайта. В зависимости от размера сайта, эти ма- шины могут быть независимыми или образовывать иерархию. Конфигурация механиз- мов продвижения данных в реализации BIND описана в разделе 17.9, а в реализации Unbound — в разделе 17.11. Если кеширующий сервер “падает”, то работа всех сетевых пользователей, являю- щихся основными клиентами этого сервера, практически останавливается.8 (И ваш те- лефон начинает разрываться от звонков.) Загрузите ваши кеширующие серверы имея по сценарию, в котором через несколько секунд после сбоя они перезагружаются. Рас- смотрим пример сценария для машины, применяющей программу named к нескольким доменам верхнего уровня (TLD). #!/bin/sh PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH export PATH trap "" 1 while :; do named -f -c /var/named/named.conf » /var/log/named 2>&1 < /dev/null logger "named restart" sleep 15 done exit Когда выполнение программы named завершается крахом, этот сценарий выводит на экран запись в системном журнале с командой logger, ждет 15 секунд (эта величина за- дается произвольно), а затем повторно запускает программу named. В инсталляционном пакете сервера BIND этот сценарий записан в каталоге contrib, хотя это не обязательно. В системе Solaris существует служба защиты SMF(cm. раздел 3.6). soiaris Требования к аппаратному обеспечению Серверы имен должны быть хорошо оснащенными по трем направлениям: централь- ный процессор, память и пропускная способность сети. Среди них центральный процес- сор, вероятно, в настоящее время является наименее важным фактором, но в будущем 8 Если в клиентском файле /etc/resolv/conf перечислено несколько серверов имен, то ме- ханизм разрешения должен переключиться на один из резервных серверов. Однако слишком часто в этом файле указывается только один сервер имен.
Глава 17. Система доменных имен 615 после полного развертывания набора спецификаций DNSSEC потребуется поддержи- вать возможность подписи зон и проверки их подлинности. По возможности исполь- зуйте специализированные машины в качестве загруженных серверов имен и отделяйте авторитетные серверы от рекурсивных. Загруженные серверы имен получают тысячи запросов в секунду, и, следовательно, им требуются несколько сетевых интерфейсов и сетевые соединения с высокой пропускной способностью. Трафик обычно состоит из огромного количества маленьких пакетов UDP. Рекурсивным серверам требуется достаточный объем памяти для кеширования всех ответов, которых ожидают пользователи. Для того чтобы определить, имеет ли сервер имен достаточный объем памяти, лучше всего запустить его и проследить за размером процесса сервера имен. В течение одной-двух недель эта величина сводится к стабиль- ному размеру, при котором старые записи кеша удаляются с той же скоростью, с кото- рой вставляются новые. В стабильном состоянии система не должна выполнять свопинг, а скорость подкачки страниц должна быть разумной. Если сервер имен функционирует на специализированном компьютере, то объем па- мяти должен быть вдвое больше, чем потребляет демон сервера имен за неделю. Объем использованной памяти демонстрируют команды top и vmstat; более подробная ин- формация приведена в разделе 29.4. Авторитетным серверам требуется довольно большой объем памяти для хранения всех данных, относительно которых они являются авторитетными. Большинство сай- тов может управлять этим процессом, но серверы для доменов верхнего уровня и сайтов DNS-хостинга могут потребовать огромный размер памяти или специальное программ- ное обеспечение, позволяющее хранить данные на диске. Вы можете управлять объемами ресурсов, используемых сервером имен, с помощью опций конфигурации. Список настроек для сервера BIND приведен в разделе 17.9, а для сервера NSD — в разделе 17.11. Безопасность Безопасности системы DNS посвящен раздел 17.13. Мы не собираемся повторять одно и то же и лишь напомним, что при использовании брандмауэра следует убедиться, что система DNS не эмитирует запросы, ответы на которые блокируются брандмауэром. Проверьте также, что ваши администраторы системы DNS взаимодействуют с админи- страторами по вопросам безопасности и администрацией сети. По умолчанию система DNS использует для запросов протокол UDP со случайными непривилегированными портами источников (>1023^ ответами являются пакеты UDP, адресованные тем же портам. При использований набора спецификаций DNSSEC и ин- тернационализированных имен доменов,‘ размеры ответов системы DNS могут превы- шать емкость пути, и поэтому они фрагментируются. Таким образом, ваш брандмауэр не должен блокировать фрагментированные пакеты UDP. Если запрос UDP завершился неудачей из-за фрагментации, то часто он посылается заново как запрос TCP, поэтому брандмауэр должен также пропускать ответы системы DNS по протоколу TCP. Итоги На рис. 17.2 показана архитектура, описанная в предыдущих абзацах. На этом рисунке продемонстрировано четкое разделение кеширующих серверов (слева) для пользователей и авторитетных серверов (справа) для данных. Обратите так- же внимание на подчиненный сервер, находящийся за пределами сайта, что считается очень желательным.
616 Часть II. Работа в сети Запросы изнутри Запросы извне Рис. 17.2. Архитектура сервера DNS Ш Информация об альтернативной адресации описана в разделе 14.4. Калифорнийский университет в Беркли (berkeley. edu) использует альтернативную IP-адресацию для репликации своих кеширующих серверов. Все клиенты контактиру- ют с одним и тем же набором серверов, а система маршрутизации (в данном случае — OSPF) направляет их на ближайший кеширующий сервер. Эта конфигурация порождает простую и логичную конфигурацию клиента и надежную среду DNS. 17.7. Что нового в системе DNS Одним из самых изящных нововведений в системе DNS является использование заг писей DNS для аутентификации и проверки целостности сообщений электронной по- чты. Эта система, получившая название DomainKeys Identified Mail (DKIM), позволя- ет выявлять фишинг (например, письма, которые якобы приходят из вашего банка и в которых вас просят “подтвердить” информацию о вашем банковском счете). Система DKIM позволяет также распознавать спамеров, подделывающих адреса отправителей. В системе DKIM сервер, являющийся источником исходящих сообщений электрон- ной почты, подписывает их с помощью закрытого криптографического ключа. Соответ- ствующий открытый ключ публикуется в виде ТХТ-записи DNS. Получатель сообщения электронной почты может проверить его целостность и происхождение, просмотрев (от- / крытый) ключ DKIM отправителя и сравнив его с подписями самого сообщения. Система DKIM не требует изменения программного обеспечения системы DNS, но она предполагает взаимодействие сервера, являющегося источником почтовых сообще- ний (для их подписи), и сервера, получающего эти сообщения (для проверки подписей). С точки зрения системы DNS для поддержки нового поддомена с именем domainkey требуется лишь изменить файлы конфигурации и данных. Кроме того, правила Author Domain Signing Practice (ADSP) позволяют сайту сооб- щать, подписывает ли он все, часть или вообще не подписывает исходящие сообщения электронной почты для каждой зоны DNS. Сайты-получатели могут использовать эту политику, чтобы решить, как поступать с неподписанными сообщениями, а также с со- общениями, подпись которых невозможно верифицировать. Например, банк, генерирующий несколько категорий сообщений электронной по- чты (например, маркетинговые письма, письма о состоянии счетов и инструкции по электронным платежам), может создавать поддомены для каждой функции и устанавли- вать для них разные политики. Получатели могут игнорировать отсутствие или несоот-
Глава 17. Система доменных имен 617 ветствие подписи оригиналу на рекламных письмах, но отклонять сообщения, которые должны иметь высокий уровень безопасности. Этот механизм напоминает систему Sender Policy Framework (SPF), определяющую способ, с помощью которого организации публикуют имена своих правильных почто- вых серверов в системе DNS, чтобы распознавать спамеров, желающих подделать адрес отправителя, и отклонять их письма. В списке новшеств мы указываем также сервер BIND 10, представляющий собой сле- дующее поколение программного обеспечения BIND, разрабатываемого консорциумом ISC (Internet System Consortium), поддерживающим сервер BIND, начиная с четвертой версии. Разработка сервера BIND 10 была оплачена спонсорами со всего мира, в основ- ном регистраторами доменов. Сервер BIND 10 по-прежнему представляет собой открытую реализацию системы DNS. Частично он основывается на версии BIND 9 и основное внимание уделяет по- вышению модульности, гибкости, интеграции, устойчивости и управляемости во время выполнения. Сервер BIND 9 и более ранние версии хранили базу данных DNS в памяти; сервер BIND 10 поддерживает работу нескольких систем хранения данных. Еще одна запла- нированная функциональная возможность сервера — это удобный пользовательский графический интерфейс API. Он облегчит заполнение зон и управление программным обеспечением. Подробная информация об этом приведена на сайте ics. org/bindlO. Некоторые изменения, которые были упомянуты в предыдущих изданиях книги, по- прежнему проходят стандартизацию, но еще не приняты. К ним относятся специ^гка- ция DNSSEC-bis (безопаснюсть), система IDN (интернациональные имена домейов) и протокол IPv6. Эти инициативы развиваются, но медленно. Мы включили их в послед- ние строки табл. 17.4. Таблица 17.4. Новые возможности в DNS и BIND Раздел 17.9 5001 NSID, идентификация имен серверов для серверов альтернативной адресации 17.8 5518,5016, 17.8 4871,4686 17.8 4470 17.8 4255 17.8 5198,4952,4690,4290, 4185,3492 14.10 4472,4339,4159,3901 Требования DKIM, подписи, подписи третьих лиц Практика подписания сообщений отправителями ADSP Система идентификации почтовых серверов SPF Слепки открытых ключей SSHFP, SSH Интернациональные доменные имена (в кодировке Punycode, в доме- нах верхнего уровня, в формате обмена) Протокол IPv6, оперативные вопросы, конфигурация узлов, использо- вание доменной зоны ip6.arpa, а не ip6.int для обратного преобразова- ния, текущие наилучшие практики 17.13 5155,5011,4641,4509, 4470,4033-5 Спецификация DNSSEC, аутентификация, записи о делегировании до- мена во время подписи сообщения (DS), практики эксплуатации, “точки доверия” (trust anchors), отказ в существовании (NXDOMAIN) Некоторые из этих предложений представляют собой огромные проекты, стандар- тизацию которых организация IETF еще не закончила. Рабочие группы, которые пишут стандарты, состоят из хороших специалистов, но недостаток “бдительных бойцов” при- водит к тому, что некоторые спецификации трудно или даже невозможно реализовать. Те- кущие выпуски серверов BIND, NSD и Unbound содержат большинство из этих новшеств.
618 Часть II. Работа в сети СЗ Протокол IPv6 более подробно описан в главе 14. Комментариев заслуживают две новые функциональные возможности: поддержка протокола IPv6 и спецификация DNSSEC. Протокол IPv6 увеличивает длину IP-адресов с 32 до 128 бит. Если он когда-нибудь будет полностью реализован, то окажет огромное влияние на Интернет. Серверы BIND, NSD и Unbound частично поддерживают прото- кол IPv6, который уже стандартизован, но вряд ли будет широко развернут в ближайшее время. По этой причине мы лишь кратко описываем протокол IPv6. В этой главе до- статочно дать общее представление об этом протоколе, но этого недостаточно для того, чтобы вы могли перевести ваш сайт на протокол IPv6 и настроить систему DNS на работу с ним. Стандарт DNSSEC добавляет в базу данных DNS и ее серверов данные об аутентифи- кации. Он использует открытый криптографический ключ для верификации источника и целостности данных DNS, а также заставляет систему DNS распространять ключи на- ряду с данными об узле. Организации, желающие развернуть зоны, подписанные в соответствии со специфи- кациями DNSSEC, столкнутся с проблемой самонастройки, пока корневой домен и до- мены верхнего уровня не будут подписаны, потому что модель доверия DNSSEC требу- ет, чтобы подписи образовывали цепочку, начинающуюся в корневом домене. Однако новая временная схема DLV (domain lookaside validation — опережающая проверка до- мена) позволяет находить и соединять друг с другом “островки доверия”, пока корневой домен и домены gTLD не реализуют спецификации DNSSEC полностью. Подробности описаны в разделе 17.13. Описание интернациональных имен доменов, позволяющих использовать неанглий- ские символы, сводится к способу, которым символы кодировки Unicode отображаются в символы кодировки ASCII. Это однозначное отображение, имеющее обратное отобра- жение, выполняет система Punycode, использующая алгоритм Bootstring. Детали описа- ны в документе RFC3492. Интернациональные имена доменов существенно сокращают максимальную длину (как покомпонентную, так и общую) имен DNS. Представление имен в кодировке Pubycode начинается со строки xf—, поэтому если вы увидите стран- ный запрос, начинающийся с этих четырех символов, то будете знать, что они означают. Каждая из этих возможностей (IPv6, DNSSEC и интернационализация) значительно повышает размер записей о данных в системе DNS. В результате система DNS может превысить размеры пакетов UDP и потребовать применения протокола EDNSO (Exten- ded DNS, версия 0), чтобы увеличить размер пакета с 512 байт (по умолчанию) до более крупной величины, например 4096 байт. В 2009 году статистические данные, накоплен- ные на корневом сервере К, свидетельствовали о том, что примерно 35% запросов не использовали протокол EDNS0 и получали усеченные или фрагментированные ответы от сайтов, использовавших более крупные пакеты.9 17.8. База данных DNS Зонные базы данных DNS — это множество текстовых файлов, поддерживаемых си- стемным администратором на главном сервере имен зоны. Эти текстовые файлы часто называются файлами зон. Они содержат записи двух типов: команды синтаксического анализатора (например, $ORIGIN и $TTL) и записи о ресурсах. Базе данных принадлежат 9 Текущие данные можно найти на странице k. root-servers .org/statistics/GLOBAL/ lonthly.
Глава 17. Система доменных имен 619 только записи о ресурсах, а команды синтаксического анализатора предназначены для того, чтобы упростить ввод записей. Ш Команды файла зоны стандартизованы в документах RFC 1035 и 2308. Команды в файлах зон Команды могут быть встроены в файлы зон, чтобы сделать их более читабельными и облегчить их сопровождение. Эти команды либо влияют на способ, с помощью которого синтаксический анализатор интерпретирует последующие записи, либо сами являются сокращением нескольких записей DNS. После того как файл зоны будет прочитан и ин- терпретирован, ни одна из этих команд не становится частью данных о зоне (по крайней мере, в их исходном виде). Три команды являются стандартными в системе DNS, а четвертая, $ GENERATE, от- носится только к серверу BIND. Пример использования команды $GENERATE приведен далее. Стандартные команды выглядят следующим образом. $ORIGIN имя_домена $INCLUDE имя_файла [источник] $TTL стандартное_время_существования Директивы должны начинаться в первой колонке и занимать отдельную строку. Файлы зон читаются и анализируются сверху вниз за один проход. Когда сервер имен читает файл зоны, он добавляет стандартное имя домена (“источник”) к любо- му имени, которое не полностью определено. По умолчанию источником служит до- мен, указанный в файле конфигурации сервера имен. Однако посредством директивы $ORIGIN можно задать или изменить источник в файле зоны. Использование относительных имен вместо полностью определенных позволяет сэ- кономить много времени на вводе данных и делает зонные файлы гораздо более удоб* ными для восприятий. Во многих организациях в зонные файлы включаются директивы $ INCLUDE* позво- ляющие разделять зонные базы данных на логические блоки или хранить ключи шиф- рования в отдельном файле с ограниченными правами доступа. Синтаксис директивы $ INCLUDE таков. $INCLUDE имя_файла [источник] Указанный файл включается в базу данных в том месте, где стоит эта директива. Если имя файла не является полностью определенным, оно интерпретируется относительна каталога, из которого был запущен сервер имен. Если задано значение параметра источник, то синтаксический анализатор действует так, будто чтению файла предшествовала директива $ORIGIN. Обратите внимание на то, что значение источник не возвращается к своему предыдущему значению после выпол- нения директивы $ INCLUDE. Возможно, вы захотите вернуться к предыдущему значению либо в конце включенного файла, либо в строке, следующей за директивой $ INCLUDE. Директива $ttl задает стандартное время существования последующих записей. Она должна стоять в первой строке файла зоны. По умолчанию время жизни измеряется в секундах, но можно задать и другие единицы измерения: часы (h), минуты (ш), дни (d) или недели (w). Например, все перечисленные ниже директивы $TTL 86400 $TTL 24h $TTL Id устанавливают значение $TTL равным одному дню.
620 Часть II. Работа в сети Записи о ресурсах С каждой зоной в иерархии DNS связан набор записей о ресурсах. Базовый формат этой записи имеет следующий вид. [имя] [ttl] [класс] тип данные Поля разделяются знаками табуляции или пробелами и могут содержать специаль- ные символы (табл. 17.5). Таблица 17.5. Специальные символы, используемые в записях о ресурсах _______1— ; Начало комментария 0 Имя текущей зоны () Разбивка данных на несколько строк *Метасимвола (только в поле имя) а Предупреждения, связанные с этим символом, см. ниже. Поле имя идентифицирует объект (обычно узел или домен), к которому относится запись. Если несколько последовательно расположенных записей ссылаются на один и тот же объект, то после первой записи поле имя можно опустить. Поле должно начи- наться в первой колонке, если она присутствует. Имя может быть относительным либо абсолютным. Абсолютные имена заканчива- ются точкой и полностью определены. На внутреннем уровне программное обеспечение работает с полными именами, добавляя имя текущего домена и точку ко всем именам, которые не заканчиваются точкой. Это позволяет укорачивать имена, но часто сопряже- но с ошибками. Например, в домене cs. Colorado. edu имя anchor интерпретируется как “anchor. cs. Colorado. edu. ”. Если же ввести имя anchor. cs. Colorado. edu, то отсутствие точки в конце также будет подразумевать сокращенное имя, к которому следует добавить стандартный домен, что в итоге даст имя “anchor. cs. Colorado. edu. cs. Colorado. edu. ”. Это очень распространенная ошибка. В поле ttl (time-to-live — время существования) задается время (в секундах), в тече- ние которого элемент данных может оставаться в кеше и при этом считаться достовер- ным. Это поле часто опускают, но оно обязательно на корневом сервере в файле под- сказок. Стандартное значение поля задается директивой $TTL, указываемой в первой строке файла зоны. СЗ Более подробная информация о службе NIS приведена в главе 19. Если время существования записей задать равным примерно неделе, то это приведет к значительному снижению сетевого трафика и нагрузки на DNS. Однако следует помнить о том, что после сохранения записи в кеше за пределами локальной сети ее уже нельзя при- нудительно сделать недостоверной. Поэтому, планируя серьезную реструктуризацию сети, сделайте значение $ttl достаточно низким (например, один час), чтобы записи, находя- щиеся во внешних кешах, быстро устарели, а новые параметры в течение часа вступили в действие. После завершения работы восстановите исходное значение этого параметра. Некоторые организации устанавливают небольшое время существования своих за- писей на серверах, имеющих выход в Интернет, для того чтобы в случае возникнове- ния проблем на этих серверах (сбоя сети, отказа аппаратного обеспечения или атаки на
Глава 17. Система доменных имен 621 основе отказа в обслуживании) администраторы могли отреагировать, изменив параме- тры отображения “имя-адрес”. Поскольку исходное время существования записей было незначительным, новые значения будут быстро распространены по сети. Например, имя google. com имеет параметр TTL, равный пяти минутам, а параметр TTL на серверам имен компании Google равен четырем дням (345 600 с). google.com 300 IN А 209.85.171.100 google.com 345600 IN NS nsl.google.com nsl.google.com 345600 IN А 216.239.32.10 Для выяснения этих данных мы использовали команду dig; для простоты вывод был сокращен. В поле класс задается тип сети. Распознаются следующие три значения. • IN — Интернет (по умолчанию). • HS — Hesiod (служба каталогов, локально используемая в некоторых организациях). • CH — ChaosNet (служжба, используемая на некоторых серверах имен для самои- дентификации). По умолчанию задается класс IN. Он часто явно указывается в файлах данных о зо- не, несмотря на то что по умолчанию его можно не задавать. Информационная служба Hesiod, разработанная Массачусетсским технологическим институтом, является над- стройкой пакета BIND. Параметр СН означает ChaosNet — почти исчезнувший сетевой протокол, ранее при- менявшийся на Lisp-машинах компании Symbolics. В настоящее время в пределах клас- са СН скрыто только два информационных элемента: номер версии программного обе- спечения сервера имен и имя узла, на котором запущен этот сервер. Эти данные можно извлечь с помощью команд dig или drill (см. раздел 17.9). Администраторы и хакеры используют номера версий программного обеспечения серверов имен для обновления информации, а администраторы используют имя узла для отладки серверов имен, реплицированных в ходе альтернативной маршрутизации (anycast routing). Раскрытие этой информации посредством класса СН сначала было представлено в пакете BIND, а потом эта возможность была осуществлена во всех реа- лизациях системы DNS. Существуют различные типы DNS-записей, из которых широко используются менее десяти. В стандарте IPv6 было добавлено еще несколько типов. Записи о ресурсах раз- биваются на четыре группы. • Зонные записи определяют домены и их серверы имен. • Базовые записи связывают имена с адресами и обеспечивают маршрутизацию электронной почты.10 • Аутентификационные записи предоставляют информацию, касающуюся аутенти- фикации и сигнатур. • Вспомогательные записи содержат дополнительную информацию о компьютерах и доменах. Содержимое поля данные зависит от типа записи. Запрос DNS о конкретном домене и типе записи получает в ответ все соответствующие ему записи о ресурсах, извлеченные из файла зоны (табл. 17.6). 10 Записи о маршрутизации почты MX относятся как к категории зонных записей, так и к кате- гории базовых записей, поскольку они могут относиться как ко всей зоне, так и к отдельным узлам.
622 Часть II. Работа в сети Таблица 17.6. Записи базы данных DNS Тип Имя ф з SOA Start Of Authority Определение DNS-зоны X X NS Name Server Определение серверов имен зоны, делегирование полномочий поддо- СО менам А IPv4 Address Преобразование имени в адрес IPv4 ф 3 АААА IPv6 Address Преобразование имени в адрес IPv6; ранее считалась устаревшей, но аз О в настоящее время возрождается со L0 PTR Pointer Преобразование адреса в имя мх Mail Exchanger Управляет маршрутизацией почты DS Delegation Signer Хеширует подписанный ключ дочерней зоны О DNSKET Public Key Открытый ключ для имени DNS LU СО СО NSEC Next Secure Используется вместе со спецификацией DNSSEC для генерации отказов Z Q NSEC33 Next Secure v3 Используется вместе со спецификацией DNSSEC для генерации отказов S RRSIG Signature Множество подписанных аутентифицированных записей о ресурсах о о X DLV Lookaside Некорневая точка доверия для спецификации DNSSEC со с: SSHFP SSH Fingerprint SSH-ключ узла, позволяющий верификацию с помощью DNS со ф |П SPF Sender Policy Идентифицирует почтовые серверы, запрещает подделки DKIM Domain Keys Проверяет отправителя сообщения электронной почты и целостность сообщения 6 § CNAME Canonical Name Дополнительные имена (псевдонимы) узла S о с: i SRV Services Местонахождение известных служб в пределах домена о СО « TXT Text Комментарии или нестандартная информация 6 а Оригинальная система NSEC позволяет хакерам использовать команду dig для перебора всех зонных за- писей. В системе NSEC3 этот недостаток устранен за счет усложнения вычислений; в настоящее время используются обе системы. 6 Записи TXT все шире используются для того, чтобы не ожидать одобрения организацией IETF новых типов записей. Например, записи SPF и DKIM были впервые реализованы именно как записи TXT. Есть и другие типы записей, которые либо устарели, либо являются эксперименталь- ными, либо не нашли широкого применения. Полный их список приведен в докумен- тации. Большинство записей поддерживается вручную (путем редактирования тексто- вых файлов), но защищенные записи о ресурсах требуют криптографической обработки и поэтому управляются с помощью программного обеспечения. Эти записи описаны в подразделе, посвященном спецификации DNSSEC, в разделе 17.13. Порядок записей о ресурсах почти произволен, но по традиции запись SOA должна идти первой. Последующие записи Moiyr располагаться в любом порядке, но обычно сразу же после записи SOA следуют записи NS. Записи по каждому узлу, как правило, группиру- ются. Вообще, принято упорядочивать записи по полю имя, хотя некоторые организации упорядочивают их по IP-адресам, чтобы было легче идентифицировать неиспользуемые адреса. Зонные файлы на подчиненных серверах не поддерживаются вручную. Они запи- сываются программным обеспечением сервера имен; порядок записей скрыт. Подробно описывая все типы записей о ресурсах в следующих разделах, мы в ка- честве примера рассмотрим записи из базы данных домена atrust.com.. Поскольку домен по умолчанию — at rust. com., то имя узла bark в действительности означает bark.atrust.com.
Глава 17. Система доменных имен 623 Ш Более подробная информация о документах RFC приведена в разделе 14.1. Формат и интерпретация каждого типа записей о ресурсах описаны организацией IETF в ряде документов RFC. В следующих разделах укажем конкретные документы RFC, относящиеся к каждой записи (вместе с годом их выпуска), в специальных примечаниях. Запись SOA Запись SOA (Start of Authority — начало полномочий) обозначает начало зоны — груп- пы записей о ресурсах, расположенных в одной точке пространства имен DNS. Это® узел дерева DNS называют также точкой передачи полномочий. Как мы увидим ниже, домен DNS обычно охватывает минимум две зоны: для прямого преобразования имен компьютеров в IP-адреса и обратного преобразования. Часть дерева DNS, которая слу- жит целям прямого преобразования, упорядочена по именам, а ветвь обратного преоб- разования — по IP-адресам. CQ Записи SOA определены в документе RFC1035 (1987). Для каждой зоны создается только одна запись SOA. Запись SOA содержит имя зоны, контактный адрес администрации зоны, порядковый номер и различные параметры об- новления данных. Комментарии начинаются с точки с запятой. Рассмотрим следующий пример. ; Начало зоны для домена atrust.com atrust.com IN SOA nsl.atrust.com. hostmaster.atrust.com. ( 2009070200 ; Порядковый номер 10800 ; Refresh (3 часа) 1200 ; Retry (20 минут) 360000 ; Expire (больше 40 дней) 3600) ; Minimum (1 час) Поле имя записи SOA (в нашем примере atrust. com.) часто содержит символ @, обо- значающий сокращенное имя текущей зоны. Текущее имя задается в инструкции zone файла named.conf или в элементе name зонного файла nsd. conf. Оно может быть из- менено в зонном файле посредством директивы синтаксического анализатора $ORIGIN. В показанном фрагменте нет поля ttl. Класс зоцы— IN (Интернет), тип записи — SOA, а остальные элементы образуют поле данное. Числовые параметры в скобках представляют собой продолжительность временных интервалов и часто записываются В одной строке с комментариями. Имя nsl. atrust. com. указывает на главный сервер имен этой зоны.11 Имя hostmaster. cs . Colorado. edu. определяет адрес электронной почты для контактов с администратором домена. Адрес дан в формате “пользователь .узел. ” (а не пользователь&узел). Если необходимо отправить сообщение администратору, просто замените первую точку символом @ и уберите точку, стоящую в конце. Вместо реального регистрационного имени часто используется псевдоним, например admin или hostmaster. Дело в том, что на должность администратора может заступить другой человек. В таком случае проще поменять одну запись в файле aliases (описывается в разделе 20.5), чем выискивать все упоминания старого адреса в зонных файлах. Круглые скобки позволяют разбить запись SOA на несколько строк. 11 На самом деле в записи SOA может быть указан любой сервер имен зоны, если вы не ис- пользуете динамическую систему DNS. В этом случае запись SOA должна содержать имя главного сервера.
624 Часть II. Работа в сети Первый числовой параметр — это порядковый номер конфигурации зоны. С его помощью подчиненные серверы определяют, когда следует загружать новые данные. Порядковым номером может быть любое 32-разрядное целое число, причем оно должно увеличиваться при каждом изменении зонного файла. Во многих организациях в этом номере зашифровывается дата последней модификации файла. Например, значение 2009070200 указывает на первое изменение в зонном файле, сделанное 2 июля 2009 года. Порядковые номера могут не быть последовательными, но должны монотонно воз- растать. Если случайно задать на главном сервере очень большое число и передать его подчиненным серверам, то исправить порядковый номер на главном сервере не удастся. Подчиненные серверы запрашивают новые данные только в том случае, когда порядко- вый номер записи SOA главного сервера больше, чем у них. Существует два способа решения этой проблемы. • Можно воспользоваться особенностями последовательного пространства, из кото- рого выбираются порядковые номера. Суть в том, что к имеющемуся номеру до- бавляется “магическое” число (231), заставляющее подчиненные серверы обновить свои данные, после чего устанавливается требуемый номер. Этот прием описыва- ется в книге Albitz, Paul and Cricket Liu, DNS and BIND и в документе RFC 1982. • Более хитроумный и утомительный способ — изменить порядковый номер на главном сервере, удалить процессы на подчиненных серверах вместе с их резерв- ными базами данных, а затем перезапустить серверы. При отсутствии кеша под- чиненные серверы повторно загрузят базы данных с главного сервера. Этот метод трудно реализовать, если, следуя полезным советам, вы распределили подчинен- ные серверы по географическому признаку, особенно если на этих подчиненных серверах нет системных администраторов. Часто пользователи делают одну и ту же ошибку: меняют файлы данных, забывая при этом исправить порядковый номер. “В наказание” сервер имен откажется распро- странить внесенные изменения на подчиненные серверы. Следующие четыре элемента записи SOA — значения интервалов времени (по умол- чанию в секундах), определяющих, как долго данные могут находиться в кеше в раз- личных точках глобальной базы данных DNS. Можно поменять единицы измерения, воспользовавшись суффиксами m (минуты), h (часы), d (дни) и w (недели). Например, выражение lh30m означает “1 час 30 минут”. Выбор интервала времени требует компро- мисса между эффективностью (использование старого значения дешевле выборки ново- го) и точностью (новые значения более точные). Эти четыре поля называются refresh, update, expire и minimum. Первый элемент задает периодичность обновления данных. Он показывает, как часто подчиненные серверы должны связываться с главным сервером и проверять, не поме- нялся ли порядковый номер конфигурации зоны. Если зонная база данных изменилась (порядковый номер главного сервера стал больше, чем у подчиненного сервера), подчи- ненные серверы должны обновить свои копии базы данных. Общепринятые значения для этого интервала — от одного до шести часов (3600—21600 секунд). Вместо того чтобы пассивно ждать истечения периода обновления, современные серверы BIND (всегда) и NSD (иногда) самостоятельно уведомляют свои подчиненные серверы об изменениях зон. Уведомление об обновлении может быть потеряно из-за пе- регруженности сети, поэтому значение параметра refresh должно быть разумным. Если подчиненный сервер пытается узнать порядковый номер у главного сервера, а тот не отвечает, то через некоторое время будет сделана повторная попытка. Как показывает опыт, нормальное значение для второго элемента — от 20 до 60 минут (1200—3600 секунд).
Глава 17. Система доменных имен 625 Если главный сервер длительное время отключен, то подчиненные серверы будут безуспешно пытаться обновить свои данные. По истечении определенного времени все подчиненные серверы должны “решить”, что главный сервер не включится никогда и его данные наверняка устарели. Параметр expire определяет, как долго подчиненные серверы будут обслуживать домен в отсутствие главного сервера. Система должна со- хранить работоспособность, даже если главный сервер не работает неделю, поэтому третьему элементу следует присваивать большое значение. Мы рекомендуем выбирать интервал от недели до месяца. Четвертый параметр minimum в записи SOA определяет время существования в кеше отрицательных ответов. Время существования положительных ответов (т.е. собственно записей) устанавливается директивой $TTL в начале зонного файла. Как свидетельствует практика, значение $TTL должно быть от нескольких часов до нескольких дней, а мини- мальное время существования отрицательных ответов — один-два часа (но не более трех). Значения параметров $TTL, expire и minimum в конечном итоге вынуждают всех пользователей DNS удалять старые данные. Изначально система доменных имен осно- вывалась на том, что информация об узлах относительно стабильна и меняется нечасто. Однако с появлением протокола DHCP и портативных компьютеров все изменилось. Теперь разработчики серверов имен отчаянно пытаются угнаться за временем, внедряя механизмы инкрементных зонных передач и динамических обновлений, которые будут описаны позднее. Концепция синхронизации была описана в этой главе ранее. Записи NS Записи NS (name server — сервер имен) идентифицируют серверы имен, которые ав- торитетны для зоны (т.е. все главные и подчиненные серверы), а также делегируют пол- номочия по управлению поддоменами другим организациям. Обычно эти записи следу- ют сразу после записи SOA. Ш Записи NS определены в документе RFC1035 (1987). Эти записи имеют следующий формат. зона [ttl] [IN] NS имя_узла Рассмотрим пример. NS nsl.atrust.com. NS ns2.atrust.com. booklab NS ubuntu.booklab.atrust.com. NS nsl.atrust.com. Первые две строки определяют серверы имен для домена atrust. com. Здесь пара- метр пате не указан, потому что он совпадает с полем пате записи SOA, которая пред- шествует этим записям; поэтому поле пате оставлено пустым. Параметр class также не Указан, потому что по умолчанию он равен IN и его не обязательно задавать явно. Третья и четвертая строки делегируют поддомен с именем booklab. atrust. com. серверам имен ubuntu .booklab и nsl. Эти записи на самом деле являются частью под- домена booklab, но они должны также появляться в родительской зоне atrust. com, чтобы делегирование было возможным. Аналогично записи NS для домена atrust. com хранятся в файле зоны . сот, чтобы определить поддомен atrust. com и идентифициро- вать его серверы. Серверы домена . сот отсылают запросы об узлах в домене atrust. com серверам, перечисленным в записях NS для домена atrust. com внутри домена . сот. Ш Подробнее о делегировании рассказывается далее.
626 Часть II. Работа в сети Список серверов имен, расположенных в родительской зоне, должен содержать ак- туальную информацию, если это возможно. Несуществующие серверы, перечисленные в родительской зоне, замедляют работу службы имен, хотя клиенты в конце концов все равно отправляются на один из функционирующих серверов. Если ни один из серверов, перечисленных в родительской зоне, не существует в дочерней зоне, возникает так на- зываемое некорректное делегирование (см. раздел 17.15). Дополнительные серверы в дочерней зоне допускаются, поскольку хотя бы один из дочерних серверов имеет запись NS в родительской зоне. Проверьте делегирование с по- мощью команд dig или drill, чтобы убедиться, что оно определяет корректный набор серверов (см. раздел 17.15). Записи А Записи A (address — адрес) являются основной частью базы данных DNS. Они обе- спечивают перевод имен компьютеров в IP-адреса (ранее эта информация хранилась в файле /etc/hosts). Для каждого из сетевых интерфейсов компьютера должна суще- ствовать одна запись А. Она имеет следующий формат. имя_узла [ttl] [IN] А IP-адрес Рассмотрим пример. nsl IN А 63.173.189.1 В этом примере поле имя_узла не завершается точкой, поэтому сервер имен до- бавляет домен, заданный по умолчанию, и образует полностью определенное имя “nsl. atrust. com. ”. Эта запись связывает данное имя с IP-адресом 63.173.189.1. Записи PTR Записи PTR обеспечивают обратный перевод IP-адресов в доменные имена. Как указывалось ранее, записи обратного отображения существуют в домене in-addr. arpa и именуются байтами IP-адреса, следующими в обратном порядке. Например, зона для подсети 189 в данном примере имеет имя 189.174.63. in-addr. arpa. Общий формат записи PTR таков. адрес [ttl] IN PTR имя_узла Например, запись PTR в зоне 189.173.63.in-addr.arpa, соответствующая приведенной выше записи А для узла nsl, будет иметь следующий вид. 1 IN PTR nsl.atrust.com. Имя 1 не заканчивается точкой и потому является относительным. Вопрос: относи- тельно чего? Не относительно домена atrust. com., потому что, для того чтобы эта за- пись была точной, домен по умолчанию должен называться 189.173.63. in-addr. arpa. Этого можно добиться, поместив записи PTR для каждой подсети в отдельный файл. Домен, связанный по умолчанию с этим файлом, задан в файле конфигурации сервера имен. Другой способ выполнить обратное преобразование — включить в файл зоны за- писи вида 1.189 IN PTR nsl.atrust.com. с доменом по умолчанию 173.63. in-addr. arpa. В некоторых организациях все запи- си обратного преобразования помещаются в один файл, а подсеть задается посредством директивы $ORIGIN. Обратите внимание на то, что имя узла nsl. atrust. com должно заканчиваться точкой, иначе к нему будет добавлена строка 173.63. in-addr. arpa.
глава 17. Система доменных имен 627 Поскольку atrust. com и 189.173.63. in-addr.агра — разные области простран- ства имен DNS, они составляют две отдельные зоны. У каждой зоны должна быть своя запись SOA и свои записи о ресурсах. Помимо определения зоны in-addr. агра, для каждой реальной сети нужно также задать зону, которая охватывала бы интерфейс об- ратной связи (127.0.0.0), по крайней мере при работе с сервером BIND. Пример по- казан в разделе 17.10. Описанные привязки прекрасно работают, когда маски подсетей проходят по границе байтов. Но как выполнять обратные преобразования для подсети вида 63.173.189.0/26, где последний байт может находиться в одной из четырех подсетей: 0-63, 64-127, 128-191 и 192-255? В документе RFC2317 описан остроумный прием, основанный на применении записей CNAME; подробнее об этом речь пойдет ниже. Обратные преобразования, выполняемые записями PTR, используются всеми про- граммами, которые аутентифицируют входящий сетевой трафик. Например, демон sshd может допускать12 удаленную регистрацию без пароля, если исходный узел указан по имени в пользовательском файле **/. shosts. Когда узел-адресат получает запрос на установление соединения, он “знает” узел-отправитель только по IP-адресу. Пользуясь услугами DNS, он преобразует IP-адрес в имя, которое сравнивается с содержимым соответствующего файла. Программы netstat, tcpd, sendmail, sshd, syslogd, X Win- dows и f tpd получают имена компьютеров из IP-адресов с помощью механизма об- ратного преобразования. Важно, чтобы записи А соответствовали записям PTR. Несовпадение и отсутствие последних приводит к ошибкам аутентификации, в результате чего система замедляет работу. Это само по себе неприятно, но еще хуже то, что появляется почва для атак типа на основе отказа от обслуживания, которые направлены на любое приложение, требую- щее соответствия записям А при обратном преобразовании. Записи MX Записи MX (mail exchanger — обмен почтой) используются системой электронной почты для более эффективной маршрутизации почтовых сообщений. Запись MX подме- няет адресата сообщения, в большинстве случаев направляя сообщение концентратору электронной почты на сервере получателя, а не прямо на его рабочую станцию. Ш Записи MX определены в документе RFC1035 (1987). Запись MX имеет следующий формат. ИМЯ [ttl] [IN] MX приоритет узел ... Записи, приведенные ниже, направляют почту, предназначенную для получателя user@server. atrust. com, на машину mail. server. atrust. com, если она включена и доступна. somehost IN MX 10 piper mailserver.atrust.com. IN MX 20 mail-relay3.atrust.com. Сначала опрашиваются узлы с низким приоритетом: наиболее высокий приори- тет — о, наиболее низкий — 65535. (Может показаться, что конфигурация, описанная в примере, не слишком надежна, поскольку оба почтовых сервера расположены в до- мене atrust. com. Однако эти два сервера расположены в разных подсетях и находятся в разных местах.) 12 Но на самом деле, по соображениям безопасности, он этого делать не должен.
628 Часть II. Работа в сети Записи MX полезны во многих ситуациях: • если в системе есть центральный концентратор почты; • если вы хотите фильтровать почту от спама и вирусов перед ее доставкой; • если узел-адресат выключен; • если адресат не подключен к Интернету; • если администратор локальной сети лучше знает, куда следует рассылать сообще- ния (т.е. всегда). Каждый узел, известный во внешнем мире, должен иметь записи MX. Они необхо- димы другим сущностям в системе DNS. Например, узлы, которые никогда не получали или не должны получать электронную почту (скажем, сетевые принтеры), должны иметь записи MX. Сам домен должен иметь запись MX, указывающую на концентратор почты, так чтобы почта, посылаемая на адрес user@domain, приходила туда, куда ее адресовал отправитель. (Однако обратите внимание на то, что в этой конфигурации все машины, существующие в домене, должны иметь уникальные пользовательские имена.) Компьютер, принимающий почту для другого узла, должен настроить свою програм- му пересылки соответствующим образом. Как задать такую конфигурацию для програм- мы sendmail и почтовых серверов Postfix, показано в разделах 20.10 и 20.15 соответ- ственно. В базе данных DNS иногда можно встретить метазаписи MX. * IN MX 10 mailserver.atrust.com. На первый взгляд кажется, что такая запись позволяет избежать многократного ввода данных и является стандартной для всех узлов. Однако метасимвол интерпретируется совсем не так, как можно ожидать. Он соответствует полю имени, которое еще не было указано в явном виде в других записях о ресурсах. Следовательно, нельзя использовать звездочку с целью задания стандартного значе-» ния для всех своих компьютеров. С ее помощью можно задать стандартные имена для “чужих” компьютеров. В результате на концентратор будет поступать масса почтовых сообщений, тут же отвергаемых по той причине, что имя узла, обозначенное звездоч- кой, не принадлежит домену. Поэтому необходимо избегать применения метасимвола в записях MX. Записи CNAME Записи CNAME (canonical паше — каноническое имя) позволяют назначать узлу дополнительные мнемонические имена. Псевдонимы широко применяются для закре- пления за компьютером какой-либо функции либо просто для сокращения его имени. Реальное имя иногда называют каноническим. Приведем несколько примеров. ftp IN CNAME anchor kb IN CNAME kibblesnbits Ш Записи CNAME определены в документе RFC1035 (1987). Запись CNAME имеет следующий формат. псевдоним [ttl] [IN] CNAME имя_узла Обнаружив запись CNAME, программное обеспечение системы DNS перестает по- сылать запросы по мнемоническому имени и переключается на реальное имя. Если у
Глава 17. Система доменных имен 629 компьютера есть запись CNAME, то другие записи для узла (A, MX, NS и др.) должны ссылаться на его реальное, а не мнемоническое имя.13 Длина цепочки записей CNAME не должна составлять больше восьми элементов. Цепочка — это когда одна запись CNAME ссылается на другую, а та — на третью и т.д. Последним, восьмым, элементом должно быть реальное имя узла. При использовании записей CNAME запись PTR должна ссылаться на реальное имя, а не псевдоним. Для того чтобы избежать использования записей CNAME, можно опубликовать за- писи А как для реальных имен, так и для псевдонимов. Эта конфигурация работает немного быстрее, поскольку в ней отсутствует дополнительный уровень косвенной адресации. Специальное применение записей CNAME С помощью записей CNAME можно организовать поддержку зон обратного преоб- разования для сетей, где маски подсетей не проходят по границе байтов. До того как протокол CIDR получил широкое распространение, такая организация подсетей не применялась или по крайней мере “неправильные” подсети существовали в рамках одной организации, поэтому управлять зонами обратного преобразования было неслож- но. Например, если сеть 128.138 класса В разделить на группу подсетей класса С, то каждая подсеть займет строго оговоренное место в домене in-addr. arpa. В частности, зоной обратного преобразования для подсети 243 будет 243.138.128. in-addr. arpa. CQ Протокол CIDR описан в разделе 14.4. Но что произойдет, если подсеть 243 разделить еще, допустим, на четыре подсе^/^26? Если все они находятся в пределах одной организации, то это — не проблема? йни по- прежнему описываются в одном файле, содержащем все их записи PTR. Однако может случиться так, что подсеть 243 принадлежит интернет-провайдеру, который делегирует подсети /26 разным клиентам. В этом случае требуется более сложное решение. Провай- дер должен либо управлять записями зон обратного преобразования на стороне каждого клиента, либо найти способ разделить третий байт IP-адреса (в рассматриваемом приме- ре — 243) на четыре разных элемента, каждый из которых делегируется независимо. Когда административная граница проходит не по границе байтов, приходится быть из- воротливым. Нужно также тесно взаимодействовать с администрацией домена, находяще- гося выше или ниже в иерархии. Трюк заключается в следующем: для каждого возможно- го адреса узла в зоне in-addr. arpa следует добавить запись CNAME, которая переводит операцию поиска в зону, управляемую владельцем соответствующей подсети. Подобная схема приводит к образованию громоздких зонных файлов в родительском домене, но она же позволяет передавать полномочия реальным пользователям каждой подсети. Рассмотрим описываемый процесс подробнее. Родительская организация (в нашем случае — провайдер) создает для каждого возможного IP-адреса записи CNAME со спе- циальным искусственным компонентом (отделяется точкой), представляющим подсеть. Например, для первого из четырех блоков адресов подсети /26 дополнительный компо- нент будет называться “0-63”, для второго — “64-127” и т.д. Вот как это выглядит. $ORIGIN 243.138.128.in-addr.arpa. 1 IN CNAME 1.0-63 2 IN CNAME 2.0-63 13 Это правило, касающееся записей CNAME, явным образом ослаблено в спецификациях DNSSEC, которые добавили цифровые подписи к каждому набору записей о ресурсах DNS.
630 Часть II. Работа в сети 63 64 65 IN IN IN CNAME CNAME CNAME 63.0-63 64.64-127 65.65-127 Для того чтобы передать управление адресами 0-63 зоны обратного преобразования клиенту, за которым закреплена эта подсеть, нужно добавить следующие записи NS. 0-63 IN NS nsl.customerl.com. 0-63 IN NS ns2.customerl.com. На узле customerl. com будет находиться зонный файл, содержащий привязки для зоны обратного преобразования 0-63.243.138.128. in-addr. агра. 1 IN PTR hostl.customerl.com. 2 IN PTR host2.customerl.com. Добавив дополнительный компонент, мы создали новую точку передачи полномочий. Когда, например, кто-то ищет доменное имя, соответствующее адресу 128.138.243.1, запись CNAME в точке 1.243.138.128. in-addr.агра перенаправит поиск в точку 1.0-63.243.138.128. in-addr. агра, а этим именем уже управляет реальный клиент. Клиентские зонные файлы не содержат ничего лишнего: со всеми конфигурацион- ными записями приходится иметь дело провайдеру. Ситуация усложняется, если клиент сам является провайдером и дальше делит свое адресное пространство. Клиент 1 может , сам быть интернет-провайдером, желающим разделить свои адреса. Однако непреодо- лимых препятствий не существует: в BIND поддерживаются цепочки записей CNAME длиной до восьми элементов, а поскольку в байте, как известно, восемь битов, превы- шения допустимого предела не произойдет. Различные документы RFC не одобряют, но и не запрещают применять такие цепочки. К негативным последствиям можно отнести то, что скорость распознавания имен замедляется, так как распознаватель должен прой- ти по каждому звену цепочки, послав соответствующее число запросов серверу. Когда схема стала получать распространение, набор команд сервера BIND попол- нился директивой $ GENERATE, которая упрощает создание записей о ресурсах в роди- тельской зоне. Например, чтобы сгенерировать все необходимые записи для первой подсети, доста- точно следующих строк. $ORIGIN 243.138.128.in-addr.агра. $GENERATE 0-63 $ CNAME $.0-63 0-63 in NS nsl.customerl.com. 0-63 in NS ns2.customerl.com. Метасимвол $ в директиве $ GENERATE является счетчиком цикла и приводит к соз- данию 64 различных записей CNAME. Остальные три подсети /26 обрабатываются ана- логично. Записи SRV Эти записи определяют местонахождение служб в пределах домена. Например, бла- годаря записи SRV можно запросить удаленный домен и узнать имя его FTP-сервера. Раньше в подобной ситуации приходилось действовать наугад в надежде на то, что адми- нистратор удаленного домена, следуя традиционной практике, добавил запись CNAME для имени “ftp” в базу данных DNS. Ш Записи SRV определены в документе RFC2782 (2000).
Глава 17. Система доменных имен 631 Гораздо разумнее применять для этих целей записи SRV. С их помощью администра- торам намного удобнее менять адреса служб и контролировать их использование. Од- нако требуется, чтобы сами клиенты знали, как найти и проанализировать записи SRV, поэтому эффект от их применения пока не столь ощутим. Записи SRV напоминают обобщенные записи MX с дополнительными полями, ко- торые позволяют администратору DNS управлять внешними соединениями и распреде- лять нагрузку на сервер. Формат записей выглядит следующим образом. служба. протокол. имя [ttl] [IN] SRV приоритет вес порт сервер Аргумент служба представляет собой имя службы, определенное в базе данных IANA (Internet Assigned Numbers Authority — Агентство по выделению имен и уникальных па- раметров протоколов Интернета). Получить доступ к этой базе данных можно по адресу iana. org/numbers. htm. Аргумент протокол должен быть равен tcp либо udp. Аргумент имя — это домен, на который ссылается запись SRV. Аргумент приоритет имеет тот же смысл, что и в записи MX. Аргумент вес используется для распределения нагрузки меж- ду несколькими серверами, порт — это номер порта, на котором выполняется служба, а сервер — имя сервера, предоставляющего данную услугу. Для того чтобы избежать повтор- ного обращения, в ответ на запрос к записи SRV обычно возвращается запись А сервера. Если вес равен 0, то специального распределения нагрузки не требуется. Имя серве- ра, равное ‘означает, что служба на данном узле недоступна. Ниже показан пример из документа RFC2052, адаптированный для домена atrust. com. -ftp.tcp SRV 0 0 21 ftp-server.atrust.com. ; одна четверть соединений обслуживается старым компьютером, ; а три четверти - новым _ssh.tcp SRV О 1 22 old-slow-box.atrust.com. SRV О 3 22 new-fast-box.atrust.com. ; основной сервер доступен через порт 80, ; а резервный — через порт 8000 на новом компьютере _http.tcp SRV 0 0 80 www-server.atrust.com. SRV 10 0 8000 new-fast-box.atrust.com. ; в адресной строке можно указывать как http://www.atrust.com, ; так и http://atrust.com _http.tcp.www SRV 0 0 80 www-server.atrust.com. SRV 10 0 8000 new-fast-box.atrust.com. ; все остальные службы блокированы *•_tcp SRV ООО udp SRV ООО В этом примере демонстрируется использование аргументов вес (служба SSH) и приоритет (служба HTTP). Задействованы оба сервера SSH, причем нагрузка между ними распределяется в соответствии с производительностью серверов. Все остальные службы заблокированы, включая службы для протоколов TCP и UDP. Однако тот факт, что эти службы не доступны в системе DNS, не означает, что они на самом деле не вы- полняются, просто вы не можете найти их с помощью системы DNS. Серверы MS Exchanges используют записи SRV для того, чтобы помочь клиентам приложения Outlook найти их и автоматически задать конфигурацию функции Outlook Anywhere.
632 Часть II. Работа в сети Записи TXT Эти записи добавляют в базу данных DNS произвольный текст. Например, в нашей базе данных имеется следующая запись, идентифицирующая организацию. IN TXT "Applied Trust Engineering, Boulder, CO, USA" Эта запись стоит непосредственно после записей SOA и NS зоны atrust. com, на- следуя от них поле имя, Ш Записи TXT определены в документе RFC1035 (1987). Запись TXT имеет такой формат. имя [ttl] [IN] TXT информация ... Все информационные элементы должны быть заключены в кавычки. Это может быть как одна, так и несколько строк, каждая из которых взята в кавычки. Будьте вниматель- ны: одна пропущенная закрывающая кавычка может привести к разрушению базы дан- ных DNS, поскольку все последующие записи, вплоть до очередной кавычки, загадоч- ным образом исчезнут. Как и у других записей о ресурсах, у записей TXT нет внутреннего порядка, поэтому серверы возвращают их в произвольном порядке. Для того чтобы закодировать длинные элементы, такие как адреса, следует использовать длинные строки, а не набор несколь- ких записей ТХТ. Поскольку записи ТХТ не имеют конкретного формата, их иногда используют для те- стирования новых типов записей в системе DNS без изменения самой системы DNS. На- пример, записи SPF (см. далее) сначала были реализованы как записи ТХТ. В настоящее время уже созданы специальные типы записей, поэтому использование их вариантов в виде записей ТХТ не рекомендуется, но многие организации по-прежнему делают это. Записи ресурсов IPv6 IPv6 — новая версия протокола IP. Процесс принятия спецификации длится уже бо- лее 15 лет, он описан в более чем 250 документах RFC, но до сих пор не завершен.14 Сво- им появлением протокол IPv6 обязан острой потребности в дополнительных IP-адресах. Ш Записи IPv6 описаны в документе RFC1886 (1995). Однако решения этой проблемы, считавшиеся временными (протокол CIDR, си- стема NAT и строгий административный контроль над адресным пространством), ока- зались столь успешными, что массовый переход к стандарту IPv6 вряд ли произойдет в скором будущем. Принятие протокола IPv6 в настоящее время стимулируется Азией, где адреса протокола IPv4 распределены более экономно. Ш Стандарт IPv6 подробно описан в главе 14. Записи IPv6 в системе DNS полностью отделены от протокола транспорта, исполь- зуемого для их доставки. Публикация записей IPv6 в ваших зонах DNS не означает, что вы должны отвечать на запросы к ним по протоколу IPv6. Около половины запросов к корневому серверу имен К (k. root-servers .net) — запросы к записям А протокола IPv4, а одна четверть — это запросы к записям АААА по протоколу IPv6. Однако 99% всех фактических запросов используют транспорт по протоколу IPv4. 14 Тони Ли (Toni Li), активный член сообщества IETF, описал протокол IPv6 так: “слишком мало, слишком рано”.
Глава 17. Система доменных имен 633 Прямые записи IPv6 — АААА Формат записи АААА имеет следующий вид. имя_узла [ttl] [IN] АААА IP-адрес Рассмотрим пример. f.roo-servers.net. IN АААА 2001:500:2f::f Каждый фрагмент адреса, отделенный двоеточием, состоит из четырех шестнадцате- ричных цифр (ведущие нули обычно опускают). Если несколько фрагментов включают в себя одни нули, они заменяются двумя двоеточиями. В адресе может быть не более одного такого сокращения. Обратные записи IPv6 — PTR В протоколе IPv6 информация обратного преобразования, соответствующая адресу АААА, представляет собой запись PTR в домене верхнего уровня in-addr. агра, а зоны прямого преобразования — в других ветвях дерева доменов (например, в доменах “сот” или “edu”). В “полубайтовом” формате адрес, указанный в записи АААА, инвертируется путем разложения каждого адресного фрагмента на четыре шестнадцатеричные цифры и за- писи их в обратном порядке с добавлением суффикса ip6. агра. Например, следующая запись PTR соответствует показанной выше записи АААА для узла anchor. f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.2.0.0.0.0.5.0.1.0.0.2.ip6.агра PTR f.roo-servers.net (Для того чтобы эта строка поместилась на странице, она была сокращена.) К сожй.* лению, они не очень удобны для работы системных администраторов, которые долж^ их писать и читать. Разумеется, в ваших реальных зонных файлах DNS задачу можЙЬ существенно упростить, воспользовавшись директивой $ORIGIN. Записи SPF Записи SPF предназначены для идентификации сообщений электронной почты с под- деланными заголовками From, которые часто используются для рассылки спама или фи- шинга. Если сайт, получивший сообщение, определяет, что его заголовки подделаны, он может удалить его, профильтровать или пометить, перед тем как передать получателю. Эта функциональная возможность впервые была реализована с помощью записей TXT, но в настоящее время уже существует специальный тип записей SPF, использующий тот же самый синтаксис, что и записи ТХТ. Сайты могут использовать записи SPF, TXT, обе версии или ни одну из них. Ш Записи SPF определены в документах RFC4406 и RFC4408 (2006). К сожалению, существует два конкурирующих способа использования записей SPF: система Sender ID компании Microsoft и альтернативная. Рабочая группа консорциума IETF не достигла консенсуса относительно наилучшего использования записей SPF, поэтому оба подхода были опубликованы в документах RFC в качестве эксперимен- тальных. Основное различие между ними заключается в том, где выполняются проверки адреса отправителя: на конверте или в заголовке. Обе спецификации записей SPF имеют существенный недостаток: пересылаемые со- общения электронной почты не проходят проверку, потому что получатель сравнивает за-
634 Часть II. Работа в сети пись SPF отправителя с IP-адресом пользователя, осуществляющего пересылку. По этой причине следует быть осторожным при удалении сообщений, не прошедших проверку. Здесь мы описываем часть синтаксиса и семантики записей SPF в соответствии в до- кументом RFC4408. Полная спецификация является чрезмерно гибкой и содержит ма- кросы, а также директивы переадресации и включения, предоставляя пользователям десятки возможностей для формирования собственных правил. Мы сосредоточим вни- мание на простом и эффективном подмножестве этих возможностей.' Запись SPF содержит IP-адреса серверов, создавших легитимное в пределах зоны со- общение электронной почты. Например, команда dig gmail. com spf15 возвращает следующую запись. gmail.com 300 IN SPF "v=spfl redirect=_spf.google.com” Эта запись SPF перенаправляет клиентов на поддомен spf домена google. com. Запрос dig_spf. google. com spf возвращает следующий ответ. _spf.google.com 300 IN SPF "v=spfl ip4:216.239.32.0/19 ip4:64.233.260.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all" Вместо перечисления конкретных узлов, эта запись SPF содержит IP-номера сетей почтовых серверов компании Google. Эти строки представляют собой одну длинную за- пись SPF, которая разделена на строки для того, чтобы она поместилась на странице. Длина строки записи SPF не должна превышать 255 байт, поэтому если в нее не- обходимо ввести больше 255 символов, то следует использовать несколько пар кавычек. Такие строки конкатенируются без дополнительных пробелов. Желательно, чтобы об- щая длина строки не превышала 450 байт, чтобы ответы на запросы могли поместиться в отдельном UDP-пакете, размер которого составляет 512 байт. Рассмотрим нашу запись SPF более подробно. • Выражение v=spf 1 означает, что запись соответствует версии 1 протокола SPF, опи- санной в документе RFC4408. Выражение v=spf 2.0 означало бы, что запись соот- ветствует системе Sender ID компании Microsoft, описанной в документе RFC4406. • Дескрипторы ip 4 означают, что за ним следует обычный IP-номер сети или адрес узла. Запись может содержать несколько фраз с дескрипторами ip 4, как в данной примере. • Выражение ?а11 означает “сделано” по отношению к функции проверки, интер- претирующей запись. Сложность языка SPF обескураживает. Остальные дескрипторы позволяют перечне^ лять имена узлов, записи MX, записи PTR, адреса IPv6 и многое другое. Некоторые из них требуют, чтобы сервер DNS выполнил повторный просмотр, поэтому, несмотря на дополнительное удобство и гибкость, они менее эффективны, чем дескриптор ip4. Если вы хотите пофантазировать о своих записях SPF, посмотрите на примеры, приведенные в конце документа RFC4408. Рассмотрим еще один пример записи SPF, полученной при выполнении команды dig sendmail.com txt. 15 Компания Google и другие организации реализуют свои собственные записи SPF на основе записей ТХТ, потому что тип записей SF является новым и лишь недавно стал поддерживаться программным обеспечением популярных серверов имен. Однако заглядывая в будущее, мы полу- чили образовательную лицензию на программное обеспечение и демонстрируем записи SPF, а не ТХТ. На самом деле команда dig работает с записями ТХТ, а не SPF.
Глава 17. Система доменных имен 635 sendmail.com IN TXT "v=spfl ip4:209.246.26.40 ip4:209.246.26.41 ip4:63.211.143.38 ip4:209.246.26.36 ip4:209.246.26.39 ip4:209.246.26.24 ip4:209.246.26.25 ip4:209.246.26.10 ip4:209.246.26.53 ip4:72.32.154.224/27 ptr:constantcontact.com ~all" Эта запись содержит полные IP-адреса серверов, а не сетей. В конце списка 1Р-ад- ресов приведена фраза ptr:, позволяющая серверу constantcontact. com послать по- чтовое сообщение, отправителем которого подразумевался сервер sendmail. com. Эта фраза может вступить в силу, только если сервер const ant contact. com имеет соответ- ствующую запись PTR. В настоящее время это условие не выполняется. Во время на- писания книги запись PTR отправляла нас обратно на сервер www. constantcontact. com, а не на сервер constantcontact. com. Следовательно, либо получатель сообщений электронной почты не проверял запись PTR достаточно строго, либо запись SPF имеет небольшую ошибку. Согласно результатам обзорного исследования (sendmail.org/dkim/survey), око- ло тысячи банков США и тысяча компаний, входящих в список журнала Fortune, со- общили, что записи SPF поддерживались более чем 90% сайтов, а формат Sender ID — 1-2%. Некоторые почтовые серверы (например, Gmail) выводят на экран ярко-красную полосу поперек сообщения, которое не прошло проверку SPF и может быть элементом фишинга. Почтовые агенты sendmail, Postfix и exim поддерживают обработку записей SPF, а программа Microsoft Exchange поддерживает систему Sender ID. Более подробная ин- формация о записях SPF приведена в разделе 20.5. Записи DKIM и ADSP Аббревиатура DKIM (DomainKeys Identified Mail) представляет собой систему, ре- зультатом которой является слияние двух систем: DomainKeys от компании Yahoo! и Identified Internet Mail от компании Cisco, обеспечивающих подпись сообщений элек- тронной почты. Получатель сообщения может аутентифицировать его отправителя (под- линность) и гарантировать его целостность (отсутствие постороннего вмешательства). Ш Записи DKIM определены в документах RFC487 (2007) и RFC5617 (2009). Спецификации DKIM являются результатом большой работы, поэтому, например, списки рассылки и внешние сообщения электронной почты реализуются правильно. Еще одной целью проекта была легкость реализации этой спецификации. Она не требует ни- каких изменений со стороны пользователей или узлов. Здесь мы рассмотрим лишь те аспекты спецификации DKIM, которые связаны с системой DNS. Особенности специ- фикации DKIM, связанные с электронной почтой, будут рассмотрены в разделе 20.15. Записи о ресурсах DKIM пока не стандартизованы так, как это сделано для записей типа DNS. Вместо этого используется особый формат записей TXT. Этот формат состоит из имени записи DNS, сформированной путем конкатенирования “селектора” и строки „domainkey. В записи хранится открытый ключ DKIM для организации. Может суще- ствовать несколько селекторов, поэтому эти ключи легко продлить и отменить. Сайт, использующий подписи DKIM, вычисляет их с помощью специальных полей заголовка и тела сообщения, содержащего закрытый ключ DKIM. Он помещает подпись в отправляемое сообщение в виде поля заголовка, называемого DKIM-Signature. Соответствующий открытый ключ доступен в зоне DNS сайта-отправителя в виде записи TXT, связанной с именем селектор._domainkey.домен. Сайт-получатель по- ручает системе DNS найти ключ и использует его для проверки корректности подписи
636 Часть II. Работа в сети в сообщении. Успешная верификация подписи удостоверяет подлинность сообщения и гарантирует, что оно поступило из предусмотренного домена отправления и по пути не было изменено. Рассмотрим пример строки заголовка подписи DKIM-Signature из подписанного со- общения. DKIM-Signature: v=l; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-s ignature:mime-version;received:reply-to:date:message-id: subject:from:to:content-type; bh=2 4HfUvt1A04 JxRNBmg94pN6ZJUPdqSbkOdZppou4 sl=; b=UtYWupx/Udqi7Sdln0h5zIDKq7R/Gg+HwYBxM0LcshlwhqrHhyHylea3So8 EnMXJEYI3jyzj3VNGGemOAOSUqHlMmdlSLdp7AvxptYOVfLgYGM9ID4uw B014a7ZJuoiVHJmsEA/ExK48rvql0ZJY+AgRdDpbx6/56phSfVJt+a+A= Разные дескрипторы, используемые в этой подписи, обясняются в табл. 17.7 Таблица 17.7. Дескрипторы в заголовке подписи сообщений электронной почты DKIM-Signature Раздел RFC '- ’ V 1 Номер версии; должен быть равным 1 а rsa-sha256 Алгоритм шифрования: rsa-shal или rsa-sha256 с relaxed/relaxed Алгоритм каноникализации:а simple или relaxed d gmail.com Домен отправителя S gamma Селектор или имя ключа h domain Поля заголовка для включения в подпись заголовка bh 24HfUvtl... Криптографический хеш тела сообщения b UtYWupx... Криптографическая подпись всего сообщения а Этот алгоритм определяет, как изменяются заголовок и тело перед шифрованием. Дескриптор селектора s=gamma сообщает имя открытого ключа, а дескриптор d= за- дает родительский домен. Для того чтобы получить открытый ключ, следует применить команду dig к записи TXT для псевдо-узла gamma ._domainkey. gmail. com. gamma._domainkey.gmail.com. 300 IN TXT "k=rsa; t=y; p=MIGfMAOGCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIhyR3oItOy22ZOaBrI Ve9m/iME3RqOJeasANSpg2YTHTYV+Xtp4xwf5gTjCmHQEMOsOqYuOFYiNQP QogJ2t0Mfx9zNu06rfRBDjiIU9tpx2T+NGlWZ8qhbiLo5By8apJavLyqTLavyPSrv sxOB3YzC63T4Age2CDqZYA+OwSMWQIDAQAB" Это слишком запутанная запись, чтобы самостоятельно записывать ее в свои зонные файлы. К счастью, в нашем распоряжении есть возможность копирования и вставки. Дескриптор к= идентифицирует тип ключа; единственное значение этого дескриптора равно rsa. Флаг t=y означает, что вы уже выполнили проверку по спецификации DKIM и сайты-получатели должны быть снисходительны, если ваша подпись не будет верифи- цирована. Дескриптор р= представляет собой сам открытый ключ. Перед точкой с за- пятой должна стоять обратная косая черта, поскольку в файлах данных DNA с точки с запятой начинаются комментарии. Запись ТХТ в системе DKIM часто содержит дескриптор версии v=DKlMl. Как и все записи ТХТ, она должна быть заключена в двойные кавычки.
Глава 17. Система доменных имен 637 Для того чтобы сгенерировать пару ключей RSA в соответствующем формате для ва- ших зонных файлов, следует использовать следующие команды openssl, генерирующие закрытый ключ и извлекающие из него соответствующий открытый ключ. $ openssl genrsa -out rsa.private 1024 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM Затем необходимо вырезать открытый ключ из файла rsa.public и вставить его в дескриптор р= вашей текстовой записи. Он не должен содержать ни пробелов, ни сим- волов перехода на новую строку, поэтому при копировании и вставке следует быть осто- рожным и не добавлять дополнительных символов. В качестве селектора можно выбрать любое имя. В приведенном выше примере сегмент _domainkey.gmail.com имени gamma_ domainkey. gmail. com на самом деле не является именем подзоны домена gmail. com с точки зрения системы DNS. Это можно подтвердить путем поиска зонных серверов имен (dig_domainkey.gmail.com ns), которые должны существовать, если имеется собственная делегированная подзона. Приведенный ниже пример, касающийся сайта yahoo. com, реализует _domainkey как собственный поддомен. Документ RFC5617 определяет запись ТХТ, которую можно спрятать в специаль- ном поддомене, чтобы задать свои собственные правила, касающиеся подписания со- общений. Эта запись недавно была стандартизована (2009) и называется ADSP (Author Domain Signing Policy). Специальным поддоменом является домен adsp . domainkey. домен. Внутри записи ТХТ содержится выражение dkim=, которое объявляет правила под- писания сообщений на сайте. Оно может принимать следующие возможные значения. • all — для доменов, подписывающих все исходящие сообщения электронной почты; • unknown — для доменов, которые могут подписывать некоторые сообщения элек- тронной почты; • discardable — для доменов, подписывающих все сообщения электронной по- чты и рекомендующих получателям игнорировать сообщения, подписи которых не прошли верификацию. Например, дескриптор discardable может использоваться банком, который посы- лает клиенту конфиденциальную информацию о его счете из поддомена, созданного для этой цели. Если бы пользователь выполнил инструкции, содержащиеся в сообщении с поддельной подписью, это имело бы катастрофические последствия, поэтому лучше всего не принимать такие сообщения и не доставлять их адресату. Текстовая запись ADSP также может содержать выражение t=y, если вы желаете про- сто протестировать спецификацию DKIM и на самом деле не хотите, чтобы получатели слишком серьезно относились к вашей подписи. В ходе разработки системы ADSP, до появления документа RFC5617, доменная тек- стовая запись ADSP хранилась в другом поддомене (_domainkey. domain^ без префикса _adsp) и имела немного другой синтаксис. Выражение о=~ означает, что домен под- писывает некоторые сообщения электронной почты, а о=--что он подписывает все сообщения. Поскольку в этих двух соглашениях используются разные поддомены, они могут со- существовать. На момент написания книги доминировала исходная форма. Если вы серьезно относитесь к тому, чтобы получатели тщательно рассматривали вашу подпись, то, вероятно, лучше всего использовать оба соглашения на протяжении следующих не- скольких лет, пока один из них не будет приведен в соответствие документу RFC5617.
638 Часть II. Работа в сети Рассмотрим еще один пример. Сайт Gmail не имеет записи ADSP, а сайт Yahoo! имеет. domainkey.yahoo.com. 7200 IN TXT "t=y; о=~; n=http://antispam.yahoo.com/domainkeys Выражение n= представляет собой комментарий, который предоставляет пользова- телю дополнительную информацию о том, как сайт Yahoo! использует записи DKIM.16 Некоторые сайты вместо этого включают адрес сообщения электронной почты (без сим- вола @). Рассмотрим текстовую запись DKIM для ключа (селектора) S1024. sl024._domainkey.yahoo.com. 86400 IN TXT "k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui /E9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm” ”JiDJOKU3Ns5L4KJAUUHjFwDebtONP+sBKOVKeTATL2Yr/S3bT/xhy+lxtj4Rkd V7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB; n=A 1024 bit key;" Здесь, как и раньше, выражение п= является комментарием, но на этот раз о самом ключе. Все записи DKIM, представленные в этом разделе, были записями TXT, но в конце концов они обязательно превратятся в записи специального типа DKIM, хотя и будут иметь тот же самый формат. Тем временем сайты могут использовать оба типа записей, чтобы решить проблемы перехода. Реализация спецификации DKIM в вашей почтовой системе рассматривается в гла- ве 20. Записи о ресурсах SSHFP Оболочка безопасности SSH позволяет обеспечить безопасность дистанционного входа в систему в незащищенной сети. Эта программа использует две схемы аутенти- фикации: для самого узла и для пользователя, осуществляющего дистанционный вход. К сожалению, пользователи обычно слепо доверяют ключам узла, полученным от про- граммы ssh. Запись DNS типа SSHFP позволяет программе ssh автоматически прове- рить ключ узла, гарантируя, что пользователь будет соединен с требуемой машиной, а не с посторонним компьютером. СЗ Записи SSHFP определены в документе RFC4255 (2006). Для того чтобы уменьшить размер пакета, записи SSHFP не хранят полные копии от- крытых ключей узла. Вместо этого они содержат дайджест (т.е. криптографический хеш) этих ключей. Их синтаксис выглядит следующим образом. пате [ttl][IN] SSHFP algorithm# fingerprint_algorithm# fingerprint Параметр algorithm# идентифицирует криптосистему открытого ключа, используе- мую для генерирования ключа данного узла. На самом деле этот алгоритм не принимает участия в процессе верификации; он просто сравнивается с ключом, предоставленным удаленным узлом, чтобы убедиться в том, что обе стороны имеют в виду один и тот же вид ключа. Система RSA — это алгоритм 1, a DSA — алгоритм 2. Параметр fingerprint — это хеш, подлежащий сравнению, а параметр fingerprint_algorithm# задает способ, которым обрабатывается ключ, предостав- ленный удаленным узлом для создания хеша, подлежащего сравнению. В настоящее 16 Правда, данный URL в настоящее время переадресовывает пользователей на страницу sourceforge.net, посвященную системе DomainKeys, которая представляет собой практически устаревший стандарт.
Глава 17. Система доменных имен 639 время определен только один алгоритм (SHA-1), поэтому содержание этого поля всегда равно 1. Рассмотрим пример, приведенный в документе RFC4255. host.example SSHFP 2 1 1235456789abcdef67890123456789abcdef67890 Программа SSH обычно создает пары ключей узла RSA и DSS; как правило, они хра- нятся в каталоге /etc/ssh с именами вроде ssh_host_rsa_key .pub и ssh_hostjdsfc key .pub. На стороне пользователя программа SSH хранит принятые открытые ключи узла в файле . ssh/known_hosts в домашнем каталоге пользователя. Вы можете извлечь ключи узла из этого каталога, чтобы создать свои собственные записи о ресурсах типа SSHFP. Последние версии программы ssh-keygen могут гене- рировать записи DNS SSHFP с флагами -г и -д. Кроме того, в системах Linux и UNIX (freshports. org/dns/sshfp) существует команда sshfp, которая конвертирует ключи в отпечатки и создает необходимые записи DNS. Ш Более подробная информация о записях SSHFP приведена в разделе 22.10. Вы можете попросить программу OpenSSH использовать записи SSHFP для установ- ки опции VerifyHostKeyDNA, равной “yes”. Программа SSH поддерживает несколько методов аутентификации и верификации. Поскольку записи SSHFP пока используются не очень широко, их не стоит делать единственно возможным вариантом. Сначала по- пробуйте использовать запись SSHFP, и если это не получится, позвольте пользователю подтвердить ключ узла вручную, как это делалось до появления записей SSHFP. Более подробно конфигурация программы SSH описывается в разделе 22.10. Подобно записям SPF и DKIM, система SSHFP в той или иной степени подразуме- вает, что вы используете спецификации DNSSEC и поэтому записи DNS заслуживают доверия. Возможно, в данный момент это и не соответствует действительности, но спец- ификации DNSSEC постепенно получают признание и в конце концов будут реализова- ны. Их описание можно найти в разделе 17.13. Записи о ресурсах DNSSEC В настоящее время со спецификациями DNSSEC ассоциируются шесть типов запи- сей. Записи типов DS, DVL и DNSKEY предназначены для хранения разнообразных ключей и их отпечатков. Записи RRSIG содержат подписи других записей в зоне (по су- ществу, наборов записей). И наконец, записи типов NSEC и NSEC3 позволяют серверам DNS подписывать несуществующие записи, обеспечивая криптографическую безопас- ность при отрицательных ответах на запросы. Эти шесть записей отличаются от большин- ства других записей тем, что они генерируются программами, а не набираются вручную. Спецификации DNSSEC представляют собой большую тему, заслуживающую отдель- ного изучения, поэтому мы обсудим записи DNSSEC и их использование в разделе 17.13. Связующие записи: связи между зонами Каждая зона имеет свой набор файлов, серверов имен и клиентов. Но зоны должны быть связаны друг с другом, чтобы образовывать иерархии: зона booklab. atrust. com — это часть зоны atrust. com, и мы должны иметь определенную связь между ними, обе- спечиваемую средствами системы DNS. Поскольку ссылки DNS направлены только от родительских доменов к дочерним, серверу имен не обязательно знать все о доменах (точнее, о зонах), расположенных выше в иерархии. Однако серверы дочернего домена должны знать IP-адреса серверов
640 Часть II. Работа в сети имен для всех своих поддоменов. Фактически родительской зоне известны только сер- веры имен, на которые можно сослаться в ответ на внешние запросы. В терминах системы DNS это значит, что родительская зона должна содержать запи- си NS для каждой делегированной зоны. Поскольку записи NS содержат имена узлов, а не их IP-адреса, родительский сервер также должен иметь способ преобразования имен узлов либо с помощью обычных запросов DNS (если при этом не возникает замкнутый круг), либо сохраняя копии соответствующих записей А. Существует два способа, с помощью которых можно удовлетворить эти требования: непосредственно включить нужные записи или использовать зоны-заглушки. В первом методе вы просто включаете требуемые записи NS и А в родительскую зону. Например, файл зоны atrust. com может содержать следующие записи. ; информация о поддомене booklab IN NS nsl.atrust.com. IN NS ubuntu.booklab.atrust.com. IN NS ns.cs.Colorado.edu. testlab IN NS nsl.atrust.com. IN NS ns.testlab.atrust.com. ; связующие записи ubuntu.booklab IN А 63.173.189.194 ns.testlab IN A 63.173.189.17 “Внешние” записи А называются связующими (glue records), поскольку на самом де- ле они не принадлежат этой зоне. Они только воспроизводятся здесь, чтобы обеспечить связь с новым доменом в дереве имен. Пропуск или неправильное воспроизведение свя- зующей записи делает ваше пространство имен недоступным, и пользователи, пытаю- щиеся обратиться к ней, получат сообщение об ошибке “host unknown”. Довольно часто пользователи ошибочно включают связующие записи для имен уз- лов, которые этого не требуют. В приведенном выше примере зона nsl. atrust. com яв- ляется частью зоны atrust. com, и ее записи А хранятся где-то в файле. Адрес ns. cs. Colorado. edu в этом связующем разделе не требуется, поскольку его можно определить с помощью обычного запроса DNS. Запись А в этой зоне, на первый взгляд, не нужна, но позднее она может устареть и стать неправильной, если адрес ns. cs. Colorado. edu изменится. Рекомендуется включать записи А только для узлов, которые находятся в те* кущем домене или в любом из его поддоменов. Серверы BIND и NSD игнорируют не* нужные связующие записи, причем сервер BIND распознает их наличие как ошибку. Описанная выше схема представляет собой стандартный способ связывания зон, но он требует, чтобы дочерняя зона поддерживала контакт с родительской и сообщала ей о любых изменениях иди дополнениях, касающихся своих серверов имен. Поскольку родительские и дочерние зоны часто функционируют на разных сайтах, обновление ин- формации может превратиться в утомительное занятие, требующее координации между организациями, разделенными административными границами. Вследствие этого в ре- альном мире этот вид координации применяется редко. Второй способ поддержки связей основан на использовании тупиковых зон. Тупи- ковая зона, по существу, представляет собой подчиненную зону, но она содержит толь- ко записи NS и соответствующие записи А ее серверов имен. Аналогично подчиненной зоне тупиковая зона обновляется автоматически и таким образом исключает необхо- димость обмена информацией между администраторами родительской и дочерних зон.
Глава 17. Система доменных имен 641 Следует помнить, что тупиковые зоны должны конфигурироваться идентично глав- ному и подчиненному серверам родительской зоны. Возможно, проще всего было бы поддерживать контакт с родительской зоной и проверять ее конфигурацию несколько раз в году (особенно если она является локальной). Для того чтобы увидеть, какие серверы родительского домена в настоящее время яв- ляются доступными, можно использовать команду dig. Сначала надо выполнить команду $ dig родитель с кий-домен ns и определить серверы имен в своем родительском домене. Затем следует выбрать один из них и выполнить команду $ dig @имя_сервера .родительский_домен дочерний_домен ns для просмотра списка публичных серверов имен. Тупиковые зоны оказываются очень полезными, когда ваша внутренняя сеть использует пространство частных IP-адресов, определенных в документе RFC 1918, и вам необходимо поддерживать синхронное деле- гирование в соответствии с документом RFC1918. Мы осветили большинство вопросов, касающихся системы Domain Name System в целом и ее базы данных в частности. В следующем разделе опишем детали конфйгу- рации, характерные для реализации сервера BIND. Реализация сервера NSD/Unbound будет описана в разделе 17.11. 1 7.9. Программное обеспечение системы BIND BIND (Berkeley Internet Domain Name System) — это созданное консорциумом ISC открытое программное обеспечение, реализующее протокол DNS для операционных си- стем Linux, UNIX, Mac OS и Windows. Существует три основные версии пакета BIND: BIND 4, BIND 8 и BIND 9. Система BIND 10 в настоящее время еще разрабатывается консорциумом ISC. В этой книге мы рассмотрим только пакет BIND 9. Определение версии Довольно часто поставщикам не приходит в голову явно указать, какую версию па- кета они реализовали в своей системе, поэтому приходится изощряться, чтобы точно выяснить, с каким именно программным обеспечением мы имеем дело. Иногда номер версии можно определить с помощью хитроумного запроса на основе утилиты dig, ко- торая является частью пакета BIND. Команда $ dig @сервер version.bind txt chaos возвращает номер версии, содержащийся в конфигурационном файле пакета BIND. Сначала определим имя сервера имен для исследуемого домена $ dig домен ns и затем выполним запрос version.bind. Например, вот как эта команда работает с сайтом is с. org. $ dig @ns-ext.isc.org version.bind txtx chaos version.bind. 0 CH TXT "9.5.1" Однако она не работает с сайтом cs. Colorado. edu.
642 Часть II. Работа в сети $ dig @mroe.cs.Colorado.edu version.bind txt chaos version.bind. 0 CH TXT "wouldn't you like to know..."17 Некоторые организации так конфигурируют систему BIND, чтобы замаскировать номер версии, исходя из того, что это как бы обеспечивает определенную степень “без- опасности, обеспечиваемой неясностью”. Мы не одобряем этого, но иногда таким об- разом можно отразить атаки взломщиков-дилетантов. Более подробно этот вопрос об- суждается немного ниже. Этот запрос работает и с другим программным обеспечением DNS. Например, запрос $ dig @k.root-servers.net version.bind txt chaos version.bind. 0 CH TXT "NSD 2.3.7" показывает, что на корневом сервере имен К выполняется система NSD. Другой фрагмент информации в классе CHAOS идентифицирует имя запрашиваемо- го сервера. Однако если вы только что послали серверу запрос, значит, вы должны знать его имя, не так ли? На самом деле некоторые очень загруженные серверы (например, корневые серверы имен) представляют собой множество машин, распределенных по земному шару и объединенных одним именем сервера и IP-адресом. Эта схема репли- кации называется “альтернативной маршрутизацией” (“antcast routing”). Система марш- рутизации находит по вашему запросу “ближайший” экземпляр. Если вы — системный администратор, пытающийся решить проблему, то может оказаться важным идентифи- цировать сервер, к которому вы получили доступ. Например, можно выполнить такие команды. $ dig @k.root-servers.net hostname.bind txt chaos hostname.bind. 0 CH TXT "k2.nap.k.ripe.net" ИЛИ $ dig @k.root-servers.net id.server txt chaos id.server. 0 CH TXT "k2.nap.k.ripe.net" Сообщество IETF пытается стандартизовать эти странные имена класса CHAOS в формах, которые не зависели бы от реализации version. server или id. server, но только форма id. server прошла всю процедуру до конца. Форма version. server су- ществует в виде черновика и никогда не была описана документом RFC. Система NSD использует все четыре формы, а пакет BIND — только три одобренные. Ш Более подробная информация о стандарте syslog изложена в главе 11. В качестве системного администратора вы можете запустить сервер имен (named или nsd) с флагом -f, чтобы он напечатал номер своей версии в стандартном виде, и выйти. В системе Linux вы можете запросить у своего менеджера пакетов номер инсталлирован- ной версии. Кроме того, вы обычно можете узнать номер версии системы BIND, загля- нув в файлы регистрации в каталоге /var/log или их эквивалент. Сервер имен системы BIND регистрирует свой номер версии в системе syslog при загрузке. Команда grep в системе BIND выводит на экран примерно такие строки. Jul 13 07:19:55 nubark named[757]: starting BIND 9.5.0-P2 -u named Если эти попытки не принесли результаты, следует помнить, что номер версии ко- манды dig обычно совпадает с номером версии сервера named, причем утилита dig ча- сто устанавливается даже тогда, когда сервер named не инсталлирован. Первая строка вывода утилиты dig содержит номер версии в качестве комментария. 17 Цифра 0 в ответе представляет собой значение TTL. Один из наших рецензентов сообщил, что однажды видел такой ответ на этот запрос: “Name is Bind, James Bind!”
Глава 17. Система доменных имен 643 Версии системы BIND, содержащейся в наших эталонных операционных системах, перечислены в табл. 17.8. Безопаснее всего использовать текущую версию. Таблица 17.8. Версии системы BIND, поставляемой с нашими эталонными операционными системами -г.Датавылуск^р^^^ ~isc - 9.6.1-P3 Январь 2010 Ubuntu 9.04 9.6.1-P2 Март 2009 SUSE 10.2 9.4.2 Ноябрь 2007 RHEL 5.3 9.3.4-P1 Июль 2007 Solaris 5.10 9.3.4-P1 Июль 2007 OpenSolaris 2009.06 9.6.1-P1 Июль 2009 HP-UX 11 9.3.2 Декабрь 2005 AIX 6.1 8.3.3+ или 9.2.1 Январь 2004 • Операционная система AIX поставляется с исполняемыми файлами пакетов BIND 8 и BIND 9, которые называются named8 и named9 соответственно. При поставке обобщенная форма named связывается с файлом oamed8. Символ + в номере версии обозначает сокращение “+Fox_fo_CERT_till_07_15_04”. Большинство поставщиков вносят исправления, касающиеся безопасности, в старые версии вместо обновления последней версии, поступившей от консорциума ISC, поэ- тому номера версий могут вводить в заблуждение. Легко убедиться, что многие версии являются довольно старыми, поэтому первейшей задачей системного администратора DNS является обновление программного обеспечения. Компоненты системы BIND В пакет BIND входит четыре основных компонента: • демон сервера имен named, отвечающий на запросы; • библиотечные функции, контактирующие с серверами распределенной базы дан- ных DNS от имени пользователей; • утилиты nslookup, dig и host, позволяющие выполнять DNS-запросы из ко- мандной строки; • программа rndc для дистанционного управления демоном named. Главнейшей задачей системного администратора, работающего с пакетом BIND, яв- ляется упорядочение многочисленных опций и функциональных возможностей, предо- ставляемых пакетом BIND, а также выбор наиболее подходящих для текущей ситуации. Файлы конфигурации Полная конфигурация демона named включает его конфигурационный файл, фай- лы данных зоны, содержащие адресные привязки для каждого узла, и файл подсказок Для корневого сервера имен. Авторитетные серверы должны иметь файл конфигурации и файлы данных зоны для каждой зоны, относительно которых они являются главными серверами. Кеширующие серверы должны иметь файл конфигурации и файл подсказок Для корневого сервера имен. Файл конфигурации демона named имеет специфический
644 Часть II. Работа в сети формат; все остальные файлы представляют собой коллекции отдельных записей дан- ных DNS, рассмотренных в разделе 17.8. В конфигурационном файле named, conf демона named задается роль узла (главный, подчиненный, тупиковый или только кеширующий) и определяется способ, которым он должен получать копию записей о данных каждой зоны, которую он обслуживает. Здесь же приводятся всевозможные параметры — как глобальные, связанные с работой самого демона named, так и локальные, связанные с серверами и зонами и относящиеся только к части трафика DNS. Файл конфигурации состоит из набора инструкций, каждая из которых оканчивается точкой с запятой и описывается в последующих разделах книги. К сожалению, формат файла довольно “хрупкий”: достаточно одной пропущенной точки с запятой, чтобы все перестало работать. К счастью, в пакете BIND имеются удобные средства проверки синтаксиса конфи- гурационного файла (named-checkconf) и зонных файлов (named-check zone). Эти утилиты ищут не только синтаксические ошибки, но и очевидные пропуски. Например, утилита named-checkzone выдаст предупреждение, если в файл не включена директива $TTL. Но в каждой бочке меда есть ложка дегтя. Например, не выявляются пропущен- ные связующие записи (см. раздел 17.8), хотя их отсутствие приводит к повышению на- грузки на корневые серверы и серверы организационных доменов gTLD. Комментарии допускаются везде, где могут стоять пробелы. Поддерживаются ком- ментарии в стиле языков С, C++ и командного интерпретатора, но лучше выбрать один стиль и придерживаться только его. /* Это комментарий, который может занимать несколько строк. */ // Весь текст до конца строки является комментарием. # Весь текст до конца строки является комментарием. Каждая инструкция начинается с ключевого слова, определяющего ее тип. Может при- сутствовать несколько инструкций одного типа, за исключением options и logging. От- дельные инструкции, а также их части могут отсутствовать; в этом случае будут приняты установки по умолчанию. Список поддерживаемых инструкций приведен в табл. 17.9. Таблица 17.9. Инструкции, используемые в файле named.conf options acl key trusted-keys server masters logging Подключает внешний файл Задает глобальные параметры конфигурации сервера имен, а также установ- ки по умолчанию Формирует списки управления доступом Определяет параметры аутентификации Задает заранее установленные ключи шифрования Задает параметры сервера Определяет список главных серверов для тупиковых и подчиненных зон Устанавливает категории журнальных сообщений и каналы их распространения statistics-channels Выводит текущую статистику в виде XML-файла Определяет зону записей о ресурсах Определяет, как утилита ndc будет управлять сервером имен named Определяет представление данных зоны Конфигурирует сервер имен named в качестве упрощенного распознавателя controls view Iwres
Глава 17. Система доменных имен 645 Прежде чем приступать к описанию этих инструкций и их использования для кон- фигурирования демона имен named, необходимо рассказать о специальной структуре данных, используемой во многих инструкциях, — список соответствия адресов (address match list). Этот список является обобщением понятия IP-адреса и может включать: • IP-адрес, либо v4, либо v6 (например, 199.165.145.4); • адрес сети с маской CIDR18 (например, 199.165/16); • имя ранее определенного списка управления доступом (задается с помощью ин- струкции acl); • криптографический ключ аутентификации; • оператор отрицания !. Списки соответствия адресов используются в качестве аргументов инструкций и оп- ций. Приведем ряд примеров. { ! 1.2.3.13; 1.2.3/24; }; { 128.138/16; 198.11.16/24; 204.228.69/24; 127.0.0.1; }; В первом списке из числа адресов исключается узел 1.2.3.13, но разрешаются другие адреса в сети 1.2.3.0/24. Во втором списке указаны сети, закрепленные за университетом штата Колорадо. Фигурные скобки и завершающая точка с запятой не являются частью списка; они относятся к инструкции, в которой содержится список. Когда IP-адрес или адрес сети проверяется на соответствие списку, содержимое спи- ска просматривается по очереди до тех пор, пока не будет найдено совпадение. Порядок элементов списка важен, так как ищется первое совпадение. Например, если в первом из показанных выше списков поменять элементы местами, результат не будет достигнут, поскольку адрес 1.2.3.13 удовлетворит первому условию (сетевому адресу 1.2.3.0/24) и второе условие никогда не будет проверяться. Перейдем к изучению инструкций! Некоторые из них лаконичны и ясны, а для опи- сания других может потребоваться отдельная глава. Инструкция include Когда конфигурационный файл становится слишком большим, можно разбить его на части, поместив их в отдельные файлы. Дополнительные компоненты подключаются к файлу named, conf посредством инструкции include. include "путь"; Если указан относительный путь, то он добавляется к имени каталога, заданному в параметре directory. Очень часто инструкцию include применяют для подключения файлов, содержащих криптографические ключи, которые должны быть недоступными для посторонних. Для того чтобы не запрещать доступ ко всему файлу named.conf, ключи хранят в отдельных файлах, которые может читать лишь демон named. Эти фай- лы затем включаются в файл named.conf. Многие организации размещают инструкции zone в отдельных файлах, а затем с по- мощью инструкции include объединяют их. Это позволяет отделить части конфигура- ции, являющиеся относительно статичными, от частей, подвергающихся частым изме- нениям. 18 Сетевые маски CIDR описываются в разделе 14.4.
646 Часть II. Работа в сети Инструкция options Эта инструкция задает глобальные параметры конфигурации, часть из которых впо- следствии может быть переопределена для конкретных зон или серверов. Общий формат инструкции имеет следующий вид. options { параметр; параметр; }; Если в файле named.conf нет инструкции options, принимаются значения по умолчанию. В пакете BIND существует много параметров, даже слишком много. В версии 9.7 их более 150, что очень затрудняет их изучение. Полный список параметров можно найти в документации. К сожалению, ходят слухи, что разработчики пакета BIND подумывают о том, чтобы удалить часть параметров, которые оказались неудачными или больше не нужны. Это будет ударом для организаций, которые все же используют такие параметры и нуждаются в них. Ниже будут описаны лишь те параметры, которые рекомендуется за- давать. (Мы опросили разработчиков пакета BIND и учли их мнения и советы.) Для более полного изучения параметров рекомендуем обратиться к одной из посвя- щенных системе DNS и пакету BIND книг, упомянутых в конце главы. Кроме того, сове- туем обратиться к документации, сопровождающей пакет BIND. Все параметры, вклю- чая их синтаксис и значения по умолчанию, описаны в документе ARM, находящемся в каталоге doc и входящем в дистрибутивный набор пакета. Кроме того, полный список параметров содержится в файле doc/misc/options. • По мере изложения будем сопровождать описание параметров краткими коммента- риями. Значения по умолчанию указываются в квадратных скобках после самого пара- метра. В большинстве случаев значения по умолчанию вполне приемлемы. Сами пара- метры перечисляются без определенного порядка. Ш Местоположение файлов directory "путь*1; [каталог запуска сервера] key-directory "путь"; [совпадает с параметром directory] Инструкция directory задает каталог, в который должен перейти демон named. Ког- да в конфигурационном файле встречаются относительные пути к файлам, они интерпре- тируются относительно этого каталога. Параметр путь должен быть абсолютным. В этот каталог помещаются все выходные файлы (отладочные, статистические данные и т.д.). Параметр key-directory определяет место хранения криптографического ключа. Он не должен быть доступен для посторонних. Мы рекомендуем хранить все конфигурационные файлы пакета BIND (кроме named. conf и resolv. conf) в подкаталоге каталога /var (или любого другого катало- га, где содержатся конфигурационные файлы других программ). Мы предпочитаем ката- логи /var/named или /var/domain. Ш Идентификация сервера имен version "строка" [реальный номер версии сервера] hostname "строка" [реальное имя сервера] server-id "строка" [реальный номер версии сервера]
Глава 17. Система доменных имен 647 Строка version идентифицирует версию программного обеспечения сервера имен, а строка hostname — сам сервер, как и строка server-id. Эти параметры позволяют скрывать истинные значения. Каждый из них позволяет записывать данные записи ТХТ в класс CHAOS, где любопытные хакеры могут найти их с помощью команды dig. Мы не советуем скрывать эти значения. С их помощью удобно запрашивать серверы имен и выяснять номера их версий, например, если вам необходимо узнать, установил ли ваш поставщик текущую версию или не надо ли установить новейшую версию всех серверов. Если все же приходится прятать номер версии, то, по крайней мере, введите строку, которая неявно сообщала бы вашему системному администратору информацию о версии. (Именно для этого предназначена новая запись о ресурсах NSID.) Данные, хранящиеся в этой текстовой записи, представляют собой строку, смысл которой поня- тен только вашему системному администратору, но не постороннему человеку. Параметры hostname и server-id были включены относительно недавно и пред- назначены для дублирования экземпляров корневого и общих доменов верхнего уровня при альтернативной маршрутизации. CQ Синхронизация зон notify yes | master-only | explicit | no; [yes] also-notify 1д_адреса_серверов; [пусто] allow-notify список_соответствующих_адресов; [пусто] Параметры notify и also notify применяются только к главным серверам, а па- раметр allow-notify — только к подчиненным. В ранних версиях сервер BIND синхронизировал файлы зон между главным и под- чиненным серверами только по истечении тайм-аута для обновления, заданного в зон- ных записях SOA. В настоящее время главный сервер named автоматически уведомляет подчиненные серверы при перезагрузке соответствующей зонной базы данных, если па- раметр notify равен yes. В ответ на полученное уведомление подчиненные серверы связываются с главным сервером, чтобы проверить, изменились ли файлы, и обновляют свои копии данных. Параметр notify может устанавливаться как на глобальном уровне, так и на уровне отдельных зон. Это позволяет быстрее обновлять зонные файлы при внесении измене- ний. По умолчанию каждый авторитетный сервер посылает обновления всем другим ав- торитетным серверам (такой способ Роль Викси (Paul Vixie) назвал “разбрызгиванием”). Если параметр notify установлен равным master-only, то “разговорчивость” сервера ограничена и уведомления посылаются только подчиненным серверам зон, по*отноше- нию к которым данный сервер является главным. Если параметр notify установлен равным explicit, то демон named уведомляет только серверы, указанные в разделе also-notify. Ш Более подробно тупиковые зоны обсуждаются в подразделе “Инструкция zone”. Демон named выясняет, какие компьютеры являются подчиненными серверами зоны, просматривая записи NS этой зоны. При наличии параметра also-notify будут так- же уведомляться дополнительные серверы, которые не зарегистрированы посредством записей NS. Подобный прием используется, если в организации имеются внутренние серверы. В списке also-notify не нужно указывать тупиковые серверы: их интересуют только записи NS, поэтому они могут участвовать в обычном цикле обновления. В списке also-notify должны присутствовать только IP-адреса и, возможно, пор- ты. Для серверов с несколькими интерфейсами дополнительные параметры задают IP- адреса и порты, предназначенные для исходящих уведомлений. Уведомления желатель-
648 Часть II. Работа в сети но также отключать для зон обратного преобразования узла localhost, поскольку они никогда не изменяются. Раздел also-notifу следует использовать только в том случае, когда вы хотите, чтобы вторичные серверы уведомлял сервер имен, а не главный сервер. recursion yes | no; [yes] allow-recursion { список_соответствия_адресов }; [все узлы] Параметр recursion указывает на то, должен ли демон named обрабатывать запро- сы пользователей рекурсивно. Этот параметр можно задать для авторитетного сервера своей зоны, но мы не рекомендуем это делать. Лучше всего разделить авторитетные и кеширующие серверы. Если сервер имен должен быть рекурсивным, то установите параметр recursive равным yes и включите раздел allow-recursion, чтобы демон named мог отличать за- просы, исходящие из вашей организации, от удаленных запросов. Демон named будет действовать рекурсивно для пользователей вашей организации и нерекурсивно — для всех остальных. Если ваш сервер имен рекурсивно обрабатывает все запросы, то он на- зывается открытым распознавателем (open resolver) и может стать рефлектором для не- которого вида атак (см. документ RFC5358). Ш Использование кеширующей памяти Если ваш сервер имеет ограниченный объем памяти, то иногда необходимо исполь- зовать параметры recursive-clients и max-cache-size. Параметр recursive- clients управляет многочисленными рекурсивными процессами поиска, которые сервер выполняет одновременно. Каждый из них требует около 20 двоичных Кбайт па- мяти. Параметр max-cache-size ограничивает объем памяти сервера, который будет использоваться для кеширования ответов на запросы. Если объем кеша увеличивается слищком сильно, то демон named удаляет записи до истечения их периода TTL, чтобы предотвратить превышение лимита. Ш Использование 1Р-порта use-v4-udp-ports [ use-v6-udp-ports [ avoid-v4-udp-ports avoid-v6-udp-ports range начало конец] range начало конец] [ список_портов ] ; [ список_ портов ]; [range 1024 65535] [range 1024 65535] [пусто] [пусто] query-source-v4 v4-адрес [ порт ]; [любой] #ВНИМАНИЕ, не используйте port query-source-v6 ve-адрес [ порт ] ; [любой] #ВНИМАНИЕ, не используйте port Порты источника стали играть важную роль в системе DNS после обнаружения ошибки протокола DNS, выявленной Дэном Камински (Dan Kaminsky). Этот недоста- ток допускает атаку кеша DNS, когда серверы имен используют предсказуемые порты источника и идентификаторы запросов. Параметры use- и avoid- для портов UDP в сочетании с изменениями программного обеспечения демона named смягчили послед- ствия таких атак. Не используйте параметр query-address для того, чтобы задать фик- сированный порт источника для запросов DNS, иначе вы не сможете воспользоваться “защитой Каминского”, которая предусматривает использование большого количества случайных портов. Значения, задаваемые по умолчанию для параметров use-v*-udp-ports, не требуют изменений. Если ваш брандмауэр блокирует некоторые порты из заданного диапазона (например, порт 2049 для файловой системы SunPRC), то может возникнуть небольшая проблема. Когда ваш сервер имен посылает запрос, используя в качестве источника один
Глава 17. Система доменных имен 649 из заблокированных портов, брандмауэр блокирует ответ и сервер имен в конце концов прекращает ожидание и посылает запрос снова. Это не фатально, но раздражает. Во избежание этого следует использовать параметр avoid-v*-udp-ports, застав- ляющий систему BIND избегать заблокированных портов. Любые порты UDP с круп- ными номерами, заблокированные вашим брандмауэром, должны быть включены в этот список.19 Если вы обновляете свой брандмауэр в ответ на опасную атаку, то не забудьте обновить список портов тоже. Параметры query-source позволяют указывать IP-адреса, предназначенные для ис- ходящих запросов. Например, может возникнуть необходимость использовать конкрет- ный IP-адрес, чтобы пройти через брандмауэр или отличить внутреннее представление от внешнего. Запросы исходят из случайно выбранных портов с крупными номерами, а ответы возвращаются обратно через те же самые порты. Следовательно, ваш брандмауэр дол- жен быть подготовлен к приему UDP-пакетов, поступающих на порты с крупными но- мерами. Некоторые системные администраторы используют специальный номер порта источника, который можно указать брандмауэру, чтобы он распознавал его и принимал UDP-пакеты только через этот порт. Однако эта конфигурация больше не являетсй без- опасной из-за дефекта протокола DNS, обнаруженного Камински. Если вы используете параметр query-source, то укажите только IP-адрес, с которо- го хотите посылать запросы; не указывайте номер порта. CQ Использование переадресации forwarders { 1р_адрес; 2.р_адрес; ... }; [пустой список] forward only | first; [first] Вместо того чтобы каждый сервер имен выполнял собственные внешние запросы, можно сделать один или несколько серверов переадресующими. В такой конфигурации обычный сервер просматривает в своем кеше записи, для которых он авторитетен, и, если не находит ответ, посылает запрос переадресующему серверу. Последний создает кеш, ко- торым пользуются все остальные серверы. Назначение происходит неявно — в файле кон- фигурации сервера нет никакой информации о том, что он является переадресующим. В параметре forwarders приводится список IP-адресов компьютеров, являющих- ся переадресующими серверами. Они опрашиваются по очереди. При использовании переадресующего сервера традиционная процедура поиска домена, которая начинается с корневого сервера, а затем продолжается по цепочке отсылок, нарушается, поэтому нужно внимательно следить за тем, чтобы не возникало циклов переадресации. Сервер, для которого установлен атрибут forward only, опрашивает переадресующие серверы и кеширует их ответы самостоятельно. Если переадресующий сервер не ответит, запрос потерпит неудачу. Сервер с атрибутом forward first связывается с переадресу- ющими серверами, но при необходимости может обработать запрос самостоятельно. Поскольку у параметра forwarders нет значения по умолчанию, переадресация происходит только в том случае, когда она задана явно. Включать переадресацию можно либо глобально, либо в пределах отдельных зон. Ш Разрешения allow-query { список_соответствия_адресов }; [все узлы] allow-query-cache { список_соответствия_адресов }; [все узлы] 19 Некоторые брандмауэры запоминают состояние и могут распознавать ответ системы DNS на запрос, посланный секунду назад. Таким серверам не требуется помощь, обеспечиваемая параме- трами avoid-v*-udp-ports.
650 Часть IL Работа в сети allow-transfer { список_соответствия_адресов }; [все узлы] allow-update { список_соответствия_адресов }; [нет] blackhole { список_соответствия_адресов }; [нет] Эти параметры позволяют указать, какие узлы (или сети) могут обращаться к серве- ру имен и запрашивать пересылку зонных баз данных, а также динамически обновлять зоны. Списки соответствия адресов представляют собой слабый способ обеспечения безопасности и уязвимы для подделки IP-адресов, поэтому полагаться на них рискован- но. Вероятно, не составит никакого труда заставить ваш сервер ответить на DNS-запрос, но следует избегать использования параметров allow update и allow transfer; вме- сто них следует использовать криптографические ключи. В списке blackhole перечислены серверы, которые никогда не “удостоятся внима- ния” демона named: он не будет принимать от них запросы и обращаться к ним за от- ветом. 03 Размеры пакетов edns-udp-size номер; [4096] max-udp-size номер; [4096] Все компьютеры в Интернете должны иметь возможность заново собирать фрагмен- тированные UDP-пакеты, размер которых составляет 512 байт и меньше. Эти консер- вативные требования имели смысл в 1980-х годах, но в настоящее время такой размер смехотворно мал. Современные маршрутизаторы и брандмауэры могут обрабатывать на- много более крупные пакеты, но достаточно всего одного неправильного звена в цепоч- ке IP-адресов, чтобы прервать весь путь. Поскольку система DNS использует для запросов пакеты UDP, а ответы часто превы- шают 512 байт, ее администраторы иногда опасаются утери крупных UDP-пакетов. Если большой по размеру пакет был фрагментирован, а ваш брандмауэр пропускает только первый фрагмент, то получатель получит усеченный ответ и повторно пошлет запрос по протоколу TCP. Протокол TCP связан с намного более крупными затратами ресурсов, в то же время загруженные серверы в корневом узле и серверы TLD не должны увеличи- вать трафик по протоколу TCP из-за того, что у кого-то вышел из строя брандмауэр. Параметр edns-udp-size задает размер буфера для повторной сборки, который сервер имен сообщает посредством протокола EDNS0, представляющего собой расши- ренный вариант протокола DNS. Параметр max-udp-size задает максимальный раз- мер пакета, который сервер может реально посылать. Оба размера измеряются в байтах. Разумным диапазоном является 512-4096 байт. Оба значения по умолчанию равны 4096 байт. Это позволяет использовать новые функциональные возможности, предоставляемые спецификациями DNSSEC. Однако некоторые (неисправные) брандмауэры не допускают UDP-пакеты, размер которых превышает 512 байт, а другие брандмауэры настроены так, чтобы блокировать все, кро- ме первого пакета фрагментированного UDP-ответа. Единственным выходом из такой ситуации является ремонт брандмауэров. Для того чтобы понять, какой размер пакета подходит для вашей организации, по- пробуйте выполнить команду dig rs. dns-oarc. net txt и посмотрите на ответ. Более подробно эта тема освещена в разделе 17.13, где речь идет о размере ответов, которые посылает сервер DNS-OARS. Если эта утилита показывает, что размер ответа невелик, то проблема, вероятно, заключается в брандмауэрах, которые следует исправить. В качестве временного решения можно попытаться установить параметр max-udp- size равным значению, которое возвращает сервер DNS-OASR. Эта установка позволя- ет демону named внедрять свои ответы в пакеты, которые могут остаться нефрагментиро-
Глава 17. Система доменных имен 651 ванными. Параметр edns-udp-size также следует установить равным этому значению, чтобы ваши пакеты могли проходить в обоих направлениях. После исправления бранд- мауэров не забудьте восстановить прежние значения параметров — 4096 байт! Не прибегайте к этим мерам, если не уверены, что проблема с размерами пакетов действительно существует, поскольку они также ограничивают размер пакета, переда- ваемого вдоль путей, которые на самом деле могли бы пропустить 4096 байт. Ш Управление спецификациями DNSSEC dbssec-enable yes | no; [yes] dbssec-validation yes | no; [yes] dbssec-lookaside домен trust-anchor домен; [".’’, '’dlv.isc.org'’] dnssec-must-be-secure домен yes | no; [none] Эти параметры конфигурируют поддержку спецификаций DNSSEC. Обсуждение спе- цификаций DNSSEC и подробное описание их настроек приведены в разделе 17.13. Параметр dsnsec-enable на авторитетном сервере должен быть включен. Для ре- курсивных серверов должны быть включены параметры dnssec-enable и dnssec- validation, а также указана точка доверия с помощью инструкции trusted-key. Если в домене нет точки доверия, то программное обеспечение попытается найти ее с помощью параметра dnssec-lookaside, обойдя проблему, которая возникает с роди- тельским доменом, не использующим спецификаций DNSSEC. По умолчанию параметры dnssec-enable и dnssec-validation включены. Это приводит к таким последствиям. • Авторитетный сервер подписанной зоны с включенным битом DNSSEC, отвечая на запрос, возвращает ответ, содержащий требуемые записи о ресурсах и их подписи. • Авторитетный сервер подписанной зоны с выключенным битом DNSSEC, отвечая на запрос, возвращает ответ, содержащий только требуемые записи о ресурсах, как это делалось до появления спецификаций DNSSEC. • Авторитетный сервер неподписанной зоны возвращает ответ, содержащий только требуемые записи о ресурсах; подписи в него не включаются. • Рекурсивный сервер посылает запросы от имени пользователей с включенным би- том DNSSEC. • Рекурсивный сервер проверяет подписи, включенные в подписанные ответы, пре- жде чем возвращать данные пользователю. Параметрами в разделе dnssec-lookaside являются два домена. Например, значе- ния по умолчанию эквивалентны следующей строке конфигурации. dnssec-lookaside ” . ’’ trust-anchor "div.isc.org”; Эта конфигурация сообщает серверам имен, пытающимся установить цепочку дове- рия, что они должны соединиться с узлом div. isc. org , если не могут получить ин- формацию о безопасном делегировании от корневого узла дерева имен DNS. Как только корневые домены и домены верхнего уровня станут подписанными и будут обслуживать- ся с помощью протокола DNSSEC, ассоциативная проверка (lookaside validation) станет ненужна. Обсуждение преимуществ и недостатков структуры DLV (DNSSEC Lookaside Validation) и последствий ее применения можно найти в разделе 17.13. Элемент конфигурации dnssec-must-be-secure позволяет указать, что вы будете принимать только безопасные ответы от конкретных доменов или, наоборот, вам все Равно и вы согласны принимать небезопасные ответы. Например, вы можете задать зна- чения yes для домена important-stuff .mybank. com и no — для домена marketing.
652 Часть II. Работа в сети mybank.com. Домен, о котором идет речь, должен быть упомянут в разделе trusted- keys или зарегистрирован DLV-сервером. Ш Статистика zone-statistics yes | по [по] Этот элемент конфигурации заставляет демона named накапливать статистические данные как о зонах, так и в целом. Более подробно вопросы накапливания статистиче- ских данных и их отображения обсуждаются в разделе 17.15. 03 Настройка производительности clients-per-query целое_число; [10] ♦Количество клиентов, ♦ожидающих один и тот же запрос max-clients-per-query целое_число; [100] ♦Максимально допустимое количество ♦клиентов до отказа сервера datasize целое_число [не ограничено] ♦Максимальное количество памяти, ♦которое может использовать сервер files целое_число [неограничено] ♦Максимальное количество ♦одновременно открытых файлов lame-ttl целое_число; [lOmin] ♦Период времени до кеширования ♦сбойного сервера max-acashe-size целое_число [] ♦Размер кеша для дополнительных ♦данных max-cashe-size целое_число [] ♦Максимальный размер памяти ♦для кешированных ответов max-cashe-ttl целое_число [lweek] ♦Максимальный период TTL для ♦кеширования позитивных данных max-journal-size целое_число [] ♦Максимальный размер файла ♦для журнала трансакций max-ncashe-ttl целое_число [] ♦Максимальный период TTL для ♦кеширования негативных данных tcp-clients целое_число; [100] ♦Максимально допустимое количество ♦ТСР-клиентов Этот длинный список элементов конфигурации можно использовать для настрой- ки демона named, чтобы он хорошо работал на вашем аппаратном обеспечении. Мы не описываем их подробно, но если у вас возникнут проблемы с производительностью, сначала следует попробовать устранить их с помощью этих настроек. Итак, мы завершаем обзор параметров! Перейдем к остальным инструкциям. Инструкция acl Список управления доступом — это просто именованный список соответствия адресов. acl имя_списка { список_ со ответствия_адресов }; Заданное имя можно указывать везде, где требуется список соответствия адресов. Инструкция acl должна быть самой первой в файле named, conf, так что не пытай- тесь ставить ее среди других объявлений. Файл named.conf читается за один проход, поэтому списки управления доступом должны быть определены до того, как на них встретится ссылка. Существует четыре стандартных списка: • any — соответствует всем узлам; • localnets — всем узлам локальной сети;
Глава 17. Система доменных имен 653 • localhost — самому компьютеру; • попе — не соответствует ни одному узлу. Сети, входящие в группу local nets, определяются адресами интерфейсов компью- тера с учетом сетевых масок. Инструкция key (TSIG) Рассматриваемая инструкция определяет именованный ключ шифрования (т.е. па- роль), используемый для аутентификации соединения между двумя серверами, напри- мер между главным и подчиненным серверами при передаче зоны или между сервером и процессом rdns, который им управляет. Подробнее о механизмах аутентификации, используемых в пакете BIND, речь пойдет в разделе 17.13. Здесь же мы лишь вкратце опишем суть процесса. Для создания ключа нужно указать как алгоритм шифрования, так и совместный се- кретный ключ, который представлен в виде строки, закодированной в формате Base64 (см. раздел 17.13). key идентификатор— ключа { algorithm строка; secret строка; }; Как и в случае списков управления доступом, идентификатор ключа должен быть определен в файле named, conf с помощью инструкции key до того, как встретится ссылка на ключ. Для того чтобы связать ключ с конкретным сервером, включите иден- тификатор ключа в список keys соответствующей инструкции server. Ключ использу- ется как для проверки запросов, поступающих от сервера, так и для подписи ответов на эти запросы. Секретная информация, принадлежащая группе лиц, не должна храниться в файле, доступном для внешнего мира. Для включения его в файл named, conf следует исполь- зовать инструкцию include. Инструкция trusted-keys С теоретической точки зрения родительские зоны DNSSEC аутентифицируют от- крытые ключи своих дочерних зон, позволяя создавать цепочки аутентифицированных подписей вплоть до корня системы DNS. На практике корневой домен и домены верх- него уровня еще не поддерживают спецификации DNSSEC, поэтому необходим другой метод проверки открытых ключей зон. Инструкция trusted-keys является довольно грубым способом сообщить демону named, что правильным открытым ключом зоны XXX.com является YYY, обойдя тем са- мым механизм DNSSEC, предназначенный для получения и верификации зонных клю- чей. Такое объявление иногда называют “точкой доверия” (“trust anchor”). Разумеется, зона XXX.com должна быть достаточно важной для вашей организации, чтобы уделить ей особое внимание, и вы должны иметь безопасный, внеполосный спо- соб определения правильного значения ее ключа. Нет волшебных способов получить правильный ключ; администратор внешней зоны должен прочитать его вам по телефону или послать как-то иначе. Для этой цели часто используется безопасная с точки зрения протокола HTTPS веб-страница. При изменении ключа этот процесс придется повто- рить с самого начала.
654 Часть II. Работа в сети Формат инструкции trusted-keys имеет следующий вид. trusted-keys { домен флаги протокол алгоритм ключ; домен флаги протокол алгоритм ключ; Каждая строка представляет точку доверия для конкретного домена. Атрибуты флаги, протокол и алгоритм являются неотрицательными целыми числами. Атрибут ключ — это строка, закодированная в формате Base64. Инструкция trusted-keys используется в тех случаях, когда зона имеет цифровую подпись, а ее родительская зона — нет, поэтому нельзя быть уверенным в том, что от- крытый ключ, получаемый от DNS-сервера, действительно надежен. Подробнее о технологии DNSSEC рассказывается в разделе 17.13. Инструкция server Демон named способен общаться с серверами, которые не используют последнюю версию пакета BIND или просто неправильно сконфигурированы. Инструкция server сообщает демону характеристики удаленных серверов. Она может заменять стандартные значения параметров конкретного сервера, хотя это не обязательно, пока вы не захотите сконфигурировать ключи для передачи зоны. server ip-адрес { bogus yes I no; [no] provide-ixfr yes | no; [yes] request-ixfr yes | no; [yes] keys {идентификатор_ключа; идентификатор_ключа; ...}; [нет] transfer-source ip-адрес [ближайший интерфейс] transfer-source-v6 ipv6-адрес [ближайший интерфейс] }; Посредством инструкции server можно переопределять значения глобальных конфи- гурационных параметров, относящихся к серверам. Просто укажите нужные параметры и их новые значения. Мы показали не все параметры инструкции server, а только самые необходимые. Полный список параметров можно найти в документации пакета BIND. Если для сервера задан атрибут bogus, демон named не посылает ему запросы. Этот । атрибут следует устанавливать для серверов, которые работают неправильно. Параметр bogus отличается от глобального атрибута blackhole тем, что подавляет только внеш- ние запросы. В отличие от него, атрибут blackhole полностью исключает все формы взаимодействия с перечисленными серверами. Сервер версии, являющийся главным сервером динамически обновляемой зоны, вы- полняет инкрементные зонные передачи, если атрибут provide-ixfr равен yes. Точно так же подчиненный сервер запрашивает инкрементные зонные передачи от главного сервера, если атрибут request-ixfr равен yes. Динамическая система DNS обсужда- ется в разделе 17.12. В списке keys задаются идентификаторы ключей, которые ранее были определены в инструкции key для использования в сигнатурах транзакций TSIG (о них рассказывает- ся в разделе 17.13). К любому запросу, посылаемому удаленному серверу, будет добавлена сигнатура, зашифрованная посредством этого ключа. Запросы, поступающие от удален- ного сервера, могут не иметь цифровой подписи, но если она есть, то будет проверена.
Глава 17. Система доменных имен 655 Атрибут transfer-source определяет IPv4- и 1Ру6-адреса интерфейса (и, возможно порта), которые следует использовать в качестве адреса источника (порта) для запросов на передачу зоны. Эти атрибуты необходимы только тогда, когда система имеет несколь- ко интерфейсов и IP-адрес удаленного сервера указан в списке allow-transfer. Инструкция masters Эта инструкция позволяет задавать имена одного или нескольких главных серверов, указывая их IP-адреса и криптографические ключи. Затем это имя можно использовать в разделе masters инструкций zone вместо повторения IP-адресов и ключей. CQ В каких случаях главных серверов бывает несколько? Ответ см. через несколько страниц. Инструкция masters удобна, когда несколько подчиненных или тупиковых зон по- лучают данные от одного и того же удаленного сервера. Если адреса и криптографиче- ские ключи удаленного сервера изменились, вы можете обновить инструкцию masters, которая их задает, а не изменять многочисленные инструкции zone. Синтаксис этой инструкции выглядит следующим образом. masters имя [ ip-адрес [port ip-порт] [key ключ]; ...] Инструкция logging Демон named в настоящее время заслуживает награды “За наиболее конфигурируе- мую подсистему журнальной регистрации на Земле”. Система Syslog предоставляет про- граммистам контроль над приоритетами сообщений, а системным администраторам — контроль над местом хранения этих сообщений. Но в рамках заданного приоритета администратор не может указать: “Это сообщение меня интересует, а это — нет”. В си- стему BIND были добавлены категории, позволяющие классифицировать сообщения по типам, и каналы, расширяющие возможности в плане хранения сообщений. Категории назначаются программистом, а каналы — администратором. Поскольку вопросы журнальной регистрации лежат несколько в стороне от нашего повествования (особенно если учесть объем материала), мы рассмотрим их позднее. Инструкция statistics Эта инструкция statistics-channels позволяет соединиться с выполняемым де- моном named с помощью браузера и просмотреть статистические показатели, которые на нем собраны. Поскольку статистические показатели сервера имен могут быть кон- фиденциальными, следует ограничить доступ к этим данным, открыв их только для до- веренных узлов вашей собственной организации. Синтаксис этой инструкции выглядит следующим образом. statistics-channels { inet (ip-адрес | *) port порт# allow { список_соответствия_адресов } ; } В файл конфигурации можно включить несколько последовательностей inet-port- allow. По умолчанию IP-адреса заданы значением any, а порт — значением 80 (обыч- ное значение для порта HTTP). Для использования каналов сбора статистики демон named следует компилировать с помощью программы libxml2.
656 Часть II. Работа в сети Инструкция zone Это “сердце” файла named, conf, которое сообщает демону named о зонах, для ко- торых он авторитетен, и задает параметры управления каждой зоной. Инструкция zone также используется для предварительной загрузки “подсказок” с корневого сервера (“подсказки” — это имена и адреса корневых серверов, участвующих в инициализации DNS-поиска). Точный формат инструкции zone зависит от роли, которую демон named должен иг- рать в отношении этой зоны. Возможными типами зоны являются master, slave, hint, forward, stub и delegation-only. Мы не будем рассматривать зоны типов stub (ис- пользуется только в системе BIND) и delegation-only (применяется для прекращения использования записей с шаблонными символами в зонах верхнего уровня при извеще- нии служб регистратора). Остальные типы зон описаны в последующих разделах. Многие из рассмотренных ранее глобальных параметров могут быть частью инструк- ции zone, т.е. переопределять глобальные установки. Мы не будем повторно упоминать о них, за исключением тех параметров, которые наиболее часто используются. Конфигурирование главного сервера зоны Ниже показан формат инструкции zone для зоны, в которой демон named является главным сервером имен. zone "имя_домена" { type master; file "путь"; }; Доменное имя в спецификации зоны всегда дается в двойных кавычках. Зонная база данных хранится на диске в текстовом файле, доступном для редакти- рования. Поскольку нет соглашения об именовании этого файла, в объявлении зоны должна присутствовать директива file. Зонный файл представляет собой набор записей о DNS-pecypcax; их формат описан в разделе 17.8. В инструкции zone часто задается также ряд других серверных атрибутов. allow-query { список_соответствия_адресов }; [все узлы] allow-transfer { список_соответствия_адресов }; [все узлы] allow-update { список_соответствия_адресов }; [попе] zone-statistics yes I по; [по] Параметры, связанные с управлением доступом, не являются обязательными, но мы рекомендуем их использовать. Они содержат либо IP-адрес, либо криптографический ключ TSIG. Как правило, криптографический ключ является более безопасным. Если для зоны поддерживаются динамические обновления, в параметре allow-update дол- жен содержаться список узлов, от которых разрешено принимать данные. Динамические обновления применимы только в отношении главных зон; параметр allow-update не может присутствовать в объявлении подчиненной зоны. Убедитесь, что в списке указа- ны лишь локальные компьютеры (например, DHCP-серверы), а не весь Интернет20. Параметр zone-statistics заставляет демон named отслеживать статистику запро- сов/ответов, например точное число и общий процент отсылок, рекурсивных и ошибоч- ных запросов. Конкретные примеры приведены в разделе 17.15. 20 Необходима также входная фильтрация на брандмауэре (см. раздел 22.11), а еще лучше ис- пользовать технологию аутентификации TSIG.
Глава 17. Система доменных имен 657 При наличии столь большого числа зонных параметров (есть еще порядка сорока, о которых мы не рассказали) конфигурация зоны кажется довольно сложной. На самом деле допускается объявление главной зоны, состоящее только из пути к зонному файлу. В BIND 4 больше ничего нельзя задать. Ниже показан пример, взятый из документации и слегка модифицированный нами. zone "example.com'’ { type master; file "forward/example.com"; allow-query { any; }; allow-transfer { my-slaves; }; }; Имя my-slaves относится к списку управления доступом, определенному ранее. Конфигурирование подчиненного сервера зоны Формат инструкции zone для подчиненного сервера будет почти таким же, как и в случае главного сервера. zone "имя_домена" { type slave; file "путь"; masters { 1р_адрес [port ip_nopT] [key имя_ключа]; ... }; [нет] allow-query { список_соответствия_адресов }; [все узлы] }; Подчиненные серверы обычно хранят полную копию зонной базы данных. Директи- ва file задает имя локального файла, в котором сохраняется реплицированная база данных. Получив новую копию данных зоны, сервер сохраняет ее в этом файле. В слу- чае сбоя и перезагрузки сервера файл можно просто прочитать с диска, а не пересылать по сети. Редактировать файл реплицированной базы данных не нужно, так как он управля- ется демоном named. Тем не менее имеет смысл просмотреть его, если есть подозрение, что в базу данных главного сервера закралась ошибка. Файл подчиненной зоны создает- ся уже после того, как демон named интерпретировал исходные данные зоны и раскрыл все относительные имена. Когда в файле присутствуют имена наподобие 128.138.243.151.cs.colorado.edu. anchor.cs.Colorado.edu.cs.Colorado.edu. можно быть уверенным в том, что где-то пропущена завершающая точка. В списке masters перечислены IP-адреса компьютеров, с которых может быть за- гружена зонная база данных. Она также может содержать имя списка главных серверов, определенных предыдущей инструкцией masters. Ранее мы говорили, что только один компьютер может быть главным сервером зоны, так почему же разрешается список, состоящий из нескольких адресов? Во-первых, у главного компьютера может быть несколько сетевых интерфейсов и, соответственно, несколько IP-адресов. Когда один из интерфейсов становится недоступным (проблемы с сетью или маршрутизацией), остаются в резерве другие интерфейсы. Следовательно, рекомендуется указывать все топологически различные адреса главного сервера. Во-вторых, демону named в действительности все равно, откуда поступают данные зоны. Он так же легко загружает базу данных с подчиненного сервера, как и с главного. Этой особенностью демона можно воспользоваться для того, чтобы сделать подчинен- ный сервер, с которым легко устанавливается связь, резервной копией главного серве-
658 Часть II. Работа в сети ра. В любом случае IP-адреса проверяются по очереди до тех пор, пока не будет найден работающий сервер. Теоретически можно даже создать иерархию серверов, в которой главный сервер обслуживает несколько серверов второго уровня, а те, в свою очередь, обслуживают множество серверов третьего уровня. Советуем в директиве masters указывать только адреса главного сервера. Задание корневых “подсказок” Инструкция zone типа hint сообщает демону named местонахождение файла, из которого он может загрузить имена и адреса корневых серверов имен, чтобы предвари- тельно заполнить свой кеш. zone { type hint; file "путь"; }; “Подсказки” — это набор DNS-записей, в которых перечислены серверы корневого домена (“.”). Они нужны для того, чтобы демон named знал, откуда начинать поиск до- менов. Не имея “подсказок”, демон знал бы только о тех доменах, которые сам обслу- живает, а также об их поддоменах. Когда демон named начинает работу, он повторно загружает подсказки с одного из корневых серверов. Следовательно, все будет в порядке, если файл подсказок содержит хотя бы одну запись с правильным и доступным корневым сервером. Для резервирова- ния подсказки о корневом сервере также компилируются в демон named. Файл “подсказок” чаще всего называется root. cache. В нем содержатся результаты , ответов, которые можно получить, запросив у корневого сервера список серверов имен; в домене “. На самом деле вы можете сгенерировать файл подсказок, выполнив ути- литу dig. Рассмотрим пример. $ dig @f.root-servers.net . ns > root.cache Обратите внимание на точку. Если сервер f. root-servers. net не отвечает, вы мо- жете выполнить запрос, не указывая конкретный сервер. $ dig . ns > root.cache Результат будет аналогичный. Однако вы получите список корневых серверов от кеша локального сервера имен, а не от авторитетного сервера. Это должно быть удоб- но — даже если вы не перезагружали или перезапускали сервер имен год или два, он пе- риодически обновляет свои записи о корневых серверах по истечении их периода TTL. Задание зоны переадресации Зона типа forward переопределяет глобальные параметры переадресации демона named (сначала опрашиваем корневой сервер, а потом следуем по цепочке отсылок) для конкретного домена. zone "имя_домена" { type forward forward only | first; forwarders { 1р_адрес; 1р_адрес; ...} }; Создавать такую зону имеет смысл, если у организации имеется деловой партнер и нужно направлять трафик непосредственно его серверам имен в обход стандартного
Глава 17. Система доменных имен 659 пути распространения запросов. Благодаря этому можно получить доступ к серверам имен, которые невидимы внешнему миру. Инструкция controls для команды rdnc Инструкция controls определяет, каким образом команда rndc будет управлять ра- ботой демона named. Эта команда может запускать и останавливать демон, выводить от- чет о его состоянии, переводить демон в режим отладки и т.д. Будучи сетевой утилитой, она требует должной конфигурации, чтобы злоумышленники не могли через Интернет влиять на работу сервера имен. Формат инструкции controls имеет следующий вид. controls { inet 1р_адрес port 1р_порт allow { список_соответствия_адресов } keys {список_ключей} } В BIND также разрешается указывать порт, но если параметр ports опущен, по умолчанию принимается порт 953. Удаленное управление сервером имен кажется одновременно и удобной, и опасной процедурой. Аутентификация необходима, причем ключи, указанные в списке соответ- ствия адресов, игнорируются, а используются только те ключи, которые перечислены в списке keys. В системе BIND существует команда rndc-conf gen, позволяющая сгенерировать ключ аутентификации, используемый в диалоге между командой rndc и демоном named. Это можно сделать двумя способами. Первый способ — заставить обе стороны загрузить ключ из общего конфигурационного файла (/etc/rndc.key) или поместить ключ в два разных файла (/etc/rndc. conf для rndc и /etc/named. conf для named). Второй спо- соб сложнее, но он необходим, если демон named и команда rndc запускаются на раз- ных компьютерах. Команда rndc-confgen -а задает ключи для доступа к локальному узлу При отсутствии инструкции controls в список соответствия адресов заносится адрес интерфейса обратной связи, а ключ ищется в файле /etc/rndc. conf. Поскольку аутентификация в этой версии пакета обязательна, команда rndc не сможет управлять работой демона named без ключа. Это кажется чрезмерным требованием, но подумайте вот о чем: даже если команда rndc работает только на узле localhost (127.0.0.1) и его адрес заблокирован для внешнего мира на брандмауэре, вы все равно выдаете всем ло- кальным пользователям определенный кредит доверия, подразумевая, что они не будут делать ничего противозаконного с сервером имен. В то же время любой из них может подключиться с помощью утилиты telnet к управляющему порту и ввести “stop”. Ниже показаны результаты работы команды rndc-confgen, генерирующей 256-раз- рядный ключ (размер ключа объясняется тем, что он позволяет уместить результаты на странице!). Обычно вывод команды направляется не на экран, а в файл /etc/rndc. conf. Комментарии в нижней части включают строки, которые необходимо добавить в файл named, conf, чтобы демон named и команда rndc могли взаимодействовать. % ./rndc-confgen -Ь 256 # Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "orZuz5amkUnEp52zlHxD6cd5hACldOGsG/elP/dv2lY=";
660 Часть II. Работа в сети options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf # Use with the following in named.conf, adjusting the allow list # as needed: # key "rndc-key" { # algorithm hmac-md5; # secret ”orZuz5amkUnEp52zlHxD6cd5hACldOGsG/elP/dv2lY=”; # I; # # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { "rndc-key”; }; # }; # End of named.conf Расщепление DNS и инструкция view Во многих организациях требуется, чтобы внутреннее представление сети отлича- лось от представления этой сети с точки зрения пользователей Интернета. Например,? внутренние пользователи могут видеть все компьютеры зоны и лишь несколько разре-J шенных внешних серверов. Или другой вариант: внутреннее и внешнее представления одинаковы по охвату узлов, однако внутренним пользователям предоставляются допол- ; нительные (либо отличающиеся) записи. В частности, записи MX, предназначенные доий маршрутизации электронной почты, за пределами домена ссылаются на почтовый кон- : центратор, а внутри домена — на отдельные рабочие станции. Ш О частных адресных областях рассказывалось в разделе 14.4. ; Расщепленная конфигурация DNS особенно удобна организациям, которые во вну- тренних сетях применяют IP-адреса из частного диапазона (RFC1918). Например, за- ; прос об имени узла с IP-адресом 10.0.0.1 не может быть обработан глобальной системой^ доменных имен, но он вполне допустим в контексте локальной сети. Среди запросов,} поступающих на корневые серверы имен, 4-5% либо имеют исходный IP-адрес из част-) ного диапазона, либо ссылаются на такой адрес. Ни на один из этих запросов нельзя ответить. Запросы обоих типов являются следствием неправильной конфигурации либо пакета BIND, либо “доменов” Microsoft. Инструкция view содержит список адресов, определяющий, кто из клиентов имеет доступ к данному представлению, а также ряд параметров, применимых ко всем зонам в представлении, и, наконец, определения самих зон. Синтаксис инструкции имеет сле- дующий вид. view имя_представления { match-clients { список_соответствия_адресов }; [все узлы] match-destinations { список_соответствия_адресов }; [все узлы] match-recursive-only yes | по; [по] параметр—Представления; инструкция^one; . . . }
Глава 17. Система доменных имен SS Инструкция view всегда содержит атрибут match-clients, который фильтрует IP- адреса источников, указанные в пакете запроса, и обычно используется для обслужива- ния внутренних и внешних представлений данных DNS, принадлежащих организации. Для более качественного контроля можно также фильтровать адреса пунктов назначе- ния и требовать рекурсивные запросы. Атрибут match-destinations просматривает адреса назначения в пакете запроса и является полезным в компьютерах с нескольки- ми интерфейсами, когда вы хотите обрабатывать разные данные DNS в зависимости от интерфейса, из которого поступил запрос. Атрибут match-recursive-only требует, чтобы запросы были рекурсивными, а также высылались разрешенными клиентами. Итеративные запросы позволяют просмотреть кеш сайта; этот атрибут предотвращает такие ситуации. Представления просматриваются по порядку, поэтому инструкции view с самыми большими ограничениями доступа должны идти впереди. Зоны в разных представлени- ях могут иметь одинаковые имена. Представления налагают ограничение на структуру файла named.conf: если они присутствуют, все инструкции zone должны находиться в контексте представлений. Ниже приводится взятый из документации к BIND 9 пример, имитирующий разде- ление пространства DNS-имен на внутреннее и внешнее. В обоих представлениях зада- ется одна и та же зона, но с разной базой данных. view ’’internal" { match-clients { наши_сети; }; recursion yes; zone "example.com" { type master; file "example-internal.db"; // только внутренние сети // только для внутренних клиентов // полное представление зоны view "external" { match-clients { any; }; recursion no; zone "example.com" { type master; file ’’example-external.db"; // допускаются любые запросы // рекурсия запрещена // только "общедоступные" узлы Если поменять порядок представлений, никто не сможет получить доступ к внутрен- нему представлению. Адреса внутренних узлов пройдут проверку на соответствие усло- вию any в предложении match-clients внешнего представления до того, как начнет проверяться внутреннее представление. Второй пример представления DNS, который будет рассмотрен ниже, демонстрирует еще один вид представлений. 17.10. Примеры конфигурации системы BIND После подробного знакомства с файлом named, conf настало время рассмотреть ряд готовых примеров. В следующих подразделах мы опишем три типичные конфигурации: • зона локального узла;
662 Часть II. Работа в сети • сервер небольшой компании, занимающейся вопросами безопасности и приме- няющей расщепленную конфигурацию DNS; • эксперты: сайт isc.org консорциума Internet System Consortium. Зона локального узла Адрес 127.0.0.1 относится к самому локальному узлу и должен быть преобразован в имя “localhost. ”21 Одни организации преобразовывают адрес в имя “localhost. локальный^домен”, а другие делают и то, и другое. Соответствующий адрес в протоколе IPv6 равен ::1. Если вы забыли задать конфигурацию зоны локального узла, то ваша организация может прекратить посылать запросы корневым серверам на получение информации о локальном узле. Корневые серверы получают так много таких запросов, что операторы предлагают просто добавить обобщенное отображение между локальным узлом и адре- сом 127.0.0.1. на корневом уровне. По данным о корневом сервере К, в Европе в январе 2010 года (k. root-servers. org/statistics) запрос домена “local” занимает четвер- тое место по распространенности, отставая лишь от сот, агра и net. Это огромное ко- личество бесполезных запросов (1500 в секунду), которые посылаются занятым серве- рам имен. Другими необычными именами в популярной категории “фиктивные домены TLD” являются lan, home, localdomain и domain. Прямое преобразование имени локального узла можно определить в файле зоны прямого преобразования (forward zone) для домена (с помощью соответствующей ин- струкции $ORIGIN) или в своем собственном файле. Каждый сервер, даже кеширующий^ обычно является главным для своего собственного обратного домена локального узла. Ниже приведено несколько строк из файла named, conf, описывающих конфигура- цию локального узла. zone '’localhost" { // зона прямого преобразования локального узла type master; file "localhost"; allow-update { none; }; }; zone "0.0.127.in-addr.агра" { // зона обратного преобразования * II локального узла type master; file "127.0.0"; ч allow-update { none; }; < }; Соответствующий файл прямой зоны localhost содержит следующие строки. $TTL 30d ; localhost. @ IN SOA localhost, postmaster.localhost. ( 1998050801 ;регистрационный номер 3600 ;тайм-аут обновления 1800 ;тайм-аут повторения 604800 ;срок действия 3600 ) ;минимум 21 На самом деле к локальному узлу относится весь класс сетей А 127/8, но большинство ис- пользует просто адрес 127.0.0.1.
Глава 17. Система доменных имен 665 NS localhost. А 127.0.0.1 Обратный файл 127.0.0 имеет следующий вид. $TTL 30d ; 0.0.127.in-addr. агра @ IN SOA localhost, postmaster.localhost. ( 1998050801 ;регистрационный номер 3600 ;тайм-аут обновления 1800 ;тайм-аут повторения 604800 ;срок действия 3600 ) ;минимальный тайм-аут NS local host. 1 PTR localhost. Отображение для адреса локального узла (127.0.0.1) никогда не изменяется, поэто- му тайм-ауты могут быть большими. Обратите внимание на регистрационный номер , который кодирует дату; данный файл последний раз изменялся в 1998 году. Кроме того, обратите внимание на то, что для домена локального узла указан только главный сервер имен. Символ @ здесь означает “0.0.127. in-addr. агра. ”. Небольшая компания, предоставляющая консалтинговые услуги в области безопасности Наш следующий пример посвящен небольшой компании, специализирующейся на предоставлении консультаций по компьютерной безопасности. На ее сервере Red Hat Enterprise Linux установлен пакет BIND 9 и применяется расщепленная конфигурация DNS, в которой внутренние и внешние пользователи получают разную информацию. В компании используются адреса из частного диапазона. Запросы, касающиеся этих адресов, не должны выходить в Интернет и засорять глобальную систему доменных имен. Ниже приведен соответствующий файл named.conf, слегка переформатирован- ный и снабженный комментариями. options { directory "/var/domain"; version ”root@atrust.com"; allow-transfer {82.165.230.84; 71.33.249.193; 127.0.0.1;}; listen-on { 192.168.2.10; 192.168.2.1; 127.0.0.1; 192.168.2.12;} }; include "atrust.key"; // файл с режимом доступа 600, содержащий // определение ключа "atkey" controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { atkey; }; }; view "internal" { // внутреннее представление match-clients { 192.168.1.0/24; 192.168.2.0/24; }; recursion yes; include "infrustructure.zones"; // Корневые подсказки, прямое и обратное // преобразование адреса локального узла
664 Часть II. Работа в сети zone "atrust.com" { // Внутренняя зона // прямого преобразования // узла localhost type master; file internal/atrust.com"; }; zone "1.168.192.in-addr.arpa" { // внутренняя зона // обратного преобразования type master; file "internal/192.168.1.rev"; allow-update { none; }; }; ... // Тут пропущено много других зон include "internal/trademark.zones"! // atrust.net, atrust.org и другие // подчиненные серверы }; // конец внутреннего представления view "world" { // внешнее представление match-clients { any; }; recursion no; । zone "atrust.com" { 11 внешняя зона прямого преобразования: type master; file "world/atrust.com"; a;;ow-update { none; }; , }; I zone "189.172.63.in-addr.arpa" { // внешняя зона // обратного преобразования type master; ’ file "world/63.173.189.rev"; ; allow-update { none; }; }; include "world/trademark.zones"; // atrust.net, atrust.org и другие // подчиненные серверы zone "admin.com" { // Главные зоны только // во внешнем представлении type master; file "worls/admin.com"; allow-update [ none; ] ; }; ... // Тут пропущено много главных и // подчиненных зон // конец внешнего представления Файл atrust .key содержит определение ключа “atkey”. key "atkey" { algorithm hmac-md5; secret "совместный секретный ключ”; }; Конфигурационный файл infrastructure. zones содержит корневые подсказки и файлы локального узла, а файл trademark. zones — варианты имени atrust. com как
глава 17. Система доменных имен 665 в разных доменах верхнего уровня (net, org, us, info и т.д.), так и с разным написани- ем (appliedtrust. com и т.д.). Зонные файлы определяют два разных представления (внутреннее и внешнее) и тип сервера (главный или подчиненный). Это отображается в соглашении об именах файлов зон. Во внутреннем представлении данный сервер является рекурсивным. Это представ- ление содержит все локальные узлы, многие из которых используют частные адреса. Во внешнем представлении этот сервер не является рекурсивным. Это представление со- держит только выбранные узлы домена atrust. com и внешние зоны, для которых они обеспечивают DNS-услуги главных или подчиненных серверов. Ниже приведены фрагменты файлов internal/atrust.com и world/atrust. сот. Сначала рассмотрим файл internal. ; файл atrust.com - внутренний файл $TTL 86400 $0RIGIN com. atrust 3600 SOA nsl.atrust.com. trent.atrust.com. ( 2001110500 10800 1200 3600000 3600 3600 NS NSl.atrust.com. 3600 NS NS2.artust.com. 3600 MX 10 mailserver.atrust.com. 3600 A 66.77.22.161 $0RIGIN atrust. nsl .com. A 192.168.2.1 ns2 A 66.77.122.161 WWW A 66.77.122.161 mailserver A 192.168.2.11 exchange A 192.168.1.100 secure A 66.77.122.161 Здесь использованы частные адреса RFC1918. Кроме того, обратите внимание на то, что, вместо записей CNAME, для определения имен локального узла эта организация использует несколько записей А. Эта схема работает быстрее, поскольку она не учиты- вает результат проверки записи CNAME в дополнительном запросе. Записи PTR долж- ны ссылаться только на одно из многих имен, которые отображаются в один и тот же IP-адрес. Эта организация также делегирует поддомены для своих DHCP-сетей, нашей лаборатории и своей Microsoft-инфраструктуры (это во фрагментах не показано). Рассмотрим текст внешнего представления той же зоны atrust.com из файла world/atrust. com. ; файл atrust.com - внешний файл $TTL 57600 $ORIGIN atrust.com. 3600 SOA nsl. .atrust.com. trent.atrust.com. ( 2010030400 10800 1200 3600000 3600 3600 NS NS1.atrust.com. 3600 NS NS2.atrusr.com. 3600 MX 10 mailserver.atrust.com. 3600 A 66.77.122.161 nsl A 206.168.198.209 ns2 A 66.77.122.161 WWW A 69.77.122.161
666 Часть II. Работа в сети mailserver secure А 206.168.198.209 А 66.77.122.161 ; обратные преобразования exteriorl IN A 206.168.198.209 209.198.168.206 IN PTR exteriorl.atrust.com exterior2 IN A 206.168.198.213 213.198.168.206 IN PTR exterior2.atrust.com Как и во внутреннем преобразовании, имена реализованы с помощью записей А. Очень немногие узлы на самом деле видны во внешнем представлении, хотя из этих фрагментов это не следует. Обратите внимание на то, что компьютеры, которые видны в обоих представлениях (например, nsl. atrust. com), во внутреннем представлении имеют частные адреса RFC1918, а во внешнем — реальные IP-адреса. Параметр TTL в зонных файлах по умолчанию установлен равным 16 часам (57 600 се- кунд). В то же время для большинства записей зонных файлов значение TTL не назна- чается явно. Загадочные записи PTR в конце файла внешнего представления позволяют провай- деру компании atrust. com делегировать ей полномочия по управлению обратными преобразованиями в очень маленьких областях адресного пространства. Это делается с помощью записей CNAME на узле провайдера. Подробнее о специальном примене- нии записей CNAME рассказывается в разделе 17.8. Консорциум The Internet Systems Consortium (isc.org) Консорциум ISC — создатель и распространитель системы BIND, а также оператор корневого сервера Е. Он также владеет сервером TLD, обслуживающим многие домены верхнего уровня. Именно поэтому мы называем его экспертом! Ниже приведены фрагменты конфигурационных файлов. Обратите внимание на то, что они используют оба протокола IPv4 и IPv6. Кроме того, они используют шифро- вание TSIG для аутентификации главного и подчиненного серверов при передаче зон. Параметры transfer-source гарантируют, что IP-адреса источника для исходящей зоны передачи соответствуют требованиям спецификаций, установленных инструкция- ми allow-transfers на главном сервере. Файл named, conf имеет следующее содержание. // TLD-сервер имен организации isc.org options { directory "/var/named"; datasize 1000M; listen-on { 204.152.184.64; }; listen-on-v6 { 2001:4f8:0:2::13; }; recursion no; transfer-source 204.152.184.64; transfer-source-v6 2001:4f8:0:2::13; }; // ключ rndc key rndc_key { algorithm hmac-md5; secret ”<secret>";
Глава 17. Система доменных имен // Ключ TSIG для сервера имен ns-ext key ns-ext { algorithm hmac-md5; secret "<secret>"; }; server 204.152.188.234 { keys { ns-ext; }; }; controls { inet 204.152.184.64 allow { any; } keys { rndc_key; }; }; include "inf/named.zones"; // Корневой, локальный, 127.0.0.1, ::1 include "master.zones"; // Управляемые зоны include "slave.zones"; // Подчиненные зоны Инструкции include позволяют сохранить файл named.conf коротким и аккурат- ным. Если вы обслуживаете много зон, постарайтесь разбить свою конфигурацию на небольшие части, похожие на эти. И, что еще более важно, организуйте иерархию ва- ших файлов так, чтобы в ней не было каталога, содержащего тысячу зонных файлов. Современные файловые системы эффективно обрабатывают многочисленные каталоги, но управление этими файлами может быть очень утомительным. Рассмотрим содержимое файла master. zones. zone "isc.org" { type master; file "master/isc.org"; allow-update { none; }; allow-transfer { none; }; }; zone "sfo2.isc.org" { type master; file "master/sfo2.isc.org"; allow-update { none; }; allow-transfer { none; }; }; // Остальные зоны пропущены Содержимое файла slaves.zones выглядит так. zone "vix.com" { type slave; file "secondary/vix.com"; masters { 204.152.188.234; }; }; zone "cix.net" { type slave; file "secondary/cix.net"; masters { 204.152.188.234; }; }; Параметр allow-transfer, заданный в файле master. zones равным none, озна- чает, что консорциум ISC использует несколько главных серверов — какой-то из них должен реализовать передачу зоны подчиненным серверам.
668 Часть II. Работа в сети 17.11. Программное обеспечение NSD/Unbound Завершив рассмотрение системы BIND, перейдем к описанию альтернативной реа- лизации сервера DNS, обладающей, наряду с высокой производительностью, еще рядом прекрасных свойств. Система NSD (Name Server Daemon) была разработана организа- цией NLnet Labs в 2003 году. Изначально цель проекта заключалась в том, чтобы раз- работать альтернативную реализацию сервера, независимую от системы BIND, которую можно было бы использовать на корневых серверах, обеспечивая более высокую устой- чивость корневой зоны за счет разнообразия программного обеспечения. В настоящее время систему NSD используют три корневых сервера и несколько доменов верхнего уровня, но вам не обязательно управлять корневым сервером или доменом TLD, чтобы оценить надежность, производительность и простоту этой реализации. Ядро пакета NSD образуют две программы: zonec (прекомпилятор зонных файлов, преобразующий текстовые зонные файлы системы DNS в базу данных) и nsd (собствен- но демон сервера имен). Сервер NSD заранее вычисляет и индексирует все возможные ответы на корректные запросы, которые он может получить, поэтому, в отличие от си- стемы BIND, создающей эти ответы на лету, система NSD уже имеет эти ответы в ис- ходящем пакете в единственном экземпляре, хранящемся в памяти, что делает ее по- разительно быстрой. Unbound — рекурсивный сервер DNS, дополняющий систему NSD. Он был разрабо- тан на языке С организацией NLnet Labs на основе реализации, выполненной на языке Java компаниями VeriSign, Nominet, Kirei и EP.NET. Сочетание систем NSD и Unbound создает гибкую, высокопроизводительную и безопасную DNS-службу, подходящую для большинства организаций. Компоненты, разработанные организацией NLnet Labs, не такие зрелые, как система BIND, и не имеют так много “прибамбасов”, но для боль- шинства сайтов они могут стать прекрасным решением. Библиотека стандартных программ Idns, упрощающая написание инструментов для программного обеспечения DNS, также доступна для использования в дистрибутивных пакетах NSD и Unbound. Она содержит каталог примеров: несколько инструментов пред- назначены, в основном, для спецификаций DNSSEC, в частности программа для созда- ния подписи DNSSEC и утилита drill, предназначенная для отладки и аналогичная ути- лите dig из пакета BIND. Все эти программы можно загрузить с сайта nlnetlabs.nl..' Организация NLnet Labs также создала инструмент под названием Autotrust, обеспечи-^ вающий управление ключом RFC5011 и продление его срока действия. Эта программа^ интегрирована в систему Unbound, однако мы ее описывать не будем. S Код DNSSEC в системе NSD/Unbound более надежен и лучше протестирован, че>$ аналогичный код в системе BIND. Кроме того, он быстрее работает. Например, системам Unbound примерно в пять раз быстрее, чем система BIND, проверяет подписи DNSSEC,^ Тем не менее в некоторых аспектах, особенно что касается документации и дополни-; тельных функциональных возможностей, система BIND по-прежнему занимает лиди- рующие позиции. Для того чтобы обеспечить действительно устойчивую систему DNS, лучше запустить оба сервера! Инсталляция и конфигурирование системы NSD Вначале создайте пользователя с именем nsd в системе, в которой будет выполняться сервер имен nsd. Затем зарегистрируйте его как nsd, загрузите пакеты NSD/Unbound (в настоящее время их три: NSD, Unbound и отдельная библиотека Idns) и распакуйте
Глава 17. Система доменных имен 669 их. Для того чтобы инсталлировать демон nsd, следуйте инструкциям, написанным в файле doc/README. $ ./configure $ make $ sudo make install В табл. 17.10 перечислены каталоги, в которые система NSD инсталлируется по умолчанию. Таблица 17.10. Каталоги для инсталляции системы NSD 7^' Выполняемые файлы Пример файла конфигурации Справочные страницы Текстовые зонные файлы Скомпилированные зонные файлы Файлы PID /usr/local/sbin /etc/nsd /usr/local/share /etc/nsd /var/db/nsd /var/run Иногда размещать зонные файлы в каталоге etc довольно неудобно, особенно если зона большая. В таком случае следует выбрать другое место, например каталог /usr /local или /var. Если вас не устраивает выбор системы NSD, предусмотренный по умолчанию, вы можете использовать команду configure; сборочный файл можно про- читать без проблем. Результаты, возвращаемые командой configure, записываются в файл config.log в каталоге инсталляции, поэтому при необходимости его можно проанализировать. Пакет NSD инсталлирует семь программ. • nsd — демон сервера имен • nsdc — сценарий, управляющий демоном nsd, посылая ему сигналы • zonec — преобразовывает текстовые зонные файлы в файлы базы данных • nsd-notify — посылает уведомления (исключен) • nsd-xf er — получает передачи зоны (исключен) • nsd-checkconf — проверяет синтаксис файла nsd. conf • nsd-patch — отражает постепенные обновления базы данных в зонных файлах Фундаментальные отличия от системы BIND Если вы использовали систему BIND, то кое-что в системе NSD сначала покажется вам странным. Например, в ней нет файлов корневых подсказок и нет необходимости включать зоны локальных узлов. Кроме того, система NSD не поддерживает представ- ления, поэтому если ваша организация публикует разные варианты данных DNS внутри и вне, то вам придется вернуться к системе BIND или использовать несколько экзем- пляров демона nsd. Динамические обновления также не поддерживаются. Поскольку nsd — это сервер, который может быть только авторитетным, многие возможности си- стемы BIND для него недоступны. Система BIND считывает зонные файлы и хранит их в памяти; система NSD заранее компилирует зонные файлы в формат базы данных и использует для ее хранения и па- мять, и диск.
670 Часть II. Работа в сети Язык описания конфигурации демона nsd проще, чем в системе BIND. В нем нет точек с запятой, которые можно забыть, нет фигурных скобок для объединения групп и есть только три инструкции верхнего уровня: server, zone и key. Комментарии отме- чаются символом #. Параметры каждой из трех инструкций имеют следующий вид. атрибут: значение Инструкция server может существовать только в одном экземпляре. Она задает гло- бальные параметры. Инструкция zone перечисляет параметры зон, а инструкция key определяет криптографические ключи, необходимые для взаимодействия между глав- ным и подчиненными серверами, а также для управления демоном nsd. Пробелы отде- ляют атрибуты от значений. Значения можно взять в кавычки, но это необязательно. Как и система BIND, демон nsd обобщает IP-адреса, но несколько иначе, чем си- стема BIND, использующая список соответствий адресов. Этот список в системе NSD называется ip-spec и может выглядеть следующим образом. • Обычный IP-адрес (IPv4 или IPv6). • Подсеть в системе обозначений CIDR, например 1.2.3.0/24. • Подсеть с явной маской, например 1.2.3.4&255.255.255.0. • Диапазон IP-адресов, например 1/2/3/4-1.2.3.25. В каждой из этих форм пробелы не допускаются.. Еще одним основным отличием является использование значений ключа для ау- тентификации передачи зон и уведомлений. В системе BIND ключ ассоциируется с 1Р^ адресом, и сообщения, поступающие из этого адреса и на этот адрес, подписываются И проверяются с помощью этого ключа. В системе NSD принята более точная классифи^ кация ключей, и демон nsd может использовать один ключ для уведомлений, другой для передачи обновлений зоны, а третий — для получения этих обновлений. Полезно? Ну, как сказать... Семантика команды notify демона nsd аналогична разделу notify explicit в си- стеме BIND: уведомление отправляется только серверам, которые включены в список^ (По умолчанию система BIND уведомляет все серверы имен, указанные в зонном файле целевого домена.) Демон nsd предпочитает осмысленное описание поведения по умолчанию с по- мощью конфигурации. Например, спецификации DNSSEC включаются по умолчаний для подписанных зон и выключаются для неподписанных. По умолчанию демон nsd прослушивает сокеты как по протоколу IPv4, так и по протоколу IPv6. Регистрация либо включена, либо выключена и не предусматривает бесчисленное количество ка- тегорий и градаций, как это принято в парадигме BIND. Для взаимодействия межд$ серверами (передачи зон, уведомлений и т.д.) демон nsd использует протокол TSIG. Краткое описание различий между системами BIND и NSD, а также пример кон* фигурации содержатся в файле doc/NSD-FOR-BIND-USERS. Справочная страница для файла конфигурации nsd. conf и файл doc/README также содержат примеры, но, к со- жалению, они не согласованы друг с другом.22 Пример конфигурации системы NSD Мы приобрели несколько образовательных лицензий и объединили три примера и: дистрибутивов и добавили собственные комментарии, чтобы читатели могли получил 22 Для того чтобы открыть справочную страницу, не инсталлируя ее, следует выполнить коман ду groff -man -Т ascii имя-файла-справочной-страницы | less.
Глава 17. Система доменных имен 671 представление о конфигурации системы NSD еще до того, как мы приступим к деталь- ному разбору разных параметров. Рассмотрим демон nsd, сконфигурированный для главного сервера домена atmst.com и подчиненного сервера домена admin.com. server: username: nsd # Пользователь nsd должен быть запущен # после выполнения операции chroot database: /var/db/nsd/nsd.db # Заранее скомпилированный # файл базы данных logfile: /var/log/nsd.log # Системный журнал, по умолчанию # направляется в потоки stderr и syslog pidfile: /var/run/nsd.pid # Идентификатор процесса nsd key: name: tsig.atrust.com. # Ключ для передачи зоны atrust..сот algorithm: hmac-md5 secret: "здесь содержится пароль, зашифрованный по методу base64" zone: name: atrust.com # Имя зоны zonefile: /var/nsd/primary/atrust.сот provide-xfr: 1.2.3.4 tsig.atrust.com. # Адрес подчиненного сервера # зоны atrust.com notify: 1.2.3.4 tsig.atrust.com # и ключ для уведомления или # xfr-файлов. provide-xfr: 1.2.30.40 tsig.atrust.com. # Адрес другого подчиненного # сервера notify: 1.2.30.40 tsig.atrust.com # и ключ для уведомления или # xfr-файлов. key: пате: tsig.admin.com. # Ключ для получения данных от # admin.com подчиненным сервером algorithm: hmac-md5 secret: "здесь содержится пароль, зашифрованный по методу base64" zone: name: admin.com # Зона, по отношению к которой # данный сервер является # подчиненным zonefile: "/var/nsd/secondary/admin.com.signed" allow-notify: 5.6.7.8 NOKEY # Ее главная зона request-xfr: 5.6.7.8 tsig.admin.com. # и ключ для xfr-файлов В этом примере файла nsd.conf описана конфигурация сервера, который является главным для зоны atrast.com и осуществляет уведомление и передачу зоны двум под- чиненным серверам, имеющим IP-адреса 1.2.3.4 и 1.2.30.40. Для аутентификации двух подчиненных серверов при передаче зон и уведомлении этот сервер использует ключ TSIG с именем tsig.atrust.com. (Вы можете и, возможно, даже обязаны использовать для каждого подчиненного сервера отдельный ключ.) Этот сервер также является подчиненным сервером для зоны admin. com, главный сервер которой имеет IP-адрес 5.6.7.8. Мы можем получать уведомления об изменении Данных зоны без ключа, но при передаче зоны обязаны использовать ключ tsig.admin.com. Главные зоны имеют разделы provide-xfr, а подчиненные — раздел request-xfr. После инсталлирования демона nsd и оформления файла конфигурации, для про- верки синтаксиса файлов конфигурации следует применить команду nsd-checkconf. Его отчеты об ошибках довольно лаконичны, например “error: syntax error” и номер строки. Исправив ошибки, выявленные командой nsd-checkconf, выполните ее еще
672 Часть II. Работа в сети раз и повторяйте этот процесс, пока команда nsd-checkconf не перестанет выдавать сообщения об ошибках. Определения ключа NSD Раздел key определяет именной ключ, который можно использовать для последую- щего доступа к параметрам управления. Каждый ключ имеет три атрибута: имя, алгоритм и разделенный секрет (т.е. пароль). Посмотрим, как разместить определение ключа или, по крайней мере, его разделенный секрет в файлах, доступ к которым ограничен. Для их импорта в файл nsd.conf можем использовать инструкцию include. Достаточно про- сто поместить в файл строку include: имя_файла в то место, куда мы хотим вставить текст из файла с именем имя_файла. Ш Определения ключа Синтаксис инструкции key выглядит следующим образом. name: имя_ключа algorithm: название_алгоритма secret: пароль в кодировке base64 Допускается несколько инструкций key. Поле name идентифицирует ключ. Выбирайте имена, идентифицирующие зону и серверы, участвующие в обменах секретной информацией. Можно использовать алго- ритмы hmac-md5, hmac-shal или hmac-sha256. Можно также сгенерировать ключи TSIG с помощью команды Idns-keygen, несмотря на то что на самом деле она предна- значена для генерирования пар закрытых и открытых ключей DNSSEC. Для получения списка алгоритмов можно выполнить команду Idns-keygen -a list. Рассмотрим пример использования алгоритма hmac-shal. $ Idns-keygen -a hmac-shal example.com Эта команда создает файл с именем Kexample. com. +158+12345. key, содержащий ключ TSIG. Достаточно просто вырезать и скопировать секретную часть в вашу специ- фйкацию ключа. Число 158 в имени файла означает алгоритм hmac-shal. Для алгорит- ма hmac-md5 зарезервировано число 157, а для алгоритма hmac-sha256 — 159. Число 12345 — это просто заполнитель для случайного пятизначного дескриптора ключа. При использовании нескольких ключей эти дескрипторы помогают правильно с ними обхо- диться. Глобальные параметры конфигурации NSD Параметры NSD подразделяются на две группы: глобальные параметры сервера и зонные параметры, которые можно применить к любой зоне, обслуживаемой конкрет- ным экземпляром демона nsd. Некоторые параметры можно заменять с помощью фла- гов командной строки при запуске демона nsd. Параметры сервера обычно имеют разумные значения, установленные по умолчанию, и требуют внимания, только если ваша структура каталогов отличается от стандартной или вы хотите сделать нечто необычное. Ниже мы приводим значения по умолчанию в квадратных скобках. Как и для параметров системы BIND, мы добавили примечания, описывающие каждую группу параметров, чтобы в них было легче разобраться. 03 Включение файла include: имя_файла
Глава 17. Система доменных имен 673 Директива include: может находиться в любом месте файла конфигурации. Файл с именем имя_файла считывается в файл конфигурации, и его содержимое заменяет ди- рективу. [все 1Р_адреса] [по] [по] [53] CQ IP-адреса и порт ip-address: 1р_адрес ip4-only: yes | по ip6-only: yes | по port: номер_порта По умолчанию система NSD связывает порт 53 со всеми сетевыми интерфейсами как по протоколу IPv4, так и по протоколу IPv6. При перечислении адресов с помощью ди- рективы ip-address: демон nsd обходит таблицы маршрутизации ядра и гарантирует, что на запрос к одному из IP-адресов не будет выдан ответ от другого IP-адреса; этого требуют многие процедуры разрешения имен. Если ваш компьютер Имеет только один сетевой интерфейс, то этот параметр бесполезен. Параметры ip4-only и ip6-only ограничивают демон nsd определенным протоколом, а параметр port устанавливает се- тевой порт, прослушивающий входящие запросы. CQ Идентификаторы Как правило, эти параметры не используются, потому что их значения по умолча- нию подобраны очень удачно. identity: строка [имя_узла] hide-version: yes | по [по] Эта пара параметров определяет, сообщать ли демону nsd правду о его версии и име- ни узла в ответ на запросы для имен классов CHAOS id. server и version. server. Как указывалось выше, мы рекомендуем не изменять эти значения. CQ Протоколирование, статистические показатели logfile: имя_файла verbosity: уровень debug-mode: yes | по statistics: #сек [stderr и stdlog] [0] [по] [0] # без статистических показателей Протоколирование по умолчанию осуществляется в стандартном потоке ошибок и системном журнале (функциональная возможность демона), причем объем протоколи- рования определяется параметром verbosity. Диапазон возможных значений варьиру- ется от 0 до 5; большие значения означают, что следует регистрировать больше данных. Параметр logfile направляет протокольные сообщения в файл, а не в стандартный си- стемный журнал. Если задан параметр debug-mode, то демон nsd не создает дополнительные копии самого себя и остается присоединенным к вашему терминалу, так что вы можете видеть сообщения, посланные в стандартный поток ошибок. Если вы хотите накапливать статистические показатели, то установите параметр #сек равным количеству секунд между сбросами информации. Статистические пока- затели похожи на другие протокольные сообщения, поэтому они направляются в файл регистрации или системный журнал, если не задан другой конкретный файл. Лучше все- го иногда просматривать статистические данные, чтобы убедиться в том, что интервал между сбросами информации выбран правильно и вы не перегружаете диски информа- цией, которую никто никогда не увидит. S3 Имена файлов
674 Часть II. Работа в сети database: difffile: xfrdfile: pid-file: zonesdir: имя_файла имя_файла имя_файла имя_файла каталог [/var/db/nsd/nsd.db] [/var/db/nsd/ifxr.db] [/var/db/nsd/xfrd.state] [/зависит от ОС, обычно /var/run/nsd.pid] [/etc/nsd] Скомпилированные зонные файлы и информация о передаче зоны обычно хранятся в каталоге /var/db/nsd; эта установка изменяется очень редко. Файл PID должен нахо- диться там, куда ваша операционная система записывает остальные файлы PID, обычно в каталоге /var/run. По умолчанию зонные файлы, редактируемые людьми, находятся в каталоге /etc/nsd, что кажется неудачным решением. Посмотрим, как переместить эти файлы в подкаталоги каталога /var, например в каталог /var/nsd/zones. Ш Настройка tcp-count: целое_число [0] server-count: целое_число [1] xfrd-reload-timeout: #сек [10] Параметр tcp-count ограничивает количество одновременных TCP-соединений, ко- торые сервер может использовать для передачи зоны. Если вы увидите сообщение “xfrd: max number of ТС connections (10) reached” в системном журнале, значит, вы превысили максимально допустимое значение. Если это происходит часто, вы должны увеличить этот предел. Параметр server-count задает количество запускаемых экземпляров демона nsd. При работе на многопроцессорных компьютерах у системного администратора может возникнуть желание увеличить это значение. Параметр xfrd-reload-timeout регу- лирует перезагрузку после передачи зоны, задавая количество секунд, которое должно пройти после предыдущей загрузки прежде, чем можно будет выполнить новую. Ш Безопасность username: регистрационное_имя [nsd] chroot: каталог [нет] Демон nsd должен запускаться как корневой процесс, чтобы открыть привилегиро- ванный сокет (порт 53), но потом он может потерять привилегии и вернуться на уровень обычного пользователя, поскольку все файлы, которые ему нужны, принадлежать дан- ному пользователю. Следовательно, демон nsd должен иметь учетную запись. Для того чтобы повысить безопасность, мы можем также запустить демон nsd в вир- туальном окружении, используя команду chroot, поскольку зонные файлы, файлы баз данных, файлы xfrdfile, difffile и PID, а также сокет системного журнала (или ре- гистрационный файл) доступны через виртуальный каталог. Зонные параметры конфигурации NSD В отличие от глобальных параметров, зонные параметры обычно требуют опреде- ленного конфигурирования, особенно это относится к спискам управления доступом (ACL — access control list). Ш Определения зон name: имя_зоны zonefile: имя_файла Зона определяется своим именем и файлом записей о ресурсах. Ш Главные ACL-серверы
Глава 17. Система доменных имен 675 notify: ip-адрес ( имя-ключа | NOKEY )23 provide-xfr: ip-спецификация ( имя-ключа | NOKEY | BLOCKED) Главный сервер для зоны уведомляет свои подчиненные серверы об обновлении зоны. Затем, по запросам подчиненных серверов, он инициирует передачу зоны для пересылки модифицированных данных. Следовательно, зона, по отношению к кото- рой сервер является главным, должна быть указана в списках notify и provide-xfr. Значения этих параметров обычно совпадают. Если не указан параметр NOKEY, то уве- домления подписываются ключом, указанным в списке как имя_ключа. Следует помнить, что, в отличие от демона named, демон nsd не уведомляет подчи- ненные серверы зоны автоматически. Вы должны явно указать их в списках notify и provide-xfr. Эти директивы могут повторяться. Ш Подчиненные ACL-серверы allow-notify: ip-адрес ( имя-ключа | NOKEY | BLOCKED)24 request-xfr: [ AXFR | UDP] ip-адреса ( имя-ключа | NOKEY) Подчиненный сервер зоны должен явно разрешить главному серверу посылать уве- домления. Любые сообщения, полученные от серверов, не перечисленных в списке allow-notify (или помеченных как BLOCKED), игнорируются. Раздел request-xfr создает запрос подчиненного сервера на передачу зоны от главного сервера по указанному в списке ip-adpecy с помощью заданного ключа с име- нем имя_ключа. Если аргумент AXFR включен, то запрашиваться будут только AXFR- передачи (т.е. передачи всей зоны, в отличие от постепенных изменений). Аргумент udp указывает, что запрос на передачу зоны должен быть послан с помощью UDP- транспорта, а не протокола TCP, заданного по умолчанию. Лучше всего все же исполь- зовать протокол TCP. Ш IP-адрес источника outgouing-interface: ip-адрес Эти списки управляют IP-адресами, используемыми подчиненными серверами для запроса на передачу зоны или главным сервером для посылки уведомлений. Эти адре- са должны совпадать, иначе говоря, раздел управления доступом в конфигурации зоны главного сервера должен содержать те же адреса, что и соответствующий раздел в кон- фигурации зоны подчиненного сервера. Запуск демона nsd Задав конфигурацию демона nsd, запустите программу nsd-checkconf, чтобы убе- диться, что в вашем файле конфигурации nsd. conf нет синтаксических ошибок. Затем поместите ваши зонные файлы в соответствующий каталог (заданный в файле nsd. conf) и используйте управляющий сценарий nsdc, чтобы скомпилировать их в файлы базы данных. В заключение запустите сервер имен с помощью сценария nsdc. $ sudo nsdc rebuild $ sudo dsdc start Проверьте сервер имен с помощью команд dig или drill. Если результаты вас удовлетворяют, добавьте в последовательность загрузки вашей операционной системы команду nsdc start, а в ее последовательность завершения работы — команду nsdc 23 Здесь и в следующей строке скобки использованы лишь для того, чтобы показать группиро- вание; на самом деле их использовать не надо. 24 См. предыдущую сноску.
676 Часть II. Работа в сети stop. Вы можете также настроить файл-расписание для службы Сгоп, чтобы раз в день выполнять команду ns cd patch для обновления текстовых зонных файлов на основе файлов базы данных. Инсталляция и конфигурирование сервера Unbound Unbound — это рекурсивный, кеширующий DNS-сервер имен, выполняющий авто- ризацию. Его разработчиком является та же самая организация, которая создала сервер NDS (NLnet Labs). Сначала он был предназначен для систем UNIX и Linux, но в настоя- щее время доступен и для системы Windows. Для того чтобы инсталлировать его, создайте нового пользователя с именем “unbound”, зарегистрируйте его как пользователя и загрузите дистрибутивный пакет с адреса unbound.net. Сервер Unbound требует наличия библиотек Idns и OpenSSL и может использовать библиотеку libevent (monkey.org/~provos/libevent), если она доступна. Как и сервер NSD, сервер Unbound сначала должен запускаться как кор- невой, а затем возвращаться на уровень пользователя со специальной учетной записью. Для того чтобы создать сервер Unbound, следует выполнить следующие команды. $ ./configure $ make $ sudo make install Сервер Unbound сопровождается обширным пакетом тестов, которые можно запу- стить командой make test. Дистрибутивный пакет инсталлирует следующие выполняе- мые файлы. • unbound — рекурсивный сервер имен. • unbound-checkconf — инструмент для проверки синтаксиса файла unbound, conf. • unbound-control, unbound-control-setup - инструменты для удаленного управления безопасностью. • unbound-host — простой инструмент для запросов. Команда unbound-host не является такой же многословной, как команды dig и drill. В табл. 17.11 перечислены каталоги, в которые размещаются компоненты системы Unbound. Таблица 17.11. Каталоги для инсталляции системы Unbound : ' -1’ '-..у-.-. 1 " IL 1 1 Выполняемые файлы Библиотеки Файл конфигурации Справочные страницы Механизм виртуализации Файлы PID /usr/local/sbin /usr/local/lib /etc/local/etc/unbound/unbound.conf /usr/local/share /usr/local/etc/unbound /usr/local/etc/unbound Файл конфигурации сервера unbound под названием unbound, conf похож на файл конфигурации сервера nsd. Его синтаксис выглядит следующим образом. атрибут-, значение
Глава 17. Система доменных имен 677 Комментарии начинаются символом # и продолжаются до конца строки. Для провер- ки корректности файла конфигурации можно выполнить команду unbiund-checkconf. Рассмотрим простой пример файла unbound, conf, адаптированный по сравнению со справочной страницей и содержащий несколько дополнительных комментариев. server: directory: "/var/unbound/etc" username: unbound chroot: "/var/unbound" pidfile: "/var/run/unbound.pid" root-hints: "root.cache" interface: 0.0.0.0 # interface: ::0 # access-control: 10.0.0.0/8 allow # access-control: 2001:DB8::/64 allow # # # # Прослушивает все интерфейсы IPv4 и все интерфейсы IPv6 Локальные частные сети Локальные сети IPv6 В этом примере сервер прослушивает все интерфейсы и допускает все запросы» по- ступающие от локальных 1Ру6-сетей и немаршрутизированных частных сетей 10. Он ре- гистрируется в системном журнале с помощью функциональных возможностей демона (по умолчанию) и запускается в виртуальном окружении, созданном командой chroot от имени пользователя unbound. Поскольку сервер unbound является рекурсивным, он имеет много параметров. Их количество (больше 70) составляет примерно половину количества параметров серве- ра BIND (больше 150). Мы опишем лишь некоторые из них. Полный обзор параме- тров можно найти в справочной системе и в документации, расположенной на сайте unbound.net. Язык конфигурации сервера unbound предусматривает четыре директивы высшего уровня: server, remote-control, stub-zone и forward-zone.25 Глобальные параме- тры находятся в разделе server. Рассмотрим наиболее важные из них. Ш Местоположение directory: каталог [/usr/local/etc/unbound] pidfile: имя_файла [/usr/local/etc/unbound/unbound.pid] root-hints: имя_файла [нет] Параметр directory задает рабочий каталог сервера: по умолчанию сервер unbound устанавливается в каталог /usr/local/etc, но многие организации предпочитают ката- лог /var. Файлы PID по умолчанию записываются в рабочий каталог сервера unbound, но их можно поместить и в более традиционные места, например в каталог /var/run. Корневые подсказки встраиваются в код сервера unbound, поэтому файл подсказок не нужен. Однако его можно создать, если вы хотите, поскольку адреса, записанные в коде, в конце концов могут устареть. Если вы хотите иногда получать свежие копии сер- вера, используйте команду dig . ns. Если же вы страдаете паранойей, попытайтесь вы- полнить команду dig@a. root-server. net . ns, чтобы получить авторитетную копию. Ш Протоколирование use-syslog: yes | no [yes] logfile: имя_файла [нет] log-time-ascii: yes I по [по] verbosity: уровень [1] 25 Он напоминает язык сценариев Python.
678 Часть II. Работа в сети Протокольная информация может поступать либо в системный журнал, либо в файл. Это зависит от параметров use-syslog и logfile. Если вы хотите знать обычное вре- мя, а не время UNIX (т.е. количество секунд, прошедших после 1 января 1970 года), включите параметр log-time-ascii. Параметр verbosity определяет объем протоко- лирования (детали описаны в разделе 17.15). Ш Статистические показатели statistics-interval: секунд [0, т.е. отключена] statistics-cumulative: yes | по [по] extended-statistics: yes | по [по] Накопление статистических данных по умолчанию отключено, потому что они за- медляют работу сервера имен. Если вы включите этот режим, установив ненулевое зна- чение параметра statistics-interval, то статистические данные будут записываться в протокольный файл (или системный журнал) через указанные промежутки времени. По умолчанию счетчики статистических показателей каждый раз при их записи в файл обнуляются; для того чтобы этого не происходило, используйте параметр statistics- cumulative. Установив параметр extended-statistics равным yes, вы сгенерируете больше данных, чем сможете записать в файл с помощью команды unbound-control. EQ Более подробная информация об утилитах Cacti и RRDTool приведена в разделе 21.12. Каталог дистрибутивов contrib содержит надстройки, которые соединяют утилиты Cacti или Munin с работающим сервером имен и выводят графическую информацию о статистических данных с помощью утилиты RRDTool. Подробности можно найти на сайте unbound.net. EQ Разрешение запросов access-control: блок_сети действие [разрешает любой локальный узел] Параметр access-control — это ключ для конфигурации сервера имен в рекур- сивном режиме по отношению к своим собственным пользователям, но не для ос- тальных пользователей. Для того чтобы разрешить несколько интерфейсов, следует использовать несколько разделов allow-control. Параметр действие может прини- мать четыре значения: • deny — блокирует все запросы от указанных сети или узла; • refuse — блокирует запросы и посылает обратно сообщение REFUSED; • allow — отвечает на запросы, поступившие от клиентов, требующих рекурсивной обработки; • allow-snoop — отвечает на запросы от рекурсивных и итеративных клиентов. Действие refuse более точно соответствует спецификации системы DNS, чем дей- ствие deny, потому что клиенты предполагают, что запросы, не получившие ответа, были потеряны в сети, а не отклонены по решению администратора. Действие allow применяется к обычным клиентам системы DNS. Параметр allow-snoop позволяет отвечать не только на итеративные, но и на ре- курсивные запросы. Его можно использовать для того, чтобы исследовать содержимое кеша сервера, поскольку итеративный запрос достигает цели, только если ответ уже на- ходится в кеше. Параметр allow-snoop можно также использовать для злонамеренных действий, поэтому на узлах системного администратора его следует ограничивать. EQ Безопасность
Глава 17. Система доменных имен 679 chroot: каталог [/usr/local/etc/unbound] username: имя [unbound] Параметр username задает непривилегированного пользователя, под именем кото- рого должен запускаться сервер unbound, после завершения процесса загрузки. Директива chroot заставляет сервер unbound выполняться в виртуальном окруже- нии. Для того чтобы убедиться, что серверу unbound доступно все, что ему нужно из его виртуального окружения, приходится преодолеть несколько препятствий, но в послед- них версиях код стал намного проще. Код очень аккуратно отображает глобальные пути в виртуальное окружение, создан- ное командой chroot (chrooted jail). Большинство путей можно задать в виде абсолют- ных глобальных путей, абсолютных путей в виртуальном каталоге или относительных путей по отношению к рабочему каталогу. Сервер unbound при необходимости выпол- няет соответствующее преобразование. Отметим несколько важных моментов, касающихся запуска сервера unbound в вирту- альной среде. Считывание файла конфигурации, разумеется, предшествует выполнению команды chroot, поэтому файл конфигурации, заданный командной строкой сервера unbound, должен быть задан глобальным путем. Файл PID, содержащий ключ unbound- control, и сокет системного журнала остаются за пределами виртуального каталога, по- скольку они открываются до того, как сервер unbound выполнит команду chroot. Сервер unbound считывает псевдоустройство /dev/random до выполнения команды chroot, но мы рекомендуем оставить его открытым и после выполнения этой команды. Дело в том, что сервер unbound может обратиться к нему позднее, чтобы получить дру- гие случайные данные. Если сервер unbound не может открыть псевдоустройство /dev/ random, он использует источник случайных чисел, заданный по умолчанию, и регистри- рует предупреждение. ДВ системе Linux можно сделать псевдоустройство /dev/random доступным в виртуальной среде, выполнив следующую манипуляцию (предполагается, что файл /var/unbound находится в виртуальном каталоге). linux$ sudo mount -bind -n /dev/random /var/unbound/dev/random Ш Идентификаторы Следующие параметры определяют, сообщать ли серверу unbound правду о номере своей версии и имени узла при запросе имен CHAOS id. server и version. server. hide-identity: yes | no [no] identity: строка [имя_узла] hide-version: yes | no [no] version: строка [версия сервера имен] Как указывалось в начале раздела, мы рекомендуем не скрывать эти значения. Ш IP-адреса interface: ip-адрес [локальныи_узел] outgoing-port-avoid: число или диапазон [нет] Сервер unbound имеет несколько параметров, управляющих интерфейсами, кото- рые он прослушивает в ожидании запросов, и номерами портов, используемых для по- лучения и отправки запросов. Для большинства организаций настройки по умолчанию вполне приемлемы и не уязвимы для атак на кеш, изобретенных Камински. Однако па- раметры interface и outgoing-port-avoid должны конфигурироваться явно.
680 Часть II. Работа в сети Параметр interface задает интерфейсы, которые сервер unbound прослушивает в ожидании запросов. Его необходимо задавать явно, поскольку по умолчанию задан ло- кальный узел, что вполне удовлетворительно, если сервер unbound выполняется на каж- дой машине, но неприемлемо, если в каждой подсети или на каждом сайте должен быть один сервер имен. Добавьте инструкцию interface для каждого интерфейса, которому клиенты могут послать запрос. Необходимо также задать конфигурацию outgoing-port-avoid, чтобы исключить все порты, блокируемые вашим брандмауэром и используемые другой программой. Сервер unbound уже исключил порты, номера которых меньше 1024, и порты, назна- ченные организацией IANA. Ш Спецификации DNSSEC module-config: имена_модулей [нет] trust-anchor-file: имя_файла [нет] trust-anchor: запись_о_ресурсах [нет] trusted-keys-file: имя_файла [нет] dlv-anchor-file: имя_файла [нет] dlv-anchor: записъ_о_ресурсах [нет] Все эти параметры относятся к процессу развертывания спецификаций DNSSEC; они позволяют задать точки доверия, указав файлы, в которых они находятся, или поме- стив запись о ресурсах непосредственно в значение параметра. Допускается только одна выделенная точка доверия DLV. Установив параметр module-config равным validator iterator, можно вклю- чить проверку спецификаций DNSSEC. Это значение должно сопровождаться точками доверия, которые должны быть либо явно сконфигурированы, либо выделены. Более подробно спецификации DNSSEC обсуждаются в разделе 17.13. CQ Подписи val-* <разное> [параметры подписи, приемлемые по умолчанию] Ряд параметров val-* регламентирует процесс проверки подписи подписанных зон. На процесс проверки могут влиять разные факторы (например, максимально допус- тимое отклонение временных показателей). Значения, установленные по умолчанию, вполне приемлемы, если вы не хотите заняться отладкой процесса развертывания спец- ификаций DNSSEC. Задав параметр val-log-level равным 1, можно отключить про- верку системного журнала, что при отладке бывает полезным. Ш Настройка Сервер unbound имеет несколько параметров, позволяющих настраивать его работу. Одним из самых важных является параметр num-threads, который должен быть рав- ным количеству ядер, доступных серверу (т.е. количеству ядер на один процессор, умно- женному на количество процессоров). Значения параметров настроек, заданные по умолчанию, вполне подходят для боль- шинства организаций. Мы не будем их перечислять, поскольку читатели могут обра- титься к справочной странице для файла unbound, conf и интернет-странице unbound, net. В конце справочной страницы есть полезный пример, демонстрирующий настрой- ку производительности компьютера с небольшим объемом памяти. Ш Частные адреса private-address: 1р_адрес_или_подсеть [нет] private-domain: имя_домена [нет]
Глава 17. Система доменных имен 681 Инструкция private-address блокирует указанные в списке IP-адреса, не позволяя отправлять им ответы на запросы. Обычно она используется в сочетании с простран- ством частных IP-адресов RFC1918 (см. раздел 14.4), чтобы не допустить их разглаше- ние в Интернете. Это типичное поведение внешних организаций, но если вы на самом деле используете частные адреса RFC1918 внутри организации, то, вероятно, не захо- тите блокировать свои собственные внутренние адреса. Инструкция private-domain разрешает этот конфликт, позволяя указанному домену и всем его поддоменам иметь частные адреса. Следующий набор параметров конфигурации относится к инструкции remote- control, управляющей взаимодействием между программами unbound и unbound- control. Это взаимодействие управляется самоподписанными сертификатами SSL/TLS в формате Х.509, установленными программой unbound-control-setup. Эта инструк- ция имеет всего несколько параметров, поэтому мы перечислим их всех. CQ Управление работой программы unbound control-enable: yes | no control-interface: ip-адрес control-port: порт server-key-file: файл_закрытого_ключа server-cert-file: файл_сертификата_реш control-key-file: файл_закрытого_ключа control-cert-file: файл_сертификата_рет [no] [локальный узел (127.0.0.1 и ::1)] [953] [unbound_server.key] [unbound_server .pern] [unbound_control.key] [unbound_control.pem] Управлять программой unbound можно из любой точки Интернета. Для того чтобы настроить аутентификацию, запустите программу unbound-control, чтобы создать со- ответствующие файлы сертификатов, установите параметр control-enable равным yes и параметр control-interface равным адресу интерфейса, который сервер будет прослушивать в ожидании команд. Для того чтобы разрешить все интерфейсы, можно использовать адрес 0.0.0.0 (и : : 0). По умолчанию требуется, чтобы контроллер был зарегистрирован на том же компьютере, что и программа unbound. Вероятно, это самый безопасный вариант. Ш Тупиковые зоны stub-zone: name: имя_домена [нет] stub-host: имя_узла [нет] stub-addr: 1р_адрес[@порт] [нет] Раздел stub-zone позволяет направлять запросы на конкретный домен, адресуя их авторитетному серверу, назначенному вами, а не разрешать их с помощью обычного иерархического поиска, начиная с корня. Например, вы можете пожелать, чтобы ваши пользователи видели закрытое представление вашей локальной сети, содержащее боль- ше узлов, чем демонстрируют запросы DNS, поступающие извне. Имя “stub zone” (“ту- пиковая зона”) является неудачным и не имеет отношения к тупиковым зонам, исполь- зуемым в сервере BIND. Для реализации этой конфигурации следует запустить авторитетный сервер, который будет обслуживать локальную версию зоны, на другом узле (или на том же самом узле, но на другом порту). Затем следует указать программе unbound этот сервер, используя параметры инструкции stub-zone. Вы можете задать либо имя_узла сервера (параметр stub-host), либо его IP-адрес (параметр stub-addr). Вы можете также указать порт, который по умолчанию имеет номер 53. Использование адреса защищает вас от заци-
682 Часть II. Работа в сети кливания в ситуациях, когда программа unbound не может найти имя, не имея доступ к целевой зоне. Можно использовать сколько угодно зон. £□ Переадресация forward-zone: name: имя_домена [нет] forward-host: имя_сервера [нет] forward-addr: ±р_адрес [нет] Параметр forward-zone позволяет серверу unbound переадресовывать все запросы (или некоторые из них, в зависимости от значения параметра name) на другой сервер, для того чтобы помочь этому серверу создать более крупный кеш. Переадресация вы- полняется, только если сервер unbound не может ответить на запрос, используя свой собственный кеш. Общая информация о переадресации и причинах ее использования приведена в разделе 17.6. 17.12. Обновление файлов зон Когда в домен вносится изменение (например, добавляется или удаляется компью- тер), следует обновить файлы данных на главном сервере. Кроме того, необходимо увели- чить порядковый номер в записи SOA для этой зоны. В заключение вы должны заставить программное обеспечение принять изменения. Последний этап зависит от программно- го обеспечения. • Сервер BIND. Выполните команду rndc reload, чтобы демон named принял из- менения. Вы можете также прекратить работу демона named и запустить его снова, но если ваш сервер является одновременно авторитетным по отношению к вашей зоне и рекурсивным по отношению к вашим пользователям, то эта операция ан- нулирует кешированные данные, полученные от других доменов. • Сервер NSD. Выполните команду nsdc rebuild, а затем команду nsdc reload. Сервер nsd не выполняет кеширование, поэтому никаких побочных эффектов от перезагрузки не будет. Обновленные данные немедленно передаются подчиненным серверам главных серве- ров BIND, поскольку параметр notify включен по умолчанию. При работе с сервером NSD необходимо конфигурировать списки управления доступом в разделе notify. Если же по какой-то причине он отключен, подчиненным серверам придется дождаться, пока истечет период обновления, установленный в записи SOA зоны (обычно один час). Если параметр notify отключен, можно выполнить на каждом подчиненном серве- ре BIND команду ndc reload, которая заставит демон связаться с главным сервером, убедиться в том, что зонная база данных изменена, и запросить ее пересылку. Соответ- ствующая команда сервера NSD — nsd reload. При изменении имени или IP-адреса компьютера не забывайте модифицировать зоны как прямого, так и обратного преобразований. Игнорирование последних может привести к появлению скрытых ошибок: часть команд будет работать, а часть — нет. Если изменить файлы данных, но не обновить порядковый номер в записи SOA, то изменения вступят в силу только на главном сервере (после перезагрузки), но не на под- чиненных. Не следует редактировать файлы данных, относящиеся к подчиненным серверам. Эти файлы ведет сам демон named, и системные администраторы не должны вмеши-
Глава 17. Система доменных имен 683 ваться в его работу. Лучше просматривать файлы данных сервера BIND, не делая в них никаких изменений. Сервер NSD ведет базы данных, которые невозможно проверить непосредственно. Однако по умолчанию изменения записываются в текстовые зонные файлы командой nsd-patch. Документом RFC2136 разрешается менять зонные базы данных сервера BIND про- граммным путем. Эта возможность, называемая динамическим обновлением, необхо- дима для протоколов автоматического конфигурирования, например DHCP. О том, как работает этот механизм, речь пойдет чуть ниже. Передача зоны Серверы DNS синхронизируются посредством механизма передачи зоны. Передача зоны может включать в себя всю зону (такая передача называется AXFR) или только по- следние изменения (такая передача именуется IXFR). По умолчанию передача зоны осу- ществляется по протоколу TCP через порт 53. Сервер BIND регистрирует соответству- ющую информацию в системном журнале с пометкой “xfer-in” или “xfer-out”. Сервер NSD включает ее в обычный протокольный поток. В процессе передачи зоны подчиненный сервер запрашивает информацию от главно- го сервера и создает резервную копию данных о зоне на диске. Если данные на главном сервере не изменились, что определяется по порядковым номерам (не по реальным дан- ным), то обновления не выполняются и резервные файлы просто фиксируются. (Иначе говоря, их время изменения устанавливается равным текущему времени.) И отправляющий, и получающий серверы способны отвечать на запросы при пере- даче зоны. Подчиненный сервер начинает использовать новые данные только после за- вершения передачи. Если зона очень большая (например, сот) или обновляется динамически (о чем пой- дет речь в следующем подразделе), то объем изменений обычно мал в сравнении с раз- мером зоны. При передаче IXFR пересылаются только изменения (когда размер изме- нений начинает превышать размер зоны, включается режим обычной передачи AXFR). Механизм IXFR напоминает программу patch: старая база данных сравнивается и син- хронизируется с новой. В системе BIND передача IXFR задается по умолчанию, а демон named, предна- значенный для ведения журнала транзакций, — именем имя_зоны. jnl. В инструкции server любого сервера, которому нужны такие передачи, можно задать параметры provide-ixf г и request-ixf г. Параметр proyide-ixfг включает и отключает службу IXFR для зон, по отношению к которым сервер является главным. Параметр request* ixf г включает и отключает службу IXFR для зон, по отношению к которым сервер яв- ляется подчиненным. provide-ixfr yes ; # В инструкции сервера BIND request-ixfr yes ; # В инструкции сервера BIND Механизм IXFR может работать и с зонами, редактируемыми вручную. Для того чтобы включить этот режим, следует включить параметр ixfr-from-difference. Механизм IXFR требует, чтобы зонные файлы были упорядочены в каноническом по- рядке. За это отвечает демон named, но при этом затрачивается определенная память сервера и ресурсы центрального процессора. Механизм IFXR компенсирует эти затраты за счет уменьшения сетевого трафика. При запросе передачи зоны подчиненные серверы NSD используют передачу IXFR, но если все главные серверы поддерживают передачу AXFR, то подчиненные серверы
684 Часть II. Работа в сети переключаются именно на этот режим. Поскольку данные в системе NSD хранятся в виде скомпилированных файлов базы.данных, упорядочение файлов для передачи IXFR не требуется. Если передача была прервана, то сервер NSD сохраняет состояние демона передачи зоны в файле, заданном атрибутом xf rdf ile. Перезагрузкой после выполнения передач IXFR можно управлять с помощью атри- бута xfrd-reload-timeout. По умолчанию он равен 10 секундам, так что изменения IXFR успевают в определенной степени сгруппироваться. В системе BIND запрос IXFR к серверу, который не поддерживает его автоматиче- ски, заменяется стандартной передачей зоны AXFR. В системе NSD эту замену можно запретить, установив атрибут allow-axfr-f allback равным no. Обе системы прилагают много сил для того, чтобы при сбое сервера во время пере- дачи зоны информация не была повреждена. динамические обновления в системе BIND Система DNS основана на предположении, что соответствие между именами и адресами относительно стабильно и меняется нечасто. Но это правило постоянно на- рушается, если в организации используется протокол DHCP и при подключении к сети компьютеру динамически назначается IP-адрес. Существует два классических решения этой проблемы: добавить обобщенные записи в базу данных DNS или непрерывно ре- дактировать DNS-файлы. В большинстве случаев ни одно из решений не является удо- влетворительным. Первое решение должно быть знакомо каждому, кто имеет коммутируемый выход в Интернет. Конфигурация DNS в этом случае выглядит примерно следующим образом. dhcp-hostl.domain. IN А 192.168.0.1 dhcp-host2.domain. IN A 192.168.0.2 Это простое решение, но оно означает, что указанные имена постоянно связаны с IP- адресами и, следовательно, компьютер, получающий новый адрес, меняет имя. В такой среде трудно соблюдать требования безопасности и вести журнальную регистрацию. Механизм динамических обновлений, появившийся в последних версиях BIND, предлагает альтернативное решение. Он позволяет демону DHCP уведомлять сервер BIND о сделанных адресных назначениях, обновляя, таким образом, содержимое базы данных DNS “на лету”. Динамические изменения могут добавлять, удалять и модифици- ровать запросы о ресурсах. Если динамические изменения дозволены, демон named ведет журнал динамических изменений (имя_зоны. jnl), который может оказаться полезным при сбое сервера. Демон named восстанавливает состояние зоны, сохраненное в памяти, считывая исходные зонные файлы и воспроизводя изменения на основе журнала. После того как зона была динамически обновлена, ее уже нельзя редактировать вруч- ную. Необходимо сначала остановить сервер BIND с помощью команд ndc f reez зона или ndc freez зона класс представление. Эти команды синхронизируют журналь- ный файл с файлом главной зоны на диске, а затем удаляют журнал. После этого можно отредактировать зонный файл вручную. К сожалению, исходное форматирование файла пропадет (он будет иметь вид файла, который ведется демоном named на подчиненных серверах). При “заморозке” зоны попытки динамического обновления отменяются. Для того чтобы загрузить зонный файл с диска и все-таки выполнить динамическое обновление, следует использовать команду rdns thaw с теми же аргументами, которые были указа- ны при “заморозке” зоны.
Глава 17. Система доменных имен 685 Утилита nsupdate, входящая в дистрибутив BIND 9, позволяет осуществлять ди- намические обновления из командной строки. Утилита работает в пакетном режиме, принимая команды, вводимые с клавиатуры, или читая их из файла. Пустая строка или команда send являются признаком завершения обновления и пересылают изменения на сервер. Две пустые строки означают конец входного потока. В командном языке предусмотрена примитивная инструкция if, позволяющая формулировать условия вида “если имя неизвестно в DNS, добавить его”. Искомое имя (или набор записей о ресур- сах) может существовать либо отсутствовать. Ниже показан простейший сценарий nsupdate, который заносит в базу данных ин- формацию о новом узле, а также псевдоним существующего узла, при условии что этот псевдоним нигде не используется. Угловые скобки создаются программой nsupdate и не являются частью командного сценария. % nsupdate > update add newhost.cs.colorado.edu 86400 А 128.138.243.16 > prereq nxdomain gypsy.cs.colorado.edu > update add gypsy.cs.colorado.edu CNAME evi-laptop.cs.colorado.edu Динамические обновления — очень опасная возможность. Они потенциально спо- собны предоставить право неконтролируемой записи важных системных данных. Не пытайтесь контролировать доступ на основании IP-адресов: их легко подделать. Лучше воспользоваться системой аутентификации TSIG с совместным секретным ключом. На- пример, в системе BIND 9 поддерживается команда % nsupdate -к каталог_ключа:файл_ключа ИЛИ % nsupdate -к каталог_ключа:секретныи_ключ Поскольку пароль задается в командной строке в виде -у, его может увидеть тот, кто запустит команду w или ps в правильный момент. По этой причине более предпочти- тельной является форма -к. Подробнее технология TSIG описана в разделе 17.13. Динамические обновления зоны разрешаются в файле named, conf посредством па- раметра allow-update или update-policy. Параметр allow-update предоставляет право обновления любых записей клиентам, чьи IP-адреса и ключи шифрования указа- ны в списке. Параметр update-policy появился в BIND 9 и позволяет точнее управ- лять обновлениями на основании имен узлов и типов записей. Он требует использовать механизмы аутентификации. Оба параметра являются зонными. С помощью параметра update-policy можно разрешить клиентам обновлять свои записи А и PTR, но не SOA, NS или KEY. Можно также позволить узлу обновлять толь- ко свои записи. Имена допускается задавать явно, в виде поддоменов, с метасимвола- ми или с помощью ключевого слова self, которое задает правила доступа компьюте- ра к собственным записям. Записи о ресурсах идентифицируются по классу или типу. Синтаксис параметра update-policy выглядит следующим образом. update-policy { grant | deny } сущность имя_типа имя [типы] ; Здесь сущность — это имя криптографического ключа, необходимого для авториза- ции обновлений. Имя_типа имеет четыре значения: name, subdomain, wildcard или self. Имя — это обновляемая зона, а типа — типы записей о ресурсах, которые можно обновить. Если типы не указаны, то могут обновляться записи всех типов, кроме SOA, NS, RRSIG и NSEC или NSEC3. Рассмотрим пример. update-policy { grant dhcp-key subdomain dhcp.cs.colorado.edu A } ;
686 Часть II. Работа в сети В такой конфигурации любому, у кого есть ключ dhcp-key, разрешается обновлять адресные записи в поддомене dhcp. cs. Colorado. edu. Эта директива должна появиться в файле named.conf в инструкции zone домена dhcp. cs. Colorado. edu. Потребуется также инструкция key, содержащая определение ключа dhcp-key. Приведенный ниже фрагмент файла named. conf факультета компьютерных наук университета Колорадо (Computer Science Department at the University of Colorado) ис- пользует инструкцию update-policy для того, чтобы позволить студентам, находя- щимся в классе системного администратора, обновлять свои поддомены, не касаясь при этом остального окружения системы DNS. // saclass.net zone "saclass.net” { type master; file "saclass/saclass.net"; update-policy { grant feanor_mroe. subdomain saclass.net.; grant mojo_mroe. subdomain saclass.net.; grant dawdle_mroe. subdomain saclass.net.; grant pirate_mroe. subdomain saclass.net.; }; 17.13. Вопросы безопасности DNS появилась как совершенно открытая система, но в процессе развития она ста- новилась все более защищенной, приобретая необходимые средства защиты. По умол- чанию каждый, у кого есть доступ в Интернет, может исследовать чужой домен отдель- ными запросами с помощью таких команд, как dig, host или nslookup. В некоторых случаях можно получить образ всей базы данных DNS. Для устранения этих недостатков в последние версии пакета BIND были введены различные средства управления доступом, основанные на проверке адресов или крипто- графической аутентификации. В табл. 17.12 перечислены элементы подсистемы безопас- ности, которые настраиваются в файлах named.conf, nsd.conf или unbound, conf. Таблица 17.12. Средства защиты в файле named.conf (Параметр Инструкции Что определяет BIND acl Разные Списки управления доступом allow-query options, zone Кто может посылать запросы зоне или серверу allow-recursion options Кто может посылать рекурсивные запросы allow-transfer options, zone Кто может запрашивать зонные передачи allow-update zone Кто может выполнять динамические обновления blackhole options Какие серверы нужно полностью игнорировать bogus server Какие серверы никогда нельзя опрашивать update-policy zone Какие обновления разрешены
Глава 17. Система доменных имен 687 Окончание табл, 17,12 Параметр Инструкций . Что определяет ’ " "" NSD/Unbound access-control server Кто может посылать запросы (Unbound) allow-notify Подчиненная зона Кто может посылать уведомления (NSD) chroot server Корневой каталог notify Главная зона Подчиненные серверы, которые должны получать уве- домление (NSD) provide-xfr Главная зона Получатели при передаче зон (NSD) request-xfr Подчиненная зона Провайдеры передачи зон (NSD) username server Пользователь, который должен работать в виртуаль- ном окружении chroot Для того чтобы минимизировать риск, все три сервера имен могут запускаться в вир- туальном окружении chroot под непривилегированным идентификатором; сервер имен unbound делает это по умолчанию. Все они могут использовать подпись транзакции, для того чтобы управлять взаимодействием между главными и подчиненными серве- рами (BIND и NSD), а также между серверами имен и их управляющими программами (BIND и Unbound). Кроме того, все они полностью поддерживают протокол DNSSEC. Эти вопросы рассмотрим в следующих разделах. Еще раз о списках управления доступом в сервере BIND Список управления доступом — это именованный список соответствия адресов, который может служить аргументом различных директив, в частности allow-query, allow-transfer и blackhole. Синтаксис списков был рассмотрен ранее. Кроме того, списки управления доступом могут способствовать укреплению безопасности QNS- серверов. В каждой организации должен существовать хотя бы один список для недоступных адресов и один — для локальных. Рассмотрим пример. acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 169.254.0.0/16; // список недоступных и фиктивных сетей // адреса по умолчанию // зарезервированные адреса // зарезервированные адреса // канально-локальные делегируемые адреса // тестовые адреса, наподобие example.com // пространство групповых адресов // частное адресное пространство (RFC1918)26 // частное адресное пространство (RFC1918) // частное адресное пространство (RFC1918) }; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/8; 192.168.0.0/16; acl cunets { 128.138.0.0/16; // список сетей университета штата Колорадо // основная кампусная сеть 198.11.16.0/24; 204.228.69.0/24; 26 Не делайте частные адреса недоступными, если они используются для конфигурирования внутренних DNS-серверов!
688 Часть II. Работа в сети Далее нужно в глобальном разделе options конфигурационного файла разместить следующие директивы. allow-recursion { cunets; }; blackhole { bogusnets; }; Желательно также ограничить зонные передачи только легитимными подчиненными серверами. Это достигается с помощью следующих списков. acl ourslaves { 128.138.242.1; // сервер anchor }; acl measurements { 198.32.4.0/24; // проект Билла Маннинга, адрес v4 2001:478:6:::/48; // проект Билла Маннинга, адрес v6 }; Собственно ограничение реализуется такой строкой. allow-transfer { ourslaves; measurements; }; Передачи разрешены только нашим подчиненным серверам, а также компьютерам глобального исследовательского проекта, который посвящен определению размеров сети Интернет и процента неправильно сконфигурированных серверов. Подобное огра- ничение лишает остальных пользователей возможности получать дамп всей базы данных с помощью команды dig. Разумеется, нужно по-прежнему защищать сеть на более низком уровне с помощью списков управления доступом на маршрутизаторе и стандартных средств защиты на каждом узле. Если такой возможности нет, ограничьте трафик DNS-пакетов шлюзовым компьютером, который находится под постоянным административным контролем. Открытые распознаватели Открытый распознаватель — это рекурсивный кеширующий сервер имен, получаю- щий запросы от любого пользователя Интернета и отвечающий на них. Открытые рас- познаватели опасны. Внешние пользователи могут потреблять ваши ресурсы без вашего разрешения или ведома, и если они делают это со злым умыслом, кеш вашего распозна- вателя может выйти из строя. Что еще хуже, открытые распознаватели иногда используются злоумышленниками для усиления распределенной атаки на основе отказа в обслуживании. Атакующие по- сылают запрос на ваш распознаватель, указывая фальшивый адрес источника, который является объектом атаки. Ваш распознаватель послушно отвечает на эти запросы и по- сылает огромный пакет жертве. Жертва не посылала запросы, но она обязана выполнить маршрутизацию и обработать сетевой трафик. Умножьте объем пакета на количество распознавателей, и вы осознаете реальную опасность, грозящую жертве. Статистика свидетельствует о том, что от 75 до 80% кеширующих серверов имен в настоящее время являются открытыми распознавателями! Сайт dns .measurement- factory . сот/tools может помочь вам проверить ваш сайт. Зайдите на него, выберите команду “open resolver test” и наберите IP-адрес вашего сервера имен. Вы можете также проверить все серверы имен вашей сети или все серверы вашей организации, используя идентификаторы whois.
Глава 17. Система доменных имен 689 Для того чтобы ваши кеширующие серверы имен отвечали на запросы только ло- кальных пользователей, используйте список управления доступом в файлах named, conf и unbound.conf. Работа в виртуальном окружении chroot Если хакеры взломают ваш сервер, то они смогут получить доступ к системе под видом законного пользователя. Для того чтобы уменьшить опасность, возникающую в этой ситуации, вы можете запустить сервер в виртуальном окружении chroot либо под видом непривилегированного пользователя, либо сделать и то, и другое одновременно. Для демона named флаг команды -t задает каталог виртуального окружения chroot, а флаг -и указывает идентификатор пользователя, под которым работает демон named. Рассмотрим пример. $ sudo named -u 53 Эта команда запускает демон named как корневой процесс, но после того как демон named закончит рутинные операции в роли корневого процесса, он потеряет привиле- гии и запустится под идентификатором 53. Для серверов nsd и unbound того же эффекта можно добиться с помощью опций username и chroot команды server в файле конфигурации. Эти опции также мож- но указать в командной строке сервера nsd с теми же самыми флагами, что и в пакете BIND,----и и -t соответственно. Многие организации не используют флаги -и и -t, но если объявлена тревога, они должны реагировать быстрее, чем хакеры. Виртуальное окружение chroot не может быть пустым каталогом, поскольку оно должно содержать все файлы, необходимые серверу имен для нормальной работы, — /dev/null, /dev/random, зонные файлы, файлы конфигурации, ключи, файлы си- стемного журнала и доменного сокета UNIX, /var и др. Для того чтобы настроить их, требуется выполнить довольно большую работу. Вызов системы chroot осуществляется после загрузки библиотек, поэтому копировать общие библиотеки в виртуальное окру- жение не обязательно. Безопасные межсерверные взаимодействия посредством технологий TSIG и TKEY Пока спецификация DNSSEC (описана в следующем подразделе) находилась на стадии принятия, группа IETF разработала более простой механизм, названный TSIG (RFC2845). Он позволял организовать безопасное взаимодействие серверов благодаря использованию сигнатур транзакций. Контроль доступа, основанный на таких сигнату- рах, надежнее контроля на основе исходных IP-адресов. Сигнатура транзакции аутенти- фицирует пару “отправитель/получатель” и позволяет проверить, изменились ли данные в процессе передачи. В технологии TSIG применяется симметричная схема шифрования, т.е. ключ шиф- рования совпадает с ключом дешифрования. Такой ключ называется совместным се- кретным ключом (shared secret). Спецификация TSIG допускает использование несколь- ких методов шифрования. В пакете BIND реализованы методы MD5, SHA-1, SHA-224 и SHA-256. Сервер NSD реализует те же методы, за исключением метода SHA-224. Для каждой пары серверов, между которыми организуется защищенный канал связи, должен создаваться свой ключ.
690 Часть II. Работа в сети Спецификация TSIG гораздо менее затратная в вычислительном плане, чем шифро- вание с открытым ключом, но она подходит только для локальной сети, где число пар взаимодействующих серверов невелико. На глобальную сеть эта спецификация не рас- пространяется. Настройка технологии TSIG для сервера BIND Утилита dnssec-keygen, являющаяся частью пакета BIND, генерирует ключ для пары серверов. Рассмотрим, например, следующую команду. $ dnssec-keygen -a HMAC-MD5 -Ь 128 -n HOST master-slavel Флаг -Ь 128 означает, что утилита dnssec-keygen должна создать 128-разрядный ключ. В данном случае мы используем 128-разрядный ключ только лишь для того, что- бы он поместился на странице. В реальной жизни следует использовать более длинный ключ; максимально допустимая длина ключа равна 512. Данная команда создает два файла: Kmaster-slavel .+157+09068 .private и Kmaster-slavel. +157+09068.key, где 157 — код алгоритма HMAC-MD5, а 09068 — случайное число, используемое в качестве идентификатора ключа на случай, если у одной пары серверов есть несколько ключей.27 Оба файла содержат один и тот же ключ, но в разных форматах. Файл .private вы- глядит примерно так. Private-key-format: vl.2 Algorithm: 157 (HMAC_MD5) Key: jxopbeb+aPc71Mm2vc9R9g== Содержимое файла . key будет таким. master-slavel. IN KEY 512 3 157 jxopbeb+aPc71Mm2vc9R9g== Обратите внимание на то, что утилита dnssec-keygen добавила точки в конец име- ни каждого ключа в обоих именах файлов и внутри файла . key. Это объясняется тем, что когда утилита dnssec-keygen использует ключи DNSSEC, добавляемые в зонные файлы, имена этих ключей должны быть полностью определены именами доменов и, следовательно, должны заканчиваться точкой. Таким образом, нам нужны два инстру- мента: один для совместных секретных ключей, а второй — для пар открытых ключей. Вообще-то, файл . key на самом деле не нужен: он создается потому, что утилита dnssec-keygen имеет двойное назначение. Просто удалите его. Число 512 в записи KEY означает не длину ключа, а флаг, идентифицирующий запись как запись о главном ключе DNS. После всех этих сложностей вы могли быть разочарованы тем, что сгенерированный ключ представляет собой просто длинное случайное число. Этот ключ можно было бы сгенерировать вручную, записав строку в кодировке ASCII, длина которой делится на четыре, и считать, что вы применили 64-разрядное кодирование, или использовать ути- литу mmencode для того, чтобы зашифровать случайную строку. Способ, которым вы ко- дируете ключ, не имеет значения; он просто должен существовать на обеих машинах. Ш Команда scp является частью пакета SSH. Скопируйте ключ из файла .private на оба сервера с помощью команды scp или просто скопируйте и вставьте его. Не используйте утилиты telnet и ftp для копирова- ния ключа: даже внутренние сети могут быть небезопасными. 27 Это число выглядит случайным, но на самом деле оно представляет собой хешированное значение ключа TSIG.
Глава 17. Система доменных имен 691 Ключ должен быть записан в файлах named. conf на обоих компьютерах. В связи с тем, что эти файлы — общедоступны, а ключ — нет, поместите ключ в отдельный файл, который будет подставляться в файл named. conf. Файл ключа должен иметь уро- вень доступа, равный 600, и принадлежать пользователю демона named. Например, можно создать файл master-slavel. tsig и включить в него следующий фрагмент. key master-slavel { algorithm hmac-md5 ; secret "сгенерированный_ключп ; }; В файл named, conf, ближе к началу, нужно добавить такую строку. include "master-slavel.tsig”; На данном этапе лишь определен ключ. Для того чтобы его можно было использо- вать для подписи и проверки обновлений, нужно посредством инструкции server и ди- рективы keys заставить каждый сервер идентифицировать другую сторону. Например, в инструкцию zone на главном сервере можно включить строку allow-transfer { key master-slavel. ; }; а в файл named.conf подчиненного сервера — строку server 1Р-адрес-главного_сервера { keys [ master-slavel ; } ; } ; Имя ключа в нашем примере носит общий характер. Если вы используете ключи TSIG для многих зон, то, возможно, захотите включить в имя ключа имя зоны, чтобы все стало ясно. Для того чтобы протестировать конфигурацию системы TSIG, выполните утилиту named-checkconf и проверьте синтаксис. Затем с помощью команды dig попытайтесь выполнить передачу зоны (dig@master axfr) от сервера slavel и какой-нибудь другой машины. Первая попытка должна оказаться успешной, а вторая должна завершиться сбоем и сообщением об ошибке “Transfer failed”. Для того чтобы убедиться, что все в по- рядке, удалите раздел allow-transfer и попытайтесь выполнить команду dig снова. На этот раз обе попытки должны завершиться успехом. (Не забудьте вернуть в файл раз- дел allow-transfer!) И наконец, увеличьте порядковый номер зоны на главном сер- вере, выполните команду rndc reload и просмотрите системный журнал на подчинен- ном сервере, чтобы убедиться, что изменения приняты и передача зоны произошла. Если вы впервые используете подписи транзакций, запускайте демона named на первом уровне отладки (режимы отладки будут описаны позднее), пока сообщения об ошибках не исчезнут. В ранних версиях пакета BIND сервер не понимал подписанных сообщений и сообщал об ошибках, что иногда приводило к ошибочной передаче зоны. Ш Протокол NTP описан в разделе 9.5 При использовании ключей TSIG и подписей транзакций между главным и подчи- ненным серверами, необходимо синхронизировать часы на обоих серверах по протоколу NTP. Если часы слишком сильно расходятся (более чем на пять минут), то верификация подписи не будет выполнена. Эту проблему иногда очень сложно распознать. TSIG — это механизм сервера BIND, позволяющий двум узлам автоматически ге- нерировать совместный секретный ключ, не прибегая к телефонным звонкам или се- кретному копированию для распространения ключа. Он использует алгоритм обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange algorithm), в котором на каждой стороне генерируется случайное число, над ним выполняются определенные математи-
692 Часть II. Работа в сети ческие операции, а результат посылается другой стороне. Затем каждая сторона объеди- няет свое и полученное числа по определенному математическому правилу и получает один и тот же ключ. Злоумышленник может перехватить сообщение, но он не сможет выполнить над ним требуемые математические операции.28 Серверы компании Microsoft используют нестандартный вариант механизма TSIG, который называется GSS-TSIG. В нем для обмена ключами используется технология TKEY. Если вам нужно, чтобы сервер компании Microsoft взаимодействовал с сервером BIND, используйте опции tkey-domain и tkey-gssapi-credential. Другой механизм для подписи трансакций между серверами или службами динами- ческого обновления и главным сервером называется SIG(O). Он использует криптогра- фию, основанную на открытых ключах. Детали этой технологии описаны в документах RFC2535 и RFC2931. Механизм TSIG на сервере NSD Для того чтобы сгенерировать ключи TSIG для списка управления доступом на сер- вере NSD, можно использовать утилиту Idns-keygen из каталога examples в дистрибу- тивном пакете Idns. Подробности описаны немного ниже. Сервер NSD не поддержива- ет ключи SIG(O) и обмен ключами TKEY по алгоритму Диффи-Хеллмана. Технология DNSSEC DNSSEC — это набор расширений DNS, позволяющих аутентифицировать ис- точник данных зоны и проверить их целостность, используя шифрование с открытым ключом. Таким образом, DNSSEC позволяет DNS-клиентам задавать вопросы вида “Действительно ли данные зоны поступили от владельца зоны?” и “Те ли это данные, которые послал владелец?”. Технология DNSSEC реализует три разных механизма: • распределение ключей посредством записей KEY, хранящихся в зонных файлах; • проверка подлинности серверов и данных; • проверка целостности данных. Здесь формируется цепочка доверия: корневые серверы предоставляют подтверждаю- щую информацию для доменов верхнего уровня, те — для доменов второго уровня и т.д. По крайней мере, так это задумывалось. В начале 2010 года и корневой, и большинство доменов верхнего уровня оставались без подписей. Корпорация ICAAN и Министерство торговли США стали делать определенные шаги в направлении внедрения подписей в корневом домене, но пока все ограничива- ется обещаниями. Возможно, это произойдет в средине 2010 года.29 Со своей стороны, по-видимому, доменный регистратор VerySign не собирается подписывать зоны . сот и .net.30 Эти зоны уже слишком велики, а их подписанные версии будут еще больше и потребуют дополнительного серверного обеспечения. Более того, сертификаты Х.509 компании feriSign обеспечивают значительную долю ее прибыли, а технология DNSSEC 28 Математическую основу этого алгоритма образует задача дискретного логарифмирования, особенность которой состоит в том, что в модулярной арифметике возвести число в степень до- вольно просто, а вычислить логарифм по этой степени практически невозможно. 29 Подписание корневой зоны состоялось 15 июля 2010 года .— Примеч. ред. 30 В конце 2010 года доменный регистратор Verisign сообщил о поддержке технологии DNSSEC для доменной зоны . net.
Глава 17. Система доменных имен 693 может заменить эти сертификаты для определенных приложений. Тем не менее компа- ния VerySign обещала подписать зону . сот в 2011 году, синхронизировав этот процесс с переговорами о своем контракте с корпорацией ICAAN, который должен быть заключен в 2012 году. К счастью, концепция точек доверия позволяет развернуть процесс легализации тех- нологии DNSSEC и расширить защищенные области в дереве DNS еще до внедрения подписанных корневых доменов и доменов верхнего уровня. В системах шифрования с открытым ключом используются два ключа: один шифрует (подписывает) сообщение, а другой дешифрует (проверяет) его. Публикуемые данные подписываются секретным “личным” ключом. Любой может проверить правильность цифровой подписи с помощью соответствующего “открытого” ключа, который свобод- но распространяется. Если открытый ключ позволил правильно расшифровать зонный файл, значит, зона была зашифрована искомым личным ключом. Суть в том, чтобы убе- диться в подлинности открытого ключа, используемого для проверки. Такие системы шифрования позволяют одной из сторон поставить свою “подпись” на открытом ключе, передаваемом другой стороне, гарантируя легитимность ключа. Отсюда термин “цепоч- ка доверия”. Данные, составляющие зону, слишком велики для шифрования с открытым ключом; процесс шифрования получится слишком медленным. Вместе с тем данные сами по себе не секретны, поэтому они просто пропускаются через функцию хеширования (к при- меру, вычисляется контрольная сумма MD5), а результат подписывается (шифруется) секретным ключом зоны. Полученный зашифрованный хеш-код называется цифровой под- писью или сигнатурой зоны. Цифровые подписи обычно добавляются к данным, подлин- ность которых они удостоверяют в виде записей RRSIG в подписанном зонном файле. Для проверки сигнатуры ее нужно дешифровать открытым ключом подписавшей стороны, “прогнать” данные через тот же алгоритм хеширования и сравнить вычислен- ный хеш-код с расшифрованным. В случае совпадения подписавшее лицо считается ау- тентифицированным, а данные — целостными. В технологии DNSSEC каждая зона имеет открытые и секретные ключи. Фактически она имеет два набора ключей: пара ключей для подписи зоны и пара ключей для под- писи ключа. Секретным ключом подписи зоны подписывается каждый набор ресурсов (т.е. каждый набор записей одного типа, относящихся к одному узлу). Открытый ключ подписи зоны используется для проверки сигнатур и включается в зонную базу данных в виде записи DNSKEY. Родительские зоны содержат записи DS, представляющие собой хешированный ва- риант записей DNSKEY для самоподписывающихся ключей подписи ключей (self-signed key-signing keys). Сервер имен проверяет аутентичность записи DNSKEY дочерней зоны, сравнивая ее с подписью родительской зоны. Для проверки аутентичности ключа ро- дительской зоны сервер имен проверяет родительскую зону родительской зоны и так далее, пока не вернется в корневую зону. Открытый ключ корневой зоны должен быть открыто опубликован и включен в файлы “подсказок” корневой зоны. В соответствии со спецификациями DNSSEC, если зона имеет несколько ключей, каждый из них должен применяться при проверке данных. Это требование объясняется тем, что ключи могут быть изменены без прерывания работы службы DNS. Если рекур- сивный сервер имен, использующий технологию DNSSEC, посылает запрос неподпи- санной зоне, то поступающий неподписанный ответ считается корректным. Проблема возникает лишь тогда, когда срок действия подписи истек или родительская и дочерняя зоны не согласовали текущий ключ DNSKEY дочерней зоны.
694 Часть II. Работа в сети Прежде чем погрузиться в механизм генерирования ключей и подписания зон, не- обходимо иметь краткое представление о реальном состоянии технологии DNSSEC и ее влиянии на системных администраторов. Ее можно развернуть уже сейчас, но остается нерешенным множество проблем. К преимуществам технологии DNSSEC можно отне- сти следующее. • Текущие версии программного обеспечения серверов DNS (как named, так и nsd/ unbound) уже готовы. Существуют инструменты для подписания зон и верифика- ции подписей. • Совсем скоро будут созданы подписанные зоны. В начале 2010 года домены . gov, . org и некоторые домены ccTLD (преимущественно в Европе) уже были подпи- саны. (Швеция первой подписала домен TLD.) Корневой домен был подписан в 2010 году, а другие домены gTLD были подписаны позднее. Правительство США потребовало, чтобы все сайты в домене . gov также были подписаны. • Стандарты IETF кажутся функциональными и работоспособными. Однако остается две проблемы: распределение ключей и размер пакетов. Пока корневой домен и домены TLD не подписаны, цепочка доверия часто обрыва- ется. Сайты, требующие, чтобы их зоны были подписаны, должны найти другие способы опубликовать свои ключи. Схема динамической проверки (lookaside validation scheme), описанная Сэмом Уейлером (Sam Weiler) из компании Sparta в документах RFC4431 и RFC5074, предоставляет удобный способ решения этой проблемы, основанный на при- влечении к проверке ключей сайтов посторонних организаций, таких как ISC. Это удоб- ное временное решение, которое также имеет изъян. Организация ICS используется для запуска критически важных серверов (в частности, она контролирует работу корневого сервера F), но иногда происходят сбои. Кроме того, существует проблема, связанная с возможным нарушением конфиденциальности со стороны посредника, знающего все сайты, которые посещают пользователи. (Разумеется, это относится ко всем операторам корневых серверов.) Другой паллиатив заключается в использовании так называемых промежуточных репозитариев точек доверия (ITAR — Interim Trust Anchor Repository). Этот механизм описан на сайте itar. iana. org. Надежные ключи имеют большую длину, и некоторые сайты предпочитают распро- странять некоторые из них. Это приводит к увеличению размера пакетов. Спецификации DNSSEC требуют использования технологии EDNS0, представляющей собой расши- ренный протокол DNS, поддерживающий пакеты UDP, размер которых превышает 512 байт. Однако их поддерживают не все реализации; эти реализации не могут исполь- зовать технологию DNSSEC. Даже на серверах, поддерживающих технологию EDNS0, предельный размер пакета, передаваемого через линию связи между двумя серверами, может оказаться меньше, чем размер огромного подписанного пакета, оснащенного ключами. Если пакет слишком велик, то на уровне IP теоретически его можно разбить на фрагменты, но проблема все равно остается. Некоторые реализации протокола ТС/IP фрагментируют пакеты TCP, но не UDP. Некоторые брандмауэры не могут сохранить состояние, чтобы затем правиль- но восстановить пакеты UDP. Кроме того, некоторые брандмауэры передают на порт 53 UDP-пакеты, размер которых превышает 512 байт. Ой! Если ответ UDP искажен или не проходит через линию связи, то клиент переключается на протокол TCP, имеющий свои собственные проблемы, связанные с производительностью.
Глава 17. Система доменных имен 695 Укажем еще несколько проблем. • Россия отказывается использовать алгоритм RSA, а ведь он является единствен- ным алгоритмом, который необходим для реализации серверов имен, поддержи- вающих протокол DNSSEC. Россия стандартизировала алгоритм GOST, представ- ляющий собой алгоритм симметричного шифрования, схема которого напоминает алгоритм DES.31 • Китай и некоторые другие страны имеют свои собственные корневой, .сот- и .net-серверы, что приводит к расщеплению дерева имен DNS. Как технология DNSSEC будет работать с расщепленным деревом имен? • Стандарт RFC5011, предложенный для автоматического обновления точек дове- рия DNSSEC, резко увеличивает затраты на обработку ключей за счет добавления ключей к пользовательским наборам записей о ресурсах DNSKEY. Это расшире- ние может исчерпать память и кажется плохой идеей. Кроме того, иногда при ис- пользовании схемы RFC5011 ключи сайта оказываются аннулированными, даже если эти ключи все еще необходимы для верификации кешированных данных. • Дистрибутивные пакеты системы Linux поставляются вместе со списком ключей, необходимых для начала работы. Это кажется нам неудачной идеей, поскольку эти ключи со временем неизбежно устареют и станут неправильными. Ваша система DNS будет медленно деградировать, а вы не будете знать почему. (Списки ключей сами по себе не всегда плохи. Например, их можно использовать на веб-сайтах RIPE и IANA для перекрестной проверки ключей, полученных по системе DNS, пока корневой домен и домены TLDs не будут подписаны.) • Иногда нам необходим хорошо известный узел (аналог www для веб-серверов), который можно было бы использовать для публикации открытых ключей в ожи- дании, пока будет подписана вершина дерева DNS — ключ.имя-домена или что-то в этом роде. Системные администраторы должны начать думать о подписании своих доменов и установке одного или двух новых серверов. Мы рекомендуем разворачивать протокол DNSSEC уже сейчас, но сначала тщательно осуществить этот процесс на тестовой сети и лишь затем переходить к масштабу предприятия. Развертывание протокола DNSSEC можно выполнить в виде двух независимых этапов. • Подпишите ваши зоны и предоставляйте подписанные данные клиентам, поддер- живающим протокол DNSSEC. • Проверяйте ответы на запросы ваших пользователей. Испытайте удобный инструмент SecSpider, разработанный в университете UCLA (University of California, Los Angeles) и размещенный на сайте secspider. cs . ucla. edu. Он зондирует вашу установку протокола DNSSEC с нескольких узлов Земного шара, чтобы убедиться, что ваши ключи доступны и крупные пакеты, содержащие эти ключи, могут достичь этих узлов. (Именно благодаря инструменту SecSpider была вы- явлена проблема, связанная с предельно допустимым размером пакета, передаваемым по линии связи при использовании протокола DNSSEC.) Программа SecSpider также 31 Протокол GOST является надежным (насколько нам известно) и использует намного более короткую длину ключа, чем другие алгоритмы. Поскольку он является алгоритмом симметричного шифрования и не относится к системам с открытым ключом, он может заменить протокол TSIG, но не может использоваться для реализации технологии DNSSEC. Предложения разрешить ис- пользование алгоритма GOST блокируются организацией IETF.
696 Часть II. Работа в сети идентифицирует неправильные конфигурации протокола DNSSEC. Это может оказать- ся полезным для сбора данных студентами, пишущими дипломные работы. Вы можете также получить копии открытых ключей других подписанных зон с веб-сайта SecSpider (secspider.cs.ucla.edu/trust-anchors.conf). Центр DNS-OARC (DNS Operations, Analysis, and Research Center) реализовал те- стовый сервер для проверки размеров ответов. С помощью утилиты dig на этот сервер можно послать запрос, чтобы выяснить, насколько большой ответный пакет UDP может пройти по линии связи между этим сервером и вашим сайтом. Рассмотрим следующий пример. $ dig +short rs.dns-oarc.net txt rst.xl014.rs.dns-oarc.net. rst.xl202.X1014.rs.dns-oarc.net. rst.x.1382.xl202.X1014.rs.dns-oarc.net. ”63.231.83.113 DNS reply size limit is at least 1382 bytes" "63.231.83.113 sent EDNS buffer size 4096" Этот пример свидетельствует о том, что по линии связи могут пройти ответы DNS, размер которых не превышает 1382 байт, несмотря на то что объявленный размер буфе- ра составляет 4096 байт. В данном случае проблема, вероятно, заключается в том, что брандмауэр не допускает фрагментирование пакетов UDP. Другие общепринятые размеры пакетов: 486, если сервер не поддерживает протокол EDNSO и ограничивает размер пакетов UDP 512 байт, и 4023 — если можно полностью использовать буфер размером 4096 байт. Если передать команде dig аргумент @ server, то можно увидеть ограничения, наложенные на размер пакетов, которые могут прохо- дить по линии связи между машиной DNS-OARC и данным сервером. Более подробную информацию можно найти на сайте dns-oarc. net/oarc/services/replysizetest. Если вы планируете реализовать протокол DNSSEC, а программа SecSpider или сер- вер DNS-OARC свидетельствуют о проблемах с размерами пакетов, возможно, настало время поговорить со специалистами, управляющими брандмауэром, и устранить про- блемы перед развертыванием протокола DNSSEC. Правила протокола DNSSEC Прежде чем приступать к развертыванию протокола DNSSEC, следует усвоить не- ’ сколько правил и процедур или хотя бы подумать о них. Рассмотрим примеры. • Ключи какого размера вы будете использовать? Более длинные ключи являются более надежными, но они увеличивают размеры пакетов. • Как часто будете изменять ключи, если никаких нарушений правил безопасности не происходит? • Как будете распространять свои открытые ключи? Как сайты, нуждающиеся в ва- ших ключах, будут проверять их аутентичность? Мы предлагаем завести специальный журнал, в который вы будете записывать дан- ные о каждом сгенерированном ключе; об аппаратном и программном обеспечении, ис- пользуемом для этого; о дескрипторе, присвоенном ключу; о версии программного ге- нератора ключей; использованном алгоритме; длине ключа; и сроке действия подписи. Если впоследствии криптографический алгоритм окажется скомпрометированным, вы сможете проверить свой журнал и выяснить, не подвергаетесь ли вы опасости.
Глава 17. Система доменных имен 697 Записи о ресурсах DNSSEC Протокол DNSSEC использует шесть типов записей о ресурсах, кратко описанные в разделе 17.8, — DS, DLV, DNSKEY, RRSIG, NSEC и NSEC3. Сначала мы опишем их в целом, а затем очертим их использование в процессе подписания зоны. Каждая из этих записей создается инструментами протокола DNSSEC, а не вводится в зонный файл с помощью текстового редактора. Запись DS (Designated Signer) возникает только в дочерней зоне и означает, что под- зона является безопасной (подписанной). Она также идентифицирует ключ, использу- емый дочерней зоной для подписания своего собственного набора записей о ресурсах KEY. Запись DS содержит идентификатор ключа (пятизначное число), криптографиче- ский алгоритм, тип дайджеста (digest type) и дайджест записи об открытом ключе, раз- решенном (или использованном) для подписи записи о ключе дочерней зоны. Если ваша родительская зона не подписана, вы можете установить точку доверия в организации ISC, используя запись DLV (domain lookaside validation) в том же самом формате. Рассмотрим пример точки доверия и соответствующей записи.32 example.com. IN DS 682 5 1 1 2898DCF9F7AD20DBCE159E7... example.com.dlv.isc.org. IN DLV 582 5 1 12898DCF9F7AD20DBCE159E7... Изменение существующих ключей в родительской и дочерней зонах является слож- ной проблемой и требует сотрудничества и взаимодействия между родительской и до- черней зонами. Для решения этой проблемы создаются записи DS, используются от- дельные ключи для подписи ключей и зон, а также применяются пары многократных ключей. Ключи, содержащиеся в записи о ресурсах DNSKEY, могут быть либо ключами для подписания ключа (key-signing key — KSK) или ключами для подписания зоны (zone- signing key — ZSK). Для различия между ними используется новый флаг под названием SEP (“secure entry point” — “точка безопасного входа”). Пятнадцатый бит поля флагов устанавливается равным единице для ключа KSK и 0 — для ключа ZSK. Это соглашение делает поле флагов нечетным числом для ключа KSK и четным для ключей ZSK, если интерпретировать его как десятичное число. В настоящее время эти значения равны 257 и 256 соответственно. Для обеспечения удобного перехода от одного ключа к другому можно генерировать многократные ключи. Дочерняя зона может изменить свои ключи подписания зоны, не сообщая об этом родительской зоне. Она должна согласовывать с родительской зоной только изменение ключа для подписания ключей. Когда ключ изменяется, и старый, и новый ключи на определенном отрезке времени считаются действующими. Как только срок действия кешированных значений в Интернете истечет, старый ключ будет счи- таться отмененным. Запись RRSIG — это подпись набора записей о ресурсах (т.е. набора всех записей одного и того же типа и с одним и тем же именем внутри зоны). Записи RRSIG генери- руются программным обеспечением, предназначенным для подписания зоны, и добав- ляются в подписанную версию зонного файла. Запись RRSIG содержит много информации. • Тип записей о ресурсах, входящих в подписываемый набор. • Алгоритм, используемый для подписания и закодированный небольшим числом. 32 В этом разделе 64-разрядные хеши и ключи были усечены, чтобы сэкономить пространство и лучше проиллюстрировать структуру записей.
698 Часть II. Работа в сети • Количество меток (фрагментов, разделенных точками) в поле имени. • Значение TTL для подписываемого набора записей. • Срок действия подписи (в формате ггггммддччсссс). • Время подписания набора записей (также в формате ггггммддччсссс). • Идентификатор ключа (пятизначный номер). • Имя подписавшего (имя домена). • Сама цифровая подпись (64-разрядная). Рассмотрим пример. RRSIG NS 5 2 57600 20090919182841 ( 20090820182841 23301 example.com. pMKZ76waPVTb!guEQNUojNVlVewHau4p...==) При подписании зоны также генерируются записи NSEC или NSEC3. В отличие от подписанных наборов записей, они сертифицируют интервалы между именами наборов записей и тем самым позволяют подписывать ответ типа “нет такого домена” или “нет такого набора записей о ресурсах”. Например, сервер может ответить на запрос записей А с именем bork. atrust. com, послав запись NSEC, подтверждающую отсутствие лю- бых записей А между именами bork. atrust. com и borrelia. atrust. com. К сожалению, включение в записи NSEC конечных точек позволяет обойти зону и выяснить все ее действующие узлы. В версии NSEC3 этот недостаток был устранен пу- тем включения в запись хешированных имен конечных точек, а не самих имен. Правда, это было сделано за счет более интенсивных вычислений: чем выше безопасность, тем ниже производительность. В настоящее время используются как записи NSEC, так и за- писи NSEC3, и вы должны будете сделать выбор между ними при генерировании своих ключей и подписании своих зон. Если защита от блуждания по зоне не является критически важной для вашей орга- низации, мы рекомендуем пока использовать запись NSEC. Только последние версии серверов BIND (9.6 и далее) и NSD (3.1 и далее) понимают записи NSEC3. Настройка протокола DNSSEC Поскольку сервер NSD является единственным авторитетным сервером имен, толь- ко он должен осуществлять обработку подписанных данных для клиентов, поддерживаю- щих протокол DNSSEC. При этом нет необходимости явно включать протокол DNSSEC. Если зона подписана, сервер NSD использует протокол DNSSEC автоматически. Сервер BIND является более сложным. Текущие версии BIND не содержат в дистри- бутивном наборе пакет OpenSSL, поэтому, если вы хотите использовать протокол DNSSEC, то должны получить либо заранее настроенный пакет, включающий поддержку протокола DNSSEC, либо библиотеки SSL непосредственно с сайта openssl. org. Если вы используете вторую возможность, то нужно перекомпилировать сервер BIND, чтобы включить криптографическую поддержку (с помощью опции —with-openssl коман- ды . /configure). Если вы не сделаете этого, то команда dnssec-keygen сообщит об ошибке. Однако она по-прежнему будет генерировать ключи TSIG, поскольку для этого не требуется пакет OpenSSL. Если версия пакета OpenSSL слишком стара и уязвима для известных угроз, то сервер BIND откроет красивую страницу с предупреждением. Использование подписанных зон связано с двумя разными рабочими потоками: один из них создает ключи и подписывает зоны, а второй обслуживает содержимое этих подписанных зон. Эти функции не обязательно реализовывать на одном и том же
Глава 17. Система доменных имен 699 компьютере. На самом деле лучше изолировать закрытые ключи и процесс подписания зоны, сильно загружающий центральный процессор, на компьютере, который не до- ступен из Интернета. (Разумеется, компьютер, обрабатывающий данные, должен быть виден из Интернета.) На первом этапе настройки протокола DNSSEC следует организовать зонные файлы так, чтобы все файлы данных для зоны находились в одном каталоге. Это необходимо для правильной работы инструментов, управляющих зонами по протоколу DNSSEC. Затем следует включить протокол DNSSEC на своих серверах с помощью опиций файла named. conf. options { dnssec-enable yes; } (для авторитетного сервера) и options { dnssec-enable yes; dns-validation yes; } (для рекурсивных серверов). Опция dnssec-enable приказывает вашему авторитет- ному серверу включать подписи наборов записей DNSSEC в свои ответы на запросы, поступающие от серверов имен, работающих по протоколу DNSSEC. Опция dnssec- validation заставляет демона named проверять легитимность подписей, которые он получает в ответ от других серверов. Генерирование пар ключей Необходимо сгенерировать две пары ключей для каждой зоны, которую хотите под- писать, — для подписания зоны (ZSK) и для подписания ключей (KSK). Каждая пара состоит из открытого и закрытого ключей. Закрытый ключ KSK подписывает ключ ZSK и создает безопасную точку входа для зоны. Закрытый ключ ZSK подписывает записи о ресурсах зоны. Открытые ключи затем публикуются, чтобы позволить другим сайтам проверить ваши подписи. Команды сервера BIND $ dnssec-keygen -a RSASHA1 -Ь 1024 -n ZONE exanple.com Kexample.com.+005+23301 $ dnssec-keygen -a RSASHA1 -Ь 2048 -n ZONE -f KSK exanple.com Kexample.com.+005+00682 и команды сервера NSD $ Idns-keygen -a RSASHA1 -Ь 1024 exanple.com Kexample.com.+005+23301 $ Idns-keygen -a RSASHA1 -Ь 2048 -к exanple.com Kexample.com.+005+00682 генерируют для сайта Kexample. com пару 1024-битовых ключей ZSK, использующую алгоритмы RSA и SHA-1, а также соответствующую пару 2048-битовых ключей KSK.33 Серьезная проблема, связанная с ограничением на предельный размер пакета UDP, вы- нуждает отдавать предпочтение коротким ключам для подписания зоны и часто их ме- нять. Для повышения уровня безопасности можно использовать более длинные ключи 33 2048 бит — это, конечно, излишество; многие сайты используют 1500 бит и меньше.
700 Часть II. Работа в сети для подписания ключей. Ключи генерируются недолго: одна-две минуты для коротких ключей и полчаса и более — для длинных ключей на медленных устаревших ноутбуках. Оба генератора ключей печатают в стандартном потоке вывода базовое имя файла для сгенерированного ключа. В нашем примере example. com — это имя ключа, 005 — идентификатор набора алгоритмов RSA/SHA-1, а 23301 и 00682 — хешированные значения, которые называются идентификаторами ключей, слепками ключей или де- скрипторами ключей.34 При каждом запуске генератор ключей в пакете BIND создает два файла (.key и .private), а генератор ключей на сервере NDS — три файла (.key, .private и .ds). Kexaxnple. com+005+23301. key Kexaxnple.com+005+23301.private Kexaxnple. com+005+23301 .ds Kexaxnple. com+005+00682. key Kexaxnple. com+005+00682 .private Kexaxnple. com+005+00682 .ds # Открытый ключ для подписи зоны # Закрытый ключ для подписи зоны # Запись DS для ключа ZSK (только NSD) # Открытый ключ для подписи ключа # Закрытый ключ для подписи ключа # Запись DS для ключа KSK (только NSD) Существует несколько алгоритмов шифрования, каждый из которых имеет свой диа- пазон длин ключей. Для того чтобы увидеть список доступных алгоритмов, можно вы- полнить команду dnssek-keygen без аргументов или команду Idns-keygen -a list. Как сервер BIND, так и сервер NSD могут использовать ключи, сгенерированные дру- гим программным обеспечением. В зависимости от версии вашего программного обеспечения, имена некоторых до- ступных алгоритмов могут содержать имя NSEC3 в качестве префикса или окончания. Если вы хотите использовать записи NSEC3, а не NSEC для подписания отрицатель- ных ответов, должны сгенерировать №ЕСЗ-совместимые ключи одним из NSEC3- совместимых алгоритмов; подробности можно найти на справочных страницах, посвя- щенных командам Idns-signzone или dnssec-keygen. Каждый файл .key содержит по одной записи о ресурсах DNSSEC для сайта example. com. Например, ниже приведен открытый ключ для подписания зоны, усечен- ный по ширине страницы. Его можно назвать ключом ZSK, потому что поле файлов равно 256, а не 257, как для ключей KSK. example.com IN DNSKEY 256 3 5 AwEAAex7tHe60w5va8sPpnRe4RX8MgI... Эти открытые ключи должны быть вставлены в зонные файлы с помощью дирек- тивы $ INCLUDE или другим способом либо в конец, либо сразу после записи SOA. Для того чтобы скопировать ключи в зонный файл, можно добавить их с помощью команды cat35 и вставить с помощью текстового редактора. Файлы .ds, созданные генератором ключей Idns-keygen на сервере NSD, содержа! записи DS. Если протокол DNSSEC развернут полностью, то файл, соответствующий ключам KSK, должен храниться в родительской зоне. Запись DS может генерироваться на основе записи о ресурсах DNSKEY, соответствующей ключам KSK. Некоторые под- писанные зоны требуют наличия именно таких записей, вместо или в дополнение к за- писи DNSKEY для ключей KSK. Запись DS может выглядеть следующим образом. 34 Для того чтобы сравнивать процессы на серверах BIND и NSD было проще, мы поступили некорректно и сделали слепки ключей одинаковыми. В реальном мире каждый ключ должен иметь отдельный слепок. 35 Используйте команды наподобие cat Kexmaple. сот+*. key»z one file. Операция » означает добавление ключа в файл zonefile,а не его замену, как операция >.
Глава 17. Система доменных имен 701 example.com 3600 IN DS 23301 1 1 5bd844108f8d8fea341b3bc2f2135e... example.com 3600 IN DS 00682 1 1 Odbf80886b7168633ff8273255de09... В идеале, закрытая часть любой пары ключей должна храниться в компьютере, от- ключенном от сети, или хотя бы в компьютере, недоступном из Интернета. Для дина- мически обновляемых зон это требование практически невыполнимо, а для ключей, предназначенных для подписания зон, еще и непрактично. Тем не менее для ключей, предназначенных для подписания других ключей, это требование абсолютно разумно, поскольку эти ключи имеют долгий срок действия. Подумайте о скрытом главном сер- вере, недоступном извне для ключей ZSK. Распечатайте закрытый ключ KSK или напи- шите его на флешке, а затем спрячьте в сейфе, пока он не потребуется в следующий раз. “Заперев” новые закрытые ключи, целесообразно записать информацию о новых ключах в системный файл ключей. При этом не обязательно записывать туда сами клю- чи. Достаточно записать их идентификаторы, алгоритмы, дату, назначение и т.д. По умолчанию срок действия подписи ограничен одним месяцем для записей RRSIG (ZSK-подписи наборов записей о ресурсах) и тремя месяцами для записей DNSSIG (KSK-подписи ключей ZSK). В настоящее время рекомендуется использовать 1024-бито- вые ключи ZSK от трех месяцев до одного года, а 1280-битовые ключи KSK — от одно- го до двух лет.36 Поскольку рекомендуемые сроки действия ключей дольше, чем сроки, установленные для них по умолчанию, эти параметры необходимо указывать явно при подписании или периодическом переподписании зон, даже если сами ключи не изме- нились. Подписание зоны Итак, теперь, когда у вас есть ключи, вы можете подписывать зоны с помощью ко- манд dnssec-signzone (сервер BIND) или Idns-signzone (сервер NDS), добавляю- щих записи RRSIG и NSEC или NSEC3 в каждый набор записей о ресурсах. Эти коман- ды считывают оригинальный зонный файл и создают отдельную подписанную копию с именем зонный_файл.signed. Синтаксис команды dnssec-signzone для сервера BIND имеет следующий вид. dnssec-signzone [-о имя_зоны] [-N increment] [-к KSK-файл] зонный_файл [ZSK-файл] Здесь параметр имя_зоны по умолчанию равен параметру зонный_файл, а поля ключей по умолчанию совпадают с именами файлов, созданных командой dnssec-keygfen, как описано выше. Если вы называете свои зонные файлы по именам зон и сохраняете имена ориги- нальных файлов ключей, то команда упрощается. dnssec-signzone [-N increment] зонный_файл Флаг -N increment автоматически увеличивает порядковый номер в записи SOA, так что забыть его невозможно. Кроме того, можно указать значение unixtime, что- бы установить порядковый номер равным текущему времени UNIX (количеству секунд, прошедших с 1 января 1970 года), или значение keep, чтобы предотвратить изменение оригинального порядкового номера командой dnssec-keygen. Порядковый номер уве- личивается в файле подписанной зоны, но не в оригинальном файле зоны. Рассмотрим пример, в котором используются сгенерированные ранее ключи. 36 Рекомендации разных организаций, касающиеся длин криптографических ключей, приведе- ны на веб-сайте keylength. com.
702 Часть II. Работа в сети $ sudo dnssec-signzone -о exaxnple.com -increment -к Kexample.com+005+00682 example.com Kexample.com+005+23301 Подписанный файл упорядочивается в алфавитном порядке и содержит записи DNSKEY, добавленные вручную, а также записи RRSIG и NSEC, сгенерированные в ходе подписания. Порядковый номер зоны увеличен. Если вы сгенерировали свои ключи с помощью алгоритма NSEC3RSASHA1, то долж- ны подписать зону так, как показано выше, но указав флаг -3 salt. Перечислим другие полезные опции команды dnssec-signzone. • -g — генерирование записи (записей) DS, которая должна быть включена в роди- тельскую зону; • -1 — генерирование записи (записей) DLV, которая используется, если родитель- ская зона не подписана; • -s начальный-момент — установка момента времени, с которого подписи счита- ются действительными; • -е конечный_момент — установка момента времени, после которого подписи счи- таются недействительными; • -t — вывод статистических показателей. Данные о сроках действия подписей можно выразить в виде абсолютного времени в формате ггггммддччммсс или относительного времени, считая от текущего момента, в формате +N, где N — количество секунд. По умолчанию период действия подписи изме- няется от одного часа в прошлое до 30 дней в будущее. Рассмотрим пример, в котором мы указываем, что подписи должны быть действительными до окончания календарного 2010 года. $ dnssec-signzone -N increment -е 20101231235959 example.com На сервере NSD синтаксис подписания зоны выглядит следующим образом. Idns-signzone [-о имя_зони} имя_зоны ключ [ключ ...] Вы можете просто указать оба ключа и разрешить команде Idns-signzone самой выяснить, какой из них является ключом KSK, а какой — ключом ZDK. Рассмотрим пример. $ sudo Idns-signzone example.com Kexample.com.+005+00682 Kexample.com.+005+23301 Как и с командой dnssec-signzone, вы можете установить предельный срок дей- ствия подписей, используя флаг -е ггггммдд, Для генерирования записей NSEC3 вместо записей NSEC для подписания пробелов, используется флаг-n -s salt. Размеры файлов подписанных зон от четырех до десяти раз больше, чем размеры файлов исходных зон, и все попытки навести логический порядок напрасны. Строка на- подобие mail-relay А 63.173.189.2 превращается в несколько следующих строк. mail-relay.example.com. 57600 А 63.173.189.2 57600 RRSIG А 5 3 57600 20090722234636 ( 20090622234636 23301 example.com. Y7s9jDWYuuXvozeU7zGRdFCl+rzU8cLiwoev Ol2TGfLlbhsRgJfkpEYFVRUB7kKVRNguEYwk d21RSkDJ9QzRQ+w==)
Глава 17. Система доменных имен 703 3600 NSEC mail-relay2.example.com. A RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20090722234636 ( 20090722234636 23301 example.com. WNsN84hF0notymRxZRIZypqWzLIPBZAUJ77R HPOhLfBDoqmZYw== ) С практической точки зрения файл подписанной зоны больше нельзя назвать понят- ным для человека и его невозможно отредактировать вручную из-за записей RRSIG и NSEC или NSEC3. Этот файл не содержит ни одного фрагмента, который пользователь мог бы изменить вручную! За исключением записей DNSSEC, каждый набор записей о ресурсах (ресурсных за- писей с одинаковым типом и именем) получает одну подпись от ключа ZSK. Записи о ресурсах DNSSEC подписываются как ключом ZSK, так и ключом KSK, поэтому они содержат две записи RRS1G. Тем не менее 64-разрядное представление подписи закан- чивается несколькими знаками равенства, потому что длина записи должны быть крат- ной четырем. Для того чтобы последующие примеры стали яснее, предположим, что зонный файл называется так же, как и зона, причем зонные файлы и ключевые файлы располагают- ся в одном и том же каталоге. В реальной жизни действительно целесообразно задавать файлы ключей явно, особенно если вы часто меняете ключи и должны быть уверены, что команды используют правильные ключи. Как только ваша зона подписана, остается лишь указать ваш сервер имен в подписан- ных версиях зонных файлов. Если вы используете сервер BIND, поищите инструкцию zone, соответствующую каждой зоне в файле named.conf, и измените параметр file с example. com на example. com. signed. Для сервера NSD соответствующий файл кон- фигурации называется nsd. conf, и вы должны найти в нем строки zonefiles. В заключение перезапустите демон сервера имен, заставив его прочитать снова свой файл конфигурации. Для сервера BIND следует выполнить команды sudo rndc reconfig и sudo rndc flush, а для сервера NSD — команды sudo nsdc rebuild И sudo nsdc restart. Теперь мы обслуживаем подписанную зону DNSSEC! Для того чтобы внести изме- нения, вы можете отредактировать либо исходный неподписанный зонный файл, либо подписанный зонный файл, а затем переподписать зону. Редактирование подписанной зоны иногда оказывается чрезвычайно сложной задачей, но это проще, чем повторное подписание всей зоны. Удалите записи RRSIG, соответствующие всем изменяемым за- писям. Для того чтобы избежать путаницы между версиями, вероятно, следует внести идентичные изменения в неподписанную зону. При передаче подписанной зоны в качестве аргумента команде dnssec-signzone или Idns-signzone все неподписанные записи подписываются, а подписи всех за- писей, срок действия которых подходит к концу, обновляются. Выражение “срок дей- ствия подходит к концу” означает, что прошло три четверти периода действия подписи. Повторное подписание, как правило, приводит к изменениям, поэтому следует изме- нить порядковый номер зоны вручную или автоматически с помощью сервера BIND, используя раздел -N increment в командной строке dnssec-signzone. Это все, что касается локальной части конфигурации протокола DNSSEC. Осталось только решить трудную проблему: соединить наш безопасный “DNS-островок” с дру- гими надежными и подписанными частями иерархии DNS. Мы должны либо передать наши записи DS в подписанную родительскую зону, либо использовать динамическую проверку доменов. Решение этих задач описывается в следующем разделе.
704 Часть II. Работа в сети Цепочка доверия в протоколе DNSSEC Продолжим наш пример, связанный с настройкой протокола DNSSEC. Сайт example. com теперь подписан, и его серверы имен поддерживают протокол DNSSEC. Это значит, что при отправке запросов они используют протокол EDNS0, расширенный протокол DNS, а в DNS-заголовке пакета устанавливают опцию, включающую прото- кол DNS. Отвечая на запросы, которые приходят с такой комбинацией установленных битов, они включают в свой ответ подписанные данные. Клиент, получающий подписанные запросы, может оценить корректность ответа, проверив его подпись с помощью соответствующего открытого ключа. Однако он по- лучает свой ключ из своей собственной зонной записи DNSKEY, что, если вдуматься, довольно подозрительно. Что может помешать постороннему лицу предоставить ложные записи и ложный публичный ключ, чтобы пройти проверку? Есть несколько вариантов ответа на этот вопрос. Ваш сайт должен реализовать хотя бы один из них. В противном случае вся ваша работа по настройке протокола DNSSEC пойдет насмарку. Каноническое решение заключается в том, чтобы передать вашей родительской зоне запись DS, которую она должна включить в свой зонный файл. Запись DS, приходящая из родительской зоны, сертифицируется родительским закрытым ключом. Если клиент доверяет своей родительской зоне, он должен верить в то, что запись DS родительской зоны правильно отражает открытый ключ вашей зоны. В свою очередь, родительская зона сертифицируется своей родительской зоной и так вплоть до корня. После развертывания протокола DNSSEC в полном масштабе един- ственным ключом, который вы должны будете знать заранее, будет открытый ключ, ис- пользуемый для подписи корня. Этот ключ может находиться в файле подсказок корня и использоваться во всем процессе функционирования системы DNS. Если вам повезло и ваша родительская зона подписана, просто передайте ее адми- нистратору свою запись DS и запись DNSKEY, предназначенную для подписи ключей и использованную для подписи записи DS.37 Флаг -д команды dnssec-signzone в пакете BIND генерирует файлы dsset-domain и keyset-domain, которые можно безопасно передать родительской зоне, чтобы она добавила их в свой зонный файл. Аналогично команда Idns-keygen генерирует требуемую DS-запись в файле .ds и запись DNSKEY в файле . key во время генерирования ключей. Помните, что вы должны опубликовать свою запись DNSKEY в своей зоне до того, как родительская зона инсталлирует соот- ветствующую запись DS. Если ваша родительская зона не подписана, необходимо как-то иначе доказать внеш- нему миру, что открытый ключ, опубликованный в вашей системе DNS, действительно принадлежит вам. Это можно сделать тремя разными способами. • Опубликуйте свой открытый ключ с помощью одного или нескольких репозита- риев доверительных точек (trusted anchor repository — TAR); например, с помощью репозитория SecSpider. Для того чтобы использовать ключи TAR на своих серве- рах, получите список ключей от репозитариев SecSpider, ITAR (поддерживается организацией IANA и содержит только домены TLD) или RIPE-NCC (содержит только свои собственные зоны, в основном европейские домены TLD и реверсные зоны). Поместите эти ключи в раздел trusted-keys в конфигурационном файле своего сервера имен. 37 Как узнать, подписана ли родительская зона? Выполните команду dig + dnssec или drill -D.
Глава 17. Система доменных имен 705 • Используйте сервер динамической проверки доменов, например сервер, поддер- живаемый консорциумом ISC (Internet Systems Consortium). По существу, этот сервер делает сайт isc. org вашим приемным DNS-родителем. Это легко и про- сто; см. isc. org/ops/dlv. Существуют и другие серверы DLV, но поскольку ис- пользовать можно только один из них, а сервер консорциума ISC очень хорошо продуман и превосходно работает, предпочесть следует именно его. • Используйте демон Vantages (vantage-points. org), который взаимодействует со своими копиями, принадлежащими друзьям, которым вы доверяете, формируя тем самым социальную сеть демонов. Эти демоны могут получать ключи от других сайтов в Интернете совершенно независимо друг от друга и сравнивать их, чтобы определить, являются ли они аутентичными. Решение, связанное с использованием серверов DLV, мы опишем более подробно в следующем разделе. Однако помните, что все три способа, перечисленные выше, явля- ются временными решениями, которые предназначены для того, чтобы облегчить раз- вертывание протокола DNSSEC. Если ваша родительская зона уже подписана, о них можно даже не упоминать. Просто передайте вашей родительской зоне свою запись DS. Сервер DLV: динамическая проверка доменов Кеширующий сервер, поддерживающий протокол DNSSEC и получающий подпи- санный ответ на запрос, сначала проверяет, совпадает ли подпись записи с открытым ключом домена, заданным его записью DNSSEC. Затем клиент пытается проверить сам ключ, просматривая родительскую зону в поисках записи DS. Если запись DS недоступ- на, клиент ищет запись DLV в исходном домене; эта запись переадресовывает его на сайт div. isc. org или другой сервер DLV, который действует как родитель зоны. Как только клиент получит запись DLV от сайта div. isc. org, он сможет проверить всю цепочку доверия. Следовательно, настройка службы DLV для вашей зоны сводится к ге- нерированию правильных записей DLV и размещению их в правильных местах. Запись DLV на самом деле представляет собой замаскированную запись DS. Типы этих записей отличаются, но тела совпадают. Поле имя в записи также изменяется, что- бы поместить запись в зоне провайдера службы DLV. Например, имя example. com мо- жет стать example.com.div.isc.org. В пакете BIND команда dnssec-signzone -1 (строчная буква L) генерирует запись DLV. $ sudo dnssec-signzone -1 dlv.isc.org example.com Эта команда повторно подписывает зону и создает файл с именем divset-example, com, содержащий запись DLV, предназначенную для зоны провайдера DLV. Пользователи серверов NSD/Unbound должны генерировать записи DLV самостоя- тельно. Скопируйте файл .ds, созданный во время генерирования ключа KSK и изме- нения типа записи с DS на DLV. Затем измените поле имя. Например, измените запись example.com 3600 IN DS 25069 1 1 Odbf80886b716863de09... на example.com.div.isc.org 3600 IN DLV 25069 1 1 Odbf80886b716863de09... Внесенные изменения выделены полужирным шрифтом. Собрав запись DLV и файлы ключей, использованных для подписания вашей зоны, зайдите на веб-страницу div. isc.org и выполните инструкции, благодаря которым сервер isc.org станет вашим DLV-сервером. Консорциум ISC заставит вас проходить
706 Часть II. Работа в сети несколько этапов проверки, чтобы убедиться, что вы действительно владеете своим доменом, имеете право им управлять и безопасно предоставили его открытый ключ. Однако это не сложная процедура. Консорциум ISC вставит несколько строк в раздел trusted-keys вашего файла named. conf. trusted-keys { dlv.isc.com 257 3 5 "хешированная информация о ключе"; dlv.isc.com 257 3 5 "хешированная информация о другом ключе"; } Пользователи сервера BIND тоже добавляют одну строку в раздел option файла named. conf. dnssec-lookaside "." trusted-anchor "dlv.isc.org" Пользователи сервера NSD должны добавить запись DLV в зону и заново подписать зону. Для того чтобы подключить проверку с помощью записи DLV и сервера unbound, получите KSK-запись DNSKEY с веб-сайта div. isc.org или сайта SecSpider и про- верьте их подписи. (Программа SecSpider проверяет согласованность ключей, получен- ных из разных мест.) Не следует просто применять команду dig к ключу. Это небезопас- но, пока протокол DNSSEC не развернут в полном масштабе. Поместите ключ в файл, находящийся в рабочем каталоге сервера unbound, например в каталоге dlv.isc.org. key, и добавьте строку dlv-anchor-file: "div.isc.org.key" в раздел server файла unbound. conf. Смена ключей DNSSEC Для протокола DNSSEC смена ключей всегда была трудной задачей. Его исходные спецификации были, по существу, изменены, для того чтобы решить проблемы, связан- ные с обеспечением взаимодействия между родительской и дочерней зонами для созда- ния, изменения или удаления ключей. Новые спецификации называются DNSSEC-bis. Смена ключей ZSK представляет собой относительно несложную задачу и не преду^ сматривает наличия родительской зоны или какой-либо точки доверия. Единственный “скользким” местом является расписание. Ключи имеют определенный срок действия", поэтому их замену необходимо производить до истечения этого срока. Однако ключи имеют период TTL, определенный в зонном файле. Для иллюстрации предположим, что период TTL равен одному дню и что ключи на следующей неделе еще будут действовать. Придется выполнить следующие действия. • Сгенерировать новый ключ ZSK. • Включить его в зонный файл. • Подписать или заново подписать зону с помощью ключа KSK или старого ключа ZSK. • Попросить сервер имен перезагрузить зону; теперь в ней будет действовать новый ключ. • Подождать 24 часа (период TTL); теперь все могут использовать как старый ключ, так и новый. • Подписать зону снова с помощью ключа KSK и нового ключа ZSK.
Глава 17. Система доменных имен 707 • Попросить сервер имен перезагрузить зону. • Подождать 24 часа; теперь все имеют новую зону. • Удалить старый ключ ZSK, например, при следующем изменении зоны. Эта схема называется предварительной публикацией (prepublishing). Совершенно очевидно, что до того, пока все будут использовать новый ключ, приходится запускать этот процесс как минимум дважды после истечения двух периодов TTL. Эти периоды ожидания гарантируют, что любой сайт с кешированными значениями всегда будет иметь кешированный ключ, соответствующий этим кешированным данным. Еще одной переменной, которая влияет на этот процесс, является время, которое по- требуется вашему самому слабому подчиненному серверу для обновления своей копии в вашей зоне после получения уведомления от главного сервера. По этой причине не следует ждать до последней минуты, чтобы начать процесс смены ключей или повторно- го подписания зон, срок действия подписей которых истек. Просроченные подписи не- действительны, поэтому сайты, проверяющие подписи DNSSEC, не смогут выполнить поиск для вашего домена. Механизм смены ключей KSK называется двойным подписанием (double signing) и также довольно прост. Однако вам придется переслать вашу новую запись DS роди- тельской зоне или послать запись DLV своему “суррогатному родителю”. Убедитесь, что родительская зона или репозиторий точек доверия вас признали, прежде чем переклю- читься на новый ключ. Процесс смены ключей KSK состоит из следующих этапов. • Создать новый ключ KSK. • Включить его в зонный файл. • Подписать зону и новым, и старым ключами KSK и ZSK. • Попросить сервер имен перезагрузить зону. • Подождать 24 часа (период TTL); теперь у всех есть новый ключ. • Уведомить все точки доверия о новом значении KSK. • После подтверждения удалить старую запись KSK из зоны. • Заново подписать зону новыми ключами KSK и ZSK. Инструменты DNSSEC Кроме комплектов инструментов, входящих в дистрибутивные наборы пакетов BIND и NSD/Unbound, есть еще четыре комплекта инструментов для развертывания прото- кола DNSSEC и тестирования существующих настроек: Idns, Sparta, RIPE и Vantages. По крайней мере, еще два комплекта инструментов находятся на этапе разработки: OpenDNSSEC (opendnssec.org) и DNSSHIM. Инструмент OpenDNSSEC должен устранить всю путаницу и сложность, автоматически возникающую при использовании протокола DNSSEC, что звучит обнадеживающе. Инструмент DNSSHIM — это реали- зация авторитетного сервера DNS с автоматической конфигурацией подчиненных сер- веров и программами для работы по протоколу DNSSEC, написанными на языках Java и Python. Инструменты Idns, nlnetlabs.nl/projects/ldns По словам сотрудников компании NLnet Labs, Idns — это библиотека программ для разработки инструментов DNS, включающая примеры, демонстрирующие использова- ние этой библиотеки. Эти инструменты перечислены ниже вместе с кратким описани-
708 Часть II. Работа в сети ем каждого из них. Все они находятся в каталоге examples, за исключением утилиты drill, имеющей свой собственный каталог в дистрибутивном пакете. Команды сопро- вождаются справочными страницами. Файл README, относящийся к верхнему уровню иерархии каталогов, содержит очень краткие инструкции по инсталляции. • Idns-keygen генерирует пары ключей TSIG и DNSSEC. • Idns-signzone подписывает зонный файл с записью NSEC или NSEC3. • Idns-verify-zone проверяет состояние записей RRSIG, NSEC или NSEC3. • ldns-key2ds преобразовывает запись DNSSEC в запись DS. • Idns-rrsig распечатывает в удобном для чтения виде даты истечения сроков дей- ствия ключей из записей RRSIG. • ldns-nsec3-hash распечатывает запись NSEC для заданного имени в хеширо- ванном виде. • 1 dns-revoke устанавливает флаг отмены для ключа RR в протоколе DNSSEC (см. документ RFC54011). • Idns-chaos показывает идентификатор сервера имен, хранящийся в классе CHAOS. • Idns-keyfetcher извлекает открытые ключи DNSSEC для зон. • Idns-read-zone читает зону и распечатывает ее в разных форматах. • Idns-update посылает пакет динамического обновления. • Idns-walk совершает обход зоны, используя записи NSEC протокола DNSSEC. • Idns-zsplit разбивает зону на фрагменты, чтобы подписывать их параллельно. • Idns-zcat объединяет зонные файлы, разбитые утилитой Idns-zsplit на фраг- менты. • Idns-compare-zones демонстрирует разницу между двумя зонными файлами. • Idns-notify проверяет обновления подчиненных серверов зон. • Idns-dpa анализирует пакеты DNS с помощью файлов слежения tcpduxnp. Многие из этих инструментов очень просты и выполняют только одну рутинную операцию для системы DNS. Они были написаны в качестве примеров использования библиотеки Idns и демонстрируют, насколько простым становится код, когда библиоте- ка берет всю тяжелую работу на себя. Инструменты Sparta, dnssec-tools.org Комплект инструментов Sparta создан на основе инструментов сервера BIND, пред- назначенных для поддержки протокола DNSSEC, и включает в себя следующие команды. • zonesigner генерирует ключи и подписи зон. • donuts анализирует зонные файлы в поисках ошибок и несоответствий. • donutsd выполняет команду donuts через определенные интервалы времени И предупреждает о проблемах. • rollerd, rollctl и rollinit осуществляют автоматическую смену ключей, ис- пользуя схему предварительной публикации для ключей ZSK и метод двойного подписания для ключей KSK. • trustman управляет точками доверия и включает реализацию смены ключей RFC5011.
Глава 17. Система доменных имен 709 • dnspktflow отслеживает поток пакетов DNS в последовательности запросов и от- ветов, перехваченных командой tcpdump, и создает диаграмму. • mapper отображает зонные файлы, демонстрируя защищенные и незащищенные фрагменты. • validate — инструмент для проверки подписи из командной строки. Веб-сайт содержит хорошую документацию и учебные пособия для всех этих инстру- ментов. Исходный код доступен для загрузки и защищен лицензией BSD. Компания Sparta поддерживает библиотеки DNSSEC, написанные на языке Perl и распространяемые в сети CPAN (Comprehensive Perl Archive Network). Кроме того, она распространяет “заплатки” для нескольких популярных пакетов программного обеспе- чения (включая Firefox, Thunderbild, Postfix, sendmail, libSPF и OpenSSH), чтобы обе- спечить их более полную совместимость с протоколом DNSSEC. Инструменты RIPE, rlpe.net Инструменты компании RIPE функционируют как внешний компонент инструмен- тов пакета BIND, предназначенных для поддержки протокола DNSSEC, и основное внимание уделяют вопросам управления. Их подробные сообщения, при выполнении и упаковке многих аргументов и команд, имеют более понятную форму. Инструменты Vantages, vantage-polnts.org Vantages — это каркас для распределенного мониторинга, база которого находится в университете штата Колорадо (Colorado State University). В настоящее время он сосре- доточен на операционных вопросах, связанных с протоколом DNSSEC. Инструменты Vantages могут помочь при развертывании протокола DNSSEC. Главным продуктом проекта является инструмент vantaged, демон, собирающий записи DNSSEC и сравнивающий их значения с аналогичными записями, полученны- ми от других демонов vantaged, находящихся в Интернете. Если множество демонов vantaged дают один и тот же ответ, то ключ считается правильным. Для того чтобы достичь этого результата обманным путем, злоумышленник должен был бы заставить все сайты, выполняющие программное обеспечение Vantage, дать неправильный ответ. Демон vantaged собирает ключи от источников DNS, НТТ и HTTPS и классифицирует их по четырем состояниям: подтвержденный, временный, неизвестный и конфликтный. Он добавляет подтвержденные ключи в раздел trusted-keys в файле named, conf. Инструменты Vantages имеют несколько дополнительных функций. • d-sync — отслеживает согласованность ключей в записях DS между родительской и дочерней зонами, что особенно полезно при смене ключей. • dnsfunnel определяет максимальную пропускную способность линии связи меж- ду вами и любым другим сайтом. Он напоминает инструмент traceroute. • dnskey-grab получает ключи DNSKEY для зоны от ее авторитетных серверов. Отладка протокола DNSSEC Протокол DNSSEC был разработан для того, чтобы обеспечить взаимодействие меж- ду подписанными и неподписанными зонами, а также между серверами имен, поддер- живающими протокол DNSSEC и игнорирующими его. Следовательно, возможно по- степенное развертывание протокола, что часто и происходит, хотя и не всегда.
710 Часть II. Работа в сети DNSSEC — это распределенная система с многочисленными изменчивыми частями. Все проблемы порождают авторитетные серверы, распознаватели клиентов и линии свя- зей между ними. Проблема, которая кажется локальной, может отразиться на удаленном пользователе, поэтому такие инструменты, как SecSpider и Vantages, отслеживающие распределенное состояние системы, могут оказаться очень полезными. Эти инструмен- ты, а также утилиты, перечисленные выше, и регистрационные файлы вашего сервера имен являются основными орудиями отладки. Сначала убедитесь, что вы записали категорию регистрации по протоколу DNSSEC из файла named, conf в файл на локальном компьютере. Полезно отделить все сообще- ния, связанные с протоколом DNSSEC, чтобы не записывать в этот файл никаких дру- гих категорий регистрации. Рассмотрим пример регистрационной спецификации для демона named. channel dnssec-log { file "/var/log/named/dnssec.log" versions 4 size 10m ; print-time yes ; print-category yes ; print-severity yes ; severity debug 3; } category dnasec { dnssec-log;} В пакете BIND следует установить уровень отладки равным 3 или выше, чтобы уви- деть этапы проверки, выполняемые рекурсивным сервером BIND при попытках прове- рить подпись. Этому уровню регистрации соответствует две страницы регистрационной информации для одной проверяемой подписи. Если вы отслеживаете работу загружен- ного сервера, то регистрационная информация от нескольких запросов будет переме- жаться другими данными. Разбираться в этой путанице — очень сложная и утомитель- ная задача. Для серверов NSD и Unbound следует установить уровень детальности сообщений в их конфигурационных файлах выше, чем заданный по умолчанию (0 и 1 соответствен- но). Для сервера Unbound достаточно настроить уровень детальности сообщений “на лету” с помощью команды verbosity уровень в команде unbound-control. Подобно серверу BIND, уровень отладки на сервере Unbound должен быть установлен равным 3, чтобы продемонстрировать этапы проверки подписи. Если все работает хорошо, установите параметр val-log-level на сервере Unbound равным 1, чтобы распечатывать сообщения об ошибках для каждой неправильной под- писи в виде одной строки. Этот уровень детальности поможет вам найти сайты, вызы- вающие проблемы. Затем вы можете отследить причины проблем для каждой подпи- си с помощью либо команды drill, либо команды unbound-host -v -d (иди даже -dddd, чтобы получить больше отладочной информации). При этом командам drill и unbound-host необходимо передать релевантные открытые ключи. Команда drill имеет два особенно полезных флага: -т — для отслеживания цепоч- ки доверия от корня до указанного узла и -S — для отслеживания подписей от указанного узла обратно к корню. Рассмотрим практический пример вывода, полученного от коман- ды drill -S, позаимствованный из документа DNSSEC HOWTO компании NLnet Labs. $ drill -s -k ksk.keyfile exanple.net SOA DNSSEC Trust tree: example.net (SOA) I--example.net. (DNSKEY keytag: 17000) I---example.net. (DNSKEY keytag: 49656)
Глава 17. Система доменных имен 711 I---example.net. (DS keytag: 49656) I—net. (DNSKEY KEYTAG: 62972) . |--net. (DNSKEY KEYTAG: 13467) I—net. (DS KEYTAG: 13467) I---. (DNSKEY KEYTAG: 63380) I--net. (DNSKEY KEYTAG: 63276) ;; Chase successful Если сервер имен, выполняющий проверку, не может проверить подпись, он возвра- щает сигнал SERVFAIL. Проблема может заключаться в неправильной конфигурации одной из зон, входящих в цепочку доверия, в фальшивых данных, поступивших от злоу- мышленника, или в настройке самого рекурсивного сервера, выполняющего проверку. Попробуйте выполнить команду drill и отследить подписи вдоль цепочки доверия, чтобы обнаружить источник проблемы. Если все подписи окажутся верифицированны- ми, то попытайтесь послать запрос проблемному сайту с помощью команды dig, а затем dig +cd. (Флаг cd отключает проверку подписей.) Примените их к каждой зоне, входя- щей в цепочку доверия, чтобы выяснить, в чем проблема. Вы можете перемещаться по цепочке доверия как вверх, так и вниз. Чаще всего причиной ошибки становятся уста- ревшие точки доверия или просроченные подписи. 17.14. Microsoft и DNS Многие годы консорциум ISC и группа разработчиков сервера BIND стремились обе- спечить взаимодействие с инструментами DNS, разработанными компанией Microsoft и ее службой Active Directory. Компанию Microsoft обвиняли в преднамеренном отклоне- нии от стандартов и отказе от документирования используемых ею расширений прото- колов. Однако оказалось, что компания Microsoft на самом деле не пыталась избежать совместимости; ее специалисты просто были несколько некомпетентными и работали с неправильным программным обеспечением (их собственным кодировщиком ASN.1 и синтаксическим анализатором), которое искажало пакеты настолько, что сервер BIND просто не мог в них разобраться. Теперь все в порядке. Ошибки исправлены, и сервер BIND совместно с компанией Microsoft следуют протоколу IETF и могут взаимодей- ствовать. Это хорошие новости. Плохая новость заключается в том, что служба Active Directory тесно интегрирована с протоколами Kerberos и LDAP и следует своими собственными извилистыми путями (которые похожи друг на друга!) Замена любого из фрагментов, например центра рас- пределения ключей Kerberos, на совместимую реализацию с открытым исходным кодом обречена на неудачу. Сервер BIND может выполнять аутентификацию с помощью служ- бы Active Directory, используя протокол GSS-TSIG, но авторизация остается практиче- ски невозможной, потому что служба Active Directory хранит всю информацию в базе данных LDAP. Советы, касающиеся обеспечения взаимодействия со службой Active Directory, мож- но найти в главе 30. 17.15. Тестирование и отладка Серверы BIND и NSD/Unbound предоставляют три основных инструмента для от- ладки: журнальная регистрация, управляющая программа и инструмент запросов их ко- мандной строки. Наиболее глубоко разработанными, но и наиболее сложными являются инструменты сервера BIND.
712 Часть II. Работа в сети Журнальная регистрация в пакете BIND Ш Система Syslog описывается в главе 11. Возможности подсистемы журнальной регистрации демона named действительно впечатляют. Сервер BIND использует систему Syslog для записи сообщений об ошиб- ках и аномалиях. В новейших версиях концепция журнальной регистрации обобщена: добавлен еще один уровень переадресации и поддерживается направление сообщений непосредственно в файлы. Прежде чем переходить к деталям, приведем мини-словарь терминов, связанных с журнальной регистрацией в пакете BIND (табл. 17.13). Таблица 17.13. Лексикон пакета BIND IjBpMHH : Ул//-/ //., л: Канал Место, куда направляются сообщения, — система Syslog, файл или устройство /dev/nullа Категория Класс сообщений, генерируемых демоном named, например сообщения о динамических об- новлениях или об ответах на запросы Модуль Имя исходного модуля, который сгенерировал сообщение Средство Название средства системы Syslog; за DNS не закреплено собственное средство, но можно выбрать любое стандартное Важность Степень важности сообщения об ошибке а /dev/nall/ — псевдоустройство, отбрасывающее все входящую информацию. Подсистема журнальной регистрации конфигурируется при помощи инструкции logging в файле named, conf. Сначала определяются каналы — возможные пункты до- ставки сообщений. Затем для различных категорий сообщений задаются каналы, куда они будут поступать. При формировании сообщения ему назначаются категория, модуль и уровень важно- сти. После этого оно рассылается по всем связанным с категорией и модулем каналам. В каждом канале имеется фильтр, определяющий, сообщения какого уровня важности можно пропускать. Каналы, ведущие в систему Syslog, подвергаются дополнительной фильтрации в соответствии с правилами, установленными в файле /etc/syslog.conf. Общий вид инструкции logging таков. logging { определение_канала определение_канала category имя_категории { имя_канала имя_канала }; }; Каналы Аргумент определение_канала выглядит по-разному, в зависимости от того, ведет ли он к файлу или к системе Syslog. Для каждого канала необходимо выбрать либо тип file, либо тип syslog; совмещать их канал не может.
Глава 17. Система доменных имен 713 channel имя_канала { file путь [versions число_версий | unlimited] [size размер]; syslog средство; severity важность; print-category yes | no; print-severity yes | no; print-time yes | no; }; Для файлового канала аргумент число_версий сообщает о том, сколько резервных копий файла нужно хранить. Аргумент размер задает предельно допустимый размер файла (например, 2048, 100k, 20m, 15g, unlimited, default), по достижении кото- рого произойдет автоматическая ротация. К примеру, если файловый канал называется mylog, то в процессе ротации появятся версии mylog.0, mylog. 1 и т.д. Для каналов системы Syslog задается имя средства, указываемое при регистрации со- общений. Это может быть любое стандартное средство, но на практике единственным разумным выбором являются средства daemon и localO—1оса17. Ш Список средств системы Syslog приводился в главе 11. Остальные разделы в определении канала являются необязательными. Аргумент важность может принимать следующие значения (в порядке уменьшения приоритета): critical, error, warning, notice, info и debug (здесь может добавляться номер уровня, например severity debug 3). Значение dynamic соответствует текущему уров- ню отладки сервера. Параметры print устанавливают или отменяют вывод различных префиксов сооб- щений. Система Syslog вставляет перед каждым сообщением метку времени, а также имя узла, но не уровень важности или категорию. Существует также параметр, позволяющий отображать имя исходного файла (модуля), сгенерировавшего сообщение. Параметр print-time рекомендуется включать только для файловых каналов, поскольку в Syslog произойдет ненужное дублирование информации. В табл. 17.14 перечислены четыре канала, которые определены по умолчанию. В боль- шинстве случаев создавать новые каналы не требуется. Таблица 17.14. Стандартные каналы журнальной регистрации пакета BIND Имя канала default_syslog Направляет сообщения уровня info и выше в систему Syslog от имени средства daemon default_debug Направляет сообщения в файл named.run; уровень важности устанавливается рав- ным dynamic default_stderr Направляет сообщения в стандартный канал ошибок демона named с уровнем важ- ности info null Отбрасывает все сообщения Категории В момент создания программы категории определяются программистом. Они орга- низовывают сообщения по темам или функциональным возможностям, а не по важно- сти. В табл. 17.15 приведен текущий список категорий сообщений.
714 Часть II. Работа в сети Таблица 17.15. Категории сообщений пакета BIND Категория Чтоохватывав^'*, client Клиентские запросы config Ошибки анализа и обработки конфигурационного файла database Сообщения об операциях с базой данных default Категории, для которых не был явно назначен канал delegation-only Запросы, посланные в NXDOMAIN зонами, выполняющими только делегирование dispatch Диспетчеризация входящих пакетов среди модулей сервера dnssec Сообщения протокола DNSSEC edns-disabled Информация о серверах, вышедших из строя general Неклассифицированные сообщения lame-servers Сообщения о серверах, которые, как предполагается, обслуживают зону, но на самом деле это не така network Сетевые операции notify Сообщения об изменениях зон queries Короткое сообщение для каждого (!) запроса, принимаемого сервером resolver Операции преобразования имен, например рекурсивный поиск, выполняемый от имени клиента security Принятые или непринятые запросы unmatched Запросы, которые демон named не может классифицировать (неправильный класс, нет представления) update Сообщения о динамических обновлениях update-security Одобрение или отклонение запросов на обновление xfer-in Сообщения о зонных передачах, принимаемых сервером xfer-out Сообщения о зонных передачах, отправляемых сервером a Это может быть как родительская, так и дочерняя зона. Журнал запросов Стандартный вид инструкции logging таков. logging { category default { default_syslog; default_debug; }; }; После внесения существенных изменений в систему BIND необходимо просматри- вать журнальные файлы; возможно, стоит также повышать уровень отладки. После того как демон named вернется в стабильное состояние, настройте систему так, чтобы реги- стрировались только важные сообщения. Журнал запросов — источник весьма полезной информации. На его основании мож- но проверить, работают ли директивы allow, узнать, кто посылает вам запросы, иден- тифицировать неправильно сконфигурированных клиентов и т.д. Для того чтобы включить режим регистрации запросов, назначьте категории queries какой-нибудь канал. Регистрация в системе Syslog менее эффективна, чем непосред- ственно в файле, поэтому при регистрации каждого запроса создайте файловый канал, связанный с локальным диском. Зарезервируйте для журнала достаточно дискового про-
Глава 17. Система доменных имен 715 странства и будьте готовы отключить регистрацию, когда накопится достаточный объем данных (команда rndc querylog включает и отключает регистрацию запросов). Иногда отладка представления является довольно сложной задачей, но, к счастью, представление, соответствующее конкретному запросу, можно занести в журнал вместе с запросом. Ниже перечислены наиболее часто регистрируемые сообщения. • Неправильно сконфигурированный сервер (“Lame server resolving ххх”). Если подобное сообщение поступает от одной из внутренних зон, значит, в конфигурации систе- мы имеется ошибка. Если же в сообщении говорится о какой-то зоне в Интернете, то можно не беспокоиться: это “чужая” ошибка. Сообщения второго вида вполне можно отбрасывать, направляя их в канал null. • Отклонение запроса (“...query (cache) ххх denied”). Причиной этого сообщения мо- жет быть неправильная конфигурация удаленного сайта, нарушение правил или ситуация, в которой некто делегировал вам зону, но вы ее не конфигурировали. • Просроченное время при распознавании: отключение EDNS (too many timeouts resol- ving ххх: disabling EDNS). Это сообщение может возникнуть вследствие отказа брандмауэра, не пропускающего пакеты UDP, размер которых превышает 512 байт, и не допускающего фрагментирование. Кроме того, оно может свидетельствовать о проблемах на конкретном узле. Следует убедиться, что проблема не связана с ва- шим брандмауэром, и рассмотреть возможность переадресации этих сообщений в нулевой канал. • Неожиданное распознавание RCODE (SERVFAIL) (unexpected RCODE (SEVFAIL) resolving ххх). Это сообщение может быть признаком атаки или, что более вероят- но, сигналом о том, что кто-то постоянно посылает запросы к неправильно скон- фигурированной зоне. • Неправильная отсылка (“Bad referral”). Это сообщение свидетельствует о непра- вильном взаимодействии серверов имен зоны. • Неавторитетен (“Not authoritative for”). Подчиненный сервер не может получить авторитетные данные о зоне. Возможно, у него хранится неправильный адрес главного сервера или же тот не смог загрузить зону. • Зона отклонена (“Zone rejected”). Демон named отказался загружать зонный файл, поскольку тот содержит ошибки. • Не найдены записи NS (“No NS RR for”). В зонном файле после записи SOA не найдены записи NS. Возможно, они отсутствуют либо не начинаются с табуляции или какого-нибудь другого пробельного символа. Во втором случае они не при- соединяются к зоне и, следовательно, интерпретируются неправильно. • Не задано стандартное значение TTL (“No default TTL set”). Желательно задавать стандартное значение TTL посредством директивы $TTL, располагаемой в начале зонного файла. Ошибка свидетельствует о том, что такая директива отсутствует. В версии BIND 9 наличие этой директивы обязательно. • Нет корневых серверов имен для класса (“No root nameservers for class”). Демону named не удается найти корневые серверы имен. Следует проверить файл корне- вых “подсказок” и подключение сервера к Интернету. • Адрес уже используется (“Address already in use”). Порт, который нужен для работы демона named, занят другим процессом, возможно, другой копией демона. Если
716 Часть II. Работа в сети демон отсутствует в списке выполняющихся процессов, то, очевидно, он перед этим аварийно завершил свою работу и оставил открытым управляющий сокет утилиты rndc, который нужно найти и удалить. Хороший способ устранить про- блему — остановить процесс с помощью утилиты rdnc и перезапустить процесс named. • % sudo rdnc stop • % sudo /usr/sbin/named . .. • Обновление запрещено (“Denied update from...”). Имела место попытка динамиче- ского обновления зоны, которая была отвергнута вследствие установки al low- update или update-policy для зоны в файле named.conf. Это очень рас- пространенное сообщение об ошибке, которая часто вызывается неправильной конфигурацией системы Windows. Пример конфигурации журнала запросов в пакете BIND Приведенный ниже фрагмент взят из файла named, conf одного из загруженных сер- веров имен TLD и представляет собой полную конфигурацию журнала запросов. logging channel default_log { # Default channel, to a file file "log/named.log" versions 3 size 10m; print-time yes; print-category yes; print-severity yes; severity info; }; channel xfer-log { # Zone transfers channel, to a file file "log/xfer.log" versions 3 size 10m; print-time yes; print-category yes; print-severity yes; severity info; }; channel dnssec-log { # DNSSEC channel, to a file file "log/dnssec.log" versions 3 size 10m; severity debug 1; print-severity yes; print-time yes; }; category default { default_log; defaula_debug; } category dnssec { dnssec-log; } category xfer-in { xfer-log; } category xfer-out { xfer-log; } category notify { xfer-log; } }; Уровни отладки в пакете BIND Уровни отладки демона named обозначаются целыми числами от 0 до 100. Чем выше число, тем больше текста содержит выходная информация. Уровень 0 выключает отлад- ку. Уровни 1 и 2 отлично подходят для отладки конфигурационного файла и базы дан- ных. Уровни выше 4 предназначены для разработчиков кода демона.
Глава 17. Система доменных имен 717 Отладку можно включить из командной строки, запуская демон named с флагом -d. Например, команда # sudo named -d2 запускает демон named на уровне отладки 2. По умолчанию отладочная информация за- писывается в файл named, run, находящийся в каталоге запуска демона. Этот файл рас- тет очень быстро, поэтому во время отладки будьте внимательны. Отладку можно также включать в процессе работы демона named с помощью ко- манды rndc trace, которая увеличивает уровень отладки на единицу. Команда rndc notrace выключает режим отладки. Кроме того, можно создать канал регистрации со- общений, в определение которого входит строка следующего вида. severity debug 3 Эта строка обеспечивает направление в канал всех отладочных сообщений вплоть до уровня 3. Другие директивы в определении канала указывают на то, куда в конечном итоге попадут сообщения. Чем выше уровень важности, тем больше информации реги- стрируется. Просматривая журнальные файлы и отладочные сообщения, можно заметить, как часто делаются ошибки в конфигурации DNS. Забыв поставить точку в конце имени, можно спровоцировать угрожающий рост трафика DNS. Помните: точка нужна в конце каждого полностью определенного имени домена. Журнальная регистрация в пакетах NSD и Unbound Журнальная регистрация в пакетах NSD и Unbound проста по сравнению с пакетом BIND. В соответствии с файлом doc.README, “пакет NSD не выполняет никакой жур- нальной регистрации”. На самом деле это означает, что пакет NSD не выполняет ника- кой регистрации трафика DNS и мониторинга, тем не менее, он регистрирует важные события, происходящие с программным обеспечением, в системе Syslog. По умолчанию журнальные сообщения выводятся в стандартный поток сообщений об ошибках и в систему Syslog с помощью вспомогательного демона. Однако если атри- бут logfile в инструкции server установлен равным unbound, conf или nsd. conf, то сообщения выводятся в указанный файл. Объем регистрируемых данных (помимо ошибок, которые учитываются всегда) управляется уровнем детализации, который можно задать в файле конфигурации. При работе с демоном unbound уровень детализации можно задать в командной строке. Этот параметр изменяется от 0 до 5; по умолчанию он равен 0 для демона nsd и 1 - для де- мона unbound. Иногда трудно понять, какой уровень детализации следует выбрать для демона nsd. Они классифицируются примерно так. • Уровень 3 — “ошибка” • Уровень 4 — “предупреждение” • Уровень 5 — “замечание” • Уровень 6 — “информация” Описание уровней детализации для демона unbound приведено на справочной стра- нице файла конфигурации. • Уровень 1 — не регистрируется никакая информация, кроме ошибок • Уровень 2 — операционная информация
718 Часть II. Работа в сети • Уровень 3 — детальная операционная информация • Уровень 4 — информация о запросах • Уровень 5 — информация об алгоритмах • Уровень 6 — информация о кеше и идентификации клиента Для того чтобы включить режим отладки, можно вызвать демона nsd с параметром -d. В этом режиме демон nsd получает высокий приоритет, не разветвляется и не прекра- щает работу. Это эквивалентно установке параметра debug-mode: yes в разделе server в файле nds .conf. Если перекомпилировать демона nsd с параметром DEBUG, соот- ветствующим конкретному уровню отладки, то можно получить еще больше отладочной информации, но она по большей части требуется только разработчикам. Демон unbound тоже имеет флаг -d, чтобы включить режим отладки. Уровнем де- тализации можно управлять с помощью параметра -v; чтобы получить еще больше ин- формации, попробуйте комбинацию -v -v. Регистрация отладочной информации за- дается отдельно от детализации регистрационной информации в файле конфигурации. Можно установить дополнительные уровни регистрации, чтобы облегчить процесс про- верки подписи DNSSEC. Управляющие программы сервера имен Все три сервера имен поставляются с управляющими программами: программа nsdc управляет демоном nsd, программа rndc — демоном named, а программа unbound- control — демоном unbound. Программа nsdc работает только на локальном компью- тере, а программы rndc и unbound-control могут работать в Интернете, если их соот- ветствующим образом настроить. Программа rndc использует сетевой сокет для взаимодействия с демоном named и систему аутентификации TSIG для безопасности; программа unbound-control исполь- зует протокол SSL/TLS, а программа nsdc — сигналы. Использование программы rndc в пакете BIND Опции программы rndc перечислены в табл. 17.16. Если напечатать имя програм- мы rndc без аргументов, то она выведет на экран список доступных команд и их крат- кое описание. В предыдущих версиях программы rndc использовались сигналы, как и в программе nsdc. Однако количество доступных команд “перевалило” за 25, поэтому разработчики пакета BIND отказались от использования сигналов. Команды, приводя- щие к созданию файлов, размещают их в каталоге, заданном в файле named.conf как начальный каталог демона named. Таблица 17.16. Команды программы rndc а Команда Назначение dumpdb flush [представление] flushname имя [представление] freeze зона [класс [представление]] thaw зона [класс [представление]] halt Записывает образ базы данных DNS в файл named.dump.db Очищает все кеши или кеши, заданные представлением Удаляет имя из кеша сервера Приостанавливает обновления динамической зоны Возобновляет обновления динамической зоны Останавливает демон named без обработки отложенных об- новлений
Глава 17. Система доменных имен 719 Окончание табл. 17.16 ^Команда Назначение z’i"' ~ querylog Переключает режим трассировки входящих запросов notify зона [класс [представление]] Повторно посылает зоне уведомления notrace Отключает режим отладки reconfig Повторно загружает конфигурационный файл и все новые зоны recursing Записывает текущие рекурсивные запросы в файл named, recursing refresh зона [класс [представление]] Поддерживает расписания для зоны reload Повторно загружает файл named.conf и зонные файлы reload зона [класс [представление]] Повторно загружает только указанную зону или представление restart6 Повторно запускает сервер retransfer зона [класс [представление]] Повторно копирует данные для зоны из главного сервера stats Записывает статистическую информацию в файл named.stats status Отображает на экране текущий статус выполнения демона named stop Сохраняет отложенные обновления и останавливает демон named trace Увеличивает уровень отладки на единицу trace приращение Увеличивает уровень отладки на приращение validation новое.состояние Включает/отключает проверку DNS на лету а Аргумент класс означает то же, что и в случае записей о ресурсах; для Интернета он обычно равен IN. 6 Эта команда еще не реализована в пакете BIND 9 (9.7.0), но разработчики обещают скоро ее реализовать (должно быть, это трудно). Команда rndc reload заставляет демон named заново прочитать конфигурацион- ный файл и повторно загрузить зонные файлы. Команду reload зона удобно приме- нять на интенсивно эксплуатируемом сервере, когда изменению подвергается только одна зона, а остальные трогать не нужно. Кроме того, можно задать параметры класс и представление, чтобы загрузить только указанное представление зонных данных. Обратите внимание на то, что команды rndc reload недостаточно, чтобы доба- вить совершенно новую зону; для этого требуется, чтобы демон named прочитал файл named, conf и новый зонный файл. Для новых зон следует использовать команду rdnc reconfig, которая заново прочитывает файл конфигурации и загружает любую новую зону, не трогая существующие. Команда rdns freeze останавливает динамические обновления и согласовывает журнал динамических обновлений с зонными файлами. После замораживания зоны зонные данные можно редактировать вручную. Поскольку зона заморожена, динамиче- ское обновление происходить не будет. Завершив редактирование, выполните команду rdnc thaw зона, чтобы принимать динамические обновления снова. Команда rndc dumpdb заставляет демон named записать образ своей базы данных в файл named_dump. db. Этот файл очень большой и содержит не только локальные дан- ные, но и данные, накопленные в кеше сервера имен. Версии демона named и программы rndc должны совпадать, иначе будет выдано со- общение о несовпадении версий протокола. Обычно они устанавливаются на один и тот
720 Часть II. Работа в сети же компьютер, и расхождение версий может вызвать проблемы, если демон named пен пытается управлять другим компьютером. I Использование программы nsdc в пакете NSD Управляющая программа nsdc пакета NSD представляет собой оболочку, использую- щую сигналы для управления поведением демона nsd и утилиты zonec, которая прила- гается к предкомпилятору зоны. Поскольку программа nsdc должна выполняться на той же машине, что и демон nsd, ключи не нужны. Как следует из табл. 17.17, программа nsdc имеет меньше команд, чем программа rndc. При выполнении программа nsdc считывает конфигурационный файл nsd. config и использует утилиту nsd-checkconf для проверки синтаксических ошибок. Таблица 17.17. Команды программы nsdc ' -Lj- -п-v t- •• •• - . "> ' vt P '> . start Запускает сервер nsd stop Останавливает сервер nsd (посылает сигнал SIGTERM) reload Повторно загружает базу данных скомпилированной зоны rebuild Повторно создает зонную базу данных с помощью утилиты zonec restart Повторно запускает сервер nsd, т.е. останавливает его, а затем запускает running Проверяет, запущен ли сервер nsd; если все в порядке, никакой информации не выводит update Пытается обновить все подчиненные зоны notify Посылает уведомления всем подчиненным серверам patch Объединяет изменения, связанные с передачей зоны (в базе данных), в зонном файле (текстовом) Использование программы unbound-control Программа unbound-control посылает сообщения серверу имен unbound посред- ством протокола безопасности транспортного уровня TLS (бывшего SSL), который ис- пользует ключ и сертификат для каждого конечного пользователя. Эти ключи конфи- гурируются в разделе remote-control файла конфигурации unbound, conf. Для того чтобы управлять поведением сервера, можно использовать более 20 команд. Вместо пе- речисления всех возможных команд, мы отправляем читателей на справочную страницу программы unbound-control, на которой она подробно описана. Среди этих 20 команд есть обычные команды для запуска, остановки и повторного чтения, но некоторые опции осуществляют очень тонкое управление кешем и локаль- ными зонными данными, которые должны конфигурироваться. Такие опции, как переа- дресовка (forwarding), могут конфигурироваться или модифицироваться на лету. Сбор статистических данных Каждый сервер имен ведет статистику запросов с той или иной степенью детализа- ции. Некоторые опции можно конфигурировать, например можно указать, какие данные регистрировать, где их записывать, как часто обновлять и т.д. Новый статистический ка- нал в пакете BIND является более гибким механизмом. Сервер NSD позиционируется как надежный и быстрый сервер, статистические данные для которого должна собирать другая программа, пока сервер NSD выполняет свою основную работу. Сервер unbound занимает промежуточную позицию.
Глава 17. Система доменных имен 721 Серверы BIND и unbound могут посылать свои статистические данные другим программам для презентации и визуализации. Сервер BIND использует инструкцию statistics-channels и язык XML. Сервер unbound применяет надстройки для ката- лога contrib, обеспечивающие связь с системами мониторинга Munin или Cacti. Демон named накапливает итоговую информацию, которую он может сохранять в файле named, stats в рабочем каталоге демона named в ожидании команды от програм- мы rndc. $ sudo rndc stats Рассмотрим небольшой фрагмент вывода с сервера в домене vix. com. Большая часть информации была отброшена; в файле показаны 20 групп данных, мы приводим лишь две из них. +++ Statistics Dump +++ (1248150900) ++ Incoming Queries ++ 2650862 A 9105 NS 404378 SOA 85744 PTR 246258 MX 3208092 TXT ++ Name Server Statistics ++ 10028960 IPv4 requests received 388015 IPv6 requests received 5890639 requests with EDNS(0) received 92403 TCP requests received 4363730 queries resulted in successful answer 766435 queries resulted in nxrrset 599672 queries resulted in NXDOMAIN Эти статистические данные демонстрируют соотношение успешных и безуспешных проверок и классифицируют разные виды ошибок. Данный сервер получил 10 млн за- просов, большинство из которых имели типы АААА (адрес по протоколу IPv6) и ТХТ (возможно, запросы на записи SF или DKIM). Записи свидетельствуют о довольно ак- тивной деятельности злоумышленников на этом сервере (например, о запросах на неав- торизованную передачу зоны). Вероятно, необычно большое количество запросов типа АААА и ТХТ является частью этой активности — чаще всего запрашивались записи А. Если демон named компилируется с библиотекой XML, то инструкция statistics- channels в файле named, conf устанавливает статистический работающий в реальном времени канал, который пользователь может просматривать с помощью веб-браузера. Отладка с помощью команды dig Команды nslookup, dig, host и drill позволяют в режиме командной строки по- сылать запросы базе данных DNS. Первые три команды входят в дистрибутив BIND, а команда drill — в дистрибутив Unbound/ldns. Команды nslookup и host простые и выдают ясные результаты, но для того чтобы выяснить все детали, необходимы коман- ды dig и drill. Команда drill лучше прослеживает цепочки подписей по протоколу DNSSEC. Имя команды drill обыгрывает имя dig (domain information groper — сред-
722 Часть II. Работа в сети ство сбора информации о доменах)38, подсказывая, что благодаря этой команде можно! получить еще больше информации от системы DNS, чем с помощью команды dig. | По умолчанию команды dig и drill посылают запросы серверам имен, сконфигу-* рированным в файле /etc/resolv.conf. Аргумент @сервер_имен адресует команду конкретному серверу имен. Способность посылать запросы конкретному серверу по- зволяет гарантировать, что любые изменения, вносимые в зону, будут распространены среди подчиненных серверов и во внешнем мире. Это свойство особенно полезно, если вы используете представления (расщепляете DNS) и должны проверять, правильно ли они сконфигурированы. Если указать тип записи, то команды dig и drill будут выполнять запрос толь- ко к этим записям. Псевдотип ANY действует немного неожиданно: вместо того чтобы вернуть все данные, ассоциированные с указанным именем, он возвращает все кеши- рованные данные, связанные с ним. Итак, чтобы получить все записи, необходимо за- дать команду dig домен US, за которой следует выражение dig @nsl. домен. домен ANY. (Авторитетные данные в этом контексте рассматриваются как кешированные.) Команда dig имеет более 50 опций, а команда drill — около половины этого коли- чества. Получив флаг -h, эти команды выдают список всех своих опций. (Для того что- бы упорядочить вывод, можно использовать параметр 1езз.)Для обеих команд опция -х изменяет порядок следования байтов в IP-адресе на противоположный и выполняет обратный запрос. Флаги +trace команды dig и -т команды drill показывают итера- тивные шаги в процессе распознавания, начиная от корня и вниз по дереву иерархии. Мы не приводим примеры вывода с помощью команд dig и drill, поскольку мы использовали их во всей главе при описании разных аспектов системы DNS. Если ответ является авторитетным (т.е. приходит непосредственно от главного или подчиненного сервера данной зоны), то команды dig и drill во флагах вывода исполь- зуют символы аа. Код ad означает, что ответ является аутентичным в смысле протокола DNSSEC. Тестируя новую конфигурацию, следует убедиться, что вам доступны данные как локальных, так и удаленных узлов. Некорректное делегирование Подавая заявку на получение доменного имени, вы просите, чтобы основному серве- ру имен и администратору DNS была выделена (делегирована) часть дерева имен. Если не поддерживать работу домена или изменить адреса серверов имен, не обновив свя- зующие записи родительского домена, будет иметь место так называемое некорректное делегирование (lame delegation). Последствия некорректного делегирования могут оказаться весьма негативными. Если хотя бы один из ваших серверов окажется некорректным, то вся ваша система DNS снизит эффективность работы. Если все серверы имен являются некорректными, то ни один из них не будет доступен. Все запросы будут начинаться с корня, пока от- веты будут кешироваться, поэтому некорректные серверы и неисправное программное обеспечение, которое не делает негативного кеширования ошибок SERVFAL, увеличи- вают нагрузку на каждый узел, находящийся на пути от корня к некорректному домену. Есть два способа выявить некорректное делегирование — просматривая журнальные файлы и используя инструмент под названием doc, которое представляет собой сокра- щение от словосочетания “domain obscenity control” (проверка корректности домена). 38 Dig — копать, a drill — бурить, т.е. проникать глубже. — Примеч. ред.
Глава 17. Система доменных имен 723 Несколько примеров работы утилиты doc мы рассмотрим в следующем разделе, а пока приведем несколько записей из журнальных файлов. На многих сайтах в качестве канала для регистрации указан каталог /dev/null, что- бы не беспокоиться о некорректном делегировании. Это допустимо, если ваш домен на- ходится в полном порядке и не является ни источником, ни жертвой некорректного деле- гирования. Всего лишь один некорректный сервер снижает эффективность работы систе- мы DNS; если все серверы некорректные, то домен практически “взлетает на воздух”. Рассмотрим пример регистрационных записей. Мы сократили вывод, чтобы не за- громождать изложение; флаг +short позволяет сделать вывод команды dig еще более лаконичным. Jul 19 14:37:50 nubark named[757]: lame server resolving 'w3w3.com'(in 'w3w3.com'?): 216.117.131.52#53 Послав с помощью команды dig запрос о серверах имен для домена w3w3. com одно- му из серверов gTLD-домена . сот, мы получим следующую информацию. $ dig @е. gtld-servers. net w3w3. com ns ;; ANSWER SECTION: w3w3.com 172800 IN NS nsO.nameservices.net. w3w3.com 172800 IN NS nsl.nameservices.net. Если же теперь опросить каждый из этих серверов по очереди, задав им этот же во- прос, то мы получим ответ от сервера nsO и не получим ответа от сервера nsl. $ dig @nsO.nameservices.net w3w3.com ns ;; ANSWER SECTION: w3w3.com 14400 IN NS nsO.nameservices.net. w3w3.com 14400 IN NS nsl.nameservices.net. $ dig @nsl.nameservices.net w3w3.com ns ;; QUESTION SECTION: ;; w3w3.com. IN IN ;; AUTHORITY RECORDS: com. 244362 IN NS M.GTLD-SERVERS.NET. com. 244362 IN NS I.GTLD-SERVERS.NET. com. 244362 IN NS E.GTLD-SERVERS.NET. Сервер имен nsl. nameservices.net делегировал ответственность за домен w3w3. com серверам домена . com, но они эту ответственность не приняли. Эта конфигурация является неправильной, и возникло некорректное делегирование. Клиенты, пытающи- еся попасть в домен w3w3. com, будут обслуживаться медленно. Если домен w3w3. com оплачивает услуги DNS домену nameservices. net, то он заслуживает компенсации! Иногда, посылая запрос с помощью команды dig на авторитетный сервер в поисках некорректности, можно не получить никакой информации. В этом случае следует по- пытаться повторить запрос с флагом +norecurse, чтобы можно было увидеть точно, что знает искомый сервер. Инструменты для проверки корректности системы DNS Существует несколько инструментов, позволяющих проверить некоторые аспекты системы DNS. В пакете BIND 9 поставляются утилиты named-checkconf и named- checkzone; они проверяют выполнение основных синтаксических правил (не семанти- ку) в файле named, conf и зонных файлах. Пакеты NSD и Unbound содержат аналогич- ные инструменты под названием nsd-checkconf и unbound-checkconf.
724 Часть II. Работа в сети Оригинальным инструментом для проверки системы DNS является программа nslint, написанная Крейгом Лересом (Craig Leres), когда он работал в компании Lawarence Berkeley Labs. Утилита doc (domain obscenity control) — программа для проверки кор- ректности домена — проверяет делегирование и находит несоответствия и ошибки в раз- вернутой системе DNS. Ниже она обсуждается более подробно. Инструмент lamer (рас- положенный на том же веб-сайте, что и утилита doc) просматривает журнальные файлы и посылает администраторам DNS по электронной почте сообщения о некорректных сайтах, уведомляя их о том, что эти сайты порождают некорректное делегирование, и описывая, как исправить проблему. Утилита DDT, написанная Жоржем Фразао (Jorze Frazao) и Артуром Ромао (Artur Romao), выполняет отладку кешированных данных. Утилита dnswalk проходит по дереву делегирования и идентифицирует несоответ- ствия между родительским и дочерним узлами или между прямыми и обратными запи- сями. Она также находит отсутствующие точки, избыточные связующие записи и т.д. Это средство для поддержания общего порядка в системе DNS. Для успешной работы утилита dnswalk должны иметь возможность выполнять передачу зоны. Некоторые средства отладки и управления протоколом DNSSEC перечислены в раз- деле “Отладка протокола DNSSEC”. Утилита doc реализует основной сценарий, написанный на языке С. В настоящее время ее сопровождение осуществляет Бред Ноулз (Brad Knowls). Эту утилиту можно загрузить с его сайта shub-internet.org/brad/dns (обратите внимание на то, что следует писать “shub”, а не “shrub”). Если вы планируете указать утилиту doc в своем разделе PATH или запустить ее с помощью планировщика задач cron, то должны от- редактировать сценарий и установить переменную auxd так, чтобы она указывала на ка- талог инсталляции. Утилита doc проверяет делегирование, выполняя повторяющиеся вызовы команды dig. Она сообщает о несоответствиях, ошибках и других проблемах, связанных с кон- кретным именем домена. На экран выводится информация о всех выявленных пробле- мах. Кроме того, эта утилита создает подробный журнальный файл в текущем каталоге. Для своей работы утилита doc использует локальный сервер имен. Если домен ис- пользует инструкцию view сервера BIND и содержит частные адреса RFC1918 в своем внутреннем представлении, то применение утилиты doc к внутреннему представлению сбивает ее с толку и она сообщает о ложных ошибках. Если вы используете представле- ния, то запустите утилиту doc извне домена, чтобы она видела то, что видят внешние пользователи. Ниже приведен отчет утилиты doc о некорректном домене w3w3. com, который был рассмотрен выше. $ doc w3w3.com Doc-2.2.3: doc w3w3.com Doc-2.2.3: Starting test of w3w3.com. parent is com. Doc-2.2.3: Test date - Tue Jul 21 21:15:11 MDT 2009 Summary. ERRORS found for w3w3.com. (count: 1) WARNINGS issued for w3w3.com. (count: 1) Done testing w3w3.com. Tue Jul 21 21:15:21 MDT 2009 Утилита doc выводит в журнальный файл (в данном случае файл Iog.w3w3.com) подробности тестирования и сообщение об ошибках (в сумме более 600 строк). ERROR: no SOA record for w3w3.com. from nsl.nameservices.net.
Глава 17. Система доменных имен 725 Утилита не помечает домен w3w3. com как “некорректное делегирование”, а иден- тифицирует проблему, которая в связи с этим возникает. Начиная с записей NS в роди- тельской зоне, утилита проверяет, является ли сервер nsl.nameservices.net автори- тетным по отношению к домену w3w3. com; в данном случае это не так. Если вы управляете доменом, который содержит поддомены (или вы не доверяете менеджерам вашего родительского домена), постарайтесь выполнять утилиту doc из планировщика заданий cron каждую неделю, чтобы проверить, что все делегирования, связанные с вашим доменом, являются корректными. Производительность системы Производительность пакета BIND 9 на многопроцессорной архитектуре оказалась не такой высокой, как надеялись его разработчики, но некоторые корневые серверы исполь- зуют пакет BIND 9 и успешно обрабатывают десятки тысяч запросов в секунду. Для боль- шинства сайтов этого, вероятно, более чем достаточно. Однако производительность па- кетов NSD и Unbound еще выше, особенно в зонах, подписанных по протоколу DNSSEC. Мы уже несколько раз об этом говорили, но скажем еще раз: присваивайте вашим параметрам TTL разумные значения — недели или дни, а не минуты и секунды. Ис- пользование коротких периодов TTL отрицательно сказывается как на вашей работе (поскольку вы постоянно перезаписываете одни и те же записи), так и на работе ваших веб-клиентов (поскольку они постоянно извлекают эти записи). Кроме того, это позво- ляет потенциальным злоумышленникам искажать содержимое вашего кеша. Некоторые серверы имен преднамеренно игнорируют параметры TTL, которые им не нравятся (т.е. если эти значения неразумно малы или чрезмерно велики). Подкачка памяти снижает производительность сервера нелинейно, поэтому не ску- питесь на память ваших узлов, которые запускают серверы имен. Для того чтобы стаби- лизировать работу рекурсивных серверов, вам понадобится около недели на копирова- ние памяти (см. раздел 17.6). Для того чтобы оценить объем памяти, который может понадобиться демону nsd для обработки ваших авторитетных данных, заполните веб-форму на веб-странице nlsnetlabs.net/nsd/nsd-memsize.html. Отлично! Используйте переадресующие серверы (см. раздел 17.9). Сценарии init, запускающие демон named на многих системах, создают дополнитель- ные точки входа (например, reload), предназначенные для системного администратора. Однако проще и надежнее с точки зрения работы на разных платформах использовать утилиту rdnc. Ш Более подробно утилита inetd описана в разделе 32.1. Не используйте программы inetd или xinetd для управления сервером имен; они перезагружают сервер каждый раз, когда им это требуется, тем самым резко замедляя время ответа и не позволяя создавать хоть сколько-нибудь полезный кеш. 17.16. Специфика различных дистрибутивов В этом разделе описывается программное обеспечение серверов имен для разных платформ. В каждый дистрибутивный пакет серверов имен входит пакет BIND, хотя при инсталлировании операционной системы, а также при отдельной установке сервера имен есть возможность указать, какой именно пакет вы хотите установить.
726 Часть II. Работа в сети Операционные системы семейства Linux более оперативно реагируют на появление новых версий пакета BIND, чем ее аналоги из семейства UNIX. Тем не менее служба имен играет чрезвычайно важную роль. По этой причине вполне естественно желать, чтобы на компьютере немедленно устанавливались новейшие системы, а не дожидаться, пока эти пакеты станут общедоступными. Системы Ubuntu и Red Hat содержат полный комплект NSD/Unbound в виде паке- тов; система SUSE хранит в своих официальных репозиториях только пакет Unbound. В настоящее время все эти пакеты слегка устарели, поэтому мы рекомендуем загружать их новейшие версии с сайта nlnetlabs. nl и собирать их самостоятельно. В этом разделе рассмотрим указатели на файлы конфигурации, на которых основана работа любой версии пакета BIND любого поставщика. Кроме того, мы покажем, как объединить пакет BIND с другими источниками административных данных, такими как однородные файлы и файлы службы NIS. Более подробное обсуждение последней темы изложено в главе 19. Ш Более подробная информация о сценариях загрузки системы приведена в разделе 3.5. Мы также рассмотрим указатели на сценарии, которые должны выполняться при за- грузке серверов имен. Если сервер имен выходит из строя, то выходит из строя абсолют- но все — сеть, электронная почта, веб-сайт. Некоторые организации используют сцена- рий сохранения работоспособного состояния. К таким сценариям относится nanny из дистрибутивного пакета BIND. Специфика системы Linux Д Пакеты BIND для системы Linux инсталлируют сценарий для пакетов named, который запускается с помощью команд init: /etc/inut. d/bind9 для си- стемы Ubuintu и /etc/init.d/named для систем RHEL и SUSE. Пакеты named в системе Linux инсталлируют все программы в своих традиционных каталогах. Детали показаны в табл. 17.18. Система Red Hat имеет дополнительные про- граммы, которые взаимодействуют с инструментом Network Manager с помощью флага -D, который задается в командной строке демона named. Подробности можно найти в файле doc/README-DBUS в пакете Red Hat BIND. Таблица 17.18. Файлы пакета BIND в Linux Файл resolv.conf /etc Библиотечный файл конфигурации распознавателя named, Iwres /usr/sbin Демон сервера имен Iwresd /usr/sbin Облегченный распознаватель named.conf /etc Конфигурационный файл сервера named (RHEL и SUSE) named.conf /etc/bind Конфигурационный файл сервера имен (Ubuntu) named-checkconf /usr/sbin Проверяет синтаксис файла конфигурации namedGetFrowarders /usr/sbin Предназначен для инструмента Network Manager (только в Red Hat) namedSetFrowarders /usr/sbin Предназначен для инструмента Network Manager (только в Red Hat) nsswitch.conf /etc Файл переключения службы Система Linux использует файл переключения /etc/nsswitch. conf для того, чтобы указать, как выполняется отображение IP-адреса в имя компьютера и в каком порядке
Глава 17. Система доменных имен 727 следует использовать систему DNS — первой, последней или вообще не использовать. Если файла переключения нет, то по умолчанию устанавливается следующее поведение. hosts: dns [!UNAVAIL=return] files Раздел ! unavail означает, что если служба DNS доступна, но имя в ней не найдено, следует прекратить попытки поиска и не продолжать просмотр следующей записи (в дан- ном случае файла /etc/hosts). Если сервер имен не был запущен (это бывает во время загрузки системы), то процесс поиска рекомендуется согласовывать с файлом hosts. Все рассмотренные нами дистрибутивные пакеты содержат в файле nsswitch. conf следующую запись, определяющую поведение по умолчанию. hosts: files dns Не существует “наилучшего” способа конфигурации поиска — все зависит от того, как управляется ваш сайт. В общем, мы предпочитаем хранить как можно больше ин- формации об узле в системе DNS, а не в файлах системы NIS или в обычных файлах, но мы также пытаемся сохранить возможность вернуться при необходимости назад к стати- ческим файлам hosts в процессе загрузки системы. ©Система Ubuntu является наиболее современной версией системы Linux, по- скольку ее дистрибутивные пакеты появились лишь совсем недавно. Ее про- граммы и файлы имеют корневого владельца и группового владельца “bind”, которые выдают разрешения на получение доступа, когда демон named вызы- вается как пользователь сервера BIND, а не как корень. Несколько полезных файлов находится в каталоге /etc/bind. Помимо них, в пакет входят файлы named, conf и зонные файлы, содержащие корневые подсказки, инфор- мацию о локальном узле, адресах широковещательной рассылки и пространстве част- ных адресов. Поставляемый файл named, conf содержит файлы named, conf, options и named, conf .local. Он задает каталог пакета BIND по умолчанию — /var/cache/ bind; при поставке этот каталог уже существует, но остается пустым. Размещение конфигурации в каталоге /etc, а зонной информации — в каталоге /var объясняется тем, что если ваш сервер является подчиненным по отношению к дру- гим сайтам, то вы не можете управлять размерами своих зонных файлов, которые запи- сывает демон named. Для того чтобы предотвратить потенциальное заполнение корне- вой части, следует сохранить файлы в каталоге /var. Зоны, для которых вы являетесь главным сервером, могут находиться вместе с файлами конфигурации (и задаваться аб- солютными путями в файле named, cond) либо в каталоге /var/cache/bind. Если вы хотите запустить только кеширующий сервер, то модифицировать файл named.conf не следует. Все зоны, по отношению к которым вы являетесь авторитет- ным, желательно добавлять в файл named, conf. local. Стандартные файлы, предоставляемые системой Ubuntu, используют новые функци- ональные возможности пакета BIND, помогающие серверам правильно работать в систе- ме DNS. Например, они конфигурируют домены . сот и . net как зоны, выполняющие только делегирование, чтобы опечатки пользователей не генерировали доход от рекла- мы для компании VerySign благодаря их инструменту Site Finder. Если вы не используете пространство частных адресов (RFC1918) изначально, то пустые зонные файлы RFC1918 предотвращают утечку этих адресов из локальной сети. Вперед, Ubuntu! Каталог /usr/share/doc/bind9 содержит несколько полезных ссылок. Проверьте файл README. Debian (даже в системе Ubuntu), чтобы понять стратегию конфигуриро- вания пакета BIND.
728 Часть II. Работа в сети Инсталляция системы SUSE сопровождается сообщениями о выполняемых действиях и генерирует, хорошо документированную инсталляцию сервера имен. По умолчанию демон named выполняется в виртуальной среде chroot в каталоге /var/lib/named как пользователь и группа “named”. Инсталлятор создает виртуальный каталог chroot и заполняет его всеми файлами, необхо- димыми для выполнения демона named, даже такими как сокет UNIX-домена для системы syslog. Дополнительные файлы конфигурации (не совпадаю- щие с файлом named.conf) и зонные файлы в каталоге /etc/named.d копи- руются в виртуальный каталог при запуске демона named. Если вы не хотите выполнять демон named в виртуальной среде, модифицируйте строку NAME D_RUN_CHROOTE D="ye s" в каталоге /etc/sysconf ig/named. Это все, что следует изменить; сценарии запуска в каталоге /etc/init.d используют эту информацию и могут запу- скать демон named в любом режиме. Система SUSE предоставляет стандартный файл /etc/named.conf, содержа- щий описание множества полезных опций. Файл /etc/named. conf является нечита- бельным, в отличие от других систем. Стандартный файл импортирует файл с именем named.conf. include, который затем импортирует файл rdnc-access. conf из ката- лога /etc/named, который можно прочитать. Не совсем ясно, почему система SUSE таким образом беспокоится о безопасности. Программа rdnc заранее конфигурируется так, чтобы принимать управляющие команды только от локального узла. Для того чтобы запустить только кеширующий сервер, файл named, conf системы SUSE можно использовать как есть. Если же вы хотите обслуживать свои зоны, то по- местите зонные файлы в каталог /etc/named.d, а список зонных имен — в файл /etc/ named. conf. include. Документация к пакету ISC BIND хранится в каталоге /usr/share/doc/packages/ bi nd 9. При инсталляции системы RHEL пакет BIND помещает бинарные файлы в ка- талог /usr/sbin, справочные страницы — в каталог /usr/share/man, добав- ляет пользователя и группу с именем “named” и создает каталоги для зонных файлов. Пользователь “named” имеет доступ к файлам данных с помощью раз- решений группы. Если не внести изменений в файл /etc/sysconfig/named, то файл named, conf за- писывается в каталог /etc (как указал Пол Викси (Paul Vixie)), а зонные файлы — в ка- талог /var/named. Стандартные файлы конфигурации не поставляются, но в пакете bindconf они есть. Специфика системы Solaris УСистема Solaris 10 поставляется вместе с пакетом BIND 9.3.4-Р1, выпущен- soiaris ным в конце 2007 года; он уже устарел, потому следует подумать о его моди- фикации. Система OpenSolaris является более современной и поставляется вместе с пакетом BIND 9.6.1-Р1 (2009). Система Solaris всегда называла свои сетевые программы как 1п.имя_программы, и демон named — не исключение, поэтому его можно не сразу найти, если забыть, что на самом деле он называ- ется in. named, а не named. К счастью, это уже не так, и теперь система Solaris называет демон просто named, а имя in. named осталось просто как ссылка.
Глава 17. Система доменных имен Аналогично системе Linux система Solaris использует файл заказа на обслужи- вание /etc/nsswitch.conf, с помощью которого она указывает, как должны взаимодействовать серверы BIND, NIS, NIS+ (только в системе Solaris 10) и файл /est/hosts. Замена строки hosts в этом файле на строку hosts: files dns заставляет распознаватель имен сначала проверять файл /etc/hosts и только потом систему DNS. Короткая инструкция NOTFOUND=return может моди- фицировать любую запись. Размещение имен важных серверов и маршрути- заторов в файле /etc/hosts облегчает решение причинно-следственной про- блемы, которая иногда возникает на этапе загрузки системы, пока не станет доступной служба имен. Служба имен в системе Solaris начинается со службы SMF svc:/network/dns/server: : default. Опции SMF задают аргументы командной строки. Имена файлов пакета BIND и их расположение в системе Solaris приведены в табл. 17.19. Таблица 17.19. Файлы пакета BIND 9 в системе Solaris Файл Каталог Описание ’ resolv.conf /etc Библиотечный файл конфигурации распознавателя named /usr/sbin Демон сервера имен named-checkconf /usr/sbin Проверяет синтаксис файла конфигурации named-checkzone /usr/sbin Проверяет синтаксис зонного файла named-conf /etc Файл конфигурации для сервера имен nsswitch.conf /etc Файл переключения службы Специфика системы HP-UX Система HP-UX содержит устаревший пакет BIND 9.3.2, выпущенный в кон- це 2005 года. Лучше обновите! Система HP-UX поставляется со стандартными файлами nsswitch.conf для разных комбинаций баз данных и служб. Один из них содержит список умолчаний для системы HP. Скопируйте файл, кото- рый кажется вам подходящим, в файл /etc/nsswitch.conf. Рекомендации по умолчанию для системы HP: hosts: dns [NOTFOUND=return] nis [NOFOUND=return] files Однако мы рекомендуем такую настройку, которая предотвращает проблемы при за- грузке системы. hosts: files [NOTFOUND=continue] dns Важно иметь возможность конфигурировать сеть в последовательности загрузки без поиска имен в службах NIS или DNS, поскольку эти службы не могут работать, пока система не загрузится. Дистрибутивный пакет системы HP-UX содержит хорошо документированные стан- дартные файлы практически на все случаи жизни. Они находятся в каталоге /usr /newconfig, но, увы, среди них нет ни одного, который относился бы к службе имен. Однако существует набор устаревших команд, связанных со службой имен, — hosts_ to_named, которая преобразует файл hosts в зонный файл, и sig_named, которая по- сылает управляющие сигналы выполняемому процессу named. В настоящее время файл
730 Часть II. Работа в сети /etc/hosts содержит как имя локального узла, так и имя самого узла, поэтому про- грамма для преобразования не нужна. Начиная с версии BIND 9, для управления про- цессом named должна использоваться программа rdnc, а не сигналы. Имена файлов пакета BIND и их расположение в системе HP-UX приведены в табл. 17.20. Таблица 17.20. Файлы пакета BIND в системе HP-UX Файл ., J; resolv.conf /etc Библиотечный файл конфигурации распознавателя named /usr/sbin Демон сервера имен Iwresd /usr/sbin Облегченный распознаватель named-checkconf /usr/sbin Проверяет синтаксис файла конфигурации named-checkzone /usr/sbin Проверяет синтаксис зонного файла named-conf /etc/namedb Файл конфигурации для сервера имен nsswitch.conf /etc Файл переключения службы Специфика системы AIX Система AIX содержит пакеты BIND 8 и 9, которым соответствуют бинарные файлы named8 и named9 соответственно. При поставке файл named представ- ляет собой ссылку на файл named8, которая больше не поддерживается кон- сорциумом ISC. Они поставляют версии 8.3.3+ и 9..2.1, выпущенные еще в ян- варе 2004 года. Очевидно, что причиной отсутствия обновлений является лень! Система AIX не содержит команд named-checkconf и named-checkzones, возможно, потому что они входят в пакет BIND начиная с 2004 года. Сценарий запуска службы имен в системе AIX находится в каталоге /etc/гс/tcpip. Мы полагаем, что такое расположение файлов неразумно, потому что операцион- ные системы во многом уже стандартизировали расположение файлов с учетом пакета BIND, а в системе AIX это еще не сделано. Имена файлов и их расположение в системе AIX приведены в табл. 17.21. Таблица 17.21. Файлы пакета BIND в системе AIX . Файл resolv.conf /etc Библиотечный файл конфигурации распознавателя named8 /usr/sbin Демон сервера имен BIND 8 named9 /usr/sbin Облегченный распознаватель BIND 9 named.conf /etc Файл конфигурации для сервера имен netsvc.conf /etc Файл переключения служб irc-conf /etc Другой файл переключения служб NSORDER окружение Переменная переключения окружения Обычно в поставку системы AIX входит три механизма, реализующие концепцию ‘переключения службы”, с помощью которых можно указать, к каким каталогам долж- ны обращаться службы. Переменная среды NSORDER замещает информацию, задан- ную в файлах /etc/netsvc. conf и /etc/irs. conf.
Глава 17. Система доменных имен 731 Эти механизмы не только размещаются в разных местах, но и имеют разный син- таксис. Например, для того чтобы выбрать поиск имен узлов в системе DNS в файле netsvc.conf, можно использовать переменную bind, но то же самое можно сделать и с помощью файла irs. conf, в котором хранится значение dns. Этот синтаксис по- зволяет определить, что делать, если предпочитаемая служба не находит ответа, но он отличается от синтаксиса файла nsswitch. conf в других системах. Детали механизма переключения служб приведены в разделе 19.5. 17.17. Рекомендуемая литература Система доменных имен и пакет BIND описаны во многих источниках, включая до- кументацию, входящую в состав пакета, отдельные главы в книгах об Интернете, це- лую книгу серии “In a Nutshell” издательства O’Reilly, а также многочисленные ресурсы в глобальной сети. Серверы NSD и Unbound являются относительно новыми, поэтому внешних источников, посвященных их описанию, относительно немного, но мы нашли одну книгу, которая охватывает сразу несколько веб-документов. Списки рассылки и новостные группы Ниже перечислены списки рассылки, посвященные пакету BIND. • bind-announce — чтобы подписаться, отправьте сообщение по адресу bind- announce-request@isc.org • namedroppers — чтобы подписаться, отправьте сообщение по адресу namedroppers-request@internic.net • bindusers — чтобы подписаться, отправьте сообщение по адресу bind-users- request@isc.org • bind9-workers — чтобы подписаться, отправьте сообщение по адресу bind9- workers-request@isc. org (для разработчиков) Сообщения об ошибках следует слать по адресу bind9-bugs@isc. org. Ниже перечислены списки рассылки, посвященные пакету NSD/Unbound. • nsd-users — чтобы подписаться, зайдите на веб-сайт nlnetlabs. nl/projects/nsd • unbound-users — чтобы подписаться, зайдите на веб-сайт unbound. net • Idns-users — чтобы подписаться, зайдите на веб-сайт nlnetlabs. nl/projects/ Idns • drill — чтобы подписаться, зайдите на веб-сайт nlnetlabs.nl/projects/drill И вот список рассылки, посвященный службе DNS и функционированию чрезвы- чайно важных сайтов (регистраторов, корневых серверов, серверов TLD и т.д.). • dns-operations — чтобы подписаться, зайдите на веб-сайт lists. dns-oarc.net Книги и другая документация • The Nominum BIND Development Team. BINDv9 Administrator Reference Manual. • Документ включен в дистрибутив BIND (doc/arm), а также доступен на веб-узле www .isc.org. В нем в общих чертах описаны принципы администрирования па- кета BIND 9.
732 Часть II. Работа в сети • Reed, Jeremy С., editor. BIND 9 DNS Administration Reference Book, redwood City, CA: Reed Media Services, 2007. • Albitz, Paul and Cricket Liu. DNS and BIND, 4th Edition. Sebastopol, CA: O’Reilly, 2001. Это очень популярная книга о пакете BIND, содержащая описание версий BIND 8 и BIND 9. Полнота изложения впечатляет. • Liu, Cricket. DNS & BIND Cookbook. Sebastobol, CA: O’Reillymedia, 2002. Это упрощенная версия книги о системе DNS, выпущенной издательством O’Reilly, содержащая четкие и ясные инструкции, а также примеры разных операций на серверах имен. Она несколько устарела, но все еще полезна. • Atchison, Ron. Pro DNS and BIND. Berkeley, CA: Apress, 2005. Это новая книга о системе DNS, содержащая очень хороший раздел о протоколе DNSSEC с примерами и описание стратегии развертывания. Мы нашли несколь- ко опечаток, но, к счастью, автор поддерживает веб-сайт, посвященный ошибкам. По глубине материала и организации эта книга выгодно отличается от книги DNS and BIND, но администратору DNS лучше иметь обе эти книги! • Mens, Jan-Piet. Alternative DNS Servers: Choice and Deployment, and Optional SQL/LDAP Back-Ends. Camridge, England: UIT Cambridge Ltd., 2009. Эта книга описывает около 10 разных реализаций серверов имен, включая NSD/ Unbound. В ней изложены разные вопросы хранения данных о зоне, приведены прекрасные диаграммы и дано много полезной информации. Ресурсы в Интернете Каталог ресурсов DNS (dns. net/dnsrd) — это полезная коллекция ресурсов и ссы- лок на них, поддерживаемая Андрашем Саламоном (Andras Salamon). Веб-сайты isc.org,dns-oarc.net, ripe.net, nlnetlabs.nl, f.root-servers. org и k. root-servers. org содержат много информации о системе DNS, исследовани- ях, результатах измерений, презентациях и др. В поисковой системе Google индексированный список ресурсов DNS находится по следующему адресу: http://directory.google.com/Top/Computers/Internet/Protocols/DNS Подробная информация о протоколе DNS, записях о ресурсах и других аспектах DNS приведена на сайте iana.org/assignments/dns-parameters. Этот документ содер- жит информацию о том, в каком документе RFC описан тот или иной факт, касающий- ся работы системы DNS. Справочник DNSSEC HOWTO, написанный Олафом Колкманом (Olaf Kolkman), — это 70-страничный документ, в котором изложены все аспекты развертывания и отлад- ки протокола DNSSEC. Его можно загрузить с сайта nlnetlabs .nl/dnssec_howto/ dnssec_howto.pdf. Документы RFC Документы RFC, в которых описывается система доменных имен, доступны на веб- узле www. гf c-editor. org. Мы использовали только самые важные из них, хотя в на- стоящее время есть около 100 документов и около 50 черновиков, опубликованных в Ин- тернете, поэтому рекомендуем читателям зайти на сайт www. rf c-editor. org и изучить
Глава 17. Система доменных имен 733 весь архив. Для того чтобы увидеть все документы, касающиеся текущей версии BIND, найдите каталоги doc/rfс и doc/draft. Исходные спецификации 1987 года: • RFC 1034 — Domain Names: Concepts and Facilities (Доменные имена: концепции и базовые возможности). • RFC1035 — Domain Names: Implementation and Specification (Доменные имена: реа- лизация и спецификация). 17.18. Упражнения 17.1. Поясните назначение следующих записей о ресурсах: SOA, PTR, А, MX и CNAME. 17.2. Что такое связующие записи и зачем они нужны? Найдите с помощью команд dig или drill записи, связывающие вашу локальную и родительскую зоны. 17.3. В чем смысл отрицательного кеширования? Почему оно так важно? 17.4. Создайте записи SPF для своего сайта, чтобы контролировать спам. 17.5. ★ Какие действия необходимо предпринять для создания домена второго уровня? Назовите технические и организационные мероприятия. 17.6. ★ В чем разница между авторитетным и неавторитетным ответом на DNS-запрос? Как убедиться в том, что ответ действительно авторитетен? 17.7. ★ Какой компьютер является вашим локальным сервером имен? Какие действия придется ему предпринимать для распознавания имени www. admin. com (предпо- лагается, что ни в одном из кешей DNS информации об этом домене нет)? 17.8. ★ Объясните, какое влияние на DNS оказывает 512-байтовое ограничение на раз- мер пакета, налагаемое протоколом UDP? Какие существуют решения потенци- альных проблем? 17.9. Изучите 512-битовый русский алгоритм GOST или 256-битовый алгоритм NIST Р-256 ECDSA и оцените их влияние на 512-байтовое ограничение размера пакетов UDP. Могут ли они обеспечить требуемый размер пакета? Насколько длинными являются ключи и подписи? 17.10. ★ Создайте записи SSHFP для своего сайта и обновите свою команду ssh для их использования. 17.11. Используйте сервер для оценки размера пакетов ISC DNS-OARC из разных точек своего сайта, чтобы определить, какая локальная конфигурация может запретить развертывание протокола DNSSEC. Какой размер вы видите? Изменяется ли он при изменении вашего расположения? Какой размер вы видите из главного узла? Соберите такие же данные с помощью инструментов SecPider или dnsfunnel. Согласуются ли ваши данные? Если нет, то какой инструмент дает более точную информацию? 17.12. ★ Используя инструменты DNSSEC или библиотеки, создайте сценарий, опреде- ляющий синхронизацию между защищенным сайтом и записями DS на его ро- дительском сервере, а также срок действия подписи. Ежедневно выполняйте этот сценарий с помощью планировщика заданий cron. 17.13. ★ Создайте записи DKIM для своего домена и настройте почтовые серверы и кли- енты на работу с ним.
734 Часть II. Работа в сети 17.14. * Создайте поддомен вашего сайта. Добавьте реальный сайт со множеством имен и адресов, затем защитите его с помощью протокола DNSSEC и соедините с на- дежной сетью в Интернете, создав запись DLV на сайте консорциума ICS. Вклю- чите регистрацию и несколько дней наблюдайте за регистрационными записями. Задокументируйте все свои действия и проблемы
Глава 18 Сетевой протокол Network File System Сетевой протокол Network File System, или NFS, позволяет пользователям совмест- но работать с файлами, расположенными на разных компьютерах. Протокол NFS почти прозрачен для пользователей, т.е. при сбое сервера, поддерживающего протокол NFS, информация не пропадает. Клиенты просто ждут, когда сервер вновь начнет функцио- нировать, а затем продолжают работать так, будто ничего не произошло. Протокол NFS разработала компания Sun Microsystems в 1984 году. Первоначально протокол NFS был реализован как суррогат файловой системы для бездисковых кли- ентов, однако предложенный протокол оказался столь удачным, что со временем стал универсальным решением проблемы совместного использования файлов. Все дистри- бутивные пакеты систем UNIX и Linux содержат версию протокола NFS; многие из них используют лицензию компании Sun. В настоящее время протокол NFS открыто описан в документах RFC (см. RFC1094, RFC1983 и особенно RFC 3530). 18.1. Введение в протокол NFS Совместное использование файлов в сети выглядит простой задачей, но на самом деле она представляет собой сложную проблему, имеющую множество вариантов реше- ния и нюансов. В качестве свидетельства сложности этой задачи напомним, что много- численные ошибки протокола NFS проявились в необычных ситуациях только спустя четверть века его использования. Современные администраторы могут быть уверены в том, что большинство протоколов совместного использования файлов (NFS и CIFS) не
736 Часть II. Работа в сети портят данные и не вызывают ярость пользователей, но для того, чтобы этого достичь, пришлось немало потрудиться. Проблемы, связанные с состоянием При разработке файловой системы необходимо решить, какая ее часть будет отсле- живать файлы, открываемые каждым клиентом. Информация об этих файлах называ- ется “состоянием” (state). Сервер, не делающий записей о статусе файлов и клиентов, называется сервером без сохранения состояния (stateless), а сервер, который решает эту задачу, — сервером с сохранением состояния (stateful). Многие годы использовались оба этих подхода, причем каждый из них имеет как преимущества, так и недостатки. Серверы с сохранением состояния отслеживают все открытые файлы в сети. Этот ре- жим работы вызывает множество проблем (больше, чем можно было бы ожидать) и за- трудняет восстановление в случае краха. Когда сервер возвращается из небытия, клиент и сервер должны заново согласовать, какое состояние следует считать последним перед крахом. Серверы без сохранения состояния позволяют клиентам лучше контролировать файлы и облегчают управление файлами, открытыми в режиме чтения/записи. На сервере без сохранения состояния каждый запрос не зависит от предшествующих запросов. Если сервер или клиент терпит крах, то никаких потерь для процесса это не влечет. В этом случае сервер безболезненно терпит крах и перезагружается, поскольку никакого контекста нет. Однако в этом случае сервер не может знать, какие клиенты от- крыли файлы для записи, поэтому не способен управлять параллельной работой. Проблемы производительности Пользовательский интерфейс сетевых файловых систем не должен отличаться от пользовательского интерфейса локальных файловых систем. К сожалению, глобальные сети имеют большое время ожидания, что приводит к неправильному выполнению опе- раций и сужению полосы пропускания. Все это в итоге приводит к снижению произво- дительности работы с большими файлами. Большинство протоколов файловых служб, включая NFS, реализуют методы минимизации потерь производительности как в ло- кальных, так и глобальных сетях. Большинство протоколов пытается минимизировать количество запросов в сети. Например, предварительное кеширование предусматривает загрузку фрагментов файла в буфер локальной памяти, чтобы избежать задержки при считывании нового раздела файла. Часть полосы пропускания используется для того, чтобы избежать обмена ин- формацией с сервером в ходе общего цикла сканирования сети (full round trip exchange). Кроме того, некоторые системы кешируют записи в памяти и посылают их обновления в пакетах, уменьшая тем самым задержку, вызванную необходимостью выполнить опе- рации записи на сервере. Эти пакетные операции обычно называют объединением за- просов (request coalescing). Безопасность Любая служба, предоставляющая удобный доступ к файлам в сети, является источни- ком серьезных угроз для безопасности. Локальные файловые системы реализуют слож- ные алгоритмы управления доступом, наделяя пользователей разными правами. В сети эти проблемы многократно усложняются, поскольку существуют требования, предъ- являемые к быстродействию машин, а также имеются различия между их конфигура-
Глава 18. Сетевой протокол Network File System 737 циями, ошибки в программном обеспечении файловых систем и нерешенные вопросы связанные с протоколами совместного использования файлов. Развитие служб каталогов и централизованной аутентификации повысило безопас- ность сетевых файловых систем. По существу, ни один клиент не может аутентифициро- вать себя самостоятельно, поэтому необходима доверенная централизованная система, верифицирующая личности и предоставляющая им доступ к файлам. Сложная орга- низация этих служб замедляет их адаптацию, но в настоящее время централизованное управление доступом в той или иной степени реализовано в большинстве организаций. 18.2. Серверная часть NFS Новейшая версия протокола NFS является платформенно-независимой, обеспечивает высокую производительность в глобальных сетях, таких как Интернет, а также гаранти- рует высокую безопасность. Большинство его реализаций также содержат диагностиче- ские инструменты для решения проблем, связанных с настройкой и производительно- стью. Клиентское и серверное программное обеспечение расположено в ядре. Однако эти части протокола NFS не требуют настройки и прозрачны для администратора. Версии и история протокола Первая открытая версия протокола NFS, появившаяся в 1989 году, имела номер 2. Клиент второй версии NFS не мог считать операцию записи завершенной, не получив подтверждения от сервера. Для того чтобы избежать сбоя, сервер должен был записы- вать каждый модифицированный блок на диск, прежде чем ответить. Такое ограничение существенно замедляло запись, поскольку во многих случаях модифицированные блоки вполне можно было хранить лишь в буферном кеше. В версии 3, появившейся в начале 1990-х годов, этот недостаток был устранен за счет схемы согласования, которая позволяла выполнять запись асинхронно. Были улучшены также другие аспекты протокола, связанные с производительностью и обработкой боль- ших файлов, вследствие чего версия NFS 3 стала работать гораздо быстрее, чем NFS 2. По этой причине все организации должны использовать версии NFS 3 или 4. Версия NFS 4 является результатом крупной переработки протокола; она содержит много усовершенствований и новых функциональных возможностей. • Совместимость и взаимодействие со всеми брандмауэрами и устройствами NAT. • Интегрирование в основном протоколе NFS протоколов блокировки и монтиро- вания. • Операции с сохранением состояния. • Высокая интегрированная безопасность. • Поддержка репликации и миграции. • Поддержка клиентов как UNIX, так и Windows. • Списки управления доступом (ACL). • Поддержка файлов в кодировке Unicode. • Хорошая производительность даже при узкой полосе пропускания. Несмотря на то что во многих аспектах версия 4 представляет собой шаг вперед, из- менения, внесенные в протокол, не изменили существенно процесс конфигурирования и администрирования протокола NSF.
738 Часть II. Работа в сети Разные версии протокола не совместимы друг с другом, но серверы, поддерживаю- щие протокол NFS (включая все рассмотренные нами операционные системы), обычно реализуют три из них. На практике все клиенты и серверы протокола NFS могут взаи- модействовать с помощью одной из этих версий. Если и клиентская, и серверная сторо- ны поддерживают протокол NFS 4, следует использовать именно эту версию. Транспортные протоколы В версии NFS 2 применялся протокол UDP, поскольку он обеспечивал наилучшую производительность в локальных сетях 80-х годов. Несмотря на то что протокол NFS сам выполняет сборку пакетов и осуществляет контроль ошибок, ни в UDP, ни в NFS не реализованы алгоритмы управления перегрузкой, которые необходимы для достижения нормальной производительности в крупных 1Р-сетях. С целью решения этих проблем в большинстве UNIX-систем теперь разрешено ис- пользовать в качестве транспортного протокола в версии NFS 3 как UDP, так и TCP, а в версии NFS 4 — только TCP.1 Первоначально эта возможность предназначалась для обеспечения работы NFS в сетях с маршрутизаторами и в Интернете. По мере удешевле- ния памяти и роста производительности центральных процессоров и сетевых контролле- ров, первоначальное преимущество протокола UDP над протоколом TCP улетучилось. Состояние Прежде чем начать работать с файловой системой NFS, клиент должен ее смонтиро- вать, как если бы это была файловая система, находящаяся на локальном диске. Однако версии NFS 2 и 3 не сохраняют состояние, поэтому сервер не “знает”, какие клиенты смонтировали ту или иную файловую систему. Вместо этого сервер вручает клиенту секретный ключ по факту успешного завершения операции монтирования. Этот ключ идентифицирует каталог монтирования на сервере NFS и дает клиенту возможность получить доступ к содержимому каталога. Ключ сохраняется при перезагрузке, чтобы сервер после сбоя смог вернуться в предыдущее состояние. Клиент может просто подо- ждать, пока сервер перезагрузится, и повторить свой запрос. С другой стороны, версия NFSv4 представляет собой протокол с сохранением состо- яния: и клиент, и сервер хранят информацию об открытых файлах и блокировках. При сбое сервера клиент облегчает процесс восстановления, посылая на сервер информацию о состоянии, предшествующем сбою. Восстанавливающийся сервер ожидает в течение заданного периода отсрочки, пока бывшие клиенты отчитаются о своем предыдущем состоянии, прежде чем приступить к выполнению новых операций и блокировок. Упра- вления ключами, которое существовало в версиях V2 и V3, в версии NSFv4 больше нет. Экспорт файловой системы Говорят, что сервер “экспортирует” файловую систему, если он делает ее доступной для использования другими компьютерами. По определению, все серверы экспортируют хотя бы один каталог. В версиях V2 и V3 каждый экспорт рассматривается как незави- симая сущность. В версии V4 каждый сервер экспортирует одну иерархическую псевдо- файловую систему, содержащую все свои экспортируемые каталоги. По существу, псев- 1 С формальной точки зрения, можно использовать любой транспортный протокол, реализую- щий алгоритм управления перегрузкой, но в настоящее время единственным разумным выбором является только протокол TCP.
Глава 18. Сетевой протокол Network File System 739 дофайловая система — это пространство имен файловой системы сервера, из которой удалено все, что не подлежит экспорту. В качестве примера рассмотрим следующий список каталогов, в котором экспорти- руемые каталоги выделены полужирным шрифтом. /www/domainl /www/domain2 /www/domain3 /www/logs/httpd /var/spool В версии NFS 3 каждый экспортируемый каталог должен конфигурироваться отдель- но. Клиентские системы должны выполнить три разных запроса на монтирование, что- бы получить доступ ко всему экспорту сервера. В то же время в версии NFS 4 псевдофайловая система соединяет разрозненные ча- сти структуры каталогов и создает единое представление для клиентов NFS. Вместо за- проса на монтирование каждого из каталогов /www/domainl, /www/domain2 и /var/ logs/httpd, клиент может просто смонтировать серверный псевдокорневой каталог и просмотреть всю иерархию. Каталоги /www/domainl и /var/spool, не подлежащие экспорту, не появляются в этой иерархии. Кроме того, отдельные файлы, содержащиеся в каталогах /, /var, / www и /var/logs, не видны клиенту, потому что псевдофайловая часть иерархии состо- ит только из каталогов. Таким образом, при использовании версии NFSv4 клиент видит экспортируемую файловую систему в следующем виде. / /www /www.domainl /www.domain2 /var /var/logs /var/logs/httpd Сервер задает корень экспортируемой файловой системы в файле конфигурации под названием exports. Блокировка файлов Блокировка файлов (реализуемая системными вызовами flock, lockf или fcntl) в течение долгого времени была слабым звеном в системах UNIX. В локальных файловых системах этот механизм был воплощен далеко не идеально. В ранних версиях протокола NFS серверы не сохраняли состояние: им не известно, какие компьютеры работают с конкретным файлом. Однако эта информация необходима для использования блокиро- вок. Как быть? Традиционное решение заключается в реализации механизма файловых блокировок отдельно от протокола NFS. В большинстве систем этой цели служат два демона: lockd и statd. К сожалению, по ряду причин они работают не оптимально, и блокировка фай- лов в протоколе NFS оставалась его слабым местом. В версии NFSv4 демоны lockd и statd больше не используются для блокировки в основном протоколе (следовательно, серверы сохраняют состояние). Это изменение значительно усложнило протокол, но устранило множество проблем, характерных для более ранних версий протокола NFS. К сожалению, по отдельности демоны lockd и statd все еще нужны для поддержки клиентов, использующих версии V2 и V3. Все рас-
740 Часть II. Работа в сети сматриваемые нами примеры операционных систем содержат ранние версии протокола NFS, поэтому отдельные демоны по-прежнему запускаются по умолчанию. Вопросы безопасности Во многих аспектах версии V2 и V3 протокола NFS были типичными наследниками всех недостатков, касающихся вопросов безопасности в системах UNIX и Linux. Этот протокол изначально не предполагал никаких мер безопасности, и благодаря этому он был удобным. Версия NFSv4 устранила дефекты системы безопасности, которые были присущи предыдущим версиям, обеспечив сильную поддержку службам безопасности и внедрив более совершенную идентификацию пользователей. Все версии протокола NFS не зависят от механизма, обеспечивающего безопасность работы в сети, и большинство серверов поддерживают разные режимы аутентификации. Некоторые из этих режимов перечислены ниже. • AUTH_NONE — без аутентификации. • AUTH_SYS — способ управления доступом для пользователей и групп, напоми- нающий стиль системы UNIX. • RPCSEC_GSS — строгий режим аутентификации, предполагающий целостность и закрытость в дополнение к аутентификации. Традиционно в большинстве организаций применяется режим AUTH_SYS, который использует идентификаторы групп и пользователей в системе UNIX. В этой схеме при запросе к серверу клиент просто посылает локальный идентификатор пользователя и группы. Сервер сравнивает значения этих идентификаторов со значениями из своего файла /etc/passwd 2 и определяет, следует ли предоставлять доступ данному пользо- вателю. Таким образом, если два пользователя имеют одинаковые идентификаторы на двух разных клиентах, то они получат доступ ко всем файлам друг друга. Более того, пользователи, имеющие права администратора системы, могут применить команду su к любому идентификатору по своему усмотрению; после этого сервер предоставит им до- ступ к соответствующим файлам. Согласование файла passwd со всеми системами играет очень существенную роль в средах, использующих режим AUTH_SYS. Однако даже это — всего лишь иллюзия без- опасности; любой мошеннический узел (или Windows-машина) может “аутентифици- ровать” своих пользователей по своему желанию и тем самым разрушить безопасность протокола NFS. Для того чтобы предотвратить эти проблемы, большинство организаций использует более надежный механизм идентификации, такой как протокол Kerberos в сочетании со слоем NFS RPSSEC_GSS. Эта конфигурация требует от клиента и сервера совместно- го участия в работе механизма Kerberos. Механизм Kerberos аутентифицирует клиентов централизованно, тем самым предотвращая возможность самоидентификации, описан- ной выше. Кроме того, протокол Kerberos обеспечивает сильное шифрование и гаранти- рует целостность файлов, передаваемых по сети. Все системы, поддерживающие прото- кол NFS версии 4, должны реализовать режим RPCSEC_GSS, в то же время в версии 3 это требование не является строгим. Ш Более подробная информация о протоколе Kerberos изложена в разделе 22.10. Доступ к томам системы NFS обеспечивает файл /etc/exports, в котором пере- числены имена узлов (или IP-адреса), которые имеют право на доступ к совместно ис- 2 Или его эквивалента в виде сетевой базы данных, такой как NIS или LDAP.
Глава 18. Сетевой протокол Network File System 741 пользуемым файловым системам сервера. К сожалению, это слишком слабый механизм безопасности, поскольку сервер доверяет клиентам, называющим свой идентификатор. Клиента легко заставить солгать и указать неверный идентификатор и IP-адрес, поэтому этот механизм не слишком надежен. Тем не менее файловые системы следует экспорти- ровать только клиентам, заслуживающим доверия, и всегда следует проверять, не экс- портировали ли вы случайно файловые системы всему миру. Протокол NFSv4 использует в качестве транспортного протокола только TCP и обыч- но осуществляет связь через порт 2049. Поскольку протокол NFSv4 не использует другие порты, открыть доступ через брандмауэр так же просто, как открыть протокол ТС через порт 2049. Как и в случае со списком всех конфигураций доступа, кроме порта, следует идентифицировать адреса источника и пункта назначения. Если ваша организация не планирует предоставлять услуги протокола NFS узлам, расположенным в Интернете, за- блокируйте доступ через брандмауэр или используйте фильтр локальных пакетов. CQ Более подробная информация о брандмауэрах приведена в разделе 22.11. Мы не рекомендуем использовать для организации файловой службы в глобальных сетях протоколы NFSv2 и NFSv3, поскольку в протоколах RPC много ошибок и нет сильных механизмов безопасности. Администраторы серверов, работающих по протоко- лу NFS 3, должны блокировать доступ к TCP- и UDP-портам 2049, а также к порту 111 сервера portmap. Идентифицирующее отображение в версии 4 Как указывалось в главе 7, операционная система UNIX идентифицирует пользо- вателей с помощью набора индивидуальных и групповых идентификаторов, записан- ных в локальном файле passwd или административной базе данных. С другой сторо- ны, версия 4 протокола NFS представляет пользователей и группы в виде строковых идентификаторов, имеющих вид пользователь@п£s-домен или rpynnaenfs-домен. И клиенты, и серверы, работающие по протоколу NFS, запускают демона идентифици- рующего отображения (identity mapping daemon), который отображает значения иден- тификаторов UNIX в строки. Когда клиент, использующий версию 4, выполняет операцию, возвращающую иден- тификаторы, например команду Is -1, возвращающую листинг файла, демон иденти- фицирующего отображения использует свой локальный файл passwd для превращения пользовательских и групповых идентификаторов каждого файлового объекта в строку, например ben@atrust.com. Затем отображение идентификаторов клиентов выпол- няет обратное действие, превращая строку ben@atrust. com в локальные пользова- тельские и групповые идентификаторы, которые могут совпадать, а могут и не совпа- дать с идентификаторами сервера. Если строковое значение не соответствует ни одной локальной сущности, используется учетная запись анонимного пользователя. В этот момент вызов удаленной файловой системы (stat) завершается и возвраща- ет вызвавшей ее команде (в данном случае команде 1s) значения пользовательского и группового идентификаторов. Однако, поскольку команда 1s была выполнена с флагом -1, она должна вывести на экран текстовые имена, а не числа. Итак, команда 1s, в свою очередь, переводит идентификаторы обратно в текстовые имена, используя библиотеч- ные утилиты getpwuid и getgrgid. Эти утилиты еще раз проверяют файл passwd или эквивалентную ему базу данных. Какая долгая и запутанная процедура! К сожалению, идентифицирующее отображение используется только при извлечении и записи атрибутов файлов, как правило, используемых монопольно. Идентифицирующее
742 Часть II. Работа в сети отображение не играет никакой роли в процессе аутентификации и управлении доступом. Оно лишь переводит идентификаторы в форму, принятую в протоколе RPC. Следова- тельно, согласованность файлов passwd по-прежнему важна для пользователей, рабо- тающих в режиме “безопасности” AUTH_SYS. В системах, не синхронизирующих файлы passwd, вследствие неоднозначности иден- тификаторов и аутентификации возникает побочный эффект. Идентифицирующее ото- бражение может выполнять отображение точнее, чем базовый протокол NFS, вызывая противоречие между прямым доступом к файлам и доступом, на самом деле предостав- ляемым сервером, работающим по протоколу NFS. В качестве примера рассмотрим сле- дующие команды клиента протокола NFSv4. [ben@nfs-client]$ id ben uid=1000(ben) gid=1000(ben) groupd=1000(ben) [ben@nfs-client]$ id john uid=1010(john) gid=1010(john) groupd=1010(john) [ben@nfs-client]$ Is -Id ben drwxr-xr-x 2 john root 4096 May 2007 16:42 ben [ben@nfs-client] $ touch ben/file [ben@nfs-client]$ Is -1 ben/file -rw-rw-r— 1 john nfsnobody 0 May 2007 17:07 ben/file Мы видим, что пользователь ben имеет идентификатор 1000, a john — 1010. Рабочий каталог ben, экспортированный по протоколу NFS, имеет разрешение 775 и принадле- жит пользователю john. Однако пользователь ben может создать файл в этом каталоге, даже если вывод команды Is -1 означает, что у него нет прав на запись. На сервере пользователь john имеет идентификатор 1000. Поскольку на клиентском компьютере идентификатор пользователя john равен 1010, идентифицирующее отобра- жение выполняет преобразование идентификатора, как описано выше, и в результате пользователь john оказывается владельцем каталога. Однако демон идентифицирующего отображения не участвует в управлении доступом. Для создания файла непосредственно на сервер посылается идентификатор пользователя ben, равный 1000, который интер- претируется как идентификатор пользователя john. Как узнать, какие операции используют идентифицирующее отображение, а ка- кие нет? Это просто: как только пользовательский или групповой идентификатор по- является в интерфейсе файловой системы (например, в сочетании с командой stat или chown), он отображается. Если пользовательские или групповые идентификаторы неявно используются для управления доступом, они направляются через специальную систему аутентификации. К сожалению для администраторов, демоны идентифицирующего отображения не стандартизованы, поэтому их процессы конфигурирования на разных система могут быть разными. Специфика каждой системы описывается в разделе 18.5. Учетные записи root и nobody В общем случае пользователи должны иметь одинаковые привилегии в любой систе- ме, к которой они получают доступ. Однако традиционно системные администраторы стараются ограничивать возможности неконтролируемого применения прав привилеги- рованного пользователя в файловых системах, смонтированных посредством NFS. По умолчанию сервер NFS перехватывает входящие запросы, посылаемые от имени пользо-
Глава 18. Сетевой протокол Network File System 743 вателя с идентификатором 0, и “делает вид”, будто они поступают от другого пользова- теля. Этот прием называется “поражением в правах” (“squashing root”). Таким образом, учетная запись root не отменяется, но уравнивается в правах с обычными учетными записями. Для этого специально определена фиктивная учетная запись nobody, чтобы под нее “маскировался” пользователь root, работающий на сервере NFS. Традиционно ее иден- тификатор равен 65534 (обратный код числа -2)3. Значения UID и GID для пользователя root в файле exports можно изменить. С помощью опции all squash можно заста- вить систему преобразовать все клиентские идентификаторы пользователей в одинако- вый серверный идентификатор. Если идентификатор равен -1, то в системах Solaris и HP-UX доступ вообще запрещается. Все эти предосторожности преследуют благородную цель, однако конечный резуль- тат далек от идеала. Даже будучи клиентом NFS, пользователь root может с помощью команды su “принять облик” любого пользователя, так что файлы никогда не бывают полностью защищены. Единственный эффект от смены идентификаторов заключается в том, что предотвращается доступ к файлам, которые принадлежат пользователю root и недоступны для чтения или записи остальным пользователям. Производительность версии 4 Протокол NFSv4 был разработан для того, чтобы обеспечить высокую производи- тельность в глобальных сетях. Большинство глобальных сетей имеет более долгое вре- мя ожидания и меньшую пропускную способность, чем локальные сети. Протокол NFS должен был решить эти проблемы с помощью следующих усовершенствований. • Процедура протокола RPC под названием COMPOUND включает несколько фай- ловых операций в один запрос, сокращая время ожидания при выполнении мно- гочисленных сетевых запросов. • Механизм делегирования позволяет кеширование файлов на клиентской стороне. Клиенты могут сохранять контроль над локальными файлами, включая их откры- тие для записи. Эти функциональные возможности являются частью ядра протокола NFS и не требу- ют специального внимания со стороны системного администратора. Дисковые квоты Доступ к информации о дисковых квотах на удаленном компьютере осуществляет серверный демон rquotad, также работающий отдельно от NFS. Сервер NFS будет под- держивать дисковые квоты, но пользователи не смогут ничего о них узнать, если на уда- ленном компьютере не работает демон rquotad. Мы считаем механизм дисковых квот морально устаревшим, поэтому не будем рас- сказывать об этом демоне. Однако некоторые организации по-прежнему поддерживают его работу, чтобы пользователи не захватили все доступное пространство на диске. Если вы поддерживаете работу сети в одной из таких организаций, то обратитесь к справоч- ной странице, посвященной квотам. Больше мы к этому вопросу возвращаться не будем. 3 На сервере NFS в Red Hat стандартное значение UID равно -2, тогда как в файле passwd учетной записи nobody присвоен идентификатор 99. Можно оставить все как есть, добавить в файл passwd запись с идентификатором -2 или задать параметры anonuid и anongid равными 99.
744 Часть II. Работа в сети 18.3. Серверная часть протокола NFS Говорят, что сервер NFS “экспортирует” каталог, когда он делает этот каталог доступ- ным для использования другими компьютерами. Системы Solaris и HP-UX вместо слова “экспорт” используют словосочетание “совместное использование”. Для того чтобы не создавать путаницы, мы будем на протяжении этой главы использовать термин “экспорт”. В версии NFSv3 процесс, используемый клиентами для монтирования файловой си- стемы (т.е. для того, чтобы узнать секретный ключ), отделен от процесса, используемого для доступа к файлам. Эти операции используют отдельные протоколы, а запросы обра- батываются разными демонами: mountd — для запросов на монтирование и nf sd — для реальной файловой службы. В некоторых системах эти демоны называются rpc.nfsd и rpc. mountd, поскольку они основаны на протоколе RPC (а значит, для их запуска ну- жен сервер postmap). В этой главе для простоты мы будем пропускать префикс грс. Версия NFSv4 не использует демон mountd вообще. Однако, если не все ваши кли- енты используют версию NFSv4, демон mountd следует выполнять. На сервере NFS демоны mountd и nf sd должны запускаться при загрузке системы и должны работать на протяжении всего времени ее функционирования. Сценарии за- грузки системы обычно автоматически запускают этих демонов, если существует какая- либо конфигурация экспорта. Имена сценариев запуска сервера NFS для каждой из рас- сматриваемых нами платформ перечислены в табл. 18.1. Таблица 18.1. Сценарии запуска сервера NFS Система ч . Путьксценарию - - -M’ Ubuntu /etc/init.d/nfs-kernel-server /etc/init.d/nfs-common SUSE /etc/init.d/nfsservera Red Hat /etc/rc.d/init.d/nfs Solaris /etc/init.d/nfs.server HP-UX /sbin/init.d/nfs.server AIX /etc/rc.nfs а /etc/init. d/nfs монтирует клиентскую файловую систему NFS. Протокол NFS использует единую базу данных для управления доступом, которая определяет, какие файловые системы должны быть экспортированы и какие клиен- ты должны их монтировать. Оперативная копия этой базы данных обычно хранится в файле xtab (sharetab — в системах Solaris и HP-UX), а также во внутренних табли- цах ядра. Поскольку файлы xtab и sharetab не предназначены для чтения людьми, для добавления и модификации записей в них используются вспомогательные команды exports или share. Для удаления записей из таблицы экспорта используются команды exportfs -и или unshare. Монтирование бинарного файла вручную — неблагодарная задача, поэтому в большин- стве систем предполагается, что пользователь монтирует текстовый файл, а не перечисля- ет экспортируемые системные каталоги и их установки доступа. Система может прочитать этот текстовый файл при загрузке и автоматически создать файл xtab или shatretab. В большинстве систем каталог /etc/exports является каноническим списком, до- ступным для чтения экспортируемых каталогов. Его содержимое можно прочитать с помощью команды exportfs -а. В системах Solaris и HP-UX каноническим списком
Глава 18. Сетевой протокол Network File System 745 является /etc/dfs/dfstab, который представляет сценарий, составленный из команд share. (Команда shareall сканирует в файле dfstab команды, связанные с протоко- лом NFS, и выполняет их. Поскольку протокол NFS — единственная “родная” система совместного использования файлов, подчиняющаяся этим правилам, команда shareall эквивалентна команде sh /etc/dfs/dfstab.) Информация, приведенная в предыдущих разделах, подытожена в табл. 18.2. В ней указано, какой файл следует отредактировать, если вы хотите экспортировать новую файловую систему, и что делать, если вы хотите ввести в действие внесенные вами ис- правления. Таблица 18.2. Где задаются экспортируемые каталоги Система Linux /etc/exports Выполнить команду /usr/sbin/exportfs -а Solaris /etc/dfs/dfstab Выполнить команду shareall HP-UX /etc/dfs/dfstab Выполнить команду shareall AIX /etc/exports Выполнить команду /usr/sbin/exportfs -а Протокол NFS работает с логическим уровнем файловой системы. Любой каталог можно экспортировать; он не обязан быть точкой монтирования или корнем физиче- ской файловой системы. Однако с точки зрения безопасности протокол NFS различает границы между файловыми системами и требует, чтобы каждое устройство было смон- тировано отдельно. Например, на компьютере, имеющем отдельный раздел /users, можно было бы экспортировать корневой каталог без экспорта каталога /users.4 Клиентам обычно разрешается монтировать подкаталоги экспортируемых катало- гов, если это необходимо, хотя протокол этого не требует. Например, если сервер экс- портирует каталог /chimchim/users, то клиент может смонтировать только каталог /chinchim/users/ joe и игнорировать остальную часть каталога users. Большинство версий системы UNIX не позволяет экспортировать подкаталоги с раз- ными опциями, но на практике в системе Linux это возможно. Команда share и файл dfstab (Solaris, HP-UX) Сценарий /etc/dfs/dfstab однократно выполняет команду share для каж- SOiariS дой экспортируемой файловой системы. Например, на сервере, использую- щем каталог /home совместно с узлами monk и leopard (причем узел monk имеет права привилегированного пользователя) и каталог /usr/share/man — совместно с узлами ross и harp, файл /etc/dfs/dfstab может содержать сле- дующие команды. share -F -nfs -о rw=monk.atrust.com:leopard.atrust.com,root=monk.atrust.com /home share -F -nfs -0 rw=ross.atrust.com:harp.atrust.com /usr/share/man После редактирования файла /etc/dfs/dfstab следует обязательно выполнить ко- манду shareall, чтобы ввести в действие сделанные изменения. Поскольку команда shareall просто выполняет команды, записанные в файле dfstab, она не выводит из совместного использования удаленные вами файловые системы. Для того чтобы удалить файловую систему из совместного использования, следует выполнить команду unshare /путъ/к/файлам. Наиболее полезные опции команды share перечислены в табл. 18.3. 4 Разумеется, никогда не следует экспортировать корневой каталог.
746 Часть II. Работа в сети Таблица 18.3. Опции команды share (Solaris, HP-UX) Опция Описание ГО Экспортирует файловую систему только для чтения всему миру (не рекомендуется) го = список Экспортирует файловую систему только для чтения, открывая доступ только для поль- зователей, перечисленных в списке rw Экспортирует файловую систему для чтения и записи всему миру (не рекомендуется) rw = список Экспортирует файловую систему для чтения и записи, открывая доступ только для пользователей, перечисленных в списке root = список Перечисляет узлы, которым разрешен доступ к данной файловой системе с правами привилегированного пользователя; в противном случае привилегированный доступ кли- ента означает доступ “анонимного” пользователя (как правило, с идентификатором -2) anon = иден- Задает идентификатор, в который должен отображаться корень; по умолчанию счита- тификатор ется анонимным nosub Запрещает клиентам монтировать подкаталоги в экспортированном каталоге nosuid Запрещает создавать файлы setuid и setgid в системе NFS Если в качестве параметра команды share указывается список, то он должен состо- ять из групп элементов, разделенных двоеточиями. В табл. 18.4 перечислены все спосо- бы, которыми можно задать узлы или группы узлов. Таблица 18.4. Спецификации клиента для команды share Тип Синтаксис Описание Имя узла имя_узла Отдельные узлы (должны быть полностью указаны) Сетевая группа имя_группы Сетевые группы NIS (используется редко) Домены DNS .домен, сот Любой узел внутри домена IP-сети @имя_сети Имена сетей, как указано в файле /etc/networks а а Допускаются также спецификации в стиле CIDR, например @128.138.92.128/25. Замечание в табл. 18.4, касающееся имен узлов, можно назвать излишним: отдельные имена узлов должны быть указаны полностью или они будут проигнорированы. Для того чтобы явно закрыть доступ к элементу, достаточно поставить перед его име- нем косую черту. Список просматривается слева направо во время каждого сканирова- ния в поисках соответствующего элемента, поэтому символы отрицания должны пред- шествовать более общим элементам, которые они модифицируют. Например, строка share -F -nfs -0 -rw=-@192.168.10.0/25:.booklab.atrust.com /users экспортирует каталог /users, допускающий чтение и запись, во все узлы домена DNS book. atrust. com, за исключением узлов сети 192.168.10. В этой команде флаг -F озна- чает, что команда share должна использовать файловую систему nfs, а не системы, перечисленные в файле /etc/dfs/fstypes. Некоторым клиентам можно экспортировать каталог только для чтения, а другим — для чтения и записи. Для этого данных клиентов следует включить в опции го= и rw= соответственно. Справочная страница команды share содержит только несколько основных пара- метров протокола NFS. Полный список этих параметров можно найти на справочной странице команды share_nf s.
Глава 18. Сетевой протокол Network File System 747 Команда exports и файл exports (Linux, AIX) ДФайл exports содержит список экспортированных каталогов в левом столбце и список связанных с ними параметров в правом. Например, строка в файле • exports в системе AIX выглядит следующим образом. /home -vers=4,sec-sys,access=harp.atrust.com Это позволяет монтировать каталог /home на машине harp.atrust.com с помощью протокола NFS и механизма аутентификации системы UNIX (sec-sys). Файловые системы, перечисленные в файле exports без указания узлов, монтиру- ются на всех компьютерах, что является значительной брешью в системе безопасности. Параметры и синтаксические конструкции, используемые в файле exports, изме- няются от системы к системе, хотя между ними существует определенная тематическая схожесть. В следующем разделе описываются общие форматы для систем AIX и Linux. Как всегда, точную информацию следует искать в справочной системе. Файл exports в системе AIX ©Формат файла exports в системе AIX можно назвать самым классическим из всех рассматриваемых в книге систем. Допустимые параметры перечислены в табл. 18.5. Таблица 18.5. Параметры файла exports в системе AIX Параметр ' * ' ... ... _ Описание г..;. access=список Перечисляет узлы, которые могут монтировать файловую систему го Экспортирует файловую систему всем только для чтения; ни один клиент не может ничего записывать в эту файловую систему rw Экспортирует файловую систему всем для чтения и записи (по умолчанию) rw=^ СПИСОК Экспортирует файловую систему, в основном, для чтения. Список перечисляет узлы, которым разрешается монтировать файловую систему для записи; все остальные клиенты должны только читать эту систему ГOOt=СПИСОК Узлы, указанные в списке, могут монтировать файловую систему как привилегирован- ный пользователь. Без этой опции привилегированный доступ клиента эквивалентен доступу анонимного пользователя vers=n Экспортирует каталог клиентам с помощью версии п. Корректными значениями счи- таются 2,3 и 4 sec=режим Задает список методов обеспечения безопасности для экспортируемого каталога. Допускаются значения sys (аутентификация в системе UNIX), dh (DES), krb5 (аутен- тификация по протоколу Kerberos), krb5i (аутентификация и защита целостности по протоколу Kerberos), krb5p (аутентификация, также защита целостности и конфи- денциальности по протоколу Kerberos) и попе (анонимный доступ; не рекомендуется) anon=n Задает идентификатор, в который отображаются привилегированные пользователи. По умолчанию значение равно -2 (аноним). Задав значение -1, можно вообще запре- тить привилегированный доступ В табл. 18.5 список состоит из имен узлов и сетевых групп, разделенных двоеточиями. Параметры в табл. 18.5 похожи на параметры команды share. Однако между ними есть небольшая разница. Например, параметр rw=leopard.atrust.com:ross.atrust.com
748 Часть II. Работа в сети в команде share означает экспорт каталога для чтения и записи с предоставлением до- ступа только перечисленным узлам. В системе AIX этот параметр позволяет всем монти- ровать данный каталог только для чтения. Ясно! В системе AIX вы должны использовать параметр access, чтобы ограничить доступ к каталогу заданным списком клиентов. rw, access=leopard.atrust.com:ross.atrust.com По умолчанию каталог экспортируется для чтения и записи, поэтому параметр rw можно не указывать. Тем не менее его указание ошибкой не является. Каждая строка в файле exports в системе AIX должна состоять из пути к каталогу, разделителя и дефиса, за которым следует список параметров, разделенных запятыми. Например, приведенная ниже команда открывает узлу leopard, atrust. com доступ к каталогу /home в режиме безопасности AUTH_SEC и в рамках четвертой версии про- токола NFS. /home -vers=4,sec=sys,rw,access=leopard.atrust.com Помните, что после изменения файла /etc/exports следует выполнить команду exportfs. Файл exports в системе Linux ДКак и в системе AIX, в* системе Linux файл /etc/exports содержит перечис- ление файловых систем, экспортируемых в рамках протокола NFS, а также кли- ентов, которые могут иметь к ним доступ. Список клиентов отделен от списка файловых систем пробелами, и после имени каждого клиента в скобках зада- ется список параметров, разделенных запятыми. Длинные строки можно раз- делять на несколько с помощью обратной косой черты. Вот как выглядит этот формат. /home harp(rw,no_root_squash) monk(rw) /usr/share/man *.atrust.com(ro) Этот формат не позволяет задать сразу несколько клиентов с одинаковыми набора- ми параметров, хотя некоторые спецификации клиентов можно распространить на не- сколько узлов. В табл. 18.6 приведены четыре типа спецификаций, которые могут поя- виться в файле exports. Таблица 18.6. Спецификации клиента в файле /etc/exports в системе Linux Имя узла имя_узла Отдельные узлы Сетевая группа @ имя_группы Сетевые группы NIS (используется редко) Шаблонный символ *и? Полностью определенные имена доменов * с шаблонными символами, причем символ не может заменять точку IP-сети 1р_адрес/маска Имена сетей, как указано в файле /etc/networksа а Fully qualified domain names (FQDN). В табл. 18.7 перечислены основные параметры экспорта, используемые в системе Linux. В системе Linux сервер NFS имеет необычные функциональные возможности, по- зволяющие экспортировать подкаталоги экспортируемых каталогов с разными параме- трами. Для подкаталогов, которые вы предпочитаете исключить из общего использова- ния, следует использовать параметр noaccess.
Глава 18. Сетевой протокол Network File System 749 Таблица 18.7. Основные параметры экспорта в системе Linux Опция ' ' *' ro Экспорт только для чтения rw Экспорт для чтения и записи (по умолчанию) rw = список Экспорт преимущественно для чтения; в списке перечисляются узлы, которым разрешено монтировать файловую систему для записи; остальные должны монти- ровать ее только для чтения root_squash Отображает (“поражает в правах”) идентификаторы UID 0 и GID 0 в значения, задан- ные параметрами anonuid и anongid.а Этот параметр задается по умолчанию no_root_squash all_squash Разрешает привилегированный доступ для всех. Опасно! Отображает все идентификаторы UID и GID в значения, установленные для ано- нимных пользователей. Целесообразно для персональных компьютеров и отдель- ных узлов, не вызывающих доверия anonuid=xxx Задает идентификатор UID для удаленных привилегированных пользователей, ко- торых следует лишить привилегий anongid=xxx Задает идентификатор GID для удаленных привилегированных пользователей, ко- торых следует лишить привилегий secure insecure Допускает удаленный доступ только через привилегированный порт Допускает удаленный доступ через любой порт noaccess Блокирует доступ к данному каталогу и подкаталогам (используется при вложен- ном экспорте) wdelay no_wdelay async Откладывает запись в ожидании объединенных обновлений Немедленно записывает данные на диск Заставляет сервер отвечать на запросы до того, как запись на диск будет выполне- на в действительности nohide hide Выявляет файловые системы, смонтированные в дереве экспортированных файлов Противоположен по смыслу параметру nohide subtree_check no_subtree_check Проверяет, находится ли запрашиваемый файл в экспортированном дереве Проверяет лишь, относится ли запрашиваемый файл к экспортированной файло- вой системе secure_locks insecure_locks sec=режим Требует авторизации для всех запросов на блокировку Использует менее строгие критерии блокировки (поддерживает старых клиентов) Задает список методов обеспечения безопасности для экспортируемого каталога. Допускаются значения sys (аутентификация в системе UNIX), dh (DES), krb5 (ау- тентификация по протоколу Kerberos), krb5i (аутентификация и защита целост- ности по протоколу Kerberos), krb5p (аутентификация, также защита целостности и конфиденциальности по протоколу Kerberos) и попе (анонимный доступ; не рекомендуется) id-num Задает псевдофайловую систему в версии 4 (обычно 0) а В отличие от большинства операционных систем, Linux разрешает “поражение в правах” не только приви- легированных клиентов. Более подробно это изложено в пункте all_squash. Например, конфигурация /home *.atrust.com(rw) Zhome/ben (noaccess)
750 I Часть II. Работа в сети позволяет узлам в домене atrust. com иметь доступ ко всему содержимому каталога /home, за исключением подкаталога /home/ben. Отсутствие имени клиента во второй строке означает, что данный параметр относится ко всем узлам; возможно, тем самым можно достичь более высокой степени безопасности. Параметр subtree_check (по умолчанию) проверяет, принадлежит ли файл, к ко- торому обращается клиент, к экспортированному подкаталогу. Если этот параметр от- ключить, то будет проверяться только факт, что файл находится в экспортированной файловой системе. Проверка поддерева может вызвать неожиданные проблемы, если запрашиваемый файл был переименован, пока клиент держал его открытым. Если такие ситуации возникают часто, следует выбрать параметр no subtree check. Параметр secure locks требует авторизации и аутентификации при блокировке файла. Некоторые клиенты системы NFS не посылают мандатов вместе с запросами на блокировку и не работают с параметром secure locks. В этом смысле существует возможность заблокировать файлы, доступные для всеобщего чтения. Лучше всего за- менить этих клиентов теми, кто посылает мандаты. Однако в качестве временной меры можно использовать и параметр insecure locks. Демон mountd в системе Linux можно запускать без демона inetd. Эта конфигурация позволяет обеспечить дополнительный контроль за доступом с помощью сетевого ана- лизатора tcpd. Более полная информация по этому вопросу приведена в разделе 22.8. Демон nfsd: обслуживание файлов После того как демон mountd убедился в правильности клиентского запроса на мо- нтирование, клиенту разрешается запрашивать различные операции над файлами. Эти запросы обрабатываются на сервере демоном nfsd5. Он не должен выполняться на компьютере-клиенте NFS. Единственное исключение — когда клиент сам экспортирует файловые системы. Демон nfsd принимает числовой аргумент, определяющий, сколько экземпляров самого себя нужно породить посредством системного вызова fork. Правильный выбор числа про- цессов очень важен, но, к сожалению, это из области черной магии. Если это число будет слишком мало или слишком велико, производительность сервера NFS может снизиться. Оптимальное количество выполняющихся демонов nfsd зависит от операционной системы и используемого аппаратного обеспечения. Если вы заметили, что команда ps обычно показывает количество демонов в состоянии D (непрерываемый сон) и при этом наблюдается простой центрального процессора, попробуйте увеличить количество потоков. Если при добавлении демонов nfsd происходит увеличение средней загрузки (о чем сообщает команда uptime), значит, вы слишком увлеклись и следует вернуться к прежнему состоянию. Кроме того, следует регулярно выполнять команду nfsstat и проверять производительность, которая может зависеть от количества выполняемых де- монов nfsd. Более подробно демон nfsd описан в разделе 18.6. На интенсивно эксплуатируемом сервере NFS версии 2 или 3 с большим числом UDP-клиентов буферы UDP-сокетов могут переполниться, если запросы начнут посту- пать в то время, когда все демоны nfsd уже задействованы. Число переполнений мож- но узнать с помощью команды netstat -s. Запускайте дополнительные демоны до тех пор, пока число переполнений не упадет до нуля, так как переполнение свидетельствует о серьезной нехватке серверных демонов. 5 Демон nfsd всего лишь осуществляет не предусматривающий ответа системный вызов, код которого встроен в ядро.
Глава 18. Сетевой протокол Network File System 751 Для изменения числа запускаемых демонов nf sd следует отредактировать соответ- ствующий сценарий в файле конфигурации. Расположение этого файла и доступные параметры зависят от системы. Их примеры приведены в табл. 18.8. Внеся изменения в файл конфигурации демона nf sd, необходимо заново запустить службу с помощью сценариев, перечисленных в табл. 18.1. Таблица 18.8. Как задать количество выполняемых демонов nfsd Система Ubuntu SUSE Red Hat Solaris HP-UX AIX default/nfs-kemel-server RPCNFSDCOUNT 8 sysconfig/nfs USE.KERNEL.NFCD.NUMBER 4 sysconfig/nfs RPCNFSDCOUNT 8 default/nfs NFSD.SERVER 16 default/nfs NFSD.SERVER 16 Для изменения количества выполняемых демонов nfsd используется программа SMIT или команда chnfs. 18.4. Клиентская часть протокола NFS Процессы монтирования сетевых и локальных файловых систем во многом схожи. Ко- манда mount понимает запись вида имя_узла: каталог как путь к каталогу, расположен- ному на указанном компьютере. Этому каталогу будет поставлен в соответствие каталог локальной файловой системы. По завершении монтирования доступ к сетевой файловой системе осуществляется традиционнышгсредствами. Таким образом, команда mount и ее NFS-расширения — самое важное для системного администратора на NFS-клиенте. Для того чтобы файловую систему NFS можно было монтировать, ее необходимо со- ответствующим образом экспортировать (об этом рассказывалось выше). Клиентская команда showmount позволяет клиенту проверить, правильно ли сервер экспортирует файловые системы. $ showmount -е monk Export list for monk: /home/ben harp.atrust.com Как следует из этого примера, каталог /home/ben на сервере monk экспортирован в клиентскую систему harp. atrast. com. Если сетевая файловая система по какой-то причине не работает, возможно, вы просто забыли выполнить команду exportfs -а по- сле редактирования файла exports. Проверьте после этого вывод команды showmount. Если каталог был правильно экспортирован на сервере, а команда showmount со- общает об ошибке или возвращает пустой список, внимательно проверьте^ все ли не- обходимые процессы запущены на сервере (portmap, mountd, nfsd, statd и lockd), разрешен ли в файлах hosts. allow и hosts. deny доступ к этим демонам и, вообще, та ли это клиентская система. Ш Более подробная информация о файлах hosts.* и системе TCP Wrapper приведена в раз- деле 22.8. Информация о пути, отображаемая командой showmount, например /home/ben, как в предыдущем случае, является корректной только в версиях протокола NFS 2 и 3. Серверы, работающие в рамках протокола NFS 4, экспортируют целостную и единоо-
752 Часть II. Работа в сети1 бразную псевдофайловую систему. Традиционная концепция протокола NFS, относяща- яся к разным точкам монтирования, в версии 4 не работает, поэтому команду showmount применять нельзя. К сожалению, достойной альтернативы команде showmount в версии NFS 4 нет. На сервере команда exportfs -v демонстрирует существующие экспортированные файло- вые системы, но она работает только в локальном масштабе. Если у вас нет прямого доступа к серверу, смонтируйте корень псевдофайловой системы сервера и пройдите по структуре каталогов вручную, отметив каждую точку монтирования. Реальное монтирование файловой системы осуществляется примерно такой командой. $ sudo mount -о rw,hard,intr,bg monk:/home/ben /nfs/ben Для того чтобы сделать то же самое в версии 4 под управлением системы Linux, вы- полните следующую команду. $ sudo mount -t nfs4 -о rw,hard,intr,bg monk: / nfs/ben В данном случае указанные после опции -о флаги говорят о том, что файловая си- стема монтируется в режиме чтения/записи (rw), файловые операции разрешается пре- рывать (intr), а повторные попытки монтирования должны выполняться в фоновом режиме (bg). Наиболее распространенные флаги приведены в табл. 18.9. Таблица 18.9. Флаги монтирования NFS Монтирование файловой системы для чтения/записи (она должна экспортировать- ся сервером в режиме чтения/записи) Монтирование файловой системы только для чтения Если смонтировать файловую систему не удается (сервер не отвечает), следует перевести операцию в фоновый режим и продолжить обработку других запросов на монтирование Если сервер отключился, операции, которые пытаются получить к нему доступ, блокируются до тех пор, пока сервер не включится вновь Если сервер отключился, операции, которые пытаются получить к нему доступ, за- вершаются выдачей сообщения об ошибке. Этот флаг полезно устанавливать для того, чтобы предотвратить зависание процессов в случае неудачного монтирова- ния не очень важных файловых систем Позволяет прерывать с клавиатуры заблокированные операции (будут выдаваться сообщения об ошибке) Не позволяет прерывать с клавиатуры заблокированные операции Указывает, сколько раз нужно повторить запрос, прежде чем будет выдано со- общение об ошибке (для файловых систем, смонтированных с флагом soft) Задает интервал тайм-аута для запросов (в десятых долях секунды) Задает размер буфера чтения равным п байт Задает размер буфера записи равным п байт Задает режим безопасности Задает версию протокола NFS proto = протокол Выбирает транспортный протокол; им должен быть протокол top для версии NVS 4 а Несмотря на то что флаг vers указан на справочных страницах систем Linux, посвященных команде mount, использование ее результатов является ошибкой. Для того чтобы задать четвертую версию протокола NFS, следует выполнить команду mount -t nfs4. rw го bg hard soft intr nointr retrans=n timeo=n rsize=n wsize=n зес=режим ------a
Глава 18. Сетевой протокол Network File System 753 Файловые системы, смонтированные с флагом hard (установка по умолчанию), мо- гут вызывать зависание процессов при отключении сервера. Это особенно неприятно, когда такими процессами оказываются стандартные демоны. Вот почему не рекомен- дуется обслуживать ключевые системные программы через NFS. В общем случае ис- пользование флагов soft и intr позволяет сократить число проблем, связанных с NFS. Но эти же флаги могут вызывать нежелательные побочные эффекты (например, оста- нов 20-часового процесса моделирования из-за временного сбоя в сети после 18 часов работы)6. Исправить некоторые недостатки монтирования позволяют средства автома- тического монтирования, например демон autofs (описывается далее). Размеры буферов чтения и записи применимы в отношении обоих протоколов — TCP и UDP, но оптимальные значения различны. В случае TCP буфер должен быть большим, поскольку данные передаются эффективнее. Хорошее значение — 32 Кбайт. В случае UDP, если сервер и клиент находятся в одной сети, оптимальный размер равен 8 Кбайт. Тем не менее по умолчанию принят размер 1 Кбайт, хотя даже на шап-странице рекомендуется повысить это значение до 8 Кбайт. Протестировать точку монтирования можно с помощью команды df, как если бы это была обычная локальная файловая система. % df /nfs/ben Filesystem lk-blocks Used Available Use% Mounted on Itopard:/home/ben 17212156 1694128 14643692 11% /nfs/ben Разделы NFS демонтируются командой umount. Если сетевая файловая система кем- то используется в момент демонтирования, будет выдано сообщение об ошибке. umount: /nfs/ben: device is busy Найдите с помощью команды Isof процессы, у которых есть открытые файлы в этой файловой системе, и уничтожьте эти процессы либо смените каталоги в случае интер- претаторов команд. Если ничего не помогает или сервер отключен, воспользуйтесь ко- мандой umount -f для принудительного демонтирования. Д Стоит повторить сноску в табл. 18.9: по умолчанию команда mount системы Linux, распознав в командной строке синтаксическую конструкцию имя_ узла:каталог, выбирает тип файловой системы nf s, который является кор- ректным только в версиях 2 и 3. Для того чтобы задать четвертую версию про- токола NFS, следует выполнить команду mount -t nfs4. Монтирование файловых систем NFS на этапе начальной загрузки С помощью команды mount можно создавать лишь временные сетевые точки мон- тирования. Файловые системы, которые являются частью постоянной конфигурации, должны быть перечислены в файле /etc/fstab (/etc/vfstab в системе Solaris), для того чтобы они автоматически монтировались на этапе начальной загрузки. С другой 6 Джефф Форис (JefTForys), один из наших рецензентов, заметил по этому поводу: “Боль- шинство сетевых файловых систем должно монтироваться с флагами hard, intr и bg, поскольку они наилучшим образом соответствуют исходной концепции NFS (надежность и отсутствие ин- формации о состоянии). Флаг soft — это мерзкий сатанинский трюк! Если пользователь захочет прервать операцию монтирования, пусть он сделает это сам. В противном случае следует дождаться включения сервера, и все в конце концов нормализуется без какой бы то ни было потери данных”.
754 Часть II. Работа в сети стороны, они могут обрабатываться утилитой автоматического монтирования, например демоном autofs. Ш Более подробная информация о демоне autofs приведена в разделе 18.8. Следующие элементы файла fstab предназначены для монтирования файловых си- стем /home и /usr/local компьютеров monk и ross. # filesystem mountpoint fstype monk:/home /nfs/home nfs ross:/usr/local /usr/local nfs4 flags dump fsck rw,bg,intr,hard,nodev,nosuid 0 0 ro,bg,intr,soft,nodev,nosuid 0 0 При добавлении элементов в файл fstab обязательно создавайте каталоги soians точек монтирования с помощью команды mkdir. Можно сделать так, чтобы изменения вступили в силу немедленно (без перезагрузки). Для этого следует выполнить команду mount -a -t nfs, которая смонтирует все файловые си- стемы типа nfs, перечисленные в файле fstab. Формат файла /etc/vfstab в системе Solaris немного отличается, но пара- soiaris метры остаются прежними. Параметры протокола NFS в основном являются одинаковыми у всех систем. ®Для конфигурирования процесса монтирования системы NFS в процессе за- грузки операционной системы AIX используется программа SMIT. Не надо редактировать файл /etc/filesystems вручную, потому что он может быть записан заново при импорте или экспорте группового тома. Ш Более подробная информация о файле fstab приведена в разделе 8.9. Добавляя записи в файл /fstab/vfstab, не забудьте создать соответствующие ката- логи в точке монтирования с помощью команды mkdir. Эти изменения можно ввести в действие немедленно (без перезагрузки), выполнив команду mount -a -F nfs в си- стемах Solaris или HP-UX; в системе Linux вместо флага -а необходимо использовать флаг -F, а версия 4 монтируется с помощью команды mount -a -t nfs4. В системе AIX файловые системы NFS можно смонтировать с помощью команды mount -v nfs -а. В поле flags файла /etc/fstab задаются параметры точек монтирования NFS. Это те же параметры, которые указываются в командной строке mount. Ограничения на выбор порта Клиентам NFS разрешается использовать любой TCP- или UDP-порт для подклю- чения к серверу NFS. Однако некоторые серверы могут требовать, чтобы запросы по- ступали из привилегированного порта (номер которого меньше 1024). Другие серверы позволяют выбирать порт по своему усмотрению. Впрочем, в мире персональных ком- пьютеров и настольных Linux-систем применение привилегированных портов не приво- дит к реальному повышению безопасности системы. Большинство клиентов протокола NFS следуют традиционному (и по-прежнему ре- комендуемому) подходу: по умолчанию выбирается привилегированный порт, что по- зволяет избежать ненужных конфликтов. Для того чтобы разрешить запросы на мон- тирование, поступающие из непривилегированных портов, в системе Linux можно использовать параметр insecure.
Глава 18. Сетевой протокол Network File System 755 18.5 Идентифицирующее отображение в протоколе NFS 4 В отличие от ранних версий протокола NFS, в которых пользователи идентифициро- вались просто по идентификаторам UID и GID, в версии 4 используются строки, имею- щие вид пользователь@nfз_домен и rpynna@nf з_домен. Как на серверной, так и на клиентской стороне демон идентифицирующего отображения выполняет преобразова- ние строковых идентификаторов в значения локальных идентификаторов UID и GID и наоборот. Отображенные значения используются для трансляции файла, содержа- щего информацию об атрибутах, но не для управления доступом, которое реализуется отдельно. Все системы, участвующие в работе системы по протоколу NFSv4, должны иметь одинаковые домены NFS. В большинстве случаев в качестве домена NFS целесообраз- но использовать свой домен DNS. Например, естественно выбрать atrust. com в ка- честве домена NFS для сервера harp. atrust. com. Клиенты в поддоменах (например, booklab. atrust. com) могут при желании использовать более короткие имена сайта (например, atrust. com) для реализации взаимодействия в рамках протокола NFS. К сожалению для администраторов, стандартной реализации отображения иденти- фикаторов UID в протоколе NFSv4 не существует. В табл. 18.10 перечислены демоны идентифицирующего отображения в каждой из систем и указано местонахождение их конфигурационного файла. Таблица 18.10. Демоны идентифицирующего отображения и их конфигурации Система Демон * 1Сонфй1уа1^- Linux /usr/sbin/rpc.idmapd /etc/idmapid.conf Solaris /usr/lib/nfs/nfsmapid /etc/default/nfsa HP-UX /usr/lib/nfs/nfsmapid /etc/default/nfsa AIX /usr/sbin/nfsgyd chnfsdom домен а Домен задается параметром NFSMAID.DOMAIN. Кроме указания доменов NFS, для реализации идентифицирующего отображения необходима дополнительная помощь системного администратора. Демон запускается в момент загрузки системы в том же самом сценарии, который управляет системой NFS. После внесения изменения в файл конфигурации необходимо вновь запустить демон. Параметры, определяющие, например, детализацию вывода и альтернативное управле- ние анонимной учетной записью, обычно являются доступными; более подробную ин- формацию следует искать на справочной странице, посвященной демону идентифици- рующего отображения. 18.6. Команда nfsstat: отображение статистики NFS Команда nfsstat отображает различные статистические данные, накапливаемые в системе NFS. Команда nfsstat -s выдает статистику процессов сервера NFS, а коман- да nfsstat -с отображает информацию, касающуюся клиентских операций. % nfsstat -с Client rpc:
756 Часть II. Работа в сети calls 62235 badcalls 1595 retrans 0 badxid 3. timeout wait newscred timers 886 1592 0 0 Client calls 62213 nfs: badcalls 3 nclget 62643 nslsleep 0 null getattr setattr readlink lookup root read 0% 34% 0% 21% 30% 0% 2% write wrcache create remove rename link symlink 3% mkdir 0% 0% readdr 6% 0% rmdir 0% 0% fsstat 0% 0% 0% 0% Приведенные результаты получены на нормально функционирующем сервере NFS. Если более 3% вызовов терпят неудачу, то это говорит о наличии проблем на NFS-сер- вере или в сети. Как правило, причину можно выяснить, проверив значение параметра badxid. Если его значение близко к нулю, а количество тайм-аутов больше 3%, то па- кеты, поступающие на сервер и отправляемые с него, теряются в сети. Решить эту про- блему можно, уменьшив значение параметров монтирования rsize и wsize (размеры блоков для чтения и записи). Если значение параметра badxid такое же большое, как и значение параметра timeout, то сервер отвечает, но слишком медленно. В этом случае необходимо либо за- менить сервер, либо увеличить параметр time о. Регулярное выполнение команд nfsstat и netstat и анализ выдаваемой ими ин- формации помогут администратору выявлять возникающие в NFS проблемы раньше, чем с ними столкнутся пользователи. 18.7. Специализированные файловые серверы NFS Быстрый и надежный файловый сервер — один из важнейших элементов вычисли- тельной среды. Конечно, дешевле всего организовать файловый сервер на рабочей стан- ции, воспользовавшись имеющимися жесткими дисками. Однако это не оптимальное решение с точки зрения производительности и удобства администрирования. Уже много лет на рынке предлагаются специализированные файловые серверы NFS. У них есть ряд преимуществ по сравнению с “кустарными” системами. • Они оптимизированы на выполнение операций с файлами и, как правило, обе- спечивают наилучшую производительность при работе с системой NFS. • По мере увеличения требований к хранилищу файлов можно легко наращивать мощности сервера, даже если придется обслуживать терабайтовые массивы дан- ных и сотни пользователей. • Они более надежны, чем обычные системы, благодаря усеченному набору про- грамм, применению дополнительных устройств, обеспечивающих избыточность, и зеркальному дублированию информации на жестких дисках. • Они обычно реализуют доступ к файлам для клиентов как UNIX, так и Windows, а иногда даже содержат встроенные веб-, FTP- и SFTP-серверы. • Чаще всего они проще в администрировании, чем файловые серверы UNIX. • Они обладают улучшенными средствами резервного копирования и контроля со- стояния, по сравнению с обычными UNIX-системами.
Глава 18. Сетевой протокол Network File System 757 На рынке существующих систем лидируют устройства компании Network Appliance, Inc. (netapp.com). Диапазон предложений — от малых до очень крупных систем, и цены вполне приемлемы. Компания ЕМС занимает нишу устройств высшего класса. Она выпускает хорошие продукты, но их цены могут испугать кого угодно. Компания LeftHand Networks, приобретенная корпорацией HP, является еще одним игроком, кото- рый выиграл от появления дешевых, высокопроизводительных и удобных устройств для хранения информации. Еще одним возможным решением проблем, связанных с эффективным управлением памятью, могут стать сети хранения данных (storage area network — SAN). Они отлича- ются от специализированных серверов тем, что не имеют представления о файловых си- стемах; они просто обслуживают блоки дисков. Следовательно, сеть SAN не обременена затратами, связанными с операционной системой, и способна осуществлять быстрый доступ для записи и чтения, но не может управлять параллельным доступом нескольких клиентов без помощи кластеризованной файловой системы. Более подробная информа- ция о сетях SAN приведена в разделе 8.11. 18.8. Автоматическое монтирование Индивидуальное монтирование файловых систем посредством упоминания их в фай- лах /etc/fstab и /etc/vfstab сопряжено в крупных сетях с рядом проблем. Во-первых, ведение файла fstab на нескольких сотнях компьютеров — весьма уто- мительная задача. Каждый из компьютеров может отличаться от других и требовать осо- бого подхода. Во-вторых, если файловые системы монтируются с множества компьютеров, то в слу- чае сбоя всего лишь одного из серверов наступает хаос, так как все команды, пытающиеся получить доступ к точкам монтирования этого сервера, зависают. В-третьих, сбой какого-нибудь важного сервера может нанести немалый ущерб поль- зователям, сделав недоступными такие важные разделы, как, например, /usr/share/ man. Самый простой выход из этой ситуации — временно смонтировать копию раздела с резервного сервера. Однако система NFS не имеет инструментов для обеспечения ра- боты резервных серверов. Решить эту проблему можно с помощью демона автоматического монтирования, ко- торый подключает файловые системы, когда к ним выполняется обращение, и отклю- чает их, когда надобность в них отпадает. Этот процесс осуществляется незаметно для пользователей и позволяет свести к минимуму число активных точек монтирования. Демону можно также предоставить список реплицированных (идентичных) файловых систем, чтобы сеть могла функционировать в случае отказа основного сервера. Для реализации фонового подключения и отключения демон связывает драйвер вир- туальной файловой системы с каталогами, обозначенными как точки автоматического монтирования. Раньше он делал это, выступая в качестве сервера NFS, но такой подход имел ряд серьезных ограничений, поэтому редко применяется в современных системах. В настоящее время используется драйвер файловой системы autofs, встроенный в ядро. Вместо того чтобы зеркально дублировать в сети реальную файловую систему, демон автоматического монтирования воссоздает ее иерархию в соответствии со специфика- циями, указанными в файле конфигурации. Когда пользователь ссылается на каталог виртуальной файловой системы демона, последний перехватывает эту ссылку, монтиру- ет реальную файловую систему, к которой обращается пользователь, и передает ссылку Дальше. На системах, поддерживающих демон autofs, файловая система NFS монтиру-
758 Часть II. Работа в сети ется в файловой системе autof s в обычном для системы UNIX режиме. Другие системы могут потребовать, чтобы монтирование осуществлялось в отдельном каталоге, на кото- рый затем устанавливается символическая ссылка. Идея автоматического монтирования была предложена компанией Sun, которая в на- стоящее время стала частью корпорации Oracle. Имеющийся в Linux демон automount имитирует работу одноименной утилиты компании Sun, хотя реализован независимо и обладает рядом отличительных особенностей. Аналогично система AIX предоставляет свой собственный демон automount, который компания IBM называет “инструментом управления для системы AutoFS”. Разные реализации демона automount используют три вида файлов конфигурации, которые называются таблицами (maps): таблицы прямых назначений, таблицы косвен- ных назначений и главные таблицы.7 Таблицы прямых и косвенных назначений содер- жат информацию о файловых системах, подлежащих автоматическому монтированию. Главная таблица перечисляет таблицы прямых и косвенных назначений, которые дол*: жен учесть демон automount. В каждый момент времени может быть активной только одна главная таблица; по умолчанию главная таблица хранится в каталоге /etc/auto_ master (/etc/auto.master — в системе Linux). В большинстве систем демон automount представляет собой отдельную команду, ко ; торая считывает свои файлы конфигурации, настраивает все необходимые для демона autof s параметры и прекращает работу. Действительные ссылки на файловые систе? . мы, подлежащие автоматическому монтированию, обрабатываются с помощью демона autof s другим процессом — демоном automontd. Этот демон выполняет свою работу незаметно и не требует дополнительной конфигурации. }' ДВ системах Linux этот демон называется automountd, а функция настройки выполняется в сценарии загрузки /etc/init.d/autofs. Подробная информ мация об этом приведена ниже. Далее мы будем называть команду настройкй^ именем automount, а демон автоматического монтирования — automountd. Если вы изменили главную таблицу или одну из таблиц прямых назначений, на кО-л торую она ссылается, то необходимо заново запустить демон automount, чтобы эти из- менения вступили в силу. При использовании параметра -v команда automount демону стрирует изменения, внесенные в ее конфигурацию. 5 Демон automount имеет также аргумент -t, сообщающий, как долго (в секундах^ файловая система, монтируемая автоматически, может оставаться неиспользуемой пе- ред тем, как будет размонтирована. По умолчанию этот параметр равен 10 минутам! Поскольку точка монтирования NFS, принадлежащая сбойному серверу, может вызвать зависание программы, целесообразно удалять автоматически смонтированные файло-^ вые системы, которые больше не используются. Кроме того, не следует задавать тайм- аут слишком долгим.8 Таблицы косвенных назначений Эти таблицы используются для автоматического монтирования нескольких файло- вых систем в общем каталоге. Однако путь к каталогу задается в главном файле, а не в самой таблице. Например, таблица назначений для файловых систем, монтируемых 7 Таблицы прямых назначений также управляют базой данных системы NFS или каталогом. LDAP, но это сложно. 8 С другой стороны, монтирование файловой системы занимает определенное время. Система отвечает быстрее и плавнее, если файловые системы не монтируются непрерывно. «
Глава 18. Сетевой протокол Network File System 759 в каталоге /chimchim (в соответствии с показанным выше главным файлом), может иметь следующий вид. users harp:/harp/users devel -soft harp:/haгр/devel info -ro harp:/harp/info В первой колонке указывается имя подкаталога, в котором будет смонтирована фай- ловая система. В следующих колонках перечислены опции монтирования и приведен исходный путь к файловой системе. В данном примере (файл /etc/auto.harp) демо- ну automount сообщается о том, что он может монтировать каталоги /harp/users, /harp/devel и /harp/info с компьютера harp, при этом каталог info монтируется только для чтения, а каталог devel — в режиме soft. В рассматриваемой конфигурации подкаталоги на компьютере chimchim и на ло- кальном компьютере будут идентичными, хотя это вовсе не обязательно. Таблицы прямых назначений Рассматриваемые таблицы перечисляют файловые системы, не имеющие общего префикса, такие как /usr/src и /cs/tools. Таблица прямых назначений (например, /etc/auto.direct), указывающая, что обе эти файловые системы должны монтиро- ваться автоматически, может выглядеть следующим образом. /usr/src harp:/usr/src /cs/tools -ro monk:/cs/tools Поскольку у этих файловых систем нет общего родительского каталога, их монтиро- вание должно реализовываться с помощью разных демонов autof s. Эта конфигурация требует дополнительных расходов, но ее преимуществом является то, что точка монти- рования и структура каталогов всегда остаются доступными таким командам, как 1s. Применяя команду 1s к каталогу, содержащему таблицы косвенных назначений, поль- зователи могут запутаться, потому что демон automount не показывает подкаталоги, пока не получит доступ к их содержимому (команда 1s не заглядывает внутрь каталогов, смонтированных автоматически, поэтому она не может вызвать их монтирование). Главные таблицы Главный файл содержит список таблиц прямых и косвенных назначений, которые должен учитывать демон automount. Для каждой таблицы косвенных назначений ука- зывается корневой каталог, используемый для монтирования, определенного в таблице. Главная таблица, использующая таблицы прямых и косвенных назначений, упомяну- тых в предыдущих примерах, может выглядеть следующим образом. # Directory Мар /harp /etc/auto.harp -proto=tcp /“ /etc/auto.direct В первом столбце указывается имя локального каталога для таблицы косвенных назначений или специальный токен / - для таблицы прямых назначений. Во втором столбце указывается файл, в котором должна храниться таблица. Может существовать несколько таблиц разного типа. Если параметр монтирования указывается в конце стро- ки» то он по умолчанию применяется ко всем точкам монтирования, указанным в та- блице. Администраторы системы Linux всегда должны указывать флаг монтирования stype=nf s4 для серверов, использующих четвертую версию протокола NFS.
760 Часть II. Работа в сети А В большинстве систем параметры, заданные по умолчанию для элементов главной таблицы, не смешиваются с параметрами, заданными для таблиц прямых и косвенных назначений. Если элемент главной таблицы имеет свой собственный список параметров, то значения, заданные по умолчанию, игно- рируются. Тем не менее в системе Linux эти наборы параметров смешиваются. Если один и тот же параметр встречается в двух местах, то значение элемента главной таблицы заменяет значение, заданное по умолчанию. Главная таблица обычно заменяется или дополняется версией, используемой со- вместно с сетевой службой NIS. Подробности можно найти в документации. Исполняемые таблицы Если файл, содержащий таблицу косвенных назначений, является исполняемым, то он считается сценарием (или программой), динамически генерирующим информацию об автоматическом монтировании. Демон не читает таблицу в текстовом виде, а запу- скает файл на выполнение, передавая ему аргумент (“ключ”), где указывается, к какому подкаталогу пользователь пытается получить доступ. Сценарий отвечает за вывод соот- ветствующей записи таблицы. Если переданный ключ неверен, сценарий завершается, ничего не отображая. Такая методика очень удобна и позволяет компенсировать многочисленные недо- статки довольно странной системы конфигурирования демона automount. По сути, она дает возможность создать единый для всей организации конфигурационный файл про- извольного формата. Можно написать несложный сценарий, декодирующий глобальные конфигурационные параметры на каждом компьютере. В состав некоторых систем вхо- дит удобный сценарий /etc/auto. net, принимающий в качестве ключа имя компью- тера и монтирующий все экспортируемые файловые системы этого компьютера. florissant_1003 гшпрОЗ f го z en_dead_guy_0ct2 009 rmnp_0 30806 greenville.021129 streamboat2006 Видимость демона automount Когда вы перечисляете содержимое родительского каталога файловой системы, мон- тируемой автоматически, этот каталог оказывается пустым независимо от того, сколько там было автоматически смонтировано файловых систем. Файловые системы, смонтиро- ванные автоматически, невозможно просмотреть с помощью пользовательского браузера. Рассмотрим пример. $ Is /portal $ Is /portal/photos art_class_2010 blizzard2008 boston021130 Файловая система photos прекрасно работает и автоматически монтируется в ка- талоге /portal. Для того чтобы получить к ней доступ, необходимо указать ее полное имя. Однако обзор каталога /portal не указывает на ее существование. Если бы вы смонтировали эту систему с помощью команды fstab или mount, то она ничем бы не отличалась от других каталогов и была бы видимой в родительском каталоге. Для того чтобы увидеть файловые системы, смонтированные автоматически, ис- пользуются символические ссылки на точки автоматического монтирования. Например, если /automounts/photos — это ссылка на каталог /portal/photos, то команда 1s позволяет увидеть среди содержимого каталога /automounts, что каталог photos был
Глава 18. Сетевой протокол Network File System 761 смонтирован автоматически. Ссылки на каталог /authomounts/photos по-прежнему проходят через механизм автоматического монтирования и работают правильно. К сожалению, эти символические ссылки требуют сопровождения и могут потерять согласованность с реальными точками автоматического монтирования, если они перио- дически не обновляются с помощью некоего сценария. Реплицированные файловые системы и демон automount В некоторых случаях файловая система, предназначенная только для чтения, напри- мер /usr/share, может оказаться идентичной на нескольких серверах одновременно. В этом случае мы можем сообщить демону automount о нескольких потенциальных ис- точниках этой файловой системы. Демон самостоятельно выберет источник файловой системы, исходя из того, какой сервер окажется ближайшим по номеру в данной сети, по версии протокола NFS, а также по времени ответа на первоначальный запрос. Несмотря на то что демон automount не видит файловую систему и не следит за ее использованием, реплицированные файловые системы должны предназначаться только для чтения (/usr/share или /usr/local/Xll). Демон automount не имеет возмож- ности синхронизировать записи между серверами, поэтому реплицированные файловые системы, предназначенные только для чтения, имеют небольшое практические значение. В системах Solaris и HP-UX при возникновении проблем демон automount может просто переключаться с одного сервера, имеющего реплицированную файловую систему, на другой. Эта функциональная возможность поддержи- soians вается исключительно для файловых систем, предназначенных только для чтения, но ходят слухи, что на системы чтения-записи она распространяется больше, чем об этом написано в документации. Однако если демон automount изменяет сервер, ссылки на файлы, открытые для записи, становятся некор- ректными, что лишний раз свидетельствует о том, что использовать реплици- рованные файловые системы для чтения и записи не рекомендуется. Несмотря на то что демон automount способен выбирать сервер с реплицирован- ной файловой системой, руководствуясь собственными критериями эффективности и близости, при желании вы можете назначить свои приоритеты. Приоритет задается не- большим целым числом, причем чем больше число, тем ниже приоритет. Наиболее под- ходящим является приоритет по умолчанию, который равен 0. Файл auto.direct, определяющий файловые системы /usr/man и /cs/tools как реплицированные, может выглядеть следующим образом. /usr/man -ro harp:/usr/share/man monk(l):/usr/man /cs/tools -ro leopard,monk:/cs/tools Обратите внимание на то, что имена серверов могут перечисляться вместе, если пути к их источникам совпадают. Значение (1) после имени monk в первой строке задает при- оритет сервера по отношению к файловой системе /usr/man. Отсутствие такого значения после имени harp означает, что этот сервер имеет неявный приоритет, равный нулю. Автоматическое монтирование (V3; все, кроме Linux) Вместо перечисления всех возможных монтируемых файловых систем в таблице кос- венных или прямых назначений, вы можете сообщить демону automount немного ин- формации о правилах именования и позволить ему разбираться в них самостоятельно. Главным обстоятельством при этом является тот факт, что демон mountd, применяемый
762 Часть II. Работа в сети к удаленному серверу, может посылать запросы о том, какие файловые системы были смонтированы на этом сервере. В четвертой версии протокола NFS экспорт всегда обозна- чается символом /, что исключает необходимость в такой функциональной возможности. Существует несколько способов “автоматического конфигурирования автоматиче- ского монтирования”. Самый простой из них относится к типу монтирования -hosts. Если указать флаг -hosts в качестве имени таблицы в файле главной таблицы, то демон automount отобразит файловые системы, экспортированные на указанные узлы, в за- данный каталог автоматического монтирования. /net -hosts -nosuid,soft Например, если сервер harp экспортировал файловую систему /usr/share/man, то каталог должен стать доступным для демона автоматического монтирования с помощью пути /net/harp/usr/ share /man. Реализация флага -hosts не подразумевает перечисления всех возможных узлов, с которых можно экспортировать монтируемую файловую систему; это просто практиче- ски невозможно. Вместо этого команда ждет ссылки на имена конкретных подкатало- гов, а затем монтирует экспортированные системы с указанного узла. Аналогичного, но более тонкого эффекта можно достичь с помощью шаблонных символов и “&” в таблице косвенных назначений. Кроме того, существует множе- ство макросов, используемых вместе с таблицами и именем текущего узла, типом архи- тектуры и т.д. Подробности можно найти на справочной странице automount(lM). Специфика системы Linux Л Реализация демона automount в системе Linux немного отличается от реали- jTjb зации компании Sun. Основные отличия касаются имен команд и файлов. В системе Linux automount — это демон, который на самом деле монтирует и демон- тирует удаленные файловые системы. Он выполняет работу, которую демон automount делает в других системах, и обычно не требует запуска вручную. По умолчанию главная таблица записана в файле /etc/auto. mas ter. Ее формат и формат таблиц косвенных назначений описаны выше. Однако документацию о них най- ти трудно. Формат главной таблицы описан на странице auto.master(5), а формат та- блицы косвенных назначений — на странице autof s(5). Будьте осторожны, не перепу- тайте их со страницей autof s(8), которая документирует команду autof s. (Как сказано на одной из справочных страниц: “Документация оставляет желать лучшего.”) Для того чтобы изменения вступили в силу, выполните команду /etc/init.d/autofs/ reload, являющуюся эквивалентом команды из системы Solaris. Реализация системы Linux не поддерживает флаг -hosts для “автоматического кон- фигурирования автоматического монтирования”. 18.9. Рекомендуемая литература • Callaghan, Brent. NFS Illustrated, Addison-Wesley, 1999. • Stem, Hal, Mike Eisler and Ricardo Labiaga. Managing NFS and NIS, Second Edition, Sebastopol: O’Reilly & Associates, 2001. В табл. 18.11 перечислены документы RFC, посвященные протоколу NFS и его рас- ширениям.
Глава 18. Сетевой протокол Network File System 763 Таблица 18.11. Документы RFC, связанные с NFS RFC Название -•? , 1094 Network File System Protocol Specification Sun Mircosystems Май 1989 1813 NFS Version 3 Protocol Specification B. Callaghan et al. Июнь 1995 2623 NFS Version 2 and Version 3 Security Issues M.Eisler Июнь 1999 2624 NFS Version 4 Design Considerations S.Shepler Июнь 1999 3530 NFS Version 4 Protocol S.Shepler et al. Апрель 2003 18.10. Упражнения 18.1. ★ Проанализируйте локальную конфигурацию NFS в своей системе. Используется ли NFS или применяется какое-то другое решение? Используется ли автомати- ческое монтирование? На какие компромиссы пришлось пойти, создавая такую конфигурацию? 18.2. Какова взаимосвязь между демонами mountd, nfsd и portmap в версиях NFS 2 и 3? Как зависимость от демона portmap сказывается на безопасности системы? 18.3. Какие принципиальные различия существуют между версиями NFS 3 и 4? Как состояние или его отсутствие влияет на другие атрибуты протокола? 18.4. Ваш начальник хочет экспортировать вам свои каталоги /usr и /usr/local через систему NFS. Ответьте на следующие вопросы: а) предположим, вследствие существующих ограничений вы хотите, чтобы слу- жащие только вашего отдела (подсеть 192.168.123.0/24) могли работать с этими файловыми системами. Какие строки необходимо добавить и в какие файлы, чтобы такая конфигурация стала возможной? Обратите внимание на выбор опций экспортирования; б) какие действия следует предпринять для того, чтобы демоны mountd и nfsd смогли распознать эти новые файловые системы? Как проверить факт со- вместного использования каталогов, не монтируя их? в) какой стратегии следует придерживаться, чтобы все компьютеры локальной подсети автоматически монтировали экспортируемые каталоги с использова- нием точек монтирования /mnt/usr и /mnt/usr/local?
Глава Совместное использование системных файлов Мы знакомы с идеей совместного использования данных разными компьютерами: посредством вложений в сообщения электронной почты, протоколов передачи данных (HTTP и FTP) или служб коллективного доступа к файлам, предоставляемым файловый ми системами NFS и CIFS. Эти механизмы позволяют и пользователям совместно ис^ пользовать файлы и данные приложений. Однако системы UNIX и Linux могут извлек пользу еще из одного вида коллективного использования ресурсов, а именно распредё- ления административных данных конфигурации. В этом случае имеет место централиза* ция административного управления ресурсами между системами и поддержка согласо- ванности данных. % Регистрационные имена и пароли пользователей — это реальный пример необходим мости этого вида коллективного использования ресурсов. Вам редко придется добавлять пользователя на один компьютер; в большинстве случаев вы будете определять этого пользователя в целый класс или сеть компьютеров. Кроме того, большинство организа- ций в настоящее время сталкивается с необходимостью поддержки платформ смешан- ного типа — UNIX, Linux и Windows. Разумеется, пользователи испытывают неудоб- ства, поскольку им приходится привыкать к тому, что на компьютерах разных платформ' им нужно вводить разные пароли (которые необходимо запоминать и иногда менять). К счастью, синхронизация конфигурации и сведений о пользователях в разных системах (например, в Linux и Windows) — это тривиальная задача. Совместное использование системных файлов не так просто реализовать, как может показаться. Попытки разработать распределенные административные базы данных для; больших сетей продолжались несколько десятилетий, в результате чего были созданы^ интересные системы. К сожалению, ни одна из этих систем сегодня не кажется нам без-|
Глава 19. Совместное использование системных файлов 765 упречной по идеологии. Некоторые из них просты, но не отличаются достаточной сте- пенью безопасности и масштабирования. Другие обладают хорошими функциональ- ными возможностями, но являются громоздкими. Всем этим системам присущи огра- ничения, которые могут помешать организовать и настроить сеть так, как нужно адми- нистратору, и ни одна из систем не позволяет управлять всей информацией, которую требуется совместно использовать на разных компьютерах. В этой главе сначала будет рассмотрен ряд базовых методик сохранения файлов конфигурации, синхронизированных по сети. Затем поговорим об облегченном (упро- щенном) протоколе доступа к сетевым каталогам (Lightweight Directory Access Protocol — LDAP) — более сложной платформонезависимой системе управления базой данных, которая уже де-факто стала стандартом как в мире UNIX, так и Windows. Сегодня во многих организациях постепенно переходят на использование протокола LDAP. К этому их подталкивает, прежде всего, принятие фирмой Microsoft стандарта LDAP в ее продук- те Active Directory, а также желание добиться более качественной интеграции сред Linux и Windows. Наконец, мы поговорим о довольно популярной прежде административной СУБД — NIS, которая остается в рабочем состоянии в некоторых средах, но не устанав- ливается в новых сетях. Обратите внимание на то, что совместное использование системных файлов отлича- ется от конфигурации систем и распространения программного обеспечения. Эти обла- сти имеют различные цели и потребности и на практике реализуются разными методами. 19.1. Предмет совместного использования В системах Linux и UNIX существует много файлов конфигурации, но далеко не все из них имеет смысл совместно использовать на нескольких компьютерах. В настоящее время совместному использованию подлежат, например, файлы, которые содержат па- роли, узлы и псевдонимы. Наиболее распространенные файлы коллективного доступа перечислены в табл. 19.1. Таблица 19.1. Системные файлы, которые часто являются объектами совместного использования Имя файла Назначение ; /etc/passwd /etc/shadow3 /etc/group /etc/hosts База данных с информацией о пользовательских учетных записях Файл паролей, соответствующих учетным записям пользователей Определения UNIX-групп Соответствия между именами компьютеров и их IP-адресами /etc/mail/aliases Псевдонимы электронной почты /etc/sudoers /etc/skel/a Полномочия для команды sudo Стандартные файлы конфигурации для новых домашних каталогов а Совместное использование может не поддерживаться другими версиями UNIX из-за несовпадения меха- низмов шифрования (см. раздел 7.1). Содержимое табл. 19.1 не претендует на “звание” исчерпывающего списка; точная конфигурация зависит от того, какую степень подобия вы хотите реализовать для своих компьютеров. По большей части, дополнительные файлы конфигурации имеют отно- шение к конкретным приложениям и не поддерживаются такими административными СУБД, как LDAP, — в этом случае совместное использование файлов достигается их ко- пированием.
766 Часть II. Работа в сети Ш О модулях РАМ речь пойдет в конце раздела 22.5. Доступ к файлам, перечисленным в табл. 19.1, традиционно осуществляется через функции стандартной библиотеки языка С. Например, поиск в файле /etc/passwd выполняют функции getpwuid, getpwnam и getpwent. Они берут на себя открытие, чтение и синтаксический анализ файла passwd, освобождая от этой задачи программы пользовательского уровня. В современных системах используются также модули РАМ (Pluggable Authentication Module — подключаемый модуль аутентификации), которые определяют стандартный программный интерфейс безопасного поиска информации. Эти модули позволяют легко интегрировать в Linux и UNIX различные системы, в част- ности Kerberos и LDAP. Точный порядок поиска данных устанавливается системным ад- министратором (подробнее об этом — в разделе 19.5). 19.2. Копирование файлов Простое копирование файлов не является идеальным решением, но оно применимо на всех типах компьютеров и отличается простотой настройки и сопровождения. Оно также надежно, поскольку число перекрестных зависимостей между компьютерами сво- дится к минимуму (правда, при этом легче нарушить синхронизацию систем). Благодаря этому мы всегда вольны решать, что распространять по сети и как именно. У нас по- является возможность своевременно обновлять не только системные файлы, но и при- ложения вместе с файлами данных. Довольно большое число конфигурационных файлов не поддерживается ни одной из административных СУБД (среди них файл /etc/ntp. conf, задающий правила сетевой синхронизации часов). Чтобы поддерживать согласованность этих файлов, не остается другого выхода, кроме как копировать их. Использование сервера NFS Некоторые системы распространяют файлы конфигурации путем опубликования их на сервере NFS. Это, пожалуй, самый простой метод с точки зрения автоматизации — все, что вам нужно на стороне клиента, сосредоточено в ср (по крайней мере, теорети- чески). Ш Об NFS больше информации можно найти в главе 18. Раньше протокол сетевого доступа к файловым системам NFS “грешил” пробле- мами безопасности, что делало его использование несколько рискованным, но в вер- сии NFSv4 основные проблемы были решены. Для улучшения безопасности и защиты от любопытных глаз можно прибегнуть к шифрованию важных файлов. Ш Подробнее о пакете PGP написано в разделе 22.10. Следующий шаг на пути повышения безопасности состоит в использовании цифро- вой подписи применительно к файлам конфигурации с помощью такого пакета шифро- вания открытых ключей, как PGP (Pretty Good Privacy — вполне хорошая секретность). Клиенты могут удостовериться, что файлы, полученные ими через систему NFS, под- линны и не были модифицированы. Причем это важно сделать еще до их инсталляции. Многие пакеты программ позволяют указать нестандартное местоположение фай- лов конфигурации. Следовательно, теоретически можно указать эти пакеты в файлах конфигурации, которые “прописаны” в файловой системе NFS, что избавило бы от необходимости создавать локальные копии. Однако мы настоятельно рекомендуем не
Глава 19. Совместное использование системных файлов использовать такую схему конфигурации, поскольку она делает каждую систему в мире зависимой от одного сервера NFS, и этот сервер тогда будет вынужден обслуживать всех таких клиентов. Хуже того, во многих пакетах не предусмотрена ситуация, когда уда- ленные системы будут блокировать свои файлы конфигурации или создавать временные файлы в конфигурационных каталогах (и их настройка может даже не сработать коррек- тно). При этом вполне вероятно, что ваша система, прекрасно работая в течение долгого времени, может вдруг напрочь отказать, причем по совершенно непонятной причине, не оставив никаких “улик”, по которым бы можно было понять, что произошло. Хотя, если вы любите сюрпризы, добро пожаловать в ад! Сравнение модели принудительной рассылки с моделью рассылки по запросу Отказавшись от модели совместно используемых файловых систем, вы можете рас- смотреть и другие варианты. Системы копирования файлов могут работать по модели принудительной рассылки (push system) либо модели рассылки по запросу (pull system). В первом случае главный сервер периодически отправляет самые свежие версии файлов каждому клиенту независимо от желания последнего. Файлы могут копироваться явно при каждом изменении или просто регулярно высылаться согласно графику (при этом, вероятно, одни файлы будут обновляться чаще других). Преимущество модели принудительной рассылки заключается в том, что система распространения работает централизованно, на одном компьютере. Файлы, списки кли- ентов, сценарии обновления и расписания хранятся в одном месте, что делает эту схему простой в управлении. Есть у нее и недостаток: каждый клиент должен позволять глав- ному серверу модифицировать свои системные файлы, что не всегда приемлемо с точки зрения безопасности. В модели рассылки по запросу каждый клиент отвечает за обновление самого себя с помощью данных, запрашиваемых с сервера. Это менее централизованный способ распространения файлов, зато более гибкий и безопасный. Данная схема копирования особенно привлекательна, когда совместно используемые данные находятся в разных административных областях, поскольку вовсе не обязательно, чтобы главный сервер и компьютер-клиент располагались в одной области. Утилита relist: принудительная рассылка файлов Проще всего распространять файлы с центрального сервера с помощью утилиты rdist. Она немного напоминает программу make: вначале пользователь в текстовом редакторе составляет описание (спецификацию) файлов, подлежащих рассылке, а за- тем утилита rdist осуществляет операции копирования в соответствии с описанием. Утилита копирует файлы только в том случае, если их копии устарели, поэтому в спец- ификации можно задать копирование всех файлов, а утилита rdist самостоятельно определит, какие файлы и когда следует копировать. Утилита rdist сохраняет информацию о владельце, группе, правах доступа и време- ни модификации файла. Когда утилита обновляет существующий файл, то перед инстал- ляцией новой версии она удаляет старую. Это позволяет использовать данную утилиту для пересылки исполняемых файлов, запущенных во время обновления1. Традиционно 1 Хотя старая версия удаляется из пространства имен файловой системы, она продолжает су- ществовать до тех пор, пока не освобождены все ссылки на нее. Об этом следует помнить при ра- боте с журнальными файлами.
768 Часть II. Работа в сети утилита rdist работала поверх команды rsh и пользовалась ее средствами аутентифика- ции для получения доступа к удаленным системам. К сожалению, она имела ряд слабых мест с точки зрения безопасности кг по умолчанию была отключена во многих современ- ных операционных системах. Несмотря даже на то, что в документации к rdist до сих пор упоминается rsh, не нужно думать, что rsh является приемлемым вариантом. Современные версии утилиты rdist примечательны тем, что позволяют заменять команду rsh любой другой, понимающей аналогичный синтаксис. Чаще всего это ко- манда ssh, которая использует шифрование с открытым ключом для аутентификации узлов и, кроме того, шифрует весь диалог, не давая возможности злоумышленникам, прослушивающим сеть, получать копии системных файлов. Недостаток заключается в том, что удаленные серверы ssh должны работать в режиме, позволяющем не указывать пароль (хотя клиента нужно аутентифицировать с помощью пары криптографических ключей), а это менее безопасный режим, чем требуется в обычных условиях. Но все рав- но это значительный шаг вперед по сравнению с rsh. Подробнее о демоне sshd и его режимах аутентификации рассказывается в разделе 22.10. Итак, разобравшись с тем, какую угрозу таит в себе утилита rdist, рассмотрим в деталях, как она функционирует. Подобно программе make, утилита rdist ищет в теку- щем каталоге управляющий файл (Distfile или distfile). Команда rdist -f задает имя управляющего файла явно. В качестве разделителей в этом файле используются зна- ки табуляции, пробелы и символы новой строки. Комментарии предваряются знаком #. Тело управляющего файла состоит из инструкций следующего вида. метка: имена_файлов -> адресаты команды Поле метка является именем инструкции. В командной строке можно ввести коман- ду rdist метка, которая обеспечит рассылку только файлов, упомянутых в указанной инструкции. Поля имена_файлов и адресаты — это список файлов, подлежащих копированию, и список компьютеров, куда их нужно переслать соответственно. Если в списке больше одного элемента, нужно заключить его в круглые скобки, а элементы разделить пробе- лами. Список имен файлов может включать метасимволы, допустимые в интерпретато- ре команд (например, /usr/man/man[123] или /usr/lib/*). Допустима также запись '-пользователь, но соответствующие ей значения на узле-отправителе и узле-адресате могут не совпадать. По умолчанию утилита rdist копирует файлы и каталоги, перечисленные в списке имен, в эквивалентные каталоги на каждом узле-адресате. Этот порядок можно изме- нить, указав последовательность команд. Каждую команду следует завершать точкой с запятой. Поддерживаются такие команды. install опции [целевой_каталог]; notify список_адресов; except список_имен; except_pat список_шаблонов; special [список_имен] строка; cmdspecial [список_имен] строка; Команда install задает опции, влияющие на то, как утилита rdist копирует фай- лы. Опции, как правило, используются для обработки символических ссылок, провер- ки правильности применяемого алгоритма сравнения файлов, а также для контроля над процедурой обработки файлов, отсутствующих в исходном дереве каталогов. Опции,
Глава 19. Совместное использование системных файлов 769 перед которыми должен стоять флаг -о, включают список разделенных запятыми имен. Например, строка install -©remove,follow; заставляет утилиту г di st отслеживать символические ссылки (а не копировать их как обычные файлы) и удалять на целевом компьютере файлы, для которых не найдено со- ответствие на исходном компьютере. Полный список опций приведен на man-странице утилиты rdist. В большинстве случаев установки по умолчанию вполне подходят. Название команды install слегка вводит в заблуждение, поскольку файлы копи- руются независимо от того, присутствует эта команда или нет. Опции задаются так, как они задавались бы в командной строке утилиты rdist, но при включении в управляю- щий файл Distfile они действуют только на совокупность файлов, указанную в ин- струкции. Необязательный аргумент целевой_каталог задает каталог, в который инсталлиру- ются файлы на компьютерах-адресатах. По умолчанию утилита rdist использует ис- ходные имена каталогов. В качестве аргумента команды notify задается список адресов электронной почты. При каждом обновлении очередного файла утилита rdist посылает по этим адресам почтовое сообщение. Ко всем адресам, не содержащим знак @, добавляется имя узла- адресата. Например, при выдаче списка файлов, откорректированных на компьютере anchor, запись “pete” превратится в “pete@anchor”. Ш Больше о регулярных выражениях можно прочитать в разделе 2.3. Команды except и except_j>at предназначены для удаления имен из списка фай- лов, подлежащих копированию. Аргументы команды except трактуются буквально, аргументы команды except_j>at интерпретируются как регулярные выражения. Эти команды весьма полезны, поскольку утилита rdist, как и make, позволяет задавать ма- кроконстанты в начале управляющего файла. Благодаря этому появляется возможность использовать один список файлов в нескольких инструкциях, указывая для каждого компьютера только добавления или удаления. Команда special позволяет выполнить команду интерпретатора sh (аргумент строка, который следует брать в кавычки) на всех удаленных компьютерах. Если бу- дет задан аргумент список_имен, утилита rdist выполнит команду после копирования каждого из указанных файлов. Без этого списка rdist выполнит команду после каждого файла. Команда cmdspecial работает подобным образом, но только выполняет коман- ду интерпретатора sh после завершения каждой операции копирования. (Содержимое аргумента список_имен передается интерпретатору sh в виде переменной окружения.) Приведем пример файла Distfile. SYS_FILES = (/etc/passwd /etc/group /etc/mail/aliases) GET_ALL = (chimchim lollipop barkadon) GET_SOME = (whammo spiff) all: ${SYS_FILES} -> ${GET_ALL} notify barb; special /etc/mail/aliases "/usr/bin/newaliases"; some: ${SYS_FILES} -> ${GET_SOME} except /etc/mail/aliases; notify eddie@spiff; Ш Подробнее о команде newaliases рассказывается в конце раздела 20.5.
770 Часть II. Работа в сети В данной конфигурации три указанных системных файла копируются на компьюте- ры chimchim, lollipop и barkadon, а по адресу ЬагЬ@адресат посылается сообщение с описанием всех изменений и замеченных ошибок. После копирования файла /etc /mail/aliases утилита rdist выполняет на каждом компьютере команду newaliases. На компьютеры whammo и spiff копируются только два файла, а отчет посылается по адресу eddie@spiff. Команда newaliases на этих двух компьютерах не выполняется. Для того чтобы утилита rdist могла работать, нужно, чтобы демон sshd на прини- мающих узлах доверял узлу, осуществляющему рассылку файлов. Для этого на сервере нужно сгенерировать текстовый ключ и сохранить копию его открытой части в фай- ле -root/. ssh/authorized_keys на каждом клиенте. Имеет также смысл ограничить сферу применения ключа и количество узлов, от которых он может приниматься. Более подробно об этом речь пойдет в разделе 22.10 при описании альтернативного метода. Утилита rsync: более безопасная рассылка файлов Ш Утилита rsync доступна по адресу: rsync. samba. org. Утилита rsync, написанная Эндрю Триджеллом (Andrew Tridgell) и Полом Маккер- расом (Paul Mackerras), подобна утилите rdist, но иначе реализована. Она не исполь- зует управляющий файл (хотя у сервера все же есть свой конфигурационный файл) и напоминает улучшенную версию команды г ср, пытающуюся сохранить ссылки, время модификации и права доступа. Утилита rsync более эффективна, чем rdist, посколь- ку анализирует отдельные файлы и пытается передавать только изменения между вер- сиями. С нашей точки зрения, основным преимуществом утилиты rsync является то, что на принимающих компьютерах серверный процесс может запускаться из демона xinetd или inetd. Сервер (на самом деле это та же утилита rsync, но работающая в другом режиме; она должна быть инсталлирована как на главном компьютере, так и на кли- ентах) допускает гибкую настройку: он может предоставлять удаленный доступ лишь к заданному набору каталогов и требовать, чтобы главный компьютер подтвердил свою подлинность паролем. Поскольку доступ на уровне команды ssh не требуется, можно организовать распространение системных файлов посредством утилиты rsync, не жерт- вуя безопасностью. (Тем не менее утилита rsync разрешает пользоваться командой ssh, а не серверным процессом, работающим под управлением демона inetd.) Более того, утилита способна работать в режиме рассылки по запросу (самостоятельно запрашивая файлы у сервера rsync и не дожидаясь принудительной рассылки в локальную систе- му), что делает ее еще более безопасной. К сожалению, утилита rsync в целом не столь гибкая в настройке, как rdist, и ее конфигурационный файл не такой сложный, как файл distfile. На стороне клиента нельзя выполнить произвольную команду и нельзя рассылать файлы нескольким узлам одновременно. Например, команда # rsync -gopt —password-file=/etc/rsync.pwd /etc/passwd lollipop::sysfiles посылает файл /etc/passwd на компьютер lollipop. Флаг -gopt указывает на со- хранение прав доступа, идентификаторов владельцев и времени модификации файла. Цва двоеточия в выражении lollipop:: sysf iles заставляют утилиту связаться с уда-
Глава 19. Совместное использование системных файлов 771 ленным сервером rsync непосредственно через порт 873, а не использовать для этого ко- манду ssh. Для аутентификации соединения берется пароль из файла /etc/rsync.pwd2. В этом примере передается только один файл, хотя утилита rsync способна обраба- тывать одновременно группу файлов. Кроме того, флаги —include и —exclude по- зволяют указать список регулярных выражений, с которым будут сравниваться имена файлов. Благодаря этому можно сформировать довольно сложный набор правил копи- рования. Если командная строка становится слишком громоздкой, поместите регуляр- ные выражения в отдельные файлы. Для этого существуют опции —include-file и —exclude-file. Linux-пакеты rsync обычно обеспечивают конфигурацию xinetd этой ути- литы. Для того чтобы активировать работу сервера, вам нужно будет отре- дактировать файл /etc/xinetd. rsync, поменяв строку disable=yes на disable=no. На момент написания этих строк утилита rsync не поставляется как часть SOLb Г IS дистрибутива Solaris. Вы можете загрузить ее исходный код с адреса rsync. samba. org и инсталлировать ее либо отыскать с помощью Google исполняе- мый файл-“полуфабрикат” Solaris. Возможно, для преобразования метода за- пуска демона в форму, совместимую с новой SMF-оболочкой Solaris, вам при- дется использовать утилиту inetconv. KjSt Система HP-UX также не включает утилиту rsync, но вы можете получить предварительно скомпилированные исполняемые файлы HP-UX в depot-фор- ме swinstall по адресу: hpux. connect. org. uk/hppd/hpux/Networking/Admin/rsync-3.0.6 Доступ к AIX-версии утилиты rsync можно получить с адреса: ftp: //ftp. software. ibm. com/aix/f reeSof tware/aixtoolbox/RPMS/ррс/r sync На момент написания этих строк пакет RPM для AIX 6.1 находится все еще в ста- дии разработки. Между тем многим удалось добиться успеха в использовании пакета AIX 5.3 RPM в своих системах AIX 6.1. После того как утилита rsync активизирована, следует модифицировать ряд кон- фигурационных файлов для настройки сервера rsync. Основной из них — это /etc /rsyncd. conf, содержащий глобальные конфигурационные параметры и описание на- бора “модулей”, каждый из которых представляет собой дерево каталогов для экспорта или импорта. Разумная конфигу рация модуля, в который можно копировать файлы (т.е. который будет принимать запросы на пересылку файлов от подключенного клиента), выглядит примерно так. # Название "sysfiles" для данного модуля выбрано произвольно. [sysfiles] # Это каталог, в который будут помещаться рассылаемые файлы. # Может быть просто '/’. path = /etc # Это файл, содержащий пары значений имя_пользователя/пароль # для аутентификации модуля. 2 Пароль посылается по сети в зашифрованном виде, но сами передаваемые файлы не шифру- ются. С другой стороны, если в качестве транспортного средства используется команда ssh (rsync -gopt -е ssh /etc/passwd /etc/shadow lollipop: /etc — обратите внимание на одинар- ное двоеточие), то шифруется все соединение, однако демон sshd придется сконфигурировать так, чтобы он не запрашивал пароль. Воистину, мы сами выбираем свою казнь!
772 Часть II. Работа в сети secrets file = /etc/rsyncd.secrets # Модуль должен быть доступен только для чтения в случае # рассылки по запросу. read only = false # Идентификаторы пользователя и группы для операций рассылки. uid = root gid = root # Список узлов, которым разрешено подключаться. hosts allow = главныи_сервер_рассылки Существует множество других опций, но установки по умолчанию вполне прием- лемы. В данной конфигурации все операции локализованы в каталоге /etc, а доступ разрешен только указанному узлу. С точки зрения пользователя или клиента можно осуществлять рассылку файлов на сервер, указывая в качестве пункта назначения выра- жение узел: :sysfile, которое соответствует описанному выше модулю. Если утилита rsync должна работать в режиме рассылки по запросу (файлы загружаются с централь- ного сервера rsync), то показанные выше строки конфигурации тоже подойдут (разве что придется включить режим “только чтение”). Наконец, необходимо настроить файл rsyncd. secrets. Он обычно хранится в ката- логе /etc (это может быть любой другой каталог) и содержит пароли, с помощью кото- рых клиенты аутентифицируют себя. root: пароль В общем случае пароли, используемые утилитой rsync, должны отличаться от реаль- ных паролей. Поскольку пароли отображаются в незашифрованном виде, файл rsyncd. secrets должен быть доступен для чтения только суперпользователю. Рассылка файлов по запросу Реализовать систему рассылки файлов по запросу можно несколькими способами. Самый простой из них заключается в том, чтобы делать системные файлы доступными на центральном FTP- или веб-сервере3 и заставлять клиентов автоматически загружать их по мере необходимости. Раньше администраторам приходилось писать для этого соб- ственные утилиты (например, сценарии системы expect), но сейчас уже существуют стандартные средства. Наиболее популярная утилита, входящая в состав большинства систем, называется wget. Это довольно простая небольшая программа, которая извлекает содержимое по указанному URL-адресу (с использованием протокола FTP либо HTTP). Например, для загрузки файла средствами FTP введите такую команду. wget ftp: //пользователь: пароль® узел! путь /файл Указанный файл будет помещен в текущий каталог. В случае протокола FTP альтернативой является команда ncf tp, которая тоже есть в большинстве систем. Она представляет собой улучшенный вариант FTP-клиента и до- пускает написание простейших сценариев. Вы можете также использовать утилиту rsync, как описано в предыдущем разделе. Если на центральном узле рассылки выполняется сервер rsync, то клиенты могут загру- жать файлы с помощью данной утилиты. Это сложнее, чем в случае FTP, зато расширя- ются функциональные возможности. 3 Следует иметь в виду, что передача данных по протоколам HTTP и FTP осуществляется по- средством открытого текста. Если вопрос защиты данных является крайне важным, можно вос- пользоваться протоколами HTTPS и SFTP соответственно.
Глава 19. Совместное использование системных файлов 773 Какая бы система ни применялась, следите за тем, чтобы на сервер ложилась посиль- ная нагрузка. Если множество клиентов попытается обратиться к серверу по сети одно- временно (например, у каждого из них операция обновления запланирована демоном cron на одно и то же время), сервер может, хоть и не преднамеренно, подвергнуться ата- ке вида “отказ в обслуживании”. Это особенно касается крупных систем, где необходимо обеспечить смещение таких операций по времени или же их запуск в случайном порядке. Проще всего распределять задания демона сгоп с помощью Perl-сценария следующе- го вида. # !/usr/bin/perl sleep rand() * 600; # пауза от 0 до 600 секунд (т.е. 10 минут) system(coimand_to_copy_files_down); 19.3. LDAP: упрощенный протокол ДОСТУПА К КАТАЛОГАМ Организациям, где применяются системы UNIX и Linux, необходим надежный способ распространения своих административных данных. Но проблема в действительности бо- лее глобальна. Как быть с неадминистративными ресурсами, например каталогами элек- тронной почты? Как контролировать информацию, предоставляемую внешнему миру? Решением, которое устроило бы всех, является унифицированная служба каталогов. Служба каталогов — это просто база данных, но такая, в которой сделан ряд допол- нительных предположений. Любой набор данных, характеристики которых подпадают под эти предположения, становится кандидатом на включение в базу данных. Основные предположения таковы: • информационные объекты относительно невелики; • база данных будет реплицироваться и кешироваться на множестве компьютеров; • у информации есть атрибуты; • данные извлекаются часто, но записываются редко; • операции поиска выполняются очень часто. Текущая стандартная система, предложенная организацией IETF для этих целей, на- зывается LDAP (Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам). В спецификациях LDAP говорится не о самой базе данных, а лишь о том, как получить к ней доступ по сети. В то же время заданы схемы организации данных и осуществления поиска, поэтому подразумевается достаточно четкая модель данных. Изначально LDAP задумывался как простой шлюзовой протокол, который позволял бы клиентам TCP/IP взаимодействовать с серверами каталогов Х.500, теперь уже уста- ревшими. Со временем стало очевидно, что стандарт Х.500 изжил себя и в UNIX необ- ходима стандартная служба каталогов. Все это привело к тому, что из LDAP получилась совершенно самостоятельная, полноценная система управления каталогами (возможно, буква “L” в названии стоит незаслуженно)4. Как бы там ни было, но протокол LDAP получил широкое распространение, чему отчасти способствовало принятие его фирмой Microsoft в качестве основы для службы Active Directory. В среде UNIX и Linux стандартной реализацией стал пакет OpenLDAP 4 Вследствие сложной истории LDAP во многих книгах можно встретить подробные рассказы о Х.500 и OSI. Однако эта история не имеет никакого отношения к современному использованию LDAP. Просто забудьте о ней.
774 Часть II. Работа в сети (openldap.org). Служба каталогов уровня предприятия 389 Directory Server (ранее из- вестная как Fedora Directory Server и Netscape Directory Server) также является проектом с открытым исходным кодом, к которому можно получить доступ на сайте port389. org. Эта служба работает в системах Linux, Solaris и HP-UX. Структура данных LDAP Данные протокола LDAP принимают форму списков свойств, которые в мире LDAP называют “записями” (entry). Каждая запись состоит из набора именованных атрибутов (например, “uid”, “description”) и значений этих атрибутов. Пользователи, работающие в среде Windows, вероятно, заметят, что эта структура напоминает структуру записей в си- стемном реестре. Как и в реестре Windows, отдельный атрибут может иметь несколько различных значений. В качестве примера рассмотрим обычную (и упрощенную) строку файла /etc/passwd, выраженную в виде записи LDAP. uid: ghopper cn: Grace Hopper userPassword: {crypt}$l$pZaGA2RL$MPDJoc0afuhHY6yk8HQFp0 loginShell: /bin/bash uidNumber: 1202 gidNumber: 1202 homeDirectory: /home/ghopper Здесь мы видим простой пример формата LDIF (LDAP Data Interchange Format — фор- мат обмена данными LDAP), который применяется в большинстве инструментов, свя- занных с LDAP, и в реализациях серверов. Причиной успеха этого формата является то обстоятельство, что LDAP можно без труда преобразовывать в простой текст и обратно. Записи систематизируются по “отличительным именам” (имя атрибута: dn — distin- guished лате), которые формируют некоторую разновидность пути поиска. Например, запись dn для вышеупомянутого пользователя может выглядеть так. dn: uid=ghopper f ou=People, dc=navy , dc=mi 1 Как и в DNS, самый значащий бит ставится справа. Здесь имя DNS navy.mil исполь- зуется для построения верхних уровней иерархии LDAP. Оно разбивается на два компо- нента домена: navy и mil, хотя это всего лишь одно из некоторых обычных соглашений. Каждая запись имеет одно отличительное имя. Поэтому иерархия записей будет вы- глядеть подобно простому ветвлению без циклов. Кроме того, существуют также и ре- зервы для символических ссылок между записями и для отсылок на другие серверы. Записи LDAP обычно составляются на основе использования атрибута objectclass (объектный класс). Классы объектов определяют атрибуты, которые может содержать за- пись, причем некоторые из них могут требоваться для проверки достоверности. Каждому атрибуту назначается тип данных. Схема вложения и комбинирования классов объектов ничем не отличается от схемы, принятой в традиционном объектно-ориентированном программировании. Верхний уровень дерева класса объектов называется top; он озна- чает лишь то, что запись должна иметь атрибут objectclass. В табл. 19.2 приведены некоторые обычные атрибуты LDAP, назначение которых с первого взгляда может быть непонятным.
Глава 19. Совместное использование системных файлов 775 Таблица 19.2. Некоторые имена атрибутов, которые можно встретить в иерархиях LDAP Атрибут Расшифровка Назначение О Organization (организация) Часто идентифицирует запись верхнего уровня сайта8 Ou Organization unit (организаци- онная единица) Логическое подразделение, например “marketing” (отдел маркетинга) Сп Common name (обычное имя) Наиболее естественное имя, с помощью которого можно передать смысл записи De Domain component (компонент домена) Используется в сайтах, в которых иерархия построена на основе DNS objectclass Object class (объектный класс) Схема, в соответствии с которой формируются атри- буты данной записи а Обычно не используется системами, в которых LDAP-иерархия построена на основе DNS. Особенности LDAP Для уверенной работы с LDAP вам нужен хотя бы небольшой опыт. Протокол LDAP сам по себе не решает какую-либо административную проблему. Нет какой-то “глав- ной задачи”, которую можно было бы решить исключительно с помощью LDAP; к тому же, на разных сайтах по-разному подходят к необходимости развертывания серверов LDAP. Поэтому прежде чем перейти к особенностям инсталляции и конфигурирования OpenLDAP, поговорим о том, в каких случаях целесообразно использовать LDAP. • LDAP можно использовать в качестве центрального хранилища полной информа- ции о пользователях (от их телефонных номеров и домашних адресов до зареги- стрированных имен и паролей). Ш Подробнее об использовании LDAP с агентом передачи почты sendmail написано в раз- деле 20.7. • В дальнейшем LDAP можно использовать для распространения конфигурационной информации для вспомогательных приложений. Многие почтовые системы, вклю- чая sendmail, Exim и Postfix, могут получить данные о маршрутизации из LDAP, и этим отчасти можно объяснить популярность применения LDAP. Инструменты будут отличаться в зависимости от конфигурации веб-сервера Apache и программы автоматического монтирования файловых систем по запросу autof s. Вероятно, со временем поддержка LDAP будет все более и более расширяться. • LDAP позволяет упростить процесс аутентифицирования пользователей для при- ложений (даже тех, которые написаны другими командами программистов и в дру- гих подразделениях), избавляя разработчиков от необходимости беспокоиться о точных деталях управления учеными записями. • Изменения, внесенные в LDAP-данные, немедленно вступают в силу и мгновенно становятся видимыми для всех узлов и приложений клиентов. • Доступ к данным LDAP производится с помощью инструментов командной стро- ки, таких как Idapsearch. Кроме того, LDAP всесторонне поддерживается языка- ми написания сценариев вроде Perl и Python (посредством использования библи- отек). Следовательно, LDAP выгодно использовать для передачи информации о конфигурации локально написанным сценариям и утилитам администрирования.
776 Часть II. Работа в сети • Для управления LDAP доступен превосходный веб-инструментарий, например phpLDAPadmin (phpldapadmin.sourceforge.com) и Directory Administrator (diradmin.open-it.org). Эти инструменты настолько просты в использовании, что вы сможете приступить к работе с ними, даже не читая руководства. • LDAP хорошо поддерживается и как служба общедоступных каталогов. Многие ведущие почтовые клиенты применяют LDAP для доступа к каталогам пользова- телей. Простой поиск с использованием LDAP поддерживается во многих веб- браузерах посредством типа LDAP URL. • Архитектура Microsoft Active Directory построена на LDAP, а текущая версия Win- dows Server включает расширения (раньше они назывались “Службы для UNIX”, затем “Службы каталогов и защиты Windows для UNIX” а сейчас — “Windows Server 2008 UNIX Interoperability Components”), с помощью которых можно вы- полнять отображение пользователей и групп UNIX. Подробнее об объединении систем UNIX с протоколом LDAP, ориентированным на использование архитек- туры Active Directory, написано в главе 30. Документация и спецификации LDAP В качестве общего введения в LDAP мы можем порекомендовать неплохой “хресто- матийный учебник” LDAP for Rocket Scientists, который содержит описание архитектуры и протокола LDAP. Эта книга опубликована в электронном виде на сайте zytrax.com/ books/ldap. Кроме того, существует множество разнообразных документов RFC, по- священных протоколу LDAP, каждый из которых является довольно сложным. Наиболее важные документы перечислены в табл. 19.3. Таблица 19.3. Документы RFC, посвященные протоколу LDAP rfc Название - ? .. 2307 An Approach for Using LDAP as a Network Information Service 2820 Access Control Requirements for LDAP 2849 LDAP Data Interchange Format (LDIF)—Technical Specification 3112 LDAP Authentication Password Schema 3672 Subentries in the Lightweight Directory Access Protocol (LDAP) 4511 LDAP: The Protocol 4512 LDAP: Directory Information Models 4513 LDAP: Authentication Methods and Security Mechanisms 4514 LDAP: String Representation of Distinguished Names 4515 LDAP: String Representation of Search Filters 4516 LDAP: Uniform Resource Locator 4517 LDAP: Syntaxes and Matching Rules 4519 LDAP: Schema for User Applications OpenLDAP: традиционный LDAP-сервер с открытым исходным кодом OpenLDAP — это расширение проекта, выполненного в Мичиганском университете. В настоящее время он продолжает оставаться проектом с открытым исходным текстом
Глава 19. Совместное использование системных файлов 777 и распространяется с большинством дистрибутивов Linux (хотя и не всегда включается в стандартный вариант инсталляции). Для использования OpenLDAP в системах Solaris HP-UX или AIX вам придется предварительно загрузить и инсталлировать необходимые компоненты соответствующей реализации. В дистрибутиве OpenLDAP стандартным демоном LDAP-сервера является slapd. В среде с несколькими серверами OpenLDAP демон slurpd выполняется на главном сервере и отрабатывает механизм репликации посредством внесения изменений на под- чиненные серверы. Утилиты командной строки позволяют выполнять запросы и моди- фицировать данные LDAP. Настройка не является сложной. В первую очередь потребуется создать файл /etc /openldap/slapd. conf, скопировав образец, который был инсталлирован вместе с сер- вером OpenLDAP. Необходимо обратить внимание на следующие строки. database bdb suffix "dc=mydomain, dc=com” rootdn "cn=admin, dc=mydomain, dc=com" rootpw {crypt}abJnggxhB/yWI directory /var/lib/ldap По умолчанию выбирается формат базы данных Berkley DB, отлично подходящий для данных, манипуляция которыми будет производиться в системе OpenLDAP. Вы мо- жете использовать разнообразные интерфейсы, включая специальные методы (напри- мер, сценарии, создающие данные “на лету”). Переменная suffix задает “базовое имя” LDAP Это корень вашей части простран- ства имен LDAP, подобный тому, что в DNS называется доменным именем. Этот пример показывает обычное использование доменного имени в качестве базового имени LDAP. Переменная rootdn задает административное имя, а переменная rootpw — пароль администратора в стандартном формате UNIX (алгоритм DES). Обратите внимание на то, что доменные компоненты, восходящие к административному имени, также должны быть указаны. Пароль можно либо скопировать из файла /etc/shadow (если не исполь- зуются пароли MD5), либо сгенерировать с помощью простейшего Perl-сценария. perl -е "print crypt ( г пароль',' примесь');" Здесь примесь — это произвольная двухсимвольная строка. Из-за наличия пароля сле- дует убедиться в том, что режим доступа к файлу slapd. conf равен 600, а его владель- цем является пользователь root. Нужно также отредактировать файл /etc/openldap/ldap. conf, чтобы указать сер- вер по умолчанию и базовое имя для клиентских запросов LDAP. Это несложно: просто задайте аргумент записи host равным имени сервера, а в переменную base занесите то же значение, что и в переменной suffix файла slapd.conf (убедитесь, что обе строки не являются комментариями). С этого момента можно запускать демон slapd без аргументов. 389 Directory Server: альтернативный LDAP-сервер с открытым исходным кодом Подобно OpenLDAP, служба каталогов уровня предприятия 389 Directory Server (port389.org) является расширением проекта, выполненного в Мичиганском универ- ситете. Однако прошло несколько лет (в компании Netscape Communications), прежде чем этот проект снова стал открытым.
778 Часть II. Работа в сети Существует множество причин рассматривать проект 389 Directory Server как альтер- нативу для OpenLDAP, но среди его явных преимуществ все же стоит выделить более совершенную документацию. Проект 389 Directory Server поставляется с инструкциями профессионального уровня по администрированию и использованию, включая подроб- ные руководства по инсталляции и внедрению. К ключевым особенностям проекта 389 Directory Server можно отнести следующие: • использование нескольких полностью равноправных мастер-серверов, что позво- ляет обеспечить отказоустойчивость и высокую скорость выполнения операций записи; • возможность синхронизации пользователей, групп и паролей с контроллерами до- мена Active Directory; • консоль администрирования с графическим интерфейсом, управления из команд- ной строки и через веб-интерфейс; • поддержка протокола LDAP, оперативное (без потерь времени) обновление схемы, конфигурации и управления, а также мощный механизм разграничения доступа вплоть до уровня отдельных атрибутов. Проект 389 Directory Server, по-видимому, имеет более активных разработчиков, чем проект OpenLDAP. Поэтому мы обычно рекомендуем отдавать предпочтение именно проекту 389 Directory Server, а не OpenLDAP. С административной точки зрения эти два сервера с открытым исходным кодом по- разительно сходны в том, что касается структуры и функционирования. И это не удиви- тельно, поскольку оба пакета были построены на базе одного и того же исходного кода. LDAP вместо /etc/passwd и /etc/group Включить поддержку LDAP на стороне клиента будет несложно. В некоторых систе- мах необходимый пакет nss_ldap инсталлируется по умолчанию; в противном случае пакет можно найти в качестве опции. Этот пакет включает модуль РАМ, с помощью ко- торого можно использовать LDAP с подключаемыми модулями аутентификации в до- полнение к переключателю службы имен. (Подробнее об интеграции систем UNIX и Linux с протоколом LDAP, построенным на базе Active Directory, написано в главе 30.) Параметры этого пакета, используемые по умолчанию в LDAP на стороне клиен- та, задаются в файле /etc/ldap.conf, который совместно использует свой формат с описанным выше файлом /etc/openldap/ldap.conf, но который включает дополни- тельные опции, специфические для службы имен и контекста РАМ. Вы должны буде- те также отредактировать файл /etc/nsswitch.conf на каждом клиенте, чтобы доба- вить Idap в качестве источника для каждого типа данных, который будет приведен к стандарту LDAP. (Изменения в файле ns switch, conf приводят к тому, что библиотека языка С передает запросы библиотеке libnss__ldap, которая затем использует инфор- мацию /etc/ldap.conf, чтобы выяснить, как нужно обращаться с запросами LDAP. Подробнее — в разделе 19.5.) В документе RFC2307 определено стандартное преобразование традиционных набо- ров данных UNIX, к которым относятся файлы passwd и group, в пространство имен LDAP. Это полезный справочный документ (по крайней мере, с теоретической точки зрения) для системных администраторов, использующих LDAP в качестве замены NIS. На практике все эти спецификации читать гораздо проще компьютерам, чем людям; вам же лучше просто просмотреть примеры.
Глава 19. Совместное использование системных файлов 779 Фирма Padl Software предлагает бесплатную коллекцию сценариев, которые перево- дят существующие текстовые файлы или карты NIS в LDAP. Эти сценарии можно най- ти по адресу: padl. com/OSS/MigrationTools.html. Работать с ними очень просто. Сценарии можно использовать в качестве фильтров для генерации LDIF, а также мож- но запускать, чтобы загружать данные прямо с сервера. Например, сценарий migrate group преобразовывает взятую из /etc/group строку ~ css taf f: х: 2033: evi, matthew , trent в следующий блок LDIF. dn: cn=csstaff,ou=Group,dc=domainname, dc=com cn: csstaff objectclass: posixGroup obj ectClass: top userPassword: {crypt}x gidNumber: 2033 memberuid: evi memberuid: matthew memberuid: trent Обратите внимание на спецификации классов объектов и отличительные имена, ко- торые были опущены в примере passwd в разделе 19.3. После импортирования базы данных вы сможете проверить работу преобразования, запустив утилиту slapcat, которая отображает всю базу данных. Создание LDAP-запросов Для администрирования LDAP вам не обойтись без просмотра содержимого базы данных и управления им. Для этого вам очень пригодится упомянутый выше свободно распространяемый пакет phpLDAPadmin, который предоставляет удобный интерфейс, работающий по принципу “указал и щелкнул”. Помимо phpLDAPadmin, можно исполь- зовать утилиту Idapsearch (распространяемую с OpenLDAP и 389 Directory Server), ко- торая предназначена для поиска информации в службе каталога и является аналогичным инструментом командной строки, генерирующим результат в формате LDIF. Утилита Idapsearch особенно полезна для вызова из сценариев, а также для сред отладки, в ко- торых служба Active Directory действует в качестве сервера LDAP. В следующем примере запроса используется утилита Idapsearch для проЬмотра информации о каталогах тех пользователей, у которых обычное имя cn (common name) начинается с “ned”. (В данном случае найден только один результат, соответствующий такому запросу.) Назначения используемых здесь флагов рассматриваются ниже. $ Idapsearch -h atlantic.atrust.com -р 389 -х -D "cn=trent,cn=users,dc=boulder,dc=atrust,dc=cQm" -W -b "CN=users , DC=boulder, DC=atrust, DC=com" ” cn=ned* " Enter LDAP Password: пароль # LDAPv3 # base <CN=users,DC=boulder,DC=atrust, DC=com> with scope sub # filter: cn=ned* # requesting: ALL # # ned, Users, boulder.atrust.com dn: CN=ned,CN=Users,DC=boulder,DC=atrust,DC=com
780 Часть II. Работа в сети objectclass: top objectclass: person objectclass: organizationalPerson objectclass: user on: ned sn: McClain telephoneNumber: 303 245 4505 givenName: Ned distinguishedName: CN=ned, CN=Users, DC=boulder, DC=atrust, DC=com displayName: Ned McClain memberOf: CN=Users,CN=Builtin,DC=boulder,DC=atrust,DC=com memberOf: CN=Enterprise Admins,CN=Users,DC=boulder,DC=atrust,DC=com name: ned sAMAccountName: ned userPrincipalName: nedOboulder.atrust.com lastLogonTimestamp: 129086952498943974 mail: ned@atrust.com Флаги -h и -p команды Idapsearch позволяют указать в запросе узел и порт серве- ра LDAP соответственно. Обычно вам потребуется аутентифицировать себя на сервере LDAP. В этом случае используются специальные флаги. Флаг -х запрашивает простую аутентификацию (в от- личие от SASL). Флаг -D идентифицирует отличительное имя учетной записи пользо- вателя, который имеет права доступа, необходимые для выполнения запроса. Наконец, флаг -W предписывает утилите Idapsearch предложить вам ввести соответствующий пароль. Флаг -Ь указывает утилите Idapsearch, где именно в иерархии LDAP начать поиск. Этот параметр известен как baseDN (отсюда и имя флага “Ь”). По умолчанию утили- та Idapsearch возвращает все соответствующие критерию поиска строки, найденные ниже базовой точки дерева baseDN, т.е. поиск будет выполняться только в дочерних эле- ментах базы поиска (включая ее саму). Подстроить характер такого поиска можно с по- мощью флага -s. Последний аргумент представляет собой “фильтр”, который описывает объект ваше- го поиска. Он не требует использования флагов. Этот фильтр, cn=ned*, обеспечивает возвращение всех строк LDAP, “обычное имя” которых начинается с “ned”. Этот фильтр заключается в кавычки ("cn=ned*"), чтобы специальные символы универсализации в строке поиска (в данном случае это “звездочка”) не были восприняты системой как управляющие символы командной оболочки. Если вы хотите извлечь все записи ниже заданной базы baseDN, просто используйте в качестве фильтра поиска выражение objectClass=* — или же опустите фильтр во- обще, поскольку такой характер поиска действует по умолчанию. Любые аргументы, которые указаны за фильтром, обеспечивают выбор конкретных атрибутов для возвращаемого результата. Например, если бы вы добавили в конец при- веденной выше командной строки аргумент mail givenName, утилита Idapsearch возвратила бы только эти атрибуты отфильтрованных записей. LDAP и безопасность Так уж сложилось, что протокол LDAP использовался чаще всего по принципу теле- фонного каталога, поэтому отправка данных без шифрования была обычным делом. Как результат, “стандартная” реализация LDAP предоставляет незашифрованный доступ че-
Глава 19. Совместное использование системных файлов 781 рез ТСР-порт 389. Однако мы настоятельно не советуем использовать незашифрован- ный протокол LDAP для передачи информации об аутентификации, даже если пароли индивидуально хешируются или зашифровываются. Как вариант, во многих ситуациях (даже в мире Microsoft) LDAP можно использовать на основе SSL (эта комбинация известна как LDAPS; обычно эта пара работает на ТСР- порте 686) на стороне как сервера, так и клиента. Такой способ доступа является пред- почтительным, поскольку он защищает информацию, содержащуюся как в запросе, так и в ответе. Желательно использовать LDAPS везде, где это возможно. Столь сложная система, как LDAP, неизбежно содержит бреши, ослабляющие ее за- щиту, не говоря уже о брешах, издавна существующих в операционной системе. Поэтому системным администраторам постоянно приходится быть начеку. 19.4. NIS: СЕТЕВАЯ ИНФОРМАЦИОННАЯ служба Административная СУБД NIS (Network Information Service — сетевая информацион- ная служба), выпущенная компанией Sun в 80-х годах, была первой СУБД такого рода. Сначала она называлась Sun Yellow Pages (желтые страницы Sun), но по причинам пра- вового характера ее пришлось переименовать. Команды NIS до сих пор начинаются с префикса ур, поскольку имя, данное при рождении, забыть трудно. СУБД NIS была с воодушевлением принята поставщиками UNIX-систем и поддерживается во всех дис- трибутивах Linux. Но в наши дни для новых систем все же не следует использовать NIS, причем не только из-за неизбежной интеграции с системами Windows, но и из-за несовершенства NIS-системы безопасности и масштабируемости. Тем не менее мы кратко рассмотрим службу NIS из уважения к большому числу дей- ствующих систем, на которых она все еще используется. Модель NIS Единицей совместного использования в NIS является запись, а не файл. Зайись обыч- но соответствует одной строке конфигурационного файла. Главный сервер хранит офи- циальные копии системных файлов, которые находятся в исходных каталогах и имеют текстовый формат. Серверный процесс делает эти файлы доступными по сети. Сервер и его клиенты образуют домен NIS5. Для повышения эффективности поиска текстовые файлы преобразуются в файлы базы данных с помощью хеширующих функций библиотеки. После редактирования файлов на главном сервере необходимо попросить NIS преобразовать их в хеширован- ный формат с помощью программы make. Полученный файл называется картой (шар). С каждой записью может быть связан всего один ключ, поэтому системные файлы иногда приходится транслировать в несколько карт NIS. Например, файл /etc/passwd преобразуется в две карты: passwd.byname и passwd.byuid. Первая служит для отбо- ра записей по имени пользователя, а вторая — для поиска по идентификатору. Любую из них можно использовать для выборки всех записей файла passwd, но хеширующие функции не сохраняют порядок записей, поэтому нельзя воссоздать точную копию ис- ходного файла. 5 Не следует путать домены NIS с доменами DNS. Это абсолютно разные понятия, не имею- щие ничего общего.
782 Часть ll. Работа в сети --_--------- , ' СУБД NIS позволяет реплицировать карты сети среди группы подчиненных серве- ров. Это дает возможность ослабить нагрузку на главный сервер и поддерживать функ- ционирование клиентов даже в том случае, когда некоторые серверы недоступны. Если на главном сервере файл изменился, необходимо разослать соответствующую карту NIS всем подчиненным серверам, чтобы везде были одинаковые данные. Клиенты не раз- личают главный и подчиненные серверы. Схема работы NIS Файлы данных NIS хранятся в одном каталоге, обычно в каталоге /var/ур. Далее мы будем называть его “NIS-каталогом”. Все карты NIS хранятся в хешированном виде (в формате базы данных) в подкаталоге NIS-каталога, соответствующем домену NISI Точное имя и количество таких файлов зависит от используемой библиотеки хеширу- ющих функций. Для каждого поля (ключа), по которому можно осуществить поиск в файле, должна быть создана отдельная карта. Например, в домене cssuns карты DB для файла /etc/passwd могут называться так. /var/yp/cssuns/passwd. byname /var/ур/cssuns/passwd. byuid Команда makedbm создает карты NIS из обычных файлов. Ее никогда не нужно вы- зывать непосредственно. Файл Makefile в каталоге /var/ур сконфигурирован так, что- бы автоматически генерировать все распространенные карты NIS. После модификации какого-нибудь системного файла перейдите в каталог /var/ур и запустите программу- make. Она сверит время модификации каждого файла со временем модификации соот- ветствующих карт и выполнит команду makedbm для каждой карты, который необходи- мо перестроить. М В системах HP-UX вместо команды make используется команда ypmake. , Копирование карт с главного сервера на подчиненные осуществляет команда ypxf хм Она работает по модели запроса: для того чтобы она импортировала карты, ее нужней запускать на каждом подчиненном сервере. Подчиненные серверы время от времени выполняют команду ypxf г для того, чтобы проверить, последние ли версии карт на^ ходятся в их распоряжении. С помощью демона cron можно управлять периодичностью J этих проверок. Стандартная реализация механизма копирования карт несколько неэффективна, поэтому в Linux существует демон rpc. ypxf rd, который можно запустить на главном сервере для ускорения ответов на запросы команды ypxf г. Этот демон работает в обход стандартного протокола NIS и просто рассылает копии файлов карт. К сожалению, в разных системах файлы карт хранятся с использованием различных форматов баз дан- ных и разного порядка следования байтов, поэтому применение команды ypxf rd чрева- то возможной несовместимостью. Команда yppush используется на главном сервере. Она не пересылает никаких данных, а просто заставляет каждый подчиненный сервер выполнить команду ypxfr. Команда yppush задается в файле Makefile, находящемся в NIS-каталоге, и обеспечи- вает принудительную рассылку откорректированных карт на подчиненные серверы. Существует специальная карта ypservers, которая не соответствует ни одному обыч- ному файлу. Он содержит список всех серверов домена и создается автоматически при
Глава 19. Совместное использование системных файлов 783 конфигурировании домена с помощью команды ypinit. Содержимое этой карты изуча- ется всякий раз, когда главному серверу нужно разослать карты на подчиненные серверы. После начального конфигурирования единственными активными компонентами си- стемы NIS остаются демоны ypserv и ypbind. Первый из них работает только на серве- рах (и главном, и подчиненных); он принимает запросы от клиентов и отвечает на них, осуществляя поиск информации в хешированных файлах карт. Демон ypbind работает на всех компьютерах NIS-домена, включая серверы. Функ- ции библиотеки языка С обращаются к локальному демону ypbind всякий раз, когда им нужно ответить на административный запрос (при условии, что это разрешено установ- ками файла /etc/nsswitch. conf). Демон ypbind находит в соответствующем домене демон ypserv и возвращает его адрес библиотечной функции, которая затем обращает- ся непосредственно к серверу. Современные версии демона ypbind периодически проверяют, работают ли они с наиболее активным сервером в домене NIS. Это является улучшением по сравнению с традиционной реализацией демона, в которой осуществлялась привязка к определен- ному серверу. В NIS есть ряд вспомогательных команд, которые предназначены для изучения карт, определения версий карт, используемых каждым сервером, и управления привязкой клиентов к серверам. Полный перечень команд и демонов NIS приведен в табл. 19.4. Таблица 19.4. Команды и демоны NIS Утилита Отйаний^< ypserv Демон сервера NIS; запускается на этапе начальной загрузки ypbind Демон клиента NIS; запускается на этапе начальной загрузки domainnaxne Задает домен NIS, в который входит компьютер (выполняется на этапе начальной загрузки) ypxf г Загружает текущую версию карты с главного сервера ypxf rd Обслуживает запросы, поступающие от команды ypxf г (работает на главном сервере) yppush Заставляет подчиненные серверы обновить свои версии карты makedbm Создает хешированную карту из обычного файла ypmakea Обновляет хешированные карты для тех файлов, которые изменились ypinit Конфигурирует компьютер как главный или подчиненный сервер yPset Заставляет демон ypbind установить соединение с конкретным сервером® ypwhich Определяет, с каким сервером работает текущий компьютер yppoll Определяет, какую версию карты использует сервер ypcat Отображает значения, содержащиеся в карте NIS ypmatch Отображает элементы карты, соответствующие заданному ключу yppasswd Изменяет пароль на главном сервере NIS ypchfn Изменяет содержимое поля GECOS на главном сервере NIS ypchsh Меняет регистрационный интерпретатор команд на главном сервере NIS yppasswdd Сервер для команд yppasswd, ypchsh и ypchfn ypupdated6 Сервер для обновления карты NIS (управляется демоном inetd) ______________ 8 Нужно отдельно включать с помощью команды ypbind -ypsetme или ypbind -ypset (второй вариант опаснее). 6 Не используется или не поддерживается во всех системах.
784 Часть II. Работа в сети Безопасность NIS Система NIS небезопасна. Особенно неприятен широковещательный режим. Любой узел сети может выступить в качестве сервера для того или иного домена и распростра- нить среди NIS-клиентов ложные административные данные. В системах Linux эту про- блему можно смягчить, если явно указать каждому клиенту доступные ему серверы NIS. Если вопросы безопасности системы для вас очень важны, не следует использовать NIS для управления скрытыми паролями. Используйте для этого такие альтернативные распределенные механизмы аутентификации, как LDAP. В старых версиях СУБД NIS содержала множество “прорех”. Поэтому используйте только современную версию NIS. 19.5. Задание приоритетов для источников АДМИНИСТРАТИВНОЙ ИНФОРМАЦИИ Информацию о конфигурации можно распространять несколькими способами. Любая система способна обрабатывать обычные файлы и осуществлять поиск имен компью- теров и IP-адресов в DNS. Поскольку для каждого элемента информации может суще- ствовать несколько потенциальных источников, предусмотрен способ задания источни- ков и порядка их опроса. Конфигурационный файл /etc/nsswitch. conf (/etc/netsvc. conf в системе AIX) позволяет для каждого типа административной информации указывать явный путь по- иска. Типичный файл nsswitch.conf выглядит следующим образом. passwd: files Idap hosts: files dns group: files Каждая строка соответствует отдельному типу информации (обычно это эквивалент одного текстового файла). Обычные источники таковы: nis, nisplus, files, dns, Idap и compat. Им соответствуют (в порядке перечисления) NIS, NIS+6, обычные текстовые файлы (без учета специальных обозначений вроде “+”), DNS, LDAP и обычные файлы системы NIS. DNS предоставляет информацию только о узлах и сетях. Источники просматриваются слева направо, пока один из них не выдаст ответ на за- прос. В показанном выше примере функция gethostbyname сначала Проверит файл / etc/hosts и, если требуемый узел там не указан, обратится к DNS. В процессе обработ- ки запросов, касающихся UNIX-групп, будет проверяться только файл /etc/group. В случае необходимости можно явно указать, как следует поступать при получении отрицательного ответа на запрос от того или иного источника. Соответствующее усло- вие берется в квадратные скобки. Например, строка hosts: dns [NOTFOUND=retum] files заставляет получать информацию только от DNS, если эта служба доступна. Получение отрицательного ответа от сервера имен приведет к немедленному завершению запроса (с выдачей кода ошибки) без обращения к текстовым файлам. В то же время текстовые файлы будут задействованы, если все серверы имен окажутся недоступными. В табл. 19.5 перечислены различные условия проверки ошибок. Каждое из них может быть задано 6 Неудачный “наследник” исходной версии NIS уже не поддерживается фирмой Sun, хотя в некоторых системах его все еще можно встретить.
Глава 19. Совместное использование системных файлов 785 равным return или continue, что означает прерывание запроса или переход к следую- щему источнику соответственно. Таблица; 19.5. Условия проверки ошибок в файле /etc/nsswitch.conf УСЛОВИф . UNAVAIL NOTFOUND TRYAGAIN SUCCESS Источник не существует или недоступен Источник существует, но не может ответить на запрос Источник существует, но занят Источник смог ответить на запрос В большинство дистрибутивов систем входит файл nsswitch.conf, который подхо- дит для изолированного компьютера. Источником всех данных служат обычные файлы, за исключением информации о узлах (сначала опрашиваются файлы, потом — DNS). В некоторых системах для файлов passwd и group задан источник compat, что, скорее всего, нежелательно. Если вы действительно используете NIS, просто вставьте этот ис- точник в файл nsswitch.conf. Демон nscd: кеширование результатов поиска В В некоторых дистрибутивах Linux большую роль в обработке системных фай- Zjb лов играет демон nscd, название которого немного сбивает с толку (лате ser- vice cache daemon — демон кеширования для службы имен). Демон nscd работает в связке с библиотекой языка С, кешируя результаты таких функ- ций, как getpwent, и подобных ей. По сути, демон является просто оболочкой этих функций; ему не известно, какие источники данных опрашивались. Теоретически демон должен способствовать повышению эффективности поиска информации в системных файлах, но с точки зрения пользователей реальный эффект практически не ощутим. Ш О DNS рассказывалось в главе 17. Мы говорим, что название “демон кеширования для службы имен” способно ввести в заблуждение, поскольку термин “служба имен” обычно относится к DNS, распределен- ной СУБД, осуществляющей связь между доменными именами и IP-адресами. Демон nscd, в числе прочего, кеширует и результаты DNS-запросов (одна из контролируемых им функций — gethostbyname), он также связан с функциями, черпающими информа- цию из файлов passwd и group, и их сетевыми эквивалентами (из соображений безо- пасности, результаты запросов к файлу /etc/shadow не кешируются). В принципе, демон nscd не должен влиять на работу системы; он лишь ускоряет выполнение повторяющихся операций поиска. Но на практике влияние демона может оказаться непредсказуемым из-за того, что он хранит собственную копию результа- тов поиска. Эти данные находятся в кеше в течение фиксированного интервала времени (задается в конфигурационном файле демона — /etc/nscd.conf), поэтому всегда есть вероятность того, что самые последние изменения не будут отражены в кеше, пока преж- ние данные не устареют. Вообще-то, демон достаточно “умен” и следит за состоянием ло- кальных источников данных (например, файлом /etc/passwd), поэтому локальные изме- нения должны вступать в силу в течение 15 секунд. Что касается удаленных источников, например NIS, то в худшем случае величина задержки будет равна периоду устаревания. Мы с вами упоминали несколько примеров дистрибутивов. Так вот, только SUSE запускает nscd по умолчанию. В системе Red Hat демон nscd инсталлируется, но по
786 Часть II. Работа в сети умолчанию не запускается на этапе загрузки системы; чтобы разрешить использование демона nscd, выполните команду chkconfig nscd on. Система Ubuntu разрешает ра- боту демона nscd, но не инсталлирует его по умолчанию; чтобы его загрузить, нужно выполнить команду apt-get install nscd. Демон nscd запускается на этапе начальной загрузки и работает непрерывно. По умолчанию в файле /etc/nscd.conf задан период 10 минут для файла passwd и 1 час — для файлов hosts и group. Интервал между попытками в случае неудачного запроса составляет 20 секунд. Эти значения редко приходится менять. Если вас удивляет, что сделанные вами изменения не вступили в силу, то, очевидно, виной тому демон nscd. 19.6. Рекомендуемая литература • Carter, Gerald. LDAP System Administration. Sebastopol, CA: O’Reilly Media, 2003. • Malere, Luiz Ernesto Pinheiro. LDAP Linux HOWTO, tldp. org • Volgmaier, Reinhard. The ABCs of LDAP: How to Install, Run, and Administer LDAP Servi- ces. Boca Raton, FL: Auerbach Publications, 2004. • LDAP for Rocket Scientists, zy tr ax. com/books / Idap 19.7. Упражнения 19.1. Почему метод обновления файлов локального компьютера по запросу считается безопаснее метода принудительной рассылки? 19.2. Поясните приведенный ниже фрагмент управляющего файла утилиты rdist. LINUX_PASSWD = ( redhatbox ubuntubox susebox ) passwd: ( /etc/passwd ) -> ( ${LINUX_PASSWD} ) install /etc/passwd.rdist; cmdspecial /etc/passwd.rdist ”/usr/local/sbin/mkpasswd"; 19.3. Объясните разницу между утилитами rdist и rsync. В каких случаях предпо- чтительнее использовать ту или другую? 19.4. 18г Какой метод совместного использования файлов применяется в вашей системе? Какие проблемы безопасности при этом возникают? Предложите альтернативную схему совместного использования файлов и укажите ее преимущества и недостатки. 19.5. Придумайте схему LDAP, которая хранила бы такую информацию о пользователе, как регистрационное имя, пароль, оболочка, авторизированные компьютеры и т.п. Создайте инструмент, с помощью которого можно в интерак- тивном режиме добавлять новых пользователей в базу данных из файла, содер- жащего список пользователей. Создайте инструмент, который будет генерировать файлы passwd, group и shadow из базы данных LDAP для компьютеров, работаю- щих в вашем отделе. Разрешите пользователям иметь различные пароли на каждом компьютере. (Чтобы пользоваться каждым компьютером, не всем пользователям нужна обязательная авторизация.) Ваша система adduser должна уметь печатать списки регистрационных имен существующих пользователей и пары “регистраци- онное имя/пароль” для новых пользователей.
Глава 20 Электронная почта Социальные сети и пересылка SMS-сообщений постепенно вытесняют электронную почту в категорию “устаревших технологий”, поскольку возникают новые отношения и новые темы для обсуждения (microthoughts). Тем не менее электронная почта остается универсальным стандартом общения по сети. Все, от старушек до огромных корпора- ций, привыкли использовать электронную почту для общения с семьей, коллегами, пар- тнерами, потребителями и даже с правительством. Этот безумный, безумный, безумный мир электронной почты!1 Электронная почта проста и удобна; если вы знаете чей-нибудь почтовый адрес, то набираете сообщение и щелкните на кнопке Send. Все! Уже через несколько секунд это сообщение окажется в электронном почтовом ящике адресата, независимо от того, где он находится: в соседней комнате или в другой части Земного шара. С точки зрения пользователя, ничего не может быть проще. Инфраструктура, лежащая в основе электронной почты и обеспечивающая все ее удобства, напротив, довольно сложная. Существует несколько программных пакетов, с помощью которых можно посылать сообщения электронной почты и управлять ею (три из них будут рассмотрены в этой главе), но все они требуют довольно сложного кон- фигурирования и управления. Кроме того, необходимо понимать основные концепции и протоколы, связанные с электронной почтой, чтобы у вас не сложилось ложное пред- ставление, что кроссплатформенная и интерорганизованная (interorganizational) элек- тронная почта — это подарок небес, работающий по мановению волшебной палочки. Понимание собственной инфраструктуры электронной почты и управление ею тре- буется не только от системного администратора. Многие провайдеры сегодня предлага- 1 Даже когда Эви пересекала на паруснике океан, она всегда находилась в контакте по элек- тронной почте с помощью своего бортового радиопередатчика HAM/SSB и “скоростного” пакета для радиосвязи, скорость которого в лучшем случае приближалась к 30 бод.
788 Часть II. Работа в сети ют “управляемую” службу электронной почты, которая размещает систему электронной почты на удаленных серверах за ежемесячную или ежегодную плату (иногда за каждого пользователя отдельно). Существует также множество аналогичных “бесплатных” служб, таких как Gmail компании Google, Yahoo! Mail и MSN Hotmail, имеющих большую по- пулярность среди индивидуальных пользователей. Если вы хотите получить персональ- ную учетную запись электронной почты или открыть почтовый адрес для маленькой компании, то эти службы будут удобными для вас. Служба Gmail не только предостав- ляет персональные учетные записи электронной почты, но и обладает интересной воз- можностью настраивать электронную почту для всего домена. Детали этого механизма и описание процесса настройки можно найти на странице google. сот/а или наберите в поисковой строке системы Google запрос “hosted Gmail”. Служба, размещенная на удаленном сервере, решает массу проблем, включая хране- ние, управление сервером, обновление программного обеспечения, конфигурирование, фильтрацию спама, резервное копирование и обеспечение безопасности. Как плата за услуги “бесплатных” служб, вы, возможно, будете вынуждены получать рекламные объ- явления и пожертвовать конфиденциальностью. Во многих ситуациях это хороший вы- бор; если служба, расположенная на удаленном сервере, вас устраивает, то остальную часть это огромной главы можно не читать. Однако служба электронной почты, расположенная на удаленном сервере, устраи- вает не всех. Коммерческие и другие крупные организации, работа которых зависит от электронной почты, не желают рисковать, размещая службу электронной почты за пределами своего офиса. Такие организации могут иметь множество причин для разме- щения службы электронной почты на своих серверах, включая вопросы безопасности, производительности и доступности. Эта глава предназначена именно для них. Огромный объем этой главы свидетельствует о том, что почтовые системы — доста- точно сложная тема. Здесь изложены только основные сведения. Схематическое описа- ние главы представлено в табл. 20.1. Таблица 20.1. Структура главы Описание Раздел Основы 20.1 Вопросы проектирования почтовых систем 20.4 Спам и вредоносные программы 20.6 Фильтрация вирусов и спама с помощью интерфейса amavisd 20.6 Настройка программы sendmail 20.8 Настройка агента exim 20.14 Настройка агента postfix 20.15 Технология DKIM 20.16 Интегрированные системы электронной почты 20.17 20.1. Системы электронной почты Теоретически система электронной почты состоит из нескольких компонентов. • Пользовательский агент (“mail user agent”— MUA или UA)9 который дает пользовате- лям возможность читать и составлять сообщения.
Глава 20. Электронная почта 789 • Агент передачи электронной почты (mail submission agent — MSA), принимающий по- чту, исходящую от агента MUA, обрабатывающий ее и передающий транспортной системе. • Транспортный агент (mail transport agent — МТА), который пересылает сообщения с одного компьютера на другой. • Агент доставки (delivery agent — DA), который помещает сообщения в локальное хранилище2. • Необязательный агент доступа (acess agent — АА), который связывает пользо- вательский агент с хранилищем сообщений (например, посредством протокола IMAP или POP). К некоторым из этих агентов присоединяются инструменты для распознания спама, вирусов и (исходящих) внутренних секретов компании. Схема взаимодействия всех ука- занных компонентов представлена на рис. 20.1. Компьютер А - отправитель Компьютер Б - получатель Рис. 20.1. Компоненты почтовой системы Пользовательские агенты Пользовательский агент (иногда говорят “клиент электронной почты”) применяется для чтения и составления электронных сообщений. Первоначально сообщения могли со- держать только простой текст, однако благодаря стандарту MIME (Multipurpose Internet Mail Extensions — многоцелевые расширения электронной почты в сети Интернет) по- явилась возможность включать в них форматированный текст и присоединять разные файлы (в том числе вирусы). Стандарт MIME поддерживается большинством пользова- тельских агентов. Поскольку он не влияет на процесс адресации и доставки почты, мы не будем его рассматривать. Самым первым пользовательским агентом была утилита /bin/mail, которая и сей- час остается удобным инструментом для чтения текстовых сообщений. Поскольку элек- тронная почта в Интернете давно вышла за пределы “текстовой эры”, пользовательские агенты, ориентированные на текст, для большинства пользователей являются непрак- 2 Иногда это почтовые ящики пользователей, иногда — база данных.
790 Часть II. Работа в сети тичными. Но не следует отбрасывать утилиту /bin/mail; она остается удобным ин- терфейсом для сценариев и других программ. (Один “завзятый” пользователь системы Linux каждую ночь посылает сообщение электронной почты от демона cron программе- планировщику, чтобы при первом взгляде на календарь становился ясным статус всех его программ. По умолчанию демон cron использует утилиту /bin/mail для уведомле- ния пользователя в ситуациях, когда он не может выполнить задание, указанное в рас- писании.) Одна из элегантных функциональных возможностей, проиллюстрированных на рис. 20.1, состоит в том, что пользовательский агент не обязан выполняться в той же самой системе и даже на той же самой платформе, на которой выполняется остальная часть почтовой системы. Пользователи могут получить свои сообщения электронной почты на ноутбуках или смартфонах, работающих под управлением системы Windows, с помощью протоколов агентов доступа IMAP или POP. Страница http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients3 содержит подробный список многих клиентов электронной почты, операционных си- стем, в которых они выполняются, и функциональные возможности, которые они поддерживают. К популярным клиентам относятся Thunderbird, Alpine, Zimbra и, раз- умеется, Microsoft Outlook. Страница http://en.wikipedia.org/wiki/Comparison_ of webmail providers содержит информацию о таких веб-службах, как Gmail, Hormail и Yahoo! Mail. Агенты представления Агенты MSA — последнее новшество в пантеоне электронной почты — были изобре- тены для того, чтобы разгрузить агентов МТА от некоторых задач. Агенты MSA облег- чают серверам-концентраторам задачу различения входящих и исходящих сообщений (например, для принятия решения об ответе) и обеспечивают пользовательским агентам единообразную и простую конфигурацию исходящей почты. Агент MSA напоминает секретаря, кторый ведет прием новых сообщений и внедрен в систему локальными пользовательскими агентами. Агент MSA располагается между поль- зовательским и транспортным агентами и выполняет несколько функций, которые ранее относились к компетенции агента МТА. Агент MSA реализует безопасную (зашифро- ванную и аутентифицированную) связь с пользовательскими агентами и часто немного изменяет заголовки и удаляет входящие сообщения. Во многих ситуациях агент MSA просто прослушивает агентов МТА на разных портах, применяя разные конфигурации. Агенты MSA используют тот же протокол передачи почты, что и агенты МТА, поэто- му с точки зрения пользовательских агентов они выглядят как агенты МТА. Однако они обычно прослушивают соединение на порту 587, а не 25, который является стандартным для агентов МТА. При такой схеме работы пользовательские агенты должны соединять- ся с портом 587, а не 25. Если ваш пользовательский агент не может использовать порт 587, вы можете запустить агента MSA на порту 25, но в системе, которая отличается от системы, в которой был запущен агент МТА; в каждый момент времени на конкретном порту можно прослушивать только один процесс. Агент MSA может помочь решить несколько задач, возникающих из-за спама. Для рассылки большого количества спама используются инфицированные домашние персо- нальные компьютеры. В результате многие интернет-провайдеры, обслуживающие до- машние компьютеры, либо блокируют исходящее соединение на порту 25, либо требу- 3 Актуальность ссылок на момент выхода русского издания не гарантируется. — Примеч. ред.
Глава 20. Электронная почта 791 ют верификации учетной записи в процессе обмена информацией по протоколу SMTP. Домашний персональный компьютер может использовать собственный почтовый сервер интернет-провайдера для исходящих сообщений, но некоторые современные механиз- мы фильтрации спама, такие как протоколы SPF (раздел 20.6) и DKIM (20.16), требуют, чтобы почта, отправляемая организацией, действительно создавалась именно указанной организацией. Если вы используете агент MSA, проверьте, что конфигурация вашего транспортного агента задана так, что он не дублирует работу, выполняемую агентом MS А. Обработка дубликатов никак не влияет на корректность обработки почты, но заставляет систему выполнять дополнительную ненужную работу. Поскольку агент MSA для передачи сообщений использует агент МТА, для взаимной аутентификации оба агента должны использовать протокол SMTP-AUTH. В противном случае возникнет так называемая “открытая передача” (open relay), которую могут ис- пользовать спамеры, и другие сайты занесут ваш адрес в “черный список”. Транспортные агенты Задача транспортного агента — принимать почту от пользовательского агента или агента представления, интерпретировать адреса получателей и перенаправлять почту на соответствующие компьютеры для последующей доставки. Транспортные агенты рабо- тают по протоколу SMTP (Simple Mail Transport Protocol — простой протокол передачи электронной почты), который вначале был определен в документе REC821, а затем до- полнен в документе RFC5321. Расширенная версия этого протокола называется ESMTP (Extended SMTP). Список заданий транспортных агентов как отправителя, так и получателя содержит следующие пункты. • Получение сообщений электронной почты от удаленных почтовых серверов. • Распознавание адресов получателей. • Перезапись адресов получателей в форме, понятной для агента доставки. • Перенаправление сообщения следующему ответственному серверу или передача его локальному агенту доставки для сохранения в почтовом ящике пользователя. Большая часть работы, связанной с настройкой почтовой системы, сводится к кон- фигурированию транспортного агента. В книге мы рассматриваем три агента MSA с от- крытым кодом: sendmail, Exim и Postfix. Локальные агенты доставки Агент доставки, которого иногда называют также локальным агентом доставки (local delivery agent — LDA), отвечает за прием почты от транспортного агента и ее передачу соответствующим получателям на локальном компьютере. Почта может доставляться конкретному пользователю, в список рассылки, в файл и даже в программу. Однако два последних получателя могут ослабить конфиденциальность и безопасность вашей си- стемы. Транспортные агенты обычно содержат встроенных локальных агентов доставки. Например, программы procmail (procmail.org) и Maildrop (courier-mta.org/ maildrop) являются локальными агентами доставки, которые способны фильтровать и сортировать почту перед ее доставкой. Некоторые агенты доступа (АА) также имеют встроенных агентов доставки, выполняющих как доставку, так и другие задания.
792 Часть II. Работа в сети Хранилища сообщений Хранилище сообщений — пункт назначения, находящийся в конце долгого пути, кото- рый сообщение электронной почты проходит по Интернету от отправителя к получателю. Почта обычно хранится в формате mbox или Maildir. В первом случае вся почта хранится в одном файле, как правило, /var/mail/имя пользователя, а индивидуаль- ные сообщения отделяются специальной линией From. Во втором варианте каждое со- общение хранится в отдельном файле. Хранить сообщения в отдельных файлах намного удобнее, но при этом в каталоге находится очень много маленьких файлов; некоторые файловые системы этого не одобряют. Эти простые файлы до сих пор используются в качестве хранилищ сообщений, но интернет-провайдеры, имеющие тысячи и миллионы клиентов электронной почты, ищут другие технологии для реализации своих хранилищ, как правило, на основе баз данных. Хранилища сообщений становятся все более сложными. Агенты доступа Для доступа к хранилищам и загрузки сообщений электронной почты на локаль- ное устройство (рабочую станцию, ноутбук, телефон и т.п.) используется два протоко- ла: IMAP4 и POP. Ранние версии этих протоколов имели проблемы с безопасностью. Убедитесь, что вы используете версию (IMAPS или POP3S), которая реализует шифрова- ние SSL и не передает через Интернет пароли в открытом виде. Мы предпочитаем протокол IMAP (Internet Message Access Protocol — протокол до- ступа к электронной почте Интернета). Он лучше, чем протокол POP, поскольку достав- ляет ваши почтовые сообщения по одному, а не все сразу, что более удобно для работы в сети (особенно если линии связи не обладают высокой пропускной способностью) и комфортнее для людей, перемещающихся с места на место. Протокол IMAP также луч- ше обрабатывает огромные файлы, которые многие любят присоединять к своим сооб- щениям: вы можете просматривать заголовки своих сообщений и не загружать вложен- ные файлы, пока не будете готовы к работе с ними. Протокол IMAP управляет почтовыми каталогами на нескольких сайтах; например, на почтовом сервере и на вашем персональном компьютере. Почта, размещенная на почтовом сервере, может стать частью процедуры резервного копирования. Страница Википедии, посвященная протоколу IMAP, содержит много информации о его доступ- ных реализациях. Протокол POP (Post Office Protocol — протокол почтового отделения) аналогичен протоколу IMAP, но основан на модели, в которой все почтовые сообщения загружают- ся с сервера на клиентский компьютер. При этом почта может быть либо удалена с сер- вера (в этом случае ее невозможно впоследствии восстановить), либо сохранена на нем (в этом случае буферный файл почты становится все больше и больше). Парадигма “вся почта за один раз” неудобна для работы в сети и некомфортна для пользователя. Если пользователь никогда не выбрасывает ненужного старья, то передача почты может стать очень медленной, а буферный файл достигнет огромных размеров. Серверы IMAP/POP имеют несколько реализаций: Courier, Cyrus IMAP, Dovecot, imapd университета штата Вашингтон (Сиэтл) и Zimbra. Мы предпочитаем серверы Dovecot и Zimbra4. Протоколы IMAP и POP поддерживают практически все почтовые пользовательские агенты. 4 Zimbra — это не просто агент доступа, а, скорее, полноценная промышленная почтовая си- стема (см. раздел 20.17).
Глава 20. Электронная почта 793 Так много компонентов, так мало времени Если почтовая система состоит из множества компонентов (а мы еще даже не упо- минали о сканировании спама и вирусов!), то ее архитектура, скорее всего, является слишком сложной. Однако в небольших организациях транспортные агенты могут ад- сорбировать функции агентов представления и локальных агентов доставки, что позво- ляет упростить почтовую систему. Более крупные организации могут пожелать хранить все компоненты по отдельности и выполнять несколько их экземпляров одновремен- но, чтобы обеспечить распределенную загрузку. На самом деле почтовая система может быть настолько же сложной, насколько и простой, в зависимости от вашего желания. Проблемы ее проектирования рассматриваются в разделе 20.4. 20.2. Структура почтового сообщения Структура электронного сообщения состоит из трех частей. • Конверт • Заголовки • Тело Конверт определяет, куда должно быть доставлено сообщение или куда его требуется возвратить в случае, если доставка невозможна. Обычно конверт невидим для пользова- теля и не является частью самого сообщения; он используется транспортным агентом. Если отправителем и получателем являются обычные люди, то адреса конверта обыч- но согласованы со строками From и То заголовка. Если же сообщение направлено спи- ску рассылки или было сгенерировано спамером, пытающимся подделать идентичность отправителя, то конверт и заголовки могут быть не согласованы друг с другом. Заголовки — это набор пар “свойство/значение”, отформатированных в соответствии с документом RFC5322. В них содержится различная информация о сообщении, вклю- чая дату и время его отправки, а также сведения о транспортных агентах, через которые оно прошло на своем пути. Заголовки являются неотъемлемой частью сообщения, но пользовательские агенты часто скрывают некоторые менее интересные заголовки при отображении сообщения. Тело сообщения — это та информация, которую, собственно, и требуется переслать. Оно должно содержать обычный текст, однако часто он представляет собой двоичные данные в специальной почтовой кодировке. Заголовки почтовых сообщений Системный администратор должен уметь анализировать заголовки почтовых сообще- ний и выявлять с их помощью возникшие проблемы. Многие пользовательские агенты скрывают заголовки, но существует способ их увидеть, открыв хранилище сообщений в текстовом редакторе. Ниже приведены заголовки (с сокращениями, обозначенными многоточиями) из обычного сообщения, которое не является спамом. Мы удалили по- ловину страницы заголовков, которые система Gmail использует для фильтрации спама. Delivered-To: sailingevi@gmail.com Received: by 10.231.39.205 with SMTP id...; Fri, 16 Oct 2009 08:14:27 -700 (PDT) Received: by 10.114.163.26 with SMTP id...; Fri, 16 Oct 2009 08:14:26 -700 (PDT) Return-Path: <david@schweikert.ch> Received: frommail-relay.atrust.com (mail-relay.atrust.com [63.173.189.2])
794 Часть II. Работа в сети by mx.google.com with ESMTP id 17si2166978pxi.34.2009.10.16.08.14.20; Fri, 16 Oct 2009 08:14:25 -0700 (PDT) Received-SPF: fail (google.com: domain of david@schweikert.ch does not designate 63.173.189.2 as permitted sender) client-ip=63.173.189.2; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of david@schweikert.ch does not designate 63.173.189.2 as permitted sender) smtp.mail=david@schweikert.ch Received: from mail.schweikert.ch (nigel.schweikert.ch [88.198.52.145]) by mail-relay.atrust.com (8.12.11/8.12.11) with ESMTP id n9GFEDKA029250 for <evi@atrust.com>; Fri, 16 Oct 2009 09:14:14 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.schweikert.ch (Postfix) with ESMTP id 3251112DA79; Fri, 16 Oct 2009 17:14:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.schweikert.ch Received: from mail.schweikert.ch ([127.0.0.1]) by localhost (mail.schweikert.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV8BpT7rhJKC; Fri, 16 Oct 2009 17:14:07 +0200 (CEST) Received: by mail.schweikert.ch (Postfix, from userid 1000) id 2A15612DB89; Fri, 16 Oct 2009 17:14:07 +0200 (CEST) Date: Fri, 16 Oct 2009 17:14:06 +0200 From: David Schweikert <david@schweikert.ch> To: evi@atrust.com Cc: Garth Snyder <garth@garthsnyder.com> Subject: Email chapter comments Для того чтобы прочитать эту тарабарщину, начнем со строк Received, но в направ- лении снизу вверх (т.е. со стороны отправителя). Это сообщение пришло с домашнего компьютера Дэвида Швайкерта (David Schweikert), находящегося в домене schweikert. ch, на его почтовый сервер (mail. schweikert. ch) , где оно прошло сканирование на вирусы. Затем оно было переслано получателю по адресу evi@atrust. com. Однако по- лучатель mail-relay.atrust.com послал его по адресу sailingevi@gmail.com, где находится почтовый ящик Эви. Ш Более подробная информация о технологии SPF приведена в разделе 20.6. Посреди заголовков мы видим, что проверка сообщения на основе технологии SPF завершилась неудачно. Это произошло потому, что система Google проверила IP-адрес сервера mail-relay. atrust. com, сравнила его с записью SPF в домене schweirkert. ch и они не совпали. Это недостаток технологии SPF — она не распознает сообщения, которые предназначены для пересылки. Мы можем видеть следы частого использования транспортных агентов (Postfix — в домене schweirkert. ch и sendmail 8.12 — в домене atrust. com). В данном случае сканирование вирусов было выполнено с помощью агента amavisd-new на порту 10024 на компьютере, работающем под управлением операционной системы Debian Linux. Мы можем проследить путь, который проделало сообщение из часового пояса центрально- европейского летнего времени (CEST +0200) в Колорадо (-0600) и на сервер Google (PDT -0700); эти числа представляют собой разницу между местным временем и все- мирным координированным временем (UTC — Coordinated Universal Time). В заголов- ках можно найти много скрытой информации! Рассмотрим заголовки (тоже сокращенные) сообщения, которое является спамом. Delivered-To: sailingevi@gmail.com Received: by 10.231.39.205 with SMTP id...; Mon, 19 Oct 2009 08:59:32 -0700... Received: by 10.231.5.143 with SMTP id...; Mon, 19 Oct 2009 08:59:31 -0700...
Глава 20. Электронная почта 795 Return-Path: <smotheringl39@sherman.dp.ua> Received: frommail-relay.atrust.com (mail-relay.atrust.com [63.173.189.2]) Received-SPF: neutral (google.com: 63.173.189.2 is neither permitted nor denied by best guess record for domain of smotheringl39@sherman.dp.ua) clientip= 63.173.189.2; Authentication-Results: mx.google.com; spf=neutral (google.com: 63.173.189.2 is neither permitted nor denied by best guess record for domain of smotheringl39@sherman.dp.ua) smtp.mail=smotheringl39@sherman.dp.ua Received: from SpeedTouch.Ian (187-10-167-249.dsl.telesp.net.br [187.10.167.249] (maybe forged)) bymail-relay.atrust.com... Received: from 187.10.167.249 by relay2.trifle.net; Mon, 19 Oct 2009 13:59: ... From: "alert@atrust.com" <alert@atrust.com> To: <ned@atrust.com> Subject: A new settings file for the ned@atrust.com mailbox Date: Mon, 19 Oct 2009 13:59:12 -0300 ... В соответствии с заголовком From, отправителем этого сообщения является почто- вый ящик alert@atrust.com. Однако заголовок Return-Path, содержащий копию конверта отправителя, свидетельствует о том, что источником сообщения является по- чтовый ящик smotheringl39@sherman.dp.ua, адрес которого указывает на Украину. Первый транспортный агент, обработавший сообщение, имеет IP-адрес 187.10.167.249 и находится в Бразилии. Хитрые спамеры ...5 Проверка по технологии SPF, которую выполнил сервер Google, снова завершилась провалом, но на этот раз с “нейтральным” результатом, потому что домен sherman. dp. ua не имеет записи SPF, с которой можно было бы сравнить IP-адрес сервера mail- relay .atrust.com. Информация о получателе также не совсем правдива. Заголовок То указывает, что сообщение направлено по адресу ned@atrust. com. Однако для того, чтобы сообщение было направлено по адресу sailingevi@gmail. com, среди адресов получателя на кон- верте должен находиться адрес evi@atrust. com. 20.3. Протокол SMTP Протокол SMTP (Simple Mail Transport Protocol — простой протокол передачи элек- тронной почты) и его расширенная версия ESMTP были стандартизованы в документах RFC (в частности, RFC5321) и используются для передачи сообщений между разными частями почтовой системы. • От пользовательского агента к агенту представления или транспортному агенту, когда сообщение поступает в почтовую систему. • От агента представления к транспортному агенту, когда сообщение начинает свой путь. • От транспортного агента или агента представления к программам сканирования спама и вирусов. • От одного транспортного агента к другому при передаче сообщений от одной ор- ганизации другой. • От транспортного агента к агенту доставки, когда сообщение поступает в локаль- ное хранилище. 5 Следует отметить, что многие строки заголовка, включая строки Received, могут оказаться поддельными. С этими данными необходимо быть крайне осторожными.
796 Часть II. Работа в сети Поскольку формат сообщений и протокол передачи стандартизированы, транспорт- ные агенты отправителя и получателя не обязательно должны быть одинаковыми и даже знать друг о друге; просто они оба должны придерживаться протоколов SMTP и ESMTP. На разных почтовых серверах могут работать различные транспортные агенты, и их вза- имодействие будет безошибочным. В соответствии со своим именем, протокол SMTP является довольно простым. Транспортный агент связывается с вашим почтовым сервером и, по существу, сообщает следующее: “Вот сообщение; пожалуйста, доставь его по адресу user@your .domain”. Ваш транспортный агент отвечает: “Хорошо”. Требование строго придерживаться протокола SMTP стало основой для борьбы со спамом и вредоносными программами, поэтому системные администраторы должны хорошо в нем разбираться. Его язык имеет всего несколько команд; самые важные пере- числены в табл. 20.2. Таблица 20.2. Команды протокола SMTP Команда______________f. Функции ;;____________; - -_______с_________________ helo имя_компыотера Проверяет, поддерживает ли компьютер протокол SMTP ehlo имя_компьютера Проверяет, поддерживает ли компьютер протокол ESMTP mail from: обратный_адрес Идентифицирует конверт отправителя rcpt то: прямой_адреса Идентифицирует конверт получателя vrfy адрес Проверяет корректность адреса (возможность доставки) expn адрес Демонстрирует расширение альтернативных имен и отображения файла .forward data Отмечает начало тела сообщения6 Quit Завершает сообщение и прерывает соединение RSET Восстанавливает состояние соединения HELP Выводит на экран описание команд SMTP а У сообщения может быть несколько команд RCPT. 6 Тело завершается точкой в строке. Вы прислали мне привет Серверы, использующие протокол ESMTP, начинают общение, посылая команду EHLO, а не HELO. Если процесс на другом конце соединения понимает эту команду и отвечает “ОК”, то участники согласовывают расширения и находят наименьший общий знаменатель для обмена. Если в ответ на команду EHLO собеседник присылает ошибку, то сервер, использующий протокол ESMTP, переключается на протокол SMTP. Однако в настоящее время практически все серверы используют протокол ESMTP. Типичное общение по протоколу SMTP для доставки сообщения состоит из следую- щих команд: HELO или EHLO, MAIL FROM:, RCPT TO:, DATA и QUIT. Большая часть команды выполняется отправителем. Получатель лишь высылает коды ошибок и под- тверждения. Протоколы SMTP и ESMTP основаны на тексте, поэтому их можно использовать непосредственно в процессе отладки почтовой системы. Достаточно просто применить утилиту telnet к ТСР-порту 25 или 587 и начать ввод команд SMTP. Пример приведен в разделе 20.15.
Глава 20. Электронная почта 797 Коды ошибок протокола SMTP Кроме протокола SMTP, в документах RFC определена совокупность кодов времен- ных и постоянных ошибок. Изначально эти коды состояли из трех цифр (например, 550), каждая из которых интерпретировалась отдельно. Если первая цифра равнялась 2, зна- чит, все прошло успешно, если 4 — произошла временная ошибка, а если 5 — постоян- ная ошибка. Трехзначная система кодирования ошибок слишком жесткая, поэтому в документе RFC3463 была описана ее гибкая модификация. В этом документе определен расширен- ный формат кодирования ошибок, получивший название уведомление о состоянии до- ставки, или DSN (delivery status notification). Коды DNS имеют формат Х.Х.Х, а не XXX, как раньше, причем каждый символ X может означать многозначное число. Первое чис- ло X по-прежнему может принимать значения 2, 4 и 5. Второе число означает тему, а третье кодирует подробности. В новой системе кодирования второе число используется для того, чтобы отличать ошибки компьютера от ошибок почтового ящика. Некоторые коды DSN перечислены в табл. 20.3. Все коды перечислены в приложении А к докумен- ту RFC3463. Таблица 20.3. Команды протокола SMTP Временная ошибка Постоянная ошибка Смысл , - . - 4.2.1 5.2.1 Почтовый ящик недоступен 4.2.2 5.2.2 Почтовый ящик полон 4.2.3 5.2.3 Слишком длинное сообщение 4.4.1 5.4.1 Нет ответа от компьютера 4.4.4 5.4.4 Невозможно выполнить маршрутизацию 4.5.3 5.5.3 Слишком много получателей 4.7.1 5.7.1 Доставка не авторизована, сообщение отклонено 4.7.* 5.7.* Нарушение правил организации Аутентификация SMTP Документ RFC4954 определяет расширение исходного протокола SMTP, позволяю- щее SMTP-клиенту идентифицировать себя и проходить аутентификацию у почтового сервера. После этого сервер может позволить клиенту использовать себя для пересылки почты. Этот протокол поддерживает несколько механизмов аутентификации. Обмен ин- формацией состоит из следующих этапов. • Клиент посылает команду EHLO, сообщая, что он использует протокол ESMT. • Сервер отвечает и уведомляет о своих механизмах аутентификации. • Клиент посылает команду AUTH и называет конкретный механизм аутентифика- ции, который он хочет использовать, включая свои данные для аутентификации. • Сервер принимает данные, присланные с командой AUTH, или начинает после- довательность команд “вызов/ответ” для обмена информацией с клиентом. • Сервер либо принимает, либо отвергает попытку аутентификации. Для того чтобы узнать, какой механизм аутентификации поддерживает сервер, мож- но применить утилиту telnet к порту 25 и выполнить команду EHLO. Например, ниже
798 Часть II. Работа в сети приведен усеченный вариант обмена сообщениями с почтовым сервером mail-relay, atrust. com (команды набраны полужирным шрифтом). Solaris $ telnet mail-relay.atrust.com 25 Trying 192.168.2.10... Connected to mail-relay.atrust.com. Escape character is ,Л]'. 220 mail-relay.atrust.com ESMTP ATE Mail Service 24.1.2/24.1.2; Tue, 20 Oct 2009 14:28:53 -0600 ehlo solaris.booklab.atrust.com 250-mail-relay.atrust.com Hello solaris.booklab.atrust.com, pleased to meet you 250-ENHANCEDSTATUSCODES 250-AUTH LOGIN PLAIN 250 HELP quit 221 2.0.0 mail-relay.atrust.com closing connection В данном случае почтовый сервер поддерживает механизмы аутентификации LOGIN и PLAIN. Серверы sendmail, Exim и Postfix поддерживают аутентификацию SMTP; де- тали их конфигураций описаны в разделе 20.11, 20.14 и 20.15. 20.4. Принципы организации электронной почты Соблюдение принципов работы с электронной почтой, описанных в этой главе, является обязательным условием нормального администрирования почтовых систем в средних и крупных организациях. Естественно, ими можно руководствоваться и в не- больших организациях. Есть несколько основных факторов, которые позволяют значи- тельно облегчить решение административных задач. • Наличие серверов для входящей и исходящей почты или, в случае крупных орга- низаций, иерархии серверов. • Фильтрация спама и вирусов прежде, чем разрешить доставку сообщения в вашу организацию. • Фильтрация спама, вирусов и утечки данных перед отправкой сообщений во внешний мир. • Для загруженных сайтов наличие резервного копирования, выполняемого агента- ми МТА для исходящих сообщений, не отправленных с первой попытки. • Ведение журнала и архива в соответствии с законом (например, для проведения расследований). • Наличие почтового каталога для каждого пользователя в организации. • Поддержка протоколов IMAP или POP для интеграции персональных компьюте- ров, систем Macintosh и удаленных клиентов. Каждый фактор будет подробно проанализирован ниже. Кроме того, необходимо добиться хорошего взаимодействия и функционирования других подсистем и средств: записи MX базы данных DNS должны быть правильными, брандмауэры должны пропу- скать входящую и исходящую почту, должны быть определены компьютеры, на которых организованы хранилища сообщений, и т.д. Ш Подробнее о записях MX рассказывалось в разделе 17.8.
Глава 20. Электронная почта 799 Почтовые серверы решают пять задач. • Принимают исходящую почту от агентов представления или пользовательских агентов. • Принимают входящую почту из внешнего мира. • Фильтруют сообщения от спама, вирусов и других вредоносных программ. • Доставляют сообщения в почтовые ящики пользователей. • Позволяют пользователям получать доступ к почтовым ящикам посредством про- токола ШАР или POP. В небольшой организации серверы, реализующие указанные функции, могут рабо- тать на одном компьютере. В крупных сетях это должны быть отдельные компьютеры. Настройка брандмауэра значительно упростится, если входящая почта будет поступать на один компьютер и вся исходящая почта тоже будет проходить через один компьютер. Кроме того, реалии современного Интернета вынуждают почтовые серверы заниматься сканированием содержимого сообщений. Почтовые серверы Существует два типа почтовых серверов: серверы, взаимодействующие с Интернетом для обработки входящих и исходящих сообщений, и внутренние серверы, взаимодей- ствующие с пользователями. Ниже мы опишем структуру почтовой системы, которая, как нам кажется, является легко масштабируемой, хорошо управляемой и безопасной. Задачи управления входящей и исходящей почтой в ней решают специально выделен- ные для этих целей серверы. Один из вариантов такой структуры приведен на рис. 20.2. Интернет Внутренняя сеть Рис. 20.2. Структура почтовой системы (вариант D Почтовая система, изображенная на рис. 20.2, состоит из двух частей: DMZ (демили- таризованной зоны), компьютеры которой подключены непосредственно к Интернету, и внутренней зоны, отделенной от зоны DMZ и Интернета с помощью брандмауэра. В зоне DMZ расположено несколько серверов. • Транспортный агент, прослушивающий порт 25 и передающий входящую почту на фильтры.
800 Часть IL Работа в сети • Фильтры вирусов и спама, отвергающие или отправляющие “в карантин” опасные сообщения. • Копия базы данных LDAP (Lightweight Directory Access Protocol — облегченный про- токол доступа к каталогам), содержащая исходящую информацию почтовой системы. • Исходящий транспортный агент, пытающийся доставить почту, отправленную аген- том представления. • Резервный исходящий агент МТА для исходящих сообщений, не отправленных с первой попытки. • Кеширующий сервер DNS, используемый исходящим агентом МТА для просмо- тра записей MX и входящим агентом МТА — для просмотра “черного списка” (до- менов отправителей), а также криптографической информации для подписанных сообщений. Сервер исходящей почты, который непосредственно подключен к Интернету, наи- более уязвим. Он должен быть хорошо защищен, иметь мало пользователей и не выполз нять посторонних процессов или услуг. Каждое сообщение, которое он обрабатывает, должно быть проверено, чтобы выполнялись следующие условия. ' • Организация отправителя не занесена в черный список. • Запись SPF отправителя является корректной. • Местный получатель является корректным. ч • Если сообщение подписано, можно проверить его подпись DKIM. • Сообщение не содержит вредоносных программ. • Сообщение не является спамом. Все эти задачи, связанные со сканированием сообщений, можно выполнить внутри агента МТА или с помощью отдельного пакета, например amavisd-new. Сканирование спама и вредоносных программ описывается в разделе 20.6. Сервер исходящей почты должен не менее хорошо контролироваться. Если в ор- ганизации используются большие списки рассылки, то резервный агент МТА может повысить общую производительность работы, изолировав проблему, связанную с пот лучателем, и решив ее отдельно. Мы предполагаем, что фильтрация и сканирование ис* ходящей почты выполняются агентом МТА во внутренней зоне. К серверам внутренней зоны относятся следующие агенты. • Транспортный агент внутренней маршрутизации, выполняющий маршрутизацию принятой почты в хранилище сообщений. • Исходная база данных LDAP, содержащая информацию о маршрутизации почты. • Агенты представления или транспортные агенты для исходящей почты. • Фильтры вирусов, спама и механизм предотвращения утечки данных (DLP — data leak prevention). Исходящая почта должна сканироваться на вирусы и спам, чтобы убедиться, что ло- кальные компьютеры не инфицированы, и ограничить распространение вредоносных программ среди других организаций. Если ваша организация обеспокоена вопросами утечки конфиденциальной или секретной информации (например, номеров кредитных карточек или карточек социального страхования), то фильтрация DLP должна быть вы- полнена во внутреннем агенте представления до того, как сообщение достигнет исходя- щего транспортного агента в более уязвимой зоне DMZ.
Глава 20. Электронная почта 801 Большинство современных систем фильтрации DLP встроено в коммерческие про- дукты для работы в сети веб и обработки электронной почты (например, ClearEmail, IronPort компании Cisco, WebSense, Content Control и так далее) и “раскручено” с по- мощью агрессивной рекламы. Некоторые из этих программ содержат механизмы для перекодировки номеров карточек социального страхования и кредитных карточек, а также слов и фраз, которые можно задать заранее. Сканирование DLP пока находится в первичном состоянии и имеет определенные юридические последствия. Следует убедить сотрудников и заключить с ними соглашение о том, что вы имеете право сканировать входящую и исходящую почту в поисках спама, вредоносных программ и конфиденци- альной информации. В конце пути, который проходит электронное сообщение, находятся пользователи, работающие во внутренней зоне и имеющие доступ как к хранилищу сообщений (для отправки входящей почты), так и к агенту представления (для посылки исходящей по- чты). Эти пользователи могут быть удаленными. В этом случае они должны использо- вать команду SMTP-AUTH, чтобы аутентифицировать себя. При необходимости почтовые серверы для входящих и исходящих сообщений можно реплицировать. Например, несколько серверов для входящих сообщений можно скрыть за блоком балансировки загрузки или можно использовать записи DNS WC, чтобы при- мерно сбалансировать загрузку. Разные клиентские машины могут направлять почту че- рез разные серверы исходящих сообщений. И наоборот, организации с небольшой загрузкой могут разумно сочетать серверы входящих и исходящих сообщений. Некоторые механизмы, такие как BATV или отража- тель Pen-pals, легче реализовать на одном сервере. BATV (bounce address tag valifation — проверка обратного адреса) — это схема, определяющая, истинным или поддельным является обратный адрес. Он не дает отражателю электронной почты отправлять со- общения по поддельным адресам. Pen-pals (часть утилиты amavisd-new) — это схема, уменьшающая вероятность того, что письмо является спамом, если его отправитель ра- нее уже отвечал на сообщения, посланные одним из ваших пользователей. Ш Обсуждение механизмов распределения файлов приведено в разделе 19.2. Большинство компьютеров вашей организации могут использовать минимальную конфигурацию агентов MSA/MTA, которые пересылают всю исходящую почту для об- работки на сервер с более сложными механизмами. Они не обязаны принимать почту из Интернета и могут использовать одну и ту же конфигурацию. Эту конфигурацию можно распространить с помощью команд rdist или rsync. Организации, использующие такие программы, как Microsoft Exchange или Lotus Notes, но не желающие подсоединять их непосредственно к Интернету, могут использо- вать схему, описанную выше, в которой программа Exchange играет роль маршрутизато- ра во внутренней зоне. Независимо от выбранной схемы организации почтовой системы, убедитесь, что ваша конфигурация агента МТА, зажси DNS MX и правила брандмауэра соответствуют одним и тем же правилам обработки почты.
802 Часть II. Работа в сети 20.5. Почтовые псевдонимы Псевдонимы позволяют системному администратору или отдельным пользователям переадресовывать почту6. Их можно применять для задания списков рассылки, для пере- сылки почты между компьютерами, а также для того, чтобы к пользователям можно было обращаться по нескольким именам. Псевдонимы обрабатываются рекурсивно, поэтому могут указывать на объекты, которые, в свою очередь, тоже являются псевдонимами. Системные администраторы часто используют роли или функциональные псевдони- мы (например, printers@example. com), чтобы направлять сообщения определенной темы именно тому пользователю, который ею сейчас занимается. Кроме того, псевдо- нимы используются для пересылки результатов ночного сканирования на вирусы и для указания администратора, отвечающего за электронную почту. Почтовые системы поддерживают несколько механизмов поддержки псевдонимов. • Отображения простых файлов, сгенерированных из файла /etc/mail/alias. • Различные маршрутные почтовые базы данных, связанные с конкретным транс- портным агентом. • Базы данных LDAP. • Другие коллективные механизмы, такие как протокол NIS. Ш Протокол LDAP описан в главе 19. Простые файлы, такие как /etc/mail/alises (см. ниже), — самый простой способ задать псевдоним в малых и средних организациях. Если вы хотите использовать кон- цепцию почтового дома (mail home) и обслуживаете крупную организацию со сложной структурой, мы рекомендуем реализовать почтовый дом, сохраняя псевдонимы на сер- вере LDAP Большинство пользовательских агентов в некоторой степени поддерживают концеп- цию псевдонимов (обычно называемых “моя группа”, “мои письма” или как-то еще). Однако пользовательский агент раскрывает такие псевдонимы еще до того, как почта достигнет агента представления или транспортного агента. Эти псевдонимы являются внутренними для пользовательского агента и не требуют поддержки от остальных ком- понентов почтовой системы. Псевдоним можно также определить в файле пересылки в рабочем каталоге каждого пользователя (~. forward). Эти псевдонимы, имеющие несколько необычную синтак- сическую структуру, применяются ко всей почте, поступающей конкретному пользова- телю. Они часто используются для пересылки почты по другому адресу или для реализа- ции автоответчика. Транспортные агенты ищут псевдонимы в глобальных файлах aliases (/etc/mail /address или /etc/aliases), а затем в файлах пересылки получателя. Псевдонимы применяются только к сообщениям, которые транспортный агент считает локальными. Формат записи в файле alises имеет следующий вид. локальное_имя: получатель!, получатель 2, ... Здесь локалъное_имя — оригинальный адрес, с которым будут сравниваться входящие сообщения, а список получателей содержит либо адреса получателей, либо другие псев- донимы. Строки, начинающиеся с отступа, считаются продолжением предыдущих строк. 6 По техническим причинам псевдонимы настраивает только системный администратор. Пользователи управляют маршрутизацией почты при помощи файла .forward, который в действи- тельности не имеет прямого отношения к псевдонимам, но мы использовали оба этих средства.
Глава 20. Электронная почта 803 С точки зрения почтовой системы, файл alises заменяет файл /etc/passwd, поэ- тому запись david: david@somewhere-else.edu не позволит локальному пользователю david вообще получать сообщения электронной почты. Следовательно, при выборе новых имен для пользователей администраторы и инструменты adduser должны проверять как файл passwd, так и файл aliases. Файл aliases всегда должен содержать псевдоним “postmaster”, перенаправляющий сообщение тому, кто обслуживает почтовую систему. Аналогично псевдоним “abuse” подходит для ситуаций, когда кто-то извне вашей организации хочет прислать вам спам или предпринимает подозрительные действия в вашей сети. Кроме того, в файле дол- жен присутствовать псевдоним для автоматических сообщений от транспортного агента; обычно этот агент называется Mailer-Daemon и часто имеет псевдоним “postmaster”. К сожалению, в настоящее время в почтовой системе происходит столько злоупотре- блений, что некоторые организации настраивают эти стандартные контактные адреса так, чтобы отбрасывать почту вообще, вместо ее пересылки индивидуальным пользова- телям. Записи вроде # Basic system aliases - these MUST be present mailer-daemon: postmaster postmaster: ”/dev/null” стали обычными. Мы не рекомендуем эту практику, поскольку люди, имеющие пробле- мы с пересылкой почты в вашу организацию, должны сообщить об этом пользователю postmaster. Мы рекомендуем использовать такие записи. # Basic system aliases - these MUST be present mailer-daemon: "/dev/null" postmaster: root Вы должны перенаправлять почту, поступающую на корневой сервер, системным администраторам или тому лицу, которое ведет ежедневные регистрационные записи. Учетные записи bin, sys, daemon, nobody и hostmaster (а также любые другие учетные за- писи псевдопользователей) должны иметь похожие псевдонимы. Помимо списков пользователей, псевдонимы могут ссылаться на следующие файлы и программы. • Файл, содержащий список адресов. • Файл, в который должны добавляться сообщения. • Программу, на вход которой должны передаваться сообщения. Два последних адресата должны вызывать подозрения с точки зрения безопасности, поскольку отправитель сообщения полностью определяет его содержание. Иметь воз- можность добавлять это содержание в файл или передавать его командам в качестве ар- гументов — значит подвергать систему опасности. Многие транспортные агенты либо не разрешают передавать сообщения таким адресатам, либо строго ограничивают список разрешенных команд и файлов. Псевдонимы могут создавать циклические ссылки. Транспортные агенты пытаются распознавать циклы, которые вызывают бесконечную циркуляцию сообщений от полу- чателя к отправителю и обратно, и возвращать ошибочные сообщения их отправителям. Для того чтобы распознать циклическую ссылку, транспортный агент может подсчи- тывать количество строк Received в заголовке сообщения и прекращать ретрансляцию,
804 Часть II. Работа в сети если это количество превышает установленный предел (обычно 25). Каждое посещение нового компьютера, на жаргоне электронной почты, называется “скачком” (“hop”). Возвращение сообщения его отправителю называется “рикошетом” (“bouncing”). Итак, типичное выражение на этом жаргоне может звучать следующим образом: “Письмо от- скакивает после 25 рикошетов”.7 Другой способ распознавания циклов заключается в добавлении заголовка Delivered-То для каждого компьютера, которому пересылается сообщение. Если транспортный агент обнаружит в этом заголовке адрес, который уже упоминался ранее, то он будет знать, что письмо “ходит по кругу”. Загрузка списков рассылки из файла Директива :include: в файле aliases (или пользовательском файле .forward) является прекрасным средством управления псевдонимами с помощью специального файла. Это отличное средство, позволяющее пользователям создавать свои собствен- ные списки рассылки. Этот файл управляется только пользователем и его можно менять без вмешательства системного администратора. Однако такой псевдоним легко может стать пособником при рассылке спама, поэтому не следует разрешать ретрансляцию со- общений, поступающих извне, на эти адреса. Если внешнему пользователю необходимо послать сообщение с использованием псевдонима, применяйте такие программы, как Mailman (см. ниже), чтобы сохранить систему в безопасности. Для создания такого списка рассылки с помощью директивы : include: системный администратор должен ввести псевдоним в глобальный файл aliases, а затем создать внешний файл и при помощи команды chown сделать его владельцем пользователя, управляющего списком рассылки. Например, файл aliases может содержать следую- щую строку. sa-book: :include:/usr/local/mail/ulsah.authors Файл ulsah. authors должен находиться в локальной файловой системе. Кроме то- го, запись в этот файл должна быть разрешена только его владельцу. Для полноты следу- ет также создать псевдоним, соответствующий владельцу списка рассылки, чтобы сооб- щения об ошибках (“рикошеты”) посылались владельцу, а не отправителю сообщения. owner-sa-book: evi О списках рассылки, а также об их взаимосвязи с файлом aliases пойдет речь чуть ниже. Направление почты в файл Если объект, на который ссылается псевдоним, — полное имя файла (заключенное в двойные кавычки при наличии специальных символов), то сообщения добавляются в ко- нец указанного файла. Сам файл должен существовать. Вот пример такого псевдонима. cron-status: /usr/local/admin/cron-status-messages Возможность посылать почту в файл или на вход программы очень полезна, но она ослабляет безопасность и потому должна быть ограничена. Приведенный синтаксис до- пустим только в файле aliases и пользовательском файле . forward (а также в файлах, 7 Мы не придерживались последовательной терминологии в этой главе, иногда называя воз- врат сообщения “рикошетом”, а иногда “ошибкой”. На самом деле мы имеем в виду, что в этом случае генерируется уведомление о состоянии доставки (DSN, представляющее собой сообщение, форматированное специальным образом). Такое уведомление обычно означает, что сообщение не было доставлено и, следовательно, возвращается отправителю.
Глава 20. Электронная почта 805 которые внедряются в них посредством директивы : include:). Имя файла не трактует- ся как адрес, поэтому почта, направленная по адресу /etc/passwd@host. domain, будет возвращена. Если ссылка на внешний файл содержится в файле aliases, то адресуемый файл либо должен быть полностью открыт для записи (что нежелательно), либо иметь уста- новленный бит смены идентификатора пользователя (SUID) и быть неисполняемым, либо принадлежать основному пользователю транспортного агента. Этот пользователь задается в файле конфигурации транспортного агента. Если же ссылка на файл содержится в файле . forward, то адресуемый файл дол- жен принадлежать и быть доступным для записи основному получателю сообще- ния. Необходимо, чтобы у этого пользователя была своя запись в файле /etc/passwd, а его интерпретатор команд был упомянут в файле /etc/shells. Для файлов, принадле- жащих пользователю root, следует задать режим доступа 4644 или 4600, т.е. установить бит SUID и отменить возможность выполнения. Направление почты в программу Благодаря псевдонимам можно организовать пересылку почты на вход заданной про- граммы. Это реализуется с помощью строки примерно следующего вида. autoftp: ’’|/usr/local/bin/ftpserver" Однако использование такого способа доставки почты создает еще более серьезные бреши в защите, чем направление почты в файл, поэтому данный механизм тоже раз- решен только для файлов aliases и . forward и для файлов, которые подключаются к ним посредством директивы : include:, и часто требует использования ограниченной оболочки (restricted shell). Примеры псевдонимов Ниже представлен ряд псевдонимов, которые могут понадобиться системному адми- нистратору. # Перенаправление на псевдозаписи bin: root daemon: root adm: root abuse: root junk: "/dev/null" root: ned # Псевдонимы пейджеров pigdog: :include:/usr/local/etc/pigdog tierlcoverage: :include:/usr/local/etc/tierlcoverage tier2coverage: :include:/usr/local/etc/tier2coverage # Соглашения системных администраторов diary: "/usr/local/admin/diary" info: "|/usr/local/bin/sendinfo” # Псевдонимы учебных групп, которые изменяются каждый семестр sa-class: real-sa-class@nag.cs.colorado.edu real-sa-class: :include:/usr/local/adm/sa-class.list
806 Часть II. Работа в сети Псевдоним sa-class имеет два уровня, чтобы файл данных, содержащий список сту- дентов, хранился только на одной машине. Псевдоним diary очень удобен для докумен- тирования работы этих странных системных администраторов, которые терпеть не могут документировать свои действия. Системные администраторы могут просто запоминать важные события, происшедшие с компьютером (обновление операционной системы, изменение аппаратного обеспечения, сбои и прочее), посылая сообщения в файл diary. Хешированная база данных псевдонимов Поскольку записи файла aliases не упорядочены, прямой поиск в данном файле был бы для программы sendmail неэффективным. По этой причине создается хеширо- ванная версия файла aliases. Это делается средствами системы Berkeley DB. Хеширо- вание значительно ускоряет поиск псевдонимов, особенно в больших файлах. Файлы, образованные из файла /etc/mail/aliases, называются aliases .db. При каждом изменении файла aliases хешированную базу данных следует перестраивать с помощью команды newaliases. Если команда newaliases вызывается в автоматиче- ском режиме, сохраняйте выводимые ею сообщения об ошибках, поскольку могут воз- никнуть проблемы с форматированием. Списки рассылки и программы для работы с ними Список рассылки — это гигантский псевдоним, при помощи которого копия каждо- го адресованного ему сообщения передается каждому члену списка. Некоторые списки рассылки содержат адреса тысяч получателей. Списки рассылки обычно объявляются в файле aliases, но формируются во внешнем файле. Существуют стандартные соглашения по присвоению имен, понятные транспорт- ным агентам и специальным программам ведения таких списков. Опытные пользователи тоже придерживаются их. Эти соглашения иллюстрируются следующими примерами. mylist: :include:/etc/mail/include/mylist owner-mylist: mylist-request mylist-request: evi owner-owner: postmaster В данном случае mylist — это имя списка рассылки; в файле /etc/mail/include/ mylist содержится список его членов. Сообщения о рикошетах посылаются его владель- цу (пользователю evi). Косвенная адресация “владелец—запрос—пользователь” удоб- на, так как адрес владельца (mylist-request) указывается в заголовке “Return-Path” каждого сообщения, посылаемого в список рассылки. Выражение “mylist-request” — это более подходящее содержимое заголовка, чем настоящее имя владельца. Сообщения об ошибках, возникающие при отправке писем псевдониму owner-mylist (на самом деле это пользователь evi), направляются псевдониму owner-owner. Когда используется общесистемный файл псевдонимов, необходимо ввести еще один уровень косвенной адресации, связав псевдоним mylist с адресом реальное_имя_ списка@главный_компьютер, чтобы файл, содержащий список членов, существовал только в одном месте. Программы для работы со списками рассылки Существует два пакета — Mailman и Sympa,— которые автоматизируют работу со спис- ками рассылки. Они лучшие в своем роде. Эти пакеты обычно позволяют пользователям
Глава 20. Электронная почта 807 получать информацию о списке и легко оформлять подписку или отказ от нее. Они об- легчают управление списком, а также выполняют фильтрацию спама и вирусов. Каждый пакет предоставляет возможность использования разных языков (обычных, не языков программирования). И пакет Mailman (gnu. org/sof tware/mailman), написанный на языке программи- рования Python, и пакет Sympa (sympa. org), написанный на языке программирования Perl, имеют веб-интерфейс, позволяющий пользователям оформлять подписку и отказ от нее, не прибегая к помощи менеджера списка. 20.6. Сканирование содержимого: спам И ВРЕДОНОСНЫЕ ПРОГРАММЫ В этом разделе рассматриваются общие вопросы, касающиеся борьбы со спамом и вирусами, включая использование внешнего антивирусного инструмента amavis-new. Детали, относящиеся к конкретным транспортным агентам, описываются в соответству- ющих разделах. Прежде чем приступать к сканированию содержимого писем, следует ответить на сле- дующие вопросы. • Где производить сканирование: в зоне DMZ или во внутренней сети? • Когда производить сканирование: при первом соединении или после получения сообщения? • В каком порядке производить сканирование? • Что делать с обнаруженными вирусами и спамом? Входящая корреспонденция обычно сканируется на концентраторе поступающих со- общений в зоне DMZ. В идеале ее следовало бы сканировать оперативно, чтобы вред- ные сообщения можно было отбрасывать, пока исходное соединение SMTP остается разомкнутым. Исходящую почту можно сканировать на вирусы и спам на внутреннем специальном компьютере, выполняющем маршрутизацию всех сообщений. Проверка корректности сообщения должна состоять из следующих действий. • Проверяем, соответствует ли реализация протокола SMTP, по которому работает отправитель, документации RFC. • Проверяем, существуют ли локальные получатели. • Сравниваем адрес с черным списком IP-адресов. • Проверяем репутацию. • Верифицируем подпись DKIM и запись SPF. • Фильтруем спам. • Фильтруем вирусы. Многие роботы для рассылки спама неточно следуют протоколу SMTP; они обыч- но посылают сообщение еще до того, как получат ответ EHLO. Небольшая задержка на вашем сервере может выявить эту “несдержанность”. Эту информацию можно исполь- зовать для того, чтобы либо разорвать соединение, либо увеличить рейтинг спама для полученных сообщений. Проверка существования локальных получателей имеет смысл, если при дальнейшей проверке вы не искажаете их адреса. Ранняя проверка минимизирует работу почтового
808 Часть II. Работа в сети сервера с недоставленной почтой. Кроме того, она исключает много “беспорядочного” спама. Однако она открывает доступ в ваше адресное пространство для зонда отправителя. Порядок остальных проверок, в основном, зависит от связанных с ними затрат. Быстрые и простые проверки следует выполнять до более продолжительных и сложных, чтобы в среднем некорректные сообщения отфильтровывались на как можно более ран- них стадиях. Что делать с обнаруженным некорректным сообщением? Отклонить его, выбросить в мусорную корзину, отправить в карантин, заархивировать? Если вы тестируете настрой- ки, мы рекомендуем отправлять их в карантин и архивировать. Если же система уже на- строена так, как надо, отклоняйте или выбрасывайте в корзину все письма с вирусами, а также отклоняйте или архивируйте спам в соответствии с установленными вами пра- вилами. Удаляйте заархивированный спам, срок давности которого превышает месяц; за это время пользователи смогут разобраться с письмами, которые были распознаны как спам по ошибке. Спам Спам — это жаргонное название макулатурной почты, которую также называют не- прошеной коммерческой электронной почтой (unsolicited commercial email — UCE). Она стала серьезной проблемой, потому что, несмотря на невысокий процент отвечающих, стоимость ответа в расчете на доллар высока. (Список, состоящий из 30 миллионов адресов электронной почты, стоит около 40 долл.) Если бы это не было выгодно для спамеров, то проблема не достигла бы таких масштабов. Исследования показывают, что" 95—98% всех почтовых отправлений являются спамом. Самые свежие данные на эту тему можно найти на специализированных сайтах, например spamlinks. net. Для борьбы со спамом рекомендуем использовать превентивные меры и открытые черные списки, доступные для вас. Хорошим источником таких списков является сайт*.. zen. spamhaus. org. Можно также перенаправлять входящую корреспонденцию аут-л сорсинговым компаниям по борьбе со спамом, таким как Postini (которая стала частью', компании Google) или Message Labs (которая в настоящее время является частью кок(Ц< пании Symantec). Однако это может повлечь за собой снижение производительности/: уровня конфиденциальности и безопасности. ; Посоветуйте своим пользователям просто удалять спам, который они получают. ' Многие сообщения, являющиеся спамом, содержат инструкции о том, как удалить свой адрес из списка рассылки. Если последовать этим инструкциям, спамеры могут действи- тельно удалить ваш адрес из текущего списка, но они немедленно добавят его в несколь- ко других списков с аннотацией “доставлено реальному человеку, прочитавшему это со- общение”. С этого момента ваш электронный адрес будет стоить еще дороже. Люди, продающие электронные адреса спамерам, для сбора адресов используют специальный вид атаки с помощью словаря. Начиная со списка распространенных фа- милий, сканирующие программы добавляют к ним разные инициалы в надежде обна- ружить реальный электронный адрес. Для того чтобы проверить этот адрес, программа связывается с почтовыми серверами, принадлежащими, например, пятидесяти крупней- шим интернет-провайдерам, и применяет команды VRFY, EXPN или RCPT к милли- ардам адресов. Транспортные агенты могут блокировать команды VRFY и EXPN про- токола SMTP, но не команду RCPT. Такие действия загружают ваш почтовый сервер и мешают быстро доставлять реальные почтовые сообщений. Для защиты от подобного рода атак транспортные агенты могут ограничивать количество выполнений команды RCPT, поступающих из одного источника.
Глава 20. Электронная почта 809 Подделки Подделать электронное письмо очень просто; многие пользовательские агенты по- зволяют заполнять поле адреса отправителя чем угодно. Транспортные агенты могут использовать механизм аутентификацию по протоколу SMTP между локальными сер- верами, но они не могут этого сделать в масштабе всего Интернета. Некоторые транс- портные агенты добавляют предупреждающие заголовки в исходящие локальные со- общения, которые могут быть подделаны. В электронном сообщении личность отправителя может быть фальсифицирована. Будьте очень осторожны, если в вашей организации электронные сообщения исполь- зуются в качестве средства авторизации, например, ключей от дверей, карточек доступа и денег. Вы должны предупредить об этом администраторов и полагаться на то, что они просматривают подозрительные письма, поступающие от авторитетных отправителей, и проверяют корректность сообщений. Следует быть еще более осторожным, если в сооб- щении предлагается предоставить необычной персоне непропорциональные привилегии. Конфиденциальность сообщений 03 Более подробно пакеты PGP и GPG описаны в разделе 22.10. Если вы не используете какой-либо внешний пакет для шифрования, например Pretty Good Privacy (PGP), его клон для GNU (GPG) или S/MIME, то о конфиденци- альности сообщений говорить не приходится. По умолчанию вся почта посылается не- зашифрованной. Шифрование требует специальной поддержки со стороны почтовых пользовательских агентов. Если ваши пользователи хотят сохранить свои сообщения в тайне, они должны применять собственное шифрование. Пакеты S/MIME и PGP описаны в документах RFC, причем стандартом считается S/MIME. Однако мы предпочитаем пакеты PGP и GPG; они являются более доступны- ми. Пакет PGP был разработан выдающимся криптографом Филом Циммерманом (Phil Zimmermann), которому мы доверяем. Эти стандарты образуют основу для обеспечения конфиденциальности электронной почты, аутентификации, проверки целостности сообщений и гарантии сохранения ав- торства. Однако анализ трафика по-прежнему возможен, потому что заголовки и кон- верты пересылаются открытым текстом. Фильтрация спама Проблема спама привела к борьбе между борцами со спамом, с одной стороны, и спа- мерами, с другой, причем обе стороны вооружены сложными технологиями. В настоя- щее время для текущего контроля используются следующие показатели. • “Серые” списки: временная отсрочка (форма проверки на соответствие докумен- там RFC). • SpamAssassin: эвристический инструмент для распознавания спама на основе срав- нения с образцами. • “Черные” списки: списки известных спамеров; часто на основе системы DNS. • “Белые” списки: списки разрешенных отправителей на основе системы DNS, что- бы избежать ложного распознавания спама. • Почтовые фильтры, сканирующие заголовки и тело сообщения.
810 Часть II. Работа в сети • Записи SPF и DKIM/ADSP для идентификации доменов отправителей и почтовых правил. • Системы amavisd-new и MailScanner: антивирусные и антиспамовские фильтрую- щие системы. Боле подробно эти инструменты будут рассмотрены немного позже. Когда следует фильтровать Это фундаментальный вопрос, и на него нет однозначного ответа. Основная пробле- ма заключается в том, следует ли выполнять фильтрацию одновременно с выполнением транзакции SMTP при соединении с отправителем или уже после получения сообще- ния. Эти схемы имеют как преимущества, так и недостатки. Преимущества оперативной фильтрации (до размещения в очереди почтовой системы) заключаются в следующем. • Вы можете отказаться от приема почты и не принимать на себя ответственность за ее доставку. (В некоторых странах это даже является юридическим требованием!) • Отправитель гарантированно уведомляется о причине, по которой его сообщение не могло быть доставлено. Вы не обязаны доверять отправителю сообщения; вы просто формулируете причину отказа и поручаете исходному почтовому серверу сообщить об этом отправителю. Это более аккуратный и надежный способ, чем прием почты и ее отправка обратно. Однако у схемы обработки почты после ее размещения в очереди почтовой системы тоже есть свои преимущества. • Производительность почтового сервера, имеющего выход в Интернет, не страда- ет от интенсивной проверки спама. Это особенно ценно, когда одновременно со спамом почтовый сервер загружен полезными сообщениями. • Фильтрация после размещения сообщения в очереди почтовой системы проще и надежнее. На первый взгляд, может показаться, что следует предпочесть фильтрацию после раз- мещения сообщения в очереди почтовой системы. Она не снижает производительность работы почтового сервера и легче управляется системными администраторами. Однако обратная отправка сообщения, генерируемая системой фильтрации после размещения в очереди почтовой системы, сама становится разновидностью спама, если адрес отправи- теля был подделан, как это обычно бывает при рассылке спама. Эта проблема называется “обратной рассылкой спама” (“backscatter spam”). Для борьбы с ней была изобретена система BATV (bounce address tag validation — проверка обратного адреса). Тем не менее проблема остается нерешенной. Система может опреде- лить корректность обратного адреса (адрес отправителя на конверте), если отправитель сообщения подписал адрес на конверте. Фильтры системы BATV могут помочь сайтам отправлять сообщения только по корректным обратным адресам. Разумным компромиссом было бы выполнение фильтрации вирусов и спама до раз- мещения сообщений в очереди почтовой системы, а затем выполнение дополнительного сканирования после размещения сообщений в очереди. "Серые" списки/DCC “Серые” списки — это схема, в которой почтовый сервер конфигурируется так, что- бы при установлении всех соединений с новыми, нераспознанными, IP-адресами воз-
Глава 20. Электронная почта 811 никала задержка, например, от 15 минут до часа. Сервер отказывается принимать почту, отправляя в ответ сообщение “повторите попытку позже”. Реальные транспортные аген- ты, посылающие реальную почту реальных пользователей, подождут и затем повторят попытку; роботы для рассылки спама перейдут к следующему адресу в списке и не будут повторять попытку. “Серые” списки были реализованы для компьютеров, на которых работают транс- портные агенты; подробности можно найти на сайте greylisting.org. Они особенно эффективны в качестве компонентов системы борьбы со спамом под названием DCC (Distributed Checksum Clearinghouses; см. rhyolite.com/dcc), распознающей “массо- вость” сообщения путем вычисления нечеткой контрольной суммы и проверки, сколько почтовых серверов имеют ту же самую контрольную сумму. Эта система распознает не спам как таковой, а массовые рассылки. Если вы поместите в белый список всю массо- вую рассылку, которую хотите получать (например, списки рассылки, принадлежащие вам), то остальные распознанные сообщения образуют непрошеную почту, т.е. спам. Система DCC также может работать с серыми списками; она используется как фильтр и может заносить в серые списки или отвергать письма до их постановки в очередь по- чтовой системы во время сеанса SMTP. Поскольку система DCC не выполняет сравне- ние с образцами, как инструменты типа SpamAssassin, ее невозможно обмануть, добав- ляя случайные слова в свои сообщения, как делают спамеры, пытаясь обмануть системы, сравнивающие образцы. Эффективность серых списков снизилась (с более чем 97% до 90%), когда роботы для рассылки спама восприняли их всерьез и привели в порядок свою реализацию про- токола SMTP. Однако они по-прежнему остаются эффективными, если используются в сочетании с черными списками, потому что система автоматической поддержки черных списков часто управляется сайтами, специализирующимися на борьбе со спамом, пока не истечет период для повторной попытки. Программа SpamAssassin Программа SpamAssassin (spamassassin. apache. org) — это открытый модуль на языке Perl, написанный Хабибом Диу (Habeeb Dihu) и поддержанный Яном Джастманом (Ian Justman). Он прекрасно справляется с распознаванием спама. Эту программу можно вызвать с помощью фильтра и использовать во многих системах для борьбы со спамом. Для распознавания спама программа SpamAssassin использует множество эмпири- ческих правил. Эти правила постоянно обновляются, но в настоящее время они под- держиваются все менее активно. Программа SpamAssassin перехватывает практически весь спам, но иногда принимает “ложноположительные” решения, особенно если она настроена с включенной опцией “авто-Байес”. При настройке программы SpamAssassin и выборе ее параметров внимательно изучите накопленный спам. Программа SpamAssassin использует систему подсчета баллов для оценки сообщений. Если сообщение набирает слишком много баллов, количество которых зависит как от настроек сайта, так и от пользователя, то программа SpamAssassin помечает сообщение как спам. После этого подозрительные сообщения можно отправить в папку для спама, либо запустив на сервере фильтр, например фильтр sieve фирмы Cyrus, либо соответ- ствующим образом настроив своего пользовательского агента. Программу SpamAssassin можно даже обучить распознавать хорошие и плохие сообщения (“ham” и “spam”), под- ключив байесовский фильтр.
812 Часть II. Работа в сети Черные списки Ш Более подробная информация о системе DNS приведена в главе 17. Несколько организаций (например, spamhaus.org) составляют списки спамеров и публикуют их в системе DNS. Транспортные агенты можно настроить так, чтобы они проверяли эти черные списки (известные также как Realtime Black Lists, или RBL) и от- вергали почту, приходящую с указанных адресов. Они также составляют списки открытых почтовых станций, т.е. почтовых серверов, предназначенных для пересылки сообщений из Интернета пользователю, находящему- ся вне локальной сети, без аутентификации сервера-отправителя. Спамеры используют открытые почтовые станции для маскировки источников сообщений и перепоручения рассылки огромного количества сообщений другим сайтам. Белые списки Белые списки — это репутационные списки, основанные на системе DNS, которые, по существу, являются противоположностью черных списков, описанных выше. Они ис- пользуются для сокращения количества “ложноположительных” ответов, генерируемых фильтрами спама. Один из белых списков, поддерживаемых на сайте dnswl. org, оце- нивает домены следующим образом. • Высокий рейтинг — никогда не посылает спама. • Средний рейтинг — редко посылает спам, исправляет проблемы, связанные со спамом, если они возникают. • Низкий рейтинг — иногда посылает спам, медленно исправляет проблемы. • Нет рейтинга — законный почтовый сервер, но может рассылать спам. Белые списки рекомендуют пропускать часть обычной процедуры сканирования по- чты с учетом рейтинга отправителя в белом списке. • Не искать в черном и сером списках домены, имеющие рейтинг. • Не выполнять фильтрацию спама для доменов с высоким или средним рейтингом. • Никогда не игнорировать сканирование на вирусы. Веб-сайт dnswl. org содержит подробную информацию о том, как использовать бе- лый список для каждого транспортного агента, рассмотренного в нашей книге. Анализ выполняется на основе системы DNS, как и для черных списков. Например, если вы хотите узнать рейтинг IP-адреса 1.2.3.4, должны выполнить DNS-запрос для псевдоузла 4.3.2.1. list. dnswl. org. В ответ вы получите IP-адрес в форме 127.0. х.у, где х — число, идентифицирующее общую категорию бизнеса для данного домена (например, финансовые услуги или маркетинг электронной почты), а у — рейтинг сайта в белом списке по шкале 0—3 (0 — нет, 3 — высокий). Для ускорения работы белых списков можно загрузить данные для полного белого списка и ежедневно выполнять команду rsync; каждый час или каждые полчаса это де- лать не следует. Можно также оценить рейтинг своей организации на веб-сайте dnswl. org. Ниже приводится типичный вывод для сайта caida. org, не рассылающего спам. IP range 192.172.226.32/32 Domain/Ноstname jungle.caida.org Score med
Глава 20. Электронная почта 813 IP range 192.172.226.36/32 Domain/Hostname fido.caida.org Score med IP range 192.172.226.78/32 Domain/Hostname rommie.caida.org Score med Домен hotmail. com порождает около десяти страниц, содержащих записи, которые имеют рейтинг “нет”. Фильтрация почты Разработчики программы sendmail создали прикладной интерфейс, позволяющий программам сторонних производителей фильтровать заголовки и содержимое почтовых сообщений так, будто они обрабатываются транспортным агентом. Эти почтовые фильтры используются для борьбы со спамом, распознавания виру- сов, статистического анализа, шифрования и многих других целей. Почтовые филь- тры поддерживаются как утилитой sendmail, так и транспортными агентами сервера Postfix; вместо них сервер Exim использует обычные фильтры и списки контроля досту- па. Каталог доступных почтовых фильтров, сопровождаемый рейтингами пользователей, лицензионной информацией и статистическими показателями о загрузках и обновлени- ях, находится на сайте milter. org. Транспортные агенты применяют почтовые фильтры к входящим сообщениям, пока те еще остаются на связи с сайтом-отправителем. Почтовые фильтры могут распознать профиль вируса или спама и сообщить об этом транспортному агенту, игнорировать со- общение, создать записи в журнале или предпринять другое действие, которое вы со- чтете приемлемым. Почтовые фильтры имеют доступ и к метаданным, и к содержимому сообщения. Почтовые фильтры представляют собой потенциально мощные инструменты как для борьбы со спамом и вирусами, так и с попытками нарушить конфиденциальность пере- писки. Когда менеджеры узнают, что по электронной почте из их организации проис- ходит утечка конфиденциальной информации, возникает щекотливая ситуация, потому что сотрудники полагают, будто их сообщения должны считаться приватными. В согла- шениях с сотрудниками следует четко указывать, что вы имеете право выполнять любое сканирование их электронных сообщений. Технология SPF и спецификации Sender ID Лучший способ борьбы со спамом — остановить работу его источника. Это звучит легко и просто, но в реальной жизни это практически невозможно сделать. Структура Интернета затрудняет отслеживание реального источника сообщения и проверку его ау- тентичности. Обществу необходим надежный способ верификации отправителя и его намерений. Для решения этой проблемы было сделано много предложений, но технология SPF и спецификации Sender ID оказались наиболее удачными. Технология SPF (Sender Policy Framework — инфраструктура политики отправителей) описана организацией IETF в документе RFC4408. Протокол SPF определяет набор DNS-записей (см. раздел 17.8), с помощью которых организация может указать свои официальные почтовые серверы для исходящей корреспонденции. Транспортные агенты могут отвергать сообщения, исходящие из домена организации, если они не отправлены из указанных источников.
814 Часть II. Работа в сети Разумеется, эта система работает хорошо только в том случае, когда большинство орга- низаций публикует записи SPF. Для проверки записей SPF разработано несколько по- чтовых фильтров. Спецификации Sender ID и технология SPF практически идентичны по форме и функ- циям. Однако ключевые части технологии Sender ID запатентованы компанией Microsoft, следовательно, являются предметом полемики. В момент написания книги компания Microsoft все еще пыталась склонить индустрию к принятию своих запатентованных стандартов. Организация IETF решила не делать однозначный выбор и опубликовала документы RFC4406 (о спецификациях Sender ID) и RFC4408 (о технологии SPF). Обе технологии названы экспериментальными, так что рынок сам должен решить, какая из них будет выбрана в качестве стандартной. Отложенные сообщения не соответствуют ни спецификациям Sender ID, ни про- токолу SPF, что является серьезным недостатком обеих систем. Получатель проверяет запись SPF об оригинальном отправителе, чтобы открыть его список авторизованных серверов. Однако эти адреса не соответствуют компьютерам, выполняющим задержку писем и задействованным в транспортировке данного сообщения. Следует быть осто- рожным, принимая решения на основе отказов системы SPF. Системы DomainKeys, DKIM и ADSP Ш Более подробно технология DKIM описана в главе 17. DKIM (DomainKeys Identified Mail — почта, идентифицированная доменными клю- чами) — это система криптографических подписей для сообщений электронной почты. Она позволяет получателю верифицировать не только личность отправителя, но и тот факт, что сообщение не было подделано по пути. Система использует DNS-записи для публикации доменных криптографических ключей и правил подписи сообщений. Оригинальная система DomainKeys, предшественница системы DKIM, обладавшая аналогичными функциональными возможностями, продвигалась компанией Yahoo!. Она по-прежнему используется. Системы DKIM и DomainKeys не конфликтуют, и ор- ганизации могут верифицировать подписи обоих типов. И все же для подписи новых сообщений лучше использовать систему DKIM. Записи ADSP DNS (Author Domain Signing Practice) позволяют отправителю объяв- лять свои правила подписи для каждого поддомена. Например, банк может объявить, что он подписывает всю почту, исходящую с сервера transactions .mybank. com. Лю- бой адресат, получивший неподписанную почту (или почту, подпись на которой не была верифицирована), которая утверждает, что отправлена с указанного домена, должен либо отвергнуть ее, либо отправить в карантин. Однако сайт marketing.mybank.com может вообще не подписывать свои сообщения. Некоторое время система ADSP называлась SSP (sender signing policy — политика подписи отправителя), так что ее можно было рассматривать как разновидность об- работки записей DNS ТХТ. Технология DKIM поддерживалась всеми транспортными агентами, описанными в этой главе, но ее развертывание в реальном мире по неизвест- ным причинам оказалось медленным. Даже если вы не хотите отвергать сообщения на основе верификации по технологи- ям DKIM или SPF, все еще можете использовать информацию, повышающую рейтинг спама, или изменять свою реакцию в соответствии с репутацией отправителя.
Глава 20. Электронная почта 815 Функциональные возможности транспортных агентов по борьбе со спамом Каждый транспортный агент имеет настройки конфигурации, которые облегчают борьбу со спамом. Например, некоторые транспортные агенты могут распознать, что их просят выполнить миллиарды операций RCPT, и ввести 15-секундную задержку между выполнением команд RCPT для соединений, которые требуют их выполнить. Мы рассмотрим настройки конфигурации, предназначенные для борьбы со спа- мом, вместе с остальными настройками транспортных агентов. Для утилиты sendmail см. раздел 20.8, для сервера Exim — раздел 20.13, а для сервера Postfix — раздел 20.15. Технологии DKIM и ADSP более подробно обсуждаются в разделах 20.16 и 17.8. Программа Mailscanner Эта программа (mailscanner. info), написанная Джулианом Филдом (Julian Field), представляет собой активно используемый, гибкий и открытый сканер концентраторов почты, который распознает спам, вирусы и попытки фишинга. Он написан на языке Perl и использует внешние антивирусные программы (в частности, ClamAV и 25 других инструментов), а также программное обеспечение для борьбы со спамом (SpamAssassin). Его компонент ScamNailer (scamnailer. info), предназначенный для предотвращения фишинга, является независимым и может использоваться самостоятельно. Системный администратор может настроить конфигурацию программы MailScanner на уровне пользователей, доменов и IP-адресов. Программа MailScanner — это не почтовый фильтр, а самостоятельная программа, ра- ботающая с очередями сообщений, принадлежащих транспортным агентам. Например, можно конфигурировать транспортный агент в своей зоне DMZ, чтобы принимать со- общения (после их проверки с помощью почтовых фильтров, черных списков и так да- лее, но до размещения в очереди), а затем размещать их в очереди входящих сообщений. Программа MailScanner считывает сообщения из очереди, проверяет их на спам, вирусы и фишинг, а затем передает в отдельную очередь исходящих сообщений. Другой экзем- пляр транспортного агента может обработать очередь входящих сообщений и доставить их адресату. Недостатком этой системы является тот факт, что почта, отвергнутая программой MailScanner, создает рикошет сообщений и, следовательно, может порождать обратную рассылку спама. Несмотря на то что программа MailScanner является свободной распространяемой, существует ее коммерческая версия. Кроме того, она поддерживает список рассылки для активных пользователей и выделенный канал IRC, который отслеживается круглосуточ- но. Она хорошо документирована как в Интернете, так и в книге MailScanner: A User Guide and Training Manual, написанной Джулианом Филдом. Файл конфигурации про- граммы MailScanner содержит так много комментариев, что примитивы конфигурации трудно распознать; если вы эксперт, то, возможно, захотите удалить некоторые из этих формулировок. Статистические показатели, определяемые программой MailScanner, можно получить от веб-интерфейса Mail-Watch. Графическое изображение данных можно создать с по- мощью программного обеспечения MRTG (рис. 20.3). Обратите внимание на огром- ный пик, возникший 19 сентября. Вероятно, в этот день имела место атака определен- ного типа.
816 Часть II. Работа в сети Total Mail Processed by Date □ Volume (Gb) El Mail □ Spam Puc. 20.3. График почтового трафика, созданный с помощью программы MRTG Интерфейс amavisd-new Программа amavisd-new — это интерфейс между транспортными агентами и скане- рами спама, такими как ClamAV и SpamAssassin. Изначально он был основан на сканере AMaViS (A Mail Virus Scanner), но в настоящее время имеет с оригиналом мало обще* го. Он написан на языке Perl Марком Мартинесом (Mark Martinec); веб-сайт: i j s. si/ software/amavisd. Следуя соглашениям с организациями, поддерживающими эту про* грамму, мы называем весь пакет (полужирным шрифтом) amavisd-new, хотя сам демон называется amavisd. * Программа amavisd-new взаимодействует с транспортным агентом через локальный ; домен или сокет TCP. Она может фильтровать письма либо до их размещения в очереди (с помощью почтового фильтра, до того как транспортный агент получит сообщение), либо после приема сообщения, но до доставки его получателю. Зачем нужна еще одна программа, если транспортный агент и так выполняет ска* нирование с помощью почтовых фильтров и аналогичных инструментов? Ответ заклюй чается в том, что конфигурацию всех фильтров удобно хранить в одном месте. Кроме ' того, если весь процесс фильтрации координируется одним интерфейсом, то легче от- ражать новую атаку или включать в линию обороны новый инструмент. Другое преиму- щество заключается в том, что сканер может работать на отдельном компьютере и тем самым облегчать работу по приему и обработке сообщений на загруженном сервере, ‘ Компромиссом является следующая схема: простые и быстрые проверки выполнять , с омощью транспортного агента, а более сложные и продолжительные — с помощью инструмента типа amavisd. Программа amavisd может взаимодействовать со многими пакетами, предназначен- ными для борьбы со спамом и вирусами. Это довольно мощный инструмент, хотя и об- ладает некоторыми недостатками. • Документация немного разбросана, и не очень понятно, что является современ- ным вариантом, а что устаревшим и не действующим. • Сложная конфигурация; содержит множество параметров и их слабо различимых вариантов.
Глава 20. Электронная почта 817 Как работает программа amavisd Программа amavisd занимает промежуточное место между транспортными аген- тами, хранящими сообщение, подлежащее проверке, и программным обеспечением, которое будет выполнять эту проверку. Программа amavisd прослушивает соединения с транспортным агентом на порту 10 024, отдает протоколам SMTP или LMTP приказ принять сообщения и возвращает ответы транспортному агенту на порту 10 025. Кроме того, если она и транспортный агент выполняются на одном и том же компьютере, эта программа использует сокет в локальном домене. Если программа amavisd передает отсканированное сообщение и результат скани- рования обратно транспортному агенту, от которого она получила данное сообщение, то можно выполнить фильтрацию до размещения сообщения в очереди и отвергнуть его во время первоначального сеанса SMTP, выполняемого транспортным агентом. Если же вместо этого программа amavisd размещает сообщения в очереди внутреннего концен- тратора почты, то фильтрация производится автономно и сообщения могут быть отвер- гнуты или отправлены обратно. CQ Информация о протоколе SNMP приведена в главе 21. Пакет amavisd старается не потерять сообщения и не пропустить их без проверки, учитывает пожелания получателей и следует стандартам, описанным в разных докумен- тах RFC, посвященных электронной почте. Несмотря на то что программа amavisd на- писана на языке Perl, ее производительность довольно высока. Она сканирует каждое сообщение только один раз, независимо от того, сколько получателей с ним связано. Процесс сканирования выполняется довольно интенсивно, инструменты, входящие в дистрибутивный набор, могут отслеживать процесс фильтрации с помощью протокола SNMP. Программу amavisd не обязательно запускать как корневую; у нее хорошая ре- путация в области безопасности. Инсталляция пакета amavisd Загрузите самую свежую версию программы с сайта Download the latest ijs. si/software/amavisd или выполните команду grab в пакете Linux и пройдите эта- пы, описанные в файле INSTALL, расположенном на вершине иерархии дистрибутива. Домашняя страница проекта имеет ссылки на заранее скомпилированные пакеты. Программа amavisd должна запускаться как пользователь и группа vscan или amavis, поэтому проще всего создать этого пользователя и группу, а затем зарегистрироваться как vscan, чтобы получить программное обеспечение и инсталлировать его. Если после инсталляции программа amavisd работает правильно, измените регистрационное имя на /bin/false или на имя другой ограниченной оболочки. Файл amavisd. conf-default содержит список всех возможных параметров конфи- гурации и их значения, заданные по умолчанию. Файл amavisd. conf-sample содержит типичный пример конфигурации. Кроме того, файл amavisd. conf представляет собой минимальную стартовую площадку (хотя и содержит более 750 строк!) с комментариями к некоторым переменным, которые необходимо изменить. Языком конфигурации явля- ется Perl. Базовая конфигурация пакета amavisd Рассмотрим базовую конфигурацию пакета amavisd для узла mail. example. com, где транспортный агент и пакет amavisd выполняются на одном и том же компьютере, а Для взаимодействия используют протоколы TCP и SMTP.
818 Часть II. Работа в сети use strict; $myhostname = 'mail.example.com.'; @local_domains_maps = ([’.example.com']); @mynetworks = qw(127.О.0.0/8 192.168.0.0/16); $forward_method = 'smtp:[127.0.0.1]:10025'; $enable_db =1; $enable_global_cache = 1; $max_servers = 5; $D0_SYSLOG = 1; $SYSLOG_LEVEL = "mail.info"; $bypass_decode_parts = 1; $final_viruS—destiny = D_REJECT; $final_banned—destiny = D_REJECT; $final—bad—header_destiny = D_PASS; $log_recip_tempi = undef; @av_scanners = ( ['ClamAV-clamd', &ask_daemon, ["CONTSCAN {}n", "/var/run/clamav/clamd"], qr/bOK$/m, qr/bF0UND$/m, qr/A.*?: (?!Infected Archive) (.*) F0UND$/m ], ); 1; В массиве стандартных конфигураций av scanners перечислены более 40 про- грамм для борьбы со спамом и вирусами; в этом фрагменте показана только программа ClamAV. Выражение 1; в конце файла является специфичным для языка Perl. Оно га- рантирует, что сам файл в любом контексте языка Perl при попытке чтения будет интер- претироваться как истинный. Инструменты amavisd-new Дистрибутивный пакет amavisd-new содержит два полезных инструмента: amavisd- nanny и amavisd-agent. Инструмент amavisd-nanny следит за состоянием пакета amavisd, а программа amavisd-agent обеспечивает доступ в реальном времени к счет- чикам и шкалам, похожим на те, которые используются в протоколе SNMP. Обе про- граммы требуют наличия библиотеки Berkeley DB library. Программа amavisd-nanny демонстрирует состояние всех процессов пакета amavisd, какие сообщения они в данный момент обрабатывают, что именно делают и как долго будут выполняться. Запустив эту программу с флагом -h, можно увидеть со- общение о ее использовании и список состояний, в которых может находиться пакет amavisd. Рассмотрим наиболее интересные состояния: S — фильтрация спама, V — ска- нирование вирусов и точка — простой. Буква, обозначающая состояние, выводится на экран ежесекундно вместе с двоеточием после каждых десяти букв, чтобы их легче было считать. Программу amavisd-nanny следует запускать иногда, просто чтобы увидеть, как система работает. Рассмотрим пример. $ sudo amavisd-nanny process-id task-id elapsed in elapsed-bar (dots indicate idle) or state idle or busy PID 01422: 0:09:51 .........:.........:.........:..... PID 26784: 26784-18 0:00:01
Глава 20. Электронная почта 819 PID 01422: 0:09:53 ........:.........:..........:..... PID 26784: 0:00:03 Программа amavisd-agent — это агент, похожий на агентов в протоколе SNMP, который собирает статистические данные от всех выполняющихся демонов и может выводить такую информацию, как количество обработанных сообщений, время обра- ботки каждого сообщения, доля содержащихся вирусов, наиболее распространенные вирусы и т.д. Приведем усеченный пример. $ sudo amavisd-agent entropy STR ipwvEIo5VA sysContact STR sysDescr STR amavisd-new-2.6.1 (20080629) sysLocation STR sysObjectID OID 1.3.6.1.4.1.15312.2.1 sysServices INT 64 sysUpTime Timeticks 111090596 (12 days, 20:35:05.96) ContentVirusMsgs 1274 InMsgs 247458 InMsgsRecips 297574 InMsgsSize ' 28728MB TimeElapsedTotal 62518s virus.byname.W32/MyDoom-N 9 virus.byname.Troj/BredoZp-H 8 3/h 0.5% (InMsgs)... 515/h 100.0% (InMsgs)... 619/h 120.3% (InMsgs)... 60MB/h 100.0% (InMsgsSize)... 0.253s/msg (InMsgs)... 0/h 15.5% (ContentVirusM... 0/h 13.8% (ContentVirusM... Первый столбец чисел — это количество элементов, за ним следует вычисленный уровень и доля по отношению к основному значению, выраженная в процентах. В данном случае почтовый сервер обработал 247 458 сообщений за 12 дней со сред- ним уровнем 1,2 получателей на сообщение (показатель InMsgsRecips равен 120,3% входящих сообщений (InMsgs)). Сервер обнаружил 1274 вируса, которые составили око- ло 0,5% всего почтового трафика. Сканеры в среднем потребовали 0,253 секунды на об- работку одного почтового сообщения. Наиболее часто встречающимися вирусами были MyDoom-N и BredoZp-H. Проверка эффективности сканирования с помощью транспортных агентов Проверяя, правильно ли ваши транспортные агенты идентифицируют вирусы и дру- гое вредоносное программное обеспечение, вы должны использовать реальные инфици- рованные сообщения, чтобы убедиться, что ваши меры оказались эффективными. Это не следует делать в промышленном окружении, где события могут выйти из-под кон- троля. Организуйте безопасную, физически отдельную тестовую лабораторию, не соеди- ненную с промышленной сетью. Исследователи антивирусных программ скомпилировали небольшой тестовый файл и предоставили его организации EICAR (European Expert Group for IT-Security (eicar. org/anti_virus_test_file .htm)) для распространения. На самом деле это не ви- рус, о последовательность байтов, которую антивирусные программы добавляют в свои базы данных как вирус (обычно под описательным именем, например, EICAR-AV-Test). Тестовый файл можно свободно пересылать по электронной почте, распространять сре- ди коллег и воспроизводить, не беспокоясь о вирусной опасности. Группа EICAR пре- доставляет несколько вариантов этого файла, так что его можно даже протестировать в архивах, например ZIP.
820 Часть II. Работа в сети Текст GTUBE, обобщенный текст для массива непрошеной почты, похож на преды- дущий файл, но предназначен для тестирования фильтров спама. Он доступен на сайте spamassassin.apache.org/gtube. Если вы тестируете и отлаживаете свой транспортный агент с помощью протокола SMTP, проверьте инструмент SWAKS (SWiss Army Knife SMTP, jetmore.org/john/ code/#swaks), разработанный Джоном Джетмором (John Jetmore). Он написан на язы- ке Perl и позволяет легко тестировать обмен сообщениями по протоколу SMTP с аргу- ментами в командной строке. Документацию можно найти на справочной странице или выполнив команду swaks —help. Для аутентификации по протоколу SMTP этот ин- струмент требует наличия библиотек libnet-ssleay-perl и libnet-dns-perl. Это не высшая математика, но все же быстрее, чем набирать команды SMTP вручную. 20.7. Конфигурация электронной почты Ядром системы электронной почты является ее транспортный агент. Программа sendmail сначала была транспортным почтовым агентом системы UNIX, написан- ной много лет тому назад выпускником университета Беркли (UC Berkeley) Эриком Аллманом (Eric Allman). С тех пор были разработаны другие транспортные агенты. Одни из них являются коммерческими продуктами, а другие — программами с открытым ко- дом. В этой главе мы рассмотрим три почтовых транспортных агента с открытым ко- дом: sendmail, Postfix, написанный Витцем Венема (Wietse Venema) из компании IBM Research, и Exim, написанный Филипом Хазелем (Philip Hazel) из Кембриджского уни- верситета. После высокоуровневого проектирования почтовой системы, ее настройка является второй по важности заботой системного администратора. К счастью, образцы конфигу- рации или примеры настроек, поставляемые вместе с транспортными агентами, часто оказываются очень близкими к тому, что требуется для среднестатистического сайта. Конфигурацию транспортного агента не следует начинать с нуля. Сайт SecuritySpace (securityspace. com) ежемесячно проводит исследования, что- бы определить рыночную долю разных транспортных агентов. В отчете за декабрь 2009 года было указано, что ответы получены от 1,7 миллионов из 2 миллионов опрошенных транспортных агентов и 950 000 из них были идентифицированы. Результаты этого ис- следования приведены в табл. 20.4 наряду с результатами исследований, проведенных в 2007 году, и некоторыми значениями, полученными в 2001 году. Таблица 20.4. Рыночная доля почтовых транспортных агентов Рыночная доля, % 2007 , 2001 Exim exim.org 30 20 8 Postfix postfix.org 20 15 2 MS Exchange microsoft.com/exchange 20 22 4 sendmail sendmail.org 19 29 60 Другие — <3% <3% <3% Очевиден переход лидерства от программы sendmail к пакетам Exim и Postfix, в то время как компания Microsoft сначала достигла лидерства на рынке транспортных аген- тов, а потом уступила его. Среди остальных операционных систем все варианты системы
Глава 20. Электронная почта 821 UNIX поставляются вместе с программой sendmail. Система Ubuntu перешла от пакета Postfix к пакету Exim, SUSE поставляется с пакетом Postfix, a Red Hat включает все три варианта, но по умолчанию устанавливает программу sendmail. Для каждого из упомянутых транспортных агентов мы приводим детали конфигура- ции, необходимой для выполнения их функций, включая следующие. • Конфигурация простых клиентов. • Конфигурация почтового сервера, имеющего выход в Интернет. • Управление маршрутизацией входящей и исходящей корреспонденции. • Штемпелевание почты, поступающей от центрального сервера или самого домена. • Безопасность. • Отладка. Если вы реализуете почтовую систему с нуля и не придерживаетесь заранее установ- ленных правил или предпочтений, вам может быть трудно выбрать транспортный агент. Программа sendmail и пакет Exim определенно являются самыми сложными и, веро- ятно, допускают самую точную настройку и самые мощные опции. Пакет Postfix проще, быстрее и основной целью считает безопасность. Если ваша организация или системные администраторы ранее работали с какими-то транспортными агентами, они, вероятно, не захотят переключаться на что-то другое, если необходимые вам функциональные воз- можности не реализованы в старых агентах. Конфигурация агента sendmail описывается в следующем разделе. Конфигурации пакета Exim описаны в разделе 20.14, а конфигурация пакета Postfix — в разделе 20.15. 20.8. Почтовый АГЕНТ SENDMAIL Почтовый агент sendmail распространяется в виде открытого кода и доступен на сайте sendmail .org, но в настоящее время его редко приходится собирать с само- го начала. При желании можно сослаться на файл верхнего уровня INSTALL. Если не- обходимо обойти определенные установки, сделанные по умолчанию, то можно найти их в файле devtools/OS/uAW-e^wew-05. Можно также добавить новые функциональ- ные свойства, отредактировав файл devtools/Site/site.config.m4. Программа sendmail использует препроцессор макросов т4 не только во время компиляции, но и для конфигурирования. Файл конфигурации т4 обычно называется имя_компыотера. тс. Он компилируется из довольно понятного синтаксиса в совершенно невразумитель- ный низкоуровневый язык и записывается в файл имя_компьютера. cf, который в свою очередь инсталлируется как /etc/mail/sendmail. cf. Для того чтобы увидеть версию программы sendmail, инсталлированной на вашем компьютере, а также узнать, как она скомпилировалась, попытайтесь выполнить сле- дующую команду. linux$ /usr/sbin/sendmail -dO.l -bt < /dev/null Version 8.13.8 Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB USE_LDAP_INIT ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = ross (canonical domain name) $j = ross.atrust.com
I 822 Часть ll. Работа в сети (subdomain name) $m = atrust.com (node name) $k = ross.atrust.com Эта команда переводит программу sendmail в режимы проверки адреса (-bt) и отладки (-dO.l), но не вводит никакого адреса для тестирования (</dev/null). Побочный эффект заключается в том, что программа sendmail сообщает номер своей версии и флаги компилятора, с которыми она компилировалась. Зная номер версии, вы можете зайти на веб-сайт sendmail. org и увидеть, существуют ли у этой версии про- граммы скрытые недостатки. Для того чтобы найти файлы программы sendmail в своей системе, посмотрите в начало инсталлированного файла /etc/mail/sendmail.cf. Комментарии, которые там находятся, содержат имя каталога, в котором была собрана данная конфигурация. Этот каталог, в свою очередь, приведет вас к файлу .тс, являющемуся исходным источ- ником конфигурации. Большинство поставщиков программы sendmail включают в дистрибутивный пакет не только исполняемый модуль, но и каталог cf из дистрибутивного дерева, который они скрывают среди файлов операционной системы. Найти его поможет табл. 20.5. Таблица 20.5. Местоположение каталога конфигурации программы sendmail Система Ubuntu SUSE Red Hat Solaris HP-UX AIX /изг/share/sendmai1 /usr/share/sendmail /usr/share/sendmail-cf /etc/mail/cf /usr/newconfig/etc/mail/cf /usr/samples/tcpip/sendmail/cf Файл переключения Ш Переключение служб более подробно описано в главе 19. В большинстве систем существует конфигурационный файл “переключения служб” /etc/nsswitch.conf, в котором перечисляются методы, удовлетворяющие разным* стандартным запросам, например запросам поиска пользователя и компьютера. Если для данного типа запросов в файле указано несколько методов распознавания, то файл переключения служб также определит порядок, в котором будут проверяться эти мето- ды. Существование переключения служб в программном обеспечении обычно не скры- вается. Однако программа sendmail осуществляет очень плотный контроль над своими процедурами поиска, поэтому в настоящее время она игнорирует системный файл пере- ключения служб и использует свой собственный внутренний файл конфигурации служб (/etc/mail/service. switch). На почтовую систему оказывают влияние два поля в файле переключения служб: aliases и hosts. Поле hosts может иметь значения dns, nis, nisplus и files, а поле aliases — files, nis, nisplus и Idap. Вспомогательные файлы для механиз- мов, которые вы используете (за исключением files), должны быть скомпилированы в программе sendmail до того, как данная служба будет использована.
Глава 20. Электронная почта 823 Запуск программы sendmail Программа sendmail не должна контролироваться демонами inetd или xinetd, поэтому ее необходимо явно запускать во время загрузки. Подробности этой процеду- ры описаны в главе 3. Функционирование программы sendmail определяется флага- ми, с которыми она запускается. Программу sendmail можно запускать в нескольких режимах, выбранных с помощью флага -Ь, который означает слово “be” (“быть”) или “become” (“становиться”) и всегда используется в сочетании с другим флагом, опреде- ляющим роль программы sendmail. Допустимые значения флага -Ь и флага -А, кото- рый производит выбор между агентами МТА и MSA, приведены в табл. 20.6. Таблица 20.6. Флаги командной строки для основных режимов работы программы sendmail Флаг > Описание ; ' -Ас Использует файл конфигурации submit. cf и действует как агент доставки -Ат Использует файл конфигурации sendmail. cf и действует как транспортный агент -Ьа Функционирует в режиме ARPANET (ожидает управляющих символов CR/LF в конце строки) - bd Функционирует в режиме демона и прослушивает соединения на порту 25 - bD Функционирует в режиме демона, но явно, а не в фоновом режимеа - bh Просматривает информацию о последнем соединении (аналогично команде hoststat) - ьн Стирает с диска копию информации об устаревших соединениях (аналогично команде purgestat) - Ы Инициализирует хешированные псевдонимы (аналогично команде newaliases) - bm Функционирует как почтальон, доставляет почту как обычно (по умолчанию) - Ьр Выводит на печать очередь почтовых сообщений (аналогично команде mailq) "ЬР Выводит на печать количество записей в очередях, расположенных в совместно используе- мой памяти Ь s Устанавливает режим сервера SMTP (для стандартного входа, но не для порта 25) “bt Устанавливает режим проверки адреса ~bv Только проверяет почтовые адреса; не посылает почту а Этот режим используется для отладки, чтобы увидеть сообщения об ошибках. Если вы конфигурируете сервер, который будет принимать почту из Интернета, запу- стите программу sendmail в режиме демона (-bd). В этом режиме программа sendmail прослушивает сетевой порт 25 и ожидает задания.8 Обычно, кроме него, устанавливается флаг -q, задающий интервал времени, в течение которого программа sendmail обраба- тывает почтовую очередь. Например, флаг -q30m заставляет программу проверять оче- редь каждые 30 минут, a -qlh — каждый час. Программа sendmail обычно пытается доставить сообщение немедленно, сохраняя его в очереди только на короткий промежуток времени, чтобы гарантировать надежность работы. Однако если ваш узел перегружен или адресат недоступен, программа sendmail размещает сообщение в очереди и пытается послать его снова. Программа sendmail ис- пользует персистентные обработчики очереди (queue runners), которые обычно запуска- ются во время загрузки. Она выполняет блокировку, поэтому параллельное выполнение нескольких обработчиков очереди вполне безопасно. Функциональная возможность 8 Порты, которые прослушивает программа sendmail, определяются параметром daemon_ options: порт 25 задается по умолчанию.
824 Часть II. Работа в сети “группы очередей” позволяет работать со списками рассылки и очередями. Более под- робно она описывается в разделе 20.12. Программа sendmail считывает Свой конфигурационный файл sendmail. cf только в момент запуска. Следовательно, если вы изменили конфигурационный файл, то долж- ны либо прекратить выполнение и запустить программу sendmail заново, либо послать сигнал HUP. Программа sendmail создает файл sendmail .pid, содержащий иденти- фикатор процесса и команду его запуска. Вы должны запустить программу sendmail, используя полностью определенный путь, потому что она, получив сигнал HUP, при- меняет сама к себе команду ехес. Файл sendmail .pid позволяет процессу принимать сигнал HUP с помощью следующей следующей команды. $ sudo kill -HUP head -1 sendmail.pid Местоположение файла PID зависит от операционной системы. Обычно он находит- ся по адресу /var/run/sendmail .pid или /etc/mail/sendmail .pid, но его можно задать в конфигурационном файле с помощью параметра conf PID FILE. define(confPID_FILE, '/var/run/sendmail.pid') Почтовые очереди Программа sendmail использует, по крайней мере, две очереди: /var/spool/ mqueue, когда она функционирует как транспортный агент на порту 25, и /var/spool/ clientmqueue, когда она функционирует как агент доставки на порту 587.9 Все сообще- ния, по крайней мере, на короткое время оказываются в очереди, прежде чем отпра- виться в дальнейший путь. Сообщения, находящиеся в очереди, сохраняются в виде фрагментов в разных фай- лах. Каждое имя файла имеет двухбуквенный префикс, идентифицирующий фрагмент, за ним следует случайный идентификатор, построенный на основе идентификатора про- цесса в программе sendmail. Шесть возможных фрагментов приведены в табл. 20.7. Таблица 20.7. Префиксы для файлов из очереди ----‘'i'1' .........................> ...........; qf Заголовок сообщения и управляющий файл df Тело сообщения tf Временная версия файла df в момент его обновления Tf Информация о том, что было выполнено более 32 неудачных попыток блокировки Qf Информация о том, что сообщение было отправлено обратно и не может быть восстановлено xf Временный файл транскрипции сообщений об ошибках, поступивших от программы для рас- сылки писем Если подкаталоги qf, df и xf в каталоге очереди уже существуют, то эти фрагменты сообщения помещаются в соответствующий подкаталог. Файл qf содержит не только за- головок сообщения, но и адреса, указанные на конверте, дату, при наступлении которой сообщение следует вернуть как недоставленное, приоритет сообщения в очереди и при- чину, по которой сообщение оказалось в очереди. Каждая строка начинается с однобук- венного кода, идентифицирующего остальную часть строки. 9 Для повышения производительности работы программа sendmail может использовать не- сколько очередей в каталоге mqueue; см. раздел 20.12.
Глава 20. Электронная почта 825 Каждое сообщение, помещенное в очередь, должно иметь файлы qf и df. Все осталь- ные префиксы программа sendmail использует, пытаясь доставить сообщение. Если компьютер дает сбой и перезагружается, то последовательность загрузочных комавд для программы sendmail должна удалить файлы tf, xf и Tf из всех очередей. Системный администратор, ответственный за почту, должен иногда проверять файлы Qf, если ло- кальная конфигурация вызывает рикошет. Эпизодическая проверка каталогов очереди позволит исправить проблемы до того, как произойдет катастрофа. Почтовая очередь создает несколько предпосылок для неприятностей. Например, файловая система может переполниться (избегайте размещения каталогов /var/spool/ mqueue и /var/log в одном и том же разделе диска), очередь может “засориться”, а беспризорные почтовые сообщения могут “застрять” в очереди. В конфигурации про- граммы sendmail есть параметры, обеспечивающие высокую производительность на очень загруженных компьютерах; рассмотрим их в разделе 20.12. 20.9. Конфигурация программы sendmail Действия программы sendmail определяются одним конфигурационным файлом, который обычно называется /etc/mail/sendmail. cf, если программа sendmail запу- скается как транспортный почтовый агент, или /etc/mail/submit.cf, если програм- ма sendmail действует как агент доставки. Флаги, с которыми запускается программа sendmail, определяют, какой файл конфигурации используется: флаги -bm, -bs и -bt означают использование файла submit. cf, если он существует, а все другие режимы ис- пользуют файл sendmail. cf. Эти имена можно изменить с помощью флагов в команд- ной строке или параметров конфигурационного файла, но лучше этого не делать. Формат конфигурационного файла был разработан для того, чтобы облегчить его разбор с помощью компьютера, а не человека. Исходный файл препроцессора m4 (с рас- ширением .тс), который порождает файл с расширением .cf, является усовершен- ствованием, но его капризный и строгий синтаксис очень неудобен. К счастью, многие парадигмы, которые вы, возможно, захотите использовать, уже были предусмотрены и реализованы в дистрибутивном пакете в качестве готовых решений. Настройка конфигурации программы sendmail состоит из нескольких этапов. • Выбор роли для компьютера, который вы конфигурируете: клиент, сервер, получа- тель почты через Интернет и т.д. • Выбор функциональных возможностей, необходимых для реализации этой роли, и создание файла с расширением .тс для данной конфигурации. • Компиляция файла с расширением .тс с помощью препроцессора т4, чтобы соз- дать файл конфигурации . cf. Мы опишем функциональные возможности, типичные для общедоступных в рамках организации серверов, имеющих выход в Интернет, и для небольших настольных кли- ентов. Более подробное описание можно найти в документации программы sendmail, в книге Sendmail Брайана Косталеса и его соавторов (Bryan Costales et al.), а также в файле cf/readme из дистрибутивного пакета. Препроцессор т4 Изначально предназначенный для использования в сочетании с языками программи- рования, препроцессор т4 позволяет пользователям писать более удобочитаемые (или,
826 Часть IL Работа в сети наоборот, запуганные) программы. Это достаточно мощный инструмент, чтобы оказать- ся полезным во многих ситуациях, связанных с преобразованием входной информации, он прекрасно работает с конфигурационными файлами программы sendmail. Макрос препроцессора т4 имеет следующую форму. name(arglf агд2, агдп) Между именем и открывающей скобкой не должно быть пробелов. Левая и правая одинарные кавычки обозначают строки в качестве аргументов. Соглашения о кавычках в макросах препроцессора т4 являются странными, поскольку левая и правая кавыч- ки — это одинаковые символы. Кроме того, кавычки могут быть вложенными. Препроцессор т4 имеет несколько встроенных макросов, и пользователи могут определять свои собственные макросы. Основные встроенные макросы, используемые в конфигурации программы sendmail, приведены в табл. 20.8. Таблица 20.8. Макросы препроцессора т4, часто используемые программой sendmail Макрос define Определяет макрос с именем arg1 со значением arg2 undefine Отменяет предыдущее определение макроса с именем arg 1 include Включает (интерполирует) файл с именем arg 1 dnl Игнорирует все символы до начала новой строки divert Управляет выходными потоками Фрагменты конфигурации программы sendmail Дистрибутивный пакет программы sendmail содержит подкаталог cf, в котором находятся все фрагменты, необходимые для конфигурации препроцессора т4. Если вы не самостоятельно инсталлируете программу sendmail на основе исходного текста, а полагаетесь на поставщика, то используйте местоположение каталога cf, указанное в табл. 20.5. Документация о конфигурации программы sendmail записана в файле README. Подкаталоги, перечисленные в табл. 20.9, содержат примеры и фрагменты, ко- торые можно включать в свою конфигурацию. Таблица 20.9. Подкаталоги конфигурации программы sendmail Каталог Содержимое Д- г , cf Эталонные файлы .тс (мастера конфигурации) domain Эталонные файлы т4 для разных доменов в домене Berkeley feature Фрагменты, реализующие разные функциональные возможности hack Особые функциональные возможности, ценность или реализация которых сомнительна т4 Основной файл конфигурации и другие важные файлы ostype Местоположение файлов, зависящее от операционной системы, и другая полезная информация mailer Файлы т4, описывающие основные программы для рассылки (агенты доставки) sh Сценарии оболочки, используемые в препроцессоре т4 Каталог cf/cf содержит примеры файлов с расширением .тс. Фактически он со- держит так много примеров, что в них легко запутаться. Мы рекомендуем хранить свои файлы с расширением .тс отдельно от примеров, размещенных в каталоге cf. Для этого следует либо создать новый каталог для своего сайта (cf/имясайта), либо разместить
Глава 20. Электронная почта 827 каталог cf отдельно под именем cf. examples и создать новый каталог cf. Если вы сделаете это, скопируйте в свой новый каталог сценарии Makefile и Build, чтобы инструкции из файла README сохранили свою работоспособность. В качестве альтер- нативы можно скопировать все собственные файлы конфигурации с расширением .тс в центральное место хранения, а не оставлять их в дистрибутивном пакете программы sendmail. Сценарий Build использует относительные пути, поэтому, если вы хотите создать файл с расширением . cf из файла с расширением .тс и не использовать имена их дистрибутивной иерархии программы sendmail, придется их изменить. Файлы из каталога cf/ostype конфигурируют программу sendmail для любой кон- кретной операционной системы. Многие из них являются заранее заданными, но если вы изменили настройки своей системы, то вам придется либо модифицировать их, либо создавать новые. Скопируйте тот из них, который лучше соответствует вашей системе, и присвойте ему новое имя. Каталог cf/feature — это место, где вы будете искать все фрагменты конфигура- ции, которые вам нужны. Там найдутся все функциональные возможности, которые мо- гут оказаться полезными для сайта, использующего программу sendmail. Остальные подкаталоги каталога cf служат, скорее, как заглушки. Их не надо иссле- довать или анализировать — просто используйте их. Конфигурационный файл, построенный на основе эталонного файла с расширением .тс Перед тем как погрузиться в детали различных конфигурационных макросов, свойств и параметров, которые могут использоваться при конфигурировании программы sendmail, создадим простую конфигурацию, тем самым проиллюстрировав весь про- цесс. Предметом нашего примера будет концевой узел myhost. example. com; главный конфигурационный файл называется myhost .тс. Рассмотрим полный файл с расшире- нием .тс. divert(-1) #### basic .тс file for example.com divert (0) VERSIONID('$Id$') OSTYPE('linux’) MAILER(4 local') MAILER('smtp*) За небольшим исключением, каждая строка содержит вызов готового макроса. Пер- вые четыре строки представляют собой заглушку; они вставляют комментарий в ском- пилированный файл, чтобы указать версию программы sendmail, созданный ката- лог конфигурации и т.д. Макрос OSTYPE интерполирует файл . . /ostype/linux.m4. Строки, содержащие вызов макроса MAILER, разрешают локальную доставку сообщений (пользователям, имеющим учетные записи на сервере myhost. example. com), а также доставку интернет-сайтам. Для того чтобы создать реальный конфигурационный файл, просто примените ко- манду Build к новому скопированному вами каталогу cf. $ . /Build myhost. cf В заключение инсталлируйте файл myhost. cf в соответствующем месте —как пра- вило, как файл /etc/mail/sendmail. cf, хотя некоторые поставщики могут поместить его в другое место. Чаще всего поставщики размещают его в каталоге /etc и /usr/lib.
828 Часть II. Работа в сети Для более крупных сайтов можно создать отдельный файл препроцессора т4, что- бы хранить там значения, заданные по умолчанию; поместите его в каталог cf/domain. Отдельные узлы могут затем включать его содержимое, используя макрос domain. Отдельный файл конфигурации нужен не каждому компьютеру, но каждая группа по- хожих компьютеров (с одинаковой архитектурой и одинаковыми ролями: сервер, клиент и т.д.), вероятно, нуждается в собственной конфигурации. Порядок следования макросов в файле с расширением .тс не случаен. Он должен быть таким. VERSIONID OSTYPE DOMAIN FEATURE определения локальных макросов MAILER Даже имея простую систему конфигурации т4 для программы sendmail, вам, воз- можно, придется принимать несколько разных решений, связанных с конфигурацией вашего сайта. Читая о функциональных возможностях, описанных ниже, подумайте о том, как их применять к вашей сети. Небольшая сеть, вероятно, будет иметь один кон- центратор и концевые узлы, а значит, только два варианта файла конфигурации. В более крупной сети могут понадобиться отдельные концентраторы для входящей и исходящей почты и, вероятно, отдельный сервер POP/IMAP. Независимо от сложности вашей сети и ее представления во внешнем мире (откры- той, за брандмауэром или виртуальной частной сети, например), скорее всего, каталог cf содержит готовые фрагменты, подходящие для настройки и использования. 20.10. Примитивы конфигурации программы sendmail Команды конфигурации sendmail чувствительны к регистру клавиатуры. По обще- принятому соглашению, имена заранее определенных макросов состоят только из про- писных букв (например, OSTYPE), команды препроцессора т4 — только из строчных букв (например, define). Названия параметров конфигурации начинаются с префикса conf, набранного в нижнем регистре, и заканчиваются именем переменной, набран- ным в верхнем регистре (например, confFALLBACK_MX). Макросы обычно ссылают- ся на файл препроцессора т4 с именем . . /имя_макроса/аг%1 .т4. Например, ссылка OSTYPE (' linux') включает файл .. /ostype/linux.m4. Таблицы и базы данных Перед тем как погрузиться в детали, связанные с конкретными примитивами конфи- гурации, сначала следует обсудить таблицы (иногда называемые ассоциативными мас- сивами (maps) или базами данных), которые программа sendmail может использовать для маршрутизации почты или перезаписи адреса. Большинство из них используется в сочетании с макросом feature. Таблица — это кеш (как правило, текстовый файл), содержащий информацию о маршрутизации, псевдонимах, правилах, а также другие данные, которые можно пре- образовать в формат базы данных с помощью команды makemap, а затем использовать как источник информации при выполнении одной или нескольких операций програм- мы sendmail.
Глава 20. Электронная почта 829 Хотя данные для программы sendmail обычно хранятся в текстовом файле, они мо- гут также поступать из системы DNS, от сервера NIS, от протокола LDAP или из других источников. Использование централизованного сервера IMAP освобождает программу sendmail от выполнения рутинных операций, связанных с розыском пользователей и их устаревших таблиц. Поддерживаются две библиотеки баз данных: библиотека dbm/ndbm — стандарт для большинства версий систем UNIX и Linux, а также Berkeley DB — более крупная библи- отека, поддерживающая многочисленные схемы хранения. Мы рекомендуем использо- вать библиотеку BDB, если она уже установлена в вашей системе или вы можете ее уста- новить. Она работает быстрее, чем база данных dbm, и создает файлы меньшего размера. Программа sendmail предусматривает три типа ассоциативных массивов. • dbm — использует расширяемые алгоритмы хеширования (dbm/ndbm) • hash — использует стандартную схему хеширования (DB) • btree — использует В-дерево (DB) В большинстве случаев использования таблиц в программе sendmail наилучшим яв- ляется формат базы данных hash, заданный по умолчанию. Для создания базы данных из текстового файла следует использовать команду makemap, задав тип и имя выходного файла базы данных. Текстовая версия базы данных должна передаваться на стандартный вход команды makemap. Рассмотрим пример. $ sudo makemap hash /etc/mail/access < /etc/mail/access На первый взгляд эта команда выглядит ошибкой, которая может вызвать переза- пись входного файла пустым результирующим файлом. Однако команда makemap добав- ляет специальный суффикс, так что реальный результирующий файл будет называться / etc/mail/access. db и конфликт не возникнет. Каждый раз при изменении текстового файла файл базы данных необходимо создавать заново с помощью команды makemap (но программа sendmail не требует использования сигнала HUP). В текстовых файлах, на основе которых создаются ассоциативные массивы, могут на- ходиться комментарии. Они начинаются символом # и продолжаются до конца строки. В большинстве случаев в качестве ключа базы данных используется самое длинное из возможных совпадений. Как и в любой другой хешированной структуре, порядок сле- дования записей во входном текстовом файле не имеет значения. Примитивы FEATURE, ожидающие файл базы данных как параметр, по умолчанию предусматривают в каче- стве типа базы данных тип hash, а в качестве имени базы данных — имя /etc/mail/ имя__таблицы. db. Обобщенные макросы и функциональные возможности В табл. 20.10 перечислены основные примитивы конфигурации с указанием степени их использования (да, нет, возможно) и кратким описанием их действий. Более подроб- но они будут рассмотрены ниже. Таблица 20.10. Основные примитивы конфигурации программы sendmail Примитив Испаньзумся? '''У* OSTYPE Да Включает пути, специфичные для операционной системы, и флаги программы рассылки DOMAIN Нет Включает детали конфигурации, специфичные для сайта
830 Часть II. Работа в сети Окончание табл. 20.10 •; «у ’-'«» .Л •_ ‘ Примитив ^ Описание - MAILER Да Допускает использование программ рассылки, обычно smtp и local FEATURE Возможно Допускает использование набора функциональных возмож- ностей программы sendmail use cw_file Да(серверы) Перечисляет узлы, на которые можно посылать сообщения redirect Возможно (серверы) Перенаправляет письма при перемещении пользователей always_add_domain Да Полностью определяет имена компьютеров, если сервер UA этого не сделал access_db Возможно (серверы) Заставляет базу данных задерживать отправление почты virtusertable Возможно (серверы) Включает псевдонимы доменов (виртуальные домены) ldap_routing Возможно (серверы) Маршрутизирует входящую почту с помощью протокола LDAP MASQUERADE_AS Да Маскирует всю почту так, будто она исходит из одного ис- точника EXPOSED_USER Да Перечисляет пользователей, которых не следует маскиро- вать MAIL_HUB Возможно (серверы) Задает почтовый сервер, предназначенный для входящей почты SMART_HOST Возможно (клиенты) Задает почтовый сервер, предназначенный для исходящей почты Макрос OSTYPE Файл OSTYPE содержит разнообразную информацию от производителей, например ожидаемое местонахождение файлов, связанных с почтовой системой, пути к командам, которые необходимы для программы sendmail, флаги для программ рассылки и т.д. Список всех переменных, которые можно определить в файле OSTYPE, перечислены в файле cf/README.10 Каждая из рассмотренных нами операционных систем, за исключением систе- * мы SUSE, содержит соответствующий файл OSTYPE из дистрибутивного паке- та sendmail. Вместо этого система SUSE содержит свой собственный файл suse_linux. m4. Этот файл длинный (более 80 строк, по сравнению с пятью строками в сопостави- мом файле linux .m4) и содержит многочисленные примитивы FEATURE наряду с други- ми макросами, которые обычно можно найти в главном конфигурационном файле сайта (файле с расширением .тс), но не в файле OSTYPE. Таким образом, реальная конфигу- рация скрыта от системного администратора — в этом есть и преимущества, и недостат- ки, но мы не рекомендуем эту практику. 10 Так где же все-таки определен макрос OSTYPE? В одном из файлов в каталоге cf /т4, кото- рый таинственным образом добавляется к вашему конфигурационному файлу при запуске сцена- рия Build.
Глава 20. Электронная почта 831 Макрос DOMAIN Директива domain позволяет указывать всю общую информацию о сайте в одном ме- сте (cf /domain/имя_файла а затем включать в каждый конфигурационный файл компьютера. DOMAIN (' filename ’) Макрос MAILER Этот макрос следует включать в каждый агент доставки, который вы хотите исполь- зовать. Полный список программ рассылки можно найти в каталоге cf/mailers, но обычно необходимы только local, smtp и, возможно, cyrus. Строки, содержащие ма- крос MAILER, обычно являются последними в файле .тс. Макрос FEATURE Рассматриваемый макрос позволяет реализовать большое количество сценариев (по последним данным, 56!), включая файлы препроцессора т4 из каталога feature. Его синтаксическая конструкция выглядит следующим образом. FEATURE (keyword, arg, arg, ...) Здесь аргумент keyword соответствует файлу keyword.яА в каталоге cf/feature. Коли- чество остальных аргументов не должно превышать девяти. Функциональная возможность use^cwjFlle Внутренний класс w программы sendmail (отсюда имя cw) содержит имена всех локальных компьютеров, к которым есть доступ из данного узла и может доставляться почта. Эта функциональная возможность позволяет доставлять почту узлам, построчно перечисленным в списке, находящемся в файле /etc/mail/local-host-names. Эту функциональную возможность активизирует конфигурационный файл. FEATURE('use_cw_file’) Клиентская машина на самом деле не нуждается в этой возможности, если у нее есть псевдоним. Файл local-host-names должен содержать имена всех локальных узлов и виртуальных доменов, которым можно доставлять почту, включая сайты, резервные за- писи MX которых ссылаются на ваш компьютер. Если эта функциональная возможность не подключена, то программа sendmail вы- полняет локальную доставку почты, только если она адресована компьютеру, на котором выполняется сама программа sendmail. Если вы добавили в сеть новый компьютер, то должны добавить его имя в файл local- host-names и послать сигнал HUP программе sendmail, чтобы изменения вступили в силу. К сожалению, программа sendmail считывает этот файл только при запуске. Функциональная возможность redirect Когда люди покидают вашу организацию, вы обычно либо пересылаете им почту, либо возвращаете ее отправителю с сообщением об ошибке. Функциональная возмож- ность redirect позволяет реализовать более элегантное решение для возврата почты. Если Джо Смит окончил университет oldsite.edu (регистрационное имя smithj) и перешел в организацию newsite. com (регистрационное имя joe), то, включив функ- циональную возможность redirect с помощью примитива FEATURE('redirect1)
832 Часть II. Работа в сети и добавив строку smithj: joe@newsite.com.REDIRECT в файл aliases на сайте oldsite.edu, вы сможете возвращать почту, адресованную пользователю smithj, отправителю вместе с сообщением об ошибке, в котором указан новый адрес получателя joe@newsite. com. Само письмо автоматически не перенаправ- ляется. Функциональная возможность always_add_domain Эта функциональная возможность задает полное определение всех почтовых адресов. Ее следует использовать постоянно. Функциональная возможность accessjdb С помощью этой функциональной возможности можно управлять задержкой и дру- гими правилами работы с почтой. Обычно данные, которые управляют этой функцио- нальной возможностью, либо поступают от сервера LDAP, либо хранятся в текстовом файле /etc/mail/access. Во втором случае текстовый файл должен быть преобразо- ван в индексированный формат с помощью команды makemap, как показано выше. Для использования простого файла в конфигурационном файле следует указать инструкцию FEATURE (' access db •); для работы с сервером LDAP следует использовать инструк- цию FEATURE ('accesS-db', 'LDAP*) .п Полем ключа для доступа к базе данных является IP-адрес сети или имя домена, сопровождаемое необязательным дескриптором, например Connect:, То: или From:. Поле значения указывает, что делать с сообщением. Наиболее широко используются такие значения, как ОК для приема сообщений, RELAY для разрешения задержки, REJECT для отказа с сообщением об ошибке общего характера или ERROR: "код ошибки и сообщение" для отказа с сообщением о конкретной ошибке. С помощью других значений можно установить более точный контроль. Рас- смотрим фрагмент из файла /etc/mail/access. localhost 127.0.0.1 192.168.1.1 192.168.1.17 66.77.123.1 fax.com 61 67.106.63 RELAY RELAY RELAY RELAY OK OK ERROR:”550 We don’t accept mail from spammers" ERROR:"550 We don’t accept mail from spammers" Функциональная возможность virtusertable Эта функциональная возможность позволяет задавать псевдонимы доменов для входящей корреспонденции, размещать несколько виртуальных доменов на одной ма- шине и использовать их для веб-хостинга. Поле ключа таблицы содержит либо адрес электронной почты (userQhost. domain), либо спецификацию домена (^domain). Поле значения содержит локальный или внешний адрес электронной почты. Если ключом является домен, то значение может либо передавать поле user как переменную %1, либо направлять почту другому пользователю. Рассмотрим несколько примеров. 11 В этом примитиве используется схема LDAP, определенная в файле cf/sendmail.schema; если вы хотите использовать другой файл схемы, укажите дополнительные аргументы в инструкции FEATURE.
Глава 20. Электронная почта 833 @appliedtrust.com %10atrust.com unix0book.admin.com sa-book-authors0atrust.com linux0book.admin.com sa-book-authors0atrust.com webmaster0example.com billy.q.zakowski0colorado.edu info0testdomain.net ausername0hotmail.com Все ключи в левой части отображения данных должны быть перечислены в файле cw, т.е. /etc/mail/local-host-names, или находиться в списке VIRTUSER DOMAIN. Если это условие не выполняется, то программа sendmail не сможет принять локальную по- чту и попытается найти адресата в Интернете. Однако записи DNS MX вернут програм- му sendmail назад на тот же самый сервер, и в результате рикошета вы получите со- общение “local configuration error” (“ошибка локальной конфигурации”). К сожалению, программа sendmail не может сообщить, что это сообщение на самом деле означает “ключа виртуального пользователя в файле cw нет”. Функциональная возможность ldap_routing Протокол LDAP (Lightweight Directory Access Protocol — облегченный протокол до- ступа к каталогам) может быть источником данных о псевдонимах или информации о маршрутизации почты, а также общих данных, хранящихся в таблицах. Файл cf /README содержит большой раздел о протоколе LDAP с множеством примеров. Для того чтобы использовать сервер LDAP указанным выше способом, необходимо скомпилировать программу sendmail так, чтобы она включала поддержку протокола LDAP. Для этого в файл .тс следует добавить такие строки. define ('confLDAP_DEFAULT_SPEC', '-h server -b searchbase') FEATURE('ldap_routing') LDAPROUTE_DOMAIN('my_domain') Эти строки означают, что вы хотите использовать базу данных протокола LDAP для маршрутизации входящей почты, адресованной указанному домену. Параметр LDAP DEFAULT SPEC идентифицирует сервер LDAP и базовое имя LDAP для поисков. Протокол LDAP использует порт 389, если вы не указали явным образом другой порт, добавив в инструкцию define параметр -р nopT_ldap. Программа sendmail использует значения двух дескрипторов в базе данных LDAP. • mailLocalAddress — для адресата входящей почты. • mailRoutingAddress — для пункта назначения, в который должна быть достав- лена почта. Кроме того, программа sendmail использует дескриптор mailHost, который на- правляет почту обработчику, заданному в поле MX для указанного узла. Адресом полу- чателя остается значение дескриптора mailRoutingAddress. Записи базы данных LDAP позволяют использовать шаблонный символ 0 domain, который перенаправляет почту, адресованную кому-либо в указанном домене (как и па- раметр virtusertable). По умолчанию почта, адресованная получателю user0hostl .mydomain, сначала направляется пользователю адресата user0hostl .mydomain. Если такого адресата нет, программа sendmail может попытаться выполнить поиск в домене 0hostl .mydomain, а не использовать адрес user0mydomain. Включив строку LDAPROUTE_EQUIVALENT('hostl.mydomain1) можно также проверить ключи user0mydomain и @mydomain. Эта функциональная возможность допускает использование единой базы данных для маршрутизации почты
834 Часть II. Работа в сети на сложных сайтах. Вы также можете использовать записи для разделов LDAPROUTE_ equivalent из файла, что делает это свойство еще более полезным. Синтаксис этой инструкции выглядит следующим образом. LDAPROUTE_EQUIVALENT_FILE('filename') Кроме того, свойство Idap routing позволяет более подробно описать схему LDAP, чем в разделе +detail, и точнее управлять обработкой имен адресатов. Как всегда, бо- лее подробную информацию следует искать в файле cf/README. Маскирующие функциональные возможности Адрес электронной почты часто используется в качестве имени пользователя, узла и домена, но многие организации не хотят демонстрировать имена своих узлов в Интернете. Макрос MASQUERADE_AS позволяет скрыть все машины за единственной сущностью. Вся появляющаяся почта будет исходить от указанного компьютера или до- мена. Это очень удобно для обычных пользователей, но системные пользователи, такие как корневой пользователь, не должны участвовать в маскировке. Например, последовательность инструкций MASQUERADE—AS (' atrust. com') EXPOSED_USER('root’) EXPOSED—USER('Mailer-Daemon') проштамповывает почту так, будто она исходит от адреса user@atrust. com, если она не была послана корневым пользователем или почтовой системой; в этих случаях почта должна иметь истинный адрес отправителя. Инструкция MASQUERADE AS — это верхуш- ка айсберга, за которой скрываются десятки вариантов и исключений. Функциональные возможности allmasquerade и masquerade_envelope (в сочетании с MASQUERADE_AS) скрывают требуемую часть локальной информации. Детали см. в файле cf/README. Макросы MAILJiUB и SMARTJiOST Маскировка изменяет заголовки и, возможно, конверт, чтобы вся почта выглядела исходящей от одного компьютера или домена. Однако большинство организаций дей- ствительно желают, чтобы вся почта исходила от одного компьютера или поступала на один компьютер, чтобы можно было контролировать поток вирусов, спама и секретов компании. Этот контроль можно обеспечить с помощью сочетания записей MX в систе- ме DNS, макроса MAIL_HUB для входящей почты и макроса SMART_HOST для исходящей почты. СЗ Более подробная информация о записях DNS MX приведена в разделе 17.8. Например, в архитектурной диаграмме из раздела 20.4 записи MX могут направлять входящую электронную почту из Интернета транспортному агенту в демилитаризован- ной зоне. После проверки того факта, что полученная почта не содержит вирусы и спам и была направлена правильному локальному пользователю, почту можно передать с по- мощью инструкции define внутреннему транспортному агенту, выполняющему марш- рутизацию. define('MAIL_HUB', 'smtp:routingMTA.mydomain1) Ш Функциональная возможность nullclient рассматривается в следующем разделе. Аналогично клиентские компьютеры могут направлять свою почту компьютеру SMART HOST, назначенному в конфигурации с помощью свойства nullclient. Компью-
Глава 20. Электронная почта 835 тер SMART HOST затем может профильтровать вирусы и спам, чтобы почта из вашей сети не просочилась в Интернет. Синтаксис инструкции SMART HOST аналогичен синтаксису инструкции MAIL нив, причем агентом доставки тоже является relay. “ define ('SMART_HOST* , ' smtp: outgoingMTA.mydomain') Ту же самую машину можно использовать как сервер для входящей и исходящей по- чты. Инструкции SMART HOST и MAIL HUB должны разрешать передачу: первая — от клиентов внутри вашего домена, а вторая — от транспортного агента в зоне DMZ. Конфигурация клиентов Если ваша организация следует принципам, описанным в разделе 20.4, то большин- ство ваших компьютеров необходимо конфигурировать как клиентов, желающих посы- лать исходящую почту, генерируемую пользователями, и не получать почту вообще. Одна из функциональных возможностей программы sendmail под названием nullcltent предназначена именно для таких ситуаций. Она создает конфигурационный файд, ко- торый перенаправляет всю почту на центральный концентратор через сервер SMTP. Содержание всего конфигурационного файла, следующее за строками с макросами VERSIONID и OSTYPE, сводится к следующим строкам. FEATURE('nocanonify’) FEATURE('nullclient’, 'mailserver1) EXPOSED_USER('root1) Здесь mailserver — это имя центрального концентратора. Параметр nocanonify сооб- щает программе sendmail, что она не должна выполнять поиск в системе DNS или перезаписывать адреса с полностью определенными именами доменов. Всю эту рабо- ту будет выполнять почтовый сервер. Этот параметр похож на параметр SMART_HOST и предполагает, что клиент применяет к почтовому серверу инструкцию MASQUERADE—AS. Инструкция EXPOSED USER исключает корень из маскировки и открывает возможности для отладки. Компьютер mailserver должен разрешать ретрансляцию от своих нулевых клиентов. Это разрешение предоставляется примитивом access_db, описанным выше. Нулевой клиент должен иметь соответствующую запись MX, ссылающуюся на компьютер mailserver, а также содержаться в файле cw на компьютере mailserver (который обычно называется /etc/mail/local -host-names). Эти настройки позволяют компьютеру mailserver принимать почту для клиента. Если пользовательские агенты на клиентской машине могут использовать порт 587 для отправки почтовых сообщений, то программа sendmail должна выполняться как агент доставки (без флага -bd). В противном случае вы можете выполнить программу sendmail в режиме демона (-bd), задав параметр конфигурации DAEMON—OPTIONS так, чтобы прослушивать соединения только в интерфейсе замыкания (loopback interface). В операционной системе SUSE есть эталонный файл /etc/mail/linux. •11 R nullclient. тс для нулевого клиента. Запишите в него имя своего почтового сервера, создайте файл sendmail. cf, и готово! Параметры конфигурации Параметры файла конфигурации задаются с помощью команды define, относящей- ся к препроцессору т4. Полный список параметров, доступных как переменные препро-
836 Часть II. Работа в сети цессора т4 (вместе с их значениями, заданными по умолчанию), приведен в файле cf/ README. Значения по умолчанию подходят для типичной организации, не страдающей от па- ранойи и не слишком обеспокоенной вопросами производительности. Параметры, за- данные по умолчанию, предназначены для защиты от спама: они отключают ретрансля- цию и требуют, чтобы адреса были полностью определенными, а домены отправителей соответствовали их IP-адресам. Если ваш почтовый концентратор слишком загружен и обслуживает слишком много списков рассылки, может потребоваться более тонкая на- стройка. Параметры, которые приходится настраивать чаще всего, перечислены в табл. 20.11 (это лишь около 10% из почти 175 параметров конфигурации). В скобках указаны их значения по умолчанию. В целях экономии места префикс conf в названиях пара- метров опущен. Например, параметр FALLBACK MX в действительности называется conf FALLBACK MX. Таблица разделена на части, в соответствии с тем, для каких целей применяются те или иные параметры: общих, связанных с ресурсами, производительно- стью, безопасностью, спамом и т.д. Некоторые параметры попадают сразу в несколько категорий, однако мы указали их только в одном месте. Таблица 20.11. Основные параметры конфигурации У" ' 11 " i._ Л 111 ' 1 К Jl)1 Параметр _ ' . RSg-j MAX_DAEMON_CHILDREN Максимальное количество порожденных процессова (ограни- чений нет) 3 о MAX_MESSAGE_SIZE Максимальный размер в байтах одного сообщения (ограниче- о. о ний нет) £ MIN_FREE_BLOCKS Минимальное пространство в файловой системе для хранения поступающей почты (100) Т0_имя Время тайм-аута для разных ситуаций (варьируется) DELAY_LA Показатель средней загруженности, при котором доставка по- чты замедляется (0 — нет ограничений) FALLBACK_MX См. описание в разделе 20.12 (значение по умолчанию отсут- ствует) FAST_SPLIT Подавляет поиск записей MX при сортировке адресов получа- телей и распределении их по очередям (1 — включено) е о HOST_STATUS_DIRECTORY См. описание в разделе 20.12 (значение по умолчанию отсут- о X ствует) MCI_CACHE_SIZE Количество открытых кешированных ТСР-соединений (2) I MCI_CACHE_TIMEOUT Время, в течение которого кешированные соединения остают- со X ся открытыми (5m) о о. CZ MIN_QUEUE_AGE Минимальный период времени, в течение которого сообщение должно находиться в очереди; позволяет улучшить обработку очереди на перегруженном компьютере (0) QUEUE_LA Показатель средней загруженности, при котором сообще- ния помещаются в очередь, а не отправляются немедленно (%* число .процессоров) REFUSE_LA Показатель средней загруженности, при котором почта пере- стает приниматься (12*число_лроцессоров)
Глава 20. Электронная почта 837 Окончание табл. 20.11 Параметр . > AUTHJMECHANISMS Список механизмов аутентификации по протоколу SMTP для библиотеки Cyrus SASL6 CONNECTION_RATE_ Предотвращает атаки типа “отказ от обслуживания”, ограничи- THROTTLE вая скорость, при которой разрешается устанавливать почто- со с вое соединение (ограничений нет) DONT_BLAME_SENDMAIL Отменяет ряд функций программы sendmail, связанных с без- н о опасностью и проверкой файлов; не изменяйте значение этой X о опции без особой необходимости (safe) со с о MAX_MIME_HEADER_LENGTH Максимальный размер заголовков MIME (ограничений нет)8 ф из MAX_RCPTS_PER_MESSAGE Препятствует отправке спама; обработка избыточного числа получателей приостанавливается и генерируется временное сообщение об ошибке (число получателей не ограничено) PRIVACY_FLAGS Налагает ограничения на информацию, выдаваемую по про- токолу SMTP (authwarnings) DOUBLE_BOUNCE_ADDRESS Перехватывает множество спама; некоторые организации ф о используют каталог /dev/null, но это может привести к оерьез- X 8 ным проблемам (почтовый сервер) О- L DAP_DE FAUL T_S PE C Спецификация базы данных LDAP, включая имя компьютера, на котором запущен сервер, и номер порта (не определена) аТочнее говоря, это максимальное количество дочерних процессов, которые можно выполнить одновремен- но. При достижении предельного значения программа sendmail отказывается принимать запросы. Эта оп- ция позволяет предотвратить атаки типа “отказ от обслуживания”. Значение по умолчанию таково: “EXTERNAL GSSAPI KERBER0S_V4 DIGEST-MD5 CRAM-MD5”. Не добавляйте “PLAIN LOGIN”, поскольку пароль передается открытым текстом. Если соединение также не защищено с по- мощью криптографического протокола SSL, то изнутри все может выглядеть благополучно, а со стороны Интернета — нет. 8 Эта опция защищает буфер пользовательского агента от переполнения. Рекомендуемое значение — “256/128”, что означает “256 байт на заголовок и 128 байт на каждый параметр заголовка”. Средства программы sendmail для борьбы со спамом Программа sendmail имеет разнообразные возможности для борьбы со спамом и вирусами. • Правила управления открытой ретрансляцией, под которой понимается использова- ние почтового сервера для отправки сообщения одним сторонним пользователем другому, тоже стороннему. Спамеры часто прибегают к ретрансляции, пытаясь таким способом замаскировать действительного адресата сообщения и тем самым избежать обнаружения со стороны своих собственных провайдеров. Это также по- зволяет им перекладывать финансовую и вычислительную нагрузку на чужие плечи. • База доступа, позволяющая фильтровать почту согласно адресам, содержащимся в базе. Это напоминает применение брандмауэра для электронной почты. • Черные списки открытых ретрансляторов и известных спамеров, проверяемые про- граммой sendmail. • Дроссели, которые могут замедлять прием почты при обнаружении неправильного по- ведения.
838 Часть II. Работа в сети • Проверка заголовков и фильтрация входящей почты посредством универсальной би- блиотеки фильтров libmilter. Эта библиотека позволяет сканировать заголовки и содержимое сообщений и отбрасывать сообщения, удовлетворяющие опреде- ленным критериям. Эти средства в сочетании с другими технологиями, такими как серые списки, скани- рование содержимого с помощью интерфейса amavisd-new и новые записи DNS для аутентификации электронной почты, описанными в разделе 20.6, создают эффективную защиту от спама. Ретрансляция Программа sendmail получает входящую почту, просматривает адреса конверта, принимает решение о том, куда переслать сообщение, после чего отправляет его в со- ответствующий пункт назначения. Это может быть не только локальный получатель, но и другой транспортный агент, расположенный далее по цепи доставки. Когда входящее сообщение не имеет локального получателя, транспортный агент, обрабатывающий его, играет роль ретранслятора (relay). До появления программы sendmail версии 8.9 по умолчанию включался режим “бес- порядочной” рассылки (известный как открытая ретрансляция). Программа sendmail принимала сообщения через порт 25 и пыталась осуществить доставку оптимальным способом. В те времена считалось, что Интернет — дружественная среда. Только узлам, помеченным ключевым словом RELAY в базе доступа (см. выше), а также узлам, перечисленным в файле /etc/mail/relay-domains, разрешается предо- ставлять почту для ретрансляции. Впрочем, некоторые типы ретрансляции необходи- мы. Как определить, какое сообщение следует ретранслировать, а какое — отклонить? Ретрансляция нужна лишь в двух случаях. • Когда транспортный агент выступает в качестве шлюза для узлов, недоступных ни- каким другим способом. Это могут быть периодически выключаемые компьютеры (PPP-узлы, персональные компьютеры, работающие под управлением Windows) и виртуальные узлы. В этом случае все получатели, которым требуется переслать со- общение, должны находиться на одном домене. • Когда транспортный агент является сервером исходящей почты для других узлов. В этом случае имена и IP-адреса всех узлов-отправителей являются локальными (или, по крайней мере, заданы явно). Любые другие случаи ретрансляции, скорее всего, свидетельствуют о плохой конфи- гурации сервера (исключение можно сделать в отношении мобильных пользователей). Чтобы избежать ретрансляции в первом из упомянутых вариантов, организуйте прием почты на центральном сервере (с использованием протокола POP или IMAP для клиент- ского доступа). Второй вариант должен быть всегда допустим, но только для локальных узлов. Лучше проверять IP-адреса, чем имена компьютеров, так как последние проще подделать; впрочем, программа sendmail следит за этим. В программе sendmail ретрансляция запрещена по умолчанию, но с помощью специальных средств ее можно разрешить либо в полном объеме, либо в ограничен- ном и контролируемом режиме. Эти средства перечислены ниже. Их можно исполь- зовать, но мы рекомендуем проявлять максимум осторожности и не злоупотреблять ими. Безопаснее всего организовать ограниченную ретрансляцию с помощью средства access db, рассматриваемого в следующем подразделе.
Глава 20. Электронная почта 839 • FEATURE (' relay entire domain') — разрешает ретрансляцию для узлов теку- щего домена. • RELAY DOMAIN (4 домен, . . .') — дополнительно разрешает ретрансляцию для указанных доменов. • RELAY_DOMAIN_FILE (' имя_файла ’) — то же самое, но список доменов берется из файла. • FEATURE (' relay_hosts_only ’) — влияет на работу макроса RELAY_DOMAIN и средства access_db. Если благодаря макроконстантам SMART_HOST и MAIL HUB почта направляется на конкретный почтовый сервер, придется сделать исключение. Этот сервер должен быть настроен на ретрансляцию всей почты, поступающей от локальных компьютеров. FEATURE('relay_entire_domain’) Если вы рассматриваете возможность разрешения ретрансляции в какой-то форме, обратитесь к документации программы sendmail в файле cf/README , чтобы ненаро- ком не стать подручным спамеров. Если решите включить ретрансляцию, то обратитесь к одному из специализированных сайтов с просьбой проверить, что вы случайно не соз- дали открытую ретрансляцию, в частности, можно обратиться на сайт spamhelp. org. Использование черных списков Если необходимо блокировать почту каких-либо локальных пользователей или узлов, воспользуйтесь средством FEATURE('blacklist_recipients') которому в базе доступа соответствуют записи следующих типов. To:nobody@ ERROR:550 Mailbox disabled for this user To:printer.mydomain ERROR:550 This host does not accept mail To:user@host.mydomain ERROR:550 Mailbox disabled for this user Эти записи блокируют почту, приходящую на адрес пользователя nobody (на любом узле), а также адресованную сетевому принтеру и одному из пользователей конкретного компьютера. Дескриптор То: разрешает этим пользователям посылать сообщения (по- добной возможностью обладают некоторые принтеры), но не принимать их. Для того чтобы подключить черные DNS-списки для входящей почты, используется параметр dnsbl. FEATURE('dnsbl’) FEATURE('enhdnsbl') Эта функциональная возможность заставляет программу sendmail отклонять по- чту, приходящую от узла, IP-адрес которого указан в списке известных спамеров (SBL, XBL и PBL), поддерживаемых сайтом spamhaus. org. В других списках указаны адреса спамеров, работающих по коммутируемым линиям, и узлов, поддерживающих открытую ретрансляцию. Черные списки распространяются через службу DNS с помощью особого приема. Более подробное описание работы этой системы приведено в разделе 20.6. Средство dnsbl может принимать третий аргумент, который задает требуемое со- общение об ошибке. Если третий аргумент пропущен, будет выдано фиксированное со- общение (из базы данных DNS, содержащей проверяемые записи). Функциональную возможность dnsbl можно включать несколько раз, чтобы прове- рять разные списки злоумышленников.
840 Часть II. Работа в сети дроссели, скорость и ограничения на количество соединений В табл. 20.12 перечислено несколько команд программы sendmail, которые могут замедлить обработку почты, если поведение клиентов покажется подозрительным. Таблица 20.12. Основные параметры конфигурации ULV'JI ' ' "Л I и II ЛИ И. . ........ 11 ^iu и 11 Ill Примитив Описание _______ bad_rcpt_throttle Замедляет коллекционирование адресов спамерами max_rcpts_per_message Откладывает доставку, если сообщение имеет слишком много получателей ratecontrol Ограничивает скорость входящих соединений conncontrol Ограничивает количество одновременных соединений greet pause Задерживает ответ НЕЮ, требует точного подчинения протоколу SMTP После того как счетчик no-such-login достигает предельного значения, заданного параметром BAD_RCPT_THROTTLE, программа sendmail выполняет односекундную за- держку после получения каждой команды RCPT, замедляя сбор адресов спамерской про- граммой. Для того чтобы задать это предельное значение равным 3, используйте следую- щую команду. define (' confBAD_RCPT_THROTTLE ’, ' 3 ’) Параметр MAX_RCPTS_PER_MESSAGE заставляет отправителя поставить дополнитель- ных получателей в конец очереди. Это простая форма серого списка для сообщений, имеющих подозрительно много получателей. Параметры ratecontrol и conncontrol позволяют установить для каждого ком- пьютера или каждой сети скорость приема входящих соединений и количество одно- временно устанавливаемых соединений соответственно. Оба параметра можно задать в файле /etc/mail/access, чтобы указать пределы и домены, к которым они относят- ся. Первый параметр сопровождается дескриптором ClientRate: в поле ключа, а вто- рой — дескриптором ClientConn:. Для того чтобы включить режим контроля скорости, вставьте следующие строки в свой файл с расширением .тс.12 FEATURE(4 ratecontrol’, 'nodelay','terminate’) FEATURE('conncontrol’, 'nodelay’, 'terminate') Затем добавьте в свой файл /etc/mail/access список компьютеров или сетей, под- лежащих контролю, а также соответствующие предельные значения. Например, строки ClientRate:192.168.6.17 2 ClientRate:170.65.3.4 10 ограничивают узлы 192.168.6.17 и 170.65.3.4 двумя новыми соединениями в минуту и де- сятью новыми соединениями в минуту соответственно. Строки ClientConn:192.168.2.8 2 ClientConn:175.14.4.1 7 ClientConn: 10 устанавливают следующие пределы: два соединения для узла 192.168.2.8, семь — для узла 175.14.4.1 и десять — для одновременных соединений со всеми другими узлами. Еще одним интересным параметром является greet pause. Когда удаленный транс- портный агент соединяется с вашим сервером sendmail, протокол SMTP заставляет 12 Наряду с инструкцией FEATURE ('access_db').
Глава 20. Электронная почта 841 его подождать и поприветствовать ваш сервер, прежде чем начать обмен сообщениями. Однако программы рассылки спама обычно мгновенно выдают команду EHLO/HELO. Это поведение частично объясняется плохой реализацией протокола SMTP в инструмен- тах для рассылки спама, но это может экономить время для спамера. Как бы то ни было, такое поведение является подозрительным и называется “навязыванием” (“slamming”). Параметр greet pause заставляет программу sendmail подождать указанный пери- од времени в начале соединения, прежде чем поздороваться со новообретенным другом. Если удаленный транспортный агент не останавливается, чтобы правильно поздоро- ваться и обменяться командами EHLO или HELO в назначенный момент времени для знакомства, программа sendmail регистрирует ошибку и отказывается от выполнения последующих команд, поступающих от удаленного транспортного агента. Вы можете задать паузу для приветствия с помощью следующей записи в файле с рас- ширением .тс. FEATURE('greet_pause', '700’) Эта строка устанавливает задержку в 700 миллисекунд в начале каждого нового сое- динения. Вы можете устанавливать задержки для узлов или сетей с помощью префикса GreetPause: в базе доступа, но большинство сайтов для этого использует общее значе- ние для этого параметра. Конфигурирование почтовых фильтров в программе sendmail Почтовые фильтры в общих чертах были описаны в разделе 20.5. Этот раздел посвя- щен вопросам конфигурирования почтовых фильтров в программе sendmail. Почтовые фильтры управляются директивами INPUT_MAIL_FILTER и MAIL FILTER и контролиру- ются опциями MILTER MACROS *, которые позволяют указывать, какие фильтры долж- ны применяться на той или иной стадии SMTP-диалога. Например, инструкция INPUT_MAIL_FILTER(’filtername', 'S=mailer:/var/run/filtername.socket’) перенаправляет все входящие сообщения программе /etc/mail/filtername через со- кет, указанный во втором аргументе. Ниже приведен боле реалистичный пример использования почтовых фильтров для соединения с программой SpamAssassin через локальный доменный сокет и для проверки подписей DKIM с помощью программы dkim-filter через сокет TCP на порту 8699. dnl # Enable SpamAssassin INPUT_MAIL_FILTER('spamassassin', 'S=local:/var/run/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m') dnl # Enable DomainKeys and DKIM INPUT_MAIL_FILTER('dkim-filter', 'S=inet:8 69 90127.0.0.1, T=R:2m') define('confMILTER_MACROS_CONNECT', ' j , {daemon_name}') define('confMILTER_MACROS_ENVFROM', 'i, {auth_type}') Две последние инструкции устанавливают параметры, передаваемые почтовым филь- трам в начале сеанса связи и после команды MAIL FROM соответственно. Для получения более подробной информации обратитесь к документации в файле libmilter/README или HTML-файлам в каталоге libmilter/docs дистрибутивного пакета sendmail. Файл README содержит обзор и простой пример фильтра, регистри- рующего сообщения в файле. Файлы в каталоге docs описывают интерфейс библиотеки и содержат информацию о том, как использовать разные вызовы для сборки своих соб-
842 Часть II. Работа в сети ственных фильтрующих программ. Отличным источником информации является также сайт milter.org. Соединение сканера amavisd и программы sendmail Amavisd — это внешний коммерческий сканер вирусов и спама, описанный в раз- деле 20.6. В этом разделе показано, как его использовать в сочетании с программой sendmail. Легче всего соединить программу sendmail и сканер amavisd с помощью двух по- чтовых серверов: один получает почту из Интернета и передает ее сканеру amavisd, а второй, работающий только в режиме постановки в очередь, получает отсканированные сообщения от сканера amavisd и передает их дальше либо для локальной доставки, либо в Интернет. Сканер amavisd в этой схеме расположен посредине, действуя как концен- тратор MAIL HUB для входящей почты и узел SMART HOST для исходящей. К сожалению, эта схема сканирует сообщения после постановки писем в почтовую очередь, после того как программа sendmail уже приняла почту для доставки. Проце- дура использования сканера amavisd до постановки писем в почтовую очередь описана в файле README .milter в документации дистрибутивного пакета amavisd-new. Основные строки конфигурации сервера, взаимодействующего с Интернетом, — это те строки, которые передают всю почту на прослушку порта 10024 с помощью сканера amavisd. FEATURE('stickyhost’) define('MAIL_HUB', 'esmtp:[127.0.0.1]’) define('SMART_HOST’, 'esmtp:[127.0.0.1]’) define('confDELIVERY_MODE1, ' q ’) define('ESMTP_MAILER_ARGS’, 'TCP $h 10024’) DAEMON_OPTIONS('Name=receivingMTA') Последняя строка намного облегчает отладку конфигурации, поскольку мы можем сказать, какой процесс (получения писем программой sendmail, передачи писем про- граммой sendmail или процесс сканирования, выполняемый программой amavisd) за- регистрировал сообщения. После сканирования программа amavisd передает сообщения процессу прослушива- ния порта 10025 (а не порта 25, как обычно) с помощью программы sendmail, работаю- щей только в режиме постановки в очередь. С этого момента обработчик очереди либо выполнит полную локальную доставку, либо вернет сообщения в Интернет. На передаточном сервере инструкция DAEMON_OPTIONS('Addr=127.0.0.1, Port=10025, Name=transmittingMTA’) сообщает программе sendmail, что она должна прослушивать порт 10025 в ожидании сообщений, поступающих от сканера amavisd. Эта программа должна регистрировать любую информацию или сообщение об ошибке, содержащее имя transmittingMTA, что- бы отличать его от сообщений, содержащих имя receivingMTA. Существует много настроек (например, пределы, регулирующие производитель- ность), позволяющих обеспечить согласованную работу двух экземпляров программы sendmail. Для того чтобы точно решить, какие проверки следует осуществить, какой процесс выполнить и в каком порядке они должны следовать друг за другом, необходи- мо хорошенько подумать. Полезным источником информации является файл README_FILES/README . sendmail-dual в дистрибутивном пакете amavisd-new.
Глава 20. Электронная почта 843 20.11. Безопасность и программа sendmail С началом лавинообразного роста Интернета программы наподобие sendmail, при- нимающие произвольные входные данные и направляющие их локальным пользовате- лям, в файлы или в интерпретаторы команд, превратились в излюбленные мишени для хакеров. В настоящее время программа sendmail, наряду со службой DNS и даже про- токолом IP, начала “обзаводиться” встроенными средствами аутентификации и шифро- вания, позволяющими решать основные проблемы безопасности. Программа sendmail поддерживает систему SMTP-аутентификации и шифрование по протоколу TSL (Transport Layer Security — безопасность транспортного уровня), ранее известному как протокол SSL (Secure Sockets Layer — протокол защищенных сокетов). Протокол TSL содержит шесть новых конфигурационных параметров, связанных с фай- лами сертификатов и ключей. Кроме того, в базе доступа появились новые операции сравнения, связанные с аутентификацией. В этом разделе мы опишем модель безопасности программы sendmail и систему для защиты конфиденциальности. Затем кратко рассмотрим протоколы TLS и SASL (Simple Authentication and Security Layer — простой протокол аутентификации и защиты) й их применение в сочетании с программой sendmail. Прежде чем довериться содержимому, скажем, файлов .forward или aliases, про- грамма sendmail тщательно проверяет права доступа к ним. Как правило, подобшЯ£ меры предосторожности действительно необходимы, но иногда все же требуетсяГЙх ослабить. С этой целью в программе появился параметр DontBlameSendmail, название которого (“не осуждай sendmail”) подсказывает системным администраторам, что по- сле изменения опции действия программы станут небезопасными. У параметра DontBlameSendmail очень много возможных значений (по последним подсчетам, 55). По умолчанию он равен safe. Полный список значений можно найти в файле doc/op/op.ps дистрибутива sendmail или в книге О’Рейли, посвященной про- грамме sendmail. Впрочем, лучше всего оставить этот параметр заданным по умолчанию. Владельцы файлов Программа sendmail различает трех специальных пользователей: Defaultuser, RunAsUser и TrustedUser. По умолчанию все агенты доставки работают от имени пользователя Defaultuser, если не установлены специальные флаги. При наличии в файле /etc/passwd учет- ной записи mailnull, sendmail или daemon именно эта запись будет соответство- вать пользователю Defaultuser. В противном случае пользователю будут соответ- ствовать значения UID и GID, равные 1. Мы рекомендуем применять учетную запись mailnull. Добавьте ее в файл /etc/passwd со звездочкой в поле пароля, с пустым по- лем идентификатора команд, с пустым полем начального каталога и группой mailnull. Понадобится также добавить запись mailnull в файл /etc/group. Этой учетной запи- си не должны принадлежать никакие файлы. Если программа sendmail не выполняется с правами суперпользователя, для агентов доставки должен быть установлен бит setuid. Если задан пользователь RunAsUser, программа sendmail работает от его имени, иг- норируя пользователя Defaultuser. Если программа запускается с установленным би- том setgid (идентификатор группы меняется на smmsp), то агент подачи почты (програм- ма sendmail) передает транспортному агенту (другой экземпляр sendmail) сообщения по протоколу SMTP. Транспортный агент sendmail не имеет установленного бита setuid, но вызывается с правами корневого пользователя из сценариев запуска системы.
844 Часть II. Работа в сети Пользователю RunAsUser соответствует значение UID, которое присваивается про- грамме sendmail при открытии сокета, подключенного к порту 25. Привилегированные порты (их номера не превышают 1024) могут открываться только суперпользователем, следовательно, программа sendmail первоначально должна работать от имени поль- зователя root. Тем не менее по завершении указанной операции программа может взять себе другое значение UID. Это уменьшает вероятность возможных злоупотребле- ний, если программа sendmail запускается обманным путем. Не применяйте средство RunAsUser на компьютерах, где есть другие пользовательские учетные записи и службы; оно предназначено для брандмауэров и бастионных узлов.13 По умолчанию программа продолжает выполняться от имени пользователя root. Если же учетная запись RunAsUser не эквивалентна суперпользователю, придется мно- гое изменить. Пользователю RunAsUser должна принадлежать очередь почтовых со- общений, он должен иметь возможность читать все подключаемые файлы и файлы баз данных, запускать нужные программы и т.д. На поиск всех файлов и каталогов, владелец которых должен быть изменен, может уйти несколько часов. Пользователь TrustedUser может владеть файлами баз данных и псевдонимов. Ему разрешается запускать демон и перестраивать файл aliases. Этот пользователь необ- ходим для поддержки графических надстроек к программе sendmail, которые вынуж- дены предоставлять ограниченный административный контроль определенным пользо- вателям. Обязательно контролируйте учетную запись, соответствующую пользователю TrustedUser, поскольку через нее можно легко получить права суперпользователя. Пользователь TrustedUser не соответствует классу TRUSTED USERS, который опреде- ляет, кто имеет право менять заголовок “From” сообщений14. Права доступа Для безопасности программы sendmail большое значение имеют права доступа к определенным файлам и каталогам. Установки, приведенные в табл. 20.13, считаются безопасными. Таблица 20.13. Владельцы и права доступа для каталогов, связанных с программой sendmail /var/spool/clientmqueue smmsp:smmsp 770 Почтовая очередь для начальной подачи по- чты /var/spool/mqueue RunAsUser 700 Очередь почтовых сообщений /, /var, /var/spool root 755 Родительские каталоги подкаталога mqueue /etc/mail/* TrustedUser 644 Таблицы, конфигурационный файл, файлы псевдонимов /etc/mail TrustedUser 755 Родительский каталог для разных файлов /etc root 755 Путь к каталогу mail Программа sendmail не будет читать файлы с “ослабленными” правами доступа (на- пример, файлы, открытые для записи, а также файлы, находящиеся в каталогах, которые открыты для записи). Программа sendmail тщательно проверяет путь к любому фай- 13 Бастионные узлы — это специально укрепленные узлы, предназначенные для отражения атаки и размещенные в зоне DMZ или за пределами брандмауэра. 14 Средство TRUSTED USERS обычно применяется для поддержки программ, работающих со списками рассылки.
Глава 20. Электронная почта 845 лу псевдонимов, что иногда сказывается на управлении списками рассылки. Для того чтобы проверить настройки, запустите команду sendmail -v -bi. Флаг -bi заставляет программу проинициализировать базу данных псевдонимов и выдать предупреждение, если права доступа не подходят. Операционная система Solaris имеет удобную программу check-permissions, SOLariS которая соответствует стандартам безопасности программы sendmail и со- общает об опасных путях и файлах. Она прослеживает директивы include в файлах псевдонимов и . forward. Кроме того, она может проверять либо вы- зывающих пользователей, либо всех пользователей, в зависимости от флагов командной строки. Программа sendmail больше не читает файл . forward, если число ссылок на него больше единицы, а путь к каталогу небезопасен (права доступа ослаблены). На этом не так давно попалась Эви Немет, когда ее файл . forward, представляющий собой жесткую ссылку либо на файл . forward. to. boulder, либо на файл . forward. to. sandiego, перестал поддерживать пересылку почты от небольшого узла, с которого ей иногда при- ходили сообщения. Прошли месяцы, прежде чем Эви поняла, что это происходит по ее вине и фраза “Я никогда не получала от вас почту” не является оправданием. Отключить многие ограничения на доступ к файлам можно с помощью опции DontBlameSendmail. Но не забывайте о безопасности. Безопасная пересылка почты в файлы и программы В качестве агента программной доставки мы рекомендуем применять утилиту smrsh, а не /bin/sh; агентом локальной доставки лучше назначить утилиту mail. local, а не /bin/mail. Обе утилиты входят в дистрибутив sendmail. Для их активизации необхо- димо добавить в mc-файл следующие директивы. FEATURE (' smrsh' t ' каталог1) FEATURE (' local_lmtp ’, ' каталог1) Если каталоги не указаны, по умолчанию принимается каталог /usr/libexec. Можно воспользоваться опцией confEBINDlR, чтобы изменить стандартный каталог исполняемых файлов. Найти агентов доставки вам поможет табл. 20.14. Таблица 20.14. Местоположение ограниченных агентов доставки программы sendmail Опера^нна^и^гема sendmail /usr/libexec /usr/libexec /usr/adm Ubuntu /usr/lib/sm.bin /usr/lib/sm.bin /usr/adm SUSE /usr/lib/sendmail.d/bin /usr/lib/sendmail.d/bin - Red Hat /usr/sbin - /etc/smrsh Solaris /usr/lib /usr/lib /var/adm HP-UX /usr/sbin - /var/adm AIX /usr/sbin - /var/adm a а Этот каталог не существует ни в системе HP-UX, ни в системе AIX, поэтому его необходимо создать. Утилита smrsh — это ограниченная оболочка, запускающая программы, находящие- ся только в одном каталоге (по умолчанию — /usr/adm/sm.bin). Она игнорирует за- данные пользователями имена каталогов и деревьев, выполняя поиск требуемых команд
846 Часть II. Работа в сети в собственном безопасном каталоге. Утилита smrsh также блокирует некоторые метасим- волы интерпретатора команд, в частности — оператор переадресации входного потока. В каталоге sm.bin допускается наличие символических ссылок, поэтому создавать копии программ не потребуется. Программа vacation — подходящий кандидат для включения в каталог sm.bin. Не размещайте в нем программу procmail; она небезопасна. Приведем несколько примеров команд вместе с их возможными интерпретациями утилитой smrsh. vacation eric # Выполняется команда /usr/adm/sm.bin/vacation cat /etc/password # Отклоняется, т.к. cat нет в каталоге sm.bin vacation eric < /etc/password # Отклоняется, т.к. оператор < не разрешен Опция SafeFileEnvironment программы sendmail контролирует, куда можно за- писывать сообщения, если в файле aliases или . forward задано перенаправление почты в файл. Это опция заставляет программу осуществить системный вызов chroot, вследствие чего корневым каталогом файловой системы станет не /, a /safe или любой другой указанный в опции каталог. Например, если в файле псевдонимов задается пере- направление почты в файл /etc/passwd, то на самом деле сообщения будут записы- ваться в файл /safe/etc/passwd. Опция SafeFileEnvironment защищает также файлы устройств, каталоги и другие специальные файлы, позволяя записывать почту только в обычные файлы. Это полезно не только в плане улучшения безопасности, но и с точки зрения борьбы с ошибками пользователей. В некоторых системах значение этой опции задается равным /home, что открывает доступ к начальным каталогам пользователей, но оставляет системные файлы вне досягаемости. Агенты доставки тоже могут запускаться в виртуальном каталоге. Опции безопасности В программе sendmail есть опции безопасности, которые определяют следующее: • какие сведения о системе можно узнать из внешнего мира по протоколу SMTP; • что требуется от узла на противоположном конце SMTP-соединения; , • могут ли пользователи просматривать или обрабатывать очередь почтовых со?, общений. В табл. 20.15 приведены текущие значения опций безопасности. Самую последнюю информацию можно узнать в файле doc/op/op.ps дистрибутива. Таблица 20.15. Значения переменной PrivacyOption public needmailhelo Проверка конфиденциальности/безопасности не осуществляется Требуется SMTP-команда HELO (идентифицирует удаленный узел) noexpn novrfy needexpnhelo needvrfyhelo noverba restrictmailq Не допускается SMTP-команда EXPN Не допускается SMTP-команда VRFY Не допускается раскрытие адреса (команда EXPN) без команды НЕЮ Не допускается проверка адреса (команда VRFY) без команды НЕЮ Не допускается “многословный” режим команды EXPN Только пользователи группы, которой принадлежит каталог mqueue, могут просма- тривать очередь сообщений
Глава 20. Электронная почта 847 Окончание табл, 20.15 Значений ХСХ restrictqrun restrictexpand noetrn**’ authwarnings Только владелец каталога mqueue может обрабатывать очередь сообщений Ограничивается объем информации, выдаваемой при наличии флагов -bv и -v6 Не допускается асинхронная обработка очереди К сообщениям добавляется заголовок “Authentication-Warning” (это установка по умолчанию) noreceipts nobodyreturn Запрещается выдача кодов состояния доставки При выдаче кода состояния доставки не возвращается тело сообщения goaway Отменяются все статусные SMTP-запросы (EXPN, VRFYи т.д.) а В “многословном” режиме команда EXPN отслеживает переадресацию в файле . forward и выдает допол- нительную информацию о местонахождении пользовательской почты. Необходимо включать опцию noverb или, еще лучше, поехрп на любом компьютере, имеющем выход во внешний мир. 6 Если только программа не выполняется от имени пользователя root или TrustedUser. в ETRN — это команда протокола ESMTP, которая используется узлами с коммутируемым доступом. Она за- прашивает обработку очереди только для сообщений данного узла. Мы рекомендуем сделать в mc-файле “консервативные” установки. define('confPRIVACY_FLAGS', ''goaway, authwarnings, restrictmailq, restrictqrun’’) По умолчанию установлен лишь параметр authwarnings. Обратите внимание на двойные кавычки: некоторые версии препроцессора т4 требуют этого для предотвраще- ния ненужной интерпретации запятых в списке значений. В системах Red Hat, Solaris и AIX по умолчанию принята установка authwarnings, в системах SuSE и Ubuntu — уста- новки authwarnings, needmailhelo, novrfу, поехрп и noverb, а в системе HP-UX — restrictqrun, goaway и authwarnings. Самыми безопасными являются установки системы HP. Выполнение программы sendmail в виртуальном каталоге (для настоящих параноиков) Те, кого беспокоит влияние программы sendmail на файловую систему, могут за- пускать ее в виртуальной среде. Создайте в этом каталоге минимальную файловую си- стему, включив в нее файл /dev/null, важные файлы каталога /etc (passwd, group, resolv.conf, sendmail. cf, таблицы баз данных, mail/*), необходимые программе sendmail совместно используемые библиотеки, исполняемый файл sendmail, каталог очереди почтовых сообщений и журнальные файлы. Вероятно, вы захотите поэкспери- ментировать со списком. Для запуска программы sendmail в виртуальном окружении используйте команду chroot. # sudo chroot /jail /usr/sbin/sendmail -bd -q30m Отражение атак типа "отказ от обслуживания” Атаки типа “отказ от обслуживания” невозможно предотвратить, потому что нельзя заранее предсказать, является ли сообщение оружием атаки или нет. Злоумышленники могут поступать по-разному, например переполнять SMTP-порт ложными запросами На подключение, “забивать” разделы диска гигантскими сообщениями, засорять вы-
848 Часть II. Работа в сети ходные соединения, бомбардировать систему почтовыми сообщениями и т.д. В про- грамме sendmail имеются конфигурационные параметры, позволяющие ограничить влияние этих атак на систему, но в результате может пострадать и легитимная почта. Определенную помощь может оказать и новая библиотека функций фильтрации почты. Параметр MaxDaemonChildren ограничивает число процессов sendmail. Он не по- зволяет программе захватить все вычислительные ресурсы системы, но зато дает воз- можность хакерам очень легко одолеть службу SMTP. Опция MaxMessageSize защищает каталог очереди от переполнения, но если задать значение опции слишком маленьким, жертвами могут оказаться обычные сообщения. (Следует уведомить пользователей о су- ществующем пределе на размер сообщения, чтобы они не удивлялись, если письмо вдруг вернется обратно. Этот предел обычно устанавливается достаточно большим.) Параметр ConnectionRateThrottle задает предельно допустимое число соединений в секунду. Это может привести к небольшому замедлению работы программы sendmail. Наконец, опция MaxRcpts PerMess age определяет максимальное число получателей сообщения. Программа sendmail всегда умела отказываться от приема сообщений (опция REFUSE LA) и ставить сообщения в очередь (опция QUEUE LA) в зависимости от уровня загруженности системы. Дополнительный параметр DELAY LA позволяет обработку по- чты, но с меньшей скоростью. Подробности изложены в разделе 20.12. Несмотря на все меры предосторожности, трудно предотвратить ситуацию, когда кто-то начинает бомбардировать систему письмами. Это может стать очень неприятной проблемой. SASL: простой протокол аутентификации и защиты Программа sendmail поддерживает систему SMTP-аутентификации, которая опре- делена в документе RFC2554. Она основана на технологии SASL (Simple Authentication and Security Layer — простой протокол аутентификации и защиты), представляющей со- бой систему совместного использования секретного ключа между двумя узлами (см. до- кументы RFC4422 и RFC4752). В ней нужно явно задавать пары серверов, осуществляю- щих взаимную аутентификацию. Обычно она используется между пользовательскими агентами и агентами доставки или между агентами доставки и транспортными агентами внутри сайта. SASL — это базовый механизм аутентификации, который может быть встроен в ряд других протоколов. Механизм SASL (это библиотека) основан на двух концепциях: ав- торизации идентификатора (например, регистрационного имени) и аутентификации идентификатора (например, пароля). Она может применять их для распределения прав доступа к файлам, паролям, сертификатам протокола Kerberos и т.д. Библиотека функ- ций SASL состоит из двух частей: модуля аутентификации (например, регистрационно- го имени) и модуля шифрования (например, пароля). Для использования библиотеки SASL в сочетании с программой sendmail необходимо получить копию библиотеки Cyrus SASL по адресу: ftp: / /ftp.andrew.cmu.edu/pub/cyrus-mail. TLS: безопасность транспортного уровня Еще одна система аутентификации и шифрования — TLS — определена в документе RFC3207. Она реализована в программе sendmail в виде расширения протокола SMTP под названием STARTTLS. Можно даже одновременно использовать протоколы SASL и TLS. Протокол TLS труднее настроить, так как требуется поддержка со стороны центра сертификации. Можно заплатить компании VeriSign, которая выдаст вам необходимые
Глава 20. Электронная почта 849 сертификаты (подписанные открытые ключи, идентифицирующие их предъявителя), или организовать собственный центр сертификации. В процессе ретрансляции почты и приема запросов от других узлов аутентификация осуществляется не на основе имени узла или его IP-адреса, а путем обмена ключами. Записи вида TLS_Srv:secure.example.com ENCR: 112 TLS_Clt:laptop.example.com PERM+VERIFY:112 в базе доступа указывают на то, что используется механизм STARTTLS. Почта, направ- ляемая в домен secure. example. com, должна шифроваться, как минимум, 112-бито- выми ключами. Почта, поступающая от узла secure. example. com, будет приниматься лишь в том случае, если клиент пройдет процедуру аутентификации. Грег Шапиро (Greg Shapiro) и Клаус Ассман (Claus Assmann) из компании Sendmail, Inc., ведут прекрасные веб-страницы, посвященные настройке протоколов SASL и TLS в программе sendmail: sendmail.org/~gshapiro и www.sendmail.org/~ca. Ссылка index на сайте ~са особенно полезна. 20.12. Производительность программы sendmail Программа sendmail имеет ряд конфигурационных опций, предназначенных для повышения производительности. Мы упоминали их ранее в главе, а теперь попытаем- ся более подробно описать наиболее важные из них. Эти опции и средства необходимо учитывать при развертывании крупномасштабной почтовой системы. Но, конечно,’ если пропускная способность системы должна составлять порядка миллиона сообщений в час, имеет смысл приобрести коммерческую версию программы sendmail, предлагае- мую компанией Sendmail, Inc. Режимы доставки Программа sendmail имеет четыре режима доставки: фоновый, интерактивный, с постановкой в очередь и отложенный. Каждый из них представляет собой определенный компромисс между временем задержки и пропускной способностью. В фоновом режиме сообщение доставляется немедленно, но для этого программа должна породить новый процесс. В интерактивном режиме тоже поддерживается немедленная доставка, но ее осуществляет тот же процесс, поэтому удаленный узел вынужден дожидаться результа- тов. В режиме очереди поступившее сообщение помещается в буфер, откуда позднее его извлекает обработчик очереди. Режим отложенной доставки аналогичен предыдущему, но в очередь заносятся также все операции поиска в таблицах, в DNS, в файлах aliases и . forward. Интерактивный режим применяется редко. Фоновый режим обеспечивает меньшее время задержки, а в режиме отложенной доставки и режиме очереди выше про- пускная способность. Режим доставки задается с помощью опции conf DELIVERY_MODE. По умолчанию принят фоновый режим. Группы очередей и разбивка конвертов Группы очередей позволяют создавать несколько очередей для исходящей почты и управлять атрибутами каждой группы по отдельности. Группа очередей используется для разбивки конвертов, позволяя распределить конверт с множеством получателей (напри- мер, сообщение, направленное списку рассылки) между несколькими группами очере- дей. Группа очередей имеет несколько примитивов конфигурации. Подробности можно
850 Часть II. Работа в сети найти в книге О’Рейли Sendmail или в файле cf/README. Это помогает решить проблему, связанную с нахождением слишком большого числа файлов в одном почтовом каталоге. Обработчики очередей Программа sendmail порождает копии самой себя при транспортировке сообще- ний. Можно задавать, сколько копий программы должно выполняться в любой момент времени и даже сколько из них должно быть связано с каждой группой очередей. Это позволяет системным администраторам перераспределять нагрузку между программой sendmail и операционной системой на крупных почтовых концентраторах. Число демонов sendmail, обрабатывающих каждую очередь, определяется тремя оп- циями. • MAX_DAEMON_CHILDREN — задает общее число демонов sendmail, которые могут выполняться одновременно, включая те, что обрабатывают очередь, и те, что при- нимают входящую почту. • MAX_QUEUE—CHILDREN — задает общее число одновременно выполняющихся об- работчиков очереди. • MAX_RUNNERS—PER—QUEUE — задает стандартный предел числа обработчиков одной очереди, если в определении группы отсутствует параметр Runners= (или R=). Контроль средней загруженности Программа sendmail всегда умела отказываться от приема сообщений или поме- щать сообщения в очередь, когда показатель средней загруженности системы становится очень высоким. К сожалению, измерение средней загруженности осуществляется раз в минуту, что не позволяет с достаточной степенью точности контролировать потребление программой sendmail ресурсов системы. Новая опция DELAY LA позволяет задать по- казатель средней загруженности, при котором программа должна замедлить свою рабо- ту: она будет делать секундную паузу между выполнением SMTP-команд текущего сое- динения и приемом нового запроса на подключение. По умолчанию опция равна нулю, т.е. режим отключен. Обработка недоставленных сообщений Недоставленные сообщения, остающиеся в почтовой очереди, способны существен- но снизить производительность почтового сервера. У программы sendmail есть ряд средств для борьбы с такими сообщениями. Наиболее эффективным из них является опция FALLBACK MX, задающая пересылку сообщений на другой компьютер, если их не удалось доставить с первой попытки. Эта опция позволяет главному серверу заниматься доставкой почты с правильными адресами, перепоручив “проблемную” почту резервно- му серверу. Вторая опция, HOST STATUS DIRECTORY, позволяет сохранять информацию о состоянии удаленных узлов между запусками обработчиков очереди. Опция FALLBACK MX позволяет существенно повысить производительность узла с большими списками рассылки, где неизбежно попадаются временно или постоянно недоступные адреса. Значением опции должен быть адрес компьютера, обрабатывающе- го отложенную почту. Например, команда define('confFALLBACKJMX', 'mailbackup.xor.com')
Глава 20. Электронная почта 851 задает пересылку всех сообщений, которые не удалось доставить с первого раза, на цен- тральный сервер mailbackup. xor. com для последующей обработки. Разрешается иметь несколько резервных серверов, если указанному узлу соответствует несколько записей MX в базе данных DNS. Параметр to inconnect задает паузу перед первой попыткой связи и отправки со- общения. Если эта пауза установлена короткой, то транспортный агент будет перегружен излишней работой. Однако она позволяет главному серверу обработать большой список рассылки за одну попытку в течение рекордно короткого времени. На резервном сервере можно воспользоваться опцией HOST STATUS DIRECTORY для решения проблемы повторных сбоев. Эта опция предписывает программе sendmail хранить статусный файл для каждого компьютера, на который посылается почта. На основании этой информации определяются приоритеты просмотра узлов при очеред- ной обработке очереди. Это позволяет реализовать схему отрицательного кеширования и хранить статусную информацию в промежутках между запусками обработчиков оче- редей. Результатом становится повышение производительности серверов, обрабатыва- ющих списки рассылки с большим числом неправильных адресов, хотя это и затратно с точки зрения файлового ввода-вывода. В следующем примере для хранения статусной информации выделяется каталог /var/ spool/mqueue/ .hoststat (его нужно предварительно создать). define('confHOST_STATUS_DIRECTORY’, '/var/spool/mqueue/.hoststat’) Если указать относительный путь к каталогу .hoststat, то он будет создан в ка- талоге очереди. Программа sendmail формирует собственную иерархию подкаталогов, основываясь на имени узла-получателя. Например, если почту по адресу evi@anchor. cs. Colorado. edu не удается доста- вить, то статусная информация будет занесена в файл anchor каталога /var/spool /mqueue/. hosts tat/edu. /Colorado. /cs. /, так как наиболее приоритетная запись MX узла anchor ссылается на него самого. Если бы записи MX задавали перенаправле- ние почты узла anchor на узел foo, то имя файла было бы foo, а не anchor. Еще одна возможность повышения производительности связана с заданием мини- мального времени пребывания сообщения в очереди. Сообщение, которое не удалось доставить с первого раза, помещается в очередь и остается там до тех пор, пока не будет осуществлена повторная попытка. Обычно это делается в сочетании с флагами команд- ной строки, задающими более частую обработку очереди (например, -q5m). Если обра- ботчик очереди “зависает” на каком-то сообщении, то через 5 минут запускается другой. Вся очередь обрабатывается блоками, формируемыми в зависимости от того, какие со- общения превысили минимальное время пребывания в очереди. Таким образом, запуск программы sendmail с флагами -bd -q5m и включение опции define('confMIN-QUEUE_AGE’, ' 27m’) в конфигурационном файле позволяют организовать более оперативную обработку почты. Настройка ядра Если UNIX- или Linux-систему планируется использовать в качестве крупного по- чтового сервера, придется модифицировать ряд параметров сетевой конфигурации ядра. В табл. 20.16 приведены параметры, которые необходимо изменить в системе Linux на загруженномтючтовом сервере, а также их рекомендуемые значения и значения, задан- ные по умолчанию.
852 Часть II. Работа в сети Таблица 20.16. Параметры ядра, которые требуется менять на крупных почтовых серверах Переменная (относительна катал ora^ioc/sys) По умолчанию Рекомендуется ~' net/ipv4/tcp_fin_timeout 180 30 net/ipv4/tcp_keepalive_time 7200 1800 net/core/netdev_max_backlog 300 1024 fs/filejnax 4096 16384 fs/inode_max 16384 65536 Л Для того чтобы настроить параметры для системы Linux, примените коман- Лв ду оболочки echo к соответствующей переменной в файловой системе /ргос. Общее описание этой процедуры приведено в разделе 14.11. Эти изменения можно сделать постоянными, выполнив команду sysctl или поместив соот- ветствующие команды echo в сценарий оболочки, который выполняется во время загрузки. Например, для того чтобы изменить значение тайм-аута FIN в протоколе TCP, мож- но выполнить следующую инструкцию. linux$ sudo sh -с "echo 30 > /ргос/sys/net/ipv4/tcp__fin__timeout"15 Для настройки сетевых параметров в системах Solaris и HP-UX используется soiaris команда ndd. Реализация системы HP-UX хорошо задокументирована, и ко- fXfft манда ndd -h (справка) дает точное описание каждой переменной, диапазона ее значений и значения, заданного по умолчанию. В системе Solaris команда ndd интерпретирует знак вопроса как попытку обратиться к документации, но перед знаком вопроса необходимо поставить обратную косую черту (ndd ?), чтобы защитить эту команду от оболочки. К сожалению, команда ndd в систе- ме Solaris просто перечисляет настраиваемые переменные, а не описывает их. Например, чтобы изменить значение тайм-аута FIN в системе HP-UX с помощью команды ndd, необходимо выполнить следующую команду. hp-ux$ sudo ndd -set tcp__fin__what__ timeout 30000 Единица тайм-аута для команды ndd задается в миллисекундах, поэтому указано чис- ло 30000, а не 30. В системе Solaris эта переменная называется tcp_f in_wait_2__f lush- interval. Интересно, что в справочной системе не указано никаких единиц измерения... но поисковая машина Google знает о них! Фактически этими единицами измерения яв- ляются миллисекунды, причем значение по умолчанию равно 675000. Более подробно команда ndd описана в разделах 14.13 (для системы Solaris) и 14.14 (для системы HP-UX). • Система AIX для настройки параметров сети использует команду по. Ин- струкция sudo по -L перечисляет настраиваемые переменные с указанием их минимального, максимального и текущего значений наряду с единицами их измерения. Если вы хотите, что изменения стали постоянными, используй- те команду по с флагом -р. В этом случае ваши изменения сохранятся после перезагрузки. 15 Если вы попытаетесь выполнить эту команду в виде sudo echo 30 > /ргос/sys/net/ ipv4/tcp__fin^timeout", то просто получите сообщение “permission denied”, потому что обо- лочка попытается открыть результирующий файл до выполнения команды sudo. Команда sudo должна применяться и к команде echo, и к перенаправлению. Следовательно, необходимо создать корневую подоболочку, в которой выполняется вся команда: sudo sh -с "echo...".
Глава 20. Электронная почта 853 Например, для задания параметра FIN_WAIT протокола TCP используется такая ко- манда. aix# sudo по -р -о tcp__finwait2=60 Единицей измерения этого параметра является половина секунды, поэтому значение 60 соответствует рекомендуемым 30 секундам. Команда по описана в разделе 14.15. 20.13. Сбор статистических данных, ТЕСТИРОВАНИЕ И ОТЛАДКА Конфигурация, основанная на применении препроцессора ш4, в определенной сте- пени тестируется автоматически. Низкоуровневая отладка, в основном, не требуется. Единственное, что невозможно контролировать при помощи флагов отладки, — это смысловые ошибки. В процессе подготовки главы мы обнаружили несколько по- добного рода ошибок в конфигурационных файлах. Иногда, к примеру, вызывалось средство без сопутствующего ему макроса (в частности, активизировалось средство masquerade envelope, но не включался режим маскирования адресов с помощью ма- кроса MASQUERADE AS). Или конфигурация программы sendmail не соответствовала настройкам брандмауэра, который определял, какую почту разрешается пропускать. Нельзя проектировать почтовую систему саму по себе. Ее необходимо согласовать с имеющимися записями MX базы данных DNS и настройками брандмауэра. Мониторинг очереди С помощью команды mailq (эквивалент команды sendmail -bp) можно просма- тривать состояние сообщений, помещенных в очереди. Сообщение могут помещаться в очередь после доставки или при неудачной попытке доставки. Команда mailq выводит на печать отчет о файлах /var/spool/mqueue в любой заданный момент. Результат позволяет определить, почему сообщение могло быть за- держано. Если выясняется, что в системе увеличивается поток почтовых сообщений, системный администратор может отследить попытки программы sendmail разобрать этот завал. По умолчанию существует две очереди: для сообщений, полученных через порт 25, и для сообщений, полученных через порт 587 (очередь подачи для клиентов). Клиентскую очередь можно увидеть с помощью команды mailq -Ас. Ниже приведен типичный результат работы команды mailq. В отчете указано, что доставки ожидают три сообщения. $ sudo mailq /var/spool/mqueue (3 requests) -----Q-ID-----—Size—---------Q-Time-------------------Sender/Recipient k623gYYk008732 23217 Sat Jul 1 21:42 MAILER-DAEMON 8BITMIME (Deferred: Connection refused by agribusinessonline.com.) <Nimtz@agribusinessonline.com> k5ULkAHB032374 279 Fri Jun 30 15:46 <randy@atrust.com> (Deferred: Name server: k2wireless.com.: host name lookup fa) <relder@k2wireless.com> k5UJDm72023576 2485 Fri Jun 30 13:13 MAILER-DAEMON (reply: read error from mx4.level3.com.) <lfinistObbnplanet.com>
854 Часть II. Работа в сети Если вы считаете, что разбираетесь в ситуации лучше, чем программа sendmail, или просто хотите, чтобы программа sendmail попыталась немедленно повторить по- пытку доставки сообщений, попавших в очередь, можете заставить обработчик очереди выполнить команду sendmail -q. Если вы используете команду sendmail -q -v, то программа sendmail показывает результаты для каждой попытки доставки, что часто оказывается полезным для отладки. Программа sendmail повторяет доставку каждому обработчику очереди по истече- нии заданного интервала (как правило, каждые 30 минут). Журнальная регистрация Программа sendmail регистрирует сообщения об ошибках и своем состоянии через систему Syslog. Это делается от имени средства mail на уровнях от debug до crit. Все сообщения помечаются строкой “sendmail”. Изменить эту установку можно с помощью флага командной строки -L, что довольно удобно, если отлаживается одна из копий программы, в то время как остальные копии продолжают нормально работать. Ш Подробнее о системе Syslog рассказывалось в главе 11. Опция confLOG LEVEL, заданная в командной строке или в файле конфигурации, определяет уровень важности, который программа sendmail примет в качестве порого- вого. Высокие пороговые значения соответствуют низким уровням важности и обеспе- чивают регистрацию большего объема информации. В табл. 20.17 показано приблизительное соответствие между уровнями журнальной регистрации в программе sendmail и уровнями важности Syslog. Таблица 20.17. Соотношение между пороговыми уровнями программы sendmail и уровнями важности Syslog Порог Й S'//'! в ж г 0 Регистрация отключена 1 alert или crit 2 crit 3 err или warning 4 notice 5-11 info >=12 debug Напомним, что сообщение, зарегистрированное в системном журнале на конкретном уровне, относится как к этому уровню, так и ко всем находящимся выше уровням. Файл /etc/syslog.conf определяет окончательный пункт назначения каждого сообщения. Местоположения, заданные по умолчанию, показаны в табл. 20.18.16 Несколько программ могут обрабатывать регистрационные файлы sendmail, созда- вая конечные продукты, которые варьируются от простых количественных и текстовых таблиц (mreport) до сложных веб-страниц (Yasma). У системного администратора мо- жет возникнуть необходимость или желание ограничить доступ к этим данным или, по крайней мере, проинформировать пользователей о сборе данных о них. Например, про- 16 Было бы отлично, если бы кто-нибудь предпринял попытку стандартизации этих беспоря- дочных и, на первый взгляд, бессмысленных различий в сценариях, чтобы обеспечить их пере- носимость.
Глава 20. Электронная почта 855 грамма Yasma (Yet Another Sendmail Log Analizer) позволяет скрывать имя пользователя, которому адресована почта, попавшая в отчет. Таблица 20.18. Местоположения регистрационных журналов программы sendmail Система , • <( Ubuntu SUSE Red Hat Solaris HP-UX AIX /var/log/mail.log /var/log/mail /var/log/maillog /var/log/syslog и /var/adm/messages /var/adm/syslog/mail.log /var/log/mail 20.14. Почтовый агент Exim Агент транспорта и доставки почты Exim был написан в 1995 году Филипом Хейзелом из Кембриджского университета и распространен под универсальной общедоступной лицензией GNU. Текущий выпуск, версия 4.71 Exim, появился в конце 2009 года. В интерактивном доступе находятся тонны документации о программе, кроме того, было опубликовано несколько книг, написанных автором программного обеспечения. Запросы в поисковой системе Google о почтовом сервере Exim часто приводят к уста- ревшим, а иногда и вообще неприемлемым ответам, поэтому в первую очередь следует обращаться к официальной документации. В дистрибутивный пакет входит документ о спецификации и конфигурации (doc/spec. txt), состоящий из более чем 400 страниц. Этот документ также доступен на сайте exim. org в виде файла PDE Он представляет собой исчерпывающий справочник по программе Exim, который неукоснительно об- новляется с каждым новым выпуском. Существует два подхода к конфигурации постового сервера Exim: Debian и альтерна- тивный. Операционная система Debian использует препроцессор т4 и управляет своим собственным набором списков рассылки для поддержки пользователей. Мы не будем рассматривать расширения конфигурации, характерные для системы Debian. Начиная с выпуска 4.70 почтовый сервер Exim прекратил поддержку технологии DomainKeys (предшественницы DKIM) и по умолчанию в настоящее время предусма- тривает поддержку технологии DKIM. В реальных условиях обе системы могут и долж- ны сосуществовать, но система DKIM является стандартом IETF и в конце концов за- менит систему DomainKeys. Почтовый сервер Exim похожа на программу sendmail тем, что он реализован как единственный процесс, выполняющий все почтовые операции. Однако его авторы отка- зались от исторического багажа программы sendmail (поддержки устаревших форматов адресов, необходимости получать почту для узлов, не находящихся в Интернете, и т.д.). После компиляции в сочетании с инструментом для сканирования содержимого, посто- вый сервер Exim взаимодействует с популярными сканерами спама и вирусами, такими как SpamAssassin и ClamAV. Контроль правил реализован с помощью списков доступа, ко- торые могут принимать или отклонять сообщения или передавать их внешнему программ- ному обеспечению для сканирования. Доступ к фильтрам пользователей обеспечивается посредством записей в пользовательских файлах . forward. Многие аспекты функцио- нирования почтового сервера Exim определяются во время компиляции, при этом ориен- тирами являются база данных почтового сервера Exim и форматы хранения сообщений.
856 Часть II. Работа в сети Основные рабочие инструменты в почтовом сервере Exim называются маршрутиза- торами и транспортными средствами. Оба они относятся к общей категории “драйве- ров”. Маршрутизаторы решают, как сообщения должны быть переданы, а транспортные средства выбирают способ доставки. Маршрутизаторы — это упорядоченный список адресов, которые следует проверить, а транспортные средства — неупорядоченный на- бор способов доставки. Инсталляция почтового сервера EXIM Последнюю версию дистрибутивного пакета можно загрузить с сайта exim.org или, если ваш сайт работает под управлением системы Linux, из вашего любимого репози- тария пакетов. Место, где следует инсталлировать программу, идентификаторы пользо- вателей и другие параметры указаны в файлах README и src/EDITME. Файл EDITME со- держит более 1000 строк, которые по большей части представляют собой комментарии к процессу компиляции; требуемые изменения помечены. После редактирования сохра- ните файл как .. /Local/Makefile или . . /Local/Makef±1е-имя_ОС (если в одном и том же каталоге вы создаете конфигурации для разных операционных систем), а затем выполните команду make. Ниже перечислены несколько важных переменных (по нашему мнению) и предла- гаемые значения (по мнению разработчиков почтового сервера Exim) из файла EDITME. Первые пять строк являются обязательными, остальные только рекомендуются. BIN_DIRECTORY=/usr/exim/bin SP00L_DIRECT0RY=/var/spool/exim CONFIGURE_FILE=/usr/exim/configure SYSTEM_ALIASES_FILE=/etc/aliases EXIM_USER=ref:exim ROUTER_ACCE PT=ye s ROUTER_DNSLOOKUP=yes R0UTER_IPLITERAL=yes ROUTER_MANUALROUTE=yes ROUTER_QUERYPROGRAM=yes ROUTER_REDIRECT=yes TRANSPORT_APPENDFILE=yes # Место для исполняемого модуля exim # Каталог для почтовой очереди # Файл конфигурации программы Exim # Место для файлов псевдонимов # Пользователь программы EXIM # Драйверы маршрутизатора TRANSPORT_AUTOREPLY=yes TRANSPORT_PIPE=yes TRANSPORT_SMTP=yes SUPPORT_MAILDIR=yes SUPPORT_MAILSTORE=yes SUPPORT_MBX=yes LOOKU P_DBM=ye s LOOKUP_LSEARCH=yes LOOKUP_DNS DB=yes LOOKUP_CDB=yes USE_DB=yes DBMLIB=-ldb WITH_CONTENT_SCAN=yes EXPERIMENTAL_SPF=yes CFLAGS += -I/usr/local/include LDFLAGS += -lspf2 LOG_FILE_PATH=/var/log/exim_%slog # Драйверы транспорта # Разрешенные форматы почтовых ящиков # Системы управления базами данных # Метод последовательного поиска # Разрешает почти все поиски в DNS # Константа Дана Бернштейна для поиска # Использовать Berkeley DB (из README) # (из файла README) # Включает сканирование содержимого # через списки ACL # Включает поддержку SPF, нужна libspf2 # Из www.libspf2.org # Файлы журнала: file, syslog или оба
Глава 20. Электронная почта 857 LOG_FILE_PATH=syslog LOG_FILE_PATH=syslog:/var/log/exim_%slog EXICYCLOG_MAX=10 # Количество сохраненных файлов журнала # равно 10 Если вы собираетесь использовать маршрутизаторы и транспортные средства, то их следует скомпилировать в код. В настоящее время, которое характеризуется большими объемами доступной памяти, их можно использовать все вместе. Некоторые пути, заданные по умолчанию, являются нестандартными: например, бинарный файл в каталоге /usr/exim/bin и файл PID в каталоге /var/spool/exim. Эти параметры можно изменить в соответствии со своим инсталлированным программным обеспечением. Существует около десяти доступных систем управления базами данных, включая MySQL, Oracle, CDB17 и LDAP. Если вы хотите выбрать систему LDAP, то должны ука- зать переменную ldap lib type, которая сообщит программе Exim о том, что вы ис- пользуете библиотеку LDAP (вариантами являются системы Netscape, Solaris и разные версии системы OpenLDAP). Кроме того, вы должны указать путь для включения фай- лов и библиотек системы LDAP. В файле EDITME хранится информация о любых зависимостях, которые могут пона- добиться при выборе базы данных. В комментариях о зависимостях, которые сопрово- ждают каждую запись, есть фраза “(from README)”, в которой указан не файл src/ EDITME, а именно README. Файл EDITME имеет много дополнительных параметров безопасности, которые по- зволяют активизировать дополнительные возможности, такие как SMTP AUTH, TLS, SASL, РАМ, а также параметры управления владением файлом и разрешениями доступа к нему. Некоторые возможности программы Exim можно отключить на этапе компиля- ции, чтобы ограничить последствия ее взлома злоумышленниками. До завершения инсталляции мы рекомендуем прочитать файл EDITME полностью. Это даст вам приятное ощущение, что вы управляете выполнением программы посред- ством конфигурационного файла. Высокоуровневый файл README содержит много ин- формации о деталях, специфичных для операционных систем, которые иногда полезно включать в файл EDITME. Модифицировав файл EDITME и инсталлировав его в каталог Local/Makef ile, вы- полните команду make на вершине дистрибутивной иерархии, а затем инструкцию sudo make install. На следующем этапе необходимо протестировать исполняемый модуль exim и убедиться, что он доставляет почту так, как ожидается. Полезная тестовая доку- ментация содержится в файле doc/spec. txt. Убедившись, что почтовый сервер Exim работает правильно, свяжите модуль /usr/ sbin/sendmail с модулем exim, чтобы почтовый сервер Exim мог эмулировать тради- ционный интерфейс командной строки для обмена информацией с почтовой системой, используемой многими почтовыми агентами. Кроме того, следует сделать так, чтобы мо- дуль exim выполнялся во время загрузки. Загрузка почтового сервера Exim На компьютере, выполняющем роль концентратора почты, модуль exim обычно запускается во время загрузки в режиме демона и работает непрерывно, прослушивая порт 25 и принимая сообщения в рамках протокола SMTP. 17 CDB — это неизменяемая база данных Дана Бернштейна; она хорошо масштабируется.
858 Часть II. Работа в сети Детали загрузки операционной системы описаны в разделе 3.6. Как и программа sendmail, почтовый сервер Exim может иметь несколько режимов работы, и при за- пуске с разными флагами она выполняет разные функции. Флаги режима почтового сервера Exim похожи на флаги режима программы sendmail, потому что разработчики модуля exim очень стараются обеспечить совместимость при вызове почтовых агентов и других инструментов. Некоторые из наиболее распространенных флагов перечислены в табл. 20.19. Таблица 20.19. Распространенные флаги командной строки модуля exim флаг / ~ J?-"' ‘ - 7 - bd Запускается в режиме демона и прослушивает соединения на порту 25 - bf или -bF Запускается в пользовательском режиме или в режиме тестирования системного фильтра - bi Перестраивает хешированные псевдонимы (эквивалентен команде newaliases) - bp Выводит на печать почтовую очередь (эквивалентен команде mailq) - bt Включает режим тестирования адресов -bv Проверяет синтаксические ошибки в конфигурационном файле -^-категория Запускается в режиме отладки; очень гибкая конфигурация, учитывающая категории -q Запускает обработчик очереди (эквивалентен команде runq) Любые ошибки, существующие в конфигурационном файле, можно обнаружить на этапе синтаксического анализа с помощью команды exim -bv, но некоторые ошибки можно выявить только на этапе выполнения. Распространенная ошибка — неправильно расположенные скобки. Все нюансы, связанные с флагами и параметрами команды exim, включая обшир- ную информацию об отладке, можно найти на соответствующей справочной странице. Утилиты почтового сервера Exim Дистрибутивный пакет программы Exim включает в себя набор утилит, облегчающих слежение, отладку и проверку инсталляции. Ниже приведен список с кратким описани- ем каждой из этих утилит. Более подробная информация о них изложена в документации. • exiwhat — перечисляет выполняемые процессы программы Exim • exiqgrep — выполняет поиск в очереди • exiqsumm — создает отчет об очереди • exigrep — просматривает основной журнал • exipick — ищет сообщения по заданным критериям • exicyclog — чередует регистрационные файлы • eximstats — извлекает статистические показатели из журнала • exim_checkaccess — проверяет доступность заданного IP-адреса • exim_dbmbuild — создает файл DBM • exinext — извлекает информацию о повторных попытках • exim_dumpdb — распечатывает базу подсказок • exim_tidydb — очищает базу подсказок • exim_f ixdb — исправляет базу подсказок
Глава 20. Электронная почта 859 • exim_lock — блокирует файл почтового ящика • exilog — визуализирует регистрационные файлы на нескольких серверах Еще одна утилита, которая входит в пакет Exim, называется eximon. Она представ- ляет собой приложение для системы X Windows, которое выводит на экран состояние программы Exim, состояние ее очереди и остаток регистрационного файла. Как и основ- ной дистрибутивный пакет, она создается с помощью редактирования хорошо коммен- тированного файла EDITME в каталоге exim_monitor и выполнения команды make. Параметры, заданные по умолчанию для утилиты eximon, подобраны очень удачно, поэтому конфигурирование этого приложения обычно не вызывает затруднений. Кроме того, конфигурирование и управление очередью можно осуществлять с помощью гра- фического интерфейса утилиты eximon. Язык конфигурации программы Exim Рассматриваемый здесь язык конфигурации программы Exim (точнее, языки: один для фильтров, другой для регулярных выражений и так далее) напоминает довольно старый (разработанный в 1970-х годах) язык Forth.18 При первом чтении конфигурации программы иногда трудно отличить ключевые слова и имена параметров, которые явля- ются фиксированными в языке Exim, от имен переменных, определенных системными администраторами. Для того чтобы решить эту проблему, мы поставили перед именем каждой переменной префикс шу_. Несмотря на то что программа Exim рекламируется как легкая для конфигурирования и хорошо документированная, ее довольно сложно освоить. Раздел спецификации “Как программа Exim получает и доставляет почту” требует от новичков больших усилий. Тем не менее в ней изложены все основные концепции, лежащие в основе системы. После присвоения стандартной переменной конкретного значения язык Exim иногда активизирует определенные действия. В нем есть около 120 стандартных переменных, значения которых можно изменять в результате одного из действий. Эти переменные можно включать в условные выражения. Выражение для вычисления инструкции if и подобных ей может напомнить обрат- ную польскую запись, характерную для времен расцвета калькуляторов Hewlett-Packard. Рассмотрим простой пример. В строке acl_smtp_rcpt = ${if ={25}{$interface_port} {acl_check_rcpt} {acl_check_rcpt_submit} } установка параметра acl smtp rcpt вызывает реализацию списка управления досту- пом для каждого пользователя (т.е. выполнение команды SMPT RCPT). Значение, при- своенное этому параметру, может быть равным acl check rcpt или acl_check_rcpt__ submit, в зависимости от того, имеет ли переменная $interface_port значение 25. Мы не будем углубляться в детали языка конфигурации программы Exim, лишь по- советуем читателям обратиться к обширной документации. В частности, обратите вни- мание на раздел продолжения строки в спецификации программы Exim. Файл конфигурации программы Exim Поведением программы Exim во время выполнения управляет файл конфигурации, который обычно называется /usr/exim/configure. Его имя представляет собой одну 18 Для экспертов в компьютерных науках заметим, что этот язык является полным по Тьюрингу; в переводе для простых смертных это значит “мощный и сложный”.
860 Часть IL Работа в сети из обязательных переменных, задаваемых в файле EDITME и компилируемых в бинар- ный код. Файл конфигурации src/configure. default, поставляемый по умолчанию, сопро- вождается подробными комментариями и хорошо подходит для новичков. Мы рекомен- дуем не слишком далеко отклоняться от этого файла, пока вы не освоитесь с парадигмой Exim и не научитесь создавать более сложные конфигурации для специальных ситуаций. Разработчики программы Exim хорошо продумали поддержку наиболее распространенных ситуаций и создали вполне разумные конфигурации, предусмотренные по умолчанию. Рекомендуем также не изменять имена переменных, использованных в файле кон- фигурации, заданном по умолчанию, поскольку именно их ожидают увидеть в списках рассылки люди, которые будут отвечать на ваши вопросы о конфигурации. Программа exim выводит сообщения в поток и прекращает работу, если в вашем файле конфигурации есть синтаксическая ошибка. Однако она не выявляет все синтак- сические ошибки немедленно, поскольку не обращается к переменным, пока в них нет потребности. Порядок записей в файле конфигурации не совсем произвольный: раздел глобальных параметров конфигурации должен существовать и быть первым. Все остальные разделы являются необязательными и могут следовать в любом порядке. Перечислим некоторые разделы. • Глобальные параметры конфигурации (обязательны) • acl — списки управления доступом, фильтрующие адреса и сообщения • authenticators — раздел для параметров команды SMPT AUTH или протокола аутентификации TLS • routers — упорядоченная последовательность, предназначенная для определения места назначения сообщения • transports — определения драйверов, предназначенных для фактической доставки • retry — настройки правил для решения проблем, связанных с сообщениями • rewrite — правила перезаписи глобальных адресов • local scan — ловушка для спама Каждый раздел, за исключением первого, начинается с инструкции begin имя- раздела, например begin acl. Инструкции end имя-раздела не существует; призна- ком конца раздела является инструкция begin следующего раздела. Отступы между раз- делами облегчают чтение, но для программы Exim значения не имеют. Некоторые инструкции конфигурации присваивают имена объектам, которые впо- следствии будут использованы для управления потоками сообщений. Эти имена должны начинаться с буквы и содержать только буквы, цифры и символ подчеркивания. Если первым символом, отличающимся от разделителей строки, является символ #, то вся остальная часть строки считается комментарием. Это значит, что вы не можете поме- стить комментарий в строку, в которой помещается инструкция; он не будет распознан как комментарий, поскольку его первый символ не является символом #. Программа Exim позволяет включать файлы в любое место файла конфигурации. Су- ществует две формы включения файлов. .include absolute-path .include_if_exists absolute-path
Глава 20. Электронная почта 861 Первая форма генерирует ошибку, если файла нет. Несмотря на то что включение файлов позволяет сохранять небольшой объем конфигурационного файла, за время су- ществования сообщения они считываются несколько раз, поэтому может быть лучше просто включить их содержимое прямо в файл конфигурации. Глобальные параметры В разделе глобальных параметров задается множество данных, включая операцион- ные параметры (пределы, размеры, тайм-ауты, свойства почтового сервера на указанном узле), определения списков (локальных узлов, локальных узлов для перенаправления, удаленных доменов для перенаправления) и макросы (имя узла, контакт, местоположе- ние, сообщения об ошибках, банер SMTP). Параметры Параметры устанавливаются с помощью следующей синтаксической конструкции. имя_параметра = значение [я] Здесь значения могут быть булевыми или строчными, целыми или десятичными чис- лами, а также временными интервалами. Допускается также несколько значений, в этом случае они разделяются двоеточиями. Использование двоеточия в качестве разделителя создает проблему, потому что в адресах IPv6 оно является частью адреса. Решить эту проблему можно путем удваи- вания количества двоеточий, но намного проще и удобнее для чтения переопределить символ разделения и задать его равным < во время присвоения параметру его значения. Например, в следующих строках задаются значения параметра localhost interfaces, содержащие IPv4- и 1Ру6-адреса локального узла. local_interfaces = 127.0.0.1 : ::::1 local_interfaces = <; 127.0.0.1 ; ::1 Вторая форма, в которой в качестве разделителя используется точка с запятой, явля- ется более удобной для чтения и менее уязвимой для ошибок. Существует огромное количество параметров — в предметном указателе докумен- тации их более 500. А мы говорили, что программа sendmail была слишком сложной! Большинство параметров имеет вполне разумные значения по умолчанию, и все пара- метры имеют информативные имена. Для того чтобы легко находить новый параметр, целесообразно скопировать файл doc/spec. txt из дистрибутивного пакета в свой при- вычный текстовый редактор. Мы не собираемся описывать все параметры, а упомянем лишь те из них, которые встречаются в наших примерах. Списки Программа Exim использует четыре вида списков, которые объявляются с помощью ключевых слов hostlist, domainlist, addresslist и localpartslist. Ниже при- ведены два примера использования ключевого слова hostlist. hostlist my_relay_list = 192.168.1.0/24 : myfriend.example.com hostlist my_relay_list = /usr/local/exim/relay_hosts.txt Члены списка могут быть перечислены непосредственно в строке или загружены из файла. Если они указываются непосредственно в строке, то разделяются двоеточиями. Существует до 16 именованных списков каждого типа. В примерах, приведенных выше,
862 Часть II. Работа в сети мы включили все компьютеры в локальной сети /24 и указали конкретное имя локаль- ного компьютера. Символ @ может быть членом списка; он означает имя локального узла и помогает написать единственный обобщенный конфигурационный файл, который будет приме- няться на всех компьютерах вашей сети. Не менее полезным является обозначение @ [ ], которое означает все IP-адреса, прослушиваемые программой Exim; иначе говоря, все IP-адреса локального узла. Для того чтобы сослаться на список, следует просто поставить символ + перед его именем, если хотите сравнивать его члены, или !+, если хотите сравнивать элементы, не являющиеся членами списка; например, +my_relay_list. Между знаком + и именем списка пробела быть не должно. Списки могут содержать ссылки на другие списки, а знак ! означает отрицание. Списки, содержащие ссылки на переменные (например, $variable_name), замедляют обработку, потому что по умолчанию программа Exim не может кешировать результаты сравнений по списку. Макрос Макросы можно использовать для определения параметров, сообщений об ошиб- ках и т.д. Грамматический разбор макросов очень примитивен, поэтому вы не можете определить макрос, имя которого является подмножеством другого макроса, не получив непредсказуемых результатов. Синтаксис макроса выглядит следующим образом. MACRO_NAME = остальная часть строки Например, в первой из приведенных ниже строк определяется макрос с именем ALIAS QUERY, который выполняет поиск записи о псевдониме пользователя в базе дан- ных MySQL. Вторая строка демонстрирует использование макроса для выполнения ре- ального поиска, результат которого хранится в переменной с именем data. ALIAS_QUERY = select mailbox from user where login = ’${quote_mysql:$local_part}'; data = ${lookup mysql{ALIAS_QUERY}} Имена макросов не обязательно набирать только прописными буквами, но они должны начинаться с прописной буквы. Однако соглашение, по которому макросы со- стоят только из прописных букв, повышают ясность текста. Файл конфигурации может содержать директиву if def, вычисляющую макрос. Система использует ее, чтобы опре- делить, включать или нет фрагмент конфигурационного файла. Поддерживаются все возможные формы инструкции if def; все они начинаются с точки. ACL (списки управления доступом) Списки управления доступом фильтруют адреса входящих сообщений и либо при- нимают их, либо отклоняют. Программа Exim разделяет адреса входящих сообщений на локальную часть, соответствующую пользователю, и доменную, соответствующую доме- ну получателя. Списки управления доступом можно применять на разных стадиях обмена информа- цией по протоколу SMTP: HELO, MAIL, RCPT, DATA и т.д. Обычно список управления доступом требует строгого следования протоколу SMTP на стадии HELO, проверяет от- правителя и его домен на стадии MAIL, проверяет получателя на стадии RCPT и скани- рует содержимое сообщения на стадии DATA.
Глава 20. Электронная почта 863 Для того чтобы определить, какой список управления доступом должен применяться после каждой команды в протоколе SMTP, используется множество параметров с имена- ми, имеющими формат acl_smtp_команда. Например, параметр acl_smtp_rcpt озна- чает, что список управления доступом должен применяться к каждому адресу, указан- ному как получатель данного сообщения. Списки управления доступом можно задать в разделе acl в файле конфигурации, в файле, на который ссылается параметр acl smtp^команда, или в командной строке. “ Ниже приведен пример списка управления доступом my acl check rcpt. Его мож- но вызвать, присвоив это имя параметру acl_smtp_rcpt в разделе глобальных пара- метров в файле конфигурации. Если этот список управления доступом отвергает адрес, указанный в команде RCPT, то сервер отправителя должен отступить и больше не пы- таться отправлять сообщения на этот адрес. Другой параметр списка управления досту- пом — acl smtp data — применяется к сообщению после его получения, например для сканирования его содержимого. begin acl my_acl_check_rcpt: accept hosts = : control = dkim_disable_verify deny message = Restricted characters in address domains - +local_domains local_parts = Л[.] : л.*[@%!/|] deny message = Restricted characters in address domains = !+local_domains local_parts = л[./|] : л.*[@%!] : A.*/\.\./ accept local_parts = postmaster domains « +local_domains require verify = sender accept hosts = +relay_from_hosts control = submission control = dkim_disable_verify accept authenticated = * control = submission control = dkim_disable_verify require message = Relay not permitted domains = +local_domains : +relay_to_domains require verify = recipient accept Этот список управления доступом, заимствованный из документации к программе Exim, по умолчанию заканчивается командой accept; вы можете изменить свое реше- ние и сделать так, чтобы список управления доступом по умолчанию отклонял сообще- ние, как это обычно делают брандмауэры. Этому списку управления доступом по умол- чанию назначено имя aclcheckrcpt; вероятно, это имя изменять не следует (тем не
864 Часть II. Работа в сети менее мы изменили его, чтобы продемонстрировать, что оно задается вами, а не фикси- руется заранее параметрами конфигурации программы Exim). Первая строка, содержащая раздел accept и одно двоеточие, представляет собой пу- стой список. Пустой список удаленных узлов применяется в ситуациях, когда локаль- ный пользовательский почтовый агент (MUA) подает сообщение на стандартный вход транспортного агента. Если проверяемый адрес соответствует данному условию, список управления доступом принимает адрес и отключает проверку подписи DKIM, которая по умолчанию включена. Если же адрес не соответствует данному разделу address, то управление переходит к следующему разделу в определении списка. Первая строка конфигурации deny предназначена для сообщений, поступающих на ваши локальные домены. Она отклоняет любой адрес, в котором локальная часть (имя пользователя) начинается с точки или содержит специальные символы @, %, !, / или |. Вторая строка deny применяется к сообщениям, посланным во внешний мир вашими пользователями. Она также не допускает использование некоторых специальных симво- лов и их комбинаций в качестве части адреса, поскольку это свидетельствует о том, что ваши компьютеры были заражены вирусом или другими вредоносными программами. В прошлом такие адреса использовались спамерами для запутывания списков управления доступом или для создания проблем в системе безопасности. В целом, если вы хотите использовать выражения $local_parts (например, в каче- стве пользовательского имени получателя) в имени каталога (для хранения почты или просмотра файла автоответчика, например), будьте очень осторожны, чтобы ваши спи- ски управления доступом, отфильтровывающие любые специальные символы, не при- вели к непредвиденным последствиям. (В этом примере выполняется поиск последо- вательности символов /. ./, которые могут создать проблемы, если имя пользователя является частью имени пути.) Следующий раздел accept гарантирует, что почта, посланная администратору элек- тронной почты, всегда будет доставляться, если она была послана в локальный домен; это облегчает отладку. Строка require проверяет, можно ли вернуть сообщение о недоставке, но проверка, относится только к домену отправителя.19 Если пользовательское имя отправителя было подделано, то сообщение о недоставке может породить новое сообщение о недоставке. В этом месте проверку можно усилить, вызвав другую программу, но некоторые сайты рассматривают такие вызовы как злонамеренные действия и могут внести ваш почтовый сервер в черный список или в список серверов с плохой репутацией. Следующий раздел accept проверяет узлы, через которые разрешается выполнять ретрансляцию, т.е. локальные узлы, подающие почту в систему. Эта строка означает, что программа exim должна действовать как агент представления почтовых сообщений и исправлять любые недостатки в заголовках при поступлении сообщений от пользова- тельского агента. Адрес отправителя не проверяется, потому что многие пользователь- ские агенты сбиваются с толку ошибочными возвратами. (Это приемлемо только для локальных машин, которые выполняют ретрансляцию на интеллектуальный узел, а не во внешние домены.) Верификация подписи DKIM отключена, поскольку эти сообще- ния отправляются вашими пользователями или их коллегами по ретрансляции. Последний раздел accept относится к локальным узлам, выполняющим аутентифи- кацию с помощью протокола SMTP AUTH. Эти сообщения снова обрабатываются как представления от пользовательских агентов. 19 Раздел require означает “deny, если не совпало”.
Глава 20. Электронная почта 865 Затем мы проверяем домен адресата, который указан в заголовке письма и должен содержаться либо в нашем списке local domains, либо в списке relay to_domains, в котором перечислены домены, имеющие право на ретрансляцию. (Списки этих доменов определяются в другом месте.) Письмо с адресом, который не входит ни в один из этих списков, порождает особое сообщение об ошибке. Проверка подписи DKIM снова от- ключена. Итак, если все наши сформулированные выше предположения были удовлетворены и ни одно из более тонких правил accept или deny не было нарушено, мы верифици- руем получателя и принимаем сообщение. В эту категорию попадает большинство со- общений, поступающих из Интернета. В приведенный выше пример мы не включили сканирование черных списков. Для до- ступа к черным спискам следует использовать один из примеров, описанных в файле кон- фигурации, предоставленном по умолчанию, или что-нибудь наподобие следующего кода. deny condition = ${if isip4 {$sender_host_address}}' I authenticated = * !hosts = +my_whitelist_ips •dnslists = list.dnswl.org domains = +local_domains verify = recipient message = You are on RBL $dnslist_domain: $dnslist_text dnslists = zen.spamhaus.org logwrite = Blacklisted sender [$sender_host_address] $dnslist_domain: $dnslist_text В переводе на обычный язык этот фрагмент означает, что если сообщение соответ- ствует всем следующим критериям, то оно отклоняется с сообщением о пользователь- ской ошибке и регистрируется в журнале (также вместе с сообщением о пользователь- ской ошибке). • Сообщение поступило с 1Ру4-адреса (некоторые списки неправильно обрабатыва- ют 1Ру6-адреса). • Сообщение не ассоциировано с аутентифицированным сеансом SMTP. • Сообщение поступило от отправителя, которого нет в локальном белом списке. • Сообщение поступило от отправителя, которого нет в глобальном (из Интернета) белом списке. • Сообщение адресовано корректному локальному получателю. • Узел отправителя занесен в черный список сайта zen. spamhaus. org. Переменные dnslist text и dnslist domain задаются путем присваивания пара- метру dnslists, который выполняет переключение поиска по черным спискам. Этот раздел deny должен размещаться сразу после проверки необычных символов в адресах. Рассмотрим еще один пример списка управления доступом, который отклоняет сооб- щение, поступившее от удаленного сайта, неправильно ответившего на команду HELO. acl_check_mail: deny message = 503 Bad sequence of cmds - must send HELO/EHLO first condition = ${if !def:sender_helo_name} accept Программа Exim решает проблему “болтуна” (более специальный случай сайта, “не- правильно отвечающего на команду HELO”) с помощью параметра smtp_enforce_sync, который включается по умолчанию.
866 Часть II. Работа в сети Сканирование содержимого на этапе применения списков управления доступом Программа Exim поддерживает мощное сканирование содержимого в нескольких точках на пути сообщения внутри почтовой системы: на этапе применения списков уп- равления доступом (после команды SMTP DATA), во время доставки с помощью пара- метра transport-filter или функции local scan после выполнения всех проверок списков управления доступом. Для поддержки сканирования необходимо выполнить компиляцию данного модуля в систему Exim с помощью переменной WITH_CONTENT_ SCAN в файле EDITME; по умолчанию она закомментирована. Этот параметр наделяет списки управления доступом дополнительными мощью и гибкостью, добавляя два но- вых параметра конфигурации: spamd_address и av__scanner. Сканирование на этапе проверки списков управления доступом позволяет отклонять сообщения на лету с помощью обмена информацией между транспортным агентом и узлом отправителя. Сообщение никогда не будет принято к доставке, поэтому сообще- ние о недоставке не генерируется. Это очень хороший способ отклонения сообщений, поскольку он позволяет избежать обратной рассылки спама, вызванного сообщениями о недоставке, по поддельным адресам отправителей. Сканирование вирусов Для сканирования вирусов сначала следует задать тип сканера и его параметры в переменной av scanner в разделе глобальных параметров в файле конфигурации. В табл. 20.20 перечислены сканеры, допустимые в текущей версии программы Exim, и их соответствующие спецификации av_scanner. Таблица 20.20. Антивирусные сканеры, известные программе exim aveserver путь-к_сокету Демон сканера Касперского 5 clamd: ip-порта или путь-к-сокету ClamAV по протоколу TCP или локальный сокет cmdline: путь found-regex name-regex Обобщенный интерфейс командной строки drweb: ip-адрес порта или путь-к-сокету Демон сканера DrWeb (said, com) f secure: путь-к-. f sav-файлу Демон сканера F-Secure (f-secure. com) kavdaemon: путь-к-сокету Демон сканера Касперского, версия 4 sophie: путь-к-сокету Интерфейс Sophie для сканера Sophosа а См. clanfield, inf o/sophie. Этот сканер задан по умолчанию (путь/var/run/sophie). Задав переменную av scanner, можно использовать условие malware в списке уп- равления доступом, которое проверяет содержимое сообщений после выполнения ко- манды DATA в ходе обмена информацией по протоколу SMTP. Рассмотрим пример, взя- тый из документации к программе Exim. deny message = This message contains malware ($malware_name) demime = * malware = * Раздел malware вызывает сканер вирусов, если передаваемое значение равно true (что в данном примере выполняется всегда). Если включен параметр demime и сообще- ние содержит приложение, закодированное по стандарту MIME, то программа exim де- кодирует приложение, чтобы сделать его доступным для антивирусного сканера.
Глава 20. Электронная почта 867 Однако большинство сканеров может выполнить это декодирование самостоятельно. Для того чтобы избежать дублирования при решении этой задачи, раздел demime следует включать, только если это необходимо для антивирусного сканера. Такое дублирование не вызывает ошибки, но расходует ресурсы и замедляет обработку почты. Сканирование спама Для сканирования спама агент Exim использует программу SpamAssassin, которая обычно принимает сообщения на ТСР-порт 783, но может также использовать сокет локального домена. Задавая параметры соединения в файле конфигурации программы exim, присвойте какое-нибудь значение переменной spamd address. Этим значением может быть либо IP-адрес и номер порта, разделенные пробелом, либо абсолютный путь сокета локального домена. Можно также одновременно задавать до 32 пар “адрес/порт”, чтобы использовать несколько экземпляров утилиты SpamAssassin. Присвоив имя пользователя переменной spam, вызовите утилиту SpamAssassin из списка управления доступом, связанного с командой SMTP DATA. Если в качестве пользователя указано имя nobody, то программа SpamAssassin использует универсаль- ный профиль сканирования, в противном случае — профиль, связанный с указанным вами пользователем (если такой профиль существует).20 Строки deny message = This message was classified as spam spam = nobody означают использование системного профиля спама, установленного по умолчанию. Просто поместить инструкцию spam в файл конфигурации недостаточно; необходимо присвоить определенное значение переменной spam. Поскольку программа SpamAssassin работает медленно, а большинство сообщений спама являются короткими, необходимо проверять размер и сканировать только неболь- шие сообщения. Рассмотрим пример. deny message = This message was classified as spam condition = ${if < {$message_size}{10K}} spam = nobody С помощью программы SpamAssassin можно решать более сложные задачи; все дета- ли описаны в спецификации программы Exim. Аутентификаторы Аутентификаторы (authenticators) — это драйверы, взаимодействующие с последова- тельностью “вызов/ответ” команд SMTP AUTH и идентифицирующие механизм аутен- тификации, приемлемый для клиента и сервера. Программа Exim поддерживает четыре механизма. • AUTH-CRAM-MD5 (RFC2195). • AUTH CYRUS SASL для использования программного обеспечения Cyrus IMAP. • AUTH PLAINTEXT, включающий макросы PLAIN и LOGIN. • auth spa, поддерживающий механизм аутентификации Secure Password Authen- tication компании Microsoft. 20 На первый взгляд, требование задавать имя пользователя обеспечивает гибкость. Однако, поскольку сканирование осуществляется после выполнения команды DATA, а не RCPT, сообще- ние уже связано со своим получателем. Если же получателей несколько, то неизвестно, какой про- филь спама следует использовать.
868 Часть II. Работа в сети Когда агент exim получает электронную почту, он действует как сервер SMTP AUTH. Когда он посылает электронную почту, является клиентом. Параметры, появляющиеся в определениях экземпляров аутентфикатора, сопровождаются префиксами server_ или client , позволяющими задавать разные конфигурации, в зависимости от роли, кото- рую играет агент Exim. Аутентификаторы используются в списках управления доступом, как показано в од- ном из примеров, приведенных выше. accept authenticated = * Ниже приведен пример, демонстрирующий клиентский и серверный механизмы LOGIN. В этом простом примере используются фиксированные имя пользователя и па- роль, что приемлемо для небольших организаций, но, вероятно, это не следует рекомен- довать для крупных сетей. begin authenticators my_client_fixed_login: driver - plaintext public_name = LOGIN client_send = : myusername : mypasswd my_server_fixed_login: driver = plaintext public_name = LOGIN server_advertise_condition = ${if def:tis_cipher} server_prompts = User Name : Password server_condition = ${if and {{eq{$authl}{имя_пользователя}} {eq{$auth2}{пароль}}}} server_set_id = $authl Данные для аутентификации могут поступать из многих источников: LDAP, РАМ, / etc/passwd и т.д. Раздел server advertise condition в указанном фрагменте кода предотвращает открытую пересылку по линии связи паролей почтовых клиентов по тре- бованию протокола TLS (через STARTTLS или SSL). Если вы хотите, чтобы програм- ма exim действовала аналогично, будучи клиентский системой, используйте параметр client_condition в разделе client, тоже вместе с параметром tis_cipher. Детальное описание всех возможных параметров аутентификации программы Exim и примеры их использования можно найти в документации. Маршрутизаторы Маршрутизаторы обрабатывают адреса электронной почты, либо перезаписывая их, либо переприсваивая транспортному агенту и посылая в пункт назначения. Конкретный маршрутизатор может иметь несколько экземпляров с разными параметрами. Вы указываете последовательность маршрутизаторов. Сообщение начинает свой путь с первого маршрутизатора и проходит по списку, пока сообщение не будет принято или отклонено. Принимающий маршрутизатор обычно передает сообщения драйверу транс- порта. Маршрутизаторы обрабатывают как входящую, так и исходящую корреспонден- цию. Их можно считать чем-то вроде подпрограмм в языке программирования. Маршрутизатор может возвращать любые из следующих уведомлений о статусе со- общения. • accept — маршрутизатор принимает адрес и передает его драйверу транспорта.
Глава 20. Электронная почта 8б9 • pass — данный маршрутизатор не может обработать указанный адрес; управление передается следующему маршрутизатору. • decline — маршрутизатор решает не обрабатывать адрес; следующий маршрути- затор, пожалуйста! • fail — адрес является неправильным; маршрутизатор ставит его в очередь для ге- нерации сообщения о недоставке. • defer — оставляет сообщение в очереди для последующей обработки. • error — обнаружена ошибка в спецификации маршрутизатора; сообщение откла- дывается. Если сообщение получило от всех маршрутизаторов в очереди уведомления pass или decline, оно возвращается отправителю как письмо, имеющее немаршрутизируемый адрес. Если сообщение удовлетворяет всем предусловиям для маршрутизатора и маршрути- затор закончил работу, выполнив инструкцию no more, то это сообщение не передается никаким дополнительным маршрутизаторам, независимо от того, какой статус оно полу- чило у текущего маршрутизатора. Например, если ваш удаленный SMTP-маршрутизатор выполнил предусловие domains = ! +local_domains и установил параметр nojnore, то следующему маршрутизатору в последовательности отправляются только сообщения, адре- сованные локальным пользователям (т.е. сообщения, нарушающие предусловие домена). Маршрутизаторы имеют много параметров; наиболее распространенными являются параметры предусловий или условий отказов, возвращаемых сообщений об ошибках и используемых драйверов транспорта. В следующих разделах подробно описываются маршрутизаторы accept, dnslookup, manualroute и redirect. Снипеты конфигурации основаны на предположении, что агент exim выполняется на локальном компьютере в домене example. com. Все эти сни- петы довольно просты; если вы захотите использовать более изощренные маршрутиза- торы, обратитесь к документации. Маршрутизатор accept Этот маршрутизатор помечает адрес как приемлемый и передает соответствующее сообщение драйверу транспорта. Ниже приведен пример экземпляров маршрутизатора accept с именами localusers (для доставки локальной почты) и save_to_f ile (для отправления сообщения в архив). localusers: driver = accept domains = example.com check_local_user transport = my_local_delivery save_to_file: driver = accept domains = dialup.example.com transport = batchsmtp_appendfile Экземпляр маршрутизатора с именем localusers проверяет, совпадает ли домен- ная часть адреса доставки с именем домена example. com и является ли локальная часть адреса регистрационным именем локального пользователя. Если оба условия выпол- нены, маршрутизатор передает сообщение экземпляру драйвера транспорта с именем my local delivery, определенному в разделе транспорта. Экземпляр save to f ile
870 Часть II. Работа в сети предназначен для абонентов автоматической телефонной линии; он добавляет сообще- ние в файл, указанный в определении транспорта batchsmtp_appendfile. Маршрутизатор dnslookup Как правило, маршрутизатор dnslookup используется для исходящих сообщений. Он ищет запись MX о домене отправителя и передает сообщение драйверу транспорта SMTP для доставки. Ниже приведен экземпляр маршрутизатора с именем remoteusers. remoteusers: driver = dnslookup domains - 1+example.com transport = my_remote_delivery Q Более подробно пространство частных адресов RFC1918 описано в разделе 14.4. Код dnslookup ищет записи MX об адресате. Если их нет, он проверяет запись А. В итоге, данный экземпляр маршрутизатора может запрещать доставку сообщений на определенные IP-адреса; например, частные адреса RFC 1918 не могут маршрутизиро- ваться в Интернет. Больше информации об этом можно найти в описании параметра ignore_target_hosts option. Маршрутизатор manualroute Гибкий драйвер manual route может посылать электронную почту куда угодно. Ин- формация о маршрутизации может быть представлена в виде таблицы правил соответ- ствия для домена получателя (route list) или отдельного правила, которое применя- ется для всех доменов (route data). Ниже приведены два экземпляра маршрутизатора manualroute. Первый экземпляр реализует концепцию “интеллектуального узла”, в ко- торой все исходящие сообщения посылаются центральному “интеллектуальному” узлу для обработки. Этот экземпляр называется smarthost и применяется ко всем доменам получателей, не указанным (используется символ !) в списке local domains. smarthost: driver = manualroute domains = !+local_domains transport = remote_snmp route_data = smarthost.example.com Экземпляр маршрутизатора firewall, приведенный ниже, использует протокол SMTP для отправки входящих сообщений узлам, находящимся внутри брандмауэра (возможно, после сканирования их на спам и вирусы). Он ищет данные о маршрутизации для каж- дого домена получателя в базе данных CDB, содержащей имена локальных узлов. (Для того чтобы иметь возможность использовать базу данных CDB, сборку программы Exim следует проводить с параметром LOOKUP_CDB.) firewall: driver = manualroute transport = remote-smtp route_data = ${lookup{$domain} cdb {/internal/host/routes}} Маршрутизатор redirect Драйвер redirect перезаписывает адрес, используя псевдонимы из системного фай- ла aliases или пользовательского файла ~/. forward. Обычно он не присваивает пере-
Глава 20. Электронная почта 8М записанный адрес транспорту, а оставляет эту работу другим маршрутизаторам, находя- щимся в цепочке. Первый экземпляр system aliases, приведенный ниже, ищет псевдонимы мето- дом последовательного перебора (lsearch) в файле /etc/aliases. Это удобно, если файл aliases небольшой, но если он огромный, то метод последовательного перебора следует заменить поиском в базе данных. Второй экземпляр с именем forwardfile сна- чала проверяет, что почта адресована локальному пользователю, а затем просматривает пользовательский файл . forward. system_aliases: driver = redirect data = ${lookup{$local_part} lsearch {/etc/aliases}} user_forward: driver = redirect check_local_user file = $home/.forward no_verify Параметр check local user гарантирует, что получатель является корректным локальным пользователем. Параметр no verify означает, что проверка правильности адреса, на который перенаправляется сообщение, не нужна, следует просто выполнить поставку. Фильтрация пользователей с помощью файлов forward Программа Exim позволяет не только перенаправлять сообщения, используя файлы . forward, но и фильтровать их, основываясь на содержимом пользовательского файла . forward. Она поддерживает свою собственную фильтрацию, а также фильтрацию ме- тодом решета (Sieve filtering), являющуюся стандартом ТЕТЕ Если первая строка пользо- вательского файла . forward выглядит как #Exim filter или #Sieve filter то последующие команды фильтрации (их около 15) можно использовать для выработки решения, куда следует доставить сообщение. Фильтрация на самом деле не подразумева- ет доставки сообщения, она просто выясняет пункт назначения. Рассмотрим пример. #Exim filter if $header_subject: contains SAGE or $header_subject: contains sysadmin then save $home/mail/sage-sysadmin endif Для того чтобы управлять тем, что пользователи могут делать в своих файлах . forward, а чего они делать не могут, используется множество параметров . forward. Имена этих параметров начинаются с префиксов forbid_ или allow . Важно предотвратить запуск пользователями оболочек, загрузку библиотек в бинарные коды или использование встро- енного интерпретатора языка Perl, если они не должны этого делать. Производя обнов- ление почтовой системы, проверьте новые параметры forbid*, чтобы убедиться, что пользователи не имеют возможности экспериментировать со своими файлами . forward.
872 Часть II. Работа в сети Транспортные механизмы Маршрутизаторы решают, куда должны следовать сообщения, а транспортные меха- низмы выполняют их фактическое перемещение в пункт назначения. Локальные транс- порты обычно добавляются в файл, передаются локальной программе или обмениваются информацией по протоколу LMTP с серверами IMAP. Удаленные транспорты обменива- ются информацией со своими партнерами в Интернете по протоколу SMTP. В агенте Exim существует пять транспортных механизма: appendfile, lmtp, smtp, autoreply и pipe; мы опишем транспортные механизмы appendfile и smtp. Транспорт autoreply обычно используется для отправки сообщений автоответчика, а транспорт pipe передает сообщения на вход команд через канал UNIX. Как и при рабо- те с маршрутизаторами, необходимо определить экземпляры транспортов, причем жела- тельно иметь несколько экземпляров транспорта одного и того же типа. Порядок важен для маршрутизаторов, но не для транспортных механизмов. Транспортный механизм appendfile Драйвер appendfile хранит сообщения в формате mbox, mbx, Maildir или mailstore в заданном файле или каталоге. Компилируя программу Exim, необходи- мо включать соответствующие форматы почтового ящика; по умолчанию они заком- ментированы в файле EDITME. В следующем примере определен транспорт my local- delivery (экземпляр транспорта appendfile), который упоминался в определении экземпляра маршрутизатора localusers в одном из предыдущих примеров. my_local_delivery: driver = appendfile file = /var/mail/$local_part delivery_date_add envelope_to_add return_path_add group = mail mode = 0660 Строки *_add добавляют заголовки в сообщение. Разделы group и mode гарантиру- ют, что транспортный агент может записывать данные в файл. Транспортный механизм smtp Это основной компонент всей почтовой системы. Здесь мы определили два экзем- пляра — для стандартного SMPT-порта (25) и для порта подачи почты (587). my_remote_delivery: driver = smtp my_remote_delivery_port587: driver = smtp port = 587 headers_add = X-processed-by: MACRO_HEADER port 587 Второй экземпляр, my_remote_delivery_port587, задает порт и указывает, что в сообщение должен быть добавлен заголовок, включающий индикацию исходяще- го порта. Кроме того, где-то в файле конфигурации должен быть определен макрос MACRO HEADER.
Глава 20. Электронная почта 873 Конфигурация retry В файле конфигурации должен существовать раздел retry, иначе программа Exim никогда не будет повторять попытку доставить почту, которая не была доставлена с пер- вого раза. Можно указать три временных интервала, каждый из которых длиннее пред- ыдущего. После истечение последнего интервала сообщения будут отправлены обратно отправителю как недоставленные. В инструкциях retry для обозначения минут, часов, дней и недель используются суффиксы in, h, d и w. Для разных узлов и доменов можно задавать разные интервалы. Вот как выглядит раздел retry. begin retry * * F, 2h, 15m; F, 24h, lh; F, 4d, 6h Этот пример означает следующее: “Для любого домена доставку почты на временно недоступный адрес следует повторять каждые 15 минут в течение двух дней, каждые де- сять часов в течение следующих 24 часов, а затем каждые 6 часов через 4 дня и в заклю- чение отправить сообщение обратно как недоставленное”. Конфигурация перезаписи Раздел перезаписи в файле конфигурации начинается словами begin rewrite. Он используется для исправления адресов, а не для перенаправления сообщений. Например, его можно использовать для исходящих адресов. • Для того чтобы точно указать, что сообщение исходит из вашего домена, а не от индивидуальных узлов. • Для отображения имен пользователей в стандартном формате, например Имя. Фамилия. Перезапись не следует применять для адресов входящей почты. Функция локального сканирования Если вы хотите еще более точно настроить программу exim, например, чтобы филь- тровать самые современные и самые распространенные вирусы, можете написать функ- цию на языке С, реализующую ваш собственный алгоритм сканирования, и инстал- лировать ее в разделе local_scan файла конфигурации. Детали и примеры описаны в документации программы Exim. Сочетание программ amavisd и Exim Для того чтобы настроить программу exim так, чтобы посылать всю почту, предна- значенную для вашего домена, программе amavisd сканирования на вирусы и спам, создайте первый маршрутизатор в файле конфигурации, как показано ниже. amavis: no_verify_recipient driver = manualroute condition = ${if or {eq {$interface_port} {10025} {eq {$received_protocol} {scanned-ok} } } {0} {1} } domain = local_domains transport = amavis route_list = * localhost byname self = send
874 Часть II. Работа в сети Строка condition означает, что сообщения, исходящие из порта 10025, не должны перенаправляться программе amavisd. Это порт, на который возвращаются сообщения от программы amavisd после сканирования, поэтому эти сообщения не должны отправ- ляться обратно программе amavisd, чтобы не возник замкнутый круг. Транспортный механизм amavis настраивается следующим образом. amavis: driver = smtp port = 10024 allow_localhost Кроме того, в начало файла конфигурации необходимо добавить строку local_interfaces = 0.0.0.0.25 : 127.0.0.1.10025 чтобы приказать программе exim принимать сообщения с любых адресов, если они по- ступили через порт 25, и от локальных узлов, если они поступили через порт 10025, ко- торый является портом возврата сообщений для программы amavisd. Эта конфигурация переводит все сканирование в автономный режим, поэтому со- общения о недоставке в ответ на выявление вирусов и спама сами по себе могут создать обратную рассылку спам. Вероятно, лучше поместить инструкцию amavis чуть ниже в упорядоченном списке маршрутизаторов и предоставить программе Exim возможность использовать богатый язык списков управления доступом для проверки относительно коротких сообщений. Еще лучше использовать конструкцию $ {run...}, предусмотрен- ную в программе exim, чтобы заставить сканер amavisd выполнять проверку в опера- тивном режиме. Кроме того, встроенные возможности сканирования в программе exim несколько снижают конкурентоспособность программы amavisd. Регистрация По умолчанию программа Exim записывает три разных регистрационных файла: главный журнал, журнал отказов и журнал тревоги. Каждая запись в журнале содержит время ее создания. Местоположение регистрационных файлов задается в файле EDITME (до компиляции программы exim) или в файле конфигурации времени выполнения с помощью параметра log file path. По умолчанию файлы регистрации хранятся в каталоге /var/spool/exim/log. Параметр log f ile path может принимать до двух значений, разделенных двоето- чием. Каждое значение должно быть либо ключевым словом syslog, либо абсолют- ным путем со встроенными символами %, вместо которых подставляются имена main, reject и panic. Например, инструкция log_file_path = syslog : /var/log/exim_%s устанавливает, что в качестве регистрационных файлов должны использоваться систем- ный журнал (с функцией “mail”) и файлы exim_main, exim_re ject и eximjpanic в ка- талоге /var/log. Программа Exim передает записи журнала main в системный журнал в качестве первоочередной информации, записи reject — в качестве первоочередных сообщений, а записи panic — в качестве первоочередных сигналов. Журнал main содержит по одной строке для поступления и доставки каждого со- общения. Отчет об информации, содержащейся в этом журнале, можно сгенерировать с помощью сценария eximstats на языке Perl, включенного в дистрибутивный пакет Exim. Записи из журнала reject хранят информацию о сообщениях, которые были отклонены из-за нарушения правил, — злонамеренные программы, спам и пр. Этот журнал содержит итоговую строку для сообщения из журнала main, а также исходные
Глава 20. Электронная почта 875 заголовки отклоненных сообщений. Если правила были изменены, проверьте журнал reject, чтобы убедиться, что все в порядке. Журнал panic предназначен для регистрации серьезных ошибок программного обе- спечения; программа exim записывает в него информацию непосредственно перед тем, как завершить работу. Если проблемы не возникли, журнал panic существовать не дол- жен. Попросите утилиту cron проверить, существует ли файл panic, устраните про- блему, вызвавшую тревогу, а затем удалите этот файл. Программа exim заново создаст его, если снова возникнет тревожная ситуация. При отладке можно увеличить объем и расширить набор типов регистрируемых данных с помощью параметра log selector. Рассмотрим пример. log_selector = +smtp_connection +snmp_incomplete_transaction +... Категории регистрируемых данных могут затем включаться или исключаться с по- мощью механизма log selector, описанного в спецификации программы Exim в раз- деле “Log files”. Существует примерно 35 возможностей, включая +а11, которая реально переполнит информацией ваши диски! Кроме того, программа exim хранит временный регистрационный файл для каждого обработанного сообщения. Он называется по идентификатору сообщения и находится в каталоге /var/spool/exim/msglog. Если возникают проблемы с конкретным пунктом назначения, следует проверить информацию в этом каталоге. Отладка Программа Exim имеет мощные средства для отладки. Вы можете управлять объемом информации, которую хотите видеть для каждой настраиваемой возможности. Команда exim -d заставляет программу exim переключиться в режим отладки, в котором ода получает высокий приоритет и не позволяет делать свои копии. К параметру -d мож- но добавить дополнительные категории отладки, вставляя символы + или - перед на- званием категории. Например, параметры -d+expand+acl предусматривают обычный вывод информации об отладке, который сопровождается дополнительными деталями, касающимися расширений строк и интерпретации списков управления доступом. (Эти две категории являются самыми проблемными.) Для отладочной информации можно настроить более 30 категорий; их полный список находится на соответствующей спра- вочной странице. При отладке почтовой системы обычно запускают почтовый транспортный агент на нестандартном порту, а затем обращаются к нему с помощью команды telnet. На- пример, для того чтобы запустить программу exim в режиме демона, прослушивающего порт 26, и включить вывод информации об отладке, можно использовать следующую инструкцию. $ sudo exim -d -оХ 26 -bd Затем можно применить команду telnet к порту 26 и набрать команды SMTP, пыта- ясь воспроизвести проблемы, решение которых следует отладить. В качестве альтернативы можно использовать команду swaks, которая вступит в об- мен информацией с протоколом SMTP. Эта команда запускает сценарий на языке Perl, ускоряющий и облегчающий отладку протокола SMTP. Инструкция swaks —help выводит на экране короткое описание, а полную информацию можно найти на сайте j etmore.org/j ohn/code/#swaks. Если ваши регистрационные файлы делают тайм-аут примерно каждые 30 секунд, следует подозревать проблемы в системе DNS. Тайм-ауты длительностью 5 секунд могут
876 Часть II. Работа в сети быть тайм-аутами запроса identd. (Демон identd в прошлом предназначался для иден- тификации реального отправителя почтового сообщения, однако поскольку его было очень легко обмануть, он больше не используется.) 20.15. Почтовый агент Postfix Постфикс — популярная альтернатива программе sendmail. Вице Венема (Wietse Venema) начал работу над проектом Postfix в 1996 году, когда проводил годичный творче- ский отпуск в Исследовательском центре им. Т. Дж. Уотсона компании IBM (Т. J. Watson Research Center), и до сих пор активно работает над ним. Целью разработки програм- мы Postfix является не только безопасность (хотя это ее первоочередная и самая главная цель!), но и реализация политики распространения открытого программного обеспече- ния, высокое быстродействие, надежность и гибкость. Все основные дистрибутивные пакеты системы Linux включают Postfix, а начиная с версии 10.3 система Mac OS X по умолчанию оснащается почтовой системой Postfix, а не sendmail. 03 Более подробно регулярные выражения описаны в разделе 2.3. О системе Postfix следует знать два самых важных факта: во-первых, она поставляет- ся в практически работоспособном виде (простейшие файлы конфигурации состоят из одной-двух строк) и, во-вторых, эффективно использует ассоциативные массивы регу- лярных выражений для фильтрации почты, особенно в сочетании с библиотекой PCRE (Perl Compatible Regular Expression). Система Postfix совместима с программой sendmail в том смысле, что файлы aliases и . forward системы Postfix имеют тот же формат и семантику, что и аналогичные файлы в системе sendmail. Система Postfix поддерживает протокол ESMTP. Кроме того, поддерживаются вирту- альные домены и фильтация спама. Для перезаписи адресов система Postfix использует поиск в таблицах, которые мо- гут быть записаны в обычных файлах или в форматах Berkeley DB, DBM, LDAP, NIS, Netlnfo и SQL. Кроме того, система Postfix поддерживает протокол почтового фильтра программы sendmail, поэтому ее функционирование можно легко настроить с помощью множества открытых почтовых фильтров (внешних программ, решающих специальные задачи в ходе сеанса SMTP; см. раздел 20.6). Архитектура системы Postfix. Система Postfix состоит из нескольких небольших взаимодействующих программ, посылающих сообщения по сети, получающих сообщения, выполняющих локальную доставку почты и т.д. Взаимодействие между ними осуществляется через сокеты локаль- ных доменов или именованные каналы FIFO. Эта архитектура довольно сильно отлича- ется от архитектуры программ sendmail и Exim, в которых основную работу выполняет большая монолитная программа. Запуск системы Postfix и слежение за всеми ее процессами выполняет программа master. В ее конфигурационном файле, master.cf, перечислены все вспомогатель- ные программы, а также информация о том, как они должны запускаться. Значения, по умолчанию установленные в этом файле, удовлетворяют большую часть потребностей пользователей, так что изощряться не обязательно. В основном, приходится отключать программы, например smtpd, которые клиент не должен прослушивать на порту SMTP. Самые важные серверные программы, вовлеченные в доставку электронной почты, показаны на рис. 20.4.
Глава 20. Электронная почта 877 Рис. 20.4. Серверные программы системы Postfix Получение почты Программа smtpd получает почту, поступающую в систему через сервер SMTP. Она также проверяет, имеют ли право клиенты, установившие соединение, отправлять по- чту, которую они пытаются доставить. Если электронная почта послана локально с по- мощью программы /usr/lib/sendmail, то файл записывается в каталог /var/spool/ postfix/maildrop. Этот каталог периодически сканируется программой pickup, об- рабатывающей любой найденный новый файл. Вся входящая почта проходит через программу cleanup, которая добавляет пропу- щенные заголовки и перезаписывает адреса в соответствии с таблицами canonical и virtual. Прежде чем вставить сообщение в очередь входящих сообщений, программа cleanup передает его программе trivial-rewrite, которая выполняет небольшое ре- дактирование адресов, например добавляет почтовый домен к не полностью заданным адресам. Управление почтовыми очередями ожидания Программа gmgr управляет пятью очередями, содержащими почту, ожидающую до- ставки. • incoming — поступающая почта • active — доставленная почта • deferred — почта, доставка которой завершилась неудачей • hold — почта, заблокированная в очереди администратором • corrupt — почта, которую невозможно прочитать или проанализировать Менеджер очереди обычно выбирает следующее сообщение для обработки, руко- водствуясь простой стратегией FIFO, но помимо нее он также поддерживает сложный алгоритм приоритетного обслуживания, который среди всей массы сообщений отдает предпочтение сообщениям, направленным избранным получателям. Для того чтобы не перегружать узел, предназначенный для получения почты, осо- бенно после его выхода из строя, система Postfix использует алгоритм медленного пуска, управляющий скоростью доставки почты. Отложенная почта получает временную метку о повторной доставке, которая имеет экспоненциальное затухание, чтобы не затрачивать ресурсы на недоставленные сообще- ния. Избежать излишних попыток доставить почту, которую невозможно доставить, по- зволяет кеш статуса.
878 Часть II. Работа в сети Отправка сообщений Программа qmgr с помощью программы trivial-rewrite решает, куда следует по- слать сообщение. Вместо решений, принимаемых программой trivial-rewrite, мож- но использовать поиск в таблицах (transport maps). Доставка почты удаленным узлам через сервер SMTP выполняется программой smtp. Программа lmtp доставляет почту, используя протокол LMTP (Local Mail Transfer Protocol), определенный в документе RFC2033. Протокол LMTP основан на протоколе SMTP, но был модифицирован так, что почтовый сервер не обязан управлять почтовой очередью. Этот обработчик почты очень полезен для доставки сообщений на почтовые серверы, такие как Cyrus IMAP. Программа local предназначена для локальной доставки электронной почты. Она находит адреса в таблице aliases и следует инструкциям, указанным в файлах полу- чателя . forward. Сообщения пересылаются на другой адрес, передаются внешней про- грамме для обработки или сохраняются в почтовых папках пользователя. Программа virtual доставляет почту в “виртуальные почтовые ящики”, т.е. в по- чтовые ящики, не связанные с локальной учетной записью в системе Linux, но имею- щие корректные адреса. В заключение программа pipe выполняет доставку посредством внешних программ. Безопасность Система Postfix обеспечивает безопасность на нескольких уровнях. Большинство серверных программ системы Postfix могут выполняться в окружении, созданном с по- мощью команды chroot. Это отдельные программы, не имеющие отношений типа “предок-потомок”. Ни одна из них не имеет механизма setuid. Каталог maildrop запол- няется группой postdrop, для которой программа postdrop установила идентификатор setgid. Впечатляет тот факт, что ни в одной версии системы Postfix еще не обнаружены де- фекты, которые можно было бы использовать дистанционно. Команды и документация системы Postfix Взаимодействие пользователя с системой обеспечивают несколько утилит, запускае- мых из командной строки. • sendmail, mailq, newaliases — выполняет замены, совместимые с системой sendmail. • postfix — запускает и останавливает почтовую систему (должна запускаться из корня). • postalias — создает, модифицирует и ставит в очередь таблицы псевдонимов.. • postcat - выводит на печать содержимое файлов очереди.. • postconf — выводит на печать и редактирует главный файл конфигурации main. cf. • postmap — создает, модифицирует или ставит в очередь таблицы поиска.. • postsuper —управляет почтовыми очередями.. Дистрибутивный пакет Postfix содержит набор справочных страниц, описывающих все программы и их параметры. Документация, размещенная на сайте postfix.org,
Глава 20. Электронная почта 879 объясняет, как конфигурировать разные аспекты программы Postfix и управлять ими. Эти документы также входят в дистрибутивный пакет Postfix и находятся в каталоге README^FILES. Конфигурация системы Postfix Файл main.cf — .главный конфигурационный файл системы Postfix. Файл master, cf конфигурирует серверные программы. Он также определяет разные таблицы поиска, на которые ссылается файл main. cf, и поддерживает разные типы служебных отобра- жений. Справочная страница postconf(5) описывает каждый параметр, заданный в фай- ле main.cf. Существует также программа postconf, которая с помощью команды man postconf позволяет получить справочную страницу, заменяющую страницу postconf(5). Для того чтобы получить правильную версию справочной страницы, следует использовать команду man -s 5 postconf (соответственно, man 5 postconf в системах HP-UX и AIX). Язык конфигурирования системы Postfix выглядит как ряд комментариев sh и ин- струкций присваивания. В определении одной переменной можно ссылаться на другие переменные с помощью префикса $. Определения переменных заносятся в память сразу, как только они обнаруживаются в файле конфигурации; они не раскрываются, пока не будут использованы, и в это время могут производиться любые подстановки. Можно создавать новые переменные, присваивая им значения. При выборе имен следует быть осторожным, чтобы не создать конфликт с существующими переменными конфигурации. Все файлы конфигурации системы Postfix, включая таблицы поиска, интерпретируют строки, начинающиеся с пробела, как продолжение предыдущей строки. Это позволяет создавать очень удобные для чтения файлы конфигурации, но при этом новую строку приходится начинать с первой позиции. Что должно находиться в файле main.cf В файле main. cf .можно задать более 500 параметров. Однако для среднестатисти- ческого сайта необходимы только некоторые из них. Автор системы Postfix настоятельно рекомендует включать в свои конфигурации только те параметры, которые имеют зна- чения, не заданные по умолчанию. Таким образом, если в будущем значение параметра, заданное по умолчанию, изменится, ваша конфигурация учтет новое значение автома- тически. Образец файла main. cf, поставляемый в дистрибутивном пакете, содержит много закомментированных параметров, а также короткое описание. Исходную версию файла лучше всего оставить в качестве ориентира. Начните создание собственной конфигура- ции с пустого файла, чтобы ваши установки не затерялись среди многочисленных ком- ментариев. Основные установки Начнем с самой простой конфигурации: пустого файла. Как это ни удивительно, это вполне допустимая конфигурация системы Postfix. Результатом такой конфигурации яв- ляется почтовый сервер, доставляющий электронную почту локально внутри того же са- мого домена, в котором находится локальная хост-система, и посылающий все сообще- ния на нелокальные адреса непосредственно на соответствующий удаленный сервер.
880 Часть II. Работа в сети Еще одна простая конфигурация называется “нулевым клиентом”; иначе говоря, си- стема, не выполняющая локальной доставки никаких электронных сообщений и пере- направляющая внешную почту на предназначенный для этого центральный сервер. Для реализации этой конфигурации определим несколько параметров: параметр my domain, задающий доменную часть имени узла, и myorigin, представляющий собой имя почто- вого домена, добавляемое в не полностью заданные адреса. Если эти два параметра со- впадают, то можно написать, например, следующие строки. mydomain = cs.Colorado.edu myorigin = $mydomain Еще один параметр, который необходимо определить, — mydestination, который задает локальные почтовые домены. Если в адресе получателя сообщения имя почто- вого домена совпадает со значением параметра mydestination, сообщение доставля- ется с помощью программы local соответствующему пользователю (в предположении, что не найдены ни релевантный псевдоним, ни файл . forward). Если в параметре mydestination указаны имена нескольких доменов, то все они считаются псевдонима- ми одного и того же домена. Для нулевого клиента локальная доставка не предусмотрена, поэтому этот параметр должен оставаться пустым. mydestination = В заключение, параметр relayhost означает, что система Postfix должна посылать все нелокальные сообщения на указанный узел, а не непосредственно в их заданные явно пункты назначения. relayhost = [mail.cs.colorado.edu] Квадратные скобки означают, что система Postfix должна интерпретировать указан- ную строку как имя узла (запись А в DNS ), а не как имя домена (запись MX в DNS). Поскольку нулевые клиенты не должны получать почту от других систем, в кон- фигурации нулевого клиента осталось только закомментировать строку smtpd в файле master.cf. Это изменение не позволяет системе Postfix вообще запускать программу smtpd. Итак, с помощью всего нескольких строк мы определили полнофункционально- го нулевого клиента! Для “реального” почтового сервера необходимо задать немного больше параметров, а также некоторые таблицы отображений. Эти темы рассмотрим в следующих подраз- делах. Использование утилиты post conf. Утилита postconf — это удобный инструмент, помогающий конфигурировать си- стему Postfix. Если запустить ее без аргументов, она выводит на печать все параметры, которые она сконфигурировала к данному моменту. Если в качестве аргумента указать конкретный параметр, утилита postconf выведет на печать его значение. Флаг -d заставляет утилиту postconf выводить значения параметров, заданные по умолчанию, а не текущие значения, указанные в конфигурации. Рассмотрим пример. $ postconf mydestination mydestination = $ postconf -d mydestination mydestination = $myhostname, localhost.$mydomain, localhost Еще один полезный флаг -п заставляет утилиту postconf выводить только те пара- метры, которые отличаются от заданных по умолчанию. Если вам необходима справка
Глава 20. Электронная почта 881 по списку рассылок в системе Postfix, именно эту информацию следует указать в вашем электронном письме. Таблицы поиска Многие аспекты функционирования системы Postfix зависят от использования та- блиц поиска, которые могут отображать ключи в значения или реализовать простые списки. Например, настройки по умолчанию для таблицы alias maps имеют следую- щий вид. alias_maps = dbm:/etc/mail/aliases, nisimail.aliases Источники данных задаются с помощью обозначения тип:путь. Обратите внимание на то, что конкретная таблица одновременно использует два разных источника инфор- мации: базу данных dbm и ассоциативный массив NIS. Множественные значения мож- но разделять запятыми, пробелами или и тем, и другим. Доступные источники данных перечислены в табл. 20.21; команда postconf -m также выводит эту информацию. Таблица 20.21. Источники информации для таблиц поиска в системе Postfix —— ' <' ' Г' -Л--МЛ. 1 1 ."Л Ът .. -У.'. WIMII _____—.-......................................................„...t........... dbm/sdbm Обычные файлы баз данных dbm или gdbm cidr Сетевые адреса в формате CIDR hash/btree Хеш-таблицы Berkeley DB или файл В-дерева (эквивалент dbm) Idap mysql nis Служба каталогов LDAP База данных MySQL Служба каталогов NIS pcre pgsql Регулярные выражения, совместимые с языком Perl База данных PostgreSQL proxy Доступ через сервер proxymap, например, чтобы избежать использования команды chroot regexp static unix Регулярные выражения POSIX Возвращает значение, указанное как путь, независимо от ключа Файлы /etc/passwd и /etc/group; использует синтаксис NISа а unix:passwd.byname — это файл passwd, a unix:group.byname — файл group. Типы dbm и sdbm следует использовать только для обеспечения совместимости с обычной таблицей псевдонимов программы sendmail. Berkeley DB (hash) — более современная реализация; она безопаснее и быстрее. Ее совместимость — это не пробле- ма, используйте следующие инструкции. alias_database - hash:/etc/mail/aliases alias_maps = hash:/etc/mail/aliases Параметр alias database задает таблицу, которая перестраивается с помощью ко- манды newaliases и должна соответствовать таблице, заданной параметром alias_ maps. Причина, по которой используются два параметра, заключается в том, что табли- ца alias maps может содержать источники, не являющиеся базами данных, например mysql или nis, которые не требуют перестройки. Все таблицы баз данных (dbm, sdbm, hash и btree) представляют собой текстовые файлы, которые компилируются в эффективный бинарный формат, предназначенный для поиска. Синтаксис этих текстовых файлов похож на синтаксис файлов конфигура-
882 Часть II. Работа в сети ции тем, что в них также используются комментарии и продолжения строк. Записи за- даются как простые пары “ключ/значение”, разделенные пробелами, за исключением таблиц псевдонимов, в которых используются двоеточия после ключей, чтобы обеспе- чить совместимость с программой sendmail. Например, следующие строки являются характерными для таблицы псевдонимов. postmaster: david, tobias webmaster: evi В следующем примере задается таблица доступа для ретрансляции почты от любого клиента, имя узла которого заканчивается строкой cs. Colorado. edu. .cs.colorado.edu OK Текстовые файлы компилируются в бинарный формат с помощью команд postmap (для обычных таблиц) и postalias (для таблиц псевдонимов). Спецификация таблицы (включая ее тип) должна передаваться как первый аргумент. Рассмотрим пример. $ sudo postmap hash:/etc/postfix/access Команда postmap может также запрашивать значения в таблице поиска (нет совпа- дения — нет вывода на экран). $ postmap -q ЫаЫа hash: /etc/postfix/access $ postmap -q .cs.colorado.edu hash:/etc/postfix/access OK Локальная доставка Программа local доставляет почту локальным получателям. Кроме того, она обра- батывает локальные псевдонимы. Например, если параметр mydestination задан равным cs. Colorado. edu, а почта поступает на адрес evi@cs. Colorado. edu, то программа local сначала проверяет та- блицы alias maps, а затем рекурсивно заменяет все соответствующие записи. Если в таблице нет соответствия псевдонимов, программа local просматривает файл . forward в рабочем каталоге пользователя evi и следует инструкциям, заданным в этом файле, если он существует. (Синтаксис совпадает с правой частью таблицы псевдони- мов.) В заключение, если файл . forward не найден, то электронное сообщение достав- ляется в локальный почтовый ящик пользователя evi. По умолчанию программа local записывает данные в файлы, имеющие формат mbox и находящиеся в каталоге /var/mail. Эти настройки можно изменить с помощью параметров, указанных в табл. 20.22. Таблица 20.22. Параметры для доставки почты в локальный почтовый ящик ___________ (задаются в файле main.cf) Параметр% ______________________________________________ mail_spool_directory Доставляет почту в центральный каталог, обслуживающий всех пользователей home_mailbox mailbox_command mailboX—transport recipient delimiter Доставляет почту в каталог -пользователь по заданному относительному пути Доставляет почту с помощью внешней программы, обычно procmail Доставляет почту с помощью службы, определенной в файле master.cfа Разрешает расширенные имена (см. описание ниже) а Этот параметр взаимодействует с почтовыми серверами, такими как Cyrus imapd.
Глава 20. Электронная почта 883 Параметры mail_spool_directory и home_mailbox обычно генерируют почтовые ящики в формате mbox, но они также могут создавать почтовые ящики Maildir. Для того чтобы сделать это, необходимо добавить косую черту в конце имени пути. Если параметр recipient-delimiter равен + , то почта, адресованная evi+whatever@cs. Colorado. edu, принимается для доставки на учетную запись evi. С помощью этой функциональной возможности пользователь может создавать специ- альные адреса и сортировать свою почту по адресу получателя. Система Postfix снача- ла пытается выполнить поиск по полному адресу, и только если поиск оказался безу- спешным, она разбирает дополнительные компоненты и “возвращается” к базовому адресу. Система Postfix также ищет соответствующий файл пересылки . forward+vTo_ угодно для дальнейшей обработки псевдонимов. Виртуальные домены Есть три возможности организовать почтовый домен на почтовом сервере Postfix. • Указать домен в параметре mydestination. Доставка выполняется, как описано выше: псевдонимы раскрываются и почта доставляется на соответствующие учет- ные записи. • Указать домен в параметре virtual alias domains. Это позволяет оснастить домен собственным пространством адресов, которое не зависит от системных учетных записей пользователей. Все адреса внутри домена должны отображаться (с помощью ассоциативных массивов) во внешние реальные адреса. • Указать домен в параметре virtual_mailbox_domains. Как и в случае параметра virtual alias domains, домен имеет собственное пространство имен. Все по- чтовые ящики должны находиться в указанном каталоге. Домен можно указать только в одном из трех указанных параметров. Решение следует хорошенько обдумать, потому что от него зависят многие элементы конфигурации. Мы уже описывали применение метода mydestination. Рассмотрим остальные возможности. Псевдонимы виртуальных доменов Если домен указан как значение параметра virtual alias domains, то почта, на- правляемая в этот домен, будет приниматься системой Postfix и должна направляться реальному получателю либо на локальном компьютере, либо где-то еще. Перенаправление адресов в виртуальный домен должно определяться в таблице по- иска, указанной в параметре virtual_alias_maps. Записи этой таблицы в левой части содержат адрес виртуального домена, а в правой — реальный адрес получателя. Не полностью заданное имя в правой части интерпретируется как локальное имя пользователя. Рассмотрим следующий пример из файла main. cf. myorigin = cs.colorado.edu mydestination = cs.colorado.edu virtual_alias_domains = admin.com virtual_alias_maps = hash:/etc/mail/admin.com/virtual В файле /etc/mail/admin.com/virtual могут содержаться следующие строки. postmaster@admin.com evi, david@admin.com david@admin.com david@schweikert.ch evi@admin.com evi
884 Часть II. Работа в сети Почта, направляемая на адрес evi@admin. com, будет перенаправлена на адрес evi@ cs. Colorado. edu (добавлен параметр myorigin) и в итоге будет доставлена в почто- вый ящик пользователя evi, потому что имя домена cs. Colorado. edu указано как зна- чение параметра mydestination. Определения могут быть рекурсивными: правая часть может содержать адреса, ко- торые в дальнейшем определяются в левой части. Обратите внимание на то, что правая часть может быть только списком адресов. Если необходимо выполнить внешнюю про- грамму или использовать подстановку файлов с помощью инструкции : include:, то нужно перенаправить почту на псевдоним, который впоследствии может быть раскрыт в соответствии с потребностями пользователя. Для того чтобы хранить всю информацию в одном файле, можно присвоить параме- тру virtual alias domains имя той же таблицы поиска, которая задана параметром virtual alias maps, и внести в эту таблицу специальную запись, которая отмечала бы этот файл как псевдоним виртуального домена. В файле main. cf соответствующие строки выглядели бы следующим образом. virtual_alias_domains = $virtual_alias_maps virtual_alias_maps = hash:/etc/mail/admin.com/virtual Файл /etc/mail/admin. com/virtual содержал бы следующие данные. admin.com notused postmaster@admin.com evi, david@admin.com Правая часть записи для почтового домена (admin. com) на самом деле никогда не используется; наличия имени admin. com в этой таблице в качестве независимого поля уже достаточно для того, чтобы система Postfix рассматривала его как псевдоним вирту- ального домена. Виртуальные почтовые домены Домены, перечисленные в списке значений параметра virtual_mailbox_domains, аналогичны локальным доменам, но список пользователей и их соответствующие по- чтовые ящики должны управляться независимо от системных учетных записей пользо- вателей. Параметр virtual_mailbox_maps указывает на таблицу, в которой перечислены все корректные пользователи в домене. Соответствующее отображение имеет следующий вид. user@domain /path/to/mailbox Если имя пути заканчивается косой чертой, почтовые ящики хранятся в формате Maildir. Значение параметра virtual mailbox base всегда является префиксом за- данных путей. Часто возникает необходимость заменить псевдонимом некоторые адреса в виртуаль- ных почтовых доменах. Для этого следует использовать параметр virtual alias map. Рассмотрим полный пример. В файле main. cf virtual_mailbox_domains = admin.com virtual_mailbox_base = /var/mail/virtual virtual_mailbox_maps = hash:/etc/mail/admin.com/vmailboxes virtual_alias_maps = hash:/etc/mail/admin.com/valiases имеется ссылка на файл /etc/mail/admin.com/vmailboxes, который может содер- жать следующую запись. evi@admin.com nemeth/evi/
Глава 20. Электронная почта 885 Файл /etc/mail/admin. com/valiases может содержать следующую строку. postmaster@admin.com evi@admin.com Отображения виртуальных псевдонимов можно применять даже к адресам, которые не являются псевдонимами виртуальных доменов. Отображения виртуальных псевдо- нимов позволяют перенаправлять любой адрес от любого домена независимо от типа домена (канонического, виртуального псевдонима или виртуального почтового ящика). Поскольку пути к почтовому ящику могут находиться только в правой части отобра- жения виртуального почтового ящика, использование этого механизма является един- ственным способом задать псевдоним для такого домена. Управление доступом Почтовые серверы должны ретранслировать почту для третьих лиц только со сторо- ны доверенных клиентов. Если почтовый сервер перенаправляет почту от неизвестных клиентов на другие серверы, то возникает так называемая открытая ретрансляция (open relay), а это плохо. Более подробно открытая ретрансляция описана в разделе 20.10. К счастью, система Postfix по умолчанию не допускает открытой ретрансляции. На самом деле она имеет довольно строгие настройки, установленные по умолчанию; их приходится скорее смягчать, чем ужесточать. Управление доступом для транзакций SMTP конфигурируется в системе Postfix с помощью “списков ограничения доступа”. Параметры, указанные в табл. 20.23, управляют тем, что следует проверять на разных этапах сеанса SMTP. Таблица 20.23. Параметры системы Postfix для ограничения доступа в рамках протокола SMTP Параметр smtpd_client_restrictionsq smtpd-helO—restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions smtpd_etrn_restrictions По запросу на соединение К команде ELO/EHLO (начало сессии) К команде MAIL FROM (спецификация отправителя) К команде RCPT ТО (спецификация получателя) К команде DATA (тело почты) К команде ETRNа а Это специальная команда, используемая для пересылки сообщений в очереди. Наиболее важным параметром является smtpd recipient restrictions, посколь- ку управление доступом легче всего реализовать, если адрес получателя известен и можно определить, локальный он или нет. Все другие параметры из табл. 20.23 в конфи- гурации, заданной по умолчанию, остаются пустыми. По умолчанию параметр smtpd_ recipient_restrictions имеет следующее значение. smtpd_recipient_restrictions - permit_mynetworks, reject_unauth_destination Каждое из указанных ограничений проверяется по очереди, пока не будет принято определенное решение о том, что делать с почтой. Общие ограничения перечислены в табл. 20.24. С помощью этих ограничений можно проверить все, а не только специфическую ин- формацию наподобие адреса отправителя в параметре smtpd sender restrictions. Следовательно, для простоты, можно наложить все ограничения, используя только один
886 Часть II. Работа в сети параметр, которым должен быть параметр smtpd_recipient_restrictions, посколь- ку только он позволяет проверять все (за исключением части DATA). Таблица 20.24. Общие ограничения доступа в системе Postfix check_client_access Проверяет адрес узла клиента, просматривая таблицу поиска check_recipient_access Проверяет почтовый адрес получателя, просматривая таблицу поиска permit_mynetworks Предоставляет доступ адресам, перечисленным в списке mynetworks re j ect unauth dest inat ion Отклоняет почту для нелокальных получателей; отменяет ретрансляцию Параметр smtpd_recipient restriction позволяет также проверять ретранслиру- емую почту. Ограничения, заданные параметром reject unauth destination, следует сохранить и с осторожностью выбирать “разрешающие” ограничения, предшествующие ему. Таблицы доступа Каждое ограничение возвращает одно действие, указанное в табл. 20.25. Таблицы доступа используются в ограничениях check_client access и check_recipient_ access для выбора действия, зависящего от адреса клиентского узла или адреса получа- теля соответственно. Таблица 20.25. Действия для таблицы доступа Д^ЙСТВЙ|к,;- 4пп текст Возвращает код временной ошибки 4nn и сообщение text 5пп текст Возвращает код постоянной ошибки 5пп и сообщение text DEFER_IF_PERMIT Если результатом оценки ограничения является действие permit, изменяет его на временную ошибку DEFER_IF_REJECT Если результатом оценки ограничения является действие reject, изменяет его на временную ошибку DISCARD Принимает сообщение, но скрытно удаляет его DUNNO Делает вид, что ключ не был найден; проверяет дальнейшие ограничения FILTER транспорт:пункт_ назначения Пропускает почту через фильтр транспорт: пункт_назначения? HOLD Блокирует почту в очереди OK Принимает почту PREPEND заголовок Добавляет заголовок в сообщение REDIRECT адрес Перенаправляет данное сообщение на конкретный адрес REJECT Отклоняет почту WARN сообщение Заносит указанное сообщение в регистрационный журнал аСм. ниже раздел, посвященный борьбе со спамом и вирусами в системе Postfix. В качестве примера предположим, что мы хотим разрешить ретрансляцию для всех компьютеров в домене cs. Colorado. edu и отправку сообщения списку внутренней рассылки newsletter@cs. Colorado. edu только доверенным клиентам. Эти правила можно реализовать с помощью следующих строк в файле main. cf.
Глава 20. Электронная почта 887 smtpd_recipient_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/relaying_access reject_unauth_destination check_recipient_access hash:/etc/postfix/restricted_recipients Обратите внимание на то, что запятые являются необязательными, если указан спи- сок значений параметра. В файл /etc/postfix/relaying_access следует внести следующую строку. .cs.colorado.edu ОК В файл /etc/postfix/restricted_recipients следует внести такую строку. newsletter@cs.colorado.edu REJECT Internal list Текст, следующий за словом REJECT, является необязательной строкой, которая по- сылается клиенту вместе с кодом ошибки. Он сообщает отправителю, почему сообще- ние было отклонено. Аутентификация клиентов и шифрование Для пользователей, отправляющих сообщения из дома, обычно проще всего направ- лять исходящую почту через домашний почтовый сервер интернет-провайдера, незави- симо от адреса отправителя сообщения. Большинство интернет-провайдеров доверяют своим непосредственным клиентам и разрешают ретрансляцию. Если эта конфигурация невозможна или используется система Sender ID или SPF, то следует убедиться, что мо- бильные пользователи, находящиеся вне сети, могут быть авторизованы для представле- ния сообщений демону smtpd. Решить эту проблему можно, используя механизм SMTP AUTH непосредственно на уровне SMTP. Для этого систему Postfix необходимо скомпилировать с библиотекой SASL. Затем эту функциональную возможность можно конфигурировать следующим образом. smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated Вам также понадобится поддержка зашифрованных соединений, чтобы избежать от- правки паролей открытым текстом. Добавьте в файл main. cf строки, похожие на сле- дующие. smtpd_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_cert_file = /etc/certs/smtp.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_protocols = !SSLv2 Необходимо также поместить правильно подписанный сертификат в файл /etc/ certs/smtp.pem. Кроме того, рекомендуется подключить шифрование на исходящие соединения SMTP. smtp_tls_security_level = may smtp_tls_loglevel = 1
888 Часть II. Работа в сети Борьба со спамом и вирусами Система Postfix имеет много функциональных возможностей, помогающих блокиро- вать подозрительную электронную почту. Один класс защитных функциональных воз- можностей предназначен для строгой реализации протокола SMTP. Законопослушный почтовый сервер должен следовать протоколу, но отправители спама и вирусов часто спешат и пренебрегают этим требованием, тем самым выдавая себя. К сожалению, не- исправные обработчики почты, обеспечивающие легитимность такой почте, все еще су- ществуют, поэтому такой метод нельзя считать панацеей. Следует тщательно выбирать ограничения и отслеживать регистрационные файлы. Перечислим некоторые основные функциональные возможности, относящиеся к данной категории. • reject non fqdn * — отклоняет сообщения, не имеющие полностью опреде- ленного домена отправителя (sender), домена получателя (recipient) или име- ни узла HELO/EHLO (hostname). • reject unauth pipelining — прекращает сеанс, если клиент не ждет, чтобы увидеть статус команды до обработки. • re j ect unknown sender domain — отклоняет сообщения с нераспознанным до- меном отправителя. Система Postfix возвращает сообщение о временной ошибке, потому что эта проблема может быть результатом временного сбоя системы DNS. • re j ect_unknown_reverse_client_hostname — отклоняет сообщения от узлов> не имеющих обратных записей DNS. 1 • smtpd helo required — запрашивает команды HELO/EHLO в начале обмена' информацией (параметр, принимающий значение yes или по). • strict rf c821_envelopes — требует правильного синтаксиса для адресов элек-! тронной почты в командах MAIL FROM и RCPT ТО (параметр, принимающий значения yes или по). Все перечисленные выше параметры не являются ограничениями. Мы вызываем их, включая их имена в параметры smtpd_helo_restrictions (reject_non_fqdn_*) или smtpd client restrictions (другие). Для проверки ограничения до включения его в процесс (настоятельно рекомендуем), вставьте ограничение warn if reject перед ним, чтобы преобразовать эффект от прямого отказа принимать почту в предупреждения^ Черные списки Вы можете заставить систему Postfix сравнивать входящие сообщения с черным спи- ском, основанным на системе DNS; подробнее эта процедура описана в разделе 20.10. Для того чтобы воспользоваться этой функциональной возможностью, используется ограничение reject rbl client с указанным адресом сервера DNS, с которым прово- дится сверка. Аналогичная функциональная возможность reject rhsbl sender про- веряет имя домена в адресе отправителя, а не имя узла клиента. Пример борьбы со спамом В следующем примере продемонстрирована относительно полная конфигурация из файла main. cf, предназначенная для борьбы со спамом. strict_rfc821_envelopes = yes smtpd_helo_required = yes
Глава 20. Электронная почта 889 smtpd_recipient_restrictions = rej ect_unknown_sender_domain rej ect_non_fqdn_sender rej ect_non_fqdn_recipient permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/relaying_access rej ect_unauth_destination reject_unauth_pipelining reject_unknown_reverse_client_hostname reject_rbl_client zen.spamhaus.org permit Обратите внимание на то, что мы поместили некоторые ограничения перед параме- тром permit mynetworks. Это позволяет проверить, посылают ли собственные клиен- ты правильно отформатированные сообщения. Это простой способ найти ошибки кон- фигурации. Заключительное действие permit задается по умолчанию и приведено явно лишь для наглядности. Программы SpamAssassin и procmail Система Postfix поддерживает работу программы SpamAssassin и других аналогичных фильтров. Общая информация об этих инструментах приведена в разделе 20.6. Программу procmail можно запустить из пользовательских файлов . forward, но это сложный и уязвимый для ошибок способ запуска. Лучше поместить в файл main.cf следующую строку. mailbox_command = /usr/bin/procmail -a "$EXTENSION" Система Postfix впоследствии использует программу procmail для доставки почты вместо записи сообщений непосредственно в почтовую очередь. Аргументы программы procmail содержат расширение адреса (фрагмент, следующий за знаком +); впослед- ствии к ним можно обращаться с помощью программы procmail, указывая ссылку $1. Демоны политики В системе Postfix 2.1 реализован механизм для делегирования управления доступом внешним программам. Эти программы, именуемые демонами политики (policy daemons), получают всю информацию, которую система Postfix имеет о сообщении, и возвращают одно из действий, перечисленных в табл. 20.25. Серые списки — одна из более интересных функциональных возможностей, кото- рую можно реализовать с помощью демона политики. Более подробную информацию о серых списках и ситуациях, в которых они могут понадобиться, можно найти в раз- деле 20.6. Фильтрация содержимого Система Postfix может использовать регулярные выражения для проверки заголовков и тел электронных сообщений, используемых как контрабанда. Она также передает со- общения другим программам, например специализированным программам для борьбы со спамом или антивирусным приложениям. Проверки заголовка и тела выполняются в реальном времени в ходе приема сообще- ния по протоколу SMTP. В случае совпадения каждое проверяемое регулярное сообще- ние вызывает действие, указанное в табл. 20.25. Например, строка header_checks - regexp:/etc/postfix/header_checks
890 Часть II. Работа в сети в файле main. cf в сочетании со строкой из файла /etc/postf ix/header_checks /ASubject: reject-me/ REJECT You asked for it приведет к отказу от приема любого сообщения, тема которого начинается со слов “reject-me”. Несмотря на то что поддержка регулярных выражений всегда работает от- лично, в контексте обработки электронных сообщений она имеет несколько недостат- ков. В частности, она неэффективна для борьбы со спамом и фильтрации вирусов. Фильтрация содержимого с помощью программы amavisd Промышленная фильтрация вирусов, как правило, осуществляется с помощью про- граммы amavisd (см. раздел 20.6), которая написана на языке Perl и связывает про- граммное обеспечение почтового сервера с одним или несколькими антивирусными приложениями. Такие фильтры конфигурируются параметром content filter про- граммы, который заставляет программу Postfix передавать все входящие сообщения ука- занной службе. Кроме настройки параметра content f ilter, системный администра- тор должен модифицировать несколько существующих записей в файле master .cf и добавить несколько новых. Система Postfix и программа amavisd взаимодействуют друг с другом посредством стандартных протоколов SMTP и LMTP. Система Postfix посылает почту для анализа программе amavisd посредством протокола LMTP. Программа amavisd сканирует ее и посылает обратно в систему Postfix в рамках протокола SMTP на альтернативный порт, доступный только для локального компьютера, на котором отключено сканирование со- держимого (чтобы избежать замкнутого круга). Ожидая почту, поступающую из Интернета, программа amavisd обычно прослуши- вает порт 10024, а для системы Postfix предназначен резервный nojyr 10025. Для обра- ботки исходящей почты и отделения ее от входящей почты необходимо использовать специальный порт для программы amavisd, например 10026. Входящая почта может вернуться в систему Postfix через тот же порт возврата, что и исходящая почта. Конфигурация, описанная ниже, представляет собой настройку “очереди с после- дующей обработкой” (post queue), которая сканирует почту после того, как она окажется в почтовой очереди системы Postfix. Если вы хотите реализовать сканирование на лету (in-line scanning), при котором почта сканируется в процессе первоначального диалога с клиентом по протоколу SMTP, запустите вспомогательную программу amavisd-milter, позволяющую присоединить программу amavisd как почтовый фильтр. На стороне программы amavisd необходимо убедиться, что ее конфигурация содер- жит следующие строки. (Эта конфигурация использует разные порты для исходящих и входящих сообщений.) $inet_socket_port = [10024,10026]; $notify_method = 'smtp:[127.0.0.1]:10025’; $forward_method = 'smtp:[127.0.0.1]:10025'; $interface_policy{'10026'} = 'ORIGINATING'; $policy_bank{'ORIGINATING'} = { originating => 1, # indicates client is ours }; Почтовый агент Postfix необходимо настроить на отправку почты программе amavisd. Файл README. Postfix в дистрибутивном пакете amavisd-new включает около 20 строк готовой конфигурации, которые можно поместить в файл /etc/postfix/ master. cf, чтобы программа amavisd была доступной и могла посылать почту обрат-
Глава 20. Электронная почта 891 но системе Postfix. Мы не повторяем их здесь; просто скопируйте их из файла README и вставьте в файл /etc/postfix/master.cf. Для того чтобы заставить систему Postfix посылать почту программе amavisd на ска- нирование, добавьте в файл main. cf следующую строку. content_filter = amavisfeed:[127.0.0.1]:10024 Для того чтобы отличать входящую почту от исходящей, конфигурацию придется немного усложнить. Вместо директивы, приведенной выше, необходимо использовать следующую модификацию ограничения smtpd_recipient_restrictions (изменения выделены полужирным шрифтом). smtpd_recipient_restrictions = rej ect_unknown_sender_domain rej ect_non_fqdn_sender rej ect_non_fqdn_recipient check_sender_access regexp: /etc/postfix/ tag_as__or iginating. re permit_mynetworks permit_sasl_authenticated check__sender__access regexp: /etc/postfix/tag__as—foreign. re check_client_access hash:/etc/postfix/relaying_access reject_unauth_destination rej ect_unauthjpipelining reject_unknown_reverse_client_hostname reject_rbl_client zen.spamhaus.org permit Затем поместите в файл tag_as_or iginating. re строку /Л/ FILTER amavisfeed:[127.0.0.1]:10026 и добавьте в файл tag_as_foreign. re следующую строку. /Л/ FILTER amavisfeed:[127.0.0.1]:10024 Почта от внешних узлов соответствует ограничению tag__as_foreign. re, которое заставляет систему Postfix фильтровать почту, посылая ее на порт 10024. Вся почта соот- ветствует ограничению tag as originating. re, а для почты, поступающей от внеш- них узлов, применяются ограничения, в именах которых содержится слово foreign. Отладка Если в системе Postfix возникает проблема, в первую очередь следует проверить ре- гистрационные файлы. Ответы на возможные вопросы, скорее всего, найдутся в этих файлах; просто надо их поискать. Каждая программа в системе Postfix обычно создает регистрационную запись для каждого обработанного сообщения. Например, ниже при- веден пример регистрационных записей для исходящего сообщения. Aug 18 22:41:33 nova postfix/pickup: 0Е4А93688: uid=506 from=<dws@ee.ethz.ch> Aug 18 22:41:33 nova postfix/cleanup: 0E4A93688: message-id= <20040818204132.GA11444@ee.ethz.ch> Aug 18 22:41:33 nova postfix/qmgr: 0E4A93688: from=<dws@ee.ethz.ch>, size=577,nrcpt=l (queue active) Aug 18 22:41:33 nova postfix/smtp: 0E4A93688: to=<evi@ee.ethz.ch>,relay=tardis.ее.ethz.ch[129.132.2.217], delay=0, status=sent (250 Ok: queued as 154D4D930B) Aug 18 22:41:33 nova postfix/qmgr: 0E4A93688: removed
892 Часть II. Работа в сети Легко видеть, что интересующая нас информация разбросана по нескольким стро- кам. Обратите внимание на то, что идентификатор 0Е4А93688 встречается на каждой строке: система Postfix присваивает идентификатор очереди сразу, как только сообщение поступает в почтовую систему, и никогда не изменяет его. Следовательно, при поиске регистрационных записей об истории сообщения в первую очередь следует определить идентификационный номер сообщения в очереди. Узнав его, легко применить команду grep ко всем релевантным записям. Система Postfix делает подробные записи о замеченных ею проблемах. Однако иногда трудно найти важные строки среди тысяч сообщений о нормальном состоянии. В этом слу- чае целесообразно использовать некоторые инструменты, перечисленные в разделе 11.5. Просмотр очереди Еще одно место, где следует искать решение проблем, — почтовая очередь. Как и в системе sendmail, команда mailq выводит на печать содержание очереди. Его можно использовать, для того чтобы выяснить причину задержки сообщения. Полезным инструментом является также сценарий qshape, который поставляется с последними версиями системы Postfix. Он демонстрирует суммарные статистические показатели о содержании очереди. Его вывод выглядит следующим образом. $ sudo qshape deferred Т 5 10 20 40 80 160 320 640 1280 1280+ TOTAL 78 0 0 0 7 3 3 2 12 2 49 expn.com 34 00000 0 0 9 0 25 chinabank, ph 500011 1 2 0 0 0 prob-helper.biz 300000 0 0 0 0 3 Сценарий qshape создает отчет о заданной очереди (в данном случае об очереди от- ложенных сообщений), упорядоченной по доменам получателя. В столбцах отчета ука- зывается, сколько минут релевантное сообщение провело в очереди. Например, в отчете видно, что 25 сообщений, направленных в домен expn. сот, провели в очереди более 1280 минут. Все пункты назначения в данном примере вызывают подозрения, что со- общения были посланы автоответчиком в ответ на спам. / Сценарий qshape также создает отчет в соответствии с доменами отправителей, если он запущен с флагом -s. Мягкий рикошет Если параметр sof t bounce установлен равным yes, система Postfix посылает со- общения о временных ошибках вместо сообщений о постоянных ошибках, таких как “пользователь неизвестен” или “ретрансляция запрещена”. Этот параметр предоставля- ет отличную возможность для тестирования; он позволяет отслеживать местонахождение сообщения после изменения конфигурации без риска потери законной электронной по- чты. В этом случае любой отказ в конце концов приводит к повторной попытке доставки. Не забудьте отключить эту функциональную возможность, когда закончите тестиро- вание, иначе попытки доставки отвергнутой почты будут повторяться снова и снова. Тестирование управления доступом Легче всего проверить ограничения управления доступом, попытавшись послать со- общение с внешнего узла и посмотрев, что произойдет. Это хороший тест, но он не охва- тывает специальные условия, например, когда почта поступает из домена, в котором у вас нет учетной записи.
Глава 20. Электронная почта 893 Система Postfix 2.1 внедрила расширение протокола SMTP, который называется XCLIENT и имитирует представление из другого места. Эта функциональная возмож- ность по умолчанию отключена, но с помощью следующей строки конфигурации из файла main. cf вы можете включить ее для соединений, исходящих из локального узла. smtpd_authorized_xclient_hosts = localhost Сеанс тестирования может выглядеть примерно так. $ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is ,Л]'. 220 tardis.ee.ethz.ch ESMTP Postfix XCLIENT NAME=mail. cs. Colorado. edu ADDR=192.168.1.1 250 Ok HELO mail. cs. Colorado. edu 250 tardis.ee.ethz.ch MAIL FROM: <evi@Colorado .edu> 250 Ok RCPT TO: <david@Colorado.edu> 554 <david@colorado.edu>: Relay access denied 20.16. Конфигурация механизма DKIM Наше описание технологии DKIM не сосредоточено в одной главе. Вступительный материал содержится в главе о системе DNS (раздел 17.8), а также в разделе 20.8. Здесь мы сосредоточимся на деталях, связанных с использованием технологии DKIM в элек- тронной почте как с помощью внешнего инструмента amavisd, так и непосредствен- но в сочетании с системами sendmail, Exim и Postfix. Системы sendmail и Postfix для реализации технологии DKIM используют почтовые фильтры; система Exim делает это непосредственно. Реализация технологии DKIM в системе Exim является новой (конец 2009 года) и остается не до конца отработанной. Технология DKIM: DomainKeys Identified Mail Технология DKIM — это новая надежда на правильную идентификацию организации отправителя. При широком развертывании она способна резко ограничить возможности злоумышленников для подделки домена отправителя. Тогда почта от вашего банка мо- жет быть действительно почтой, посланной вашим банком, или, по крайней мере, клас- сифицироваться как почта, которая не является фишингом или спамом. Технология DKIM вытесняет прежнюю систему DomainKeys; она использует крип- тографию с открытым ключом (с ключами, хранящимися в системе DNS), чтобы позво- лить получателям проверять как источник сообщения, так и его целостность. Это ста- новится важным в глобальном мире, где так много сделок совершается в электронном виде. Система DKIM также не позволяет отправителю отрицать, что это он отправил сообщение; так называемый отказ от авторства. Реализация системы DKIM имеет две стороны: та, которая подписывает исходящую почту, когда она покидает ваш сайт, и та, которая проверяет подписи входящей почты в момент ее поступления. Первая операция должна выполняться концентратором исходящей почты непосред- ственно перед тем, как почта покинет ваш сайт (после всех внутренних переписываний и сканирования содержания). Вторая операция, верификация, должна выполняться сразу
894 Часть II. Работа в сети после получения сообщения, перед добавлением другого инструмента сканирования или изменения заголовков. На сайте sendmail. org есть много удобных и универсальных инструментов, кото- рые могут использоваться любым программным обеспечением, реализующим техноло- гию DKIM. Первым является мастер ADSP, принимающий имя домена и генерирующий соответствующие текстовые ADSP ТХТ , которые вы должны добавить в систему DNS, чтобы реализовать технологию DKIM.21 Второй инструмент — это верификатор, с по- мощью которого можно проверить свои настройки после завершения приготовлений к работе. Детали технологии DKIM и ресурсных записей ADSP изложены в разделе 17.8. Они до сих пор остаются текстовыми, хотя в будущем будут преобразованы в тип собствен- ной базы данных о ресурсах DNS. Программы OpenSSL и amavisd содержат код для ге- нерации ключей DKIM. Кроме того, различные пакеты почтовых фильтров DKIM также содержат сценарии для генерации ключей. Настроив конфигурацию вашего почтового транспортного агента так, чтобы он гене- рировал подписи DKIM, вы можете послать сообщение по адресу sa-test@sendmail. net, чтобы проверить, что все работает правильно. Сервер пришлет вам сообщение, в котором укажет, какие функции безопасности он распознал. Если у вас есть учетная за- пись в системе Gmail, то проверить эти возможности можно, послав сообщение само- му себе. Щелкнув на ссылке “show details”, вы раскроете подписанное поле. Вы може- те также попросить систему Gmail выполнить команду “Show original” в выпадающем меню. Эта команда показывает исходное сообщение со всеми его заголовками, включая подпись DKIM. Почтовые фильтры DKIM Программное обеспечение для реализации технологии DKIM изначально было раз- работано корпорацией Sendmail, Inc., для того, чтобы использовать его как почтовый фильтр при взаимодействии с транспортным агентом программы sendmail. Существует две версии этого кода: оригинальная, DKIM-milter; и альтернативная, OpenDKIM. Оба пакета доступны с исходным кодом на сайте sourceforge. net и в скомпилирован- ном виде в разных репозиториях пакетов. Мы проиллюстрируем версию для программы sendmail под названием DKIM-milter v2.8.3. Этот пакет содержит программу dkim-filter, почтовый фильтр, создающий и про- веряющий подписи, и несколько утилит для отладки и отслеживания эксплуатации. Ниже приведен список этих утилит. • dkim-f ilter — генерирует и верифицирует подписи DKIM. • dkim-genkey — генерирует пары ключей и требуемые записи DNS. • dkim- stats — создает отчеты на основе статистических данных, собранных ути- литой dkim-f ilter. • dkim-testkey — проверяет, имеют ли ключи правильный формат и являются ли они доступными. • dkim-testssp — проверяет запись ADSP (которая ранее называлась SSP). 21 Не публикуйте записи ADSP, пока система подписи исходящих сообщений на будет нала- жена и не станет правильно работать, иначе другие сайты не будут принимать вашу электронную почту.
Глава 20. Электронная почта 895 На первом этапе настройки пакета DKIM-milter необходимо создать специальную учетную запись пользователя и группы для своих собственных файлов, связанных с тех- нологией DKIM. Для обеих записей следует использовать имя “dkim”. При этом необ- ходимо убедиться, что учетная запись имеет ограниченную оболочку, например /bin/ false. Утилита dkim-genkey генерирует пару ключей DKIM. Домен, для которого предна- значен ключ, задается с помощью флага -d, а селектор (т.е. имя ключа) — с помощью флага -s. По умолчанию они имеют значения example. com и “default”. Флаг -г огра- ничивает использование ключа только подписанием электронной почты, а флаг -t означает, что вы тестируете систему DKIM. Ключи сохраняются в отдельных файлах: селектор.private (для закрытого ключа) и селектор, txt (для текстовой записи DNS, содержащей открытый ключ). Например, инструкция $ dkim-genkey -г -d example.com -s email генерирует пару ключей в файлах email .private и email. txt, находящихся в теку- щем каталоге. Инсталлируйте закрытый ключ где-нибудь, например, в каталоге /etc/mail/dkim/ keys. Установите режим каталога /etc/mail/dkim равным 600 и примените команду chown (рекурсивно) к пользователю и группе dkim. Добавьте запись TXT системы DNS в соответствующий зонный файл, введите порядковый номер зоны и пошлите сигнал вашему серверу имен. После окончания проверки всей системы можно добавить запись ADSP, но раньше этого делать не следует. Запустите утилиту dkim-testkey, чтобы проверить правильность ключей. Эта ути- лита не создает вывода, если все в порядке, поэтому молчание в данном случае — дей- ствительно золото. На следующем этапе необходимо задать конфигурацию утилиты dkim-filter для ее использования в качестве почтового фильтра. Создайте файл /etc/mail/dkim. conf, владельцем которого является пользователь и группа dkim. Ниже приведен пример, по- заимствованный из статьи T.J. Nelson Setting up DKIM with Sendmail. Canonicalization simple Domain mail.example.com KeyFile /etc/mail/dkim/keys/email.key.pern MTA MSA PidFile /var/run/dkim-filter.pid Selector email Socket inet:8891@localhost SignatureAlgorithm rsa-shal Syslog Yes UserID dkim X-Header Yes Mode sv InternalHosts /etc/mail/dkim-internal-hosts Общий формат записей в файле dkim. conf имеет следующий вид. параметр значение Символ # означает начало комментария. Дистрибутивный пакет содержит хорошо прокомментированный пример конфигурации dkim-filter.conf.sample, включа- ющий описание переменных и их значения, заданные по умолчанию. На справочной странице dkim-filter.conf можно найти еще более подробное описание.
896 Часть II. Работа в сети При настройке конфигурации центрального почтового концентратора строка Domain должна содержать список полностью определенных имен доменов, предназначенных для подписи, разделенных запятыми, или имя файла, в котором содержится этот список. Параметр KeyFile задает местоположение закрытого ключа, используемого для подписи сообщений. Предполагается, что первая часть имени этого файла представля- ет собой селектор (в данном случае “email”). Строка МТА содержит список имен транс- портных агентов, чья почта всегда должна подписываться, а не верифицироваться. Она аналогична части Name параметра DAEMON_O PT IONS в конфигурации программы sendmail. Спецификация Socket идентифицирует прослушивающий сокет TCP; в данном слу- чае он прослушивает порт 8891 на локальном узле. Параметр SignatureAlgorithm мо- жет принимать значения rsa-shal или rsa-sha256; второе значение задается по умол- чанию, но, поскольку этот алгоритм является относительно новым, его поддерживают не все транспортные агенты. Параметр X-Header указывает, что dkim-filter должен добавить строку заголовка в каждое сканируемое сообщение. Параметр Mode может иметь значение s (для подписи), v (для верификации) или sv (для обоих режимов). Параметр internalHosts должен ссылаться на файл, содержащий список узлов, ис- ходящая почта которых должна быть подписана. Узлы должны быть перечислены с пол- ностью определенными именами. Несколько параметров конфигурации позволяют облегчить отладку. К ним относятся параметры MilterDebug, LogWhy и SyslogSuccess. Некоторые из них генерируют так называемую регистрационную информацию, которую после отладки следует отключить. Другие параметры указывают, что делать с сообщениями, подписи которых не могут быть верифицированы: On-Default, On-BadSignature, On-DNSError, On-Security, On-InternalError и On-NoSignature. Каждый из них принимает значения reject, tempfail, accept и discard. Система допускает гибкую конфигурацию и имеет много параметров (более 80), ко- торые описаны на справочной странице dkim-filter .conf. Конфигурация DKIM в программе amavisd-new Для использования технологии DKIM в программе amavisd-new необходимо иметь модуль Mail: : DKIM версии 0.33 или выше, написанный на языке Perl. Если такого мо- дуля нет, загрузите его с сайта CPAN. Вы должны сгенерировать пару ключей, включить режим верификации и подписи DKIM, указать файл, содержащий закрытый ключ, и за- дать некоторые параметры подписи. Программа amavisd может генерировать ключи для системы DKIM самостоятельно. $ amavisd genrsa /var/db/dkim/example, com-email, key. pern Еще одним аргументом программы amavisd является имя файла, в котором хранятся ключи. Поскольку он содержит и закрытый, и открытый ключи, лучше всего проверить разрешения и убедиться, что этот файл невозможно прочитать извне и несанкциониро- ванный доступ к нему закрыт. Следующий фрагмент конфигурации был немного изменен по сравнению с разделом документации amavisd-new под названием “Bits and pieces.” В этом примере мы пред- полагаем, что домен вашего сайта называется example. com и что вы используете селек- тор “email” для своих ключей. $enable_dkim_verification = 1; $enable_dkim_signing = 1;
Глава 20. Электронная почта 897 dkim_key('example.com', 'email', '/vaг/db/dkim/example.com-email.key.pern'); @dkim_signature_options_bysender_maps = ( { '.'=>{ ttl => 21*24*3600, c => 'relaxed/simple' } } ); Omynetworks = qw(127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16); Строка с параметрами подписи DKIM позволяет заменить дескрипторы, заданные по умолчанию и хранящиеся в ассоциативном массиве. Подписи могут иметь 13 разных значений дескрипторов. Многие дескрипторы, такие как дескриптор d, который задает домен отправителя, устанавливаются автоматически. Важным дескриптором является s, который задает селектор, предназначенный для использования при запросе у системы DNS открытого ключа для верификации подписи. В данном примере мы заменили зна- чение параметра ttl, задающего срок действия ключа, с 30 дней на 21. Некоторые де- скрипторы становятся важными при ретрансляции почты (например, через списки рас- сылки), если вы хотите сохранить возможность подписания таких сообщений. Присвоив булевы значения ассоциативному массиву signed header fields, мож- но задать поля заголовков, которые должны быть включены в подпись. Например, ин- струкции $signed_header_fields{'received'} = 0; $signed_header_fields{'sender'} = 1; $signed_header_fields{'to'} = 1; $signed_header_fields{'cc'} = 1; исключают заголовок Received (Получено), но включают Sender (Отправитель), То (Кому) и Сс (Копии). Значения, заданные по умолчанию, вероятно, подойдут для боль- шинства сайтов. Для тестирования конфигурации можно использовать инструкции amavisd showkeys и amavisd testkeys. Команда showkeys выводит на печать открытый ключ, который необходимо добавить в зонный файл для домена example. com. (Не забудьте изменить порядковый номер зоны и отправить сигнал вашему серверу имен!) Команда testkeys проверяет как процесс подписания, так и тот факт, что ваш ключ был опубли- кован в системе DNS. Технология DKIM в системе sendmail Используя почтовые фильтры (для оперативной фильтрации, описанной в разде- ле 20.6) или дублирующий сервер в сочетании с программой amavisd, можно реали- зовать технологию DKIM для программы sendmail. Здесь мы опишем использование почтовых фильтров DKIM для подписания и верификации сообщений. Примитивы masquerade as и genericstable конфигурации программы sendmail переписывают заголовки, поэтому эти примитивы должны быть реализованы до добав- ления любых подписей DKIM, в противном случае подпись станет недействительной. Для поддержки технологии ОЙМ системный администратор должен скомпилиро- вать программу sendmail с поддержкой почтовых фильтров, иметь доступ к библиоте- кам OpenSSL и Berkeley DB и инсталлировать пакет DKIM-milter (который можно най- ти на сайте sourceforge. net). Библиотека OpenSSL используется для генерирования ключей. Следует добавить ее в свою зону DNS, как указано в разделе 17.8, или исполь- зовать утилиту dkim-genkey, как показано выше. В данном примере наш домен называется example.com. Мы выбрали селектор “email” и сохранили наш закрытый ключ в файле email .private, а открытый ключ — в файле email .key .pem. Проверить ключи можно с помощью утилиты dkim-testkey. $ dkim-testkey -d example.com -k /var/db/dkim/email .key.pem -s ma
898 Часть II. Работа в сети Если все в порядке, утилита dkim-testkey не выведет никаких результатов. Добавьте в конфигурационный файл sendmail .тс программы sendmail строку INPUT MAIL_FILTER ('dkim-filter', 'S=inet:8891@localhost’) и повторите сборку файла sendmail. cf (с помощью инструкций . /Build sendmail. cf; sudo make install-cf). Затем заново запустите программу sendmail и утилиту dkim-filter. Технология DKIM в системе Exim Выпуск Exim 4.70 (конец 2009 года) добавил естественную поддержку технологии DKIM и перестал поддерживать технологию DomainKeys компании Yahoo!. Ожидается, что набор его функциональных возможностей будет расширяться по мере исправления ошибок и приобретения опыта работы с технологией DKIM. Поддержка технологии DKIM в системе Exim включена по умолчанию. Для того что- бы ее отключить, установите значение DlSABLE_DKIM=yes в файле Local/Makefile, а затем соберите и заново инсталлируйте пакет. Реализация системы Exim подписывает исходящие сообщения в конфигурации транспортного протокола SMTP и верифицирует входящие сообщения с помощью но- вого списка управления доступом acl_smtp_dkim. Концентраторы могут отключать ве- рификацию подписей на сообщениях, которые они ретранслируют на локальные узлы, установив для этих сообщений параметр dkim_disable__verify. Подписание исходящих сообщений Первое действие при реализации технологии DKIM — генерация криптографических ключей с помощью библиотеки OpenSSL (см. раздел 17.8). Для транспортного протокола SMTP необходимо определить несколько новых параметров системы Exim. Эти параме- тры могут включать переменные, которые должны раскрываться при вызове транспорта. Список параметров подписей, связанных с технологией DKIM, приведен в табл. 20.26. Таблица 20.26. Параметры подписей DKIM в системе Exim Параметр ' к® dkim_domain строка да Подписываемый домен dkim_selector строка да Селектор ключа (имя) dkim_private_key строка да Закрытый ключ или файл, который его содержит dkim_canon строка нет Метод канонизации: simple или relaxed dkim_strict строка нет Если true, то из-за ошибок в подписи сообщение возвращается в очередь dkim_sign_headers строка нет Заголовок для включения в подпись Первые три параметра являются обязательными и должны быть заданы в конфигу- рации; остальные параметры носят факультативный характер. По умолчанию для кано- низации (dkim canon) используется метод relaxed, сообщения, вызывающие ошибки в подписях, посылаются без подписей (dkim strict), а система Exim для подписи ис- пользует список заголовков RFC4871 (dkim sign headers). Обязательные параметры не требуют дополнительных объяснений, но в сложном сайте, содержащем несколько реальных и виртуальных доменов, их настройка требует определенного опыта.
Глава 20. Электронная почта 899 Верификация входящих подписанных сообщений Входящие почтовые сообщения, подписанные по технологии DKIM, проверяются с помощью списка управления доступом acl smtp dkim. Этот список вызывает каж- дую подпись и возвращает один из нескольких кодов. • попе — сообщение не подписано. • invalid — подпись невозможно верифицировать (ключ недоступен или некор- ректен). • fail — подпись не прошла верификацию заголовка, тела или и того, и другого. • pass — подпись является корректной. Статус сообщения записывается в переменную $dkim_verify_status, а инфор- мация об ошибках — в переменную $dkim_verif у reason. Существует много других дескрипторов вида $dkim_nepeMeHHan, предоставляющих доступ к разным полям под- писи и позволяющих реализовать специальную политику (например, маркировку сооб- щений от сайта gmail. com, которые не имеют подписей, или отказ от приема сообще- ний от сайта paypal. com, которые не поддаются верификации). Законченный пример Следующий пример позаимствован из настроек системы DKIM, предложенных Филом Пенноком.22 Она содержит определения параметра acl_process_dkim для ве- рификации подписей, а также маршрутизатора и транспорта (dnslookup signed и remote dksign соответственно) для создания реальных подписей. Эта конфигурация позволяет подписывать несколько доменов и использовать не- сколько ключей, чтобы осуществлять их смену. Этот файл хранится в формате CDB и отображает ключи вида “example.ofg” в значения вида “6200912.” Селектор ключа называется dyyyymm, где d — это просто первая буква слова “date” (дата), уууу - это год, в котором был сгенерирован ключ, а шт - месяц, в котором он был сгенерирован. Файлы с ключами называются rsa. private, селектор .домен и хра- нятся в каталоге ключей, определенном макросом DKKEY_DIR. Убедитесь, что этот ката- лог доступен для системы exim и не доступен для всего остального мира. # ####### macros to define the directories for databases and keys CONFIG_DIR - path_to_config_dir DKKEY_DIR = path_to_key_dir # ####### main section: define the domains to sign and required DKIM acl domainlist dksign_domains = cdb;CONFIG_DIR/dk.selector.cdb acl_smtp_dkim - acl_process_dkim # ####### ACL section: verify signature on incoming mail, add a header acl_process_dkim: warn !dkim_status = none add_header = :at_start:X-DKIM-Report: $dkim_verify_status ${if !eq{$dkim_verify_status}{pass}{$dkim_verify_reason }{}} (Signer=$dkim_cur_signer) (Testing=$dkim_key_testing) ######## Router section: put just before "dnslookup" router, sign nonlocal dnslookup_signed: driver = dnslookup 22 Фил является активным участником группы рассылки для пользователей системы Exim.
900 Часть II. Работа в сети domains = !+local_domains transport = remote_dksign condition = ${if match_domain{$sender_address_domain} {+dksign_domains}} no_verify ######## Transport section: does the actual signing remote_dksign: driver = smtp dkim_domain = $sender_address_domain dkim_selector = ${lookup {$sender_address_domain} cdb{CONFIG_DIR/dk.selector.cdb} {$value}fail} dkim_private_key = DKKEY_DIR/rsa.private.$dkim_selector.$dkim_domain dkim_strict = 1 В результате применения этих фрагментов исходящие сообщения будут подписы- ваться, входящие сообщения, имеющие подпись, будут верифицироваться, а затем к ним будет добавляться заголовок отчета системы DKIM. Ниже приведен пример такого заголовка. X-DKIM-Report: pass (Signer=gmail.com) (Testing=0) Если вы собираетесь отказываться от приема или каким-то образом обрабатывать со- общения, подписи которых не были верифицированы, эти правила следует дополнить. Строка no_verify в строке маршрутизатора относится не к верификации подписей DKIM, а к верификации адреса получателя; в данном маршрутизаторе этот параметр от- ключен, зато в следующем маршрутизаторе dnslookup он включен. Нет никакого смыс- ла делать это дважды. Технология DKIM в системе Postfix Технология DKIM реализована в системе Postfix с помощью пакета DKIM-milter, описанного выше. Сгенерируйте свою пару ключей и проверьте их с помощью утилиты dkim-testkey; скомпилируйте файл dkim-f ilter. conf на основании примера из дис- трибутивного пакета, а затем укажите системе Postfix, чтобы она использовала утилиту dkim-filter. В файле main.cf, после всех параметров почтовых фильтров, добавьте следующие строки. smtpd_milters = inet:localhost:8891 non_smtpd_miIters = inet:localhost:8891 milter_protocol = 2 milter_default_action = accept Теперь необходимо лишь запустить утилиту dkim-filter и повторно запустить си- стему postfix. 20.17. Интегрированные почтовые системы В настоящее время существует много интегрированных почтовых систем: от свободно распространяемых систем с открытым кодом до дорогих коммерческих продуктов. Все делают намного больше, чем просто принимают и отправляют электронную почту. Обыч- но они предусматривают следующие функции для организации групп и конференций. • Управление адресной книгой и списком контактов • Управление календарем и расписанием
Глава 20. Электронная почта 901 • Списки рассылки и доски объявлений • Мгновенная передача сообщений • Шифрование SSL/TLS • Архивирование и автоматическое резервирование • Поддержка мобильных устройств (BlackBerry, iPhone, etc.) Большинство этих мегапакетов содержит описание конфигурации графического поль- зовательского интерфейса, которое в некоторой степени может заменить собой чтение этой главы. (Возможно, этот раздел следовало бы поместить не в конец, а в начало главы.) Многие системы предназначены для вытеснения программы Microsoft Exchange. Некоторые программы достойны отдельного упоминания. • Citadel (citadel. org) — это открытый пакет для электронной почты и программ- ного обеспечения совместной работы (groupware), предусматривающий контракт на поддержку. • Zimbra (zimbra. com) занимает промежуточное положение между программами с открытым кодом и коммерческими системами. Существует ее полнофункциональ- ная коммерческая версия и упрощенная версия, открытая и бесплатная. • Kerio MailServer (kerio. com) — это коммерческая система, которая, подобно си- стеме Zimbra, лицензируется для каждого пользователя. Для крупных организаций эта система может стоить дорого. • Communigate Pro (communigate. com) внедряет поддержку аудио- и видеофайлов в обычный пакет для электронной почты и программного обеспечения совместной работы и предусматривает либо традиционное безлимитное лицензирование, либо лицензирование для каждого пользователя. Существуют также аппаратные устройства, предназначенные для реализации функ- ций электронной почты, которые обычно являются частью систем FreeBSD UNIX или Linux. Заслуживают также внимания устройства IronPort Series компании Cisco, а также модели от компаний Sophos и Clearswift. Эти устройства обычно выполняют фильтрацию вирусов и спама, а затем передают сообщения программе Microsoft Exchange для доставки. 20.18. Рекомендуемая литература Для того чтобы не смешивать все ссылки в один список, мы упорядочили их по транспортным агентам и темам. Общие вопросы по борьбе со спамом • Clayton R. Good Practice for Combating Unsolicited Bulk Email. — RIPE/Demon Internet, 2000, ripe.net/ripe/docs/ripe-206.html. Этот документ предназначен для интернет-провайдеров. Он содержит много ин- формации о правилах и полезные описания технических вопросов. • Field J. MailScanner: A User Guide and Training Manual. — University of Southampton Department of Electronics, 2007. • McDonald A. SpamAssassin: A Practical Guide to Configuration, Customization, and Integration. — Packt Publishing, 2004.
902 Часть II. Работа в сети • Schwartz A. SpamAssassin. — Sebastopol, CA: O’Reilly Media, 2004. • Wolfe P., Scott C., Erwin M. The Anti-Spam Tool Kit. — Emeryville, CA: Osborne, 2004. Литература по программе sendmail Costales B., Assmann C., Jansen G., Shapiro G. Sendmail, 4th Edition. —Sebastopol, CA: O’Reilly Media, 2007. Эта книга представляет собой внушительный том о конфигурации программы sendmail размером более 1300 страниц. Она содержит руководство системного адми- нистратора, а также полный список библиографических ссылок. Кроме того, существует электронный вариант этой книги. В коллектив авторов входят два ключевых разработ- чика программы sendmail (Claus и Greg), что является гарантией технической коррект- ности и авторитетности книги. В разделе Sendmail Installation and Operation Guide изложе- ны инструкции по инсталляции и хорошее описание файла конфигурации. Файл с этим разделом можно найти в подкаталоге doc/op дистрибутивного пакета sendmail. Этот документ является достаточно полным, и в сочетании с файлом README из каталога cf он дает конкретное представление о системе sendmail. Сайты sendmail.org, sendmail.org/~ca и sendmail.org/~gshapiro содержат документы, ответы на вопросы и справочные материалы по программе sendmail. Литература о системе Exim • Hazel Р. The Exim SMTP Mail Server: Official Guide for Release 4, 2nd Edition. — Cam- bridge, UK: User Interface Technologies, Ltd., 2007. • Hazel P. Exim: The Mail Transfer Agent. — Sebastapol, CA: O’Reilly Media, 2001. • Meers J. Getting started with EXIM. — exim-new-users. co. uk, 2007. Спецификация системы Exim представляет собой определяющий документ о ее конфигурации. Он является исчерпывающим и обновляется с появлением каждой новой версии. Текстовая версия включена в файл doc/spec. txt из дистрибутив- ного пакета, а соответствующий файл PDF доступен на сайте exim.org. Кроме того, на этом веб-сайте можно найти несколько справочных документов. Литература о системе • Blum R. Postfix. — Sams Publishing, 2001. • Dent K.D. Postfix: The Definitive Guide. — Sebastopol, CA: O’Reilly Media, 2003. • Hildebrandt R., Koetter P. The Book of Postfix: State of the Art Message Transport. — San Francisco, CA: No Starch Press, 2005. Эта книга посвящает читателя во все тонкости конфигурации системы Postfix, даже в сложных средах. Авторы являются активными членами сообщества поль- зователей системы Postfix и регулярно участвуют в почтовых рассылках группы пользователей Postfix. К сожалению, эта книга не переиздается, но ее можно при- обрести в букинистических магазинах. • Страница postfix. org/SOHO_README. html представляет собой справочное ру- ководство по использованию системы Postfix дома или в офисах небольших ком- паний.
Глава 20. Электронная почта 903 Документы RFC Текущими версиями документов RFC821 и RFC822 являются документы RFC5321 и RFC5322. В них определен протокол SMTP и форматы сообщений и адресов для элек- тронной почты в Интернете. Документы RFC5335 и RFC5336 посвящены вопросам интернационализации адресов электронной почты. Существует около 90 документов RFC, связанных с электронной почтой. Их слиш- ком много, чтобы перечислять в этой книге. Все эти документы можно найти на сайте rfc-editor.org с помощью поисковой машины. 20.19. Упражнения 20.1. Кратко объясните разницу между пользовательским агентом (MUA), агентом до- ставки (DA) и агентом доступа (АА). Затем объясните разницу между почтовым транспортным агентом (МТА) и почтовым агентом передачи (MSA). 20.2. Проверьте почтовую очередь на вашем локальном почтовом сервере? Есть ли там сообщения без управляющих файлов или управляющие файлы без сообщений? Какое самое старое сообщение вы нашли в очереди? (Это действие требует прав суперпользователя.) 20.3. Объясните, что такое запись MX. Почему записи MX важны для доставки почты? Приведите пример, в котором неверно сконфигурированная запись MX может привести к отказу от доставки почты. 20.4. Определите схему почтовой службы на вашем сайте и нарисуйте диаграмму в сти- ле рис. 20.2. Где находится входящая почта, прошедшая сканирование на спам и вирусы? Что скажете об исходящей почте? 20.5. Сравните использование файла /etc/mail/aliases с использованием сервера LDAP или базы данных MySQL для хранения почтовых псевдонимов. Какие преи- мущества и недостатки имеет каждый из этих механизмов? 20.6. ★ Дайте краткое описание следующих заголовков сообщений. Какой путь прой- дет электронная почта? Кому она адресована и кому была доставлена? Как долго она находилась в пути? Delivered-To: sailingevi@gmail.com Received: by 10.231.143.81 with SMTP id tl7csl75323ibu; Mon, 28 Dec 2009 20:15:20 -0800 (PST) Received: by 10.231.157.131 with SMTP id b3mr2134004ibx.19.1262060119841; Mon, 28 Dec 2009 20:15:19 -0800 (PST) Return-Path: <garth@grsweb.us> Received: from mail-relay.atrust.com (mail-relay.atrust.com [63.173.189.2]) by mx.google.com with ESMTP id 12sil9092249iwn.27.2009.12.28.20.15.19; Mon, 28 Dec 2009 20:15:19 -0800 (PST) Received-SPF: neutral (google.com: 63.173.189.2 is neither permitted nor denied by best guess record for domain of garth@grsweb.us) clientip= 63.173.189.2; Authentication-Results: mx.google.com; spf=neutral (google.com: 63.173.189.2 is neither permitted nor denied by best guess record for domain of garthOgrsweb.us) smtp.mail=garth@grsweb.us
904 Часть II. Работа в сети Received: frommout.perfora.net (mout.perfora.net [74.208.4.194]) by mail-relay.atrust.com (8.12.11/8.12.11) with ESMTP id nBT4FI9rO17821 for <evi@atrust.com>; Mon, 28 Dec 2009 21:15:19 -0700 Received: from grsweb.us (wolverine.dreamhost.com [75.119.201.185]) by mrelay.perfora.net (node=mrusl) with ESMTP (Nemesis) id OMaORD- lNgKS52KT9-00LeuN; Mon, 28 Dec 2009 23:15:17 -0500 Date: Mon, 28 Dec 2009 20:15:13 -0800 From: UNIX and Linux System Administration Handbook <garth@grsweb.us> Reply-То: garth@grsweb.us To: eviOatrust.com Cc: garth@grsweb.us Message-Id: <4b398251bllab_e92383578b2d9b036fOwolverine.tmail> Subject: New comments on Printing Mime-Version: 1.0 Content-Type: text/html; charset=utf-8 X-Provags-ID: V01U2FsdGVkX18pouiYXif/bVfh+D9wFXMr24TahAzDNZqM+jA04iLR7S4 olDXRpXlrbQMblNoZf5jO6edc+WIGC8Fi4hd5Akl5vBARASOFQYxNJWea9 8SyQg== X-Spam-Status: No, hits=-99.3 required=4.0 tests=BAYES_30,HTML_20_30, MIME_HTML_ONLY,USER_IN_WHITELIST version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 20.7. ★ Какие последствия возникают из-за включения в черный список сайта spamhaus. org или аналогичной службы? Что следует делать, если выяснилось, что ваш сайт попал в черный список? Сначала опишите действия, которые позво- ляют не попасть в черные списки. 20.8. ★ Если ваш сайт позволяет использовать программу procmail и вы имеете раз- решение от локального системного администратора группы, настройте ваш файл конфигурации программы procmail так, чтобы проиллюстрировать, как програм- ма procmail может разрушить систему безопасности. 20.9. АА Исследуйте текущую конфигурацию транспортного агента на вашем сайте. Какие специальные функциональные возможности транспортного агента в нем используются? Есть ли проблемы в вашей конфигурации? Как улучшить эту кон- фигурацию? 20.10. АА Найдите спам в вашем почтовом ящике и проверьте заголовки. Укажите при- знаки подделанной почты. Затем запустите какую-нибудь программу, описанную в главе, например SpamAssassin, и проанализируйте результаты ее работы. Как вы распознали подделанные заголовки? Опишите спам и представьте ваши выводы об отправителе, корректности перечисленных узлов и другие факты, свидетельствую- щие о нарушениях. Упражнения, связанные с программой sendmail 20.11. Опишите утилиту smrsh и способ ее использования, вместо утилиты /bin/sh? Если утилита smrsh применяется на вашем сайте, укажите, какие про- граммы разрешается запускать в качестве обработчика очереди? Являются ли какие-нибудь из этих программ небезопасными?
Глава 20. Электронная почта 905 20.12. Напишите небольшой файл /etc/mail/aliases, демонстрирующий три разных вида псевдонимов. Кратко опишите, что делает каждая строка в этом файле и чем она может быть полезной. 20.13. ★ Перечислите префиксы для файлов в каталоге почтовой очереди и объясните, что означает каждый из них. Почему следует удалять одни файлы из очереди и по- чему большой ошибкой было бы удалять другие? Как могут некоторые префиксы использоваться для отладки ошибок в конфигурации программы sendmail? 20.14. ★ Объясните назначение каждого макроса препроцессора т4. Если макрос встав- ляет файл, кратко опишите, какое содержимое должен иметь такой файл. a) VERSIONID б) OSTYPE В) DOMAIN Г) MAILER д) FEATURE 20.15. ★ Объясните, как задать конфигурацию сервера sendmail, чтобы он принимал электронную почту как для вашего домена, так и для виртуального домена. Раз- решите виртуальному домену ретранслировать почту на почтовые ящики, находя- щиеся за пределами сайта. Упражнения, связанные с системой Exim 20.16. Возьмите список управления доступом для команды SMTP RCPT, продемон- стрированный в разделе 20.14, и измените значение параметра deny, заданного умолчанию, на противоположное, разрешив тем самым использование одинако- вых адресов. 20.17. ^Версии 4.70 и более поздние не поддерживают технологию DomainKeys, отдавая предпочтение технологии DKIM. Упростите пример настройки системы DKIM, продемонстрированный в разделе 20.16, так чтобы она поддерживала только один домен и один ключ подписи. Затем добавьте несколько правил, например реги- страцию неподписанной почты, поступающей от сайтов Gmail или Yahoo!, или от- каз от приема писем, не прошедших верификацию, если они поступили от систе- мы PayPal или вашего банка. 20.18. ★ Объясните, как настроить конфигурацию сервера Exim, чтобы он прини- мал почту как для вашего собственного домена, так и для виртуального домена. Разрешите виртуальному домену ретранслировать почту на почтовые ящики, на- ходящиеся за пределами сайта. 20.19. ★ Проанализируйте фрагменты конфигурации в документе spec.txt из дистри- бутивного пакета Exim и попробуйте включить некоторые из них в вашу конфи- гурацию. Включите подробную регистрацию для каждого действия, которое вы предпринимаете, и проверьте регистрационные файлы, чтобы убедиться, что вы получили желаемый результат. Упражнения, связанные с системой Postfix 20.20. Попробуйте настроить “нулевого клиента”, т.е. почтовую систему, которая только посылает почту и не может получать ее. Убедитесь, что порт 25 закрыт.
906 Часть II. Работа в сети 20.21. Задайте конфигурацию системы Postfix так, чтобы она аутентифицировала ваш сайт для вашего провайдера или сервера компании (даже Gmail!); используйте следующие параметры. smtp_sender_dependent_authentication sender_dependent_relayhost_maps smtp_sasl_auth_enable smtp_sasl_password_maps 20.22. Как вы думаете, почему система Postfix поддерживает так много типов отображе- ний? 20.23. Для чего используется отображение рсге? Может ли быть полезным для почтовых систем подстановка значений? Необходимо ли использовать команду postmap для компиляции отображений рсге? 20.24. Найдите описание параметра recipient delimiter в документации (справочная страница postconf). Для чего он может использоваться? 20.25. ★ Объясните, как настроить конфигурацию системы Postfix, чтобы она прини- мала почту как для вашего собственного домена, так и для виртуального домена. Разрешите виртуальному домену ретранслировать почту на почтовые ящики, на- ходящиеся за пределами сайта.
Глава 21 Управление сетями Поскольку при объединении компьютеров в сети число связей между ними увели- чивается, в сетях, как правило, усугубляются все имеющиеся проблемы. Как гласит на- родная мудрость, “работа в сети — это когда вы не можете выполнить свое задание из-за отказа компьютера, о котором никогда не слышали”. Управление сетями — это, прежде всего, искусство и наука поддержания их в работо- способном состоянии. Сюда обычно входят следующие задачи: • поиск неисправностей в сетях, шлюзах и важных серверах; • разработка схем уведомления администратора о наличии проблем; • общий мониторинг сети с целью распределения нагрузки в ней и планирования ее дальнейшего расширения; • документирование и визуализация работы сети; • управление сетевыми устройствами с центральной станции. В отдельном сегменте сети вряд ли стоит внедрять формальные процедуры управле- ния сетью. Достаточно провести тщательное тестирование сети после ее прокладки и время от времени проверять уровень нагрузки. Сломается — почините. По мере роста сети процедуры управления должны становиться все более автомати- зированными. В сети, где несколько подсетей объединяются посредством коммутаторов или маршрутизаторов, решение административных задач можно автоматизировать с по- мощью сценариев и простейших программ. Если используются глобальные или сложные локальные сети, подумайте об инсталляции станций управления сетью со специальным программным обеспечением. В некоторых случаях усложнение системы управления сетью диктуется необходимо- стью обеспечения надежности. Часто бывает так, что возникновение проблемы в сети приводит к полной остановке работы. Если подобные задержки недопустимы, лучше приобрести и установить высококлассную корпоративную систему управления сетью.
908 Часть II. Работа в сети К сожалению, даже самая лучшая система не поможет предупредить все проблемы. Важно иметь хорошо документированную схему сети и высококвалифицированный об- служивающий персонал, способный справляться с неизбежными сбоями. 21.1. Поиск НЕИСПРАВНОСТЕЙ В СЕТЯХ Существует несколько хороших инструментов, позволяющих искать неисправности в сети на уровне TCP/IP. Большинство из них выдает низкоуровневую информацию, поэтому для того, чтобы пользоваться ими, нужно хорошо понимать принципы работы протоколов TCP/IP и маршрутизации. С другой стороны, источником проблем в сети могут служить и ошибки в работе та- ких высокоуровневых протоколов, как DNS, NFS или HTTP. Прежде чем приступать к чтению этой главы, прочтите главы 14 и 15. В этом разделе мы рассмотрим общую стратегию поиска неисправностей, после чего перейдем к знакомству с основными инструментами этого поиска: утилитами ping, traceroute, netstat, tcpduxnp и Wireshark. Команда arp, которая также предназначе- на для поиска неисправностей в сети, здесь не описывается; о ней рассказывалось раз- деле 14.6. Когда в сети возникает неисправность, появляется желание побыстрее все устранить. Не торопитесь! Важно обдумать подход к решению проблемы, избегая необдуманных действий. Наибольшая ошибка заключается во внесении плохо спланированных изме- нений в несправную сеть. Прежде чем “набрасываться” на собственную сеть, примите во внимание следующие принципы. • Вносите пошаговые изменения в конфигурацию сети, тщательно проверяя ре- зультаты, чтобы убедиться в совпадении полученного эффекта с ожидаемым. Изменения, которые не дали нужного результата, должны отменяться. • Документируйте возникшую ситуацию и все вносимые в нее изменения. • Проблемы могут носить временный характер, поэтому начните с поиска релевант- ной информации с помощью утилит, таких как sar и nmon. • Начните с “края” системы или сети и продвигайтесь по ключевым ее компонен- там, пока не доберетесь до источника неисправности. Например, начните с ис- следования сетевой конфигурации клиентского компьютера, затем проверьте фи- зическое соединение клиента с сетью, сетевое оборудование и, наконец, сетевые аппаратные средства сервера и его программную конфигурацию. • Будьте в курсе событий. Сетевые проблемы оказывают влияние на многих людей: пользователей, провайдеров, системных администраторов, инженеров по телеком- муникациям, сетевых администраторов и т.д. Постоянный контакт с другими спе- циалистами позволит вам не мешать друг другу при решении проблемы. • Работайте в команде. Многолетний опыт показывает, что люди совершают меньше глупых ошибок, если им оказывают поддержку. • Помните о многоуровневой структуре сетевых средств. Начните с верхнего или нижнего уровня и последовательно продвигайтесь по стеку протоколов, проверяя их работу. Последнее замечание заслуживает более подробного рассмотрения. Как указывалось в разделе 14.2, в семействе протоколов TCP/IP определяются уровни абстракции, на ко-
Глава 21. Управление сетями 909 торых функционируют различные компоненты сети. Например, протокол HTTP зависит от протокола TCP, который, в свою очередь, основан на протоколе IP, а последний взаи- модействует с протоколом Ethernet, работоспособность которого зависит от целостно- сти сетевого кабеля. Можно существенно уменьшить время поиска неисправности, если предварительно понять, средства какого уровня ведут себя неправильно. Проходя стек протоколов уровень за уровнем (вверх или вниз), проверяйте следующее. • Есть ли физическое соединение и светится ли индикатор связи? • Правильно ли сконфигурирован сетевой интерфейс? • Отображаются ли в таблицах маршрутизации адреса других компьютеров? • Есть ли брандмауэр на вашем локальном компьютере? • Если брандмауэр есть, проходят ли через него ICMP-пакеты утилиты ping и от- веты? • Находит ли команда ping узел localhost (127.0.0.1)? • Находит ли команда ping другие компьютеры локальной сети по IP-адресам? • Правильно ли сконфигурирована служба DNS?1 • Находит ли команда ping другие компьютеры локальной сети по именам? • Находит ли команда ping компьютеры в другой сети? • Работают ли высокоуровневые сетевые утилиты, такие как telnet или ssh? • Вы правда проверили брандмауэры? Определив, на каком уровне возникает проблема, не спешите с выводами. Подумайте сначала, как отразятся последующие проверки и вносимые изменения на других сетевых службах и компьютерах. 21.2. Команда ping: проверка доступности компьютера Команда ping удивительно проста, но во многих случаях ее оказывается вполне до- статочно. Она посылает ICMP-пакет ECHO_REQUEST конкретному компьютеру и ждет ответа. Команду ping можно применять для проверки работоспособности отдельных ком- пьютеров и сегментов сети. В обработке ее запроса участвуют таблицы маршрутизации, физические компоненты сетей и сетевые шлюзы, поэтому для достижения успешного результата сеть должна быть в более или менее рабочем состоянии. Если команда не ра- ботает, можно быть совершенно уверенным в том, что более сложные средства тем более не функционируют. Однако это правило неприменимо в сетях, где брандмауэры блоки- руют эхо-запросы ICMP. Убедитесь в том, что брандмауэр не препятствует работе коман- 1 Если компьютер загружается очень медленно, зависает при загрузке или при попытке уста- новить связь посредством утилиты telnet, вероятнее всего, служба DNS функционирует неверно. В системах Solaris и Linux используется очень сложный подход к разрешению имен, конфигурация которого задана в файле /etc/nsswitch.conf. В других системах особый интерес представляет Демон кеширования службы имен (nscd). Если он дает сбой или имеет неправильную конфигу- рацию, это сказывается на поиске имен. По мере развития протокола IPv6 выяснилось, что мно- гие маршрутизаторы DSL выполняют функции службы по перенаправлению DNS, которые про- сто игнорируют запросы на записи DNS для IPv6 (АААА). Эта “оптимизация” вызывает длинные простои при выполнении запросов на распознавание имен. Для проверки правильности работы вашего распознавателя и сервера имен используйте команду getend (например, getend hosts google. com).
910 Часть II. Работа в сети ды ping, прежде чем подозревать, что зондируемый компьютер игнорирует эту команду. В конце концов, отключите на короткое время брандмауэр для проверки работоспособ- ности сети. Если сеть находится в плохом состоянии, вероятно, система DNS работает непра- вильно. Упростите ситуацию, используя числовые IP-адреса при выполнении утилиты ping, и примените параметр -п, чтобы предотвратить обратный поиск IP-адресов, по- скольку при этом также генерируются DNS-запросы. Если утилита ping используется для проверки выхода в Интернет, необходимо про- верить брандмауэр. Некоторые хорошо известные сайты отвечают на пакеты ping, а другие — нет. Например, оказалось, что сайт google. com отвечает на такие запросы. Большинство версий команды работает в бесконечном цикле, если не задан аргумент “число пакетов”. В системе Solaris команда ping -s обеспечивает расширенный вывод, а в других системах это происходит по умолчанию. Для того чтобы прервать работу ко- манды, нажмите <Ctri+C>. Приведем пример. linux$ ping beast PING beast (10.1.1.46): 56 data bytes 64 bytes from beast (10.1.1.46): icmp_seq=0 ttl=54 time=48.3 ms 64 bytes from beast (10.1.1.46): icmp_seq=l ttl=54 time=46.4 ms 64 bytes from beast (10.1.1.46): icmp_seq=2 ttl=54 time=88.7 ms ЛС --- beast ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss, time 2026ms rtt min/avg/max/stddev = 46.490/61.202/88.731/19.481 ms Информация о компьютере beast включает его IP-адрес, порядковый номер ответ- ного ICMP-пакета и полное время прохождения пакета. Полученные результаты свиде- тельствуют о том, что компьютер beast работает и подключен к сети. Порядковый номер ICMP-пакета — особенно ценный элемент информации. Нарушение последовательности свидетельствует об удалении пакетов. Обычно они со- провождаются сообщениями о каждом пропущенном пакете. Несмотря на то что протокол IP не гарантирует доставку пакетов, пакеты будут про- падать только в том случае, если сеть перегружена. Потерю пакетов следует обязательно выявлять, потому что этот факт иногда скрывается протоколами более высокого уровня. Может показаться, что сеть функционирует нормально, хотя на самом деле она работает гораздо медленнее, чем должна, причем не только из-за повторной передачи пакетов, но и из-за “накладных расходов”, требуемых для выявления и обработки пропавших паке- тов соответствующими протоколами. В случае исчезновения пакетов сначала выполните команду traceroute (описана ниже) для выяснения маршрута, по которому пакеты следуют к компьютеру-адресату. Затем посредством команды ping проверьте все промежуточные шлюзы, через которые пролегает маршрут, и узнайте, на каком этапе теряются пакеты. Для того чтобы точно диагностировать проблему, следует отправить такое количество пакетов, которое по- зволит получить статистически достоверные результаты. Неисправность сети находится на участке между последним шлюзом, для которого количество потерянных пакетов не больше некоторой заданной величины, и шлюзом, при обращении к которому количе- ство потерянных пакетов превышает эту величину. Полное время прохождения пакетов, сообщаемое командой ping, дает представле- ние об общей скорости передачи пакета по сети. Колебания этого значения, как прави- ло, не являются признаком проблем. Иногда пакеты задерживаются на десятки и сотни
Глава 21. Управление сетями 911 миллисекунд без видимой причины — просто так работают протокол IP и сама операци- онная система Linux. Но все-таки следует ожидать, что полное время прохождения па- кетов будет более-менее постоянным, за некоторыми исключениями. Большинство со- временных маршрутизаторов ограничивает скорость выдачи ответов на ICMP-запросы, т.е. маршрутизатор может задержать ответ на пакет команды ping в связи с общим огра- ничением трафика протокола ICMP. Команда ping позволяет задать размер посылаемого эхо-пакета. Если передается па- кет, размер которого превышает значение MTU для данной сети (в частности, 1500 байт в сети Ethernet), включается режим принудительной фрагментации. Это позволяет вы- являть ошибки передачи данных в самом кабеле и другие низкоуровневые ошибки, на- пример проблемы, связанные с перегрузкой сети или виртуальной частной сетью. В системах семейства Linux желательный размер пакета в байтах задается с помощью флага -s. # ping -S 1500 cuinfo.cornell.edu В системах Solaris, HP-UX и AIX достаточно просто указать желательный размер па- кета в конце команды ping. # ping cuinfo.cornell.edu 1500 Помните, что даже простая команда вроде ping может повлечь драматические по- следствия. В 1998 году так называемая атака Ping of Death (Смертельный Ping) вызва- ла сбой большого количества UNIX- и Windows-систем. Эта атака началась с отправки чрезмерно большого ping-пакета. Когда фрагментированный пакет был собран заново, он заполнил весь буфер получателя и привел к сбою компьютера. Опасность повторения атаки Ping of Death давно устранена, но некоторые изъяны, связанные с использованием утилиты ping, все еще существуют. Во-первых, сложно отличить неисправность сети от неисправности сервера, поль- зуясь только этой командой. Потеря эхо-пакетов означает лишь, что что-то работает неправильно. Во-вторых, успешно выполненная команда ping не позволяет получить информа- цию о состоянии исследуемого компьютера. Эхо-запросы обрабатываются в стеке про- токола IP и не требуют, чтобы на зондируемом компьютере выполнялся серверный про- цесс. Получение ответа гарантирует только то, что компьютер включен и ядро системы функционирует. Для проверки работы отдельных служб, таких как HTTP и DNS, следует применять высокоуровневые средства. 21.3. Инструмент SmokePinc: сбор статистики В РАБОТЕ КОМАНДЫ PINC ВО ВРЕМЕНИ Как указывалось выше, даже исправная сеть иногда теряет пакеты. С другой стороны, сети не должны постоянно терять пакеты, даже если уровень потерь невелик, поскольку последствия для пользователей могут быть непропорционально серьезными. Поскольку высокоуровневые пакеты часто продолжают функционировать даже при потере пакетов, вы можете не заметить потери пакетов, пока не станете активно их отслеживать. Для этой цели можно использовать утилиту SmokePing — программу с открытым исходным кодом, написанную Тобиасом Ойтикером (Tobias Oetiker) для отслеживания простоев сети. Программа SmokePing посылает несколько ping-пакетов на целевой узел через регулярные интервалы времени. Кроме того, она демонстрирует результаты отеле-
912 Часть II. Работа в сети живания каждого соединения через веб-узел и может посылать сигналы, когда возникает неблагоприятная ситуация. Копию программы можно загрузить с сайта oss. oetiker. ch/smokeping. На рис. 21.1 представлен график, построенный программой Smoke Ping. На верти- кальной оси отложены среднее время прохождения ping-пакеты (секунды), а на горизон- тальной — даты, в которые проходили ping-пакетов (номера недель). Сплошная черная линия, от которой поднимаются серые пики, означает среднее время прохождения паке- тов; сами пики представляют собой время прохождения отдельных пакетов. Поскольку серые пики всегда находятся сверху средней линии, подавляющее большинство пакетов должно проходить по сети за время, близкое к среднему, и с очень небольшой задерж- кой. Это типичная ситуация. 70 Ш * 60 m ‘ 50 ш (Л 1 1 •° 40 п) 20 m ; 10 в I о 1---------------------------------------------------------------------------------------------< Week 13 Week 14 Week 15 Week 16 Week 17 Week IB Week 19 Median rtt: 37,0 ms avg 52 1 ms wax 25,7 ms Min 40.6 ns now 5 3 ms sd 70 airi/s packet loss: 0.06 % avg 7.93 % мах 0.00 % min 0001 now loss color: B0 1/20 12/26 3/20 4/20 110/20 19/20 probe: 20 ICW1 Echo Pings (56 Bytes) every 300s end: Tue May 12 02 33 2009 ME ST Puc. 2LL Пример графика, построенного программой Smoke Ping Ступенчатая форма средней линии означает, что базисная линия времени прохожде- ния пакетов к данному узлу несколько раз изменялась на протяжении периода наблюде- ний. Наиболее вероятно, что к этому узлу ведут несколько маршрутов или что на самом деле он представляет собой совокупность нескольких узлов, имеющих одно и то же имя DNS, но разные IP-адреса. 21.4. Команда traceroute: трассировка IP-пакетов Команда traceroute, написанная Ваном Джейкобсоном (Van Jacobson), позволя- ет выявлять последовательность шлюзов, через которые проходит IP-пакет на пути к пункту назначения. Эта команда есть во всех современных операционных системах.2 Синтаксис ее вызова прост. traceroute имя_компьютера У этой команды очень много параметров, большинство которых в повседневной ра- боте не применяется. Как обычно, имя_компьютера может быть задано как имя DNS или IP-адрес. Команда выдает список узлов, начиная с первого шлюза и заканчивая пунктом назначения. Например, на нашем компьютере jaguar проверка узла nubark дает следующие результаты. 2 Она есть даже в системе Windows, но в ней она называется tracert (если догадаетесь, поче- му, получите дополнительные баллы по истории).
Глава 21. Управление сетями 913 % traceroute nubark traceroute to nubark (192.168.2.10), 30 hops max, 38 byte packets 1 lab-gw (172.16.8.254) 0.840ms 0.693ms 0.671ms 2 dmz-gw (192.168.1.254) 4.642ms 4.582ms 4.674ms 3 nubark (192.225.2.10) 7.959ms 5.949ms 5.908ms Эти результаты говорят о том, что для попадания с компьютера jaguar на узел nubark пакеты должны сделать три перехода. Кроме того, они содержат информацию о шлюзах, через которые проходят пакеты. Показано также полное время прохождения пакетов для каждого шлюза — проведено по три замера для каждого перехода. Обычно количество переходов от одного узла Интернет к другому составляет более 15, даже если два сайта расположены через дорогу. Команда traceroute работает путем записи искусственно заниженного значения в поле TTL (Time То Live — время жизни, или предельное число переходов) отправляемо- го пакета. Когда пакет приходит на очередной шлюз, его значение TTL уменьшается на единицу. Если шлюз обнаруживает, что значение TTL стало равным нулю, он удаляет пакет и возвращает узлу-отправителю специальное ICMP-сообщение: “Время жизни па- кета истекло”. Ш Более подробную информацию об обратном поиске имен в системе DNS можно найти в разделе 17.8. У первых трех пакетов команды traceroute значение TTL равно 1. Первый шлюз, получивший пакет (в нашем примере это lab-gw), обнаруживает, что его время жиз- ни истекло. Тогда он удаляет пакет и посылает компьютеру jaguar указанное ICMP- сообщение, в поле отправителя которого записан IP-адрес шлюза. Команда traceroute обращается к службе DNS и по имеющемуся адресу находит имя шлюза. Для получения данных о следующем шлюзе посылается очередная группа пакетов, поле TTL которых равно 2. Первый шлюз маршрутизирует эти пакеты и уменьшает значение TTL на единицу. Второй шлюз удаляет пакеты и генерирует описанные выше ICMP-сообщения. Этот процесс продолжается до тех пор, пока пакеты не достигнут нужного компьютера; значение TTL при этом будет равно числу переходов. Большинство маршрутизаторов посылает свои ICMP-сообщения через тот интерфейс, который является “ближайшим” к узлу-отправителю (т.е. имеет наименьшую метрику стоимости). Если, наоборот, запустить команду traceroute на узле-получателе, чтобы узнать маршрут к исходному компьютеру, то, скорее всего, будет получен другой список IP-адресов, соответствующий тому же набору маршрутизаторов. Иногда весь набор шлю- зов оказывается совершенно другим; такая конфигурация называется асимметричной. Для каждого значения TTL команда traceroute посылает три пакета, что иногда приводит к интересным результатам. Если промежуточный шлюз распределяет трафик по нескольким маршрутам, то пакеты могут возвращаться разными компьютерами. В та- ком случае команда traceroute сообщает обо всех полученных ответах. Рассмотрим пример, в котором посредством команды traceroute определяется маршрут с компьютера в Швейцарии к домену caida. org в суперкомпьютерном центре Сан-Диего (San Diego Supercomputer Center).3 linux$ traceroute caida.org traceroute to caida.org (192.172.226.78), 30 hops max, 46 byte packets 1 gw-oetiker.init7.net (213.144.138.193) 1.122 ms 0.182 ms 0.170 ms 2 rlzurl.core.init7.net (77.109.128.209) 0.527 ms 0.204 ms 0.202 ms 3 rlfral.core.init7.net (77.109.128.250) 18.279 ms 6.992 ms 16.597 ms 3 Мы удалили несколько цифр в дробной части миллисекунд, чтобы сделать строки короче.
914 Часть II. Работа в сети 4 rlamsl.core.init7.net (77.109.128.154) 19.549 ms 21.855 ms 13.514 ms 5 rllonl.core.init7.net (77.109.128.150) 19.165 ms 21.157 ms 24.866 ms 6 rllaxl.ce.init7.net (82.19-7.168.69) 158.232 ms 158.224 ms 158.271 ms 7 cenic.laap.net (198.32.146.32) 158.349 ms 158.309 ms 158.248 ms 8 dc-lax-core2—lax-peerl-ge.cenic.net (137.164.46.119) 158.60 ms * 158.71 ms 9 dc-tus-aggl—lax-core2-10ge.cenic.net (137.164.46.7) 159 ms 159 ms 159 ms 10 dc-sdsc-sdsc2—tus-dc-ge.cenic.net (137.164.24.174) 161 ms 161 ms 161 ms 11 pinot.sdsc.edu (198.17.46.56) 161.559 ms 161.381 ms 161.439 ms 12 rommie.caida.org (192.172.226.78) 161.442 ms 161.445 ms 161.532 ms Эти строки свидетельствуют о том, что пакеты долго путешествовали внутри сети Init Seven. Иногда по именам шлюзов можно догадаться об их географическом местополо- жении. Сеть Init Seven раскинулась от Цюриха (zur) до Франкфурта (fra), Амстердама (ams), Лондона (Ion) и, наконец, до Лос-Анджелеса (lax). В этом месте пакеты достиг- ли сайта cenic. net, который доставил пакеты на узел caida. org внутри сети супер- компьютерного центра Сан-Диего (sdsc) в городе Ла Хойя (La Jolla)4, шт. Калифорния. На восьмом переходе вместо одного из значений времени отображается звездочка. Это означает, что на один из отправленных пакетов не был получен ответ. Такая ситуа- ция может быть вызвана перегрузкой сети, но это не единственное возможное объяс- нение. Команда traceroute использует низкоприоритетные ICMP-пакеты, которые отбрасываются многими маршрутизаторами, отдающими предпочтение “реальному” трафику. Появление нескольких звездочек в выводе команды traceroute не является причиной для беспокойства. Если для какого-то шлюза отображаются все три звездочки, значит, от него не было получено ни одного сообщения. Вероятнее всего, шлюз просто выключен. Правда, ино- гда шлюз конфигурируют таким образом, чтобы он игнорировал устаревшие пакеты. В этом случае пакеты благополучно перейдут на следующий шлюз. Другой возможной причиной появления звездочек может быть то, что ответные пакеты от шлюза возвраща- ются слишком долго и команда traceroute перестает ожидать их прибытия. Некоторые брандмауэры полностью блокируют передачу ICMP-сообщений о пакетах с истекшим временем жизни. Если маршрут пролегает через один из таких брандмауэ- ров, команда traceroute не сможет получить информацию о шлюзах, находящихся за ним. Однако она узнает общее число переходов до пункта назначения, так как отправ- ляемые эхо-пакеты пройдут весь маршрут. Некоторые брандмауэры могут также блокировать исходящие UDP-пакеты, кото- рые команда traceroute посылает для инициирования ICMP-ответов. В этом случае команда не выдаст никакой полезной информации. Если ваш брандмауэр не дает вы- полнить команду traceroute, убедитесь, что его конфигурация открывает порт 33434- 33534 и допускает пакеты ICMP ECHO (тип 8). Медленная передача данных не всегда свидетельствует о неисправности сети. Не- которые сети действительно имеют большую задержку, особенно если в них использу- ется технология UMTS/EDGE/GRPS. Ярким примером являются беспроводные сети. Медлительность может быть также следствием перегрузки сети. Определить это можно по нелогичному значению полного времени прохождения пакета. Иногда можно увидеть символы ! N вместо значения времени. Это говорит о том, что соответствующий шлюз вернул сообщение о “недостижимости” сети, т.е. он не знает, куда посылать пакет. Сообщения о “недостижимости” узла или протокола помечаются как ! н или ! р соответственно. Шлюз, от которого получено одно из указанных сообще- ний, является последним в цепочке и обычно имеет проблемы с маршрутизацией (воз- 4 Пригород Сан-Диего. — Примеч. ред.
Глава 21. Управление сетями 915 можно, они вызваны разрывом связи): либо его статические маршруты заданы неверно, либо протоколы динамической маршрутизации не могут определить правильный марш- рут для передачи пакета получателю. Если команда traceroute не работает (или работает слишком медленно), это мо- жет быть вызвано превышением тайм-аута при попытках узнать имя компьютера в DNS. Возможно, на компьютере не функционирует служба DNS. В таком случае воспользуй- тесь командой traceroute -п. Флаг -п отменяет поиск имен, и только этот способ иногда позволяет все же выполнить команду traceroute в поврежденных сетях. Для выполнения команды traceroute необходимо иметь права суперпользователя. Чтобы обычный пользователь могут выполнить эту команду, она должна быть инстал- лирована с установленным битом setuid. В некоторые дистрибутивные пакеты системы Linux команда traceroute включается без установленного бита setuid. В зависимости от окружения и потребностей, бит setuid можно включить снова или предоставить заин- тересованным пользователям доступ к этой команде с помощью команды sudo. В последние годы появилось несколько утилит, аналогичных команде traceroute, которые могут проходить через брандмауэры, блокирующие ICMP-пакеты. Обзор этих инструментов можно найти на странице tinyurl. com/y99qh6u на сайте РЕТТКВ Wiki. Нам особенно понравилась утилита mtr, которая имеет интерфейс, похожий на интер- фейс утилиты top, и работает, как утилита traceroute. Очень хорошо сделано! В зависимости от вида маршрутизации, иногда полезно посмотреть на свой сайт с точки зрения внешнего мира. Несколько веб-служб для отслеживания маршрутов позво- ляют выполнять функции, обратные утилите traceroute, не выходя из браузера. Томас Кернен (Tomas Kemen) поддерживает список этих служб на сайте traceroute. org. 21.5. Команда netstat: получение информации о состоянии СЕТИ Команда netstat выдает различную информацию о состоянии сетевого программ- ного обеспечения, включая статистику сетевых интерфейсов, данные о маршрутизации и таблицы соединений. Никакого объединяющего звена во всех этих информационных блоках нет, просто они касаются функционирования сети. Команду netstat можно сравнить с “кухонным сливом” сетевых инструментов — она отражает много сетевой информации, которая не появляется больше нигде. Мы рассмотрим пять наиболее распространенных вариантов использования коман- ды netstat, а именно: • проверка состояния сетевых соединений; • анализ конфигурации интерфейсов; • изучение таблицы маршрутизации; • проверка таблицы маршрутизации; • получение статистических данных о различных сетевых протоколах. Контроль состояния сетевых соединений Команда netstat -i демонстрирует конфигурацию и состояние каждого сетевого интерфейса узла и данные соответствующих счетчиков трафика. Результаты обычно вы- водятся в виде таблицы, структура которой зависит от операционной системы.
916 Часть II. Работа в сети soians solaris$ netstat -i Name Mtu Net/Dest lo0 8232 loopback elOOOgl 1500 host-ifl el000g2 1500 host-if2 Address Ipkts localhost 319589661 host-ifl 369842112 host-if2 93141891 lerrs 0 0 0 Opkts 319589661 348557584 121107161 Oerrs . 0 : 0 0 Collis Queue 0 0 0 0 0 0 E3 hp-ux$ netstat -i Name Mtu Network lanO 1500 192.168.: loO 32808 loopback A 10. Address . 0 hpuxl1 hpuxll.atrust.< 20m Ipkts lerrs Opkts 2611259 0 2609847 Oerrs 0 Coll 0 aix$ netstat Name Mtu en3 1500 епЗ 1500 loO 16896 loO 16896 loO 16896 -i Network link#2 192.168.: link#l 127 : :1 10 Address ZoneID 0.11.25.39.e0.b6 IBM loopback 0 Ipkts lerrs 41332 0 41332 0 1145121 0 1145121 0 1145121 0 Opkts Oerrs 14173 3 14173 3 1087387 0 1087387 0 1087387 0 Coll 0 0 0 0 0 linux$ ifconfig -а ethO Link encap:EthernetHWaddr 00:15:17:4c:4d:00 inet addr:192.168.0.203Bcast:192.168.0.255Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe4c:4d00/64 Scope:Link UP BROADCAST RUNNING MULTICASTMTU:1500Metric:1 RX packets:559543852 errors:0 dropped:62 overruns:0 frame:0 TX packets:457050867 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:478438325085 (478.4 GB)TX bytes:228502292340 (228.5 GB) Memory:b8820000-b8840000 ethl Link encap.-EthernetHWaddr 00:15:17: 4c: 4d: 01 BROADCAST MULTICASTMTU:1500Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B)TX bytes:0 (0.0 B) Memory:b8800000-b8820000 lo Link encap:Local Loopback inet addr:127.0.0.IMask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNINGMTU:16436Metric:1 RX packets:1441988 errors:0 dropped:0 overruns:0 frame:0 TX packets:1441988 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:327048609 (327.0 MB)TX bytes:327048609 (327.0 MB)
Глава 21. Управление сетями 917 Этот узел имеет два сетевых интерфейса: один предназначен для регулярного тра- фика, а второй в настоящее время не используется (он не имеет IP-адреса и не отмечен меткой UP). Команды RX packets и ТХ packets сообщают количество пакетов, полу- ченных интерфейсом и прошедших через него после загрузки компьютера. В разделах, предназначенных для подсчета ошибок, регистрируются многие виды ошибок, и обычно в них можно увидеть небольшие числа. Количество ошибок не должно превышать 1% от связанных с ними пакетов. Если уровень ошибок выше, сравните его с уровнем ошибок на соседних компьютерах. Большое количество ошибок на отдельном компьютере свидетельствует о проблеме с интерфейсом или соединением. Высокий уровень ошибок почти наверняка означает проблему с окружением или сетью. Одна из наиболее частых причин большого количе- ства ошибок заключается в том, что несоответствие скорости работы платы Ethernet или дуплекса вызывает сбой при автоопределении. Несмотря на то что коллизия — это разновидность ошибки, программа nestat под- считывает ее отдельно. Поле с заголовком Collisions содержит количество коллизий, зарегистрированных при отправке пакетов. На основе этого числа можно вычислить процент исходящих пакетов (ТХ packets), вызвавших коллизию. В коммутированной сети с полнодуплексными связями, т.е. в современных версиях плат Ethernet, коллизий быть не должно, даже если сеть перегружена. Если обнаружены коллизии, значит, произошло нечто серьезное. Кроме того, следует проверить, что по- ток управления поступает на ваши коммутаторы и маршрутизаторы, особенно если ваша сеть содержит связи с разными скоростями. Причинами сетевых проблем часто становятся дешевые компоненты настольного се- тевого оборудования, например коммутатор с временной проводкой, который следует заменить. Отслеживание состояния сетевых соединений Если программа netstat запущена без аргументов, она выводит на экран состояние активных TCP- и UDP-портов. Неактивные (“прослушивающие”) серверы, ожидающие соединения, как правило, скрываются, но вы можете увидеть их, выполнив команду netstat -а.5 Результаты ее работы выглядят следующим образом. linux$ netstat -a Active Internet : connections (servers and established) Proto Recv-Q Send-Q Local Address ForeignAddress State tcp 0 0 *:Idap *. * LISTEN tcp 0 0 *:mysql *. * LISTEN tcp 0 0 *:imaps *. * LISTEN tcp 0 0 bull:ssh dhcp-32hw:4208 ESTABLISHED tcp 0 0 bull:imaps nubark:54195 ESTABLISHED tcp 0 0 bull:http dhcp-30hw:2563 ESTABLISHED tcp 0 0 bull:imaps dhcp-18hw:2851 ESTABLISHED tcp 0 0 *:http *. * LISTEN tcp 0 0 bull:37203 baikal:mysql ESTABLISHED tcp 0 0 *: ssh *. * LISTEN 5 В отчете показаны также соединения для “сокетов доменов UNIX”, но поскольку они не от- носятся к работе сети, мы их не обсуждаем.
918 Часть н. Работа в сети Этот отчет сильно сокращен; например, здесь не показаны соединения сокетов UDP и UNIX. В этом отчете упомянуты входящее SSH-соединение, два входящих IMAPS- соединения, одно входящее HTTP-соединение, исходящее MySQL-соединение и группа портов, прослушивающих остальные соединения. Адреса представлены в формате имя_компьютера. служба, где служба — это номер порта. Для известных служб порты указаны в символическом виде (соответствия между номерами портов и их именами определены в файле /etc/services). При наличии оп- ции -п все адреса отображаются в числовом виде. Помните: когда служба DNS не функ- ционирует, команда netstat будет выполняться очень медленно, если не указать флаг -п. В колонках Send-Q и Recv-Q показывается, сколько запросов находится во входя- щих и исходящих очередях на данном компьютере. На другом конце соединения раз- меры очередей могут быть иными. Желательно, чтобы эти значения были близки к нулю и не были ненулевыми постоянно. Конечно, если команда netstat запускается через сетевой терминал, для ее соединения размер исходящей очереди, скорее всего, никогда не будет равен нулю. Состояние соединения определено только для протокола TCP. Протокол UDP не проверяет факт установления соединения. Наиболее распространенные состояния тако- вы: ESTABLISHED (установлено) — для активных соединений, LISTEN (ожидание) — для серверов, ожидающих поступления запросов (при отсутствии опции -а обычно не по- казываются), TIME WAIT (ожидание закрытия) — для соединений, находящихся в про- цессе закрытия. Эта информация полезна, главным образом, для устранения проблем на высоком уровне, если, конечно, базовые сетевые средства работают нормально. Команда netstat позволяет проверить правильность настройки серверов и диагностировать определенные виды нарушений связи, особенно при работе с протоколом TCP. Например, если соеди- нение находится в состоянии SYN SENT, то это означает наличие процесса, который пы- тается установить контакт с несуществующим или недоступным сервером. Если команда netstat сообщает о большом количестве соединений, находящихся в состоянии SYN WAIT, то компьютер, очевидно, не в состоянии обработать имеющееся число запросов на установление соединений. Такая ситуация может быть вызвана огра- ничениями системного ядра или даже злонамеренными попытками вызвать перегрузку. 03 Информация о настройке ядра приводилась в главе 13. Идентификация прослушивающих сетевых служб Один из наиболее часто возникающих вопросов, связанных с безопасностью, звучит так: “Какие процессы на данном компьютере прослушивает сеть в ожидании входящих соединений?” Команда netstat -а показывает все порты, активно прослушивающие соединения (любой TCP-порт в состоянии LISTEN и потенциально любой UDP-порт), но на загруженной машине эти линии могут оказаться затерянными в шуме установлен- ных ТСР-соединений. ДВ системе Linux для выявления только прослушивающих портов следует ис- пользовать команду netstat -1. Кроме того, можно добавить флаг -р, что- бы идентифицировать специфичные процессы, связанные с каждым прослу- шивающим портом.6 Пример, продемонстрированный ниже, описывает три обычные службы (sshd, sendmail и named) и одну необычную. 6 В системах UNIX, не поддерживающих флаг -р, эту и другую информацию можно получить с помощью команды Isof, описанной в разделе 6.2.
Глава 21. Управление сетями 919 linux$ netstat -Ip tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 23858/sshd tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 10342/sendmail udp 0 0 0.0.0.0:53 0.0.0.0:* 30016/named udp 0 0 0.0.0.0:962 0.0.0.0:* 38221/mudd Служба mudd с идентификатором PID 38221 прослушивает UD-порт 962. Если вы не знаете, что такое служба mudd, уточните в справочной системе. Для безопасности полезно смотреть на компьютеры с точки зрения внешнего поль- зователя, запускающего сканер порта. Для этого очень полезна команда nmap (см. раз- дел 22.8). Проверка таблицы маршрутизации Команда netstat -г отображает таблицу маршрутизации ядра. Следующие резуль- таты получены на компьютере, который имеет два сетевых интерфейса. redhat$ netstat -г -п Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ethl 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ethO 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 ethO Пункты назначения и шлюзы могут быть представлены доменными именами либо IP-адресами. Флаг -п задает вывод IP-адресов. В колонке Flags отображаются флаги, характеризующие маршрут: U (up) — актив- ный, G (gateway) — шлюзовой, Н (host) — узловой (связан с конкретным адресом, а не се- тью). Флаг D (не показан) обозначает маршрут, полученный в результате переадресации по протоколу ICMP. Флаги Син, стоящие вместе, обозначают маршрут к компьюте- ру, проходящий через промежуточный шлюз. Остальные поля содержат статистические данные о маршруте: текущее число TCP-соединений по этому маршруту, количество от- правленных пакетов и имя используемого интерфейса. 03 0 таблицах маршрутизации рассказывалось в разделе 14.5. Рассмотренный вариант команды netstat полезен для проверки правильности та- блицы маршрутизации. Особенно важно убедиться в наличии и корректности стандарт- ного маршрута. Он обозначается в виде адреса со всеми нулями (0.0.0.0) или словом default. Стандартный маршрут может не существовать, но такая конфигурация крайне нетипична. Просмотр статистических данных функционирования различных сетевых протоколов Команда netstat -s отображает содержимое всевозможных счетчиков, используе- мых в сетевых программах. Информация разбивается на разделы в соответствии с про- токолами: IP, ICMP, TCP и UDP. Ниже показаны отдельные фрагменты листинга ко- манды netstat -s, полученного на компьютере-шлюзе; они отредактированы, чтобы остались только наиболее интересные данные.
920 Часть II. Работа в сети 1р: 671349985 total packets received О forwarded 345 incoming packets discarded 667912993 incoming packets delivered 589623972 requests sent out 60 dropped because of missing route 203 fragments dropped after timeout Проверьте, что ни один пакет не был потерян или забракован. Некоторые входящие пакеты могут быть забракованы, но быстрое увеличение этого показателя обычно озна- чает уменьшение объема памяти или другую проблему, связанную с ресурсами. Icmp: 242023 ICMP messages received 912 input ICMP message failed. ICMP input histogram: destination unreachable: 72120 timeout in transit: 573 echo requests: 17135 echo replies: 152195 66049 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 48914 echo replies: 17135 В этом примере количество эхо-запросов в разделе входа соответствует количеству эхо-ответов в разделе выхода. Обратите внимание на то, что сообщение “destination un- reachable” может генерироваться даже в том случае, когда все пакеты явно допускают перенаправление. Неисправные пакеты в конец концов достигнут шлюза, который их отвергнет, и со- общение об ошибках будет отправлено обратно по цепочке шлюзов. Тер: 4442780 active connections openings 1023086 passive connection openings 50399 failed connection attempts 0 connection resets received 44 connections established 666674854 segments received 585111784 segments send out 107368 segments retransmited 86 bad segments received. 3047240 resets sent Udp: 4395827 packets received 31586 packets to unknown port received. 0 packet receive errors 4289260 packets sent Рекомендуем определить приемлемые диапазоны этих показателей, чтобы можно было сразу же распознать ненормальное состояние сети.
Глава 21. Управление сетями 921 21.6. Проверка функционирования ИНТЕРФЕЙСА В РЕАЛЬНОМ ВРЕМЕНИ Хороший способ обнаружить сетевые проблемы — посмотреть, что происходит пря- мо сейчас. Сколько пакетов было послано за последние пять минут через данный ин- терфейс? Сколько байтов? Происходили ли коллизии или другие ошибки? Ответить на все эти вопросы можно, наблюдая за функционированием сети в реальном времени. Для этого были разработаны разные инструменты. В системе Solaris в командную строку netstat -i можно добавить интервал SOiariS в секундах и значение счетчика. solaris$ netstat -i 2 3 input elOOOg output input (Total) output packets errs packets errs colls packets errs packets errs colls 17861 0 26208 0 0 17951 0 26298 0 0 4 0 2 0 0 4 0 2 0 0 1 0 1 0 0 1 0 1 0 0 В системах HP-UX и AIX используется единственное число, которое задает интервал (в секундах), за который следует собрать статистические показатели. • $ netstat -i 2 (lan0)-> input packets output packets (Total)-> input packets output packets 9053713 9052513 10115002 10113803 8 8 8 8 22 22 22 22 9 9 9 9 Команда netstat в системе Linux не имеет параметра, задающего интервал, поэтому в системе Linux мы рекомендуем использовать совершенно другой инструмент: утилиту sar. (Утилита sar рассматривается в разделе 29.4 с точки зрения общего мониторинга системы.) В большинстве дистрибутивных па- кетов утилита sar по умолчанию не инсталлируется, но всегда доступна как дополнительная функциональная возможность. Пример, продемонстрирован- ный ниже, содержит отчеты, которые формируются каждые две секунды в те- чение одной минуты (т.е. 30 отчетов). Аргумент DEV представляет собой лите- ральное ключевое слово, а не обозначение устройства или имя интерфейса. redhat$ sar -n DEV 2 30 17:50:43 IFACE rxpck/s txpck/s rxbyt/s 17:50:45 lo 3.61 3.61 263.40 17:50:45 ethO 18.56 11.86 1364.43 17:50:45 ethl 0.00 0.00 0.00 txbyt/s rxcmp/s txcmp/s rxmcst/s 263.40 0.00 0.00 0.00 1494.33 0.00 0.00 0.52 0.00 0.00 0.00 0.00 Этот пример получен на компьютере, работающем под управлением операционной системы Red Hat, с двумя сетевыми интерфейсами. Вывод содержит как моментальные, так и средние данные об использовании интерфейса в байтах и пакетах. Совершенно очевидно, что второй интерфейс (ethl) не используется вообще. В первых двух столбцах приведены моменты времени, в которые были сделаны из- мерения, а также имена сетевых интерфейсов. Следующие два столбца содержат количе- ство полученных и переданных пакетов соответственно.
922 Часть II. Работа в сети Столбцы rxbyt/s и txbyt/s, вероятно, являются самыми полезными, поскольку содержат информацию о реально используемой пропускной способности. Последние три столбца состоят из статистических показателей о сжатых (rxcmp/s, txcmp/s) и многоадресных (rxmcst/s) пакетах. Команда sar -n DEV особенно полезна для отслеживания источников ошибок. Команда ifconfig может предупредить о существовании проблем, но не способна со- общить, является ли ошибка следствием постоянной низкоуровневой проблемы или кратковременного, но катастрофического события. В таком случае для того, чтобы понять, что происходит, необходимо наблюдать за работой сети в течение некоторого времени и при разных условиях загруженности. Попробуйте выполнить команду ping с загрузкой большого по размеру пакета, а затем просмотрите отчет о результатах вы- полнения команды sar -n DEV. 21.7. Анализаторы пакетов Программы tcpdump и Wireshark относятся к классу утилит, известных как анализа- торы пакетов. Они следят за трафиком в сети и регистрируют либо выводят на экран пакеты, удовлетворяющие заданным критериям. Например, можно перехватывать все пакеты, посылаемые на какой-то компьютер или с него, либо TCP-пакеты, относящие- ся к конкретному сетевому соединению. Анализаторы пакетов полезны как для решения известных проблем, так и для выяв- ления абсолютно новых. Важно время от времени запускать эти программы и проверять, нормально ли обрабатывается сетевой трафик. Поскольку анализаторы должны уметь перехватывать пакеты, которые локальный компьютер обычно не получает (или на которые не обращает внимания), базовые се- тевые аппаратные средства должны разрешать доступ к каждому пакету. Это характерно для широковещательных технологий, в частности Ethernet, а также для большинства со- временных локальных сетей. Анализаторы пакетов должны иметь доступ к низкоуровневому трафику, поэтому их работе могут мешать коммутаторы, одной из функций которых является препятствие распространению “ненужных” пакетов. Однако с помощью анализаторов удается полу- чить полезную информацию даже в коммутируемых сетях. Можно, к примеру, обнару- жить проблемы, затрагивающие широковещательные и групповые пакеты. Объем вы- даваемой информации зависит от модели коммутатора. Ш О коммутаторах рассказывалось в разделе 16.1. Аппаратный интерфейс должен не только иметь возможность получать доступ ко всем сетевым пакетам, но и содержать механизм, обеспечивающий передачу этих па- кетов вверх на программный уровень. Ведь обычно адреса пакетов проверяются на ап- паратном уровне, а ядру предоставляются лишь широковещательные/групповые пакеты и те, которые адресованы данному компьютеру. В беспорядочном режиме (promiscuous mode) интерфейс позволяет ядру получать все сетевые пакеты, даже если они предна- значены для других компьютеров. Анализаторы понимают многие форматы пакетов, используемые стандартными де- монами, и часто могут отображать содержимое пакетов в удобном для восприятия виде. Это облегчает пользователю анализ сеанса между двумя программами. Существуют ана- лизаторы, которые, кроме заголовка пакета, выводят и его содержимое в текстовом виде, что полезно при исследовании протоколов верхних уровней.
Глава 21. Управление сетями 923 Некоторые из этих протоколов пересылают информацию (в том числе и пароли) по сети в незашифрованном виде, поэтому следует заботиться о сохранении конфиденци- альности пользовательских данных. С другой стороны, ничто так не подчеркивает не- обходимость шифрования, как вид паролей, пересылаемых в открытом виде в сетевом пакете. В связи с тем что анализатору необходим доступ к пакетам на самом низком уров- не, он должен запускаться от имени пользователя root. Подобное ограничение снижает шансы обычных пользователей получить доступ ко всему сетевому трафику, но на самом деле этот барьер можно преодолеть. Во многих организациях анализаторы пакетов уда- лены с большинства компьютеров с целью уменьшения риска злоупотребления этими программами. Если такая мера невозможна, следует проверять интерфейсы системы, чтобы они не работали в “беспорядочном” режиме без ведома или согласия администра- тора. В Linux интерфейс, работающий в “беспорядочном” режиме, помечается в выводе команды ifconfig флагом PROMISC. В системах семейства Linux факт, что интерфейс был переключен в “беспорядочный режим”, также записывается в журнал ядра. Утилита tcpdump: стандартный анализатор Замечательный анализатор пакетов tcpdump, написанный Ваном Якобсоном (Van Jacobson), входит в состав большинства дистрибутивов Linux. Он уже давно считается промышленным стандартом, и другие анализаторы читают и/или записывают файлы трассировки в формате tcpdump, который в настоящее время называется libpcap. По умолчанию утилита tcpdump использует первый найденный ею сетевой интер- фейс. Если она выбрала не тот интерфейс, то посредством опции -i следует задать нуж- ный. В случае неисправности службы DNS или если необходимо видеть адреса компью- теров, воспользуйтесь опцией -п. Эта опция имеет большое значение, так как медленная работа DNS может привести к удалению пакетов еще до того, как они будут проанали- зированы утилитой tcpdump. Опция -v позволяет получить более детальное описание каждого пакета, а самые подробные результаты выдаются при задании опции -w. Если указана опция -w, утилита сохраняет перехваченные пакеты в файле. Для чтения пакетов из файла предназначена опция -г. Отметим, что команда tcpdump -w по умолчанию сохраняет только заголовки па- кетов. Это сделано для уменьшения размеров распечаток, но при этом можно потерять наиболее полезную и релевантную информацию. Поэтому, если вы уверены, что, кроме заголовков, вам нужна дополнительная информация, используйте флаг -s со значени- ем, которое равно 1056 (фактические значения зависят от максимального размера пакета (MTU)), чтобы иметь возможность проанализировать весь пакет. В качестве примера рассмотрим укороченный вариант распечатки, полученной на машине nubark. Спецификация фильтра host bull ограничивает вывод пакета на экран только информацией, относящейся к машине bull, которая может быть как ис- точником, так и получателем. $ sudo tcpdunp host bull 12:35:23.519339 bull.41537 > nubark.domain: A? atrust.com. (28) (DF) 12:35:23.519961 nubark.domain > bull.41537: A 66.77.122.161 (112) (DF) Первый пакет свидетельствует о том, что компьютер bull послал компьютеру nubark запрос на поиск домена atrust. com в системе DNS. Ответом является IP-адрес машины, связанной с этим именем, т.е. 66.77.122.161. Обратите внимание на временную метку в левой части строки и на то, что команда tcpdump понимает протокол на уровне
924 Часть II. Работа в сети приложения (в данном случае DNS). Номер порта на компьютере bull является про- извольным и записывается в виде числа (41537), но поскольку номер порта на сервере хорошо известен (53), команда tcpdump выводит его символическое имя domain. Анализаторы пакетов могут порождать огромные массивы информации, неподъем- ные не только для человека, но и для операционной системы. Для того чтобы избежать перегрузки сети, утилита tcpdump позволяет задавать сложные фильтры. Например, сле- дующий фильтр собирает только входящий веб-трафик из одной подсети. $ sudo tcpdump src net 192.168.1.0/24 and dst port 80 Справочная страница утилиты tcpdump содержит несколько хороших примеров сложных фильтров, а также список примитивов.7 Система Solaris содержит анализатор, работающий так же, как tcpdump. Он soiaris называется snoop. Дистрибутивные пакеты систем HP-UX, AIX и большин- ства систем семейства Linux не содержат таких утилит. solaris$ snoop Using device /dev/el000g0 (promiscuous mode) nubark -> Solaris TCP D=22 S=58689 Ack=2141650294 Seq=3569652094 Len=0 Win=15008 Options=<nop,nop,tstamp 292567745 289381342> nubark -> Solaris TCP D=22 S=58689 Ack=2141650358 Seq=3569652094 Len=0 Win=15008 Options=<nop,nop,tstamp 292567745 289381342> ? -> (multicast) ETHER Type=023C (LLC/802.3), size = 53 bytes Если вы используете зоны Solaris, обратите внимание на то, что утилита snoop рабо- тает правильно, только если вы устраняете проблему в локальной зоне. Утилиты Wireshark и TShark: усовершенствованный вариант tcpdump Утилита tcpdump появилась довольно давно, но в последнее время все более по- пулярным становится новый открытый пакет под названием Wireshark (который ранее назывался Ethereal). Пакет Wireshark активно совершенствуется и содержит больше функциональных возможностей, чем большинство коммерческих приложений. Это не- обычайно мощный инструмент анализа, который должен входить в инструментальный набор каждого эксперта. Кроме того, он незаменим при обучении. Пакет Wireshark содержит как пользовательский графический интерфейс (wireshark), так и интерфейс командной строки (tshark). В системе Linux он ин- сталлируется автоматически. Администраторы системы UNIX должны посетить сайт wireshark.org, на котором хранится открытый код и множество скомпилированных модулей. Программа Wireshark может читать и записывать файлы слежения в форматах, ис- пользуемых многими другими анализаторами пакетов. Еще одна удобная функциональ- ная возможность заключается в том, что одним щелчком мыши можно выбрать любой пакет в сеансе TCP и попросить программу Wireshark заново собрать (соединить вместе) данные, включенные во все пакеты, находящиеся в потоке. Эта возможность полезна, если вы хотите проверить данные, переданные в ходе полного TCP-обмена, например, какое соединение было использовано для передачи сообщения об ошибке по сети. 7 Если ваши требования, касающиеся фильтрации, превосходят возможности утилиты tcpdump, обратите внимание на утилиту ngrep (ngrep. sourceforge.net), которая может филь- тровать пакеты в соответствии с их содержимым.
Глава 21. Управление сетями 925 Фильтры перехвата программы Wireshark функционально идентичны фильтрам ути- литы tcpdump, поскольку программа Wireshark использует ту же самую библиотеку libpcap. Тем не менее следует быть внимательным: важный нюанс заключается в том, что программа Wireshark имеет дополнительную функцию “фильтры дисплея”, которая влияет на внешний вид данных, а не содержание, перехваченное анализатором. Фильтр дисплея имеет более мощный синтаксис, чем библиотека libpcap, поддерживаемая в момент перехвата. Фильтры дисплея похожи на фильтры библиотеки libpcap, но они не совпадают с ними. Программа Wireshark имеет встроенные дешифраторы для многих сетевых протоко- лов, включая многочисленные протоколы, используемые для реализации сетей хранения данных. Она преобразует пакет в структурированное информационное дерево, в котором каждый бит информации описан на английском языке. На рис. 21.2 показан перехват DNS-запроса и ответа на него в программе Wireshark. file Edit yiew fio Rapture Analyze Statistics tdelp В V « Ш Ш H X ® ы 4 * Ф 7 £ Bit Gt О ’ 0filter: h ip »ddrq ZL3 144 13Э 134 yxi ip жИг is5 238 ▼ | ф Expression.., Д £lewI Apply > Fnaa 52 (IM byt«« on urt, 159 byt»» c«ptur*d( t> Etlwmot П, Srt TjranCoap_47 4f 2f (90 «9 81 47 4f 2f), Ost 2/1с«1С<ж_а2 91 м (ее 11 cb. «2 SI t> Internet Protocol, Src 213 144 133.194 (213 144 133 194). Opt 195 238 24 152 (195 238 24 152) t> User OwtaQraa Protocol, Src Port down (53), Ost Port 32B1G (32819) v Dornin Nnm Systee (гжаропм) |Г1М □ 000343000 seconds] Puc. 2L2. Пара DNS-пакетов в программе Wireshark В таблице, расположенной в верхней части рисунка, указаны два пакета. Первый пакет представляет собой запрос на пересылку на DNS-сервер, а второй пакет являет- ся полученным ответом. Выбран пакет запроса, поэтому в среднем окне показана его структура. В нижнем окне пакет представлен в виде набора байтов. Раскрытый раздел дерева демонстрирует данные, содержащиеся в пакете. Содержание пакета в виде байтов также может представлять интерес, потому что иногда он содер- жит фрагменты, которые могут подсказать, что именно произошло. Сканировать текст особенно удобно, когда нет встроенного анализатора текущего протокола. Справочное меню программы Wireshark содержит массу примеров, с которыми можно начинать ра- ботать. Экспериментируйте!
926 Часть II. Работа в сети Следует сделать одно предупреждение, касающееся программы Wireshark: несмотря на множество прекрасных функциональных возможностей, она еще требует многолет- ней доработки с точки зрения безопасности. Запустите текущую версию, но не остав- ляйте ее работать постоянно на важных компьютерах; программа Wireshark может стать потенциальным проводником для атаки. 21.8. Служба Netalizr Института ICSI Мы рассмотрели несколько инструментов для отладки сети и анализа сетевой кон- фигурации. Но даже при самом тщательном мониторинге полезно иметь инструмент, который время от времени будет просматривать вашу сеть. Netalyzr — это служба, пре- доставляемая Международным институтом компьютерных наук из Беркли (International Computer Science Institute at Berkeley), которая представляет собой полезную альтерна- тиву. Для ее использования просто зайдите на сайт netalyzr.icsi.berkeley.edu (об- ратите внимание на то, что буква ‘е’ пропущена специально), включив в вашем браузере поддержку языка Java. Служба Netalyzr проверяет ваше интернет-соединение разными способами. Очень полезно иметь доступ к вашей сети как изнутри (через программу Java, выполняемую в вашем браузере), так и с серверов института ICSI. На рис. 21.3 показан отчет службы Netalyzr для рабочей станции в частной сети, сое- диненной с внешним миром связью DSL. Служба Netalyzr отлично устанавливается, но имеет небольшие проблемы с веб-сервером Apache (тем не менее блокирование неверно составленных HTTP-запросов может оказаться полезным). Полный отчет состоит из разделов, содержащих информацию о IP-соединениях, полосе пропускания, простоях, буферизации, обработке фрагментированных пакетов и других аспектах. Особенно сильны тесты для выявления аномалий в системе DNS и протоколе HTTP. 21.9. Протоколы управления сетями Усложнение и разрастание сетей за последние 20 лет вызвало потребность в разра- ботке средств управления сетями. Поставщики операционных систем и разработчики стандартов подходили к решению этой задачи самыми разными способами. Наиболее значительным результатом стало появление ряда стандартных протоколов управления сетевыми устройствами и множества высокоуровневых программных средств, в которых эти протоколы используются. Протоколы управления сетями определяют стандартные методы зондирования какого-либо устройства с целью выявления его сетевых соединений, конфигурации и общего состояния. Кроме того, протоколы позволяют модифицировать часть этой ин- формации, чтобы можно было стандартизировать управление различными устройствами на сетевом уровне и осуществлять это управление с центральной станции. Самым распространенным протоколом управления, используемым в сетях TCP/IP, является SNMP (Simple Network Management Protocol — простой протокол управления сетями). Несмотря на название, этот протокол достаточно сложный. Он определяет ие- рархическое пространство имен для объектов управления и методы чтения/записи дан- ных, относящихся к этим объектам, на каждом узле иерархии. Он также определяет спо- соб, которым управляемые сущности (“агенты”) посылают сообщения о происходящих событиях (“прерывания”) станциям управления.
Глава 21. Управление сетями 927 TheicsiNetalyzr Beta Result Summary adsl-133-194.dsl.init7.net / 213.144.133.194 Rewarded at 12 33 EDT (16:33 UTG)an Sat, August 08 2009 Permalink Transcrpt. Noteworthy Events Minor Aberrations !• Network packet buffering may be excessive 4 • An HTTP proxy was detected based on added or changed HTTP traffic 4 • The detected HTTP proxy blocks malformed HTTP requests 4 Address-based Tests NAT detection: NAT Detected Yourglobal IP address is 21 3 144 1 33.194 while your local one is 192 168 0,203, You are behind a NAT. Your local address is in unroutable address space. ' Your NAT renumbers TCP source ports sequentially. The fallowing graph shows connection attempts on the X-axis and theircorresponding source ports on the Y-axis. 36677i , . • 36668*-*------—------------------- Puc. 2L3. Отчет службы Netalyv Протокол SNMP действительно является простым; самая сложная часть находится над протокольным уровнем и заключается в соглашениях по организации пространства имен и по форматированию элементов данных на узле иерархии. Протокол SNMP ши- роко поддерживается разработчиками программного обеспечения. Существует и ряд других стандартов управления сетями. Многие из них созда- ны организацией DMTF (Distributed Management Task Force — рабочая группа по раз- работке распределенных систем управления), которая реализовала такие концепции, как WBEM (Web-Based Enterprise Management — система управления предприятием на основе веб-технологий), DMI (Desktop Management Interface — интерфейс управления компьютером) и CIM (Conceptual Interface Model — концептуальная модель интерфей- са). Некоторые из этих концепций, в частности DMI, приняты рядом известных фирм- производителей и могут служить полезным дополнением (а иногда и заменой) протоко- лу SNMP. В настоящее время, однако, основным средством управления сетями остается все же SNMP. Поскольку SNMP — абстрактный протокол, для его использования нужны программа-сервер (“агент”) и программа-клиент (“менеджер”). (Как ни странно, сер- верная сторона SNMP является управляемым элементом, а клиентская — управляю- щим.) Клиентом может быть как простая утилита, работающая в режиме командной строки, так и выделенная станция управления, на мониторе которой в графическом виде отображается сеть вместе со всеми неполадками.
928 Часть II. Работа в сети Выделенные станции управления сетью являются главной причиной существования самих протоколов управления. Большинство программных продуктов позволяет стро- ить не только логическую, но и топографическую модель сети. Обе модели выводятся на экран, при этом постоянно отображается текущее состояние каждого сетевого компонента. Подобно тому, как график может показать скрытый смысл, заложенный в заполнен- ной числами странице, так и станция управления сетью способна обобщить и предста- вить состояние крупной сети в форме, приемлемой для человека. Другим способом та- кую информационную сводку получить практически невозможно. Основное преимущество протокола SNMP в том, что абсолютно все типы сетевых аппаратных средств выводятся на один уровень. Linux-системы в основном похожи друг на друга, чего нельзя сказать о маршрутизаторах, шлюзах и остальных низкоуровневых компонентах. При использовании протокола SNMP все они начинают “общаться” на одном языке и могут зондироваться, сбрасываться в начальное состояние и конфигури- роваться с центральной станции. Очень удобно, когда есть один согласованный интер- фейс, применимый ко всем сетевым устройствам. 21.10. SNMP: простой протокол управления сетями Когда в начале 90-х годов протокол SNMP впервые появился на рынке, возникла своеобразная “золотая лихорадка”. Сотни компаний выпустили собственные пакеты управления по протоколу SNMP. Кроме того, многие поставщики аппаратных и про- граммных средств стали включать в свои продукты SNMP-агенты. Большинство компо- нентов сетевого аппаратного обеспечения, предназначенных для производства (а не для домашнего использования), в настоящее время содержат агенты SNMP. Прежде чем погрузиться в дебри SNMP, заметим, что терминология, употребляемая в этой области, одна из самых бестолковых и невразумительных. Стандартные назва- ния объектов и концепций SNMP будут активно уводить читателей от понимания их назначения, так что запаситесь терпением. У людей, ответственных за такое положение вещей, следует отобрать клавиатуру. Структура протокола SNMP В SNMP данные организованы иерархически, причем структура иерархии жестко определена. Это делает пространство имен универсальным и расширяемым, по крайней мере теоретически. Большие его области оставлены для перспективного использования; дополнения, создаваемые поставщиками операционных систем, локализуются в опреде- ленных диапазонах во избежание конфликтов. Для формирования пространства имен используются так называемые базы управляющей информации (Management Information Base, MIB). Это структурированные текстовые файлы, которые содержат описания дан- ных, доступных по протоколу SNMP. Ссылки на конкретные переменные, описываемые в базе данных, называются идентификаторами объектов (Object Identifier, OID). В переводе на человеческий язык это означает всего лишь, что протокол SNMP определяет иерархическое пространство имен переменных, хранящих “интересные” па- раметры системы. Иерархия SNMP напоминает иерархию имен файловой системы. Только в качестве символа-разделителя используется точка, а каждому узлу иерархии присваивается не имя, а номер. Для облегчения ссылок узлам присваиваются также текстовые имена, но схема именования выходит за рамки самой иерархии и определяется на высоком уровне. (Это похоже на связь между именами компьютеров и их IP-адресами.)
Глава 21. Управление сетями 929 К примеру, идентификатор OID, соответствующий показателю общего времени ра- боты системы, выглядит так: 1.3.6.1.2.1.1.3. В текстовом виде его можно записать сле- дующим образом. iso.org.dod.intemet.mgmt.mib-2.system.sysUpTime Верхние уровни иерархии SNMP носят искусственный характер и обычно не содер- жат полезных данных. По сути, интересная информация начинает появляться только на уровне iso.org.dod.internet.mgmt (вчисловом виде — 1.3.6.1.2). Основная административная база данных SNMP для протоколов TCP/IP (MIB-I) обеспечивает доступ к наиболее важным управляющим данным: информации о системе, ее интерфейсах, преобразовании адресов и протоколах (IP, ICMP, TCP, UDP и др.). В до- кументе RFC1213 описана новая, более полная версия этой базы: MIB-П. Большинство SNMP-серверов поддерживает базу MIB-П. В табл. 21.1 приведена выборка узлов иерар- хии из пространства имен MIB-II. Таблица 21.1. Некоторые идентификаторы из базы MIB-II ою* ' ‘ Oi л .Ллй/ *. . . ЬЛ.М.-ч, system.sysDescr строка Информация о системе: производитель, модель, тип ОС и т.д. system.sysLocation строка Физическое местонахождение компьютера system.sysContact строка Информация о владельце компьютера system.sysName строка Имя системы (обычно это полное DNS-имя) interfaces.ifNumber целое Количество имеющихся сетевых интерфейсов interfaces.ifTable таблица Таблица с информацией о каждом интерфейсе ip.ipForwarding целое 1, если система является шлюзом, иначе 2 ip.ipAddrTable таблица Таблица данных IP-адресации (маски и т.д.) ip.ipRouteTable таблица Системная таблица маршрутизации icmp.icmpInRedirects целое Число полученных директив переадресации протокола ICMP icmp.icmpInEchos целое Число полученных эхо-пакетов tcp.tcpConnTable таблица Таблица текущих ТСР-соединений udp.udpTable таблица Таблица с информацией о UDP-сокетах, через которые серверы ожидают прием запросов а Относительно узла iso.org.dod.internet.mgmt.mib-2. Помимо основной административной базы данных, существуют базы для различных типов аппаратных интерфейсов и протоколов. Имеются также базы данных по отдель- ным поставщикам и конкретным изделиям. База MIB — это лишь соглашение об именовании управляющих данных. Для того чтобы эта схема заработала, ее необходимо подкрепить программой-агентом, которая будет обеспечивать соответствие содержимого SNMP-переменных текущему состоянию устройства. Код для основной базы MIB (в настоящее время MIB-II) поставляется с большинством SNMP-агентов Linux. Некоторые агенты разрешают подключать допол- нительные базы данных. Агенты SNMP — сложные существа, имеющие общие проблемы с безопасностью. Не следует полагаться на агентов, которых поставщики предоставляют в готовом виде. Ра- зумнее скомпилировать и инсталлировать текущую версию агента NET-SNMP (см. далее).
930 Часть II. Работа в сети Операции протокола SNMP В пространстве имен SNMP определено всего четыре базовые операции: get (про- читать), get-next (прочитать следующий), set (записать) и trap (прерывание). Операции get и set — это базовые операции чтения и записи данных на узле иерар- хии, который определяется конкретным значением OID. Операция get-next использу- ется для последовательного прохода по базе MIB, а также для чтения таблиц. Прерывание (операция trap) — это неожиданное уведомление клиента о том, что на сервере произошло нестандартное событие. Определен ряд стандартных прерываний, в том числе уведомления вида “я только что включился”, сообщения об отказах и восста- новлении сетевых каналов, а также сообщения, связанные с различными проблемами маршрутизации и аутентификации. Широко применяются и нестандартные прерывания, например для отслеживания значений требуемых SNMP-переменных. Если эти значе- ния выходят за границы установленного диапазона, выдается соответствующее сообще- ние. Способ определения получателей таких сообщений зависит от реализации агента. Поскольку сообщения SNMP потенциально могут изменять информацию о конфи- гурации компьютера, необходим какой-то механизм защиты. Простейшая защита осно- вана на концепции группового имени (community name). Для тех, кто не страдает кос- ноязычием, поясним: на языке разработчиков протокола это синоним слова “пароль”. Доступу только для чтения соответствует один пароль, простите, групповое имя, а до- ступу для записи — другой. Несмотря на то что многие организации продолжают использовать общепринятую строковую аутентификацию имени и пароля, версия 3 протокола SNMP включает ме- тоды управления доступом с высокой степенью безопасности. Их настройка требует до- полнительной работы, но снижение риска стоит этого. Если по каким-то причинам вы не можете использовать версию 3 протокола SNMP, по крайней мере выберите строку имени и пароля, которую сложно угадать. RMON: база MIB для дистанционного мониторинга База RMON (remote monitoring — дистанционный мониторинг) накапливает данные о общих характеристиках сети (т.е. тех, которые не относятся к конкретному устрой- ству). Сетевые анализаторы, или “зонды”, могут собирать информацию о загруженности и производительности сети. Полезные данные группируются, подвергаются статистиче- ской обработке и доставляются на центральную станцию управления для анализа и гра- фического воспроизведения. Многие зонды имеют буферы для перехваченных пакетов и могут работать подобно утилите tcpdump. База RMON формально описана в документе RFC1757, который был принят в каче- стве чернового стандарта в 1995 году. Она разделяется на девять “групп RMON”. Каждая группа хранит собственный набор статистических данных. Если сеть достаточно боль- шая и имеет много глобальных соединений, необходимо рассмотреть возможность при- обретения зондов для снижения SNMP-трафика через глобальные соединения. При на- личии итоговых статистических данных отпадет необходимость в дистанционном сборе первичных данных. Многие коммутаторы и маршрутизаторы поддерживают базы RMON и хранят в них собственные статистические данные.
Глава 21. Управление сетями 931 21.11. Агент NET-SNMP После публикации первой версии стандарта SNMP в университете Карнеги-Меллона (Carnegie Mellon University) и Массачусетсском технологическом институте (MIT) были разработаны реализации протокола. Университетская реализация протокола SNMP была более полной и быстро стала стандартом де-факто. После прекращения разработ- ки SNMP-продуктов в университете Карнеги-Меллона работу продолжили специалисты Калифорнийского университета в Дэвисе. Когда код системы стабилизировался, она была передана для дальнейшего сопровождения компании SourceForge. В настоящее время пакет называется NET-SNMP. Этот пакет теперь считается официальной бесплат- ной реализацией протокола SNMP для систем UNIX и Linux. Последнюю версию пакета можно получить на веб-узле net-snmp. sourceforge. net. В состав пакета входят SNMP-агент, несколько утилит командной строки и даже би- блиотека для разработки SNMP-приложений. Ниже рассмотрим работу самого агента, а об утилитах поговорим чуть позже. Как и в других реализациях протокола, агент NET-SNMP собирает данные о локаль- ном компьютере и предоставляет их SNMP-менеджерам по сети. По умолчанию инстал- лируются базы MIB, содержащие статистические данные об использовании сетевых ин- терфейсов, памяти, дисков и центрального процессора. Возможности агента достаточно велики, так как он способен запустить любую Linux-команду и представить ее выходные данные в качестве SNMP-ответа. Это позволяет посредством протокола SNMP осущест- влять мониторинг событий, происходящих в системе. По умолчанию агент инсталлируется под именем /usr/sbin/snmpd. Обычно он за- пускается на этапе начальной загрузки системы и считывает параметры конфигурации из файлов, находящихся в каталоге /etc/snmp. Наиболее важный из этих файлов на- зывается snmpd. conf; он содержит большинство конфигурационных параметров и опи- сание множества доступных методов сбора данных. При разработке пакета его авторы полагали, что пользователи будут редактировать только файл snmpd. local. conf. Но на практике приходится хотя бы один раз изменять и файл snmpd. conf, чтобы отключить те методы сбора данных, использование которых не планируется. Сценарий configure пакета NET-SNMP позволяет задать используемый по умолча- нию журнальный файл и ряд других локальных параметров. С помощью опции -1, ука- зываемой при вызове демона snmpd, можно выбрать другой журнальный файл, а благода- ря опции -s журнальные сообщения направляются в систему Syslog. Перечень наиболее важных опций демона snmpd приведен в табл. 21.2. Мы рекомендуем всегда задавать оп- цию -а. При поиске неисправностей удобно применять опции -V, -d и -D, которые по- зволяют получать более детальную информацию о происходящих в системе событиях. Таблица 21.2. Опции демона snmpd пакета NET-SNMP ОпЦМ -1 файл -а -d -V -D -h Направление журнальной информации в указанный файл Регистрация адресов всех SNMP-соединений Регистрация содержимого каждого SNMP-пакета Включение режима подробного описания событий Регистрация отладочной информации Отображение аргументов демона snmpd
932 Часть II. Работа в сети Окончание табл. 21.2 Опция Назначение . - -3^ -н Отображение директив конфигурационного файла -А Добавление данных в журнальный файл, а не его перезапись -S Направление журнальной информации в систему Syslog Следует заметить, что существует большое количество полезных модулей, написан- ных на языках Perl для SNMP, Ruby и Python. Их можно найти в соответствующих репо- зиториях. 21.12. Программы управления сетями Мы начнем этот раздел с рассмотрения простейших SNMP-инструментов: команд пакета NET-SNMP. С их помощью удобно проверять значения конкретных идентифи- каторов OID. Затем познакомимся с программой Cacti, которая строит графики измене- ния SNMP-переменных, и системой мониторинга событий Nagios. В завершение приво- дятся рекомендации относительно того, на что следует обращать внимание при покупке коммерческих систем. Команды пакета NET-SNMP Даже если система поставляется с собственным SNMP-сервером, для полноценного администрирования понадобится скомпилировать и инсталлировать семь клиентских команд пакета NET-SNMP (табл. 21.3). Таблица 21.3. Команды пакета NET-SNMP snmpdelta snmpdf Контролирует изменения SNMP-переменных во времени Контролирует изменение дискового пространства на удаленном компьютере по протоколу SNMP snmpget snmpgetnext snmpset snmptable snmptranslate snmptrap snmpwalk Запрашивает у агента значение SNMP-переменной Запрашивает значение следующей переменной последовательности Передает агенту значение SNMP-переменной Запрашивает таблицу значений SNMP-переменных Осуществляет поиск идентификаторов OID и их описаний в базе MIB Генерирует сообщение о прерывании Просматривает базу MIB начиная с заданного идентификатора OID Перечисленные команды чрезвычайно удобно использовать в сценариях. Например, часто требуется сценарий, в котором данные, полученные командой snmpget, каждые несколько минут сохраняются в текстовом файле. (Составить такой график позволит де- мон cron; см. главу 9.) Примечательна также команда snmpwalk. Начав с указанного идентификатора OID (или, по умолчанию, с начала базы MIB), она выполняет в цикле запрос get-next. В результате формируется полный список доступных идентификаторов OID и их значе- ний. Команда snmpwalk особенно полезна, если необходимо обнаружить новые иденти- фикаторы и организовать их мониторинг.
Глава 21. Управление сетями 933 Ниже приведен сокращенный пример работы команды snmpwalk на узле tuva. Строка имени и пароля имеет вид “secret813community”, а флаг -vl означает простую аутентификацию. $ snmpwalk -с secrete13community -vl tuva SNMPv2-MIB::sysDescr.О = STRING: Linux tuva.atrust.com 2.6.9-11.ELsmp #1 SNMPv2-MIB::sysUpTime.0 = Timeticks: (1442) 0:00:14.42 SNMPv2-MIB::sysName.0 = STRING: tuva.atrust.com IF-MIB::ifDescr.l = STRING: lo IF-MIB::ifDescr.2 = STRING: ethO IF-MIB::ifDescr.3 = STRING: ethl IF-MIB::ifType.1 = INTEGER: softwareLoopback(24) IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6) IF-MIB::ifPhysAddress.1 = STRING: IF-MIB::ifPhysAddress.2 = STRING: 0:11:43:d9:le:f5 IF-MIB::ifPhysAddress.3 = STRING: 0:11:43:d9:le:f6 IF-MIB::ifInOctets.1 - Counter32: 2605613514 IF-MIB::ifInOctets.2 = Counter32: 1543105654 IF-MIB::ifInOctets.3 = Counter32: 46312345 IF-MIB::ifInUcastPkts.1 = Counter32: 389536156 IF-MIB::ifInUcastPkts.2 = Counter32: 892959265 IF-MIB::ifInUcastPkts.3 = Counter32: 7712325 В этом примере команда отобразила основную информацию о системе и статисти- ческие данные о работе ее сетевых интерфейсов: loO, ethO и ethl. В зависимости от поддерживаемых агентом баз MIB, вывод команды snmpwalk может содержать сотни строк. Сбор и накопление данных протокола SNMP Сетевые данные лучше всего оценивать визуально и с учетом временной перспекти- вы. Важно иметь возможность отслеживать и изображать графически показатели произ- водительности, но выбор конкретного программного обеспечения не является критиче- ски важным. Одним из наиболее популярных пакетов для сбора и графического отображения дан- ных о протоколе SNMP был пакет MRTG, написанный Тоби Отикером. Большая часть пакета MRTG была написана на языке Perl. Он может регулярно запускаться демоном cron и собирать данные от любого источника SNMP. Каждый раз при запуске програм- мы записываются новые данные и создаются новые графические изображения. Еще одним полезным инструментом в этой области является пакет RRDtool, также написанный Тоби Ойтикером. Это набор прикладных программ для хранения и графиче- ского отображения показателей производительности. Все ведущие инструменты для мо- ниторинга основаны на пакете RRDtool, включая нашего фаворита — программу Cacti. Программа Cacti, доступная на сайте cacti. net, обладает несколькими привлека- тельными функциональными возможностями. Во-первых, используя пакет RRDtool как основу, она собирает данные мониторинга в статических базах данных, не требующих технического обслуживания. Программа Cacti собирает столько данных, сколько требу- ется для построения желаемых графиков. Например, программа Cacti может сохранять по одной выборке каждую минуту в течение дня, каждый час в течение недели и каждую неделю в течение года. Эта схема позволяет собирать важную информацию без хранения незначительных деталей и без затрат времени на управление базами данных.
934 Часть II. Работа в сети Во-вторых, программа Cacti может записывать и изображать в графическом виде любую переменную SNMP, а также любые другие показатели производительности. Пользователь может свободно собирать любые данные, которые его интересуют. В соче- тании с агентом NET-SNMP программа Cacti генерирует данные об истории функцио- нирования практически любой системы или сетевого ресурса. На рис. 21.4 приведено несколько примеров графиков, построенных с помощью программы Cacti. Эти графики демонстрируют среднюю загрузку сервера в течение не- скольких недель, а также суточный трафик сетевого интерфейса. WWW - Load Average week 28 week 29 week 30 ’ week 31 week 32 Week 33 week 34 week 35 From 2009/08/28 22:51:02 TO 2009/08/28 22:51:02 □ 1 Minute Average Current: 0.75 □ 5 Minute Average current: 0.50 15 Minute Average Current: 0.39 H0U-S2-SW6S09-2 - Traffic - 1/1 02:00 04:00 os:oo os:oo 10:00 12:00 i4:oo 16;oo 18:oo 20:00 22:00 □ inbound Current: 3.94 M Average: 7.85 M Maximum: 12.83 M Total in; 674.89 GB outbound Current: 3.88 M Average: 6,30 M Maximum: 9.20 м Total Out: 541.56 GB Puc. 21.4. Пример графика, построенного программой Cacti Программа Cacti имеет простую конфигурацию, использующую средства веб, а так- же встроенные возможности пакета RRDtool, например небольшой объем технического обслуживания и прекрасные графические функции. Посетите домашнюю страницу па- кета RRDtool rrdtool. org и обратите внимание на ссылки на текущие версии пакетов RRDtool и Cacti, а также десятки других инструментов для мониторинга. Nagios: событийная служба мониторинга Служба Nagios специализируется на составлении отчетов об ошибках в реальном времени. Она содержит набор сценариев для обеспечения работы средств мониторинга всех форм и размеров, а также имеет широкие функциональные возможности для мони- торинга протокола SNMP. Возможно, ее главным преимуществом является модульная, легко настраиваемая система конфигурации, позволяющая записывать пользователь- ские сценарии мониторинга любых мыслимых показателей. Несмотря на то что служба Nagios не поможет определить, насколько повысилась пропускная способность сети за последний месяц, она может оповестить вас, когда ваш веб-сервер выйдет из строя.
Глава 21. Управление сетями 935 Дистрибутивный пакет Nagios содержит надстройки для слежения за типичными проблемными точками. Пользователь может создавать новые мониторы на языке Perl или даже на языке С, если чувствует в себе силы. Для уведомления об ошибках дистри- бутивный пакет может посылать электронные сообщения, генерировать веб-отчеты и использовать модемы коммутируемых линий передачи. Как и надстройки мониторинга, все они легко настраиваются. Кроме отсылки уведомлений об отключении систем в реальном времени, служба Nagios хранит архив ретроспективных данных. Она имеет несколько мощных интерфей- сов для генерации графических отчетов о трендах доступности и производительности работы сети. Многие организации используют службу Nagios для измерения степени со- ответствия показателей заданным уровням обслуживания; на рис. 21.5 показана доступ- ность DNS-сервера. State History For Service 'DNS' On Host 'nsl6' Tue Aug 29 08:04:33 2006 to Tue Sep 5 08:04:33 2006 State Bieakdowns 0k : C96.8272!) 6d 18h 40м 12s Warning : (0.0002!) Od Oh 0m 0s Unknown : (0.0002!) Od Oh Ora 0s Critical : (3.1732!) Od 5h 19m 48s Indeterminate: (0.000Z) Od Oh Om 0s Puc. 21.5. График показателя доступности сервера, построенный службой Nagios Система Nagios очень хорошо работает с сетями, состоящими менее чем из тысячи компьютеров и устройств. Ее легко настраивать и расширять. Кроме того, она имеет множество мощных функциональных возможностей, таких как резервирование, удален- ный мониторинг и эскалация уведомлений. Если вы не можете себе позволить приоб- рести коммерческое программное обеспечение для мониторинга сети, мы настоятель- но рекомендуем обратить внимание на систему Nagios. Более подробную информацию можно найти на сайте nagios.org. Совершенный пакет для мониторинга: поиски продолжаются При исследовании пакетов для управления сетями в ходе редактирования нашей книги мы обнаружили, что в этой области на протяжении последнего десятилетия происходит активная деятельность. Однако большинство пакетов для регистрации и графического отображения информации по-прежнему используют пакет RRDtool. Высококачественный стандарт наподобие редакторов vi или emacs пока не появился. Две хорошо финансируемые компании, использующие модель “открытый источник плюс” (Ground-Work Open Source и Zenoss), приступили к разработке пакетов для управ-
936 Часть и. Работа в сети ления сетями, подкрепив ее серьезной рекламой и отшлифованными интерфейсами. В этой традиционной области программного обеспечения их конкурентами стали паке- ты Munin (munin.pro jects. linpro. no) и collectd (collectd. org). Пакет Munin особенно популярен в скандинавских странах. Он основан на остро- умной архитектуре, в которой есть надстройки не только для сбора данных, но и для уведомления системы о способе их представления. Пакет collectd написан на языке С, чтобы обеспечить высокое быстродействие и мобильность программ. Он работает даже на крошечных системах, не имея проблем с производительностью и не требуя дополнительной поддержки. Во время редактирова- ния книги пакет collectd поставлялся с 70 надстройками для сбора данных. Коммерческие системы сетевого управления Сотни компаний продают программное обеспечение для управления сетями, и каж- дую неделю на рынке появляются новые продукты. Мы не будем рекомендовать кон- кретные продукты (за время подготовки книги к печати все может измениться), а по- пробуем сформулировать требования к системе управления сетью. Возможность получения различных видов данных. Для систем управления сетью важно уметь получать данные не только по протоколу SNMP. Многие программы позволяют принимать данные от большинства других сетевых служб, например выполнять SQL- запросы, обращаться к DNS и веб-серверам. Качество пользовательского интерфейса. Дорогостоящие системы обычно позво- ляют выбирать между имеющимся графическим интерфейсом или веб-интерфейсом. Программы, разработчики которых учитывают конъюнктуру рынка, поддерживают XML-шаблоны для форматирования данных. Важно, чтобы интерфейс позволял пред- ставлять информацию в наглядном и понятном виде. Стоимость. Некоторые программы имеют завышенную цену. Пакет OpenView компа- нии Hewlett-Packard является одним из наиболее дорогостоящих, но в то же время од- ним из самых распространенных. Для многих компаний престижно, что их сети управ- ляются высококачественной коммерческой системой. Если для вашей организации это не так важно, обратите внимание на бесплатное программное обеспечение, в частности программы Cacti и Nagios. Автоматическое обнаружение узлов. Многие системы обладают способностью “обна- руживать” сеть. Посылая широковещательные эхо-пакеты, выполняя SNMP-запросы, просматривая таблицы маршрутизации и обращаясь к службе DNS, они могут иденти- фицировать все компьютеры и устройства в сети. Как правило, данная функция реали- зована достаточно хорошо, но не всегда удается получить точные результаты в сложных сетях или сетях с брандмауэрами. Средства отчета. Многие программы способны посылать предупреждения по элек- тронной почте, выдавать сообщения на пейджеры и автоматически генерировать уве- домления для популярных систем обнаружения ошибок. Убедитесь в том, что выбран- ная платформа позволяет гибко настраивать систему отчетности. Никто не знает, какие устройства появятся в ближайшие годы. Возможности конфигурирования. Некоторые производители в своих разработках пошли гораздо дальше простого мониторинга и выдачи сообщений. Их продукты по- зволяют управлять конфигурацией компьютеров и устройств. Например, система Cisco Works посредством специального интерфейса разрешает пользователю не только прове- рять состояние маршрутизатора по протоколу SNMP, но и менять его конфигурацию.
Глава 21. Управление сетями 957 Поскольку данные о конфигурации устройства необходимы для глубокого анализа сете- вых проблем, мы предполагаем, что в будущем большинство программ будет располагать средствами изменения конфигурации сетевых компонентов. 21.13. Протокол NetFlow: мониторинг соединений Широко известна способность протокола SNMP регистрировать объем трафика, проходящего через интерфейс. Однако если вас интересует не только объем трафика, но и его тип и пункты назначения, протокол SNMP становится практически бесполезным. Для того чтобы выяснить дополнительные детали, можно запустить анализатор из на- бора инструментов системы UNIX, но эту возможность нельзя реализовать для конкрет- ного маршрутизатора. Для того чтобы решить эту проблему, поставщики маршрутизаторов предложили свои собственные инструменты. Самым популярным среди них стал протокол NetFlow компании Cisco. Протокол NetFlow отслеживает каждое соединение по семи ключам: источник и IP- адрес получателя, источник и номер порта назначения, протокол (TCP, UDP и т.д.), тип службы (ToS) и логический интерфейс. Эти метаданные в сочетании с дополнительной информацией, такой как количество пакетов и байтов, можно послать любой подходя- щей программе для сбора данных. Наиболее распространенными являются версии протокола NetFlow v5 и v7, которые часто объединяются, потому что они по существу одинаковы, за исключением того, что версия v7 имеет дополнительное поле (маршрутизатор источника). Версия v7 использу- ется коммутаторами Cisco Catalyst. В настоящее время все более популярной становится версия 9. Ее шаблонная природа обеспечивает высокую гибкость. Маршрутизатор NetFlow может посылать собранные метаданные соответствующему получателю, например пакету cf lowd, разработанному организацией CAIDA. Если се- тевое соединение сильно загружено, эта конфигурация порождает огромный объем дан- ных, для хранения которого необходима большая дисковая память, и анализатор, спо- собный решить поставленную задачу. В качестве такого анализатора можно использовать пакет FlowScan, разработан- ный Дэйвом Плонка (Dave Plonka). К сожалению, он до сих пор не обновлен, но по- прежнему работает хорошо. Его можно найти на сайте net. doit. wise. edu/~plonka/ FlowScan. Мониторинг данных протокола NetFlow с помощью утилит nfdump и NfSen Рассмотрим еще одну пару полезных инструментов для сбора и анализа данных про- токола NetFlow — утилиты nfdump (nfdump. source forge .net; разработана Петером Хаагом (Peter Haag)) и NfSen (nf sen. source forge. net). Коллектор (nfcapd) записы- вает данные протокола NetFlow на диск для дальнейшей обработки утилитой nfdump. Утилиты nfcapd и nfdump предназначены для версий v5/v7 и v9. Для поддержки протокола IPv6 следует использовать версию v9; версии 5 и 7 его не поддерживают. Утилита nfdump работает почти так же, как и утилита tcpdump (см. раздел 21.7). Она имеет аналогичный синтаксис фильтра, адаптированный для данных протокола NetFlow. Иокие форматы вывода позволяют настраивать внешний вид записей. Встроенные ге-
938 Часть II. Работа в сети нераторы отчетов демонстрируют N активных пользователей8 (talkers) вашей сети и другую полезную информацию. Следующий (немного сжатый) отчет утилиты nfdump показывает, какие IP-адреса и сети составляют трафик, какие порты в настоящий момент являются наиболее актив- ными и т.п. Параметры -s ip/flows запрашивают информацию о IP-адресах всех ис- точников или пунктов назначения, упорядоченных по объему потока. Параметры -п 10 ограничивают вывод десятью пунктами. linux$ nfdump -М /data/nfsen/profiles-data/live/upstream -г 2009/07/28/12/nfcapd.200907281205 -n 10 -s ip/flows Top 10 IP Addr ordered by flows: Date first seen Durat'n IP Addr Flows Pkts Bytes PPS bps bpp 2009-07-28 12:02 467.596 192.168.96.92 27873 67420 3.8 M 144 67347 58 2009-07-28 12:02 462.700 192.168.96.107 18928 43878 4.7 M 94 85522 112 2009-07-28 12:02 464.443 192.168.96.198 17321 45454 3.5 M 97 63884 81 2009-07-28 12:02 454.299 172.16.152.40 11554 29093 1.3 M 64 23996 46 2009-07-28 12:02 362.586 192.168.97.203 6839 11104 1.2 M 30 28883 117 2009-07-28 12:02 393.600 172.16.220.139 4802 12883 618384 32 12568 48 2009-07-28 12:02 452.353 192.168.96.43 4477 5144 554709 11 9810 107 2009-07-28 12:02 456.306 192.168.96.88 3416 6642 697776 14 12233 105 2009-07-28 12:02 459.732 192.168.96.108 2544 25555 3.2 M 55 58478 131 2009-07-28 12:02 466.782 192.168.96.197 2143 24103 5.3 M 51 94988 229 Summary: total flows: 98290, total bytes: 311.6 M, total packets: 759205, avg bps: 5.3 M, avg pps: 1623, avg bpp: 430 Time window: 2009-07-28 12:02:12 - 2009-07-28 12:09:59 Total flows processed: 98290, skipped: 0, Bytes read: 5111164 Sys: 0.310s flows/second: 317064.5 Wall: 0.327s flows/second: 300366.1 Поскольку данные протокола NetFlow хранятся на диске, их можно несколько раз анализировать с помощью разных наборов фильтров. Еще одна удобная функциональ- ная возможность утилиты nf dump позволяет объединять входящие и исходящие потоки в один двунаправленный поток. Утилита Nf Sen — это веб-интерфейс для данных протокола NetFlow, который до- полняет утилиту nfdump и, следовательно, сочетает графические возможности со всеми функциями утилиты nfdump. Она отображает данные трех разных категорий: потоки, пакеты и байты. Утилита NfSen не только строит графики, но и позволяет просматри- вать их, указывать на интересующие пики графика и исследовать отдельные потоки. Для уточнения внешнего вида данных можно применять любые фильтры утилиты nfdump. Сочетание удобного графического пользовательского интерфейса для просмотра данных с функциями утилиты nfdump делает программу NfSen мощным инструментом. Утилита NfSen позволяет сохранить пользовательский фильтр и настройки внешнего вида отчета в виде профиля, который легко использовать в будущем. Например, можно определить профиль, отслеживающий трафик для вашей зоны DMZ, веб-сервера или клиентской сети. Профили также делают утилиту NfSen ценным инструментом для работы групп, обе- спечивающих безопасность сети, поскольку они могут легко определять разновидность проблемы или сетевого трафика. Например, на рис. 21.6 показан отчет об исследовании атак на основе отказа в обслуживании типа “SYN flood”. 8 “Активный пользователь” — это термин протокола NetFlow, обозначающий устройство, соз- дающее сетевой трафик.
Глава 21. Управление сетями 939 Profile: SYN.flood ProflMjtfo: Тяг.ыляг, Мил мМЫ Кар: миг Start: Маг 22 ХМ - «МО К8Т ОМ: Маг 22 ХМ > 22:55 ЕЭТ Select Display. Q) (Т) (д) (V) ( » ) (~м~) t^ 200843-224745 Ud 200843-224745 Packets Traffic #Lm Scale 0 Stacked О Log Scale О Line Puc. 21.6. Профиль “SYNflood” для утилиты NfSen Исследование причин сбоя обычно проводится в течение ближайших часов и дней после инцидента, который его вызвал, но если данные протокола NetFlow были со- хранены, то можно легко создать профиль для предшествующего периода. Этот ретро- спективный анализ позволяет идентифицировать IP-адреса, вовлеченные в атаку, и от- следить другие узлы, на которые она могла повлиять. Можно также настроить утилиту NfSen так, чтобы она следила за потоком в нерабочие часы и посылала сигналы тревоги в случае возникновения определенных ситуаций. Настройка протокола NetFlow для маршрутизатора Cisco router Приступая к работе с протоколом NetFlow, необходимо сконфигурировать свое се- тевое устройство так, чтобы оно посылало данные протокола NetFlow утилите nf capd. В этом разделе мы рассмотрим конфигурацию протокола NetFlow для маршрутизатора Cisco. Экспорт данных протокола NetFlow включен для каждого интерфейса. ios# interface fastethernet 0/0 ios# ip route-cache flow Для того чтобы сообщить маршрутизатору, куда посылать данные протокола NetFlow, ВВеДите следующую команду. ios# ip flow-export nfcapd-hostname listen-port Параметры, указанные ниже, разбивают долговременные потоки на пятиминутные сегменты. Пользователь может выбрать любой сегмент длиной от 1 до 60 минут, но их Длина должна быть равной периоду ротации файлов утилиты nfdump, которая по умол- Чанию равна пяти минутам, или меньше его. ios# ip flow-export version 5 x°s# ip flow-cache timeout active 5
940 Часть II. Работа в сети В маршрутизаторе Catalyst 6500/7600, кроме обычного экспорта данных протокола NetFlow, необходимо включить параметр NDE (NetFlow Data Export). Для этого необходимо выполнить следующие команды. ios# mis flow ip interface-full ios# mis flow ipv6 interface-full ios# mis nde sender version 5 На загруженном маршрутизаторе можно предусмотреть многочисленные простои ма- леньких потоков. ios# mis aging fast time 4 threshold 2 ios# mis aging normal 32 ios# mis aging long 900 При этом обычная конфигурация протокола NetFlow все равно необходима, вклю- чая применение команд ip flow ingress или ip route-cache flow к каждому ин- терфейсу, так что потоки могут переключаться не только самим маршрутизатором, но и программным обеспечением. Для версии NetFlow v9 конфигурация может быть еще длиннее. В зависимости от версии операционной системы , пользователь может задавать свой шаблон. С появлени- ем технологии Flexible NetFlow (FNF), среда NetFlow стала еще более сложной. 21.14. Рекомендуемая литература Википедия содержит прекрасный (хотя и неполный) обзор протокола SNMP со ссылками на документы RFC. Это хорошая отправная точка. Mauro D., Schmidt К. Essential SNMP (2nd Edition) ~ Sebastopol, CA: O’Reilly Media, 2005. Simple Web. SNMP and Internet Management. — Сайт simple web. org. Могут оказаться полезными и перечисленные ниже документы RFC. Вместо назва- ний мы приводим краткое описание их содержимого, так как названия представляют собой не вполне понятный набор модных словечек и жаргона SNMP. • RFC1155 — Characteristics of the SNMP data space (data types, etc.) (Характеристики пространства имен SNMP (типы данных и т.д.)). • RFC 1156 — MIB-I definitions (description of the actual OIDs) (Определения базы MIB-I (описание идентификаторов OID)). • RFC1157 — Simple Network Management Protocol (Протокол SNMP). • RFC 1213 — MIB-II definitions (OIDs) (Определения базы MIB-II (описание иден- тификаторов OID)). • RFC3414 — User-based Security Model for SNMPv3 (Модель безопасности, опреде- ленная пользователем для протокола SNMPv3). • RFC3415 — View-based Access Control Model for SNMPv3 (Модель управления до- ступом на основе представления для протокола SNMPv3). • RFC3512 — Configuring devices with SNMP (Конфигурирование устройство в рам- ках протокола SNMP (лучшее обозрение)). • RFC3584 — Practical coexistence between different SNMP versions (Практическое со- существование разных версий протокола SNMP). • RFC3954 — Cisco Systems NetFlow Services Export Version 9.
Глава 21. Управление сетями 941 21.15. Упражнения 21.1. При поиске источника проблемы в сети, команда netstat -rn выдает показан- ные ниже результаты. В чем проблема и с помощью какой команды ее можно устранить? Destination Gateway Genmask F. 128.138.202.0 0.0.0.0 255.255.255.0 U 127.0.0.0 0.0.0.0 255.0.0.0 U 255.0.0.0 Flags MSS Window irtt Iface 40 0 0 ethO 40 0 0 lo 21.2. ★ Напишите сценарий, который будет контролировать заданную группу компью- теров и сообщать администратору по электронной почте, если какой-нибудь ком- пьютер не реагирует на эхо-запросы в течение заданного времени. Не задавайте список компьютеров, почтовый адрес и величину интервала времени в тексте сце- нария. 21.3. ★ Поэкспериментируйте с изменением сетевой маски одного из компьютеров ло- кальной сети. Продолжит ли компьютер нормально работать? Все ли компьюте- ры доступны в сети? Можно ли с других компьютеров получить доступ к нему? Поддерживается ли широковещательный режим (т.е. запросы протокола ARP и пакеты DHCP)? Объясните полученные результаты. (Необходим доступ с правами суперпользователя.) 21.4. ★ Воспользуйтесь командой traceroute для обнаружения маршрутов в своей сети. а) сколько переходов требуется сделать на пути к серверу? б) присутствуют ли маршрутизаторы между компьютерами, на которых у вас есть учетные записи? в) можно ли обнаружить узкие места в сети? г) есть ли в сети компьютеры с несколькими IP-адресами? 21.5. АА Составьте базу MIB, содержащую все переменные, которые вам как ад- министратору Linux может понадобиться запрашивать или устанавливать. Предусмотрите возможность расширения этой базы данных. 21.6. АА Воспользуйтесь утилитами wireshark или tshark для перехвата трафика перечисленных ниже протоколов. В случае протокола TCP укажите начальные и конечные пакеты. (Необходим доступ с правами суперпользователя.) a) ARP; б) эхо-запросы и эхо-ответы протокола ICMP; в) SMTP; г) FTP и FTP-DATA; Д) DNS; е) Samba; ж) SSH. 21.7. АА Настройте программу Cacti на отображение графика пакетов, посылаемых ло- кальному маршрутизатору и получаемых от него. Необходимо, чтобы агент SNMP опрашивал маршрутизатор; для этого следует узнать SNMP-имя маршрутизатора.
942 Часть II. Работа в сети 21.8. ★★ Напишите сценарий, в котором используется пакет RRDtool для слежения за сетевым трафиком аналогично команде netstat -i, и создайте веб-страницу с помощью команды rrdcgi, демонстрирующую результаты. Если вы никогда не работали с пакетом RRDtool, это упражнение, вероятно, займет несколько часов. Дерзайте! Это стоит затраченных усилий, поскольку вы поймете, чем хороши та- кие сценарии, а освоение пакета RRDtool поможет вам правильно настроить его для эффективного управления сетью.
глава 22 Безопасность Несмотря на все попытки Голливуда, защита компьютерных сетей остается тяжелым и недооцененным занятием, далеким от гламура. Дисциплина системного администрато- ра — следствие суровой необходимости; если системы UNIX и Linux обслуживают конфи- денциальные данные и управляют важными процессами, мы обязаны их защитить. Такая защита требует ресурсов: как времени работы системного администратора, так и специального оборудования. К сожалению, многие организации не вкладывают нуж- ные инвестиции в эту область, пока не произойдет несчастный случай. В ноябре 1988 года, когда Роберт Моррис-младший (Robert Morris, Jr.) выпустил в Интернет своего первого “червя”, мы впервые столкнулись с реальной опасностью все- мирного масштаба. До того момента Интернет переживал “век невинности”. Вопросы безопасности, заботившие администраторов, звучали, в основном, так: “А что, если...? . Серьезным происшествием считалась поимка пользователя, узнавшего пароль админи- стратора и прочитавшего чужую почту (часто не по злому умыслу, а просто для самоу- тверждения). “Червь” Морриса привел к потере тысяч часов рабочего времени системных адми- нистраторов, зато бдительность пользователей Интернета возросла на порядок. Все мы просто еще раз вспомнили народную мудрость: чем выше заборы, тем добрее соседи. В результате появился ряд прекрасных инструментальных средств для системных адми- нистраторов (и была основана организация, предназначенная для борьбы с сетевым вре- дительством). В настоящее время взлом систем безопасности стал распространенным явлением. Как показало совместное исследование Института компьютерных наук (CSI Computer Science Intitute) и ФБР “Computer Crime and Security Survey”1, проведенное в 2008 году, 1 Это исследование проводится каждый год, а отчет о нем публикуется на сайте gocsi. com.
944 Часть II. Работа в сети среднегодовые потери опрошенных организаций вследствие взломов систем безопас- ности составляли 234 тыс. долл. Большинство крупных организаций регистрируют по крайней мере одну попытку серьезного взлома системы безопасности в год. Решить эту проблему не так просто, как кажется. Безопасность нельзя купить в ма- газине или заказать в сервис-центре. Соответствующие коммерческие продукты и услу- ги могут быть частью предлагаемого решения для конкретной организации, но это не панацея. Достижение приемлемого уровня безопасности требует огромного терпения, постоянной бдительности, немалых знаний и упорства. Это касается не только админи- страторов, но и всех пользователей и управляющего персонала. Системный администратор несет личную ответственность за безопасность системы и степень образованности пользователей в данном вопросе. Он должен знать современные технологии защиты, быть подписчиком соответствующих групп новостей и нанимать экспертов в области компьютерной безопасности, если его знаний оказывается недо- статочно для решения возникшей проблемы. 22.1. Безопасна ли система UNIX Конечно, нет! Ни UNIX, ни Linux, ни какая-либо другая операционная система, управляющая сетью, не являются безопасными операционными системами. Для соз- дания абсолютно непробиваемой защиты придется изолировать2 компьютер от всех устройств доступа (и, возможно, поместить его в специальную комнату, стены которой не пропускают электромагнитное излучение). Кто может себе это позволить? Кое-что для повышения надежности системы, разумеется, сделать можно. Но иде- альная безопасность все же недостижима, ибо в модели безопасности Linux есть не- сколько фундаментальных изъянов, которые невозможно преодолеть. • Операционная система UNIX ориентирована, прежде всего, на удобство примене- ния, что отнюдь не предполагает естественность и простоту ее защиты. Концепция этой системы заключается в обеспечении удобного манипулирования данными в сетевой многопользовательской среде. • Программное обеспечение для системы UNIX разрабатывается большим сообще- ством программистов. Все они имеют разную квалификацию, по-разному отно- сятся к своей работе и обладают различными знаниями о строении операционной системы и ее особенностях. Поэтому даже самые современные средства зашиты, выпущенные с самыми благими намерениями, могут приводить к появлению но- вых “дыр”. • Большинство административных функций реализовано за пределами ядра, где их можно проверять и модифицировать. Хакеры имеют широкий доступ в систему. С другой стороны, исходный код этих систем (т.е. Linux, Solaris и других) доступен каждому, и тысячи людей могут проверить каждую строку этого кода на предмет нали- чия ошибок. Считается, что это приводит к существенному повышению безопасности по сравнению с закрытыми операционными системами, где доступ к коду имеет лишь небольшое число разработчиков. Многие организации не торопятся устанавливать новые версии операционной си- стемы: либо по причине сложности локализации, либо потому, что они не заключили с поставщиком договор о сопровождении системы. Даже если производитель “заткнул” 2 Появление беспроводных сетей привело к возникновению новых проблем безопасности. В данном контексте “изолировать” означает “отключить сеть”.
Глава 22. Безопасность 945 маленькую дырочку в системе защиты, на устранение “лазейки” потребуется какое-то время. Может показаться, что по мере выявления и устранения брешей безопасность опера- ционных систем будет непрерывно повышаться, но, к сожалению, это не так. Сложность системного программного обеспечения стремительно растет, хакерская деятельность все больше приобретает черты организованной преступности, компьютеры оказываются все теснее связанными посредством Интернета. Война переходит в новые измерения, и, по- хоже, победителей не будет. Запомните такую формулу: 1 Безопасность = __—--------- 1,072 х Удобство Чем безопаснее система, тем труднее пользователям работать в ней. 22.2. Слабые места в системе защиты В последующих разделах будут рассматриваться некоторые наиболее распространен- ные проблемы, связанные с безопасностью, и стандартные контрмеры, позволяющие избежать этих проблем. Но прежде чем погрузиться в детали, необходимо взглянуть на ситуацию в целом и определить основные источники неприятностей. Человеческий фактор Пользователи (и администраторы) системы часто являются ее слабейшим звеном. Даже сейчас, когда образованность людей в области безопасности повысилась, беспеч- ные пользователи легко распространяют конфиденциальную информацию. Никакая технология не может защитить сеть от неосторожных пользователей, поэтому систем- ный администратор обязан информировать пользователей о существующих угрозах, и это обстоятельство станет частью системы безопасности. Эта проблема может проявляться в разных формах. Хакеры звонят своим жертвам и представляются легальными пользователями, попавшими в трудное положение, пытаясь проникнуть в сеть. Иногда сами системные администраторы неосторожно размещают конфиденциальную информацию на открытых форумах, описывая решения сложных проблем. Физические взломы возникают, например, когда внешне легальные сотрудни- ки отдела технического обслуживания проникают в телефонный монтажный шкаф. Термином “фишинг” (phishing) называют попытку сбора информации от пользова- телей с помощью обманных электронных сообщений, мгновенных сообщений и даже сообщений SMS. От фишинга особенно трудно защититься, поскольку сообщения часто содержат информацию, которая свидетельствует о знакомстве с жертвой и создает види- мость аутентичности. Использование человеческого фактора остается мощным хакерским приемом, ко- торому трудно противостоять. Ваша стратегия обеспечения безопасности должна пред- усматривать обучение новых сотрудников. Эффективно также распространять среди сотрудников информацию о телефонных атаках, физических проблемах, фишинге и правильном выборе паролей. Может показаться, что для того, чтобы противостоять попыткам использовать чело- веческий фактор, можно попытаться самому спровоцировать такую атаку. Однако сна- чала необходимо получить разрешение от менеджера. Если у вас не будет такого разре-
946 Часть II. Работа в сел шения, такие действия будут выглядеть подозрительно. Кроме того, они могут вызвать “шпиономанию” и обиду. Многие организации считают необходимым сообщить своим пользователям, что ад- министраторы ни при каких обстоятельствах не имеют права спрашивать у них пароли ни через электронные сообщения, ни через мгновенные сообщения, ни по телефону. О любой попытке узнать пароль с помощью этих средств следует сообщать в отдел ин- формационных технологий. Ошибки в программах За много лет в программном обеспечении (включая сторонние программы, как ком- мерческие, так и бесплатные) было выявлено несметное число ошибок, связанных с безопасностью. Используя незаметные программистские просчеты или контекстные зависимости, хакерам удавалось манипулировать системой по своему усмотрению. Основной программной ошибкой, одной из самых опасных по своим последствиям,, является переполнение буфера. Для хранения информации разработчики часто выделя- ют заранее определенный объем временной памяти, который называется буфером. Если программа не следит за размерами данных и контейнера, в котором они должны хра- ниться, то память, смежная с выделенной областью, рискует оказаться перезаписанной. Умелые хакеры могут ввести тщательно скомпонованные данные так, чтобы они приве- ли к краху программы или, в худшем случае, выполнили некий заданный код. К счастью, огромное количество случаев переполнения буферов, которое наблюду лось в последние годы, научило программистов бороться с этим. Несмотря на то что переполнение буфера остается сложной проблемой, она быстро распознается и исправ- ляется, особенно в приложениях с открытым кодом. Новейшие программные системы, такие как Java и .Net, содержат механизмы, автоматически проверяющие размеры дан- ных и предотвращающие переполнение буфера (правда, не всегда). Переполнение буфера является частным случаем более широкого класса проблем,, связанных с безопасностью программного обеспечения, который называется уязвимо-? стью проверки вводимых значений (input validation vulnerability). Почти все програм- мы принимают от пользователей вводимые данные (например, аргументы командной строки или формы HTML). Если программа обрабатывает эти данные без строгой про- верки соответствующего формата и содержания, то могут возникнуть неприятности; Рассмотрим следующий простой пример. #! /usr/bin/perl # Example user input validation error open (HTMLFILE, "/var/www/html/$ARGV[0] ’’) or die "tryingn"; while(<HTMLFILE>) {print; } close HTMLFILE; Вероятно, этот код должен выводить на печать содержимое некоего HTML-файла, находящегося в каталоге /var/www/html, который по умолчанию является корневым каталогом документов для веб-сервера Apache среди серверов системы Red Hat. Этот код получает от пользователя имя файла и включает его как часть аргумента команды open. Однако злоумышленник ввел в качестве аргумента строку /et/passwd и по- лучил в качестве ответа содержимое этого файла! Как администратор может предотвратить такой тип атак? Почти никак, по крайней мере, пока не будет найдена ошибка и создана соответствующая заплатка. По этой при- чине выпуск заплаток и бюллетеней, посвященных вопросам безопасности, является
Глава 22. Безопасность 947 важной частью работы системного администратора. Большинство дистрибутивных паке- тов системы Linux включает автоматизированные утилиты для создания заплаток, такие как yum в системе Red Hat и apt-get в системе Ubuntu. Система OpenSolaris также име- ет автоматизированные (и надежные) модификации, реализуемые посредством команды pkg image-update. Воспользуйтесь преимуществами этих утилит, чтобы уберечь ваш сайт от опасностей. Ошибки конфигурации Многие компоненты программного обеспечения можно сконфигурировать в режиме полной или частичной безопасности. К сожалению, поскольку программное обеспече- ние должно быть полезным и не должно раздражать пользователей, по умолчанию чаще всего принят второй вариант. Хакеры вламываются в системы, иезуитски эксплуатируя функциональные возможности, которые предоставлены разработчиками для удобства пользователей: учетные записи без паролей, глобальный совместный доступ к жестким дискам и т.д., и т.п. Один из типичных примеров уязвимости узлов является стандартная практика, ког- да системы семейства Linux загружаются, не требуя ввода пароля загрузчика. Загрузчик операционной системы GRUB можно настроить так, чтобы он во время инсталляции запрашивал пароль, но администраторы часто отказываются от этой возможности. Это упущение открывает возможность для физической атаки системы. Однако этот же при- мер демонстрирует необходимость балансирования между безопасностью и удобством. Запрос пароля означает, что при непроизвольной перезагрузке системы (например, при сбое электропитания) администратор должен физически присутствовать при повторном включении компьютера. Одна из наиболее важных задач, связанных с обеспечением безопасности систе- мы, — убедиться в том, что, заботясь о благополучии пользователей, вы случайно не от- крыли двери для хакеров. Такие проблемы проще обнаружить и устранить, чем другие, хотя их может быть очень много и не всегда очевидно, что именно следует проверять. Сканирование портов и уязвимых мест, описанное в главе, может помочь заинтересо- ванному администратору выявить проблему еще до ее возникновения. 22.3. Ключевые аспекты безопасности В этой главе рассматривается множество аспектов компьютерной безопасности. В идеале их все нужно учитывать. Системные администраторы, вероятно, должны про- читать эту главу несколько раз. Большинство операционных систем не поставляется с уже готовой защитой. Кроме того, настройка, которая осуществляется как во время инсталляции, так и после нее, из- меняет профиль безопасности новых систем. Администраторы должны укреплять новые системы, интегрировать в локальную среду и планировать их долговременную безопас- ную эксплуатацию. Когда к вам придет проверка, вы должны доказать, что следовали стандартной мето- дологии, особенно если эта методология соответствует общепринятым рекомендациям и передовым достижениям в вашей области промышленности. Для защиты новых систем мы используем технологическую карту. Системный адми- нистратор применяет стандартные меры по укреплению безопасности системы, а ад- министратор по вопросам безопасности проверяет, чтобы эти меры были приняты пра- вильно, и ведет системный журнал.
948 Часть II. Работа в сети Программные "заплаты" Оснащение операционной системы вновь разработанными программными “заплата- ми” является первейшей обязанностью системного администратора. Большинство си- стем конфигурируется так, чтобы иметь связь с репозиторием поставщика. В этом слу- чае установка программной “заплаты” сводится всего лишь к выполнению нескольких команд. В крупных сетях могут существовать локальные репозитории, являющиеся зер- калами репозитория поставщика. При установке программных “заплат” следует учитывать следующее. • Нужно составить расписание инсталляции программных “заплат” и строго его придерживаться. При составлении такого расписания необходимо учитывать его влияние на пользователей. Обычно достаточно выполнять ежемесячные обновле- ния; регулярность важнее срочности. Нельзя сосредоточиваться только на защите от вредоносных программ и игнорировать другие обновления. • Необходимо разработать план изменений, который учитывал бы влияние каждого набора “заплат”, предусматривал соответствующие этапы тестирования после ин- сталляции системы и описывал возможности отказа от внесенных обновлений при возникновении проблем. Этот план следует обсудить со всеми заинтересованными сторонами. • Необходимо понимать, какие заплаты подходят к данному окружению. Системные администраторы должны подписываться на специальные списки рассылки и бло- ки по вопросам безопасности, создаваемые поставщиками, а также принимать участие в работе форумов по вопросам безопасности, таких как Bugtraq. Ненужные службы Большинство систем поставляется с несколькими службами, которые запускаются по умолчанию. Отключите (и по возможности удалите) все ненужные службы, особенно если они реализованы в виде сетевых демонов. Для того чтобы обнаружить выполняе- мые службы, можно использовать команду netstat. Рассмотрим частичные результаты работы этой команды в системе Solaris. solaris$ netstat -an | grep LISTEN 111 * * 0 0 49152 0 LISTEN 32771 * * 0 0 49152 0 LISTEN 32772 * * 0 0 49152 0 LISTEN 22 * * 0 0 49152 0 LISTEN 4045 * * 0 0 49152 0 LISTEN Для обнаружения служб, использующих неизвестный порт, существует несколько приемов. В большинстве операционных систем эту задачу можно решить с помощью команд Isof или fuser. В системе Linux эти команды могут распознать идентификатор PID процесса, использующего данный порт. ubuntu$ sudo fuser 22/top 22/tcp: 2454 8387 ubuntu$ sudo Isof -i:22 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 2454 root 3u IPv4 5730 TCP * :ssh(LISTEN) sshd 2454 root 4u IPv6 5732 TCP * :ssh(LISTEN)
Глава 22. Безопасность 949 Выяснив идентификатор PID, с помощью команды ps можно идентифицировать конкретный процесс. Если данная служба не нужна, остановите ее и убедитесь, что она не будет заново стартовать во время загрузки системы. К сожалению, доступность команд Isof и fuser зависит от системы, и их реали- зации сильно отличаются друг от друга. Многим версиям этих инструментов недостает поддержки сетевых сокетов. Если утилиты Isof и fuser недоступны (или бесполезны), можно либо проверить “хорошо известные” порты для служб в файле /etc/service, либо запустить утилиту netstat без параметра -п, чтобы она выполнила эту проверку за вас. Некоторым сетевым протоколам присущ риск, которому подвергается безопасность системы. В этом случае она остается почти все время уязвимой. Например, программы FTP, Telnet и BSD “г” (rep, rlogin и rsh) используют ненадежную аутентификацию и ненадежные методы передачи данных. Они должны быть отключены во всех системах и заменены более безопасными программами, например программой SSH. Удаленная регистрация событий 03 Протокол syslog описан в главе 11. Механизм syslog направляет регистрационную информацию в файлы, списки поль- зователей и другие узлы сети. Попробуйте настроить узел, отвечающий за безопасность, так, чтобы он действовал как центральная регистрационная машина, анализирующая полученные события и выполняющая соответствующие действия. Единый централизо- ванный регистратор событий может получать сообщения от разных устройств и преду- преждать администраторов о важных событиях. Удаленная регистрация также предот- вращает перезапись или очистку регистрационных файлов во взломанных системах. Большинство систем поставляется сконфигурированными так, что механизм syslog включен по умолчанию, но для настройки удаленной регистрации необходимо выпол- нить дополнительное конфигурирование. Резервные копии Регулярное резервное копирование является важной частью системы безопасности любой сети. Оно входит в так называемую триаду ЦРУ и относится к категории “доступ- ность” (см. раздел 22.15). Убедитесь, что все части системы регулярно копируются и что эта информация хранится за пределами сайта. Если произойдет серьезный инцидент, связанный с безопасностью сети, вы сможете воспользоваться “надежным” источником информации и восстановить работу. Резервное копирование само по себе также может создавать угрозу безопасности. Украденная коллекция магнитных лент может уничтожить всю систему безопасности. Для хранения магнитных лент используйте огнеупорные сейфы, которые могут противо- стоять взлому, и применяйте шифрование. Рассматривая возможность заключения кон- тракта на хранение информации, попросите разрешения совершить экскурсию и лично убедиться в надежности хранилища. 03 Резервное копирование подробно описывается в главе 10. Вирусы и черви Системы UNIX и Linux имеют иммунитет от вирусов. Существует всего несколько вирусов (большинство из них носит чисто академический характер), которые могут за-
950 Часть IL Работа в сети разить системы UNIX и Linux, но ни один из них не способен нанести серьезный урон, в отличие от среды Windows, где это стало частым явлением. Тем не менее этот факт не снижает озабоченности поставщиков антивирусных программ — разумеется, если вы покупаете их продукт по специальной цене. Точная причина отсутствия вредоносных программ неясна. Некоторые утверждают, что система UNIX просто занимает слишком незначительную долю рынка настольных систем и поэтому не интересует авторов вирусов. Другие настаивают на том, что среда с контролем доступа, существующая в системе UNIX, ограничивает размер урона от само- распространяющихся червей или вирусов. Последний аргумент заслуживает внимания. Поскольку система UNIX ограничивает доступ исполняемых модулей на файловом уровне, непривилегированные пользовате- ли не могут инфицировать остальную среду. Если код вируса был запущен не из корня, его вред будет значительно ограничен. Следовательно, не нужно использовать корневую учетную запись для повседневной деятельности. Ш Более подробная информация о сканировании содержимого электронных сообщений приведена в главе 20. Как ни странно, одна из причин внедрения антивирусного программного обеспече- ния на серверах UNIX — стремление защитить работающие под управлением Windows компьютеры, существующие в вашей сети, от Windows-ориентированных вирусов. Почтовый сервер может сканировать входящую электронную почту на вирусы, а файло- вый сервер в поисках инфекции может сканировать общие файлы. Однако это решение должно быть дополнительным по отношению к антивирусной защите настольных си- стем, а не основным. Программа ClamAV, написанная Томашем Коймом (Tomasz Kojm), — это популяр- ная свободно распространяемая антивирусная программа для систем UNIX и Linux. Она широко используется в качестве полноценного антивирусного обеспечения, которое хранит сигнатуры тысяч вирусов. Новейшую версию этой программы можно загрузить с сайта clamav .net. Троянские программы Это программы, которые не выглядят программами. Примером является программа turkey, распространявшаяся в сети Usenet много лет тому назад. Эта программа утверж- дала, что способна нарисовать индейку на экране компьютера, но на самом деле удаляла файлы из рабочего каталога. Фрагменты троянских программ встречаются в основных пакетах программного обе- спечения до сих пор. Авторы программ sendmail, tcpdump, OpenSSH и nterBase даже опубликовали советы, касающиеся вредоносных программ, внедренных в их программ- ное обеспечение. Эти троянские программы обычно внедряют вредоносный код, ко- торый позволяет хакерам проникать в систему. К счастью, большинство поставщиков регулярно исправляют свои ошибки и публикуют соответствующие рекомендации раз в одну-две недели. Следите за списками рассылок по вопросам безопасности, посвящен- ными всем сетевым программным пакетам, которые выполняются на ваших узлах. Несмотря на большое количество проблем, возникших в области безопасности си- стем UNIX за последние несколько лет, следует отметить малое количество инцидентов, связанных с троянскими программами. В основном, это объясняется скоростью ком- муникаций через Интернет. Очевидные проблемы с безопасностью быстро выявляются и широко обсуждаются. Вредоносные пакеты не задерживаются надолго на хорошо из- вестных интернет-серверах.
Глава 22. Безопасность 951 Вы можете быть уверены, что любое выявленное вредоносное программное обе- спечение вызовет в Интернете широкое волнение. Поищите в системе Google имя про- граммного пакета, прежде чем его инсталлировать, и посмотрите, нет ли на первой стра- нице неприятных сообщений о нем. Руткиты Умелые хакеры пытаются скрывать свои следы и избегать разоблачения. Часто они рассчитывают продолжить использование вашей системы для нелегального распростра- нения программного обеспечения, зондирования других сетей или запуска атаки против других сетей. Для того чтобы оставаться незамеченными, они часто используют “рутки- ты” (“rootkits”). Троянские программы, внедренные в файлы, созданные фирмой Sony, используют возможности руткитов, чтобы скрыть себя от пользователей. Руткиты — это программы и заплатки, скрывающие важную системную информа- цию, например процесс, диск или сетевую активность. Они имеют много обличий и разную степень сложности — от простых замен приложения (как взломанные версии утилит 1s и ps) до модулей ядра, которые практически невозможно выявить. Для эффективного мониторинга системы и выявления внедренных руткитов суще- ствует специальное программное обеспечение, например OSSEC. Кроме того, разра- ботаны сценарии распознавания руткитов (такие, как chkrootkit, chkrootkit.org), сканирующие систему в поисках известных руткитов. Несмотря на существование программ, позволяющих системным администраторам удалять руткиты из взломанных систем, время, которое они вынуждены затрачивать на очистку систем, можно было бы сэкономить, сохранив данные, переформатировав диск и начав работу с нуля. Большинство современных руткитов знают о существовании про- грамм для их удаления и пытаются оказывать сопротивление. Фильтрация пакетов Если система подключается к сети, где есть выход в Интернет, необходимо, чтобы между этой системой и внешним миром стоял брандмауэр либо маршрутизатор, филь- трующий пакеты. В качестве альтернативы можно включить фильтрацию пакетов в ядре (описывается в разделе 22.11). Какой бы ни была реализация, фильтр должен пропускать через себя трафик только важнейших служб, выполняющих “полезную” работу в сети. Пароли Все мы любим простые правила. Вот одно из них: у каждой учетной записи должен быть пароль, который трудно угадать. Но даже самые лучшие пароли нельзя передавать через Интернет в текстовом виде. Поэтому, если в системе допускается удаленная реги- страция, следует применять SSH или какой-нибудь другой механизм аутентификации (см. раздел 22.10). Бдительность Для того чтобы быть уверенным в безопасности системы, следите за ее состоянием, сетевыми соединениями, таблицей процессов. Делать это нужно регулярно (желательно каждый день). Проблема всегда начинается с малого, а затем нарастает, как снежный ком, так что чем раньше будет обнаружена аномалия, тем меньшим окажется ущерб.
952 Часть II. Работа в сети Общие принципы защиты Эффективная система безопасности должна базироваться на здравом смысле. Она во многом напоминает борьбу с мышами в доме. Вот ряд правил, которые при этом следует соблюдать. Этими же правилами (в компьютерном варианте) можно с успехом руководствовать- ся при организации защиты Linux-систем. Вот как они звучат применительно к Linux. • Не оставляйте без присмотра файлы, которые могут представлять интерес для ха- керов и не в меру любопытных сослуживцев. Коммерческие тайны, персональные досье, бухгалтерские ведомости, результаты выборов и так далее — за всем этим нужен присмотр. Гораздо надежнее зашифровать данные, чем просто пытаться предотвратить к ним несанкционированный доступ. • В организации должен существовать порядок работы с конфиденциальной инфор- мацией. Некоторые рекомендации по этому поводу даны в главе 32. • Старайтесь, чтобы в системе не было мест, где хакеры могли бы закрепиться. Хакеры часто вламываются в одну систему, а затем используют ее как базу для взлома других систем. Иногда хакеры используют вашу сеть для сокрытия своих следов во время атаки реальной цели. Уязвимые службы с открытым доступом, ка- талоги, доступные для записи по протоколу FTP в анонимном режиме, групповые учетные записи, учетные записи с плохо подобранными паролями — вот основные уязвимые места. • Устанавливайте ловушки для обнаружения вторжений или попыток вторжения. Такие инструменты, как OSSEC, Bro, Snort и John the Ripper (описаны в разде- ле 22.8), помогут предупредить возможные проблемы. • Следите за отчетами, которые генерируются этими утилитами. Незначительная проблема, проигнорированная в отчете, к моменту получения следующего отчета может перерасти в катастрофу. • Учитесь защищать системы своими силами. Применяйте традиционные техноло- гии, обучайте пользователей, руководствуйтесь, в конце концов, здравым смыс- лом. В случае необходимости приглашайте специалистов со стороны, но при этом тщательно контролируйте их работу. • Постоянно следите за тем, не появились ли отклонения от нормального хода ра- боты системы. Обращайте внимание на все необычное, например на непонятные журнальные сообщения или изменение характера использования какой-либо учет- ной записи (резкий рост активности, работа в необычное время, использование учетной записи во время отпуска ее владельца). 22.4. Пароли и учетные записи пользователей Очень часто источником неприятностей является плохое управление паролями. По умолчанию в файлах /etc/passwd и /etc/shadow содержатся данные о том, кто может входить в систему и что он при этом имеет право в ней делать. Эти файлы представля- ют собой передовую линию защиты системы от захватчиков. Их нужно вести с особой тщательностью, стараясь не допускать ошибок и не загромождать файлы устаревшими данными. QJ Подробнее о файле passwd см. раздел 7.1.
Глава 22. Безопасность 953 Система UNIX позволяет пользователям выбирать свои собственные пароли, но, не- смотря на то, что это удобно, из-за этого возникает множество проблем, связанных с бе- зопасностью. Когда вы даете пользователям их регистрационные имена, должны также инструктировать их о правилах выбора паролей. Рекомендуется выбирать пароли не ме- нее чем из восьми символов, среди которых должны быть цифры, знаки препинания, а также прописные и строчные буквы. Бессмысленные сочетания символов, слогов, пер- вые буквы слов легко запоминаемой фразы — вот самые лучшие пароли. При этом легко запоминаемая фраза не должна быть одной из широко распространенных. Лучше при- думать свою собственную. Совет по выбору фраз приводился в разделе 4.3. Важно постоянно проверять (желательно ежедневно), чтобы каждая регистрацион- ная запись имела пароль. Записи в файле /etc/shadow, описывающие псевдопользо- вателей, таких как “демон”, которые владеют файлами, но никогда не регистрируются, должны быть отмечены звездочками или знаком восклицания в поле зашифрованного пароля. Эти символы не совпадают ни с одним паролем и тем самым предотвращают использование данной учетной записи. В организациях, использующих централизованную схему аутентификации, такую как LDAP или Active Directory, используется та же логика. Они требуют сложных паролей и блокируют учетные записи после нескольких неудачных попыток регистрации. Устаревание паролей В большинстве систем, использующих теневые пароли, можно реализовать меха- низм так называемого устаревания паролей, при котором пользователей заставляют пе- риодически менять пароли. На первый взгляд, это хорошая идея, однако ее практическая реализация влечет за собой определенные проблемы. Не всякому пользователю по душе периодически менять пароль, поскольку это сопряжено с запоминанием нового пароля. Обычно для пароля выбирается простое слово, которое легко вводится и запоминается, и когда приходит время замены, многие пользователи, не желая себя утруждать, опять берут предыдущий пароль. Таким образом, дискредитируется сама идея. Модули РАМ могут по- мочь выбрать сильные пароли, чтобы избежать описанной выше ситуации (раздел 22.5). JB В системе Linux процессом устаревания паролей управляет программа chage. ГЛ С ее помощью администраторы могут задавать минимальное и максимальное количество изменений пароля, дату истечения срока действия пароля, коли- чество дней до наступления даты истечения срока действия пароля, когда сле- дует заблаговременно предупредить пользователя, количество дней простоя, в течение которых учетные записи остаются заблокированными, и другие параметры. Следующая команда задает минимальное количество дней между изменениями пароля равным 2, максимальное количество изменений пароля равным 90, дату истечения срока действия пароля равной 31 июля 2010 года, а также то, что пользователя следует предупредить об истечении срока действия пароля за 14 дней. $ sudo chage -m 2 -М 90 -Е 2010-07-31 -W 14 ben Ш Более подробно процедура настройки параметров учетных записей описана в главе 7. Другие системы иначе реализуют механизм устаревания паролей, обычно не так де- тально. В системе Solaris параметры механизма устаревания паролей задаются в файле /etc/password. Устареванием паролей в системах семейства HP-UX управляет утилита smc, а в системе AIX оно настраивается в файле /etc/security/user.
954 Часть II. Работа в сети Групповые и совместно используемые учетные записи Опасно, если учетная запись используется несколькими людьми. Групповые реги- страционные имена (например, guest или demo) представляют собой удобную лазейку для хакеров, поэтому они запрещены во многих сетях федеральными законами, такими как HIPAA. Не допускайте этого в своей сети. Однако технические средства не могут предотвратить совместное использование пользователями паролей, поэтому в этом во- просе лучше всего вести разъяснительную работу. Пользовательские оболочки Теоретически можно установить в качестве оболочки для пользовательской учетной записи любую программу, включая пользовательский сценарий. На практике использо- вание оболочек, отличающихся от стандартных, таких как bash и tcsh, весьма опас- но. Еще опаснее беспарольные регистрационные имена, оболочкой которых является сценарий. Если у вас возникнет соблазн создать такое регистрационное имя, примените вместо него пару ключей SSH без пароля. Привилегированные учетные записи Единственная отличительная черта пользователя root состоит в том, что его иден- тификатор равен 0. Поскольку в файле /etc/passwd может быть несколько записей с таким идентификатором, существует и несколько способов входа в систему в качестве суперпользователя. * Один из способов, который хакеры, получив доступ к интерпретатору команд су- перпользователя, широко применяют для открытия “черного хода”, — редактирование: файла /etc/passwd. Поскольку такие команды, как who и w, работают с регистрацион- ным именем, хранящимся в файле /var/run/utmp, а не с идентификатором владельца' регистрационного интерпретатора, они не в состоянии разоблачить хакера, который выи глядит как рядовой пользователь, хотя на самом деле зарегистрирован в системе в каче-; стве суперпользователя. Не допускайте удаленную регистрацию суперпользователя даже через стан- soiaris дартную корневую учетную запись. Для того чтобы это запретить, следует с помощью оболочки OpenSSH установить в файле /etc/ssh/sshd_config параметр конфигурации PermitRootLogin равным No. Благодаря программе sudo (см. раздел 4.3) необходимость регистрироваться в каче- стве суперпользователя, даже с системной консоли, возникает редко. 22.5. Модули РАМ: украшение или ЧУДО АУТЕНТИФИКАЦИИ Аббревиатура РАМ означает “подключаемые модули аутентификации” (Pluggable Authentication Modules — РАМ). Эти модули освобождают программистов от необ- ходимости выполнять рутинные операции для реализации систем аутентификации. Концепция и термин были придуманы в компании Sun Microsystems (которая в настоя- щее время является частью компании Oracle) и описаны в 1996 году в статье, авторами которой были Самар (Samar) и Лаи (Lai) из компании SunSoft.
Глава 22. Безопасность 955 В далеком прошлом команды вроде login включали встроенный код аутентифика- ции, который предлагал пользователю ввести пароль, сравнил его с зашифрованной за- писью из файла /etc/shadow (на самом деле в настоящее время этот файл называется /etc/passwd) и делал вывод об их совпадении или несовпадении. Разумеется, другие команды (например, passwd) содержали такой же код. Не имея доступа к открытому коду, было невозможно изменить метод аутентификации, поэтому администраторы име- ли мало возможностей для управления настройками паролей (например, задавать пра- вила, описывающие правильные пароли) или не имели их вообще. Появление модулей РАМ в корне изменило положение дел. Модули РАМ поместили системные процедуры аутентификации в совместно ис- пользуемую библиотеку, которая может вызывать программу login и другие программы. Выделение функций аутентификации в отдельную подсистему облегчает интеграцию новых методов аутентификации и шифрования в компьютерную систему. Например, многофакторная аутентификация может поддерживаться без внесения изменений в про- граммы login и passwd. Для системного администратора выбор правильного уровня безопасности для аутен- тификации стал простой задачей конфигурирования. Программисты также полумили выгоду: они больше не обязаны писать сложный код для аутентификации и, что еще более важно, их системы аутентификации правильно реализуются с первой попытки. Модули РАМ могут аутентифицировать все виды деятельности: регистрацию пользова- телей, другие формы доступа к системе, использование защищенных веб-сайтов и даже конфигурирование приложений. Системная поддержка для моделей РАМ Все рассмотренные нами операционные системы содержат модули РАМ. Конфигурационная информация хранится в каталоге /etc/pam.d (Linux) или в файле /etc/pam.conf (Solaris, HP-UX и AIX). Форматы файлов конфигурации, в основном, совпадают, но в системах семейства UNIX вся информация хранится в одном файле, а в системах семейства Linux каждая служба или команда, использующая модули РАМ, имеет отдельный файл. С этой точки зрения поддержка модулей РАМ является практически универсальной, но если вы используете другой вариант системы UNIX и хотите проверить, использует ли ваша система модули РАМ, можно выполнить команду Idd /bin/login и увидеть, ссылаются ли исполняемые модули на совместно используемую библиотеку моделей РАМ libpam. Конфигурация модулей РАМ Файлы конфигурации модулей РАМ содержат по одной строке, каждая из которых представляет собой имя модуля РАМ, используемого в системе. Общий формат этих файлов имеет следующий вид. [служба] тип_модуля управляющий_флаг путь_к_модулю [аргументы] Поля разделяются пробелами. Системы Linux не используют поле служба или, точнее, они помещают каждую служ- бу в отдельный файл конфигурации и имя этого файла играет роль параметра служба, принятого в системе UNIX. Параметр служба может называть контекст аутентифика- ции, к которому относится строка конфигурации (например, login для обычных реги-
956 Часть II. Работа в сети страционных имен пользователей), или содержать ключевое слово other для установки системных параметров по умолчанию. Рассмотрим иллюстративный фрагмент конфигурации из системы Solaris; все поля путь_к_модулю являются относительными к каталогу /usr/lib/security. # login service login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 Отдельные модули РАМ имеют более тонкие настройки, чем просто “аутентифици- ровать пользователя”, поэтому в файле конфигурации модулей РАМ для каждой службы и каждого типа модуля может содержаться несколько строк. Серия строк для заданной службы и типа модуля называется стеком. Порядок, в котором модули перечисляются в файле конфигурации, имеет значение. Например, модуль, предлагающий пользователю ввести пароль, должен предшествовать модулю, проверяющему корректность пароля. Один модуль может передавать результаты своей работы другому модулю, изменяя параметры окружения или переменные РАМ. Поле тип_модуля может иметь значения auth, account, session или password. Модуль типа auth идентифицирует пользователя и может предоставлять ему право груп- пового доступа. Модуль типа account выполняет действия, не связанные с аутентифика- цией, например предоставляет доступ в зависимости от времени суток, ограничивает ко- личество одновременно работающих пользователей или количество портов, на которых может происходить регистрация. (Например, можно использовать модуль типа account для ограничения регистрации суперпользователя на консоли.) Действия, которые не- обходимо выполнить до или после того, как пользователь получит доступ к требуемой службе, например монтирование файловой системы, реализуются модулем типа session. Наконец, модуль типа password используется, когда пользователь должен ввести аутен- тификационную информацию (например, пароль или кодовое словосочетание). Поле управляющий_флаг определяет, как должны взаимодействовать модули, обра- зующие стек (табл. 22.1). Таблица 22.1. Управляющие флаги модулей РАМ Флаг Остановка в случае ошиб —ДЗДЛШ X iu 'J J 'i.i.hh < 1' i—i к 1 ки в случае успеха КоммеитаРии binding® Нет Да Похож на флаг sufficient, но только ошибка приводит к отказу всего стека include® - Включает другой файл конфигурации в данную точку стека optional Нет Нет Имеет значение, только если модуль единственный required Нет Нет Ошибка приводит со временем к отказу всего стека requisite Да Нет Так же как и required, но отказ стека наступает мгновенно sufficient Нет Да Неудачное название; см. пояснения в тексте Значение include используется только в системе Linux, значение binding — только в системе Solaris.
Глава 22. Безопасность 957 Если бы модуль РАМ мог просто возвращать код ошибки как только первый модуль в стеке потерпит неудачу, то система этих флагов была бы проще. К сожалению, систе- ма разработана так, что большинство модулей имеет шанс на выполнение независимо от успеха или сбоя других модулей, находящихся с ними на одном и том же уровне, и этот факт имеет определенные тонкости, связанные с потоком управления. (Это было сделано для того, чтобы хакеры не могли понять, какие модули РАМ в стеке вызывают отказ.) Модули required должны следовать один за другим; отказ одного из них гаранти- рует, что весь стек со временем даст сбой. Однако отказ модуля, помеченного флагом required, не приводит к немедленному сбою стека. Если вы хотите, чтобы сбой насту- пал моментально, вместо флага required используйте флаг requisite. Успех модуля типа sufficient немедленно прекращает работу стека. Однако окон- чательный результат работы стека не обязательно должен быть успешным, поскольку модуль типа sufficient не может компенсировать ошибку выполненного ранее мо- дуля типа required. Если ранее выполненный модуль типа required выдал ошибку, успешно выполненный модуль типа sufficient прекращает работу стека и возвращает ошибку в качестве итогового результата. Флаг binding в системе Solaris действует точно так же, как флаг sufficient, но отказ модуля типа binding гарантирует общий сбой стека. В противоположность этому, отказ модуля типа sufficient интерпретируется как ошибка модуля типа optional: он не влияет на окончательный результат, если стек не состоит из одного модуля. Дело ясное, что дело темное, не так ли? Для того чтобы еще больше усложнить си- туацию, в системе Linux предусмотрена параллельная система альтернативных управля- ющих флагов, которые теоретически можно использовать вместо перечисленных выше межсистемных стандартов. В общем, для того чтобы объяснить, что означают управ- ляющие флаги, необходимо несколько страниц. Однако мы не будем углубляться в эту тему, потому что конфигурации модулей РАМ довольно стереотипны. Вряд ли вы ста- нете писать что-то совершенно оригинальное. Мы упомянули некоторые детали только для того, чтобы дать вам представление о том, что имена управляющих флагов не соот- ветствуют их назначению. Если вы планируете изменить настройки безопасности вашей системы, сначала убедитесь, что вы правильно понимаете смысл параметров, и дважды перепроверьте это. (Конфигурации модулей РАМ не изменяют ежедневно. Как долго вы можете помнить разницу между флагами requisite и required?) Для простоты рассмотрим следующий фрагмент конфигурации из файла pam. conf в системе Solaris. # login service login auth requisite login auth required login auth required login auth required login auth required pam_authtok_get.so.1 pam_dhkeys.so.1 pam_unix_cred.so.1 pam_unix_auth.so.1 pam_dial_auth.so.1 Рассмотрим отдельные модули. Библиотечный модуль pam authtok get предлагает пользователю ввести свое имя (если оно еще не было введено) и пароль, а также хранить эти значения в токене аутен- тификации с именем PAM_AUTHTOK. Модуль pam dhkeys используется для аутентифи- кации вызова RPC (remote procedure call — удаленный вызов процедуры) для систем NIS или NIS+ и ищет ключи Диффи-Хеллмана, т.е. имя.
958 Часть II. Работа в сети Модуль pam unix cred устанавливает мандаты для аутентифицированного пользо- вателя, а модуль pam_unix_auth выполняет фактическую аутентификацию, проверяя, является ли значение, хранящееся в переменной PAM AUTHTOK, правильным паролем пользователя. В заключение, модуль pam dial auth аутентифицирует пользователя для доступа по коммутируемым телефонным линиям к содержанию файлов /etc/dialups и/etc/d_passwd. Один и тот же модуль может встречаться в разных конфигурационных файлах с раз- ными значениями тип_модуля. Это прекрасно; если реализации нескольких типов име- ют значительный объем общего кода, они часто объединяются в одну библиотеку. Подробный пример конфигурации системы Linux Д Система Linux хранит каждый набор строк конфигурации модулей РАМ, ссы- лающихся на одну и ту же службу, в отдельном файле, имя которого совпадает с именем службы. В остальном формат прежний, за исключением того, что поле служба больше не нужно. Например, ниже приведен файл /etc/pam.d/login из системы SUSE с включенны- ми файлами, которые раскрыты, чтобы сделать пример более связным. auth requisite pam_nologin.so auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_ securetty.so auth required pam_env.so auth required pam_unix2.so account required pam_unix2.so password requisite pam_pwcheck.so nullok cracklib password required pam_unix2.so use_authtok nullok session required pam_loginuid.so session required pam_limits.so session required pam_unix2.so session optional pam_umask.so session required pam_lastlog.so nowtmp session optional pam_mail.so standard session optional pam_ck_connector.so Стек auth содержит несколько модулей. В первой строке модуль pam nologin проверяет существование файла /etc/nologin. Если он существует, модуль немед- ленно прекращает регистрацию, если пользователь не является корневым. Модуль pam securetty гарантирует, что суперпользователь может регистрироваться только с терминалов, перечисленных в файле /etc/secure tty. В этой строке используется альтернативный синтаксис системы Linux, описанный на справочной странице рат. conf. В этом случае функционирование модуля аналогично реакции на флаг required. Модуль pam env устанавливает переменные окружения в файле /etc/security/pam_ env.conf, и наконец, модуль pam_unix2 проверяет мандаты пользователя, выполняя стандартную аутентификацию системы UNIX. Если один из этих модулей дает сбой, стек auth возвращает ошибку. Стек account содержит только модуль pam_unix2, который в данном контексте оценивает корректность самой учетной записи. Например, он возвращает ошибку, если учетная запись просрочена или пароль должен быть изменен. В последнем случае мо- дуль принимает от пользователя новый пароль и передает его модулям password.
Глава 22. Безопасность 959 Строка pam pwcheck проверяет устойчивость предложенных паролей, вызывая би- блиотеку cracklib. Она возвращает ошибку, если новый пароль не соответствует уста- новленным требованиям. Однако она допускает пустые пароли, потому что установлен флаг nullok. Строка pam_unix2 обновляет действующий пароль. В заключение модули session выполняют несколько рутинных процедур. Модуль pam loginuid устанавливает атрибут процесса ядра loginuid равным идентификатору пользователя, модуль pam limits считывает лимиты использования ресурсов из файла /etc/security/limits. conf и устанавливает соответствующие параметры процесса, чтобы ввести их в действие. Модуль pam_unix2 регистрирует доступ пользователя в си- стему, а модуль pam unmask устанавливает режим создания начального файла. Модуль pam lastlog выводит время последней регистрации пользователя, а модуль pam mail — сообщение, если пользователь получил новое электронное сообщение. В заклкн чение, модуль pam ck connector уведомляет демон ConsoleKit (системный демон, управляющий сеансами регистрации) о новой регистрации. В результате пользователь был успешно аутентифицирован, и модули РАМ вернули управление программе login. 22.6. Программы с установленным битом SETUID Программы, выполняемые с установленным битом SETUID (Set User ID — сме- на идентификатора пользователя), запускаются пользователем, который считается их владельцем. Например, программа passwd должна запускаться с привилегиями супер- пользователя, чтобы иметь возможность модифицировать файл /etc/shadow, когда пользователи изменят свои пароли. Основная информация об этой функциональной возможности изложена в разделе 4.1. Программы, выполняемые с установленным битом SETUID, особенно имеющие привилегии суперпользователя, являются источником проблем для безопасности систе- мы. Тем не менее программы этой категории, поставляемые вместе с операционными системами, являются безопасными, по крайней мере теоретически. Однако огрехи в за- щите обнаруживались в прошлом и, несомненно, будут обнаруживаться в будущем. Самый надежный способ уменьшения количества проблем, вызванных сменой иден- тификатора, — сведение к минимуму числа программ с установленным битом SETUID. Подумайте дважды, прежде чем инсталлировать такую программу, и вообще избегайте устанавливать этот бит для своих программ. Выполнение программ с установленными битами SETUID и SETGID (Set Group ID — смена идентификатора группы) можно отключать в отдельных файловых систе- мах с помощью опции nosuid команды mount. Это целесообразно делать в файловых системах, содержащих начальные каталоги пользователей или смонтированные из нена- дежных административных доменов. Полезно периодически сканировать диски на предмет выявления новых программ с установленным битом SETUID. Хакер, взломавший систему, вполне может создать собственный командный SETUID-интерпретатор, который облегчит ему последующий вход в систему. Ряд программ, описанных в разделе 22.7, позволяет обнаруживать такие файлы, но вполне подойдет и простая команда find. /usr/bin/find I -user root -perm -4000 -print | /bin/mail -s "Setuid root files" netadmin В данном случае пользователю netadmin по электронной почте посылается спи- сок всех файлов, принадлежащих пользователю root и имеющих установленный бит
960 Часть II. Работа в сети SETUID. (На практике может потребоваться более конкретная информация об искомых файловых системах.) 22.7. Эффективное использование команды chroot Системный вызов chroot ограничивает процесс конкретной библиотекой. Он за- крывает доступ к файлам, расположенным за пределами каталога, и тем самым смягчает последствия, которые могут возникнуть при его взломе. Команда chroot — это простая оболочка описанного выше системного вызова. Кроме того, некоторые демоны, представляющие угрозу для безопасности системы, имеют встроенную поддержку команды chroot и должны запускаться только в этом ре- жиме, который устанавливается в их конфигурационных файлах. Эксперты по вопросам безопасности иногда косо смотрят на использование коман- ды chroot в этом контексте, поскольку они считают, что неправильное использование или неверное понимание этой команды может создать у системных администраторов иллюзию безопасности. Они жалуются, что некоторые системные администраторы ис- пользуют команду chroot, чтобы избавить себя от хлопот, связанных с использованием других инструментов для обеспечения безопасности, например регулярного обновления программного обеспечения и пристального мониторинга. Эти утверждения не точны, и в любом случае их нельзя считать приговором команде chroot. Аналогичные высказывания звучали и в адрес брандмауэров, но лишь немногие эксперты осмелятся посоветовать удалить фильтры пакетов из вашей сети. При условии правильного использования в сочетании с другими средствами безопасности команда chroot достойна включения в арсенал инструментов для защиты сети (даже если это не входило в планы ее разработчиков). Перечислим сценарии, в которых целесообразно использовать команду chroot. • Допустим, что вы хотите запустить демона без привилегий суперпользователя, на- пример Apache или BIND в ограниченном поддереве файловой системы. Если де- мон окажется взломанным, то хакер будет ограничен поддеревом, поскольку дру- гих уязвимых мест нет и эскалация привилегий не произойдет. • Предположим, что вы хотите ограничить удаленных пользователей конкретной совокупностью файлов и команд. Однако команда chroot может защитить вас в указанных сценариях только при вы- полнении следующих условий. • Все процессы в окружении chroot запускаются без привилегий суперпользова- теля. Процессы, которые запускаются с привилегиями суперпользователя, всегда способны взломать окружение chroot. • Вы не запускаете программы, выполняемые с установленным битом setuid, с правами суперпользователя. • Окружение chroot соответствует современному уровню и является минимальным, т.е. содержит только исполняемые программы, библиотеки и конфигурационные файлы, необходимые для выполнения поставленной задачи. В эпоху совместно используемых библиотек и зависимостей между процессами соз- дание описанного выше окружения chroot становится непростой задачей. Некоторые сценарии, которые могут облегчить ее решение, содержатся в пакете JailKit (olivier. sessink.nl/jailkit).
Глава 22. Безопасность 961 22.8. Инструментальные средства защиты Для решения задач, упоминавшихся в предыдущих разделах, можно использовать свободно распространяемые программы. Ниже будут рассмотрены наиболее интересные из них. Команда nmap: сканирование сетевых портов Эта команда является сканером сетевых портов. Ее основное назначение — проверка указанных компьютеров на предмет того, какие TCP- и UDP-порты на них прослушива- ются серверными программами3. За большинством сетевых служб закреплены “извест- ные” порты, поэтому такая информация позволяет узнать, какие программы выполня- ются на компьютере. Запуск команды nmap — отличный способ узнать, как выглядит система в глазах того, кто пытается ее взломать. В качестве примера приведем отчет, выданный этой командой на самом обычном, относительно незащищенном компьютере. ubuntu$ nmap -sT ubuntu.booklab.atrust.com Starting Nmap 4.20 ( http://insecure.org ) at 2009-11-01 12:31 MST Interesting ports on ubuntu.booklab.atrust.com (192.168.20.25): Not shown: 1691 closed ports PORT STATE SERVICE 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 3306/tcp open mysql Nmap finished: 1 IP address (1 host up) scanned in 0.186 seconds Аргумент -sT сообщает команде nmap о необходимости подключиться к каждому TCP-порту на указанном узле4. Как только соединение устанавливается, команда nmap немедленно отключается, что це очень корректно, зато безболезненно для правильно написанного сетевого сервера. Как следует из примера, на узле ubuntu выполняются две службы, являющихся тра- диционными источниками проблем для безопасности системы: portmap (rpcbind) и почтовый сервер (smtp). Это наиболее вероятные места для атаки хакеров. Колонка STATE (состояние) содержит запись open (открыт) для портов, с которыми связаны серверы, closed (закрыт) для портов, с которыми не связан ни один сервер, за- пись unfiltered (нефильтруемый) для портов, пребывающих в неизвестном состоянии, и запись filtered (фильтруемый) для портов, доступ к которым невозможен из-за на- личия брандмауэра. Чаще всего встречаются нефильтруемые порты. Они отображаются только при АСК-сканировании. Вот, например, результат запроса к более защищенному коммерческому веб-серверу secure .booklab. atrust. com. 3 Как объяснялось в главе 14, порт — это нумерованный канал взаимодействия. IP-адрес иден- тифицирует весь компьютер, а комбинация IP-адреса и номера порта определяет конкретный сер- вер или сетевое соединение. 4 На самом деле по умолчанию проверяются только привилегированные (их номера меньше 1024) и “известные” порты. С помощью опции -р можно явно задать диапазон сканирования.
962 Часть II. Работа в сети ubuntu$ nmap -sT secure.booklab.atrust.com Starting Nmap 4.20 ( http://insecure.org ) at 2009-11-01 12:42 MST Interesting ports on secure.booklab.atrust.com (192.168.20.35): Not shown: 1691 closed ports PORT STATE SERVICE 25/tcp open smtp 80/tcp open http Nmap finished: 1 IP address (1 host up) scanned in 0.143 seconds В данном случае очевидно, что компьютер сконфигурирован на обработку электрон- ной почты по протоколу SMTP и работу с сервером HTTP. Брандмауэр блокирует доступ к остальным портам. Помимо стандартного опроса TCP- и UDP-портов, команда nmap способна про- верять порты “по-хакерски”, не устанавливая с ними реального соединения. В боль- шинстве случаев посылаются пакеты, которые похожи на пакеты из уже имеющегося TCP-соединения (это не квитирующие пакеты), а затем проверяются полученные в от- вет диагностические пакеты. Таким способом можно обойти брандмауэр или программу мониторинга сети, которая контролирует появление сканеров портов. Если в вашей ор- ганизации имеется брандмауэр (см. раздел 22.11), не поленитесь проверить его в разных режимах сканирования. Команда nmap обладает магической способностью угадывать, какая операционная система установлена на удаленном узле. Это делается путем анализа деталей реализации стека TCP/IP. Чтобы проверить работу команды nmap в этом режиме, воспользуйтесь опцией -О, например. ubuntu$ sudo nmap -sV -О secure.booklab.atrust.com Starting Nmap 4.20 ( http://insecure.org ) at 2009-11- 1 12:44 MST Interesting ports on secure.booklab.atrust.com (192.168.20.35) : Not shown: 1691 closed ports PORT STATE SERVICE VERSION 25/tcp open smtp Postfix smtpd 80/tcp open http lighttpd 1.4.13 Device type: general purpose Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.6.16 - 2.6.24 Nmap finished: 1 IP address (1 host up) scanned in 8.095 seconds Эта возможность может оказаться весьма полезной при анализе состояния локаль- ной сети. К сожалению, она же является рабочим инструментом хакеров, которые могут определить тип атаки на основании известных слабых мест конкретных операционных систем или серверов. Не забывайте также, что большинство администраторов не приветствуют попыток сканирования сети и выяснения ее слабых мест, какими бы благородными ни были мо- тивы. Никогда не запускайте команду nmap в чужой сети без разрешения сетевого адми- нистратора. Nessus: сетевой сканер следующего поколения В 1998 году Рено Дерезон (Renaud Deraison) выпустил интересный пакет Nessus, в котором реализуются многие функциональные возможности сканера. Он использует бо- лее 31000 надстроек для проверки локальных и удаленных дефектов. Несмотря на то что
Глава 22. Безопасность 963 эта программа имеет закрытый код и является коммерческим продуктом, она свободно распространяется и для нее регулярно появляются новые надстройки. Это наиболее ши- роко распространенный и полный из доступных сканеров. Программа Nessus — это сетевой сканер, который ничему не доверяет. Вместо того чтобы предполагать, к примеру, будто все веб-серверы работают через порт 80, он ищет веб-серверы на любом порту, а затем анализирует их слабые места. Программа не дове- ряет даже номеру версии, о котором сообщает сам сервер, проверяя все известные сла- бые места, чтобы понять, насколько уязвим сервер. Для первого запуска программы Nessus требуется потратить немало усилий (необхо- димо установить много пакетов, которые не входят в стандартный дистрибутив), но ко- нечный результат того стоит. Система Nessus состоит из клиента и сервера. Сервер игра- ет роль базы данных, а клиент отвечает за графический пользовательский интерфейс. Серверы и клиенты могут работать на платформах UNIX или Windows. Одним из главных преимуществ программы Nessus является ее модульная структу- ра, позволяющая сторонним разработчикам добавлять собственные модули проверки. Благодаря активности сообщества ее пользователей, эта программа сможет быть полез- ной долгое время. John the Ripper: средство для выявления слабых паролей Один из способов пресечь использование плохих паролей заключается в том^ что- бы самостоятельно взломать пароль и заставить пользователя выбрать другой. John the Ripper — это сложная программа, разработанная компанией Solar Designer, которая ре- ализует разные алгоритмы взлома паролей в виде единого инструмента. Она заменила программу crack, которая была описана в предыдущем издании книги. Несмотря на то что большинство систем использует файл теневых паролей, чтобы скрыть зашифрованные пароли от публики, целесообразно проверять, что пароли поль- зователей являются устойчивыми ко взлому.5 Знание пароля пользователя может ока- заться полезным, потому что люди предпочитают все время использовать один и тот же пароль. Единственный пароль может обеспечить доступ к другой системе, зашифровать файлы, хранящиеся в рабочем каталоге, и открыть доступ к финансовым счетам в сети веб. (Не стоит и говорить, что использовать пароль таким способом очень глупо. Однако никто не хочет запоминать десять разных паролей.) Несмотря на свою внутреннюю сложность, программа John the Ripper весьма проста в использовании. Достаточно просто нацелить программу john на файл, подлежащий взлому, чаще всего /etc/shadow, и произойдет чудо. $ sudo ./john /etc/shadow Loaded 25 password hashes with 25 different salts (FreeBSD MD5 [32/32]) password (jsmith) badpass (tjones) В этом примере из теневого файла были считаны 25 уникальных паролей. После взлома пароля программа John выводит его на экран и сохраняет в файл john.pot. Этот вывод содержит пароль в левом столбце и регистрационное имя в скобках в правом столбце. Для просмотра паролей после завершения работы программы john, следует вы- полнить ту же самую команду с аргументом -show. 5 Особенно это относится к паролям системных администраторов, имеющих привилегии sudo.
964 Часть II. Работа в сети На момент написания книги самой новой версией программы John the Ripper была версия 1.7.З.4. Она доступна на сайте openwall. сот/john. Поскольку вывод програм- мы содержит взломанные файлы, его следует тщательно охранять и удалять сразу после проверки, убедившись, что пароли пользователей являются небезопасными. Как и для большинства других методов мониторинга безопасности, перед взломом паролей с помощью программы John the Ripper необходимо получить одобрение руко- водства. Команда hosts_access: управление доступом к узлу Брандмауэры сети являются первой линией защиты от доступа со стороны неавто- ризованных узлов, однако они не должны быть единственным средством защиты. Два файла, /etc/hosts.allow и /etc/hosts.deny, также являются оболочками прото- кола TCP, которые могут ограничивать доступ к службам для генерирования сетевых запросов. Файл hosts .allow содержит список узлов, которым разрешено соединять- ся с конкретной службой, а файл hosts. deny ограничивает доступ. Однако эти фай- лы управляют доступом только к службам, которые знают о существовании команды hosts_access, например к службам, управляемым демонами inetd, xinetd, sshd и некоторыми конфигурациями программы sendmail. В большинстве ситуаций разумно установить ограничения и разрешить доступ только к службам, играющим важную роль для указанных узлов. Мы рекомендуем отключить доступ, установленный по умолчанию в файле hosts. deny, с помощью одной строки. ALL:ALL Затем вы можете разрешить доступ в конкретных ситуациях с помощью файла hosts .allow. Следующая конфигурация разрешает доступ к системе SSH с узлов сети 192.168/16, а также к агенту sendmail отовсюду. sshd: 192.168.0.0/255.255.0.0 sendmail: ALL Формат записи в файле имеет вид служба: узел или служба: сеть. Соединения, кото- рым отказано в доступе, перечисляются в журнале syslog. Соединения, которым не был разрешен доступ к службе, немедленно закрываются. Большинство дистрибутивных пакетов системы Linux по умолчанию содержит файлы hosts. allow и hosts. deny, но, как правило, они пустые. Другие рассмотренные нами операционные системы после инсталляции предлагают использовать оболочки TCP. Bro: программная система для распознавания вторжения в сеть Открытая система Вго предназначена для распознавания вторжений в сеть (network intrusion detection system — NIDS). Она выполняет мониторинг сети и следит за подо- зрительной активностью. Эта система была написана Верном Паксоном (Vem Paxson) и доступна на сайте bro-ids. org. Система Bro проверяет весь трафик, поступающий в сеть и исходящий из нее. Она может функционировать в пассивном режиме, генерируя предупреждения о подозритель- ной активности, или в активном режиме, в котором она пресекает враждебные действия. Оба режима, скорее всего, потребуют внесения изменений в конфигурацию вашей сети. В отличие от других систем NIDS, система Вго отслеживает потоки трафика, а не просто сопоставляет образцы внутри отдельных пакетов. Это значит, что система Вго
Глава 22. Безопасность 965 может распознавать подозрительную активность, основываясь на информации о том, кто с кем говорит, даже не сравнивая никаких строк или шаблонов. Например, система Вго может решать следующие задачи. • Распознавать системы, использующие “мостики” (“stepping stones”), определяя корреляцию между входящим и исходящим трафиками. • Распознавать сервер, имеющий лазейку, инсталлированную для неожиданных ис- ходящих соединений сразу после входящего соединения. • Распознавать протоколы, выполняемые на нестандартных портах. • Сообщать о правильно угаданных паролях (и игнорировать неправильные догадки). Некоторые из этих функциональных возможностей требуют существенных систем- ных ресурсов, но система Вго имеет поддержку кластеризации, облегчающую управле- ние группами машин, распознающих вторжение. Система Вго имеет сложный язык конфигурации, требующий значительного опыта кодирования. К сожалению, в системе нет конфигурации, заданной по умолчанию, ко- торую было бы легко инсталлировать новичкам. Большинство сайтов требует умеренно- го уровня настройки. Система до некоторой степени поддерживается Группой сетевых исследований Международного института компьютерных наук (Networking Research Group of the International Computer Science Institute (ICSI)), но в большей степени она поддерживает- ся сообществом ее пользователей. Если вы ищете готовую коммерческую систему NIDS, то, вероятно, будете разочарованы системой Вго. Однако она может делать то, что не доступно коммерческим системам NIDS, и может служить дополнением или заменой коммерческого продукта. Snort: популярная программная система для распознавания проникновения в сеть Открытая система Snort предназначена для предотвращения и распознавания не- санкционированного проникновения в сеть; написана Марти Решем (Marty Roesch) и в настоящее время поддерживается коммерческой компанией Sourcefire (snort. org). Она де-факто стала стандартом для кустарных систем NIDS, а также основной для многих коммерческих реализаций систем NIDS с “управляемыми услугами”. Сама по себе система Snort распространяется как пакет с открытым кодом. Однако компания Sourcefire взимает плату за подписку на доступ к новейшим правилам рас- познавания. Большое количество платформ, созданных сторонними производителями, включают в себя или экспортируют систему Snort, причем некоторые из этих проектов являют- ся программами с открытым кодом. Ярким примером является проект Aanval (aanval. com), собирающий данные от многочисленных датчиков системы Snort на веб-консоль. Система Snort перехватывает пакеты из кабеля и сравнивает их с наборами правил, которые называются сигнатурами. Когда система Snort распознает событие, которое представляет интерес, она может предупредить системного администратора или устано- вить контакт с сетевым устройством и, помимо прочего, заблокировать нежелательный трафик. Несмотря на то что система Вго намного мощнее, система Snort намного проще и легче конфигурируется, благодаря чему является удачным выбором для стартовой плат- формы NIDS.
966 Часть II. Работа в сети OSSEC: система для распознавания вторжения в сеть на уровне узла Мучались ли вы бессонницей из-за опасения, что ваша система безопасности сети будет взломана? Не предполагали ли вы, что ваш рассерженный сотрудник может ин- сталлировать вредоносную программу в ваших системах? Если на один из этих вопросов вы ответили положительно, то подумайте над инсталляцией системы для распознавания проникновения на уровне узла (HIDS), такой как OSSEC. Система OSSEC — это свободное программное обеспечение, доступное в виде от- крытого кода по лицензии GNU (General Public License). Ее коммерческая поддерж- ка обеспечивается компанией Third Brigade (недавно приобретенной компанией Trend Micro). Система OSSEC имеет версии для систем Linux, Solaris, HP-UX, AIX и Windows. Она обеспечивает следующие функциональные возможности. • Распознавание руткитов. • Проверка целостности файловой системы. • Анализ регистрационных файлов. • Выдача сигналов по расписанию. • Активные реакции. Система OSSEC работает в заданной операционной системе и отслеживает ее актив- ность. Она может выдавать сигналы или предпринимать действия, предусмотренные на- бором правил, которые устанавливает пользователь. Например, система OSSEC может выполнять мониторинг операционных систем с целью выявления добавления неавто- ризованных файлов и посылать по электронной почте уведомления, похожие на при- веденное ниже. Subject: OSSEC Notification - courtesy - Alert level 7 Date: Fri, 15 Jan 2010 14:53:04 -0700 From: OSSEC HIDS <ossecm@courtesy.atrust.com> To: <courtesy-admin@atrust.com> OSSEC HIDS Notification. 2010 Jan 15 14:52:52 Received From: courtesy->syscheck Rule: 554 fired (level 7) -> "File added to the system." Portion of the log(s): New file ’/courtesy/httpd/barkingseal.com/html/wp-content/uploads/2010/01/hbird.jpg’ added to the file system. —END OF NOTIFICATION Таким образом, система OSSEC работает круглосуточно, следя за операционной си- стемой. Мы рекомендуем запускать эту систему на каждой операционной системе, одно- временно изменяя политику управления (см. главу 32). Основные принципы системы OSSEC Система OSSEC состоит из двух основных компонентов: менеджера (сервера) и аген- тов (клиентов). В сети нужен один менеджер, который необходимо инсталлировать пер- вым. Менеджер хранит базу данных для проверки целостности файловой системы, реги-
Глава 22. Безопасность 967 страционные журналы, события, декодеры, основные варианты конфигурации, а также записи об аудите системы для всей сети. Менеджер может соединяться с любым агентом OSSEC, независимо от его операционной системы. Менеджер также может отслеживать работу определенных устройств, которые не имеют специального агента OSSEC. Агенты работают в системах, которые подвергаются мониторингу, и сообщают ин- формацию менеджеру. Они имеют маленькую зону обслуживания и оперируют неболь- шим объемом привилегий. Большую часть конфигурации агент получает от менеджера. Соединение между сервером и агентом зашифровано и аутентифицировано. Для каждо- го агента менеджер должен создать отдельный ключ аутентификации. Система OSSEC классифицирует серьезность сигналов по уровням от 0 до 15; число 15 соответствует высшему уровню опасности. Инсталляция системы OSSEC Система OSSEC еще не стала частью основных дистрибутивных пакетов операци- онных систем UNIX и Linux, даже в качестве вспомогательного пакета. По этой причи- не вы должны загрузить пакет исходного кода в веб-браузер или инструмент, такой как wget, а затем собрать программу. $ wget http://ossec.net/files/ossec-hids-latest.tar.gz $ tar -zxvf ossec-hids-latest.tar .gz $ cd ossec-hids-* $ sudo ./install.sh Сценарий инсталляции спрашивает, какой язык вы предпочитаете (например, “еп” для английского) и какой тип инсталляции хотите выполнить — серверный, агент- ский или локальный. Если вы инсталлируете систему OSSEC в отдельной, персонально управляемой операционной системе, следует выбрать локальный тип инсталляции. В противном случае сначала следует выполнить инсталляцию сервера OSSEC в предназна- ченной для этого операционной системе, а затем инсталляцию агента во всех остальных системах, которые будут предметом мониторинга. Сценарий инсталляции тоже задает несколько дополнительных вопросов, например, по какому адресу посылать уведомле- ния и какие модули мониторинга следует подключить. После завершения инсталляции запустите chctcm^OSSEC с помощью следующей команды. server$ sudo /var/ossec/bin/ossec-control start Затем зарегистрируйте каждого агента у менеджера. Находясь на сервере, выполните следующую команду. server$ sudo /var/ossec/bin/manage__agents Вы увидите меню, которое будет выглядеть примерно так. **************************************** * OSSEC HIDS v2.3 Agent manager. * The following options are available: * *************************************** (A) dd an agent (A) . (E)xtract key for an agent (E) . (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q:
968 Часть II. Работа в сети Выберите пункт А, чтобы добавить агента, а затем наберите имя и IP-адрес этого агента. Затем выберите пункт Е и извлеките ключ агента. Вот как это выглядит. Available agents: ID: 001, Name: linuxclientl, IP: 192.168.74.3 Provide the ID of the agent to extract the key (or ’q' to quit) : 001 Agent key information for *001’ is: MDAyIGxpbnV4Y2xpZW50MSAxOTIuMTY4LjcOLjMgZ jk4YjMyYzlkMjg5MWJlMT В заключение зарегистрируйте в системе агента и выполните команду manage_ agents. agent $ sudo /var/ossec/bin/manage_agents Находясь на компьютере клиента, вы увидите меню с другими пунктами. **************************************** * OSSEC HIDS v2.3 Agent manager. * The following options are available: **************************************** (I)mport key from the server (I) . (Q)uit. Choose your action: I or Q: Выберите пункт I, а затем вырежьте и вставьте ключ, который был извлечен ранее. После того как добавите агента, вы должны заново запустить сервер OSSEC. Повторите процесс генерирования ключа, его извлечение и инсталляцию каждого агента, с кото- рым хотите установить связь. Конфигурация системы OSSEC После инсталляции и запуска системы OSSEC вы захотите настроить ее так, чтобы она выдавала достаточный объем информации, но не слишком большой. Большая часть конфигурации хранится на сервере в файле /var/ossec/etc/ossec.conf. Это XML- подобный файл, который подробно прокомментирован и вполне понятен, хотя и содер- жит десятки параметров. Чаще всего необходимо конфигурировать список файлов, которые следует игнори- ровать при проверке целостности (наличия изменений) файла. Например, если у вас есть приложение, записывающее свой регистрационный файл в каталог /var/log/ customapp.log, то вы можете добавить следующую строку в раздел <syscheck> этого файла. <syscheck> <ignore>/var/log/customapp.log</ignore> </syscheck> После того как внесете эти изменения и заново запустите сервер OSSEC, система OSSEC прекратит выдавать сообщения при каждом изменении регистрационного фай- ла. Многие параметры конфигурации системы OSSEC описаны в файле ossec.net/ main/manual/configuration-options. Для того чтобы запустить и настроить систему HIDS, требуется затратить много вре- мени и усилий. Но через несколько недель вы отфильтруете шум и система станет вы- давать ценную информацию об изменяющихся условиях в вашем окружении.
Глава 22. Безопасность 969 22.9. Мандатное управление доступом Мандатное управление доступом (Mandatory Access Control — МАС) представляет собой альтернативу традиционному механизму управления доступом в системе UNIX, который передает управление всеми разрешениями в руки администратора по безопас- ности. В противоположность стандартной модели, описанной в главах 4 и 6, система МАС не позволяет пользователям модифицировать никакие разрешения, даже для своих собственных объектов. Стратегия безопасности в системе МАС управляет доступом в соответствии со степе- нью конфиденциальности управляемого ресурса. Пользователям присваиваются опреде- ленные уровни доступа, образующие структурную иерархию. Пользователи могут читать и записывать информацию, относящуюся к их уровню доступа или более низкому^ ио не имеют доступа к объектам, имеющим более высокую степень конфиденциальности. Например, пользователь с уровнем доступа “секретный” не может читать документы, классифицированные как совершенно секретные. Хорошо реализованная стратегия системы МАС основывается на принципе мини- мальных привилегий (т.е. разрешает доступ только при необходимости), точно так как правильно спроектированные брандмауэры пропускают только знакомые службы и кли- ентов. Система МАС может предотвратить взлом системы через уязвимое программное обеспечение (например, из-за переполнения буфера), ограничивая область их влияния лишь несколькими конкретными ресурсами, необходимыми для данной программы. >*• Очевидно, что для реализации механизма МАС в операционных системах UNIX h Linux необходимо внести изменения в ядро. В рассмотренных нами системах семейства UNIX (Solaris, HP-UX и AIX) версии с внедренным механизмом МАС предоставляют- ся за дополнительную плату. Эти версии называются Solaris Trusted Extensions (бывшая Trusted Solaris), HP-UX Security Cotttamment и Trusted AIX соответственно. Если вы не работаете с секр^ЙйЙ^Г правительственными документами, то вряд ли вам понадобятся эти версии. Система Linux с усиленной системой безопасности (SELinux) Система SELinux (Security-enhanced Linux) — это вариант системы Linux, в котором реализован механизм МАС. Несмотря на то что в некоторых дистрибутивных пакетах эта система стала основной, она стала печально известной из-за трудностей в управле- нии и ошибок. Приведем безымянную цитату из страницы Википедии, посвященной ранней версии системы SELinux, в которой отражено отчаяние многих системных адми- нистраторов. “Как ни странно, несмотря на то, что система SELinux разрабатывалась для того, чтобы облегчать создание стратегий индивидуального управления доступом, специально приспособленных к способам и правилам хранения данных в организациях, вспомогатель- ные программные средства настолько скудны и неудобны, что поставщики преимуще- ственно ограничиваются консультациями, которые обычно принимают вид нарастаю- щих модификаций стандартных стратегий безопасности.” Несмотря на сложность в управлении системой SELinux, ее адаптация постепенно увеличивается, особенно в правительственных учреждениях, в которых приняты стро- гие правила безопасности. В рассмотренных нами примерах дистрибутивных пакетов
970 Часть II. Работа в сети системы Linux самую совершенную модель SELinux имел пакет Red Hat Enterprise Linux. Механизм SELinux доступен как вспомогательный пакет для систем Ubuntu и SUSE. Разработка стратегии — сложная тема. Для защиты нового демона, например, не- обходимо тщательно пронумеровать все файлы, каталоги и другие объекты, к которым другие объекты имеют доступ. Для сложного программного обеспечения, такого как sendmail или Apache httpd, эта задача может оказаться довольно сложной. По крайней мере одна компания предлагает трехдневный тренинг по разработке стратегий. К счастью, многие общие стратегии доступны в Интернете, и большинство дис- трибутивных пакетов имеет разумные решения, принятые по умолчанию. Их легко ин- сталлировать и конфигурировать для конкретной среды. Полноценный редактор стра- тегий, предназначенный для их легкой реализации, можно найти на сайте seedit. sourceforge.net. Механизм SELinux встроен в систему Red Hat Enterprise Linux начиная с версии 4. По умолчанию инсталляция системы RHEL включает готовую защиту SELinux. Конфигурацией системы SELinux управляет файл /etc/selinux/conf ig. Интерес представляют следующие строки. SELINUX=enforcing SELINUXTYPE=targeted Первая строка имеет три возможных значения: enforcing, permissive или disabled. Значение enforcing гарантирует применение загружаемых правил и за- прещает их нарушение. Значение permissive разрешает нарушать правила, но реги- стрирует нарушения в журнале с помощью системы syslog, что оказывается полезным для отладки. Значение disabled вообще отключает механизм SELinux. Параметр SELINUXTYPE означает тип применяемой стратегии. Система Red Hat реализует две стратегии: targeted, которая определяет дополнительный уровень безопасности для демонов, которых защищает система Red Hat6, и strict, которая защищает всю систе- му. Несмотря на доступность стратегии strict, в системе Red Hat она не поддержива- ется; ее ограничения настолько сильны, что системе их трудно применять. Стратегия targeted предоставляет защиту для важных сетевых демонов без влияния на систему в целом, по крайней мере, теоретически. Однако даже стратегия targeted не является идеальной. Если у вас есть проблемы со вновь установленным программным обеспече- нием, поищите в файле /var/log/messages сообщения об ошибках системы SELinux. Система SUSE использует реализацию механизма МАС, выполненную компа- • нией Novell и получившую имя АррАгтог. Однако в версии 11.1 система SUSE также включает основные функциональные возможности механизма SELinux. ©Система Ubuntu по умолчанию поставляется с механизмом АррАгтог. Пакеты SELinux для систем Ubuntu поддерживаются Расселом Кокером (Russell Coker), бывшим сотрудником компании Red Hat, разработавшим стратегии targeted и strict. 22.10. Системы криптографической защиты Большинство широко используемых в системах UNIX сетевых протоколов было соз- дано до широкого распространения Интернета и до изобретения современных крипто- графических систем. При проектировании многих протоколов о безопасности просто не 6 Защищаемыми демонами являются httpd, dhcpd, mailman, named, portmap, nscd, ntpd, mysqld, postgres, squid, winbindd и ypbind.
Глава 22. Безопасность 971 думали. Там же, где она якобы учитывалась, реализованные механизмы дискредитиру- ются передачей паролей в незашифрованном виде или отсутствием проверки на надеж- ность компьютера или порта, от которого поступил пакет. Сегодня эти протоколы эксплуатируются в кишащих хакерами крупных корпора- тивных локальных сетях и Интернете, где весь трафик открыт для прослушивания. Более того, любой может вмешаться в сетевой диалог. Как удостовериться в личности собеседника? Криптография — это решение многих проблем. Давным-давно существовала возмож- ность шифровать сообщения так, чтобы даже в случае перехвата их нельзя было прочи- тать, но это лишь одно из чудес криптографии. Такие разработки, как шифрование с открытым ключом и защитное хеширование, сделали возможным построение криптоси- стем, удовлетворяющих самым строгим требованиям. Тем, кого интересуют вопросы криптографии, рекомендуем обратиться к документу “RSA Labs’ Frequently Asked Questions about Today’s Cryptography” (rsa. com/rsalabs). Несмотря на название, это объемистый трактат, который можно загрузить в формате PDF. Этот документ не обновлялся с 2000 года, но большая часть его содержания все еще не потеряла актуальности. Кроме того, историю криптографии можно подробно изучить по книге Стивена Леви (Stephen Levy) Crypto. Kerberos: унифицированный подход к сетевой безопасности Система Kerberos, разработанная в Массачусетсском технологическом институте (MIT), ориентирована на решение задач, связанных с обеспечением безопасности ком- пьютерных сетей. Kerberos — это система аутентификации, предоставляющая “гаран- тию” того, что пользователи и служебные программы действительно являются теми, за кого себя выдают. Никаких дополнительных проверок и шифрования передаваемых данных не предусмотрено. Используя алгоритм DES, Kerberos создает вложенные наборы идентификаторов, на- зываемых билетами или мандатами. Мандаты передаются по сети с целью подтверждения личности пользователя и предоставления ему доступа к сетевым службам. В каждой орга- низации, где используется Kerberos, должен выделяться хотя бы один физически защищен* ный компьютер (называемый сервером аутентификации) для выполнения демона Kerberos. Этот демон выдает мандаты пользователям и служебным программам, требующим аутенти- фикации, на основании предъявляемых ими “удостоверений”, в частности паролей. По сути, Kerberos улучшает традиционную схему парольной защиты всего двумя спо- собами: пароли никогда не передаются по сети в незашифрованном виде и пользователи избавляются от необходимости многократно вводить пароли. Сообщество пользователей Kerberos может похвастаться одним из самых толко- вых и оригинальных документов, посвященных криптосистемам, — “Designing ап Authentication System: a Dialogue in Four Scene” (Проектирование системы аутентифика- ции: диалог в четырех актах) Билла Брайанта (Bill Bryant). Его будет интересно почитать любому, кто интересуется темой криптографии. Документ можно найти по адресу: web.mit.edu/kerberos/www/dialogue.html Лучше использовать Kerberos, чем вообще отказаться от средств защиты. К сожале- нию, Kerberos нельзя назвать полностью безопасной системой, а ее инсталляция и за- пуск — не самое приятное занятие. В то же время она не заменяет собой ни одну из про- грамм, описанных в данной главе.
972 Часть II. Работа в сети К сожалению, (хотя, возможно, вполне предсказуемо) система Kerberos, распростра- няемая как часть службы Active Directory системы Windows, использует запатентованные, недокументированные расширения. Как следствие, она плохо взаимодействует с тра- диционной версией системы. К счастью, модуль winbind позволяет системам UNIX и Linux взаимодействовать с версией системы Kerberos для службы Active Directory. Более подробную информацию о настройке системы Kerberos можно найти в разделе 30.9. PGP: высокая конфиденциальность Пакет PGP (Pretty Good Privacy), написанный Филом Циммерманом (Phil Zimmer- mann), содержит криптографические утилиты, ориентированные, в основном, на безо- пасность систем электронной почты. Он используется для шифрования данных, генери- рования сигнатур и проверки источников происхождения файлов и сообщений. 03 Более подробная информация о защите электронной почты приведена в разделе 20.6. Пакет PGP имеет интересную историю, которая включает в себя судебные иски, кри- минальные расследования и приватизацию фрагментов исходного пакета PGP. В настоя- щее время формат файла и протоколы PGP стандартизованы организацией IETF под име- нем OpenPGP, и уже существует несколько реализаций предложенного стандарта. Проект GNU обеспечивает превосходную, свободную и широко применяемую реализацию под на- званием GnuPG, которую можно найти по адресу gnupg. org. Для ясности, мы будем назы- вать эту систему просто PGP, даже если ее отдельные реализации имеют другие названия. Вероятно, PGP — наиболее популярная криптографическая программа. К сожале- нию, для того чтобы работать с ней в системе UNIX/Linux, нужно быть специалистом в области криптографии. Пакет PGP может оказаться полезным, но мы не рекоменду- ем заставлять пользователей работать с ним из-за нетривиальности процесса обучения. Гораздо удобнее использовать Windows-версию PGP, чем команду рдр с ее 52 различны- ми режимами работы. Программные пакеты, распространяемые через Интернет, часто содержат файл сиг- натуры PGP, подтверждающий их подлинность и целостность. Но проверить эти сигна- туры не так-то легко людям, не являющимся фанатиками PGP. Не потому, что процесс проверки сложен, а потому, что при использовании PGP истинная безопасность дости- гается только путем создания персональной коллекции открытых ключей тех людей, ко- торые были проверены напрямую. Загрузка дистрибутива с открытым ключом и файлом сигнатуры безопасна примерно в той же степени, что и загрузка одного дистрибутива. Некоторые почтовые клиенты, такие как Mozilla Thunderbird, имеют надстройки, обеспечивающие простой графический пользовательский интерфейс для зашифро- ванных входящих и исходящих сообщений. Программа Enigmail для клиента Mozilla Thunderbird может даже выполнять поиск баз открытых ключей в сети, если ключ для вашего получателя еще не был загеристрирован. Подробности можно найти на сайте enigmail.mozdev.org. SSH: безопасная оболочка Система SSH (Secure Shell) является безопасной заменой утилит rlogin, гср и telnet. Она использует криптографическую аутентификацию для подтверждения личности пользователя и шифрует любые соединения между двумя компьютерами. Протокол, используемый системой SSH, разрабатывался для противодействия ряду воз- можных атак. Он уже подробно описан в документах RFC4250—4256 и предложен орга- низацией IETFb качестве стандарта.
Глава 22. Безопасность 973 Пакет SSH трансформировался из свободно распространяемой открытой системы (SSH1) в коммерческий продукт с немного иным (более надежным) протоколом (SSH2). К счастью, сообщество разработчиков открытых систем взяло ситуацию под контроль и выпустило пакет OpenSSH (поддерживаемый операционной системой OpenBSD), в ко- тором реализованы оба протокола. Основными компонентами пакета SSH являются серверный демон sshd и две ути- литы пользовательского уровня: ssh предназначена для удаленной регистрации и scp — для копирования файлов. Среди остальных компонентов отметим команду ssh-keygen, генерирующую пары открытых ключей, и несколько утилит, необходимых для поддерж- ки безопасных серверов X Windows. Демон sshd способен аутентифицировать пользователей различными способами. Выбор остается за администратором. • Метод А. Если имя удаленного компьютера, с которого регистрируется пользо- ватель, указано в файле */. rhosts, ~/. shosts, /etc/hosts. equiv или /etc/ shosts. equiv, то пользователь автоматически получает доступ в систему без про- верки пароля. Подобная схема моделирует работу старого демона rlogind и, по нашему мнению, неприемлема для широкого применения. • Метод Б. В дополнение к методу А, демон sshd может применять шифрование с открытым ключом для проверки адреса удаленного компьютера. Для того что- бы это произошло, открытый ключ компьютера (генерируется при инсталляции пакета) должен находиться в файле /etc/ssh_known_hosts локального узла или в файле ~/. ssh/known_hosts пользователя. Если удаленный компьютер предо- ставляет соответствующий секретный ключ (обычно хранится в файле /etc/ssh_ host_key, который недоступен для чтения рядовым пользователям), то пользова- телю разрешается войти в систему без проверки пароля. Мы полагаем, что данный метод сильнее, чем метод А, но все же недостаточно безопасен. Если удаленный компьютер взломан, локальная система также окажет- ся под угрозой. • Метод В. Демон sshd может применять шифрование с открытым ключом для идентификации самого пользователя. На этапе регистрации пользователь должен иметь доступ к файлу своего секретного ключа и предоставить пароль для его де- шифровки. Ключ можно также создать без пароля, что является разумным реше- нием для автоматической регистрации из удаленных систем. Этот метод самый безопасный, но он утомляет пользователей. Кроме того, он де- лает невозможной регистрацию в системе мобильных пользователей, если толь- ко они не возят с собой копию файла с секретным ключом (возможно, на USB- ключе, который должен быть зашифрован). Если вы решили использовать пару ключей, широко используйте команду ssh -v в процессе поиска ошибок. • Метод Г. Наконец, демон sshd может просто попросить пользователя ввести свой регистрационный пароль. Это напоминает утилиту telnet, за исключением того, что пароль и все данные, передаваемые в ходе сеанса, подвергаются шифрованию. Основной недостаток этого метода заключается в том, что пароли оказываются относительно слабыми (часто их длина ограничена 8 символами) и есть готовые программы (например, crack) для взлома таких паролей. Тем не менее этот метод, как правило, лучше всего подходит для повседневного использования.
974 Часть II. Работа в сети Правила аутентификации задаются в файле /etc/sshd_config. Он уже заполнен разного рода конфигурационным, “мусором”, большую часть которого можно проигно- рировать. Параметры, касающиеся аутентификации, перечислены в табл. 22.2. Таблица 22.2. Параметры аутентификации, задаваемые в файле /etc/sshd_config Параметр' Метод* Поумол- чанию - Назначение RhostsAuthentication A no Разрешает регистрацию через файлы ~/.shosts, /etc/shosts.equiv и т.п. RhostsRSAAuthentication Б yes Разрешает регистрацию через файл ~/.shosts и другие, но также требует от компьютера предо- ставить ключ IgnoreRhosts А, Б no Задает игнорирование файлов ~/.rhosts и hosts, eq uiv6 IgnoreRootRhosts А, Б noB Запрещает аутентификацию пользователя root через файлы .rhosts и .shosts RSAAuthentication В yes Разрешает аутентификацию пользователей по ме- тоду шифрования с открытым ключом PasswordAuthentication Г yes Разрешает использование обычных регистрацион- ных паролей а Методы аутентификации, к которым относится параметр. 6 Файлы ~/.shosts и shosts.equiv продолжают использоваться. в По умолчанию равен значению параметра IgnoreRhosts. Рекомендуемая нами конфигурация, в которой разрешаются методы В и Г, но не А и Б, такова. RhostsAuthentication по RhostsRSAAuthentication по RSAAuthentication yes PasswordAuthentication yes Никогда не следует разрешать суперпользователю регистрироваться в удаленном ре- жиме. Доступ суперпользователя должен осуществляться только с помощью команды sudo. Для того чтобы установить этот режим, используйте следующий параметр. PermitRootLogin по Когда вы впервые устанавливаете соединение с новой системой посредством прото- кола SSH, вам предложат принять открытый ключ для доступа к удаленному узлу (ко- торый обычно генерируется в процессе инсталляции системы OpenSSH или сразу по- сле этого). Настоящий параноик может проверить его вручную, но большинство из нас слепо доверяют этому ключу и сохраняют его в файле ~/. ssh/known_hosts. Протокол SSH больше не вспоминает о серверном ключе, пока он не изменится. К сожалению, не- брежность пользователей по отношению к ключам новых систем делает их уязвимыми для атак злоумышленников, если ключ на самом деле был предоставлен системой хакера. Для устранения этого недостатка была изобретена запись DNS, получившая название SSHFP. В ее основе лежит предположение, что серверный ключ хранится в виде записи DNS. Когда клиент соединяется с неизвестной системой, протокол SSH ищет запись SSHFP, чтобы самостоятельно проверить ключ сервера, а не полагаться на пользователя. Утилита sshfp, доступная на сайте xelerance.com/software/sshfp, генериру- ет записи SSHFP DNS, либо сканируя удаленный сервер, либо выполняя анализ ранее
Глава 22. Безопасность 975 принятого ключа из файла known_hosts. (Разумеется, в любом случае предполагает- ся, что источник ключа известен и заслуживает доверия.) Использование этой утили- ты не представляет трудностей: для генерирования ключа на основе сканирования сети применяется флаг -s, а для анализа файла known__hosts — флаг -к (по умолчанию). Например, следующая команда генерирует BIND-совместимую запись SSHFP для до- мена Solaris.booklab.atrust.com. Solaris$ sshfp solaris.booklab.atrust.com solaris.booklab.atrust.com IN SSHFP 1 1 94a26278ee713a37f 6a78110f lad9bd... solaris.booklab.atrust.com IN SSHFP 2 1 7cf72d02e3d3fa947712bc56fd0e0a3i... Добавьте эти записи в зонный файл домена (будьте осторожны с именами и коман- дой $ORIGIN), перезагрузите домен и примените команду dig для верификации ключа. solaris$ dig solaris.booklab.atrust.com. IN SSHFP | grep SSHFP ; «» DiG 9.5.1-P2 «» solaris.booklab.atrust.com. IN SSHFP ; solaris.booklab.atrust.com. IN SSHFP solaris.booklab.atrust.com. 38400 IN SSHFP 1 1 94a26278ee713a37f6a78110f... solaris.booklab.atrust.com. 38400 IN SSHFP 2 1 7cf72d02e3d3fa947712bc56f... По умолчанию утилита ssh не проверяет записи SSHFP. Для того чтобы заставить ее сделать это, добавьте параметр VerifyHostKeyDNS в файл конфигурации /etc/ssh/ ssh_conf ig. Как и в большинстве случаев, связанных с использованием параметров клиента SSH, при первом обращении к системе вы можете также указать в командной строке аргумент-о "VerifyHostKeyDNS yes”. Утилита SSH имеет много вспомогательных функций, полезных для системных ад- министраторов. Одна из них позволяет безопасно туннелировать соединения TCP с по- мощью зашифрованного канала SSH, тем самым разрешая устанавливать соединения с небезопасными или защищенными брандмауэрами службами на удаленных сайтах. Эта функциональная возможность повсеместно предоставляется клиентам протокола и допу- скает простое конфигурирование. На рис. 22.1 показано типичное использование тунне- ля SSH. Этот рисунок должен помочь разобраться в принципах его функционирования. Рис. 22.1. Туннель SSH для RDP-соединения В этом сценарии удаленный пользователь желает установить RDP-соединение (уда- ленная настольная система) с системой Windows, входящей в корпоративную сеть. Доступ к этому узлу или порту 3389 блокируется брандмауэром, но поскольку пользо- ватель имеет доступ по протоколу SSH, он может маршрутизировать свое соединение через сервер SSH.
976 Часть II. Работа в сети Для того чтобы установить соединение через сервер SSH, пользователь должен заре- гистрироваться на удаленном сервере SSH с помощью команды ssh. В командной строке ssh он должен указать произвольный, но конкретный локальный порт (в данном случае 9989), на который утилита ssh должна перенаправить безопасный туннель к порту 3389 удаленной Windows-машины. (В стандартной реализации системы OpenSSH для этого до- статочно задать аргумент -Ълокалъный_порт:удаленный_узел'.удаленный_порт.) Все порты источника в данном примере помечены как случайные, потому что выбор произвольного порта, с которым необходимо установить соединение, производится программой. Для доступа к настольной Windows-машине пользователь должен открыть удаленного настольного клиента (в данном случае rdesktop) и ввести localhost:9989 как адрес серве- ра, с которым он хочет установить соединение. Локальная утилита ssh получит соедине- ние с портом 9989 и туннелирует трафик по существующему соединению через удаленный сервер sshd. В свою очередь, сервер sshd направляет соединение на узел Windows. Разумеется, туннели, подобные этим, также могут оказаться преднамеренными или непреднамеренными лазейками. Системные администраторы должны использовать тун- нели с осторожностью и обязаны следить за неавторизованным и неправильным ис- пользованием этой возможности пользователями. В последние годы протокол SSH стал целью регулярных атак на пароли методом перебора. Хакеры выполняют повторяющиеся попытки аутентификации как обычные пользователи, такие как root, joe или admin. Свидетельством таких атак являются реги- страционные записи о сотнях и тысячах неудачных попыток зарегистрироваться. Для защиты от этих атак лучше всего отключить аутентификацию паролей. Пока, похоже, хакеры сосредоточились на порте 22, поэтому эффективной контрмерой является пере- нос сервера SSH на другой порт. Однако история показывает, что защита по принципу “безопасность через неясность” (“security through obscurity”) редко бывает долговремен- ной. Проверка на ваших системах может выявить слабые пароли, которые могут быть взломаны с помощью прямого перебора. Пакет Stunnel Stunnel — это открытый пакет, написанный Михалом Тройнара (Michal Trojnara), ко- торый шифрует TCP-соединения аналогично протоколу SSH. Он использует протокол SSL (Secure Sockets Layer) для создания сквозных туннелей, передающих данные неза- шифрованной службе и обратно. Известно, что он хорошо работает с небезопасными службами, такими как Telnet, IMAP и POP. Демон stunnel работает как на клиентской, так и на серверной системе. Локальный демон stunnel обычно принимает соединения на традиционный порт службы (на- пример, порт 25 для протокола SMTP) и направляет их через протокол SSL к демону stunnel на удаленном узле. Демон stunnel на удаленном узле принимает соединение, расшифровывает входящие данные и направляет их на удаленный порт, на котором про- слушивается сервер. Эта система позволяет незашифрованным службам обеспечивать конфиденциальность и целостность данных, гарантируемые шифрованием, не требуя при этом никаких изменений в программном обеспечении. Достаточно только сконфи- гурировать клиентское программное обеспечение для поиска служб на локальной систе- ме, а не на сервере, который их предоставляет. Протокол Telnet является хорошим примером этого метода, потому что он состоит из простого демона, прослушивающего отдельный порт. Для того чтобы установить соеди- нение со службой Telnet с помощью утилиты stunnel, сначала необходимо создать сер-
Глава 22. Безопасность 977 тификат SSL. Утилита Stunnel не зависит от библиотеки SSL, поэтому это можно сделать в любой стандартной операционной системе; мы предпочитаем систему OpenSSL. Для генерирования сертификата необходимо выполнить следующую команду. server$ sudo openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem Generating a 1024 bit RSA private key .++++++ .................................++++++ writing new private key to 'stunnel.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '. the field will be left blank. Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:Colorado Locality Name (eg, city) [Newbury] :Boulder Organization Name (eg, company) [My Company Ltd]:Booklab, Inc. Organizational Unit Name (eg, section) [] : Common Name (eg, your name or server's hostname) []:server.example.com Email Address [] : Эта команда создает самоподписанный и беспарольный сертификат. С одной сто- роны, отсутствие пароля — это удобно (реальный человек не должен вводить пароль при каждом новом запуске утилиты stunnel), но, с другой стороны, возникает опреде- ленный риск нарушения системы безопасности. Защитите файл сертификата строгими ограничениями. Далее следует определить конфигурацию утилиты stunnel для сервера и клиента. Стандартный конфигурационный файл называется /etc/stunnel/stunnel.conf, но вы можете создать несколько конфигураций, если хотите установить несколько туннелей. cert = /etc/stunnel/stunnel.pem chroot = /var/run/stunnel/ pid = /stunnel.pid setuid = nobody setgid = nobody debug = 7 output = /var/log/stunnel.log client = no [telnets] accept = 992 connect =23 В конфигурации сервера есть несколько важных аспектов. Инструкция chroot огра- ничивает процесс stunnel каталогом /var/run/stunnel. Пути для вспомогательных файлов должны быть выражены либо в обычном системном пространстве имен, либо в пространстве имен, ограниченном командой chroot. Это зависит от точки, в которой они открываются. В данном случае файл stunnel .pid фактически расположен в ката- логе /var/run/stunnel. Раздел [telnets] содержит две инструкции: инструкция accept приказывает ути- лите stunnel принимать соединения на порту 992, а инструкция connect пропускает эти соединения через порт 23, т.е. через реальную службу Telnet.
978 Часть II. Работа в сети Конфигурация клиента является аналогичной. cert = /etc/stunnel/stunnel.pern chroot = /var/run/stunnel/ pid = /stunnel.pid setuid = nobody setgid = nobody debug = 7 output = /var/log/stunnel.log client = yes [telnets] accept =23 connect = server.example.com:992 Несколько директив являются обратными по отношению к конфигурации сервера. Инструкция client = yes приказывает программе выполнить инициацию соединений с помощью утилиты stunnel, а не принимать их. Локальная утилита stunnel прослу- шивает соединения на порту 23 и устанавливает соединения с сервером на порту 992. Имя узла в директиве connect должно совпадать с именем, указанным при создании сертификата. Утилиты s tunnel на клиентской и серверной сторонах могут запускаться без аргу- ментов командной строки. Если вы выполните команду netstat -ап, то увидите, что утилита stunnel на сервере ожидает соединений на порту 992, а клиентская утилита stunnel — на порту 23. Для доступа к туннелю пользователь должен просто применить команду telnet к локальному узлу. client$ telnet localhost 23 Trying 127.0.0.1. . . Connected to localhost (127.0.0.1) . Escape character is ,A] ’. Red Hat Enterprise Linux WS release 4 (Nahant Update 2) Kernel 2.6.9-5.EL on an i686 login: Теперь пользователь может безопасно регистрироваться, не опасаясь кражи пароля. Бдительный администратор может использовать оболочки протокола TCP для ограни- чения соединений на клиентском компьютере только локальным интерфейсом, чтобы не позволить внешним пользователям устанавливать безопасные соединения службы telnet с сервером! Утилита stunnel — одна из немногих программ, которая имеет встроенную поддержку оболочки и не требует использования команды tcpd для ограни- чения доступа. Инструкции по ее использованию можно найти на сайте stunnel. org. 22.11. Брандмауэры Помимо защиты отдельных компьютеров, можно предпринять меры для обеспече- ния безопасности на сетевом уровне. Основным инструментом сетевой защиты является брандмауэр, физическое устройство или часть программного обеспечения, не допускаю- щие нежелательные пакеты в системы или сети. Брандмауэры в настоящее время ис- пользуются всюду. Их можно обнаружить как в настольных компьютерах и серверах, так и в маршрутизаторах и корпоративном сетевом оборудовании.
Глава 22. Безопасность 979 Брандмауэры, фильтрующие пакеты Брандмауэр, фильтрующий пакеты, ограничивает виды трафика, проходящего че- рез интернет-шлюз (или через внутренний шлюз, разделяющий домены в пределах организации), основываясь на информации, извлеченной из заголовков пакетов. Это напоминает прохождение таможни, когда вы на своем автомобиле пересекаете грани- цу. Администратор указывает, какие целевые адреса, номера портов и типы протоколов являются допустимыми, а брандмауэр просто отбрасывает (в некоторых случаях также регистрирует) все пакеты, которые не соответствуют заданным критериям. В системах семейства Linux фильтрация пакетов осуществляется с помощью утилиты iptables, в системах Solaris и HP-UX — с помощью программы IPFilter, а в системе AIX — с помощью команды genf ilt. Подробно они будут рассмотрены чуть позже. Несмотря на то что эти инструменты способны выполнять сложную фильтрацию и значительно повышают степень безопасности, в целом мы разочарованы использовани- ем систем UNIX и Linux в качестве сетевых маршрутизаторов и особенно в качестве кор- поративных маршрутизаторов, играющих роль брандмауэров. Сложность универсальных систем снижает их защищенность и надежность по сравнению со специальными устрой- ствами. Для защиты корпоративных сетей лучше применять специальные брандмауэры, например устройства компании Check Point и Cisco. Принципы фильтрации служб Большинству “известных” служб назначается сетевой порт в файле /etc/services или его системно-зависимом эквиваленте. Демоны, которые реализуют соответствую- щие службы, постоянно опрашивают порты, ожидая поступления запросов на подклю- чение со стороны удаленных компьютеров7. В основном, такие порты являются “при- вилегированными”. Это значит, что их номера находятся в диапазоне от 1 до 1023 и что порты могут использоваться только процессами, работающими от имени пользователя root. Порты с номерами 1024 и выше являются непривилегированными. Фильтрация на уровне служб основана на предположении, что клиент (компью- тер, инициирующий соединение по протоколу TCP или UDP) будет использовать не- привилегированный порт для установления соединения с привилегированным портом сервера. Например, если компьютеру с адресом 192.108.21.200 нужно разрешить только входящие SMTP-соединения, то следует установить фильтр, который позволит посылать TCP-пакеты по этому адресу через порт 25 и отправлять TCP-пакеты с этого адреса че- рез любой порт8. Способ инсталляции такого фильтра будет зависеть от типа используе- мого маршрутизатора. Некоторые службы, например FTP, еще больше усложняют эту головоломку. При пересылке файла по протоколу FTP на самом деле устанавливается два соединения: для команд и для данных. Клиент инициирует командное соединение, а сервер — информационное.9 Следовательно, если необходимо получать файлы из Интернета по протоколу FTP, следует разрешить вход в систему через все непривилегированные ТСР- 7 Во многих случаях задачу ожидания берут на себя демоны inetd или xinetd. Подробнее об этом рассказывается в разделе 32.1. 8 Порт 25 — это порт SMTP, определенный в файле /etc/services. 9 Это относится к традиционному протоколу FTP, известному как “активный протокол FTP”. Некоторые системы поддерживают “пассивный протокол FTP”, в котором оба соединения ини- циируются клиентом.
980 Часть II. Работа в сети порты, так как неизвестно, какой из них будет использован для установления информа- ционного соединения. £□ Подробнее о конфигурировании FTP-сервера рассказывается в разделе 23.4. Это сводит на нет преимущества фильтрации пакетов, поскольку некоторые общеиз- вестные службы, печально известные своей незащищенностью, работают с непривиле- гированными портами (например, служба XI1 на порту 6000). Кроме того, любознатель- ные пользователи получают возможность запускать собственные служебные программы (например, сервер telnet на нестандартном и непривилегированном порту), к которым они и их друзья могут обращаться из Интернета. Самый безопасный способ использования фильтра пакетов — использовать протокол передачи данных SSH. В настоящее время в Интернете опубликован его черновик, но он уже широко используется и достиг достаточно высокой степени зрелости. Обычно он используется как компонент протокола SSH, обеспечивающего аутентификацию и шифрование. В отличие от протокола FTP, протокол SFTP использует только один порт и для команд, и для данных, разрешая парадокс фильтрации пакетов. Существует мно- го реализаций протокола SFTP. Мы рекомендуем использовать клиентскую утилиту ко- мандной строки SFTP, поставляемую в системе OpenSSH. Наиболее разумный способ решения проблем с протоколом FTP — разрешить вы- ход по протоколу FTP во внешний мир только с этого изолированного компьютера. Пользователи смогут регистрироваться на нем, когда им понадобится выполнять сете- вые операции, запрещенные во внутренней сети. Поскольку копирование всех пользо- вательских учетных записей на FTP-сервер противоречит сути административного деле- ния в организации, можно создавать учетные записи только по заявкам. Естественно, на FTP-сервере должен быть инсталлирован полный комплект средств защиты. В некоторых организациях, которые заботятся о безопасности, используется двух- ступенчатая фильтрация. Один фильтр в этой схеме подключен к Интернету как шлюз, а второй находится между этим шлюзом и остальной частью локальной сети. Идея со- стоит в том, чтобы оставить внешний шлюз относительно открытым, а внутренний — сделать очень консервативным. Если промежуточный компьютер административно от- делен от остальной части сети, появляется возможность реализовать различные службы Интернета с меньшим риском. Частично защищенная сеть обычно называется “демили- таризованной зоной” (DMZ). Наиболее безопасным способом использования фильтрации пакетов является на- стройка первоначальной конфигурации, которая не позволяет никаких входящих сое- динений. Затем можно постепенно ослабить фильтрацию, выяснив полезные службы, которые не работают, и перенеся все службы, доступные в Интернете, в демилитаризо- ваную зону. Брандмауэры, осуществляющие инспекцию пакетов с отслеживанием состояния соединений В основе инспекции пакетов с отслеживанием состояния соединений лежит концеп- ция, которую можно описать с помощью следующего примера. Представьте себе, что вы ищете террориста в переполненном аэропорту, внимательно прислушиваясь ко всем раз- говорам, происходящим вокруг вас, и понимая их содержание (на всех языках). Брандмауэ- ры, осуществляющие инспекцию пакетов с отслеживанием состояния соединений (stateful inspection firewalls), проверяют весь трафик, проходящий через них, и сравнивают его с те- кущей сетевой активностью в ожидании события, которое “должно” произойти.
Глава 22. Безопасность 981 Например, если пакеты, обмениваемые в ходе выполнения последовательности ко- манд протокола FTP, называют порт, который впоследствии должен использоваться для информационного соединения, то брандмауэр должен проверить, что информационное соединение произойдет именно на этом порту. Попытки удаленного сайта соединиться с другими портами заранее считаются фальшивыми и должны пресекаться. Так что же на самом деле предлагают разработчики под видом инспекции пакетов с учетом состояния протокола. Их продукты либо осуществляют мониторинг ограни- ченного количества соединений или протоколов, либо распознают конкретный набор “неблагоприятных” ситуаций. В этом нет ничего плохого. Очевидно, что из любой тех- нологии, способной распознавать аномалии трафика, можно извлечь пользу. Однако в данном случае важно помнить, что все эти обещания преимущественно являются лишь рекламным ходом. Насколько безопасны брандмауэры Фильтрация пакетов не должна быть основным средством защиты от хакеров. Это всего лишь вспомогательная мера. При наличии брандмауэра порой создается ложное впечатление, будто уровень безопасности является исключительно высоким. Если, до- верившись брандмауэру, ослабить бдительность на других “рубежах”, это отрицательно скажется на защищенности информации. Каждый компьютер необходимо защищать индивидуально и регулярно проверять с помощью таких средств, как Вго, Snort, Nmap, Nessus и OSSEC. Следует также обучать пользователей правилам безопасной работы в системе. В противном случае вы просто создадите внешне устойчивую, но крайне запутанную внутри систему. В идеале локальные пользователи должны иметь возможность подключаться к любой службе Интернета, но доступ к локальным службам со стороны интернет-узлов должен быть ограничен демилитаризованной зоной. Например, к серверу архивов может быть разрешен SFTP-доступ, а к почтовому серверу, получающему входящую почту, — доступ только по протоколу SMTP. Для того чтобы интернет-канал работал с максимальной эффективностью, советуем все же обратить основное внимание на удобство работы и доступность. В конце концов, сеть становится безопасной благодаря бдительности системного администратора, а не благодаря брандмауэру. 22.12. Особенности брандмауэров в системе Linux Обычно мы не рекомендуем использовать компьютер, работающий под управле- нием Linux (а также UNIX или Windows), в качестве брандмауэра, поскольку в целом операционная система не обеспечивает надлежащий уровень безопасности.10 Однако лучше инсталлировать усиленную систему Linux, чем вообще ничего, если речь идет о Домашнем компьютере или организации, бюджет которой не предусматривает покуп- ку оборудования соответствующего уровня. В любом случае локальный фильтр, такой как команда iptables, может оказаться превосходным инструментом для обеспечения безопасности. Устанавливая систему Linux в качестве брандмауэра, убедитесь, что она включа- ет самые последние обновления и “заплаты”, касающиеся брешей в системе защиты. 10 И все же многие сетевые устройства, например маршрутизаторы компании Linksys, в своих ядрах используют систему Linux и iptables.
982 Часть II. Работа в сети Компьютер, функционирующий в качестве брандмауэра, — идеальное место для практи- ческой проверки всех рекомендаций^ изложенных в этой главе. (В разделе 22.11 собраны сведения, касающиеся брандмауэров в целом. Читателям, не знакомым с концепцией брандмауэра, советуем предварительно прочитать приведенный там материал.) Правила, цепочки и таблицы В ядре Linux версии 2.4 появился новый механизм фильтрации пакетов — Netfilter. Контролирующая его работу команда iptables является “наследницей” более старой команды ipchains, которая использовалась в ядрах версии 2.2. В команде iptables применяется концепция упорядоченной цепочки правил, согласно которым проверяют- ся сетевые пакеты. Наборы цепочек образуют таблицы, предназначенные для обработки определенных видов трафика. К примеру, стандартная таблица для команды iptables называется filter. Цепочки правил этой таблицы используются для фильтрации сетевых пакетов. В таблице filter содержатся три стандартные цепочки: FORWARD, INPUT и OUTPUT. Каждый пакет, обра- батываемый ядром, поступает на проверку в одну цепочку. Правила в цепочке FORWARD применяются ко всем пакетам, которые поступают в один интерфейс и перенаправляются в другой. Правила в цепочках INPUT и OUTPUT предназначены для пакетов, адресованных локальному компьютеру или исходящих от него соответственно. Обычно этих трех цепочек вполне достаточно для фильтрации данных между двумя интерфейсами. В случае необходимости можно определять более сложные конфигурации. Помимо таблицы filter, существуют также таблицы nat и mangle. В первой со- держатся цепочки правил, предназначенные для управления системой NAT (Network Address Translation — трансляция сетевых адресов). Подробнее об этой системе расска- зывалось в разделе 14.4, а в разделе 14.12 приводился пример использования таблицы nat. В этом разделе мы воспользуемся цепочкой PREROUTING данной таблицы для филь- трации пакетов с поддельными IP-адресами. Таблица mangle содержит цепочки, предназначенные для модификации содержимо- го сетевых пакетов вне контекста системы NAT или механизма фильтрации пакетов. Эта таблица редко применяется в крупных системах, поэтому мы не будем ее рассматривать. Целевые директивы для правил В каждом правиле цепочки имеется целевая директива, определяющая, что следует делать с пакетами, подчиняющимися этому правилу. Если пакет прошел проверку, его судьба предрешена и другие проверки не выполняются. В качестве директивы разреша- ется указывать имя другой цепочки. Правила таблицы filter могут содержать следующие целевые директивы: ACCEPT, drop, REJECT, LOG, MIRROR, QUEUE, REDIRECT, RETURN и ULOG. Директива ACCEPT разре- шает пакету следовать своим маршрутом. Директивы DROP и REJECT запрещают пропу- скать пакет, но первая приводит к “безмолвному” удалению пакета, а вторая — к выдаче ICMP-сообщения об ошибке. Директива LOG позволяет следить за тем, какие правила применяются к пакетам, а директива ULOG включает режим расширенной регистрации. Директива REDIRECT перенаправляет пакеты прокси-серверу. Она удобна, когда весь трафик веб-узла должен проходить через кеширующую программу, такую как Squid. Ди- ректива RETURN объявляет конец пользовательской цепочки. Директива MIRROR меняет
Глава 22. Безопасность 983 местами IP-адреса отправителя и получателя перед отправкой пакета. Наконец, дирек- тива QUEUE передает пакеты локальным программам пользователя через модуль ядра. Настройка команды iptables в качестве брандмауэра Для того чтобы можно было использовать команду iptables, следует включить ре- жим перенаправления IP-пакетов и убедиться в том, что многочисленные модули ко- манды загружены в ядро. О том, как включить указанный режим, рассказывалось в раз- делах 13.3 и 14.12. Во всех дистрибутивах, где есть команда iptables, есть и сценарии загрузки ее модулей. В системе Linux брандмауэр обычно реализуется в виде последовательности команд iptables, содержащихся в одном из сценариев запуска системы. Отдельные команды iptables, как правило, имеют одну из следующих форм. iptables -F имя_цепочки iptables -Р имя_цепочки директива iptables -А имя_цепочки -i интерфейс - j директива В первом случае (-F) из цепочки удаляются все предыдущие правила. Во втором слу- чае (-р) задается стандартная директива цепочки. Мы рекомендуем по умолчанию использовать директиву DROP. В третьем случае (-А) заданное правило добавляется к цепочке. Если не указан флаг -t, команда применяется к цепочкам таблицы filter. Опция -i определяет интерфейс, для которого это правило действует. Опция - j задает директиву. Команда iptables понимает также ряд других опций (табл. 22.3). Таблица 22.3. Дополнительные флаги для фильтров команды iptables Опция Назначав -р протокол Соответствие протоколу: tcp, udp или icmp -s исходный_адрес Соответствие исходному IP-адресу узла или сети (допускается нотация CIDR) -d целевой_адрес Соответствие целевому IP-адресу узла или сети --sport номер_порта Соответствие номеру исходного порта (обратите внимание на двойной дефис) —dport номер_порта Соответствие номеру целевого порта (обратите внимание на двойной дефис) --icmptype тип Соответствие типу ICMP-сообщения (обратите внимание на двойной дефис) j Инверсия смысла опции -t Задает таблицу, к которой применяется команда (по умолчанию — filter) Полный пример Ниже мы детально разберем конкретный пример. Предполагается, что интерфейс ethl подключен к Интернету, а интерфейс ethO — к локальной сети. IP-адрес интер- фейса ethl равен 128.138.101.4, а интерфейса ethO — 10.1.1.254. В обоих случаях маска сети равна 255.255.255.0. В этом примере выполняется фильтрация пакетов без учета со- стояния для защиты веб-сервера с IP-адресом 10.1.1.2. Это стандартный метод защиты веб-серверов. В конце примера будет продемонстрирована фильтрация пакетов с учетом состояния для защиты настольных компьютеров. Нашим первым действием будет инициализация таблицы filter. Сначала все це- почки таблицы очищаются, после чего для цепочек INPUT и OUTPUT назначается стан- дартная директива drop. Как и в других подобных случаях, наиболее безопасная страте- гия заключается в удалении всех пакетов, которые не упомянуты явно.
984 Часть II. Работа в сети iptables -F iptables -Р INPUT DROP iptables -P FORWARD DROP Поскольку правила проверяются по порядку, поместим наиболее часто используемые вперед11. Первые правила цепочки forward разрешают устанавливать соединения с сете- выми службами по адресу 10.1.1.2. В частности, разрешаются протоколы SSH (порт 22), HTTP (порт 80) и HTTPS (порт 443). Самое первое правило пропускает все пакеты, ис- ходящие из внутренней сети. iptables -A FORWARD -i ethO -р ANY -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p tcp —dport 22 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p tcp —dport 80 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p tcp —dport 443 -j ACCEPT Единственный TCP-трафик, который может приниматься узлом, — это трафик про- токола SSH, с помощью которого можно управлять брандмауэром. Второе из показан- ных ниже правил разрешает трафик интерфейса обратной связи внутри брандмауэра. Наши администраторы начинают нервничать, если им не удается с помощью команды ping найти стандартный маршрут, поэтому третье правило пропускает ICMP-пакеты ECHO_REQUEST, имеющие локальный IP-адрес отправителя. iptables -A INPUT -i ethO -d 10.1.1.1 -p tcp —dport 22 -j ACCEPT iptables -A INPUT -i lo -d 127.0.0.1 -p ANY - j ACCEPT iptables -A INPUT -i ethO -d 10.1.1.1 -p icmp —icmp-type 8 -j ACCEPT Компьютеру, имеющему выход в Интернет, для нормальной работы необходимо, что- бы брандмауэр пропускал определенные типы ICMP-пакетов. Следующие восемь пра- вил пропускают минимальный набор ICMP-пакетов как на сам брандмауэр, так и в за- щищаемую им сеть. iptables -A INPUT -р icmp —icmp-type 0 -j ACCEPT iptables -A INPUT -p icmp —icmp-type 3 -j ACCEPT iptables -A INPUT -p icmp —icmp-type 5 -j ACCEPT iptables -A INPUT -p icmp —icmp-type 11 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p icmp —icmp-type 0 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p icmp —icmp-type 3 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p icmp —icmp-type 5 -j ACCEPT iptables -A FORWARD -d 10.1.1.2 -p icmp —icmp-type 11 -j ACCEPT Теперь добавим правила в цепочку PREROUTING таблицы nat. Эти правила не связа- ны с фильтрацией пакетов, зато полезны для защиты от поддельных IP-адресов. Правила с директивой DROP не нужно дублировать в цепочках INPUT и FORWARDING, поскольку цепочка PREROUTING применяется ко всем пакетам, поступающим на брандмауэр. iptables -t nat -A PREROUTING -i ethl -s 10.0.0.0/8 -j DROP iptables -t nat -A PREROUTING -i ethl -s 172.16.0.0/12 -j DROP iptables -t nat -A PREROUTING -i ethl -s 192.168.0.0/16 -j DROP iptables -t nat -A PREROUTING -i ethl -s 127.0.0.0/8 -j DROP iptables -t nat -A PREROUTING -i ethl -s 224.0.0.0/4 -j DROP Наконец, завершим цепочки input и forward правилами, которые запрещают все пакеты, не упомянутые явно. Вообще-то, это уже было сделано с помощью команд iptables -Р, но директива LOG позволяет увидеть, кто к нам “стучится” из Интернета. 11 Следите за тем, чтобы стремление к повышению производительности не нарушало логику выполнения правил.
Глава 22. Безопасность 985 iptables -A INPUT -i ethl -j LOG iptables -A FORWARD -i ethl -j LOG При желании можно включить систему NAT, чтобы скрывать частные адреса, ис- пользуемые во внутренней сети. Подробнее об этом рассказывалось в разделе 14.12. Одной из наиболее интересных возможностей механизма Netfilter является филь- трация пакетов с учетом состояния. Вместо того чтобы пропускать входящий трафик определенных типов, брандмауэр пропускает трафик, выдаваемый в ответ на клиентские запросы. Показанная ниже простейшая цепочка разрешает всем пакетам покидать сер», но принимаются лишь те пакеты, которые поступают в рамках соединений, установлен- ных узлами нашей сети. iptables -A FORWARD -i ethO -р ANY -j ACCEPT iptables -A FORWARD -m state —state ESTABLISHED,RELATED -j ACCEPT Для того чтобы команда iptables могла отслеживать сложные сетевые сеансы, на- пример сеансы протоколов FTP и IRC, должны быть загружены определенные модули ядра. В противном случае команда просто не будет позволять устанавливать соответству- ющие соединения. Фильтрация пакетов с учетом состояния способна повысить безопас- ность системы, но она резко повышает и сложность управления сетью. Убедитесь в том, что она действительно нужна, прежде чем реализовать ее на брандмауэре. Для отладки цепочек правил, вероятно, лучше всего подходит команда iptables -L-Цг. Она сообщит, сколько раз для того или иного правила было найдено совпадение. Мы часто добавляем временные правила с директивой LOG, если хотим получить дополни- тельную информацию о проверке пакетов. Более сложные проблемы решаются с помо- щью анализатора пакетов, такого как tcpdump. 22.13. Модуль IPFilter для систем UNIX Большинство разработчиков системы UNIX не имеют собственного программного обеспечения для брандмауэров.12 Однако его достаточно легко добавить: технологию NAT и функции брандмауэра с отслеживанием состояния соединений для систем UNIX реализует открытый пакет IPFilter, разработанный Дарреном Ридом (Darren Reed). Система Solaris включает его по умолчанию. Кроме того, он доступен в виде надстроек для систем HP-UX, AIX и многих других, включая Linux. Пакет IPFilter можно испол^ зовать как загружаемый модуль ядра (что рекомендуется разработчиками) или включать в ядро статически. Пакет IPFilter является зрелым и полнофункциональным программным обеспечени- ем. Он имеет активное сообщество его пользователей и постоянно совершенствуется. Этот пакет способен отслеживать состояние соединений даже для протоколов без запо- минания состояния, таких как UDP и ICMP. Пакет IPFilter считывает правила фильтрации из файла конфигурации (обычно /etc/ipf .conf или /etc/ipf/ipf .conf), не заставляя пользователя выполнять не- сколько таких команд, как iptables. Рассмотрим простое правило, которое может встретиться в файле ipf. conf. block in all 12 Исключением является компания IBM. Система AIX включает отдельное программное обе- спечение для фильтрации пакетов IP Security, хотя оно не выполняет фильтрацию с учетом состоя- ния протокола. Для начала изучите справочную страницу genfilt.
986 Часть II. Работа в сети Это правило блокирует весь входящий трафик (т.е. сетевые команды, полученные системой) на всех сетевых интерфейсах. Определенно, это безопасно, но не слишком полезно! В табл. 22.4 перечислены некоторые возможные условия, которые могут упоминаться в правилах ipf. Таблица 22.4. Типичные условия ipf Условие 'QltlMNMk •' 1 ' on интерфейс Применяет правило к конкретному интерфейсу proto протокол Выбирает пакет в соответствии с протоколом: tcp, udp или icmp from ip—Источника Фильтрует по источнику: host, network или any to 1р_получателя Фильтрует по получателю: host, network или any port = номер_порта Фильтрует по имени порта (из /etc/services) или номеру8 flags флаг Фильтрует по флагам заголовка TCP icmp-type число Фильтрует по типу и коду ICMP keep state Сохраняет подробную информацию о сеансе; см. комментарии ниже а Можно использовать любой оператор сравнения: = <, >, <=, >=, etc. Пакет IPFilter оценивает правила в том порядке, в котором они представлены в фай- ле конфигурации. Последнее совпадение является привязкой. Например, входящие паке- ты, передаваемые через следующий фильтр, всегда проходят через него. block in all pass in all Правило block применяется ко всем пакетам, как и правило pass, но при этом пра- вило pass проверяется последним. Для того чтобы немедленно применить одно правило и пропустить остальные, следует использовать ключевое слово quick. block in quick all pass in all Промышленные брандмауэры обычно состоят из многих правил, поэтому для под- держания их эффективной работы важно свободно пользоваться ключевым словом quick. Без этого каждый пакет будет оценивать каждое правило, что приведет к нео- правданным затратам времени. Возможно, чаще всего брандмауэры используются для управления доступом к кон- кретной сети или узлу и контроля за их обращениями к другим сетям и узлам, часто по отношению к конкретному порту. Пакет IPFilter имеет мощный синтаксис для управле- ния трафиком на данном уровне детализации. В следующих правилах разрешается вхо- дящий трафик в сеть 10.0.0.0/24 на ТСР-порты 80 и 443 и UDP-порт 53. block out quick all pass in quick proto tcp from any to 10.0.0.0/24 port = 80 keep state pass in quick proto tcp from any to 10.0.0.0/24 port = 443 keep state pass in quick proto udp from any to 10.0.0.0/24 port = 53 keep state block in all Ключевые слова keep state заслуживают особого внимания. Пакет может отслежи- вать соединения, отмечая первый пакет в новом сеансе. Например, когда новый пакет поступает на порт 80 в узле 10.0.0.10, программа IPFilter делает запись в таблице состо- яний и пропускает пакет в сеть. Он также позволяет веб-серверу ответить, даже если
Глава 22. Безопасность 987 первое правило явно блокирует весь исходящий трафик. Ключевые слова keep state также полезны для устройств, которые не предоставляют никаких услуг, но обязаны инициировать соединения. Следующий набор правил разрешает любую передачу дан- ных, инициированную узлом 192.168.10.10. Он блокирует все входящие пакеты, за ис- ключением пакетов, связанных с соединениями, которые уже были инициированы. block in quick all pass out quick from 192.168.10.10/32 to any keep state Ключевые слова keep state относятся и к пакетам UDP и ICMP, но поскольку эти протоколы не запоминают состояния, их механизм довольно необычен: программа IPFilter разрешает ответы на UDP- и ICMP-пакет в течение 60 секунд после того, как входящий пакет был обнаружен фильтром. Например, если UDP-пакет, пришедший от узла 10.0.0.10 с порта 32000, адресован узлу 192.168.10.10 на порт 53, то ответ по прото- колу UDP от узла 192.168.10.10 будет разрешен в течение 60 секунд после прохождения через порт. Аналогично ICMP-эхо (ответ на команду ping) разрешается после того, как запрос эха был занесен в таблицу состояний. 03 Частные адреса и технология NAT описаны в разделе 14.4. Трансляция сетевых адресов (Network address translation — NAT) — это еще одна функциональная возможность, предлагаемая пакетом IPFilter. Система NAT позволяет крупной сети, использующей частные адреса RFC1918, соединяться с Интернетом с по- мощью небольшого набора интернет-маршрутизируемых IP-адресов. Устройство NAT отображает трафик, исходящий из частной сети, в один или несколько открытых адре- сов, посылает запросы через Интернет, а затем перехватывает ответы и переписывает их в терминах локальных IP-адресов. Для выполнения функций NAT пакет IPFilter использует ключевое слово шар (вме- сто pass и block). В следующем правиле трафик, исходящий из сети 10.0.0.0/24, ото- бражается в текущий маршрутизируемый адрес на интерфейсе elOOOgO. map elOOOgO 10.0.0.0/24 -> 0/32 Если адрес интерфейса elOOOgO, то фильтр должен быть перезагружен, поскольку может оказаться, что интерфейс elOOOgO арендует динамические IP-адреса по протоко- лу DHCP. По этой причине функциональные возможности NAT в пакете IPFilter лучше всего использовать на сайтах, имеющих статические адреса на интерфейсе, имеющем выход в Интернет. Правила пакета IPFilter являются гибкими и настраиваемыми. С помощью дополни- тельных возможностей, таких как макросы, их можно значительно упростить. Подроб- ности, относящиеся к этим дополнительным возможностям, можно найти на официаль- ном сайте IPFilter coombs. anu. edu. au/~ aval on. Пакет IPFilter включает несколько команд, перечисленных в табл. 22.5. Таблица 22.5. Команды пакета IPFilter Команда ... ; _ ipf Управляет списками правил и фильтров ipfstat Получает статистическую информацию о фильтрации пакетов ipmon Отслеживает зарегистрированную информацию о фильтре ipnat Управляет правилами NAT
988 Часть II. Работа в сети Среди команд, перечисленных в табл. 22.5, чаще всего используется команда ipf. Она получает на вход файл правил и добавляет правильно сформулированные правила в список фильтров в ядре. Если не указан аргумент -Fa, стирающий все существующие правила, команда ipf добавляет правила в конец фильтра. Например, для того чтобы стереть существующий набор фильтров в ядре и загрузить правила из файла ipf. conf, следует выполнить следующую команду. solaris$ sudo ipf -Fa -f /etc/ipf/ipf.conf Для управления доступом пакет IPFilter использует файлы псевдоустройств из ка- талога /dev, и по умолчанию только пользователь root может редактировать список фильтров. Мы рекомендуем не изменять разрешения, установленные по умолчанию, а для управления фильтром использовать команду sudo. При загрузке файла для отладки синтаксических ошибок и выявления других, свя- занных с конфигурацией, используйте флаг -v команды ipf. Пакет IPFilter изначально инсталлирован в ядре операционной системы soiaris Solaris, но перед использованием его необходимо активизировать с помощью следующей команды. solaris$ sudo svcadm enable network/ipfilter 22.14. Виртуальные частные сети В простейшем виде виртуальная частная сеть (Virtual Private Networks — VPN) — это специальный тип сетевого соединения, эмулирующего непосредственное подключение удаленной сети, даже если в действительности она находится за тысячу километров и скрыта за множеством маршрутизаторов. Для повышения безопасности соединение не только подвергается аутентификации в том или ином виде (обычно с использованием совместного секретного ключа, например пароля), но еще и шифруется. Это называется защищенным туннелем. Приведем пример ситуации, в которой сеть VPN оказывается очень удобной. Предположим, компания имеет офисы в нескольких городах: Чикаго, Боулдере и Майами. Если каждый офис подключен к локальному провайдеру Интернета, то по- средством виртуальных частных сетей компания может прозрачным образом (и, главное, весьма безопасно) соединить все офисы через такую ненадежную сеть, как Интерне/. Конечно, такого же результата можно достичь и за счет покупки выделенных линий, но это обойдется гораздо дороже. В качестве еще одного примера можно взять компанию, служащие которой выходят в сеть из дому. Наличие виртуальных частных сетей позволит служащим пользоваться преимуществами своих высокоскоростных и недорогих кабельных модемов и в то же время работать так, будто они непосредственно подключены к корпоративной сети. Благодаря удобству и популярности такого подхода, многие компании стали пред- лагать решения, связанные с сетью VPN. Функции поддержки VPN могут быть реализо- ваны в маршрутизаторе, в операционной системе и даже в специализированном сетевом устройстве. Если позволяет бюджет, рассмотрите коммерческие предложения, в избытке имеющиеся на рынке. Если же вы ограничены в средствах, обратитесь к пакету SSH, который позволяет организовать защищенные туннели (раздел 22.10).
Глава 22. Безопасность 989 Туннели IPSEC Те, кого интересует надежное и недорогое решение в области VPN, должны обра- тить внимание на IPSEC (Internet Protocol Security — механизм защиты протокола IP). Изначально он был реализован для протокола IPv6, но теперь доступен также и для IPv4. IPSEC — это одобренная организацией IETF система аутентификации и шифро- вания соединений. Практически все серьезные поставщики VPN-систем оснащают свои продукты по крайней мере режимом совместимости с IPSEC. Системы Linux, Solaris, HP-UX и AIX содержат поддержку технологии IPSec, встроенную в ядро. Для аутентификации и шифрования механизм IPSec использует сильные криптогра- фические алгоритмы. Аутентификация гарантирует, что пакеты приходят от легального отправителя и по дороге не были искажены, а шифрование предотвращает несанкцио- нированный просмотр содержимого пакета. В туннельном режиме система шифрует заголовок транспортного уровня, содержа- щий номера портов отправителя и получателя. К сожалению, этот механизм напрямую конфликтует со способом работы большинства брандмауэров. По этой причине в боль- шинстве современных реализаций по умолчанию используют транспортный режим, в котором шифруется только содержимое пакетов (т.е. передаваемые данные). Существует одна тонкость, связанная с туннелями IPSEC и параметром MTU переда- ваемых пакетов. Важно убедиться в том, что пакет, зашифрованный средствами IPSEC, не подвергается фрагментации при прохождении туннеля. Для этого может потребовать- ся снизить значение MTU для сетевых интерфейсов, расположенных перед туннелем (обычно подходит значение 1400 байт). Подробнее о параметре MTU рассказывалось В разделе 14.2. Так ли уж нужны виртуальные частные сети К сожалению, у виртуальных частных сетей есть и недостатки. Они позволяют орй- низовать достаточно надежный туннель через ненадежный канал связи между двумя ко- нечными точками, но они, как правило, не защищают сами конечные узлы. Например, если создать сеть VPN между корпоративной магистралью и домашним компьютером президента компании, то можно ненароком открыть удобную лазейку для 15-летнего вундеркинда, по ночам наведывающегося в папин кабинет. Хорошо, если он использует эту возможность лишь для игр по сети с одноклассниками. А если нет? Отсюда вывод: соединения, устанавливаемые через туннели VPN, следует рассматри- вать как внешние и предоставлять им дополнительные привилегии лишь в случае крайней необходимости, тщательно взвесив все за и против. Можно добавить в свод правил безо- пасности, принятый в организации, специальный пункт, касающийся работы в сети VPN. 22.15. Сертификация и стандарты Если содержание этой главы ошеломило вас, не беспокойтесь. Компьютерная безо- пасность — сложная и необъятная тема, которой посвящены бесчисленные книги, веб- сайты и журналы. К счастью, для оценки и организации существующей информации было сделано немало. Существуют десятки стандартов и сертификаций, и разумный ад- министратор должен их знать. Один из основных философских принципов информационной безопасности нефор- мально называется “триадой CIA”.
990 Часть II. Работа в сети Эта аббревиатура расшифровывается так. • Конфиденциальность (confidentiality) • Целостность (integrity) • Доступность (availability) Конфиденциальность означает секретность данных. Доступ к информации должен быть ограничен кругом лиц, которые имеют право ее знать. Аутентификация, контроль доступа и шифрование — это всего лишь несколько компонентов механизма обеспече- ния конфиденциальности. Если хакер взломает систему и украдет базу данных, содержа- щую персональную информацию о клиентах, то конфиденциальность будет нарушена. Целостность связана с аутентификацией информации. Технология обеспечения це- лостности данных обеспечивает их корректность и защиту от несанкционированных изменений. Она также связана с благонадежностью источников информации. Когда безопасный веб-сайт предоставляет подписанный SSL-сертификат, он подтверждает пользователю не только то, что информация посылается в зашифрованном виде, но и то, что его идентичность удостоверяется авторитетным источником сертификатов (та- ким как компания VeriSign или агентство Equifax). Целостность данных также гаранти- руют специальные технологии, например PGP и Kerberos. Доступность выражает идею о том, что информация должна быть доступной для авторизованных пользователей, когда они в ней нуждаются, но не хотят ее хранить. Перебои, вызванные не действиями злоумышленников, а административными ошибка- ми или сбоями электропитания, также относятся к этой категории проблем. К сожале- нию, доступность часто игнорируется, пока не возникнут проблемы. Принципы CIA следует учитывать при разработке, реализации и эксплуатации си- стем. Старая поговорка гласит: “Безопасность — это процесс”. Сертификации Описание принципов CIA, изложенное выше, представляет собой всего лишь крат- кое введение в более широкую тему, связанную с безопасностью. Крупные корпорации часто нанимают постоянных сотрудников, работа которых заключается в защите инфор- мации. Для того чтобы поддерживать высокую степень компетентности в этой области, эти профессионалы посещают тренинги и получают сертификаты. Если вам придется ра- ботать с некоторыми из этих сертификатов, приготовьтесь запомнить массу аббревиатура Одним из наиболее широко признанных сертификатов является CISSP (Certified Information Systems Security Professional — сертифицированный специалист по безопас- ности информационных систем). Этот сертификат выдается организацией (ISC)2, пол- ное название которой звучит так: International Information Systems Security Certification Consortium (попробуйте произнести это в десять раз быстрее!). Одной из главных осо- бенностей сертификата CISSP является представление организации (ISC)2 об “общей совокупности знаний” (“common body of knowledge — СВК), которая по существу пред- ставляет собой самые эффективные методы работы в области информационной безопас- ности. Комплекс СВК охватывает законодательство, криптографию, аутентификацию, физическую безопасность и многое другое. Это невероятно авторитетный сертификат в среде специалистов по безопасности. Недостатком сертификата CISSP является излишняя широта охвата и, как следствие, недостаток глубины знаний. В комплекс СВК входит много тем, которые необходимо изучить за короткое время! Для того чтобы решить эту проблему, организация (ISC)2 создала специальные программы CISSP, посвященные архитектуре, технике и управле-
глава 22. Безопасность 991 нию. Эти специализированные сертификаты придают глубину более общему сертифи- кату CISSP. Институт системного администрирования, сетей и безопасности (System Administration, Networking, and Security Institute — SANS Institute) в 1999 году создал на- бор сертификатов Global Information Assurance Certification (GIAC). Три дюжины разных экзаменов охватывают всю область информационной безопасности тестами, разделен- ными на пять категорий. Сертификаты ранжируются по сложности — от умеренного уровня GISF с двумя экзаменами до экспертного уровня GSE с 23-часовым экзаменом. Экзамены на получение сертификата GSE печально известны как самые трудные в дан- ной индустрии. Многие экзамены нацелены на техническое вопросы и требуют доволь- но большого опыта работы. В заключение упомянем мандат сертифицированного аудитора информационных систем (Certified Information Systems Auditor — CI SA), представляющий собой сертифи- кат специалиста по аудиту и процессам, связанным с информационной безопасностью. Курс обучения для получения этого сертификата сосредоточен на бизнес-процессах, процедурах, мониторинге и других вопросах управления. Некоторые специалисты счи- тают сертификат CISA промежуточным и приемлемым для сотрудников, занимающихся безопасностью в организациях. Одним из преимуществ этого сертификата является то, что для его получения достаточно сдать только один экзамен. Несмотря на то что сертификаты выдаются индивидуально, их признание в деловой среде невозможно отрицать. В настоящее время все больше компаний считают сертифи- кат признаком эксперта. Многие компании предлагают таким сотрудникам более высо- кую зарплату и продвигают их по карьерной лестнице. Если вы решили получить сертификат, убедите вашу организацию, чтобы она опла- тила ваше обучение. Стандарты безопасности Возрастающая роль информационных систем привела к появлению законов и указов правительства, регулирующих вопросы защиты конфиденциальной информации. Многие законодательные акты США, такие как HIPAA, FISMA, NERC CIP, и Sarbanes-Oxley Act (SOX), содержат разделы, посвященные информационной безопас- ности. Несмотря на то что иногда удовлетворение этих требований связано с большими затратами, они привлекли внимание к важным аспектам технологии, которые ранее иг- норировались. Ш Более широкое обсуждение промышленных и законодательных стандартов, влияющих на информационные технологии, приведено в разделе 32.9. К сожалению, эти законодательные акты содержат множество юридических терми- нов, которые иногда трудно понять. Большинство из них не содержит никаких указа- ний на то, как удовлетворить сформулированные требования. По этой причине, для того чтобы помочь администраторам выполнить требования закона, были разработаны стандарты. Эти стандарты не являются законодательными актами, но следование этим стандартам обычно обеспечивает согласование с законами. Поскольку сразу все стан- дарты выполнить бывает затруднительно, лучше всего сначала полностью реализовать какой-то один из них.
992 Часть II. Работа в сети ISO 27002 Стандарт ISO/IEC 27002 (бывший ISO 17799) является, вероятно, самым широко признанным в мире. Впервые он был введен в 1995 году как британский стандарт. Тогда он содержал 34 страницы и 11 разделов, которые охватывали широкий круг вопросов — от политических до вопросов физической безопасности и управления доступом. Каждый раздел имел цели, специфичные требования и рекомендации оптимальных практиче- ских решений. Этот документ стоит около 200 долл. Требования не носят технический характер и могут быть выполнены любой органи- зацией самым эффективным способом. С другой стороны, использование общих слов оставляло у читателя ощущение слишком большой гибкости. Критики жаловались на то, что недостаток специфики оставляет организации незащищенными перед атаками. Тем не менее, этот стандарт является одним из наиболее ценных документов в обла- сти информационной безопасности. Он создал мост над пропастью, пролегавшей между вопросами управления и техническими проблемами, и помог обеим сторонам миними- зировать риск. PCI DSS Стандарт Payment Card Industry Data Security Standard (PCI DSS) имеет совершенно другую природу. Он возник вследствие возрастающей потребности повысить безопас- ность обработки кредитных карточек после ряда драматических событий. Например, в июне 2005 года компания CardSystems Services International обнаружила “пропажу” но- меров 40 миллионов кредитных карточек. По оценкам Министерства национальной безопасности США (U.S. Department of Homeland Security) только в 2009 году из-за кражи персональной информации были по- теряны 49,3 млрд долл. Разумеется, не все эти потери могут быть напрямую связаны с потерей номеров кредитных карточек, но возрастающая бдительность разработчиков имела благоприятные последствия. ФБР даже связало поиск мошенников, ворующих номера кредитных карточек, с выявлением террористических групп. Этому способство- вали конкретные инциденты, происшедшие в Бали и мадридском метро. Стандарт PCI DSS является результатом совместных усилий компаний Visa и MasterCard, хотя в данный момент он поддерживается только компанией Visa. В отличие от стандарта ISO 27002, он находится в свободном доступе. Этот стандарт полностью сфокусирован на защите данных о владельцах кредитных карточек и имеет 13 разделов, определяющих требования к этой защите. Поскольку стандарт PCI DSS посвящен обработке карточек, он не является уни- версальным и не подходит для бизнеса, не имеющего дела с кредитными карточками. Однако компании, собирающие данные о кредитных карточках, обязаны строго следо- вать этому стандарту, чтобы избежать крупных штрафов и возможного уголовного пре- следования. Этот документ находится на сайте pcisecuritystandards. org. Документы NIST 800 Сотрудники организации National Institute of Standards and Technology (NIST) разра- ботали рад документов под названием Special Publication (SP) 800, в которых изложили результаты своих исследований, рекомендации и другую информацию, посвященную компьютерной безопасности. Эти документы часто используются для оценки соответ- ствия организаций, имеющих дело с правительственной информацией, требованиям
Глава 22. Безопасность 993 федерального закона США об управлении информационной безопасностью (Federal Information Security Management Act). Это открытые и доступные стандарты. Они имеют превосходное содержание и широко применяются в промышленности. Серия SP 800 содержит более 100 документов. Все они доступны на сайте csrc. nist .gov/publications/PubsSPs .html. Перечислим те из них, с которых целесоо- бразно начинать изучение стандартов, — NIST 800-12, An Introduction to Computer Security: The NIST Handbook; NIST 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems; NIST 800-34 Rl, Contingency Planning Guide for Information Technology Systems; NIST 800-39, Managing Risk from Information Systems: An Organizational Perspective; NIST 800-53 R3, Recommended Security Controls for Federal Information Systems and Organizations; NIST 800-123, Guide to General Server Security. Стандарт Common Criteria Документ Common Criteria for Information Technology Security Evaluation (известный под названием “Common Criteria”) — это стандарт, по которому оценивают уровень безопасности продукции информационных технологий. Эти рекомендации были уста- новлены международным комитетом, состоящим из представителей разных компаний и отраслей промышленности. Для ознакомления с этим документом и сертифицированными продуктами посетите сайт commoncriteriaportal. org. OWASP Open Web Application Security Project (OWASP) — это некоммерческая всемирная ор- ганизация, занимающаяся повышением безопасности прикладного программного обе- спечения. Она хорошо известна благодаря своему списку “top 10”, посвященному рискам веб- приложений и предназначенному для повышения бдительности разработчиков. Текущую версию этого списка и массу других материалов можно найти на сайте о wasp. org. 22.16. Источники ИНФОРМАЦИИ ПО ВОПРОСАМ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ В битве за безопасность системы половина успеха — знание современных разрабо- ток в этой области. Если система оказалась взломанной, это вряд ли стало следствием применения технологической новинки. Скорее всего, маленькая брешь в броне системы широко обсуждалась в какой-нибудь телеконференции или группе новостей. Организация CERT В связи с бурной реакцией общественности на вторжение интернет-“червя”, соз- данного Робертом Моррисом-младшим (Robert Morris, Jr.) в 1988 году, организация DARPA (Defense Advanced Research Projects Agency — Управление перспективных иссле- довательских программ Министерства обороны США) учредила новую структуру: CERT (Computer Emergency Response Team — группа компьютерной “скорой помощи”). В ее обязанности входит сбор информации, касающейся компьютерной безопасности. До сих пор это наиболее известный консультативный орган, хотя со временем он стал весь- ма медлительным и бюрократичным. Более того, в самой организации сейчас настаива-
994 Часть II. Работа в сети ют на том, что ее название не означает ничего кроме “зарегистрированной служебной марки университета Карнеги-Меллона”. В средине 2003 года организация CERT заключила договор о партнерстве с Управ- лением компьютерной безопасности Министерства национальной безопасности США (Department of Homeland Security’s National Cyber Security Division, NCSD). Непонятно, к лучшему или к худшему, но новая организация изменила структуру списков рассылки. Объединенная организация под названием US-CERT предлагает четыре списка рас- сылки. Самым полезным среди них является “Technical Cyber Security Alerts”. Подпи- саться на любой из этих четырех списков рассылки можно на сайте forms . us-cert. gov/maillists. Сервер SecurityFocus.com и список рассылки BugTraq Сервер SecurityFocus. com специализируется на сборе новостей и различной ин- формации по вопросам безопасности. В новостях публикуются как общие обзоры, так и статьи, посвященные конкретным проблемам. Есть также обширная библиотека по- лезных документов, удобно отсортированных по тематике. Программный архив сервера содержит инструментальные средства для множества операционных систем. Программы снабжаются аннотациями и пользовательскими рей- тингами. Это наиболее глобальный и исчерпывающий из известных нам архивов подоб- ного рода. Список рассылки BugTraq — это форум для обсуждения проблем безопасности и путей их устранения. Для того чтобы подписаться на него, посетите страницу securityfocus. com/archive. Объем информации, рассылаемый по списку, может оказаться довольно значительным, и отношение “сигнал-шум” довольно плохое. На веб-узле также хранит- ся база данных с отчетами о рассмотренных в форуме BugTraq проблемах. Блог Брюса Шнайера Блог Брюса Шнайера (Bruce Schneier), посвященный вопросам безопасности, яв- ляется ценным и иногда забавным источником информации о компьютерной безопас- ности и криптографии. Кроме того, Шнайер является автором широко известных книг Applied Cryptography и Secrets and Lies, Информацию с его блога можно получать в виде ежемесячного бюллетеня под названием Grypto-Gram. Более подробную информацию вы найдете на сайте schneier.com/crypro-gram.html. Организация SANS SANS (System Administration, Networking, and Security Institute — институт системного и сетевого администрирования и проблем безопасности) — это профессиональная орга- низация, которая спонсирует конференции и обучающие семинары, посвященные во- просам безопасности, а также публикует различную информацию по данной тематике. Ее сайт sans. org является ценным информационным ресурсом, занимающим проме- жуточное положение между сайтами SecurityFocus и CERT; он не столь исчерпывающий, как первый, но и не такой скудный, как второй. Организация SANS рассылает по электронной почте ряд еженедельных и ежемесяч- ных бюллетеней, на которые можно подписаться на ее веб-узле.
Глава 22. Безопасность 995 Информационные ресурсы отдельных дистрибутивов Проблемы, касающиеся безопасности, очень влияют на репутацию, поэтому постав- щики операционных систем остро заинтересованы в том, чтобы помочь пользователям сделать свои системы безопасными. Многие крупные поставщики ведут собственные списки рассылки и публикуют в них бюллетени по вопросам безопасности. Эта же ин- формация часто доступна и на веб-узлах. Не редкость, когда защитные “заплаты” рас- пространяются бесплатно, даже если поставщики обычно взимают плату за программ- ную поддержку. В Интернете есть веб-порталы, например SecurityFocus.com, на которых содер- жится информация, касающаяся конкретных производителей, и имеются ссылки на по- следние официальные пресс-релизы. ©Разработчики системы Ubuntu поддерживают список рассылки, посвященный вопросам безопасности, по адресу: https://lists.ubintu.com/mailman/listinfo/ubuntu-security-announce Рекомендации по поводу защиты SuSE можно найти по адресу: ** novell.com/linux/security/securitysupport.html Для того чтобы подписаться на официальный список рассылки, посвященный во- просам безопасности SuSE, посетите страницу suse.com/en/private/support/online_help/mailinglists/index.html ... Объявления о продуктах компании Red Hat, связанных с безопасностью, рассылаются по списку “Enterprise watch”, который расположен по адресу: ’redhat.com/mailman/listinfo/enterprise-watch-list. * Несмотря на то что компания Sun Microsystems была приобретена компанией soians Oracle, ее блог, посвященный вопросам безопасности, продолжает обновлять- ся (blogs . sun. com/security/category/alerts). Когда торговая Марка и местоположение блога изменятся, вероятно, вы найдете там необходи- мую ссылку. Д°СТУП к предложениям компании HP можно получить с помощью сайтов us-support.external.hp.com (для Америки и Азии) и europe-support. external. hp. com (для Европы). Информация, связанная с обеспечением безопасности, тщательно скрыта. Для того чтобы найти ее, войдите в область maintenance/support и выберите пункт поиска по базе технических знаний. Ссылка, находящаяся среди опций фильтра на этой странвде, приведет вас к архиву бюллетеней по вопросам безопасности. (Если вы не зарегистри- рованы, придется это сделать.) В этой области можно также найти “заплаты” для систем безопасности. Для того чтобы получать бюллетени по вопросам безопасности, вернитесь на глав- ную страницу в область maintenance/support и выберите пункт “Subscribe to proactive notifications and security bulletins”. К сожалению, по электронной почте подписаться не получится. • Подписаться на уведомления по вопросам безопасности системы AIX мож- но с помощью ссылки “Му notifications” на странице ibm.com/systems/ support.
996 Часть II. Работа в сети Информация о безопасности продуктов Cisco распространяется в виде практических замечаний, список которых находится по адресу cisco.com/public/support/tac/ fn index.html. Для того чтобы подписаться на список рассылки, посвященный во- просам безопасности продуктов Cisco, направьте письмо по адресу ma jordomo@cisco. сот, включив в тело сообщения строку “subscribe cust-security-announce”. другие списки рассылки и веб-сайты Перечисленные выше контактные адреса — лишь небольшая часть интернет-ресурсов по вопросам безопасности. Учитывая объем имеющейся сегодня информации, а также скорость, с которой появляются и исчезают различные ресурсы, мы посчитали целесоо- бразным указать несколько “метаресурсов”. Хорошей стартовой площадкой является веб-узел linuxsecurity.com, на котором каждый день размещается несколько сообщений по вопросам безопасности системы Linux. Он также содержит постоянно обновляющуюся коллекцию советов по вопросам безопасности системы Linux, регистрирует происходящие события и поддерживает ра- боту групп пользователей. (IN)SECURE — это свободно распространяемый двумесячный журнал, содержащий информацию о современных тенденциях, а также интервью с выдающимися специали- стами в области безопасности. Правда, некоторые статьи в этом журнале следует читать с долей недоверия — убедитесь, что ее автор не занимается беззастенчивой рекламой своей продукции. Сайт Linux Security (linuxsecurity.com) освещает последние новости, касающие- ся системы Linux и вопросов безопасности открытых кодов. Для того чтобы извлечь из него максимальную выгоду, подпишитесь на канал RSS. Linux Weekle News — это симпатичный источник информации о ядре, безопасности, дистрибутивных пакетах и других вопросах. Раздел, посвященный проблемам безопас- ности, находится по адресу lwn. net/security. 22.17. Что нужно делать в случае атаки на сервер Прежде всего, не паникуйте! Скорее всего, к моменту обнаружения взлома большая часть ущерба уже нанесена. Возможно, хакер “гулял” по системе несколько недель или даже месяцев. Вероятность того, что вам удалось выявить факт взлома, происшедшего всего час назад, близка к нулю. В свете этого мудрая сова приказывает сделать глубокий вдох и начать тщательно продумывать стратегию устранения взлома. Старайтесь не вспугнуть злоумышленника, во всеуслышание заявляя о происшествии или выполняя действия, которые могут на- сторожить того, кто наблюдал за деятельностью организации на протяжении нескольких недель. Подсказка: в этот момент неплохо выполнить резервное копирование. Надеемся, это не удивит нарушителя?!13 Стоит также напомнить самому себе о том, что, согласно исследованиям, в 60% ин- цидентов, связанных с нарушением безопасности, присутствовал “внутренний враг”. Не изучив всех фактов, старайтесь не посвящать в проблему лишних людей, кем бы они ни были. Приведем короткий план, который поможет администратору пережить кризис. 13 Если создание резервных копий не является “нормальным” действием в вашей организации, то обнаружение взлома окажется самой незначительной из ожидающих вас проблем.
Глава 22. Безопасность 997 Этап 1: не паникуйте. Во многих случаях проблема обнаруживается только спустя какое-то время. Еще один-два часа или дня уже ничего не решают. Однако имеет значе- ние реакция на событие — паническая или рациональная. Часто в результате возникшей паники ситуация только усугубляется уничтожением важной информации, которая по- зволяет выявить нарушителя. Этап 2: определите адекватную реакцию. Никому не выгодно раздувать инцидент. Будьте благоразумны. Решите, кто из персонала будет участвовать в решении возникшей проблемы и какие ресурсы при этом должны быть задействованы. Остальные будут по- могать осуществлять “вынос тела”, когда все закончится. Этап 3: соберите всю возможную информацию. Проверьте учетные и журнальные фай- лы. Попытайтесь определить, где первоначально произошел взлом. Выполните резерв- ное копирование всех систем. Убедитесь в том, что резервные ленты физически защи- щены от записи, если вы вставляете их в дисковод для чтения. Этап 4: оцените нанесенный ущерб. Определите, какая важная информация (если та- ковая имеется) “покинула” компанию, и выработайте подходящую стратегию смягчения возможных последствий. Оцените степень будущего риска. Этап 5: выдерните шнур. Если это необходимо и возможно, отключите “взломанные” компьютеры от сети. Перекройте обнаруженные “дыры”. Организация CERT предлагает инструкции по обнаружению взлома. Этот документ находится по адресу: cert.org/tech_tips/win-UNIX-system_compromise.html Этап 6: разработайте стратегию восстановления. Соберите толковых людей и обсуди- те план восстановления. Не заносите его в компьютер. Сосредоточьтесь на том, чтобы потушить “пожар” и свести ущерб к минимуму. Избегайте обвинений в чей-либо адрес или нагнетания обстановки. Не забывайте о психологическом ударе, который могут ис- пытать пользователи. Этап 7: сообщите о своем плане. Расскажите пользователям и управляющему персона- лу о последствиях взлома, возможных будущих проблемах и предварительной стратегии восстановления. Будьте честны и откровенны. Инциденты, связанные с безопасностью, являются неотъемлемой частью современных сетей. Это не отражение ваших способно- стей как системного администратора или чего-то другого, чего можно было бы стыдить- ся. Открытое признание возникшей проблемы — 90% победы, если при этом вы демон- стрируете, что у вас есть план выхода из ситуации. Этап 8: воплотите план в жизнь. Вы знаете свои системы и сети лучше, чем кто бы то ни было. Доверьтесь плану и инстинктам. Посоветуйтесь с коллегами из других органи- заций, чтобы убедиться в правильности выбранного направления. Этап 9: сообщите об инциденте в соответствующие органы. Если в инциденте участво- вал “внешний игрок”, сообщите об этом случае в организацию CERT. Соответствующий адрес электронной почты — cert@cert. org. Предоставьте им как можно больше ин- формации. Стандартная форма для отчета находится на веб-узле cert. org. Ниже приведен спи- сок того, что желательно включить в отчет. • имена, модели “взломанных” компьютеров, а также установленные на них опера- ционные системы; • список “заплат”, которые были установлены в системе на момент инцидента; • список учетных записей, подвергшихся нападению; • имена и IP-адреса всех удаленных компьютеров, вовлеченных в инцидент;
998 Часть II. Работа в сети • контактная информация, если известны администраторы удаленных систем; • соответствующие журнальные записи и учетные данные. Если есть подозрение, что вами обнаружена ранее неизвестная проблема в программ- ном обеспечении, следует также сообщить об этом компании-разработчику. 22.18. Рекомендуемая литература • Barrett, Daniel J., Siverman Richard E., Byrnes Robert G. “Linux Security Cookbook”. Sebastobol, CA: O’Reilly Media, 2003. • Bauer Michael D., “Linux Server Security (2nd Edition). Sebastobol, CA: O’Reilly Media, 2005. • Bryant, William. “Designing an Authentication System: a Dialogue in Four Scenes.” 1988; web.mit.edu/kerberos/www/dialogue.html. • Cheswick William R., Bellovin Steven M., Rubin Aviel D. “Firewalls and Internet Security: Repelling the Wily Hacker (2nd Edition). Reading, MA: Addison-Wiley, 2003. • Curtin Matt, Ranum Marcus, Robinson P.D. “Internet Firewalls: Frequently Asked Quetions”, 2004; interhack.net/pubs/fwfaq. • Farrow Rick, Power Richard “Network defence article series”, 1998—2004; spirit. com/Network. • Fraser B. (Ed.) “RFC2196: Site Security Handbook.” 1997; rfc-editor.org. • Garfinkel Simson, Spafford Gene, Schwartz Alan. “Practical UNIX and Internet Security (3rd Edition). Sebastobol, CA: O’Reilly Media, 2003. • Kerby Fred et. al. SANS Intrusion Detection and Response FAQ”. SANS. 2009; sans. org/resources/idfaq. • Lyon Gordon Fyodor. “Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning”. Nmap Project, 2009. • Mann Scott, Mitchell Ellen I. “Linux System Security: The Administrator’s Guide to Open Source Security Tools (2nd Edition). Upper Saddle River, NJ: Prentice Hall PTR, 2002. • Morris Robert, Thompson Ken. “Password Security: A Case History”. Communications pf the ACM, 22 (11): 594—597, November, 1979. Reprinted in “Unix System Manager's Manual”, 4.3 Berkeley Software Distribution. Universityof California, Berkeley, April 1986. • Ritchie, Dennis M. “On the Security of UNIX.” May 1975. Перепечатано в UNIX System Manager's Manual, 4.3 Berkeley Software Distribution. University of California, Berkeley. April 1986. • Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. New York, NY: Wiley, 1995. • Steves K. “Building a Bastion Host Using HP-UX 11”. HP Consulting, 2002; tinyurl. com/5sffy2. • Thompson, Ken. “Reflections on Trusting Trust.” Опубликовано в ACM Turing Award Lectures: The First Twenty Years 1966-1985. Reading, MA: ACM Press (Addison-Wesley), 1987.
Глава 22. Безопасность 999 22.19. Упражнения 22.1. Каковы преимущества SSH-аутентификации с использованием паролей Linux по сравнению с SSH-аутентификацией посредством идентификационного пароля и пары ключей. Если один из методов обеспечивает большую безопасность, обяза- тельно ли переходить на него? 22.2. * Туннели SSH часто являются единственным средством передачи трафика на удаленный компьютер, к которому у вас нет административного доступа. Прочтите man-страницу команды ssh и составьте команду, которая организует туннельную пересылку трафика с порта 113 локального компьютера на порт 113 узла mail. remotenetwork.org. Точкой перенаправления туннеля тоже должен быть узел mail.remotenetwork.org. 22.3. ★ Проанализируйте один из последних преданных огласке инцидентов, связан- ных с компьютерной безопасностью. Найдите соответствующие “заплаты” или способы защиты компьютеров вашей лаборатории. Укажите, какими источниками информации вы пользовались и какие действия следует предпринять для защиты системы. 22.4. Предварительно получив разрешение от администратора, инсталлируйте ути- литу John the Ripper, которая ищет учетные записи со “слабыми” паролями. а) модифицируйте исходный код этой утилиты, чтобы она отображала только ре- гистрационные имена, но не пароли. б) примените утилиту John the Ripper к файлу паролей вашей лаборатории (по- требуется получить доступ к файлу /etc/shadow) и посмотрите, сколько паро- лей она сможет взломать. в) задайте собственный пароль в виде слова из словаря и заставьте утилиту john проверить только вашу запись файла /etc/shadow. Сколько времени ушло на взлом пароля? г) попробуйте разные варианты написания (с заглавной буквы, с цифрой в кон- це, однобуквенный пароль и так далее) и оцените возможности утилиты. 22.5. Выберите два компьютера в лаборатории и назначьте один из них мишенью, а второй — зондом. 22.6. Инсталлируйте на зондирующем компьютере утилиты nmap и Nessus и попытай- тесь атаковать компьютер-мишень. Как можно обнаружить факт атаки? 22.7. Создайте на компьютере-мишени брандмауэр с помощью команды iptables для защиты от этих атак. Можно ли теперь обнаружить факт атаки? Как именно? 22.8. Какими дополнительными средствами защиты можно воспользоваться? (Необходим доступ с правами суперпользователя.) 22.9. Используя общие списки рассылки или веб-сайт, идентифицируйте приложе- ние, которое недавно обнаружило уязвимость. Найдите надежный источник ин- формации о “лазейке” и обсудите пути ее устранения. 22.10. Программы с установленным битом SETUID часто являются необходимыми. А вот SETUID-сценариев интерпретатора команд следует избегать. Почему? 22.11. Используя команду tcpdump, перехватите трафик службы FTP в активном и пассивном режимах. Как необходимость поддерживать анонимный сервер FTP
1000 Часть II. Работа в сети влияет на функционирование брандмауэра? Что именно должны разрешить пра- вила брандмауэра? (Необходим доступ с правами суперпользователя.) 22.12. Что разрешают и запрещают показанные ниже правила, сообщаемые коман- дой iptables? Что можно сделать для повышения безопасности такой системы? (Подсказка: цепочки output и forward можно расширить.) Chain INPUT target prot block all (policy ACCEPT) opt source anywhere destination anywhere Chain FORWARD (policy ACCEPT) target prot opt source all — anywhere destination anywhere Chain OUTPUT target prot (policy ACCEPT) opt source destination Chain block (1 references) target prot opt source destination ACCEPT all ESTABLISHED — anywhere anywhere state RELATED, ACCEPT tcp — anywhere anywhere state NEW tcp dpt:www ACCEPT tcp — anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp — 128.138.0. .0/16 anywhere state NEW tcp dpt: kerberos ACCEPT icmp — anywhere anywhere DROP all anywhere anywhere 22.13. Проанализируйте цепочки правил вашего брандмауэра. Какие стратегии за- щиты они выражают? Все ли надежно в такой системе? (Выполнение этого упраж- нения может потребовать взаимодействия с администраторами, отвечающими за безопасность организации.) 22.14. Напишите программу, которая находит сетевые интерфейсы, работаю- щие в “беспорядочном” режиме. Регулярно запускайте эту программу для раннего обнаружения попыток вторжения в сеть. Какую нагрузку на сеть создает програм- ма? Ее нужно запускать на каждом компьютере или достаточно одного? Можете ли вы составить такой пакет, который сообщит о том, что интерфейс находился в “беспорядочном” режиме? (Необходим доступ с правами суперпользователя.)
Глава 23 Веб-хостинг В настоящее время системы UNIX и Linux являются основными платформами для обслуживания веб-содержимого и веб-приложений. Это идеальные системы для этой цели, поскольку они изначально были разработаны как многозадачные системы с вы- теснением (preemptive, multitasking systems). Они могут обрабатывать огромный объем веб-запросов и делать это эффективно, безопасно и надежно. В некоторых аспектах веб-приложения действительно облегчили работу администра- торов. Технологии “Web 2.0”, такие как AJAX (Asynchronous JavaScript and XML) и дина- мический HTML, не только предоставили пользователям функциональные возможности локально инсталлированных приложений, но и освободили системных администрато- ров от проблем, связанных с развертыванием программного обеспечения; из всего про- граммного обеспечения на клиентской стороне требуется лишь веб-браузер. На серверной стороне типичной конфигурацией является высоко функциональный стек LAMP (Linux, Apache, MySQL и PHP/Perl/Python)1. Для приложений, связанных с управлением базами данных, популярные веб-приложения с открытым кодом основаны на языке Ruby. Оба стека являются разумным выбором и легко поддерживаются. 23.1. Основы ВЕБ-ХОСТИНГА Хостинг веб-узла мало чем отличается от других сетевых услуг. Демон прослушивает TCP-порт с номером 80 (в соответствии со стандартом HTTP), принимает запросы на выдачу документов, а затем посылает эти документы пользователю. Многие из этих 1 Дистрибутивные пакеты, не содержащие операционную систему Linux, называют эту конфи- гурацию просто АМР. В системе Solaris она называется SAMP, а в среде пользователей системы Windows — WAMP. Поди разбери.
1002 Часть II. Работа в сети документов генерируются “на лету” во взаимодействии с базами данных и прикладными каркасами, но для основного протокола HTTP это не характерно. Обнаружение ресурсов в сети веб Информация в Интернете организована с помощью архитектуры, определенной ор- ганизацией Internet Society (ISOC). Это целеустремленная (хотя и управляемая комите- тами) организация, которая поддерживает согласованную работу и операционную со- вместимость в Интернете. £3 Информацию об организации Internet Society можно найти в разделе 14.1. Организация ISOC определяет три способа идентификации ресурсов: унифициро- ванные идентификаторы ресурсов (Uniform Resource Identifier — URI), унифицирован- ные указатели ресурсов (Uniform Resource Locator — URN) и унифицированные име- на ресурсов (Uniform Resource Names — URN). Как показано на рис. 23.1, по существу, унифицированные указатели и имена ресурсов представляют собой частный случай уни- фицированного идентификатора ресурсов. Рис. 23.1. Классификация унифицированных идентификаторов ресурсов В чем же различия между ними? • Унифицированные указатели ресурсов сообщают вам, как найти ресурс, описывая его механизм первичного доступа (например, http: / /admin. com). • Унифицированные имена ресурсов идентифицируют (“называют”) ресурс без указания на него или сообщают, как получить доступ к нему (например, urn: isbn: 0-13-020601-6). Что же тогда называется URI? Если доступ к ресурсу возможен только через Интер- нет, то используется указатель URL. Если же доступ к ресурсу возможен не только через Интернет, но и с помощью других средств, то используется идентификатор URL Унифицированные указатели ресурсов Большую часть времени мы работаем с указателями URL, описывающими доступ к объекту с помощью пяти базовых компонентов. • Протокол или приложение • Имя узла • Порт TCP/IP (необязательно) • Каталог (необязательно) • Имя файла (необязательно) В табл. 23.1 перечислены протоколы, которые наиболее часто упоминаются в URL- адресах.
Глава 23. Веб-хостинг 1003 Таблица 23.1. Протоколы URL-адресов Протокол file Доступ к локальному файлу (выход в Интернет file://etc/syslog.conf не осуществляется) ftp http https Idap mailto Доступ к файлам по протоколу FTP ftp://ftp.admin.com/adduser.tar.gz Доступ к файлам по протоколу HTTP http://admin.com/index.html Доступ к файлам по протоколам HTTP/SSL https://admin.com/order.shtml Доступ к службе каталогов LDAP ldap://ldap.bigfoot.com:389/cn=Herb Отправка электронного сообщения по указан- mailto:sa-book@admin.com ному адресу Принцип работы HTTP HTTP — это клиент-серверный протокол, не хранящий информацию о состоянии сеанса. Клиент запрашивает у сервера “содержимое” заданного URL-адреса. Сервер дт- вечает, передавая поток данных или возвращая сообщение об ошибке. Затем клиент мо- жет запросить следующий объект. Поскольку протокол HTTP настолько прост, можно легко подключиться к веб-бра- узеру с помощью утилиты telnet. Для этого достаточно подключиться к порту 80 вы- бранного веб-сервера. После установления соединения сервер готов принимать НТТР- команды. Чаще всего используется команда GET, которая запрашивает содержимое документа. Обычно она задается в формате GET /. В этом случае возвращается корневой документ сервера (как правило, начальная страница). Протокол HTTP чувствителен к регистру символов, поэтому команды следует набирать прописными буквами. $ telnet localhost 80 Trying 127.0.0.1. . . Connected to localhost.atrust.com. Escape character is ,A] ’. GET I <далее следует содержимое файла, заданного по умолчания» Connection closed by foreign host. Более “полный” HTTP-запрос должен включать номер версии протокола HTTP, за- прашиваемый узел (необходимый для того, чтобы извлечь файл из виртуального узла, использующего имена) и другую информацию. В этом случае ответ, помимо возвращае- мых данных, содержит информативные заголовки. $ telnet localhost 80 Trying 127.0.0.1. . . Connected to localhost.atrust.com. Escape character is ,A] ’ . GET / HTTP/1.1 Host: www.atrust.com HTTP/1.1 200 OK Date: Sat, 01 Aug 2009 17:43:10 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Sat, 01 Aug 2009 16:10:22 GMT Content-Length: 7044 Content-Type: text/html
1004 Часть II. Работа в сети сдалее следует содержимое файла, заданного по умолчании» Connection closed by foreign host. В данном случае мы сообщили серверу, что собираемся передавать данные по прото- колу НТТ версии 1.1, и назвали виртуальный узел, у которого мы запрашиваем инфор- мацию. Сервер вернул нам код состояния (НТТР/1.1 200 ОК), текущую дату и время, имя и версию программного обеспечения, на котором выполняется протокол, дату по- следнего изменения запрашиваемого файла и содержимое запрашиваемого файла. Ин- формация заголовка отделена от содержимого одной пустой строкой. Генерирование содержимого "на лету" Помимо работы со статическими документами, HTTP-сервер способен выдавать пользователям страницы, формируемые “налету”. Например, если требуется отобра- зить текущие время и температуру, сервер вызывает сценарий, предоставляющий эту информацию. Такие сценарии зачастую создаются средствами CGI (Common Gateway Interface — единый шлюзовой интерфейс). CGI является не языком программирования, а, скорее, спецификацией, описываю- щей обмен информацией между HTTP-сервером и другими программами. Чаще всего CGI-сценарии представляют собой программы, написанные на языке Perl, Python или PHP. В действительности подойдет практически любой язык программирования, кото- рый поддерживает операции ввода-вывода в режиме реального времени. Встроенные интерпретаторы Модель CGI обеспечивает высокую гибкость, благодаря которой разработчик веб- приложения может свободно использовать любой интерпретатор или язык сценариев. К сожалению, запуск отдельного процесса в каждом сценарии может стать ночным кошмаром для загруженного веб-сервера, обрабатывающего значительный объем дина- мического содержания. Кроме поддержки дополнительных внешних сценариев CGI, многие веб-серверы < определяют модульную архитектуру, позволяющую интерпретаторам сценариев, таким j как Perl и РНР, самим встраиваться в веб-сервер. Это связывание значительно увеличи- вает производительность, поскольку веб-сервер больше не обязан запускать отдельный процесс, чтобы обрабатывать каждый запрос сценария. Архитектура, большей частью, скрыта от разработчиков сценариев. Как только сервер видит файл, имя которого за- канчивается специфическим расширением (например, .pl или .php), он посылает со- держимое файла встроенному интерпретатору для выполнения. Некоторые интерпрета- торы, которые могут выполняться внутри веб-сервера Apache, перечислены в табл. 23.2. Таблица 23.2. Модули встроенных сценариев для веб-сервера Apache Язык . Имя встроенного интерпретатора Источник информации Perl mod_perl perl.apache.org Python mod_python modpython.org PHP mod_php (традиционно) Zend server (коммерческий ускоритель) apache.org zend.com Ruby on Rails Phusion Passenger (он же mod jails или mod jack) modrails.com
Глава 23. Веб-хостинг 1005 Модуль FastCCI В некоторых ситуациях удобно использовать модуль FastCGI (fastcgi. com). Этот модуль улучшает производительность сценариев, запуская их один раз, а затем оставляя выполняться для обслуживания многих запросов. Такая схема снижает стоимость запу- ска интерпретатора и анализа сценария при выполнении нескольких запросов. Иногда она работает быстрее, чем запуск интерпретатора внутри самого веб-сервера Apache. К сожалению, в этом случае сценарии приходится модифицировать, чтобы они со- ответствовали новому способу взаимодействия с веб-сервером. Основной протокол реа- лизовать легко, но сценарии FastCGI не могут избежать погрешностей при управлении памятью. Неудачные завершения сценариев оставляют в памяти следы, количество кото- рых со временем возрастает. Другая потенциальная опасность заключается в персистент- ности данных между выполнением запросов; программист должен гарантировать, что эти данные не будут взаимодействовать друг с другом. Разработчики веб-приложений должны оценить, стоит ли повышение производительности за счет сценариев FastCGI дополнительных усилий и риска. Безопасность сценариев Как правило, CGI-сценарии интересуют веб-разработчиков и программистов. Одна- ко один из аспектов сценариев не обходит стороной и системных администраторов — безопасность. Поскольку CGI-сценарии получают доступ к файлам, сетевым соедине- ниям и прочим механизмам перемещения данных, выполнение этих сценариев несет потенциальную угрозу компьютеру, на котором инсталлирован HTTP-сервер. Ведь CGI- сценарий или надстройка позволяет любому пользователю выполнять программы на сервере. Поэтому CGI-сценарии должны подчиняться тем же правилам безопасности, что и другие сетевые программы. Сайт OWASP (Open Web Application Security Project, owasp. org) публикет массу пре- восходных материалов о веб-безопасности. Общую информацию по вопросам безопас- ности можно найти в главе 22. Серверы приложений Сложные промышленные приложения могут требовать больше функциональных возможностей, чем может предоставить базовый НТТ-сервер. Например, современные страницы Web 2.0 часто содержат компоненты, связанные с динамическими котиров- ками (например, биржевым аппаратом). Несмотря на то что на веб-сервере Apache эту функциональную возможность можно реализовать с помощью таких технологий, как AJAX и JavaScript Object Notation (JSON), некоторые разработчики предпочитают более богатые языки, такие как Java. Обычно для взаимодействия приложения, написанного на языке Java, с другими источниками данных на предприятии используется “сервлет”. Сервлеты (servelet) — это программы, которые выполняются на сервере прикладных программ поверх его платформы. Серверы прикладных программ могут работать не- зависимо или в сочетании с веб-сервером Apache. Большинство серверов прикладных программ разрабатывается “программистами для программистов” и не имеет достаточно мощного механизма отладки, необходимого системным администраторам. В табл. 23.3 перечислены некоторые серверы прикладных программ для систем UNIX/Linux. Если вам придется столкнуться с необходимостью поддержки одного из этих серве- ров прикладных программ, поищите документацию, описывающую программы, и по-
1006 Часть II. Работа в сети тренируйтесь. Поверьте нам, это не та технологию, которую можно освоить “на ходу”, как большинство приложений для систем UNIX и Linux. Мы вас предупредили. Таблица 23.3. Модули встроенных сценариев для веб-сервера Apache Сервер тив3 Tomcat Открытый код tomcat.apache.org GlassFish Открытый код grassfish.dev.j ava.net JBoss Открытый код jboss.org 0CJ4 Коммерческий oracle.com/technology/tech/j ava/oc4j WebSphere Коммерческий ibm.com/websphere WebLogic Коммерческий oracle.com/appserver/weblogic/weblogic-suite.html Jetty Открытый код eclipse.org/j etty Распределение нагрузки Довольно трудно предсказать, сколько обращений (запросов к одному объекту, тако- му как текстовый файл или изображение) либо операций просмотра страниц (запросов всех объектов на одной просматриваемой странице) может обработать сервер за единицу времени. Все зависит от операционной системы, ее настройки, аппаратной платформы, а также от организации веб-узла (например, содержатся ли там статические HTML-стра- ницы или выполняются запросы к базе данных и математические вычисления). Только непосредственное определение производительности и уточнение фактических параметров узла, использующего реальное аппаратное обеспечение, позволят ответить на этот вопрос. Иногда подсказку могут дать разработчики, создающие аналогичные узлы с помощью аналогичного аппаратного обеспечения. Но ни в коем случае не стоит пола- гаться на числа, указываемые поставщиками коммерческих систем. Кроме того, следу- ет помнить о том, что одним из основных факторов является пропускная способность. Отдельная машина, обслуживающая статические HTML-файлы и изображения, может легко выдать столько данных, чтобы вызвать перегрузку канала типа ОСЗ (155 Мбайт/с). Иначе говоря, вместо показателя производительности одного сервера лучше сосре- доточиться на показателе масштабируемости; перед перегрузкой интерфейса Ethernet веб-сервер обычно интенсивно использует центральный процессор или механизм ввода- вывода. Убедитесь в том, что вы и ваша команда веб-дизайнеров работаете по плану, ко- торый позволяет распределять нагрузку узла между несколькими серверами. Распределение нагрузки повышает как производительность работы, так и избыточ- ность. Существует несколько различных подходов к распределению нагрузки: круговая система DNS, аппаратное распределение нагрузки и программное распределение на- грузки. Круговая система DNS — это простейшая форма распределения нагрузки. В этой си- стеме нескольким IP-адресам назначается одно имя узла. Когда на сервер имен поступа- ет запрос к веб-серверу с заданным IP-адресом, клиент получает в ответ один 1Р-адрес. Адреса обрабатываются один за другим в круговой последовательности. Ш Информация о системе DNS и ее функционировании изложена в главе 17. Круговая система DNS используется очень широко. Она применяется даже компа- нией Google. Например, если вы пошлете инфраструктуре DNS запрос о сервере www. google. com, то получите в ответ примерно такие записи.
Глава 23. Веб-хостинг 1007 $ dig www.google.com а ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 0 www.1.google.com. www.1.google.com. www.1.google.com. www.1.google.com. www.1.google.com. www.1.google.com. IN CNAME www.1.google.com. 65 IN A 74.125.95.104 65 IN A 74.125.95.105 65 IN A 74.125.95.106 65 IN A 74.125.95.147 65 IN A 74.125.95.99 65 IN A 74.125.95.103 В данном примере имя www.google.com отображается в каноническое имя www. 1.google. com. Компания Google добавляет этот уровень косвенной адресации, чтобы делегировать ответственность за доставку содержимого внутреннему провайдеру, например Akamai (см. раздел 23.6), не предоставляя управления содержанием (CDN) своему корневому домену. Клиент DNS может выбрать любую из записей А, возвращенных для сайта www. 1. google. com. Предполагается, что это делается случайным образом. В противополож- ность общепринятому мнению, порядок, в котором возвращаются записи А, значения не имеет. В частности, первая запись не является “главной”. Поскольку клиенты выби- рают адрес случайно, нагрузка на этот сайт примерно равномерно распределяется между шестью серверами. Недостатком круговой системы DNS является то, что в случае отказа сервера данные DNS необходимо обновить, чтобы можно было перенаправить трафик в обход. Длинные тайм-ауты, связанные с записями А, могут сделать эту операцию сложной и ненадеж- ной. С другой стороны, короткие тайм-ауты мешают кешированию и замедляют поиск сайта в системе DNS, затрачивая дополнительные ресурсы. Обсуждение этой проблемы изложено в разделе 17.2. В приведенном выше примере записи А можно кешировать за 65 секунд до истече- ния срока их действия. Это относительно короткий тайм-аут. Если в вашем распоряже- нии есть резервный сервер, можно установить более длинные тайм-ауты для записей А и просто переназначить IP-адрес поврежденного сервера на резервный сервер. Аппаратное распределение трафика является довольно простой альтернативой кру- говой системе DNS, но оно требует наличия резервного кеша. К аппаратному обеспече- нию, предназначенному для распределения нагрузки, относятся Big-IP Controller ком- пании F5 Networks, веб-коммутаторы Alteon компании Nortel и коммутаторы Content Services Swithes компании Cisco. Эти устройства ориентируются на параметры, задавае- мые администратором, в частности на время отклика отдельного сервера и время до- ступности. Благодаря распределению нагрузки увеличивается производительность и от- казоустойчивость сети. Программное распределение нагрузки не требует использования аппаратного обеспе- чения; эти программы можно запускать в системе UNIX. Существуют как открытые, так и коммерческие программы для распределения нагрузки. К программам с открытым ко- дом относятся Linux Virtual Server (linuxvirtualserver. org) и модуль для распределе- ния нагрузки между прокси-серверами (mod_proxy_balancer), внедренный на веб-сервере Apache 2.2. Примером коммерческого продукта является программа Zeus (zeus.com). Компания Google на самом деле использует сочетание круговой DNS-системы и ап- паратного распределения нагрузки. Более подробно этот механизм описан в Википедии в статье “Google platform”.
1008 Часть II. Работа в сети Помните, что в настоящее время большинство сайтов генерируется автоматически. Эта архитектура предусматривает колоссальную нагрузку на серверы баз данных. При необходимости проконсультируйтесь у администратора ваших баз данных, как лучше организовать распределение нагрузки между многими серверами баз данных. 23.2. Инсталляция НТТР-сервера Установить и поддерживать веб-сервер очень просто! Веб-службы значительно уступа- ют системам электронной почты и службе DNS в плане сложности администрирования. Выбор сервера Существует несколько HTTP-серверов, но чаще всего используют сервер Apache, ко- торый отличается высокой гибкостью и производительностью. По состоянию на январь 2010 года, 54% веб-серверов в Интернете работали под управлением Apache, обслуживая 111 миллионов сайтов. Среди остальных сайтов 24% обслуживаются серверами Microsoft. Это распределение рыночных долей между серверами Apache и Microsoft на протяжении последних пяти лет практически не изменилось. Более подробную информацию о ры- ночных долях этих веб-серверов можно найти на сайте news.netcraft.com/acrhives/web_server_survey.html Полезную информацию для сравнения существующих HTTP-серверов содержит сайт serverwatch. сот/stypes (выберите в меню Server Туре команду web). Ниже указано несколько факторов, которые следует учитывать при выборе. • Надежность • Производительность • Своевременность обновлений и исправлений ошибок • Доступность исходного кода • Уровень коммерциализации или поддержки сообщества • Цена • Безопасность и контроль доступа • Возможность использования в качестве прокси-сервера • Возможность шифрования данных Код HTTP-сервера Apache распространяется свободно и доступен на сайте Apache Group apache. org. Если вы не желаете заниматься компиляцией кода, можно инстал- лировать пакет готовых исполняемых модулей (подсказки в табл. 23.4). Некоторые по- ставщики не употребляют слово Apache, но, по существу, вы получите именно его. Таблица 23.4. Адреса модулей веб-сервера Apache Система Катален* Рекомендуемый источник , | Linux /usr/sbin Инсталлируется как часть стандартного дистрибутива Solaris /usr/apache2 Инсталлируется как часть стандартного дистрибутива HP-UX /opt/apache Инсталлируется HP-UX 11i “Web Server suite” AIX /usr/IBMIHS Инсталлируется продукт IBM HTTPServer
Глава 23. Веб-хостинг 1009 Инсталляция сервера Apache Если вы решили загрузить исходный код сервера и скомпилировать его самостоя- тельно, выполните сценарий configure, который включен в дистрибутив. Этот сцена- рий автоматически определяет тип операционной системы, а также устанавливает со- ответствующие make-файлы проекта. Потребуется указать каталог, в котором должен располагаться сервер Apache. Для этого предназначена опция -prefix. $ ./configure —prefix=/etc/httpd Если вы не укажете префикс, то по умолчанию будет использоваться каталог /usr/ local/apache2. Для того чтобы увидеть список возможных аргументов, выполните команду config -help. Большинство этих аргументов содержит опции —enable-модуль= и —disable-модуль-, включающие и отключающие функциональные компоненты, су- ществующие внутри веб-сервера. Задав опцию —enable-MO^yjib=shared (или —enable-mods-shared-all, чтобы сделать совместно используемыми все модули), можно также скомпилировать модули в файлы динамических совместно используемых объектов. Это позволит вам позднее ре- шить, какие модули включить, а какие исключить; во время выполнения загружаются только модули, указанные в конфигурации httpd. Эта конфигурация по умолчанию за- дается для бинарного пакета Apache — все модули компилируются в совместно исполь- зуемые объекты и динамически загружаются при запуске веб-сервера Apache. Единственным недостатком совместно используемых библиотек является более долгое время загрузки и небольшое снижение производительности (обычно менее чем на 5%). Для большинства сайтов возможность “на лету” добавлять новые модули и вклю- чать существующие модули без перекомпиляции перевешивает снижение производи- тельности. Полный список стандартных модулей приведен на сайте httpd.apache. org/docs- 2.2/mod. Несмотря на то что набор модулей, предлагаемый по умолчанию, является вполне приемлемым, можно также включить модули, указанные в табл. 23.5. Таблица 23.5. Полезные модули Apache, которые не включены по умолчанию Модуль Л auth_dbm Использует базу данных DBM для управления доступом со стороны пользователей/групп (ре- комендуется для обеспечения индивидуального доступа пользователей на основе паролей) rewrite Переписывает URL-адреса на основе регулярных выражений expires Позволяет включать в документ дату его истечения proxy Конфигурирует Apache в качестве прокси-сервера mod ssi Включает поддержку протокола Secure Socket Layer* для HTTPS , а Этот протокол известен также под именем Transport Layer Security или RSL (раздел 23.4). Аналогичным образом можно отключить модули, перечисленные в табл. 23.6. От- ключая неиспользуемые модули, следует исходить из соображений безопасности и по- вышения производительности. После завершения сценария configure выполните команды make и make install Для фактической компиляции и установки соответствующих файлов.
1010 Часть II. Работа в сети Таблица 23.6. Модули Apache, которые могут быть отключены модуль .. asis Позволяет посылать файлы указанных типов без использования НТТР-заголовков autoindex Индексирует каталоги, в которых отсутствует начальная HTML-страница (например, index.html) env Позволяет устанавливать специальные переменные среды для CGI-сценариев userdir Разрешает пользователям иметь собственные HTML-каталоги К сожалению, компиляция веб-сервера Apache в системе AIX не такая простая. Советы и приемы для этой инсталляции приведены на сайте people. apache. org/~trawick/apache-2-on-aix.html. Конфигурирование сервера Apache После инсталляции сервера необходимо сконфигурировать его с учетом выполняемых функций. Все конфигурационные файлы находятся в каталоге conf (например, /etc/ httpd/conf). Необходимо проверить и настроить файл httpd.conf, разделенный на три раздела. Первый раздел файла httpd.conf определяет глобальные настройки, например пул сервера, TCP-порт, через который HTTP-сервер принимает запросы (обычно это порт 80, но можно на одном компьютере запустить несколько HTTP-серверов, подключенных к различным портам), а также параметры для загрузки динамических модулей. Второй раздел описывает сервер “по умолчанию”, который будет отвечать на все за- просы, не обработанные определениями VirtualHost (раздел 23.3). В нем находятся параметры конфигурации, включающие пользователя и группу, для которых будет ра- ботать сервер (не суперпользователь!), и инструкцию DocumentRoot, которая опреде- ляет корневой каталог для обслуживаемых документов. В этом разделе указывается так- же ряд специальных установок, связанных, в частности, с обработкой “специальных” URL-адресов, использующих синтаксис -пользователь для. доступа к рабочему каталогу пользователя. Глобальные параметры безопасности также устанавливаются во втором разделе кон- фигурации. Он содержит директивы, которые позволяют управлять доступом на уровне отдельных каталогов (директива <Directory>) или файлов (<File>). С их помощью; можно предотвратить доступ к важным файлам через демон httpd. Необходимо опреде- лить, как минимум, два уровня управления доступом: на одном уровне охватывается весь каталог документов, а второй применяется только к главному каталогу документов. Для этого достаточно оставить без изменения параметры, установленные для веб-сервера Apache по умолчанию, хотя мы рекомендуем удалить параметр AllowSymLinks, чтобы предотвратить обращение демона httpd к вашему дереву документов по символическим ссылкам. (Ведь никто не хочет, чтобы кто-нибудь случайно создал символическую ссыл- ку на каталог /etc, не так ли?) Более подробные советы по укреплению безопасности веб-сервера Apache можно найти на сайте httpd.apache.org/docs-2.2/misc/security_tips.html. Третий, и последний, раздел файла конфигурации настраивает виртуальные узлы. Эту тему мы обсудим в отдельном разделе. Внеся изменения в конфигурацию, проверьте синтаксис конфигурационного файла, выполнив команду httpd -t. Если все в порядке, веб-сервер Apache ответит “Syntax ОК”. Если нет, проверьте опечатки в файле httpd. conf.
Глава 23. Веб-хостинг 1011 Запуск сервера Apache Для запуска сервера Apache уожно запустить демон httpd вручную либо воспользо- ваться сценариями запуска системы. Последний способ предпочтительнее, поскольку он гарантирует, что веб-сервер перезапускается всякий раз при перезагрузке компьютера. Для ручного запуска сервера следует ввести примерно такую команду. % apachectl start Сценарии загрузки описаны в главе 3. Анализ регистрационных файлов Разрабатывая свой веб-сайт, вы, вероятно, захотите собрать статистические показате- ли об его использовании, например количество обращений к каждой странице, среднесу- точное количество запросов, процент ошибочных запросов и объем переданных данных. Убедитесь, что вы используете “комбинированный” формат регистрации (директивы CustomLog должны содержать слово combined, а не common). Комбинированный фор- мат регистрации содержит информацию о домене, ссылающемся на ваш сайт (страницу, с которой произошел переход на URL), и пользовательском агенте (браузере клиента и операционной системе). Файлы регистрации доступа и ошибок находятся в каталоге logs сервера Apache. Эти файлы являются удобочитаемыми для человека, но они содержат так много инфор- мации, что для ее анализа необходима дополнительная программа. Существуют букваль- но сотни анализаторов регистрационных файлов, как свободных, так и коммерческих. > Заслуживают внимание два свободно распространяемых анализатора: Analog (analog.сх) и AWStats (awstats.sourceforge.net). Оба они позволяют получить действительно важную информацию. Если вас интересует информация о трафике и привычках пользователей вашего веб- сайта, обратитесь к службе Google Analysics на сайте analytics. google. com. Эта служ- ба требует, чтобы вы поместили небольшую заглушку на каждую веб-страницу, за кото- рой хотите следить, но зато совершенно бесплатно собирает все данные и выполняет анализ инфраструктуры.2 Высокопроизводительный хостинг За последние несколько лет стало очевидно, что самым простым способом организа- ции высокопроизводительного хостинга является оптимизация некоторых серверов для обслуживания статического содержимого. Одним из способов решения этой проблемы является использование веб-сервера или веб-страницы, работающих в адресном пространстве ядра. Они повышают произво- дительность работы, поскольку эти системы не копируют данные из пользовательского адресного пространства и обратно, прежде чем вернуть их инициатору запроса. Однако поскольку они работают в адресном пространстве ядра, возникает дополнительный риск безопасности системы. Мы рекомендуем использовать этот прием с предельной осто- рожностью. Веб-сервер, работающий в адресном пространстве ядра, называется TUX. Он взаимо- действует с традиционным веб-сервером, например Apache, доступным в некоторых дис- 2 Разумеется, эта схема подразумевает, что компания Google получает доступ к вашему трафи- ку, что может оказаться и хорошо, и плохо.
1012 Часть II. Работа в сети трибутивных пакетах системы Linux. Когда есть такая возможность, сервер TUX предо- ставляет статические страницы, не покидая адресного пространства ядра, как это делает демон rpc. nfsd при обслуживании файлов. Несмотря на то что сервер TUX был вы- пущен для системы Red Hat (в настоящее время компания Red Hat называет его Red Hat Content Accelerator), он распространяется на условиях лицензии GPL, поэтому он может использоваться в других дистрибутивах Linux. Правда, настраивать его не так-то легко. Подробности можно узнать по адресу http: //www. redhat. com/docs/manuals/tux. Для кеширования содержимого в адресном пространстве ядра системы Solaris компа- ния SUN выпустила программу Solaris Network Cache and Accelerator (NCA). Программа NCA перехватывает трафик, входящий и исходящий от демона httpd, и кеширует ста- тические страницы. Когда поступают последующие запросы на то же самое содержимое, они обслуживаются из кеша без использования демона httpd. 23.3. Виртуальные интерфейсы Раньше компьютер с системой UNIX обычно служил сервером для одного веб-узла (например, acme.com). По мере роста популярности сети веб, практически каждый пользователь обзавелся собственным веб-узлом, и, как грибы после дождя, стали появ- ляться тысячи новых компаний, занимающихся веб-хостингом. Ш Основные конфигурации интерфейса описаны в главе 14. Провайдеры быстро осознали, что можно добиться существенной экономии средств и ресурсов, если на одном сервере размещать несколько узлов. Это позволило управлять группой узлов, таких как acme. com, aj ах. com, toadranch. com и многие другие, ис- пользуя одно и то же аппаратное обеспечение. На практике такой подход реализуется с помощью виртуальных интерфейсов. Идея, лежащая в основе виртуальных интерфейсов, весьма проста: одиночный ком- пьютер обслуживает больше IP-адресов, чем позволяют его физические сетевые интер- фейсы. Каждый из “виртуальных” сетевых интерфейсов может иметь доменное имя, под которым он известен пользователям Интернета. Это позволяет единственному серверу обслуживать сотни веб-узлов. Виртуальные интерфейсы позволяют демону идентифицировать соединения не толь- ко по номеру порта назначения (например, порта 80 для HTTP), но и по целевому IP- адресу. В настоящее время виртуальные интерфейсы получили широкое распростране- ние и оказались полезными не только для веб-хостинга. Протокол HTTP 1.1 реализует функциональные возможности, подобные виртуаль- ным интерфейсам (официально это называется “виртуальные интерфейсы, не имеющие IP-адреса”), устраняя потребность в назначении уникальных IP-адресов веб-серверам или в конфигурировании специального интерфейса на уровне операционной системы. Этот подход позволяет совместно использовать IP-адреса, что особенно полезно, когда один сервер содержит сотни или тысячи начальных страниц (например, в случае уни- верситетских веб-узлов). Однако такой подход нельзя назвать практичным для коммерческих узлов, посколь- ку уменьшается степень их масштабируемости (приходится изменять IP-адрес при пере- мещении узла на другой сервер) и возникает угроза безопасности системы (если доступ к узлу фильтруется брандмауэром на основе IP-адресов). Кроме того, виртуальные узлы,
Глава 23. Веб-хостинг 1013 основанные на именах, требуют, чтобы браузер поддерживал протокол SSL.3 Видимо, из-за этого ограничения настоящие виртуальные интерфейсы будут применяться еще долго. Конфигурирование виртуальных интерфейсов Настройка виртуального интерфейса проходит в два этапа. Сначала требуется соз- дать виртуальный интерфейс на уровне TCP/IP. Как именно, зависит от версий системы UNIX; инструкции для разных версий системы UNIX приводятся ниже. На втором эта- пе необходимо сообщить серверу Apache об имеющихся виртуальных интерфейсах. Этот этап также описан ниже. Виртуальные интерфейсы в системе Linux Виртуальные интерфейсы Linux обозначаются в формате интерфейс: экземпляр. Например, если интерфейс Ethernet называется ethO, то связанные с ним виртуальные интерфейсы именуются ethO: 0, ethO: 1 и т.д. Все интерфейсы конфигурируются с по- мощью команды ifconfig. Например, команда $ sudo ifconfig ethO:0 128.138.243.150 netmask 255.255.255.192 up настраивает интерфейс ethO: 0 и закрепляет за ним адрес в сети 128.138.243.128/26. Для того чтобы назначенные виртуальные адреса стали постоянными, необходимо мо- дифицировать сценарии запуска системы. jp’x В системе Red Hat требуется для каждого виртуального интерфейса создать отдельный файл в каталоге /etc/sysconfig/network-scripts. Например, файл ifcfg-ethO; 0, соответствующий приведенной выше команде ifconfig, может содержать такие строки. DEVICE=ethO:О IPADDR=128.138.243.150 NETMASK=255.255.255.192 NETWORK=128.138.243.128 BROADCAST=128.138.243.191 ONBOOT=yes ©Подход, принятый в системе Ubuntu, аналогичен подходу, используемому в си- стеме Red Hat, за исключением того, что определения интерфейсов должны содержаться в файле /etc/network/interfaces. Записи, соответствующие ин- терфейсу ethO: 0, в нашем примере должны выглядеть следующим образом. Iface ethO:0 inet static address 128.138.243.150 netmask 255.255.255.192 broadcast 128.138.243.191 В системе SuSE можно создать виртуальные интерфейсы либо с помощью * и ' " программы YaST, либо путем редактирования интерфейсных файлов. Для ис- пользования программы YAST сначала на вкладке Global Options раздела Network Settings выберите команду Traditional method with ifup. 3 Относительно новая функциональная возможность Server Name Indication (SNI) позволяет использовать протокол SSL с виртуальными узлами, но старые браузеры этого делать не могут.
1014 Часть II. Работа в сети В системе SUSE IP-адреса каждого интерфейса конфигурируются в одном файле. Для редактирования конфигурации поищите в каталоге /etc/sysconfig/network файлы, имена которых начинаются словами if сдЪ-имя_интерфейса. Например, в показанном ниже файле определяются интерфейсы ethO и ethO: 0. IPADDR_1=128.138.243.149 NETMASK_1=255.255.255.192 STARTMODE_1=”auto" LABEL_1=O IPADDR_2=128.138.243.150 NETMASK_2=255.255.255.192 S TARTMODE_2="aut о" LABEL_2=1 Суффиксы, следующие за именами IPADDR и NETMASK (в данном случае _1 и _2), не обязательно должны быть представлены числами, но для согласованности такое со- глашение является вполне приемлемым. Для того чтобы виртуальные интерфейсы рас- познавались, необходимо отредактировать файл /etc/sysconfig/network/config и установить параметр NETWORKMANAGER="no". Виртуальные интерфейсы в системе Solaris Система Solaris поддерживает виртуальные интерфейсы (“вспомогательные ин- терфейсы”) посредством концепции физического интерфейса и логического модуля. Например, если hmeO — это имя физического интерфейса, то hmeO : 1, hmeO :2 и так далее — это имена соответствующих виртуальных интерфейсов. По умолчанию с каж- дым физическим интерфейсом может быть связано до 256 виртуальных сущностей. Если вы хотите изменить это ограничение, используя команду ndd, измените параметр ip_ addrs_per_if (описание команды ndd см. в разделе 14.13). Для конфигурирования виртуального интерфейса просто примените команду ifconfig к одному из виртуальных имен. (Соответствующий физический интерфейс в этот момент уже должен быть “подключен”.) В большинстве случаев систему настраи- вают так, чтобы команда ifconfig применялась к виртуальным интерфейсам во время загрузки. Рассмотрим пример, в котором компьютер под управлением системы Solaris имеет адрес в пространстве частных адресов во внутренней частной виртуальной сети (VPN) и внешний адрес — в Интернете, причем оба адреса связаны с одним и тем же физиче- ским устройством hmeO. Для того чтобы эти интерфейсы автоматически конфигуриро- вались во время загрузки, администратор должен отредактировать два файла имен узлов: /etc/hos tname. hmeO и /etc/hostname. hmeO: 1. $ Is -1 /etc/host* -rw-r—r— 1 root 10 Nov 4 10:19 /etc/hostname.hmeO -rw-r—r— 1 root 16 Dec 21 19:34 /etc/hostname.hmeO:1 Файлы имен узлов могут содержат либо имена узлов из файла /etc/hosts либо IP- адреса. В данном случае администратор использовал каждую из этих возможностей. $ cat /etc/hostname.hmeO overkill $ cat /etc/hostname.hmeO:1 206.0.1.133 $ grep overkill /etc/hosts 10.1.2.9 overkill overkill.domain
Глава 23. Веб-хостинг Ю15 Во время загрузки оба адреса конфигурируются автоматически (вместе со шлейфо- вым адресом, который мы пропустили). $ ifconfig -а hmeO: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 10.1.2.9 netmask ffffffOO broadcast 10.1.2.255 hme0:l: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST mtu 1500 inet 206.0.1.133 netmask ffffff80 broadcast 206.0.1.255 Виртуальные интерфейсы в системе HP-UX В системе HP-UX все виртуальные интерфейсы можно добавлять с помощью коман- ды ifconfig. Ее синтаксис очень похож на синтаксис, используемый в системе Solaris. Например, для того чтобы добавить первый интерфейс, следует выполнить такую ко- манду. $ sudo ifconfig 1ап0:1 192.168.69.1 up Виртуальные интерфейсы системы AIX В системе AIX, для того чтобы добавить дополнительный IP-адрес для интерфейса, можно создать “псевдоним”. Например, для того чтобы добавить 192.168.1.3 как вирту- альный IP-адрес интерфейса епО, можно использовать команду ifconfig. $ sudo ifconfig епО 192.168.1.3 netmask 255.255.255.0 alias Однако этот псевдоним является временным. Для того чтобы создать постоянный виртуальный IP-адрес, следует выполнить команду chdev. $ sudo chdev -1 епО -a alias4=192.168.1.3,255.255.255.0 Передача серверу Apache информации о виртуальном интерфейсе После создания виртуальных интерфейсов с помощью команды ifconfig требуется сообщить серверу Apache о том, какие документы должны обрабатываться при попытке подключения клиента к каждому интерфейсу (IP-адресу). Это можно сделать с помощью директивы VirtualHost файла httpd. conf. Каждому сконфигурированному виртуаль- ному интерфейсу должна соответствовать одна такая директива. Приведем пример. <VirtualHost 128.138.243.150> ServerName www.company.com ServerAdmin webmasterGwww.company.com DocumentRoot /var/www/htdocs/company ErrorLog logs/www.company.com-error_log CustomLog logs/www.company.com-access_log combined ScriptAlias /cgi-bin/ /var/www/cgi-bin/company </VirtualHost> После подключения клиента к виртуальному узлу 128.138.243.150 будут обрабаты- ваться документы из каталога /var/www/htdocs/ company. Для настройки параме- тров виртуального узла в раздел VirtualHost может включаться почти любая дирек- тива веб-сервера Apache. Относительные пути к каталогам, включая пути для директив DocumentRoot, ErrorLog и CustomLog, интерпретируются в контексте ServerRoot. Если виртуальные узлы имеют имена, то множественные имена в системе DNS ссы- лаются на один и тот же IP-адрес. Конфигурация веб-сервера Apache остается прежней,
1016 Часть II. Работа в сети но необходимо задать основной IP-адрес, который веб-сервер Apache должен прослуши- вать в ожидании входящих запросов к именованному виртуальному узлу, и не указывать IP-адрес в разделе VirtualHost. NameVirtualHost 128.138.243.150 cVirtualHost *> ServerName www.company.com ServerAdmin webmaster@www.company.com DocumentRoot /var/www/htdocs/company ErrorLog logs/www.company.com-error_log CustomLog logs/www.company.com-access_log combined ScriptAlias /cgi-bin/ /var/www/cgi-bin/company </VirtualHost> В этой конфигурации веб-сервер Apache ищет заголовки HTTP, чтобы определить требуемый сайт. Сервер прослушивает запросы к сайту www. company. com на его основ- ном IP-адресе 128.138.243.150. 23.4. Протокол Secure Sockets Layes Протокол SSL защищает соединения между веб-сайтом и клиентским браузером. Эту технологию используют универсальные указатели ресурса, начинающиеся с префик- са https: //. Протокол SSL использует алгоритмы криптографии для предотвращения перехвата, взлома и подделки сообщений. Браузер и сервер используют схему аутентификации с помощью сертификата, после которой они переключаются на более быстродействующую схему шифрования для за- щиты реального соединения. Протокол SSL выполняется на отдельном уровне, лежащем ниже уровня протоко- ла приложения HTTP. Он просто обеспечивает защиту соединения и не вмешивается в трансакцию HTTP. Благодаря такой аккуратной схеме, протокол SSL может защищать не только HTTP, но и другие протоколы, такие как SMTP и FTP. Более подробную ин-; формацию можно найти в Википедии в статье “Secure Sockets Layer.”4 В первые годы использования протокола SSL большинство ключей симметричного шифрования были относительно слабыми и состояли из 40 бит, потому что правитель- $ ство США наложило ограничения на экспорт криптографической технологии. После ' многолетних переговоров и судебных исков, правительство ослабило некоторые огра- ничения экспорта, позволив реализовать протокол SSL с использованием 128-битовых симметричных ключей. Генерирование файла Certificate Signing Request Владелец веб-сайта, использующий протокол SSL, должен сгенерировать цифровой файл Certificate Signing Request (CSR), содержащий открытый ключ и название компа- нии. Этот “сертификат” должен быть “подписан” доверенным источником, известным как Certificate Authority (СА). Сертификат, подписанный источником сертификатов, со- держит открытый ключ сайта, а также подтверждение подлинности источника. 4 Transport Layer Security (TLS) — это протокол, являющийся преемником протокола SSL. Он реализован во всех современных браузерах. Однако сообщество пользователей сети веб по- прежнему называет его SSL.
Глава 23. Веб-хостинг 1017 Веб-браузеры имеют встроенные списки источников СА, подписанные сертификаты которых они будут принимать. Браузер, знающий источник сертификата для вашего сай- та, может верифицировать подпись вашего сертификата и получить ваш открытый ключ, тем самым позволив посылать сообщения, которые может расшифровать только ваш сайт. Кроме того, вы действительно можете подписывать ваш собственный сертификат. Получив сертификат от какого-либо непризнанного источника, большинство браузеров сообщает пользователю о том, что этот сертификат является подозрительным. В ком- мерческих приложениях такая ситуация, очевидно, представляет проблему. Однако, если вы хотите подписывать сертификаты для внутреннего использования и тестирования, изучите документ httpd. apache. org/docs/2.2/ssl/ssl_faq. html#aboutcerts. Вы можете получить подпись сертификата от любого источника сертификатов. Введите в поисковой строке Google слова “SSL certificate” и выберите любую ссылку. Реальное различие между источниками сертификатов заключается в объеме работы, которую они выполняют для проверки вашей идентичности; гарантиях, которые они предоставляют; и количестве браузеров, которые они поддерживают изначально (боль- шинство источников сертификатов поддерживают практически все браузеры). Создание сертификата, который будет послан источнику сертификатов, является довольно простой процедурой. Необходимо инсталлировать пакет OpenSSL, который по умолчанию есть в большинстве систем. Затем необходимо выполнить следующие действия. Сначала, создайте 1024-битовый закрытый ключ RSA для своего веб-сервер^ Apache. $ openssl genrsa -des3 -out server.key 1024 Вам предложат войти и подтвердить пароль для шифрования серверного ключа. Ско- пируйте файл server. key в безопасное место (которое доступно только суперпользог вателю) и запомните введенный пароль. Интересующиеся пользователи могут увидеть многочисленные детали ключа с помощью следующей команды. $ openssl rsa -noout -text -in server.key Затем создайте файл Certificate Signing Request (CSR), содержащий серверный ключ, который вы только что сгенерировали. $ openssl req -new -key server.key -out server.csr Когда увидите приглашение ввести “стандартное имя”, введите полностью опре- деленное имя домена сервера. Например, если ваш сайт имеет URL-идентификатОр https: / /company. com, введите в качестве стандартного имени строку “сотрапусот*. Обратите внимание на то, что для каждого узла нужен отдельный сертификат, даже для узла “www.company.com”, который отличается от “company.com.” Компании обычно ре- гистрируют только стандартное имя; они должны гарантировать, что каждая ссылка по протоколу SSL ссылается именно на этот узел. Детали сгенерированного файла CSR можно увидеть, выполнив такую команду. $ openssl req -noout -text -in server.csr Теперь можно послать файл server. csr выбранному вами источнику сертификатов. Сохранять его локальную копию не обязательно. Подписанный файл CSR, возвращен- ный источником сертификатов СА, должен иметь расширение . crt. Поместите подпи- санный сертификат в каталог, содержащий ваши файлы конфигурации демона httpd, например в каталог /usr/local/apache2/con£/ssl.crt.
1018 Часть II. Работа в сети Конфигурация веб-сервера Apache для использования протокола SSL Запросы по протоколу HTTP приходят на порт 80, а запросы по протоколу HTTPS используют порт 443. Трафики протоколов HTTPS и HTTP можно обслуживать одним и тем же процессом веб-сервера Apache. Однако протокол SSL не работает с именован- ными виртуальными узлами; каждый виртуальный узел должен иметь конкретный IP- адрес. (Это ограничение является следствием внутренней структуры протокола SSL.) Для того чтобы настроить веб-сервер Apache на использование протокола SSL, сна- чала примите меры, чтобы модуль SSL был включен в файле httpd.conf, найдя или добавив следующую строку. LoadModule ssl_module libexec/mod_ssl.so Затем добавьте директиву VirtualHost для порта SSL. <VirtualHost 128.138.243.150:443> ServeгName www.company.com ServerAdmin webmaster@www.company.com DocumentRoot /var/www/htdocs/company ErrorLog logs/www.company.com-ssl-error_log CustomLog logs/www.company.com-ssl-access_log combined ScriptAlias /cgi-bin/ /var/www/cgi-bin/company SSLEngine on SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key </VirtualHost> Обратите внимание на цифры :443 после IP-адреса и директивы протокола SSL, ука- зывающие веб-серверу Apache, где искать ваш закрытый ключ и подписанный сертифи- кат. Запустив веб-сервер Apache, вы получите сообщение с просьбой ввести пароль для вашего файла server. key. Благодаря этому демон httpd больше не сможет запускаться автоматически при загрузке компьютера. Если хотите, можно удалить шифрование из вашего закрытого ключа, чтобы устранить необходимость вводить пароль. $ ср server.key server.key.orig $ openssl rsa -in server .key. orig -out server, key $ chmod 400 server.key server.key.orig Разумеется, каждый, кто получит копию вашего расшифрованного ключа, затем смо- жет выдать свой сайт за ваш. Более подробную информацию о протоколе SSL можно найти на следующих стра- ницах. httpd.apache.org/docs-2.2/ssl/ssl_faq.html httpd.apache.org/docs/2.2/mod/mod_ssl.html 23.5. Кеширование и прокси-серверы Развитие Интернета и увеличение объема находящейся в нем информации по- прежнему происходят очень быстро. Следовательно, пропускная способность глобаль- ных каналов и мощность вычислительных ресурсов, требуемых для их обслуживания, также резко возрастают. Как с этим справиться? Единственным методом справиться с этим является использование репликации. Независимо от того, на каком уровне — национальном, региональном или корпора-
Глава 23. Веб-хостинг 1019 тивном — находится информация, по мере развития Интернета требуется перемещать данные на ближние узлы. Не имеет смысла передавать одну и ту же популярную веб- страницу, скажем, из Австралии в США миллионы раз в день, используя весьма дорого- стоящий международный канал связи. Должен существовать способ сохранять эту ин- формацию после ее однократной передачи по каналу. К счастью, такой способ есть, хотя бы на уровне сайтов. Веб-прокси позволяет ке- шировать данные и управлять внешними запросами к содержимому вашего веб-сайта. Схема работы веб-прокси такова. Клиентские веб-браузеры подключаются к прокси- серверу, чтобы запросить объект из Интернета. Прокси-сервер выполняет запрос от име- ни клиента (либо извлекает объект из кеша) и возвращает результат клиенту. Прокси- серверы этого типа часто используются для усиления безопасности или фильтрации содержимого. В системе, где работает прокси-сервер, непосредственный доступ в Интернет через брандмауэр нужен лишь одному компьютеру. В компьютерных классах средних школ прокси-серверы зачастую выполняют фильтрацию содержимого, чтобы дети не могли получить доступ к неподобающим материалам. В настоящее время имеется множество коммерческих и бесплатных прокси-серверов. Некоторые из них основаны исклю- чительно на программном обеспечении, а другие встроены в аппаратные устройства. Обширный список технологий прокси-сервера можно найти на странице web-caching, com/proxy-caches.com. В следующих разделах описывается пакет Squid Internet Object Cache5, популярный автономный кеш. Мы также кратко обрисуем функциональные возможности прокси, которыми обладает модуль mod__cache веб-сервера Apache. Использование кеша Squid и прокси-сервера Squid — это кеширующий прокси-сервер, поддерживающий несколько протоколов, включая HTTP, FTP и SSL. Служба прокси — это, конечно, хорошо, но действительно преимуществом сервера Squid являются его кеширующие возможности. Сервер Squid не только кеширует ин- формацию, получаемую в результате выполнения запросов локальных пользователей, но и формирует иерархию серверов6. Группы серверов Squid применяют протокол ICP (Internet Cache Protocol — протокол кеширования в Интернете) для передачи друг другу сведений о содержимом своих кеш-буферов. Это позволяет администратору создать систему, в которой локальные пользова- тели взаимодействуют с кеширующим сервером организации с целью получения веб- содержимого. Если другой пользователь организации уже запрашивал эти же данные, то при повторном обращении к ним будет возвращена их копия, причем скорость передачи окажется сравнима со скоростью работы локальной сети (обычно 10 или 100 Мбит/с). При отсутствии на локальном сервере Squid требуемой информации она запрашивается у регионального кеширующего сервера. Как и в случае локального сервера, если какой- либо пользователь регионального сервера уже запрашивал объект раньше, то этот объект будет немедленно взят из кеша. При отсутствии объекта сервер обратится к “вышестоя- 5 Почему “Squid” (кальмар — Примеч. ред.)? По версии авторов, “потому что все хорошие имена уже были заняты”. 6 К сожалению, некоторые узлы помечают все свои страницы как некешируемые, что препят- ствует эффективной работе сервера Squid. Кроме того, сервер не кеширует динамически форми- руемые страницы.
1020 Часть II. Работа в сети щему” серверу (обслуживающему страну или континент) и т.д. В результате производи- тельность обработки запросов существенно повышается, и пользователи это чувствуют. Применение пакета Squid экономически выгодно. Поскольку пользователи часто за- прашивают в Интернете одну и ту же информацию, в крупных организациях наблюда- ется значительное дублирование внешних веб-запросов. Эксперименты показали, что установка кеширующего сервера приводит к уменьшению внешнего трафика на 40%. Для эффективного использования сервера Squid, вероятно, потребуется заставить пользователей использовать кеш. Либо конфигурируйте прокси по умолчанию с по- мощью службы Active Directory (в среде Windows), либо настройте ваш маршрутизатор на перенаправление всего веб-трафика в кеш Squid с помощью протокола Web Cache Communication Protocol (WCCP). Инсталляция сервера Squid Сервер Squid довольно легко инсталлировать и конфигурировать. Поскольку серверу нужно свободное пространство для кеша, потребуется выделенный компьютер, имею- щий достаточный объем оперативной и дисковой памяти. Приемлемая конфигурация такова: 32 Гбайт ОЗУ и 8 Тбайт на жестком диске. Пакет доступен в виде бинарных скомпилированных модулей. Кроме того, свежую копию пакета Squid можно загрузить с узла squid-cache. org. Во втором случае после распаковки инсталляционного дистрибутива запустите сценарий configure, находя- щийся в начальном каталоге. По умолчанию предполагается, что пакет будет установлен в каталог /usr/local/squid. Если требуется задать другой каталог, воспользуйтесь оп- цией —pref ±х=ка та лог сценария configure. После завершения сценария выполните команды make и make install. Далее потребуется модифицировать файл конфигурации squid, conf. Обратитесь к файлу QUICKSTART, находящемуся в дистрибутивном каталоге, для получения перечня изменений, которым должен подвергнуться имеющийся файл squid, conf. Нужно также выполнить команду squid -z, чтобы сформировать и предварительно очистить структуру каталогов, в которой будут храниться кешированные веб-страницы. В конце можно запустить сервер вручную с помощью сценария RunCache, хотя обычно он вызывается из сценариев запуска системы, чтобы сервер Squid автоматически запу- скался на этапе начальной загрузки. Для тестирования сервера Squid необходимо указать его в качестве прокси-сервера для веб-браузера. Настройка обратного прокси с помощью веб-сервера Apache Для обеспечения безопасности и равномерного распределения нагрузки иногда по- лезно создавать веб-прокси для обработки входящих запросов (т.е. запросов, которые по- ступают от браузеров из Интернета к вашему серверу). Поскольку эта ситуация является противоположной по отношению к обычному использованию веб-прокси (подразуме- вающему обработку запросов, исходящих от браузеров в вашей сети), такая инсталляция называется обратным прокси (reverse proxy). Ш Сети DMZ описаны в главе 22. Одна из распространенных конфигураций подразумевает размещение обратного прокси в вашей сети DMZ, чтобы иметь доступ к запросам, поступающим из Интернета,
Глава 23. Веб-хостинг 1021 к вашим службам, например электронной почте, основанной на использовании сети веб. Затем прокси передает эти запросы соответствующим внутренним серверам. Этот подход имеет несколько преимуществ. • Это исключает соблазн установить прямые соединения с серверами, не принад- лежащими сети DMZ. • Достаточно настроить только один DMZ-сервер, а не по одному серверу для каж- дой службы, доступной извне. • Можно управлять доступными указателями URL с центрального пункта, повышая безопасность. • Входящие запросы можно регистрировать для мониторинга и анализа. Конфигурирование веб-сервера Apache для обеспечения обратного прокси является относительно простым. В разделе VirtualHost файла httpd. conf веб-сервера Apache следует использовать директивы ProxyPass и ProxyPassReverse. • Директива ProxyPass отображает удаленный указатель URL в пространство URL локального сервера, так что эта часть локального адресного пространства выгля- дит как зеркало удаленного сервера. (В этом сценарии “локальный” сервер — это DMZ-компьютер, а “удаленный” сервер — это сервер вашей внутренней сети.) • Директива ProxyPassReverse скрывает реальный сервер с помощью “ретуширо- вания” внешних HTTP-заголовков, проходящих через прокси. ; Ниже приведен фрагмент конфигурации обратного прокси, который необходимо по- местить в систему UNIX DMZ перед сервером Microsoft Outlook Web Access (OWA), обе- спечивающим работу электронной почты с помощью сети веб. CLocation /грс> ProxyPass https://wm.monkeypaw.com/rpc ProxyPassReverse https://wm.monkeypaw.com/rpc SSLRequireSSL </Location> CLocation /exchange> ProxyPass https://wm.monkeypaw.com/exchange ProxyPassReverse https://wm.monkeypaw.com/exchange SSLRequireSSL </Location> CLocation /exchweb> ProxyPass https://wm.monkeypaw.com/exchweb ProxyPassReverse https://wm.monkeypaw.com/exchweb SSLRequireSSL c/Location> CLocation /public> ProxyPass https://wm.monkeypaw.com/public ProxyPassReverse https://wm.monkeypaw.com/public SSLRequireSSL c/Location> CLocation /oma> ProxyPass https://wm.monkeypaw.com/oma ProxyPassReverse https://wm.monkeypaw.com/oma SSLRequireSSL
1022 Часть II. Работа в сети </Location> cLocation /Microsoft-Server-ActiveSync> ProxyPass https://wm.monkeypaw.com/Microsoft-Server~ActiveSync ProxyPassReverse https://wm.monkeypaw.com/Microsoft~Server~ActiveSync SSLRequireSSL </Location> В этом примере прокси-службы обеспечиваются только для нескольких указателей URL верхнего уровня: /rpc, /exchange, /exchweb, /public, /ота и /Microsoft- Server-ActiveSync. По соображениям безопасности желательно ограничить запросы, проходящие через прокси. 23.6. Расширение возможностей Внезапная популярность сайта в сети веб может стать ночным кошмаром для си- стемного администратора. Популярный блок или объявление на сайте digg. com может увеличить ваш веб-трафик в несколько раз. Даже “реальный” рост популярности мо- жет быстро исчерпать пропускную способность вашего локального сервера или сетевого соединения. Но не бойтесь; для решения этих проблем есть много решений. Облачные вычисления Ш Облачные вычисления описаны в главе 24. Облачный хостинг предоставляет вам доступ к виртуальному экземпляру операци- онной системы, выбранной вами, без необходимости устанавливать аппаратное обе- спечение в вашей организации. Фактически в этой схеме аппаратное обеспечение и его поддержка являются полностью абстрактными — вы можете иметь только самое общее представление о том, где на самом деле работает ваш виртуальный экземпляр. Существует много провайдеров облачного хостинга, но компания Amazon являет- ся первопроходцем и остается рыночным лидером со своими службами Amazon Web Services (AWS), работающими на сайте aws. amazon. com. Менее чем за пять минут вы можете запустить новый экземпляр системы Linux или UNIX. Вы регистрируетесь с по- мощью утилиты ssh, чтобы управлять этой системой так, будто это ваш собственный информационный центр. А лучше всего то, что эта услуга невероятно дешевая (в настоя- щее время около 10 центов за час работы одного экземпляра в США для службы самого низкого уровня). Несколько служб можно разместить на верхнем уровне облака, чтобы автоматически подключать или отключать серверы. Собственная служба масштабирования компании Amazon называется Auto Scaling. Интегрированные службы масштабирования продает компания RightScale (rightscale. com). Хостинг совместного размещения серверов Совместное размещение серверов — еще один способ организации хостинга ваших систем в удаленном информационном центре, но в этом случае вы обычно или владеете серверным аппаратным обеспечением, или арендуете его. Этот способ предпочтителен, если стандарты или регламенты запрещают использовать облачные информационные центры (например, при использовании стандарта защиты информации в индустрии пла- тежных карт PCI DSS) или необходимо специальное оборудование. Некоторые прило-
Глава 23. Веб-хостинг 1023 жения, связанные с интенсивным вводом и выводом данных, также лучше работают на специальном оборудовании, хотя виртуальный мир их быстро догоняет. Ш Более подробно уровни информационных центров описаны в главе 27. Существуют сотни провайдеров совместного размещения серверов. Выберите один из них на требуемом вам ярусе в соответствии с рекомендациями организации Uptime Institute (uptimeinstitute. org). Коммерческие приложения обычно размещаются в информационных центрах третьего или четвертого уровня. Сети для распределения контента Большинство контента в Интернете является статическим: изображения, докумен- ты, пакеты программного обеспечения. Помещая копии этих статических компонентов ближе к пользователям (в терминах сети), вы можете уменьшить или вообще исклю- чить необходимость обращаться к данным из оригинального источника и выключить его из сети. Система компьютеров, обеспечивающая эту возможность, называется сетью для рас- пределения контента (content distribution network — CDN). Межконтинентальные сете- вые соединения обычно перегружены, поэтому сети CDN особенно важны для обеспе- чения быстрого доступа к популярному контенту на других континентах. Большинство сетей CDN действует как коммерческие службы, финансируемые про- вайдерами контента, желающими обеспечить доступность и оперативность своих сай- тов без масштабирования их инфраструктуры. Наиболее успешной оказалась платфор- ма CDN, управляемая компанией Akamai Technologies (akamai. com). Крупнейшими конкурентами этой компании являются недавно появившиеся компании Limelight (limelightnetworks. com) и Disney-owned EdgeCast (edgecast. com). При правильной реализации использование сети CDN не представляет для конечно- го пользователя никаких трудностей. Некоторые объекты могут доставляться из относи- тельно близкого сервера или кеша, а другие — непосредственно из источника. Однако все это стоит больших затрат. Включать службу CDN в свой план хостинга могут только богатые организации. 23.7. Упражнения 23.1. Сконфигурируйте виртуальный интерфейс на рабочей станции. Выполните ко- манду ifconfig до и после этого и сравните результат. Можно ли обнаружить виртуальный интерфейс с помощью команды ping, выполненной на другом ком- пьютере той же подсети? А другой сети? Объясните ваш ответ. (Необходим доступ с правами суперпользователя.) 23.2. Используя свой браузер, зайдите на популярный и содержательный сайт, напри- мер abcnews. com, и посмотрите на источник страницы (View«=>Page в браузере Firefox или Page^View в браузере IE). С помощью команды dig просмотрите за- писи DNS для узлов, заданных в указателе URL отдельного объекта. Можете ли вы определить, какие объекты хранятся в сети для распределения контента? 23.3. ★ С помощью анализатора пакетов (tcpdump) прослушайте трафик двустороннего HTTP-диалога, связанного с передачей информации на сервер (например, с за- полнением полей формы или поля поиска). Покажите, каким образом браузер по- сылает данные веб-серверу. (Необходим доступ с правами суперпользователя.)
1024 Часть II. Работа в сети 23.4. Используйте анализатор пакетов для перехвата трафика, возникающего при от- крытии часто посещаемой веб-страницы, например начальной страницы портала amazon. com или cnn. com. Сколько отдельных TCP-соединений приходится от- крывать? Кто инициирует их? Является ли это наиболее эффективным способом использования протокола TCP? (Необходим доступ с правами суперпользователя.) 23.5. Найдите журнальные файлы веб-сервера и проанализируйте их. Запросы каких типов поступали серверу за последние несколько часов? Какие ошибки произош- ли за этот период? Что можно сказать о безопасности сервера на основании со- держимого журнальных файлов? (Может потребоваться доступ с правами супер- пользователя.) 23.6. Инсталлируйте сервер Apache и создайте несколько веб-страниц. Проверьте с других компьютеров, работает ли сервер. Найдите журнальные файлы Apache, которые позволяют узнать, какие браузеры обращались к серверу. Настройте сер- вер Apache на выдачу некоторых веб-страниц через виртуальный интерфейс, соз- данный в упр. 23.1. (Необходим доступ с правами суперпользователя.)
ЧАСТЬ III Разное

Глава 24 виртуализация В то время как корпоративные центры обработки данных продолжают увеличивать количество серверов для удовлетворения информационных аппетитов современного бизнеса, системные администраторы стараются разрешить технический парадокс: как управлять существующими системами более эффективно, чтобы экономить электроэ- нергию, площадь и стоимость охлаждения, продолжая обслуживать сотни пользователей? Разработчики программного обеспечения никогда не поощряли администраторов выполнять свои приложения на других платформах, ссылаясь на потенциальную несо- вместимость, а в некоторых случаях даже угрожая прекратить техническую поддержку. В результате возникло огромное количество узкоспециализированных серверов. По по- следним оценкам коэффициент использования среднестатистического сервера коле- блется от 5 до 15% и продолжает снижаться по мере увеличения производительности серверов. Выйти из этого затруднительного положения позволяет виртуализация: параллель- ное использование разных независимых операционных систем на одном и том же ап- паратном обеспечении. Администраторы могут рассматривать каждую виртуальную машину как уникальный сервер, удовлетворяющий капризных поставщиков (в боль- шинстве случаев) и одновременно уменьшающий затраты на работу центра обработки данных. Виртуализацию поддерживают многие платформы, а разработка специальных инструкций центрального процессора, предназначенных для поддержки виртуализа- ции, и преобладание многоядерных процессоров резко повысили производительность. Виртуальные серверы легко инсталлировать и проще сопровождать (в расчете на один сервер), чем физические машины. Со временем реализация виртуализации сильно изменилась, но основные концепции остаются прежними. Компания IBM использовала виртуальные машины еще в первых мейнфреймах, исследуя в 1960-х годах концепцию разделения времени и позволяя со- вместно использовать процессор и ресурсы для хранения данных с помощью абстрактно-
1028 Часть III. Разное го уровня. Аналогичная технология, разработанная компанией IBM, была использована в мейнфреймах в средине 1970-х годов, пока в 1980-х не начался клиент-серверный бум. Эта технология оставалась доминантной на протяжении 1980— 1990-х годов, пока пробле- мы, связанные с высокой стоимостью обслуживания и сложностью управления огром- ными фермами серверов, не возродили интерес к виртуализации современных систем. По общему мнению, путь для современного виртуального безумия проложила компания VMware, создав в 1999 году платформу для виртуализации на основе архитектуры Intel х86. Сегодня технология виртуализации — это процветающий бизнес, открывающий пе- ред разработчиками множество рыночных возможностей. Компания VMware остается явным лидером и предлагает продукты, предназначенные для бизнеса любого масштаба, а также программное обеспечение для управления организациями с высокой степенью виртуализации. Сообщество разработчиков программ с открытым исходным кодом от- ветило на этот вызов проектом Хеп, получившим коммерческую поддержку компании XenSource, которая в настоящее время называется Citrix. Выпустив систему Solaris 10, компания Sun предложила мощную технологию, осно- ванную на концепциях зон и контейнеров и способную запускать более 8000 виртуаль- ных систем на базе одной инсталляции Solaris. На этом рынке всего несколько игроков и десятки конкурирующих продуктов, каждый из которых занимает свою нишу. Ш Сети хранения данных описаны в главе 8. Несмотря на то что главной темой этой главы является серверная виртуализация, аналогичные концепции можно применить ко многим другим областям информацион- ной инфраструктуры, включая сети, хранилища данных, приложения и даже настоль- ные системы. Например, при использовании сетей для хранения данных или хранилищ, объединенных в сеть, пулы дисков можно рассматривать как службу, при необходимости создавая дополнительный объем памяти. Применение виртуализации к настольным си- стемам может оказаться полезным как для системных администраторов, так и для поль- зователей, поскольку каждому пользователю предоставляется среда, настроенная по его требованиям. Широкие возможности виртуализации создали дополнительные сложности для не- расторопных администраторов систем UNIX и Linux. Их пугает возможность выбора между десятками платформ и конфигураций и необходимость определения долгосроч- ной стратегии. В этой главе мы начнем с определения терминов, используемых в техно- логиях виртуализации, продолжим обсуждением преимуществ виртуализации, подска- жем, как принять наилучшее решение, удовлетворяющее ваши потребности, и, наконец, дадим несколько практических советов, касающихся наиболее популярного программ- ного обеспечения для виртуализации, работающего в исследуемых нами операционных системах. 24.1. Виртуальный жаргон Виртуализация имеет свои термины и концепции. Овладение этим языком является первым шагом к овладению разнообразными функциональными возможностями. Предполагается, что операционные системы управляются аппаратным обеспечением, поэтому одновременное функционирование двух систем вызывает конфликты, связан- ные с совместным использованием ресурсов. Серверная виртуализация — это абстракция вычислительных ресурсов, позволяющая операционным системам работать, ничего не зная о базовом аппаратном обеспечении. Программное обеспечение для виртуализации
Глава 24. Виртуализация 1029 “дробит” физические ресурсы, такие как диски, память и центральный процессор, ди- намически предоставляя их для использования несколькими виртуальными машинами. Администраторы системы UNIX должны понимать три разные парадигмы: полная виртуализация, паравиртуализация и виртуализация на уровне операционной системы. Каждая модель по-своему решает проблемы выделения ресурсов и доступа к аппаратно- му обеспечению, и каждая из них имеет свои преимущества и недостатки. Полная виртуализация В настоящее время наиболее широко признанной является парадигма полной вир- туализации. В этой модели операционная система не знает, что она функционирует на виртуализированной платформе, а между виртуальными машинами (“гостями”) и аппа- ратным обеспечением инсталлируется гипервизор (“hypervisor”), известный также как монитор виртуальной машины. Такие гипервизоры называются автономными (bare-metal), потому что они управ- ляют аппаратным обеспечением. Гипервизор обеспечивает уровень эмуляции для всех аппаратных устройств узла. Гостевая операционная система не модифицируется. Гости выполняют прямые запросы к виртуализированному аппаратному обеспечению, и лю- бые привилегированные инструкции, которые гостевые ядра пытаются выполнить, об- рабатываются гипервизором. Автономная виртуализация — наиболее безопасный вид виртуализации, потому что гостевые операционные системы изолированы от базового аппаратного обеспечения. Кроме того, не требуется вносить никаких изменений в ядра операционных систем, и гости могут выбирать разные базовые архитектуры. Если имеется программное обеспе- чение для виртуализации, то гость может функционировать на любой архитектуре про- цессоров. (Однако трансляция инструкций центрального процессора приводит к уме- ренному снижению производительности.) Примером полной виртуализации является популярная технология VMware. Общая структура систем, созданных по технологии VMware, представлена на рис. 24.1. Рис. 24.1. Архитектура полной виртуализации Паравиртуализация Паравиртуализация — это технология, используемая виртуальной платформой с открытым исходным кодом Хеп. Как и полная виртуализация, паравиртуализация по- зволяет нескольким операционным системам согласованно функционировать на одной
1030 Часть III. Разное машине. Однако ядра каждой операционной системы должны быть модифицирова- ны, чтобы поддерживать “гипервызовы” (“hypercalls”), т.е. перевод определенных ин- струкций, предназначенных для центрального процессора. Приложения, действующие в адресном пространстве пользователя, не требуют модификации и выполняются на Xen-машинах естественным образом. Гипервизор в паравиртуализации используется точно так же, как и в полной виртуализации. Уровень трансляции в паравиртуализированной системе связан с меньшими наклад- ными расходами ресурсов, поэтому паравиртуализация ведет к номинальному повы- шению производительности. Однако необходимость модифицировать гостевые опера- ционные системы резко снижает эффект и является основной причиной того, почему технология паравиртуализации Хеп слабо поддерживается за пределами сообщества Linux и других ядер с открытым исходным кодом. Среда паравиртуализации продемонстрирована на рис. 24.2. Она похожа на пол- ностью виртуализированную систему, изображенную на рис. 24.1, в которой гостевые операционные системы взаимодействуют с гипервизором посредством определенного интерфейса и первый гость является привилегированным. Рис, 24,2, Архитектура паравиртуализации Виртуализация на основе операционной системы Системы виртуализации на основе операционной системы резко отличаются от предыдущих двух моделей. Вместо создания множественных виртуальных машин внутри физической системы, виртуализация на основе операционной системы позволяет опера- ционной системе создать множественные изолированные окружения прикладных про- грамм, относящихся к одному и тому же ядру. Виртуализацию на основе операционной системы следует рассматривать как функциональную возможность ядра, а не отдельный уровень абстракции программного обеспечения. Поскольку в этой схеме нет реального уровня трансляции или виртуализации, на- кладные расходы ресурсов при таком способе виртуализации очень низкие. Большинство реализаций обеспечивает практически естественную производительность. К сожалению, этот тип виртуализации препятствует использованию нескольких операционных систем, поскольку все гости совместно используют одно и то же ядро (или “контейнеры”, как принято говорить в данном контексте).1 Разделы рабочих нагрузок (workload partitions) 1 Это не совсем так. Контейнеры системы Solaris имеют функциональную возможность под названием “фирменные зоны” (“branded zones”), позволяющие выполнять бинарные модули си- стемы Linux в ядре системы Solaris.
Глава 24. Виртуализация 1031 в системе AIX, а также контейнеры и зоны в системе Solaris представляют собой приме- ры виртуализации на основе операционной системы. Архитектура виртуализации на основе операционной системы представлена на рис. 24.3. Виртуализация на основе операционной системы (например, контейнеры Solaris, виртуальные машины Integrity VM компании HP, разделы рабочих нагрузок компании IBM) Рис. 24.3. Архитектура виртуализации на основе операционной системы Естественная виртуализация Пытаясь обеспечить преимущество своему аппаратному обеспечению, ведущие компании—производители микропроцессоров AMD и Intel ведут острую конкурентную борьбу за лучшую поддержку виртуализации с помощью аппаратного обеспечения, те. за естественную (“native”) виртуализацию. Обе компании предлагают центральные процес- соры, которые содержат инструкции по виртуализации, что исключает необходимость в уровне трансляции для полной виртуализации или паравиртуализации. В настоящее время все основные игроки на рынке виртуализации могут воспользоваться этими воз- можностями центральных процессоров. Облачные вычисления В дополнение к традиционной виртуализации, относительно недавно появилась технология, которую неформально (и в некоторой степени недоброжелательно) назы- вают облачными вычислениями и считают альтернативой локальным серверным фер- мам. Облачные вычисления предлагают вычислительные мощности в качестве службы, которая оплачивается по привлекательно низкой цене на почасовой основе. Большая часть очевидных преимуществ этой технологии заключается в преобразовании ресур- сов серверов в инфраструктуру, аналогичную коммунальным службам. Администраторы и разработчики никогда не видят реальное аппаратное оборудование, которое они ис- пользуют, и ничего не знают о его структуре. Название этой технологии происходит от традиционного использования очертания облака для обозначения Интернета на сетевых диаграммах. Поскольку эта книга предназначена для системных администраторов, мы рассмотрим облачные вычисления на уровне сервера, но приложения также могут перемещаться в облако (эта технология называется “программное обеспечение как служба” (software-as- a-service — SAAS)). Все программы для настольных систем, реализующие разнообразные функции — от рассылки электронной почты до деловой активности, — можно перепо- ручить сторонним организациям и ими можно управлять независимо.
1032 Часть III. Разное Облачные службы обычно сопровождаются интерфейсом для управления, который настраивает мощности по требованию и позволяет резервировать новые системы одним щелчком мыши. Служба Elastic Compute Cloud (ЕС2) компании Amazon — это наибо- лее зрелая служба этого типа, относящаяся к первому поколению. Она пользуется попу- лярностью среди компаний, предлагающих веб-платформы нового поколения. Любите ли вы его или ненавидите, но принцип предоставления информационных сервисов как коммунальных услуг (utility computing) привлекает скупых менеджеров как дешевая аль- тернатива центрам обработки данных и локализованной серверной инфраструктуре. Фа- натики информационных технологий верят, что облачные технологии в различных фор- мах — это будущее вычислительных систем. Облачные вычисления основаны на идеях, некоторые из которых легли в основу виртуализации, но ее следует рассматривать как отдельный набор технологий со своими особенностями. Динамическая миграция Последняя концепция, которую нам следует рассмотреть, — это возможность ми- грации виртуальных машин с одной физической машины на другую. Большинство про- граммного обеспечения для виртуализации позволяют переносить виртуальные машины с одной функционирующей системы на другую, причем в некоторых случаях это про- исходит без прерывания обслуживания или потери соединения. Эта функциональная возможность называется динамической миграцией (live migration). Она полезна для равномерного распределения нагрузки, восстановления работы после сбоя, поддержки сервера и обеспечения общей гибкости системы. Сравнение технологий виртуализации Несмотря на то что разные технологии виртуализации основаны на разных концеп- циях, все они в конце концов приводят к одинаковым результатам. Администраторы об- ращаются к виртуальным системам точно так же, как это происходит в обычном режи- ме работы в сети. Основные отличия заключаются в том, что проблемы с аппаратным оборудованием сказываются на всех операционных системах одновременно (поскольку все они совместно используют эти устройства), а проблемы, связанные с содержанием ресурсов, должны устраняться на том же уровне, на котором реализована виртуализация (т.е. в гипервизоре). 24.2. Преимущества виртуализации Услышав столько комплиментов в адрес виртуальных вычислений, удивительно осознавать, что на ее разработку и коммерческую адаптацию ушло так много лет. Ос- новными факторами, способствующими принятию виртуальных технологий, являются экономия средств, снижение потребления электроэнергии, упрощенное обеспечение бесперебойной работы и высокая техническая маневренность. Стоимость является основным фактором во всех новых проектах в области информа- ционных технологий, и, оценивая технологии виртуализации, бизнесмены видят крат- косрочную выгоду, поскольку им не придется покупать несколько серверов. Вместо приобретения новых серверов для реализации новых приложений, админи- страторы могут запустить новые виртуальные машины и сэкономить деньги на покупке физических устройств и их дальнейшем обслуживании. Кроме того, резко снижаются
Глава 24. Виртуализация 1033 затраты на охлаждение, поскольку виртуальные серверы не генерируют тепла, что также приводит к дополнительной экономии. Упрощается работа центров обработки данных и удешевляется их обслуживание. Некоторые организации объединяют на одном виртуальном узле до 30 серверов, благо- даря чему они экономят место для стоек. Помимо прочего, виртуализация снижает нагрузку на окружающую среду. По неко- торым оценкам, прожорливыми центрами обработки данных потребляется около одного процента электричества, производимого в мире.2 Современные многоядерные централь- ные процессоры используются более эффективно, когда на них одновременно работает несколько виртуальных машин. Бесперебойность бизнеса, т.е. способность компании переживать физический и ло- гические кризисы с минимальными потерями, — это досадная и дорогостоящая про- блема для системных администраторов. Сложные подходы к восстановлению системы после сбоя упрощаются, если виртуальные серверы могут перемещаться с одной фи- зической машины на другую с помощью одной команды. Технологии такой миграции, поддерживаемые большинством платформ виртуализации, позволяют обеспечивать не- зависимость приложений от физического местоположения. Поскольку виртуальные серверы могут независимо обращаться к гипервизорам, ко- торые их поддерживают, управление серверами разрывает связь с физической реально- стью и может полностью описываться сценариями. Системные администраторы могут быстро удовлетворять потребности заказчиков в новых системах и приложениях, ис- пользуя шаблонное обеспечение серверов. Сценарии могут автоматизировать и упро- стить задачи управления типичными виртуальными системами. Загрузку, прекращение работы и миграцию виртуального сервера можно автоматизировать с помощью сцена- риев оболочки и даже задать расписание его работы с помощью демона cron. Снятые с производства операционные системы и приложения можно переносить с устаревшего аппаратного обеспечения на более современные архитектуры. Виртуализация увеличивает доступность. Динамическая миграция позволяет снимать физические серверы с обслуживания без прерывания работы службы. Обновление аппа- ратного обеспечения также не нарушает бизнес-процессы. Когда приходит время заме- нить устаревшую машину, виртуальная система немедленно мигрирует без болезненной модификации, инсталляции, тестирования и цикла переключений. Виртуализация обеспечивает строгое разделение между средами для разработки, тести- рования, размещения и производства даже в небольших компаниях. Исторически сложи- лось так, что поддержка этих раздельных сред для многих компаний была слишком до- рогим удовольствием, хотя этого могут требовать законы и стандарты. Отдельные среды могут быть выгодными; например, специалисты, занимающиеся обеспечением качества продукции, могут легко восстанавливать базовую конфигурацию среда для тестирования. С точки зрения немедленной отдачи, лишь немногие технологии предлагают так много преимуществ, как серверная виртуализация. Однако, как мы увидим в следующем разделе, виртуализация — это не панацея. 24.3. Практичный подход Необходимо тщательно планировать, контролировать и реализовывать переход в виртуализованную среду. Несогласованный подход приведет к появлению неупорядо- 2 Эта оценка приведена Джонатаном Куми (Jonathan Koomey) в его превосходном исследова- нии “Estimating total power consumption by servers in the U.S. and the world”.
1034 Часть III. Разное ченного набора неустойчивых и неуправляемых реализаций, которые принесут больше вреда, чем пользы. Более того, доверие заинтересованных лиц легко потерять: ошибки, сделанные на ранних этапах, могут усложнить будущие попытки перетянуть сопротив- ляющихся пользователей на новые платформы. Тише едешь — дальше будешь. Важно правильно выбрать системы, в которых одни приложения виртуализировать удобнее, чем другие. Службы, которые уже интенсивно используются, лучше оставить на физической системе, по крайней мере на начальном этапе. Среди других служб, ко- торые целесообразно оставить в покое, перечислим следующие. • Серверы интенсивного резервирования ресурсов или регистрационные узлы. • Приложения с высокой пропускной способностью, например системы для обна- ружения взлома. • Загруженные серверы для управления базами данных с вводом и выводом. • Лицензионные приложения с аппаратной защитой от копирования. • Приложения с особыми требованиями к аппаратному обеспечению, например ме- дицинские системы или некоторые системы для сбора научных данных. Хорошими кандидатами на виртуализацию являются следующие серверы. • Веб-серверы с выходом в Интернет, посылающие запросы межплатформенному программному обеспечению или базе данных. • Мало используемые изолированные серверы прикладных программ. • Системы для разработки программ, например серверы сборки или контроля версий. • Узлы для проверки качества продукции и среды для разворачивания программ. • Системы ядерной инфраструктуры, такие как каталоги LDAP, серверы DHCP и DNS, сервер времени и шлюзы SSH. Сначала организуйте миграцию небольшого количества менее важных систем. Это повысит доверие организации и обогатит опыт администратора. Очевидными претен- дентами на миграцию являются новейшие приложения, которые могут изначально иметь встроенные возможности для виртуализации. После стабилизации среды можно продолжить регулярный перенос систем. Для крупных организаций разумный темп ми- грации составляет от 25 до 50 серверов в год. Планируйте соответствующую поддержку инфраструктуры в новой среде. Планы по миграции должны поддерживаться соответствующими объемами дисковой памяти и се- тевыми ресурсами. Если несколько систем с одного узла окажутся в разных физических сетях, запланируйте соединение сетевых интерфейсов. Предусмотрите соответствующее оснащение для систем, которые будут использовать память в сети SAN. Правильно раз- мещайте подобные системы на одном и том же физическом аппаратном обеспечении, чтобы упростить инфраструктуру. В заключение примите меры, чтобы каждая виртуаль- ная машина имела запасную позицию, на которую ее можно перенести, если на первич- ной системе возникнут проблемы. Не запускайте все важные службы на одном и том же физическом аппаратном обе- спечении и не перегружайте системы слишком большим количеством виртуальных ма- шин. Благодаря быстрому совершенствованию серверного оборудования администрато- ры имеют широкие возможности для виртуализации. Многоядерная многопроцессорная архитектура — очевидный выбор для виртуальных машин, поскольку они уменьшают потребность в переключателях контекста и облегчают выделение ресурсов центрального процессора. Для виртуальных сред основные производители выпускают новые лезвий-
Глава 24. Виртуализация 1035 ные серверы (blade server) и предлагают быстродействующие средства ввода и вывода, а также большие объемы памяти. Полупроводниковые дисковые устройства отлично под- ходят для виртуализации, потому что они обеспечивают быстрый доступ и потребляют мало электроэнергии. 24.4. Виртуализация с помощью системы linux За звание чемпиона по виртуализации системы Linux соперничают две платформы: Хеп и KVM. В одном углу ринга — платформа Хеп, устоявшаяся, хорошо документиро- ванная, с широкой поддержкой от авторитетных дистрибьюторов. В другом углу рин- га — платформа KVM, которую Линус Торвальдс (Linus Torvalds) включил в ядро систе- мы Linux. Количество ее поклонников возрастает. Кроме того, она получила поддержку со стороны систем Ubuntu и Red Hat. В этом разделе мы не станем вмешиваться в их состязание, а сосредоточимся на во- просах администрирования систем, связанных с каждой из этих технологий. Введение в платформу Хеп Изначально Linux-ориентированная платформа Хеп была разработана Яном Праттом (Ian Pratt) как исследовательский проект Кембриджского университета (University of Cambridge). Со временем она стала мощной платформой для виртуализации, которая, благодаря производительности, безопасности и дешевизне, оказалась способной конку- рировать даже с коммерческими гигантами. Накладные расходы, связанные с эксплуа- тацией паравиртуального гипервизора виртуальной машины Хеп, составляют 0,1—3,5%, что намного меньше, чем у полностью виртуализованных платформ. Поскольку гипервизор Хеп является программой с открытым исходным кодом, су- ществует множество инструментов с разными уровнями поддержки ее функциональных возможностей. Исходный код платформы Хеп можно загрузить на сайте хеп. огд. Кроме того, она входит во многие дистрибутивные пакеты. Хеп — это автономный гипервизор, который функционирует непосредственно на физическом аппаратном обеспечении. Работающая виртуальная машина называется до- меном. Всегда существует по крайней мере один домен, который называется нулевым (или domO). Нулевой домен имеет полный доступ к аппаратному обеспечению, управ- ляет другими доменами и запускает драйверы всех устройств. Непривилегированные до- мены называются domU. Всеми доменами, включая domO, управляет гипервизор Хеп, ответственный за работу центрального процессора и управление памятью. Архитектуру платформы Хеп дополняют демоны, инструменты и библиотеки, обеспечивающие взаи- модействие между доменами domU, domO и гипервизором. Несколько инструментов управления упрощают решение общих задач управления платформой Хеп, таких как загрузка и остановка, конфигурирование и создание гостей. Хеп Tools — это коллекция сценариев на языке Perl, которые упрощают создание доме- нов domU. Сценарий MLN, или Manage Large Networks, — это еще один сценарий на языке Perl, создающий виртуальные сети на основе ясных и понятных файлов конфигу- рации. ConVirt — это превосходный инструмент с графическим пользовательским интер- фейсом для управления гостями. Он обеспечивает динамическую миграцию по принципу “drag-and-drop”, мультисерверную поддержку без агентов, доступ к приборным интер- фейсам и их конфигурирование, а также шаблонное создание новых виртуальных машин. Для поклонников командной строки предусмотрена также встроенная утилита хт.
1036 Часть III. Разное Дистрибутивные пакеты Linux по-разному поддерживают платформу Хеп. Компания Red Hat сначала включала платформу Хеп в свои дистрибутивные пакеты, пока не от- казалась от нее в пользу конкурирующего программного обеспечения KVM. Платформа Хеп хорошо поддерживается системой SUSE Linux, особенно в версии Enterprise 11. Разработчики канонической системы Ubuntu Linux выбрали странный подход к плат- форме Хеп, нерешительно поддерживая ее вплоть до появления версии 8.10, в которой они отказались от платформы Хеп и предпочли программное обеспечение KVM (хотя платформа Хеп по-прежнему упоминается в документации). После инсталляции способ использования платформы Хеп мало чем отличается в разных дистрибутивных пакетах. В общем, для крупного развертывания виртуализации на основе платформы Хеп мы ре- комендуем использовать системы Red Hat или SUSE. Основы платформы Хеп Сервер Linux Хеп требует большого количества демонов, сценариев, конфигураци- онных файлов и инструментов. Большинство элементов этой головоломки перечисле- но в табл. 24.1. Конфигурационный файл каждого домена на платформе Хеп в каталоге /etc/xen содержит информацию о том, какие виртуальные ресурсы доступны для до- мена domU, например дисковые устройства, центральный процессор, память и сетевые интерфейсы. Каждый домен domU имеет свой конфигурационный файл. Формат этого файла очень гибкий и позволяет администраторам точно контролировать ограничения, накладываемые на каждого гостя. Если в подкаталог auto добавлена символическая ссылка на конфигурационный файл домена domU, то гостевая операционная система будет автоматически запускаться во время загрузки. Таблица 24.1. Компоненты платформы Хеп Путь .................................................. / . .. / /etc/xen Каталог основной конфигурации xend-config.sxp Высокоуровневый файл конфигурации демона xend . auto Конфигурационные файлы гостевой операционной системы для автоматического scripts /var/log/xen /usr/sbin/xend /usr/sbin/xm запуска во время загрузки Вспомогательные сценарии, создающие сетевые интерфейсы и т.д. Регистрационные файлы платформы Хеп Главный управляющий демон платформы Хеп Инструмент для управления гостевым доменом на платформе Хеп Демон xend обеспечивает создание доменов domU и миграцию, а также решает дру- гие задачи управления. Он должен всегда находиться в работе и, как правило, запускает- ся во время загрузки. Его файл конфигурации /etc/xen/xend-config.sxp задает па- раметры соединения для гипервизора и ограничения ресурсов для домена domO. Кроме того, он конфигурирует функциональные возможности для динамической миграции. Ш Разреженные файлы упоминаются также в разделе 10.4. Диски гостевых доменов обычно хранятся в виртуальных блочных устройствах (virtual block devices — VBD) в домене domO. Устройство VBD может быть соединено со специ- альным ресурсом, например физическим дисковым запоминающим устройством или логическим томом. Кроме того, оно может представлять собой закольцованный файл (loopback file), также известный как файловое устройство VBD (file-backed VBD), соз-
Глава 24. Виртуализация 1037 данное программой dd. Если используется специальный диск, то производительность такого устройства оказывается более высокой, но файлы являются более гибкими и могут управляться с помощью обычных команд системы Linux (таких, как mv или ср) в нулевом домене. Файлы, на основе которых создается такое устройство, являются раз- реженными и при необходимости могут увеличиваться. Если в системе возникает узкое место с точки зрения производительности, то фай- ловое устройство VBD обычно оказывается лучшим выбором. Если вы передумаете, устройство VBD легко переключить на специальный диск. Аналогично виртуальные сетевые интерфейсы (VIF) можно установить многими спо- собами. По умолчанию используется мостовой режим (bridged mode), в котором каждый гостевой домен является узлом той же сети, что и главный узел. Маршрутизированный режим и режим NAT конфигурируют гостевые домены как частные сети, доступные друг для друга и нулевого домена, но скрытые от остальной части сети. Более сложные кон- фигурации включают связанные сетевые интерфейсы и сети VLAN для гостей из разных сетей. Если ни одна из этих возможностей не удовлетворяет вашим требованиям, можно настроить сценарии платформы Хеп для реализации практически любых пожеланий. Инсталляция гостя на платформе Хеп с помощью программы virt-install Для простой инсталляции гостя существует инструмент virt-install, являющийся частью приложения virt-manager для системы Red Hat.3 Инструмент virt-install — это утилита, запускаемая из командной строки для инсталляции операционной системы. Она принимает средства инсталляции из разных источников, например устройства сетевой файловой системы NFS, физического CD- или DVD-привода или местоположения HTTP. Например, инсталляция гостевого домена может быть выполнена с помощью сле- дующей инструкции. redhat$ sudo virt-install -n chef -f /vm/chef.img -1 http://exainple.com/myos —r 512 —nographics Это типичный гостевой домен на платформе Хеп с именем “chef,” дисковым устрой- ством VBD, размещенным в каталоге /vm/chef .img, и средой инсталляции, получен- ной с помощью протокола HTTP. Этот экземпляр имеет 512 двоичных Мбайт (MiB) оперативной памяти и не использует во время инсталляции графическую поддержку X Windows. Утилита virt-install загружает файлы, необходимые для начала инсталля- ции, а затем запускает процесс инсталлятора. Вы увидите пустой экран и пройдете через все стандартные этапы инсталляции систе- мы Linux в текстовом режиме, включая конфигурирование сети и выбор пакета. После инсталляции гостевой домен перезагружается и готов к использованию. Для отсоедине- ния от гостевой консоли и возвращения в домен domO выполните команду <Control-]>. £□ Более подробно система VNC обсуждается в разделе 30.2. Несмотря на то что в данном примере волшебное заклинание virt-install осу- ществляет текстовую инсталляцию, возможна также графическая поддержка этого про- цесса с помощью системы Virtual Network Computing (VNC). Конфигурация домена хранится в файле /etc/xen/chef. Этот файл выглядит сле- дующим образом. 3 Для поддержки инструмента virt-install в системе Ubuntu инсталлируйте пакет python- virtinst.
1038 Часть III. Разное name = "chef" uuid = "a85e20f4-dllb-d4f7-1429-7339bld0d051" maxmem = 512 memory = 512 vcpus = 1 bootloader = "/usr/bin/pygrub" on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" vfb = [ ] disk = [ "tap:aio:/vm/chef.dsk,xvda,w" ] vif - [ "mac=00:16:3e:le:57:79,bridge=xenbrO" ] Как видим, по умолчанию сетевой интерфейс установлен в мостовой режим. В этом случае устройство VBD представляет собой “блочный” файл, обеспечивающий более высокую производительность, чем стандартный кольцевой файл. Файл образа диска, допускающий запись, предоставлен гостю под именем /dev/xvda. Это специфическое определение дискового устройства tap: aio рекомендовано разработчиками платформы Хеп по соображениям производительности. Инструмент хт удобен для ежедневного управления виртуальными машинами, на- пример для их запуска и остановки, присоединения к их консолям и исследования те- кущего состояния. Ниже показана процедура запуска гостевого домена с последующим присоединением к консоли chef. Идентификаторы присвоены в порядке возрастания по мере создания гостевых доменов. При перезагрузке узла они восстанавливаются. redhat$ sudo xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 2502 2 r------- 397.2 chef 19 512 1 -b------ 12.8 redhat$ sudo xm console 19 Для того чтобы ввести в действие любую настройку гостевого домена, например при- соединение другого диска или перевод сети из мостового режима в режим NAT, необхо- димо отредактировать гостевой конфигурационный файл в каталоге /etc/xen и переза- грузить гостя. Подробную информацию о дополнительных параметрах гостевых доменов можно найти на справочной странице xmdomain. cfg. Динамическая миграция на платформе Хеп Динамическая миграция — это процесс переноса домена domU с одного физическо- го узла на другой без прекращения работы службы. С практической точки зрения это один из наиболее удобных и самых магических трюков виртуализации, который могут выполнить системные администраторы. Поскольку поддерживаются открытые сетевые соединения, то ни сеанс протокола SSH, ни одно активное соединение HTTP не будут потеряны. Хорошим поводом для динамической миграции является добавление ап- паратного обеспечения, обновление операционной системы и перегрузка физических серверов. Для успешного осуществления миграции важно, чтобы запоминающие устройства использовались совместно. Любое запоминающее устройство, необходимое для домена domU, например файл образа диска, на котором хранится виртуальная машина, должно быть доступным для обоих узловых серверов. Динамическую миграцию виртуальных ма- шин с файловой поддержкой выполнить легче всего, потому что они обычно содержатся в одном переносимом файле. Однако совместное использование файлов между система-
Глава 24. Виртуализация 1039 ми возможно также в сетях SAN и NAS, а также в протоколах NFS и iSCSI. Несмотря на то что устройство VBD используется совместно несколькими пользователями, примите меры, чтобы домен domU единовременно функционировал только на одном физиче- ском сервере. Файловые системы Linux не поддерживают непосредственный параллель- ный доступ к нескольким узлам. Кроме того, поскольку IP- и МАС-адреса виртуальной машины следуют за ней от одного узла к другому, каждый сервер должен находиться на том же самом уровне 2 и в той же самой IP-подсети. Как только виртуальная машина посылает трафик по сети, сетевое аппаратное обе- спечение узнает новое местоположение МАС-адреса. Если все эти основные требования удовлетворены, все, что нужно для выполнения миграции, — внести новые изменения в конфигурационный файл гипервизора /etc /xen/xend-conf ig. sxp. Соответствующие параметры перечислены в табл. 24.2; в стан- дартном процессе инсталляции платформы все они закомментированы. Внеся измене- ния, запустите демон xend заново, выполнив команду /etc/init. d/xend restart. Таблица 24.2. Параметры динамической миграции в конфигурационном файле xend xend-relocation-server Включает механизм миграции; установить равным yes xend-relocation-port xend-relocation-address Сетевой порт, используемый для выполнения миграции Интерфейс, прослушиваемый для миграционных соединений. Если не задан, платформа Хеп прослушивает все интерфейсы в домене domO xend-relocation-hosts-allow Узлы, из которых разрешены соединения8 а Этот параметр никогда нельзя оставлять пустым; в противном случае будут разрешены все соединения со всех узлов. В процессе миграции виртуальной машины между узлами образ памяти домена domU передается по сети в незашифрованном виде. Если гость хранит в памяти конфиденци- альные данные, администраторы обязаны обеспечивать секретность. Перед выполнени- ем миграции файл конфигурации гостя должен находиться как на сервере источника, так и на сервере назначения. Если местоположение файлов образа диска на разных узлах разное (например, если один сервер монтирует совместно используемое запоминающее устройство в каталоге /хеп, а другой — в каталоге /vm), то это различие должно отра- жаться в параметре disk = в файле конфигурации домена. Сама миграция выполняется очень просто. redhat$ sudo xm migrate —live chef server2.exanple.com Предполагая, что гостевой домен chef функционирует, команда переносит его на дру- гой узел платформы Хеп, server2. example. com. Из-за того что флаг —live пропу- щен, он останавливает свою работу перед миграцией. Поучительно применить команду ping к IP-адресу домена chef во время миграции, чтобы увидеть отброшенные пакеты. Платформа KVM KVM (Kernel-based Virtual Machine) — это инструмент полной виртуализации, вклю- чаемый в магистральное ядро системы Linux начиная с версии 2.6.20. Необходимым условием его применения является наличие расширений центрального процессора Intel
1040 Часть III. Разное VT и AMD-V для поддержки виртуализации.4 В операционной системе Ubuntu эта техно- логия виртуализации предусмотрена по умолчанию, а компания Red Hat переключилась с платформы Хеп на программу KVM после поглощения компании Qumranet, разрабо- тавшей программу KVM. Поскольку виртуализация KVM поддерживается аппаратным обеспечением центрального процессора, поддерживаются многие гостевые операцион- ные системы, включая Windows. Для работы этого программного обеспечения необходи- ма также модифицированная версия эмулятора процессора QEMU. На платформе KVM ядро операционной системы Linux функционирует как гиперви- зор; управление памятью и диспетчеризация выполняются с помощью ядра узла, а го- стевые машины представляют собой обычные процессы Linux. Этот уникальный подход к виртуализации сулит огромные преимущества. Например, сложность, порождаемая многоядерными процессорами, устраняется с помощью ядра системы, и для их под- держки не требуется вносить никаких изменений в гипервизор. Команды Linux, такие как top, ps и kill, управляют виртуальными машинами так, будто они являются обычными процессами. Интеграция с системой Linux является без- упречной. Следует предупредить администраторов о том, что KVM — относительно новая тех- нология, поэтому перед использованием ее следует тщательно протестировать. На сайте KVM зарегистрировано множество проблем, связанных с несовместимостью и возни- кающих при запуске гостей, представляющих собой разные типы операционных систем. Сообщается также о частом прерывании миграции между разными версиями программ- ного обеспечения KVM. Об этом следует помнить. Инсталляция платформы KVM и ее использование Несмотря на то что технологии, лежащие в основе платформ Хеп и KVM, принципи- ально отличаются друг от друга, инструменты, инсталлирующие гостевые операционные системы и управляющие ими, похожи друг на друга. Как и на платформе Хеп, для созда- ния новых гостей по технологии KVM можно использовать программу virt-install, а для управления ими — команду virsh.5 Для работы этих утилит необходима библиотека libvirt, разработанная компанией Red Hat. Перед началом инсталляции необходимо сконфигурировать узел так, чтобы он под- держивал работу сетей в гостевых операционных системах.6 В большинстве конфигура- ций для организации моста, обеспечивающего сетевую связность узлов в каждой гостевой системе, используется один физический интерфейс. В системе Red Hat конфигурацион- ные файлы сетевого устройства хранятся в каталоге /etc/sysconf ig/network-scripts. Требуется два файла устройства: для моста и физического устройства. В приведенном ниже примере pethO — это физическое устройство, a ethO — мост. /etc/sysconf ig/network-scripts/pethO DEVICE=pethO 4 Имеет ли ваш центральный процессор эти расширения? Выполните следующую команду egrep ’ (vmx| svm) ’ /proc/cpuinfo. Если эта команда ничего не выведет на экран, значит, рас- ширений нет. В некоторых операционных системах, для того чтобы увидеть расширения, необхо- димо включить их в настройках BIOS. 5 При желании команду virsh можно использовать и для управления доменом domU на плат- форме Хеп. 6 Это в равной степени относится и к платформе Хеп, но демон xend берет эту работу на себя, создавая интерфейсы в фоновом режиме.
Глава 24. Виртуализация 1041 0NB00T=yes BRIDGE=ethO HWADDR=XX:XX:XX:XX:XX:XX /etc/sysconfig/network-scripts/ethO DEVICE=ethO BOOTPROTO=dhcp ONBOOT=yes TYPE=Bridge Здесь устройство ethO получает IP-адрес с помощью протокола DHCP. Флаги, передаваемые программе virt-install, могут немного отличаться от фла- гов, используемых при инсталляции платформы Хеп. Например, флаг —hvm означает, что для виртуализации гостя должно использоваться аппаратное обеспечение, а не пара- виртуализация. Кроме того, аргумент —connect гарантирует, что по умолчанию будет выбран правильный гипервизор, потому что утилита virt-install поддерживает не- сколько гипервизоров. В заключение, чтобы получить выгоду от возможностей платфор- мы KVM, рекомендуется использовать файл -accelerate. Следовательно, пример пол- ной команды для инсталлирования гостевого сервера Ubuntu с диска CD-ROM должен выглядеть следующим образом. ubuntu$ sudo virt-install —connect qemu:///system -n UbuntuHardy -r 512 -f **/ubuntu-hardy,img -s 12 -c /dev/dvd —os-type linux —accelerate —hvm -vnc Would you like to enable graphics support? (yes or no) Если инсталляционный диск DVD для системы Ubuntu вставлен в дисковод, эта команда запускает процесс инсталляции и сохраняет гостя в файле ~/ubuntu-hardy, img, позволяя увеличивать его размер до 12 Гбайт. Поскольку мы не указали ни флаг -nographics, ни флаг —vnc, утилита virt-install спрашивает, включать ли графику. Утилита virsh запускает свою собственную оболочку, которая выполняет комавды. Для того чтобы открыть эту оболочку, наберите команду virsh —connect qemu:/// system. Следующая серия команд демонстрирует некоторые основные функциональ- ные возможности утилиты virsh. Для того чтобы увидеть полный список этих функ- ций, наберите команду help в оболочке или просмотрите справочную страницу. ubuntu$ sudo virsh —connect qemu:///system virsh # list —all Id Name State 3 UbuntuHardy running 7 Fedora running Windows2003Server shut off virsh # start Windows2003Server Domain WindowsServer started virsh # shutdown FedoraExample Domain FedoraExample is being shutdown virsh # quit Похоже, что динамическая миграция на платформе KVM пока находится на стадии разработки; ее реализации в разных версиях резко отличаются друг от друга. Миграции между системами с разной архитектурой центрального процессора могут потребовать
1042 Часть III. Разное специальных “заплат”. Мы не рекомендуем полагаться на механизм динамической ми- грации в платформе KVM в промышленной среде, пока эта технология не станет доста- точно устойчивой. 24.5. Зоны И КОНТЕЙНЕРЫ СИСТЕМЫ SOLARIS Компания Sun раньше многих реализовала виртуализацию на уровне операцион- ной системы, предложив в системе Solaris 10 (которая относится примерно к 2005 году) концепцию зон и контейнеров. Обширная интерактивная документация и сообщество активных пользователей привели к широкой адаптации и признанию этой технологии со стороны бизнеса. Гибкость и богатый набор инструментов для управления также спо- собствуют продажам средств виртуализации для системы Solaris. Зоны и контейнеры нельзя назвать средствами виртуализации, характерными ис- ключительно для системы Solaris. Например, проект xVM включает в себя гиперви- зор LDOM для виртуальных машин, основанный на технологии Хеп, наряду с другими мощными средствами управления для развертывания и контроля за большим количе- ством гостевых систем. Технология, основанная на аппаратном обеспечении компании Sun (наряду с системами многих других производителей), может выполнять физическое разделение устройств на электрическом уровне, позволяя нескольким операционным системам параллельно работать на одном и том же шасси. В этой книге мы не соби- раемся обсуждать дополнительные технологии, но читателям стоит заглянуть на сайты, посвященные многочисленным устройствам компании Sun. Зоны и контейнеры отличаются от других инструментов виртуализации, поэтому мы начнем с быстрого обзора, который поможет нам не углубляться в некоторые темы. Термины “зона” и “контейнер” во многом являются синонимами. В самом стро- гом смысле, зоны — это защищенная среда выполнения, а контейнер — это зона плюс управление ресурсами. На практике эти термины эквивалентны, и именно так мы будем их использовать в данной главе. Все системы Solaris имеют “глобальную зону”, которая запускает ядро и все процес- сы в системе, включая процессы из других зон. Неглобальная зона — это виртуальная система Solaris, работающая наряду с глобальной зоной. Сетевой трафик и выполнение процессов в неглобальной зоне скрыты от других неглобальных зон, но все процессы являются видимыми в глобальной зоне. С целью обеспечения безопасности важно огра- ничить доступ системных администраторов в глобальную зону. Существует два типа зон: целостная (whole-root) и разреженная (sparse). Целостная зона содержит копии файлов собственной операционной системы и независимых фай- ловых систем, требуя при этом намного больше места для хранения на запоминающих устройствах. Разреженная зона совместно с глобальной использует несколько своих файловых систем, монтируя их только для чтения. Пулы ресурсов являются коллекциями системных ресурсов, таких как процессоры, которые можно распределять между зонами. Во всех системах существует по крайней мере один стандартный пул ресурсов. Все зоны, включая глобальную, должны иметь хотя бы один пул ресурсов. Можно также создавать несколько пулов ресурсов для рас- пределения доступных системных ресурсов между функционирующими зонами. Пул ресурсов состоит из, как минимум, одного набора ресурсов (который в настоя- щее время ограничен частью ресурсов центрального процессора) и алгоритма их распре- деления. Несколько зон могут совместно использовать один пул ресурсов. В этом случае
Глава 24. Виртуализация 1043 распределитель может определять, как совместно использовать центральный процессор среди зон, использующих пул ресурсов. Зоны поддерживают множество разных алгоритмов распределения ресурсов для раз- ных ситуаций, но мы сосредоточимся на самом популярном — “справедливом разделе” (“fair share scheduling”). Рассмотрим конкретный пример. Представьте себе систему с двумя физическими центральными процессорами. Эта система собирается запустить две виртуальные си- стемы Solaris: одну со специализированным приложением, требующим по крайней мере одного полноценного центрального процессора, а другую — с облегченным веб- сервером, не требующим особенных ресурсов. Реализация этой архитектуры в системе Solaris представлена на рис. 24.4. Контейнер 2 Контейнер 3 Контейнер 1 Глобальная зона Рис, 24,4, Пример контейнеров в системе Solaris На рис. 24.4 показаны три контейнера: контейнер для специализированного при- ложения, веб-сервер и оригинальный (глобальный) экземпляр системы Solaris. Кроме того, существует три зоны: для лицензионного приложения, веб-сервера и глобальная. Помимо них, есть два пула ресурсов: по одному для каждого центрального процессора. Веб-сервер и глобальная зона совместно используют стандартный пул ресурсов, со- держащий один центральный процессор и реализующий алгоритм справедливого раз- дела. Каждая из этих зон имеет свою долю (которые не изображены на рисунке), т.е. ресурсы центрального процессора разделяются поровну между глобальной зоной и зо- ной веб-сервера. Спецализированное приложение использует отдельный пул ресурсов со специальным центральным процессором. Система Solaris имеет несколько утилит командной строки для управления контей- нерами, зонами и ресурсами. Наиболее важно то, что каждая зона и пул ресурсов име- ют инструмент конфигурации и инструмент управления: zonecfg, zoneadm, poolcfg и pooladm. С помощью команды pooladm можно создать пул ресурсов до его присвоения зоне. Для включения пулов используется флаг -е, а затем выполняется команда pooladm без аргументов, чтобы увидеть текущее состояние пула. Solaris$ sudo pooladm -е solaris$ sudo pooladm system default string system.comment
1044 Часть III. Разное int system.version 1 boolean system.bind-default true string system.poold.objectives wt-load Мы сократили довольно длинный вывод; команда продолжает печатать информацию о текущем состоянии пула и доступности центрального процессора. Стандартный пул называется pool_default. Он содержит все доступные ресурсы центрального процессора. Команда poolcfg создает новый пул. В серии команд, представленных ниже, мы выделяем отдельный центральный процессор для набора специализированных ресурсов, присваиваем этот набор ресурсов новому пулу ресурсов и активизируем процессор. solaris$ sudo poolcfg -с 'create pset proprietary-pset (uint pset.min=l; uint pset.max=l) ' solaris$ sudo poolcfg -c 'create pool proprietary-pool' Solaris $ sudo pooladm -c Теперь мы создаем зону с помощью команд zoneadm и zonecfg. Выполнение коман- ды zonecfg открывает новую оболочку конфигурации для зоны. Следовательно, этот инструмент поддерживает оболочечные функциональные свойства, такие как автозапол- нение при нажатии клавиши <ТаЬ> и “горячие” клавиши для перемещения курсора. Как минимум, должны выполняться следующие условия. • Зона создана. • Для зоны задан путь к запоминающему устройству для зонных файлов и файловых систем. • Для зоны задан независимый 1Р-адрес. • Зоне присвоен один из активных системных интерфейсов. • Зоне выделен созданный выше пул ресурсов. Рассмотрим команды, выполняющие эти действия. solaris$ sudo zonecfg -z proprietary-zone zonecfg:proprietary-zone> create zonecfg:proprietary-zone> set zonepath=/zones/proprietary-zone zonecfg:proprietary-zone> set autoboot=true zonecfg:proprietary-zone> add net zonecfg:proprietary-zone:net> set address=192.168.10.123 zonecfg:proprietary-zone:net> set physical=el000g0 zonecfg:proprietary-zone:net> end zonecfg:proprietary-zone> set pool=proprietary-pool zonecfg:proprietary-zone> verify zonecfg:proprietary-zone> commit zonecfg:proprietary-zone> exit Обратите внимание на то, что команда zonecfg просит вас указать объект, с кото- рым вы в настоящее время работаете. В этот момент происходит конфигурирование зоны, но на самом деле она еще не инсталлирована и не готова к работе. Это полно- ценная система Solaris, которой нужен пакет инсталляции, как любой нормальной опе- рационной системе. Утилита zoneadm инсталлирует, загружает и выполняет другие операции над зоной. Solaris $ sudo zoneadm -z proprietary-zone install Preparing to install zone <proprietary-zone>. Creating list of files to copy from the global zone.
Глава 24. Виртуализация 1045 solaris$ sudo zoneadm -z proprietary-zone boot Solaris$ sudo zoneadm list global proprietary-zone После запуска зоны вызов команды zlogin -С proprietary-zone приводит к со- единению с ее консолью. Процесс загрузки зоны напоминает загрузку физической си- стемы, поэтому соединение с утилитой zlogin перед загрузкой приводит к выводу на экран всей информации во время процесса загрузки. Необходимо выполнить обычное конфигурирование новой системы, например выбрать язык и метод аутентификации. Осталось создать зону для нашего веб-сервера. Поскольку зона веб-сервера делит стандартный пул ресурсов с глобальной зоной, нет необходимости создавать новый пул. Вместо этого мы просто создадим зону с помощью утилиты zonecfg, как показано выше, но с параметром pool=pool_default. Концепция зон и контейнеров намного глубже, чем мы описали в этом разделе. Она предусматривает функциональные возможности для миграции зон между физическими системами (хотя динамическая миграция не поддерживается), ZFS-ресурсы для неболь- ших целостных зон и “фирменные зоны” (“branded zones”), поддерживающие выполне- ние бинарных модулей, принадлежащих другим платформам (например, Linux), в яйфе системы Solaris. 24.6. Разделы рабочей нагрузки в системе AIX Компания IBM уже давно занимается виртуализацией. Ее сотрудники изобрели эту концепцию еще в 1960-х годах, но не реализовали ее, пока в конце 2007 года не появи- лась версия AIX 6.1. Любая система, способная выполнить программную платформу AIX 6, поддерживает разделы рабочей нагрузки (WPAR). (Эта технология отличается от различных реализаций логического разделения, предлагавшихся компанией IBM в вер- сиях, предшествующих версии 4.3.) Разделы WPAR работают в изолированной среде выполнения. Процессы могут взаи- модействовать только с процессами, находящимися в том же самом разделе. Сигналы и события в глобальной среде не влияют на разделы и наоборот. Разделы WPAR могут иметь собственные сетевые адреса. Разделы WPAR бывают двух видов: системные и прикладные. • Системный раздел WPAR совместно с глобальным окружением использует только ядро системы AIX (по существу, узел). Приложение, работающее в системе WPAR, функционирует так, будто оно запущено в независимом экземпляре системы AIX с собственным демоном inetd для обеспечения сетевой автономии. • Прикладной раздел WPAR выполняет отдельное приложение в изолированной среде. Он использует все файловые системы совместно с глобальным окружением и не может предоставить возможности для удаленного доступа. После выполнения приложения прикладной раздел WPAR продолжает существовать. Компания IBM предоставляет несколько разных инструментов для управления раз- делами WPAR, продолжая традицию обеспечения удобного управления, характерную для системы. Здесь мы обсудим интерфейс командной строки, но администраторы должны знать, что в типичной ситуации для системы AIX существует полноценный интерфейс SMIT и программа WPAR Manager, представляющая собой веб-интерфейс для централи- зованного управления несколькими серверами и их разделами рабочей нагрузки.
1046 Часть III. Разное Мы создаем систему WPAR с помощью команды mkwpar. Для нее нужен только один аргумент -п, чтобы задать имя системы. Таким образом, команда mkwpar -n mario соз- дает раздел с именем “mario.” Команда mkwpar создает файловые системы, инсталли- рует соответствующие наборы файлов и готовит подсистемы и службы. Этот процесс занимает мало времени; после его завершения для запуска системы WPAR необходимо выполнить команду startwpar mario. Каталог /wpars в глобальной среде содержит файловые системы для раздела mario. Разделы WPAR из глобальной среды можно перечислить с помощью команды Iswpar. aix$ sudo Iswpar Name State Type Hostname Directory mario A S mario /wpars/mario Для того чтобы соединить корень с консолью, используется команда clogin mario. Что может быть проще? Этот простой пример не учитывает множество важных фактов и возможностей для настройки. Например, новое программное обеспечение нельзя инсталлировать в раз- деле mario, потому что файловые системы /usr и /opt по умолчанию монтируются только для чтения, чтобы сэкономить память запоминающего устройства. Кроме того, не доступен ни один сетевой интерфейс. Упрощенная процедура, описанная выше, так- же игнорирует превосходные возможности, которые компания IBM предоставляет для управления ресурсами и которые упрощают контроль над использованием центрального процессора, памяти, виртуальной памяти и других ресурсов разделом WPAR. Для создания более полезного экземпляра можно снабдить команду mkwpar допол- нительными аргументами. Приведенная ниже процедура создает раздел WPAR со сле- дующими атрибутами. • Имя WPAR — mario (-n). • Настройки для разрешения имен наследуются у глобального экземпляра (-г). • Созданы частные, допускающие запись файловые системы /opt и /usr (-1). • Раздел WPAR использует IP-адрес 192.168.10.15 на интерфейсе епО из глобального раздела WPAR (-N). • Доля центрального процессора, выделенного данному разделу WPAR, колеблется от 5 (минимум) до 15% (условный максимум); абсолютный предел составляет 25% (-R). aix$ sudo mkwpar -n mario -r -1 -N interface=en3 address=192.168.10.15 netmask-255.255.255.0 broadcast=192.168.10.255 -R active=yes C₽U=5%-15%,25% Этот вызов более подробный по сравнению с предыдущим вызовов команды mkwpar и выполняется дольше из-за дублирования файловых систем /usr и /opt. Для модификации раздела после его создания следует использовать команду chwpar. С помощью команды stopwpar можно прекратить работу раздела, а с помощью коман- ды rmwpar — удалить его. Прикладные разделы WPAR обрабатываются аналогично. Вместо команды mkwpar для создания прикладного раздела WPAR используется команда wparexec. Ее параме- тры в целом идентичны параметрам команды mkwpar, но вместо имени следует указать приложение, которое выполняется как аргумент. Например, для того чтобы запустить веб-сервер Apache в своем прикладном разделе WPAR, следует просто выполнить ко- манду wparexec /usr/local/sbin/httpd.
Глава 24. Виртуализация 1047 24.7. Программное обеспечение Integrity Virtual Machines в системе HP-UX Если целью сотрудников компании HP было запутать администраторов неорганизо- ванной массой возможных подходов к виртуализации, то они ее достигли. Программное обеспечение Integrity Virtual Machines распределяет ресурсы аппаратного обеспечения среди нескольких гостевых операционных систем на отдельном низкоуровневом серве- ре. Для более крупных систем с несколькими ядрами компания HP разработала более мощное программное обеспечение Virtual Partitions или vPars. Кроме того, служба разде- ления аппаратного обеспечения nPartitions обеспечивает истинное разделение ресурсов среди работающих серверов на электрическом уровне. Эти технологии совместно с про- граммным обеспечением компании HP для кластеризации получили обобщенное назва- ние Virtual Server Environment. В этом разделе рассматривается только программное обеспечение Integrity Virtual Machines (IVM). ГУМ — это технология полной виртуализации. Немодифицированные версии систем Windows и Linux могут выполнять его на узле HP-UX. Каждый гость по- лучает заранее сконфигурированную долю времени центрального процессора. Память ц ресурсы запоминающих устройств также допускают настройку. Можно конфигурировать неограниченное количество гостей, но количество функционирующих виртуальных шин ограничено числом 256. Сеть для гостевых машин состоит из трех компонентов. • Адаптер физической сети в узле, который называется pNIC. • Адаптер гостевой сети, который называется виртуальным интерфейсом NIC или vNIC. • Виртуальный коммутатор, или vswitch, создающий сеть между узлом и одним или несколькими гостями. Сложность различных сетевых конфигураций, возникающих при инсталляций вир- туальных машин Integrity, ошеломляет, но в то же время это обеспечивает гибкость си- стемы. Для иллюстрации создадим отдельный виртуальный коммутатор, выполняющий отображение в ту же сеть, в которой находится узел. Это простейшая конфигурация, ко- торая эквивалентна мостовым сетям, упомянутым ранее. Почти как на платформе Хеп, узел может предоставлять гостям ресурсы запоми- нающего устройства в виде физических дисков, DVD, лентопротяжных устройств или файлов операционной системы узла. Кроме того, как и на платформе Хеп, достичь максимальной производительности работы запоминающего устройства иногда доволь- но сложно. Инструкции по сложной конфигурации сети и методам оптимизации запоминающих устройств можно найти в руководстве Installation, Configuration, and Administration Guide для системы HP-UX. Создание и инсталляция виртуальных машин Команды, создающие виртуальные машины, инсталлирующие их и управляющие ими, являются мощными и в то же время простыми. Имя каждой команды начинается с префикса hpvm, а остальная часть имени описывает требуемое действие. Например, команда для создания новой виртуальной машины называется hpvmcreate.
1048 Часть III. Разное Для управления конфигурацией гостевых операционных систем в каждой команде используются различные аргументы и нет статических файлов, которыми мог бы управ- лять администратор. Изменения в настройке гостя осуществляются с помощью команды hpvmmodify. Прежде чем создать виртуальную машину, следует обеспечить доступ к ресурсам ее запоминающих устройств и сети. В приведенном ниже примере сначала мы создаем файловую систему на одном из физических дисков для хранения гостя, а затем вирту- альный коммутатор для обеспечения сетевой связности гостя. Кратко опишем процесс создания виртуальной машины. • Создаем ресурсы запоминающих устройств для файлов гостя. • Создаем виртуальный коммутатор для сетевой связности. • Создаем виртуальную машину. • Запускаем и инсталлируем виртуальную машину. В серии приведенных ниже команд мы используем команду mkf s для создания фай- ловой системы на физическом устройстве disk3, произвольном диске, который оказал- ся доступным в нашей лабораторной системе. В результате он будет хранить гостевую операционную систему, приложения и данные. Файл монтируется в каталоге /vdev, и, в заключение, команда hpvmdevmgmt (не путайте ее с командой hpwndkwlvyfm) создав! запоминающее устройство с именем diskl. hp-ux$ sudo mkfs -F vxfs -o large files /dev/disk/disk3 hp-ux$ sudo mount /dev/disk/disk3 /vdev/vmOdisk/ hp-ux$ sudo hpvmdevmgmt -S 8G /vdev/vmOdisk/diskl На следующем шаге создается виртуальный коммутатор для гостя. Один виртуаль- ный коммутатор может использоваться несколькими гостями. hp-ux$ lanscan Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPt Path Address In# State NamePPA ID Type Support Mjr# 0/0/3/0 0x00306EEA9237 0 UP lanO snapO 1 ETHER Yes 119 0/1/2/0 0x00306EEA720D hp-ux$ sudo hpvmnet -c -S hp-ux$ sudo hpvmnet -b -S 1 UP lanl snapl vmOswitch -n 0 vmOswitch 2 ETHER Yes IIS' Здесь удобная команда lanscan находит все системные сетевые интерфейсы. Нам необходим правильный идентификатор для сетевого интерфейса в правильной сети; в данном случае это идентификатор 0 в сети 1ап0. Используя команду hpvmnet и имя 1ап0, мы создаем коммутатор, а затем запускаем его с помощью следующей команды, передавая ей аргумент -Ь. Создав необходимые ресурсы, можно приступать к созданию самой виртуальной машины. hp-ux$ sudo hpvmcreate -₽ vmO -О hpux -r 26 -a network: lan: vswitch: vmOswitch -a disk:scsi:-.file:/vdev/vmOdisk/diskl hp-ux$ sudo hpvmstart -₽ vmO Эта команда создает виртуальную машину с именем vmO, выделяет два двоичных ги- габайта памяти, использует виртуальный коммутатор vmOswitch и выбирает запоминаю- щее устройство, созданное нами ранее. Затем новая виртуальная машина запускается с помощью команды hpvmstart. Инсталляция виртуальной машины идентична инсталляции физической машины с консоли. Соединение с консолью осуществляется с помощью команды hpvmconsole
Глава 24. Виртуализация 1049 -р vmO, а отсоединение — с помощью комбинации клавиш <Ctrl+B>. Для проверки статуса гостя используется команда hpvmstatus -Р vmO. 24.8. VMware: операционная система СО СВОИМИ СОБСТВЕННЫМИ ПРАВАМИ Компания VMware — крупнейший игрок на авангардном рынке средств виртуали- зации и первый разработчик методов виртуализации капризной платформы х86. Она разработала технологию для выполнения семнадцати проблематичных инструкций, ко- торые ранее препятствовали распространению виртуализации. Выпуск программного обеспечения VMware Workstation в 1999 году открыл возможности для более эффектив- ных вычислений, реализация которых остается актуальной проблемой и в наши дни. Платформа VMware — это третий коммерческий продукт, заслуживающий внима- ния при выборе технологии виртуализации для сайта. Администраторов систем UNIX и Linux в первую очередь должны заинтересовать платформы ESX и ESXi — автономные гипервизоры для архитектуры Intel х86. Платформа ESXi распространяется свободно, но некоторые полезные функциональные возможности, такие как доступ к консоли, из нее удалены. Платформа ESX предназначена для предприятий, использующих инсталляции, управляемые сценариями, средства для слежения с помощью протокола SNMP и под- держку загрузки с устройства сети для хранения данных (SAN). Кроме продуктов ESX, компания VMware выпустила несколько мощных и современ- ных программ, облегчающих централизованное развертывание и управление виртуаль- ными машинами. Разработчики компании VMware создали самую зрелую технологию динамической миграции, которую нам довелось видеть. К сожалению, их интерфейс управления кли- ентом в данный момент работает только в среде Windows. В общем, продукция компа- нии VMware относится к следующему поколению информационных сред, подробное описание которых выходит за рамки нашей книги. Системы HP-UX и AIX не могут работать как виртуальные машины VMware, по- скольку они используют специализированную архитектуру процессора, которую про- граммное обеспечение VMware не эмулирует. Разумеется, система Linux поддерживается хорошо. Система Solaris также может функционировать под управлением программы VMware, поскольку ее исходный код охватывает платформы SPARC и х86. 24.9. Веб-службы компании Amazon Все крутые парни занимаются облачными вычислениями, и компания Amazon Web Services (AWS) впереди всех. Начиная с 2006 года компания Amazon начала выпускать на рынок инфраструктуру, в основе которой лежит сайт amazon. com, продавая доступ к набору прикладных интерфейсов и веб-служб. Эти службы представляют собой чрезвы- чайно мощную, масштабируемую и широко доступную вычислительную платформу для всех, кому необходимы дешевые и быстродействующие вычислительные мощности или Ресурсы. Основной пакет услуг, предлагаемых компанией AWS администраторам системы UNIX, включает в себя следующие службы.
1050 Часть III. Разное • ЕС2, Elastic Compute Cloud, — платформа для масштабируемых вычислений. “Экземпляр” платформы ЕС2 представляет собой расположенный в Интернете сервер, который запускает операционную систему по вашему выбору и находится под вашим полным контролем. Вы можете добавлять или удалять экземпляры по своему желанию. Платформа ЕС2 основывается на платформе Хеп и поддерживает много разных операционных систем. • EBS, Elastic Block Store, — постоянное дископодобное устройство для экземпля- ров ЕС2. Концепция EBS похожа на хранилище SAN. Это устройство позволяет сохранять экземпляры платформы ЕС2 и сберегать ее состояние между разными вызовами. • S3, Simple Storage Services, — широко доступная долгосрочная инфраструктура хра- нения. В отличие от платформы EBS, она не предназначена для монтирования в ка- честве файловой системы, а вместо этого хранит и извлекает объекты с помощью прикладного программного интерфейса. Эти службы обеспечивают администраторам беспрецедентную гибкость и масштаби- руемость за счет потери части контроля над аппаратным обеспечением и сетевой кон- j фигурацией. j Перенося службы в облако, администраторы и разработчики должны учитывать по- ’ следствия для безопасности. Конфиденциальные данные должны оставаться в физиче-; ским центре обработки данных, особенно если его деятельность регулируется законами, j такими как Sarbanes-Oxley или HIPAA (в США). Требования регуляторов могут исклю- * чать (но могут и не исключать!) использование облачных вычислений, но пока суды за- полняют пробелы в законодательстве, лучше не играть с огнем. Где же тогда служба AWS может оказаться полезной? С точки зрения стоимости, до- ступности и динамической масштабируемости, служба AWS находится вне конкуренции как платформа для веб-хостинга. Стоимость использования экземпляров ЕС2 “до востребования” в настоящее время колеблется от 0,09 до 0,68 долл, за час, в зависимости от вычислительной мощности эк- земпляра. Стоимость использования хранилища S3 составляет 0,15 долл, за гигабайт в месяц. Эти гроши складываются в приличную сумму (работа самого дешевого из доступ- ных экземпляров платформы ЕС2 будет стоить около 379 долл, в год в рамках трехлетне- го контракта), но если учесть стоимость электроэнергии, систем охлаждения и эксплуа- тационные издержки, то итоговая сумма покажется более привлекательной, чем расходы на содержание собственных серверов. С учетом неограниченных ресурсов, облако также является привлекательным в ка- честве распределенной вычислительной платформы. Фактически служба AWS может с пользой использоваться для хостинга электронной почты, DNS или других услуг, кото- рые обычно предоставляются центрами обработки данных. Служба AWS — это ядро набора интерфейсов прикладного программирования SOAP, но компания Amazon предоставляет несколько простых оболочек командной строки, написанных на языке Java, а также графический пользовательский веб-интерфейс и надстройки для браузера Firefox. Служба AWS может запускать в качестве гостевых опе- рационных систем как систему Linux, так и систему Windows. Ниже перечислены этапы создания и запуска постоянного запоминающего устройства. • Инсталляция и конфигурирование среды выполнения на языке Java (проследите, чтобы переменная окружения JAVAHOME ссылалась на правильное место). • Создание учетных записей S3 и ЕС2 на веб-сайте Amazon Web Services.
Глава 24. Виртуализация 1051 • Загрузка и инсталляция инструментов для платформы ЕС2. • Создание экземпляра ЕС2 из образа диска Amazon Machine Image (AMI), пред- ставляющего собой образ диска сконфигурированной операционной системы, возможно, с инсталлированным дополнительным программным обеспечением. Вы можете выбрать эти программы из обширного списка доступного программно- го обеспечения или развернуть свое собственное. • Создание тома EBS и присоединение его к вашему экземпляру. Веб-сайт AWS содержит страницы для регистрации учетных записей и все необхо- димые модули для загрузки. Для того чтобы приступить к использованию службы AWS, загрузите инструменты командной строки и идентификаторы доступа, которые состоят из сертификата и закрытого ключа. Создайте каталог с именем ~/.ес2 и перенесите туда загруженный файл сертифика- та, файл ключа и загруженные инструменты. Все команды ЕС2 будут находиться в ка- талоге ~/. ec2/bin, а библиотечные модули — в каталоге ~/. ec2/lib. Для того чтобы настроить окружение для более легкого использования, добавьте в сценарий регистра- ции следующие инструкции. (Например, для пользователя bash файл будет называться ~/.bash_login или ~/ .bash_profile.) export ЕС2_НОМЕ=~/.ес2 export РАТН=$PATH:$ЕС2_Н0МЕ/bin export EC2_PRIVATE_KEY=$EC2_HOME/pk-<long string value>.pem export EC2_CERT=$EC2_HOME/cert-<long string value>.pem export JAVA_HOME=/path/to/java В заключение, прежде чем сделать выбор образа и загрузить его, создайте пару клю- чей, которые вы собираетесь использовать для обеспечения доступа к этому образу. Новую пару ключей создает команда ес2-add-keypair. Все новые образы, которые вы создадите, будут автоматически конфигурироваться для использования нового открыто- го ключа для аутентификации SSH на корневой учетной записи. ubuntu$ ес2-add-keypair my-keypair KEYPAIR my-keypair bO:65:11:df:05:43:3b:f7:42:93:fb:Oe:7f:63:22:13:ff:88:e5:ae -----BEGIN RSA PRIVATE KEY---- MIIEowIBAAKCAQEAoiJxHIHjuXOqeEoKaeluj8ny55lNuWS5hOQVBxfuhEwG7kttz kiuF8B7U4C4 82827HZO/9cCok6FP81oOAR8GIJvDzvWozZ7hdRhc/i6isWBiMTDQQUItk79fl9atk7P -----END RSA PRIVATE KEY---- Этот ключ понадобится в будущем, поэтому сохраните все, кроме строки, начина- ющейся словом KEYPAIR, в файл, находящийся в каталоге ~/.ес2, и установите па- раметр режима доступа равным 600. Никогда не допускайте совместное использование файла, содержащего закрытый ключ, ведь именно в нем содержатся ключи от облаков! Настало время выбрать образ AMI. Существует огромный список образов AMI, одни из них созданы компанией Amazon, а другие предоставлены (или проданы) членами со- общества. Можно также самостоятельно создать образ AMI для собственного использо- вания и сконфигурировать его с учетом особенностей вашего окружения или инсталли- ровать в него заранее все необходимые приложения. Выбрав образ, обратите внимание на его идентификатор. Команда, приведенная ниже, выводит на экран список образов AMI, созданных компанией Amazon. Добавив в переменную PATH имя каталога с инструментами, можно выполнять команды плат- формы ЕС2 где угодно.
1052 Часть III. Разное ubuntu$ ес2-describe-images -о amazon IMAGE ami-ba4eaad3 /aws-quickstart/phpquickstart.manifest.xml amazon available public i386 machine IMAGE ami-b44bafdd /aws-quickstart/rubyquickstart.manifest.xml amazon available public i386 machine aki-a71cf9ce ari-a51cf9cc IMAGE ami-lc54b075 /aws-quickstart/tomcatquickstart.manifest.xml amazon available public i386 machine aki-a71cf9ce ari-a51cf9cc Имя образа обычно имеет краткое описание, помогающее понять его назначение и конфигурацию, но подробная информация находится на сайте. Для того чтобы препро- цессор РНР быстро запустил образ AMI из приведенного выше списка, выполните сле- дующую команду. ubuntu$ ес2-run-instances ami-ba4eaad3 -k my-keypair ubuntu$ ec2-describe-instances RESERVATION r-56aa053f default INSTANCE i-1343fb7a ami-ba4eaad3 pending my-keypair 0 ml.small 2008-12-22T01:43:27+0000 us-east-lc Результаты работы команды ec2-describe-instances отражают тот факт, что эк- земпляр еще загружается (статус “pending”) и что он использует пару ключей с именем my-keypair. Следует подчеркнуть, что, согласно этим результатам, экземпляр работает в зоне до- ступности us-east-lc. Компания Amazon разделила свои системы на отдельные зоны до- ступности, поэтому пользователь, желающий получить гарантии, что несколько экзем- пляров будут выполняться в физически разделенных центрах обработки данных, может послать запрос в командной строке. Это значение также необходимо для присоединения тома EBS. В заключение отметим, что, согласно данной команде, экземпляр имеет тип ml.small. Этот код сообщает объем ресурсов, доступных для системы. Служба Amazon имеет не- сколько стандартных профилей; ml.small — это стандартный профиль, включающий единственный 32-битовый центральный процессор ЕС2, память объемом 1,7 Гбайт и 160 Гбайт памяти на диске (непостоянном). Разумеется, реальное аппаратное обеспече- ние, на котором работает ваш сервер, вряд ли имеет такие параметры; это просто способ описать ваши ресурсы. Запустив экземпляр платформы, необходимо провести авторизацию всех сете- вых портов, к которым вам нужен доступ. Для этого используется команда ЕС2 ес2- authorize. ubuntu$ ес2-authorize default -р 22 В данном случае порт 22 (для протокола SSH) авторизован для всех узлов в стандарт- ной группе. (Группы — это механизм для управления коллекциями экземпляров. Если не указано иное, новые экземпляры включаются в стандартную группу.) После авто- ризации порта 22 можно, наконец-то, соединиться с вашим новым экземпляром. Для этого сначала найдите имя узла, затем соединитесь с ним с помощью утилиты ssh, как с обычным узлом в Интернете (потому что он таким и является!). ubuntu$ ес2-describe-instances RESERVATION r-56aa053f default INSTANCE i-1343fb7a ami-ba4eaad3 ec2-67-202-24-235.compute- 1.amazonaws.com domU-12-31-39-02-5E-55.compute-1.internal runninmy-keypair 0 ml.small 2008-12-22T01:43:27+0000 us-east-lc
Глава 24. Виртуализация 1053 ubuntu$ ssh -i ~/.ec2/id_rsa-my-keypair root@ec2-67-202-24-235.compute-1. amazonaws.com Эта команда использует пару ключей, сохраненную ранее, для соединения с корне- вой учетной записью нового экземпляра. Для обеспечения безопасности мы рекоменду- ем отключить корневой доступ по протоколу SSH. Осталась только одна проблема — экземпляры не являются персистентными. Иначе говоря, когда экземпляр прекращает работу, любые изменения состояния его дисков или памяти не сохраняются. Тома запоминающих устройств для новых экземпляров предо- ставляет устройство EBS. В данном случае мы создаем том и присоединяем его к рабо- тающему узлу. ubuntu$ ес2-create-volume -s 1 -z us-east-lc VOLUME vol-5de80c34 1 us-east-lc creating 2008-12-22T02:02: 53+0000 ubuntu$ ec2-attach-volume vol-5de80c34 -i i-1343fb7a -d /dev/sdf ATTACHMENT vol-5de80c34 i-1343fb7a /dev/sdf attaching 2008- 12-22T02:04:01+0000 ubuntu$ ec2-describe-volumes VOLUME vol-5de80c34 1 us-east-lc in-use 2008-12-22T02:02: 53+0000 ATTACHMENT vol-5de80c34 i-1343fb7a /dev/sdf attached 2008-12- 22T02:04:01+0000 Ш Более подробно создание файловых систем описано в главе 8. Эти команды создают новый том запоминающего устройства EBS в зоне доступности us-east-lc и присоединяют его как устройство /dev/sdf к ранее созданному экземпляру. Для того чтобы создать файловую систему и приступить к использованию этого тома, зарегистрируйте его в экземпляре платформы и работайте так, будто вы на самом деле создали файловую систему на физическом диске. Помните, что служба AWS взимает почасовую плату за работу каждого экземпляра, поэтому неиспользуемые экземпляры и тома следует удалять. Прежде чем завершить ра- боту ненужного экземпляра, отсоедините от него все тома EBS и аккуратно остановите работу системы, как это обычно делают с физически существующими узлами. ubuntu$ ес2-detach-volume vol-5de80c34 ATTACHMENT vol-5de80c34 i-1343fb7a /dev/sdf detaching 2008- 12-22T02:04:01+0000 ubuntu$ ec2-terminate-instances i-1343fb7a INSTANCE i-1343fb7a running shutting-down ubuntu$ ec2-delete-volume vol-5de80c34 VOLUME vol-5de80c34 В дополнение к интерфейсу командной строки, компания Amazon предлагает уп- равляющий веб-интерфейс, который может инициировать те же самые команды, что и утилитц командной строки, например запуск и останов экземпляров, присоединение томов запоминающих устройств и выделение IP-адресов. Надстройка ElasticFox для веб- браузера Firefox обеспечивает те же функциональные возможности непосредственно в самом браузере. Компания Amazon регулярно предлагает новые функциональные возможности и про- дукты для своих веб-служб. Например, автоматическое масштабирование экземпляров ЕС2 предусматривает автоматический запуск новых серверов, чтобы предотвратить их отключение при высокой нагрузке. Служба CloudWatch проводит мониторинг показате-
1054 Часть III. Разное лей, таких как степень использования центрального процессора и дисковых механизмов ввода-вывода, чтобы быстро реагировать на изменяющиеся условия. Обратите внимание на блог службы AWS по адресу: aws. typepad. com. Он содержит информацию о новых функциональных возможностях и усовершенствованиях. 24.10. Рекомендуемая литература • Веб-сайт virtualization, info — превосходный источник новостей и слухов о виртуализации и облачных вычислениях. • Troy Ryan. VMware Cookbook: A Real-World Guide to Effective VMware Use. Sebastopol, CA: O’Reilly Media, 2009. • Crawford, Luke. The Book of Xen: A Practical Guide for the System Administrator. San Francisco, CA: No Starch Press, 2009. • Hess, Kenneth. Practical Virtualization Solutions: Virtualization from the Trenches. Upper Saddle River, NJ: Prentice Hall PTR, 2009. 24.11. Упражнения 24.1. Сравните разные подходы к визуализации. К какой категории относится платфор- ма KVM? Чем технология облачных вычислений отличается от виртуализации? 24.2. Современные процессоры Intel и AMD имеют специальные инструкции, улуч- шающие поддержку виртуализации. Что это за инструкции и какие специальные функции они выполняют? Выберите конкретную операционную систему и модель процессора и опишите, по крайней мере, два способа, позволяющих определить, поддерживаются ли инструкции виртуализации. 24.3. Какие новые функциональные возможности стала поддерживать служба Amazon Web Services с момента написания этой главы? Улучшают ли они существующую инфраструктуру или представляют собой совершенно новые службы? 24.4. Создайте учетную запись на службе Amazon Xfeb Services и пару открытых клю- чей. Установите окружение Java и создайте экземпляр платформы ЕС2. Имеете ли вы прямой доступ к консоли? Что из этого следует? Предположим, что созданный вами экземпляр платформы предназначен для хранения конфиденциальных дан- ных, какие шаги следует предпринять, чтобы убедить клиента в том, что данные в облаке хорошо защищены? 24.5. Крупное предприятие планирует развернуть новую систему для управления взаимоотношениями с клиентами (CRM), состоящую из зарезервированных прикладного и интерфейсного серверов, промежуточных серверов и сервера для управления базой данных. Какие из этих компонентов системы CRM следует вир- туализировать? Объясните свое решение.
Глава Система X Window System Основой для большинства графических пользовательских сред для систем UNIX и Linux является система X Window (ее еще называют XI1 или просто X). X — это прямая наследница оконной системы, называемой W (это действительно так), которая разра- батывалась под эгидой проекта Project Athena в Массачусетсском технологическом ин- ституте (MIT) в начале 80-х годов прошлого века. Система X Window System версии 10, вышедшая в 1985 году, была первой, которой удалось достичь широкого распростране- ния, а вскоре после нее вышла версия 11 (XII). Благодаря относительно либеральным условиям лицензионного соглашения, систему X стали переносить на другие платфор- мы, появились различные варианты ее реализации. Как и в случае с протоколом ТСР/ IP, элегантная архитектура и гибкость системы X позволили ей стать самым популярным в мире графическим интерфейсом пользователя (GUI), отличающимся от интерфейса системы Windows. В 1998 году группа X Consortium, входящая в состав MIT, выработала общее направ- ление развития протокола X. В течение последующих десяти лет эта группа, а также ее последователи постоянно работали над обновлениями протокола. Самой последней и большой версией является XI 1R7.5 — теперь к номерам версий добавляются новые чис- ла, а не увеличиваются существующие. Версия XFree86 являлась фактической реализацией Х-сервера для многих платформ до тех пор, пока в 2004 году не изменились условия лицензионного соглашения, вслед- ствие чего многие дистрибьюторы были вынуждены переключиться на ветвь XFree86, которая не подпадала под условия нового лицензионного соглашения. Эта ветвь под- держивается некоммерческой организацией X.Org Foundation и сегодня является доми- нирующей реализацией. Кроме того, версию X.Org Server можно переносить на плат- форму Windows для использования в среде совместимости Cygwin Linux. (Для Windows
1056 Часть III. Разное существует несколько коммерческих версий Х-сервера; более подробно об этом можно прочитать в разделе 30.2.) В этой главе будет рассмотрена версия X.Org, которая используется во всех наших примерах систем, за исключением HP-UX. Реализации версий X.Org и XFree86 имеют расхождения в плане архитектуры, однако многие административные функции одина- ковы. Чтобы использовать команды для версии XFree86, можно менять в них записи “xorg” на “xf86”. Система Solaris (начиная с версии 10) включала как X.Org Server, так и Xsun SOLdriS (еще одну реализацию системы X)1. Сервер Xsun применяется в системах SPARC, работающих под управлением Solaris 10, а системы х86 обычно ис- пользуют реализацию сервера X.Oig. Но в настоящее время X.Org уже поддер- живает архитектуру SPARC, и проектом OpenSolaris заявлено, что сервер X.Oig будет единственным вариантом поддержки платформы X в будущем. Поэтому здесь мы не будем рассматривать реализацию Xsun. • По умолчанию система AIX не включает среду X Window System. Чтобы инстал- лировать ее, выполните команду smitty easy-install, укажите в качестве исходной библиотеки 1рр, а затем выберите либо вариант CDE (для традици- онной и “святой” для IBM платформы Motif), либо вариант KDE (для более со- временных платформ)2. Вы получите версию среды X.Oig, высокая степень на- страиваемости которой позволяет придать ей вид старых-добрых систем X эры Motif. Но под “ретро-оболочкой” вы обнаружите поддержку среды XI 1R7.5. В системе X Window System можно выделить несколько ключевых компонентов. Она содержит диспетчер дисплеев (display manager), главной задачей которого является аутен- тификация пользователей, их регистрация и запуск исходной среды .для сценариев за- пуска системы. Диспетчер дисплеев запускает Х-сервер (X server), который определяет ; абстрактный интерфейс для растровых изображений и устройств ввода (например, для клавиатуры и мыши). Сценарии запуска запускают диспетчер окон (window manager), j который позволяет пользователям перемещать окна, сворачивать, восстанавливать и из- < менять их размеры, а также управлять отдельными виртуальными рабочими столами. ** Наконец, на самом нижнем уровне приложения связываются с библиотекой графических интерфейсных элементов (widget library), которая реализует механизмы высокоуровнево- го пользовательского интерфейса, такие как кнопки и меню. На рис. 25.1 можно просле- дить взаимосвязь между диспетчером дисплеев, Х-сервером и приложениями клиентов. Х-сервер понимает только базовый набор рисуемых примитивов в сетевом API; он не определяет программный интерфейс для высокоуровневых объектов, таких как кнопки, текстовые окна, меню и ползунки. Это обусловлено двумя причинами. Во-первых, это позволяет Х-серверу работать на совершенно другом компьютере из приложения кли- ента. Во-вторых, Х-сервер позволит серверу поддерживать разнообразные диспетчеры окон и наборы библиотек графических интерфейсных элементов. У разработчиков приложений имеются свои библиотеки графических интерфейс- ных элементов и стандарты пользовательских интерфейсов. К сожалению, часто выбор зависит от “религиозной” приверженности, а не от того, какие задачи нужно решать разработчикам в действительности. Несмотря на удобства, которые открываются бла- 1 Реализация Xsun включала поддержку технологии Display PostScript, которой когда-то про- рочили стать языком отображения будущего. 2 Совместная инсталляция обеих сред возможна, но не рекомендуется. Больше о настольных ' средах см. в разделе 25.5.
Глава 25. Система X Window System 1057 годаря свободе выбора, агностицизм пользовательского интерфейса системы X и сдача лидерских позиций в области дизайна в течение долгих лет сдерживали разработку каче- ственных пользовательских интерфейсов. К счастью, степень завершенности основных Х-сред заметно возросла. Настольные среды KDE и GNOME существенно оживляют современные веб-браузеры, дружественные к пользователю программы управления фай- лами, и новые мультимедийные возможности. = Библиотека графических интерфейсных элементов Диспетчер дисплеев Требует ввести регистрационное имя и пароль Запускает сценарии запуска системы Обрабатывает протокол управления XDM Х-клиент Х-клиент >ц^сервер Управляет дисплеем Управляет устройствами ввода Среда дисплея Диспетчер окон 4З Рис. 25.1. Модель “клиент/сервер” в системе X В этой главе мы поговорим о том, как запускаются программы на дистанционном дис- плее и как выполняется процесс аутентификации. Кроме того, мы рассмотрим вопрос конфигурирования сервера X.Oig, а также поиска и устранения ошибок в конфигура- ции. В конце главы мы вкратце поговорим о некоторых доступных диспетчерах окон и средах рабочего стола. 25.1. Диспетчер дисплеев Диспетчер дисплеев представляет себя с помощью экрана регистрации, и обычно именно его пользователь видит первым, садясь за компьютер. Он не является обязатель- ным; многие пользователи отключают эту утилиту и запускают систему X из текстовой консоли или из сценария . login, выполняя команду startx (она является оболочкой для программы xinit, которая запускает Х-сервер). Исходный диспетчер дисплеев называется xdm (для диспетчера дисплеев системы X), однако современные варианты, такие как gdm (диспетчер дисплеев для GNOME) и kdm (диспетчер дисплеев для KDE), предлагают дополнительный набор функций и имеют более привлекательный вид. Диспетчер дисплеев может позволить выполнять дистан- ционную регистрацию на других Х-серверах посредством протокола XDMCP. Он может также поддерживать аутентификацию дисплея (см. раздел “Аутентификация клиентов” далее в этой главе). Конфигурационные файлы, находящиеся в подкаталогах xdm, gdm или kdm катало- га /etc/Xll, определяют, как будет работать утилита xdm. К примеру, файл Xservers можно отредактировать таким образом, чтобы изменить номер дисплея, используемо- го для данного сервера, если множество серверов будет работать на других виртуальных терминалах. Или же можно изменить компоновку сервера с помощью опции -layout, если вы определили компоновку, подходящую для множества систем. Ш Подробные сведения о РАМ можно найти в разделе 22.5.
1058 Часть III. Разное Как правило, диспетчер дисплеев предлагает ввести имя пользователя и пароль. Пароль пользователя проверяется в соответствии с конфигурацией РАМ (Pluggable Authentication Modules — подключаемые модули аутентификации), заданной в файле .etc/pam.d/xdm (или gdm/kdm, если вы используете диспетчеры дисплеев GNOME или KDE). На экране регистрации может быть предложено использование нескольких альтернативных сред рабочего стола, включающих важную безотказную опцию, о кото- рой поговорим немного позже. В заключение диспетчер дисплеев должен выполнить сценарий интерпретатора ко- манд XSession, который настраивает среду рабочего стола пользователя. Сценарий XSes- sion, который, как правило, находится в каталоге /etc/Xll/{xdm,gdm,kdm}, является общесистемным сценарием запуска. Он задает стандартные настройки приложений, ин- сталлирует стандартные клавиатурные привязки и выбирает языковые настройки. Затем сценарий XSession выполняет личный пользовательский сценарий запуска, который обыч- но называется ~/.xsession. Он запускает диспетчер дисплеев, панель задач, вспомога- тельные аплеты, а также может запускать и другие программы. GNOME и KDE имеют собственные сценарии запуска, которые конфигурируют рабочий стол пользователя в со- ответствии со средствами конфигурации GNOME и KDE. При этой схеме ошибок возни- кает меньше, чем при редактировании пользователями собственных сценариев запуска. Когда работа сценария -/.xsession завершена, пользователь выводится из системы и диспетчер дисплеев снова предлагает ввести имя пользователя и пароль. Таким обра- зом, сценарий ~/.xsession должен запускать все программы в фоновом режиме (до- бавляя символ & в конце каждой команды), кроме самой последней, которой обычно является диспетчер окон. (Если все команды в сценарии -/.xsession будут работать в фоновом режиме, работа сценария будет тут же прекращена и пользователь будет вы- веден из системы сразу же после входа в нее.) Если же диспетчер окон будет работать в качестве приоритетного процесса, пользователь сможет выйти из системы только после того, как будет завершена работа диспетчера окон. Безотказная опция позволяет пользователям входить в систему с целью устранения сбоев в проблемных сценариях запуска. Как правило, эту опцию можно выбирать на экране регистрации диспетчера дисплеев. В этом случае открывается только простое окно терминала; после закрытия окна пользователь выходит из системы. Благодаря это- му пользователь может самостоятельно устранить возникшие неполадки, не обращаясь за помощью к администратору. Как правило, самой распространенной проблемой при запуске системы является как раз то, что процессу не присваивается высокий уровень приоритета и он остается работать в фоновом режиме. Однако это не единственная проблема, которая может возникнуть. Если причину возникновения проблемы установить сложно, можно просмотреть файл */ .xsession-errors, в котором содержатся результаты выполнения команд в сценарии *7 .xsession. Постарайтесь найти в этом файле ошибки или какое-либо необычное пове- дение системы. Если и это не поможет, переместите сценарий ~/.xsession в какое-нибудь изолированное место и попробуйте войти в систему без него. Затем постепенно восстанав- ливайте одну-две строки до тех пор, пока не будет найдена “проблемная” строка. 25.2. Процесс запуска Х-приложения Процедура, необходимая для запуска Х-приложения, на первый взгляд может пока- заться слишком сложной. Тем не менее вскоре вы обнаружите, что клиент-серверная модель дисплеев предлагает высокую степень гибкости. Так как информация об обнов-
Глава 25. Система X Window System 1059 лении дисплея передается по сети, приложение (клиент) может работать на совершенно другом компьютере, а не на том, где оно отображает свой графический интерфейс поль- зователя (на сервере). Х-сервер может соединяться со многими другими приложениями, каждое из которых будет работать на отдельном компьютере. Чтобы эта схема работала, клиенты должны знать, к какому дисплею нужно подклю- чаться и какой экран нужно занимать на этом дисплее. После соединения с дисплеем клиенты должны пройти аутентификацию на Х-сервере, гарантируя, что человек, сидя- щий перед дисплеем, имеет право устанавливать соединение. Ш Подробные сведения о протоколе SSH даны в разделе 22.10. Тем не менее даже после прохождения аутентификации система X не обязательно бу- дет полностью защищена. Еще один безопасный способ управления соединениями за- ключается в использовании протокола SSH (см. раздел “Перенаправление соединений с помощью протокола SSH” далее в этой главе). Мы настоятельно рекомендуем использо- вать протокол SSH для соединений системы X с Интернетом. В любом случае это будет нелишним для локальной передачи данных. Переменная окружения DISPLAY Х-приложения обращаются к переменной окружения DISPLAY для того, чтобы узнать, где они будут отображать свои данные. Эта переменная содержит имя или IP- адрес сервера, номер дисплея (он указывает на определенный экземпляр Х-сервера, с которым нужно соединиться) и необязательный номер экрана (для дисплеев с нисколь- кими мониторами). Когда приложения работают на том же компьютере, на котором отображаются их интерфейсы, для простоты записи большинство этих параметров мож- но опустить. Следующий пример показывает и формат информации, представленной на дисплее, и синтаксис интерпретатора команд bash, используемого для задания переменной окру- жения. client$ ЪТ32ЪкЧ—имя_сервера. домен, сохл: 1G.2; export DISPLAY Эта запись расшифровывается так: Х-приложение находится по адресу имя_серве- ра. домен, сот, дисплей 10, экран 2. Приложения устанавливают TCP-соединение с сер- вером на порту с номером 6000 плюс номер дисплея (в данном примере это порт 6010), на котором Х-сервер, обрабатывающий данный дисплей, должен вести прослушивание. Следует иметь в виду, что каждый процесс имеет собственные переменные окруже- ния. Если переменную окружения DISPLAY задать для интерпретатора команд (оболоч- ки), то ее значение будет передано только тем программам, которые будут запускаться этим интерпретатором. Если выполнить приведенные выше команды в одной програм- ме xterm, а затем попытаться запустить любимое Х-приложение в другой программе, то приложение не будет иметь доступа к созданной вами переменной DISPLAY. Обратить внимание нужно и на другой момент. Дело в том, что хотя Х-приложения посылают свои графические выходные данные на обозначенный Х-сервер, они по- прежнему имеют локальные каналы stdout и stderr. На терминальное окно, из кото- рого было запущено Х-приложение, могут направляться некоторые выходные данные об ошибках. Если и клиент, и сервер находятся в вашей организации, вы можете убрать из пере- менной DISPLAY полное доменное имя сервера, в зависимости от того, каким образом был сконфигурирован распознаватель вашего сервера имен. Поскольку большинство си-
1060 Часть IIL Разное стем работает на одном Х-сервере, дисплей обычно имеет нулевой номер. Номер экра- на можно опустить, в результате чего будет подразумеваться номер 0. Итак, чаще всего удобнее будет присваивать переменной DISPLAY значение имя_сервера: 0. Ш О конфигурировании распознавателя DNS рассказывалось в разделе 17.3. Если приложение клиента будет работать на том же компьютере, что и Х-сервер, пе- ременную DISPLAY можно еще больше упростить, опустив имя компьютера. Это не про- сто косметическое изменение: если указать пустое имя, то для связи с Х-сервером би- блиотеки клиента будут использовать сокет домена UNIX, а не сокет сети. Кроме того, что этот тип соединения является более быстрым и эффективным, он позволяет обойти любые ограничения, вводимые брандмауэром в локальной системе, которые блокируют внешние соединения с системой X. Наиболее простым из возможных значений пере- менной окружения DISPLAY является нулевое значение (: 0). Аутентификация клиентов Несмотря на то что Х-среда обычно считается относительно незащищенной, любая мера предосторожности поможет защититься от несанкционированного доступа. Ранее, до того как вопрос безопасности системы стал крайне важным, Х-серверы с помощью команды xhost принимали соединения от любого клиента, работающего на компьюте- ре, который помечался как безопасный. Однако в связи с тем, что любой пользователь, работающий на этом компьютере, мог соединиться с вашим дисплеем и причинить вред (случайно или преднамеренно), от метода предоставления доступа посредством коман- ды xhost отказались навсегда. Больше о нем и мы не будем упоминать. Наиболее распространенным альтернативным вариантом защиты является аутенти- фикация с использованием “магических” cookie-наборов (magic cookie). Если вы знако- мы с работой в Интернете, то cookie-наборы вам тоже должны быть знакомы; в данном контексте cookie-наборы используются для аутентификации Х-соединений. Суть в том, что диспетчер дисплеев X в самом начале процедуры регистрации в системе генерирует большое случайное число, которое и называется cookie-набором. Cookie-набор сервера записывается в файл ~/ .Xauthority, который находится в домашнем каталоге пользо- вателя. Соединение могут выполнять любые клиенты, которым известен cookie-набор. Пользователи могут выполнять команду xauth для того, чтобы просматривать суще- ствующие cookie-наборы и добавлять в этот файл собственные cookie-наборы. Как работает эта схема, проще всего продемонстрировать на примере. Предположим, что вы задали вашу переменную DISPLAY в системе клиента для отображения Х-приложений на компьютере, за которым работаете. Однако когда вы запускаете про- грамму, на экран выводится ошибка, которая выглядит примерно так. client$ xprogram -display server:0 Xlib: connection to "server:0.0" refused by server xprogram: unable to open display ’server:0' Это сообщение говорит о том, что у клиента нет подходящего cookie-набора, поэто- му дистанционный сервер отклонил данное соединение. Чтобы получить подходящий cookie-набор, нужно зарегистрироваться на сервере (это уже может быть сделано, если вы пытаетесь отобразить программу прямо на нем) и вывести список cookie-наборов сервера, выполнив команду xauth list. server$ xauth list server:0 MIT-MAGIC-COOKIE-1 f9d888df6077819ef4d788fab778dc9f
Глава 25. Система X Window System 1061 server/unix:О MIT-MAGIC-COOKIE-1 f9d888df6077819ef4d788fab778dc9f localhost:0 MIT-MAGIC-COOKIE-1 cb6cbf9e5c24128749feddd47f0e0779 Каждый сетевой интерфейс на сервере имеет свою запись. В данном примере мы имеем cookie-набор для Ethernet, для сокета домена UNIX, который используется для локальных соединений, и для сетевого интерфейса обратной связи localhost. Самый простой способ “обзавестись” cookie-набором на клиенте (при условии, что не используется сетевой протокол SSH, который сам заботится о cookie-наборах) заклю- чается в применении знакомой всем операции вырезания и вставки. Многие эмуляторы терминалов (например, xterm3) позволяют выделять текст с помощью мыши и вставлять его в другом окне, обычно посредством щелчка средней кнопкой мыши. В этом случае удобно то, что команда xauth add принимает в качестве ввода тот же формат, который отображает команда xauth list. Добавить cookie-набор к клиенту можно следующим образом. client$ xauth add server:О MIT-MAGIC-COOKIE-1 9d888df6077819ef4d788fab778dc9f Чтобы убедиться в том, что cookie-набор был добавлен правильно, нужно выполнить команду xauth list на клиенте. Если переменная окружения DISPLAY задана и добав- лен действительный “магический” cookie-набор, приложения смогут отображать свои данные на сервере. Если у вас возникнут проблемы с работой cookie-наборов, можно на время вернуть- ся к процедуре аутентификации с использованием команды xhost — просто для того, чтобы посмотреть, не возникают ли какие-то проблемы в ней (например, ограничения, выдвигаемые брандмауэрами или локальной сетью, которые не предоставляют клиенту доступ к серверу). Чтобы отключить аутентификацию xhost после выполненного вами теста, нужно выполнить команду xhost - (т.е. xhost со знаком дефиса в качестве един- ственного аргумента). Перенаправление соединений с помощью протокола SSH “Магические” cookie-наборы усиливают защиту, однако использовать одни лишь cookie-наборы недостаточно. Любой пользователь, который может получить cookie- набор вашего дисплея, сможет подключиться к нему и запустить программы, которые будут отслеживать ваши действия. Даже без вашего cookie-набора Х-протокол будет пе- редавать данные по сети без шифрования, в результате чего буквально каждый пользо- ватель сможет их перехватывать. Ш Подробные сведения о протоколе SSH даны в разделе 22.10. Усилить защиту можно с помощью протокола SSH (secure shell — защищенный ин- терпретатор команд). Этот протокол обеспечивает аутентификацию и шифрование на терминале. Тем не менее SSH может также передавать произвольные сетевые данные, включая данные протокола X, по защищенному каналу. Механизм перенаправления, ис- пользуемый в системе X, подобен обобщенному перенаправлению портов с помощью SSH, однако поскольку SSH знает об особенностях системы X, вы получаете дополни- тельные преимущества, включая псевдодисплей на дистанционном компьютере и “до- говорную” передачу “магических” cookie-наборов. Протокол SSH обычно используется для передачи данных между компьютером, на котором работает Х-сервер, и компьютером, на котором функционируют Х-программы. 3 Или команда aixterm в системе AIX. Мудро, да?
1062 Часть III. Разное Эта схема может привести читателя в замешательство, поскольку SSH-клиент работает на том же компьютере, что и Х-сервер, и соединяется с SSH-сервером, который работает на том же компьютере, где работают приложения Х-клиента. Ситуация усугубляется еще и тем, что виртуальный дисплей, который формирует SSH для вашего Х-сервера, явля- ется локальным по отношению к дистанционной системе. На рис. 25.2 показано, как осуществляется передача данных посредством SSH-соединения в системе X. Компьютер Х-клиента Компьютер Х-сервера Рис. 25.2. Использование протокола SSH в системе X Вашу переменную окружения DISPLAY и информацию об аутентификации можно задать автоматически посредством команды ssh. Номер дисплея начинается с : 10.0 и увеличивается на единицу для каждого SSH-соединения, при котором передаются дан- ные в системе X. В качестве примера можно предложить следующую последовательность. x-server$ ssh -v -X х-cl lent, xnydomain.com SSH-2.0-OpenSSH_5.1 debugl: Reading configuration data /home/boggs/.ssh/config debugl: Reading configuration data /etc/ssh/ssh_config debugl: Applying options for * debugl: Connecting to x-client.mydomain.com [192.168.15.9] port 22. debugl: Connection established. Enter passphrase for key ' /home/boggs/. ssh/id_rsa' : debugl: read PEM private key done: type RSA debugl: Authentication succeeded (publickey). debugl: Entering interactive session. debugl: Requesting Xll‘forwarding with authentication spoofing. debugl: Requesting authentication agent forwarding. x-client$ В последних двух строках видно, что клиент получает запрос на перенаправление данных для XI1-приложений. Перенаправление в системе X может быть разрешено как на SSH-сервере, так и на SSH-клиенте; кроме того, у клиента должен быть подходящий cookie-набор для сервера. Если у вас не получается организовать перенаправление, по- пробуйте использовать флаги -X и -v, как было показано выше (для OpenSSH), чтобы явным образом разрешить перенаправление в системе X и запросить подробные выход- ные данные4. Также можно просмотреть глобальные конфигурационные файлы SSH в каталоге /etc/ssh и убедиться в том, что перенаправление в системе XI1 не было отме- 4 Обратите внимание на то, что команда ssh также имеет флаг -Y, который “выражает дове- рие” соединениям со всеми клиентами. Эта возможность поможет решить некоторые проблемы перенаправления данных, но использовать ее все же нужно с предельной осторожностью.
Глава 25. Система X Window System 1065 нено администратором. Сразу после входа в систему вы можете проверить ваш дисплей и магические cookie-наборы. x-client$ echo $DISPLAY localhost:12.0 x-client$ xauth list x-client/unix:12 MIT-MAGIC-COOKIE-1 a54b67121eb94c8a807f3ab0a67a51f2 Обратите внимание на то, что переменная DISPLAY указывает на виртуальный ди- сплей на SSH-сервере. Остальным SSH-соединениям (производимым как вами, так и другими пользователями) присваиваются разные виртуальные номера дисплеев. Если переменная DISPLAY и cookie-набор будут заданы правильно, вы сможете запустить приложение клиента. х-alient$ xeyes debugl: client_input_channel_open: ctype xll rchan 4 win 65536 max 16384 debugl: client_request_xll: request from 127.0.0.1 35411 debugl: channel 1: new [xll] debugl: confirm xll debugl: channel 1: FORCE input drain Если с помощью команды ssh -v разрешить отображение отладочной информа- ции, вы увидите, что ssh получила запрос на Х-соединение и покорно перенаправила его Х-серверу. Сам процесс перенаправления может быть немного медленным, однако приложение в конечном счете должно появиться на вашем экране. 25.3. Конфигурирование Х-сервера Сервер X.Oig, или Xorg, сложно поддается конфигурированию на конкретном аппа- ратном обеспечении. Но после определенных работ по модернизации сервера Xoig мно- гие системы смогли успешно его запускать вообще без файла конфигурации. При этом сохранилась возможность вручную адаптировать сервер Xorg к широкому разнообразию оборудования для графики, устройств ввода, режимов видео, разрешений и глубины цвета, которую поддерживают устройства. Очень хорошо, если ваша система нормально работает без файла конфигурации сер- вера Xoig! Это возможно, например, при использовании модуля KMS, который описан ниже в этой главе. В противном случае у вас есть два варианта. Первый вариант состоит в ручном конфигурировании файла xorg. conf (см. описание ниже). Причем в некото- рых ситуациях этот вариант, по правде говоря, может оказаться вашим единственным выходом из положения. Второй вариант заключается в использовании утилиты xrandr для конфигурирования вашего сервера (подробности ниже). Конфигурационный файл сервера Xorg обычно находится в каталоге /etc/Xll /xorg. conf, однако Х-сервер будет просматривать целые кипы каталогов, пытаясь найти его. Полный список есть на man-странице, однако нужно иметь в виду, что некоторые пути, по которым Xoig ведет поиск, содержат имя компьютера и глобальную переменную, что облегчает хранение конфигурационных файлов для множества систем в одном месте. • Система AIX не требует файла конфигурации xorg. conf и пытается авто- матически распознавать все типы AIX-оборудования. Вы можете передать Х-серверу свои пожелания по конфигурации как аргументы. Некоторые программы могут помочь вам в конфигурировании системы X (напри- мер, xorgconfig), однако вам желательно самим разобраться со структурой конфигура-
1064 Часть III. Разное ционного файла на тот случай, если вы захотите самостоятельно просматривать или ре- дактировать эти файлы. Первичную информацию по этому вопросу можно найти прямо на Х-сервере, выполнив команду Xorg -probeonly и просмотрев выходные данные для видеоплаты и прочие тестовые значения. Если выполнить команду Xorg -configure, Х-сервер создаст исходный конфигурационный файл, который будет основан на тесто- вых значениях. Для начала этой информации вам вполне хватит. Файл xorg. conf состоит из нескольких разделов, каждый из которых начинается с ключевого слова Section и заканчивается ключевым словом Endsection. Наиболее распространенные типы разделов перечислены в табл. 25.1. Таблица 25.1. Разделы файла xorg.conf Раздел Описание' v ' " ServerFlags Module Перечисляет главные конфигурационные параметры Х-сервера Определяет динамически загружаемые расширения для ускоренной графики, визуа- лизаторов шрифтов и т.п. Device Monitor Конфигурирует информацию о видеоплате, драйвере и оборудовании Описывает физические параметры монитора, включая синхронизацию и разрешения дисплеев Screen Связывает монитор с видеоплатой (Device) и определяет разрешения и глубину цве- та, доступные в данной конфигурации InputDevice ServerLayout Определяет устройства ввода, такие как клавиатуры и мыши Связывает устройства ввода с экранами и позиционирует экраны относительно друг друга Как правило, создавать конфигурационный файл проще всего “снизу вверх”, начи- ная с определения разделов для устройств ввода и вывода и комбинируя их в различ- ных компоновках. При таком иерархическом подходе простой конфигурационный файл можно использовать для многих Х-серверов, каждый с разным оборудованием. Этот подход будет удобен и для одной системы, в которой установлено несколько видеоплат и используется несколько мониторов. На рис. 25.3 показано, как некоторые из этих разделов располагаются в иерархии кон- фигурации X.Org. Физический дисплей Monitor и видеоплата Device формируют экраЗй Screen. Набор экранов Screen плюс устройства ввода InputDevices формируют ком- поновку ServerLayout. В конфигурационном файле может быть определено множеств# компоновок сервера, однако только одна из них будет активной в данном экземпляре процесса Xorg. Рис. 25.3. Взаимоотношение между разделами конфигурации xorg. conf
Глава 25. Система X Window System 1065 Некоторые разделы, составляющие файл xorg. conf, являются относительно фикси- рованными. Стандартные разделы часто могут браться прямо из существующего конфи- гурационного файла или из его образца. Другие (например, Device, Monitor, Screen, inputDevice и ServerLayout) зависят от того, как настроено оборудование компьюте- ра. В следующих подразделах мы рассмотрим наиболее интересные из этих разделов. раздел Device В этом разделе описывается определенная видеоплата. Вы должны указать строку, ко- торая идентифицирует плату и драйвер, подходящий для данного устройства. Драйвер загружается только в том случае, если на это устройство имеется ссылка в соответствую- щем разделе Screen. Типичная раздел Device может выглядеть примерно так. Section "Device" Identifier "VideocardO" Driver "radeon" опция значение EndSection На странице справочного руководства этого драйвера (в данном случае это radeon) перечисляются и описываются оборудование, которым он управляет, и опции, которые он поддерживает. Если во время работы возникают какие-то странные явления, можно отключить аппаратное ускорение (если эта функция поддерживается), сократив доступ к видеопамяти, или модифицировать параметры интерфейса. Однако перед тем как что- либо изменять, желательно проконсультироваться в Сети или у специалиста. Раздел Monitor В разделе Monitor описываются дисплеи, подключенные к вашему компьютеру. В ней могут быть определены детализированные значения синхронизации. Информация о синхронизации необходима для оборудования старого образца; тем не менее она мо- жет быть полезной для многих современных мониторов. Спецификации дисплеев обыч- но можно получить на веб-сайтах производителей, однако самым лучшим источником, естественно, является руководство, прилагаемое к монитору. В любом случае вам нужно будет знать как минимум частоты горизонтальной и вертикальной развертки для вашей модели. Типичный раздел Monitor выглядит примерно так. Section "Monitor" Identifier Option HorizSync VertRefresh EndSection "ViewSonic" "DPMS" 30-65 50-120 Как и во всех разделах, строка Identifier присваивает имя, с помощью которого вы будете ссылаться на данный монитор. Здесь мы включили функцию DPMS (Display Power Management Signaling — сигналы управления энергопотреблением дисплеев), бла- годаря которой Х-сервер будет выключать монитор, когда мы будем делать перерыв на чашечку кофе или просто отлучаться на некоторое время. Строки HorizSync и VertRefresh должны содержать значения, подходящие для вашего CRT-монитора (с электронно-лучевой трубкой). Они могут быть определены
1066 Часть III. Разное в виде диапазона частот (как это сделано в приведенном выше примере) или в виде на- бора дискретных значений, разделяемых запятыми. Драйвер теоретически может про- тестировать поддерживаемые режимы, однако если параметры будут определены, он не будет использовать неподдерживаемые частоты. Раздел Screen В разделе Screen устройство (видеоплата) связывается с монитором при опреде- ленной глубине цвета, а также задаются параметры разрешения дисплея. Ниже показан пример, в котором используются упомянутые видеоплата и монитор. Section "Screen" Identifier "ScreenO" Device "VideocardO" Monitor "ViewSonic" DefaultDepth 24 Subsection "Display" Depth 8 Modes "640x400" EndSubsection Subsection "Display" Depth 16 Modes "640x400" "640x480" "800x600" "1024x768" EndSubsection Subsection "Display" Depth 24 Modes "1280x1024" "1024x768" "800x600" "640x400" "640x480" EndSubsection EndSection Как можно было предположить, в строке Identifier указывается имя экрана и перечисляются идентификаторы ранее определенной видеоплаты и монитора. Это пер- вый представленный нами раздел, в котором имеются подразделы. Для каждой глуби- ны цвета определяется одн подраздел, а стандартное значение глубины задается в поле DefaultDepth. Данный экземпляр Х-сервера может работать только при одной глубине цвета. В са- мом начале сервер определяет, какие разрешения поддерживаются для данной глу- бины цвета. Возможные разрешения зависят, как правило, от видеоплаты. В разделе “Специальные комбинации клавиш в системе X” этой главы описано, в каком порядке производится выбор определенных здесь разрешений. Любая современная видеоплата должна уметь работать с вашим монитором с пол- ным его разрешением при 24- или 32-битовом цвете. Если вам понадобится запустить старые программы, для которых сервер должен работать с 8-битовым цветом, запусти- те другой Х-сервер в отдельной виртуальной консоли. Чтобы отменить действие опции DefaultDepth, в командной строке Xorg используйте флаг -depth 8. Раздел inputDevice В разделе InputDevice описывается устройство ввода (например, клавиатура или мышь). Каждому устройству соответствует собственный раздел InputDevice и, как и в других разделах, имя в поле Identifier. Если вы используете один конфигурацион- ный файл для нескольких компьютеров с разным оборудованием, можете определить
Глава 25. Система X Window System 1067 все устройства ввода; использоваться будут только те из них, которые указаны в разделе ServerLayout. Ниже показано типичное определение клавиатуры. Section "InputDevice Identifier Driver Option Option Option EndSection "Generic Keyboard" "Keyboard" "AutoRepeat" "500 30 "XkbModel" "pcl04" "XkbLayout" "us" "Generic Mouse" "mouse" "CorePointer" "Device" "/dev/input/mice "Protocol" "IMPS/2" "Emulate3Buttons" "off" "ZAxisMapping" "4 5" Среди прочего, в определении клавиатуры можно задать такие опции, которые опре- делят настройку клавиш <Ctri> и <Caps Lock>. В данном примере опция AutoRepeat определяет, как долго нужно удерживать клавишу нажатой, чтобы это привело к повтору нажатия символа, и как быстро будет повторяться ввод символа. Конфигурация мыши определяется в другом разделе InputDevice. Section "InputDevice" Identifier Driver Option Option Option Option Option EndSection Опция CorePointer обозначает эту мышь как основное указывающее устройство в системе. Файл устройства (Device), связанный с мышью, определен в поле Option. Файлы мультиплексоров мыши перечислены в табл. 25.2. Таблица 25.2. Файлы мультиплексоров мыши ос ; / Linux Solaris HP-UX AIX /dev/input/mice /dev/mouse /dev/devi ceFi leSys tem/mouseMux /dev/mouseO Протокол связи зависит от конкретного производителя мыши, ее функциональных характеристик и интерфейса. Если ему присвоить значение auto, сервер попытает- ся определить протокол самостоятельно. Если колесико мыши не работает, попробуй- те воспользоваться протоколом IMPS/2. Если мышь содержит много кнопок (больше трех), используйте протокол ExplorerPS/2. Некоторые пользователи систем Solaris сооб- щают об успешном использовании протокола VUID. Опция Emulate3Button позволяет двухкнопочным мышам имитировать работу трехкнопочных, определяя щелчок двумя кнопками как щелчок средней кнопкой мыши. Опция ZAxisMapping иногда нужна для поддержки прокрутки колесика или работы джойстика; эта поддержка осуществляется путем сопоставления кнопок. Большинство современных моделей мыши имеют как минимум три кнопки, колесико прокрутки, встроенный МРЗ-плеер, щетку для массажа ступней и холодильник для пива5. 5 Xoig поддерживает не все опции. Некоторые продаются отдельно.
1068 Часть ill. Разное Раздел ServerLayout Этот раздел является узлом верхнего уровня в иерархии конфигурации. Каждая ап- паратная конфигурация, на которой будет работать сервер, должна иметь собственный экземпляр раздела ServerLayout. Компоновка, используемая определенным Х-серве- ром, обычно определяется в командной строке сервера. Этот раздел связывает вместе все остальные разделы, представляя Х-дисплей. Она на- чинается с необходимого поля Identifier, в котором указывается данная конкретная компоновка. После этого набор экранов связывается с компоновкой6. Если к отдель- ным видеоплатам подключено несколько мониторов, то каждый экран будет опреде- ляться вместе с необязательными направлениями, чтобы показать их физическое ме- сторасположение. В данном примере один экран (Screen 1) находится слева, а другой (Screen 2) — справа. Ниже показан пример всего раздела ServerLayout. Section "ServerLayout" Identifier Screen Screen InputDevice InputDevice Option Option Option Option EndSection "Simple Layout" "Screen 1" LeftOf "Screen 2" "Screen 2" RightOf "Screen 1" "Generic Mouse" "CorePointer" "Generic Keyboard" "CoreKeyboard" "BlankTime" "10" # Погасить экран через 10 минут "StandbyTime" "20" # Отключить экран через 20 минут (DPMS) "SuspendTime" "60" # Полное засыпание через 60 минут (DPMS) "OffTime" "120"# Отключить DPMS-монитор через 2 часа Некоторые видеоплаты могут управлять одновременно несколькими мониторами. В данном случае в разделе ServerLayout определен только один экран Screen. За спи- ском экранов следует набор устройств ввода, которые необходимо связать с этой ком- поновкой. Опции CorePointer и CoreKeyboard перемещены в раздел InputDevice, чтобы показать, что эти устройства должны быть активными в данной конфигурации. Эти опции могут быть заданы прямо в соответствующих разделах InputDevice, однако проще всего задавать их в разделе ServerLayout. В последних нескольких строках конфигурируется несколько опций, специфиче- ских для компоновки. В приведенном выше примере все они связаны со спецификаци- ей DPMS (Display Power Management System — управление режимом энергосбережения монитора), благодаря которой мониторы, рассчитанные на работу в режиме Energy Star (режим пониженного энергопотребления мониторов), “знают”, когда нужно отключать питание. Мониторы должны также иметь собственные DMPS-опции, разрешенные в со- ответствующих разделах Monitor. Утилита xrandr: конфигуратор Х-сервера Расширение Х-сервера RandR (X Resize and Rotate Extension) позволяет клиентам ди- намически изменять разрешение, частоту развертки, ориентацию (использовать “пор- третный” режим) и отображение экранов их Х-серверов без перезапуска Х-сервера. Утилита командной строки xrandr представляет собой интерфейс с расширением RandR. 6 Помните, что экраны идентифицируют комбинацию “монитор/видеоплата” при определен- ной глубине цвета.
Глава 25. Система X Window System 1069 Безусловно, все мы (исключительно из любви к искусству программирования) с удо- вольствием потратили бы несколько дней, тщательно “вылизывая” каждую строку фай- ла xorg.conf, на поддержку новейшей системы SUPERINATOR 3000 с ее четырьмя роскошными дисплеями. Но во многих случаях это (т.е. работу по конфигурированию) может сделать за нас утилита xrandr (тем самым освободив для нас время для встречи с друзьями). Выполненная без аргументов, утилита xrandr показывает доступные дис- плеи и их возможные варианты разрешения. $ xrandr VGA-0 connected 1024x768+0+0 (normal left inverted right x a...) 0mm x 0mm 1024x768 61.0 60.0 59.9 59.9 800x600 60.3 61.0 59.9 56.2 59.8 640x480 59.9 61.0 59.4 59.5 DVI-0 connected 1024x768+0+0 (normal left inverted right x a...) 0mm x 0mm 1024x768 60.0 60.0 800x600 60.3 59.9 640x480 59.9 59.4 Вы можете задать разрешение для каждого дисплея, а также указать расположение конкретного монитора относительно других7. Рассмотрим пример. $ xrandr —auto —output VGA-0 —mode 800x600 —right-of DVI-0 Аргумент —auto включает все мониторы. Аргументы —output и —mode устанавлива- ют для монитора с видеографической матрицей (VGA) разрешение 800x600, а аргумент —right-of определяет, что VGA-монитор должен физически располагаться справа аг DVI-монитора. (Последняя опция необходима для упорядочения составляющих рабо- чего стола.) Для просмотра множества доступных опций выполните команду xrandr —help. Если вы хотите выполнять утилиту xrandr автоматически при запуске Х-сервера, поместите ее в файл ~/.xprofile. Установка режима ядра Для того чтобы сделать представление системы более гладким и устранить шум мерцания, ответственность за установку начального режима графического отображения в настоящее время перекладывается на ядро Linux посредством модуля KMS (kernel mode setting). Как и в версии ядра 2.6.30-10.12, KMS по умолчанию инициализирует видеокарту в начале процесса загрузки ядра. Вы можете разрешить или запретить KMS с помощью настроек в конфигурационных файлах видеодрайвера каталога /etc/modprobe. d. Например, если у вас есть видеокар- та ATI Radeon, вы сможете отключить KMS, добавив следующую строку в файл /etc/ modprobe.d/radeon.conf. options radeon modeset=0 Модуль KMS пока не поддерживает все типы видеокарт. Если вам посчастливи- лось быть обладателем поддерживаемой карты, то лучше всего переименовать файл xorg. conf так, чтобы Х-сервер пытался стартовать без него и обращался к KMS- конфигурации. 7 До начала использования утилиты xrandr выполните команду Xorg -configure, чтобы перевести файл xorg. conf в известное исходное состояние.
1070 Часть III. Разное 25.4. Устранение неполадок и отладка Х-сервера Конфигурация Х-сервера прошла долгий путь за последние десять лет, однако она по-прежнему остается сложной, и вам будет непросто добиться того, чтобы все работало именно так, как вы того хотите. Вам придется экспериментировать с частотами монито- ров, опциями драйверов, оригинальными драйверами или расширениями для трехмер- ной визуализации. Как правило, сбои в работе мониторов возникают именно тогда, ког- да вам крайне необходимо просмотреть информацию об отладке на экране. К счастью, сервер X.Org может дать вам любую необходимую информацию (и даже сверх того), ко- торая поможет вам выявить причину возникновения проблемы. Специальные комбинации клавиш в системе X Так как Х-сервер принимает на себя управление вашей клавиатурой, дисплеем и мы- шью, вы можете себе представить, что он может оставить вам небольшое количество ре- сурсов и выключит питание системы, если что-то не будет работать. Однако прежде чем дело дойдет до этого, нужно попытаться выполнить некоторые действия. Если нажать и удерживать клавиши <Ctrl> и <Alt>, а затем нажать функциональную клавишу (<F1>—<F6>), Х-сервер переключит вас на один из текстовых виртуальных терминалов. В нем вы сможете войти в систему и выполнить отладку. Для того чтобы вернуться к Х-серверу, работающему на терминале 7, нужно нажать <Alt+F7>8. Если вы работаете в сети, можете также попробовать войти в систему на другом компьютере, чтобы уничтожить Х-сервер, прежде чем нажимать кнопку сброса. Для поддержки виртуальной консоли в системе Solaris разрешите использова- SOLdriS ние системы управления службами (Service Management Facility — SMF) svc:/ sys tern/vtdaemon:default и службы console-login:vt[2-6]. Если монитор не синхронизируется с видеосигналом, поступающим с видеоплаты, попытайтесь изменить разрешение экрана. Доступные разрешения указаны в строке Modes раздела Screen конфигурационного файла. Строка Modes, являющаяся актив- ной, зависит от глубины цвета; более подробно об этом см. раздел 25.3. Стандартные настройки Х-сервера выбираются с учетом первого разрешения, указанного в активной строке Modes, однако вы можете переходить от одного разрешения к другому, удерживая клавиши <Alt> и <Ctri> и нажимая клавиши со знаком “плюс” или “минус” на цифро- вой клавиатуре. При нажатии комбинации клавиш <Ог1+АЙ+пробел> происходит немедленное уни- чтожение Х-сервера. Если вы запустили сервер из консоли, окажетесь в ней после пре- кращения работы сервера. Если сервер был запущен диспетчером дисплеев, то диспетчер запустит новый сервер и предложит снова ввести имя пользователя и пароль. Вам нужно будет уничтожить диспетчер дисплеев (xdm, gdm и т.п.) из текстовой консоли, чтобы он не порождал новые Х-серверы. Когда с Х-сервером творится что-то неладное После того как вновь получите возможность управлять компьютером, вы сможете найти причину возникновения проблемы. Проще всего начать с анализа выходных дан- 8 При нажатии комбинации <А1г+функциональная клавиша> следует удерживать нажатой кла- вишу <Ctrl>, чтобы Х-сервер мог переключить виртуальные терминалы; для текстовой консоли нажимать клавишу <Ctrl> не нужно.
Глава 25. Система X Window System 1071 ных Х-сервера. Эти данные периодически появляются на первом виртуальном терми- нале (<Ctrl+Alt+Fl >), на который поступают все выходные данные программы запуска. Как правило, выходные данные Х-сервера направляются в регистрационный файл, на- пример в файл /var/log/Xorg. О. log (/var/Xll/Xserver/logs/Xf86.0. log в си- стеме HP-UX). Как будет показано ниже, каждой строке предшествует символ, определяющий ее категорию. Вы можете использовать эти символы для обозначения ошибок (ЕЕ) и пред- упреждений (WW), а также для того, чтобы определить, как сервер будет находить каждую порцию информации: посредством стандартных настроек (==), в конфигурационном файле (**), путем автоматического обнаружения (—) или в командной строке Х-сервера (++). Давайте проанализируем следующий фрагмент кода из системы Ubuntu. X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-23-server i686 Ubuntu Current Operating System: Linux nutrient 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 Build Date: 09 April 2009 02:10:02AM xorg-server 2:1.6.0-0ubuntul4 (builddOrothera.buildd) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (—) probed, (**) from config file, (==) default setting, (++) from command line, (’!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun May 10 22:11:47 2009 (==) Using config file: "/etc/Xll/xorg.conf" (==) ServerLayout "MainLayout" (**) |—>Screen "Screen 0" (0) (**) | |—>Monitor "Monitor 0" (**) । ।—>Device "Console" (**) |—>Input Device "MouseO" (**) |—>Input Device "KeyboardO" В первых строках указывается версия Х-сервера и номер протокола XII, которые он реализует. В последующих строках сообщается о том, что сервер использует стандарт- ные значения для местонахождения регистрационного и конфигурационного файлов, а также компоновки активного сервера. Дисплей и устройства ввода в конфигурационном файле отображаются схематически. Одной из часто встречаемых проблем, которые можно увидеть в журнале, являет- ся сложность с определенными разрешениями экрана, о чем обычно свидетельству- ет сообщение об ошибке “Unable to validate any modes; failing back to the default mode” (Невозможно проверить какой-либо из режимов; производится возврат к стандартному режиму). Если не определить список частот для вашего монитора, Х-сервер попытается использовать их с помощью EDID-данных (Extended Display Identification Data — Pac“ ширенные данные идентификации дисплея). Если ваш монитор не поддерживает EDID или если ваш монитор выключен, когда запускается система X, вам нужно указать диа- пазон частот для системы X в разделе Monitor конфигурационного файла. Ошибка округления в результатах, полученных после тестирования EDID, может привести к тому, что некоторые разрешения будут недоступными, даже если они должны
1072 Часть III. Разное поддерживаться вашей видеоплатой и монитором. Об этом свидетельствуют такие запи- си в журнале, как “No valid modes for 1280x1024; removing” (Нет подходящих режимов для разрешения 1280x1024; удаление). Решить эту проблему можно, приказав Х-серверу игнорировать информацию EDID и использовать частоты, определенные вами в следу- ющих строках раздела Device. Option "IgnoreEDID" "true" Option "UseEdidFreqs" "false" В качестве другого примера предположим, что вы забыли правильно определить на- стройки мыши в разделе InputDevice. В этом случае выходные данные должны содер- жать сообщение об ошибке следующего рода. (==) Using config file: "/etc/Xll/xorg.conf” Data incomplete in file /etc/Xll/xorg.conf Undefined InputDevice "MouseO" referenced by ServerLayout "MainLayout". (EE) Problem parsing the config file (EE) Error parsing the config file Fatal server error: no screens found После того как система X заработает и вы войдете в нее, сможете запустить команду xdpyinfо, чтобы получить дополнительную информацию о конфигурации Х-сервера9. После выполнения команды xdpyinf о вы получите имя дисплея и версию Х-сервера. Кроме того, будет сообщено также о доступной глубине цвета, загруженных расширени- ях и установленных экранах, их размерах и конфигурации. Выходные данные команды xdpyinf о можно проверять синтаксически с помощью сценария (такого, как ~/ .xsession), чтобы узнать размер активного экрана и правиль- но задать параметры рабочего стола. В процессе отладки команду xdpyinf о полезно вы- полнять для того, чтобы определить, что Х-сервер работает и следит за запросами в сети, что у него правильно сконфигурирован экран и разрешение и что он работает с требуе- мой глубиной цвета. Если все это подтверждается, можно запускать Х-приложения. 25.5. Краткое замечание о настольных средах Гибкость модели “клиент/сервер” в системе X Window с годами привела к появлению наборов библиотек графических интерфейсных элементов, диспетчеров окон, обозрева- телей файлов, утилит панели инструментов и полезных программ. Первые полнофунк- циональные среды, OpenLook и Motif, были элегантными, но слишком узкоспециали- зированными, а условия лицензирования, распространяемые на библиотеки разработки и диспетчер окон, сделали их недоступными для широкой публики. По мере того как приложения становились более совершенными и требовали более серьезной поддержки от базовой оконной системы, стало ясно, что без перехода к более передовой платфоме не обойтись. Как результат, в современных средах рабочего стола для Linux мы имеем двух крупных игроков: GNOME и KDE. Несмотря на то что неко- торые пользователи имеют свое понимание того, какая из них является самым “истин- ным путем”, обе среды являются полноценными диспетчерами рабочего стола. В сущ- 9 Входить в систему X от имени суперпользователя не рекомендуется, поскольку эта операция может создать множество стандартных файлов запуска в домашнем каталоге суперпользователя, которым обычно является каталог / или /root. Кроме того, это небезопасно. Наоборот, входить в систему нужно от имени обычного пользователя и использовать утилиту sudo. В системах Ubuntu эта схема принята по умолчанию.
Глава 25. Система X Window System 1075 ности, работая в одном “королевстве”, вы можете использовать приложения из другого “королевства”. Вы должны лишь быть готовы к тому, что приложение будет выглядеть и вести себя по-другому. Проект freedesktop. org посвящен созданию среды, которая позволит приложени- ям быть совместимыми с любой настольной средой. KDE Среда KDE (расшифровывается как “К Desktop Environment — настольная среда К) написана на языке C++ и основана на библиотеке инструментов Qt. Ее предпочитают те пользователи, которым нравятся привлекательные элементы и эффекты интерфейса (прозрачные окна, тени и анимированные указатели мыши). Выглядит она привлека- тельно, однако может замедлить работу малопроизводительных персональных компью- теров. Работать в этой среде удобно тем пользователям, которые большую часть времени тратят на щелчки на рабочем столе, а не на запуск приложений. Среду KDE часто предпочитают пользователи, перешедшие из Windows или Мас, и причина тому — все та же привлекательность графики. Она придется по вкусу также тем пользователям, кому нравится самостоятельно настраивать все параметры среды. Для остальных пользователей среда KDE вряд ли подойдет — они могут воспользоваться средой GNOME. Приложения, написанные для среды KDE, практически всегда содержат букву “К” в своем названии (например, Konqueror — обозреватель Веб или файлов, Konsole — ими- татор терминала, Kword — текстовый процессор). Стандартный диспетчер окон, KWin, поддерживает стандарт Window Manager Specification проекта freedesktop. org, кон- фигурируемые оболочки (skin) для изменения внешнего вида, а также многое другое. Комплект приложений KOffice позволяет обрабатывать тексты, электронные таблицы и проводить презентации. KDE предлагает обширный набор инструментов для разработ- ки, включая интегрированную среду разработки (IDE). GNOME Среда GNOME написана на языке С и основана на библиотеке графических интер- фейсных элементов GTK+. Название GNOME первоначально являлось акронимом GNU Network Object Model Environment (Среда сетевых объектных моделей GNU), однако в наши дни это не имеет никакого значения — сейчас существует просто имя GNOME. С последним добавлением поддержки Compiz (compiz.org) — композитного ме- неджера окон для X Window System — среда GNOME приобрела множество симпа- тичных функций, которых в ней ранее недоставало. Среда GNOME менее броская, чем KDE, предлагает меньше возможностей для конфигурирования и, вообще, является ме- нее согласованной. Однако она гораздо понятнее, быстрее и проще, чем KDE. Среда GNOME используется во многих дистрибутивах в качестве стандартной настольной сре- ды. Подобно KDE, GNOME имеет богатый набор приложений. Ее приложения обычно идентифицируются буквой “G” в названии приложения. Исключением является стан- дартный диспетчер окон, называемый Metacity, который предлагает базовые функции работы с окнами и оболочки, позволяющие изменять внешний вид. В соответствии с моделью GNOME, Metacity обязана быть “шустрой и проворной”. Если вам понадобятся какие-то дополнительные особенности вроде интеллекту- ального размещения окон, нужна будет поддержка внешних приложений, таких как brightside или devilspie. (В области “шика-блеска”, KDE все еще занимает непло- хие позиции.)
1074 Часть III. Разное К офисным приложениям относятся AbiWord (для обработки текстов), Gnumeric (для работы с электронными таблицами), а также один из наиболее впечатляющих проек- тов — GIMP, позволяющий производить обработку изображений. Еще есть диспетчер файлов Nautilus. Как и KDE, для разработчиков приложений GNOME предлагает об- ширную инфраструктуру. Подводя итоги, можно с уверенностью сказать, что GNOME предлагает функциональную архитектуру для разработки приложений в простой в ис- пользовании среде рабочего стола. Что лучше: GNOME или KDE? Попробуйте-ка задать такой вопрос на одном из открытых форумов, как тут же нач- нется “большой базар”. Вопрос о предпочтениях практически всегда затрагивает личные чувства и становится причиной настоящих “крестовых походов”, поэтому вы можете не согласиться с тем, что написано в следующих двух абзацах. Конечно же, лучше всего попробовать в деле обе среды и решить самостоятельно, какая из них подходит вам больше всего. Следует иметь в виду, что ваши приятели, ваши пользователи и ваш администратор могут иметь совершенно разные предпочтения от- носительно среды рабочего стола, и в этом нет ничего плохого. Не забывайте, что ваш выбор, сделанный в пользу той или иной среды, не означает, что вы сможете работать только с некоторыми приложениями. Не важно, какую среду вы выберете, — вы сможете выбирать приложения из всего имеющегося программного обеспечения, доступного для каждого из этих (и других) проектов с открытым исходным кодом. 25.6. Рекомендуемая литература • На домашней странице X.Oig (www. х. org) содержится информация о свежих вы- пусках, а также ссылки на проект Wiki X.Oig, списки рассылки и ссылки для за- грузки. • На man-страницах Xserver и Xorg (или просто X в системе AIX) рассмотрены об- щие опции Х-сервера и специфические опции командной строки Xorg. Они со- держат также обзор принципов работы Х-сервера. • На man-странице xorg.conf приводится конфигурационный файл с подробным описанием его разделов и перечислены драйверы видеоплат в разделе REFERENCES (Справка). На этой странице уточните, какой драйвер управляет вашей видеопла- той, а затем ознакомьтесь с man-страницей этого драйвера, чтобы узнать обо всех его опциях. 25.7. Упражнения 25.1. Используя SSH, запустите программу X по сети. Используйте команду ssh -v, чтобы удостовериться, что перенаправление настроено должным образом. Какое значение будет иметь переменная окружения DISPLAY после того, как вы войдете в систему? Выведите на экран список cookie-наборов, выполнив команду xauth, и убедитесь в том, что для данного дисплея включена проверка достоверности с ис- пользованием cookie-наборов.
Глава 25. Система X Window System 1075 25.2. Напишите команду интерпретатора команд или сценарий для проверки синтакси- са выходных данных xdpyinf о и напечатайте текущее разрешение экрана в фор- мате XxY (например, 1024x768). 25.3. Проверьте регистрационный файл Xorg (/var/logXorg.о. log) и на его основе постарайтесь ответить на следующие вопросы: а) какая видеоплата используется и какой драйвер управляет ее работой? б) какой объем памяти установлен на видеоплате? в) использовались ли данные EDID для тестирования настроек монитора? Как это можно узнать? г) какие режимы (разрешения) поддерживаются? д) включена ли функция DPMS? е) о каких физических размерах экрана известно серверу? ж) какой файл устройства используется для мыши? 25.4. Какой флаг отключает нелокальные TCP-соединения с сервером? Объясните, чем полезна эта опция?
Глава 26 Печать В операционной системе UNIX процесс печати довольно запутан. Давайте разберемся. В операционной системе Linux печатать довольно удобно. Точно так же удобно печа- тать в системе Mac OS X. Эти операционные системы используют современную, слож- ную, сетевую и безопасную систему печати Common UNIX Printing System (CUPS). Эта система предоставляет современный графический пользовательский интерфейс, осно- ванный на использовании браузера, а также команды оболочки, позволяющие печатать и управлять системой печати с помощью сценариев. Подобно тому как новейшие транспортные системы для передачи почтовых сообще- ний сохраняют команду sendmail, позволяющую выполнять старые сценарии (старым администраторам!) в память о старых славных днях, так и система CUPS допускает вы- полнение команд 1р и 1рг, обеспечивая обратную совместимость с традиционными си- стемами печати в UNIX. В результате все довольны. Судя по названию, можно было бы подумать, что систему CUPS можно найти во всех версиях UNIX. Увы, это не так. Ни одна из рассмотренных нами платформ UNIX — Solaris, HP-UX и AIX — ее не использует. И что еще хуже, быстрый поиск в системе Google показывает, что попытки инсталлировать систему CUPS на этих платформах обычно терпят неудачу. Вместо нее упомянутые платформы предлагают варианты устаревших систем печа- ти System V и BSD. Что было хорошо для компьютера PDP-11, то должно быть хоро- шо и для вас! К сожалению, в сфере печати документов доминируют системы Microsoft Windows и Mac OS, поэтому разработчики систем UNIX не испытывают давления со стороны пользователей и не торопятся улучшать поддержку печати. В то время как раз-
Глава 26. Печать 1077 работники платформы UNIX внедряют систему CUPS (а вы осваиваете системы Linux и Max OS), пользователи вынуждены изучать старые системы печати. Начнем главу с общего обсуждения систем печати и терминологии, принятой в этой сфере. Затем перейдем к описанию разных систем печати на платформах UNIX и Linux, а также их архитектур. После этого обсудим специфику конфигурирования и управления принтерами и закончим кратким руководством по отладке систем печати, обзором допол- нительного программного обеспечения для печати, а также советами общего характера. Впрочем, прежде чем начать, стоит напомнить: системные администраторы часто считают печать менее приоритетной задачей, чем пользователи. Администраторы чита- ют документы в сети, а пользователи часто хотят иметь бумажную копию и хотят, чтобы система печати работала 100% времени. 26.1. Архитектура системы печати Процесс печати состоит из нескольких компонентов. Очередь печати (spooler), собирающая задания и устанавливающая их очередность. Аббревиатура “spool” образована от Simultaneous Peripheral Operation Online. Теперь эта аббревиатура стала термином. Пользовательские утилиты (интерфейс командной строки и/или графический поль- зовательский интерфейс), которые отправляют задания в очередь печати и запросы си- стеме об этих заданиях (приостанавливая или завершая их работу), удаляют задания или изменяют их очередность, а также конфигурируют другие части системы. Внутренние интерфейсы (back end), которые обмениваются информацией с устрой- ствами печати. (Обычно они не видны и скрыты под панелями.) Сетевые протоколы, обеспечивающие связь с очередями печати и передачу заданий. Для управления печатью полезно понимать, как распределены роли между частями системы. К сожалению, существует слишком много вариантов такого распределения. Основные системы печати Каждая операционная система, описанная в книге, имеет подсистему печати, при- надлежащую одному из трех семейств: System V, BSD или CUPS. Мы расскажем, как возникли эти имена. Это не только интересно с исторической точки зрения, но и полез- но. Программное обеспечение для печати не всегда связано с линейкой операционных систем. Например, операционная система AIX, которая изначально была разработана на основе подсистемы System V.0 с расширениями V.2, использует подсистему печати BSD. Существуют самостоятельные системы печати, которые можно инсталлировать от- дельно (как, например, печально известная подсистема LPRng), но функции печати в этом случае часто оказываются перемешаны с другими частями операционной системы и заставить их работать бывает трудно. Инсталлирование собственных систем печати напоминает инсталлирование своей оболочки: система UNIX позволяет это сделать, и у вас могут быть веские причины для этого, но вы оказываетесь предоставлены сами себе. В этой книге мы рассматриваем только программное обеспечение, которое входит в дистрибутивные пакеты по умолчанию. Для того чтобы увидеть, какое программное обеспечение для печати встроено в вашу операционную систему, достаточно посмотреть на очередь печати. Система CUPS имеет демон cupsd, BSD — Ipd, a System V — Ipshed, так что команда which cupsd Ipd Ipshed сообщит вам, что есть в вашем распоряжении.
1078 Часть III. Разное Очереди печати Каждая система имеет очередь печати: часть программного обеспечения, которая по- лучает задания на печать, хранит их, присваивает им приоритеты и последовательно по- сылает их на один или несколько принтеров. Иногда очередь называют демоном или сервером печати. В некоторых принтерах (обычно сложных моделей) существуют собственные вну- тренние очереди печати. Если вы попросили вашего демона печати очистить очередь заданий на печать и проблема не исчезла, проверьте, нет ли заданий во внутренней оче- реди принтера. Для того чтобы очистить внутреннюю очередь заданий, принтер необхо- димо выключить и запустить снова. Очереди печати Ipd (BSD) и Ipshed (SysV) — это автономные демоны, специально предназначенные для печати. Приложения, работающие в системе, либо обмениваются информацией с этими серверами, либо читают и записывают ее в файлы очереди печати или файлы конфигурации, размещенные в “хорошо известных” местах, например в ка- талоге /var/spool или /etc. 26.2. Система печати CUPS Д Серверы CUPS — это веб-серверы, а клиенты CUPS — это веб-клиенты. Кли- ентами CUPS могут быть как команды (наподобие 1рг и Ipq), так и прило- жения с графическим пользовательским интерфейсом (наподобие kprinter). По сути, все они являются веб-приложениями, даже если просто передают информацию демону CUPS в локальной системе. Серверы CUPS могут также функционировать как клиенты других серверов CUPS Сервер CUPS предоставляет полнофункциональный веб-интерфейс на порту 631. Для администраторов веб-браузер обычно является самым удобным способом для управления системой: достаточно просто перейти на адрес http://prw/Aatf:631. Если вам необходимо секретное соединение с демоном (и ваша система позволяет это), исполь- зуйте порт https://prw/Aatf:433. Для управления системой сценарии могут использовать дискретные команды, и пользователи могут обращаться к ним с помощью интерфейсов GNOME или KDE. Эти способы эквивалентны. ; В основе всех взаимодействий между серверами CUPS и клиентами лежит протокол HTTP, точнее, протокол печати в Интернете IPP (Internet Printing Protocol), его улучшен- ная версия. Клиенты посылают задания с помощью операции POST протокола HTTP/ IPP и запрашивают их статус с помощью команды GET из того же протокола. Файлы конфигурации CUPS также выглядят подозрительно похожими на файлы конфигурации веб-сервера Apache. Интерфейсы для системы печати Система CUPS является достаточно современной, так что большинство ее функций можно выполнить из графического пользовательского интерфейса, а администрирование часто осуществляется с помощью веб-браузера. Системный администратор (и, возмож- но, некоторые из консервативных пользователей) может также использовать команды оболочки. В системе CUPS есть аналоги многих команд оболочки из классических си- стем печати BSD и System V. К сожалению, система CUPS не эмулирует все, без исклю- чения, свойства этих систем. Иногда она эмулирует старые интерфейсы слишком хорошо;
Глава 26. Печать 1079 например, вместо того чтобы выдать пользователю краткую информативную справ- ку, команды Ipr —help и Ip -help просто распечатывают сообщения об ошибках. И все же многие старые сценарии, использующие эти команды, просто отлично ра- ботают в системе CUPS. Думайте об отсутствующих функциях как о возможностях: если вы хотите сохранить мир во всем мире и обеспечить оптимальность по Парето, пишите свою программу (а если вы используете старую систему, используйте существующий код). Вот как можно было бы распечатать файлы foo.pdf и /tmp/testprint.pdf. $ Ipr foo.pdf /tap/testprint.ps Команда Ipr передает копии файлов серверу CUPS cupsd, который сохраняет их в очереди на печать (print queue). Когда принтер готов, CUPS начинает обрабатывать каж- дый файл по очереди. Во время печати система CUPS проверяет как документ, так и PPD-файл принтера (PostScript Printer Description — описание принтеров в PostScript), чтобы узнать, что не- обходимо сделать для того, чтобы документ был распечатан должным образом. (Как бу- дет объяснено позже, PPD-файлы используются даже и для принтеров, не понимаюпщх язык PostScript.) Для того чтобы подготовить задание к печати на конкретном принтере, CUPS про- пускает его через конвейер, состоящий из фильтров. Эти фильтры могут выполнять са- мые разные функции. Например, фильтр может изменять формат задания так, чтобы на каждой физической странице печаталось по два экземпляра уменьшенных в размене страниц, или преобразовывать задание из формата Postscript в PCL. Фильтр также моШТ выполнять какую-нибудь специфическую для принтера операцию обработки, такую инициализация принтера. Фильтр даже может преобразовывать изображения в растро- вый формат, превращая абстрактные инструкции, такие как “проведите линию поперек страницы”, в двоичное изображение. Такая функция полезна для принтеров, которые не могут самостоятельно выполнять растеризацию или не понимают язык, на котором сформулировано задание. Последним этапом в конвейере печати является внутренний интерфейс, который от- правляет задание с узла на принтер через подходящий протокол, такой как Ethernet (tea также отправляет информацию о состоянии обратно на сервер CUPS. Просмотреть до- ступные внутренние интерфейсы можно при помощи такой команды. $ locate backend | grep -i cups Передав задание на печать, демон CUPS возвращается снова к обработке своих оче- редей и запросов от клиентов. Принтер приступает к работе, пытаясь распечатать пере- данное ему задание. Очередь на печать Централизованное управление демона cupsd позволяет легко понять, как работают пользовательские команды. Например, команда Ipq запрашивает с сервера CUPS ин- формацию о состоянии задания и форматирует ее для отображения. Клиенты CUPS мо- гут просить сервер откладывать задания, отменять их или изменять их приоритет. Они также могут переносить задания из одной очереди в другую. Почти все изменения требуют указания номера задания, который сообщается в отче- те, возвращаемом командой Ipq. Например, чтобы удалить какое-нибудь задание, нуж- но просто выполнить такую команду: 1рпп идентификатор_задания. Команда Ipstat -t предоставляет хороший сводный отчет об общем состоянии сер- вера печати.
1080 Часть III. Разное Множество принтеров Система CUPS создает для каждого принтера отдельную очередь. Клиенты команд- ной строки принимают аргумент (обычно -р принтер или -р принтер) для указания очереди принтера. Также можно самостоятельно задать принтер, который должен ис- пользоваться по умолчанию, просто установив переменную окружения PRINTER $ export РН1КТЕН=имя_принтера или указав системе CUPS использовать определенный параметр по умолчанию для дан- ной учетной записи. $ Ipoptions -&имя_принтера При выполнении от имени пользователя root, команда Ipoptions устанавли- вает системные параметры по умолчанию, которые хранятся в каталоге /etc/cups /Ipoptions. Эта команда позволяет каждому пользователю устанавливать свои пара- метры, которые хранятся в каталоге ^/Ipoptions. Команда Ipoptions -1 отображает список текущих опций. Экземпляры принтеров Если имеется только один принтер и его нужно использовать по-разному — напри- мер, как для быстрой печати черновых вариантов, так и для качественной печати про- изводственных документов, — система CUPS позволяет создавать для выполнения этих задач разные “экземпляры принтера”. Например, если уже есть принтер с именем Phaser_6120, команда $ Ipoptions -р Phaser_6120/2up -о number-up=2 -о job-sheets=standard создаст экземпляр с именем Phaser_6120/2up, печатающий по две странице на листе и добавляющий титульные страницы. После создания нового экземпляра команда $ Ipr -Р Phaser__6120/2up biglisting.ps затем распечатает файл PostScript biglisting.ps как задание с двумя страницами на каждом листе и соответствующими титульными страницами. Сетевая печать С точки зрения системы CUPS, сеть со множеством машин не очень отличается от изолированной машины. На каждом компьютере выполняется демон CUPS (cupsd), и все эти демоны взаимодействуют между собой. Для того чтобы сконфигурировать демон CUPS так, чтобы он принимал задания на печать с удаленных систем, можно отредактировать файл /etc/cups/cupsd.conf (подробнее об этом будет рассказываться чуть позже в этой главе, в разделе “Настройка сервера сетевой печати”). Настроенные таким образом серверы CUPS по умолчанию каждые 30 секунд рассылают информацию об обслуживаемых ими принтерах. Благодаря этому имеющиеся в локальной сети компьютеры автоматически узнают о доступных им принтерах. Такую же конфигурацию можно создать, просто установив флажки в графи- ческом пользовательском интерфейсе CUPS в вашем браузере. Если кто-нибудь подключил новый принтер или включил в сеть ноутбук либо ин- сталлировал новую рабочую станцию, то с помощью команды cupsd можно най- ти и увидеть новые компоненты сети, щелкнув на кнопке Find New Printers вкладки Administration графического пользовательского интерфейса CUPS.
Глава 26. Печать 1081 Сделать принтеры доступными для множества сетей или подсетей немного сложнее, потому что рассылаемые пакеты не пересекают границ подсетей. Наиболее популярным решением является выделить в каждой подсети подчиненный сервер, который будет за- прашивать информацию с серверов в других подсетях и затем рассылать ее машинам в своей локальной подсети. Предположим, необходимо, чтобы серверы allie (192.168.1.5) и j j (192.168.2.14), находящиеся в разных подсетях, были доступны пользователям в третьей подсети, 192.168.3. Чтобы решить эту проблему, нужно просто выделить подчиненный сервер (например, copeland, 192.168.3.10) и добавить в его файл cupsd. conf такие строки. BrowsePoll allie BrowsePoll jj BrowseRelay 127.0.0.1 192.168.3.255 Первые две строки указывают демону cupsd подчиненного сервера запрашивать у находящихся на серверах allienjj демонов cupsd информацию об обслуживаемых ими принтерах. Третья строка указывает серверу copeland рассылать получаемую ин- формацию по своей собственной подсети. Вам необходима более тонкая настройка? Требуется множество очередей для одного принтера и чтобы у каждой были свои параметры по умолчанию? Нужен один сервер, балансирующий нагрузку путем распределения заданий между несколькими принте- рами? Необходимо иметь множество серверов, способных работать с равнозначными экземплярами одного и того же принтера? Необходимы клиенты Ipd или Windows? Вариантов слишком много, чтобы их все можно было рассмотреть здесь, но CUPS име- ет решение для всех этих ситуаций, и узнать о них подробнее можно в документации CUPS (см. раздел 26.13). Фильтры Вместо того чтобы использовать специализированную утилиту печати для каждого принтера, система CUPS использует ряд фильтров, которые преобразовывают формат распечатываемого файла в формат, понятный для имеющегося принтера. Схема фильтров в системе CUPS является довольно изящной. Когда система CUPS получает подлежащий распечатке файл, она определяет его тип MIME. Затем она про- веряет файл PPD и выясняет, какие типы MIME может обрабатывать принтер. После этого с помощью файлов . convs она решает, какая цепочка фильтров может преобразо- вать один тип в другой и сколько это будет стоить. В заключение она выбирает цепочку и пропускает документ через фильтры. Последний фильтр в цепочке передает серверу пригодный для печати формат, а он, в свою очередь, передает данные на принтер либо через аппаратное устройство, либо через протокол, поддерживаемый принтером. Для распознавания типа поступающих данных система CUPS использует правила, указанные в файле /etc/cups/mime, types. Например, правило application/pdf pdf string (0,%PDF) означает следующее: “Если файл имеет расширение pdf или начинается со строки %PDF, тогда его типом MIME является application/pdf”. О том, как преобразовать один тип данных в другой, система CUPS узнает, просма- тривая правила в файле /etc/cups/mime.convs. Например, правило application/pdf application/postscript 33 pdftops означает следующее: “Для того чтобы преобразовать файл application/pdf в файл application/postscript, нужно выполнить фильтр pdftops”. Число 33 — это стой-
1082 Часть III. Разное мость такой операции преобразования. Если выясняется, что одно и то же преобразова- ние могут выполнить несколько цепочек фильтров, система CUPS выбирает цепочку с наименьшей общей стоимостью. (Стоимость определяется тем, кто создал файл, напри- мер производителем дистрибутивов. Мы не знаем, как. Если вы хотите уточнить этот механизм, потому что считаете, что можете сделать это лучше, значит, у вас слишком много свободного времени.) Последним компонентом в конвейере CUPS является фильтр, который непосред- ственно взаимодействует с принтером. В PPD-файле принтера, не поддерживающего язык PostScript, можно увидеть строки типа *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip" или даже *cupsFilter: "application/vnd.cups-postscript foomatic-rip” Строка, заключенная в кавычки, имеет точно такой же формат, как и строка в файле mime. convs, но в ней указан только один тип MIME, а не два. Она сообщает о том, что фильтр foomatic-rip преобразовывает данные типа application/vnd. cups- postscript в родной формат данных принтера. Стоимость равна нулю (или вообще не указывается), потому что существует только один способ выполнить эту операцию^ так что зачем притворяться, что есть еще какая-то стоимость? (PPD-файлы проекта Gutenprint для принтеров, не поддерживающих язык PostScript, немного отличаются.) . Узнать, какие фильтры доступны в системе, можно при помощи команды locate pstops (pstops — это популярный фильтр, который выполняет с PostScript-зaдaниямt^ различные манипуляции, например добавляет PostScript-команды для указания количе- ства копий. Остальные фильтры обязательно будут где-нибудь поблизости). f Для того чтобы просмотреть список доступных серверных служб (back ends), выпол- ните команду Ipinf о -v. Если в используемой системе нет серверной службы для нет обходимого сетевого протокола, возможно, она доступна в Интернете или на сайте про- изводителя системы Linux. Управление сервером CUPS Демон cupsd запускается во время загрузки и выполняется непрерывно. Все изучен- ные нами разновидности системы Linux работают именно так по умолчанию. t Конфигурационный файл CUPS называется cupsd.conf; обычно его можно най- ти в каталоге /etc/cups. По формату он похож на конфигурационный файл Apache. Если вы умеете работать с одним из этих файлов, значит, сможете работать и с другим. Просматривать и редактировать файл cupsd.conf можно как с помощью текстово- го редактора, так и посредством графического пользовательского интерфейса CUPS. Стандартный конфигурационный файл хорошо прокомментирован. Эти комментарии и справочная страница cupsd. conf настолько подробные, что мы не будем повторять ту же самую информацию в книге. Система CUPS считывает файл конфигурации только в момент запуска. Если вы внесли изменения в конфигурационный файл cupsd. conf, то должны запустить систе- му печати снова, чтобы они вступили в силу. Если изменения вносились с помощью гра- фического пользовательского интерфейса через веб-браузер, то они вступят в силу ав- томатически. Для того чтобы перезапустить демон cupsd из командной строки, просто выполните команду /etc/init. d/cups restart или /etc/init. d. cupsys restart. Конфигурационный файл CUPS можно редактировать вручную или с помощью гра- фического пользовательского интерфейса. Если установлена настольная среда KDE, то
Глава 26. печать 1085 редактирование можно выполнить с помощью приложения KDE Print Manager, которое доступно через центр управления KDE. Когда мы его тестировали, он “жаловался” нам на то, что не понимает некоторые опции в создаваемых по умолчанию файлах cups. conf, на всех наших тестовых системах. Браузер графиского пользовательского интер- фейса безопаснее и, конечно, авторитетнее. Настройка сетевого сервера печати Для того чтобы заставить систему CUPS принимать задания на печать из сети, нужно внести два изменения в файл cupsd. conf. Сначала нужно изменить <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location> на cLocation /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From адресноети </Location> В качестве параметра адрес__сети следует указать IP-адрес сети, из которой должны приниматься задания на печать (например, 192.168.0.0). Далее нужно отыскать ключевое слово BrowseAddress и указать напротив него адрес рассылки в этой сети и порт CUPS. BrowseAddress 192.168.0.255:631 Эти два действия заставят сервер принимать запросы с любой машины в сети и рас- сылать известную ему информацию об обслуживаемом им принтере всем имеющимся в сети демонам CUPS. Вот и все! После перезапуска демон cupsd станет сервером. Автоматическое конфигурирование принтера На самом деле система CUPS может использоваться и без принтера (например, для преобразования файлов в формат PDF или формат факса), но в основном она все-таки используется для управления принтерами. В этом разделе речь пойдет о самих принтерах. В некоторых случаях добавление принтера является обычным делом. Система CUPS старается автоматически обнаружить USB-принтеры при их подключении и выяснить, что с ними нужно делать. Производители принтеров обычно предоставляют установочное программное обеспе- чение, которое автоматически (без участия пользователя) выполняет большую часть не- обходимых установочных операций на Windows и даже на Mac OS X (где тоже использу- ется система CUPS). Однако нельзя рассчитывать на то, что производители позаботятся о предоставлении подобного установочного программного обеспечения для системы Linux. Даже если установку приходится выполнять самостоятельно, процесс добавления принтера часто состоит всего лишь из подключения оборудования, установки соединения с веб-интерфейсом CUPS по адресу localhost: 631/admin и предоставления ответов на несколько вопросов. Среды KDE и GNOME поставляются с собственными утилитами для конфигурирования принтера, которые могут использоваться вместо интерфейса CUPS.
1084 Часть III. Разное Если кто-то другой добавляет принтер и об этом становится известно одному или более функционирующим в сети серверам CUPS, ваш сервер CUPS тоже уведомляется о появлении нового принтера. Ни добавлять этот принтер явно в локальный перечень устройств, ни копировать его PDD-файл на свою машину вам не нужно. Это магия. Конфигурирование сетевых принтеров Сетевым принтерам необходима собственная конфигурация только для того, чтобы быть членами сети TCP/IP. В частности, им необходимо знать свой IP-адрес и сетевую маску. Такая информация обычно передается им одним из двух способов. Почти все современные принтеры могут получать эту информацию по сети от серве- ра ВООТР или DHCP. Этот метод работает хорошо в средах со множеством гомогенных принтеров. Более подробную информацию о DHCP можно найти в разделе 14.7. Второй способ заключается в установке статического IP-адреса при помощи консоли принтера, которая обычно состоит из ряда кнопок на передней панели и однострочной индикаторной панели. Все, что нужно сделать, — это “походить” по меню и отыскать раздел, где можно установить IP-адрес. (Если вдруг попадется команда, позволяющая распечатать меню, следует воспользоваться ею и сохранить печатную версию.) Некоторые принтеры предоставляют доступ к виртуальной консоли через последователь- ный порт. Это замечательная идея, но в целом предполагает выполнение почти точно такого же количества операций, как и использование кнопок на передней панели принтера. После завершения конфигурирования сетевые принтеры обычно имеют веб-консоль, доступную через браузер. Однако для того чтобы с ними можно было работать через эту консоль, у них должен быть IP-адрес и они уже должны функционировать в сети, когда вы к ним обратитесь, так что этот интерфейс оказывается недоступным как раз тогда, когда он вам очень нужен. Когда принтер уже находится в сети и готов к использованию, нужно обязательно убедиться в том, что он защищен от несанкционированного доступа. О том, как это можно сделать, см. в разделе 26.12. Примеры конфигурирования принтеров В качестве примеров добавим принтер с параллельным интерфейсом groucho и се- тевой принтер fezmo из командной строки. $ Ipadmin -р groucho -Е -v parallel:/dev/IpO -m pxlcolor.ppd $ Ipadmin -p fezmo -E -v socket://192.168.0.12 -m laser jet.ppd Как вы видите, интерфейс groucho предоставляется через порт /dev/lpO, a femzo — через IP-адрес 192.168.0.12. Мы указываем каждое устройство в виде универсального идентификатора ресурса (URI) и выбираем PDD-файл из списка PDD-файлов, находя- щихся в каталоге /usr/share/cups/model. Если локальный демон cupsd сконфигурирован как сетевой сервер, он сразу же сде- лает эти новые принтеры доступными для других клиентов в сети. Поскольку сервер cupsd конфигурируется как сетевой, он немедленно делает новые принтеры доступными для других клиентов в сети. Перезапуск при этом не требуется. CUPS позволяет использовать для принтеров самые разные URI-идентификаторы. Вот еще несколько примеров. ipp://zoe.canary.com/ipp Ipd://riley.canary.com/ps serial://dev/ttyS0?baud=9600+parity=even+bits=7
Глава 26. Печать 1085 socket://gillian.canary.com:9100 usb://XEROX/Phaser%206120?serial=YGG210547 Одни URI-идентификаторы принимают параметры (например, serial), а другие — нет. Команда Ipinfо -v отображает список устройств, которые система может видеть, и список типов URI-идентификаторов, которые понимает система CUPS. Создание класса принтеров “Класс” — это группа принтеров, которые используют очередь совместно. Задания в очереди могут распечатываться на любом из этих принтеров, а именно на том, который становится доступен первым. Показанная ниже команда создает класс haemer и добав- ляет в него три принтера: riley, gilly и zoe. $ Ipadmin -р riley -с haemer $ Ipadmin -p gilly -c haemer $ Ipadmin -p zoe -c haemer Обратите внимание на то, что никакого явного шага для создания класса нет; класс существует только при условии добавления в него принтеров. На самом деле интеллек- туальные возможности системы CUPS этим не ограничиваются: если множеству прин- теров в сети присваивается одинаковое имя, система CUPS воспринимает их как неяв- ный класс и автоматически распределяет между ними связанную с заданиями нагрузку. Если не все принтеры расположены в одной комнате, это может оказаться неудобным. Отключение принтера Если вы хотите удалить принтер или класс, это можно легко сделать при помощи команды Ipadmin -х. $ Ipadmin -х fezmo $ Ipadmin -х haemer Но как быть, если нужно только временно отключить принтер для прохождения технического осмотра, а не удалять его? В таком случае можно просто заблокировать очередь печати на входе или выходе. Если отключить “хвост” (т.е. выходную или прин- терную сторону) очереди, пользователи по-прежнему смогут отправлять задания, но эти задания никогда не будут печататься. Если отключить “головную” (входную) часть оче- реди, те задания, которые уже находятся в очереди, будут распечатаны, а вот все попыт- ки добавить в очередь новые задания будут отклоняться. Команды cupsdisable и cupsenable контролируют выходную сторону очереди, а команды reject и accept — ее принимающую сторону.1 $ sudo disable groucho $ sudo reject corbet Какую же из них лучше использовать? Принимать задания на печать, которые точно не будут распечатаны в ближайшем будущем, глупо, поэтому для длительных периодов простоя лучше использовать команду reject. Для коротких перерывов, которые даже 1 В старых версиях системы CUPS вместо команд cupsdisable и cupsenable используются команды disable и enable. К сожалению, команда enable также является встроенной командой оболочки bash, поэтому оболочка bash предполагает, что вы используете ее собственную коман- ду enable, если не указать полный путь к команде. В этом случае выполняется версия команды enable из оболочки bash, которая включает и отключает встроенные команды этой оболочки, поэтому ее саму можно выключить, выполнив команду enable -n enable.
1086 Часть III. Разное не должны быть заметны пользователям (например, когда нужно просто удалить за- стрявшую в принтере бумагу), лучше использовать команду cupsdisable. Администраторы иногда просят дать им какую-нибудь подсказку, которая помогла бы им запомнить, какие команды контролируют каждый конец очереди. Предлагаем попробовать такой вариант: если система CUPS “отклоняет” (reject) задание, это означает, что его нельзя “предоставить”. Еще один способ не путать команды — это за- помнить, что приниматься (accept) и отклоняться (reject) могут только задания на печать, а отключаться (disable) и включаться (enable) — только принтеры. Система CUPS иногда сама временно отключает принтер, с которым не может нор- мально работать (например, из-за того, что кто-то выдернул его кабель). Устранив про- блему, следует снова активизировать очередь. Если забыть это сделать, команда Ips tat напомнит. (Более подробную информацию по этой теме и альтернативному подходу можно найти по адресу www. linuxprinting. org/beh.html.) Другие связанные с конфигурированием задачи Современные принтеры имеют очень много опций, которые можно конфигуриро- вать. Система CUPS позволяет настраивать самые разные функциональные возможности с помощью ее веб-интерфейса и команд Ipadmin и Ipoptions. Как правило, команду Ipadmin используют для выполнения задач на уровне системы, а команду Ipoptions — для выполнения задач на уровне пользователя. Команда Ipadmin позволяет более четко задать ограничения доступа, чем команды disable и reject. Например, с ее помощью можно создавать квоты на печать и указы- вать, на каких именно принтерах разрешается выполнять печать тем или иным пользо- вателям. В табл. 26.1 перечислены все команды, которые поставляются с системой CUPS, и их источники, в которых они использовались первоначально. Таблица 26.1. Утилиты командной строки, поставляемые с системой CUPS, и системы, в которых они использовались первоначально Команда •> „ . ' cups-configa Выводит информацию об API-интерфейсе, компиляторе, каталоге и канале связи системы CUPS cupsdconf8 Представляет собой утилиту для конфигурирования cupsdisable6 Останавливает печать принтера или класса 8 cupsenable6 Восстанавливает печать принтера или класса Ipinfo Показывает доступные устройства или драйверы Ipoptions Отображает или устанавливает опции и параметры по умолчанию принтера Ippasswd Добавляет, изменяет или удаляет пароли дайджеста accept, reject Принимает или отклоняет поступающие в очередь задания cancel Отменяет задания e ip ф H Печатает файлы £ Ipadmin Конфигурирует принтеры и классы CUPS Ipmove Перемещает задание в новое место Ipstat Печатает информацию о состоянии CUPS
Глава 26. Печать 1087 Окончание табл. 26.1 Команда 1рс Представляет собой общую программу для управления принтерами о со Ipq Отображает статус очереди принтера 03 Ipr Iprm Печатает файлы Отменяет задания на печать а Не пугайте эти похожие имена: cupsdconf — это утилита с графическим пользовательским интерфейсом (GUI), поставляемая с KDEPrint, a cups-conf ig — это утилита с интерфейсом командной строки (CU), по- ставляемая с CUPS. 6 На самом деле это просто переименованные команды disable и enable из System V. 26.3. Печать в настольных системах Мы уже упоминали о графическом пользовательском интерфейсе системы CUPS, который является альтернативой надстройкам для среды KDE. Этот графический интер- фейс широко признан и отлично работает. Рассмотрим теперь проблему переносимости. Возможно, вы уже сталкивались с тре- мя разными семействами систем печати, так зачем вносить дополнительную путаницу, заставляя администраторов разбираться с разными графическими пользовательскими интерфейсами? Если ваше руководство хочет печатать файлы из нового ноутбука Macin- tosh, то, возможно, вы не знаете, где надо щелкнуть, чтобы получить доступ к конфигу- рации новейшего пользовательского интерфейса, разработанного компанией Apple. Но если вы просмотрите порт localhost:631, то окажетесь на знакомой территории. Впрочем, если все ваши пользователи используют конкретные настольные системы, вы можете использовать для их поддержки графический пользовательский интерфейс. В каче- стве примера рассмотрим KDEPrint, доминирующее приложение для системы печати KDE. Программа KDEPrint включает средства для добавления принтеров, администрирова- ния заданий на печать, перезапуска серверов печати и т.д. Как и все остальные инструмен- ты системы KDE, она имеет внешний вид KDE, что делает их более понятными для поль- зователей KDE. (Не трудно заметить, что даже имена утилит KDE имеют определенный внешний вид. Однажды у нас кто-то спросил, является ли ksh приложением KDE.) Программа KDEPrint не зависит от системы CUPS. Несмотря на то что она может выполнять все функции системы CUPS, ее можно настроить на работу с любой систе- мой — от LPRng до универсальной внешней программы. Если по какой-то причине вы не используете систему CUPS (или, что еще хуже, вынуждены переключаться то на одну, то на другую систему печати), все равно можете использовать программу KDEPrint для управления процессом печати. Однако заранее предупреждаем, что CUPS мощнее дру- гих систем печати, так что если вы перейдете на какую-нибудь альтернативную систему печати, не исключено, что некоторые из функциональных возможностей KDEPrint вам больше не будут доступны. Ниже перечислены основные компоненты приложения KDEPrint, о которых следует знать. Утилита kprinter с графическим пользовательским интерфейсом, которая позво- ляет отправлять задания на печать. Мастер Add Printer, который автоматически обнаруживает сетевые принтеры (JetDirect, IPP и SMB) и некоторые принтеры, подключаемые локально. Он также по-
1088 Часть III. Разное зволяет добавлять и конфигурировать принтеры, которые не удается обнаружить авто- матически. Утилита Print Job Viewer, которая позволяет менять местами и отменять задания на печать, а также просматривать информацию об их состоянии. Руководство KDEPrint Handbook, в котором содержится необходимая справочная инфор- мация по данной системе. Оно доступно через панель KDE Help Center, но там его иногда трудно найти. Легче всего вызвать какую-нибудь программу наподобие kprinter и щел- кнуть на кнопке Help или же выполнить команду konqueror help: /kdeprint. Кроме того, документация по KDEPrint еще также доступна по адресу printing. kde. org. Программа Print Manager, которая является главным средством управления графи- ческим пользовательским интерфейсом для системы печати. Иногда ее тоже немного трудно найти. Можно попробовать поискать ее в главном меню рабочего стола, хотя ее расположение в дереве меню в каждом дистрибутиве выглядит по-разному. Еще один ва- риант — выполнить команду kcmshell printmgr или konqueror print: /manager. Мастер Add Printer и программа Print Job Manager доступны либо через kprinter, либо KDE Print Manager (не говоря уже об URL-адресах print: /manager и print: / printers в браузере Konqueror). Информация о пользователях KDEPrint хранится в каталоге ~/. kde. Эти файлы име- ют понятный для человека формат и их можно изменять через программу Print Manager. Если хотите, попробуйте отредактировать что-нибудь в них на свой страх и риск. Документы kprinter: printing Утилита kprinter — это имеющая графический интерфейс версия программы Ipr. Ее также можно использовать и из командной строки. Например, команда $ kprinter —nodialog -5 -₽ 1J4600 riley.ps gillian.pdf zoe.prn эквивалентна следующей команде. $ Ipr -5 -Р 1J4600 riley.ps gillian.pdf zoe.prn Ваши пользователи, скорее всего, захотят воспользоваться GUI-интерфейсом. Покажите им, как можно перетащить файлы из окна диспетчера файлов или с рабочего стола в диалоговое окно kprinter и затем распечатать их все сразу. Замените Ipr на kprinter в появляющемся в их браузере окне печати, и у них будет окно печати с GUI- интерфейсом. Научите их устанавливать флажок Keep this dialog open after printing, и они даже не будут тратить время на повторный запуск этой программы каждый раз, ког- да им необходимо будет напечатать что-нибудь. Обратите внимание на меню Print System currently in use, показывающее, что систе- ма KDEPrint сейчас не активна. Также обратите внимание на то, что когда принтер не доступен, kprinter предлагает выполнить печать в PDF или распечатать документ че- рез факс. Дополнительные опции тоже заслуживают внимания: они позволяют ставить в очередь на печать свое резюме и указывать, что оно должно быть распечатано после того, как начальник уйдет домой. Konqueror и печать Многие веб-браузеры распознают ряд специальных URI-адресов, которые выступают в роли шлюзов к уникальным функциональным возможностям. Вы, наверняка, пробо- вали вводить about: config и about :mozilla в окне Firefox. Точно так же семейство URI-адресов print: является в веб-браузере Konqueror шлюзом к KDEPrint.
Глава 26. Печать 1089 При вводе URI-адреса print: / отображается перечень всех возможностей, при вво- де print: / jobs — перечень заданий на печать, а при вводе print: /manager внутри Konqueror запускается программа Print Manager. Даже если вы не работаете с системой печати CUPS непосредственно, все значитель- но упрощается, если помнить, что система CUPS является веб-браузером. Браузеры зна- ют, как общаться с веб-серверами, поэтому их относительно легко оснастить функциями печати CUPS. 26.4. Система печати System V Программное обеспечение System V самое старое и простое среди всех рассматри- ваемых нами систем печати. Оно настолько старое, что вообще не предполагает работу в сети. Большинство разработчиков, использующих его, вынуждены были внести в него много изменений. Как это обычно бывает, некоторые из этих изменений оказались по- лезными, а некоторые нет. СреДи изученных нами операционных систем программное обеспечение System V используют системы Solaris и HP-UX. В обоих случаях программы System V были существенно модифицированы. Ниже мы рассмотрим стан- soians дартную систему, попутно отмечая изменения, внесенные разработчиками. Обзор Пользователь, желающий что-нибудь распечатать, должен использовать либо коман- ду 1р, либо команду, которая вызывает команду 1р неявно. Команда 1р заносит дан- ные в буферный каталог (spool directory), связанный с их пунктом назначения. Демон Ipsched определяет, когда и где следует распечатать данные, а затем выполняет интер- фейсную программу, форматирующую данные и посылающую их на соответствующий принтер. В табл. 26.2 перечислены команды системы печати System V. Таблица 26.2. Команды системы System V Общие accept /usr/sbin Включает режим постановки заданий в очередь cancel /bin Удаляет задания на печать из очереди disable /bin Выключает печать заданий, находящихся в очереди enable /bin Включает печать заданий, находящихся в очереди Ip /bin Ставит задания в очередь для печати Ipadmin /usr/sbin Конфигурирует систему печати Ipmove /usr/sbin Переносит задания из одной очереди в другую Ipsched /usr/sbin Планирует и выполняет задания Ipshut /usr/sbin Останавливает работу системы печати Ipstat /usr/sbin Выводит отчет о состоянии системы печати reject /usr/sbin Выключает режим постановки заданий в очередь Ipfilter /usr/sbin Управляет фильтрами печати Ipforms /usr/sbin Управляет использованием предпечатных форм
1090 Часть III. Разное Окончание табл. 26.2 Команда "1114 " IP" j м ", ,j. ?hiii Ipget /bin Считывает параметры конфигурации Ipset /bin Модифицирует параметры конфигурации Ipuser /usr/sbin Управляет приоритетами заданий в очереди Ipalt /bin Модифицирует задания в очереди Ipana /usr/sbin Анализирует регистрационные записи о работе системы печати Ipfence /usr/sbin Устанавливает минимальный приоритет задания на принтере Ipr /bin Поддерживает функции печати системы BSD Пункты назначения и классы “Пункт назначения” печати имеет имя, которое может состоять максимум из 14 букв, цифр и знаков подчеркивания. Пункт назначения — это, как правило, принтер, хотя и не обязательно. Например, пунктом назначения может быть файл, в который различные пользователи хотят добавить текст. Поскольку система печати является системой мас- сового обслуживания, команду 1р можно использовать для предотвращения ситуаций, когда два человека одновременно пытаются добавить текст в один и тот же файл. Каждый пункт назначения может относиться к одному или нескольким классам, но может и не принадлежать ни одному классу. Класс — это группа пунктов назначения, которые имеют одно и то же назначение. Например, если в организации два принтера стоят в одной комнате, то их можно объединить в один класс. Аналогично два принтера с одинаковыми параметрами (например, цветом, разрешением, дуплексом или скоро- стью) также можно отнести к одному классу. Демон Ipsched направляет данные, пред- назначенные для определенного класса, на тот из двух принтеров, который свободен в данный момент. Имена классов подчиняются тем же правилам, что и имена пунктов на- значения. Как бы там ни было, термин “пункт назначения” часто используется как синоним слов “принтер” или “класс”. Конкретный смысл этого термина зависит от контекста. Краткое описание команды 1р Это команда пользовательского уровня, которая помещает данные в очередь на пе- чать. Команда 1р копирует эти данные (которые могут поступать либо из именованных файлов, либо из стандартного ввода) в файл или в набор файлов в буферном каталоге. В системе HP-UX буферный каталог для пункта назначения обычно называется /var/ spool/lp/reques t/луж тиазначения, где пункт_назначения— это имя, под кото- рым этот принтер или класс принтеров известны команде 1р. Буферные файлы называются хххп, где п — идентификационный номер задания, при- своенный командой 1р, а часть имени ххх зависит от конкретной системы. Это имя файла позволяет идентифицировать задание как пользователю, так и системе печати для внутрен- них целей. Далее мы будем использовать это имя в качестве идентификатора задания. Запрос Ip -d ставит входную информацию в очередь на печать в конкретном пункте назначения. Если опция -d не указана, команда 1р использует в качестве имени пункта назначения содержимое переменной среды LPDEST. Если же эта переменная не уста- новлена, команда 1р ставит данные в очередь для вывода в пункте назначения, исполь- зуемом по умолчанию, который администратор может установить с помощью команды Ipadmin -d.
Глава 26. Печать 1091 В системе Solaris если пункт назначения по умолчанию не задан командой SOLSriS Ipadmin -d, то команда 1р ищет файл ~/ .printers, файл /etc/printers. conf и, наконец, службу Federated Naming Service как пункт назначения, за- данный по умолчанию. Команды Ipsched и Ipshut: начало и конец печати Демон Ipsched посылает файлы, помещенные в буферный каталог командой 1р, на соответствующее устройство по мере его освобождения. Он заносит в файл информа- цию о каждом обработанном файле и возникших ошибках. В операционной системе Solaris регистрационный файл по умолчанию имеет имя / var/1р/logs/Ipsched. Операционная система HP-UX хранит регистрационный файл в каталоге /usr/spool/lp/log. Когда демон Ipsched начинает работу (обычно во вре- мя загрузки), он переносит старый регистрационный журнал в каталог oldlog и начи- нает новый. Журнальный файл выглядит примерно так. ***** LP LOG: Jul 6 12:05 ***** prl-107 garth prl Jul 6 12:10 pr-112 scott prl Jul 6 12:22 pr-117 evi pr2 Jul 6 12:22 prl-118 garth prl Jul 6 12:25 prl-119 garth prl Jul 6 13:38 pr-132 evi prl Jul 6 13:42 В первой колонке указывается идентификатор задания, во второй — имя пользовате- ля, пославшего задание, в третьей колонке задается принтер, на который было послано задание, а в последней — время постановки задания в очередь. В системе HP-UX, взятой для этого примера, имеется два принтера — prl и рг2, ко- торые относятся к классу рг. Пользователь garth всегда указывал конкретный принтер prl, поэтому его задания постоянно посылались именно на него. Пользователи scott и evi, со своей стороны, указывали класс рг, поэтому их задания посылались на первый свободный принтер этого класса. Для того чтобы по какой-то причине прервать выполнение демона Ipsched, необ- ходимо выполнить команду Ipshut как суперпользователь или как пользователь 1р. Когда демон Ipsched не работает, никакие задания не печатаются, хотя можно продол- жать постановку заданий в очередь с помощью команды 1р. Задание, которое в момент останова демона печаталось, после его перезапуска будет напечатано сначала. Команда Ipsched создает файл /usr/spool/lp/SCHEDLOCK, который предназначен для индикации ее работы. Если попытаться запустить другую копию демона Ipsched, вы получите сообщение, что такой файл уже есть, и запуск демона будет прерван. Если выполнение демона Ipsched было прервано не с помощью команды Ipshut, а другими средствами, то перед перезапуском демона файл SCHEDLOCK обязательно нужно удалить вручную. Команда Ipadmin: конфигурирование среды печати Команда Ipadmin информирует систему печати о конфигурации принтеров. Она присваивает принтерам имена, создает классы и задания для принтера, используемого по умолчанию. На самом деле эта команда только создает текстовые файлы и модифи- цирует текстовые файлы в каталоге /usr/spool/1р.
1092 Часть III. Разное Несмотря на то что эти файлы конфигурации можно читать, рядом с ними неплохо бы поместить табличку: “Руками не трогать!” Эти файлы имеют жестко заданный фор- мат, так что их легко испортить. Разработчики операционной системы Solaris попытались использовать файл SOiariS описания принтера, принятый в системе BSD, чтобы облегчить конфигури- рование системы. Однако на деле это привело к разбиению конфигурации на два файла: /etc/printers. conf и /etc/lp. Операционная система Solaris требует, чтобы во время выполнения большинства ад- министративных команд работал демон Ipsched. С другой стороны, в операционной системе HP-UX большинство команд демона Ipadmin не выполняется, если работа- ет демон Ipsched. В этом случае демон Ipsched должен быть остановлен командой Ipshut и лишь после этого можно использовать демон Ipadmin. (Возможно, эти раз- работчики противятся переходу на систему CUPS, потому считают, что она будет одина- ковой во всех операционных системах и лишит мир богатого разнообразия?) Перед тем как система начнет вывод заданий на принтер, необходимо сообщить ей о том, что этот принтер существует. Для того чтобы добавить новый принтер, необходимо выполнить следующую команду. $ sudo Ipadmin -рпринтер -уустройство { -епринтер | -шмодель | ^интерфейс } [ -скласс ... ] [ { -1 | -h } ] Здесь принтер — это имя принтера (как внутреннее в системе организации очере- дей, так и на уровне пользовательских команд), а устройство — это файл устройства, с которым связан принтер. В качестве аргумента устройство обычно используется спе- циальный файл в каталоге /dev, хотя в принципе можно использовать любой файл. Флаги -е, -т и -i сообщают системе организации очередей, какую интерфейсную программу принтера она должна использовать. Интерфейсная программа отвечает за фактическое форматирование заданий, поступающих непосредственно на принтер. Ин- терфейсные программы в системе System V аналогичны фильтрам системы CUPS. Более подробную информацию о фильтрах можно найти в разделе 26.2. Интерфейсную программу можно задать одним из трех способов. • -епринтер, В этом случае принтер — это имя существующего принтера. Этот ме- тод задания интерфейсной программы полезен в том случае, если вы добавляете принтер, идентичный одному из уже имеющихся. Команда Ipadmin создает ко- пию интерфейсной программы с новым именем пункта назначения. • -тлмодель, В этом случае модель — это тип устройства, для которого в системе имеется стандартная интерфейсная программа. Информация о том, какие моде- ли поддерживает система, содержится в каталоге /usr/spool/lp/model. В этом случае команда Ipadmin создает копию файла /usr/spool/1р/model/модель в каталоге /usr/spool/lp/interface/пункт_назначения, • -^интерфейс. В этом случае интерфейс является полным именем пути для про- граммы, которая будет использоваться как интерфейсный сценарий. Большинство версий команды Ipadmin делает копию интерфейсной программы, поэтому если вы захотите изменить ее после запуска команды Ipadmin, необходимо будет заме- нить копию, а не свой оригинал. Система HP-UX позволяет определять программы, которые возвращают ин- формацию о состоянии очереди и отменяют задания печати. Их можно зада- вать как интерфейсные сценарии, но при этом используются другие префиксы
Глава 26. Печать 1093 параметров (префиксы -ост и -osm задают соответственно сценарий отмены и сценарий выдачи статуса). Кроме того, при вызове команды Ipadmin можно задавать следующие параметры. • -^принтер. Этот параметр сообщает команде Ipadmin, с какими принтерами вы хотите работать. Для того чтобы изменить принтер, необходимо комбинировать этот флаг с другими параметрами. • -скласс. Этот параметр задает имя класса, в который следует включить принтер. Для одного принтера можно задать сколько угодно классов. Если указан несуще- ствующий класс, он будет создан. Длина имени класса не должна превышать 14 символов. • -хпринтер. Этот параметр удаляет принтер из системы печати. Если принтер яв- ляется представителем целого класса принтеров, удаляется весь класс. Ни прин- тер, ни класс не могут быть удалены, если они уже выполняют задание из очереди на печать. Если поставленные в очередь задания мешают удалить принтер, ис- пользуйте команду reject, чтобы предотвратить загрузку в очередь печати новых заданий, а также команды Ipmove и cancel для удаления существующих заданий. Если команда Ipadmin -х по-прежнему не удаляет принтер, последуйте совету, приведенному в конце этого раздела. • -хкласс. Этот параметр удаляет принтер из заданного класса, а не из системы печати. Если указанный принтер является единственным представителем класса, удаляется сам класс. Команда 1р не принимает запросы к новому принтеру, пока ей не поступит таЙе указание от команды accept. Команды печати в системе System V вместо одного пункта назначения часто полу- чают список аргументов, заключенных в кавычки и разделенных запятыми. Например, команда $ sudo /usr/sbin/lpadmin -p”howler-lwzralphie-lw’’ -ceng-printers добавляет принтеры howler-lw и ralphie-lw в класс eng-printers. Флаги, которые используются при вызове программы Ipadmin, перечислены в табл. 26.3. Таблица 26.3. Флаги команды Ipadmin Флаг ' Функция •^принтер -дпункТ-Назначения -хпункТ-Назначения -скласс Задает принтер, к которому относятся все последующие параметры Назначает пункт назначения, используемый по умолчанию Удаляет пункт назначения из системы печати Добавляет принтер в класс -гкласс Удаляет принтер из класса -епункт_назначения ^интерфейс •шмодель -h -уфайл •^“описание” -L“ местоположение” Копирует интерфейсную программу для принтера Задает интерфейс в качестве интерфейсной программы для принтера Назначает модель интерфейсной программой для принтера Определяет, подключен ли принтер физически Определяет полный путь к файлу устройства, связанному с принтером Задает строку описания принтера Задает текстуальное описание местоположения принтера
1094 Часть III. Разное Примеры использования команды Ipadmin Рассмотрим несколько примеров использования команды Ipadmin. $ sudo Ipadmin -phowler-lw -v/dev/ttyO 6 -mPostScript -cpr Эта команда сообщает системе печати, что принтер с именем howler-lw назначен файлу устройства /dev/tty06 и что он должен относиться к классу рг, а также о том, что следует использовать интерфейсную программу для принтеров PostScript. Команда Ipadmin сама создает буферный каталог. Команда $ sudo Ipadmin -dpr задает используемый по умолчанию системный пункт назначения для класса (или прин- тера) рг. Команда $ sudo Ipadmin -phowler-lw -1"Conference room" задает строку описания принтера howler-lw. Команда $ sudo Ipadmin -phowler-lw -rpr -cfast удаляет принтер howler-lw из класса рг и добавляет его в класс fast. Команда $ sudo Ipadmin -xhowler-lw i полностью удаляет принтер howler-lw из системы печати. Команда Ipstat: получение информации о состоянии системы печати Команда Ipstat выдает информацию о состоянии системы печати. Если не указаны аргументы, эта команда сообщает статус всех заданий, которые посланы на печать задав- шим ее пользователем. Если задан аргумент -р, то она выдает информацию о состоянии конкретного принтера. Например, команда $ Ipstat -phowler-lw howler-lw is now printing pr-125. enabled since Jul 4 12:25 выводит информацию о состоянии принтера howler-lw. Статус демона Ipsched можно определить с помощью команды Ipstat -г. $ Ipstat -г scheduler is running В данном случае она сообщает, что все нормально. Флаги команды Ipstat перечис- лены в табл. 26.4. Таблица 26.4. Флаги команды Ipstat ' Флаг_________ Функция_______- ; ; г Выводит информацию о состоянии демона Ipsched * d Выводит информацию о пункте назначения, используемом по умолчанию - скласс Выводит список членов класса
Глава 26. Печать 1095 Окончание табл. 26.4 Флаг Функция , .• : •’’ЖЗЯ® -^аргумент -ипользователь Выводит информацию о состоянии запросов на вывод аргумента Выводит информацию о состоянии заданий, посланных на печать пользователем •^принтер -упринтер -апункт_назначения -S -t Выводит информацию о состоянии принтера Выводит информацию об устройстве вывода, связанном с принтером Выводит информацию о режиме постановки заданий в очередь пункта назначения Выводит краткую информацию о состоянии системы печати Выводит полную информацию о состоянии системы печати Команда cancel: удаление заданий печати Команда cancel удаляет из очереди задания, которые находятся в ней или печата- ются в данный момент. В этой команде можно указывать либо идентификатор задания (он определяется с помощью команды Ipstat), либо имя принтера (тогда отменяется задание, которое выводится на печать в данный момент). Ш Более подробную информацию о выполнении программ с установленным битом setid можно найти в разделе 6.5. Для команды cancel обычно установлены такие права доступа: владелец — псевдо- пользователь 1р, группа — bin, а код прав доступа — 6775, поэтому любой пользователь может выполнить ее и отменить явно фиктивное задание. Если задание отменяет тот, кто его не посылал, владельцу задания посылается сообщение по электронной почте. Если пользователи будут злоупотреблять этой возможностью, установите такой режим, чтобы команда cancel не устанавливала бит setuid. Команды accept и reject: управление очередью печати Если принтер недоступен длительное время (например, из-за неисправности), бу- феризацию заданий, посылаемых на это устройство, следует отключить, чтобы задания пользователей, не знающих о ситуации, не переполнили очередь. Отключение буфери- зации производится с помощью команды reject. Например, следующая команда за- ставляет демон 1р отменить запросы к принтеру howler-lw. $ sudo reject -r"howler-lw will be down until Tuesday" howler-lw Флаг -г является необязательным, однако это отличный способ сообщить пользо- вателям, почему принтер отклоняет запросы. При попытке вывести файл на печать, ко- манда 1р выведет следующее сообщение. $ Ip -dhowler-lw my file Ip: cannot accept requests for destination "howler-lw" — howler-lw will be down until Tuesday Команда accept принтер указывает демону Ip начать прием запросов к принтеру. Команду accept необходимо выполнять один раз для каждого нового принтера, добав- ляемого командой Ipadmin, потому что новые принтеры по умолчанию конфигуриру- ются так, чтобы запросы к ним отклонялись. Для того чтобы обеспечить возможность буферизации для целого класса, в командах accept и reject вместо имени принтера можно указать имя класса.
1096 Часть III. Разное Команды enable и disable: управление печатью Команда disable отдает демону Ipsched указание прекратить посылку заданий на конкретный принтер. В отличие от команды reject, команда disable позволяет утилите 1р продолжать ставить задания в очередь на этот принтер. Однако стоящие в очереди задания не будут выводиться на печать, пока принтер не будет повторно вклю- чен командой enable. Команда disable обычно не прерывает печать текущего зада- ния; это можно сделать с помощью флага -с. Как и команда reject, команда disable поддерживает флаг -г, который позволяет объяснить причину отключения принтера. Например, команда $ sudo disable -r"Being cleaned, back in 5 minutes" howler-lw выключает печать на принтере howler-lw. Для возобновления печати необходимо выполнить следующую команду. $ sudo enable howler-lw Команда Ipmove: перемещение заданий Иногда необходимо переместить задания, стоящие в очереди к одному принтеру или классу принтеров, на другой принтер. Это можно сделать с помощью команды Ipmove, которая получает список идентификаторов заданий и имя нового принтера. Например, команда $ sudo Ipmove howler-lw-324 howler-lw-325 anchor-lj перемещает задания с номерами 324 и 325 из очереди к принтеру howler-lw в очередь к принтеру anchor-lj. В качестве источника в команде Ipmove можно задать принтер или класс принтеров. Например, команда $ sudo Ipmove howler-lw anchor-lj перемещает все задания из очереди к принтеру howler-lw в очередь к принтеру anchor-lj. В этом случае возникает побочный эффект: к исходному принтеру приме-1 няется команда reject. В предыдущем примере демон 1р перестанет принимать запрет сы для принтера howler-lw. БЗ Операционная система HP-UX спроектирована так, чтобы команду Ipmove нельзя было использовать, если выполняется демон Ipsched. Вначале следуй* выполнить команду Ipshut. Интерфейсные программы Интерфейсная программа извлекает данные из файла, заданного демоном Ipsched, форматирует их и посылает в свой стандартный поток вывода. Кроме того, интерфейс- ная программа отвечает за правильную установку режимов на устройстве вывода и за формирование заголовков и завершителей, если они необходимы. Интерфейсные про- граммы, как правило, представляют собой сценарии оболочки, но могут быть и испол- няемыми двоичными файлами. Демон Ipsched вызывает интерфейсные программы со следующими аргументами. идентификатор_задания пользователь заголовок копии опции файл . . . Здесь использованы следующие аргументы. • идентификатор—Задания — назначается программой 1р;
Глава 26. Печать 1097 • пользователь — владелец задания; • заголовок — необязательный заголовок (задается пользователем); • копии — количество печатных экземпляров документа; • опции — указываемые пользователем параметры; • файл — полный путь к файлу, который следует распечатать. Перечисленные аргументы должны указываться при каждом выполнении интерфейс- ной программы, но некоторые из них могут быть пустыми строками. Стандартным вход- ным потоком для интерфейсной программы является файл /dev/null, а стандартные потоки вывода и ошибок направляются на устройство, заданное командой Ipadmin -v. В отличие от систем CUPS и BSD, в которых каждому формату файлов должна со- ответствовать собственная интерфейсная программа, в системе System V интерфейсные программы предназначены для обработки данных всех типов, которые поддерживает принтер. (Получив данные неизвестного типа, такие программы прекращают работу.) По этой причине интерфейсные программы обычно представляют собой сценарии обо- лочки, которые просто обрабатывают аргументы, а для выполнения реального формати- рования вызывают другие программы. По существу, интерфейсный сценарий в системе печати отвечает за весь этап вывода данных. Это облегчает настройку, но вместе с тем приводит к тому, что разные принтеры работают совершенно по-разному. Интерфейсы необходимы, если вы собираетесь печатать что-либо помимо текста, подготовленного специально для печати на PostScript-принтере. В настоящее время поч- ти все принтеры используют интерфейсы. Струйные принтеры обязательно используют интерфейсы для преобразования задания на печать в свой собственный формат. Если интерфейсная программа закончила свою работу успешно, то ее код заверше- ния равен 0; при ошибке он равен целому числу от 1 до 127. Если задание не выведено на печать, интерфейсный сценарий должен предпринять повторную попытку. Если же ошибка оказалась серьезной, интерфейсная программа должна отключить принтер с по- мощью команды disable. Если проблемы с печатью возникают постоянно, причину, скорее всего, следует искать именно в интерфейсном сценарии. Что делать, если система печати вышла из строя Иногда попытки задать или отменить конфигурацию принтера приводят к тому, что система печати выходит из строя. Файлы конфигурации, хранящие информацию о принтере, имеют сложную структуру и очень уязвимы. Один неверный символ может привести принтер в нерабочее состояние. Если каким-то образом вы создали принтер, который вывел систему печати из строя, то лучше всего полностью удалить его и начать все сначала. Иногда система запутывает- ся настолько, что принтер не удается даже удалить. В такой ситуации может спасти только метод грубой силы. В следующем примере мы попытаемся удалить принтер hoser. (Если имя hoser не уникально, этого делать нельзя.) $ sudo Ipshut $ sudo Ipadmin -xhoser $ sudo find /usr/spool/lp -name hoser -exec rm -rf {} ; # удаляем задания $ Ipsched $ Ipstat -t
1098 Часть ill. Разное Первые две команды отключают систему буферизации и пытаются удалить принтер. Если система запуталась, команда Ipadmin -х может не сработать. Команда find удаля- ет все интерфейсные программы и буферные каталоги, соответствующие данному прин- теру. Демон Ipsched перезапускает систему буферизации, а команда Ipstat использу- ется для проверки того, все ли ссылки на принтер hoser в системе печати уничтожены. 26.5. Печать BSD и AIX еМы могли бы назвать этот раздел просто “Печать в системе AIX”, поскольку AIX — единственная среди рассмотренных нами операционных систем, кото- рая все еще поддерживает систему печати BSD. Однако мы сохранили тради- ционное имя этой системы, поскольку ее все же можно обнаружить в некото- рых операционных системах, помимо AIX. Система печати BSD была разработана специально для использования старых иголь- чатых принтеров, но хорошая конструкция этой системы позволяет легко приспосабли- вать ее для поддержки большинства современных принтеров. Сетевая часть системы пе- чати BSD также хорошо масштабируется для использования в крупных неоднородных сетях и позволяет многим компьютерам совместно использовать принтеры. Программа буферизации печати Ipd, относящаяся к системе BSD, получила широкое распростра- нение и применяется во многих сетевых принтерах. Обзор архитектуры системы BSD В системе BSD доступом к принтерам управляет демон Ipd. Он принимает задания на печать от пользователей и других (удаленных) демонов Ipd, обрабатывает их и по- сылает на свободный принтер. Для того чтобы выполнить эти действия, демон Ipd счи- тывает данные о конфигурации принтера из файла /etc/printcap — системной базы данных, содержащей информацию о принтерах. Для отправки своих заданий демону Ipd пользователи вызывают программу 1рг. Эти два процесса взаимодействуют через сокет домена системы UNIX /dev/printer. Для того чтобы определить, какому принтеру послать задание, демон 1рг сначала анализирует командную строку. Если пользователь указал аргумент -Рпринтер, то пун- ктом назначения становится принтер. В противном случае демон 1рг проверяет, опре- делена ли переменная окружения PRINTER. Если эта переменная определена, демон 1рг использует ее значение. Во всех остальных случаях демон 1рг передает задание на общесистемный принтер, заданный по умолчанию. Его имя должно начинаться с букв 1р. Если таких символов нет, то используется первый принтер, указанный в файле /etc/ princap. Почти все команды, связанные с принтерами, включая команды Ipq и Iprm, понимают переменную окружения PRINTER и аргумент -Р. Как только программа 1рг узнает, на какой принтер направляется текущее задание, она начинает искать его в базе данных о принтерах системы /etc/printcap. Прочитав файл printcap, программа 1рг узнает, где хранится задание на печать для данного принтера. Этот буферный каталог обычно называется /var/spool I Ipd/имя_принтера. Для каждого задания программа 1рг создает в буферном каталоге два файла. Имя первого состоит из букв cf (control file) и числа, идентифицирующего задание. Этот файл содержит справочную информацию и информацию об обработке задания, напри- мер сведения о пользователе, который его послал. Числовая часть имени файла может состоять максимум из трех цифр, поэтому если в очереди более 999 заданий, система
Глава 26. Печать 1099 печати дает сбой. Имя второго файла начинается с букв df (data file) и заканчивается тем же числом. Этот файл содержит данные, которые должны быть выведены на печать. Поместив этот файл в очередь печати, программа 1рг уведомляет демона Ipd о суще- ствовании задания. Получив это уведомление, демон Ipd обращается к файлу printcap и выясняет, яв- ляется ли пункт назначения локальным или удаленным. Если принтер подключен ло- кально, демон Ipd проверяет наличие демона печати, обрабатывающего соответствую- щую очередь, и при необходимости создает его (копируя самого себя). Если соответствующий принтер подключен к другому компьютеру, демон Ipd уста- навливает соединение с демоном Ipd удаленного компьютера и пересылает туда файл данных и управляющий файл. Затем демон ipd удаляет локальные копии этих файлов. Планирование заданий печати осуществляется по принципу “первым пришел- первым вышел” (FIFO), но системный администратор может при желании изменить по- рядок печати с помощью команды 1рс. К сожалению, не существует способа постоянно указывать системе печати о том, чтобы она отдавала предпочтение заданиям, направ- ленным на печать конкретным пользователем или компьютером. Когда задание готово к печати, демон Ipd создает ряд каналов UNIX между буфер- ным файлом и печатающим устройством для передачи данных, подлежащих печати. Посредине этой цепочки демон Ipd устанавливает фильтрующий процесс, в задачи ко- торого входит просмотр и, возможно, редактирование содержимого потока данных, пре- жде чем они поступят на принтер. Фильтрующие процессы могут выполнять различные преобразования данных иди вообще ничего не делать. Их главное назначение — обеспечивать форматирование и поддержку любых связанных с устройствами протоколов, которые могут понадобиться для работы с конкретным принтером. Фильтр, заданный по умолчанию для конкретного принтера, указывается в файле /etc/printcap, но с помощью команды 1рг для прин- тера можно назначить другой фильтр. Управление средой печати Для ежедневного сопровождения системы печати достаточно знать всего три коман- ды: Ipq, Iprm и 1рс. Команда Ipq отображает содержимое очереди заданий конкретно- го принтера. Команда Iprm позволяет удалять одно или несколько заданий, при этом из системы печати удаляются соответствующие файлы данных и все ссылки на них. Обе команды доступны для пользователей и могут работать по сети, хотя только суперполь- зователь может удалить чье-то еще задание. Команда 1рс позволяет вносить изменения в среду печати, например отключать принтеры и переупорядочивать задания, стоящие в очереди. Некоторые ее функции до- ступны пользователям, но, в основном, это инструмент администратора. В табл. 26.5 перечислен ряд других команд и демонов системы BSD. Таблица 26.5. Команды системы BSD Команда ' Каталог / 1рс /usr/sbin Позволяет управлять принтером или очередью на печать Ipd /usr/sbin Планирует обработку заданий и направляет их на печать Ipq /usr/bin Отображает содержимое очереди на печать и статус заданий в ней Ipr /usr/bin Ставит задания в очередь на печать
1100 Часть III. Разное Окончание табл. 26.5 Iprm /usr/bin Отменяет задание Iptest/usr/bin Генерирует тестовую ASCII-страницу Демон Ipd: буферизация заданий на печать Демон Ipd, запущенный с флагом -1, регистрирует задания на печать в системе Sys- log от имени средства Ipr. При отсутствии этого флага демон регистрирует только си- стемные ошибки. Контроль доступа осуществляется на уровне отдельных компьютеров. Система BSD не позволяет контролировать конкретных удаленных пользователей. Только компьюте- рам, указанным в файле /etc/hosts.equiv или /etc/hosts.Ipd, разрешено ставить задания в очередь. По соображениям безопасности, использовать файл hosts .equiv не рекомендуется; применяйте лучше файл hosts. Ipd. Команда Ipr: выдача заданий на печать Это единственная команда в системе BSD, которая может помещать задания в оче- редь на печать. Все остальные программы печати файлов (например, enscript и брау- зер) вынуждены вызывать эту команду. Флаг -Ъчисло позволяет напечатать указанное количество копий документа, а флаг -h запрещает печать титульной страницы. Например, для того чтобы напечатать две копии файла thesis на принтере howler-lw, следует выполнить следующую команду. $ Ipr -Phowler-lw -#2 thesis Команда Ipq: просмотр очереди печати Рассматриваемая команда обычно вызывается с опцией -Р для выбора принтера, но есть и опция -1, позволяющая получить более детальный отчет. Выходные данные ко- манды выглядят примерно так. $ Ipq anchor-lj is ready and printing Rank Owner Job Files Total Size active garth 314 domain.2xl.ps 298778 bytes 1st kingery 286 standard input 17691 bytes 2nd evi 12 appendices 828 bytes Выходные строки всегда расположены по порядку: активное задание указывается первым, а последнее — в самом низу. Если первое задание обозначено как 1st, а не как active, значит, демон печати не запущен. Во втором столбце приводится имя пользователя, который послал задание на печать. В третьем столбце указывается идентификатор задания. Его необходимо знать, если за- дание должно обрабатываться с помощью команд Iprm или 1рс. В четвертой колонке перечислены файлы, посылаемые на печать (они были заданы в строке вызова коман- ды Ipr). Если данные для печати поступили через канал (как, например, первое и пятое задания в нашем примере), в этой колонке будет стоять запись standard input. В пя- той колонке указывается размер задания. Это значение соответствует размеру задания до его передачи программе-фильтру и не дает информации о том, сколько страниц займет задание и как долго оно будет печататься.
Глава 26. Печать 1101 Команда Iprm: удаление заданий на печать Самая распространенная форма команды Iprm — Iprm номер, где номер — это идентификатор задания согласно выходным данным команды Ipq. Команда Iprm пользователь удаляет все задания, принадлежащие указанному пользователю. Команда Iprm без аргументов уничтожает активное задание. Команда Iprm - (это дефис) удаляет все задания, посланные на печать текущим пользователем. Если это пользователь root, уничтожаются все задания, стоящие в очереди. Рядовой пользователь не может удалять чужие задания, в отличие от суперпользователя. В противоположность ожидаемому, команда Iprm делает ошибки молча, а при успешном завершении выдает результат. Если вы не видите результат вроде строк dfA621xinet dequeued cfA621xinet dequeued после запуска команды Iprm, значит, команда не была выполнена, т.е. она либо не смогла удалить задание, либо вы ее неправильно вызвали. Система печати записывает узлы, откуда поступило задание, и пользователя, кото- рый его послал. Эта информация учитывается командой Iprm. Таким образом, пользо- ватель garth@boulder не эквивалентен пользователю garth@sigi, и ни один из них не имеет права удалять задания другого. Попытка удалить с помощью команды Iprm активное задание может вызвать про- блемы на некоторых принтерах. Фильтрующий процесс, связанный с заданием, надле- жащим образом не уведомляется о его уничтожении, вследствие чего вся система “за- висает”, а фильтрующий процесс продолжает блокировать порт принтера, не допуская к нему другие процессы. Единственный способ исправить положение — определить идентификаторы филь- трующих процессов с помощью команды ps и вручную уничтожить их. Команда 1рс в такой ситуации бесполезна. В принципе, при зависании демона Ipd можно переза- грузить систему, но это радикальная мера. Прежде чем прибегнуть к ней, попробуйте уничтожить и перезапустить главный процесс Ipd, а также вручную удалить задания из буферного каталога с помощью команды rm. Команда 1рс: внесение административных изменений Команда 1рс выполняет следующие функции: • включение и выключение режима постановки заданий в очередь на конкретный принтер; • включение и выключение печати на конкретном принтере; • удаление всех заданий из очереди принтера; • перемещение задания в начало очереди; • запуск, останов и перезапуск демона Ipd; • получение информации о состоянии принтера. Пока система печати работает нормально, команда 1рс тоже функционирует кор- ректно. Но стоит “зависнуть” фильтру или появиться другой незначительной проблеме, как команда 1рс полностью теряет контроль и начинает просто “врать”: иногда она за- являет, что все исправлено, тогда как на самом деле ничего подобного не произошло. Приходится устранять проблемы вручную и даже отключать и включать питание, если печать выполняется очень плохо.
1102 Часть III. Разное Команду 1рс нельзя вызывать по сети; нужно зарегистрироваться на компьютере, к которому подключен принтер. Обычно команда используется в интерактивном режи- ме, хотя возможен и одноразовый ее вызов путем включения интерактивной директивы в командную строку. Команда 1рс понимает описанные ниже директивы. help [директива] Если директива help вводится без аргументов, то выдается краткий перечень всех поддерживаемых директив. При наличии аргумента выдается однострочное описание указанной директивы. enable принтер disable принтер Эти директивы включают и выключают буферизацию заданий для указанного прин- тера. Если постановка задания в очередь невозможна, пользователю сообщается об этом. Задания, уже находящиеся в очереди, не затрагиваются. Указанные операции реализу- ются путем установки или сброса бита, обозначающего право выполнения для группы, которой принадлежит файл /var/spool/lpd/wpwH/wep/lock. start принтер stop принтер Эти директивы включают и выключают режим печати на указанном принтере. После выполнения директивы stop постановка заданий в очередь продолжается, однако вывод их на печать будет приостановлен до тех пор, пока режим печати вновь не будет вклю- чен. Эти операции реализуются путем установки или сброса бита, обозначающего право выполнения для владельца файла /var/spool/Ipd/принтер/lock. Кроме того, опи- сываемые директивы запускают и уничтожают соответствующие демоны печати. После получения директивы stop сначала завершается активное задание и только затем вы- ключается режим печати. abort принтер Директива abort аналогична директиве stop, но при этом активное задание немед- ленно прерывается. После возобновления печати оно будет печататься заново. down принтер сообщение up принтер Эти директивы влияют и на буферизацию, и на печать. Они используются в слу- чае серьезного сбоя принтера, когда необходимо отключить его на длительное время. Параметр сообщение директивы down может иметь произвольную длину (в пределах одной строки) и не должен заключаться в кавычки. Указанное сообщение помещается в файл /var/spool/Ipd/принтер/status и выдается всем пользователям, которые вы- полняют команду Ipq. Как правило, сообщение содержит краткое разъяснение причи- ны отключения принтера и информацию о том, когда он вновь заработает. Директива up выполняет противоположные действия. clean принтер Эта директива удаляет из очереди на принтер все задания, включая активное. По- скольку демон обработки очереди все равно будет содержать ссылки на файлы текущего задания, Linux не удалит их по-настоящему, и текущее задание будет завершено. topq принтер номер_задания topq принтер имя_пользователя
Глава 26. Печать 1103 Первая директива topq перемещает в начало очереди указанное задание, а вторая — все задания, принадлежащие заданному пользователю. restart принтер Эта директива используется для перезапуска демона печати, который по каким-то причинам завершил работу. При отсутствии демона команда Ipq сообщает: “No daemon present”. На первый взгляд может показаться, что действие директивы restart анало- гично действию связки stop/start, но это не так: если продолжает работать фильтр печати, то с помощью директивы restart перезапустить демон нельзя. status принтер Эта директива сообщает следующие сведения об указанном принтере: включен ли режим буферизации, разрешена ли печать на нем, сколько заданий стоит в очереди и каково состояние демона данного принтера. Если в очереди нет заданий, будет выдано примерно следующее. lpc> status сег сег: queuing is enabled printing is enabled no entries no daemon present Факт отсутствия демона сам по себе не является причиной для беспокойства. Если очередь пуста, демоны печати прекращают работу и запускаются вновь главным процес- сом Ipd только при постановке в очередь нового задания. Файл /etc/printcap Этот файл является главной базой данных системы BSD. В ней содержится инфор- мация, необходимая для печати на локальных и удаленных принтерах. Задания на прин- тер можно передавать только в том случае, если он описан в этом файле. Каждая запись файла printcap начинается со списка имен принтера, разделенных символами вертикальной черты (|). Затем следует ряд конфигурационных параметров, разделенных двоеточиями. Каждый параметр имеет вид хх, хх=строка или хх# число, где хх — двухсимвольное имя параметра, а строка и число — присваиваемые ему значе- ния. Если никакого значения не присваивается, то переменная является булевой и ей соответствует значение “истина”. Допускаются пустые операторы: два двоеточия, стоящих рядом. Рекомендуется начи- нать и заканчивать каждую строку двоеточием, чтобы в будущем легче было вносить из- менения. Комментарии в файле /etc/printcap должны начинаться со знака #. Запись может занимать несколько строк, при этом строки, имеющие продолжение, должны заканчиваться обратной косой чертой. По соглашению, строки продолжения немного сдвигаются вправо по отношению к первой позиции. В качестве иллюстрации приведем небольшой пример, в котором определяется уда- ленный принтер, подключенный к компьютеру anchor. anchor-1j|сег|1-56|LaserJet 5M in cer lab: :lp=/var/spool/lpd/anchor-lj/.null: :sd=/var/spool/lpd/anchor-lj : :lf=/var/adm/lpd-errs: :rw:mx#0:rm=anchor:rp=anchor-lj:
1104 Часть III. Разное Из первой строки видно, что cer, anchor-lj, 1-56 и LaserJet 5М in cer lab — эквивалентные имена одного принтера. Принтерам можно присваивать сколько угодно имен, но обязательно следует указывать три формы основного имени: • сокращенную (три-четыре символа, которые удобно вводить, например сег); • полную (имя компьютера и тип принтера, например anchor-lj); • описательную (прочая информация, например LaserJet 5М in cer lab). Следующие три строки примера содержат конфигурационные параметры для име- ни устройства (1р), буферного каталога (sd) и журнала ошибок (If). Последняя стро- ка определяет режим чтения/записи при подключении к принтеру (rw), максимальный размер файла (шх; в данном случае не ограничен), имя удаленного компьютера (rm) и, наконец, имя удаленного принтера (гр). Задания, поступившие в систему печати и не адресованные конкретному принтеру, направляются на первый принтер, среди псевдонимов которого есть 1р. Псевдоним 1р нельзя использовать в качестве основного имени принтера, поскольку замена стандарт- ного принтера в этом случае будет затруднена. Если принтер с именем 1р отсутствует, используется первый принтер, описанный в файле printcap. Переменные файла printcap Своей гибкостью система BSD во многом обязана файлу printcap. Его структура хорошо описана на соответствующей man-странице, поэтому мы рассмотрим лишь са- мые полезные переменные этого файла (табл. 26.6). Таблица 26.6. Наиболее часто используемые переменные файла printcap sd строка Буферный каталог sd=/var/spool/lpd/howler-lw If строка Журнал ошибок lf=/var/log/lpd-errors 1Р строка Имя устройства lp=/dev/lpO af строка Файл учета af=/var/adm/lpr.acct rm строка Имя удаленного компьютера rm=beast.xor.com rp строка Имя удаленного принтера rp=howler-lw of строка Выходной фильтр of=/usr/libexec/lpr/lpf if строка Входной фильтр if=/usr/sbin/stylascii mx число Максимальный размер файла mx#0 sh булев Подавление печати титульных страниц sh Все записи файла printcap должны включать, как минимум, спецификацию буфер- ного каталога (sd), журнала ошибок (If) и устройства печати (1р). Если используется современный принтер, нужно включить режим чтения/записи (rw), чтобы принтер мог возвращать сообщения об ошибках и статусные сообщения. Переменная sd: буферный каталог У каждого принтера должен быть свой буферный каталог. Такие каталоги должны на- ходиться в одном родительском каталоге (обычно это /var/spool/lpd) и называться в соответствии с полными именами обслуживаемых ими принтеров (в нашем примере это anchor-lj). Буферный каталог необходим даже в том случае, когда описываемый прин-
Глава 26. Печать 1105 тер подключен к другому компьютеру. Задания находятся на локальном компьютере до тех пор, пока не будут переданы на печать. При инсталляции нового принтера необходимо создать буферный каталог вручную и назначить ему режим доступа 775. Владельцем этого каталога должен быть пользователь daemon, и группа тоже должна называться daemon. В буферном каталоге находятся два статусных файла: lock и status. Файл status содержит однострочное описание состояния принтера. Эту строку формирует демон Ipd; она отображается командой Ipq. Назначение файла lock заключается в том, чтобы избежать активизации нескольких экземпляров демона Ipd для одной очереди. Кроме того, в нем хранится информация об активном задании. В процессе управления очере- дью печати и печатью на принтере команда 1рс изменяет права доступа к файлу lock. Переменная If: журнал ошибок Сообщения, генерируемые фильтрами печати, помещаются в журнал ошибок. Один общий журнал может совместно использоваться всеми принтерами и располагаться где угодно. В каждой записи этого файла указывается имя соответствующего принтера. Журнальные файлы должны создаваться даже для удаленных принтеров, на случай если вдруг возникнет проблема со связью. Ш Подробнее о журнальных файлах рассказывалось в главе 11. Помните о том, что демон Ipd посылает сообщения об ошибках в систему Syslog. Не- которые фильтры направляют сообщения туда же, ничего не оставляя в журнальном файле. В случае возникновения проблем проверяйте оба источника информации. Переменная 1р: имя устройства Имя устройства должно назначаться только локальному принтеру. Обычно это имя файла в каталоге /dev, связанного с портом, к которому подключен принтер. Демон Ipd проверяет наличие блокировки файла, указанного в переменной 1р, что- бы определить, используется ли принтер. Даже если доступ к принтеру осуществляется через сетевое соединение, переменная 1р обязательно должна быть задана. Необходимо указать уникальный файл, который существует на локальном диске. Переменная rw: режим открытия устройства Если принтер возвращает информацию о своем состоянии через файл устрой- ства, должна быть определена булева переменная rw, запрашивающая открытие файла устройства в режиме чтения/записи. Этот режим используется для учета использования принтера и передачи статусных сообщений, поэтому некоторые фильтры требуют вклю- чения такого режима. Переменная af: файл учета Можно учитывать объем распечатываемой пользователями информации, просто ука- зав файл учета на компьютере, к которому принтер подключен физически. Записи вно- сятся в файл по завершении вывода задания на печать. Для обобщения учетной информации используется команда рас. По соглашению, учетные файлы принтеров называются /var/adm/принтер-acct. В них фиксируется количество страниц, напечатанных по каждому заданию (обычно не соответствующее действительности), имя компьютера, от которого было получено задание, а также имя владельца задания.
1106 Часть III. Разное Записи для учета генерируются входным фильтром печати. Не стоит доверять счет- чику страниц, если только фильтр не запрашивает показания счетчика до и после печати очередного задания. Переменная тх: ограничения на размеры файлов Эта переменная задает предельный объем данных, посылаемых на печать за раз. Это значение имеет смысл только для построчно печатающих принтеров. Небольшие файлы формата PostScript или PCL могут выводить на печать сотни страниц. В некоторых системах значение тх, устанавливаемое по умолчанию, отлично от нуля (О означает отсутствие ограничений), и для того чтобы иметь возможность выводить на печать большие задания, необходимо явно указать тх#0. Отметим, что тх является чис- ловой переменной, поэтому выражение тх=0 ошибочно. Переменные гт и гр: информация об удаленном доступе В большинстве случаев к принтеру необходимо обращаться не с одного, а с несколь- ких компьютеров. Даже если принтер является сетевым устройством, следует выбрать один компьютер и назначить его ответственным за связь с принтером. Все остальные компьютеры должны пересылать ему свои задания. Это позволяет демону Ipd создавать единую очередь заданий, что исключает случаи конфликтов между компьютерами за право управления принтером. Кроме того, если печать не работает, администратор будет знать, где искать причину. В файле printcap удаленного компьютера (не имеющего непосредственного соеди- нения с принтером) будет присутствовать запись, в которой указывается, куда направ- лять задания. Переменная rm определяет компьютер, на который должны посылаться задания, а переменная гр задает имя принтера на этом компьютере. Тот факт, что записи файла printcap для локальных и удаленных принтеров отли- чаются друг от друга, затрудняет совместное использование этого файла на разных ком- пьютерах. Выход заключается в том, чтобы сделать локальное и сетевое имена принтера разными, например howler-lw-local и howler-lw. В такой конфигурации принтер howler-lw будет “удаленным” даже для того компьютера, к которому он непосред- ственно подключен, что вполне допустимо. Однако при работе с командой 1рс придется указывать имя howler-lw-local. Переменные of и if: фильтры печати Фильтры выполняют ряд функций. Фильтр печати, заданный по умолчанию (обыч- но это /usr/lib/lpf), обрабатывает различные управляющие последовательности и, если требуется, генерирует записи для учета. Не существует единого стандарта фильтров. Каждый поставщик стремится разработать свой набор уникальных фильтров, что услож- няет задачу администраторам. Даже если используется лазерный или струйный принтер или даже старинное набор- ное устройство или плоттер, вместе с программным обеспечением принтера обязательно поставляются необходимые фильтры. Фильтры — это, как правило, просто сценарии оболочки, которые вызывают ряд программ преобразования данных. Фильтрующая программа должна принимать зада- ние из стандартного входного потока, преобразовывать его в формат, поддерживаемый устройством, и записывать результат в стандартный выходной поток. Если при вызове команды 1рг пользователь не указал фильтр, будет использовать- ся либо входной (переменная if), либо выходной (переменная of) фильтр. Термины
Глава 26. печать 1107 “входной/выходной фильтр” не должны вводить в заблуждение, так как оба фильтра по- сылают данные на принтер. Если в файле /etc/printcap присутствует переменная if, но нет переменной of, файл устройства будет открываться один раз для каждого задания, а программа-фильтр будет посылать одно задание на принтер и завершать работу. Если определен только выходной фильтр, демон Ipd однократно откроет файл устройства и вызовет программу-фильтр для обработки сразу всех заданий в очереди. Это полезно для тех устройств, соединение с которыми устанавливается очень долго, хотя такие устройства встречаются редко. Если определены оба фильтра, то выходному посылается титульная страница (этот фильтр вызывается даже в том случае, когда печать титульных страниц отключена), а входной обрабатывает остальную часть задания. Такая комбинация слишком сложна для непосвященных, поэтому лучше ее избегать. При написании новых фильтров ориентируйтесь на входные фильтры: их легче от- лаживать. Входные фильтры вызываются с многочисленными аргументами. Наиболее интересные из них — имя пользователя, имя компьютера и имя учетного файла. Если требуется организовать учет работы принтера, то входной фильтр должен генерировать записи для учета и добавлять их в конец учетного файла. Если необходимо ограничить доступ к принтеру (например, запретить печать пользователю guest на всех компьюте- рах), то это тоже должен делать входной фильтр, поскольку демон Ipd не имеет соот- ветствующих встроенных средств. В качестве иллюстрации рассмотрим очень простой пример входного фильтра. В дан- ном случае это фильтр PostScript-принтера, подключенного через последовательней порт к локальному компьютеру. #!/bin/csh -f /usr/local/bin/textps $* | /usr/local/bin/psreverse Поскольку принтер подключен последовательно, демон Ipd открывает файл устрой- ства в соответствующих режимах согласно указаниям файла /etc/printcap. Первой вызывается программа textps, которая анализирует входные данные и определяет их формат. Если это не PostScript (формат, поддерживаемый принтером), выполняется пре- образование. Программа textps принимает все аргументы фильтра ($*) и на основе этой информации генерирует записи для учета. Вторая программа, psreverse, изменяет порядок следования страниц на противоположный. Переменные файла printcap для устройств последовательного доступа Многие переменные и функции из файла printcap используются для работы с уста- ревшими принтерами, подключаемыми к последовательному порту. Если вы устанавли- ваете сетевой принтер, то найдите время и откройте руководство, найдите специфика- ции, касающиеся взаимодействия с принтером, и хорошенько напейтесь. Если же вы не пьете, то потратьте деньги, предусмотренные в смете для покупки алкоголя, на приоб- ретение нового принтера. Расширения файла printcap У системы BSD есть одна прекрасная особенность: если пользователь задает зна- чения нестандартных переменных файла printcap, они игнорируются. Часто, когда конкретному принтеру нужно больше сведений о конфигурации, чем имеется в базовой системе, можно определить в файле printcap дополнительные переменные, которые будут использоваться фильтрами печати.
1108 Часть III. Разное Например, выходному фильтру сетевого принтера может потребоваться сетевое имя этого устройства. В запись файла printcap для этого принтера можно добавить следую- щую установку. :nn=laser.Colorado.edu: Использование такого рода расширений позволяет хранить всю информацию о кон- фигурации принтера в одном, удобном для администратора месте. Если вы вдруг увиди- те в файле printcap переменные, не упомянутые на man-странице, поищите их значе- ния в документации к фильтрам принтера. В нашей сети описанным выше способом документируется физическое расположе- ние каждого принтера. Все принтеры имеют установки следующего ввда. :lo=Room 423, Engineering building: Мы используем сценарии, которые отслеживают наличие бумаги и запас тонера в принтерах и при возникновении проблем посылают группе технического обслуживания сообщения типа “Добавьте бумагу в принтер, находящийся в комнате 423 здания маши- ностроительного факультета”. 26.6. Долгая странная история Из предыдущих разделов становится ясно, насколько разнятся три основные систе- мы печати’ почему разработчикам стоит отказываться от старых систем и переходить на систему CUPS и почему ее разработчики приняли мудрое решение сохранить команды* напоминающие команды старых систем. Как же все это произошло? Приведем краткое изложение истории систем печати. История печати и появления систем печати Много лет тому назад были распространены игольчатые принтеры. Лазерные прин- теры встречались редко, да и стоили дорого. Для устройств вывода с высоким разрешу нием требовались специальные драйверы и программы для форматирования. ч В настоящее время лазерные принтеры часто подключены к сети TCP/IP через ин- терфейс Ethernet, Wi-Fi или Bluetooth, а не к единственному компьютеру с помощь^ последовательного или параллельного порта. На рынке дешевой продукции лазерные принтеры уступили место струйным. Цветными принтерами, которые когда-то счита- лись роскошью и обеспечивали качество печати, сравнимое с качеством цветной фото- графии и изображений на дисплеях, сегодня никого не удивишь. Найти черно-белый принтер скоро будет также сложно, как черно-белый телевизор, если к тому времени телевизоры вообще сохранятся. Специализированные принтеры, сканеры, копировальные машины и факсы по- степенно вытесняются многофункциональными устройствами, которые способны вы- полнять всю их работу. Некоторые из них уже сейчас могут считывать файлы непосред- ственно из микросхемы памяти на цифровой видеокамере. Прежние принтеры были примитивными, как и их механизмы буферизации. Пред- полагалось (по правилам), что компьютер, на котором вы работали, непосредственно подсоединен к принтеру. Конфигурирование принтера сводилось к ответу на вопрос: “Последовательный или параллельный интерфейс?” Это касалось и операционных си- стем, отличных от UNIX, хотя все они были специализированными: системы IBM зна- ли, как управлять принтерами IBM, компьютеры Apple знали, как управлять принтерами
Глава 26. Печать 1109 Apple, и т.д. Используемый компьютер часто должен был (по правилам) подключаться к принтеру напрямую. Настройка принтера заключалась в предоставлении ответов на вопросы типа “Принтер с последовательным интерфейсом или принтер с параллельным интерфейсом?” Первым коммерческим приложением для системы UNIX, проданным компанией INTERACTIVE Systems Corporation, была система подготовки документов для юридиче- ской фирмы. Основными компонентами этой системы были текстовый редактор, языки разметки (nroff/trof f) и программы для печати. Поскольку технологии становились все сложнее и сложнее, предпринимались по- пытки создать универсальный стандарт, но ни одна из них не имела должного успеха. Используемые протоколы устаревали и работали все хуже и хуже. Системы печати BSD и System V были разработаны довольно давно для игольчатых принтеров. Эти системы, переделанные и перегруженные в попытках догнать развиваю- щиеся технологии, так никогда и не смогли обеспечить поддержку современных прин- теров, и каждая новая функциональная возможность принтеров, например дуплексиро- вание (двусторонняя печать), требовала специальных доработок. Почему же существовали только две конкурирующие системы печати и почему так важны различия между ними? Встаньте посредине группы пользователей и воскликните: “Все, кто использует команду vi вместо emacs, — идиоты!”, а затем приходите и зада- вайте свои вопросы. Когда стали доступны сетевые принтеры, количество проблем только возросло. Первые сетевые системы печати были слишком уникальными и использовали ряд про- токолов для обеспечения связи между принтером и очередью печати, между клиентом и очередью печати и для осуществления обмена сетевым трафиком. Принтеры JetDirect компании HP часто принимали необработанные данные на порт 9100, как это делали принтеры старых разработчиков, принявших правила компании HP. Принтеры с внутренними демонами Ipd (реализациями протокола BSD) принимали задания на порту 515. Стиснув зубы, рабочая группа по решению проблем печати (Printing Working Group) из института IEFT создала протокол IPP (Internet Printing Protocol — протокол печати через Интернет) поверх протокола HTTP. Он не только оформлял взаимодействия в виде простых запросов GET и POST, но и позволял системам печати пользоваться преимуще- ствами стандартных, широко используемых технологий для аутентификации, контроля доступа и шифрования. Майкл Свит (Michael Sweet) и Эндрю Сенфт (Andrew Senft) из компании ESP (Easy Software Products) перенесли IPP в UNIX в виде реализации CUPS. Компания Apple адаптировала систему печати CUPS для операционной системы Mac OS X (и в 2007 году купила ее исходный код), после чего система CUPS стала самой полноценной реализа- цией протокола IPP на планете. Система CUPS является свободно распространяемым проектом с открытым кодом, в котором устранены проблемы, связанные со старыми си- стемами. Разнообразие принтеров Кроме разнообразия систем печати, администраторы столкнулись с разнообразием самих принтеров. Поскольку принтеры могут подключаться к компьютерам, пользователи отождест- вляют их с периферийными устройствами, такими как мышь и мониторы. Однако они
1110 Часть III. Разное представляют собой более сложные устройства. На самом деле они больше напоминают смартфоны или маршрутизаторы, но с движущимися частями. Одно время самым мощным компьютером, который когда-либо создавала компания Apple, был принтер Apple LaserWriter. В настоящее время ваш настольный компьютер, вероятно, мощнее принтера, но принтер остается компьютером. Он имеет центральный процессор, память, операционную систему, а иногда и диск. Сетевой принтер имеет свой сетевой стек и IP-адрес. Если у вас есть сетевой прин- тер, введите его адрес (или имя DNS) в ваш веб-браузер. Скорее всего, принтер обслу- живает несколько веб-страниц, с помощью которых вы можете управлять его аппарат- ными компонентами: принтер запускает свой собственный веб-сервер. Поскольку системные администраторы озабочены вопросами безопасности, вы, воз- можно, уже подумали: “Значит ли это, что принтер можно взломать или подвергнуть атаке на основе отказа в обслуживании?” Увы, да. Вопросы безопасности рассматрива- ются в разделе 26.12. Какая операционная система работает на вашем принтере? Как?! Вы не знаете? Ничего удивительного. Вы, вероятно, не можете найти нужную информацию, даже хо- рошенько покопавшись в документации. Операционные системы принтеров зависят от разработчиков, а иногда даже от модели. Средние и дорогие принтеры могут даже запу- скать операционные системы, производные от UNIX или Linux. Ваш принтер способен выполнять множество протоколов и принимать задания на разных языках, описывающие страницы и документы. Он может даже понимать и рас- печатывать такие форматы, как GIF, JPG и TIFF. Ваш принтер может быть черно-белым или цветным. Он может печатать страни- цы с разрешением от 150 до 2400 точек на дюйм (dpi — dots per inch) и даже страница с асимметричным разрешением, например 1200x600, т.е. 1200 dpi в одном направлении и 600 dpi в другом. Если вы управляете крупной сетью, то вам, вероятно, придется обслуживать несколь- ко моделей принтеров, созданных разными производителями, каждый из которых имеет разные возможности. Это значит, что программное обеспечение для принтеров на ваших компьютерах должно справляться с разнообразным (и часто неизвестным) аппаратный обеспечением с помощью набора протоколов. 26.7. Основные программы печати Печать — это не только буферизация и задания на печать. Даже на системе Ubuntu (которая использует систему печати CUPS) команда $ man -к . | egrep -i ’ ghostscript | cups | print (er | ing | * (job | queue | filter)) ’ отображает более сотни страниц из руководства, посвященных проблемам печати, — и это при поиске “на скорую руку”. (Кстати, изучая связанные с печатью команды, об* ратите внимание на то, что не все команды имеют отношение к печати. Например, apcupsd — это демон, который взаимодействует с устройством Universal Power Supplies, разработанным компанией АРС, и даже команда print не имеет никакого отношения £ печати.) О некоторых из этих команд и утилит стоит знать. В системах BSD и System V недостает многих функций, связанных с преобразования- ми форматов, необходимыми для управления современными принтерами. По этой при- чине многие разработчики, использующие эти системы, имеют хотя бы один набор ин- струментов, реализованных на основе их систем печати, для выполнения этих функций.
Глава 26. Печать 1111 Иногда эти инструменты включаются в операционную систему, но чаще они продаются как надстройки. Широко используются также свободно распространяемые пакеты, раз- работанные сторонними производителями. Утилита рг — это один из самых старых инструментов для печати. Она изменяет формат текстовых файлов так, чтобы он соответствовал формату печатной страницы. В частности, она разбивает содержащиеся в них данные на включающие по 66 строк страницы, добавляет верхние и нижние колонтитулы и, при необходимости, делает меж- ду строками двойной интервал. (Почему 66? Потому что именно столько строк помеща- лось на странице, которая распечатывалась старыми построчными принтерами.) Команда enscript, разработанная компанией Adobe, выполняет похожие преобра- зования с несколькими дополнительными “наворотами”; она тоже выводит данные в формате PostScript. Команда enscript, разработанная в рамках проекта GNU, пред- ставляет собой распространяемую с открытым исходным кодом версию этой коман- ды и имеет обратную совместимость с аналогичной командой Adobe; однако команда enscript предлагает ряд новых функциональных возможностей, в частности, чувстви- тельное к языку выделение, поддержка для различных форматов (размеров бумаги), за- грузка шрифтов и определяемые пользователем заголовки. Одним из главных преимуществ команды enscript была реализация возможности печати сразу двух страниц на одном листе (2-up printing). Те, кто до сих пор пользуется командой enscript из-за этой возможности, могут попробовать применить в системе CUPS команду 1рг -о number-up=2. Одной из самых сложных считается утилита Ghostscript, которую первоначально соз- дал Л. Питер Дойч (L. Peter Deutsch) для того, чтобы иметь возможность печатать до- кументы PostScript на недорогих принтерах PCL. Сегодня программа Ghostscript интер- претирует не только формат PostScript, но и формат PDF. Система CUPS использует ее в качестве фильтра, но программа Ghostscript также может создавать изображения стра- ниц для экрана как самостоятельно, так и при помощи внешних программ наподобие gv, GNOME Ghostview (ggv), или KDE KGhostView. Абсолютно все дистрибутивы Linux поставляются с бесплатной версией программы Ghostscript, подробнее о которой можно узнать на сайте ghostscipt. com. Коммерческая версия Ghostscript с поддержкой доступна на сайте компании Artifex Software. 26.8. Языки принтеров Задание на печать — это на самом деле компьютерная программа, написанная на специальном языке программирования. Они называются языками описания страниц или просто PDL-языками (PDL — Page Description Language). Страницы, кодируемые на языке PDL, могут быть гораздо меньше по размеру (ино- гда больше) и передаваться гораздо быстрее аналогичных необработанных изображений. Кроме того, PDL-описания также могут не зависеть ни от используемых устройств, ни от их разрешающей способности. Наиболее известными PDL-языками на сегодняшний день являются PostScript, PCL5, PCL6 (также называемый “PCL/XL” или “pxl”) и PDF. Многие принтеры спо- собны принимать входные данные на более чем одном языке. Каждый из этих языков кратко описывается в следующих разделах. Принтеры должны интерпретировать задания на этих языках и преобразовывать их в какой-нибудь понятный для используемого устройства обработки изображений формат. Поэтому принтеры содержат языковые интерпретаторы. Точно так же как и у языка С
1112 Часть III. Разное или Java, у этих языков имеется множество версий, и каждая из них работает по-своему. Почти все принтеры PostScript понимают PostScript Level 3, но если вы отправите про- грамму Level 3 на принтер, который понимает только Level 2, принтер, скорее всего, не сможет ее выполнить. Процесс преобразования PDL-описания (или, например, графических файлов) в растровые изображения страниц называется обработкой растровых изображений, а про- грамма, которая выполняет его, — процессором растровых изображений (Raster Image Processor) или просто RIP. Задания на печать можно копировать на компьютер и просматривать на экра- не. Централизованные интерпретаторы, которые позволяют это делать, такие как Ghostscript, описываются в разделе 26.11. В теории можно даже делать следующее: ко- пировать задания на компьютер и затем отправлять готовые (и значительно большие по размеру) растровые изображения на печать какому-нибудь “не очень разумному” устрой- ству печати. На самом деле именно так и работают многие принтеры GDI (Windows), да и в системе Linux этот подход тоже поддерживается до некоторой степени. PostScript Это самый распространенный из всех встречающихся на системах Linux языков семейства PDL. Первоначально PostScript был разработан компанией Adobe Systems, и многие принтеры до сих пор используют интерпретатор, требующий наличия лицен- зии от Adobe. Почти все программы компоновки страниц умеют генерировать данные на языке PostScript, а некоторые вообще работают только с такими данными. PostScript — этот полнофункциональный язык программирования. Почти все напи- санные на нем программы могут просматриваться с помощью текстового редактора или утилиты less. Эти программы отличаются обилием круглых и фигурных скобок, а также символов косой черты и часто начинаются символами %! PS. Хотя эти начальные сим- волы не являются обязательными в самом языке PostScript, PostScript-интерпретаторы и другие программы для печати часто ищут их, пытаясь распознать и классифицировать задания на печать. PCL Одной из альтернатив языка PostScript является разработанный компанией Hewlett- Packard язык PCL (Printer Control Language — язык управления принтерами). Его пони- мают не только принтеры производства Hewlett-Packard, но и принтеры многих других производителей; некоторые принтеры вообще умеют работать только с ним. В отличие от PostScript, который поддерживает все операции Тьюринга и является универсальным языком программирования, PCL просто сообщает принтерам, как им следует печатать страницы. Написанные на PCL задания на печать имеют бинарный, не доступный для понимания человека формат и обычно намного короче аналогичных заданий, написан- ных на языке PostScript. Приложения Linux редко генерируют выходные данные на язы- ке PCL напрямую, но фильтры могут преобразовывать PostScript в PCL. В отличие от языка PostScript, версии языка PCL разнятся лишь немного. Отличия небольшие, но достаточно значительные для того, чтобы вызвать раздражение. Задания, которые печатаются правильно на LaserJet 5si, могут печататься немного не так на LaserJet 5500 и наоборот. И это касается не только этой пары моделей; каждый PCL- принтер имеет свой диалект языка PCL со своими специальными командами, которые извлекают пользу из функциональных возможностей именно этого принтера.
Глава 26. Печать 1113 Например, если указать компьютеру, что используется принтер LaserJet 4500, ког- да на самом деле используется принтер LaserJet 4550, он может сгенерировать какие- нибудь PCL-команды, которые принтер LaserJet 4550 проигнорирует или неправильно интерпретирует. Также, если имеется какое-нибудь сохраненное, написанное на языке PCL задание на печать (скажем, чистый бланк на оформление покупки), а принтер, для которого оно было сгенерировано, заменяется на какой-нибудь более новый, не исклю- чено, что это задание придется генерировать заново. Еще хуже то, что компания HP (Hewlett-Packard) определила два совершенно не свя- занных между собой семейства языков — PCL5 (PLC5C означает “цветной”, PLC5E — “черно-белый”) и PCL6 (второе название — “PCL/XL”). Сегодня новые принтеры HP обычно имеют языковые интерпретаторы для обоих. PDF Разработанный компанией Adobe формат PDF (Portable Document Format — формат переносимых документов) генерируется программой Adobe Acrobat, а многие другие на- стольные средства для издательского дела, такие как OpenOffice, позволяют экспортиро- вать документы в этом формате. PDF-документы не зависят от платформы. Формат PDF очень часто используется для обмена электронными документами с возможностью последующего просмотра и пе- чати. Окончательный вариант текста данной книги, например, передавался на принтер именно в виде PDF-файла. PDF — это язык описания документов, а не просто язык описания страниц. Он по- зволяет описывать не только отдельные страницы, но и общую структуру документа: к каким главам относятся те или иные страницы, какие текстовые столбцы переходят в другие текстовые столбцы и т.д. Он также предлагает ряд различных мультимедийных возможностей для использования на экране. Некоторые принтеры интерпретируют PDF напрямую. Если ваш этого не делает, су- ществует масса программ-трансляторов и программ для просмотра PDF-файлов (среди них Ghostview, xpdf, kpdf, Evince и Acrobat Reader), которые позволяют преобразовать документы в какой-нибудь более универсальный формат (такой, как PostScript например). Ваша система печати может даже скрывать требование на выполнение преобразования от вас и автоматически преобразовывать PDF-документы перед их отправкой на принтер. XPS Стоит также упомянуть язык Paper Specification, разработанный компанией Microsoft. Он также называется XPS или OpenXPS. Этот язык не получил широкого распростране- ния даже в системах Windows. Системы UNIX и Linux слабо поддерживают этот язык, хотя компания Artifex уже создала интерпретатор языка XPS. Дистрибутивные пакеты системы Linux, несомненно, вскоре включат поддержку языка XPS, если он станет по- пулярным. Зачем это может быть нужно пользователям? Представьте, что вы — начальник от- дела маркетинга, просматривая веб-страницы на своем телефоне, вдруг обнаруживаете среди них одну, очень подходящую к теме вашей презентации, которую вы как раз соби- раетесь провести. Вы подходите к ближайшему поддерживающему Bluetooth принтеру и отправляете ему со своего телефона URL-адрес этой страницы. Дальше принтер делает все сам: загружает страницу из Интернета, визуализирует ее и печатает копии. Вы берете копии из лотка и спокойно направляетесь на свою презентацию.
1114 Часть III. Разное PJL PJL (Printer Job Language — язык заданий принтеров; разработан компанией Hewlett- Packard) — это не PDL-язык, а метаязык, который описывает задания принтеров. Мы рассказываем о нем здесь потому, что он будет встречаться в описаниях принтеров. Итак, PJL — это язык управления заданиями, который позволяет указывать, какой PDL-язык должен использоваться для задания, это задание типа дуплекс или симплекс, какой размер бумаги следует использовать и т.д. PJL-команды идут в начале задания, а PJL-операторы все начинаются с символов @PJL. @PJL SET COPIES=3 @PJL COMMENT FOO BAR MUMBLE @PJL SET DUPLEX=ON @PJL SET PAGEPROTECT=OFF @PJL ENTER LANGUAGE=PCL PJL обычно нормально распознается (или преднамеренно игнорируется) принтерами стороннего производства (не Hewlett-Packard), но в случае проблем при распечатке та- кого документа на стороннем принтере попробуйте удалить PJL при помощи текстового редактора и снова отправить задание на печать. Драйверы принтеров и как они обрабатывают PDL-языки А что если принтер поддерживает только некоторые из нужных языков? Что делать, если из Интернета загружен файл PostScript, а имеющийся принтер распознает только PCL5E? Как распечатать PDF-файл, если принтер не интерпретирует PDF напрямую? Один из вариантов — это преобразовать файл вручную. Дистрибутивы Linux постав- ляются со множеством утилит преобразования; практически всегда есть какой-нибудь способ превратить имеющийся документ в документ, который может быть распечатан на принтере. Браузеры, например, позволяют преобразовывать страницы HTML (или XHTML) в PostScript. OpenOffice позволяет преобразовывать файлы MS Word в формат PDF. Ghostscript позволяет преобразовывать PDF-файлы в формат PostScript, а уже из формата PostScript — в почти любой другой формат, включая PCL. Более простой вариант — позволить системе печати сделать все самой. Многие си- стемы имеют встроенные знания о том, какие преобразования должны выполняться, и могут выполнять их автоматически. Если необходимо определить, какой PDL-язык используется в файле, и сделать это по имени файла (например, food.pdf) невозможно, воспользуйтесь командой file (если только файл не начинается с ряда PJL-инструкций, потому что в таком случае ко- манда file вернет просто такое сообщение: “HP Printer Job Language data”, т.е. “данные на языке заданий принтеров”). Сохраните несколько заданий на печать в файлах, вместо того чтобы отправлять их на принтер, и увидите, как выглядит программа на одном из этих языков. Изучив файлы каждого из этих типов минуту или две в своем текстовом редакторе, вы поймете, на- сколько они разные. (Не выводите их прямо на экран при помощи команды cat, по- тому что только PostScript отображается в формате ASCII. Случайные бинарные данные только запутывают интерпретаторов терминалов.) PostScript % IPS-Adobe-3.О %%BoundingBox: 0 0 612 792 %%Pages: 1
Глава 26. Печать 1115 % ... % Draw a line around the polygons... pop pop pop dup 0 setgray 0 0 moveto dup 0 lineto 0.707106781 mul dup lineto closepath stroke PDF %PDF-1.3 %A.A.AA" 81 0 obj /Linearized 1 /0 83 /Н [ 915 494 ] /Т 125075 endobj xref 81 24 0000000016 00000 n A€<8f> ЛРЛ@АпА'<9е> endstream endobj PCL5 л[EA[&llo0olt016DA[&11XA[*r0FA[*v0nlOA[*p4300XA[%1BDT~,1TR0TD1SP1FT10,50 CF3,1LB.~;A[%1AA[*cl00GA[*v2TA[&a0PA[*p0XA[*p0YA[(10UA[(slpl2vsb4148TA[&10 EA[*p0YA[*ct7920YA[(10UA[(slpl2vsb4101TA[&a0PA[&10o66f0EA[9A[&a0PA[*p0XA[* p0YA[*p474YA[*pl41XA[(10UA[(10UA[(slpl2vsb4101TA[*p402YA[*pl86XA[*vOOA[*c9 00a4bl00g2PA[*vlOA[*p250YA[*vOOA[*c900a4bl00g2PA[*vlOA[*vOOA[*c4al56bl00g2 PA[*vlOA[*p251YA[*pl87XA[*vOOA[*c899al54bl0g2PA[*vlOA[*p346YA[*p256X PCL/XL A'XABXABA.<89>AA@A.<86>AACA.<8f>AAA@A.<88>AAAA.<82>HAA@A.(AA@A.%A A. cAAAPA OTimesNewRmnBdA. A. A...UUAOBA. A! Au ABA. A. o<8 5>A"A > ACAABA. Lk AA@A@A.A.dA€A:A@ 26.9. Файлы PPD При вызове демона Ipr для распечатки файла book.ps на цветном принтере Pollux, он может спросить, бумага какого размера должна использоваться для печати. Но подо- ждите, откуда система CUPS знает, что ей нужно указать своему клиенту, демону 1рг, что принтер Pollux может выполнять печать на бумаге размера А4? Откуда система CUPS знает, что он понимает язык PostScript, и что ей делать, если это не так? Где система CUPS находит информацию о том, что Pollux является цветным принтером? Если вы используете систему CUPS, то вся эта информация содержится в файле PPD (PostScript Printer Description — файл описания принтера на языке PostScript), который описывает атрибуты и возможности принтера, поддерживающего язык PostScript. Демон CUPS считывает PPD-файлы обслуживаемых им принтеров и передает информацию о них клиентам и, если необходимо, фильтрам. Файлы PPD изначально разрабатывались для мира Мас, но были быстро переняты системой Windows. Каждый новый принтер поставляется с файлом PPD от производи- теля. Драйверы принтеров Мас и Windows используют файл PPD для выяснения того,
1116 Часть III. Разное как отправлять на принтер задания на языке PostScript. Например, нет никакого смысла просить поддерживающий только одностороннюю печать черно-белый принтер, прода- ваемый в Америке, распечатать двухсторонний цветной документ на европейской бума- ге формата В4. Каждый принтер, поддерживающий язык PostScript, имеет свой собственный файл PPD, хотя его нелегко найти. Проверьте инсталляционный диск и веб-сайт разработчика. Файлы PPD — это просто текстовые файлы. Откройте один из них в текстовом ре- дакторе и посмотрите, какая информация в нем содержится. В сети файл PPD может быть даже удаленным, а пользователи системы CUPS могут получить информацию на соответствующем сервере CUPS. Система CUPS также использует файлы PPD для описания принтеров, у которых нет интерпретатора PostScript. Весь трюк заключается в одном дополнительном поле. $ grep cupsFilter /usг/share/cups/mode 1/pxlmono.ppd *cupsFilter: "application/vnd.cups-postscript 100 pstopxl" *cupsFilter: "application/vnd.cups-pdf 0 pstopxl" Для того чтобы увидеть, чем именно отличаются два типа принтеров, можно срав- нить два связанных друг с другом файла PPD (например, файл pxlmono .ppd и файл pxlcolor .ppd) при помощи команды diff. Если производитель принтера не предоставляет файл PPD — возможно, потому, что у принтера нет интерпретатора PostScript и производителя не волнует ничего, кроме си- стемы Windows, — следует зайти на сайт linuxprinting. org и поискать информацию в базе данных Foomatic. Не исключено, что принтер поддерживается проектом Gutenprint (gutenprint. sourceforge. net). Если доступны несколько или все перечисленные источники файлов PPD и пользователи хотят наилучшего возможного качества, нужно попробовать источник с пометкой “footmatic+gutenprint”. Если отыскать PPD-файл нигде не удается, тогда примите следующие советы. • Вероятно, следовало проверить принтер по базе данных на linuxprinting. org, прежде чем приобретать его. Даже если вы получили принтер по цене металлоло- ма, “свободно распространяемый” не всегда означает “бесплатный”. • Вполне вероятно, что существует какой-нибудь файл PPD, который позволит выполнять печать, хотя и не будет пользоваться преимуществами всех функцио- нальных возможностей принтера. Например, нам удалось использовать типичные драйверы HP на принтерах других компаний. Несмотря на то что система CUPS зависит от файлов PDS, старые системы печати не используют их. Для систем BSD и System V вы можете либо сами настроить механизм PostScript, либо смириться с тем, что получаете по умолчанию. 26.10. Форматы бумаги Пользователи хотят видеть информацию на бумаге. Бумага имеет размер и форму. Для того чтобы пользователи были довольны, следует знать основные факты о форматах бумаги. В США и Канаде самый распространенный формат бумаги Letter размером 8,5x11 дюймов. Некоторые дистрибутивы системы Linux (такие, как пакеты Knopix и SUSE) выпускаются в Европе, где никто даже не знает, что такое дюймы, в Англии знают, что такое дюймы, но не пользуются ими для измерения бумаги. В этих странах и в Японии самый распространенный формат бумаги А4, и все принтеры поставляются с лотками
Глава 26. Печать 1117 размера А4. Поэтому утилиты печати в некоторых дистрибутивах генерируют изображе- ния размером со страницу формата А4 по умолчанию. Лист формата А4 является удобным, потому что он иррационален (с математической точки зрения). Соотношение длины к ширине у листа формата А4 равняется ^2. Если сложить лист А4 пополам горизонтально, получится два листа с одинаковым соотноше- нием длины к ширине. Такой формат листа уже называется А5. Если сложить пополам лист формата А5, получится два листа формата А6. Если пойти в обратном направлении, лист формата АЗ будет по площади в два раза больше листа формата А4, но точно такой же формы, и т.д. Другими словами, можно изготавливать листы формата АО, которые по площади рав- няются одному квадратному метру, и при помощи бумагорезальной машины создавать из них листы необходимых размеров. Единственным распространенным в США форма- том бумаги, с которым можно проворачивать подобное, является формат Ledger (11x17 дюймов, также известный как “таблоид”): если сложить лист такого формата пополам, получится два листа формата Letter. Также еще существуют ISO-форматы серий В и С, которые сохраняют пропор- цию 1:^2, но имеют другую базовую площадь. Формат ВО составляет 1 метр в высоту, а СО имеет площадь 2 м2. Инженеры сразу же увидят, что стороны листа Вл представляют собой среднее геометрическое сторон Ал-7 и Ал, а стороны листа Сл — среднее геоме- трическое сторон Ал и Вл. Что это все означает? Формат Вл выглядит точно так же, как Ал, но он больше, а формат Сл представляет собой нечто среднее между ними двумя. Отчет на листе форма- та А4 прекрасно поместится в папку формата С4. Если сложить пополам письмо форма- та А4, оно превратится в письмо формата А5, которое легко войдет в конверт формата С5. А если его сложить еще раз, оно также легко войдет и в конверт формата С6. Немного усложняет дело то, что в Японии имеется своя серия форматов В, которые немного отличаются. Хоть они и имеют те же пропорции, что и ISO-листы, японский формат В4 представляет собой среднее арифметическое форматов АЗ и А4, что делает его немного больше ISO-формата В4. Японских форматов серии С не существует. Система ISO позволяет копировать две страницы формата В5 на одну страницу фор- мата В4, а также печатать сколько угодно уменьшенных изображений страниц на одном листе. На европейских копировальных машинах часто имеются кнопки, позволяющие уменьшать или увеличивать изображение на множитель 7L Если в системе установлена команда paperconf, можно использовать ее и сделать так, чтобы размеры разных известных форматов бумаги отображались в дюймах, санти- метрах или точках (каждая из которых составляет 1/72 дюйма). В табл. 26.7 перечислены некоторые наиболее распространенные случаи использования основных форматов бу- маги (для американцев). Таблица 26.7. Основные ISO-форматы бумаги Форматы "V — :—” Назначение АО, А1 АЗ, В4 А4 А5 В5.В6 А7 Объявления Газеты Универсальные документы Блокноты (примерно 5x8 дюймов) Книги, открытки, немецкая туалетная бумага Учетные карточки “3x5”
1118 Часть III. Разное Окончание табл. 26.7 Форматы ~ ' , ; ~ ,, , . ~ ? В7 Паспорта (даже в США паспорта имеют формат В7) А8 Визитные карточки В8 Игральные карты К сожалению, бумага формата А4 немного тоньше и длиннее (8,3 х 11,7 дюймов) бу- маги американского формата Letter. Печать документа формата А4 на бумаге формата Letter обычно заканчивается обрезанием таких его важных частей, как верхние колон- титулы, нижние колонтитулы и номера страниц. И наоборот, печать документа формата Letter на бумаге формата А4 приводит к усечению его сторон (хотя это и менее важно). Некоторые программные пакеты имеют собственные параметры по умолчанию для формата бумаги. Например, утилита enscript по проекту GNU обслуживается в Фин- ляндии человеком по имени Маркку Росси (Markku Rossi) и по умолчанию использует формат А4. Те, кто проживают в Америке и пользуются дистрибутивом, в котором ути- лита enscript не была скомпилирована с другим параметром по умолчанию, могут сде- лать только одно — взять исходный код и переконфигурировать его. Однако обычно про- ще поступить следующим образом: указать нужный формат бумаги в командной строке или конфигурационном файле GUI. Если документы печатаются с обрезанными конца- ми или сторонами, причиной, скорее всего, является несовместимость форматов бумаги. Иногда можно настроить используемый по умолчанию формат бумаги для мно- гих связанных с печатью задач при помощи команды paperconfig, переменной сре- ды PAPERSIZE или содержимого файла /etc/papersize. (Обратите внимание: paperconfig ! = paperconf.) Следует признать, что информация выводится не только на бумагу. Если в хлебный отдел крупного супермаркета принести цветную фотографию, то, возможно, кулинары смогут сделать для вас торт, на поверхности которого будет ваше изображение. Такие рисунки печатаются на специализированных растровых принтерах, использующих съе- добные чернила. Крупные прямоугольные торты называются “тортами на противне” (“sheet cake”) и тоже имеют стандартные размеры. К сожалению, мы вынуждены закон- чить наш разговор о форматах бумаги. Мы не можем говорить обо всем на свете ... 26.11. Практические советы Принтеры могут стать причиной беспокойства. Для того чтобы смягчить это бес- покойство, мы решили сформулировать несколько советов. Если все остальные устрой- ства отказали, радуйтесь тому, что вы, по крайней мере, не обязаны до сих пор возиться с игольчатыми принтерами, подсоединенными через последовательный порт RS-232. (Если это так, конечно.) Выбор принтера Если вы используете систему CUPS, то прежде чем покупать принтер или брать “бесплатный” принтер, который кто-то выкидывает, следует заглянуть в базу данных Foomatic на сайте linuxprinting.org (которая поддерживается и финансируется орга- низацией Linux Foundation) и проверить, насколько хорошо он поддерживается в систе- ме Linux. В этой базе данных все принтеры поделены на четыре категории, начиная от категории Paperweight (Пресс-папье) и заканчивая категорией Perfectly (Отлично); нам нужна категория категорию Perfectly.
Глава 26. Печать 1119 Все предпочитают принтеры со встроенным интерпретатором языка PostScript. Эти принтеры обычно имеют простую конфигурацию. Принтеры, не понимающие язык PostScript, тоже поддерживаются, но не так хоро- шо. Для того чтобы выполнять печать на этих принтерах, потребуется специальное про- граммное обеспечение, умеющее преобразовывать задания на печать в предпочитаемый принтером формат PDL или другой формат данных. Не исключено, что такое программ- ное обеспечение удастся найти в пакете CUPS или в одном из других упоминавшихся ранее в этой главе источников. Впрочем, система CUPS поддерживает все эти принтеры очень хорошо. Если вы не используете систему CUPS и работаете с принтером, поддерживающим язык PostScript, то вы, вероятно, в хорошей форме. Если вы работаете с принтером, не по- нимающим язык PostScript, попробуйте использовать программу Ghostscript, чтобы пре- образовать документы на языках Postscript и PDF в нечто понятное для вашего принтера. GDI-принтеры Система Windows по-прежнему имеет два преимущества, одним из которых являет- ся ее поддержка очень старых и дешевых принтеров. Дешевые принтеры, используемые на системах Windows, называются GDI-принтерами или WinPrinter. Такие принтеры об- ладают очень незначительным количеством встроенных логических возможностей и не имеют никаких интерпретаторов для языка PDL. Они ожидают, что растеризация будет выполняться на обслуживающем их компьютере. Часть информации, необходимой для взаимодействия с GDI-принтерами, скрыта в специальном, запатентованном коде Windows. Такая секретность затрудняет разработку поддержки для таких устройств в системе Linux, но сообщество сторонников программ- ного обеспечения с открытым кодом продемонстрировало удивительную способность к воспроизведению структурной схемы и алгоритма работы. Система CUPS поддержи- вает многие принтеры WinPrinter. Вторым преимуществом системы Windows является ее поддержка новейших принте- ров. Точно так же как новые видео- и аудиокарты, новые принтеры сначала выпускаются с драйверами для системы Windows, которые полностью поддерживают все задокумен- тированные и не задокументированные функциональные возможности данной модели. Драйверы для системы Linux обычно выходят с некоторым опозданием. В случае по- купки нового модного принтера с расширенными возможностями, не исключено, что некоторое время им можно будет пользоваться только из Windows. Старые системы UNIX, которые обычно не поддерживают систему CUPS, име- ют с этими принтерами еще больше проблем. Если вы хотите использовать принтер WinPrinter в старой системе UNIX, лучше купите недорогие дистрибутивы систем Мас, Linux или Windows. Вы всегда можете совместно использовать принтер в сети. Двусторонняя печать Дуплексор — это компонент аппаратного обеспечения, который позволяет принте- ру выполнять печать на обеих сторонах страницы. У некоторых принтеров он входит в комплектацию, а у некоторых идет как дополнение. Это удобно, потому что экономит и бумагу, и место. Если у вас нет принтера с возможностью двусторонней печати или желания его ку- пить, можно поступить следующим образом: распечатать на листах бумаги сначала только нечетные страницы, а затем перевернуть листы и распечатать только четные страницы.
1120 Часть III. Разное Однако сначала следует поэкспериментировать с двусторонним документом, чтобы уз- нать, как нужно правильно переворачивать листы бумаги, и только потом давать соот- ветствующие инструкции принтеру. Многие программы печати могут помочь с этим процессом; например, в программе Ghostview (gv) есть пиктограммы, позволяющие отмечать подлежащие печати страницы (четные или нечетные), и опция, позволяющая распечатывать только отмеченные стра- ницы. Версии команд 1р и 1рг в системе CUPS позволяют делать то же самое при по- мощи опций -о page-set=odd и -о page-set=even. В случае частого использования эти опции можно сохранить в “экземпляре принтера” (см. раздел 26.2). Некоторые, особенно недорогие лазерные принтеры разрабатывались без возмож- ности двусторонней печати. Их производители часто предупреждают о непоправимом ущербе, которым может закончиться для принтера печать на обеих сторонах страницы. Мы никогда не слыхали о том, что такой ущерб действительно имел место, но вряд ли производители стали бы предупреждать нас о нем просто так. Не так ли? Другие аксессуары для принтера Помимо дуплексоров, многие принтеры позволяют добавлять память, дополнитель- ные лотки для бумаги, жесткие диски и другие аксессуары. Эти дополнительные компо- ненты могут давать возможность распечатывать задания, печать которых в противном случае была бы невозможна, или просто печатать задания более эффективно. При на- личии проблем с отправкой заданий на печать следует просмотреть журналы ошибок и выяснить, не поможет ли справиться с этой проблемой увеличение памяти. О журналах ошибок подробнее рассказывается в разделе 26.12. Принтеры с последовательным и параллельным интерфейсом Если принтер подключается прямо к компьютеру через кабель, значит, он использует для соединения либо последовательный, либо параллельный порт. Несмотря на то что стандарт параллельных интерфейсов немного устарел, он все- таки подразумевает использование портов, конфигурирование которых требует мини- мальных усилий. Те, кто приобрел принтер с параллельным интерфейсом, скорее всего, смогут установить его без проблем — конечно, если у них на компьютере предусмотрен параллельный порт. Последовательным портом на оборудовании Мас может служить порт FireWire, но в мире Linux в роли такого порта обычно выступает порт USB. Узнать больше об этом можно, заглянув в базу данных о поддерживаемых USB-устройствах на сайте linuxprinting.org. Вероятность приобретения давно устаревшего принтера, подключаемого через после- довательный порт RS-232, очень низка. Но если такое все-таки случилось, чтобы скон- фигурировать его, скорее всего, придется приложить массу дополнительных усилий. Для того чтобы очередь печати могла нормально работать с принтером, ей необходимо знать скорость двоичной передачи (baud rate) и другие требующиеся для взаимодействия через последовательный порт параметры. Указать все эти параметры можно только в иденти- фикаторе устройства URL (Этот процесс подробно описан в руководстве CUPS Software Administrators Manual, размещенном в Интернете.) Пожалуй, легче будет купить другой принтер, чем вычислять точно все параметры, требующиеся для того, чтобы заставить работать данный принтер с последовательным интерфейсом.
Глава 26. Печать 1121 Сетевые принтеры Многие принтеры имеют полнофункциональные сетевые интерфейсы, которые по- зволяют им находиться прямо в сети и принимать задания через одну и более сетей или протоколов печати. На принтеры, подключенные к сети, данные могут отправляться го- раздо быстрее, чем на принтеры, подключенные к последовательному или параллельно- му порту. Лазерные принтеры обычно используются как сетевые. Струйные принтеры реже используются в таком качестве. Если вы хотите узнать, есть ли в вашем распоряжении сетевой принтер, загляните в порт Ethernet или посмотрите на беспроводную антенну на задней панели. Другие советы Некоторые проблемы администрирования не связаны с устройством системы печати. Большей частью они возникают из-за того, что принтеры представляют собой ненадеж- ные механические устройства, которые порождают затраты при каждом их использова- нии. Используйте титульные и завершающие страницы только в случае необходимости Система печати может предварять каждое задание страницей с названием задания и сведениями о том, кто направил его на печать (header page), а также дополнять задание завершающей страницей (trailer page). Такие страницы могут оказаться полезными при организации совместной печати на одном принтере, хотя, в основном, это пустая трата времени и бумаги. Если титульные и завершающие страницы не нужны, запретите их печать в системе BSD, установив булеву переменную sh. В системе System V не используйте сценарий, генерирующий такие страницы. В системе CUPS можно вообще отключить печать титульных и завершающих стра- ниц с помощью графического пользовательского интерфейса или утилиты Ipadmin, а затем включить ее для отдельных заданий. $ Ipr -о -job-sheets=confidential gilly.ps Система CUPS позволяет включать печать титульных страниц для отдельных пользо- вателей с помощью утилиты Ipoptions. Можно также создать экземпляр принтера, ко- торый будет добавлять титульные страницы в задание (см. раздел 26.2). Система CUPS также позволяет создавать индивидуальную заголовочную страницу, копируя ее из ка- талога /usr/share/cups/banners и модифицируя. Сохраните новую страницу среди остальных, присвоив ей новое имя. "Распушивайте" листы Принтеры загружают бумагу по одному листу из лотка за один раз. Иногда листы склеиваются, и принтер втягивает два и даже больше листов. Вероятность этой непри- ятности можно снизить, просто “распушив” стопку бумаги перед тем, как ее загрузить. Держа стопку бумаги за один конец, согните ее и проведите большим пальцем поперек среза, как будто вы тасуете игральные карты. Это просто, бесплатно и полезно. Некоторые струйные принтеры реагируют на то, как листы положены в лоток. В их настройках должна быть указана предпочтительная ориентация.
1122 Часть III. Разное Обеспечьте утилизацию отходов Все виды компьютерной бумаги пригодны к переработке. Коробки, в которых по- ставляется бумага, могут быть использованы в качестве контейнеров для ненужных ли- стов. Пометьте коробки, чтобы в них не сбрасывали посторонние предметы (скрепки, скобы скоросшивателей, газеты). Выполняйте предварительный просмотр Часто после распечатки документа обнаруживается незначительная ошибка в форма- тировании — и приходится все перепечатывать. Ненужного расхода бумаги можно из- бежать, если инсталлировать специальные программы, позволяющие увидеть готовый к печати документ на экране монитора. Просто иметь средства предварительного просмотра недостаточно. Ваши пользовате- ли должны уметь их применять. Впрочем, иногда они не хотят этому учиться. Для того чтобы стимулировать их к этому, введите учет, чтобы выяснить, сколько раз перепечаты- вался один и тот же документ. Это сразу позволит выявить пользователя, который пре- небрегает предварительным просмотром. Средства для предварительного просмотра встроены во многие современные редакто- ры WYSIWYG, браузеры и системы печати. Для документов другого типа следует исполь- зовать иные возможности. Например, для просмотра документов в форматах PostScripr и PDF можно использовать программу Ghostview (gv). Для системы rof f направляй- те вывод в программу Ghostview, а для языка ТеХ применяйте утилиты xdvi, kdvi или Evince. Покупайте дешевые принтеры Современный уровень технологий печати довольно высокий, поэтому на высокопро- изводительные устройства с надежной механикой не приходится тратить много средств. Не гоняйтесь за дорогими принтерами “для рабочих групп”, если в этом нет острой необходимости. Разницы в качестве печати никакой, а по производительности и надеж- ности “персональный” принтер среднего уровня во многих случаях ничуть не уступает принтеру старшей модели, не говоря уже о том, что он на несколько килограммов лег- че. Принтера со скоростью печати 10 страниц в минуту более чем достаточно для пяти штатных клерков или редакторов, так что для группы из 25 сотрудников выгоднее ку- пить пять принтеров за 150 долл., чем один — за 750 долл. Даже если вы предпочитаете продукцию ведущих компаний, помните, что ни один производитель не является совершенным. У нас был отличный опыт эксплуатации принтеров HP. Это надежные устройства, и компания HP очень агрессивно поддер- живает их работу в системах Linux и CUPS. И тем не менее некоторые принтеры HP оказались просто катастрофой. Прежде чем совершать покупку, проконсультируйтесь в Интернете. При этом следует главным преимуществом считать дешевизну: ошибку стои- мостью 150 долл, пережить легче, чем ошибку стоимостью 750 долл. Держите под рукой запасной картридж Бледные или белые области на странице, напечатанной на лазерном принтере, озна- чают, что в картридже заканчивается тонер. Купите запасной картридж заранее. В труд- ную минуту можно просто вынуть картридж из принтера и аккуратно потрясти, чтобы перераспределить оставшийся тонер. Этого часто оказывается достаточно, чтобы напе- чатать еще несколько сотен страниц.
Глава 26. Печать 1123 Полосы и пятна, вероятно, свидетельствуют о том, что вы должны почистить прин- тер. Проверьте, есть ли у принтера “режим очистки”. Если нет или это не помогло, про- читайте инструкции производителя. Большинство картриджей имеет барабан, поэтому попытайтесь поменять картриджи, чтобы узнать, в чем проблема: в принтере или кар- тридже? Если и после этого полосы не исчезнут, отправляйтесь в сервисный центр. Производители принтеров пытаются предотвратить повторное использование вос- становленных картриджей и картриджей со вторичного рынка. Для этого они предпри- нимают разные меры. Многие устройства используют “именные” расходные материа- лы, которые распознаются принтером электронным или физическим способом. Даже если два принтера выглядят одинаковыми, например Xerox Phaser 6120 и Konica-Minolta Magicolor 2450, это не значит, что один и тот же картридж можно использовать на обоих принтерах. Иногда приходится разбирать принтер, чтобы приспособить картридж одного произ- водителя к принтеру другого производителя. Обычно это сопровождается “разведением грязи”. Если вы просыпали тонер, втяните его пылесосом как можно быстрее и вымойте это место холодной водой. Вопреки расхожему мнению, тонер лазерного принтера не токсичен, но он состоит из очень мелких частиц и его не следует вдыхать. Заменив картридж, сохраните коробку и чехол от нового картриджа, чтобы отчитать- ся. Затем найдите компанию, которая заберет у вас старый картридж. Использование “именных” расходных материалов стимулировало быстрый рост ком- паний (“открывай и насыпай”), заново наполняющих старые картриджи за долю цены нового картриджа. Компании, восстанавливающие картриджи, также используют прин- цип “открывай и насыпай”, поэтому вы можете восстановить старый картридж и одно- временно заменить его. Мнения о качестве и сроках службы восстановленных картриджей сильно разнятся. Одна из компаний, известных нам, не желает восстанавливать цветные картриджи или продавать их аналоги, потому что, по их мнению, экономия в этом случае будет меньше, чем стоимость обслуживания принтеров, использующих восстановленные картриджи. Помните о стоимости печати одной страницы Самые дешевые принтеры продаются по цене их производства. Производители по- лучают прибыль за счет непропорционально дорогих расходных материалов. На момент написания книги поиск “на скорую руку” выявил, что компания Amazon продает лазер- ный принтер за 80 долл., а картридж к нему — за 65 долл. Вы можете купить дешевый струйный принтер в магазине Wall-Mart за 50 долл., но вскоре вы будете вынуждены ку- пить набор запасных картриджей, который стоит больше принтера.2 Эмпирическое правило гласит: струйный принтер является дешевым, пока вы на нем не печатаете. Лазерный принтер имеет более высокую начальную цену, но его расходные материалы дешевле и служат дольше. Полноцветная страница, напечатанная на струй- ном принтере, может стоить в 20—50 раз дороже, чем аналогичная страница, напечатан- ная на лазерном принтере. Кроме того, для струйного принтера требуется специальная бумага, и он работает медленнее, чем лазерный. Чернильные картриджи быстро опусто- шаются и часто выходят из строя. Чернила часто расплываются, поэтому не используйте струйный принтер для печати кулинарной книги, которая будет использоваться на кух- не. С другой стороны, на струйном принтере теперь можно распечатывать фотографии, 2 Впрочем, помните, что многие недорогие принтеры поставляются с “родным” картриджем, который стоит меньше, чем запасной картридж.
1124 Часть III. Разное качество которых не уступает специальной фотолаборатории. Лазерные цветные фото- графии? Довольно хороши, но сравнивать их нельзя. Все принтеры имеют уязвимые механические детали. Дешевые принтеры ломаются быстрее. Иначе говоря, все эти моменты являются предметом компромиссов. Если вы приоб- ретаете принтер для персональных нужд и будете использовать его не очень интенсив- но, например распечатывать веб-страницу один-два раза в день или несколько катушек с фотопленкой раз в месяц, то дешевый универсальный струйный принтер — прекрас- ный выбор. Следующий раз, когда вы отправитесь покупать принтер, оцените, как долго, на- сколько интенсивно и для каких целей вы будете его использовать. Вычислите долго- срочную стоимость печати одной страницы для каждого принтера, который вы хотели бы купить. Спросите местную компанию, заправляющую картриджи, восстанавливает ли она картриджи для данного принтера и по какой цене. Организуйте учет использования принтера Учет использования принтера даст вам четкое представление о затраченных ресурсах. В сетях среднего и большого размера рассматривайте как вариант организацию учета ресурсов принтера, даже если вы не собираетесь взимать плату за печать. На скорость печати заданий это почти никак не влияет, зато позволяет в любой момент выяснить, кто и как часто пользуется принтером. Информация об источниках заданий на печать очень полезна при выборе мест для установки новых принтеров. Защищайте принтеры Большинство современных сетевых принтеров допускает дистанционное управле- ние в том или ином виде. Даже если вы не используете систему CUPS и пароль IPP, возможность такого управления очень удобна для системных администраторов, так каК они могут выполнять конфигурирование с помощью веб-браузера через протокол HTTP, или, возможно, SNMP. С помощью удаленного интерфейса администратор может задать по сети IP-адрес принтера, стандартный шлюз, сервер Syslog, групповое имя (пароль^ SNMP, параметры протокола и, что самое важное, пароль доступа. По умолчанию большинство принтеров, допускающих дистанционное администри- рование, не защищено, и пароль для доступа к ним следует задавать в процессе инстал- ляции (или строку имени и пароля в протоколе SNMP). Прочтите руководство по ин- сталляции, предоставленное производителем принтера, чтобы узнать, как это сделать в вашем конкретном случае. Графические средства администрирования, такие как интерфейс браузера CUPS, все чаще скрывают от пользователя варианты разработчиков. Ожидается, что эта тенденция будет продолжаться. 26.12. Советы по выявлению проблем Принтеры сочетают все слабости механического устройства со странностями внеш- ней операционной системы. Они (и программное обеспечение, которое ими управляет) обожают создавать проблемы для вас и ваших пользователей. Рассмотрим несколько со- ветов по борьбе с враждебными принтерами.
Глава 26. Печать 1125 Повторный запуск демона печати Никогда не следует забывать перезапускать демоны после внесения изменений в конфигурационный файл. Перезапустить демона cupsd можно любым способом, который операционная си- стема предусматривает для повторного запуска демонов, — выполнить команду /etc/ init.d/cups restart или аналогичную команду. Теоретически, можно также отпра- вить демону cupsd сигнал HUP, но похоже, что на системах SUSE это приводит к уни- чтожению демона. Кроме того, демона cupsd можно перезапустить с помощью графического интерфей- са системы CUPS или посредством другого графического интерфейса, например при- ложения KDE Print Manager. В других системах существуют свои специальные методы для перезагрузки системы печати; часто они зависят от разработчиков. Например, в системе AIX используется сле- дующая последовательность команд. $ sudo stopsrc -s Ipd $ sudo startsrc -s Ipd Вы так и думали, не так ли? Регистрационные журналы Система CUPS поддерживает три регистрационных журнала: журнал страниц, жур- нал доступа и журнал ошибок. Журнал страниц представляет собой просто список напе- чатанных страниц. Журнал доступа и журнал ошибок похожи на аналогичные журналы в веб-сервере Apache. И в этом нет ничего удивительного, потому что сервер CUPS — это веб-сервер. Уровень регистрации и путь к журнальным файлам задается в файле cupsd. conf. Обычно журнальные файлы сохраняются в каталоге /var/log. Ниже приведен фрагмент из журнального файла, охватывающий одно задание на пе- чать. I I I I I [26/JU1/2006:18:59:08 -0600] [26/Jul/2006:18:59:08 -0600] [26/Jul/2006:18:59:08 -0600] [26/Jul/2006:18:59:08 -0600] (PID 19985) for job 24. [26/Jul/2006:18:59:08 -0600] (PID 19986) for job 24. Adding start banner page "none" to job 24. Adding end banner page "none" to job 24. Job 24 queued on ' Phaser_6120 ’ by ’jsh'. Started filter usr/libexec/cups/filter/pstops Started backend /usr/libexec/cups/backend/usb Проблемы с прямой печатью Удостовериться в наличии физического соединения с локальным принтером можно, напрямую выполнив внутреннюю программу принтера. Например, вот что мы получим, если выполним внутреннюю программу принтера, который подключается через USB- кабель. $ /usr/lib/cups/backend/usb direct usb "Unknown" "USB Printer (usb)" direct usb://XEROX/Phaser%206120?serial=YGG210547 "XEROX Phaser 6120" "Phaser 6120"
1126 Часть III. Разное Если USB-кабель принтера Phaser 6120 отключится, строка для этого принтера ис- чезнет из вывода внутренней программы. $ /usr/lib/cups/backend/usb direct usb "Unknown" "USB Printer (usb)" Проблемы с печатью в сети Прежде чем начинать искать проблему печати в сети, проверьте, выполняется ли пе- чать с компьютера, к которому непосредственно подключен принтер. Ваша “проблема печати в сети” может оказаться просто “проблемой печати”. Также проверьте, все ли в порядке с сетью. Далее попробуйте установить соединение с обслуживающим данный принтер демо- ном cupsd при помощи браузера (имя_узла:631) или команды telnet (telnet имя__ узла 631). Сетевой демон Ipd распечатывает задания, которые он доставил в ТСР-порт 515. Если вы не хотите печатать задания от посторонних лиц, ваш брандмауэр должен бло- кировать весь трафик, поступающий на этот порт из Интернета. Для проверки соедине- ния с удаленным сервером Ipd примените команду telnet к порту 515 на этом сервере. Если можно установить соединение, то, по крайней мере, проверьте работоспособность сети и факт запуска демона Ipd на сервере. В случае возникновения проблем при настройке соединения с сетевым принтером, помните о том, что на клиентском компьютере у вас должна быть очередь для заданий, способ для решения того, куда отправлять задание, и метод отправки задания на ком- пьютер, который отвечает за обслуживание очереди на печать. На сервере печати у вас должно быть место для постановки задания в очередь, соответствующие права доступа для разрешения печати задания и способ для вывода данных на устройство. Для того чтобы выяснить причину этих проблем, возможно, придется заглянуть в не- сколько мест. • Системные журнальные файлы на клиентском компьютере (в случае проблем с распознаванием имен и правами доступа). • Системные журнальные файлы на сервере печати (в случае проблем с правами до- ступа). • Журнальные файлы на клиентском компьютере (если отсутствуют какие-то филь- тры или каталоги или если имеются неизвестные принтеры и т.д.). • Журнальные файлы демона на сервере печати (в случае появления сообщений о неправильных именах устройств, неправильных форматах и т.д.). • Журнальные файлы принтера на компьютере, получившем задание (в случае по- явления ошибок при передаче задания), как указано в переменной If в файле /etc/printcap/ в системе BSD. • Журнальные файлы принтера на компьютере, отправившем задание (в случае по- явления сообщений о неправильной предварительной обработке или ошибочной постановке задания в очередь). Проверьте по системной документации, где находятся журнальные файлы. Путь к журнальным файлам системы указан в файле /etc/syslog. conf, а путь к журнальным файлам CUPS — в файле /etc/cups/cupsd.conf.
Глава 26. Печать 1127 Проблемы с распространением Любая программа содержит ошибки.3 В операционной системе Ubuntu, например, система CUPS обновляется каждый месяц. Одни проблемы бывают хуже других, а дру- гие имеют последствия для безопасности. Например, на более старых версиях Red Hat Enterprise Linux система CUPS постоян- но “взламывается”. Наиболее правильным решением в таких случаях является обновле- ние операционной системы, но если нет возможности установить более новую версию, можно попробовать установить текущую версию системы CUPS. 26.13. Рекомендуемая литература Каждый дистрибутивный пакет и графический пользовательский интерфейс сопро- вождаются специальной документацией, посвященной системе печати. В состав па- кета KDE входят справочные страницы с описанием команд KDEPrint и руководство KDEPrint Handbook. Дополнительную информацию можно найти на сайте printing. kde.org. Все эти источники содержат полезные ссылки на другую документацию. (Даже если у вас нет KDE, в документации по KDE вы сможете найти неплохую общую информацию о CUPS.) Система CUPS поставляется с обширной документацией в формате HTML. Для того чтобы получить к ней доступ, необходимо соединиться с сервером CUPS и щелкнуть на справочной ссылке. Разумеется это не поможет, ели у вас нет связи с этим серве- ром. Впрочем, на вашем компьютере эта документация инсталлируется в каталог /usr /share/doс/cups в форматах HTML и PDE Если ее там нет, обратитесь к менеджеру, поставившему дистрибутивный пакет, или на сайт cups. org. В форуме cups. org можно задавать вопросы, но сначала следует попробовать разо- браться во всем самому и только потом ставить вопросы, причем делать это вежливой Если вы работаете в системе Linux, обратитесь на сайт linuxprinting.org. Он представляет собой обширную коллекцию различных источников информации по пе- чати в системе Linux и является прекрасным местом для поиска ответов на вопросы. На этом сайте также выложено замечательное учебное пособие по CUPS, в котором имеет- ся раздел, посвященный выявлению и устранению проблем. Хорошие обзоры системы CUPS размещены на сайтах Википедии и SUSE. Обзор си- стемы CUPS на сайте SUSE находится по адресу: en. opensuse. org/SDB: CUPS_in__a_ Nutshell. Если вы хотите иметь напечатанное справочное пособие по системе CUPS, то мы ре- комендуем авторитетное руководство по системе CUPS, можно сказать, из первых рук. Sweet Michael R. CUPS: Common UNIX Printing System. Indianaposis, Indiana. Sams Publishing, 2001. 26.14. Упражнения 26.1. Найдите кого-нибудь, кто не разбирается в компьютерах, и научите его распеча- тывать документ PDF в вашей системе. Не испытали ли вы сложности на каком- нибудь этапе? Как облегчить этот процесс для остальных пользователей? 3 И любую программу можно сократить. Следовательно, продолжая эту мысль, можно сказать, что любую программу можно сократить до одной строки, которая не работает.
Часть III. Разное 26.2. Используя веб-браузер, зайдите на ваш сетевой принтер. Если вы работаете с си- стемой CUPS, посетите ее веб-сервер с помощью того же самого браузера. Что ме- шает вам внести изменения в настройки принтеров на этом сервере? 26.3. Зайдите в реальный или виртуальный магазин и выберите три цветных лазерных принтера, которые можно купить дешевле 400 долл. Если вы должны купить прин- тер завтра, то какой бы вы выбрали и почему? Обратитесь за информацией к базе данных на сайте linuxprinting.org. 26.4. Представьте, что вам поручили разработать системное программное обеспечение, которое должно запускаться внутри лазерного принтера, предназначенного для обеспечения работы корпоративных рабочих групп. Какой дистрибутивный пакет вы выберете? Какое дополнительное программное обеспечение вам потребуется? Как учесть потребности клиентов систем Windows и Mac Os X? (Подсказка: про- верьте дистрибутивные пакеты для системы Linux, предназначенные для “встро- енных систем”.)
Глава 27 Центры обработки данных Надежность службы зависит от надежности центра обработки данных, который ее под- держивает. Для специалистов, имеющих практический опыт, это очевидно. Однако высше- му руководству центры обработки данных кажутся чем-то далеким и почти иллюзорным. С появлением настольных рабочих станций и уходом с арены больших железных ящиков, набитых электроникой, показалось, что дни центров обработки данных со- чтены. На самом деле в настоящее время потребность в центрах обработки данных еще выше, чем прежде. Они состоят из чрезвычайно важных серверов (часто работающих под управлением операционных систем UNIX или Linux), поставляющих информацию всем желающим получать оперативные данные и интернет-приложения. Некоторые аспекты центров обработки данных — например, их физическая орга- низация, энергоснабжение и охлаждение — традиционно разрабатывались и поддер- живались “техниками”. Однако бурное развитие информационных технологий и воз- растающая нетерпимость к простоям вынудили специалистов по информационным технологиям и техников стать партнерами при планировании и эксплуатации центров обработки данных. Как системный администратор вы играете важную роль “эксперта по предметной области” в глазах техников.1 Центр обработки данных состоит из следующих компонентов. • Безопасное место. • Стойки с компьютерами, сетевым оборудованием и дисками. • Система энергоснабжения, достаточная для работы инсталлированных устройств. • Система охлаждения для поддержки требуемого температурного режима работы устройств. • Сетевые соединения внутри центра и с внешними рабочими местами (корпора-
1130 Часть III. Разное 27.1. Уровни надежности центров обработки данных На правильное функционирование центра обработки данных влияют следующие аспекты его организации. • Устройства бесперебойного электроснабжения (uninterruptible power supplies — UPSs). Устройства UPS обеспечивают электроснабжение при отказе обычного дол- говременного источника электроэнергии (например, коммерческой электрической сети). В зависимости от размера и емкости, они могут обеспечить от нескольких минут до нескольких часов работы. Сами по себе устройства UPS не могут поддер- живать работу сети при долговременном отключении электроснабжения. • Автономное генерирование электроэнергии. Если коммерческая электрическая сеть не работает, можно подключить автономные генераторы, которые могут за- менить долговременные источники электроэнергии. Генераторы обычно заправля- ются дизельным топливом, сжиженным газом или природным газом и могут под- держивать работу сети, пока не закончится топливо. Целесообразно иметь запас топлива на 72 часа автономной работы и покупать его у разных поставщиков. • Для работы с автономными генераторами также необходимы устройства UPS, что- бы обеспечить кратковременный период (обычно не превышающий 60 секунд), необходимый для запуска генераторов и перехода от электрической сети на пита- ние от генератора. • Дополнительные источники электроэнергии. В некоторых организациях суще- ствует возможность использовать несколько источников электроснабжения от электрической сети (например, от разных электростанций). • Механические системы. Эти системы называются HVAC2, но в контексте центра обработки данных к ним относится только система терморегулирования — тепло для компьютеров не нужно! Для обеспечения работы основной и резервной систе- мы терморегуляции существует множество технологий. Исследованием вопросов, связанных с управлением центрами обработки данных, занимается промышленная группа Uptime Institute. Ее сотрудники разработали четы- рехуровневую систему классификации надежности центров обработки данных, которая представлена в табл. 27.1. В этой таблице обозначение N означает, что в распоряжении центра есть достаточно ресурсов (устройств UPS, генераторов), чтобы обеспечить нор- мальную работу. Обозначение N+1 означает, что у центра есть одна запасная единица оборудования; 2N — что у каждого устройства есть дублирующее оборудование. Таблица 27.1. Система классификации, предложенная промышленной группой Uptime Institute Уровень Генератор UPS Источник энергии HVAC Коэффициент доступности 1 Нет N Один N 99.671% 2 N N+1a Один N+1 99.741% 3 N+1 N+1a Два с возможностью переключения N+1 99.982% _4 2N 2N Два работающих одновременно 2N 99.995% а С запасными компонентами. 2 Heating, ventilation and air conditioning, — отопление, вентиляция и система терморегулирова- ния. — Примеч, ред.
Глава 27. Центры обработки данных 1131 Центры, относящиеся к высшему уровню надежности, должны быть разделены на отсеки, так чтобы сбой систем электроснабжения или терморегуляции одной группы си- стем не приводил к отказу другой. Коэффициент доступности, равный 99,671%, на первый взгляд может выглядеть привлекательным, но это значит, что в течение года система будет примерно 29 часов простаивать. Коэффициент использования, равный 99,995%, означает, что система будет простаивать 26 минут в год. Но kvOv^OAL кА1С01Л,"Л0 kvAjoOtb крОЛХ^ ко кого лил коолалтл, иго ОС/«мАК0&1Л^Ь АиДЛХ U. oSptAAATA. ЛТАлилЛЛ, C&lJlAy kAic'Dbt Htvvy ОН. ИХ O^joAriVlAJl кА кДЛХ^КЛЛА4АкДЛА. Ок. hjoOOv^O *6ocC/^AK£fClAJl 0O|oL^AKjKMjL нАЛОЛ. кА&МЛЛу ^0|оЛЮЧА Ч^О-ЛО к|оО iXie'HwO. . М1Л Q кА|о€ал1ЛЛЬ НА OVtCAjACVVHA. Рис. 27.1. С любезного разрешения сайта xkcd .com Разумеется, никакое количество резервных источников электроснабжения или устройств терморегуляции не спасет систему, если она плохо управляется или непра- вильно спроектирована. Центр обработки данных — это основной структурный элемент, но его недостаточно для обеспечения работы всей организации с точки зрения конечно- го пользователя. Стандарты работоспособности систем, разработанные группой Uptime Institute, мож- но найти на ее веб-сайте uptimeinstitute. org. 27.2. Терморегуляция Как и люди, компьютеры лучше и дольше работают в благоприятной среде. Под- держка безопасной температуры — основное условие их благополучия. Ш Вопросы энергосбережения при эксплуатации центров обработки данных обсуждаются в главе 28. Американская ассоциация инженеров по отоплению, охлаждению и кондициониро- ванию воздуха (American Society of Heating, Refrigerating and Air-conditioning Engineers — ASHRAE) традиционно рекомендует поддерживать температуру воздуха в центрах обра- ботки данных (измеряемую на воздухозаборниках серверов) от 20 до 25°С. Поддерживая попытки организаций сократить потребление электроэнергии, ассоциация ASHRAE вы- пустила в 2008 году новые рекомендации, согласно которым температуру воздуха следует поддерживать в диапазоне от 18 до 27°С. Поддержка требуемой температуры начинается с точной оценки нагрузки на систе- му терморегуляции. Традиционные модели терморегуляции в центрах обработки дан- ных, взятые из учебников (даже из книг, написанных в 1990-х годах), могут на порядки отличаться от сегодняшних реалий, связанных с функционированием высокоплотных шасси на лезвийных серверах. По этой причине мы рекомендуем перепроверять оценки
1132 Часть III. Разное нагрузки на систему терморегуляции, полученные вашими инженерами по отоплению, охлаждению и кондиционированию воздуха. Вы обязаны помочь инженерам HVAC провести вычисления нагрузки на систему терморегуляции, которую оказывают крыша, стены и окна вашего здания (не забудьте о солнечном свете). Инженеры HVAC обычно имеют большой опыт работы с этими ком- понентами и обязаны дать вам точную оценку. Вам, со своей стороны, следует проверить внутреннюю тепловую нагрузку на ваш центр обработки данных. Вы должны проверить тепловую нагрузку, которую оказывают следующие компоненты. • Крыша, стены и окна (от инженеров HVAC). • Электронное оборудование. • Осветительная арматура. • Операторы (люди). Электронное оборудование Для того чтобы определить тепловую нагрузку, которую оказывают ваши серверы (и другое электронное оборудование), следует определить потребление электроэнер- гии серверами. Получить эту информацию лучше всего с помощью прямых измерений. В этом вам может помочь знакомый электрик. Впрочем, вы можете купить недорогой электроизмерительный прибор и выполнить эту работу самостоятельно.3 На большин- стве оборудования указывается максимальный расход мощности, измеренный в ваттах, но реальное потребление обычно значительно меньше максимума. Расход мощности можно преобразовать в стандартную единицу количества тепла BTUH (British Thermal Unit per hour — количество британских тепловых единиц в час), умножив его на коэффициент 3,413 BTUH/Bt. Например, если вы хотите построить центр обработки данных, в котором будет 25 центров, потребляющих по 450 Вт каждый, то вычисления будут выглядеть следующим образом. 25 серверов х 450 Вт/сервер х 3,412 BTUH/Bt = 38 385 BTUH. Осветительная арматура Как и в случае электронного оборудования, оценить тепловую нагрузку от освети- тельного оборудования можно по расходу мощности. Как правило, в офисах в качестве осветительной арматуры используются 40-ваттные люминесцентные лампы. Если в ва- шем новом центре обработки данных шесть таких ламп, то вычисления будут выглядеть следующим образом. 6 ламп х 160 Вт/лампа х 3,412 BTUH/Bt = 3 276 BTUH. Операторы Иногда людям необходимо войти в центр обработки данных, чтобы выполнить какие-то действия. Предположим, что каждый входящий человек создает тепловую на- грузку величиной 300 BTUH. Допустим, что одновременно в центр обработки данных могут войти четыре человека. 4 человека х 300 BTUH/чел = 1 200 BTUH. 3 Самым популярным электроизмерительным прибором является Kill a W^tt компании РЗ сто- имостью около 20 долл.
Глава 27. Центры обработки данных 1133 Общая тепловая нагрузка Вычислив тепловую нагрузку для каждого компонента, просуммируйте их и опреде- лите общую тепловую нагрузку. В нашем примере мы предполагали, что инженер HVAC оценил тепловую нагрузку от крыши, стен и окно равной 20000 BTUH. 20000 BTUH для крыши, стен и окон 38385 BTUH для серверов и другого электронного оборудования 3276 BTUH для осветительной арматуры 1200 BTUH для операторов 62861 BTUH всего Производительность систем терморегуляции обычно измеряется в тоннах. Для того чтобы преобразовать единицы BTUH в тонны, необходимо поделить результат на 12000 BTUH/т. Кроме того, следует допустить, по крайней мере, 50%-ный коэффициент ухуд- шения, чтобы учесть ошибки и будущий рост системы. 62,681 BTUH х 1т/ 12000 х 1,5 = 7,87 тонн охлаждения Проверьте, насколько ваши оценки расходятся с оценками инженеров HVAC. Теплые и холодные отсеки Вы можете резко уменьшить трудности, связанные с охлаждением центра обработки данных, проанализировав схему его устройства. Самой эффективной стратегией являет- ся разделение центра на теплые и холодные отсеки. Устройства, приподнятые над полом и охлаждаемые традиционными средствам# CRAC (кондиционеры воздуха в компьютерных комнатах), часто установлены так, что холодный воздух проходит над полом, поднимается через отверстия в перфорированном покрытии, охлаждает оборудование, а затем, уже в нагретом состоянии, поднимается к потолку и всасывается обратными воздуховодами. Обычно стойки и перфорированные плитки распределяются по центру обработки данных “случайно”, и в результате обеспе- чивается относительно равномерное распределение температуры. Вследствие этого среда становится комфортабельной для человека, но не оптимальной для компьютеров. Лучше было бы чередовать теплые и холодные отсеки, разделяя их стойками. В хо- лодных отсеках есть перфорированные плитки, а в теплых — нет. Сойки следует рас- положить так, чтобы оборудование втягивало воздух из холодного отсека, а отдава- ло — в теплый. Таким образом, стороны выпуска воздуха двух смежных стоек должны располагаться бок о бок. Эта схема изображена на рис. 27.2. Эта схема оптимизирует поток воздуха так, чтобы воздуховоды всегда втягивали холодный, а не теплый воздух, отработанный на охлаждении соседнего сервера. При правильном воплощении стратегия чередующихся стоек позволяет создать заметно холодные и заметно теплые отсеки. Успех охлаждения можно оценить с помощью ин- фракрасного термометра, который является незаменимым инструментом современного системного администратора. Это устройство стоит 100 долл, (например, Fluke 62) и по- стоянно измеряет температуру любого предмета, на который вы его нацелите на рас- стоянии до 20 метров. Только не доставайте его в баре! Если вы обязаны проводить кабель под полом (см. раздел 27.4), проводите кабели пи- тания под холодными отсеками, а сетевые — под теплыми. В помещениях без фальшпола могут использоваться междурядные охлаждающие устройства, например АРС (www.apcc.com). Эти маленькие устройства помещаются между стойками.
1134 Часть III. Разное Рис. 27.2. Холодные и теплые отсеки с фальшполом Принцип работы этой схемы показан на рис. 27.3. Рис. 27.3. Холодные и теплые отсеки с междурядными охлаждающими устройствами Устройства CRAC и междурядные устройства охлаждения должны иметь возмож- ность выводить тепло за пределы центра обработки данных. Это требование обычно удо- влетворяется с помощью циркуляции охлаждающей жидкости (например, охлажденной воды, хладагента Puron/R410A или R22), которая выносит тепло во внешнюю среду. Мы не показали на рис. 27.2 и 27.3 циркуляцию охлаждающей жидкости, чтобы не загро- мождать рисунки, но в большинстве случаев они необходимы. Некоторые комментарии по поводу использования внешнего воздуха для охлаждения в качестве альтернативы ме- ханическому охлаждению читатель найдет в главе 28. Влажность В соответствии с рекомендациями 2008 ASHRAE, влажность воздуха в центре обра- ботки данных должна быть в пределах 30—55%. Если влажность воздуха слишком низ- кая, возникают проблемы из-за статического электричества. Если влажность слишком высокая, конденсация может создать электрические цепи, которые могут вызвать корот-
Глава 27. Центры обработки данных 1135 кое замыкание и окисление. В зависимости от географического расположения, может возникнуть необходимость увлажнения или осушения оборудования, чтобы поддержи- вать требуемый уровень влажности. Мониторинг окружающей среды Если вы обеспечиваете работу чрезвычайно важного вычислительного оборудования, необходимо следить за температурой (и другими факторами окружающей среды, таки- ми как шум и электропитание) в центре обработки данных, когда вы там отсутствуете. Вы будете очень огорчены, придя на работу в понедельник и обнаружив расплавленный пластик на полу вашего центра обработки данных. К счастью, существуют автоматические мониторы, которые могут следить за состоя- нием окружающей среды в ваше отсутствие. Мы сами используем и рекомендуем вам продукцию семейства Sensaphone (sensaphone. com). Эти недорогие устройства для мо- ниторинга следят за такими показателями, как температура, шум и мощность, и звонят вам по телефону или отправляют сообщение на веб-сайт, если возникают проблемы. Фирма Sensaphone находится в Астоне, штат Песильвания (Aston, Pennsylvania). Ее теле- фон: (610) 558-2700. 27.3. Электропитание Компьютерное оборудование требует ровного и стабильного электропитания. В кон- тексте центров обработки данных это значит, что в нем должен работать, по крайней мере, стабилизатор, фильтрующий всплески напряжения и обеспечивающий требуемый уровень напряжения и фазы. Ш Процедуры выключения описаны в разделе 3.7. Серверы и сетевая инфраструктура должны оснащаться бесперебойными источни- ками электроснабжения. Качественные устройства UPS имеют интерфейсы RS-232, Ethernet или USB, позволяющие подключать их к компьютеру, который они обеспечива- ют электричеством, или к централизованной системе слежения, способной обеспечить быстрое реагирование. Такие соединения позволяют пересылать на компьютеры или операторам сообщения об отказе системы электроснабжения и требования выполнить аккуратное выключение компьютеров, пока не разрядились батареи. Устройства UPS имеют разные размеры и емкости, но даже самое большое из них не может служить долговременным источником электроэнергии. Если переключение на резервные источники электроэнергии занимает больше времени, чем могут работать устройства UPS, необходимо включить локальный генератор. Существует широкий выбор резервных генераторов, мощность которых колеблется от 5 до 2500 кВт. Золотым стандартом является семейство генераторов компании Cummins Onan (onan. com). Большинство организаций выбирает дизельное топливо. Если вы ра- ботаете в холодном климате, примите меры, чтобы генератор был заправлен “зимней дизельной смесью”, или замените его авиационным топливом Jet А-1, чтобы предотвра- тить гелеобразование. Дизельное топливо является химически стабильным, но на нем можно выращивать водоросли, поэтому, если вы планируете хранить дизельное топливо долгое время, добавьте в него водоросли. Генераторы и их инфраструктура — дорогое оборудование, но в некоторых ситуациях они могут сэкономить вам деньги. Если вы установите резервный генератор, то ваше устройство UPS должно быть достаточно большим, чтобы охватить промежуток времени между выключением электричества и запуском генератора.
1136 Часть III. Разное Если вы используете устройства UPS или генераторы, чрезвычайно важно периоди- чески их тестировать. Мы рекомендуем тестировать все компоненты резервной системы электроснабжения каждые полгода. Кроме того, вы (или ваш поставщик) должны вы- полнять регламентные работы на этом оборудовании, как минимум, раз в год. Требования к электроснабжению стоек Планирование электроснабжения центра обработки данных — одна из наиболее сложных задач. Как правило, возможность создать новый центр обработки данных или значительно перестроить существующий возникает каждые десять лет, поэтому, обдумы- вая систему электроснабжения, важно заглянуть далеко в будущее. Большинство архитекторов вычисляют мощность, необходимую для обеспечения центра обработки данных, умножают ее на его площадь, а затем на поправочный коэф- фициент. В реальных ситуациях этот подход не эффективен, потому что сам по себе раз- мер центра обработки данных несет мало информации о типе оборудования, которое в нем будет работать. Мы рекомендуем использовать модель энергопотребления в расчете на стойку и не обращать внимания на площадь пола. Традиционно центры обработки данных проектировались так, чтобы на каждую стойку приходилось от 1,5 до 3 кВт мощности. В настоящее время производители стали упаковывать серверы в стойки Ш и создавать шасси блэйд-серверов, в которых разме- щаются более 20 модулей, поэтому мощность, необходимая для питания всей стойки со- временного электронного оборудования, резко увеличилась. Одно из возможных решений проблемы, связанной с плотностью мощности, — раз- мещать в каждой стойке только несколько серверов Ш, оставляя остальную часть стой- ки пустой. Несмотря на то что эта технология устраняет необходимость обеспечения дополнительной мощности для стойки, она приводит к чрезмерному растрачиванию места. Лучше разработать реалистичный проект обеспечения мощности, которая может понадобиться для каждой стойки, и подумать, где ее взять. Требования к мощности у разного оборудования различные, поэтому трудно предска- зать, какая мощность понадобится в будущем. Целесообразно создать систему с разны- ми уровнями потребления мощности, в которой на каждом уровне все стойки получают одинаковую мощность. Эта схема полезна не только для удовлетворения потребностей текущих моделей, но и для планирования будущего использования. Некоторые факто- ры, которые следует учитывать при определении уровней, перечислены в табл. 27.2. Таблица 27.2. Модель распределения мощности по уровням для стоек в центре обработки данных Уровень мощности Х-- •< г . . Ватт/стойка - ' л Сверхвысокая плотностьа 25 кВт Очень высокая плотность (например, блэйд-серверы)6 20 кВт Высокая плотность (например, серверы 1U) 16 кВт Диски 12 кВт Сетевые коммутаторы 8 кВт Обычная плотность 6 кВт а Прогнозируемый верхний уровень в 2015 г. 6 Текущий верхний уровень в 2010 г.
Глава 27. Центры обработки данных 1137 Распределение мощности на верхних уровнях в табл. 27.2 может показаться слиш- ком щедрым, но его не так трудно достигнуть, даже на современном оборудовании. Компания АРС измерила потребление мощности на шасси, содержащем 14 серверов IBM BladeCenter HS20 по 4050 Вт.4 Шесть из этих шасси в стойке потребляли 24,3 кВт. Без охлаждения этой энергии достаточно, чтобы расплавить примерно 23 кг стали, алю- миния или силикона за 15 минут. Не стоит и говорить о том, что для таких конфигура- ций необходимо специальное охлаждающее оборудование. Определив уровни мощности, оцените потребности в стойках для каждого уровня. Затем на плане помещения поместите рядом друг с другом стойки, относящиеся к одно- му и тому же уровню. Такое разделение на зоны концентрирует стойки с высоким по- треблением мощности и позволяет правильно распределить ресурсы охлаждения. Киловольт-ампер или киловатт Одна из основных причин непонимания между специалистами по информацион- ным технологиям, техниками и инженерами UPS заключается в том, что каждая из этих групп использует разные единицы измерения мощности. Объем мощности, который мо- жет обеспечить устройство UPS, обычно измеряется в киловольт-амперах (кВА). Однако инженеры, обслуживающие компьютерное оборудование, и электротехники, обеспечи- вающие работу центра обработки данных, обычно выражают мощность в ваттах (Вт) или киловаттах (кВт). Возможно, вы помните из курса физики, что ватт=вольтхампер. К со- жалению, ваш учитель забыл напомнить, что ватт — это векторная величина, которая для мощности переменного тока, кроме напряжения (вольт) и силы тока (апмер), содер- жит “коэффициент мощности” (pf). Если вы разрабатываете конвейерную линию по разливке пива на пивоваренном за- воде, в которой используется много двигателей и другого тяжелого оборудования, то пропустите этот раздел и наймите квалифицированного инженера, который вычислит коэффициент мощности для вашей установки. При работе с современным компьютер- ным оборудованием вы можете схитрить и использовать константу. Для “приблизитель- ного” преобразования кВА в кВт можно использовать следующие формулы. кВА = вКт/ 0,85 кВт =кВА х 0,85 И наконец, оценивая объем мощности, необходимой для центра обработки данных (или для вычисления размера устройства UPS), следует измерить потребление мощности приборами с помощью амперметра, такого как Fluke 902, а не полагаться на значения, указанные производителем на этикетке (на которой обычно указываются максимальные значения потребления). Удаленное управление Вы можете оказаться в ситуации, в которой необходимо регулярно включать и вы- ключать сервер из-за ошибок в работе ядра или оборудования. Кроме того, возможно, в вашем центре обработки данных установлены серверы, которые работают под управ- лением другой операционной системы, а не UNIX. В этом случае также часто возникает необходимость их регулярного включения и выключения. В любом случае следует рас- смотреть возможность инсталляции системы, позволяющей выполнять эти операции в удаленном режиме. 4 См. отчет “Power and Cooling for Ultra-High Density Racks and Blade Servers” на сайте ape. com.
1138 Часть III. Разное Разумным решением является выбор продукции компании American Power Conversion (АРС). Продукция MasterSwitch похожа на линейку бесперебойного питания, за ис- ключением того, что ею можно управлять с веб-браузера с помощью встроенного порта Ethernet. Связаться с компанией АРС можно по телефону (401) 789-0204 или через веб- сайт ар с. сот. 27.4. Стойки Времена традиционных центров обработки данных с фальшполами, в которых кабели электроснабжения, система охлаждения, сетевые соединения и телефонные линии спрята- ны под полом, прошли. Можете ли вы отследить кабель, который теряется в подпольном лабиринте? Наш опыт подсказывает, что все это выглядит красиво только на картинке, а на самом деле комната с “классическим” фальшполом — это просто скрытая крысиная нора. Сегодня фальшполы используются только для того, чтобы скрыть электрические ка- бели, распределить охлажденный воздух, и больше ни для чего. Сетевые кабели (и медный, и оптоволоконный) должны проходить по внешним специальным каналам. В специализированных центрах обработки данных размещение оборудования в стой- ках (в противоположность, например, расположению на столах или на полу) — един- ственный профессиональный выбор. Самые лучшие схемы расположения запоминаю- щих устройств используют стойки, связанные друг с другом внешними каналами для кабелей маршрутизации. Этот подход обеспечивает высокую технологичность без поте- ри возможности для сопровождения. Лучшие внешние каналы для кабелей производятся компанией Chatsworth Products (Chatsworth, CA, (818) 882-8595; chatsworth.com). Использование стандартных 19-дюй- мовых монорельсовых телекоммуникационных стоек позволяет создавать блоки серве- ров, монтируемых на полках или в стойках. Две смежные 19-дюймовые телекоммуникационные стойки создают высокотехноло- гичную разновидность “традиционной” стойки (для ситуаций, в которых вы вынуждены располагать в соседних стойках оборудование, ориентированное относительно передней и задней панелей). Компания Chatsworth поставляет стойки, каналы для кабелей и вся- кие штучки для кабелей, а также оборудование, необходимое для их монтажа в вашем здании. Поскольку кабели располагаются в доступных каналах, их легко отслеживать и содержать в порядке. 27.5. Инструменты Эффективный системный администратор — это хорошо оснащенный системный ад- министратор. Иметь набор специальных инструментов важно для минимизации време- ни простоя в случае отказа оборудования. В табл. 27.3 перечислены некоторые инстру- менты, которые следует включать в такой набор. Таблица 27.3. Инструментальный набор системного администратора Универсальные инструменты / _____________ Комплект шестигранных ключей (ключей Фигурный молоток, 4 унции Аллена) Ножницы Нож электротехника или складной нож Небольшой светодиодный фонарик Крестообразная отвертка: #0, #1, and #2
Глава 27? Центры обработки данных 1159 Окончание табл. 27.3 Универсальные инструменты < — - - Набор торцевых шестигранных ключей Клещи, игловидные и обычные Детектор неоднородностей Инспекционная микрокамера Ridgid SeeSnake Рулетка Щелевая отвертка: 1/8", 3/16" и 5/16" Набор звездообразных ключей Тогх Миниатюрный пинцет Миниатюрные ювелирные отвертки Специальные.... Цифровой мультиметр (DMM) Кабельная стяжка (и их аналоги на "липучках”) Инфракрасный термометр Комплекс винтов PC (например, на сайте crazypc. com) Щипцы RJ-45 Портативный сетевой анализатор/ноугбук Концевые муфты SCSI Запасные кабели с перекрещивающимися парами категорий 5n6ARJ-45 Запасной кабель питания Запасные разъемы RJ-45 (с твердым ядром и многожильный) Заземляющий браслет для статического Клещи для удаления изоляции (с встроенным инструментом электричества для резки проволоки) Разное Баллон со сжатым воздухом Зеркальце дантиста (желательно телескопическое) Мобильный телефон Комплект первой помощи, включающий ибупрофен и ацета- минофен Изоляционная лента Номер домашнего телефона и служебных телефонов сотруд- ников Ватные палочки Список контактов для срочной связи в случае опасной ситуа- ции8 Шесть банок пива (как минимум) а Номера контрактов на обслуживание. 27.6. Рекомендованная литература • Telecommunications Infrastructure Standard for Data Centers. ANSI/TIA/EIA 942. • ASHRAE Inc. ASHRAE 2008 Environmental Guidelines for Datacom Equipment. Atlanta, GA: ASHRAE, Inc., 2008. • Eubank H., Swisher J., Bums C., Seal J., Emerson B. Design Recommendations for High Performance Data Centers. Snowmass, CO:Rocky Mountain Institute, 2003. 27.7. Упражнения 27.1. Зачем размещать компьютеры в стойках? 27.2. 'Аг Окружающая среда влияет как на людей, так и на компьютеры. Добавьте свои факторы к тем, которые указаны в книге (например, пыль, шум, свет, помехи и др.). Выберите четыре показателя и оцените комфортабельность вашей лаборато- рии для людей и машин.
1140 Часть III. Разное 27.3. На входе рабочей станции сила тока составляет 0,8 А, на входе монитора 0,7 А, а напряжение равно 120 В. а) сколько мощности потребляет ваша система в ваттах? б) допустим, что электричество стоит около 0,12 долл.ДкВт час). Сколько будет стоить круглогодичная работа такой системы? в) сколько вы сэкономите за год, отключая мониторы на 16 часов в день (вруч- ную или с помощью функциональных возможностей Energy Star, таких как стандарт DPMS)? г) чему равна годовая стоимость охлаждения такой системы? (Сформулируйте свои предположения и проведите вычисления.) 27.4. ★★ Разработайте проект новой компьютерной лаборатории для вашей организа- ции. Сформулируйте свои предположения о требуемой площади, количестве ком- пьютеров, типе каждого компьютера и потребляемой мощности. Затем определите требования к мощности и системе терморегуляции в вашей лаборатории. Учтите в проекте как серверы, так и клиентские рабочие станции. Приложите схему комна- ты, освещения и укажите ожидаемую тепловую нагрузку за счет людей.
Глава 28 Экологичные информационные технологии Может показаться, что книга о системном администрировании — это неподходящее место для главы о защите окружающей среды и социальных вопросах. Однако в настоя- щее время, когда крупные организации, внедряющие информационные технологии, уже не редкость, вопросы, связанные с их влиянием на окружающую среду и потребление ресурсов, стали привлекать к себе внимание. Экологичные информационные техноло- гии — это искусство и наука о сокращении скрытых и явных затрат ресурсов. Несмотря на то что каждый из нас может внести маленький вклад в защиту окру- жающей среды, изменив свои привычки и предпочтения, основное влияние все же оказывают централизованные усилия. Например, никакие попытки следовать лозунгу “Выбирайте неэтилированный бензин! В целом, он намного лучше!” нельзя сравнить с эффектом от принятия федерального закона, останавливающего производство авто- мобилей, использующих свинец. Угадайте, кто может отдать подобный приказ вашей организации? Вы! Однако зачем же беспокоиться? Например, чтобы испытывать гордость за то, что ты делаешь полезное дело для всей планеты, хотя существуют и практические причины, чтобы убедить руководителей вашей организации внедрить “зеленые” информационные технологии. • Снижение первоначальных издержек. Минимизируя количество оборудования, при- обретаемого и используемого вашей организацией, вы снижаете капитальные за- траты. Минимизируя размер центра обработки данных, вы снижаете стоимость недвижимости.
1142 Часть III. Разное • Снижение эксплуатационных расходов. Электроэнергия, управление и эксплуата- ция оборудования стоят денег. Эффективное использование меньшего количества устройств означает снижение прямых издержек вашего предприятия. • Экономия накладных расходов. Вы платите за электричество дважды: один раз — за электроснабжение оборудования, а второй — за охлаждение оборудования после того, как оно преобразует дорогую энергию в тепло.1 Чем меньше оборудования, тем меньше его требуется охлаждать, тем меньше нужно ему площади и меньше людей для обслуживания. Чем меньше людей, тем меньше затраты на аренду и кондиционирование офиса, меньше объем заработной платы, премий и матери- альной помощи. В главе рассматриваются основные концепции, позволяющие уменьшить потребле- ние электроэнергии и ресурсов вашей организацией. Мы имеем в виду организации, в центрах обработки данных которых работают от 1 до 500 серверов. Если ваша органи- зация крупнее, следует нанять эксперта по проектированию экологичных центров об- работки данных, чтобы достичь наибольшего эффекта. 28.1. Введение в экологичные ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ Что мы имеем в виду под “экологичными” технологиями? • Более низкое потребление электроэнергии. • Более скромные требования к оборудованию. • Снижение потребления расходных материалов. • Вторичная переработка отходов. В области экологичных информационных технологий нет волшебного решения или единственно возможного пути решения проблем. Несмотря на заверения поставщиков, вы не можете купить одну продукцию, которая решила бы все экологические проблемы в мире. В частности, экологичные информационные технологии — это нечто большее, чем просто серверная виртуализация. Аналогично тому как системное администриро- вание имеет много аспектов, внедрение экологичных информационных технологий — это больше процесс, чем цель. Сначала необходимо представить себе, чего вы хотите достичь, наметить план достижения цели, а затем воплотить его в жизнь. Ключевыми элементами в этом плане должны стать постоянные измерения и мониторинг. Для начала оцените экологичность вашей среды. Сделайте полный обзор всех ин- формационных мощностей вашей организации, и не только для того, чтобы повысить эффективность вашего проекта, но и чтобы убедить людей, что вы не просто сотрясаете воздух. Например, с экологической точки зрения было бы замечательно удалить все сер- веры, но вы скоро поймете, что исключение 50 управляемых вами серверов приведет к тому, что ваши пользователи в ответ купят и установят 600 неконтролируемых серверных систем в своих комнатах. В начале своих экологических исследований необходимо собрать следующую инфор- мацию. 1 Информационная работа, выполняемая компьютерным оборудованием, не является значи- тельной величиной с точки зрения термодинамики. Компьютеры, по существу, представляют со- бой эффективное устройство, которое преобразует 100% электроэнергии в тепло.
Глава 28. Экологичные информационные технологии 1143 • Учет оборудования. Следует учесть все, включая серверы, ноутбуки, мониторы, принтеры, запоминающие устройства, сетевое оборудование, резервное оборудо- вание, устройства UPS и модули охлаждения. Определите их местоположение, но- мер модели, “размер” (в единицах, характерных для выбранного оборудования), а также возраст. • Полезно также узнать уровень потребления мощности для каждой единицы обору- дования. Номинальный уровень потребления мощности может исказить реальное положение дел. Лучше измерить фактическое потребление энергии с помощью прибора Kill a Watt, который стоит около 20 долл.2 Для устройств, имеющих актив- ный и спящий режим (например, принтеров), можно записать средний уровень потребления энергии за день или неделю. • Учет расходных материалов. К ним относятся бумага, тонер, диски. • Показатели работы организации. Эти показатели включают в себя валовой доход, количество сотрудников, количество рабочих мест, общий объем потребления энергии, объем энергии, потребляемой компьютерным оборудованием (в центрах обработки данных), уровень потребления энергии системами терморегуляции в центре обработки данных, общий объем капиталовложений в информационные технологии, общий объем эксплуатационных издержек, связанных с информаци- онными технологиями, и общую стоимость оборудования для центров обработки данных. Собрав эти данные, определите от одной до трех целей для оптимизации. Эти цели должны быть связаны с общей стратегией развития вашего предприятия и демонстриро- вать прогресс в направлении более экологичных информационных технологий. Мы не можем указать, какая цель может оказаться наиболее подходящей для вашей организа- ции, но приведем несколько примеров. • Уровень потребления энергии центром обработки данных в расчете на доллар ва- лового дохода. • Количество сотрудников в расчете на один сервер. • Количество листов бумаги, использованной сотрудниками за месяц. • Среднее потребление энергии оборудованием, расположенным на рабочем месте сотрудника. • Средний срок службы ноутбука. • Уровень потребления энергии центром обработки данных по отношению к обще- му потреблению энергии всем оборудованием.3 Выполняйте повторную оценку состояния вашего компьютерного оборудования не реже одного раза в год, а уровень потребления мощности измеряйте ежемесячно. 2 Этот прибор разработан для североамериканского рынка, но аналогичную продукцию можно найти и на других рынках. Например, аналоги для Великобритании можно найти на сайте геик. со.uk/Buy-UK-Power-Meter.htm. 3 Этот показатель, умноженный на 100, равен процентной доле мощности оборудования, на- правленной на потребление компьютерным оборудованием. В промышленности этот показатель называется DCiE. Это стандартный показатель, который можно использовать для сравнения орга- низаций. Эффективность потребления мощности (PUE — power usage effectiveness) — это показа- тель, обратный к показателю DCiE. Он используется для оценки эффективности крупных центров обработки данных.
1144 Часть III. Разное 28.2. Экологическая пирамида Понять, насколько экологичной является ваша организация, достаточно легко. Труд- нее достичь (и измерить) ее прогресс в направлении улучшения окружающей среды. Для того чтобы вы ориентировались в возможностях, описанных в этой главе, мы разделили стратегии экологического развития компьютерных технологий на три категории, как по- казано на рис. 28.1. Рис. 28.1. Подходы к экологичным информационным технологиям Мы представили эти категории в виде пирамиды, поскольку стратегии, указанные внизу, имеют наибольший эффект и чаще обеспечивают побочную выгоду. По мере подъема по пирамиде, стратегии становятся более дорогостоящими, а усилия менее эф- фективными. Поиск путей к экологичным информационным технологиям всегда следует начинать! с сокращения прямого потребления — лучше меньше да лучше. Если вы можете достичь своей цели с меньшими усилиями и затратами ресурсов, сократите капитальные и экс- плуатационные расходы. Второй по качеству является стратегия уменьшения вторичного потребления. На-? пример, охлаждение, необходимое для работы серверов, относится к вторичному потре- блению, поскольку оно возникает как следствие существования сервера. Оптимизации системы HVAC для минимизации затрат на охлаждение экономит деньги, но это не мо- жет сравниться с экономией от полного отказа от сервера. Возможно, это не логично, но выбор продукции и технологий, называемых эколо- гичными, мы отнесли к последней категории. Это можно описать такой аналогией: сна^ чала мы уменьшаем количество автомобилей на дорогах до минимально возможного й только потом заменяем оставшиеся автомобили эффективными моделями. 28.3. Стратегии разработки экологичных информационных технологий: центр обработки данных Центры обработки данных представляют собой превосходные объекты для экологи- ческих инициатив, потому что они обычно работают по принципу 7x24x365 и находятся под непосредственным контролем специалистов под информационным технологиям.
Глава 28. Экологичные информационные технологии 1145 Исследование компании Lawrence Berkeley Laboratories показало, что центры обработки данных могут потреблять в 40 раз больше энергии, чем обычные офисы.4 При таком уровне потребления необходимы специальные стратегии. Как показано на рис. 28.2, стратегии сокращения прямого потребления, расположенные внизу пира- миды, являются самыми эффективными. В принципе, нет необходимости использовать в конкретной ситуации сразу все стратегии, но каждая из них может внести свой вклад. Оборудование с низким уровнем потребления Рис. 28.2. Экологичные стратегии для центров обработки данных Наименее эффективная Наиболее Поддержание более высокой температуры в компьютерном зале Продление сроков д ействия оборудования Режим ограниченной функциональности для простоев Эффективное охлаждение/внешний воздух Облачные вычисления Детальное планирование потребления Установка ^ве^втолькопринеобх^мости Cera SAN вместо локальных дисков |ЩВшциясер£Йр<» кКон(»л^ < Консолидация приложений Со временем организации и департаменты информационных технологий стремятся аккумулировать приложения. Новые приложения поступают для поддержки специфик ческих деловых инициатив и игрушечных проектов директоров, но старые приложения исчезают редко. Чаще они долго не уступают дорогу, и никто не берет на себя риск полг ностью их устранить. Какой бы ни была причина, в устоявшейся организации основной тенденцией является стремление к консолидации приложений до минимального набора, удовлетворяющего текущие производственные потребности. Рассмотрим пример организации, в которой эксплуатируется три приложения: EmployeeLinq, AccountAwesome и ElectricClockster. Несмотря на то что это упрощен- ный пример, он похож на реальную ситуацию, которая сложилась в одной из изучен- ных нами организаций. Каждое из этих приложений имеет сервер базы данных, сервер приложения и веб-сервер. В сумме получаем девять серверов, поддерживающих эти три приложения. На первом этапе в направлении консолидации следует составить список функций, вы- полняемых каждым приложением. Функции, выполняемые приложениями из нашего при- мера, перечислены в табл. 28.1. Как видим, некоторые функции дублируют друг друга. Таблица 28.1. Функциональные возможности трех приложений Кредиторская/дебиторская задолженность X Управление прибылью X X ^Временные данные персонала X X X 4 См. сайт eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf.
1146 Часть III. Разное Окончание табл. 28.1 функция el аа ЕС Главная бухгалтерская книга X Расчет заработной платы X X Оценка времени X X X Учет отпусков и отгулов X X Эта организация имела три системы для отслеживания времени, две системы — для расчета заработной платы (хотя в каждый момент времени использовалась только одна из них) и многие другие дублирующие функции. Такая ситуация сложилась потому, что три отдела — финансовый, кадров и произ- водственный — использовали свое собственное приложение. Это не только привело к растрате энергии и компьютерных ресурсов, но и усложнило или вообще сделало невозможным интеграцию данных между отделами. В данном случае переход органи- зации на одно прикладное приложение привело к сокращению аппаратного обеспече- ния и затрат энергии на 60%, при этом потоки данных внутри компании стали более согласованными. Ваша ситуация, возможно, выглядит не так трагично, но если вы потратите время на составление таблицы функций, то, вероятно, обнаружите их дублирование. Обосновать консолидацию приложений очень легко, потому что проектируемые ре- зультаты (по крайней мере, частично) можно выразить в сэкономленных долларах. Ин- теграция данных и улучшение функционирования предприятия — это просто дополни- тельное преимущество. Консолидация серверов В большинстве организаций работает, по крайней мере, несколько узкоспециали- зированных серверов, уровень использования которых составляет 10% или меньше. Например, мы видели много организаций, в которых были выделенные серверы NTP (network time protocol). NTP — это низкоуровневый протокол, требующий небольших вычислительных усилий. Резервирование сервера для протокола NTP напоминает neper лет Боинга 767 через всю страну с одним пассажиром на борту. Консолидация серверов очень напоминает консолидацию приложений и является нё менее эффективной, только вместо концентрации многих функций в одном приложен нии мы концентрируем несколько служб на одном серверном компьютере. В отличие от системы Windows, системы UNIX и Linux изначально превосходно реа- лизуют режим приоритетной многозадачности. Хорошим решением в случае протокол# NTP является запуск демона NTP на одних и тех же серверах, обеспечивающих работу таких общих инфраструктурных служб, как DNS и Kerberos.5 Еще одну часто возникающую возможность консолидации серверов предоставляю? серверы баз данных, предназначенные для работы с одним приложением. Если у вас ра- ботают компетентные системный администратор и администраторы баз данных (а также есть хорошие средства мониторинга), то отдельный сервер баз данных может хранить 5 Протокол NTP — это особый случай, в котором задержка ответа может быть небольшой. Однако это не значит, что на той же самой машине вы сможете запустить другие службы. К до- менам сервера NTP обычно применяется утилита nice, чтобы при необходимости предоставить ИМ доступ к центральному процессору (см. раздел 5.6). Аналогичный результат — и даже более надеж- ный — можно получить с помощью серверной виртуализации.
Глава 28. Экологичные информационные технологии 1147 базы данных для многих приложений. Эта консолидация также снижает стоимость ли- цензий, капиталовложения и потребление электроэнергии. В некоторых ситуациях сократить количество серверов можно, заменив старые и ме- нее мощные серверы меньшим количеством новых и более мощных серверов, эффек- тивно потребляющих электроэнергию. Сеть SAN Признаком “ненасытности” информационных технологий является парк серверов, заполненных жесткими дисками. Представьте себе центр обработки данных, состоящий из 100 серверов, каждый из которых содержит шесть дисков емкостью один терабайт. Эти 600 дисков необходимо произвести, обслужить, снабдить электроэнергией, а по- том вынуть и выбросить. Вероятность того, что средняя степень использования этих устройств превысит 50%, равна нулю. Этот подход приводит к чрезмерным расходам, потому что он подразумевает разделе- ние запоминающих устройств на изолированные части, которыми невозможно эффек- тивно управлять, так чтобы для каждого сервера или приложения выделялся “правиль- ный” объем памяти. На некоторых серверах может храниться меньше одного терабайта данных, в то время как другие серверы могут оказаться перегруженными, не имея воз- можности использовать простаивающие диски на соседних шасси. ЕУтипичном центре обработки данных с изолированными дисками на каждом сервере трудно достичь хотя бы 30% использования запоминающих устройств. у Хорошей альтернативой этому подходу является сеть хранения данных, или SAN; она описана в разделе 8.11. Технология SAN обеспечивает высоконадЪкное хранение данных, которое одновременно является экологичным, потому что системные адми- нистраторы могут эффективно выделять память на централизованных запоминающих устройствах. Многие организации превысили 90%-ный уровень использования своих сетей SAN. Это в три раза выше эффективности использования изолированных дисков. Сейчас, когда сети SAN функционируют на интерфейсах Ethernet, больше нет препят- ствий для развертывания этого превосходного инструмента. Серверная виртуализация Одной из самых популярных экологичных информационных технологий является серверная виртуализация, впрочем, частично эта популярность подогревается рекламой, которая оплачивается компаниями, производящими платформы для виртуализации. Серверная виртуализация (подробно описана в главе 24) — действительно фантасти- ческий инструмент. Ее влияние на экологию можно сравнить с консолидацией серверов. В обоих случаях на одном компьютере выполняется несколько приложений или служб. Виртуализация сокращает потребление электроэнергии за счет уменьшения количества шасси, задействованных в производстве, и более эффективного использования осталь- ного оборудования. Виртуализация предлагает дополнительные функциональные возможности, которых нет у консолидации, например возможность легко масштабировать идентичные систе- мы, резервировать часть мощности аппаратного обеспечения для конкретного сервера, а также переносить виртуальные серверы на другие физические шасси. Эти аспекты вир- туализации являются ее преимуществами. Однако у виртуализации есть и недостатки. Приложения с интенсивным вводом- выводом обычно плохо виртуализируются и медленнее работают в виртуализированной
1148 Часть III. Разное среде. Процесс виртуализации сам по себе требует ресурсов, поэтому виртуализиро- ванные системы имеют накладные расходы, которых нет у физических систем. Допол- нительные уровни абстракции, создаваемые из-за виртуализации, вызывают насторо- женность у некоторых системных администраторов, потому что самой виртуализацией необходимо активно управлять и она может влиять на функционирование систем, рас- положенных на конкретном узле. Виртуализацию лучше всего проводить в компаниях с хорошо подготовленными спе- циалистами в области информационных технологий и устоявшимися бизнес-процессами. На данный момент мы не рекомендуем осуществлять серверную виртуализацию начина- ющим системным администраторам. Однако эта технология быстро совершенствуется и становится более простой. Скоро она станет совершенно необходимой. Только самые необходимые серверы При использовании только необходимых серверов, те серверы, которые в данный мо- мент не используются, выключаются. Этот подход лучше всего зарекомендовал себя в ситуациях с предсказуемым циклическим потреблением электроэнергии; например, ког- да сервер связан с циклом бухгалтерских вычислений или работой, которая выполняется только ранним утром. Этот метод не получил широкого распространения, но иногда вне- дрить экологичные информационные технологии можно только с помощью этого трюка. Для того чтобы реализовать эту технологию, нужно иметь несколько схем и удли- нители, соединенные с интерфейсом Ethernet (управляемые). Такие платформы, как RightScale (rightscale. com), распространили эту концепцию на системы с повышен- ными требованиями. С ее помощью можно установить пороговые значения, достигнув которые дополнительные серверы автоматически включаются (или выключаются) в со- ответствии с нагрузкой центрального процессора или объемом трансакций. Использование детализированных данных и планирование потребления В области экологичных информационных технологий, как и в других областях, мож- но управлять только тем, что можно измерить. Тщательный сбор данных играет важную роль в процессе оптимизации вашей среды. Если вы регистрируете использование ресурсов вашей сети, например загрузку цен- тральных процессоров и памяти (см. главу 29), можете планировать установку нового ап- паратного обеспечения так, чтобы не покупать сервер “про запас”. Мониторинг и анализ требуют времени, но они позволяют правильно организовать управление работой центра обработки данных. Покупайте только то, что вам необходи- мо; используйте только то, что должны использовать. Конфигурация серверов, оптимизированная по потреблению энергии Некоторые системы позволяют сэкономить энергию, управляя работой самой системы. Возможности экономии энергии в системе Linux Центральные процессоры и ядра центральных процессоров можно останавливать, чтобы сократить потребление энергии. Для того чтобы свести потребление энергии к
Глава 28. Экологичные информационные технологии 1149 минимуму, следует упаковать как можно больше потоков в одном ядре или центральном процессоре и не активизировать дополнительные ядра и центральные процессоры, пока они не понадобятся. И наоборот, чтобы достичь максимальной производительности, следует распределить потоки среди ядер и центральных процессоров как можно шире, чтобы минимизировать время простоя за счет переключения и поочередного использо- вания кеша. Теоретически, следует пожертвовать частью производительности в пользу уменьшения потребления электроэнергии. На практике возможность отключения части центрального процессора возника- ет только тогда, когда система не загружена. В этой ситуации дополнительные уси- лия на упаковку потоков в одном ядре могут не привести к осязаемому эффекту. Поэкспериментируйте, чтобы увидеть хоть какую-нибудь разницу на фоне вашей кон- кретной рабочей нагрузки. Система управления потреблением электроэнергии, которая является частью плани- ровщика процессов, проверяет две управляющие переменные. Обе они устанавливаются в файлах, расположенных в каталоге /sys/devices/system/cpu. Переменная sched_mcjpower_savings контролирует, все ли ядра центрального процессора используются, прежде чем активизировать другой центральный процессор, а переменная sched_smt_power_savings контролирует, все ли слоты потоков в ядре используются, прежде чем активизировать другое ядро. В обоих случаях значение 0 от- ключает режим экономии электроэнергии, а значение 1 включает его. Например, для того чтобы включить оба режима экономии электроэнергии, можно выполнить следующие команды. / $ sudo sh -с 'echo 1 > / sys/devices/sys tem/cpu/sched_mc_powe г/savings' $ sudo sh -c 'echo 1 > /sys/devices/sys tem/cpu/sched_smt_powe7_savings' Для того чтобы эти изменения применялись при перезагрузке, выполните команду sysctl или добавьте эти строки в стартовый сценарий, например /etc/init.d/local в системах Ubuntu и SUSE (создайте его, если необходимо) или /etc/ге. local в си- стеме Red Hat. Центральный процессор компьютера — один из самых расточительных потребителей электроэнергии (его можно считать поглотителем тепла!), поэтому агрессивное управле- ние его функционированием может значительно снизить потребление электроэнергии системой. Экономия электроэнергии, потребляемой файловыми системами Сэкономить электроэнергию и повысить производительность можно, запретив фай- ловым системам записывать “время последнего обращения” (st_atime) к каждому файлу. Эта информация не очень полезна и теоретически добавляет к каждой файловой опера- ции одну операцию позиционирования и одну операцию записи. (Оценить ее влияние в реальных условиях намного труднее из-за блочного кеширования.) В 2003 году Зедлевски и соавторы (Zedlewski et al.) проанализировали потребление электроэнергии дисками и пришли к выводу, что на диске IBM Microdrive на операцию позиционирования затрачивается 4 миллиджоуля; для стандартных дисков с более круп- ными деталями эту величину следует, по меньшей мере, удвоить. Суммируя затраты на позиционирование и запись, можно вычислить выгоду от запрета записи “времени по- следнего обращения”, которая составит несколько киловатт на один диск в год. Это не много, но заслуживает внимания с точки зрения повышения производительности; эко- номия электроэнергии в данном случае представляет собой побочный эффект.
1150 Часть III. Разное В большинстве файловых систем запретить запоминать время последнего обращения можно с помощью параметра noatime команды mount. $ sudo mount -о remount,noatime I Некоторые системы семейства Linux также поддерживают параметр relatime ко- манды mount, обеспечивая гибридные функциональные возможности. В этом случае время последнего обращения обновляется, только если предыдущее значение предше- ствует моменту модификации файла. Этот режим позволяет таким инструментам, как программа для чтения почты, правильно распознавать ситуации, в которых интересую- щий их файл был изменен, но еще не прочитан. Облачные вычисления Ш Облачные вычисления описываются в разделе 24.1. Сделайте глубокий вдох и посмотрите на проблему с иной точки зрения. Недавно появившаяся возможность “облачных вычислений” принесла массу выгод, одной из ко- торых является экономия электроэнергии. Стремясь организовать дешевые и надежные службы, провайдеры наподобие компании Amazon создали сверхэффективные центры обработки данных и процессы для управления загрузкой оборудования. Эти облачные провайдеры могут предоставить компьютерные циклы, которые являются более эколо- гичными, чем любой самый эффективный центр обработки данных, который вы можете спроектировать самостоятельно. Если нет острой необходимости, чтобы ваши приложения (особенно веб-приложе^ ния) функционировали только в вашем здании, рассмотрите возможность перенести их инфраструктуру в центр облачных вычислений. Вы будете по-прежнему обладать пол- ным административным контролем над виртуальными системами, которые будут функ- ционировать в этой среде. Просто вы никогда не сможете их физически “пощупать”. Свободное охлаждение Представьте себе холодный зимний день. Вы прогуливаетесь вокруг центра обработ- ки данных и видите, как, работая на полную катушку, кондиционер выводит тепло в ат- мосферу. Снаружи 10 градусов мороза, но совершенно очевидно, что инженер HVAC разрабатывал систему терморегуляции, использующую механическое охлаждение (и зна- чительный объем электроэнергии), чтобы выводить тепло за пределы центра обработки данных независимо от температуры окружающей среды. К счастью, некоторые современные инженеры HVAC, специализирующиеся на про- ектировании центров обработки данных, предлагают лучшее решение этой проблемы: использовать для охлаждения оборудования внешний воздух, если его температура до- статочно низкая. Разумеется, это решение подходит не везде и не всегда. Консорциум технологиче- ских компаний Green Grid, специализирующийся на повышении эффективности ис- пользования электроэнергии центрами обработки данных, выпускает карты “свободного охлаждения” для Северной Америки и Европы, на которых показано, сколько часов в год можно охлаждать внешним воздухом центры обработки данных в данной местности. Существует также более подробный калькулятор охлаждения, который можно найти на сайте thegreengrid.org.
Глава 28. Экологичные информационные технологии 1151 Эффективное охлаждение центра обработки данных Для сокращения потребления электроэнергии системой охлаждения центра обработ- ки данных существует несколько способов. Например, можно применить описанную выше схему теплых и холодных отсеков, которая концентрирует охлаждение там, где эго необходимо, и позволяет другим частям вычислительного центра функционировать при более высокой температуре. Более подробное обсуждение некоторых из этих советов изложено в главе 27. Режим ограниченной функциональности во время простоя Многие организации зациклены на эксплуатационной готовности (например, Upti- me). При этом они часто не учитывают дополнительные затраты энергии и ресурсов, необходимые для того, чтобы достичь требуемого уровня эксплуатационной готовности. Внутренние потребители привыкают думать о услугах как о чем-то таком, что либо есть, либо нет. Представьте себе услуги с ухудшенными характеристиками как дополни- тельную возможность управления простоями и спросите себя, как это может удовлетво- рить потребности клиентов. Например, вместо запуска абсолютно избыточного набора оборудования для каждой производственной среды, можно применить серверную виртуализацию и развернуть не- сколько приложений на одном шасси для работы во время простоя. Эта конфигурация может иметь все стандартные функциональные возможности, но работает медленнее, чем обычно. В некоторых ситуациях этот компромисс может сэкономить до 50% капи- тальных затрат предприятия и даже больше. Продление срока эксплуатации оборудования Производство электроники потребляет энергию и генерирует ядовитые отходы, поэтому покупка нового оборудования влечет нагрузку на окружающую среду, которая не всегда отражается на ценнике. К сожалению, промышленность настолько привыкла к быстрым инновациям и'поящтению новых изделий, что производители часто прекра- щают поддержку своей продукции уже через несколько лет после ее выпуска. Если ваше оборудование удовлетворяет ваши потребности и потребляет разумное количество электроэнергии, то подумайте о стратегии, основанной на продлении срока его эксплуатации.6 Такая схема обычно сопровождается поисками на аукционе eBay и в других источниках дешевых подержанных запасных частей для аналогичных систем и превращением своего рабочего места в выставку антиквариата. Это позволяет прод- лить функционирование системы на два-три года, хотя в одном случае нам таким обра- зом удалось заставить систему проработать на восемь лет больше положенного срока. Если старое оборудование не удовлетворяет требованиям, предъявляемым к уровню производительности, или для него нет запасных частей, можно купить новое оборудова- ние для производственного отдела, а старое передать отделу проектирования, где произ- водительность и надежность не так важны. Этот подход не позволяет вообще избежать покупки нового оборудования, но откладывает покупку для отдела проектирования на один-два года. 6 Если же ваше оборудование не является эффективным с энергетической точки зрения, то лучше заменить его немедленно, чтобы сэкономить на потреблении электроэнергии, даже с учетом стоимости его размещения и замены.
1152 Часть III. Разное Если оборудование просто устарело, примите меры, чтобы передать его компании, занимающейся утилизацией компьютеров, которая разберет его на запасные части и каждую из них соответствующим образом утилизирует. Убедитесь, что у этой компа- нии есть сертифицированная программа утилизации, чтобы ваши данные не попали кому-то еще. Компьютеры содержат удивительно много ядовитых веществ. Что бы ни случилось, не выбрасывайте компьютер в мусорный контейнер, поскольку оттуда он, скорее всего, попадет на свалку, не предназначенную для хранения электронных устройств. В некоторых регионах существуют организации, бесплатно осуществляющие утили- зацию компьютеров. Например, в Портленде, штат Орегон, существует программа ути- лизации (freegeek.org). Более высокая температура в центре обработки данных Примерно треть электроэнергии, потребляемой обычным центром обработки дан- ных, уходит на охлаждение. Ранее температура воздуха в центрах обработки данных под- держивалась в диапазоне от 20 до 25°С. Сейчас эти оценки кажутся слишком консерва- тивными. В начале 2009 года Американская ассоциация инженеров по отоплению, охлажде- нию и кондиционированию воздуха (American Society of Heating, Refrigerating and Air- conditioning Engineers — ASHRAE) выпустила руководство, в котором указан приемле- мый диапазон температуры для центров обработки данных от 18 до 27°С. Повышение температуры воздуха в центре обработки данных на три градуса экономит примерно 12% стоимости охлаждения. Дополнительные советы по системе охлаждения можно найти в главе 27. Энергосберегающее оборудование Покупая новое оборудование, посвятите время выбору продукции с минимальным влиянием на окружающую среду. Организация IEEE стандартизировала критерии для оценки влияния электроники на окружающую среду в публикации IEEE Р1680. Оценочная система, основанная на доку- менте IEEE Pl680, Electronic Products Environmental Assessment Tool (EPEAT), учитывает большой спектр потенциальных факторов, которые могут иметь место в производстве. Это позволяет осуществлять правильную оценку продукции. В настоящее время эта си- стема охватывает производство настольных компьютеров и ноутбуков, “тонких клиен- тов”, рабочих станций и компьютерных мониторов. Ее оценки являются обязательными при осуществлении правительственных закупок. (Посетите сайт EPEAT epeat. net.) Обратите внимание на то, что от потребления электроэнергии система ЕРЕАТ требу- ет согласованности со стандартом Energy Star (версия 5.0, 1 июля 2009 года). Некоторые производители серверов (включая Dell, Sun, IBM и HP) предлагают эко- логически ориентированные линейки продукции. Однако даже экологичные серверы влияют на окружающую среду и потребляют энергию. Существование такой продукции еще не дает право приписывать к названию оборудования слова “экологичное”. В пер- вую очередь следует определить количество необходимых серверов и только затем вы- бирать самые экологичные.
Глава 28. Экологичные информационные технологии 1153 28.4. Экологические информационные стратегии: рабочее место пользователя Еще одна возможность для внедрения экологичных технологий — рабочее место пользователя. Некоторые подходы к реализации этих технологий проиллюстрированы на рис. 28.3. Работа в дистанционном режима Утилизация бумаги и тонера Наименее эффективная Наиболее Рис. 28.3. Стратегии для создания экологичных рабочих мест пользователей Утилизация на рабочем месте Продление срока эксплуатации оборудования Утилизация оборудования Более высокая температура воздуха в офисе Электронная документация ^т^Знн^Аечать и печать двух страниц Огказ от обогревания пустого пространства Обоснованный выборразмера Одна рабочая станция на человека СпяЩий режимво время простоя ЗаменаЭЛТнаЖКД- Образование пользователей - - Ниже указано, на что может влиять экологичная информационная технология. Большинство соображений вполне очевидно, и многие из них можно найти в других пу- бликациях. (Вполне возможно, что вы об этом уже знаете.) • Образование пользователей. Поощряйте пользователей отключать оборудование, когда оно не нужно, думать, прежде чем распечатывать документы на принтере, и переводить настольные системы в энергосберегающий режим вместо запуска экранной заставки (а еще лучше, выключать их). • Мониторы. Заменяйте электроннолучевые трубки (ЭКТ) на жидкокристалличе- ские дисплеи (LCD). Последние тратят намного меньше электроэнергии и содер- жат меньше токсичных элементов. • Простои рабочих станций. Централизованно настройте рабочие станции так, чтобы во время простоя они переходили в спящий режим или отключались на заданный период (например, на 30 минут). • Считайте рабочие станции. Ограничьте количество рабочих станций — не больше одной станции на человека. Пользователи, заявляющие, что им нужно несколько станций, должны использовать виртуального клиента. • Размер станции должен соответствовать поставленной задаче. Не покупайте одина- ковые для всех рабочие станции. Выберите три-четыре уровня спецификаций, что- бы пользователи могли выбрать конфигурацию, соответствующую их заданиям. • Персональные обогреватели. Вообще-то, эта тема не относится к информационным технологиям, но это досадный фактор, который замечают только компьютерщи- ки. Не разрешайте использовать персональные обогреватели в офисах и рабочих отсеках. Объясните пользователям, что эти обогреватели создают порочный круг, в котором система терморегуляции офиса и обогреватель борются друг с другом,
1154 Часть III. Разное преследуя противоположные цели. Если температура воздуха на рабочем месте пользователя действительно является некомфортной, поставьте этот вопрос перед группой обслуживания HVAC. (Возможно, в обмен на особые услуги в области ин- формационных технологий.) • Двусторонняя печать. По умолчанию настройте принтеры на двустороннюю печать, по две страницы на листе. Этого вполне достаточно для рутинных распечаток, и пользователи всегда могут выбрать другие настройки, если им понадобится иначе распечатать документы. • Электронные документы. Начните кампанию или проведите конкурс внутри вашей организации, чтобы найти способ исключить использование бумажных документов. • Температура в офисе. Поскольку компьютерное оборудование офиса предназначе- но для работы при значительно более высоких температурах, чем привыкли люди, поднимите уровень охлаждения в офисе до 27°С и выше. • Утилизация оборудования. Один-два раза в год проводите дни утилизации оборудо- вания, в течение которых сотрудники могут избавиться от нежелательного, ненуж- ного или слишком старого оборудования и сдать его компании, занимающейся утилизацией компьютеров. Если вас действительно беспокоит состояние окру- жающей среды, разрешите вашим сотрудникам принести для утилизации старые компьютеры из дома. • Продление сроков эксплуатации оборудования. Как только рабочая станция стала слишком старой или медленной, чтобы использовать ее для интенсивной работы, передайте ее сотрудникам, которых устроят ее характеристики. Они будут рады полу- чить новую технику, а у вас появится один-два дополнительных года эксплуатации. • Утилизация на рабочем месте. Начните программу утилизации использованной бу- маги на рабочем месте. Многие компании по переработке отходов, кроме бумаги, принимают пластик (пластиковые бутылки и т.д.). • Утилизация бумаги и картриджей. Станьте потребителем повторно используемых товаров. Покупайте для ваших принтеров и копировальных машин бумагу, изготов- ленную только из макулатуры, а также восстановленные картриджи. Рекомендуем универсальную и недорогую бумагу Boise Aspen 100, изготовленную из макулатуры и обладающую превосходными экологическими характеристиками. • Работа в дистанционном режиме. Стимулируйте сотрудников один-два дня в неделю работать дома в дистанционном режиме, установив и эксплуатируя средства дис- танционного доступа, такие как сеть VPN, служба VOIP и веб-приложения. Кроме выгоды для ваших сотрудников, работа в дистанционном режиме уменьшает на- грузку на транспорт и вспомогательные службы офиса. Однако примите меры, чтобы сотрудники, работающие в дистанционном режиме, выключили оборудова- ние, которое они в данный день не используют. В противном случае эта стратегия принесет обратный эффект, по крайней мере с точки зрения энергопотребления. 28.5. Компании, поддерживающие экологичные ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ Если вас интересует, кто еще разрабатывает экологичные информационные техноло- гии, вы можете найти и помощь единомышленников в разных организациях. Некоторые из них перечислены в табл. 28.2.
Глава 28. Экологичные информационные технологии 1155 Таблица 28.2. “Зеленая мафия” Организация Веб-сайт Energy Star ЕРЕАТ French Green IT energystar.gov epeat.net greenit.fr Green IT Observatory Green IT Promo Council Green Standards Trust IT Industry Council Less Watts The Green Grid greenit.bf.rmit.edu.au greenit-pc.jp greenstandards.org itic.org lesswatts.org thegreengrid.org Стандарты потребительской продукции Производство экологичной электроники Французский блог, посвященный экологичным ин- формационным технологиям Исследования в области экологичных информацион- ных технологий Экологичные информационные технологии для Японии и Азии Утилизация офисного оборудования Наилучшие стратегии для информационных техно- логий Экономия электроэнергии с помощью системы Linux Центры обработки данных Кроме экологических идей, многие из этих организаций имеют собственные наборы стандартных показателей, которые можно использовать для сравнения организаций по размерам и сферам деятельности. 28.6. Упражнения 28.1. С помощью электроизмерительного прибора Kill a Watt измерьте уровень потре- бления электроэнергии вашей рабочей станцией при разных уровнях нагрузки, включая спящий режим и режим пониженного энергопотребления. Сколько энер- гии можно сэкономить, если отключать вашу рабочую станцию каждый вечер? 28.2. Напишите сценарий, который будет посылать системному администратору элек- тронную почту, когда нагрузка центрального процессора достигнет уровня, при котором следует подключать новый сервер. 28.3. Создайте список основных приложений, используемых в вашей организации в на- стоящий момент. Какие из них дублируют друг друга? 28.4. Зайдите на сайт thegreengr id. org и определите, стоит ли для охлаждения ваше- го офиса использовать внешний воздух. 28.5. ★ Такие организации, как TerraPass и Carbonfund.org, продают “компенсаторы’ С02, с помощью которых организации могут возместить свои выбросы углекисло- го газа. Например, организации, осуществляющие компенсацию, могут субсиди- ровать разработку источников энергии, не связанной с выбросом углекислого газа (например, солнечной энергии или энергии ветра), чтобы снизить эмиссию этого газа в будущем. Эти программы оказались спорными. Некоторые наблюдатели сомневаются в реаль- ности заявленных целей, а другие критикуют программу с философских позиций.
1156 Часть III. Разное 28.6. Выберите поставщика компенсаторов и оцените целесообразность предлагаемой им стратегии. Хорошо ли документированы его программы, чтобы правильно оце- нить их качество?7 Оценила ли этого провайдера независимая группа, и если да, к каким выводам она пришла? 7 Разработчик из компании WorldPress Марк Жаке (Mark Jaquith) написал: “Представьте себе, что вас убили, а потом убийцу стали убеждать убить на одного человека меньше. Мы не должны вступать в переговоры с убийцами. Вас все равно убили. Убеждать кого-то сократить выбросы — совсем не значит, что ваши выбросы исчезнут”. Мы не разделяем это мнение, но такая точка зре- ния на вопросы компенсации является довольно типичной.
Глава Анализ производительности Анализ производительности и ее настройку часто относят к магической стороне си- стемного администрирования. Конечно же, магии здесь никакой нет, но можно гово- рить о симбиозе науки и искусства. “Научная” часть включает тщательное проведение количественных измерений и применение научного подхода. Составляющая “искусства” связана с необходимостью сохранять баланс ресурсов на практическом уровне, посколь- ку оптимизация для одного приложения или пользователя может отрицательно повли- ять на другие приложения или на других пользователей. Как это часто бывает в жизни, невозможно сделать счастливыми всех сразу. В блогосфере бытует мнение, что сегодня проблемы производительности кардиналь- но отличаются от аналогичных проблем предыдущих десятилетий. Но это не совсем так. Да, системы стали гораздо сложнее, но определяющие факторы производительности и высокоуровневые абстракции, используемые для ее измерения и управления, не ме- няются. К сожалению, повышение производительности систем сильно коррелирует со способностью соответствующего сообщества создавать новые приложения, которые по- глощают все доступные ресурсы. В этой главе мы сосредоточим внимание на производительности серверных систем. В настольных системах проблемы, характерные для серверов, обычно не возникают, поэтому ответ на вопрос о том, как повысить производительность настольной системы, обычно прост: “Провести модернизацию”. Пользователям такой ответ нравится, по- скольку это означает, что у них появятся новые модные системы. Одним из аспектов, отличающих UNIX и Linux от других основных операционных систем, является объем данных, которые они предоставляют о своих внутренних опера- циях. Детальная информация доступна буквально по каждому уровню системы, благода-
1158 Часть III. Разное ря чему администраторы могут настраивать различные параметры именно так, как нуж- но. Если установить источник проблем с производительностью никак не удается, всегда можно просмотреть исходный код. По этим причинам UNIX и Linux часто считаются наиболее подходящими операционными системами для пользователей, которых особен- но беспокоит тема производительности. Даже при этих условиях настройка производительности не является простой зада- чей. Как пользователи, так и администраторы часто думают, что если бы они владели нужными “магическими” приемами, их системы работали бы в два раза быстрее. Одним из наиболее распространенных заблуждений является убеждение в том, что настроить производительность может помочь манипулирование переменными ядра, которые от- вечают за управление системой страничного обмена и буферными пулами. В наши дни ядра основных дистрибутивов изначально настроены на достижение разумной (хотя и не оптимальной) производительности при различных уровнях загруженности. Если попытаться оптимизировать систему по какому-то конкретному показателю производительности (например, по степени использования буферов), весьма вероятно, что поведение системы ухудшится в отношении других показателей и режимов работы. В этой главе будет рассказываться о том, как можно настроить производительность на уровне системы; возможность рассказать о настройке производительности на уровне приложений мы оставили другим. Как системному администратору, вам необходимо помнить о том, что разработчики — тоже люди. (Сколько раз вы говорили или думали, что проблема кроется в сети?) При таком уровне сложности современных приложений некоторые проблемы можно решить только посредством сотрудничества их разработ- чиков, системных администраторов, проектировщиков серверов, администраторов баз данных, администраторов памяти и архитекторов сети. В этой главе мы поможем вам определить, какие данные следует предъявить этим специалистам, чтобы они смогли ре- шить проблемы производительности (если в действительности эти проблемы лежат в их области). Такой подход гораздо эффективнее, чем просто сказать: “Все выглядит пре- красно, это не моя проблема”. В любом случае, никогда не доверяйте полностью тому, что пишут в Интернете. Ка- кие только аргументы не приводятся в дискуссиях о производительности систем! При этом сторонники всевозможных теорий не обладают, как правило, ни знаниями, ни дис- циплиной, ни временем, необходимыми для проведения достоверных экспериментов. Широкая поддержка пользователей еще ничего не значит, ибо каждое глупое предложе- ние очень часто сопровождается хором восторженных комментариев: “Я увеличил раз- мер кеш-буфера в десять раз, как он предложил, и система заработала гораздо, гораздо быстрее!!!” Да уж, конечно! Ниже перечислены некоторые правила, которыми следует пользоваться. • Собирайте и анализируйте хронологические данные о работе системы. Если еще неделю назад производительность системы была нормальной, а сейчас все изме- нилось, то сравнение характеристик системы в двух состояниях позволит выявить источник проблемы. Всегда держите под рукой список оптимальных параметров производительности. А также первым делом просматривайте журнальные файлы, чтобы выяснить, не связана ли возникшая проблема с появлением какой-нибудь неполадки в оборудовании. • В главе 21 рассказывалось о некоторых средствах трендового анализа, которые также подходят для мониторинга производительности. Утилита sar, которая будет описываться чуть позже в этой главе, тоже может использоваться в качестве сред- ства трендового анализа.
Глава 29. Анализ производительности 1159 • Всегда настраивайте систему так, чтобы потом иметь возможность сравнить ре- зультаты с предыдущими показателями производительности системы. • Всегда проверяйте наличие плана отката на случай, если внесенные “чудодействен- ные” изменения окажутся вовсе не чудодейственными и лишь только ухудшат дело. • Не перегружайте умышленно свои системы или свою сеть. Ядро создает для каж- дого процесса иллюзию бесконечности ресурсов. Но как только в дело вступают все 100% ресурсов системы, операционной системе приходится работать очень напряженно. На поддержку иллюзии расходуется ощутимая доля самих ресурсов. В результате выполнение процессов замедляется. • Как в физике элементарных частиц, чем больше данных вы собираете с помощью утилит мониторинга системы, тем большее влияние вы оказываете на исследуемую систему. Для наблюдения за системой лучше всего полагаться на простые инстру- менты, которые работают в фоновом режиме (например, sar или vmstat). Если они обнаружат что-то существенное, то для более глубокого анализа можете вос- пользоваться и другими инструментами. 29.1. Способы повышения производительности Ниже перечислены конкретные действия, которые можно выполнить, чтобы улуч- шить производительность. • Убедиться в том, что память доступна в достаточном объеме. В следующем раз- деле вы увидите, что объем памяти очень сильно влияет на производительность. Устройства памяти сегодня стоят довольно недорого, так что обычно оснастить по максимуму любой компьютер, от которого требуется высокая производитель- ность, — не проблема. • Если UNIX- или Linux-система используется в качестве веб-сервера или сетевого сервера приложений, можно попробовать распределить трафик между нескольки- ми компьютерами с помощью какого-нибудь коммерческого приложения для ба- лансирования нагрузки, такого как Content Services Switch производства компании Cisco (cisco. com), Serverlron производства компании Brocade (brocade. com) или Alteon Web Switch производства компании Nortel (nortelnetworks. com). • Эти устройства делают так, что несколько физических серверов выглядят для внеш- него мира как один логический сервер. Они распределяют нагрузку согласно од- ному из нескольких выбираемых пользователем алгоритмов типа “минимальное время отклика” или “циклический алгоритм обслуживания”. • Тщательно проверить конфигурацию системы и отдельных приложений. Многие приложения могут резко увеличить производительность, если их правильно на- строить (распределить данные между дисками, не осуществлять динамический по- иск имен в DNS, запустить дополнительные экземпляры сервера и т.д.). • Устранить проблемы, связанные с использованием ресурсов. Проблемы могут соз- даваться как “реальными заданиями” (одновременный запуск слишком большого количества серверов, неэффективные методы программирования, выполнение па- кетов заданий с завышенным приоритетом, запуск ресурсоемких программ в не- подходящее время), так и самой системой (ненужные демоны). • Ликвидировать по возможности зависимость ресурсов памяти от механических операций. В настоящее время широко доступны полупроводниковые диски (Solid
1160 Часть III. Разно# state disk drives — SSDs), которые могут обеспечить быстрый рост производитель- ности, поскольку они не требуют физического движения диска для считывания битов информации. SSD-диски легко устанавливаются вместо “старых добрых” дисковых накопителей1. • Организовать жесткие диски и файловые системы так, чтобы нагрузка на них бы- ла равномерной, и тем самым максимально повысить пропускную способность каналов ввода-вывода. При наличии специфических приложений, таких как базы данных, можно попробовать использовать какую-нибудь модную многодисковую технологию вроде RAID для оптимизации процессов обмена данными. За реко- • мендациями следует обращаться к производителю базы данных. Для систем Linux | нужно удостовериться в том, что для диска выбран самый подходящий из доступ-; ных в Linux планировщик ввода-вывода. 1 • Обратить внимание на то, что разные приложения и СУБД ведут себя по-разному при размещении на нескольких дисках. Технология RAID поставляется в несколь- ких вариантах, поэтому следует потратить время и выяснить, какой из них лучше всего подходит для данного конкретного случая (если вообще подходит). • Провести мониторинг сети, чтобы убедиться в том, что она не перегружена тра* ! фиком и что количество ошибок в ней минимально. Очень много такой полезной < информации о сети можно собрать с помощью команды netstat, которая описы- валась в разделе 21.5. Также можно еще раз перечитать главу 21. $ • Определить ситуации, в которых система совершенно не удовлетворяет предъяв- ; ляемым к ней требованиям. Нельзя настраивать производительность без учета та- ких ситуаций. л Эти меры перечислены в порядке убывания эффективности. Добавление памяти и распределение трафика между несколькими серверами может значительно повысить ’ производительность. Степень эффективности остальных мер варьируется от значитель- : ной до нулевой. ’ Анализ и оптимизация структур данных и алгоритмов программ почти всегда ведет к существенному повышению производительности. Однако эти вопросы обычно находят- ся вне компетенции системного администратора. 29.2. Факторы, влияющие на производительность Производительность системы во многом определяется базовыми характеристиками системных ресурсов и эффективностью их распределения и совместного использования. Определение термина “ресурс” весьма расплывчато. Оно может подразумевать даже та- кие компоненты, как кеш содержимого регистров центрального процессора и элементы таблицы адресов контроллера памяти. Однако в первом приближении серьезное влия- ние на производительность оказывают только четыре фактора: • время использования центрального процессора; • память; 1 У современных SSD-дисков есть два основных недостатка. Во-первых, они на порядок до- роже (в расчете на гигабайт), чем традиционные жесткие диски. Во-вторых, их можно перезапи- сывать только ограниченное число раз. Их перезаписывающая способность достаточно высока и вполне приемлема для настольных компьютеров (десятки тысяч записей на блок), но может ока- заться потенциальным камнем преткновения для сервера с большой рабочей нагрузкой. Подробнее о SSD-дисках см. в разделе 8.2.
Глава 29. Анализ производительности 1161 • пропускная способность дисковой подсистемы ввода-вывода; • пропускная способность сетевой подсистемы ввода-вывода. Если после выполнения активных процессов остались свободные ресурсы, можно считать, что производительность системы является удовлетворительной. Когда ресурсов не хватает, процессы становятся в очередь. Процесс, не имеющий не- медленного доступа к необходимым ресурсам, должен ждать, ничего при этом не делая. Время, затрачиваемое на ожидание ресурсов, — один из основных показателей ухудше- ния производительности. Самый простой, с точки зрения учета, ресурс — использование центрального про- цессора (ЦП). В распоряжении системы всегда имеется примерно одна и та же часть его мощности. Теоретически эта величина составляет все 100% циклов ЦП, но “наклад- ные расходы” и другие причины приводят к снижению этого показателя примерно до 95%. Для процесса, занимающего более 90% времени ЦП, ограничивающим фактором является быстродействие центрального процессора. Такой процесс потребляет большую часть вычислительных мощностей системы. Многие считают, что быстродействие ЦП — основной фактор, влияющий на общую производительность системы. При наличии неограниченных объемов всех остальных ре- сурсов или для определенных типов приложений (например, программ численного мо- делирования) быстродействие ЦП действительно играет роль. Но в повседневной жизни этот показатель значит относительно мало. Настоящим узким местом является канал обмена данными с жестким диском. Жест- кие диски представляют собой механические системы, поэтому на поиск нужного бло- ка, выборку его содержимого и активизацию ожидающего его процесса уходят десятки миллисекунд. Задержки такого порядка отодвигают на второй план все остальные факто- ры ухудшения производительности. Каждое обращение к диску вызывает приостановку активного процесса “стоимостью” несколько миллионов инструкций ЦП. Эту проблему можно решить, например, с помощью полупроводниковых дисковых накопителей, ко- торые работают значительно быстрее, чем диски с движущимися деталями. Благодаря использованию виртуальной памяти, скорость дискового обмена может быть непосредственно связана с объемом имеющейся памяти, если потребность в физи- ческой памяти превышает ее реальный объем. Ситуации, в которых физической памяти становится недостаточно, часто приводят к необходимости записывать содержимое ее страниц на диск, чтобы эти страницы можно было восстановить и использовать для дру- гой цели. Это означает, что обращение к памяти по своей “стоимости” приближается к работе с диском. Избегайте таких ловушек, если характеристики производительности имеют для вас большое значение; побеспокойтесь о том, чтобы каждая система имела достаточно физической памяти. Пропускная способность сети подвержена примерно тем же ограничениям, что и скорость дискового обмена. Ее ухудшение связано со всевозможными задержками. Но возникающие проблемы охватывают целые сообщества пользователей, а не отдельные компьютеры. Кроме того, сети восприимчивы к проблемам аппаратного обеспечения и перегрузкам серверов. 29.3. Как анализировать проблемы ПРОИЗВОДИТЕЛЬНОСТИ В сложной системе нелегко выделить именно проблемы производительности. Сис- темные администраторы часто получают частные (несистематические) отчеты о пробле-
1162 Часть III. Разное мах, которые содержат эмоциональные описания конкретных случаев или сложных ситуа- ций (например, “веб-сервер застопорился из-за всех этих проклятых AJAX-вызовов...”). Вы, конечно, должны обратить внимание на эту информацию, но не воспринимайте ее как достоверную и надежную; проводите собственное исследование. Строгая и прозрачная научная методика поможет вам сделать правильные выводы, которым ваши сотрудники и вы сами можете доверять. Научный подход позволит дру- гим оценить ваши результаты, повысит доверие к вашей работе и увеличит вероятность того, что предлагаемые вами изменения смогут реально решить проблему. Применение научного подхода не означает, что вы должны собирать все релевантные данные сами. Весьма полезной бывает и “внешняя” информация. Не стоит тратить часы на изучение вопросов, ответы на которые можно легко почерпнуть из разделов FAQ (Frequently Asked Questions — часто задаваемые вопросы). Мы предлагаем вам выполнить следующие пять действий. Шаг 1. Сформулируйте вопрос. Поставьте конкретный вопрос в определенной функциональной области или сфор- мулируйте предварительное заключение или рекомендацию, которую вы обдумали. Будь- те точны, говоря о технологиях, компонентах и альтернативах, которые вы предлагаете рассмотреть, и результатах, которые могут быть достигнуты. Шаг 2. Соберите и классифицируйте факты. Проведите систематический поиск в документации, базах знаний, известных вам из- даниях, блогах, технических описаниях, форумах и прочих информационных ресурсах с целью выявления внешних фактов, имеющих отношение к вашему вопросу. В собствен- ных системах зафиксируйте телеметрические данные и (по возможности или необходи- мости) оснастите инструментальными средствами конкретные интересующие вас обла- сти в системе или отдельных приложениях. Шаг 3. Критически оцените данные. Просмотрите каждый источник данных на предмет релевантности и критически оце- ните его с точки зрения достоверности. Выделите ключевые данные и обратите внима- ние на качество источников информации. ~ Шаг 4. Подытожьте данные вербально и графически. Представьте сведения, взятые из нескольких источников, в словесной (вербальной^ по возможности графической форме. Данные, кажущиеся сомнительными при выражвт нии в числовой форме, могут оказаться убедительными в виде диаграммы. Шаг 5. Сформулируйте заключение. Представьте свои выводы в лаконичной форме (как ответ на поставленный вами же вопрос). Поставьте оценку, чтобы обозначить уровень силы или слабости доказательств, которые поддерживают ваши заключения. 29.4. Проверка производительности системы Хватит обобщать — пора рассмотреть некоторые конкретные инструменты и “зоны интереса”. Прежде чем переходить к измерениям, необходимо знать, что именно вы хо- тите получить. Инвентаризуйте свое оборудование Начните с оценки своего оборудования, особенно ЦП и ресурсов памяти. Инвен- таризация поможет вам интерпретировать данные, представленные с помощью других
Глава 29. Анализ производительности 1163 инструментов, а также построить реалистичные ожидания касательно верхних границ производительности. В системах Linux именно в файловой системе /ргос стоит искать ответ на вопрос, какое, с точки зрения вашей операционной системы, вы используе- те оборудование (более детальную информацию об аппаратуре можно найти в каталоге /sys; см. раздел 13.8). Некоторые ключевые файлы перечислены в табл. 29.1. Общую информацию о файловой системе /ргос можно найти в разделе 13.3. Таблица 29.1. Источники информации об оборудовании в системах Linux Файл Содержимое /proc/cpuinfo Тип и описание ЦП /proc/meminfo Размер памяти и коэффициент загрузки /ргос/diskstats Дисковые устройства и статистика их использования Четыре строки в файле /proc/cpuinfo помогут вам идентифицировать ЦП в си- стеме: vendor_id, cpu family, model, и model name. Некоторые из этих значений не- понятны, поэтому лучше всего узнать о них в интерактивной справочной системе. Точная информация, содержащаяся в файле /proc/cpuinfo, зависит от системы и процессора. Рассмотрим типичный пример содержимого этого файла. suse$ cat /proc/cpuinfo processor : 0 vendor__id : Genuinelntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPUE53100 1.60GHz stepping : 11 cpu MHz : 1600.003 cache size : 4096 KB physical id : 0 cpu cores : 2 siblings : 2 Этот файл содержит по одной записи для каждого процессорного ядра, видимого операционной системой. Конкретные данные незначительно варьируются в зависимости от версии ядра. Значение поля processor уникально идентифицирует ядро. Значения поля physical id являются уникальными для каждого физического сокета на печатной плате, а значения id values уникальны для ядра в физическом сокете. Ядра, которые поддерживают гиперпотоковый режим работы (дублирование контекстов ЦП без ду- блирования других характеристик обработки), идентифицируются значением ht в поле flags. Если в системе действительно реализован гиперпотоковый режим работы, поле siblings для каждого ядра показывает, сколько контекстов доступно на данном ядре. Существует еще одна команда, которая позволяет получить информацию об аппарат- ных характеристиках вашего компьютера. Речь идет о команде dmidecode. Она выводит содержимое системной таблицы DMI (Desktop Management Interface — интерфейс управ- ления настольными системами), также известной под именем SMBIOS. Самой полезной опцией этой команды является -t тип (допустимые типы представлены в табл. 29.2).
1164 Часть III. Разное Таблица 29.2. Значения типов для команды dmidecode -t Значение ' Описание Ч УГ - 1 ---- ' ' ......*....................................... — 1 Система 2 Материнская плата 3 Корпус 4 Процессор 7 Кеш-память 8 Разъемы портов 9 Системные разъемы 11 ОЕМ-строки 12 Опции системной конфигурации 13 Язык BIOS 16 Массив физической памяти 17 Устройство памяти 19 Отображаемый адрес массива памяти 32 Загрузка системы 38 1РМ1-устройство Следующий пример демонстрирует получение типичной информации. suse$ sudo dmidecode -t 4 # dmidecode 2.7 SMBIOS 2.2 present. Handle 0x0004, DMI type 4, 32 bytes. Processor Information Socket Designation: PGA 370 Type: Central Processor Family: Celeron Manufacturer: Genuinelntel ID: 65 06 00 00 FF F9 83 01 Signature: Type 0, Family 6, Model 6, Stepping 5 Биты информации о сетевой конфигурации разбросаны “по всей системе”. Лучшим источником IP- и МАС-информации для каждого сконфигурированного интерфейса служит команда ifconfig -а. В системах Solaris лучшим источником информации о ЦП и ресурсах памяти sotaris являются команды psrinfo -v и prtconf соответственно. Вот пример ре- зультата выполнения этих команд. solaris$ psrinfo -v Status of virtual processor 0 as of: 01/31/2010 21:22:00 on-line since 07/13/2009 15:55:48. The sparcv9 processor operates at 1200 MHz, and has a sparcv9 floating point processor. Status of virtual processor 1 as of: 01/31/2010 21:22:00 on-line since 07/13/2009 15:55:49. The sparcv9 processor operates at 1200 MHz, and has a sparcv9 floating point processor.
Глава 29. Анализ производительности 1165 Solaris$ prtconf System Configuration: Sun Microsystems sun4v Memory size: 32640 Megabytes System Peripherals (Software Nodes): SUNW,Sun-Fire-T200 В системах HP-UX информацию о конфигурации аппаратных средств компью- тера можно получить с помощью одной-единственной команды machinf о. Вот типичный пример ее выполнения. hp-ux$ sudo machinfо CPU info: 1 Intel(R) Itanium 2 processor (1.5 GHz, 6 MB) 400 MT/s bus, CPU version Bl Memory: 4084 MB (3.99 GB) Firmware info: Firmware revision: 02.21 FP SWA driver revision: 1.18 BMC firmware revision: 1.50 Platform info: Model: "ia64 hp server rx2600" OS info: Nodename: hpuxll Release: HP-UX B.11.31 Machine: ia64 • В системах AIX для получения информации о ЦП и памяти придется выпол- нить несколько действий. Сначала с помощью команды Iscf g найдите имена инсталлированных процессоров. aix$ Iscfg | grep Processor + procO Processor + proc2 Processor Затем для получения описания каждого процессора можно использовать команду Isattr. aix$ Isattr -Е -1 ргосО frequency 1898100000 Processor Speed False smt_enabled true Processor SMT enabled False smt_threads 2 Processor SMT threads False state enable Processor state False type Powe г PC_POWER5 Processor type False С помощью команды Isattr можно также узнать объем физической памяти в си- стеме. aix$ Isattr -Е -1 sysO -a realmem realmem 4014080 Amount of usable physical memory in Kbytes
1166 Часть III. Разное Сбор данных о производительности Программы анализа производительности в большинстве своем сообщают о том, что происходит в системе в данный момент времени. Но следует учесть, что структу- ра и характер нагрузки меняются в течение дня. Поэтому до принятия мер обязательно проведите всесторонний анализ данных, касающихся производительности. Истинная производительность выясняется только после длительного (месяц или даже больше) на- блюдения за системой. Особенно важно собирать данные в периоды пиковой загружен- ности системы. Ограничения на использование ресурсов и ошибки в конфигурации си- стемы часто выявляются только в таких условиях. Анализ использования центрального процессора Обычно собирают три вида данных о центральном процессоре: общий показатель использования, показатели средней загруженности и потребление ресурсов отдельны- ми процессами. Первая характеристика определяет, является ли быстродействие самого процессора узким местом. Показатели средней загруженности дают возможность оце- нить общую производительность системы. Данные, касающиеся отдельных процессов, позволяют выявить наиболее ресурсоемкие процессы. Сводную информацию выдает команда vmstat. Она принимает два аргумента: вре- мя (в секундах), в течение которого необходимо наблюдать за системой для получения каждой строки выходной информации, и необходимое количество отчетов. Если не ука- зать число отчетов, команда будет выполняться до тех пор, пока пользователь не нажмет комбинацию клавиш <Ctrl+C>. В первой строке отображаемых данных сообщаются средние значения, измеренные с момента запуска системы. В последующих строках выдаются результаты по каждому очередному замеру, стандартная продолжительность которого составляет пять секунд. $ vmstat 5 5 procs — -memory— — -swap- - —io— -system— — —cpu— — г Ь swpd free buff cache si so bi bo in cs us sy id wa 1 0 820 2606356 428776 487092 0 0 4741 65 1063 4857 25 1 73 0 1 0 820 2570324 428812 510196 0 0 4613 11 1054 4732 25 1 74 0 1 0 820 2539028 428852 535636 0 0 5099 13 1057 5219 90 1 9 0 1 0 820 2472340 428920 581588 0 0 4536 10 1056 4686 87 3 10 0 3 0 820 2440276 428960 605728 0 0 4818 21 1060 4943 20 3 77 0 Несмотря на то что содержимое этих колонок может не совпадать в разных системах, статистические данные показателей использования ЦП практически не различаются среди платформ. Пользовательское время, системное время (время ядра), время простоя и время ожидания для каналов ввода-вывода (I/O) показаны в колонках us, sy, id и wa соответственно. Большие числа в колонке us обычно означают вычисления, а в колонке sy они свидетельствуют о том, что процессы осуществляют очень много системных вы- зовов или выполняют операции ввода-вывода. Выработанное нами за многие годы эмпирическое правило для серверов общего на- значения, справедливое для большинства систем, гласит следующее: система должна тратить примерно 50% рабочего времени на обслуживание пользовательских запросов и столько же на системные запросы. Общее время простоя не должно быть нулевым. Если сервер выделяется под одно единственное, но интенсивно использующее ЦП приложе- ние, большая часть времени должна тратиться на обработку пользовательских запросов.
Глава 29. Анализ производительности 1167 В колонке cs показано число переключений контекста за данный период, т.е. сколь- ко раз ядро переключало процессы. В колонке in отображается число прерываний, ге- нерируемых аппаратными устройствами или компонентами ядра. Слишком большие значения в этих колонках свидетельствуют о неправильно работающем аппаратном устройстве. Остальные колонки важны для анализа использования памяти и жесткого диска, о чем будет рассказываться позже в этой главе. Длительные измерения показателей, характеризующих работу центрального процес- сора, позволяют определить, достаточно ли его ресурсов для нормальной работы систе- мы. Если процессор регулярно часть времени простаивает, значит, есть запас по такто- вой частоте. В этом случае увеличение быстродействия процессора ненамного улучшит общую производительность системы, хотя может и ускорить выполнение отдельных операций. Как видно из показанного примера, центральный процессор постоянно переключа- ется из режима интенсивного использования в режим полного бездействия и обратно. Поэтому необходимо наблюдать за показателями, соответствующими обоим режимам, и выводить среднее за определенный период времени. Чем меньше интервал наблюдения, тем ниже достоверность оценок. В мультипроцессорных системах команды вроде vmstat сообщают средние значе- ния по всем процессорам. Но существует и команда xnpstat, которая выдает отчет по каждому процессору. В системах Linux, Solaris и AIX с помощью флага -Р можно вы- брать один конкретный процессор. Этой командой удобно пользоваться при отладке программ, поддерживающих симметричную многопроцессорную обработку. Интересно также узнать, насколько система эффективно (или неэффективно) работает с несколь- кими процессорами. Рассмотрим пример отображения статуса каждого из четырех процессоров. linux$ mpstat -₽ ALL 08:13:38 PM CPU %user 08:13:38 PM 0 1.02 08:13:38 PM 1 0.28 08:13:38 PM 2 0.42 08:13:38 PM 3 0.38 %nice %sys %iowait %irq %soft %idle intr/s 0.00 0.49 1.29 0.04 0.38 96.79 473.93 0.00 0.22 0.71 0.00 0.01 98.76 232.86 0.00 0.36 1.32 0.00 0.05 97.84 293.85 0.00 0.30 0.94 0.01 0.05 98.32 295.02 Центральный процессор однопользовательской рабочей станции обычно простаива- ет большую часть времени. Когда запрашивается прокрутка содержимого окна или об- новляется веб-страница, ЦП справляется с этой операцией за считанные секунды. В та- кой ситуации долгосрочный средний показатель использования ЦП практически лишен смысла. Еще одним статистическим показателем, полезным для оценки интенсивности ис- пользования системы, является показатель “средняя загруженность”, который представ- ляет собой среднее количество выполняемых процессов. Он дает достаточное представ- ление о том, сколько процессов требуют свою долю процессорного времени. Узнать его значение можно с помощью команды uptime. $ uptime 11:10am up 34 days, 18:42, 5 users, load average: 0.95, 0.38, 0.31 Выдаются три значения, которые соответствуют средней загруженности за пять, де- сять и пятнадцать минут. Как правило, чем выше средняя загруженность, тем важнее общая производительность системы. Если выполняется всего лишь один процесс, то он обычно ограничен одним ресурсом (центральным процессором или пропускной способ-
1168 Часть III. Разное ностью дискового канала ввода-вывода). Пиковый спрос на этот ресурс и становится определяющим фактором производительности. Когда в системе одновременно работает несколько процессов, нагрузка распределя- ется более равномерно. Если все работающие процессы потребляют ресурсы ЦП, диска и памяти, то зависимость производительности системы от ограниченных возможностей какого-то одного ресурса снижается. В такой ситуации гораздо важнее следить за сред- ними показателями загруженности, в частности за общим временем использования цен- трального процессора. Ш О приоритетах рассказывалось в конце раздела 5.1. Обычно в однопроцессорных системах значение 3 показателя средней загруженности свидетельствует о сильной загруженности системы, а значение 8 и выше — считается критическим. Такие значения являются сигналом о том, что пора начать поиск путей искусственного перераспределения нагрузки, например назначить процессам приорите- ты с помощью команды nice. Показатель средней загруженности отлично подходит для повседневного контроля системы. Если известен показатель работающей системы и он находится в диапазоне, характерном для перегрузки, значит, следует искать внешний источник проблемы (это может быть, к примеру, сеть). В противном случае нужно проверить процессы самой си- стемы. Еще один способ контроля над использованием ЦП — посмотреть, какую часть его времени отнимает каждый процесс. Для этого служит команда ps с аргументами (-aux — в системах Linux и AIX; -elf — в системах HP-UX и Solaris). Зачастую в ин- тенсивно эксплуатируемой системе минимум 70% времени ЦП отнимается одним-двумя процессами. Запуск таких процессов в другое время суток или снижение их приоритетов позволит высвободить ЦП для выполнения других процессов. Ш Подробнее об утилите top рассказывалось в разделе 5.8. Прекрасной альтернативой команде ps является утилита top. Она выдает примерно туже информацию, что и ps, но в “живом”, постоянно обновляемом формате, позволяв ющем наблюдать за изменением состояния системы во времени2. В системе AIX можно^ воспользоваться даже более эффективной командой topas. < В виртуализированных системах ps, top и другие команды, которые отображай^ данные о показателях использования ЦП, могут вводить в заблуждение. Виртуальной машина, которая не использует все виртуальные циклы своего центрального процессору позволяет другим виртуальным машинам использовать (заимствовать) эти циклы. Любой измерение, которое имеет отношение к операционной системе (например, количество “тиков” системных часов в секунду), должно быть вами тщательно проанализировано, чтобы вы до конца понимали результаты своих измерений. О различных технологиях виртуализации можно подробнее см. в главе 24. Управление памятью в системе В UNIX- и Linux-системах память организована в виде модулей, называемых стра- ницами, размер которых составляет 4 Кбайт или больше. Когда процессы запрашивают у операционной системы память, ядро выделяет им виртуальные страницы. Каждой такой странице соответствует настоящее физическое хранилище, такое как ОЗУ или “резерв- 2 Утилита top потребляет довольно много ресурсов, поэтому пользуйтесь ею в разумных преде- лах.
29. Анализ производительности 1169 ное ЗУ” на жестком диске. (Резервное ЗУ обычно представляет собой просто простран- ство в области подкачки, но для страниц, которые содержат текст исполняемой програм- мы, резервное ЗУ — это самый настоящий исполняемый файл. Аналогично резервное ЗУ для некоторых файлов данных может представлять собой сами файлы.) Информация о связях между виртуальными и реальными страницами хранится в таблице страниц. Ядро способно эффективно обслуживать запросы процессов, выделяя для них столь- ко памяти, сколько им нужно. Это реализуется дополнением реального ОЗУ областью подкачки. Поскольку процессы ожидают, что их виртуальные страницы будут отобра- жаться в реальной памяти, ядру постоянно приходится перемещать страницы между ОЗУ и областью подкачки. Такие операции называются страничным обменом (paging)3. Ядро старается управлять памятью так, чтобы страницы, к которым недавно обра- щались, хранились в физической памяти, а менее активные страницы выгружались на диск. Этот алгоритм известен под названием LRU (least recently used — замещение наи- менее используемых элементов), поскольку те страницы, к которым долго никто не об- ращался, перемещаются на диск. Впрочем, отслеживать все обращения к страницам было бы слишком накладно для ядра, поэтому оно использует страничный кеш-буфер, анализ содержимого которого и позволяет принять решение о том, какие именно страницы оставить в памяти. Точный алгоритм этого механизма зависит от конкретной системы, но везде действует примерно одинаковый принцип. Такой вариант гораздо проще в реализации, чем LRU-система, а результаты дает почти такие же. В случае нехватки памяти ядро пытается определить, какие страницы из “неактив- ного” списка давно не использовались. Если при последнем обращении такие страницы модифицировались процессом, ядро считает их “грязными”; они обязательно должны быть выгружены на диск, прежде чем память будет повторно использована. Все осталь- ные страницы считаются “чистыми” и могут быть переданы другому процессу. Когда выполняется обращение к странице из “неактивного” списка, ядро возвра- щает ссылку на нее в таблицу страниц, обнуляет ее “возраст” и переводит страницу из “неактивного” списка в “активный”. Страницы, выгруженные на диск, должны быть прочитаны с диска, прежде чем их можно будет активизировать. Когда процесс обра- щается к неактивной странице, находящейся в памяти, происходит сбой программной страницы (это так называемая “мягкая ошибка”). В случае обращения к нерезидентной (выгруженной) странице имеет место отказ страницы диска (а это уже “жесткая ошиб- ка”). Другими словами, при возникновении ошибки второго типа (в отличие от первого) требуется прочитать страницу с диска. Ядро старается прогнозировать потребности системы в памяти, поэтому операции выделения и выгрузки страниц не обязательно взаимосвязаны. Цель системы — обеспе- чить наличие достаточного объема свободной памяти, чтобы процессам не приходилось ждать выгрузки страниц всякий раз, когда им нужна свободная память. Если в периоды сильной загруженности системы страничный обмен резко возрастает, имеет смысл ку- пить дополнительную память. Д Система Linux по-прежнему быстро эволюционирует, и ее система виртуаль- ной памяти продолжает развиваться, причем несколько неровно и даже неу- клюже. Можно настроить параметр “подкачки” (/ргос/sys/vm/swappiness) и тем самым дать ядру подсказку о том, насколько быстро оно должно делать 3 Когда-то имела место иная операция, именуемая подкачкой (или свопингом), посредством которой все страницы некоторого процесса одновременно переписывались на диск. Теперь же во всех случаях обязательно используется страничный обмен (paging).
1170 Часть III. Разное страницы пригодными для возврата из процесса в случае нехватки памяти. По умолчанию для этого параметра устанавливается значение 60. Если для него установить значение 0, ядро будет забирать страницы, которые были назна- чены процессу, только тогда, когда испробует все остальные возможности. Если для него установить значение 60 или выше (максимальным значением является 100), ядро, скорее всего, будет забирать страницы из процесса. Если возникает желание изменить этот параметр, значит, возможно, пришла пора увеличить ОЗУ. Когда ядру не хватает как физической памяти, так и области подкачки, это означа- ет, что виртуальная память исчерпана. В данной ситуации включается режим “прину- дительного уничтожения”. Чтобы освободить память, системе приходится уничтожать целые процессы. И хотя выбираются наименее важные для системы процессы, все равно это очень неприятная процедура, ведь значительная часть ресурсов системы тратится не на полезную работу, а на управление памятью. Анализ использования памяти Интенсивность операций с памятью количественно представляется двумя показа- телями: общим объемом задействованной виртуальной памяти и страничного обмена. Первый показатель характеризует общую потребность в памяти, а второй указывает на то, какая доля этой памяти активно используется. Задача администратора заключается в снижении интенсивности использования или увеличении объема памяти до тех пор, пока не будет достигнут приемлемый уровень страничного обмена. Страничный об- мен — процесс неизбежный, поэтому не пытайтесь полностью избавиться от него. У вас есть возможность определить размер текущей области подкачки. Для этого в Linux выполните команду swapon -s, в Solaris и AIX—команду swap -1, а в HP-UX — команду swapinfo. linux$ swapon -s Filename Type Size Used Priority /dev/hdbl partition 4096532 0 -1 /dev/hda2 partition 4096564 0 -2 solaris$ swap -1 swapfile dev swapl blocks free /dev/dsk/c0t0d0sl 32,1 16 164400 162960 hp-ux$ swapinfo Kb Kb Kb PCT START/ Kb TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME dev 8388608 0 8388608 0% 0 1 /dev/vg00/lvol При выполнении команд swapinfo и swapon значения выводятся в килобайтах, а команда swap -1 использует 512-байтовые дисковые блоки. Значения размеров, выво- димые этими командами, не включают содержимое памяти ядра, поэтому вам придется вычислить общий объем виртуальной памяти самостоятельно. VM = ОЗУ + используемый_объем_области__подкачки В системах UNIX вывод статистических показателей страничного обмена, получен- ных с помощью команды vmstat, подобен результату выполнения команды в системе Solaris. solaris$ vmstat 5 5 procs memory page disk faults
Глава 29. Анализ производительности 1171 г b w swap free re mf Pi po fr de sr sO s6 s4 — in sy cs 0 0 0 338216 10384 0 3 1 0 0 0 0 0 0 0 0 132 101 58 0 0 0 341784 11064 0 26 1 1 1 0 0 0 0 10 150 215 100 0 0 0 351752 12968 1 69 0 9 9 0 0 0 0 2 0 173 358 156 0 0 0 360240 14520 0 30 6 0 0 0 0 0 0 10 138 176 71 1 0 0 366648 15712 0 73 0 8 4 0 0 0 0 36 0 390 474 237 Из этого примера удалена информация об использовании центрального процессора. Под заголовком procs показано количество процессов, готовых к немедленному вы- полнению, заблокированных в ожидании ввода-вывода, а также готовых к выполнению, но перекачанных на диск. Если значение в колонке w когда-нибудь станет отличным от нуля, это будет означать, что объем системной памяти не соответствует текущей на- грузке. Колонки, объединенные под общим заголовком раде, содержат данные о выполне- нии страничного обмена. Во всех этих колонках представлены средние значения: коли- чество в секунду (табл. 29.3). В колонке swap выдается объем доступной виртуальной памяти в килобайтах. В ко- лонке free отображается объем (в килобайтах) списка неиспользуемых страниц систе- мы. Если приведенные в ней числа не достигают 3% от общего объема системной памя- ти, это говорит о наличии проблем. Таблица 29.3. Описание статистических показателей, выводимых командой vmstat Колонка ' 0писайиегюказате|й / - re Количество восстановленных страниц, т.е. возвращенных из списка неиспользуемых mf Количество незначительных ошибок (связанных с небольшим числом страниц) Pi Объем подкачанных данных в килобайтах PO fr Объем выгруженных данных в килобайтах Объем списка неиспользуемых страниц в килобайтах de Объем “ожидаемого краткосрочного дефицита памяти” в килобайтах sr Количество страниц, обработанных по алгоритму часов Содержимое колонки de — самый надежный показатель возникновения серьезных проблем с памятью. Если находящееся в ней число зачастую “зашкаливает” за 100, это значит, что компьютеру нужно больше памяти. К сожалению, во многих версиях коман- ды vmstat это значение не выводится. В системах Linux статистические показатели, получаемые с помощью команды vmstat, могут иметь следующий вид. linux$ vmstat 5 5 procs memory -swap- io— -system- CpU г b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 66488 40328 597972 0 0 252 45 1042 278 3 4 93 1 0 0 0 0 66364 40336 597972 0 0 0 37 1009 264 0 1 98 0 0 0 0 0 66364 40344 597972 0 0 0 5 1011 252 1 1 98 0 0 0 0 0 66364 40352 597972 0 0 0 3 1020 311 1 1 98 0 0 0 0 0 66364 40360 597972 0 0 0 21 1067 507 1 3 96 0 0 Как и в результате выполнения команды vmstat при использовании системы UNIX, количество процессов, готовых к немедленному выполнению и заблокированных в ожидании ввода-вывода, выводится под заголовком procs. Статистические показатели
1172 Часть III. Разное страничного обмена ограничены двумя колонками: si и so, которые представляют ко- личество подкачанных и выгруженных страниц соответственно. Кажущиеся несоответствия между колонками, большей частью, иллюзорны. В одних колонках указывается число страниц, в других — объем в килобайтах. Все значения яв- ляются округленными средними величинами. Более того, одни из них — средние ска- лярных величин, а другие — средние изменений. С помощью полей si и so можно оценить интенсивность страничного обмена в си- стеме. Операция загрузки (поле si) не обязательно означает, что из области подкачки восстанавливается страница. Это может быть исполняемый код, постранично загружае- мый из файловой системы, или копия страницы, создаваемая в режиме дублирования при записи. Оба случая вполне типичны и не обязательно означают нехватку памяти. С другой стороны, операция выгрузки (поле so) всегда означает принудительное изъя- тие данных ядром. Система, в которой непрерывно происходят операции выгрузки, скорее всего, выи- грает от добавления памяти. Если же это случается лишь время от времени и не вызы- вает жалоб со стороны пользователей, то можно не беспокоиться. В остальных случаях дальнейший анализ будет зависеть от того, что нужно сделать, — оптимизировать систе- му для интерактивного режима (например, как рабочую станцию) или сконфигуриро- вать ее для одновременной работы пользователей (например, как сервер приложений). При использовании обычного жесткого диска можно считать, что каждые 100 опе- раций выгрузки создают задержку примерно в одну секунду4. Соответственно, если для прокрутки окна требуется 150 операций выгрузки, придется ждать около полутора се- кунды. Исследователи пользовательских интерфейсов утверждают, что среднестатисти- ческий пользователь считает систему “медленной”, когда время ее реакции превышает семь десятых секунды. Анализ операций обмена с диском Производительность жесткого диска можно контролировать с помощью команды iostat. Как и vmstat, эта команда поддерживает дополнительные аргументы, задаю- щие интервал времени в секундах между моментами выдачи статистических данных за истекший период и число повторений. Команда iostat выдает также сведения об ис- пользовании ЦП. Приведем небольшой пример для системы Solaris. solaris$ iostat 5 5 tty sdO sdl nfsl cpu tin tout kps tps serv kps tps serv kps tps serv us sy wt id 0 1 5 1 18 14 2 20 0 0 0 0 0 0 99 0 39 0 0 0 2 0 14 0 0 0 0 0 0 100 2 26 3 0 13 8 1 21 0 0 0 0 0 0 100 3 119 0 0 0 19 2 13 0 0 0 0 1 1 98 1 16 5 1 19 0 0 0 0 0 0 0 0 0 100 Колонки разделены по темам (в данном случае их пять: tty, sdO, sdl, nf si и cpu). В разных системах данные, выводимые командой iostat, выглядят по-разному. В разделе tty содержатся данные о терминалах и псевдотерминалах. В общем-то, это неинтересная информация, хотя она и может оказаться полезной для оценки пропуск- ной способности модема. В колонках tin и tout дается среднее суммарное число сим- волов, введенных и выведенных всеми терминалами системы за секунду. 4 Мы считаем, что половину операций страничного обмена составляет выгрузка.
Глава 29. Анализ производительности 1173 Информация о каждом жестком диске размещается в колонках kps, tps и serv: объем данных, пересланных за секунду (в килобайтах); общее количество пересылок за секунду; и среднее время позиционирования головки в миллисекундах. Одно обраще- ние к диску может затронуть сразу несколько его секторов, поэтому соотношение между числами, приведенными в колонках kps и tps, говорит о структуре пересылок: толи это несколько крупных пересылок, то ли множество мелких. Крупные пересылки бо- лее эффективны. Механизм вычисления времени позиционирования, похоже, работает только на некоторых дисковых накопителях и иногда дает странные результаты (к дан- ному примеру это не относится). Результат выполнения команды iostat в системах Linux, HP-UX и AIX может вы- глядеть примерно так. aix$ iostat Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn hdiskO 0.54 0.59 2.39 304483 1228123 hdiskl 0.34 0.27 0.42 140912 216218 hdisk2 0.01 0.02 0.05 5794 15320 hdisk3 0.00 0.00 0.00 0 0 Для каждого жесткого диска сообщается число операций ввода-вывода в секунду (tps), количество операций блочного чтения и блочной записи в секунду (Blk_read/s и Blk_write/s), общий объем прочитанных (Blk_read) и записанных (Blk_wrtn) блоков. Размер дискового блока обычно равен 1 Кбайт (KiB), поэтому можно легко опреде- лить реальную скорость обмена данными с диском в килобайтах в секунду. В то же время понятие операции ввода-вывода несколько размыто. Один запрос на пересылку данных может включать в себя несколько запросов ввода-вывода к различным секторам. Время, затрачиваемое на поиск блока, — основной фактор, влияющий на производи- тельность жесткого диска. В первом приближении скорость вращения диска и быстро- действие шины, к которой он подключен, не имеют особого значения. Современные ди- ски могут пересылать сотни мегабайтов данных в секунду, если эти данные считываются из смежных секторов. Вместе с тем количество операций поиска составляет от 100 до 300 в секунду. Если после каждой операции поиска будет читаться один-единственный сектор, легко подсчитать, что в таком режиме задействуется менее 5% максимальной пропускной способности канала обмена данными с диском. Затраты времени на поиск блока возрастают, если головке приходится перемещать- ся на большие расстояния. Когда есть диск с файловой системой, расположенной в не- скольких разделах, и файлы считываются из каждого раздела в случайной последова- тельности, то для перехода из одного раздела в другой головка вынуждена преодолевать очень большой путь. С другой стороны, файлы в одном разделе расположены относи- тельно близко друг к другу. Разбивая новый диск на разделы, необходимо принять во внимание факторы, влияющие на производительность, и постараться поместить файлы, обращение к которым осуществляется одновременно, в одну файловую систему. Для достижения максимальной производительности нужно помещать файловые си- стемы, которые используются одновременно, на разные диски. Хотя тип шины и драй- веры устройств влияют на степень эффективности, большинство компьютеров может работать с несколькими дисками параллельно, что значительно повышает пропускную способность дисковой подсистемы. Например, данные и журнальные файлы веб-сервера имеет смысл размещать на разных дисках.
1174 Часть III. Разное Особенно важно распределить область подкачки между несколькими дисками, если это возможно, поскольку страничный обмен обычно замедляет работу системы в целом. Многие системы позволяют создавать как выделенные разделы подкачки, так и файлы подкачки, записываемые в обычную файловую систему. Кроме того, многие системы позволяют создавать “резидентные” файловые систе- мы. Фактически это то же самое, что и виртуальный диск ПК. Специальный драйвер выдает себя за драйвер диска, хотя на самом деле записывает данные в память. Во мно- гих организациях виртуальные диски применяются для хранения файловой системы /tmp и других часто используемых файлов, например журналов веб-сервера и почтовых буферов. Это приводит к уменьшению объема общедоступной памяти, но значительно ускоряет чтение и запись временных файлов. Как правило, такой подход оказывается весьма эффективным. Ш Подробнее о командах Isof и fuser см. в разделе 6.2. Команда Isof, которая выводит список открытых файлов, и команда fuser, которая перечисляет процессы, использующие файловую систему, могут оказаться весьма полез- ными для выявления проблем, связанных с операциями обмена с диском. Эти команды отображают взаимодействия между процессами и файловыми системами и могут указать на непредусмотренные вами взаимосвязи. Например, если некоторое приложение ре- гистрирует свои события на то же устройство, которое используется и журналами реги- страции базы данных, то в результате этот диск может стать “узким местом” системы. Утилита xdd: анализ производительности дисковой подсистемы Современные системы хранения информации могут включать сети или SAN-эле- менты, RAID-массивы и другие уровни абстракции. Для измерения и оптимизации этих сложных систем имеет смысл воспользоваться утилитой xdd, которая доступна под от- крытой лицензией (GPL) и выполняется во всех наших примерах систем (не говоря уже о Windows). Утилита xdd измеряет параметры подсистемы ввода-вывода на отдельном компьюте- ре и на кластерах систем. Она хорошо описана и обеспечивает точные и воспроизводи- мые измерения производительности. Подробнее о ней см. на сайте ioperformance. com. Команда sar: сбор статистических данных и генерирование отчетов по ним Команда sar — предназначенный для мониторинга производительности инструмент, который “проверен временем” (эта команда появилась еще во времена AT&T UNIX) на системах UNIX и Linux и все еще остается актуальным, несмотря на использование “старого-доброго” синтаксиса командной строки. На первый взгляд может показаться, что команда sar отображает ту же информа- цию, что и команды vmstat и iostat. Однако имеется одно очень важное отличие: sar “умеет” предоставлять отчеты как по старым (накопленным), так и текущим данным. £3 Пакет Linux, который содержит команду sar, называется sysstat. Без опций команда sar предоставляет отчет о том, как ЦП использовался в течение того или иного дня каждые 10 минут, начиная с полуночи. Получение такой коллекции накопленных данных делает возможным сценарий sal, который является частью паке-
Глава 29. Анализ производительности 1175 та sar и требует указания интервала времени, через который он должен запускаться из демона cron. Все данные, которые собирает команда sar, она сохраняет в бинарном формате в каталоге /var/log. linux$ sar Linux 2.6.18-92.ELsmp (bajafur.atrust.com) 01/16/2010 12:00:01 AM CPU %user %nice %system %iowait %idle 12:10:01 AM all .10 0.00 0.04 0.06 99.81 12:20:01 AM all 0.04 0.00 0.03 0.05 99.88 12:30:01 AM all 0.04 0.00 0.03 0.04 99.89 12:40:01 AM all 0.09 0.00 0.03 0.05 99.83 12:50:01 AM all 0.04 0.00 0.03 0.04 99.88 01:00:01 AM all 0.05 0.00 0.03* 0.04 99.88 Помимо информации о ЦП, sar также может предоставлять отчеты по метрическим показателям, таким как показатели дисковой и сетевой активности. Команда sar -d отображает сводку данных об активности диска за сегодняшний день, sar -n DEV — ста- тистические данные о сетевом интерфейсе, a sar -А — всю доступную информацию. Команда sar имеет некоторые ограничения и потому хорошо подходит только для быстрого получения кратких накопленных сведений. Тем, кто решил “всерьез и надолго” заняться мониторингом производительности, лучше установить специальную платформу с возможностями сбора коллекций данных и представления их в виде графиков, такую как платформа Cacti. Эта платформа “пришла к нам” из мира сетевого управления, но действительно умеет отображать произвольные метрические показатели системы, та&ие как показатели использования ЦП и памяти, в виде графиков. Пример отображаемого Cacti графика с дополнительными комментариями приводился в разделе 21.12. nmon и nmon_analyser: мониторинг производительности в системе AIX ®В системах AIX утилиту nmon системные администраторы часто выбирают в качестве инструмента измерения и настройки производительности. Она во многом напоминает утилиту sar. Стивен Аткинс (Stephen Atkins), сотрудник компании IBM, разработал крупноформатную электронную таблицу nmon_ analyser, которая обрабатывает данные, собираемые утилитой nmon. Данная утилита позволяет специалистам по производительности просматривать данные в формате большой таблицы, находить “плохие” данные и составлять графики, которые можно показать клиентам. Она выполняет более сложный анализ, чем утилита sar. Например, она вычисляет взвешенные средние числа для анализа пиковых точек, отображает загруженность устройства, размер считанных и за- писанных данных за день для системы хранения IBM и строит отдельные диа- граммы для систем хранения ЕМС. И хотя утилита nmon_analyser официаль- но не поддерживается компанией IBM, вы можете найти ее на сайте IBM: ibm.com/developerworks/aix/library/au-nmon_analyser. Выбор Linux-планировщика ввода-вывода ®В системах Linux используется алгоритм планирования подсистемы ввода- вывода, который выступает в роли “арбитра” между соревнующимися за дис- ковый ввод-вывод процессами. Он оптимизирует порядок и время запросов
1176 Часть III. Разное для обеспечения наилучшей возможной производительности подсистемы ввода-вывода для данного приложения или ситуации. В ядро Linux 2.6 встроены четыре разных алгоритма планирования. Можно выби- рать любой. К сожалению, алгоритм планирования устанавливается во время загрузки (при помощи атрибута ядра е1еуаЬог=алгоритм) и поэтому его не легко изменить. Алгоритм планирования системы обычно указывается в файле конфигурации начально- го загрузчика GRUB grub. config. Все доступные алгоритмы перечислены ниже. Comletely Fair Queuing (elevator=cfq). Этот алгоритм используется по умолчанию и обычно является наиболее подходящим вариантом для серверов общего назначения. Он старается равномерно предоставлять доступ к подсистеме ввода-вывода. (Во всяком случае этот алгоритм заслуживает награды за маркетинг: кто скажет “нет” совершенно справедливому планировщику?) Deadline (elevator=deadline). Этот алгоритм “старается” сводить к минимуму время задержки для каждого запроса. Он изменяет порядок запросов для повышения производительности. NOOP (elevator=noop). Этот алгоритм реализует простую очередь типа FIFO (First In, First Out — первым пришел, первым обслужен). Он предполагает, что запросы к под- системе ввода-вывода уже были (или еще будут) оптимизированы или переупорядоче- ны драйвером или устройством (каковым вполне может быть какЙЙ-нибудь контроллер со встроенной логикой). Он может быть наиболее подходящим вариантом в некоторых SAN-средах и для SSD-устройств. Определив, какой из этих алгоритмов планирования является наиболее подходящим для данной среды (что может потребовать перепробовать все четыре варианта), возмож- но, вам удастся улучшить производительность подсистемы ввода-вывода. Программа oprofile: универсальный профилировщик системы Linux ©Программа oprofile — это чрезвычайно мощная, интегрируемая в систему программа профилирования для систем Linux с ядром версии 2.6 или выше. Профилированию могут подвергаться все компоненты системы Linux: аппа- ратные и программные обработчики прерываний, модули ядра, само ядро, со- вместно используемые библиотеки и приложения. При наличии свободного времени и желания точно знать, как используются ре- сурсы системы (до самых мельчайших деталей), стоит рассмотреть вариант установки oprofile. Эта утилита особенно полезна для тех, кто разрабатывает свои собственные приложения или код ядра. В состав дистрибутива oprofile, который доступен для загрузки на сайте sourceforge. net, входят как модули ядра, так и ряд пользовательских утилит. В начале 2010 года на горизонте появилась новая система отслеживания производи- тельности. Известная как подсистема событий производительности (“perf events”), она обеспечивает уровень оснащенности, никогда ранее не виданный в ядре Linux. По всей вероятности, эта система в будущем заменит программу профилирования производи- тельности в системах Linux oprofile.
Глава 29. Анализ производительности 1177 29.5. Помогите! Моя система почти остановилась! В предыдущих разделах речь шла, в основном, о средней производительности систе- мы. Для ее повышения требуется корректировать конфигурационные параметры или модернизировать систему. Но даже правильно сконфигурированные системы иногда работают медленнее обыч- ного. К счастью, нерегулярные проблемы обычно легко диагностируются. В большин- стве случаев они создаются “ненасытным” процессом, который потребляет так много ресурсов процессора, жесткого диска или сетевой подсистемы, что остальные процессы буквально останавливаются. Иногда процесс намеренно захватывает ресурсы, чтобы за- медлить работу системы или сети. Это называется атакой типа “отказ в обслуживании”. Очень часто, чтобы определить, какой конкретно ресурс исчерпан, не нужно даже за- пускать диагностическую программу. Если система начинает “подвисать”5 или подозри- тельно долго обращаться к диску, то проблема, скорее всего, связана с пропускной спо- собностью дисковой подсистемы или дефицитом памяти. Если же производительность приложений падает ниже критического уровня, проблема, возможно, в загрузке ЦП. Первый шаг в диагностировании проблемы — запуск команды ps auxww (ps -elf в Solaris и HP-UX) или top для выявления явно неуправляемых процессов. Любой про- цесс, отнимающий более 50% времени ЦП, можно с большой долей вероятности считать ненормальным. Если столь непомерную долю ресурсов ЦП не получает ни один про- цесс, посмотрите, сколько процессов получают минимум по 10%. Когда их больше двух- трех (не считая самой команды ps), средняя загруженность, скорее всего, будет очень высокой. Такая ситуация сама по себе является причиной низкой производительности. Проверьте среднюю загруженность системы с помощью команды uptime, а затем выпол- ните команду vmstat или top, чтобы узнать, простаивает ли когда-нибудь процессор. Если конкуренции за право использования центрального процессора не наблюдает- ся, выполните команду vmstat, чтобы посмотреть, какова интенсивность страничного обмена. Следует обращать внимание на все операции обмена с диском: множество опе- раций выгрузки может означать соперничество за память, а наличие дискового трафика в отсутствие страничного обмена говорит о том, что какой-то процесс монополизировал диск, непрерывно читая и записывая файлы. Нельзя непосредственно сопоставить дисковые операции с выполняющими их про- цессами, но с помощью команды ps можно сузить круг “подозреваемых”. Любой про- цесс, работающий с диском, должен отнимать какую-то часть времени ЦП. Как пра- вило, всегда можно сделать обоснованное предположение о том, какой конкретно из активных процессов захватил ресурсы6. Для проверки своей теории на практике выпол- ните команду kill -STOP. Предположим, процесс-виновник найден. Что с ним делать дальше? Как правило, ничего. Некоторые операции действительно требуют много ресурсов и неизбежно за- медляют работу системы, но это вовсе не означает, что они незаконны. Но с помощью 5 Другими словами, требуется больше времени на переключение между приложениями, хотя скорость выполнения отдельных заданий приемлема. 6 Ранее признаками этого служили большой размер области данных процесса, размещенной в виртуальной памяти, либо неестественно большой объем занимаемой процессом физической памяти, но появление совместно используемых библиотек сделало эти показатели не столь по- лезными. Команда ps не умеет отделять общесистемные совместно используемые библиотеки от адресного пространства отдельных процессов. Кажется, что многие процессы занимают десятки мегабайтов физической памяти, хотя на самом деле это не так.
1178 Часть III. Разное команды renice можно изменить приоритет процесса, для которого ограничивающим фактором является быстродействие ЦП. Иногда правильная настройка приложения мо- жет привести к значительному снижению потребления ресурсов. Этот эффект особенно заметен в сетевых серверных программах, например в веб-приложениях. Процессы, интенсивно использующие диск и память, нелегко поддаются воздей- ствию. Команда renice обычно не помогает. Можно уничтожить или остановить про- цесс, но, на наш взгляд, такая мера оправдана только в экстренных ситуациях. Лучше прибегнуть к административной мере: попросить владельца запустить процесс позже. Ядро позволяет процессу ограничивать объем потребляемой им самим физической памяти при помощи системного вызова setrlimit7. Эта возможность также доступна в оболочке С в виде встроенной команды limit. Например, команда % limit memoryuse 32m ограничивает использование физической памяти для всех последующих пользова- тельских команд тридцатью двумя мегабайтами (в системе Solaris вместо команды memoryuse используется команда memory size). Ее действие примерно эквивалентно действию команды renice в отношении процессов, ограничивающим фактором для ко- торых является объем памяти. Если неуправляемый процесс не является источником снижения производитель- ности, нужно проанализировать две другие возможные причины. Первая — перегруз- ка сети. Многие программы настолько тесно связаны с сетью, что иногда трудно по- нять, где речь идет о производительности системы, а где — о производительности сети. Подробная информация о средствах контроля над работой сети приведена в главе 21. В некоторых случаях проблемы, связанные с перегрузкой сети, выявить сложно, по- тому что они возникают и исчезают очень быстро. Например, если на всех компьютерах сети каждый день в определенное время с помощью демона cron запускается какая-то сетевая программа, то в сети может возникать кратковременный, но серьезный затор. Все компьютеры “зависнут” секунд на пять, после чего ситуация нормализуется. Вторая причина — задержки, связанные с серверами. UNIX- и Linux-системы по- стоянно обращаются к удаленным серверам NFS, Kerberos, DNS и т.п. Если сервер не работает или какая-то иная проблема привела к тому, что связь с ним стала ненадежной, это ощущают на себе все клиентские системы. Предположим, что в интенсивно эксплуатируемой системе какой-то процесс каждые несколько секунд вызывает библиотечную функцию gethostent. Если сбой в работе DNS заставляет эту функцию тратить на свое выполнение две секунды, будет заметно общее снижение производительности системы. На удивление, большое число проблем с производительностью серверов связано с неправильной конфигурацией прямого и об- ратного поиска в DNS. 29.6. Рекомендуемая литература • Cockcroft Adrian and Bill Walker. Capacity Planning for Internet Services. Upper Saddle River, NJ: Prentice Hall, 2001. • Drepper Ulrich. What Every Programmer Should Know about Memory, lwn.net/ Articles/250967. 7 Более тонкое управление ресурсами может быть достигнуто посредством CKRM-функций (Class-based Kernel Resource Management — управление ресурсами ядра на базе классов); см. скгт. sourceforge. net.
Глава 29. Анализ производительности 1179 • Ezolt Phillip G. Optimizing Linux Performance. Upper Saddle River, NJ: Prentice Hall PTR, 2005. • Johnson S., et al. Performance Tuning for Linux Servers. Indianapolis, IN: IBM Press, 2005. • Loukides, Mike and Gian-Paolo D. Musumeci. System Performance Tuning (2nd Edition). Sebastopol, CA: O’Reilly & Associates, 2002. • Tufte, Edward R. The Visual Display of Quantitative Information (2nd Edition). Cheshire, CT Graphics Press, 2001. 29.7. Упражнения 29.1. Определите возможную причину проблем в каждом из перечисленных ниже слу- чаев. а) при переключении между приложениями возникает заметная пауза и слышно, как диск интенсивно перекачивает данные; б) программа численного моделирования выполняется дольше, чем нужно, но системная память практически свободна; в) пользователи интенсивно эксплуатируемой ЛВС жалуются на медленный до- ступ через NFS, но показатель средней загруженности сервера остается очень низким; г) В процессе работы команда часто сообщает о нехватке памяти. 29.2. ★ Системы балансирования нагрузки способны существенно влиять на произво- дительность серверов. Перечислите несколько механизмов, которые могут исполь- зоваться для распределения нагрузки. 29.3. ★ Перечислите четыре основных фактора, влияющих на производительность. Для каждого из них приведите пример приложения, способного легко захватить весь ресурс. Укажите способы решения проблемы в каждом конкретном случае. 29.4. ★ Напишите три простые программы (или сценарии). Первая должна увеличить процессорное время, выделяемое на выполнение системных задач, а вторая — на выполнение пользовательских задач. Третья не должна влиять ни на один из этих параметров, но должна иметь большую продолжительность выполнения (elapsed time). Используйте свои программы в сочетании с командами, описанными в раз- деле “Анализ использования центрального процессора” (выше в этой главе), что- бы узнать, что произойдет при воздействии на систему различными способами. 29.5. ★ Напишите две простые программы (или сценарии). Первая должна интенсивно выполнять операции чтения, а вторая — операции записи. Используйте свои про- граммы с командами, приведенными в разделе “Анализ операций обмена с дис- ком” (выше в этой главе), чтобы узнать, что произойдет при воздействии на си- стему различными способами. (В качестве дополнительного условия предложите каждой из своих программ по выбору использовать модель либо произвольного, либо последовательного доступа.) 29.6. ★ Выберите любые две программы, потребляющие заметный объем системных ресурсов. Воспользуйтесь командой vmstat и другими рассмотренными в этой главе средствами для анализа работы каждой программы. Укажите, какие действия программы приводят к повышенному потреблению ресурсов. Подтвердите свои выводы конкретными числами.
глава 30 Взаимодействие с системой Windows Сегодня администраторы очень часто работают со средами, в которых установлены одновременно и Windows-, и UNIX-системы. Поэтому они должны знать о том, что су- ществует немало способов, которыми эти операционные системы могут помогать друг другу. Например, Windows-приложения, помимо всего прочего, могут запускаться с ра- бочего стола UNIX или получать доступ к находящимся на сервере UNIX принтерам и файлам, а UNIX-приложения могут отображать свои пользовательские интерфейсы на рабочем столе Windows. Обе платформы имеют сильные стороны, и их можно заставить работать совместно. Windows — это популярная и удобная настольная система, способная выступать в роли “мостика” между пользователем и выходящим из стены сетевым кабелем. С другой сто- роны, UNIX — это надежная и масштабируемая инфраструктурная платформа. Так что давайте не будем ссориться, ладно? 30.1. Вход в систему UNIX из Windows У пользователей может возникнуть желание поработать в сеансе оболочки С или bash, не вставая из-за своего компьютера Windows. Лучшим инструментом для удаленного до- ступа в системах UNIX и Linux является протокол оболочки безопасности SSH. Ш О протоколе SSH более подробно рассказывалось в разделе 22.10. Существует несколько реализаций протокола SSH для системы Windows. Протокол SSH также поддерживает передачу файлов, а пакет PuTYY включает две предназначен- ные для этой цели клиентские программы с интерфейсом командной строки: psf tp
Глава 30. Взаимодействие с системой Windows 1181 и pscp. Приверженцам системы Windows, которые никогда не имели дела с командной строкой, скорее всего, придется по душе имеющая графический интерфейс клиентская программа WinSCP, доступная по адресу: winscp.net. Еще один неплохой вариант — установить общий пакет UNIX-on-Windows Cywin и запускать доступные в нем SSH-утилиты из эмулятора rxvt. Пакет Cygwin описывается в разделе 30.4. Модную, не имеющую пока никаких негативных отзывов Java-реализацию прото- кола SHH под названием MindTerm предлагает компания AppGate (appgate. com). Для личного использования программа MindTerm доступна бесплатно. Она запускается на любой системе, которая поддерживает язык Java, и может конфигурироваться различ- ными способами. Среди коммерческих реализаций клиента протокола SSH нашим фаворитом являет- ся программа SecureCRT компании VanDyke Software. Ее можно приобрести на сайте vandyke.com. Программа SecureCRT поддерживает все необходимые терминальные функции. Кроме того, компания VanDyke предлагает прекрасное обслуживание заказ- чиков и стимулирует их предлагать новые функции. Как и в программе PuTTY, функции программы SecureCRT встроены в программное обеспечение протокола для передачи файлов SFTR Интересной функцией протокола SSH является способность перенаправлять порты TCP между клиентом и сервером. Например, эта функция позволяет администратору настроить на клиенте локальный порт, который будет перенаправлять входящее сое- динение на другой порт, находящийся на машине, доступ к которой возможен только с сервера. Хотя эта функция открывает множество новых возможностей, она потенци- ально опасна и потому должна учитываться администратором при предоставлении SSH- доступа к своему серверу. К счастью, ее можно отключить на стороне сервера и тем са- мым ограничить возможности SSH только доступом к терминалу и передачей файлов. 30.2. Получение доступа к удаленным НАСТОЛЬНЫМ СРЕДАМ Графические настольные среды в системе UNIX связаны с распространяемой бес- платно системой X Window System, которая не имеет никакого отношения к Micro- soft Windows. Система X Windows была разработана в исследовательских центрах Массачусетсского технологического института в средине восьмидесятых годов прошло- го столетия и принята как стандарт всеми производителями рабочих станций UNIX и дистрибутивов системы Linux. Она претерпела несколько серьезных обновлений; ста- бильная база была окончательно достигнута лишь в версии 11, которая была впервые опубликована в начале девяностых годов прошлого века. Номер версии протокола был добавлен к ее названию — "XII”; под этим именем она известна сегодня. (Слово “Windows”, используемое само по себе, всегда — как в этой главе, так и в реальном мире — означает операционную систему Microsoft Windows.) XI1 — это клиент-серверная система. Сервер X Server отвечает за отображение дан- ных на экране пользователя и за получение входных данных с клавиатуры или от мыши пользователя. Он взаимодействует с клиентскими приложениями через сеть. Вовсе не обязательно, чтобы сервер и клиенты запускались на одной и той же машине. Ш Архитектура X Windows более подробно описывалась в главе 25.
1182 Часть III. Разное Запуск сервера X Server на компьютере Windows XI1 — это богатый протокол, в который за последние годы было добавлено мно- го расширений. Поэтому реализация сервера X Server является довольно сложной. Несмотря на это, сегодня реализации сервера X Server существуют практически для каждой операционной системы. Сама система X Windows безразлична к операционной системе, так что клиенты протокола XII, работающие на UNIX-компьютере, могут ото- бражать сервер X Server, работающий под управлением системы Microsoft Windows, и по- зволять пользователю управлять ими точно так же, как если бы этот пользователь сидел за системной консолью. К сожалению, первые разработчики протоколов X не уделили должного внимания вопросам безопасности. Каждая программа, которая подключается к серверу X Server, может считывать все, что вводит с клавиатуры обслуживающий этот сервер администра- тор, и видеть все, что он отображает на своем экране. Еще больше ухудшает дело то, что удаленным программам даже не нужно отображать окно при получении доступа к серве- ру X Server: они могут просто “ тихонько прокрадываться” на заднем фоне. Со временем для защиты протокола XI1 было предложено несколько методов, но все они оказались несколько сложными. Вывод таков: лучше не разрешать никаких удален-, ных подключений к своему серверу X Server, если нет уверенности в том, что делаешь. Большинство серверов X по умолчанию конфигурируется так, чтобы они не допускали удаленных соединений, так что угрозы безопасности быть не должно, по крайней мере до тех пор, пока не будет запущена программа xhosts (или ее аналог), предоставляю- щая права на удаленный доступ. К сожалению, предоставление прав на удаленный доступ — это единственный путь, когда нужно сделать так, чтобы программы выполнялись в системе UNIX, а их интер- фейсы отображались в системе Windows. Как же запустить удаленное приложение, не предоставив разрешения на удаленный доступ серверу X Server? Наиболее распростра- ненный метод — использовать функциональную возможность протокола SSH, которая была специально разработана для поддержки протокола XI1. В таком случае между клин ентами системы X, работающими на удаленном хосте, и локальным сервером X будет создан безопасный канал. Программы, запускаемые на удаленном хосте, будут автома- тически отображаться на локальной машине, но благодаря чудодейственным операциям; протокола SSH локальный сервер X будет воспринимать их так, будто они были запуще- ны локально. Ш О протоколе SSH более подробно рассказывалось в разделе 22.10. Обратите внимание на то, что переадресация системы X будет работать, только если ее функции переадресации включены как на стороне сервера SSH, так и на стороне кли- ента SSH. Например, если используется SSH-клиент PuTTY в системе Windows, функ- цию переадресации протокола XI1 можно включить прямо на его экране установки И потом на стороне сервера SSH (соответственно, на стороне клиента XI1, т.е. на компью- тере с системой UNIX), удостовериться в том, что файл /etc/ssh/sshd_config содер- жит такую строку. XllForwarding yes , В случае изменения конфигурации SSH-сервера, следует перезапустить процесс sshd для того, чтобы новая конфигурация вступила в силу. Параметр XllForwarding преду-< смотрен в большинстве систем UNIX, реализующих протокол OpenSSH.
Глава 30. Взаимодействие с системой Windows 1183 Как заметил наш технический редактор Дан Фостер (Dan Foster), перенаправление соединений в системе X в рамках протокола XII “может быть мучительно медленным, даже в системе LAN, причем ситуацию ухудшает наличие задержек в сети”. Альтернати- вой является система VNC. В то время как компания Apple предоставляет бесплатную версию сервера X Server для операционной системы Mac OS X, компания Microsoft, к сожалению, ничего по- добного для системы Windows не предлагает. Однако существует одна бесплатная версия сервера X Server, доступная на сайте проекта Cygwin (cygwin. com), которая работает очень хорошо после того, как ее сконфигурировать. Прекрасной альтернативой, допу- скающей намного более простое конфигурирование, является сервер Xming для системы Windows. К коммерческим версиям X Server для Windows относятся Exceed и X-Win32. Эти версии предлагают более простую процедуру конфигурации, но по довольно высо- кой цене. VNC: система виртуальных сетей В конце девяностых годов предыдущего столетия несколько человек из исследова- тельского центра AT&T Labs в Кембридже (Великобритания) разработали систему для удаленного доступа к настольным системам под названием VNC. Их идеей было “под- ружить” считающиеся уже примитивными, но зато простые терминалы с современ- ными оконными системами. В отличие от протокола XII, протокол VNC не работает с отдельными приложениями. Он создает виртуальный рабочий стол (или предостав- ляет удаленный доступ к существующему) в виде отдельного компонента. В системе VNC специальный сервер XI1 функционирует на центральной машине, а для получения к нему доступа используется специальное приложение типа программы просмотра. Компания AT&T опубликовала программное обеспечение VNC под либеральной лицензией на программное обеспечение с открытым исходным кодом. Это позволило другим разработчикам подхватить эту идею и создать дополнительные реализации сер- вера и программы просмотра, а также улучшить ограниченную пропускную способность протокола. Сегодня VNC-программы просмотра доступны для большинства устройств, имеющих хоть какие-нибудь средства для графического отображения. VNC-серверы для систем UNIX, Linux и Windows тоже доступны повсеместно. Реализация VNC-сервера для системы UNIX, по сути, представляет собой эмуля- тор графического адаптера, который подключается к серверу X.Org X Windows. Запуск vncserver через учетную запись системы UNIX приводит к созданию нового вирту- ального рабочего стола, который функционирует на машине UNIX в своем собствен- ном, отдельном, мире. После этого пользователи могут использовать VNC-программу просмотра и получать доступ к этому рабочему столу удаленно. Мы рекомендуем перед первым запуском сервера выполнить команду vncpasswd, чтобы установить пароль для соединения. Протокол VNC не запоминает состояние и использует двоичное отображение. Сле- довательно, пользователи могут свободно присоединяться и отсоединяться. Более того, несколько программ для просмотра могут иметь доступ к одному и тому же серверу од- новременно. Последнее свойство особенно полезно для поддержки удаленного доступа и отладочных настроек. Кроме того, оно облегчает доступ к консоли для системных ад- министраторов. VNC-серверы в мире Windows обычно не создают никакого дополнительного рабо- чего стола: они просто экспортируют стандартный рабочий стол системы Windows в том
1184 Часть III. Разное виде, в котором он отображается на экране. Главным приложением для этой технологии является удаленная поддержка. В наши дни первые создатели VNC уже владеют собственной компанией, которая называется RealVNC (realvnc. com). Авторы проекта UltraVNC (ultravnc. com) зани- маются разработкой очень быстрой и многофункциональной реализации VNC-сервера для системы Windows, а участники проекта TightVNC (tightvnc. com) работают над по- вышением степеней сжатия. Все они обязательно обмениваются информацией между собой, поэтому между разными приложениями происходит взаимное обогащение. Протокол VNC совершенствуется с учетом возможности расширения. Все програм- мы просмотра и серверы могут работать друг с другом в любой комбинации: они подби- рают наилучший вариант протокола, понятный обеим сторонам. Функциональные воз- можности, наличие которых зависит от конкретной реализации (такие, как возможность передачи файлов), обычно доступны только при использовании сервера и клиента из одного и того же проекта. Протокол RDP в системе Windows Начиная с версии Windows 2000 Server каждая система Windows имеет техническую возможность предоставлять графический удаленный доступ нескольким пользователям одновременно. Компонент удаленного доступа, называемый Remote Desktop, использует протокол RDP (Remote Desktop Protocol — протокол для удаленных дисплеев) для обе- спечения связи между клиентом и сервером. Клиенты протокола RDP в системе UNIX позволяют администраторам управлять системой Windows с рабочего стола UNIX. Это неоценимый инструмент для системных администраторов UNIX, которым приходится иметь дело с системой Windows. Для того чтобы воспользоваться протоколом RDP, необходимо активизировать сер- верную сторону (систему Windows) и обеспечить клиенту доступ к ней. Для этого в си- стеме Windows 7 следует зайти на панель управления System, щелкнуть на пиктограмме Remote и выбрать параметр на панели Remote Desktop. 30.3. Запуск системы Windows и Windows-приложений Как указывалось в главе 24, коммерческий продукт VMware Server (vmware. com) по- зволяет запускать на оборудовании персонального компьютера несколько операцион- ных систем одновременно. Программа VMware эмулирует все виртуальные “гостевые” машины поверх базовой операционной системы, в роли которой выступает либо Linux, либо Windows. Какой бы ни была базовая операционная система, на виртуальных ма- шинах VMware может быть установлена любая Intel-совместимая операционная систе- ма. С точки зрения гостевой машины, операционная система работает точно так же, как она работала бы на “родном” аппаратном обеспечении, и приложения инсталлируются нормально. Другими средствами виртуализации являются программы KVM и VirtualBox, которые также запускают систему Windows и должны рассматриваться как средства для запуска Windows-приложений. Система Wine (winehq.com) работает иначе. Она реализует в среде UNIX API-интер- фейс программирования Windows, тем самым позволяя запускать Window-приложения прямо поверх системы X. Эта бесплатно доступная программа транслирует “родные” вызовы API-интерфейса Windows в их UNIX-аналоги и может делать это, не используя
Глава 30. Взаимодействие с системой Windows 1185 никакого кода компании Microsoft. Кроме того, она поддерживает протоколы TCP/IP, устройства последовательного доступа и звуковые платы. Она работает в системах Linux, BSD, Mac OS и Solaris. Многие приложения Windows запускаются без проблем, но некоторые можно за- ставить работать лишь при помощи определенных уловок; подробнее об этом можно узнать на официальном веб-сайте проекта Wine. К сожалению, заставить приложения выполняться под управлением системы Wine часто не так-то просто. Талантливые раз- работчики на сайте codeweavers. com написали небольшую коммерческую программу- инсталлятор, которая умеет вынуждать “упрямые” приложения Windows работать так, как надо. Если выбранное приложение поддерживается программой Code Weavers — замеча- тельно. Если нет, нужно дать ему шанс, а вдруг оно сможет приятно удивить. Но если приложение не хочет работать само и никакие заготовленные подсказки отыскать не удается, будьте готовы потратить время, чтобы придать ему нужную форму, если уж ре- шили сделать это своими силами. При наличии бюджетных средств можете попробовать договориться с Code Weavers о помощи. Коммерческой альтернативой программе Wine является программа Win4Lin компа- нии NeTraverse. Разработчики программы Win4Lin утверждают, что она более устойчива и поддерживает немного больше приложений компании Microsoft, чем программа Wine. Однако она требует модификации ядра, в то время как программа Wine обходится без этого. Программу Win4Lin можно приобрести на сайте win41 in. com. Двухвариантная загрузка и почему ею не стоит пользоваться Тем, кто хоть когда-нибудь устанавливал систему Linux на компьютер, на котором ра- нее была установлена Windows, несомненно, предлагалось создать конфигурацию с двух- вариантной загрузкой. В наши дни такие конфигурации функционируют во многом так, как обещают. Сегодня даже можно монтировать Windows-разделы под управлением системы Linux и получать доступ к файловой системе Linux под управлением Windows. О том, как именно можно настроить конфигурацию с двухвариантной загрузкой, под- робно рассказывалось в разделе 3.3. Но не стоит спешить! Тем, кто действительно работает как с Windows, так и с UNIX и нуждается в доступе к ним, следует очень скептично относиться к конфигурации с двухва- риантной загрузкой. Такие конфигурации представляют собой воплощение закона Мэр- фи в его самом худшем виде: они, кажется, почти всегда загружают не ту операционную систему, и из-за этого даже самая простая операция обычно заканчивается выполнением нескольких повторных загрузок. Сегодня компьютеры стоят так дешево и удаленный доступ настраивается так легко, что, как правило, нет никакого смысла подвергать себя таким бесконечным мучениям. Альтернативы Microsoft Office Несколько лет назад компания Sun выпустила новую версию пакета StarOffice, ко- торый является аналогом пакета Microsoft Office. Эта версия, также распространяемая с открытым исходным кодом, называется OpenOffice.org. В этот пакет входят основные офисные утилиты, такие как редактор электронных таблиц, текстовый редактор, пакет средств для создания презентаций и приложение для рисования. Эти программы могут
1186 Часть III. Разное читать и записывать файлы, сгенерированные их Microsoft-аналогами. Загрузить пакет OpenOffice.org можно по адресу: openoffice. org. Пакет OpenOffice.org доступен на всех основных платформах, включая Windows, Linux, Solaris, Mac OS X и многие другие версии UNIX. Если нужен пакет с контрактом о поддержке, можно приобрести пакет StarOffice, который отличается от OpenOffice.org только наличием более мощного механизма проверки правописания и базы данных. Компания Google выпустила конкурентное приложение Google Apps. Кроме мощ- ных приложений Gmail и Google Calendar, компания разработала текстовый процессор и электронные таблицы. Эти свободно распространяемые программы включают взаимо- действующие функции, позволяющие пользователям одновременно редактировать до- кументы, расположенные в разных местах. Поскольку все приложения компании Google запускаются в веб-браузере, их можно использовать буквально в любой системе. Кроме того, можно экспортировать и импортировать содержимое файлов в разных форматах, включая форматы приложений Microsoft Office. 30.4. Использование утилит командной СТРОКИ В СИСТЕМЕ WINDOWS Чего многим пользователям системы UNIX не хватает при работе на системах Windows, так это командной строки. И не просто старого консольного приложения или чего-то вроде DOS Box, а настоящей программы xterm, поддерживающей изменение размеров, цветовые схемы, управление мышью и все модные управляющие последова- тельности. Хотя автономного (т.е. не зависящего от системы X) родного порта xterm для си- стемы Windows не существует, имеется небольшая аккуратная программа rxvt, которая очень близка к идеалу. Она является частью системы Cygwin, которую можно загрузить с сайта cygwin. com. Если вы установите сервер X Server, поставляемый с системой Cygwin, сможете пользоваться настоящей программой xterm. Эта система распространяется под общедоступной лицензией GNU General Public License и включает довольно обширный дополнительный набор общих команд UNIX, а также переносимую библиотеку, которая реализует API-интерфейсы POSIX под Windows. Ее подход к согласованию обозначений командной строки и файловых систем UNIX и Windows довольно хорошо продуман и “умудряется” наделять родные команды Windows многими удобными возможностями оболочки UNIX. Cygwin не только позволяет поль- зователям UNIX чувствовать себя в Windows “как дома”, но и упрощает запуск про- граммного обеспечения UNIX под Windows. Подробнее о Cygwin можно узнать на сайте cygwin.com. Пакет MKS Toolkit представляет собой коммерческий аналог Cygwin. Более под- робную информацию о нем можно найти на сайте MKS, который находится по адресу: mkssoftware.com. Список программ UNIX, которые могут сами запускаться на Windows, постоянно растет; на текущий момент в него уже входят Apache, Perl, BIND, PHP, MySQL, Vim, Emacs, Gimp, Wireshark и Python. Прежде чем пытаться заставить приложение работать под управлением системы Windows с помощью инструмента вроде Cygwin, поищите его “родную” реализацию.
Глава 30. Взаимодействие с системой Windows 1187 30.5. Совместимость Windows со стандартами ЭЛЕКТРОННОЙ ПОЧТЫ И ВЕБ В идеальном мире все бы пользовались для связи открытыми стандартами и были счастливы. Но наш мир не идеален, и многие ругают систему Windows за то, что она представляет собой кучу запатентованных протоколов и неисправных реализаций ин- тернет-стандартов. Пожалуй, они частично правы, но, тем не менее, существует много областей, благодаря которым система Windows вполне может нормально функциониро- вать в мире стандартов. Этими областями являются службы электронной почты и веб. За всю богатую историю веб, многие корпорации пытались охватить и расширить веб-возможности, чтобы защититься от конкуренции и увеличить свои доходы во много раз. Компания Microsoft по-прежнему ведет такую борьбу на уровне браузера с его мно- гочисленными расширениями, подходящими исключительно для Internet Explorer. На базовом уровне протокола HTTP, однако, система Windows и Windows-браузеры практи- чески не зависят от платформы. Компания Microsoft предоставляет свой собственный веб-сервер — IIS, но его про- изводительность всегда была ниже производительности сервера Apache, запускаемого в системе Linux, причем намного. Тем, кто не “зациклился” на серверной технологии типа ASP, использовать Windows-машины в качестве веб-серверов вовсе не обязательно. Что касается электронной почты, то компания Microsoft усиленно предлагает в каче- стве предпочтительной серверной технологии свой продукт Exchange Server. По правде сказать, возможности программы Exchange Server действительно превосходят возмож- ности почтовых систем интернет-стандарта, особенно когда почтовые клиенты пред- ставляют собой компьютеры Windows, запускающие Microsoft Outlook. И это еще не все: программа Exchange Server также может использовать протокол SMTP для входящей и исходящей почты и передавать почту UNIX-клиентам при помощи стандартных Прото- колов IMAP и POP. На стороне клиента программа Outlook и ее бесплатный аналог Outlook Express мо- гут подключаться к серверам UNIX IMAP и POP (как и большинство аналогичных про- грамм, созданных сторонними разработчиками). Экспериментируйте с любыми комби- нациями и выбирайте наиболее подходящую. О протоколах POP и IMAP более подробно рассказывалось в разделе 20.1. 30.6. Совместное использование файлов при помощи Samba и CIFS В начале 1980-х годов компания IBM разработала API-интерфейс, который позволял компьютерам в одной и той же подсети общаться друг с другом, используя не замысло- ватые номера, а имена. Этот интерфейс получил такое название: Network Basic Input/ Output System (Сетевая базовая система ввода-вывода), сокращенно — NetBIOS. Его расширенная версия, включающая исходный базовый сетевой протокол транспортного уровня, была названа так: NetBIOS Extended User Interface (Расширенный пользователь- ский интерфейс NetBIOS), сокращенно — NetBEUI. API-интерфейс NetBIOS стал до- вольно популярным и потому был адаптирован для использования поверх ряда различ- ных сетевых протоколов, таких как IPX, DECNet и TCP/IP.
1188 Часть III. Разное Компании Microsoft и Intel разработали на базе NetBIOS протокол совместного ис- пользования файлов и назвали его “основным протоколом” (core protocol). Позже он был переименован в протокол Server Message Block (Блок сообщений сервера) или, со- кращенно, SMB. Далее протокол SMB эволюционировал в систему CIFS (Common Internet File System — Общая межсетевая файловая система), которая, по сути, пред- ставляла собой улучшенную и настроенную для работы в глобальных сетях версию SMB. Эта система CIFS по сей день остается главной технологией для совместного исполь- зования файлов на компьютерах, работающих под управлением операционной системы Windows. В мире Windows файловая система или каталог, который доступен через сеть, является совместно используемым ресурсом. Этот термин звучит немного странно для пользовате- лей UNIX, но при описании файловых систем CIFS мы будем пользоваться именно им. Samba: сервер CIFS для UNIX Чрезвычайно популярный пакет Samba распространяется на условиях открытой лицензии GNU и реализует серверную часть CIFS в системах UNIX и Linux. Он был создан австралийцем Эндрю Триджеллом (Andrew Tridgell), который путем “обратного” проектирования воссоздал код протокола SMB и опубликовал полученный результат в 1992 году. Здесь мы рассмотрим пакет Samba версии 3. Сегодня пакет Samba хорошо поддерживается и постоянно совершенствуется для расширения его функциональных возможностей. Он предоставляет собой стабильный, надежный механизм для интеграции в сеть UNIX, состоящую из компьютеров, работаю- щих под управлением системы Windows. Прелесть пакета заключается в том, что уста- навливать его нужно только на сервере — на Windows-компьютере никакого дополни- тельного программного обеспечения не требуется. Система CIFS предоставляет пять основных служб. • Совместное использование файлов. • Сетевая печать. • Аутентификация и авторизация. • Разрешение имен. • Объявление служб (“обзор” сервера файлов и принтера). Пакет Samba не только обрабатывает файлы с помощью системы CIFS, но и выпол- няет основные функции контроллера службы Windows Active Directory. Как контроллер домена, пакет Samba поддерживает такие функциональные возможности, как регистра- ция доменов Windows, роуминг профилей пользователей Windows и буферизация зада- ний на печать в системе CIFS. Большинство функциональных возможностей пакета Samba реализуется двумя демо- нами: smbd и nmbd. Демон smbd реализует обслуживание файлов и заданий на печать, а также выполняет аутентификацию и авторизацию. Демон nmbd обслуживает другие основные компоненты системы CIFS: разрешение имен и объявление служб. В отличие от файловой системы NFS, которая тесно связана с ядром, пакет Samba не требует модификации ядра и запускается исключительно как пользовательский процесс. Он устанавливает соединения с сокетами, через которые посылаются NBT-запросы, и ждет клиентских запросов на доступ к ресурсам. Как только запрос поступил и был ау- тентифицирован, демон smbd создает новый экземпляр самого себя, который работа- ет от имени пользователя, сделавшего запрос. В результате все права доступа к файлам
Глава 30. Взаимодействие с системой Windows 1189 (включая групповые права) остаются ненарушенными. Единственная дополнительная функциональная возможность, которую демон smbd реализует, — это сервис блокировки файлов, позволяющий клиентским персональным компьютерам придерживаться при- вычной для них семантики блокировок. Установка Samba Пакет Samba может работать со всеми рассмотренными нами операционными систе- мами.1 Это относится и к системе Linux. Заплатки, документация и другие файлы можно загрузить с сайта samba. org. Обязательно следует убедиться в том, что используются новейшие из доступных для данной системы пакеты Samba, потому что дефекты пре- дыдущих версий чреваты потерей данных и возникновением проблем с безопасностью. Во всех системах придется отредактировать файл smb. conf (который должен нахо- диться либо в каталоге /etc/samba/smb. conf, либо /etc/smb. conf), чтобы задать по- ведение пакета Samba. В этом файле указываются каталоги и принтеры, которые долж- ны использоваться совместно, права доступа к ним и общие рабочие параметры пакета Samba. Кроме того, в состав пакета Samba входит образец файла smb. conf, который содержит подробные комментарии и может стать хорошей отправной точкой для зада- ния новой конфигурации. Обратите внимание на то, что после запуска Samba проверяет свой конфигурационный файл каждые несколько секунд и загружает все появившиеся изменения. Также важно помнить о проблемах безопасности, которые могут возникать при со- вместном использовании файлов и других ресурсов по сети. Для типичного сайта можно обеспечить базовый уровень безопасности, выполнив два действия. • Явно указав, каким клиентам разрешается получать доступ к ресурсам Samba. За эту часть конфигурации отвечает находящаяся в файле smb. conf конструкция hosts allow. Всегда проверяйте, чтобы в ней содержались только необходимые IP-адреса (или диапазоны адресов). • Заблокировав возможность получения доступа к серверу людьми, де работающими в данной организации. Samba использует шифрование только для аутентифика- ции пароля. При транспортировке данных шифрование не применяется. В зависи- мости от природы хранящихся на сервере Samba данных, администратор может за- блокировать возможность получения доступа к серверу за пределами организации, дабы исключить вероятность случайной загрузки файлов посторонними людьми. Это обычно делается на уровне сетевого брандмауэра; Samba использует UPD-nop- ты 137-139 и ТСР-порты 137, 139 и 445. После выхода версии Samba 3 превосходная документация стала доступна на сайте samba.org. Пакет Samba поставляется с разумными значениями по умолчанию для большинства его конфигурационных опций, поэтому для большинства сайтов будет вполне достаточ- но небольшого конфигурационного файла. При помощи команды testparm -v можно отобразить перечень всех конфигурационных опций Samba и значений, которые для них установлены на текущий момент. Этот перечень будет включать как параметры, задан- ные в файле smb. conf, так и параметры, установленные по умолчанию. Параметры в файле smb. conf лучше не изменять, если только они не отличаются от параметров по умолчанию или имеется веская причина их заблокировать. Преиму- 1 Компания HP предлагает производный от пакета Samba продукт, который называется HP CIFS Server. Его можно загрузить из хранилища программного обеспечения компании HP
1190 Часть III. Разное ществом такого подхода является то, что в таком случае при обновлении до более новой версии Samba текущая конфигурация будет автоматически адаптировать параметры, ре- комендуемые авторами Samba. Приняв во внимание сказанное выше, обязательно проверяйте, чтобы была включе- на функция шифрования паролей. encrypt passwords = true Эта опция отвечает за шифрование паролей, которыми обмениваются клиенты Win- dows и сервер Samba. На текущий момент она является параметром по умолчанию, и се- рьезной причины, по которой ее действительно лучше было бы отключить, не существует. Функция шифрования вынуждает сервер Samba сохранять специальный, имеющий вид хеш-значения Windows-пароль для каждого пользователя. Windows-пароли работают совершенно не так, как UNIX-пароли, и поэтому использовать их из каталога /etc/ shadow невозможно.2 Пакет Samba предоставляет для установки этих паролей специальную утилиту — smbpasswd. Например, попробуем добавить пользователя tobi и установить для него пароль. $ sudo smbpasswd -a tobi New SMB password: <пароль> Retype new SMB password: <пароль> Пользователи тоже могут изменять свои собственные пароли в системе Samba при помощи smbpasswd. $ smbpasswd -г smbserver -U tobi New SMB password: <пароль> Retype new SMB password: <пароль> В этом примере на сервере smbserver изменяется пароль пользователя tobi. Кодирование имен файлов Начиная с версии 3.0 все имена файлов в пакете Samba кодируются в формате UTF-8. Тем, у кого сервер работает в режиме кодировки UTF-8, очень повезло: у них будет иде- альная совместимость.3 Тем, кто находится в Европе и до сих использует на своем сер- вере один из режимов кодировки ISO 8859, повезло меньше: их имена файлов, содержа- щие специальные символы, наподобие а, о, и или е, будут выглядеть довольно странно при вводе команды 1s в каталоге, в котором эти файлы были созданы в пакете Samba с помощью кодировки UTF-8. Решением является указать пакету Samba использовать тот же режим кодировки символов, что и на сервере. unix charset = ISO8859-15 display charset = ISO8859-15 Правильность режима кодировки лучше проверять сразу. Иначе количество файлов со странно закодированными именами начнет расти, и их исправление позже может оказаться довольно нелегкой задачей. 2 При установлении соединения система Windows передает мандаты пользователя серверу Samba, поэтому пароли пользователя в пакете Samba выбираются так, чтобы они совпадали с их паролями в системе Windows. 3 Проверить, может ли система работать в режиме кодировки UTF-8, можно при помощи ко- манды echo $LANG.
Глава 50. Взаимодействие с системой Windows 1191 Аутентификация пользователей В системах аутентификации Windows клиент не доверяет серверу, т.е. пароль поль- зователя никогда не передается по сети в виде открытого текста. Вместо этого система Windows использует алгоритм типа “запрос-ответ” протокола Kerberos. Клиент Windows также может аутентифицироваться у пакета Samba с помощью протокола Kerberos. Если при входе в систему Windows предоставить имя пользователя и пароль, Windows сохранит их и будет пытаться использовать эту информацию для аутентификации вез- де, где это необходимо, при помощи соответствующего аутентификационного запро- са. Таким образом, если пользователь имеет такое же имя пользователя и пароль на Windows-компьютере, как и на Samba-сервере, Samba не будет явно запрашивать у него пароль при получении им доступа к совместно используемым ресурсам Samba. Вся про- цедура аутентификации будет выполняться незаметно на заднем фоне. Недостатком подхода с аутентификацией типа “запрос-ответ” является то, что серве- ру приходится сохранять пароли в формате, эквивалентном открытому тексту. В действи- тельности серверные копии паролей локально шифруются, но это защищает их только от случайного просмотра. Злонамеренный пользователь, получивший доступ к зашиф- рованным таким образом паролям, сможет использовать их для получения доступа к ас- социируемым с ними учетным записям без какого-либо дополнительного “взламыва- ния”. Пароли Samba следует защищать даже более тщательно, чем файл /etc/shadow. В сложных средах со множеством серверов Samba имеет смысл использовать центра- лизованную службу каталогов, проверяющую, чтобы на всех серверах был указан оди- наковый пароль. В качестве аутентификационных служб Samba позволяет использовать службу LDAP и Windows. Служба LDAP описана в главе 19. Существует два основных способа объединить системы аутентификации Windows и UNIX. Во-первых, можно сконфигурировать сервер Samba так, чтобы он выступал в роли первичного контроллера домена Windows Active Directory (см. раздел 30.9). Во- вторых, можно установить на Windows-клиентах приложение pGina (sourceforge. net/ projects/pgina). Это интеллектуальное приложение заменяет стандартную систему регистрации Windows на каркас, который поддерживает все стандартные службы аутен- тификации, включая LDAP и NIS. Совместное использование основных файлов Когда у каждого пользователя имеется свой домашний каталог, имеет смысл сделать доступными для совместного использования домашние каталоги. [homes] comment = Home Directories (Домашние каталоги) browseable = no valid users = %S writeable = yes guest ok = no Эта конфигурация, например, позволит пользователю oetiker получать доступ к своему домашнему каталогу через путь \сервер—San?baoetiker с любой системы Windows. На некоторых сайтах установленные стандартные разрешения на домашних катало- гах системы UNIX позволяют людям просматривать файлы друг друга. Поскольку пакет Samba ограничивает доступ на основании разрешений, имеющихся у файлов системы UNIX, пользователи системы Windows, заходящие через CIFS, тоже смогут просматри-
1192 Часть III. Разное вать домашние каталоги друг друга. Однако, как показывает опыт, такое поведение ча- сто смущает пользователей Windows и вызывает у них чувство, будто бы они находятся у всех на виду. Строка valid users в показанном выше фрагменте конфигурации ука- зывает Samba предотвращать подключения к домашним каталогам других людей. Не до- бавляйте ее, если такое поведение вас не устраивает. Пакет Samba обращается к своему волшебному разделу [homes] только в крайнем случае. Если в конфигурации для домашнего каталога пользователя явно указан какой- нибудь определенный совместно используемый ресурс, установленные там параметры перекрывают значения, указанные в разделе [homes]. Групповые ресурсы Пакет Samba может отображать списки управления доступом в системе Windows либо в разрешения файлов, либо в списки ACL (если лежащая в основе файловая система поддерживает их). На практике концепция списков ACL часто оказывается слишком сложной для большинства пользователей. Поэтому администраторы обычно просто создают отдельный совместно используемый ресурс для каждой группы пользователей, которые в таковом нуждаются, и конфигурируют сервер Samba так, чтобы он сам за- ботился о предоставлении нужных разрешений. Дальше, когда пользователь пытается смонтировать этот сетевой каталог, Samba проверяет, является ли он членом соответ- ствующей группы пользователей UNIX, и заменяет его уникальный идентификатор (UID) на идентификатор владельца этого группового сетевого ресурса (т.е. созданного специально для этой цели псевдопользователя). Рассмотрим пример. [eng] comment = Group Share for engineering ; Каждый, кто является членом группы eng, может получать доступ к этому ; совместно используемому ресурсу comment = Group Share for engineering ; Каждый, кто состоит в группе eng, может получать доступ к этому ; совместно используемому ресурсу ; Пользователям придется входить в систему при помощи своей ; учетной записи Samba) valid users = @eng ; Мы создали специальную пользовательскую учетную запись по имени "eng". ; Все записываемые в этот каталог файлы будут принадлежать этой учетной ; записи, а также группе eng force user = eng force group = eng path = /home/eng ; Отключаем все ACL-списки NT, потому что мы не собираемся ; использовать их здесь nt acl support = no ; Делаем так, чтобы у всех файлов были приемлемые разрешения create mask = 0660 force create mask = 0660 security mask = 0000 directory mask = 2770 force directory mask = 2770 directory security mask = 0000 /Обычные параметры для совместного пользования browseable = no
Глава 30. Взаимодействие с системой Windows 1195 writeable = yes guest ok = no Подобного эффекта можно добиться и при помощи такой опции пакета Samba, как inherit permissions. Если активизировать эту опцию на совместно используемом ре- сурсе, все новые файлы и каталоги будут наследовать свои параметры от родительского каталога. [eng] comment = Group Share for engineering path = /home/eng nt acl support = no browseable = no writeable = yes inherit permissions = yes Поскольку теперь пакет Samba будет брать параметры из родительского каталога, важно не забыть правильно установить разрешения на корневом каталоге этого совмест- но используемого ресурса. $ sudo chmod u=rw,g=rws ,о= /home/eng $ sudo chgrp eng /home/eng $ sudo chown eng /home/eng Обратите внимание на то, что при такой конфигурации все равно нужно создать псевдопользователя eng, который будет выступать в роли владельца данного совместно используемого каталога. Прозрачная переадресация при помощи MS DFS MS DFS (Microsoft’s Distributed File System — Распределенная файловая система про- изводства компании Microsoft) позволяет каталогам внутри совместно используемого ре- сурса заставлять клиентов автоматически монтировать другие совместно используемые ресурсы, как только к ним будет получен доступ. Для постоянных пользователей систем UNIX и Linux в этом нет ничего удивительного, но для системы Windows эта концепция, в целом, является довольно революционной и неожиданной. Приведем пример. [global] ; Включить поддержку MS DFS для данного сервера Samba host msdfs = yes [mydfs] ; Эта строка указывает Samba искать символические ссылки ; в каталоге данного совместно используемого ресурса msdfs root = yes path = /home/dfs/mydfs Для того чтобы настроить автоматическое монтирование, нужно создать соответ- ствующие символические ссылки в каталоге /home/dfs/mydfs. Например, показанная ниже команда превращает “каталог” junq? в ссылку на один из двух каталогов на других серверах. (Обратите внимание на одинарные кавычки. Они необходимы для защиты об- ратной косой черты.) Если указывается несколько источников (как здесь), Windows будет выбирать какой- нибудь один из них. Другими словами, пользователи, получающие доступ к каталогу \servermydfs jump, теперь фактически будут считывать файлы либо из источника
1194 Часть III. Разное shareX на сервере serverX, либо из источника shareY на сервере shareY, в зависимости от того, какой из них будет доступен. Если файловые системы экспортируются с разреше- ниями не только на чтение, но и на запись, обязательно нужно позаботиться о механиз- ме для синхронизации файлов. На эту роль может подойти приложение rsync. Пакет Samba также позволяет делать так, чтобы все клиенты, получающие доступ к определенному источнику совместного пользования, перенаправлялись на какой- нибудь другой сервер. Windows-сервер такого не позволяет. [myredirect] msdfs root = yes msdfs proxy = WserverZshareZ Обратите внимание на то, что система DFS будет работать только для тех пользова- телей, которые имеют одинаковое имя пользователя и пароль на всех задействованных серверах. Программа smbclient: простой клиент CIFS Помимо множества серверных функциональных возможностей, в состав пакета Sam- ba также входит удобная программа для пересылки (передачи) файлов с интерфейсом командной строки, которая называется smbclient. Этой программой можно пользо- ваться для получения прямого доступа к любому серверу Windows или Samba. $ smbclient //redmond/joes -U joe Password: <пароль> Doman=[REDMOND] 0S=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb: > После успешной регистрации на файловом сервере можно приступать к навигации и передаче файлов, используя для этого стандартные команды в стиле ftp (такие, как get, put, cd, led и dir). Поддержка системы CIFS на клиентской стороне системы Unux Система Linux включает прямую клиентскую поддержку для файловой системы SMB/CIFS. Это значит, что в любой файловой системе Linux можно смонтировать CIFS- ресурс совместного пользования, который ядро будет понимать непосредственно. # mount -t smbfs -о username=joe //redmond/joes /home/joe/mnt Хотя эта функциональная возможность и является полезной, следует помнить о том, что система Windows воспринимает монтируемые сетевые каталоги как устанавливаемые определенным пользователем (отсюда и опция usemame=joe в показанной выше стро- ке), в то время как система UNIX воспринимает их больше как принадлежащие системе в целом. Windows-серверы обычно не могут понять концепцию, подразумевающую, что к смонтированному сетевому Windows-каталогу могут получать доступ несколько разных пользователей. С точки зрения UNIX-клиента, все файлы в смонтированном каталоге принадлежат пользователю, который его смонтировал. Другими словами, если сетевой каталог смон- тировать от лица пользователя root, тогда все файлы в нем будут принадлежать пользо- вателю root и, следовательно, обычные пользователи не смогут записывать в него ника- кие файлы на Windows-сервере. Опции монтирования uid, gid, fmask и dmask позволяют настраивать эти параме- тры так, чтобы права владения и доступа более точно отражали предусматриваемую для
Глава 30. Взаимодействие с системой Windows 1195 данного сетевого каталога политику. Подробнее об этом поведении можно узнать на странице руководства mount. smbf s. Для того чтобы позволить пользователю самостоятельно монтировать сетевой Win- dows-каталог, можно добавить в файл /etc/fstab следующую строку. //redmond/joes /home/joe/mnt smbfs username=joe, fmask=600,dmask=700, user, noauto 0 0 Благодаря указанной здесь опции user, пользователи теперь смогут монтировать фай- ловую систему путем выполнения следующей команды. $ mount /home/joe/mnt Команда mount будет предлагать пользователю ввести пароль, прежде чем монтиро- вать сетевой каталог. Хотя стандартной сетевой файловой службой для UNIX является NFS, в некоторых ситуациях для обмена файлами между компьютерами UNIX и Linux лучше использо- вать Samba или CIFS. Например, опасно позволять пользователям выполнять NFS- монтирование корпоративных файловых систем со своих персональных ноутбуков4. Однако можно безопасно использовать CIFS для предоставления этим ноутбукам досту- па к домашним каталогам их владельцев. Ш Об NFS более подробно рассказывалось в главе 18. 30.7. Совместное использование принтеров при помощи Samba Простой способ обеспечить возможность совместного использования принтеров — добавить в файл smb. conf раздел [printers ] :. Это заставит пакет Samba сделал. До- ступными для совместного пользования все локальные принтеры. Для выполнения сво- ей работы пакет Samba пользуется командами системы печати, но поскольку печать в системе UNIX не очень стандартизирована, может понадобиться указать Samba/какая именно система печати используется на сервере, путем установки для опции printing соответствующего значения. Перечень поддерживаемых на текущий момент систем пе- чати доступен на справочной странице smb. conf. [printers] ; Где должны сохраняться файлы, прежде чем они будут переданы системе печати? path = /var/tmp ; Пользоваться принтерами разрешается всем guest ok = yes ; Пусть Samba знает, что в данном случае совместно используемым ресурсом ; является принтер printable = yes ; Показывать принтеры всем, кто их ищет browseable = yes ; Указать Samba, какая подсистема печати используется в системе printing = LPRNG 4 Механизм безопасности в службе NFSv3 основан на идее, что пользователь не имеет прав суперпользователя на клиентском компьютере и что идентификаторы на клиентской и серверной сторонах совпадают. Для самоуправляемых машин это неестественно. Система NFSv4 лучше осу- ществляет отображение пользовательских идентификаторов и намного безопаснее.
1196 Часть III. Разное Windows-клиенты теперь смогут пользоваться этими принтерами как сетевыми, точно так же как если бы те обслуживались Windows-сервером. Однако существует небольшая проблема. Windows-клиенты захотят знать, принтер какого именно типа им достался, и пригласят пользователя выбрать подходящий драйвер принтера. Это чревато посту- плением довольно большого количества просьб о помощи от пользователей, которые не знают, как поступать в такой ситуации. А если какой-то из имеющихся принтеров требу- ет драйвер, не поставляемый с Windows, тогда этих просьб будет еще больше. Ш Более подробно о печати рассказывалось в главе 26. К счастью, сервер Samba можно сконфигурировать так, чтобы он предоставлял не- обходимые Windows-драйверы принтеров всем Windows-клиентам. Однако прежде чем это делать, нужно выполнить кое-какие подготовительные операции. Следует гаранти- ровать, что пакет Samba будет вести себя как сервер печати, добавив соответствующие записи в раздел [global] файла smb. conf. [global] ;Кто у нас отвечает за администрирование принтеров printer admin = printadm ; Следующий параметр по умолчанию всегда имеет указанное справа значение disable spoolss = no ; Не пытайтесь отобразить эту информацию; вы все равно ; не можете добавлять принтеры show add printer wizard = no ; Если нужно, чтобы выполнять печать могли все guest ok = yes browseable = no Теперь программа Samba знает, что является сервером печати, и будет воспринимать пользователя printadm как своего администратора. Если вы собираетесь предоставлять драйверы принтера для своих Windows-клиентов, тогда у вас должно быть место для хранения этих драйверов. Таким местом может быть специальный сетевой каталог (share) [print$ ]. [print$] comment = Printer Driver Area ; Место для хранения драйверов принтеров path = /var/lib/samba/printers browseable = yes guest ok = yes read only = yes /Кому разрешено администрировать репозиторий драйверов принтеров write list = printadm Прежде чем загружать драйверы принтеров на новый сервер печати, следует позабо- титься еще о нескольких деталях на уровне системы. Во-первых, нужно удостовериться в том, что учетная запись printadm существует и имеет права на получение доступа к серверу Samba. $ sudo useradd printadm $ sudo smbpasswd -a printadm Во-вторых, система Samba сможет сохранять драйверы принтеров только при усло- вии, если соответствующая структура каталогов уже существует и ее владельцем являет- ся пользователь printadm (как указано в опции write list).
Глава 30. Взаимодействие с системой Windows 1197 $ sudo mkdir -р /var/lib/samba/printers $ sudo cd /var/lib/samba/printers $ sudo mkdir W32X86 WIN40 $ sudo chown -R printadm . Здесь возможно два варианта: либо загрузить драйверы принтеров с Windows- компьютера, либо воспользоваться средствами системы Samba и сделать это все из ко- мандной строки. К сожалению, простого способа узнать, что именно должно устанав- ливаться для конкретного драйвера, нет, поэтому в большинстве случаев рекомендуется первый вариант. Только если предстоит повторно устанавливать драйвер на множестве серверов, имеет смысл изучить процедуру его установки и научиться воспроизводить ее при помощи средств командной строки. Установка драйвера принтера из системы Windows Для того чтобы установить драйверы принтеров с Windows-клиента, установите со- единение с сервером Samba путем ввода в диалоговом окне Run, появляющемся после выбора в меню Start команды Run, следующей строки: сервер-Samba. example. com. Windows попросит ввести имя пользователя и пароль для входа на сервер Samba. Введите имя пользователя и пароль учетной записи printadm. Если все пойдет хорошо, появит- ся окно со списком имеющихся на этом сервере сетевых папок. Отыщите подпапку Printers; в ней должны отображаться принтеры, которые были сделаны доступными для совместного использования. Щелкните правой кнопкой мыши на каком-нибудь пустом месте между пиктограммами принтеров, чтобы отобразить диа- логовое окно Server Properties, и добавьте свои любимые драйверы принтеров через вкладку Drivers. Загружаемые драйверы будут помещаться в каталог, указанный в [ print $ ]. На этом этапе можно будет быстренько заглянуть в свойства того или иного загруженного драй- вера. Именно этот список файлов придется предоставлять утилите командной строки Samba, если когда-нибудь возникнет желание автоматизировать процесс загрузки этого драйвера. Загрузив все необходимые драйверы, следует связать их с конкретными принтерами. Для того чтобы сделать это, отобразите панель Properties каждого принтера по очереди (щелкая правой кнопкой мыши и выбирая в появляющемся контекстном меню коман- ду Properties) и выберите подходящий драйвер на вкладке Advanced. Затем откройте диалоговое окно Printing Defaults и измените параметры печати. Даже если указанные параметры печати вас устраивают, все равно внесите хоть какое-нибудь небольшое из- менение, чтобы вынудить систему Windows сохранить структуры данных конфигурации на сервере Samba. Тогда система Samba будет предоставлять эти данные получающим доступ к принтеру клиентам. Невыполнение последнего шага может привести к сбоям на клиентах, из-за невозможности отыскать подходящую конфигурацию при попытке использования принтера. Инсталляция принтера из командной строки Как вы уже, наверняка, догадались, некоторые из перечисленных шагов довольно трудно воспроизвести, не используя систему Windows, особенно это касается установ- ки принтерных параметров по умолчанию. Но если на сервере Samba нужно установить сотни принтеров, все-таки имеет смысл попробовать сделать это из командной строки. Такой метод особенно хорошо подходит для PostScript-принтеров, потому что Windows-
1198 Часть III. Разное драйвер для PostScript-принтеров работает правильно и без информации о конфигура- ции по умолчанию. Итак, если вы знаете, какие файлы требуются для данного драйвера, сможете устано- вить этот драйвер из командной строки. Для того чтобы сделать это, сначала скопируйте требующиеся файлы в каталог [print$]. $ cd ~/туdriver $ smbclient -U printadm '//samba-server/print$' -c 'input *.*' Далее назначьте драйвер определенному принтеру. Предположим, что используется простой PostScript-принтер со специальным PPD-файлом. $ rpcclient -U printadm -с " adddriver "Windows NT х8б" "Our Custom PS: PSCRIPT5. DLL: CUSTOM. PPD: PS5UI. DLL: PSCIPT. HLP: NULL:NULL: PSCRIPT. NTF " " samba-server Символы обратной косой черты в конце строк позволяют разбить команду на не- сколько отдельных строк для ясности; вы можете опустить их и ввести команду в виде одной строки, если хотите. Символы обратной косой черты перед двойными кавычками указывают на наличие вложенных наборов кавычек. В длинной строке приведенного выше примера содержится информация, отображае- мая в диалоговом окне свойств принтерного драйвера, которое доступно, когда драйвер принтера устанавливается из Windows. • Длинное имя принтера. • Имя файла драйвера. • Имя файла данных. • Имя конфигурационного файла. • Имя справочного файла. • Имя языкового монитора (указывайте здесь значение NULL, если языкового мо- нитора нет). • Тип данных по умолчанию (указывайте здесь значение NULL, если такого типа данных нет). • Разделенный запятыми список дополнительных файлов. Сконфигурировать принтер так, чтобы он использовал один из загруженных драйве- ров, можно, выполнив такую команду. $ rpcclient -U printadm -с " set driver "myprinter" "Our Custom PS"" samba-server 30.8. Отладка сервера Samba Обычно сервер Samba работает нормально, не требуя никакого особого внимания. Но если проблема все-таки появилась, попробовать выявить ее источник можно при помо- щи двух таких основных источников отладочной информации, как журнальные файлы отдельных клиентов и команда smbstatus. Для начала нужно удостовериться в наличии соответствующих параметров журнальных файлов в своем конфигурационном файле. [global] ; Комбинация символов %т указывает, что для каждого клиента должен ; записываться отдельный файл.
Глава 30. Взаимодействие с системой Windows 1*199 log file = /var/log/samba.log.%m max log size = 1000 ; Объем подлежащей регистрации (занесению в журнал) информации. ; Также можно указывать уровень регистрации для компонентов системы. ; (Здесь указывается, что в общем должен использоваться уровень 3, ; но для аутентификации должен использоваться уровень 10.) log level = 3 auth: 10 Чем выше уровень регистрации, тем больше объем отладочной информации. На за- несение данных в журналы тратится определенное время, поэтому не стоит требовать слишком большого количества деталей до тех пор, пока они не понадобятся для отлад- ки, потому что это может замедлить работу системы. Ниже показаны журнальные записи, сгенерированные после одной неуспешной и одной успешной попыток соединения. [2004/09/05 16:29:45, 2] auth/auth.c:check_ntlm_password(312) check_ntlm__password: Authentication for user [oetiker] -> [oetiker] FAILED with error NT_STATUS_WRONG_PASSWORD [2004/09/05 16:29:45, 2] smbd/server.c:exit_server(571) Closing connections [2004/09/05 16:29:57, 2] auth/auth.c:check_ntlm_password(305) check_ntlm_password: authentication for user [oetiker] -> [oetiker] -> [oetiker] succeeded [2004/09/05 16:29:57, 1] smbd/service.c:make_connection_snum(648) etsuko (127.0.0.1) connect to service oetiker initially as user oetiker (uid=1000, gid=1000) (pid 20492) [2004/09/05 16:29:58, 1] smbd/service.c:close_cnum(837) etsuko (127.0.0.1) closed connection to service oetiker [2004/09/05 16:29:58, 2] smbd/server.c:exit_server(571) Closing connections Команда smbcontrol позволяет изменять уровень отладки на функционирующем сервере Samba без внесения изменений в файл smb. conf. Рассмотрим пример. $ sudo smbcontrol smbd debug "4 auth: 10" Эта команда установила бы для общих отладочных данных уровень 4, а для данных, связанных с аутентификацией, — уровень 10. Аргумент smbd указывает, что такие уров- ни отладки должны быть установлены для всех демонов smbd в системе. Выполнит^ от- ладку конкретного установленного соединения можно следующим образом: использо- вать команду smbstatus для выяснения того, какой демон smbd обслуживает данное соединение, а затем передать его идентификатор (PID) команде smbcontrol, чтобы та выполнила отладку именно этого соединения. При уровнях журнализации свыше 100 в журналах начнут появляться (зашифрованные) пароли. Команда smbstatus отображает информацию об активных соединениях и заблоки- рованных файлах. Эта информация может особенно пригодиться при выявлении про- блем блокировки (например, для выяснения, кто из пользователей открыл файл xyz для чтения/записи в монопольном режиме). В первом разделе ее выходных данных перечис- ляются все ресурсы, к которым подключался пользователь, а во втором — любые актив- ные блокировки файлов. Samba version 3.0.5 PID Username Group Machine 13036 zauck ее zhaka (192.168.1.228) 29857 milas guests beshil (192.168.1.123)
1200 Часть III. Разное Service pid machine Connected at milasa 29857 beshil Fri Sep 3 17:07:39 2004 zaucker 13036 zhaka Thu Sep 2 12:35:53 2004 Locked : files: Pid DenyMode Access R/W Oplock Name 29857 DENY_NONE 0x3 RDWR NONE /home/milasa/hello.dba 13036 DENY_NONE 0x2019f RDWR NONE /home/zaucker/aufbest.doc Если уничтожить демон smbd, ассоциируемый с определенным пользователем, все его блокировки исчезнут. Некоторые приложения умеют справляться с этим и бу- дут просто заново ставить блокировку, если она им нужна. Другие приложения (такие, как MS Access) будут зависать или “умирать страшной смертью”, требуя выполнения множества щелчков на стороне Windows только для того, чтобы их закрыли. И как бы странно это ни звучало, но такая процедура все-таки пока еще никогда не приводила к повреждению. Но в любом случае к заявлениям системы Windows о том, файлы были заблокированы каким-нибудь другим приложением, все-таки следует относиться с осто- рожностью. Нередко система Windows оказывается права, и проблему можно устранить, просто закрыв приложение на клиентской стороне, вместо того чтобы применять к нему “грубую силу” на стороне сервера. 30.9. Аутентификация службы Active Directory Рабочие столы системы Windows, притаившиеся в вашей сети, скорее всего, исполь- зуют систему Active Directory компании Microsoft для аутентификации, доступа к ката- логам и выполнения других сетевых операций. Служба Active Directory собирает пользо- вателей, группы, компьютеры и правила операционной системы под общим зонтиком, централизуя и упрощая системное администрирование. Кроме того, это одна из основных причин, по которым система Windows занимает устойчивое положение на многих предприятиях. Система UNIX собрала воедино неко- торые фрагменты этой головоломки, но ни одно из реализованных в системе UNIX ре- шений не было так отшлифовано и широко признано, как служба Active Directory. Ш Информацию о системе РАМ можно найти в разделе 22.5. Пользуясь хитроумными способами, разработчики проекта Samba сделали много ша- гов в направлении поддержки службы Active Directory в системах UNIX и Linux. С по- мощью пакета Samba системы семейства Linux могут присоединять домен Active Direc- tory и открывать доступ в систему по учетным записям, определенным в службе Active Directory и не отраженным в файле /etc/passwd. Идентификаторы пользователей в системе Linux выведены из своих аналогов, суще- ствующих в системе Windows и известных как идентификаторы безопасности, или SID. С помощью системы РАМ можно автоматически создать домашний каталог для поль- зователя, который его еще не имел. Эта система интеграции позволяет даже выполнять команду passwd, чтобы изменить пароль пользователя в службе Active Directory. Вся эта магия интеграции, присущая системе Windows, осуществляется компонентом пакета Samba под названием winbind. Служба Active Directory включает в себя и расширяет несколько стандартных про- токолов, в частности LDAP и Kerberos. Стремясь максимально удовлетворить запросы
Глава 30. Взаимодействие с системой Windows 1201 администраторов информационных систем, компания Microsoft, к сожалению, пожерт- вовала совместимостью с оригинальными протоколами, создав токсичные зависимо- сти сети веб от лицензионных технологий удаленного вызова процедур (RPC — Remote Procedure Call). Ш Информация о переключении службы имен изложена в разделе 19.5. Для эмуляции поведения клиента службы Active Directory демон winbind вносит из- менения в протоколы РАМ, NSS и Kerberos. Он преобразует запросы на аутентифи- кацию и получение системной информации в соответствующие форматы, характерные для продуктов компании Microsoft. С точки зрения системы UNIX, служба Active Direc- tory — это просто другой источник информации о каталоге LDAP и данных аутентифи- кации по протоколу Kerberos. Вы должны выполнить следующие процедуры, связанные с конфигурированием, прежде чем система Linux сможет войти в сферу действия службы Active Directory. • Инсталлируйте пакет Samba с поддержкой службы Active Directory и преобразова- нием идентификаторов. • Конфигурируйте переключение службы имен nsswitch. conf, чтобы использо- вать демона winbind как источник информации о пользователе, группе и пароле. • Конфигурируйте систему РАМ для обслуживания запросов на аутентификацию с помощью демона winbind. • Конфигурируйте службу Active Directory как сферу действия протокола Kerberos. Ш Более подробно система DNS описана в главе 17. Клиенты службы Active Directory в системах UNIX и Linux также должны использо- вать контроллеры этой службы, чтобы обслуживать свои DNS-запросы и согласовывать свою работу с протоколом NTP. Кроме того, следует принять меры, чтобы полностью определенное системное имя домена было указано в файле /etc/hosts. В некоторых ситуациях в файл etc/hosts необходимо также добавить IP-адрес контроллера домена. Однако мы не рекомендуем это делать, если вы используете службу Active Directory для работы с системой DNS. Демон winbind отлично работает в системе Linux, но система UNIX осталась за бор- том. Нам известны отчеты о сайтах UNIX, в которых успешно развернута общая схема, описанная выше, но каждая система имеет свои тонкости, а интеграция в системе UNIX выполняется не так безукоризненно, как в системе Linux. Для систем UNIX мы предла- гаем один из описанных ниже вариантов. Подготовка к интеграции службы Active Directory Пакет Samba по умолчанию включен в большинство дистрибутивов системы Linux, но некоторые дистрибутивы не содержат службы отображения идентификаторов, необ- ходимые для полной реализации клиента службы Active Directory. Компилируя модули из исходного кода, придется тщательно настраивать эти компоненты, поэтому мы ре- комендуем инсталлировать готовые пакеты исполняемых модулей, если есть такая воз- можность. С другой стороны, компоненты Samba должны быть как можно более современны- ми. Интеграция службы Active Directory представляет собой одну из новейших функцио- нальных возможностей пакета Samba, поэтому загрузка последней версии кода с сайта samba. org поможет избежать неприятных ошибок.
1202 Часть III. Разное Если вы создаете систему Samba на основе исходного кода, настройте ее с помощью совместно используемых модулей idmap__ad и idmap_rid. Соответствующий аргумент в сценарии . /configure должен иметь следующий вид. —wi th-shared-modules=idmap_ad , idmap__rid Соберите и инсталлируйте систему Samba с помощью уже знакомой вам последова- тельности команд make, sudo make install. Если система инсталлирована правильно, библиотека winbind будет размещена в ка- талоге /lib. ubuntu$ Is -1 /lib/libnss_winbind.so.2 -rw-r—r— 1 root root 21884 2009-10-08 00:28 /lib/libnss_winbind.so.2 Демон winbind останавливается и запускается с помощью обычных системных про- цедур. После изменения файлов nsswitch.conf, smb.conf или файла конфигурации протокола Kerberos krb5. conf его следует запустить повторно. Его не следует запускать, пока не выполнено конфигурирование других служб. Конфигурирование протокола Kerberos для интеграции службы Active Directory Протокол Kerberos не удобен для сложной конфигурации, особенно на серверной стороне. К счастью, нам достаточно настроить только клиентскую сторону протокола Kerberos, что представляет собой намного более простую задачу. Файл конфигурации имеет имя /etc/krb5. conf. Во-первых, следует убедиться, что полное системное имя домена включено в файл /etc/hosts и что протокол NTP использует сервер Active Directory для привязки по времени. Затем отредактируйте файл krb5. conf и добавьте в него приведенные ниже строки. Замените свой домен Active Directory на ULSAH. СОМ. [logging] default = FILE:/var/log/krb5.log [libdefaults] clockskew = 300 default_realm = ULSAH.COM kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] ULSAH.COM = { kde = dc.ulsah.com admin_server = dc.ulsah.com default_domain = ULSAH } [domain_realm] .ulsah.com = ULSAH.COM ulsah.com = ULSAH.COM В этом примере представляют интерес несколько значений. Даже несмотря на при- вязку по времени с помощью протокола NTP, допускается пятиминутное расхождение. Это дает определенный запас времени, если с протоколом NTP возникнет проблема. По умолчанию областью считается домен Active Directory, а центр распределения ключей
Глава 30. Взаимодействие с системой Windows 1203 (KDC — key distribution center) конфигурируется как домен контроллера Active Directory. Для отладки удобно пользоваться файлом krb5. log. Запросите билет у контроллера службы Active Directory, выполнив команду kinit. Укажите корректную учетную запись пользователя домена. Для проверки подойдет имя “administrator”, хотя учетная запись может быть любой. Когда получите приглашение, введите пароль домена. ubuntu$ kinit administrator@ULSAH.COM Password for administrator@ULSAH.COM: <password> Для демонстрации билета Kerberos следует использовать команду klist. ubuntu$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: administrator@ULSAH.COM Valid starting Expires Service principal 10/11/09 13:40:19 10/11/09 23:40:21 krbtgt/ULSAH.COM@ULSAH.COM renew until 10/12/09 13:40:19 Kerberos 4 ticket cache: /tmp/tktlOOO klist: You have no tickets cached Если билет выведен на экран, значит, аутентификация прошла успешно и протокол Kerberos сконфигурирован правильно. В данном случае билет действует еще 10 часов и может быть возобновлен через 24 часа. (Для отмены билета можно использовать коман- ду kdestroy.) Остальные параметры конфигурации можно найти на справочной странице krb5. conf. Программа Samba как член домена Active Directory Как и остальные компоненты пакета Samba, конфигурация демона winbind запи- сана в файле smb. conf. Конфигурируйте пакет Samba как член домена Active Directory с помощью параметра security = ads. Ниже приведена работоспособная конфигурация. Мы задали область Kerberos и ука- зали аутентификацию пакета Samba в контроллере домена. Мы также задали отображе- ние идентификаторов с помощью параметра idmap в файле smb.conf. Обратите внима- ние на то, что конфигурация отдельных общих ресурсов в файле smb. conf производится отдельно от конфигурации служб аутентификации Active Directory. [global] security = ads realm = ULSAH.COM password server = 192.168.7.120 workgroup = ULSAH winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%D/%U template shell = /bin/bash client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes
1204 Часть III. Разное winbind use default domain = yes restrict anonymous = 2 Большинство параметров очевидно, а детали можно найти на справочной странице smb. conf. Особого внимания заслуживает параметр winbind use default domain. Если вы используете несколько доменов Active Directory, то это значение должно быть равным по. Однако если вы используете только один домен, то присвоение этому параметру значе- ния yes позволит пропустить домен в ходе аутентификации (например, можно исполь- зовать домен “ben” вместо “ULSAHben”). Кроме того, значение winbind separator задает альтернативу обратной косой черте при указании имен пользователей. Значение workgroup должно быть коротким именем домена. Например, значение параметра workgroup для домена linux.ulsah.com может быть равным LINUX. Задав конфигу- рацию системы Samba, запустите ее и службы winbind снова, чтобы новые установки вступили в силу. И наконец, присоединим систему к домену; воспользуемся инструментом net из па- кета Samba, который позаимствовал синтаксис у команды системы Windows с тем же именем. Команда net принимает в качестве аргументов протоколы для взаимодействия с системой Windows. Для службы Active Directory мы используем параметр ads. Убедитесь, что билет существует, выполнив команду klist (и запросите его с по- мощью команды kinit, если билета еще нет), а затем для присоединения к домену ис- пользуйте следующую команду. ubuntu$ sudo net ads join -S DC.ULSAH.COM -U administrator Enter administrator’s password: <password> Using short domain name — ULSAH Joined 'UBUNTU' to realm 'ulsah.com' В командной строке мы указали сервер службы Active Directiry de. ulsah. com (что необязательно) и учетную запись администратора. По умолчанию служба Active Directory добавляет новую систему в раздел Computer иерархии домена. Если система оказывается в разделе Computers OU внутри оснастки Users and Computers службы Active Direc- tory, то операция присоединения к домену прошла успешно. Состояние системы можно также проверить с помощью команды net ads status. Дополнительные параметры, в том числе операции поиска протокола LDAP, указаны на справочной странице net. Конфигурация переключения службы имен проста. Сначала следует проверить си- стемные файлы passwd и group, а затем запустить службу Active Directory с помощью демона winbind. Этот трюк описывается в файле nsswitch. conf следующим образом. passwd: compat winbind group: compat winbind shadow: compat winbind После конфигурирования системы NSS можно выполнить распознавание пользова- теля и группы в службе Active Directory с помощью команды wbinf о. Для того чтобы увидеть список пользователей домена, используется команда wbinf о -и, а список групп выводит команда wbinfо -д. Команда getent passwd показывает учетные записи поль- зователей во всех источниках в формате /etc/passwd. ubuntu$ getent passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bwhaley:x:10006:10018::/home/bwhaley:/bin/sh
Глава 30. Взаимодействие с системой Windows 1205 guest:*:10001:10001:Guest:/home/ULSAH/guest:/bin/bash ben:*:10002:10000:Ben Whaley:/home/ULSAH/ben:/bin/bash krbtgt:*:10003:10000:krbtgt:/home/ULSAH/krbtgt:/bin/bash Отличить локальных пользователей от учетных записей домена можно только по идентификатору пользователя и по пути ULSAH в домашнем каталоге, который можно увидеть в последних трех записях. Если ваш сайт использует несколько доменов или параметр winbind use default domain не установлен, к учетной записи домена приписывается его короткое имя (на- пример, ULSAHben). Конфигурация системы РАМ Ш Общее описание системы РАМ дано в разделе 20.5. В данный момент мы настроили систему на взаимодействие со службой Active Direc- tory с помощью программы Samba, но аутентификация еще не сконфигурирована. На- строить систему РАМ на аутентификацию с помощью службы Active Directory довольно сложно, в основном, потому, что ее специфика зависит от конкретного дистрибутива системы Linux. Общая идея заключается в конфигурировании демона winbind как модуля аутен- тификации для всех служб, которым необходима поддержка службы Active Directory. В некоторых дистрибутивных пакетах, например в системе Red Hat, все службы удобно настраиваются в одном файле. В других, например в системе Ubuntu, параметры конфи- гурации распределены по нескольким файлам. В табл. 30.1 перечислены соответствую- щие файлы для каждого дистрибутивного пакета системы Linux. Таблица 30.1. Файлы конфигурации системы РАМ для поддержки демона winbind —----------------,.л............... ..................... , , .—-R'"" ;; Сеанс Ubuntu common-account, common-auth, sudo common-session SUSE common-auth, common-password, common-account common-session Red Hat system-auth common-auth Для того чтобы включить аутентификацию winbind, добавьте строку auth sufficient pam_winbind.so в начало каждого файла. Исключение составляет файл common-password в системе SUSE, в котором ключевое слово auth необходимо заменить словом password. password sufficient pam_winbind.so Система РАМ может автоматически создавать домашние каталоги при регистрации новых (для системы) пользователей. Поскольку пользователей службы Active Directory невозможно добавить стандартной командой useradd, которая обычно создает до- машние каталоги, эта функциональная возможность оказывается довольно удобной. Добавьте в файл конфигурации сессии системы РАМ, указанный в табл. 30.1, следую- щую строку. session required pam_mkhomedir.so umask=0022 skel=/etc/skel В этой конфигурации система РАМ создает домашние каталоги с разрешением на доступ в восьмеричном виде, равным 755, и профилями учетных записей, скопирован- ными из каталога /etc/skel.
1206 Часть III. Разное Вы можете также ограничить доступ к локальной системе для пользователей, входя- щих в конкретную группу Active Directory. Для этого следует добавить в файл конфигу- рации сессии службы РАМ следующие строки. session required /lib/security/$ISA/pam_winbind.so use_first_pass require_membership_of=unix_users В данном случае регистрироваться могут только пользователи из группы unix users службы Active Directory. Альтернатива демону winbind Несмотря на то что свободное подключение к службе Active Directory, описанное вы- ше, работает вполне хорошо, оно уязвимо к ошибкам и выглядит довольно сложным. Для администраторов, желающих осуществить относительно простую инсталляцию и по- лучить поддержку при устранении ошибок, существует альтернатива. Программы компании Likewise Software автоматизируют работу демона winbind, пе- реключение службы имен, протокола РАМ и конфигурирование отображения идентифи- каторов для более чем 100 дистрибутивных пакетов системы Linux и вариантов системы UNIX, включая все системы, рассмотренные в книге. Кроме того, они включают в себя агента групповой политики, который позволяет проводить централизованное конфигу- рирование систем UNIX, оснащенных службой Active Directory. Несколько надстроек к графическим пользовательским интерфейсам, включая консоль управления и оснаст- ку службы Active Directory, также упрощают инсталляцию и конфигурирование. Версии этого программного обеспечения с ограниченными функциональными возможностями доступны бесплатно, а полнофункциональные варианты и сопровождение предлагаются на коммерческой основе. Детали можно найти на сайте likewise. com. Еще одна возможность, которая позволяет полностью обойтись без демона winbind, — это комплект инструментов Quest Authentication Services. Он предлагает те же самые функциональные возможности, что и программы компании Likewise, но имеет дополнительные функции для управления групповой политикой. Приготовьте свои бу- мажники, потому что инструменты Quest недешевы. Полный список продукции можно найти на сайте quest. com/authentication-services. 30.10. Рекомендуемая литература • Terprstra, John Н. Samba-3 by Example: Practical Exercises to Successfill Deployment 2nd Edition. Upper Saddle River, NJ: Prentice Hall PTR, 2006. (Электронная версия этой книги доступна на сайте samba. org.) • Terprstra, John H., Jelmer R. Vemooij. The Official Samba-3 HOWTO and Reference Guide. (2nd Edition). Upper Saddle River, NJ: Prentice Hall PTR, 2006. (Электронная версия этой книги доступна на сайте samba. org.) 30.11. Упражнения 30.1. Зачем может понадобиться блокировать доступ через Интернет к портам 137-139 и 445 на сервере Samba?
Глава 30. Взаимодействие с системой Windows 1207 30.2. Инсталлируйте программу Cygwin на компьютере с системой Windows и восполь- зуйтесь утилитой ssh в эмуляторе rxvt, чтобы подключиться к компьютеру с си- стемой UNIX. Какие изменения появились в программе PuTTY? 30.3. ★ Сравните производительность работы клиента, имеющего доступ к файлам с по- мощью системы Samba, с производительностью клиента, имеющего доступ к фай- лам через “родной” сервер CIFS (т.е. компьютер с системой Windows). Ели на этих двух серверах установлено разное аппаратное обеспечение, целесообразно нивели- ровать влияние аппаратного обеспечения, чтобы влияние программного обеспече- ния проявилось ярче. (Может потребоваться доступ с правами суперпользователя.) 30.4. ★★ Воспользуйтесь анализатором пакетов (типа tcpdump или Wireshark) для пе- рехвата telnet-сеанса между Windows и UNIX, Инсталлируйте программу PuTTY и повторите процедуру. Проанализируйте результаты обеих проверок. (Необходим доступ с правами суперпользователя.) 30.5. Сконфигурируйте сервер печати Samba так, чтобы он использовал драйверы принтеров Windows для всех обслуживаемых им принтеров. Удостоверьтесь в том, что принтеры имеют приемлемую конфигурацию по умолчанию. 30.6. ★★ Настройте систему так, чтобы она аутентифицировала среду Active Directory. Примите меры, чтобы была возможность изменять пароль и при регистрации но- вых пользователей домашние каталоги создавались автоматически.
Глава 31 Последовательные устройства и терминалы Операционная система с сорокалетней историей, естественно, обросла хламом. К ка- тегории хлама можно отнести поддержку последовательных устройств, аргументируя это тем, что эту технологию доисторических времен лучше забыть. По сравнению с совре- менными мультимегабитовыми последовательными интерфейсами, такими как USB, тра- диционные последовательные порты кажутся медленными и пустячными. Понимание принципов работы последовательных интерфейсов — важная составляю- щая подготовки любого системного администратора. Хорошо ли, плохо ли, но интерфейс командной строки в системе UNIX основан на старинной концепции последовательного терминала и связанных с ней командах и управляющих устройствах, используемых и по сей день. Даже если вы никогда не приближались ближе 50 метров к кабельному терми- налу, по-прежнему используете функциональные возможности операционной системы, которые его поддерживают. Например, консольное окно на рабочем столе системы UNIX или Linux на самом деле представляет собой псевдотерминал, поскольку оно является устройством, с которым вы устанавливаете соединение, регистрируясь в сети. Настоящие последовательные порты RS-232 также используются до сих пор. Они больше не относятся к основным функциональным возможностям, но в некоторых си- туациях по-прежнему важны. Их можно использовать в качестве “общего знаменателя” для всех типов аппаратного обеспечения, от серверных менеджеров промышленного класса до встроенных систем миниатюрного масштаба, включая специальные проекты. Эту среду можно использовать для работы с устаревшими системами. В некоторых си- туациях их можно даже обнаружить под фальшполом. В этой главе рассказывается о том, как подключать к системе устройства после- довательного доступа RS-232 и использовать их в современной среде. В начале главы познакомимся с устройствами последовательного доступа и соответствующими кабель-
Глава 31. Последовательные устройства и терминалы 1209 ными системами. Затем речь пойдет о программном обеспечении, которое традиционно применялось для поддержки аппаратных и псевдотерминалов, которые их эмулируют. Оставшаяся часть главы содержит базовые сведения об использовании последователь- ных консолей в системах UNIX и Linux. 31.1. Стандарт RS-232C Большинство медленных последовательных портов работает в соответствии с одним из вариантов стандарта RS-232C. Этот стандарт определяет электрические характеристи- ки и назначение каждого сигнального провода, а также разводку контактов традицион- ного 25-контактного последовательного разъемного соединения DB-25 (рис. 31.1). Разъем Номера контактов Рис. 31.1. Вилка разъема DB-25 Поскольку стандарт RS-232C1 предназначен для распространения сигналов, многие из которых не используются в основных режимах передачи данных, в практической ра- боте полный набор сигнальных проводов не используется. Кроме того, разъемные сое- динения DB-25 слишком громоздки. Поэтому сейчас широко применяются альтерна- тивные модели 9-контактных разъемов, а не оригинальные 25-контактные. Кроме того, если возникает необходимость применять структурированные кабельные системы, аль- тернативой является разъем RJ-45. Эти разъемы описаны в разделе 31.2. На рис. 31.1 изображена вилка DB-25. Во всех последовательных разъемных соеди- нениях номера контактов на розетке зеркально отражают номера на вилке, чтобы при стыковке разъемов контакты с одинаковыми номерами совпадали. Схема в правой части рисунка соответствует показанной в левой части ориентации вилки. Обратите внимание: у разъема, изображенного на рисунке, всего семь штырьков. Это наиболее типичный случай. Сигналы интерфейса RS-232 и соответствующие им контак- ты разъемного соединения DB-25 перечислены в табл. 31.1. На практике используются только сигналы 1—8, остальные можно игнорировать. В отличие от стандартов разъемов, таких как USB и Ethernet, имеющих “защиту от дурака”, разъем RS-232 требует от пользователя, чтобы тот знал, какой тип устройства к нему подключен. Для последовательных устройств существует две конфигурации ка- бельной системы: DTE (Data Terminal Equipment — терминальное оборудование) и DCE (Data Communications Equipment — коммуникационное оборудование). Эти конфигура- ции определяют, какие сигналы устройство будет ожидать на тех или иных контактах разъемного соединения. 1 С технической точки зрения сегодня правильнее называть его стандартом EIA-232-E. Но если вы будете так говорить, вряд ли вас кто-нибудь поймет.
1210 Часть III. Разное Таблица 31.1. Сигналы интерфейса RS-232 и соответствующие им контакты разъемного соединения DB-25 Контакт Сигам г ... Контакт Дина», . • 1 FG — корпусная земля 14 STD — вторичный сигнал TD 2 TD — передаваемые данные 15 ТС — синхронизация передачи 3 RD — принимаемые данные 16 SRD — вторичный сигнал RD 4 RTS — готовность к передаче 17 RC — синхронизация приема 5 CTS — готовность к приему 18 Не назначен 6 DSR — готовность данных 19 SRTS — вторичный сигнал RTS 7 SG — сигнальная земля 20 DTR — готовность терминала 8 DCD — обнаружение несущей 21 SQ — детектор качества сигнала 9 Положительное напряжение 22 RI — индикатор вызова 10 Отрицательное напряжение 23 DRS — селектор скорости передачи данных 11 Не назначен 24 SCTE — внешняя синхронизация передачи 12 SDCD — вторичный сигнал DCD 25 BUSY—занято 13 SCTS — вторичный сигнал CTS Устройства конфигурируются либо в режиме DTE, либо в режиме DCE, хотя некото- рые поддерживают оба варианта (но не одновременно). Компьютеры, терминалы и прин- теры чаще всего относятся к типу DTE, тогда как модемы являются DCE-устройствами. Последовательные порты DTE- и DCE-устройств могут взаимодействовать друг с другом в произвольных сочетаниях, но в каждом конкретном случае требуются разные кабели. Смысла в одновременном существовании двух конфигураций нет, поскольку для всего оборудования может использоваться одна и та же разводка контактов. Просто это одно из многих бессмысленных наследий стандарта RS-232. Ниже перечислены особенности обеих конфигураций. • Разводка контактов в любом разъемном соединении RS-232 всегда одинакова, неза- висимо от того, вилка это или розетка (штырьки всегда совпадают с соответствую- щими отверстиями) и где находится разъем: на кабеле, DTE- или DCE-устройстве. • Спецификация RS-232 основана на модели прямого соединения DTE- и DCE-уст- ройств. Под “прямым” соединением понимается подключение линии TD DTE- устройства к линии TD DCE-устройства и так далее, т.е. все одноименные контак- ты соединяются друг с другом. • Названия сигналов отражают работу DTE-устройств. Например, название сигнала TD (transmitted data — передаваемые данные) в действительности означает “дан- ные, передаваемые от DTE-устройства к DCE-устройству”. Несмотря на это кон- такт TD служит для приема данных на DCE-устройстве. Аналогичным образом контакт RD является входным на DTE-устройстве и выходным на DCE-устройстве. • Когда кабелем соединяются два DTE-устройства (компьютер и терминал либо два компьютера), их нужно заставить воспринимать противоположную сторону как DCE-устройство. Например, оба устройства будут предполагать передачу данных по линии TD и прием — по линии RD, поэтому необходимо соединить провода крест-накрест, связав выходной контакт одного устройства с входным контактом другого и наоборот.
Глава 31. Последовательные устройства и терминалы 1211 • Подобное “перекрещивание” при соединении двух DTE-устройств требуется для трех групп сигналов: 1) TD и RD, о чем говорилось выше; 2) RTS и CTS; 3) кон- такт DTR должен быть соединен с контактами DCD и DSR на противоположном конце. Кабель, соединяющий два DTE-устройства, называют ну ль-модемным. Несмотря на это подключать к нему модемы нельзя, ведь модем — это DCE-устройство! Кабель для модемов называется просто “модемным” или “прямым”. На рис. 31.2 изображены разводки контактов и схемы соединений нуль-модемным и прямым кабелями. Показаны только “полезные” сигналы, используемые на практике. Легенда Прямо Нуль-модем Корпусная земля FG Передаваемые данные TD Принимаемые д анные rd Готовность к передаче RTS Готовность к приему CTS Готовность данных DSR Сигнальная земля SG Обнаружение несущей DCD Готовность терминала DTR Рис. 31.2. Разводки контактов и схемы соединения кабелей для разъемов DB-25 31.2. Альтернативные разъемные соединения В следующих подразделах описываются наиболее распространенные альтернатив- ные разъемные соединения: DB-9 и RJ-45. Несмотря на конструктивные различия, эти соединения обеспечивают передачу тех же электрических сигналов, что и разъем DB-25. Устройства, в которых используются разные разъемы, всегда совместимы, если правиль- но выбран переходный кабель. Разъем DB-9 Девятиконтактный разъем DB-9 (внешне напоминающий уменьшенный DB-25) обычно применяется в персональных компьютерах. Он обеспечивает передачу восьми сигналов стандарта RS-232 (рис. 31.3). Рис. 31.3. Вилка разъема DB-9
1212 Часть III. Разное У местных поставщиков персональных компьютеров обычно можно приобрести го- товые переходные кабели DB-9/DB-25. Соответствующая разводка контактов представ- лена в табл. 31.2. Таблица 31.2. Разводка контактов для прямого кабельного перехода DB-9 DB-9 Сигнал 3 TD — передаваемые данные 2 RD — принимаемые данные 7 RTS — готовность к передаче 8 CTS — готовность к приему 6 DSR — готовность данных 5 SG — сигнальная земля 1 DCD — обнаружение несущей 4 DTR — готовность терминала Разъем RJ-45 RJ-45 — это 8-проводной модульный телефонный разъем. Он облегчает прокладку последовательных соединений через существующую разводку, если здание оборудовано витой парой Ethernet. Гнезда RJ-45 практически не встречаются в компьютерах и обычных последователь- ных интерфейсах, но их часто применяют в качестве промежуточных соединителей при разводке линий последовательной передачи данных через коммутационные панели. Иногда их можно встретить в тех устройствах, где на небольшой площади размещено много портов (например, в терминальных серверах). Разъемы RJ-45, как правило, ис- пользуются не с витой парой, а с плоским телефонным кабелем. Оба варианта допу- стимы в последовательных соединениях, но витая пара обеспечивает лучшее качество сигнала при передаче данных на большие расстояния. Для работы с разъемными соеди- нениями RJ-45 требуется недорогой инструмент. Разъем Номера контактов Вид сверху Рис. 31.4. Вилка разъема RJ-45 Существует несколько стандартов, определяющих соответствие контактов разъема RJ-45 контактам разъема DB-25. В табл. 31.3 описан официальный стандарт RS-232D, который почти не используется. Другой стандарт — это система Дэйва Йоста (Dave Yost), в которой каждое устройство снабжено гнездом RJ-45 и используются стандартизированные кабели, позволяющие соединять как DCE-, так и DTE-устройства (yost. com/computers/RJ45-serial).
Глава 31. Последовательные устройства и терминалы 1213 Таблица 31.3. Разводка контактов для прямого кабельного перехода RJ-45/DB-25 1 6 2 8 3 20 4 7 5 3 6 2 7 5 8 4 DSR — готовность данных DCD — обнаружение несущей DTR — готовность терминала SG — сигнальная земля RD — принимаемые данные TD — передаваемые данные CTS — готовность к приему RTS — готовность к передаче 31.3. Аппаратная и программная несущие При подсоединении и включении устройства система UNIX ожидает, что сигнал об- наружения несущей (DCD) перейдет на высокий уровень (положительное напряжение). Этот сигнал подается на восьмой контакт разъемного соединения DB-25. Если в после- довательном кабеле есть линия DCD и компьютер “обращает на нее внимание”, значит, используется аппаратная несущая. В большинстве систем допускается также применение программной несущей, когда компьютер “делает вид”, что сигнал DCD всегда присутствует. Для некоторых устройств (в частности, для терминалов) программная несущая — это подарок судьбы. Она позволяет в каждом последовательном соединении обходиться все- го тремя линиями: передаваемых данных, принимаемых данных и сигнальной земли. Но в модемных соединениях сигнал DCD обязателен. Если терминал подключен через модем и сигнал обнаружения несущей пропадает, модем должен разрывать соединение (особенно при междугородных звонках). Режим программной несущей для последовательного порта обычно задается в кон- фигурационном файле (например, /etc/gettydef s или /etc/inittab, в случае реги- страционного терминала, и /etc/printcap, в случае принтера) той клиентской про- граммы, которая обслуживает этот порт. Если нужно включить этот режим “на лету”, воспользуйтесь командой stty -clocal. Например, команда suse$ sudo stty -clocal < /dev/ttySl включает программную несущую для порта ttySl. 31.4. Аппаратный контроль передачи данных Назначение сигналов CTS и RTS — обеспечить такую скорость передачи данных, что- бы приемное устройство успевало их обрабатывать. Например, если существует опасность переполнения буфера модема (возможно, из-за того, что соединение с удаленным узлом Работает медленнее, чем последовательный канал между локальным компьютером и мо- демом), модем может приказать компьютеру сделать паузу, пока буфер не освободится. Контроль передачи данных имеет большое значение для принтеров и высокоскорост- ных модемов. В системах, где аппаратный контроль передачи отсутствует (из-за того, 470 последовательные порты не поддерживают этот режим, либо из-за того, что в после- довательном кабеле выводы CTS и RTS не подключены), его иногда можно имитировать Программным путем с помощью управляющих ASCII-символов XON и XOFE Однако
1214 Часть III. Разное программный контроль должен явно поддерживаться высокоуровневым программным обеспечением, хотя даже в этом случае его реализация затруднена. Символам XON и XOFF соответствуют комбинации клавиш <Ctrl+Q> и <Ctrl+S>. Это представляет проблему для пользователей редактора emacs, где при нажатии комби- нации клавиш <Ctrl+S> по умолчанию вызывается команда поиска. Во избежание этого необходимо связать команду поиска с другой комбинацией клавиш или воспользоваться командами stty start и stty stop для изменения установок драйвера терминала. Большинство терминалов игнорирует сигналы CTS и RTS. Те немногие терминалы, которые для установления связи требуют, чтобы по этим линиям была проведена про- цедура квитирования, можно обмануть, соединив перемычкой контакты 4 и 5 на том конце кабеля, который подключен к терминалу. В результате, когда терминал посылаем сигнал на вывод 4, заявляя “я готов”, с вывода 5 он получает этот же сигнал обратно^ что означает “начинай”. Таким же способом можно решить вопрос с квитированием по линиям DTR/DSR/DCD. Как и в случае программной несущей, параметрами аппаратного контроля передачи можно управлять посредством конфигурационных файлов или команды stty. На аппаратном обеспечении компании Sun контроль передачи данных для soians встроенных последовательных портов можно настроить с помощью команде eeprom. [КЯ На некоторых платформах компании HP возникает необходимость настраи- вать встроенные последовательные порты с помощью системы Guardia» Service Processor (GSP). 31.5. Файлы последовательных устройств Последовательные порты представляются в системе файлами устройств, расположен- ными в каталоге /dev или его подкаталогах. Даже сегодня у большинства компьютеров имеется два встроенных последовательных порта: /dev/ttya и /dev/ttyb, впрочем их часто называют /dev/ttySO и /dev/ttySl соответственно. Иногда на один и тот же последовательный порт ссылается несколько устройств: Например, в системе /dev/cua/a означает тот же порт, что и /dev/term/а. Однако порт /dev/cua/a имеет другой, младший номер устройства. solaris$ Is -IL /dev/term/а /dev/cua/a crw -------i uucp uucp 37, 130172 Jan 11 16:35 /dev/cua/a crw-rw-rw- 1 root sys 37, 0 Jan 11 16:35 /dev/term/a Как обычно, имена файлов устройств не имеют значения. Отображение устройств^ определяется его старшими и младшими номерами, а имена файлов устройств введены просто для удобства пользователей. Несколько файлов устройств одновременно используется, в основном, для под- держки модемов, обрабатывающих входящие и исходящие звонки. В схеме Solaris драйвер позволяет открыть порт /dev/term/а, только когда модем получает сигнал на контакт DCD, означающий наличие активного (входящего) соединения (при усло- вии что на порт не установлена программная несущая). Порт /dev/cua/a может от- крываться независимо от состояния контакта DCD; он используется при соединении с модемом, чтобы тот принял звонок. Если используется одно устройство, то доступ другого блокируется.
Глава 31. Последовательные устройства и терминалы 1215 ИСЯ В системе HP-UX файлы последовательных устройств не всегда создаются ав- тематически. Для того чтобы заставить систему их найти, можно использовать следующую команду. hp-ux$ sudo ioscan -С tty -fn Файлы устройств можно также создать с помощью такой команды. hp-ux$ sudo mfsf -Н порт-с-вывода-устройства-ввода-вывода -d asioO -аО -i -v Похоже, что система AIX целиком отказалась от поддержки последовательных _ ' интерфейсов. В частности, если в вашей системе несколько LPAR (см. гла- ву 24), то последовательные интерфейсы не доступны по умолчанию. В этом случае вам, видимо, придется купить специальное оборудование. 31.6. Команда setserial: передача драйверу ПАРАМЕТРОВ ПОСЛЕДОВАТЕЛЬНОГО ПОРТА В СИСТЕМЕ LlNUX Последовательным портам персональных компьютеров можно назначать различные адреса ввода-вывода и номера запросов на прерывание (IRQ). Параметры портов счи- тываются из BIOS при включении питания компьютера. Менять их приходится, только если какое-нибудь “вредное” устройство соглашается работать лишь при выделении ему ресурсов, обычно закрепленных за одним из последовательных портов. К сожалению, драйвер последовательных портов не всегда способен распознать подобные изменения конфигурации без посторонней помощи. В системе UNIX эта проблема традиционно решается указанием параметров после- довательного порта на этапе компиляции ядра. К счастью, в системе Linux этого можно избежать, воспользовавшись командой setserial. При наличии флага -д она отобра- жает текущие установки порта. ubuntu$ setserial -g /dev/ttySO /dev/ttySO, UART: 16550A, Port: 0x03f8, IRQ: 4 Задавая параметры порта, нужно сначала указать файл устройства, а затем — после- довательность названий параметров и их значений. К примеру, команда ubuntu$ sudo setserial /dev/ttySl port 0x02f8 irq 3 устанавливает адрес ввода-вывода и номер прерывания для порта ttySl. Важно уяс- нить, что эта команда ни в коей мере не меняет аппаратную конфигурацию системы. Она лишь сообщает конфигурационные параметры драйверу последовательных портов в системе Linux. Физические установки изменяются через системный BIOS. Изменения, производимые командой setserial, не сохраняются при перезагрузке системы. Стандартного способа сделать их постоянными не существует; в каждом дис- трибутиве это делается по-разному. й В системе Ubuntu для инициализации последовательных портов использует- ДА ся сценарий /etc/init. d/setserial. Он считывает параметры для каждого порта из файла /var/lib/setserial/autoserial.conf. /CSfe В системе SUSE для инициализации последовательных портов используется * 11 ,г сценарий /etc/init. d/serial. К сожалению, этот сценарий не имеет файла
1216 Часть III. Разное конфигурации; для того чтобы отразить команды, которые вы хотите выпол- нить, его приходится редактировать непосредственно. Бедная система SUSE! Этот сценарий написан на своем собственном метаязыке, позволяющем соз- давать строки команд setserial, но, к счастью, в нем достаточно много хо- рошо прокомментированных примеров. В системе Red Hat сценарий /etc/rc.d/rc.sysinit проверяет наличие сценария /etc/rc. serial и, если он существует, выполняет его на этапе на- чальной загрузки. Готового примера сценария нет, поэтому его придется соз- дать самостоятельно. Просто перечислите команды setserial, которые нуж- но выполнить, по одной на строку. Для надежности можно добавить в начало файла строку #! /bin/sh и сделать сам файл исполняемым, хотя это необяза- тельно. 31.7. Псевдотерминалы Терминалы с электронно-лучевыми трубками сегодня представляют собой не более чем музейные экспонаты, но их дух сохранился в виде псевдотерминалов. Эти пары файлов устройств эмулируют текстовый интерфейс терминалов со стороны служб, на- пример, виртуальных консолей, виртуальных терминалов (например, xterm) и служб сетевой регистрации (например, telnet и sh). Рассмотрим принцип их работы. Каждая пара файлов устройств имеет доступ к одно- му и тому же драйверу устройства внутри ядра. Подчиненное устройство имеет имя вро- де /dev/ttypl. Процесс, который мог бы нормально взаимодействовать с терминалом, например оболочка, использует подчиненное устройство вместо физического, например /dev/ttySO. Главный процесс, например sshd или telnetd, открывает соответствую- щее главное устройство, в нашем примере — /dev/ttypl. Драйвер псевдотерминала переносит коды нажатых клавиш и введенный текст между этими двумя устройствами, скрывая, что физического терминала не существует. Несмотря на то что псевдотерминалы не имеют скорости двоичной передачи или стратегии управления передачей данных, к ним можно применить большинство других атрибутов и настроек, описанных в главе. Язык сценария expect использует псевдотер- минал для управления процессами (например, ftp или parted), которые могут взаимо- действовать с пользователем. Он довольно полезен для автоматизации некоторых адми- нистративных задач. 31.8. Конфигурирование терминалов За последнее десятилетие дешевые компьютеры практически вытеснили с рынка тек- стовые терминалы. Но даже “терминальные” окна, работающие в графическом режиме, используют те же драйверы и файлы конфигурации, что и реальные терминалы, поэтому системные администраторы должны знать, как они работают. При настройке терминала нужно решить две важные задачи: закрепить за термина- лом процесс, который будет принимать поступающие от него запросы на регистрацию, и обеспечить доступность информации о терминале после входа пользователя в систе- му. Однако прежде чем приступать к решению этих задач, давайте рассмотрим, как осу- ществляется регистрация в системе.
Глава 51. Последовательные устройства и терминалы 1217 Процедура регистрации в системе В ходе регистрации задействуется несколько программ, самая важная из них — демон init. Одна из его задач заключается в порождении процесса, обобщенно называемо- го getty, на каждом терминальном порту, который определен в файле /etc/inittab. Демон getty устанавливает начальные характеристики порта (в частности, скорость передачи и режим контроля четности) и выводит на экран приглашение к регистрации. Q О демоне init рассказывалось в разделе 3.5. Д Реальное имя демона getty зависит от дистрибутива системы Linux, а в неко- торых дистрибутивах существует даже несколько реализаций демона. В систе- мах Red Hat и SuSE используется упрощенная версия, называемая mingetty, которая обрабатывает запросы, поступающие от виртуальных консолей. Для работы с терминалами и модемами предназначен демон mgetty, разработан- ный Гертом Дорингом (Gert Doering). В системе Ubuntu используется утилита getty, созданная Вице Венема (Wietse Venema). Она есть и в системе SuSE под названием age tty. Более старая реализация, называемая uugetty, в основном, вытеснена демоном mgetty. И наконец, популярный открытый сервер факсов HylaFAX (hylafах. org) имеет свою собственную версию де- мона getty, которая называется faxgetty. Для того чтобы сориентироваться в этом многообразии, рассмотрим утилиты с точки зрения сложности. Проще всех демон mingetty. Он способен лишь обрабатывать за- просы, поступающие от виртуальных консолей системы Linux. На следующем уровне иерархии находится демон agetty, который умеет обрабатывать запросы, поступающие от последовательных портов и модемов. Наконец, на вершине иерархии находится де- мон mgetty. Он может обрабатывать не только запросы на регистрацию, но и команды факсов, а также координировать работу модемов, чтобы один и тот же модем мог управ- лять как входными, так и выходными потоками. Последовательность событий при регистрации в системе такова. • Демон getty отображает содержимое файла /etc/issue, а также приглашение к регистрации. • Пользователь вводит регистрационное имя в строке приглашения. • Демон getty запускает программу login, передавая ей в качестве аргумента вве- денное имя. • Программа login запрашивает пароль и сверяет его с записями в файле /etc/ shadow или административной базе данных, например NIS или LDAP. • Программа login выводит на экран “сообщение дня”, хранящееся в файле /etc/ motd, и запускает интерпретатор команд. • Интерпретатор выполняет соответствующие сценарии конфигурации2. • Интерпретатор отображает на экране приглашение командной строки и переходит в режим ожидания команд. Когда пользователь выходит из системы, управление возвращается демону init, ко- торый “пробуждается” и порождает новый процесс getty для порта терминала. 2 Файл .profile — в случае sh/ksh; файлы .bash__profile и .bashrc — в случае bash; фай- лы . cshrc и . login — в случае csh/tcsh.
1218 Часть III. Разное Большинство параметров каждого терминального порта сосредоточено в файлах ка- талога /etc. К ним относятся приглашение к регистрации и процесс getty, связанный с портом, скорость передачи двоичных данных и тип терминала, соединенного с портом. К сожалению, среди разработчиков нет согласия по поводу конфигурации терминалов. В табл. 31.4 перечислены конфигурационные файлы, используемые в разных системах. Таблица 31.4. Конфигурационные файлы терминалов Система Вкл/выкл Тип терминала Параметры Монитор ч Ubuntua /etc/event.d/tty6 /etc/ttytype /etc/getttydefs getty SUSE /etc/inittab /etc/ttytype /etc/getttydefs getty Red Hat /etc/inittab /etc/ttytype /etc/getttydefs getty SolarisB _sactab .sactab zsmon/_pmtab ttymon HP-UX /etc/inittab /etc/ttytype /etc/getttydefs getty AIXr /etc/inittab /etc/security/login.cfg База данных ODM getty а Для управления демоном TTY/getty в системе Ubuntu используется не демон init, а демон ipstart. 6 Виртуальные консоли определены в файле /etc/default/console-setup. в Конфигурационные файлы системы Solaris хранятся в каталоге /etc/saf и управляются демоном sacadm. г Для обеспечения согласованности следует для модификации параметров T7Y использовать систему SMIT. Файл /etc/ttytype Во многих системах информация о типе терминала хранится в файле /etc/ttytype. Формат записи в файле ttytype имеет следующий вид. тип_терминала устройство Здесь устройство — это короткое имя файла устройства, соответствующего порту, a term type — запись в базе данных termcap или terminfo. Когда вы регистрируетесь, переменной окружения TERM присваивается значение этого поля. Рассмотрим пример файла ttytype. wyse console dialup ttyiO dialup ttyil vt320 ttyi2 Ы9 ttyi3 dialout ttyi4 Файл /etc/gettytab Файл gettytab ассоциирует символические имена, например std. 9600, с профиля- ми конфигурации портов, содержащих такие параметры, как скорость, четность и пред- ложение зарегистрироваться. Рассмотрим пример. # Запись, используемая, чтобы задать значения по умолчанию # для остальных записей, а также в ситуациях, когда демон getty # вызывается без конкретного имени записи. default: :ар:lm=rn%h login72 :sp#9600: # Параметры фиксированной скорости
Глава 31. Последовательные устройства и терминалы 1219 2|std.9600|9600-baud: :sp#9600: h|std.38400|38400-baud: :sp#38400: Этот формат совпадает с форматом файлов printcap или termcap. Строки с имена- ми, разделенными вертикальными чертами (|), перечисляют имена каждой конфигура- ции. Другие поля в записях задают параметры, используемые последовательным портом. Файл /etc/gettydefs Как и файл gettytab, файл gettydefs определяет конфигурации портов, исполь- зуемые демоном getty. Каждая система может использовать только один из этих двух файлов. Файл gettydef s выглядит следующим образом. console# В9600 HUPCL # В9600 SANE IXANY #login: #console 19200# B19200 HUPCL # B19200 SANE IXANY #login: #9600 9600# В9600 HUPCL # B9600 SANE IXANY HUPCL #login: #4800 4800# В4800 HUPCL # B4800 SANE IXANY HUPCL #login: #2400 2400# В2400 HUPCL # B2400 SANE IXANY HUPCL #login: #1200 1200# В1200 HUPCL # B1200 SANE IXANY HUPCL #login: #300 300# B300 HUPCL # B300 SANE IXANY TAB3 HUPCL #login: #9600 Формат записи имеет следующий вид. метка# инит_ флаги # финал_флаги # приглашение #следующий Демон getty пытается сравнить свой второй аргумент с меткой. Если он вызывается без второго аргумента, то используется первая запись в файле. Поле инит_ флаги со- держит флаги ioctl(2), которые должны быть установлены на порту, пока выполняется регистрация. Поле финал_флаги устанавливает флаги, которые должны использоваться в дальнейшем. В файле должна существовать запись, задающая скорость соединения в наборах фла- гов инит_флаги и финал_флаги. Набор флагов зависит от системы; полную информа- цию о них можно найти на справочных страницах gettydef s или mgettydef s. Поле приглашение определяет строку приглашения зарегистрироваться, которая может содержать символы табуляции и перехода на новую строку с помощью обратной косой черты. Поле следующий задает метку записи inittab, которая должна заменяться текущей меткой, если поступила команда на прерывание. Это было полезно десятки лет тому назад, когда модемы не согласовывали скорость автоматически и вы должны были согласовывать ее вручную с помощью серии прерываний. Сегодня это уже анахронизм. Для аппаратного терминала поле следующий должно ссылаться на метку текущей записи. Каждый раз, изменяя файл gettydefs, вы должны выполнять команду getty -с gettydefs, которая проверяет синтаксис этого файла, чтобы убедиться, что все записи являются правильными. Файл /etc/inittab Демон init поддерживает различные “уровни выполнения”, которые определяют, какие системные ресурсы задействуются. Существует семь уровней выполнения, про- нумерованных от 0 до 6, плюс уровень “s”, являющийся синонимом уровня 1 (одно- пользовательский режим). При выходе из однопользовательского режима демон init приглашает пользователя ввести номер уровня выполнения, если только в файле /etc
1220 Часть III. Разное /inittab не задан параметр initdef ault, как описано ниже. Затем демон просматри- вает файл inittab в поиске всех строк, соответствующих указанному уровню. Ш Демон init описан в разделе 3.5. Уровни выполнения обычно устанавливаются таким образом, чтобы у пользователя был один уровень, на котором доступна только консоль, и другой уровень, на кото- ром доступны все терминалы. Можно задавать уровни выполнения так, как того тре- бует конкретная система, но мы рекомендуем не слишком отклоняться от значений по умолчанию. Записи файла inittab имеют следующий формат. идентификатор: уровни_выполнения: действие: процесс Приведем примеры записей в файле inittab. # Обработка команды <Ctrl+Alt+Del> са::ctrlaltdel:/sbin/shutdown -t3 -r now # Запуск демонов getty на стандартных уровнях 1:2345:respawn:/sbin/mingetty ttyl 2:2345:respawn:/sbin/mingetty tty2 Здесь поле идентификатор — это одно- или двухсимвольная строка, идентифицирую- щая запись. Поле идентификатора может быть пустым. Для терминалов в качестве иден- тификатора обычно указывают номер терминала. В поле уровни_выполнения перечислены номера уровней выполнения, к которым от- носится запись. Если уровни не заданы (как в первой строке), то запись действительна для всех уровней. В поле действие указывается, как трактовать поле процесс', наиболее распространенные значения приведены в табл. 31.5. Таблица 31.5. Возможные значения поля действие файла /etc/inittab wtle'lw.fl'l© Ждать? жифацтмй» '' initdefault — Задает исходный уровень выполнения boot Нет Процесс запускается при первом чтении файла inittab bootwait Да Процесс запускается при первом чтении файла inittab ctrlaltdel Нет Процесс запускается в ответ на нажатие комбинации клавиш <Ctrl+Alt+Del> once Нет Процесс запускается однократно wait Да Процесс запускается однократно respawn Нет Процесс постоянно поддерживается в рабочем состоянии powerfail Нет Процесс запускается при получении демоном init сигнала сбоя питания powerwait Да Процесс запускается при получении демоном init сигнала сбоя питания sysinit Да Процесс запускается перед обращением к консоли off - Прерывает выполняемый процесс в некоторых системах Если одно из значений в поле уровни_выполнения совпадает с номером текущего уровня, а значение поля действие свидетельствует об актуальности записи, то демон init с помощью интерпретатора sh выполняет команду, заданную в поле процесс (или прекращает ее выполнение). В столбце “Ждать?” табл. 31.5 указано, в каких случаях демон init ожидает завершения команды, прежде чем продолжить работу. В приведенном выше примере в последних двух строках порождаются демоны mingetty для первых двух виртуальных консолей (консоли переключаются нажатием
Глава 31. Последовательные устройства и терминалы 1221 комбинаций клавиш <ALT+F1> и <Alt+F2>). При добавлении в систему аппаратных терминалов или модемов соответствующие записи файла inittab будут примерно та- кими же, только в качестве команды должна быть указана строка вызова демоня mgetty или getty (agetty в SuSE), поскольку демон mingetty не работает с этими устрой- ствами. Как правило, в качестве значения поля действие выбирается respawn, а в поле уровни_выполнения указывают 2345. Команда telinit -q заставляет демон init повторно прочитать файл inittab. а Различные версии демона getty конфигурируются по-разному. Версия getty/agetty, имеющаяся в SuSE и Ubuntu, немного проще в этом плане, чем mgetty, потому что берет свою конфигурационную информацию из ко- мандной строки (содержащейся в файле /etc/inittab). Общий формат строки имеет следующий вид. /sbin/getty порт скорость тип_терминала Здесь порт — это файл устройства для данного порта (имя файла указано относительно каталога /dev); скорость — это скорость передачи в бодах (например, 38400), а поле тип_ терминала определяет стандартный тип терминала, подключаемого к данному пор- ту. Последнее поле является ссылкой на запись базы данных terminfo. Большинство эмуляторов имитирует работу терминала VT100 компании DEC, обозначаемого как vtlOO. Существует и много других параметров, в основном связанных с управлением модемами. Демон mgetty обладает более сложными средствами работы с модемами, чем agetty, и к тому же понимает входные и выходные команды факсов. Его конфигурация рассредоточена среди большего количества файлов. Помимо обычных флагов команд- ной строки, демон mgetty может принимать ссылку на файл /etc/gettydefs, в кото- ром указаны детали конфигурации драйвера последовательных портов. Необходимость в этом возникает только при сложной настройке модемов. Информацию о файле gettydefs можно получить с помощью команды man mgettydef s. Соответствующая страница названа так во избежание конфликта со старой man-страницей gettydefs, которая больше не существует ни в одной системе Linux. Строка вызова демона mgetty для аппаратного терминала выглядит примерно так. /sbin/mgetty -rs скорость устройство Параметр скорость — это скорость передачи в бодах (например, 38400), а устройство — это файл устройства для последовательного порта (указывайте полный путь к нему). Если требуется задать тип терминала по умолчанию, это придется сделать в отдель- ном файле, /etc/ttytype, а не в командной строке демона mgetty. Формат записей этого файла описан выше. Демон Upstart в системе Ubuntu ®В системе Ubuntu демон init заменен его модифицированным вариан- том Upstart, который запускает и останавливает службы в ответ на события. Однако выполняемый файл демона Upstart имеет прежнее имя /sbin/init. Демон Upstart использует один файл для каждого активного терминала, указанного в файле /etc/event .d. Например, если мы хотим применить демон getty к термина- лу ttySO, то файл /etc/event.d/ttySO может иметь следующий вид.
1222 Часть III. Разное # ttySO - getty # Эта служба поддерживает работу демона getty на терминале ttysO # с момента запуска системы до ее остановки start on runlevel 2 start on runlevel 3 start on runlevel 4 start on runlevel 5 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/getty 38400 ttySO Дополнительные комментарии по поводу программы Upstart можно найти в разде- ле 3.5. система Solaris и демон sacadm soiaris Вместо традиционных демонов getty из системы UNIX, которые следили за работой каждого порта и выдавали приглашение зарегистрироваться, в системе Solaris существует запутанная иерархия Service Access Facility, управляющая мониторами TTY, мониторами портов и многими другими сложными, но почти бесполезными функциями. Для того чтобы последовательный порт выдавал приглашение зарегистрировать- ся, сначала необходимо сконфигурировать “монитор”, следящий за состоянием порта (ttymon). Затем следует сконфигурировать монитор порта, который следит за монито- ром TTY. Например, чтобы настроить монитор, работающий со скоростью 9 600 бод, на терминал ttyb и заставить его выдавать приглашения зарегистрироваться с помощью терминала типа VT100, необходимо выполнить следующие команды. solaris$ sudo sacadm -а -р myttymon -t ttymon -c /usr/lib/saf/ttymon -v 1 solaris$ sudo pmadm -a -p myttymon -s b -i root -fu -v 1 -m ” 'ttyadm -d /dev/term/b -1 9600 -T vtlOO -s /usr/bin/login'" Файл /etc/ttydefs используется почти так же, как и файл gettydefs в других си- стемах, чтобы задать параметры скорости и четности. Информацию о демонах saf, sacadm, pmadm, ttyadm и ttymon можно найти на со- ответствующих справочных страницах и в главе о терминалах в книге Solaris AnswerBook. Развлекайтесь! 31.9. Специальные символы и драйвер терминала Драйвер терминала поддерживает несколько специальных функций, доступ к кото- рым осуществляется нажатием особых комбинаций клавиш (как правило, в эти комби- нации входит клавиша <Ctrl>). Привязку функций к клавишам можно задать с помощью команд tset и stty. Некоторые из этих функций и соответствующие им комбинации клавиш приведены в табл. 31.6. В зависимости от желания разработчика, значением по умолчанию для функции erase может быть либо комбинация клавиш <Ctrl+H>, либо символ удаления. (Реаль- ная клавиша на клавиатуре может быть помечена как “backspace” или “delete” или стрелка, направленная влево.) К сожалению, существование двух различных стандартов порождает многочисленные проблемы.
Глава 31. Последовательные устройства и терминалы 1223 Таблица 31.6. Специальные символы и функции драйвера терминала Название — —~ > Стандартная комбинация клавиш функция , v - . erase <Ctrl+?> Стирает один введенный символ werase <Ctrl+W> Стирает одно введенное слово kill <Ctrl+U> Стирает всю строку eof <Ctrl+D> Посылает терминалу признак конца файла intr <Ctrl+C> Прерывает выполнение текущего процесса quit <Ctrl+> Уничтожает текущий процесс, создавая дамп памяти stop <Ctrl+S> Останавливает вывод на экран start <Ctrl+Q> Возобновляет вывод на экран susp <Ctrl+Z> Приостанавливает текущий процесс Inext <Ctrl+V> Игнорирует специальное значение следующего символа Можно воспользоваться командой stty erase, чтобы сообщить драйверу терминала о том, какой символ на самом деле используется. Однако некоторые программы (напри- мер, текстовые редакторы и командные интерпретаторы с режимом редактирования ко- мандной строки) имеют “собственное представление” о том, каким должен быть символ возврата, поэтому они не всегда обращают внимание на установку драйвера терминала. Часть программ поддерживает оба варианта. Может даже оказаться, что в локальной си- стеме принята одна установка, а в удаленной системе, в которой вы зарегистрировались по сети, — другая. В целом, не существует простого, универсального, решения подобных конфликтов. С каждой конкретной программой приходится разбираться отдельно. Есть два полезных ресурса на эту тему: документ Linux Backspace/Delete mini-HOWTO на узле tldp.org и статья Анне Баретта (Anne Baretta) по адресу: ibb.net/-anne/keyboard.html. 31.10. Команда stty: задание параметров терминала Команда stty позволяет непосредственно изменять и запрашивать значения различ- ных параметров драйвера терминала. Существует множество опций, большинство кото- рых можно проигнорировать. Обычно названия опций команды stty совпадают с теми, которые указаны на man-странице termios, хотя бывают и расхождения. Вот хорошее сочетание опций для простого терминала. solans $ stty intr АС kill AU erase AH -tabs Здесь параметр -tabs запрещает драйверу терминала задействовать встроенный ме- ханизм табуляции, поскольку многие эмуляторы не поддерживают его в полной мере. Остальные параметры назначают специальным символам прерывания (intr), удале- ния строки (kill) и удаления символа (erase), соответственно, комбинации клавиш <Ctri+C>, <Ctrl+U> и <Ctrl+H> (возврат с удалением). Команду stty можно использовать для анализа текущих режимов драйвера термина- ла и их включения. Команда stty без аргументов выдает такую информацию. solaris$ stty speed 38400 baud; erase = AH;eol = М-л?; eol2 = М-л? swtch = <undef>; ixany tab3
1224 Часть III. Разное Более детальный отчет можно получить с помощью команды stty -а. solaris$ stty -а speed 38400 baud; rows 24; columns 80; intr = AC; quit = A; erase = AH; kill = AU; eof = AD; eol = M-A?; eol2 = M-A?; swtch = <undef>; start = AQ; stop = AS; susp = AZ; dsusp = AY; rprnt = AR; werase = AW; Inext = AV; flush = AO; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon - ixoff -iuclc ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nlO crO tab3 bsO vtO ffO isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echop rt echoctl echoke Формат вывода остался прежним, но отображена вся имеющаяся информация. О на- значении параметров в большинстве случаев можно догадаться интуитивно. Команда stty работает с файловым дескриптором своего стандартного входного по- тока, поэтому с помощью оператора переадресации, предусмотренного в интерпретаторе команд (<), можно устанавливать и запрашивать режимы не только текущего, но и дру- гих терминалов. Изменять режимы чужих терминалов имеет право только пользователь root. 31.11. Команда tset: автоматическое ЗАДАНИЕ ПАРАМЕТРОВ ТЕРМИНАЛА Команда tset переводит драйвер терминала в режим, соответствующий типу терми- нала. Тип терминала можно задать в командной строке. Если он не указан, используется значение переменной окружения TERM. Синтаксис команды tset предусматривает возможность изменения значений пере- менной окружения TERM. Это удобно, если вы часто регистрируетесь в системе через модем или коммутатор данных и хотите, чтобы драйвер был сконфигурирован в расчете на реальный терминал, который используется на другом конце соединения, а не на не- что общее и бесполезное вроде “коммутируемого терминала” (тип “dialup”). Предположим, к примеру, что на домашнем компьютере используется программа xterm, а система, в которой вы регистрируетесь по модему, воспринимает тип термина- ла модема как “dialup”. Тогда, если добавить команду tset -m dialup:xterm в файл . login или .profile, драйвер терминала всегда будет настроен на работу с про- граммой xterm. К сожалению, команда tset не так проста, как кажется. Для того чтобы заставить ее не только задавать режим работы терминала, но и менять значения переменных среды, нужно воспользоваться следующим мини-сценарием. set noglob eval 'tset -s -Q -m dialup:xterm' unset noglob Здесь подавляется обычный вывод команды tset (флаг -Q), а вместо этого запра- шивается вывод команд интерпретатора, устанавливающих значения переменных среды (флаг -s). Поскольку присутствуют обратные кавычки, командные строки, отобража- емые командой tset, перехватываются и подаются на вход интерпретатора благодаря
Глава 31. Последовательные устройства и терминалы 1225 встроенной команде eval. В результате команды будут выполнены так, как если бы их ввел сам пользователь. Команда set noglob запрещает интерпретатору раскрывать метасимволы, такие как и ‘?’, в выводе команды tset, а команда unset noglob восстанавливает нормаль- ный режим работы интерпретатора. Это не нужно в интерпретаторах sh/ksh, посколь- ку обычно они не раскрывают специальные символы, которые заключены в обратные кавычки. Вид самой команды tset не зависит от интерпретатора: проверяя значение переменной среды SHELL, она определяет, какие команды следует генерировать. 31.12. Как справиться с "зависшим” терминалом Некоторые программы (например, редактор vi) в процессе работы вносят серьезные изменения в параметры драйвера терминала. Пользователь, как правило, этого не за- мечает, поскольку при завершении или приостановке программы состояние терминала полностью восстанавливается. Однако существует опасность, что программа завершит работу аварийно или ее выполнение будет прекращено до завершения процедуры вос- становления. Если это случится, терминал может начать вести себя очень странно: пере- стать правильно обрабатывать символы новой строки, отображать вводимые символы и адекватно выполнять команды. Еще один способ нарушить работу терминала — применить к бинарному файлу команду cat или more. В большинстве таких файлов содержится причудливая смесь управляющих символов, которая, наверняка, окажется “смертельной” для недостаточно устойчивых эмуляторов. Для того чтобы решить эту проблему, можно воспользоваться командой reset или stty sane. Первая из них является всего лишь ссылкой на команду tset и может при- нимать большинство ее аргументов, хотя, как правило, вызывается без аргументов. Обе команды — и reset, и stty sane — восстанавливают работоспособность драйвера тер- минала и посылают терминалу соответствующий код сброса, который берется из базы данных termcap/terminfo, если таковая имеется. Во многих случаях сброс необходим потому, что терминал был оставлен в особом со- стоянии, когда вводимые пользователем символы не обрабатываются. В этом состоянии большинство терминалов при нажатии клавиши <Retum> или <Enter> генерирует толь- ко символ возврата каретки (<Ctrl+M>), а символ новой строки, при получении которо- го текущая команда посылается на выполнение, не генерируется. Чтобы ввести символ новой строки непосредственно, вместо клавиши <Retum> нажмите комбинацию кла- виш <Ctrl+J> или клавишу перевода строки (если таковая имеется). 31.13. Отладка последовательной линии Наладить работу последовательной линии несложно. Приведем перечень типичных ошибок. • Вы забыли дать демону init указание повторно прочитать свои конфигурацион- ные файлы. • Вы забыли установить режим программного управления потоком при использова- нии трехпроводных кабелей. • Вы используете несоответствующий нуль-модемный кабель. • При пайке или обжиме проводов вы перевернули вверх ногами разъем DB-25.
1226 Часть III. Разное • Вы подключили устройство не к тому проводу из-за того, что монтажные схемы оказались неправильными или неточными. • Вы неверно задали параметры терминала. Коммутационный тестер — незаменимое средство устранения проблем в кабельных системах. Он подключается к последовательной линии и показывает наличие сигналов в каждом проводе кабеля. У качественных коммутационных тестеров на каждой стороне есть и вилки, и розетки, поэтому они могут подключаться самыми разными способами. С каждым из представляющих интерес контактов связаны индикаторы, которые подсве- чиваются, когда контакт активен. Одни коммутационные тестеры позволяют только наблюдать за сигналами, другие дают возможность осуществлять повторную разводку соединений и подтверждают на- личие напряжения на контакте. Например, если есть подозрение, что кабель нужно сде- лать нуль-модемным, то можно с помощью коммутационного тестера изменить имею- щуюся разводку. 31.14. Соединение с консолями ПОСЛЕДОВАТЕЛЬНЫХ УСТРОЙСТВ Вероятно, самым распространенным и полезным приложением порта RS-232 в на- стоящее время является соединение с последовательной “консолью” другого устройства. Этим устройством может быть все, что угодно, — от управляемого устройства UPS или коммутатора сети до встроенной системы Linux вроде системы TiVo в вашем телевизоре. Например, вы можете установить последовательное соединение с устройством UPS, ко- торое служит источником электроэнергии для вашего оборудования в удаленном центре обработки данных, чтобы дистанционно отключать его в случае опасности. Перечислим основные этапы соединения с последовательной консолью. • Соедините кабелем последовательный порт в вашей системе UNIX и устройство, с которым хотите работать. Типы соединений и разъемов, которые могут вам по- надобиться, описаны выше. Вероятно, вам также понадобится нуль-модемный ка- бель. Его можно купить в любом магазине, торгующем компьютерной техникой. • Инсталлируйте или укажите программное обеспечение для работы с терминалом, которое вы будете использовать в системе UNIX или Linux. Десятки лет тому на- зад для этого использовались команды си или tip. Вы можете использовать их и сегодня, но лучше применить современные варианты — minicom и picocom. Дистрибутивы системы Linux обычно содержат эти утилиты; в других системах вам, вероятно, придется самостоятельно инсталлировать это программное обеспе- чение (см. freshmeat.net/projects/minicom и freshmeat.net/projects/ picocom соответственно). • Конфигурируйте ваше программное обеспечение для работы с терминалом так, чтобы оно открывало правильный файл устройства (см. выше). Обычно этими файлами являются /dev/ttya, /dev/tty 1, /dev/ttySO или /dev/SO. • Установите скорость передачи двоичных данных, биты остановки и поток управле- ния в соответствии со стандартными установками целевого устройства. Эти пара- метры обычно описаны в документации по устройству, но вы можете попробовать применить все возможные комбинации. Если вы не знаете правильной скорости передачи двоичных данных, примените старый трюк: установите соединение и на-
Глава 31. Последовательные устройства и терминалы 1227 берите несколько символов. Если вам приходится набирать несколько символов, чтобы получить один символ мусора, значит, скорость передачи данных слишком высокая. Если набор одного или двух символов создает много символов мусора, значит, скорость передачи данных слишком низкая. Тсс... не говорите никому! • Если вы успешно установили соединение, то должны иметь возможность вводить команды на удаленной консоли. Если устройство вдруг надолго зависает, значит, вы неправильно настроили поток управления; иногда в этих ситуациях помогает нажатие клавиш <Ctrl+Q>. Если возникли проблемы с соединением, в первую очередь удалите перекрещива- ние в кабеле или добавьте еще один кабель, если одного недостаточно. Не забывайте, если вы соединяетесь с удаленным блоком UNIX, необходимо настроить демон getty на удаленном конце, чтобы он прослушивал ваше соединение и выдавал приглашение зарегистрироваться. 31.15. Упражнения 31.1. Что такое нуль-модемный кабель? Как он используется при подключении DCE- и DTE-устройств? 31.2. Можно ли использовать трехпроводной последовательный кабель для подключе- ния модема? А для последовательного принтера? Почему? 31.3. Как осуществляется аппаратный контроль передачи данных? Что можно сделать, если система не поддерживает аппаратный контроль? 31.4. Что такое псевдотерминал? Какие программы работают с псевдотерминалами? 31.5. Создайте в файле /etc/inittab записи, которые осуществляют следующее: а) запускают программу server-fallback и дожидаются ее завершения, а затем немедленно останавливают работу системы, если поступает сигнал сбоя пита- ния; б) перезапускают серверную программу unstable-srv в случае сбоя; в) запускают сценарий clean- temp, который удаляет все временные файлы при каждом перезапуске системы. 31.6. Ваш друг забыл выйти из Linux-системы, оставив ее включенной на ночь в ла- боратории. На следующий день он столкнулся со странными проблемами при за- пуске программ в интерпретаторе команд. Программы внезапно завершались или зависали, а введенные символы исчезали при вводе определенных команд или символов. В то же время некоторые программы работали вполне корректно. Чем могут быть вызваны подобные аномалии? Как это проверить? Как устранить про- блему? Кто мог так “пошутить”?
Глава Управление, стратегия и политика Можно иметь самую профессиональную команду администраторов в мире, но без со- ответствующего технического руководства не обойтись. Эта глава посвящена рассмотре- нию нетехнических аспектов создания успешного отдела информационных технологий, а также нескольких технических вопросов, затрагивающих связанную с управлением часть системного администрирования. Большинство представленных в этой главе тем и идей не относится ни к какой опре- деленной области. Они касаются как одного системного администратора, работающе- го на полставки, так большой группы профессионалов, работающих на полную ставку над каким-нибудь большим проектом. Они подобно зелени подходят каждому, какое бы “блюдо” ни готовилось. Хорошие администраторы должны одинаково хорошо разбираться как в аппаратном, так и программном обеспечении. Способность организовать группу администраторов и принять меры, чтобы они полностью удовлетворяли потребности организации, отличает просто хорошего администратора от выдающегося. Кроме советов, касающихся управления, глава содержит разделы по таким темам, как политика в области информационных технологий, эффективные методы работы и соответствие стандартам. 32.1. Цель информационных технологий Отдел информационных технологий — это нечто большее, чем просто группа техни- ческих специалистов, умеющих ремонтировать принтеры и компьютеры. Со стратегиче- ской точки зрения, это коллектив людей, которые обслуживают организацию, поддер-
Глава 32. Управление, стратегия и политика 1229 живая работу пользователей и системы. Никогда не следует забывать золотое правило администратора: производство должно управлять информационными технологиями, а не наоборот. Для того чтобы достичь максимальной результативности, отдел информационных технологий должен взаимодействовать с другими подразделениями организации. В част- ности, необходимо согласовывать свои действия в области расходов, политики, управле- ния и качества оказываемых услуг (service level agreements — SLA). Во многих организациях — особенно в небольших компаниях и маленьких подраз- делениях внутри больших компаний — системный администратор совмещает несколько обязанностей, возможно, включая роль начальника отдела или менеджера. Понимание ключевых областей, в которых отдел информационных технологий взаимодействует с остальной частью организации, поможет сделать это взаимодействие намного эф- фективнее. Перечислим минимальные обязанности отдела информационных технологий. • Вести список нерешенных задач. • Расставлять приоритеты задач и распределять ресурсы для их решения. • Сообщать о состоянии задачи пользователям и сотрудникам предприятия. • Взаимодействовать с сотрудниками предприятия, чтобы правильно удовлетворять их потребности. • Осуществлять мониторинг компьютерного окружения, включая систему безопас- ности. • Следить за появляющимися технологиями. • Развивать навыки своих сотрудников. • Способствовать соблюдению требований регулирующих органов. • Разрабатывать инструкции по выполнению повторяющихся процессов и строго им следовать. • Измерять прогресс в достижении поставленной цели. • Быть готовым к катастрофам и иметь соответствующий план действий. • Быть достаточно гибким, чтобы удовлетворять потребности пользователей, и до- статочно дисциплинированным, чтобы удовлетворять потребности руководства. Составление сметы и расходование средств Расходование средств отделом информационных технологий должно соответствовать Целям всей организации. Бюджет отдела информационных технологий оказывает огром- ное влияние на диапазон и качество услуг, которые он может оказывать другим подраз- делениям организации, поэтому крайне важно, чтобы сотрудники этого отдела помогали всем понять эту связь и достигали необходимых компромиссов. Доля расходов на информационные технологии в общем бюджете организации от- носительно невелика, хотя и представляет собой нетривиальный компонент сметы. Среднестатистическая организация тратит на них от 2 до 9% своего бюджета. Эта ве- личина зависит от конкретной отрасти промышленности, но в среднем составляет при- мерно 4-5%. Этот общий бюджет впоследствии подразделяется на капитальные затраты и экс- плуатационные расходы. Капитальные затраты обычно связаны с приобретением обо- рудования. Эксплуатационные расходы включают стоимость труда и услуг, например
1230 Часть III. Разное поддержание работы глобальной сети. Существует много способов конвертировать за- траты одного типа в затраты другого. Например, аренда оборудования преобразует капи- тальные затраты в эксплуатационные расходы, а предварительно оплаченные контракты на техническое обслуживание позволяют капитализировать расходы по обслуживанию. Вероятно, вас не интересуют различия между этими видами расходов, а вот ваших бух- галтеров они очень даже интересуют, так что вам придется в этом разбираться. Системные администраторы должны понимать, как составляется бюджет, потому что от этого зависит их способность планировать свою работу на год. Например, если адми- нистратор хочет реализовать и систему централизованной регистрации, и систему мо- ниторинга безопасности, то его желания будут ограничены бюджетом. Если бюджетных средств хватает только на один сервер, то администратор должен либо изменить прио- ритеты проектов, либо принять решение, позволяющее запустить обе системы на одном сервере. (Отличным вариантом в этом случае станет виртуализация, но в других ситуа- циях совместное использование сервера осуществить не так легко и стоит дороже.) Если администратор может влиять на составление бюджета, он может способствовать выде- лению больших средств, если сможет обосновать, как информационная инфраструктура сможет повысить доходы компании. Стратегия в области информационных технологий Стратегии в области информационных технологий влияют на работу всей органи- зации, поэтому они являются важными компонентами общей стратегии компании. Основной вклад в разработку и реализацию стратегий в области информационных тех- нологий вносят системные администраторы. Администраторы иногда несут прямую от- ветственность за стратегию развития; в других случаях их могут попросить дать отзыв на стратегии, разработанные другими членами организации. В любом случае системные администраторы вносят ценный вклад в разработку об- щей стратегии организации. Многие организации имеют один набор стратегий для ко- нечных пользователей и другой — для администраторов. Администраторы должны быть знакомы с обоими наборами стратегий и обязаны разрабатывать организационные ме- роприятия, направленные на их поддержку. Ведение документации, тесно связанное с разработкой стратегии, иногда игнориру- ется или считается маловажным по сравнению с “реальной работой”. Большинство си- стемных администраторов не любят писать документы, хотя это важно для нормального функционирования информационной системы. Настройте систему wiki или используйте другие инструменты, с помощью которых администраторы могут делать короткие замет- ки, и помогите другим размещать релевантную информацию для последующего разбора или использования. Для этой цели хорошо подходят пакеты MediaWiki и Confluence. Программа MediaWiki, основанная на Википедии, — это свободно распространяемый пакет, написанный на языке PHP (mediawiki. org). Программа Confluence — это промышленное коммерче- ское приложение, разработанное для средних и крупных предприятий. Вы можете ин- сталлировать его на своем сервере или взять в аренду (hosted solution), если не хотите управлять им локально (atlassian.com). “Список вики-приложений” на странице Википедии содержит много пунктов, а сделать правильный выбор на основе сравни- тельного анализа вам поможет сайт wikimatrix. org. Конкретные стратегии и способы их согласованной реализации обсуждаются в раз- деле 32.7.
Глава 32. Управление, стратегия и политика 1231 Соглашения о качестве оказываемых услуг Системное администрирование — это услуга, а получателями этой услуги являют- ся люди и компьютеры. Для того чтобы отдел информационных технологий успешно справлялся со своими обязанностями, стараясь угождать пользователям и удовлетворяя потребности предприятия, все детали необходимо согласовать и зафиксировать в согла- шении о качестве оказываемых услуг. Хорошее соглашение предусматривает соответ- ствующий уровень обслуживания и является документом, на который можно ссылаться в проблемных ситуациях. (Однако помните, что отдел информационных услуг помогает, а не мешает пользователям!) Пользователи довольны, если выполняются следующие условия. • Их компьютеры в порядке, и они могут на них зарегистрироваться. • Их другие ресурсы, такие как принтеры и файловые серверы, доступны. • Их файлы с данными сохраняются, когда они их оставляют на время. • Их прикладное программное обеспечение установлено и работает, как положено. • При необходимости они получают дружественную и компетентную помощь. Пользователи хотят, чтобы эти условия выполнялись 24 часа в сутки, 7 дней в неде- лю. Желательно бесплатно. Пользователи недовольны в следующих случаях. • У них возникает простой, намеченный или незапланированный. • Из-за модернизации происходят внезапные, несовместимые изменения. • Они получают непонятные сообщения от системы или системных администра- торов. • Они получают долгие объяснения того, почему все это не работает. Когда что-то выходит из строя, пользователи хотят знать, когда это будет исправле- но. Их не интересует, какой жесткий диск или генератор сломались или почему; оставь- те эту информацию для своих административных отчетов. С точки зрения пользователя никакие новости не являются хорошими. Система или работает, или нет, и в последнем случае не имеет значения почему. Максимальное удо- вольствие наши клиенты получают, если они даже не замечают, что мы существуем! Грустно, но факт. Не менее важно, чтобы были довольны и ваши сотрудники. Хороших администра- торов трудно найти, и их потребности нужно учитывать при настройке системы управ- ления вашей организацией. Системные администраторы и другой технический штат до- вольны, если выполняются следующие условия. • Их компьютеры и системы поддержки пребывают в работоспособном состоянии. • У них есть необходимые ресурсы, чтобы выполнять свою работу (двойные мони- торы!). • Они имеют новейшее и лучшее программное и аппаратное обеспечение. • Они имеют стимул для работы или, по крайней мере, интересную работу (мини- мум тяжелой работы). • Их никто постоянно не дергает. • Они могут проявлять творческий подход без оглядки на босса, постоянно во все вмешивающегося и подсказывающего. • Их часы работы и уровень стресса не выходят за пределы разумного.
1232 Часть III. Разное Для того чтобы двигаться вперед, технические сотрудники нуждаются не только в зарплате в конце месяца. Они должны чувствовать, что у них есть степень творческого контроля над своей работой и что их ценят коллеги, босс и их пользователи. Некоторые условия, при которых довольны и пользователи, и технический персонал, совпадают. Однако некоторые факторы кажутся несовместимыми или даже находятся в прямом противоречии. Босс должен удостовериться, что все эти противоречия можно сгладить или устранить. Соглашение о качестве оказываемых услуг помогает помирить конечных пользова- телей и технический персонал. Хорошо написанное соглашение учитывает каждую про- блему, упомянутую в следующих разделах. Спектр услуг и их описание В соглашении о качестве оказываемых услуг описывается то, что организация может ожидать от отдела информационных технологий. Он должен быть написан в терминах, которые могут быть поняты нетехническими сотрудниками. Перечислим в качестве при- мера некоторые из этих услуг. • Электронная почта. • Интернет и веб-доступ. • Файловые серверы. • Бизнес-приложения. • Печать. В соглашении также должны быть определены стандарты, которых будет придержи- ваться отдел информационных технологий. Например, раздел о доступности услуг дол- жен определять часы работы, согласованные окна обслуживания и ожидаемое время, в течение которого будет доступен технический персонал, чтобы обеспечить интерактив- ную поддержку. Одна организация могла бы решить, что регулярная поддержка должна быть доступна с 8:00 до 18:00 в будние дни, а чрезвычайная поддержка — круглосуточно. Другая организация могла бы решить, что нуждается в стандартной интерактивной под- держке, доступной всегда. Представим список проблем, которые следует рассмотреть, документируя ваши стан- дарты. • Время отклика. • Обслуживание (и время отклика) в течение выходных и неурочных часов. • Посещения на дому (поддержка для домашних компьютеров). • Специальное (уникальное или патентованное) аппаратное обеспечение. • Политика модернизации (устаревшие аппаратные средства, программное обеспе- чение и Т.Д.). • Поддерживаемые операционные системы. • Стандартные конфигурации. • Истечение сроков действия резервных магнитных лент. • Программное обеспечение специального назначения. • Вспомогательная работа (чистка экранов и клавиатур, прочистка вентиляционных решеток).
Глава 32. Управление, стратегия и политика 1233 Рассматривая стандарты услуг, имейте в виду, что многие пользователи захотят само- стоятельно настроить свою среду (или даже свои системы), если не будет установлено программное обеспечение, чтобы это предотвратить. Стереотипный ответ на эти попыт- ки — запретить всем пользователям осуществлять любые модификации. Это упрощает работу отдела информационных технологий, но не всегда является лучшей стратегией для всей организации. Укажите эту проблему в своем соглашении о качестве оказываемых услуг и попытай- тесь стандартизировать ее решение на нескольких определенных конфигурациях. Иначе ваше стремление к легкому обслуживанию и быстрому росту в рамках всей организации встретят серьезные препятствия. Поощряйте своих творческих сотрудников предлагать модификации, в которых они нуждаются, и будьте заботливы и щедры, учитывая их предложения в своих стандартных конфигурациях. Если вы не сделаете этого, то ваши пользователи будут упорно нарушать ваши правила. Стратегии управления очередями Пользователи должны знать не только, какие услуги им будут оказаны, но и схему приоритетов, используемую для управления очередью заданий. Схемы приоритетов всегда оставляют возможность для маневра, но все же попытайтесь спроектировать та- кую схему, которая охватывала бы большинство ситуаций, почти или вовсе не прибегая к исключениям. Некоторые факторы, связанные с приоритетом, перечислены ниже. • Важность услуги для всей организации. • Влияние на безопасность (там было нарушение?). • Оплаченный или оговоренный уровень сервисного обслуживания. • Количество задействованных пользователей. • Важность любого релевантного крайнего срока. • Скандальность задействованных пользователей (“писклявые колеса”). • Важность задействованных пользователей (это дело тонкое, но будем честными: у некоторых людей в вашей организации есть больше авторитета, чем у других). Хотя на ваше ранжирование будут влиять все эти факторы, мы рекомендуем подхо- дить к исключениям с простым сводом правил и долей здравого смысла. В основном, мы используем следующие приоритеты. • Много людей не могут работать успешно. • Один человек не может работать успешно. • Запросы на усовершенствования. Если два или больше запросов имеют высший приоритет и они не могут выполнять- ся параллельно, мы делаем выбор, основываясь на серьезности проблемы (например, неработающая электронная почта доставляет неудобства почти всем, тогда как времен- ное отсутствие веб-службы могло бы помешать только нескольким людям). Очереди с более низкими приоритетами обычно обрабатываются по принципу FIFO. Пользователи предполагают, что все их важные данные хранятся на резервных маг- нитных лентах, которые будут заархивированы навсегда. Однако резервные носители не хранятся неопределенно долго; магнитные носители имеют конечный срок годности, после наступления которого чтение данных затрудняется. (Вы должны периодически перезаписывать свои данные, возможно, на более новые носители, если хотите хранить их в течение долгого времени.) Резервные магнитные ленты могут также быть затребова-
1234 Часть III. Разное ны в суд. Таким образом, ваша организация, возможно, не захочет, чтобы старые данные остались доступными навсегда. В этом случае лучше всего совместно с руководителями, отвечающими за такие решения, составить письменное соглашение, которое определяет, сколько времени резервные копии должны храниться, следует ли их обновлять (обяза- тельно? возможно? никогда?) и где эти копии должны храниться. Эти решения должны быть приняты в контексте политики хранения данных всей организации. Такой тип стратегий описан в этой главе позже, но, вообще, вы должны классифицировать свои данные и разработать график хранения для каждого класса. Доведите стратегию резервирования и хранения данных до ваших пользователей. Эта мера будет способствовать реалистическим ожиданиям и относительно резервных ко- пий, и относительно возможности их восстановления. Она также позволит уведомить пользователей, что они должны принять собственные меры предосторожности, если считают, что нуждаются в лучшей защите данных, чем предусмотрено в их соглашении о качестве оказываемых услуг. В частности, пользователи должны понять, будут ли сохраняться файлы на их мест- ных автоматизированных рабочих местах. Многие организации поддерживают свои цен- трализованные файловые серверы, но не отдельные автоматизированные рабочие места. Обычно автоматизированные рабочие места клонируются на основе системных образов и считаются доступными. Пользователи должны знать об этом, чтобы правильно хра- нить важную информацию. Роли и обязанности Вы должны зафиксировать в документе, кто и за что отвечает. Организации, которые не делят обязанности, становятся непроизводительными и неэффективными. Задачи остаются “беспризорными”, потому что не ясно, где заканчивается одна область компе- тенции и начинается другая. Задачи могут также стать жертвой группового мышления, где одну задачу решают два или три администратора. Перечислим примеры определен- ных ролей. • Администратор резервного копирования • Знаток сетей хранения и файловых серверов • Прикладной спорщик • Царь безопасности и заплат • Парень, который никогда не уверен в том, что он делает1 В качестве альтернативы вы могли бы распределять роли и обязанности согласно описаниям услуг, которые вы уже определили. Этот подход может подразумевать, что вы должны очертить обязанности с точки зрения администрации, а не с точки зрения пользователя. Не забывайте включать обязанности “дублера” в свою таксономию. Сотрудники не будут присутствовать в офисе каждый день, и вы должны знать, кто куда идет, когда основной администратор домена отсутствует. Показатели соответствия Соглашение о качестве оказываемых услуг должно определить, как организация из- меряет ваш успех при выполнении условий соглашения. Цели и ориентиры позволяют 1 Ну хорошо, возможно, в вашем коллективе эта роль не нужна. Но она предусмотрена про- мышленным стандартом.
Глава 32. Управление, стратегия и политика 1235 работникам совместно стремиться к общему результату и могут заложить основу для со- трудничества во всей организации. Конечно, вы должны удостовериться, что у вас есть инструменты, позволяющие измерить согласованные показатели. Как минимум, вы должны отследить следующие показатели вашей информационной инфраструктуры. • Процент или количество проектов, законченных вовремя и в пределах бюджета. • Процент или количество выполненных пунктов соглашения о качестве оказывае- мых услуг. • Процент продолжительности работы системы (например, электронная почта до- ступна через службу Q1 в течение 99,92% времени). • Процент или число билетов, которые были удовлетворительно распознаны. • Среднее время распознания билета. • Процент или количество нарушений техники безопасности, зарегистрированных согласно установленной процедуре. 32.2. Информационная структура организации Теперь, когда мы рассмотрели общую схему функционирования отдела информаци- онных технологий, остановимся на структуре организации. По мере развития органи- зации становится очевидным, что не каждый член группы может или должен знать все о ее инфраструктуре. Вместо этого необходимо найти баланс между эффективностью и разделением обязанностей. Ролевое разделение добавляет уровень сдержек и противовесов к структуре организа- ции. Со временем эта особенность становится более важной, а стандарты и инструкции внедряются в даже самую маленькую организацию. Рассмотрим, например, американскую компанию с 20 сотрудниками, которая раз- работала дистанционное приложение для медицинских учреждений. Если это прило- жение хранит какую-либо защищенную медицинскую информацию (protected health information — PHI), то все системы организации должны соответствовать суровому Закону об отчетности и безопасности медицинского страхования (Health Insurance Portability and Accountability — HIPAA). Между прочим, это законодательство требует, чтобы вы определили роли, чтобы защитить доступ к конфиденциальным данным. На- пример, определением уровня доступа, который должен иметь пользователь, и фактиче- ским обеспечением этого доступа обязаны заниматься два разных человека. В центре типичной информационной структуры организации лежит система отсле- живания запросов (ticketing system), а также сервисная служба, группа архитектуры пред- приятия, оперативная группа и уровень управления. Как показано на рис. 32.1, каждая часть организации взаимодействует с системой отслеживания запросов. Основы: система отслеживания запросов и управления задачами Система отслеживания запросов и управления задачами лежит в основе функциони- рования каждого отдела информационных технологий. Наличие хорошей системы по- может вашим сотрудникам избежать двух наиболее распространенных ловушек техноло- гического процесса, перечисленных ниже.
1236 Часть III. Разное Рис. 32.1. Типичная информационная структура организации • “Беспризорные” задачи, о которых все думают, что о них заботится кто-то другой. • Ресурсы, растраченные впустую из-за дублирования усилий, когда несколько лю- дей или групп работают над той же самой проблемой без координации. Общие функции систем отслеживания запросов Система отслеживания запросов на устранение неисправностей принимает заявки через различные интерфейсы (электронная почта, веб-формы и командные строки, яв- ляющиеся наиболее распространенными инструментами) и отслеживает их от момен- та подачи до решения проблемы. Менеджеры могут пересылать заявки специальным * группам или отдельным сотрудникам. Штат может запросить у системы, чтобы видеть > очередь поданных заявок и, возможно, удовлетворить некоторых из них. Пользователи могут узнать статус запроса и видеть, кто работает над ним. Менеджеры могут извлечь следующую информацию высокого уровня. • Количество поданных заявок • Среднее время удовлетворения заявки • Производительность системных администраторов • Процент неудовлетворенных заявок • Распределение рабочей нагрузки во время поиска решения История заявки, сохраненная в системе отслеживания запросов, становится истори- ей проблем, существующих в вашей информационной инфраструктуре, и их решений. Если эта история легко доступна для поиска, то это становится неоценимым ресурсом для системного администратора. Сообщения о решенных проблемах можно послать начинающему системному ад- министратору и стажерам, поместить в систему часто задаваемых вопросов или просто зарегистрировать. Новые сотрудники могут извлечь выгоду из получения копий удо- влетворенных запросов, потому что эти запросы содержат не только техническую ин- формацию, но и примеры тона и коммуникационного стиля, которые являются подхо- дящими для общения с клиентами.
Глава 32. Управление, стратегия и политика 1237 Как и все документы, исторические данные системы отслеживания запросов могут потенциально использоваться против вашей организации в суде. Следуйте инструкциям по хранению документов, установленным вашим юридическим отделом. Большинство систем, отслеживающих запросы, автоматически подтверждают по- лучение новых запросов и назначают им номер, который сотрудник, подавший запрос, может использовать, чтобы отследить его или его статус. В ответе, который отсылается автоматически, должно быть ясно указано, что это — только подтверждение. Оно долж- но сопровождаться немедленным сообщением от живого человека, который объяснит план устранения проблемы или обработки запроса. Владение запросом Работу можно разделить, но, как показывает опыт, ответственность меньше под- дается распределению. Каждая задача должна иметь одного владельца. Этот человек не должен быть наблюдателем или менеджером, желающим действовать только как ко- ординатор. Этот кто-то должен быть готов сказать: “Я беру на себя ответственность за решение задачи”. Важный побочный эффект этого подхода состоит в том, что он позволяет выяснить, кто что сделал и кто какие изменения внес. Эта прозрачность становится важной, если вы хотите выяснить, почему что-то было сделано именно так или почему что-то работа- ет не так или не работает вообще. Быть “ответственным” за задачу — не значит быть козлом отпущения, если возника- ют проблемы. Если ваша организация определяет ответственность как “наказуемость”, то вы можете обнаружить, что количество доступных владельцев проектов быстро ис- тощилось. Ваша цель в назначении ответственности состоит в том, чтобы просто устра- нить двусмысленность в отношении того, кто должен решать каждую проблему. Не на- казывайте сотрудников за то, что они попросили помощи. С точки зрения клиента, хорошая система назначения — та, в которой проблемы по- падают к компетентному человеку, способному решить проблемы быстро и полностью. Но с организаторской точки зрения, назначения должны быть стимулом для сотруд- ников, чтобы они продолжали совершенствоваться. Ваша работа состоит в том, чтобы уравновесить возможности сотрудников и стимулировать их, одновременно удовлетво- ряя все желания клиентов. Большие задачи могут быть разными, включая полноценные проекты по разработке программного обеспечения. Эти задачи могут потребовать использования методов фор- мального управления проектом и инструментов программирования. Мы не описываем эти инструменты здесь; однако они важны и не должны быть пропущены. Иногда системные администраторы знают, что конкретная задача должна быть сде- лана, но они не делают этого, потому что эта задача неприятна. Системный админи- стратор, указавший на заброшенную, беспризорную или непопулярную задачу, веро- ятно, и получит ее “в награду”. Эта ситуация создает конфликт интересов, потому что заставляет системных администраторов замалчивать такие ситуации. Не позволяйте этому происходить в вашей организации; дайте вашему системному администратору свободу безбоязненно указывать на проблемы. Вы можете позволить им поднимать во- просы, не назначая владельца или привязывая их непосредственно к проблеме. Кроме того, вы можете создать почтовый псевдоним, на который можно послать сообщения о проблемах.
1238 Часть III. Разное Система отслеживания запросов с точки зрения пользователей Получение быстрого ответа от человека является критерием удовлетворенности по- требителя, даже если личный ответ содержит не больше информации, чем автоматизи- рованный. При возникновении большинства проблем человеку, подавшему заявку, бо- лее важно знать, что она была рассмотрена человеком и что это поможет немедленно решить проблему. Пользователи понимают, что администраторы получают много запро- сов, и они готовы ждать вашего внимания разумно долгое время. Но они не желают, чтобы их игнорировали. Механизм, посредством которого пользователи представляют запросы, затрагива- ет их восприятие системы. Удостоверьтесь, что вы понимаете культуру своей органи- зации и предпочтения своих пользователей. Они хотят использовать веб-интерфейс? Прикладную программу? Почтовый псевдоним? Возможно, они хотят делать только телефонные звонки! Также важно, чтобы администраторы не торопились и удостоверились, что они пони- мают то, о чем фактически просят пользователи. Это кажется очевидным, но вспомните последние пять писем, которые вы послали по электронной почте псевдониму техниче- ской поддержки или обслуживания клиентов. Держим пари, что было, по крайней мере, несколько случаев, когда ответ не имел никакого отношения к вопросу — не потому, что те компании не были компетентны, а потому, что точный анализ заявок на устранение неисправности более труден, чем это кажется. Как только вы прочитали первую часть запроса и поняли, о чем спрашивает клиент, остальная часть запроса часто перестает вас интересовать и заменяется фразой “и тому подобное”. Боритесь с этим! Клиенты очень не любят, когда их запрос был неправиль- но понят и должен быть повторно представлен или вновь заявлен. Перечитайте его еще раз. Запросы часто бывают неопределенными или неточными, потому что сотрудники, которые их подают, не обязаны иметь техническую подготовку, чтобы описывать про- блему так, как хочет системный администратор. Как бы то ни было, это не мешает поль- зователям высказывать их собственные предположения относительно того, что случи- лось. Иногда эти предположения совершенно правильные, а иногда вы должны сначала расшифровать запрос, чтобы определить то, что пользователь думает о проблеме, а затем проследить ход его мыслей, чтобы интуитивно постигнуть основную проблему. Типичные диагностические системы В табл. 32.1 и 32.2 перечислены характеристики нескольких известных диагностиче- ских систем. В табл. 32.1 содержатся характеристики общедоступных систем, а в табл. 32.2 представлены коммерческие системы. Таблица 32.1. Открытые диагностические системы Название МЙШг Double Choco Latte w PHP PM dcl/sourceforge.net Mantis WE PHP M mantist.org OTRS WE Perl PMOD otrs.org RT Request Tracker WE Perl M bestpractical.com
Глава 32. Управление, стратегия и политика 1239 Окончание табл. 32.1 Название Ввод* Язык Прикладная часть6 веб-caftr ’ Scarab WE Java м scarab.tigris.org Trouble Ticket Express WEB Perl FMB troubleticketexpress.com а Типы ввода: W — веб, Е — электронная почта. 6 Прикладная часть: М — MySQL, Р — PostgreSQL, О — Oracle, D — DB2, F — простые файлы. в Для использования электронной почты и MySQL необходимо купить модули надстроек (правда, они недо- рогие). Таблица 32.2. Коммерческие диагностические системы Название Масштаб ~Веб*е«йг EMC lonix (Infra) Огромная infra-corp.com/solutions HEAT Средняя frontrange.com Remedy (сейчас BMC) Огромная remedy.com ServiceDesk Огромная ca.com/us/service-desk.aspx Track-lt! Средняя numarasoftware.com Нам очень нравится система Mantis. Первоначально она была разработана для от- слеживания неполадок в программном обеспечении видеоигр. Она запускается на Linux, Solaris, Windows, Mac OS и даже OS/2, занимает мало места, проста, легко изменяется и конфигурируется. Требует наличия РНР, MySQL и веб-сервера. Но ее самым важным качеством является хорошая документация! OTRS (Open Ticket Request System) — тоже неплохая система. В ней доступны интер- фейсы как для клиентов, так и для системных администраторов, а также интерфейс для электронной почты. OTRS позволяет настраивать очень много параметров (например, она позволяет по очереди настраивать приветственные сообщения) и умеет даже фикси- ровать время, затраченное на обработку сообщений о неполадках. В табл. 31.2 представлено несколько коммерческих программ для управления запро- сами. Их язык реализации и базы данных здесь не указаны, потому что эта информация в полном объеме доступна на посвященных им веб-сайтах. Некоторые из этих коммерческих систем настолько сложны, что для их сопровожде- ния, настройки и поддержания в рабочем состоянии нужно нанимать отдельного чело- века или даже двух (для тех, кто не знает, сообщаем, что в данном случае речь идет о системах Remedy и ServiceDesk). Такие системы подходят для организаций с большим штатом IT-сотрудников и являются неудачным выбором при наличии типичной, не- большой команды IT-специалистов, которые и так постоянно завалены работой. Распределение сообщений о неполадках В большой организации, даже в той, где установлена замечательная диагностиче- ская система, все равно необходимо решить еще одну проблему. Не очень хорошо, когда системным администраторам приходится разрываться между задачей, над которой они сейчас работают, и очередью запросов, особенно если запросы поступают по электрон- ной почте прямо в их личный почтовый ящик. Мы применили два подхода для решения этой проблемы. Вначале мы организовали для наших системных администраторов смены по полдня. Каждый во время своей смены должен был стараться ответить на как можно большее
1240 Часть III. Разное количество поступивших запросов. Проблемой этого подхода было то, что не у всех системных администраторов были навыки, необходимые для ответа на все вопросы и устранения всех проблем. Иногда ответы были некорректными из-за того, что заступив- ший на смену человек был новичком и еще плохо знал клиентов, их среды или преду- смотренные в их контракте услуги поддержки. В результате старшим администраторам все равно приходилось присматривать за всеми остальными, из-за чего они, естествен- но, не могли полностью сконцентрироваться на своей работе. В конечном итоге каче- ство обслуживания только ухудшилось, и никакой пользы этот подход не принес. После такого неудачного опыта мы придумали роль “диспетчера”, которая ежеме- сячно переходит от одного старшего администратора к другому. Диспетчер отвечает за проверку системы отслеживания запросов на наличие новых записей и распределяет за- дачи между конкретными сотрудниками. При необходимости диспетчер связывается с пользователями и узнает у них дополнительные сведения, необходимые для определения степени важности запросов. Диспетчер пользуется специальной базой данных о навыках сотрудников, созданной в организации своими силами, для принятия решений о том, у кого в группе поддержке имеются необходимые навыки и время. Кроме того, диспетчер также следит за тем, чтобы запросы обрабатывались своевременно. Перечень навыков Никто не раздражает опытного пользователя больше, чем человек из команды под* держки, который, пока на самом деле просто пытается отыскать в базе данных инфор- мацию о клиенте, спрашивает: “А вы подключили кабель питания?”. С другой стороны* заставлять опытного администратора объяснять пользователю-новичку, как отыскать клавишу <Del> в какой-нибудь системе обработки текстов, — это тоже просто неэффек- тивное использование ресурсов. У нас каждый сотрудник обязательно должен отработать в службе поддержки опреде- ленное количество часов в неделю. Сотрудники отдела поддержки включают это время в свой еженедельный план работ и затем вызывают человека, когда для него появля;- ется задание. Задания распределяются в соответствии с навыками, требующимися для устранения проблемы, и количеством времени, оставшимся у каждого в еженедельном резерве отдела поддержки. Для того чтобы эта схема работала успешно, необходим сбалансированный перечень навыков сотрудников. На протяжении определенного времени каждый сотрудник должен отработать свое количество часов в службе поддержки. В целом, сотрудник, имеющий ' множество записей в списке навыков, является более “ценным”. Однако в сотруднике с меньшим количеством навыков тоже нет ничего плохого, если для всех хватает работы* Точный список навыков помогает определить, достаточно ли в организации сотруд- ников с определенными навыками, чтобы можно было не волноваться, если кто-то из них уйдет на больничный или в отпуск. Список навыков можно составлять постепенно, по мере появления проблем и их решения различными сотрудниками, включая в него наименование проблемы, имя занимавшегося ею сотрудника и продемонстрированный им при ее решении уровень мастерства. Навыки следует описывать с определенной степенью точности, т.е. и не слишком конкретно и не слишком обще. Приведенный ниже в качестве примера список демон- стрирует наиболее оптимальный вариант перечисления навыков. • Создание и удаление пользователей, установка паролей, изменение квот. • Создание учетных записей CVS или SVN.
Глава 32. Управление, стратегия и политика 1241 • Интегрирование новых драйверов оборудования в RIS (Windows). • Упаковка Windows-приложения в формате MSI. • Создание и установка пакетов программ в Linux. • Анализ журнальных файлов. • Устранение неполадок, связанных с почтовым сервером. • Отладка проблем, связанных с печатью. • Устранение общих неполадок с оборудованием. • Внесение записей в службу DNS. • Решение вопросов, касающихся лицензий на программное обеспечение. • Умение отвечать на вопросы, касающиеся безопасности в системах Windows. • Умение отвечать на вопросы, касающиеся безопасности в системах UNIX. • Разрешение запросов по пакету Samba. • Конфигурирование сервера DHCP. • Настройка сервера LDAP. • Добавление и удаление веб-сайтов (конфигурирование сервера Apache). Управление временем Системное администрирование подразумевает такое количество переключений с од- ного контекста на другой за день, которое нигде не встретишь и за целый год, и, в ос- новном, с этим хаосом приходится справляться именно сотрудникам отдела поддержки пользователей. Каждый администратор должен обладать навыками распределения вре- мени. Без них он не сможет справляться со своими повседневными обязанностями и, следовательно, станет раздражительным или вообще впадет в депрессию. (Если же он уже находится в раздраженном или депрессивном состоянии, ему станет еще хуже.) Системные администраторы “изнашиваются” очень быстро. Многих из них хватает всего лишь на несколько лет. Никто не хочет, чтобы его все время вызывали и постоянно вычитывали. Умение эффективно распределять время и успевать обслуживать пользова- телей так, чтобы они оставались довольны, является очень выигрышным качеством. 32.3. Служба поддержки Служба поддержки — главная составляющая структуры отдела информационных тех- нологий, представленной на рис. 32.1. Задача службы поддержки — взаимодействие с людьми, которые используют компьютерные системы, которые вы обслуживаете. Диапазон услуг Сотрудники службы поддержки выполняют те разделы соглашения о качестве ока- зываемых услуг, в которых определено, какие виды прямой помощи человек в пределах организации может получить. Проблемы, решаемые службой поддержки, включают во- просы эксплуатации настольных систем, сопровождение приложений и такие первоо- чередные проблемы системного администрирования, как отключение электропитания сервера, сбой в сети и восстановление файлов. Кроме обычных услуг, предоставляемых диагностической системой или системой экстренной поддержки, это подразделение может также предложить вспомогательные
1242 Часть III. Разное услуги, такие как учебные семинары. Эти меры помогают увеличить самостоятельность клиентов и сокращают количество запросов поддержки. Кроме того, важно сформулировать правила эскалации. Служащие должны знать, что сделать, когда их потребности не удовлетворяются или когда они хотят выразить благо- дарность за хорошо сделанную работу. Доступность службы поддержки Хороший отдел информационных технологий состоит из квалифицированных со- трудников, всегда готовых прийти на помощь клиентам. Большинство проблем незначительны и могут безопасно включаться в очередь на об- служивание. Другие проблемы приводят к простою и требуют пристального внимания. Автоматизированные ответы от системы отслеживания запросов и записанные телефон- ные сообщения, объявляющие о рабочем расписании, только вызывают раздражение. Обеспечьте пользователям доступ к последней инстанции, если возникает такая необхо- димость. Как правило, для этого достаточно мобильного телефона, которым обменива- ются системные администраторы во внеурочное время. Зависимость от службы поддержки К сожалению, превосходная поддержка иногда порождает зависимость. Пользователи могут легко привыкнуть консультироваться со службой поддержки, даже когда это не является необходимым. Если вы понимаете, что кто-то использует систему поддержки для ответов, которые они легко могли найти в справочнике или в системе Google, то можете попытаться ответить на такие вопросы, указывая соответствующую справочную страницу или идентификатор URL. Однако будьте осторожны: эта тактика может дей- ствительно возмутить пользователей, если не проявить при этом предельное уважение. 32.4. Архитектура предприятия Еще одна информационная составляющая (рис. 32.1) — архитектура предприятия — состоит из администраторов, имеющих полное техническое представление об органи- зации. Эта роль почти всегда подразумевает некоторое количество администраторов систем UNIX или Linux. Эти люди рассматривают как непосредственное, так и долго- срочное влияние новых систем на общую инфраструктуру. Они понимают, как организа- ция будет развиваться в ближайшие годы и как сегодняшние требования станут основой для будущих модификаций. Архитекторы предприятия также ответственны за понимание принципов взаимодей- ствия систем. Например, в организации, которая хранит конфиденциальную информа- цию о клиентах, архитекторы должны понимать, как возможность шифрования базы данных будет воздействовать на конечных пользователей, и определять, является ли это воздействие приемлемым. Следующие разделы представляют собой перечень наилучших архитектурных реше- ний, которыми следует пользоваться при планировании структуры отдела информаци- онных технологий в своей организации. Эти принципы особенно важны, когда кон- фигурация, которая будет поддерживаться, является новой или необычной, потому что примеры таких ситуаций очень сложно отыскать в реальном мире. Все хорошо спроек- тированные процессы подразумевают соблюдение этих или близких к ним принципов.
Глава 52. Управление, стратегия и политика 1243 Процессы должны быть воспроизводимыми Системное администрирование — это не показательное выступление. Все, что дела- ется, должно делаться последовательно и многократно. Обычно это означает, что низ- коуровневые изменения должны вноситься сценариями или конфигурационными про- граммами, а не самими системными администраторами. Расхождения в конфигурации должны перехватываться и фиксироваться в конфигурационных файлах соответствую- щего, предназначенного для администрирования программного обеспечения. Например, сценарий, настраивающий новый компьютер, не должен задавать вопро- сов о номерах IP-адресов и пакетах, которые нужно установить. Вместо этого, он должен проверять каталог конфигурации системы и извлекать всю необходимую информацию оттуда. Он может отображать эту информацию для подтверждения, но выбираемые па- раметры должны быть предопределены. Чем меньше будет участвовать в этом процессе пользователь, тем меньше шансов, что он допустит какую-нибудь ошибку. Но давайте уточним: мы не описываем здесь организацию, где все стратегические решения принимаются администраторами “высшего ранга” и беспрекословно выполня- ются глупыми трутнями. Возможность воспроизведения не менее важна и тогда, когда вы являетесь единственным администратором в своей организации. Незапланированных конфигурационных решений, не оставляющих никаких данных для аудита, лучше не принимать. Если требуется что-то изменить, изменяйте центральную конфигурацион- ную информацию и распространяйте изменения уже оттуда. Сохранение отладочных данных Кто сделал, что сделал и зачем? В случае появления проблем в системе, наличие воз- можности вернуться к последнему рабочему состоянию или, по крайней мере, выяснить, что изменилось с тех пор, позволит устранить их быстрее. Важно знать не только “что” изменилось, но и “кто” внес это изменение и “почему”. Беседа с человеком, реализо- вавшим приведшее к возникновению проблем изменение, часто позволяет увидеть суть. Возможно, изменение удастся быстро отменить, но иногда бывает так, что изменение было внесено в благих целях и его отмена может только ухудшить дело. Системы контроля изменений являются одним из наиболее удобных способов их от- слеживания. Они предоставляют как хронологический перечень фактических данных, так и информацию о том, каким из системных администраторов было внесено то или иное изменение. При правильном использовании каждое изменение сопровождается комментарием, в котором объясняется причина его внесения. Автоматизированные средства могут проверять конфигурационные файлы, которые они изменяют, и указывать на себя в этих комментариях. Благодаря этому выявить не- правильно работающий сценарий и отменить внесенные им изменения совсем не трудно. Ш Системы контроля изменений описаны в разделе 12.9. Если ваша организация использует систему отслеживания запросов, в ней также удобно хранить изменения. Для каждого изменения можно создать запрос, в который включается информация о том, кто, что, когда, где и почему сделал. Кроме того, не ме- нее важно то, что этот запрос может содержать план возврата. Иначе говоря, если од- нажды ночью что-то пойдет не так, то дежурному администратору будет не обязательно будить системного администратора. И вы, и ваши сотрудники должны дисциплинированно обращаться с каждым запро- сом на изменение. Системы отслеживания запросов приносят пользу только при усло- вии, что их используют все администраторы при каждом изменении.
1244 Часть III. Разное Осознание важности документации На самом деле документация настолько важна для масштабируемой инфраструктуры, что мы посвятили ей целый подраздел в разделе 32.5. Настройка и кодирование Использовать существующие средства — это хороший подход, и так следует посту- пать всегда, когда это возможно. Но двух абсолютно одинаковых организаций не бы- вает, и каждая организация обязательно имеет какие-нибудь уникальные требования. Информационная инфраструктура, которая в точности удовлетворяет требования орга- низации, увеличивает конкурентоспособность этой организации в целом и продуктив- ность ее сотрудников в частности. Благодаря гибкости в плане написания сценариев и обилию средств с открытым ис- ходным кодом, система UNIX является идеальной базой для создания хорошо отрегули- рованной инфраструктуры. С нашей точки зрения, группа системных администраторов, не умеющая выполнять такую функцию, как разработка программного обеспечения, яв- ляется слабой. Содержание системы в чистоте Системное управление заключается не только в установке, добавлении и конфигу- рировании программного и аппаратного обеспечения; оно также предполагает наличие знаний о том, что следует сохранить, выкинуть и обновить. Мы называем эту концеп- цию “устойчивым управлением”. Иметь возможность добавить новый компьютер в сре- ду за пять минут и создать новую учетную запись пользователя за десять секунд — это замечательно. Но если заглянуть в будущее, станет ясно, что наличие возможности от- ыскивать и удалять старые учетные записи и компьютеры организованным образом яв- ляется не менее важным. Устойчивость в системном управлении означает, что у вас есть концепции и средства, необходимые для того, чтобы вы могли выполнять свою работу организованным образом в течение длительного срока. 32.5. Операции В заключение рассмотрим последнюю роль в этой главе — операции. С деловой точ- ки зрения, под операциями подразумеваются “ежедневные рутинные действия, которые и представляют собой цель бизнеса”. С технической точки зрения, операции — это ис- точник проблем, которые должен решать системный администратор. В качестве приме- ра операций назовем возврат, мониторинг, установку заплат, обновление, инсталляцию нового программного обеспечения и отладку. Оперативная группа отвечает за установку и сопровождение информационной ин- фраструктуры. Как правило, оперативная группа имеет дело с компьютерами и прово- дами, а справочная служба — с людьми. Оперативная группа фокусируется на создании стабильной и заслуживающей дове- рия среды для клиентов. Доступность и надежность являются ее ключевыми задачами. Сотрудники этой группы не должны ни проводить никаких экспериментов, ни делать никаких неожиданных исправлений или улучшений по пятницам. Просто вероятность того, что это закончится появлением проблем (заметить которые на выходных смогут только клиенты), слишком высока.
Глава 32. Управление, стратегия и политика 1245 Время простоев должно быть минимальным Многие люди зависят от предоставляемой нами вычислительной инфраструктуры. Внутреннее подразделение, пожалуй, сможет какое-то время обходится без своего веб- сайта, а вот компания, принимающая заказы по почте через Интернет, такая как компа- ния Amazon.com, — нет. Некоторые даже не заметят, что сервер печати не работает, но сотрудника, которого поджимают сроки сдачи документа, это действительно очень рас- строит. В большинстве организаций потеря доступа к электронной почте обычно всех выводит из себя. Центральные файловые серверы тоже являются потенциальным источ- ником неприятностей. В некоторых организациях придется обеспечивать наличие “аварийной службы”. В коммерческой среде это может означать круглосуточное присутствие на месте опыт- ных системных администраторов. Даже если бюджет не позволяет явно обеспечить круглосуточное дежурство, нужно быть готовым к вызову любых администраторов, которые окажутся доступны в позднее время суток или в выходной день. Дежурный мобильный телефон или другая система уведомления часто являются “довольно хорошим” средством. Проверьте, чтобы пользо- ватели могли получать доступ к этому средству каким-нибудь простым и хорошо извест- ным способом; например, создайте адрес-псевдоним и сделайте так, чтобы все посту- пающие на этот адрес SMS-сообщения автоматически и немедленно перенаправлялись на дежурный мобильный телефон. Документирование зависимостей Для того чтобы делать точные предположения о доступности оборудования или пе- риоде безотказной работы, нужно знать не только о своих сильных и слабых местах (сте- пени надежности устанавливаемого оборудования), но и о зависимостях информацион- ных систем от другого оборудования, программного обеспечения и персонала. • Питание. Независимые источники и схемы питания, защита от перепадов напря- жения, резервные системы питания, такие как генераторы и источники беспере- бойного питания, разводка кабелей электропитания в здании, карты электропита- ния определенных компонентов оборудования. • Сеть. Проводка в здании, резервные линии связи, служба работы с клиентами для интернет-провайдеров, топология сети, контактная информация для других отде- лов в организации, выполняющих свою собственную роль в сетевом управлении. • Оборудование. Системы высокой степени готовности и процедуры для их исполь- зования, горячие и холодные резервы, запасные детали, договоры на техническое обслуживание оборудования. Переналадка или списывание старого оборудования Для того чтобы поддерживать свою инфраструктуру, нужно покупать новые компью- теры, переналаживать устаревшие и выкидывать совсем старые. О закупке оборудования мы расскажем позднее, но отметим, что многие сотрудники не желают расставаться со своими “любимцами”. Поскольку пользователям и менеджерам часто не очень хочется обновлять устарев- шее оборудование, вы иногда должны брать инициативу в свои руки. Финансовая ин- формация является самым убедительным доказательством. Если вам удастся на бумаге
1246 Часть III. Разное продемонстрировать, что стоимость обслуживания старого оборудования превышает стоимость средств, требующихся на его замену, многие возражения по поводу обнов- ления отпадут сразу. Иногда разнородное оборудование полезно заменить хотя бы для того, чтобы сэкономить время и усилия, требующиеся на поддержание различных версий операционных систем и программного обеспечения на уровне современных требований. Недорогое оборудование Intel/PC является стандартной архитектурной базой на- стольных систем, особенно теперь, когда продукция компании Apple поставляется на оборудовании компании Intel. Распространенность персональных компьютеров за по- следние годы сместила затраты со стороны оборудования в сторону программного обе- спечения и его поддержки. Для того чтобы поддерживать актуальную инфраструктуру, необходимо действовать на опережение. Разработайте правила, которые регламентируют срок использования разных систем. Например, ноутбуки следует использовать не более трех лет, настольные системы — четыре года, а серверы — пять лет. Эти показатели могут зависеть от произ- водителей и контракта на поддержку. Планирование замены старого оборудования экономит время и снижает вероятность сбоев. Если ноутбуки меняются каждые три года, то вряд ли вы посреди ночи получите сообщение, что ваш исполнительный директор, находящийся в командировке, не может получить электронные сообщения, потому что его ноутбук вышел из строя. Поддержка локальной документации Точно так же как большинство людей верят в то, что физические упражнения и све- жие овощи благотворно влияют на организм, каждый ценит хорошую документацию и знает о ее важности. К сожалению, это вовсе не означает, что она будет составляться и обновляться ими без напоминаний. Действительно, почему мы должны волноваться о документации? • Документация снижает вероятность одиночных сбоев. Замечательно, когда есть программы, которые позволяют мгновенно разворачивать рабочие станции и рас- пространять заплаты и обновления при помощи одной-единственной команды, но они становятся практически бесполезными, если по ним нет никакой документа- ции, а умеющий с ними обращаться специалист ушел в отпуск или вообще уволился. • Документация способствует воспроизводимости. Если правила и процедуры не хранятся в документах организации, ими вряд ли будут пользоваться регулярно. Когда администраторы не могут отыскать информацию о том, как следует посту- пать в том или ином случае, им приходится импровизировать. • Документация экономит время. Когда пишешь документацию, вовсе не кажется, что ты экономишь время, но, потратив несколько дней на решение проблемы, которая когда-то раньше решалась, но как именно уже никто не помнит, боль- шинство администраторов соглашаются, что написание документации более чем оправдывает себя. • И, наконец, самое главное: документация делает систему более понятной и по- зволяет вносить последующие изменения с учетом архитектуры системы. Когда изменения вносятся на основе только частичных знаний, они часто не совсем вписываются в имеющуюся архитектуру. Со временем степень несоответствия уве- личивается, и система даже работающим с ней администраторам начинается ка- заться беспорядочной коллекцией компонентов. В конечном итоге часто возника- ет желание удалить все компоненты и начать все заново.
Глава 32. Управление, стратегия и политика 1247 Локальная документация удобна во многих ситуациях. Доводилось ли вам заходить в машинный зал для выполнения перезагрузки одного сервера и сталкиваться с ряда- ми стоек с похожей и в то же время разной аппаратурой, никак не помеченной? При- ходилось ли вам устанавливать устройство, с которым вы уже имели дело когда-то дав- но, но сейчас помните только то, что настраивать его было очень трудно? Локальная документация должна храниться в четко установленном месте. В зави- симости от объема выполняемых операций, это может быть либо каталог на файловом сервере, смонтированный на всех компьютерах, либо даже домашний каталог, принад- лежащий какой-нибудь специальной учетной записи в системе. Убедив системных администраторов описывать в документах конфигурации и дей- ствия, важно защитить саму документацию. Злонамеренный пользователь может прине- сти много вреда, исказив документацию организации. Примите меры, чтобы сотрудни- ки, которым нужна документация, могли найти и прочитать ее (организуйте ее порск) и чтобы каждый, кто поддерживает эту документацию, мог изменить ее. Однако следует уравновешивать доступ и защиту. Документация, основанная на системе Wiki, особенно хороша, если вам необходимо легко устранить злонамеренные искажения. Другие системы можно защитить аналогич- ным образом с помощью системы контроля вариантов. Стандартизированная документация Как показывает наш опыт, самым простым и эффективным способом ведения доку- ментации является стандартизация небольших, простых документов. Вместо того чтобы писать целое руководство по системному управлению для своей организации, лучше на- писать ряд одностраничных документов, посвятив каждый из них какой-нибудь одной конкретной теме. Начните с общей темы, а затем разбейте ее на подтемы, содержащие дополнительную информацию. Если где-то необходимо добавить больше деталей, на- пишите дополнительный документ и перечислите в нем шаги, которые являются слож- ными или запутанными. Такой подход имеет несколько преимуществ. • Начальника, наверняка, интересует только общая настройка компьютерной среды в организации. Этого будет вполне достаточно, чтобы ответить на все вопросы как начальства, так и менеджеров. В подробности лучше не вдаваться, а то начальник еще решит разобраться во всем. • То же верно и для клиентов. • Любому сотруднику, переведенному на новую должность, необходимо быстро оз- накомиться с инфраструктурой, чтобы нормально включиться в производствен- ный процесс. “Загружать” таких сотрудников деталями не имеет никакого смысла, это только замедлит их адаптацию на новом месте. • Намного эффективнее и быстрее выбрать один подходящий короткий документ, чем искать нужную информацию в длинном руководстве. • Можно индексировать страницы, чтобы их было легко найти. Чем меньше време- ни администратор проводит в поиске, тем лучше. • Поддерживать документацию в “текущем” состоянии намного проще, если можно обновлять по одной странице.
1248 Часть III. Разное Последнее особенно важно. Обновление документации — это непростая задача; ее часто откладывают, когда не хватает времени. Имеется несколько подходов, которые по- зволяют поддерживать документацию в порядке. Во-первых, нужно установить правило, что документация должна быть краткой, важ- ной и вовсе не обязательно “отшлифованной”. Главное — передать суть. Ничто так не отбивает желание составлять документацию, как осознание того, что придется писать целую “диссертацию” на тему проектирования. Предъявление высоких требований к составлению документации приведет только к тому, что никто вообще не будет ее со- ставлять. Разработайте простую форму или шаблон для системных администраторов. Стандартная структура помогает системным администраторам регистрировать важную информацию, не раздувая документацию. Во-вторых, нужно внедрить документацию в процессы. Комментарии в конфигура- ционных файлах являются чуть ли не самой лучшей документацией. Они всегда там, где нужны, и их сопровождение (обновление) занимает совсем немного времени. Во многие стандартные конфигурационные файлы разрешается добавлять комментарии, и даже в те из них, которые не очень “дружат” с комментариями, часто все равно можно вставить какую-нибудь дополнительную информацию. Создаваемые локально средства могут требовать документацию в качестве части их стандартной конфигурационной информации. Например, программе, выполняющей установку нового компьютера, может быть нужна информация о владельце компьюте- ра, размещении, уровне поддержки и оплате, даже если эти факты не влияют непосред- ственно на конфигурацию программных средств компьютера. Документация не должна приводить к информационной избыточности. Например, если в организации имеется главный конфигурационный файл, в котором перечисляют- ся все компьютеры и их IP-адреса, больше нигде эта же информация не должна обнов- ляться вручную. Это чревато не только тратой дополнительного времени на обновление многочисленных источников, но и неизбежным появлением в них через какое-то вре- мя определенных несоответствий. При необходимости использовать эту информацию в другом контексте или другом конфигурационном файле, следует просто написать сце- нарий, который будет извлекать ее из главного конфигурационного файла (или обнов- лять ее там). Если устранить все избыточные источники не представляется возможным, нужно хотя бы определиться с тем, какой из них будет главным, а также написать про- грамму для перехвата несоответствий и сделать так, чтобы она запускалась регулярно, например, из программы сгоп. Появление таких инструментов, как Wiki, блоги и другие простые системы управле- ния знаниями, намного упростило отслеживание документации по информационным технологиям. Выберите одно место, в котором можно найти и отредактировать все ваши документы. Одну страницу Wiki с 200 дочерними страницами в одном списке очень трудно использовать. Не забудьте включить функцию поиска в вашу систему. Маркировка оборудования Иногда документация оказывается наиболее удобной, когда она написана на бумаге, приклеенной к устройству. Например, в случае отказа всей системы или сети от перечня действий мало толку, если он хранится на сломавшемся или недоступном компьютере. Нужно, чтобы каждый компьютер можно было идентифицировать без включе- ния и прохождения регистрации, потому что эти операции не всегда будут возможны. Промаркируйте все рабочие станции каким-нибудь уникальным образом (например, путем указания имени узла и его IP-адреса) и наклейте на них бумажки с контактной информацией службы поддержки.
Глава 32. Управление, стратегия и политика 1249 В серверном зале все системы и их внешние устройства должны иметь уникальные метки с обеих сторон компьютеров (особенно тех, что установлены в узких стойках), чтобы, при необходимости отключить и снова включить какой-нибудь компьютер, мож- но было быстро отыскать выключатель, отключающий именно его питание. При наличии множества систем разных типов полезно добавить дополнительную ин- формацию, такую как сведения об архитектуре, инструкции по загрузке, специальные последовательности нажатия клавиш, ссылки на дополнительную документацию, теле- фон “горячей линии” производителя или номер телефона человека, который за все это отвечает. Записывание последовательностей нажатия клавиш может показаться немного глупым занятием, но серверы часто подключены к устаревшему терминалу или консоли, а не к специальному монитору. Копию информации со всех наклеек следует обязательно сохранить также и в цен- тральном хранилище записей или инвентаризационных данных. Она пригодится, если вы решите управлять своими компьютерами через TCP/IP-соединение с сервером кон- соли, вместо того чтобы проводить рабочий день в шумном машинном зале. Если в организации есть много специфичных компьютерных данных, необходимо подумать о внедрении системы штрихкодов, которая позволит хранить всю релевантную документацию на ноутбуке. (Разумеется, такая мобильная система сама не должна за- висеть от работы сети или сервера баз данных.) Сетевая документация Сетевая проводка должна быть тщательно документирована. Подпишите все кабели, обозначьте коммутационные панели и сетевые розетки и пометьте сетевые устройства. Всегда делайте так, чтобы электрику было удобно обновлять документацию; повесьте на стенку в коммутационном шкафу ящик с карандашом и формами, для того чтобы он мог всегда быстро записать, что такой-то кабель был отключен от одного устройства и подключен к другому. И не забывайте регулярно переносить эти данные в электронное хранилище. Большинство сетевых устройств (например, маршрутизаторы и коммутаторы) могут быть переконфигурированы по сети. Хотя это и позволяет управлять компьютерами в разных подсетях, не выходя из своего удобного кабинета, документация становится еще более важной. В таком случае следует соблюдать еще большую осторожность, потому что можно быстро и безнадежно испортить гораздо большую часть инфраструктуры. Следует подумать об использовании специального программного обеспечения, такого как Rancid, чтобы отслеживать конфигурации устройств. Эти инструменты могут перехва- тывать случайные и забытые изменения, что поможет резко сократить время простоев. Документация для пользователей Неплохой идеей является подготовка печатного документа, который можно будет вы- давать новым пользователям. В этом документе следует перечислить местные “обычаи”, правила уведомления о проблемах, имена и местонахождение принтеров, расписания резервного копирования и простоев и т.д. Такой документ может сэкономить системным администраторам и пользователям огромное количество времени. Эту информацию так- же следует сделать доступной в сети веб. Печатный документ дает большую уверенность в том, что новые пользователи его все-таки прочитают, зато на веб-страницу удобно ссылаться в случае возникновения вопросов. Поэтому лучше сделать и печатную, и веб- версию документа и не забывать регулярно их обновлять. Ничто не раздражает так, как устаревшие электронная документация или раздел часто задаваемых вопросов (FAQ).
1250 Часть III. Разное Помимо документа с информацией о локальной компьютерной среде, можно так- же подготовить какой-нибудь вводный материал по системе UNIX. Мы предоставляем нашим пользователем одностраничные “шпаргалки”, в которых перечислены наиболее часто используемые в нашей среде команды и приложения. Разделение окружающей среды Организации, которые пишут и развертывают свое собственное программное обеспе- чение, должны разделить разработку, тестирование и производство, чтобы выпуски мог- ли быть организованы с помощью структурированного процесса. Разделяйте окружаю- щую среду, но примите меры, чтобы после обновления системы изменения учитывались в средах для тестирования и производства. Конечно, обновления самой конфигурации должны подвергнуться тому же самому виду структурированного контроля версий, что и код. “Изменения конфигурации” включают все: от заплат операционных систем до при- кладных обновлений и административных изменений. Очень важно защитить вашу производственную среду путем ролевого разделения в рамках процесса продвижения кода. Например, разработчики, имеющие администра- тивные привилегии в среде проектирования, не должны иметь административных прав и привилегий продвижения кода в другой окружающей среде. Раздраженный разработ- чик с правами продвижения кода может специально вставить вредоносный код на ста- дии разработки и затем продвинуть его на этап производства. Если вы распределяете обязанности одобрения и продвижения среди разных людей, то проблемы могут попасть на этап производства, только если много людей тайно сговорятся или сделают ошибки. Зафиксируйте в документах процесс продвижения кода и следуйте ему неукосни- тельно. Не делайте исключений! Если вы находите, что регулярный процесс не доста- точно эффективен для экстренных изменений, опишите в документации этот процесс экстренных изменений и затем удостоверьтесь, что он выполняется. Вы должны также перепроверить процесс продвижения кода и при необходимости внести корректировки. Разработчиков иногда расстраивает уровень документации, который требуется в этом типе системы. Проведите несколько встреч за обеденным столом и помогите им понять побудительные мотивы ваших требований. Разработчики, которые стали вашими единомышленниками, более вероятно, будут следовать стандартным процедурам. Автоматизируйте, автоматизируйте, автоматизируйте! Ваша система управления организацией должна содержать следующие главные эле- менты. • Автоматизированная установка новых компьютеров. Это относится не только к ин- сталляции операционных систем, но и ко всему дополнительному программному обеспечению и локальным конфигурациям, необходимым для того, чтобы вклю- чить компьютер в производственный процесс. Ваш сайт неизбежно должен будет поддерживать несколько типов конфигурации, поэтому следует сразу включить разные типы компьютеров в свои планы. • Систематическое внесение исправлений и обновление существующих машин. Когда вы выявляете проблему со своей установкой, нуждаетесь в стандартизированном й легком способе развертывания обновлений на всех затронутых машинах. Отметьте, что, поскольку компьютеры не включены все время (даже если это предполага- ется), ваша схема обновления должна правильно обращаться с выключенными компьютерами во время инициирования обновлений. Поиск обновлений можно
Глава 32. Управление, стратегия и политика 1251 выполнять на этапе загрузки или по расписанию. Дополнительную информацию можно найти в главе 12. • Система мониторинга. Вашим пользователям не придется звонить вам, чтобы ска- зать, что сервер “упал”. Мало того, что это непрофессионально, но и вы понятия не имеете, надолго ли “упала” система. Вы должны обнаружить проблему еще до того, как вам позвонят первые пострадавшие. Вам нужна определенная система мониторинга, которая поднимет тревогу, как только проблемы станут очевидны- ми. Однако сигнализация — тонкая вещь. Если сигналов слишком много, систем- ные администраторы начинают их игнорировать, а если слишком мало, то важные проблемы остаются незамеченными. • Система связи. Следите за потребностями ваших пользователей; их поддержка яв- ляется конечной целью всего, что вы делаете как системный администратор. Сис- тема отслеживания запросов — это необходимость (см. раздел 32.2). Кроме того, по- лезно организовать централизованное место, где пользователи могут найти инфор- мацию о состоянии системы и контактную информацию (как правило, в сети веб). 32.6. Управление Главной задачей руководства отдела информационных технологий является опреде- ление общей информационной стратегии и управление работой отдела. На плечи менед- жера ложится много обязанностей. • Выполнение роли руководителя группы, определение цели и предоставление не- обходимых ресурсов. • Набор, увольнение, оценка и развитие навыков персонала. • Распределение заданий и контроль за ходом их выполнения. • Проверка и оценка качества работы. • Согласование изменений и дополнений к соглашению о качестве оказываемых услуг. • Взаимодействие с менеджерами в рамках всей организации. • Решение проблем: конфликты между сотрудниками, недовольные пользователи, старое оборудование и т.д. • Выполнение роли “высшей инстанции”, к которой пользователи могут обращать- ся со своими проблемами. • Контроль над разработкой масштабируемой инфраструктуры. • Составление планов на случай аварии и других чрезвычайных обстоятельств. • Извлечение документации из “замороченных” голов системных администраторов. • Разработка и реализация стратегии обеспечения безопасности (как пользователей, так и администраторов). Может показаться, что в этом списке не хватает такой обязанности, как общение с клиентами. Однако мы считаем, что эта роль больше подходит техническому персоналу. Менеджерам обычно не хватает технических знаний для того, чтобы правильно оценить степень сложности и выполнимости требований клиента. Сюрпризов будет меньше для обеих сторон, если в определении сроков доставки и составлении графиков выполнения будут принимать участие именно те, кто и будет этим непосредственно заниматься.
1252 Часть III. Разное Руководство Да, это трудно описать. Но когда оно отсутствует или плохо осуществляется, это сразу же становится заметно. В некотором роде руководство — это “системное адми- нистрирование” организаций: оно тоже подразумевает выбор направления, проверку компонентов “на совместимость” и поддержание всей “системы” в рабочем состоянии с наименьшим возможным количеством “сообщений об ошибках”. К сожалению, технические навыки, позволяющие человеку стать замечательным администратором компьютерных систем, вовсе не означают, что он сможет хорошо справляться с ролью руководителя, которая требует, скорее, умения работать с людьми. Совладать с людьми гораздо сложнее, чем с языком Perl, например. Новым менеджерам с хорошими техническими навыками может быть особенно трудно сфокусироваться на выполнении роли руководителя и избежать соблазна заняться разработ- кой. Намного проще и интереснее погрузиться в решение технической проблемы, чем вести длительные беседы с “проблематичным” сотрудником. Но что важнее для организации? Проще всего определить свой уровень как руководителя так: составить список задач, над которыми сейчас работает организация, одним цветом выделить области, в которых всем руководишь ты, а другим — области, в которых всем руководит кто-то другой, а ты лишь ему подчиняешься, и потом посмотреть, какой цвет преобладает. Управление персоналом Это особенно трудная задача. Выполняя руководящую роль, приходится иметь дело как с техническими, так и с личностными качествами сотрудников. Согласно стереоти- пу, системные администраторы, гениальные с технической точки зрения, как правило, совсем не умеют общаться и порой лучше ладят с машинами, чем с людьми. Менеджер должен следить за кривой роста у сотрудников в обеих этих областях. Стимулировать и оценивать технический рост довольно легко, но личностный рост не менее важен. Ниже приведено несколько важных вопросов, которые следует задавать при оценке “пользовательского интерфейса” сотрудника. • Вписывается ли поведение этого человека в вашу рабочую среду? • Как этот человек общается с начальством, клиентами и поставщиками? • Ладит ли этот человек с другими членами команды? • Имеются ли у этого человека задатки руководителя, которые следовало бы развить? • Как этот человек реагирует на критику и технические споры? • Старается ли этот человек устранить пробелы в своих знаниях? • Каковы коммуникативные навыки этого человека? • Может ли этот человек спланировать, реализовать и продемонстрировать проект клиента? • Чувствует ли этот человек ответственность за выполнение поставленной задачи? • Стремится ли этот человек решать задачи или видит одни препятствия? Набор персонала Оценивать подобным образом следует не только уже работающих сотрудников, но и тех, кто претендует на работу в данной организации. Личностные качества кандидатов часто не учитываются или недооцениваются. Будьте внимательными, чтобы потом не пришлось пожалеть!
Глава 32. Управление, стратегия и политика 1253 Существует два подхода к формированию штата системных администраторов. • Нанимать опытных специалистов. • Растить своих собственных. Опытные специалисты обычно быстрее включаются в работу, но всегда есть что-то, от чего их нужно отучать. Неопытных специалистов, наоборот, придется интенсивно учить. Как бы то ни было, желательно иметь точно сформулированные и зафиксиро- ванные в документе правила и процедуры. Если существующий штат сотрудников имеет ясную цель и понимает ваши правила, они могут сами стать лидерами и помочь аккли- матизироваться новичкам. Некоторые качества хорошего системного администратора противоречат друг другу. Администратор должен быть достаточно дерзким для того, чтобы не бояться принимать неординарные решения при возникновении сложной проблемы, но при этом и доста- точно осторожным для того, чтобы не нанести вред системе. Навыки в межличностных отношениях и решении проблем одинаково важны, хотя, по нашим наблюдениям, у многих администраторов они являются взаимоисключающими. И хотя системные адми- нистраторы не обязаны блестяще владеть навыками коммуникации, некоторым из них удается пройти долгий путь навстречу клиентам. Нанимая системных администраторов, вы должны решить, какие личностные каче- ства являются самыми важными для конкретной роли. Например, если вы нанимаете администратора сервера, который будет сосредоточен на прикладной части и будет ред- ко взаимодействовать с клиентами, то коммуникативные способности менее важны, чем технические навыки. Если же этот человек будет частью многочисленной команды, вы не можете полностью проигнорировать его коммуникабельность. Для того чтобы оценить его техническую подготовку, поставьте перед ним ряд соот- ветствующих технических задач. Вы могли бы даже подбросить ему коварный вопрос, чтобы измерить его интеллектуальный уровень. Мы полагаем, что личная беседа имеет большое значение. За первые 15 минут лич- ной беседы вы узнаете больше, чем в более длинном телефонном разговоре. Мы также верим в рекомендательные письма. Во время проверки рекомендательных писем, мы любим задавать открытые вопросы, которые дают респонденту шанс сделать тонкий намек о соискателе. Слушайте внимательно! Людям вообще не нравится гово- рить отрицательные вещи во время проверки рекомендаций, но вы можете уловить тон- кий намек, если будете внимательны. После интервью с кандидатом у вас могут появиться еще кое-какие вопросы. Например, если в ходе беседы возникнет вопрос о том, обращает ли претендент внима- ние на детали, вы могли бы спросить человека, давшего ему рекомендацию, что-нибудь вроде следующего: “Считаете ли вы претендента человеком, ориентированным на дета- ли, или он любит мыслить крупными категориями?” Увольнение персонала Допустив ошибку при подборе сотрудника, лучше уволить его как можно раньше. Промахи с подбором персонала случаются, но держать на работе людей, не желающих тянуть общую лямку, — значит настраивать против себя других сотрудников, потому что именно им придется взваливать на свои плечи обязанности этих лентяев и подчищать за ними их работу. Клиенты тоже быстро заметят, что кое-кто не делает то, чего от него просят, и начнут требовать, чтобы их задания выполнял какой-нибудь конкретный си-
1254 Часть III. Разное стемный администратор. Мало кому из менеджеров понравится давление со стороны клиентов и их подсказки, кому какое задание следует дать. Во многих организациях сложно уволить сотрудника, особенно по истечении испыта- тельного срока. По этой причине к испытательному сроку следует относиться серьезно. Не исключено, что позже все-таки придется собирать факты, подтверждающие не- компетентность сотрудника, делать ему официальные выговоры, устанавливать рабочие нормы и т.д. Тонкости управления персоналом Ддя интеграции нового сотрудника в вашу инфраструктуру необходимо нечто боль- шее, чем простое письмо с приглашением на работу. Вы должны понимать и соблюдать правила вашей организации относительно размещения объявлений о вакансиях, испы- тательных сроках, собеседовании и т.д. Еще один набор правил должен определять процедуру выделения новому сотруднику стола, компьютера, ключей, учетных записей и доступа sudo. Ваши процедуры долж- ны гарантировать, что найм системным администратором сотрудника для управления конкретным набором серверов не означает карт-бланш на набор администраторов для любой системы, существующей в компании. Не менее важно выполнять процедуры и правила, когда системный администратор покидает компанию. Вы должны составить обходной лист, чтобы гарантировать, что ни- чего не забыли. Ваш обходной лист должен включать следующие пункты. • Удаление доменной учетной записи пользователя (LDAP или Active Directory). • Удаление учетной записи пользователя в системах UNIX и Linux. • Удаление пользователя из всех файлов sudoers вашей организации. • Возвращение ключей и карт доступа (регистрируйте все собранные ключи и карты). • Возвращение сотового телефона компании. Некоторые организации могут напечатать точный список прав доступа и аппаратных средств, выданных каждому служащему. Это отличный способ удостовериться, что вы ничего не забыли. В Соединенных Штатах Америки служащим принято высылать уведомление за две недели до увольнения. Некоторые организации не желают ждать две недели и выстав- ляют сотрудника за дверь, немедленно отменяя любой физический доступ к рабочему месту и в сеть. Это разумно! Тщательное тестирование и контроль качества выполняемой работы Менеджеры задают тон для контроля качества. У каждой задачи должны быть ясные критерии ее выполнения. Кроме действий, характерных для каждой задачи, критерии ее выполнения могли бы включать следующие факторы. • Тестирование решения. • Обновление локальной документации. • Рассылка решения на все задействованные компьютеры. • Выполнение заявки на устранение неисправности с подробным указанием пред- принятых мер. • Просьба лицу, пославшему заявку, поставить отметку о том, насколько он удовлет- ворен.
Глава 32. Управление, стратегия и политика 1255 Даже простая задача, такая как создание расписания cron для выполнения ежеднев- ных административных процедур, должна включать фазу тестирования, чтобы гаранти- ровать, что изменение работает как надо. Более сложные задачи должны иметь утверж- денный план испытаний. В идеале отдел информационных технологий должен внедрить культуру, в которой системные администраторы гарантируют, что каждая работа выполняется качественно и полностью. Однако для этого вам, вероятно, придется установить жесткий контроль; это тот случай, когда можно применить принцип “доверяй, но проверяй”. Управление, а не вмешательство Технически компетентный менеджер может советовать сотрудникам, как они долж- ны выполнять свою работу. Но таким образом он может лишить их шанса приобрести собственные навыки и стать полностью ответственным за их работу. Мы думаем о развитии сотрудника в некотором роде как о его воспитании. Если со- трудник может совершить серьезную ошибку, вызвать проблему, которую трудно устра- нить, попросите, чтобы сотрудник показал свой план действий, и удостоверьтесь, что он понимает вероятные последствия своего плана. В противном случае вы, вероятно, должны будете вмешаться. С другой стороны, если кто-то может сделать ошибку, которая послужит хорошей возможностью для обучения без нанесения серьезного ущерба, то стоит устраниться. Уроки, извлеченные из непосредственного опыта, усваиваются лучше. Конечно, оба варианта не идеальны. Вы не хотите, чтобы вас воспринимали как мелочного менеджера, но вы также не хотите выглядеть руководителем, не желающим ничего знать или позволяющим сотрудникам терпеть неудачу, которой можно было из- бежать. Поддержите своих сотрудников, даже если они совершили ошибки, и помогите им. Никогда не позволяйте ошибкам стать постоянным источником затруднений. Связи с сотрудниками организации Системное администрирование — забавное занятие. Если вы делаете свою рабо- ту хорошо, пользователи считают вашу незаметную вычислительную среду само собой разумеющимся, и никто не замечает то, что вы делаете. Однако в сегодняшнем мире ви- русов, спама, раздутых приложений и тотальной зависимости от Интернета, сотрудники отдела информационных технологий — обязательная часть организации. Ваши удовлетворенные клиенты — ваш лучший маркетинговый индикатор. Однако есть другие способы стать заметным в вашей организации и даже в пределах более ши- рокого сообщества. Основываясь на нашем опыте “саморекламы”, мы предлагаем сле- дующие методы, так как считаем их особенно эффективными. • Проводите общие собрания, на которых пользователи могут формулировать свои проблемы и задавать вопросы о вычислительной инфраструктуре. Проанализируйте просьбы пользователей о помощи, чтобы кратко описать самые неприятные темы, которые вы обнаружили. Обеспечьте закуски, чтобы гарантировать хорошую явку. • Оставьте достаточно много времени для вопросов и удостоверьтесь, что вы имеете хорошо осведомленный штат, чтобы ответить на них. Не пытайтесь блефовать, от- вечая на неожиданные вопросы. Если вы не знаете ответа в данный момент, лучше признаться в этом и отложить решение вопроса. • Запланируйте ряд семинаров, предназначенных для конечных пользователей в ва- шей организации. Проводите их один раз в два-три месяца и заранее оглашайте темы, которые будут на них освещаться.
1256 Часть III. Разное • Посещайте конференции по системному администрированию, делайте доклады или пишите статьи об инструментах, которые вы разрабатываете. Такие презен- тации не только способствуют взаимодействию с вашими коллегами, но и демон- стрируют вашим клиентам (и вашему боссу), что вы делаете свою работу хорошо. Системное администрирование, в конечном счете, сводится к общению с людьми и удовлетворению их потребностей. Личные отношения столь же важны, как и в любом другом деле. Разговаривайте со своими клиентами и коллегами и уделите время личным обсуждениям и обмену мнениями. Если вы поддерживаете работу нескольких групп людей, подумайте о том, чтобы по- ручить определенному сотруднику действовать как менеджер по работе с заказчиками в рамках группы. Этот сотрудник должен взять на себя ответственность за общее удовлет- ворение клиентов и регулярно общаться с конечными пользователями. Канал новостей и передача информации об изменениях в вычислительной среде через посредника по- зволят создать дополнительные возможности для контакта. Манипулирование вышестоящим руководством Для того чтобы эффективно выполнять свои обязанности руководителя (особенно лидера), нужно уважать и поддерживать свое собственное руководство. Нужно уме- ло подбирать штат своих сотрудников и распределять, кто будет принимать решение о приеме и увольнении людей. Нужно контролировать процесс распределения заданий и определить, кто отвечает за их выполнение и назначение новых задач сотрудникам. И, наконец, нужно нести ответственность за представление своей команды как внутри соб- ственной организации, так и вне ее. Вышестоящее руководство часто не имеет ни малейшего представления о том, чем занимаются системные администраторы. Предоставляйте им такую информацию, поль- зуясь возможностями своей системы отслеживания запросов, когда хотите убедить на- чальника в необходимости найма дополнительных сотрудников или приобретении но- вого оборудования. Примите меры, чтобы ваше руководство понимало разницу между службой поддержки и оперативной группой. Они должны понимать, что сотрудник, от- вечающий по телефону службы поддержки, — это не тот специалист, который конфигу- рирует маршрутизаторы и серверы. Это позволит избежать многих недоразумений. Фиксировать информацию о выполняемой системными администраторами работе может быть полезно даже при отсутствии конкретной цели. Руководители, особенно ме- неджеры нетехнического звена, часто недооценивают сложность и трудоемкость стоя- щих перед системными администраторами задач. Особенно это касается задач, связан- ных с поиском и устранением неисправностей. Старайтесь подходить к планированию реалистично. Если не уверены, увеличьте время, которое, на ваш взгляд, необходимо для решения масштабных и очень важных задач. Если обновление системы будет выполнено за два дня, вместо трех, пользователи только поблагодарят вас вместо того, чтобы ругать, как они бы сделали, если бы вы ре- шили, что оно может быть выполнено за один день. Когда наступает время вносить изменения в производственные системы, необходимо строго придерживаться утвержденной процедуры. Она должна предусматривать полу- чение одобрения от комиссии экспертов по изменениям. Участие руководства в рабо- те этой комиссии позволит в будущем уменьшить количество жалоб от пользователей. Пользователи, увидевшие в составе этой комиссии исполнительного директора, при переходе на новую систему электронной почты вряд ли станут настаивать на сохранении старой.
Глава 32. Управление, стратегия и политика 1257 Труднее §сего обычно получить поддержку руководства в вопросах ужесточения стратегии безопасности. Чем жестче правила безопасности, тем больше неудобств ис- пытывают пользователи, а поскольку их больше и ноют они громче, их протесты быстро находят отклик у начальства. Увеличение степени безопасности может снижать продук- тивность пользователей, поэтому прежде чем вносить то или иное изменение в систему защиты, следует проводить анализ степени риска, дабы быть уверенными в том, что ру- ководство и пользователи понимают, почему оно предлагается. Также нужно следить за тем, чтобы пользователи были заранее оповещены обо всех планирующихся изменениях в стратегии безопасности, которые могут повлиять на их работу (например, о переходе с паролей на ключи RSA/DSA для удаленной регистра- ции). Все эти изменения должны быть хорошо документированы и сопровождаться под- держкой во время внедрения. Документация должна быть понятной и содержать поша- говые инструкции по работе с новой системой. При переходе на новую систему лучше выделить дополнительное время на обслуживание пользователей, которые могут начать паниковать из-за того, что не успели прочитать свою электронную почту. Приобретение оборудования Во многих организациях системные администраторы не принимают решения о за- купках. Иногда это оправданно, но при покупке компьютерной техники системные ад- министраторы должны иметь возможность высказывать свое мнение и даже выбирать ту или иную систему. Системные администраторы могут сообщить много полезной информации об имею- щихся в локальной среде требованиях к совместимости, о компетентности поставщиков (особенно сторонних посредников) и надежности определенных типов оборудования. Информация о надежности играет особенно важную роль при покупке системы, от ко- торой зависит работа всей организации. Еще одна важная информация, которую может сообщить системный администра- тор, — воздействие новой системы на информационную безопасность и ее соответствие законодательству. Хороший пример — клиническое отделение больницы, которое зака- зывает новую систему обработки изображений, не консультируясь с группой системного администрирования. К сожалению, в результате оказывается, что новое оборудование не способно взаимодействовать с существующей системой аутентификации, работаю- щей в больнице. Фактически новое оборудование не требует регистрации пользователей вообще! Больница потратила тысячи долларов на систему, которая не соответствует за- кону ШРАА, и теперь она вынуждена покупать новую систему или просить разработчи- ка установить индивидуальную систему аутентификации. Ни одно из этих решений не является удачным. Для больницы было бы лучше, если бы системные администраторы были с самого начала привлечены к решению этой проблемы и могли рекомендовать другого поставщика. Системные администраторы должны уведомляться о предстоящих заказах любого нового оборудования для того, чтобы они могли определить, как его можно будет инте- грировать в текущую инфраструктуру и какие проекты и ресурсы будут необходимы для его поддержки. Несмотря на то что системные администраторы могут давать рекомендации, оконча- тельное решение о приобретении оборудования принимает руководство. Если организа- ция купила нечто, что вам не нравится, вы обязаны с этим смириться — игнорировать системы, которые вам не нравятся, нельзя.
1258 Часть III. Разное Участие системного администратора в разработке спецификаций приобретаемых си- стем особенно важно в тех организациях, где все покупается по минимальным ценам. В большинстве случаев при закупке разрешается указывать критерии оценки. Не стоит забывать включать и такие пункты, как “должна быть совместима с существующей сре- дой” или “должна позволять нормально работать с пакетом программ XYZ”. Показатель воздействия и стоимости дополнительного компонента оборудования (или иногда программного обеспечения) не постоянен. Является ли он шестидесятым в этой архитектуре или первым? Достаточно ли у него места на жестком диске для си- стемных файлов? Хватит ли у него памяти для выполнения современных объемных приложений? Имеется ли свободный сетевой порт, к которому его можно подключить? Установлена ли на нем совершенно новая операционная система? Соответствует ли он текущему законодательству? Как он согласуется с долговременными планами предприя- тия? Одобрили ли его приобретение архитекторы всей системы предприятия? Разрешение конфликтов Некоторые из ложащихся на плечи менеджера обязанностей связаны непосредствен- но с умением ладить с людьми (как правило, клиентами или сотрудниками) в напря- женных ситуациях. Мы сначала рассмотрим, каким должно быть поведение менеджера в целом, а затем поговорим о таком особом случае, как работа с “норовистыми” клиента- ми, которых иногда еще также называют ковбоями. В мире системного администрирования конфликты чаще всего возникают между си- стемными администраторами и их клиентами, коллегами или поставщиками. Например, клиент может быть не доволен качеством предоставленных ему услуг, поставщик мог не предоставить обещанный материал вовремя, коллега мог сделать не то, что его проси- ли, а конструкторский отдел мог требовать полного контроля над установленными на их компьютерах конфигурациями операционной системы. Посредничество Большинство людей не любят говорить о конфликтах или даже признавать, что они существуют. Когда эмоции уже бушуют, это обычно означает, что конфликт распознан слишком поздно и что негатив накапливался на протяжении длительного периода вре- мени. За это время стороны могли уже затаить серьезную обиду и не раз прокрутить в своей голове “подлые” намерения друг друга. Встреча лицом к лицу под контролем нейтрального посредника иногда позволяет разрядить обстановку. Попробуйте ограничить спор одним вопросом, а выделенное на его обсуждение время — одним часом. Такие меры снижают вероятность превращения встречи в бесконечную “схватку”. Цель такой встречи — выработка взаимовыгодного решения. Формальную подготовку в этой области можно получить в разных организа- циях, но мы сформулируем основные принципы. • Дайте каждой стороне шанс выразить свое представление о желаемом результате. Запишите его нейтральным способом на доске, что обе стороны могли его видеть. • Ваша цель как посредника состоит в том, чтобы выявить точки соприкосновения, рассматривая оба варианта желаемых результатов. • Вы не сможете достигнуть соглашения за одну встречу. Но если вы сделаете шаги к обнаружению точек соприкосновения, считайте встречу успехом. • Основывайтесь на любых точках соприкосновения, которые вы выявили на после- дующих встречах. После нескольких встреч вы сможете найти достаточно много точек соприкосновения, чтобы обе стороны были удовлетворены результатом.
Глава 32. Управление, стратегия и политика 1259 Норовистые пользователи и конфликтные отделы Процесс внедрения строго контролируемых систем часто приводит к возникновению конфликтов. Технические пользователи (а иногда и целые отделы) могут посчитать, что централизованное системное администрирование не может адекватно удовлетворять их конфигурационные потребности или что они нуждаются в автономном контроле над ис- пользуемыми ими компьютерами. Первым импульсом менеджера может быть просто взять и заставить этих норовистых пользователей принять стандартную конфигурацию для того, чтобы свести к минимуму затраты и время, требующиеся на их поддержку. Однако такой жесткий подход обычно заканчивается недовольством как среди пользователей, так и среди системных админи- страторов. Не забывайте, что желания норовистых пользователей зачастую бывают впол- не законными и что именно системным администраторам приходится поддерживать их или, по крайней мере, воздерживаться от усложнения им жизни. Лучше всего в такой ситуации поступить следующим образом: выяснить причи- ны, по которым норовистые пользователи не хотят принимать управляемые системы. В большинстве случаев их потребности можно удовлетворить и тем самым поставить их на место. В качестве альтернативного варианта можно согласиться на автономию. Разрешите своим норовистым пользователям или отделам делать все, что им хочется, при усло- вии что они сами будут отвечать за поддержание своих систем в рабочем состоянии. Установите брандмауэр, чтобы защитить контролируемые вами системы от возможного взлома или вирусов со стороны сети этих норовистых пользователей. Обязательно заставьте всех представителей автономной сети подписать соответству- ющий стратегический документ, оговаривающий определенные правила безопасности: например, если их системы начнут мешать работе организации, они будут отключены от общей сети до тех пор, пока на них не будут установлены необходимые заплаты и об- новления и они не перестанут негативно влиять на производственный процесс. Во всех организациях есть так называемые “пользователи-передовики”, которые лю- бят устанавливать все самые последние новинки сразу. Такие пользователи не чураются ни бета-версий, ни нестабильных предварительных выпусков программных продуктов; им главное, чтобы у них было самое новое программное обеспечение. К таким пользова- телям следует научиться относиться как к полезным ресурсам, а не как к “бельму на гла- зу”. Они являются просто идеальными кандидатами для тестирования нового программ- ного обеспечения и зачастую с удовольствием составляют отчеты об обнаруженных в нем дефектах, тем самым предоставляя возможность вовремя устранить проблемы. Творческое системное администрирование также необходимо, чтобы иметь дело с увеличивающимся числом мобильных устройств, принесенных на работу. Вы долж- ны найти способы оказывать услуги и для этих (вообще-то, не вызывающих доверия) устройств, чтобы не подвергать опасности целостность ваших систем. В этой ситуации хорошей идеей могла бы быть отдельная сеть. Другой выбор — запускать ноутбуки через сеть VPN, которая производит “оценку положения”. Оценка положения гарантирует, что ноутбуки придерживаются вашей самой важной политики безопасности. Например, вы могли бы потребовать, чтобы у всех машин, со- единяющихся через сеть VPN, были установлены критически важные заплаты. Для но- утбуков, работающих под управлением операционной системы Windows, вы могли бы также потребовать наличия антивирусного программного обеспечения.
1260 Часть III. Разное 32.7. Инструкции и процедуры Исчерпывающие инструкции и процедуры, касающиеся информационных техноло- гий, служат основой для работы современных организаций. Инструкции устанавливают нормы для пользователей и администраторов и способствуют согласованной работе всех вовлеченных в нее сотрудников. Все больше и больше инструкции требуют подтверж- дения в форме подписи или другого доказательства, что пользователь согласился их со- блюдать. Хотя это может показаться чрезмерным формализмом, но такое подтверждение представляет собой действительно отличный способ защитить администраторов. Хорошим основанием для разработки инструкций является стандарт ISO/IEC 27001. Он сочетает общую стратегию в области информационных технологий с другими важ- ными элементами, такими как информационная безопасность и роль отдела кадров, В следующих разделах мы обсудим стандарт ISO/IEC 27001 и выдвинем на первый план некоторые из его самых важных и полезных элементов. Различие между инструкциями и процедурами Инструкции и процедуры — это разные категории, но их часто путают, и иногда они даже используются как синонимы, что вызывает путаницу. Для того чтобы правильно понимать их сущность, рассмотрим следующие аспекты. • Инструкции — это документы, устанавливающие требования или правила. Тре- бования обычно определяются на относительно высоком уровне. Примером ин- струкции можно считать требование, чтобы добавочное копирование выполнялось ежедневно, а резервное копирование с копиями уровня 0 — каждую неделю. • Процедуры — это документы, описывающие процесс выполнения требований или правил. Так, процедура, связанная с описанной выше инструкцией, могла бы быть сформулирована примерно так: “Добавочное копирование выполняется с помощью программы Backup Ехес, инсталлированной на сервере backupsOl ...” Это различие важно, потому что инструкция не должна изменяться очень часто. ВЫ могли бы пересматривать их ежегодно и, возможно, изменять один или два разделав С другой стороны, процедуры уточняются непрерывно, поскольку постоянно изменяет- ся архитектура, системы и конфигурации. Некоторые стратегические решения диктуются программным обеспечением, которым вы управляете, или инструкциями внешних групп, например интернет-провайдерами: Если необходимо защитить конфиденциальные данные пользователей, то некоторые инструкции носят категорический характер. Мы называем эти инструкции “не подлежа- щими обсуждению”. В частности, мы полагаем, что IP-адресами, именами узлов, идентификаторами пользователей, идентификаторами групп и именами пользователей необходимо управ- лять централизованно. Некоторые организации (транснациональные корпорации, на- пример) являются слишком большими, чтобы осуществить эту политику, но если вы можете реализовать ее, то централизованное управление сделает все намного проще. Мы знаем компанию, которая реализует политику централизованного управления для 35 тысяч пользователей и 100 тысяч компьютеров. Таким образом, порог, после которого организация становится слишком крупной для централизованного управления, должен быть довольно высоким.
Глава 32. Управление, стратегия и политика 1261 Другие важные проблемы имеют более широкую сферу влияния, чем ваша локальная группа системных администраторов. • Борьба со взломами системы безопасности. • Контроль над экспортом файловой системы. • Критерии выбора паролей. • Удаление регистрационных записей. • Материал, защищенный авторским правом (например, MP3 и DVD). • Программное пиратство. Эффективные инструкции Существует несколько стратегических инструкций, охватывающих примерно такую же область. Ниже перечислены примеры инструкций, которые, как правило, включают- ся в стратегический набор инструкций, относящихся к информационным технологиям. • Информационная политика безопасности. • Соглашения о возможности соединения с посторонними организациями. • Политика управления активами. • Информационная система классификации. • Политика безопасности людей. • Физическая политика безопасности. • Политика управления доступом. • Стандарты безопасности для разработки и обслуживания новых систем. • Политика управления инцидентами. • Управление непрерывностью бизнеса (аварийное восстановление). • Политика соответствия установленным требованиям закона. Процедуры Процедуры в форме контрольных списков или рецептов могут формализовать суще- ствующую практику. Они полезны и для новичков, и для опытных системных админи- страторов. Еще лучше процедуры, которые содержат выполняемые сценарии. У стандартных процедур есть несколько преимуществ. • Рутинные операции всегда выполняются единообразно. • Контрольные списки уменьшают вероятность ошибок или забытых операций. • По рецепту системный администратор работает быстрее. • Изменения самодокументируются. • Письменные процедуры обеспечивают измеримый стандарт корректности. Вот некоторые общие задачи, для которых вы могли бы захотеть сформулировать процедуры. • Подключение компьютера. • Добавление пользователя. • Конфигурирование локального компьютера.
1262 Часть III. Разнос • Настройка процедур резервного копирования для нового компьютера. • Защита нового компьютера. • Повторный запуск сложных компонентов программного обеспечения. • Перезагрузка веб-серверов, которые не отвечают на запросы или “зависли”. • Очистка очереди на печать и перезагрузка принтера. • Модернизация операционной системы. • Установка заплат. • Установка пакета прикладных программ. • Установка программного обеспечения по сети. • Обновление наиболее важных программ (sendmail, gcc, named, OpenSSL и т.д.). • Резервное копирование и восстановление файлов. • Уничтожение резервных лент. • Аварийный останов системы (всех компьютеров; кроме самых важных; и т.д.). Такие вопросы следует строго регламентировать, чтобы не стать жертвой известной уловки четырехлетних детей: “Мама не разрешила, надо спросить у папы!” 32.8. Восстановление после аварий Работа организации зависит от функционирования информационной среды. Системный администратор отвечает не только за повседневные операции, но и за на- личие плана действий на случай возникновения различных экстренных ситуаций, по крайней мере тех, которые можно предвидеть. Подготовка к таким масштабным про- блемам влияет как на общий план работы, так и на способ выполнения повседневных операций. Оценка рисков Прежде чем завершить разработку плана восстановления после аварий, целесообраз- но оценить степень риска, чтобы понять, какими активами вы располагаете, каким ри- скам подвергаетесь и как можно смягчить последствия аварии. Специальный документ NIST 800-30 детализирует обширный процесс оценки степени риска. Вы можете загру- зить его с адреса http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf В ходе оценки степени риска необходимо составить список потенциальных угроз, от которых вы хотите защититься. Угрозы не являются одинаковыми, и вам, возможно, по- надобится несколько различных планов, чтобы покрыть полный спектр возможностей. Например, перечислим угрозы общего характера. • Наводнения. • Пожары. • Землетрясения. • Ураганы и торнадо. • Магнитные бури и всплески электропитания. • Перебои в питании, короткие и долгосрочные.
Глава 32. Управление, стратегия и политика 1263 • Чрезвычайно высокая температура или отказ охлаждающего оборудования. • Отказы аппаратных средств (“упавшие” серверы, “сгоревшие” жесткие диски). • Отказы сетевых устройств (маршрутизаторов, выключателей, кабелей). • Злонамеренные пользователи, внешние и внутренние2. • Случайные пользовательские ошибки (удаленные или поврежденные файлы и базы данных, потерянная информация о конфигурации, потерянные пароли и т.д.). Для каждой потенциальной угрозы рассмотрите и запишите все возможные послед- ствия. Как только вы поймете угрозу, расставьте приоритеты служб в пределах своей инфор- мационной среды. Составьте таблицу, в которой перечисляются службы и их приорите- ты. Например, компания, предлагающая “программное обеспечение как службу”, может оценить свой внешний веб-сайт как службу первостепенной важности, в то время как офис с простым, информационным внешним веб-сайтом не мог бы волноваться о судь- бе организации во время бедствия. Борьба со стихийными бедствиями Все больше организаций проектируют свои критические системы так, чтобы автома- тически переключаться на вспомогательные серверы в случае проблем. Это прекрасная идея, если вы не допускаете отключение службы. Однако не становитесь жертвой веры в то, что отражение ваших данных отменяет необходимость в резервном копировании. Даже если ваши информационные центры расположены далеко, вы вполне могли по- терять оба сервера. Не забудьте включить резервное копирование данных в свой план борьбы с бедствиями. £□ Облачные вычисления описаны в разделе 24.1. Облачные вычисления — еще один ресурс для борьбы со стихийными бедствиями, который становится все более популярным. Благодаря таким службам, как ЕС2 компа- нии Amazon, вы можете настроить удаленный сайт и запустить его за несколько минут, без необходимости платить за специализированные аппаратные средства. Вы платите только за то, что используете. Это прекрасная и недорогая альтернатива специализиро- ванному резервному сайту, хотя и требует значительного технического планирования. План восстановления после аварии должен включать следующие разделы (на основе стандарта аварийного восстановления NIST 800-34). • Введение — цель и предмет документа. • Понятие операций — описание системы, цели восстановления, классификация ин- формации, порядок преемственности, обязанности. • Уведомление и активация — процедуры уведомления, процедуры оценки поврежде- ний, активация плана. • Восстановление — последовательность событий и процедур, требуемых для восста- новления потерянных систем. • Возврат к нормальному функционированию — параллельная обработка, воссоздан- ное тестирование системы, возвращение к нормальному функционированию, де- активация плана. 2 По данным 2005 года половина взломов системы безопасности осуществлялась инсайдерами.
1264 Часть III. Разное Мы привыкли использовать сеть для общения и доступа к документам. Однако эти средства могут оказаться недоступными или оказаться под угрозой после инцидента. Сохраняйте автономно все соответствующие контакты и процедуры. Вы должны знать, где можно получить недавние буферные ленты и как использовать их независимо от се- тевых данных. Во всех сценариях бедствий вам понадобится доступ и к автономным, и к интерак- тивным копиям существенной информации. Интерактивные копии по возможности должны быть сохранены на самостоятельном компьютере, на котором есть богатый на- бор инструментов, среды ключевых системных администраторов, управление собствен- ным сервером, полноценный локальный файл /etc/hosts, соединение с принтером и нет никаких зависимостей от обмена файлами и т.д. Не используйте старую рухлядь, это бесполезно; компьютер для хранения информации, необходимой для аварийного вос- становления, должен быть быстродействующим и должен иметь много памяти и дис- кового пространства, которое вы можете использовать для восстановления. Компьютер должен иметь полноценную среду проектирования, чтобы можно было исправить и вторно собрать любое поврежденное программное обеспечение. Хорошо, если у этого компьютера есть интерфейсы для всех типов дисководов, используемых на вашем сайта (IDE, SATA, SCSI, FC-AL и т.д.). Вот список данных для хранения на резервном компьютере в форме печатного бу- клета или оптического диска. • Схема процедуры восстановления: кому звонить, что сказать. • Номера телефонов сервисного центра и клиентов. • Ключевые местные номера телефона: полиция, пожарные, сотрудники, босс. • Запас резервных лент и резервного графика их создания. • Карты сети. • Регистрационные номера программного обеспечения, лицензионные данные и пароли. • Копии инсталляционных пакетов программного обеспечения (могут храниться в формате ISO). • Копия инструкций по эксплуатации ваших систем. • Контактная информация продавца поврежденного диска, в которой вы нуждаетесь. • Административные пароли. • Данные о конфигурациях аппаратного и программного обеспечения: версии опе- рационных систем, заплаты, таблицы разделов, параметры настройки аппаратных средств IRQ, DMA и т.п. • Инструкции по запуску систем, которые должны быть восстановлены в интерак- тивном режиме. Подбор персонала на случай аварии Нужно заблаговременно решить вопрос о том, кто будет справляться с ситуацией в случае, если произойдет авария. Следует составить план действий и написать номера телефонов тех, кому надлежит звонить в такой ситуации. Может оказаться, что на роль главного больше подходит кто-нибудь из системных администраторов, а не начальник отдела информационных технологий (начальники отделов обычно не подходят для этой роли).
Глава 32. Управление, стратегия и политика 1265 Ответственным в случае аварии должен быть кто-то, кто пользуется авторитетом и не боится принимать трудные решения при наличии минимального количества инфор- мации (наподобие решения отключить от сети весь отдел целиком). Способность при- нимать такие решения, уведомлять о них понятным образом и фактически руководить персоналом во время кризиса, пожалуй, важнее теоретических знаний о системном и се- тевом управлении. Мы пользуемся небольшой ламинированной карточкой, на которой мелким шрифтом напечатаны все важные имена и номера телефонов: она очень удобна, потому что легко помещается в бумажник. При составлении плана аварийных мероприятий обычно предполагается, что админи- стративный персонал будет на месте, когда произойдет авария, и сумеет справиться с си- туацией. К сожалению, люди иногда болеют, уходят на курсы повышения квалификации, уезжают в отпуск, а в тяжелые времена вообще могут даже становиться крайне недруже- любными. Поэтому стоит заранее продумать, где можно будет быстро найти дополни- тельную помощь. (Если система не слишком устойчива, а персонал неопытен, то недо- статочное количество администраторов уже само по себе является аварийной ситуацией.) Одним из решений может быть договоренность с какой-нибудь местной консульта- ционной компанией или университетом, где всегда есть талантливые и готовые помочь администраторы. Конечно, если у них когда-нибудь возникнут проблемы, тогда вы тоже должны будете оказать им необходимую помощь. Но самое главное — это не работать на пределе: наймите достаточное количество администраторов и не требуйте, чтобы они работали по 12 часов в сутки. Электропитание и кондиционирование План аварийных мероприятий лучше проверить до того, как он понадобится. Непроверенный план вообще не является планом! Тестировать и обновлять план следует ежегодно. Ш Информацию об источниках бесперебойного питания можно найти в разделе 27.3. Генераторы и источники бесперебойного питания следует проверять раз в месяц или в квартал, в зависимости от того, на какую степень риска готово согласиться руковод- ство. Нужно убедиться в том, что все важные устройства подключены к источнику бес- перебойного питания, их батареи в порядке и механизм включения питания работает. Для того чтобы проверить какой-нибудь отдельный источник бесперебойного питания, нужно просто вынуть вилку из розетки, а чтобы проверить все источники, т.е. все ли важное оборудование к ним подключено, возможно, придется отключить питание во всем здании или в комнате. В любом случае следует обязательно знать обо всех зависи- мостях и слабых местах своей системы электропитания. Источники бесперебойного питания тоже нуждаются в обслуживании. Эта задача может и не входит в обязанности системного администратора, но именно он должен следить за тем, чтобы она выполнялась. Если у вас есть генератор, заключите с местной компанией контракт на поставку топлива. Храните достаточное количество топлива, чтобы обеспечивать свои системы электричеством во время простоя, но помните, что топливо в конце концов портится. Бензин начинает портиться примерно через месяц. Даже если добавить в него стаби- лизатор, бензин не может храниться более года. Дизельное топливо является более хи- мически стабильным, но может способствовать росту водорослей, поэтому в дизельное топливо, которое будет храниться долго, следует добавлять средства, подавляющие рост водорослей.
1266 Часть Ш. Разное Чаще всего электричество отключается ненадолго, но на всякий случай батареи должны обеспечивать два часа работы, чтобы было время правильно выключить техни- ку. Большинство источников бесперебойного питания оборудованы портами USB или интерфейсом Ethernet, которые можно использовать для корректного выключения не являющихся критически важными компьютеров через определенное время после от- ключения питания. Периоды отключения электропитания можно использовать для выполнения лю- бых пятиминутных процедур обновления, которые уже были протестированы, но еще не проводились. Работать все равно невозможно, так что людям будет все равно. В не- которых организациях пользователи спокойнее воспринимают дополнительную пяти- минутную задержку после отключения электричества, чем пятиминутное плановое от- ключение системы, о котором их оповестили за неделю. Если есть старые компьютеры, которыми вроде бы никто уже не пользуется, можно оставить их отключенными до тех пор, пока кто-нибудь не пожалуется на их отсутствие. Иногда отсутствие таких компью- теров остается незамеченным в течение нескольких недель, а иногда о них вообще ни- кто так никогда и не вспоминает. Ш Влияние на окружающую среду рассматривается в главе 28. Системы охлаждения часто оборудованы датчиками температуры со средствами опо- вещения о ее повышении. Задайте такую верхнюю границу температуры, чтобы после сигнала у вас оставалось время выключить технику, прежде чем она перегреется и вый- дет из строя; например, мы пользуемся отметкой в 24 градуса по Цельсию вместо 32, но живем в горах в сорока пяти минутах езды от работы (это летом, а зимой на то, чтобы добраться до места, может уходить и гораздо больше времени). В машинном зале лучше еще держать парочку обычных или работающих от батареи термометров, ведь при от- ключении электропитания все электронные индикаторы станут бесполезными. Если какая-то часть оборудования устанавливается в удаленном месте, попросите от- вечающие за обслуживание этого помещения службы показать резервные средства пи- тания, прежде чем подписывать с ними договор. Удостоверьтесь в том, что генератор находится в рабочем состоянии и проверяется регулярно. Попросите разрешения при- сутствовать при следующей проверке генератора; независимо от того, разрешат вам это или нет, таким путем, скорее всего, удастся получить очень полезную информацию. Сетевая избыточность Интернет-провайдеры часто поглощаются более крупными компаниями в результате слияния. Это сводит на нет их тщательно продуманные планы по поддержанию избы- точных соединений с Интернетом. Поглощаемые интернет-провайдеры часто консоли- дируют электрические цепи, принадлежавшие независимым компаниям. В результате клиенты, у которых раньше были отдельные соединения с Интернетом, после этого мо- гут получать их все по одному-единственному кабелю, но и, соответственно, быть от- ключенными от всех них сразу. Интернет-провайдеры также нередко рекомендуют устанавливать “избыточные це- почки” или “резервные каналы”, преимущества которых являются очень сомнительны- ми. При более тщательном изучении может оказаться, что кабелей действительно два, но они находятся в одной и той же цепи или что по резервному каналу уже передается объемный ATM-трафик. Для уверенности в том, что избыточные каналы оправдывают себя, проводите со своими интернет-провайдерами ежегодную проверку.
Глава 32. Управление, стратегия и политика 1267 Проблемы с безопасностью Об обеспечении безопасности системы подробно рассказывалось в главе 22. Однако здесь тоже стоит коснуться этой темы, потому что вопросы безопасности влияют на многие из выполняемых системным администратором задач. Ни один аспект стратегии управления организации не должен разрабатываться без учета безопасности. В главе 22, по большей части, рассказывалось о способах предотвращения проблем с безопас- ностью. Однако продумывание способов восстановления системы после происшедшего из-за связанных с безопасностью проблем инцидента является не менее важным. Кража данных с веб-сайта относится к числу наиболее серьезных нарушений систе- мы безопасности. Для системного администратора, работающего в компании, которая занимается предоставлением услуг веб-хостинга, такой инцидент может превратиться в настоящую катастрофу, особенно если речь идет о сайтах, использующих данные о кре- дитных карточках пользователей. Поступает поток телефонных звонков от клиентов, от средств массовой информации, от VIP-клиентов компании, которые только что услыша- ли о происшедшей краже в новостях. Кто будет отвечать на эти звонки? Что он должен говорить? Кто будет главным? Кто что будет делать? Тем системным администраторам, которые работают в очень популярных компаниях, обязательно следует продумать такой сценарий, подготовить подходящие ответы и план действий и, возможно, даже провести тренировочную проверку, чтобы отработать детали. Для сайтов, которые имеют дело с данными о кредитных карточках, всегда предусма- триваются правила поведения в случае атаки с целью кражи информации. Поэтому си- стемный администратор обязательно должен привлечь к планированию мероприятий на случай проблем с безопасностью сотрудников юридического отдела своей организации и позаботиться о наличии номеров телефонов и имен людей, которым следует звонить во время кризиса. Когда в новостях объявляют, что такой-то веб-сайт был атакован хакерами, возника- ет ситуация, напоминающая аварию на дороге: все бросаются посмотреть, что же про- изошло, и в результате интернет-трафик сильно возрастает, нередко настолько сильно, что все, что администраторам наконец-то с таким трудом удалось исправить, снова мо- жет оказаться под угрозой. Поэтому, если веб-сайт не рассчитан на 25-процентное (или более высокое) увеличение трафика, следует позаботиться о наличии программ вырав- нивания нагрузки, которые будут просто направлять превышающие норму вызовы на сервер, а тот будет возвращать страницу со следующим сообщением: “Извините, сервер слишком загружен и поэтому в данный момент не может обработать ваш запрос”. 32.9. Соответствие законам и стандартам IT-аудит и управление в настоящее время являются очень популярными. Инструкции и квазистандарты для спецификации, измерений и сертификации соответствия законам породили множество аббревиатур: SOX, ITIL, COBIT и ISO 27002, и это только некото- рые из них. К сожалению, эта мешанина букв оставляет у системных администраторов неприятный осадок, поэтому сейчас ощущается недостаток программного обеспечения, предназначенного для реализации всех средств управления, необходимых для обеспече- ния соответствия с действующим законодательством. Некоторые из основных рекомендательных стандартов, руководящих принципов, промышленных концепций и законодательных требований, которые могут касаться си- стемных администраторов, перечислены ниже. Законодательные требования являются в
1268 Часть III. Разное значительной степени специфичными для Соединенных Штатов Америки. Однако эти стандарты действительно содержат полезную информацию даже для организаций, ко- торые не обязаны их придерживаться. Некоторые из них стоит знать только для того, чтобы овладеть передовым опытом. (Стандарты перечислены в алфавитном порядке.) • CJIS (Информационные системы уголовного судопроизводства) —стандарт, относя- щийся к организациям, которые отслеживают криминальную информацию и ин- тегрируют ее с базами данных ФБР. Его требования могут быть найдены на стра- нице fbi.gov/hq/cjisd/cjis.htm. • СОВГГ — рекомендации для информационного управления, основанного на пере- довом промышленном опыте. Они разработаны совместно Ассоциацией аудита и управления информационными системами (Systems Audit and Control Association — ISACA) и Институтом информационного управления (IT Governance Instutute — ITGI); см. детали на сайте isaca.org. Задача рекомендаций COBIT состоит в том, чтобы “исследовать, развивать, предавать гласности и продвигать авторитет- ный, современный, международный набор общепринятых целей управления ин- формационными технологиями для ежедневного использования менеджерами и аудиторами.” Первая редакция этих рекомендаций была выпущена в 1996 году, сейчас действует версия 4.0, изданная в 2005 году. Последняя версия разрабатывалась под сильный влиянием требований закона Сарбейнза—Оксли (Sarbanes-Oxley). Она включает 34 цели высокого уровня, которые охватывают 215 “целей управления”, классифи- цированных по четырем областям: планирование и организация, приобретение и реализация, поставка и поддержка, мониторинг и оценка. • СОРРА (Children’s Online Privacy Protection Act — Закон о защите конфиденциаль- ной информации о детях в Интернете); регулирует работу организаций, который6 собирают или хранят информацию о детях, не достигших 13 лет. Для сбора опре- деленной информации необходимо разрешение родителей; см. детали на сайте сорра.org. • FERPA (Family Educational Rights and Privacy Act — Закон о правах семьи на обра- зование и неприкосновенность частной жизни); относится ко всем учреждениям, являющимся получателями федеральной помощи, которой управляет министер- ство образования. Этот закон защищает информацию о студентах и предостав- ляет студентам определенные права относительно их данных; см. детали на сайте ed.gov/policy/gen/guid/fpco/ferpa/index.html. • FISMA (Federal Information Security Management Act — Закон об управлении ин- формационной безопасностью в федеральном правительстве); относится ко всем правительственным учреждениям и подрядчикам правительственных учреждений. Это большой и довольно неопределенный набор требований, которые нацелены на согласование со множеством публикаций об информационной безопасности, выпущенных институтом NIST, Национальным институтом по стандартизации и технологии (National Institute of Standards and Technology). Независимо от того, подпадает ли ваша организация под мандат FISMA или нет, документы NIST за- служивают внимания; см. csrc.nist.gov/publications/PubsTC.html. • Концепция Safe Harbor (правило безопасной гавани) Федеральной комиссии по тор- говле США (FTC) представляет собой мост между подходами США и Европейского Союза к законодательству, защищающему частную жизнь, и определяет способ, с
Глава 32. Управление, стратегия и политика 1269 помощью которого американские организации могут взаимодействовать с евро- пейскими компаниями, чтобы продемонстрировать защиту своей информации; см. export.gov/safeharbor/eg_main_018236.asp. • Закон П)эма-Лич-Блайли (Gramm-Leach-Bliley Act — GLBA) регулирует исполь- зование финансовыми учреждениями конфиденциальной информации потре- бителей. Если вы задавались вопросом, почему банки, выпускающие кредитные карточки, брокеры и страховщики забрасывали вас уведомлениями о конфиден- циальности, то это следствие закона Грэма—Лич—Блайли; см. ftc.gov/privacy/ privacyinitiatives/glbact.html. • Закон ШРАА (Health Insurance Portability and Accountability Act — Закон об отчет- ности и безопасности медицинского страхования) относится к организациям, ко- торые передают или хранят защищенную медицинскую информацию (иначе PHI). Это широкий стандарт, который был первоначально предназначен для борьбы с растратами, мошенничеством и злоупотреблениями в области здравоохранения и медицинского страхования, но теперь он используется для того, чтобы измерить качество и улучшить безопасность информации о здоровье; см. hhs.gov/ocr/ privacy/index.html. • ISO 27001 и ISO 27002 — это рекомендательная (и информативная) коллекция передового опыта, связанного с безопасностью организаций, использующих ин- формационные технологии; см. iso. org. • Библиотека ITIL (IT Insfrustructure Library) — коллекция руководств, первоначаль- но разработанных британским правительством, которые обрисовывают в общих чертах структуру управления информационными услугами. Это всего лишь реко- мендации, но они широко используются; см. сайт itil.org и раздел, помещен- ный далее. • CIP (Critical Infrastructure Protection) — семейство стандартов, разработанных кор- порацией North American Electric Reliability Corporation (NERC), которые способ- ствуют защите инфраструктурных систем, таких как электроснабжение, телефон- ные линии и финансовые сети, от стихийных бедствий и терроризма. В полном соответствии с учебной иллюстрацией ницшеанского понятия “жажды власти” оказывается, что большая часть экономики попадает в один из 17 секторов “критических инфраструктур и ключевых ресурсов” (CI/KR) и поэтому очень нуж- дается в стандартах CIP. Организации, попадающие в эти сектора, должны оценить свои системы и защищать их соответствующим образом; см. cip. gmu. edu/cip. • Стандарт PCI DSS (Payment Card Industry data Security Standard — Стандарт защи- ты информации в индустрии платежных карточек) был создан консорциумом пла- тежных брендов, включая American Express, Discover, MasterCard и Visa. Он охва- тывает вопросы управления данными о платежной карточке и относится к любой организации, которая принимает платежи по кредитной карточке. Стандарт имеет два варианта: самооценку для небольших организаций и внешний аудит для орга- низаций, которые обрабатывают много сделок; см. pci securitystandards. org. • Правила Red Flags Rules Федеральной Комиссии по торговле США требуют, чтобы любой, кто расширяет кредит на потребителей (т.е. любая организация, которая отсылает счета), осуществлял формальную программу, предотвращающую и обна- руживающую “хищение персональных данных”. Правила требуют, чтобы эмитен- ты кредитов разработали эвристические правила для того, чтобы идентифициро-
1270 Часть III. Разное вать подозрительные манипуляции со счетами. Для выяснения деталей наберите фразу “red flag” в поисковой строке на сайте f tc. gov. • Раздел IT General Controls (ITGC) в законе Сарбейнза-Оксли (SOX), последний по расположению, но не по важности, относится ко всем акционерным обществам и разработан, чтобы защитить акционеров от бухгалтерских ошибок и мошенниче- ских методов; см. sec. gov/rules/final/33-812 4 . htm. Библиотека ITIL: Information Technology Infrastructure Library Среди этих стандартов библиотека Information Technology Infrastructure Library (ITIL) стала фактическим стандартом для организаций, ищущих полноценное решение для управления информационными услугами. Процессы ITIL разделены на шесть групп. • Служба поддержки - информационные услуги для клиентов, а также прием запро- сов и сообщений о проблемах; также включает условия для отслеживания и эска- лации проблем. • Управление инцидентами — восстановление обслуживания после инцидента, вы- звавшего сбой. • Управление проблемами — идентифицирует причины инцидентов, чтобы предот- вратить будущие сбои. • Управление конфигурацией — инкапсулирует информацию о компонентах инфра- структуры и их взаимозависимостях. • Управление изменениями — процессы управления изменениями в пределах инфра- структуры. • Управление выпусками — процесс, аналогичный процессу управления изменения- ми, но используемый для крупномасштабных изменений в пределах организации. У крупных организаций может быть формальная программа ITIL, дополненная си- стемой отслеживания запросов, которая точно отражает концепции ITIL и ее опреде- ления. Однако даже небольшая организация, использующая общедоступную систему отслеживания запросов, может принять политику, которая поощряет внимательное управление изменениями. Все изменения должны сопровождаться подачей заявки на изменение, одобрения комитета по изменениям и отслеживаться с помощью диагно- стической системы. Все инциденты должны обрабатываться в соответствии с установ- ленным процессом реагирования, который включает анализ состояния после устра- нения последствий инцидента, чтобы определить, была ли проблема решена самым лучшим способом. В общем, следует интерпретировать рекомендации в свете определенных потреб- ностей вашей организации. Главная цель состоит в том, чтобы понять концепции, во- площенные в стандартах, и принять их философию. Некоторые из упомянутых выше стандартов состоят из сотен страниц, поэтому их даже трудно просто прочитать; не стес- няйтесь резюме и сжатых версий. NIST: Национальный Институт стандартов и технологии Институт NIST издает множество стандартов, полезных для администраторов и тех- нологов. Некоторые из популярных стандартов упомянуты ниже, но если вам скучно и вы ищете стандарты, можете зайти на его веб-сайт. Вы не будете разочарованы.
Глава 32. Управление, стратегия и политика 1271 Стандарт NIST 800-53 (Рекомендуемые средства управления системами безопас- ности для федеральных информационных систем и организаций) описывает, как оце- нить безопасность информационных систем. Если ваша организация разработала вну- треннее приложение, которое хранит конфиденциальную информацию, этот стандарт может помочь вам удостовериться, что вы действительно защитили ее. Однако осте- регайтесь: процедура согласования со стандартом NIST 800-53 не для слабонервных. Вы, вероятно, столкнетесь с документом объемом около 100 страниц со множеством мучительных деталей.3 Стандарт NIST 800-34 (Принципы планирования на случай непредвиденных ситуа- ций для информационных систем) является библией аварийного восстановления, разра- ботанной организацией NIST. Он предназначен для правительственных учреждений, но любая организация может извлечь из него выгоду. Следование стандарту планирования NIST 800-34 требует времени, но это вынуждает вас ответить на такие важные вопросы, как: “Какие системы являются самыми важными?”, “Сколько времени мы можем обой- тись без этих систем?” и “Как мы собираемся восстанавливаться, если наш основной информационный центр потерян?” 32.10. Правовые вопросы Правительство США и некоторые штаты издали законы о преступлениях в области вычислительной техники. На федеральном уровне с начала 1990-х годов существовало два закона, а теперь их четыре. • Федеральный Закон о конфиденциальности связи. • Закон о компьютерном мошенничестве и компьютерных злоупотреблениях. • Закон о компьютерных кражах. • Закон об авторских правах “Digital Millenium Copyright Act”. Основными правовыми проблемами в настоящее время являются ответственность системных администраторов, сетевых операторов и провайдеров, предоставляющих услуги веб-хостинга; сети для обмена файлами между пользователями, защита авторских прав и конфиденциальность. В разделе рассматриваются эти и другие юридические во- просы, связанные с системным администрированием. Конфиденциальность Частную жизнь всегда было трудно скрыть, но с развитием Интернета она подвер- гается еще большей опасности, чем когда-либо. Медицинская документация неодно- кратно раскрывалась с помощью плохо защищенных систем, украденных ноутбуков и резервных магнитных лент, которые находились не в положенном месте. Базы данных, номера кредитных карточек всегда подвергались нападениям. Веб-сайты, предлагающие антивирусное программное обеспечение, фактически сами устанавливают программы- шпионы. Поддельная электронная почта поступает почти ежедневно в виде фиктивных писем от вашего банка, в которых утверждается, что у вас возникли проблемы с вашим счетом и требуется, чтобы вы проверили свои учетные данные. Обычно тщательное из- учение электронной почты показывает, что эти данные попали бы к хакеру в Восточной Европе или Азии, а не в ваш банк. Этот тип нападения называют фишингом. 3 Если вы планируете сотрудничество с правительственными учреждениями США, от вас могут потребовать соответствия стандарту NIST 800-53, хотите вы этого или нет...
1272 Часть III. Разное Технические меры никогда не смогут защитить от этих нападений, потому что они нацелены на самый уязвимый компонент — ваших пользователей. Ваша лучшая защи- та — образованные пользователи. Никакая легальная служба электронной почты или веб-сайт никогда не будут сообщать о следующем: • что вы выиграли приз; • чтобы вы “проверили” информацию о счете или пароли; • чтобы вы отправили часть электронной почты; • чтобы вы установили программное обеспечение, которое вы не искали; • о вирусе или другой проблеме безопасности. Пользователи, осведомленные о таких опасностях, с большей вероятностью сделают правильный выбор, когда всплывающее окно будет утверждать, что они выиграли бес- платный MacBook. Реализация стратегии Файлы системного журнала могут легко доказать вам, что человек X сделал плохо че- ловеку Y, но для суда это всего лишь слова. Защитите себя письменными предписания- ми. Файлы системного журнала иногда содержат метки времени, которые полезны, но не обязательно допустимы как доказательства, если ваш компьютер не управляет протоко- лом NTP (Network Time Protocol), чтобы синхронизировать свои часы со стандартными. Вам, возможно, понадобится инструкция по безопасности, чтобы преследо- вать кого-то по суду за неправильный поступок. Она должна содержать утверждение: “Несанкционированное использование вычислительных систем может повлечь не толь- ко нарушение организационной политики, но и нарушение законов штата и федераль- ных законов. Несанкционированное использование — это преступление, которое может повлечь уголовное наказание и гражданско-правовые санкции; оно будет преследовать- ся по суду в полном объеме закона.” Мы советуем показывать заставку, которая сообщает пользователям о ваших прави- лах слежения. Вы могли бы написать что-то вроде следующего: “Действие может отсле- живаться в случае реального или подозреваемого нарушения правил безопасности”. Вы можете гарантировать, что пользователи видят уведомление, по крайней мере, один раз включив его в файлы запуска, которые вы предоставляете новым пользова- телям. Если вы требуете, чтобы использование протокола SSH регистрировалось (а вы должны это требовать), можете сформировать файл /etc/ssh/sshd_config так, чтобы протокол SSH всегда показывал заставку. Убедитесь, что, пользуясь своими учетными записями, пользователи признают вашу письменную инструкцию. Объясните, где пользователи могут получить дополнительные копии стратегических документов и куда отправлять ключевые документы о соответству- ющей веб-странице. Также включайте определенный штраф за несоблюдение правил (удаление учетной записи и т.д.). Более важно, чтобы вы добросовестно уведомили поль- зователей об их обязанностях, а не просто составили юридически точное уведомление. Кроме заставки, целесообразно сделать так, чтобы пользователи подписали страте- гическое соглашение, прежде чем получить доступ к вашим системам. Это приемлемое пользовательское соглашение должно быть разработано в сотрудничестве с вашим юри- дическим отделом. Если у вас нет подписанных соглашений со служащими, соберите их. Сделайте подписание соглашения стандартной частью процесса приема на работу новых сотрудников.
Глава 32. Управление, стратегия и политика 1273 Вы могли бы также периодически проводить семинары по вопросам безопасности. Это удобная возможность рассказать пользователям о важных проблемах, таких как фи- шинг, научить их правильно устанавливать программное обеспечение и пароли, а также кое-чему другому, что относится к вашей компетенции. Контроль — это ответственность Поставщики интернет-услуг обычно следуют правилам пользования сетью (appropriate use policy — AUP), которые диктуют стоящие над ними поставщики и ко- торые являются обязательными для их клиентов. Таким образом, вся ответственность за действия клиентов ложится на самих клиентов, а не на провайдеров. Целью такой стратегии является защита провайдеров от ответственности за рассылку спама и прочие незаконные действия, например хранение пользователями на своих узлах незаконно- го или защищенного авторскими правами материала. В каждом штате и каждой стране имеются свои законы на этот счет. Ваши правила должны явно запрещать пользователям использовать ресурсы ком- пании для незаконной деятельности. Однако на самом деле этого недостаточно — вы также должны дисциплинировать пользователей, обнаружив, что они осуществляют не- законные действия. Организации, которые знают о незаконных действиях, но не при- нимают меры для их пресечения, считаются соучастниками и могут преследоваться по закону. Нет ничего хуже несоблюдаемых или противоречащих друг другу правил, как с практической, так и юридической точки зрения. Из-за риска стать соучастником незаконных действий пользователя, некоторые ор- ганизации ограничивают данные, которые они регистрируют, отрезок времени, в тече- ние которого сохраняются файлы системного журнала, и объем информации о файлах системного журнала, хранящейся на резервных лентах. Некоторые пакеты программ помогают выполнять эти правила, устанавливая уровни регистрации. Это помогает си- стемным администраторам устранять проблемы, не вторгаясь в частную жизнь пользо- вателей. Тем не менее всегда следует знать, какой вид регистрации требуется по местным законам или по любым регулирующим стандартам, которые распространяются на вашу организацию. Лицензии на программное обеспечение Многие компании оплачивают меньшее количество копий программ, чем использу- ют на самом деле. Если об этом становится известно, компания теряет гораздо больше, чем сэкономила на приобретении недостающего числа лицензий. Другие компании по- лучают демоверсию дорогого пакета и взламывают ее (меняют дату на компьютере, опре- деляют лицензионный ключ и так далее), чтобы пакет продолжал работать по истечении демонстрационного срока. Как системный администратор должен реагировать на пред- ложения нарушить лицензионное соглашение и установить нелицензионные копии про- граммы на дополнительные компьютеры? Что он должен делать, если обнаруживается, что на обслуживаемых им компьютерах работает пиратское программное обеспечение? И как быть с условно-бесплатными программами, за которые так никогда и не заплатили? Это очень сложный вопрос. К сожалению, начальство не всегда поддерживает адми- нистратора, предлагающего удалить нелицензионные копии программ либо оплатить их. А ведь часто именно системный администратор подписывает лицензионное соглашение, требующее удалить демонстрационные копии после определенной даты, тогда как реше- ние их не удалять принимает руководитель.
1274 Часть III. Разное Нам известно несколько случаев, когда непосредственный начальник системного ад- министратора предлагал ему “не раскачивать лодку”. Тогда администраторы написали докладную вышестоящему руководству, в которой указали количество лицензированных и используемых копий, а также процитировали лицензионное соглашение. В одном слу- чае подход сработал, и уволен был непосредственный начальник системного админи- стратора. Во втором случае уволиться пришлось системному администратору, потому что даже вышестоящее руководство отказалось действовать по закону. Чтобы вы ни делали в такой ситуации, обязательно делайте это в письменном виде. Требуйте, чтобы ответы предоставлялись в письменном виде, а если не получится, документируйте полученные инструкции в виде коротких служебных записок и отправляйте их ответственному лицу. 32.11. Организации, конференции и другие ресурсы Многие группы поддержки систем UNIX и Linux — и общего характера, и кон- кретных поставщиков — помогают устанавливать контакты с другими людьми, ис- пользующими то же программное обеспечение. В табл. 32.3 приведен короткий список организаций, но большинство национальных и региональных групп в этой таблице не упомянуто. Организация FSF (Free Software Foundation — Фонд бесплатного программного обе- спечения) является спонсором проекта GNU (GNU — аббревиатура от “GNU is Not Unix”; так называется проект по свободному распространению программного обеспече- ния). Под словосочетанием “бесплатное программное обеспечение” в названии этой ор- ганизации подразумевается программное обеспечение, которое не имеет почти никаких ограничений в использовании, а не бесплатное программное обеспечение. Также орга- низация FSF является автором лицензии GPL, которая распространяется на большую часть систем UNIX и Linux. Организация USENIX, представляющая собой союз пользователей Linux, UNIX и других операционных систем с открытым исходным кодом, каждый год проводит одну общую конференцию и несколько специализированных (небольших). На общей конфе- ренции обычно речь идет об открытых системах и новых разработках, которые прово- дятся в рамках Linux и BSD. Таблица 32.3. Организации, ориентированные на системных администраторов систем UNIX ; и Linux Название URL / ОММММК- - ? * - - ’’ •’ FSF fsf.org Free Software Foundation, спонсор GNU USENIX usenix.org Группа пользователей UNIX, обсуждающих технические вопросы SAGE sage.org Гильдия System Administrators Guild, ассоциированная с органи- зацией USENIX; проводит ежегодные конференции USA LOPSA lopsa.org League of Professional System Administrators — лига профессио- нальных системных администраторов, “отколовшаяся” от органи- зации USENIX/SAGE SANS sans.org Проводит конференции по системному администрированию и безопасности; обсуждает менее технические вопросы по сравне- нию с гильдией SAGE, делая упор на обучении The Linux Foundation linuxfoundation.org Некоммерческий консорциум, ориентированный на стимулирова- ние роста системы Unux
Глава 32. Управление, стратегия и политика 1275 Окончание табл. 32.3 Название tWML AUUG auug.org.au SAGE-AU sage-au.org.au SANE sane.nl Australian UNIX Users Group; охватывает технические и управлен- ческие аспекты вычислений Australian SAGE; проводит ежегодные конференции в Австралии Группа System Administration and Network Engineering; проводит ежегодные конференции в Европе Важным событием для системных администраторов является конференция LISA (Large Installation System Administration — системное администрирование в крупных ор- ганизациях), которая проводится поздней осенью. Помимо всех этих конференций, ча- сто проводятся соответствующие торговые выставки. Кроме того, в течение нескольких последних лет организация USENIX специально для сообщества Linux проводит отдельную конференцию по вопросам разработки ядра Linux. Попасть на это двухдневное мероприятие можно только по приглашению. SAGE (USENIX System Administration Guild — гильдия системных администраторов USENIX) является первой международной организацией для системных администрато- ров. Она рекламирует системное администрирование как профессию путем финанси- рования различных конференций и неофициальных программ. Подробнее о ней можно узнать на сайте www. sage. org. Гильдия SAGE совместно со своей головной организацией USENIX проводит конфе- ренции, посвященные управлению системами и сетями, учебные и технические семина- ры, лекции и презентации. Иногда она также проводит однодневные рабочие семинары, посвященные специальным темам. См. информацию на сайте usenix. org. Бюллетень организаций USENIX и SAGE — ;login: — выпускается обеими организа- циями; он содержит административные новости, советы, обзоры и объявления, пред- ставляющие интерес для системных администраторов. Гильдия SAGE поддерживает список ресурсов для системных администраторов. Свежую информацию можно найти на сайте sage.org. В 2005 году раскол организаций USENIX и SAGE поставил будущее гильдии SAGE под сомнение. В результате этого раскола появилась новая отдельная организация под названием LOPS A (League of Professional System Administrators — Лига профессиональ- ных системных администраторов), основанная бывшими сотрудниками организации SAGE. До начала 2010 года организация LOPSA еще не проводила никаких конферен- ций. У SAGE была программа по сертификации системных администраторов, но она от нее отказалась; будем надеяться, что LOPSA вернется к ней. Институт SANS проводит много курсов обучения и семинаров по вопросам безо- пасности и поддерживает программу по сертификации. Экзамен проводится в течение ограниченного времени в форме многовариантного теста, вопросы которого известны заранее. Прежде чем сдать реальный экзамен, испытуемые могут попробовать сдать два тренировочных экзамена. Индивидуальные сертификаты относятся к узкоспециализи- рованным вопросам; соискатели могут также получить общий сертификат по безопас- ности (GSEC). Сертификат действует только 2-3 года, поэтому вы должны следить за новинками и повторно проходить сертификацию (за дополнительную плату). Детали см. на сайте giac.org. Существует множество групп пользователей UNIX, Linux и других открытых систем. Некоторые из них связаны с организацией USENIX, а другие нет. Локальные группы обычно проводят регулярные встречи и рабочие семинары с местными или приезжими
1276 Часть III. Разное лекторами и часто организовывают банкеты до или после мероприятия. Это хороший способ поддерживать контакты с системными администраторами в своем регионе. Главной торговой выставкой в сфере сетевой индустрии является выставка Interop. Проводимые в ее рамках обучающие семинары известны своим высоким качеством. Когда-то выставка Interop проходила только раз в год; этого события с нетерпением ждали как технические специалисты, так и производители. Сейчас она проводится не- сколько раз в год, можно сказать, представляя собой “бродячий цирк сетевых техноло- гий”. Зарплата преподавателей семинаров сократилась вполовину, но качество семина- ров вроде бы от этого не пострадало. 32.12. Рекомендуемая литература • Limoncelli Т.Д. Time management for system administrators. Sebastopol, CA: O’reilly Media, 2005. • Machiavelli Niccolo. The prince. 1513. Available on-line from gutenberg.org/ etext/1232. • Brooks F.P., Jr. The mythical man-month: essays on software engineering. Reading, MA: Addison-Wesley, 1995. • Senft S., Gallegos G. Information technology control and audit (3rd edition). Boca Raton, FL: Auerbach Publications, 2008. • Сайт itil-toolkit. com удобен для начала поисков, если вы хотите овладеть тер- минологией и жаргоном, связанными с процессами и стандартами ITIL. • Сайт itl.nist.gov — домашняя страница организации NIST Information Technology Laboratory. Она содержит много информации о стандартах. Зайдите на страницы с публикациями. • Веб-сайт организации Electronic Frontier Foundation, eff.org, — прекрасное ме- сто для поиска комментариев, касающихся новейших достижений в области за- щиты конфиденциальности, криптографии и законодательства. Эти материалы всегда интересны. • Страница sans. org/resources/policies содержит проект инструкции SANS о безопасности. На этом сайте можно найти хорошие примеры инструкций по ин- формационным технологиям. • Большое количество отличных ресурсов для системных администраторов можно найти на сайте гильдии SAGE: sage. org/field/field.html. 32.1 3. УПРАЖНЕНИЯ 32.1. Назовите повторяющиеся процедуры, выполняемые в вашей организации? Какие из них повторяются редко и каждый раз изменяются? Какие из них связаны с ри- ском? 32.2. Как вы зависите от внешних поставщиков? Нуждаетесь ли вы в плане Б и есть ли он у вас? Объясните, почему. Опишите план Б, если он существует. 32.3. Проведите краткие интервью с несколькими внутренними клиентами, чтобы опре- делить их ожидания относительно доступности вычислительной инфраструктуры.
Глава 32. Управление, стратегия и политика 1277 Согласованы ли эти ожидания? Действительно ли они разумны? Действительно ли они совместимы с установленными целями группы системного администрирования? 32.4. Какая организованная инфраструктура для системного управления уже установле- на в вашей организации? Идентифицируйте части, которые все еще отсутствуют. 32.5. Один из ваших сотрудников собирается уехать завтра в обед и никогда возвра- щаться, но вы еще не знаете кто. (Нет, не пытайтесь угадать.) На какие критиче- ские процедуры это могло бы повлиять и насколько готова ваша организация вос- полнить недостаток сотрудника? Какая документация могла бы помочь избежать разрушения службы? 32.6. Что произошло бы, если бы вы не ходили на работу в течение следующих трех ме- сяцев? Насколько ваши коллеги ненавидели бы вас, когда вы наконец вернулись, и почему? Что вы можете сделать за следующие две недели, чтобы уменьшить ущерб от своего отсутствия? 32.7. ★ Босс приказывает вам сократить бюджетные ассигнования на системное адми- нистрирование на 30% до конца текущего года. Вы можете оценить последствия этого сокращения? Представьте резюме, которое позволит боссу принять обосно- ванное решение относительно того, какие службы сократить или ликвидировать. 32.8. ★ Кто в вашей корпорации поддерживает систему Linux? Каковы их интересы и побуждения? Какие вклады они делают? 32.9. ★ Вы наводите порядок после сбоя диска и замечаете файлы в каталоге lost+found. Проводя дальнейшее расследование, вы обнаруживаете, что некоторые файлы пре- дставляют собой почтовые сообщения, которые послали друг другу два студента, настраивающие черный ход вокруг брандмауэра отдела, чтобы заархивировать фай- лы MP3 на отдаленном файловом сервере. Что вы должны сделать? Есть ли пра- вила или инструкции в вашей организации, которые касаются таких инцидентов? 32.10. ★★ Оцените локальную документацию вашей организации, предназначенную для новых пользователей, системных администраторов, стандартных процедур и чрез- вычайных ситуаций. 32.11. ★★ Опишите будущее различных коммерческих и свободных вариантов UNIX и разновидностей Linux на следующие пять лет. Как будут развиваться текущие мо- дели разработки и распределения в течение долгого времени? Каковы будут долго- срочные последствия принятия системы Linux продавцами аппаратных средств? Проведите различие между рынками серверов и настольных систем.
Краткая история системного администрирования Из записок доктора Питера Салуса (Peter Н. Salus), историка, занимающегося вопро- сами развития технологий В современную эпоху большинство людей имеют хотя бы минимальное представ- ление о задачах, решаемых системными администраторами: они должны неустанно за- ботиться об удовлетворении потребностей пользователей и организаций, а также зани- маться проектированием и реализацией устойчивой к ошибкам вычислительной среды, стараясь при этом поражать своих клиентов эффективными решениями. Несмотря на то что системные администраторы часто считаются низкооплачиваемыми и недооценны- ми, большинство пользователей могут хотя бы назвать имя своего местного “сисадми- на” — причем во многих случаях гораздо быстрее, чем имя начальника их начальника. Но так было не всегда. За последние 40 лет (и в течение 20-летней истории этой кни- ги) роль системного администратора постепенно эволюционировала вместе с операци- онными системами (ОС) UNIX и Linux. Полное постижение предназначения системно- го администратора потребует понимания того, каким путем мы пришли к нынешнему состоянию, а также понимания некоторых исторических факторов, которые сформи- ровали наш ОС-ландшафт. Итак, окинем взглядом несколько чудесных десятилетий. Присоединяйтесь! Рассвет компьютеризации: системные операторы (1952-1960) Первый коммерческий компьютер, IBM 701, был выпущен в 1952 году. До него все компьютеры выпускались в единичных экземплярах. В 1954 году модернизированная версия IBM 701 была анонсирована как IBM 704. Она имела оперативную память на магнитных сердечниках объемом 4 096 слов и включала три индексных регистра. Этот компьютер использовал 36-разрядные слова (в отличие от 18-разрядных слов у IBM 701)
Краткая история системного администрирования 1279 и выполнял арифметические операции с плавающей запятой. Он работал со скоростью 40 000 инструкций в секунду. Но компьютер IBM 704 был несовместим с IBM 701. Несмотря на то что его постав- ки должны были начаться к концу 1955 года, операторы (предшественники современ- ных системных администраторов) восемнадцати существующих компьютеров IBM 701 уже нервничали: как им пережить эту “модернизацию” и на какие еще подводные кам- ни они могут наткнуться? Что касается самой компании IBM, то ее специалисты не имели решения проблемы модернизации и совместимости. В августе 1952 года для пользователей IBM 701 компа- ния провела “курсы повышения квалификации”, но учебников не выпустила. Некоторые слушатели этих “курсов” продолжали неформально встречаться и обсуждать свой опыт использования системы. Компания IBM поощряла встречи операторов, поскольку со- вместное рассмотрение проблем помогало общими усилиями найти их решение. IBM финансировала встречи операторов и предоставила их участникам доступ к библиотеке, включающей 300 компьютерных программ. Эта группа по обмену информацией, име- нуемая SHARE, все еще существует (вот уже 50 с лишним лет)1. От узкого назначения к работе с разделением времени (1961-1969) Первые образцы компьютерного оборудования были достаточно громоздкими и чрез- вычайно дорогими. Это наводило покупателей на мысль о том, что их компьютерные системы предназначены для решения одной-единственной конкретной задачи: только достаточно крупная и достаточно конкретная задача могла оправдать дороговизну и гро- моздкость такого компьютера. Если компьютер был инструментом специального назначения (таким, как, например, пила), то персонал, который обслуживал компьютер, можно назвать операторами такой “пилы”. К первым системным операторам относились скорее как к “тем, кто пилит дре- весину”, чем как к “тем, кто обеспечивает все необходимое для строительства здания”. Переход от системного оператора к системному администратору начался тогда, когда компьютеры превратились в универсальные (многоцелевые) инструменты. Основной причиной изменения точки зрения на компьютер стало то, что его начали использовать в режиме разделения времени. Джон Мак-Карти (John McCarthy) начал подумывать о режиме разделения времени в средине 1950-х годов. Но это было только в Массачусетсском технологическом ин- ституте (MIT) в 1961-1962 годах, когда Джон Мак-Карти, Джек Дэннис (Jack Dennis) и Фернандо Корбато (Fernando Corbato) серьезно говорили о том, чтобы разрешить “каждому пользователю компьютера вести себя так, будто он — единственный его поль- зователь”. В 1964 году MIT, General Electric и Bell Labs объединили свои усилия по созданию проекта по построению претенциозной системы, работающей в режиме разделения времени. Эта система получила название Multics (Multiplexed Information и Computing Service). Пять лет спустя проект Multics превысил бюджет и безнадежно отстал от графи- ка работ. В результате компания Bell Labs вышла из проекта. 1 Несмотря на то что группа SHARE изначально спонсировалась производителями вычисли- тельной техники, в настоящее время она является независимой организацией.
1280 Краткая история системного администрирования Рождение UNIX (1969-1973) Отказ компании Bell Labs от участия в проекте Multics оставил нескольких научных работников в Мюрей Хилл (штат Нью-Джерси) без работы. Трое из них — Кен Томпсон (Ken Thompson), Руд Кенедей (Rudd Canaday) и Дэннис Ричи (Dennis Ritchie) — за- интересовались некоторыми аспектами проекта Multics, но не были в восторге от раз- мера и сложности этой системы. Они не раз собирались вместе обсудить принципы проектирования компьютерных систем. Компания Labs запустила систему Multics на своем компьютере GE-645, и Кен Томпсон продолжил работу над этим проектом “шут- ки ради.” Дуг МакИлрой (Doug McIlroy), руководитель этой группы, сказал: “Система Multics впервые заработала именно здесь. Вдохнуть в нее жизнь удалось трем нашим со- трудникам”. Летом 1969 года Томпсон на месяц стал холостяком, пока его жена, Бонни, взяв их годовалого сына, уехала повидать родственников на западное побережье. Томпсон вспо- минал: “Я выделил по неделе на операционную систему, интерпретатор команд, редак- тор и ассемблер...и все эти компоненты были полностью переписаны в форме, которая придавала им вид операционной системы (с набором известных утилит, ассемблером, редактором, интерпретатором команд), которая, если не поддерживала себя сама, была практически на грани такой поддержки, т.е. больше совершенно не нуждалась в GECOS2”. Стив Борн (Steve Bourne), пришедший работать в Bell Labs в следующем году, так описывал “заброшенный” компьютер PDP-7, которым воспользовались Ричи и Томпсон: “В PDP-7 были только ассемблер и загрузчик. На этом компьютере мог работать лишь один пользователь. Среда еще “отдавала сыростью”, хотя части одно- пользовательской системы UNIX уже были “на подходе”... И вот были написаны ассем- блер и зачаточное ядро операционной системы, которые еще требовали использования кросс-ассемблера для трансляции программы на машине PDP-7 с системой GECOS. Название UNICS (UNiplexed Information and Computing Service) для “новорожден- ной” операционной системы придумал заядлый остряк Питер Нейман (Peter Neumann) в 1970 году”. Первоначально UNIX была однопользовательской системой, отсюда, по- видимому, и намек на “урезанный вариант Multics”. И хотя некоторыми аспектами си- стема UNICS/UNIX все же обязана своей предшественнице Multics, у них, по словам Дэнниса Ричи, были “серьезные различия”. “Мы были немного подавлены большим менталитетом системы, — сказал он. — Кен хотел создать что-то простое. Вероятно, из-за того, что наши возможности были тог- да довольно невелики. Мы могли достать только маленькие машины без каких-либо аппаратных средств Multics. Поэтому UNIX нельзя назвать ответным ударом, направ- ленным против Multics... Операционная система Multics больше не существовала для нас, но нам нравилось ощущение интерактивной работы на компьютере, которое она предлагала пользователю. У Кена были некоторые идеи по созданию новой системы... И хотя Multics повлияла на подходы к реализации UNIX, это влияние не было опреде- ляющим.” “Игрушечная” система Кена и Дэнниса не долго оставалась “простой”. К 1971 году в число команд пользователя входили следующие: as (ассемблер), cal (простая утилита- календарь), cat (конкатенация и вывод), chdir (изменение рабочего каталога), chmod (изменение режима), chown (изменение владельца), стр (сравнение двух файлов), ср 2 GECOS (General Electric Comprehensive Operating System) — операционная система, разрабо- танная компанией General Electric в 1962 г.
Краткая история системного администрирования 1281 (копирование файла), date, de (калькулятор), du (отчет об использовании дискового пространства), ed (редактор) и еще два десятка других команд. Большинство из этих ко- манд все еще находятся в употреблении. К февралю 1973 года можно было говорить о существовании 16 инсталляций UNIX, а также о двух больших нововведениях. Первое связано с “новым” языком програм- мирования С, основанным на языке В, который сам представлял собой “урезанную” версию языка BCPL (Basic Combined Programming Language), созданного Мартином Ричардсоном (Martin Richards). Второе нововведение — понятие канала. Канал, попросту говоря, — это стандартный способ связи выходных данных одной программы с входными данными другой. Среда Dartmouth Time-Sharing System имела файлы связи, которые предвосхитили каналы, но их использование было гораздо бо- лее узким. Идея каналов (как обобщенного средства передачи данных) была предло- жена Дутом Макилроем (Doug McIlroy), а реализована — Кеном Томпсоном благодаря настойчивости МакИлроя. (“Это был один из немногочисленных случаев, когда я, по сути, осуществлял административное управление над UNIX”, — сказал Дуг.) “Легко сказать: 'cat — в grep — в...’ или ‘who — в cat — в grep’ и так далее, — как- то заметил МакИлрой. — Это легко сказать, и было ясно с самого начала, что именно это вы и хотели бы сказать. Но еще существуют все эти параметры... И время от времени я говорил: ‘Как бы нам сделать что-то вроде этого?’ И вот в один прекрасный день я пришел с синтаксисом для командного языка, который развивался вместе конвейерной пересылкой данных, и Кен сказал: ‘Я готов сделать это!’ ” Применив множество вариантов, Томпсон обновил все UNIX-программы за одну ночь. Это было настоящее начало власти UNIX, возникшее не из отдельных программ, а из взаимосвязей между ними. Теперь у UNIX были собственные язык и основополагаю- щие принципы. • пишем программы, которые бы выполняли одну задачу, но выполняли ее хорошо; • пишем программы, которые бы работали вместе; • пишем программы, которые обрабатывали бы текстовые потоки как универсаль- ный интерфейс. Итак, можно было говорить о “рождении” операционной системы общего назначе- ния с разделением времени, но пока лишь в “недрах” фирмы Bell Labs. ОС UNIX обе- щала простое и незаметное разделение компьютерных ресурсов между проектами, груп- пами и организациями. Но прежде чем этот универсальный инструмент стал достоянием всего мира, он должен был вырваться из собственной колыбели и “размножиться”. UNIX становится знаменитой (1974-1990) В октябре 1973 года международная научно-образовательная Ассоциация по вычис- лительной технике (Association for Computing Machinery — ACM) провела симпозиум на тему “Принципы построения операционных систем” (Symposium on Operating Systems Principles — SOSP) в аудитории Центра исследований (T.J. Watson Research Center) компании IBM в Йорктаун Хайтс (Yorktown Heights), штат Нью-Йорк. Кен и Дэннис представили на рассмотрение свой доклад и в один прекрасный осенний день поехали в Долину Гудзона (Hudson Valley), чтобы представить его. (Томпсон сделал настоящую презентацию.) В зале было около 200 человек, и доклад произвел фурор. Шесть месяцев спустя количество инсталляций UNIX утроилось. Когда этот доклад был опубликован в июльском (1974) выпуске журнала “Communications of the АСМ”, ре- акция читателей была просто ошеломляющей. Научно-исследовательские лаборатории
1282 Краткая история системного администрирования и университеты увидели в разделяемых UNIX-системах потенциальное решение пробле- мы их постоянно возрастающих потребностей в компьютерных ресурсах. В соответствии с положениями антитрестовского соглашения 1958 года, подписан- ного корпорацией AT&T (из недр которой выделилась фирма Bell Labs) с федеральным правительством, ее деятельность была весьма ограничена: она не имела право занимать- ся рекламой, продажей и сопровождением компьютерных продуктов. Компания Bell Labs должна была давать разрешение на использование другими своей технологии. Тем не менее система UNIX завоевала популярность в мире, особенно среди телефонных компаний. Отвечая на многочисленные просьбы, Кен Томпсон стал распространять ко- пии исходного кода UNIX, и, по легенде, каждый пакет включал его личную записку, подписанную “love, ken” (с любовью, Кен). Одним из тех, кто получил копию системы от Кена, был профессор Роберт Фабри (Robert Fabry) Калифорнийского университета в Беркли. Так, к январю 1974 года зерно Berkeley UNIX попало в плодородную почву. Другие ученые, работающие в области компьютерных наук, также проявили интерес к UNIX. В 1976 году Джон Лайонс (John Lions), преподаватель факультета компьютер- ных наук в Университете Нового Южного Уэльса в Австралии, опубликовал подробные комментарии относительно ядра версии V6. Эта работа стала первым серьезным паке- том документации по системе UNIX и помогла другим понять и развить работу Кена и Дэнниса. Студенты Калифорнийского университета в Беркли поработали над версией UNIX, полученной из Bell Labs, и изменили ее так, чтобы она отвечала их требованиям. Первый ленточный дистрибутив программы Беркли (1st Berkeley Software Distribution — 1BSD) содержал систему Pascal для Unix и текстовый редактор ех для компьютера PDP-11. Этот дистрибутив подготовил аспирант Билл Джой (Bill Joy). Второй выпуск (2BSD) вы- шел в следующем году, а третий (3BSD) — в качестве первого дистрибутива программы Беркли для мини-компьютера VAX, выпускаемого корпорацией DEC, увидел свет в кон- це 1979 года. В 1980 году профессор Роберт Фабри заключил контракт с управлением перспектив- ных исследовательских программ в области обороны (Defense Advanced Research Project Agency — DARPA) на продолжение разработки системы UNIX. Результатом этого со- глашения стало образование в Беркли исследовательской группы по компьютерным си- стемам (Computer Systems Research Group — CSRG). В конце следующего года вышла четвертая версия системы — 4BSD. Она приобрела довольно широкую популярность, в основном, потому, что это была единственная версия UNIX, которая работала на DEC VAX 11/750, весьма распространенной в то время компьютерной платформе. Еще одно крупное усовершенствование, отличавшее выпуск 4BSD, состояло в использовании со- кетов TCP/IP, обобщенной сетевой абстракции, которая в будущем породила Интернет и сейчас используется многими современными операционными системами. К средине 1980-х годов в большинстве крупных университетов и научно-исследовательских инсти- тутов была установлена хотя бы одна система UNIX. В феврале 1982 года в городе Санта-Клара, что расположен в Кремниевой Долине, была основана компания Sun Microsystems. Так вышло, что Билл Джой присоединился к SUN (сейчас это часть компании Oracle America) практически в момент зарождения, причем вместе с усовершенствованной им версией Unix (4.2BSD). Там он начал рабо- тать над операционной системой SunOS (версия UNIX для рабочих станций и серверов). В 1983 году по решению суда началась ликвидация корпорации AT&T, и одним непред- виденным побочным эффектом этой ликвидации было то, что AT&T отныне могла сво-
Краткая история системного администрирования 1283 бодно продавать систему UNIX как программный продукт. В результате увидела свет версия AT&T UNIX System V — общеизвестная, хотя и несколько неудобная коммерче- ская реализация системы UNIX. Теперь, когда Berkeley, AT&T, Sun и другие дистрибутивы UNIX стали доступны для широкого круга организаций, был заложен фундамент для общей компьютерной инфра- структуры, построенной на технологии UNIX. Систему, которую использовали в обла- сти астрономии для вычисления звездных расстояний, можно было успешно применять в математике для вычисления множеств Мандельброта. И та же система одновременно обеспечивала доставку электронной почты для всего университета. Системные администраторы, ваш выход! Управление компьютерными системами общего назначения требовало другого уров- ня знаний, чем двадцать лет назад. Ушли в прошлое дни, когда системный оператор обслуживал единственную компьютерную систему, предназначенную для выполнения узкоспециализированной задачи. Системный администратор в начале 1980-х годов стал настоящим “хозяином положения”, который знает, как настроить систему UNIX, чтобы она удовлетворяла требованиям самых разных приложений и пользователей. Поскольку система UNIX была весьма популярной в университетах и множество студентов горело желанием овладеть новейшими технологиями, именно университеты лидировали в создании организованных групп системных администраторов. Такие учеб- ные заведения, как Университет Пердью, Университет штата Юта, Университет штата Колорадо, Университет штата Мэриленд и Университет штата Нью-Йорк (SUNY) в г. Буффало, стали “рассадниками” специалистов в области системного администриро- вания. Кроме того, системные администраторы разработали собственные процессы, стан- дарты, инструкции и инструменты (например, sudo). Большинство из этих продуктов родилось из необходимости, поскольку без них системы работали нестабильно, что, естественно, вызывало недовольство пользователей. Эви Немет (Evi Nemeth) приобрела известность как “мать системного администриро- вания” тем, что приглашала на работу в качестве системных администраторов студентов старших курсов Инженерного колледжа (Engineering College) при Университете штата Колорадо. Ее близкие связи с сотрудниками Калифорнийского университета в Беркли, Университета штата Юта и SUNY в г. Буффало позволили создать сообщество экспертов по вопросам системного администрирования, которые делились советами и инструмен- тами. Ее команду часто называли как “munchkins”, т.е. “переработчики информации” или “рабы Эви”. Члены этой команды посещали различные конференции (в том числе и спонсируемые организацией USENIX) и работали там в качестве служебного персона- ла в обмен на возможность получать информацию, излагаемую участниками этих кон- ференций. Уже стало ясно, что системные администраторы должны были стать “мастерами на все руки”. В 1980-х годах обычное утро системного администратора могло начаться с монтажа проводов для починки поврежденного переключателя на задней панели мини- компьютера VAX. Днем он мог заниматься очищением лазерного принтера первого по- коления от рассыпавшегося тонера. Его обеденный перерыв мог бы быть потрачен на помощь какому-нибудь студенту отладить новый драйвер ядра, а вечерние часы могли быть заполнены записью информации на архивные ленты и уговорами пользователей почистить свои персональные каталоги, чтобы освободить пространство в файловой си-
1284 Краткая история системного администрирования стеме. Системный администратор был, без преувеличения, бескомпромиссным ангелом- хранителем, который должен был решить любую проблему. 1980-е годы можно было назвать временем ненадежного оборудования. Центральные процессоры были сделаны не из одной кремниевой микросхемы, а из нескольких сотен чипов, каждый из которых мог в любую минуту отказать. И именно системный адми- нистратор должен был быстро отыскать неисправный элемент и заменить его работаю- щим. К сожалению, в то время еще не работала Federal Express (частная почтовая служба срочной доставки небольших посылок и бандеролей), и поэтому элементы для замены нужно было находить самим, что зачастую было очень непросто. Однажды перестал работать наш любимый компьютер VAX 11/780, в результате чего весь университет остался без электронной почты. Мы знали, что недалеко от нас есть фирма, которая собирала компьютеры VAX, предназначенные “для научных исследова- ний” для отправки в Советский Союз (то было время “холодной войны”). Практически без всякой надежды на успех мы заявились на склад с большой суммой наличных в кар- мане, и после часа переговоров мы все-таки получили необходимую печатную плату. Кое-кто отметил, что в то время в Боулдере (штат Колорадо) было легче достать нарко- тики, чем запчасти к VAX. Документация по системному администрированию й обучение По мере того как отдельные “компьютерщики” стали считать себя системными ад- министраторами — и причем стало ясно, что такая специализация может обеспечить до- стойную жизнь, — потребности в документации и соответствующем обучении ощутимо возрасли. “Идя навстречу пожеланиям трудящихся”, Тим О’Рейлли (Tim O’Reilly) и его команда (именуемая ранее O'Reilly and Associates, а теперь O'Reilly Media) начали публи- ковать документацию по системе UNIX, написанную простым языком и основанную на реальном опыте. Ш Больше ссылок на источники информации о системном администрировании приведено в главе 32. В качестве посредника межличностного взаимодействия ассоциация USENIX про- вела свою первую конференцию, посвященную системному администрированию, в 1987 году. Эта конференция (Large Installation System Administration — LISA) охватила, в основном, западное побережье. Три года спустя был учрежден институт SANS (SysAdmin, Audit, Network, Security) для удовлетворения потребностей специалистов восточного по- бережья. В настоящее время конференции LISA и SANS обслуживают всю территорию США и до сих пор на достаточно высоком уровне. В 1989 году мы опубликовали первое издание этой книги, имевшей тогда название UNIX System Administration Handbook. Она была быстро раскуплена, в основном, из-за от- сутствия альтернативы. В то время наш издатель был настолько далек от системы UNIX, что в их производственном отделе все вхождения строки “etc” были заменены строкой “and so on”, в результате чего появились такие имена файлов, как /and so on/passwd. Мы воспользовались создавшейся ситуацией, чтобы взять под полный контроль все со- держимое книги от корки до корки, и сейчас, надо признать, наш издатель стал более осведомленным в вопросах UNIX. Наше 20-летнее сотрудничество с этим издателем дало пищу для других интересных историй, но мы их опустим, дабы не испортить наши вполне дружеские отношения.
Краткая история системного администрирования 1285 UNIX "при смерти”. Рождение Linux (1991-1995) К концу 1990 года казалось, что UNIX стремительно движется к мировому господ- ству. Бесспорно, именно эту операционную систему выбирали как для ведения бизнеса (например, Taco Bell и McDonald’s), так и для исследовательских и научных расчетов. Группа CSRG (Computer Systems Research Group — исследовательская группа по ком- пьютерным системам) в Беркли, состоящая из Кирка Мак-Кузика (Kirk McKusick), Майка Карелса (Mike Karels), Кейта Бостика (Keith Bostic) и многих других, как раз вы- пустила версию 4.3BSD-Reno, основанную на выпуске 4.3, в которую была добавлена поддержка для процессора CCI Power 6/32 (с кодовым именем “Tahoe”). Коммерческие выпуски UNIX (например, SunOS) также пользовались успехом, кото- рый, отчасти, им обеспечили появление Интернета и первые шаги в направлении элек- тронной торговли. Оборудование персонального компьютера (ПК) стало предметом ши- рокого потребления. Оно уже было относительно надежным, недорогим и обеспечивало довольно высокую производительность. И хотя версии системы UNIX, запускаемые на ПК, действительно существовали, все они были коммерческими, причем с закрытым исходным кодом. Назрела ситуация для появления UNIX для ПК с открытым исходным кодом. В 1991 году, группа разработчиков, трудившихся над выпусками BSD, — Донн Сили (Donn Seeley), Майк Кареле, Билл Джолитц (Bill Jolitz) и Трент Р. Хейн (Trent R. Hein) —- вместе с другими приверженцами BSD основали компанию Berkeley Software Design, Inc. (BSDI). Под руководством Роба Колстада (Rob Kolstad) компания BSDI предостав- ляла исполняемые файлы и исходный код для полностью функциональной коммерче- ской версии BSD UNIX на платформе ПК. Среди прочего, этот проект доказал, что для массового производства компьютеров можно использовать недорогое оборудование ПК. Компания BSDI продемонстрировала взрывоподобный рост прибыли на заре развития Интернета, поскольку именно ее операционную систему выбирали первые провайдеры услуг Интернета (Internet service providers — ISP). Пытаясь снова упрятать джинна, который выскочил из бутылки в 1973 году, кор- порация AT&T в 1992 году начала судебный процесс против компании BSDI и членов правления университета Калифорнии (Regents of the University of California), заявив о копировании кода и воровстве производственных секретов. Юристам компании AT&T потребовалось более двух лет, чтобы идентифицировать проблемный код. В результате судебного разбирательства из кода BSD было удалено три файла (из более чем 18 000). К сожалению, этот двухлетний период неопределенности оказал негативное воздей- ствие на весь мир UNIX, операционную систему BSD и подобные ей He-BSD-версии. Многие компании перешли на использование Microsoft Windows, испугавшись, что они могут оказаться во власти компании AT&T, которая практически “задушила в объяти- ях” свое дитя. К тому времени, когда дым сражений развеялся, оказалось, что компании BSDI и CSRG “смертельно ранены”. Эра BSD подходила к концу. Тем временем Линус Торвальдс (Linus Torvalds), студент колледжа в Хельсинки, наигравшись с Minix — сво- бодной Unix-подобной микроядерной операционной системой, распространяемой по лицензии BSD, — начал писать собственную систему-клон UNIX3. К 1992 году появи- лось множество дистрибутивов Linux (включая SuSE и ^gdrasil Linux). В 1994 году мир узнал о создании систем Red Hat и Linux Pro. 3 ОС Minix была разработана Эндрю Таненбаумом (Andrew S. Tanenbaum), профессором Амс- тердамского свободного университета.
1286 Краткая история системного администрирования Феноменальный успех Linux основан на многих факторах. Мощная поддержка всех, кому понравилась эта система, и обширный список программ из архива GNU сделали Linux неуязвимой системой. Она прекрасно работает в любых производственных средах, и поговаривают, что на основе Linux можно построить более надежную и более произ- водительную систему, чем на основе любой другой операционной системы. Интересно также отметить, что отчасти своим успехом Linux обязана блестящей возможности, пре- доставленной ей действиями компании AT&T против BSDI и университета Калифорнии в Беркли. Тот неуместный судебный процесс вселил страх в сердца приверженцев UNIX прямо на заре электронной торговли и в начале эры Интернета. Но не все ли равно теперь? Главное, что в результате всех этих перипетий осталась огромная потребность в системных администраторах. Багаж знаний и опыт, накоплен- ный системными администраторами при обслуживании систем UNIX, полностью при- менимы к Linux, и большинство “UNIX-лоцманов” заботливо продолжали вести своих пользователей через бурные моря 1990-х. Возмите себе на заметку: хороший системный администратор должен всегда оставаться спокойным во время любого шторма. Мир Windows (1996-1999) В 1993 году компания Microsoft выпустила ОС Windows NT. Эта “серверная” версия Windows, которая имела популярный пользовательский интерфейс, имела значительный эффект, причем как раз тогда, когда корпорация AT&T старалась убедить всех в том, что? она больше никому не позволит обманывать себя в лицензионных вопросах. Как след- ствие, многие организации приняли Windows в качестве предпочтительной платформы, для совместных вычислений. Это был конец 1990-х. Вне всякого сомнения, платформа Microsoft прошла долгий путь развития, и для некоторых организаций это был наилуч- ший выбор. К сожалению, сначала администраторы UNIX, Linux и Windows использовали в сво- ей работе конкурентные подходы, соперничая за “место под солнцем” путем противо- поставления аргументов из рекламы пива: “отличный вкус” против “меньшего объема”4. Многие администраторы систем UNIX и Linux начали срочно изучать Windows, убеж- денные в том, что в противном случае им придется “положить зубы на полку”. А на го- ризонте уже показалась Windows 2000. С приближением “миллениума” будущее UNIX выглядело все более мрачным. Расцвет UNIX и Linux (с 2000-го по настоящее время) С приходом Интернета все стрались понять, что “настоящее”, а что — всего лишь мираж. Когда страсти “от новизны” немного улеглись, стало ясно, что многие органи- зации с успешными техническими стратегиями использовали UNIX или Linux вместе с Windows, а не только что-то одно. Конкурентной войны больше не было. Системные администраторы UNIX и Linux, которые пополнили свой квалификаци- онный багаж системой Windows, стали еще более ценными специалистами. Они могли теперь “наводить мосты” над пропастью между двумя мирами и эффективно использо- вать обе системы на благо своей организации. Оценки экспертов, использующих методи- ку определения наилучшего соотношения цены/качества (total cost of ownership — TCO), показали, что этот показатель для сервера Linux был значительно ниже аналогичного показателя для сервера Windows. Для ясности: в Windows действительно “меньше объема”.
Краткая история системного администрирования 1287 В настоящее время можно говорить о процветании UNIX и Linux. Коммерческие версии UNIX (AIX, Solaris и HP-UX) вполне отвечают требованиям соответствующих рынков. Linux и ПК-ориентированные UNIX-версии продолжают увеличивать свою долю рынка, причем Linux — единственная операционная система, у которой доля рын- ка по серверам растет постоянно (по данным 2010 года). Кроме того, не надо забывать о том, что такая современная операционная система от компании Apple, как Mac OS X, также построена на основе UNIX5. Множество новых достижений в системах UNIX и Linux относится к сфере вирту- альных и облачных вычислений. (Подробнее об этих технологиях см. главу 24.) И снова- таки, в этих средах есть один общий элемент: системные администраторы. Ваш бесценный опыт как системного администратора обязательно найдет применение: и в материальной, и виртуальной среде! Завтрашний день UNIX и Linux Не важно, в каком направлении пойдет развитие UNIX и Linux в ближайшие не- сколько лет, одно можно сказать точно: UNIX и Linux будут по-прежнему востребованы! Системные администраторы заботятся о целостности компьютерной инфраструктуры, решают сложнейшие проблемы эффективности и масштабируемости систем и снабжают квалифицированными рекомендациями в области компьютерных технологий как рядо- вых пользователей, так и руководителей организаций. Мы — системные администраторы! Без нас — никак! Рекомендуемая литература • Mckusick, Marshall Kirk, Keith Bostic, Michael J. Karels and John S. Quarterman. The Design and Implementation of the 4.4BSD Operating System (2nd Edition). Reading, MA: Addison-Wesley, 1996. • Salus, Peter H. A Quarter Century of UNIX. Reading, MA: Addison-Wfesley, 1994. • Salus, Peter H. Casting the Net: From ARPANET to Internet and Beyond. Reading, MA: Addison-Wesley, 1995. • Salus, Peter H. The Daemon, the Gnu, and the Penguin. Marysville, WA: Reed Media Ser- vices, 2008. Эта книга также опубликована на сайте www.groklaw.net. 5 Даже устройства iPhone, производимые компанией Apple, используют урезанный вариант си- стемы UNIX, а операционная система Android (от компании Google) включает абстракции, взятые из ядра Linux.
в защиту Aix Диалог с Дэном Фостером (Dan Foster) Система AIX известна с 1980-х годов, но в этом издании книги она впервые рассмо- трена в качестве примера. Мы и ранее обсуждали внесение системы AIX в некоторые предыдущие издания, но всегда нам мешал тот факт, что она слишком сильно отлича- ется от других версий UNIX. Если говорить точнее, нам было удобнее описывать их без упоминания AIX. Мы хотели встретить AIX с распростертыми объятиями. Тем не менее внимательные читатели могли бы отметить определенное постоянство тона в отношении AIX, который звучит не совсем хвалебно. Подобно бездомному щенку, система AIX, казалось бы, всег- да ведет себя как-то не так и никогда не понимает, почему вдруг все расстроены. От этого всего нам не по себе: кому нравится прогонять щенка? Чтобы вернуть себе душевное равновесие, мы попросили Дэна Фостера, одного из наших рецензентов из мира AIX, описать достоинства системы AIX. Итак, мы выступим с обвинением против AIX, а Дэну предоставим слово для ее защиты. Наши бурные обвинения AIX —• операционная система, созданная для мэйнфреймов IBM в 1970-е годы и му- чительно “застрявшая” в теле системы UNIX. Хотя структура UNIX поддерживает эту систему в работоспособном состоянии, AIX совершенно не заинтересована в соблюде- нии UNIX-соглашений. Она использует множество различных “шиньонов”, “корсетов” и “косметических наборов”, чтобы представить более гармоничный образ системы во вкусе IBM. Это — открытая, состоящая из модулей система, которая стремится быть за- крытой и монолитной. Тех, кто подходит к системе AIX как к UNIX, ожидает ряд затруднений. AIX не пи- тает иллюзий, что администраторы действительно понимают, что они делают или долж- ны сделать для модификации системы. Вместо простоты, модульности и гибкости, AIX предлагает структуру. Были затрачены значительные усилия, чтобы каталогизировать ад- министративные операции и собрать их “под крышей” интерфейсных средств админи- стратора системы (System Management Interface Tool — SMIT). Если необходимой вам опе- рации не окажется в этом каталоге,... ну что ж, не стоит из-за этого сильно переживать. К сожалению, SMIT — не единственный дополнительный уровень косвенности AIX. Операции SMIT преобразуются в команды оболочки, поэтому каждая операция SMIT требует специальной команды, которая бы реализовала ее одним шагом. Отсюда и изо- билие семейств команд (таких, как erf s/chfs/rmfs), которые реализуют заранее пред- писанные рецепты. Эти команды повышают уровень сложности системы и накладные расходы, не создавая больших ценностей, в то время как другие системы UNIX прекрас- но обходятся без них. Поскольку административные операции занимают промежуточное положение в про- граммном обеспечении, система AIX не видит никакой необходимости сохранять ин- формацию в текстовых файлах. Вместо этого она скопила множество разнообразных двоичных форматов и журналов регистрации, в основном, в виде подсистемы ODM (Object Data Manager — управление объектными данными). Системные администра- торы могут использовать обобщенные ODM-команды для просмотра и модификации этих данных, но это уже из области черной магии, что, мягко говоря, удручает. В целом, ODM — это “черный и загадочный континент” с многочисленными “темными” углами, напоминающий системный реестр Windows.
В защиту AIX 1289 Если сорвать “панцирь” AIX, то под ним обнаружатся печальные маленькие гомун- кулы UNIX, лежащие скрученными там и сям. Это “существо” нельзя назвать здоровым: оно испещрено возрастными морщинами, его кожа бледна вследствие отгороженности от внешнего мира и от усовершенствований UNIX последних десятилетий. Вероятно, компания IBM видит для своей системы не мейнстрим UNIX, а совсем другое направ- ление развития. Дэн Фостер: аргументы в защиту Да уж, вы нарисовали не очень приятную картину. Но, я думаю, будет справедливо оха- рактеризовать многие из перечисленных вами недостатков как синдром “не мы придума- ли”, другими словами, как противодействие всему, что не подчиняется стандарту UNIX. Есть определенная доля истины в вашем заявлении о том, что система AIX стремит- ся быть больше, чем просто еще одним клоном UNIX. И это совсем не плохо. Система AIX предназначена не для ковбоев. Ее назначение — упростить администрирование си- стемы, помочь в обеспечении надежности и устойчивости ее работы. По своим целям она серьезно отличается от других систем UNIX, поэтому и производит несколько иное впечатление. AIX позаимствовала у IBM-систем AS/400 ряд полезных инструментов. Например, она использует централизованное средство регистрации ошибок, которое приложения могут легко задействовать через API. Такая система упрощает протоколирование оши- бок, уведомление о событиях администратора и выявление проблем. Протокол Syslog реализует некоторые из этих функций, в основном, для UNIX, но, судя по тому, как описана регистрация ошибок во многих разделах этой книги, единообразия в его ис- пользовании не наблюдается. Несколько лет спустя компания Sun реализовала анало- гичный подход с помощью демона fmd (fault management daemon — защита от ошибок и неисправностей) в системе Solaris 10. Теперь возьмем подсистему управления оборудованием. AIX предоставляет центра- лизованные средства диагностики для практически любого поддерживаемого системой устройства. Они позволяют даже регистрировать действия, связанные с ремонтом обо- рудования (в некоторых случаях возможно отключение неисправных светодиодов и ге- нерирование соответствующих уведомлений), обеспечивая таким образом ведение жур- нала контрольных записей. Эта система’предусматривает и другие действия по оказанию помощи через процедуры обратного вызова, но не оставляет вас “на произвол судьбы”, как большинство версий UNIX. Отвечая на ваши конкретные претензии, могу сказать, что команды, предназначен- ные для выполнения конкретных задач, — это просто особенность, а не дефект системы! Они (команды) зачастую оказываются полезными для системных администраторов. • Как показано в приведенном вами примере, наборы AIX-команд имеют ясные име- на, говорящие сами за себя (чего нельзя сказать о командах UNIX). Семейство ко- манд mk* предназначено для создания объектов, семейство rm* — для их удаления, ch* — для модификации, a 1s* — для отображения текущего состояния. Эти струк- турированные семейства команд генерируют предсказуемые результаты и позволяют сократить время, необходимое на их изучение. Они уменьшают вероятность выпол- нения неправильной команды, если, например, вы засиделись до глубокой ночи и с затуманенными глазами все же продолжаете работать или если вы только начинае- те осваивать систему AIX. Конечно, в таких ситуациях хорошую службу сослужит вам и меню SMIT (интерфейсные средства администратора системы).
1290 В защиту AIX • Команды могут проверять допустимость своих аргументов, а файлы конфигура- ции — нет. Команда-“обертка” способна гарантировать, что предлагаемое вами изменение не разрушит систему. Если вы все же намерены это сделать, команда может “пожаловаться на вас” или, попросту, отказаться внести такое изменение в систему. Это гораздо лучше, чем потом “пожинать горькие плоды”, случайно из- менив содержимое файла конфигурации. • Специализированные команды упрощают написание сценариев. В них не только сочетаются функции и допустимые аргументы, но они также освобождают сцена- рии от необходимости анализировать сложные файлы конфигурации и управлять ими. Это делает сценарии короче, надежнее и проще для обслуживания (и изуче- ния!). Воспринимайте эти команды как высокоуровневую библиотеку функций администрирования, которая встроена в операционную систему и способна пони- мать практически любые языки, на которых пишутся сценарии. • Использование упомянутого интерфейса администратора уменьшает зависимость от конкретных файловых форматов или реализаций. Он позволяет IBM изменять свои серверные приложения и вводить новые технологии, не разрушая существу- ющих сценариев. Например, в настоящее время подсистема ODM сохраняет свои данные в файлах BDB (Berkeley DB — высокопроизводительная встраиваемая база данных, реализованная в виде библиотеки). Однако IBM не могла просто заме- нить ODM протоколом LDAP (Lightweght Directory Access Protocol — облегченный протокол службы каталогов) или некоторыми другими будущими технологиями, сохранив ODM-команды и пользовательский интерфейс в прежнем виде. Просто не будьте ненавистниками SMIT! SMIT — гибкая система, которая реализу- ет разнообразные интерфейсы (XII, веб-страница, клиент командной строки). Эта гиб- кость означает, что вы можете использовать один тот же интерфейс, сидя за офисным компьютером или работая дома глубокой ночью. Интерфейс SMIT упрощает сложные процедуры и помогает начинающим админи- страторам быстрее выйти на должный уровень квалификации. Он используется и под- держивается уже многие годы, в течение которых постоянно совершенствовались раз- личные пользовательские интерфейсы. Его легко использовать независимо от вашего отношения к UNIX вообще или к AIX в частности. И потом, SMIT — это прекрасное средство обучения, даже для опытных администраторов. Вы можете заполнить SMIT- форму требуемыми для вас значениями, после чего SMIT будет работать именно с теми командами, которые вам нужны. Ничего подобного нет ни в какой другой системе, и это замечательно! Что касается вашего определения AIX как не “настоящей” UNIX-версии, то это про- сто неправда. Изначально система AIX была основана на ОС BSD, и следы этого проис- хождения (например, использование mbuf-кластеров в сетевом стеке AIX) сохранились по сей день. Позже внимание разработчиков переключилось на совершенствование ба- зовых составляющих системы System V. Система AIX была сертифицирована на соответ- ствие стандартам SUS (Single Unix Specification), Х/Open и POSIX. Кроме того, компа- ния IBM воспользовалась легендарной переносимостью системы UNIX и перевела AIX в ранг систем, которые могут работать на машинах широкого диапазона: от персональных компьютеров серии PS/2 до мэйнфреймов. Наконец, суперкомпьютер Deep Blue (вы- сокопроизводительный кластер IBM НРС), который одержал победу в матче из шести партий с чемпионом мира по шахматам Гарри Каспаровым в 1996 и 1997 годах, работал под управлением системы AIX!
Предметный указатель в BIND, пакет журнальная регистрация 772, 717 каналы 713 категории сообщений 714 конфигурация 663 параметры конфигурации 646 allow-query 650 allow-transfer 650 also-notify 647 blackhole 650 directory 646 forward 649 forwarders 649 notify 647 recursion 648 сообщения об ошибках 715 статистика 720 BIOS 124 С CGI-сценарии 1004 D DNS 597, 598, 602, 616 база данных 618, 641 директива $GENERATE 619 SINCLUDE 619 SORIGIN 619 $TTL 619, 620, 625 записи о ресурсах 600, 620 запись А 626 CNAME 628, 629 KEY 690 MX 627 NS 625 PTR 626 SOA 604, 623 SRV 630 TXT 632 класс записи 621 обновление 682, 684 делегирование 600 динамические обновления 656 домен регистрация 611 создание поддоменов 612 зона 623 порядковый номер 604, 624 создание 656 цифровая подпись 693 конфигурирование 530 кеширование 601 некорректное делегирование 612, 722 обратное преобразование 626 посредством записей CNAME 629 передача зоны 608 пространство имен 610, 612 прямое преобразование 626 распознаватель 598 сервер имен 599, 608 авторитативный 608 авторитетный 625 главный 608, 656 кеширующий 608 нерекурсивный 609 переадресующий 649, 658 подчиненный 608, 657 рекурсивный 609 усеченный 608 сигнатуры транзакций 689 спецификация DNSSEC 692 TKEY 689 TSIG 689 файл подсказок 610, 656, 658 Е Ethernet 579 МАС-адрес 502 инкапсуляция пакетов 500 параметр MTU 501 соединение сегментов 583 спецификации 578 топология 580 фрейм 500 стандарты 501 широковещательный домен 580 Exim, почтовый агент 855 аутентификация 867 загрузка 857 конфигурация 859 макрос 862 маршрутизатор accept 869 dnslookup 870 manualroute 870 redirect 870 регистрация 874 сканирование вирусов 866 спама 867 список ACL 862 транспортный механизм 872 appendfile 872 smtp 872 утилита exicyclog 858 exigrep 858 exilog 859 exim_checkaccess 858 exim_dbmbuild 858 exim dumpdb 858 exim_fixdb 858 exim lock 859 eximon 859 eximstats 858 exim_tidydb 858 exinext 858 exipick 858 exiqgrep 858 exiqsumm 858 exiwhat 858 фильтрация пользователей 871 с GDI-принтерами 1119 I IOS, операционная система 572
1292 Предметный указатель L Linux безопасность 944, 947 дистрибутивы 49 N NAT 510, 982 IP-маскирование 537 РАТ 540 Netfilter 982 NFS 735 блокировка файлов 739 выбор порта 754 дисковые квоты 743 клиент 751 пользователь nobody 742 root 742 сервер 738 специализированный 756 р РАМ 954 модуль binding 956 include 956 optional 956 required 956 requisite 956 sufficient 956 Postfix, почтовый агент 876 архитектура 876 аутентификация 887 механизм SMTP AUTH 887 виртуальные домены 883 программа cleanup 877 local 878, 882 pickup 877 pipe 878 postdrop 878 qmgr 877 trivial-rewrite 878 virtual 878 таблица поиска 881 управление доступом 885 утилита mailq 878 newalises 878 postalias 878 postcat 878 postconf 878 postfix 878 postmap 878 postsuper 878 утилита sendmail 878 файл main.cf 879 master.cf 879 шифрование 887 R Red Hat сетевое конфигурирование 532 s Sendmail, почтовый агент 821 база доступа 837, 839 безопасность 843 библиотека libmilter 838, 841 группы очередей 849 журнальная регистрация 854 изменение корневого каталога 847 макрос DOMAIN 831 FEATURE 831 MAILER 831 MAIL_HUB 834 MASQUERADEAS 834 OSTYPE 830 RELAY-DOMAIN 839 RELAY_DOMAIN_FILE 839 SMART_HOST 834 направление почты в программу 805, 845 в файл 804, 845 обработка недоставленных сообщений 850 опции безопасности 846 очередь сообщений обработка 850 права доступа 844 производительность 849, 850 псевдонимы 805 хешированная база данных 806 разбивка конвертов 849 режим доставки 849 ретрансляция 837, 838 спам дроссели 837 черные списки 837 специальные пользователи 843 списки рассылки 804, 806 средство blacklist_recipients 839 local_lmtp 845 relay_entire_domain 839 relay_hosts_only 839 smrsh 845 статистика работы 853 утилита smrsh 845 vacation 846 функциональная возможность access_db 832 always_add_domain 832 ldap_routing 833 redirect 831 use_cw_file 831 virtusertable 832 T TCP/IP IP-адрес 503, 505 альтернативный 504 в стандарте IPv6 511 выделение 509 групповой 504 классы 505 маска подсети 506 назначение компьютеру 525 направленный 504 подмена 521 сетевой 508 типы 504 частный 510 широковещательный 504, 508, 527 кадр 500 канальный уровень
Предметный указатель 12S параметр MTU 501 пакет 500 адресация 502 поле TTL 913 порт 504 сегмент 500 сетевая модель 498 U URL 1002 W WinPrinter 1119 А Автозагрузчик 351 Агент MSA 790 Администратор объектных данных 480 Алгоритм Comletely Fair Queuing 1176 Deadline 1176 NOOP 1176 аутентификации CHAP 327 Алшлритм LRU 1169 Анализатор пакетов 591, 921, 922 Архитектура 436 Аутентификатор 867 Б Безопасность системы 46 Библиотека curses 246 libvirt 1040 OpenSSL 898 Бит setgid 148,165,197 setuid 148, 165, 197 выполнения 197 дополнительный 198 записи 197 поиска 197 режима 196 чтения 197 Брандмауэр 978, 981 безопасность 981 фильтрация пакетов на уровне служб 979, 980 с учетом состояния 985 В Веб-сервер TUX 1011 распределение нагрузки 1006 Веб-хостинг 1001,1011 Виртуализация 1029 автономная 1029 естественная 1031 полная 1029 Виртуальная частная сеть 522, 988, 989 Виртуальный интерфейс 1012,1015 конфигурирование 1013 Выпуск 435 Выражение регулярное 77 Г Гипервизор 1029 Группа DMTF 460 томов 267 д Дамп памяти 167 Дейтаграмма 500 Делегирование некорректное 722 Демон agetty 1217 automount 758 таблица назначений 758 cron 64, 330, 773 crond 335 cupsd 1082 errdemon 402 gated 570 getty 1217 конфигурирование 1221 httpd 69, 390,1011 inetd 141, 770 in.ftpd 227 init 120,130,167,1217 уровни выполнения 1219 ISC Cron 334 klogd 401 lockd 739 ipd 1105,1107 опция -1 1100 Ipsched 1089,1090,1091 mgetty 1217 mingetty 1217 mysqld 390 named безопасность 689 журнальная регистрация 655, 712, 717 начальный каталог 646 обработка запроса 602 уровни отладки 716 флаг-d 717 nmbd 1188 nscd 785 rquotad 743 smartd 277 smbd 1188 snmpd 931 sshd 770,973,1182 регистрация без пароля 62 statd 739 stunnel 976 syslogd 394, 405 udevd 195, 468 Upstart 136,1221 uugetty 1217 vixie-cron 334 winbind 1203 xend 1036 xinetd 770 ypbind 783 ypserv 783 Дескриптор файла 72,102 Динамическая миграция 1032,1038 Директива 477 Диск Blu-Ray 348 CD 347
1294 Предметный указатель DVD 347 SSD 348 Дисковая квота 743 Диспетчер дисплеев gdm 1057 kdm 1057 xdm 1057 Дистрибутив Linux CentOS 50 Debian 50 Fedora 50 Gentoo 50 Linux Mint 50 Mandriva 50 OpenSUSE 50 Oracle Enterprise Linux 50 PCLinuxOS 50 Red Flag 50 Red Hat Enterprise 51 Slackware 51 SUSE Linux Enterprise 51 Ubuntu 51 Дистрибутив UNIX AIX 53 HP 53 Solaris 53 Документация man-страницы 57 локальная 46 серия RFC 497 справочные страницы 56 Домен 611 Допустимое время восстановление 346 Допустимый уровень восстановление 346 Драйвер 466 md 289 терминала 1222 Дуплексор 1119 Ж Жесткий диск 256 3 Загрузка AIX 138 HP-UX 137 Red Hat 133 Solaris 139 SUSE 135 Ubuntu 136 мультисистемная 127 начальная 119 Загрузчик начальный 121 универсальный 125 Запись загрузочная главная 124, 279 связующая 639, 640 управления доступом 203 Зеркальное отражение 284 Зона тупиковая 640 И Идентификатор группы 147,165 реальный 147 сохраненный 147 текущий 147 пользователя 147,165 реальный 147 сохраненный 147 текущий 147, 165 файловой системы 147 процесса 164 родительского процесса 164 Имя пользователя 220 регистрационное 220 Инициализация пользователей 44 Инкапсуляция 500 Инсталляция программ 45 Инструмент DNSSEC Idns 707 Sparta 708 Vantages 709 Интернет документация 497 провайдеры 496 число пользователей 495 Интерпретатор bash 47 sh 47, 330 Интерпретатор команд метасимволы 1225 Интерфейс АТА 260 Fibre Channel 260 FireWire 260 РАТА 260, 261 SAS 265 SATA 260, 262 SCSI 260, 262 USB 260 виртуальный 1012 внутренний 1077 обратной связи 505, 514, 559 К Канал именованный 195 Карта 781 Каталог 193 /bin 190,191 /boot 191 /boot/vmlinuz 466 cf/cf 826 cf/feature 827 cf/ostype 827 /dev 146, 190, 191, 466 /devices 468 drivers/net 475 /etc 190,191, 234, 334 /etc/bacula 370 /etc/cron.d 334 /etc/cups 1082 /etc/cups/lpoptions 1080 /etc/default/login 239 /etc/default/passwd 239 /etc/dfs/dfstab 745 /etc/exports 745 /etc/init.d/nfs-common 744 /etc/init.d/nfs-kemel-server 744 /etc/init.d/nfs.server 744 /etc/init.d/nfsserver 744 /etc/iscsi/nodes 324 /etc/logrotate.d 392, 407 /etc/mail/cf 822 /etc/modprobe.d 1069 /etc/rc.bootc 403 /etc/rc.d/init.d/nfs 744 /etc/rc.nfs 744 /etc/security 230, 234
Предметный указатель 1295 /etc/skel 234 /etc/snmp 931 /etc/sysconfig 135 /etc/udev 468 /etc/udev/rules.d 488 /etc/XH 1057 /etc/xen 1036 /export/install 425 /home 191 /kernel 191, 476 /lib 190,191 /lib/modules/ 483 /lib/udev 468 /lib/udev/rules.d 488 /media 191 /mnt 191 network-scripts 134 /opt 191 /platform 476 /proc 178,191 /proc/sys/dev/cdrom 471 /proc/sys/fs 471 /proc/sys/kemel 471 /proc/sys/net/ipv4 471 /root 191 /sbin 190,191 /sbin/init.d/nfs.server 744 /stand 191, 466 /stand/vmunix 466 /sys 487 /tmp 190,191,279 /usr 190,191,278 /usr/bin 191, 461 /usr/include 191 /usr/kemel 476 /usr/lib 191, 461 /usr/lib64 191 /usr/lib/boot/unix 466 /usr/lib/cron 334 /usr/local 191, 457 /usr/local/etc/skel 234 /usr/newconfig/etc/mail /cf 822 /usr/samples/tcpip/sendmail /cf 822 /usr/sbin 191 /usr/share 191 /usr/share/docs 461 /usr/share/man 191 /usr/share/sendmail 822 /usr/share/sendmail-cf 822 /usr/src 191, 472 /usr/src/linux 466 /usr/tmp 191 /var 190,191,279 /var/adm 191,390,393 /var/adm/cron 334 /var/log 191,390, 393 /var/log/syslog 390 /var/spool 191 /var/spool/cron 330 /var/tmp 191 /vmlinuz 466 корневой 186 Каталоге /etc/profile.d 234 Команда accept 1095 add 326 adduser 237 arp 516, 908 backup 356 basha 234 boot 126,128 cancel 1095 cat 178 cfgmgr 327, 468 chdev 481 chfn 226 chgrp 201 chkconfig 136 chmod 196,200 chown 201 chroot 148, 960 chsh 227 cmdspecial 769 cp 193 crfs 300,305 crontab 331,333 csh/tcsh 234 cut 75 date 181 dd 364 devfsadmd 271 df 182,307, 753 disable 1096 dmesg 401 dmidecode 1163 dnskeygen 690 dnssec-keygen 690 dpkg 433 dump 356 echo 81 emacs 234 enable 1096 errclear 404 except 769 except_pat 769 expand 111 extendvg 300 find 72,126, 336,1098 finger 226 format 273, 283 fsck 123,188,305 fuser 182,188 getfacl 206 GNOME 234 gpasswd 231 grep 77 groupadd 231 groupdel 231 groupmod 231 grpck 232 halt 144 hdparm 275 head 77 help 126 hostname 525 hosts_access 964 idisk 283 ifconfig 481, 506, 526, 1013 ifdown 533 ifup 533 inetadm 141 info 59 install 768 installp 446 install-sd 444 ioo 482 iostat 1173 ipchains 982 iptables 540, 982 опция-A 983 - F 983 - i 983 - j 983 - P 983 iscsiadm 325 KDE 234 kernel 126 kill 167, 170 killall 170 klist 1204
1296 Предметный указатель less 59, 77 more 178 procwdx 179 In 193 mount 123,188, 254, 307, 751 prtconf 478 logger 394, 400 флаги монтирования 744, ps 122,173,1168 login 1217 745, 746, 747, 749, 751, psig 179 Ip 1089 752 pvcreate 293, 298 Ipadmin 1091 mtfsf 345 pwait 179 Ipc 1099 named-checkconf 644 pwdx 179 директивы 1101 named-checkzone 644 raso 482 Ipinfo 1082 ndc read 81 Ipmove 1096 инструкция dumpdb 719 reboot 126 Ipoptions 1080 notrace 717 refresh 394 Ipq 1099, 1100 reload 719 reject 1095 Ipr 1079 trace 717 renice 172 опция-# 1100 ndd 481 reset 1225 опция -h 1100 netstat 559, 915 restore 356, 359 Iprm 1099,1101 опция -n 918, 919 rm 192,193 Ipshut 1091 -r 919 rmdev 481 Ipstat 1079,1094 -s 979 rmmod 484 Is 193 newgrp 231 rndc 659 Isattr 481 Iscfg 1165 Isconn 481 newusers 243 nfso 482 nfsstat 755 mdc-confgen 659 root 126 route 514, 529 Isdev 481 Isof 182,1174 Isparent 481 nice 172 nmap 961 опция-0 962 no 482 nroff 58 nsupdate 685 odmadd 481 директива add 536 rpm 432 rpmbuild 432 Ivchange 297 sar 922 Ivcreate 299 Ivdisplay 296 Ivextend 299 schedo 482 scp 973 sd 444 Ivlnboot 300 machinfo 1165 mail.local 845 mail/mailx 234 odmchange 481 odmcreate 481 odmdelete 481 odmdrop 481 setfacl 206 setserial 1215 sg_format 273 sh 234 make_depots 427 odmget 481 odmshow 481 share 745 man 57 mdadm 289 passwd 57 pcred 179 pfiles 179 shareall 422 showmount 751 mediainit 273 messages 382 shutdown 120,143 smbcontrol 1199 mii-tool 528 pgrep 170 smbstatus 1199 mkdev 481 ping 909 smrsh 845 mkfs 300,305 pkg 443 sort 75 mk_kemel 480 mklv 300 pkill 170 pldd 179 special 769 ssh 973 ssh-keygen 973 startx 1057 status 382 mknod 468 mksf 468 mkswap 310 pooladm 1043 poolcfg 1044 printf 81 mkuser 240 proccred 179 strace 179 mkvg 293,300 modify 326 procfiles 179 procldd 179 stty 1223 • опция-a 1224 modinfo 479, 485 procsig 179 clocal 1213 modprobe 485 procwait 179 erase 1223
Предметный указатель 1297 опция sane 1225 tabs 1223 su 755 svcadm 141 svc.configd 141 swacl 444 swagentd 444 swap 310 swapon 310 swask 444 swconfig 444 swcopy 444 swinstall 65, 444 swjob 444 swlist 444 swmodify 444 swpackage 444 swreg 444 swremove 444 swverify 444 sysctl 470 sysdef 479 taH 77 tar 357,363 tcpdump 923 tee 77 telinit 120,131 опция-q 1221 telnet 573,1003 top 181 topas 1168 traceroute 911, 912 truss 179 tset 1224 tune2fs 303 tusc 179 udevadm 487 ufsdump 356 ufsrestore 356 umount 188,308, 753 uniq 76 uptime 181 useradd 237 usermod 229 vipw 233 virsh 1040 visudo 158 vi/vim 234 vmo 482 wbinfo 1204 wc 76 whereis 63 which 63 xdpyinfo 1072 xhost 1060 ypmake 782 yppush 782 zfs 312 zpool 312 zypper addrepo 442 zypper dist-upgrade 442 zypper info 442 zypper install 442 zypper list-updates 442 zypper modifyrepo 442 zypper refresh 442 zypper remove 442 zypper repos 442 zypper search 442 zypper shell 442 zypper update 442 Командная оболочка bash 74 Коммутатор 584 Коммутационный тестер 1226 Компонент 435 Концентратор 583 Копирование резервное 45 Криптографическая защита 970 Л Ленточные библиотеки 351 Ленточный массив 351 Локализация 454 М Магнитная лента 349 AIT 350 DAT 349 DDS 349 DLT/S-DLT 349 LTO 351 SAIT 350 Мандатное управление доступом 969 Манифест 141 Маршрутизатор 585, 868 Cisco 572 Маршрутизация 513, 558, 559, 567 автономная система 564 динамическая 514 метрика стоимости 563 от источника 520 перенаправление пакетов 520 протоколы 561, 564 внешние 564 внутренние 564 дистанционно-векторные 562 состояния канала 563 топологические 563 стандартный маршрут 560 статическая 514, 529 таблица 575 проверка 918, 919 Массив RAID 267,283 Менеджер udev 488 логических томов 267,293 Метасимволы 54,1225 Механизм fork 121 Многопоточность 164 Модель CIM 460 NIS 781 принудительной рассылки 767 рассылки по запросу 767 Модем кабельный 589 Модуль FastCGI 1005 аутентификации 752 Мониторинг системы 45 н Накопитель 267 USB 310 Неэкранированная витая пара 580
1298 Предметный указателе 0 Перезагрузка 142 Переменная среды Облачные вычисления 1150 PAGER 57 Обратная рассылка спама SHELL 1225 810 TERM 1224 Организация Перехват сигнала 168 CAIDA 511 Печать CERT 993 журналошибок 1105 DMTF 927 система LPD IANA 631 команды 1089,1093,1099 ICANN 496, 509 файл учета 1105 IETF 496 фильтр IGF 496 входной 1106 ISC 517 выходной 1106 ISO 581 Платформа ISOC 496 KVM 1039 SANS 994 Хеп 1035 TIA 580, 592 Подкачка 310 Осветительная арматура Подключение 1132 аппаратных средств 44 Открытая система Подписание Bro 964 двойное 707 OSSEC 966 Пользователь Snort 965 nobody 161, 742 Очередь root 147,390, 954 печати 1077 в NFS 742 почтовая sys 161 /var/spool/clientmqueue 824 Порт /var/spool/mqueue 824 последовательный 1210 аппаратная несущая 1213 п контроль передачи данных 1213 Пакет нуль-модемный кабель apt-mirror 440 1211 depot 65 параметры 1215 findutils 63 программная несущая 1213 IPFilter 985 разъем DB-9 1211 MKS Toolkit 1186 DB-25 1209 PGP 972 RJ-45 1212 RRDtool 933 стандарт RS-232 1209 Samba 1188 типИСЕ 1209 sentrytools 407 DTE 1209 smartmontool 277 файлы устройств 1214 Stunnel 976 Поток wget 66 выполнения 164 Wireshark 924 Правило 488 Паравиртуализация 1029 Предварительная Пароль 951 публикация 707 DES 153 Препроцессор устаревание 953 т4 825 Передача зоны 683 Приоритет процесса 166 Программа adduser 330 amavisd-agent 819 amavisd-nanny 818 amavisd-new 816 Apache виртуальные интерфейсы 1015 запуск 1011 инсталляция 1009 конфигурирование 1010 Bacula 367 Berkeley DB 806 Cacti 933 chage 953 dd 340, 1037 GRUB 125 KeePass 160 LISTSERVLite 807 login 148 Maildrop 791 MailScanner 815 MRTG 933 Nessus 962 OpenSSH 973 oprofile 1176 procmail 889 procmail 791 savelog 407 sendmail 134, 813 smbclient 1194 smitty 247 SpamAssassin 811, 889 Squid инсталляция 1020 virt-install 1040 VMware 1184 Wine 1184 xterm 1186 yum 434 Проект 389 Directory Server 778 OpenLDAP 776 Прокси-сервер 1016,1018 Протокол ARP 498, 503, 515 BGP 563, 568 ВООТР 426, 518 CIDR 506, 508
1редметный указатель 1299 DHCP 426,516, 517, 518, 524 агент ретрансляции 518 пакет ISC 518 EIGRP 562, 566 ESMTP 791 FTP 979 HTTP 1003 версия 1.1 1012 ICMP 498 директивы переадресации 575, 520,561 широковещательные пакеты 527 ICP 1019 IGMP 504 IGRP 566 IMAP 792 IP 498 фрагментация пакетов 502 IPSEC 522, 989 IPv6 адресация 577 поддержка в BIND 632 iSCSI 326 IS-IS 567 Kerberos 249,1202 LDAP 247, 773, 833 NetFlow 937 OSPF 566 POP 792 PPP 523 PXE 414 RDP 1184 RIP 562, 565 SASL 843, 848 SMTP 791, 795 SNMP 926, 928 агент NET-SNMP 931, 932 база MIB 928 MIB-II 929 RMON 930 групповое имя 930 дистанционный мониторинг 930 идентификаторы объектов 928 операции 930 прерывание 930 SSL 843, 1016 TCP 498 использование в NFS 753 TLS 848,1016 Director 376 UDP 498 FilSet 374 использование в NFS 753 Job 375 VNC 1184 Messages 378 WEP 588 Pool 373 Xll 1182 Shedule 373 аутентификации Storage 373,376 Kerberos 752 Роль 150 сетевой 1077 Руткит 957 Профиль 141 Процесс 163 с khubd 722 kjoumald 722 Сектор 279 ksoftirqd 722 Серверная виртуализация kswapd 722 1147 sched 727 Серия svc.startd 142 ВСР 498 зомби 777 FYI 498 Псевдопользователь 160, 224 STD 498 Псевдотерминал 1216 Сеть Псевдоустройство 467 DSL 589 Путь беспроводная абсолютный 186 стандарт Bluetooth 588 относительный 186 локальная виртуальная 585 р отладка 590 поиск неисправностей 908 Раздел 267 проектирование 593 Распознаватель прокладка кабелей 597 открытый 688 управление 594, 907 Регистрация в системе 7277 хранения данных 321 Редактор Сигнал 147,167 ed 77 BUS 168 emacs 47, 71 CONT 168 gedit 46 HUP 168,394 nano 47 INT 168 vi 47, 71 KILL 168 vim 47 QUIT 168 Режим SEGV 168 восстановления 120 STOP 168 однопользовательский 120 TERM 168 AIX 129 TSTP 168 GRUB 128 USR1 168 HP-UX 729 USR2 168 SPARC 128 WINCH 168 профилактический 120 Система Ресурс AIX 429 Autochanger 377 BSD UNIX 49 Catalog 373 FreeBSD 49 Client 374 Ignite-UX 426 Device 376 Linux 48, 431
1300 Предметный указатель NetBSD 49 OpenBSD 49 TCP/IP 495 Ubuntu 433 X Window 1055 аутентификации Kerberos 971 SSH 972 диагностическая Mantis 1239 OTRS 1239 загрузочная PXE 413 PXELINUX 414 конфигурирования LCFG 459 Template Tree 2 459 криптографическая ADSP 814 DKIM 814 DomainsKeys 814 печати BSD 1098 CUPS 1078 System V 1093 управления версиями Git 450 Subversion 448 управления пакетами Software Distributor 444 yum 441 Zypper 441 Система регистрации Rsyslog 401 SDSC Secure Syslog 400 Syslog 393 Syslog-ng 400 Системный вызов fcntl 739 flock 739 fork 166 ioctl 467 lockf 739 socket 195 sync 304 time 181 wait 167 write 181 Служба Active Directory 248, 1200 Automated Installer 421 cryptosvc 141 JumpStart 421 Nagios 934 Red Hat Network 434 SSH 141 utmp 141 поддержки 1270 Сокет локальный 195 Спам 808 Список NFSv4ACL 210 POSIX ACL 206 белый 811 серый 810 управления доступом 152, 203 черный 812 Справочная система Texinfo 58 Справочная страница 43, 56 Среда GNOME 1073 KDE 1073 MAC 151 OpenBootPROM 128 Среднее время до отказа 345 Средство Syslog auth 395 authpriv 395 cron 395 daemon 395 ftp 395 kern 395 localO-7 395 Ipr 395 mail 395 mark 395 news 395 syslog 395 user 395 uucp 395 Ссылка жесткая 193 мягкая 193 символическая 195 Стандарт Common Criteria 993 FHS 461 ISO 27002 992 PCIDSS 992 POSIX 151 RS-232C 1209 SMART 277 шифрования DES 153 Стандартный канал STDERR 72 STDIN 72 STDOUT 72 Стек 956 Стойка 1138 Страница 163 Страничный обмен 1169 Суперблок 304 Суперпользователь 147, 954 в NFS 742 Схема четности 284 Сценарий crfs 300 /etc/init. d/serial 1215 /etc/init.d/setserial 1215 /etc/rc.d/rc.sysinit 1216 MLN 1035 rc.tcpip 139 XSession 1058 запуска 123 T Таблица разделов GUID 282 Тепловая нагрузка 1133 Терминал VT100 1221 драйвер 1222 конфигурирование 1216, 1223, 1224 специальные символы 1222 устранение проблем 1225 Терморегуляция 1131 Тестирование 456 Технология DKIM 893 РАМ 152 SPF 794 Том логический 267 физический 293 Точка доверия 653 монтирования 187
Предметный указатель Туннель IPSEC 989 защищенный 988 У Управление выпусками 1270 доступом 150 AIX 151 HP-UX 151 SELinux 151 Solaris 150 на основе ролей 150 принудительное 151 изменениями 1270 инцидентами 1270 конфигурацией 1270 проблемами 1270 учетными данными 249 Управляющий терминал 166 Уровень важности alert 396 crit 396 debug 396 emeig 396 err 396 info 396 notice 396 warning 396 Уровень выполнения 1219 Утилита Amanda 383 apt-get 437, 440 /bin/mail 789 cfdisk 282 cfengine 458 debconf 418 dkim-filter 894 dkim-genkey 894 dkim-stats 894 dkim-testkey 894 dkim-testssp 894 domainname 783 dump 340 fdisk 253 gparted 253, 282 gzip 58 kcweb 480 Kickstart 415 kprinter 1087 Idapsearch 779 logcheck 407, 408 logrotate 392, 405, 407 Isof 189 make 472 makedbm 783 Mondo Rescue 384 nfcapd 937 nfdump 937 NfSen 937 nim 430 nimclient 430 nim_clients_setup 430 nim_master_recover 430 nim_master_setup 430 nim_update_all 430 nmon 1175 parted 253,282 pkgutil 64 pr 1111 prstat 177 pwconv 229 rdist 767 rsync 384, 770 sar 1174 sfdisk 253 share 318 sharemgr 318 star 384 sudo 156 swatch 407 swinstall 66 system-config-kickstart 415 tcpdump 923, 924 telnet 797, 909 test 85 top 177 topas 177 tusc 179 unshare 318 useradd 231 wget 64 xdd 1174 xrandr 1068 YaST 136 YaST2 417 ypbind 783 ypcat 783 ypchfn 783 ypchsh 783 _______________________130; ypinit 783 ypmakea 783 ypmatch 783 yppasswd 783 yppasswdd 783 yppoll 783 yppush 783 ypserv 783 ypset 783 ypupdated 783 ypwhich 783 ypxfr 783 ypxfrd 783 пользовательская 1077 Учетная запись nobody 161 root 147 sys 161 Ф Файл acct 138 aliases 803 auditing 138 bacula-dir.conf 370 bacula-fd.conf 370 bacula-sd.conf 370 .bash_profile 234 .bashrc 234 bconsole.conf 370 cde 138 clean* 138 cron.allow 334 cron.deny 334 crontab 330 .cshrc 234 /dev/error 403 /dev/log 394 drivers/net/Kconfig 475 drivers/net/Makefile 475 .emacs 234 errlog 403 /etc/apt/sources.list 438 /etc/crontab 334 /etc/cups/cupsd.conf 1080 /etc/cups/mime.convs 1081 /etc/cups/mime.types 1081 /etc/datemsk 229 /etc/default/security 240
1302 Предметный указатег /etc/default/useradd 238,240 /etc/dumpdates 357 /etc/filesystems 188,300,309 /егс/fstab 188, 307, 753 /etc/gettydefs 1219 /etc/gettytab 1218 /etc/group 147,225,230, 765, 784 /etc/gshadow 231 /etc/hosts 525, 765 /etc/hosts.allow 964 /etc/hosts.deny 964 /etc/inittab 1219 etc/iscsi/iscsid.conf 325 /etc/login.defs 238 /etc/logrotate.conf 407 /etc/mail/access 832 /etc/mail/aliases 235, 765 /etc/mail/local-host-names 833 /etc/mail/service.switch 822 /etc/mail/submit.cf 825 /etc/mtab 452 /etc/named.conf 686 инструкция acl 652 controls 659 include 645 key 653 logging 655, 712 options 646 server 654 trusted-keys 653 zone 656, 658 пример 663 список соответствия адресов 645 список управления доступом 652, 687 /etc/netsvc.conf 784 /etc/nsswitch.conf 220, 784, 822 .etc/pam.d/xdm 1058 /etc/passwd 147, 219, 765, 954 защита 952, 954 /etc/printcap 1103,1107 переменная af 1105 if 1106 If 1105 Ip 1105 mx 1106 of 1106 переменная rm 1106 ip 1106 rw 1105 расширения 1107 список переменных 1104 /etc/resolv.conf 605 /etc/security/crypt.conf 239 /etc/security/login.cfg 227, 230 /etc/security/passwd 220,227 /etc/security/policy.conf 239 /etc/security/user 230 /etc/services 504 /etc/shadow 123,220, 228, 765, 953 защита 952 /etc/shells 227 765 /etc/sudoers 158, 765 /etc/swapspaces 311 /etc/sysctl.conf 470, 471 /etc/syslog.conf 390,394 /etc/system 477 /etc/ttydefs 1222 /etc/ttytype 1218,1221 /etc/udev/udev.conf 488 /etc/vfstab 188 /etc/xen/xend-config.sxp 1036 .exrc/.vimrc 234 foobard.conf 452 fstab 123 .gconf 234 .gconfpath 234 gdm/kdm 1058 grub.conf 125 hpetherconf 138 init.d 129 inittab 131 .kde/ 234 ks.cfg 415 lastlog 391 .login 234 login.cfg 240 Ip 138 .mailrc 234 mailservs 138 menuJst 125 mkuser.default 240 nameservs 138 nddconf 138 netconf 138 netdaemons 138 nettl 138 network 134 nfsconf 138 passwd 803 PPD 1115 /proc/cmd 178 /proc/cmdline 178 /proc/cwd 178 /proc/environ 178 /proc/exe 178 /proc/fd 178 /proc/maps 178 /proc/root 178 /proc/stat 178 /proc/statm 178 .profile 234 profile 141 repository.db 141 sendmail 134 smb.conf 1189 Snmp* 137 snmpd.conf 931 SnmpMaster 137 sshd 138 sshd_config 141 /stand/system 480 syslog.conf 405 system 128 user 240 utmp 392 /var/adm/lastlog 229 /var/adm/ras/errlog 403 /var/cron/log 331 /var/run/utmp 954 vfstab 123 vt 138 wtmp 390 wtmpx 390 -/.Xauthority 1060 xfs 138 xoig.conf 1063 секция Device 1065 InputDevice 1066 Monitor 1065 Screen 1066 ServerLayout 1068 -/.xsession-errors 1058 блокировка 739 конфигурации 370
Предметный указатель 1303 обычный 193 переключения 822 права доступа GhtSUID 959 самозагрузки 375 устройства 194,1214 блочный 467 символьный 467 Файловая система 186 9660 185 autofs 757 Btrfs 185 ext2 302 ext3 185,302 ext4 185,302 FAT 185 JFS 185 NTFS 185 /ргос 1163 ReiserFS 185 VxFS 185 ZFS 185,365 монтирование автоматическое 757 сетевая 735 демонтирование 753 монтирование 751, 753 экспорт 738 Фактор уступчивости 172 Флеш-диск 258 Формат Maildir 792 mbox 792 Функция closelog 394 getpwent 766 getpwnam 766 getpwuid 766 openlog 394 syslog 394 Э Экологическая пирамида 1144 Электронная почта 798 агент доставки 789, 791 доступа 789, 792 пользовательский 788, 789 представления 790 транспортный 789, 791 почтовые псевдонимы 802 сообщение заголовки 793 маршрутизация 627 структура 793 хранилище 792 стандарт MIME 789 Электронное оборудование 1132 Электропитание 1135 Я Ядро 121, 464 безопасность 540 конфигурирование на почтовом сервере 851 Язык expect 47 PCL 1112 PDF 1113 Perl 47, 96 PJL 1114 PostScript 1112 Python 108 Python 47 Ruby 47 XPS 1113 X Хеш 99 Ц Центр распределения ключей 1202
Системное администрирование UNIX/LINUX "Как автор, редактор и издатель, я никогда не придавал большого значения конкуренции — за исключением нескольких случаев. Это один из таких случаев. UNIX System Administration Handbook — это одна из немногих книг, на которые мы равняемся". — Тим О'Рейли (Tim O'Reilly), основатель компании O'Reilly Media (из предисловия) Данное издание, появившееся в год, когда исполняется 20 лет со дня появления мирового бестселлера по системному администрированию UNIX, стало еще лучше благодаря описанию распространенных вариантов системы Linux: Ubuntu, openSUSE и RHEL. Системное администрирование в книге рассматривается с практической точки зрения. Она представляет собой бесценный справочник как для начинающих администраторов, так и для опытных профессионалов. В ней подробно описываются эффективные методы работы и рассматриваются все аспекты системного администрирования, включая управление памятью, проектирование и управление сетями, электронную почту, веб-хостинг, создание сценариев, управление конфигурациями программного обеспечения, анализ производительности, взаимодействие с системой Windows, виртуализацию, DNS, безопасность, управление провайдерами IT-услуг и многое другое. В данной книге отражены текущие версии следующих операционных систем. • Ubuntu®Linux openSUSE® Linux Red Hat® Enterprise Linux soiaris Oracle America® Solaris™ (бывший Sun Solaris) HP HP-UX® IBM AIX® "Эта книга увлекательна и полезна как справочник. Если вы используете системы UNIX и Linux, она должна стать вашей настольной книгой. В ней кратко и без лишних разглагольствований написано об истории этих систем. Она содержит точную информацию, которая излагается в яркой и запоминающейся форме". — Джейсон А. Наннелли (Jason A. Nunnelley) "Это всесторонний справочник о том, как обслуживать и поддерживать работоспособность систем UNIX и Linux. Авторы излагают факты, сопровождая их практическими советами и реальными примерами. Их точка зрения на различия между системами представляет ценность для всех, кто работает в неоднородных вычислительных средах". — Пат Парсегян (Pat Parseghian) ВИЛЬЯМС Издательский дом "Вильямс' www.williamspublishing.com • •PRENTICE HALL ф Pearson Education 9 785845917409

О книге «Unix и Linux. Руководство системного администратора»

Системное администрирование в книге рассматривается с практической точки зрения. Она представляет собой бесценный справочник как для начинающих администраторов, так и для опытных профессионалов. В ней подробно описываются эффективные методы работы и рассматриваются все аспекты системного администрирования, включая

— управление памятью, — проектирование и управление сетями, — электронную почту, веб-хостинг, — создание сценариев, — управление конфигурациями программного обеспечения, — анализ производительности, взаимодействие с системой Windows, — виртуализацию, DNS, — безопасность, — управление провайдерами IT-услуг и многое другое.

В данной книге отражены текущие версии следующих операционных систем: — Ubuntu Linux; — openSUSE Linux; — Red Hat Enterprise Linux; — Oracle America SolarisTM (бывший Sun Solaris); — HP HP-UX; — IBM AIX.

Книга будет чрезвычайно полезной всем системным администраторам, а также пользователям систем UNIX и Linux, студентам, преподавателям и специалистам по сетевым технологиям.

«Как автор, редактор и издатель, я никогда не придавал большого значения конкуренции — за исключением нескольких случаев. Это один из таких случаев. UNIX System Administration Handbook — это одна из немногих книг, на которые мы равняемся.» — Тим О’Рейли (Tim O’Reilly), основатель компании O’Reilly Media (из предисловия).

«Эта книга увлекательна и полезна как справочник. Если вы используете системы UNIX и Linux, она должна стать вашей настольной книгой. В ней кратко и без лишних разглагольствований написано об истории этих систем. Она содержит точную информацию, которая излагается в яркой и запоминающейся форме. «- Джейсон А. Наннелли (Jason A. Nunnelley).

«Это всесторонний справочник о том, как обслуживать и поддерживать работоспособность систем UNIX и Linux. Авторы излагают факты, сопровождая их практичными советами и реальными примерами. Их точка зрения на различия между системами представляет ценность для всех, кто работает в неоднородных вычислительных средах.» — Пат Парсегян (Pat Parseghian).

На нашем сайте вы можете скачать книгу «Unix и Linux. Руководство системного администратора» Эви Немет, Гарт Снайдер, Хейн Трент Р., Бэн Уэйли в формате pdf, читать книгу онлайн или купить книгу в интернет-магазине.

Понравилась статья? Поделить с друзьями:
  • Пимафукорт мазь инструкция по применению цена отзывы для детей
  • Мануал для yamaha tdm 850
  • Вюи фсин россии официальный сайт руководство
  • Руководство по ремонту двигателя ваз 11183
  • Что такое система коллективного руководства при брежневе