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

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

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

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

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

Прочитали: 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). Наконец, в этой книге делается акцент на администрировании корпоративных сер­веров и сетей, т.е. на серьезной теме системного администрирования. Несложно установить операционную систему на отдельном компьютере, гораздо труднее поддерживать устойчивую работу виртуализированной сетевой среды при больших нагрузках, сбоях в работе дисков и умышленных атаках. Поэтому мы описываем методы и практические способы, которые позволят вам “поднимать” “упавшие” сети, а также выбирать решения, которые останутся актуальными при расширении и усложнении вашего сайта и из­менении его гетерогенности. Мы не претендуем на абсолютную степень объективности в решении перечисленных выше задач, поэтому по ходу изложения постарались максимально ясно пояснить свои субъективные взгляды и предпочтения. Особенность системного администрирования заключается в том, что опытные администраторы могут иметь совершенно разные пред­ставления о правилах и процедурах управления системами. Читателям придется само­стоятельно решать, какой именно материал и в какой степени соответствует той среде, в которой они работают.

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 НАПИСАНИЕ СЦЕНАРИЕВ ДЛЯ ОБОЛОЧКИ .

.

sв

Оболочка 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. испол ьзуются диски или раздел ы сопостави­ мого размера. Хотя в конкретной реализаци и с исте м ы 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