Evi Nemeth
Garth Snyder
Trent R. Hein
Веп Whaley
DanMackin
with James Garnett, Fabrizio Branca, and Adrian Mouat
Boston • Columbus • lndianapolis • New York • San Francisco • Amsterdam •Саре Town
Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City
Sao Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
UNIXИLINUX
РУКОВОДСТВО
СИСТЕМНОГО
АДМИНИСТРАТОРА
----
5-еиздание
----
ЭвиНемет,
Гарт Снайдер,
ТрентХейн,
Бэн Уэйли,
ДэнМакин
при участии Джеймса Гарнетта, Фабрицио Бранка и Адриана Муата
Москва
•
Санкт-Петербург
2020
ББК
32.973.26-018.2.75
Н50
УДК
681.3.07
ООО "Диалектика"
Зав. редакцией С.Н. Тригуб
Перевод с английского и редакция докт. физ.-мат. наукД.А. Клюшина
По общим вопросам обращайтесь в издательство "Диалектика" по адресу:
Linux: руководство системною администратора, 5-е изд.:
: ООО "Диалектика", 2020. - 1168 с. : ил. - Парал. тит. англ.
ISBN 978-5-907144-10-1 (рус.)
Пер. с англ.
-
СПб.
ББК
32.973.26-018.2.75
Все названия про11Jаммных продуктов являются зарегистрированными торговыми марками со
ответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой
бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические,
включая фотокопирование и запись на магнитный носитель, если на это нет письменного разре
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. Методология, политика и стратегии
Глава
Глава
Краткая история системного администрирования
Предметный указатель
1.1. Основные обязанности системного администратора
Управление доступом
Добавление оборудования
Автоматизация задач
Управление резервными копиями
Установка и обновление программного обеспечения
Мониторинг
Исправление проблем
Ведение локальной документации
Бдительный мониторинг безопасности
Настройка производительности
Разработка правил
Работа с поставщиками
Тушение пожаров
1.2. Предварительный опыт
1.3. Дистрибутивы Linux
1.4. Примеры систем, используемых в этой книге
Примеры дистрибутивов Linux
Пример дистрибутива UNIX
1.5. Обозначения и типографские соглашения
1.6. Единицы измерения
1.7. Маn-страницы и другая онлайн-документация
Организация mаn-страниц
Команда man: чтение страниц интерактивного руководства
Хранение страниц интерактивного руководства
1.8. Другая официальная документация
Руководства по конкретным системам
Документация по конкретным пакетам
45
45
45
45
46
46
46
46
46
47
48
49
50
51
52
53
54
54
55
55
56
56
56
7
Содержание
57
57
57
Книги
Документы
1. 9. Другие
RFC
источники информации
58
58
59
Сохранение актуальности
Практические руководства и справочные сайты
Конференции
1.1 О.
1.11.
1.12.
Способы поиска и установки программного обеспечения
Как определить, установлено ли программное обеспечение
Добавление нового программного обеспечения
61
Создание программного обеспечения из исходного кода
63
Установка с помощью веб-сценария
64
65
66
Где разместить программное обеспечение
Специализация и смежные дисциплины
Методология
66
DevOps
Инженеры по надежности сайтов
66
Инженеры по безопасности
66
Сетевые администраторы
66
67
67
67
67
67
68
68
Администраторы баз данных
Инженеры центра сетевых операций
Технические специалисты центров обработки данных
Архитекторы
1.13. Литература
Системное администрирование и методология
Важные инструменты
Глава
2.1.
2.2.
60
60
2.
Загрузка и системные демоны
Обзор процесса загрузки
Системные прошивки
BIOS
или
BIOS
UEFI
2.3. Загрузчики
2.4. GRUB: универсальный загрузчик
Конфигурация GRUB
Командная строка GRUB
Параметры ядра Linux
2.5. Процесс загрузки FreeBSD
Вариант BIOS: bootO
Вариант UEFI
Конфигурация загрузчика
Команды загрузчика
69
69
70
71
UEFI
Устаревший интерфейс
2.6. Демоны
DevOps
loader
управления системой
Обязанности демона
ini t
ini t
Традиционный стиль ini t
Менеджер systemd против
Аргументы против ini t
Реализации демона
остального мира
72
72
74
74
74
76
76
77
77
78
78
79
79
80
80
81
82
82
содержание
8
2.7.
Менеджер
systemd
в деталях
Модули и модульные файлы
Команда
systemctl:
управление менеджером
systemd
Состояние модуля
Цели
Зависимости между модулями
Порядок выполнения
Более сложный пример файла
Локальные службы и настройки
Предостережения об управлении службами и запуском
Журнал
2.8.
2.9.
systemd
Сценарии инициализации и запуска системы
FreeBSD
Процедуры перезагрузки и выключения
Выключение физических систем
Выключение облачных систем
2.1 О.
Что делать, если система не грузится?
Однополъзовательский режим
FreeBSD
Однополъзовательский режим с загрузчиком GRUB
Восстановление облачных систем
Глава
3. Управление доступом и привилегии суперпользователя
Стандартное управление доступом в
UN IX
Контроль доступа к файловой системе
Владение процессом
Учетная запись суперпользователя
root
setuid и setgid
3.2. Управление учетной записью root
Вход в учетную запись root
Команда su: замена идентификатора пользователя
Программа sudo: ограниченный вариант команды su
Отключение учетной записи root
Системные учетные записи, отличные от root
3.3. Расширения стандартной модели контроля доступа
Установка флагов
Недостатки стандартной модели
РАМ: подключаемые модули аутентификации
KerЬeros: сетевая криптографическая аутентификация
Списки управления доступом к файловой системе
Возможности
Linux
Пространства имен
3.4.
Linux
Современный контроль доступа
Отдельные экосистемы
Обязательный контроль доступа
Контроль доступа на основе ролей
SELinux: улучшенная безопасность Linux
AppArmor
3.5. Литература
ls: просмотр атрибутов файла
chmod: изменение прав доступа
Команды chown и chgrp: смена владельца и группы
Команда umask: задание стандартных прав доступа
Дополнительные флаги в системе Linux
Команда
ACL
ACL в системе Linux
Поддержка ACL в системе Free BS D
Обзор POSIX ACL
Списки NFSv4 ACL
Глава
6.1.
6.
177
178
181
Инсталляция и управление программным обеспечением
Инсталляция операционных систем
Загрузка по сети на персональном компьютере
Настройка РХЕ
187
188
188
189
Использование
Kickstart - автоматизированного
Red Hat и CentOS
Автоматизированная инсталляция систем Deblan и Ubuntu
инсталлятора
6.2. Управление пакетами
6.3. Системы управления пакетами для Linux
Команда rpm: управление пакетами RPM
Команда dpkg: управление пакетами . deb
6.4. Использование высокоуровневых систем управления
пакетами в системе Linux
Хранилища пакетов
АРТ: усовершенствованное средство управления пакетами
Настройка конфигурации хранилища
Пример файла
/etc/apt/sources.list
Создание локального зеркала хранилища
Автоматизация работы системы АРТ
Система yum: управление выпусками для
6.5. Управление
RPM
программным обеспечением в системе
FreeBSD
Базовая система
Менеджер пакетов
pkg в системе
FreeBSD
Коллекция портов
6.6. Локализация и
настройка конфигурации программного обеспечения
Организация локализации
Структурные изменения
Ограничение количества ныпусков
Тестирование
6.7. Литература
Глава
7.1.
7.
Сценарии и командная оболочка
Основы сценариев
Создание микросценариев
Хорошо изучите несколько инструментов
Автоматизируйте все, что возможно
Основы работы с оболочками
Редактирование команд
Каналы и перенаправление потоков
Использование переменных и кавычек
Переменные окружения
Команды фильтрации
7.3.
Написание сценариев дr1я оболочки
sh
Выполнение
От команд к сценариям
Ввод и вывод данных
Пробелы в именах файлов
Функции и аргументы командной строки
Поток управления
Циклы
Арифметика
7.4.
Регулярные выражения
Процесс сопоставления
Литеральные символы
Жадность, леность и катастрофический поиск с возвратом
7.5.
Программирование на языке
Python
Страсти по
Python 3
Python 2 или Python 3?
Краткое введение в язык
Python
Объекты, строки, числа, списки, словари, кортежи и файлы
Пример проверки ввода
Циклы
7.6.
Программирование на языке
Ruby
Инсталляция
Краткое введение в язык
Ruby
Блоки
Символы и хеши опций
Регулярные выражения в языке
Язык
7. 7.
Ruby
Ruby как фильтр
Управление библиотекой и средой дr1я
Python
и
Ruby
Поиск и установка пакетов
Создание воспроизводимых сред
Несколько сред
7.8.
Контроль версий с помощью системы
Простой пример
Ловушки
Git
Git
Git
Коллективное кодирование с помощью системы
Git
269
269
12
Содержание
7.9. Литература
271
271
271
272
272
Оболочки и сценарии оболочки
Регулярные выражения
Python
Ruby
Глава
8.
Управление учетными записями пользователей
8.1. Основы управления учетными
8.2. Файл /etc/passwd
записями
Регистрационное имя
Зашифрованные пароли
Идентификатор пользователя
Идентификатор группы по умолчанию
Поле GECOS
Домашний каталог
Регистрационная оболочка
8.3.
8.4.
Файлы
/etc/shadow
/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 в системах Deblan и Ubuntu
Команда adduser в системе FreeBSD
Команда newusers в системе Linux: добавление
Системы "единого входа"
Системы управления учетными данными
Глава
9.
Облачные вычисления
9.1. Облако в контексте
9.2. Выбор облачной платформы
Публичные, частные и гибридные облака
287
289
289
290
290
291
292
292
пользователей пакетом
8.8. Безопасное удаление учетных записей пользователей и
8.9. Блокирование регистрационных имен пользователей
8.10. Уменьшение риска с помощью модулей РАМ
8.11. Централизация управления учетными записями
Протокол LDAP и служба Active Directory
Amazon Web Services
Goog1e C1oud P1atform
Digita\Ocean
9.3.
Основы работы с облачными службами
Доступ к облаку
Регионы и зоны доступности
Виртуальные частные серверы
Сети
Хранилище
Идентификация и авторизация
Автоматизация
9.4. Облака:
быстрый запуск VPS на платформе
Веб-службы Amazon
Интерфейс aws: управление подсистемами
AWS
Google Cloud P1atform
Digita\Ocean
9.5. Контроль затрат
9.6. Литература
Глава
10.1.
10. Журналирование
Местоположение файлов регистрации
Специальные журнальные файлы
Как просмотреть записи в журнале
systemd
10.2. Журнал systemd
Настройка журнала systemd
Добавление дополнительных параметров фильтрации для журнала
Совместное использование с системой
Sys1og
10.3. Система Sys1og
Чтение сообщений системы Sys1og
Архитектура системы Rsys1og
Версии Rsyslog
Конфигурация Rsys1og
Примеры конфигурационных файлов
Отладка системы Sys1og
10.4. Журнальная регистрация на уровне ядра и на этапе начальной загрузки
10.5. Управление журнальными файлами и их ротация
Утилита logrotate: кросс-платформенное управление журналами
Утилита newsyslog: управление журналами в системе FreeBSD
l 0.6. Управление журналами в крупном масштабе
Стек ELK
Gray1og
Журналирование как услуга
10.7.
Принципы обработки журнальных файлов
Глава
11. Драйверы и ядро
11.1. Ядра и системное администрирование
11.2. Нумерация версий ядра
Файлы и номера устройств
Проблемы управления файлами устройств
Создание файлов устройств
Управление современными файловыми системами
Управление устройствами в
Linux
Создание правил и постоянных имен
Управление устройствами в системе
11.4.
Конфигурирование ядра
FreeBSD
Linux
Конфигурирование параметров ядра
linux
Сборка ядра
Добавление драйвера устройства в
Linux
FreeBSD
Настройка параметров ядра FreeBSD
Сборка ядра FreeBSD
11.5.
Конфигурация ядра системы
11.6.
Загружаемые модули ядра
Загружаемые модули ядра в
Linux
Загружаемые модули ядра в системе
11. 7.
Загрузочные сообщения системы
Загрузочные сообщения системы
11.8.
11.9.
FreeBSD
Загрузка
Linux
FreeBSD
Загрузка альтернативных ядер в облаке
Ошибки ядра
Ошибки ядра
Linux
Паника ядра в системе
FreeBSD
11.10. Литература
Глава
12.
Печать
12.1. Система печати CUPS
Интерфейсы для системы печати
Очередь на печать
Множество принтеров
Экземпляры принтеров
Сетевая печать
Фильтры
12.2.
Управление сервером
CUPS
Настройка сетевого сервера печати
Автоматическое конфигурирование принтера
Конфигурирование сетевых принтеров
Примеры конфигурирования принтеров
Отключение принтера
Другие связанные с конфигурированием задачи
12.3.
Советы по выявлению проблем
Повторный запуск демона печати
Регистрационные журналы
Трюки и инструменты для арифметических вычислений,
связанных с подсетями
CIDR: протокол бесклассовой междоменной маршрутизации
Выделение адресов
Частные адреса и система NAT
Адресация в стандарте 1Pv6
13.5.
Маршрутизация
Таблицы маршрутизации
Директивы переадресации протокола ICMP
13.6. ARP: протокол преобразования адресов в /Pv4 и 1Pv6
13.7. DHCP: протокол динамического конфигурирования хостов
Программное обеспечение DHCP
Схема работы DHCP
Программное обеспечение DHCP, созданное организацией ISC
13.8. Вопросы безопасности
Перенаправление IР-пакетов
Директивы переадресации протокола ICMP
Маршрутизация по адресу отправителя
Широковещательные пакеты эхо-запросов и другие виды
направленных широковещательных сообщений
Подмена IР-адресов
Встроенные брандмауэры
Виртуальные частные сети
13.9.
Основы конфигурирования сети
Присвоение сетевых имен и IР-адресов
427
427
428
429
430
430
Содержание
16
Настройка сетевых интерфейсов и протокола 1Р
Настройка маршрутизации
Конфигурирование
DNS
Сетевое конфигурирование в различных системах
13.1 О.
Сетевое конфигурирование в системе
Программа NetworkManager
Команда
ip:
Linux
ручное конфигурирование сети
Сетевое конфигурирование в системе Ubuntu
Сетевое конфигурирование в системе Red Hat и CentOS
Настройка сетевого оборудования в системе Linux
Опции протокола
Linux TCP/IP
Переменные ядра, связанные с безопасностью
13.11.
Сеть FreeBSD
Команда ifconfig: настройка сетевых интерфейсов
Конфигурация сетевого оборудования в системе
FreeBSD
Конфигурирование сети во время загрузки системы FreeBSD
Конфигурирование протокола TCP/IP в системе FreeBSD
13.12. Сетевые
проблемы
Команда
Команда
ping: проверьте, работает ли хост
traceroute: трассировка IР-пакетов
Пакетные анализаторы трафика
Утилита
13.13.
tcpdump:
пакетный анализатор трафика из командной строки
Мониторинг сети
Программа
SmokePing: постепенный сбор статистики об эхо-запросах
iPerf: отслеживание производительности сети
Программа Cacti: сбор и отображение данных
13.14. Брандмауэры и система NAT
Утилита iptaЫes в системе Linux: правила, цепочки и таблицы
IPFilter для UNIХ-систем
13.15. Облачные сети
Виртуальное частное облако АWS (УРС)
Сеть на платформе Google Cloud Platform
Сеть DigitaIOcean
13.16. Литература
Программа
История
Классика
Протоколы
Глава
14.
Сетевые аппаратные средства
14.1. Технология Ethernet: сетевая
Как работает Ethemet
Топология Ethernet
панацея
Неэкранированная витая пара
Оптическое волокно
Соединение и расширение сетей
14.2.
Ethernet
Беспроводные сети: локальная сеть для кочевников
Стандарты беспроводных сетей
Доступ клиентов к беспроводной сети
Офисные точки подключения
Стандарты кабельных систем
14.6.
Проектирование сетей
Структура сети и архитектура здания
Расширение сетей
Перегрузка
Обслуживание и документирование
14.7. Управление сетью
14.8. Рекомендуемые поставщики
Кабели и разъемные соединения
Тестовые приборы
Маршрутизаторы/коммутаторы
14.9. Литература
15. IР-маршрутизация
Глава
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. \.Архитектура DNS
Запросы и ответы
Поставщики услуг DNS
16.2. DNS для поиска
resol v. conf: конфигурация
Серверы имен
Авторитетные и кеширующие серверы
Рекурсивные и нерекурсивные серверы
Записи о ресурсах
Делегирование
Кеширование и эффективность
Неоднозначные ответы и балансировка загрузки
DNS
Отладка с помощью инструментов запросов
16.5.
База данных
DNS
Команды синтаксического анализатора в файлах зон
Записи о ресурсах
Запись SOA
Записи NS
Записи А
Записи АААА
Записи PTR
Записи мх
Записи CNAME
Записи SRV
Записи тхт
Записи SPF, DКIM и DМARC
Записи о ресурсах
16.6.
DNSSEC
BIND
системы BIND
Программное обеспечение
Компоненты
Файлы конфигурации
Инструкция
include
options
Инструкция acl
Инструкция key (TSIG)
Инструкция server
Инструкция masters
Инструкция logging
Инструкция statistics-channels
Инструкция zone
Инструкция controls для команды rndc
16.7. Расщепление DNS и инструкция view
16.8. Примеры конфигурации системы BIND
Инструкция
Технология DNSSEC
Правила протокола DNSSEC
Записи о ресурсах DNSSEC
Настройка протокола DNSSEC
Генерирование пар ключей
Подписание зоны
Цепочка доверия в протоколе DNSSEC
Смена ключей DNSSEC
Инструменты
DNSSEC
DNSSEC
16. l l. Отладка сервера BIND
Отладка протокола
Журнальная регистрация на сервере
BIND
Некорректное делегирование
16.12. Литература
Книги и другая документация
Ресурсы в Интернете
Документы
RFC
17. Система единого входа
Глава
17 .1. Основные элементы системы единого входа
17.2. LDAP: "облегченные" службы каталогов
Особенности LDAP
Структура данных LDAP
OpenLDAP: традиционный LDAP-cepвep с открытым исходным
389 Directory Server: альтернативный LDAP-cepвep
с открытым исходным кодом
Создание LDАР-запросов
Преобразования файлов паролей и групп
17.3.
LDAP
Использование служб каталогов для входа в систему
Система KerЬeros
Демон sssd: служба системной безопасности
nsswi tch. conf: переключатель службы имен
Модули РАМ: украшение или чудо аутентификации?
Конфигурационный файл, построенный на основе
эталонного файла с расширением .mc
Примитивы конфигурации программы
Таблицы и базы данных
sendmail
Обобщенные макросы и функциональные возможности
Конфигурация клиентов
Параметры конфигурации препроцессора
Средства программы
Ретрансляция
sendmail
Безопасность и программа
m4
для борьбы со спамом
sendmail
Владельцы файлов
Права доступа
Безопасная пересылка почты в файлы и программы
Опции безопасности
Выполнение программы sendmail в виртуальном каталоге
(для настоящих параноиков)
Отражение атак типа "отказ от обслуживания"
безопасносный протокол транспортного уровня
Тестирование и отладка программы sendmail
Безопасность
Команды и документация системы
Конфигурация системы
Postfix
Postfix
Виртуальные домены
Управление доступом
Отладка
18.11. Литература
Литература по программе sendmail
Литература о системе Exim
Литература о системе Postfix
Документы
Глава
19 .1.
19.
RFC
Веб-хостинr
НТТР: протокол передачи гипертекста
Унифицированные указатели ресурсов
(URL)
Структура транзакции протокола НТТР
Утилита curl: инструмент командной строки для работы с НТТР
Повторное использование ТСР-соединений
НТТР на основе протокола
Виртуальные хосты
TLS
программного обеспечения для веба
Веб-серверы и прокси-сервер протокола НТТР
Балансировщики нагрузки
19.2. Основы
Кеши
Сети доставки контента
Языки веба
Интерфейсы прикладного программирования
Базовая аутентификация протокола НТТР
Ведение журнала
19.5.
Веб-сервер
NGINX
У станов ка и запуск N G INX
Настройка веб-сервера NGINX
Настройка ТLSдля
NGINX
Балансировка нагрузки с помощью
19.6.
Программное обеспечение
NGINX
HAProxy
Проверки работоспособности
Статистика сервера
Липкие сессии
Прекращение использования
TLS
19.7. Литература
111. Хранение данных
Глава 20. Дисковая память
Часть
729
20.1. Добавление диска
Рецепт для Linux
Рецепт для FreeBSD
20.2. Аппаратное обеспечение для хранения данных
Жесткие диски
Твердотельные диски
Гибридные диски
Расширенный формат и блоки по
20.3.
Интерфейс
Интерфейс
Интерфейс
Интерфейс
20.4.
4 КиБ
Интерфейсы устройств для хранения данных
SATA
PCI Express
SAS
USB
Подключение и низкоуровневое управление накопителями
Проверка инсталляции на уровне аппаратного обеспечения
Файлы дисковых устройств
Непостоянные имена устройств
Форматирование дисков и управление сбойными секторами
Безопасное стирание дисков АТ А
Команды hdparm и camcontrol: параметры диска и интерфейса
Мониторинг жесткого диска с помощью стандарта SMART
20.5.
Программное обеспечение накопителей
Отображение устройств в системе
Разбиение диска
Традиционное разбиение
Разбиение диска по схеме
MBR
GUID
Разбиение дисков в системе Linux
Разбиение дисков в системе FreeBSD
Схема
20.7.
GPT:
таблица разделов
Управление логическими томами
Управление логическими томами в системе Linux
Управление логическими томами в FreeBSD
избыточные массивы недорогих дисков
Программная и аппаратная реализации системы
20.8. RAID:
RAID
Уровни системы RAID
Восстановление диска после сбоя
Недостатки конфигурации
Команда
mdadm:
RAID 5
программное обеспечение
20.9. Файловые системы
20.1 О. Традиционные файловые
системы:
RAID
в системе
U FS, ext4 и XFS
Терминология файловых систем
Полиморфизм файловых систем
Форматирование файловых систем
Команда fsck: проверка и исправление файловых систем
Монтирование файловой системы
Настройка автоматического монтирования
Монтирование USВ-накопителя
Включение подкачки
20.11.
Файловые системы следующего поколения:
Копирование при записи
ZFS
Обнаружение ошибок
Производительность
20.12.
Файловая система
ZFS:
Linux
Архитектура ZFS
ZFS
все проблемы решены
в системе
Пример: добавление диска
Файловые системы и свойства
Наследование свойств
- одна файловая система
Один пользователь
Мгновенные копии и клоны
Неразмеченные логические тома
Управление пулом памяти
20.13.
Файловая системы
облегченная версия
Btrfs:
ZFS для Linux
Btrfs или ZFS
Настройка и преобразование хранилища
Сравнение популярных систем СМ
Терминология
Бизнес-модели
Архитектурные параметры
Параметры языка
Варианты управления зависимостями
Общие комментарии по поводу систему Chef
Общие комментарии по поводу системы Puppet
Общие комментарии по поводу систем АпsiЫе и
Salt
ОдаУАМL
23.5.
Введение в систему AnsiЫe
Пример использования системы АпsiЫе
Настройка клиента
Группы клиентов
Присваивание переменных
Динамические и вычисляемые группы клиентов
Списки задач
Параметры состояния
Итерация
Взаимодействие с
Jinja
Визуализация шаблона
Привязки: сценарии и файлы сценариев
Роли
Рекомендации по структурированию базы конфигурации
Параметры доступа в системе АпsiЫе
23.6.
us
840
841
841
842
843
843
Введение в систему
Salt
Настройка миньонов
26
Содержание
Привязка значения переменной к миньону
Сопоставление миньонов
Состояния системы Salt
Система Salt и препроuессор Jinja
Идентификаторы состояний и зависимости
Функции состояния и выполнения
Параметры и имена
Привязка состояний к миньонам
Состояния высокого уровня
Формулы Salt
Среды
Документация
23.7.
Сравнение систем AnsiЫe и
Salt
Гибкость развертывания и масштабируемость
Встроенные модули и расширяемость
Безопасность
Разное
23.8. Рекомендации
23.9. Литература
Глава
24.1.
24.
Виртуализация
Виртуальный жаргон
Гипервизоры
Динамическая миграuия
Образы виртуальных машин
Контейнеризация
24.2.
Виртуализация с помощью системы Linux
Платформа Xen
Инсталляция гостевой операционной системы на платформе
Платформа КУМ
Инсталляция гостевой операционной системы
на платформе КУМ и ее использование
24.3. Система FreeBSD bhyve
24.4. Компания VMWare
24.5. Гипервизор VirtualBox
24.6. Программа Packer
24.7. Программа Vagrant
24.8. Литература
Глава
25.1.
25. Контейнеры
Основные концепции
Поддержка ядра
Образы
Сеть
25.2. Докер:
механизм с открытым исходным кодом
Базовая архитектура
Инсталляция
Настройка клиента
Элементы безопасности
Слабые места в системе защиты
Социальная инженерия
Уязвимости в программах
Распределенные атаки типа "отказ в обслуживании"
(DDoS)
Инсайдерская информация
Ошибки конфигурации сети, системы или приложения
27.3.
Основные вопросы безопасности
Обновления программного обеспечения
Ненужные службы
Удаленная регистрация событий
Резервные копии
Вирусы и черви
Руткиты
Фильтрация пакетов
Пароли и многофакторная аутентификация
Бдительность
Тестирование приложений на проникновение
27.4.
Пароли и учетные записи пользователей
Изменение пароля
Хранилища и депоненты паролей
Устаревание паролей
Групповые и совместно используемые учетные записи
Пользовательские оболочки
Привилегированные учетные записи
27.5.
Инструментальные средства защиты
Команда
nmap:
сканирование сетевых портов
Nessus: сетевой сканер нового поколения
Metasploit: программа для выявления попыток проникновения
Lynis: встроенный аудит безопасности
John the Ripper: средство для выявления слабых паролей
Bro: программная система для распознавания вторжения в сеть
Snort: популярная программная система для распознавания
проникновения в сеть
OSSEC: система для распознавания вторжения в сеть на уровне хоста
Fail2Ban: система отражения атаки методом перебора
27.6.
Основы криптографии
Криптография с симметричными ключами
Криптография с открытым ключом
Инфраструктура с открытым ключом
Протокол защиты транспортного уровня
Криптографические хеш-функции
Генерация случайных чисел
1005
1005
1008
1008
1009
1009
1О1 О
TLS
Выбор криптографического программного обеспечения
Команда openssl
Отладка TLS-ceaнca с сервером
с отслеживанием состояния соединений
Насколько безопасны брандмауэры
27.9.
Виртуальные частные сети
Туннели
(VPN)
IPsec
Так ли уж нужны виртуальные частные сети
27.10.
Сертификаты и стандарты
Сертификаты
Стандарты безопасности
27 .11.
Источники информации по вопросам обеспечения безопасности
Сервер SecurityFocus.com и списки рассьmки
Блог Брюса Шнайера
Отчет компании
Институт
BugTraq и OSS
Verizon Data Breach lnvestigations
SANS
Информационные ресурсы отдельных дистрибутивов
Другие списки рассылки и веб-сайты
27.12. Что нужно делать в случае атаки
27.13. Литература
Глава
28.1.
28.
на сервер
Мониторинг
Обзор мониторинга
Инструментарий
Типы данных
Ввод и обработка
Уведомления
Контрольные панели и пользовательские интерфейсы
28.2.
28.3.
Культура мониторинга
Платформы мониторинга
Платформы реального времени с открытым исходным кодом
Платформы временных рядов с открытым исходным кодом
Платформы визуализации данных с открытым исходным кодом
Мониторинг сетей
Мониторинг систем
Команды для мониторинга систем
Сборщик обобщенных системных данных
Утилиты
28.7.
sysdig
и
dtrace:
collectd
трассировки выполнения
Мониторинг приложений
Мониторинг системного журнала
Supervisor + Munin:
простой вариант для некоторых
предметных областей
Коммерческие средства мониторинга приложений
28.8.
Мониторинг безопасности
Проверка целостности системы
Контроль обнаружения вторжений
28.9. SNMP:
простой протокол сетевого управления
Организация протокола
Операции протокола
SNMP
SNMP
Net-SNMP: средства для серверов
28.1 О. Советы и рекомендации по мониторингу
28.11. Литература
Глава
29.1.
29.2.
29.3.
29.4.
29.5.
29.6.
29. Анализ производительности
Принципы настройки производительности
Способы повышения производительности
Факторы, влияющие на производительность
Захваченные циклы центрального процессора
Как анализировать проблемы производительности
Проверка производительности системы
Инвентаризуйте свое оборудование
Сбор данных о производительности
Анализ использования центрального процессора
Управление памятью в системе
Анализ использования памяти
Анализ операций обмена с диском
Утилита f
Команда
io: анализ производительности дисковой подсистемы
sar: сбор статистических данных и генерирование
отчетов по ним
Выбор планировщика ввода-вывода в системах
Программа
системы
Соответствие законам и стандартам
Правовые вопросы
Конфиденциальность
Реализация политики безопасности
Контроль
-
это ответственность
Лицензии на программное обеспечение
31.1 О. Организации,
31.11. Литература
конференции и другие ресурсы
Краткая история системноrо администрирования
Рассвет компьютеризации: системные операторы
( 1952-1960)
1139
1139
От узкой специализации к работе в режиме
разделения времени
( 1961-1969)
UNIX ( 1969-1973)
UN IX становится знаменитой ( 197 4-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
о соавторах
Джеймс Гарнетr имеет степень доктора компьютерных наук в Уни
верситете Колорадо и является старшим инженером-программистом
в компании
Secure64 Software, Inc., rде он разрабатывает технологии
DDoS на ядра Linux. Если он не погружен в код
перехода с системы
ядра, значит, он находится где-то в глубине Каскадных гор в штате
Вашингтон.
Фабрнцно Бранка
(@fbrnc)
является ведущим разработчиком систем
в компании АОЕ. Он, его жена и их двое детей только что вернулись
в Германию после четырех лет жизни в Сан-Франциско. Фабрицио
внес свой вклад в несколько проектов с открытым исходным кодом .
Он фокусируется на архитектуре, инфраструктуре и высокопроизводи
тельных приложениях. Кроме того, он разрабатывает процессы непре
рывной разработки, тестирования и развертывания крупных проектов.
Адриан Муат
(@adrianmouat)
работает с контейнерами с самых пер
вых дней появления технологии
Docker (amzn. to/2sVAIZt)
в
Docker.
Он опубликовал книгу
издательстве
Using
О'Рейли. В настоящее
время он является главным научным сотрудником общеевропейской
компании
Container Solutions,
специализирующейся на консалтинге
и разработке продуктов для микрослужб и контейнеров.
С общими комментариями и сообщениями об ошибках, пожалуйста, обращайтесь по адресу
uJ.sah@book. admi n . сот.
Мы сожалеем, что не можем ответить на технические вопросы
Об авторах
Эви Немет уволилась с факультета вычислительной техники Универ
ситета штата Колорадо в
2001
г. Многие годы она исследовала просторы
Тихого океана на своей 40-футовой яхте
"Wonderland"
до ее трагического исчезновения в
г. Четвертое издание этой кни
ги
-
2013
( " Страна чудес")
это последнее издание, в котором она принимала активное уча
стие, но мы изо всех сил старались сохранить ее текст там , где это было
возможно.
Гарт Снайдер (@ Ga rt Sn yder) работал в компаниях NeXT и Sun и по
лучил степень бакалавра электротехники в колледже Суортмор, штат
Пенсильвания, а также степени магистра медицины и делового админи
стрирования в Университете Рочестера .
Трент Р. Xeйн(@t r enth e in)
-
большой энтузиаст кибербезопасности и
автоматизации. Помимо технологий, он любит езду на велосипеде, гор
ные лыжи, ловлю рыбу нахлыстом , туристические походы, песни в сти
ле кантри, собак и оксфордскую запятую'. Трент получил степень бака
лавра вычислительной техники в Университете штата Колорадо.
Бэн Уэйли
-
основатель компании
занимающейся независи
WhaleTech,
мым консалтингом. Он отмечен призом компании
выдающихся энтузиастов
Amazon как один из
Amazon Web Seivices (AWS Community Heroes).
Он получил степень бакалавра компьютерных наук в университете шта
та Колорадо в Боулдере.
Дэн Макин
(@dan_mac kin)
получил ученую степень бакалавра элек
трической и компьютерной инженерии в университете штата Колорадо
в Боулдере. Он применяет систему
Linux
и другие технологии с откры
тым исходным кодом не только для выполнения своих профессиональ
ных обязанностей , но и в качестве хобби
-
для автоматизации сбора
метеорологических данных. Дэ н любит горные лыжи, п арусный спорт,
внутренний туризм, а также проводить время со своей женой и собакой.
'3ашпая , которая ставится перед союзом
and
в конце перечисления.
-
Примеч. ред.
памяти эви
В каждой области знаний есть авторитет, который ее определяет и олицетворяет.
В системном администрировании таким человеком является Эви Немет.
Это пятое издание книги, в которой Эви является главным автором. Хотя Эви не
смогла физически присоединиться к нам, ее образ всегда был рядом, кроме того, ей
принадлежат многие главы и примеры. Мы прилагали огромные усилия для сохранения
необычного стиля Эви, для которою характерна объективность, техническая глубина
и внимание к деталям.
Профессиональный математик и криптограф, Эви еще недавно работала профессо
ром информатики в Университете Колорадо в Боулдере. То, как возникло системное ад
министрирование, и какое участие Эви в нем приняла, подробно описано в последней
главе этой книги "Краткая история системною администрирования".
На протяжении всей своей карьеры Эви с нетерпением ждала выхода на пенсию,
чтобы отправиться в кругосветное плавание. В
мечту
-
купила парусник
Wonderland
2001
г. она наконец осуществила свою
и отправилась в путешествие. Многие годы Эви
приводила нас в восторг рассказами об удивительных островах, замечательных людях
и парусных приключениях. Работая над двумя изданиями этой книги, Эви бросала
якорь как можно ближе к береrу, чтобы загружать свои наброски через сети
Никогда не отказываясь от рискованных приключений, в июне
членом экипажа знаменитою парусника
морю. Вскоре после этого шхуна
Nina
Nina
2013
Wi-Fi.
г.
Эви стала
и отправилась в плавание по Тасманскому
исчезла в сильном шторме, и с тех пор мы ничею
не слышали от Эви. Она жила своей мечтой.
Эви научила нас гораздо большему, чем системное администрирование. Даже ког
да ей исполнилось
70 лет,
она оставалась лучшей: лучше всех организовывала сети, на
вино. Вместе с Эви все было достижимым.
Здесь невозможно кратко сформулировать всю мудрость Эви, но некоторые принци
пы глубоко внедрились в наши головы.
•
Будьте консервативными по отношению к тому, что вы отправляете, и либераль-
ными
•
•
•
•
•
•
•
•
-
к тому, что вы получаете. 1
Будьте либеральными к тому, кого вы нанимаете, но своевременно их увольняйте.
Избегайте двусмысленности.
Бакалавры
-
секретное сверхмощное оружие.
Красных чернил не бывает слишком много.
Вы не поймете, что вы делаете, пока не сделаете.
Время для суши есть всегда.
Не бойтесь попробовать что-то дважды.
Всегда используйте программу
sudo.
Мы уверены, что некоторые читатели спросят нас, что на самом деле означают не
которые из приведенных выше афоризмов. Мы, по примеру Эви, оставим это в ка
честве упражнения. Вы можете даже услышать, как она говорит: "Попробуйте сами.
Посмотрите, как это работает".
Счастливого плавания, Эви. Мы скучаем по тебе.
1 Этот
принцип также известен как Закон Постела, названный в честь Джонатана Постела
который был редактором серии документов RFC с 1969 r. до своей смерти в 1998 r.
Postel),
(Jon
предисловие
Современные технологи
-
мастера в поиске ответов в
Google.
Если другой систем
ный администратор уже столкнулся с проблемой (и, возможно, решил ее), вы наЙдете
описание решения в Интернете. Мы приветствуем и поощряем этот открытый обмен
идеями и решениями.
Если в Интернете есть так много информации, зачем нужно новое издание данной
книги? Мы считаем, что эта книга способствует профессиональному росту системного
администратора.
Мы предлагаем принципы, руководство и контекст для надлежащего применения
•
технологии. Важно рассмотреть любое пространство проблем с разных точек зре
ния. Необходимо владеть основами смежных дисциплин, таких как безопасность,
согласованность, методология
DevOps,
облачные вычисления и жизненные циклы
разработки программного обеспечения.
Мы принимаем практический подход. Наша цель
•
-
обобщить коллективную точ
ку зрения на системное администрирование и рекомендовать подходы, которые
выдержали испытание временем. Эта книга содержит описания многочисленных
случаев из практики и множество прагматических советов.
Это книга не о том, как запустить операционную систему
•
UN IX
или
Linux
у себя
дома, в гараже или на смартфоне. Вместо этого мы описываем управление произ
водственными средами, такими как предприятия, правительственные учреждения
и университеты. В этих средах есть требования, которые выходят далеко за преде
лы возможностей типичного любителя.
Мы учим вас, как быть профессионалом. Эффективное системное администриро
•
вание требует как технических, так и программистских навыков. А также чувства
юмора.
ОРГАНИЗАЦИЯ книги
Книга разделена на четыре большие части: основы администрирования, сеть, хране
ние и эксплуатация.
Раздел "Основы администрирования" содержит широкий обзор операционных си
стем
UNIX
и
Linux,
с точки зрения системного администратора. Главы в этом разделе
охватывают большинство фактов и методов, необходимых для запуска автономной сис
темы.
Раздел "Сеть" описывает протоколы, используемые в системах
UNIX,
и методы,
применяемые для настройки, расширения и поддержки сетей и серверов, работающих
в Интернете. Здесь также рассматривается сетевое программное обеспечение высокого
уровня. Среди предлагаемых тем
-
система доменных имен, электронная почта, единый
вход и веб-хостинг.
В разделе "Хранение" рассматриваются проблемы хранения и управления данными.
В этом разделе также рассматриваются подсистемы, которые допускают совместное ис
пользование файлов в сети, такие как сетевая файловая система и протокол
вместимый с
SMB,
со
Windows.
Раздел "Эксплуатация" посвящен ключевым темам, с которыми сталкивается си
стемный администратор на ежедневной основе при управлении производственными
Предисловие
37
средами. Эти темы включают в себя мониторинг, безопасность, производительность,
взаимодействие с разработчиками и политику управления группой системного админи
стрирования.
АВТОРЫ
Мы рады приветствовать Джеймса Гарнетта, Фабрицио Бранку и Адриана Муата
в качестве соавторов этого издания. Глубокие знания этих ученых в разных областях
значительно обогатили содержание книги.
КОНТАКТНАЯ ИНФОРМАЦИЯ
Пожалуйста, отправляйте предложения, комментарии и сообщения об ошибках
на адрес
ulsah@book. adтin. сот. Мы отвечаем на письма, но, пожалуйста, будьте тер
пеливы; иногда может пройти несколько дней до того, как один из нас сможет ответить.
Из-за объема электронной почты, которая приходит на этот адрес, мы сожалеем, что не
можем ответить на технические вопросы.
Чтобы просмотреть текущий список ошибок и другую актуальную информацию, по
сетите наш веб-сайт
adrnin. сот.
Надеемся, вам понравится эта книга, и желаем удачи в увлекательном системном ад
министрировании!
Гарт Снайдер
Трент Р. Хейн
Бен Уэйли
Дэн Макин
Июль
2017 r.
введение
В
1942 г.
Уинстон Черчилль описал одну из первых битв Второй мировой войны: "Эrо
еще не конец, это даже не начало конца, но это, возможно, конец начала". Я вспомнил
эти слова, когда мне было предложено написать предисловие к пятому изданию
и
Linux:
"UNIX
руководство системного администратора". Исчезновение в море Эви Немет
бьuю большой печалью для сообщества
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
и интернет-сообщества. Эви очень гор
дилась бы своими детьми, как из-за этой книги, так и из-за того, кем они оказались.
Я ими горжусь.
Пол Викси (Раи/
Vixie)
Ла Хонда, Калифорния
Июнь
2017
г.
БЛАГОДАРНОСТИ
Многие люди внесли свой вклад в этот проект
-
от технических обзоров и конструк
тивных предложений до общей моральной поддержки. Следующие лица заслуживают
особой благодарности.
Джейсон Каролан
Нед Макклейн
Дэйв Рот
(Jason Carolan)
(Ned McClain)
(Dave Roth)
Рэнди Элсе
Бет Мак-Элрой
Питер Санкаускас
(Randy Else)
(Beth McElroy)
(Peter Sankauskas)
Стив Геде
Пол Нельсон
Дипак Сингх
(Steve Gaede)
(Paul Nelson)
(Deepak Singh)
Асиф Хан
Тим О'Рейли
Пол Викси
(Asif Кhan)
(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. сот.
(Laszlo Nemeth)
за его готов
ность поддержать продолжение этой серии.
От издАтЕльствА
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим
ваше мнение и хотим знать, что было сделано нами правильно, что можно бьшо сде
лать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать
и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам элек
тронное письмо, либо просто посетить наш веб-сайт и оставить свои замечания там.
Одним словом, любым удобным для вас способом дайте нам знать, нравится или нет
вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более ин
тересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов,
а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обя
зательно учтем его при отборе и подготовке к изданию последующих книг.
Наши электронные адреса:
E-mail:
WWW:
info@dialektika.com
http://www.dialektika.com
ЧАСТЬ
1
Основы администрирования
Глава
1
с чеrо начать
Мы написали эту книгу, чтобы занять конкретную нишу в обширной экосистеме
mаn-страниц, блогов, журналов, книг и других справочных материалов, которые должны
Во-первых, это общее руководство. В нем рассматриваются основные системы
управления, выделяются разные части каждой из них и объясняется, как они работают
вместе. Во многих случаях, когда вы должны выбирать между различными реализация
ми определенной концепции, мы описываем преимущества и недостатки самых попу
лярных возможностей.
Во-вторых, это краткий справочник, в котором собрано то, что необходимо знать,
чтобы выполнять типичные задачи на множестве распространенных систем
и
Linux.
Например, команда
поддерживает более
80
ps,
UNIX
показывающая состояние выполняемых процессов,
параметров командной строки в системах
Linux.
Однако всего
несколько комбинаций этих параметров удовлетворяют большинство потребностей си
стемного администратора; мы приводим их в разделе
4.3.
Наконец, в этой книге основное внимание уделяется управлению корпоративными
серверами и сетями, т.е. серьезному профессиональному системному администрирова
нию. Легко настроить одну систему; сложнее сохранить распределенную облачную плат
форму, работающую без сбоев, несмотря на опасность распространения вирусов, наруше
ние связности сетей и целенаправленные атаки. Мы описываем методы и эмпирические
правила, помогающие восстанавливать системы после сбоев, и предлагаем решения, ко
торые масштабируются по росту размеров, сложности и неоднородности вашей империи.
Мы не претендуем на полную объективность, но считаем, что выразили свои предпо
чтения достаточно ясно. Одной из интересных особенностей системного администриро-
Часть
44
1. Основы
администрирования
вания является то, что разумные люди могут иметь совершенно разные представления
о наиболее подходящем решении. Мы предлагаем наши субъективные мнения как ин
формацию к размышлению. Решайте сами, до какой степени вы с ними согласны и на
сколько они соответствуют вашей среде.
1.1. ОСНОВНЫЕ
ОБЯЗАННОСТИ СИСТЕМНОГО АДМИНИСТРАТОРА
В приведенных ниже разделах описаны основные задачи, которые должны выпол
нять администраторы. Эти обязанности не всегда возлагаются на одного человека, во
многих организациях работа распределяется между несколькими членами команды.
Однако по крайней мере один человек должен разбираться во всех компонентах и обе
спечивать правильное решение каждой задачи.
Управление доступом
Системный администратор создает учетные записи для новых пользователей, удаляет
учетные записи неактивных пользователей и решает все связанные с учетными запися
ми проблемы, которые могут возникнуть (например, забытые пароли и потерянные пары
ключей). Процесс добавления и удаления учетных записей обычно автоматизируется с по
мощью системы управления конфигурацией или централизованной службы каталогов.
W Информация о работе с учетными записями пользователей приведена в главах 8, 17 и 23.
Добавление оборудования
Администраторы, работающие с физическим оборудованием (в отличие от облачных
систем и систем, размещенных на виртуальном сервере), должны устанавливать и на
страивать его так, чтобы операционная система могла его распознать. Функции под
держки оборудования могут варьироваться от простой задачи добавления сетевой интер
фейсной карты до настройки специализированного внешнего массива хранения.
Автоматизация задач
Использование инструментов для автоматизации повторяющихся и трудоемких задач
повышает эффективность работы, снижает вероятность ошибок и повышает вашу спо
собность быстро реагировать на изменяющиеся требования. Администраторы стремят
ся сократить количество ручного труда, необходимого для бесперебойной работы систем.
Знакомство с языками сценариев и инструментами автоматизации
-
важная часть работы.
W Информацию о сценариях и автоматизации см. в главе 7.
Управление резервными копиями
Резервное копирование данных и их восстановление при необходимости являются
важными административными задачами. Хотя резервное копирование
-
долгое и скуч
ное занятие, частота бедствий в реальном мире просто слишком велика, чтобы можно
было игнорировать эту работу.
W Советы по резервному копированию см. в разделе 20.13.
Существуют операционные системы и отдельные пакеты программного обеспече
ния, которые зарекомендовали себя как хорошие инструменты и методы для облегчения
Глава
1. с
чего начать
45
резервного копирования. Резервные копии должны выполняться по регулярному рас
писанию, а их восстановление должно периодически проверяться, чтобы гарантировать
правильную работу.
Установка и обновление программного обеспечения
Программное обеспечение необходимо выбирать, инсталлировать и настраивать,
причем, как правило, в разных операционных системах. По мере обновления заплаток
и обновлений безопасности их необходимо тестировать, анализировать и внедрять в ло
кальную среду, не ставя под угрозу стабильность производственных систем.
W
Информацию об управлении программным обеспечением см. в главе б.
Термин поставка программного обеспечения относится к процессу выпуска обновлен
ных версий, главным образом, собственного программного обеспечения. Непрерывная
поставка переносит этот процесс на следующий уровень, предусматривая автоматиче
скую регулярную поставку программного обеспечения пользователям по мере его разра
ботки. Администраторы помогают внедрять надежные процессы поставки, отвечающие
требованиям предприятия.
W
Информацию о развертывании и непрерывной поставке программного обеспечения
см. в главе
26.
Мониторинг
Работа над решением проблемы обычно требует меньше времени, чем документиро
вание и создание отчетов, и пользователи, работающие в организации, зачастую следуют
по пути наименьшего сопротивления. Внешние пользователи чаще открыто публикуют
свои жалобы, чем просят о помощи. Администраторы могут предотвратить жалобы, об
наруживая и устраняя проблемы до их открытого проявления. К задачам мониторинга
относится обеспечение того, чтобы веб-службы быстро и корректно реагировали на со
бытия, собирали и анализировали файлы журналов и отслеживали доступность ресурсов
сервера, таких как дисковое пространство. Все это открывает отличные возможности
для автоматизации, а множество систем мониторинга (как коммерческих, так и с откры
тым исходным кодом) могут помочь системным администраторам решить эти задачи.
W
Информацию о мониторинге см. в главе
28.
Исправление проблем
Сбои сетевых системы происходят неожиданно, а иногда приводят к тяжелым по
следствиям. В обязанности администратора входят функции механика, который диагно
стирует проблемы и при необходимости прибегает к помощи экспертов. Поиск источ
ника проблемы часто сложнее, чем ее решение.
W Информацию о сетевых проблемах см. в разделе 13.12.
граммное обеспечение и принимают множество других решений, которые могут быть не
сразу очевидными или интуитивно понятными другим. Полная и точная документация
является благом для членов команды, которые в противном случае вынуждены были
Часть
46
1. Основы администрирования
бы ночами выполнять обратное проектирование системы, чтобы устранить проблему.
Подробная схема сети полезнее, чем многословный текст в описании проекта.
m
Информацию о локальной документации см. в разделе
31 .3.
Бдительный мониторинг безопасности
Администраторы
-
первая линия защиты сетевых систем. Администратор должен
выполнять правила безопасности и вырабатывать процедуры для предотвращения на
рушений. В зависимости от контекста эти функции могут включать как несколько про
стых проверок несанкционированного доступа, так и сложную сеть ловушек и программ
аудита. Системные администраторы осторожны по своей природе и часто являются спе
циалистами по безопасности в технических организациях.
m Информацию о системах безопасности см. в главе 27.
Настройка производительности
UNIX
и Liпux
-
это операционные системы общего назначения, которые хорошо
подходят практически для любой мыслимой вычислительной задачи. Администраторы
могут адаптировать системы для достижения оптимальной производительности в соот
ветствии с потребностями пользователей, доступной инфраструктурой и услугами, пре
доставляемыми системами. Если сервер работает плохо, задача администратора
-
про
анализировать его работу и определить области, которые нуждаются в улучшении.
W Информацию о вопросах производительности см. в главе 29.
Разработка правил
По нормативно-правовым причинам в большинстве организаций необходимо уста
новить правила,
регулирующие допустимое
использование компьютерных систем,
управление данными и их хранение, конфиденциальность и безопасность сетей и си
стем, а также другие вопросы, представляющие интерес. Системные администраторы
часто помогают организациям вырабатывать разумные правила, которые отвечают букве
и духу закона и одновременно способствуют успеху и производительности.
m
Информацию о разработке локальных правил см. в разделе
1.8.
Работа с поставщиками
Для предоставления разнообразных вспомогательных услуг и продуктов, связанных
с их вычислительной инфраструктурой, большинство организаций прибегает к по
сторонней помощи. Эту помощь могут оказывать разработчики программного обе
спечения, поставщики облачной инфраструктуры, продавцы программных продуктов
как услуг
(service-as-a-service - SaaS),
сотрудники службы поддержки, консультанты,
подрядчики, эксперты по безопасности и поставщики платформ или инфраструктур.
Администраторам можно поручить выбирать поставщиков, помогать в переговорах
по контрактам и внедрять решения после завершения работы над документами.
Тушение пожаров
Хотя помощь другим людям с их разнообразными проблемами редко включается
в описание функциональных обязанностей системного администратора, эти задачи за
нимают значительную часть большинства рабочих дней администраторов. На системных
1. С чего
Глава
47
начать
администраторов обрушивается град жалоб, начиная с "Он еще вчера работал, а сегодня
нет! Что вы изменили?" и заканчивая "Я пролил кофе на клавиатуру! Можно ли вылить
на нее воду, чтобы смыть кофе?"
В большинстве случаев ваши ответы на эти вопросы гораздо больше влияют на то,
насколько ценным администратором вас будут считать, чем любые технические навыки,
которыми вы могли бы обладать. Вы можете либо выть от несправедливости, либо радо
ваться тому, что за одну хорошо выполненную просьбу о помощи вам будет начислено
больше баллов, чем за пять часов ночной работы. Выбор за вами!
1.2.
ПРЕДВАРИТЕЛЬНЫЙ опыт
В этой книге мы предполагаем, что у вас есть определенный опыт работы с систе
мами
Linux
или
UNIX.
В частности, у вас должно быть общее представление о том, как
система выглядит и воспринимается с точки зрения пользователя, поскольку мы не рас
сматриваем этот материал. Повысить уровень вашей квалификации помогут несколько
хороших книг; см. раздел "Рекомендуемое чтение" в конце главы.
Мы любим хорошо продуманные графические интерфейсы. К сожалению, инстру
менты графического пользовательского интерфейса для системного администрирования
в системах
UNIX и Linux остаются рудиментарными
по сравнению с богатством базово
го программного обеспечения. В реальном мире администраторам должно быть удобно
использовать командную строку.
Для редактирования текста мы настоятельно рекомендуем изучить редактор
перь он чаще всего рассматривается в расширенной форме,
vim),
vi
(те
который является
стандартным для всех систем. Он простой, мощный и эффективный. Освоение редак
тора
vim -
это, пожалуй, лучший способ повышения производительности, доступный
для администраторов. Используйте команду
vimtutor
для отличного интерактивного
введения в эту тему.
Существует альтернатива
-
редактор
nano
с графическим пользовательским интер
фейсом, представляющий собой простой и компактный "редактор для начинающих"
с экранными подсказками. Не используйте его открыто; профессиональным админи
страторам зачастую очень не нравится, когда их коллеги используют этот редактор.
Хотя администраторы обычно не считаются разработчиками программного обе
спечения, отраслевые тенденции размывают границы между этими функциями.
Эффективные администраторы, как правило, знают многоязыков программирования
и не прочь освоить новый язык, если возникнет такая необходимость.
W
Введение в сценарии см. в главе 7.
Для создания новых сценариев мы рекомендуем языки
Bash (или bash, или sh), Ruby
Python. Bash - это командная оболочка, принятая по умолчанию для большинства си
стем UNIX и Linux. Bash примитивен как язык программирования, но является хорошим
средством интеграции инструментов системного администратора. Python - это умный язык
или
с хорошо понятным синтаксисом, широким сообществом разработчиков и библиотеками,
которые облегчают решение многих задач. Разработчики, использующие язык
вают его как "приятный" и "красивый". Языки
Ruby и Python во
Ruby, описы
многом похожи, и мы об
наружили, что они обладают одинаковыми функциональными возможностями д11я управле
ния системами. Выбор между ними в основном зависит от личных предпочтений.
Мы также предполагаем, что вы умеете работать с инструментом
expect,
который
представляет собой не язык программирования, а интерфейс для запуска интерактивных
Часть
48
1. Основы
администрирования
программ. Это эффективная технология интеграции, которая может заменить некото
рые сложные сценарии и проста в освоении.
Самые важные факты, которые необходимо знать о сценариях дпя работы с языками
Bash, Python
и
Ruby,
обобщаются в главе
7.
В ней также рассматриваются регулярные
выражения (шаблоны соответствия текста) и некоторые идиомы оболочки, полезные
дпя системных администраторов.
1.3. ДистРИ&Утивы
В дистрибутив
Linux
L1нux
входит ядро операционной системы и пакеты, содержащие все
команды, которые можно выполнять в системе. Все дистрибутивы имеют одну и ту же
линейку ядер, но формат, тип и количество пакетов немного отличаются. Дистрибутивы
также различаются по направленности, уровню поддержки и популярности. По-прежнему
существуют сотни независимых дистрибутивов
Linux,
но мы считаем, что в ближайшие
годы в производственных средах будут преобладать дистрибутивы
По большому счету, различия между дистрибутивами
Linux
Deblan
и
Red Hat.
не являются очень уж
большими. Довольно странно, что существует так много разных дистрибутивов, каждый
из которых утверждает, что он отличается "легкой инсталляцией" и "крупной библи
отекой программного обеспечения". Трудно избежать вывода о том, что людям просто
нравится создавать новые дистрибутивы
Linux.
Большинство основных дистрибутивов имеют относительно безболезненную процедуру
инсталляции, среду рабочего стола и некоторую форму управления пакетами. Вы можете
легко их испытать, запустив экземпляр на облаке или на локальной виртуальной машине.
По большей части незащищенность операционных систем общего назначения явля
ется следствием их сложности. Практически все ведущие дистрибутивы забиты множе
ством неиспользуемых пакетов программного обеспечения; в результате часто возника
ют уязвимости в области безопасности и сложности в управлении. В ответ появилось
относительно новое поколение минималистских дистрибутивов. Лидером среди них яв
ляется система
CoreOS, которая предпочитает запускать все программное обеспечение
Alpine Linux - это легкий дистрибутив, который используется в качестве
основы дЛЯ многих публичных образов Docker. Учитывая эту редукционистскую тенден
цию, мы ожидаем, что в ближайшие годы доля дистрибутивов Linux будет сокращаться.
в контейнерах.
Выбрав дистрибутив, вы делаете инвестиции в какой-то конкретный способ работы.
Вместо того чтобы учитывать только функции инсталлированного программного обе
спечения, разумно посмотреть, как ваша организация и конкретный поставщик будут
работать друг с другом. Перечислим некоторые важные вопросы.
•
•
•
•
Будет ли существовать этот дистрибутив через пять лет?
Будет ли дистрибутив распространяться поверх последних исправлений уязвимости?
Имеет ли этот дистрибутив активное сообщество и достаточную документацию?
Если у меня возникнут проблемы, будет ли продавец говорить со мной и сколько
это будет стоить?
Некоторые из самых популярных распространенных дистрибутивов
в табл.
перечислены
l. l.
Наиболее жизнеспособные дистрибутивы не обязательно являются корпоративны
ми. Например, мы ожидаем, что дистрибутив
Linux!)
Deblan
Deblan Linux
(ладно-ладно,
Deblan GNU/
останется жизнеспособным в течение дпительного времени, несмотря на то, что
не является компанией, ничего не продает и не предпагает поддержки на уров-
Глава
1. с
49
чего начать
не предприятия. Проект
Deblan
извлекает выгоду из существования преданной группы
opensuse. org
openwrt. org
oracle. сот
rancher. сот
redhat. сот
slackware. сот
suse. сот
ubuntu. сот
Бесплатный аналог
CeпtOS
CoreOS
DеЬiап
opeпWRT
Oracle Liпux
RaпcherOS
Red Hat Eпterprise
Slackware
SUSE Liпux Enterprise
Ubuпtu
Бесплатный аналог
Red Hat Eпterprise
Все в контейнерах
Бесплатный, как и большинство дистрибутивов
Испытательный стенд для
GNUish
Red Hat Liпux
Для специалистов по поиску уязвимых мест
SUSE Liпux Eпterprise
Liпux для маршрутизаторов и встроенных устройств
Версия
RHEL,
поддерживаемая
Oracle
20МиБ, все в контейнерах
Надежный, медленно меняющийся, коммерческий
Древний, долгоживущий дистрибутив
Очень популярный в Европе, многоязычный
Улучшенная версия Deblaп
Полный список дистрибутивов, включая множество неанглоязычных, можно найти
на сайтах
lwn. net/Distributions
или
distrowa tch. com.
W Дополнительную информацию о платформе Docker и контейнерах см. в главе 25.
1.4.
ПРИМЕРЫ СИСТЕМ, ИСПОЛЬЗУЕМЫХ В ЭТОЙ КНИГЕ
В качестве основных примеров для этой книги мы выбрали три популярных дис
Linux и один вариант UNIX: Deblan GNU/Linux, Ubuntu Linux, Red Hat
Enterprise Linux (и его клон CentOS) и FreeBSD. Эти системы являются репрезентатив
трибутива
ными для общего рынка с учетом значительной части инсталляций, используемых се
годня на крупных объектах.
Информация в этой книге обычно относится ко всем рассматриваемым системам,
если не указано иное. Детали, характерные для отдельной системы, отмечены логотипом.
@
Deblan GNU/Linux 9.0 "Stretch"
е
Ubuntu 00 17.04 "Zesty Zapus"
RHEL. Red Hat® Enterprise Linux 00 7.1
•
и CentOS
00
7.1
FreeBSD® 11.0
Большинство этих торговых марок принадлежат производителям, выпускающим со
ответствующее программное обеспечение, и используются с любезного разрешения их
владельцев. Тем не менее поставщики не рецензировали и не утверждали содержание
ЭТОЙ КНИГИ.
Часть
50
1. Основы
администрирования
Мы неоднократно пытались, но не смогли получить разрешение от
Red Hat
на ис
пользование их логотипа с красной шляпой, поэтому были вынуждены использовать
акроним
RHEL.
Более подробная информация о каждой из иллюстративных систем приводится в ни
жеследующих разделах.
Примеры дистрибутивов
Linux
Информация, характерная для
а не для какого-либо конкретного
Linux,
дистрибутива, отмечена логотипом с пингвином Туке, показанным слева.
Deblan
(произносится как "деб-ян" в честь покойного основателя Яна
Мердока
(lan Merdock)
и его жены Дебры
(Debra))
является одним из самых
старых и наиболее популярных дистрибутивов. Это некоммерческий проект
с более чем тысячами участников по всему миру. Проект
Deblan
поддержи
вает идеологическую приверженность развитию сообщества и открытому
доступу, поэтому для него никогда не возникает вопросов о том, какие части
дистрибутива являются свободными или распространяемыми.
Существуют три выпуска дистрибутива
Deblan,
которые поддерживаются одновре
менно: стабильный, нацеленный на промышленные серверы; нестабильный, содержа
щий пакеты, которые могут иметь ошибки и уязвимости с точки зрения безопасности;
и тестовый, который находится где-то посредине.
Дистрибутив
Ubuntu основан
на проекте
Deblan
и поддерживает его привер
женность бесплатному программному обеспечению с открытым исходным
кодом. За системой
Ubuntu
стоит бизнес
-
компания
ванная предпринимателем Марком Шаттлвортом
Компания
Canonical
Canonical Ltd.,
(Mark Shuttleworth).
предлагает множество выпусков
Ubuntu,
осно
предназна
ченных для облаков, настольных компьютеров и серверов без программного
обеспечения. Существуют даже выпуски, предназначенные для телефонов
и планшетов. Номера версий
сия
16.1 О
Ubuntu означают год и месяц, например вер
2016 года. Каждая версия также имеет аллите
такое как Vivid Vervet или Wily ~rewolf.
появилась в октябре
рационное кодовое имя,
Ежегодно выпускаются две версии
Ubuntu:
в апреле и октябре. Апрельские выпуски
в четные годы представляют собой долгосрочные версии поддержки
LTS),
(long-term support -
которые обещают пять лет обновлений технического обслуживания. Это выпуски,
рекомендованные для использования в производстве.
RHEL
Система
Red Hat
была доминирующей силой в мире
Linux
более двух десяти
летий, и ее дистрибутивы широко используются в Северной Америке и за ее
пределами. По количеству инсталляций
Red Hat, lnc.
является самой успеш
ной в мире компанией с открытым исходным кодом.
Система
Red Hat Enterprise Linux,
часто сокращаемая до
RHEL,
ориентирована
на производственные среды крупных предприятий, которые требуют поддержки и кон
салтинговых услуг для бесперебойной работы своих систем. Как ни парадоксально, си
стема
RHEL является
открытым исходным кодом, но требует лицензии. Если вы не хо
тите платить за лицензию, вы не имеете права инсталлировать
Компания
Red Hat
также спонсирует систему
Fedora,
Red Hat.
коллективно разработанный
дистрибутив, служащий инкубатором для ультрасовременного программного обеспече
ния, которое не считается достаточно стабильным для
RHEL. Fedora
используется в ка-
Глава
1. С
чего начать
51
честве исходного тестового стенда для программного обеспечения и конфигураций, ко
торые позже находят свой путь к
RHEL.
~
Дистрибутив CeпtOS практически идентичен
~
бесплатный.
CentOS Project (centos. org)
Red Hat Enterprise Linux, но он
Red Hat и выполняет
принадлежит
ся ее ведущими разработчиками. Однако они работают отдельно от команды
Red Hat Enterprise Linux. На дистрибутив CentOS не распространяется торго
Red Hat и в нем нет нескольких патентованных инструментов, но
вая марка
в других отношениях они эквивалентны.
CentOS -
отличный выбор для организаций, которые хотят развернуть производ
ственный дистрибутив, не выплачивая десятину
и гибридный под
ход: основные серверы могут запускать
пользоваться пре
восходной поддержкой
Red Hat. Возможен
Red Hat Enterprise Linux и
Red Hat, в то время как для непроизводственных систем может
CentOS. Это решение учитывает все важные аспекты с точки
использоваться система
зрения риска и поддержки, а также минимизирует стоимость и сложность управления.
Система
CentOS
стремится к полной двоичной совместимости и совместимости
по спецификациям и отклонениям с системой
Red Hat Enterprise Linux. Вместо того
CentOS", в этой книге мы обычно упоминаем
Текст зачастую в равной степени относится и к Red Hat, и к CentOS,
чтобы постоянно повторять
только одну из них.
"Red Hat
и
если не указано обратное.
Другие популярные дистрибутивы также являются потомками
Oracle
продает переименованную и видоизмененную версию
Red Hat. Компания
CentOS клиентам своего
программного обеспечения для обслуживания корпоративных баз данных. Дистрибутив
Amazon Linux,
доступный для пользователей служб
был создан на основе системы
CentOS
Amazon Web Servises,
первоначально
и по-прежнему разделяет многие ее соглашения.
Большинство администраторов в какой-то момент своей карьеры обязательно стол
кнутся с системой, подобной
Red Hat,
и знакомство с ее нюансами полезно, даже если
эта система не установлена в вашей организации.
Пример дистрибутива
Популярность
UNIX
UNIX
в течение некоторого времени постепенно ослабевает, и боль
шинство устаревших дистрибутивов
UNIX
(например,
используются. Открытый исходный код системы
Solaris, HP-UX и AIX) больше не
BSD является исключением из этой
тенденции и продолжает оставаться предметом культового поклонения, особенно среди
экспертов по операционным системам, приверженцев открытого программного обеспе
чения и системных администраторов, нацеленных на безопасность. Другими словами,
некоторые из ведущих операционных систем в мире полагаются на различные дистрибу
тивы
•
BSD.
Например, система
Дистрибутив
MacOS
FreeBSD,
компании
Apple
использует наследие
впервые выпущенный в конце
1993
более широко используемым производным инструментом
ствии со статистикой использования он занимает
BSD.
70%
BSD .
г., является наи
BSD.
В соответ
доли рынка версий
Среди его пользователей встречаются крупные интернет-компании,
такие как
WhatsApp, Google
и
Netflix.
В отличие от
Linux, FreeBSD -
это
полная операционная система, а не только ядро. Как программное обеспе
чение ядра, так и пользовательское программное обеспечение лицензируют
ся в соответствии с разрешительной лицензией
витию и расширению бизнес-сообщества.
BSD,
что способствует раз
52
Часть
1.5. ОБОЗНАЧЕНИЯ
1. основы администрирования
И ТИПОГРАФСКИЕ СОГЛАШЕНИЯ
Имена файлов, команды и аргументы команд, которые следует набирать на клавиа
туре без изменений, даны полужирным шрифтом. Аргументы, вместо которых следует
подставлять конкретные значения, даны курсивом. Например, в команде
ер файл ка та лог
предполагается, что аргумент файл следует заменить именем реального файла, а аргу
мент каталог
-
именем реального каталога.
Фрагменты сценариев и файлов конфигурации даны моноширинным шрифтом.
Комментарии к интерактивным сеансам иногда сопровождаются символом коммента
рия языка
ному, непривилегированному пользователю. Приглашение для привилегированного
пользователя начинается символом#. Если команда является специфичной для дистри
бутива или семейства дистрибутивов, символ приглашения сопровождается названием
дистрибутива. Например:
$ sudo su - root #
# passwd
#
deЬian# dpkg -l
#
#
Стать
привилегированным пользователем
Изменить пароль
суперпользователя
root
Вывести инсталлированные
пакеты в
Debian
и
Ubuntu
Это соглашение принято в стандартных оболочках
UNIX и Linux.
За исключением специальных случаев мы старались избегать использования особых
шрифтов и форматов, чтобы не отвлекать читателей. Например, мы часто говорим о таких
сущностях, как группа
daemon,
никак не выделяя их с помощью отдельного формата.
При описании синтаксиса команд мы, как правило, используем те же обозначения,
что и в интерактивном руководстве:
•
•
•
(" [" и "] "), является необязательным;
(" ... "), можно повторять;
текст, заключенный в квадратные скобки
текст, после которого стоит многоточие
фигурные скобки
(" {"
и
") ")
указывают на то, что необходимо выбрать один из
элементов, разделенных вертикальной чертой
(" 1").
Например, спецификации
bork
[-х]
(onloff}
имя_файла
соответствует любая из следующих команд:
bork on /etc/passwd
bork -х off /etc/passwd /etc/smartd.conf
bork off /usr/liЬ/tmac
В выражениях с шаблонами поиска используются следующие метасимволы:
•
•
•
•
звездочка(*) обозначает нуль или более символов;
знак вопроса(?) обозначает один символ;
тильда
(-) обозначает начальный
каталог текущего пользователя;
выражение -пользователь обозначает начальный каталог указанного пользователя.
Глава
1. с чего начать
53
Например, иногда мы обозначаем каталоги, где хранятся сценарии запуска
rc* .d, eto/rc* .d и
1.6. Единицы
т.д.), сокращенным шаблоном
(eto/
etc/rc* .d.
ИЗМЕРЕНИЯ
Метрические приставки кило-, мега- и гига- определяются показателями степени
числа
10
(например, один мегагерц составляет миллион герц). Однако для компьютер
ных типов данных используются степени числа
2. Например, один "мегабайт" памяти
220, или 1048576 байт. Ассоциация твердотельных технологий (Solid State
Technology Association) Объединенного инженерного совета по электронным устрой
ствам (Joint Electronic Device Engineering Council - JEDEC) даже превратила эти едини
цы измерения в официальный стандарт Standard 1008.01, который признает их степеня
составляет
ми двойки (не без некоторых натяжек).
Пытаясь внести ясность, Международная электротехническая комиссия (lnternational
Electrotechnical Commission - 1ЕС) определила ряд числовых приставок, основанных
именно на степенях числа 2: киби- (kibl-), меби- (mebl-), гиби- (gibl-) и так далее с аб
бревиатурами КиБ (Ki), МиБ (Mi) и ГиБ (Gi) соответственно. Эти единицы измерения
исключают двусмысленность, но их еще только начинают использовать. Поэтому при
вычный набор кило-, мега- и гига-префиксов все еще в ходу в обоих смыслах: десятич
ном И ДВОИЧНОМ.
Определить конкретное значение можно по контексту. Объем оперативной памя
ти всегда измеряется в степенях двойки, а пропускная способность сети
числа
10.
-
в степенях
Размер дисков их производители обычно указывают в десятичных единицах,
а размер секторов и страниц
-
в двоичных.
В этой книге мы используем единицы измерения МЭК
и метрические
-
для степеней числа
10.
(IEC)
для степеней двойки
Метрические единицы измерения мы при
меняем также для приблизительных значений и в тех случаях, когда точное основание
степени неясно, не зафиксировано в документах или его невозможно определить. В ко
мандах файлов конфигурации
output
и
in
мы оставляем исходные значения и указа
тели единиц измерений. Для обозначения бита служит буква Ь, а для байта
Некоторые примеры интерпретации единиц измерения приведены в табл.
Таблица
1.2.
1.2.
буква В.
Примеры интерпретации единиц измерения
Пример
Описание возмо•иого варианта
1 Кбайт (kB)
Размер файла, равный
4КиБ(КiВ)
Общий размер страниц твердотельного диска
8 Кбайт(КВ)
Размер памяти
100 Мбайт (МВ)
Номинально составляет
-
1ООО байт
(SSD) 4096 байт
не используется в этой книге (см. описание ниже)
108 байт (неоднозначность,
понимается по контексту)
100 Мбайт (МВ)
Номинально составляет 108 байт, в зависимости от контекста, возможно,
1 ГиБ (GiB)
1073 741 824 байт памяти
1 Гбит/с (Gb/s)
Скорость передачи информации в сети, равная
бТбайт(ТВ)
Объем жесткого диска, равный
99 999 744 байl"
1000000000 бит в секунду
6 ООО ООО ООО ООО байт
•Число 10 округлено в меньшую сторону до ближайшего целого, кратного размеру 512-байтового сектора диска.
8
Буква К в аббревиатуре, как в случае
"8
Кбайт (КВ)", не является частью стандар
та. Это компьютерная адаптация метрической аббревиатуры
k
(обозначение приставки
Часть
54
кило-), которая означает
1024
в отличие от
1ООО.
1. Основы администрирования
Поскольку в аббревиатурах для многих
метрических приставок уже используется прописная буква, стала возникать путаница
при новом и исходном использовании буквы К в качестве множителя
1ООО.
В большинстве стран эта проблема не считается важной, например в США метриче
ские префиксы часто используются неоднозначно. В дистрибутиве
Ubuntu
была пред
принята попытка реализовать последовательную политику использования единиц из
мерений, но широкой поддержки, даже в самой компании
получила (подробнее см.
Canonical,
она, похоже, не
wiki. ubuntu. com/Uni tsPolicy).
1.7. МАN-СТРАНИЦЫ
И ДРУГАЯ ОНЛАЙН-ДОКУМЕНТАЦИЯ
Традиционную онлайн-документацию образуют страницы справочного руководства,
обычно называемые тап-страницами, потому что они считываются с помощью команды
man.
(Конечно, в наши дни вся документация в той или иной форме находится в режиме
онлайн.) Справочные страницы поставляются вместе с новыми пакетами программного
обеспечения. Даже в эпоху
Google
мы продолжаем рассматривать справочные страницы
как авторитетный ресурс, потому что они доступны из командной строки и, как пра
вило, содержат полную информацию о параметрах программы, а также демонстрируют
полезные примеры и связанные с ними команды.
Справочные страницы
-
это краткое описание отдельных команд, драйверов, фор
матов файлов или библиотечных процедур. Они не затрагивают более общие темы, та
кие как "Как установить новое устройство?" или "Почему эта система так медленно
работает?"
Организация mаn-страниц
Системы
FreeBSD и Linux разделяют mаn-страницы на разделы. Их базовая схема
1.3. Другие варианты UNIX иногда определяют разделы несколько
показана в табл.
иначе.
Точная структура разделов не важна для большинства тем, потому что человек на
ходит соответствующую страницу там, где она хранится. Просто учитывайте определе
ния разделов, если тема с тем же именем появляется в нескольких разделах. Например,
passwd -
это и команда, и конфигурационный файл, поэтому существуют соответству
ководства и выводит ее на терминал пользователя с помощью утилит
more, less
или
другой программы постраничной разбивки, которая задана в переменной окружения
PAGER. Аргумент заголовок - это, как правило, имя команды, устройства или файла,
о которых необходимо получить справочную информацию. Поиск по разделам руковод
ства осуществляется в порядке возрастания номеров, хотя разделы, посвященные описа
нию команд
( 1 и 8),
обычно просматриваются в первую очередь.
W Информацию о переменных окружения см. в разделе 7.2.
Команда
man
раздел заголовок вызывает справочную страницу из указанного
раздела. Так, в большинстве систем команда
man sync вызывает справочную страницу
sync, а команда man 2 sync - для системного вызова sync.
Команда man -k ключевое_ слово или apropos ключевое_ слово выводит список
для команды
справочных страниц, в строке пояснений к которым имеется указанное ключевое слово.
and translate object files
translate message
translate or delete characters
translate SNMP OID values into more useful information
translate characters
сору
База данных ключевых слов может устаревать. При добавлении новых справочных
страниц к системе вам, возможно, придется перестроить этот файл с помощью команд
makewhatis (Red Hat
и
FreeBSD)
или
mandb (Ubuntu).
Хранение страниц интерактивного руководства
Неформатированная информация для справочных страниц (входные данные ко
манды
nroff)
обычно хранится в подкаталогах каталога
экономии места на диске системы
Команда
man
Команда
cache/man
Linux
/usr/share/man.
В целях
сжимают страницы с помощью утилиты
gzip.
может очень быстро разархивировать их.
man поддерживает кеш отформатированных страниц в каталогах /var/
/usr/share/man, если соответствующие каталоги доступны для запи
или
си, но эти операции рискованны с точки зрения безопасности. В большинстве систем
предварительное форматирование справочных страниц выполняется однократно во вре
мя инсталляции (см. команду
Команда
man
catman)
или не выполняется совсем.
ищет страницы в ряде каталогов. В Linux-cиcтeмax выяснить путь по
иска позволяет команда
manpath.
Результат ее работы (в системе
Ubuntu)
обычно таков.
ubuntu$ manpath
/usr/local/man:/usr/local/share/man:/usr/share/man
Эта установка хранится в переменной среды МАNРАТН, и в случае необходимости ее
можно изменить.
$ export
МANPATH=/home/share/localman:/usr/share/man
Некоторые системы позволяют установить общесистемный параметр пути поиска
для справочных страниц, который может оказаться полезным в случае, если вам придет
ся поддерживать параллельное дерево справочных страниц, например сгенерированных
кроссплатформенным менеджером пакетов
OpenPKG.
Если же вы хотите распростра-
Часть
56
1. Основы администрирования
нять локальную документацию в виде справочных страниц, проще всего использовать
стандартный системный механизм пакетирования и выложить справочные страницы
в стандартные справочные каталоги. Подробнее об этом написано в главе
1.8. ДРУГАЯ
6.
ОФИЦИАЛЬНАЯ ДОКУМЕНТАЦИЯ
Справочные страницы
это лишь малая часть официальной документации.
-
Остальная в основном рассеяна в веб-пространстве.
Руководства по конкретным системам
Одни производители систем ведут собственные онлайн-проекты по подготовке до
кументации, другие выпускают полезные руководства в виде объемных книг. В насто
ящее время нужное руководство быстрее найти в Интернете, чем в форме печатного
издания. Объем и качество документации бывают разными, но большинство произ
водителей выпускает по меньшей мере руководство по администрированию и инстал
ляции системы. Где найти документацию по каждому из наших примеров систем, по
казано в табл.
1.4.
Несмотря на полезность этой документации, она не относится к тем книгам, кото
рые читают перед сном (хотя отдельные поставщики пишут справочные руководства,
которые могут усыпить кого угодно). Прежде чем обращаться к документации постав
щиков, мы обычно ищем ответы в системе
Google.
Таблица 1.4. Где найти документацию от производителей операционных систем
Система
UAL
Описание
DеЬiап
deЬian.org/com
Справочник для системного администратора, поставляемый
UbuЫu
help.ubuntu.com
Дружественная к пользователю; версии
вместе с текущей версией системы
ле
LTS описаны
в разде
"server guide".
RHEL
redhat.com/docs
Исчерпывающая документация для системных админист
CeпtOS
wiki.ceЬtos.org
Советы, подсказки и ответы на часто задаваемые вопросы
FreeBSD
freebsd.org/docs.html
раторов
Информацию для системного администратора см. в
FreeBSD
Handbook
Документация по конкретным пакетам
Большинство важнейших программных пакетов в мире
ют отдельные лица или такие сторонние организации, как
и
Apache Software Foundation.
UNIX и Linux поддержива
Intemet Systems Consortium
Сотрудники этих групп пишут собственную документа
цию, качество которой варьируется от плохого до замечательного. При этом существуют
и такие прекрасно выполненные документы, как
Pro Git
от
git-scm. /book,
которые
вполне оправдывают ожидания.
В число дополнительных документов входят: технические отчеты, проектные обосно
вания и трактовки конкретных тем. Эти дополнительные материалы зачастую не ограни
чиваются простым описанием команд и могут включать самоучители и другие разделы.
Многие программные пакеты, помимо справочных страниц, содержат и статьи по соот
ветствующим темам. Например, после вызова справочной страницы для редактора
vim
Глава
1. С
57
чего начать
вам будет предложено не только ознакомиться с аргументами командной строки, но и пе
рейти к разделу, из которого вы узнаете, как в действительности отредактировать файл.
Для большинства проектов по разработке программного обеспечения создаются спи
ски рассылки для пользователей и разработчиков, а также каналы
1RC
для интернет
чата. Если у вас возник вопрос о конкретной конфигурации или вы обнаружили ошиб
ку, советуем в первую очередь обращаться туда.
Книги
К самым лучшим источникам информации для системных администраторов в книж
ном мире можно отнести серию книг издательства
положено книгой
и командам
UNIX in
и
UNIX
а
Linux
O'Reilly.
Начало этой серии было
Теперь же практически всем важным подсистемам
Nutshell.
гим темам, не связанным с
O'Reilly публи
Microsoft Windows и дру
посвящены ее отдельные тома. Издательство
кует также книги о сетевых протоколах, операционной системе
Все эти книги имеют приемлемую цену, своевремен
UNIX.
ны и ориентированы на конкретную аудиторию.
Многие читатели издательства
Online -
O'Reilly
используют интернет-магазин
Safari Books
службу подписки, предлагающую доступ к электронным книгам, видео и дру
гим учебным материалам. Наряду с книгами издательства
O'Reilly в этом
магазине мож
но найти многочисленные книги других издателей.
Документы
RFC
Документы из серии
RFC (Request for Comments -
запрос на комментарии) опи
сывают протоколы и процедуры, используемые в Интернете. Большинство из этих до
кументов достаточно детализированы и специализированы, но некоторые написаны
в виде обзоров. Информации, которую они содержат, вполне можно доверять, но не
которые из них являются всего лишь обзорами. Фраза "эталонная реализация" озна
чает, что программа "разработана надежным источником в соответствии со специфи
кациями
RFC".
RFC
Авторитет
незыблем, а некоторых из документов этой серии достаточно полез
ные для системных администраторов. Подробное описание этих документов приведено
в разделе
13.1.
Мы будем часто цитировать их в нашей книге.
1.9. ДРУГИЕ ИСТОЧНИКИ
ИНФОРМАЦИИ
Источники, рассмотренные в предыдущем разделе, изучены экспертами и написаны
авторитетными специалистами, но вряд ли это последнее слово в области управления
системами
UNIX
и
Linux.
В Интернете доступны бесчисленные блоги, дискуссионные
форумы и новостные ленты.
Однако, что ни говорите, но
Google -
лучший друг системного администратора.
Если вы ищите детали определенной команды или формата файла,
Google
либо экви
валентная поисковая система должны быть первым ресурсом, который вы запрашиваете
для любого вопроса системного администратора. Сделайте это привычкой; так вы избе
жите задержек и унижений, когда на ваши вопросы в интерактивном форуме отвечают
с помощью ссылки на
Google. 1 Если
вы столкнулись со сложным вопросом, ищите ответ
в Интернете.
1 Или, что еще хуже, указывают ссыпку на
Google
через сайт
lmgtfy. сот.
Часть
58
1. Основы администрирования
Сохранение актуальности
Операционные системы, инструменты и методы их поддержки быстро меняются.
Советуем вам ежедневно просматривать сайты, перечисленные в табл.
1.5,
чтобы быть
в курсе тенденций, наблюдаемых в отрасли.
Табпица
1.5. Актуальные
ресурсы
Веб-сайт
Оnисание
darkreading. com
devopsreactions. tumЫr. com
Новости о средствах безопасности, тенденции и обсуждение
linux. com
Сайт консорциума Liпux Fouпdatioп; форум полезен для новых
Юмор системных администраторов в анимированном виде
пользователей
Некоммерческий проект компании
linuxfoundation. org
OSS,
работодателя Линуса
Торвальдса (Uпus Torvalds)
lwn. net
lxer. com
Высококачественные, своевременные статьи о Liпux и
securi tyfocus. com
Отчеты об уязвимостях и списки рассылки, связанные с безопас
OSS
Новости о Liпux
ностью
Размышления от имени Тейлор Свифт (Taylor
@Swi ftOnSecuri ty
Swift) о безопасно
сти информации (пародия)
@nixcraft
everythings ysadmin. сот
Твиты о системном администрировании
Благ Томаса Лимончелли
UNIX и Liпux
(Tomas Limonchelli), авторитетного си
стемного администратора•
s ysadvent. Ыogspot. сот
Благ для системных администраторов, публикующий статьи каж
дый декабрь
oreilly. coт/topics
Учебные ресурсы издательства O'Reilly по многим темам
schneier. сот
Благ Брюса Шнайера
(Bruce Schneier), эксперта по криптографии
и безопасности
•см. также сборник Томаса Лимончелли April Fools's RFC на сайте rfc-humor. сот
Социальные сети также полезны.
Twitter
и
Reddit,
в частности, имеют сильные со
общества с большим количеством предложений, хотя отношение сигнал-шум в этих се
тях иногда может быть довольно плохим. На сайте
основного форума
sysadmin, linux, linuxadmin
и
Reddit присоединяйтесь
netsec.
к разделам
Практические руководства и справочные сайты
Сайты, перечисленные в табл.
1.6,
как выполнять определенные задачи в
Таблица
1.6.
содержат руководства, учебники и статьи о том,
UNIX
и
Linux.
Сnециапьные форумы и справочные сайты
Веб·саiт
wiki. archlinux. org
-
Оnиоаиме
Статьи и руководства по Arch Liпux; многие из них носят более общий
характер
as kubun t и. сот
Вопросы и ответы для пользователей и разработчиков
digi talocean. сот
Учебники по многим темам
администрирования•
OSS,
Ubuntu
разработки и системного
Глава
1. с
59
чего начать
Окончнаие табл.
1.6
Веб-сайт
Описание
kernel. org
Официальный сайт ядра Liпux
serverfaul t. com
Совместно отредактированная база данных вопросов системного адми
нистрированияб
s е rve r s f or hac ke rs • com
Высококачественные видеоролики, форумы и статьи о системном адми
нистрировании
'Cм.Digitalocean.com/community/tutorials
бТакже см. аналогичный сайт stackoverflow. com, посвященный программированию, но полезный и для систем
ных администраторов
Stack Overflow и Server Fault, указанные в табл. 1.6 (оба входят в группу сай
Stack Exchange), требуют более пристального взгляда. Если у вас возникла проблема,
Сайты
тов
скорее всего, кто-то с ней уже сталкивался и попросил о помощи на одном из этих сай
тов. Авторитетный формат вопросов и ответов, используемый сайтами
Stack Exchange,
хорошо подходит для тех проблем, с которыми сталкиваются системные администра
торы и программисты. Рекомендуем создать учетную запись и присоединиться к этому
большому сообществу.
Конференции
Отраслевые конференции
-
отличный способ наладить связь с другими професси
оналами, следить за технологическими тенденциями, проходить учебные курсы, полу
чать сертификаты и узнавать о последних услугах и продуктах. В последние годы рез
ко возросло количество конференций, связанных с системным администрированием.
Некоторые из наиболее известных конференций предстамены в табл.
Таблица
1.7.
1.7.
Конференции по системному администрированию
Конференция
Место
Врем•
Описание
LISA
Переменное
4кв.
Управление инсталляцией крупных систем
Moпitorama
Портленд
Июнь
Инструменты и методы мониторинга
OSCON
Переменное (США/ЕС)
2 или
SCALE
Пасадена
Январь
Southerп
DefCoп
Лас-Вегас
Июль
Самый старый и самый большой съезд хакеров
Velocity
По всему миру
Переменное
Конференция
BSDCaп
Оттава
Май-июнь
Все о
re:lпveпt
Лас-Вегас
4кв.
АWS-конференция по облачным вычислениям
VMWorld
Переменное (США/ЕС)
з или
LiпuxCoп
По всему миру
Переменное
RSA
Сан-Франциско
1 кв.
DevOpsDays
По всему миру
Переменное
з кв.
Долгосрочная конференция
O'Reilly OSS
California Liпux Ехро
BSD для
O'Reilly по
веб-операциям
новичков и гуру
в Лас-Вегасе
4 кв.
или
2 кв.
Виртуализация и облачные вычисления
Будущее Liпux
Промышленная криптография и безопасность
информации
Ряд тем для преодоления разрыва между ко-
мандами разработки и групп по эксплуатации
QСоп
По всему миру
Переменное
Конференция для разработчиков программно-
го обеспечения
Часть
60
Meetups (meetup. com) -
1. Основы
администрирования
это еще один способ общения с единомышленниками.
В большинстве городов США, как и во всем мире, есть группы пользователей
DevOps,
1.1 О.
Linux или
спонсирующие ораторов, дискуссии и хакерские семинары.
Спосо&ы поискА и УСТАновки
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Подгоrовка к работе программного обеспечения подробно рассматривается в главе
Но
6.
для самых нетерпеливых мы прямо :щесь расскажем о том, как выяснить, чrо уже установле
но в вашей системе, и как получить новое программное обеспечение и инсталлировать его.
В современных операционных системах программное обеспечение разделено на па
кеты, которые можно инсталлировать независимо друг от друга. При стандартной уста
новке системы используется группа "стартовых" пакетов, которую можно при необхо
димости расширить.
Добавочные программные продукты зачастую предоставляются также в виде пред
варительно скомпилированных пакетов, но далеко не во всех системах. Большая часть
программного обеспечения создается независимыми группами разработчиков, выпуска
ющими программы в виде исходных кодов. Репозитории пакетов затем берут исходные
коды, компилируют их в соответствии с особенностями конкретной системы и вклю
чают в пакеты полученные бинарные файлы. Как правило, намного проще инсталли
ровать бинарную версию пакета, предназначенную для данной системы, чем искать
и компилировать исходный код. Однако нужно учитывать, что иногда создатели пакетов
на один-два выпуска отстают от текущей версии системы.
Если в двух системах используется один и тот же формат обработки пакетов, 10 это еще
не означает, чrо пакеты обеих систем будут взаимозаменяемыми. Например, в системах
Hat и SUSE применяется
формат
RPM,
Red
однако структура их файловых систем неодинакова.
Рекомендуется всегда пользоваться пакетами, со:щанными для конкретной системы.
В рассматриваемых нами дистрибутивах предусмотрены отлаженные системы управ
ления пакетами, которые включают средства доступа к репозиториям программных
продуктов и поиска их в Интернете. Дистрибьюторы активно поддерживают эти репо
зитории от имени сообщества, которое они представляют, чтобы облегчить процесс ис
правления и обновления систем. Другими словами, жизнь прекрасна!
Администраторы без доступа к предварительно скомпонованным бинарным версиям
пакеrов должны инсталлировать системы по-старому, т.е. загружать архив исходного кода
tar,
а затем вручную конфигурировать, компилировать и инсталлировать систему. Иногда
этот процесс проходит гладко, а иногда может превратиться в кошмар: все зависит от ис
пользуемого программного обеспечения и конкретной операционной системы.
В этой книге мы предполагаем, что дополнительное программное обеспечение уже
установлено, и не собираемся мучить вас шаблонными инструкциями по инсталля
ции каждого пакета. При необходимости мы будем указывать точные названия пакетов
для выполнения конкретного проекта. Однако большей частью мы не будем повторять
инструкции по инсталляции, поскольку они практически идентичны для всех пакетов.
Как определить, установлено ли программное обеспечение
По целому ряду причин может быть сложно определить, какой пакет содержит про
граммное обеспечение, которое вам действительно нужно. Вместо того чтобы начинать
с уровня пакета, проще использовать команду оболочки и выяснить, находится ли со-
Глава
1. С
61
чего начать
ответствующий бинарный файл в вашем пути поиска. Например, следующая команда
показывает, что компилятор
GNU
С уже установлен на этом компьютере:
ubuntu$ which gcc
/usr/Ьin/gcc
Если вы не можете найти нужную команду, попробуйте выполнить команду
whereis;
она ищет более широкий набор системных каталогов и не зависит от пути поиска вашей
оболочки.
Другой альтернативой является невероятно полезная команда
locate,
которая
справляется с предварительно скомпилированным индексом файловой системы, чтобы
найти имена файлов, которые соответствуют определенному шаблону.
Система FreeBSD реализует команду locate как часть базовой системы. В системе
Linux текущая реализация команды locate находится в пакете mlocate. В системах
Red Hat и CentOS установите пакет mlocate с помощью команды yum; см. раздел 6.4.
Команда locate может найти любой тип файла, но это не относится к командам
или пакетам. Например, если вы не были уверены, где найти подключаемый файл
signal. h,
вы можете попробовать выполнить следующую команду.
freebsd$ locatesignal.h
/usr/include/machine/signal.h
/usr/include/signal.h
/usr/include/sys/signal.h
База данных команды
системt
cron.
FreeBSD -
locate периодически обновляется командой updatedЬ (в
locate. updatedЬ), которая запускается из программы
командой
Поэтому результаты поиска не всегда отражают недавние изменения файловой си
стемы.
Зная имя пакета, который ищете, вы также можете использовать утилиты для упаков
ки системы, чтобы напрямую проверить наличие пакета. Например, в системе
Red Hat
Python:
следующая команда проверяет наличие (и установленную версию) интерпретатора
Добавление нового программного обеспечения
Если вам необходимо установить дополнительное программное обеспечение, сначала
следует определить каноническое имя соответствующего пакета программного обеспе
чения. Например, вам нужно будет перевести фразу "Я хочу установить
locate"
в "Мне
нужно установить пакет
или перевести "Мне нужен справочник
в "Мне нужно
этом может помочь целый ряд системных индек-
mlocate"
установить BIND". В
named"
Часть
62
сов в Интернете, но
command"
Google,
1. Основы администрирования
как правило, так же эффективен. Например, поиск
"locate
приводит вас непосредственно к нескольким соответствующим обсуждениям.
В следующих примерах показана инсталляция команды
иллюстративных систем. Команда
tcpdump -
tcpdwap для
каждой из наших
это инструмент для захвата пакетов, позво
ляющий просматривать исходные пакеты, отправляемые в систему и из системы в сети.
В системах Deblan и Ubuntu
Advanced Package Tool.
используется программа АРТ
-
Deblan
ubuntu# sudo apt-qet install tcpdump
Reading package lists ... Done
Building dependency tree
Reading state information ... Done
The following NEW packages will Ье installed:
tcpdump
О upgraded, 1 newly installed, О to remove and 81 not upgraded.
Need to get О В/360 kB of archives.
After this operation, 1,179 kB of additional disk space will Ье used.
Selecting previously unselected package tcpdump.
(Reading database ... 63846 files and directories currently installed.)
Preparing to unpack ... /tcpdump_4.6.2-4ubuntul_amd64.deb
Unpacking tcpdump (4.6.2-4ubuntul) ...
Processing triggers for man-db (2.7.0.2-5)
Setting up tcpdump (4.6.2-4uЬuntul) ...
RHEL ~ В системах Red Hat и CentOS аналогичная версия выглядит следующим об-
Fetching packagesite.txz:
100%
5 MiB
5.5MB/s
00:01
Processing entries: 100%
FreeBSD repository update completed. 24632 packages processed.
All repositories are up-to-date.
The following 2 package(s) will Ье affected (of О checked):
New packages to Ье INSTALLED:
tcpdump: 4.7.4
libsmi: 0.4.8 1
The process will require 17 MiB more space.
2 MiB to Ье downloaded.
Fetching tcpdump-4.7.4.txz:
100%
301 KiB
Fetching libsmi-0.4.8_1.txz: 100%
2
MiB
Checking integrity ... done (0 conflicting)
(1/2] Installing libsmi-0.4.8_1 ...
(1/2] Extracting libsmi-0.4.8_1: 100%
[2/2] Installing tcpdump-4.7.4 ...
[2/2] Extracting tcpdump-4.7.4: 100%
307.7kB/s
2.0MB/s
00:01
00:01
Создание программного обеспечения из исходного кода
В качестве иллюстрации рассмотрим процесс создания версии
tcpdump
из исходного
кода.
Первая задача
-
найти сам код. Сторонники программного обеспечения иногда хра
нят индекс выпусков на веб-сайте проекта, которые можно загрузить в виде архивов. Для
проектов с открытым исходным кодом вы, скорее всего, найдете код в репозитории
Git.
tcpdum.p хранится в репозитории GitHub. Выполните клонирование ре
каталоге /tmp, создайте ветку с тегами, которую вы хотите создать, затем
Источник
позитория в
распакуйте, настройте, создайте и установите:
redhat$ cd /tmp
redhat$ qit clone https://qithuЬ.com/the-tcpdump-qroup/tcpdump.qit
redhat$ cd tcpdump
redhat$ qit checkout taqs/tcpdump-4.7.4 -Ь tcpdump-4.7.4
Switched to а new branch 'tcpdump-4.7.4'
redhat$ ./confiqure
checking build system type ... x86_64-unknown-linux-gnu
checking host system type ... x86_64-unknown-linux-gnu
checking for gcc ... gcc
checking whether the С compiler works ... yes
redhat$ make
redhat$ sudo make install
Эта последовательность
configure/m.ake/m.ake
устанавливается для большинства
программ, написанных на языке С, и работает во всех системах
UNIX
и
Linux.
Всегда
полезно проверить файл INSTALL или READМE пакета для уточнения. Должна быть уста
новлена среда разработки и любые необходимые для пакета требования. (В случае паке
та
tcpdump
необходимой предпосылкой является установка библиотеки
путствующих библиотек.)
libpcap
и со
Часть
64
1. Основы администрирования
Зачастую возникает необходимость настроить конфигурацию сборки, поэтому ис
пользуйте команду
. /configure --help,
чтобы просмотреть параметры, доступные
для каждого конкретного пакета. Другим полезным параметром команды
является
-prefix
configure
= directory, который позволяет скомпилировать программное обе
спечение для установки где-то, кроме
/usr/local,
которое обычно является значением
по умолчанию.
Установка с помощью веб-сценария
Кросс-платформенные пакеты программного обеспечения все чаще предлагают
ускоренный процесс установки, который управляется сценарием оболочки, загружае
мым из Интернета с помощью команд
ить машину как клиент
$ curl -о
$ sudo sh
Salt,
/tшp/saltЬoot
curl, fetch
или
wget. 2
Например, чтобы настро
вы можете выполнить следующие команды:
-sL https://bootstrap.saltstack.com
/tшp/saltЬoot
Сценарий
bootstrap
исследует локальную среду, затем загружает, инсталлирует
и настраивает соответствующую версию программного обеспечения. Этот тип инстал
ляции особенно распространен в тех случаях, когда сам процесс сложен, но поставщик
очень мотивирован, чтобы облегчить пользователям работу. (Еще один хороший при
мер
- RVM,
III
см. ра~ел
7.7.)
Дальнейшую информацию об инсталляции пакетов см. в главе
6.
Этот метод установки отлично работает, но он поднимает несколько проблем, ко
торые стоит упомянуть. Во-первых, он не оставляет должной записи об инсталля
ции для будущих ссылок. Если ваша операционная система предлагает пакетную
версию программного обеспечения, обычно лучше установить пакет вместо запуска
веб-инсталлятора. Пакеты легко отслеживаются, обновляются и удаляются. (С другой
стороны, большинство пакетов на уровне операционных систем устарели. Вероятно, вы
не получите самую последнюю версию программного обеспечения.)
III Более подробную информацию о цепочке доверия НТТРS см. в разделе 27.6.
Будьте очень подозрительными, если URL-aдpec загрузочного сценария небезопасен
(т.е. он не начинается с префикса
мым для захвата, а
U RL-aдpeca
https: ).
Незащищенный НТГР является легкоуязви
инсталляции представляют особый интерес для хакеров,
потому что они знают, что вы, скорее всего, будете работать в качестве привилегиро
ванного пользователя, независимо от того, какой код возвращается. В отличие от этого,
протокол НТГРS проверяет подлинность сервера с помощью криптографической це
почки доверия. Это не вполне, но достаточно надежный способ.
Некоторые продавцы публикуют URL-aдpec инсталляции по протоколу НТТР. кото
рый автоматически перенаправляет пользователя на НТГРS-версию. Это глупо и на самом
деле не более безопасно, чем прямой адрес НlТР. Ничто не мешает перехвату исходного
НlТР-обмена, поэтому вы, возможно, никогда не достигнете перенаправления поставщика.
Однако наличие таких переадресаций означает, что стоит попробовать собственную замену
https для http в небезопасных
URL-aдpecax. Чаще всего это работает отлично.
Оболочка принимает текст сценария как свой стандартный вход, и эта функция по
зволяет использовать процедуры инсталляции в режиме онлайн, например:
$ curl -L https://badvendor.com 1 sudo sh
2 Эrо
все простые НТТР-клиенты, загружающие содержимое URL-aдpeca в локальный файл или
(необязательно) распечатывающие содержимое в виде результата своей работы.
Глава
1. С
чего начать
65
Тем не менее существует потенциальная проблема, связанная с этой конструкци
ей,
корневая оболочка все еще работает, даже если команда
-
ный сценарий, а затем терпит неудачу
-
curl
выводит частич
скажем, из-за кратковременного сбоя сети.
Конечный результат непредсказуем и потенциально не очень хорош.
Нам неизвестны какие-либо документированные случаи проблем, связанных с этой
причиной. Тем не менее это правдоподобный режим отказа. Более того, направление
результатов работы команды
curl
в оболочку в среде системных администраторов рас
сматривается как типичный промах новичков, поэтому, если вы это сделаете, никому
об этом не говорите.
Исправить ситуацию легко: просто сохраните сценарий во временном файле, а затем
запустите сценарий на отдельном этапе после успешного завершения загрузки.
1.11.
ГДЕ РАЗМЕСТИТЬ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Операционные системы и программное обеспечение могут размещаться в частных
центрах обработки данных, на объектах совместного размещения, на облачной платфор
ме или в некоторой их комбинации. Наиболее быстро растущие начинающие компании
выбирают облако. У солидных предприятий, вероятно, есть центры обработки данных,
поэтому они могут организовать частное облако внутри организации.
Самый практичный выбор и наша рекомендация для новых проектов
-
это публич
ные облачные провайдеры. Они предоставляют множество преимуществ по сравнению
с центрами обработки данных.
•
•
•
Отсутствие капитальных затрат и низкие начальные эксплуатационные расходы.
Отсутствие необходимости устанавливать, защищать и управлять оборудованием.
Регулировка емкости, пропускной способности и вычислительной мощности
по требованию.
•
Готовые решения для общих вспомогательных потребностей, таких как базы дан
ных, балансировки нагрузки, очереди, мониторинг и т.д.
•
Более дешевая и простая реализация высокодоступных или избыточных систем.
Ранние облачные системы имели репутацию слабо защищенных и низкопроизводи
тельных, но это уже не является серьезной проблемой. В наши дни большая часть адми
нистративной работы выполняется в облаке (см. главу
9 для
общего введения в тему).
Наша предпочтительная облачная платформа является лидером в своей области:
Amazon Web Seivices (AWS). Gartner, ведущая исследовательская фирма по технологиям,
обнаружила, что AWS в десять раз превосходит всех конкурентов. AWS быстро внедряет
инновации и предлагает гораздо более широкий спектр услуг, чем любой другой постав
щик. Она также имеет отличную репутацию по обслуживанию клиентов и поддерживает
большое сообщество. На первых порах
AWS
предлагает бесплатный уровень обслужива
ния, включая использование в течение года маломощного облачного сервера.
Облачная платформа
Google (GCP)
активно совершенствует и продает свои про
дукты. Некоторые утверждают, что эта технология не имеет себе равных по сравнению
с другими поставщиками. Рост
пании
Google,
GCP
был медленным, отчасти благодаря репутации ком
отказавшейся поддерживать несколько популярных служб. Тем не менее
его удобные для клиента условия ценообразования и уникальные функции являются
привлекательными характеристиками.
Digita\Ocean -
это более простая служба, целью которой является высокая произ
водительность. Она ориентирована на разработчиков, которым
Digita\Ocean
предла-
Часть
66
1. Основы
администрирования
гает ясный интерфейс прикладного программирования, низкую цену и чрезвычайно
быструю загрузку. Разработчики
DigitalOcean -
ярые сторонники программного обеспе
чения с открытым исходным кодом, а их учебники и руководства по популярным интер
нет-технологиям являются одними из лучших.
1.12. СПЕЦИАЛИЗАЦИЯ
И СМЕЖНЫЕ ДИСЦИПЛИНЫ
Системные администраторы работают не в вакууме; создавать и поддерживать слож
ную сеть должна команда экспертов. В этом разделе описываются некоторые роли, ко
торые системные администраторы могут выполнять в соответствии со своими навыками
и возможностями. Некоторые администраторы предпочитают специализироваться в од
ной или нескольких из этих областей.
Ваша цель как системного администратора или как профессионала, работающего
в любой из этих смежных областей,
-
достижение целей организации. Не позволяйте
политике или иерархии мешать прогрессу. Лучшие администраторы решают проблемы
и свободно обмениваются информацией с другими.
Методология
Ш
DevOps
Дополнительную информацию о методологии
DevOps -
DevOps см.
в главе
31.
это не столько специфическая методология, сколько культура или фило
софия работы. Ее цель
-
повышение эффективности создания и поставки программ
ного обеспечения, особенно в крупных организациях, в которых существует множество
взаимосвязанных служб и команд. Организации, внедрившие методику
DevOps,
стиму
лируют интеграцию между инженерными командами и могут не делать различия между
разработкой и эксплуатацией или не придавать им значения. Эксперты, работающие
в этой области, ищут неэффективные процессы и заменяют их небольшими сценариями
оболочки или большими и громоздкими репозиториями
Chef.
Инженеры по надежности сайтов
Инженеры по надежности сайтов ставят на первое место время безотказной и пра
вильной работы. Мониторинг сети, развертывание программного обеспечения на про
изводстве, координация работ, планирование будущего расширения и аварийные от
ключения
-
все это лежит в основе этих крестоносцев доступности. Головной болью
инженеров по надежности сайта является единственная точка отказа.
Инженеры по безопасности
Инженеры по безопасности сосредоrочены на практической, повседневной стороне ин
формационной безопасности. Эrи люди устанавливают и используют инструменты дЛЯ по
иска уязвимых мест и мониторинга дЛЯ предотвращения сетевых атак. Они также участвуют
в имитации атак, чтобы оценить эффективность методов их профилактики и обнаружения.
Сетевые администраторы
Сетевые администраторы проектируют, устанавливают, настраивают и управляют се
п1м~1. Организации, в которых функционируют центры обработки данных, скорее всего,
будут использовать сетевых администраторов; это объясняется тем, что такие объекты
Глава
1. С
67
чего начать
имеют множество физических переключателей, маршрутизаторов, брандмауэров и дру
гих устройств, которым требуется управление. Облачные платформы также предлагают
множество сетевых опций, но обычно они не требуют специального администратора,
поскольку большая часть работы выполняется поставщиком.
Администраторы баз данных
Администраторы баз данных являются экспертами по установке и управлению про
граммным обеспечением баз данных. Они управляют схемами базы данных, выполняют
установки и обновления, настраивают кластеризацию, выбирают параметры для оптималь
ной производительности и помогают пользователям формулировать эффективные запросы.
Администраторы баз данных обычно владеют одним или несколькими языками запросов
и имеют опыт работы с реляционными и нереляционными
(NoSQL) базами данных.
Инженеры центра сетевых операций
Инженеры центра сетевых операций контролируют состояние крупных объектов
в режиме реального времени и отслеживают инциденты и сбои. Они принимают запро
сы на устранение ошибок от пользователей, выполняют обычные обновления и коорди
нируют действия других команд. Их чаще всего можно найти наблюдающими за пане
лью мониторов, на которых демонстрирутся графики и измерения.
Технические специалисты центров обработки данных
Технические специалисты центров обработки данных используют аппаратные сред
ства. Они получают новое оборудование, ведут инвентарный учет, следят за жизненным
циклом оборудования, устанавливают серверы в стойки, управляют кабелями, поддер
живают энергопитание и кондиционирование воздуха, а также выполняют ежедневные
операции по эксплуатации центра обработки данных. Системному администратору же
лательно дружить с техническими специалистами центров обработки данных, подпаивая
их кофе, энергетическими напитками и алкоголем.
Архитекторы
Системные архитекторы обладают глубокими знаниями в более чем одной обла
сти. Они используют свой опыт для разработки распределенных систем. Их должност
ные инструкции могут предусматривать определение зон безопасности и сегментацию,
устранение отдельных точек отказа, планирование будущего роста, обеспечение взаимо
действия между несколькими сетями и третьими сторонами, а также принятие решений,
касающихся всей организации. Хорошие архитекторы технически компетентны и обыч
но предпочитают внедрять и тестировать свои собственные проекты.
1.13. ЛИТЕРАТУРА
Аввотт, МлRПN L., AND М1снлн Т. F1sHER. The Art of Scalabllity: Sса!аЬ/е Web
Architecture, Processes, and Organizations for the Modern Enterprise (2nd Edition).
Addison-Wesley Professional, 2015.
• GлNcлRZ, М1кЕ. Linux and the Unix Philosophy. Boston: Digital Press, 2003.
• L1моNСЕШ, Тномлs А., AND РЕТЕR Sлшs. The Comp/ete April Fools' Day RFCs.
•
Часть
68
• Peer-to-Peer Communications LLC. 2007.
можно свободно прочитать на сайте
1. Основы администрирования
Юмор инженеров. Эту коллекцию историй
rfc-humor. com.
RAvмoND, ERJc S. The Cathedral & The Bazaar: Musings оп Linux and Ореп Source Ьу ап
Accidental Revolutionary. Sebastopol, СА: O'Reilly Media, 2001.
• SAшs, РЕТЕR Н. The Daemon, the GNU & the Penguin: How Free and Ореп Software
is Changing the World. Reed Media Services, 2008. Это увлекательная история борьбы
за открытый исходный код, написанная самым известным историком UNIX, так
же доступна на сайте groklaw. com под лицензией Cгeative Commons. Адрес URL
•
для самой книги довольно длинный; найдите текущую ссылку на сайте
или попробуйте этот сжатый эквивалент:
com
• SIEVER, ELLEN, STEPHEN FюGJNS, RoвERT LovE, AND ARNOLD
(бth Edition). Sebastopol, СА: O'Reil\y Media, 2009.
Roвв1Ns.
Системное администрирование и методология
•
groklaw.
tinyurl. com/dбu7j ).
Linux in а Nutshell
DevOps
К1м,
/Т,
GENE, KEVIN BEHR, AND GF.ORGE SPAFFORD. The Phoenix Project: А Novel about
DevOps, and Helping Your Business Win. Portland, OR: 1Т Revolution Pгess, 2014.
Введение в философию и принципы создания современной IТ-организации, на
писанная в повествовательном стиле. Непреходящая классика.
GENE, JEZ НuмвLЕ, PATRICK DEвo1s, AND JoнN W1LL1s. The DevOps Handbook:
to Create World-Class Agility, Reliabllity, and Security iп Technology Organizations.
Portland, OR: 1Т Revolution Press, 2016.
• L1мoNCELLI, ТномАs А., CHRISТINA J. HoGAN, AND SтRATA R. СнАШР. The Practice о/
System and Network Administration (2nd Edition). Reading, МА: Addison-Wesley, 2008.
•
К1м,
Ноw
Это хорошая книга, в которой очень подробно описаны организационные и про
цедурные аспекты системного администрирования Авторы ведут блог, посвящен
ный системному администрированию:
•
everythingsysadmin. com.
L1мoNCELLI, ТномАs А., CнRISТINA
J. HoGAN, AND SтRАтА R. СнАШР. The Practice о/
Cloud System Administration. Reading, МА: Addison-Wesley, 2014. Книга предыдущих
авторов, посвященная распределенным системам и облачным вычислениям.
Важные инструменты
AND СнюsпNЕ BRESNAHAN. Linux Command Line and She/l Scripting
Edition). Wiley, 2015.
• DouaнERТY, DALE, AND ARNOLD Roв1Ns. Sed & Awk (2nd Edition). Sebastopol, СА:
O'Reilly Media, 1997. Классическая книга издательства O'Reilly о мощных и ши
•
BLuм, R1cнARD,
ВiЫе (Зrd
роко распространенных текстовых процессорах
и
awk.
The Hacker Playbook 2: Practical Guide То Penetration Testing. CreateSpace
lndependent PuЫishing Platform, 2015.
• Nш., DREW. Practical Vim: Edit Text at the Speed о/ Тhought. Pragmatic Вookshelf, 2012.
• S1ютrs, WILLIAM Е. The Linux Command Line: А Complete lntroduction. San Francisco,
СА: No Starch Press, 2012.
• SwEIGART, А1.. Automate the Boring Stuff with Python: Practica/ Programming for Total
Beginners. San Francisco, СА: No Starch Pгess, 2015.
•
Кlм, РЕТЕR.
sed
Глава 2
Загрузка и системные демоны
"Загрузка"
(booting) -
это стандартный термин, означающий запуск компьютера. Он
представляет собой сокращенную форму слова "самозагрузка"
(bootstrapping),
которое
подразумевает, что компьютер должен "привести себя в рабочее состояние с помощью
собственных программ начальной загрузки
(bootstraps)".
Процесс загрузки состоит из нескольких задач, определенных в широком смысле.
•
•
•
•
Поиск, ввод в память и запуск кода начальной загрузки.
Поиск, ввод в память и запуск ядра операционной системы.
Активирование сценариев запуска и системных демонов.
Поддержание порядка управление переходами системы из одного состояния
в другое.
Действия, указанные в последнем пункте, продолжаются до тех пор, пока система
остается в рабочем состоянии, поэтому граница между загрузкой и нормальной работой
по своей сути немного размыта.
2.1.
ОБЗОР ПРОЦЕССА ЗАГРУЗКИ
Процедуры запуска в последние годы сильно изменились. Появление современных
BIOS
с поддержкой
UEFI (Unified
ExtensiЫe
Firmware lnterface -
унифицированный
интерфейс расширяемой прошивки) упростило ранние этапы загрузки, по крайней
мере с концептуальной точки зрения. На более поздних этапах большинство дистрибу-
70
Часть
тивов
Linux
1. Основы
администрирования
теперь используют демон системного менеджера под названием
вместо традиционного демона
UNIX init.
Помимо всего прочего, менеджер
systemd
systemd
упрощает процесс загрузки путем добавления управления зависимостями, поддержки
одновременных процессов запуска и комплексного подхода к протоколированию.
Управление загрузкой также изменялось по мере того, как системы мигрировали
в облако. Дрейф в сторону виртуализации, облачных экземпляров и контейнеризации
уменьшил потребность в том, чтобы администраторы касались физического оборудова
ния. Вместо этого у нас теперь есть управление изображениями, интерфейсы
API
и па
нели управления.
Во время начальной загрузки ядро загружается в память и начинает выполняться.
При этом выполняется множество задач инициализации, и затем система становится
доступной для пользователей. Общий обзор этого процесса показан на рис.
Создать структуры
Загрузить ядро
Загрузить
данных ядра
Опредеnить,какое
BIOS/UEFI
Запусrить ini t/
изNVRАМ
ядро загрузить
Собрать сведения
Загрузить BIOS/UEFI
Выполнить
об аппаратуре
изNVRAM
щенарии запуска
Выбрать устройства для
Рис.
systemd
Идентифицировать
запуска (диск, сеть, •.. )
системный раздеn
2.1.
2.1.
EFI
Процессы загрузки
как PID 1
Запусrить систему
Unux и Unix
Администраторы не имеют средств для прямого интерактивного управления боль
шинством действий, необходимых для загрузки системы. Вместо этого администраторы
могут изменять конфигурации загрузчиков, редактируя файлы конфигурации для сцена
риев запуска системы или изменяя аргументы, которые загрузчик передает ядру.
Прежде чем система будет полностью загружена, должны быть проверены и смон
тированы файловые системы и запущены системные демоны . Этими процедурами
управляет набор сценариев оболочки (иногда называемых "сценариями
файлы, которые запускаются последовательно с помощью демона
зируются менеджером
systemd.
ini t") либо
init или анали
Точная компоновка сценариев запуска и способ их
выполнения зависит от операционной системы. Подробности изложены в этой главе
ниже.
2.2. СИСТЕМНЫЕ
ПРОШИВКИ
При включении компьютера процессор выполняет загрузочный код, хранящийся
в постоянном запоминающем устройстве. В виртуальных системах это постоянное запо
минающее устройство может быть виртуальным, но концепция остается прежней .
глава
2.
загрузка и системные демоны
71
Прошивка системы, как правило, знает обо всех устройствах, которые подклю
чены к материнской плате, таких как контроллеры
SATA,
сетевые интерфейсы, USВ
контроллеры и датчики для питания и температуры 1 • Помимо возможности аппаратной
настройки этих устройств, прошивка позволяет вам либо сообщить о них операционной
системе, либо отключить и скрыть их.
На физическом (в отличие от виртуального) оборудовании большинство проши
вок предлагает пользовательский интерфейс. Тем не менее оно, как правило, слиш
ком простое и неудобное. Для работы с ним необходимо иметь доступ к компьютеру
и консоли, а также сразу же нажать на конкретную клавишу после включения системы.
Ксожалению, "золотой ключик" у каждого производителя свой; проверьте, сможете ли
вы разобраться в загадочной строке инструкций в тот момент, когда система включится
впервые 2 • Если не сможете, попробуйте клавиши
или
, , , ,
Для увеличения шансов на успех коснитесь клавиши несколько раз, затем
.
удерживайте ее нажатой.
Во время обычной начальной загрузки система прошивки проверяет аппаратное обе
спечение и диски, запускает простой набор проверок работоспособности, а затем ищет
следующий этап кода начальной загрузки. Пользовательский интерфейс прошивки по
зволяет назначить загрузочное устройство, как правило, путем определения приоритетов
списка доступных параметров (например, "попробуйте загрузить с DVD-привода, затем
с USВ-диска, а затем с жесткого диска").
В большинстве случаев системные диски входят в список вторичных приоритетов. Для
загрузки с определенного диска необходимо смонтировать его как диск с самым высоким
приоритетом и убедиться, что в качестве загрузочного носителя включен "жесткий диск".
BIOS
или
UEFI
В прошлом обычная прошивка для персонального компьютера называлась
(Basic lnput/Output System).
Однако за последнее десятилетие термин
нен более формализованным и современным стандартом
тить термин
"UEFI BIOS",
- UEFI.
поддерживает
UEFI -
BIOS,
BIOS
был вытес
Часто можно встре
но для ясности в этой главе мы зарезервируем термин
для устаревшего стандарта. Большинство систем, реализующих
к устаревшей реализации
BIOS
UEFI,
BIOS
могут вернуться
если операционная система, которую они загружают, не
UEFI.
это текущая версия предыдущего стандарта
EFI.
Ссьmки на имя
EFI
сохра
няются в некоторых старых документах и даже в некоторых стандартных терминах, та
ких как "системный раздел
EFI".
Во всех, кроме самых очевидных ситуаций, эти терми
ны можно рассматривать как эквивалентные.
В наши дни поддержка
UEFI
довольно типична для новых персональных компью
теров, но в мире существует очень много систем
часто используют
BIOS
BIOS.
Более того, виртуальные среды
в качестве основного механизма загрузки, поэтому мир
BIOS
еще не находится под угрозой исчезновения.
Поскольку мы предпочли бы игнорировать
BIOS
и говорить только об
UEFI,
вполне
вероятно, что вы столкнетесь с обоими типами систем еще в течение довольно долгого
времени.
знания
UEFI также интегрирует в себя некоторые функции BIOS, поэтому рабочие
BIOS могут быть весьма полезны для расшифровки документации UEFI.
1Виртуальные
2 Возможно,
системы имитируют, что имеют такой же набор устройств.
вам будет полезно временно отключить функции управления питанием монитора.
Часть
72
Устаревший интерфейс
Традиционный
1. Основы администрирования
BIOS
BIOS предполагает, что загрузочное устройство начинается с записи
MBR (Master Boot Record). MBR содержит первичный загрузчик
(сектора), называемой
("bootЬ\ock") и простую таблицу разделов диска. Объем свободного места для загрузчи
ка настолько мал (менее
512
байт), что он не может выполнять ничего, кроме загрузки
и запуска вторичного загрузчика.
Из-за ограниченности размера ни загрузочный сектор, ни
BIOS
не могут обрабаты
вать записи любой стандартной файловой системы, поэтому вторичный загрузчик должен
храниться там, где его легко найти. В одном типичном сценарии загрузочный сектор счи
тывает информацию о разбиении диска из
MBR
и идентифицирует раздел диска, поме
ченный как "активный". Затем он считывает и выполняет вторичный загрузчик с самого
начала этого раздела. Эта схема называется загрузочной записью тома
11) Разбиение диска ле
(volume Ьооt record).
ЭТО способ разделения физического диска. Детали СМ. В разде
20.5.
В качестве альтернативы вторичный загрузчик может находиться в "мертвой зоне",
которая расположена между
MBR
и началом первого раздела диска. По историческим
причинам первый раздел не начинается до 64-го сектора диска, поэтому эта зона обыч
но содержит минимум
32
Кбайт памяти: все еще не много, но достаточно для хране
ния драйвера файловой системы. Эта схема хранения обычно используется загрузчиком
GRUB
(см. раздел
2.4).
Для успещной загрузки все компоненты загрузочной цепочки должны быть правиль
но установлены и совместимы друг с другом. Загрузочный сектор
MBR
ничего не знает
об операционной системе, но, поскольку он предполагает определенное местоположе
ние для второго этапа, может быть установлено несколько версий. Вторичный загруз
чик, как правило, хорошо осведомлен об операционных системах и файловых системах
(он может поддерживать несколько из них) и обычно имеет собственные параметры
конфигурации.
UEFI
Спецификация
ную как
GPT
UEFI
включает в себя современную схему разделения диска, извест
(таблица разделов
GUID,
где
GUID (global\y unique identifier) обознача
UEFI также понимает файловую систему
ет "глобально уникальный идентификатор").
FAT (File Allocation ТаЬ\е), простую, но функциональную схему, впервые примененную
MS DOS. Эти функции объединяются для определения концепции системного раздела
EFI (ESP - EFI System Partition). Во время загрузки микропрограмма обращается к та
блице разделов G РТ для идентификации ESP. Затем она считывает настроенное целевое
приложение непосредственно из файла в ESP и выполняет его.
в
W Дополнительную информацию о разделах GPT см. в разделе 20.б.
Поскольку
ESP
представляет собой общую файловую систему FАТ, ее можно смон
тировать, прочитать, записать и поддерживать в любой операционной системе. Никакие
скрытые загрузочные сектора на диске не требуются. 3
1 По
правде говоря, для облегчения взаимодействия с системами
BIOS
спецификация
UEFI
предусматривает МВR-совместимую запись в начале каждого диска. Системы BIOS не могут
видеть полную таблицу разделов в стиле G РТ, но они, по крайней мере, распознают диск как
отформатированный. Будьте осторожны, не запускайте определенные административные
инструменты для
MBR на дисках GP'I
Они могут неправильно интерпретировать структуру диска.
Глава
2. Загрузка
и системные демоны
73
Фактически никакой загрузчик вообще не требуется. Целью загрузки
быть ядро
UNIX или Linux,
которое настроено для прямой загрузки
UEFI,
UEFI
может
что приводит
к загрузке без загрузчика. На практике, однако, большинство систем по-прежнему ис
пользуют загрузчик, отчасти потому, что он упрощает поддержку совместимости с уста
ревшими
BIOS.
Интерфейс
UEFI
сохраняет имя пути для загрузки из
ESP
конфигурации. Если этот параметр не задан, используется
временных системах
lntel
обычно это путь
/efi/boot/bootx64 .efi.
ный путь в системе с заданной конфигурацией (для
/efi/ubuntu/grubx64. efi.
в качестве параметра
стандартный путь, в со
Более типич
и загрузчика
Ubuntu
GRUB) -
Другие дистрибутивы придерживаются аналогичного
соглашения.
Интерфейс
UEFI
определяет стандартные интерфейсы
API
для доступа к аппарат
ным средствам системы. В этом отношении он представляет собой нечто вроде ми
ниатюрной операционной системы. Он даже обеспечивает наличие дополнительных
драйверов устройств на уровне
от процессора, и сохраняются в
фейс
UEFI
UEFI, которые записываются на языке, не зависящем
ESP. Операционные системы могут использовать интер
или напрямую управлять оборудованием.
Поскольку
UEFI
имеет формальный интерфейс
API,
переменные
UEFI
можно про
верять и изменять (включая записи загрузочного меню) уже в загруженной системе.
Например, команда
Boot0004* ubuntu HD(l,GPT,020c8d3e-fd8c-4880-9b61ef4cffc3d76c,Ox800,0xl00000)/File(\EFI\ubuntu\shimx64 .efi
Команда
efibootmgr
позволяет изменить порядок загрузки, выбрать следующий
настроенный параметр загрузки или даже создать и уничтожить загрузочные записи.
Например, установить порядок загрузки так, чтобы сначала обращаться к системному
диску, а потом
-
к сети, игнорируя другие параметры загрузки, можно с помощью ко
манды
$ sudo efibootmgr
-о
0004,0002
Здесь мы указываем параметры
Boot0004
Возможность изменять конфигурацию
и
Boot0002
UEFI
из выведенных выше данных.
из пользовательского пространства оз
начает, что информация о конфигурации прошивки может как читаться, так и записы
ваться
-
это и благословение, и проклятие. В системах, разрешающих доступ на запись
по умолчанию (как правило, с помощью менеджера
systemd),
команды
rm -rf /
мо
жет быть достаточно, чтобы навсегда уничтожить систему на уровне прошивки; в допол
нение к удалению файлов команда
UEFI,
4Для
доступную через
/sys 4•
rm также
удаляет переменные и другую информацию
Не пытайтесь повторить это дома!
получения дополнительной информации см.
goo. g 1 / QMS i SG
(ссьmка на статью Phoroпix).
74
Частьl.Основыадминистрирования
2.3. ЗАГРУЗЧИКИ
Большинство процедур начальной загрузки включают в себя выполнение загрузчика,
который отличается от кода
BIOS/UEFI
и ядра операционной системы. Он также отде
лен от начального загрузочного сектора в
Основное задание загрузчика
-
BIOS,
если вы считаете этапы.
определить и загрузить соответствующее ядро опера
ционной системы. Большинство загрузчиков также могут предоставлять пользователь
ский интерфейс загрузки, который позволяет выбирать, какое из нескольких возмож
ных ядер или операционных систем вызвать.
Другая задача загрузчика
-
это маршалинг
(marshaling)
аргументов конфигурации
для ядра. Ядро не имеет командной строки как таковой, но обработка его параметров
запуска может показаться довольно похожей на работу с оболочкой. Например, аргу
мент
single
или
-s
обычно указывает ядру войти в однопользовательский режим, а не
выполнять нормальный процесс загрузки.
Такие параметры могут быть жестко привязаны к конфигурации загрузчика, если вы
хотите, чтобы они использовались при каждой загрузке, или предоставляться "на лету"
через пользовательский интерфейс загрузчика.
В следующих нескольких разделах мы обсудим
онной системы
Linux)
GRUB
(основной загрузчик операци
и загрузчики, используемые с системой
2.4. GRUB: УНИВЕРСАЛЬНЫЙ
FreeBSD.
ЗАГРУЗЧИК
GNU Project, является загруз
Linux. Линия GRUB
имеет два основных направления: оригинальный G RU В, теперь называе
мый GRUB Legacy, и новый GRUB 2, который является текущим стандар
том. Убедитесь, что вы знаете, с каким вариантом загрузчика GRUB вы име
GRUB (GRand Unified Boot),
разработанный
чиком по умолчанию для большинства дистрибутивов
ете дело, поскольку эти две версии совершенно разные.
GRUB 2
ная с версии
был загрузочным менеджером по умолчанию для системы
9.1 О,
Все наши примеры дистрибутивов
RHEL 7.
книге мы обсуЖДаем только
У системы
Однако
GRUB
Ubuntu,
начи
и недавно стал загрузочным менеджером по умолчанию для системы
FreeBSD
GRUB 2 и
Linux
используют его по умолчанию. В этой
называем его просто
GRUB.
есть собственный загрузчик (более подробно см. раздел
отлично справляется с загрузкой
FreeBSD.
2.5).
Это может оказаться удоб
ным, если вы планируете загружать несколько операционных систем на одном компью
тере. В противном случае загрузчика
Конфигурация
GRUB
FreeBSD
более чем достаточно.
GRUB
позволяет указать такие параметры, как загрузочное ядро (указанное в каче
стве записи меню
GRUB)
и режим работы для загрузки.
Поскольку эта информация о конфигурации необходима во время загрузки, можно
подумать, что она будет храниться где-то в необычном месте, например в энергонеза
висимой системной памяти
грузчика. На самом деле
NVRAM или в секторах диска, зарезервированных для за
GRUB понимает большинство используемых файловых систем
и обычно может самостоятельно найти корневую файловую систему. Это позволяет за
грузчику
GRUB
читать свою конфигурацию из обычного текстового файла.
Глава
2. Загрузка
75
и системные демоны
Конфигурационный файл называется gruЬ. cfg, и его обычно хранят в каталоге
gruЬ (/boot/gruЬ2 в системах
Red Hat
и
/boot/
вместе с выбором других ресурсов и мо
CentOS)
G RU В может потребовать для доступа во время загрузки. 5 Изменение
- это простой вопрос об обновлении файла gruЬ. cfg.
Хотя можно создать файл grub. cfg самостоятельно, чаще всего его проще гене
рировать с помощью утилиты grub-mkconfig, которая называется grub2-mkconfig
в системах Red Hat и CentOS и update-gruЬ в системах Deblan и Ubuntu. Фактически
большинство дистрибутивов предполагают, что файл gruЬ. cfg может быть регенериро
дулей кода, которые
конфигурации загрузки
ван по желанию, и они делают это автоматически после обновлений. Если вы не пред
примете никаких шагов, чтобы предотвратить это, ваш файл
Как обычно в системе
mkconfig
Linux,
grub. cfg
будет испорчен.
дистрибутивы задают конфигурацию утилиты
различными способами. Чаще всего конфигурация задается в каталоге
default/gruЬ в виде присваивания переменных
sh.
В табл.
2.1
grub/etc/
показаны некоторые из
часто изменяемых опций.
Таблица
2.1.
Общие параметры конфиrурации
в файле
/ etc/ defaul t/ gruЬ
Обозначение переменной оболочки
Содержимое или функция
GRUB BACKGROUND
Фоновое изображение•
GRUB _ CMDLINE _ LINUX
Параметры ядра для добавления в записи меню для
GRUB DEFAULT
Номер или название элемента меню по умолчанию
GRUB DISABLE RECOVERY
Предотвращает создание записей режима восстановления
GRUB,
Linux6
загружаемых как можно раньше
GRUB_ PRELOAD _ MODULES
Список модулей
GRUB TIМEOUT
Секунды для отображения меню загрузки перед автозагрузкой
•Фоновое изображение должно иметь формат
6
GRUB
. pnq, . tqa, • jpq или . jpeq.
8 табл. 2.3 в разделе 3.4 перечислены некоторые из доступных опций.
Ш
Подробнее о режимах работы см. раздел 2.7.
После редактирования каталога
/etc/default/grub
запустите утилиты
update-
gruЬ или gruЬ2-mkconfig, чтобы перевести вашу конфигурацию в правильный файл
gruЬ. cfg. В рамках процесса построения конфигурации эти команды проверяют загру
зочные ядра системы, поэтому они могут быть полезны для запуска после внесения из
менений ядра, даже если вы явно не изменили конфигурацию
GRUB.
Возможно, вам потребуется отредактировать файл /etc/gruЬ.d/40_custom, чтобы
изменить порядок, в котором ядра указаны в меню загрузки (например, после созда
ния настраиваемого ядра), установить пароль для загрузки или изменить имена пунктов
меню загрузки. Как обычно, после внесения изменений запустите утилиты
update-
gruЬ или gruЬ2-mkconfig.
Например, вот как выглядит файл
ядро в системе
40_custom,
который вызывает пользовательское
Ubuntu.
'Если вы знакомы с соглашениями файловой системы
UNIX
(см. главу
5),
то можете задаться
вопросом, почему каталог /boot/qruЬ не назван как-то более стандартно, например
/var/lib/
qruЬ или /usr/local/etc/gruЬ. Причина в том, что драйверы файловой системы, используемые
во время загрузки, несколько упрощены. Загрузчики не могут обрабатывать дополнительные
функции, такие как точки монтирования, когда они обходят файловую систему. Все в каталоге
/boot должно быть
простым файлом или каталогом.
Часть
76
1. Основы
администрирования
#!/Ьin/sh
ехес
tail -n +3 $0
Jt This file provides an easy way to add custom menu entries. Just type
Jt the menu entries you want to add after this comment. Ве careful not to
Jt change the 'ехес tail' line above.
menuentry 'Му Awesome Kernel'
set root=' (hdO,msdosl)'
linux
/awesome_kernel root=UUID=XXX-XXX-XXX ro quiet
initrd
/initrd.img-awesome_kernel
W Для получения дополнительной информации о монтировании файловых систем см.
раздел 5.1.
В этом примере
GRUB
загружает ядро из каталога
/awesome_kernel.
Пути к ядру
являются относительными и связаны с загрузочным разделом который исторически
монтировался как
но с появлением
/boot,
монтированным системным разделом
EFI.
UEFI
теперь, скорее всего, он является де
Для проверки вашего диска и определения
состояния загрузочного раздела используйте команды
Командная строка
GRUB
gpart show
и
mount .
GRUB
поддерживает интерфейс командной строки для редактирования записей
в файле конфигурации "на лету" во время загрузки. Чтобы войти в режим командной
строки, введите команду с на экране загрузки
G RUB.
Вкомандной строке можно загружать операционные системы, которые не указаны
в файле
grub. cfg,
отображать системную информацию и выполнять рудиментарное
тестирование файловой системы. Все, что можно сделать через файл
grub. cfg,
также
можно выполнить с помощью командной строки.
Нажмите клавишу , чтобы просмотреть список возможных команд. Некоторые
наиболее полезные команды показаны в табл.
Таблица
2.2.
Команды
2.2.
GRUB
Команда
Функци•
boot
help
linux
Загружает систему из указанного образа ядра
reЬoot
Перезагружает систему
search
usb
Поиск устройств по файлу, метке файловой системы или
Получает интерактивную помощь для команды
Загружает ядро
Linux
Проверка поддержки
UUID
USB
Для получения подробной информации о
GRUB и параметрах командной строки об
gnu. org/software/gruЬ/manual.
ратитесь к официальному руководству по адресу
Параметры ядра
Linux
Параметры запуска ядра обычно изменяют значения параметров ядра, инструкти
руют ядро проверять определенные устройства, указывать путь к процессу
systemd либо
назначать определенное корневое устройство. В табл.
сколько примеров.
2.3
ini t
или
приведено не
Глава
2. Загрузка
Таблица
2.3.
и системные демоны
77
Примеры параметров времени загрузки ядра
Опция
Значение
debug
Включает отладку ядра
init=/Ьin/bash
Запускает только оболочку bash; полезна для аварийного восстановления
root=/dev/foo
single
Загрузка в однопольэовательском режиме
Инструктирует ядро использовать
/dev/foo в качестве корневого устройства
Если параметры ядра задаются во время загрузки, они не являются постоянными.
· Для
того чтобы сделать изменение постоянным при перезагрузке, отредактируйте соот
ветствующую строку ядра в файле /etc/gruЬ.d/40
custom или /etc/defaults/gruЬ
(переменная с именем GRUB_ CMDLINE _ LINUX).
В ядро Linux постоянно добавляются заплатки безопасности, исправления ошибок
и новые функции. Однако в отличие от других пакетов программного обеспечения но
вые версии ядра обычно не заменяют старые. Вместо этого новые ядра устанавливаются
наряду с предыдущими версиями, так что в случае возникновения проблем можно вер
нуться к старому ядру.
Это соглашение помогает администраторам отказаться от обновления, если заплатка
ядра разрушает их систему, хотя это также означает, что загрузочное меню имеет тенден
цию сохранять старые версии ядра. Попробуйте выбрать другое ядро, если ваша система
не будет загружаться после обновления.
Подробнее о параметрах ядра см. в главе
2.5.
•
ПРОЦЕСС ЗАГРУЗКИ
Система загрузки
11.
FREEBSD
FreeBSD
во многом похожа на
конечной стадии (под именем
loader)
GRUB,
поскольку загрузчик
использует файл конфигурации на ос
нове файловой системы, поддерживает меню и предлагает интерактивный
режим командной строки. Загрузчик
вариантов загрузки
Вариант
BIOS
и
loader -
это последнее пересечение
UEFI.
BIOS: bootO
Как и в случае с интерфейсом
G RUB,
полная среда загрузчика
лика для размещения в загрузочном секторе
MBR,
поэтому в
BIOS
loader
слишком ве
постепенно загружа
ется и запускается цепочка более сложных предварительных загрузчиков.
Интерфейс
GRUB объединяет все эти компоненты под общим названием "GRUB",
FreeBSD ранние загрузчики являются частью отдельной системы под на
bootO, которая используется только в системах BIOS. Система bootO имеет
но в системе
званием
свои собственные опции, главным образом потому, что она хранит более поздние этапы
цепочки загрузки в загрузочной записи тома (см. раздел "Устаревший интерфейс
в разделе
2.2),
BIOS"
а не перед первым дисковым разделом.
По этой причине для загрузочной записи
MBR
нужен указатель на раздел, который
необходимо использовать для продолжения процесса загрузки. Как правило, все это ав
томатически настраивается как часть процесса установки
FreeBSD,
но если вам когда
либо понадобится настроить конфигурацию, это можно сделать с помощью команды
bootOcfg.
1. Основы администрирования
часть
78
Вариант
UEFI
Операционная система
ный раздел
EFI
FreeBSD,
использующая интерфейс
UEFI,
создает систем
и устанавливает там заrрузочный код в файле /Ьооt/Ьооtхб4
путь по умолчанию, который проверяют системы
UEFI
.ef"i. 6 Это
во время заrрузки (по крайней
мере на современных платформах персональных компьютеров), поэтому никакой кон
фиrурации прошивки не требуется, за исключением правильно установленных приори
тетов заrрузки устройств.
По умолчанию система
EFI после
gpart.
FreeBSD
не сохраняет смонтированным системный раздел
заrрузки. Таблицу разделов можно идентифицировать с помощью команды
Хотя существует возможность подключить системный раздел
в нем содержится (используя команду
mount -t msdos),
ESP,
чтобы узнать, что
вся файловая система
-
это
всеrо лишь копия образа, найденного в файле /Ьoot/bootl. ef"if"at на корневом дис
ке. Внутри нет деталей, которые пользователь мог бы изменить.
W
Для получения дополнительной информации о монтировании файловых систем см.
раздел
5.1.
Если раздел
ESP
поврежден или удален,
дел с помощью команды
щью команды
gpart,
ero
можно повторно создать, настроив раз
а затем скопировав образ файловой системы с помо
dd:
$ sudo dd if=/boot/bootl.efifat of=/dev/adaOpl
Как только начальный заrрузчик первого этапа
uf s 7,
UEFI находит раздел типа freebsdloader из файла /Ьoot/loader. ef"i. С это
так же, как под управлением BIOS: заrрузчик
он заrружает UЕFl-версию проrраммы
го момента загрузка выполняется точно
loader определяет,
какое ядро следует заrрузить, устанавливает параметры ядра и т.д.
Конфигурация загрузчика
Заrрузчик
loader на самом деле является средой сценариев на языке Forth. 8 Внутри
каталога /boot хранится код на языке Forth, управляющий операциями заrрузчика, но
он вполне самодостаточный - вам не нужно изучать Forth.
Чтобы получить значения переменных конфиrурации, сценарии на языке Forth счи
тывают файл /boot/loader. conf", поэтому задавать их следует именно здесь. Не путай
те этот файл с файлом /boot/def"aults/loader.conf", который содержит настройки
по умолчанию и не предназначен для изменения. К счастью, присваивания переменных
6 Не
пуrайте каталог /boot в системном разделе EFI с каталогом /boot в корневой файловой
системе FreeBSD. Они отделены друг от друга и служат различным uелям, хотя, конечно, оба
связаны с начальной загрузкой.
7 Начиная
с версии
использовать
FreeBSD 10.1,
в качестве корневого раздела в системе
UEFJ
можно
ZFS.
"Это замечательный и интересный факт, имеющий значение лишь для людей, интересующихся историей
языков программирования.
Глава
2. Загрузка
в файле
и системные демоны
loader. conf
sh.
79
синтаксически похожи на стандартные операции присваивания
в оболочке
Справочные mаn-страницы о загрузчике
loader
и файле
loader. aonf
содержат
информацию обо всех параметрах загрузчика и переменных конфигурации, которые
их контролируют. Некоторые из наиболее интересных вариантов защищают меню за
грузки паролем, меняют экран заставки, отображаемый при загрузке, и передают па
раметры ядра.
Команды загрузчика
loader
Загрузчик понимает различные интерактивные команды. Например, чтобы найти
и загрузить альтернативное ядро, необходимо использовать последовательность следу
ющих команд:
Туре
ок
'?' for
а
list of commands, 'help' for more detailed help.
ls
1
d .snap
d dev
d rescue
1 home
unload
load /boot/kernel/kernel.old
/boot/kernel/kernel.old text=Oxf8f898 data=Oxl24 ...
ОК boot
ок
ОК
Ь077)
Здесь мы вывели содержимое корневой файловой системы (по умолчанию), вы
грузили ядро по умолчанию
{/boot/kernel/kernel), загрузили
{/boot/kernel/kernel. old) и продолжили процесс загрузки.
более старое ядро
Для получения полной документации о доступных командах выполните команду
man
loader.
2.6. ДЕМОНЫ УПРАВЛЕНИЯ СИСТЕМОЙ
После загрузки и завершения процесса инициализации ядро создает "спонтанные"
процессы в пользовательском пространстве. Они называются спонтанными, потому что
ядро запускает их автономно
-
при нормальном ходе событий новые процессы созда
ются только по воле существующих процессов.
Большинство спонтанных процессов действительно являются частью реализации ядра.
Они не обязательно соответствуют программам в файловой системе. Они не настраивают
ся и не требуют внимания со стороны системного администратора. Их можно распознать
в списках
ps (см. раздел 4.3) по низким значениям параметра PID и скобкам вокруг их имен
[pagedaemon] в системе FreeBSD или [kdump] в системе Linux).
(например,
Исключением из этого шаблона является демон управления системой. Он имеет
идентификатор процесса, равный
демону
ini t
1,
и обычно работает под именем
ini t.
Система дает
несколько специальных привилегий, но по большей части это просто про
грамма на уровне пользователя, как любой другой демон.
Часть
80
Обязанности демона
Демон
ini t
1. Основы
администрирования
ini t
имеет несколько функций, но его главной целью является обеспечение
того, чтобы система запускала правильные комплекты служб и демонов в любой момент
времени.
Для достижения этой цели
ini t
поддерживает понятие режима, в котором система
должна работать. Ниже перечислены некоторые общепринятые режимы 9 •
•
Однопользовательский режим, в котором монтируется только минимальный на
бор файловых систем, ни одна из служб не запущена, а на консоли запущена кор
невая оболочка.
•
Многопользовательский режим, в котором монтируются все обычные файловые
системы и запущены все настроенные сетевые службы, а также оконная система
и графический менедЖер входа в консоль.
•
Режим сервера, аналогичный режиму многопользовательского режима, но без ис
пользования графического пользовательского интерфейса на консоли.
Каждый режим связан с определенным комплектом системных служб, а демон ини
циализации запускает или останавливает службы по мере необходимости, чтобы при
вести фактическое состояние системы в соответствие с текущим активным режимом.
Режимы могут также иметь связанные с ними контрольные задачи, которые запускают
ся всякий раз, когда режим начинается или заканчивается.
Например, демон
ini t
обычно выполняет многие задачи, связанные с запуском,
в качестве побочного эффекта перехода от начальной загрузки к многопользовательско
му режиму. К ним могут относиться следующие задачи.
•
•
•
•
•
•
•
•
Установка имени компьютера.
Установка часового пояса.
Проверка дисков с помощью команды
fsck.
Монтирование файловых систем.
Удаление старых файлов из каталога
/tJnp.
Настройка сетевых интерфейсов.
Настройка фильтров пакетов.
Запуск других демонов и сетевых служб.
У демона
init очень мало
встроенных знаний об этих задачах. Он просто запускает
набор команд или сценариев, которые были назначены для выполнения в этом конкрет
ном контексте.
Реализации демона
ini t
В настоящее время широко используются три совершенно разных стиля в процессах
системного управления.
•
Стиль
init,
принятый в системе
System V UNIX компании АТ&Т, который мы
init". Этот стиль был преобладающим в систе
менедЖера systemd.
называем "традиционным стилем
мах
Linux до появления
''Не принимайте эти имена или описания режимов слишком буквально; это всего лишь примеры
общих режимов работы, которые большинство систем определяют так или иначе.
Глава
•
2. загрузка
Вариант
и системные демоны
81
который происходит от системы
ini t,
в большинстве ВSD-систем, включая
проверен временем, как и стиль
BSD UN IX и используется
FreeBSD, OpenBSD и NetBSD. Он так же
SysV ini t,
и имеет столько же прав называть
ся "традиционным", но для ясности мы называем
ero "BSD init". Этот вариант
SysV. Мы обсудим ero от
довольно прост по сравнению с инициализацией стиля
дельно в разделе
•
2.8.
Относительно недавно у демона
ini t
появился конкурент
-
менеджер
systemd,
целью которого является полное решение всех проблем, связанных с демонами
и состоянием системы. Как следствие, менеджер
systemd
захватил значительно
большую территорию, чем любая традиционная версия демона
ini t.
Это несколь
ко противоречивая ситуация, о которой мы поrоворим ниже. Тем не менее все
наши примеры дистрибутивов
Linux теперь содержат
менеджер
systemd.
Хотя эти реализации являются преобладающими в данный момент, они далеки
от того, чтобы быть единственным вариантом. Например, в операционной системе
macOS
компании
Apple
используется система инициализации с именем
в системе UЬuntu не бьm реализован менеджер
временный вариант демона
В системах
ini t
systemd,
под названием
Linux теоретически
launchd.
Пока
в ней использовался друrой со
Upstart.
можно заменить инициализацию по умолча
нию в зависимости от того, какой вариант вы предпочитаете. Но на прак
тике демон
ini t
настолько важен для работы системы, что многое до
полнительное программное обеспечение может выйти из строя. Если вы
не желаете использовать менеджер
systemd,
примите в качества стандарта
дистрибутив, который его не использует.
Традиционный стиль
ini t
В традиционном мире инициализации системные режимы (например, однополъзо
вательские или мноrополъзовательские) называются уровнями выполнения. Большинство
уровней выполнения обозначаются одной буквой или цифрой.
Традиционный стиль
init появился в начале 80-х гг. Его сторонники (т.е. против
systemd) часто ссьmаются на принцип: "Не сломалось чини". Тем не менее традиционный стиль ini t имеет ряд заметных недостатков.
Начнем с тоrо, что традиционный демон init сам по себе не настолько силен, чтобы
ники применения менеджера
не
справляться с потребностями современных операционных систем. Большинство систем,
которые
рацию
ero
ini t,
используют, на самом деле имеют стандартную и фиксированную конфигу
которая никогда не изменяется. Эта конфигурация ссылается на второй уро
вень сценариев оболочки, которые выполняют фактическую работу по изменению уров
ней выполнения и позволяют администраторам вносить изменения в конфигурацию.
Второй уровень сценариев поддерживает еще и третий уровень сценариев, связанных
с демоном и системой, которые привязаны к каталогам определенного уровня, указы
вающим, какие службы должны работать и на каком уровне запуска. Все это немного
запутанно и неизящно.
Говоря конкретно, эта система не имеет общей модели зависимостей между служ
бами, поэтому требуется, чтобы все запуски и демонстрации выполнялись в порядке,
заданном администратором. Более поздние действия не могут выполняться до тех пор,
пока не будут закончены все предыдущие, поэтому выполнять их параллельно невоз
можно, и система тратит много времени, чтобы изменить состояние.
Часть
82
Менеджер
systemd против
остального мира
Лишь немногие проблемы в области
от традиционного демона
init
1. Основы администрирования
Linux обсуждались более горячо, чем переход
systemd. По большей части, жалобы со
к менеджеру
средоточиваются на постоянно растущих масштабах системы.
Менеджер
systemd
осуществляет все функции
init,
ранее реализованные с помо
щью хитроумных уловок и приемов, и формализует их в единое целое, позволяя настра
ивать, получать доступ и управлять службами.
В качестве системы управления пакетами менеджер
systemd
определяет надежную
модель зависимостей не только среди служб, но и среди "целей". Этот термин исполь
зуется в контексте
ционного демона
systemd для описания режимов работы, которые в контексте тради
init назывались уровнями выполнения. Менеджер systemd не толь
ко управляет процессами параллельно, но также управляет сетевыми подключениями
(networkd),
записями журнала ядра
(journald) и авторизацией (logind).
systemd утверждают, что философия UNIX
Противники использования менеджера
заключается в том, чтобы системные компоненты были небольшими, простыми и мо
дульными. Говорят, что такой фундаментальный компонент, как
ini t
не должен иметь
монолитного контроля над многими другими подсистемами операционной системы.
Менеджер
systemd не
только порождает сложность, но и создает потенциальные не
достатки в области безопасности и препятствует разграничению между платформой опе
рационной системы и службами, которые работают на ее основе.
Ш
Дополнительную информацию об управлении пакетами см. в главе
Менеджер
в ядро
Linux,
systemd также
6.
критикуют за введение новых стандартов и обязанностей
качество кода, предполагаемую невосприимчивость его разработчиков
к сообщениям об ошибках, дизайн его основных функций и нелепый вид. Мы не можем
справедливо решить эти проблемы в этой книге, но читатели могут ознакомиться с аргу
ментами в разделе
Arguments against systemd по
ном сайте противников
адресу
without-systemd. org,
на основ
systemd.
Аргументы против
ini t
Архитектурные возражения против менеджера
systemd,
изложенные выше, явля
ются вполне разумными. Он действительно имеет большинство типичных недостатков
надстроенного программного проекта.
На практике, однако, многие администраторы очень любят использовать
systemd,
и мы относимся к этому лагерю. Оставьте на время полемику и предоставьте менеджеру
systemd
шанс завоевать ваше признание. Как только вы привыкнете к нему, вы, скорее
всего. оцените его многочисленные преимущества.
По крайней мере, имейте в виду, что традиционный демон
ся менеджером
systemd,
init,
который вытесняет
не был идеальным. Помимо всего прочего, менеджер
просто устраняет несколько ненужных различий между дистрибутивами
systemd
Linux.
Дебаты действительно не имеют значения, потому что соревнование завершено.
Аргументы против использования
systemd потеряли силу, когда на него переключились
Red Hat, Deblan и Ubuntu. Многие другие дистрибутивы Linux теперь принима
systemd либо вольно, либо невольно.
Традиционный демон ini t по-прежнему играет определенную роль, если дистрибу
системы
ют
тив либо нацелен на небольшой размер инсталляции, либо не нуждается в расширенных
функциях управления процессом
systemd.
Также существует значительное количество
глава
2. Загрузка
и системные демоны
83
реваншистов, которые презирают систему из принципа, поэтому некоторые дистрибу
тивы
Linux
обязательно будут поддерживать традиционную инициализацию в течение
неопределенного срока в качестве формы протеста.
Тем не менее мы не считаем, что традиционный демон
ini t имеет будущее, чтобы
Linux мы в основном огра
заслужить подробное обсуждение в этой книге. Для системы
ничиваемся менеджером
systellld.
Мы также обсудим очень простую систему инициализации, используемую
в разделе
FreeBSD,
2.8.
2.7. МЕНЕДЖЕР
SYSTEМD в ДЕТАЛЯХ
Конфигурация и управление системными службами
трибутивы
Linux
-
это область, в которой дис
традиционно отличаются друг от друга. Менеджер
systemd нацелен
на стандартизацию этого аспекта системного администрирования, и в этой области он
достиг больших успехов, чем любая предыдущая альтернатива.
Системный менеджер systemd -
это не отдельный демон, а набор программ, де
монов, библиотек, технологий и компонентов ядра. Как отмечается в сообщении, опу
бликованном в блоге, посвященном systemd на странице
сборка проекта генерирует
69 разных двоичных файлов.
Opointer. de/Ьlog,
полная
Подумайте об этом как о конди
терской, в которой вы обязаны съесть все конфеты.
Поскольку менеджер systemd сильно зависит от особенностей ядра
ложение предназначено только дпя
другом варианте
UNIX
Linux.
Вы не увидите его в системе
Linux, это пред
BSD или любом
в течение следующих пяти лет.
Модули и модульные файлы
Сущность, которой управляет менеджер systemd, называется модулем
(unit) 10 •
Более
конкретно, модулем может быть "служба, сокет, устройство, точка монтирования, точка
автоматического монтирования, файл или раздел подкачки, цель запуска, просматрива
емый файловый путь, таймер, управляемый systemd, часть ресурса управления, группа
со:щанных извне процессов или портал в альтернативную вселенную" . 11 Хорошо, мы даже
захватили часть альтернативной вселенной, но она все еще занимает много территории.
Внутри менеджера systellld поведение каждого модуля определяется и настраивается
модульным файлом. Например, в случае службы файл модуля указывает местоположе
ние исполняемого файла дпя демона, сообщает systemd, как запускать и останавливать
службу, а также идентифицирует любые другие модули, от которых зависит служба.
Вскоре мы рассмотрим синтаксис модульных файлов, а пока приведем простой при
мер из системы
демона
rsync,
Ubuntu.
Этот файл устройства
rsync. service;
он обрабатывает запуск
который отображает файловые системы.
[Unit]
Description=fast rernote f ile сору prograrn daernon
ConditionPathExists=/etc/rsyncd.conf
[Service]
ExecStart=/usr/bin/rsync --daernon --no-detach
111 На
жаргоне программистов их часто называют юнитами.
11 В основном, цитируется по mаn-странице
systemd. uni t.
Примеч. ред.
84
часть
1. основы администрирования
[Install]
WantedBy=multi-user.target
Если вам показалось, что это напоминает файл в формате
темах
MS-DOS,
значит, вы хорошо понимаете почему к
. ini, используемом в сис
systemd так плохо относятся.
Модульные файлы могут находиться в нескольких местах. Основное место, где паке
ты сохраняют свои модульные файлы во время инсталляции
system;
в некоторых системах для этого используется каталог
- /usr/liЬ/systemd/
/lib/systemd/system.
Содержимое этого каталога считается ресурсом, поэтому вы не должны изменять его.
Файлы локальных файлов и настройки могут выполняться в каталоге
system.
В каталоге
/run/systemd/system есть также
/etc/systemd/
каталог модулей, который явля
ется рабочей областью для переходных модулей.
Менеджер
systemd
поддерживает телескопическое представление всех этих катало
гов, поэтому они в значительной степени эквивалентны. Если возникает конфликт, то
файлы в каталоге
/etc
имеют наивысший приоритет.
W Для получения дополнительной информации о демоне rsync см. раздел 17.4.
По соглашению, модульные файлы именуются суффиксом, который зависит от типа
настраиваемого устройства. Например, служебные модули имеют суффикс
а таймеры используют суффикс
. timer.
. service,
Внутри модульного файла некоторые разде
лы (например,
(например,
[ Uni t]) относятся в общем случае ко всем типам модулей, но другие
[ Service]) могут отображаться только в контексте определенного типа
устройства.
Команда
systemctl: управление
Команда
жера
Git
systemctl systemd и внесения
менеджером
systemd
это универсальная команда для изучения состояния менед
изменений в его конфигурацию. Как и в случае с системой
и несколькими другими сложными пакетами программного обеспечения, первый
аргумент команды
systemctl
обычно представляет собой подкоманду, которая задает
общую последовательность действий, а последующие аргументы являются специфиче
скими для этой конкретной подкоманды. Подкоманды могут быть отдельными коман
дами верхнего уровня, но для согласованности и ясности они объединены в команду
systemctl.
W Для получения дополнительной информации о системе Git см. раздел 7.8.
Выполнение команды
зывает подкоманду
systemctl без каких-либо аргументов по умолчанию вы
list-units, в которой отображаются все загруженные и активные
службы, сокеты, цели, смонтированные диски и устройства. Для того чтобы показывать
только загруженные и активные службы, используйте ключ
$
-type = service:
systemctl list-units --type=service
UNIT
accounts-daemon.service
LOAD
loaded
ACTIVE
active
SUB
running
wpa_supplicant.service
loaded
active
running
DESCRIPTION
Accounts Service
WPA supplicant
Также иногда полезно видеть все инсталлированные модульные файлы, независимо
от того, активны они или нет:
188 unit files listed.
Для подкоманд, действующих на определенный модуль (например,
status),
команда
systemctl
systemctl
обычно может принимать имя модуля без суффикса, ука
зывающего тип модуля (например,
cups
вместо
cups. service).
Тем не менее тип моду
ля по умолчанию, с которым объединены простые имена, зависит от подкоманды.
В табл.
2.4
systemctl
Таблица
2.4.
показаны наиболее востребованные и полезные подкоманды команды
(для получения полного списка см. тап-страницу
Наиболее распространенные подкоманды команды
systemctl
Функци•
Подкоманда
list-uni t-files
systemctl).
[шаблон}
Показывает установленные модули; существует возможность сравнения по шаблону
еnаЫе модуль
Включает модуль для активации при загрузке
disaЫe модуль
Запрещает запуск модуля при загрузке
isolate
stop
модуль
restart
status
kill
цель
модуль
start
модуль
модуль
шаблон
Изменяет режим работы на целевой
Немедленно активирует модуль
Немедленно деактивирует модуль
Немедленно перезагружает (или запускает, если не работает) модуль
Показывает состояние модуля и последние записи журнала
Отправляет сигнал в модуль, соответствующий шаблону
reЬoot
Перезагрузка компьютера
daemon-reload
Перезагружает файлы модулей и конфигурацию
systemd
Состояние модуля
systemctl list-unit-files, приведенном выше, мы видим,
cups. service отключен. Для получения более подробной информации мы
использовать команду systemctl status.
В выводе команды
что модуль
можем
$ sudo systemctl status -1 cups
cups.service - CUPS Scheduler
Loaded: loaded (/liЬ/systemd/system/cups.service; disaЫed; vendor
preset: enaЫed)
Active: inactive (dead) since Sat 2016-12-12 00:51:40 MST; 4s ago
Docs: man:cupsd(8)
Main PID: 10081 (code=exited, status=O/SUCCESS)
Dec 12 00:44:39 ulsah systemd[l]: Started CUPS Scheduler.
Dec 12 00:44:45 ulsah systemd[l): Started CUPS Scheduler.
Dec 12 00:51:40 ulsah systemd[l): Stopping CUPS Scheduler ...
Dec 12 00:51:40 ulsah systemd[l]: Stopped CUPS Scheduler.
Часть
86
Здесь команда
(dead),
systemctl
1. Основы администрирования
показывает, что служба в настоящее время неактивна
и сообщает, когда процесс был прекращен. (Для этого примера мы отключили
его всего несколько секунд назад.) Он также показывает (в разделе с надписью
Loaded),
что служба по умолчанию была включена при запуске, но теперь она отключена.
Последние четыре строки
-
это последние записи журнала. По умолчанию запи
си журнала конденсируются так, что каждая запись занимает только одну строку. Это
сжатие часто делает записи нечитаемыми, поэтому мы включили опцию
-1
для запроса
полных записей. В этом случае нет никакой разницы, но это полезная привычка.
В табл.
2.5 отображаются
состояния, с которыми вы чаще всего столкнетесь при про
верке модулей.
Таблица
2.5. Состояние модульных файлов
СостОАние
Описание
Ьаd
У менеджера
systemd возникла какая-то
проблема; обычно это связано со сбоем
модульного файла
disaЫed
Присутствует, но не настроен для автономного запуска
enaЫed
Инсталлирован и запущен; стартует автономно
indi rect
Отключен, но имеет одинаковые значения в разделах Also, которые могут быть включены
linked
Модульный файл, доступный через символическую ссылку
mas ked
Нежелательный статус с логической точки зрения
st а t i
Зависит от другого устройства; не требует установки
с
Состояния enaЫed и disaЫed применяются только к модульным файлам, которые
находятся в одном из системных каталогов
ссылкой) и имеют раздел
[ Install J
systemd (т.е.
они не связаны символической
в своих модульных файлах. Включенные модули,
по-видимому, действительно должны считаться "инсталлированными", что означает,
что директивы в разделе
были выполнены и что устройство подключено
[Install]
к его обычным активационным триггерам. В большинстве случаев это состояние застав
ляет модуль автоматически активироваться после загрузки системы.
Аналогично, состояние disaЫed является чем-то неправильным, потому что един
ственное, что фактически отключено,
-
это нормальный путь активации. Можно вруч
ную активировать устройство, которое было отключено, запустив команду
менеджер
systemd
systemctl;
не будет возражать.
У многих устройств нет процедуры инсталляции, поэтому нельзя сказать, что они
включены или отключены; они просто доступны. Статус таких элементов указан как
static.
Они активируются только вручную
(systemctl start)
или указываются в ка
честве зависимостей от других активных модулей.
Файлы, имеющие состояние
link.
linked,
были созданы с помощью команды
Эта команда создает символическую ссылку из одного из каталогов
неджера
systemd
systemctl
system ме
на модульный файл, который находится в другом месте в файловой
системе. Такие модульные файлы могут обрабатываться командами или указывать
ся в качестве зависимостей, но они не являются полноправными элементами системы
и имеют некоторые заметные отклонения. Например, применение команды
disaЬle к модульному файлу в состоянии
linked
systemctl
приводит к удалению связи и всех
ссылок на него.
К сожалению, точное поведение модульных файлов в состоянии
l inked
недостаточ
но хорошо документировано. Хотя идея хранить локальные модульные файлы в отдель-
Глава
2. Загрузка
и системные демоны
ном репозитории и связывать их с менеджером
87
systemd имеет
определенную привлека
тельность, вероятно, это не лучший подход на данный момент. Просто сделайте копии.
Состояние
masked
означает "заблокирован администратором". Менеджер
systemd
знает о модуле, но ему запрещено активировать его или действовать по любой из
ero
конфигурационных директив с помощью команды
systemctl mask. В этом случае сле
дует отключить модули, находящиеся в состоянии enaЫed или linked, с помощью ко
манды systemctl disaЫe и зарезервировать команду systemctl m.ask для модулей
в состоянии static.
Возвращаясь к нашему исследованию службы cups, мы могли бы использовать сле
дующие команды для ее повторного включения и запуска.
$ sudo systemctl еnаЫе cups
Synchronizing state of cups.service with SysV init with /liЬ/systemd/
systemd-sysv-install ...
Executing /liЬ/systemd/systemd-sysv-install еnаЫе cups
insserv: warning: current start runlevel (s) (empty) of script cups
overrides LSB defaults (2 З 4 5).
insserv: warning: current stop runlevel (s) (1 2 З 4 5) of script 'cups ·
overrides LSB defaults (1).
Created symlink from /etc/systemd/system/sockets.target.wants/cups.socket
to /lib/systemd/system/cups.socket.
Created symlink from /etc/systemd/system/multi-user.target.wants/cups.
path to /lib/systemd/system/cups.path.
$ sudo systemctl start cups
Цели
Модульные файлы могут объявлять свои отношения с другими модулями различ
ными способами. Так, в примере, приведенном в начале раздела "Модули и модульные
файлы", спецификатор
user. target,
WantedBy
означает, что, если система имеет модуль
то данный модуль должен зависеть от него
(rsync. service},
multi-
когда тот
находится в состоянии enaЫed.
Поскольку модули непосредственно поддерживают управление зависимостями,
для реализации эквивалента уровней выполнения
нительных механизмов. Для ясности менеджер
модулей (типа
. target),
ini t не требуется никаких допол
systemd определяет отдельный класс
чтобы использовать их как маркеры общих режимов работы.
Однако цели не имеют особой силы, за исключением управления зависимостями. до
ступного для любого другого модуля.
Традиционный демон
init
определяет как минимум семь уровней выполнения, но
многие из них на самом деле не используются. Стремясь к ложно понятой исторической
преемственности, менеджер
systemd определяет цели как прямые аналоги уровней за
ini t (runlevelO. target и т.д.). Он также определяет мнемонические
цели для повседневного использования, такие как poweroff. target и graphical .
target. В табл. 2.6 показано сопоставление между уровнями выполнения init и целя
ми systemd.
Единственными целями, которые действительно необходимо знать, являются mul tiuser. target и graphical . target для повседневного использования и rescue.
target для доступа к однопользовательскому режиму. Для того чтобы изменить теку
щий режим работы системы, используйте команду systemctl isolate:
пуска демона
$ sudo systemctl isolate multi-user.tarqet
Часть
88
Таблица
2.6.
Сопоставление между уровнями запуска
1. Основы
администрирования
ini t и системными целями
Уровеньвыполнения
Цепь
Описание
О
poweroff.target
Остановка системы
emergency
emergency. target
Простейшая оболочка для восстановления системы
1, s, single
rescue. target
Однопользовательский режим
2
3
mul ti-user. target•
Многопользовательский режим (командная строка)
mul ti-user. target•
Многопользовательский сетевой режим
4
mul ti-user. target•
Обычно не используется
5
graphical. target
Многопользовательский сетевой режим с графическим
6
reЬoot.target
ini t
интерфейсом
"По умолчанию цель 11ul ti-user.
Перезагрузка системы
target соответствует runlevelЗ. target,
многопользовательскому сете
вому режиму.
Подкоманда
isolate
называется так, потому что она активирует указанную цель
и ее зависимости, но деактивирует все остальные модули.
В традиционном демоне
ini t для изменения уровней запуска
telini t. Некоторые дистрибутивы
символическую ссылку на команду systemctl.
стемы используется команда
telini t
как
после загрузки си
теперь определяют
Для того чтобы увидеть цель, к которой система загружается по умолчанию, запусти
те подкоманду
get-defaul t:
$ systemctl get-default
graphical.target
Большинство дистрибутивов
target,
Linux загружаются
по умолчанию в модуль
graphical .
что не подходит для серверов, которым не нужен графический интерфейс. Но
это легко изменить:
$ sudo systemctl set-default multi-user.target
Чтобы увидеть все доступные цели системы, запустите системные списки:
$ systemctl list-units --type = target
Зависимости между модулями
Пакеты программного обеспечения
Linux
обычно поставляются со своими соб
ственными модульными файлами, поэтому системные администраторы не нуждаются
в подробном знании всего языка конфигурации. Тем не менее им необходимы рабочие
знания системы зависимостей
system.d для
диагностики и устранения проблем с зави
симостями.
Во-первых, не все зависимости являются явными. Менеджер
функции старого демона
системы связи
D-Bus.
inetd,
systemd
берет на себя
а также расширяет эту идею в домене межпроцессной
Другими словами, менеджер
systemd знает,
какие сетевые порты
или IРС-соединения указывают, где будет размещаться указанная служба, и может про
слушивать запросы по этим каналам, не запуская службу. Если клиент выполняет мате
риализацию, система просто запускает фактическое обслуживание и отключает соедине
ние. Служба запускается, если она фактически используется, и остается бездействующей
в противном случае.
глава
загрузка и системные демоны
2.
Во-вторых. менеджер
89
systemd делает
некоторые предположения о нормальном по
ведении большинства видов единиц. Точные предположения варьируются в зависимости
от типа единицы. Например, менеджер
systemd предполагает,
что среднестатистическая
служба является надстройкой, которая не должна запускаться на ранних этапах инициа
лизации системы. Отдельные блоки могут отключать эти допущения с помощью строки
DefaultDependencies ; false
в разделе
[Unit]
их модульного файла; по умолчанию значение равно
true.
Чтобы уви
деть точные предположения, которые применяются к каждому типу модуля, см. спра
вочную страницу дпя типа
systemd. uni t, (например. man systemd. service).
- те, которые явно объявлены в разделе [Unit] модуль
параметры показаны в табл. 2.7.
Третий класс зависимостей
ных файлов. Доступные
Таблица
2.7. Явные зависимости в разделе [Unit] модульного файла
Параметр
Значение
Модули, которые должны быть активированы одновременно, если это возможно, но не
Wants
обязательно
Requi re s
Строгие зависимости; отказ от каких-либо предварительных условий прекращает работу
этой службы
Requisi te
Аналогично
Requires, но модуль должен быть активным
Bindsтo
Аналогично
Requires,
PartOf
Аналогично
Requires, но влияеттолько на запуск и остановку
С on f
Отрицательные зависимости; не может взаимодействовать с этими единицами
1i с t s
За исключением параметра
но модуль должен быть связан еще более тесно
Conflicts,
все параметры в табл.
2.7
выражают основ
ную идею о том, что настраиваемый модуль зависит от некоторого набора других моду
лей. Точные различия между этими параметрами являются незначительными и в первую
очередь интересны разработчикам служб. Когда это возможно, предпочтение следует от
Wants.
Wants или Requires, создав файл модульный-файл.
модульный-файл. requires в каталоге /etc/systemd/system и добавив
давать наименее ограничительному варианту,
Можно расширить группу
wants
или
туда символические ссылки на другие модульные файлы. Еще лучше, просто дайте ко
манде
systemctl сделать это за вас. Например, команда
$ sudo systeшctl аdd-хочет шulti-user.target my.local.service
добавляет зависимость от модуля
my. local. service
к стандартной многопользова
тельской цели, гарантируя, что служба будет запускаться каждый раз, когда система пе
реходит в многопользовательский режим.
В большинстве случаев такие специальные зависимости устанавливаются автомати
чески на основе раздела
[ Install J в модульных файлах. Эгот раздел содержит опции
WantedBy и RequiredBy, которые читаются, только если модуль включен с помощью
команды systemctl еnаЫе или отключен с помощью команды systemctl disaЫe.
При включении они заставляют команду systemctl выполнять эквивалент add-wants
для каждой опции WantedBy или add-require для каждой опции RequiredBy.
Разделы [ Install J сами по себе не влияют на нормальную работу, поэтому, если
модуль не запускается, убедитесь, что он правильно подключен и связан с символиче
ской ссылкой.
часть
90
1. Основы администрирования
Порядок выполнения
Разумно предположить, что если модуль А требует
(Requeres)
наличия модуля В,
то модуль В будет запущен или настроен до модуля А. Но на самом деле это не так.
В менеджере
systemd
порядок, в котором блоки активируются (или деактивируются),
является совершенно отдельным вопросом.
Когда система переходит в но1юе состояние, менеджер
systemd сначала отслежива
ет различные источники информации о зависимости, изложенные в предыдущем раз
деле, чтобы определить задействованные модули. Затем он использует разделы
и
After
Before
из модульных файлов, чтобы упорядочить список заданий. Если модули не
имеют разделов
или
Before
After,
они могут быть скорректированы параллельно.
Это удивительная, но достойная внимания функция дизайна. Одной из основных целей
проектирования менеджера
syst8111d было
облегчение параллелизма, поэтому логично, что
модули не получают зависимостей сериализации, если они явно не запрашивают их.
На практике раздел
After
используется чаще, чем
Wants
или
Requires.
Определе
ния целей (и, в частности, обратных зависимостей, закодированных в предложениях
WantedBy
и
RequiredBy)
устанамивают общие контуры служб, работающих в каждом
рабочем режиме, а отдельные пакеты беспокоятся только о своих непосредственных
и прямых зависимостях.
Более сложный пример файла
Теперь внимательно рассмотрим несколько директив, используемых в модульных
файлах. Вот модульный файл для веб-сервера
NG INX, nginx. service.
[Unit]
Description=The nginx НТТР and reverse proxy server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $МAINPID
KillMode=process
KillSignal=SIGQUIT
TimeoutStopSec=S
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Эта служба имеет тип
forking,
что означает, что команда запуска должна завершить
ся, даже если демон продолжает работать в фоновом режиме. Так как менеджер
systemd
PID
не будет непосредственно запускать демона, тот записывает свой идентификатор
(идентификатор процесса) в указанном
PIDFile,
чтобы
systemd мог определить,
какой
процесс является основным экземпляром демона.
Строки Ехес -
ExecStartPre
это команды для запуска в различных обстоятельствах. Команды
запускаются до фактического запуска службы; показанные здесь коман
ды подтверждают синтаксис конфигурационного файла
ние любого существующего РID-файла.
ExecStart-
NG INX
и гарантируют удале
это команда, которая фактически
Глава
2. загрузка
и системные демоны
запускает службу. Команда
91
ExecReload сообщает менеджеру system.d, как заставить
службу перечитать ее файл конфигурации. (Менеджер
system.d автоматически
устанав
ливает переменную среды МAINPID в соответствующее значение.)
m Дополнительную информацию о сигналах см. в разделе 4.2.
Завершение этой службы обрабатывается через параметры
которые сообщают
system.d,
KillMode и KillSignal,
QUIT как ин
что демон службы интерпретирует сигнал
струкцию мя очистки и выхода. Строка
ExecStop
= /bin/kill -s HUP
$МAINPID
будет иметь по существу тот же результат. Если работа демона не закончится за коли
чество секунд, заданных параметром
TimeoutStopSec,
менеджер
system.d заставит
прекратить работу с помощью сигнала ТЕRМ, а затем неперехватываемоrо сигнала
Параметр
службы
PrivateTmp -
/tmp в место,
его
KILL.
попытка повысить безопасность. Он помещает каталог
отличающееся от фактического каталога
/tm.p,
который использу
ется всеми процессами и пользователями системы.
Локальные службы и настройки
Как показано в предыдущих примерах, довольно просто создать модульный файл
мя домашней службы. Просмотрите примеры в каталоге
/usr/lib/system.d/system
и адаптируйте их к своим потребностям. Для получения полного списка параме
тров конфигурации служб обратитесь к справочной странице мя
system.d.service.
Параметры, общие для всех типов устройств, описаны на справочной странице
system.d. uni t.
Поместите свой новый файл в каталог
/etc/system.d/system..
Затем можно запу
стить команду
$ sudo systemctl
еnаЫе custoш.service
мя активации зависимостей, перечисленных в разделе
[ Install J
в служебном файле.
Как правило, не следует редактировать модульный файл, написанный не вами.
Вместо этого создайте каталог конфигурации в каталоге /etc/system.d/system./unitfile. d и добавьте один или несколько файлов конфигурации, которые называются ххх.
conf. Часть ххх не имеет значения; просто убедитесь, что файл имеет суффикс . conf
и находится в нужном месте. Имя override. conf является стандартным.
Файлы с расширением . conf имеют тот же формат, что и модульные файлы, и на
самом деле менеджер system.d сглаживает их все вместе с исходным файлом. Однако,
если оба источника попытаются установить значение одного итого же параметра, пере
определенные файлы имеют приоритет над исходными модульными файлами.
Следует иметь в виду, что многие параметры менеджера
system.d могут
отображаться
в модульном файле более одного раза. В этих случаях множественные значения обра
зуют список и остаются активными одновременно. Если вы задаете значение в файле
override. conf,
оно присоединяется к списку, но не заменяет существующие записи.
Это может быть не тем, что вы хотите. Чтобы удалить существующие записи из списка,
просто присвойте параметру пустое значение, а затем добавьте свой.
Рассмотрим пример. Предположим, что ваша организация хранит файл конфигу
рации
NGINX
в нестандартном месте, например
нужно запустить демон
nginx
с параметром -с
он мог найти нужный файл конфигурации.
/usr/local/www/nginx.conf. Вам
/usr/local/www/nginx.conf, чтобы
Часть
92
Вы не можете просто добавить эту опцию в файл
nginx. service,
1. Основы администрирования
/usr/lib/systemd/system/
NGINX об
потому что он будет заменяться каждый раз, когда пакет
новляется или модифицируется.
Вместо этого можно использовать следующую последовательность команд.
удаляет текущую запись, а второй устанавливает аль
тернативную команду запуска. Команда
systemctl daemon-reload
осуществляет по
вторный синтаксический разбор модульных файлов.
Тем не менее она не перезапускает демоны автоматически, поэтому вам придется по
вторно выполнить команду
systemctl,
чтобы изменения вступили в силу немедленно.
Эта последовательность команд представляет собой настолько распространенную
идиому, что менеджер
systemctl
теперь реализует ее непосредственно:
$ sudo systemctl edit nginx.service
$ sudo systemctl restart nginx.service
Как уж было сказано, вам все равно придется перезапустить менеджер вручную.
Последнее, что нужно знать о переопределяемых файлах, заключается в том, что они
не могут изменить раздел
[ Install]
модульного файла. Любые сделанные вами изме
нения молча игнорируются. Просто добавьте зависимости напрямую с помощью команд
systemctl add-needs
или
systemctl add-require.
Предостережения об управлении службами и запуском
Применение менеджера
адаптация
пуски
-
-
systemd
имеет много архитектурных последствий, и его
непростая задача для разработчиков дистрибутивов
Linux.
Текущие вы
это в основном системы Франкенштейна, которые используют большую часть
системы, но также сохраняют несколько ссылок на прошлые версии. Иногда старые
версии просто еще не полностью преобразованы. В других случаях для облегчения со
вместимости были оставлены различные формы устаревшего кода.
Хотя менеджер
systemctl
можно и нужно использовать для управления службами
и демонами, не удивительно, если вы до сих пор запускаете традиционные сценарии
ini t
или связанные с ними вспомогательные команды. Если вы попытаетесь использо
вать менеджер
systemctl
Д/IЯ отключения сети в системе
CentOS
или
Red Hat,
напри
мер, вы получите следующий вывод.
$ sudo systemctl disaЫe network
network.service is not а native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig network of f
12 Символы
> и !$ -
а действие символов
это метасимволы оболочки. Символ
!$
> переадресовывает
вывод в файл,
распространяется до последнего компонента предыдущей командной
строки, так что вам не нужно его повторно вводить. Все оболочки понимают эти обозначения.
Информацию о некоторых других удобных функциях см. в разделе 7.2.
Глава
2. Загрузка
и системные демоны
93
Дополнительную информацию о службе
W
Apache см.
в разделе
19.3.
Традиционные сценарии инициализации часто продолжают функционировать в си
systemd. Например, сценарий инициализации /etc/rc.d/init.d/my-oldservice может быть автоматически сопоставлен с модульным файлом, таким как
my-old-service. service, во время инициализации системы или при выполнении
команды systemctl daemon-reload. Примером является служба Apache 2 на Ubuntu
17.04: попытка отключить apache2. service приводит к следующему выводу.
стеме
$ sudo systemctl disaЫe apache2
Synchronizing state of apache2.service with SysV service script with
/liЬ/systemd/systemd-sysv-install.
Executing:
/liЬ/systemd/systemd-sysv-install disaЫe
apache2
Конечный результат соответствует тому, что вы хотели, но процесс проходит доволь
но окольным путем.
В системах
RHEL. local
Red Hat
и
CentOS все
еще запускается сценарий
/etc/rc.d/rc.
во время загрузки, если вы настроите его на выполнение. 13
Теоретически можно использовать этот сценарий для взлома уязвимостей
сайта или загрузки задач, если это необходимо. (На данный момент, однако,
вам нужно проигнорировать хакерские возможности и сделать что-то полез
ное в системе, создав соответствующий набор файлов модулей.)
Некоторые задачи загрузки систем
Red Hat
фигурационные файлы, найденные в каталоге
в табл.
и
CentOS
продолжают использовать кон
/etc/sysconfig.
Эти данные приведены
2.8.
Таблица 2.8. Файлы и подкаталоги каталога Red Hat /etc/sysconfig
Файл или каталоr
Содержимое
console/
Каталог, который исторически допускал настраиваемое сопоставление клавиш
crond
Аргументы для перехода к демону
crond
ini t
Конфигурация для обработки сообщений из сценариев запуска
iptaЫes-config
Загружает дополнительные модули iptaЫes, такие как NАТ-помощники
network-scripts/ Сценарии аксессуаров и сетевые файлы конфигурации
и
nfs
ntpd
Необязательные аргументы
selinux
Символическая ссылка на каталог/ etc/ selinux/ config"
•устанавливает аргументы для системы
Пара пунктов табл.
•
RPC
Параметры командной строки
2.8
SELinux или
NFS
ntpd
позволяет полностью отключить ее; см. раздел
3.4.
заслуживают дополнительного комментария.
Каталог сетевых сценариев содержит дополнительные материалы, относящиеся
к сетевой конфигурации. Единственное, что вам может понадобиться изменить
здесь,
-
файлы с именем
ifcfg-ethO
ifcfg-interface.
Например, файл
network-scripts/
ethO. Он уста
содержит параметры конфигурации для интерфейса
навливает IР-адрес и сетевые параметры интерфейса. Дополнительная информа
ция о настройке сетевых интерфейсов приведена в разделе
•
13.1 О.
Файл iptaЫes-config фактически не позволяет изменять правила iptaЬles
(брандмауэра). Это просто способ загрузки дополнительных модулей, таких как
11 Быстрая
команда
sudo chmod
+х
/etc/rc.d/rc. local
гарантирует, что файл будет исполняться.
Часть
94
трансляция сетевых адресов
(NAT),
1. основы администрирования
если вы собираетесь пересылать пакеты или
использовать систему в качестве маршрутизатора. Дополнительная информация
о настройке iptaЫes содержится в разделе
Журнал
13.14.
systemd
Фиксация сообщений в журнале, созданных ядром, всегда был сложной задачей. Она
стала еще более важной с появлением виртуальных и облачных систем, поскольку не
возможно просто стоять перед консолями этих систем и следить за тем, что происходит.
Часто важнейшая диагностическая информация терялась в эфире.
Менеджер
systemd устраняет эту проблему с
помощью универсальной структуры ве
дения журнала, которая включает все сообщения ядра и службы от начальной загрузки
до окончательного завершения. Этот объект, называемый журналом, управляется демо
ном
journald.
Системные сообщения, записанные журналом, хранятся в каталоге
rsyslog
/run.
Демон
может обрабатывать эти сообщения и хранить их в традиционных файлах жур
налов или пересылать их на удаленный сервер
щаться к журналам с помощью команды
Без аргументов команда
journalctl
syslog.
journalctl.
Можно также напрямую обра
выводит все записи журнала (начиная с самых
старых).
$ journalctl
-- Logs begin at Fri 2016-02-26 15:01:25 UTC, end at Fri 2016-02-26
15:05:16 uтс. -Feb 26 15:01:25 ubuntu systemd-journal[285]: Runtime journal is using
4.6М (max allowed 37 .ом, t
Feb 26 15:01:25 ubuntu systemd-journal[285]: Runtime journal is using
4.6М (max allowed 37.ОМ, t
Feb 26 15:01:25 ubuntu kernel: Initializing cgroup subsys cpuset
Feb 26 15:01:25 ubuntu kernel: Initializing cgroup subsys cpu
Feb 26 15:01:25 ubuntu kernel: Linux version 3.19.0-43-generic (buildd@
lcyOl-02) (gcc version 4.
Feb 26 15:01:25 ubuntu kernel: Command line: BOOT_IМAGE=/boot/vmlinuz3.19.0-43-generic root=UUI
Feb 26 15:01:25 ubuntu kernel: KERNEL supported cpus:
Feb 26 15:01:25 ubuntu kernel: Intel Genuineintel
Можно настроить демон journaldдля сохранения сообщений из предыдущих загру
-1 a73415fade0e4e7f4bea60913883dl80dc Fri 2016-02-26 15:01:25 UTC
Fri 2016-02-26 15:05:16 UTC
О Oc563fa3830047ecaa2d2b053d4e66ld Fri 2016-02-26 15:11:03 UTC Fri
2016-02-26 15:12:28 uтс
Затем можно получать доступ к сообщениям из предыдущей загрузки, ссылаясь
на свой индекс или длинный идентификатор.
Глава
2.
Загрузка и системные демоны
$ journalctl
$ journalctl
-Ь
-Ь
95
-1
a73415fade0e4e7f4bea60913883d180dc
Для того чтобы ограничиться конкретным модулем, используйте флаг
-u.
$ journalctl -u ntp
-- Logs begin at Fri 2016-02-26 15:11:03 UTC, end at Fri 2016-02-26
15:26:07 uтс. -Feb 26 15:11:07 ub-test-1 systernd[l]: Stopped LSB: Start NТР daemon.
Feb 26 15:11:08 ub-test-1 systernd[l]: Starting LSB: Start NТР daemon ...
Feb 26 15:11:08 ub-test-1 ntp[761]: * Starting NTP server ntpd
Ведение журнала
2.8.
systemd более
подробно описано в главе
1О.
СЦЕНАРИИ ИНИЦИАЛИЗАЦИИ и ЗАПУСКА
СИСТЕМЫ FREEBSD
Система
FreeBSD
использует инициализацию в стиле
BSD,
который не поддержи
вает концепцию уровней выполнения. Чтобы привести систему в полностью загружен
ное состояние, инициализация
FreeBSD
запускает программу
/etc/rc.
Эта программа
является сценарием оболочки, но ее нельзя изменять напрямую. Вместо этого система
rc
реализует несколько стандартных способов расширения системы запуска и измене
ния конфигурации, доступных для системных администраторов и пакетов программ
ного обеспечения.
Ш
Информацию о сценариях оболочки см. в главе
Прежде всего,
/etc/rc -
7.
это оболочка, которая запускает другие сценарии, боль
шинство из которых находятся в каталогах
/usr/local/etc/rc.d. и /etc/rc.d.
ro выполняет три фай
Однако, прежде чем запускать любой из этих сценариев, система
ла, которые содержат информацию о конфигурации мя системы.
• /etc/defaults/config
• / etc/ rc. conf
• /etc/rc.conf .local
Эти файлы сами являются сценариями, но обычно они содержат только определения
значений переменных оболочки. Затем сценарии запуска проверяют эти переменные,
чтобы определить, как вести себя дальше. (Программа
/etc/rc
использует некоторые
средства оболочки, чтобы гарантировать, что переменные, определенные в этих файлах,
будут видны повсюду.)
Ш
Дополнительную информацию о сценариях оболочки см. в главе
В файле
/etc/defaults/rc.conf
7.
перечислены все параметры конфигурации и их
настройки по умолчанию. Никогда не редактируйте этот файл, чтобы сценарий иници
ализации не перезаписал ваши изменения при следующем обновлении системы. Вместо
этого просто переопределите значения по умолчанию, установив их снова в файлах
/etc/rc. conf
или
/etc/rc. conf. local.
На справочной странице
rc. conf
имеется
обширный список переменных, которые можно задать.
Теоретически файлы
rc. conf
могут также содержать имена других каталогов, в ко
торых для запуска сценариев можно установить значение переменной
local _ startup.
Часть
96
Значение по умолчанию
- /usr/local/etc/rc. d,
1. основы администрирования
и мы рекомендуем оставить его не
изменным.14
Заглянув в файл
/etc/rc.d,
можно увидеть, что существует множество различ
ных сценариев запуска, в стандартной установке их более
скает эти сценарии в порядке, определенном командой
150.
Файл
rcorder,
/etc/rc
запу
которая считывает
сценарии и ищет информацию о зависимостях, которая была закодирована стандарт
ным образом.
Сценарии запуска
FreeBSD
верхняя часть сценария запуска
для разнообразных служб довольно просты. Например,
rcvar содержит имя переменной, которая должна быть определена
rc. conf', в данном случае sshd_ enaЬle. Если вы хотите, что
бы для автоматического запуска во время загрузки использовался демон sshd (реаль
ный демон, а не сценарий запуска, хотя оба называются sshd), поместите в файл /etc/
rc. conf' строку:
Переменная
в одном из сценариев
sshd
еnаЫе
=
"YES"
Если эта переменная имеет значение
"NO"
или закомментирована, сценарий
sshd
не за
пускает демон или не проверяет, следует ли его останавливать при выключении системы.
Команда
servioe обеспечивает интерфейс
ционной системы
реального времени в системе
rc. d
опера
FreeBSD.'5
Например, чтобы остановить службу
sshd вручную,
можно запустить команду
$ sudo service sshd stop
Обратите внимание: этот метод работает только в том случае, если служба указана
в файлах
или
/etc/rc. conf'. Если это не так, используйте подкоманды onestop, onestart
onerestart, в зависимости от того, что вы хотите сделать. (Команда service, как
правило, напомнит вам об этом, если это необходимо.)
2.9. ПРОЦЕДУРЫ
ПЕРЕЗАГРУЗКИ И ВЫКЛЮЧЕНИЯ
Исторически сложилось так, что машины
UNIX
и
Linux очень строго
регламентиро
вали процесс выключения. Современные системы стали менее чувствительными, осо
бенно если используется надежная файловая система, но всегда полезно выключить ма
шину, когда это возможно.
14Для
локальных настроек можно либо создать стандартные сценарии в стиле
находятся в каталоге
rc. local.
15 Версия
/usr/local/etc/rc.d, либо редактировать общедоступный
rc. d,
которые
сценарий
/etc/
Первый вариант предпочтительнее.
службы, которую использует система
FreeBSD,
основывается на команде
в системе Liпux, которая управляет традиционными службами
ini t.
service
Глава
2. Загрузка
97
и системные демоны
Операционные системы прошлых лет приучали многих системных администраторов
перезагружать систему как первый шаг при решении любой проблемы. Тогда это была
адаптивная привычка, но в наши дни она чаще приводит к ненужным затратам времени
и прерыванию обслуживания. Сосредоточьтесь на выявлении основной причины про
блем, и вы, вероятно, обнаружите, что nерезагружаетесь реже.
Тем не менее после изменения сценария запуска или внесения значительных измене
ний в конфигурацию рекомендуется выполнить перезагрузку. Эта проверка гарантирует
успешную загрузку системы. Если вы обнаружили проблему, но не решали ее в течение
нескольких недель, то вряд ли вспомните детали последних изменений.
Выключение физических систем
Основные обязанности, необходимые для закрытия системы, выполняет команда
hal t.
Она регистрирует выключение, прекрашает несущественные процессы, сбрасыва
ет кешированные блоки файловой системы на диск и останавливает ядро. В большин
стве систем команда
Команда
reboot
hal t
-р начинает процесс выключения системы.
по существу идентична команде
hal t,
но она заставляет машину
перезагружаться, а не останавливаться.
Команда
shutdown -
это надстройка над командами
hal t
и
reboot,
которая обе
спечивает запланированные выключения и выдачу тревожных предупреждений для за
регистрированных пользователей. Она восходит к эпохе систем разделения времени и в
настоящее время в значительной степени устарела. Команда
важного, кроме выполнения команд
hal t
или
reboot,
shutdown
не делает ничего
поэтому ее можно не использо
вать, если у вас нет многопользовательских систем.
Выключение облачных систем
Можно остановить или перезапустить облачную систему либо с сервера (с помощью
команды
halt
или
reboot,
как описано в предыдущем разделе), либо с помощью веб
консоли поставшика облачных вычислений (или эквивалентного интерфейса
API).
Вообще говоря, отключение системы с помошью облачной веб-консоли сродни от
ключению питания. Лучше, если виртуальный сервер будет управлять собственным вы
ключением, но если он перестает отвечать на запросы, все что вам остается
-
отклю
чить его с помошью веб-консоли. Что еще можно сделать?
В любом случае убедитесь, что вы понимаете, что означает выключение с точки зре
ния поставщика облака. Было бы очень обидно уничтожить вашу систему, когда вы хо
тели всего лишь перезагрузить ее.
В среде AWS операции Stop и ReЬoot делают именно то, что вы ожидаете. Команда
Terminate деактивирует экземпляр и удаляет его из памяти. Если для базового устрой
ства хранения установлено значение delete on termination (удалить при заверше
нии), будет уничтожен не только ваш экземпляр, но и данные на корневом диске. Все
хорошо, если вы хотели сделать именно это. Если же вы считаете, что это плохо, можно
включить параметр
2.1 о.
termination protection
(защита завершения).
Что ДЕЛАТЬ, ЕСЛИ СИСТЕМА НЕ ГРУЗИТСЯ?
Множество проблем может помешать загрузке системы, начиная от неисправных
устройств и заканчивая обновлениями ядра. Сушествует три основных подхода к этой
ситуации, перечисленные здесь в порядке нежелательности.
Часть
98
•
•
1. Основы администрирования
Не отлаживать; просто верните систему в хорошо известное состояние.
Довести систему до уровня, достаточного для запуска оболочки и отладки в инте
рактивном режиме.
•
Загрузить отдельный системный образ, смонтировать файловые системы неис
правной системы и исследовать его.
Первый вариант наиболее часто используется в облаке, но он может быть полезен и на
физических серверах, если у вас есть доступ к последнему образу всего загрузочного дис
ка. Если ваша организация делает резервные копии файловой системы, восстановление
всей системы может создать больше проблем, чем хотелось бы. Мы обсуждаем вариант
восстановления всей системы в режиме восстановления облачных систем немного ниже.
В оставшихся двух подходах основное внимание уделяется предоставлению вам до
ступа к системе, определению основной проблемы и исправлению любых проблем.
Загрузка неисправной системы в оболочку на сегодняшний день является предпочти
тельным вариантом, но проблемы, которые происходят на ранних этапах загрузки, мо
гут привести к нарушению этого подхода.
Режим "загрузка в оболочку" известен как однопользовательский режим или режим
спасения
(rescue mode).
Системы, которые используют менеджер
имеют еще
systemd,
более примитивный вариант, доступный в форме аварийного режима
(emergency mode);
он концептуально похож на однопользовательский режим, но делает абсолютный мини
мум работы перед запуском оболочки.
Поскольку однопользовательский режим, режим спасения и аварийный режим не
настраивают сеть и не запускают связанные с сетью службы, обычно, чтобы их исполь
зовать, необходим физический доступ к консоли. В результате однопользовательский
режим обычно недоступен для облачных систем. Мы рассмотрим некоторые варианты
восстановления испорченных облачных образов чуть ниже.
Однопользовательский режим
В однопользовательском режиме, также известном как
использующих менеджер
systemd,
rescue. target,
для систем,
запускается только минимальный набор процессов,
демонов и служб. Корневая файловая система смонтирована (как правило,
/usr),
но
сеть остается неинициализированной.
Во время заrрузки вы запрашиваете однопользовательский режим, передавая аргу
мент ядру, обычно
single
или
-s.
Это можно сделать с помощью интерфейса команд
ной строки загрузчика.
В некоторых случаях он может быть настроен автоматически в качестве опции меню
загрузки. Если система уже запущена, ее можно перевести в однопользовательский ре
жим с помощью команды
shutdown (FreeBSD), telini t
(традиционный
ini t)
или
systemctl (systemd).
Ш Дополнительную информацию об учетной записи root см. в главе 3.
Системы
Sane
перед запуском однопользовательской корневой оболочки запрашива
ют корневой пароль. К сожалению, это означает, что сбросить забытый корневой пароль
в однопользовательском режиме практически невозможно. Если вам нужно сбросить па
роль, придется получить доступ к диску с помощью отдельного загрузочного носителя.
Ш
Дополнительную информацию о файловых системах и мониторинге см. в главе
5.
Из однопользовательской оболочки можно выполнять команды так же, как при вхо
де в систему с полной загрузкой. Однако иногда монтируется только корневой раздел;
Глава
2.
99
Загрузка и системные демоны
чтобы использовать программы, которые не находятся в каталогах /Ьin, /sЬin или
/etc,
необходимо смонтировать другие файловые системы вручную.
Часто можно найти указатели на доступные файловые системы, просмотрев ка
талог
В системе
/etc/fstab.
Linux
можно выполнить команду
fdisk
(буква
-1
L
в нижнем регистре), чтобы просмотреть список разделов диска локальной системы.
Аналогичная процедура для системы
FreeBSD
заключается в том, чтобы выполнить ко
camcontrol devlist для идентификации дисковых
fdisk -s устройство для каждого диска.
манду
ду
устройств, а затем
-
коман
Во многих однопользовательских средах корневой каталог файловой системы начи
нает монтироваться в состоянии "только для чтения". Если каталог
/etc
является ча
стью корневой файловой системы (обычный случай), то будет невозможно редактиро
вать многие важные файлы конфигурации. Чтобы устранить эту проблему, необходимо
начать сеанс в однопользовательском режиме, перемонтировав каталог в режиме чтения
и записи. В системе
# mount
-о
В системах
Linux этот трюк обычно
выполняет команда
rw,remount /
FreeBSD
возможность повторного подключения является неявной, когда вы
повторяете монтирование, но необходимо явно указать исходное устройство. Например,
# mount
-о
rw /dev/qpt/rootfs /
Однопользовательский режим в системах
Red Hat
и
CentOS
немного более
агрессивен, чем обычно. К моменту достижения командной строки эти си
стемы уже пытались подключить все локальные файловые системы. Хотя
это умолчание обычно полезно, при несnравной файловой системе могут
возникнуть проблемы. В этом случае можно загрузиться в аварийном режи
ме, добавив команду
systemd. uni t=emergency. target
из загрузчика {обычно
GRUB).
к аргументам ядра
В этом режиме локальные файловые систе
мы не монтируются и запускается всего несколько основных служб.
m Для получения дополнительной информации о файловых системах и их монтировании см.
главу
Команда
5.
fsck
запускается во время обычной загрузки для проверки и восстановле
ния файловых систем. В зависимости от того, какую файловую систему вы используе
те для корневого каталога, вам может потребоваться запустить
fsck
вручную, когда вы
подключаете систему в однопользовательском или аварийном режиме. Для получения
более подробной информации о команде
Однопользовательский режим
-
fsck
обратитесь к разделу
можно выйти из однопользовательской оболочки, введя команду
ши
,
20.10.
это просто точка на обычном пути загрузки, поэтому
exi t
или нажав клави
чтобы продолжить загрузку. Вы также можете нажать клавиши
в момент запроса пароля, чтобы полностью обойти однопользовательский режим.
Однопользовательский режим в системе
•
Система
1.
2.
3.
4.
FreeBSD
FreeBSD
включает одноnользовательский вариант в меню загрузки.
Boot Multi User [Enter)
Boot Single User
Escape to loader prompt
Reboot
Часть
100
1. Основы администрирования
Options
5. Kernel: default/kernel (1 of 2)
6. Configure Boot Options ...
Одна приятная особенность однопользовательскоrо режима в
FreeBSD
заключается
в том, что он спрашивает, какую проrрамму использовать в качестве оболочки. Просто
нажмите
для оболочки
Выбрав вариант
3,
/bin/ sh.
вы переЙдете в среду командной строки заrрузочного уровня, реа
лизованную финальным загрузчиком
FreeBSD loader.
Однопользовательский режим с загрузчиком
GRUB
В системах, использующих менеджер
восстановления, добавив команду
существующей строки ядра
systemd, можно заrрузиться в режиме
systemd. uni t=rescue. target в конец
Linux. Чтобы изменить параметры заrрузки, вы
GRUB и нажмите клавишу . Аналогично
режиме используйте команду systemd. uni t=
делите нужное ядро на заставке
для загрузки в аварийном
emergency. target.
Вот пример типичной конфигурации:
linuxl6/vmlinuz-3.10.0-229.el7.x86_64 root=/dev/mapper/rhel_rhel-root
ro crashkernel=auto rd.lvm.lv=rhel_rhel/swap rd.lvm.lv=rhel_rhel/root
rhgb quiet LANG=en_US.UTF-8 systemd.unit=rescue.target
Для того чтобы запустить систему после внесения изменений, нажмите
.
Восстановление облачных систем
Из-за природы облачных систем невозможно подключить монитор или USВ
накопитель при возникновении проблем с загрузкой. Облачные провайдеры делают все
возможное, чтобы облегчить решение проблем, но основные ограничения остаются.
W Для более широкого ознакомления с облачными вычислениями см. главу 9.
Резервные копии важны для всех систем, но для облачных серверов сделать такую
копию очень просто. Провайдеры взимают дополнительную плату за резервные копии,
но они недороги. Чаще создавайте образы
(snapshot)
и вы всегда будете иметь разумный
системный образ, чтобы вернуться к нему в короткие сроки.
С философской точки зрения вы, вероятно, ошибаетесь, если вашим облачным сер
верам требуется отладка при загрузке. Неисправные физические серверы можно срав
нить с домашними животными, которых лечат, если они заболели, но больной круп
ный рогатый скот не лечат, а просто забивают. Ваши облачные серверы
-
это крупный
рогатый скот; если они плохо работают, замените их заведомо рабочими копиями.
Использование этого подхода помогает не только избежать критических сбоев, но и об
легчает масштабирование и миrрацию системы.
Тем не менее вам неизбежно придется попытаться восстановить облачные системы
или диски, поэтому мы кратко обсудим этот процесс ниже.
В рамках
AWS однопользовательские
и аварийные режимы недоступны. Однако файловые
системы ЕС2 могут быть подключены к другим виртуальным серверам, если они поддержи
ваются устройствами
Elastic Block Storage (EAS).
Эrо значение по умолчанию установлено
для большинства экземпляров ЕС2, поэтому вполне вероятно, что при необходимости вы
Глава
2.
101
Загрузка и системные демоны
сможете использовать этот метод. Понятно, что это похоже на загрузку с USВ-накопителя,
так что можно сориентироваться на загрузочном диске физической системы.
Вот что надо сделать.
1.
Запустите новый экземпляр в области видимости экземпляра, с которым возник
ли проблемы. В идеале этот экземпляр восстановления должен запускаться с од
ного и того же базового образа и использовать тот же тип экземпляра, что и неис
правная система.
2.
Остановите проблематичный экземпляр. (Но будьте осторожны, чтобы не выпол
нить операцию terтinate, потому что она удаляет образ загрузочного диска.)
3.
С помощью веб-консоли
AWS
или
CLI
отсоедините том от проблемной системы
и присоедините его к системе восстановления.
4.
Войдите в систему восстановления. Создайте точку монтирования и смонтируйте
том, а затем сделайте все, что необходимо для устранения проблемы. Затем от
ключите том. (Не выходит? Убедитесь, что вы не находитесь в одном из каталогов
этого тома.)
5.
В консоли
AWS
отсоедините том от экземпляра восстановления и подключите
его к проблематичному экземпляру. Запустите проблематичный экземпляр и на
дейтесь на лучшее.
Дроплеты компании
DigitalOcean
предлагают консоль с поддержкой
VNC,
к которой
можно получить доступ через Интернет, хотя использовать неб-приложения в некоторых
браузерах довольно неудобно. Компания
DigitalOcean
не предоставляет возможности от
соединить устройства хранения и перенести их в систему восстановления, как это делает
Amazon.
Вместо этого большинство системных образов позволяют загружаться с альтер
нативного ядра восстановления.
Чтобы получить доступ к ядру восстановления, сначала отключите дроплеты, а затем
смонтируйте ядро восстановления и перезагрузитесь. Если все пойдет хорошо, виртуаль
ный терминал предоставит вам доступ к однопользовательскому режиму. Более подроб
digi talocean. сот.
Google Compute Engine сначала должны
ные инструкции для этого процесса доступны на сайте
Проблемы с загрузкой в экземпляре
быть
исследованы путем изучения информации о последовательном порте экземпляра:
$ gcloud compute instances get-serial-port-output
экземпляр
Такую же информацию можно получить через веб-консоль
GCP.
Процесс перемещения диска, аналогичный описанному выше для облака
также доступен в
Google Compute Engine.
Вы используете
CLI
Amazon,
для удаления диска из
неработающего экземпляра и загрузки нового экземпляра, который монтирует диск
в качестве дополнительной файловой системы. Затем можно запускать проверки файло
вой системы, изменять параметры загрузки и при необходимости выбирать новое ядро.
Этот процесс подробно описан в документации
coтpute/docs/trouЬleshooting.
Google
по адресу
cloud. google. сот/
Глава 3
Управление доступом
и привилегии
суперпользователя
Эта глава посвящена контролю доступа, под которым, в отличие от концепции без
опасности, мы подразумеваем механизм принятия решений, связанных с безопасно
стью, реализуемый ядром и его делегатами. В главе
27,
посвященной безопасности, рас
сматривается более общий вопрос о том, как настроить систему или сеть, чтобы свести
к минимуму вероятность нежелательного доступа злоумышленников.
Контроль доступа
-
это область активных исследований, которая уже давно является
одной из главных проблем разработки операционных систем. За последнее десятилетие
мир
UNIX
и Liпux пережил кембрийский взрыв новых возможностей в этой области.
Первичным драйвером этого всплеска стало появление АРl-интерфейсов ядра, которые
позволяют сторонним модулям увеличивать или заменять традиционную систему управ
ления доступом
UNIX.
Этот модульный подход создает множество новых возможностей;
контроль доступа теперь так же открыт для изменений и экспериментов, как и любой
другой аспект
UNIX.
Тем не менее традиционная система остается стандартом
UNIX и
Liпux, и она подхо
дит для большинства установок. Даже системные администраторы, которые хотят выйти
на новые рубежи, должны овладеть основами.
Часть
104
1. Основы администрирования
3.1. СТАНДАРТНОЕ УПРАВЛЕНИЕ ДОСТУПОМ в UNIX
Стандартная модель контроля доступа в системе
UN IX
в течение десятилетий прак
тически не изменилась. С некоторыми усовершенствованиями она по-прежнему явля
ется стандартной для распространенных дистрибутивов операционных систем. Схема
соответствует таким основным правилам.
Решения по управлению доступом зависят от того, какой пользователь пытается
•
выполнить операцию или в некоторых случаях от членства этого пользователя
в группе
UNIX.
Объекты (например, файлы и процессы) имеют владельцев. Владельцы имеют ши
•
рокий (но не обязательно неограниченный) контроль над своими объектами.
Вы являетесь владельцами создаваемых вами объектов.
•
•
Специальная учетная запись пользователя под названием
root
может действовать
как владелец любого объекта.
•
Только пользователь
root
может выполнять особо важные административные
операции. 1
Некоторые системные вызовы (например,
ми пользователя
root;
settimeofday)
ограничены привилегия
реализация просто проверяет подлинность текущего пользова
теля и отклоняет операцию, если пользователь не является привилегированным
Другие системные вызовы (например,
kill)
(root).
реализуют различные вычисления, кото
рые включают как сравнение прав собственности, так и проверку специальных условий
для пользователя
root.
Наконец, файловые системы имеют свои собственные системы
управления доступом, которые они реализуют в сотрудничестве с уровнем ядра
VFS.
Они, как правило, более сложны, чем элементы управления доступом в других местах
ядра. Например, файловые системы гораздо чаще используют группы
UNIX для
контро
ля доступа.
Усложнение этой картины состоит в том, что ядро и файловая система тесно пере
плетаются. Например, вы управляете и общаетесь с большинством устройств через фай
лы, которые представляют их в каталоге
/dev.
Поскольку файлы устройств являются
объектами файловой системы, они подчиняются семантике управления доступом к фай
ловой системе. Ядро использует этот факт в качестве основной формы контроля доступа
для устройств.
m
Дополнительную информацию о файлах устройств см. в разделе
5.4.
Контроль доступа к файловой системе
В стандартной модели каждый файл имеет как владельца, так и группу, иногда назы
ваемую "групповым владельцем". Владелец может устанавливать разрешения для файла.
В частности, владелец может установить их настолько ограничительно, что никто другой
не сможет получить к нему доступ. Мы больше говорим о разрешениях файлов в главе
(см. раздел
1 Имейте
5
5.5).
в виду, что мы здесь описываем оригинальный дизайн системы контроля доступа. В наши
дни не все эти утверждения остаются истинными в буквальном смысле. Например, процесс Liпux,
который имеет соответствующие возможности (см. раздел
3.3), теперь может выполнять некоторые
root.
операции, которые ранее были ограничены только компетенцией пользователя
Глава
3. Управление доступом и
привилегии суперпользователя
105
Хотя владельцем файла всегда является один человек, многие могуr быть владельца
ми файлов, если они все являются частью одной группы. Группы традиционно опреде
ляются в файле
/etc/group,
но в настоящее время информация о группе часто сохра
няется в системе сетевых баз данных, такой как
информации см. главу
LDAP; для
получения дополнительной
17.
m Для получения дополнительной информации о группах см. раздел 8.5.
Владелец файла определяет, что могут сделать с ним члены групп. Эта схема позволя
ет делиться файлами между членами одного и того же проекта.
Владельца файла можно определить с помощью команды
$ ls -1
ls -1:
~qarth/todo
-rw-r----- 1 garth staff 1259
Мау
29 19:55 /Users/garth/todo
Данный файл принадлежит пользователю
garth
и группе
staf'f'.
Буквы и тире
в первом столбце символизируют разрешения на файл; для получения подробной ин
формации о том, как декодировать эту информацию, обратитесь к разделу
случае коды означают, что пользователь
члены группы
staf'f' могут его
garth может читать или
5.5.
В данном
записывать файл и что
прочитать.
m Дополнительную информацию о файлах passwd и qroup см. в главе 8.
И ядро, и файловая система отслеживают владельцев и группы как числа, а не как
текстовые имена. В подавляющем большинстве случаев идентификационные номера
UID) сопоставляются с именами пользовате
/etc/passwd, а идентификационные номера групп (GID) сопоставляются
с именами групп в файле /etc/group. (Для получения информации о более сложных
ВОЗМОЖНОСТЯХ см. главу 17.)
Текстовые имена, соответствующие идентификаторам UID и GID, определяются
только для удобства пользователей системы. Когда команды, такие как ls, должны ото
пользователей (короткие идентификаторы
лей в файле
бражать информацию о владельце в удобочитаемом формате, они ищуr каждое имя в со
ответствующем файле или базе данных.
Владение процессом
Владелец процесса может отправлять сигналы процесса (см. раздел
4.2),
а также мо
жет понизить (повысить) приоритет планирования процесса. Процессы на самом деле
имеют несколько идентификаторов, связанных с ними: реальный, текущий и сохранен
ный
UID;
реальный, текущий и сохраненный
GID;
а в системе
Linux -
"идентификатор
файловой системы", который используется только для определения разрешений доступа
к файлам. Вообще говоря, реальные номера используются для учета (и в настоящее вре
мя в значительной степени являются рудиментарными), а текущие номера
-
для опре
деления разрешений доступа. Реальные и текущие номера, как правило, одинаковы.
Сохраненные
UID
и
GID -
это парковочные места для идентификаторов, которые
в настоящее время не используются, но остаются доступными для вызова из процесса.
Сохраненные идентификаторы позволяют программе повторно входить в привилегиро
ванный режим работы и выходить из него; эта предосторожность уменьшает риск не
преднамеренного неправильного поведения.
Идентификатор
UID
файловой системы обычно описывается как деталь реализа
ции сетевой файловой системы
ром
UID.
NFS.
Обычно он совпадает с текущим идентификато
Часть
106
Учетная запись суперпользователя
Учетная запись
UNIX.
root
это запись всемогущего административного пользователя
root -
Она также называется учетной записью суперпользователя, хотя фактическое
имя пользователя
- root
(корень).
Определяющей характеристикой учетной записи
UID,
1. Основы администрирования
root
является ее идентификатор
равный О. Ничто не мешает вам изменять имя пользователя в этой учетной записи
или создавать дополнительные учетные записи, идентификаторы
UID
которых равны О;
однако это плохие идеи. 2 Такие изменения обычно создают непреднамеренные наруше
ния безопасности системы. Они также создают путаницу, когда другим людям приходит
ся иметь дело со странным способом настройки вашей системы.
Подробнее о системе
W
Традиционная система
NFS см.
UNIX
в главе
21.
позволяет суперпользователю (т.е. любому процессу,
для которого текущий идентификатор
UID
равен О) выполнять любую допустимую опе
рацию для любого файла или процесса. 3
Перечислим некоторые примеры привилегированных операций.
Создание файлов устройстn.
•
•
•
•
•
•
•
Установка системных часов.
Повышение лимитов использования ресурсов и приоритетов процессов.
Изменение имени хоста системы.
Настройка сетевых интерфейсов.
Открытие привилегированных сетевых портов (с номерами меньше
1024).
Выключение системы.
Примером полномочий суперпользователя является способность принадлежащего
ему процесса изменять свои идентификаторы
программа входа всистему
loqin
UID
и
GID.
Примером может служить
и ее эквиваленты в виде графического пользователь
ского интерфейса; процесс, который запрашивает ваш пароль при входе в систему, из
начально запускается с правами пользователя
root.
Если введенный вами пароль и имя
пользователя являются законными, то программа входа в систему
UID
и
GID
на ваши
UID
и
GID
login
изменяет свои
и запускает среду оболочки или графический поль
зовательский интерфейс. Как только процесс
root
изменит своего владельца и станет
обычным пользовательским процессом, он не сможет восстановить прежнее привилеги
рованное состояние.
Установка флагов
setuid и setgid
Традиционный контроль доступа UNIХдополняется системой подстановки идентифи
каторов, которая реализована ядром и файловой системой, взаимодействующими между
собой. Эта схема позволяет запускать специально выделенные исполняемые файлы с по
вышенными разрешениями, обычно с правами пользователя
root.
Это дает возможность
разработчикам и администраторам создавать структурированные способы, с помощью
которых непривилегированные пользователи могут выполнять привилегированные опе
рации.
2 Дженнин
Таунсенд, одна из наших рецензентов, прокомментировала это так: "Настолько плохие
идеи, что я боюсь даже упоминать их, чтобы кого-нибудь не спровоцировать".
3 3десь
ключевое слово
-
"допустимая". Некоторые операции (например, выполнение файла,
для которого не устаноw~ен бит разрешения выполнения) запрещены даже суперпользователю.
Глава
3. Управление доступом и
107
привилегии суперпользователя
Когда ядро запускает исполняемый файл с установленными битами разрешения
setuid
или
setgid, оно изменяет текущий идентификатор UID или GID результиру
UID или GID файла, содержащего образ программы, а не на UID
ющего процесса на
и
GID
пользователя, который ввел команду. Таким образом, привилегии пользователя
распространяются только на выполнение этой конкретной команды.
Например, пользователи должны иметь возможность изменять свои пароли. Однако,
поскольку пароли (традиционно) хранятся в защищенном файле
или
/etc/shadow, пользователям
Команда passwd проверяет, кто ее
нужна команда
passwd,
/etc/master.passwd
чтобы обеспечить доступ.
запускает, и соответственно настраивает свое пове
дение: пользователи могут изменять только собственные пароли, но пользователь
root
может изменять любой пароль.
Программы, запускаемые с флагом
setuid,
особенно для пользователя
создавать проблемы безопасности. Команды с установленным флагом
root, могут
setuid, постав
ляемые с системой, теоретически защищены; однако в прошлом уже были обнаружены
бреши в системе безопасности и, несомненно, некоторые будут обнаружены в будущем.
Самый верный способ минимизировать количество проблем, связанных с фла
гом
setuid, -
минимизировать количество программ, запускаемых с этим флагом.
Подумайте дважды, прежде чем использовать программное обеспечение, которое долж
но устанавливать флаг
setuid,
и избегайте применения флага
setuid
в вашем соб
ственном домашнем программном обеспечении. Никогда не используйте флаг
setuid
в программах, которые не бьmи написаны специально для этого.
Вы можете отключить установку флагов
системах, указав параметр
nosuid
setuid
и
в отдельных файловых
setgid
при их монтировании. Рекомендуется использовать
этот параметр в файловых системах, которые содержат домашние каталоги пользовате
лей или монтируются из менее надежных административных доменов.
W
Дополнительную информацию о возможностях монтирования файловой системы
см. в разделе
20.10.
3.2. УПРАВЛЕНИЕ УЧЕТНОЙ ЗАПИСЬЮ ROOT
Доступ к учетной записи
root
необходим для администрирования системы. Кроме
того, он представляет собой точку опоры для системы безопасности. Правильное ис
пользование этой учетной записи является решающим навыком.
Вход в учетную запись
Поскольку
root -
root
это просто еще один пользователь, большинство систем позволя
ют вам напрямую входить в учетную запись
root.
Однако это оказывается плохой иде
ей, поэтому в системе UЬuntu такие действия запрещены по умолчанию.
Во-первых, учетные записи
полнялись с правами
в
3:00 утра
root.
root не содержат
информации о том, какие операции вы
Это плохо, когда вы понимаете, что вчера испортили что-то
и не можете вспомнить, что именно вы изменили; это еще хуже, если доступ
бьт несанкционированным, и вы пытаетесь выяснить, что нарушитель сделал с вашей си
стемой. Другим недостатком является то, что сценарий входа в систему не содержит запи
сей о том, кто на самом деле выполняет данную работу. Если у нескольких пользователей
есть доступ к учетной записи
root,
вы не сможете определить, кто ее использовал и когда.
По этим причинам большинство систем позволяют отключать вход в учетные записи
root
на терминалах, через оконные системы и по всей сети
-
везде, кроме системной
Часть
108
1. Основы администрирования
консоли. Мы преддагаем вам использовать эти возможности. Чтобы узнать, как реали
зовать эту политику в вашей конкретной системе, см. раздел
Если у пользователя
root
17.3.
есть пароль (т.е. учетная запись
root
не отключена,
см. ниже), этот пароль должен быть очень сложным. Для получения дополнительных
комментариев относительно выбора пароля см. раздел
Команда
su: замена
27.3.
идентификатора пользователя
Лучше получать доступ к учетной записи
root
с помощью команды
без аргументов она выдает приглашение на ввод пароля пользователя
su. При вызове
root, а затем за
пускает оболочку с привилегированными правами. Эти права будут сохраняться, пока
вы не завершите работу (нажав комбинацию клавиш
exi t).
Команда
su
или выполнив команду
не фиксирует действия, производимые привилегированным пользо
вателем, но добавляет запись в журнальный файл с указанием, кто и когда вошел в си
root.
su способна
стему под именем
Команда
также подставлять вместо имени
root
имена других пользова
телей. Иногда единственный способ помочь пользователю в решении проблемы
йти с помощью команды
su
во
-
в его среду и воспроизвести ситуацию.
Зная чей-либо пароль, можно непосредственно зарегистрироваться в системе под его
именем, введя команду
имя_ пользовател я. В ответ будет выдан запрос на ввод
su -
пароля. При использовании в качестве ключа команды
su дефиса (-)
оболочка перейдет
в режим регистрации.
Точная реализация этого режима зависит от конкретной оболочки, но обычно в этом
режиме меняются количество и имена файлов запуска, считываемых интерпретатором.
Например, в режиме регистрации оболочка
этого режима
-
файл"/
.bashrc.
bash считывает файл "/ . bashyrofile,
а вне
При диагностике проблем конкретного пользователя ре
жим регистрации позволяет максимально точно воспроизвести среду, в которой он работал.
В одних системах пароль
или
login
root
позволяет регистрироваться с помощью команд
под любым именем. В других нужно сначала стать пользователем
менив в явном виде команду
su,
root,
su
при
а затем с помощью этой же команды перейти в другую
учетную запись. В таком случае вводить пароль не потребуется.
Рекомендуем сделать правилом при вводе команды указывать полное имя, например
/Ьin/su или /usr/Ьin/su, а не просто
программ с именем
su,
su.
Это послужит определенной защитой от тех
которые преднамеренно были изменены злоумышленником,
планировавшим собрать хороший "урожай" паролей 4 •
В некоторых системах, чтобы использовать команду
su,
необходимо быть членом
группы
whee\.
Команду su
в значительной степени может заменить программа
щий раздел), саму же команду
Программа
su лучше
sudo
(см. следую
всего оставить ддя аварийных ситуаций.
sudo: ограниченный
вариант команды
su
Без одной из усовершенствованных систем управления доступом, описанных в раз
деле
4 По
3.4,
трудно разрешить кому-то выполнять какую-то задачу (например, резервные
аналогичной причине настоятельно рекомендуем не включать запись
в переменную
path
(которую можно увидеть, набрав команду
echo
"."
(текущий каталог)
$РАТИ). Несмотря на
очевидное удобство, подобная конфигурация приводит к тому, что можно непреднамеренно
запустить "специальную" версию какой-нибудь системной команды, которую з.лоумышленник
оставил в качестве приманки. Пользователю
root следует бьrrь бдительным
вдвойне.
Глава
3. Управление
доступом и привилегии суперпользователя
109
копии), не предоставляя этому пользователю права свободно запускать систему. И если
учетная запись
root
используется несколькими администраторами, на самом деле у вас
будет только смутное представление о том, кто ее использует или что они сделали.
Наиболее широко используемым решением этих проблем является программа
под названием
sudo,
которая в настоящее время поддерживается Тоддом Миллером
Эта программа работает на всех наших иллюстративных системах и также
доступна в форме исходного кода на сайте sudo. ws. Мы рекомендуем использовать ее
(Todd Miller).
root.
sudo принимает в качестве аргумента командную строку, выполняемую
с правами root (или правами любого другого ограниченного пользователя). Программа
sudo проверяет файл /etc/sudoers (/usr/local/etc/sudoers в системе FreeBSD), в ко
тором перечислены люди, имеющие разрешение использовать программу sudo и команды,
в качестве основного метода доступа к учетной записи
Программа
которые им можно запускать на каждом хосте. Если предЛагаемая команда разрешена, про
грамма
sudo запрашивает собственный
пароль пользователя и выполняет команду.
В течение пяти минут после запуска программа
sudo
позволяет выполнять команды без
обязательного введения пароля (продолжительность этого периода можно менять), после
чего программа
sudo
перейдет в режим ожидания. Этот тайм-аут служит скромной защитой
от пользователей с привилегиями
Программа
sudo
sudo,
которые оставляют терминалы без присмотра.
ведет журнал выполненных командных строк, регистрирует хосты,
на которых они выполнялись, людей, которые их выполняли, каталоги, из которых они
были выполнены, и время, в которое они были выполнены. Эта информация может
быть зарегистрирована в системном журнале или помещена в файл по вашему выбору.
Мы рекомендуем использовать механизм
Syslog дЛЯ
пересылки записей журнала на без
опасный центральный сервер.
Запись журнала для выполнения команды
вателя
randy
sudo
/Ьin/cat
/etc/sudoers
пользо
может выглядеть так:
Dec 7 10:57:19 tigger sudo: randy: TTY=ttypO ; PWD=/tigger/users/randy;
USER=root ; COММAND=/bin/cat /etc/sudoers
Пример конфигурации
Файл
sudoers
разработан таким образом, что одна версия может использоваться
сразу на нескольких разных хостах. Вот типичный пример.
# Define aliases for machines in CS & Physics departments
Host_Alias CS = tigger, anchor, piper, moet, sigi
Host Alias PHYSICS = eprince, pprince, icarus
# Define collections of commands
Cmnd_Alias DUMP = /sbin/dump, /sЬin/restore
Cmnd Alias WATCHDOG = /usr/local/Ьin/watchdog
Cmnd Alias SHELLS = /Ьin/sh, /Ьin/dash, /Ьin/bash
# Permissions
PHYSICS = ALL
mark, ed
CS = /usr/sЬin/tcpdump : PHYSICS = (operator) DUMP
herb
ALL = (ALL) ALL, !SHELLS
lynda
ALL, !PHYSICS = NOPASSWD: WATCHDOG
%wheel
Первые два набора строк определяют группы хостов и команды, которые упоми
наются в дальнейших спецификациях разрешений, включенных в файл. Списки могут
быть включены буквально в спецификации, но псевдонимы облегчают чтение и пони
мание файла
sudoers;
они также упрощают обновление файла в будущем. Также воз-
Часть
110
1. Основы
администрирования
можно определить псевдонимы для пользователей и групп пользователей, для которых
могут выполняться команды.
m
Дополнительную информацию о файле
sysloq см.
в главе
10.
Каждая строка спецификации разрешений содержит следующую информацию.
•
•
•
•
Пользователи, к которым относится запись.
Хосты, на которые распространяется эта запись.
Команды, которые могут выполняться указанными пользователями.
Пользователи, которым разрешается выполнять команды.
Первая строка разрешений применяется к пользователям
в группе
ALL
PHYSICS (eprince, pprince
и
icarus).
mark
и
ed
на машинах
Встроенный командный псевдоним
позволяет им выполнять любую команду. Поскольку в круглых скобках не указан
список пользователей, программа
sudo будет
запускать команды с правами
root.
tcpdump
на машинах группы cs и команды вывода дампа на машинах группы PHYSICS. Однако
команды вывода дампа могут выполняться только с правами пользователя operator,
Вторая строка разрешений позволяет пользователю
herb
запускать утилиту
а не суперпользователя. Реальная командная строка, которую должен был бы ввести
пользователь herb, выглядела бы так:
ubuntu$ sudo -u operator /usr/sbin/ dWDp Ou /dev/sdal
Пользователь
lynda
может запускать команды как любой пользователь на любой
машине, за исключением того, что она не может запускать несколько общих оболочек.
Означает ли это, что пользователь
lynda
действительно не имеет доступа к корневой
оболочке? Конечно, нет:
ubuntu$ ер -р /bin/sh/tmp/sh
ubuntu$ sudo /tmp/sh
Вообще говоря, любая попытка разрешить "все команды, кроме ... " обречена на про
вал, по крайней мере в техническом смысле. Тем не менее может оказаться целесоо
бразным настроить файл
оболочку с правами
root
sudoers таким
образом, чтобы напомнить о том, что вызывать
крайне нежелательно.
Последняя строка позволяет пользователям группы
манду
watchdog с
правами
root
wheel выполнять локальную ко
eprince, pprince и icarus.
на всех машинах, кроме
Кроме того, для выполнения этой команды не требуется пароль.
Обратите внимание на то, что команды в файле
sudoers
указаны с полными име
нами путей, чтобы люди не могли выполнять свои собственные программы и сценарии
с правами
root.
Хотя в вышеприведенном примере это не показано, можно указать ар
гументы, допустимые для каждой команды.
Чтобы вручную изменить файл
sudoers,
используйте команду
visudo, которая про
(vi или любой
веряет, что никто другой не редактирует файл, вызывает для него редактор
редактор, указанный вами в переменной среды
EDITOR),
а затем проверяет синтаксис от
редактированного файла перед его установкой. Этот последний шаг особенно важен, по
тому что неправильный файл
sudoers
может помешать вам снова исправить ошибку.
Преимущества и недостатки программы sudo
Использование программы
•
•
sudo
имеет следующие преимущества.
Благодаря ведению журнала команд значительно улучшается учет.
Пользователи могут выполнять определенные задачи, не имея неограниченных
прав
root.
3. Управление
Глава
111
доступом и привилегии суперпользователя
• Реальный пароль root может быть известен только одному или двум людям. 5
• Использование программы sudo быстрее, чем вызов su или вход в систему с пра
вами root.
• Привилегии можно отменить без необходимости изменения пароля пользователя
root.
• Поддерживается канонический список всех пользователей с правами root.
• Уменьшается вероятность того, что корневая оболочка останется без присмотра.
• Один файл может управлять доступом ко всей сети.
У программы
sudo
есть и несколько недостатков. Хуже всего то, что любое наруше
ние безопасности личной учетной записи
самой учетной записи
root.
sudoer
может быть эквивалентно нарушению
Вы не можете сделать многого, чтобы противостоять этой
угрозе, кроме как предостеречь пользователей, перечисленных в файле
sudoers, чтобы
root. Вы
они защитили свои учетные записи, поскольку они будут иметь учетную запись
также можете регулярно запускать взломщик паролей ДllЯ пользователей, перечислен
ных в
sudoers,
чтобы убедиться, что они выбрали правильные пароли. Все комментарии
по выбору пароля см. в разделе
27.3.
Регистрацию команд в программе
sudo
можно легко обойти с помощью таких трю
ков, как временный выход в оболочку из разрешенной программы, или команды
sh
и
sudo su.
sudo
(Такие команды отображаются в журналах, поэтому вы по крайней мере
узнаете, что они бьuш запущены.)
Программа
sudo и расширенный контроль доступа
Программе
sudo
как способ разделения привилегий корневой учетной записи пре
восходит многие из систем управления доступом, описанных в разделе
3.4.
Вы точно определяете, как будут разделены привилегии. Ваше подразделение мо
•
жет быть более грубым или более тонким, чем привилегии, определенные ДllЯ вас
с помощью готовой системы.
Простые конфигурации
•
-
самые распространенные
-
просты в настройке, обслу
живании и понимании.
Программа
•
sudo
работает на всех системах
UNlX
и
Linux.
Вам не нужно беспоко-
иться об управлении различными решениями на разных платформах.
Вы можете использовать один файл конфигурации во всей организации.
•
•
Вы бесплатно получаете качественные протоколы.
Поскольку система уязвима для катастрофической компрометации, если корневая
учетная запись будет взломана, основным недостатком контроля доступа на основе про
граммы
sudo
является то, что потенциальная поверхность атаки расширяется и распро
страняется на учетные записи всех администраторов.
Программа
sudo
хорошо работает как инструмент благонамеренных администрато
ров, которым необходим общий доступ к привилегиям
root.
Она также отлично под
ходит для того, чтобы остальные пользователи могли выполнить несколько конкретных
операций. Несмотря на синтаксис конфигурации, который предполагает иное, програм
ма
sudo,
к сожалению, не является безопасным способом определить ограниченные об
ласти автономии или вынести определенные операции за пределы безопасной области.
W
1 Или
Для получения дополнительной информации о взломе пароля см. раздел
даже никому, если у вас есть правильная система хранения паролей.
27.5.
112
Часть
1. Основы
администрирования
Даже не пытайтесь использовать эти конфигурации. Если вам нужна эта функцио
нальная возможность, лучше всего подключить одну из систем управления доступом,
описанных в разделе
3.4.
Типичная настройка
За многие годы система конфигурации
sudo
накопила много функций. Она была
модифицирована, чтобы учесть множество необычных ситуаций и крайних случаев.
В результате текущая документация создает впечатление сложности, которое не обяза
тельно оправданно.
Поскольку важно, чтобы программа
sudo
была надежным и безопасным инструмен
том, естественно задаться вопросом, можете ли вы подвергать свои системы дополни
тельному риску, если не используете ее расширенные функции и не устанавливаете пра
вильные значения дпя всех параметров. Ответ: нет.
90%
содержимого файла
sudoers
ADMINS = alice,
ALL = (ALL) ALL
User Alias
ADMINS
ЬоЬ,
выглядит примерно так:
charles
Это совершенно респектабельная конфигурация, и во многих случаях нет необходи
мости ее усложнять. Мы упоминали несколько дополнительных функций, которые вы
можете использовать в следующих разделах, но все они являются инструментами дпя ре
шения проблем, которые полезны дпя конкретных ситуаций. Для общей надежности
больше ничего не требуется.
Управление окружением
Многие команды проверяют значения переменных окружения и изменяют свое пове
дение в зависимости от того, что они находят. В случае, если команды выполняются с пра
вами
root.
этот механизм может быть полезным и многообещающим способом атаки.
Например, допустим, что несколько команд запускают программу, указанную в пере
менной окружения EDITOR, дпя редактирования текстового файла. Если эта переменная
указывает на вредоносную программу хакера вместо текстового редактора, вполне веро
ятно, что в конечном итоге вы запустите эту программу с правами
Чтобы минимизировать этот риск, поведение программы
sudo
root. 6
по умолчанию заклю
чается в передаче только минимального, дезинфицированного множества переменных
окружения дпя команд, которые она запускает. Если вам нужны дополнительные пере
менные окружения, которые нужно передать, вы можете их перечислить, добавив в спи
сохраняют несколько переменных окружения, используемых Х
пересылки ключей
Windows и механизмом
SSH.
Для разных пользователей или групп можно настроить разные списки
env_ keep,
но
конфигурация быстро усложнится. Мы предпагаем придерживаться единого универсаль
ного списка и быть относительно консервативным с исключениями. которые вы закре
пляете в файле
sudoers.
1'Поясним,
сценарий в этом случае заключается в том, что ваша учетная запись была
что
скомпрометирована, но злоумышленник не знает ваш фактический пароль и поэтому не может
напрямую запускать программу
sudo.
К сожалению, это обычная ситуация, все, что требуется,
это терминальное окно, оставленное на мгновение без присмотра.
-
Глава
3. Управление доступом
и привилегии суперпользователя
113
Если необходимо сохранить переменную среды, которая не указана в файле
sudoers, ее можно явно установить
$ sudo EDITOR=emacs vipw
в командной строке
sudo.
редактирует файл системного пароля с помощью редактора
Например, команда
emacs.
Эта функция имеет
некоторые потенциальные ограничения, но они не распространяются на пользователей,
которые могут запускать все команды.
Программа sudo без паролей
Часто можно с сожалением видеть, что программа
команды с правами
root
гурация задается с помощью ключевого слова
ALL = (ALL) NOPASSWD: ALL
ansiЫe
sudo
настроена на выполнение
без необходимости вводить пароль. Для справки, эта конфи
NOPASSWD
#
в файле
sudoers.
Например:
Не делайте этого
Иногда это делается из-за лени, но, как правило, основная причина
полнить какие-то операции без санкции программы
sudo.
-
желание вы
Наиболее распространенны
ми случаями являются удаленная настройка с помощью такой системы, как AnsiЫe, или
запуск команд из планировщика
W
cron.
Дополнительную информацию о системе AnsiЫe см. в главе
23.
Излишне говорить, что эта конфигурация опасна, поэтому избегайте ее, если може
те. По крайней мере ограничьте выполнение небезопасного доступа к определенному
набору команд, если сможете.
Другим вариантом, который хорошо работает в контексте удаленного выполнения,
является замена введенных вручную паролей аутентификации с помощью программы
ssh-agent
и перенаправленных SSН-ключей. Вы можете настроить этот метод аутен
тификации с помощью модуля РАМ на сервере, где будет выполняться программа
sudo.
Большинство систем не включают модуль РАМ, который по умолчанию использует
аутентификацию на основе
SSH,
но он легко доступен. Найдите пакет
pam_ ssh _ agent_
auth.
Пересылка ключей
SSH
имеет собственный набор проблем безопасности, но это,
безусловно, лучше, чем полное отсутствие аутентификации.
Приоритет
sudo потенциально может быть рассмотрен несколькими
sudoers. Например, рассмотрим следующую конфигурацию:
ADMINS = alice, ЬоЬ, charles
User Alias
MYSQL_ADMINS = alice, ЬоЬ
User Alias
Вызов программы
запися
ми в файле
%wheel
MYSQL_ADMINS
ADMINS
ALL
ALL
ALL
(ALL) ALL
(mysql) NOPASSWD: ALL
(ALL) NOPASSWD: /usr/sbin/logrotate
W Дополнительную информацию о конфигурации РАМ см. в разделе 17.3.
Здесь администраторы могут запускать команду
тель без предоставления пароля. Администраторы
манду от имени пользователя
mysql
logrotate
MySQL
как обычный пользова
могут выполнять любую ко
без пароля. Любой человек в группе
выполнять любую команду под любым идентификатором
пройти аутентификацию с помощью пароля.
UID,
wheel
может
но сначала он должен
Часть
114
Если пользователь находится в группе
wheel,
1. Основы
администрирования
она потенциально охватывается каж
дой из последних трех строк. Откуда вы знаете, какая из них будет определять поведение
sudo?
Правило заключается в том, что
sudo
всегда подчиняется последней соответству
ющей строке, причем совпадение определяется всеми четырьмя параметрами: именем
пользователя, хостом, именем целевого пользователя и командой. Каждый из этих эле
ментов должен соответствовать строке конфигурации, или строка просто игнорируется.
Поэтому исключения
NOPASSWD
должны соответствовать их более общим аналогам,
как показано выше. Если бы порядок последних трех строк был отменен, то бедной
Алисе 7 пришлось бы вводить пароль независимо от того, какую команду
sudo она пыта
лась бы запустить.
Программа sudo без терминала управления
Помимо проблемы аутентификации без пароля, автоматическое выполнение про
граммы
sudo
(например, из планировщика
cron)
часто происходит без обычного тер
минала управления. В этом нет ничего неправильного, но это странная ситуация, кото
рую программа
опция
sudo
requiretty.
может обнаружить и отклонить, если в файле
включена
sudoers
Этот параметр не задается по умолчанию с точки зрения программы
торые дистрибутивы операционных систем включают его в файлы
sudo, но неко
sudoers по умолча
нию, поэтому его стоит проверить и удалить. Найдите строку, имеющую вид
Defaults
requiretty
и поменяйте в ней значение на противоположное:
Defaults
!requiretty
Опция
requiretty
предлагает небольшую символическую защиту от определенных
сценариев атаки. Тем не менее ее легко обойти, таким образом, она дает мало реальных
преимуществ в плане безопасности. По нашему мнению, опцию
requiretty
необходи
мо отключить, потому что это общий источник проблем.
Конфигурация sudo на уровне сайта
Поскольку файл
sudoers
включает текущий хост в качестве подходящего критерия
для строк конфигурации, вы можете использовать один главный файл
sudoers
в адми
нистративном домене (т.е. в области, где гарантируется эквивалентность имен хостов
и у•1етных записей пользователей). Этот подход немного усложняет исходные настройки
sudoers,
но это отличная идея по нескольким причинам. Вам следует это попробовать.
Основное преимущество этого подхода заключается в том, что нет никакой тайны
в том, кто и какие имеет разрешения и для каких хостов. Все записано в одном авто
ритетном файле. Например, когда администратор покидает вашу организацию, нет не
обходимости отслеживать все хосты, на которых у этого пользователя могли быть пра
ва
sudo.
Когда необходимы изменения, вы просто изменяете главный файл
sudoers
и рассылаете его заново.
Естественным следствием этого подхода является то, что разрешения
sudo
быть лучше выражены в терминах учетных записей пользователей, а не групп
Например, запись
%wheel
ALL
7 Традиционный
=
ALL
персонаж в описаниях криптографических протоколов.
-
Примеч. ред.
могут
UNIX.
Глава
3. Управление доступом
и привилегии суперпользователя
115
имеет некоторую интуитивную привлекательность, но она отменяет перечисление при
вилегированных пользователей на каждой локальной машине. Вы не можете взглянуть
на эту строку и определить, к кому она относится, не подходя к рассматриваемой маши
не. Поскольку идея состоит в том, чтобы сохранить всю соответствующую информацию
в одном месте, лучше избегать такого типа группировки при совместном использовании
файла
sudoers
в сети. Конечно, если членство в вашей группе тесно координируется
по всей организации, группы можно использовать без проблем.
Распределение файла
sudoers
лучше всего достигается с помощью более широкой
системы управления конфигурацией, как описано в главе
23.
Однако если вы еще не
достигли такого уровня, вы можете легко разослать его самостоятельно. Однако будьте
осторожны: установка поддельного файла
sudoers -
это быстрый путь к катастрофе.
Это также удобный файл для использования в системе мониторинга целостности фай
лов; см. раздел
28.8.
В случае отсутствия системы управления конфигурацией лучше всего использовать
сценарий извлечения информации, который заканчивается планировщиком
дом хосте. Используйте команду
scp
вестного центрального репозитория, а затем проверьте его с помощью
-с
cron на каж
sudoers из из
команды visudo
для копирования текущего файла
-f newsudoers перед установкой, чтобы убедиться, что формат является приемле
мым для локальной программы
sudo. Команда scp проверяет ключ хоста удаленного сер
sudoers поступает с вашего хоста, а не с поддельного сервера.
При совместном использовании файла sudoers спецификация имени хоста может
быть немного сложной. По умолчанию программа sudo использует вывод команды
hostname в качестве текста, который нужно сравнить. В зависимости от соглашений,
вера, гарантируя, что файл
используемых в вашей организации, это имя может включать или не включать часть до
мена (например,
или
anchor
стов, указанные в файле
anchor. cs. colorado. edu).
sudoers,
В любом случае имена хо
должны совпадать с именами, которые возвращают
все хосты. (Вы можете включить опцию
fqdn
в файле
sudoers,
чтобы попытаться пре
образовать локальные имена хостов в их полные формы.)
Совпадение имен хостов сложнее проверяется в облаке, где имена экземпляров часто
по умолчанию имеют алгоритмически сгенерированные шаблоны. Программа
нимает простые символы шаблонов соответствия
sudo
по
(подстановки) в именах хостов, по
этому рассмотрите возможность использования схемы именования, которая включает
в себя некоторые указания на классификацию безопасности каждого хоста с точки зре
ния программы
sudo.
Кроме того, можно использовать виртуальные сетевые функции облачного провай
дера для разделения хостов по JР-адресу, а затем сопоставлять IР-адреса вместо имен
хостов из файла
sudoers.
Отключение учетной записи
root
Если ваша организация стандартизирует использование программы
ли будете использовать реальные пароли
root.
sudo,
вы вряд
Большая часть вашей административной
команды никогда не будет иметь возможности использовать их.
Этот факт ставит вопрос о том, нужен ли пароль
root
вообще. Если вы решите, что
root, установив
root равным * или другой произвольной строке фиксирован
Linux, команда passwd -1 блокирует учетную запись, добавляя
не нужен, вы можете полностью отключить вход в систему с правами
зашифрованный пароль
ной длины. В системе
знак
!
к зашифрованному паролю с эквивалентными результатами.
Часть
116
*и
Символы
1. основы администрирования
! - просто условности; никакое программное обеспечение не проверя
ет их явным образом. Их эффект заключается в задании некорректных хешей паролей.
В результате пароль
root
просто не проходит проверку.
Основной эффект блокировки учетной записи
ватель
root
заключается в том, что пользо
не может войти в систему, даже с консоли. Ни один из пользователей не
root
может успешно запустить программу
пароля
root.
su, потому что дпя этого также требуется проверка
root продолжает существовать, и все программ
выполняется с правами root, продолжает это делать.
Однако учетная запись
ное обеспечение, которое обычно
В частности, программа
sudo
работает как обычно.
Основное преимущество отключения учетной записи
вам не нужно записывать пароль
ность взлома пароля
root,
root
заключается в том, что
root
и управлять им. Вы также устраняете возмож
но это более приятный побочный эффект, чем убедительная
причина для перехода без пароля. Редко используемые пароли уже имеют низкий риск
компрометации.
Особенно полезно иметь реальный пароль
на физических компьютерах (в от
root
личие от облачных или виртуальных экземпляров, см. главы
9
с оборудованием или конфигурацией мешают процессу
или загрузке, реальным
sudo
и
24).
Если проблемы
компьютерам необходимо будет уделить внимание. В этих случаях удобно иметь тради
ционную учетную запись
Система
root
Ubuntu
как аварийный резерв.
поставляется с отключенной учетной записью
административный доступ осуществляется через программу
root, и весь
sudo или ее эк
вивалент с графическим пользовательским интерфейсом. Если хотите, мо
жете установить пароль
root на Ubuntu, а затем разблокировать учетную за
sudo passwd -u root.
пись с помощью команды
Системные учетные записи, отличные от
Пользователь
root
root
обычно является единственным, кто имеет особый статус с точ
ки зрения ядра, но в большинстве систем существуют и другие псевдопользователи. Вы
можете идентифицировать эти фиктивные учетные записи по их идентификаторам
которые обычно не превышают
100.
Чаще всего идентификаторы
ся к системным учетным записям, а
UID от 10 до 100 -
UID
менее
UID,
10 относят
к псевдопользователям, связан
ным с определенными компонентами программного обеспечения.
Обычно принято заменять звездочкой зашифрованное поле пароля этих специаль
ных пользователей в файле
shadow
или
master. passwd,
чтобы под их учетными за
писями нельзя было войти в систему. В качестве их системных оболочек должны быть
установлены программы /Ьin/false или /Ьin/nologin, чтобы защитить от удаленных
попыток входа в систему, которые используют альтернативы паролей, такие как файлы
ключей
SSH.
Как и в случае с учетными записями пользователей, в большинстве систем определя
ются множество связанных с системой групп, которые имеют одинаково низкие иден
тификаторы
W
GID.
Дополнительную информацию о файлах
shadow
и шaster .passwd см. в разделе
8.3.
Файлам и процессам, являющимся частью операционной системы, которые не долж
ны принадпежать к категории
тели Ьin или
daemon.
root,
иногда в качестве владельцев назначаются пользова
Теория заключалась в том, что это соглашение поможет избежать
угроз безопасности, связанных с владением правами
root.
Однако это не слишком ве
ский аргумент, и в современных системах часто используется только учетная запись
root.
Глава
3. Управление доступом
117
и привилегии суперпользователя
Основное преимущество псевдоучетных записей и псевдогрупп заключается в том,
что с их помощью можно безопаснее обеспечить доступ к определенным группам ре
сурсов, чем с помощью учетной записи
root.
Например, базы данных часто реализуют
сложные системы управления доступом. С точки зрения ядра они работают как псевдо
пользователь, такой как
myscq,
который владеет всеми ресурсами, связанными с базой
данных.
Сетевая файловая система
ления пользователей
root
(NFS)
использует учетную запись
nobody
для представ
в других системах. Для удаленных суперпользователей, ко
торые должны быть лишены своих привилегированных полномочий, удаленный
равный О, должен быть сопоставлен с чем-то другим, кроме локального
Учетная запись
лей. В системе
UID,
UID,
равного О.
nobody действует как общее имя для этих удаленных суперпользовате
NFSv4 учетная запись nobody может применяться к удаленным поль
зователям, которые также не соответствуют действительной локальной учетной записи.
Ш Дополнительную информацию об учетной записи
Поскольку учетная запись
nobody
в разделе
nobody см.
21.2.
должна представлять обобщенного и относи
тельно бесправного пользователя, она не должна владеть файлами. Если учетная за
пись
nobody
владеет файлами, значит, удаленные суперпользователи могут их контро
лировать.
3.3.
РАСШИРЕНИЯ СТАНДАРТНОЙ МОДЕЛИ КОНТРОЛЯ ДОСТУПА
В предыдущих разделах описаны основные концепции традиционной модели управ
ления доступом. Несмотря на то, что эту модель можно описать на нескольких страни
цах, она выдержала испытание временем, потому что проста, предсказуема и способна
обрабатывать требования средней организации. Все варианты
UNIX
и
Linux
продолжа
ют поддерживать эту модель, и она по-прежнему остается стандартной и наиболее ши
роко распространенной.
В современных операционных системах эта модель включает в себя ряд важных усо
вершенствований. Текущий статус-кво обеспечивают три уровня программного обеспе
чения.
•
•
•
Стандартная модель, описанная в этом пункте.
Расширения, которые обобщают и точно настраивают базовую модель.
Расширения ядра, которые реализуют альтернативные подходы.
Эти категории являются не архитектурными слоями, а скорее историческими арте
фактами. Ранние производные системы
UNIX
использовали стандартную модель, но ее
недостатки были широко признаны даже тогда. Со временем сообщество начало разра
батывать обходные пути для решения нескольких более насущных проблем. В интересах
поддержания совместимости и поощрения широкого распространения изменения обыч
но были структурированы как усовершенствования традиционной системы. Некоторые
из этих настроек (например, РАМ) теперь считаются стандартами
UNIX.
За последнее десятилетие в области модуляризации систем контроля доступа были
достигнуты большие успехи. Эта эволюция позволяет еще более радикально изменить
контроль доступа. Мы рассмотрим некоторые из наиболее распространенных подклю
чаемых параметров для
Linux
и
FreeBSD,
начиная с раздела
3.4.
Часть
118
1. Основы администрирования
Пока мы рассмотрим некоторые из более прозаических расширений, которые связа
ны с большинством систем. Во-первых, мы рассмотрим проблемы, которые пытаются
решить эти расширения.
Недостатки стандартной модели
Несмотря на свою элегантность, стандартная модель имеет некоторые очевидные не
достатки.
Начнем с того, что учетная запись
•
root
представляет собой потенциально един
ственную точку отказа. Если она будет скомпрометирована, целостность всей си
стемы будет нарушена, и, по существу, нет ограничений на ущерб, который может
нанести злоумышленник.
Единственный способ разделить привилегии учетной записи
•
граммы с флагом
setuid.
писать про
root -
К сожалению, как показывает постоянный поток об
новлений программного обеспечения, связанных с безопасностью, написать без
опасное программное обеспечение сложно. Любая программа, использующая флаг
setuid,
является потенциальной целью.
Стандартная модель мало что может сказать о безопасности в сети. Нет компью
•
тера, к которому непривилегированный пользователь имел бы физический доступ
и которому можно было бы доверять, чтобы точно представлять владельцев запу
скаемых процессов. Кто скажет, что кто-то не переформатировал диск и не уста
новил свою собственную операционную систему с идентификатором
UID
по сво
ему выбору?
В стандартной модели определение группы является привилегированной опера
•
цией. Например, универсальный пользователь не может выразить намерение, что
только пользователи
alice
и ЬоЬ должны иметь доступ к определенному файлу.
Поскольку многие правила управления доступом встроены в код отдельных ко
•
манд и демонов (классический пример
-
программа
passwd),
невозможно пере
определить поведение системы без изменения исходного кода и перекомпиляции.
В реальном мире это непрактично и провоцирует ошибки.
Стандартная модель также практически не поддерживает аудит или ведение жур
•
нала. Вы можете видеть, к каким группам
UNIX
принадлежит пользователь, но
не можете определить, что такое членство в группах позволяет пользователю де
лать. Кроме того, нет реального способа отслеживать использование повышенных
привилегий или посмотреть, какие операции они выполнили.
РАМ: подключаемые модули аутентификации
Учетные записи пользователей традиционно защищены паролями, хранящимися
(в зашифрованном виде) в файлах
/etc/shadow
или
/etc/master.passwd
или в экви
валентной сетевой базе данных.
Многим программам может потребоваться проверка учетных записей, включая
login, sudo, su
и любую программу, которая требует регистрации на рабочей станции
с графическим пользовательским интерфейсом.
m
Дополнительную информацию о файлах
shadow и 111aster .passwd см. в разделе 8.3.
Эти программыдействительно не должны иметь жестко запрограммированных
ожиданий о том, как должны шифроваться и проверяться пароли. В идеале они даже
Глава
3. Управление
119
доступом и привилегии суперпользователя
не должны предполагать, что пароли вообще используются. Что делать, если вы хотите
использовать биометрическую идентификацию, систему идентификации сети или ка
кую-либо двухфакторную аутентификацию? На помощь приходят подключаемые моду
ли аутентификации РАМ!
РАМ (PluggaЬle
это оболочка для различных библиотек ау
Autentication Modules) -
тентификации, реализующих разные методы. Системные администраторы определя
ют методы аутентификации, которые они хотят использовать в системе, а также соот
ветствующие контексты для каждого из них. Программы, требующие аутентификации
пользователя, просто вызывают систему РАМ, а не реализуют собственные методы ау
тентификации.
В свою очередь РАМ вызывает библиотеку аутентификации, указанную системным
администратором. Строго говоря, РАМ
-
это технология аутентификации, а не техно
логия контроля доступа. Следовательно, вместо ответа на вопрос "Имеет ли пользова
тель Х разрешение на выполнение операции У?", она помогает ответить на вопрос "Как
узнать, что это действительно пользователь Х?"
РАМ является важным компонентом цепочки контроля доступа в большинстве си
стем, а конфигурация РАМ является общей административной задачей. Более подроб
ную информацию о РАМ вы можете найти в разделе
Kerberos: сетевая
17.3.
криптографическая аутентификация
Как и РАМ, протокол
Kerberos
занимается аутентификацией, а не контролем досту
па как таковым. Однако, если РАМ является основой проверки подлинности,
Kerberos
является специфическим методом аутентификации. В организациях, которые исполь
зуют
а
Kerberos, РАМ и Kerberos, как правило,
Kerberos - фактическая реализация.
работают вместе, РАМ
-
это оболочка,
Протокол KerЬeros использует доверенную стороннюю организацию (сервер) для ау
тентификации всей сети. Вы не аутентифицируете себя на машине, которую исполь
зуете, а предоставляете свои учетные данные службе
Kerberos.
Затем
Kerberos
выдает
криптографические данные, которые вы можете представить другим службам в качестве
доказательства вашей подлинности.
это зрелая технология, которая широко используется десятилетиями. Это
Kerberos -
стандартная система аутентификации, используемая системой
ется частью системы
в разделе
Active Directory Microsoft.
Windows, которая явля
Kerberos написано
Больше о технологии
17.3.
Списки управления доступом к файловой системе
Поскольку управление доступом к файловой системе крайне важно для систем
и
Linux,
UNIX
это одна из главных целей их разработки. Наиболее распространенным допол
нением была поддержка списков управления доступом
(access control lists - ACL),
обоб
щение традиционной модели прав пользователь/группа/друтое, которая позволяет уста
навливать разрешения для нескольких пользователей и групп одновременно.
Списки
ACL
являются частью реализации файловой системы, поэтому они должны
явно поддерживаться любой файловой системой, которую вы используете. Тем не менее
теперь все основные файловые системы
UNIX и Linux
в той или иной форме поддержи
вают АСL.
Поддержка
дарта
POSIX,
ACL обычно осуществляется
в одной из двух форм: ранний вариант стан
который так и не дошел до формального принятия, но был широко реа-
Часть
120
лизован в любом случае, и система, стандартизованная
Microsoft Windows.
Оба стандарта
ACL
Ш Дополнительную информацию об
Возможности
N FSv4,
которая адаптирует
описаны более подробно в разделе
NFS см.
в главе
ACL
5.6.
21.
Linux
Системы мандатов
root
1. Основы администрирования
(capabllity systems) делят полномочия
30) отдельных разрешений.
учетной записи
на несколько (около
Версия системы мандатов в
Linux
основана на черновике проекта
POSIX 1003.le,
который используется, несмотря на то, что он официально не был одобрен в качестве
стандарта. Ломимо прочего, теоретики считают, что эта зомби-система не соответствует
академической концепции системы мандатов. Однако это не важно; система существует,
и
Linux
называет ее мандатной, поэтому мы подчиняемся.
Мандаты могут быть унаследованы от родительского процесса. Они также могут
быть включены или отключены атрибутами, установленными в исполняемом файле,
в процессе, напоминающем выполнение программы с флагом
setuid.
Лроцессы могут
отказаться от мандатов, которые они не планируют использовать.
Традиционные полномочия
это просто объединение всех мандатов, поэтому
root -
существует довольно прямое сопоставление между традиционной моделью и мандатной.
Мандатная модель является более детальной.
В качестве примера укажем, что мандат
Linux
под названием САР _ NET _ BIND_ SERVICE
контролирует возможность процесса связывания с привилегированными сетевыми порта
ми (номера которых меньше
с правами
root,
1024).
Некоторым демонам, которые традиционно работают
нужен только этот конкретный мандат. В системе мандатов такой демон
может теоретически работать как непривилегированный пользователь и получать мандат
на возможность привязки к порту из исполняемою файла. Лока демон не проверяет явно,
что он работает от имени пользователя
root,
он даже не должен знать о нем.
Так ли все это в реальном мире? Совсем нет. Как это обычно бывает, мандаты эво
люционировали и стали более мощной технологией, чем система взаимодействия с поль
зователями. Они широко используются системами более высокого уровня, такими как
AppArmor
(см. раздел
3.4)
и
Docker (см.
главу
25),
но редко используются самостоятельно.
Для администраторов полезно просмотреть тап-страницу capaЬili ties
(7), чтобы
понять, что включено в каждую из категорий мандатов.
Пространства имен
Система
Linux
Linux
может распределять процессы по иерархическим разделам
(пространствам имен), из которых видна только часть системных файлов, се
тевых портов и процессов. Ломимо прочего, эта схема действует как форма
превентивного контроля доступа. Вместо того, чтобы основывать решения
управления доступом на потенциально тонких критериях, ядро просто отри
цает существование объектов, которые не видны изнутри данной области.
Внутри раздела применяются обычные правила контроля доступа, и в большинстве
случаев процессы, которые бъmи ограничены, даже не знают об этом. Лоскольку огра
ничение является необратимым, внутри раздела процессы могут выполняться с правами
root,
не опасаясь, что они могут поставить под угрозу другие части системы.
Этот умный трюк является одним из оснований для программной контейнеризации
и его наиболее известной реализации
Docker.
Полная система намного сложнее и вклю-
Глава
3. Управление
доступом и привилегии суперпользователя
121
чает в себя расширения, такие как доступ к файловой системе для копирования на за
пись. Нам еще немного нужно сказать о контейнерах в главе
25.
В качестве формы контроля доступа пространство имен является относительно гру
бым подходом. Конструкция правильно настроенных гнезд для процессов, в которых
можно жить, также несколько сложна.
В настоящее время эта технология применяется в первую очередь к дополнительным
службам, а не к внутренним компонентам операционной системы.
КОНТРОЛЬ ДОСТУПА
3.4. СОВРЕМЕННЫЙ
Учитывая широкий диапазон вычислительных сред и смешанный успех усилий
по продвижению стандартной модели, разработчики ядра неохотно выступали в каче
стве посредников в более широких дискуссиях по контролю доступа. В мире
туация активизировалась в
2001
Linux
си
г., когда Агентство национальной безопасности США
предложило интегрировать свою систему
в ядро в качестве
Enhanced Linux (SELinux)
стандартного средства.
По нескольким причинам сторонники ядра сопротивлялись этому слиянию. Вместо
SELinux или другую альтернативную систему, они разработали
того чтобы использовать
интерфейс уровня ядра
API Linux Security Modules,
позволяющий системам управления
доступом интегрироваться в качестве загружаемых модулей ядра.
Системы на основе
LSM
не действуют, если пользователи не загрузили и не вклю
чили их. Этот факт снижает барьеры для включения в стандартное ядро, и система
Linux
теперь поставляется с
ТОМОУО и
Yama),
SELinux
и четырьмя другими системами
(AppAnnor, Smack,
готовыми к работе.
Linux, в основном
(Robert Watson) над TrustedBSD. Этот код был вклю
чен в систему FreeBSD, начиная с версии 5. Он также предоставляет технологию песоч
ницы приложений, используемую в системах MacOS и IOS от Apple.
Разработки на стороне
BSD
примерно совпадают с разработками
благодаря работе Роберта Уотсона
Если одновременно задействованы несколько модулей управления доступом, для их
разрешения должна быть утверждена отдельная операция. К сожалению, система
LSM
требует явного сотрудничества между активными модулями, и ни один из существую
щих модулей не включает эту функцию. На данный момент системы
ограничены выбором одного дополнительного модуля
Linux
фактически
LSM.
Отдельные экосистемы
Контроль доступа по своей сути относится к уровню ядра. За исключением списков
управления доступом к файловой системе (см. раздел
5.6),
по существу, среди систем
в отношении альтернативных механизмов контроля доступа нет стандартизации. В ре
зультате каждое ядро имеет свой собственный набор доступных реализаций, и ни одна
из них не является кросс-платформенной.
Поскольку дистрибутивы
Linux
имеют общую линию ядра, все они теорети
чески совместимы со всеми раз.личными предложениями обеспечения без
опасности
Linux.
Однако на практике это не так: эти системы нуждаются
в поддержке на уровне пользователя в виде дополнительных команд, моди
фикаций компонентов уровня пользователя и профилей защиты для демо
нов и служб. Следовательно, у каждого дистрибутива есть только один или
два механизма контроля доступа, которые он активно поддерживает.
122
Часть
1. Основы
администрирования
Обязательный контроль доступа
Стандартная модель
UNIX
рассматривается как форма "избирательного контроля
доступа", поскольку позволяет владельцам контролируемых доступом объектов устанав
ливать права на них. Например, вы можете разрешить другим пользователям просматри
вать содержимое вашего домашнего каталога или написать программу с флагом
setuid,
которая позволяет другим людям отправлять сигналы вашим процессам.
Избирательное управление доступом не обеспечивает особой гарантии безопасности
данных на пользовательском уровне. Поскольку пользователи имеют возможность уста
навливать разрешения самостоятельно; никто не знает, что они могут делать со своими
собственными файлами. Даже самые благонамеренные и обученные пользователи могут
ошибаться.
Системы мандатного управления доступом
(mandatory access control -
МАС) по
зволяют администраторам писать политики контроля доступа, которые переопределя
ют или дополняют избирательные разрешения традиционной модели. Например, вы
можете установить правило, что домашние каталоrи пользователей доступны только их
владельцам. Тогда не важно, что пользователь делает приватную копию конфиденциаль
ного документа и небрежно относится к разрешениям документа; в любом случае никто
ничего не может увидеть в домашнем каталоге этого пользователя.
Мандаты МАС
-
это эффективная технология для реализации моделей безопасно
сти, таких как система многоуровневой безопасности Министерства обороны. В этой
модели политики безопасности контролируют доступ в соответствии с воспринимаемой
секретностью контролируемых ресурсов. Пользователям назначается уровень безопас
ности из структурированной иерархии. Они могут читать и писать документы на том же
уровне секретности или ниже, но не могут получить доступ к документам с более высо
ким уровнем секретности. Например, пользователь с уровнем "секретно" может читать
и писать секретные документы, но не может читать документы, которые классифициру
ются как совершенно секретные.
Если вы не обрабатываете секретные данные для государственного органа, малове
роятно, что вы когда-нибудь столкнетесь или захотите развернуть такие всеобъемлющие
модели безопасности. Чаще всего система МАС используется для защиты отдельных
служб, в противном случае они остаются вне доступа пользователей.
Хорошо реализованная политика МАС основывается на принципе наименьших при
вилегий (разрешая доступ только тогда, когда это необходимо), поскольку правильно
спроектированный брандмауэр позволяет проходить только определенным признанным
службам и клиентам. Система МАС может помешать компрометации системы с уязви
мым программным обеспечением (например, на основе переполнения буфера), ограни
чив объем нарушения до нескольких конкретных ресурсов, требуемых этому программ
ному обеспечению.
К сожалению, система МАС стала чем-то вроде модного слова, синонимом "расши
ренного контроля доступа". Даже общий АРl-интерфейс безопасности
FreeBSD
назы
вается интерфейсом МАС, несмотря на то, что некоторые дополнения не предлагают
никаких реальных функций МАС.
Доступные системы МАС варьируются от глобальной замены стандартной модели
до облегченных расширений, которые предназначены для конкретных предметных об
ластей и сценариев использования. Общим для реализаций МАС является то, что они
обычно добавляют в систему контроля доступа централизованные, написанные адми
нистратором (или поставляемые поставщиком) политики, а также обычное сочетание
разрешений файлов, списков управления доступом и атрибутов процесса.
Глава
3. Управление доступом
и привилегии суперпользователя
123
Независимо от области действия, системы МАС представляют собой потенциально
значительное отклонение от стандартных систем, которое может оказаться неожидан
ным для проrрамм, основанных на стандартной модели безопасности
UNIX.
ПреЖде
чем перейти к полномасштабному развертыванию МАС, убедитесь, что вы понимаете
правила ведения журнала модуля и знаете, как идентифицировать и устранять пробле
мы, связанные с МАС.
Контроль доступа на основе ролей
Еще одна функция, которая обычно проверяется системами контроля доступа,
- это
RBAC), теоретическая модель,
(David Ferraiolo) и Риком Куном (Rick
контроль доступа на основе ролей (также известный как
формализованная в
Kuhn).
1992 r.
Дэвидом Феррариоло
Основная идея состоит в том, чтобы добавить слой косвенности в управление до
ступом к вычислениям.
Разрешения назначаются не пользователям непосредственно, а промежуточным кон
струкциям, называемым ролями, а роли, в свою очередь, назначаются пользователям.
Чтобы принять решение, связанное с управлением доступом, система перечисляет роли
текущеrо пользователя и проверяет, имеют ли какие-либо из этих ролей соответствую
щие разрешения.
Роли похожи на разные rруппы
UNIX,
но они носят более общий характер, посколь
ку моrут использоваться вне контекста файловой системы. Роли также моrут образовы
вать иерархии, что значительно упрощает администрирование. Например, вы можете
определить роль "старшеrо администратора", которая имеет все разрешения "админи
стратора" плюс дополнительные разрешения Х, У и
Мноrие версии
UNIX,
форму встроенной системы
ственноrо средства
RBAC.
Z.
Solaris, HP-UX и AIX, включают в себя некоторую
RBAC. Системы Linux и FreeBSD не имеют четкоrо, соб
включая
Однако она встроена в несколько более полных вариантов
системы МАС.
SELinux: улучшенная
SELinux
безопасность
Linux
является одной из старейших реализаций системы
Linux
МАС и является
продуктом Аrентства национальной безопасности США. В зависимости от точки зре
ния, этот факт может быть источником уверенности или подозрительности. 8
Система SELiпux использует максималистский подход и реализует почти все возмож
ности МАС и
RBAC,
которые можно себе представить. Несмотря на то что она внедрена
в нескольких дистрибутивах, ею, как правило, сложно упраалять и устранять неполадки.
Приведем анонимную цитату из старой версии страницы
Как ни странно, хотя заявленное предназначение SELiпиx заключается в том, чтобы
облегчить создание индивидуализированных политик управления доступом, специаль
но предназначенных для практики и правил хранения данных в организациях, ее про
грамм11ые инструменты настолько скудны и неудобны, что поставщики выживают
главным образом благодаря консалтингу, который обычно принимает форму дополни
тельных изменений в политике безопасности шаблонов.
8 Если
вы склонны к подозрениям, то стоит отметить. что в качестве части дистрибуrива ядра
кодовая база
SELinux открьrrа для
проверки.
Linux
124
Часть
1. Основы администрирования
Несмотря на сложность управления, внедрение системы
SELinux
медленно расши
раяется, особенно в таких средах, как правительственные органы, финансы и здравоох
ранение, которые имеют высокие и конкретные требования к безопасности. Она также
является стандартной частью платформы
Android.
SELinux
Наше общее мнение относительно системы
заключается в том, что она спо
собна принести больше вреда, чем пользы. К сожалению, этот вред может проявляться
не только как потерянное время и испорченное настроение системных администрато
ров, но и, как это ни парадоксально, в качестве недостатков в области безопасности.
Сложные модели трудно обсуждать, а
это не ровное игровое поле; хакеры,
SELinux -
которые специализируются на этой системе, понимают ее гораздо лучше, чем средний
системный администратор.
В частности, разработка политики
SELinux
является сложной задачей. Например,
для защиты нового демона политика должна тщательно перечислить все файлы, каталоги
и другие объекты, к которым процесс должен получить доступ. Для сложного программ
ного обеспечения, такого как
sendmail
или
httpd,
эта задача может быть довольно слож
ной. Например, одна компания предлагает треХдневный курс по разработке политики.
К счастью, многие общие политики доступны в режиме онлайн, и большинство дис
трибуrивов
SELinux
имеют разумные значения по умолчанию. Их можно легко устано
вить и настроить для конкретной среды. Полномасштабный редактор политики, целью
которого является облегчение применения политики, можно найти на сайте
seedi t.
sourceforge. net.
Система
RНЕL •
хорошо поддерживается системами
SELinux
Red Hat
(и, следова-
тельно, CentOS) и Fedora. Система Red Hat устанавливает ее по умолчанию.
~ Системы
Deblan
и
SUSE Linux также
имеют некоторую доступную поддерж-
~\_...,, ку SELinux, но вы должны установить дополнительные пакеты, а конфигу
рация по умолчанию является более слабой.
Система
Ubuntu
наследует некоторую поддержку
в последних версиях
SELinux от Deblan, но
AppArmor (см. далее).
к SELinux, по-прежнему
используется система
Ubuntu
Некоторые рудиментарные пакеты, относящиеся
доступны, но они, как правило, не обновляются.
Файл
SELinux.
/etc/selinux/config -
это элемент управления верхнего уровня для систем
В нем есть интересные строки:
SELINUX=enf orcing
SELINUXTYPE=targeted
Первая строка имеет три возможных значения:
disaЫed. Параметр
enforcing
и запрещает нарушения. Параметр ре rmi s
рует их в журнале
syslog,
SELINUXTYPE
или
s i ve
допускает нарушения, но регистри
что полезно для отладки и разработки политики. Параметр
disaЫed полностью отключает систему
Имя
enforcing, permissive
гарантирует, что загруженная политика применяется
SELinux.
представляет собой имя используемой базы данных политик. Это,
по суrи, имя подкаталог11 внуrри каталога
/etc/selinux.
В один и тот же момент вре
мени применяться может только одна политика, а доступные наборы политик зависят
от системы.
RHEL •
По умолчанию стратегия системы
Red Hat
задается параметром
targeted
и напраалена на обеспечение дополнительной безопасности нескольких демо-
нов, которые она явно защищает, предоставляя остальную часть системы самой
Глава
3. Управление
доступом и привилегии суперпользователя
125
себе. Раньше существовала отдельная политика, называемая
strict,
которая
применяла стратегию МАС ко всей системе, но эта политика была объединена
с политикой
targeted. Чтобы получить полную систему МАС, удалите модули
unconfinedus и unconfineduser с помощью команды semodule -d.
Система
вую зашиту
Red Hat также определяет политику mls, которая реализует многоуровне
DoD. Она устанавливается отдельно с помощью команды yum install
selinux-policy-mls.
Если вы заинтересованы в разработке собственных политик
мание на утилиту
audi t2allow.
SELinux,
обратите вни
Она создает определения политики из журналов нару
шений. Идея заключается в том, чтобы разрешить защиту подсистемы, регистрируя, но
не запрещая ее нарушения. Затем можно подключить подсистему и создать политику,
которая, по существу, позволяет этой подсистеме все. К сожалению, трудно гарантиро
вать полное покрытие всех путей кода с помощью такого подхода, поэтому автоматиче
ски созданные профили вряд ли будут идеальными.
AppArmor
ф
Система
AppArmor
является продуктом компании
пускающей дистрибутив
Ubuntu.
Canonical, Ltd., вы
Deblan
Она поддерживается системами
и Ubuntu, но также была принята в качестве стандарта дистрибутивами
SUSE. Системы Ubuntu и SUSE позволяют устанавливать ее по умолчанию,
хотя набор защищенных служб не является обширным.
Система
AppArmor
реализует стратегию МАС и предназначена в качестве дополне
ния к традиционной системе управления доступом
на любая конфигурация,
на пользователя. Ее
AppArmor
основная цель -
UNIX.
Несмотря на то что возмож
не предназначена для системы, ориентированной
обеспечение безопасности, т.е. ограничение ущер
ба, который могут нанести отдельные программы, если они будут скомпрометированы
или запущены.
Защищенные программы по-прежнему подвергаются всем ограничениям, налага
емым стандартной моделью, но, кроме того, ядро фильтрует их действия через назна
ченный и специфичный для приложения профиль
AppArmor отклоняет
AppArmor.
По умолчанию система
все запросы, поэтому профиль должен явно указывать все, что раз
решено для процесса.
Программы без профилей, таких как пользовательские оболочки, не имеют особых
ограничений и работают так, как если бы система
AppArmor
не была установлена.
Эта роль обеспечения безопасности службы, по сути, является той же конфигураци
ей, которая реализована системой
стема
AppArmor
SELinux
в целевой среде
Red Hat.
Тем не менее си
разработана специально для обеспечения безопасности, поэтому она
скрывает некоторые из самых загадочных нюансов
Профили
AppArmor
хранятся в файле
SELinux.
/ etc/ apparmor. d,
и относительно понят
ны даже без подробного знания системы. Например, вот профиль для демона
browsed,
входящего в систему печати в операционной системе
#include
/usr/sbin/cups-browsed (
#include
#include
Ubuntu:
cups-
126
Часть
1. Основы администрирования
#include
#include
#include
/etc/cups/cups-browsed.conf r,
/etc/cups/lpoptions r,
/{var/,}run/cups/certs/* r,
/var/cache/cups/* rw,
/tmp/** rw,
# Site-specific additions and overrides. See local/README.
#include
Большая часть этого кода является модульным шаблоном. Наnример, этот де
мон должен выполнять поиск имен хостов, поэтому nрофиль интерnолирует nуть
aьstractions/nameservice и предостамяет доступ к библиотекам разрешений имен,
файлам
лом
/etc/nsswitch.conf
LDAP и т.д.
и
/etc/hosts,
сетевым портам, используемым протоко
Информация профилирования, специфичная для этого демона, состоит (в данном
случае) из списка файлов, к которым может обращаться демон, а также разрешений
для каждого файла. Синтаксис сопостамения шаблонов немного отличается: символы
**могут соответствовать нескольким компонентам пути, а
ке
var /
{var/, 1 соответствует стро
в соответствующем месте пути.
Даже этот простой профиль устроен довольно сложно. Если раскрыть все инструк
ции
iinclude,
то профиль имеет длину около
750
строк. (А ведь мы выбрали этот nри
мер ради его краткости. Увы!)
Система AppArmoг ссылается на файлы и программы
no
имени пути, что дела
ет профили удобочитаемыми и независимыми от какой-либо конкретной реализации
файловой системы. Однако этот подход ямяется компромиссным. Например, система
AppArmor не
распознает жесткие ссылки, указывающие на один и тот же объект.
3.5. ЛИТЕРАТУРА
• FERRAJOLo, Dлvю F., D. R1cнлRD KuнN, дND Rлмлswлмv CндNDRAMOULI. Role-Based
Access Control (2nd Edition). Вoston, МА: Artech House, 2007.
• HлrNEs, RrcнлRD. The SELinux Notebook (4th Edition). 2014. Сборник информации,
относящейся к системе SELinux, наиболее близкий к официальной документации.
Доступен для загрузки на сайте freecomputerbooks. сот.
• VERMEULEN, SvEN. SELinux Cookbook. Birmingham, UK: Packt PuЬlishing, 2014. Книга,
содержащая самые разнообразные советы по работе с системой SELinux. В ней
описаны модели обеспечения безопасности как служб, так и пользователей.
Глава 4
Управление процессами
Процесс представляет собой выполняемую проrрамму. Это абстракция, с помощью ко
торой можно управлять памятью, временем работы процессора и ресурсами ввода-вывода.
Это аксиома философии
UNIX,
позволяющая как можно больше работать в кон
тексте процессов, а не ядра. Системные и пользовательские процессы соответствуют
одним и тем же правилам, поэтому вы можете использовать один набор инструментов
для управления ими.
4.1.
КОМПОНЕНТЫ ПРОЦЕССА
Процесс состоит из адресного пространства и набора структур данных внутри ядра.
Адресное пространство представляет собой набор страниц памяти, которые ядро выде
лило для использования процессу. 1 Эти страницы содержат код и библиотеки, которые
выполняются процессом, переменные процесса,
ero
стеки и различную дополнитель
ную информацию, необходимую ядру во время выполнения. Виртуальное адресное про
странство процесса вьщеляется в физической памяти случайным образом и отслежива
ется таблицами страниц ядра.
В структурах данных ядра хранится всевозможная информация о каждом процессе.
К наиболее важным относятся следующие сведения:
текущее состояние процесса (неактивен, приостановлен, выполняется и т.п.);
1 Страницы
-
это базовые блоки памяти, размер которых состамяет от 1до8 Кбайт.
Часть
128
•
1. Основы
администрирования
информация о ресурсах, используемых процессом (центральный процессор, память и т.д.);
•
•
•
информация о файлах и сетевых портах, открытых процессом;
маска сигналов (запись о том, какие сигналы блокируются);
имя владельца процесса.
Поток
-
это контекст выполнения процесса. Каждый процесс имеет как минимум
один поток, но некоторые процессы могут иметь несколько потоков. Каждый поток,
действуя в адресном пространстве внешнего процесса, имеет свой собственный стек
и регистры центрального процессора
В современных компьютерных системах используются несколько центральных про
цессоров и несколько ядер внутри каждого центрального процессора. Такие многопо
точные приложения, как
BIND
и
Apache,
извлекают максимальную пользу из муль
тиядерных систем благодаря тому, что эти приложения могут отрабатывать несколько
запросов одновременно.
Многие характеристики процесса непосредственно влияют на его выполнение.
В частности, имеет значение, сколько времени выделяется ему центральным процес
сором, к каким файлам он имеет доступ и т.д. В следующих подразделах рассмотрим
наиболее интересные с точки зрения системного администратора характеристики про
цессов. Они поддерживаются во всех версиях систем
Идентификатор процесса
UN 1Х и Linux.
PID
Ядро назначает каждому процессу уникальный идентификатор. Большинство команд
и системных вызовов, работающих с процессами, требует указания конкретного иден
тификатора, чтобы был ясен контекст операции. Идентификаторы
PID
присваиваются
по порядку по мере создания процессов.
В настоящее время система
Linux использует концепцию
пространства имен
процесса, которая еще больше ограничивает способность процессов видеть
друг друга и влиять друг на друга. Контейнерные реализации используют эту
функцию для разделения процессов. Один из побочных эффектов заклю
чается в том, что процесс может иметь разные
PID
в зависимости от про
странства имен наблюдателя. Это похоже на эйнштейновскую относитель
ность для идентификаторов процессов. Для получения дополнительной
информации см. главу
25.
Идентификатор родительского процесса
Ни в
UNIX,
ни в
Linux нет системного
PPID
вызова, который бы инициировал новый про
цесс для выполнения конкретной программы. Для того чтобы породить новый процесс,
существующий процесс должен клонировать сам себя. Клон может заменить выполняе
мую программу другой.
В операции клонирования исходный процесс называют родительским, а его клон
-
дочерним. Помимо собственного идентификатора, каждый дочерний процесс имеет
атрибут
PPID (Parent Process ID),
который совпадает с идентификатором породившего
его родительского процесса 2 •
2 По
крайней мере первоначально. Если родительский процесс по какой-то причине завершается
раньше потомка, демон
init или sytemd (процесс
4.2).
(подробности описаны в разделе
с номером
1)
подставляет себя на место предка
Глава
4. Управление процессами
129
Идентификатор родительского процесса
-
весьма полезная информация, если при
ходится иметь дело с неизвестным (и, возможно, нестандартно ведущим себя) процес
сом. Отслеживание истоков процесса может облегчить понимание его назначения и зна
чимости.
W Дополнительную информацию об идентификаторах UID см. в разделе 8.2.
Идентификатор пользователя
пользователя EUID
UID
(Useг
UID и текущий
идентификатор
это идентификатор пользователя, создавшего данный процесс,
ID) -
точнее, копия значения
UID
родительского процесса. Менять атрибуты процесса могут
только его создатель (владелец) и суперпользователь.
m
Дополнительную информацию об установке флага
EUID (Effective User ID) -
setuid см
в разделе
3.1.
это текущий пользовательский идентификатор процесса,
предназначенный для того, чтобы определить, к каким ресурсам и файлам у процесса
есть право доступа в данный момент. У большинства процессов значения
UID
и
EUID
одинаковы. Исключение составляют программы, у которых установлен бит смены иден
тификатора пользователя
(setuid).
Зачем нужны идентификаторы
UID
и
EUID'?
Просто чтобы разграничить понятия
идентификации и прав доступа. К тому же программы с установленным битом
setuid
не всегда выполняются с расширенными привилегиями. В большинстве систем значе
ние
EUID
можно устанавливать, чтобы предоставлять процессу дополнительные полно
мочия, и сбрасывать, чтобы отбирать их.
В большинстве систем хранится начальный идентификатор, т.е. копия значения
EUID,
которое имел процесс в начальной точке. Если процесс не удалит сохраненный
идентификатор, его можно будет использовать в качестве реального или текущего иден
тификатора. Благодаря этому "консервативно" написанная программа с установленным
битом
setuid
может большую часть времени работать с обычными привилегиями, пере
ходя в режим расширенных привилегий лишь в определенные моменты.
А
В системе
М
Linux есть еще
и нестандартный параметр
редко и не переносится на другие системы
Идентификатор группы
идентификатор группы
m
FSUID,
определяющий
возможности работы с файловой системой, но вне ядра он используется
UNIX.
(GID) и текущий
(EGID)
Дополнительную информацию о группах см. в разделе
GID (Group ID) -
8.2.
это идентификатор группы, к которой принадлежит владелец
процесса. Идентификатор
EGID
связан с атрибутом
GID
так же, как с атрибутом
т.е. они будут отличаться, если программа запускается с установленным битом
В ядре назначение сохраненного
храненного атрибута
GID для
UID,
setgid.
каждого процесса аналогично назначению со
UID.
В значительной степени атрибут
GID
процесса является рудиментарным. С точки
зрения определения прав доступа процесс одновременно может относиться к несколь
ким группам. Список групп хранится отдельно от значений
GID
и
EGID.
При анализе
прав доступа проверяется текущий идентификатор и дополнительный список групп, но
не значение
GID.
Часть
130
Единственная ситуация, в которой атрибут
GID
1.
Основы администрирования
имеет реальное значение,
-
созда
ние процессом новых файлов. В зависимости от установленных прав доступа в данной
файловой системе новые файлы могут принимать атрибут
Подробнее эти вопросы рассмотрены в разделе
G 1D создающего
их процесса.
5.5.
Фактор уступчивости
Приоритет процесса определяет, какую долю времени центрального процессора по
лучает программа. Ядро применяет динамический алгоритм вычисления приоритетов,
учитывающий, сколько времени центрального процессора уже использовал процесс
и сколько времени он ожидает своей очереди. Кроме того, учитывается заданный адми
нистратором так называемый фактор уступчивости, который определяет, в какой сте
пени программа может "делиться" процессором с другими пользователями. Подробнее
этот механизм рассматривается в разделе
4.4.
Управляющий терминал
m
Дополнительную информацию о стандартных каналах связи см в разделе 7.2.
С большинством процессов, не являющихся демонами, связан управляющий терми
нал, который определяет базовую конфигурацию стандартных каналов ввода, вывода
и ошибок. От управляющего терминала зависит также распределение сигналов в ответ
на события клавиатуры, например нажатие клавиш
деле
,
о чем пойдет речь в раз
4.2.
4.2. Жизненный
цикл ПРОЦЕССА
Для создания нового процесса существующий процесс, как правило, клонирует сам
себя с помощью системного вызова fork. 3 В результате формируется копия исходного
процесса, имеющая лишь некоторые отличия. В частности, новому процессу присваи
вается собственный идентификатор
PID,
и учет ресурсов ведется для него независимо
от предка.
Системный вызов
fork имеет уникальное свойство: он возвращает два разных зна
чения. В дочернем процессе это число О, а в родительском
-
идентификатор
PID
про
цесса-потомка. Поскольку в остальном процессы идентичны, они должны проверять
результат вызова, чтобы определить, какую роль следует играть в дальнейшем.
После завершения системного вызова
fork дочерний процесс обычно запускает но
вую программу с помощью одного из системных вызовов семейства ехес. Все вызовы
этого семейства заменяют программу, выполняемую процессом, и устанавливают сег
менты памяти в исходное состояние. Формы вызовов ехес различаются только спосо
бами указания аргументов командной строки и переменных среды, передаваемых новой
программе.
При загрузке системы ядро самостоятельно запускает несколько процессов.
Наиболее важный из них
ным
1.
-
демон
ini t
или
systemd
с номером процесса, всегда рав
Эти процессы отвечают за выполнение сценариев запуска системы, хотя харак-
'Технически в системах
Linux используется системный вызов clone, расширение системного
fork, которое обрабатывает потоки и включает дополнительные функции. Системный
вызов fork остается в ядре для обеспечения обратной совместимости, но на самом деле он
выполняет системный вызов clone.
вызова
Глава
4. Управление процессами
тер их действий в
UNIX
и
Linux
131
различается. Все процессы, кроме тех, что создаются
ядром, являются потомками этих процессов. Дополнительная информация о загрузке
и демоне
ini t содержится в главе 2.
ini t (или systemd) играет
Демон
и другую важную роль в управлении процесса
ми. Завершающийся процесс вызывает функцию_exi t, чтобы уведомить ядро о своей
готовности прекратить работу. В качестве параметра функции_exi t передается код за
вершения
-
целое число, обозначающее причину прекращения процесса. По общепри
нятому соглашению, нуль свидетельствует об успешном завершении процесса.
Ядро системы требует, чтобы, прежде чем процесс окончательно исчезнет, его удале
ние было подтверждено родительским процессом с помощью системного вызова
wai t.
Этот вызов возвращает код завершения потомка (или сообщает о причине его уничто
жения, если завершение не было естественным) и в случае необходимости статистику
использования ресурсов.
Описанный механизм работает нормально, если родительский процесс завершается
позже порожденных им процессов и выполняет системные вызовы
wai t
для их унич
тожения. Если же родительский процесс завершается раньше срока, то ядро распозна
ет, что вызова
init
(или
wait не последует, и переназначает все "осиротевшие" процессы демону
systemd). Он берет их под свой контроль, осуществляя для каждого из них
вызовwаit.
Сигналы
Сигналы
-
это запросы на прерывание, реализуемые на уровне процессов.
Существуют свыше тридцати различных сигналов, и они находят самое разное приме
нение.
•
•
Сигналы могут посылаться между процессами как средство коммуникации.
Сигналы могут посылаться драйвером терминала для уничтожения или приоста
новки процессов, когда пользователь нажимает специальные комбинации клавиш,
такие как
•
или
4•
Сигналы могут посылаться в самых разных целях пользователем или администра
тором с помощью команды
•
kill.
Сигналы могут посылаться ядром, когда процесс выполняет недопустимую ин
струкцию, например деление на нуль.
•
Сигналы могут посылаться ядром для уведомления процесса о "представляющем
интерес" событии, таком как прекращение дочернего процесса или доступность
данных в канале ввода-вывода.
W
Дамп памяти
-
это файл, содержащий образ памяти процесса. Его можно использовать
для отладки.
Когда поступает сигнал, возможен один из двух вариантов развития событий. Если
процесс назначил сигналу подпрограмму обработки, то после вызова ей предоставляется
информация о контексте, в котором был сгенерирован сигнал. В противном случае ядро
выполняет от имени процесса действия, заданные по умолчанию. Эти действия зависят
от сигнала. Многие сигналы приводят к завершению процесса, а в некоторых случаях
при этом еще и создаются дампы памяти.
4 Функции,
связанные с комбинациями клавиш или , мо~уг назначаться другим
stty, но на практике такое встречается очень редко. В этой главе
клавишам с помощью команды
мы подразумеваем, что с данными клавишами связаны их стандартные функции.
Часть
132
1. Основы
администрирования
Процедура вызова обработчика называется перехватом сигнала. Когда выполнение
обработчика завершается, процесс возобновляется с той точки, где был получен сигнал.
Для того чтобы определенные сигналы не поступали в программу, нужно задать их
игнорирование или блокирование. Игнорируемый сигнал просто пропускается и не вли
яет на работу процесса. Блокируемый сигнал ставится в очередь на обработку, но ядро не
требует от процесса никаких действий до явного разблокирования сигнала. Обработчик
вызывается DJIЯ разблокированного сигнала только один раз, даже если в течение перио
да блокировки поступило несколько аналогичных сигналов.
В табл.
4.1
перечислены сигналы, которые должны быть известны любому системно
му администратору. Традиционно имена сигналов записываются прописными буквами.
Иногда к именам добавляется префикс SIG (например, SIGHUP).
Табпица
4.1.
№' Имя
1
2
з
HUP
INT
QUIT
Сиrнапы, которые допжен знать каждый администратор•
Описание
Реакция
ПО yмD.llЧ8HMIO
ПереХ88ТЫвеется?
&покируетсt1?
Дамn
памяти?
Нет
Отбой
Завершение
~
~
Прерывание
Завершение
~
~
Нет
Выход
Завершение
~
~
~
9 KILL
10 BUS
11 SEGV
15 ТЕRМ
Уничтожение
Завершение
Нет
Нет
Нет
Ошибка на шине
Завершение
~
~
~
Ошибкасегментации
Завершение
~
~
~
Запрос на завершение
Завершение
~
~
Нет
STOP
18 TSTP
Остановка
Остановка
Нет
Нет
Нет
Сигнал остановки, посылаемый с клавиатуры
Остановка
~
~
Нет
Продолжение после оста-
Игнорируется
~
Нет
Нет
Изменение окна
Игнорируется
~
~
Нет
Определяется пользова-
Завершение
~
~
Нет
Завершение
~
~
Нет
17
19 CONT
новки
28 WINCH
30 USRl
тел ем
31 USR2
Определяется пользователем
"Список названий сигналов и номеров также можно получить с помощью встроенной в оболочку bash команды
kill -1.
"Зависит от используемой системы. Подробнее см. файл /usr/ include/ signal. h или тап-страницы интерактивного руководства для системного вызова
s i gna 1 ( ) .
Существуют и другие сигналы, не показанные в табл.
4.1;
большинство из них со
общает о загадочных ошибках, например "неверная инструкция". По умолчанию та
кие сигналы, как правило, приводят к завершению программы и созданию дампа ядра.
Перехват и блокирование сигналов обычно разрешены, так как есть достаточно "ум
ные" программы, устраняющие последствия ошибок.
Сигналы вus и SEGV также посылаются при возникновении ошибок. Мы включили
их в таблицу, поскольку они чрезвычайно распространены: обычно программа аварийно
завершается именно из-за них. Сами по себе эти сигналы не имеют диагностической
ценности. Они лишь указывают на факт неправильного обращения к памяти.
Сигналы KILL и STOP нельзя ни перехватить, ни заблокировать, ни проигнориро
вать. Сигнал KILL приводит к уничтожению процесса, которому он посылается, а сиг-
глава
4. Управление
процессами
133
нал STOP приостанавливает выполнение процесса до получения сигнала CONT. Сигнал
CONT можно перехватить и проигнорировать, но нельзя заблокировать.
Сигнал TSTP представляет собой более "гибкую" версию сигнала STOP. Проще всего
описать его как запрос на остановку. Он генерируется драйвером терминала при нажа
тии пользователем комбинации клавиш
.
Программы, перехватывающие этот
сигнал, обычно выполняют операции очистки, а затем посылают сами себе сигнал STOP.
С другой стороны, программы могут игнорировать сигнал TSTP, чтобы их нельзя было
остановить командой с клавиатуры.
Хотя назначение сигналов
KILL, INТ, TERM, HUP и QUIT может показаться одинако
вым, в действительности они совершенно разные.
•
Сигнал
KILL не блокируется и приводит к безусловному завершению процесса
на уровне ядра. По сути, процесс не успевает даже принять этот сигнал.
Перехватив этот сигнал, простые программы должны завершить работу или позво
лить уничтожить себя стандартному обработчику сигнала. Программы, в которых
есть интерактивный режим командной строки, должны прекратить текущую опе
рацию, выполнить очистку и снова перейти в режим ожидания.
•
Сигнал ТЕRМ представляет собой запрос на завершение программы. Предполагается,
что процесс, получивший этот сигнал, осуществляет очистку и завершается.
•
У сигнала HUP есть две распространенные интерпретации. Во-первых, многие де
моны воспринимают его как команду сброса. Если демон способен повторно про
честь свой конфигурационный файл и адаптироваться к изменениям без переза
пуска, сигнал
•
HUP
позволяет менять его поведение.
Во-вторых, этот сигнал иногда генерируется драйвером терминала при попытке
уничтожить связанные с терминалом процессы. В основном это поведение сохра
нилось со времен использования проводных соединений терминалов и модемов.
Отсюда и название "отбой".
•
Оболочки семейства С (tcsh и другие) обычно делают фоновые процессы невос
приимчивыми к сигналу
HUP, чтобы они могли продолжать свою работу, даже когда
пользователь выходит из системы. Пользователи оболочек семейства
bash и так далее)
•
Сигнал
Bourne (ksh,
nohup.
могут эмулировать такое поведение с помощью команды
QUIT напоминает сигнал TERM, за исключением того, что по умолчанию
стандартный обработчик создает дамп памяти.
Сигналы USRl и USR2 не имеют стандартного назначения. Ими можно пользоваться
в различных целях. Например, веб-сервер
Apache
на немедленный перезапуск. Сигнал USRl
интерпретирует сигнал нuв как запрос
инициирует более плавный переход, в ходе
которого разрешается закончить сеансы связи существующего клиента.
Команда
kill: отправка сигналов
Команду kill чаще всего используют для уничтожения процессов. Эта команда мо
жет послать процессу любой сигнал, но по умолчанию это сигнал TERM. Команду kill
могут выполнять как рядовые пользователи (для своих собственных процессов), так
и суперпользователь (для любого процесса). Она имеет следующий синтаксис:
kill
[-сигнал]
pid
Часть
134
где сигнал
а
pid -
1. Основы администрирования
это номер или символическое имя посылаемого сигнала (см. табл.
-
4.1),
идентификационный номер целевого процесса.
Команда
kill без номера сигнала не гарантирует, что процесс будет уничтожен,
TERM можно перехватывать, блокировать и игнорировать. Команда
по
скольку сигнал
$ kill -9 pid
"гарантированно" уничтожает процесс, так как сигнал с номером
вается. Используйте команду
kill -9
9 (KILL)
не перехваты
только в случае, если "вежливый" запрос на за
вершение программы не был выполнен. Мы написали слово "гарантированно" в кавыч
ках, так как иногда процессы переходят в такое состояние, в котором их нельзя завершить
даже таким способом (обычно это связано с блокировкой ввода-вывода, например при
остановке жесткого диска). Единственный выход в такой ситуации
Команда
killall
-
перезагрузка.
уничтожает процессы, заданные именем. Например, следующая
команда уничтожает все процессы веб-сервера
Apache.
$ sudo killall httpd
Команда
pkill
осуществляет поиск процессов, заданных именами (или другими
атрибутами, например
EUID),
и посылает найденным процессам сигнал. Например,
следующая команда посылает сигнал
TERM
всем процессам, выполняемым от имени
ben.
$ sudo pkill -u Ьеn
пользователя
Состояния процессов и потоков
Как показано в предыдущем разделе, процесс может быть приостановлен сигналом
STOP
и возвращен в активную нагрузку с сигналом
CONT.
Состояние приостановления или
выполнения применяется к процессу в целом и наследуется всеми потоками процесса. 5
Даже при номинальнqм запуске потоки часто должны ждать, пока ядро завершит
какую-то фоновую работу дпя них, прежде чем они смогут продолжить выполнение.
Например, когда поток считывает данные из файла, ядро должно запрашивать соответ
ствующие блоки диска, а затем упорядочивать их содержимое для доставки в адресное
пространство процесса запроса. В течение этого времени запрашивающий поток входит
в состояние краткосрочного спящего режима, в котором он не может быть выполнен.
Однако другие потоки в одном процессе могут продолжать работать.
Существуют процессы, которые называют "спящими" (например, в выводе резуль
татов работы команды
ps -
см. следующий раздел). Поскольку атрибут сна относится
к потоку, этот термин немного обманчив. Обычно процесс считается спящим, когда все
его потоки являются спящими. Разумеется, различие остается спорным в случае одно
поточных процессов, которые представляют собой наиболее распространенный случай.
Интерактивные оболочки и системные демоны проводят большую часть времени,
ожидая ввода данных с терминала или сетевых подключений. Поскольку спящий поток
эффективно блокируется до тех пор, пока его запрос не будет удовлетворен, его процесс
обычно не получает никакого процессорного времени, если он не получает сигнал или
ответ на один из своих запросов ввода-вывода.
W
Дополнительную информацию об инсталляции файловой системы NFS с параметром
hard см. в разделе 21.4.
5 Аналоrичным
образом можно управлять отдельными потоками. Однако эти объекты в первую
очередь представляют интерес для разработчиков; системные администраторы не должны
беспокоиться по этому поводу.
Глава
4. Управление
процессами
135
Некоторые операции могут привести к тому, что процессы или потоки войдут в со
стояние беспробудного сна. Это состояние обычно является переходным и не наблю
дается в результате работы команды
см. табл.
4.2).
ps
(оно обозначается буквой D в столбце STAT,
Однако несколько специфических ситуаций могут привести к тому, что
это состояние станет постоянным. Наиболее распространенная причина связана с про
блемами сервера в файловой системе
NFS,
инсталлированной с параметром
hard.
Поскольку процессы в состоянии беспробудного сна не могут просыпаться даже для об
служивания сигнала, они не могут быть прекращены. Чтобы избавиться от них, вы
должны устранить основную проблему или перезагрузить компьютер.
4.3.
КОМАНДА
Команда
ps -
Ps: ТЕКУЩИЙ КОНТРОЛЬ ПРОЦЕССОВ
основной инструмент, которым системный администратор пользует
ся для текущего контроля процессов. Версии этой команды различаются аргументами
и выходным форматом, но, по сути, выдают одну и ту же информацию. В основном,
различие в версиях
это следствие разных путей развития систем
-
UN IX.
Кроме того,
поставщики систем могут настраивать эту команду с учетом конфигурации системы, так
как она тесно связана с особенностями обработки процессов в ядре и поэтому часто от
ражает изменения в ядре.
С помощью команды
UID,
ps
можно получить информацию об идентификаторах
PID,
приоритете и управляющем терминале того или иного процесса. Она также по
зволяет выяснить, какой объем памяти использует процесс, сколько времени централь
ного процессора заняло его выполнение, каково его текущее состояние (выполняется,
остановлен, простаивает и т.д.). Процессы-зомби в листинге команды обозначаются как
или
Команда
ps
.
безнадежно усложнилась за последние несколько лет. Некоторые по
ставщики оставили попытки стандартизировать выходной формат этой команды и сде
лали ее полностью конфигурируемой. Проведя небольшую настройку, можно получить
практически любые требуемые результаты.
В системе
Linux
команда
ps
является настоящим хамелеоном и понимает
наборы опций из ряда других систем. В отличие от остальных команд си
стемы
UNIX,
команда
ps
в системе
Linux
воспринимает флаги командной
строка как с дефисом, так и без дефиса, хотя их интерпретация может ока
заться разной. Например, результат выполнения команды
от результата выполнения команды
ps
ps
-а отличается
а.
Не пугайтесь всех этих сложностей: пусть они будут кошмаром разработчиков ядра,
а не системных администраторов! Дпя повседневной работы достаточно знать лишь не
сколько наиболее важных опций команды
ps.
Получить список всех процессов, выполняющихся в системах, можно с помощью
команды
ps aux.
Ключ а означает, что мы хотим увидеть все процессы, ключ х
-
что
мы хотим увидеть даже процессы, отсоединенные от управляющего терминала, а ключ
u
обеспечивает фильтрование по имени или идентификатору пользователя, который запу
стил программу. Ниже показаны результаты работы команды
redhat$ ps aux
USER PID %CPU
root
1
0.1
root
2
о
root
о
3
%МЕМ
vsz
0.2
3356
RSS
560
о
о
о
о
о
о
ТТУ
?
?
?
SТАТ
s
SN
S<
ps aux
в системе
TIME СОММАND
0:00 init [5]
0:00 [ksoftirqd/0]
0:00 [events/0]
по изменению направления передаваемых командой данных в файл или принимаемых
Часть
224
"" и">>" перенаправляют поток STDOUT; причем символ
">"используется для замены содержимого файла, а">>"
-
для добавления данных в его
конец. Например, команда
$ qrep bash /etc/passwd > /tmp/bash-users
копирует строки, содержащие слово
users
"bash"
из файла
/etc/passwd
в файл
/tmp/bash-
(при необходимости файл будет создан). Следующая команда упорядочивает со
держимое этого файла и выводит результат на терминал.
$ sort < /tmp/bash-users 7
root:x:O:O:root:/root:/bin/bash
Для того чтобы перенаправить потоки STDOUT и STDERR в одно и то же место, ис
пользуйте символ">&". Для того чтобы перенаправить только поток STDERR, исполь
зуйте вариант
"2>".
На примере команды
find
можно показать, почему важно обрабатывать потоки
STDOUТ и SТDERR отдельно. Дело в том, что она формирует выходные данные по обо
им каналам, особенно в случае ее выполнения непривилегированным пользователем.
Например, при выполнении команды
$ find / -name core
обычно генерируется так много сообщений об ошибках
"permission denied"
(отсутствие
прав доступа), что настоящие результаты поиска теряются в "шуме". Чтобы отбросить
все сообщения об ошибках, можно использовать такой вариант.
$ find / -name core 2> /dev/null
В этой версии команды
find
только настоящие совпадения (где пользователь имеет
разрешение на чтение родительского каталога) выводятся в окно терминала. Чтобы со
хранить список совпадающих путей в файле, выполните такую команду.
> /tmp/corefiles 2> /dev/null
$ find / -name core
Эта командная строка отправляет совпадающие пути в файл
/tmp/corefiles,
от
брасывая все ошибки и ничего не посылая в окно терминала.
Для того чтобы связать канал STDOUT одной команды с каналом STDIN другой, ис
пользуйте символ
" 1".
Рассмотрим несколько примеров.
$ find / -name core 2> /dev/null 1 less
Первая команда выполняет операцию
find
из предыдущего примера,
список найденных файлов не в файл, а в программу постраничного вывода
но посылает
less.
$ ps -ef 1 qrep httpd
Здесь команда
ps
генерирует список процессов, из которого команда
строки, содержащие слово
httpd.
Результат выполнения команды
grep
grep
выбирает
никуда больше
не перенаправляется, поэтому совпадающие строки попадают в окно терминала.
$ cut -d: -f7 < /etc/passwd 1 sort -u
Здесь команда
cut
выбирает из файла
/etc/passwd
пути к оболочке каждого поль
зователя. Список оболочек затем отправляется через команду
sort -u,
чтобы сформи
ровать отсортированный список уникальных значений.
Для того чтобы последующая команда выполнялась только в случае успешного вы
полнения предыдущей, можно разделить эти команды символом"&&". Например, ко
мандная строка
$ lllkdir foo && cd foo
7 По
правде говоря, команда
sort
может работать с файлами напрямую, поэтому символ
контексте является необязательным. Он используется здесь для иллюстрации.
<
в этом
Глава
7. Сценарии
и командная оболочка
пытается создать каталог с именем
случае успех выполнения команды
225
foo и в случае успеха выполняет команду cd. В данном
mkdir будет зафиксирован при получении кода завер
шения, равного нулю. Использование для этой цели символа, означающего операцию "ло
гическое И", может сбить с толку тех, кто в других языках программирования использовал
вычисления в сокращенной форме записи. Если кому-то это непонятно, не стоит слишком
долго здесь застревать; а просто примите это как идиому командной оболочки.
И наоборот, символ
"1 1"
обеспечит выполнение следующей команды только в том
случае, если предыдущая команда не выполнится (т.е. сгенерирует ненулевое значение
кода завершения).
$ cd foo 1 1 echo "No such directory"
Для того чтобы разбить команду на несколько строк, для наглядности отделяя тем
самым код обработки ошибок от остальной части командного конвейера, можно ис
пользовать в сценариях обратную косую черту.
--preserve --recursive /etc/* /spare/backup \
1 1 echo "Did NOT make backup"
ер
Для получения обратного эффекта, т.е. объединения нескольких команд в одной
строке, можно использовать в качестве разделителя точку с запятой.
$ mkdir foo; cd foo; touch afile
Использование переменных и кавычек
В операциях присваивания имена переменных никак не выделяются, но предваряются
знаком доллара при ссылке на их значения.
$ etcdir=' / etc'
$ echo $etcdir
/etc
Не ставьте до и после знака равенства ( =) пробелы, в противном случае оболочка
ошибочно примет имя вашей переменной за имя команды.
При ссьшке на переменную можно заключить ее имя в фигурные скобки, чтобы син
таксический анализатор (да и сам человек) не сомневался в том, где заканчивается имя
переменной и начинается другой текст; например, используйте запись$ {etcdir) вме
сто
$etcdir.
Обычно без фигурных скобок можно обойтись, но они могут оказаться по
лезными в случае, если вам понадобится раскрывать переменные в строках с двойными
кавычками. Часто нужно сделать так, чтобы после значения переменной стояли буквы
или знаки препинания. Например,
$ echo "Saved ${rev}th version of mdadm.conf."
Saved Bth version of mdadm.conf.
Для имен переменных командной оболочки не существует стандартного соглашения,
но обычно предполагается, что имена, полностью написанные прописными буквами,
принадлежат переменным среды или переменным, считанным из файлов глобальной
конфигурации. И чаще всего все буквы в именах локальных переменных - строчные,
а отдельные их компоненты разделяются символами подчеркивания. Вообще имена пе
ременных чувствительны к регистру букв.
Командная оболочка интерпретирует строки, заключенные в одинарные и двойные
кавычки, почти одинаково. Различие состоит в том, что строки в двойных кавычках
служат субъектами для универсализации файловых имен (замены реальных символов
в имени и расширении файла универсальными, т.е. такими метасимволами, как "*"
и"?") и для раскрытия переменных (замены переменных их значениями). Например,
Частьl.Основыадминистрирования
226
$ mylang="Pennsylvania Dutch"
$ echo "I speak ${mylang}."
I speak Pennsylvania Dutch.
$ echo 'I speak ${mylang}.'
I speak $(mylang).
Обратные апострофы (также известные как обратные галочки, левые кавычки, ле
вые одиночные кавычки или открывающие кавычки) интерпретируются аналогично
двойным кавычкам, но несут при этом дополнительную нагрузку. Эта нагрузка состоит
в интерпретации содержимого такой строки, как команды оболочки, выполнении этой
команды и замене строки результатом выполнения этой команды.
"Тhere are 'wc -1 < /etc/passwd" lines in the passwd file."
There are 28 lines in the passwd file.
$ echo
Переменные окружения
При запуске процесса
UNIX
он получает список аргументов командной строки,
а также набор переменных окружения. Большинство оболочек показывают вам текущее
окружение в ответ на команду
printenv:
$ printenv
EDITOR = VI
USER = garth
EN\' = / gome / garth/. bashrc
LSCOLORS = exfxgxgxdxgxgxbxbxcxcx
PWD = /mega/Documents/Projects/Code/spl
HOl'IE = /home/garth
...
По соглашению имена переменных окружения набираются прописными буквами, но
формально это не требуется.
Программы, которые вы запускаете, могут обращаться к этим переменным и соответ
ствующим образом изменять их поведение. Например, программа
vipw проверяет перемен
ную среды EDITOR, чтобы определить, какой текстовый редактор будет работать для вас.
Переменные окружения автоматически импортируются в пространство имен пере
менных
sh,
поэтому их можно установить и прочитать с помощью стандартного син
таксиса. Чтобы превратить переменную оболочки в переменную среды, используйте ко
манду
export
имя_ переменной. Вы также можете комбинировать этот синтаксис со
значением присваивания, как показано здесь:
$ export EDITOR = nano
$ vipw
Несмотря на то что они называются переменными окружения, эти значения не су
ществуют в каком-то абстрактном месте вне пространства и времени. Оболочка пере
дает снимок текущих значений в любую запущенную вами программу, но при этом нет
никаких открытых соединений. Более того, каждая оболочка или программа и каждое
окно терминала имеют свою собственную отдельную копию окружения, которая может
быть изменена отдельно.
Команды для переменных окружения, которые вы хотите настроить во время вхо
да в систему, должны быть включены в ваш файл~/
Другие переменные среды, такие как
ски поддерживаются оболочкой.
PWD
.profile
или~/
.bash_profile.
для текущего рабочего каталога, автоматиче
Глава
7. Сценарии
и командная оболочка
227
Команды фильтрации
Любая корректная команда, которая считывает данные из канала STDIN и записы
вает данные в канал STDOUТ, может использоваться в качестве фильтра (т.е. компонента
конвейера) для обработки данных. В этом разделе мы кратко рассмотрим некоторые из
наиболее широко используемых команд фильтра, но список практически бесконечен.
Команды фильтрации отличаются настолько сильным "коллективизмом'', что порой
даже трудно продемонстрировать их индивидуальное использование.
Большинство команд фильтра принимают одно или несколько имен файлов в ко
мандной строке. Только если вы не укажете файл, они прочитают данные из стандарт
ного входного потока.
Команда
cut: разбивка строк на поля
Команда
cut
выводит выбранные части входных строк. Она чаще всего выделяет
поля с разделителями, как в примере, показанном ниже, но также может возвращать
сегменты, определяемые границами столбцов. Разделителем по умолчанию служит
символ , но вы можете изменить разделители с помощью опции
-d. Параметр -f
определяет, какие поля включать в вывод.
Пример использования команды
де
cut приведен
ниже в разделе, посвященном коман
uniq.
Команда
sort: сортировка строк
Команда
sort сортирует входные строки.
Звучит просто, да? Хотя на самом деле не все
так безоблачно: существуют потенциальные нюансы, связанные с точно заданными частя
ми сортируемых строк (т.е. с использованием сортировочного ключа) и порядком сортиров
ки. Наиболее распространенные варианты применения этой команды показаны в табл.
7.2,
в отношении же остальных случаев обратитесь к соответствующей тап-странице.
Таблица
7 .2.
Ключи команды
sort
Ключ команды
Значение
-ь
Игнорировать ведущие пробельные символы
-f
Сортировать независимо от регистра букв
-h
Сортировать "читабельные" числа (например, 2Мб)
-k
Указывать столбцы, которые формируют сортировочный ключ
-n
Сравнивать полR как целые числа
-r
Изменить порRдок сортировки на противоположный
-t
Установить разделитель полей (по умолчанию
-u
Выводить только уникальные записи
-
пробельный символ)
На примерах приведенных ниже команд демонстрируется различие между число
вой и лексикографической сортировкой (последняя действует по умолчанию). В обеих
командах используются ключи
-t:
и -kЗ,З для сортировки файла
/etc/group
по его
третьему полю (в качестве разделителя используется двоеточие), содержащему иденти
фикатор
(ID)
группы. Первая команда реализует числовую сортировку, а вторая
сикографическую (в алфавитном порядке).
-
лек
Часть
228
$ sort -t:
-kЗ,З
1. Основы
администрирования
-n /etc/group'
root:x:O:
Ьin:x:l:daemon
daemon:x:2:
$ sort -t:
-kЗ,З
/etc/group
root:x:O:
Ьin:x:l:daemon
users:x:lOO:
Также полезна опция
-h,
реализующая числовую сортировку, которая понимает суф
фиксы, такие как м мя мега и G мя гига. Например, следующая команда правильно со
ртирует размеры подкаталогов в каталоге
операция, удобным средством реализации которой и является команда
wc (word count).
Выполненная без каких-либо ключей, она выведет все три результата подсчета.
$ wc /etc/passwd
32 77 2003 /etc/passwd
В контексте написания сценариев команду
ключей
wc
часто применяют только с одним из
(-1, -w или -с), чтобы результат ее выполнения состоял из одного числа. Эту
форму чаще всего можно встретить внутри обратных апострофов, и тогда результат мо
жет быть сохранен или использован по назначению.
нкоманда
sort принимает
ключ -kЗ (а не -kЗ, З), но, вероятно, она не делает то, что вы ожидаете.
Без номера завершающего поля ключ сортировки действует до конца строки.
глава
7. Сценарии и командная оболочка
229
tee: копирование входного потока в два места
Команда
Командный конвейер, как правило, действует прямолинейно, но зачастую полез
но распараллелить поток данных, т.е. "перехватить" его и отправить копию в файл или
окно терминала. Это можно сделать с помощью команды
tee,
которая отправляет свой
стандартный входной поток как в стандартный выходной канал, так и в файл, указан
ный в командной строке. Представьте действие этой команды в виде тройника в трубо
проводе (tee (англ.)
Устройство
-
тройник.
/dev/tty
-
Примеч. пер.).
можно считать синонимом для текущего терминала.
Например, команда
$ find /
core 1 tee /dev/tty 1 wc -1
-nаше
выводит найденные путевые имена файлов
Часто работа конвейера с командой
core
tee,
и результат подсчета их количества.
выводящей результаты и в файл, и в окно
терминала (для проверки), занимает много времени. Вы можете понаблюдать за первы
ми результатами, чтобы убедиться в том, что все работает как надо, а затем смело уходи
те: результаты сохранятся в файле.
head и tail: чтение файла с начала или с конца
Просмотр строк с начала или конца файла - обычная административная
Команды
Команды
head
и
tail
операция.
отображают по умолчанию десять строк, но вы можете использо
вать ключ, задающий желаемое количество строк.
Для интерактивного использования команда
head
сто нее (в этом контексте) часто используется команда
для отображения по страницам. Однако команду
head
уже несколько устарела, и вме
less,
которая разбивает файлы
можно успешно применять в сце
нариях и с другой целью.
С командой
tail
используется ключ
-f, который чрезвычайно полезен для си
стемных администраторов. Вместо немедленного завершения после вывода требуемо
го количества строк команда
tail -f
ожидает поступления новых строк, которые будут
добавлены в конец файла, а затем выведены по назначению, что очень удобно для мо
ниторинга журналов регистрации. Однако следует иметь в виду, что программа, которая
реализует запись данных в файл, может буферизировать свои выходные данные. Даже
если строки будут добавляться регулярно (с точки зрения логики), они могут стать види
мыми только фрагментами объемом
1 или 4 КиБ. 9
Команды
head и tail получают несколько имен файлов из командной строки. Даже
tail -f допускает использование нескольких файлов, и это довольно удобно;
появляются новые результаты, подлежащие выводу на экран, команда tail выво
команда
когда
дит имя файла, содержащего эти результаты.
Для остановки процесса мониторинга нажмите комбинацию клавиш
Команда
.
grep: поиск текста
При выполнении команды
grep
по мере просмотра входного текста выводятся стро
ки, которые совпадают с заданным образцом (шаблоном). Свое название эта команда
получила "в наследство" от команды g/регулярное _ выражение/р) из старого (и ныне
действующего) редактора
ed, используемого в самых первых версиях UNIX.
"Регулярные выражения"
(regular expressions) -
это шаблоны, предназначенные
для поиска совпадающего с ними текста и написанные на стандартном языке шаблонов.
"Информаuию о единицах измерения см. в разделе
1.6
главы
1.
Часть
230
1. Основы администрирования
Они представляют собой универсальный стандарт, используемый большинством про
грамм при поиске по совпадению с шаблоном, хотя и с небольшими различиями в ре
ализациях. Странное имя команды уходит своими корнями в оригинальные изыскания
соответствующих разделов теории вычислений. Более детально синтаксис регулярных
выражений рассматривается в разделе
7.4.
Подобно большинству фильтров, команда
grep
имеет множество ключей. Например,
ключ -с позволяет выводить количество совпавших строк, ключ
-i
служит для игнори
рования регистра букв при сопоставлении, а ключ
-v предназначен для вывода отлича
ющихся (а не совпавших) строк. Очень полезным является ключ -1 (прописная буква
"[;'),который заставляет команду
grep
выводить только имена файлов, содержащие со
впавшие с шаблоном строки, а не все совпавшие строки.
Например, выполнение команды
$ sudo grep -1 mdadm /var/log/*
/var/log/auth.log
/var/log/syslog.O
демонстрирует, что записи с именем утилиты
mdadm
нашлись в двух различных файлах
системных журналов.
Команду
grep
можно считать классической реализацией базового механизма ис
пользования регулярных выражений, но в некоторых версиях предлагается выбор других
диалектов. Например, Linuх-команда
языка
Perl.
grep
-р служит для поиска выражений в стиле
хотя в справочных страницах можно найти неопределенное предупреждение
о том, что такой вариант носит "экспериментальный характер". Для полной уверенно
сти в своих сценариях просто используйте язык
Если вы фильтруете с помощью команд
--line-buffered,
Ruby, Python
tail -f
и
или
grep,
Perl.
то добавьте параметр
чтобы убедиться, что вы увидите каждую соответствующую строку,
как только она станет доступной
/var/log/шessages 1 grep --line-buffered ZFS
8 00:44:00 nutrient ZFS: vdev state changed, pool_
guid=l0151087465118396807 vdev_guid=7163376375690181882
$ tail -f
Мау
7 .3.
НАПИСАНИЕ СЦЕНАРИЕВ ДЛЯ ОБОЛОЧКИ sв
Оболочка
sh отлично подходит для простых сценариев, которые автоматизируют то,
что вы в противном случае вводили бы в командной строке. Ваши навыки командной
строки переносятся на сценарии
sh, и наоборот, что помогает вам извлечь максималь
sh. Но
ную отдачу от времени обучения. которое вы вкладываете в изучение оболочки
как только сценарий sh получает более
рых нет в оболочке
sh,
50
строк или когда вам нужны функции. кото
приходит время переходить на язык
Python
или
Ruby.
Для сценариев есть смысл ограничить себя диалектом, понятным исходной оболочке
Вoume, которая является стандартом
IEEE и POSIX.
Оболочки, совместимые с sh, часто
дополняют эту базовую линейку языковыми функциями. Целесообразно применять эти
расширения, если вы делаете это намеренно и хотите использовать конкретный интер
претатор. Однако чаще всего сценарии в конечном итоге используют эти расширения
непреднамеренно, и затем администраторы удивляются, когда их сценарии не работают
в других системах.
Глава
7.
Сценарии и командная оболочка
231
В частности, не предполагайте, что версией оболочки
sh в вашей системе всегда яв
bash, или даже, что оболочка bash доступна. В 2006 году система Ubuntu заме
нила bash на dash в качестве интерпретатора сценариев по умолчанию, и в рамках это
ляется
го процесса преобразования был составлен удобный список команд, за которыми нужно
следить. Вы можете найти его на сайте
wiki. uЬuntu. com/DashAsBinSh.
Выполнение
В оболочке
sh
комментарии начинаются со знака
#
и продолжаются до конца стро
ки. Как и в командной строке, вы можете разбить одну логическую строку на несколько
физических строк, обозначив переход на новую строку символом обратной косой черты
(\).
И, наоборот, можно поместить на одной строке несколько операторов, разделив их
точкой с запятой.
Сценарий для оболочки
sh
может состоять только из последовательности командных
строк. Например, следующий сценарий
helloworld
просто выполняет команду
echo.
#!/Ьin/sh
echo "Hello, world!"
Первая строка содержит сочетание символов#!, которое означает, что данный тек
стовый файл является сценарием, предназначенным для интерпретации командной обо
лочкой из каталога /Ьin/sh (которая сама может служить ссылкой на оболочку
и
bash)
dash
При принятии решения о том, как выполнить этот файл, ядро найдет соответ
ствующий синтаксис. С точки зрения оболочки, выполняющей этот сценарий, первая
строка представляет собой просто комментарий.
Теоретически, если ваша оболочка
sh
находится в другом месте, вам придется отре
дактировать первую строку. Тем не менее многие существующие сценарии предполага
ют, что она находится в каталоге /Ьin/sh, который системы вынуждены поддерживать,
хотя бы через ссылку.
Если вам нужен сценарий для запуска в оболочке
bash или
в другом интерпретаторе,
который может не иметь одного и того же командного пути в каждой системе, вы може
те использовать каталог /usr/Ьin/env для поиска переменной среды РАТН для опреде
ленной команды. 10 Например,
#!
/usr/Ьin/env
ruby
является распространенной идиомой для запуска сценариев на языке
Ruby.
Подобно ка
талогу /Ьin/sh, каталог /usr/Ьin/env является настолько широко распространенным
вариантом, что все системы обязаны его поддерживать.
Для того чтобы подготовить этот файл к выполнению, достаточно установить его бит,
"отвечающий" за выполнение (см. раздел
5.5).
$ chmod +х helloworld
$ • /helloworld' 1
Hello, world!
'"Поиск путей имеет последствия для безопасности, особенно при запуске сценариев в среде
sudo.
Дополнительную информацию об обработке переменных окружения в среде
разделе
sudo
см. в
3.2.
11 Если ваша оболочка понимает команду
вашем пути поиска указан текущий каталог
helloworld без префикса . /, это означает, что в
(. ).
Это плохо, поскольку дает другим пользователям
возможность устраивать для вас ''ловушки" в надежде, что вы будете пытаться выполнить
определенные команды при переходе к каталогу, в котором они имеют доступ д.1я записи.
232
Часть
1. Основы администрирования
Можно также непосредственно запустить (активизировать) оболочку в качестве ин
терпретатора сценария.
$ sh helloworld
Hello, world!
$ source helloworld
Hello, world!
Первая команда выполнит сценарий
а вторая
helloworld
в новом экземпляре оболочки
sh,
заставит вашу начальную оболочку прочитать содержимое файла, а затем вы
-
полнить его. Второй вариант полезен в случае, когда сценарий устанавливает перемен
ные среды или выполняет другие операции настройки, применимые только к текущей
оболочке. Обычно этот вариант используется при написании сценариев, включающих
содержимое файла конфигурации, написанного в виде ряда присваиваний значений
переменным. 12
m
Дополнительную информацию о битах разрешения можно прочитать в разделе
Если вы пришли из мира
Windows,
5.5.
то вам привычно использовать понятие расши
рения файла, по которому можно судить о типе файла, а также о том, можно ли его
выполнить. В мире
UNIX
и
Linux
признак того, может ли файл быть выполнен (и если
да, то кем), содержится в специальных битах полномочий. При желании вы можете на
делить свои Ьаsh-сценарии суффиксом
. sh,
который бы напоминал вам об их типе, но
тогда при выполнении соответствующей команды вам придется вводить суффикс
поскольку
UNIX
. sh,
не интерпретирует расширения специальным образом.
От команд к сценариям
Прежде чем переходить к особенностям написания сценариев для оболочки
sh,
оста
новимся на методике этого процесса. Многие пишут эти сценарии так же, как на языке
Python
или
Ruby,
т.е. используя какой-нибудь текстовый редактор. Однако удобнее рас
сматривать в качестве интерактивной среды разработки сценариев режим с приглаше
нием на ввод команды.
Предположим, например, что у вас есть журналы регистрации, именованные с суф
фиксами
. log
и
. LOG
и разбросанные по всей иерархической системе каталогов.
Допустим также, что вы хотите изменить эти суффиксы, переведя их в верхний регистр.
Прежде всего, попытаемся отыскать все эти файлы.
$ find . -name '*log'
.do-not-touch/important.log
admin.com-log/
foo.log
genius/spew.log
leather _ flog
Ой! Похоже на то, что нам надо включить в шаблон точку и при поиске игнориро
вать каталоги. Нажмите комбинацию клавиш
,
чтобы вернуться в режим ко
мандной строки, а затем модифицируйте ее.
$ find . -type f -name '*.log'
.do-not-touch/important.log
foo.log
12 Синонимом
для команды
. helloworld.
source
служит команда в виде точки (dоt-команда), например
Глава
7. Сценарии
и командная оболочка
233
genius/spew.log
Отлично, это уже выглядит лучше. Правда, каталог
. do-not-touch
(т.е. "не тро
гать") вызывает смутное чувство тревоги; но мы можем избавиться от него.
$ find . -type f -name '*.log'
1
grep -v .do-not-touch
foo. log
genius/spew.log
Прекрасно, мы получили абсолютно точный список файлов, которые должны быть
переименованы. Попробуем сгенерировать несколько новых имен.
$ 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.log foo.LOG
mv genius/spew.log genius/spew.LOG
Да, это именно те команды, которые позволят переименовать нужные файлы. Как
же их выполнить? Мы могли бы снова вызвать уже выполненную команду и отредакти
ровать команду
echo,
чтобы заставить оболочку
sh
выполнять команды
выводить их. Ведь передача команд в отдельную копию оболочки
sh -
mv,
а не просто
более надежный
вариант работы, который к тому же требует меньшего объема редактирования.
Нажав комбинацию клавиш
,
мы обнаруживаем, что оболочка
bash
забот
ливо свернула наш мини-сценарий в одну-единственную строку. К этой "уплотненной"
командной строке мы просто добавляем канал, передаюший выходные данные команде
sh
-х.
grep -v .do-not-touch 1 while read fname;
$ find . -type f -name '*.log•
sed s/.log/.LOG/'; done 1 sh -х
do echo mv $fname 'echo $fname
+ mv foo.log foo.LOG
+ mv genius/spew.log genius/spew.LOG
Ключ -х команды
bash обеспечивает
вывод каждой команды перед ее выполнением.
Мы завершили переименование файлов, но нам хотелось бы сохранить этот сцена
рий, чтобы использовать его снова. Встроенная в
sh
во многом аналогична нажатию комбинации клавиш
команда
fc
,
по своему действию
но вместо возврата по
следней команды в командную строку она передает команду в заданный вами редактор.
Добавьте в свой файл строку идентификационного комментария, поместите сохранен
ный файл в приемлемый ДJIЯ вас каталог (например,
... /Ьin
или /usr/local/Ьin), сде
лайте файл исполняемым, и вы получите настоящий сценарий.
Итак, подытожим.
1.
Разрабатывайте сценарий (или его часть) в виде конвейера команд, причем по
шагово и в режиме выполнения командных строк.
2.
Пересылайте результат в стандартный выходной поток, проверяя правильность
работы используемых вами команд.
3.
На каждом этапе используйте буфер ранее выполненных команд ДJIЯ их появле
ния в командной строке и инструменты редактирования
-
ДJIЯ их модификации.
Часть
234
1. Основы администрирования
Пока вы получаете неправильные результаты, можно считать, что вы, по сути,
4.
ничего не сделали, и до тех
nop,
пока команды не заработают так, как надо, ниче
го (из уже сделанного) не надо удалять.
Если результат выглядит правильным, выполните команды на реальном примере,
5.
чтобы убедиться, •по все получилось так, как ожидалось.
Используйте команду
6.
fo,
чтобы зафиксировать свою работу в редакторе, оформи
те еесоответствующим образом и сохраните.
В приведенном выше примере мы вывели командные строки, а затем направили их
в подоболочку для выполнения. Этот метод не является универсально применимым, но
часто оказывается полезным. В качестве альтернативного варианта можно фиксировать
результаты, перенапрамяя их в файл. Терпеливо добивайтесь получения нужных резуль
татов и, пока не увидите их, не выполняйте никаких потенциально деструктивных дей
ствий.
Ввод и вывод данных
Команда
eoho
не отличается сложностью, но зато проста в применении. Для полу
чения большего контроля над выводом данных используйте команду
printf.
Она не
очень удобна, поскольку предполагает, что вы должны в явном виде указывать в нуж
ных для вас местах символы перехода на новую строку
(\n),
но позволяет использовать
символ табуляции и другие средства форматирования результата. Сравните результаты
выполнения следующих двух команд.
$ echo
11 \taa\t.ЬЬ\tcc\n"
\taa\tbb\tcc\п
11 \taa\tЬb\tcc\n"
$ printf
аа
ЬЬ
се
Иногда работа команд
eoho
и
printf
поддерживается на уровне операционной си
стемы (обычно соответствующие им исполняемые файлы хранятся в каталогах /Ьin и
/usr/Ьin соответственно). Хотя эти команды и встроенные в оболочку утилиты в целом
подобны, они могут иметь незначительные отличия, особенно это касается команды
printf.
Вы можете либо придерживаться sЬ-синтаксиса, либо вызывайте "внешнюю"
команду
printf,
указывая ее полный путь.
Для того чтобы сформировать для пользователя приглашение ввести данные, можно
read.
использовать команду
#!/Ьiп/sh
echo -п "Eпter your
read user пате
if [
-п
пате:
"$user_пaтe"
echo "Hello
exit О
"
]; then
$user_пaтe!"
else
echo "Greetiпgs,
exit 1
пaтeless
опе!"
fi
Ключ
-n
в команде
eoho подавляет привычный переход на новую строку, но здесь
printf. Мы еще рассмотрим вкратце синтаксис оператора if,
с нашей точки зрения, очевидно. Ключ -n в операторе if обе-
была бы кстати команда
но его действие здесь,
7. Сценарии
Глава
и командная оболочка
235
спечит значение истины, если его строковый аргумент не окажется нулевым. Вот как
выглядит результат выполнения этого сценария.
$ sh readexample
Enter your name: Ron
Hello Ron !
Пробелы в именах файлов
Именование файлов и каталогов, по существу, не регламентируется, за исключением
того, что имена ограничены по длине и не должны содержать косой черты или нули.
В частности, допускаются пробелы. К сожалению, система
UNIX
имеет давнюю тради
цию разделения аргументов командной строки на пробелы, поэтому устаревшее про
граммное обеспечение имеет тенденцию давать сбой, когда в именах файлов появляют
ся пробелы.
Пробелы в именах файлов были обнаружены прежде всего в файловых системах, со
вместно используемых с компьютерами Мае и персональными компьютерами, но те
перь они внедрились в культуру
UNIX
и также встречаются в некоторых стандартных
пакетах программного обеспечения. Выхода нет: административные сценарии должны
быть готовы обрабатывать пробелы в именах файлов (не говоря уже об апострофах, звез
дочках и различных других угрожающих пунктуационных метках).
В оболочке и в сценариях можно указывать имена файлов с пробелами, чтобы дер
жать их части вместе. Например, команда
$ less
"Му
spacey file"
считает файл Му
spacey file
в качестве единственного аргумента команды
less.
Вы
также можете избежать отдельных пробелов с помощью обратной косой черты:
$ less
Му\
spacey\ file
Функция завершения имени файла большинства оболочек (зачастую привязанная
к клавише ) обычно автоматически добавляет обратную косую черту. Когда вы пи
шете сценарии, полезным оружием, о котором нужно знать, является опция
В сочетании с параметром
xargs -0
она делает комбинацию
find /xargs
-printO.
коррект
ной, независимо от пробелов, содержащихся в именах файлов. Например, команда
$ find / home-type f -size +
1М
-printO
1
xarqs -0 ls -1
выводит на экран длинный список всех файлов в каталоге
/home размером
более одного
мегабайта.
Функции и аргументы командной строки
Аргументы командной строки служат для сценария переменными с числовыми име
нами:
$1 -
первый аргумент командной строки,
$2 -
второй и т.д. Аргумент $О со
держит имя, по которому бьm вызван сценарий, например
. /Ьin/ example. sh,
т.е. это
не фиксированное значение.
Переменная
а переменная
мент
$0.
$*
$#
содержит количество переданных аргументов командной строки,
-
все эти аргументы. Ни одна из этих переменных не учитывает аргу
Рассмотрим пример использования этих аргументов.
#!/Ьin/sh
show_usage()
echo "Usage: $0 source dir dest dir" 1>&2
Часть
236
1. Основы
администрирования
exit 1
#
Здесь
начинается
основная
программа
if [ $# -ne 2 ]; then
show_usage
else # There are two arguments
if [ -d $1 ]; then
source_dir=$1
else
echo 'Invalid source directory' 1>&2
show_usage
fi
if
-d $2 ]; then
dest_dir=$2
else
echo 'Invalid destination directory' 1>&2
show_usage
fi
fi
printf "Source directory is $(source_dir}\n"
printf "Destination directory is $(dest_dir}\n"
Если вы вызываете сценарий без аргументов или с недействительными аргумента
ми, сценарий должен вывести короткое сообщение об ошибке, чтобы напомнить вам,
как его использовать. В приведенном выше примере сценарий принимает два аргумен
та, подтверждает, что оба аргумента являются каталогами, и выводит на экран их име
на. Если аргументы недействительны, сценарий печатает сообщение об использовании
и выходит с ненулевым кодом возврата. Если вызывающий сценарий проверяет код воз
врата, он будет знать, что этот сценарий не удалось выполнить правильно.
Мы создали отдельную функцию
show_ usage
для печати сообщения об использо
вании. Если впоследствии сценарий будет обновлен, чтобы принимать дополнительные
аргументы, сообщение об использовании должно быть изменено только в одном месте.
Обозначение
1>&2
в строках, которые отображают сообщения об ошибках, выводит ре
зультаты в поток SТDERR.
$ mkdir ааа ЬЬЬ
$ sh showusage ааа
ЬЬЬ
Source directory is ааа
Destination directory is ЬЬЬ
$ sh showusage foo bar
Invalid source directory
Usage: showusage source_dir dest dir
Аргументы для функций оболочки
строки. Первый аргумент
- $1
sh
рассматриваются как аргументы командной
и т.д. Как бьшо показано выше, $О остается именем сце
нария.
Чтобы сделать пример более надежным, мы могли бы заставить программу
usage
show_
получать в качестве аргумента код ошибки. Это позволит возвращать более опре
деленный код для каждого типа сбоя. Следующий фрагмент кода показывает, как это
может выглядеть.
Глава
7. Сценарии
237
и командная оболочка
show_ usage () {
echo "Usage: $0 source_dir dest_dir" 1>&2
if [ $# -eq О]; then
exit 99 # Exit with arbitrary nonzero return code
else
exit $1
fi
В этой версии подпрограммы аргумент не является обязательным. Внутри символы
$#
сообщают, сколько аргументов было передано. Если не указан более конкретный
код, сценарий заканчивает работу с кодом
99.
Однако конкретное значение, например
show_usage 5
приводит к тому, что сценарий завершает работу после вывода сообщения об использо
вании именно с этим кодом. (Переменная оболочки$? содержит статус выхода послед
ней выполненной команды, независимо от того, используется она внутри сценария или
в командной строке.)
В оболочке
sh
сильна аналогия между функциями и командами. Вы можете опре
делить полезные функции в файле~/
лочки
sh),
.bash_profile
(~/
.profile
для обычной обо
а затем использовать их в командной строке, как если бы они были команда
ми. Например, если ваш сайт стандартизован на сетевом порту
7988
для протокола
SSH
(форма "безопасность через безвестность"), вы можете определить функцию
ssh () {
/usr/bin/ssh
-р
7988 $*
}
в каталоге~/
метрами -р
.bash_profile,
чтобы функция команда
ssh
всегда выполнялась с пара
7988.
Как и многие оболочки,
bash
имеет механизм псевдонимов, который может воспро
извести этот пример более точно, при этом функция становится все более универсаль
ной И МОЩНОЙ.
Поток управления
Выше в этой главе мы уже рассмотрели несколько конструкций
else
if-then
и
if-then-
(они работают вполне ожидаемым образом). Терминатором (признаком конца)
для оператора
if
служит оператор
использовать ключевое слово
elif,
fi.
Для образования цепочки if-операторов можно
означающее
"else if".
if [ $base -eq 1 ] && [ $dm -eq 1 ]; then
installDMBase
$dm -eq 1 ] ; then
elif [ $base -ne 1
&&
installBase
$dm -ne 1 ] ; then
elif [ $base -eq
&&
installDM
else
echo '==> Installing nothing'
fi
Как и специальный []-синтаксис для выполнения операций сравнения, так и "пара
метрические" имена операторов целочисленного сравнения (например,
-eq) являются
наследием утилиты /Ьin/test из ранней командной оболочки Стивена Борна. В дей-
Часть
238
1. Основы
администрирования
ствительности квадратные скобки
- это не что иное, как условное обозначение вызова
test; они не являются частью оператора if. 13
В табл. 7.3 собраны операторы оболочки bash, позволяющие сравнивать числа
строки. В отличие от языка Perl, в оболочке bash используются текстовые операторы
утилиты
и
для чисел и символические операторы для строк.
Таблица
7.3.
Элементарные операторы сравнения оболочки
Строки
х
х
х
х
х
х
-n
-z
Истина, если
Числа
у
х равно у
х
-eq
-ne
у
хне равно у
х
-lt
у
х меньше у
у
х меньше или равно у
= у
!= у
< у
"
>=
х
х
у
х
у
-le
-gt
-ge
sh
у
х больше у
у
х больше или равно у
null
null
х
хне равно значению
х
х равно значению
"Здесь должна использоваться обратная косая черта или двойные квадратные скобки, чтобы предотвратить интер
> в символ перенаправления ввода-вывода.
претацию символа
В оболочке
bash
предусмотрены возможности оценки свойств файлов (снова-таки
как освобождение от наследства /Ьin/test). Некоторые из операторов тестирования
и сравнения файлов приведены в табл.
Таблица
7.4.
7.4.
Операторы проверки файлов оболочки
Оператор
sh
Истина, если
-d
файл
Файл файл существует и является каталогом
-е
файл
Файл файл существует
-f
файл
Файл файл существует и является обычным
-r
-s
-w
файл
У вас есть право доступа для чтения файла
файл
Файл файл существует и он не пустой
файл
файлl
файлl
У вас есть право доступа для записи в файл
-nt
-ot
файл2
Файл файлl новее, чем файл2
файл
Файл файлl старше, чем файл2
Несмотря на всю полезность формы
elif, зачастую с точки зрения ясности
case. Ниже показан ее синтаксис на
граммного кода лучше использовать структуру
про
при
мере функции, которая централизует процесс регистрации сценария. Конкретные вари
анты описываются закрывающими скобками после каждого условия и двумя точками
с запятой, завершающими блок операторов, который должен быть выполнен при реали
зации заданного условия. Оператор
#
#
#
Уровень
переменной
от
case
завершается ключевым словом
протоколирования устанавливается
самого
LOG_LEVEL.
строгого
Возможные
до наименее
в
варианты перечислены в
строгого:
esac.
глобальной
порядке
Error, Warning, Info
и
Debug.
logMsg {
message level=$1
11 Сейчас
эти оnераuии встроены в оболочку и уже не запускают на выполнение утилиту /Ьin/test.
Глава
7. Сценарии
и командная оболочка
239
message_itself=$2
if [ $message_level -le $LOG_LEVEL ]; then
case $message_level in
0) message_level_text="Error" ;;
1) message_level_text="Warning" ;;
2) message_level_text="Info" ;;
3) message_level_text="Debug" ,,
*) message_level_text="Other"
esac
echo "${message_level_text}: $message_itself"
if
Эта функция иллюстрирует общепринятую парадигму "уровня регистрации"
level),
(log
используемую многими приложениями административного характера. Код это
го сценария позволяет генерировать сообщения на различных уровнях детализации, но
действительно регистрируются или отрабатываются только те из них, которые "прохо
дят" глобально устанавливаемый порог
$ LOG_ LEVEL. Чтобы прояснить важность каждо
го сообщения, его текст предваряется меткой, описывающей соответствующий уровень
регистрации.
Циклы
В оболочке
sh
конструкция
for".in
позволяет упростить выполнение некоторых
действий для группы значений или файлов, особенно при универсализации файловых
имен, т.е. замене реальных символов в имени и расширении универсальными (напри
мер, "*"и "?")с целью формирования целых списков имен файлов. Шаблон
в приведенном ниже цикле
for
*. sh
позволяет обработать целый список совпадающих с ним
(шаблоном) имен файлов из текущего каталога. Оператор
по очереди присваивает имя каждого файла переменной
for, проходя
script.
по этому списку,
#!/Ьin/sh
suffix=BACKUP--'date +%Y-%m-%d-%H%M'
for script in *.sh; do
newname="$script.$suffix"
echo "Copying $script to $newname ... "
ер -р $script $newname
done
Вывод выглядит следующим образом:
$ sh forexample
Copying rhel.sh to rhel.sh.BACKUP--2017-01-28-2228 .. .
Copying sles.sh to sles.sh.BACKUP--2017-01-28-2228 .. .
В раскрытии имени файла нет ничего магического; все работает в точном соответ
ствии с тем, как написано в командной строке. Другими словами, сначала имя файла
раскрывается (т.е. шаблон заменяется существующим именем), а затем обрабатывается
интерпретатором в развернутом виде. Имена файлов можно также вводить статически,
как показано ниже:
for script in rhel.sh sles.sh; do
Часть
240
1. Основы администрирования
В действительности любой список имен, содержащих пробельные символы (включая
содержимое переменной), обрабатывается как объект циклической конструкции for."
in.
Вы также можете опустить список полностью (вместе с ключевым словом
in),
и в
этом случае цикл неявно выполняет итерации по аргументам командной строки сцена
рия (на верхнем уровне) или аргументы, переданные функции:
#!/Ьin/sh
for file; do
newname="$(file).backup"
echo "Copying $file to $newname ... "
ер -р $file $newname
done
Циклы в оболочке
bash,
в отличие от традиционной оболочки
sh,
ближе к циклам
из традиционных языков программирования, в которых задается стартовое выражение,
инкрементация и условие окончания цикла. Например:
# bash-specif ic
for (( i=O; i < $CPU_COUNT; i++ )); do
CPU_LIST="$CPU_LIST $i"
done
На примере следующего сценария иллюстрируется цикл
while,
который часто при
меняется д11Я обработки аргументов командной строки и чтения строк файла.
# ! /Ьin/sh
ехес 0,
с которой связан этот шаблон,
-
это последнее возмож
ное допустимое вхождение искомого элемента во входном тексте, что, наверняка, совсем
не отвечает вашим намерениям. Вероятно, вы хотели отыскать совпадение с подстро
кой
, за которой следует тег . Тогда лучше переписать этот шаблон в виде
", поскольку следующим после тега
быть не тег
17 Несмоrря
.
может
А такой результат вас, скорее всего, не устроит.
на то что в этом разделе в качестве примеров обрабатываемого текста показаны фрагменты
НТМL-кода, регулярные выражения - не самый подходящий инструмент в данном случае (что не
преминули отметить и наши рецензенты). Языки Ruby и Pythoп имеют прекрасные расширения,
которые анализируют НТМL-документы надлежащим образом. Вы можете получить доступ к
интересующим вас порциям с помощью Xpath- или СSS-селекторов. Подробнее о модульных
репозиториях соответствующих языков можно узнать, обратившись к странице Википедии,
посвященной языку запросов Xpath (XML Path Language) и соответствующим модулям в репозиториях.
Глава
7. Сценарии
и командная оболочка
247
Шаблоны с несколькими секциями групповых символов могут "спровоцировать"
анализатор регулярных выражений на экспоненциальное поведение, особенно в случае,
если порции текста могут совпадать с несколькими шаблонными выражениями, и тем
более в случае, если искомый текст в действительности не соответствует шаблону. Эта
ситуация не является такой уж необычной, как может показаться, главным образо:-.~
тогда, когда шаблон сопоставляется с НТМL-кодом. Очень часто вам придется искать
конкретные теги, за которыми следуют другие теги, возможно, разделенные третьими
тегами, и так далее, одним словом, вам придется создавать задание, которое потребует,
чтобы анализатор проверил массу возможных комбинаций.
Большой специалист в области регулярных выражений Ян Гойвертс
называет этот эффект катастрофическим откатом
(Jan Goyvaerts)
(catastrophic backtracking) и описыва
ет его в своем блоге (за подробностями и некоторыми удачными решениями обращай
тесь по адресу:
regular-expressions. info/catastrophic. html).
Из всего сказанного выше можно сделать такие выводы.
•
Если вы можете организовать построчное сопоставление шаблона, а не пофай
ловое (т.е. с просмотром сразу всего файла), значит, вы значительно уменьшаете
риск получения, мягко говоря, низкой производительности.
•
Несмотря на то что регулярные выражения являются "жадными" по умолчанию,
вам, скорее всего, такие не нужны. Используйте "ленивые" операторы.
•
Все экземпляры специальных символов".*" по существу подозрительны и долж
ны быть тщательно исследованы.
7 .5.
ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ РпноN
Python
и
интерпретируемые языки с выраженным объектно-ориентирован
Ruby -
ным уклоном. Оба они широко используются в качестве языков сценариев общего на
значения и имеют обширные библиотеки сторонних модулей. Мы обсудим
подробно в разделе
Язык
Python
Ruby
более
7.6.
предлагает простой синтаксис, который обычно довольно легко отсле
живать, даже при чтении кода других людей.
Мы рекомендуем всем системным администраторам свободно владеть языко:\-1
Python.
Это один из лучших среди современных языков системного администрирования
и общего назначения. Он также широко поддерживается в качестве связующего сред
ства для использования в других системах (например, в базе данных
разработки
Xcode
PostgreSQL и среде
Apple). Он отлично взаимодействует с интерфейсом прикладного
REST и имеет хорошо разработанные библиотеки для машинного
от
программирования
обучения, анализа данных и вычислений.
Страсти по
в
Python 3
Python уже успел
2008 году появилась
стать основным языком написания сценариев в мире, когда
версия
от обратной совместимости с
Python 3. В этой версии разработчики решили отказаться
Python 2, чтобы можно было реализовать группу скром
ных, но фундаментальных изменений и исправлений в языке, особенно в области ин
тернационализированной обработки текста. 18
1 кточный
список изменений в версии
Python 3 не
можете найти их описание на страниuе
является предметом нашего обсуждения. но вы
docs .python.org/З .O/whatsnew/3 .О .htшl.
248
Часть
К сожалению, развертывание версии
1. Основы администрирования
Python 3 потерпело
фиаско. Обновления языка
были вполне разумными, но не обязательными для среднестатистического программи
ста на
Python
с существующей базой поддерживаемого кода. В течение долгого време
ни разработчики сценариев избегали использования
потому что их любимые
Python 3,
библиотеки не поддерживали его, в то время как авторы библиотек не поддерживали
Python 3,
потому что их клиенты все еще использовали
Python 2.
Даже в самых благоприятных обстоятельствах трудно подтолкнуть большое и взаи
мозависимое сообщество пользователей к такого рода разрыву. В случае
шла в течение большей части десятилетия. Однако по состоянию на
Python 3 борьба
2017 год эта ситуа
ция, по-видимому, меняется.
Библиотеки совместимости, которые позволяют одному и тому же Python-кoдy ра
ботать в любой версии языка, в какой-то степени облегчили переход. Но даже сейчас
версия
Python 3 остается
менее распространенной, чем
Python 2.
На момент написания этой статьи книги руЗ readiness.
из
360 лучших библиотек Python остаются
org
несовместимыми с
сообщает, что только
17
Однако длинный
Python 3.
хвост непереносимого программного обеспечения хорошо отрезвляет: только немногим
более
25% библиотек, хранящихся на сайте pypi. python. org (индекс Python Package,
PyPI) работает под управлением версии Python 3. 19 Конечно, многие из этих проек
тов устарели и больше не поддерживаются, но 25% по-прежнему является относительно
или
небольшим числом.
Python 2 или Python
З?
Замедленный переход привел к тому, что версии
Pythons 2 и 3 стали
рассматриваться
как отдельные языки. Вам не нужно делать взаимоисключающий выбор
в любой си
-
стеме можно запускать обе версии одновременно без конфликтов.
Все наши иллюстративные системы устанавливают версию
Python 2
по умолчанию,
обычно как /usr/Ьin/python2 с символической ссьmкой из /usr/Ьin/python.
Python 3
может быть установлен как отдельный пакет; двоичный код называется pythonЗ.
RHEL.
Проект
Fedora
работает над тем, чтобы сделать
ей по умолчанию, а системы
Red Hat
и
CentOS
Python 3
своей верси
намного отстают и даже
не определяют предварительно построенный пакет для версии
Однако вы можете выбрать один из репозиториев
Packages for Enterprise Linux).
Для получения инструкций по доступу к это
му репозиторию, обратитесь в раздел
wiki/EPEL для
Python 3.
EPEL Fedora (Extra
FAQ
на сайте
fedoraproj ect. org /
получения инструкций по доступу к этому репозиторию. Его
легко настроить, но точные команды зависят от версии.
Если вы впервые приступаете к разработке сценариев или к программированию
на языке
Python,
имеет смысл перейти непосредственно к
Python 3.
Именно его син
таксис мы демонстрируем в этой главе, хотя на самом деле разница между
и
Python 3 в
наших простых примерах заключается только в строках
Python 2
print.
Для существующего программного обеспечения вы можете использовать любую вер
сию
Python,
которую предпочитает Программное обеспечение. Если ваш выбор сложнее,
чем просто новый или старый код, обратитесь к вики-системе
org/moin/Python2orPython3,
Python
на
wiki. python.
в которой содержится отличная коллекция задач, реше
ний и рекомендаций.
'~Для получения актуальной статистики см. сайт caniusepythonЗ
. com.
Глава
7. Сценарии
249
и командная оболочка
Краткое введение в язык
Python
Python мы рекомендуем 5-е издание двух
(Mark Lutz). Полную ссылку можно найти в раз
Для более полного ознакомления с языком
томника Изучаем
Python
Марка Лутца
деле "Литература".
Приведем короткий сценарий
"Hello, world!",
который нужно сохранить в файле
helloworld.
#!/usr/local/bin/pythonЗ
print ("Hello, world!")
Чтобы запустить его, установите бит выполнения или вызовите интерпретатор
pythonЗ напрямую.
$ chmod
+х
helloworld
$ . /helloworld
Hello world!
Самый крупный разрыв
Python
с традиционным стилем программирования заклю
чается в том, что отступы имеют логический смысл. Для разграничения блоков в язы
ке
и
Python
end.
не используются фигурные и квадратные скобки или ключевые слова
begin
Блоки автоматически формируются из выражений, находящихся на одном уровне
отступов. Точный стиль отступов (пробелы или табуляция, а также глубина отступов)
значения не имеет.
Создание блоков на языке
простое выражение
Python
лучше всего показано на примере. Рассмотрим
if-then-else:
import sys
sys.argv[l]
а=
if
== "1":
print
print
а
('а
равно
('Это
все
1')
then
еще раздел
инструкции
if.')
else:
print
print
('а
это',
('Это
print ( 'Это -
все
а)
else инструкции if. ')
if. ' )
еще раздел
вывод nосле
инструкции
Первая строка импортирует модуль
инструкции
if
sys,
который содержит массив
argv.
Две ветки
состоят из двух строк, каждая с отступом до одного уровня. (Двоеточие
в конце строки обычно обозначает начало блока и связано с отступом, который следует
за ним.) Окончательный оператор печати находится вне контекста оператора
$
pythonЗ Ыockexample
а равно
Это
все
Это
-
еще
раздел
вывод после
then
инструкции
инструкции
$
pythonЗ Ыockexample
ЭТО
if.
if.
2
2
Это все
-
1
1
а
Это
if.
еще раздел
вывод после
else
инструкции
инструкции
if.
if.
Соглашение об отступах в языке
Python
является менее гибким средством формати
рования кода, но оно уменьшает беспорядок, связанный с использованием скобок и то
чек с запятой. Это требует перестройки от тех, кто привык к традиционным разделите
лям, но большинство людей в конечном итоге приходят к выводу, что им это нравится.
Часть
250
Функция
1. Основы
администрирования
print в языке Python принимает произвольное количество аргументов.
Она вставляет пробел между каждой парой аргументов и автоматически передает новую
строку. Вы можете подавлять или изменять эти символы, добавляя опции
sep
=
= или
end
в конец списка аргументов.
Например, строка
print
("один",
"два",
"три",
sep
" - 11 ,
end
"! \n")
производит вывод
один-два-три!
Комментарии начинаются с символа
ках
sh, Perl
и
#и
простираются до конца строки, как и вязы
Ruby.
Можно разделить длинные строки, поставив обратные косые черты в местах разрыва
строк. Когда вы это делаете, значение имеют только отступы первой строки. Вы може
те отступать в строках продолжения настолько далеко, насколько вам нравится. Строки
с несбалансированными круглыми, квадратными или фигурными скобками автоматиче
ски сигнализируют о продолжении даже в отсутствие обратных косых черт, но вы може
те включить обратную косую черту, если это упрощает структуру кода.
Некоторые операции вырезания и вставки преобразуют символы табуляции в пробе
лы, и, если вы не знаете, чего хотите, это может привести вас в бешенство. Золотое пра
вило гласит: "Никогда не смешивайте табуляцию и пробелы; используйте для отступов
или то, или другое". Многие программные средства делают традиционное предположе
ние о том, что табуляции эквивалентны восьми пробелам, что является слишком боль
шим отступом для читаемого кода. Большинство специалистов из сообщества
Python,
похоже, предпочитают пробелы и четырехсимвольные отступы.
Впрочем, большинст~ю текстовых редакторов имеют варианты, которые могут по
мочь сохранить ваше душевное равновесие, либо путем запрета табуляции в пользу про
белов, либо путем разного отображения пробелов и табуляции. В крайнем случае вы мо
жете перевести табуляцию в пробелы с помощью команды expand.
Объекты, строки, числа, списки, словари, кортежи и файлы
Все типы данных в языке
Python
являются объектами, и это дает им большую мощ
ность и гибкость, чем о большинстве других языков.
В языке
Python
списки заключены в квадратные скобки и индексируются с нуля.
Они по существу похожи на массивы, но могут содержать объекты любого типа. 20
В языке
Python
есть кортежи, которые, по сути, являются неизменными списками.
Кортежи эффективнее, чем списки, и полезны для представления постоянных данных.
Синтаксис кортежей такой же, как и для списков, за исключением того, что в качестве
разделителей используются круглые, а не квадратные скобки. Поскольку выражение
(thing)
выглядит как простое алгебраическое выражение, кортежи, содержащие толь
ко один элемент, должны содержать запятую, играющую роль маркера, чтобы устранить
неоднозначность:
(thing,
).
Приведем несколько основных переменных и типов данных в языке
name = 'Гвен'
rating = 10
characters =
20 0днородный
['Губка
Боб',
'Патрик',
'Сквидвард']
и более эффективный тип массива реализован в модуле
целей мы рекомендуем использовать списки.
Python:
array,
но для большинства
Глава
7. Сценарии
251
и командная оболочка
elements = ( 'литий', 'углерод', 'бор')
print ("Имя: \t%s\nРейтинг: \t%d" % (name, rating))
print ("Персонажи:\t%s" % characters)
print ("Кумир:\t%s" % characters[O])
print ("Элементы:\t%s" % (elements, ) )
В этом примере получается следующий результат:
$
pythonЗ
Имя:
objects
Гвен
10
Рейтинг:
['Губка
Персонажи:
Кумир:
Губка
Боб',
'Патрик',
'Сквидвард']
Боб
( 'литий' ,
Элементы:
'углерод'
,
'бор'
)
Обратите внимание на то, что стандартное преобразование строки для типов списка и
кортежей представляет их в том виде, в котором они были введены в исходном коде.
Переменные в языке
Python
не являются синтаксически помеченными или не име
ют объявления типа, но объекты, к которым они относятся, имеют базовый тип. В боль
шинстве случаев
Python
не конвертирует типы автоматически, но отдельные функции или
операторы могут это сделать. Например, вы не можете объединить строку и число (с по
мощью оператора +) без явного преобразования числа в его строковое представление. Тем
не менее операторы и инструкции форматирования приводят все к строковой форме.
Как показано выше, каждый объект имеет строковое представление. Словари, спи
ски и кортежи рекурсивно формируют свои строковые представления, создавая их со
ставные элементы и комбинируя эти строки с соответствующей пунктуацией.
Оператор форматирования строк% очень похож на функцию
sprintf
из языка С,
но его можно использовать везде, где может появляться строка. Это двоичный оператор,
который берет строку слева и значения, которые нужно вставить справа. Если необхо
димо вставить более одного значения, значения должны быть представлены как кортеж.
Словарь в языке
Python
(также известный как хеш или ассоциативный массив) пред
ставляет собой набор пар ключ-значение. Хеш можно представить как массив, чьи ин
дексы (ключи) являются произвольными значениями; они не должны быть цифрами.
Однако на практике цифры и строки являются общими ключами.
Словарные литералы заключены в фигурные скобки, каждая пара ключей-значений
разделяется двоеточием. При использовании словари работают так же, как списки, за ис
ключением того, что индексы (ключи) могут быть объектами, отличными от целых чисел.
Переход на новую строку в конце вызовов функции
параметра
end
=
print
подавляется с помощью
"",потому что каждая строка уже содержит символ перехода на но
вую строку из исходного файла.
Python
не разделяет их автоматически.
Пример проверки ввода
В следующем сценарии показана общая схема проверки ввода в языке
Python.
Он
также демонстрирует определение функций и использование аргументов командной
строки, а также пару других специфических особенностей.
import sys
import os
def show_usage(message, code = 1):
print(message)
print("%s: исходный каталог целевой
sys.exit(code)
if len(sys.argv)
каталог"
% sys.argv[O])
!= 3:
2 аргумента; вы
elif not os.path.isdir(sys.argv[l]):
show_usage("Иcxoдный
не
каталог
один
ввели
show_usage("Hyжны
%d" % (len(sys.argv) - 1))
найден")
elif not os.path.isdir(sys.argv[2]):
show_usage("Цeлeвoй каталог
source, dest =
рrint("Исходный
рrint("Целевой
sys.argv[l:З]
source)
dest)
каталог:",
каталог",
Помимо импорта модуля
цедуре
не найден")
os. path. isdir.
sys,
мы также импортируем модуль
os
для доступа к про
Обратите внимание на то, что импорт не сокращает ваш доступ
к любым символам, определенным модулями; вы должны использовать полностью ква
лифицированные имена, которые начинаются с имени модуля.
Определение подпрограммы
show _ usage
предоставляет значение по умолчанию
для кода выхода, если вызывающий объект явно не указывает этот аргумент. Поскольку
все типы данных являются объектами, аргументы функции эффективно передаются
по ссылке.
В первой позиции список
sys. argv
содержит имя сценария, поэтому его длина
больше, чем количество аргументов командной строки, которые были фактически пре
доставлены. Форма
sys. argv [ 1: З]
-
это список фрагментов. Любопытно, что срезы
не включают элемент в дальнем конце указанного диапазона, поэтому этот фрагмент
включает только элементы
sys. argv [1]
и
sys. argv [2]. Чтобы
sys. argv [ 1:].
включить второй и по
следующие аргументы, можно просто написать
Как и в
ляется
sh, в языке P_ython есть специальное условие "else if'; ключевым словом яв
elif.
Но в нем нет явной инструкции
Параллельное присваивание переменных
case или switch.
source и dest немного
которых языков тем, что сами переменные не входят в список.
Python
отличается от не
допускает парал
лельные назначения в любой форме.
В языке
Python
используются одинаковые операторы сравнения для числовых
и строковых значений. Оператор сравнения "не равен" имеет вид
! =,
но в языке нет
Глава
7. Сценарии
253
и командная оболочка
унарного оператора
! ; для этой цели используется ключевое слово not. Существуют
and и or.
также булевы операторы
Циклы
В приведенном ниже фрагменте используется конструкция
элементов в диапазоне от
for ... in
для обхода
1 до 1О.
for counter in range (1, 10):
print(counter, end=" ")
print ()
#
Последний переход на новую строку
Как и в срезе массива в предыдущем примере, правая конечная точка диапазона
фактически в него не входит. Вывод включает только числа от
1 2 3 4 5 6 7
Это единственный тип цикла в языке
В языке
Python
1 до 9:
9
в
Python,
но это очень мощный инструмент.
есть несколько функций, которые отличают его конструкцию
for
от других языков.
•
В числовых диапазонах нет ничего особенного. Любой объект может поддержи
вать итерационную модель
Python
как обычно. Можно перебирать строку (по сим
волам), список, файл (по символам, строкам или блокам), список и т. д.
•
Итераторы могут принимать несколько значений, и можно иметь несколько пере
менных цикла. Присваивание в верхней части каждой итерации действует так же,
как обычные множественные присваивания в языке
Python.
Эта функция особен
но хороша дЛЯ обхода словарей.
•
В циклах
for и while в конце могут быть разделы else, которые выполняются
только в том случае, если цикл завершается нормально, в отличие от выхода из цик
ла по инструкции
break.
Поначалу это кажется неестественным, но такой подход
позволяет довольно элегантно обрабатывать некоторые варианты использования.
В приведенном ниже примере сценарий принимает регулярное выражение в команд
ной строке и сопоставляет его с списком гномов из сказки о Белоснежке, а также с цве
тами их костюмов. На экран выводится первое совпадение с частями, которые соответ
ствуют регулярному выражению, окруженному символами подчеркивания.
import sys
import re
suits = {
'Bashful': 'yellow', 'Sneezy': 'brown', 'Doc': 'orange', 'Grumpy': 'red',
'Dopey': 'green', 'Нарру': 'Ыuе', 'Sleepy': 'taupe'
pattern = re.compile("(%s)" % sys.argv[l])
for dwarf, color in suits.items():
if pattern.search(dwarf) or pattern.search(color):
print("%s's dwarf suit is %s." %
(pattern.sub(r"_\l_", dwarf), pattern.sub(r" \1_", color)))
break
else:
print("No dwarves or dwarf suits matched the pattern.")
Ниже приведен вариант вывода:
Часть
254
$
pythonЗ
1. Основы администрирования
dwarfsearch '[aeiou] {2)'
Sl_ee_py's dwarf suit is t_au_pe.
$
pythonЗ
dwarfsearch 'qalgu'
No dwarves or dwarf suits matched the pattern.
Присваивание переменной
suits демонстрирует синтаксис Python
sui ts. i terns (} является итератором
ния символьных словарей. Метод
значение
-
Д/JЯ шифрова
ДIJЯ пар ключ
обратите внимание на то, что на каждой итерации мы извлекаем как имя
гнома, так и цвет его костюма. Если вы хотите перебирать только ключи, вы можете
dwarf in suits.
Python реализует обработку регулярных выражений с помощью
просто написать
Язык
модуля
re.
В язы
ке нет встроенных функций для работы с регулярными выражениями, поэтому обработка
регулярных выражения в языке
Perl.
Python немного
более ограниченная, чем, скажем, в языке
Здесь шаблон регулярного выражения изначально компилируется из первого аргумента
командной строки, окруженного скобками (для формирования группы захвата). Затем стро
ки тестируются и модифицируются поисковыми и вспомогательными методами объекта
regex.
Вы также можете вызвать
re. search
и другие функции непосредственно, предо
стаRЛЯя регулярное выражение для использования в качестве первого аргумента.
Символы
\1
в строке подстановки представляют собой обратную ссылку на содер
жимое первой группы захвата. Странно выглядящий префикс
r,
который предшествует
строке подстановки
(r"_ \1_"), подавляет нормальную подстановку управляющих сим
волов в строковых константах (r обозначает "raw"). Без этого шаблон замены состоял
бы из двух символов подчеркивания, окружающих символ с цифровым кодом 1.
Следует отметить, что в словарях нет определенного порядка обхода. Если вы запу
стите поиск гномов во второй раз, то можете получить другой ответ:
$
pythonЗ
dwarfsearch '[aeiou] {2)'
Dopey's dwarf suit is gr_ee_n.
7.6. ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ
Ruвv
Язык
Ruby, разработанный и поддерживаемый японским разработчиком Юкихиро
(Yukihiro "Matz" Matsumoto), обладает многими функциями, общими с язы
ком Python, включая широко распространенный подход "Все является объектом".
Первоначально выпущенный в середине 1990-х годов, язык Ruby не получил известно
сти, пока десятилетия спустя не появилась платформа веб-разработки Rails.
В умах людей язык Ruby по-прежнему тесно связан с сетью, но в самом языке нет
Мацумото
ничего веб-специфичного. Он хорошо подходит для написания сценариев общего на
значения. Однако язык
Python,
вероятно, все же лучший выбор для основного языка
сценариев, хотя бы из-за его более широкой популярности.
Хотя язык
Ruby
Например, классы
во многом эквивалентен языку
Ruby
Python,
он является более гибким.
остаются открытыми для модификации другим программным
обеспечением, и сообщество программистов на языке
Ruby не
возражает против расши
рений, которые изменяют стандартную библиотеку.
Язык
Ruby
нравится тем, у кого есть склонность к "синтаксическому сахару",
т.е. особенностям, которые на самом деле не меняют базовый язык, но позволяют более
четко и четко выражать код.
В среде
due date
Rails,
например, строка
7.days.from_now
Глава
7. Сценарии
и командная оболочка
255
создает объект класса т ime без ссылки на имена любых связанных с временем классов
или выполнения явных арифметических операций над датой и временем. Платформа
Fixnum, представляющего целые
Duration, который действует как число; исполь
зуется в качестве значения, эквивалентного 604800, т.е. количеству секунд в семи днях.
Если проверить его в отладчике, он опишет себя как "7 дней". 21
Язык Ruby упрощает разработку "доменных языков" (например, DSL), мини-язы
ков, которые на самом деле являются подмножеством языка Ruby, но которые рассма
триваются как специализированные системы конфигурации. Например, язык Ruby DSL
используется в средствах настройки Chef и Puppet.
Rails
определяет объект
days
как расширение класса
числа. Этот метод возвращает объект
W Дополнительную информацию об инструментах Chef и Puppet см. в главе 23.
Инсталляция
В некоторых системах язык
Ruby
установлен по умолчанию, а в некоторых
-
нет.
Тем не менее он всегда доступен как пакет, часто в нескольких версиях.
На сегодняшний день (версия
2.3)
язык
Ruby
поддерживает относительно хорошую
совместимость со старым кодом. В отсутствие конкретных предупреждений обычно луч
ше всего установить самую последнюю версию.
К сожалению, большинство системных пакетов отстают на несколько выпусков
от релизов языка
(проверьте сайт
Ruby. Если ваша библиотека пакетов не включает текущую версию
ruby-lang. org, чтобы определить, так ли это), установите самую све
жую версию через RVМ; не пытайтесь делать это сами.
W Подробнее об RVM см. в разделе 7.7.
Краткое введение в язык
Поскольку языки
на языке
Python,
Ruby
Ruby
и
Ruby
Python
настолько похожи, некоторые фрагменты кода
могут показаться похожими на фрагменты кода из раздела о языке
приведенныеранее в этой главе.
#!/usr/bin/env ruby
print "Hello, world!\n\n"
name = 'Gwen'
rating = 10
characters
[ 'SpongeBob', 'Patrick', 'Squidward' ]
elements = { З => 'lithium', 7 => 'carbon', 5 => 'boron'
print "Name:\t", name, "\nRating:\t", rating, "\n"
print "Characters:\t#{characters}\n"
print "Elements:\t#{elements}\n\n"
element_names = elements.values.sort!.map(&:upcase).join(', ')
print "Element names:\t", element_names, "\n\n"
elements.each do Jkey, valuel
print "Atomic numЬer #{key} is #{value}.\n"
end
21 Эта
форма полиморфизма является общей для языков
Ruby
и
Python.
Его часто называют
"утиной типизацией": если объект ходит как утка и крякает как утка, вам не нужно беспокоиться
о том, действительно ли это утка.
Element names: BORON, CARBON, LITHIUM
Atomic
Atomic
Atomic
numЬer
numЬer
numЬer
Как и
З is lithium.
7 is carbon.
5 is boron.
Python,
язык
Ruby использует скобки для
разграничения массивов и фигурные
скобки для разделения словарных литералов. (В языке
Оператор
=>
Ruby они
ключ-значение отделяются друг от друга запятыми. В языке
Функция
и в языке
называются "хешами".)
отделяет каждый хеш-ключ от его соответствующего значения, а пары
в языке
print
Python 3.
Ruby -
Ruby
нет кортежей.
это функция (или, точнее, глобальный метод), как
Однако, если вы хотите использовать переход на новую строку, вы
должны явно указать это. 22 Кроме тоrо, круглые скобки, обычно встречающиеся вокруг
аргументов в вызовах функций, в
Ruby являются
необязательными. Разработчики обыч
но не включают их, если они не помогают прояснить код или устранить неоднознач
ность. (Обратите внимание на то, что некоторые из вызовов функции печати включают
в себя несколько аргументов, разделенных запятыми.)
В нескольких случаях мы использовали фигурные скобки
# { } скобки для
интерполя
ции значений переменных, заключенные в строках с двумя кавычками. Такие скобки мо
гут содержать произвольный код
Ruby; любое
значение. созданное кодом, автоматически
преобразуется в тип строки и вставляется во внешнюю строку. Вы также можете конка
+. но интерполяция обычно более эффективна.
element_names, иллюстрирует еще несколько возможностей
тенировать строки с помощью оператора
Строка, вычисляющая
языка
Ruby:
element_names = elements.values.sort! .map (&: upcase) .join (', ')
Это серия вызовов методов, каждый из которых работает с результатом, возвра
щаемым предыдущим методом, подобно конвейеру. Например, метод
values
объек
та elements создает массив строк, которые затем сортируются в алфавитном порядке
функцией sort ! . 23 Метод map класса Array вызывает метод upcase для каждого эле
мента, а затем снова собирает все результаты в новый массив. Наконец, метод j oin
объединяет элементы этоrо массива, чередующиеся с запятыми, для создания строки.
Блоки
В предыдущем коде текст между
do
и
end
представляет собой блок, известный в дру
гих языках как лямбда-функция, замыкание или анонимная функция. 24
22 Есть
также функция
puts,
которая добавляет символы перехода на новую строку автоматически,
но она, возможно, слишком изощренная. Если вы попытаетесь самостоятельно добавить символ
перехода на новую строку, функция puts не будет вставлять эти символы автоматически.
2 .~восклицательный
знак в имени функции
sort!
предупреждает вас, что при использовании этого
метода нужно быть осторожным. Это не синтаксическое правило, а просто часть имени метода.
В данном случае функция
sort !
сортирует массив на месте. Существует также метод
sort
без
восклицательного знака, который возврашает элементы в новом отсортированном массиве.
24 Фактически
в языке
Ruby существуют три объекта этого общего типа, известные как блоки,
процедуры и лямбда. Различия меЖдУ ними незначительны и не важны для этого обзора.
Глава
7. Сценарии
и командная оболочка
257
elements.each do lkey, valuel
print "Atomic numЬer #{key} is #{value}. \n"
end
Данный блок принимает два аргумента, которые он называет
key
и
value,
и выво
дит их значения на экран.
Оператор
выглядит как функция языка, но это всего лишь метод, определя
each
емый хешами. Оператор
each
принимает блок как аргумент и вызывает его один раз
для каждой пары ключ-значение, содержащей хеш. Этот тип итерационной функции,
используемой в сочетании с блоком, очень характерен для кода на языке
each
Ruby.
Имя
является стандартным именем обобщенных итераторов, но многие классы опреде
ляют более конкретные версии, такие как
В языке
Ruby
each _ line
или
each_ character.
есть альтернативный синтаксис для блоков, в котором в качестве раз
делителей используются фигурные скобки, а не
do ... end.
Он означает точно то же са
мое, но больше похож на часть выражения. Например,
Эта форма функционально идентична
чтобы просто указывать методу
map,
character. map ( & : reverse) ,
но вместо того,
какой метод вызывать, мы включили явный блок,
вызывающий обратный метод.
Значение блока
-
это значение последнего выражения, которое оно вычисляет
до завершения. Удобно, что почти все в языке
Ruby
является выражением (т.е. "фраг
ментом кода, который может быть выполнен для создания значения"), включая струк
туры управления, такие как
и
if-else.
case
(аналог конструкции
swi tch
в большинстве языков)
Значения этих выражений отражают значение, полученное в зависимости
от того, какой из разделов
case
или ветви инструкции
if-else
был выполнен.
Блоки имеют много применений, помимо итераций. Они позволяют одной функции
выполнять процедуры настройки и удаления от имени другого раздела кода, поэтому
они часто представляют собой многоэтапные операции, такие как транзакции баз дан
ных или операции с файловой системой.
и выводит строку, опреде
Например, следующий код открывает файл
/etc/passwd
root:
open '/etc/passwd', 'r' do 1file1
file.each_line do llinel
print line if line.start with? 'root:'
end
end
ляющую учетную запись
Функция
open
открывает файл и передает его объект
IO
во внешний блок. После
того как блок завершит работу, файл откроется автоматически. Нет необходимости
в отдельной операции закрытия (хотя она существует, если вы хотите ее использовать),
и файл закрывается независимо от того, как завершается внешний блок.
Применяемая здесь постфиксная конструкция
пользовал язык
Perl.
i f может быть знакома тем, кто ис
Это хороший способ выразить простые условные обозначения без
сокрытия основного действия. Здесь сразу видно, что внутренний блок представляет со
бой цикл, который выводит некоторые строки.
В случае, если структура аргумента
line
функции
чаются необязательные круглые скобки. Оператор
и использует один метод вызова для обоих вариантов:
print (line) if line.start with? ('root: ')
print
не ясна, в нее снова вклю
i f имеет самый низкий приоритет
Часть
258
Как и в случае метода
sort ! ,
1. Основы
администрирования
знак вопроса представляет собой соглашение об именах
методов, возвращающих логические значения.
Синтаксис для определения именованной функuии несколько отличается от синтак
сиса для блока.
Этот тип гибкой обработки аргументов проявляется в стандарте языка
Ruby
и дру
включая стандартную библиотеку, как правило, де
Ruby,
гими способами. Библиотеки
лают все возможное, чтобы принять максимально широкий диапазон входных данных.
Скаляры, массивы и хеши часто ямяются равноправными аргументами, и многие функ
ции можно вызывать с помощью блоков или без них.
Регулярные выражения в языке
В отличие от
Python,
язык
Ruby
Ruby
имеет немного "синтаксического сахара" мя работы
с регулярными выражениями. Язык
Ruby
поддерживает традиционную
/ ... /
нотацию
для литералов регулярных выражений, а содержимое может содержать упрамяющие по
# { ) , похожие на строки с двумя
Ruby определен оператор =- (и его
следовательности символов
Кроме того, в языке
кавычками.
отрицание
!- )
дЛЯ провер
ки соответствия между строкой и регулярным выражением. Он возвращает либо индекс
первого совпадения, либо
nil,
если нет совпадения.
"Hermann Hesse" =- /H[aeiou]/
#=>О
Для того чтобы получить доступ к компонентам соответствия, явно вызовите метод
match
регулярного выражения. Он возвращает либо
nil
(если соответствий нет), либо
объект, к которому можно получить доступ в виде массива компонентов.
if m = /(лH\w*)\s/.match("Heinrich Hoffmeyer headed this heist")
puts m[O] # 'Heinrich'
end
Рассмотрим предыдущую программу для определения цвета костюма гнома на языке
if matches.any?
dwarf, color = matches.first
print "%s\'s dwarf suit is %s.\n" %
[ dwarf.to_s.sub(pat, ' \1 '), color.sub(pat, ' \1 ')
else
print "No dwarves or dwarf suits matched the pattern.\n"
end
Метод
select,
примененный к коллекции, создает новую коллекцию, включаю
щую только те элементы, для которых предоставленный блок имеет значение как
true.
В этом случае совпадения представляют собой новый хеш, содержащий только пары,
мя которых либо ключ, либо значение соответствует шаблону поиска. Поскольку
мы применили ленивый вызов (lazy), фильтрация на самом деле не произойдет, пока мы
не попытаемся извлечь значения из результата. Фактически этот код проверяет столько
пар, сколько необходимо мя поиска соответствия.
Вы заметили, что оператор
=-
сопостамения с образцом использовался на символах,
которые представляют имена гномов? Он работает, потому что оператор =- достаточно
умен, чтобы перед сопостамением преобразовать символы в строки. К сожалению, при
часть
260
1. Основы администрирования
использовании шаблона подстановки мы должны явно выполнить это преобразование
(с помощью метода
to_s);
метод
sub
определен только для строк, поэтому нам нужна
настоящая строка для его вызова.
Обратите внимание также на параллельное присваивание гнома и цвета. Метод
matches. first
возвращает двухэлементный массив, который
Ruby
распаковывает ав
томатически.
Оператор % для строк работает аналогично такому же оператору в языке
версия функции
sprintf
в языке
Ruby.
Python;
это
Здесь есть два компонента для заполнения, по
этому мы передаем значения как двухэлементный массив.
Язык
Ruby
Язык
Ruby
как фильтр
можно использовать без сценария, помещая изолированные выражения
в командную строку. Это простой способ сделать быстрые преобразования текста (прав
да, язык
Perl
по-прежнему намного лучше справляется с этой задачей).
Используйте параметры командной строки -р и -е для циклического обхода пото
ка
STDIN, выполните простое выражение для каждой строки (представленное как пере
$ _) и распечатайте результат. Например, следующая команда переводит строку
Только бесстрашный программист может использовать параметр
с параметром -ре для редактирования файлов на месте. Язык
Ruby
-i в сочетании
читает содержимое
файлов, представляет их строки для редактирования и сохраняет результаты в исход
ные файлы. Вы можете задать параметр
-i, который сообщает языку Ruby, как создать
-i. bak создает копию
резервную копию исходной версии каждого файла. Например,
файла
passwd с
именем
passwd. 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
Python
называется
или рiрЗ, в зависимости от того,
pip (pip2
установлены). Не все системы включают его по умолчанию.
Системы, которые этого не делают, обеспечивают доступ к нему как к отдельному паке
ту на уровне операционной системы. Как и в случае с пакетами языка
командами являются
pip search
и
pip install.
Опция
Ruby, основными
--user устанавливает пакеты
в ваш домашний каталог.
Утилиты
gem
и
pip
понимают зависимости между пакетами, по крайней мере на ба
зовом уровне. Когда вы устанавливаете пакет, вы неявно запрашиваете, чтобы все паке
ты, от которых он зависит, также были установлены (если они еще не инсталлированы).
В базовой среде
Ruby
или
Python
может быть установлена только одна версия пакета.
Если вы переустановите или обновите пакет, старая версия будет удалена.
У вас часто есть выбор для установки пакета
го языкового механизма
(gem
или
pip)
gem
или
pip
с помощью стандартно
или пакета уровня операционной системы, ко
торый хранится в стандартном хранилище вашего поставщика. Пакеты операционной
системы с большей вероятностью будут устанавливаться и запускаться без проблем, но
они с меньшей вероятностью будут обновляться. Ни один из вариантов не имеет явного
преимущества.
Соэдание воспроизводимых сред
Программы, библиотеки и языки развивают сложные сети зависимостей, поскольку они
эволюционируют вместе во времени. Производственный сервер может зависеть от десятков
или сотен таких компонентов, каждый из которых имеет свои собственные ожидания отно
сительно среды установки. Как определить, какая комбинация версий библиотеки создаст
гармоничную среду? Как убедиться, что конфигурация, которую вы тестировали в лабора
тории разработки, является той же самой, которая развертывается в облаке'? В общем, как
сделать так, чтобы управление всеми этими частями не было большой проблемой?
Языки
Python
и
Ruby
имеют стандартизированный способ для выражения зависимо
сти между пакетами. В обеих системах разработчики пакетов создают текстовый файл
в корне проекта, который перечисляет его зависимости. В языке
Gemfile,
а в языке
Python - requirements. txt.
Ruby
файл называется
Оба формата поддерживают гибкие
спецификации версий для зависимостей, поэтому пакеты могут заявить, что они совме
стимы с "любой версией пакета
Rails 4".
simplejson
версии
3
или выше" или
"Rails 3,
но не
Также можно указать точное требование к версии для любой зависимости.
Оба формата файлов позволяют указать источник для каждого пакета, поэтому зави
симости не обязательно должны распространяться через стандартный пакет хранилища.
Поддерживаются все распространенные источники: от веб-адресов до локальных фай
лов и хранилищ
GitHub.
Часть
262
Инсталлируйте пакет зависимостей
requirements. txt.
Хотя команда
pip
Python
1. Основы администрирования
с параметром
pip install -r
отлично справляется с определением спец
ификаций отдельных версий, она, к сожалению, не может самостоятельно решать
сложные отношения зависимостей между пакетами. Разработчикам иногда приходит
ся настраивать порядок, в котором пакеты упоминаются в файле
requirements. txt
для достижения удовлетворительного результата. Кроме того, новые выпуски пакетов
могуг нарушить равновесие версии, хотя это происходит редко.
Команда pip freeze распечатывает текущий пакет пакетов Python в формате
requirements. txt, указывая точную версию для каждого пакета. Эта функция может
быть полезна для репликации текущей среды на производственном сервере.
В мире Ruby прямым аналогом команды pip -r является команда gem install
-g Gemfile. Однако в большинстве случаев для управления зависимостями лучше ис
пользовать менеджер управления пакетами Bundler. Выполните команду gem install
bundler, чтобы установить его (если он еще не установлен в системе), а затем запустите
установку пакета из корневого каталога проекта, который вы настраиваете. 25
У менеджера
•
Bundler есть несколько
интересных особенностей.
Он действительно выполняет рекурсивное управление зависимостями, поэтому,
если существуют пакеты, которые взаимно совместимы и удовлетворяют всем
ограничениям, менеджер
•
Bundler может
найти его самостоятельно.
Он автоматически записывает результаты расчетов версий в файл
Gemfile. lock.
Bundler об
Поддержание этой контекстной информации позволяет менеджеру
рабатывать обновления в файле
на новую версию
Gemfile
Gemfile надежно и эффективно. При переносе
Bundler изменяет только пакеты, в которых он
менеджер
нуждается.
•
Поскольку файл
Gemfile. lock ассоциирован
со средой, запуск установки пакета
на сервере развертывания автоматически воспроизводит среду пакета, найденную
в среде разработки. 26
•
В режиме развертывания
(bundle install --deployment)
менеджер
Bundler
устанавливает отсутствующие пакеты в каталог локального проекта, помогая изо
лировать проект от любых будущих изменений. Затем можно использовать команду
bundle
ехес для запуска определенных команд в этой гибридной среде пакетов.27
Несколько сред
Команда
pip
и
дельных программ
bundle успешно осуществляют управление зависимостями для от
Python и Ruby, но что, если две программы на одном сервере имеют
противоречивые требования?
В идеале каждая программа в производственной среде будет иметь собственную би
блиотечную среду, которая не зависит от системы и всех других программ.
2 ~nакеты
в языке
Ruby
моrут содержать команды на уровне оболочки. Однако у них обычно
нет справочных страниu; для получения подробных сведений о пакете выполните команду
bundle help
2 ''Или,
или обратитесь к полной документаuии на сайте
bundler. io"
по крайней мере, это поведение по умолчанию. При необходимости в файле Gelllfile леrко
указывать различные требования к средам разработки и развертывания.
27 Некоторые
программные пакеты, такие как
Rails,
являются совместимыми с менеджером Buпdler
и моrут использовать локально установленные пакеты даже без выполнения команды ехес
bundle.
7. сценарии
Глава
Пакет
и командная оболочка
263
virtualenv: виртуальные среды для языка Python
Пакет
virtualenv
языка
Python
создает виртуальные среды, которые находятся
в своих собственных каталогах. 28 Чтобы настроить новую среду, после установки пакета
просто запустите команду
virtualenv с
именем пути.
$ virtualenv myproject
New python executaЫe in /home/ulsah/myproject/bin/python
Installing setuptools, pip, wheel ... done.
Каждая виртуальная среда имеет каталог Ьin/, содержащий двоичные файлы
Д11Я виртуальных сред
Python
и
PIP.
Когда вы запускаете один из этих двоичных файлов,
вы автоматически помещаетесь в соответствующую виртуальную среду. Установите па
кеты в среду, как обычно, запустив копию команды
pip
в виртуальной среде.
Для того чтобы запустить виртуализованную программу
Python
из демона
из сценария запуска системы, явно укажите путь к правильной копии
cron или
python. (В каче
стве альтернативы поместите путь в строку сценария.)
При интерактивной работе в оболочке можно запустить сценарий Ьin/activate
виртуальной среды, чтобы установить версии утилит
python
и
pip
в виртуальной сре
де по умолчанию. Сценарий перестраивает переменную РАТН вашей оболочки. Для того
чтобы покинуть виртуальную среду, используйте команду
deactivate.
Python. Во время создания
виртуальной среды вы можете установить связанный двоичный код Python с помощью па
раметра --python virtualenv. В результате будет устаномен бинарный файл Python.
Виртуальные среды привязаны к определенным версиям
RVM: менеджер enVironment для языка Ruby
В мире
Bundler
Ruby
все похоже, но несколько сложнее. Выше было указано, что менеджер
может кешировать локальные копии пакетов
Ruby
от имени конкретного при -
ложения. Это разумный подход при перемещении проектов в производство, но это не
так удобно для интерактивного использования. Он также предполагает, что вы хотите
использовать установленную версию
Ruby.
Те, кто хочет получить более общее решение, должны подумать о менеджере RVМ, слож
ном и довольно неудобном виртуализаторе среды, который использует несколько особенно
стей оболочки. СправеД11ивости ради отметим, что менеджер
RVM
ямяется чрезвычайно
отполированным примером "кривых костьиrей". На практике он работает плавно.
Менеджер
RVM
упрамяет как версиями
Ruby,
так и несколькими коллекциями па
кетов, и позволяет переключаться между ними на ходу. Например, команда
$ rvm
ruЬy-2.3.0@ulsah
активирует
Ruby версии 2.3.0 и набор пакетов под названием ulsah. Ссьmки на утилиты
gem теперь разрешаются в рамках указанных версий. Этот пример также ра
ботает Д11Я программ, устаноменных пакетами, такими как bundle и rails. К счастью,
ruby
или
упрамение пакетами не изменилось; просто используйте пакет или комплект, как обыч
но, и все вновь устаноменные пакеты автоматически попадут в нужное место.
Процедура установки менеджера
RVM
включает выбор сценария
Bash
из Интернета
и его локальное выполнение. В настоящее время используются команды
и в случае с другими командами, связанными с языком Pythoп, существуют версии команды
virtualenv с
числовыми суффиксами, которые поступают с определенными версиями Pythoп.
Часть
264
1. Основы администрирования
но все же проверьте текущую версию и криптографическую подпись на сайте
Обязательно проведите инсталляцию с помощью программы
если вы этого не сделаете, менеджер
RVM
sudo,
rvm. io. 29
как показано выше;
настроит частную среду в вашем домашнем
каталоге. (Это не страшно, но ничто в производственной системе не должно ссылать
ся на ваш домашний каталог.) Кроме того, вам нужно будет добавить авторизованных
пользователей
RVM
в группу
UN IX rvm.
RVM не используйте sudo при установке пакетов
или изменении конфигураций RVM. Менеджер RVM контролирует доступ через член
ство в группе rvm.
Менеджер RVM выполняет свою работу автоматически, манипулируя переменными
После первоначальной установки
среды оболочки и путем поиска. Следовательно, он должен быть включен в вашу среду
во время запуска оболочки при входе в систему. Когда вы устанавливаете
стемном уровне, он включает сценарий
/etc/profile. d.
rvm. sh
RVM
на си
с соответствующими командами в файл
Некоторые оболочки автоматически запускают эту заглушку. Если
это не так, необходимо явно выполнить команду
source,
которую вы можете добавить
в файлы запуска вашей оболочки:
source /etc/profile.d/rvm.sh
Менеджер
RVM
никак не изменяет исходную установку
Ruby,
в частности сценарии, на
чинающиеся с
#!/usr/bin/env ruby
Символы
#!
в стандартном
Ruby
видят только системные пакеты. Следующий вариант
более гибкий:
#!/usr/bin/env ruby
Он находит команду ruЬy в соответствии с контекстом
RVM
пользователя, который его
запускает.
Команда
rvm install
устанавливает новые версии языка
позволяет легко устанавливать несколько разных версий
собственным пакетам
Команда
Ruby
rvm install
Ruby. Эта функция RVМ
Ruby. Ее следует предпочесть
вашей операционной системы, которые редко обновляются.
загружает двоичные файлы, если они доступны. Если нет, она
устанавливает необходимые пакеты операционной системы, а затем строит
Ruby
из ис
ходного кода.
Вот как мы можем настроить развертывание приложения
но, совместимо с
Rails,
которое, как извест
Ruby 2.2. l.
$ rvm install ruЬy-2.2.1
Searching for binary rubies, this might take some time.
No binary rubies availaЫe for: ubuntu/15.10/x86_64/ruby-2.2.1.
Continuing with compilation. Please read 'rvm help mount' to get more
information on binary rubies.
Checking requirements for ubuntu.
Installing required packages: gawk, libreadlineб-dev, zliЬlg-dev,
libncurses5-dev, automake, libtool, bison, libffi-dev ............... .
Requirements installation successful.
Installing Ruby from source to: /usr/local/rvm/rubies/ruby-2.2.1, this
may take а while depending on your cpu(s) ...
29 См.
комментарии о том, почему наши команды не соответствуют рекомендациям
в разделе
1.10.
RVM,
Глава
7. Сценарии
и командная оболочка
Если вы установили
логе
/usr/local/rvm
Для поиска версии
265
как описано выше, система
RVM,
Ruby
устанавливается в ката
и доступна для всех учетных записей в системе.
следует использовать команду
RVM
rvm first known, которая,
rvm list выводит спи
как известно, знает, как выполнять загрузку и сборку. Команда
сок уже установленных и доступных для использования пакетов
создает комплект пакетов, если он еще не существует. Флаг
--default
уста
навливает эту комбинацию по умолчанию, а флаг -ruЬy-version записывает имена
интерпретатора
Ruby
. ruЬy-version
и комплекта пакетов в файлы
. ruЬy-gemset
и
в текущем каталоге.
Если файл
. *-version
существует, то менеджер
RVM
автоматически считывает
и оценивает их при работе со сценариями в этом каталоге. Эта функция позволяет каж
дому проекту указывать свои собственные требования и освобождает вас от необходи
мости помнить, что с ним связано.
Чтобы запустить пакет в запрошенной среде (как описано в файлах
и
. ruЬy-gemset),
rvm in
. ruЬy-version
выполните команду
/путь/к/каталогу
do
команда-запуска
аргументы_ запуска
...
Это удобный синтаксис для использования при запуске заданий из сценариев запу
ска или демона
cron.
или от конфигурации
Он не зависит от текущего пользователя, настраивающего
RVM
RVM,
текущего пользователя.
В качестве альтернативы можно указать явную среду для команды, например:
rvm ruby-2.2.l@myproject do
команда-запуска
Однако существует и третий вариант
-
аргументы_запуска
...
запустить двоичный код ruЬy изнутри обо
лочки, поддерживаемой RУМ для этой цели. Например, команда
/usr/local/rvm/wrappers/ruЬy-2.2.l@myproject/ruЬy
автоматически переносит вас в мир
7.8.
Ruby 2.2.l.
КОНТРОЛЬ ВЕРСИЙ С ПОМОЩЬЮ СИСТЕМЫ G1т
Ошибки неизбежны. Важно следить за изменениями конфигурации и кода, чтобы,
когда эти изменения вызовут проблемы, можно было легко вернуться к известному бла
гополучному состоянию. Системы контроля версий
-
это программные средства, кото
рые отслеживают, архивируют и предоставляют доступ к нескольким версиям файлов.
266
Часть
1. Основы
администрирования
Системы контроля версий решают ряд проблем. Во-первых, они определяют орга
низованный способ отслеживания истории изменений в файле, чтобы эти изменения
можно было понять в контексте и чтобы можно было восстановить более ранние вер
сии. Во-вторых, они расширяют концепцию версий выше уровня отдельных файлов.
Связанные группы файлов могут быть сопоставлены вместе с учетом их взаимозависи
мостей. Наконец, системы контроля версий координируют действия нескольких редак
торов, поэтому условия гонки не могут привести к тому, что чьи-либо изменения будут
окончательно потеряныJ 0 , и поэтому несовместимые изменения от нескольких редакто
ров не станут активными одновременно.
Самой популярной в настоящее время системой является
ная Линусом Торвальдсом
ходным кодом ядра
Linux
(Linus Torvalds).
Git, единолично создан
Git для управления ис
Линус создал систему
из-за его разочарования в системах контроля версий, которые
сушествовали в то время. В настоящее время он является таким же вездесущим и влия
тельным, как
Linux.
Трудно сказать, какие из этих изобретений Линуса оказали большее
влияние на мир.
Большинство современных программ разработано с помощью системы
Git,
и, как
результат, администраторы сталкиваются с ним ежедневно. Вы можете найти, загру
зить и внести вклад в проекты с открытым исходным кодом на
GitHub, GitLab и других
Git для отсле
сайтах коллективной разработки. Вы также можете использовать систему
живания изменений в сценариях, коде управления конфигурацией, шаблонах и любых
других текстовых файлах, которые необходимо отслеживать с течением времени. Мы
используем
Git
для отслеживания содержания этой книги. Он хорошо подходит для со
вместной работы и совместного использования, что делает его важным инструментом
для сайтов, которые охватывают
W
DevOps.
Для получения дополнительной информации о
Прелесть системы
Git
DevOps
см. раздел
31.1.
состоит в том, что у нее нет выделенного центрального хра
нилища. Чтобы получить доступ к хранилищу, клонируйте его (включая всю его исто
рию) и носите с собой, как улитка свою раковину. Ваши фиксации в хранилище
-
это
локальные операции, поэтому они выполняются быстро, и вам не нужно беспокоиться
о связи с центральным сервером.
Система
Git
использует интеллектуальную систему сжатия, чтобы снизить стоимость
хранения всей истории, и в большинстве случаев эта система достаточно эффективна.
Система
Git
отлично подходит для разработчиков, потому что они могут сворачи
вать исходный код на ноутбук и работать без подключения к сети, сохраняя при этом
все преимущества контроля версий. Когда придет время интегрировать работу несколь
ких разработчиков, их изменения могут быть интегрированы из одной копии хранили
ща в другую любым способом, который подходит для рабочего процесса организации.
Всегда можно развернуть две копии хранилища обратно в их общее состояние предка,
независимо от того, сколько изменений и итераций произошло после раскола.
Использование локального хранилища
версиями
-
Git -
большой шаг вперед в управлении
или, возможно, более точно, это большой шаг назад, но в хорошем смыс
ле. Ранние системы контроля версий, такие как
RCS
и
CVS,
использовали локальные
хранилища, но не могли обеспечивать совместную работу, слияние изменений и не-
10 Например, предположим, что системные администраторы Алиса и Боб оба редактируют один и
тот же файл и каждый из них вносит некоторые изменения. Алиса сохраняет файл первой. Когда
Боб сохраняет свою копию файла. он перезаписывает версию Алисы. После того как Алиса выйдет
из редактора, ее изменения полностью и бесследно исчезнут.
Глава
7. Сценарии
и командная оболочка
267
зависимую разработку проектов. В настоящее время установка файлов под контролем
версий
-
это быстрая, простая и локальная операция. В то же время все расширенные
возможности совместной работы
Git
доступны для использования в соответствующих
ситуациях.
Система
Git
обладает сотнями функций и может быть довольно сложной в использо
вании. Тем не менее большинство пользователей
Git
обойдутся лишь несколькими про
стыми командами. Особые ситуации лучше всего обрабатывать путем поиска в
Google
"git undo last commit"). В первую оче
сайт Stack Overflow и найти дискуссию,
описания того, что вы хотите сделать (например,
редь
Google,
конечно же, предложит посетить
которая точно соответствует вашей ситуации. Прежде всего, не паникуйте. Даже если
вам кажется, что вы испортили хранилище и удалили результаты работы за последние
несколько часов, в системе
пользовать флан
reflog
Git,
скорее всего, есть скрытая копия. Вам просто нужно ис
и найти ее.
Прежде чем вы начнете использовать систему
укажите свое имя и адрес элек
Git,
тронной почты:
$ qit confiq --qlobal user.name "John Q. Ulsah"
$ qit confiq --qlobal user.email "ulsah@admin.com"
Эти команды создают ini-файл конфигурации
ществует. Более поздние команды
Система
Git
git
Git -1 .gitconfig,
если он еще не су
читают этот файл для настройки конфигурации.
предоставляет пользователям широкие возможности для настройки рабоче
го процесса.
Простой пример
Git
Мы разработали простое хранилище примеров для поддержки некоторых сценариев
оболочки. На практике вы можете использовать
Git
для отслеживания кода управления
конфигурацией, шаблонов инфраструктуры, специальных сценариев, текстовых докумен
тов, статических веб-сайтов и всего, что вам нужно для работы в течение долгого времени.
gi t ini t создает инфраструктуру
/home/bwhaley/scripts. После того как
"hel\o, world", добавьте команду git add. Она копирует
В приведенной выше последовательности команда
хранилища, создавая каталог
.git
вы создадите исходный сценарий
в каталоге
ero в "индекс" Git, который является промежуточной областью для предстоящей фиксации.
Индекс - это не просто список файлов для фиксации; это дерево файлов, каждое из
которых является таким же реальным, как текущий рабочий каталог и содержимое храни-
Часть
268
1. Основы администрирования
лища. Файлы в индексе имеют содержимое, и в зависимости от того, какие команды вы вы
полняете, это содержимое может отличаться как от хранилища, так и от рабочего каталога.
Команда
git add на самом деле просто означает "ер из рабочего каталога в индекс".
gi t commi t вводит содержимое индекса в хранилище. Для каждой фикса
Команда
ции требуется сообщение журнала. Флаг -m позволяет включить сообщение в команд
ной строке. Если вы оставите это, команда
gi t
запустит для вас редактор.
Теперь внесите изменения и проверьте их в хранилище.
$ vi super-script.sh
$ git commit super-script.sh -m 11 маdе the script more super"
[master 67514fl] Made the script more super
1 file changed, 1 insertions(+), О deletions(-)
Именование модифицированных файлов в командной строке
обычное использование
Git
gi t commi t
обходит
индекса и создает вариант, который включает только изме
нения в указанные файлы. Существующий индекс остается неизменным, и система
Git
игнорирует любые другие файлы, которые могут быть изменены.
Если изменение связано с несколькими файлами, существуют несколько вариантов.
Если вы точно знаете, какие файлы были изменены, вы всегда можете их перечислить
в командной строке, как показано выше. Если вы ленивы, то можете выполнить команду
-а, чтобы система
git commit
Git добавляла все
измененные файлы в индекс перед вы
полнением фиксации. Однако у этого последнего варианта есть пара подводных камней.
Во-первых, могут быть изменены файлы, которые вы не хотите включать в фикса
цию. Например, если у сценария
super-script. sh
был файл конфигурации, и вы из
менили этот файл конфигурации для отладки, вы можете не захотеть перенести изме
ненный файл обратно в хранилище.
Вторая проблема заключается в том, что команда
git commit
-а выбирает только
изменения в файлах, которые в настоящее время находятся под управлением системы
контроля версий. Он не отображает новые файлы, которые вы, возможно, создали в ра
бочем каталоге.
Для обзора состояния системы
Git
вы можете выполнить команду
get status.
Эта
команда сообщает вам о новых, измененных и индексированных файлах. Например,
предположим, что вы добавили сценарий
Система
Git
more-scripts/another-script. sh.
может показать следующее.
$ git status
On branch master
Changes not staged for commit:
(use "git add ... " to update what will Ье committed)
(use "git checkout -- ... " to discard changes in working directory)
modified: super-script.sh
Untracked files:
(use "git add ... " to include in what will Ье committed)
more-scripts/
tmpfile
no changes added to commit (use "git add" and/or "git commit -а")
Сценарий
another-script. sh не указан по имени, потому что система Git еще не
more-scripts, который его содержит. Вы можете видеть, что сценарий
super-script. sh был изменен, а также увидеть файл tmpfile, который, вероятно, не
должен быть включен в хранилище. Вы можете выполнить команду gi t diff superscript. sh, чтобы увидеть изменения, внесенные в сценарий. Команда gi t предлагает
видит каталог
команды для следующих операций, которые вы можете выполнить.
глава
7. Сценарии
269
и командная оболочка
Предположим, вы хотите отследить изменения в файле
super-script. sh
another-script. sh.
$ git colllllli.t super-script.sh -m "The most super change yet"
Created commit бf785Зс: The most super change yet
1 files changed, 1insertions(+), О deletions(-)
отдельно
от вашего нового файла
Для того чтобы искоренить файл
tmpfile из системы Git, создайте или отредакти
. gi tignore и поместите в него имя файла. Это заставляет систему Git игно
рировать файл tmpfile раз и навсегда. Шаблоны в тоже работают.
руйте файл
$ echo tmpfile
>> .gitignore
Наконец, зафиксируйте все сделанные изменения.
$ git add .
$ sudo git commit -m "Ignore tmpfile; Add another-script.sh to the repo"
Created commit 32978еб: Ignore tmpfile; add another-script.sh to the repo
2 files changed, 2 insertions(+), О deletions(-)
create mode 100644 .gitignore
create mode 100755 more-scripts/another-script.sh
Обратите внимание на то, что сам файл
. gi tignore
становится частью управляемого
набора файлов, который обычно вы хотите. Зачастую приходится повторно добавлять фай
лы, которые уже находятся под контролем, поэтому команда gi t
add -
это простой способ
сказать: "Я хочу, чтобы образ нового хранилища выглядел как рабочий каталог, за исключе
нием того, что указано в
. gi tignore".
В этой ситуации нельзя просто выполнить команду
-а, потому что она не найдет файлы
gi t commi t
файлы являются новыми Д11Я системы
Ловушки
another-script. sh и . gi tignore;
Git и поэтому должны быть явно добавлены.
эти
Git
Для того чтобы заставить вас думать, что система
Git
управляет файлами разреше
ний, а также их содержимым, она показывает вам режимы файлов при добавлении но
вых файлов в хранилище. Это неправда; система
Git
не отслеживает режимы, владель
цев или время модификации.
Система
Git
отслеживает бит исполнения. Если вы выполняете сценарий с установ
ленным битом исполнения, любые будущие клоны также исполняются. Однако не сле
дует ожидать, что система
Git
будет отслеживать право собственности или статус "только
Д11Я чтения". Следствием является то, что вы не можете рассчитывать на использование
системы
Git
для восстановления сложных иерархий файлов в ситуациях, когда важны
права собственности и разрешения.
Другим следствием является то, что в хранилище
Git
никогда нельзя включать простые
текстовые пароли и другие секреты. Они не только открыты Д11Я всех, кто имеет доступ
к хранилищу, но также могут бьпь непреднамеренно распакованы в форме, доступной миру.
Коллективное кодирование с помощью системы
Git
Появление и быстрый рост сайтов коллективной разработки, таких как
и
GitLab,
GitHub
является одним из самых важных тенденций в новейшей компьютерной исто
рии. Миллионы проектов программного обеспечения с открытым исходным кодом соз
даются и прозрачно управляются огромными сообществами разработчиков, которые
используют все мыслимые языки. Программное обеспечение никогда не было проще
создавать и распространять.
Часть
270
GitHub
и
GitLab -
это, по сути, хранилища
Git
1. Основы
администрирования
с множеством дополнительных функ
ций, связанных с коммуникацией и рабочим процессом. Хранилище может создать лю
бой человек. Хранилища доступны как благодаря команде
gi t,
так и в Интернете. Веб
интерфейс дружелюбен и предлагает функции поддержки сотрудничества и интеграции.
Опыт коллективного кодирования может быть несколько пугающим для новичков,
но на самом деле это не сложно, как только будут поняты некоторые основные термины
и методология.
это имя по умолчанию, назначенное первой ветви в новом хранилище.
• "Master" -
Большинство программных проектов по умолчанию используют это имя в каче
стве основной линии разработки, хотя у некоторых главная ветвь может отсутство
вать. Главной ветвью обычно управляют, чтобы поддерживать текущий, но рабо
тоспособный код; разработка нового кода происходит в другом месте. Последняя
фиксация называется вершиной главной ветви.
•
Ветвление
(fork)
в системе
GitHub
представляет собой моментальный снимок хра
нилища в определенный момент времени. Ветвления возникают, когда у пользо
вателя нет разрешения на изменение основного хранилища, но он хочет внести
изменения, либо для дальнейшей интеграции с основным проектом, либо для соз
дания совершенно отдельного пути разработки.
•
Запрос на включение
(pull request) -
это запрос на объединение изменений из
одной ветви или ветвления в другую. Они читаются сторонними разработчиками
целевого проекта и могут быть приняты для включения кода других пользователей
и разработчиков. Каждый запрос на включение также является нитью дискуссии,
поэтому комментировать предполагаемые обновления кода могут как владелец,
так и любой другой человек.
•
Разработчик
(committer)
и специалист по эксплуатации
(maintainer) -
это лицо,
у которого есть доступ к хранилищу для записи. Для крупных проектов с откры
тым исходным кодом этот очень желанный статус предоставляется только дове
ренным разработчикам, которые имеют долгую историю вкладов.
Вам часто придется обращаться в хранилище
GitHub
или
GitLab,
чтобы найти или
обновить часть программного обеспечения. Убедитесь, что вы просматриваете главное
хранилище, а не случайное ветвление. Обратите внимание на ближайшую метку "ответ
вление от" и следуйте за ней.
Будьте осторожны при оценке нового программного обеспечения с этих сайтов.
Ниже приведены несколько вопросов, которые стоит обдумать, прежде чем запускать
случайную часть нового программного обеспечения на своих компьютерах.
•
•
•
•
Сколько участников принимали участие в разработке?
Означает ли история фиксации, что разработка является недавней и регулярной?
Какова лицензия и совместима ли она с потребностями вашей организации?
На каком языке написано программное обеспечение, и знаете ли вы, как им
управлять?
•
Достаточно ли документации для эффективного использования программного
обеспечения?
Большинство проектов имеют определенную стратегию ветвления, на которую они
полагаются, чтобы отслеживать изменения программного обеспечения. Некоторые сто
- более
Git Row, раз-
ронники настаивают на строгом соблюдении выбранной ими стратегии, а другие
снисходительны. Одной из наиболее широко используемых является модель
Глава
7. Сценарии
и командная оболочка
работанная Винсентом Дриссеном
на сайте
goo. gl/GDaF.
ero разработки,
271
(Vincent Driessen);
дополнительную информацию см.
Прежде чем вносить свой вклад в проект, ознакомьтесь с методами
чтобы помочь специалистам, которые его сопровождают.
Прежде всего, помните, что разработчики с открытым исходным кодом часто не по
лучают никакой платы. Участвуя в коллективной разработке и поддерживая проекты,
они ценят терпение и вежливость.
7.9. ЛИТЕРАТУРА
•
BRooкs, FREDER1cк Р.
Reading,
•
JR. The Mythical Man-Month: Essays
МА: Addisoп-Wesley,
оп
Software Engineering.
1995.
СнлсоN, Sсотт, AND SтRAuв, BEN. Pro Git, 2nd edition. 2014. git-scm. com/book/
en/v2. Исчерпывающая книга о Pro Git, свободно опубликованная по лицензии
Creative Commons.
Оболочки и сценарии оболочки
Roвв1Ns, ARNOLD, AND №LsoN Н. F. ВЕЕВЕ. Classic Shell Scrlpting. Sebastopol, СА:
O'Reilly Media, 2005. Книга, посвященная традиционному (и переносимому) диа
лекту оболочки Boume. Она также содержит довольно много информации об ути
литах sed и awk.
• PoWERs, SнELLEY, JERRY РЕЕК, Т1м O'REILLY, AND М1кЕ LotJКIDES. Unix Power Too/s, (Зrd
Edition), Sebastopol, СА: O'Reilly Media, 2002. Классическая книга о системе UNIX,
•
охватывающая много вопросов, в том числе сценарии для оболочки
sh
и работу
с командной строкой. Некоторые разделы несколько устарели, но материал, каса
ющийся оболочек, остается актуальным.
•
SoвELL, МдRК
G. А Practical Guide to Linux Commands, Editors, and Shell Programming.
Upper Saddle River, NJ: Prentice На\\, 2012. Книга заслуживает внимания, посколь
ку в ней описываются оболочки
•
Sноттs, W1LL1лм Е.,
Francisco,
СА:
tcsh
и
bash.
JR. The Linux Command Line:
No Starch Press, 2012.
А
Complete lntroduction. San
Книга посвящена оболочке
bash,
но в ней
также есть материал об интерактивной работе и программировании. Большая
UNIX и Linux.
• Вшм, R1снлRо, AND CнR1sпNE BRESNAHAN. Linux Command Line and Shell Scripting
ВiЬ/е (Зrd Edition). lndianapo\is, IN: John Wiley & Sons, Inc. 2015. Книга посвящена,
часть материала относится к системам
в основном, оболочкам, в частности оболочке
bash.
• CooPER, MENDEL. Advanced Bash-ScriptingGuide. www.tldp.org/LDP/abs/html.
Свободно распространяемая и легко доступная в Интернете книга. Несмотря на ее
название, новички ее легко поймут благодаря множеству хороших примеров.
ник информации о регулярных выражениях с учетом всевозможных диалектов.
• KRUMINS, PEТERIS. Perl Oпe-Liпers: 130 Prograтs That Get
СА: No Starch Press, 2013.
Thiпgs Dопе.
San Francisco,
Python
• SwEIGART, AL. Аиtотаtе the Boriпg Stиff with Pythoп: Practical Prograттiпg for Total
Begiппers. San Francisco, СА: No Starch Press, 2015. Удачное введение в програм
мирование на языке Python 3 и программирование в целом. Содержит множество
примеров системного администрирования.(Эл СвЕйГАРТ. Автоматизация рутинных
задач с помощью Pythoп: практическое руководство для начинающих, пер. с англ.,
изд. "Диалектика", 2016.)
• PtLGRIM, MARK. Dive /пtо Pythoп. Berkeley, СА: Apress, 2004. Классическая книга
о языке Python 2, свободно доступная на веб-сайте di veintopython. net.
• P1LGRIM, МАRк. Dive /пtо Pythoп 3. Berkeley, СА: Apress, 2009. Dive lnto Python updated
for Python 3. Книга свободно доступна на веб-сайте di veintopythonЗ. net.
• Luтz, МлRк. Learпiпg Pythoп, 5th Editioп. O'Reilly, 2013. Фундаментальная книга о
языке Python.(MAPK ЛУГц. Изучаем Pythoп, 5-е издание, в двух томах, пер. с англ"
изд. "Диалектика", 2019.)
• RАмлLно, Luc1лNo. F/иепt Pythoп. Sebastopol, СА: O'Reilly Media, 2015. Advanced,
idiomatic Python 3.
• BEAZLEY, Dлvю, AND BRtAN К. JoNES. Pythoп Cookbook (3rd Editioп), Sebastopol, СА:
O'Reilly Media, 2013. Covers Python 3.
• Gtтт, Nолн, AND JEREMY М. JoNEs. Pythoп for Uпix апd Liпих Systeт Adтiпistrators,
Sebastopol, СА: O'Reilly Media, 2008.
Ruby
AND Уuк1н1Rо Млтsuмото. The RиЬу Prograттiпg Laпgиage.
O'Reilly Media, 2008. Классическая, исчерпывающая и хорошо на
писанная книга о языке Ruby из первых рук. Она уже немного устарела и не учи
тывает Ruby 2.0 и более новые версии; однако языковые различия между ними яв
• FLANAGAN,
Sebastopol,
Dлvю,
СА:
ляются минимальными.
The Well-Groипded Rиbyist (2пd Editioп). Shelter lsland, NY: Manning
2014. Не бойтесь названия, которое может отпугнуть новичков; это
хорошая, основательная книга о языке Ruby 2.1.
• Тномлs, DAVE. Prograттiпg RиЬу 1.9 & 2.0: 1he Pragmatic Prograттer's Gиide (4th Editioп).
Pragmatic Вookshelf, 2013. Classic and frequently updated.
• FuLтoN, HAL. The RиЬу Way: Solиtioпs апd Techпiqиes iп RиЬу Prograттiпg (3rd Editioп).
Upper Saddle River, NJ: Addison-Wesley, 2015. Еще один классический и современ
ный справочник по языку Ruby, с легким философским уклоном.
•
ВLАск, Dлvю А.
PuЫications,
глава 8
Управление учетными
записями пользователей
Современные вычислительные среды состоят из физического оборудования, облач
ных систем и виртуальных хостов. Гибкость этой гибридной инфраструктуры порождает
растущую потребность в централизованном и структурированном управлении учетны
ми записями. Системные администраторы должны понимать как традиционную модель
учетных записей, используемую
UNIX и Linux,
так и способы расширения этой модели
для интеграции с такими службами каталогов, как
LDAP
и
Microsoft Active Directory.
Правильное управление учетными записями является ключевым фактором безопас
ности системы. Редко используемые учетные записи, а также учетные записи с легко
угадываемыми паролями являются основными целями для злоумышленников. Даже
если вы используете автоматизированные инструменты вашей системы для добавления
и удаления пользователей, важно понимать изменения, которые осуществляют эти ин
струменты. По этой причине мы начинаем обсуждение управления учетными записями
с простых файлов, которые необходимо изменить, чтобы добавить пользователей авто
номного компьютера. В последующих разделах мы рассмотрим команды управления бо
лее высокого уровня, которые поставляются с нашими демонстрационными примерами
операционных систем, и файлы конфигурации, которые контролируют их поведение.
В большинстве систем также есть простые инструменты с графическим пользователь
ским интерфейсом для добавления и удаления пользователей, но они, как правило, не под
держивают дополнительные функции, такие как пакетный режим или расширенная лока
лизация. Эти инструменты достаточно простые, поэтому мы не считаем целесообразным
детально анализировать их работу и в этой главе будем использовать командную строку.
274
Часть
1.
Основы администрирования
В этой главе мы сосредоточимся исключительно на добавлении и удалении пользо
вателей. Многие темы, связанные с управлением учетными записями, описаны в других
главах (здесь вы найдете соответствующие ссылки).
РАМ) для шифрования паролей и обеспечения их стойкости, описаны в главе
(см. раздел
17.3).
Хранилища паролей описаны в главе
•
•
Службы каталогов, такие
ве
17
(см. раздел
27 (см. раздел 27.4).
как OpenLDAP и Active Directory,
рассматриваются в гла
17.2).
Наконец, политические и правовые вопросы яаляются основными темами главы
•
31.
8.1. Основы УПРАВЛЕНИЯ УЧЕТНЫМИ ЗАПИСЯМИ
По существу, пользователь предстааляет собой всего лишь число, 32-битное целое чис
ло без знака, известное как идентификатор пользователя,
ID
или
UID.
Почти все, что свя
зано с упраалением учетными записями пользователей, вращается вокруг этого числа.
Система определяет интерфейс прикладного программирования (через стандартные
подпрограммы библиотеки С), который осущесталяет прямое и обратное отображение
между идентификаторами
Например, функция
UID и более полными наборами сведений о пользователях.
getpwuid () принимает UID в качестве аргумента и возвращает
соответствующую запись, содержащую имена пользователя и его домашнего каталога.
Аналогично функция
getpwnam ()
просматривает эту же информацию по имени учетной
записи.
Традиционно эти библиотечные функции получали аргументы непосредственно из
текстового файла
/etc/passwd.
Со временем они начали поддерживать дополнитель
ные источники информации, такие как сетевые информационные базы данных (напри
мер,
LDAP)
и файлы с защитой от чтения, в которых зашифрованные пароли можно
было бы хранить более надежно.
Эти уровни абстракции (которые часто устанааливаются в файле
nsswi tch. conf)
позволяют функциям более высокого уровня функционировать без достоверного знания
используемого метода управления базой данных. Например, когда вы входите в систе
му как
dotty,
процесс регистрации
меняет к этому имени функцию
(Window Server, login, getty или что-то еще) при
getpwnam () , а затем сравнивает пароль, который вы
вводите, с его зашифрованной записью, возвращаемой библиотекой, независимо от его
фактического источника.
Мы начинаем с подкаталога
/etc/passwd,
который по-прежнему поддерживается
везде. Другие варианты воспроизводят эту модель, если не по форме, то по духу.
W
Дополнительную информацию о файле
8.2. ФАйЛ
Файл
nsswitch. conf см.
в разделе 17.З.
/Eтc/PASSWD
/etc/passwd содержит список
пользователей, которые известны системе. Его
можно расширить или заменить службой каталогов, поэтому его можно считать полным
и достоверным только в автономных системах.
Традиционно зашифрованный пароль каждого пользователя также хранился в фай
ле
/etc/passwd,
который был доступен для чтения. Однако пояаление более мощных
процессоров повысило вероятность взлома этих открытых паролей. В ответ системы
Глава
8. Управление учетными
записями пользователей
275
UNIX и Linux переместили пароли в отдельный файл (/etc/master. passwd в FreeBSD
и /etc/shadow в Linux), который защищен от чтения. В наши дни сам файл passwd
содержит только формальную запись, чтобы отметить прежнее местоположение поля
для ввода пароля (х в
Linux
*
и
в
FreeBSD).
В процессе регистрации пользователя система обращается к файлу / etc/passwd
в поисках идентификатора пользователя и его домашнего каталога, а также другой ин
формации. Каждая строка файла описывает одного пользователя и содержит семь следу
ющих полей, разделенных двоеточиями:
•
•
регистрационное имя;
шифрованный пароль или "заполнитель" пароля (вопросы применения шифрованных паролей описаны далее в этом разделе);
•
•
•
•
•
идентификатор пользователя
UID;
идентификатор группы по умолчанию
поле
GECOS
GID;
(полное имя, номер офиса, рабочий и домашний телефоны);
m Дополнительную информацию о файле nsswi tch. conf см. в разделе 17.3.
Если пользовательские учетные записи совместно используются с помощью службы
LDAP, в файле passwd появляются специальные записи, которые
каталогов, например
начинаются с символа"+" или"-". Эти записи сообщают системе, как интегрировать
/etc/passwd. Эта интеграция также мо
/ etc/nsswi tch. conf.
рассмотрим поля файла /etc/passwd более подробно.
данные службы каталогов в содержимое файла
жет быть реализована в файле
В следующих разделах мы
Регистрационное имя
Регистрационные имена (называемые также именами пользователей) должны быть
уникальными и в зависимости от системы могут иметь ограничения на длину и набор
символов. В настоящее время во всех версиях систем
шает
UNIX и Linux эта длина
не превы
32 символа.
Пользовательские имена не могут содержать двоеточия и символы новой строки, по
скольку эти символы применяются в качестве разделителей полей и записей соответ
ственно в файле
passwd.
В зависимости от системы на пользовательские имена могут
быть наложены и другие ограничения. В системе
Ubuntu
эти ограничения наиболее
слабые, поскольку они допускают имена, начинающиеся или целиком состоящие из
чисел и других специальных символов.' По многочисленным причинам, которые было
бы слишком долго объяснять, мы рекомендуем ограничивать допустимый диапазон ре
гистрационных имен алфавитно-цифровыми символами, использовать только нижний
регистр и начинать имена с буквы.
Регистрационные имена чувствительны к регистру. Нам неизвестны случаи. ког
да смешение регистров в именах приводило бы к возникновению проблем, но имена,
1 По
какой-то непостижимой причине допустимый набор символов в
состоящие из строчных букв, считаются традиционными, к тому же их проще вводить.
Если, например, такие регистрационные имена, как
john
и
John,
будут принадлежать
различным людям, проблемы обязательно возникнут.
Следует выбирать такие регистрационные имена, которые легко запомнить, поэтому
имя, состоящее из случайной последовательности букв, является не самым удачным ва
риантом. Поскольку регистрационные имена часто используются в адресах электронной
почты, полезно определить стандартную процедуру их формирования. Пользователям
должна быть предоставлена возможность делать обоснованные предположения о реги
страционных именах друг друга. Имена, фамилии, инициалы и сочетания этих элемен
тов
вот приемлемые варианты для схем формирования имен. 2
-
Любая жестко заданная схема в конечном счете приводит к появлению дубликатов
или слишком длинных имен, поэтому иногда придется делать исключения. Выберите
стандартный способ разрешения конфликтов, добавив, например, в конец имени цифру.
В крупных организациях в адресах электронной почты часто используются полные
имена (например,
John. Q.
РuЫ
ic@mys i te. com),
благодаря чему регистрационные
имена скрываются от внешнего мира. Это прекрасная идея, но, чтобы облегчить работу
администраторам, необходимо установить четкое и понятное соответствие между реги
страционными именами и реальными именами пользователей.
В заключение отметим: необходимо, чтобы имя пользователя на всех компьютерах
было одинаковым. Это удобно как самому пользователю, так и администратору.
Зашифрованные пароли
Исторически системы шифровали пароли пользователей с помощью алгоритма
По мере увеличения вычислительной мощности эти пароли стали тривиальными
DES.
для взлома. Затем системы перешли на скрытые пароли и криптографию на основе алго
ритма MD5. Теперь, когда в алгоритме MD5 были обнаружены значительные недостатки,
текущим стандартом стало хеширование паролей с помощью криптографической "соли"
на основе алгоритма
SHA-512
(см. документ
Guide to Cryptography на веб-сайте owasp. org).
Наши иллюстративные системы поддерживают множество алгоритмов шифрования,
но все они по умолчанию соответствуют алгоритму
SHA-512.
Если вы не обновляете си
стемы из более старых версий, вам не нужно обновлять выбор алгоритма .
•
(ё'Ф
В системе
FreeBSD
алгоритм, заданный по умолчанию, можно модифици
ровать с помощью файла
В системах
Deblan
и
/etc/login. conf.
Ubuntu
алгоритм, заданный по умолчанию, можно было
модифицировать с помощью файла
/etc/login.defs,
но после появления
подключаемых модулей аутентификации РАМ, этот подход стал устаревшим.
Политики установления паролей по умолчанию, включая выбор алгоритма
хеширования, можно найти в файле
~
/etc/pam.d/common-passwd.
В системах алгоритм шифрования паролей можно по-прежнему установить
RHEL ~ в файле /etc/login. defs с помощью команды authconfig, как показано
ниже:
$ sudo authconfig --passalgo=sha512 --update
2 Стандарт RFC5321 требует, чтобы локальная часть адреса (т.е. часть перед знаком @) считалась
чувствительной к регистру. Остальная часть адреса обрабатывается в соответствии со стандартами
DNS, который нечувствителен к регистру. К сожалению, это различие является тонким, и оно не
реализуется повсеместно. Помните также, что многие устаревшие системы электронной почты
возникли до появления сообщества IE~F.
Глава
8. Управление учетными
записями пользователей
277
Изменение алгоритма шифрования паролей не приводит к обновлению существу
ющих паролей, поэтому пользователи должны вручную изменить свои пароли, прежде
чем новый алгоритм вступит в действие. Для того чтобы аннулировать старый пароль
и принудительно внести обновления, используйте команду
$ chage -d
имя_пользователя
О
Качество пароля
-
еще одна важная проблема. Теоретически более длинные пароли
более безопасны, как и пароли, содержащие разнотипные символы (например, пропис
ные буквы, знаки препинания и цифры).
Большинство систем позволяют устанавливать стандарты построения паролей
для пользователей, но имейте в виду, что пользователи могут умело обойти эти требо
вания, если найдут их чрезмерными или обременительными. Стандарты, используемые
нашими иллюстративными системами, приведены в табл.
Таблица
Ш Дополнительную информацию о выборе паролей см. в разделе
Требования к качеству пароля
27.3.
это вопрос дебатов, но мы рекомендуем вам опреде
-
лить приоритет по сложности. 3 Двенадцать символов
-
это минимальная длина для бу
дущего пароля; обратите внимание, что это значительно больше, чем длина, заданная
по умолчанию в любой системе. В вашей организации могут существовать общие стан
дарты качества пароля. Если это так, отложите эти настройки.
Если вы решили обойти свои системные инструменты для добавления пользовате
лей и вместо этого изменить файл
см. раздел
8.6),
/etc/passwd
вручную (выполнив команду
vipw -
чтобы создать новую учетную запись, поместите в зашифрованное
поле пароля символ
* (FreeBSD)
или х
(Linux).
Эта мера предотвратит несанкциони
рованное использование учетной записи до тех пор, пока вы или пользователь не уста
новите реальный пароль.
Шифрованные пароли имеют постоянную длину
вола для
MD5
и
13
символов для
DES)
(86
символов для
SHA-512, 34
сим
независимо от длины незашифрованного паро
ля. Пароли шифруются в сочетании со случайной "солью", так что одному паролю могут
соответствовать разные зашифрованные формы. Если два пользователя выбирают один
и тот же пароль, этот факт обычно не может быть обнаружен путем проверки зашифро
ванных паролей.
Пароли, зашифрованные алгоритмом
SHA-256 -
с
MD5
в файле теневого пароля, всегда начина
$1$ или $md5$. Пароли Blowfish
$5$, а пароли SHA-512 - с $6$.
ются с символов
начинаются с символов
'Дополнительную информаuию по этой проблеме см. по адресу
strength. png.
$2$,
пароли
xkcd. сот/ comi cs /password _
Часть
278
1. Основы администрирования
Идентификатор пользователя
Ш Дополнительную информацию об учетной записи пользователя
По определению идентификатор пользователя
root
root
см. в разделе
3.1.
равен нулю. Большинство си
стем также определяют псевдопользователей, например Ьin и
daemon,
как владельцев
команд или файлов конфигурации. Эти фиктивные регистрационные имена принято
указывать в начале файла
/etc/passwd,
присваивая им низкие идентификаторы
UID
и назначая для них фиктивную оболочку (например, /Ьin/false), чтобы никто не мог
войти в систему под этими именами.
Для того чтобы зарезервировать достаточно места для будущих фиктивных пользо
вателей, мы рекомендуем назначать
UID
для реальных пользователей начиная с \ООО
или выше. (Желаемый диапазон для новых
присваивают идентификаторы
вому реальному пользователю
UID
можно указать в файлах конфигурации
Linux
UID, начиная с 1000. Система FreeBSD присваивает пер
UID, равный 1001, а затем добавляет единицу для каждо
с помощью параметров команды
useradd.)
По умолчанию наши системы ссылок
го нового пользователя.
Не используйте
UID
повторно, даже когда пользователи покидают вашу организа
цию и вы удаляете их учетные записи. Эта предосторожность предотвращает путани
цу, которая может возникнуть при дальнейшем восстановлении файлов из резервных
копий, в которых пользователи могут быть идентифицированы с помощью
UID,
а не
по регистрационному имени.
Идентификаторы
должны быть уникальными в масштабе всей организации.
UID
Иначе говоря, конкретный
UID должен
ссылаться на одно и то же регистрационное имя
и одного и того же человека на всех машинах, которые разрешено использовать этому
человеку. Неспособность поддерживать уникальные
безопасности в таких системах, как
NFS,
UID
может привести к проблемам
а также к путанице, когда пользователи пере
ходЯт из одной рабочей группы в другую.
Трудно поддерживать уникальные
UID,
если группы машин управляются разными
людьми или организациями. Эти проблемы носят технический и политический харак
тер. Лучшее решение
-
иметь центральный сервер базы данных или каталог, который
содержит запись для каждого пользователя и обеспечивает уникальность.
Более простая схема
диапазон
UID
-
назначить каждой группе внутри организации собственный
и позволить каждой группе управлять собственным диапазоном. Это ре
шение ограничивает пространство
UID,
но не устраняет параллельную проблему с уни
кальными регистрационными именами. Независимо от вашей схемы, основной задачей
является согласованность подхода. Если согласованность невозможна, уникальность
U1D становится
второй по важности целью.
Популярной системой управления и распространения информации об учетных за
писях, которая зарекомендовала себя в крупных организациях, является протокол
Идентификатор группы по умолчанию
Как и идентификатор пользователя
(UID),
идентификатор группы
(GID)
являет
ся 32-битовым целым числом. Идентификатор О зарезервирован для группы с именем
root, system
или
wheel.
Как и в случае идентификаторов пользователей, системы ис
пользуют несколько предопределенных групп для собственных нужд. Увы, в этом вопро
се согласованности среди коллег
-
производителей систем не наблюдается. Например,
Глава
8. Управление
учетными записями пользователей
279
GJD, равный 1, в системах Red Hat, CentOS
Ubuntu, Deblan и GJD, равный 7, - в системе FreeBSD.
группа Ьin имеет идентификатор
равный
в системах
2, -
и
GID,
В те далекие времена, когда компьютеры были еще дорогим удовольствием, группы
использовались для учета машинного времени, чтобы время работы центрального про
цессора, время, затраченное на регистрацию, и использованное дисковое пространство
оплачивал соответствующий отдел. В настоящее время группы используются, в основ
ном, для организации совместного доступа к файлам.
m Дополнительную информацию о каталогах с установленным битом setgid см. в раз
деле
5.5.
Группы определяются в файле
ле
/etc/passwd
/etc/group,
а поле идентификатора группы в фай
задает стандартный ("фактический") идентификатор
GID
на момент
регистрации пользователя в системе. Этот идентификатор не играет особой роли при
определении прав доступа; он используется лишь при создании новых файлов и ката
логов. Новые файлы обычно включаются в фактическую группу своего владельца, но
если вы хотите разделять файлы с другими участниками проектной группы, не забудьте
вручную изменить для этих файлов владельца группы.
При этом следует иметь в виду, что если у каталогов установлен бит
или файловая система смонтирована с опцией
grpid,
setgid (02000)
новые файлы включаются в груп
пу родительского каталога.
Поле
GECOS
Это поле иногда используется для хранения персональной информации о каждом
пользователе. Оно является наследием некоторых из ранних версий системы
использовавших для разных целей семейство операционных систем
UNIX,
General Electric
Comprehensive Operating Systems. Оно не имеет четко определенного синтаксиса.
В принципе структура поля G ECOS может быть произвольной, а ее элементы разделя
ются запятыми и размещаются в следующем порядке:
•
•
•
•
полное имя (часто используется только это поле);
номер офиса и здания;
рабочий телефон;
домашний телефон.
lШ Дополнительную информацию о базе данных
Информацию, содержащуюся в поле
chfn.
LDAP см
GECOS,
в разделе
17.2.
можно изменять с помощью команды
Эта команда используется для ведения и обновления списка телефонных номе
ров, но ею часто злоупотребляют: например, пользователь может изменить информа
цию так, что она станет нецензурной или некорректной. В некоторых системах мож
но установить ограничения, указав, какие поля может модифицировать команда
chfn.
Администраторы сетей большинства университетских городков совсем отключают ко
манду
chfn.
Во многих системах команда
chfn
"понимает" только файл
passwd,
по
этому, если для управления регистрационной информацией вы используете базу данных
LDAP
или какую-либо иную службу каталогов, команда
chfn
может не работать вовсе.
Домашний каталог
Войдя в систему, пользователь попадает в свой домашний каталог. Именно в домаш
них каталогах оболочки регистрации ищут информацию, связанную с учетной записью,
Часть
280
1. Основы
псевдонимы оболочки и переменные окружения, а также ключи
администрирования
SSH,
сертификаты сер
веров и другие параметры.
Следует иметь в виду, что если домашние каталоги смонтированы вне файловой си
стемы, то в случае проблем с сервером или с самой сетью они могут оказаться недо
ступными. Если на момент регистрации этот каталог отсутствует, выводится сообщение
вроде
no home directory (домашний каталог отсутствует) и пользовательские данные
/. 4 В качестве альтернативы регистрацию можно отключить со
помещаются в каталог
всем с учетом системной конфигурации. Более подробно домашние каталоги описыва
ются в разделе
8.6.
Регистрационная оболочка
В качестве регистрационной оболочки, как правило, задается интерпретатор команд,
но в принципе это может быть любая программа. По умолчанию для системы
используется интерпретатор
версия оболочки
sh,
а для системы
Linux -
интерпретатор
FreeBSD
bash (GNU-
sh).
В некоторых системах пользователи могут менять интерпретатор с помощью коман
ды
chsh,
но, подобно
chfn,
эта команда может не работать, если для управления ре
гистрационной информацией вы используете базу данных
службу каталогов. Если вы используете файл
LDAP
/etc/passwd,
или какую-либо иную
системный администратор
всегда может заменить интерпретатор пользователя, отредактировав файл
мощью программы
vipw.
8.3. ФАйлы
/Eтc/sНADow
passwd с
по
Файл скрытых паролей доступен для чтения только суперпользователю и предназна
чен для хранения зашифрованных паролей подальше от любопытных глаз и программ
взлома. В нем также содержится учетная информация, которая отсутствует в исход
ном файле
/etc/passwd.
В настоящее время механизм скрытых паролей используется
по умолчанию практически во всех системах.
Файл
shadow
не включает в себя файл
тически при изменении файла
shadow.
passwd,
и последний не генерируется автома
Оба файла необходимо хранить независимо друг
от друга (или использовать команду наподобие
ния файлами). Как и
/etc/passwd,
файл
useradd для автоматического управле
/etc/shadow содержит одну строку для каж
дого пользователя. Каждая строка состоит из
•
•
•
•
•
•
9
полей, разделенных двоеточиями:
регистрационное имя;
зашифрованный пароль;
дата последнего изменения пароля;
минимальное число дней между изменениями пароля;
максимальное число дней между изменениями пароля;
количество дней до истечения срока действия пароля, когда выдается предупреж
дение;
4 Это
сообщение появляется при регистрации в системе через консоль или терминал, но не через
экранный диспетчер, такой как
xdm, gdm
или
kdm.
В последнем случае пользователь вообще
будет немедленно выведен из системы, поскольку программа-диспетчер не сможет осуществить
запись в нужный каталог (например,
... / . gnome).
Глава
•
8. Управление
учетными записями пользователей
281
количество дней по истечении срока действия пароля, когда учетная запись аннулируется;
•
•
дата истечения срока действия учетной записи;
зарезервированное поле, в настоящее время пустое.
Лишь первые два поля обязательно должны быть заполнены. Поля дат в файле
/ etc/ shadow задаются
в виде числа дней (а не секунд), прошедших с
1 января 1970 года,
UNIX и Linux. 5
что не является стандартным способом вычисления времени в системах
Типичная запись выглядит так.
Приведем более подробное описание некоторых полей.
•
Регистрационное имя совпадает с именем из файла
записи файлов
•
/etc/passwd.
Оно связывает
passwd и shadow.
Зашифрованный пароль идентичен тому, который ранее хранился в файле
/etc/
passwd.
•
Третье поле содержит дату последнего изменения пользователем своего пароля.
Это поле обычно заполняется командой
•
passwd.
В четвертом поле задано количество дней, спустя которые пользователь сможет
снова изменить пароль. Это не позволяет пользователям немедленно возвращать
ся к привычным паролям после их обязательного изменения. Такая возможность
кажется нам опасной, если в течение указанного времени будет обнаружено на
рушение безопасности системы. Поэтому мы рекомендуем устанавливать данное
поле равным нулю.
•
В пятом поле задано максимальное число дней между двумя изменениями паро
ля. С помощью этой установки администраторы заставляют пользователей менять
свои пароли (подробнее механизм устаревания паролей описан в разделе
В системе
Linux
27.4).
максимальное время жизни пароля определяется суммой значе
ний данного и седьмого (льготный период) полей.
•
В шестом поле задано количество дней, оставшихся до момента устаревания паро
ля, когда программа
login
должна предупреждать пользователя о необходимости
сменить пароль.
•
В восьмом поле задан день, в который истекает срок действия учетной записи
(считая от
1 января 1970
года). По прошествии этой даты пользователь не смо
жет зарегистрироваться в системе, пока администратор не сбросит значение поля.
Если поле оставлено пустым, учетная запись всегда будет активной. 6
•
Чтобы установить поле даты истечения срока, можно использовать команду
usermod
•
(даты здесь должны быть в формате гггг-мм-дд).
Девятое поле зарезервировано на будущее. 7
Теперь, когда назначение полей понятно, вернемся к рассмотренному выше примеру.
этом вы можете преобразовать секунды в дни с помощью команды
6 Седьмое
поле в книге не описано.- Примеч. ред.
7 Возможно,
это поле никогда не будет использовано.
expr 'date+'iss' / 86400.
Часть
282
В этой записи говорится о том, что пользователь
пароль
19
июня
2017
1. Основы администрирования
millert
последний раз менял свой
года. Следующий раз пароль должен быть изменен через
180 дней.
За две недели до этого пользователь начнет получать предупреждения о необходимости
сменить пароль. Учетная запись не имеет срока действия.
С помощью утилиты
и
passwd,
pwconv
можно согласовать содержимое файлов
выявляя и удаляя пользователей, не указанных в файле
8.4. ФАйлы
/Етс/МАSТЕR. PASSWD и /Етс/
LOGIN. CONF в СИСТЕМЕ
•
shadow
passwd.
FREEBSD
Появление модулей РАМ и наличие аналогичных команд управления поль
зователями в системах
FreeBSD
и
Linux
сделали управление учетными за
писями относительно согласованным между платформами, по крайней мере
на самом верхнем уро1ше. Однако между ними существуют некоторые раз
личия на уровне реализации.
Файл
/etc/master .passwd
В системе
FreeBSD
"реальным" файлом паролей является
который доступен только для чтения. Файл
/etc/passwd
/etc/master.passwd,
предназначен для обратной
совместимости и не содержит паролей (вместо этого он содержит символы
*
в качестве
заполнителей).
Чтобы изменить файл паролей, выполните команду
vipw.
Эта команда вызывает ваш
редактор для копии /etc/шaster. passwd, затем инсталлирует новую версию и повтор
но генерирует файл
/etc/passwd,
ляется стандартной для всех систем
в системе
FreeBSD,
чтобы отразить все изменения. (Команда
UNIX
и
Linux,
vipw
яв
но особенно важно использовать ее
потому что файлы с двойным паролем должны оставаться синхро
низированными (см. раздел
Кроме полей файла
8.6).)
passwd файл master. passwd
содержит три дополнительных
поля. К сожалению, по умолчанию они зажаты между полем
GID
и полем
GECOS,
заданными по умолчанию, поэтому форматы файлов напрямую не совместимы.
Дополнительные три поля перечислены ниже:
•
•
•
класс регистрации;
время изменения пароля;
время истечения срока действия пароля.
Класс регистрации (если он указан) относится к записи в файле
/etc/ login. conf.
Этот класс определяет ограничения потребления ресурсов и управляет множеством дру
гих параметров (см. следующий раздел).
Поле времени изменения пароля отражает возраст пароля. Он содержит время в секун
дах с момента
UNIX,
после которого пользователь будет вынужден изменить свой пароль.
Вы можете оставить это поле пустым, указав, что пароль будет действовать вечно.
Время истечения срока действия учетной записи означает время и дату (в секундах,
как и для момента истечения срока действия пароля), по прошествии которого истекает
срок действия учетной записи пользователя. Пользователь не может войти в систему по
сле этой даты, если поле не будет сброшено администратором. Если это поле оставлено
пустым, учетная запись останется действительной.
Глава
8. Управление учетными записями
Файл
пользователей
283
/ etc/ loqin. conf
Файл
в системе
/ etc/ loqin. conf
Free BS D
задает параметры учетной записи
для пользователей и групп пользователей. Его формат состоит из пар ключ-значение
с двоеточием и булевых флагов.
Когда пользователь входит в систему, поле входа в каталог
деляет, какую запись из файла
/ etc/ loqin. conf применять.
/etc/master.passwd опре
Если в записи пользователя
master. passwd не указан класс входа в систему, используется класс по умолчанию.
Элемент loqin. conf может установить любое из следующих значений.
• Ограничения ресурсов (максимальный размер процесса, максимальный размер
файла, количество открытых файлов и т.д.).
•
Сеансовые ограничения (с какого момента и насколько долго разрешены регистрационные имена).
•
•
•
•
•
•
Переменные окружения по умолчанию.
Пути ПО умолчанию (РАТН, МАNРАТН и т.д.).
Расположение файла с сообщениями для всех пользователей.
Хост и контроль доступа на основе подсистемы ТТУ.
Стандартная маска для команды
umask.
Контроль учетных записей (в основном заменяется модулем РАМ
pam_passwdqc).
Следующий пример демонстрирует переопределение нескольких значений по умолчанию. Он предназначен для назначения системных администраторов.
sysadrnin:\
:ignorenologin:\
:requirehome@:\
:maxproc=unlimited:\
:openfiles=unlimited:\
:tc=default:
Пользователи, имеющие класс регистрации
если их имя указано в файле
sysadmin, могут войти в систему, даже
/var/run/noloqin и у них может не быть рабочего домаш
него каталога (этот параметр позволяет регистрацию, когда система
Пользователи класса
sysadmin
NFS
не работает).
могут запускать любое количество процессов и открывать
любое количество файлов.~ Последняя строка записывает информацию в запись
Хотя система
FreeBSD
defaul t.
имеет разумные стандартные значения, может возникнуть
необходимость обновить файл
/ etc/ loqin. conf,
чтобы установить предупреждения
об истечении времени ожидания или об истечении срока действия пароля. Например,
чтобы установить время ожидания равным
15
мин. и вьщавать предупреждения за семь
дней до истечения срока действия паролей, необходимо добавить следующие элементы
default:
warnpassword=7d:\
: idletime=l5m:\
в запись
Если вы изменяете файл
/ etc/ loqin. conf,
вы также должны выполнить следую
щую команду для компиляции ваших изменений в хешированную версию файла, кото
рую система фактически использует в повседневной работе:
$
cap_lllkdЬ
/etc/loqin.conf
8 nо-прежнему
существуют технические ограничения на общее количество процессов и открытых
файлов. которые может подцерживать ядро, но искусственно установленных ограничений нет.
284
Часть
8.5. ФАйЛ
Файл
1. Основы
администрирования
/Eтc/GROUP
/etc/group
содержит имена UNIХ-групп и списки членов каждой группы.
Вот как выглядит фрагмент файла
group
из системы
FreeBSD.
wheel:*:O:root
sys:*:З:root,Ьin
operator:*:5:root
Ьin:*:7:root
ftp:*:14:dan
staff:*:20:dan,ben,trent
nobody:*:65534:lpd
Каждая строка представляет одну группу и содержит следующие четыре поля:
•
•
•
•
имя группы;
зашифрованный пароль или заполнитель;
идентификатор группы;
список членов, разделенный запятыми (пробелов быть не должно).
Как и в файле
/etc/passwd, поля разделяются двоеточиями.
8 символов из соображений совместимости,
не должна превышать
Длина имени группы
хотя во многих систе
мах такого ограничения нет.
Несмотря на возможность установить пароль группы, позволяющий любому пользо
newgrp, она используется редко.
gpasswd; а его зашифрованная форма
/etc/gshadow.
вателю присоединиться к группе, выполнив команду
Пароль можно установить с помощью команды
в системе
Linux сохраняется
в файле
Имена групп и их идентификаторы должны быть одинаковыми на всех компьютерах,
получающих совместный доступ к файлам через сетевую файловую систему. Этого труд
но достичь в гетерогенной среде, поскольку в разных операционных системах использу
ются разные идентификаторы дпя одних и тех же групп.
Если в файле
/etc/passwd пользователь объявлен членом определенной группы
/etc/group - нет, пользователь все равно включается в груп
по умолчанию, а в файле
пу. На этапе регистрации членство в группе проверяется по обоим файлам, но лучше все
же согласовывать их содержимое.
В некоторых старых системах ограничивается количество групп, к которым может
принадпежать пользователь. В современных ядрах систем
Linux и FreeBSD ограничений
нет вообще.
Для того чтобы избежать конфликтов, связанных с идентификаторами стандартных
групп, рекомендуем выбирать идентификаторы локальных групп, начиная со значе
ния
1000.
Согласно традиции
UNIX
новые пользователи добавляются в группу, название ко
торой отражает их категорию, например
"students"
или
"finance".
Однако следует учи
тывать, что подобная традиция повышает вероятность доступа пользователей к файлам
друг друга из-за неаккуратной установки прав.
Чтобы этого избежать, рекомендуем создавать дпя каждого пользователя уникальную
группу с помощью утилит
useradd и adduser (т.е. группу,
имя которой совпадает с именем
пользователя и содержит только данного пользователя). Это соглашение намного проще
выполнить, чем обеспечить согласование между идентификаторами пользователя и группы.
Чтобы пользователи могли обмениваться файлами с помощью группового механизма,
со:щайте отдельные группы. Идея персональных групп состоит в том, чтобы не препятство-
Глава
8. Управление
учетными записями пользователей
285
вать использованию групп как таковых, а просто создать более ограничительную группу
по умолчанию для каждого пользователя, чтобы файлы не бьmи предоставлены для совмест
ного пользователя непреднамеренно. Можно также ограничить доступ к вновь созданным
umask по умолчанию вашего пользователя в
/etc/profile или /etc/bashrc (см. раздел 8.6).
файлам и каталогам, установив маску
запуска по умолчанию, например
m
Дополнительную информацию о программе
sudo см.
в разделе
файле
3.2.
Членство в группах также может служить маркером для других контекстов или при
вилегий. Например, вместо того, чтобы вводить имя пользователя каждого системного
администратора в файл
sudoers,
вы можете настроить программу
члены группы "admiп" автоматически имели привилегии
sudo
так, чтобы все
sudo.
В системе Liпux для создания, изменения и удаления групп предусмотрены
л
•
команды
groupadd, groupmod
Система
FreeBSD
pw.
и
groupdel .
для выполнения всех этих функций использует команду
Чтобы добавить пользователя
dan
в группу
staff,
а затем проверить,
что изменение было правильно реализовано, необходимо выполнить следу
ющие команды:
ВРУЧНУЮ: ОСНОВНЫЕ ДЕЙСТВИЯ
Прежде чем создавать учетную запись для нового пользователя в крупной коммерче
ской компании, правительственном учреждении или учебном заведении, важно заста
вить его подписать соглашение о правилах работы в системе. (Как?! У вас нет такого
соглашения? Немедленно прочтите материал в разделе
31.9,
чтобы узнать, для чего оно
нужно и как его составлять.)
У пользователей нет веских причин подписывать такое соглашение, поэтому в инте
ресах администратора убедить их сделать это, чтобы иметь рычаги влияния. После того
как учетная запись создана, добиться подписи будет трудно, так что лучше получить ее
заранее. Если существует такая возможность, прежде чем создавать учетную запись, по
лучите подпись пользователя на бумажном документе.
Процесс подключения нового пользователя состоит из ряда этапов, определяемых
системными требованиями; два связаны с формированием пользовательской среды,
а еще несколько этапов может понадобиться для целей системного администрирования.
•
Обязательные этапы:
•
отредактировать файлы
ме
•
FreeBSD),
passwd
и
shadow
(или файл
master. passwd
в систе
чтобы создать учетную запись пользователя;
добавить запись нового пользователя в файл
/etc/group
(в действительности
это не необходимо, а желательно);
•
•
задать первоначальный пароль;
создать для нового пользователя домашний каталог, назначив его владельца
с помощью команды
•
chown
и задав режим доступа с помощью команды
настроить роли и права доступа (если вы используете
RBAC;
chmod;
см. чуть ниже).
286
1. Основы администриравания
часть
Пользовательские этапы:
•
скопировать в домашний каталог пользователя стандартные конфигурацион
•
ные сценарии.
Административные этапы:
•
получить подпись пользователя на соглашении о правилах работы;
•
•
•
проверить правильность создания учетной записи;
добавить контактную информацию о пользователе, а также сведения о статусе
учетной записи в административную базу данных.
Для выполнения этого списка действий необходимо иметь сценарий или утилиту,
и во всех наших иллюстративных системах они предусмотрены в виде команд
и
adduser
useradd.
Редактирование файлов passwd и
Ручное редактирование файлов
passwd
и
qroup
group
уязвимо для ошибок и неэффек
тивно, поэтому мы рекомендуем инструменты высокого уровня, такие как
adduser, usermod, pw
и
useradd,
chsh.
Если вам придется добавлять пользователя вручную, используйте команду
vipw,
shadow (в системе FreeBSD - файл master.
passwd). По умолчанию выбирается редактор vi, но эту установку можно изменить, за
дав новое значение переменной среды EDITOR. 9 Более важно то, что команда vipw бло
чтобы отредактировать файлы
passwd
и
кирует редактируемый файл, позволяя только одному пользователю редактировать его.
Это не допускает никаких конфликтов между действиями разных пользователей.
В системах
Linux
после редактирования файла
passwd
команда
vipw
авто
матически напомнит пользователю о необходимости отредактировать файл
shadow. Для
•
этого используется команда
vipw -s .
В системе
FreeBS О команда vipw редактирует файл master. passwd, а не
/etc/passwd. После внесения изменений команда vipw запускает выпол
нение команды pwd_mkdЬ для генерирования производного файла passwd
и двух хешированных версий mas ter . pas swd (одна из них содержит за
шифрованные пароли, доступные для чтения только пользователю root,
а вторая не содержит паролей и доступна для чтения любому пользователю).
Например, выполнение команды
vipw и добавление
whi tney.
Sather, АМАТН 3-27,
следующей строки приведет
к определению учетной записи с именем
whitney:*:lOOЗ:lOOЗ::O:O:Whitney
х7919,:
/home/staff/whitney:/bin/sh
Обратите внимание на звездочку в поле зашифрованного пароля. Она предотвращает
использование учетной записи, пока не будет установлен настоящий пароль с помощью
команды
passwd (см.
следующий раздел).
Затем отредактируйте
/etc/group,
выполнив команду
vigr.
Добавьте строку
для новой персональной группы, если ваша организация использует их, и добавьте имя
пользователя для каждой группы, в которой пользователь должен иметь членство.
''Если сначала выполнить команду
vipw (или vigr), системы Ubuntu и Deblan предложат вам
vim.basic, vim. tiny, nano или ed. Если впоследствии вы передумаете,
команду select-editor.
выбрать одну из команд
выполните
Глава
8. Управление учетными
записями пользователей
287
Как и в случае с командой
vipw, использование команды vigr гарантирует, что из
/etc/group, являются корректными и атомарными. После
сеанса редактирования команда vigr должна попросить вас выполнить команду vigr -s
для редактирования файла теневой группы (gshadow). Если вы не хотите устанавливать
менения, внесенные в файл
пароль для группы, что необычно, вы можете пропустить этот шаг.
•
Чтобы внести изменения в файл
ется команда
/etc/group,
в системе
FreeBSD
использу
pw groupmod.
Задание пароля
W Правила выбора удачных паролей приведены в разделе 27.З.
Установите пароль для нового пользователя с помощью следующей команды.
$ sudo passwd
новое-имя-пользователя
В некоторых автоматизированных системах при добавлении новых пользователей
необязательно вводить начальный пароль. Задание пароля в таких случаях происходит
при первой регистрации. Несмотря на удобство, этот вариант приводит к образованию
огромной дыры в системе безопасности; тот, кто может угадать новые регистрационные
имена (или узнать их в файле
/etc/passwd),
может выполнить "пиратские" действия
по отношению к учетным записям, прежде чем соответствующие пользователи получат
•
возможность зарегистрироваться
.
Помимо других функций команда
pw
в системе
FreeBSD
генерирует и уста
навливает случайные пароли пользователей.
$ sudo pw usermod raphael -w random
Password for 'raphael' is:
lnЗtcYuls
Мы не являемся горячими сторонниками использования случайных паролей. Однако
они бывают полезными в качестве временных паролей, которые подлежат замене после
использования.
Создание домашнего каталога пользователя
и инсталляция конфигурационных файлов
Новые домашние каталоги пользователей создаются с помощью команд
и
adduser,
useradd
но вы вряд ли захотите выполнять двойную проверку прав доступа и файлов
запуска для новых учетных записей.
Домашний каталог создать легко. Если вы забыли это сделать при создании учетной
записи нового пользователя, исправить положение можно с помощью простой команды
mkdir.
Вам также понадобится установить права владения на новый каталог и права до
ступа к нему, но лучше всего сделать это после инсталляции локальных конфигурацион
ных файлов.
Имена таких файлов традиционно начинаются с точки и заканчиваются суффиксом
rc
(сокращение от
системы
CTSS.
"run command" -
команда запуска)
-
"отголосок" операционной
Предшествующая точка заставляет команду lв не включать эти файлы
в листинги каталогов, если только не указана опция -а. Мы рекомендуем предоставлять
стандартные файлы запуска для всех интерпретаторов команд, которые популярны в ва
ших системах, чтобы пользователи по умолчанию продолжали работать в корректной
среде даже при смене командной оболочки. Наиболее часто встречающиеся конфигура
ционные файлы перечислены в табл.
8.2.
1. Основы администрирования
Часть
288
Таблица
8.2.
Распространенные конфигурационные файлы
Команда
Имя фама
Применение
Все
• loqin_сом
Настройки параметров регистрации пользователя по умолчанию
sh
.profile
Установка пути поиска, типа терминала и среды
Ьаsь•
. bashrc
Установка типа терминала (если это необходимо)
. bash_profile
Установка опций программ Ьiff и
(FreeBSD)
оболочки
mesq
Установка переменных окружения
Установка псевдонимов команд
Установка пути поиска
Установка атрибута umask для управления правами дос~упа
Установка переменной CDPATH для поиска имен файлов
Установка переменных Р s 1 (строка приглашения) и HI s TCONTROL
csh/ tcsh
Считывается всеми зарегистрированными экземплярами интерпретатора
bash также читает файлы .profile или /etc/profile в режиме эмуляции sh. Файл .bash_
profile считывается командами регистрации, а файл . bashrc считывается с помощью интерактивных оболочек
без регистрации.
Образцы файлов запуска традиционно хранятся в каталоге
самое удачное место для хранения модифицированных копий.
skel -
Конфигурационные файлы и каталоги, перечисленные для настольных сред
и
KDE,
на уrилиту
gconf,
предназначенную для хранения предпочтений в выборе приложений
для программ под управлением
ном реестре
W
GNOME
представляют собой лишь вершину айсберга. В частности. обратите внимание
GNOME
(подобно тому, как это реализовано в систем
Windows).
Дополнительную информацию об атрибуте uшask см. в разделе 5.5.
Не забудьте задать разумное значение
umask
(рекомендуем
077, 027
или
022,
в зави
симости от "дружелюбности" среды и размеров организации). Если вы не используете
индивидуальные группы, рекомендуем установить для
umask
значение
077,
поскольку
оно предоставляет владельцу полный доступ, а для группы и вообще для всех осталь
ных
-
никакого доступа.
В зависимости от интерпретатора, в каталоге
/etc
могут содержаться системные
конфигурационные файлы, обрабатываемые раньше пользовательских. Например,
интерпретаторы
bash
и
sh
читают файл
/ etc/profile
до начала обработки файла
Глава
8. Управление учетными
289
записями пользователей
~ /. profile и ~ /. bash_profile. В эти файлы стоит помещать стандартные установки,
необходимые для функционирования вашего хоста, но следует иметь в виду, что пользо
ватели могут переопределять свои установки в собственных конфигурационных файлах.
Информацию о других интерпретаторах можно найти в документации (см. соответству
ющие mаn-страницы).
Linux сохраняет фрагменты загрузочных файлов
/ etc/profile. d. Хотя имя каталога происходит из соглаше
принятых для оболочки sh, файл /etc/profile. d может фактически
По соглашению, система
в каталоге
ний,
включать фрагменты для нескольких разных оболочек. Конкретные целе
вые оболочки различаются суффиксами имен файлов(*.
В оболочке не встроена поддержка файла
profile. d;
исполняются сценарием запуска по умолчанию в каталоге
/etc/profile
в случае оболочки
sh
или
sh, *. csh
и т.д.).
фрагменты просто
/etc
(например,
bash).
Разделение файлов запуска, заданных по умолчанию, на фрагменты облегчает мо
дульность и позволяет программным пакетам включать собственные значения по умол
чанию на уровне оболочки. Например, фрагменты
но раскрасить вывод команды
ls,
colorls. *указывают,
как правиль
чтобы сделать его нечитаемым на темном фоне.
Установка прав доступа и владения
После установки домашнего каталога переходите к пользователю и убедитесь, что он
имеет соответствующие права доступа. Команда
$ sudo chown -R
новый_пользователь:новая_группа
-новый_пользователь
должна надлежащим образом установить права владения. Обратите внимание на невоз
можность использования команды
$ sudo chown -R
новый_пользователь:новая_группа
-новый_пользователь/.*
применительно к файлам, имена которых начинаются с точки, поскольку новый_
пользователь станет владельцем не только собственных файлов, но и родительского
каталога"
.. "
(например,
/home).
Это распространенная и опасная ошибка.
Конфигурирование ролей и административных привилегий
Управление доступом на основе ролей
(role-based access control - RBAC)
позволя
ет "подогнать" системные права к отдельным пользователям и обеспечивается на мно
RBAC не является традиционной частью моде
Linux, но если на вашем хосте она используется, то
гих наших примерах систем. Политика
ли управления доступом
UNIX
или
конфигурация ролей должна быть частью процесса добавления пользователей. Модель
RBAC
подробно описана в разделе
3.4.
W Подробнее о законах SOX и GLBA написано в главе 31.
(Sarbanes-Oxley Act), закон о преемствен
(Health Insurance Portabllity
Грэмма-Лича-Блайли (Gramm-Leach-8\i\ey
Принятые в США закон Сарбейнса-Оксли
ности страхования и отчетности в области здравоохранения
and Accountabllity Act - НIРАА) и закон
Act}, предназначенные, в частности, для защиты
информации заказчика, полученной или
используемой финансовыми организациями США, от кражи, неавторизованного доступа
либо злоупотребления, усложнили многие аспекты системного администрирования в кор
поративной сфере, включая управление пользователями. Поэтому использование ролей
290
Часть
1. Основы
администрирования
может быть вашим единственным жизнеспособным вариантом, позволяющим выполнить
некоторые требования, устанавливаемые законами
SOX,
НIРАА и
GLBA.
Заключительные действия
Для того чтобы удостовериться, что новая учетная запись сконфигурирована надле
жащим образом, завершите сеанс работы (т.е. выйдите из системы}, а затем снова во
йдите в систему под именем нового пользователя и выполните следующие команды.
$ pwd
$ ls -la
#
#
Для проверки домашнего
каталога
Для проверки владельца/группы файлов
конфигурации
Вам необходимо уведомить новых пользователей об их регистрационных именах
и начальных паролях. Многие хосты отправляют эту информацию по электронной
почте, но из соображений безопасности это не приветствуется. Делайте это при лич
ном контакте или по телефону. Но если вам приходится добавлять сразу
на университетские компьютеры
CS-1,
500
новичков
переложите эту задачу на преподавателей! Если
вам приходится распространять пароли через электронную почту, проследите за тем,
чтобы срок их действия истекал через несколько дней, если они не используются и не
были изменены.
W
Подробнее о заключении письменных контрактов с пользователями можно прочитать
в разделе
31 .9.
Если в вашей организации требуется, чтобы пользователи подписывали соответству
ющее соглашение, убедитесь в реализации этого действия до создания их учетных запи
сей. Такая проверка предотвратит возможные упущения и усилит правовую основу санк
ций, которые, возможно, вам придется позже применить. Кроме того, это подходящий
момент для того, чтобы ознакомить пользователей с дополнительной документацией
о локальных настойках.
Напомните новым пользователям о необходимости немедленного изменения их па
ролей. При желании это можно обеспечить путем установки действия паролей в течение
некоторого короткого времени. Еще один вариант состоит в создании сценария, кото
рый бы проверял новых пользователей и удостоверялся в том, что их зашифрованные
пароли были изменены 10 •
Если вы знаете пользователей лично, то в такой среде относительно несложно про
следить, кто использует систему и с какой целью. Но если в подчинении администра
тора большой и часто меняющийся штат пользователей, необходим более формальный
способ контроля учетных записей. Ведение базы данных с контактной информацией
и сведениями о статусе учетных записей поможет в случае необходимости, легко выяс
нить, кто есть кто и зачем тому или иному пользователю понадобилась учетная запись.
8.7. ДОБАВЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ
СЦЕНАРИЕВ:
С ПОМОЩЬЮ
USERADD, ADDUSER И NEWUSERS
Во всех иллюстративных системах сценарии
useradd
и
adduser
реализуют одну и ту
же базовую процедуру, описанную выше. Но ее можно сконфигурировать под конкретную
среду. К сожалению, в каждой системе существуют свои представления о том, что именно
"'Поскольку один и тот же пароль может иметь множество зашифрованных предстамений, этот
метод проверяет только сам факт изменения пользователем своего пароля, а не то, что пароль
реально был заменен другим паролем.
глава
291
записями пользователей
8. Управление учетными
следует настраивать, где следует реализовать настройки и каково должно быть стандарт
ное поведение, поэтому мы описываем эти подробности в соответствующих разделах.
В табл.
8.3
приведены команды и файлы конфигурации, имеющие отношение
к управлению пользователями.
Таблица
Команды и файлы конфиrурации для управления пользователями
292
Эта команда создает следующую запись в файле
hilbert:x:lOOS:ЗO:David
1. основы
администрирования
passwd:
Hilbert:/home/math/hilbert:/bin/tcsh
Назначенный идентификатор
UID
превышает наивысший
в системе, а соответствующая запись в файле
shadow
UID,
существующий
имеет вид:
hilbert::14322:0:99999:7:0::
Символ (символы) заполнения пароля в файлах
passwd и shadow различаются в за
useradd также добамяет пользователя
hilbert в соответствующие группы в файле /etc/group, создает каталог /home/math/
hilbert с надлежащими владельцами и заполняет его файлами из каталога /etc/skel.
висимости от операционной системы. Команда
Команда
adduser
в системах
Deblan
и
Ubuntu
В дополнение к семейству команд uвeradd, линия
Deblan также
предостав
ляет несколько сценариев более высокого уровня для этих команд в виде
adduвer и deluвer. Эти дополнительные команды настраиваются в файле
/etc/adduвer. conf, где можно указать такие параметры:
•
правила размещения домашних каталогов: по группам, по имени пользователя
и т.д.;
•
•
•
•
•
настройки разрешения для новых домашних каталогов;
диапазоны
UID
и
GID для
системных и общих пользователей;
возможность создания отдельных групп для каждого пользователя;
квоты диска (только булевские, к сожалению);
сопостамение имен пользователей и групп с помощью регулярных выражений.
Другие типичные параметры команды
useradd,
такие как правила для паролей,
устанамиваются как параметры модуля РАМ, который выполняет обычную аутенти
фикацию пароля. (Подключаемые модули аутентификации РАМ обсуждаются в разделе
17.3.)
У команд
Команда
•
adduser
и
adduser
Система
deluser
есть аналоги для групп:
в системе
addgroup
и
delgroup.
FreeBSD
FreeBSD поставляется
со сценариями оболочки
adduser
и
rmuser,
которые можно использовать в готовом виде или модифицировать в соот
ветствии с вашими потребностями. Сценарии построены на основе средств.
предоставленных командой
pw.
При желании команду adduвer можно использовать интерактивно. По умолчанию
она создает записи пользователей и групп и домашний каталог. Можно указать сцена
рию файл после флага
-f, содержащий список учетных записей для создания, или вве
сти каждого пользователя в интерактивном режиме.
Например, процесс создания нового пользователя
$ sudo adduser
Username: raphael
Full name: Raphael DoЬЬins
Uid (Leave empty for default) :
Login group [raphael]:
raphael
выглядит так.
Глава
8. Управление учетными записями
пользователей
293
Login group is raphael. Invite raphael into other groups? (]:
Login class (default]:
Shell (sh csh tcsh bash rbash nologin) (sh]: Ьавh
Home directory (/home/raphael]:
Home directory perrnissions (Leave ernpty for default):
Use password-based authentication? (yes] :
Use an ernpty password? (yes/no) (no]:
Use а randorn password? (yes/no) (no]: уев
Lock out the account after creation? (no]:
Usernarne
raphael
Password
Full Name
Raphael Dobbins
Uid
1004
Class
raphael
Groups
/home/raphael
Home
Ноте Mode
/usr/local/bin/bash
Shell
Locked
no
ОК? (yes/no)
уев
adduser: INFO: Successfully added (raphael) to the user database.
adduser: INFO: Password for (raphael) is: RSCAds5fyOvxOt
Add another user? (yes/no) : no
Goodbye!
Команда newusers в системе Linux:
добавление пользователей пакетом
При выполнении Linuх-команды
newusers одновременно создается
несколь
ко учетных записей из содержимого подготовленного текстового файла. Это
не вполне формальный способ, но им удобно пользоваться в случае, если
нужно добавить много пользователей сразу, например при создании учетных
записей для учебной группы. Команда
newusers
в качестве аргумента полу
чает входной файл, состоящий из строк, подобно файлу
/etc/passwd,
за ис
ключением того, что его поле пароля содержит начальный пароль, заданный
открытым текстом. Поэтому хорошо подумайте о защите такого файла.
Команда
newusers
принимает связанные со сроком действия пароля параметры,
установленные в файле
/etc/login.defs, но не копирует стандартные конфигураци
онные файлы, как это делает команда useradd. Единственный файл, который предо
ставляется в этом случае, - файл .xauth.
В университетских системах действительно важно применять "пакетный" сценарий
adduser,
который использует список студентов из данных регистрации для генерирова
ния входной информации для команды
newusers.
Для этого необходимо иметь имена
пользователей, подготовленные в соответствии с локальными правилами при гарантии
их уникальности (на локальном уровне), а также метод случайного генерирования па
ролей при увеличивающихся значениях идентификаторов пользователей и групповых
идентификаторов для каждого студента. Возможно, вам лучше написать собственную
оболочку для команды
useradd на языке Python,
newusers.
дык тому, что предлагает команда
чем пытаться приспособить свои нуж-
Часть
294
8.8.
1. Основы
администрирования
БЕЗОПАСНОЕ УДАЛЕНИЕ УЧЕТНЫХ ЗАПИСЕЙ
ПОЛЬЗОВАТЕЛЕЙ И ФАЙЛОВ
Когда пользователь покидает организацию, его учетная запись и файлы должны быть
удалены из системы. Эта процедура включает удаление всех ссьmок на регистрационное
имя, которые были введены вручную или с помощью команд
useradd
и
rm.user.
При
ручном удалении учетной записи последовательность операций будет примерно такой:
•
•
удалить записи пользователя из локальных баз данных и телефонных списков;
удалить пользовательские почтовые псевдонимы из файла либо организовать пе
ренаправление поступающих ему сообщений;
•
удалить пользовательские задания из файла
crontab,
из очереди команды
at,
а также из заданий на печать;
•
•
•
•
•
уничтожить пользовательские процессы, которые еще выполняются;
•
удалить или преобразовать права владения любыми списками рассьmки, использу
удалить записи пользователя из файлов
passwd, shadow, group
и
gshadow;
удалить домашний каталог пользователя;
удалить почтовый каталог пользователя (если почта хранится локально);
удалить записи в совместно используемых календарях, системах бронирования но
меров и пр.
емыми удаленным пользователем.
Перед тем как удалять домашний каталог пользователя, необходимо переместить из
него в другие каталоги все файлы, которые нужны остальным пользователям. Поскольку
не всегда можно с уверенностью сказать, какие файлы понадобятся, .а какие
-
нет,
лучше предварительно скопировать пользовательские домашний и почтовый каталоги
на какой-то носитель.
После удаления учетной записи пользователя убедитесь, что в системе не осталось фай
лов с его идентификатором. Чтобы узнать точный путь к этим файлам, воспользуйтесь ко
мандой
find с
аргументом
-nouser.
Поскольку команда
find
может вести поиск на сете
вых серверах, проверяйте файловые системы по отдельности, задавая опцию
-xdev.
$ sudo find filesystem -xdev -nouser
Если в организации за пользователями закреплены отдельные рабочие станции,
эффективнее всего переинсталлировать систему, прежде чем предоставлять ее новому
пользователю. Но не забудьте сбросить на системный жесткий диск локальные файлы,
которые могут понадобиться в будущем. 11
Каждая система из наших примеров имеет команды, с помощью которых она авто
матизирует процесс удаления пользователя. Если эти команды не отвечают вашим высо
ким требованиям, можете дополнить их функциональные возможности предоставлени
ем расширенного списка мест хранения данных о пользователях.
~А
\_- W
11
В системах
Deblan и Ubuntu команда deluser представляет собой сцена
Perl, который вызывает обычную команду userdel, аннулируя
все результаты работы команды adduser. При этом вызывается сценарий
user/local/sЬin/deluser. local, если таковой существует, чтобы реа
лизовать несложную операцию локализации. Файл конфигурации /etc/
deluser. conf позволяет установить следующие опции:
рий на языке
Помните о лицензионных ключах!
Глава в. Управление учетными записями пользователей
295
удалять ли домашний и почтовый каталоги пользователя;
•
•
•
•
резервировать ли файлы пользователя и куда поместить резервные копии;
удалять ли все файлы. которыми владел пользователь;
удалять ли группу, если в данный момент она не имеет членов.
RHEL.
•
В системе
Red Hat
предусмотрен сценарий
userdel. local,
но не предус
мотрены префиксные и постфиксные сценарии для автоматизации опера
ций по резервированию файлов пользователя, подлежащего удалению .
Сценарий
rmsuser
в системе
FreeBSD
представляет собой превосходный
инструмент для удаления файлов и процессов пользователей. С ним не мо
гут сравниться никакие программы
userdel
других поставщиков.
8.9. БЛОКИРОВАНИЕ РЕГИСТРАЦИОННЫХ ИМЕН ПОЛЬЗОВАТЕЛЕЙ
Иногда возникает необходимость временно отключить учетную запись пользователя.
Проще всего сделать это, поставив звездочку
(*)
шифрованного пароля в файле
или
/etc/shadow
или какой-то другой символ в поле за
/etc/master.passwd.
Эта мера пре
пятствует большинству типов доступа, управляемых паролем, поскольку дешифровка
больше не может привести к получению какого-либо приемлемого пароля .
•
Система
FreeBSD позволяет блокировать
pw. Например, команда
$ sudo pw lock пользователь
учетные записи с помощью ко
манды
помещает строку
*LOCKED* в начало хешированного пароля, блокируя учет
ную запись.
Во всех дистрибутивах
команды
usermod -L
Linux,
рассматриваемых нами в качестве примеров.
пользователь и
usermod -U
пользователь позво
ляют легко соответственно блокировать и разблокировать пароли. Флаг -L
просто помещает символ"!" перед зашифрованным паролем в файле
shadow,
а флаг
/etc/
-u удаляет его.
К сожалению, модификация пароля пользователя просто приводит к блокированию
регистрации. При этом пользователь не уведомляется о блокировке пароля и не полу•1а
ет разъяснений, почему его учетная запись больше не работает. Альтернативный способ
блокировать регистрационные имена состоит в замене интерпретатора команд пользо
вателя программой, которая выдает сообщение, поясняющее, почему учетная запись от
ключена, и содержащее инструкции по исправлению ситуации. Затем программа завер
шается и вместе с ней заканчивается сеанс регистрации.
Этот метод имеет как преимущества, так и недостатки. Те формы доступа, которые
проверяют пароли, но не обращают внимания на интерпретатор команд. не будут забло
кированы. Многие демоны, предоставляющие доступ к системе без регистрации (напри
мер,
ftpd},
проверяют, упомянут ли интерпретатор пользователя в файле
/etc/shells.
Если он там не указан, вход в систему будет запрещен (именно это нам и требуется).
К сожалению, этот метод нельзя назвать универсальным. Поэтому, если для блокирова
ния учетных записей вы решите модифицировать интерпретатор команд, вам придется
провести дополнительные исследования своей системы.
Кроме того, поясняющее сообщение нельзя увидеть, если пользователь пытается за
регистрироваться в системе в оконной среде или посредством эмулятора терминала, ко
торый не позволяет увидеть сообщения после выхода из системы.
Часть
296
8.1 о.
1. Основы
администрирования
УМЕНЬШЕНИЕ РИСКА с помощью МОДУЛЕЙ РАМ
Подключаемые модули аутентификации (PluggaЫe
подробно описаны в разделе
17.3.
Authentication Modules -
РАМ)
В них сосредоточено управление системными сред
ствами аутентификации посредством стандартных библиотечных утилит, чтобы такие
программы, как
login, sudo, passwd и su,
не должны были предоставлять собственный
код аутентификации. Модули РАМ уменьшают риск, присущий отдельно взятым про
граммным продуктам, позволяют администраторам устанавливать политики безопасно
сти, действующие в рамках всего хоста сети, а также определяют простой способ добав
ления в систему новых методов аутентификации.
Добавление и удаление учетных записей пользователей не предусматривает измене
ние конфигурации модулей РАМ, но используемые для этих целей инструменты долж
ны действовать по правилам РАМ и в соответствии с требованиями РАМ. Кроме того,
многие параметры конфигурации РАМ подобны тем, которые используются командами
useradd
или
usermod.
в этой главе), а команда
Если вы измените какой-нибудь параметр (как описано ниже
useradd,
казалось бы, не обратит на это внимания, проверьте,
не аннулировала ли системная конфигурация РАМ ваше новое значение.
8.11.
ЦЕНТРАЛИЗАЦИЯ УПРАВЛЕНИЯ УЧЕТНЫМИ ЗАПИСЯМИ
В средних и крупных корпорациях всех типов (академических, частных или госу
дарственных) важно использовать определенную форму централизованного управления
учетными записями. Каждый пользователь должен иметь на хосте уникальное, удобное
и безопасное регистрационное имя, идентификатор
(UID)
и пароль. Администраторам
нужна централизованная система, которая бы немедленно обеспечивала повсеместное
распространение изменений (например, аннулирование конкретной учетной записи).
Такая централизация может быть достигнута различными способами, большинство
из которых (включая систему
Active Directory
компании
Microsoft)
в той или иной степе
ни (от бесплатных инсталляций с открытым исходным кодом до дорогих коммерческих
систем) использует упрощенный протокол доступа к сетевым каталогам
(Lightweight
Directory Access Protocol - LDAP).
Протокол
LDAP
и служба
Active Directory
W Подробнее о протоколе LDAP и его реализациях рассказывается в разделе 17.2.
Протокол
LDAP
представляет собой обобщенный репозиторий (наподобие базы
данных), который может хранить данные, связанные с управлением пользователями,
а также другие типы данных. Он использует иерархическую модель "клиент-сервер",
которая поддерживает несколько серверов и несколько одновременно работающих кли
ентов. Одно из самых больших преимуществ
LDAP
как централизованного репозитория
для учетных данных состоит в том, что он может обеспечить в системах уникальность
идентификаторов
UID
и
GID.
Кроме того,он хорошо стыкуется с
Windows,
хотя обрат
ное утверждение справедливо лишь в самой малой степени.
Служба
Active Directory
компании
Microsoft
использует протоколы
LDAP
и КеrЬегоs
(сетевой протокол аутентификации) и может управлять множеством типов данных, вклю
чая данные пользователей. Она ведет себя несколько "эгоистично", навязывая "свою ли
нию" при взаимодействии с
UN IX-
или Linuх-репозиториями
LDAP.
Если вам нужна еди
ная система аутентификации для хоста, который включает Windоws-компьютеры, а также
Глава
8. Управление учетными
UNIX-
и Linuх-системы, то, возможно, проще всего позволить службе
пользовать ваши UNIХ-базы данных
LDAP
Подробнее вопросы интеграции систем
и
297
записями пользователей
Active Directory см.
в главе
Active Directory ис
в качестве вспомоrательных серверов.
UNIX
и
Linux
со службами
LDAP, Kerberos
17.
Системы "единого входа"
Системы с однократной идентификацией пользователей
(single sign-on - SSO)
уравно
вешивают удобства пользователя с проблемами безопасности. Их основная идея состоит
в том, чтобы пользователь, один раз зарегистрировавшись (в ответ на соответствующее
приглашение на веб-странице или в окне
Windows),
мог затем переходить, к примеру,
из одного раздела в другой без повторной аутентификации. Иначе говоря, пользователь
получает аутентификационный мандат (обычно в неявном виде, чтобы не требовалось
больше никакого активного управления), который затем можно использовать для доступа
к другим компьютерам и приложениям. Пользователь должен помнить только одну после
довательность (а не много), состоящую из регистрационного имени и пароля.
Эта схема позволяет усложнять мандаты (поскольку пользователю не нужно помнить
о них и вообще иметь с ними дело), которые теоретически повышают степень сложно
сти. Однако влияние скомпрометированной учетной записи в этом случае усиливается,
поскольку одно регистрационное имя предоставляет взломщику доступ сразу к несколь
ким компьютерам и приложениям. Системы
SSO
переносят "арену действий" из на
стольного компьютера (пока вы спокойно регистрировались) в зону особой уязвимости.
Кроме того, узким местом системы становится сервер аутентификации. Если он "упа
дет", вся работа организации остановится.
Несмотря на то что в основе системы
SSO
лежит простая идея, она предполагает
большую внутреннюю сложность, поскольку различные приложения и компьютеры,
к которым пользователь хотел получить доступ, должны понимать процесс аутентифи
кации и SSО-мандаты.
Существует ряд систем
SSO
с открытым исходным кодом:
• JOSSO, сервер SSO с открытым исходным кодом, написанный на языке Java;
• служба CAS (Central Authentication Service), созданная Йельским университетом
(на языке Java);
• продукт Snibboleth, система SSO с открытым кодом, распространяемая по лицен
зии Apache 2.
Существуют также коммерческие системы, большинство из которых интегрировано
с семействами программных продуктов, предназначенными для управления учетными
данными (о них пойдет речь в следующем разделе).
Системы управления учетными данными
Управление учетными данными
(identity management) -
это последний писк моды
в области управления пользователями. Если говорить проще, то этот термин означает
идентификацию пользователей конкретной системы, аутентифицирование их лично
стей и предоставление привилегий на основе этих аутентифицированных личностей.
Стандартизация этой деятельности проводится такими организациями, как
Web Consortium
и
World Wtde
The Open Group.
Коммерческие системы управления учетными данными сочетают несколько клю
чевых концепций
UNIX
в виде графического интерфейса, "приправленного" терми-
Часть
298
1. основы
администрирования
нами из сферы маркетинга. Основным элементом для всех этих систем является база
данных, которая содержит информацию, связанную с аутентификацией и авторизацией
пользователей, часто хранимую в формате
понятий, как группы
UN\X,
средством таких утилит, как
LDAP.
Управление реализуется на базе таких
а ограниченные административные права усиливаются по
sudo.
Большинство таких систем было разработано с целью
урегулирования требований, диктуемых с точки зрения возможности идентификации,
использования контрольных записей и слежения за ними.
Создано много коммерческих систем в этой сфере, например: ldentity Management
(Oracle), Sun ldentity Management Suite 12 , Courion, Avatier ldentity Management Suite (AIMS)
и ВМС ldentity Management Suite. Оценивая системы управления учетными данными,
ищите следующие функции.
•
Контроль:
•
безопасный веб-интерфейс для управления, доступного как изнутри, так
и снаружи организации;
•
интерфейс, при использовании которого наем менеджеров может потребовать,
чтобы учетные записи предоставлялись в соответствии с ролью;
•
возможность согласования с базами данных кадров для автоматического уда
ления доступа для служащих, которые уволены или сокращены.
•
Управление учетными записями:
•
•
генерирование глобальных уникальных идентификаторов пользователей;
возможность создания, изменения и удаления пользовательских учетных за
писей в организации на оборудовании и операционных системах всех типов;
•
возможность простого отображения имен всех пользователей, которые имеют
определенный набор привилегий;
•
простой способ отобразить всех пользователей, имеющих определенные при
вилегии, а также все привилегии, предоставленные конкретному пользователю;
•
управление доступом на основе ролей, включая инициализацию учетных за
писей пользователей с использованием ролевого принципа; создание исклю
чений для предостамения прав на основе ролей, включая организацию дейст
вий для рассмотрения исключений;
•
регистрация с перестраиваемой конфигурацией всех изменений и действий
администратора и создание реконфигурируемых отчетов на основе регистра
ционных данных (по пользователю, по дате и пр.).
•
Удобство использования:
•
•
возможность для пользователей менять их пароли глобально в одной операции;
возможность разрешить пользователям изменять (и восстанавливать) соб
ственные пароли при соблюдении правил выбора сильных паролей.
Рассмотрите также, как реализована система с точки зрения того, какие в действи
тельности выполняются аутентификации и авторизации. Требуется ли системе повсе
местная инсталляция пользовательских агентов или возможно самостоятельное согласо
вание с базовыми системами?
12 Теперь,
коrда компания
Oracle
купила
завершения процесса поглощения.
Sun,
не ясно, выживет ли эта система как продукт после
глава 9
Облачные вычисления
Облачные вычисления
-
это практика лизинга компьютерных ресурсов из пула об
щей емкости. Облачные службы предоставляют пользователям ресурсы по их требова
нию и получают за это установленную цену. Компании, использующие облако, быстрее
выходят на рынок, демонстрируют большую гибкость и несут меньшие капитальные
и эксплуатационные расходы, чем предприятия, управляющие традиционными центра
ми обработки данных.
Облако
-
это реализация "коммунальных вычислений", впервые задуманная уче
ным-программистом Джоном Мак-Карти, который описал эту идею в одной беседе
в Массачусетском технологическом институте в
1961
году. Многочисленные техноло
гические достижения, появившиеся за прошедшее время, помогли воплотить эту идею
в жизнь. Перечислим лишь некоторые из них.
•
Программное обеспечение виртуализации надежно выделяет ресурсы центральных
процессоров, памяти, хранилища и сети по требованию.
•
Надежные слои безопасности изолируют пользователей и виртуальные машины
друг от друга, даже если они совместно используют базовое оборудование.
•
Стандартизированные аппаратные компоненты позволяют создавать центры об
работки данных с огромными мощностями, ресурсами хранения и системами ох
лаждения.
•
Надежная глобальная сеть соединяет все это вместе.
Облачные провайдеры используют эти и многие другие инновации. Они предлага
ют множество услуг, начиная от размещения частных серверов и заканчивая полностью
управляемыми приложениями. Ведущие поставщики облачных технологий являются
конкурентоспособными, высокодоходными и быстро растущими компаниями.
Часть
300
1. Основы
администрирования
В этой главе излагаются мотивы перехода в облако, описываются некоторые из ос
новных поставщиков облачных вычислений, рассматриваются самые важные облачные
службы и предлагаются советы по контролю затрат. В качестве еще более краткого вве
дения в разделе
9.4
показано, как создавать облачные серверы из командной строки.
Управление облачными серверами упоминается еще в нескольких разделах этой кни
ги, которые перечислены в таблице
Таблица
9.1.
9.1.
Разделы, в которых рассматриваются темы,
связанные с облачными вычислениями
Раздел
Название и тема раздела или подраздела
2.10
13.15
Восстановление облачных систем (проблемы, связанные с загрузкой для облака)
Облачные сети (сеть
TCP/IP для
облачных платформ)
19.З
Веб-хостинг в облаке
24.6
25.4
26.4
Packer (использование инструмента Packer для
создания изображений ОС для облака)
Контейнерная кластеризация и управление (особенно в разделе, посвященном AINS
Непрерывная интеграция и развертывание на практике (пример конвейера
Cl/CD,
ECS)
использую
щего облачные службы)
28.7
Инструменты мониторинга коммерческих приложений (инструменты мониторинга для облака)
Кроме того, облачные системы часто упоминаются в главе
9.1. ОБЛАКО В
23.
КОНТЕКСТЕ
Переход от серверов в частных центрах обработки данных к современному вездесу
щему облаку был быстрым и драматичным. Давайте посмотрим на причины этого мас
сового движения.
Облачные провайдеры создают технически развитую инфраструктуру, которую боль
шинство компаний не могут себе позволить по финансовым соображениям. Они разме
щают свои центры обработки данных в районах с недорогой электроэнергией и много
численными сетевыми коммутаторами. Они разрабатывают пользовательские серверные
шасси, которые максимизируют энергоэффективность и минимизируют стоимость
эксплуатации. Они используют специально созданную сетевую инфраструктуру со спе
циальным аппаратным и программным обеспечением, точно настроенным на их вну
тренние сети. Они проводят интенсивную автоматизацию, чтобы обеспечить быстрое
расширение и уменьшить вероятность человеческой ошибки.
Благодаря всем этим инженерным усилиям (не говоря уже об экономии за счет мас
штаба) стоимость распределенных вычислительных услуг для облачного провайдера на
много ниже, чем для типичной компании с небольшим центром обработки данных.
Экономия затрат отражается как на цене облачных услуг, так и на прибьти поставщиков.
На этой аппаратной основе созданы элементы управления, упрощающие и облегча
ющие настройку инфраструктуры. Облачные поставщики предлагают как интерфейсы
прикладного программирования, так и инструменты, ориентированные на пользовате
ля, которые контролируют предоставление и освобождение ресурсов. В результате весь
цикл жизненного цикла системы или группы систем, распределенных в виртуальной
сети, может быть автоматизирован. Эта концепция носит название "инфраструктура как
код" и резко контрастирует с процедурами закупки и подготовки ручного сервера про
шлых времен.
9. Облачные
Глава
Гибкость
-
вычисления
301
еще одна важная движущая сила внедрения облаков. Поскольку облач
ные системы могут предоставляться и освобождаться автоматически, любая компания,
имебщая циклический спрос, может оптимизировать эксплуатационные расходы за счет
добавления дополнительных ресурсов в периоды максимального использования и уда
ления дополнительной емкости, когда она больше не нужна. Встроенные функции ав
томатического масштабирования, доступные на некоторых облачных платформах, упро
щают этот процесс.
Облачные провайдеры имеют глобальное присутствие на рынке. Приложив опреде
ленные усилия по планированию и проектированию, предприятия могут выйти на но
вые рынки, предложив услуги в нескольких географических регионах. Кроме того, вы
полнить аварийное восстановление в облаке проще, чем в частных центрах обработки
данных, поскольку резервные системы могут физически находиться в разных местах.
W Дополнительную информацию о методике DevOps см. в разделе 31 .1.
Все эти характеристики хорошо сочетаются с методикой системного администриро
вания
DevOps,
делающей акцент на гибкости и повторяемости. В облаке вы больше не
ограничены медленными процессами закупок или подготовки, и почти все можно авто
матизировать.
Тем не менее от вас требуется определенный умственный скачок, потому что вы
больше не контролируете свое собственное оборудование. Эту ситуацию хорошо опи
сывает одна промышленная метафора: серверы следует рассматривать как скот, а не как
домашних животных. Домашнему животному дают имя, его любят и лелеют. Когда до
машнее животное болеет, его несут к ветеринару и лечат. Напротив, крупный рогатый
скот
-
это товар, который пасется, продается и перемещается в больших количествах.
Заболевший крупный рогатый скот пристреливают.
Облачный сервер
-
это всего лишь один из членов стада, иначе пришлось бы игно
рировать базовый факт облачных вычислений: облачные системы являются эфемерны
ми, и они могут выйти из строя в любое время. Планируйте эту ситуацию, и вы будете
более успешны при работе с отказоустойчивой инфраструктурой.
Несмотря на все свои преимущества, облако не является панацеей для быстрого сни
жения затрат или повышения производительности. Непростой перенос существующе
го корпоративного приложения из центра обработки данных в облачный провайдер (по
принципу "поднять и перенести") вряд ли будет успешным без тщательного планирова
ния. Для облака нужны другие процессы эксплуатации, которые требуют обучения и те
стирования. Кроме того, большинство корпоративных программ предназначено для ста
тических сред, но отдельные системы в облаке следует рассматривать как недолговечные
и ненадежные. Система называется облачной, если она надежна даже перед лицом не
предвиденных событий.
9.2.
ВЫБОР ОБЛАЧНОЙ ПЛАТФОРМЫ
На выбор поставщика облачных услуг влияет множество факторов.
Вероятно, опре
деленную роль будут играть стоимость, прошлый опыт, совместимость с существующи
ми технологиями, безопасность, требования соответствия и внутренняя политика. На
процесс отбора также может повлиять репутация, размер провайдера, функции и, ко
нечно же, маркетинг.
К счастью, существует много облачных провайдеров. Мы решили сосредоточиться
только на трех основных провайдерах облачных услуг: Amazoп
Web Services (AWS), Google
Часть
302
Cloud
Platfoпn
(GCP)
и
DigitalOcean (DO).
1. Основы
администрирования
В этом разделе мы упомянем несколько допол
нительных вариантов. Основные игроки в этой области перечислены в табл.
9.2.
Таблица 9.2. Наиболее wироко используемые облачные платформы
Проваiдер
Простая и надежная. Имеет удобный интерфейс прикладного программирования.
Хороша для разработки
Google Cloud Platform
Технически сложная и быстро совершенствующаяся. Делает акцент на производи-
················· .......................... ".......................................!.е.~.~~.О?.!..~.:. .~.t.1е.е.!...~~Р.О~~.~ . ~.n._е.~!.Р ... У~~У.~П.О.П.е.Р.е.!:l~~е...~.~.~.~.~.~. ,!\З..~~~.1 ~ ................................ ·······-····
IBM Softlayer
Больше похожа на хостинг, чем на облачную платформу. Имеет глобальную част
сеть
Вторая по размеру, но далеко отстает от первой. Имеет историю отключений .
Microsoft Azure
... . . ....................................... ..... ............ ....~О.~.t.1.0.'."~0.~...~.З..~~-~-~-~-а.е..т.~~~t.1.З.~~~ ?.О ~торо~ы м_~г~~инов Microsoft . ..
OpeпStack
Модулярная DIY платформа с открытым исходным кодом для создания частных об····........................... - .. - ....... ~З.~ОВ: ~t.le.e.!. ~~~?.O~t.1e.~!.~t.1~1e ~~!.е.РФе.йсы прикладного программирования
Rackspace
Открытые и частные облака, реализующие проекты OpeпStack. Предлагает управ
ляемые службы для AWS и Azure. Имеет фанатичных сторонников
.
. .
. .
Заумный сервис для публичных, частных и гибридных облаков. Использует техно
VMware vCloud Air
логию
VMware.
Вероятно, обречен
Публичные, частные и гибридные облака
В публичном облаке поставщик контролирует все физическое оборудование и предо
ставляет доступ к системам через Интернет. Это снимает с пользователей обязанность
инсталлировать и обслуживать оборудование, но за счет меньшего контроля над функ
циями и характеристиками платформы.
AWS, GCP и DO являются
общедоступными об
лачными провайдерами.
Частные облачные платформы аналогичны, но размещаются в собственном центре
обработки данных организации или управляются поставщиком от имени одного кли
ента. Серверы в частном облаке являются единственными арендаторами, а не делят его
с другими клиентами, как в общедоступном облаке.
Частные облака обеспечивают гибкость и программный контроль, так же, как
и обычные облака. Они привлекательны для организаций, которые уже инвестировали
значительный капитал в оборудование, а также для инженеров, особенно тех, которые
ценят полный контроль над своей средой.
OpenStack -
это ведущая система с открытым исходным кодом, используемая
для создания частных облаков. Она получает финансовую и техническую поддержку
от таких предприятий, как АТ
из крупнейших участников
& Т, IBM
OpenStack.
и
lntel. Rackspace
сама по себе является одним
Комбинация публичных и частных облаков называется гибридным облаком. Гибриды
могут быть полезными, когда предприятие сначала переходит с локальных серверов
в публичное облако, для добавления временной емкости обработки пиковых нагрузок
и реализации других сценариев. Администраторы должны быть осторожными: работа
с двумя различными облачными платформами в тандеме непропорционально увеличи
вает сложность.
Облако VМware
vSphere Air,
основанное на технологии виртуализации
vSphere,
пред
ставляет собой удобное гибридное облако для клиентов, которые уже используют вирту-
Глава
9. Облачные
ализацию
вычисления
VMware
303
в своем локальном центре обработки данных. Эти пользователи могут
прозрачно перемещать приложения в инфраструктуру
vC\oud Air и
из нее.
Термин публичное облако является немного неудачным и вызывает опасения, связанные
с безопасностью. На самом деле пользователи публичных облаков изолированы друг от друга
несколькими слоями аппаратной и программной виртуализации. Частное облако практически
не имеет преимущества в области безопасности над публичным облаком.
Кроме того, работа с частным облаком
-
это сложная и дорогостоящая перспекти
ва, которую нельзя предпринимать необдуманно. Только крупнейшие и наиболее совер
шенные организации имеют инженерные ресурсы и финансовые средства, необходимые
дЛЯ внедрения надежного, безопасного частного облака. В то же время, после реали
зации функции частного облака обычно не соответствуют тем, которые предлагаются
коммерческими облаками.
Для большинства организаций мы рекомендуем публичное облако над частными или
гибридными опциями. Публичные облака предлагают наивысшую ценность и простоту
администрирования. В оставшейся части этой книги мы ограничимся публичными об
лаками. В следующих нескольких разделах представлен краткий обзор каждой из при
веденных выше платформ.
Amazon Web Services
AWS (Amazon ~Ь Services)
предлагает множество услуг: от виртуальных серверов (ЕС2)
до управляемых баз данных, хранилищ данных
(RDS
и
Redshift)
и бессерверных функций,
выполняемых в ответ на события (LamЬda). Кажцый год компания
AWS выпускает сотни об
новлений и новых функций. Она имеет самое большое и самое активное сообщество поль
зователей.
безусловно, самая крупная компания в области облачных вычислений.
AWS -
С точки зрения большинства пользователей,
AWS
имеет практически неограничен
ные возможности. Однако новые учетные записи имеют ограничения, которые опреде
ляют, какой объем вычислительной мощности вы можете запросить. Эти ограничения
защищают как
Amazon,
так и вас, поскольку затраты могут быстро вырваться из-под
контроля, если услуги не будут должным образом управляться. Чтобы увеличить свои
лимиты, вы должны заполнить форму на сайте поддержки
AWS.
Ограничения, связан
ные с каждой службой, перечислены в документации по лимитам услуг.
Онлайновая документация
documentation,
AWS,
расположенная по адресу
aws.amazon.com/
является авторитетной, всеобъемлющей и хорошо организованной. Это
должно быть первое место, которое вы рассматриваете при исследовании конкретной
услуги. Белые страницы, посвященные безопасности, пути миграции и архитектуры, не
оценимы для тех, кто заинтересован в создании надежных облачных сред.
Google Cloud Platform
Если
AWS является действующим чемпионом в области
Google является его потенциальным преемником.
компания
облачных вычислений, то
Он конкурирует за клиен
тов, используя такие нечестные трюки, как снижение цен и прямое обращение к боле
вым точкам
AWS.
Спрос на инженеров настолько ожесточен, что
Google, как известно, браковала быв
AWS. В прошлом компания Google проводила вечеринки параллельно
AWS re:lnvent в Лас-Вегасе, пытаясь привлечь как талантливых людей,
ших сотрудников
с конференцией
так и пользователей. По мере эскалации облачных войн клиенты в конечном итоге вы
игрывают от этого конкурса в виде более низких затрат и улучшенных функций.
304
Часть
1. Основы
администрирования
использует самую передовую глобальную сеть в мире, которая приносит
Google
пользу облачной платформе. Центры обработки данных
Google -
это технологические
чудеса, которые предлагают множество инноваций для повышения энергоэффективно
сти и снижения эксплуатационных затрат 1 • Компания
Google
относительно прозрачна
в своих операциях, а ее вклад с открытым исходным кодом помогает развивать облач
ную индустрию.
Несмотря на свою техническую подкованность, по каким-то причинам компания
является приверженцем публичного облака, а не лидером. Когда оно появи
Google
лось в
2011-2012 rr. 2 , GCP
уже опаздывала на игру. Ее службы имеют много одинако
вых функций (и часто одни и те же имена), эквивалентных функциям
знакомы с
от
AWS,
AWS,
то обнаружите, что веб-интерфейс
GCP
AWS.
Если вы
внешне несколько отличается
но их функциональные возможности поразительно похожи.
Мы ожидаем, что в последующие годы
поскольку компания
Google
GCP
получит определенную долю рынка,
улучшает свою продукцию и укрепляет доверие клиентов.
Она наняла некоторые из самых ярких умов в отрасли, которые должны разработать не
которые инновационные технологии. Как потребители, мы все выиграем от этого.
DigitalOcean
DigitalOcean - это другая разновидность публичного облака. В то время как AWS
GCP конкурируют за крупные предприятия и стартапы, ориентированные на рост,
DigitalOcean привлекает маленьких клиентов с более простыми потребностями.
Название этой стратегии - минимализм. Нам нравится применять DigitalOcean для экс
и
периментов и проверок концепций.
DigitalOcean
предлагает центры обработки данных в Северной Америке, Европе
и Азии. В каждом из этих регионов есть несколько центров, но они не связаны напря
мую и поэтому не могут считаться зонами доступности (см. раздел
9.3).
В результате по
строить глобальные высокодоступные производственные службы на основе
значительно сложнее, чем на основе
Серверы
DigitalOcean
AWS
называются
DigitalOcean
или
Google.
дроплетами (droplet).
командной строки или веб-консоли и быстро загружаются.
Они просто управляются из
DigitalOcean поставляет об
Red Hat. Он так
разы для всех наших демонстрационных операционных систем, кроме
же имеет несколько образов для популярных приложений с открытым исходным кодом,
таких как
Cassandra, Drupal, Django и Git Lab.
DigitalOcean также имеет функции балансировки нагрузки и хранения
блоков. В главе 26 мы приводим пример предоставления балансировщика нагрузки
DigitalOcean с двумя дроплетами с использованием инструмента обеспечения инфра
структуры Terraform компании HashiCorp.
Платформа
9.3. Основы
РАБОТЫ с ОБЛАЧНЫМИ СЛУЖБАМИ
Облачные службы слабо группируются по трем категориям.
•
Инфраструктура как услуга
(Infrastructure-as-s-Service - IaaS),
в которой пользо
ватели запрашивают исходные ресурсы вычислений, памяти, сети и хранилища.
1 См.
сайт Google.com/aЬout/datacenters, на котором можно найти фотографии и факты о
том, как работают центры обработки данных
2 Компания
Google.
выпустила другие облачные продукты уже в 2008 г" включая Арр Engine, первый
продукт платформы. Однако стратегия Google и бренд GCP не были очевидны до 2012 г.
Google
Глава
9. Облачные
вычисления
305
Обычно они поставляются в виде виртуальных частных серверов, а также VPS.
Пользователи IaaS отвечают за управление всем: операционными системами, се
тями, системами хранения и собственным программным обеспечением.
•
Платформа как услуга
(Platform-as-s-Service - PaaS),
в которой разработчики
представляют свои специализированные приложения, упакованные в формате,
указанном поставщиком. Затем поставщик запускает код от имени пользователя.
В этой модели пользователи несут ответственность за свой собственный код, а по
ставщик управляет операционной системой и сетью.
•
Программное обеспечение как услуга
(Software-as-s-Service - SaaS) -
самая ши
рокая категория, в которой поставщик размещает программное обеспечение
и управляет им, а пользователи платят абонентскую плату за доступ. Пользователи
не поддерживают ни операционную систему, ни приложение. Почти любое разме
щенное веб-приложение (например,
В табл.
9.3
WordPress)
попадает в категорию
SaaS.
показано, как каждая из этих абстрактных моделей разбивается на слои,
связанные с полным развертыванием.
Таблица
9.3.
На каких споях вы отвечаете за управление?
Спой
Локальный•
laaS
PaaS
Приложение
.(
.(
.(
Базы данных
.(
.(
.(
Время выполнения приложения
.(
.(
.(
Операционная система
.(
.(
Виртуальная сеть, хранилище и серверы
.(
.(
Платформа виртуализации
.(
Физические серверы
.(
Системы хранения
.(
Физическая сеть
.(
Мощность, пространство и охлаждение
.(
SaaS
'Локальный: локальные серверы и сеть
laaS PaaS SaaS -
инфраструктура как услуга (виртуальные серверы).
платформа как услуга (например,
Google Арр
Епgiпе).
программное обеспечение как услуга (например, большинство веб-служб).
Из этих вариантов
IaaS
является наиболее подходящим для системного администри
рования. В дополнение к определению виртуальных компьютеров, поставщики
laaS
виртуализируют связанные с ними аппаратные элементы, такие как диски (в настоящее
время используется более общий термин
-
"блочные устройства хранения данных")
и сети. Виртуальные серверы могут посещать виртуальные сети, для которых вы указы
ваете топологию, маршруты, адресацию и другие характеристики.
В большинстве случаев эти сети являются частными для вашей организации.
IaaS
также может включать в себя другие основные службы, такие как базы данных, очереди,
хранилища ключей-значений и вычислительные кластеры. Эти функции в совокупности
создают полную замену традиционного центра обработки данных (и во многих случаях
даже улучшение).
Часть
306
1. Основы
администрирования
это область больших обещаний, которая еще не полностью реализована.
PaaS -
Текущие предложения, такие как
AWS Elastic Beanstalk, Google
Арр
Engine
и
Heroku,
имеют экологические ограничения или нюансы, которые делают их непрактичными
(или неполными) для использования в загруженных производственных средах. Снова
и снова мы видели, как бизнес перерастает эти услуги. Однако новым услугам в этой
области уделяется большое внимание. В ближайшие годы мы ожидаем значительных
улучшений.
Облачные поставщики широко различаются по своим функциям и деталям реализа
uии, но концептуально многие услуги очень похожи. В следующих разделах описывают
ся облачные службы в целом, но поскольку
AWS
является лидером в этом пространстве,
мы иногда принимаем его номенклатуру и условные обозначения в качестве значений
по умолчанию.
Доступ к облаку
Первичный интерфейс большинства облачных провайдеров
-
это своего рода веб
интерфейс. Новые системные администраторы должны использовать эту веб-консоль
для создания учетной записи и для настройки своих первых ресурсов.
Облачные провайдеры также определяют интерфейсы прикладного программирова
ния, имеющие доступ к тем же базовым функциям, что и к веб-консоли. В большинстве
случаев у них также есть стандартная оболочка командной строки, переносимая боль
шинством систем для этих интерфейсов прикладного программирования.
Даже ветераны системного администрирования часто используют веб-графические
интерфейсы. Тем не менее важно также дружить с инструментами командной строки, по
скольку они легче справляются с автоматизацией и повторяемостью. Используйте сцена
рии, чтобы избежать утомительного и вялого процесса запроса всего и вся через браузер.
Облачные поставщики также поддерживают комплекты разработки программного
обеспечения
(SDK)
для многих популярных языков, чтобы помочь разработчикам ис
пользовать их интерфейсы прикладного программирования. Сторонние инструменты
используют
SDK для
упрощения или автоматизации определенных наборов задач. Вы,
несомненно, столкнетесь с этими
SDK, если напишете свои собственные инструменты.
UNIX и Linux, работающим в облаке, используется
Обычно для доступа к системам
алгоритм
SSH
с аутентификацией открытого ключа. Для получения дополнительной ин
формации об эффективном использовании
SSH
см. раздел
27.7.
Некоторые поставщики облачных вычислений позволяют получить доступ к сеансу
консоли через веб-браузер, что может быть особенно полезным, если вы ошибочно за
блокируете себя с помощью правила брандмауэра или сломанной конфигурации
SSH.
Однако это не означает представление реальной консоли системы, поэтому вы не мо
жете использовать эту функцию для отладки начальной загрузки или проблем с
BIOS.
Регионы и зоны доступности
Облачные провайдеры поддерживают центры обработки данных по всему миру.
Несколько стандартных терминов описывают особенности, связанные с географией.
Регион
-
это область, в которой облачный провайдер поддерживает центры обра
ботки данных. В большинстве случаев регионы названы в честь территории предпола
гаемого обслуживания, хотя сами центры обработки данных более сконцентрированы.
Глава
9. Облачные
вычисления
Например, регион
Amazon us-east-1
307
обслуживается центрами обработки данных в се
верной Вирджинии. 3
Некоторые провайдеры также имеют зоны доступности (или просто зоны), которые
представляют собой совокупность центров обработки данных в регионе. Зоны внутри
региона просматриваются в сетях с высокой пропускной способностью и низкой за
держкой . поэтому межзональная связь выполняется быстро, хотя и не обязательно де
шево. Например, мы наблюдали межзонную задержку длительностью менее
1 мс .
Зоны обычно проектируются так, чтобы быть независимыми друг от друга с точки
зрения мощности и охлаждения, и они географически распределены, так что стихийное
бедствие, которое затрагивает одну зону, имеет низкую вероятность воздействия на дру
гих людей в том же регионе.
Регионы и зоны имеют основополагающее значение для создания высокодоступных
сетевых услуг. В зависимости от требований доступности вы можете развертывать свои
ресурсы в нескольких зонах и регионах, чтобы минимизировать последствия сбоя в цен
тре обработки данных или в географической области. Отключения зоны доступности
возможны, но редки; региональные сбои происходят еще реже. Большинство служб,
предоставляемых облачными провайдерами, знают о зонах и используют их для дости
жения встроенной избыточности.
Регионы соединяются через
Интернет или через частные сети;
плата взимается в любом случае
1
1
Западный реrион США
~
частным и оплачивается
в зависимости от объема
Рис.
9.1.
Восточный реrион США
~
Серверы, распределенные между несколькими регионами и зонами
Многоуровневые развертывания являются более сложными из-за физических рас
стояний между регионами и связанной с ними большей задержки. Некоторые постав
щики облачных технологий используют более быструю и надежную межрегиональную
сеть, чем другие. Если ваш сайт обслуживает пользователей по всему миру, качество сети
вашего облачного поставщика имеет первостепенное значение.
Выбирайте регионы в зависимости от географической близости к вашей пользова
тельской базе. Для сценариев, в которых разработчики и пользователи находятся в раз
ных географических регионах, подумайте над тем, чтобы ваши системы разработки
были близки к разработчикам, а производственные системы ближе к пользователям.
)Для сигнала, передаваемого 110 шпическому волокну, требуется около
5 мс, чтобы преодолеть 1000 км,
поэтому ре1·ионы размером с восточное побережье США с точки зрения производительности вполне
приемлемы. Сетевое подклю•1ение, доступное ДJIЯ дата-центра, важнее, чем его точное местоположение.
Часть
308
1. основы администрирования
Для сайтов, предоставляющих услуги для глобальной пользовательской базы, работа
в нескольких регионах может существенно повысить производительность для конечных
пользователей. Запросы могут направляться на региональные серверы каждого клиента,
используя географическое DNS-разрешение, которое определяет местоположение кли
ентов по их исходным IР-адресам.
Большинство облачных платформ имеют регионы в Северной Америке, Южной
Америке, Европе и странах Азиатско-Тихоокеанского региона. Только
AWS и Azure не
AWS и vCloud,
посредственно присутствуют в Китае. Некоторые платформы, в частности
имеют регионы, совместимые со строгими федеральными требованиями IТAR, приня
тыми в США.
Виртуальные частные серверы
Флагманской службой облака является виртуальный частный сервер, виртуальная
машина, работающая на аппаратном обеспечении провайдера. Виртуальные частные
серверы иногда называются экземплярами. Вы можете создать столько экземпляров,
сколько вам нужно, запустив свою предпочтительную операционную систему и прило
жения, а затем закрыть экземпляры, когда они больше не нужны. Вы платите только за
то, что используете, и обычно не несете авансовых расходов.
Поскольку экземпляры являются виртуальными машинами, их мощность процессо
ра, память, размер диска и сетевые настройки могут настраиваться, когда экземпляр соз
дается и даже корректируется постфактум. Открытые облачные платформы определяют
предустановленные конфигурации, называемые типами экземпляров. Они варьируются
от однопроцессорных узлов с
512
Мбайт памяти до больших систем со многими ядрами
процессора и несколькими ТиБ памяти. Некоторые типы экземпляров сбалансированы
для общего использования, а другие специализируются на приложениях с процессором,
памятью, диском или сетью. Конфигурации экземпляров
-
это одна из областей, в ко
торой поставщики облачных вычислений энергично конкурируют, чтобы соответство
вать потребностям рынка.
Экземпляры создаются из образов, сохраненного состояния операционной системы,
которое содержит (как минимум) корневую файловую систему и загрузчик. Образ мо
жет также включать в себя тома дисков для дополнительных файловых систем и других
настраиваемых параметров. Вы можете легко создавать собственные образы с помощью
собственного программного обеспечения и настроек.
Все наши иллюстративные операционные системы используются широко, поэтому
облачные платформы обычно предоставляют для них официальные образы. 4 Многие
сторонние поставщики программного обеспечения также поддерживают образы обла
ков, которые имеют предустановленное программное обеспечение для облегчения при
нятия клиентами.
Также легко создавать свои собственные образы. Подробнее о том, как создавать об
разы виртуальной машины в пакете, см. раздел
24.5.
Сети
Облачные провайдеры позволяют создавать виртуальные сети с настраиваемыми то
пологиями, которые изолируют ваши системы друг от друга и от Интернета. На плат
формах, которые предлагают эту функцию, вы можете установить диапазоны адресов ва-
8 настоящее время
Compute Eпgine.
4
вы должны создать свой собственный образ
FreeBSD, если
используете
Google
глава
9. Облачные вычисления
309
ших сетей, оnределить nодсети, настроить маршруты, установить nравила брандмауэра
и nостроить
VPN
для nодключения к внешним сетям. С сетью и эксnлуатацией более
круnных и более сложных облачных nриложений связаны оnределенные издержки.
Ш Дополнительную информацию о сети
VPN
см. в разделе
27.9.
Вы можете сделать ваши серверы достуnными в Интернете nутем аренды nублично
маршрутизируемых адресов от вашего nровайдера. У всех nоставщиков есть большой
пул таких адресов, из которых nользователи могут выбирать. В качестве альтернативы
серверам может быть предоставлен только частный адрес
RFC 1918
в адресном про
странстве, выбранном мя вашей сети, что делает их общедоступными.
Ш Дополнительную информацию о частных адресах
RFC1918
см. в разделе
13.4.
Системы без общедоступных адресов напрямую не доступны из Интернета, даже
для администраторов. Вы можете nолучить достуn к таким узлам через сервер nерехода
или хост-бастион, который открыт для Интернета, или через сеть
VPN,
которая под
ключается к вашей облачной сети. Для безопасности лучше, чтобы внешняя зона вашей
виртуальной империи была как можно меньше.
Хотя все это звучит многообещающе, у вас меньше возможностей управлять вирту
альными сетями, чем традиционными, и вы должны подчиняться прихотям и капризам
набора функций, предоставленных вашим выбранным nровайдером. Это особенно раз
дражает, когда новая функция не может взаимодействовать с вашей частной сетью. (Мы
смотрим на тебя,
Amazon!)
Для nолучения nодробной информации о сети
дел
TCP/IP
в облаке nерейдите в раз
13.15.
Хранилище
Важной частью облачных вычислений является хранение данных. Облачные про
вайдеры имеют самые большие и самые современные системы хранения данных на пла
нете, поэтому вам будет трудно обеспечить их объем и возможности в частном центре
обработки данных. Поставщики облачных вычислений взимают nлату с объема данных,
которые вы храните. Они очень мотивированы, чтобы дать вам как можно больше воз
можностей мя хранения ваших данных. 5
Перечислим несколько наиболее важных сnособов хранения данных в облаке.
•
Объектные хранилища содержат коллекции дискретных объектов
(no
существу,
файлов) в nлоском пространстве имен. Объектные хранилища могут вмещать
nрактически неограниченный объем данных с исключительно высокой надежно
стью, но относительно низкой производительностью. Они предназначены в ос
новном д11я чтения. Файлы в хранилище объектов доступны через сеть с помощью
протокола НТТРS. Примеры
•
- AWS SЗ и Google Cloud Storage.
- это виртуализированные жесткие
Блочные устройства хранения
диски. Они
могут быть настроены по вашему выбору и nодключены к виртуальному серверу,
nодобно томам
SAN
в традиционной сети. Вы можете перемещать тома между уз
лами и настраивать свои профили ввода-вывода. Примеры
- AWS EBS
и
Google
Cloud Storage.
компания AWS предлагает посетить вашу организацию на машине AWS Snowmoblle,
представляющей собой транспортный контейнер длиной 45 футов, который буксируется грузовым
5 Например,
тягачом и способен перевести
100
ПиБ из вашего дата-центра в облако.
Часть
310
•
1. Основы
администрирования
Эфемерное хранилище
ном частном сервере
- это локальное дисковое пространство на виртуаль
(Virtual Private Server - VPS). созданное на основе дисков
на главном сервере. Они обычно бывают быстрыми и емкими, но при удалении
VPS
данные теряются, поэтому эфемерное хранилище лучше всего использовать
для временных файлов.Примеры
кальные
SSD
на
тома хранилища экземпляров на
-
и ло
AWS
GCP.
В дополнение к этим службам хранения данных облачные провайдеры обычно пред
лагают множество бесплатных служб баз данных, которые вы можете получить через
сеть. Реляционные базы данных, такие как
MySQL, PostgreSQL
как службы
Они предлагают встроенную мультизонную
AWS Relational Database Service.
и
Oracle,
выполняются
избыточность и шифрование данных при хранении.
Распределенные аналитические базы данных. такие как
BigQuery,
AWS Redshift
и
GCP
предлагают невероятную рентабельность инвестиций; обе эти базы заслужива
ют внимательного изучения, прежде чем строить собственное дорогостоящее хранили
ще. Поставщики облаков также предлагают обычный ассортимент баз данных в опера
тивной памяти и
NoSQL,
таких как
Redis
и
memcached.
Идентификация и авторизация
Администраторам, разработчикам и другим техническим сотрудникам необходимо
управлять облачными службами. В идеальном случае средства управления доступом
должны соответствовать принципу наименьших привилегий: каждый директор может
иметь доступ только к объектам, которые имеют к нему отношение, и не более того.
В зависимости от контекста такие спецификации контроля доступа могут стать доволь
но сложными.
Компания AWS исключительно сильна в этой
ldentity and Access Management (IAM) определяет
области. Ее служба под названием
не только пользователей и группы,
но и роли для систем. Например, серверу могут быть назначены политики, позволяю
щие его программному обеспечению запускать и останамивать другие серверы, хранить
и извлекать данные в хранилище объектов или взаимодействовать с очередями
с автоматической ротацией ключей. Служба
IAM
-
все
также имеет интерфейс прикладного
программирования для управления ключами, который поможет вам безопасно хранить
секреты.
Другие облачные
платформы
Неудивительно, что служба
Azure
имеют меньше
основана на службе
возможностей
авторизации.
Active Directory Microsoft.
Она хо
рошо сочетается с сайтами, для которых существует интегрированный каталог. Служба
ся основными строительными блоками пользовательской автоматизации. но они часто
неуклюжи и непрактичны для организации больших коллекций ресурсов. Например,
что делать, если вам нужно создать новую сеть, запустить несколько экземпляров
VPS,
предоставить базу данных, настроить брандмауэр и, наконец, подключить все эти ком
поненты'? С точки зрения облачного
API это бьш бы сложный сценарий.
AWS CloudFormation стала первой службой для решения этой проблемы. Она принимает
шаблон в формате JSON или YAML, который описывает требуемые ресурсы и связанные
Глава
9. Облачные
вычисления
311
с ними детали конфиrураuии. Вы отпрамяете шаблон в службу
CloudFormation,
который
проверяет его на наличие ошибок, сортирует зависимости между ресурсами и создает или
обновляет конфиrураuию облака в соответствии с вашими спецификациями.
Шаблоны
CloudFormation
ямяются мощными, но подвержены ошибкам в челове
ческих руках из-за строгих требований синтаксиса. Полный шаблон является невыно
симо многословным, и людям сложно даже читать его. Вместо того, чтобы писать эти
шаблоны вручную, мы предпочитаем автоматически генерировать их с помощью биб,ш
отеки
Python под названием Troposphere
cloudtools/troposphere).
от Марка Пика
(Mark Peek)
(см.
Третья сторонняя служба также нацелена на эту проблему. Служба
крытым исходным кодом компании
HashiCorp,
Github. com/
Terraform
с от
является средством для построения
и изменения инфраструктуры независимо от особенностей облака.
Как и в службе
CloudFormation, вы описываете ресурсы в настраиваемом шаблоне,
Terraform создавать правильные вызовы API для реализации
а затем позволяете службе
вашей конфиrурации.
Затем вы можете проверить свой конфигурационный файл на управление версиJ1ми
и управлять инфраструктурой с течением времени.
9.4. ОБЛАКА: БЫСТРЫЙ ЗАПУСК VPS НА ПЛАТФОРМЕ
UNIX и Linux.
Эrот
короткий раздел поможет вам инсталлировать и запускать виртуальные серверы на
Облако
AWS,
GCP
или
-
отличная песочница, в которой можно изучить системы
Digita\Ocean.
В качестве системных администраторов мы активно используем
командную строку (в отличие от веб-графических интерфейсов) для взаимодействия с об
лаком, поэтому иллюстрируем
Веб-службы
здесь использование именно этих инструментов.
Amazon
Для того чтобы использовать AWS, сначала настройте учетную запись на сайте aws.
amazon. com. Создав учетную запись, немедленно следуйте инструкциям AWS Trusted
Advisor, чтобы настроить свою учетную запись в соответствии с предлагаемыми рекоменда
циями. Затем вы можете перейти к отдельным консолям обслуживания для ЕС2, VPC и т.д.
Каждая служба AWS имеет специальный пользовательский интерфейс. Когда вы
войдете в веб-консоль, вы увидите вверху список служб. Внутри Amazon каждая служ
ба управляется независимой командой, и, к сожалению, данный интерфейс отражает
этот факт. Хотя это решение помогло развивать АWS-службы, это приводит к несколь
ко фрагментированному опыту взаимодействия. Некоторые интерфейсы более удобны
и интуитивны, чем другие.
Для того чтобы защитить свою учетную запись, включите многофакторную аутенти
фикацию
(MFA) для
пользователя
root,
а затем создайте привилегированного пользова
теля \АМ для повседневного использования. Мы также обычно настраиваем псевдоним,
чтобы пользователи могли получить доступ к веб-консоли без ввода номера учетной за
писи. Эта опция находится на начальной странице службы
IAM.
В следующем разделе мы представляем официальный инструмент aws командной строки, написанный на
ваться службой быстрого запуска
интерфейс
Python. Новые пользователи также могут воспользо
Amazon Lightsail, целью которой ямяется запуск эк
земпляра ЕС2 с минимальными усилиями.
1. Основы администрирования
Часть
312
Интерфейс
Программа
AWS.
aws: управление
aws -
подсистемами
AWS
это унифицированный интерфейс командной строки для служб
Он управляет экземплярами, сохраняет резервные копии, редактирует записи
DNS
и выполняет большинство других задач, отображаемых в веб-консоли. Инструмент ос
нован на замечательной библиотеке
Boto, SDK Python для AWS API
Python.
помощью команды pip:
и работает в любой
системе с действующим интерпретатором
Установите этот инструмент с
$ pip install awscli
Для того чтобы использовать
aws, сначала выполните аутентификацию
AWS, используя пару случайных строк,
се прикладного программирования
в интерфей
называемых
идентификатором ключа доступа и секретным ключом доступа. Создайте эти учетные
данные в веб-консоли
IAM,
а затем скопируйте и вставьте их на местном уровне.
При выполнении команды
aws confiqure вам будет предложено
API и регион по умолчанию:
$ aws confiqure
AWS Access Кеу ID: AКIAIOSFODNN7EXAМPLE
AWS Secret Access Кеу: wJalrXUtnFEМI/K7МDENG/bPxRfiCYEXAМPLEКEY
Default region narne [us-east-1]:
Default output forrnat [None]:
установить учет
ные данные
Эти настройки сохраняются в файле-/
.aws/config.
Пока вы настраиваете среду,
мы также рекомендуем вам настроить функцию автозаполнения оболочки
bash,
чтобы
легче было обнаружить подкоманды. Дополнительная информация представлена в до
кументах
AWS CLI.
Первый аргумент команды
aws
называет конкретную службу, которой вы хотите мани
пулировать; например, ес2 ДllЯ действий, которые управляют веб-службой
Cloud.
бы увидеть инструкции. Так,
help
Elastic Compute
Вы можете добавить подсказку по ключевым словам в конце любой команды, что
aws help, aws
ес2
help
и
aws
ес2 descriЬe-instance
помогают создавать полезные справочные страницы.
Создание экземпляра ЕС2
m
Дополнительную информацию о команде
pip см.
в разделе
7.6.
Для создания и запуска экземпляров ЕС2 используйте команду
instances.
aws
ес2
run-
Хотя вы можете создавать несколько экземпляров с помощью одной коман
По умолчанию экземпляры ЕС2 в подсетях УРС не имеют подключенных общедо
ступных IР-адресов, что делает их доступными только из других систем в пределах одно
го УРС. Чтобы использовать экземпляры непосредственно из Интернета, задействуйте
параметр --associate-puЫic-ip-address, как показано в нашем примере. Вы може
те узнать назначенный lР-адрес постфактум с помощью команды
instances
aws
ес2
describe-
или путем поиска экземпляра в веб-консоли.
Брандмауэры в ЕС2 называются группами безопасности. Поскольку мы не указали
здесь группу безопасности,
AWS
принимает группу
default,
которая не дает доступа.
Чтобы подключиться к экземпляру, настройте группу безопасности, чтобы разрешить
выполнение алгоритма
SSH
с вашего IР-адреса. В сценариях реального мира структура
группы безопасности должна быть тщательно спланирована во время проектирования
сети. Мы обсуждаем группы безопасности в разделе
Команда
aws configure устанавливает область
13.15.
по умолчанию, поэтому вам не нуж
но указывать регион для экземпляра, если вы не хотите задать что-то, отличное от зна
чения, принятого по умолчанию.
и интерфейс
случае
AMI,
aws
AMI,
пара ключей и подсеть относятся к региону,
жалуется, если их нет в указанном вами регионе. (В этом конкретном
пара ключей и подсеть находятся в регионе
us-east-1.)
Часть
314
Обратите внимание на поле
Instanceld
1. Основы
администрирования
в списке результатов, которое является
уникальным идентификатором для нового экземпляра. Команда
instance -instance-id id выводит подробную
пляре, а команда aws ес2 describe-instances -
aws
ес2
describe-
информацию о существующем экзем
обо всех экземплярах в регионе.
Когда экземпляр запущен и группа безопасности по умолчанию настроена для пере
дачи трафика по ТСР-порту
22, вы можете использовать алгоритм SSH для входа в си
AMI настроены с учетной записью nonroot с привилегиями sudo.
Для системы Ubuntu имя пользователя - ubuntu; для CentOS - centos. FreeBSD
и Amazon Linux используют имя ec2-user. В документации для выбранного вами AMI
стему. Большинство
должно быть указано имя пользователя, если оно не является одним из них.
Правильно настроенные образы позволяют использовать только открытые ключи
для аутентификации
ключом
SSH,
SSH,
а не пароли. После того как вы вошли в систему с секретным
у вас будет полный доступ к
sudo
без необходимости пароля. Мы реко
мендуем отключить пользователя по умолчанию после первой загрузки и создать лич
ные учетные записи.
Просмотр журнала консоли
Отладка низкоуровневых проблем, таких как проблемы при запуске и ошибки диска,
может быть сложной задачей без доступа к консоли экземпляра. Интерфейс ЕС2 позво
ляет получить вывод консоли экземпляра, который может быть полезен, если экземпляр
находится в состоянии ошибки или, по-видимому, зависает. Вы можете сделать это че
рез веб-интерфейс или с помощью команды
aws
ес2
get-console-output,
как пока
зано ниже.
$ aws
ес2
qet-console-output --instance-id i-c4f60303
{
"Instanceld": "i-c4f60303",
"Timestamp": "2015-12-21T00:01:45.000Z",
"Output": "[ 0.000000] Initializing cgroup subsys cpuset\r\n[
0.000000] Initializing cgroup subsys cpu\r\n[ 0.000000]
Initializing cgroup subsys cpuacct\r\n[ 0.000000] Linux version
4.1.7-15.23.amznl.x86_64 (mockbuild@gobi-build-60006)
(gcc version 4.8.З 20140911 (Red Hat 4.8.3-9)) #1 SMP Mon Sep
14 23:20:33 UTC 2015\r\n
W Дополнительную информацию об управлении пользователями см. в главе 8.
Полный журнал, конечно, намного дольше, чем этот фрагмент. В дампе
JSON
со
держимое журнала, к сожалению, склеивается в одну строку. Для лучшей читаемости от
форматируйте его с помощью команды
sed.
$ aws ес2 qet-console-output --instance-id i-c4f60303 1 sed
's/\\r\\n/\\n/q'
"Instanceid": "i-c4f60303",
"Timestamp": "2015-12-21T00:01:45.000Z",
"Output": "[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000) Initializing cgroup subsys cpuacct
[ 0.000000) Linux version 4.l.7-15.23.amznl.x86_64
(mockbuild@gobi-build-60006) (gcc version 4.8.З 20140911
Глава
9. Облачные вычисления
315
(Red Hat 4.8.3-9)) #1 SMP Mon Sep 14 23:20:33 UTC 2015
Эта запись журнала поступает непосредственно из процесса загрузки
Linux.
В приве
денном выше примере показано несколько строк с момента инициализации экземпляра.
В большинстве случаев вы найдете самую интересную информацию в конце журнала.
Остановка и завершение работы экземпляров
Когда вы закончите работать с экземпляром, вы можете остановить
(stop)
его, чтобы
закрыть экземпляр, но сохранить его для последующего использования, или завершить
(terminate)
его, чтобы полностью удалить экземпляр. По умолчанию завершение также
полностью освобождает корневой диск экземпляра. После прекращения работы экзем
Обратите внимание на то, что виртуальные машины не меняют состояние мгновен
но; им требуется перезагрузка. Следовательно, суmествуют переходные состояния, такие
как начало
(starting)
и остановка
(stopping).
Обязательно учитывайте их в любых сцена
риях, которые вы можете написать.
Google Cloud Platform
Для того чтобы начать работу с платформой
cloud. goog le. com.
GCP,
создайте учетную запись на сайте
Если у вас уже есть идентификатор
Google,
вы можете зарегистри
роваться в той же учетной записи.
Службы
GCP
работают в разделе, известном как проект. В каждом проекте есть от
дельные пользователи, данные о счетах и учетные данные
API,
поэтому вы можете до
стичь полного разделения между разрозненными приложениями или областями бизне
са. Создав свою учетную запись, создайте проект и включите отдельные службы
в соответствии с вашими потребностями.
Google Compute Engine,
служба
VPS,
GCP
является
одной из первых служб, которые вы, возможно, захотите включить.
Настройка
gcloud
Программа
Python, является инструментом CLI
Google Cloud SDK, который содержит множество библиотек
и инструментов для взаимодействия с GCP. Чтобы установить его, следуйте инструкци
ям по установке на сайте cloud. goog le. com/ sdk.
для
GCP.
gcloud,
Это компонент
приложение на языке
Часть
316
1. Основы
администрирования
Первое действие должно состоять в том, чтобы настроить среду, выполнив команду
gcloud ini t.
Эта команда запускает небольшой локальный веб-сервер, а затем откры
вает ссылку браузера для отображения пользовательского интерфейса
тификации. После аутентификации через веб-браузер
gcloud
аутен
Google для
попросит вас (в оболоч
ке) выбрать профиль проекта, зону по умолчанию и другие значения по умолчанию.
Настройки сохраняются в файле~/.
Выполните команду
config/gcloud/.
gcloud help для получения общей
информации или
gcloud -h
для краткого описания использования. Также доступна помощь по подкоманде; например,
команда
gcloud help compute
показывает справочную страницу для службы
Compute
Engine.
Запуск экземпляра на
GCE
В отличие от команд
gcloud compute
aws,
которые немедленно возвращают управление, команда
работает синхронно. Например, когда вы выполняете команду
для запроса нового экземпляра, команда
gcloud делает
необходимый вызов
API,
create
а затем
ждет, пока экземпляр не будет настроен и запущен, а затем возвращает его. Это соглаше
ние позволяет избежать необходимости опроса состояния экземпляра после его создания. 6
Для того чтобы создать экземпляр, сначала определите имя или псевдоним образа,
которое вы хотите загрузить:
$ gcloud compute images list --regexp 'debian.*'
ALIAS
PROJECT
DEPRECATED STATUS
READY
READY
NАМЕ
deЬian-7-wheezy-v20160119
deЬian-cloud
deЬian-7
deЬian-8-jessie-v20160119
deЫan-cloud
deЬian-8
Затем создайте и загрузите экземпляр, указав его имя и образ.
Обычно результаты работы этой команды содержит столбец, который показывает,
является ли экземпляр вытесняемым, но в этом случае он был пустым, и мы удалили
его, чтобы уместить вывод на странице. Вытесняемые экземпляры менее дороги, чем
стандартные экземпляры, но они могут работать только
прекращена в любое время, если
Google
24
часа и их работа может быть
нуждается в ресурсах для другой цели. Они
предназначены для долговременных операций, которые могут допускать перерывы, на
пример задания пакетной обработки.
Вытесняемые экземпляры аналогичны спот-экземплярам ЕС2 в том смысле, что вы
платите дисконтированную ставку за остальную резервную емкость. Тем не менее мы
обнаружили, что вытесняемые экземпляры
нии, чем спот-экземпляры
AWS.
Google
более разумны и проще в управле
Однако долговременные стандартные экземпляры оста
ются наиболее подходящим выбором для большинства задач.
Программа
gcloud
инициализирует экземпляр публичным и частным IР-адресом.
Вы можете использовать публичный IР-адрес с алгоритмом
имеет полезную оболочку для упрощения входа в систему
SSH,
SSH:
но программа
gcloud
$ gcloud compute ssh ulsah
Last login: Mon Jan 25 03:33:48 2016
ulsah:-$
6 Выполните
вAWS ЕС2.
команду
aws
ес2
wai t
для получения информации об опросе событий или состояний
глава
9. Облачные
вычисления
317
DigitalOcean
С объявленным временем загрузки
ты)
55
с виртуальные серверы
DigitalOcean
(дропле
это самый быстрый путь к корневой оболочке. Стоимость начального уровня со
-
ставляет
m
5 долл.
США в месяц, поэтому они также не разорят вас.
Дополнительную информацию о настройке "драгоценных камней"
Ruby см.
в разделе
7.6.
После создания учетной записи вы можете управлять своими дроплетами через веб
сайт
DigitalOcean.
Тем не менее нам удобнее применять буксир, инструмент команд
ной строки, написанный на языке
Ruby,
Предположим, что у вас есть
DigitalOcean.
который использует опубликованный
Ruby
и его менеджер библиотеки,
новленный в локальной системе. Для инсталляции программы
ните команду
gem,
API
уста
просто выпол
tugboat
gem install tugboat.
Необходимо выполнить несколько этапов настройки. Сначала создайте пару крипто
графических ключей, которые вы можете использовать для контроля доступа к дроплетам.
$ ssh-keygen -t rsa -Ь 2048 -f "/.ssh/id_rsa_do
Generating puЫic/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/ben/.ssh/id_rsa_do.
Your puЫic key has been saved in /Users/ben/.ssh/id_rsa_do.pub.
Скопируйте содержимое файла открытого ключа и вставьте его в веб-консоль
DigitalOcean
(в настоящее время в разделе Setting~Security). В рамках этого процесса
назначьте короткое имя открытому ключу.
Затем подключите программу
tugboat API DigitalOcean, введя токен доступа, кото
tugboat сохраняет токен для будущего ис
файле"/. tugboat.
рый вы получите с веб-сайта. Программа
пользования в
W Дополнительную информацию об алгоритме SSH см. в разделе 22.7.
$ tugboat authorize
Note: You can get your Access Token from https://cloud.digitalocean.com/
settings/tokens/new
Enter your access token: e9dffla9a7ffdd8faf3".f37b015b3d459c2795bб4
Enter your SSH key path (defaults to -/.ssh/id_rsa): "/.ssh/id_rsa_do
Enter your SSH user (optional, defaults to root):
Enter your SSH port numЬer (optional, defaults to 22):
Enter your default region (optional, defaults to nycl): sfol
Authentication with DigitalOcean was successful.
Чтобы создать и запустить дроплеты, сначала укажите имя образа системы, который
вы хотите использовать в качестве базовой. Например, так.
Вам также нужен цифровой идентификатор
ного в веб-консоль.
DigitalOcean
для ключа
SSH,
вставлен
318
Часть
1. основы
администрирования
$ tuqboat keys
SSH Keys:
Name: id_rsa_do, (id: 1587367), fingerprint:
bc:32:3f:4d:7d:b0:34:ac:2e:3f:Ol:fl:el:ea:2e:da
Этот вывод показывает, что числовой идентификатор для ключа с именем
do равен 1587367. Создайте и запустите дроплеты следующим образом:
id rsa
-
$ tuqboat create -i uЬuntu-16-04-x64 -k 1587367 ulsah-uЬuntu
queueing creation of droplet 'ulsah-ubuntu' ... Droplet created!
Здесь аргумент -k -
это идентификатор ключа
SSH,
а последний аргумент
-
корот
кое имя для дроплета, которое вы можете назначить по своему усмотрению.
Как только дроплет загрузится, вы можете войти в систему с помощью команды
tugboat ssh.
$ tuqboat ssh ulsah-uЬuntu
Droplet fuzzy name provided. Finding droplet ID ... done, 23754420
(ubuntu-16-04-x64)
Executing SSH on Droplet (ubuntu-16-04-x64) ...
This droplet has а private IP, checking if you asked to use the Private IP ...
You didn't! Using puЫic IP for ssh ...
Attempting SSH: root@45.55.l.165
Welcome to Ubuntu 16.04 ((GNU/Linux 4.4.0-28-generic х86_64)
root@ulsah-ubuntu:-#
Вы можете создать столько дроплетов, сколько вам нужно, но имейте в виду, что вам
будет выставлен счет за каждый из них, даже если он выключен. Чтобы отключить дроплет,
выполните команду
tugboat snapshot
мок памяти системы, и команду tugЬoat
имя-дроплета имя-снимка, чтобы сделать сни
destroy
имя-дроплета, чтобы отключить дро
плет. Позднее вы можете воссо:щать дроплет, используя снимок в качестве исходного образа.
9.5.
КОНТРОЛЬ ЗАТРАТ
Новички в облачных вычислениях часто наивно предполагают, что крупномасштабные
системы будут значительно дешевле работать в облаке, чем в дата-центре. Это ожидание
может быть связано с превратной интерпретацией низкой стоимости часа работы с экзем
пляром на облачной платформе. Кроме тоrо, возможно, пользователи поддаются уговорам
облачных маркетологов, чьи тематические исследования всегда показывают огромную
экономию.
Независимо от их источника, мы обязаны отбросить надеж:ды и оптимизм. По наше
му опыту, новые пользователи облачных вычислений часто удивляются, когда затраты
быстро растут.
Тарифы облака обычно состоят из нескольких компонентов.
•
Вычислительные ресурсы виртуальных частных серверов, балансировщиков на
грузки и всеrо остального, которые потребляют циклы процессора для запуска ва
ших служб. Цена взимается за час использования.
•
Передача данных в Интернете (как входящая, так и исходящая), а также трафик
меж:ду зонами и регионами. Цены взимаются за двоичные гига- или терабайты.
•
Хранилища всех типов: блочные тома хранения, объектные хранилища, момен
тальные снимки диска, а в некоторых случаях и операции ввода-вывода в раз
личных постоянных хранилищах. Взимается цена за каж:дый двоичный гига- или
терабайт в месяц.
Глава
9. Облачные
вычисления
319
Для вычислительных ресурсов наиболее дорогостоящей является модель "плати или
иди", также известная как "ценообразование по требованию". У
AWS и DigitalOcean мини
GCP - минута. Цены варьируются
от долей процента в час (самый маленький тип дроплета DigitalOcean с 512 Мбайт и одним
ЯдРОМ процессора или экземплярами AWS t2. nano) до нескольких долларов в час (экзем
пляр i2. 8xlarge в AWS с 32 ядрами, ОЗУ 104 ГиБ и 8 х 800 Г5 локальных SSD).
мальный интервал биллинrа составляет один час, а на
Вы можете добиться существенной экономии на виртуальных серверах, заплатив
авансом за более длительные сроки. В компании
AWS
это называется "ценой зарезерви
рованных экземпляров". К сожалению, чтобы точно определить, что покупать, необхо
димо выполнить очень тяжелую и длительную работу.
Зарезервированные экземпляры ЕС2 привязаны к определенному семейству экзем
пляров. Если позже вы решите, что вам нужно что-то другое, ваши инвестиции будут
потеряны. С другой стороны, если вы зарезервируете экземпляр, вам гарантируется, что
он будет доступен для вашего использования. С экземплярами по запросу желаемый
тип может быть недоступен даже при его установке, в зависимости от текущей емкости
и спроса.
AWS
продолжает корректировать свою структуру ценообразования, поэтому,
к счастью, нынешняя система может быть упрощена в будущем.
Для рабочих нагрузок, которые допускают перерывы,
образование. Спот-рынок
-
AWS
предлагает точечное цено
это аукцион. Если ваша ставка превышает текущую спот
цену, вам будет предоставлен тип запрашиваемого вами экземпляра, пока цена не пре
высит максимальную ставку, после чего работа вашего экземпляра будет прервана. Цены
могут быть значительно снижены по сравнению с ЕС2 по требованию и зарезервирован
ным ценам, но варианты использования ограничены.
Сравнить цены на
Google Compute Engine
достаточно просто. При длительном ис
пользовании автоматически применяются скидки, и вы никогда не будете платить аван
сом. Вы платите полную базовую цену за первую неделю месяца, а инкрементная цена
падает каждую неделю на
20%
от базовой ставки до максимальной скидки
скидка на полный месяц использования составляет
30%.
60%.
Чистая
Это примерно сопоставимо
с дисконтом на один год зарезервированного экземпляра ЕС2, но вы можете изменять
экземпляры в любое время. 7
Еще более сложно прогнозировать сетевой трафик. Факторы, которые, как правило,
вызывают высокие затраты на передачу данных, включают в себя следующее.
•
Веб-сайты, которые загружают и обслуживают большие мультимедийные файлы
(видео, образы, РDF-файлы и другие крупные документы) непосредственно из об
лака, а не выгружают их в
•
CDN.
Межзонный или межрегиональный трафик для кластеров баз данных, которые ре
плицируются для отказоустойчивости; например, программное обеспечение, такое
как
Cassandra, MongoDB и Riak.
• MapReduce или кластер хранилищ данных, которые охватывают несколько зон.
• Образы дисков и снимки томов, передаваемые между зонами или регионами
для резервного копирования (или другим автоматическим процессом).
В ситуациях, когда репликация между несколькими зонами важна для обеспечения
доступности, вы сэкономите на трансферных расходах, ограничив кластеры до двух зон,
7 Совет
для бережливых людей: поскольку схема скидок связана с вашим биллинrовым циклом, время
переходов имеет значение. Вы можете переключать типы экземпляров в начале или в конце цикла
без штрафа. Наихудший случай заключается в том, чтобы переключаться на полпуrи биллинговоrо
цикла. Эго переключение штрафуется примерно на
20% от месячной
базовой ставки экземпляра.
Часть
320
1. Основы
администрирования
а не используя три или более. Некоторые программы предлагают такие настройки, как
сжатие, которое может уменьшить количество реплицированных данных.
Существенным источником расходов на
вывода
(IOPS) ДllЯ
томов
AWS является
EBS (Extemal BLOB Storage). Цены
количество операций ввода
за использование
ются за количество двоичных гигабайтов в месяц и за количество операций
Цена за
200
IОайт
EBS объемом 5000 IOS составляет
EBS взима
IOPS в месяц.
несколько сотен долларов в месяц. Их
кластер может разорить компанию.
Лучшая защита от высоких счетов
-
это измерение, мониторинг и трезвый расчет.
Используйте функции автомасштабирования для удаления емкости, когда это не требу
ется, снижая затраты в периоды низкого спроса. Используйте более мелкие экземпляры
для более детального управления. Следите за шаблонами использования, прежде чем
тратить пакет на зарезервированные экземпляры или объемы с высокой пропускной
способностью. Облако является гибким, и вы можете вносить изменения в свою инфра
структуру по мере необходимости.
W Дополнительную информацию об CDN см. в разделе 19.2.
Окружающая среда ЦС растет, выявление того, где деньги расходуются, может стать
проблемой. Большим облачным учетным записям могут быть полезны сторонние служ
бы, которые анализируют использование и предлагают функции отслеживания и от
четности. Мы использовали
выставления счетов
AWS
Cloudabllity
и
CloudHealth.
Оба подключаются к функциям
для разбивки отчетов по пользовательскому тегу, сервису или
географическому местоположению.
9.6. ЛИТЕРАТУРА
•
Wптю, ANDREлs,
PuЫications,
AND
М1снлЕL Wптю.
Amazon Web Services
/п
Action. Manning
2015.
• GooGLE. cloudplatforт. googleЫog. сот. Официальный блог Google Cloud
Platfonn .
• BARR, JEFF, AND OTHERS АТ АмлzоN WEB SERVICES. aws. aтazon. coт/Ыogs/aws.
Официальный блог Amazon Web Services.
• Dю1тлLОСЕАN. digitalocean.coт/coтpany/Ьlog. Технический и производствен
ный блог DigitalOcean.
• VoGELS, WERNER. А/1 Things Distributed. all thingsdistributed. сот. Блог Вернера
Фогельса (Wemer \Ьgels), технического директора компании Amazon.
• WлRDLEY, S1мoN. Bits or pieces? Ыоg. gardeviance. org. Блог исследователя и за
конодателя мод в области облачных технологий Саймона Уордли (Simon Wardley),
содержащий анализ тенденций в области облачных технологий, а иногда и резкую
критику.
•
В1лs, RлNDY.
OpenStack,
cloudscaling.
сот/Ыоg. Рэнди Байес
-
директор компании
имеющий инсайдерскую информацию об индустрии частных облаков
и его будущем.
•
CлNТRJLL,
BRYAN. The Observation Deck. dtrace. org /Ыogs /Ьтс.
Интересные точ
ки зрения и технические идеи о вычислениях технического директора компании
Joyent,
•
разработавшей специальную, но очень интересную платформу.
АмлzоN.
youtube.
coт/AтazonWebServices. Выступления на конференциях
и другие видеоматериалы от компании
AWS.
глава
10
Журналирование
Системные демоны, ядро, утилиты и приложения
-
все они генерируют журнальные
данные, которые регистрируются и попадают на далеко не безразмерные диски. Срок
полезной службы большинства данных ограничен, поэтому их приходится группиро
вать, сжимать, архивировать и, наконец, удалять. Доступом и журналами аудита необхо
димо управлять точно в соответствии с регулятивными правилами хранения информа
ции или политикой безопасности, принятой для вашего хоста.
В большинстве случаев регистрируемое событие перехватывается в виде одной стро
ки текста, которая включает временную метку, тип и степень серьезности события,
а также имя и идентификатор процесса. Системные администраторы несут ответствен
ность за извлечение полезной информации из этого потока сообщений.
Данная задача называется управлением журналами, и ее можно разделить на несколь
ко основных подзадач.
•
•
Сбор журналов из различных источников.
Предоставление структурированного интерфейса для запросов, анализа, фильтра
ции и мониторинга сообщений.
•
Управление хранением и истечением срока действия сообщений, чтобы инфор
мация сохранялась до тех пор, пока она потенциально полезна или юридически
необходима, но не на неопределенный срок.
322
Часть
1. Основы
администрирования
Система
UNIX исторически упрамяет журналами через интегрированную, но несколько
syslog, коrорая предстамяет приложения со стан
дартизованным интерфейсом для отправки сообщений журнала. Демон syslog сортирует
рудиментарную систему, известную как
сообщения и сохраняет их в файлы или пересьтает их другому хосту по сети. К сожалению,
syslog
решает только первую из перечисленных выше задач регистрации (сбор сообще
ний), а ее конфиl)'рация сильно варьируется среди операционных систем.
Возможно, из-за недостатков демона
многие приложения, сетевые демоны,
syslog
сценарии запуска и другие средства ведения журнала полностью обходят
syslog
и запи
сывают сообщения в свои собственные файлы. Это привело к тому, что в разных версиях
U N IX и даже
среди дистрибутивов Liпux журналы значительно отличаются друг от друга.
Журнал
systemd
от
Linux
представляет собой вторую попытку привнести
здравомыслие в этот беспорядок. Журнал собирает сообщения, сохраняет их
в индексированном и сжатом двоичном формате и предоставляет интерфейс
командной строки для просмотра и фильтрации журналов. Журнал может
существовать в одиночестве или сосуществовать с демоном
syslog с
разной
степенью интеграции в зависимости от конфигурации.
Разнообразные сторонние инструменты (как запатентованные, так и с открытым ис
ходным кодом) затрагивают более сложную проблему отбора сообщений, которые по
ступают из большой сети систем. Эти инструменты включают такие вспомогательные
средства, как графические интерфейсы, языки запросов, визуализация данных, опове
щение и автоматическое обнаружение аномалий. Они могут масштабироваться для об
работки томов сообщений порядка терабайт в день. Вы можете подписаться на эти про
дукты в виде облачной службы или разместить их самостоятельно в частной сети.
На рис.
10.1
изображена архитектура сайта, на котором используются все службы
упрамения журналами, упомянутые выше. Администраторы и другие заинтересован
ные стороны могут запускать графический интерфейс централизованного журнально
го кластера для просмотра сообщений журнала, поступающих из систем по всей сети.
Администраторы могут также регистрироваться на отдельных хостах и получать доступ
к сообщениям через журнал
syslog.
systemd
или файлы обычного текста, записанные демоном
Если эта диаграмма вызывает у вас больше вопросов, чем ответов, вы читаете
правильную главу.
При отладке проблем и устранении ошибок опытные администраторы в первую
очередь обращаются к журналам. Файлы журналов часто содержат важные подсказки,
указывающие на источник неприятных ошибок конфигурации, ошибок программного
обеспечения и проблем безопасности. Журналы
-
это первое место, которое вы долж
ны посмотреть, если демон дал сбой или произошел отказ от его запуска либо возникла
хроническая ошибка при загрузке системы.
После принятия официальных стандартов, таких как
PCI DSS,
СОВП и
ISO 27001,
и достижения зрелости регуляторных норм в отдельных отраслях важность четко опре
деленной журнальной стратегии возросла. В настоящее время эти внешние стандарты
могут потребовать, чтобы для ведения журнала вы поддерживали централизованный
репозитарий предприятия с временными метками, подтвержденными протоколом
(Network
Тime
Protocol)
NTP
и строго определенным графиком хранения. 1 Однако даже ор
ганизации, не имеющие нормативных требований или требований соответствия, могут
извлечь выгоду из централизованного ведения журналов.
1 Конечно,
точное системное время имеет значение даже без наличия регуляторных норм. Мы
настоятельно рекомендуем включить протокол
NTP дЛЯ
всех ваших систем.
Глава
1О.
Журналирование
323
Источники журналов
в
в
NTP
cron
друrи@
syslog
systemd-journal
Apach@ httpd
SSH
..•
Двоичный журнал
Источники журналов
Обычные текстовые файлы
syslog
Apach@ httpd
SSH
NTP
cron
друrи@ ...
--------~ Обычные текстовые файлы
Рис.
10.1. Архитектура
Централизованный
кластер журналов
централизованной журнальной системы
В этой главе описывается собственное программное обеспечение для управле
ния журналами, используемое в системах
systemd
и приложение
logrotate.
Linux
и
FreeBSD,
включая
syslog,
журнал
Мы также вводим некоторые дополнительные ин
струменты для централизации и анализа журналов по всей сети. Глава закрывается не
которыми общими советами для создания разумной политики управления журналом.
10.1.
МЕСТОПОЛОЖЕНИЕ ФАЙЛОВ РЕГИСТРАЦИИ
Систему
UNIX
часто критикуют за несогласованность, и эта критика вполне спра
ведлива. Посмотрите на содержимое каталога файлов регистрации
найдете файлы с такими именами, как
maillog, cron. log
-
вы обязательно
и, возможно, еще нечто
специфичное для демонов и дистрибутивов. По умолчанию большинство этих файлов
хранится в каталоге
/var/adm
или
/var/log,
но некоторые приложения разбрасывают
журнальные файлы по файловым системам.
В табл.
10.1
представлена информация о наиболее часто используемых журнальных
файлах демонстрационных дистрибутивов. Указаны, в частности, следующие сведения:
•
•
•
•
•
журнальные файлы, подлежащие архивированию или другой обработке;
программа, создающая каждый из этих файлов;
информация о том, где задается имя файла;
периодичность удаления устаревшей информации, которая считается приемлемой;
системы (из числа демонстрационных), в которых используется каждый из этих
файлов;
•
описание содержимого файлов.
Имена файлов в табл.
иное.
10. \
даны относительно каталогов,
/var/log, если не указано
10.1 контролируются
Многие журнальные файлы из числа перечисленных в табл.
системой
Syslog,
а остальные
-
приложениями.
Часть
324
Таблица
1.
Основы администрирования
10.1. Журнальные файлы
ФаАл
Проrрамма
Место" Частота• СистемЫ" Содерасимое/наэначение
apache2/*
httpd
ф
д
АРТ
ф
м
D
D
Журналы НПР-сервераАрасhе (версия
apt*
auth.log
boot.loq
sudoидp. 6
s
м
DF
Авторизационные сообщения
Сценарииrс
ф
м
R
Выходная информация сценариев запуска
cloud-init
ф
2)
Программы для инсталляции
программных пакетов
cloudinit.log
Выходная информация сценариев запуска
облаков
cron,cron/ cron
log
daemon.
Различные
loq
s
s
н
д
н
RA
Сведения о выполнении и об ошибках
демонасrоn
c\eЬuq*
Различные
s
dmesq
dpkq.loq
Ядро
в
dpkq
ф
failloq"
loqin
н
httpd/*
kern.loq
httpd
ф
д
Ядро
s
н
lastloq
loqin
в
D*
Все сообщения средств демона
F, D*
Отладочные сообщения
все
Образ буфера сообщений ядра
м
u
Журнал управления пакетом
н
D*
Сообщения о неудачных попытках
R
Журналы НПР-сервера Apache
D
Все сообщения средств ядра
R
Время последней регистрации в системе
регистрации в системе
каждого пользователя (бинарный файл)
mail*
Связанные с элек-
s
н
RF
Все сообщения средств электронной
R
Основной системный журнальный файл
тронной почтой
ПОЧ1ЪI
messaqes
Различные
s
н
saJDЬa/*
smЬdидр.
ф
н
SamЬa (совместное использование
файлов в системах Wпdows/SMB)
secure
sshdидp. 6
s
м
R
Конфиденциальные авторизационные
сообщения
suloq
su
ф
sysloq*
Различные
s
н
D
Основной системный журнальный файл
wtmp
loqin
в
м
RD
Сообщения о регистрации в системе
xen/*
Хеп
ф
1m
RD
SAH
Учет удачных и неудачных попыток
использования команды
su
(бинарный файл)
Информация от монитора виртуальных
машинахХеп
Xorq.n.loq Xorq
ф
н
R
Сообщения об ошибках сервера
XWпdows
yum.loq
yum
ф
м
R
Журнал управления пакетом
'Здесь используются следующие обозначения:
: Ф - конфигурационный файл, В - встроенный, S - Syslog,
в столбце "Частота": Д- ежедневно, Н - еженедельно, М - ежемесячно, Nмn - зависит от размера(например,
1m - мегабайт),
в столбце "Системы": D - Deblan и Ubuntu, D* - только Deblan, R - Red Hat и CeпtOS, F - FreeBSD.
в столбце "Место"
б Команды passwd, sshd, login и shutdown тоже записывают информацию в журнал авторизации.
'Двоичный файл, который должен быть прочитан с помощью утилиты
faillog.
Глава
10. Журналирование
325
Журнальные файлы обычно принадлежат пользователю
root,
хотя соглашения
о владельцах и режимах доступа к этим файлам не одинаковы в разных системах. В не
которых случаях менее привилегированный демон (такой как
httpd
или
mysqld)
может
потребовать доступ для записи, а затем определить ее владельца и режим работы соот
ветственно. Вам, возможно, для просмотра важных журнальных файлов, которые имеют
строгие разрешения доступа, придется использовать команду
m
sudo.
Дополнительную информацию о разделении диска см. в разделе 20.б.
Журнальные файлы могут очень быстро увеличиваться в размере, особенно это каса
ется файлов для службы электронной почты, веб- и DNS-cepвepoв. Неконтролируемый
файл регистрации может заполнить весь диск и тем самым вывести систему из строя.
Поэтому мы предпочитаем определять раздел
/var/109
как отдельный раздел диска
или отдельную файловую систему. (Этот совет одинаково полезен как для облачных эк
земпляров, и частных виртуальных машин, так и для физических серверов.)
Специальные журнальные файлы
Большинство журнальных файлов
-
это обычные текстовые файлы, в которые запи
сываются сообщения о "важных" событиях. Но некоторые файлы из числа перечислен
ных в табл.
Файл
10.1
имеют совершенно другое назначение.
wtmp (иногда wtmpx) содержит записи о том, когда пользователи входили в систе
му и выходили из нее, а также когда система выключалась или перезагружалась. Это до
вольно простой файл (новые записи просто добавляются в конец), тем не менее он хранится
в бинарном виде. Расшифровать содержимое файла можно с помощью команды
В файле
lastlog регистрируется
last.
время последнего входа в систему каждого пользовате
ля. Это разреженный бинарный файл, записи которого индексируются по идентификатору
пользователя
UID.
Размер файла будет меньше, если назначать идентификаторы по поряд
ку, хотя вряд ли об этом стоит сильно беспокоиться. Файл
lastlog
не должен участвовать
в цикле ротации, поскольку его размер в большинстве случаев остается неизменным.
Кроме того, некоторые приложения (особенно базы данных) создают двоичные фай
лы транзакций. Не пытайтесь управлять этими файлами и даже просматривать их, иначе
терминальное окно выйдет из строя.
Как просмотреть записи в журнале
В системах
Linux,
systemd
в которых ведется журнал
собом просмотра записей является команда
сообщения из журнала
systemd.
нале или, указав флаг -u, -
systemd, самым простым и легким спо
journalctl, которая выводит на экран
Сообщения можно фильтровать и устанавливать другие ограничения, такие как интер
вал времени, идентификатор процесса и даже путь к конкретному выполняемому файлу.
Например, следующая выходная информация извлечена из записей журнала о демо
не
SSH:
$ journalctl -u ssh
-- Logs begin at Sat 2016-08-27 23:18:17 uтс, end at Sat 2016-08-27
23:33:20 uтс. -Aug 27 23:18:24 uxenial sshd[2230]: Server listening on О.О.О.О port 22.
Aug 27 23:18:24 uxenial sshd[2230]: Server listening on :: port 22.
Aug 27 23:18:24 uxenial systemd[l]: Starting Secure Shell server ...
Aug 27 23:18:24 uxenial systemd[l]: Started OpenBSD Secure Shell server.
326
Часть
1. Основы
администрирования
Aug 27 23:18:28 uxenial sshd[2326]: Accepted puЫickey for bwhaley from
10.0.2.2 port 60341 ssh2: RSA SHA256:aaRfGd10untn758+UCpxL7gkSwcs
zkAYe/wukrdBATc
Aug 27 23:18:28 uxenial sshd[2326]: pam_unix(sshd:session): session
opened for user bwhaley Ьу (uid=O)
Aug 27 23:18:34 uxenial sshd[2480]: Did not receive identification string
from 10.0.2.2
С помощью команды
journalctl -f
можно выводить на экран новые сообщения
по мере их постуШiения. Это эквивалент любимой команды
tail -f,
позволяющей сле
дить за добамяемыми текстовыми файлами по мере их постуШiения.
В следующем разделе мы рассмотрим демон systeшd-journald и его конфиrурацию.
10.2. ЖУРНАЛ
Журнал
SYSTEМD
systemd
должен был заменить все остальные подсистемы
и поэтому он содержит демон регистрации с именем
Linux
systemd-journald.
Он выполняет большинство функций, связанных с регистрацией событий,
в зависимости от конфигурации системы. Если вы сомневаетесь. стоит ли
переходить на
systemd,
потому что
syslog
и так делает все, что вам нужно,
посвятите немного времени изучению возможностей
systemd.
После этого
вы убедитесь в его преимуществах.
В отличие от системы
стовых файлах, журнал
syslog, которая обычно сохраняет сообщения журнала в тек
systemd хранит сообщения в двоичном формате. Все атрибуты
сообщений индексируются автоматически, что делает журнал проще и быстрее для по
иска. Как обсуждалось выше, вы можете использовать команду
journalctl
для про
смотра сообщений, хранящихся в журнале.
Журнал собирает и индексирует сообщения из нескольких источников.
•
Сокет
/dev/log для
сбора сообщений от программного обеспечения, отпрамяю
щего сообщения согласно соглашениям системы
•
Syslog.
Файл устройства /dev/Шsg для сбора сообщений от ядра
мон
systemd
заменяет традиционный процесс
klogd,
Linux.
вал этот канал и перенапрамял сообщения от ядра в систему
•
Сокет
UNIX /run/systemd/journal/stdout для
Журнальный де
который ранее прослуши
Syslog.
обслуживания программного
обеспечения, которое записывает сообщения журнала в стандартный вывод.
UNIX /run/systemd/journal для сервисного программного обеспечения,
API журнала systemd.
• Сообщения аудита от демона ядра audi td.
Смелые администраторы моrут использовать утилиту systemd-journal-remote
ее аналоги, systemd-journal-gateway и systemd-journal-upload) для потоко
•
Сокет
отпрамяющего сообщения через
(и
вой передачи сериализованных сообщений журнала по сети в удаленный журнал. К со
жалению, эта функция не постамяется предустановленной в обычных дистрибутивах.
На момент написания данного текста эти пакеты были доступны для систем
и
Ubuntu,
но не для
Red Hat
или
CentOS.
Deblan
Мы ожидаем, что в ближайшее время эта ситу
ация будет испрамена; тем временем мы рекомендуем придерживаться системы
если вам нужно пересьшать сообщения журналов между системами.
Syslog,
Глава
1о.
Журналирование
327
Настройка журнала
systemd
Конфигурационный файл журнала ло умолчанию
conf;
- /etc/systemd/journald.
однако этот файл не предназначен для прямого редактирования. Вместо этого до
бавьте свои настроенные конфигурации в каталог
Любые файлы, размещенные там с расширением
/ etc/ systemd/ j ournald. conf. d.
. conf, автоматически включаются
в конфигурацию. Чтобы настроить собственные параметры, создайте в этом каталоге
новый файл с расширением
По умолчанию файл
. conf и включите нужные параметры.
j ournald. conf содержит прокомментированную
версию
каждой возможной опции, а также значение по умолчанию каждого параметра, по
этому вы ~.tожете сразу увидеть, какие опции доступны. Они включают в себя мак
симальный размер журнала, период хранения сообщений и различные ограничения
скорости.
Опция
Storage
определяет, следует ли сохранять журнал на диск. Возможные зна•1е
ния несколько сбивают с толку:
• volatile сохраняет журнал только в памяти.
• persistent сохраняет журнал в каталоге /var/log/journal/,
создавая его при
необходимости.
• auto сохраняет журнал
в каталоге
/var/log/journal/,
но не создает каталог. Это
значение по умолчанию.
• none
удаляет все данные журнала.
Большинство дистрибутивов
пользуют значение
auto
Linux
(включая все наши примеры) по умолчанию ис
и содержат каталог
/var/log/journal.
Следовательно, жур
нал не сохраняется между перезагрузками по умолчанию, что является неудачным.
Вы можете изменить это поведение либо путем создания каталога
journal,
/var/log/
либо путем обновления журнала для использования постоянного хранилища
systemd-journald:
# mkdir /etc/systemd/journald.conf.d/
# cat /etc/systemd/journald.conf .d/storage.conf
[Journal]
Storage=persistent
END
# systemctl restart systemd-journald
и перезапуска
Эта серия команд создает настраиваемый каталог конфигурации
создает файл конфигурации, чтобы установить параметр
и перезапускает журнал, чтобы новые настройки вступили в
создаст каталог и сохранит журнал. Мы рекомендуем выполнить это
изменение для всех систем; было бы очень обидно терять все данные журнала при каж
дой перезагрузке системы.
Одним из самых неожиданных параметров журнала является
Seal, что позволяет
Forward Secure Sealing (FSS) повысить целостность сообщений журнала. При
включенной системе FSS сообщения, отправленные в журнал, не могут быть измене
системе
ны без доступа к паре криптографических ключей. Вы сами генерируете пару ключей,
выполнив команду
страницам
для файла
обзор этой
опции.
journalctl --setup-keys. Обратитесь к справочным
journald.conf и команды journalctl, чтобы увидеть полный
Часть
328
1. Основы
администрирования
Добавление дополнительных параметров
фильтрации для журнала
В конце разделе
10.1. мы привели короткий пример поиска журнала с помощью ко
journalctl. В этом разделе мы покажем несколько дополнительных способов
использования команды journalctl для фильтрации сообщений и сбора информации
манды
о журнале.
Для того чтобы нормальные пользователи могли читать из журнала без необходимых
разрешений
sudo, добавьте их в группу UNlX systemd-journal.
-disk-usage показывает размер журнала на диске.
# journalctl --disk-usage
Journals take up 4.ОМ on disk.
Опция
Параметр
-list-boots
показывает последовательный список системных загрузок
с числовыми идентификаторами. Самая последняя загрузка всегда имеет идентифика
тор, равный О. Даты в конце строки показывают временные метки первого и последнего
сообщений, сгенерированных во время этой загрузки.
# journalctl --list-boots
-1 сеО ... Sun 2016-11-13 18:54:42 UTC-Mon 2016-11-14 00:09:31
о 844 ... Mon 2016-11-14 00:09:38 UTC-Mon 2016-11-14 00:12:56
Вы можете использовать опцию -Ь, чтобы ограничить отображение журнала опреде
ленным сеансом загрузки. Например, для просмотра журналов, сгенерированных алго
ритмом
SSH
во время текущего сеанса:
# journalctl
-Ь
О
-u ssh
Для того чтобы показать все сообщения, начиная с прошлой полночи до сегодняш
него дня, выполните команду:
# journalctl --since=yesterday --until=now
Для того чтобы показать последние
100 записей
журнала из определенного двоично
го файла, выполните команду:
# journalctl -n 100 /usr/sbin/sshd
Для
получения краткой
справки об этих аргументах используйте
команду
journalctl --help.
Совместное использование с системой
Как система
Syslog,
Syslog
так и журнал
наших демонстрационных систем
systemd по умолчанию активны для каждой из
Linux. Оба пакета собирают и сохраняют сообщения
журнала. Зачем нужно, чтобы оба они работали, и как это сделать?
К сожалению, в журнале отсутствуют многие функции, доступные в системе
Как будет показано в разделе
10.3,
система
rsyslog
Syslog.
может получать сообщения от раз
личных входных дополнительных модулей и перенаправлять их на разнообразный набор
выходов в соответствии с фильтрами и правилами, которые невозможны, если исполь
зуется журнал
systemd. В среде systemd существует инструмент удаленного потока,
systemd-journal-remote, но он относительно новый и не сравнивался с системой
Syslog. Администраторам также может быть удобно хранить определенные файлы жур
налов в виде обычного текста, как это делает система Syslog, а не в двоичном формате
журнала.
Глава
1о.
Журналирование
329
Мы ожидаем, что со временем новые функции в журнале узурпируют обязанности
системы
Syslog.
Но на данный момент дистрибутивам
Linux
по-прежнему необходимо
запустить обе системы для достижения полной функциональности.
Механика взаимодействия между журналом
systemd и системой Syslog несколько
systemd-journald берет на себя ответственность
за сбор журнальных сообщений из /dev/log, сокета протоколирования, который исто
рически контролировался системой Syslog. 2 Для того чтобы система Syslog могла выпол
запутанна. Начнем с того, что демон
нить регистрацию, она должна получить доступ к потоку сообщений через системный
менеджер
systemd.
Система
Syslog
может извлекать сообщения из журнала двумя спо
собами.
•
Журнал
system.d может пересылать сообщения другому сокету (обычно /run/
system.d/journal/syslog), из которого демон системы Syslog может их читать.
В этом режиме демон system.d-journald имитирует исходных отправителей со
общений в соответствии со стандартным API системы Syslog. Следовательно, пе
ренаправляются только основные параметры сообщения; некоторые метаданные,
специфичные для системы, теряются.
В качестве альтернативы система
•
Syslog
может обрабатывать сообщения непо
средственно из интерфейса прикладного программирования журнала таким же
образом, как и команда
ничества со стороны
journalctl. Этот метод требует явной поддержки сотруд
syslogd, но это более полная форма интеграции, которая
сохраняет метаданные для каждого сообщения. 3
СистеМ1>1
и
CentOS
Deblan
и
Ubuntu
по умолчанию используют прежний метод, но
Red Hat
используют последний. Чтобы определить, какой тип интеграции был на
строен в вашей системе, проверьте опцию ForwaгdToSyslog в файле
journald.conf.
Если его значение равно
yes,
/etc/system.d/
используется переадресация сокетов.
10.3. СистЕмА SvsLoG
Syslog -
это полнофункциональная система регистрации событий, написанная
Эриком Оллманом
(Eric Allman),
вержденный
Она выполняет две важные функции: освобождает программистов
IETF. 4
и стандартный протокол регистрации событий, ут
от утомительной механической работы по ведению журнальных файлов и передает
управление журнальной регистрацией в руки администраторов. До появления системы
Syslog
каждая программа сама выбирала схему регистрации событий, а у системных ад
министраторов не было возможности контролировать, какая информация и где именно
сохраняется.
Система
Syslog отличается высокой гибкостью. Она позволяет сортировать сообще
(facility) и уровню важности (severity) и направлять их в различные
ния по источникам
пункты назначения: в журнальные файлы, на терминалы пользователей и даже на дру
гие компьютеры. Одной из самых ценных особенностей этой системы является ее спо
собность централизовать процедуру регистрации событий в сети.
2 Точнее,
ссылки журнала из
1 Краткое
/dev/log в /run/systemd/journal/dev-log.
описание доступных метаданных см. на справочной страниuе
systemd. journal-
fields.
•последняя по времени версия спецификации системы
Syslog - RFC5424,
RFCЗ\64, лучше отражает реальную инсталлированную систему.
но предыдущая версия,
Часть
330
В системах
Linux
1. Основы
администрирования
исходный демон системы
Syslog (syslogd) был заменен более но
Rsyslog (rsyslogd). Rsyslog - проект с открытым исход
расширяет возможности исходной системы Syslog, но поддержива
вой реализацией, называемой
ным кодом, который
ет обратную совместимость с интерфейсом прикладного программирования. Это самый
разумный выбор для администраторов, работающих в современных системах
и
Linux,
•
и это единственная версия
Система
Syslog,
FreeBSD, и мы рекомендуем вам принять ее,
FreeBSD, если у вас нет простых тре
бований. Инструкции по преобразованию системы FreeBSD для использования демона rsyslog содержатся по адресу wiki. rsyslog. сот/ index.
php/FreeBSD.
Rsyslog
доступна для
а не стандартный системный журнал
Если вы решите придерживаться традиционной системы
стеме
UN IX
которую мы рассмотрим в этой главе .
FreeBSD,
перейдите в раздел "Синтаксис
sysklogd"
syslog
в операционной си
для получения информации
о конфигурации.
Чтение сообщений системы
Syslog
Простые сообщения системы
Syslog можно читать с помощью инструментов си
UNIX и Linux для обработки текста, например команд grep, less, cat и awk.
Приведенный ниже фрагмент кода демонстрирует сообщения о типичных событиях
в журнале /var/log/eyelog, поступившие от хоста системы Deblan.
jessie# cat /var/log/sysloq
стем
Jul 16 19:43:01 jessie networking[244]: bound to 10.0.2.15 -- renewal in
42093 seconds.
Jul 16 19:43:01 jessie rpcbind[397]: Starting rpcbind daemon ....
Jul 16 19:43:01 jessie nfs-common[412]: Starting NFS common utilities:
statd idmapd.
Jul 16 19:43:01 jessie cron[436J: (CRON) INFO (pidfile fd = 3)
Jul 16 19:43:01 jessie cron[436]: (CRON) INFO (Running @reboot jobs)
Jul 16 19:43:01 jessie acpid: starting up with netlink and the input layer
Jul 16 19:43:01 jessie docker[486]: time="2016-0716T19:43:01.972678480Z" level=info msg="Daemon has completed
initialization"
Jul 16 19:43:01 jessie docker[486]: time="2016-0716Tl9:43:01.972896608Z" level=info msg="Docker daemon"
commit=c3959Ы execdriver=native-0.2 graphdriver=aufs
version=l.10.2
Jul 16 19:43:01 jessie docker[486]: time="2016-0716T19:43:01.979505644Z" level=info msg="API listen on /var/run/
docker.sock"
Этот пример содержит сообщения, поступившие от нескольких разных демонов
и подсистем: сети,
NFS, aron, Docker
и демона управления питанием
сообщение содержит следующие поля, разделенные пробелами.
•
•
•
•
Временная метка.
Системное имя хоста, в данном случае j
essie.
Имя процесса и его идентификатор в квадратных скобках.
Полезная нагрузка сообщения.
acpid.
Каждое
Глава
1о.
Журналирование
331
Некоторые демоны кодируют полезную нагрузку сообщения, добавляя в них мета
данные, которые сопровождают это сообщения. В приведенном выше примере процесс
docker
включает свою временную метку, уровень журнала и информацию о конфигура
ции демона. Эту дополнительную информацию генерирует и форматирует посылающий
процесс.
Архитектура системы
Rsyslog
Сообщения журнала можно представить как поток событий, а систему
Rsyslog -
как
механизм обработки потока событий. Журнальные сообщения, которые интерпретиру
ются как события, представляются в виде входов, обрабатываются фильтрами и пере
сылаются по ацресу назначения. В системе
Rsyslog
каждый из этих этапов является кон
фигурируемым и модульным. По умолчанию система
rsyslog. conf.
Процесс rsyslogd
Rsyslog
настроена в файле
/etc/
обычно запускается при загрузке и выполняется непрерывно.
Syslog, заносят записи журнала в специальный
/dev/log, сокет домена UNIX. В конфигурации систем без демона systemd де
rsyslogd напрямую считывает сообщения из этого сокета, консультируется с его
Программы, которые известны системе
файл
мон
конфигурационным файлом для руководства по их маршрутизации и отправляет каждое
сообщение в соответствующее место назначения. Также можно (и желательно) настраи
вать демон
rsyslogd для
прослушивания сообщений в сетевом сокете.
Если вы изменяете файл
/etc/rsyslog. conf или любой из его включенных фай
rsyslogd, чтобы ваши изменения вступили в силу.
TERM прекращает работу демона. Сигнал HUP заставляет демон rsyslogd закры
лов, то должны перезапустить демон
Сигнал
вать все открытые файлы журналов, что полезно для ротации (переименования и пере
запуска) журналов.
По сложившейся трациции демон
в файл
/var/run/syslogd.pid,
rsyslogd записывает свой
идентификатор процесса
поэтому послать сигнал из сценария в процесс
rsyslogd
не составляет труда. 5 Например, следующая команда посылает сигнал зависания.
$ sudo kill
-НUР
'/bin/cat /var/run/sysloqd.pid'
Попытка сжать или выполнить ротацию журнального файла, который был открыт
демоном
rsyslogd для
записи,
-
плохая идея, которая приводит к непредсказуемым
результатам, поэтому перед этим обязательно отправьте сигнал HUP. Информацию
о правильной ротации журнала с помощью утилиты
Версии
logrotate
см. в разделе
10.4.
Rsyslog
Системы
Red Hat и CentOS используют Rsyslog версии 7, а Deblan и Ubuntu обновле
8. Пользователи FreeBSD, устанавливающие систему из портов, могут вы
версию 7, либо 8. Как и следовало ожидать, в проекте Rsyslog рекомендуется
ны до версии
брать либо
использовать самую последнюю версию, но мы не следуем этим советам. Тем не менее,
если ваша операционная система является самой современной, это не повлияет на ваш
опыт ведения журнала.
Версия
Rsyslog 8 является
основным переработанным вариантом основного механиз
ма, и, хотя в его устройстве многое изменилось с точки зрения разработчиков модулей,
аспекты, обращенные к пользователю, остаются в основном неизменными. За некоторы
ми исключениями, конфигурации в следующих разделах действительны для обеих версий.
5В
современных версиях системы I.inux
/var/run является
символической ссылкой на
/run.
332
Часть
Конфигурация
администрирования
Rsyslog
Поведение демона
conf.
1. Основы
rsyslogd
контролируется настройками в файле
Все наши примеры дистрибутивов
Linux
/etc/rsyslog.
включают в себя простую конфигурацию
с разумными значениями по умолчанию, которые подходят большинству организаций.
Пустые строки и строки, начинающиеся с символа#, игнорируются. Строки в конфигу
рации системы
Rsyslog
обрабатываются в порядке от начала до конца, а порядок имеет
значение.
В верхней части файла конфигурации находятся глобальные свойства, которые на
страивают сам демон. В этих строках указаны загружаемые модули, формат сообще
ний по умолчанию, права собственности и разрешения файлов, рабочий каталог, в ко
тором можно сохранить состояние системы
и другие параметры. Следующая
Rsyslog,
примерная конфигурация адаптирована из стандартного файла
сии
rsyslog. conf
в вер
Deblan Jessie.
# Поддержка локальной
$ModLoad imuxsock
системы регистрации
# Поддержка регистрации
$ModLoad imklog
ядра
# Выводить сообщения в традиционном формате с временными
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
# Новым файлам регистрации
$File0wner root
$FileGroup adm
# Стандартные права доступа
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
назначается
для
вновь
# Каталог, в котором хранятся рабочие
$WorkDirectory /var/spool/rsyslog
владелец
созданных
файлы
метками
root:adm
файлов
и
каталогов
rsyslog
Большинство дистрибутивов используют устаревшую директиву
$IncludeConfig
/etc/
для включения дополнительных файлов из каталога конфигурации, обычно
rsyslog .d/*. conf.
Поскольку порядок важен, дистрибутивы организуют файлы с по
мощью предшествующих имен файлов с номерами. Например, конфигурация
Ubuntu
по умолчанию включает следующие файлы:
20-ufw.conf
21-cloudinit.conf
50-default.conf
Система
Rsyslogd
интерполирует эти файлы в файл
/etc/rsyslog. conf
в лексико
графическом порядке, чтобы сформировать окончательную конфигурацию.
Фильтры, иногда называемые селекторами, составляют основную часть конфигура
ции системы
Rsyslog.
Они определяют, как система
Rsyslog
сортирует и обрабатывает
сообщения. Фильтры формируются из выражений, выбираются конкретные критерии
сообщений и действия, которые направляют выбранные сообщения в нужное место на
значения.
Глава
10. Журналирование
Система
•
Rsyslog
333
понимает три синтаксиса конфигурации.
Строки, использующие формат исходного файла конфигурации систем
После появления демона регистрации ядра
"формат
sysklogd".
sysklogd
Syslog.
этот формат известен как
Он прост и эффективен, но имеет некоторые ограничения.
Используйте его для создания простых фильтров.
•
Устаревшие директивы системы
Rsyslog,
которые всегда начинаются с знака
синтаксис уходит корнями в старые версии систем
Rsyslog
$.
Их
и действительно дол
жен быть признан устаревшим. Однако не все опции бьmи преобразованы в новый
синтаксис, и поэтому этот синтаксис остается важным для некоторых функций.
•
Синтаксис
RainerScript,
названный в честь Райнера Герхардса
ведущего автора системы
Rsyslog.
(Reiner Gerhards),
Это синтаксис сценариев, который поддержи
вает выражения и функции. Вы можете использовать его для настройки большин
ства, но не всех аспектов системы
Rsyslog.
Многие конфигурации в реальном мире включают в себя сочетание всех трех фор
RainerScript существует с 2008 r.,
матов, иногда с запутанным эффектом. Хотя синтаксис
он все еще используется немного реже других. К счастью, ни один из диалектов не яв
ляется особенно сложным. Кроме того, на многих сайтах не придется делать крупную
операцию по простым конфигурациям, включенным в их распределение ресурсов.
Для того чтобы перейти из традиционной конфигурации
ществующего файла
syslog. conf
Syslog,
просто начните с су
и добавьте параметры для функций системы
Rsys\og,
которые вы хотите активировать.
Модули
Модули системы
Rsyslog
расширяют возможности основного механизма обработки.
Все входы (источники) и выходы (адресаты) настраиваются через модули, а модули мо
гут даже анализировать и изменять сообщения. Хотя большинство модулей были напи
саны Райнером Герхардсом, некоторые из них были внесены третьими лицами. Если вы
программист на языке С, то можете написать свой собственный.
Имена модулей соответствуют предсказуемому префиксному шаблону. Те, которые
im, являются модулями ввода; om* - модули вывода, mm* - мо
начинаются с префикса
дули модификации сообщений и т.д. Большинство модулей имеют дополнительные па
раметры конфигурации, которые настраивают их поведение. Документация о модулях
системы
Rsyslog
является полным и исчерпывающим справочником.
В следующем списке кратко описаны некоторые из наиболее распространенных (или
интересных) модулей ввода и вывода, а также несколько экзотических примеров.
•
Модуль
imj ournal
интегрируется с журналом
"Совместное использование с системой
•
Модуль
imuxsock
systemd
•
•
systemd,
как описано в разделе
Syslog".
считывает сообщения из сокета домена
UNIX.
Если журнал
отсутствует, это значение устанавливается по умолчанию.
и
BSD.
Модуль
imklog
понимает, как читать сообщения ядра в системах
Модуль
imfile
преобразует простой текстовый файл в формат сообщения систе
мы
Syslog.
Linux
Это полезно для импорта файлов журналов, созданных с помощью про
граммного обеспечения, не имеющего встроенной поддержки
Syslog.
Существуют
два режима: режим опроса, который проверяет файл на наличие обновлений в на
страиваемый интервал и режим уведомления
терфейс событий файловой системы
Linux.
после отключения при перезапуске демона
(inotify),
который использует ин
Этот модуль допускает восстановление
rsyslogd.
Часть
334
•
Модули
imtcp
и
imudp
1. Основы
администрирования
принимают сетевые сообщения через ТСР и
UDP
соот
ветственно. Они позволяют централизовать ведение журнала в сети. В сочетании
с драйверами сетевого потока системы
Rsyslog
модуль ТСР также может прини
мать взаимно аутентифицированные сообщения системы
Syslog через TLS. Для
Linux с чрезвычайно высоким объемом см. также модуль imptcp.
модуль immark присутствует, система Rsyslog создает сообщения с отметкой
сайтов
•
Если
времени через равные промежутки времени. Эти метки времени могут помочь вам
понять, что ваща машина потерпела крах между
3:00
и
3:20 утра,
а не просто но
чью. Эта информация также является большой помощью, когда вы отлаживаете
проблемы, которые происходят регулярно. Для настройки интервала метки ис
пользуйте параметр MarkМessagePeriod.
•
Модуль
omfile
записывает сообщения в файл. Это наиболее часто используемый
модуль вывода и единственный, который настроен при установке по умолчанию.
•
Модуль
UDP.
omfwd
пересылает сообщения на удаленный сервер
Syslog
через ТСР или
Этот модуль особенно полезен, если ваша организация нуждается в центра
лизованном протоколировании.
•
Модуль
Katka.
omkafka -
это реализация производителя для потокового движка
Apache
Пользователи крупных сайтов могут извлечь выгоду из возможности обра
батывать сообщения, у которых есть много потенциальных потребителей.
omkafka модуль omelasticsearch записывается непосред
Elasticsearch. Дополнительную информацию о стеке управления
журналом ELK, который включает Elasticsearch в качестве одного из своих компо
нентов, см. в разделе I0.5.
• Модуль ommysql отправляет сообщения в базу данных MySQL. Распределение ис
точников Rsyslog содержит примерную схему. Для повышения надежности объеди
ните этот модуль с устаревшей директивой $MainMsgQueueSize.
•
Аналогично модулю
ственно в кластер
Модули можно загружать и настраивать либо с помощью устаревших форматов кон
фигурации, либо с помощью синтаксиса
RainerScript.
Ниже мы приводим некоторые
примеры в разделах, посвященных конкретным форматам.
Синтаксис демона sysklogd
Синтаксис демона
sysklogd -
это традиционный формат системы
знаете, как работает стандартный демон
ная в системе
FreeBSD,
syslogd,
Syslog.
Если вы
например его версия, инсталлирован
то, вероятно, вы знаете все, что требуется. (Но учтите, что файл
конфигурации традиционного демона
syslogd
называется
/ etc/ syslog. conf,
а не
/etc/rsyslog. conf.)
Изначально этот формат был предназначен для пересылки сообщений определенно
го типа в заданный файл или по заданному сетевому адресу. Базовый синтаксис записей
файла таков.
селектор
действие
Селектор отделен от действия одним или несколькими пробелами или знаком табу
ляции. Например, строка
auth.*
/var/log/auth.log
обеспечивает сохранение сообщений, связанных с аутентификацией пользователей, в файле
/var/log/auth.log.
Глава
10. Журналирование
335
Селектор указывает источник
важности
(severity)
(facility),
посьmающий журнальное сообщение, и уровень
эrого сообщения. Формат селектора выглядит следующим образом.
источник.уровень_важности
Названия источников и уровней важности следует выбирать из стандартного списка
значений; программы не могут самостоятельно составлять такие списки. Есть источни
ки, определенные для ядра, для основных групп утилит и для локальных программ. Все
остальное проходит под общим названием
Селекторы могут содержать символы
user
(т.е. пользователь).
* и none,
которые обозначают "все" и "ниче
го" соответственно. В селекторе разрешается через запятые перечислять группу источ
ников. Допускается также разделение самих селекторов с помощью точки с запятой.
В общем случае селекторы объединяются операцией
OR,
т.е. указанное действие бу
дет выполняться для сообщения, соответствующего любому селектору. Селектор уровня
none
означает исключение перечисленных в нем источников, независимо от того, что
указано в остальных селекторах этой же строки.
Приведем несколько примеров селекторов.
#
Применяем действие
facility.level
action
ко всем сообщениям от
facility.level
# Применяем действие ко всем
facilityl, facility2.level
# Применяем действие только к сообщениям
facilityl.levell; facility2.1eve12
# Применяем
*.level
#
действие
facilityl.level
action
сообщениям от
от
ко
всем источникам,
10.2
facili ty2. level2
badfacility
action
кроме
перечислены допустимые названия источников. Они определены в стан
дартной библиотеке в файле
10.2.
и
action
Применяем действие
Таблица
facili tyl. leve11·
action
facility2.level
только источникам с заданным уровнем важности
*.level;badfacility.none
В табл.
и
syslog. h.
Названия средств
Syslog
Источник
Проrраммы или сообщения, которые
*
auth
authpriv
cron
daemon
ftp
kern
local0-7
lpr
mail
mark
news
syslog
user
Все источники, кроме
ero испольэу~от
mark
Команды, связанные с безопасностью и авторизацией
Конфиденциальные авторизационные сообщения
Демон
cron
Системные демоны
Демон
ftpd (устаревший)
Ядро
Восемь разновидностей локальных сообщений
Система спулинга построчной печати
Система
sendmail, postfix и другие почтовые программы
Метки времени, генерируемые через одинаковые промежутки
Система телеконференций
Usenet (устаревшая)
Внутренние сообщения демона
syslogd
Пользовательские процессы (это установка по умолчанию, если не указано иное)
Часть
336
1. Основы
администрирования
Не воспринимайте слишком серьезно различие между сообщениями системы
типа
и
auth
authpri v.
Syslog
В действительности все авторизационные сообщения являются
конфиденциальными, и ни одно из них не должно быть открытым для всеобщего досту
sudo использует authpriv.
10.3 перечислены уровни важности,
па. Журнал
В табл.
существующие в системе
Syslog (в
поряд
ке убывания важности).
Таблица
10.3. Уровни
важности сообщений
Syslog
Уровень
Приблиэитепьное значение
emerg
alert
crit
err
warning
notice
info
debug
Экстренные сообщения; система вышла из строя
Срочные сообщения; требуются срочные действия
Критические состояния
Другие ошибочные состояния
Предупреждения
Необычные события, которые заслуживают внимания
Информационные сообщения
Отладочные сообщения
Уровень сообщения определяет его важность. Границы между различными уровня
ми несколько размыты. Существует четкое различие между событиями, заслуживаю
щими внимания, и предупреждениями (а также между предупреждениями и сообщени
ями об ошибках), но трудно однозначно разграничить значения уровней
alert
и
cri t.
Уровни обозначают минимальную важность, которую сообщение должно иметь
для того, чтобы быть зарегистрированным. Например, сообщение от
SSH
имеющее
уровень важности
warning, будет соответствовать селектору auth. warning, а также
селекторам auth. info, auth. notice, auth. debug, *. warning, *. notice, *. info и
*. debug. Если в конфигурации указано, что сообщения auth. info должны регистри
роваться в файле, то сообщения auth. warning тоже будут направляться в этот файл.
Этот формат также допускает символы= и
!
перед названиями уровней,
означаю
щие "только этот уровень" и "за исключением этого и более высоких уровней" соот
ветственно (табл.
Таблица
i nf о
info, notice и warning
любого уровня, кроме wa rning
Выбор почтовых сообщений уровней
Выбор почтовых сообщений
Поле действие определяет способ обработки сообщения. Возможные варианты пе
речислены в табл.
Таблица
10.5.
10.5. Типичные действия
Действие
Назначение
имя_файла
Дописать сообщение в указанный файл на локальном компьютере
@имя хоста
Переслать сообщение демону rsyslogd, выполняющемуся
на компьютере с указанным именем
Глава
1о.
Журналирование
337
Окончание табл.
10.5
действие
Назначение
@IР_адрес
Переслать сообщение на
@@IР_адрес
Переслать сообщение на IР_ адрес по протоколуТСР, порт 514
порт 514
Записать сообщение в указанный именованный канал•
lимя_FIFO
пользовательl,
r Р_адрес по протоколу UDP,
пользователь2 ,...
Вывести сообщение на экраны терминалов указанных пользовате
лей, если они зарегистрированы в системе
Вывести сообщение на экраны терминалов всех пользователей,
*
зарегистрированных в системе
Игнорировать сообщение
лпроrрамма ;шаблон
Форматировать сообщение в соответствии со спецификацией
шаблон и послать его проrрамме как первый аргумент icmp_echo_ignore_broadcasts"
19
в каталоге
/proc/sys/net или
ubuntu$ sysctl net.ipv4.icmp_echo_ignore_broadcasts=l
Имена переменных в команде
sysctl
представляют собой имена путей относи
тельно каталога /proc/вys. Традиционным разделителем являются точки, но команда
sysctl
также допускает использование обратной косой черты.
19 Если попытаться выполнить эту команду в форме sudo echo 1 > icmp echo iqnore
broadcasts, то будет сrенерирооано сообщение "в разрешении отказано" ("permission deпied"~
потому что ваша оболочка пытается открыть выходной файл до выполнения команды sudo. Вы же
хотите применить команду sudo как к команде echo, так и к перенаправлению. Следовательно,
вы должны создать корневую подоболочку (root subshell), в которой необходимо выполнять всю
команду целиком.
Глава
13. сети TCP/IP
443
Обычно вы зарегистрированы в той же сети, которую пытаетесь настроить, поэто
му будьте осторожны! Вы можете так запутать настройки, что придется перегружать си
стему с консоли, а это может оказаться неудобным, если система, например, находится
в Пойнт-Барроу, штат Аляска, и за окном январь. Прежде чем даже просто подумать
о настройке головного компьютера, проведите тестирование на своей настольной си
стеме.
Для того чтобы указанные изменения стали постоянными (или, говоря точнее, чтобы
они восстанавливались при каждой перезагрузке системы), добавьте соответствующие
переменные в каталог
/ etc/ sysctl . conf,
который считывается командой
sysctl
во
время загрузки. Например, строка
net.ipv4.ip_forward=O
в файле
/ etc/ sysctl . conf отключает пересылку 1Р-пакетов на заданный хост.
/proc документированы лучше, чем другие.
Рекомендуем обратиться к разделу 7 справочной системы протокола. Например, коман
да шаn 7 iсшр документирует четыре из шести возможных вариантов. (При этом не
Некоторые подкаталоги каталога
обходимо, чтобы справочные страницы о ядре системы
Linux
были инсталлированы за
ранее.)
Кроме того, полезные комментарии можно найти в файле
ip-sysctl. txt,
находя
щемся в дистрибутивах исходного кода ядра. Если исходный код ядра не инсталлирован,
то отправьте в поисковую систему запрос
ip-sysctl-txt.
Переменные ядра, связанные с безопасностью
В табл.
13.8
описано стандартное поведение систем
Linux
в отношении различных
сетевых методик обеспечения безопасности. Все они кратко рассмотрены выше. Мы
рекомендуем установить соответствующие параметры так, чтобы система не отвечала
на широковещательные IСМР-запросы, не подчинялась директивам переадресации и не
принимала пакеты, маршрутизируемые по адресу отправителя. Все эти параметры долж
ны быть установлены по умолчанию, за исключением
Таблица
accept_redirects.
13.8. Режимы безопасности в системе Unux, заданные по умолчанию
Функциональная
Реализация
Реализация
ВОЗМОltНОСТЬ
на простом хосте
нawnl03e
/proc/sys/net/ipv4)
Пересылка
Отключена
Включена
ip_ forward для всей системы
IР-nакетов
Управnя~ощиА фаАл (в квтаnоrе
conf/интepфeйc/forwarding для каждого интерфейса
Переадресующие
Принимаются
Игнорируются
Отключена
Отключена
•
conf/интepфeйc/accept_ redirects
IСМР-nакеты
Маршрутизация
conf/интepфeйc/accept_source_
route
по адресу отnрави-
теля"
Широковещательное
Игнорируется
Игнорируется
icmp echo_iqnore_broadcasts
тестирование
•В качестве параметра интерфейс может быть задано имя конкретного интерфейса или ключевое слово all.
444
Часть
11. Работа
в сетях
13.11. СЕТЬ FREEBSD
•
Будучи прямым потомком линии
BSD,
операционная система
FreeBSD оста
TCP/IP. В нем не хватает
стек Linux. С точки зрения
FreeBSD проста и ясная.
ется чем-то вроде эталонной реализации протокола
многих разработок, которые усложняют сетевой
системных администраторов, конфигурация сети
Команда ifconfiq: настройка сетевых интерфейсов
Команда
ifconfig
включает или отключает сетевой интерфейс, устанавливает его
IР-адрес и маску подсети и задает различные другие опции и параметры. Обычно она
выполняется во время загрузки с параметрами командной строки, взятыми из файлов
конфигурации, но ее также можно запускать вручную для внесения изменений. Будьте
осторожны, внося изменения с помощью команды
лись удаленно,
-
ifconfig,
если вы зарегистрирова
многие системные администраторы были заблокированы в таких си
туациях и вынуЖДены были приезжать лично, чтобы исправить ситуацию.
Команда
ifconfig
ifconfig чаще
интерфейс
всего имеет форму
[семейство]
адрес параметры
...
Например, команда
ifconfig emO 192.168.1.13/26 up
устанавливает адрес
1Pv4 и
сетевую маску, связанную с интерфейсом
emO,
и готовит ин
терфейс для использования.
Параметр интерфейс идентифицирует аппаратный интерфейс, к которому применя
ется команда. Интерфейс обратной связи называется
loO.
Имена реальных интерфейсов
различаются в зависимости от их аппаратных драйверов. Команда
ifconfig
-а выво
дит список сетевых интерфейсов системы и их текущие настройки.
Параметр семейство указывает команде
ifconfig,
какой сетевой протокол ("се
мейство адресов") вы хотите настроить. Вы можете настроить несколько протоколов
на одном интерфейсе и использовать их все одновременно, но настраивать их необходи
мо по отдельности. Основные параметры здесь
- inet для 1Pv4 и
inetб для
1Pv6; inet
предполагается, если вы опустите параметр.
Параметр адрес указывает IР-адрес интерфейса. Здесь также допустимо имя хоста,
но оно должно определено для IР-адреса во времязагрузки. Для основного интерфейса
машины это означает, что имя хоста должно быть указано в файле локальных хостов,
поскольку другие методы определения имен зависят от инициализации сети.
Ключевое слово
ifconfig
up
up
включает интерфейс;
down
отключает его. Когда команда
назначает интерфейсу IР-адрес, как в приведенном выше примере, параметр
является неявным и не должен упоминаться по имени.
Для сетей, имеющих подсети, можно указать сетевую маску в стиле
казано в примере выше, или включить отдельный аргумент
netmask.
CIDR,
как по
Маска может быть
указана в десятичной системе с точками или в виде 4-байтового шестнадцатеричного
числа, начинающегося с Ох.
Параметр
broadcast указывает
IР-широковещательный адрес интерфейса, выражен
ный в шестнадцатеричной или точечной четырехзначной нотации. Широковещательный
адрес по умолчанию
-
это номер, в котором машинная часть состоит из одних единиц.
В приведенном выше примере использования команды
строенный широковещательный адрес равен
192.168.1.61.
ifconfig
автоматически на
13. Сети TCP/IP
Глава
445
Конфигурация сетевого оборудования в системе
В системе
Linux.
FreeBSD
нет специальной команды, аналоrичной
Вместо этого команда
ifconfig
FreeBSD
ethertool
в системе
передает информацию о конфигурации вплоть
до драйвера сетевого интерфейса через разделы
media
и
mediaopt.
Допустимые значе
ния этих параметров зависят от аппаратного обеспечения. Чтобы найти их список, про
читайте справочную страницу для конкретного драйвера.
Например, интерфейс с именем emO использует драйвер "em". На справочной стра
нице
man 4 em показано,
что этот драйвер предназначен для определенных типов про
водного Еthеmеt-оборудования на базе
Intel.
Чтобы заставить этот интерфейс работать
в гигабитном режиме с использованием четырехпарной кабельной системы (типичная
конфигурация), команда должна иметь вид:
* ifconfig emO media lOOObaseT mediaopt full-duplex
Вы можете включить эти параметры среды передачи данных вместе с другими пара
метрами конфигурации для интерфейса.
Конфигурирование сети во время загрузки системы
Статическая система конфигурации системы
метры сети находятся в файле
/etc/rc.conf,
FreeBSD
FreeBSD
довольно простая. Все пара
а также в других системных настройках.
Вот типичная конфигурация:
hostname="freebeer"
ifconfig_emO="inet 192.168.0.48 netmask 255.255.255.0"
defaultrouter="l92.168.0.1"
Каждый сетевой интерфейс имеет собственную переменную
переменной просто передается команде
ки. Раздел
defaul trouter
ifconfig
ifconfig_*.
Значение
как ряд аргументов командной стро
определяет сетевой шлюз по умолчанию.
Чтобы получить сетевую конфигурацию системы с DНСР-сервера, используйте сле
дующий параметр:
ifconfig_emO="DHCP"
Эта форма является "черным ящиком" и не передается команде
ifconfig,
которая
не знает, как интерпретировать аргумент DHCP. Вместо этого она активирует сценарии за
пуска команды
dhclient emO.
Чтобы изменить рабочие параметры системы
мя ожидания и т.д.), установите их в файле
/ etc/ dhclien t. conf.
DHCP
(вре
Версия этого файла
по умолчанию пуста, за исключением комментариев, и обычно ее не нужно изменять.
Если вы измените конфигурацию сети, то можете выполнить команду service
netif restart, чтобы повторить начальную процедуру настройки. Если вы изменили
параметр defaultrouter, также выполните команду service routing restart.
Конфигурирование протокола
Параметры сети на уровне ядра
Linux
(см. раздел
13.10),
TCP/IP
FreeBSD
в системе
FreeBSD
контролируются аналогично настройкам
за исключением того, что в ней нет иерархии
рой можно использовать права пользователя
root.
/proc,
в кото
Вместо этого выполоните команду
sysctl -ad, чтобы просмотреть доступные параметры и их однострочные описания.
(5495 на FreeBSD 11), поэтому вам нужно отобрать с помощью утилиты grep
роятных кандидатов, таких как "redirect" или "лnet".
В табл. 13.9 приведен список параметров, связанных с безопасностью.
много
Их
ве
Часть
446
Таблица
13.9.
Параметры сетевой безопасности в системе
Ст.
Параметр
эн.
11.
Работа в сетях
FreeBSD
Что он делает, коrда установлено значение
1
net.inet.ip.forwarding
о
Действует как маршрутизатор для пакетов
net.inetб.ipб.forwarding
о
Действует как маршрутизатор для пакетов IPvб
net.inet.tcp.Ыackhole
о
Отключает сообщения о недостижимости пакетов для за
net.inet.udp.Ыackhole
о
Не отправляет RSТ-пакеты для закрытых портов ТСР
1Pv4
крытых портов
net.inet.icmp.drop_redirect
о
Игнорирует перенаправления
net.inetб.icmpб.rediraccept
1
Принимает (подчиняется) IСМР-перенаправлениям по про
токолу IРvб
net.inet.ip.accept_sourceroute
о
1Pv4 ICMP
Разрешает маршрутизацию пакетов
1Pv4 по адресу оmра
вителя
Параметры Ыackhole потенциально полезны для систем, которые вы хотите защитить
от сканеров портов, но они изменяют стандартное поведение протоколов
UDP и
1Pv4 и 1Pv6.
ТСР. Вы
Вы можете установить параметры в работающем ядре с помощью команды
sysctl.
также можете отключить прием переадресаций
ICMP для
протоколов
Например,
$ sudo sysctl net.inet.icmp.drop_redirect=l
Для установки параметров во время загрузки поместите их в файл
/ etc/ sysctl.
conf.
net.inet.icmp.drop_redirect~l
13.12. СЕТЕВЫЕ
ПРОБЛЕМЫ
Для отладки сети на уровне протокола
TCP/IP доступно
несколько хороших инструмен
тов. Большинство из них предоставляют информацию на низком уровне, поэтому для их
использования вы должны понимать основные идеи протокола
TCP/IP
и маршрутизации.
В этом разделе мы начнем с некоторой общей стратегии устранения неполадок.
Затем рассмотрим несколько важных инструментов, включая
tcpdump
и
Wireshark.
В этой rлаве не обсуждаются команды
ping, traceroute,
arp, ndp, ss или netstat,
хотя они также являются полезными инструментами отладки.
Прежде чем атаковать свою сеть, учтите следующие принципы.
•
Делайте по одному изменению за раз. Проверьте каждое изменение, чтобы убе
диться, что оно возымело эффект, на который вы рассчитывали. Откажитесь
от любых изменений, которые имеют нежелательный эффект.
•
Зафиксируйте в документе ситуацию, которая сложилась до вашего вмешатель
ства, и записывайте все вносимые вами изменения.
•
Начните с одного конца системы или сети и пройдитесь по критическим компо
нентам системы, пока не обнаружите проблему. Например, вы можете начать с про
смотра конфигурации сети на клиентской стороне, пройти весь путь вплоть до фи
зических подключений, исследовать сетевое оборудование и, наконец, проверить
физические подключения и конфигурацию программного обеспечения сервера.
•
Или используйте слои сети для устранения проблемы. Начните сверху вниз или
снизу вверх и пройдитесь по стеку протокола.
Глава 13. Сети TCP/IP
447
Этот последний момент заслуживает более подробного обсуждения. Как описано
в разделе
13.2, архитектура TCP/IP определяет несколько уровней абстракции, на кото
рых могут функционировать компоненты сети. Например, НТТР зависит от ТСР, ТСР
зависит от
IP, IP
зависит от протокола
Ethernet,
а протокол Etheгnet зависит от целост
ности сетевого кабеля. Вы можете значительно сократить время, затрачиваемое на от
ладку проблемы, если сначала выясните, какой слой работает плохо.
Проходя по стеку сверху вниз или снизу вверх, задавайте себе такие вопросы.
•
•
•
•
•
•
Есть ли у вас физическая связь и горят ли светодиоды соединения?
Правильно ли настроен ваш интерфейс?
Показывают ли ваши таблицы
ARP другие
хосты?
Существует ли межсетевой экран (брандмауэр) на вашем локальном компьютере'?
Существует ли межсетевой экран где-то между вами и пунктом назначения?
Если задействованы брандмауэры, передают ли они пакеты и ответы
ICMP эхо-за
просов?
•
•
Можете ли вы выполнить эхо-запрос по адресу локального хоста
(127.0.0.1)?
Можете ли вы выполнить эхо-запросы к другим локальным хостам по их IРадресам?
•
•
•
•
•
Правильно ли работает
DNS? 20
Можете ли вы посылать эхо-запросы другим локальным хостам по имени?
Можете ли вы посылать эхо-запросы хостам в другой сети?
Работают ли службы высокого уровня, такие как веб-серверы и SSН-серверы?
Вы действительно проверяли брандмауэры?
После того как вы определили, где проблема, и нашли решение, изучите эффект, ко
торый вызовут ваши последующие проверки и предполагаемые исправления по отноше
нию к другим службам и хостам.
Команда
Команда
pinq:
ping
проверьте, работает ли хост
и ее 1Рv6-аналог pingб крайне просты, но во многих ситуациях они
являются единственными командами, которые необходимы для сетевой отладки. Они
отправляют IСМР-пакет ЕСНО _ REQUEST на целевой хост и ждут, вернет ли хост ответ.
Команду
ping
можно использовать для проверки состояния отдельных хостов и тес
тирования сегментов сети.
В обработку эхо-запроса вовлечены все таблицы маршрути
зации, физические сети и шлюзы, поэтому сеть должна работать более или менее устой
чиво, чтобы команда
ping
завершилась успешно. Если команда
ping
не работает, вы
можете быть уверены, что ничего более сложного работать тоже не будет.
Однако это правило не применяется к сетям или хостам, которые блокируют эхо-за
просы
ICMP
с помощью брандмауэра. 21 Прежде чем сделать вывод о том, что целевой
20 Если
машина подвисает во время загрузки, загружается очень медленно или зависает от входящих
SSH, основной подозреваемой должна быть система DNS. В большинстве систем
используется механизм преобразования имен, который настраивается в файле / etc/nsswi tch.
соединений
conf.
Если в системе запущен
nscd,
некоторого подозрения. Если демон
демон кеширования службы имен, этот компонент заслуживает
nscd
выходит из строя или неправильно сконфигурирован, это
влияет на поиск имен. Используйте команду
getent,
чтобы проRерить правильность работы ваших
механизмов преобразования имен и серверов имен (например,
21 0братите
getent hosts qooqle. com).
внимание на то, что в последних версиях операционной системы Windows эхо-запросы
по умолчанию блокируются.
Часть
448
11. Работа
в сетях
хост игнорирует эхо-запрос, убедитесь, что брандмауэр не мешает вашей отладке. Чтобы
облегчить отладку, можно ненадолго отключить промежуточный межсетевой экран.
Если ваша сеть находится в плохом состоянии, возможно, что не работает система
DNS.
Упростите ситуацию, используя числовые IР-адреса при выполнении эхо-запро
сов, и примените параметр
-n
обратный поиск по IР-адресам
команды
-
ping для
предотвращения попыток выполнить
этот поиск также инициирует запросы
Помните о проблеме брандмауэра, если вы используете команду
DNS.
ping для
проверки
возможности подключения к Интернету. Одни известные серверы отвечают на пакеты
эхо-запросов, а другие нет. Мы обнаружили, что сервер
google. сот
всегда отвечает
на эхо-запросы.
Если не задать аргумент, устанавливающий количество пакетов, то большинство вер
сий команды
ping
будут выполняться в бесконечном цикле. После того как вы выпол
нили эхо-запрос, введите символ прерывания (обычно
),
чтобы выйти.
Вот пример:
linux$ pinq beast
PING beast (10.1.1.46): 56 bytes
64 bytes from beast (10.1.1.46):
64 bytes from beast (10.1.1.46):
64 bytes from beast (10.1.1.46):
--- beast ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2026ms
rtt min/avg/max/mdev = 46.490/61.202/88.731/19.481 ms
Вывод для сервера
beast
показывает IР-адрес хоста, порядковый номер
ICMP
каж
дого ответного пакета и время прохождения в оба конца. Вышеприведенный вывод го
ворит о том, что сервер
beast
Номер последовательности
работает и подключен к сети.
ICMP является
особенно ценной информацией. Разрывы
в последовательности свидетельствуют об отброшенных пакетах. Обычно они сопрово
ждаются сообщением для каждого недостающего пакета.
Несмотря на то что протокол
IP
не гарантирует доставку пакетов, работоспособная
сеть должна терять очень мало пакетов. Проблемы с потерянным пакетом важны для от
слеживания, поскольку они, как правило, маскируются протоколами более высоко
го уровня. Возможно, сеть функционирует правильно, но она работает медленнее, чем
должна, не только из-за повторных пакетов, но также из-за накладных расходов прото
кола, необходимых для их обнаружения и управления ими.
Чтобы отследить причину исчезновения пакетов, сначала запустите команду
traceroute
(см. следующий раздел), чтобы обнаружить маршрут, по которому пакеты
отправляются на целевой хост. Затем выполните поочередную проверку промежуточных
шлюзов, чтобы узнать, какое соединение удаляет пакеты. Чтобы выявить проблему, не
обходимо отправить достаточно большое количество пакетов. Ошибка, как правило,
кроется в соединении между последним шлюзом, которому вы можете послать эхо-за
просы без потери пакетов, и следующим за ним шлюзом.
Время, затраченное на передачу пакетов в оба конца, сообщаемое командой
ping,
может дать представление об общей скорости пути через сеть. Умеренные вариации
времени в оба конца обычно не указывают на проблемы. Иногда пакеты могут задер
живаться на десятки или сотни миллисекунд без видимой причины; так работает про
токол
IP.
Вы должны увидеть довольно согласованное время прохождения в оба кон
ца для большинства пакетов, с периодическими провалами. Многие из сегодняшних
маршрутизаторов реализуют ограниченные по скорости или низкоприоритетные ответы
Глава
449
13. Сети TCP/IP
на IСМР-пакеты, это означает, что маршрутизатор может отложить ответ на ваш эхо-за
прос, если он в текущий момент обрабатывает большой объем другого трафика.
Программа
ping может отправлять пакеты эхо-запросов любого размера, поэтому,
используя пакет, превышающий
дительно
ero
MTU
сети
(1500
байт для
Ethernet),
вы можете прину
фрагментировать. Эта практика помогает идентифицировать ошибки сре
ды передачи данных или другие проблемы низкого уровня, такие как проблемы с пере
груженной сетью или
VPN.
Размер требуемого пакета задается в байтах после флага
-s:
$ ping -s 1500 cuinfo.cornell.edu
Обратите внимание на то, что даже такая простая команда, как
ping, может вызвать
1998 г. так называемая атака "Ping of Death" вывела из
систем UNIX и Windows. Эта атака была выполнена просто
драматические последствия. В
строя большое количество
путем передачи слишком большого пакета эхо-запросов. Когда фрагментированный
пакет был повторно собран, он заполнил буфер памяти получателя и вывел машину из
строя. Хотя проблема
"Ping of Death"
уже давно исправлена, следует иметь в виду не
сколько других предостережений относительно команды
только с помощью команды
Во-первых,
ping.
ping трудно отличить отказ сети от от
каза сервера. В среде, где обычно выполняются эхо-запросы, неудачное выполнение
команды
ping
просто говорит вам о том, что что-то идет не так, как надо. Также стоит
отметить, что успешный эхо-запрос не дает подробной информации о состоянии целе
вой машины. Пакеты эхо-запросов обрабатываются в стеке протокола
IP
и не требуют,
чтобы серверный процесс выполнялся на зондируемом хосте. Ответ гарантирует только,
что машина включена и не испытала панику ядра. Для проверки доступности отдельных
служб, таких как НТТР и
Команда
Команда
Jacobson),
DNS,
вам понадобятся методы более высокого уровня.
traceroute: трассировка IР-пакетов
traceroute,
первоначально написанная Ваном Джейкобсоном
(Van
раскрывает последовательность шлюзов, через которые IР-пакет перемещается,
чтобы добраться до места назначения. Все современные операционные системы постав
ляются с некоторой версией команды
traceroute
имя
traceroute. 22
Синтаксис этой команды простой:
хоста
Большинство параметров этой команды не так важны при ежедневном использова
нии. Как обычно, параметр имя_ хо ста может быть указан как в виде DNS-имени или
IР-адреса. Вывод
-
это просто список хостов, начиная с первого шлюза и заканчивая
пунктом назначения. Например, применение команды
дящему от нашего хоста
jaguar до
хоста
nubark,
traceroute
к маршруту, прохо
производит следующий вывод.
$ traceroute nuЬark
traceroute to nubark (192.168.2.10), 30 hops max, 38 byte packets
1 lab-gw (172.16.8.254) 0.840 ms 0.693 ms 0.671 ms
2 dmz-gw (192.168.1.254) 4.642 ms 4.582 ms 4.674 ms
3 nubark (192.168.2.10) 7.959 ms 5.949 ms 5.908 ms
Анализируя этот вывод, мы можем сказать, что хост
от
nubark,
j agua r
находится в трех переходах
и мы можем видеть, какие шлюзы задействованы в соединении. Также показано
время прохождения в оба конца для каждого шлюза
-
в выводе измеряются и отобража
ются три отсчета для каждого перехода. Типичный маршрут между интернет-хостами часто
включает в себя более
22 Эrа
15
переходов, даже если оба сервера находятся в одном городе.
команда есть даже в системе
Windows,
но nод именем
tracert
(nоnробуйте догадаться, почему).
Часть
450
Команда
traceroute
11.
Работа в сетях
начинает работу с установки искусственно заниженного значе
ния в поле времени жизни
(TTL,
или "подсчет переходов") исходящего пакета. По мере
поступления пакетов на шлюз их значение ТТL уменьшается. Когда шлюз уменьшает
ТТL до О, он отбрасывает пакет и отправляет сообщение
ICMP "time exceeded"
("время
жизни") обратно на исходный хост.
m
Дополнительную информацию об обратном поиске DNS СМ в разделе
Первый из трех пакетов
TTL,
traceroute
16.5.
в приведенном выше примере имеет значение
равное единице. Первый шлюз, через который проходит такой пакет (в данном
случае
lab-gw),
определяет, что ТТL бьm превышен, и уведомляет хост
jaguar об от
ICMP. IР-адрес отправителя в заголовке пакета
команда traceroute выполняет поиск этого адреса
брошенном пакете, отправив сообщение
ошибок идентифицирует шлюз, а
в
DNS,
чтобы найти имя хоста, на котором находится шлюз.
Чтобы определить шлюз второго перехода, команда
traceroute
отправляет второй
пакет с ТТL-полем, равным двум. Первый шлюз маршрутизирует пакет и уменьшает его
TTL на единицу. На втором шлюзе пакет затем отбрасывается, и сообщения об ошибках
ICMP генерируются по-прежнему. Этот процесс продолжается до тех пор, пока значе
ние ТТL не будет равным количеству переходов на целевой хост, и пакеты не достигнут
получателя.
Большинство маршрутизаторов отправляют свои сообщения
расположенный ближе всего к получателю. Если вы выполните
ICMP через интерфейс,
traceroute в обратном
порядке с целевого хоста, то сможете увидеть разные IР-адреса, используемые для иден
тификации одного и того же набора маршрутизаторов. Вы также можете обнаружить,
что пакеты, проходящие в обратном направлении, имеют совершенно другой путь
-
конфигурацию, известную как асимметричная маршрутизация.
Поскольку команда
поля
TTL,
traceroute
отправляет по три пакета для каждого значения
иногда вы можете наблюдать интересный эффект. Если промежуточный
шлюз мультиплексирует трафик по нескольким маршрутам, пакеты могут быть возвра
щены разными хостами; в этом случае команда
traceroute
просто выводит их все.
Рассмотрим более интересный маршрут от хоста из Швейцарии до сервера
org
компьютерного центра
caida.
San Diego Supercomputer Center.23
traceroute caicla.org
traceroute to caida.org (192.172.226.78), 30 hops max, 46 byte packets
1
gw-oetiker.init7.net (213.144.138.193) 1.122 ms 0.182 ms 0.170 ms
2
rlzurl.core.init7.net (77.109.128.209) 0.527 ms 0.204 ms 0.202 ms
3
rlfral.core.init7.net (77.109.128.250) 18.27 ms 6.99 ms 16.59 ms
4
rlamsl.core.init7.net (77.109.128.154) 19.54 ms 21.85 ms 13.51 ms
5
rllonl.core.init7.net (77.109.128.150) 19.16 ms 21.15 ms 24.86 ms
6
rllaxl.ce.init7.net (82.197.168.69) 158.23 ms 158.22 ms 158.27 ms
7
cenic.laap.net (198.32.146.32) 158.34 ms 158.30 ms 158.24 ms
8
dc-lax-core2-ge.cenic.net (137.164.46.119) 158.60 ms * 158.71 ms
9
dc-tus-aggl-core2-10ge.cenic.net (137.164.46.7) 159 ms 159 ms 159 ms
10 dc-sdsc2-tus-dc-ge.cenic.net (137.164.24.174) 161 ms 161 ms 161 ms
11 pinot.sdsc.edu (198.17.46.56) 161.559 ms 161.381 ms 161.439 ms
12 rommie.caida.org (192.172.226.78) 161.442 ms 161.445 ms 161.532 ms
l~nux$
Этот вывод показывает, что пакеты в течение длительного времени перемещаются
внутри сети
21
Init Seven.
Иногда мы можем угадать местоположение шлюзов по их име-
Мы удалили несколько долей миллисекунд из более длинных строк, чтобы они уместились на
странице.
Глава
13. Сети TCP/IP
451
нам. Ядро
lnit Seven простирается от Цюриха (zur) до Франкфурта (fra), Амстердама
(lon) и, наконец, Лос-Анджелеса (lax). Здесь трафик переносится в сеть
cenic. net, которая доставляет пакеты хосту caida. org в сети компьютерного центра
San Diego Supercomputer Center (sdsc) в Ла-Холле, Калифорния.
На переходе 8 мы видим звездочку вместо одного из показателей. Это означает, что
(ам), Лондона
не был получен ответ на зондирующий пакет (т.е. пакет с ошибкой). В данном случае
вероятной причиной является затор, но это не единственная возможность. Команда
traceroute
использует низкоприоритетные IСМР-пакеты, которые многие маршрути
заторы распознают и отбрасывают в пользу реального трафика. Несколько звездочек не
должны приводить вас в состояние паники.
Если вы видите звездочки во всех полях времени для данного шлюза, значит, из этой
машины не возвращаются сообщения об истечении времени. Возможно, шлюз просто
не работает. Иногда шлюз или брандмауэр настроены на безмолвное удаление пакетов
с просроченными ТГL. В этом случае вы все равно можете видеть, что находится за "не
мым" шлюзом хоста. Вполне возможно, что ошибочные пакеты шлюза возвращаются
слишком медленно, поэтому команда
traceroute
перестает их ждать.
Некоторые брандмауэры полностью блокируют сообщения
ICMP об
истечении вре
мени. Если такой брандмауэр расположен вдоль пути, вы не получите информацию
о каком-либо из шлюзов, расположенных за ним. Тем не менее вы все равно можете
определить общее количество переходов в пункт назначения, потому что зондирующие
пакеты в конечном итоге проходят всегда.
Кроме того, некоторые брандмауэры могут блокировать исходящие UDР
датаrраммы, отправленные командой
traceroute, чтобы инициировать ответы ICMP.
traceroute не сообщает какую-либо по
Эта проблема приводит к тому, что команда
лезную информацию вообще. Если вы обнаружите, что ваш собственный брандмауэр
препятствует выполнению команды
трафик через UDР-порты
traceroute, убедитесь, что брандмауэр пропускает
33434-33534, а также пакеты ICMP ЕСНО (тип 8).
Медленное соединение не обязательно указывает на неисправность. Некоторые фи
зические сети имеют естественную высокую задержку. Хорошим примером являются
беспроводные сети
UMTS/EDGE/GPRS.
Медлительность также может быть призна
ком высокой нагрузки на принимающую сеть. Нелогично высокое время передачи в оба
конца может подтвердить такую гипотезу.
Вместо звездочки или отметки времени вы можете иногда видеть обозначение
! N. Это обозначение указывает, что текущий шлюз отправил сообщение об ошиб
ке
"network
unreachaЫe" ("недоступность сети"), что означает, что он не знает,
как перенаправить ваш пакет. Существуют и другие варианты:
unreachaЫe" ("хост недоступен") и
!н
для ошибки
"host
! Р -"protocol unreachaЫe" ("протокол недо
ступен"). Шлюз, который возвращает любое из этих сообщений об ошибках, обычно
является последним переходом, до которого вы можете добраться. У этого хоста часто
возникает проблема маршрутизации (возможно, вызванная вышедшим из строя сетевым
соединением): либо его статические маршруты являются неправильными, либо динами
ческие протоколы не могут определить маршрут до места назначения.
Если вам кажется, что команда
traceroute
не работает или работает медленно, это
может объясняться временем ожидания при попытке определить имена хостов с по
мощью системы
traceroute,
DNS.
Если DNS-cepвep на хосте, с которого вы выполняете команду
не работает, используйте команду
traceroute -n для
запроса числово
го вывода. Этот параметр отключает поиск имен хостов; это может быть единственный
способ заставить команду
traceroute функционировать
в поврежденной сети.
часть
452
Для исполь:ювания команды
traceroute
11.
Работа в сетях
необходимы привилегии поль:ювателя
root.
Чтобы эта команда стала доступной для обычных поль:ювателей, необходимо установить
для нее флаг
setuid для root. В некоторых дистрибуrивах Linux для команды traceroute
setuid сброшен. В зависимости от вашей среды и поrребностей вы можете либо уста
новить бит setuid, либо дать заинтересованным поль:ювателям доступ к команде через
уrилиту sudo.
В последние годы появилось несколько новых уrилит, похожих на traceroute, ко
торые мoryr обходить блокировки межсетевых экранов ICMP (см. Wiki PERTKB для об
зора этих инструментов на сайте goo. gl/fXpMeu). Нам особенно нравится уrилита mtr,
которая имеет интерфейс, похожий на интерфейс команды top, и демонстрирует своего
рода усовершенствованную команду traceroute. Отлично!
флаг
Решая проблемы маршрутизации, посмотрите на свою сеть с точки зрения внеш
него мира. Несколько веб-служб трассировки маршруrов позволяют увидеть результат
выполнения команды
Кернен
traceroute в обратном порядке прямо в окне браузера.
(Thomas Kernen) ведет список этих служб на сайте traceroute.org.
Томас
Пакетные анализаторы трафика
Утилита
tcpdump
и программа
Wireshark относятся к классу инструментов,
(sniffers). Они прослушивают сетевой
ных как пакетные анализаторы трафика
извест
трафик
и записывают или распечатывают пакеты, соответствующие критериям по вашему выбо
ру. Например, вы можете проверить все пакеты, отпраменные на конкретный хост или
с него, или пакеты ТСР, связанные с одним конкретным сетевым соединением.
Пакетные анализаторы трафика полезны как для решения проблем, о которых вы
знаете, так и для обнаружения совершенно новых проблем. Иногда полезно обследовать
сеть, чтобы убедиться, что трафик в порядке.
Пакетные анализаторы трафика должны иметь возможность перехватывать трафик,
который локальная машина обычно не получает (или, по крайней мере, не обращает
на него внимание), поэтому базовое сетевое оборудование должно разрешать доступ
к каждому пакету. Широковещательные технологии, такие как
Ethemet,
работают пре
красно, как и большинство других современных локальных сетевых технологий.
W
Дополнительную информацию о сетевых коммутаторах см. в разделе
14.1.
Пакетные анализаторы должны видеть как можно больше необработанного сетевого
трафика, но им могут мешать сетевые коммуrаторы, которые в соответствии со своим пред
назначением пытаются ограничить распространение "ненужных" пакетов. Тем не менее
работа анализатора трафика в коммуrируемой сети может оказаться информативной. Вы
можете обнаружить проблемы, связанные с широковещательными или многоадресатными
пакетами. В зависимости от производителя коммуrатора вас может удивить большой объем
трафика. Даже если вы не видите сетевой трафик других систем, пакетный анализатор мо
жет быть полезен для отслеживания проблем, связанных с локальным хостом.
Помимо доступа ко всем сетевым пакетам, аппаратное обеспечение интерфейса
должно передавать эти пакеты на уровень программного обеспечения. Адреса паке
тов обычно проверяются на аппаратном уровне, и только пакеты широковещательной
и многоадресатной передачи, адресованные локальному хосту, передаются в ядро. В ре
жиме прослушивания
("promiscuous mode")
интерфейс позволяет ядру читать все пакеты
в сети, даже те, которые предназначены для других хостов.
Пакетные анализаторы трафика понимают многие форматы пакетов, используемые
стандартными сетевыми службами, и могут отображать эти пакеты в удобочитаемой
Глава
13. Сети TCP/IP
453
форме. Эта возможность облегчает отслеживание потока обмена информацией между
двумя программами. Некоторые сетевые анализаторы выводят текстовое содержимое
пакета в дополнение к заголовку пакета и поэтому полезны для исследования протоко
лов высокого уровня.
Поскольку некоторые протоколы отправляют информацию (и даже пароли) по сети
в виде открытого текста, старайтесь не вторгаться в конфиденциальность ваших пользо
вателей. С другой стороны, ничто так ярко не свидетельствует о необходимости крипто
графической защиты, как обнаружение пароля в виде открытого текста, в захваченном
в сетевом пакете.
Анализаторы трафика считывают данные прямо с сетевого устройства, поэтому они
должны запускаться с правами
root.
Хотя это ограничение должно уменьшить вероятность
того, что обычные пользователи будут прослушивать ваш сетевой трафик, на самом деле это
не слишком большое препятствие. В некоторых организациях предпочитают удалять про
граммы анализаторов трафика с большинства хостов, чтобы уменьшить вероятность злоупо
треблений. Кроме того, вы должны проверить интерфейсы своих систем, чтобы убедиться,
что они не работают в режиме прослушивания без вашего ведома или согласия.
Утилита tcpdump: пакетный анализатор
трафика из командной строки
Утилита
tcpdump -
еще один удивительный сетевой инструмент, разработанный
Ваном Джейкобсоном и работающий в большинстве систем. Утилита tcpdшnp уже дав
но является стандартным анализатором трафика, а большинство других инструментов
анализа сети считывают и записывают файлы трассировки в формате tcpdшnp, также
известном как формат
libpcap.
По умолчанию утилита tcpdшnp настраивается на первый сетевой интерфейс, с ко
торым она сталкивается. Если она выбирает неправильный интерфейс, вы можете заста
вить ее настроиться на правильный интерфейс с помощью флага
не работает или вы просто не хотите, что.бы утилита
ни, используйте параметр
служба
DNS
tcpdump
-i. Если система DNS
выполняла поиск по име
-n. Этот параметр важен, потому что медленно работающая
может заставить фильтр отбрасывать пакеты до того, как их можно будет
обработать с помощью утилиты
tcpdump.
Флаг
-v увеличивает информацию о пакетах, а -vv дает вам еще больше данных.
Наконец, утилита tcpdump может записывать пакеты в файлы с помощью флага -w
и считывать их обратно с помощью флага
Обратите внимание на то, что команда
-r.
tcpdump -w сохраняет
по умолчанию только
заголовки пакетов. Это значение по умолчанию создает небольшие дампы, но самая по
лезная и релевантная информация в них может отсутствовать. Таким образом, если вы
не уверены, что вам нужны только заголовки, используйте параметр
порядка
1560
(фактические значения зависят от параметра
MTU)
-s
со значением
для захвата целых па
кетов для последующего их анализа.
В качестве примера рассмотрим следующий усеченный вывод, поступающий от ма
шины с именем
nubark.
Спецификации фильтра
host bull
ограничивают отображе
ние пакетов теми, которые непосредственно связаны с машиной
454
Первый пакет показывает, что машина
адреса, соответствующему имени
atrust.
bull
отправила DNS-зaпpoc на поиск IР
сот, машине
машины, связанной с этим именем, который равен
на метку времени слева и распознавание утилитой
DNS). Номер порта
(41537), но поскольку
жений (в данном случае
водится в виде числа
вестен, утилита
nubark.
Ответ
66.77.122.161.
-
это IР-адрес
Обратите внимание
tcpdump протокола уровня прило
bull произволен и поэтому вы
на машине
номер порта DNS-cepвepa
выводит его символическое имя с суффиксом
tcpdump
Работа в сетях
(53)
хорошо из
domain.
Пакетные анализаторы трафика могут обеспечить огромное количество информа
ции, которая может перегрузить не только вас, но и операционную систему. Чтобы из
бежать этой проблемы в загруженных сетях, утилита
tcpdump
позволяет создавать слож
ные фильтры. Например, следующий фильтр собирает только входящий веб-трафик из
одной подсети:
$ sudo tcpdump src net 192.168.1.0/24 and dst port 80
Страница
man tcpdump содержит
несколько хороших примеров расширенной филь
трации, а также полный список примитивов.
Wireshark
и
Утилита
TShark: улучшенные варианты tcpdump
tcpdump
существует уже давно, но в последнее время быстро завоевывает
популярность новая программа с открытым исходным кодом под названием
(ранее известная как
Ethereal).
Программа
Wireshark
Wireshark
находится в активной разработке
и обладает большей функциональностью, чем многие коммерческие продукты для ана
лиза трафика. Это невероятно мощный инструмент анализа, который должен быть
включен в набор инструментов сетевого эксперта. Кроме того, это бесценное учебное
пособие.
Программа
wirehark
включает в себя графический пользовательский интерфейс
Wireshark
и интерфейс командной строки
tshark.
Она доступна в качестве базово
го пакета для большинства операционных систем. Если она не находится в основном
хранилище вашей системы, проверьте сайт
wirehark. org,
где размещен исходный код
и множество предварительно скомпилированных двоичных файлов.
Программа
Wireshark
может читать и записывать файлы трассировки в форматах, ис
пользуемых многими другими анализаторами пакетов. Еще одна удобная функция за
ключается в том, что вы можете щелкнуть по любому пакету в ТСР-цепочке и попро
сить программу
Wireshark
собрать (объединить вместе) данные полезной нагрузки всех
пакетов в потоке. Эта функция полезна, если вы хотите изучить данные, переданные во
время полного сеанса обмена по протоколу ТСР, например через соединение, по кото
рому передается электронное сообщение по сети.
Фильтры захвата
поскольку
Wireshark
Wireshark
функционально идентичны фильтрам утилиты
использует ту же базовую библиотеку
libpcap.
внимание на одну важную проблему, связанную с программой
tcpdump,
Однако обратите
Wireshark -
добавленную
функцию "фильтров отображения", которые влияют на то, что вы видите, а не на то, что
действительно захватывает анализатор пакетов. Синтаксис фильтра отображения более
мощный, чем синтаксис
libpcap,
поддерживаемый во время захвата. Фильтры отобра
жения выглядят несколько похожими, но они не совпадают.
Программа
Wireshark
имеет встроенные модули разбора
(dissectors)
для широкого
спектра сетевых протоколов, включая многие используемые для реализации сетевых
хранилищ
SAN.
Она преобразует пакеты в структурированное дерево информации, в ко
тором каждый бит пакета описывается обычным английским языком.
Глава
455
13. Сети TCP/IP
Ш Дополнительную информацию о хранилищах SAN см. в разделе
Следует сделать одно замечание относительно программы
21.1.
Wireshark:
хотя у нее много
удобных функций, на протяжении многих лет ей также требовалось много обновлений
для системы безопасности. Запустите текущую копию и не оставляйте ее на неопреде
ленный срок на машинах, содержащих конфиденциальную информацию; они могут
стать потенциальным маршрутом для атаки.
Ш Дополнительную информацию о программе Wireshark можно почерпнуть из третьего
издания книги Криса Сандерса Анализ пакетов: практическое руководство по
использованию
Wireshark
и
tcpdump для решения реальных проблем
2019 г.).
в локальных сетях
(пер. с англ" изд. "Диалектика",
13.13.
В главе
МОНИТОРИНГ СЕТИ
28
описывается несколько универсальных платформ, которые могут помочь
структурировать постоянный контроль над вашими системами и сетями. Эти системы
принимают данные из различных источников, суммируют их таким образом, чтобы ос
вещать текущие тенденции и предупреждают администраторов о проблемах, требующих
немедленного внимания.
Сеть является ключевым компонентом любой вычислительной среды, поэтому ча
сто это одна из первых частей инфраструктуры, которая подвергается систематическому
мониторингу. Если вы не чувствуете себя готовым присоединиться к единой платформе
мониторинга для всех ваших административных потребностей, используйте пакеты, опи
санные в этом разделе, для мелкомасштабного мониторинга, ориентированного на сеть.
Программа SmokePing: постепенный
сбор статистики об эхо-запросах
Даже вполне благополучные сети иногда теряют пакеты. С другой стороны, сети не
должны терять пакеты регулярно, даже с низкой скоростью, потому что воздействие
на пользователей может быть непропорционально серьезным. Поскольку протоколы
высокого уровня часто продолжают работать даже при наличии потери пакетов, вы ни
когда не заметите удаленные пакеты, если не будете активно контролировать их.
SmokePing, инструмент с открытым исходным кодом от Тобиаса Ойтикера (ToЬias
Oetiker), поможет вам разработать более полную картину поведения ваших сетей.
SmokePing отправляет несколько пакетов эхо-запросов на целевой хост через равные
промежутки времени. Он показывает историю каждой контролируемой связи через веб
интерфейс и может отправлять сигналы тревоги, когда что-то идет не так. Вы можете
oss. oetiker. ch/smokeping.
SmokePing. Вертикальная ось представляет собой вре
а горизонтальная ось - время (недели). Черная линия,
получить копию этой программы по адресу
На рис.
13.4
показан график
мя прохождения эхо-запросов,
из которой торчат серые всплески, указывает среднюю продолжительность прохожде
ния эхо-запросов в оба конца. Сами пики
-
это время прохождения отдельных пакетов.
Поскольку серые линии в этом графе расположены только над срединной линией, пода
вляющее большинство пакетов должно перемещаться со скоростью, близкой к средней,
причем лишь несколько из них задерживаются. Это типичная ситуация.
Ступенчатый характер срединной линии указывает на то, что среднее время про
хождения пакетов до этого пункта назначения в течение периода мониторинга менялось
несколько раз. Наиболее вероятные гипотезы, объясняющие это наблюдение, заключа-
456
Часть
11.
Работа в сетях
ются в том, что доступ к хосту осуществляется по нескольким путям или что он факти
чески представляет собой набор из нескольких хостов, имеющих одно и то же имя
DNS,
1Р-адресов.
но несколько
70 m
60
11'1
50.
"' 46 11
~
о
~ зе • '
10.
1
10.
о
Week 13
Week 15
iweek 14
11"k 16
Week 17
\loek 18
Week 19
11edian rtt: 37.8 •s avg 52.l •s •aix 25.7 11s •1n 40.б •s now 5 . З •s sd
packet \oss: о. 66 \ avo 7. 93 \ •ах о ' 00 \ •1n е. ео \ now
\oss со\ог: 8 е 8 1/10 8 1/28 8 3/26 8 4/20 8 16/26 8 19/20
probe:
20
IСМР
Echo Pings {56 Bytes) every
Рис.
13.4.
ЗIЭ0s
Пример графика
end : Tue
Мау
7
О
16 02:33 2017
а•/$
МЕSТ
SmokePing
Программа iPerf: отслеживание производительности сети
Инструменты на основе эхо-запросов полезны для проверки доступности, но недоста
точно эффективны для анализа и отслеживания производительности сети . Для решения
этой задачи предназначена программа
iPerf.
В последней версии iPerfЗ имеется широкий
набор функuий, которые администраторы могут использовать для точной настройки сете
вых параметров, чтобы достичь максимальной производител ьности .
Рассмотрим мониторинг пропускной способности с помощью программы
Фактически программа iPerfвcero лишь открывает соединение (ТСР или
iPerf.
UDP) между двумя
серверами, передает данные между ними и записывает, скол ько времени занял этот процесс .
После установки программы
iperf
на обеих машинах запустите сервер .
$ iperf -s
Se r ve r l istening on Т С Р po r t 5001
wi ndow siz e : 85 .3 KByt e (defa ul t)
ТС Р
Затем с машины, которую вы хотите протестировать, передайте некоторые данные ,
как показано ниже.
$ iperf
-с
10 . 211.55 . 11
Cli ent connect ing t o 10.211 . 55.1 1, ТС Р port 5001
ТС Р window s iz e : 22 . 5 KB yt e (defaul t )
3] local 10. 211 . 55 .1 0 port 53862 connected with 10 . 211. 55. 11 port 500 1
I D] Interva l
Tra nsfe r
Bandwi dth
3 ] 0 .0-1 0 . 0 sec 4.1 3 GByte s 3 . 55 Gbi ts / sec
Программа
iPerf возвращает
большие объемы потоковых данных для отслеживания
полосы пропускания . Это особенно полезно для оценки влияния изменений параметров
ядра, которые управляют сетевым стеком, таких как изменения в максимальном блоке
передачи
(MTU);
более подробную информацию см. в разделе
13.2.
Глава
13.
457
Сети ТСР/IP
Cacti: сбор
Программа
доступная на сайте
Cacti,
Программа
и отображение данных
cacti. net,
тельных функций. Она использует отдельный пакет,
предлагает несколько привлека
RRDtool,
в качестве вспомогатель
ного средства, в котором хранятся данные мониторинга в виде баз данных статического
размера, не требующих технического обслуживания.
Кактусы хранят столько данных, сколько необходимо для создания графиков, кото
рые вы хотите построить. Например, программа
может сохранять одну выборку
Cacti
каждую минуту в течение дня, одну выборку каждый час в неделю и одну выборку каж
дую неделю в течение года. Эта схема консолидации позволяет поддерживать важный
исторический контекст без необходимостихранить неважные данные или тратить время
на администрирование базы данных.
Программа
28.9),
может записывать и отображать любую SNМР-переменную (см. раздел
Cacti
а также многие другие показатели производительности. Вы можете собирать любые
данные, которые захотите. В сочетании с агентом
NET-SNMP
программа
Cacti
генерирует
историческую перспективу практически для любого системного или сетевого ресурса.
На рис.
приведены примеры графиков, созданных программой
13.5
Cacti.
Эти гра
фики показывают среднее значение нагрузки на устройстве в течение нескольких недель
вместе с дневным трафиком на сетевом интерфейсе.
WWW - Load Average
"'
..."'""
е
"'
.с
~
"
1.0
"'"'
"'~"'
"
Е
week 34
"'
1 мinute Avнage current:
5 м1 nute Ave rage cu r·rent:
8 15 Minute Average current:
О
о.
О
о.
о.
........"..........
~
week 35
76
50
39
HOU- S2- SW6S09- 2 - Traffi c - 1/1
J_. i .. ; __ } ; . ---!- J7~~: J
;, : _~"~~y~~~~~,fl··\\л_ ~~ .. !
'
f ·у~~~
r _,
'
! .N~.; '
11ом ~~~,
i~ 6М
--$._"_.._
14: 00 16: 00
18: 00
м
t~aximu111:
12.63
и
м
махiюuО1:
9. 20
м
Пример графика
1
....
20: 00
J
~"-..
22: 00
In: 674.89
Total O!Jt: 541, 56
тotal
,...-..Р
св
св
Cacti
легко управляется с помощью веб-интерфейса, а также предостав
ляет другие преимущества встроенного инструмента
RRDtool,
такие как низкая стои
мость обслуживания и красивое графическое представление. Ссылки на текущие версии
программ
RRDtool
и
Cacti,
а также десятки других инструментов мониторинга можно
найти на домашней странице
RRDtool
на сайте
rrdtool. org.
Часть
458
11. Работа в сетях
13.14. БРАНДМАУЭРЫ и СИСТЕМА NAT
Мы не рекомендуем использовать системы
Linux, UNIX
или
Windows
в качестве
брандмауэров из-за отсутствия безопасности, присущей полноценным операционным
системам общего назначения.24 Однако все операционные системы имеют функции
брандмауэра и могут стать вполне работоспособной заменой для организаций, у которых
нет денег для покупки дорогого брандмауэра. Аналогично брандмауэр
Linux
или
UN IX
является прекрасным вариантом для домашнего пользователя, обладающего знаниями
в области безопасности и предпочитающего самостоятельно латать ее дыры.
Если вы используете компьютер общего назначения в качестве брандмауэра, убе
дитесь, что на нем установлены параметры безопасности и соответствующие заплатки.
Брандмауэр
-
отличное место для реализации всех рекомендаций, изложенных в главе
(Брандмауэры с фильтрацией пакетов обсуждаются в разделе
27.7.
27.
Если вы не знакомы
с базовой концепцией брандмауэра, вероятно, было бы разумно прочитать этот раздел,
прежде чем продолжить чтение.)
Компании
Microsoft
в значительной степени удалось убедить мир в том, что каж
дый компьютер нуждается в собственном встроенном брандмауэре. Однако это не так.
Фактически машинно-зависимые брандмауэры могут привести к некорректной работе
систем и появлению таинственных сетевых проблем, если они не управляются в соот
ветствии с общепринятыми стандартами.
Существуют две основные школы по вопросу о машинно-зависимых брандмауэрах.
Первая школа считает их из.лишними. Согласно этой точке зрения брандмауэры принад
лежат маршрутизаторам шлюза, rде они могут защитить всю сеть посредством примене
ния одного последовательного (и постоянно применяемого) набора правил.
Вторая школа считает, что машинно-зависимые брандмауэры являются важным
компонентом глубоко эшелонированной обороны. Хотя шлюзовые брандмауэры те
оретически достаточны для управления сетевым трафиком, они могут быть скомпро
метированы, обойдены по другому маршруту или неправильно сконфигурированы ад
министраторами. Поэтому разумно реализовать те же ограничения сетевого трафика
с помощью множества избыточных брандмауэрных систем.
Если вы решите реализовать машинно-зависимые брандмауэры, вам нужна система
для их развертывания последовательным и легко обновляемым способом. Системы управ
ления конфигурацией, описанные в главе
23,
являются прекрасными кандидатами на эту
задачу. Не полагайтесь на ручную конфигурацию; она слишком уязвима.
Утилита iptaЫes в системе
Версия
2.4
ядра
Linux
Linux: правила,
цепочки и таблицы
представила совершенно новый механизм обработ
ки пакетов под названием
Netfilter,
а также инструмент командной строки
iptaЫes дпя управления им. 25
Конфигурация утилиты iptaЫes может быть довольно затруднительной.
Системы
Deblan
и
Ubuntu
имеют простой интерфейс
ufw,
который упроща
ет общие операции и настройку конфигурации. Стоит проверить, насколько
далеки ваши потребности от типичных.
24 Тем
не менее многие бюджетные потребительские сетевые устройства, такие как маршрутизаторы
Liпksys, используют
и iptaЬle1 в своем ядре.
Linux
21 Еше
3
более новая система, nftaЬle1, была доступна в версии ядра 3. 1 с 2014 г. Эrо разработка
системы Netfilter, которая конфигурируется командой мt, а не командой iptaЫes. Мы не обсуждаем
ее в этой книге, но ее стоит внедрить о орrанизаuиях, использующих новые ядра.
глава
13. сети
ТСР/IP
459
Утилита iptaЫes применяет к сетевым пакетам упорядоченные цепочки правил.
Наборы цепочек образуют таблицы и используются для обработки определенных видов
трафика.
Например, таблица iptaЫes по умолчанию называется фильтром. Цепочки пра
вил в этой таблице используются для пакетной фильтрации сетевого трафика. Таблица
фильтров содержит три стандартные цепочки:
FORWARD, INPUT и OUTPUT. Каждый пакет,
обработанный ядром, проходит через одну из этих цепочек.
Правила в цепочке
FORWARD
применяются ко всем пакетам, которые поступают
на один сетевой интерфейс и должны быть перенаправлены на другой. Правила в це
почках
INPUT и OUTPUT применяются к трафику, адресованному локальному хосту или
исходящему из него соответственно.
Как правило, эти три стандартные цепочки,
-
все, что вам нужно для создания меж
сетевого экрана между двумя сетевыми интерфейсами. При необходимости вы може
те определить настраиваемую конфигурацию для поддержки более сложных сценариев
учета или маршрутизации.
В дополнение к таблице фильтров iptaЫes включает таблицы
блице
nat
и
mangle.
адресов (здесь
na t -
это имя таблицы iptaЬles, а
мы перевода адресов). Система
NAT обсуждается
NAT - это название общей схе
13.4, а пример таблицы nat
в разделе
в действии показан ниже. Позже в этом разделе мы используем цепочку
сети
na t
В та
содержатся цепочки правил, которые управляют преобразованием сетевых
nat
PREROUTING
для фильтрации пакетов, препятствующей анализу трафика.
Таблица
mangle
содержит цепочки, которые модифицируют или заменяют содержи
мое сетевых пакетов вне контекста
NAT
и фильтрации пакетов. Хотя таблица
mangle
удобна для специальной обработки пакетов, например для сброса значений времени
ожидания
IP,
она обычно не используется в большинстве производственных сред. Мы
обсуждаем только таблицы фильтров и
na t
в этом разделе, оставляя таблицу
mang le
вне
поля зрения.
Цели правил iptaЬles
Каждое правило, составляющее цепочку, имеет раздел
target,
который определяет,
что делать с соответствующими пакетами. Если пакет соответствует правилу, в большин
стве случаев он сразу обрабатывается; никакие дополнительные правила не проверя
ются. Хотя многие цели определены внутри программы
iptatiles,
существует возмож
ность задать другую цель цепочки.
Целями, доступными для правил в таблице фильтров, являются АССЕРТ, DROP, REJECT,
LOG, ULOG, REDIRECT, RETURN, MIRROR и QUEUE. Если правило приводит к цели АССЕРТ,
то соответствующим ему пакетам разрешается продолжать свой путь. Цели DROP и REJECT
отбрасывают свои пакеты; цель DROP не выдает никаких сообщений, а цель REJECT воз
вращает сообщение об ошибке ICMP. Цель LOG предоставляет простой способ отслежи
вания пакетов, если они соответствуют правилам, а ULOG расширяет протоколирование.
Цель REDIRECT отправляет пакеты на прокси-сервер вместо того, чтобы позволить
им идти своим путем. Например, вы можете использовать эту функцию, чтобы заста
вить весь веб-трафик вашего сайта проходить через кеш-сервер, например
RETURN
тору
Squid.
Цель
завершает определяемые пользователем цепочки и действует аналогично опера
return
в вызове подпрограммы. Цель
MIRROR меняет местами IР-адрес отправите
QUEUE передает пакеты
ля и адреса получателя перед отправкой пакета. Наконец, цель
локальным пользовательским программам через модуль ядра.
460
Часть
11. Работа
в сетях
Настройка брандмауэра iptaЬles
Прежде чем вы сможете использовать программу iptaЬles в качестве брандмауэра,
необходимо включить переадресацию
1Р
и убедиться, что в ядро загружены различные
модули iptaЬles. Дополнительные сведения о включении IР-переадресации см. в раз
деле
13.1 О.
Пакеты, в которых устанавливается программа iptaЬles, обычно включают
сценарии запуска для обеспечения ее подключения и загрузки.
Брандмауэр
Linux обычно реализуется как серия команд iptaЬles, содержащихся
rc. Команды iptaЬles обычно принимают одну из следующих форм:
в сценарии запуска
iptaЬles
-F
iptaЬles
-Р имя-цепочки цель
iptaЬles
-А имя-цепочки
имя-цепочки
Первая форма
(-F)
-i
интерфейс
-j
цель
сбрасывает все предыдущие правила из цепочки. Вторая форма
(-Р) устанавливает политику по умолчанию (т.е. цель) для цепочки. Мы рекомендуем
использовать
DROP для целевой цепочки по умолчанию. Третья форма (-А) добавляет
текущую спецификацию в цепочку. Если вы не укажете таблицу с аргументом
команды применяются к цепочкам в таблице фильтров. Параметр
-t,
ваши
-i применяет прави
ло к именованному интерфейсу, а -j идентифицирует цель. Программа iptaЬles при
нимает множество других параметров, часть из которых приведена в табл.
Таблица
13.10. Флаги
13. 10.
командной строки дпя фильтров iptaЬles
Параметр
Описание или воэмоJКНые значения
-р
протокол
Ограничение протокола:
-s
iр-отправителя Ограничение оmравителя по имени или адресу (подходит система обозначений
tcp, udp или icmp
CIDR)
-d iр-получателя
Ограничение получателя по имени или адресу
- -sport порт#
Ограничение порта оmравителя (обратите внимание на двойное тире)
--dport порт#
Ограничение порта назначения (обратите внимание на двойное тире)
--icпp-type тип
Ограничение типа IСМР-пакета (обратите внимание на двойное тире)
-t
Указание таблицы, к которой применяется команда (по умолчанию
Отмена параметра
таблица
-
фильтр)
Полный пример
Ниже мы разберем полный пример. Мы предполагаем, что интерфейс
ethl имеет вы
ethO имеет выход во внутреннюю сеть. IР-адрес ethl ethO - 10.1.1.1, причем оба интерфейса имеют сетевую маску
ход в Интернет и что интерфейс
128.138.101.4, IР-адрес
255.255.255.0. В этом примере используется фильтрация пакетов без сохранения состояния
для защиты веб-сервера с IР-адресом 10.1.1.2, что является стандартным методом защи
ты интернет-серверов. Позже в этом примере мы покажем, как использовать фильтрацию
с сохранением состояния для защиты пользователей настольных компьютеров.
Наш первый набор правил инициализирует таблицу фильтров. Во-первых, все це
почки в таблице пусты, а для цели цепочек
значение
DROP.
INPUT
и
FORWARD
по умолчанию установлено
Как и в случае с любым другим сетевым брандмауэром, наиболее без
опасной стратегией является удаление любых пакетов, которые вы явно не разрешали.
iptaЫes
-F
iptaЫes
-Р
iptaЫes
-Р
INPUT DROP
FORWARD DROP
Глава
Сети
13.
461
TCP/IP
Поскольку правила оцениваются по порядку, мы ставим наши самые загружаемые пра
вила впереди. 26 Первое правило разрешает все подключения через брандмауэр, которые
происходят из доверенной сети. Следуюшие три правила в цепочке
подключение через брандмауэр к сетевым службам
подключения
iptaЫes
Единственным ТСР-трафиком, который мы разрешаем к нашему хосту брандмауэра
является
(10.l.l.l),
SSH,
что полезно для управления самим брандмауэром. Второе пра
вило, указанное ниже, позволяет осушествлять циклический трафик, который остается
локальным для хоста. Администраторы нервничают, когда не могут выполнить эхо-за
прос по маршруту, заданному по умолчанию, поэтому третье правило разрешает пакеты
Чтобы любой IР-хост в Интернете работал правильно, необходимо разрешить пере
дачу через брандмауэр IСМР-пакетов определенных типов. Следующие восемь правил
допускают передачу минимального набора IСМР-пакетов для хоста брандмауэра, а также для сети, расположенной за ним.
iptaЫes
10.0.0.0/8 -j DROP
172.16.0.0/12 -j DROP
192.168.0.0/16 -j DROP
127.0.0.0/8 -j DROP
224.0.0.0/4 -j DROP
INPUT,
так и
FORWARD
с правилом, запрещаю
щим пакеты, которые не были разрешены явным образом. Хотя мы уже применяли это
поведение с помощью команд iptaЬles -Р, цель
LOG
позволяет нам видеть, кто обра
щается к нам из Интернета.
26 0днако
вы должны быть осторожными, чтобы изменение порядка правил для повышения
производительности не влияло на функциональность.
Часть
462
iptaЫes
-А
iptaЬles
-А
11. Работа
в сетях
INPUT -i ethl -j LOG
FORWARD -i ethl -j LOG
По желанию мы могли бы настроить
IP NAT
для маскировки частного адресного
пространства, используемого во внутренней сети. Для получения дополнительной ин
формации об
NAT см.
раздел
13.4.
Одной из самых мощных функций, которой межсетевой экран
брандмауэр
Linux,
Netfilter обеспечивает
является фильтрация пакетов с учетом состояния. Вместо того чтобы
разрешать определенные входящие службы, брандмауэр для клиентов, подключающихся
к Интернету, должен разрешать входящие ответы на запросы клиентов.
Простая цепочка состояния FORWARD ниже позволяет всему трафику покидать нашу
сеть, но разрешает только входящий трафик, связанный с подключениями, иницииро
ванными нашими хостами.
iptaЫes
-А
iptaЬles
-А
FORWARD -i ethO -р ANY -j АССЕРТ
FORWARD -m state --state ESTABLISHED,RELATED -j
АССЕРТ
Чтобы позволить программе iptaЫes отслеживать сложные сетевые сеансы, такие
как FТР и
IRC,
необходимо загрузить некоторые модули ядра.
Если эти модули не за
гружены, программа iptaЫes просто запрещает эти соединения. Несмотря на то что
фильтры с установленными состояниями могут повысить безопасность вашего сайта,
они также увеличивают сложность сети и могут снизить производительность. Перед реа
лизацией в брандмауэре убедитесь, что вам нужна функциональность с сохранением со
стояния.
Возможно, лучший способ отладки ваших наборов правил iptaЫes
вать команду iptaЬles
-L -v.
-
использо
Эти параметры позволяют получить информацию о том,
сколько раз каждое правило в ваших цепочках соответствовало пакету. Мы часто добав
ляем временные правила iptaЬles с целью
LOG,
когда нам нужна дополнительная ин
формация о пакетах, которые совпадают. Более сложные проблемы часто можно решать,
используя пакетный анализатор трафика, такой как
Linиx
tcpdump.
NAT и фильтрация пакетов
Система
Linux традиционно реализует только ограниченную форму преобразования
(NAT), которая более правильно называется Port Address Translation
сетевых адресов
(РАТ). Вместо использования диапазона IР-адресов в качестве истинной реализации
NAT
РАТ мультиплексирует все соединения на один адрес. Детали и различия не имеют
большого практического значения.
Программа iptaЬles реализует технологию NАТ. а также фильтрацию пакетов. В более
ранних версиях
Linux
эта функциональность была немного беспорядочной, но програм
ма iptaЬles проводит намного более четкое разделение между технологией
NAT и филь
трацией. Конечно, если вы используете NАТ, чтобы локальные хосты могли поль:юваться
Интернетом, вы должны также использовать полный набор фильтров брандмауэра.
Чтобы заставить технолгию
новив переменную ядра
NAT работать, включите переадресацию IP в ядре, уста
/proc/sys/net/ipv4/ip_forward равной единице. Кроме
того, вставьте соответствующие модули ядра:
$ sudo
modproЬe iptaЫe_nat
$ sudo modproЬe ip_conntrack
$ sudo modprobe ip_conntrack_ftp
Многие другие модули отслеживают соединения; см. подкаталог
в каталоге
/lib/modules
рые вам нужны.
net/netfil ter
для получения более полного списка и включения тех, кото
Глава
13. Сети TCP/IP
463
Команда iptaЫes для маршрутизации пакетов с использованием
-t nat
iptaЫes
-А POSTROUТING -о
NAT имеет форму
ethO -j SNAT --to 128.138.101.4
Этот пример относится к тому же хосту, что и пример фильтрации в предьщущем раз
деле, поэтому
ethl - это интерфейс, подключенный к Интернету. Интерфейс ethl не
отображается непосредственно в командной строке выше, но его IР-адрес является тем,
который появляется в качестве аргумента для
-to.
Интерфейс
ethO -
это тот интер
фейс, который подключен к внутренней сети.
Для интернет-хостов, кажется, что все пакеты от хостов во внутренней сети имеют
IР-адрес
Хает, который реализует
ethl.
NAT,
принимает входящие пакеты, просма
тривает их истинные адресаты, переписывает их с соответствующим внутренним IР
адресом сети и отправляет по маршруту.
IPFilter для
•
UNIХ-систем
IPFilter, пакет с открытым исходным кодом, разработанный Дарреном Ридом
(Darren Reed), предоставляет технологию NAT и услуги брандмауэра с под
держкой состояния в различных системах, включая Linux и FreeBSD. Вы можете использовать пакет IPFilter в качестве загружаемого модуля ядра (кото
рый рекомендуется разработчиками) или статически включить его в ядро.
Пакет
IPFilter
является зрелым и полнофункциональным. Он имеет активное со
общество пользователей и историю непрерывного развития. Он способен отслеживать
состояние даже для протоколов без учета состояния, таких как
Пакет
IPFilter считывает правила фильтрации
/ etc/ ipf / ipf. conf или / etc/ ipf. conf), вместо
U DP
и
ICMP.
из файла конфигурации (обычно
того, чтобы предлагать вам выпол
нять серию команд так же, как и iptaЫes.
Примером простого правила, которое может отображаться в файле
Ыосk
ipf. conf, является
in all
Это правило блокирует весь входящий трафик (т.е. сетевую активность, получаемую си
стемой) на всех сетевых интерфейсах. Это, конечно, безопасно, но не особенно полезно!
В табл.
в правиле
Таблица
13.11
ipf.
показаны некоторые из возможных условий, которые могут появиться
13.11. Типичные условия, используемые пакетом lpf
Условие
on
from
Применяет правило к указанному интерфейсу
протокол
proto
to
Описание или возможные значения
интерфейс
iр-отправителя
iр-получателя
port
flags
=
порт
#
флаг-спец
icmp-type
keep s ta te
число
Выбирает пакет в соответствии с протоколом:
Фильтры по отправителю: хост, сеть или
Фильтры по получателю: хост, сеть или
Фильтры по имени порта (из файла
tcp, udp
icmp
any
/etc/services) или номеру8
Фильтры в соответствии с битами флагов ТСР-эаголовка
Фильтры по типу и коду
или
any
ICMP
Сохраняет сведения о потоке сеанса; см. ниже
'Можно использовать любой оператор сравнения:=,,= и т.д.
Часть
464
Пакет
IPFilter оценивает
11.
Работа в сетях
правила в порядке, в котором они представлены в файле
конфигурации. При этом срабатывает самое последнее совпадающее правило. Например,
входящие пакеты, проходящие по следующему фильтру, всегда будут проходить:
in all
pass in all
Ыосk
Правило Ыосk относится ко всем пакетам, как и правило
pass,
но правило
pass -
это последнее совпадающее правило. Чтобы принудительно применить правило соот
ветствия и заставить пакет
IPFilter пропустить последующие
правила, используйте клю
чевое слово
quick:
Ыосk in quick all
pass in all
Промышленный брандмауэр обычно содержит множество правил, поэтому для под
держания его высокой производительности важно использовать ключевое слово
quick.
Без этого каждый пакет оценивается по каждому правилу, и эта расточительность явля
ется слишком дорогостоящей.
Возможно, наиболее распространенным использованием брандмауэра является кон
троль доступа к определенной сети или хосту и от него, часто по отношению к опре
деленному порту. Пакет
IPFilter
имеет мощный синтаксис для управления трафи
ком на этом уровне детализации. В следующих правилах входящий трафик разрешен
для сети
10.0.0.0/24 на портах ТСР 80 и 443 и
на UDР-порту
out quick all
pass in quick proto tcp from any to 10.0.0.0/24 port
pass in quick proto tcp from any to 10.0.0.0/24 port
pass in quick proto udp from any to 10.0.0.0/24 port
Ыосk in all
53.
Ыосk
Ключевые слова
80 keep state
443 keep state
53 keep state
заслуживают особого внимания. Программа
keep state
IPFilter
может отслеживать соединения, отмечая первый пакет новых сеансов. Например, когда
новый пакет поступает на порт
80 хоста 10.0.0.1 О,
программа
IPFilter делает запись в таб
лице состояний и пропускает пакет. Эти ключевые слова позволяют также веб-серверу
отправить ответ, даже если первое правило явно блокирует весь исходящий трафик.
Ключевые слова
keep state
также полезны для устройств, которые не предлагают
никаких услуг, но которые должны инициировать соединения. Следующий набор пра
вил разрешает все обмены информацией, инициированные хостом
192.168.10.10.
Он
блокирует все входящие пакеты, кроме тех, которые связаны с уже установленными со
единениями.
in quick all
pass out quick from 192.168.10.10/32 to any keep state
Ыосk
Ключевые слова
keep state
работают также для
UDP-
и IСМР-пакетов, но по
скольку эти протоколы не имеют состояния, их работа немного сложнее:
решает ответы на
UDP-
или IСМР-пакет в течение
60 с
IPFilter
раз
после того, как входящий пакет
просматривается фильтром. Например, если UDР-пакет поступил от хоста
10. О. О .10
32000 и адресован хосту 192. 168. 10. 1 О на порт 53, то ответ UDP от хоста
192 .168 .10 .10 будет разрешен в течение 60 с. Аналогично эхо-ответ ICMP (рing-ответ)
с порта
разрешен после ввода эхо-запроса в таблицу состояний.
m
Дополнительную информацию о технологии
NAT см. в разделе 13.4.
глава
13. сети TCP/IP
465
Для предоставления услуг
(вместо
pass
программа
NAT
IPFilter
использует ключевое слово
и Ыосk). В следующем правиле трафик из сети
ся на текущий маршрутизируемый адрес интерфейса
10. О.
О.
0/24
map
отображает
emO.
map emO 10.0.0.0/24 -> 0/32
Если адрес emO изменится, то фильтр должен быть перезагружен. Это может слу
читься, если emO получает IР-адрес динамически через
функции
IPFilter лучше
DHCP.
По этой причине NАТ
всего использовать на серверах со статическим IР-адресом в ин
терфейсе, обращенном к Интернету.
В табл.
с пакетом
Табnица
13.12 перечислены
IPFilter.
13.12.
Команды
инструменты командной строки, которые поставляются
IPFilter
Команда
Функция
ipf
Управляет правилами и списками фильтров
ipfstat
Получает статистику фильтрации пакетов
ipmon
Отслеживает зарегистрированную информацию о фильтрах
ipnat
Управляет правилами
Из команд, приведенных в табл.
NAT
13.12,
наиболее часто используется
ipf.
Эта коман
да принимает файл правил в качестве входных данных и добавляет правильно разобран
ные правила в список фильтров ядра. Если вы не используете аргумент
сбрасывает все существующие правила, команда
ipf
-Fa,
который
добавляет правила в конец филь
тра. Например, чтобы очистить существующий набор фильтров ядра и загрузить правила
из файла
ipf. conf,
используйте следующий синтаксис:
$ sudo ipf -Fa -f /etc/ipf/ipf.conf
Программа
IPFilter использует файлы
псевдоустройств из каталога
ния доступом, и по умолчанию только пользователь
root
/dev для
управле
может редактировать список
фильтров. Мы рекомендуем оставить разрешения по умолчанию на месте и использо
вать для поддержки фильтра программу
Используйте флаг
-v
команды
ipf
sudo.
при загрузке файла правил для выявления син
таксических ошибок и других проблем в конфигурации.
13.15.
ОБЛАЧНЫЕ СЕТИ
Одна из интересных особенностей облака заключается в том, что вы можете опре
делить сетевую среду, в которой действуют ваши виртуальные серверы. Разумеется,
в конечном счете облачные серверы работают на физических компьютерах, которые
подключены к реальному сетевому оборудованию. Однако это не обязательно означа
ет, что виртуальные серверы, работающие на одном и том же хосте, объединены в сеть.
Комбинация технологии виртуализации и программируемого сетевого коммутационно
го оборудования дает платформенным поставщикам большую гибкость для определения
сетевой модели, которую они экспортируют клиентам.
Виртуальное частное облако
AWS (VPC)
УРС, программная сетевая технология для
сети в более широкой сети
AWS.
Amazon Web Services,
создает частные
Технология УРС впервые была представлена в
2009
г.
11.
Часть
466
Работа в сетях
как мост между локальным центром обработки данных и облаком, открывая множество
гибридных вариантов использования для корпоративных организаций. Сегодня
является центральной особенностью
AWS
записей. Экземпляры ЕС2 для новых учетных записей
ответствии с технологией
держкой родной
VPC,
AWS должны быть созданы
AWS запускаются с
в со
а большинство новых служб
под
VPC.2'
Перечислим основные функциональные особенности
•
VPC
и по умолчанию включена для всех учетных
Диапазон адресов
1Pv4,
VPC.
выбранный из частного адресного пространства
выраженный в нотации
CIDR
(например,
10.110.0.0/16
RFCl918,
10.110.0.0-
для адресов
IO.I 10.255.255). 28
Сегментация адресного пространства
•
•
•
•
VPC
на более мелкие подсети.
Таблицы маршрутизации, определяющие, куда отправлять трафик.
Группы безопасности, которые действуют как брандмауэры для экземпляров ЕС2.
Списки контроля доступа к сети
(Network Access
Coпtrol
List - NACL)
для изо
ляции подсетей друт от друrа.
Вы можете создать столько частных сетей
пользователь
AWS
VPC,
сколько вам нужно, и ни один другой
не имеет доступа к их сетевому трафику. 29 Сети
VPC
в одном регионе
могут взаимодействовать, создавая частные маршруты между отдельными сетями. Сети
VPC
в разных регионах могут быть связаны с программными VРN-туннелями через
Интернет или с дорогостоящими, настраиваемыми, прямыми подключениями к цен
трам обработки данных
AWS
через частные сети, которые вы должны арендовать у теле
коммуникационной компании.
Сети
VPC
могут быть такими же маленькими, как сеть
/28,
или большими как
Это очень важно планировать заранее, потому что после создания сети
VPC
/16.
ее размер
не может быть скорректирован. Выберите адресное пространство, которое достаточно
велико для обеспечения будущего роста, но также убедитесь, что оно не конфликтует
с другими сетями, которые вы можете подключить.
Подсети и таблицы маршрутизации
m
Дополнительную информацию о сегменте
Как и традиционные сети, сети
VPC
DMZ см. в разделе 27.8.
разделены на подсети. Публичные подсе
ти предназначены для серверов, которые должны напрямую общаться с клиентами
в Интернете. Они сродни традиционным сегментам
DMZ.
Частные подсети недоступны
из Интернета и предназначены для надежных или конфиденциальных систем.
Маршрутизация
VPC
проще, чем маршрутизация традиционной аппаратной сети,
поскольку облако не моделирует физическую топологию. Каждый получатель достига
ется за один логический переход.
В мире физических сетей каждое устройство имеет таблицу маршрутизации, которая
сообщает ему, как маршрутизировать исходящие сетевые пакеты. Но в сети
VPC табли
цы маршрутизации также являются абстрактным объектом, который определяется через
веб-консоль
27 Долrое
AWS
или ее эквивалент командной строки. Каждая подсеть
время пользователи жаловались на то, что службы
AWS
VPC
имеет свя-
являются неполными, если они
не поддерживают технологию УРС.
2 'Недавно
''8
2
в технологию УРС также добавили поддержку протокола IPvб
зависимости от состояния вашей учетной записи служба
AWS
может сначала ограничить вас
пятью сетями УРС. Однако, если вам это нужно, вы можете запросить более высокий лимит.
Глава
13. Сети TCP/IP
467
занную таблицу маршрутизации УРС. Когда экземпляры создаются в подсети, их табли
цы маршрутизации инициализируются из шаблона УРС.
Простейшая таблица маршрутизации содержит только статический стандартный
маршрут для доступа к другим экземплярам в пределах одного и того же УРС. Вы може
те добавить дополнительные маршруты для доступа в Интернет, локальные сети (через
УРN-соединения) или другие УРС (через пиринговые подключения).
Компонент, называемый интернет-шлюзом, соединяет сеть УРС с Интернетом. Этот
объект прозрачен для администратора и управляется службой
AWS.
Однако, если экзем
пляры должны иметь подключение к Интернету, необходимо создать этот объект само
стоятельно и добавить его к сети УРС. Хосты в публичных подсетях могут напрямую
обращаться к интернет-шлюзу.
Экземпляры в частных подсетях недоступны из Интернета, даже если им назначены
публичные IР-адреса, что приводит к большой путанице для новых пользователей.
Для исходящего доступа они должны переходить через NАТ-шлюз в общую под
сеть. Технология УРС предлагает управляемую функцию
NAT,
которая экономит ваши
накладные расходы на запуск собственного шлюза, но это требует дополнительных по
часовых затрат. Шлюз
NAT
является потенциальным узким местом для приложений
с высокими требованиями к пропускной способности, поэтому лучше найти серверы
для таких приложений в общественных подсетях, избегая NАТ.
Реализация службы
настроенные для
1Pv6,
AWS
в протоколе
1Pv6
не имеет механизма NАТ, и все экземпляры,
получают общедоступные (т.е. маршрутизируемые) адреса
делаете частные подсети
1Pv6
1Pv6.
Вы
конфиденциальными, подключая их через интернет-шлюз,
предназначенный только для исходящих соединений (объект с префиксом
egw),
который
блокирует входящие соединения. Шлюз запоминает состояние, поэтому внешние хосты мо
гут общаться с серверами в частной сети
1Pv6,
пока сервер
AWS
инициирует соединение.
Чтобы понять сетевую маршрутизацию для экземпляра, целесообразнее обратиться
к таблице маршрутизации УРС для своей подсети, чем просматривать фактическую та
блицу маршрутизации экземпляра (которую, например, может вывести на экран с помо
щью команды
netstat -r
или
ip route show
при регистрации в экземпляре). Версия
УРС идентифицирует шлюзы ("цели") своими идентификаторами
AWS,
что упрощает
анализ таблицы.
В частности, просмотрев таблицу маршрутизации УРС, можно легко отличить пуб
личные подсети от частных. Если стандартный шлюз (т.е. цель с адресом О. о. О. О/ О)
является интернет-шлюзом (объект с префиксом
igw),
то эта подсеть является общедо
ступной. Если стандартный шлюз является устройством
фиксом идентификатора экземпляра i или
В табл.
Таблица
13.13
13.13.
nat),
NAT
(целью маршрута с пре
то подсеть является частной.
показана примерная таблица маршрутизации для частной подсети.
Пример таблицы маршрутизации УРС для частной подсети
Тип цели
Пункт назначения
Цепь
10.110.0.0/16
local
Встроенный маршрут для локальной сети
О.О.О.О/О
nat-a31ed812
Дос-туп в Интернет через шлюз
10.120.0.0/16
рсх-38с3е8Ь2
Пиринговое соединение с другой
192.168.0.0/16
vgw-le513d90
VРN-шлюз во внешнюю сеть
VPC
VPC NAT
VPC
Сети УРС являются региональными, но подсети ограничены одной зоной доступ
ности. Чтобы создать высокодоступные системы, используйте по меньшей мере одну
468
Часть
11.
Работа в сетях
подсеть для каждой зоны и равномерно распределите экземпляры всех подсетей. В ти
пичной схеме балансировщики нагрузки или другие прокси-серверы размещаются
в публичных подсетях и ограничивается доступ к неб-серверам, приложения и серверам
баз данных только из частных подсетей.
Группы безопасности и
группы безопасности
NACL
-
это брандмауэры для экземпляров ЕС2. Правила группы
безопасности определяют, какие исходные адреса разрешены для трафика
ICMP, UDP
и ТСР (входные правила), а какие порты в других системах могут быть доступны экзем
плярам (выходные правила). Группы безопасности по умолчанию запрещают все под
ключения, поэтому любые добавленные вами правила создают дополнительный трафик.
Все экземпляры ЕС2 принадлежат хотя бы одной группе безопасности, но могут быть
частью даже пяти групп. 30 Чем больше групп безопасности принадлежит экземпляру, тем
более запутанным может быть определение того, какой трафик разрешен, а какой нет. Мы
предпочитаем, чтобы каждый экземпляр находился только в одной группе безопасности,
даже если эта конфигурация приводит к некоторым повторяющимся правилам среди групп.
При добавлении правил в группы безопасности всегда учитывайте принцип наи
меньших привилегий. Открытие излишне большого количества портов создает угрозу
для безопасности, особенно для систем с общедоступными маршрутизируемыми IР
адресами. Например, неб-серверу могут потребоваться только порты
ется для управления и администрирования системой),
80
(НТТР) и
22 (SSH, использу
443 (НТТРS).
Кроме того, все хосты должны принимать IСМР-пакеты, используемые для реали
зации обнаружения МТU-пути. Неспособность принять эти пакеты может значительно
снизить пропускную способность сети, поэтому мы с недоумением восприняли реше
ние
AWS
на сайте
блокировать их по умолчанию (см. страницу
docs. aws. ama zon. com),
goo. gl/WrETNq (глубокая ссылка
где описаны действия по включению этих пакетов).
Большинство групп безопасности имеют детальные правила, регламентирующие вхо
дящий трафик, но разрешают весь исходящий трафик, как показано в табл.
13.14.
Эта
конфигурация удобна, так как вам не нужно думать о том, какую внешнюю связь имеет
ваша система. Тем не менее злоумышленникам легче достичь своей цели, если они мо
гут подобрать средства и общаться с системами, находящимися под их внешним управ
лением. Самые безопасные сети имеют как входящие, так и исходящие ограничения.
Таблица
13.14. Типичные
Направление
Протокол
правила группы безопасности
Порты
CIDR
Примечание
Вход
ТСР
22
10.110.0.0/16
SSH из внутренней сети
Вход
ТСР
80
О.О.О.О/О
НТТР из любого места
Вход
ТСР
443
О.О.О.О/О
НТТРS из любого места
Вход
ICMP
п/а•
О.О.О.О/О
Разрешить обнаружение
Выход
ALL
ALL
О.О.О.О/О
Исходящий трафик (все ОК)
MTU пути
•Подробные инструкции см, на странице goo. gl /WrETNq; эта запись немного сложна для настройки.
"'Группы безопасности фактически связаны с сетевыми интерфейсами, и экземпляр может иметь
более одного сетевого интерфейса. Поэтому, чтобы быть совершенно правильно понятыми, мы
должны сказать, что максимальное количество групп безопасности
интерфейсов, умноженное на пять.
-
это количество сетевых
глава
13. Сети TCP/IP
469
Подобно спискам контроля доступа на устройстве брандмауэра, списки
NACL управ
NACL
ляют трафиком между подсетями . В отличие от групп безопасности, списки
не имеют состояния : они не различают новые и существующие соединения. Они чем-то
похожи на списки
NACL на аппаратном брандмауэре . Списки NACL разрешают весь
трафик по умолчанию. На практике группы безопасности используются гораздо чаще,
чем
NACL.
Пример архитектуры
На рис.
13.6
изображены две сети УРС, каждая из которых содержит публичные и част
ные подсети. Сеть
подсетях.
ELB
VPC
2 размещает
балансировщик эластичной нагрузки в своих публичных
действует как прокси-сервер для некоторых экземпляров ЕС2 с автомати
ческим масштабированием, которые находятся в частной подсети и защищают эти экзем
пляры из Интернета. Службе
ной в сети
2 в сети 2 может потребоваться доступ к службе 1, размещен
1, и они мoryr общаться конфиденциально посредством пиринга УРС.
УРС 1: 10.110.0.0/16
Публичные СfТИ
Программа Terгaform не зависит от конкретного облака, поэтому она может управ
лять ресурсами для
AWS, GCP, DigitalOcean, Azure, Docker и других поставщиков .
Terraform, а когда - CLI? Если вы создаете инфраструктуру
Когда использовать
для команды или проекта, или вам нужно будет внести изменения и повторить сборку
позже, используйте
Terraform.
Если вам нужно запустить быстрый экземпляр в качестве
теста, просмотреть сведения о ресурсе или получить доступ к
используйте
API
из сценария оболочки ,
CLI.
Сеть на платформе
На платформе
Google Cloud Platform
Google C\oud Platform
сетевое взаимодействие является функцио
нальной частью платформы, а не представляет собой отдельный сервис. Частные сети
GCP
являются глобальными: экземпляр в регионе
гим экземпляром в регионе
e uro pe-we st 1
us-ea st l
может связываться с дру
через частную сеть, что упрощает создание
глобальных сетевых служб. Сетевой трафик между экземплярами в одной и той же зоне
является бесплатным, но есть плата за трафик между зонами или регионами .
Новые проекты имеют сеть по умолчанию с диапазономадресов 1О .24О . О .О / 16 . Вы
можете создать до пяти отдельных сетей для каждого проекта, а экземпляры являются
членами одной сети. Многие сайты используют эту сетеву ю архитектуру для изоляции
тестов и разработки от производственных систем .
Сети могут подразделяться по регионам с подсетями. Это относительно недавнее до
полнение к платформе
GCP,
которое отличается от подсетей на базе
сеть не должна быть частью одного диапазона префиксов
жет быть несколько префиксов. Платформа
GCP
1Pv4,
AWS.
Глобальная
и в каждом регионе мо
настраивает всю маршрутизацию, по
этому экземпляры на разных СIDR-блоках в одной и той же сети могут по-прежнем у
взаимодействовать друг с другом. Эта топология показана на рис.
13.7.
----1Внутренняя маршрутизация~-----..
10.100.0.105
10.100.0.103
10.120.0.94
[]
192.168.10.19
us-central1-f
us-central1-b
us-central1
10.100.0.0/16
192.168.10.0/24
Рис.
13. 7.
Частная сеть
GCP с подсетями
us-east1-b
us-east1
10.120.0.0/16
и несколькими регионами
Подсети не классифицируются как публичные или частные; вместо этого экземпля
ры, которые не должны принимать входящий трафик из Интернета , могут просто не
иметь общедоступного адреса, обращенного к Интернету. Компания
Google
предлага
ет статические внешние IР- адреса , которые вы можете использовать в записях
DNS,
не
Глава
473
13. Сети TCP/IP
опасаясь, что они будут назначены другому клиенту. Когда экземпляр имеет внешний
адрес, вы все равно не увидите его, выполнив команду
ip addr show;
компания
Google
выполняет перевод адресов дЛЯ вас.
По умолчанию правила брандмауэра в сети
GCP
применяются ко всем экземплярам.
Чтобы ограничить правила меньшим набором экземпляров, вы можете пометить экзем
пляры и фильтровать правила в соответствии с тегами. Глобальные правила брандмауэра
по умолчанию запрещают все, кроме следующих:
• IСМР-трафик дЛЯ О/О;
• RDP (удаленный настольный компьютер дЛЯ Windows, ТСР-порт 3389) дЛЯ 0/0;
• SSH (порт ТСР 22) дЛЯ О/О;
• все порты и протоколы дЛЯ внутренней сети (по умолчанию 10.240.0.0/16).
Когда речь идет о решениях, влияющих на безопасность, мы всегда возвращаемся
к принципу наименьших привилегий. В этом случае мы рекомендуем сузить эти пра
вила по умолчанию, чтобы полностью блокировать
RDP,
разрешать
SSH
только из ва
ших собственных исходных IР-адресов и дополнительно ограничивать трафик в сети
GCP.
Вы также можете заблокировать
IСМР-пакеты типа
Сеть
3,
код
4,
ICMP,
но имейте в виду, что вам нужно разрешить
чтобы включить обнаружение МТU-пути.
DigitalOcean
Сеть
DigitalOcean
не имеет частной сети, по крайней мере такой, как
GCP
и
AWS.
Дроплеты могут иметь частные интерфейсы, которые обмениваются данными по вну
тренней сети в одном регионе. Однако эта сеть используется совместно со всеми други
ми клиентами
DigitalOcean
в том же регионе. Это небольшое улучшение по сравнению
с использованием Интернета, но брандмауэры и шифрование в пути становятся жестки
ми требованиями.
Мы можем исследовать загруженный дроплет
DigitalOcean
с помощю интерфейса
CLI tugboat:
$ tugboat info ulsah
Droplet fuzzy name provided. Finding droplet ID ... done, 8857202
(ulsah-ubuntu-15-10)
ulsah-ubuntu-15-10
Name:
8857202
ID:
active
Status:
45.55.1.165
IP4:
2604:A880:0001:0020:0000:0000:01EF:D001
IP6:
10.134.131.213
Private IP:
San Francisco 1 - sfol
Region:
14169855 - ubuntu-l5-10-x64
Image:
512МВ
Size:
Backups Active: false
Вывод включает в себя адрес IPvб в дополнение к общедоступным и частным адре
сам
1Pv4.
На примере мы можем продолжить изучение, просмотрев адреса на локальных
интерфейсах.
# tugboat ssh ulsah-uЬuntu-15-10
# ip address show ethO
2: ethO: mtu 1500 qdisc pfifo fast
state UP group default qlen 1000
link/ether 04:01:87:26:d6:01 brd ff:ff:ff:ff:ff:ff
Часть
474
11.
Работа в сетях
inet 45.55.1.165/19 brd 45.55.31.255 scope global ethO
valid_lft forever preferred_lft forever
inet 10.12.0.8/16 scope global ethO
valid_lft forever preferred_lft forever
inet6 fe80::601:87ff:fe26:d601/64 scope link
valid_lft forever preferred_lft forever
# ip address show ethl
3: ethl: mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 04:01:87:26:d6:02 brd ff:ff:ff:ff:ff:ff
inet 10.134.131.213/16 brd 10.134.255.255 scope global ethl
valid_lft forever preferred_lft forever
inet6 fe80::601:87ff:fe26:d602/64 scope link
valid_lft forever preferred_lft forever
Общий адрес присваивается непосредственно интерфейсу
ethO,
а не транслирует
ся провайдером, как на других облачных платформах. Каждый интерфейс также имеет
1Рv6-адрес, поэтому можно одновременно обслуживать трафик через
1Pv4 и 1Pv6.
13.16. ЛИТЕРАТУРА
История
•
СомЕR, DouuLлs Е. Jnternetworking with ТСР//Р Volume 1: Principles, Protocols, and
Architectures (бth Edition). Upper Saddle River, NJ: Prentice Hall, 2013. Эта книга дол
гое время являлась стандартным справочником по протоколам TCP/IP. Она напи
сана как учебник для студентов и является хорошим введением в тему.
•
Sлшs,
МА:
PETER Н. Casting the Net, From ARPANET to INTERNET and Beyond. Reading,
Addison-Wesley Professional, 1995. Это прекрасная история ARPANET, пред
течи Интернета, написанная ученым, который так долго был близко знаком с раз
работчиками системы
UNIX,
что стал восприниматься как один из них. Эта книга
представляет собой отличный сборник документов об истории Интернета и его
ра111ичных технологиях (см. сайт
isoc. org / internet/history).
Классика
•
SтEVF.NS,
W. R1cнARIJ. UNJX Network Programming. Upper Saddle River, NJ: Prentice
Hall, 1990.
• Sпvt.:Ns, W. R1c11лRD, BIL.L FENNER, AND ANDREW М. RuDOFI'. UNJX Network
Programming, Volume 1, The Sockets Networking APJ (З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, 1999.
Эти книги - канонические учебники о сетевых классах, в том числе о сетевом
программировании в UN IX. Если вам нужен только интерфейс сокетов Berkeley,
оригинальное издание по-прежнему является прекрасным источником знаний.
Если вам нужен интерфейс
STREAMS,
то третья версия, включающая IPvб,
-
хо
роший выбор. Все три книги четко и ясно написаны в типичном стиле Ричарда
Стивенса.
Глава
•
13. Сети TCP/IP
475
ТлNЕNвлuм,
ANDREW S., AND Dлvro J. WEТHERALL. Computer Networks (5th Edition).
Upper Saddle River, NJ: Prentice Hall PTR, 2011.
Это первая книга о сетях, которая стала классикой. Она содержит подробное опи
сание всех деталей физических и канальных уровней стека протоколов. Последнее
издание охватывает беспроводные сети, гигабитную сеть
Ethernet,
одноранговые
сети, голосовую IР-телефонию, сотовые сети и т.д.
Протоколы
•
FлLL,
KEVIN R" AND W.
(2nd Edition). Reading,
R1снлRо SТEVENS. ТСР//Р
lllustrated, Volume
Опе:
The Protocols
Addison-Wesley, 2011.
• WRIGHT, GлRY R" AND W. RtcHARD STEVENS. ТСР//Р lllustrated, Volume Two: The
lmplementation. Reading, МА: Addison-Wesley, 1995.
Книги в серии TCP/IP lllustrated - отличное и подробное руководство по стеку
протоколов ТСР
МА:
/1 Р.
• HtJNT, СRлю. ТСР//Р Network Administration (Згd Edition). Sebastopol, СА: O'Reilly
Media, 2002. Как и другие книги данной серии, эта книга предназначена для ад
министраторов систем UNIX. Половина книги посвящена протоколу TCP/IP,
а остальная часть описывает высокоуровневые функции UNIX, такие как элек
тронная почта и удаленная регистрация.
•
FлRREL,
AoRtAN. The lnternet and lts Protocols: А Comparative Approach. San Francisco,
Morgan Kaufmann PuЬlishers, 2004.
• KozrERAK, CНARLES М. The ТСР//Р Guide: А Comprehensive, !llustrated lnternet Protocols
Reference. San Francisco, СА: No Starch Press, 2005.
• DoNAHUE, GARY А. Network Warrior: Everything Уои Need to Know That Wasn't оп the
CCNA Ехат. Sebastopol, СА: O'Reilly Media, 2015.
СА:
глава
14
Сетевые аппаратные средства
Независимо от того, работают ваши системы в центре обработки данных, в облаке
или пусковой ракетной шахте, у них есть нечто общее
-
необходимость обмена ин
формацией по сети. Возможность быстрой и надежной передачи данных необходима
в любой среде. Если есть область, в которой технология
UNIX
затронула человеческие
жизни и повлияла на другие операционные системы, то она связана с практической ре
ализацией крупномасштабного пакетированного транспорта данных.
Сети проходят такую же эволюцию, как и серверы, поскольку физические и логи
ческие представления сети все больше разделяются уровнем виртуализации, имеющим
собственную конфигурацию. В облаке такие конфигурации являются стандартными, но
даже физические центры обработки данных в настоящее время часто включают в себя
слой программно конфигурируемых сетей
(software-defined networking - SDN).
Администраторы взаимодействуют с сетевым оборудованием реального мира менее
часто, чем когда-то, но знакомство с традиционными сетями остается решающим на
выком. Виртуализированные сети тесно имитируют физические сети в своих функциях,
терминологии, архитектуре и топологии.
Многие сетевые технологии продвигались в течение долгих лет, но в результате поя
вился очевидный победитель
- Ethemet.
Сегодня технологию
Ethemet
можно встретить
всюду: от игровых приставок до холодильников. Глубокое понимание принципов работы
этой системы чрезвычайно важно для успешной работы системного администратора.
Совершенно очевидно, что быстродействие и надежность сетей непосредственно
влияют на результаты деятельности компаний. Однако в настоящее время сетевые тех
нологии настолько вездесущи, что состояние сети может повлиять на возможность вза-
478
Часть
11. Работа
в сетях
имодействия между людьми, например возможность делать телефонные звонки. Плохая
организация сети
-
это личная и профессиональная неудача, которая может иметь ката
строфические социальные последствия. Кроме того, устранение этих недостатков порой
обходится очень дорого.
Успешное создание сети зависит от по крайней мере четырех важнейших факторов:
разработки разумной структуры сети;
•
•
•
•
выбора высококачественного оборудования;
правильной инсталляции и документирования;
компетентной эксплуатации и сопровождения.
В этой главе рассматриваются принципы, инсталляция и функционирование се
тей
Ethemet. Мы также кратко опишем такие устаревшие технологии, как DSL (Digital
Subscriber Line), которые обычно предстают перед конечными пользователями в обли
ке - сюрприз! - технологии Ethernet.
14.1. Технология
ETHERNET: СЕТЕВАЯ ПАНАЦЕЯ
Захватив более
95% мировоrо рынка локальных сетей (l..ocal Area Network - LAN),
Ethemet в самых разных формах проявляется почти всюду. Разработку стан
Ethemet начал Боб Меткалф (ВоЬ Metcalfe) из Массачусетского технологического
технология
дарта
института в рамках своей кандидатской диссертации, но в настоящее время она описана
во многих стандартах
IEEE.
В первоначальной спецификации
ных
Ethernet
была определена скорость передачи дан
10 Мбит/с. Как
1994 году была закончена работа над стандартом, предусматривавшим скорость
100 Мбит/с, стало ясно, что технология Ethemet будет лишь эволюционировать, а не вы
3
Мбит/с (мегабит в секунду), но почти сразу же она выросла до
только в
тесняться новой технологией. Это вызвало гонку технологий, в ходе которой произво
дители старались создать все более быстродействующую версию
Ethemet,
и это сорев
нование еще не закончено. Основные этапы эволюции различных стандартов
приведены в табл.
Таблица
Ethernet
14. JI.
14. 1. Эволюция Ethernet
Год
Скорость
Название стандарта
1973
1976
3 Мбит/с
10 Мбит/с
Xerox Ethernet
Ethernet 1
1989
10 Мбит/с
10BASE-T
НомерlЕЕЕ
802.3
Расстояние
Средство передачи•
?
Коаксиальный кабель
500м
Коаксиальный кабель
100м
RG-11
Медный кабель НВП категории Э
1994
100 Мбит/с
100Ваsе-ТХ
802.Эu
100м
Медный кабель НВП категории
1999
1 Гбит/с
1OOOBASE-T ("gigablt")
802.ЭаЬ
100 м
5
Медный кабель НВП катего-
рий 5е и
2006
10 Гбит/с
10GBASE-T ("10 Gig")
802.Эаn
100м
6
ВП категории ба,
7, НВП
тегории 7а
2009
40 Гбит/с
40GBASE-CR4
40GBASE-SR4
1 Мы
Р802.3Ьа
10м
Медный кабель НВП
100 м
ММ-оптоволокно
не упомянули несколько менее популярных стандартов.
ка-
Глава
14. Сетевые
аппаратные средства
479
Окончание табл.
Год
Скорость
Название стандарта
Номер
2009
100 Гбит/с
100GBASE-CR1 О
100GBASE-SR10
200GBASE-FR4
200Gbase-LR4
400GBASE-SR16
400Gbase-DR4
400GBASE-FR8
400Gbase-LR8
Р802.ЗЬа
2018 6
2018 6
2020 6
'ММ
-
200 Гбит/с
400 Гбит/с
Пбит/с
ТЬЕ
многомодовое, НВП
-
IEEE
Расстояние
1О
Средство передачи•
Медный кабель НВП
м
100м
М М-оптоволокно
Р802.ЗЬs'
2км
СWDМ-оптоволокно
СWDМ-оптоволокно
Р802.ЗЬs
10 км
100 м
500м
ММ-оптоволокно
TBD
неэкранированная витая пара, ВП
ММ-оптоволокно
(16 жил)
(4 жилы)
2 км
СWDМ-оптоволокно
10 км
TBD
СWDМ-оптоволокно
-
14. 1
TBD
витая пара,
CWDM -
разреженное спектраль
ное мультиплексирование.
"Промышленный проект.
'Мы немного сомневаемся и предполагаем, что этот вариант кодировки был неудачным совпадением.
Как работает
Технологию
Ethernet
Ethernet
можно представить в виде великосветского раута, на котором
гости (компьютеры) не перебивают друг друга, а ждут паузы в разговоре (отсутствия
трафика в сетевом кабеле), чтобы заговорить. Если два гостя начинают говорить одно
временно (т.е. возникает конфликт), оба они останамиваются, извиняются друг перед
другом, ждут немного, а затем один из них начинает говорить снова.
В технической терминологии такая схема называется
Multiple Access with Collision Detection -
CSMA/CD (Carrier Sense
множественный доступ с контролем несущей
и обнаружением конфликтов). Смысл этого названия :шключается в следующем:
•
•
•
контроль несущей
(CS) -
вы можете говорить одновременно с другими;
множественный доступ (МА)
обнаружение конфликтов
- говорить могут все;
(CD) - вы знаете, когда перебиваете
кого-то.
Фактическая задержка при обнаружении конфликтов является случайной. Это позволяет избежать такого развития событий, при котором два компьютера одновременно
передают сообщения в сеть, обнаруживают коллизию, ждут некоторое время, а затем
синхронно возобновляют передачу, переполняя, таким образом, сеть конфликтами.
В настоящее время важность соглашений
CSMA/CD
осознали даже приверженцы
коммутаторов, которые обычно ограничивают количество хостов в домене, в котором
происходят коллизии, до двух. (Если продолжить аналогию с великосветским раутом,
можно описать этот вариант как ситуацию, в которой два собеседника, как в старом
кино, чопорно сидят на противоположных концах длинного обеденного стола.)
Топология
Ethernet
С точки зрения топологии сеть
Ethernet
представляет собой разветвляющуюся шину,
но без петель. У пакета есть только один путь следования между любыми двумя хостами,
расположенными в одной сети. В сети
однонаправленные
(unicast),
Пакеты первого типа адресованы
всем хостам сегмента.
Ethernet могут передаваться пакеты трех типов:
(multicast) и широковещательные (broadcast).
одному хосту, второго - группе хостов, третьего -
групповые
Часть
480
Широковещательный домен
-
11. Работа
в сетях
это совокупность хостов, которые принимают па
кеты, направляемые по аппаратному широковещательному адресу. В каждом логи
ческом сегменте сети
В ранних стандартах
Ethernet
Ethernet
существует только один широковещательный домен.
и средствах передачи (например,
10Base5)
понятия
физического и логического сегментов были тождественными, поскольку все пакеты
передавались по одному большому кабелю, в который втыкались сетевые интерфей
сы компьютеров 2 •
С появлением современных коммутаторов логические сегменты стали включать
в себя множество (десятки и даже сотни) физических сегментов, к которым подклю
чено всего два устройства: порт коммутатора и компьютер. Коммутаторы отвечают за
доставку групповых и однонаправленных пакетов в физический сегмент, где расположен
нужный адресат (адресаты); широковещательные пакеты направляются во все сетевые
порты логического сегмента .
С появлением коммутаторов сегодняшние логические сегменты обычно состоят из
многих физических сегментов (возможно, десятков или сотен). к которым подключе
ны только два устройства: порт коммутатора и хост..~ Коммутаторы несут ответствен
ность за сопровождение многоадресатных и одноадресатных пакетов к физическим
(или беспроводным) сегментам , на которых находятся предполагаемые получатели .
Широковещательный трафик пересылается всем портам в логическом сегменте.
Логический сегмент может состоять из физических сегментов, имеющих разную ско
рость передачи данных. Следовательно, коммутаторы должны иметь средства буфериза
ции и синхронизации для предотвращения возможных конфликтов.
Неэкранированная витая пара
Неэкранированная витая пара (НВП)
в сетях
Ethernet.
-
самая популярная среда передачи данных
Общая схема сети на основе НВП изображена на рис.
14.1.
r@51
~
Питание
Рабочая станция
Рабочая станция
Рис.
2
14. /.
Ethernet-npинтep
Схема сети на основе НВП
Мы не шутим! Подключение нового компьютера к сети предполагало прокалывание отверстия
в изоляuии кабеля с помощью спеuиального соединителя , называемого «зуб вампира», который
позволял добраться до uентральноrо проводника. Этот соединитель затем зажимался винтами .
'Беспроводные сети
-
еше один распространенный тип логического сегмента Ethernet. Они ведут
Ethernet, которые используют один кабель для соединения
себя, скорее, как традиuионные формы
многих хостов сети (см. раздел
14.2).
Глава
481
14. Сетевые аппаратные средства
Провода, используемые в современных локальных вычислительных сетях на осно
ве неэкранированной витой пары, обычно подразделяют на восемь категорий. Эта си
стема оценки параметров была впервые введена компанией Anixter, крупным постав
щиком кабельной продукции, и впоследствии стандартизирована организацией
(Telecommunications lndustry Association -
1-7 и промежуточные
ISO (lnternational Organization for Standartization -
мышленности). Сегодня выделяются категории
Организация
TIA
ассоциация телекоммуникационной про
категории 5е и ба.
Международная
организация по стандартизации) тоже подключилась к процессу стандартизации кабе
лей и предложила собственную классификацию, которая почти в точности повторяет
классификацию ПА Например, кабель категории
класса
D
в системе
ISO.
Для наглядности в табл.
5 в системе ПА эквивалентен кабелю
14.2 подытожены ключевые различия
между основными современными стандартами кабелей. Эта таблица поможет вам про
извести впечатление на своих друзей во время вечеринки.
Таблица 14.2. Характеристики кабелей НВП
Единица
Параметр•
Категории
измерения
5 D6
5е
6Е
6аЕА
7F
7aFA 81
Ширина полосы
МГц
Затухание
дБ
дБ
дБ
Затухание отраженного сигнала
дБ
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
ELFEXТ
100
24
ЗО, 1
17,4
10
250
21,7
NЕХТ
100
24
27, 1
17
8
нс
548
548
548
548
504
534
548
8
{обратная потеря)
Задержка распространения сигнала
(Near-end crosstalk) - ослабление перекрестной наводки на ближнем конце.
crosstalk) - ослабление равноуровневой перекрестной наводки на дальнем конце.
0 Включая дополнительные спецификации TIA TSB 95 и ISO FDAM 2.
"NЕХТ
Кабель категории
ELFEXТ
(Equal level far-end
5 поддерживает работу на скорости 100 Мбит/с. Кабели категорий 5е,
1 Гбит/с и в настоящее время используются в ка
б и ба поддерживают скорость передачи
честве стандарта. Кабель категории ба лучше всего подходит для организации новых сетей,
поскольку он особенно устойчив к помехам, возникающим из-за использования старых
Более быстродействующие стандарты требуют применения нескольких пар НВП. Это
ускоряет передачу данных по линии связи по сравнению с использованием единственной
lOBASE-T требуются две пары проводов категории 5. В соедине
IOOBASE-TX предельная длина та же, но используются две пары проводов катего
рии 5. Соединение \ОООВАSЕ-ТХ требует четырех пар проводов категорий 5е или б/ба.
Аналогично соединение IOGBASE-ТX требует четырех пар проводов категорий ба, 7 или
7а. Длина кабеля во всех стандартах ограничена 100 м.
пары. Для соединений
ниях
Существуют провода с поливинилхлоридной и тефлоновой изоляцией. Выбор изо
ляции диктуется средой, в которой будут проложены кабели. В замкнутых помещениях,
связанных с вентиляционной системой здания, обычно требуется тефлоновая изоляция 4 •
Поливинилхлоридная изоляция дешевле и проще в эксплуатации.
•конкретную информацию можно получить у пожарного инспектора или ответственного за
пожарную безопасность.
482
Часть
11.
Работа в сетях
Подключая четырехпарный НВП-кабель к коммутационным панелям и настенным
розеткам
RJ-45,
придерживайтесь стандарта разводки ТIA/EIA-568A. Этот стандарт, со
вместимый с другими вариантами
RJ-45
(например,
RS-232),
позволяет избежать оши
бок при разводке концов кабеля, независимо от того, есть ли свободный доступ к парам.
Требования стандарта отражены в табл.
14.3.
Таблица 14.З. Стандарт TIA/EIA-568A для подключения четырехпарного
НВП-кабеля к розетке RJ-45
Пара
Цвета
Контакты разъема
1
2
Белый/синий
Белый/оранжевый
5/4
3/6
3
4
Белый/зеленый
1/2
Белый/коричневый
7/8
Имеющаяся в здании проводка может не подходить для прокладки сетей, в зависи
мости от того, как и когда она прокладывалась.
Оптическое волокно
Оптическое волокно используется в тех ситуациях, когда применение медного ка
беля по тем или иным причинам неприемлемо. Оптическое волокно передает сигнал
быстрее, чем медный провод. Кроме того, оно является более устойчивым к электриче
ским помехам, что в некоторых приложениях очень важно. Там, где оптическое волокно
не является абсолютно необходимым, обычно выбирают медный кабель, поскольку он
дешевле и с ним легче работать.
Оптическое волокно бывает "многомодовым" и "одномодовым". Многомодовое оп
тическое волокно обычно используется в зданиях или комплексах зданий. Оно толще,
чем одномодовое, и может проводить несколько лучей света; это свойство позволяет ис
пользовать менее дорогую электронику (например, в качестве источника света можно
использовать светодиоды).
Одномодовое оптическое волокно часто используется в магистральных приложени
ях, например для прокладки линий связи между городами и регионами. Оно может про
водить только один световой луч и требует дорогой прецизионной электроники в конеч
ных точках.
Следует помнить основное правило: все элементы должны соот
ветствовать друг другу. Оптическое волокно, соединяющее конечные точки, оптические
кабели перекрестной коммутации и электронные приборы, установленные в конечных
точках, должны иметь один и тот же тип и размер. Обратите внимание на то, что кабели
ОМ 1 и ОМ2 не являются взаимозаменяемыми, хотя и окрашены в один и тот же оран
жевый цвет
-
проверьте размеры, указанные на кабелях, чтобы убедиться, что они со
ответствуют друг другу. Если вы нарушите это правило, то вам будет сложно обеспечить
изоляцию в конечных точках.
На концах оптических волокон используются разъемы более чем
30
типов, и нет ни
четких правил, ни принципов, регламентирующих их выбор. В каждой конкретной си
туации на выбор того или иного типа разъема влияют поставщики оборудования или
параметры оптического волокна, уже проложенного внутри здания.
можно соединять с помощью устройств нескольких типов. На выбор
устройств, описанных ниже, влияет их стоимость, причем более дешевые устройства
описаны в первую очередь. Чем сложнее логические правила, по которым устройства
перемещают биты из одной сети в другую, тем больше аппаратного и встроенного про
граммного обеспечения необходимо и тем более дорогой становится сеть.
Концентраторы
Концентраторы
(hub)
иногда еще называют повторителями
ные устройства, используемые для соединения сегментов сетей
(repeators). Это актив
Ethemet на физическом
уровне. Им требуется внешний источник питания.
Выступая в качестве повторителя, концентратор ретранслирует Еthеmеt-фреймы, но
никак не интерпретирует их. Он "не имеет представления" ни о том, куда направля
ются пакеты, ни о том, какой протокол они используют. За исключением экзотических
ситуаций, концентраторы больше не должны использоваться в промышленных сетях, и мы
не советуем их использовать даже в домашних сетях. (Почему? Потому что коммутаторы
(switches)
значительно эффективнее используют полосу пропускания частот в сети и в
настоящее время стоят недорого.)
Коммутаторы
Коммутатор соединяет сети
Ethemet
на канальном уровне. Его назначение
-
объ
единить две физические сети так, чтобы они выглядели как одна большая физическая
сеть. В настоящее время коммутаторы являются промышленным стандартом для соеди
нения устройств
Ethemet.
Коммутаторы принимают, регенерируют и ретранслируют пакеты на аппаратном
уровне. Они используют алгоритм динамического обучения. Коммутаторы запоминают,
какие исходные адреса поступают с одного порта, а какие
-
с другого. Пакет переходит
из одного порта в другой только при необходимости. Первоначально пересьшаются все
пакеты, но через несколько секунд, когда коммутатор изучит расположение большин
ства хостов сети, запускается механизм фильтрации.
Поскольку между сетями пересылаются не все пакеты, каждый сегмент кабеля менее
загружен, чем в случае, когда все компьютеры подключены к одному кабелю. А если
учесть, что основной трафик имеет тенденцию к локализации, то увеличение реальной
пропускной способности может оказаться заметным. Кроме того, коммутатор не влияет
на логическую модель сети, поэтому его установка требует лишь незначительного вме
шательства со стороны администратора.
Часть
484
11. Работа
в сетях
Если сеть имеет петли, коммутатор может безнадежно запутаться, потому что паке
ты, посылаемые одним компьютером, окажутся сразу на двух (или более) портах ком
мутатора. В одной сети
Ethernet
петлей не бывает, но после объединения нескольких
таких сетей с помощью маршрутизаторов и коммутаторов топология изменится, вслед
ствие чего может образоваться несколько путей к одному хосту. Некоторые коммутаторы
решают эту проблему путем резервирования альтернативных маршрутов на тот случай,
если основной маршрут станет недоступным. Они упрощают топологию видимой ими
сети, отсекая дублирующиеся пути до тех пор, пока в оставшихся сегментах не окажется
только по одному маршруту к каждому хосту сети. Другие коммутаторы создают между
сетями двойные каналы и переключают трафик по циклическому принципу.
Коммутаторы должны просматривать каждый пакет, определяя, нужно ли
ero
пере
сылать в другой сегмент. Производительность этих устройств обычно измеряют как ско
ростью просмотра пакетов, так и скоростью их пересылки. Многие поставщики не ука
зывают в диаграммах производительности коммутаторов размеры протестированных
пакетов, поэтому реальная производительность может быть ниже объявленной.
Несмотря на то что быстродействие коммутаторов
Ethernet
все время растет, эффек
тивно использовать их можно при объединении в один логический сегмент не более
сотни компьютеров. В крупных коммутируемых сетях часто возникают проблемы напо
добие "широковещательных штормов", поскольку широковещательный трафик должен
проходить через все порты. Для решения этой проблемы нужно изолировать широко
вещательный трафик между коммутируемыми сегментами посредством маршрутизатора
(создавая тем самым более одного логического Ethernet-ceгмeнтa).
Выбор коммутатора может представлять определенную трудность. В этом сегменте
рынка очень высокая конкуренция, следствием которой являются многочисленные ре
кламные заявления, не всегда подтверждаемые на практике. Поэтому не стоит особо до
верять данным, которые приводятся поставщиками; лучше прислушаться к советам не
зависимых экспертов (просмотрите тесты, приводимые в журналах). В последние rоды
нередко случалось так, что чей-то продукт оказывался "лучшим" в течение нескольких
месяцев, а затем, после попыток внесения улучшений,
ero
производительность или на
дежность падала ниже критической отметки.
В любом случае убедитесь, что скорость объединительной панели коммутатора явля
ется достаточной. У хорошо спроектированного коммутатора эта скорость должна пре
вышать сумму скоростей всех его портов.
Коммутаторы, позволяющие создавать виртуальные локальные сети
В крупных организациях можно использовать коммутаторы, позволяющие разбивать
их порты (программным путем) на группы, называемые виртуальными локальными се
тями
(Virtual Local Area Network - VLAN).
Виртуальная локальная сеть
-
это группа
портов, принадлежащая к одному логическому сегменту, как если бы порты были соеди
нены со своим собственным выделенным коммутатором. Подобное секционирование
позволяет повысить степень изоляции трафика, что полезно с точки зрения как безопас
ности, так и производительности.
Трафиком между виртуальными локальными сетями управляет маршрутизатор или,
в некоторых случаях, модуль маршрутизации или уровень программной маршрутизации
самого коммутатора. Расширение этой системы, называемое транкингом виртуальной
локальной сети (один из примеров реализации
-
протокол
IEEE 802. \Q),
позволяет раз
ным коммутаторам обслуживать порты одной логической виртуальной локальной сети.
Глава
14. Сетевые аппаратные
485
средства
Важно помнить, что сами сети
VLAN
почти не обеспечивают дополнительной защи
ты. Для того чтобы обеспечить защиту, необходимо фильтровать трафик
VLAN.
Маршрутизаторы
Маршрутизаторы (известные также как "коммутаторы третьего уровня") направля
ют трафик на третьем сетевом уровне модели
OSI.
Маршрутизаторы доставляют пакеты
адресатам на основании информации, хранящейся в ТСР/IР-заголовках. Помимо про
стого перемещения пакетов, маршрутизаторы могут также выполнять ряд особых функ
ций, например фильтрацию пакетов (в соответствии с правилами безопасности), раз
деление трафика по приоритетам (в соответствии с заданным качеством обслуживания)
и обнаружение общей сетевой топологии.
Конфигурация маршрутизаторов бывает фиксированной или модульной.
•
Устройства первого типа содержат сетевые интерфейсы, установленные в за
водских условиях. Они обычно подходят для специализированных применений.
Например, маршрутизатор с интерфейсами Т1 и
Ethernet
может оказаться удоб
ным, когда нужно подключить небольшую компанию к Интернету.
Модульные маршрутизаторы имеют слотовую или шинную архитектуру, а ин
•
терфейсы к ним добавляются пользователями. Как правило, это более дорогие
устройства, но зато они гибче в эксплуатации.
В зависимости от необходимой надежности и ожидаемого трафика, специализиро
ванный маршрутизатор может оказаться как дороже, так и дешевле системы
Linux,
UNIX
или
сконфигурированной в качестве маршрутизатора. Однако специализированное
устройство, как правило, демонстрирует более высокую производительность и надеж
ность. Это та область сетевого проектирования, где лучше заранее вложить чуть больше
денег, чем потом иметь головную боль.
Автосогласование
С появлением разных стандартов
Ethernet
возникла необходимость, чтобы устрой
ства могли идентифицировать конфигурацию своих соседей и согласовывать с ними
свои настройки. Например, сеть не будет работать, если на одной стороне соединения
она работает со скоростью
1 Гбит/с,
а на другой
ления и решения этой проблемы организацией
rласования
Ethernet.
- со скоростью 10 Гбит/с. Для выяв
IEEE был разработан стандарт автосо
В одних случаях он работает, а в других применяется неправильно
и лишь усугубляет проблему.
Следует запомнить два золотых правила автосогласования.
•
Вы обязаны использовать автосогласование всех интерфейсов, работающих на ско
рости
•
1 Гбит/с
и выше. Этого требует стандарт.
Если интерфейсы ограничены скоростями
100
Мбит/с и ниже, необходимо либо
конфигурировать оба конца соединения, либо вручную настроить скорость иду
плекс (половинный или полный) обеих сторон. Если в режиме автосогласования
настроить только одну сторону соединения, то в большинстве случаев она не смо
жет выяснить, какую конфигурацию имеет другая сторона. В результате конфигу
рация станет несогласованной и производительность упадет.
Для того чтобы выяснить, как задать стратегию автосогласования интерфейсов, про
читайте специальный раздел
13.1 О.
Часть
486
Передача электропитания по сетям
11. Работа
в сетях
Ethernet
Технология передачи питания по сетям
Ethernet (Power on Ethernet -
РоЕ) основана
на передаче электропитания по той же неэкранированной витой паре
(UTP Ethernet),
по которой передается сигнал
Ethernet.
Данная технология регламентируется стандартом
802.Заf. Это особенно удобно для систем связи, обеспечивающих передачу рече
IEEE
вого сигнала по сети Интернет (\Ьiсе
over IP -
\ЬIР), или пунктов доступа к системе
беспроводной связи (мы указали только два примера, но список можно продолжить),
в которых требуется как маломощный источник питания, так и сетевое соединение.
По мощности питания системы РоЕ разделяются на четыре класса в диапазоне
от
3,84 до 25,5
Вт. Промышленность, которая никогда не останавливается на достигну
том, уже работает над новым стандартом (802.ЗЬt), предусматривающим более высокую
мощность (более
Bake
60
Вт). Будет ли этого достаточно, чтобы подключить духовку
Easy-
к сетевому порту в конференц-зале? 5
Технология РоЕ порождает два обстоятельства, о которых должен знать системный
администратор.
•
Вы должны знать о существовании устройств РоЕ в вашей инфраструктуре, чтобы
правильно спланировать доступ к портам коммутаторов, поддерживающих техно
логию РоЕ. Эти порты дороже, чем порты, не поддерживающие технологию РоЕ.
Вычисляя расход электроэнергии на обслуживание коммуникационных шка
•
фов, содержащих коммутаторы РоЕ, следует учитывать мощность устройств РоЕ.
Обратите внимание на то, что вы не должны учитывать дополнительный расход
электроэнергии на охлаждение коммуникационных шкафов, поскольку большая
часть тепла, выделяемого из-за потребления мощности РоЕ, рассеивается за пре
делами шкафа (обычно по офису).
Гигантские пакеты
Технология
Ethernet стандартизована для типичного пакета размером 1 500 байт
- 1 518 байт). Это значение было выбрано давно, когда сети были
(вместе с фреймом
медленными и память для буферов была дефицитной. В настоящее время пакеты разме
ром
1 500
байт выглядят крохотными в контексте гиrабитных сетей
Ethernet.
Поскольку
с каждым пакетом связаны накладные расходы и определенное время задержки, произ
водительность сети можно повысить, если допустить более крупные размеры пакетов.
К сожалению, стандарты
IEEE для
разных типов сетей
Ethernet
запрещают использо
вание крупных пакетов по соображениям совместимости сетей. Однако, поскольку ско
рость магистрального трафика часто во много раз превышает установленный предел, не
стандартные большие пакеты
Ethernet
в современных сетях перестали быть редкостью.
Подстрекаемые нетерпеливыми потребителями, производители сетевого оборудования
негласно бойкотируют стандарт
IEEE
и обеспечивают поддержку крупных фреймов
в своей гигабитной продукции.
Для использования так называемых гигантских пакетов (jumЬo
лишь повысить максимально возможный размер пакета
MTU)
frames) необходимо
(maximal transmission uпit -
в интерфейсах сети. Повышение производительности зависит от вида трафика,
но наибольший выигрыш достигается для крупномасштабных перемещений по прото
колу ТСР (например, в файловых службах
NFSv4 или CIFS).
Ожидается, что умеренное,
но заметное повышение производительности должно составить примерно
5 Для
10%.
интересующихся этим вопросом: да, существует возможность загрузить небольшую
систему Liпux через порт сети РоЕ. Возможно, проще всего это сделать с помощью RaspЬerry
и коммутатора
Pi
РоЕ
Switch
НАТ.
Pi
Глава
14. Сетевые
487
аппаратные средства
Тем не менее следует отметить следующее.
•
Поддерживать и использовать гигантские пакеты должно все сетевое оборудова
ние в подсетях, включая коммутаторы и маршрутизаторы. Их нельзя смешивать
и подгонять.
•
Поскольку гигантские пакеты являются нестандартными, обычно их необходи
мо разрешать явным образом. Устройства могут принимать гигантские пакеты
по умолчанию, но, вероятнее всего, они не будут их генерировать.
•
Поскольку гигантские пакеты представляют собой незаконное явление, не суше
ствует соглашения, насколько большими они могут или должны быть. Типичной
величиной является
9000 байт
или
9018
вместе с фреймом. Необходимо проверить,
какой максимальный размер пакета может принять ваше устройство. Пакеты раз
мером больше
9
Кбайт иногда называют сверхгигантскими, но это экзотическое
название вас пугать не должно. Чем больше размер, тем лучше, по крайней мере
в диапазоне до
64
Кбайт.
Мы одобряем использование гигантских пакетов в гигабитных сетях Etheгnet, но
будьте готовы к дополнительной отладке, если что-то пойдет не так, как надо. Лучше
всего развернуть новую сеть, задав максимально возможный размер пакета по умолча
нию, а позднее, когда надежность сети будет проверена, изменить эти настройки и раз
решить гигантские пакеты.
14.2.
БЕСПРОВОДНЫЕ СЕТИ: ЛОКАЛЬНАЯ СЕТЬ ДЛЯ КОЧЕВНИКОВ
Беспроводные сети состоят из беспроводных точек доступа (Wiгeless
WAP)
и клиентов беспроводной сети. Точки
WAP
Access Points -
могут соединяться традиционными
проводными сетями (обычная конфигурация) или с другими точками
WAP без
исполь
зования проводов (конфигурация известна под названием "беспроводная сеть").
Стандарты беспроводных сетей
Распространенными стандартами беспроводных сетей в настоящее время являются
IEEE 802.1 lg, 802. l ln
и
.802.1 lac
Стандарт
802.1 lg
работает на частоте
чивает доступ к локальной сети со скоростью, достигающей
одной точки доступа колеблется от
100
м до
40
54
2,4
ГГц и обеспе
Мбит/с. Радиус действия
км, в зависимости от оборудования и фи
зических особенностей местности.
Стандарт
802. l l n обеспечивает скорость до 600 Мбит/с 6 и может использовать частоты
2,4 ГГц (при этом рекомендуется использовать диапазон 5 ГГц). Радиус
действия точки доступа в стандарте 1ЕЕЕ 802. l l n в два раза больше, чем в стандарте
IEEE 802. l lg. Преемником стандарта IEEE 802. l ln является стандарт IEEE 802. l lac, под
держивающий производительность многостанционной сети на уровне до l IОит/с.
Все эти стандарты обозначаются одним общим термином Wi-Fi. Формально говоря,
метка Wi-Fi ограничена семейством стандартов IEEE 802.11. Однако это лишь один из
многих видов аппаратного обеспечения Ethemet, доступных на рынке, поэтому все бес
проводные сети Ethemet называются Wi- Fi.
как
5
ГГц, так и
•скорость
600
802.1 ln является, скорее, теоретической. На практике полоса
WAP при оптимальной конфигурации может обеспечить
не более 400 Мбит/с. Это объясняется разJiичием между теоретическ11ми
Мбит/с в стандарте
пропускания в окрестности точки
скорость передачи данных
и практическими возможностями оборудования и среды. В беспроводных сетях всякое бывает!
488
Часть
В настоящее время стандарты
802. l lg
и
802.11 n
11.
Работа в сетях
стали общепринятыми. Трансиверы
недороги и встроены в большинство ноутбуков. Кроме тоrо, платы расширения также
стоят недорого и доступны для любых персональных компьютеров.
Доступ клиентов к беспроводной сети
Вы можете настроить системы
UNIX
или
Linux
для подключения к беспроводной
сети в качестве клиента, если у вас есть правильное оборудование и драйвер. Поскольку
большинство беспроводных плат на базе персональных компьютеров все еще предна
значены для системы
ми
FreeBSD
или
MicrosoftWindows,
Linux.
они моrут не поставляться с завода с драйвера
При попытке добавить беспроводное подключение к системе
FreeBSD
или
Linux
вам, скорее всего, понадобятся следующие команды:
• ifconfig -
для конфигурирования интерфейса беспроводной сети;
для получения списка доступных точек доступа к беспроводной сети;
• iwlist -
• iwconfig -
для настройки параметров беспроводного соединения;
• wpa_supplicant сети
для аутентификации в беспроводной сети (или проводной
802.lx).
К сожалению, гонка продаж дешевого оборудования часто означает, что для на
стройки правильной работы беспроводного адаптера в системе
UN IX
или
Linux
мо
жет потребоваться много часов проб и ошибок. Планируйте все заранее или выясните
в Интернете, какой адаптер лучше всеrо подходит для вашей операционной системы.
Беспроводные коммутаторы и точки беспроводного доступа
Все хотят иметь доступ к беспроводной сети в любом месте, и для обеспечения этой
услуги доступно множество продуктов. Но, как и во многих других областях, вы получа
ете то, за 'ITO платите. Недорогие устройства часто удовлетворяют потребности домаш
них пользователей, но не моrут хорошо масштабироваться в корпоративной среде.
Топология беспроводных сетей
Точки беспроводного доступа
(Wireless Access Point - WAP)
обычно представляют
собой специализированные устройства, состоящие из одной или нескольких радиостан
ций и некоторой формы встроенной сетевой операционной системы, часто урезанной
версии
Linux.
Одна то'lка
WAP
может обеспечить подключение нескольких клиентов,
но их число ограничено. Хорошее эмпирическое правило состоит в том, чтобы одновре
менно обслуживать не более сорока клиентов с помощью одной корпоративной ТО'IКИ
WAP.
В качестве клиента может действовать любое устройство, которое обменивается
данными по беспроводному стандарту, поддерживаемому вашими точками
Точки
WAP
WAP.
имеют один или несколько "служебных идентификаторов сети", а также
идентификатор
SSID,
который служит именем беспроводной локальной сети и должен
быть уникальным в определенной окрестности. Коrда клиент хочет подключиться к бес
проводной локальной сети, он выясняет, какие идентификаторы
SSID доступны,
и вы
бирает одну из этих сетей.
Вы можете сделать имя своего идентификатора
нающимся, например
Third Floor
SSID
осмысленным и легко запоми
PuЫic (Третий этаж, открытый доступ), или изо
брести что-нибудь необычное. Некоторые из наших любимых имен
SSID:
Глава
•
14. сетевые
FВI
аппаратные средства
Surveillance Van
• The Promised LAN
• IP Freely
• Get Off
Му
(Служба наблюдения ФБР);
(Обещанная локальная сеть);
(Свободный
LAN
IP);
(Убирайся из моей локальной сети);
• Virus Distribution Center
• Access Denied
489
(Центр распространения вирусов);
(Доступ запрещен).
Нет ничего лучше, чем изобретательные чудаки ... В простейших сценариях точка
объявляет единственный
SSID,
ваш клиент подключается к этому
SSID
и всё
-
WAP
вы в сети!
Тем не менее несколько аспектов беспроводной сети действительно просты. Что де
лать, если ваш дом или здание слишком большие, чтобы обслуживаться одной точкой
WAP?
Или что если вам нужно предоставлять разные сети различным группам пользова
телей (например, сотрудникам или гостям)? Для этих случаев вам необходимо стратеги
чески структурировать свою беспроводную сеть.
Вы можете использовать несколько
SSID
для разбивки групп пользователей или
функций. Как правило, вы сопоставляете их с отдельными виртуальными локальны
ми сетями, которые затем можно маршрутизировать или фильтровать по желанию, как
и проводные сети.
Частотный спектр, выделенный для беспроводной сети
лосы, обычно называемые каналами. Точка
радиоканал для объявления
SSID.
WAP
802.11,
разбивается на по
самостоятельно выбирает свободный
Клиенты и точка
WAP
используют этот канал для свя
зи, формируя единый широковещательный домен. Ближайшие точки
WAP,
скорее всего,
будут выбирать другие каналы, чтобы максимизировать доступную полосу пропускания
и минимизировать помехи.
Теория состоит в том, что по мере того, как клиенты перемещаются по окружаю
щей среде, они будут отделяться от одной точки
бым, и соединяться с ближней точкой
WAP
WAP,
когда ее сигнал становится сла
с более сильным сигналом. Однако теория
и реальность часто не согласуются друг с другом. Многие клиенты поддерживают связь
с точкой
WAP,
излучающей слабый сигнал, и игнорируют лучшие варианты.
В большинстве ситуаций вы должны разрешить
WAP
автоматически выбирать свои
предпочтительные каналь1. Если вы должны вручную вмешаться в этот процесс, ис
пользуя стандарты
802.11 b/g/n,
рассмотрите выбор между каналами
1, 6
или
11.
Спектр,
выделенный этим каналам, не перекрывается, поэтому комбинации этих каналов обе
спечивают наибольшую вероятность широкого распространения
водную магистраль. Каналы по умолчанию для
802. l la/ac
-
открытую беспро
не перекрываются вообще,
поэтому просто выберите свой любимый номер.
Некоторые точки
WAP
имеют несколько антенн и используют технологию множе
ственного ввода и множественного вывода
(multiple-input, multiple-output - MIMO).
Эта практика может увеличить доступную полосу пропускания, используя несколько
передатчиков и приемников, чтобы использовать преимущества смещения сигнала в ре
зультате задержки распространения. В некоторых ситуациях эта технология может обе
спечить небольшое улучшение производительности, хотя, вероятно, не такое значитель
ное улучшение, как широкая сеть антенн.
Если вам нужна физически большая зона покрытия, разверните несколько точек
WAP.
Если область полностью открыта, вы можете развернуть их в структуре решет
ки. Если существуют физические препятствия вроде стен, проведите исследование
для определения наилучших вариантов размещения точек
атрибутов вашего пространства.
WAP
с учетом физических
Часть
490
11. Работа в
сетях
Дешевая беспроводная связь
Ublquiti (ubnt. com) д11я недорогих, высокопроизводительных
Google Wifi - :Jамечательное облачное решение, если вы поддерживаете
Нам нравятся продукты
домашних сетей.
связь с удаленными членами семьи. Другим вариантом является запуск урезанной версии
Linux
(например,
org д11я
OpenWn
или
LEDE)
на коммерческой точке
WAP
(см. сайт
Openwrt.
получения дополнительной информации и списка совместимого оборудования).
Буквально десятки продавцон сейчас поставляют оборудование д11я точек беспро
водного доступа. Вы можете купить их в
продуктовом магазине.
Дешевые точки доступа (в диапазоне
Home Depot и даже в
30 долл.), вероятно, будут
плохо работать при об
работке больших файлов или наличии нескольких активных клиентов.
Дорогая беспроводная связь
Большая беспроводная связь означает большие деньги. Предоставление надежной бес
проводной сети высокой плотности (в крупных больницах, спортивных учреждениях, шко
лах, городах) представляет собой сложную задачу, связанную с ограничениями физических
установок, плотностью поль:зователей и законами физики. В таких ситуациях вам нужны
беспроводные устройства корпоративного класса, которые знают местоположение и состоя
ние каждой точки
WAP и активно настраивают каналы WAP, силу сигналов и группы
клиен
тов, чтобы обеспечить наилучшие результаты. Эти системы обычно поддерживают прозрач
ный роуминг, который позволяет группе клиентов с определенной виртуальной локальной
WAP.
Aerohive
сетью и сессией беспрепятственно перемещаться между точками
Наши любимые крупные беспроводные платформы
няя принадлежит компании
Cisco).
-
это
и
Meraki
(послед
Эти платформы следующего поколения управляют
ся из облака, что позволяет вам пить мартини на пляже, контролируя свою сеть через
браузер. Вы даже можете выбросить отдельных пользователей из беспроводной сети,
не вставая с шезлонга. Уйди, противный!
Если вы развертываете беспроводную сеть в больших масштабах, вам, вероятно, при
дется приобрести анализатор беспроводной сети. Мы настоятельно рекомендуем анали
тические продукты, разработанные компанией
AirMagnet.
Безопасность беспроводных сетей
Традиционно безопасность беспроводных сетей очень низкая. Существует протокол
WEP (Wired Equivalent Privacy),
применяемый в сетях
802. l lb
и д11я шифрования паке
тов, передаваемых с помощью радиоволн. К сожалению, в современной версии стандар
та была обнаружена фатальная проектная недоработка, которая делает его практически
бесполезным. Посторонний человек, находящийся за пределами здания, может полу
чить прямой доступ к сети и остаться незамеченным.
Тем не менее недавно появившиеся стандарты
Wi-Fi Protected Access (WPA)
возроди
ли доверие к безопасности беспроводных сетей. В настоящее время во всех новых ин
WPA (в частности, стандарт WPA2), а не
WPA2 беспроводные сети должны считаться полностью
сталляциях должны использоваться стандарты
WEP.
Без применения стандарта
незащищенными и не должны использоваться за пределами предприятия. Даже дома
не используйте стандарт
WEP!
Для того чтобы запомнить, что стандарт
WPA -
WEP
является незащищенным, а стандарт
безопасным, просто расшифруйте аббревиатуру
WAP (Wired Equivalent Privacy -
конфиденциальность на уровне проводных сетей). Это название точно отражает суть
дела; протокол
WEP
обеспечивает такую защиту, как проводная сеть, допускающая
Глава
14. Сетевые аппаратные
средства
491
непосредственное подключение посторонних лиц. (Иначе говоря, никакой защиты
по крайне мере на уровне
14.3. SDN:
-
IP.)
ПРОГРАММНО-КОММУТИРУЕМЫЕ СЕТИ
Как и при виртуализации серверов, разделение физического сетевого оборудования
с функциональной архитектурой сети может значительно повысить гибкость и управля
емость. Лучшим средством для достижения этих целей являются программно-коммути
руемые сети
(software-defined networking - SDN).
SDN заключается в том, что компоненты,
Основная идея
управляющие сетью (пло
скость управления), физически отделены от компонентов, которые пересылают пакеты
(плоскость данных). Плоскость данных программируется через плоскость управления,
поэтому вы можете настраивать или динамически изменять маршруты передачи данных
для достижения целей производительности, безопасности и доступности.
Как и многое в нашей отрасли,
SDN для
корпоративных сетей превратилась в марке
тинговый трюк. Первоначальная цель состояла в том, чтобы стандартизировать незави
симые от поставщика способы перенастройки сетевых компонентов. Несмотря на то что
некоторые из этих планов были реализованы, многие поставщики теперь предлагают
собственные продукты
SDN
для предприятий, которые в какой-то мере степени проти
воречат первоначальной цели
SDN.
Если вы изучаете пространство предприятия
SDN,
выбирайте продукты, соответствующие открытым стандартам и совместимые с продук
тами других поставщиков.
Для крупных поставщиков облачных вычислений
SDN
добавляет уровень гибкости,
который уменьшает вашу потребность знать (или заботиться) о том, где определенный
ресурс находится физически. Хотя эти решения могут быть коммерческими, они тесно
интегрированы в платформы облачных провайдеров и могут упростить настройку вашей
виртуальной инфраструктуры.
Сеть
SDN
и ее система управления, основанная на интерфейсах
API,
предлагают
системным администраторам соблазнительную возможность интегрировать управление
топологией сети с другими инструментами стиля
DevOps для
непрерывной интеграции
и развертывания. Возможно, в каком-то идеальном мире у вас всегда есть производ
ственная среда, поставленная и готовая к активации одним щелчком мыши. По мере
того как новая среда продвигается к производству, сетевая инфраструктура магическим
образом преобразуется, устраняя простои, заметные для пользователя, и необходимость
планировать окна обслуживания.
14.4. ТЕСТИРОВАНИЕ
Ключ к отладке сети
-
И ОТЛАДКА СЕТЕЙ
ее разбивка на сегменты и тестирование каждого из них до тех
пор, пока не будет обнаружена неисправность. Загадочные лампочки на коммутаторах
и концентраторах (обозначающие, к примеру, состояние канала и наличие трафика паке
тов) помогают быстро выявить источник проблемы. Для того чтобы эти индикаторы рабо
тали так, как вы хотите, следует руководствоваться первоклассной документацией.
Как всегда, важно иметь под рукой нужные инструменты, чтобы выполнить работу
правильно и без проволочек. На рынке предлагаются средства сетевой отладки двух ти
пов (правда, наблюдается тенденция к их объединению).
Устройство первого типа
-
ручной кабельный тестер. Он измеряет электрические
характеристики кабеля, включая его длину (для этого применяется особая технология,
Часть
492
11.
Работа в сетях
называемая рефлектометрией во временной области). Такие устройства способны выяв
лять простейшие проблемы, например разрыв или неправильную разводку кабеля.
Нашим любимым инструментом тестирования локальных сетей является устройство
Fluke LanMeter. Это универсальный анализатор, способный даже посылать эхо-пакеты
протокола ICMP. Профессиональные варианты этого оборудования описаны на специ
альном веб-сайте. Для телекоммуникационных сетей WAN лучше всего подходит тестер
T-BERD, выпускаемый компанией Viavi (viavisolutions. com).
Средства отладки второго типа - это анализаторы сетевых пакетов. Они просмат
ривают сетевые пакеты на предмет наличия ошибок протоколов, неправильной кон
фигурации и прочего беспорядка. Эти анализаторы работают на уровне каналов, а не
на электрическом уровне, поэтому они не могут распознавать проблемы, связанные
с физическими повреждениями кабелей или электропитанием.
Существуют профессиональные анализаторы сетевых пакетов, но мы нашли свободно
распространяемую программу
Wireshark 7 (wireshark. org),
которая может выполнять
ся на полнофункциональном ноутбуке. Именно ее можно считать наилучшим выбором.
Более подробная информация об анализаторах сетевых пакетов приведена в разделе
14.5.
13.12.
ПРОКЛАДКА КАБЕЛЕЙ
Если вы занялись прокладкой кабелей в здании, то самый ценный совет, который мы
можем вам дать, звучит так: "Делайте все правильно с первого раза". Это не та область,
в которой можно скупиться или халтурить. Покупая качественные материалы, выби
рая компетентного подрядчика для прокладки кабелей и устанавливая дополнительные
разъемы (отводы), вы тем самым избежите многолетних мучений.
Неэкранированная витая пара
Кабель категории ба имеет наилучшее соотношение цены и производительности на со
временном рынке. Его стандартный вариант
-
четыре пары проводов под одной оболоч
кой, что подходит для большинства соединений, включая
RS-232
и гиrабитные линии.
Спецификации кабеля категории ба требуют, чтобы скрутка провода заканчивалась
в точке контакта. Для того чтобы обеспечить это требование, необходимы специальное
обучение и оконечное оборудование. При этом необходимо использовать настенные ро
зетки и коммутационные панели категории ба. Самые хорошие отзывы заслужила про
дукция компании
Siemon.
Офисные точки подключения
Многие годы идут споры, сколько точек подключения требуется для офиса. Одной
точки подключения на офис явно недостаточно. Сколько же нужно
-
две или четыре'?
Мы рекомендуем четыре, обосновывая это следующими причинами.
•
Их можно использовать просто для подключения телефонов и других специализи
рованных устройств.
•
Большинство пользователей предпочитают подключаться с помощью беспровод
ных сетей, а не проводов.
•
7 Как
Гораздо дешевле проложить весь кабель сразу, чем делать это поэтапно.
и многие популярные программы, программа
Wireshark
Убедитесь, что вы используете самую последнюю ее версию.
часто подвергается атакам хакеров.
Глава
•
14. Сетевые
493
аппаратные средства
Средства, выделенные на приобретение проводов, лучше потратить на основную
инфраструктуру, а не на оборудование отдельных офисов.
При прокладке кабеля в здании можно установить дополнительные розетки в кори
дорах, конференц-залах, столовых, туалетных комнатах и на потолках (для точек бес
проводного доступа). Однако не забывайте о безопасности и размещайте открыто предо
ставляемые порты на "гостевой" виртуальной локальной сети, не допуская посторонних
к своим внутренним сетевым ресурсам. Публикуя защищенные публичные порты, ис
пользуйте стандарт аутентификации
802.1 х.
Стандарты кабельных систем
Необходимость обеспечения всех видов деятельности внутри современных зданий
обусловливает потребность в крупной и сложной кабельной инфраструктуре. Заглянув
в обычный коммутационный шкаф, вы будете потрясены, увидев его стенки, сплошь
покрытые непомеченными проводами одного цвета.
С целью улучшения оперативного контроля и стандартизации кабельных систем зда
ний в феврале
1993
г. организация ТIА опубликовала административный стандарт на те
лекоммуникационную инфраструктуру коммерческих зданий (ТIA/EIA-606). В
2012
г.
появилась его обновленная версия ТIA/EIA-606- В.
Этот стандарт устанавливает требования и принципы идентификации и документирования телекоммуникационной инфраструктуры. Он касается следующих аспектов:
•
•
•
•
•
•
оконечной аппаратуры;
кабелей;
прокладки кабелей;
расстояний между элементами оборудования;
В частности, определены стандартные цвета маркировки проводов (табл.
14.5).
Таблица 14.5. Таблица цветовой маркировки по стандарту TIA/EIA-606
Тип оконечного устройства
Цвет
Код•
Комментарии
Граничное
Оранжевый
150С
Центральная телефонная станция
Сетевые соединения
Зеленый
35ЗС
Также применяется для вспомогательных
Общее оборудование 6
Фиолетовый
264С
Магистраль первого уровня
Белый
Магистраль второго уровня
Серый
422С
Кабели
Станция
Синий
291С
Горизонтальные кабели
Магистраль между зданиями
Коричневый
465С
Кампусные кабели
Разное
Желтый
101С
Служебные и сигнальные линии
Ключевые телефонные системы
Красный
184С
электросетей
Основное оборудование коммутации
и передачи данных
'В соответствии с цветовой моделью
6 0фисные
Кабели
Pantone.
АТС, компьютеры, локальные сети, мультиплексоры и т.д.
494
Часть
14.6.
11.
Работа в сетях
ПРОЕКТИРОВАНИЕ СЕТЕЙ
В этом разделе рассматриваются вопросы, связанные с логическим и физическим
проектированием сетей среднего размера. Представленные здесь идеи подходят для не
скольких сотен хостов, но неприменимы ни для трех, ни для нескольких тысяч компью
теров, включенных в одну сеть. Также предполагается, что работа будет начата с нуля.
Основной объем работ по проектированию сети состоит из определения:
•
•
•
типов сред передачи;
топологии и способов прокладки кабелей;
системы концентраторов, коммутаторов и маршрутизаторов.
Еще один ключевой вопрос проектирования сети связан с управлением перегрузкой.
Например, файловые протоколы
NFS
и
SMB
очень сильно загружают сеть, поэтому та
кие файловые системы нежелательно подключать по магистральному кабелю.
Ниже анализируются аспекты, которые необходимо учитывать при проектировании
сети.
Структура сети и архитектура здания
Структуру сети проще изменить, чем архитектуру здания, но обе они должны нор
мально сосуществовать. Если вам крупно повезло, т.е. представилась возможность про
ектировать сеть до постройки здания, будьте щедрым. К сожалению, в большинстве слу
чаев здание и отдел технического обслуживания компании на момент проектирования
сети уже существуют и налагают жесткие ограничения на структуру сети.
В уже построенных зданиях сеть должна адаптироваться к архитектуре, а не проти
востоять ей. В современных зданиях, помимо высоковольтной электропроводки, водо
и газопроводов, иногда имеются каналы для прокладки кабелей. Часто монтируются
подвесные потолки
-
настоящий подарок для тех, кто прокладывает сеть. Во многих
университетских городках существуют туннели, которые облегчают создание сетей.
Необходимо следить за целостностью брандмауэров. 8 При прокладке кабеля через
брандмауэр отверстие должно соответствовать диаметру кабеля и заполняться негорю
чим веществом. Выбирая кабель, учитывайте наличие приточной вентиляции. Если уз
нают, что вы нарушили правила пожарной безопасности, вас могут оштрафовать и за
ставить устранить недостатки, даже если для этого придется проложить заново всю сеть.
Логическая структура сети должна соответствовать физическим ограничениям зда
ний, в которых она будет функционировать. Приступая к проектированию, помните,
что можно найти логически красивое решение, а затем вдруг обнаружить, что реализо
вать его физически сложно или вообще невозможно.
Расширение сетей
Прогнозировать потребности на десять лет вперед очень сложно, особенно в области
вычислительной техники и сетей. Поэтому, проектируя сеть, всегда следует учитывать
перспективы ее расширения и увеличения пропускной способности. Прокладывая ка
бель, особенно в труднодоступных местах, протягивайте в три-четыре раза больше пар,
'Речь идет о брандмауэрах в виде бетонных, кирпичных или огнеупорных стен, которые
препятствуют распространению огня по всему зданию. Значительно отличаясь от сетевых
брандмауэров, они не менее важны.
Глава
14. Сетевые
аппаратные средства
495
чем нужно. Помните: основная часть стоимости прокладки сети приходится на оплату
труда, а не на материалы.
Даже если волоконно-оптические линии не планируется использовать немедленно,
разумно будет все же проложить немного оптического волокна, особенно если известно,
что впоследствии протянуть его будет гораздо труднее. Прокладывайте и многомодовый,
и одномодовый кабели. Как правило, нужным оказывается как раз тот кабель, который
не проложен.
Перегрузка
Сеть
-
как цепь: ее качество определяется самым слабым или самым медленным
звеном. Производительность
Ethernet,
как и многих других сетевых технологий, при уве
личении нагрузки падает.
Активно эксплуатируемые коммутаторы, нестыкующиеся интерфейсы, низкоско
ростные каналы связи
-
все это может привести к перегрузке. Эффективный способ
борьбы с ней заключается в локализации трафика путем создания подсетей и установ
ки маршрутизаторов. Подсети можно использовать и для изоляции компьютеров, за
действованных в отдельных экспериментах. Трудно проводить эксперимент на несколь
ких компьютерах, если нет надежного способа изолировать их физически и логически
от остальной части сети.
Обслуживание и документирование
Опыт показывает, что удобство обслуживания сети напрямую зависит от качества до
кументации на нее. Точная, полная, своевременно корректируемая документация абсо
лютно необходима.
Кабели следует маркировать во всех точках подключения. Рекомендуем вкладывать
копии местных монтажных схем в коммутационные шкафы, чтобы при всех изменениях
эти экземпляры можно было скорректировать на месте. Каждые несколько недель не
обходимо переносить все корректировки в электронную базу данных.
Стыки между крупными системами в виде коммутаторов или маршрутизаторов могут
упростить отладку, поскольку позволяют изолировать части сети и отлаживать их по от
дельности. Полезно также разграничивать административные области.
14.7. УПРАВЛЕНИЕ СЕТЬЮ
Если необходимо обеспечить нормальную работу сети, одни функции управления
следует централизовать, другие
-
распределить, а третьи
-
оставить на локальном уров
не. Требуется сформулировать и согласовать обоснованные "правила поведения добро
порядочных граждан".
Типичная крупномасштабная среда включает в себя:
•
•
•
•
магистральную сеть, соединяющую здания;
сети подразделений, подключенные к магистрали;
подсети рабочих групп в рамках подразделения;
соединения с внешним миром (например, с Интернетом или периферийными фи
лиалами).
496
Часть
11. Работа
в сетях
При проектировании и реализации сетей следует предусматривать централизованные
контроль, ответственность, сопровождение и финансирование. Поскольку подразделе
ния, как правило, стремятся свести к минимуму собственные расходы, быстро растет
число сетей с централизованной оплатой каждого соединения. Вот основные объекты
централизованного управления:
•
структура сети, в том числе принципы использования подсетей, маршрутизаторов,
коммутаторов и т.д.;
•
•
•
•
магистральный кабель, в том числе подключения к нему;
IР-адреса и имена компьютеров, доменные имена;
используемые протоколы (требуется обеспечить их взаимодействие);
правила доступа в Интернет.
Имена доменов, IР-адреса и сетевые имена компьютеров в определенном смысле уже
находятся под централизованным контролем таких организаций, как
Registry for lnternet Numbers)
и
ICANN,
ARIN (American
но координация использования этих элементов
на локальном уровне также необходима.
Центральный орган управления имеет общее представление о сети, ее структуре,
производительности и перспективах роста. Он может позволить себе иметь собственное
контрольное оборудование (и обслуживающий его персонал) и следить за нормальной
работой магистральной сети. Центральный орган может настоять на правильном выборе
структуры сети, даже если для этого придется заставить подразделение купить марш
рутизатор и создать подсеть для подключения к магистрали. Такое решение иногда не
обходимо для того, чтобы новое соединение не навредило работе существующей сети.
Если в сети работают разнородные компьютеры, операционные системы и протоко
лы, обязательно нужно иметь "высокоинтеллектуальный" маршрутизатор (например,
компании
14.8.
Cisco),
который будет служить шлюзом между сетями.
РЕКОМЕНДУЕМЫЕ ПОСТАВЩИКИ
Занимаясь более
30
лет инсталляцией сетей по всему миру, мы не раз обжигались
на продуктах, которые не соответствовали спецификациям, имели завышенную цену,
неправильно указанные характеристики или как-то иначе не оправдывали ожидания.
Ниже приведен список поставщиков, которым мы доверяем и услугами которых реко
мендуем пользоваться.
Кабели и разъемные соединения
АМР
(подразделение Тусо)
Маршрутизаторы/коммутаторы
Cisco Systems
(415) 326-1941
www.cisco.com
Juniper Network
(408) 745-2000
juniper.com
14.9. ЛИТЕРАТУРА
•
Commercial Building Telecommunications CaЬling Standard
Administration Standard for the Telecommunications lnfrastrncture
о/ Commercial Buildings. Это стандарты телекоммуникационной промышленно
ANSI/ТIA/EIA-568-A.
и ANSl(ГIA/EIA-606,
сти для построения кабельных систем зданий. К сожалению, они не бесплатны.
Посетите веб-сайт
www. tiaonline. org.
BдRNETT Dлvю, GRотн Dлvю дND J1м МсВЕЕ. CaЬling:
The Complete Guide to Network
edition). San Francisco: Sybex, 2004.
• GoRANssoN, PдuL, дND Снuск ВLлск. Software Defined Networks, А Comprehensive
Approach (2nd Edition). Burlington, МА: Morgan Kaufman, 2016.
• SruRGEON, CндRLES, дND JoдNN Z1мMERMAN. Ethernet: The Definitive Guide: Designing
and Managing Local Area Networks (2nd Edition). Sebastopol, СА: O'Reilly, 2014.
•
Wiring
(Зrd
Глава
15
IР-маршрутизация
4,3 миллиарда IР-адресов, поэтому получение пакетов
- непростая задача. 1 Маршрутизация IР-пакетов уже была
13. В этой главе мы рассмотрим процесс маршрутизации
Во всем мире доступны более
в нужном месте в Интернете
кратко представлена в главе
более подробно и исследуем несколько сетевых протоколов, которые позволяют марш
рутизаторам автоматически обнаруживать эффективные маршруты. Протоколы маршру
тизации не только уменьшают административную нагрузку, связанную с обработкой ин
формации о маршрутизации, но также позволяют быстро перенаправить сетевой трафик,
если маршрутизатор, соединение или сеть не вышли из строя.
Важно отличать реальное перенаправление IР-пакетов от управления таблицей
маршрутизации, хотя в обоих случаях употребляют один и тот же термин
зация. Перенаправление пакетов
-
-
маршрути
простая процедура, тогда как вычисление маршрутов
происходит по довольно запутанному алгоритму. Мы познакомимся только с одноадрес
ной маршрутизацией, так как при многоадресной (когда пакеты направляются группе
подписчиков) возникает ряд новых проблем, рассмотреть которые, учитывая объем кни
ги, не представляется возможным.
Для того чтобы составить правильное представление о маршрутизации, в большин
стве случаев достаточно информации, изложенной в главе
13.
Если сетевая инфра
структура уже налажена, можно просто задать единственный статический маршрут (как
описано в разделе "Маршрутизация") и все готово
-
у вас есть информация обо всем
Интернете. Если же вы стремитесь справиться с сетью, имеющей сложную топологию,
или используете операционные системы
'Cм.wapo.st/world-ip.
UNIX либо Linux
как часть своей сетевой ин-
500
Часть
11.
Работа в сетях
фраструктуры, тогда эта глава о протоколах и инструментах динамической маршрутиза
ции окажется полезной для вас. 2
\Р-маршрутизация (как для
1Pv4,
так и для \Рvб)
-
маршрутизация " следующего
перехода". В любой момент времени системе, обрабатывающей пакет, необходимо опре
делить только следующий хост или маршрутизатор в пути пакета до конечного пункта
назначения. Это отличается от подхода многих устаревших протоколов, которые опре
деляют точный путь, по которому пакет будет перемещаться, прежде чем покинет свой
исходный хост, схему, известную как маршрутизация от источника. 3
15.1.
ПОДРОБНЕЕ О МАРШРУТИЗАЦИИ ПАКЕТОВ
Прежде чем приступать к изучению алгоритмов маршрутизации, рассмотрим под
робнее, как используются маршрутные таблицы. Предположим , сеть имеет топологию ,
изображенную на рис.
с внешним миром. Посмотрим, как выглядят таблицы маршрутизации и некоторые кон
кретные сценарии перенаправления пакетов. Таблица хоста А выглядит следующим об
разом.
А$
netstat -rn
Destinat ion
127.0. 0 . 0
199.165.145.0
Gat e way
о .о .о .о
о. о . о . о
Genmask
255 . 0.0 . 0
255 . 25 5. 255.0
u
u
199.1 65.145.24
о.о . о . о
UG
о. о.о . о
Fl ags
MSS Window irt t I f ace
о
о
о
lo
ethO
о
о
о
о
о
о
e th O
В приведенном выше примере для запроса таблицы маршрутизации использует
ся хорошо известный инструмент
рационной системой
FreeBSD
netstat.
Этот инструмент распространяется с опе
и доступен для
Linux
как часть пакета
net-tools.
Этот
пакет больше не имеет активной поддержки и, как ре зультат, считается устаревшим.
Официально рекомендованным способом получить эту информацию в
менее функциональная команда
2 Мы
Linux
является
ip route:
не рекомендуем использовать системы UNIX или Linux в качестве сетевых маршрутизаторов
в производственной инфраструктуре
' 1Р-пакеты
-
лучше купите выделенный маршрутизатор .
также могут маршрутизироваться на основе адреса отправителя
- по крайней
мере теоретически , но это почти никогда н е выполняется. Эта функция не получила широкого
распространения из соображений безопасности .
Глава
15. IР-маршрvтизация
501
ip route
default via 199.165.145.24 dev ethO onlink
199.165.145.0/24 dev ethO proto kernel scope link src 199.165.145.17
А$
Результат работы команды
netstat -rn
немного легче читать, поэтому мы исполь
зуем его для последующих примеров и исследования рис.
15.1.
Хост А имеет самую простую конфигурацию среди всех четырех компьютеров.
Первые два маршрута описывают собственные сетевые интерфейсы хоста. Они необхо
димы, чтобы пакеты, направляемые непосредственно в подключенные сети, не марш
рутизировались особым образом. Устройство
а
lo -
ethO -
это Еthеrnеt-интерфейс хоста А,
интерфейс обратной связи (виртуальный сетевой интерфейс, эмулируемый про
граммным обеспечением). Обычно такие записи автоматически добавляются при кон
фигурировании сетевого интерфейса.
W См. обсуждение сетевых масок в разделе 13.4.
Стандартный маршрут хоста А задает перенаправление всех пакетов, не адресован
195.165.145,
ных интерфейсу обратной связи или сети
рого в данной сети
- 199.165.145.24.
на маршрутизатор
RI,
адрес кото
Шлюзы должны находиться на расстоянии одного
перехода.
m
Дополнительную информацию об адресах см. в разделе
13.3.
Предположим теперь, что хост А посылает пакет хосту В с адресом 199.165.146.4.
199.165.146 и, не найдя такового, отправляет пакет
IР-подсистема ищет маршрут к сети
по стандартному маршруту, т.е. маршрутизатору
пакета, проходящего по сети
Ethemet
ветствующих интерфейсов компьютеров А и
Заголовок
Ethernet
Заrоловок
От:
От: А
Кому:
Rl
Кому:
Тип:
IP
Тип:
R 1. На рис. 15.2 приведена структура
Ethernet указаны МАС-адреса соот
сети 145).
(в заголовке
RI
в
Заголовок UDP и данные
IP
199.165.145.17
199.165.146.4
о
UDP
ПАКЕТUDР
ПАКЕТIР
ФРЕЙМ ЕТНЕRNЕТ
Рис.
15.2.
Ethernet-naкem
Аппаратный Ethernet-aдpec получателя соответствует маршрутизатору
R 1,
но
1Р
пакет, скрытый в Ethemet-фpeймe, не содержит никаких упоминаний о маршрутизато
ре. Когда маршрутизатор просматривает поступивший пакет, он обнаруживает, что не
является его получателем. Тогда он обращается к собственной таблице маршрутизации,
чтобы узнать, как переслать пакет хосту В, не переписывая его IР-заголовок (необходи
мо, чтобы отправителем пакета оставался хост А).
Таблица маршрутизации устройства
Window irtt Iface
lo
о
о
ethO
о
о
ethl
о
о
ethl
о
о
Часть
502
11. Работа
в сетях
Она почти аналогична таблице хоста А. за исключением того, что здесь присуrству
ет два физических сетевых интерфейса. Стандартный маршрут в данном случае ведет
к устройству
поскольку через него осуществляется выход в Интернет. Пакеты, адре
R2,
сованные любой из сетей
199.165, доставляются
напрямую.
Подобно хосту А, хост В имеет один реальный сетевой интерфейс. Но для корректного
функционирования ему необходим дополнительный маршруr, поскольку хост имеет пря
мое соединение сразу с двумя маршруrизаторами. Трафик сети
ходить через устройство
Window irtt Iface
о
о
lo
о
о
ethO
ethO
о
о
о
о
ethO
о
о
о
о
lll Описание переадресации ICMP см. в разделе 13.5.
Теоретически, как и хост А, хост В можно сконфигурировать так, чтобы изначально
он "знал" только об одном шлюзе, полагаясь на помощь директив переадресации про
токола
ICMP для
устранения избыточных переходов. Ниже показан пример начальной
конфигурации.
В$ netstat -rn
Destination
Gateway
Genmask
127.0.0.О
О.О.О.О
255.О.О.О
199.165.146.0
О.О.О.О
255.255.255.0
О.О.О.О
199.165.146.3
О.О.О.О
Теперь, если хост В посылает пакет хосту А
ден не будет, и пакет отправится на устройство
Flags
U
U
UG
MSS Window irtt Iface
О
О
О
lo
О
О
О
ethO
О
О
О
ethO
(199.165.145.17), прямой маршруr най
R2. Поскольку устройство R2 является
маршруrизатором, оно имеет полную информацию о состоянии сети и. следовательно,
"знает" о роли устройства
обнаружит, что хосты
Rl
Rl,
куда и будет послан пакет. Кроме того, маршруrизатор
R2
и В находятся в одной сети, поэтому он дополнительно напра
вит хосту В IСМР-сообщение, в соответствии с которым хост В добавит в свою таблицу
маршруrизации прямой маршруr к хосту А.
199.165.145.17 199.165.146.1 255.255.255.255 UGHD
о
о
о
ethO
Благодаря этому маршруту весь трафик, адресованный хосту А, начнет идти непо
средственно через маршруrизатор
к другим хостам в сети
тизатора
145.
Rl.
Однако это изменение не затрагивает трафик
Для них нужно получить отдельные директивы от маршру
R2.
Некоторые администраторы выбирают для своих систем директивы переадресации
протокола
ICMP
в качестве основного "протокола" маршруrизации, думая, что подоб
ный подход обеспечит большую динамичность. К сожалению, системы и маршруrиза
торы осуществляют перенаправление по-разному. Некоторые хранят эти директивы по
стоянно. Другие удаляют их из таблицы маршруrизации через относительно короткое
время
(5-15
минут). Третьи вообще игнорируют их, что, вероятно, правильно с точки
зрения безопасности.
Перенаправления имеют несколько других потенциальных недостатков: например,
увеличение нагрузки на сеть, увеличение нагрузки на
R2,
беспорядок в таблице марш
руrизации и зависимость от дополнительных серверов, поэтому мы не рекомендуем их
Глава
15. IР-маршрутизация
503
использовать. В правильно настроенной сети перенаправления никогда не должны по
являться в таблице маршрутизации.
Если вы используете адреса
1Pv6,
применяется та же модель. Вот как выглядит таб
лица маршрутизации с хоста. работающего под управлением операционной системы
FreeBSD,
на котором запущен протокол
1Pv6:
$ netstat -rn
Destination
default
Gateway
2001:88бЬ:4452::/64
link#l
: :1
link#l
feB0::/10
fe80::%re0/64
Как и в протоколе
2001:886Ь:4452::1
1Pv4,
Flags
UGS
u
UGRS
u
Netif
reO
reO
loO
reO
Expire
первый маршрут является значением по умолчанию, которое
используется, когда нет более конкретных записей. Следующая строка содержит марш -
рут к глобальной сети
1Pv6,
где находится хост,
2001: 886Ь: 44 52: : / 64.
Последние две
строки являются особенными; они представляют маршрут к зарезервированной сети
1Pv6 fe80,
известной как локальная сеть одноадресатной передачи. Эта сеть использу
ется для трафика, который привязан к локальному широковещательному домену (как
правило, к одному и тому же сегменту физической сети). Он чаще всего используется
сетевыми службами, которые должны найти друг друrа в одноадресатной сети, напри
мер
OSPF.
Не используйте подобные локальные адреса для обычных сетевых целей.
15.2. ДЕМОНЫ
И ПРОТОКОЛЫ МАРШРУТИЗАЦИИ
В простых сетях, подобно той, которая представлена на рис.
15.1,
маршрутизацию
целесообразно настраивать вручную. Однако с определенного момента сети становят
ся слишком сложными для подобного администрирования. Вместо того чтобы явно со
общать каждому компьютеру, как находить другие компьютеры и сети, лучше заставить
сами компьютеры искать эту информацию. Данная задача возлагается на протоколы
маршрутизации и демоны, которые их реализуют.
Основное преимущество протоколов маршрутизации над системами статической марш
рутизации заключается в том, что они позволяют быстро адаптироваться к изменениям
в тополоrии сети. Когда пропадает канал связи, демоны быстро находят альтернативные
маршруты, если они существуют, и сообщают о них в сети, связанные с этим каналом.
Демоны маршрутизации собирают информацию из трех источников: конфигура
ционных файлов, существующих таблиц маршрутизации и ''родственных" демонов
других систем. Собранные данные объединяются, и вычисляется оптимальный набор
маршрутов, после чего новые маршруты записываются в системную таблицу (и при не
обходимости посылаются другим системам посредством протоколов маршрутизации).
Состояние сети время от времени меняется, поэтому демоны должны периодически
опрашивать друг друга, чтобы убедиться вактуальности имеющейся у них информации.
Конкретный алгоритм вычисления маршрутов зависит от протоколов. Последние
бывают двух типов: дистанционно-векторные и топологические.
Дистанционно-векторные протоколы
В основе дистанционно-векторных протоколов лежит следующая идея: если маршрути
затор Х находится в пяти переходах от сети У и является моим соседом, то я нахожусь в ше
сти переходах от данной сети. Демон, работающий по такому протоколу, объявляет о том.
Часть
504
11.
Работа в сетях
как далеко, по его расчетам, расположены известные ему сети. Если соседние демоны не
"знают" более коротких маршрутов к этим сетям, они помечают данный компьютер как оп
тимальный шлюз. В противном случае они просто игнорируют этот анонс. Предполагается,
что со временем таблицы маршрутизации придут в стабильное состояние.
Это действительно элегантная идея, и, если бы все работало так, как задумано,
маршрутизация существенно упростилась бы. К сожалению, описанный алгоритм не
лучшим образом справляется с изменениями топологии. 4 Иногда стабилизация таблиц
вообще не наступает вследствие возникновения бесконечных циклов (например, марш
рутизатор Х получает информацию от маршрутизатора У и посылает ее маршрутизатору
Z,
который возвращает ее маршрутизатору У). На практике приходится вводить сложные
эвристические правила или задавать ограничения. К примеру, в протоколе
Information Protocol -
RIP (Routing
протокол маршрутной информации) считается, что любая сеть,
находящаяся на расстоянии более пятнадцати переходов, недоступна.
Даже в обычных ситуациях может потребоваться слишком много циклов обновле
ний, прежде чем все маршрутизаторы перейдут в стабильное состояние. Следовательно,
чтобы не превысить допустимые пределы, необходимо сделать периоды обновлений ко
роткими, а это, в свою очередь, ведет к тому, что дистанционно-векторные протоколы
оказываются слишком "словоохотливыми''. Например, протокол
RIP
требует, чтобы
маршрутизаторы осуществляли широковещательную рассылку всей имеющейся у них
информации каждые
30
с. В протоколе
EIGRP обновления анонсируются каждые 90 с.
BGP (Border Gateway Protocol - протокол
В противоположность этому в протоколе
граничного шлюза) вся таблица посылается один раз, после чего изменения распростра
няются по мере возникновения. Такая оптимизация позволяет существенно снизить
"переговорный" трафик (большей частью ненужный).
В табл.
15.1
перечислены дистанционно-векторные протоколы, широко используе
Топологические протоколы
В топологических протоколах, или протоколах состояния канала, информация
рассылается в относительно необработанном виде. Записи выглядят примерно так:
"Маршрутизатор Х является смежным по отношению к маршрутизатору У, и канал
функционирует". Полный набор таких записей образует карту сетевых связей, на ос4
Проблема заключается в том, что изменения топологии могут приводить к удлинению
существующих маршрутов. Некоторые дистанционно-векторные протоколы, например
EIGRP,
хранят информацию о всех возможных маршрутах, чтобы на крайний случай был "план
отступления". Впрочем, конкретные детали не так уж важны.
Глава
15. IР-маршрутизация
505
новании которой каждый маршрутизатор может сформировать собственную таблицу.
Основное преимущество топологических протоколов, по сравнению с дистанционно
векторными, заключается в способности быстро стабилизировать таблицы маршрути
зации в случае непредвиденного сбоя. К издержкам относится необходимость хранения
полной карты соединений на каждом хосте, для чего требуются дополнительные про
цессорные мощности и память.
Поскольку процесс общения между маршрутизаторами не ямяется частью собственно
алгоритма вычисления маршрутов, поямяется возможность реализовать топологические
протоколы так, чтобы не возникало циклов. Изменения в тополоmческой базе данных рас
пространяются по сети очень быстро, не перегружая ни канал, ни центральный процессор.
Топологические протоколы сложнее дистанционно-векторных, зато они позволяют ре
ализовать такие технологии, как маршрутизация на основании запрашиваемого типа об
служивания (поле
TOS
IР-пакета) и поддержка нескольких маршрутов к одному адресату.
Единственным топологическим протоколом, получившим широкое распростране
ние, ямяется протокол
OSPF.
Метрика стоимости
Для того чтобы протокол маршрутизации мог определить, какой путь к заданной
сети является кратчайшим, необходимо вначале выяснить, что значит "кратчайший".
Это путь с наименьшим числом переходов? С наименьшей задержкой? С наименьшими
финансовыми затратами?
Для целей маршрутизации качество канала связи определяется числом, называемым
метрикой стоимости. Путем сложения метрик отдельных отрезков пути вычисляется
общая стоимость маршрута. В простейших системах каждому каналу назначается сто
имость
1,
и в результате метрикой маршрута становится число переходов. Но любой из
перечисленных выше критериев может являться метрикой стоимости.
Эксперты в области сетей долго и упорно трудились над тем, чтобы определение
такого понятия, как метрика стоимости, было максимально гибким, а некоторые со
временные протоколы даже позволяют использовать разные метрики для разных видов
сетевого трафика. Тем не менее в
99%
случаев на все это можно не обращать внимания.
Для большинства систем вполне подойдут стандартные метрики.
Бывают ситуации, когда кратчайший физический маршрут к адресату не должен
быть выбран по умолчанию из административных соображений. В таких случаях мож
но искусственно завысить метрики критических каналов. Всю остальную работу предо
ставьте демонам.
Внутренние и внешние протоколы
Автономная система
-
это группа сетей, находящихся под административным или
политическим контролем одного юридического лица. Такое определение довольно рас
плывчато. Реальные автономные системы могут представлять собой как глобальные
корпоративные сети, так и сети университетов или даже отдельных факультетов. Все
зависит от того, как осуществляется маршрутизация. Сейчас наблюдается тенденция
к укрупнению автономных систем. Это упрощает администрирование и повышает эф
фективность маршрутизации.
Маршрутизация внутри автономной системы отличается от маршрутизации между
такими системами. Протоколы второго типа (внешние, или протоколы внешних шлю
зов) должны управлять множеством маршрутов к различным сетям и учитывать тот
506
Часть
11.
Работа в сетях
факт, что соседние маршрутизаторы находятся под контролем других людей. Внешние
протоколы не раскрывают топологию автономной системы, поэтому в определенном
смысле их можно рассматривать как второй уровень маршрутизации, на котором соеди
няются группы сетей, а не отдельные компьютеры или кабели.
На практике небольшим и среднего размера организациям редко требуется внешний
протокол, если только они не подключены к нескольким провайдерам одновременно. При
наличии нескольких провайдеров традиционное разделение на локальный домен и домен
Интернета нарушается, поскольку маршрутизаторам приходится определять, какой марш
рут в Интернете лучше всего подходит для конкретного адреса. (Это не означает, что каж
дый маршрутизатор должен знать всю необходимую информацию. Большинство хостов мо
жет направлять свои пакеты внутреннему шлюзу, хранящему необходимые сведения.)
Поскольку внешние протоколы не сильно отличаются от своих внутренних аналогов,
в этой главе мы сосредоточим внимание на внутренних протоколах и демонах, которые
их поддерживают. Если в вашей сети поддерживается внешний протокол, обратитесь
к литературным источниками, ссылки на которые приведены в конце главы.
15.3. ОСНОВНЫЕ
ПРОТОКОЛЫ МАРШРУТИЗАЦИИ
В этом разделе мы познакомимся с основными внутренними протоколами маршру
тизации, узнаем их преимущества и недостатки.
Протоколы
и
RIP
RIPng
RIP (Routing Information Protocol - протокол маршрутной информации) - это
Xerox, адаптированный для IР-сетей. Его IР-версия была
описана примерно в 1988 году в документе RFC 1058. Существует три версии этого про
токола: RIPvl, RIPv2 и RIPng только для протокола 1Pv6 (ng (next generation) означает
старый протокол компании
"следующее поколение").
Все версии этого протокола представляют собой простые дистанционно-векторные
протоколы, метрикой стоимости в которых является количество переходов. Поскольку
протокол
RIP
разрабатывался в те времена, когда отдельные компьютеры были доро
гими, а сети маленькими, в версии
RIPvl
предполагается, что все хосты, находящие
ся на расстоянии пятнадцати и более переходов, недоступны. В более поздних версиях
это ограничение не было снято, чтобы стимулировать администраторов сложных сетей
переходить на более сложные протоколы маршрутизации.
W
Информация о бесклассовой адресации, известной под именем
в разделе
Протокол
CIDR, приведена
13.4.
RIPv2 -
это улучшенная версия протокола
RIP,
в которой вместе с адре
сом следующего перехода передается сетевая маска. Это упрощает управление сетями,
где есть подсети и применяется протокол
CIDR,
по сравнению с протоколом
RIPvl.
RIP.
В нем была также предпринята невнятная попытка усилить безопасность протокола
Протокол
RIPv2
можно выполнять в режиме совместимости. Это позволяет сохра
нить большинство его новых функциональных возможностей, не отказываясь от полу
чателей, использующих простой протокол
RIP.
Во многих аспектах протокол
идентичен исходному протоколу, и отдавать предпочтение следует именно ему.
W
Детали протокола
1Pv6 приведены в разделе 13.2.
RIPv2
Глава
15. IР-маршрутизация
507
Протокол
RIPng представляет собой переформулирование протокола RIP в терми
1Pv6. Он может использоваться только в рамках протокола 1Pv6, в то
время как протокол RIPv2 - только в рамках протокола IPv4. Если вы хотите ис
пользовать как протокол IPv4, так и протокол 1Pv6 вместе с протоколом RIP, то RIP
и RIPng необходимо выполнять как отдельные протоколы.
Несмотря на то что протокол RIP известен своим расточительным использовани
нах протокола
ем широковещательного режима, он весьма эффективен при частых изменениях сети,
а также в тех случаях, когда топология удаленных сетей неизвестна. Однако после сбоя
канала он может замедлить стабилизацию системы.
Сначала исследователи были уверены, что появление более сложных протоколов
маршрутизации, таких как
токол
RIP
OSPF,
сделает протокол
RIP
устаревшим. Тем не менее про
продолжает использоваться, потому что он простой, легкий в реализации
и не требует сложной настройки. Таким образом, слухи о смерти протокола
RIP
оказа
лись слишком преувеличенными.
Протокол
ную систему
RIP широко используется
UNIX. Многие устройства,
на платформах, не использующих операцион
включая сетевые принтеры и сетевые управля
емые SNМР-компоненты, способны принимать RIР-сообщения, узнавая о возможных
сетевых шлюзах. Кроме того, почти во всех версиях систем
иной форме существует клиент протокола
RIP.
UNIX
и
Linux в той или
RIP считается
Таким образом, протокол
"наименьшим общим знаменателем" протоколов маршрутизации. Как правило, он при
меняется для маршрутизации в пределах локальной сети, тогда как глобальную маршру
тизацию осуществляют более мощные протоколы.
На некоторых серверах запускаются пассивные демоны протокола
мон
routed
или
ripd
из пакета
Quagga),
RIP
(обычно де
которые ожидают сообщений об изменени
ях в сети, не осуществляя широковещательной рассылки собственной информации.
Реальные вычисления маршрутов выполняются с помощью более производительных
протоколов, таких как
OSPF
(см. следующий раздел). Протокол
RIP
используется толь
ко как механизм распространения.
Протокол
OSPF
OSPF (Open Shortest Path First -
открытый протокол обнаружения первого кратчайше
го маршрута) является самым популярным топологическим протоколом. Термин первый
кратчайший маршрут
(shortest path first)
означает специальный математический алгоритм,
по которому вычисляются маршруты; термин открытый (ореn)-синоним слова "непатен
тованный". Основная версия протокола
OSPF (версия 2)
а расширенная версия протокола
поддерживающая протокол
OSPF,
определена в документе
RFC2328,
1Pv6 (версия 3), - в до
кументе
в
RFC5340. Первая версия протокола OSPF устарела и сейчас не используется.
OSPF - протокол промышленного уровня, который эффективно функционирует
крупных сетях со сложной топологией. По сравнению с протоколом RIP, он имеет
ряд преимуществ, включая возможность управления несколькими маршрутами, ве
дущими к одному адресату, и возможность разделения сети на сегменты ("области"),
которые будут делиться друг с другом только высокоуровневыми данными маршрути
зации. Сам протокол очень сложный, поэтому имеет смысл использовать его только
в крупных системах, где важна эффективность маршрутизации. Для эффективного ис
пользования протокола
хический характер.
OSPF
необходимо, чтобы ваша схема адресации имела иерар
Часть
508
В спецификации протокола
11.
Работа в сетях
не навязывается конкретная метрика стоимости.
OSPF
По умолчанию в реализации этого протокола компанией
Cisco
в качестве метрики ис
пользуется пропускная способность сети.
Протокол
EIGRP
EIGRP (Enhanced lnterior Gateway Routing Protocol - улучшенный протокол марш
- это патентованный протокол маршрутизации, ис
пользуемый только маршрутизаторами компании Cisco. Протокол IGRP был разработан
для устранения некоторых недостатков протокола RIP еще в те времена, когда не было
такого надежного стандарта, как протокол OSPF. Протокол IGRP был отклонен в пользу
протокола EIGRP, который допускает произвольные сетевые маски CIDR. Протоколы
IGRP и EIGPR конфигурируются одинаково, несмотря на различия в их организации.
Протокол EIG RP поддерживает протокол 1Pv6, но в нем, как и во всех других про
токолах маршрутизации, адресные пространства 1Pv6 и 1Pv4 конфигурируются отдельно
рутизации внутреннего шлюза)
и существуют как параллельные домены маршрутизации.
Протокол
EIGRP является дистанционно-векторным,
но он спроектирован так, что
бы избежать проблем зацикливания и медленной стабилизации, свойственных другим
протоколам данного класса. В этом смысле протокол
EIGRP
большинства применений протоколы
обеспечивают равные функцио
EIGRP
и
OSPF
считается образцом. Для
нальные возможности.
BGP:
протокол граничного шлюза
Протокол
BGP (Border Gateway Protocol -
протокол граничного шлюза) является
протоколом внешней маршрутизации, т.е. он управляет трафиком между автономными
системами, а не между отдельными сетями. Существовало несколько популярных про
токолов внешней маршрутизации, но протокол
В настоящее время
BG Р
BG Р
пережил их всех.
является стандартным протоколом, используемым для ма
гистральной маршрутизации в Интернете. В средине
ции Интернета содержала около
660
2017
года таблица маршрутиза
тысяч префиксов. Совершенно очевидно, что это
масштаб, при котором магистральная маршрутизация существенно отличается от ло
кальной.
15.4. МногоАдРЕСАТНАЯ
кооРдинАция
ПРОТОКОЛА МАРШРУТИЗАЦИИ
Маршрутизаторы должны обмениваться информацией, чтобы узнать, как добраться
до мест в сети, но, чтобы добраться до мест в сети, они должны поговорить с маршрути
затором. Эта проблема с курицей и яйцом чаще всего решается посредством многоадре
сатной связи. Это сетевой эквивалент согласия на встречу с вашим другом на опреде
ленном углу улицы, если вы разделитесь. Этот процесс обычно невидим для системных
администраторов, но иногда вы можете видеть этот многоадресатный трафик в трасси
ровке пакета или при других видах сетевой отладки.
Согласованные групповые адреса для различных протоколов маршрутизации пере
числены в табл.
Существует четыре уровня сложности, характеризующих процесс управления маршрутизацией в сети:
•
•
•
отсутствие маршрутизации как таковой;
только статическая маршрутизация;
преимущественно статическая маршрутизация, но клиенты принимают RIР
обновления;
•
динамическая маршрутизация.
Общая топология сети существенно влияет на маршрутизацию каждого конкретно
го сегмента. В различных сетях могут требоваться совершенно разные уровни поддерж
ки маршрутизации. При выборе стратегии следует руководствоваться перечисленными
ниже эмпирическими правилами.
•
•
Автономная сеть не нуждается в маршрутизации.
Если из сети есть только один выход во внешний мир, клиенты сети (нешлюзовые
хосты) должны иметь стандартный статический маршрут к этому шлюзу. Никакой
другой конфигурации не требуется, кроме как на самом шлюзе.
•
Можно задать явный статический маршрут к шлюзу, ведущему в небольшую груп
пу сетей, и стандартный маршрут к шлюзу, ведущему во внешний мир. Однако
динамическая маршрутизация предпочтительнее, если до нужной сети можно до
браться разными маршрутами.
•
Если сети пересекают государственные или административные границы, следует
использовать динамическую маршрутизацию, даже если сложность сетей этого не
требует.
•
Протокол
RIP
отлично работает и широко используется.
Не отказывайтесь
от него просто потому, что он имеет репутацию устаревшего протокола.
•
Проблема протокола
RIP заключается
в том, что его невозможно масштабировать
до бесконечности. Расширение сети рано или поздно приведет к отказу от него.
Из-за этого протокол
RIP
считается промежуточным протоколом с узкой обла
стью применения. Эта область ограничена с одной стороны сетями, которые яв
ляются слишком простыми, чтобы применять в них какой-либо протокол марш
рутизации, а с другой стороны
-
сетями, которые являются слишком сложными
Часть
510
для протокола
RI Р.
в сетях
Если вы планируете расширять свою сеть, то было бы целесоо
бразно игнорировать протокол
•
11. Работа
Даже если протокол
RIP
RIP
вообще.
не соответствует вашей стратегии глобальной маршру
тизации, он остается хорошим способом распределения маршрутов к концевым
хостам. Однако его не следует применять без особой надобности: системы в сети,
имеющей только один шлюз, никогда не требуют динамического обновления.
•
Протоколы
EIGRP и OSPF имеют одинаковые функциональные возможности, но
EIGRP является собственностью компании Cisco. Компания Сisсодела
ет прекрасные и оптимальные по соотношению "цена - качество" маршрутизато
ры; тем не менее стандартизация протокола EIG RP ограничивает ваши возмшк
протокол
ности будущего расширения.
•
Маршрутизаторы, подключенные к магистрали Интернета, должны использовать
протокол
BGP.
Обычно большинство маршрутизаторов имеет только один вход и,
следовательно, для них достаточно задать простой статический стандартный маршрут.
•
OSPF примерно одинаково функциональны, но EIGRP является соб
Cisco. Cisco делает превосходные и конкурентоспособные по стои
маршрутизаторы; тем не менее стандартизация EIGRP ограничивает ваш
EIGRP
и
ственностью
мости
выбор для будущего расширения.
•
Маршрутизаторы, подключенные к Интернету через несколько провайдеров вос
ходящего потока, должны использовать протокол
BGP.
Однако большинство
маршрутизаторов имеют только один восходящий путь и поэтому могут использо
вать простой статический маршрут по умолчанию.
Хорошей стратегией по умолчанию для организации среднего размера с относитель
но стабильной локальной структурой и подключением к чужой сети является исполь
зование комбинации статической и динамической маршрутизации. Маршрутизаторы
в локальной структуре, которые не приводят к внешним сетям, могут использовать ста
тическую маршрутизацию, пересылку всех неизвестных пакетов на машину по умолча
нию, которая понимает внешний мир и выполняет динамическую маршрутизацию.
Сеть, которая слишком сложна для управления с помощью этой схемы, должна опи
раться на динамическую маршрутизацию. Статические маршруты по умолчанию все
еще можно использовать в сетях, состоящих из листьев, но машины в сетях с несколь
кими маршрутизаторами должны запускаться маршрутизированным или другим RIР
приемником в пассивном режиме.
15.6. ДЕМОНЫ
МАРШРУТИЗАЦИИ
Мы не рекомендуем использовать системы
UNIX
и
Linux
в качестве маршрутизато
ров в производственных сетях. Специализированные маршрутизаторы проще, надежнее,
безопаснее и более быстродействующие (даже если они скрытно запускают ядро систе
мы
Linux).
Иначе говоря, очень хорошо иметь возможность организовать новую подсеть,
используя всего лишь сетевую карту стоимостью
15
долл. и коммутатор за
40
долл. Это
вполне разумный подход к организации разреженных, тестовых и вспомогательных сетей.
Системы, действующие как шлюзы в таких подсетях, не требуют дополнитель
ных инструментов для управления их собственными таблицами маршрутизации.
Статические маршруты вполне адекватны как для машин, используемых в качестве
шлюзов, так и для машин, представляющих собой хосты самой подсети. Однако если
Глава
15. IР-маршрутизация
511
вы хотите, чтобы ваша подсеть была доступной для других сетей в вашей организации,
вам необходимо сообщить о ее существовании и идентифицировать маршрутизатор,
к которому будут привязаны пакеты, посылаемые данной подсетью. Обычно для этого
на шлюзе запускается демон маршрутизации.
Системы
UNIX
и
Linux
могут участвовать в большинстве протоколов маршрутизации
с помощью различных демонов маршрутизации. Важным исключением из этого прави
ла является протокол
EIGRP,
который, насколько нам известно, не имеет широко до
ступной реализации в системах
UNIX
и
Linux.
Поскольку демоны маршрутизации редко реализуются в производственных систе
мах, мы не будем подробно описывать их использование и конфигурацию. Тем не менее
в следующих разделах мы приведем краткое описание типичных программ и укажем, где
искать детали конфигурации.
Демон
routed: устаревшая
Долгое время демон
routed был
реализация в протоколе
стандартным демоном маршрутизации, и его до сих
пор включают в дистрибутивы некоторых систем. Демон
токол
Демон
RIP
и при этом плохо: даже поддержка версии
routed
не понимает протокол
менных демонах, таких как
Демон
routed
Quagga
RIP
и
RIPng,
ramd
routed
RIPv2
понимает только про
не поправила ситуацию.
реализация которого основана на совре
в системе
HP-UX.
целесообразно использовать в пассивном режиме
(-q), в котором
он принимает сообщения об обновлениях маршрутов, но не осуществляет широко
вещательную рассылку собственных сообщений. Кроме указания опций в командной
строке, демон
routed
не требует конфигурирования. Он представляет собой дешевый
и простой способ получения сообщений об обновлениях маршрутов без сложного кон
фигурирования.
Демон заносит обнаруженные маршруты в таблицу ядра. Все маршруты долж
ны анонсироваться, как минимум каждые четыре минуты, иначе они будут удалены.
Правда, демон
route
помнит, какие маршруты он добавлял, и не удаляет статические
маршруты, заданные с помощью команды
route.
W См. способы ручного управления таблицами маршрутизации в разделе 13.5.
Пакет
Quagga:
основной демон маршрутизации
Quagga (quagga. net) -
это опытно-конструкторское подразделение проекта
Zebra,
Zebra был запущен Кунихиро Ишигуро
(Kunihiro Ishiguro) и Йошинари Йошикава (Yoshinari Yoshikawa) для реализации много
выполняемого в рамках проекта
GNU.
Проект
протокольной маршрутизации с помощью коллекции независимых демонов, а не одного
монолитного приложения. В реальной жизни квагга
(quagga) - это
1870 году.
зебры, которая была последний раз сфотографирована в
инкарнация
Quagga
выжила, а проект
В настоящее время пакет
(версии
2 и 3)
системы BSD.
и
BGP.
Но его цифровая ре
Zebra закрылся.
реализует все протоколы
RIP (все версии), OSPF
Linux, FreeBSD и разных вариантах
системы Linux, имеющихся в нашем распо
Он выполняется в системах
В системе
ряжении, пакет
Quagga
исчезнувший подвид
Quagga
Solaris
и версиях
либо инсталлирован по умолчанию, либо доступен в качестве
вспомогательного пакета, который можно загрузить из стандартного системного репо
зитория программного обеспечения.
В пакете
Quagga демон zebra
играет роль информационного центра для маршрути
зации. Он управляет взаимодействием между таблицей маршрутизации ядра и демона-
ospfбd и Ьgpd). Кроме того, он управляет потоками информации о маршрутах, которы
ми обмениваются протоколы. Каждый демон имеет свой собственный конфигурацион
ный файл в каталоге
/etc/'J)J.agga.
Для того чтобы послать запрос или изменить конфигурацию, можно соединиться
с любым из демонов
интерфейса командной строки
ме
Командный язык разработан так, чтобы он был
Linux
Quagga с помощью
'J)J.aggaadm в системе Solaris).
и
понятен пользователям операционной системы
IOS
компании
детали можно найти в разделе, посвященном маршрутизаторам
IOS, для
(vtysh
в систе
Cisco; дополнительные
Cisco. Как и в системе
того чтобы войти в режим "суперпользователя", необходимо выполнить коман
ду еnаЫе, для того чтобы ввести команды конфигурирования, необходимо выполнить
команду
config term,
а для того чтобы сохранить изменения конфигурации в файле
конфигурации демона, необходимо выполнить команду
Официальная документация доступна на сайте
тах
HTML и PDF.
wri te.
quagga. net
в виде файлов в форма
Несмотря на свою полноту, эта документация содержит, в основном,
удобный каталог опций, а не общий обзор системы. Более практичную документацию
можно найти на сайте
wiki. quagga. net.
Здесь находятся подробно прокомментиро
ванные примеры файлов конфигурации, ответы на часто задаваемые вопросы и советы.
Несмотря на то что файлы конфигурации имеют простой формат, необходимо знать
протокол, конфигурацию которого вы настраиваете, а также понимать, что означают
те или иные опции. Список рекомендованной литературы по этому вопросу приведен
в конце главы.
Маршрутизатор
Проект
XORP
XORP
(eXtensiЫe
Open Router Platform -
расширяемая платформа маршрути
зации с открытым кодом) бьm открыт примерно в то же время, что и проект
его цели бьmи более универсальными. Вместо маршрутизации проект
Zebra, но
XORP бьm нацелен
на эмулирование всех функций заданного маршрутизатора, включая фильтрацию пакетов
и управление трафиком. Информация об этом проекте хранится на сайте
Интересный аспект платформы
XORP
ционирует в разных операционных системах
и
Windows Seiver 2003),
xorp. org.
заключается в том, что она не только функ
(Linux,
разных версиях
BSD,
Мае
OS
Х
но и может запускаться непосредственно с "живого" компакт
диска (т.е. непосредственно с компакт-диска, без инсталляции на жесткий диск.
Примеч. ред.) на персональном компьютере.
скрытно основан на системе
Linux,
Этот "живой" компакт-диск
(live CD)
но он прошел долгую эволюцию и позволяет превра
щать типичный персональный компьютер в специализированное устройство для марш
рутизации.
15.7. МАРШРУТИЗАТОРЫ C1sco
Маршрутизаторы, выпускаемые компанией
Cisco Systems, Inc.,
сегодня являются
стандартом де-факто-на рынке интернет-маршрутизаторов. Захватив более
компания
Cisco добилась
60%
рынка,
широкой известности своих продуктов, к тому же есть много
специалистов, умеющих работать с этими устройствами. Раньше в качестве маршрути
заторов часто приходилось использовать UNIХ-системы с несколькими сетевыми ин
терфейсами. Сегодня специализированные маршрутизаторы размещены в коммутаци
онных шкафах и над подвесными потолками, где сходятся сетевые кабели.
Глава
15. IР-маршрутизация
513
Cisco работает под управлением операционной систе
компании и не имеет отношения к си
собственностью
является
которая
IOS,
мы Cisco
стеме UNIX. У нее достаточно большой набор команд: полная бумажная документация
Большинство маршрутизаторов
занимает на полке почти полтора метра. Мы никогда не смогли бы полностью описать
здесь эту операционную систему, но все же постараемся дать о ней основные сведения.
По умолчанию в системе
IOS
определены два уровня доступа (пользовательский
и привилегированный), каждый из которых включает механизм парольной защиты.
Чтобы войти в пользовательский режим можно воспользоваться
acme-gw.acme.com>
С этого момента можно начинать вводить команды, например
для отображения списка сетевых интерфейсов маршрутизатора или
show interfaces
show ? для получе
ния справки по возможным параметрам.
Для того чтобы перейти в привилегированный режим, введите команду еnаЫе,
а при последующем запросе
-
привилегированный пароль. Признаком привилегиро
ванного режима является наличие символа"#" в конце строки приглашения.
acme-gw.acme.com#
Будьте осторожны! В данном режиме можно делать все что угодно, включая удаление
конфигурационной информации и даже самой операционной системы. Если сомневае
тесь, обратитесь к справочным руководствам по системе
ющих книг, выпускаемых издательством
Команда
Cisco
или одной из исчерпыва
Cisco Press.
show running позволяет узнать текущие динамические параметры марш
show config отображаются текущие неизменяемые парамет
рутизатора, а по команде
ры. В большинстве случаев оба набора данных идентичны. Типичная конфигурация вы
глядит следующим образом.
acme-gw.acme.com# show running
Current configuration:
version 12.4
hostname acme-gw
еnаЫе secret хххххххх
ip subnet-zero
interface EthernetO
description Acme internal network
ip address 192.108.21.254 255.255.255.О
no ip directed-broadcast
interface Ethernetl
description Acme backbone network
ip address 192.225.33.254 255.255.255.0
no ip directed-broadcast
ip classless
line con О
transport input none
line aux О
transport input telnet
line vty О 4
password хххххххх
514
Часть
11.
Работа в сетях
login
end
Модифицировать конфигурацию маршрутизатора можно разными способами.
Компания
Cisco предлагает графические утилиты, работающие в некоторых версиях
LJNJX/Linux и Windows, но опытные сетевые администраторы никогда ими не пользу
ются. Их самый мощный "инструмент" - командная строка. Кроме того, с помощью
команды scp можно загрузить с маршрутизатора его конфигурационный файл и отре
дактировать в любимом текстовом редакторе, после чего снова записать файл в память
маршрутизатора.
Для того чтобы отредактировать конфигурационный файл в режиме командной
строки, введите команду
config term.
acme-gw.acme.com# config term
Eпt.er configuratioп commands, one per line. End with CNTL/Z.
acme-gw(config)#
Теперь можно вводить конфигурационные команды в том виде, в котором их будет
отображать команда
терфейса
EthernetO,
iпterface
show running.
Например, если требуется изменить IР-адрес ин
введите следующее.
EtherпetO
ip address 192.225.40.253
255.255.255.О
По окончании ввода конфигурационных команд нажмите
,
чтобы вернуть
сн к обычной командной строке. Если все прошло успешно, сохраните новую конфигу
рацию в постоянной памяти посредством команды
wri te mem.
Приведем несколько советов, касающихся эффективной работы с маршрутизаторами
Cisco.
• Присвойте
маршрутизатору имя с помощью команды
hostname.
Это позволит из
бежать несчастных случаев, связанных с изменением конфигурации не того марш
рутизатора. Заданное имя всегда будет отображаться в командной строке.
•
Всегда храните резервную копию конфигурационного файла маршрутизатора. С
помощью команд
scp
или
tftp
можно каждую ночь пересылать текущую конфи
гурацию в другую систему на хранение.
•
Зачастую сушествует возможность хранить копию конфигурации в энергонезависи
мой памяти
•
NVRAM
или на переносном флеш-накопителе. Не пренебрегайте этим!
Сконфигурировав маршрутизатор для SSН-доступа, отключите протокол
Telnet
совсем.
•
Контролируйте доступ к командной строке маршрутизатора, создавая списки до
ступа для каждого порта УТУ (аналогичен порту РТУ в UNIХ-системе). Это не по
зволит посторонним пользователям "взломать" маршрутизатор.
•
Управляйте трафиком между сетями (по возможности, и во внешний мир тоже),
создавая списки доступа для каждого интерфейса. Более подробная информация
приведена в разделе
•
22.11.
Физически ограничивайте доступ к маршрутизаторам. Ведь если у злоумышлен
ника будет физический доступ к устройству, он легко сможет изменить пароль
привилегированного режима.
Если у вас несколько маршрутизаторов и несколько сотрудников, отвечающих
за их работу, воспользуйтесь утилитой
shruberry. net.
Название
RANCID
RANCID,
(игра слов:
которую можно загрузить
rancid -
негодный.
-
с сайта
Примеч. ред.) го-
Глава
515
15. IР-маршрутизация
ворит само за себя, но у этой программы есть одно преимущество: она регистрируется
на ваших маршрутизаторах каждую ночь и получает их файлы конфигурации. Затем она
сравнивает эти файлы и сообщает вам об их изменениях. Кроме того, она автоматиче
ски передает файлы конфигурации системе контроля версий (см. раздел
7.8).
15.8. ЛИТЕРАТУРА
• PERLMAN
Interconnections: Bridges, Routers, Switches, and lnterworking Protocols
2000. Это вьщающаяся книга в данной
Rло1л.
(2nd Edition).
Readiпg, МА: Addisoп-Wiley,
области. Если вы решили купить только одну книгу об основах работы в сетях,
покупайте ее. Кроме того, не упускайте шанса "зависнуть" с Радией
-
она очень
веселая и обладает удивительно обширными знаниями.
AлRoN Foss, AND Rлм1Rо GлRZA Rюs. /Р Routing оп Cisco /OS,
IOS ХЕ, and IOS XR: Ап Essential Guide to Understanding and Implementing /Р Routing
Protocols. lпdiaпapolis, IN: Cisco Press, 2014.
• НuпЕмл CнRISТIAN. Routing in the lnternet, Second Edition. Preпtice Hall, 2000. Эта
• EDGEWORTH, BRAD,
книга представляет собой отличное введение в маршрутизацию для начинающих.
В ней описано большинство используемых сегодня протоколов маршрутизации,
а также рассматривается ряд сложных тем, например групповое вещание.
Существует много документов
перечислены в табл.
RFC,
посвященных маршрутизации. Основные из них
15.3.
Таблица 15.З. Документы
RFC,
посвищенные маршрутизации
RFC
Название
Авторы
1256
ICMP Router Discovery Messages
Deering
1724
RIP Version 2 MIB Extension
Malkin, Baker
2080
Rlng for 1Pv6
Malkin, Minnear
2328
OSPF Version 2
Моу
2453
RIP Version 2
Malkin
4271
А
Rekhter, Li, et al.
Border Gateway Protocol 4 (BGP-4)
4552
Authentication/Confidentiality for OSPFv3
Gupta, Melam
4822
RIPv2 Cryprographic Authentication
Arkinson, Fanto
Narten et al.
4861
Neighbor Discovery for 1Pv6
5175
IPvб
5308
Routing 1Pv6 with IS-IS
Hopps
5340
OSPF for IPvб
Coltun et al.
5643
Management lnformation Base for OSFv3
Joyal, NManral, et al.
Router Advertisement Flags Option
Haberman, Hinden
глава
16
DNS:
система доменных имен
Интернет обеспечивает мгновенный доступ к ресурсам по всему миру, и каждый из
этих компьютеров или сайтов имеет уникальное имя (например,
google. com).
Тем не
менее любой, кто пытался найти друга или потерянного ребенка на переполненном ста
дионе, знает, что мало просто знать имя и его выкрикивать. Существенным фактором
для поиска чего-либо (или кого-либо) является организованная система передачи, об
новления и распространения имен и их местоположений.
Пользователи и программы на уровне пользователя любят ссылаться на ресурсы
по имени (например,
ama zon. com),
но сетевое программное обеспечение низкого уров
ня понимает только IР-адреса (например,
54.239.17.6).
Сопоставление имен и адресов
является самой известной и, возможно, самой важной функцией
ных имен.
DNS
DNS,
системы домен
включает в себя другие элементы и функции, но почти без исключения
все они существуют для поддержки этой основной цели.
На протяжении всей истории Интернета система
DNS
вызывала как восхищение, так и
критику. Ее первоначальная элегантность и простота способствовали успеху в первые годы
и позволили Интернету быстро расти под небольшим централизованным управлением. По
мере роста потребностей в дополнительных функциональных возможностях система
DNS
стала нуждаться в усовершенствовании. Иногда эти функции добавлялись способом, ко
торый сегодня выглядит уродливым. Скептики указывают на недостатки инфраструктуры
DNS
в качестве доказательства того, что Интернет находится на грани краха.
Однако, что ни говори, основные концепции и протоколы
DNS до сих
пор выдержи
вали рост от нескольких сотен хостов в одной стране до всемирной сети, которая под-
Часть
518
11. Работа
в сетях
держивает более трех миллиардов пользователей на более чем одном миллиарде ком
пьютеров.' Примеров информационной системы, которая выросла до этого масштаба
с таким количеством вопросов, больше нет. Без
DNS
Интернет давно бы провалился.
16.1. АРХИТЕКТУРА DNS
Система
DNS -
это распределенная база данных. В рамках этой модели один сервер
хранит данные для компьютеров, о которых он знает, а другой сервер хранит данные
для своего собственного набора компьютеров, при этом серверы взаимодействуют и об
мениваются данными, когда одному серверу необходимо найти данные на другом серве
ре. С административной точки зрения DNS-cepвepы, которые вы настроили для своего
домена, отвечают на внешние запросы об именах в вашем домене и в свою очередь за
прашивают серверы других доменов от имени ваших пользователей.
Запросы и ответы
DNS-зaпpoc состоит из имени и типа записи. Возвращаемый ответ
сей о ресурсах"
(resource records - RR),
-
это набор "запи
которые реаmруют на запрос (или, альтернативно,
на ответ, указывающий, что имя и тип записи, которые вы запрашивали, не существуют).
"Реаrирует" не обязательно означает "знает". DNS-cepвepы образуют иерархию,
и для ответа на конкретный запрос может потребоваться связь с серверами на несколь
ких уровнях (см. раздел
16.4). 2 Серверы,
не знающие ответа на запрос, возвращают за
писи ресурсов, которые могут помочь клиенту найти сервер, знающий ответ.
Наиболее распространенный запрос
адрес, связанный с именем. На рис.
16.l
это запрос записи А, которая возвращает IР
-
показан типичный сценарий.
"НаКти систему,
в которой находится
сайт faceЬook. com•
"Какая
запись А у сайта
facebook.cOD1?"
9et~ostbynue
( "faceЬook.cOID")
Системная бмбnиотека
Веб-браузер
Человек
Рис.
16.1.
и механизм
преобразования имен
Сервер имен
Простой поиск имени
Во-первых, человек вводит имя желаемого сайта в веб-браузер. Затем браузер вызы
вает библиотеку
DNS Resolver для
поиска соответствующего адреса. Библиотека
Resolver
создает запрос на запись А и отправляет ее на сервер имен, который возвращает запись
А в своем ответе. Наконец, браузер открывает ТСР-соединение с целевым хостом через
IР-адрес, возвращаемый сервером имен.
'Статистика относительно пользователей взята с сайта
users,
internetlivestats. com/internetstatista. com.
имен обычно получают запросы на порт 53 UDP.
а статистика по хостам
2 Серверы
-
насайте
Глава
16. DNS: система
доменных имен
Поставщики услуг
519
DNS
Несколько лет назад одной из основных задач каждого системного администратора
было создание и обслуживание DNS-cepвepa. Сегодня ситуация изменилась. Если орга
низация вообще поддерживает DNS-cepвep, он часто используется только для внутрен
него использования. 3
Каждой организации по-прежнему нужен внешний DNS-cepвep, но теперь для ис
пользования этой функции используется один из многих коммерческих "управляемых"
поставщиков
DNS.
Эrи службы предлагают интерфейс управления графическим интер
фейсом и высокодоступную, защищенную DNS-инфраструктуру за очень небольшую
плату в день.
Amazon Route 53, CloudFlare, GoDaddy, DNS Made Easy
и
Rackspace -
это
лишь некоторые из основных поставщиков.
Конечно, вы можете настроить и сохранить свой собственный DNS-cepвep (внутрен
ний или внешний), если хотите. У вас есть десятки реализаций
DNS на выбор, но си
Berkeley Internet Name Domain (BIN D) по-прежнему доминирует
75% DNS-cepвepoв являются ее разновидностью. 4
стема интернет-имен
в Интернете. Более
Независимо от того, какой путь вы выберете, в качестве системного администрато
ра вам необходимо понять основные концепции и архитектуру
DNS.
Первые несколько
разделов данной главы посвящены этим важным фундаментальным знаниям. Начиная
с раздела
16.8,
мы показываем некоторые конкретные конфигурации для
16.2. DNS для
BIND.
ПОИСКА
Независимо от того, запускаете ли вы свой собственный сервер имен, пользуйтесь
управляемой службой
DNS
или кто-то предоставляет службу
DNS
DNS.
тельно захотите настроить все свои системы на поиск имен в
для вас, вы обяза
Для этого необходимо пройти два этапа. Во-первых, следует настроить свои систе
мы как DNS-клиенты. Во-вторых, нужно сообщить системам, когда использовать
а не другие методы поиска имен, такие как статический файл
resol v. conf:
DNS,
/etc/hosts.
конфигурация клиентского
модуля распознавания
Каждый компьютер, подключенный к сети, должен быть клиентом системы
Конфигурация клиентской части системы
DNS
задается в файле
DNS.
/etc/resolv. conf,
содержащем список DNS-cepвepoв, которым можно посылать запросы.
m
Дополнительную информацию о протоколе см. в разделе
13.6.
Если ваш компьютер получает свой
сервера, то файл
1Р-адрес и сетевые параметры
/etc/resolv.conf должен заполняться автоматически. В
от
D НС Р
противно:\!
случае его нужно редактировать вручную. Формат записей файла имеет следующий вид.
search имя_домена ...
nameserver IР-адрес
1 Система
Active Directory Microsoft
включает интегрированный DNS-cepвep, который прекрас
но сочетается с другими службами, поддерживаемыми
Active Directory
Microsoft
в корпоративной среде. Однако
подходит только для внутреннего использования. Эта система никогда не должна
использоваться как внешний DNS-cepвep, связанный с Интернетом, из-за потенuиа.1ьных проб
лем с безопасностью.
•см. обзор
/SC lnternet Domain Survey,
опубликованный в июле
2015
г.
Часть
520
11.
Работа в сетях
Может быть указано от одного до трех серверов имен. Рассмотрим пример.
приведен список доменов, которые следует опрашивать, если имя
search
компьютера определено не полностью. Например, когда пользователь вводит команду
ssh coraline,
то распознаватель дополняет имя первым доменом в списке (в рассмот
ренном выше примере
- atrust. сот),
после чего ищет хост
coraline. atrust. сот.
coraline. booklab. atrust.
задать в директиве search, зависит от специ
Если это имя не найдено, делается попытка найти хост
сот. Количество доменов, которые можно
фики распознавателя; большинство из них допускает от шести до восьми доменов, при
этом предельное количество символов равно
Серверы имен, указанные в файле
256.
resol v. conf,
должны разрешать вашему ком
пьютеру посылать запросы и обязаны давать на них полные ответы (т.е. быть рекурсив
ными), а не отсылать вас на другие серверы имен (см. раздел
16.4).
Серверы имен опрашиваются по порядку. Если первый сервер отвечает на запрос,
другие серверы игнорируются. Если возникает проблема, то по истечении времени, от
веденного для ответа на запрос, он переадресуется следующему серверу. Все серверы
опрашиваются по очереди, до четырех раз каждый. С каждой неудачей тайм-аут уве
личивается. По умолчанию интервал тайм-аута задается равным пяти секундам, что
для нетерпеливых пользователей кажется вечностью.
nsswi tch. conf': кого я запрашиваю по имени?
Операционные системы
nsswi tch. conf для
FreeBSD
и
используют файл переключения
Linux
/etc/
того, чтобы указать, как выполняется отображение IР-адреса в имя
компьютера и в каком порядке следует использовать систему
DNS -
первой, последней
или вообще не использовать. Если файла переключения нет, то по умолчанию устанав
ливается следующее поведение.
hosts: dns [!UNAVAIL=return] files
Раздел
! UNAVAIL означает, что если служба DNS доступна, но имя в ней не найдено,
следует прекратить попытки поиска и не продолжать просмотр следующей записи (в дан
ном случае файла
/etc/hosts).
Если сервер имен не был запущен (это бывает во время
загрузки системы), то процесс поиска рекомендуется согласовывать с файлом
Во всех рассматриваемых нами дистрибутивах систем в файле
hosts.
nsswi tch. conf
со
держится следующая запись, определяющую поведение по умолчанию.
hosts: files dns
Эта конфигурация дает приоритет файлу
Обращение к системе
DNS
/etc/hosts,
который всегда проверяется.
происходит только для поиска имен, которые невозможно
распознать с помощью файла
/etc/hosts.
Не существует "наилучшего" способа конфигурации поиска
-
все зависит от того,
как управляется ваша сеть. В общем, мы предпочитаем хранить как можно больше инфор
мации об хаете в системе
DNS,
но мы также пытаемся сохранить возможность вернуться
при необходимости назад к статическим файлам
hosts
в процессе загрузки системы.
Если служба имени предоставляется вам внешней организацией, вы можете выпол
нить настройку
DNS
после настройки файлов
resolv. conf
и
nsswitch. conf.
В этом
случае вы можете пропустить оставшуюся часть этой главы или продолжать читать даль
ше, чтобы узнать больше.
Глава
16. DNS:
16.3.
521
система доменных имен
ПРОСТРАНСТВО ИМЕН
Пространство имен
DNS
представляет собой дерево с двумя основными ветвями, со
DNS
ответствующими прямым и обратным преобразованиям. Прямые преобразования ставят
в соответствие именам компьютеров их IР-адреса (и другие записи), а обратные пре
образования отображают
1Р-адреса
в имена компьютеров. Каждое полностью опреде
ленное имя компьютера (например, nubark.atrust.coт)
прямых преобразований, а каждый IР-адрес
-
-
это узел дерева на ветви
это узел дерева на ветви обратных преоб
разований. Уровни дерева разделяются точками; корнем дерева является точка.
Зоны прямого преобразования
Зоны обратного преобразования
. (root)
/
~ра _.-!---л~
com
in-addr
/\~
···--61~~~---
amazon
/
/'/\
... 173 ...
.. , ., {;?' \..
../~ ...
Рис.
DNS
16.2.
de ' au . . . ···
net
/\
/\
/\
···
atrust
/'\"
www
Для того чтобы система
org
n~ba~ ···
Дерево DNS-зoн
могла работать с данными обоих видов, ветвь IР
адресов в пространстве имен инвертируется, т.е. октеты IР-адресов записываются в об
ратном порядке. Например, если хост
"nubark. atrust. сот."
имеет адрес
63.173.189.1,
"nubark.
"1 . 18 9 . 1 7 3 . 6 3 .
то соответствующий узел на ветви прямых преобразований в дереве имеет имя
rus t . сот. ", а узел
in-addr.arpa." 5
аt
на ветви обратных преобразований имеет имя
Оба эти имени заканчиваются точкой, так же как полные пути файлов всегда на
чинаются с косой черты. Это делает их "полностью квалифицированными доменными
именами", или
FQDN
для краткости.
Вне контекста системы
DNS
имена, такие как
nubark. а trust.
сот (без конечной
точки), иногда называются "полностью квалифицированными именами хостов", но это
жаргонизм . В самой системе
DNS
наличие или отсутствие конечной точки имеет реша
ющее значение.
Существует два типа доменов верхнего уровня: национальные домены верхнего уров
(country code top-level domain - ccTLD) и общие домены верхнего уровня (generic top
level domain - gTLD). Организация ICANN (lnternational Corporation for Assigned Names
and Numbers) управляет проектом регистрации имен в доменах gTLD, таких как сот,
net и org, с помощью аккредитованных агентств. Для регистрации имени в домене
ccTLD зайдите на веб-страницу организации IANA (lnternet Assigned Numbers Authority)
iana. org / cctld и найдите реестр соответствующей страны.
ня
·' Часть имени
in-addr. arpa
представляет собой фиксированный суффикс.
Часть
522
11. Работа в
сетях
Регистрация доменного имени
Для того чтобы зарегистрировать домен второго уровня, необходимо подать заявку
в администрацию соответствующего домена верхнего уровня. Для того чтобы заполнить
бланки регистрации, необходимо назначить ответственного технического специалиста
и ответственного администратора, а также выбрать хотя бы два компьютера, которые
будут серверами домена. Кроме того, необходимо выбрать доменное имя, никем не за
нятое. Стоимость регистрации зависит от агентства, но в настоящее время она относи
тельно небольшая.
Создание собственных поддоменов
Процедура создания поддомена аналогична той, что используется при регистрации
домена второго уровня, только центральная администрация теперь находится в пределах
самой организации. Этот процесс предусматривает следующие этапы.
•
•
•
Выбор имени, уникального в пределах организации.
Назначение двух или более компьютеров серверами нового домена. 6
Согласование действий с администратором родительского домена.
Прежде чем передавать полномочия, администратор родительского домена должен
убедиться в том, что серr~еры имен дочернего домена сконфигурированы и работают
правильно. В противном случае произойдет то, что называется некорректным делегиро
ванием, и вы получите по электронной почте неприятное сообщение с требованием ис
править ошибку (см. раздел
17.15).
16.4. КАК РАБОТАЕТ СИСТЕМА DNS
Серверы имен по всему миру работают вместе. чтобы отвечать на запросы. Как пра
вило, они распространяют информацию, поддерживаемую любым администратором,
ближайшим к цели запроса. Понимание ролей и взаимоотношений серверов имен важ
но как для повседневных операций, так и для отладки.
Серверы имен
Сервер имен выполняет несколько рутинных операций.
•
•
Отвечает на запросы об именах и IР-адресах компьютеров.
Посылает запросы локальным и удаленным компьютерам от имени своих пользо
вателей.
•
Кеширует ответы на запросы, для того чтобы ускорить ответы на них в следую
щий раз.
•
Пересылает данные между серверами имен, чтобы обеспечить их синхронизацию.
Серверы имен работают с зонами, которые представляют собой домен без поддоме
нов. Часто термин домен употребляется как синоним термина зона, даже в этой книге.
Серверы имен работают в нескольких разных режимах, поэтому дать их точное опре
деление нелегко. Ситуация усложняется еще и тем, что один и тот же сервер может вы
полнять неодинаковые функции о разных зонах. В табл.
16. l
перечислены прилагатель
ные, употребляемые при описании серверов имен.
6С
технической точки зрения, поскольку вы сами устанавливаете правила для своего поддомена.
может быть один сервер или несколько.
Глава
16. DNS: система
Таблица
16.1.
523
доменных имен
Классификация серверов имен
Описание
Тип сервера
(authoritative)
главный (master)
Авторитетный
Официальный представитель зоны
Основное хранилище данных зоны; берет информацию из дискового
файла
первичный
(primary)
(slave)
Синоним термина главный
подчиненный
Копирует данные с главного сервера
вторичный (secoпdary)
Синоним термина подчиненный
тупиковый
(stub)
Похож на подчиненный сервер, но копирует данные только о серверах
имен (записи
внутренний (distributioп)
NS)
Сервер, доступный только в пределах домена (также называется
невидимым сервером)
Неавторитетный • (пoпauthoritative)
Отвечает на запросы, пользуясь данными из кеша; не "знает", являются
ли эти данные корректными
кеширующий (cachiпg)
Кеширует данные, полученные от предыдущих запросов; обычно
не имеет локальных зон
Выполняет запросы от имени многих клиентов; формирует большой кеш
Осуществляет запросы от имени клиента до тех пор, пока не будет най
ден ответ
Нерекурсивный (пoпrecursive)
Отсылает клиента к другому серверу, если не может получить ответ
на запрос
•строго говоря, атрибут "неавторитетный" относится к ответу на DNS-зaпpoc, а не к самому серверу.
Серверы имен систематизируются на основании источника данных (авторитетный,
кеширующий, главный, подчиненный), типа хранимых данных (усеченный), пути рас
пространения запроса (переадресующий), типа выдаваемого ответа (рекурсивный, не
рекурсивный) и, наконец, доступности сервера (внутренний). В следующих подразделах
конкретизируются наиболее важные из этих различий; об остальных различиях пойдет
речь в других разделах главы.
Авторитетные и кеширующие серверы
Главный, подчиненный и кеширующий серверы различаются только двумя харак
теристиками: откуда поступают данные и авторитетен ли сервер для домена. В каждой
зоне есть один главный сервер имен. 7 На нем хранится официальная копия данных зоны
(в файле на диске). Системный администратор модифицирует информацию, касающую
ся зоны, редактируя файлы главного сервера.
Подчиненный сервер копирует свои данные с главного сервера посредством опера
ции, называемой передачей зоны
(zone
tгansfer). В зоне должен быть как минимум один
- особый вид подчиненного сервера, загружа
NS (описания серверов имен). Один и тот же
сервером для одних зон и подчиненным - для других.
подчиненный сервер. Тупиковый сервер
ющий с главного сервера только записи
компьютер может быть главным
m
Дополнительную информацию о передаче зоны см. в разделе в разделе 16.9.
Кеширующий сервер имен загружает адреса серверов корневого домена из конфи
гурационного файла и накапливает остальные данные, кешируя ответы на выдаваемые
7 Некоторые
организации используют несколько главных серверов или вообще обходятся без них;
мы описываем вариант, в котором существует один главный сервер.
Часть
524
11. Работа
в сетях
им запросы. Собственных данных у кеширующего сервера нет, и он не является автори
тетным ни мя одной зоны (за исключением, возможно, зоны локального компьютера).
Гарантируется, что авторитетный ответ сервера имен является точным; неавторитет
ный ответ может быть устаревшим. Тем не менее очень многие неавторитетные ответы
оказываются совершенно корректными. Главные и подчиненные серверы авторитетны
мя своих зон, но не мя кешированной информации о других доменах. По правде го
воря, даже авторитетные ответы могут быть неточными, если системный администратор
изменил данные главного сервера (например, обновил порядковый номер зоны) и забыл
передать их подчиненным серверам.
В каждой зоне должен быть хотя бы один подчиненный сервер. В идеале подчинен
ных серверов имен должно быть минимум два, причем один из них
-
вне организации.
Подчиненные серверы на местах должны быть включены в разные сети и в разные цепи
электроснабжения. Если служба имен вдруг перестанет функционировать, пользователи
не смогут нормально работать в сети.
Рекурсивные и нерекурсивные серверы
Серверы имен бывают рекурсивными и нерекурсивными. Если у нерекурсивного
сервера есть адрес, оставшийся в кеше от одного из предыдущих запросов, или он явля
ется авторитетным мя домена, к которому относится запрашиваемое имя, то он даст со
ответствующий ответ. В противном случае он вернет отсылку на авторитетные серверы
другого домена, которые с большей вероятностью ответят на запрос. Клиенты нерекур
сивного сервера должны быть готовы принимать отсылки и обрабатывать их.
У нерекурсивных серверов обычно есть веские причины не выполнять дополнительную
работу. Например, все корневые серверы и серверы доменов верхнего уровня являются не
рекурсивными, поскольку им приходится обрабатывать десятки тысяч запросов в секунду.
Рекурсивный сервер возвращает только реальные ответы или сообщения об ошиб
ках. Он сам отслеживает отсылки, освобождая от этой обязанности клиента. Базовая
процедура анализа запроса, по сути, остается неизменной.
Из соображений безопасности, серверы имен организации, доступные извне, всегда
должны быть нерекурсивными. Рекурсивные серверы имен, которые видны извне, мо
гут стать объектом мя атаки.
Учтите, что библиотечные функции распознавания имен не понимают отсылок.
Любой локальный сервер имен, указанный в файле
resolv.conf
клиента, должен быть
рекурсивным.
Записи о ресурсах
Каждая организация поддерживает один или несколько фрагментов распределенной
базы данных, лежащей в основе всемирной системы
DNS.
Ваш фрагмент данных состоит
из текстовых файлов, содержащих записи о каждом компьютере вашей сети; эти записи на
зываются "записями о ресурсах". Каждая запись представляет собой отдельную строку, со
стоящую из имени (обычно имени компьютера), типа записи и некоторых значений. Поле
имени можно не указывать, если его значение совпадает с именем в предьщущей строке.
Например, строки
nubark
IN
IN
А
МХ
63.173.189.1
10 mailserver.atrust.com.
в файле "прямого преобразования" (с именем
1
IN
PTR nubark.atrust.com.
atrust. com)
и строка
Глава
16. DNS:
525
система доменных имен
в файле "обратного преобразования" (с именем
atrust. сот с
IР-адресом
63.173.189.1.
63 .173 .189. rev) связывают сайт nubark.
Запись МХ перенапрамяет сообщение электронной
почты, адресованное на эту машину, на компьютер тailserver.
atrust. сот.
Поля IN обозначают классы записей. На практике, эти поля означают Интернет.
Записи о ресурсах - это универсальный язык системы DNS. Они не зависят от фай
лов конфигурации, управляющих операциями , которые выполняются на любой реали
зации данного сервера DNS. Все они являются фрагментами данных, циркулирующих
внутри системы
и кешируются в разных местах.
DNS,
Делегирование
Все серверы имен считывают имена корневых серверов из локальных файлов кон
фигурации или содержат их в своем коде. Корневые серверы "знают" о доменах сот,
org, edu, fi, de
и других доменах верхнего уровня . Эта цепочка продолжается даль
edu "знает" о домене colorado. edu, berkely. edu, сервер домена
сот "знает" о домене adтin. сот и т.д. Каждая зона может делегировать полномочия
ше: сервер домена
по управлению своими поддоменами другим серверам .
Рассмотрим реальный пример . Предположим, требуется узнать адрес хоста
vangogh.
lair.cs.c olo rado.edu . Компьютер lair
просит локальный сервер имен, ns. cs. colorado. edu, найти ответ на этот вопрос.
Последующие события представлены на рис . 16.3.
cs.berkeley.edu,
находясь на хосте
Нерекурсивный
Рекурсивный
root(".")
СТАРТ
edu
ns.cs.colorado.edu
lair
9- А
8-Q
berkeley .edu
Q -Запрос
А -Ответ
cs.berkeley.edu
R -Ссылка
Рис. 16.З. Обработка запроса в
DNS
Числа возле стрелок определяют порядок событий, а буквы
-
тип транзакции (запрос,
ссылка или ответ) . Предполагается , что никакие из требуемых данных предварительно
не кешировались, за исключением имен и IР-адресов серверов корневого домена.
Локальный сервер имен не "знает" адреса компьютера vangogh. Более того, ему
ничего не известно о доменах cs. berkeley. edu, berkeley. edu и даже edu. Он "зна
ет" лишь некоторые серверы корневого домена, запрашивает корневой домен об хосте
vangogh. cs. berkeley. edu
и получает ссылку на серверы в домене
edu.
Локальный сервер имен является рекурсивным. Если ответ на запрос содержит
ссылку на другой сервер, то локальный сервер повторно направляет запрос новому сер
веру. Он продолжает этот процесс, пока не найдет требуемый сервер .
В нашем примере локальный сервер имен посылает запрос серверу домена
всегда, запрашивая компьютер
vangogh. cs. berkeley. edu)
edu
(как
и получает ссылку на неза-
Часть
526
11. Работа
в сетях
висимые серверы домена
berkeley. edu. Затем локальный сервер повторяет запрос, на
berkeley. edu. Если сервер университета Беркли не содержит ответ
в кеше, он вернет ссьmку на домен cs. berkeley. edu. Сервер этого домена компетентен
в отношении запрашиваемой информации и возвращает адрес компьютера vangogh.
По окончании процедуры в кеше сервера ns. cs. colorado. edu окажется адрес
компьютера vangogh. В кеше будут также находиться списки серверов доменов edu,
berkeley. edu и cs. berkeley. edu.
Детали процедуры запроса можно выяснить с помощью утилит dig +trace или
правляя его в домен
drill -Т. 8
Кеwирование и эффективность
Кеширование повышает эффективность поиска: кешированный ответ выдается поч
ти мгновенно и обычно точен, так как адресно-именные соответствия меняются редко.
Ответ хранится в течение периода времени, называемого
TTL (time to live),
продолжи
тельность которого задается владельцем искомой записи. Большинство запросов каса
ется локальных компьютеров и обслуживается быстро. Повышению эффективности не
вольно содействуют и сами пользователи, так как многие запросы повторяются.
Обычно записи о ресурсах вашей организации должны использовать период
TTL,
продолжительность которого, как правило, лежит в диапазоне от одного часа до одного
дня. Чем дольше период
TTL,
тем меньше трафик сети, потребляемый интернет-клиен
тами, получающими свежие копии записи.
Если у вас есть специальная служба, загрузка которой сбалансирована между логи
ческими подсетями (этот процесс называется балансированием нагрузки глобального сер
вера), вы можете потребовать, чтобы поставщик услуг, выполняющий балансирование
загрузки, выбрал более короткую продолжительность
одну минуту. (Короткий период
TTL
TTL,
например десять секунд или
позволяет балансировщику загрузки быстро реа
гировать на бездействие серверов и атаки на основе отказа в обслуживании.) Система
с короткими периодами
TTL
продолжает работать корректно, но ваши серверы имен
должны работать в более интенсивном режиме.
В примере, описанном выше, продолжительность периодов
TTL бьmа установлена так:
- 42 дня, в домене edu - два дня, в домене berkeley. edu - два дня
и один день - для сайта vangough. cs. berkeley. edu. Это разумные величины. Если вы
планируете крупную перенумерацию, то можете сделать периоды TTL короче, чем раньше.
Серверы DNS также реализуют негативное кеширование. Иначе говоря, они помнят,
на корневых серверах
в каких ситуациях запрос остался без ответа, и не повторяют его, пока не истечет период
TTL для
негативного кеширования. Ответы при негативном кешировании сохраняются
в следующих ситуациях.
•
•
•
•
Нет хоста или домена, соответствующего запрашиваемому имени.
Данные запрашиваемого типа для данного хоста не существуют.
Запрашиваемый сервер не отвечает.
Сервер недоступен из-за проблем в сети.
Сервер
BIND
кеширует данные в двух первых ситуациях, а сервер UnЬound
-
во всех
четырех. Количество повторений негативного кеширования можно задавать в любой ре
ализации.
кутилиты
diq
набор сервера
и
drill - это инструменты системы DNS;
BIND, а утилита drill разработана группой
утилита
NLпet
diq
Labs.
входит в дисТРибутивный
Глава
16. DNS: система
доменных имен
527
Неоднозначные ответы и балансировка загрузки
DNS
Сервер имен в ответ на запрос часто получает несколько записей. Например, при по
пытке узнать адрес сервера имен корневого домена можно получить список, содержа
щий все
13
корневых серверов. Большинство серверов имен возвращает ответы в слу
чайном порядке, выполняя примитивный вид балансирования загрузки.
Можно достичь балансирования загрузки своих серверов, закрепив одно имя за не
сколькими IР-адресами (которые в реальности соответствуют разным компьютерам).
www
IN
IN
IN
А
192.168.0.1
192.168.0.2
А
192.168.0.З
А
Большинство серверов имен возвращают многорекордные множества в другом по
рядке каждый раз, когда они получают запрос, вращая их в циклическом режиме. Когда
клиент получает ответ с несколькими записями, наиболее распространенное поведение
заключается в том, чтобы попробовать адреса в порядке, возвращаемом DNS-cepвepoм. 9
Эта схема обычно называется балансированием нагрузки на основе циклического рас
пределения нагрузки. Однако в лучшем случае это грубое решение. На больших сайтах
используется программное обеспечение балансирования нагрузки (например,
см. раздел
19.6)
HAProxy,
или специализированные устройства балансирования нагрузки.
Отладка с помощью инструментов запросов
W
Дополнительную информацию о спецификациях
DNSSEC см.
в разделе
16.1 О.
Пять инструментов командной строки, которые запрашивают базу данных
пространяются с помощью дистибутивов
Утилиты
nslookup
и
host
просты и имеют неплохую производительность, но, чтобы
получить все детали, нужны утилиты
с цепочками подписей
lnformation Groper -
DNS, рас
BIND: nslookup, dig, host, drill и delv.
DNSSEC.
dig
или
drill. Утилита drill лучше работает
drill обыгрывает имя dig (Domain
Имя команды
средство сбора информации о доменах}, подсказывая, что благода
ря этой утилите можно получить еще больше информации от системы
щью утилиты
итоге заменит
dig.
Утилита
delv
утилиту drill для
впервые появилась в системе
отладки
DNS, чем с помо
BIND 9.10 и в конечном
DNSSEC.
W Дополнительную информацию о расщеплении DNS см. в разделе 16.7.
По умолчанию утилиты
рированным в файле
dig и drill посылают запросы серверам имен, сконфигу
/etc/resolv.conf. Аргумент @сервер_имен адресует команду
конкретному серверу имен. Способность посылать запросы конкретному серверу по
зволяет гарантировать, что любые изменения, вносимые в зону, будут распространены
среди подчиненных серверов и во внешнем мире. Это свойство особенно полезно, если
вы используете представления (расщепляете
DNS)
и должны проверять, правильно ли
они сконфигурированы.
Если указать тип записи, то команды
к этим записям. Псевдотип
any
dig
и
drill
будут выполнять запрос только
действует немного неожиданно: вместо того чтобы вер
нуть все данные, ассоциированные с указанным именем, он возвращает все кеширован
ные данные, связанные с ним. Итак, чтобы получить все записи, необходимо выполнить
команду
dig
домен
NS,
за которой следует выражение
dig
@nsl.домен. домен
any.
(Авторитетные данные в этом контексте рассматриваются как кешированные.)
9 0днако
это поведение не является обязательным. Разные клиенты могут иести себя по-разному.
Часть
528
Утилита
dig
имеет более
чества. Получив флаг
50
опций, а утилита
drill -
11. Работа
в сетях
около половины этого коли
-h, эти утилиты выдают список всех своих опций. (Для того чтобы
упорядочить вывод, можно передать его утилите
less.) Для
обеих утилит опция -х зме
няет порядок следования байтов в IР-адресе на противоположный и выполняет обрат
ный запрос. Флаги
+trace
утилиты
dig
и -т утилиты
drill
показывают итеративные
шаги в процессе распознавания, начиная от корня и вниз по дереву иерархии.
Если ответ является авторитетным (т.е. приходит непосредственно от главного или
подчиненного сервера данной зоны), то команды
зуют символы аа. Код
DNSSEC.
ad
dig и drill
во флагах вывода исполь
означает, что ответ является аутентичным в смысле протокола
Тестируя новую конфигурацию, следует убедиться, что вам доступны данные
как локальных, так и удаленных хостов. Если вы имеете доступ к хосту только по его
адресу, а не по имени, то в этом, вероятно, виновата система
Чаше всего утилита
dig
1Р
DNS.
используется для выяснения того, какие записи в настоя
щее время возвращаются для определенного имени. Если возвращается только ответ
AUTHORITY,
вет ANSWER,
значит, вы перенаправлены на другой сервер имен. Если возвращается от
значит, на ваш вопрос был дан ответ (и, может быть, была включена другая
информация).
Часто бывает полезно следить за цепочкой делегирования вручную с корневых сер
веров, чтобы убедиться, что все находится в правильных местах. Ниже мы рассмотрим
пример этого процесса для названия
www. viawest.
сот. Во-первых, мы запрашиваем
корневой сервер, чтобы узнать, кто является авторитетным для сайта
просив начальную запись
viawest.
сот, за
(start-of-authority - SOA).
$ dig @a.root-servers.net viawest.com soa
; DiG 9.8.3-Pl @a.root-servers.net viawest.coт soa
; (1 server found)
,, global options: +стd
,, Got answer:
,, ->>HEADERHEADERHEADERHEADER update add newhost.cs.colorado.edu 86400 А 128.138.243.16
>
> prereq nxdomain gypsy.cs.colorado.edu
> update add gypsy.cs.colorado.edu СNАМЕ evi-laptop.cs.colorado.edu
Динамические обновления - очень опасная возможность. Они потенциально
спо
собны предоставить право неконтролируемой записи важных системных данных.
Не пытайтесь контролировать доступ на основании IР-адресов: их легко подделать.
Лучше воспользоваться системой аутентификации
Например, в системе
$ nsupdate -k
BIND 9 поддерживается
каталог_ключа:файл_ключа
TSIG
команда
с общим секретным ключом.
Глава
16. DNS: система доменных имен
567
или
% nsupdate -k
каталог_ключа:секретный_ключ
Поскольку пароль задается в командной строке после ключа -у, его может увидеть
тот, кто запустит команду
w или ps
в правильный момент. По этой причине более пред
почтительной является форма -k. Подробнее технология
TSIG описана в разделе 16. IO.
named.conf посредством па
update-policy. Параметр allow-update предоставляет
Динамические обновления зоны разрешаются в файле
раметра
или
allow-update
право обновления любых записей клиентам, чьи IР-адреса и ключи шифрования указа
ны в списке. Параметр
update-policy
появился в
BIND 9
и позволяет точнее управ
лять обновлениями на основании имен хостов и типов записей. Он требует использовать
механизмы аутентификации. Оба параметра являются зонными.
С помощью параметра
записи А и
update-policy
можно разрешить клиентам обновлять свои
PTR, но не SOA, NS или КЕУ. Можно также позволить хосту обновлять толь
ко свои записи. Имена допускается задавать явно, в виде поддоменов, с метасимвола
ми или с помощью ключевого слова
self,
которое задает правила доступа компьютера
к собственным записям. Записи о ресурсах идентифицируются по классу или типу.
Синтаксис параметра
(grantldeny)
update-policy
сущность имя_типа
Сущность
-
имя
выглядит следующим образом.
[типы]
;
это имя криптографического ключа, необходимого для авторизации
обновлений. Имя_типа имеет четыре значения:
Опция
self
name, subdomain, wildcard
или
self.
является особенно полезной, потому что позволяет хосту обновлять только
свои записи. По возможности, следует использовать именно ее.
Имя -
это обновляемая зона, а типы -
типы записей о ресурсах, которые можно об
новить. Если типы не указаны, то могут обновляться записи всех типов, кроме
SOA, :-is,
RRSIG и NSEC или NSECЗ. Рассмотрим пример.
update-policy ( grant dhcp-key subdomain dhcp.cs.colorado.edu
А
) ;
В такой конфигурации любому, у кого есть ключ
dhcp-key, разрешается обнов
dhcp. cs. colorado. edu. Эта дир·ектива должна
появиться в файле named.conf в инструкции zone домена dhcp.cs.colorado.e ju.
Потребуется также инструкция key, содержащая определение ключа dhcp-key.
Приведенный ниже фрагмент файла named. conf факультета компьютерных наук
университета Колорадо (Computer Science Department at the University of Colorado) ис
пользует инструкцию update-policy для того, чтобы позволить студентам, находя
лять адресные записи в поддомене
0
щимся в классе системного администратора, обновлять свои поддомены, не касаясь при
этом остального окружения системы
DNS.
// saclass.net
zone "saclass.net" (
type master;
file "saclass/saclass.net";
update-policy (
grant feanor mroe. subdomain saclass.net.;
grant mojo_mroe. subdomain saclass.net.;
grant dawdle mroe. subdomain saclass.net.;
grant pirate_mroe. subdomain saclass.net.;
);
Часть
568
11. Работа в
сетях
16.10. ВОПРОСЫ БЕЗОПАСНОСТИ DNS
DNS
появилась как совершенно открытая система, но в процессе развития она ста
новилась все более защищенной, приобретая необходимые средства защиты. По умол
чанию каждый, у кого есть доступ в Интернет, может исследовать чужой домен от
дельными запросами с помощью таких команд, как
dig, host, nslookup
или
drill.
В некоторых случаях можно получить образ всей базы данных
Для устранения этих недостатков в последние версии
DNS.
пакета BIND
были введены
различные средства управления доступом, основанные на проверке адресов или крипто
);
Собственно ограничение реализуется такой строкой.
allow-transfer { ourslaves; measurements; );
Передачи разрешены только нашим подчиненным серверам, а также компьютерам
глобального исследовательского проекта, который посвящен определению размеров
сети Интернет и процента неправильно сконфигурированных серверов. Подобное огра
ничение лишает остальных пользователей возможности получать дамп всей базы дан
ных с помощью команды
dig
(см. раздел
16.4).
Разумеется, нужно по-прежнему защищать сеть на более низком уровне с помо
щью списков управления доступом на маршрутизаторе и стандартных средств защиты
на каждом хосте. Если такой возможности нет, ограничьте трафик DNS-пакетов шлюзо
вым компьютером, который находится под постоянным административным контролем.
Открытые распознаватели
Открытый распознаватель
-
это рекурсивный кеширующий сервер имен, получаю
щий запросы от любого пользователя Интернета и отвечающий на них. Открытые рас
познаватели опасны. Внешние пользователи могут потреблять ваши ресурсы без вашего
разрешения или ведома, и, если они делают это со злым умыслом, кеш вашего распоз
навателя может быть "заражен".
Что еще хуже, открытые распознаватели иногда используются злоумышленниками
для усиления распределенной атаки на основе отказа в обслуживании. Организаторы
атаки посылают запрос на ваш распознаватель, указывая фальшивый адрес отправителя,
который является объектом атаки. Ваш распознаватель послушно отвечает на эти запро
сы и посылает огромный пакет жертве. Жертва не посьmала запросы, но она обязана
выполнить маршрутизацию и обработать сетевой трафик. Умножьте объем пакета на ко
личество распознавателей, и вы осознаете реальную опасность, грозящую жертве.
Статистика свидетельствует о том, что от
70
до
75%
кеширующих серверов имен
в настоящее время являются открытыми распознавателями! Сайт
dns.measurementfactory. com/tools может помочь вам проверить вашу организацию. Зайдите на него,
щелкните на ссылке Open resolver test и введите IР-адрес вашего сервера имен. Вы мо-
Часть
570
11. Работа в
сетях
жете также проверить все серверы имен вашей сети или все серверы вашей организации,
используя идентификаторы
whois.
Для того чтобы ваши кеширующие серверы имен отвечали на запросы только локаль
ных пользователей, исполь.зуйте список упрамения доступом в файлах
Работа в виртуальном окружении
named. conf.
chroot
Если хакеры взломают ваш сервер, то они смогут получить доступ к системе под ви
дом законного пользователя. Для того чтобы уменьшить опасность, возникающую
в этой ситуации, вы можете запустить сервер в виртуальном окружении
chroot
под ви
дом непривилегированного пользователя либо сделать и то, и другое одновременно.
Для демона
а флаг
-u
n&lll8d флаг
команды
-t задает
каталог виртуального окружения
chroot,
named.
указывает идентификатор пользователя, под которым работает демон
Рассмотрим пример.
$ sudo nalll8d -u 53
Эта команда запускает демон
named
named
как корневой процесс, но после того как демон
закончит рутинные операции в роли корневого процесса, он потеряет привиле
гии и запустится под идентификатором
UID 53.
-u
Многие организации не используют флаги
и
-t,
но если объявлена тревога, они
должны реагировать быстрее, чем хакеры.
Виртуальное окружение
chroot
не может быть пустым каталогом, поскольку оно
должно содержать все файлы, необходимые серверу имен для нормальной работы,
грузки библиотек, поэтому копировать общие библиотеки в виртуальное окружение не
обязательно.
Безопасные межсерверные взаимодействия
посредством технологий TSIG и ТКЕУ
Пока спецификация
нятия, группа
DNSSEC (см. следующий подраздел) находилась на стадии при
IETF разработала более простой механизм, названный TSIG (RFC2845). Он
позволял организовать безопасное взаимодействие серверов благодаря использованию сиг
натур транзакций. Контроль доступа, основанный на таких сигнатурах, надежнее контроля
на основе исходных IР-адресов. Технология
TSIG
позволяет защитить передачу зоны между
главным и подчиненным серверами, а также защитить динамические изменения.
В технологии
TSIG
применяется симметричная схема шифрования, т.е. ключ шиф
рования совпадает с ключом дешифрования. Такой ключ называется общим секретным
ключом (shaгed
secret).
Спецификация
дов шифрования. В пакете
BIND
TSIG
допускает использование нескольких мето
реализованы некоторые из таких методов. Для каждой
пары серверов, между которыми организуется защищенный канал связи, должен созда
ваться свой ключ.
Спецификация
TSIG
гораздо менее затратная в вычислительном плане, чем шифро
вание с открытым ключом, но она подходит только для локальной сети, где число пар
взаимодействующих серверов невелико. На глобальную сеть эта спецификация не рас
пространяется.
глава
16. DNS:
система доменных имен
Настройка технологии
Утилита
571
для сервера
TSIG
BIND
являющаяся частьюпакета
dnssec-keygen,
BIND,
генерирует ключ
для пары серверов. Рассмотрим, например, следующую команду.
$ dnssec-keygen
-а НМАС-SНА256
-Ь
128 -n HOST master-slavel
Кmaster-slavel+l63+15496
Флаг -Ь
означает, что утилита
128
dnssec-keygen
должна создать 128-разрядный
ключ. В данном случае мы используем 128-разрядный ключ только лишь для того, что
бы он поместился на странице. В реальной жизни следует использовать более длинный
ключ; максимально допустимая длина ключа равна
512.
Данная команда создает два файла:
Кmaster-slavel.+163+15496.private
Кmaster-slavel.+163+15496.key
Здесь
163 -
код алгоритма
HMAC-SHA256,
а
случайное число, использу
15496 -
емое в качестве идентификатора ключа на случай, если у одной пары серверов есть не
сколько ключей. 20 Оба файла содержат один и тот же ключ, но в разных форматах.
Файл .private выглядит примерно так.
Private-key-format: vl.3
Algorithm: 163 (НМАС_SНА256)
Кеу: owKt6ZWOluOgaVFkwOqGxA==
Bits: ААА=
Created: 20160218012956
PuЬlish: 20160218012956
Activate: 20160218012956
Содержимое файла
master-slavel. IN
. key
КЕУ
512
будет таким.
З
163 owKt6ZWOluOgaVFkwOqGxA==
Обратите внимание на то, что утилита
dnssec-keygen
добавила точки в конец име
. key. Это объясняется тем,
DNSSEC, добавляемые в файлы
ни каждого ключа в обоих именах файлов и внутри файла
что когда утилита
dnssec-keygen
использует ключи
зон, имена этих ключей должны ~ыть полностью определенными именами доменов и,
следовательно, должны заканчиваться точкой. Таким образом, нам нужны два инстру
мента: один для общих секретных ключей, а второй
Вообще-то, файл
dnssec-keygen
. key
-
для пар открытых ключей.
на самом деле не нужен: он создается потому, что утилита
имеет двойное назначение. Просто удалите его. Число
512
в записи
КЕУ означает не длину ключа, а флаг, идентифицирующий запись как запись о главном
ключе
DNS.
После всех этих сложностей вы могли быть разочарованы тем, что сгенерирован
ный ключ представляет собой просто длинное случайное число. Этот ключ можно бьuю
бы сгенерировать вручную, записав строку в кодировке
ASCII,
длина которой делится
на четыре, и считать, что вы применили 64-разрядное кодирование, или использовать
утилиту
mmencode для
того, чтобы зашифровать случайную строку. Способ, которым вы
кодируете ключ, не имеет значения; он просто должен существовать на обеих машинах.
Скопируйте ключ из файла
.private
на оба сервера с помощью команды
просто скопируйте и вставьте его. Не используйте утилиты
telnet
и
ftp
scp
или
для копирова
ния ключа: даже внутренние сети могут быть небезопасными.
20 Это
число выглядит случайным, но на самом деле оно представляет собой хешированное значе
ние ключа
TSJG.
572
Часть
11. Работа
в сетях
W Команда scp является частью пакета SSH. Дополнительную информацию
см. в разделе 27.7.
Ключ должен быть записан в файлах
named. conf на обоих компьютерах. В связи
- нет, поместите ключ в отдельный файл,
который будет включаться в файл named. conf. Файл ключа должен иметь уровень до
ступа, равный 600, и принадлежать пользователю демона named.
Например, можно создать файл master-slavel. tsig и включить в него следующий
с тем, что эти файлы общедоступны, а ключ
На данном этапе лишь определен ключ. Для того чтобы его можно было использо
вать для подписи и проверки обновлений, нужно посредством инструкции
рективы
keys
в инструкцию zone на главном сервере можно
allow-transfer { key master-slavel. ; };
а в файл
server
server
иди
заставить каждый сервер идентифицировать другую сторону. Например,
named. conf
включить строку
подчиненного сервера
IР-адрес-главного_сервера
- строку
{ keys [ master-slavel ; } ; } ;
Имя ключа в нашем примере носит общий характер. Если вы используете ключи
TSIG
для многих зон, то, возможно, захотите включить в имя ключа имя зоны, чтобы
все стало ясно.
Если вы впервые используете подписи транзакций, запускайте демон
named
на первом уровне отладки (режимы отладки будут описаны позднее), пока сообщения
об ошибках не исчезнут.
При использовании ключей
TSIG
и подписей транзакций между главным и подчи
ненным серверами необходимо синхронизировать часы на обоих серверах по протоколу
NTP.
Если часы слишком сильно расходятся (более чем на пять минут), то верификация
подписи не будет выполнена. Эту проблему иногда очень сложно распознать.
TSIG -
это механизм сервера
BIND,
позволяющий двум хостам автоматически ге
нерировать общий секретный ключ, не прибегая к телефонным звонкам или секретно
му копированию для распространения ключа. Он использует алгоритм обмена ключами
Диффи-Хеллмана
(Diffie-Hellman key exchange algorithm),
в котором на каждой сторо
не генерируется случайное число, над ним выполняются определенные математические
операции, а результат посылается другой стороне. Затем каждая сторона объединяет
свое и полученное числа по определенному математическому правилу и получает один
и тот же ключ. Злоумышленник может перехватить сообщение, но он не сможет выпол
нить над ним требуемые математические операции. 21
Серверы компании
который называется
Microsoft
GSS-TSIG.
используют нестандартный вариант механизма
ТКЕУ. Если вам нужно, чтобы сервер компании
BIND,
используйте опции
TSIG,
В нем для обмена ключами используется технология
tkey-domain
и
Microsoft взаимодействовал
tkey-gssapi-credential.
с сервером
21 Математическую основу этого алгоритма образует задача дискретного логарифмирования, осо
бенность которой состоит в том, что в модулярной арифметике возвести число в степень довольно
просто, а вычислить логарифм по этой степени практически невозможно.
Глава
16. DNS: система
доменных имен
573
Другой механизм для подписи транзакций между серверами или службами динами
ческого обновления и главным сервером называется
SIG(O).
Он использует криптогра
фию, основанную на открытых ключах. Детали этой технологии описаны в документах
RFC2535
и
RFC293 l.
Технология
DNSSEC
это набор расширений
DNSSEC -
DNS,
позволяющих аутентифицировать ис
точник данных зоны и проверить их целостность, используя шифрование с открытым
ключом. Таким образом,
DNSSEC
позволяет DNS-клиентам задавать вопросы вида
"Действительно ли данные зоны поступили от владельца зоны?" и "Те ли это данные, ко
торые послал владелец?"
Технология
DNSSEC
основана на цепочке доверия: корневые серверы предоставля
ют подтверждающую информацию для доменов верхнего уровня, те
-
для доменов вто
рого уровня и т.д.
В системах шифрования с открытым ключом используются два ключа: один шифру
ет (подписывает) сообщение, а другой дешифрует (проверяет) его. Публикуемые данные
подписываются секретным "личным" ключом. Любой может проверить правильность
цифровой подписи с помощью соответствующего "открытого" ключа, который свободно
распространяется. Если открытый ключ позволил правильно расшифровать файл зоны,
значит, зона была зашифрована искомым личным ключом. Суть в том, чтобы убедиться
в подлинности открытого ключа, используемого для проверки. Такие системы шифрова
ния позволяют одной из сторон поставить свою "подпись" на открытом ключе, переда
ваемом другой стороне, гарантируя легитимность ключа. Отсюда термин цепочка доверия.
Данные, составляющие зону, слишком велики для шифрования с открытым ключом;
процесс шифрования получится слишком медленным. Вместе с тем данные сами по себе
не секретны, поэтому они просто пропускаются через функцию хеширования (к примеру,
вычисляется контрольная сумма
MDS),
а результат подписывается (шифруется) секрет
ным ключом зоны. Полученный зашифрованный хеш-код называется цифровой подписью
или сигнатурой зоны. Цифровые подписи обычно добавляются к данным, подлинность
которых они удостоверяют в виде записей
RRSIG
в подписанном файле зоны.
Для проверки сигнатуры ее нужно дешифровать открытым ключом подписавшей
стороны, "прогнать" данные через тот же алгоритм хеширования и сравнить вычислен
ный хеш-код с расшифрованным. В случае совпадения подписавшее лицо считается
аутентифицированным, а данные
В технологии
DNSSEC
-
целостными.
каждая зона имеет открытые и секретные ключи. Фактически
она имеет два набора ключей: пара ключей для подписи зоны и пара ключей для под
писи ключа. Секретным ключом подписи зоны подписывается каждый набор ресурсов
(т.е. каждый набор записей одного типа, относящихся к одному хосту). Открытый ключ
подписи зоны используется для проверки сигнатур и включается в базу данных зоны
в виде записи
DNSKEY.
Родительские зоны содержат записи
DS,
представляющие собой хешированный ва
риант записей DNSKEY для самоподписывающихся ключей подписи ключей
key-signing keys).
(self-signed
Сервер имен проверяет аутентичность записи DNSKEY дочерней зоны,
сравнивая ее с подписью родительской зоны. Для проверки аутентичности ключа ро
дительской зоны сервер имен проверяет родительскую зону родительской зоны и так
далее, пока не вернется в корневую зону. Открытый ключ корневой зоны должен быть
открыто опубликован и включен в файлы "подсказок" корневой зоны.
В соответствии со спецификациями
DNSSEC,
если зона имеет несколько ключей,
каждый из них должен применяться при проверке данных. Это требование объясняется
часть
574
тем, что ключи мoryr быть изменены без прерывания работы службы
сивный сервер имен, использующий технологию
DNSSEC,
11. Работа
DNS.
в сетях
Если рекур
посылает запрос неподпи
санной зоне, то поступающий неподписанный ответ считается корректным. Проблема
возникает лишь тогда, когда срок действия подписи истек или родительская и дочерняя
зоны не согласовали текущий ключ
Правила протокола
DNSKEY
дочерней зоны.
DNSSEC
Прежде чем приступать к развертыванию протокола
DNSSEC,
следует усвоить не
сколько правил и процедур или хотя бы подумать о них. Рассмотрим примеры.
•
Ключи какого размера вы будете использовать'? Более длинные ключи являются
более надежными, но они увеличивают размеры пакетов.
•
Как часто будете изменять ключи, если никаких нарушений правил безопасности
не происходит'?
Мы предлагаем завести специальный журнал, в который вы будете записывать дан
ные о каждом сгенерированном ключе; об аппаратном и программном обеспечении,
используемом для этого; о дескрипторе, присвоенном ключу; о версии программного
генератора ключей; использованном алгоритме; длине ключа и сроке действия подписи.
Если впоследствии криптографический алгоритм окажется скомпрометированным, вы
сможете проверить свой журнал и выяснить, не подвергаетесь ли вы опасности.
Записи о ресурсах
DNSSEC
Протокол
в разделе
DNSSEC использует шесть типов записей о ресурсах, кратко описанных
16.4, - DS, DLV, DNSKEY, RRSIG, NSEC и NSECЗ. Сначала мы опишем их в це
лом, а затем очертим их использование в процессе подписания зоны. Каждая из этих
записей создается инструментами протокола
DNSSEC,
а не вводится в файл зоны с по
мощью текстового редактора.
Запись
DS (Designated Signer) возникает только в дочерней зоне и означает, что под
зона является безопасной (подписанной). Она также идентифицирует ключ, использу
емый дочерней зоной для подписания своего собственного набора записей о ресурсах
КЕУ. Запись
DS содержит идентификатор ключа (пятизначное число), криптографи
ческий алгоритм, тип дайджеста
(digest type)
и дайджест записи об открытом клю
че, разрешенном (или использованном) для подписи записи о ключе дочерней зоны.
Соответствующий пример приведен ниже. 22
example.com. IN
DS
682
5
1
12898DCF9F7AD20DBCE159E7 ...
Изменение существующих ключей в родительской и дочерней зонах является сложной
проблемой и требует сотрудничества и взаимодействия между родительской и дочерней
зонами. Для решения этой проблемы создаются записи
DS,
используются отдельные клю
чи для подписи ключей и зон, а также применяются пары многократных ключей.
Ключи, содержащиеся в записи о ресурсах
DNSKEY, могут быть либо ключами
для подписания ключа
(key-signing key - KSK), либо ключами для подписания зоны
(zone-sigпing key - ZSK). Для различия между ними используется новый флаг под на
званием SEP ("secure eпtry poiпt" - "точка безопасного входа"). Пятнадцатый бит поля
флагов устанавливается равным единице для ключа KSK и О - для ключа ZSK. Это со
глашение делает поле флагов нечетным числом для ключа KSK и четным для ключей
22 8 этом разделе 64-разрядные хеши и ключи были усечены, чтобы сэкономить пространство и
лучше проиллюстрировать структуру записей.
Глава
16. DNS: система доменных
ZSK,
если интерпретировать его как десятичное число. В настоящее время эти значения
равны
257
и
256
имен
575
соответственно.
Для обеспечения удобного перехода от одного ключа к другому можно генерировать
многократные ключи. Дочерняя зона может изменить свои ключи подписания зоны, не со
общая об этом родительской зоне. Она должна согласовывать с родительской зоной только
изменение ключа для подписания ключей. Когда ключ изменяется, и старый, и новый клю
чи на определенном отрезке времени считаются действующими. Как только срок действия
кешированных значений в Интернете истечет, старый ключ будет считаться отмененным.
Запись RRSIG -
это подпись набора записей о ресурсах (т.е. набора всех записей од
ного и того же типа и с одним и тем же именем внутри зоны). Записи RRSIG генериру
ются программным обеспечением, предназначенным для подписания зоны, и добавля
ются в подписанную версию файла зоны.
Запись
•
•
•
•
•
•
•
•
•
RRSIG содержит много информации.
Тип записей о ресурсах, входящих в подписываемый набор.
Алгоритм, используемый для подписания и закодированный небольшим числом.
Количество меток (фрагментов, разделенных точками) в поле имени.
Значение ТТL для подписываемого набора записей.
Срок действия подписи (в формате ггггммддччсссс).
Время подписания набора записей (также в формате ггггммддччсссс).
Идентификатор ключа (пятизначный номер).
Имя подписавшего (имя домена).
Сама цифровая подпись (64-разрядная).
от подписанных наборов записей, они сертифицируют интервалы между именами на
боров записей и тем самым позволяют подписывать ответ типа "нет такого домена" или
"нет такого набора записей о ресурсах". Например, сервер может ответить на запрос за
писей А с именем
bork. atrust. сот, послав запись NSEC, подтверждающую отсутствие
bork. atrust. сот и borrelia. atrust. сот.
любых записей А между именами
К сожалению, включение в записи
NSEC конечных точек позволяет обойти зону
и выяснить все ее действующие хосты. В версии NSECЗ этот недостаток был устранен пу
тем включения в запись хешированных имен конечных точек, а не самих имен. Правда,
это было сделано за счет более интенсивных вычислений: чем выше безопасность, тем
ниже производительность. В настоящее время используются как записи
NSEC,
так и за
писи NSECЗ, и вы должны будете сделать выбор между ними при генерировании своих
ключей и подписании своих зон.
Если защита от блуждания по зоне не является критически важной для вашей орга
низации, мы рекомендуем пока использовать запись
Настройка протокола
NSEC.
DNSSEC
Использование подписанных зон связано с двумя разными рабочими потоками: один
из них создает ключи и подписывает зоны, а второй обслуживает содержимое этих подпи
санных зон. Эти функции не обязательно реализовывать на одном и том же компьютере.
11. Работа
Часть
576
в сетях
На самом деле лучше изолировать закрытые ключи и процесс подписания зоны, сильно за
Jl)ужающий центральный процессор, на компьютере, который не доступен из Интернета.
(Разумеется, компьютер, обрабатывающий данные, должен быть виден из Интернета.)
На первом этапе настройки протокола
DNSSEC
следует организовать файлы зон
так, чтобы все файлы данных для зоны находились в одном каталоге. Это необходимо
для правильной работы инструментов, управляющих зонами по протоколу
Затем следует включить протокол
файла
example. сот пару 1024-битовых ключей ZSK, использующую ал
SHA-256, а также соответствующую пару 2048-битовых ключей KSK. 23
проблема, связанная с Оfl)аничением на предельный размер пакета UDP, вы
RSA
Серьезная
и
нуждает отдавать предпочтение коротким ключам для подписания зоны и часто их ме
нять. Для повышения уровня безопасности можно использовать более длинные ключи
для подписания ключей.
Генерирование ключей занимает немного времени
-
всего несколько секунд. Как
правило, Оfl)аничивающим фактором является не мощность центрального процессора,
а энтропия, доступная для рандомизации. В системе
счет дополнительных источников используется демон
Linux для повышения энтропии за
haveged, который повышает ско
рость генерирования ключей.
21 Рекомендации
на веб-сайте
разных организаций, касающиеся длин криптографических ключей, приведены
keylength.com.
глава
16. DNS:
Команда
577
система доменных имен
dnssec-keygen
выводит в стандартный поток вывода базовое имя файла
example. com - это имя ключа, 008 RSA/SHA-256, а 29718 и 05005 - хешированные
для сгенерированного ключа. В нашем примере
идентификатор набора алгоритмов
значения, которые называются идентификаторами ключей, слепками ключей или де
скрипторами ключей. При каждом запуске команда
Существует несколько алгоритмов шифрования, каждый из которых имеет свой диа
пазон длин ключей. Для того чтобы увидеть список доступных алгоритмов, можно вы
dnssec-keygen
полнить команду
без аргументов. Кроме того, сервер
BIND
может ис
пользовать ключи, сгенерированные другим программным обеспечением.
В зависимости от версии вашего программного обеспечения, имена некоторых до
ступных алгоритмов могут содержать имя NSECЗ в качестве префикса или окончания.
Если вы хотите использовать записи NSECЗ, а не
NSEC для подписания отрицатель
ных ответов, должны сгенерировать NSЕСЗ-совместимые ключи одним из NSЕСЗ
совместимых алгоритмов; подробности можно найти на справочной странице, посвя
щенной команде
dnssec-keygen.
. key содержит
Каждый файл
по одной записи о ресурсах
ный по ширине страницы. Его можно назвать ключом
равно
256,
а не
ехатрlе.сот.
DNSSEC
для сайта
Например, ниже приведен открытый ключ для подписания зоны, усечен
example. сот.
257,
как для ключей
ZSK,
потому что поле файлов
KSK.
IN DNSKEY 256 3 8 AwEAAcyLrgENt80J4PIQiv2ZhWwSviA ...
Эти открытые ключи должны быть вставлены в файлы зон с помощью директивы
$INCLUDE
или другим способом либо в конец, либо сразу после записи
SOA.
Для того
чтобы скопировать ключи в файл зоны, можно добавить их с помощью команды
cat24
и вставить с помощью текстового редактора.
В идеале закрытая часть любой пары ключей должна храниться в компьютере, отклю
ченном от сети, или хотя бы в компьютере, недоступном из Интернета. Для динамически
обновляемых зон это требование практически невыполнимо, а для ключей, предназначен
ных для подписания зон, еще и непрактично. Тем не менее для ключей, предназначенных
для подписания других ключей, данное требование абсолютно разумно, поскольку эти
ключи имеют долгий срок действия. Подумайте о скрытом главном сервере, недоступном
извне для ключей ZSК. Распечатайте закрытый ключ
KSK
или запишите его на флешку,
а затем спрячьте в сейфе, пока он не потребуется в следующий раз.
"Заперев" новые закрытые ключи, целесообразно записать информацию о новых
ключах в системный файл ключей. При этом не обязательно записывать туда сами клю
чи. Достаточно записать их идентификаторы, алгоритмы, дату, назначение и т.д.
По умолчанию срок действия подписи ограничен одним месяцем для записей
(ZSК-подписи наборов записей о ресурсах) и тремя месяцами для записей
подписи ключей
ZSK).
DNSSIG
RRSIG
(КSК
В настоящее время рекомендуется использовать 1024-битовые
ключи ZSK от трех месяцев до одного года, а 1280-битовые ключи KSK - от одного
до двух лет. 25 Поскольку рекомендуемые сроки действия ключей дольше, чем сроки, уста
новленные для них по умолчанию, эти параметры необходимо указывать явно при под
писании или периодическом переподписании зон, даже если сами ключи не изменились.
24 Исполыуйте
25 Рекомендации
веб-сайте
cat Кехтарlе. сот+*. key >> zonefile. Операция>> означает до
zonefile, а не его замену, как операция>. (Не перепугайте их!)
команду наподобие
бамение ключа в конец файла
разных организаций, касающиеся мин криптографических ключей, приведены на
keylength. сот.
578
Часть
11.
Работа в сетях
Подписание зоны
Итак, теперь, когда у вас есть ключи, вы можете подписывать зоны с помощью ко
манды dnssec-signzone, добавляющей записи RRSIG и NSEC или NSECЗ в каждый на
бор записей о ресурсах. Эти команды считывают оригинальный файл зоны и создают
отдельную подписанную копию с именем файл_ зоны.
Синтаксис команды dnssec-signzone для сервера
dnssec-signzone
[-о зона]
файл_зоны
[-N increment] [-k
signed.
BIND
имеет следующий вид.
КSК-файл]
[ZSК-файл]
где параметр зона по умолчанию равен файл_ зоны, а ключевые файлы по умолчанию
задаются командой
dnssec-keygen,
как описано выше.
Если имена ваших файлов зоны совпадают с именами зон, а имена ключевых файлов
не изменялись, то команда сокращается до следующего варианта:
dnssec-signzone [-N increment]
Флаг -N
increment
файл_зоны
автоматически увеличивает порядковый номер в записи SOA,
так что забыть это сделать будет невозможно. Кроме того, можно указать значение
unixtime, чтобы установить порядковый номер равным текущему времени UNIX (ко
личеству секунд, прошедших с 1 января 1970 года), или значение keep, чтобы предот
вратить изменение оригинального порядкового номера командой dnssec-signzone.
Порядковый номер увеличивается в файле подписанной зоны, но не в оригинальном
файле зоны.
Рассмотрим пример, в котором используются сгенерированные ранее ключи.
$ sudo dnssec-signzone -о example.com -N increment
-k Kexample.com+008+05005 example.com Kexample.com+008+29718
Подписанный файл упорядочивается в алфавитном порядке и содержит записи
DNSKEY, добавленные вручную, а также записи RRSIG и NSEC, сгенерированные в ходе
подписания. Порядковый номер зоны увеличен.
Если вы сгенерировали свои ключи с помощью алгоритма, совместимого с NSECЗ,
то должны подписать зону так, как показано выше, но указав флаг
-3 sal t.
Другие по
лезные опции команды dnssec-signzone приведены в табл.16.6.
Таблица 16.б. Флаги команды dnssec-siqnzone
Флаг
Описание
Генерирование записи (записей)
-g
os,
которая должна быть включена в роди
тельскую зону
-s
начальный_момент
-е конечный_момент
Установка момента времени, с которого подписи считаются действительными
Установка момента времени, после которого подписи считаются недействительными
Вывод статистических показателей
-t
Данные о сроках действия подписей можно выразить в виде абсолютного времени
в формате ггггммддччммсс или относительного времени, считая от текущего момен
та, в формате
+N,
где
N-
количество секунд. По умолчанию период действия подписи
юменяется от одного часа в прошлое до
30 дней
в будущее. Рассмотрим пример, в ко
тором мы указываем, что подписи должны быть действительными до окончания кален
дарного
2017
года.
$ sudo dnssec-signzone -N increment
-е
20171231235959 example.com
глава
16. DNS:
система доменных имен
579
Размеры файлов подписанных зон от четырех до десяти раз больше, чем размеры
файлов исходных зон, и все попытки навести логический порядок напрасны.
Строка
наподобие
rnail-relay
А
63.173.189.2
превращается в несколько следующих строк.
mail-relay.example.com.
57600
А
63.173.189.2
57600
RRSIG
А 8 3 57600 20090722234636 (
20150622234636 23301 example.com.
Y7s9jDWYuuXvozeU7zGRdFCl+rzU8cLiwoev
OI2TGfLlbhsRgJfkpEYFVRUB7kKVRNguEYwk
d2RSkDJ9QzRQ+w== )
NSEC
mail-relay2.example.com. А RRSIG NSEC
3600
3600
RRSIG
NSEC 8 3 3600 20090722234636 (
20150622234636 23301 example.com.
42QrXP8vpoChsGPseProBMZ7twf7eS5WK+40
WNsN84hFOnotymRxZRIZypqWzLIPBZAUJ77R
HPOhLfBDoqmZYw== )
С практической точки зрения файл подписанной зоны больше нельзя назвать по
нятным дпя человека и его невозможно отредактировать вручную из-за записей
RRSIG
и NSEC или NSECЗ. Этот файл не содержит ни одного фрагмента, который пользователь
мог бы изменить вручную!
За исключением записей
DNSSEC,
каждый набор записей о ресурсах (ресурсных за
писей с одинаковым типом и именем) получает одну подпись от ключа
ZSK.
о ресурсах DNSSEC подписываются как ключом
поэтому они
ZSK,
так и ключом
KSK,
Записи
содержат две записи RRSIG. Тем не менее 64-разрядное представление подписи заканчи
вается несколькими знаками равенства, потому что дпина записи должны быть кратной
четырем.
Как только ваша зона подписана, остается лишь указать сервер имен в подписан
ных версиях файлов зоны. Если вы используете сервер
zone,
соответствующую каждой зоне в файле
с ехатрlе. сот на ехатрlе. сот.
BJND, поищите инструкцию
named. conf, и измените параметр file
signed.
В заключение перезапустите демон сервера имен, заставив его прочитать снова
свой файл конфигурации. Для сервера
reconfig
и
BIND
следует выполнить команды
sudo rndc
sudo rndc flush.
Теперь мы обслуживаем подписанную зону
DNSSEC! Для того чтобы
внести измене
ния, вы можете отредактировать либо исходный неподписанный файл зоны, либо под
писанный файл зоны, а затем переподписать зону. Редактирование подписанной зоны
иногда оказывается чрезвычайно сложной задачей, но это проще, чем повторное под
писание всей зоны. Удалите записи RRSIG, соответствующие всем изменяемым записям.
Для того чтобы избежать путаницы между версиями, вероятно, следует внести идентич
ные изменения в неподписанную зону.
При передаче подписанной зоны в качестве аргумента команде
dnssec-signzone
все неподписанные записи подписываются, а подписи всех записей, срок действия ко
торых подходит к концу, обновляются. Выражение "срок действия подходит к концу"
означает, что прошло три четверти периода действия подписи. Повторное подписа
ние, как правило, приводит к изменениям, поэтому следует изменить порядковый но
мер зоны вручную или автоматически с помощью сервера
-N increment
в командной строке
dnssec-signzone.
BIND,
используя паратмер
Часть
580
Это все, что касается локальной части конфигурации протокола
11.
Работа в сетях
DNSSEC.
Осталось
только решить трудную проблему: соединить наш безопасный "DNS-островок" с дру
гими надежными и подписанными частями иерархии
наши записи
DS
DNS.
Мы должны либо передать
в подписанную родительскую зону, либо использовать динамическую
проверку доменов. Решение этих задач описывается в следующем разделе.
Цепочка доверия в протоколе
DNSSEC
Продолжим наш пример, связанный с настройкой протокола
example. сот
DNSSEC. Сайт
DNSSEC.
EDNSO, расширенный
теперь подписан, и его серверы имен поддерживают протокол
Это значит, что при отправке запросов они используют протокол
протокол
DNS,
DNSSEC.
Отвечая на запросы, которые приходят с таким установленным битом в за
а в DNS-заголовке пакета устанавливают флаг, включающий протокол
головке, они включают в свой ответ подписанные данные.
Клиент, получающий подписанные запросы, может оценить корректность ответа,
проверив его подпись с помощью соответствующего открытого ключа. Однако он полу
чает этот ключ опять же из записи зоны
DNSKEY,
что, если вдуматься, довольно подозри
тельно. Что может помешать постороннему лицу предоставить ложные записи и лож
ный открытый ключ, чтобы пройти проверку'!
Каноническое решение заключается в том, чтобы передать вашей родительской зоне
запись DS, которую она должна включить в свой файл зоны. Запись DS, приходящая из
родительской зоны, сертифицируется родительским закрытым ключом. Если клиент
доверяет своей родительской зоне, он должен верить в то, что запись DS родительской
зоны правильно отражает открытый ключ вашей зоны.
В свою очередь, родительская зона сертифицируется своей родительской зоной и так
вплоть до корня.
Смена ключей
Для протокола
DNSSEC
DNSSEC
смена ключей всегда была трудной задачей. Его исходные
спецификации были, по существу, изменены для того, чтобы решить проблемы, связан
ные с обеспечением взаимодействия между родительской и дочерней зонами для созда
ния, изменения или удаления ключей. Новые спецификации называются DNSSEC-Ьis.
Смена ключей
ZSK
представляет собой относительно несложную задачу и не преду
сматривает наличия родительской зоны или какой-либо точки доверия. Единственным
"скользким" местом является расписание. Ключи имеют определенный срок действия,
поэтому их замену необходимо производить до истечения этого срока. Однако ключи
имеют период ТТL, определенный в файле зоны. Для иллюстрации предположим, что
период ТТL равен одному дню и что ключи на следующей неделе еще будут действовать.
Придется выполнить следующие действия.
•
•
•
Сгенерировать новый ключ
ZSK.
Включить его в файл зоны.
Впервые или повторно подписать зону с помощью ключа
KSK либо старого ключа
ZSK.
•
Попросить сервер имен перезагрузить зону; теперь в ней будет действовать новый
ключ.
•
Подождать
24 часа
так и новый.
(период ТТL); теперь все могут использовать как старый ключ,
Глава
16. DNS: система
доменных имен
581
•
•
•
Подписать зону снова с помощью ключа
•
Удалить старый ключ
KSK
и нового ключа
ZSK.
Попросить сервер имен перезагрузить зону.
Подождать
24
часа; теперь все имеют новую зону.
ZSK,
например при следующем изменении зоны.
Эта схема называется предварительной публикацией (prepuЫishing). Совершенно оче
видно, что до того, пока все будут использовать новый ключ, приходится запускать этот
процесс как минимум дважды после истечения двух периодов
TTL.
Эти периоды ожи
дания гарантируют, что любой сайт с кешированными значениями всегда будет иметь
кешированный ключ, соответствующий этим кешированным данным.
Еще одной переменной, которая влияет на этот процесс, является время, которое
потребуется вашему самому слабому подчиненному серверу для обновления своей ко
пии вашей зоны после получения уведомления от главного сервера. По этой причине не
следует ждать до последней минуты, чтобы начать процесс смены ключей или повторно
го подписания зон, срок действия подписей которых истек. Просроченные подписи не
действительны, поэтому сайты, проверяющие подписи
DNSSEC,
не смогут выполнить
поиск имен для вашего домена.
Механизм смены ключей
KSK
называется двойным подписанием (douЫe
signing)
и так
же довольно прост. Однако вам придется переслать новую запись DS родительской зоне
DLV своему "суррогатному родителю". Убедитесь, что родительская
или послать запись
зона или репозитарий точек доверия вас признали, прежде чем переключиться на новый
ключ. Процесс смены ключей
KSK состоит
из следующих этапов.
•
•
•
•
•
Создать новый ключ
•
•
Уведомить все точки доверия о новом значении
•
Заново подписать зону новыми ключами
KSK.
Включить его в файл зоны.
Подписать зону и новым, и старым ключами
KSK
и
ZSK.
Попросить сервер имен перезагрузить зону.
Подождать
24
часа (период ТТL); теперь у всех есть новый ключ.
После подтверждения удалить старую запись
Инструменты
KSK.
KSK из зоны.
KSK
и
ZSK.
DNSSEC
В дистрибутивный набор BIND 9.10 входит новый инструмент для отладки. Domain
Entity Lookup and Vcllidation Engine (DELV) выполняет поиск аналогично утилите diq,
но при этом он лучше согласован с протоколом DNSSEC. Фактически утилита delv
проверяет цепочку доверия DNSSEC с помощью того же самого кода, который исполь
зует демон named в пакете BIND 9.
Кроме инструментов DNSSEC, поставляемых с пакетом BIND, существует четыре
набора инструментов для развертывания и тестирования: ldns, DNSSEC-Too\s (бывший
Sparta), RIPE и OpenDNSSEC (opendnssec. org).
Инструменты
ldns,
nlnetlaЬs.
nl/projects/ldns
По словам сотрудников компании
для разработки инструментов
DNS,
NLnet Labs, ldns -
это библиотека программ
включающая примеры, демонстрирующие исполь
зование этой библиотеки. Эти инструменты перечислены ниже вместе с кратким описа-
Часть
582
нием каждого из них. Все они находятся в каталоге
drill,
exaaples,
11. Работа
в сетях
за исключением уrилиты
имеющей свой собственный каталог в дистрибуrивном пакете. Команды сопро
вождаются справочными страницами. Файл READМE, относящийся к верхнему уровню
иерархии каталогов, содержит очень краткие инструкции по инсталляции.
• ldns-chaos показывает идентификатор сервера имен, хранящийся в классе CHAOS.
• ldns-compare-zones демонстрирует
разницу между двумя файлами зон.
• ldns-dpa анализирует
помощью файлов слежения
пакеты
DNS с
• ldns-key2ds
преобразовывает запись
• ldns-notify
проверяет обномения подчиненных серверов зон.
tcpdwnp.
DNSSEC в запись DS.
• ldns-keyfetcher извлекает открытые ключи DNSSEC для зон.
• ldns-keygen генерирует пары ключей TSIG и DNSSEC.
•
ldns-nsecЗ-hash распечатывает запись
NSEC
для заданного имени в хеширо
ванном виде.
• ldns-read-zone читает
зону и распечатывает ее в разных форматах.
• ldns-revoke устанавливает флаг отмены для
документ RFC540l l).
• ldns-rrsig
DNSSEC
(см.
распечатывает в удобном для чтения виде даты истечения сроков
зону на фрагменты, чтобы подписывать их параллельно.
Многие из этих инструментов очень просты и выполняют только одну рутинную
-операцию для системы
библиотеки
ldns
DNS.
Они были написаны в качестве примеров использования
и демонстрируют, насколько простым становится код, когда библиоте
ка берет всю тяжелую работу на себя.
Инcmpyмeнmыdnssec-tools.org
Комплект инструментов
BIND,
DNSSEc-Tools
создан на основе инструментов сервера
предназначенных для поддержки протокола
DNSSEC,
и включает в себя следу
ющие команды.
• dnspktflow отслеживает
поток пакетов
ветов, перехваченных командой
DNS в последовательности
tcpdwnp, и создает диаграмму.
запросов и от
• donuts анализирует файлы зон в поисках ошибок и несоответствий.
• donutsd выполняет команду donuts через определенные интервалы
времени
и предупреждает о проблемах.
• mapper
отображает файлы зон, демонстрируя защищенные и незащищенные
фрагменты.
• rollerd, rollctl
и
rollini t
осуществляют автоматическую смену ключей, ис
пользуя схему предварительной публикации для ключей
подписания для ключей
KSK.
ZSK
и метод двойного
Глава
16. DNS:
583
система доменных имен
• trustman управляет точками доверия и включает реализацию смены
RFC501 l.
• validate - инструмент для проверки подписи из командной строки.
• zonesigner генерирует ключи и подписи зон.
клю•1ей
Веб-сайт содержит хорошую документацию и учебные пособия для всех этих инстру
ментов. Исходный код доступен для загрузки и защищен лицензией
Инструменты
RIPE, ripe. net
Инструменты компании
тов пакета
BSD.
BIND,
RIPE
функционируют как внешний компонент инструмен
предназначенных для поддержки протокола
DNSSEC,
и основное
внимание уделяют вопросам управления. Их подробные сообщения при выполнении
и упаковке многих аргументов и команд имеют более понятную форму.
Инструменты Ореп
OpenDNSSEC -
DNSSEC, opendnssec. org
это набор инструментов, которые получают неподписанные зоны,
добавляют подписи и другие записи для протокола
DNSSEC,
а затем передают их авто
ритетным серверам имен для этой зоны. Эта автоматизация значительно упрощает на
чальную настройку протокола
Отладка протокола
Протокол
DNSSEC
DNSSEC.
DNSSEC
был разработан для того, чтобы обеспечить взаимодействие меж
ду подписанными и неподписанными зонами, а также между серверами имен, поддер
живающими протокол
DNSSEC
и игнорирующими его. Следовательно, возможно по
степенное развертывание протокола, что часто и происходит, хотя и не всегда.
DNSSEC -
это распределенная система с многочисленными изменчивыми частями.
Все проблемы порождают авторитетные серверы, распознаватели клиентов и линии свя
зей между ними. Проблема, которая кажется локальной, может отразиться на удаленном
пользователе, поэтому такие инструменты, как SecSpideг и
Yantages,
отслеживающие
распределенное состояние системы, могут оказаться очень полезными. Эти инструмен
ты, а также утилиты, перечисленные выше, и регистрационные файлы вашего сервера
имен являются основными орудиями отладки.
Сначала убедитесь, что вы перенаправили категорию вывода журнала регистрации
по протоколу
DNSSEC,
указанную в файле
named. conf,
в файл на локальном компью
тере. Полезно отделить все сообщения, связанные с протоколом
DNSSEC,
чтобы не за
писывать в этот файл никаких других категорий журнала регистрации. Рассмотрим при
мер спецификации журнала регистрации для демона
Если сервер имен, выполняющий проверку, не может проверить подпись, он воз
вращает сигнал
SERVFAIL.
Проблема может заключаться в неправильной конфигурации
одной из зон, входящих в цепочку доверия, в фальшивых данных, поступивших от зло
умышленника, или в настройке самого рекурсивного сервера, выполняющего проверку.
Попробуйте выполнитькоманду
drill
и отследить подписи вдоль цепочки доверия,
чтобы обнаружить источник проблемы.
Если все подписи окажутся верифицированными, то попытайтесь послать запрос
проблемному сайту с помощью команды
dig,
а затем
dig +cd.
(Флаг
cd отключает
про
верку подписей.) Примените их к каждой зоне, входящей в цепочку доверия, чтобы вы
яснить, в чем проблема. Вы можете перемещаться по цепочке доверия как вверх, так
и вниз. Чаще всего причиной ошибки становятся устаревшие точки доверия или про
сроченные подписи.
16.11. ОТЛАДКА СЕРВЕРА BIND
Сервер
BIND
предоставляет три основных инструмента для отладки: журнальная ре
гистрация, управляющая программа и инструмент запросов их командной строки.
Журнальная регистрация на сервере
Ш Система
BIND
Syslog описывается в главе 1О.
Возможности подсистемы журнальной регистрации демона
впечатляют. Сервер
BIND
использует систему
Syslog
named
действительно
для записи сообщений об ошиб
ках и аномалиях. В новейших версиях концепция журнальной регистрации обобщена:
добавлен еще один уровень переадресации и поддерживается направление сообщений
непосредственно в файлы. Прежде чем переходить к деталям, приведем мини-словарь
терминов, связанных с журнальной регистрацией в пакете
BIND
(табл.
16.7).
Глава
16. DNS: система
Таблица
доменных имен
585
16.7. Лексикон пакета BIND
Термин
Что означает
Канал
Место, куда направляются сообщения,
Категория
Класс сообщений, генерируемых демоном
новлениях или об ответах на запросы
Модуль
Имя исходного модуля, который сгенерировал сообщение
Название средства системы
Средство
Syslog;
за
-
система
Syslog,
файл или устройство
/dev/null"
named, например сообщения о динамических об
DNS не закреплено собственное средство,
но можно
выбрать любое стандартное
Степень важности сообщения об ошибке
Важность
'/dev/null/ - псевдоустройство, отбрасывающее всю входящую информацию.
Подсистема журнальной регистрации конфигурируется при помощи инструкции
logging
в файле
named. conf.
Сначала определяются каналы
-
возможные пункты до
ставки сообщений. Затем для различных категорий сообщений задаются каналы, куда
они будут поступать.
При формировании сообщения ему назначаются категория, модуль и уровень важ
ности. После этого оно рассылается по всем связанным с категорией и модулем ка
налам. В каждом канале имеется фильтр, определяющий, сообщения какого уровня
важности можно пропускать. Каналы, ведущие в систему
Syslog,
подвергаются допол
нительной фильтрации в соответствии с правилами, установленными в файле
/etc/
syslog. conf.
Общий вид инструкции
logging
таков.
logging {
определение_канала
определение_канала
category
имя_категории
имя
канала
имя
канала
};
};
Каналы
Аргумент определение_канала выглядит по-разному, в зависимости от того, ве
};
Для файлового канала аргумент число_ версий сообщает о том, сколько резервных
копий файла нужно хранить. Аргумент размер задает предельно допустимый размер
файла (например,
2048, lOOk, 20rn, 15g, unlirnited, default),
по достижении кото-
Часть
586
11.
Работа в сетях
рого произойдет автоматическая ротация. К примеру, если файловый канал называется
mylog,
то в процессе ротации появятся версии
Для каналов системы
Syslog задается
mylog. О, mylog .1
и т.д.
имя средства, указываемое при регистрации со
общений. Это может быть любое стандартное средство, но на практике единственным
разумным выбором являются средства
daemon
и
localO-local 7.
m Список средств системы Syslog приводился в главе 10.
Остальные разделы в определении канала являются необязательными. Аргумент
важность может принимать следующие значения (в порядке уменьшения приорите
та):
cri tical, error, warning, notice, info и debug (здесь может добавляться но
severi ty debug 3). Значение dynamic соответствует текущему
мер уровня, например
уровню отладки сервера.
Параметры
print
общений. Система
устанавливают или отменяют вывод различных префиксов со
Syslog
вставляет перед каждым сообщением метку времени, а также
имя хоста, но не уровень важности или категорию. Существует также параметр, по
зволяющий отображать имя исходного файла (модуля), сгенерировавшего сообщение.
Параметр
ку в
print-time
Syslog
В табл.
рекомендуется включать только для файловых каналов, посколь
произойдет ненужное дублирование информации.
16.8 перечислены
четыре канала, которые определены по умолчанию. В боль
шинстве случаев создавать новые каналы не требуется.
Таблица
16.8.
Стандартнь1е каналы журнальной регистрации пакета
Имя канала
BIND
Назначение
def ault _syslog
Направляет сообщениs~ уровнs~
info
и выше в систему
Syslog от имени
средства
daemon
de f а ul t _ debug
Направляет сообщениs~ в файл
равным
defaul t stderr
named. run;
уровень важности устанавливаетсs~
dynamic
Направляет сообщениs~ в стандартный канал ошибок демона
важности
named с уровнем
i nf о
Отбрасывает все сообщения
null
Категории
В момент создания программы категории определяются программистом. Они орга
низовывают сообщения по темам или функциональным возможностям, а не по важно
сти. В табл.
Таблица
16.9 приведен
16.9.
текущий список категорий сообщений.
Категории сообщений пакета
Категория
Что ох11ты1ает
client
Клиентские запросы
BIND
config
Ошибки анализа и обработки конфигурационного файла
database
Сообщения об операциs~х с базой данных
defaul t
Категории, для которых не был явно назначен канал
delegation-only
dispatch
Диспетчеризация входs~щих пакетов среди модулей сервера
dnssec
Сообщения протокола
edns-disaЫed
Информация о серверах, вышедших из строя
Запросы, посланные в
NXDOMAIN
зонами, выполняющими только делегирование
DNSSEC
Глава
16. DNS: система
доменных имен
587
Окнчание табл.
16.9
Категория
Что охватывает
general
lame-servers
Сообщения о серверах, которые, как предполагается, обслуживают зону, но на са-
Неклассифицированные сообщения
мом деле зто не так•
network
notify
queries
resolver
Сетевые операции
Сообщения об изменениях зон
Короткое сообщение для каждого(!) запроса, принимаемого сервером
Операции преобразования имен, например рекурсивный поиск, выполняемый
от имени клиента
security
unmatched
Принятые или непринятые запросы
Запросы, которые демон
named не
может классифицировать (неправильный класс,
нет представления)
Сообщения о динамических обновлениях
update
update-securi ty
xfer-in
xfer-out
0 Это
Одобрение или отклонение запросов на обновление
Сообщения о передачах зон
Сообщения о передачах зон
, принимаемых сервером
, отправляемых сервером
может быть как родительская, так и дочерняя зона.
Журнал запросов
Стандартный вид инструкции
logging
таков.
logging {
category default ( default_syslog; default debug; );
);
После внесения существенных изменений в систему
BIND
необходимо просматри
вать журнальные файлы; возможно, стоит также повышать уровень отладки. После того
как демон
named
вернется в стабильное состояние, настройте систему так, чтобы реги
стрировались только важные сообщения.
Журнал запросов
-
источник весьма полезной информации. На его основании мож
но проверить, работают ли директивы
allow,
узнать, кто посылает вам запросы, иден
тифицировать неправильно сконфигурированные клиенты и т.д.
Для того чтобы включить режим регистрации запросов, назначьте категории
какой-нибудь канал. Регистрация в системе
Syslog менее
queries
эффективна, чем непосредствен
но в файле, поэтому при регистрации каждого запроса создайте файловый канал, связан
ный с локальным диском. Зарезервируйте для журнала достаточно дискового простран
ства и будьте готовы отключить регистрацию, когда накопится достаточный объем данных
(команда
rndc querylog включает
и отключает регистрацию запросов).
Иногда отладка представления является довольно сложной задачей, но, к счастью,
представление, соответствующее конкретному запросу, можно занести в журнал вместе
с запросом.
Ниже перечислены наиболее часто регистрируемые сообщения.
•
Неправильно сконфигурированный сервер
("Lame server resolving
ххх"). Если по
добное сообщение поступает от одной из внутренних зон, значит, в конфигура
ции системы имеется ошибка. Если же в сообщении говорится о какой-то зоне
в Интернете, то можно не беспокоиться: это "чужая" ошибка. Сообщения второго
вида вполне можно отбрасывать, направляя их в канал
null.
Часть
588
•
Отклонение запроса
("".query (cache)
ххх
11. Работа
в сетях
Причиной этого сообщения мо
denied").
жет быть неправильная конфигурация удаленного сайта, нарушение правил или
ситуация, в которой некто делегировал вам зону, но вы ее не конфигурировали.
•
Просроченное время при распознавании: отключение
resolving
ххх: disaЫing
каза брандмауэра, не пропускающего пакеты
512
EDNS ("too many timeouts
Это сообщение может возникнуть вследствие от
EDNS").
размер которых превышает
UDP,
байт, и не допускающего фрагментирование. Кроме того, оно может свиде
тельствовать о проблемах на конкретном хаете. Следует убедиться, что проблема
не связана с вашим брандмауэром, и рассмотреть возможность переадресации
этих сообщений в нулевой канал.
•
Неожиданное распознавание
resolving
RCODE (SERVFAIL) ("unexpected RCODE (SEVFAIL)
ххх"). Это сообщение может быть признаком атаки или, что более ве
роятно, сигналом о том, что кто-то постоянно посылает запросы к неправильно
сконфигурированной зоне.
•
Неправильная отсылка
Это сообщение свидетельствует о непра
("Bad referral").
вильном взаимодействии серверов имен зоны.
•
Неавторитетен
("Not authoritative for").
Подчиненный сервер не может получить
авторитетные данные о зоне. Возможно, у него хранится неправильный адрес
главного сервера или же тот не смог загрузить зону.
•
Зона отклонена
("Zone rejected").
Демон
named
отказался загружать файл зоны,
поскольку тот содержит ошибки.
•
Не найдены записи
записи
NS.
NS ("No NS RR for").
В файле зоны после записи
SOA не
найдены
Возможно, они отсутствуют либо не начинаются с табуляции или како
го-нибудь другого пробельного символа. Во втором случае они не присоединяются
к зоне и, следовательно, интерпретируются неправильно.
•
Не задано стандартное значение
стандартное значение
TTL
TTL ("No default
ТТL
посредством директивы
set").
$TTL,
Желательно задавать
располагаемой в нача
ле файла зоны. Ошибка свидетельствует о том, что такая директива отсутствует.
В версии
•
BIND 9 наличие
этой директивы обязательно.
Нет корневых серверов имен для класса
("No root nameservers for class").
Демону
не удается найти корневые серверы имен. Следует проверить файл корне
named
вых "подсказок" и подключение сервера к Интернету.
•
Адрес уже используется
демона
named,
("Address already in use").
Порт, который нужен для работы
занят другим процессом, возможно, другой копией демона. Если де
мон отсутствует в списке выполняющихся процессов, то, очевидно, он перед этим
аварийно завершил свою работу и оставил открытым управляющий сокет утилиты
rndc,
который нужно найти и удалить. Хороший способ устранить проблему
остановить процесс с помощью утилиты
rndc
и перезапустить процесс
-
named.
$ sudo rndc stop
$ sudo /usr/sЬin/named ...
•
Обновление не выполнено
("".updating zone
ххх:
update unsuccessful").
Имела место
попытка динамического обновления зоны, которая была отвергнута вследствие
установки
allow-update
или
update-policy для
зоны в файле
named. conf.
Это
очень распространенное сообщение об ошибке, которая часто вызывается непра
вильной конфигурацией системы
Windows.
Глава
16. DNS: система
доменных имен
589
Пример конфигурации журнала запросов в пакете BIND
Приведенный ниже фрагмент взят из файла
веров имен
TLD
named. conf одного
из загруженных сер
и представляет собой полную конфигурацию журнала запросов.
число, тем больше текста содержит выходная информация. Уровень О выключает отлад
ку. Уровни
1 и 2 отлично подходят для отладки конфигурационного файла и базы дан
4 предназначены для разработчиков кода демона.
Отладку можно включить из командной строки, запуская демон named с флагом -d.
ных. Уровни выше
Например, команда
# sudo named -d2
запускает демон
named на уровне отладки 2. По умолчанию отладочная информация за
named. run, находящийся в каталоге запуска демона. Этот файл рас
писывается в файл
тет очень быстро, поэтому во время отладки будьте внимательны.
Отладку можно также включать в процессе работы демона
named с помощью ко
rndc trace, которая увеличивает уровень отладки на единицу. Команда rndc
notrace выключает режим отладки. Кроме того, можно создать канал регистрации со
манды
общений, в определение которого входит строка следующего вида.
severity debug 3;
Эта строка обеспечивает направление в канал всех отладочных сообщений вплоть
до уровня
3.
Другие директивы в определении канала указывают на то, куда в конечном
590
Часть
11. Работа
в сетях
итоге попадут сообщения. Чем выше уровень важности, тем больше информации реги
стрируется.
Просматривая журнальные файлы и отладочные сообщения, можно заметить, как
часто делаются ошибки в конфигурации
DNS.
Забыв поставить точку в конце имени,
можно спровоцировать угрожающий рост трафика
DNS.
Помните: точка нужна в конце
каждого полностью определенного имени домена.
Управление сервером имен с помощью команды
Опции команды
rndc
перечислены в табл.
16.1 О.
rndc
Если ввести имя команды
rndc
без
аргументов, то она выведет на экран список доступных подкоманд и их краткое описа
ние. В предыдущих версиях программы
rndc
использовались сигналы. Однако количе
ство доступных подкоманд уже "перевалило" за
25,
поэтому разработчики пакета
BIND
отказались от использования сигналов. Подкоманды, приводящие к созданию файлов,
размещают их в каталоге, указанном в файле
на
named. conf
как начальный каталог демо
named.
Таблица
16.1 О.
Опции команды
rndc8
Инструкция
Назначение
duшpdЬ
flush
Записывает образ базы данных
(представление]
flushname
freeze
имя [представление)
зона [класс [представление]]
thaw зона
halt
[класс [представление]]
DNS в файл named_ duшp . dЬ
Очищает все кеши или кеши, заданные представлением
Удаляет имя из кеша сервера
Приостанавливает обновления динамической зоны
Возобновляет обновления динамической зоны
Останавливает демон
named без обработки
отложенных
обновлений
querylog
notify зона
notrace
Переключает режим трассировки входящих запросов
(класс [представление]]
Повторно посылает зоне уведомления
Отключает режим отладки
reconf ig
Повторно загружает конфигурационный файл и все новые
зоны
recursing
Записываеттекущие рекурсивные запросы в файл
named.
recursing
refresh зона
[класс (представление]]
Повторно загружает файл
reload
reload зона
Планирует обновления для зоны
[класс [представление]]
named. conf и
файлы зон
Повторно загружает только указанную зону или
представление
retransfer зона
[класс
Повторно копирует данные для зоны из главного сервера
[представление]]
stats
Записывает статистическую информацию в файл
named.
stats
status
Отображает на экране текущий статус выполнения демона
named
stop
Сохраняет отложенные обновления и останавливает демон
named
Глава
16. DNS: система
591
доменных имен
Окончание табл.
Инструкция
Назначение
trace
Увеличивает уровень отладки на единицу
trace приращение
Увеличивает уровень отладки на приращение
validation новое
16.10
Включает/отключает проверку DNSSEC на лету
состояние
•Аргумент класс означает то же, что и в случае записей о ресурсах; для Интернета он обычно равен IN.
Команда
rndc reload
заставляет демон
named
заново прочитать конфигураци
онный файл и повторно загрузить файлы зон. Команду
reload
зона удобно приме
нять на интенсивно эксплуатируемом сервере, когда изменению подвергается толь
ко одна зона, а остальные трогать не нужно. Кроме того, можно задать параметры
класс и представление, чтобы загрузить только указанное представление данных
зоны.
Обратите внимание на то, что команды
rndc reload
недостаточно, чтобы доба
вить совершенно новую зону; для этого требуется, чтобы демон
named прочитал файл
named. conf и новый файл зоны. Для новых зон следует использовать команду rndc
reconfig, которая заново прочитывает файл конфигурации и загружает любую новую
зону, не трогая суrnествующие.
Команда
rndc freeze
зона останавливает динамические обновления и согласо
вывает журнал динамических обновлений с файлами зон. После замораживания зоны
ее данные можно редактировать вручную. Поскольку зона заморожена, динамическое
обновление происходить не будет. Завершив редактирование, выполните команду
thaw
rndc
зона, чтобы принимать динамические обновления снова.
Команда
в файл
rndc dumpdЬ заставляет демон named записать образ своей базы данных
named_ dump. dЬ. Этот файл очень большой и содержит не только локальные дан
ные, но и данные, накопленные в кеше сервера имен.
Версии демона
named
и программы
rndc должны
со1шадать, иначе будет выдано со
общение о несовпадении версий протокола. Обычно они устанавливаются на один и тот
же компьютер, и расхождение версий может вызвать проблемы, если попытаться управ
лять демоном
named,
запущенном на другом компьютере.
Некорректное делегирование
Подавая заявку на регистрацию доменного имени, вы просите, чтобы основному
серверу имен и администратору
DNS
была выделена (делегирована) часть дерева имен.
Если не поддерживать работу домена или изменить адреса серверов имен, не обновив
связующие записи родительского домена, будет иметь место так называемое некоррект
ное делегирование
(lame delegation).
Последствия некорректного делегирования могут оказаться весьма негативными.
Если хотя бы один из ваших серверов окажется некорректным, то вся ваша система
DNS
снизит эффективность работы. Если все серверы имен являются некоррект
ными, то ни один из них не будет доступен. Все запросы будут начинаться с кор
ня, пока ответы будут кешироваться, поэтому некорректные серверы и неисправное
программное обеспечение, которое не делает негативного кеширования ошибок
SERVFAIL, увеличивают нагрузку на каждый хост, находящийся на пути от корня
к некорректному домену.
Некорректное делегирование можно обнаружить с помощью инструмента под назва
нием
doc (domain obscenity control -
проверка корректности домена) либо путем не-
Часть
592
11. Работа
в сетях
посредственного просмотра записей из журнальных файлов. 26 Рассмотрим пример реги
страционных записей.
Jul 19 14:37:50 nubark naтed[757]:
'w3w3.coт'?): 216.117.131.52#53
Послав с помощью команды
му из серверов gТLD-домена
dig
. сот,
lате
server resolving
'w3w3.coт'
(in
запрос о серверах имен для домена wЗwЗ. сот одно
мы получим следующую информацию.
$ d.ig @e.gtld-servers.net wЗwЗ.com ns
;; ANSWER SECTION:
w3w3.coт
172800 IN NS nsO.naтeservices.net.
w3w3.coт
172800 IN NS nsl.naтeservices.net.
Если же теперь опросить каждый из этих серверов по очереди, задав им этот же во
прос, то мы получим ответ от сервера
$ d.ig @nsO.nameservices.net
;; ANSWER SECTION:
14400 IN
w3w3.coт
14400 IN
w3w3.coт
NS
NS
nsO и
ns
не получим ответа от сервера
nsl.
wЗwЗ.com
nsO.naтeservices.net.
nsl.naтeservices.net.
$ d.ig @nsl.nameservices.net w3w3.com ns
,, QUESTION SECTION:
,, w3w3.coт.
IN IN
, , AUTHORITY RECORDS:
92152 IN NS
сот.
92152 IN NS
сот.
92152 IN NS
сот.
nsl. naтeservices. net делегировал ответственность за домен wЗwЗ.
. сот, но они эту ответственность не приняли. Эта конфигурация
сот серверам домена
является неправильной, и возникло некорректное делегирование. Клиенты, пытающи
еся попасть в домен wЗwЗ. сот, будут обслуживаться медленно. Если домен wЗwЗ. сот
оплачивает услуги
DNS домену
naтeservices.
net,
Иногда, посылая запрос с помощью команды
то он заслуживает компенсации!
dig
на авторитетный сервер в поисках
некорректности, можно не получить никакой информации. В этом случае следует по
пытаться повторить запрос с флагом
+norecurse,
чтобы можно было увидеть точно, что
знает искомый сервер.
16.12. ЛИТЕРАТУРА
Система доменных имен и пакет
BIN D описаны
во многих источниках, включая до
кументацию, входящую в состав пакета, отдельные главы в книгах об Интернете, целую
книгу серии
ln
а
Nutshell
издательства
O'Reilly,
а также многочисленные ресурсы в гло
бальной сети.
26
80
многих организациях в качестве канала laтe-servers для журналов регистрации указан ка
талог
/dev/null,
чтобы не беспокоиться о некорректном делегировании других доменов, не при
надлежащих этой организации. Это допустимо, если ваш домен находится в полном порядке и не
является ни источником, ни жертвой некорректного делегирования.
Глава
16. DNS: система
доменных имен
593
Книги и другая документация
BIND DEVELOPMENT ТЕАМ. BINDv9 Administrator Reference Manual.
BIND (doc/arm), а также доступен на веб-сайте
ТнЕ Noм1NUM
•
Документ включен в дистрибутив
www. isc. org.
кета BIND 9.
•
В нем в общих чертах описаны принципы администрирования па
PлuL АLвпz.
В/ND
(5th Edition). Sebastopo\,
Lщ СR1скЕт,
AND
Media, 2006.
Эта книга стала настольным справочником по серверу
DNS and
СА:
O'Reilly
BIND, хотя
и написана довольно тяжелым языком.
Lщ
•
CRICKET. DNS &
В/ND
Cookbook. Sebastopo\, СА: O'Reilly Media, 2002.
O'Reilly о системе DNS, содержащая
упрощенная версия книги издательства
Это
чет
кие инструкции и примеры работы с серверами имен. Довольно старая, но все еще
полезная.
Lщ СR1скп.
•
DNS and В/ND оп !Рvб. Sebastopol, СА: O'Reilly Media, 2011.
DNS и BIND в рамках протокола IPvб. Она невелика и
ориентирована на
Книга
содер
жит исключительно материал, связанный с протоколом IPvб.
Lucлs, М1снлн W DNSSEC Mastery: Securing the Domain Name System with BJND.
Grosse Point Woods, MI: 1ilted Windmill Press, 2013.
•
Ресурсы в Интернете
Веб-сайты
org
и
isc.org, dns-oarc.net, ripe.net, nlnetlabs.nl, f.root-servers.
k. root-servers. org содержат много информации о системе DNS, исследовани
ях, результатах измерений, презентациях и др.
DNS, записях о ресурсах и других аспектах
iana. org / assignments/dns-parameters. Этот документ со
держит информацию о том, в каком документе RFC описан тот или иной факт, касаю
щийся работы системы DNS.
Справочник DNSSEC НОWТО, написанный Олафом Колкманом (O\af Kolkman), Подробная информация о протоколе
DNS
приведена на сайте
это 70-страничный документ, в котором изложены все аспекты развертывания и отлад
ки протокола
DNSSEC.
dnssec howto. pdf.
Документы
Его можно загрузить с сайта
nlnetlabs. nl/ dnssec _ howto/
RFC
RFC, в которых описывается система доменных имен, доступны на веб
www. rfc-edi tor. org. Мы использовали только самые важные из них, хотя в на
стоящее время есть около 100 документов и около 50 черновиков, опубликованных
в Интернете, поэтому рекомендуем читателям зайти на сайт www. rfc-edi tor. org и из
Документы
сайте
учить весь архив.
Для того чтобы увидеть все документы, касающиеся текущей версии
каталоги
doc/rfc
и
doc/draft.
BIND,
найдите
Глава
17
Система единого входа
Пользователи и системные администраторы хотели бы, чтобы информация
об учетной записи волшебным образом распространялась на все компьютеры сети
и пользователь мог войти в любую систему с одинаковыми учетными данными. Эта
функция называется "единым входом"
(single sing-on - SSO)
и потребность в ней
повсеместна.
SSO
включает в себя две основные концепции безопасности: идентификацион
ную информацию и аутентификацию. Идентификационная информация пользовате
ля
-
это абстрактное представление лица, которому необходим доступ к системе или
приложению. Обычно она включает такие атрибуты, как имя пользователя, пароль,
идентификатор пользователя и адрес электронной почты. Аутентификация
-
это до
казательство того, что лицо является законным владельцем идентификационной ин
формации.
В этой главе основное внимание уделяется системе
UNIX
и
Linux
SSO
как компоненту систем
в рамках единой организации. Для единого входа в нескольких органи
зациях (который, например, может потребоваться для интеграции ваших систем и си
стем поставщика программного обеспечения в рамках модели обслуживания "про
(Software-as-a-Service - SaaS)) доступны несколько
SSO. В этих случаях в каче
рекомендуем изучить язык Security Assertion Markup Language
граммное обеспечение как услуга"
решений на основе стандартов и коммерческих решений
стве первого шага мы
(SAML).
Часть
596
17 .1. Основные ЭЛЕМЕНТЫ
11.
Работа в сетях
СИСТЕМЫ ЕДИНОГО ВХОДА
Хотя существует множество способов создания единого входа, в каждом сценарии
обычно требуется четыре элемента.
•
Централизованное хранилище каталогов, которое содержит идентификацион
ные данные пользователя и информацию авторизации. Наиболее распространен
ными решениями являются службы каталогов, основанные на протоколе LDAP
(Lightweight Directory Access Protocol). В средах, в которых сочетаются системы
Windows, UNIX и Linux, хорошим выбором является популярная служба Microsoft
Active Directory, включающая настраиваемый, нестандартный интерфейс LDAP.
•
Инструмент для управления информацией пользователя в каталоге. Для соб
ственных реализаций
Studio.
LDAP
мы рекомендуем
phpLDAPadmin
или
Apache Directory
Оба являются простыми в использовании неб-инструментами, которые по
зволяют импортировать, добавлять, изменять и удалять записи в каталоге. Если
вы являетесь приверженцем службы
Microsoft Active Directory,
то для управления
информацией в каталоге вы можете использовать интегрируемый модуль
Windows
"Active Directory Users and Computers".
•
Механизм аутентификации идентификационной информации пользователей. Вы
можете аутентифицировать пользователей непосредственно в хранилище
LDAP,
но помимо этого часто используется система аутентификации на основе манда
тов на основе протокола
Kerberos,
Windows Active Directory
предоставляет доступ
первоначально разработанная в МIТ. 1 В средах
LDAP
к идентификаторам пользо
вателей и использует настраиваемую версию KerЬeros для аутентификации.
•
Аутентификация в современных системах
PluggaЫe
Authentication Module,
UNIX
и
Linux
выполняется системой
также известной как РАМ. Для агрегирования досту
па к службам идентификации и аутентификации пользователя вы можете использо
вать демон
•
System Security Service Daemon (sssd), а затем указать
РАМ в
sssd.
Библиотеки подпрограмм на языке С для централизованной идентификации и ау
тентификации, которые ищут пользовательские атрибуты. Эти утилиты (напри
мер,
и
getpwent) традиционно читают обычные файлы, такие как /etc/passwd
/etc/group, и отвечают на запросы, основываясь на их содержании. В настоя
щее время источники данных настраиваются в файле переключения службы имен,
/etc/nsswi tch. conf.
17.1 показаны отношения высокого уровня между различными компонен
тами SSO в типичной конфиrурации. В этом примере в качестве сервера каталогов ис
пользуется Active Directory. Обратите внимание на то, что как временная синхрониза
ция (NTP), так и отображение имен хостов (DNS) имеют решающее значение для сред,
использующих Kerberos, поскольку мандаты аутентификации имеют временные метки
На рис.
и ограниченный срок действия.
В этой главе мы рассмотрим основные концепции системы
два конкретных LDAP-cepвepa для систем
UNIX
и
Linux.
LDAP
и представим
Затем мы обсудим шаги, не
обходимые для того, чтобы машина использовала централизованную службу каталогов
для обработки авторизации.
1 Сообщество
специалистов по системам безопасности делится на тех, кто считает, что наилучшую
LDAP, и сторонников протокола Kerberos. Дорога
зашиту аутентификации обеспечивает служба
жизни усеяна расплющенными белками, которые не могли сделать выбор. Выберите свой вариант
и не оглядывайтесь назад.
Глава
17. Система
597
единого входа
Внешние серверы
Локальная система
login, getty,
оконный сервер
Провайдер
идентификации
ntpd
- - - - Сервер NTP
nss_sss
!
Связующее
звено LDAP
Библ и отека С
Сервер
шd
getp~ntO
getpwnam()
Active Directory
Связующее
звено Kerberos
раm_ш
[
Провайдер аутентификации JРаспознаватель DNS 1---8"1~ Сервер DNS j
17. 1.
Рис.
Компоненты
SSO
17 .2. LDAP: 11 0БЛЕГЧЕННЫЕ" СЛУЖБЫ
КАТАЛОГОВ
Служба каталогов - это просто база данных, но такая, в которой сделан ряд допол
нительных предположений. Любой набор данных, характеристики которых подпадают
под эти предположения, становится кандидатом на включение в базу данных. Основные
предположения таковы :
•
•
•
•
•
информационные объекты относительно невелики;
база данных будет реплицироваться и кешироваться на множестве компьютеров;
у информации есть атрибуты;
данные извлекаются часто, но записьшаются редко;
операции поиска выполняются очень часто.
IETF д.11я этих целей, на
протокол доступа
упрощенный
Protocol
Access
Directory
(Lightweight
LDAP
зывается
к каталогам). 2 Изначально LDAP задумывался как простой шлюзовой протокол, кото
рый позволял бы клиентам TCP/IP взаимодействовать с серверами каталогов Х.500, те
Текущая стандартная система, пред.11оженная организацией
перь уже устаревшими.
LDAP является служба Active
эту службу д.11я аутен
используют
организации
Многие
Microsoft.
Directory компании
тификации как в системе Windows, так и в системах UNIX и Linux. Для таких организа
ций стандартной реализацией стал пакет OpenLDAP (openldap. o rg) . Служба катало
гов уровня предприятия, остроумно названная 389 Directory Server (ранее известная как
Fedora Directory Server и Netscape Directory Server), также является проектом с открытым
исходным кодом, к которому можно получить доступ на сайте port38 9. org. 3
Наиболее распространенной реализацией протокола
Особенности
LDAP
Для уверенной работы с
LDAP
вам нужен хотя бы небольшой опыт. Протокол
LDAP
сам по себе не решает какую-либо административную проблему. Нет какой-то "'глав
ной задачи", которую можно было бы решить исключительно с помощью
2 Как
это ни парадоксально, но протокол
LDAP
LDAP;
можно назвать каким угодно, но только не упро
щенным.
'ТСР-порт
389
к тому
является портом по умолчанию для всех реализаций протокола
LDAP.
598
Часть
11. Работа в сетях
же на разных сайтах по-разному подходят к необходимости развертывания серверов
LDAP. Поэтому прежде чем перейти к особенностям инсталляции и конфигурирования
OpenLDAP, поговорим о том, в каких случаях целесообразно использовать LDAP.
• LDAP можно использовать в качестве хранилища дополнительной информации
о пользователях (телефонных номеров, домашних и рабочих адресов).
•
Многие почтовые системы, включая
данные о маршрутизации из
ность применения
токола
• LDAP
LDAP
LDAP.
LDAP,
sendmail, Exim
и
Postfix,
могут получить
и этим отчасти можно объяснить популяр
Дополнительную информацию об использовании про
в почтовой системе
sendmail
см. в разделе
18.8.
позволяет упростить процесс аутентификации пользователей для приложе
ний (даже тех, которые написаны другими командами программистов и в других
подразделениях), избавляя разработчиков от необходимости беспокоиться о точ
ных деталях управления учетными записями.
•
Изменения, внесенные в LDАР-данные, немедленно вступают в силу и мгновенно
становятся видимыми для всех хостов и приложений клиентов.
• LDAP всесторонне поддерживается языками написания сценариев вроде Perl
и Python (посредством использования библиотек). Следовательно, LDAP удобно
использовать для передачи информации о конфигурации локально написанным
сценариям и утилитам администрирования.
• LDAP
хорошо поддерживается и как служба общедоступных каталогов. Многие
ведущие почтовые клиенты применяют
LDAP для доступа к каталогам пользо
LDAP поддерживается во многих веб
вателей. Простой поиск с использованием
браузерах посредством типа
Структура данных
Данные протокола
называют "записями"
(например,
в среде
LDAP
LDAP принимают форму списков свойств, которые в мире LDAP
(entry). Каждая запись состоит из набора именованных атрибутов
uid, description)
Windows,
LDAP U RL.
и значений этих атрибутов. Пользователи, работающие
вероятно, заметят, что эта структура напоминает структуру записей
в системном реестре. Как и в реестре
Windows,
отдельный атрибут может иметь несколь
ко различных значений.
В качестве примера рассмотрим обычную (и упрощенную) строку файла
/etc/
passwd, выраженную в виде записи LDAP.
dn: uid=ghopper,ou=People,dc=navy,dc=mil
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: ghopper
cn: Grace Hopper
userPassword: {crypt}$1$pZaGA2RL$MPDJoc0afuhHY6yk8HQFp0
loginShell: /bin/bash
uidNumЬer: 1202
gidNumber: 1202
homeDirectory: /home/ghopper
Здесь мы видим простой пример формата
мат обмена данными
LDAP),
LDIF (LDAP Data lnterchange Format -
фор
который применяется в большинстве инструментов, связан-
Глава
17. Система
ных с
LDAP.
единого входа
599
и в реализациях серверов. Причиной успеха этого формата яШiяется то обсто
ятельство, что
LDAP можно без труда преобразовывать в простой текст и обратно.
Записи образуют иерархию по "отличительным именам" (имя атрибута:
dn distinguished name), которые формируют некоторую разновидность пути поиска. Как и в
системе DNS, "самый старший бит" находится справа. Например, в приведенном выше
примере имя DNS navy. rnil используется для построения верхних уровней иерархии
LDAP. Оно разбивается на два компонента домена: navy и rnil, хотя это всего лишь
одно из некоторых обычных соглашений.
Каждая запись имеет только одно отличительное имя. Записи совершенно изолиро
ваны друг от друга и не образуют иерархии, за исключением иерархии, неявно опре
деляемой атрибутами
dn.
Это гарантирует их уникальность и подсказывает реализации
протокола, как эффективно индексировать и искать данные. Виртуальную иерархию,
созданную атрибутами
dn,
применяют разные пользователи протокола
LDAP,
но она
является скорее соглашением о структуризации данных, чем явной функциональной
возможностью протокола
LDAP.
В то же время существуют возможности для создания
символических связей между записями и ссьшками на другие серверы.
Записи
LDAP обычно составляются
на основе использования атрибута
obj ectCla.s s.
Классы объектов определяют атрибуты, которые может содержать запись, причем не
которые из них могут требоваться для проверки достоверности. Каждому атрибуту на
значается тип данных. Схема вложения и комбинирования классов объектов ничем не
отличается от схемы, принятой в традиционном объектно-ориентированном програм
мировании. Верхний уровень дерева класса объектов называется
то, что запись должна иметь атрибут
В табл.
приведены некоторые обычные атрибуты
17.1
top;
он означает лишь
obj ectClass.
LDAP,
назначение которых
с первого взгляда может быть непонятным.
Таблица
17. 1• Некоторые имена
атрибутов, которые можно встретить в иерархиях
LDAP
Атрибут
Расwифровка
Назначение
о
Orgaпizatioп (организация)
Часто идентифицирует запись верхнего уровня сайта•
ou
Orgaпizatioп uпit (организаци
Логическое подразделение, например
онная единица)
(отдел маркетинга)
cn
Commoп паmе (обычное имя)
Наиболее естественное имя, с помощью которого
dc
Domaiп соmропепt (компонент
Используется в сайтах, в которых иерархия построена
домена)
на основе
marketing
можно передать смысл записи
objectClass
Object class (класс
объектов)
DNS
Схема, в соответствии с которой формируются атри·
буты данной записи
"Обычно не используется системами, в которых ШАР-иерархия построена на основе
OpenLDAP: традиционный
DNS.
LDAP-cepвep
с открытым исходным кодом
OpenLDAP -
это расширение проекта, выполненного в Мичиганском университете.
В настоящее время он продолжает оставаться проектом с открытым исходным текстом
и распространяется с большинством дистрибутивов
Linux
(хотя и не всегда включается
в стандартный вариант инсталляции). Его документацию, вероятно, лучше всего харак
теризует слово "оживленная".
Часть
600
В дистрибутиве
OpenLDAP
11.
Работа в сетях
стандартным демоном LDAP-cepвepa является
В среде с несколькими серверами
OpenLDAP
демон
slurpd
slapd.
выполняется на главном
сервере и отрабатывает механизм репликации посредством внесения изменений на под
чиненные серверы. Утилиты командной строки позволяют выполнять запросы и моди
фицировать данные
LDAP.
Настройка довольно простая. В первую очередь потребуется создать файл
вером
OpenLDAP.
/ etc/
скопировав образец, который был инсталлирован вместе с сер
openldap/ slapd. conf,
Необходимо обратить внимание на следующие строки.
database bdb
suffix "dc=mydomain,dc=com"
rootdn "cn=admin,dc=mydomain,dc=com"
rootpw {crypt)abJnggxhB/yWI
directory /var/liЬ/ldap
По умолчанию выбирается формат базы данных
Berkley DB,
отлично подходящий
для данных, манипуляция которыми будет производиться в системе
OpenLDAP.
Вы мо
жете использовать разнообразные интерфейсы, включая специальные методы (напри
мер, сценарии, создающие данные "на лету").
Переменная
ства имен
задает "базовое имя"
suffix
LDAP,
подобный тому, что в
DNS
LDAP.
Это корень вашей части простран
называется доменным именем. Этот пример
показывает обычное использование доменного имени в качестве базового имени
Переменная
rootdn
задает административное имя, а переменная
rootpw -
LDAP.
хеширо
ванный пароль администратора. Обратите внимание на то, что доменные компоненты,
восходящие к административному имени, также должны быть указаны. Для генериро
вания значения для этого поля можно использовать утилиту
slappaswd;
просто скопи
руйте и вставьте в поле результат работы этой утилиты.
Поскольку пароль хешируется, проверьте, что файл
вилегированному пользователю, а
ero
slapd. conf
уровень допуска равен
Нужно также отредактировать файл
принадлежит при
600.
/ etc/ openldap/ ldap. conf, чтобы указать сер
LDAP. Это несложно: просто
вер по умолчанию и базовое имя для клиентских запросов
задайте аргумент записи
host
равным имени сервера, а в переменную
же значение, что и в переменной
suffix
файла
slapd. conf
не являются комментариями). Вот как выглядит пример для сайта
BASE
URI
base
занесите то
(убедитесь, что обе строки
atrust. com.
dc=atrust,dc=com
ldap://atlantic.atrust.com
С этого момента можно запускать демон
389 Directory Server:
slapd
без аргументов.
альтернативный
LDAP-cepвep с открытым исходным кодом
Подобно
OpenLDAP,
(port389. org)
служба каталогов уровня предприятия
389 Directory Server
является расширением проекта, выполненного в Мичиганском универ
ситете. Однако прошло несколько лет (в компании
Netscape Communications),
прежде
чем этот проект снова стал открытым.
Существует множество причин рассматривать проект
нативу для
OpenLDAP,
389 Directory Server как
альтер
но среди его явных преимуществ все же стоит выделить более
совершенную документацию. Проект
389 Directory Server
поставляется с инструкциями
профессионального уровня поадминистрированию и использованию, включая подроб
ные руководства по инсталляции и внедрению.
Глава
17. система
единого входа
601
К ключевым особенностям проекта
•
389 Directory Server можно
отнести следующие:
использование нескольких полностью равноправных мастер-серверов, что позволяет
обеспечить огказоустойчивость и высокую скорость выполнения операций записи;
•
возможность синхронизации пользователей, групп и паролей с контроллерами до
мена
•
Active Directory;
консоль администрирования с графическим интерфейсом, управления из команд
ной строки и через веб-интерфейс;
Проект 389 Directory Server имеет больше активных разработчиков, чем проект
OpenLDAP. Поэтому мы обычно рекомендуем отдавать предпочтение именно проекту
389 Directory Server.
С административной точки зрения эти два сервера с открытым исходным кодом по
разительно сходны в том, что касается структуры и функционирования. И это не удиви
тельно, поскольку оба пакета были построены на базе одного и того же исходною кода.
Создание LDАР-запросов
Для администрирования
LDAP
вам не обойтись без просмотра содержимого базы
данных и управления им. Для этого вам очень пригодится упомянутый выше свободно
распространяемый пакет
phpLDAPadmin,
который предоставляет удобный интерфейс,
работающий по принципу "указал и щелкнул". Помимо
пользовать утилиту
ldapsearch
(распространяемую с
phpLDAPadmin, можно ис
OpenLDAP и 389 Directory Server),
которая предназначена для поиска информации в службе каталога и является анало
гичным инструментом командной строки, генерирующим результат в формате
Утилита
ldapsearch
LDIF.
особенно полезна для вызова из сценариев, а также для сред ог
ладки, в которых служба
Active Directory действует
в качестве сервера
LDAP.
ldapsearch для просмотра
обычное имя сп (common name)
В следующем примере запроса используется утилита
информации о каталогах тех пользователей, у которых
начинается с
"ned".
В данном случае найден только один результат, соответствующий
такому запросу. Назначения используемых :щесь флагов рассматриваются ниже.
# LDAPvЗ
# base with scope sub
# filter: cn=ned*
# requesting: ALL
#
# ned, Users, boulder.atrust.com
dn: cn=ned,cn=Users,dc=boulder,dc=atrust,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: ned
Часть
602
11.
Работа в сетях
sn: McClain
telephoneNumber: 303 245 4505
givenName: Ned
distinguishedName: cn=ned,cn=Users,dc=boulder,dc=atrust,dc=com
displayName: Ned McClain
memЬerOf: cn=Users,cn=Builtin,dc=boulder,dc=atrust,dc=com
memЬerOf: cn=Enterprise Admins,cn=Users,dc=boulder,dc=atrust,dc=com
name: ned
sAМAccountName: ned
userPrincipalName: ned@boulder.atrust.com
lastLogonTimestamp: 129086952498943974
mail: ned@atrust.com
Флаги
ра
LDAP
-h
и -р команды
ldapsearch
позволяют указать в запросе хост и порт серве
соответственно.
Обычно вам потребуется аутентифицировать себя на сервере
LDAP.
В этом случае ис
пользуются специальные флаги. Флаг -х запрашивает простую аутентификацию (в отли
чие от
SASL).
Флаг -D идентифицирует отличительное имя учетной записи пользователя,
который имеет права доступа, необходимые для выполнения запроса. Наконец, флаг
-w
ldapsearoh предложить вам ввести соответствующий пароль.
Флаг -Ь указывает утилите ldapsearch, где именно в иерархии LDAP начать поиск.
Этот параметр известен как baseDN (отсюда и имя флага "Ь"). По умолчанию утили
та ldapsearch возвращает все соответствующие критерию поиска строки, найденные
ниже базовой точки дерева baseDN, т.е. поиск будет выполняться только в дочерних эле
предписывает утилите
ментах базы поиска (включая ее саму). Уточнить характер такого поиска можно с по
мощью флага
-s.
Последний аргумент представляет собой "фильтр", который описывает объект ва
шего поиска. Он не требует использования флагов. Этот фильтр,
вает возвращение всех строк
LDAP,
фильтр заключается в кавычки
cn=ned*, обеспечи
"ned". Этот
"обычное имя" которых начинается с
("cn=ned*"),
чтобы специальные символы универсали
зации в строке поиска (в данном случае это "звездочка") не были восприняты системой
как управляющие символы командной оболочки.
Если вы хотите извлечь все записи ниже заданной базы baseDN, просто используйте
в качестве фильтра поиска выражение
или же опустите фильтр во
objectClass=* -
обще, поскольку такой характер поиска действует по умолчанию.
Любые аргументы, которые указаны за фильтром, обеспечивают выбор конкретных
атрибутов для возвращаемого результата. Например, если бы вы добавили в конец при
веденной выше командной строки аргумент
mail givenName,
утилита
ldapsearch
воз
вратила бы только эти атрибуты отфильтрованных записей.
Преобразования файлов паролей и групп
Если вы переходите на протокол
LDAP
LDAP
и у вас уже есть информация о пользовате
лях и группах, то вам, возможно, потребуется перенести существующие данные. В доку
менте
UNIX,
RFC2307
определено стандартное преобразование традиционных наборов данных
к которым относятся файлы
passwd
и
group,
в пространство имен
LDAP.
Это
полезный справочный документ (по крайней мере с теоретической точки зрения). На
практике все эти спецификации читать гораздо проще компьютерам, чем людям; вам же
лучше просто просмотреть примеры.
Фирма
Padl Software
предлагает бесплатную коллекцию сценариев, которые перево
дят существующие текстовые файлы или карты
NIS
в
LDAP.
Эти сценарии можно най-
Глава
17. Система
ти по адресу:
603
единого входа
padl. com/OSS/MigrationTools. html.
Работать с ними очень просто.
Сценарии можно использовать в качестве фильтров мя генерации
LDIF,
а также мож
но запускать, чтобы загружать данные прямо с сервера. Например, сценарий
group
преобразовывает взятую из
/etc/group
migrate_
строку
csstaff:x:2033:evi,matthew,trent
в следующий блок
LD 1F:
dn: cn=csstaff,ou=Group,dc=domainname,dc=com
cn: csstaff
objectClass: posixGroup
objectClass: top
userPassword: {crypt}x
gidNumЬer: 2033
memЬeruid: evi
memЬeruid: matthew
memЬeruid: trent
17 .3.
ИспользовАНИЕ СЛУЖБ КАТАЛОГОВ
ДЛЯ ВХОДА В СИСТЕМУ
После инсталляции службы каталогов выполните следующие задачи по настройке,
чтобы ваша система могла использовать
•
настройте
•
SSO.
Если вы планируете использовать службу
Kerberos
Настройте утилиту
Active Directory с протоколом Kerberos,
Active Directory.
и присоедините систему к домену
sssd мя связи с соответствующими хранилищами
(LDAP, Active Directory или Kerberos).
идентифи
кации и аутентификации
•
Настройте ключ службы имен,
nsswitch. conf,
чтобы использовать утилиту
sssd
в качестве источника информации о пользователе, группе и пароле.
•
Настройте РАМ мя обслуживания запросов аутентификации с помощью демона
sssd. 4
Ниже мы рассмотрим эти процедуры.
Система
Kerberos
Kerberos -
это система аутентификации на основе мандатов, использующая крип
тографию с симметричным ключом. Его популярность в последнее время была обеспе
Microsoft, которая использует ее как часть системы ау
Active Directory и операционной системе Windows. В контексте
SSO мы описываем, как интегрироваться со средой Active Directory Kerberos в системах
Linux и FreeBSD. Если вы используете LDAP-cepвep, отличный от Active Directory, или
если вы хотите пройти аутентификацию в службе Active Directory с помощью LDAP, а не
Kerberos, вы можете сразу перейти к обсуждению демона sssd.
чена прежде всего компанией
тентификации в службе
W
Дополнительную информацию о системе Kerberos см. в разделе 27.6.
•одна часть программного обеспечения использует традиционное семейство библиотечных про
цедур getpwent для поиска информации о пользователе, но современные службы часто напрямую
вызывают процедуры аутентификации РАМ. Чтобы обеспечить полностью функциональную среду,
настройте и РАМ, и
nsswitch.conf.
Часть
604
Конфигурация Linиx
11. Работа в сетях
Kerberos для интеграции службы Active Directory
Системные администраторы часто хотят, чтобы их системы
нами домена
Linux
были чле
Раньше сложность этой конфигурации приво
Active Directory.
дила к тому, что некоторые из системных администраторов приходили в от
чаяние. К счастью, появление пакета
Пакет
realmd действует
sssd,
так и мя системы
realmd
намного упростило эту задачу.
в качестве инструмента настройки как мя демона
Kerberos.
Прежде чем пытаться присоединиться к домену
Active Directory,
проверьте следую-
щие условия.
В системе
•
Linux,
которую вы присоединяете к домену, инсталлирован пакет
realmd.
•
•
•
Демон
sssd инсталлирован
(см. ниже).
Демон
ntpd
•
У вас есть учетные данные для учетной записи
установлен и запущен.
Вы знаете правильное имя своего домена
Active Directory.
Active Directory,
которой разреше
но присоединяться к системе в домене. Это действие приводит к выдаче мандата
на вьщачу мандатов в
Kerberos (ticket granting ticket - TGT),
чтобы он мог выпол
нять операции аутентификации в будущем без доступа к паролю администратора.
Например, если ваше доменное имя
пись
Active Directory
под именем
trent
Active Directory - ULSAH.COM,
а учетная за
имеет право на присоединение системы к до
мену, вы можете использовать следующую команду мя присоединения вашей системы
к домену.
печально известна своим сложным процессом настрой
ки, особенно на стороне сервера. К сожалению, система
FreeBSD не имеет
realmd в системе Linux, кото
рый настраивает Kerberos и объединяет домен Active Directory за один шаг.
Однако вам необходимо настроить только клиентскую сторону Kerberos.
Конфигурационным файлом является /etc/krbS. conf.
надежного инструмента, похожего на пакет
17. Система единого входа
Глава
605
Во-первых, дважды проверьте, что полное доменное имя системы включено в файл
/etc/hosts,
conf,
мена
а протокол
NTP
настроен и работает. Затем отредактируйте файл
krbS.
чтобы добавить область, как показано в следующем примере. Замените имя до
Пятиминутное рассогласование часов разрешено, даже если время установлено с по
мощью протокола
с протоколом
NTP.
NTP.
Эта свобода позволяет системе работать даже в случае проблем
Область по умолчанию установлена в домене
Active Diгectory, а центр
Active Diгectory. Для
распределения ключей (или КОС) настроен как контроллер домена
отладки может пригодиться файл
krb5. log.
Запросите мандат из контроллера
Active
Diгectory, запустив команду
действительную учетную запись пользователя домена. Аккаунт
kini t.
Укажите
administrator
обычно
является хорошим тестом, но подойдет и любая учетная запись. При появлении запроса
введите пароль домена.
$ kinit
administrator@ULSAН.COМ
Password for adrninistrator@ULSAH.COM:
Используйте команду
klist,
чтобы показать мандат КегЬегоs.
$ klist
Ticket cache: FILE:/trnp/krb5cc_l000
Default principal: adrninistrator@ULSAH.COM
Service principal
Valid starting
Expires
04/30/17 13:40:19 04/30/17 23:40:21 krbtgt/ULSAH.COM@ULSAH.COM
renew until 05/01/17 13:40:19
Kerberos 4 ticket cache: /trnp/tktlOOO
klist: You have no tickets cached
Если мандат отображается на экране, то аутентификация прошла успешно. В этом
случае мандат действителен в течение
10
часов и может быть продлен на
аннулирования мандата можно использовать команду
kdestroy.
24
часа. Для
Часть
606
Последний шаг
11. Работа
в сетях
присоединить систему к домену, как показано ниже. Используемая
-
учетная запись администратора (в данном случае
полномочия на сервере
Active Directory для
trent) должна
иметь соответствующие
присоединения систем к домену.
$ net ads join -U trent
Enter trent's password:
Using short domain -- ULSAH
Joined 'example.ulsah.com' to domain 'ULSAH.COM'
Дополнительные параметры конфигурации приведены на справочной странице
krb5. conf.
Демон
s s sd: служба
системной безопасности
В прошлом путь к установке системы
и
Linux
SSO
в операционных системах
UNIX
был долог и труден. Несколько лет назад было принято устанавли
вать независимую аутентификацию для каждой службы или приложения.
Такой подход часто приводил к появлению запутанных конфигураций и не
документированных зависимостей, которые со временем невозможно было
контролировать. Пароли пользователей будут работать с одним приложением, но не с другим, что вызовет разочарование для всех.
Ранее компания Microsoft опубликовала расширения (первоначально называемые
"Services for UNIX", затем "Windows Security and Directory Services for UNIX" и, нако
нец, "ldentity Management for UNIX" в Windows Server 2012), которые облегчили раз
мещение пользователей и групп UNIX в службе Active Directory. Однако использование
полномочий для управления этими атрибутами в системе, отличной от UNIX, было не
естественным. К облегчению многих пользователей компания Microsoft прекратила под
держку этой функции в версии Windows Server 2016.
Эти проблемы нуждались в каком-то комплексном решении, и именно это мы полу
чили с помощью демона
так и для
FreeBSD
sssd, Demon System Security Services. Доступный как для Linux,
sssd - это универсальный инструмент для проверки прав
демон
пользователей, аутентификации и сопоставления учетных записей. Он также может ке
шировать учетные данные в автономном режиме, что полезно для мобильных устройств.
Демон sssd поддерживает аутентификацию как с помощью собственного протокола
LDAP, так и протокола Kerberos. Демон sssd настраивается с помощью файла sssd.
conf. Ниже приведен базовый пример для среды, которая использует Active Directory
в качестве службы каталогов:
[sssd]
services = nss, pam
domains = ULSAH.COM
[domain/ULSAH.COM]
id_provider = ad
access_provider = ad
Если вы используете сервер
файл
по незашифрованному каналу, поэтому требуется использование LDAPS/ТLS. Установка
атрибута
tls_reqcert для
запроса в приведенном выше примере застамяет демон
дополнительно проверять сертификат сервера. Демон
sssd отключает
sssd
соединение, если
обнаруживается, что сертификат недостаточен.
Когда демон
sssd
запущен и работает, вы должны сообщить системе, чтобы
она использовала его в качестве источника для идентификации и аутентификации.
Следующим шагом в этом процессе является настройка ключа службы имен и настрой
ка РАМ.
nsswi tch. conf: переключатель службы
Коммутатор службы имен
имен
(name service switch - NSS)
был разработан для упроще
ния выбора между различными базами данных конфигурации и механизмами разреше
ния имен. Вся конфигурация находится в файле
/eto/nsswi toh. conf.
Синтаксис прост: для определенного типа поиска достаточно просто перечислить
источники в том порядке, в котором им следует обратиться. Вначале следует запраши
вать локальные системные файлы
passwd и group (заданные атрибутом files), а затем
Active Directory или другой службе каталогов с помощью
атрибутом sss). Этот трюк описан в следующих строках.
nsswi tch. conf, конфигурацию можно проверить с помо
getent passwd. Эта команда выводит список учетных записей пользова
определенных во всех источниках в формате /etc/passwd:
Как видно из последних трех записей, приведенных выше, единственный способ
отличить локальных пользователей от учетных записей домена
-
это идентификатор
пользователя и путь к домашнему каталогу.
Модули РАМ: украшение или чудо аутентификации?
Аббревиатура РАМ означает "подключаемые модули аутентификации" (PluggaЬ\e
Authentication Modules -
РАМ). Эти модули освобождают программистов от необ
ходимости выполнять рутинные операции для реализации систем аутентификации.
Часть
608
11. Работа
в сетях
Концепция и термин бьmи придуманы в компании
(которая в настоя
щее время является частью компании
в статье, авторами
которой бьmи Самар
и Лаи
(Samar)
Sun Microsystems
Oracle) и описаны в 1996 юду
(Lai) из компании SunSoft.
В далеком прошлом команды вроде
login
включали встроенный код аутентифи
кации, который предлаrал пользователю ввести пароль, сравнивал ею с зашифрован
ной записью из файла
passwd)
/etc/shadow
(в настоящее время этот файл называется
/etc/
и делал вывод об их совпадении или несовпадении. Разумеется, друrие коман
ды (например,
passwd)
содержали такой же код. Не имея доступа к открытому коду,
было невозможно изменить метод аутентификации, поэтому администраторы имели
мало возможностей для управления настройками паролей (например, задавать правила,
описывающие правильные пароли) или не имели их вообще. Появление модулей РАМ
в корне изменило положение дел.
Системные процедуры аутентификации из модулей РАМ были помещены в сов
местно используемую библиотеку, которую может вызывать программа
login
и другие
программы. Выделение функций аутентификации в отдельную подсистему облегчает
внедрение новых методов аутентификации и шифрования в компьютерную систему.
Например, многофакторная аутентификация может поддерживаться без внесения изме
нений в программы
login
и
passwd.
Для системноrо администратора выбор правильною уровня безопасности для аутен
тификации стал простой задачей конфигурирования. Программисты также получили
выгоду: они больше не обязаны писать сложный код для аутентификации и, что еще
более важно, их системы аутентификации правильно реализуются с первой попытки.
Модули РАМ могут аутентифицировать все виды деятельности: регистрацию пользова
телей, друrие формы доступа к системе, использование защищенных веб-сайтов и даже
настройку приложений.
Конфигурация модулей РАМ
Файлы конфигурации модулей РАМ содержат по одной строке, каждая из которых
представляет собой имя модуля РАМ, используемоrо в системе.
Общий формат этих файлов имеет следующий вид.
тип_ модуля управляЮШJ1й_флаг путь_к_модулю
[аргументы]
Поля разделяются пробелами.
Порядок полей в файле конфигурации РАМ имеет значение. Например, модуль,
предлагающий пользователю ввести пароль, должен выполняться раньше модуля, про
веряющего корректность паролей. Один модуль передает результаты своей работы дру
юму, устанавливая значения переменных окружения или переменных РАМ.
Поле тип_ модуля может иметь значения
Модуль типа
auth
auth, account, session
или
password.
идентифицирует пользователя и может предоставлять ему право груп
повою доступа. Модуль типа
account
выполняет действия, не связанные с аутентифи
кацией, например предоставляет доступ в зависимости от времени суток, ограничивает
количество одновременно работающих пользователей или количество портов, на которых
может происходить регистрация. (Например, можно использовать модуль типа
account
для ограничения регистрации суперпользователя на консоли.) Действия, которые не
обходимо выполнить до или после тою, как пользователь получит доступ к требуемой
службе, например монтирование файловой системы, реализуются модулем типа
Наконец, модуль типа
password применяется,
session.
когда пользователь должен ввести аутенти
фикационную информацию (например, пароль или кодовое словосочетание).
Глава
17. Система единого
609
входа
Поле управляющий_флаг определяет, как должны взаимодействовать модули, обра
зующие стек (табл.
Таблица
17.2).
17.2. Управляющие
флаги модулей РАМ
Остановка
в случае ошибки
Флаг
Остановка
в случае успеха
include
Комментарии
Включает другой файл конфигурации в данную точку
стека
optional
required
requisite
Нет
Нет
Имеет значение, только если модуль единственный
Нет
Нет
Ошибка приводит со временем к 0"11=12
или
cri t
er·r или warning
notice
info
debug
sendmail
глава
18. Электронная почта
657
Напомним, что сообщение, зарегистрированное в системном журнале на конкрет
ном уровне, относится как к этому уровню, так и ко всем находящимся выше уровням.
Файл
/ etc/ syslog. conf
определяет окончательный пункт назначения каждого сооб
щения. Местоположения, заданные по умолчанию, показаны в табл.
Таблица
18.16.
18.16.
Местоположения регистрационных журналов программы seпdmail
Существует несколько программ, которые могут обрабатывать регистрационные фай
лы
sendmail,
создавая итоговые отчеты, которые варьируются от простых количествен
ных и текстовых таблиц
(mreport)
до сложных веб-страниц
(Yasma).
У системного ад
министратора может возникнуть необходимость или желание ограничить доступ к этим
данным или по крайней мере проинформировать пользователей о сборе данных о них.
18.9.
Почтовый АГЕНТ Ех1м
Агент транспорта и доставки почты
Exim
был написан в
1995
году Филипом Гейзелом
из Кембриджского университета и распространен под универсальной общедоступной
лицензией
GNU.
Текущий на момент русского издания книги выпуск,
появился в весной
2019
Exim
версии
4.92,
года. В интерактивном доступе находятся тонны документации
о программе, кроме того, было опубликовано несколько книг, написанных автором про
граммного обеспечения.
Запросы в поисковой системе
о почтовом сервере
Google
Exim
часто приводят к уста
ревшим, а иногда и вообще неприемлемым ответам, поэтому в первую очередь следует
обращаться к официальной документации. В дистрибутивный пакет входит документ
(doc/ spec. txt), состоящий из более чем 400 стра
exim. org в виде файла PDF. Он представ
справочник по программе Exim, который неукоснительно
о спецификации и конфигурации
ниц. Этот документ также доступен на сайте
ляет собой исчерпывающий
обновляется с каждым новым выпуском.
Существует два подхода к конфигурации постового сервера
тивный. Операционная система
Deblan
Exim: Deblan
и альтерна
использует препроцессор m4 и управляет своим
собственным набором списков рассылки для поддержки пользователей. Мы не будем
рассматривать расширения конфигурации, характерные для системы
Почтовый сервер
Exim
похож на программу
sendmail
Deblan.
тем, что он реализован как
единственный процесс, выполняющий все почтовые операции. Однако его авторы от
казались от исторического багажа программы
sendmail
(поддержки устаревших фор
матов адресов, необходимости получать почту для хостов, не находящихся в Интернете,
и т.д.). Многие аспекты функционирования почтового сервера
Exim
определяются во
время компиляции, при этом ориентирами являются база данных почтового сервера
Exim
и форматы хранения сообщений.
Основные рабочие инструменты в почтовом сервере
Exim
называются маршрутиза
торами и транспортными средствами. Оба они относятся к общей категории "драйве-
Часть
658
11.
Работа в сетях
ров". Маршруrизаторы решают, как сообщения должны быть переданы, а транспортные
средства выбирают способ доставки. Маршруrизаторы
это упорядоченный список
-
адресов, которые следует проверить, а транспортные средства
-
неупорядоченный на
бор способов доставки.
Инсталляция почтового сервера
Exim
Последнюю версию дистрибуrивного пакета можно загрузить с сайта
если ваш сайт работает под управлением системы
Linux,
exim. org
или,
из вашего любимого репози
тария пакетов. Место, где следует инсталлировать программу, идентификаторы пользо
вателей и друтие параметры указаны в файлах READМE и src/EDIТМE. Файл ЕDIТМЕ со
держит более
1ООО
строк, которые по большей части представляют собой комментарии
к процессу компиляции; требуемые изменения помечены. После редактирования сохра
ните файл как
.. /Local/Мakefile
или
.. /Local/Makefile-имя_ OC
(если в одном
и том же каталоге вы создаете конфигурации для разных операционных систем), а затем
запустите команду
make.
Ниже перечислены несколько важных переменных (по нашему мнению) и предла
гаемые значения (по мнению разработчиков почтового сервера
Exim)
из файла ЕDIТМЕ.
Первые пять строк являются обязательными, остальные только рекомендуются.
BIN DIRECTORY=/usr/exim/bin
SPOOL_DIRECTORY=/var/spool/exim
CONFIGURE_FILE=/usr/exim/configure
SYSTEM- ALIASES - FILE=/etc/aliases
EXIM USER=ref:exim
SUPPORT_MBX=yes
LOOKUP_DBM=yes
LOOKUP_LSEARCH=yes
LOOKUP_DNSDB=yes
USE_DB=yes
DBMLIB=-ldb
WITH CONTENT SCAN=yes
#
#
#
#
#
#
#
#
Системы управления базами данных
Метод последовательного поиска
Разрешает почти
все поиски
Berkeley DB
README)
Использовать
(из
файла
Включает
через
сканирование
списки
в
(из
DNS
README)
содержимого
ACL
EXPERIMENTAL_SPF=yes
Включает поддержку SPF, нужна libspf2
CFLAGS += -I/usr/local/include
#Из www.libspf2.org
LDFLAGS += -lspf2
LOG_FILE_PATH=/var/log/exim_%slog
# Файлы журнала: файл, Syslog или оба
LOG_FILE_PATH=syslog
LOG_FILE_PATH=syslog:/var/log/exim_%slog
EXICYCLOG МАХ=lО
# Количество сохраненных файлов журнала
# равно 10
Глава
18. Электронная
почта
659
Если вы собираетесь использовать маршрутизаторы и транспортные средства, то их
следует скомпилировать в код. В настоящее время, которое характеризуется большими
объемами доступной памяти, их можно использовать все вместе. Некоторые пути, за
данные по умолчанию, ямяются нестандартными: например бинарный файл в каталоге
/usr/exim/Ьin и файл
PID
в каталоге
/var/spool/exim.
Эти параметры можно изме
нить в соответствии со своим инсталлированным программным обеспечением.
Существует около десяти доступных систем управления базами данных, включая
MySQL, Oracle
менную
и
LDAP.
Если вы хотите выбрать систему
которая сообщит программе
LDAP _ LIB _ TYPE,
библиотеку
LDAP. Кроме
LDAP.
LDAP,
Exim о
то должны указать пере
том, что вы используете
того, вы должны указать путь для включения файлов и библи
отек системы
хранится информация о любых зависимостях, которые могут по
В файле ЕDIТМЕ
надобиться при выборе базы данных. В комментариях о зависимостях, которые сопро
вождают каждую запись, есть фраза
"(from README)",
в которой указан не файл
src/
ЕDIТМЕ, а именно READМE.
Файл ЕDIТМЕ имеет много дополнительных параметров безопасности, которые поз
воляют активизировать дополнительные возможности, такие как
SASL,
SMTP AUTH, TLS,
РАМ, а также параметры управления мадением файлом и разрешениями доступа
к нему. Некоторые возможности программы
Exim
можно отключить на этапе компиля
ции, чтобы ограничить последствия ее взлома злоумышленниками.
До завершения инсталляции мы рекомендуем прочитать файл ЕDIТМЕ полностью.
Это даст вам приятное ощущение, что вы упрамяете выполнением программы посред
ством конфигурационного файла. Файл READМE, находящийся в корне дистрибутивного
каталога, содержит много информации о деталях, специфичных для операционных си
стем, которые иногда полезно включать в файл ЕDIТМЕ.
Модифицировав файл ЕDIТМЕ и инсталлировав его в каталог Local/Мakefile, за
make на вершине дистрибутивной иерархии, а затем инструкцию sudo
make install. На следующем этапе необходимо протестировать исполняемый модуль
exim и убедиться, что он достамяет почту так, как ожидается. Полезная тестовая доку
ментация содержится в файле doc/ spec. txt.
Убедившись, что почтовый сервер Exim работает правильно, свяжите модуль /usr
/sЬin/sendmail с модулем exim, чтобы почтовый сервер Exim мог эмулировать тради
пустите команду
ционный интерфейс командной строки для обмена информацией с почтовой системой,
используемой многими почтовыми агентами. Кроме того, следует сделать так, чтобы мо
дуль
exim
запускался во время загрузки системы.
Загрузка почтового сервера
Exim
На компьютере, выполняющем роль концентратора почты, модуль
exim
обычно
запускается во время загрузки в режиме демона и работает непрерывно, прослушивая
порт
25
и принимая сообщения в рамках протокола
тем описана в главе
SMTP.
Загрузка операционных сис
2.
Как и программа
sendmail,
почтовый сервер
Exim
может иметь несколько режимов
работы, и при запуске с разными флагами она выполняет разные функции. Флаги ре
жима почтового сервера
что разработчики модуля
Exim
похожи на флаги режима программы
exim
sendmail,
потому
очень стараются обеспечить совместимость при вызове
почтовых агентов и других средств. Некоторые из наиболее распространенных флагов
перечислены в табл.
18.17.
660
Таблица
Часть
18.17.
Распространенные флаги командной строки модуля
Флаг
Работа в сетях
Exim
Смысл
-Ьd
-Ьf ипи
11.
Запускается в режиме демона и ожидает соединения на пор~у 25
-ЬF
Запускается в пользовательском режиме или в режиме тесrnрования системного фильтра
-Ьi
Перестраивает хешированные псевдонимы (эквивалентен команде newaliases)
-Ьр
Выводит на печать почтовую очередь (эквивалентен команде mailq)
-Ьt
Включает режим тестирования адресов
-ьv
Проверяет синтаксические ошибки в конфигурационном файле
-d+-категория
Запускается в режиме отладки; очень гибкая конфигурация, учитывающая категории
-q
Запускает обработчик очереди (эквивалентен команде runq)
Любые ошибки, существующие в конфигурационном файле, можно обнаружить
на этапе синтаксического анализа с помощью команды
exim
-ьv, но некоторые ошиб
ки можно выявить только на этапе выполнения. Распространенная ошибка
-
непра
вильно расставленные скобки.
Все нюансы, связанные с флагами и параметрами команды
exim,
включая обшир
ную информацию об отладке, можно найти на соответствующей справочной странице.
Утилиты почтового сервера
Дистрибутивный пакет программы
Exim
Exim
включает в себя набор утилит, облегчающих
слежение, отладку и проверку инсталляции. Ниже приведен список с кратким описанием
каждой из этих утилит. Более подробная информация о них изложена в документации.
exicyclog - выполняет ротацию журнальных файлов.
exigrep - просматривает основной журнал.
exilog - визуализирует регистрационные файлы на нескольких серверах.
exim_checkaccess - проверяет доступность заданного IР-адреса.
exim_dЬmЬuild - создает файл DBM.
exim_ dumpdЬ - распечатывает базу данных уточнений (hints).
exim_ fixdЬ - исправляет базу данных уточнений .
exim_ lock - блокирует файл почтового ящика.
exim_ tidydЬ - очищает базу данных уточнений .
eximstats - извлекает статистические показатели из журнала.
exinext - извлекает информацию о повторных попытках.
exipick - ищет сообщения по заданным критериям.
exiqgrep - выполняет поиск в очереди.
exiqsumm - создает отчет об очереди.
exiwhat - выводит список выполняемых процессов программы Exim.
Еще одна утилита, которая входит в пакет Exim, называется eximon. Она представ
ляет собой приложение для системы Х Windows, которое выводит на экран состояние
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
программы
Exim,
состояние ее очереди и несколько последних строк из файла журна
ла. Как и основной дистрибутивный пакет, она создается с помощью редактирования
хорошо комментированного файла ЕDIТМЕ в каталоге
ды
make.
exim_monitor и запуска коман
eximon, подобраны очень
Параметры, заданные по умолчанию для утилиты
удачно, поэтому настройка этого приложения обычно не вызывает затруднений. Кроме
Глава
18. Электронная
почта
661
того, конфигурирование и управление очередью можно осуществлять с помощью гра
фического интерфейса утилиты
eximon.
Язык конфигурации программы
Exim
Рассматриваемый здесь язык конфигурации программы
Exim
(точнее, языки: один
для фильтров, друrой для регулярных выражений и так далее) напоминает довольно
старый (разработанный в 1970-х годах) язык
Forth.17
При первом чтении конфигурации
программы иногда трудно отличить ключевые слова и имена параметров, которые явля
ются фиксированными в языке
Exim,
от имен переменных, определенных системными
администраторами.
Несмотря на то что программа
Exim
рекламируется как легкая для конфигурирова
ния и хорошо документированная, ее довольно сложно освоить. Раздел спецификации
"Как программа
Exim
получает и доставляет почту" требует от новичков больших уси
лий. Тем не менее в ней изложены все основные концепции, лежащие в основе системы.
После присвоения стандартной переменной конкретного значения язык
активизирует определенные действия. В нем есть около
120 стандартных
Exim
иногда
переменных,
значения которых можно изменять в результате одного из действий. Эти переменные
можно включать в условные выражения.
Выражение для вычисления инструкции
i f и подобных ей может напомнить обрат
ную польскую запись, характерную для времен расцвета калькуляторов
Hewlett-Packard.
Рассмотрим простой пример. В строке
acl_smtp_rcpt = $(if ={25}{$interface_port} \
(acl_check_rcpt} (acl_check_rcpt_submit} }
установка параметра
acl _ smtp _ rcpt
вызывает реализацию списка управления досту
пом для каждого пользователя (т.е. выполнение команды
SMPT RCPT).
Значение, при
своенное этому параметру, может быть равным
submi t,
в зависимости от тоrо, имеет ли
acl check_ rcpt или acl _ check _ rcpt
переменная $ interface _port значение 25.
Мы не будем углубляться в детали языка конфигурации программы
Exim,
лишь по
советуем читателям обратиться к обширной документации. В частности, обратите вни
мание на раздел расширения строк в спецификации программы
Файл конфигурации программы
Поведением программы
который обычно называется
Exim.
Exim
Exim во время выполнения управляет файл конфигурации,
/usr/exim/configure. Ero имя представляет собой одну из
обязательных переменных, задаваемых в файле ЕDIТМЕ и компилируемых в бинарный код.
Файл конфигурации
src/ configure. defaul t,
поставляемый по умолчанию, сопро
вождается подробными комментариями и хорошо подходит для новичков. Мы рекомен
дуем не слишком далеко отклоняться от этоrо файла, пока вы не освоитесь с парадигмой
Exim
и не научитесь создавать более сложные конфигурации для специальных ситуаций.
Разработчики программы
Exim хорошо
продумали поддержку наиболее распространенных
ситуаций и создали вполне разумные стандартные конфигурации.
Рекомендуем также не изменять имена переменных, использованных в файле кон
фигурации, заданном по умолчанию, поскольку именно их ожидают увидеть в списках
рассылки люди, которые будут отвечать на ваши вопросы о конфигурации.
17 Для
экспертов в компьютерных науках заметим, что этот язык является полным по Тьюрингу;
в переводе для простых смертных это значит "мощный и сложный".
Часть
662
Программа
exim
выводит сообщения в поток
stderr
11. Работа
в сетях
и прекращает работу, если
в вашем файле конфигурации есть синтаксическая ошибка. Однако она не выявляет
все синтаксические ошибки немедленно, поскольку не обращается к переменным, пока
в них нет потребности.
Порядок записей в файле конфигурации не совсем произвольный: раздел глобаль
ных параметров конфигурации должен существовать и быть первым. Все остальные раз
делы являются необязательными и могут следовать в любом порядке.
Перечислим некоторые разделы.
•
Глобальные параметры конфигурации (обязательны).
• acl -
списки управления доступом, фильтрующие адреса и сообщения.
• authenticators аутентификации
• routers -
раздел для параметров команды
SMPT AUTH
или протокола
TLS.
упорядоченная последовательность, предназначенная для определения
места назначения сообщения.
• transports -
определения драйверов, предназначенных для фактической до-
ставки.
• retry -
настройки правил для решения проблем, связанных с сообщениями.
• rewri te -
правила перезаписи глобальных адресов.
• local _ scan -
ловушка для спама.
begin имя
end имя-раздела не существует; призна
begin следующего раздела. Отступы между раз
Каждый раздел, за исключением первого, начинается с инструкции
раздела, например
begin acl.
Инструкции
ком конца раздела является инструкция
делами облегчают чтение, но для программы
Exim
значения не имеют.
Некоторые инструкции конфигурации присваивают имена объектам, которые впо
следствии будут использованы для управления потоками сообщений. Эти имена должны
начинаться с буквы и содержать только буквы, цифры и символ подчеркивания. Если
первым символом, отличающимся от разделителей строки, является символ #,то вся
остальная часть строки считается комментарием. Это значит, что вы не можете поме
стить комментарий в строку, в которой помещается инструкция; он не будет распознан
как комментарий, поскольку его первый символ не является символом
Программа
Exim
#.
позволяет включать файлы в любое место файла конфигурации.
Существует две формы включения файлов .
. include полный-путь
.include if exists полный-путь
Первая форма генерирует ошибку, если файла нет. Несмотря на то что включение
файлов позволяет сохранять небольшой объем конфигурационного файла, за время об
работки сообщения они считываются несколько раз, поэтому лучше просто включить их
содержимое прямо в файл конфигурации.
Глобальные параметры
В разделе глобальных параметров задается множество данных, включая рабочие па
раметры (пределы, размеры, тайм-ауты, свойства почтового сервера на указанном хо
сте), определения списков (локальных хостов, локальных хостов для перенаправления,
удаленных доменов для перенаправления) и макросы (имя хоста, контакт, местоположе
ние, сообщения об ошибках, баннер
SMTP).
Глава
18. электронная
663
почта
Параметры
Параметры устанавливаются с помощью следующей синтаксической конструкции.
имя_параметра
=
значение[я]
Здесь значения могут быть булевыми или строчными, целыми или десятичными
числами, а также временными интервалами. Допускается также несколько значений,
в этом случае они разделяются двоеточиями.
Использование двоеточия в качестве разделителя создает проблему, потому что
в адресах IPvб оно является частью адреса. Решить эту проблему можно путем удваи
вания количества двоеточий, но намного проще и удобнее для чтения переопределить
символ разделения и задать его равным
< во
время присвоения параметру его значения.
Например, в следующих строках задаются значения параметра
содержащие
1Pv4-
и
1Рvб-адреса
localhost interfaces,
локального хоста.
local interfaces = 127. О. О .1 : : : : : 1
local_interfaces = fd19524415dc
Step 2 : ADD index.html /usr/share/nginx/html/
---> c0c25eaf7415
Removing intermediate container 04cc3278fdb4
Successfully built c0c25eaf7415
Для создания образа с именем
nginx и тегом ulsah используется команда docker
-t nginx: ulsah, чтобы отличить его от официального образа
сервера NGINX. Конечная точка сообщает команде docker build, где можно найти
файл Dockerfile (в данном случае в текущем каталоге).
build
с параметрами
Теперь мы можем запустить образ и просмотреть работу нашего измененного файла
ULSAH index.html file
А simple Docker image, brought to you Ьу ULSAH.
Мы можем убедиться, что наш образ указан среди локальных образов, выполнив ко
манду
docker images.
# docker iшaqes 1 qrep ulsah
REPOSITORY
TAG
IМAGE ID
nginx
c0c25eaf7415
ulsah
CREATED
З minutes ago
Чтобы удалить образы, выполните команду
dockerrmi.
SIZE
134. 6
мв
Вы не можете удалить об
раз, пока не остановите и не удалите все контейнеры, которые его используют.
# docker ps
qrep nqinx:ulsah
IМAGE
СОММАND
STAТUS
nginx:ulsah
"nginx -g 'daemon off"
Up 37 seconds
# docker stop nqinx-ulsah && docker rm nqinx-ulsah
nginx-ulsah
nginx-ulsah
# docker rmi nqinx:ulsah
Обе команды
- docker stop
и
контейнера, в результате чего строка
PORTS
0.0.0.0:80->80/tcp
docker rm - повторяют название
"nginx-ulsah" выводится дважды.
используемого
Реестры
Реестр
-
это индекс образов платформы
Docker,
к которому демон
dockerd
может
получить доступ через протокол НТТР. Когда запрашивается образ, не существующий
на локальном диске, демон
dockerd извлекает его из реестра. Образы загружаются в ре
docker push. Хотя операции с образами инициируются ко
мандой docker, только демон dockerd фактически взаимодействует с реестрами.
Docker Hub - это общедоступная служба реестра, поддерживаемая компанией
Docker, Inc. Она содержит образы для многих дистрибутивов и проектов с открытым ис
естр с помощью команды
ходным кодом, включая все рассматриваемые нами примеры Linux-cиcтeм. Целостность
этих официальных образов проверяется с помощью системы доверенного контента,
гарантируя тем самым, что загружаемый образ предоставляется поставщиком, чье имя
Глава
25.
943
Контейнеры
находится на этикетке. Вы также можете публиковать собственные образы в реестре
Docker Hub Д11Я
других пользователей.
Любой пользователь может загружать общедоступные образы из реестра
Docker Hub,
но,
имея подписку, вы также можете создавать частные репозитории. Получив платную учетную
запись на сайте
строки с помощью ко
манды
получить возможность
hub. docker. com, войдите в систему из командной
docker login Д11Я доступа к персональному реестру, чтобы
загружать и выгружать собственные пользовательские образы. Вы также можете запускать
сборку образов всякий раз, когда в репозитории
Служба
Docker Hub -
Существуют и другие:
Container Registry.
Docker Hub -
GitHub рируется
фиксация.
не единственный реестр, поддерживающий подписку.
quay. io, Artifactory, Google Container Registry
и
Amazon
ЕС2
это щедрый источник образов Д11Я крупной экосистемы. Кроме того,
он постепенно становится реестром по умолчанию, если вам не нужно нечто более не
обычное.
Например, команда
# docker pull debian:jessie
сначала ищет локальную копию образа. Если образ не доступен локально, следующей
остановкой является
Docker Hub.
Вы можете указать демону
docker
использовать дру
гой реестр, включив имя хоста или URL-aдpec в спецификацию образа:
# docker pull registry.admin.com/debian:jessie
Аналогично при создании образа Д11Я занесения в пользовательский реестр вы долж
ны указать его URL-aдpec и пройти аутентификацию перед загрузкой.
# docker tag
deЬian:jessie
registry.admin.com/debian:jessie
# docker login https://registry.admin.com
Username: ben
Password:
# docker push registry.admin.com/debian:jessie
Система
Docker
сохраняет данные регистрации в файле, хранящемся в вашем до
машнем каталоге под названием
. dockercfg,
поэтому вам не нужно снова входить
в систему при следующем взаимодействии с персональным реестром.
Исходя из соображений, связанных с производительностью или безопасностью, вы
можете использовать собственный реестр образов. Проект реестра относится к откры
тому исходному коду
(gi thub. com/docker /distribution),
а простой реестр легко за
пускается как контейнер. 6
# docker run -d
-р
5000:5000 --name registry registry:2
Служба реестра теперь запущена на порту
5000.
Вы можете извлечь из него искомый
образ, указав его имя.
localhost:5000/deЬian:jessie
# docker pull
В реестре реализованы два метода аутентификации:
token
и
htpasswd.
Метод
token
делегирует аутентификацию внешнему провайдеру, что, вероятно, потребует специаль
ных усилий с вашей стороны. Метод
htpasswd
проще и допускает базовую аутентифи
кацию НТТР для доступа к реестру. Кроме того, вы можете настроить прокси-сервер
(например,
NGINX) Д11Я
TLS.
обработки аутентификации. Всегда запускайте реестр с под
держкой протокола
'Тег
отличает реестр последнего поколения от предыдущей версии, которая реализует
несовместимый с текущими версиями платформы Docker.
registry: 2
интерфейс
API,
ЧастьlV.Эксплуатация
944
Стандартная конфигурация персонального реестра не подходит для крупномасштаб
ного развертывания. Для использования в производственной среде нужно учесть ряд
требований, связанных с пространством для хранения, требованиями к аутентификации
и авторизации, к стиранию образов и другими задачами обслуживания.
По мере расширения контейнерной среды ваш реестр будет затоплен новыми обра
зами. Для пользователей, работающих в облаке, одним из возможных способов хране
ния всех этих данных ямяются объектные хранилища, такие как
Cloud Storage.
Amazon
SЗ или
Google
Реестр поддерживает обе службы.
Еще лучше перенаправить свои функции реестра в реестры, встроенные в выбран
ную вами облачную платформу, и одной проблемой станет меньше. Обе компании,
Google
и
Amazon,
предостамяют услуги упрамяемого реестра контейнеров. Вы платите
за хранение и сетевой трафик, необходимый для загрузки и выгрузки образов.
25.3.
КОНТЕЙНЕРЫ НА ПРАКТИКЕ
Как только вы освоите общие принципы работы с контейнерами, вы обнаружите,
что в контейнеризованном мире к административным функциями необходимо подхо
дить по-другому. Например, как вы упрамяете файлами журналов для контейнерных
приложений? Каковы требования безопасности? Как устранить ошибки?
В приведенном ниже списке содержатся эмпирические правила, которые помогут
вам адаmироваться к жизни внутри контейнера.
•
Если вашему приложению необходимо выполнить запланированное задание, не
запускайте планировщик
cron
в контейнере. Для того чтобы создать расписание
для короткоживущего контейнера, который запускает задание и завершает свою
работу, используйте демон
cron
на хосте (или таймер
systemd).
Контейнеры
предназначены для одноразового использвания.
•
Вам необходимо войти в систему и проверить, что делает процесс? Не запускайте
демона
sshd
в контейнере. Подключитесь к хосту с помощью команды
тем используйте команду
•
docker
ssh,
а за
ехес, чтобы открыть интерактивную оболочку.
По возможности настройте свое программное обеспечение так, чтобы оно полу
чало информацию о конфигурации из переменных окружения. Вы можете пере
давать переменные окружения в контейнеры с помощью команды
docker run
и аргумента -е ключ=значение. Или установите сразу несколько переменных
окружения из отдельного файла с помощью параметра
•
-env-file
имя_файла.
Игнорируйте распространенное мнение, утверждающее, что в контейнере должен
существовать только один процесс. Это вздор. Распределяйте процессы по отдель
ным контейнерам только тогда, когда это целесообразно. Например, обычно реко
мендуется запускать приложение и его сервер базы данных в отдельных контейне
рах, поскольку они разделены четкими архитектурными границами. Однако ничего
страшного, если в контейнере есть несколько процессов. Руководствуйтесь здравым
смыслом.
•
Сосредоточьтесь на автоматическом создании контейнеров для вашей среды.
Напишите сценарии для создания образов и их загрузки в реестры. Убедитесь, что
процедуры развертывания программного обеспечения включают замену контейне
ров, а не обномение их на месте.
•
Избегайте обслуживания контейнеров. Если вы вручную загружаете контейнер,
чтобы исправить что-то, выясните, в чем проблема, устраните ее на образе, а затем
Глава
25. контейнеры
945
замените контейнер. Немедленно обновите инструмент автоматизации, если это
необходимо.
•
Столкнулись с трудностями? Задавайте вопросы, используя список рассылки
пользователей
Docker Slack Community или
IRС-канал
Jtdocker
в сети
freenode.
Все, что необходимо для работы приложения, должно быть доступно в его контейне
ре: файловая система, доступ к сети и функциональные средства ядра. Единственными
процессами, которые запускаются в контейнере, являются те, которые запускаете вы. Для
контейнеров нетипично запускать обычные системные службы, такие как
и
sshd,
cron, rsyslogd
хотя это, безусловно, возможно. Эти обязанности лучше всего оставить для хоста
операционной системы. Если эти службы вам нужны именно в контейнере, еще раз ис
следуйте свою проблему и попытайтесь найти более удобный для контейнеров способ.
Ведение журнала
Для вывода диаrностических сообщений в приложениях
используется система
Syslog
(теперь демон
rsyslogd}.
UNIX и Linux традиционно
Syslog выполняет филь
Система
трацию сообщений в журналах, а также их сортировку и маршрутизацию в удаленные
системы. В некоторых приложениях система
Syslog
не используется, и вместо этого со
общения записываются непосредственно в файлы журнала.
Система
Syslog
не запускается в контейнерах. Вместо этого система
Docker собирает
диагностические сообщения с помощью специальных драйверов ведения журнала. Для
этого контейнерные процессы должны записывать сообщения только в поток STDOUT,
а ошибки
-
только в поток STDERR. Система
Docker собирает эти сообщения
и отправля
ет их в указанный пункт назначения.
Если ваше программное обеспечение поддерживает ведение журнала только с помо
щью файлов, примените тот же метод, что и в примере с сервером
NGINX,
приведен
ном выше: при сборке образа создайте символические ссылки из файлов журнала в по
токи
/dev/stdout и /dev/stderr.
Docker пересылает журнальные записи, которые она получает, выбираемому
драйверу ведения журнала. В табл. 25.4 перечислены некоторые из наиболее распростра
Система
Заносит журнальные записи в место, указанное системой
Syslog 6
Заносит записи в журнал systemd"
Заносит журнальные записи в расширенном формате
Заносит журнальные записи в службу AWS
Заносит записи в службу
Google Cloud
Graylog
CloudWatch
Loggiпg
Не ведет журналы
"Журнальные записи, хранящиеся таким образом, доступны для просмотра с помощью команды docker logs.
6 Поддерживает
протоколы UDP, ТСР и ТСР+TLS.
При использовании драйверов
json-file
или
journald
вы можете получить до
ступ к данным журнала из командной строки с помощью команды
контейнера.
docker logs id_
ЧастьlV.Эксплуатация
946
Стандартный драйвер ведения журнала для демона
мощью параметра командной строки
--log-driver.
устанавливается с по
dockerd
Вы также можете назначить драй
вер ведения журнала во время запуска контейнера с помощью команды
--logging-driver.
ры. Например, параметр
файлов для драйвера
docker run
Некоторым драйверам можно передать дополнительные парамет
--log-opt
макс-размер настраивает ротацию журнальных
j son-file. Используйте этот параметр, чтобы не заполнять диск
журнальными файлами. Подробная информация содержится в документации по веде
нию журнала в системе
Docker.
Советы по безопасности
Безопасность контейнеров зависит от процессов, выполняемых внутри контейнеров,
которые не могут получить доступ к файлам, процессам и другим ресурсам вне их пе
сочницы. Уязвимости, позволяющие злоумышленникам вырваться из контейнеров, из
вестны как атаки на прорыв
(breakout attack), -
это серьезные, но редкие атаки. Код,
лежащий в основе изоляции контейнеров, был включен в ядро
с
2008
Linux
по крайней мере
г.; он зрелый и стабильный. Как и в случае с незащищенными или виртуализо
ванными системами, небезопасные конфигурации являются гораздо более вероятным
источником компрометации, чем уязвимости на изолирующем уровне.
Платформа
Docker поддерживает
интересный список известных программных уязви
мостей, которые могут смягчаться путем контейнеризации (см. сайт
docs. docker. сот/
engine/ securi ty /non-events).
Ограничьте доступ к демону
Прежде всеrо защитите демон
dockerd.
Поскольку
dockerd
обязательно работает
с повышенными привилегиями, любой пользователь, имеющий доступ к этому демону,
может легко получить полный привилегированный доступ к хосту.
Этот риск демонстрирует следующая последовательность команд.
$ id
uid=lOOl(ben) gid=lOOl(ben) groups=lOOl(ben) ,992(docker)
# docker run --rm -v /:/host -t -i deЬian bash
root@e5lae86c5f7b:/# cd /host
root@e51ae86c5f7b:/host# ls
proc
run
srv
test
bin
dev
home lib64
mnt
tmp
root
sЬin
sys
boot etc
lib
media
opt
usr
var
Эти сообщения показывают, что любой пользователь в группе
docker
может под
ключить корневую файловую систему хоста к контейнеру и получить полный контроль
над ее содержимым. Это всего лишь один из многих возможных способов повышения
привилегий с помощью платформы
Docker.
Если по умолчанию для связи с демоном вы используете сокет домена
те только доверенных пользователей в группу
doc ke r,
UNIX,
добавь
которая имеет доступ к со кету.
Еще лучше контролировать доступ с помощью программы
sudo.
Используйте ТLS
Мы говорили об этом раньше и повторим еще раз: если демон
dockerd должен
быть
доступен удаленно по сети (запущен с параметром -Н), необходимо использовать про
токол
TLS
и сервера.
для шифрования сетевых сообщений и взаимной аутентификации клиента
Глава
25. контейнеры
947
W Дополнительную информацию о протоколе TLS см. в разделе 27.б.
Настройка
TLS предполагает наличие авторитетного органа, выдающего сертификаты
dockerd и клиентов. После инсталляции пары ключей и центра сертификации
подключение протокола TLS для docker и dockerd просто сводится к указанию правиль
ных аргументов командной строки. Основные параметры перечислены в табл. 25.5.
для демона
Таблица
25.5. Арrументы TLS,
общие для проrраммы
docker
Арrумент
Значение ипи арrумент
--tlsverify
Требуется аутентификация
--tlscert•
--tlskey"
--tlscacert•
Путь к подписанному сертификату
и демона
dockerd
Путь к закрытому ключу
Путь к сертификату доверенного органа
•Необязательный аргумент. По умолчанию находится в каталоге ~ /
Успешное использование протокола
TLS
. docker / {cert, key, са) . pem.
зависит от зрелости процессов управления
сертификатами. Выдача сертификатов, аннулирование и истечение срока их действия
вот некоторые из вопросов, которые требуют внимания. В основном
-
это бремя адми
-
нистратора, ответственного за безопасность.
Выполняйте процессы от имени непривилегированного пользователя
Процессы в контейнерах должны выполняться от имени непривилегированного
пользователя, как это происходит в полнофункциональной операционной системе. Эта
практика ограничивает способность злоумышленников организовывать атаки на про
рыв. Когда вы создаете файл
Dockerfile,
используйте инструкцию
USER
дЛЯ запуска
будущих команд на образе под учетной записью с указанным именем пользователя.
Используйте корневую файловую систему в режиме только для чтения
Для того чтобы дополнительно ограничить использование контейнеров, вы можете
задать команду
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:jessie
Вы также можете удалить все привилегии и добавить обратно те, которые вам нужны:
i docker run --cap-drop ALL --cap-add NET_RAW
deЬian:jessie
948
ЧастьlV.Эксплуатация
Защищайте образы
Функция доверия в системе
Docker
позволяет проверять подr1инность и целостность
образов в реестре. Издатель образа подписывает его секретным ключом, а реестр прове
ряет его с помощью соответствующего открытого ключа. Этот процесс гарантирует, что
образ был создан ожидаемым автором. Вы можете использовать доверительное содер
жимое дr1я подписывания собственных образов или дr1я проверки образов в удаленном
реестре. Эта функция доступна в хранилище
реестрах, таких как
Docker Hub
и в некоторых независимых
Artifactory.
К сожалению, большая часть содержимого в хранилище Dockeг
Hub
является не
подписанной и должна считаться ненадежной. На самом деле большинство образов
в
Docker Hub
никогда не исправляются, не обновляются и не проверяются каким-либо
образом.
Отсутствие надлежащей цепи доверия, ассоциированной со многими образами
Docker,
является показателем жалкого состояния безопасности в Интернете в целом.
Обычно пакеты программного обеспечения зависят от сторонних библиотек, которые
мало или вообще не заботятся о достоверности заложенного в них содержимого. В неко
торых хранилищах программного обеспечения нет криптографических подписей вооб
ще. Также часто можно встретить статьи, авторы которых активно поощряют отключе
ние проверки. Ответственные системные администраторы должны очень подозрительно
относиться к неизвестным и ненадежным репозиториям программного обеспечения.
Отладка и устранение неполадок
Контейнеры приносят с собой особенно отвратительное усложнение и без того
мутных методов отладки. Когда приложение заключается в контейнер, симптомы это
го явления становятся более сложными, а их исходные причины становятся более за
гадочными. Многие приложения могут работать без изменений внутри контейнера,
но в некоторых ситуациях могут вести себя по-другому. Вы также можете столкнуться
с ошибками внутри самой системы
Docker.
Этот раздел поможет вам ориентироваться
в этих мутных водах.
Ошибки обычно проявляются в журнальных файлах, поэтому с них и нужно начать
поиск проблемы. Используйте рекомендации из раздела "Ведение журнала", чтобы на
строить ведение журнала для контейнеров и всегда просматривайте журналы при воз
никновении проблем. Если у вас возникли проблемы с запущенным контейнером, что
бы открыть его интерактивную оболочку, попробуйте выполнить команду
# docker
ехес
-ti
имя_контейнера
bash
В этой оболочке вы можете попытаться воспроизвести проблему, проверить файло
вую систему на наличие ошибок и выявить проблемы в конфигурации. Если вы видите
ошибки, связанные с демоном
doc:kerd,
или если у вас возникли проблемы с его запус
ком, выполните поиск в списке проблем по адресу
gi thub. corn/rnoby /rnoby.
Вы може
те найти других коллег, которые столкнулись с такой же проблемой, и, наверняка, один
из них сможет предr1ожить потенциальное исправление или обходное решение.
Система
Docker
не стирает образы или контейнеры автоматически. Если пренебречь
этим обстоятельством, такие остатки могут занять чрезмерный объем дискового простран
ства. Если рабочая нагрузка вашего контейнера предсказуема, настройте задание
дr1я удаления ненужного материала, выполнив в нем команды
и
doc:ker image prune.
c:ron
doc:ker system 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 }}'
имя_контейнера
25.4. СОЗДАНИЕ И УПРАВЛЕНИЕ
КОНТЕЙНЕРНЫМИ КЛАСТЕРАМИ
Одним из величайших достижений контейнеризации является перспектива совмест
ного размещения многих приложений на одном и том же хосте. Это позволяет избежать
взаимозависимостей и конфликтов и тем самым обеспечить более эффективное исполь
зование серверов. Это привлекательная перспектива, но демон
Docker отвечает
только
за отдельные контейнеры, а не за более широкий вопрос о том, как запускать множество
контейнеров на распределенных хостах в конфигурации с высокой доступностью.
Все инструменты управления конфигурацией, такие как
поддерживают систему
Docker.
Chef, Puppet,
AnsiЫe и
Salt,
Они могут гарантировать, что на хостах запускаются
определенные наборы контейнеров с объявленными конфигурациями. Они также под
держивают создание образов, интерфейсы реестра, управление сетью и томами, а также
другие задачи, связанные с контейнерами. Эти инструменты централизуют и стандар
тизуют конфигурацию контейнеров, но не решают проблему развертывания множества
контейнеров в сети серверов. (Обратите внимание на то, что, хотя системы управления
конфигурацией полезны для различных задач, связанных с контейнером, вам редко
придется использовать управление конфигурацией внутри контейнеров.)
Для развертывания контейнеров в масштабах всей сети вам необходимо программ
ное обеспечение для совместной работы контейнеров, также известное как планирование
контейнеров или программное обеспечение для управления контейнерами. Для обработки
большого количества контейнеров доступно множество открытого и коммерческого ин
струментария. Такие инструменты имеют решающее значение для запуска контейнеров
в производственном масштабе.
Чтобы понять, как работают эти системы, подумайте о серверах в сети как о ферме
вычислительных мощностей. Каждый хост фермы предлагает планировщик для про
цессора, памяти, дисков и сетевых ресурсов. Когда планировщик получает запрос
на запуск контейнера (или набора контейнеров), он помещает контейнер на хост,
у которого есть достаточные запасные ресурсы для удовлетворения потребностей кон
тейнера. Поскольку планировщик знает, где были размещены контейнеры, он также
может помочь в маршрутизации сетевых запросов на правильные хосты в кластере.
Администраторы взаимодействуют с системой управления контейнерами, а не с ка
ким-либо отдельным механизмом контейнера. Эта архитектура показана на рис.
25.4.
ЧастьlV.Эксплуатация
950
Контейнер
Агент
Механизм
контейнера
Контейнер
Управление
Контейнер
Рис.
25.4.
Входящий запрос
Сетка маршрутизации
Контейнер
Узnы
Административное управление
Планировщик контейнера
Типичная архитектура пла11ировщика ко11тей11еров
Системы управления контейнерами предоставляют несколько полезных функций .
•
Алгоритмы планирования выбирают лучший хост в свете запрошенных ресурсов
задания и использования кластера. Например, задание с высокими требованиями
к пропускной способности сети может быть размещено на хосте с сетевым интер
фейсом
•
10
Гбит/с.
Формальные интерфейсы
API
позволяют программам отправлять задания в кла
стер, открывая возможности для интеграции с внешними инструментами. Это по
зволяет легко использовать системы управления контейнерами в сочетании с си
стемами
•
Cl/CD для
упрощения развертывания программного обеспечения.
Размещение контейнеров может удовлетворить потребности конфигураций с вы
сокой доступностью. Например, может потребоваться запустить приложение
на узлах кластера, расположенного в нескольких разных географических регионах.
•
В систему встроен мониторинг работоспособности. Система может прекратить ра
боту и перенести неисправные рабочие места, а также перенаправить задания из
неисправных узлов кластера.
•
Существует возможность легко добавлять или удалять вычислительную емкость .
Если ваша вычислительная ферма не располагает достаточными ресурсами
для удовлетворения спроса, вы можете просто добавить другой узел. Эта возмож
ность особенно хорошо подходит для облачных сред.
•
Система управления контейнером может взаимодействовать с балансировщиком
нагрузки для маршрутизации сетевого трафика от внешних клиентов. Это сред
ство устраняет сложный административный процесс ручной настройки доступа
к сети в контейнеризованных приложениях.
Одной из наиболее сложных задач в распределенной контейнерной системе является
сопоставление имен служб с контейнерами. Помните, что контейнеры обычно запуска
ются на непродолжительное время и им могут назначаться номера портов динамически.
Как сопоставить удобное, постоянное имя службы с несколькими контейнерами, осо
бенно когда узлы кластера и порты часто меняются? Эта проблема известна как обнару
жение служб, а системы управления контейнерами имеют различные ее решения.
Все эти функции позволяют ознакомиться с базовым механизмом выполнения кон
тейнера перед погружением в инструментарий оркестровки. Все системы управления
контейнерами, о которых мы знаем, используют систему
Docker в
качестве стандартного
механизма выполнения контейнеров, хотя некоторые системы также поддерживают дру
гие механизмы.
глава
25. контейнеры
951
Краткий обзор программного обеспечения
для управления контейнерами
Несмотря на свою относительную молодость, инструменты упрамения контейнера
ми, которые мы обсуждаем ниже, являются зрелыми и могут считаться промышленны
ми. Фактически многие из них уже используются на производстве в крупномасштабных
технологических компаниях.
Большинство из них представляют собой программное обеспечение с открытым ис
ходным кодом и имеют значительные сообщества пользователей. Основываясь на по
следних тенденциях, мы ожидаем существенного развития в этой области в ближайшие
годы. В следующих разделах мы расскажем о функциональных возможностях и особен
ностях наиболее широко используемых систем. Мы также упомянем их точки интегра
ции и типичные сценарии использования.
Kubernetes
Название
вой
k
Kubernetes
иногда сокращается до
и последней буквой
s
"k8s",
потому что между первой бук
стоят восемь букв. Так называется проект, который стал
лидером в области управления контейнерами. Он разработан компанией
запущен частью из тех же разработчиков, которые работали над проектом
Google и был
Borg, менед
жером внутреннего кластера
крытым исходным кодом в
Google. Kubernetes был выпущен в качестве проекта с от
2014 г. и теперь имеет более тысячи активных участников.
Он имеет большинство функциональных возможностей и самый быстрый цикл разра
ботки любой системы, о которой мы знаем.
Программное обеспечение
Kubernetes состоит из
нескольких отдельных служб, кото
рые объединяются для формирования кластера. К его основным строительным блокам
относятся следующие компоненты.
• Сервер API для запросов оператора
• Планировщик для размещения задач
• Менеджер контроллеров для отслеживания состояния кластера
• Kubelet - агент, который работает на всех узлах кластера
• Служба cAdvisor для мониторинга показателей контейнеров
• Прокси-сервер для маршрутизации входящих запросов в соответствующий
кон
тейнер
Для обеспечения высокой доступности первые три элемента в этом списке выпол
няются на нескольких главных серверах (которые могут при необходимости выполнять
двойные обязанности как узлы кластера). Процессы
Kubelet
и
cAdvisor
запускаются
на каждом узле, обрабатывают запросы от менеджера контроллеров и сообщают стати
стику о состоянии своих задач.
В
Kubernetes
контейнеры размещаются в виде модуля, содержащего один или не
сколько контейнеров. Все контейнеры в модуле обязательно размещаются на одном узле
кластера. Каждому модулю присваивается уникальный
1Р-адрес
на уровне кластера,
и он получает метку для целей идентификации и размещения.
Модули не предназначены для долговременного использования. Если узел прекра
щает работу, контроллер планирует перенос модуля на другой узел с новым IР-адресом.
По этой причине нельзя использовать адрес модуля как долговременное имя.
ЧастьlV.Эксплуатация
952
Службы предстамяют собой коJUJекции связанных модулей с адресом, который никог
да не изменяется. Если модуль внутри службы прекращает существование или не проходит
проверку работоспособности, служба удаляет этот модуль из ротации. Можно также исполь
зовать встроенный DNS-cepвep для назначения службам распознаваемых имен.
Система
Kubernetes
интегрировала поддержку для обнаружения служб, упрамения
ключами, развертывания и автоматического масштабирования модулей. Она имеет под
ключаемые сетевые опции для поддержки оверлейных сетей контейнера. Она может
поддерживать приложения с фиксацией состояния путем переноса томов между узла
ми кластера по мере необходимости. Ее инструмент командной строки под названием
kubectl
ямяется одним из самых интуитивно понятных, с которыми мы когда-либо
работали. Короче говоря, он имеет набор гораздо более сложных функций, чем те, что
мы включили в этот короткий раздел.
Хотя система
Kubernetes обладает самым
активным и деятельным сообществом и ос
нащена самыми передовыми функциями, эти преимущества компенсируются крутой
кривой обучения. Недавние версии упростили процесс освоения для новичков, но пол
ноценное, тонко настроенное развертывание системы KuЬernetes
ких. Развертывание промышленных версий
k8s
-
занятие не для роб
связано с большой административной
и оперативной нагрузкой.
На основе системы
Kubernetes
реализована служба
Google Container Engine -
одна
из самых удобных для команд, которые хотят использовать контейнерные рабочие на
грузки без эксплуатационных издержек упрамения кластерами.
Mesos
и
Mesos -
Marathon
проект совершенно другоrо рода. Он был задуман в Калифорнийском уни
верситете в Беркли около
пробился в
Twitter,
2009
г. как универсальный менеджер кластера. Он быстро
где теперь работает на тысячах узлов. Сегодня
оритетным проектом от организации
Apache Foundation
Mesos
ямяется при
и может похвастаться большим
количеством корпоративных пользователей.
Основными концептуальными объектами в
касы. Мастер
Mesos
являются мастера, агенты и кар
это посредник между агентами и каркасами. Мастера ретранслируют
-
предложения системных ресурсов от агентов к каркасам. Если у каркаса есть задача
для выполнения, он выбирает предложение и отдает мастеру приказ выполнить задачу.
Мастер отпрамяет данные задачи агенту.
Marathon -
это каркас системы
Mesos,
который развертывает контейнеры и управ
ляет ими. Он включает красивый пользовательский интерфейс для управления прило
жениями и простой интерфейс
определение запроса в формате
RESTful API. Чтобы запустить приложение, вы пишете
JSON и отправляете ero в Marathon через API или поль
зовательский интерфейс. Поскольку это внешний каркас структуры, его развертывание
является гибким. Для удобства
Marathon
может работать на том же узле, что и мастер,
или же запускаться извне.
- самый главный отличительный
Mesos. Apache Spark, инструмент обработки больших данных, и Apache
Cassandra, база данных NoSQL, предлагают каркасы Mesos, что позволяет использо
вать агенты Mesos как узлы в кластере Spark или Cassandra. Каркас Chronos предназна
чен для планирования заданий, скорее, как версия cron, которая работает в кластере,
Поддержка нескольких сосуществующих каркасов
признак системы
а не а отдельной машине. Возможность запуска такоrо количества каркасов на одном
и том же наборе узлов ямяется удобной функциональной возможностью и помогает вы
работать единый и централизованный опыт для администраторов.
Глава
25. Контейнеры
953
В отличие от системы
Kubemetes, Mesos
не поставляется с готовым набором функ
ций. Например, балансировка нагрузки и маршрутизация трафика являются подклю
чаемыми опциями, которые зависят от вашего выбора. Вы можете выбрать инструмент
Marathon-lb,
который реализует эту услугу, или же использовать друтой. Например,
мы успешно использовали инструменты
Consul
и
HAProxy
компании
HashiCorp.
Проектирование и внедрение точного решения остается в качестве упражнения для ад
министратора.
Изучение систем
Kubemetes и Mesos требуют определенных усилий. Для координа
Mesos и большинство ее каркасов полагаются на службу Apache
ции кластеров система
Zookeeper.
Ею довольно сложно управлять, к тому же стало известно о нескольких слож
ных случаях сбоев. Кроме того, кластер
Mesos с
высокой доступностью требует минимум
трех узлов, что может быть обременительным для некоторых организаций.
Менеджер
Docker Swarm
Чтобы не отставать, разработчики платформы
Docker
предложили
контейнерного кластера, встроенный непосредственно в систему
Swarm, менеджер
Docker. Нынешняя
реализация менеджера
Swarm появилась в 2016 г. как ответ на растушую популярность
Mesos, Kubemetes и других кластерных менеджеров, в которых использовались контейне
ры Docker. Оркестровка контейнеров теперь является основным приоритетом компании
Docker, lnc.
Запустить систему Swarm легче, чем Mesos или Kubemetes. Любой узел кластера, на
котором запущена система Docker, может присоединиться к системе Swarm как рабочий
узел, и любой рабочий узел также может быть менеджером. Нет необходимости запускать
отдельные узлы в качестве мастеров. 7 Для запуска системы
простую команды
docker swarm ini t.
Swarm достаточно
выполнить
Нет дополнительных процессов для управления
и настройки, и нет состояния для отслеживания. Все работает прямо из коробки.
Для запуска служб в системе
(как в системе
Kubemetes для
Swarm
можно использовать знакомые команды
docker
работы с коллекциями контейнеров). Вы объявляете состо
яние, которое хотите достичь (например, "мое веб-приложение должно быть запущено на
трех контейнерах"), а система
Swarm
планирует выполнение задач в кластере. Она автома
тически обрабатывает состояния отказа и выполняет обновление без простоя. У системы
Swarm
есть встроенный балансировщик нагрузки, который автоматически настраивается
при добавлении или удалении контейнеров. Платформа балансировки
полнофункциональная, как инструменты
NGINX
или
HAProxy,
Swarm
не такая
но, с другой стороны, она
не требует никакого внимания со стороны системных администраторов.
По умолчанию система
Swarm
единения между узлами в системе
обеспечивает безопасность системы
Swarm зашифрованы
по протоколу
Docker. Все со
TLS, и со стороны
администратора никакой настройки не требуется. Это большое преимущество системы
Swarm
перед конкурентами.
Контейнерная служба
Инфраструктура
AWS
AWS ЕС2
предлагает
ECS,
службу управления контейнерами, предна
значенную для экземпляров ЕС2 (естественных виртуальных серверов
напоминающей многие службы
Amazon,
инфраструктура
'Строго говоря, это верно и для системы KuЬernetes и
Mesos,
AWS
AWS).
В манере,
сначала выпустила служ-
но мы обнаружили, что обьlчной
практикой в конфигурациях с высокой доступностью является отделение мастеров от агентов.
ЧастьlV.Эксплуатация
954
бу
ECS с
минимальной функциональностью, но со временем улучшила ее. Служба
ECS
стала прекрасным выбором д;1я организаций, которые уже вложили средства в инфра
структуру
ECS -
AWS
и хотят придерживаться режима
E-Z.
это "почти упрамяемая" служба. Компоненты кластерного менеджера управ
AWS. Пользователи запускают экземпляры ЕС2, на которых
Docker и агент ECS. Агент подключается к центральному API ECS
ляются инфраструктурой
установлены система
и регистрирует доступность его ресурсов. Чтобы выполнить задачу в вашем кластере
ECS,
отправьте определение задаLIИ в формате
JSON
через
API.
Затем
ECS
назначит за
дачу на одном из ваших узлов кластера.
Поскольку служба является "почти управляемой", порог д;1я входа низкий. Вы мо
жете начать работу с
ECS
всего за несколько минут. Служба хорошо масштабируется
по меньшей мере до сотен узлов и тысяч одновременных задач.
Служба
ECS
взаимодействует с другими службами
AWS.
Например, балансировка на
грузки между несколькими задачами вместе с обнаружением необходимых служб обра
батывается службой
ECS,
Application Load Balancer.
Вы можете добавить ресурс в свой кластер
воспользовавшись автоматическим масштабированием службы ЕС2. Она также
интегрирована со службами
ldentity
и
Access Manager
инфраструктуры
AWS,
что поз
воляет предоставлять разрешения д;1я задач вашего контейнера с целью взаимодействия
с другими службами.
Одной из наиболее проработанных частей
Docker.
Вы можете загружать образы
Docker в
ECS
нятся и становятся доступными любому клиенту
со службой
ECS
является встроенный реестр образов
реестр ЕС2
Docker,
Container Registry,
где они хра
независимо от того, работает он
или нет. Если вы используете контейнеры в инфраструктуре
AWS,
ис
пользуйте реестр контейнеров в той же области, что и ваши экземпляры. Так вы достиг
нете
ropa3110 большей
надежности и производительности, чем с любым другим реестром.
ECS, хотя и функциональный, но ему присущи огра
AWS. Инструмент AWS CLI имеет полную поддержку API
ECS. Для управления приложениями в службе ECS мы рекомендуем обратиться к сто
ронним инструментам с открытым исходным кодом, таким как Empire (github. com/
remindlOl/empire) или Convox (convox. com).
Пользовательский интерфейс
ничения других интерфейсов
25.5. ЛИТЕРАТУРА
•
DocкER,
INc. Ojficial Docker Documentation. docs. docker. com.
Платформа
Docker
имеет хорошую документацию. Она является исчерпывающей и, как правило, ак
туальной.
Docker Up & Running. Sebastopol, СА: O'Reilly
Media, 2015. В этой книге основное внимание уделяется использованию контей
неров Docker в производственных средах.
• Моuлт, ADRIAN. Using Docker: Developing and Deploying software with Containers.
Sebastopol, СА: O'Reilly Media, 2016. Эта книга охватывает темы от базового
•
Млттн1лs, КлRt., дND SF.дN КАNЕ.
до продвинутого и включает в себя множество примеров.
The Docker Book. www. dockerbook. сот.
• Блоr Container Solutions на сайте container-solutions. com/Ьlog
• TLJRNBULL,
JлмЕs.
содержит тех
нические советы, рекомендации и интервью с экспертами по контейнерам.
Глава 26
Непрерывная интеграция
и доставка
,/
Еще nримерно десять лет назад обновление nрограммного обеспечения было труд
ным и долгим делом. В nроцессе выnуска обычно исnользовались сnециальные, кустар
ные сценарии, которые вызывались в загадочном nорядке и соnровождались устаревшей
и неnолной документацией. Тестирование
-
если оно вообще существовало
-
вы
nолнялось груnnой контроля качества, которая была далека от цикла разработки и ча
сто становилась серьезным nреnятствием для nоставки кода конечному nотребителю.
Администраторы, разработчики и руководители nроектов были вынуждены nланировать
мительные nроцедуры на nоследних этаnах выnуска обновлений для текущих nользова
телей. Перебои в обслуживании часто nланировались за несколько недель.
Учитывая этот сомнительный контекст, неудивительно, что некоторые очень умные
люди усердно работали над улучшением ситуации. В конце концов там, где одни видят
только nроблемы, другие видят возможность.
Одним из наиболее мудрых сnециалистов в этой области является Мартин Фаулер
(Martin Fowler),
оракул индустрии nрограммного обесnечения и главный научный со
трудник влиятельной консалтинговой комnании
(goo. g l/Y2 li s I)
ThoughtW:>rks.
В nроницательной статье
Фаулер оnисывает неnрерывную интеграцию
(Continuous Integration)
как "nрактику разработки nрограммного обесnечения, в которой члены команды часто
интегрируют свою работу", тем самым устраняя одну из главных nроблем в работе nро
граммноrо обесnечения: утомительнуюзадачу согласования фрагментов кода, которые
отдалились друг от друга в течение длительного nериода независимой разработки. В на-
ЧастьlV.Эксплvатация
956
стоящее время практика непрерывной интеграции стала общепринятой среди разработ
чиков программного обеспечения.
Вершиной достижений в рамках этого подхода стала непрерывная доставка
Delivery),
(Continuous
которая похожа на концепцию непрерывной интеграции, но направлена на до
стижение другой цели: надежное развертывание обновленного программного обеспечения
в уже функционирующих системах. Непрерывная доставка подразумевает небольшие из
менения в информационной инфраструктуре. Если что-то выходит из строя (т.е. появля
ется регресс), этот подход позволяет легко изолировать и решить проблему, потому что
изменения между версиями малы. В крайних случаях некоторые организации стремятся
разворачивать новый код для пользователей несколько раз в день. Ошибки и насущные
проблемы безопасности можно решить в течение часов, а не дней или недель.
Сочетание концепций непрерывной интеграции и непрерывной доставки (далее обо
значается как
CI/CD)
охватывает инструменты и процессы, необходимые для облегче
ния частого, постепенного обновления программного обеспечения и конфигурации.
W
Дополнительную информацию о методологии
Концепция
Cl/CD
DevOps см.
является основой методологии
в разделе
DevOps.
31 .1.
Это подход, объединяю
щий как специалистов, которые занимаются разработкой, так и специалистов, которые
осуществляют эксплуатацию программного обеспечения. Это такой же бизнес-актив,
как и технические инновации. После внедрения концепция
Cl/CD
становится основой
информационной политики организации, поскольку она определяет логику и структуру
процессов выпуска, которые ранее были хаотичными.
Системные администраторы занимают центральное место в разработке, внедрении
и постоянном обслуживании систем
Cl/CD.
Администраторы устанавливают, настраи
вают и управляют инструментами, которые выполняют функцию
Cl/CD.
Они несут от
ветственность за то, чтобы процессы сборки программного обеспечения были быстрыми
и надежными.
Тестирование является важным элементом
Cl/CD. Администраторы
не могут писать те
сты (хотя иногда они это делают!), но они несут ответственность за настройку инфраструк
туры и систем, на которых выполняются тесты. Возможно, самое главное, что именно си
стемные администраторы отвечают за развертывание, т.е. компонент доставки
Эффективная система
CI/CD
Cl/CD.
реализуется не с помощью одиночного инструмен
та, а на основе комплексного программного обеспечения, которое работает в унисон,
формируя связанную среду. Существуют разнообразные средства с открытым исходным
кодом и коммерческие инструменты для координации различных элементов
Cl/CD.
Эти инструменты координации полагаются на другие пакеты программного обеспече
ния для выполнения фактической работы (например, компиляция кода или настройка
серверов в определенной конфигурации). Действительно, существует так много вариан
тов, что первоначальное знакомство с концепцией
Cl/CD
может быть ошеломляющим.
Кроме всего прочего, недавнее широкое распространение разнообразных инструментов
в этой области свидетельствует о растущем значении
CI/CD для
отрасли.
В этой главе мы попытаемся сориентироваться в лабиринте концепций, терминоло
гии и инструментов
CI/CD.
Мы освещаем основы конвейера
тестирования и их релевантность концепции
Cl/CD,
CI/CD,
различные типы
практику параллельной работы не
скольких сред и некоторые из наиболее популярных инструментов с открытым исход
ным кодом. В конце главы мы рассмотрим пример конвейера
Cl/CD,
в котором исполь
зуются некоторые из самых популярных инструментов. Прочитав эту главу, вы начнете
понимать принципы и методы, на которых основана мощная и гибкая система
CI/CD.
Глава
26. Непрерывная
интеграция и доставка
26.1. ОСНОВНЫЕ
957
КОНЦЕПЦИИ
Многие термины, относящиеся к
Cl/CD,
звучат одинаково и имеют перекрывающи
еся значения. Итак, давайте сначала рассмотрим различия между непрерывной интегра
цией, доставкой и развертыванием.
•
Непрерывная интеграция
(continuous integration - CI) -
это процесс совместной
работы с общей кодовой базой, слияние разрозненных изменений кода в систему
контроля версий и автоматическое создание и тестирование сборок.
•
Непрерывная доставка
(continuous delivery -
СО)
-
это процесс автоматического
развертывания сборок в непроизводственных средах после завершения процесса
непрерывной интеграции.
•
Непрерывное развертывание
(continuous deployment)
завершает цикл путем развер
тывания в функционирующих системах, которые обслуживают реальных пользо
вателей без какого-либо вмешательства оператора.
Непрерывное развертывание без какого-либо контроля со стороны людей может быть
пугающим, но это именно так: идея состоит в том, чтобы уменьшить фактор страха путем
развертывания программного обеспечения как можно чаще, тем самым устраняя все боль
ше и больше проблем, пока команда не будет достаточно уверенной в результатах тестиро
вания и инструментах, чтобы затем дать разрешение на автоматический выпуск.
Непрерывное развертывание не обязательно должно быть конечной целью всех ор
ганизаций. В любой момент в конвейере могут возникнуть проблемы и риски. Если это
так, вы все равно можете сделать так, чтобы каждый этап процесса был максимально
простым для человека, который нажимает последнюю кнопку. Каждая организация
должна устанавливать свои собственные границы.
Принципы и практика
Гибкость бизнеса является одним из ключевых преимуществ подхода
CI/CD.
Непрерывное развертывание облегчает выпуск проверенных функций на производстве
в течение нескольких минут или часов вместо недель или месяцев. Поскольку каждое
изменение собирается, тестируется и развертывается немедленно, разница между вер
сиями становится намного меньше. Это снижает риск развертывания и помогает сузить
круг причин возможных неполадок. Вместо того чтобы организовывать небольшое ко
личество развертываний в год после внесения большого количества изменений, вы мо
жете выпускать новый код несколько раз в неделю или даже в день.
Подход
Cl/CD
стимулирует выпускать новый функционал больше и чаще. Эта цель
достижима только тогда, когда разработчики пишут, отлаживают и фиксируют в общем
хранилище небольшие фрагменты кода. Чтобы реализовать непрерывную интеграцию,
разработчикам необходимо проводить фиксацию изменений кода не реже одного раза
в день после проведения локальных тестов.
Для системных администраторов процессы
CI/CD
значительно сокращают время,
затрачиваемое на подготовку и реализацию выпусков. Они также сокращают время от
ладки, если при развертывании возникают неизбежные проблемы. Немного на свете бо
лее приятных занятий, чем наблюдение за выпуском новой функции на производстве
без вмешательства человека. В следующих разделах описаны некоторые основные пра
вила, которые следует учитывать при разработке процессов
CI/CD.
ЧастьlV.Эксплvатация
958
Использовать контроль версий
Весь код следует отслеживать в системе контроля версий. Мы рекомендуем систему
Git,
но есть много вариантов. Само собой разумеется, что большинство команд разра
ботчиков программного обеспечения используют систему контроля версий.
В организациях, которые приняли на вооружение концепцию инфраструктуры как
кода (см. раздел "Подход
Cl/CD
на практике"), вы можете отслеживать инфраструк
турный код вместе с вашими приложениями. Вы даже можете хранить документы и на
стройки конфигурации в системе контроля версий.
Убедитесь, что контроль версий является единственным источником истины. Ничто
не должно управляться вручную или без фиксации записи.
Собирайте один раз, развертывайте часто
Конвейер
CI/CD
начинается со сборки. С этого момента результат сборки ("арте
факт") используется для тестирования и развертывания. Единственный способ подтвер
дить, что конкретная сборка готова к производству,
-
пропустить данную сборку через
все тесты. Разверните один и тот же артефакт по крайней мере в одной или двух средах,
которые как можно лучше соответствуют целевой производственной платформе.
Сквозная автоматизация
Сборка, тестирование и развертывание кода без ручного вмешательства является
ключом к надежным и воспроизводимым обновлениям. Даже если вы не планируете по
стоянно развертывать код на производстве, конечный шаг развертывания должен вы
полняться без вмешательства человека.
Собирайте каждую фиксацию в процессе интеграции
Интеграция объединяет изменения, сделанные несколькими разработчиками или ко
мандами разработчиков. Продукт представляет собой составную кодовую базу, которая
включает в себя все обновления. Интеграция не должна случайным образом прерывать
работу разработчиков и заставлять их помещать фрагменты кода в основную кодовую
базу; это верный путь к катастрофе. Отдельные разработчики несут ответственность за
управление собственным потоком разработки. Когда они будут готовы, они должны на
чать процесс интеграции. Интеграции должны происходить как можно чаще.
Интеграции выполняются через систему контроля версий исходного кода. Рабочий
процесс может быть разным. Ответственность за слияние своей работы с основной
веткой проекта (trunk) могут нести отдельные разработчики, или же назначенный на
блюдатель за выпусками может одновременно интегрировать работу сразу нескольких
разработчиков или команд. Процесс слияния может быть в значительной степени авто
матизирован, но всегда существует возможность конфликта между двумя наборами из
менений. Такая ситуация требует вмешательства человека.
Идея непрерывной интеграции заключается в том, что любая фиксация в интеграци
онной ветке системы контроля версий должна автоматически запускать процесс сборки.
"Интеграционная ветка" важна, потому что контроль версий исходного кода служит не
скольким целям. Помимо того, что он является средством сотрудничества и интеграции,
он также полезен как система резервного копирования, как контрольная точка для неза
вершенного производства и как система, которая позволяет разработчикам работать с не
сколькими обновлениями, сохраняя при этом изменения, связанные с этими обновле
ниями, логически раздельными. Таким образом, только фиксация результата интеграции
должна приводить к запуску процесса сборки.
Глава
26. Непрерывная
интеграция и доставка
959
Частая интеграция позволяет легко выявить причины неудачного построения сборки
и выявить точные строки кода, которые вызвали проблему. Затем система контроля вер
сий может определить личность ответственного разработчика. Но обратите внимание:
неисправная сборка не должна стать причиной административного наказания или стать
позором конкретного исполнителя. Наша цель состоит в том, чтобы снова запустить эту
сборку. Поощряйте политику отказа от поиска виновных в своих командах.
Разделяйте ответственность
Если что-то пойдет не так, конвейер необходимо исправить. Никакой новый код не
может быть внедрен до тех пор, пока предыдущая проблема не будет решена. Это экви
валентно остановке сборочной линии на производстве. Вся команда обязана исправить
сборку, прежде чем возобновить работу по разработке.
Подход
CI/CD
не должен быть таинственной системой, которая работает в фоновом
режиме и иногда отправляет электронную почту, если что-то идет не так, как ожидалось.
Каждый член команды должен иметь доступ к интерфейсу
CI/CD
для просмотра па
нелей мониторинга и журналов. В некоторых организациях создаются юмористические
виджеты, такие как светильники
RGB,
которые служат визуальным индикатором теку
щего состояния конвейера.
Собирайте быстро, исправляйте быстро
Подход
CI/CD
предназначен для обеспечения как можно более быстрой обратной
связи, в идеале в течение нескольких минут после фиксации кода в системе контроля
версий исходного кода. Этот быстрый отклик гарантирует, что разработчики обратят
внимание на результат. Если сборка завершится неудачей, разработчики, скорее всего,
смогут быстро решить проблему, потому что изменения, которые они только что внесли,
еще свежи в их памяти. Медленные процессы сборки контрпродуктивны. Стремитесь
устранять лишние и трудоемкие этапы. Убедитесь, что ваша система сборки имеет доста
точно агентов и что агенты имеют достаточные системные ресурсы для быстрой сборки.
Аудит и проверка
Часть системы
Cl/CD
включает подробную историю каждого выпуска программного
обеспечения, включая его переход от разработки к производству. Эта возможность от
слеживания может быть полезна для обеспечения развертывания только авторизован
ных сборок. Параметры и временные рамки событий, связанные с каждой средой, могут
быть неопровержимо подтверждены.
Среды
Приложения не работают изолированно. Они зависят от внешних ресурсов, таких
как базы данных, прокси-серверы, сетевые файловые системы, записи
DNS,
удаленные
интерфейсы НТТР АР!, другие приложения и внешние сетевые службы. Среда выполне
ния включает все эти ресурсы и все остальное, что необходимо для приложения, чтобы
оно могло работать. Создание и поддержание такой среды является объектом значитель
ного административного внимания.
Большинство организаций работают как минимум в трех средах, перечисленных
здесь в порядке возрастания важности.
•
Среда разработки для интеграции обновлений от нескольких разработчиков, те
стирования изменений инфраструктуры и проверки на наличие очевидных сбоев.
Эта среда используется главным образом техническим персоналом, а не бизнесме-
Часть
960
нами или конечными пользователями. В контексте
Cl/CD среда
IV. Эксплуатация
разработки может
создаваться и разрушаться несколько раз в день.
•
Промежуточная среда для ручного и автоматизированного тестирования и для
дальнейшей проверки изменений и обновлений программного обеспечения.
Некоторые организации называют ее тестовой средой. Тестировщики, владельцы
продуктов и другие заинтересованные стороны бизнеса используют промежуточ
ную среду для тестирования новых функций и исправления ошибок. Такие среды
могут также применяться для тестирования незаконного проникновения и других
проверок безопасности.
•
Производственная среда для предоставления услуг конечным пользователям. Про
изводственная среда обычно включает в себя обширные меры дr1я обеспечения высо
кой производительности и безопасности. Сбой на производстве
-
это чрезвычайная
ситуация, которая должна быть устранена немедr1енно общими усилиями.
Типичная система
Cl/CD
последовательно продвигает программное обеспечение че
рез каждую из этих сред, отфильтровывая ошибки и дефекты программного обеспечения
на этом пути. Вы можете с уверенностью развернуть приложение в производственной сре
де, потому что знаете, что изменения уже были протестированы в двух других средах.
Паритет сред является предметом некоторой сложности дr1я системных администрато
ров. Цель непроизводственных, или "нижних". сред заключается в подготовке и анализе
изменений всех типов до перехода на стадию производства. Существенные различия меж
ду средами могут привести к непредвиденной несовместимости, которая в конечном итоге
может вызвать ухудшение производительности, простои или даже разрушение данных.
Например, представьте, что среда разработки и промежуточного тестирования под
верглась обновлению операционной системы, но в производственной среде все еще
работает ее более старая версия. Пришло время для развертывания программного обе
спечения. Новое программное обеспечение тщательно проверено на стадиях разработки
и тестирования и, похоже, работает нормально. Однако во время развертывания в про
изводственной среде становится очевидной неожиданная несовместимость, поскольку
в старой версии определенной библиотеки отсутствует функциональная возможность,
используемая в новом коде.
Этот сценарий довольно распространен, и это одна из причин, по которой систем
ные администраторы должны проявлять бдительность в отношении синхронизации
сред. Чем ближе производственная среда к среде более низкого уровня, тем выше ваши
шансы на поддержание высокой доступности и доставки программного обеспечения.
Запуск нескольких сред на полную мощность может быть дорогостоящим и трудоем
ким. Поскольку производственная среда обслуживает гораздо больше пользователей, чем
среды более низкого уровня, в этой среде обычно необходимо запускать больше дорогих
систем. Наборы данных на производстве, как правило, крупнее, поэтому выделенное под
него дисковое пространство и мощности сервера пропорционально увеличиваются.
Даже такой тип различий между средами может вызвать непредвиденные проблемы.
Неправильная конфигурация балансировки нагрузки, которая не имеет значения в сре
дах разработки и тестирования, может выявить дефект. Или запрос базы данных, кото
рый быстро запускается в средах разработки и тестирования, может оказаться намного
медленнее при применении к данным производственного масштаба.
Совместимость производственных мощностей в средах более низкого уровня
-
сложная
проблема. Стремитесь иметь хотя бы одну среду более низкого уровня, у которой есть избы
точность там же, где она есть в производственной среде (например, несколько неб-серверов,
Глава
961
Непрерывная интеграция и доставка
26.
полностью реruшцированные базы данных и соответствующие стратегии перехода на другой
ресурс в случае отказа ДllЯ любых кластерных систем). Это нормально ДllЯ промежуточных
серверов меньшего размера, хотя любые тесты, которые вы запускаете Д/IЯ проверки произ
водительности, не будут отражать реальные производственные показатели.
Для достижения наилучших результатов наборы данных в средах более низкого уров
ня должны быть схожими по размеру и содержанию с объемами данных в производ
ственной среде. Одна из стратегий
-
создавать по ночам снимки всех соответствующих
производственных данных и копировать их в среду более низкого уровня. Для обеспече
ния соблюдения и обеспечения наД11ежащей гигиены безопасности конфиденциальные
пользовательские данные должны быть сделаны анонимными до того, как они будут ис
пользованы таким образом. Для действительно массивных наборов данных, которые не
целесообразно копировать, импортируйте меньший, но все еще значимый образец.
Несмотря на все ваши усилия, среда более низкого уровня никогда не будет похожа
на производственную среду. Некоторые параметры конфигурации (такие как учетные
данные, URL-aдpeca, адреса и имена хостов) будут отличаться. Используйте управление
конфигурацией ДllЯ отслеживания этих элементов конфигурации между средами. Когда
система
Cl/CD
запускает развертывание, проконсультируйтесь с вашим авторитетным
источником, чтобы найти соответствующую конфигурацию Д/IЯ этой среды, и убедитесь,
что все среды развернуты одинаково.
Флаги функций
Флаг функции включает или отключает функцию приложения в зависимости от зна
чения параметра конфигурации. Разработчики могут создавать поддержку флагов
функций в своем программном обеспечении. Вы можете использовать флаги функций
ДllЯ включения определенных функций в определенных средах.
Например, вы можете включить некоторую функцию в тестовой среде, оставив ее
отключенной в производственной среде до тех пор, пока она не будет полностью про
тестирована и готова ДllЯ широкого использования.
В качестве примера рассмотрим приложение ДllЯ электронной торговли с корзиной
покупок. Руководство хочет запустить рекламную кампанию, требующую внесения в код
некоторых изменений. Команда разработчиков может создать эту функцию и внедрить
ее авансом во все три среды, но включить ее только в средах разработки и тестирования.
Когда руководство будет готово проводить рекламные акции, ДllЯ включения этой функ
ции нужно просто изменить параметры конфигурации с низким уровнем риска, а не де
лать выпуск новой версии программного обеспечения. Если функция содержит ошибку,
ее легко отключить без обновления программного обеспечения.
26.2.
КОНВЕЙЕРЫ
Конвейер
Cl/CD представляет собой последовательность шагов,
- это по существу сценарий, который выполняет
ми. Каждый этап
называемых этапа
задачи, специфич
ные для вашего программного проекта.
На базовом уровне конвейер
•
•
•
Cl/CD
выполняет следующие функции.
Надежная сборка и упаковка программного обеспечения.
Выполнение ряда автоматических тестов ДllЯ поиска ошибок конфигурации.
Развертывание кода в одной или нескольких средах, включая производственную.
962
ЧастьlV.Эксплvатация
На рис.
26. \
показаны этапы простого (но вполне зрелого) конвейера
Развертывание
Развертывание
настаАИИ
на стадии
разработки
Cl/ CD.
Развертывание
на стадии
тестирования
п
оизво
ства
Зрелость
Рис.
26. 1.
Конвейер
Cl/CD
В следующих разделах эти три этапа описаны более подробно.
Процесс сборки
Сборка
-
это моментальный снимок текущего состояния программного проекта.
Это, как правило, первый этап любого конвейера
Cl/CD,
возможно, после этапа ана
лиза кода, на котором происходит контролирование качества кода и поиск угроз без
опасности . Этап сборки преобразует код в инсталлируемую часть программного обеспе
чения . Сборка может быть инициирована фиксацией в ветке интеграции репозитория
кода либо выполняться по регулярному расписанию или по требованию.
Каждый запуск конвейера начинается со сборки, но не каждая сборка достигает
производства. После того как произойдет тестирование, сборка станет "кандидатом
на выпуск". Если кандидат на выпуск фактически развертывается для работы в произ
водственной среде, он становится "выпуском". Если вы выполняете непрерывное раз
вертывание, каждый кандидат на выпуск также является выпуском . Эти категории про
и.1люстрированы на рис.
26.2.
Сборки
(
при изменении кода
26.2.
на выпуск
)
Каждый раз
Рис.
Кандидаты
После прохождения
Развертывание
всех тестов
для производства
Сборки, кандидаты 11а выпуск и выпуски
Точное содержание этапов процесса сборки зависят от языка и программного обе
спечения. Для программ на языках С, С++ или
Go процесс сборки представляет собой
make, которая приводи т к исполняе
требуют компиляции , таких как Python
компиляцию, часто инициированную командой
мому двоичному коду. Для языков, которые не
ил~1
Ruby,
этап сборки может включать упаковку проекта со всеми соответствующими
зависимостями и ресурсами, включая библиотеки, образы , шаблоны и файлы разметки .
Некоторые сборки могут включать только изменения конфигурации.
Глава
26.
963
Непрерывная интеграция и доставка
Результатом этапа сборки является "артефакт сборки". Характер этого артефак
та зависит от программного обеспечения и конфигурации остальной части конвейера.
В табл.
26.1
перечислены некоторые из распространенных типов артефактов. Независимо
от формата, артефакт является основой для развертывания в остальной части конвейера.
Таблица
Статически скомпилированные программы, обычно на языках С или
Пакеты программного обеспечения для операционных систем
Go
Red Hat или
Deblan
Пакет pip или пакет
qem
Упакованные приложения
Python
или
Ruby
Образ контейнера
Приложения, выполняемые на платформе
Образ машины
Виртуальные серверы, особенно для открытых или закрытых облаков
Файл .ехе
Исполняемый файл
Docker
Windows
Артефакты сборки сохраняются в хранилище артефактов. Тип репозитория зави
сит от типа артефакта. В своем простейшем случае репозиторий может быть каталогом
на удаленном сервере, доступным через SFТP или
зиторий
yum
такое как
или АРТ, репозиторий образов
AWS
Docker
NFS.
Это также может быть репо
или хранилище объектов в облаке,
SЗ. Репозиторий должен быть доступен для всех систем, которые должны
загружать и инсталлировать артефакт во время развертывания.
Тестирование
На каждом этапе конвейера
Cl/CD
выполняются тесты, чтобы выявлять ошибочный
код и плохие сборки, чтобы код, который дошел до этапа производства, не имел дефек
тов (или по крайней мере был как можно более надежным). Основой этого процесса яв
ляется тестирование. Это порождает доверие к тому, что выпуск готов к развертыванию.
Если сборка не проходит какой-либо тест, оставшиеся этапы конвейера не имеют
смысла. Команда разработчиков должна определить, почему сборка не удалась, и ре
шить основную проблему. nоскольку сборки создаются для каждой фиксации кода, лег
ко изолировать проблему до последней фиксации. Чем меньше строк кода изменяется
между сборками, тем легче изолировать проблему.
Неудачи не всегда связаны с ошибками программного обеспечения. Они могут воз
никать из-за проблем с сетью или ошибок инфраструктуры, требующих административ
ного внимания. Если приложение зависит от внешних ресурсов, таких как сторонние
сбои могут возникать во внешнем ресурсе. Одни тесты могут выполняться изоли-.
API,
рованно, но для других тестов требуется та же инфраструктура и данные, которые будут
присутствовать в производственной версии.
Рассмотрите возможность добавления каждого из следующих типов тестов в конвей
ер
Cl/CD.
•
Анализ статического кода позволяет выявить синтаксические ошибки, дублирова
ния, нарушения правил кодирования, проблемы с безопасностью или чрезмерной
сложностью. Эти проверки выполняются быстро и не требуют выполнения факти
ческого кода.
•
Модульные тесты, написанные теми же разработчиками, которые пишут код прило
жения, отражают представление разработчика о том, как должен функционировать
964
ЧастьlV.Эксплуатация
код. Цель состоит в проверке ввода и вывода каждого метода и функции (модуля)
в коде. "Покрытие кода"
-
это (иногда вводящий в заблуждение) показатель, кото
рый описывает, какая часть кода подвергается модульному тестированию. 1
•
Тесты интеграции
-
это модульные тесты, которые выполняются после запуска
приложения в его предполагаемой среде исполнения. Эти тесты запускают прило
жение с его базовыми каркасами и внешними зависимостями, такими как внеш
ние
•
API,
базы данных, очереди и кеши.
Приемочные тесты отражают точку зрения пользователя. Для веб-программ этот
этап может включать дистанционное управление загрузкой страниц браузера с по
мощью таких инструментов, как
Selenium.
Для мобильного программного обе
спечения артефакт сборки может поступать на ферму устройств, которая запуска
ет приложение на разных мобильных устройствах. Различные браузеры и версии
делают приемочные испытания сложными для создания, но в конце концов эти
тесты имеют значимые результаты.
•
Тесты производительности предназначены для поиска проблем производительно
сти, связанных с последним кодом. Чтобы выявить узкие места, эти так называемые
стресс-тесты должны выполнить приложение в идеальном клоне вашей производ
ственной среды с реальным поведением трафика. Такие инструменты, как
или
Gatling,
JMeter
могут моделировать тысячи одновременных пользователей, взаимодей
ствующих с приложением в запрограммированном шаблоне. Чтобы получить мак
симальную отдачу от тестирования производительности, убедитесь, что у вас уста
новлены контрольные и графические средства. Эти инструменты проясняют как
типичную производительность приложения, так и его поведение в новой сборке.
•
Инфраструктурные тесты идут рука об руку с программной облачной инфра
структурой. Если вы создаете временную облачную инфраструктуру как часть кон
вейера
CI/CD,
вы можете написать тестовые примеры, чтобы проверить правиль
ную конфигурацию и работу самой инфраструктуры. Успешно ли работает система
управления конфигурацией'? Выполняются ли только ожидаемые демоны? Один
из интересных инструментов в этой области
m
- Serverspec (serverspec. org).
Дополнительную информацию о системах мониторинга и графических системах
см. в главе
28.
В зависимости от характеристик вашего проекта некоторые тесты могут оказаться важ
нее других. Например, программное обеспечение, которое реализует интерфейс
REST API,
не нуждается в приемочных тестах с применением браузера. Вместо этого вы, скорее всего,
сосредоточитесь на тестах интеграции. С другой стороны, для программного обеспечения
интернет-магазина обязательно требуется проверка в браузере всех важных пользователь
ских маршрутов (каталог, страницы продукта, корзина, оформление заказа). Рассмотрите
потребности своего проекта и соответствующим образом выполните тестирование.
Рабочие процессы не обязательно должны быть линейными. На самом деле, поскольку
одна из целей заключается в том, чтобы как можно быстрее получить обратную связь, ре
комендуется проводить как можно больше тестов параллельно. Но имейте в виду, что одни
тесты могут зависеть от результатов других тестов; некоторые могут потенциально мешать
друг друrу. (В идеале тесты не должны иметь перекрестных зависимостей.)
1
Код, который трудно тестировать, скорее всего, имеет дефекты. У вашего кода может быть
85%
покрытия кода (что довольно много по отраслевым стандартам), но если самый сложный код не
протестирован, ошибки могут быть пропущены. Одно лишь покрытие кода не ямяется адекватной
мерой качества кода.
Глава
26. Непрерывная
интеграция и доставка
965
Избегайте соблазна игнорировать или недооценивать неудачные тесты. Иногда воз
никает привычка снисходительно относиться к некоторым причинам сбоя, считая их
безвредными или неважными, и подавлять тест. Однако такой образ мыслей опасен
и может привести к менее надежной системе тестирования. Имейте в виду золотое пра
вило
Cl/CD:
исправление неисправного конвейера является главным приоритетом.
Чтобы укрепить этот принцип, сделайте почти невозможным игнорирование неудач
ных тестов. Обязательно установите техническое требование с помощью программно
го обеспечения
Cl/CD:
развертывание в производственной среде не может произойти,
если есть какие-либо неудачные тесты.
Развертывание
Развертывание
-
это процесс установки программного обеспечения и подготов
ки его для использования в среде сервера. Специфика того, как это делается, зависит
от набора технологий. Система развертывания должна понимать, как извлечь артефакт
сборки (например, из репозитория пакетов или реестра образов контейнеров), как уста
новить его на сервере и какие шаги настройки необходимы, если таковые имеются.
Развертывание завершается, когда новая версия программного обеспечения запущена,
а старая версия отключена.
Развертывание может быть очень простым, как, например, обновление некоторых
файлов
HTML
на диске. При этом не требуется перезагрузка сервера или его дальней
шая настройка! Однако для большинства случаев развертывание включает по крайней
мере установку пакета и перезапуск приложения. Комплексное развертывание крупно
масштабного приложения в производственной среде может включать в себя установку
кода на нескольких серверах при одновременном обработке трафика в реальном време
ни без приостановки обслуживания.
Системные администраторы играют важную роль в процессе развертывания. Обычно
они отвечают за создание сценариев развертывания, мониторинг важных индикаторов
работоспособности приложений во время развертывания и обеспечение соответствия
потребностей инфраструктуры и конфигурации другим членам команды.
В следующем списке описано несколько возможных способов развертывания про
граммного обеспечения.
•
Запустите базовый сценарий оболочки, который вызывает программу
ssh для
вхо
да в систему, загрузки и установки артефакта сборки, а затем перезапускает при
ложение. Эти типы сценариев обычно разрабатываются самостоятельно и не вы
ходят за рамки небольшого количества систем.
•
Используйте инструмент управления конфигурацией для организации процесса
инсталляции с помощью управляемого набора систем. Эта стратегия более орга
низована и масштабируема, чем использование сценариев оболочки. Большинство
систем управления конфигурацией не предназначены специально для облегчения
развертывания, хотя они могут использоваться для этой цели.
•
Если артефакт сборки представляет собой образ контейнера, и приложение запуска
ется на платформе управления контейнером, такой как
или
AWS ECS,
Kubernetes, Docker Swarm
API
развертывание может быть не более чем быстрым вызовом
для диспетчера контейнеров. Служба контейнера самостоятельно управляет осталь
ной частью процесса развертывания (см. раздел "Контейнеры и подХод
•
Cl/CD").
Существует несколько проектов с открытым исходным кодом, которые позволяют
стандартизировать и упростить развертывание.
Capistrano (capistranorb. com) -
966
ЧастьlV.Эксплуатация
это инструмент развертывания на основе языка
Rake Ruby
Ruby,
который расширяет систему
для запуска команд на удаленных системах.
это аналогичный инструмент, написанный на языке
Fabric
Python.
(faЬfile.
org) -
Эти инструменты,
предназначенные для разработчиков, в основном служат для создания сценариев
оболочки.
Развертывание программного обеспечения
•
это хорошо изученная проблема
-
для поль:ювателей публичных облаков. Большинство облачных экосистем включа
ют в себя как интегрированные, так и сторонние службы развертывания, которые
могут использоваться из конвейера
AWS CodeDeploy
и
Cl/CD,
например
Google Deployment Manager,
Heroku.
Примените технологию развертывания к арсеналу технологий вашей организации с уче
том ее потребностей. Если у вас простая среда с несколькими серверами и небольшое ко
личество приложений, то может быть уместным использование инструмента управления
конфигурацией. В организациях с большим количеством серверов, распределенных между
центрами обработки данных, требуется специализированное средство развертывания.
Термин неизменяемое развертывание (immutaЫe
deployment)
означает принцип, со
гласно которому серверы никогда не должны изменяться после их инициализации.
Чтобы развернуть новую версию, инструментарий
Cl/CD
создает совершенно новые
серверы с обновленным артефактом сборки, включенным в образ. В этой модели сер
веры считаются одноразовыми и временными. Эта стратегия основана на программиру
емой инфраструктуре, такой как открытое или закрытое облако, где экземпляры могут
быть распределены через вызов интерфейса
API.
Некоторые из крупнейших пользовате
лей открытого облака применяют неизменяемые варианты развертывания.
В разделе "Подход
Cl/CD
на практике" мы рассмотрим пример неизменяемого
развертывания, в котором используется инструмент
Terraform
от компании
HashiCorp
для создания и обновления инфраструктуры.
Методы развертывания с нулевым временем простоя
В некоторых организациях службы должны продолжать работать даже во время их об
новления или повторноrо развертывания либо потому, что из-за сбоя возникает неприем
лемый риск (в области здравоохранения или государственных услуг) или это может при
вести к значительным финансовым затратам (в области крупной электронной торговли
или финансовых услуг). Обновление программного обеспечения в реальном времени без
прерывания обслуживания
-
это высший пилотаж в сфере развертывания программного
обеспечения и одновременно источник большого беспокойства и трудностей.
Одним из распространенных способов достижения выпуска с нулевым временем
простоя является "сине-зеленое" развертывание. Концепция проста: запустите новое
программное обеспечение в резервной системе (или наборе систем), выполните тесты,
чтобы подтвердить его функциональность, а затем переключите трафик из реальной си
стемы в резервную после завершения тестов.
Эта стратегия работает особенно хорошо, когда трафик проксируется через баланси
ровщик нагрузки. Реальные системы обрабатывают все пользовательские соединения,
пока готовятся резервные системы. В подходящий момент можно добавить в баланси
ровщик нагрузки резервные системы и удалить предыдущие системы. Развертывание за
вершено, когда все старые системы находятся вне ротации и все транзакции, которые
они обрабатывают, завершились.
m
Дополнительную информацию о балансировщиках нагрузки см. в разделе
19.2.
Глава
26.
Непрерывная интеграция и доставка
Плавное развертывание
967
поэтап
(rolling deployment) обновляет существующие системы
но, изменяя программное обеспечение в одной системе за один раз. Каждая система уда
ляется из балансировщика нагрузки, обновляется, а затем добавляется обратно в ротацию
для обработки пользовательского трафика. Такой тип развертывания может вызвать проб
лемы, если приложение не допускает существования двух разных версий одновременно.
Стратегии сине-зеленого и плавного развертывания можно совместить с подхо
дом, который называется "канареечным", по аналогии с канарейкой в угольной шахте.
Сначала вы направляете небольшой объем трафика в одну систему (или небольшой про
цент систем), которая запускает новую версию. Если у новой версии есть проблемы, вы
ее отключаете и исправляете проблему, оказывая влияние только на нескольких пользо
вателей. Конечно, канареечным системам нужна точная телеметрия и мониторинг, что
бы вы могли вовремя определить, не появились ли новые проблемы.
СЕРВЕР АВТОМАТИЗАЦИИ
26.3. JENКINS:
С ОТКРЫТЫМ ИСХОДНЫМ КОДОМ
это сервер автоматизации, написанный на языке
Jenkins -
Java.
Это, безусловно, са
мое популярное программное обеспечение, используемое для реализации подхода
$ docker run
-р
CI/
модулей
CD. Благодаря широкому внедрению и обширной экосистеме подключаемых
Jenkins хорошо подходит для различных вариантов использования.
Сервер Jenkins несложно запустить в контейнере Docker:
8080:8080 --name jenkins jenkinsci/jenkins
После запуска контейнера вы можете получить доступ к пользовательскому интер
фейсу
Jenkins
в веб-браузере через порт
8080.
Начальный пароль администратора будет
указан в сообщениях, выводимых контейнером. На практике вам нужно немеш1енно из
менить этот пароль!
Для изучения основ подойдет конфигурация с одним контейнером, но в производ
ственных средах, скорее всего, потребуется более надежное решение. На странице загруз
ки сервера
Jenkins (j enkins. io/ download) есть инструкции
по инсталляции, которые мы
не будем здесь повторять. Обратитесь к этим документам для инсталляции сервера в опе
рационных системах
Linux
и
FreeBSD.
Компания
CloudBees,
У сервера
Jenkins
Jenkins,
Jenkins Enterprise.
создатель сервера
также предлагает версию с высокой доступностью под названием
есть подключаемые модули для каждой мыслимой задачи.
Используйте подключаемые модули для выполнения сборок в разных типах агентов, от
правки уведомлений, координации выпусков и выполнения запланированных заданий.
Подключаемые модули взаимодействуют с инструментами с открытым исходным ко
дом и со всеми основными облачными платформами и внешними поставщиками
Именно подключаемые модули обеспечивают сверхспособности серверу
Большинство настроек
Jenkins
SaaS.
Jenkins.
выполняются через неб-интерфейс, и, проявляя \Ш
лосердие к вашему вниманию, мы не пытаемся описать все нюансы пользовательского
интерфейса. Вместо этого мы представляем основы работы сервера Jeпkins и некоторые
из его наиболее важных особенностей.
Основные концепции сервера
По сути,
Jenkins -
Jenkins
это координирующий сервер, который связывает ряд инструмен
тов в цепочку, или, используя терминологию
CI/CD,
конвейер. Сервер
Jenkins
является
организатором и посредником; вся фактическая работа зависит от внешних служб, та-
968
ЧастьlV.Эксплуатация
ких как репозитории исходного кода, компиляторы, инструменты сборки, средств тес
тирования и системразвертывания.
Задание
(job)
для сервера
Создание проекта
Jenkins,
или проект,
-
это коллекция связанных этапов.
это задача первостепенной важности для новой инсталляции. Вы
-
можете связать этапы проекта, чтобы они выполнялись последовательно или параллель
но. Вы можете даже настроить условные этапы, которые делают разные вещи в зависи
мости от результатов предыдущих этапов.
Каждый проект должен быть подключен к репозиторию исходного кода. У серве
ра
Jenkins есть собственная поддержка почти каждой системы контроля версий: Git,
Subversion, Mercurial и даже таких древних систем, как CVS. Существуют также подклю
чаемые модули интеграции для более высокоуровневых служб контроля версий, таких
как
GitHub, Gitl...ab
и
BitBucket.
Вам нужно будет предоставить серверу
Jenkins
соответ
ствующие учетные данные, чтобы он мог загружать код из вашего репозитория.
"Контекст сборки"
это текущий рабочий каталог системы
(build context) -
Jenkins.
в котором выполняется сборка. Исходный код копируется в контекст сборки вместе
с любыми поддерживающими файлами, которые необходимы для сборки.
Подключив сервер
Jenkins
к репозиторию контроля версий, вы сможете создать триг
гер сборки. Это сигнал для сервера
процесс сборки. Сервер
Jenkins
Jenkins скопировать текущий
исходный код и начать
может опросить исходный репозиторий в поисках но
вых фиксаций, и коrда он ее найдет
-
инициировать сборку. Он также может запускать
сборку по расписанию или запускаться с помощью веб-триггера, который поддержива
ется репозиторием
GitHub.
После настройки трипера создайте этапы сборки, т.е. конкретные задачи, которые
будут создавать сборку. Этапы моrут быть специфичными для кода или универсальными
сценариями оболочки. Например, проекты
Java обычно создаются с помощью инструмен
Jenkins поддерживает Maven напрямую, поэтому вы мо
жете просто добавить этап сборки Maven. Для проекта, написанного на языке С, первый
этап сборки может быть просто сценарием оболочки, который запускает команду make.
та
Подключаемый модуль
Maven.
Остальные этапы сборки зависят от целей вашего проекта. Наиболее распространен
ные сборки включают этапы, которые инициируют задачи тестирования, обсуждаемые
выше в разделе "Тестирование". Вам может понадобиться этап для создания произволь
ного артефакта сборки, такого как архив
tar,
пакет операционной системы или образ
контейнера. Вы также можете включить этапы, которые инициируют уведомления ад
министратора, предпринимают действия, связанные с развертыванием, или координи
руются с помощью внешних инструментов.
Для проекта
Cl/CD
этапы сборки могут охватывать все этапы конвейера: создавать
код, запускать тесты, загружать артефакт в репозиторий и запускать развертывание.
Каждый этап конвейера является всего лишь этапом сборки в рамках проекта
Jenkins.
Интерфейс
Jenkins
представляет собой обзор состояния каждого этапа. поэтому
легко увидеть, что происходит в конвейере.
Организации, в которых есть мноrо приложений, должны иметь отдельные проекты
Jenkins
для каждого приложения. Каждый проект будет иметь отдельный репозиторий
кода и этапы сборки. Система
Jenkins требует для
запуска сборки в любом из своих про
ектов наличия всех инструментов и зависимостей. Например, если вы настроили проект
на языке
Java и проект на языке С, ваша
Maven, так и к команде make.
система
Jenkins должна
иметь доступ как к ин
струменту
Проекты моrут зависеть от других проектов. Используйте это в своих интересах, струк
турируя проекты как общие, наследуемые шаблоны. Например, если у вас есть множество
приложений, которые построены по-разному, но развернуты одинаково (например, как
Глава
26.
969
Непрерывная интеграция и доставка
контейнеры, запущенные на кластере серверов), вы можете сщдать общий проект "развер
тывания". который упраRЛяет общим этапом развертывания. Оrдельные проекты приложе
ний мoryr выполнять проект развертывания, тем самым устраняя шаг избыточной сборки.
Распределенные сборки
В тех средах, где поддерживаются десятки приложений, причем каждое со своими
зависимостями и этапами сборки, легко непреднамеренно создать конфликты зависи
мостей и узкие места, поскольку сразу запускается слишком много конвейеров. Чтобы
компенсировать это, сервер
Jenkins
позволяет вам перейти в распределенную архитек
туру сборки. В этом режиме работы используется "мастер сборки", центральная систе
ма, которая отслеживает все проекты и их текущее состояние, а также "агенты сборки",
которые выполняют фактические этапы сборки для проекта. Если вы часто используете
сервер
Jenkins,
то довольно быстро перейдете к этой конфигурации.
Аrенты сборки запускаются на хостах, которые отделены от мастера сборки. Мастер сер
вера
Jenkins
подключается к подчиненным системам (обычно через протокол
SSH),
чтобы
запустить процесс агента и добавить метки, которые документируют возможности подчи
ненных систем. Например, вы можете отличить своих агентов, поддерживающих язык
Java,
от ваших же агентов с поддержкой языка С, применяя соответствующие метки. Для дости
жения наилучших результатов запускайте агенты в контейнерах, удаленных виртуальных
машинах или временных облачных средах, которые масштабируются и возвращаются в ис
ходное состояние по требованию. Если у вас есть кластер контейнеров, вы можете исполь
зовать подключаемые модули
Jenkins для
запуска агентов в кластере через систему упраRЛе
ния контейнерами.
Конвейер как код
До сих пор мы описали процесс создания проектов
Jenkins,
объединяя отдельные
этапы сборки в веб-интерфейсе. Это самый быстрый способ начать работу с сервером
Jenkins,
но с точки зрения инфраструктуры это немного непрозрачно. Код
контексте им является содержимое каждого этапа сборки
-
-
в данном
управляется сервером
Jenkins.
Вы не можете проверять этапы сборки в репозитории кода с помощью графического ин
струмента, и если вы потеряете сервер
Jenkins,
у вас не будет простого способа его заме
нить; вам нужно будет восстановить свои проекты из недавней резервной копии.
Во второй версии сервера
Jenkins введена
новая основная функция, называемая
которая обеспечивает первоклассную поддержку конвейеров
Cl/CD.
Pipe\ine,
Jenkins
В конвейере
этапы проекта кодируются в декларативном стиле, специфичном для предметно-ориенти
рованного языка, который основан на языке программирования
дать код
Jenkins,
называемый
Следующий код
ния
-
Jenkinsfile, вместе с
Jenkinsfile демонстрирует
развертывания.
pipeline {
agent any
stages {
stage ( 'Build')
steps {
sh 'make'
stage ( 'Test')
steps {
Groovy.
Вы можете пере
кодом, связанным с конвейером.
базовый цикл сборки
-
тестирова
ЧастьlV.Эксплуатация
970
sh 'rnake test'
stage ( 'Deploy' )
steps {
sh 'deploy.sh'
Выражение
agent any
инструктирует сервер
Jenkins
подготовить рабочую область
для этого конвейера на любом доступном агенте сборки. 2 Этапы сборки, тестирования
и развертывания соответствуют концептуальным этапам конвейера
Cl/CD. В нашем приме
(sh) для выполнения команды.
сценарий deploy. sh, который
ре каждый этап имеет один шаг, который вызывает оболочку
На этапе развертывания выполняется собственный
обрабатывает все развертывание, включая копирование артефакта сборки (сгенериро
ванного на этапе
Build)
на набор серверов и перезапуск серверных процессов. На прак
тике развертывание обычно делится на несколько этапов, чтобы обеспечить лучшую ви
димость и контроль над полным процессом.
26.4. Подход Cl/CD НА ПРАКТИКЕ
Теперь мы переЙдем к искусственному примеру, чтобы проиллюстрировать представ
ленные нами концепции. Мы придумали простое приложение
UlsahGo,
намного более
основательное, чем все, что вам может понадобиться для управления в реальном мире.
Оно полностью автономное и не имеет зависимостей от других приложений.
Наш пример включает следующие элементы:
•
•
•
неб-приложение
UlsahGo с
одной небольшой функцией;
модульные тесты для приложения;
образ виртуальной машины для облачной инфраструктуры
Digita\Ocean,
которая
содержит приложение;
•
•
•
односерверную среду разработки, создаваемую по требованию;
многосерверную среду с балансировкой нагрузки, создаваемую по требованию;
конвейер
Cl/CD,
который соединяет все эти части вместе.
В этом примере мы используем несколько популярных инструментов и служб:
• GitHub как репозиторий кода;
• виртуальные машины Digita\Ocean и балансировщики нагрузки;
• упаковщик HashiCorp для обеспечения образа для облачной инфраструктуры
Digita\Ocean;
• инструмент Terraform от HashiCorp для создания среды развертывания;
• сервер Jenkins для управления конвейером Cl/CD.
В ваших приложениях может использоваться другой набор технологий, но общие по
нятия похожи, независимо от арсенала используемых инструментов.
2 Рабочая
область
-
это синоним контекста сборки: место на локальном диске агента, в котором
содержатся все файлы, необходимые для сборки, включая исходный код и зависимости. Каждая
сборка имеет частное рабочее пространство.
Глава
26.
971
Непрерывная интеграция и доставка
На рис.
26.1
показаны первые несколько этапов примерного конвейера. На диаграм
GitHub в поисках новых фиксаций в проект UlsahGo. Когда
Jenkins запускает блок тестирования. Если тесты проходят, сервер
Подробное описание этапов развертывания приводится ниже, но сначала мы долж
ны рассмотреть начальные этапы .
Тривиальное веб-приложение
UlsahGo
Приложение из нашего примера предстамяет собой веб-службу с одной функцией.
Оно возвращает список, авторов, связанных с указанным изданием этой книги, в формате
JSON.
Например, следующий запрос отображает имена авторов указанного издания.
$ curl ulsahgo . admin.com/?edition=S
{
"authors": [
"Evi",
"Garth",
"Trent",
"Ben",
"Dan"
]
'
"numЬer":
5
При обработке этого запроса мы должны выполнить простую проверку корректности
полученных данных, чтобы убедиться, что пользователи не слишком умекаются, напри
мер запрашивая неправдоподобные номера изданий.
$ curl -vs ulsahgo.admin.com/?edition=б
< НТТР/1.1 404 Not Found
< Content - Type : applicat io n /j son
"error":
" бth
ed iti o n i s inva lid . "
Наше приложение имеет также специальную точку входа для проверки работоспо
собности. Проверка работоспособности
-
это простой способ для мониторинга систем,
чтобы спросить приложение : "Привет, все хорошо?"
$ curl ulsahgo.admin.com/healthy
{
ЧастьlV.Эксплvатация
972
"healthy": "true"
Разработчики обычно тесно сотрудничают с администраторами в процессе со:щания
этапов сборки и тестирования конвейера
ние написано на языке
build и go test)
Go,
Cl/CD.
В данном случае, поскольку приложе
мы можем использовать стандартные инструменты
Go (go
в нашем конвейере.
Модульное тестирование
Модульные тесты
-
UlsahGo
это первый тестовый набор для запуска, поскольку они работают
на уровне исходного кода. Модульные тесты проверяют функции и методы приложения
с максимально возможной детализацией. Для большинства языков программирования соз
даны тестовые каркасы, в которых реализована встроенная поддержка модульных тестов.
Давайте проанализируем один модульный тест для
UlsahGo.
Рассмотрим следующую
функцию.
func ordinal(n int) string {
suffix := "th"
switch n {
case 1:
suf f ix
"st"
case 2:
suffix
"nd"
case 3:
suffix
"rd"
return strconv.Itoa(n) + suffix
Этой функции в качестве входного параметра передается целое число, а она определя
ет соответствующее порядковое выражение. Например, если функции передан аргумент,
равный
1, то она
возвращает строку
"lst".
Программа
UlsahGo
использует эту функцию
для форматирования текста в сообщении об ошибке для недопустимых номеров изданий
книг.
Модульные тесты пытаются доказать, что при произвольных входных данных функ
ция всегда возвращает ожидаемый результат. Вот модульный тест, который выполняет
эту функцию.
func TestOrdinal(t *testing.T)
ord := ordinal(l)
ехр := "lst"
i f ord != ехр {
t.Error("expected %s, got %s",
ord
ехр
ехр,
ord)
ехр,
ord)
= ordinal(lO)
= "lOth"
i f ord !=
ехр {
t.Error("expected %s, got %s",
Этот модульный тест запускает функцию для двух значений
- 1 и 10 -
и подтверж
дает, что фактический ответ соответствует ожиданию. 3 Мы можем запускать тесты через
встроенную систему тестирования
1 8 функции
ordinal ()
Go.
реализовано три особых случая и один общий. nри запуске полного на
бора модульных тестов должна быть выполнена каждая из возможных веток кода.
глава
26. Непрерывная
интеграция и доставка
$ go test
PASS
ok github.com/bwhaley/ulsahgo
973
О.ООбs
Если какая-то часть приложения в будущем изменится
ordinal ()
будут добавлены обновления
-
-
например, если в функцию
тесты сообщат о любом расхождении с ожи
даемым выходным значением. За обновление модульных тестов отвечают разработчи
ки, поскольку именно они вносят изменения в код. Опытные разработчики сразу пишут
код, который легко тестировать. Они нацелены на полное покрытие тестами каждого
метода и функции.
Знакомство с конвейером
Jenkins Pipeline
Подготовив к поставке код и модульные тесты, сделайте первый шаг на пути освое
ния
настройте проект на сервере
Cl/CD -
Jenkins.
Через процесс вас проведет графи
ческий пользовательский интерфейс. Ниже приводятся варианты, которые мы выбрали.
•
Наш новый проект называется
Pipeline.
Он определен кодом, а не традиционным
проектом в свободном стиле с этапами сборки, которые в основном определяются
элементами пользовательского интерфейса.
•
Мы хотим отслеживать наш конвейер вместе с репозиторием исходного кода в фай
ле
Jenkinsfile, поэтому мы выбираем для определения Pipeline пункт Pipeline
script from SCM.
•
GitHub в поисках фиксации. Мы добавля
Jenkins мог получить доступ к репозиторию
GitHub в поисках изменений каждые пять минут.
Мы запускаем сборку путем опроса
ем учетные данные, чтобы сервер
U\sahGo
и настроиться на опрос
Начальная настройка занимает всего несколько секунд. В реальной жизни мы ис
пользовали бы веб-триггер
GitHub,
чтобы уведомить сервер
фиксация доступна, и избежать опроса, тем самым избавляя
ращений к его интерфейсу
о том, что новая
от ненужных об
API.
С помощью этой настройки сервер
Jenkinsfile
Jenkins
GitHub
Jenkins
в репозитории всякий раз, когда в
выполняет конвейер, описанный в файле
GitHub
появляется новая фиксация.
Теперь давайте рассмотрим структуру репозитория. В нашем проекте мы решили объ
CI/CD и код приложения в одном репозитории, при этом все файлы, связанные
Cl/CD, хранятся в подкаталоге pipeline. Репозиторий UlsahGo представлен следую
единить
с
щим образом.
$
tree ulsahgo
ulsa~.qo
pipeline
,Tenkinsfile
packer
~ prov1.· s~oпer. sh
ulsahgo. ё son
L
ulsaг.go.service
pr·oduction
f- tf proo. s:O
L ulsa!lgo.:::
testinq
[
tf_c:esting.s'°'
ulsahgo.t:
ulsahgo.go
ulsahgo_test.go
ЧастьlV.Эксплvатация
974
Интегрированная структура хорошо работает для небольшого проекта, подобного
этому.
Jenkins, Packer, Terraform
и другие инструменты могут искать свои файлы кон
фигурации в подкаталоге конвейера. Изменение конвейера развертывания выполняется
путем простого обновления репозитория. Для более сложных сред, в которых несколько
проектов имеют общую инфраструктуру, рекомендуем использовать вьщеленный репо
зиторий инфраструктуры.
После настройки инфраструктуры проекта можно выполнить фиксацию в репозито
рии нашего первого файла
Jenkinsfile.
Первым шагом в любом конвейере является
получение исходного кода. Вот полный сценарий конвейера
стемы управления конфигурацией программного обеспечения (это общий отраслевой
термин для систем контроля версий).
После опроса репозитория
GitHub
сервером
Jenkins
и завершения этапа получения
исходного кода мы можем перейти к настройке этапов тестирования и сборки. Наш
проект
Go
не имеет внешних зависимостей. Единственным требованием для создания
и тестирования нашего кода является двоичный исполняемый файл
вили систему
Jenkins
(с помощью команды
go. Мы уже устано
install golang-go), поэтому
сборки в файл Jenkinsfilse:
apt-get
нам нужно только добавить этапы тестирования и
-у
stage('Unit tests')
steps {
sh 'go test'
stage ( 'Build')
steps {
sh 'go build'
После того как мы зафиксируем изменения в хранилище, система
новую фиксацию и запустит конвейер. Затем система
Jenkins
Jenkins
обнаружит
генерирует читабельную
запись журнала, подтверждая, что она сделала это.
Mar 30, 2017 4:35:00 РМ hudson.triggers.SCMTrigger$Runner run
INFO: SCM changes detected in UlsahGo. Triggering #4
Mar 30, 2017 4:35:11 РМ org.jenkinsci.plugins.workflow.job.WorkflowRun
finish
INFO: UlsahGo #4 completed: SUCCESS
В графическом интерфейсе
Jenkins
используется метеорологическая метафора, ука
зывающая на работоспособность последних сборок. Значок солнца обозначает проект,
который собран успешно, а значок пасмурного облака обозначает сбои. Вы можете
Глава
26. Непрерывная интеграция
975
и доставка
устранять сбои сборки. проверяя консольный вывод, который находится в деталях сбор
ки. Он представляет собой содержание потока STDOUT, которое выводится на экран лю
бой частью сборки.
Ниже приведен фрагмент результатов вывода команд
go
teвt и
go build
в ходе ра
боты конвейера.
[Pipeline) stage
[Pipeline) { (Unit Tests)
[Pipeline] sh
[UlsahGo) Running shell script
+ go test
PASS
ok
_/var/jenkins home/workspace/UlsahGo
[Pipeline) }
[Pipeline) // stage
[Pipeline) stage
[Pipeline) { (Build)
[Pipeline) sh
[UlsahGo) Running shell script
+ go build
[Pipeline) )
[Pipeline) // stage
[Pipeline) }
[Pipeline) // node
[Pipeline) End of Pipeline
Finished: SUCCESS
О.ООбs
Обычно определить причину неудачной сборки можно, просмотрев журнал. Ищите
сообщения об ошибках, которые идентифицируют неудавшийся шаг. Вы также можете
добавить собственные сообщения в журнал, чтобы предоставлять подсказки о состоянии
системы, такие как значения переменных или содержимое сценария в данной точке вы
полнения. Использование отладочной печати
-
это старая традиция программистов.
Результатом нашей сборки является один двоичный файл ulвahgo, который содержит
все наше приложение. (Это, кстати, одно из основных преимуществ программ на языке
Go,
и одна из причин, почему язык
Go
популярен у системных администраторов: с его
помощью легко создавать статические двоичные файлы, которые выполняются в несколь
ких архитектурах и не имеют внешних зависимостей. Установка приложения на языке
Go
часто бывает простой и сводится к его копированию в нужный каталог системы.)
Создание образа
DigitalOcean
Теперь, когда файл
шины для облака
ulsahgo готов к поставке, мы создадим образ виртуальной ма
DigitaIOcean. Мы начинаем с простого образа Ubuntu 16.04, устанав
ливаем последние обновления, а затем устанавливаем программу ulвahgo. Полученный
образ становится артефактом развертывания для остальных этапов конвейера.
m
Если вы не знакомы с упаковщиком packer, который создает образ виртуальной
машины, перед продолжением обратитесь к разделу
Упаковщик
packer
24.6.
считывает конфигурацию своего образа из шаблона, который
имеет два основных раздела: \)сборщики, которые взаимодействуют с удаленными ин
терфейсами
"image": "ubuntu-16-04-x64",
"snapshot name": "ulsahgo-latest",
"ssh username": "root"
}]
Помимо других деталей, относящихся к конкретному провайдеру, сборщик сообщает
упаковщику
packer,
какая платформа используется для создания образа и как аутенти
==> digitalocean: Gracefully shutting down droplet ...
==> digitalocean: Creating snapshot: ul sahgo-latest
==> digitalocean: Waiting for snapshot to complete ...
==> digitalocean: Destroying droplet ...
==> digitalocean: Deleting temporary ssh key ...
Build 'digitalocean' finished.
==> Builds finished. The artifacts of successful builds are:
--> digitalocean: А snapshot was created: (ID: 23838540)
На втором шаге выполняется команда
grep, с помощью которой извлекается иден
packer. txt и сохраняется в новом фай
тификатор образа из последней строки файла
ле. находящемся в контексте сборки. Поскольку образ является артефактом развертыва
ния, на более поздних этапах конвейера мы должны ссылаться на него с помощью его
идентификатора.
Обеспечение единой системы тестирования
Итак, у нас есть процесс непрерывного выполнения модульных тестов, создания
приложения и образа виртуальной машины в качестве артефакта сборки . Остальные
этапы сборки сосредоточены на этапе развертывания артефакта и его тестирования в ре
UlsahGo мы решили использовать утили
Hasl1iCorp. Утилита terraform считывает
свою конфигурацию из так называемых "планов" JSОN-подобных файлов конфигурации,
в которых описывается желаемая конфигурация инфраструктуры. Затем она создает об
лачные ресурсы, описанные в плане, путем создания соответствующей серии вызовов
API.
terraform поддерживает десятки облачных провайдеров и широкий спектр служб.
Следующая конфигурация terraform, заданная в файле ulsahgo. tf, подготавлива
Утилита
ет отдельный дроплет
DigitalOcean,
дущем этапе конвейера.
запускающий образ, который мы создали на преды
ЧастьlV.Эксплуатация
978
variaЫe
variaЫe
variaЫe
"do_token" 11
"ssh_fingerprint" 11
"do_image" 11
provider "digitalocean" 1
token = "$1var.do_token)"
resource "digitalocean_droplet" "ulsahgo-latest" 1
image = "${var.do_imagel"
name = "ulsahgo-latest"
region = "sfo2"
size = "512mb"
ssh_keys = ["${var.ssh fingerprintl"J
Большинство этих директив самоочевидны: используйте службу DigitalOceaп в ка
честве провайдера, выполните аутентификацию с предоставленным токеном и создайте
s f о2 из указанного идентификатора образа.
Packer, представленном выше, мы непосредственно
дроплет в области
В шаблоне
ввели в конфигура
цию упаковщика такие параметры, как токен АР!. Одна (большая!) проблема с этим
подходом заключается в том, что ключ АР! сохраняется в репозитории исходного кода,
даже если он предположительно является секретным. Этот ключ дает доступ к интер
фейсу АР! провайдера облачных вычислений и, следовательно, будет опасен в непра
вильных руках. Сохранение секретов в системе контроле версий
-
это антишаблон без
опасности по причинам, которые мы более подробно описывали в разделе
7.8.
В этом примере мы вместо этого считываем параметры в виде переменных. Эти три
переменные перечислены ниже.
•
•
•
Токен Digita!Oceaп АР!.
Отпечаток ключа
SSH,
которому будет разрешен доступ к дроплету.
Идентификатор образа для новой системы, который мы записали на предыдущем
этапе конвейера.
Система Jeпkiпs может хранить такие секреты, как токен АР!, в своем "хранилище
у•1етных данных"
-
зашифрованной области, предназначенной именно для таких кон
фиденциальных данных. Конвейер может считывать значения из хранилища учетных
данных и сохранять их в виде переменных среды. Затем значения становятся доступны
ми по всему конвейеру без сохранения в системе контроля версий.
Вот как мы сделали это в файле Jenkinsfile.
pipeline 1
environment 1
DO TOKEN = credentials ( 'do-token')
SSH_FINGERPRINT = credentials('ssh-fingerprint')
Напомним, что мы сохранили идентификатор образа машины Digita!Oceaп в файле
do_ image. txt,
который находится в области сборки. Нам нужен этот идентификатор
на нашем новом этапе конвейера, который создает фактический дроллет Digita!Oceaп.
Код для нового этапа просто запускает сценарий из репозитория проекта.
Намного проще и удобнее хранить код сложных сценариев отдельно от остальной
части конвейера, как мы и сделали. Файл
tf_ testing. sh содержит следующие
строки.
do_image.txt pipeline/testing
cd pipeline/testing
terraform apply \
-var do_image="$( mtree
sЬin
if [ $1 = "-v" ]; then
cd $DIR
mtree -s $КЕУ -р /sЬin < mtree sЬin 1 \
mail -s '" hostname' mtree integri ty check" dan@admin.com
fi
С помощью флага -Ь этот сценарий создает и сохраняет базовое состояние. При по
вторном запуске с флагом
-v он сравнивает текущее содержимое каталога /sЬin с базо
вым состоянием.
Как и во многих аспектах системного администрирования, создание платформы
FIM
и управление ею с течением времени являются совершенно разными проблемами. Вам
понадобится определенный процесс, чтобы поддерживать данные
на предупреждения
FIM.
FIM
и реагировать
Мы предпагаем загружать информацию с платформы
FIM
в вашу инфраструктуру мониторинга и оповещения, чтобы она не отодвигалась в сторо
ну и не игнорировалась.
5 Лриемлемые
алгоритмы хеширования со временем меняются. Например, алгоритм
MD5
не считается криптоrрафически защищенным и в дальнейшем не должен использоваться.
больше
Глава
28.
1065
Мониторинг
Контроль обнаружения вторжений
Используются две распространенные формы систем обнаружения вторжений
(intrusion detection systems - IDS): на основе хоста (host-based IDS - НIDS) и на основе
сети (network-based IDS - NIDS). Системы NIDS исследуют трафик, проходящий через
сеть, и пытаются идентифицировать неожиданные или подозрительные шаблоны его
поведения. Наиболее распространенная система
робно освещена в разделе
Системы
HIDS
NIDS основана на системе Snort
и под
27.5.
работают как набор процессов, выполняемых в каждой системе. Как
правило, они ведут таблицы, в которых записана разная информация, в частности сетевые
соединения, моменты изменения файлов и контрольные суммы, журналы демонов и при
ложений, факты использования повышенных привилегий и другие моменты, которые
могут сигнализировать о работе средств, предназначенных для предоставления несанкци
онированного доступа к системе (так называемые руткиты). Системы
HIDS
не являются
универсальным решением для обеспечения безопасности, но это ценный компонент ком
плексного подхода.
Двумя наиболее популярными платформами
HIDS с открытым исходным кодом явля
OSSEC (Open Source SECURE) и AIDE (Advanced lntrusion Detection Environment).
По нашему опыту, OSSEC - лучший выбор. Хотя AIDE - хорошая платформа FIM в си
стеме Linux, платформа OSSEC имеет более широкий набор функций. Ее можно даже ис
ются
пользовать в режиме клиент-сервер, который поддерживают не-UNIХ-клиенты, такие как
Microsoft Windows и
различные устройства сетевой инфраструктуры.
Подобно предупреждениям
внимание.
HIDS -
FIM,
данные
HIDS
полезны, только если им уделяется
это не подсистема, работающая по принципу "установил и забьш".
Вы обязаны интегрировать предупреждения
HIDS
и вашу общую систему мониторинга.
Наиболее эффективная стратегия, которую мы нашли для решения этой проблемы,
автоматическое открытие билетов на оповещения
HIDS
-
в вашей системе вьщачи биле
тов. Затем вы можете добавить контрольную проверку, которая предупреждает о любых
необработанных билетах НIDS.
28.9. SNMP: ПРОСТОЙ
ПРОТОКОЛ СЕТЕВОГО УПРАВЛЕНИЯ
Много лет назад сетевая индустрия решила, что бьшо бы полезно создать стандарт
ный протокол сбора данных мониторинга. В результате возник протокол
Management Protocol,
Simple Network
также известный как
Несмотря на свое название, протокол
SNMP.
SNMP на
самом деле довольно сложный. Он
определяет иерархическое пространство имен данных управления и методы для чтения
и записи этих данных на каждом сетевом устройстве. Протокол
SNMP также определяет
способ управления серверами и устройствами ("агентами") для отправки уведомлений
о событиях ("ловушек") на станции управления.
Прежде чем мы углубимся в тайны протокола
с ним терминология
-
SNMP,
следует отметить, что связанная
одна из самых неудачных в мире сетей. Во многих случаях стан
дартные названия концепций и объектов в протоколе
SNMP
активно уводят вас от по
нимания того, что происходит.
Тем не менее сам протокол прост; большая часть сложности
SNMP
лежит выше
уровня протокола в соглашениях о построении пространства имен и ненужного вычур
ного словаря, который окружает
SNMP
как защитная оболочка. Если не слишком много
думать о его внутреннем устройстве, протокол
SNMP
прост в использовании.
ЧастьlV.Эксплуатация
1066
Протокол
SNMP
был разработан для реализации в специализированном сетевом
оборудовании, таком как маршрутизаторы, в контексте которых он остается вполне
приемлемым. Позднее
SNMP расширился,
включив мониторинг серверов и настольных
систем, но его пригодность для этой цели всегда вызывала сомнения. Сегодня доступны
гораздо более эффективные альтернативы (например,
Мы предлагаем использовать
collectd,
см. выше).
в качестве протокола сбора данных низкого
SNMP
уровня для использования с устройствами специального назначения, которые не под
держивают ничего лишнего. Получайте данные из мира
SNMP как можно
быстрее и пе
реходите к платформе мониторинга общего назначения для их хранения и обработки.
SNMP
может быть интересным объектом экскурсии, но вы не захотите там жить!
Организация протокола
Данные
SNMP
SNMP
организованы в виде стандартизованной иерархии. Иерархия име
нования состоит из так называемых "баз управляющей информации"
(Management
Bases - MIB) - структурированных текстовых файлов, которые описывают
данные, доступные через SNMP. Базы MIB содержат описания конкретных перемен
ных, на которые ссылаются имена, называемые объектными идентификаторами (010) 6•
Все текущие устройства, поддерживающие протокол SNMP, поддерживают структуру
для MIB-11, определенную в спецификации RFC1213. Однако каждый производитель
оборудования может расширить MIB, чтобы добавить больше данных и показателей,
Infoпnation
и часто пользуется этой возможностью.
Идентификаторы
010 существуют в
иерархическом пространстве имен, где узлы ну
меруются, а не называются. Однако для удобства ссылок узлы также имеют обычные
текстовые имена. Разделителем для компонентов пути является точка. Например,
который указывает на время безотказной работы устройства,
- l.3.6.l.2.l.l.3.
Этот
010,
010
также может быть представлен в виде имени, понятного для человека (хотя и не всегда
понятного без дополнительного описания):
iso.org.dod.internet.mgmt.mib-2.system.sysUpTime
В табл.
28.3
представлена выборка 010-узлов, которые могут быть интересны
для мониторинга доступности сети.
Таблица 28.З. Избранные идентификаторы
OID
из базы
MIB-11
010-
Тиn
Содержание
system.sysDescr
Строка
Системная информация: производитель, модель, тип опера
Целое число Количество полученных эхо-запросов
Целое число Количество полученных ошибок протокола ТСР
iso. org. dod. internet .mgmt .mib-2.
2
1067
28. Мониторинг
Глава
В дополнение к универсально поддерживаемой базе МIВ-11 существуют базы МIВ
для различных типов аппаратных интерфейсов и протоколов, отдельных производителей
оборудования, различных реализаций сервера
База
MIB -
полезной, база
snmpd и
конкретных аппаратных продуктов.
это всего лишь схема для управления данными об именах. Чтобы быть
MIB должна
сопровождаться агентским кодом, который выполняет ото
бражение между пространством имен
SNMP и фактическим состоянием устройства.
SNMP, работающий в системах UNIX, Liпux или Windows, имеет встроенную
поддержку баз MIB-11. Большинство из них моrут быть расширены для поддержки допол
нительных MIB и для взаимодействия со сценариями, которые выполняют фактическую
работу по извлечению и хранению связанных данных MIB. Вы увидите много программ
ного обеспечения, которое осталось от ушедшей эпохи, когда протокол SNMP бьm в моде.
Агент
Но все это дым без огня; в настоящее время вы не должны запускать SNМР-агент в си
стеме
UNIX,
за исключением, возможно, случая, когда он должен отвечать на основные
запросы о настройке сети.
Операции протокола
SNMP
Существуют только четыре основные операции
Операции
get
и
определенный идентификатором
MIB
SNMP: get, get-next, set
и
trap.
это основные операции для чтения и записи данных на узел,
set -
OID.
Операция
get-next
выполняет обход иерархии
и читает содержимое таблиц.
Операция
trap -
это незапрашиваемое асинхронное уведомление от сервера (агента)
клиенту (менеджеру), которое сообщает о возникновении интересного события или си
туации. Определены несколько стандартных уведомлений, в том числе уведомления "Я
только что включился", отчеты об отказе или восстановлении сетевого соединения, а так
же анонсы о различных проблемах маршрутизации и аутентификации. Механизм, с по
мощью которого определяются адресаты сообщений
Поскольку сообщения
SNMP
trap,
зависит от реализации агента.
моrут изменять информацию о конфигурации, необ
ходим какой-то механизм защиты. В простейшей версии защиты протокола
пользуется концепция "общей строки"
(community string),
SNMP
ис
которая на самом деле пред
ставляет собой просто ужасно запутанное название пароля. Обычно есть одна общая
строка доступа только для чтения и другая
-
для записи. 7 В наши дни имеет смысл уста
новить инфраструктуру управления SNMPvЗ, позволяющую повысить систему защиты
данных за счет авторизации и контроля доступа для отдельных пользователей.
Net-SNMP: средства
В системах
для серверов
FreeBSD наиболее распространенный пакет, реализующий прото
Net-SNMP. Он включает в себя агент (snmpd), некоторые утили
ты командной строки, сервер для приема уведомлений trap и даже библиотеку для раз
работки приложений, поддерживаюших протокол SNMP.
В наши дни пакет Net-SNMP в первую очередь представляет интерес из-за его команд
кол
SNMP,
Linux
и
называется
и библиотек, а не его агента. Он был перенесен на множество разных UNIХ-подобных
систем, поэтому действует как согласованная платформа, поверх которой можно писать
сценарии. Поэтому в большинстве дистрибутивов агент
Net-SNMP просто
вынесен в от
дельный пакет, что облегчает отдельную инсталляцию только команд и библиотек.
~А
\.._""' \1:'J
В системах
Deblan
и
Ubuntu
пакеты
Net-SNMP
называются
Команды инсталлируются так: apt-get install snmp.
snmp
и
snmpd.
ЧастьlV.Эксплуатация
1068
RHEL ~
~
В системах Red Hat и CentOS аналогичные пакеты называются net-snmp
и net-snmp-tools. Команды инсталлируются так:ушu install net-snmp-
tools.
В системе
•
Linux
информация о конфигурации хранится в каталоге
Выполните
/ etc/
snmpd. conf и каталог snmp. d в этом месте.
команду systemctl start snmpd, чтобы запустить демон агента .
В системе
FreeBSO
snmp;
обратите внимание на файл
все включено в один пакет:
snmp,
который вам придется создать вручную. Вы можете запустить агент
вручную вместе со службой
snmpd_enaЫe
в файле
snmpd или
установить значение
= "YES"
/etc/rc.conf,
чтобы запустить
ero
Во всех системах, где необходимо запустить агент
что порт
протокола
162
UOP
SNMP.
SNMP,
вам необходимо убедиться,
Net-SNMP,
могут ознакомить вас с протоко
Они также отлично подходят для однократных проверок определенных
идентификаторов
Таблица
во время загрузки системы.
не заблокирован брандмауэром.
Команды, которые входят в пакет
лом
pkg install net-snmp.
/usr/local/etc/
Информация о конфигурации хранится в каталоге в
28.4.
OID.
Наиболее часто используемые средства перечислены в табл.
Средства командной строки в пакете
28.4.
Net·SNMP
Команда
Назначение
snmpdelta
snmpdf
snmpqet
snmpqetnext
snmpset
Мониторинг изменений SNМР-переменных во времени
Устанавливает SNМР-переменную на агенте
snmptaЫe
Получает таблицу переменных
snmptranslate
smnptrap
snmpwalk
Ищет и описывает идентификаторы
Мониторинг дискового пространства на удаленном хаете через протокол
SNMP
Возвращает значение SNМР-переменной от агента
Получает следующую переменную в последовательности
SNMP
OID в иерархии MIB
t r ар
Генерирует предупреждение об уведомлении
Выполняет обход базы
MIB, начиная
с определенного идентификатора
OID
Для базовых проверок
SNMP обычно используется некоторая комбинация команд
snmpdelta. Другие программы полезны, когда вы хотите найти новые иден
тификаторы 010 для мониторинга с помощью вашего средства управления, принятого
в вашей организации. Например, команда snmpwalk запускается с указанного иденти
фикатором 010 места (или по умолчанию с начала базы MIB) и повторно выполняет
команды get-next, посылая вызовы агенту. Этапроцедура выдает полный список до
ступных идентификаторов 010 и связанных с ними значений.
Например, вот усеченный пример результатов применения команды snmpwalk к хо
сту tuva системы Linux. Общая строка - "secret81Зcommuni ty", а флаг -vl означает
snmpget
IF-MIB::ifDescr.l
STRING: lo
IF-MIB::ifDescr.2
STRING: ethO
IF-MIB::ifDescr.3
STRING: ethl
IF-MIB::ifType.l
INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifPhysAddress.l
STRING:
IF-MIB::ifPhysAddress.2 = STRING: 0:11:43:d9:le:f5
IF-MIB::ifPhysAddress.3 = STRING: 0:11:43:d9:le:f6
IF-MIB::iflnOctets.l
Counter32: 2605613514
IF-MIB::iflnOctets.2 = Counter32: 1543105654
IF-MIB::iflnOctets.3 = Counter32: 46312345
IF-MIB::iflnUcastPkts.l
Counter32: 389536156
IF-MIB::ifinUcastPkts.2
Counter32: 892959265
IF-MIB::iflnUcastPkts.3
Counter32: 7712325
В этом примере общая информация о системе сопровождается статистикой сетевых
интерфейсов хоста:
loO, ethO
и
ethl.
В зависимости от баз
MIB,
поддерживаемых аген
том, которым вы управляете, полный дамп может содержать до сотен строк. Фактически
полная инсталляция в системе
М 1В, выводит более
Если вы просмотрите базы
Ubuntu,
Ubuntu,
настроенной для обслуживания каждой базы
12 ООО строк!
MIB 8
для последней версии
Net-SNMP
в системе
то увидите, что средний за пять минут показатель загрузки системы равен
1.3.6.1.4.1.2021.10.1.3.2.
Если вам интересно увидеть пятиминутную загрузку системы
для локального хоста, для которого задана общая строка "puЬlic", вы должны выпол
нить команду:
$ snmpqet -v
2с -с puЬlic
localhost
iso.3.6.1.4.1.2021.10.1.3.2
Многие полезные модули
.1.З.б.1.4.1.2021.10.1.3.2
= STRING: "0.08"
SNMP,
связанные с языками
Perl, Ruby
и
Python, доступны
из соответствующих репозиториев модулей этих языков. Хотя вы можете в своих сцена
риях непосредственно указывать команды пакета
Net-SNMP,
проще и легче использо
вать встроенные модули, которые уже написаны для вашего языка программирования.
28.1 о.
Советы и РЕКОМЕНДАЦИИ по МОНИТОРИНГУ
На протяжении многих лет мы выработали несколько советов о том, как максимизи
ровать эффективность мониторинга. Ниже изложены основные идеи.
•
Избегайте выгорания системных администраторов, проводящих мониторинг.
Убедитесь, что системные администраторы, получающие уведомления во внеуроч
ное время, регулярно отдыхают. Эта цель лучше всего достигается с помощью си
стемы ротации, в которой в течение одного дня или недели звонки адресуются ко
манде из двух или более человек, а затем наступает очередь следующей команды.
Неспособность прислушаться к этим советам приводит к появлению ворчливых
системных администраторов, которые ненавидят свою работу.
•
Определите, какие обстоятельства действительно требуют внимания
ки
7
24 часа
в сут
дней в неделю, и убедитесь, что эта информация четко передается вашей
группе мониторинга, дежурным командам, а также клиентам или бизнес-подраз"Зайдите на сайт
mibdepot. сот
или установите пакет
snmp-mibs-downloader.
ЧастьlV.Эксплуатация
1070
делениям, работу которых вы поддерживаете. Сам факт, что вы контролируете
что-то, не означает, что администраторы должны собираться в
3:30 утра,
если не
которое значение выходит за рамки допустимого. Многие проблемы следует ре
шать в обычное рабочее время.
•
Устраняйте шум мониторинга. Если генерируются ложные срабатывания или уве
домления для некритических служб, установите время, чтобы остановить и испра
вить их. В противном случае, как в истории о мальчике, который постоянно кричал
о волках, все уведомления в конечном итоге не получат необходимоrо внимания.
•
Создавайте рабочие журналы регистрации для всего. Любая обычная процедура
перезапуска, сброса или исправления должна быть задокументирована в форме,
которая позволяет системному администратору, который не знаком с данной си
стемой, предпринять соответствующие действия. Если такой документации нет,
проблемы станут хроническими, повысится вероятность ошибок и для борьбы
с чрезвычайными ситуациями придется направлять дополнительный персонал.
Для поддержки такого типа документации отлично подходит система
•
Wiki.
Контролируйте платформу мониторинга. Это станет очевидным после того, как
вы пропустите критический сбой из-за выхода из строя платформы мониторинга.
Учитесь на наших ошибках и убедитесь, что за вами тоже кто-то наблюдает.
•
Пропустили сбой компонента из-за того, что он не контролировался? Добавьте его
в систему мониторинга и в следующий раз вы вовремя распознаете проблему.
•
Наконец, и, возможно, самое главное: ни сервер, ни служба не должны включать
ся в производственную цепочку без предварительного добавления в систему мони
торинга. Исключений здесь быть не может!
28.11. ЛИТЕРАТУРА
•
НЕснт, JлмЕs.
Rethinking Monitoring/or Container Operations.
Отличная информация
о стратегии и философии мониторинга контейнеров. С этой книгой можно озна
комиться по адресу
http://thenewstack.io/monitoring-reset-containers/
• TuRNBULL, JлмЕs. The Art о/ Monitoring. Seattle, WA: Amazoп Digital Services, 2016.
• DIXoN, JлsoN. Monitoring with Graphite: Tracking Dynamic Нost and App/ication Metrics at
Sca/e. Sebastopol, СА: O'Reilly Media, 2017.
глава 29
Анализ производительности
Анализ производительности и ее настройку часто относят к магической стороне си
стемного администрирования. Конечно же, магии здесь никакой нет, а следует говорить
о симбиозе науки и искусства. "Научная" часть включает тщательное проведение ко
личественных измерений и применение научного подхода. Составляющая "искусства"
связана с необходимостью сохранять баланс ресурсов на разумном уровне, поскольку
оптимизация для одного приложения или пользователя может отрицательно повлиять
на другие приложения или на других пользователей. Как это часто бывает в жизни, не
возможно сделать счастливыми всех сразу.
В блогосфере бытует мнение, что сегодня проблемы производительности кардиналь
но отличаются от аналогичных проблем предьщущих десятилетий. Но это не совсем так.
Да, системы стали гораздо сложнее, но определяющие факторы производительности
и высокоуровневые абстракции, используемые для ее измерения и управления, не ме
няются. К сожалению, повышение производительности систем сильно коррелирует со
способностью соответствующего сообщества создавать новые приложения, которые по
глощают все доступные ресурсы.
В последние годы дополнительную сложность создает многоуровневая абстракция,
которая часто располагается между серверами и физической инфраструктурой облака.
Часто невозможно точно знать, какое оборудование обеспечивает хранение или выпол
нение циклов центрального процессора на вашем сервере.
Магия и проблема облачных технологий
-
это два аспекта одного и того же вида.
Несмотря на распространенное мнение, вы не можете игнорировать вопросы произво-
1072
ЧастьlV.Эксплvатация
дительности только потому, что ваши серверы являются виртуальными. Фактически мо
дели биллинrа, используемые провайдерами облаков, создают еще более прямую связь
между производительностью и затратами на сервер. Знать, как измерять и оценивать
производительность, стало более важным, чем когда-либо.
В этой главе основное внимание уделяется производительности систем, которые ис
пользуются в качестве серверов. Настольные системы (и ноутбуки) обычно не испыты
вают тех же проблем с производительностью, что и серверы. Ответ на вопрос о том, как
повысить производительность на настольном компьютере, почти всегда сводится к со
вету обновить аппаратное обеспечение. Пользователям нравится этот ответ, потому что
благодаря ему они чаще получают новые интересные системы.
29.1.
ПРИНЦИПЫ НАСТРОЙКИ ПРОИЗВОДИТЕЛЬНОСТИ
Одним из аспектов, отличающих
UNIX и Linux от других популярных операционных
систем, является объем данных, которые они предоставляют о своих внутренних опера
циях. Детальная информация доступна буквально по каждому уровню системы, благода
ря чему администраторы моrут настраивать различные параметры именно так, как нуж
но. Если установить источник проблем с производительностью никак не удается, всегда
можно просмотреть исходный код. По этим причинам
UNIX
и
Linux
часто считаются
наиболее подходящими операционными системами для пользователей, которых особен
но беспокоит тема производительности.
Даже при этих условиях настройка производительности не является простой задачей.
Как пользователи, так и администраторы часто думают, что если бы они владели нуж
ными "магическими" приемами, их системы работали бы в два раза быстрее. Однако
так бывает очень редко.
Одним из наиболее распространенных заблуждений является убеждение в том, что
для настройки производительности нужно изменить значение переменных ядра, ко
торые отвечают за управление системой страничного обмена и буферными пулами.
В наши дни ядра основных дистрибутивов изначально настроены на достижение раз
умной (хотя и не оптимальной) производительности при различных уровнях загру
женности. Если попытаться оптимизировать систему по какому-то конкретному по
казателю производительности (например, по степени использования буферов), весьма
вероятно, что поведение системы ухудшится в отношении других показателей и режи
мов работы.
Наиболее сложные вопросы производительности часто связаны с приложениями,
а не операционными системами. В этой главе будет рассказываться о том, как можно
настроить производительность на уровне системы; возможность рассказать о настройке
производительности на уровне приложений мы оставили другим. Как системному адми
нистратору, вам необходимо помнить о том, что разработчики
-
тоже люди. (Сколько
раз вы говорили или думали, что проблема кроется в сети?) Так и разработчики прило
жений тоже часто предполагают, что все проблемы возникают в подсистемах, за которые
отвечает кто-то другой.
При таком уровне сложности современных приложений некоторые проблемы можно
решить только посредством сотрудничества их разработчиков, системных администра
торов, проектировщиков серверов, администраторов баз данных, администраторов си
стем хранения данных и архитекторов сети. В этой главе мы поможем вам определить,
какие данные следует предъявить этим специалистам, чтобы они смогли решить про
блемы производительности (если в действительности эти проблемы лежат в их области).
Глава
29.
Анализ производительности
1073
Такой подход гораздо эффективнее, чем просто сказать: "Все выглядит прекрасно, это
не моя проблема".
В любом случае никогда не доверяйте полностью тому, что пишут в Интернете.
Какие только аргументы не приводятся в дискуссиях о производительности систем! При
этом сторонники всевозможных теорий не обладают, как правило, ни знаниями, ни дис
циплиной, ни временем, необходимыми для проведения достоверных экспериментов.
Широкая поддержка пользователей еще ничего не значит, ибо каждое глупое предложе
ние очень часто сопровождается хором восторженных комментариев: "Я увеличил раз
мер кеш-буфера в десять раз, как он предложил, и система заработала гораздо, гораздо
быстрее!" Да уж, конечно!
Ниже перечислены ряд правил, которыми следует пользоваться.
•
Собирайте и анализируйте хронологические данные о работе системы. Если еще
неделю назад производительность системы была нормальной, а сейчас все изме
нилось, то сравнение характеристик системы в двух состояниях позволит выявить
источник проблемы. Всегда держите под рукой список оптимальных параметров
производительности. Кроме того, первым делом просматривайте журнальные
файлы, чтобы выяснить, не связана ли возникшая проблема с появлением какой
нибудь неполадки в оборудовании.
•
В главе
28
рассказывалось о некоторых средствах анализа тенденций, которые так
же подходят для мониторинга производительности.
•
Всегда настраивайте систему так, чтобы потом иметь возможность сравнить ре
зультаты с предыдущими показателями производительности системы.
•
Не перегружайте умышленно свои системы или свою сеть. Ядро создает для каж
дого процесса иллюзию бесконечности ресурсов. Но как только в дело вступают
все
100%
ресурсов системы, операционной системе приходится работать очень
напряженно. На поддержку иллюзии расходуется ощутимая доля самих ресурсов.
В результате выполнение процессов замедляется.
•
Как в физике элементарных частиц, чем больше данных вы собираете с помощью
утилит мониторинга системы, тем большее влияние вы оказываете на исследу
емую систему. Для наблюдения за системой лучше всего полагаться на простые
инструменты, которые работают в фоновом режиме (например,
sar
или
vmstat).
Если они обнаружат что-то существенное, то для более глубокого анализа можете
воспользоваться и другими инструментами.
•
Вносите изменения шаг за шагом и документируйте их. Прежде чем вносить оче
редное изменение, измерьте показатели, запишите их и обдумайте результаты.
•
Всегда продумывайте план отката на случай, если ваши изменения на самом деле
ухудшат работу системы.
29.2.
СПОСОБЫ ПОВЫШЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
Ниже перечислены конкретные действия, которые можно выполнить, чтобы улуч
шить производительность.
•
Убедитесь в том, что память доступна в достаточном объеме. В следующем раз
деле вы увидите, что объем памяти очень сильно влияет на производительность.
Устройства памяти сегодня стоят довольно недорого, так что обычно оснастить
по максимуму любой компьютер, от которого требуется высокая производитель-
1074
ЧастьlV.Эксплуатация
ность,
-
не проблема. Если ваш сервер работает в облаке, то изменить объем па
мяти, выделенный его экземпляру, обычно очень легко (хотя часто он связан с
другими выделяемыми ресурсами в полном профиле системы).
•
Там, где это возможно, ликвидируйте зависимость систем хранения данных от ме
ханических устройств. В настоящее время широко доступны твердотельные диски
(so\id state disk drive - SSD),
которые могут обеспечить быстрый рост производи
тельности, поскольку для них не требуется физическое вращение дискоа для счи
тывания битов информации. SSD-диски легко устанавливаются вместо "старых
добрых" дисковых накопителей.
•
Если
UNIX-
или Linux-cиcтeмa используется в качестве веб-сервера или сетевого
сервера приложений, можно попробовать распределить трафик между нескольки
ми компьютерами с помощью какого-нибудь (физического или виртуального) ба
лансировщика нагрузки. Эти устройства распределяют нагрузку согласно одному
из нескольких выбираемых пользователем алгоритмов типа "минимальное время
отклика" или "циклический алгоритм обслуживания".
Кроме того, балансировщики нагрузки добавляют полезную избыточность на слу
чай перегрузки сервера. Они просто необходимы, если ваш сервер вынужден об
рабатывать неожиданные всплески трафика.
•
Тщательно проверяйте конфигурацию системы и отдельных приложений. Многие
приложения могут резко увеличить производительность, если их правильно на
строить (распределить данные между дисками, не осуществлять динамический по
иск имен в
•
DNS,
запустить дополнительные экземпляры сервера и т.д.).
Устраните проблемы, связанные с использованием ресурсов. Проблемы могут соз
даваться как "реальными заданиями" (одновременный запуск слишком большого
количества серверов, неэффективные методы программирования, выполнение па
кетов заданий с завышенным приоритетом, запуск ресурсоемких программ в не
подходящее время), так и самой системой (ненужные демоны).
•
Организуйте жесткие диски и файловые системы так, чтобы нагрузка на них была
равномерной, и тем самым максимально повысьте пропускную способность ка
налов ввода-вывода. При наличии специфических приложений, таких как базы
данных, можно попробовать использовать какую-нибудь модную многодисковую
технологию вроде
RAID
для оптимизации процессов обмена данными. За реко
мендациями следует обращаться к разработчику базы данных. Для систем
Linux
нужно удостовериться в том, что для диска выбран самый подходящий из доступ
ных в Linнx планировщик ввода-вывода (детали см. в разделе
29.6).
Обратите внимание на то, что разные приложения и системы управления базами
данных ведут себя по-разному при размещении на нескольких дисках. Технология
RAID
существует в нескольких вариантах, поэтому следует потратить время и вы
яснить, какой из них лучше всего подходит для данного конкретного случая (если
вообще подходит).
•
Проведите мониторинг сети и убедитесь в том, что она не перегружена трафиком
и что количество ошибок в ней минимально. Очень много такой полезной инфор
мации о сети можно собрать с помощью команды
•
net8tat (FreeBSD)
и
88 (Linux).
Определите ситуации, в которых система совершенно не соответствует предъяв
ляемым к ней требованиям. Нельзя настроить производительность без учета таких
ситуаций.
Глава
29. Анализ
производительности
1075
Эти меры перечислены в порядке убывания эффективности. Добавление памяти
и распределение трафика между несколькими серверами может значительно повысить
производительность. Степень эффективности остальных мер варьируется от значитель
ной до нулевой.
Анализ и оптимизация структур данных и алгоритмов программ почти всегда ведет
к существенному повышению производительности. Однако эти вопросы обычно нахо
дятся вне компетенции системного администратора.
29.3. ФАКТОРЫ,
ВЛИЯЮЩИЕ НА ПРОИЗВОДИТЕЛЬНОСТЬ
Производительность системы во многом определяется базовыми характеристиками
системных ресурсов и эффективностью их распределения и совместного использования.
Определение термина ресурс весьма расплывчато. Оно может подразумевать даже такие
компоненты, как кеш содержимого регистров центрального процессора и элементы таб
лицы адресов контроллера памяти. Однако в первом приближении серьезное влияние
на производительность оказывают только четыре фактора:
•
время использования центрального процессора и его захваченные циклы (см.
ниже);
•
•
•
память;
пропускная способность дисковой подсистемы ввода-вывода;
пропускная способность сетевой подсистемы ввода-вывода.
Если после запуска активных процессов остались свободные ресурсы, можно счи
тать, что производительность системы является удовлетворительной.
Когда ресурсов не хватает, процессы становятся в очередь. Процесс, не имеющий не
медленного доступа к необходимым ресурсам, должен ждать, ничего при этом не делая.
Время, затрачиваемое на ожидание ресурсов,
-
один из основных показателей ухудше
ния производительности.
Самый простой с точки зрения учета ресурс
-
использование центрального процес
сора. В распоряжении системы всегда имеется примерно одна и та же часть его мощно
сти. Теоретически эта величина составляет все
100%
циклов центрального процессора,
но "накладные расходы" и другие причины приводят к снижению этого показателя при
мерно до
95%.
Для процесса, занимающего более
90%
времени центрального процессо
ра, ограничивающим фактором является его быстродействие. Такой процесс потребляет
большую часть вычислительных мощностей системы.
Многие считают, что быстродействие центрального процессора
-
основной фактор,
влияющий на общую производительность системы. При наличии неограниченных объ
емов всех остальных ресурсов или для определенных типов приложений (например, про
грамм численного моделирования) быстродействие центрального процессора (или коли
чество ядер) действительно играет роль. Но в повседневной жизни этот показатель значит
относительно мало.
Настоящим узким местом является канал обмена данными с жестким диском.
Жесткие диски представляют собой механические системы, поэтому на поиск нужного
блока, выборку его содержимого и активизацию ожидающего его процесса уходят де
сятки миллисекунд. Задержки такого порядка отодвигают на второй план все остальные
факторы ухудшения производительности. Каждое обращение к диску вызывает приоста
новку активного процесса "стоимостью" несколько миллионов инструкций централь-
частьlV.Эксплvатация
1076
ного процессора. Эту проблему можно решить, например, с помощью твердотельных
дисковых накопителей.
Благодаря использованию виртуальной памяти скорость дискового обмена может
быть непосредственно связана с объемом имеющейся памяти, если потребность в физи
ческой памяти превышает ее реальный объем. Ситуации, в которых физической памяти
становится недостаточно, часто приводят к необходимости записывать содержимое ее
страниц на диск, чтобы эти страницы можно было освободить и использовать для дру
гой цели. Это означает, что обращение к памяти по своей скорости приближается к ра
боте с диском. Избегайте таких ловушек, если характеристики производительности
имеют для вас большое значение; побеспокойтесь о том, чтобы каждая система имела
достаточно физической памяти.
Пропускная способность сети подвержена примерно тем же ограничениям, что
и скорость дискового обмена. Ее ухудшение связано со всевозможными задержками. Но
возникающие проблемы охватывают целые сообщества пользователей, а не отдельные
компьютеры. Кроме того, сети восприимчивы к проблемам аппаратного обеспечения
и перегрузкам серверов.
29.4. ЗАХВАЧЕННЫЕ
ЦИКЛЫ ЦЕНТРАЛЬНОГО ПРОЦЕССОРА
Облачные технологии (и, как правило, виртуализация) обещают, что ваш сервер
всегда будет иметь необходимые ему ресурсы. На самом деле большая часть этой щедро
сти
-
иллюзия. Даже в крупномасштабной виртуальной среде борьба за ресурсы может
оказать заметное влияние на производительность виртуального сервера.
Центральный процессор
-
это наиболее часто используемый ресурс. Существует два
способа, с помощью которых можно захватить циклы процессора на вашей виртуальной
машине.
•
Гипервизор, на котором работает ваша виртуальная машина, определяет кво
ту центрального процессора, основываясь на том, какую мощность вы заказали.
Дефицит может быть устранен либо путем выделения большего количества ресур
сов на уровне гипервизора, либо путем заказа более крупного экземпляра у по
ставщика облачных вычислений.
•
Происходит превышение лимита, выделенного для физического оборудования,
и для удовлетворения текущих потребностей всех экземпляров виртуальной ма
шины физических циклов процессора оказывается недостаточно, хотя на все эти
экземпляры могут распространяться квоты центрального процессора. В облачном
провайдере исправление этой проблемы можно свести к перезапуску вашего эк
земпляра, чтобы он был переназначен на новое физическое оборудование. В ва
шем центре обработки данных решение может потребовать обновления среды
виртуализации с большим количеством ресурсов.
Хотя захват процессора может произойти в любой операционной системе, работаю
щей на виртуализованной платформе, система
мощью показателя
st (stolen -
Linux
захвачен) в командах
Вот пример использования команды
позволяет выявить этот факт с по
top, vmstat
и
mpstat.
top:
top - 18:36:42 up 3 days, 18:03, 1 user, load average: 3.40, 2.25, 2.08
Tasks: 218 total, 4 running, 217 sleeping, О stopped, О zomЬie
%Cpu: 41.6 us, 42.2 sy, О.О ni, О.О id, О.О wa, О.О hi, О.О si, 16.2 st
Глава
29. Анализ производительности
В этом примере в
16,2%
1077
случаев система готова, но не может работать, потому что
процессор отвлекается от виртуальной машины гипервизором. Время, потраченное
на ожидание, непосредственно переводится в снижение пропускной способности.
Внимательно следите за этим показателем на виртуальных серверах, чтобы гарантиро
вать, что ваши рабочие нагрузки не будут непреднамеренно испытывать дефицит про
цессора.
29.5.
КАК АНАЛИЗИРОВАТЬ ПРОБЛЕМЫ ПРОИЗВОДИТЕЛЬНОСТИ
В сложной системе нелегко выделить именно проблемы производительности.
Системные администраторы часто получают невразумительные отчеты о проблемах, ко
торые содержат эмоциональные описания конкретных случаев или сложных ситуаций
(например, "веб-сервер застопорился из-за всех этих проклятых АJАХ-вызовов"."). Вы,
конечно, должны обратить внимание на эту информацию, но не воспринимайте ее как
достоверную и надежную; проводите собственное исследование.
Строгая и прозрачная научная методика поможет вам сделать правильные выводы,
которым ваши сотрудники и вы сами можете доверять. Научный подход позволит дру
гим оценить ваши результаты, повысит доверие к вашей работе и увеличит вероятность
того, что предлагаемые вами изменения смогут реально решить проблему.
Применение научного подхода не означает, что вы должны собирать все релевантные
данные сами. Весьма полезной бывает и "внешняя" информация. Не стоит тратить часы
на изучение вопросов, ответы на которые можно легко почерпнуть из разделов
(Fгequently
Asked Questions -
FAQ
часто задаваемые вопросы).
Мы предлагаем вам выполнить следующие пять действий.
1.
Сформулируйте вопрос. Поставьте конкретный вопрос в определенной функцио
нальной области либо сформулируйте предварительное заключение или рекомен
дацию, которую вы обдумали. Будьте точны, говоря о технологиях, компонентах
и альтернативах, которые вы предлагаете рассмотреть, и результатах, которые мо
гут быть достигнуты.
2.
Соберите и классифицируйте факты. Проведите систематический поиск в доку
ментации, базах знаний, известных вам изданиях, блогах, технических описани
ях, на форумах и прочих информационных ресурсах с целью выявления внешних
фактов, имеющих отношение к вашему вопросу. В собственных системах зафик
сируйте телеметрические данные и (по возможности или необходимости) осна
стите инструментальными средствами конкретные интересующие вас области
в системе или отдельных приложениях.
3.
Критически оцените данные. Просмотрите каждый источник данных на предмет
релевантности и критически оцените его с точки зрения достоверности. Выделите
ключевые данные и обратите внимание на качество источников информации.
4.
Подытожьте данные вербально и графически. Представьте сведения, взятые из не
скольких источников, в словесной (вербальной) и по возможности графической
форме. Данные, кажущиеся сомнительными при выражении в числовой форме,
могут оказаться убедительными в виде диаграммы.
5.
Сформулируйте заключение. Представьте свои выводы в лаконичной форме (как от
вет на поставленный вами же вопрос). Поставьте оценку, чтобы обозначить уровень
силы или слабости доказательств, которые поддерживают ваши заключения.
ЧастьlV.Эксплvатация
1078
29.6.
ПРОВЕРКА ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ
Хватит общих советов
-
пора рассмотреть некоторые конкретные инструменты
и "зоны интереса". Прежде чем переходить к измерениям, необходимо знать, что имен
но вы хотите получить.
Инвентаризуйте свое оборудование
Начните с оценки своего оборудования, особенно центрального процессора и ресур
сов памяти. Инвентаризация поможет вам интерпретировать данные, представленные
с помощью других инструментов, а также построить реалистичные ожидания касательно
верхних границ производительности.
В системах
Linux
именно в файловой системе
стоит искать ответ
/proc
на вопрос, какое с точки зрения вашей операционной системы вы использу
ете оборудование (более детальную информацию об аппаратуре можно най
ти в каталоге
/sys; см. раздел 11.3). Некоторые ключевые файлы перечис
29.1. Общую информацию о файловой системе /proc можно
разделе 4.6.
лены в табл.
найти в
Таблица
29.1.
Источники информации об оборудовании в системах
Файл
Содержимое
/proc/cpuinfo
Тип и описание центрального процессора
/proc/meminfo
Размер памяти и коэффициент загрузки
Linux
/proc/diskstats Дисковые устройства и статистика их использования
Четыре строки в файле
ный процессор в системе:
/proc/cpuinfo помогут вам идентифицировать централь
vendor id, cpu family, model и model name. Некоторые из
этих значений непонятны, поэтому лучше всего узнать о них в интерактивной справоч
ной системе.
Точная информация, содержащаяся в файле
/proc/cpuinfo,
зависит от системы
и процессора. Рассмотрим типичный пример содержимого этого файла.
$ cat /proc/cpuinfo
proeessor
О
vendor id
Genиinelntel
ери family
6
model
15
model name
Intel(R) Xeon(R) CPUE5310
stepping
11
ери MHz
1600.003
eaehe size
4096 кв
physieal id
о
ери eores
2
siЬlings
@ l.60GHz
2
Этот файл содержит по одной записи для каждого процессорного ядра, видимого опе
рационной системой. Конкретные данные незначительно варьируются в зависимости
от версии ядра. Значение поля
поля
physical id
processor
уникально идентифицирует ядро. Значения
являются уникальными для каждого физического сокета на печат-
Глава
29.
Анализ производительности
ной плате, а значения
core id
1079
(не показано в приведенном выше примере) уникальны
мя ядра в физическом сокете. Ядра, которые поддерживают гиперпотоковый режим ра
боты (дублирование контекстов ЦП без дублирования других характеристик обработки),
идентифицируются значением
ht
в поле
flags
(также не показано в приведенном выше
примере). Если в системе действительно реализован гиперпотоковый режим работы, поле
siЫings мя каждого ядра показывает, сколько контекстов доступно на данном ядре.
Существует еще одна команда, которая позволяет получить информацию об аппарат
ных характеристиках вашего компьютера. Речь идет о команде
dmidecode.
Она выводит
DMI (Desktop Management Interface - интерфейс управ
ления настольными системами), также известной под именем SMBIOS. Самой полезной
опцией этой команды является -t тип (допустимые типы представлены в табл. 29.2).
содержимое системной таблицы
Таблица
29.2. Значения типов для команды dmidecode -t
Значение
Описание
1
Система
2
Материнская плата
3
Корпус
4
Процессор
7
Кеш-память
8
Разъемы портов
9
Системные разъемы
11
ОЕМ-строки
12
Опции системной конфигурации
13
Язык
16
Массив физической памяти
17
Устройство памяти
BIOS
19
Отображаемый адрес массива памяти
32
Загрузка системы
38
IРМl-устройство
В следующем примере демонстрируется получение типичной информации.
$ sudo dmidecode -t 4
# drnidecode 2.11
SMBIOS 2.2 present.
Handle Ох0004, DMI type 4, 32 bytes.
Processor Information
Socket Designation: PGA 370
Туре: Central Processor
Family: Celeron
Manufacturer: Genuineintel
ID: 65 06 00 00 FF F9 83 01
Signature: Туре О, Family 6, Model 6, Stepping 5
Биты информации о сетевой конфигурации разбросаны "по всей системе". Лучшим
IP- и МАС-адресам мя каждого сконфигурированного
ifconfig -а (FreeBSD) и ip а (Linux).
источником информации о
терфейса служат команды
ин
ЧастьlV.Эксплуатация
1080
Сбор данных о производительности
Программы анализа производительности в большинстве своем сообщают о том, что
происходит в системе в данный момент времени. Но следует учесть, что структура и ха
рактер загрузки системы меняются в течение дня. Поэтому до принятия мер обязатель
но проведите всесторонний анализ данных, касающихся производительности. Истинная
производительность выясняется только после длительного (месяц или даже больше)
наблюдения за системой. Особенно важно собирать данные в периоды пиковой загру
женности системы. Ограничения на использование ресурсов и ошибки в конфигура
ции системы часто выявляются только в таких условиях. Дополнительную информацию
о сборе и анализе данных см. в главе
28.
Анализ использования центрального процессора
Обычно собирают три вида данных о центральном процессоре: общий показатель
использования, показатели средней загруженности и потребление ресурсов отдельны
ми процессами. Первая характеристика определяет, является ли быстродействие самого
процессора узким местом. Показатели средней загруженности дают возможность оце
нить общую производительность системы. Данные, касающиеся отдельных процессов,
позволяют выявить наиболее ресурсоемкие процессы.
Сводную информацию выдает команда
Ей передается два аргумента: вре
vmstat.
мя (в секундах), в течение которого необходимо наблюдать за системой для получения
каждой строки выходной информации, и необходимое количество отчетов. Если не ука
зать число отчетов, команда будет выполняться до тех пор, пока пользователь не нажмет
комбинацию клавиш
----cpu---us sy id wa
25 1 73 о
25 1 74 о
90 1 9 о
87 3 10 о
20 3 77 о
Несмотря на то что содержимое этих столбцов может не совпадать в разных систе
мах, статистические данные показателей использования центрального процессора прак
тически не различаются среди платформ. Пользовательское время, системное время
(время ядра), время простоя и время ожидания для каналов ввода-вывода
ны в столбцах
us, sy, id
и
wa
соответственно. Большие числа в столбце
начают активные вычисления, а в столбце
sy
(1/0) показа
us обычно оз
они свидетельствуют о том, что процессы
осуществляют очень много системных вызовов или выполняют операции ввода-вывода.
Выработанное нами за многие rоды эмпирическое правило для серверов общего на
значения, справедливое для большинства систем, гласит следующее: система должна
тратить примерно
50%
рабочего времени на обслуживание пользовательских запросов
и столько же на системные запросы. Общее время простоя не должно быть нулевым.
Если сервер выделяется под одно-единственное приложение, интенсивно использую
щее центральный процессор, то большая часть времени должна тратиться на обработку
пользовательских запросов.
В столбце
cs
показано число переключений контекста за данный период, т.е. сколь
ко раз ядро переключало процессы. В столбце
in
отображается число прерываний, ге-
Глава
29. Анализ производительности
1081
нерируемых аппаратными устройствами или компонентами ядра. Слишком большие
значения в этих столбцах свидетельствуют о неправильно работающем аппаратном
устройстве. Остальные столбцы важны для анализа использования памяти и жесткого
диска, о чем будет рассказываться ниже в этой главе.
Долговременные измерения средних показателей, характеризующих работу цент
рального процессора, позволяют определить, достаточно ли его ресурсов для нормаль
ной работы системы. Если процессор регулярно часть времени простаивает, значит, есть
запас по тактовой частоте. В этом случае увеличение быстродействия процессора нена
много улучшит общую производительность системы, хотя может и ускорить выполнение
отдельных операций.
Как видно из показанного примера, центральный процессор постоянно переключа
ется из режима интенсивного использования в режим полного бездействия и обратно.
Поэтому необходимо наблюдать за показателями, соответствующими обоим режимам,
и выводить среднее за определенный период времени. Чем меньше интервал наблюде
ния, тем ниже достоверность оценок.
В мультипроцессорных системах команды вроде
ния по всем процессорам. В системе
vm.stat сообщают
Linux существует команда mpstat,
средние значе
которая выдает
отчет по каждому процессору. С помощью флага -Р можно выбрать один конкретный
процессор. Этой командой удобно пользоваться при отладке программ, поддерживаю
щих симметричную многопроцессорную обработку. Интересно также узнать, насколь
ко система эффективно (или неэффективно) работает с несколькими процессорами.
Рассмотрим пример отображения состояния каждого из четырех процессоров.
linux$ шpstat -Р ALL
08:13:38 РМ CPU %user %nice %sys %iowait %irq %soft %idle intr/s
08:13:38 РМ
о
1.02 0.00 0.49
1.29 0.04 0.38 96.79 473.93
08:13:38 РМ
1 0.28 0.00 0.22
о. 71 0.00
0.01 98.76 232.86
1.32 0.00 0.05 97.84 293.85
08:13:38 РМ
2 0.42 0.00 0.36
0.94 0.01 0.05 98.32 295.02
08:13:38 РМ
3 0.38 0.00 0.30
Центральный процессор однопользовательской рабочей станции обычно проста
ивает большую часть времени. Когда запрашивается прокрутка содержимого окна или
обновляется веб-страница, центральный процессор справляется с этой операцией за
считанные доли секунды. В такой ситуации долгосрочный средний показатель исполь
зования центрального процессора практически лишен смысла.
Еще одним статистическим показателем, полезным для оценки интенсивности ис
пользования системы, является показатель "средняя загруженность", который представ
ляет собой среднее количество выполняемых процессов. Он дает достаточное представ
ление о том, сколько процессов требуют свою долю процессорного времени. Узнать его
значение можно с помощью команды
Эта команда выдает три значения, которые соответствуют средней загруженности за
пять, десять и пятнадцать минут. Как правило, чем выше средняя загруженность, тем
важнее общая производительность системы. Если выполняется всего лишь один про
цесс, то он обычно ограничен одним ресурсом (центральным процессором или про
пускной способностью дискового канала ввода-вывода). Пиковый спрос на этот ресурс
и становится определяющим фактором производительности.
Когда в системе одновременно работает несколько процессов, нагрузка распределя
ется более равномерно. Если все работающие процессы потребляют ресурсы централь-
ЧастьlV.Эксплvатация
1082
ного процессора, диска и памяти, то зависимость производительности системы от огра
ниченных возможностей какого-то одного ресурса снижается. В такой ситуации гораздо
важнее следить за средними показателями загруженности, в частности за общим време
нем использования центрального процессора.
m
Дополнительную информацию о приоритетах см. в разделе
4.2.
Показатель средней загруженности отлично подходит Д/IЯ повседневного контроля сис
темы. Если известен показатель работающей системы и он находится в диапазоне, характер
ном для перегрузки, значит, следует искать внешний источник проблемы (это может быть,
к примеру, сеть). В противном случае нужно проверить процессы самой системы.
Еще один способ контроля над использованием центрального процессора
-
треть, какую часть его времени отнимает каждый процесс с помощью команды
Зачастую в интенсивно эксплуатируемой системе минимум
70%
посмо
ps -aux.
времени работы цент
рального процессора отнимается одним-двумя процессами. Запуск таких процессов в дру
гое время суток или снижение их приоритетов позволит высвободить ресурсы ЦП ДIIЯ вы
полнения других процессов.
W
Подробнее об утилите
top рассказывалось в
Прекрасной альтернативой команде
ту же информацию, что и
ps,
разделе
4.4.
является утилита
ps
top.
Она вьщает примерно
но в "живом", постоянно обновляемом формате, позволя
ющем наблюдать за изменением состояния системы во времени. 1
Управление памятью в системе
В
UNIX-
и Linux-cиcтeмax память организована в виде блоков, называемых стра
ницами, размер которых составляет
4
КиБ или больше. Когда процессы запрашивают
у операционной системы память, ядро выделяет им виртуальные страницы. Каждой та
кой странице соответствует настоящее физическое хранилище, такое как оперативное
запоминающее устройство или "резервное запоминающее устройство" на жестком дис
ке. (Резервное запоминающее устройство обычно представляет собой просто простран
ство в области подкачки, но для страниц, которые содержат код исполняемой програм
мы, резервное запоминающее устройство
-
это самый настоящий исполняемый файл.
Аналогично резервное запоминающее устройство Д/IЯ некоторых файлов данных может
представлять собой сами файлы.) Информация о связях между виртуальными и реаль
ными страницами хранится в таблице страниц.
Ядро способно эффективно обслуживать запросы процессов, выделяя ДIIЯ них столь
ко памяти, сколько им нужно. Это реализуется за счет дополнения области подкачки
к реальной оперативной памяти. Поскольку Д/IЯ работы процессов требуется, чтобы их
виртуальные страницы находились в реальной памяти, ядру постоянно приходится пе
ремещать страницы между оперативной памятью и областью подкачки. Такие операции
называются страничным обменом
(paging). 2
Ядро старается управлять памятью так, чтобы страницы, к которым недавно об
ращались, хранились в физической памяти, а менее активные страницы выгружались
на диск. Этот алгоритм известен под названием
'Утилита
top
LRU (least recently used -
замещение
требует довольно много системных ресурсов, поэтому пользуйтесь ею вразумных
пределах.
2 Когда-то
имела место иная операuия, именуемая подкачкой (или свопингом), посредством которой
все страницы некоторого процесса одновременно переписывались на диск. Теперь же во всех слу
чаях обязательно используется страничный обмен
(paging).
Глава
29.
1083
Анализ производительности
наименее используемых элементов), поскольку те страницы, к которым долго никто не
обращался, перемещаются на диск.
Впрочем, отслеживать все обращения к страницам было бы слишком накладно
для ядра, поэтому оно использует страничный кеш-буфер, анализ содержимого которого
и позволяет принять решение о том, какие именно страницы оставить в памяти. Точный
алгоритм этого механизма зависит от конкретной системы, но везде действует примерно
одинаковый принцип. Такой вариант гораздо проще в реализации, чем LRU-система,
а результаты дает почти такие же.
В случае нехватки памяти ядро пытается определить, какие страницы из "неактив
ного" списка давно не использовались. Если при последнем обращении такие страницы
модифицировались процессом, ядро считает их "грязными"; они обязательно должны
быть выгружены на диск, прежде чем занимаемая ими память будет повторно исполь
зована. Все остальные страницы реальной памяти считаются "чистыми" и могут быть
назначены другому процессу.
Когда выполняется обращение к странице из "неактивного" списка, ядро возвраща
ет ссылку на нее в таблицу страниц, обнуляет ее "возраст" и переводит страницу из "не
активного" списка в "активный". Если при этом изменяются адреса страниц реальной
памяти, то страницы, выгруженные на диск, должны быть сначала прочитаны с диска,
прежде чем их можно будет активизировать. Когда процесс обращается к неактивной
странице, находящейся в памяти, происходит программный сбой (это так называемая
"мягкая ошибка", или
"soft fault").
В случае обращения к нерезидентной (выгруженной)
странице имеет место аппаратный сбой (так называемая "жесткая ошибка",
"hard fault").
Друrими словами, при возникновении ошибки второго типа (в отличие от первого) тре
буется прочитать страницу с диска.
Ядро старается прогнозировать потребности приложений в памяти, поэтому опе
рации выделения и выгрузки страниц не обязательно взаимосвязаны. Цель системы
-
обеспечить наличие достаточного объема свободной памяти, чтобы процессам не при
ходилось ждать выгрузки страниц всякий раз, когда им нужна свободная память. Если
в периоды сильной загруженности системы страничный обмен резко возрастает, имеет
смысл купить дополнительную память.
Можно изменить значение "коэффициента подкачки"
swappiness)
(/proc/sys/vm/
и тем самым дать ядру подсказку о том, при каком проценте
свободной памяти следует начинать активную выгрузку страниц. Если уста
новить это значение равным нулю, то выгрузка страниц на диск начнется
только когда закончится свободная память. При значении этого параметра
100,
все страницы будут автоматически вытесняться на диск. По умолча
нию для этого параметра устанавливается значение
60,
т.е. выгрузка стра
ниц начнется, когда процент использования основной памяти достигнет
(100-60=40).
40
Если у вас возникает желание изменить этот параметр, значит,
возможно, пришла пора увеличить объем оперативной памяти.
Если ядру не хватает как физической памяти, так и области подкачки, это означа
ет, что виртуальная память исчерпана. В данной ситуации включается режим "прину
дительного уничтожения". Чтобы освободить память, системе приходится уничтожать
целые процессы. И хотя выбираются наименее важные для системы процессы, все равно
это очень неприятная процедура, ведь значительная часть ресурсов системы тратится не
на полезную работу, а на управление памятью.
ЧастьlV.Эксплvатация
1084
Анализ использования памяти
Интенсивность операций с памятью количественно представляется двумя показателями:
общим объемом задействованной виртуальной памяти и текущим коэффициентом стра
ничного обмена. Первый показатель характеризует общую потребность в памяти, а второй
указывает на то, какая доля этой памяти активно используется. Задача администратора за
ключается в снижении интенсивности использования или увеличении объема памяти до тех
пор, пока не будет достигнут приемлемый уровень страничного обмена. Страничный об
мен - процесс неизбежный, поэтому не пытайтесь полностью избавиться от него.
Для того чтобы определить размер текущей области подкачки в системе
полните команду
freebsd$ vmstat 5 5
page
procs memory
re
flt
fre
r Ь w avm
97
о
1.BG
о о о 412М
1
о
2 о о 412М 1.BG
о
о
2 о о 412М 1.BG
о
о
1 о о 412М 1.BG
о
1.BG
о
о о о 412М
выглядит так.
о
о
fr
200
о 7
о
о
о
7
о
о
о
о
о
о
6
7
pi
1
ро
о
faults
disk
in
sr daO cdO
51
о
о
6
5
о
о
о
4
о
о
о
4
о
о
о
6
о
о
о
sy
359
27
25
25
26
Из этого примера удалена информация об использовании центрального процессора.
Под заголовком
procs
показано количество процессов, готовых к немедленному вы
полнению, заблокированных в ожидании завершения операции ввода-вывода, а также
готовых к выполнению, но вытесненных на диск. Если значение в столбце
w когда-ни
будь станет отличным от нуля, это будет означать, что объем системной памяти не соот
ветствует текущей загрузке.
Столбцы, объединенные под общим заголовком
ной виртуальной памяти
(avm)
memory,
содержат данные об актив
и свободной виртуальной памяти
единенные под общим заголовком
page,
(fre).
Столбцы, объ
содержат данные об страничном обмене. Во
всех этих столбцах представлены средние значения: количество в секунду (табл.
29.3).
Таблица 29.З. Описание статистических показателей, выводимых командой V111stat
Столбец
Описание показателя
flt
Общее количество страничных сбоев
re
pi
Количество восстановленных страниц, т.е. возвращенных из списка неиспользуемых
Объем подкачанных страниц в килобайтах
ро
Объем выгруженных страниц в килобайтах
fr
sr
Объем списка неиспользуемых страниц в килобайтах
Количество страниц, обработанных по алгоритму часов
глава
29. Анализ
производительности
1085
В системах Linux статистические показатели, получаемые с помощью
vmstat, могут иметь приведенный ниже вид.
linux$ vmstat 5 5
procs --------memory--------- -swap- ---io-- -system- -----cpu-----r Ь swpd free buff cache si so
Ьi Ьо
in cs us sy id wa st
5
о
о
о
о
о
о
о
о
о
о
о
о
о
о
66488
66364
66364
66364
66364
В системе
40328
40336
40344
40352
40360
597972
597972
597972
597972
597972
о
о
о
о
о
о
о
о
о
о
252 45
о 37
о
5
о
3
о 21
1042
1009
1011
1020
1067
278
264
252
311
507
3
о
1
1
1
4
1
1
1
3
1
93
98
98
98
96
команды
о
о
о
о
о
о
о
о
о
количество процессов, rотовых к немедленному выполнению
FreeBSD
и заблокированных в ожидании ввода-вывода, выводится под заrоловком
procs.
si
Статистические показатели страничноrо обмена оrраничены двумя столбцами:
и
so,
которые представляют количество подкачанных и выrруженных страниц соот
ветственно.
Кажущиеся несоответствия между столбцами большей частью иллюзорны. В одних
столбцах указывается число страниц, в друrих
-
объем в килобайтах. Все значения явля
ются окруrленными средними величинами. Более тоrо, одни из них
ных величин, а друrие
С помощью полей
si
-
средние скаляр
средние изменений.
и
so
можно оценить интенсивность страничноrо обмена в си
стеме. Операция заrрузки (поле
si)
не обязательно означает, что из области подкачки
восстанавливается страница. Это может быть исполняемый код, постранично заrружа
емый из файловой системы, или копия страницы, создаваемая в режиме дублирования
при записи. Оба случая вполне типичны и не обязательно означают нехватку памяти. С
друrой стороны, операция выrрузки (поле
so)
всеrда означает принудительное вытесне
ние страниц с данными ядром.
Система, в которой непрерывно происходят операции выrрузки, скорее всеrо, вы
иrрает от добавления памяти. Если же это случается лишь время от времени и не вызы
вает жалоб со стороны пользователей, то можно не беспокоиться. В остальных случаях
дальнейший анализ будет зависеть от тоrо, что нужно сделать
-
оптимизировать систе
му для интерактивноrо режима (например, как рабочую станцию) или сконфиrуриро
вать ее для одновременной работы пользователей (например, как сервер приложений).
Анализ операций обмена с диском
Производительность жесткоrо диска можно контролировать с помощью команды
iostat.
Как и
vmstat,
эта команда подцерживает дополнительные арrументы, задающие
интервал времени в секундах между моментами выдачи статистических данных за истек
ший период и число повторений. Команда
iostat
выдает также сведения об использова
нии центральноrо процессора. Приведем небольшой пример для системы
Linux.
linux$ iostat
Device:
sda
dm-0
dm-1
dm-2
tps
0.41
0.39
0.02
0.01
kB_read/s
8.20
7.87
0.03
0.23
kB_wrtn/s
1.39
1.27
0.04
О.Об
kB read
810865
778168
3220
22828
kB wrtn
137476
125776
3964
5652
Информация о каждом жестком диске размещается в столбцах
kB _ wrtn/ s, kB read
и
kB wrtn:
tps, kB read/s.
объем пересылок за секунду, количество килобайтов,
частьlV.Эксплvатация
1086
считываемых за секунду, число килобайтов, записываемых за секунду, общее количество
считанных килобайтов и общее число записанных килобайтов.
Время, затрачиваемое на поиск блока,
-
основной фактор, влияющий на п}Юизводи
тельность жесткого диска. В первом приближении скорость вращения диска и быстро
действие шины, к которой он подключен, не имеют особого значения. Современные
диски могут пересылать сотни мегабайтов данных в секунду, если эти данные считыва
ются из смежных секторов. Вместе с тем количество операций поиска составляет от
до
300
100
в секунду. Если после каждой операции поиска будет читаться один-единствен
ный сектор, легко подсчитать, что в таком режиме задействуется менее
5%
максималь
ной пропускной способности канала обмена данными с диском. Твердотельные диски
имеют большое преимущество перед своими механическими предшественниками, по
скольку их производительность не связана со скоростью вращения пластин и перемеще
ниями головок.
Независимо от того, какой вид дисков вы используете
- SSD
или механические,
для достижения максимальной производительности необходимо помещать файло
вые системы, которые применяются одновременно, на разные диски. Хотя тип шины
и драйверы устройств влияют на степень эффективности, большинство компьютеров
могут работать с несколькими дисками параллельно, что значительно повышает про
пускную способность дисковой подсистемы. Например, данные и журнальные файлы
веб-сервера имеет смысл размещать на разных дисках.
Особенно важно распределить область подкачки между несколькими дисками, если
это возможно, поскольку страничный обмен обычно замедляет работу системы в целом.
Многие системы позволяют создавать как выделенные разделы подкачки, так и файлы
подкачки, записываемые в обычную файловую систему.
W
Подробнее о командах
Команда
lsof,
lsof и fuser
см. в разделе
5.2.
которая выводит список открытых файлов, и команда
fuser,
которая
перечисляет П}Юцессы, использующие файловую систему, могут оказаться весьма полез
ными для выявления проблем, связанных со скоростью выполнения операций обмена
с диском. Эти команды отображают взаимодействия между процессами и файловыми
системами и могут указать на непредусмотренные вами взаимосвязи. Например, если
некоторое приложение записывает свой журнальный файл на то же усТ}Юйство, кото}Юе
используется для ведения журналов регистрации базы данных, то в результате этот диск
может стать "узким местом" системы.
Утилита f io: анализ производительности
дисковой подсистемы
fio (github. com/axboe/fio) доступна как для системы Linux, так и для си
FreeBSD. Используйте ее для проверки производительности подсистемы хранения
Утилита
стемы
данных. Это особенно полезно в больших средах, где развертываются общие ресурсы хра
нения (такие как сеть хранения данных). Если вы оказываетесь в ситуации, когда скорость
работы системы хранения данных является проблемой, часто бывает полезно определить
следующие количественные показатели.
•
Пропускная способность при выполнении операций ввода-вывода в секунду
(IOPS)
(чтение, запись и смесь).
•
Средняя задержка (чтение и запись).
•
Максимальная задержка (максимальные значения задержек при чтении и записи).
Глава
29. Анализ
Как часть дистрибутива
(. fio)
1087
производительности
fio
в подкаталог
examples
включены файлы конфигурации
для типичных тестов. Рассмотрим пример простого теста чтения-записи.
READ: io=l024.7MB, aggrb=91326KB/s, minb=91326B/s, maxb=91326KB/s,
mint=10671msec, maxt=l0671msec
WRITE: io=l023.4MB, aggrb=98202KB/s, minb=98202KB/s, maxb=98202KB/s,
mint=10671msec, maxt=1067lmsec
Как и у многих показателей, связанных с производительностью, у этих параметров
нет общепринятых правильных значений. Лучше всего установить контрольный показа
тель, внести коррективы и выполнить повторные измерения.
Команда
sar: сбор статистических данных
и генерирование отчетов по ним
Команда
sar -
предназначенный для мониторинга производительности инструмент,
который "проверен временем" (эта команда появилась еще во времена АТ&Т
на системах
UNIX
и
Linux
UNIX)
и все еще остается актуальным, несмотря на использование
устаревшего синтаксиса командной строки.
На первый взгляд может показаться, что команда
цию, что и команды
vmstat и iostat.
sar
отображает ту же информа
Однако имеется одно очень важное отличие:
sar
"умеет" предоставлять отчеты как по старым (накопленным), так и текущим данным.
W
Пакет Linux, который содержит команду
sar,
называется ayaatat.
Если не указаны конкретные параметры, команда
sar
предоставляет отчет о том, как
центральный процессор использовался в течение того или иного дня каждые
10
мин.,
начиная с полуночи. Получение такого набора накопленных данных делает возможным
сценарий
sal,
который является частью пакета
sar
и требует указания интервала време
ни, через который он должен запускаться из демона
ет команда
sar,
aron.
Все данные, которые собира
она сохраняет в бинарном формате в каталоге
linux$ sar
Linux 4.4.0-66-generic (nuerbull) 03/19/17 - хВб 64 (4
19:10:01 CPU %user %nice %system %iowait %steal
19:12:01 all
0.02
0.00
0.01
0.00
0.00
19:14:01 all
0.01
0.01
0.00
0.00
0.00
/var/log.
CPU)
%idle
99.97
99.98
ЧастьlV.Эксплуатация
1088
Помимо информации о центральном процессоре, команда
sar
также может предо
ставлять отчеты по показателям дисковой и сетевой активности. Команда
бражает сводку данных об активности диска за сегодняшний день,
стические данные о сетевом интерфейсе, а
Команда
sar
sar
-А
-
sar -d ото
sar -n DEV - стати
всю доступную информацию.
имеет некоторые ограничения и потому хорошо подходит только
для быстрого получения кратких накопленных сведений. Тем, кто решил всерьез за
няться мониторингом производительности, лучше установить специальную платформу
с возможностями сбора коллекций данных и представления их в виде графиков, такую
как платформа
Grafana.
W Подробнее о платформе Grafaпa см. в разделе 28.3.
Выбор планировщика ввода-вывода в системах
В системах
Linux
Linux
используется алгоритм планирования подсистемы ввода
вывода, который выступает в роли "арбитра" между соревнующимися за
дисковый ввод-вывод процессами. Он оптимизирует порядок и время за
просов для обеспечения наилучшей возможной производительности подси
стемы ввода-вывода для данного приложения или ситуации.
В текущую версию ядра
Linux встроены три разных алгоритма планирования.
• Comletely Fair Queuing. Этот алгоритм используется по умолчанию и обычно
яв
ляется наиболее подХодящим вариантом для серверов общего назначения. Он ста
рается равномерно предоставлять доступ к подсистеме ввода-вывода. (Во всяком
случае этот алгоритм заслуживает награды за маркетинг: кто скажет "нет" совер
шенно справедливому планировщику?)
• Deadline.
Этот алгоритм "старается" сводить к минимуму время задержки для каж
дого запроса. Он изменяет порядок запросов для повышения производительности.
• NOOP.
Этот алгоритм реализует простую очередь типа
FIFO (First ln, First Out -
первым пришел, первым обслужен). Он предполагает, что запросы к подсистеме
ввода-вывода уже были (или еще будут) оптимизированы или переупорядочены
драйвером или устройством (каковым вполне может быть какой-нибудь контрол
лер со встроенной логикой). Он может быть наиболее подходящим вариантом
в некоторых SAN-cpeдax и для SSD-устройств (так как у этих устройств нет пере
менной задержки считывания данных).
Просмотреть или настроить алгоритм для конкретного устройства можно с помощью
файла /sys/Ьlock/ диcк/queue/scheduler. Активный планировщик указывается
в квадратных скобках.
$ cat /sys/Ыock/sda/queue/scheduler
noop deadline [cfq]
$ sudo sh -с "echo noop > /sys/Ыock/sda/queue/scheduler"
$ cat /sys/Ыock/sda/queue/scheduler
[noop] deadline cfq
Определив, какой из этих алгоритмов планирования является наиболее подходящим
для данной среды (что может потребовать проверки всех планировщиков), возможно,
вам удастся улучшить производительность подсистемы ввода-вывода.
W Дополнительную информацию о загрузчике GRUB см. в разделе 2.3.
Глава
29. Анализ
1089
производительности
К сожалению, алгоритм планирования не сохраняется при перезагрузке системы,
если он был установлен таким образом. Вы можете установить его для всех устройств во
время загрузки с помощью переменной ядра еlеvаtоr=алгоритм. Эта конфигурация
обычно устанавливается в файле конфигурации загрузчика
G RUB
gruЬ. conf.
Программа perf: универсальный
профилировщик системы Linux
Ядро
Linux
версии
2.6
и выше включает интерфейс
perf_events,
который
обеспечивает доступ на уровне пользователя к потоку событий, связанных
с производительностью ядра. Команда
perf -
это мощный интегрирован
ный системный профилировщик, который считывает и анализирует инфор
мацию из этого потока. Можно профилировать все компоненты системы:
аппаратное обеспечение, модули ядра, само ядро, совместно используемые
библиотеки и приложения.
Чтобы начать работу с командой
perf, вам нужно будет установить
linux-tools.
$ sudo apt-qet install linux-tools-common linux-tools-qeneric
linux-tools-'uname -r·
полный набор
пакетов
После того как вы установили программное обеспечение, ознакомьтесь с его руко
водством на сайте
goo. gl/f88rnt,
в котором приведены примеры и сценарии использо
вания. (Это глубокая ссылка на сайт
perf. wiki. kernel. org.)
Самый легкий путь начать работу не погружаясь в чтение документации
вать выполнить команду
perf top.
-
попробо
которая выводит на экран данные об использовании
центрального процессора в стиле команды
top.
Конечно, простой пример, приведен
ный ниже, дает только самое поверхностное представление о команде
показан процент времени, в течение которого процессор выпол
нял соответствующую функцию. В столбце
Shared Object
указан компонент (напри
мер, ядро), совместно используемая библиотека или процесс, в котором находится эта
функция, а в столбце
имя функции (в тех случаях, когда информация о сим
Symbol -
волах не была удалена).
29.7. ПОМОГИТЕ! Мой СЕРВЕР ТОРМОЗИТ!
В предыдущих разделах речь шла в основном о мероприятиях, которые позволяют до
биться средней производительности системы. Для ее повышения требуется корректиро
вать параметры конфигурации или модернизировать аппаратное обеспечение системы.
Однако даже правильно сконфигурированные системы иногда работают медленнее
обычного. К счастью, нерегулярные проблемы обычно легко диагностируются. В боль
шинстве случаев они создаются "ненасытным" процессом, который потребляет так
много ресурсов процессора, жесткого диска или сетевой подсистемы, что остальные
процессы буквально останавливаются. Иногда процесс намеренно захватывает ресурсы,
чтобы замедлить работу системы или сети. Это называется атакой типа "отказ в обслу
живании".
Первый шаг в диагностировании проблемы
-
запуск команд
ps auxww
или
top
для выявления явно неуправляемых процессов. Любой процесс, отнимающий более
50%
времени центрального процессора, можно с большой долей вероятности счи
тать ненормальным. Если столь непомерную долю ресурсов центрального процессо
ра не получает ни один процесс, посмотрите, сколько процессов получают минимум
по
10%.
Если их больше двух-трех (не считая самой команды
ps),
средняя загружен
ность системы, скорее всего, будет очень высокой. Такая ситуация сама по себе яв
ляется причиной низкой производительности. Проверьте среднюю загруженность
системы с помощью команды
uptime,
а затем выполните команду
vmstat
или
top,
чтобы узнать, простаивает ли когда-нибудь процессор.
Если конкуренции за право использования центрального процессора не наблюдает
ся, выполните команду
vmstat,
чтобы посмотреть, какова интенсивность страничного
обмена. Следует обращать внимание на все операции обмена с диском: множество опе
раций выгрузки могут означать соперничество за память, а наличие дискового трафика
в отсутствие страничного обмена говорит о том, что какой-то процесс монополизировал
диск, непрерывно читая и записывая файлы.
Нельзя непосредственно сопоставить дисковые операции с выполняющими их
процессами, но с помощью команды
ps
можно сузить круг "подозреваемых". Любой
процесс, работающий с диском, должен отнимать какую-то часть времени ЦП. Как
правило, всегда можно сделать обоснованное предположение о том, какой конкретно
ю активных процессов захватил ресурсы. 3 Для проверки своей теории на практике вы
полните команду
kill -STOP.
Предположим, процесс-виновник найден. Что с ним делать дальше? Как правило,
ничего. Некоторые операции действительно требуют много ресурсов и неизбежно за1 J>анее
признаками этого служили большой размер области данных процесса, размещенной в вир
туальной памяти, либо неестественно большой объем занимаемой процессом физической памя
ти, но появление совместно используемых библиотек сделало эти показатели не столь полезными.
Команда
ps
не умеет отделять общесистемные совместно используемые библиотеки от адресного
пространства отде.1ьных процессов. Кажется, что многие процессы занимают десятки мегабайтов
физической памяти, хотя на самом деле это не так.
Глава
29. Анализ
производительности
1091
медляют работу системы, но это вовсе не означает, что они незаконны. Однако с помо
щью команды
renice
можно изменить приоритет процесса, для которого ограничиваю
щим фактором является быстродействие центрального процессора.
Иногда правильная настройка приложения может привести к значительному сниже
нию потребления ресурсов. Этот эффект особенно заметен в сетевых серверных про
граммах, например в веб-приложениях.
В системе Liпux существует удобный инструмент для работы с процессами,
которые со:щают значительную нагрузку на диск,
-
команда
ionice.
Эта ко
манда устанавливает класс планирования ввода-вывода процесса; по крайней
мере один из доступных классов должен поддерживать числовые приоритеты
ввода-вывода, которые также могут быть установлены с помощью команды
ionice.
ionice
Наиболее полезным вариантом для запоминания является команда
-с
3
-р
pid,
позволяющая указанному процессу выполнять опе
рации ввода-вывода только в том случае, если на это не претендуют другие
процессы.
Ядро позволяет процессу ограничивать объем потребляемой им самим физической
памяти при помощи системного вызова
setrlimit. 4 Эта возможность также доступна
ulimit (limits в системе FreeBSD).
в системной оболочке в виде встроенной команды
Например, команда
$
uliшit -ш
32000000
ограничивает использование физической памяти для всех последующих пользователь
ских команд тридцатью двумя мегабайтами. Ее действие примерно эквивалентно дей
ствию команды
renice
в отношении процессов, ограничивающим фактором для кото
рых является объем памяти.
Если неуправляемый процесс не является источником снижения производитель
ности. нужно проанализировать две другие возможные причины. Первая
-
переrрузка
сети. Многие программы настолько тесно связаны с сетью, что иногда трудно понять,
где речь идет о производительности системы, а где
-
о производительности сети.
В некоторых случаях проблемы, связанные с перегрузкой сети, выявить сложно, по
тому что они возникают и исчезают очень быстро. Например, если на всех компьютерах
сети каждый день в определенное время с помощью демона
cron
запускается какая-то
сетевая программа. то в сети может возникать кратковременный, но серьезный затор.
Все компьютеры "зависнут" секунд на пять, после чего ситуация нормализуется.
Вторая причина
-
задержки, связанные с работой серверов.
постоянно обращаются к удаленным серверам
UNIX- и Liпuх-системы
NFS, Kerberos, DNS и т.п. Если сервер
не работает или какая-то иная проблема привела к тому, что связь с ним стала ненадеж
ной, это ощущают на себе все клиентские системы.
Предположим, что в интенсивно эксплуатируемой системе какой-то процесс каждые
несколько секунд вызывает библиотечную функцию
DNS
gethostent.
Если сбой в работе
заставляет эту функцию тратить на свое выполнение две секунды, будет заметно
общее снижение производительности системы. На удивление, большое число проблем
с производительностью серверов связано с неправильной конфигурацией прямою и об
ратного поиска в
4 Более
DNS.
тонкое управление ресурсами может быть достигнуто посредством СКRМ-функций
based Kerпel Resource
sourceforge.net.
Maпagemeпt
-
управление ресурсами ядра на базе классов); см.
(Classckrm.
частьlV.Эксплvатация
1092
29.8. ЛИТЕРАТУРА
• DREPPER ULRICH. What Every Programmer Should Know about Memory. 1 wn. net /
Articles/250967.
•
EzoLт Рн1шr
G. Optimizing Linux Pe!formance. Upper Saddle River, NJ: Prentice
На\\
PTR, 2005.
• GREGG, BRENDAN. Systems Performance: Enterprise and the Cloud. Upper Saddle River,
NJ: Prentice На\\ PTR, 2013.
• KozюL, РRАвнлт, AND QшNCEY KozюL. Нigh Pe!formance Parallel 1/0. London: CRC
Press, 2014.
Глава 30
центры обработки данных
Надежность службы зависит от надежности работы центра обработки данных, кото
рый ее обеспечивает. 1 Для специалистов, имеющих практический опыт, это очевидно.
Сторонники облачных вычислений иногда, по-видимому, подразумевают, что обла
ко может волшебным образом разбить цепи, соединяющие физический и виртуальный
миры. Однако, хотя облачные провайдеры предлагают множество услуг, которые помо
гают повысить устойчивость и доступность, каждый облачный ресурс в конечном итоге
живет где-то в физической реальности.
Понимание того, где на самом деле находятся ваши данные, яВ11яется важной частью
работы системного администратора. Если вы участвуете в выборе сторонних облачных
провайдеров, оцените поставщиков и их возможности количественно. Вы также може
те оказаться в положении, когда безопасность, суверенитет данных или политические
проблемы диктуют необходимость создания и обслуживания собственного центра об
работки данных.
Центр обработки данных состоит из следующих компонентов.
•
•
•
Физически безопасное и защищенное место.
Стойки с компьютерами, сетевым оборудованием и дисками.
Система энергоснабжения (основная и резервная), достаточная для работы всех
размещенных устройств.
1 По
крайней мере в первом приближении. Разумеется, можно распределить службу между
несколькими центрами обработки данных, тем самым ограничив влияние сбоя в каком-либо из
центров.
1094
•
ЧастьlV.Эксплуатация
Система охлаждения для поддержки требуемого температурного режима работы
устройств.
•
Сетевые соединения внутри центра и с внешним миром (корпоративная сеть,
•
Технический персонал, поддерживающий работу оборудования и инфраструктуры.
партнеры, поставщики оборудования, Интернет).
Некоторые аспекты центров обработки данных, такие как их физическое расположе
ние, системы электропитания и охлаждения, традиционно разрабатывались и поддержи
вались техническим персоналом объекта. Тем не менее стремительные темпы развития
IТ-технологий и все более высокие требования к недопустимости простоев стимулируют
тесное сотрудничество между сотрудниками IТ-подразделений и техническим персона
лом при планировании и эксплуатации центров обработки данных.
30.1.
Стойки
Времена традиционных центров обработки данных с фальшполами, в которых ка
бели электропитания, система охлаждения, сетевые соединения и телефонные линии
спрятаны под полом, прошли. Сможете ли вы обнаружить кабель, который теряется
в подпольном лабиринте? Наш опыт подсказывает, что все это выглядит красиво толь
ко на картинке, а на самом деле комната с "классическим" фальшполом
-
это просто
скрытая "крысиная нора". Сегодня фальшполы используются только для того, чтобы
скрыть электрические кабели, распределить охлажденный воздух и больше ни для чего.
Сетевые кабели (и медный, и оптоволоконный) должны проходить по верхним направ
ляющим коробам. 2
В специализированных центрах обработки данных размещение оборудования в стой
ках (а не, скажем, на столах или на полу)
-
единственный профессиональный выбор с
точки зрения обслуживания. В лучших схемах расположения запоминающих устройств
используются стойки, связанные друг с другом через верхние направляющие короба, по
которым проходят кабели. Этот подход обеспечивает высокую технологичность без по
тери возможности для сопровождения.
Лучшие верхние направляющие короба для кабелей, насколько нам известно, произ
водятся компанией
Chatsworth Products ( chatsworth. com).
Использование стандартных
19-дюймовых монорельсовых телекоммуникационных стоек позволяет создавать бло
ки серверов, монтируемых на полках или в стойках. Две смежные 19-дюймовые теле
коммуникационные стойки создают высокотехнологичную разновидность "традицион
ной" стойки для ситуаций, в которых вы вынуждены располагать в соседних стойках
оборудование, ориентированное относительно передней и задней панелей. Компания
Chatsworth
поставляет стойки, короба для кабелей и всякие приспособления для их
укладки и маркировки, а также оборудование, необходимое для их монтажа в вашем
здании. Поскольку кабели располагаются в доступных коробах, их легко отслеживать
и содержать в порядке.
30.2.
ЭЛЕКТРОПИТАНИЕ
Компьютерное оборудование требует стабильного и бесперебойного электропитания.
Для этого центр обработки данных должен иметь следующие компоненты.
2 Провода
электропитания в настоящее время также проходят по наружным кана.лам.
30.
Глава
•
Центры обработки данных
1095
Источники бесперебойноrо электропитания
(UPS)
обеспечивают питание, ко1'да
обычный стационарный источник питания (например, коммерческая электро
сеть) становится недоступным. В зависимости от размера и мощности источники
бесперебойного электропитания могут обеспечивать работу оборудования на про
тяжении от нескольких минут до нескольких часов. Они не могут самостоятельно
поддерживать работу устройств в случае длительного отключения внешнего элек
тропитания.
•
Автономные резервные электроrенераторы. Если коммерческая сеть электропитания
недоступна, автономные резервные электрогенераторы могут обеспечить долго
временную работу оборудования. Генераторы обычно заправляются дизельным то
пливом, сжиженным или природным газом и могут поддерживать работу системы
до тех пор, пока имеется топливо. Обычно принято хранить на месте запас топ,1и
ва как минимум на
72
часа работы и организовать покупку топлива у нескольких
поставщиков.
•
Резервные фазы электропитания. В некоторых местах существует возможность под
ключить оборудование к нескольким фазам электропитания (возможно, от разных
поставщиков).
m
Процедуры выключения и перезагрузки системы описаны в разделе
2.9.
Во всех случаях серверы и сетевая инфраструктура должны оснащаться источника
ми бесперебойного электропитания. Качественные устройства
Ethernet
или
USB,
UPS
имеют интерфейсы
позволяющие подключать их к компьютеру, который они обеспечива
ют электричеством, или к централизованной системе слежения, способной обеспечить
быстрое реагирование. Такие соединения позволяют пересылать на компьютеры или
операторам сообщения об отказе системы электропитания и требования выполнить ак
куратное выключение компьютеров, пока не разрядились батареи.
Устройства
UPS
имеют разные размеры и мощности, но даже самое большое из них
не может служить долговременным источником электропитания. Если ваше оборудова
ние должно работать от автономного источника питания дольше, чем может выдержать
UPS,
вам нужно подключить к системе автономный резервный электрогенератор.
Существует широкий выбор резервных генераторов, мощность которых
колеблет
ся от
5 до 2500 кВт. Золотым стандартом является семейство генераторов компании
Cummins Onan (power. cummins. com). Большинство организаций выбирает дизельный
генератор. Если вы работаете в холодном климате, примите меры, чтобы генератор был
заправлен "зимней соляркой", или замените ее авиационным топливом
Jet
А-1, чтобы
предотвратить гелеобразование. Дизельное топливо является химически стабильным, но
со временем в нем могут заводиться водоросли. Поэтому, если вы планируете хранить
дизельное топливо долгое время, добавьте в него альгицид.
Генераторы и обслуживающая их инфраструктура
-
довольно дорогое удовольствие,
но в некоторых ситуациях они могут сэкономить вам деньги. Если вы планируете уста
новить резервный генератор, то ваше устройство
UPS должно быть достаточно
мощным,
чтобы после выключения электропитания вы успели запустить резервный генератор.
Если вы используете устройства
UPS
или генераторы, чрезвычайно важно периоди
чески их тестировать. Мы рекомендуем тестировать все компоненты резервной систе
мы электропитания каждые полгода. Кроме того, вы (или производитель оборудования)
должны выполнять регламентные работы на этом оборудовании как минимум раз в r·од.
ЧастьlV.Эксплуатация
1096
Требования к электроснабжению стоек
Планирование электроснабжения центра обработки данных
-
одна из наиболее
сложных задач. Как правило, возможность создать новый центр обработки данных или
значительно перестроить существующий возникает каждые десять лет, поэтому, обдумы
вая систему электроснабжения, важно заглянуть далеко в будущее.
Большинство архитекторов дпя вычисления мощности, необходимой в перспективе
дпя обеспечения работы центра обработки данных, склонны умножать его площадь в
кв. футах на некий загадочный поправочный коэффициент. В реальных ситуациях этот
подход не эффективен, потому что сам по себе размер центра обработки данных несет
мало информации о типе оборудования, которое в нем будет работать. Мы рекомендуем
использовать модель энергопотребления в расчете на стойку и не обращать внимания
на площадь пола.
Традиционно центры обработки данных проектировались так, чтобы на каждую
стойку приходилось от
1,5 до 3 кВт
мощности. В настоящее время производители стали
упаковывать серверы в стоечные корпуса типа
ров, в которых размещаются более
20
1U
и создавать шасси лезвийных серве
лезвий, поэтому мощность, необходимая дпя пи
тания всей стойки современного электронного оборудования, резко возросла.
Одно из возможных решений проблемы, связанной с плотностью упаковки оборудо
вания и ростом при этом потребляемой мощности,
ко необходимое количество серверов типа
1U,
-
размещать в каждой стойке толь
оставляя остальную часть стойки пустой.
Несмотря на то что эта технология устраняет необходимость обеспечения дополнитель
ной мощности дпя стойки, она приводит к чрезмерному растрачиванию места. Лучше
разработать реалистичный проект обеспечения мощности, которая может понадобиться
дпя каждой стойки, и подумать, где ее взять.
Требования к мощности у разного оборудования различные, поэтому трудно пред
сказать, какая мощность понадобится в будущем. Целесообразно создать систему
с разными уровнями потребления мощности, в которой на каждом уровне все стойки
получают одинаковую мощность. Эта схема полезна не только дпя удовлетворения по
требностей текущих моделей, но и дпя планирования будущего использования. Ряд фак
торов, которые следует учитывать при определении уровней потребляемой мощности,
перечислены в табл.
Таблица
30.1.
30.1.
Оценки уровня мощности для стоек в центре обработки данных
Уровень мощности
кВт/стойка
Невероятно высокая плотность или специальные требования
Сверхвысокая плотность
40
25
Очень высокая плотность (например, лезвийные серверы)
20
Высокая плотность (например, серверы
Системы хранения данных
16
12
Сетевые коммутаторы
8
Обычная плотность
6
1U)
Определив уровни мощности, оцените потребности в стойках дпя каждого уровня.
Затем на плане помещения поместите рядом друг с другом стойки, относящиеся к одно
му и тому же уровню. Такое разделение на зоны концентрирует стойки с высоким потре
блением мощности и позволяет правильно распределить ресурсы охлаждения.
Глава
30.
Центры обработки данных
1097
Киловольт-ампер или киловатт
Одна из основных причин непонимания между специалистами по информационным
технологиям, техниками и инженерами-электриками заключается в том, что в каждой
из этих групп используются разные единицы измерения мощности. Выходная мощ
ность, которую может обеспечить устройство
UPS,
обычно измеряется в киловольт-ам
перах (кВА). Однако инженеры, обслуживающие компьютерное оборудование, и элек
трики, обеспечивающие работу центра обработки данных, обычно выражают мощность
в ваттах (Вт) или киловаттах (кВт). Возможно, вы помните из курса физики, что ватт =
= вольт х ампер. К сожалению, ваш школьный учитель забыл напомнить, что ватт - это
векторная величина, в формулу которой для вычисления мощности переменного тока,
кроме напряжения (вольт) и силы тока (апмер), входит еще так называемый "коэффи
циент мощности"
(power factor).
Если вы разрабатываете конвейерную линию по разливу пива на пивоваренном заво
де, в которой используется много двигателей переменного тока и другого тяжелого обо
рудования, то пропустите этот раздел и наймите квалифицированного инженера, который
вычислит коэффициент мощности для вашей установки. При работе с современным ком
пьютерным оборудованием вы можетесхитрить и использовать константу. Для "прибли
зительного" преобразования кВА в кВт можно использовать следующие формулы.
кВА
= кВт/ 0,85
И наконец, оценивая суммарные мощности, необходимые для центра обработки
данных (или для вычисления выходной мощности устройства
UPS),
следует измерить
реальную потребляемую мощность, а не полагаться на значения, указанные произво
дителем оборудования на этикетке устройства, на которой обычно указываются макси
мальные значения потребления.
Ш Дополнительные советы по измерению потребляемой мощности см. в разделе 30.З.
Энерzоэффективность
Энергоэффективность стала популярным показателем для оценки эксплуатации
центров обработки данных. Промышленность стандартизировала простой коэффици
ент, известный как эффективность использования энергии
PUE),
(power usage effectiveness -
выражающий общую эффективность центра.
PUE = Общая мощность, потребляемая предприятием /
/ Общая мощность, потребляемая IТ-оборудованием
Гипотетически идеальный центр обработки данных должен иметь показатель
равный
1,0;
PUE,
иначе говоря, он будет потреблять ровно столько энергии, сколько необходи
мо для работы IТ-оборудования, без накладных расходов. Конечно, эта цель недостижима
на практике. Оборудование генерирует тепло, которое необходимо отводить, сотрудникам
требуется освещение и другие условия для комфортной работы и т.д. Чем выше значение
PUE, тем
меньше энергоэффективность (и выше стоимость) центров обработки данных.
Современные центры обработки данных, которые являются достаточно энергоэф
фективными, обычно имеют коэффициент
PUE,
равный
1,4
или менее. Для справки,
центры обработки данных еще десять лет назад обычно имели коэффициенты
апазоне
2,0-3,0.
Компания
Google,
PUE в ди
которая сделала акцент на энергоэффективность,
регулярно публикует свои коэффициенты
трах обработки данных среднего значения
PUE, а с 2016 года она достигла
PUE, равного 1,12.
в своих цен
ЧастьlV.Эксплvатация
1098
Измерение
Вы можете судить только о том, что имеет количественный показатель, получен
ный в результате измерения. Если вы серьезно относитесь к энергоэффективности,
важно понять, какие устройства потребляют больше всего энергии. Хотя коэффициент
PUE
дает общее представление об объеме энергии, потребляемой сверх IТ-ресурсов,
он очень мало говорит о энергоэффективности реальных серверов. (Фактически за
мена серверов на более энергоэффективные модели увеличит коэффициент
PUE,
а не
уменьшит его.)
Администратору центра обработки данных следует выбрать компоненты, которые
используют минимальное количество энергии. Одной из очевидных технологий явля
ется измерение потребления энергии на уровне отсека, стойки и устройства. Выберите
или создайте центры обработки данных, которые могут легко предоставить наиболее
важные данные.
Стоимость
Когда-то стоимость электроэнергии была более или менее одинаковой для цент
ров обработки данных в разных местах. В наши дни индустрия облачных вычислений
(Amazon, Google, Microsoft
и др.) заставляет проектировщиков центров обработки дан
ных учитывать их потенциальную экономическую эффективность в любом уголке мира.
Одной из успешных стратегий было размещение крупных центров обработки данных
вблизи источников недорогой электроэнергии, таких как гидроэлектростанции.
Принимая решение о том, следует ли запускать собственный центр обработки дан
ных, обязательно учитывайте стоимость электроэнергии в вашей местности. Скорее все
го, у крупных компаний будет естественное преимущество в стоимости таких (и других)
услуг. Широкая доступность высокоскоростных оптических каналов передачи данных
и их невысокая стоимость уже не ставят во главу угла поиск ближайшего центра обра
ботки данных рядом с вашим местом работы.
Удаленное управление
Вы можете оказаться в ситуации, в которой необходимо регулярно включать и вы
ключать сервер из-за ошибок в работе ядра или оборудования. Кроме того, возможно,
в вашем центре обработки данных установлены серверы, которые работают под управ
лением другой операционной системы, а не
Linux.
В этом случае также часто возни
кает необходимость их регулярного включения и выключения. В любом случае следует
рассмотреть возможность инсталляции системы, позволяющей выполнять эти операции
в удаленном режиме.
Разумным решением является выбор продукции компании
(АРС). Продукция
MasterSwitch
American Power Conversion
похожа на линейку устройств бесперебойного питания,
за исключением того, что ею можно управлять с веб-браузера с помощью встроенного
порта
Ethemet.
30.3. ОХЛАЖДЕНИЕ
и ОКРУЖАЮЩАЯ СРЕДА
Как и люди, компьютеры лучше и дольше работают в благоприятной среде.
Поддержка безопасной температуры
-
основное условие их благополучной работы.
Глава
30.
центры обработки данных
1099
Американская ассоциация инженеров по отоплению, охлаждению и кондициониро
ванию воздуха
ASHRAE)
(American Society of Heating, Refrigerating and Air-conditioning Engineers -
традиционно рекомендует поддерживать температуру воздуха в центрах обра
ботки данных (измеряемую на воздухозаборниках серверов) от
20 до 25
·с. Поддерживая
попытки организаций сократить потребление электроэнергии, ассоциация
пустила в
2012
ASHRAE
вы
году новые рекомендации, согласно которым температуру воздуха следует
поддерживать в диапазоне от
18 до 27
·с. Несмотря на то что этот диапазон кажется не
обычайно широким, он предполагает, что современное оборудование способно работать
в широком диапазоне температур.
Оценка нагрузки на систему охлаждения
Поддержка требуемой температуры в помещении начинается с точной оценки на
грузки на систему охлаждения. Традиционные модели охлаждения в центрах обработки
данных, взятые из учебников (даже из книг, написанных в 1990-х годах), могут на по
рядки отличаться от сегодняшних реалий, связанных с функционированием высоко
упакованных шасси, содержащих лезвийные сервера. По этой причине мы рекомендуем
перепроверять оценки нагрузки на систему охлаждения, полученные вашими инженера
ми по отоплению, охлаждению и кондиционированию воздуха
(HVAC).
Вы должны проверить тепловую нагрузку, которую оказывают следующие компоненты.
•
Крыша, стены и окна (от инженеров
•
•
•
Электронное оборудование.
HVAC).
Осветительная арматура.
Операторы (люди).
Из этих факторов только первый относится к компетенции инженеров
HVAC.
Конечно, они могут оценить и остальные факторы, но вы обязаны провести собствен
ные вычисления. Оцените расхождения между вашими оценками и оценками, получен
ными инженерами
HVAC,
и дайте исчерпывающее объяснение.
Крыша, стены и окна
Крыша, стены и окна (не забывайте о солнечной нагрузке) вносят дополнительную
нагрузку на систему охлаждения вашего помещения. Инженеры
HVAC
обычно имеют
большой опыт работы с этими элементами и должны быть в состоянии дать вам хоро
шие оценки.
Электронное оборудование
Для тоrо чтобы определить тепловую нагрузку, которую оказывают ваши серверы (и
другое электронное оборудование), следует определить потребляемую серверами мощ
ность. С практической точки зрения вся входящая электрическая энергия в конце кон
цов превращается в тепловую.
Как и при планировании мощностей по электропитанию, непосредственное измерение
потребляемой мощности, безусловно, является лучшим способом получить эту информа
цию. Вам может помочь дружелюбный сосед-электрик или же вы можете купить недорогой
прибор и сделать это сами. Самым популярным устройством является КШ А
нии РЗ по цене около
20 долл.,
но он ограничен небольшими нагрузками
Wcitt от компа
(15 ампер), кото
рые подключаются к стандартной розетке. Для больших нагрузок или нестандартных разъ
емов используйте такие амперметры, как
Fluke 902 (также
известный как "токовые клещи").
частьlV.Эксплуатация
1100
Большая часть оборудования характеризуется максимальной потребляемой мощно
стью, измеренной в ваттах. Однако типичное потребление, как правило, значительно
меньше максимального.
Расход мощности можно преобразовать в стандартную единицу количества тепла
BTUH (British Thermal Unit per hour - количество британских тепловых единиц в час),
умножив его на коэффициент 3,412 ВТUН/Вт. Например, если вы хотите построить
центр обработки данных, в котором будет 25 серверов, потребляющих по 450 Вт каж
дый, то вычисления будут выглядеть следующим образом.
25
серверов х
450
Вт/сервер х
3,412
ВТUН/Вт =
38385 BTUH.
Осветительная арматура
Как и в случае электронного оборудования, оценить тепловую нагрузку от освети
тельного оборудования можно по расходу мощности. Как правило, в офисах в качестве
осветительной арматуры используются 40-ваттные люминесцентные лампы. Если в ва
шем новом центре обработки данных шесть таких светильников (по
4 лампы
в каждом),
то вычисления будут выглядеть следующим образом.
6 ламп
х
160
Вт/светильник х
3,412
ВТUН/Вт =
3276 BTUH.
Операторы
Иногда людям необходимо войти в центр обработки данных, чтобы выполнить
какие-то действия. Предположим, что каждый входящий человек создает тепловую на
грузку величиной
300 BTUH.
Допустим, что одновременно в центр обработки данных
могут войти четыре человека.
4 человеках 300
ВТUН/чел =
1200 BTUH.
Общая тепловая нагрузка
Вычислив тепловую нагрузку для каждого компонента, просуммируйте их и опреде
лите общую тепловую нагрузку. В нашем примере мы предполагали, что инженер
оценил тепловую нагрузку от крыши, стен и окон равной
HVAC
20000 BTUH.
20000 BTUH для крыши, стен и окон
38385 BTUH для серверов и другого электронного оборудования
3276 BTUH для осветительной арматуры
1200 BTUH для операторов
62861 BTUH всего
Производительность систем охлаждения обычно измеряется в тоннах охлаждения.
Для того чтобы преобразовать единицы
лить результат на
12000
BTUH
в тонны охлаждения, необходимо поде
ВТUН/т. Кроме того, следует допустить по крайней мере
ный коэффициент ухудшения, чтобы учесть ошибки и будущий рост системы.
62681 BTUH
х
1 т / (12000 BTUH)
х
1,5
= 7,86 тонн охлаждения
Проверьте, насколько ваши оценки расходятся с оценками инженеров
HVAC.
50%-
Глава
30.
Центры обработки данных
1101
Теплые и холодные отсеки
Вы можете резко уменьшить трудности, связанные с охлаждением центра обработки
данных, nроанализировав схему его устройства. Самой эффективной стратегией являет
ся разделение центра на теnлые и холодные отсеки .
Помещения, которые имеют фальшnол и охлаждаются традиционными
(computer room air conditioner -
CRAC
кондиционеры воздуха в ком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ирометра), который является
незаменимым инструментом современного системного администратора. Это устройство
стоит около
100 долл.
(наnример,
Fluke 62)
и nостоянно измеряет темnературу любого
nредмета, на который вы его нацелите на расстоянии до
2 метров.
Только не доставайте
его в баре!
Теплый
.,.__--"
Холодный
отсек
Рис.
30.1.
Холодные и теплые отсеки с фальшполом
Если вам нужно развести кабеля nод nолом, nрокладывайте кабели nитания nод хо
лодными отсеками, а сетевые
-
nод теnлыми.
В nомещениях без фальшnола могут исnользоваться междурядные охлаждающие
устройства, наnример фирмы АРС (аре .
com). Эти небольшие nлоские устройства nо
30.2.
мещаются между стойками. Принциn работы этой схемы nоказан на рис.
ЧастьlV.Эксплvатация
1102
о°"
..,:s:
о"'
,_:х:
Стойка
'-'~
....
...,
~*
.... =
,..,
=""
~~
.... ...,
о°"
=""
,_:х:
Стойка
Стойка
,_:х:
Стойка
о°"
..,:s:
,_:х:
Стойка
~~
.... ...,
~*
vv
,_:х:
Стойка
Стойка
'-'~
.......
~*
Стойка
Стойка
>-с:
'-'><
>-о
~~
30.2.
Стойка
о"'
co:S:
>-с:
Рис.
g~
....
...,
....
=
'-'><
"'о
vv
vv
Стойка
Стойка
~s
"'о
Холодные и теплые отсеки с междурядными охлаждающими устройствами
Устройства
CRAC
и междурядные устройства охлаждения должны иметь возмож
ность отводить тепло за пределы центра обработки данных. Это требование обычно
удовлетворяется за счет циркуляции охлаждающей жидкости (например, охлажденной
воды, хладагента
Puron/R410A или R22), которая отводит теruю во внешнюю среду. Мы
30.1 и 30.2 циркуляцию охлаждающей жидкости, чтобы не загро
не показали на рис .
мождать рисунки, но в большинстве проектов охлаждения они обязательно использу
ются.
Влажность
В соответствии с рекомендациями
ботки данных должна быть в пределах
2012 ASHRAE влажность воздуха в центре обра
8-60%. Если влажность воздуха слишком низкая,
возникают проблемы из-за статического электричества. Проведенное недавно исследо
вание показало, что существует небольшая эксruJуатационная разница между
дыдущим стандартом в
25%,
8%
и пре
поэтому минимальный стандарт влажности был скорректи
рован соответствующим образом .
Если влажность слишком высокая, конденсат воды может создать нежелательную
проводимость на печатных платах, вызвать короткое замыкание и окисление контаков.
В зависимости от географического расположения может возникнуть необходимость
увлажнения или осушения среды центра обработки данных, чтобы поддерживать требу
емый уровень влажности.
Мониторинг окружающей среды
Если вы обеспечиваете работу чрезвычайно важного вычислительного оборудования,
необходимо следить за температурой (и другими факторами окружающей среды, такими
как шум и потребляемая мощность) в центре обработки данных, когда вы там отсутству
ете. Вы будете очень огорчены, придя на работу в понедельник и обнаружив расплав
ленный пластик на полу центра обработки данных.
К счастью, существуют автоматические мониторы, которые могут следить за состо
янием окружающей среды в ваше отсутствие . Мы сами используем и рекомендуем вам
Глава
30.
Центры обработки данных
продукцию семейства
Sensaphone.
1103
Эти недорогие устройства для мониторинга следят за
такими показателями, как температура, шум и потребляемая мощность, и звонят вам
по телефону или отправляют сообщение на веб-сайт, если возникают проблемы.
30.4. УРОВНИ
НАДЕЖНОСТИ ЦЕНТРОВ ОБРАБОТКИ ДАННЫХ
Исследованием вопросов, связанных с управлением центрами обработки данных,
занимается промышленная группа
Ее сотрудники разработали четы
Uptime lnstitute.
рехуровневую систему классификации надежности центров обработки данных, которая
представлена в табл.
30.2.
В этой таблице обозначение
центра есть достаточно ресурсов (устройств
мальную работу. Обозначение
оборудования;
Таблица
30.2.
2N -
UPS,
N+ 1 означает,
N означает,
что в распоряжении
генераторов), чтобы обеспечить нор
что у центра есть одна запасная единица
что у каждого устройства есть дублирующее оборудование.
Система классификации, преД11оженная промыw11енной группой
Uptime lnstitute
Уровень
Генератор
UPS
Источник электропитания
HVAC
Коэффициент
доступности, %
Нет
N
N+I
2N
N
N+t•
N+t•
2N
Один
2
3
N
N+I
N+I
2N
99,671
99,741
99,982
99,995
4
Один
Два (с возможностью переключения)
Два (работающих одновременно)
ас запасными компонентами.
Центры, относящиеся к высшему уровню надежности, должны быть разделены
на отсеки, чтобы сбой систем электропитания или охлаждения в одной из группы си
стем не приводил к отказу другой.
Коэффициент использования, равный
99,671 %,
на первый взгляд может выглядеть
привлекательным, но это значит, что в течение года система будет находиться в нерабо
чем состоянии примерно
29
часов. Коэффициент использования, равный
чает, что система может не работать
26
99,995%,
озна
минут в год.
Разумеется, никакое количество резервных источников электропитания или
устройств охлаждения не спасет систему, если она плохо управляется или неправиль
но спроектирована. Центр обработки данных
-
это основной структурный элемент, но
его недостаточно для обеспечения работы всей организации с точки зрения конечного
пользователя.
Стандарты работоспособности систем, разработанные группой
Uptime Jnstitute
(включая сертификацию проектов, конструкций и этапов эксплуатации), можно най
ти на ее веб-сайте
uptimeinstitute.org.
В некоторых случаях организации исполь
зуют концепцию этих уровней, не выплачивая значительных средств за сертификацию
Uptime lnstitute.
Важным является не сертификат в рамочке, а использование общей
лексики и методологии оценки для сравнения центров данных.
30.5.
БЕЗОПАСНОСТЬ ЦЕНТРОВ ОБРАБОТКИ ДАННЫХ
Возможно, это само собой разумеется, но физическая безопасность центра обработки
данных по крайней мере так же важна, как и его экологические атрибуты. Удостоверьтесь,
ЧастьlV.Эксплvатация
1104
что вы внимательно учли все возможные угрозы, как естественные (например, пожар, на
воднение, землетрясение), так и искусственные (например, происки конкурентов и пре
ступников). Многоуровневый подход к безопасности
-
лучший способ гарантировать, что
одна ошибка или сбой не приведут к катастрофическому результату.
Местонахождение
По возможности центры обработки данных не должны располагаться в районах, под
верженных лесным пожарам, торнадо, ураганам, землетрясениям или наводнениям. По
аналогичным причинам рекомендуется избегать техногенных опасных зон, таких как
аэропорты, автострады, нефтеперерабатывающие заводы и нефтебазы.
Поскольку центр обработки данных, который вы выбираете (или создаете), вероят
но, будет вашим домом в течение длительного времени, стоит потратить некоторое вре
мя на изучение доступных данных о рисках при выборе места для его расположения.
Геологическая служба США
(usgs. gov)
публикует статистические данные, такие как
вероятность землетрясения, а организация
Uptime Institute
создает сложную карту рис
ков, связанных с выбором места для расположения центров обработки данных.
Периметр
Чтобы снизить риск целенаправленной атаки, центр обработки данных должен быть
окружен ограждением, находящимся на расстоянии не менее
8 метров (25
футов) от зда
ния со всех сторон. Доступ к внутренней части периметра ограждения должен кон
тролироваться охранником или многофакторной системой пропусков (бейдж-системы
доступа). Транспортные средства, которым разрешен въезд на территорию центра об
работки данных, не должны находиться ближе
8 метров
к зданию.
Непрерывный видеомониторинг должен охватывать
100%
внешнего периметра,
включая все ворота, подъездные пути доступа, автостоянки и крыши.
Здания не должны иметь вывесок. Никакая вывеска не должна указывать, кому при
надлежит здание, или упоминать, что в нем находится центр обработки данных.
Доступ к объекту
Доступ к самому центру обработки данных должен контролироваться охранником
и многофакторной системой пропусков, возможно, со снятием биометрических пока
зателей. В идеальном случае уполномоченные стороны должны быть включены в систе
му контроля физического доступа до их первого посещения центра обработки данных.
Если это невозможно, охранники на месте должны следить за процессом проверки, ко
торый включает подтверждение личности и санкционированных действий каждого со
трудника.
Одной из самых сложных ситуаций в обучении охранников является надлежащее об
ращение с посетителями, которые утверждают, что они пришли ремонтировать какую
то часть инфраструктуры, например кондиционер. Не делайте ошибку: если охранник
не может подтвердить, что кто-то разрешил доступ или пригласил этого техника, такие
посетители не должны получать пропуск.
Глава
30.
Центры обработки данных
1105
Доступ к стойке
Большие центры обработки данных часто сдаются в аренду третьим сторонам. Этот
подход экономически оправдан, но он несет дополнительную ответственность за орга
низацию защиты каждой стойки (или отсека стоек). Это еще один случай, когда необ
ходима многофакторная система контроля доступа (например, устройство чтения карт
памяти и считыватель отпечатков пальцев), чтобы гарантировать, что только авторизо
ванные стороны имеют доступ к вашему оборудованию. Каждая стойка также должна
иметь индивидуальную систему видеонаблюдения.
30.6.
ИНСТРУМЕНТЫ
Эффективный системный администратор
-
это хорошо оснащенный системный ад
министратор. Иметь набор специальных инструментов важно для минимизации време
ни простоя в случае отказа оборудования. В табл.
30.3
перечислены некоторые инстру
менты, которые следует включать в такой набор.
Таблица 30.З. Инструментальный набор системного администратора
Универсальные инструменты
150-200 грамм
Комплект шестигранных ключей (ключей Аллена)
Шариковый молоток,
Ножницы
Нож электрика или складной нож
Небольшой светодиодный фонарик
Крестообразная отвертка: №О, №1 и №2
Набор торцевых шестигранных ключей
Плоскогубцы и круглогубцы
Искатель скрытой проводки
Отвертка под шлиц:
Набор звездообразных ключей
Миниатюрные часовые отвертки
Torx
1/8", 3/16" и 5/16"
Миниатюрный пинцет
·····-''.'' ..
..
..
.
Специальные компьютерные инструменты
····························································••······························································································
Цифровой мультиметр
(DMM)
Инфракрасный термометр
Щипцы
RJ-45
Терминаторы SСSl-устройств
Кабельная стяжка (и их аналоги на "липучках")
Набор винтов для ремонта ПК
Портативный сетевой анализатор/ноутбук
Запасные коммутационные шнуры
рий
5и
RJ-45
катего
6А (как прямые, так и перекрещенные)
RJ-45 для
обжима кабелей
Запасной кабель питания
Запасные разъемы
Заземляющий браслет для статического электричества
Клещи для снятия изоляции (со встроенным ин
струментом для резки провода)
Разное
Ватные палочки
Мобильный телефон
Телескопический магнитный уловитель
Комплект первой помощи, включающий ибупро
фен и парацетамол
Изоляционная лента
Номера домашних и служебных телефонов со
трудников
Баллон со сжатым воздухом
Список контактов для срочной связи в случае
опасной ситуации
Зеркальце дантиста
•с номерами контрактов на обслуживание.
•
Шесть банок пива (как минимум)
30.7. ЛИТЕРАТУРА
• ASHRAE lnc. ASHRAE 2008 Environmental Guidelinesfor Datacom Equipment. Atlanta,
GA: ASHRAE, lnc., 2008.
Разнообразную полезную информацию и стандарты, связанные с энергоэффек
тивностью, можно найти на веб-сайте Центра экспертизы энергоэффективно
сти в центрах обработки данных
Centers)
по адресу
(Center of Expertise for Energy Efficiency in Data
datacenters. lЫ. gov.
• Telecommunications Jnfrastructure Standardfor Data Centers.
ANSl/ТIA/EIA
942.
Глава 31
Методология, политика
и стратегии
За последние четыре десятилетия роль информационных технологий в бизнесе и по
вседневной жизни резко изменилась. Трудно представить мир без мгновенного удовлет
ворения поиска в Интернете.
В течение большей части этого периода преобладающей философией IТ
менеджмента было повышение стабильности за счет минимизации изменений. Во
многих случаях сотни или тысячи пользователей зависели от одной системы. Если
происходил сбой, оборудование часто должно было быть отправлено на ремонт, или
требовалось время простоя для переустановки программного обеспечения и восста
новления состояния. IТ-команды жили в страхе, что что-то сломается и что они не
смогут это исправить.
Стратегия минимизации изменений имеет нежелательные побочные эффекты.
1Т -отделы часто застревали в прошлом и не соответствовали потребностям бизнеса.
Накапливался "технический долг" в виде систем и приложений, отчаянно нуждающих
ся в обновлении или замене, которых все боялись касаться, опасаясь что-то сломать. IТ
сотрудники стали предметом шуток и наименее популярными людьми повсеместно
-
от залов для заседаний советов директоров до праздничных вечеринок.
К счастью, эти времена позади. Появление облачной инфраструктуры, виртуали
зации, средств автоматизации и широкополосной связи значительно сократило по
требность в одиночных системах. Такие серверы были заменены армиями клонов,
которые управляются как батальоны. В свою очередь, эти технические факторы по
зволили разработать философию обслуживания, известную как
DevOps,
которая по-
1108
ЧастьlV. Эксплуатация
зволяет IТ-организациям управлять изменениями, а не сопротивляться им. Имя
DevOps -
это слово-гибрид, состоящее из слов
(эксплуатация),
-
П-организация
-
-
(разработка) и
operations
это больше, чем группа технических специалистов, которые на
страивают точки доступа к
подразделение
development
названий двух традиционных дисциплин, которые оно объединяет.
Wi-Fi
и компьютеры. Со стратегической точки зрения П
это группа людей и ролей, которые используют технологии для уско
рения работы и достижения целей компании. Никогда не забывайте о золотом правиле
системного администрирования: предприятиям нужно управлять П-деятельностью, а не
наоборот.
В этой главе мы обсудим нетехнические аспекты работы успешной П-организации,
которая использует методологию
DevOps
в качестве своей всеобъемлющей схемы.
Большинство тем и идей, представленных в этой главе , не являются специфическими
для какой-либо конкретной среды. Они применяются в равной степени к системному
администратору с частичной занятостью или к большой группе профессионалов, ра
ботающих полный рабочий день. Подобно свежим овощам, они полезны, независимо
от того, насколько большой обед вы готовите.
31.1.
ВЕЛИКАЯ ЕДИНАЯ ТЕОРИЯ: DEV0PS
Системное администрирование и другие эксплуатационные роли в сфере 1Т тради
ционно отделяются от таких областей, как разработка приложений и управление про
ектами . Теория заключалась в том, что разработчики приложений были специалистами,
которые продвигали продукты с новыми функциями и улучшениями. Тем временем ста
бильная и устойчивая к изменениям эксплуатационная группа обеспечивала непрерыв
ное управление производственной средой. Такое соглашение обычно создает колоссаль
ный внутренний конфликт и в конечном итоге не отвечает потребностям бизнеса и его
клиентов.
ков, владельцев приложений, менеджеров проектов) с IТ-персоналом по эксплуатации
(системными и сетевыми администраторами. контролерами безопасности, персоналом
дата-центра, администраторами баз данных). Эта философия базируется на убеждении,
что совместная работа членов единой команды разрушает барьеры, уменьшает частоту
выяснения отношений и дает лучшие результаты . На рис.
основных концепций
Рис.
DevOps -
31.2 приведены некоторые из
DevOps.
31.2.
Что такое
DevOps
относительно новая концепция в области управления IТ-организациями.
В начале 2000-х гг. произошли изменения в области разработки, которая перешла от ка
скадной схемы циклов выпусков к гибким подходам, которые отличались итеративной
разработкой. Эта схема увеличила скорость, с которой могли быть созданы продукты.
функции и исправления, но развертывание этих улучшений часто останавливалось, по
скольку эксплуатационная сторона не была готова двигаться так быстро, как сторона
разработки. Объединение разработчиков и эксплуатационных групп позволило всем ра
ботать в одном и том же темпе, и появилась методология
DevOps -
это
DevOps.
CLAMS
Принципы методологии DevOps наиболее легко описываются аббревиатурой
CLAMS: Culture (Культура), Lean (Рациональность), Automation (Автоматизация),
Measurement (Измерения) и Sharing (Совместная работа).
Культура
В конечном счете, основной движущей силой любой успешной команды являются
люди, поэтому культурные аспекты
гия
DevOps
DevOps
являются самыми важными. Хотя методоло
имеет собственный набор культурных советов и приемов, главная задача
-
заставить всех работать вместе и сосредоточиться на общей цели.
В методологии
DevOps
все работают вместе, чтобы поддерживать общий биз
нес-драйвер (продукт, цель, сообщество и т.д.) на всех этапах его жизненного цикла.
Достижение этой цели может в конечном итоге потребовать изменений в структуре
отчетности (больше нет изолированных групп по разработке приложений), штатного
расписания и даже должностных обязанностей. В наши дни хорошие системные адми-
1110
ЧастьlV.Эксплуатация
нистраторы иногда пишут код (часто сценарии автоматизации или развертывания), а хо
рошие разработчики приложений регулярно проверяют показатели производительности
инфраструктуры и управляют ими.
Перечислим некоторые типичные особенности культуры
•
И разработчики
рывно
(Dev),
и сотрудники отдела
DevOps.
эксплуатации (Ops)
работают непре
одновременно ("сообщения получают все") и несут ответственность
(24/7),
за всю среду. Это правило обладает прекрасным побочным эффектом, который со
стоит в том, что причины неполадок могут быть устранены в любом месте, где бы
они не возникали. 1
•
Никакое приложение или служба не могут запускаться без автоматического те
стирования и мониторинга как на уровне системы, так и на уровне приложений.
Это правило фиксирует функциональность и создает контракт между
Аналогично
•
и
Dev
Ops должны
Dev
и
Ops.
заранее одобрять все запуски.
Все производственные среды зеркально отражаются в одинаковых средах разра
ботки. Это правило создает основу для тестирования и уменьшает количество про
изводственных сбоев.
•
Команды
команды
Dev
Ops.
регулярно проводят обзоры кода, на которые приглашаются члены
Архитектура и функциональность кода больше не являются функ
циями команды
Dev.
Аналогично команда
Ops
проводит регулярные обзоры ин
фраструктуры, в которых участвуют члены команды
Dev.
Они должны знать и вли
ять на решения, касающиеся базовой инфраструктуры.
•
Команды
Dev
и
Ops
проводят регулярные совместные совещания. В целом встре
чи должны быть сведены к минимуму, но совместные собрания служат полезным
средством коммуникации.
•
Члены команд
Dev
и
Ops
должны находиться в общем чате, посвященном об
суждению как стратегических (архитектура, направление, размер), так и эксплу
атационных вопросов. Этот канал связи часто называют
ChatOps,
и для его под
держки доступны несколько замечательных платформ, в частности
HipChat, Slack,
MatterMost
и
Zulip.
DevOps
Успешная культура
настолько сближает команды
Dev
и
Ops,
что их области
смешиваются, и при этом каждый член команды старается чувствовать себя комфортно.
Оптимальный уровень перекрытия, вероятно, превышает уровень, на котором работают
люди, не разделяющие принципы
DevOps.
Члены команды должны учиться правиль
но реагировать на запросы и учитывать отзывы о своей работе от коллег, которые могут
быть формально обучены другим дисциплинам.
Рациональность
Самый простой способ объяснить рациональность
DevOps -
отметить, что если
вы планируете периодические еженедельные встречи, чтобы обсудить план внедрения
DevOps, значит вы
DevOps - это
уже потерпели неудачу.
взаимодействие и общение в реальном времени между людьми,
процессами и системами. Используйте инструменты реального времени (например,
ChatOps)
для связи, где это возможно, и сосредоточьтесь на решении проблем по оче-
'Примерно первые шесть недель такая модель работы вызывает болезненные ощущения. Затем
они внезапно прекращаются, поверьте нам.
Глава
31. Методология,
политика и стратегии
1111
реди. Всегда спрашивайте, "что мы можем сделать сегодня", чтобы добиться прогресса
по проблеме. Избегайте искушения объять необъятное.
Автоматизация
Автоматизация
-
это наиболее общепризнанный аспект
DevOps.
Два золотых прави-
ла автоматизации гласят:
•
•
если вам нужно выполнить задачу более двух раз, ее следует автоматизировать;
не автоматизируйте то, чего вы не понимаете.
Автоматизация приносит много преимуществ.
•
Она препятствует тому, чтобы сотрудники завязли в рутине. Интеллектуальная
мощь и творческий потенциал персонала могут быть использованы для решения
новых и более сложных задач.
•
•
Она снижает риск человеческих ошибок.
Она выражает инфраструктуру в виде кода, позволяя отслеживать версии и ре
зультаты.
•
Она способствует эволюции, а также снижает риск. Если изменения потерпели
неудачу, легко (ну, теоретически) выполнить автоматический откат.
•
Она облегчает использование виртуальных или облачных ресурсов для обеспече
ния масштабирования и избыточности. Нужно больше ресурсов'? Добавьте немно
го. Нужно меньше ресурсов? Удалите лишнее.
Важную роль в автоматизации играют инструменты. Такие системы, как АпsiЬ\е,
Puppet
и
Chef (см.
интеграции, такие
Salt,
23), - это передний край и центр. Инструменты непрерывной
как Jenkins и ВаmЬоо (см. раздел 26.3), помогают управлять повторя
главу
емыми или запускаемыми задачами. Низкоуровневые задачи инфраструктуры автомати
зируют утилиты для упаковки и выпуска, такие как
Packer и Terraform.
В зависимости от используемой среды вам может понадобиться один из этих инстру
ментов, несколько или даже все. Новые инструменты и усовершенствования разрабаты
ваются быстро, поэтому сосредоточьтесь на поиске инструмента, подходящего для кон
кретной функции или процесса, который вы автоматизируете, и не пытайтесь сначала
выбирать инструмент, а затем выяснять проблемы, которые он решает. Переоценивать
набор инструментов необходимо каждый год или два.
Ваша стратегия автоматизации должна включать по крайней мере следующие элементы.
•
Автоматическая настройка новых машин: это не просто установка операционной
системы. Она также включает в себя все дополнительное программное обеспече
ние и локальную конфигурацию, необходимые для запуска машины. Ваша ор1·а
низация неизбежно будет поддерживать более одного типа конфигурации, поэто
му с самого начала включите в свои планы несколько типов компьютеров.
•
Автоматическое управление конфиrурацией: изменения конфигурации должны в1ю
диться в базу конфигурации и автоматически применяться ко всем машинам од
ного и того же типа. Это правило помогает поддерживать целостность среды.
•
Автоматическое продвижение кода. Распространение новых функций из среды раз
работки в тестовую среду и из тестовой среды в производственную должно быть
автоматизировано. Само тестирование должно быть автоматизировано, с четкими
критериями оценки и продвижения по службе.
ЧастьlV.Эксплvатация
1112
Систематическое исправление и обновление существующих машин. Когда станет
•
ясна проблема с установкой используемой среды, вам нужен стандартизован
ный и простой способ развертывания обновлений для всех затронутых машин.
Поскольку серверы могут быть не включены постоянно (даже если предполага
ется противоположное), при запуске обновления ваша схема внесения измене
ний должна правильно обрабатывать машины, которые находятся в выключен
ном состоянии.
Вы можете проверять обновления во время загрузки или по расписанию; дополни
тельную информацию см. в разделе
4.9.
Измерения
Возможность масштабирования виртуальной или облачной инфраструктуры (см. гла
ву
9)
подтолкнула мир приборов и измерений к новым высотам.
W
Дополнительную информацию о мониторинге см. в главе
Сегодняшний золотой стандарт
-
28.
это сбор субсекундных измерений во всех службах
(бизнес, приложения, базы данных, подсистемы, серверы, сеть и т.д.). Эти усилия поддержи
вают некоторые инструменты
DevOps, такие
как
Graphite, Grafana, ELK (стек Elasticsearch +
+ Logstash + Кibana), а также JUJатформы мониторинга, такие как lcinga и Zenoss.
Однако иметь данные измерений и делать что-то полезное
Опытный отдел
DevOps
-
это две разные вещи.
гарантирует, что метрики из окружающей среды будут доступ
ными и признаваемыми всеми заинтересованными сторонами (как внутри, так и за пре
делами П-организации).
DevOps устанавливает
номинальные цели для каждой метрики
и преследует любые аномалии, чтобы определить их причину.
Совместная работа
В основе успеха методологии
DevOps лежат
совместная работа и совместное раз
витие возможностей. Персонал следует поощрять и стимулировать делиться своей
работой как внутри организации (с помощью презентаций, лекций, материалов, по
казательных выступлений команд, учебных статей в вики-системе и т.д.), так и вне
ее (используя семинары, публикации, конференции). Эти мероприятия усиливают
взрывной эффект методологии за пределами локальной рабочей группы и помогают
каждому учиться и расти.
Системное администрирование в мире
DevOps
Системные администраторы всегда были главными и универсальными действую
щими лицами в мире п; и это остается в силе под более широким зонтиком
DevOps.
Системный администратор контролирует системы и инфраструктуру, как правило, при
нимая на себя основную ответственность за следующие области.
•
•
Создание, настройка, автоматизация и развертывание системной инфраструктуры.
Обеспечение безопасности, исправления и обновления эксJUJуатационной систе
мы и основных подсистем.
Обучение других членов команды на основе передовой практики в области инфра
структуры и безопасности.
•
Мониторинг и поддержка инфраструктуры (физической, виртуальной или облачной)
для обеспечения соответствия требованиям производительности и доступности.
•
•
•
•
•
Реагирование на пользовательские ресурсы или запросы на расширение.
Устранение проблем с системами и инфраструктурой по мере их возникновения.
Планирование будущего расширения систем, инфраструктуры и возможностей.
Пропаганда кооперативных взаимодействий между членами команды.
Управление различными внешними поставщиками (облако, совместное размеще
ние, аварийное восстановление, сохранение данных. подключение, физическое
оборудование, аппаратное обеспечение).
•
•
Управление жизненным циклом компонентов инфраструктуры.
Поддержание экстренного запаса ибупрофена, текилы и/или шоколада для со
вместного использования с другими членами команды в трудные времена.
Это всего лишь подмножество обязанностей, которые лежат на плечах успешного
системного администратора. Он одновременно сержант-инструктор, опекун, спасатель
и звено, которое обеспечивает бесперебойную работу.
Прежде всего, помните, что методология
DevOps основана
на преодолении нормаль
ных рефлексов по защитесвоей территории. Если вы обнаружили, что воюете с другими
членами команды, сделайте шаг назад и помните, что вы наиболее эффективны, если
вас считают героем, который способствует общему успеху.
31.2.
Системы УПРАВЛЕНИЯ БИЛЕТАМИ и ЗАДАЧАМИ
В основе каждой действующей П-группы лежит система управления билетами и за
дачами. Как и для всех элементов методологии
DevOps,
наличие одной системы биле
тов, которая охватывает все IТ-дисциплины, имеет решающее значение. В частности,
запросы на улучшение, управление выпуском и отслеживание ошибок программного
обеспечения должны быть частью одной и той же системы.
Хорошая билетная система помогает сотрудникам избегать двух наиболее распро
страненных ловушек рабочего процесса:
•
задач. которые ускользают от внимания. потому что все думают, что их кто-то ре
шает;
•
ресурсов, которые теряются в результате дублирования усилий, когда несколько
человек или групп несогласованно работают над одной и той же проблемой.
Общие функции билетных систем
Билетная система принимает запросы через различные интерфейсы (наиболее рас
пространенными являются электронная почта и Интернет) и отслеживают их от по
ступления до решения. Менеджеры могут назначать билеты группам или отдельным
сотрудникам. Сотрудники могут запрашивать систему, чтобы увидеть очередь билетов,
ожидающих выполнения. и, возможно, выполнить некоторые из них. Пользователи мо
гут узнавать состояние своих запросов и выяснять, кто над ними работает. Менеджеры
могут извлекать информацию высокого уровня, в частности:
ЧастьlV.Эксплуатация
1114
•
•
•
•
•
количество открытых билетов;
среднее время закрытия билета;
производительность сотрудников;
процент невыполненных билетов;
распределение рабочей нагрузки по времени, требуемому для выполнения.
История запросов, хранящаяся в билетной системе, становится историей проблем,
связанных с вашей П-инфраструктурой, а также решений этих проблем. Если эта исто
рия легко доступна для поиска, она станет неоценимым ресурсом для сотрудников си
стемы.
Выполненные билеты могут быть предоставлены начинающим сотрудникам и ста
жерам, вставлены в систему часто задаваемых вопросов или включены в поисковую
систему для последующего изучения. Новые сотрудники могут извлекать выгоду от по
лучения копий выполненных билетов, поскольку эти билеты включают не только техни
ческую информацию, но и примеры стиля общения с клиентами.
Как и все документы, исторические данные вашей билетной системы потенциально
могут быть использованы против вашей организации в суде. Следуйте рекомендациям
по сохранению документов, установленным юридическим отделом.
Большинство систем отслеживания запросов автоматически подтверждают новые за
просы и присваивают им номер отслеживания, который участники могут использовать
для отслеживания или выяснения состояния своего запроса. В автоматическом ответном
сообщении должно быть четко указано, что это просто подтверждение. За ним должно
незамедлительно следовать сообщение от реального человека, в котором объясняется
план решения проблемы или выполнения запроса.
Владелец билета
Работа может быть совместной, но, по нашему опыту, ответственность меньше под
дается распределению. У каждой задачи должен быть один, четко определенный вла
делец. Этот человек не должен быть руководителем или менеджером, а просто кем-то,
желающим действовать в качестве координатора,
-
кем-то, кто хочет сказать: "Я беру
на себя ответственность за то, чтобы эта задача была решена".
Важным побочным эффектом этого подхода является то, что благодаря ему стано
вится ясным, кто и что реализовал или кто и какие изменения внес. Эта прозрачность
очень важна, если вы хотите понять, почему что-то было сделано определенным обра
зом или почему что-то неожиданно работает по-другому или больше не работает.
Если возникают проблемы, ответственного за задачу не следует приравнивать к коз
лу отпущения. Если ваша организация определяет ответственность как виновность, вы
можете обнаружить, что количество доступных владельцев билетов быстро сократится.
Ваша цель при назначении владельца билета
-
просто устранить двусмысленность в от
ношении того, кто должен решать каждую проблему. Не наказывайте сотрудников за
просьбу о помощи.
С точки зрения клиента, хорошая система назначения
-
та, которая направляет
проблемы человеку, имеющему большой объем знаний и способному быстро и полно
стью решить эти проблемы. Однако с управленческой точки зрения, задания иногда
должны быть сложными, чтобы сотрудники продолжали расти и учиться в процессе вы
полнения своей работы. Ваша задача состоит в поиске такого баланса между сильны-
Глава
31.
Методология, политика и стратегии
1115
ми сторонами сотрудников и необходимостью решать сложные задачи, чтобы при этом
были довольны и клиенты, и сотрудники.
Большие задачи могут быть любыми, вплоть до полномасштабных проектов разра
ботки программного обеспечения. Эти задачи могут потребовать использования фор
мальных инструментов упрамения проектами и разработки программного обеспечения.
Мы не описываем эти инструменты здесь; тем не менее они важны и их не следует упу
скать из виду.
Иногда системные администраторы знают, что нужно выполнить определенную за
дачу, но они этого не делают, потому что задача им неприятна. Системный администра
тор, который укажет на эту забытую, неназначенную или непопулярную задачу, скорее
всего, и получит эту задачу как свое задание. Эта ситуация создает конфликт интере
сов, потому что она побуЖДает системных администраторов сохранять молчание в таких
ситуациях. Не допускайте, чтобы это происходило в вашей организации; дайте вашим
системным администраторам возможность прояснить проблемы. Вы можете разрешить
им открывать билеты, не назначая мадельца или не связывая себя с проблемой, или мо
жете создать псевдоним адреса электронной почты, по которому могут быть адресованы
проблемы.
Восприятие пользователями билетных систем
Получение быстрого ответа от реального человека ямяется критическим фактором,
определяющим удометворенность клиентов, даже если персональный ответ содержит
не больше информации, чем автоматизированный. В большинстве случаев гораздо важ
нее сообщить заявителю, что билет был просмотрен реальным человеком, чем устранить
проблему немедпенно. Пользователи понимают, что администраторы получают много
запросов, и они готовы ждать вашего внимания настолько долго, насколько они сочтут
это справедпивым и разумным. Но они не хотят, чтобы их игнорировали.
Механизм, посредством которого пользователи отпрамяют билеты, мияет на их вос
приятие системы. Убедитесь, что вы понимаете культуру своей организации и предпочте
ния пользователей. Они хотят веб-интерфейс? Пользовательское приложение? Псевдоним
адреса электронной почты? Может быть, они хотят звонить только по телефону!
Также важно, чтобы администраторы нашли время убедиться, что они правильно по
нимают запросы пользователей. Этот момент кажется очевидным, но вспомните послед
ние пять раз, когда вы отпрамяли сообщение по электронной почте в службу поддерж
ки клиентов или технической поддержки. Думаем, что было по крайней мере несколько
случаев, когда ответ, казалось, не имел никакого отношения к вашему вопросу,
-
не
потому, что эти компании были особенно некомпетентны, а потому, что подробно раз
бирать проблемы, указанные в билете, сложнее, чем кажется.
Как только вы прочитаете достаточно большую часть билета, чтобы понять, о чем
спрашивает клиент, остальная часть билета покажется вам пустыми словами. Боритесь
с этим! Клиенты злятся, когда узнают, что билет дошел до адресата, но запрос был не
верно истолкован и его необходимо повторно отправить или перерегистрировать.
Возникает замкнутый круг.
Билеты часто расплывчаты или неточны, потому что у заявителя нет технического
опыта, необходимого дпя описания проблемы, как это бьшо бы с системным админи
стратором. Однако это не мешает пользователям делать собственные догадки о причи
нах неполадок. Иногда эти догадки совершенно правильны, а иногда вы должны снача
ла расшифровать билет, чтобы выяснить, что думает пользователь о проблеме, а затем
проследить за ходом мысли пользователя, чтобы понять основную проблему.
ЧастьlV.Эксплvатация
1116
Типовые билетные системы
В следующих таблицах приведены характеристики нескольких известных билетных
систем. В табл.
указаны системы с открытым исходным кодом, а в табл.
31.1
31.2 -
ком
мерческие системы.
В табл.
31.2
показаны некоторые коммерческие альтернативы для управления запро
сами. Поскольку веб-сайты для коммерческих предложений в основном содержат мар
кетинговую информацию, такие детали, как язык реализации и интерфейс, не указаны.
Таблица
31 .1.
Билетные системы с открытым исходным кодом
Ввод•
Язык
База данных6
Веб-сайт
Choco Latte
w
РНР
МР
github.com/gnuedcl/dcl
РНР
м
mantisЬt.org
Perl
DMOP
otrs.org
RT: Request Tracker
WE
WE
WE
WE
WE
Perl
м
bestpractical.com
РНР
м
osticket.com
Perl
МОР
bugzilla.org
Имя
DouЫe
Mantis
OTRS
OSTicket
Bugzilla
"Типы ввода:
0 Баэа
W-
веб, Е
-
электронная почта.
данных: О - DB2, М - MySQL, О - Oracle, Р - PostgreSQL.
Таблица З 1.2. Коммерческие билетные системы
Масштаб
Веб-сайт
Огромный
infracorp.com/solutions
НЕАТ
Средний
ticomix.com
Jira
Любой
atlassian.com
Remedy (теперь ВМС)
Огромный
remedy.com
Имя
ЕМС
lonix (lnfra)
ServiceDesk
Огромный
ca.com/us/service-desk.aspx
ServiceNow
Любой
servicenow.com
Track-lt!
Средний
trackit.com
Некоторые коммерческие предложения настолько сложны, что для их эксплуатации,
настройки и поддержания работоспособности нужны один или два специально назна
ченных сотрудника. Другие (такие как
Jira
и
ServiceNow) доступны
в виде "программно
го обеспечения как услуги".
Диспетчеризация билетов
Во многих билетных системах, одна из которых широко известна, нерешенной оста
лась такая проблема: несколько сотрудников не могут эффективно разделять свое вни
мание между задачами, над которыми они работают прямо сейчас, и очередными за
просами, особенно если запросы поступают по электронной почте в личный почтовый
ящик. Мы экспериментировали с двумя решениями этой проблемы.
Наша первая попытка заключалась в том, чтобы назначить половину группы си
стемных администраторов дневной смены на обслуживание запросов. Во время смены
дежурный должен был попытаться ответить на как можно больше входящих запросов.
Недостаток этого подхода заключался в том, что не все системные администраторы
Глава
31.
1117
Методология, политика и стратегии
умели правильно отвечать на все вопросы и исправлять все проблемы. Иногда ответы
были неуместными, поскольку дежурный был новым и не был знаком с клиентами, их
средой или конкретными контрактами на поддержку. В результате вышестоящие со
трудники вынуждены были следить за ситуацией и поэтому не могли сосредоточиться
на собственной работе. В итоге качество обслуживания снизилось, и ничего не полу
чилось.
После этого опыта мы создали роль диспетчера, на которую ежемесячно пооче
редно назначается кто-то из группы старших администраторов. Диспетчер проверяет
билетную систему в поисках новых записей и назначает задания конкретным сотруд
никам. При необходимости диспетчер связывается с пользователями для получения
любой дополнительной информации, необходимой для установления приоритетности
запросов. Диспетчер использует самодельную базу данных о навыках работы с персо
налом, чтобы решить, кто в команде поддержки имеет соответствующие навыки и вре
мя для выполнения данного билета. Диспетчер также гарантирует своевременное вы
полнение запросов.
31.3.
ПОДДЕРЖКА ЛОКАЛЬНОЙ ДОКУМЕНТАЦИИ
Так же, как большинство людей понимают пользу для здоровья от физических
упражнений и свежих овощей, каждый ценит хорошую документацию, но имеет туман
ное представление о том, насколько это важно. К сожалению, это не обязательно оз
начает, что некто должен писать или обновлять документацию просто так. Почему мы
должны об этом заботиться, правда?
•
Документация уменьшает вероятность единственной точки отказа. Замечательно
иметь инструменты, которые быстро развертывают рабочие станции, и распро
странять исправления с помощью одной команды, но эти инструменты почти бес
полезны, если документации для них не существует, а эксперт находится в отпуске
или уволился.
•
Документация облегчает воспроизводимость. Если правила и процедуры не хра
нятся в локальной памяти, они вряд ли будут последовательно соблюдаться. Если
администраторы не найдут информацию о том, как что-то сделать, они и не смо
гут это сделать.
•
Документация экономит время. Не похоже, что вы экономите время, когда пи
шете ее, но, потратив несколько дней на повторное решение проблемы, которая
раньше уже была решена, но решение было забыто, большинство администрато
ров убедятся в пользе документации.
•
Последнее и самое главное: документация улучшает понятность системы и по
зволяет производить последующие модификации согласованным образом. Когда
изменения производятся
на основе только частичного понимания,
они часто
не вполне соответствуют архитектуре. Со временем энтропия увеличивается,
и даже администраторы, которые работают в системе, видят в ней беспорядочную
коллекцию приемов. Конечным результатом часто является желание отказаться
от всего и начать с нуля.
Локальная документация должна храниться в четко определенном месте, таком как
внутренняя вики-система или сторонняя служба, такая как
Google Drive.
После того
как вы убедите своих администраторов документировать конфигурации и методы адми
нистрирования, важно также защитить эту документацию. Злоумышленник может на-
ЧастьlV.Эксплуатация
1118
нести большой урон, нарушив документацию вашей организации. Убедитесь, что люди,
которые нуждаются в документации, могут найти ее и прочитать (сделайте ее доступной
для поиска), и каждый, кто поддерживает документацию, может ее изменить. В то же
время соблюдайте баланс между доступностью и необходимостью защиты.
Инфраструктура как код
Другая важная форма документации называется "инфраструктура как код". Она мо
жет принимать различные формы, но чаще всего рассматривается в виде определений
конфигурации (таких как модули
Puppets
или сценарии AnsiЫe), которые затем могут
храниться и отслеживаться в системе контроля версий, такой как
Git.
Система и ее из
менения хорошо документированы в файлах конфигурации, и среда может быть по
строена и сопоставлена со стандартом на регулярной основе. Такой подход гарантиру
ет, что документация и окружающая среда всегда соответствуют стандарту и актуальны,
тем самым решая наиболее распространенную проблему традиционной документации.
Дополнительную информацию см. в главе
23.
Стандарты документации
Если вы должны документировать элементы вручную, наш опыт показывает, что са
мый простой и эффективный способ ведения документации
-
стандартизация на осно
ве коротких и легких документах. Вместо написания руководства по управлению систе
мой для вашей организации напишите много одностраничных документов, каждый из
которых охватывает одну тему.
Начните с большой картины, а затем разбивайте ее на куски, содержащие дополнитель
ную информацию. Если вам нужно углубиться в подробности, напишите дополнительный
документ на одну страницу, в котором основное внимание будет уделено особенно сложным
шагам.
Такой подход имеет ряд преимуществ.
•
Возможно, высшее руководство заинтересовано только в общей настройке вашей
среды. Это все, что нужно, чтобы отвечать на вопросы сверху или вести управлен
ческую дискуссию. Не раскрывайте слишком много деталей, иначе вы просто под
толкнете своего босса вмешаться в них.
•
•
То же самое справедливо для клиентов.
Новый сотрудник или кто-то, кто принимает новые обязанности в вашей органи
зации, нуждается в обзоре инфраструктуры, чтобы стать продуктивным. Нехорошо
хоронить таких людей под грудой информации.
•
•
Эффективнее использовать нужный документ, чем просматривать большой.
Вы можете индексировать страницы; чтобы их было легко найти. Чем меньше
времени администраторам приходится тратить на поиск информации, тем лучше.
•
Легче поддерживать текущую документацию, когда вы можете это сделать, обно
вив только одну страницу.
Этот последний момент особенно важен. Поддержание документации в актуальном
состоянии является огромной проблемой; когда времени мало, документацией жертву
ют в первую очередь. Мы обнаружили, что несколько конкретных подходов позволяют
облегчить документирование.
Глава
31. Методология,
1119
политика и стратегии
Во-первых, укажите, что документация будет краткой, актуальной и неотшлифо
ванной. Переходите к самой сути. Информация должна быть эффективной. Ничто так
не отталкивает от документирования, как перспектива написания диссертации по те
ории проектирования. Попросите слишком много документации, и вы, возможно, не
получите ничего. Рассмотрите возможность разработки простой формы или шабло
на для ваших системных администраторов. Стандартная структура помогает избежать
"воды" и ориентирует системных администраторов на изложение конкретной информа
ции, а не общих рассуждений.
Во-вторых, внедряйте документацию в процессы. Комментарии в файлах конфигура
ции являются одними из лучших документов для всех. Они всегда уместны там, где они
вам нужны, и их сохранение практически не требует времени. Большинство стандарт
ных файлов конфигурации позволяют оставлять комментарии, и даже те, которые не
особого хорошо прокомментированы, часто могут служить источником дополнительной
информации.
Локально созданные инструменты могут требовать документацию как часть стан
дартной информации о конфигурации. Например, инструмент, который настраивает но
вый компьютер, может потребовать информацию о владельце компьютера, его местопо
ложении, состоянии поддержки и финансовые данные, даже если эти факты не имеют
прямого отношения к конфигурации программного обеспечения устройства.
Документация не должна создавать избыточности информации. Например, если вы
поддерживаете общий список систем для всех компьютеров, не должно быть другого
места, где эта информация обновляется вручную. Делать обновления в нескольких ме
стах
-
это не только пустая трата времени, но и высокая вероятность того, что со вре
менем проявятся несоответствия. Если эта информация требуется в друтих контекстах
и файлах конфигурации, напишите сценарий, который получает ее от мастера конфигу
рации или обновляет. Если вы не можете полностью устранить избыточность, по край
ней мере должно быть понятно, какой источник является авторитетным. Кроме того,
напишите инструменты, чтобы уловить несоответствия, возможно, регулярно запуская
их через планировщик
m
cron.
Дополнительную информацию о планировщике
cron см.
в разделе
4.9.
Появление таких инструментов, как вики, блоги и друтие простые системы управ
ления знаниями, значительно облегчило отслеживание П-документации. Создайте хра
нилище, где все ваши документы могут быть найдены и обновлены. Однако не забудьте
сохранить его организованность. Одна страница вики-системы с
200
дочерними стра
ницами в одном списке слишком громоздкая и сложная в использовании. Не забудьте
включить функцию поиска, чтобы получить максимальную отдачу от вашей системы.
31.4.
РАЗДЕЛЕНИЕ ОКРУЖАЮЩЕЙ СРЕДЫ
Организации, которые создают и разворачивают собственное программное обеспе
чение, нуждаются в отдельных средах разработки, тестирования и производства, чтобы
выпуски можно было передавать в общее пользование с помощью структурированно
го процесса. 2 Отдельные, но идентичные; убедитесь, что при обновлении систем раз
работки изменения распространяются также на тестовые и производственные среды.
Разумеется, сами настройки конфигурации должны подчиняться тому же типу структу-
2
80
многих случаях это утверждение относится также к организациям, в которых запущено готовое
ERP или финансовые системы.
комплексное программное обеспечение, такое как
ЧастьlV.Эксплvатация
1120
рированного управления выпуском, что и код. "Изменения конфигурации" включают
все: от исправления операционных систем до обновлений приложений и администра
тивных изменений.
Исторически сложилось так, что стандартная практика защищает производственную
среду путем разделения ролей на протяжении всего процесса продвижения. Например,
разработчики, обладающие правами администратора в среде разработки,
люди,
у которых есть привилегии
администратора и
продвижения
-
это не те
в других средах.
Существовало опасение, что недовольный разработчик, имеющий разрешения на продви
жение кода, мог бы вставлять вредоносный код на стадии разработки, а затем продвигать
его в производственную среду. Если одобрение дистрибутива и продвижение осуществля
ют разные люди, им необходимо будет сговориться или одновременно сделать ошибки,
чтобы проблемы могли попасть в производственные системы.
К сожалению, ожидаемые выгоды от таких драконовских мер редко достигаются.
У людей, продвигающих код, часто нет навыков или времени для пересмотра изменений
кода на уровне, который фактически выявил бы злонамеренный фрагмент. Вместо того
чтобы помогать, система создает ложное чувство защиты, вводит ненужные контрольно
пропускные пункты и тратит ресурсы.
В эпоху методологии
DevOps
эта проблема решается по-другому. Вместо отдельных
ролей предпочтительным подходом является отслеживание всех изменений "как кода"
в репозитории (например,
Git),
который имеет неизменяемый контрольный журнал.
Любые нежелательные изменения можно проследить вплоть до конкретного человека,
который их представил, поэтому строгое разделение ролей не нужно. Поскольку изме
нения конфигурации применяются автоматическим способом в каждой среде, идентич
ные изменения могут быть выполнены в более низких средах (например, разработки или
тестирования) до того, как они будут продвинуты в производство, чтобы гарантировать,
что непредвиденные последствия не проявятся. Если проблемы обнаружены, возвраще
ние в исходное состояние происходит настолько же просто, как выявление проблемной
фиксации и ее временный обход.
В идеальном мире ни разработчики, ни сотрудники отдела эксплуатации не должны
иметь административных привилегий в производственной среде. Вместо этого все изме
нения должны выполняться с помощью автоматизированного отслеживаемого процес
са, который имеет собственные привилегии. Несмотря на то что это достойная и весьма
желанная цель, наш опыт заключается в том, что для большинства организаций это еще
не реально. Работайте над этой утопической идеей, но не попадитесь в ловушку.
31.5.
ВоссТАНОВЛЕНИЕ ПОСЛЕ АВАРИЙ
Работа организации зависит от функционирования информационной среды.
Системный администратор отвечает не только за повседневные операции, но и за нали
чие плана действий на случай возникновения различных экстренных ситуаций, по край
ней мере тех, которые можно предвидеть. Подготовка к таким масштабным проблемам
влияет как на общий план работы, так и на способ выполнения повседневных операций.
В этом разделе мы рассмотрим разные виды аварий, данные, которые необходимо вос
становить, а также важные элементы планов по возобновлению работы.
Оценка рисков
Прежде чем завершить разработку плана восстановления после аварий, целесообраз
но оценить степень риска, чтобы понять, какими активами вы располагаете, каким ри-
Глава
31.
Методология, политика и стратегии
1121
скам подвергаетесь и как можно смягчить последствия аварии. Специальный документ
NIST 800-30 детализирует обширный
nist. gov.
процесс оценки степени риска. Вы можете загру
зить его с сайта
В ходе оценки степени риска необходимо составить список потенциальных угроз,
от которых вы хотите защититься. Угрозы не являются одинаковыми, и вам, возможно,
понадобится несколько различных планов, чтобы покрыть полный спектр возможно
стей. В качестве примера перечислим угрозы общего характера.
•
Злонамеренные пользователи, как внутренние, так и внешние 3
•
Наводнения
•
Пожары
•
Землетрясения
•
Ураганы и торнадо
•
Магнитные бури и броски электропитания
•
Перебои в электропитании, короткие и долгосрочные
•
Чрезвычайно высокая температура или отказ охлаждающего оборудования
•
Сбой в работе телекоммуникационного оборудования провайдера или облачной
системы
•
Отказы аппаратных средств ("зависшие" серверы, "сгоревшие" жесткие диски)
Случайные ошибки пользователей (удаленные или поврежденные файлы и базы
данных, потерянная информация о конфигурации, забытые пароли и т.д.).
Для каждой потенциальной угрозы рассмотрите и запишите все возможные послед
ствия.
Как только вы поймете угрозу, расставьте приоритеты служб в пределах своей инфор
мационной среды. Составьте таблицу, в которой перечисляются службы и их приорите
ты. Например, компания, премагающая "программное обеспечение как службу", может
оценивать свой внешний веб-сайт как службу первостепенной важности, в то время как
офис с простым информационным внешним веб-сайтом может не волноваться о том,
что сайт не работает во время стихийных бедствий.
Планирование мероприятий по восстановлению
Все больше организаций проектируют свои критические системы так, чтобы мож
но было автоматически переключаться на резервные серверы в случае возникновения
проблем. Это прекрасная идея, если простои в работе служб не допускаются. Тем не
менее не становитесь жертвой веры в то, что зеркалирование ваших данных отменяет
необходимость в их резервном копировании. Даже если ваши центры обработки дан-
1
Причиной около половины нарушений в области безопасности являются действия внутренних
пользователей. В большинстве организаций неправильные действия внутренних пользователей
остаются наиболее вероятными причинами сбоев.
1122
ЧастьlV.Эксплvатация
ных расположены достаточно далеко, вы вполне можете потерять в них все данные. 4
J-le
забудьте включить резервное копирование данных в свой план по борьбе с аварий
ными ситуациями.
m Облачные вычисления описаны в главе 9.
Облачные вычисления
-
еще один ресурс мя борьбы со стихийными бедствиями,
который становится все более популярным. Благодаря таким службам, как ЕС2 компа
нии
Amazon,
вы можете настроить удаленный сайт и запустить его за несколько минут
без необходимости платить за специализированные аппаратные средства. Вы платите
только за то, что используете.
В план по восстановлению после аварийных ситуаций должны быть включены пере
численные ниже разделы (составлено на основе стандарта аварийного восстановления
NIST 800-34).
•
•
Введение
-
цель и предмет документа.
Понятие операций
-
описание системы, цели восстановления, классификация ин
формации, порядок преемственности, обязанности.
•
Уведомление и активация
-
процедуры уведомления, процедуры оценки поврежде
ний, активация плана.
•
Восстановление
-
последовательность событий и процедур, требуемых для восста
новления работоспособности потерянных систем.
•
Возврат к нормальному функционированию
-
параллельная обработка, тестирова
ние восстановленной системы, возвращение к нормальному функционированию,
отмена введенного аварийного плана.
Мы привыкли использовать сеть для общения и доступа к документам. Однако
эти средства могут стать недоступными или оказаться под угрозой после инцидента.
Поэтому сохраняйте локально все соответствующие контакты и процедуры. Вы должны
знать, где можно получить свежие резервные копии своих данных и как использовать их
независимо от сетевых данных.
Во всех сценариях восстановления вам понадобится доступ и к автономным, и к ин
терактивным копиям важных данных. Интерактивные копии по возможности должны
быть сохранены на отдельном компьютере, на котором есть богатый набор инструмен
тов, настроенная ключевая среда мя системного администрирования, запущен соб
ственный сервер имен, полный локальный файл
/etc/hosts,
подключение к принтеру
и нет никаких зависимостей от ресурсов, расположенных на других компьютерах.
Ниже приведен список полезных данных мя хранения в среде восстановления при
аварийных ситуациях.
•
Схема процедуры восстановления: кому звонить, что сказать
•
•
•
•
Номера телефонов сервисного центра и клиентов
Набор резервных копий данных и график их создания
•
Карты сети
Ключевые местные номера телефонов: полиция, пожарные, сотрудники, начальник
Информация мя входа в облачный сервис
•злонамеренные хакеры и программы могут легко вывести из строя организацию, которая игнори
рует необходимость создания автономных резервных копий, предназначенных только для чтения.
Глава
•
31. методология,
1123
политика и стратегии
Регистрационные номера программного обеспечения, лицензионные данные
и пароли
•
Копии инсталляционных пакетов программного обеспечения (могут храниться
в формате
•
•
•
•
ISO)
Копии инструкций по эксплуатации ваших систем
Контактная информация поставщика оборудования
Административные пароли
Данные о конфиrурациях аппаратного и программного обеспечения: версии опе
рационных систем, пакеты обновлений, таблицы разделов дисков и т.п.
•
Инструкции о порядке запуска систем, работоспособность которых должна быть
восстановлена в первую очередь
Подбор персонала на случай аварии
Нужно заблаговременно решить вопрос о том, кто будет справляться с ситуацией
в случае, если произойдет авария. Следует составить план действий и записать номера
телефонов тех, кому надлежит звонить в такой ситуации. Мы пользуемся небольшой ла
минированной карточкой, на которой мелким шрифтом напечатаны все важные имена
и номера телефонов: она очень удобна, потому что легко помещается в бумажник.
Лучше всего назначать ответственным одного из системных администраторов, а не
IТ-руководителя (обычно он плохо подходит для этой роли).
Ответственным в случае аварии должен быть кто-то, кто пользуется авторитетом
и не боится принимать трудные решения при наличии минимального количества ин
формации (наподобие решения отключить от сети весь отдел целиком). Способность
принимать такие решения, уведомлять о них понятным образом и фактически руково
дить персоналом во время кризиса, пожалуй, важнее теоретических знаний о системном
и сетевом управлении.
При составлении плана аварийных мероприятий обычно предполагается, что адми
нистративный персонал будет на месте, когда произойдет авария, и сумеет справиться
с ситуацией. К сожалению, люди иногда болеют, уходят на курсы повышения квали
фикации, уезжают в отпуск, а в тяжелые времена вообще могут даже становиться край
не недружелюбными. Поэтому стоит заранее продумать, где можно будет быстро найти
дополнительную помощь. (Если система не слишком устойчива, а персонал неопытен,
то недостаточное количество администраторов уже само по себе является аварийной си
туацией.)
Одним из решений может быть договоренность с какой-нибудь местной консульта
ционной компанией или университетом, где всегда есть талантливые и готовые помочь
администраторы. Конечно, если у них когда-нибудь возникнут проблемы, тогда вы тоже
должны будете оказать им необходимую помощь. Но самое главное
-
это не работать
на пределе: наймите достаточное количество администраторов и не требуйте, чтобы они
работали по
12 часов в сутки.
Проблемы с безопасностью
Об обеспечении безопасности системы подробно рассказывалось в главе
27.
Однако здесь тоже стоит коснуться этой темы, потому что вопросы безопасности вли-
1124
ЧастьlV.Эксплvатация
яют на многие из выполняемых системным администратором задач. Ни один аспект
стратегии управления организации не должен разрабатываться без учета безопасности.
В главе
27
по большей части рассказывалось о способах предотвращения проблем
с безопасностью. Однако продумывание способов восстановления системы после про
исшедшего из-за связанных с безопасностью проблем инцидента является не менее
важным.
Взлом веб-сайта относится к числу наиболее серьезных нарушений системы безопас
ности. Для системного администратора, работающего в компании, которая занимается
предоставлением услуг веб-хостинга, такой инцидент может превратиться в настоящую
катастрофу, особенно если речь идет о сайтах, использующих данные о пластиковых
картах пользователей. При этом будет поступать лавина телефонных звонков от клиен
тов, средств массовой информации, УIР-клиентов компании, которые только что ус
лышали о произошедшем взломе в новостях. Кто будет отвечать на эти звонки? Что он
должен говорить'? Кто будет главным'? Кто что будет делать? Тем системным админи
страторам, которые работают в очень популярных компаниях, обязательно следует про
думать такой сценарий, подготовить подходящие ответы и план действий и, возможно,
даже провести тренировочную проверку, чтобы отработать детали.
Для сайтов, которые имеют дело с данными о платежных картах, всегда предусма
триваются правила поведения в случае взлома с целью кражи информации. Поэтому
системный администратор обязательно должен привлечь к планированию мероприятий
на случай проблем с безопасностью сотрудников юридического отдела своей организа
ции и позаботиться о наличии номеров телефонов и имен людей, которым следует зво
нить во время кризиса.
Когда в новостях объявляют, что такой-то веб-сайт был атакован хакерами, возника
ет ситуация, напоминающая аварию на дороге: все бросаются посмотреть, что же про
изошло, и в результате интернет-трафик сильно возрастает, нередко настолько сильно,
что все, что администраторам наконец-то с таким трудом удалось восстановить, сно
ва может оказаться под угрозой. Поэтому, если веб-сайт не рассчитан на 25-процент
ное (или более высокое) пиковое увеличение трафика, следует позаботиться о наличии
устройств выравнивания нагрузки, которые будут просто направлять превышающие
норму запросы на специальный сервер, а тот будет возвращать страницу со следующим
сообщением: "Извините, сервер слишком загружен и поэтому в данный момент немо
жет обработать ваш запрос". Разумеется, хорошо продуманный заранее план по возоб
новлению работы, включающий автоматическое масштабирование в облаке (см. главу
9),
позволит избежать такой ситуации.
Разработайте подробное руководство по действиям в чрезвычайных ситуациях, чтобы
исключить непродуктивную работу при устранении проблем с безопасностью. Более под
робно об этом шла речь в разделе
31.6.
27 .12.
ИНСТРУКЦИИ И ПРОЦЕДУРЫ
Исчерпывающие инструкции и процедуры, касающиеся информационных техноло
гий, служат основой для работы современных организаций. Инструкции устанавливают
нормы для пользователей и администраторов и способствуют согласованной работе всех
вовлеченных в нее сотрудников. Все чаще инструкции требуют подтверждения в форме
подписи или другого доказательства, что пользователь согласился их соблюдать. Хотя
это может показаться чрезмерным формализмом, такое подтверждение представляет со
бой действительно отличный способ защитить администраторов.
Глава
31. методология, политика
1125
и стратегии
Хорошим основанием для разработки инструкций является стандарт
27001:2013.
ISO/IEC
Он сочетает общую стратегию в области информационных технологий с дру
гими важными элементами, такими как информационная безопасность и роль отдела
кадров. В следующих разделах мы обсудим стандарт
JSO/IEC 27001:2013
и выдвинем
на первый план некоторые из его самых важных и полезных элементов.
Различие между инструкциями и процедурами
Инструкции и процедуры
-
это разные категории, но их часто путают, и иногда они
даже используются как синонимы, что вызывает путаницу. Для того чтобы правильно
понимать их сущность, рассмотрим следующие аспекты.
•
Инструкции
-
это документы, устанавливающие требования или правила.
Требования обычно определяются на относительно высоком уровне. Примером
инструкции можно считать требование, чтобы инкрементные резервные копии
создавались ежедневно, а полные резервные копировании
•
Процедуры
-
-
каждую неделю.
это документы, описывающие процесс выполнения требований
или правил. Например, процедура, связанная с описанной выше инструкцией,
могла бы быть сформулирована примерно так: "Инкрементные резервные копии
выполняются с помощью программы
Backup
Ехес, инсталлированной на сервере
backupsOl"."
Это различие важно, потому что инструкции не должны изменяться очень часто.
Они могут пересматриваться ежегодно и, возможно, в них поменяется один или два раз
дела. С другой стороны, процедуры уточняются непрерывно, поскольку постоянно из
меняется архитектура, системы и конфигурации.
Некоторые стратегические решения диктуются программным обеспечением, которое
вы используете, или инструкциями внешних групп, например интернет-провайдерами.
Если необходимо защитить конфиденциальные данные пользователей, некоторые ин
струкции составляются в категоричной форме. Мы называем эти инструкции "не под
лежащими обсуждению".
В частности, мы полагаем, что IР-адресами, именами хостов, идентификаторами
пользователей, идентификаторами групп и именами пользователей необходимо управ
лять централизованно. Некоторые организации (транснациональные корпорации, на
пример) являются слишком большими, чтобы осуществить эту политику, но если вы мо
жете реализовать ее, то централизованное управление сделает все намного проще. Мы
знаем компанию, которая реализует политику централизованного управления для
сяч пользователей и
100 тысяч
35 ты
компьютеров. Таким образом, порог, после которого ор
ганизация становится слишком крупной для централизованного управления, должен
быть довольно высоким.
Другие важные проблемы имеют более широкую сферу влияния, чем ваша локальная
группа системных администраторов.
•
•
•
•
•
•
Борьба со взломами системы безопасности
Управление экспортом файловой системы
Критерии выбора паролей
Удаление регистрационных записей
Материал, защищенный авторским правом (например, МР3 и
Программное пиратство
DVD)
1126
ЧастьlV.Эксплvатация
Лучшие практики применения инструкций
Инструкции могут быть ограничены несколькими рамками, но все они охватывают
примерно одинаковую область. Ниже перечислены примеры инструкций, которые, как
правило, включаются в стратегический набор инструкций, относящихся к информаци
онным технологиям.
•
Информационная политика безопасности
•
Соглашения о возможности подключения посторонних организаций
•
•
Информационная система классификации данных
•
Политика безопасности сотрудников
•
•
Физическая политика безопасности
Политика управления активами
Политика управления доступом
•
Стандарты безопасности для разработки и обслуживания новых систем
•
Политика управления инцидентами
•
Управление непрерывностью бизнеса (аварийное восстановление)
•
Стандарты хранения данных
•
•
Защита конфиденциальности
Политика соответствия установленным требованиям закона
Процедуры
Процедуры в форме контрольных списков или рецептов могут формализовать суще
ствующую практику. Они полезны и для новых системных администраторов, и для опыт
ных людей. Еще лучше процедуры, которые содержат выполняемые сценарии или отра
жаются в инструментах упрамения конфигурацией, таких как AnsiЬ\e,
Puppet
или
Chef.
долгосрочной перспективе большинство процедур должны быть автоматизированы.
У стандартных процедур есть несколько преимуществ.
•
Рутинные операции всегда выполняются единообразно
•
•
По рецепту системный администратор работает быстрее
•
•
Контрольные списки уменьшают вероятностьошибок или забытых операций
Изменения самодокументируются
Письменные процедуры обеспечивают измеримый стандарт корректности
Вот часть общих задач, для которых можно сформулировать процедуры.
•
•
Подключение компьютера
Добамение пользователя
•
•
Конфигурирование локального компьютера
•
Защита нового компьютера
•
•
Удаление старого компьютера
Настройка процедур резервного копирования для нового компьютера
Повторный запуск сложных компонентов программного обеспечения
В
Глава
31. Методология,
политика и стратегии
•
Перезагрузка веб-серверов, которые не отвечают на запросы или "зависли"
•
•
•
•
•
•
•
Обновление операционной системы
1127
Установка исправлений
Установка пакета прикладных программ
Обновление наиболее важных программ
Резервное копирование и восстановление файлов
Удаление старых резервных копий
Аварийный останов системы (всех компьютеров; кроме самых важных; и т.д.)
Многие вопросы находятся в непосредственной связи политик и процедур.
Например:
•
•
Кто из сотрудников может иметь учетную запись в вашей сети?
Что происходит, когда они увольняются'?
Такие вопросы следует строго регламентировать, чтобы не стать жертвой известной
уловки четырехлетних детей: "Мама не разрешила, надо спросить у папы!"
31.7. (ОГЛАШЕНИЯ
О КАЧЕСТВЕ ОКАЗЫВАЕМЫХ УСЛУГ
Для того чтобы отдел информационных технологий успешно справлялся со своими
обязанностями, стараясь угождать пользователям и удовлетворяя потребности предпри
ятия, все детали необходимо согласовать и зафиксировать в договоре о качестве оказыва
емых услуг. Хороший договор предусматривает соответствующий уровень обслуживания
и является документом, на который можно ссылаться в проблемных ситуациях. (Однако
помните, что отдел информационных технологий помогает, а не мешает пользователям!)
Когда что-то выходит из строя, пользователи хотят знать, когда это будет исправле
но. Их не интересует, какой жесткий диск или генератор сломались и почему; оставьте
эту информацию для своих административных отчетов.
С точки зрения пользователя, никакие новости не являются хорошими. Система
или работает, или нет, и в последнем случае не имеет значения, почему. Максимальное
удовольствие наши клиенты получают, если они даже не замечают, что мы сушествуем!
Грустно, но факт.
Соглашение о качестве оказываемых услуг помогает помирить конечных пользовате
лей и технический персонал. Хорошо написанное соглашение учитывает каждую проб
лему, упомянутую в следующих разделах.
Спектр услуг и их описание
В договоре о качестве оказываемых услуг описывается то, что организация может
ожидать от отдела информационных технологий. Он должен быть написан в терминах,
которые могут быть поняты нетехническими сотрудниками. Перечислим в качестве
примера некоторые из этих служб.
•
•
•
•
Электронная почта
Чаты
Интернет и неб-доступ
Файловые серверы
ЧастьlV.Эксплvатация
1128
•
•
Бизнес-приложения
Аутентификация
В договоре также должны быть определены стандарты, которых будет придерживать
ся отдел информационных технологий. Например, раздел о доступности услуг должен
определять часы работы, согласованные окна обслуживания и время, в течение которо
го будет доступен технический персонал, чтобы обеспечить интерактивную поддержку.
Одна организация могла бы решить, что регулярная поддержка должна быть доступна
с
8:00 до 18:00
в будние дни, а чрезвычайная поддержка
-
круглосуточно. Другая орга
низация могла бы решить, что нуждается в стандартной интерактивной поддержке, до
ступной всегда.
Представим список проблем, которые следует рассмотреть, документируя ваши стандарты.
•
•
•
•
•
Время отклика
Обслуживание (и время отклика) в течение выходных и неурочных часов
Посещения на дому (поддержка для домашних компьютеров)
Специальное (уникальное или патентованное) аппаратное обеспечение
Политика модернизации (устаревшие аппаратные средства, программное обеспечение и т.д.)
•
•
•
•
•
Поддерживаемые операционные системы
Поддерживаемые облачные платформы
Стандартные конфигурации
Хранение данных
Программное обеспечение специального назначения
Рассматривая стандарты услуг, имейте в виду, что многие пользователи захотят само
стоятельно настроить свою среду (или даже свои системы), если не будет установлено
программное обеспечение, чтобы это предотвратить. Стереотипный ответ на эти попыт
ки
-
запретить всем пользователям осуществлять любые модификации. Это упрощает
работу отдела информационных технологий, но не всегда является лучшей стратегией
для всей организации.
Укажите эту проблему в своем соглашении о качестве оказываемых услуг и попытай
тесь стандартизировать ее решение на нескольких определенных конфигурациях. Иначе
ваше стремление к облегчению обслуживания и быстрому росту в рамках всей организа
ции встретят серьезные препятствия. Поощряйте своих творческих сотрудников предла
гать модификации, в которых они нуждаются, и будьте заботливы и щедры, учитывая их
предложения в своих стандартных конфигурациях. Если вы не сделаете этого, то ваши
пользователи будут упорно нарушать ваши правила.
Стратегии управления очередями
Пользователи должны знать не только, какие услуги им будут оказаны, но и схе
му приоритетов, используемую для управления очередью заданий. Схемы приори
тетов всегда оставляют возможность для маневра, но все же попытайтесь спроекти
ровать такую схему, которая охватывала бы большинство ситуаций, почти или вовсе
не прибегая к исключениям. Некоторые факторы, связанные с приоритетом, пере
числены ниже.
Глава
•
•
•
•
•
•
•
31. Методология,
1129
политика и стратегии
Важность услуги мя всей организации
Влияние на безопасность (было ли нарушение правил безопасности?)
Оплаченный или оговоренный уровень сервисного обслуживания
Количество задействованных пользователей
Важность любого релевантного крайнего срока
Скандальность задействованных пользователей ("скрипучие колеса")
Важность задействованных пользователей (это дело тонкое, но будем честными:
у некоторых людей в вашей организации есть больше авторитета, чем у других).
Хотя на ваше ранжирование будут влиять все эти факторы, мы рекомендуем подхо
дить к исключениям с простым сводом правил и долей здравого смысла. В основном,
мы используем следующие приоритеты.
•
•
•
Много людей не могут работать успешно
Один человек не может работать успешно
Запросы на усовершенствования
Если два или больше запросов имеют высший приоритет и они не могут выполнять
ся параллельно, мы делаем выбор, основываясь на серьезности проблемы (например,
неработающая электронная почта доставляет неудобства почти всем, тогда как времен
ное отсутствие неб-службы могло бы помешать только нескольким людям). Очереди
с более низкими приоритетами обычно обрабатываются по принципу
FIFO.
Показатели соответствия
Соглашение о качестве оказываемых услуг должно определить, как организация из
меряет ваш успех при выполнении условий соглашения. Цели и ориентиры позволяют
работникам совместно стремиться к общему результату и могут заложить основу мя со
трудничества во всей организации. Конечно, вы должны удостовериться, что у вас есть
инструменты, позволяющие измерить согласованные показатели.
Как минимум, вы должны отследить следующие показатели вашей информационной
инфраструктуры.
•
•
Процент или количество проектов, законченных вовремя и в пределах бюджета
Процент или количество выполненных пунктов соглашения о качестве оказывае
мых услуг
•
Процент продолжительности работы системы (например, электронная почта до-
ступна через службу
•
•
•
Q\
в течение
99,92%
времени)
Процент или число билетов, проблема которых бьmа удометворительно решена
Среднее время решения проблемы, описанной в билете
Процент или количество нарушений системы безопасности, обработанных соглас
но устаноменной процедуре
31.8. СООТВЕТСТВИЕ ЗАКОНАМ И СТАНДАРТАМ
П-аудит и управление в настоящее время являются очень популярными. Инструкции
и квазистандарты мя спецификации, проведения измерений и сертификации соответ
ствия законам породили множество аббревиатур:
SOX,
IТIL, СОВП и
ISO 27001,
и это
ЧастьlV.Эксплуатация
1130
только часть из них. К сожалению, эта смесь букв оставляет у системных администрато
ров неприятный осадок, поэтому сейчас ощущается недостаток программного обеспече
ния, предназначенного дnя реализации всех средств управления, необходимых дnя обе
спечения соответствия с дейстоующим законодательством.
Некоторые из основных рекомендательных стандартов, руководящих принципов,
промышленных концепций и законодательных требований, которые могут касаться си
стемных администраторов, перечислены ниже. Законодательные требования являются
в значительной степени специфичными дnя Соединенных Штатов Америки.
Обычно стандарты определяются типом организации или обрабатываемых данных.
Организации, находящиеся вне юрисдикции США, должны сами выяснить, какие регу
ляторные правила распространяются на них.
• CJIS
(Информационные системы уголовного судопроизводства) -стандарт, отно
сящийся к организациям, которые отслеживают криминальную информацию
и пользуются базами данных ФБР. Его требования могут быть найдены на страни
це fЬi.gov/hq/cjisd/cjis.htm.
• COBIT -
рекомендации дnя информационного управления, основанного на пе
редовом промышленном опыте. Они разработаны совместно Ассоциацией ау
дита и управления информационными системами
(Systems Audit and Control
Association - ISACA) и Институтом информационного управления (IТ
Governance lnstutute - ПGI); см. детали на сайте isaca. org. Задача рекомен
даций COBIT состоит о том, чтобы "исследовать, развивать, предавать гласности
и продвигать авторитетный, современный, международный набор общепринятых
целей уnравления информационными технологиями дnя ежедневного использова
ния менеджерами и аудиторами."
Первая редакция этих рекомендаций бьша выпущена в
версия
5.0,
изданная в
2012
1996
году, сейчас действует
году. Последняя версия разрабатывалась под сильным
влиянием требований закона Сарбейнза-Оксли
(Sarbanes-Oxley).
Она включает
37
целей высокого уровня, которые разделены на пять категорий: согласование, пла
(Align, Plan, and Organize - АРО), создание, приобрете
(Build, Acquire, and lmplement - BAI), поставка, обслуживание
и поддержка (Deliver, Service, and Support - DSS), мониторинг, оценка и доступ
(Monitor, Evaluate, and Access - МЕА), а также оценка, управление и мониторинг
(Evaluate, Direct, and Monitor - EDM).
• СОРРА (Ch\ldren's Onllne Prlvacy Protection Act - Закон о защите конфиденциаль
нирование и организация
ние и реализация
ной информации о детях в Интернете); регулирует работу организаций, которые
собирают или хранят информацию о детях, не достигших
13 лет.
Для сбора опре
деленной информации необходимо разрешение родителей; см. детали на сайте
ftc. gov.
• FERPA (Family Educatlonal Rlghts and Privacy Act -
Закон о правах семьи на образо
вание и неприкосновенность частной жизни); относится ко всем учреждениям, яв
ляющимся получателями федеральной помощи, которой уnравляет министерство
образования. Этот закон защищает информацию о студентах и предоставляет сту
дентам определенные права относительно их данных; см. детали на сайте
•
FISМA
(Federal Information Security Management Act -
ed. gov.
Закон об управлении ин
формационной безопасностью в федеральном правительстве); относится ко всем
правительственным учреждениям и подрядчикам правительственных учреждений.
Это большой и довольно неопределенный набор требований, которые нацелены
Глава
31. Методология,
политика и стратегии
1131
на согласование со множеством публикаций об информационной безопасности,
выпущенных институтом
NIST, Национальным институтом по стандартизации
(National lnstitute of Standards and Technology). Независимо от того,
подпадает ваша организация под мандат FISМA или нет, документы N IST заслу
живают внимания; см. nist. gov.
• Концепция Safe HarЬor (правило безопасной rаванн) Федеральной комиссии по тор
rовле США (FfC) представляет собой мост между подходами США и Европейского
и технологии
Союза к законодательству, защищающему частную жизнь, и определяет способ,
с помощью которого американские организации могут взаимодействовать с ев
ропейскими компаниями, чтобы продемонстрировать защиту своей информации;
cм.export.gov/safeharbor.
•
Закон Jрэмма-Лича-Блайли
(Gramm-Leach-Bliley Act - GLBA)
регулирует исполь
зование финансовыми учреждениями конфиденциальной информации потре
бителей. Если вы задавались вопросом, почему банки, выпускающие платежные
карты, брокеры и страховщики забрасывали вас уведомлениями о конфиденци
альности, то это следствие закона Грэмма-Лича-Блайли; см. детали на сайте
gov.
ftc.
В настоящее время самая полная информация по закону Грэмма-Лича
& Advice этого сайта. В качестве
goo. g 1/vv2О11.
HIPAA (Health lnsurance PortaЬility and AccountaЬility Act -
Блайли находится в разделе Тips
глубокой ссылки
можно использовать сокращение
•
Закон
Закон об отчет
ности и безопасности медицинского страхования) относится к организациям, ко
торые передают или хранят защищенную медицинскую информацию (иначе РНI).
Это широкий стандарт, который был первоначально предназначен для борьбы
с растратами, мошенничеством и злоупотреблениями в области здравоохранения
и медицинского страхования, но теперь он используется для того, чтобы измерить
качество и улучшить безопасность информации о здоровье; см.
privacy/index. html.
• ISO 27001:2013 и ISO 27002:2013 -
hhs. gov / ocr /
это рекомендательная (и информативная)
коллекция передового опыта, связанного с безопасностью организаций, использу
ющих информационные технологии; см.
iso. org.
• CIP (Critical Infrastructure Protection) - семейство стандартов, разработанных кор
порацией North American Electric Reliabllity Corporation (NERC), которые способ
ствуют защите инфраструктурных систем, таких как электроснабжение, телефон
ные линии и финансовые сети, от стихийных бедствий и терроризма. В полном
соответствии с учебной иллюстрацией ницшеанского понятия "жажды власти"
оказывается, что большая часть экономики попадает в один из
тических инфраструктур и ключевых ресурсов"
ется в стандартах
CIP.
(Cl/KR)
17 секторов
"кри
и поэтому очень нужда
Организации, попадающие в эти сектора, должны оценить
свои системы и защищать их соответствующим образом; см.
•
Стандарт
nerc. сот.
PCI DSS (Payment Card lndustry data Security Standard - Стандарт
за
щиты информации в индустрии платежных карт) был создан консорциумом пла
тежных брендов, включая
American Express, Discover, MasterCard, JCB
и
Visa.
Он
охватывает вопросы управления данными о платежной карте и относится к любой
организации, которая принимает платежи по пластиковой карте. Стандарт имеет
два варианта: самооценку для небольших организаций и внешний аудит для орга
низаций, которые обрабатывают много сделок; см.
pcisecuri tystandards. or·g.
1132
•
ЧастьlV.Эксплvатация
Правила
Red Flags Rules Федеральной
Комиссии по торговле США требуют, чтобы
любой, кто расширяет кредит на потребителей (т.е. любая организация, которая
отсылает счета), осуществлял формальную программу, предотвращающую и обна
руживающую "хищение персональных данных". Правила требуют, чтобы эмитен
ты кредитов разработали эвристические правила для того, чтобы идентифициро
вать подозрительные манипуляции со счетами. Для выяснения деталей наберите
фразу
•
"red flag" в поисковой строке на сайте ftc. gov.
Information Technology Infrastructure Library
Библиотека
(IТIL) в 1990-х и 2000-х
годах стала фактическим стандартом для организаций, ищущих полноценное ре
шение для управления информационными услугами. Во многих крупных органи
зациях была развернута формальная программа IТI L, дополненная назначениями
менеджеров проекта для каждого процесса, менеджеров, управляющих менед
жерами проектов, а также системой отчетности для менеджеров, управляющих
менеджерами проектов. В большинстве случаев результаты не были благоприят
ными. Зацикленность на процессах в сочетании с разделением функций привел
к неразрешимым П-конфликтам. Эта бюрократическая цепочка создала возмож
ности для небольшого количества стартапов, получивших возможность забрать
долю рынка у хорошо зарекомендовавших себя компаний, в результате чего мно
гие П-специалисты остались без работы. Мы надеемся, что увидели последний из
IТIL. Некоторые говорят, что
•
Раздел 1Т
General Controls
DevOps -
это методология против IТIL.
(IТGC) в законе Сарбейнэа-Оксли
(SOX),
последний
по расположению, но не по важности, относится ко всем акционерным обществам
и разработан, чтобы защитить акционеров от бухгалтерских ошибок и мошенни
ческих методов; см.
sec.gov/rules/final/33-8124 .htm.
Некоторые из этих стандартов содержат хорошие рекомендации даже для организа
ций, которые не обязаны придерживаться их. Вероятно, стоит просмотреть некоторые
из них, чтобы понять, содержат ли они какие-либо рекомендации, которые вы, возмож
но, захотите принять. Если у вас нет других ограничений, проверьте
800-53; они являются
NERC CIP
и
NIST
нашими фаворитами в отношении тщательности и применимости
к широкому кругу ситуаций.
Национальный институт стандартов и технологии
(NIST)
издает множество стандар
тов, полезных для администраторов и технологов. Некоторые из популярных стандартов
упомянуты ниже, но если вам скучно и вы ищете стандарты, можете зайти на его веб
сайт. Вы не будете разочарованы.
Стандарт
NJST 800-53 (Рекомендуемые средства управления
системами безопасности
для федеральных информационных систем и организаций) описывает, как оценить без
опасность информационных систем. Если ваша организация разработала внутреннее
приложение, которое хранит конфиденциальную информацию, этот стандарт может
помочь вам удостовериться, что вы действительно защитили ее. Однако остерегайтесь:
процедура согласования со стандартом
NIST 800-53 не для слабонервных. Вы, вероят
100 страниц со множеством мучитель
но, столкнетесь с документом объемом около
ных деталей. 5
Стандарт
NJST 800-34
(Принципы планирования на случай непредвиденных ситуаций
для информационных систем) является библией аварийного восстановления, разрабо
танной организацией NISТ. Он предназначен для правительственных учреждений, но
5 Если
вы планируете сотрудничество с правительственными учреждениями США. от вас могут по
требовать соответствия стандарту
NIST 800-53,
хотите вы этого или нет".
Глава
31. Методология,
политика и стратегии
1133
любая организация может извлечь из него выгоду. Следование стандарту планирования
N IST 800-34 требует
времени, но это вынуждает вас ответить на такие важные вопросы,
как: "Какие системы являются самыми важными?", "Сколько времени мы можем обой
тись без этих систем?" и "Как мы собираемся восстанавливаться, если наш основной
центр обработки данных потерян?"
31.9.
ПРАВОВЫЕ ВОПРОСЫ
Правительство США и некоторые штаты издали законы о преступлениях в области
компьютерной техники. На федеральном уровне с начала 1990-х годов существовало два
закона, а теперь их стало больше.
•
Федеральный Закон о конфиденциальности связи (Electгonic
Communications
Privacy Act).
•
Закон о компьютерном мошенничестве и компьютерных злоупотреблениях
(Computer Fraud and Abuse Act).
•
•
Закон о компьютерных кражах
•
•
Закон о конфиденциальности электронной почты
(No Electronic Theft Act).
Закон об авторских правах
Закон о
(Digital Millenium Copyright Act).
(The Emai\ Privacy Act)
кибербезопасности 2015 года (Cybersecurity Act of2015).
Основными правовыми проблемами в настоящее время являются ответственность
системных администраторов, сетевых операторов и облачных провайдеров; пиринговые
сети для обмена файлами между пользователями, защита авторских прав и конфиден
циальность. В разделе рассматриваются эти и другие юридические вопросы, связанные
с системным администрированием.
Конфиденциальность
Частную жизнь всегда было трудно скрыть, но с развитием Интернета она подвер
гается еще большей опасности, чем когда-либо. Медицинская документация неодно
кратно раскрывалась с помощью плохо защищенных систем, украденных ноутбуков
и магнитных лент с резервными копиями данных, которые находились не в положен
ном месте. Базы данных, содержащие номера пластиковых карт, всегда подвергались
атакам. Веб-сайты, предлагающие антивирусное программное обеспечение, фактиче
ски сами устанавливают программы-шпионы. Поддельная электронная почта посту
пает почти ежедневно в виде фиктивных писем от вашего банка, в которых утвержда
ется, что у вас возникли проблемы с вашим счетом и требуется, чтобы вы проверили
свои учетные данные. 6
Технические меры не могут защитить от этих видов атак, потому что они направлены
на самую уязвимую часть вашего сайта: его пользователей. Поэтому лучшей его защитой
является база хорошо обученных пользователей. В первом приближении можно сказать,
что в никаком законно посланном сообщении электронной почты или на веб-сайте ни
когда не будет перечисленных ниже вещей.
"Обычно внимательное изучение электронной почты показывает, что данные будут отправлены ка
кому-нибудь хакеру из Восточной Европы или Азии, а не в ваш банк. Этот тип атаки называется
фишингом.
1134
•
•
•
•
ЧастьlV.Эксплvатация
Поздравлений с тем, что вы выиграли приз
Запросов на "подтверждение" персональных данных учетной записи или паролей
Требований о пересылке куда-либо фрагментов сообщения электронной почты
Указаний на установку программного обеспечения, которое вы не искали и не за
прашивали в явном виде
•
Уведомлений об обнаруженных на вашем компьютере вирусах и других проблемах
с системой безопасности
Пользователи, которые имеют основное представление об этих опасностях, чаще
всего адекватно отреагируют, когда во всплывающем окне браузера появится сообще
ние, что они выиграли бесплатный
MacBook
и ссылка, на которой нужно щелкнуть.
Реализация политики безопасности
Файлы системного журнала могут легко доказать вам, что человек Х сделал плохо че
ловеку У, но для суда это всего лишь слова. Защитите себя письменными заявлениями.
Файлы системного журнала как правило содержат отметки времени, которые полезны, но
их не всегда принимают в качестве доказательства, если на вашем компьютере систем
ное время не синхронизировано с эталоном посредством протокола
NTP (Network
Тtme
Protocol).
Лучше всего создать собственную политику безопасности и довести ее до сведе
ния пользователей вашего сайта, чтобы затем можно было преследовать нарушите
лей в судебном порядке. Она должна содержать утверждение: "Несанкционированное
использование вычислительных систем
может повлечь не только нарушение орга
низационной политики, но и нарушение законов штата и федеральных законов.
Несанкционированное использование
-
это преступление, которое может повлечь уго
ловное наказание и гражданско-правовые санкции; оно будет преследоваться в право
вом порядке в полном объеме".
Мы советуем показывать заставку, которая сообщит пользователям о ваших правилах
контроля. Можно написать что-то вроде такого: "Действие может отслеживаться и фик
сироваться в случае реального или предполагаемого нарушения правил безопасности".
Можно гарантировать, что пользователи увидят ваше уведомление, по крайней мере
один раз, если вы включите его в файлы запуска, которые вы предоставляете новым
пользователям. Если вы требуете, чтобы все попытки входа в систему через протокол
SSH
регистрировалось (а вы должны это требовать!), укажите соответствующие парамет
ры конфигурации в файле
ла
SSH
/etc/ssh/sshd_config,
чтобы при запуске клиент протоко
всегда показывал заставку.
Убедитесь, что, пользуясь своими учетными записями, пользователи соблюдают вашу
письменную политику безопасности. Объясните, где они могут получить дополнительные
копии документов политики и опубликуйте основные документы на соответствующей
веб-странице. Также включите в нее информацию о том, что будет в случае несоблюдения
этих правил (вплоть до удаления учетной записи и т.д.). Более важно, чтобы вы добросо
вестно уведомили пользователей об их обязанностях, а не просто составили юридически
грамотное заявление.
Кроме заставки, целесообразно сделать так, чтобы пользователи в явном виде под
писали соглашение о политике безопасности, прежде чем получить доступ к вашим си
стемам. Это соглашение о приемлемом использовании должно быть разработано в со
трудничестве с вашим юридическим отделом. Если у вас нет подписанных соглашений
глава
31. Методология,
политика и стратегии
1135
со служащими, соберите их. Сделайте подписание соглашения стандартной частью про
цесса приема на работу новых сотрудников.
Вы могли бы также периодически проводить семинары по вопросам безопасности.
Это удобная возможность рассказать пользователям о важных проблемах, таких как фи
шинг, научить их правильно устанавливать программное обеспечение и пароли, а также
кое-чему другому, что относится к вашей компетенции.
Контроль
-
это ответственность
Поставщики услуг (провайдеры Интернета, облачных вычислений и т.п.) обычно
следуют правилам пользования сетью
(appropriate use policy - AUP),
которые диктуют
стоящие над ними провайдеры и которые являются обязательными для их клиентов.
Таким образом, вся ответственность за действия клиентов ложится на самих клиентов,
а не на провайдеров. Целью такой стратегии является защита провайдеров от ответ
ственности за рассьшку спама и прочие незаконные действия, например хранение поль
зователями на своих компьютерах незаконного или защищенного авторскими правами
материала. В каждом штате и каждой стране имеются свои законы на этот счет.
Ваши правила должны явно запрещать пользователям использовать ресурсы ком
пании для незаконной деятельности. Однако на самом деле этого недостаточно
-
вы
также должны дисциплинировать пользователей, обнаружив, что они осуществляют не
законные действия. Организации, которые знают о незаконных действиях, но не при
нимают меры для их пресечения, считаются соучастниками и могут преследоваться
по закону. Нет ничего хуже несоблюдаемых или противоречащих друг другу правил, как
с практической, так и юридической точки зрения.
Из-за риска стать соучастником незаконных действий пользователя некоторые орга
низации ограничивают данные, которые они регистрируют, отрезок времени, в течение
которого сохраняются файлы системного журнала, и объем информации о файлах си
стемного журнала, хранящейся в виде резервных копий. Некоторые пакеты программ
помогают выполнять эти правила, устанавливая уровни регистрации. Это позволяет си
стемным администраторам устранять проблемы, не вторгаясь в частную жизнь пользо
вателей. Тем не менее всегда следует знать, какой вид регистрации требуется по местным
законам или по любым регулирующим стандартам, которые распространяются на вашу
организацию.
Лицензии на программное обеспечение
Многие компании оплачивают меньшее количество копий программ, чем использу
ют на самом деле. Если об этом становится известно, компания теряет гораздо боль
ше, чем сэкономила на приобретении недостающего числа лицензий. Другие компании
получают демонстрационную версию дорогого пакета и взламывают ее (меняют дату
на компьютере, где-то находят и вводят лицензионный ключ и так далее), чтобы па
кет продолжал работать по истечении демонстрационного срока. Как системный ад
министратор должен реагировать на предложения нарушить лицензионное соглашение
и установить нелицензионные копии программы на дополнительные компьютеры? Что
он должен делать, если обнаруживается, что на обслуживаемых им компьютерах работа
ет пиратское программное обеспечение'? И как быть с условно-бесплатными программа
ми, за которые так никогда и не заплатили'?
1136
ЧастьlV.Эксплvатация
Это очень сложный вопрос. К сожалению, начальство не всегда поддерживает ад
министратора, предлагающего удалить нелицензионные копии программ либо оплатить
их. А ведь часто именно системный администратор подписывает лицензионное согла
шение, требующее удалить демонстрационные копии после определенной даты, тогда
как решение их не удалять принимает руководитель.
Нам известно несколько случаев, когда непосредственный начальник системного
администратора предлагал ему "не раскачивать лодку". Тогда администраторы написа
ли докладную вышестоящему руководству, в которой указали количество лицензиро
ванных и используемых копий, а также процитировали лицензионное соглашение. В
одном случае подход сработал, и уволен был непосредственный начальник системного
администратора. Во втором случае уволиться пришлось системному администратору,
потому что даже вышестоящее руководство отказалось действовать по закону. Что бы
вы ни делали в такой ситуации, обязательно делайте это в письменном виде. Требуйте,
чтобы ответы предоставлялись в письменном виде, а если не получится, документи
руйте полученные инструкции в виде коротких служебных записок и отправляйте их
ответственному лицу.
31.1 0.
ОРГАНИЗАЦИИ, КОНФЕРЕНЦИИ И ДРУГИЕ РЕСУРСЫ
Многие группы поддержки систем
ных производителей
-
UNIX
и
и общего характера, и конкрет
Linux -
помогают устанавливать контакты с другими людьми, использу
ющими то же программное обеспечение. В табл.
31.3
приведен короткий список таких
организаций, хотя большинство национальных и региональных групп в этой таблице
не упомянуто.
Таблица
31 .З.
Орrанизации, ориентированные на системных администраторов
UNIX и Unux
систем
Название
Описание
FSF
Free Software Fouпdatioп GNU
фонд свободного программного обеспечения, спонсор
USENIX
Группа пользователей
LOPSA
League of Professioпal System Admiпistrators -
SANS
Спонсор конференций по системному администрированию и безопасности
SAGE-AU
Австралийская гильдия системных администраторов; проводит ежегодные конфе
Liпux Fouпdatioп
Некоммерческий консорциум, ориентированный на стимулирование роста системы
UNIX/LINUX, обсуждающих технические
вопросы•
лига профессиональных системных
администраторов
ренции в Австралии
Liпux
LiпuxFest
NorthWest
Новая и очень содержательная конференция
"Хорошо известная организация, создавшая специальную группу участников конференций
пущена в
Организация
FSF (Free Software Foundation - фонд
GNU (GNU -
спечения) является спонсором проекта
Unix";
LISA,
которая была рас
2016 г.
свободного программного обе
аббревиатура от
"GNU is Not
так называется проект по свободному распространению программного обеспече
ния). Под словосочетанием "свободное программное обеспечение" в названии этой ор
ганизации подразумевается программное обеспечение, которое не имеет почти никаких
Глава
31. Методология,
1137
политика и стратегии
ограничений в использовании, а не бесплатное программное обеспечение. Также орга
низация
FSF
является автором лицензии
UN IX и Linux.
Организация USENIX,
G PL,
которая распространяется на большую
часть систем
представляющая собой союз пользователей
Linux, UNIX
и других операционных систем с открытым исходным кодом, каждый год проводит одну
общую конференцию и несколько специализированных (небольших). Конференция
Annua\ Technical Conference (АТС),
занные с системами UNIX и Linux,
на которой обсуждаются разнообразные темы, свя
представляет собой отличное место для укрепления
связей с сообществом.
Лига профессиональных системных администраторов (League of Professional System
Administrators - LOPSA) имеет сложную и запутанную историю. Изначально она была
создана организацией USENIX и бьu~а предназначена для объединения системных орга
низаторов в отдельную группу SAGE. К сожалению, отношения между организациями
LOPSA и USENIX не сложились, и они стали существовать раздельно.
В настоящее время лига LOPSA организовывает учебные и образовательные про
граммы по системному управлению сетями, такие как System Administrator Appreciation
Day (День системного администратора) в последнюю пятницу июля. Традиционным по
дарком на этот праздник считается бутылка виски.
Институт
SANS
проводит конференции и семинары по вопросам безопасно
сти, а также управляет отдельной учебной программой по сертификации
lnformation Assurance Cenification (G IAC).
Global
В рамках этой программы гильдия выдает
сертификаты по разным направлениям, таким как системное администрирование,
программирование, устранение сбоев и сетевая криминалистика (см. информацию
на сайте
giac. org).
Существует множество групп пользователей
Одни из них связаны с организацией
USENIX,
UNIX, Linux
и других открытых систем.
а другие нет. Локальные группы обычно
проводят регулярные встречи и рабочие семинары с местными или приезжими лекто
рами и часто организовывают банкеты до или после мероприятия. Это хороший способ
поддерживать контакты с системными администраторами в своем регионе.
31.11. ЛИТЕРАТУРА
•
BRooкs,
JR. The Mythical Man-Month: Essays оп So/tware Engineering (2nd
Addison-Wesley, 1995.
К1м, GENE, KEVIN BEHR, AND GEORGE SPAFFORD. The Phoenix Project: А Novel About IT,
DevOps, and Helping Your Business Win (Revised Edition). Scottsdale, AZ: 1Т Revo\ution
Press, 2014.
Кlм, GENE, ЕТ AL. The DevOps Handbook: How to Create World-Class Agility, Reliabllity,
and Security in Technology Organizations. Scottsdale, AZ: 1Т Revo\ution Press, 2016.
L1мoNcELL1, Тномлs А. Тiте Management /or System Administrators. Sebastopol, СА:
O'Rei\ly Media, 2005.
Млсн1лvЕ1_L1, Niccoш. Тhе Prince. 1513. Доступен на сайте gutenberg .org.
FREDERICK
Edition). Reading,
•
•
•
•
Р.,
МА:
• Morris, Kief. ln/rastructure as Code: Managing Servers in the C/oud. Sebastopol, СА:
O'Rei\ly Media, 2016. Эта книга представляет собой хорошо написанный и под
робный обзор методологии DevOps, а также крупномасштабных инструментов
для администрирования системы в облаке. Он включает в себя несколько специ-
ЧастьlV.Эксплvатация
1138
фических особенностей управления конфигурацией как таковой, но это полезно
для понимания того, как управление конфигурацией входит в более крупную схе
му
•
DevOps
Сайт
и структурированное администрирование.
i tl. nist. gov является целевой страницей для лаборатории информацион
NIST и содержит множество информации о стандартах.
ных технологий
•
Веб-сайт
Electronic Frontier Foundation, eff. org,
является отличным местом
для поиска комментариев по актуальным вопросам конфиденциальности, крипто
графии и законодательства. Его всегда интересно читать.
•
Институт
су
SANS размещает коллекцию
sans. org /resources/policies.
шаблонов политики безопасности по адре
Краткая история
системного администрирования
Из записок доктора Питера Салуса
(Peter Н.
Salиs),
историка, занимающегося вопросами развития технологий
В современную эпоху большинство людей имеют хотя бы минимальное предстамение
о задачах, решаемых системными администраторами: они должны неустанно заботиться
об удометворении потребностей пользователей и организаций, а также заниматься про
ектированием и реализацией устойчивой к ошибкам вычислительной среды, стараясь при
этом поражать своих клиентов эффективными решениями. Несмотря на то что системные
администраторы часто считаются низкооплачиваемыми и недооцененными, большинство
пользователей могут хотя бы назвать имя своего местного системного администратора
-
причем во многих случаях гораздо быстрее, чем имя начальника их начальника.
Но так было не всегда. За последние
50
лет (и в течение более чем 30-летней исто
рии этой книги) роль системного администратора постепенно эволюционировала вместе
с операционными системами
UNIX и
Liпux. Полное постижение предназначения систем
ного администратора потребует понимания того, каким путем мы пришли к нынешнему
состоянию, а также понимания ряда исторических факторов, которые сформировали наш
ландшафт. Итак, окинем взглядом несколько чудесных десятилетий. Присоединяйтесь!
Рассвет компьютеризации: системные операторы
Первый серийный коммерческий компьютер,
IBM 701,
был выпущен в
До него все компьютеры выпускались в единичных экземплярах. В
зированная версия
IBM 701
была анонсирована как
память на магнитных сердечниках объемом
4 096
(1952-1960)
IBM 704.
1954
1952
году.
году модерни
Она имела оперативную
слов и включала три индексных реги
стра. Этот компьютер использовал 36-разрядные слова (в отличие от 18-разрядных слов
у
IBM 701)
скоростью
и выполнял арифметические операции с плавающей запятой. Он работал со
уже нервничали: как им пережить эту "модернизацию" и на какие еще подво
дные камни они могут наткнуться?
Что касается самой компании IВМ, то ее специалисты не имели решения проблемы
модернизации и совместимости. В августе
1952
года для пользователей
IBM 701
компа
ния провела курсы повышения квалификации, но учебников не выпустила. Некоторые
слушатели этих курсов продолжали неформально встречаться и обсуждать свой опыт
использования системы. Компания
IBM
поощряла встречи операторов, поскольку со
вместное рассмотрение проблем помогало общими усилиями найти их решение.
IBM
финансировала встречи операторов и предоставила их участникам доступ к библиотеке,
включающей
емая
SHARE,
300
компьютерных программ. Эта группа по обмену информацией, имену
все еще существует (вот уже более 60-ти лет!) 1 •
От узкой специализации к работе в режиме
разделения времени (1961 - 1969)
Первые образцы компьютерного оборудования были достаточно громоздкими и чрез
вычайно дорогими. Это наводило покупателей на мысль о том, что их компьютерные
системы предназначены для решения одной-единственной конкретной задачи: только
достаточно крупная и конкретная задача могла оправдать дороговизну и громоздкость та
кого компьютера.
Если компьютер был инструментом специального назначения (наподобие пилы), то пер
сонал, который обслуживал компьютер, можно назвать операторами такой "пилы". К пер
вым системным операторам относились скорее как к "тем, кто пилит древесину", чем как
к "тем, кто обеспечивает все необходимое ДllЯ строительства здания". Переход от систем
ного оператора к системному администратору начался тогда, когда компьютеры преврати
лись в универсальные (многоцелевые) инструменты. Основной причиной изменения точки
зрения на компьютер стало то, что его начали использовать в режиме разделения времени.
Джон Маккарти
начал подумывать о режиме разделения времени
(John McCarthy)
в средине 1950-х годов. Изначально это бьuю только в Массачусетсском технологическом
институте (МIТ) в
1961-1962 годах, когда Джон Маккарти, Джек
(Femando CorЬato) начали серьезно говорить
и Фернандо Корбато
Деннис
(Jack Dennis)
о том, что нужно раз
решить "каждому пользователю компьютера вести себя так, будто он единственный его
пользователь".
В
1964
году мп:
General Electric
и Ве\1
Labs
объединили свои усилия по созданию
проекта по построению претенциозной системы, работающей в режиме разделения
времени. Эта система получила название
Seivice).
Multics (Multiplexed lnforrnation и Computing
Multics превысил бюджет и безнадежно отстал от графи
компания Bell Labs вышла из проекта.
Пять лет спустя проект
ка работ. В результате
Рождение
UNIX (1969-1973)
Отказ компании
Bell Labs
от участия в проекте
Multics
оставил нескольких научных
работников в Мюррей Хилл (штат Нью-Джерси) без работы. Трое из них
(Ken Thompson),
1 Несмотря
Руд Кенедей
на то что группа
(Rudd Canaday)
и Деннис Ритчи
- Кен Томпсон
(Dennis Ritchie) - заин-
SHARE изначально спонсировалась производителями
техники, в настоящее время она является независимой организацией.
вычислительной
1141
Краткая история системного администрирования
тересовались некоторыми аспектами проекта
Multics,
но не были в восторге от размера
и сложности этой системы. Они не раз собирались вместе, чтобы обсудить принципы про
ектирования компьютерных систем. Компания
Labs запустила систему Multics на своем
GE-645, и Кен Томпсон продолжил работу над этим проектом "шутки ради."
Макилрой (Doug Mcllroy), руководитель этой группы,сказал: "Система Multics впер
компьютере
Дуг
вые заработала именно :щесь. Вдохнуть в нее жизнь удалось трем нашим сотрудникам".
Летом
года Томпсон на месяц стал холостяком, пока его жена, Бонни, взяв их го
1969
довалою сына, уехала повидать родственников на западное побережье. Томпсон вспоминал:
"Я выделил по неделе на операционную систему, интерпретатор команд, редактор и ассем
блер ... И все эти компоненты были полностью переписаны в форме, которая придавала им
вид операционной системы (с набором известных утилит, ассемблером, редактором, интер
претатором команд), которая практически полностью была самодостаточной и для своей
работы больше не требовала
Стив Борн
(Steve
GECOS 2•• .Пo сути
сывал "заброшенный" компьютер
"В
все это сделал один человек за один месяц".
Вoume), пришедший работать в
PDP-7,
Bell Labs
в следующем rоду, так опи
которым воспользовались Ритчи и Томпсон:
бьти только ассемблер и загрузчик. На этом компьютере мог работать лишь
PDP-7
один пользователь. Среда еще "отдавала сыростью", хотя части однопользовательской
системы
уже были "на подходе" ... И вот бьти написаны ассемблер и зачаточное
UNIX
ядро операционной системы, которые еще требовали использования кросс-ассемблера
для трансляции программы в системе
GECOS
и работы на машине
Название
PDP-7.
апd Computing Service) для "новорожденной" операци
онной системы придумал заядлый остряк Питер Нейман (Peter Neumann) в 1970 году".
UNICS (UNiplexed Information
Первоначально
UNIX бьта
однополъзовательской системой, отсюда, по-видимому, и на
мек на "урезанный вариант
UNIX
Multics''.
И хотя некоторыми аспектами система
все же обязана своей предшественнице
Multics,
UNICS/
у них, по словам Денниса Ритчи,
бьти "серьезные различия".
"Мы бьти немного подавлены большим менталитетом системы,
-
сказал он.
-
Кен
хотел создать что-то простое. Вероятно, из-за того, что наши возможности были тогда до
вольно невелики. Мы могли получить доступ только к небольшим компьютерам, кото
рые никак нельзя было сравнить с теми фантастическими аппаратными средствами, на
которых работал
Multics.
против
Операционная система
Multics ...
Поэтому
UNIX
нельзя назвать ответным ударом, направленным
Multics
больше не существовала для нас, но нам
нравилось ощущение интерактивной работы на компьютере, которое она предлагала
пользователю. У Кена бьти некоторые идеи по со:щанию новой системы ... И хотя
повлияла на подходы к реализации
UNIX,
"Игрушечная" система Кена и Денниса недолго оставалась "простой". К
в число ее пользовательских команд входили следующие:
утилита-календарь),
cat (конкатенация
Multics
это влияние не было определяющим".
и вывод),
chdir
as
(ассемблер),
cal
1971
году
(простая
(изменение рабочеrо каталога),
chmod (изменение режима), chown (изменение владельца), cm.p (сравнение двух фай
лов), ер (копирование файла), date, dc (калькулятор), du (отчет об использовании дис
кового пространства), ed (редактор) и еще два десятка других команд. Большинством из
этих команд все пользуются и по сей день.
К февралю
1973
года можно было говорить о существовании
16
инсталляций
UNIX,
а также о двух больших нововведениях. Первое связано с "новым" языком програм
мирования С, основанным на языке В, который сам представлял собой "урезанную"
версию языка
Ричардсом
GECOS
2
BCPL (Basic Comblned Programming Language), созданного
(Martin Richards). Второе нововведение - понятие канала.
(Geпeral
компанией
Electric Compreheпsive
General Electric в 1962 r.
Operatiпg
System) -
Мартином
операционная система, разработанная
1142
Краткая история системного администрирования
Канал, попросту говоря,
-
это стандартный способ связи выходных данных одной
программы с входными данными другой. Среда
Dartmouth
Тime-Sharing
System
имела
файлы связи, которые предвосхитили каналы, но их использование было гораздо бо
лее узким. Идея каналов (как обобщенного средства передачи данных) была предло
жена Дугом Макилроем, а реализована
-
Кеном Томпсоном благодаря настойчивости
Макилроя. ("Это был один из немногочисленных случаев, когда я, по сути, осуществлял
административное управление над
«Легко сказать:
то заметил
cat Макилрой. -
в
UNIX", -
grep -
в". или
сказал Дуг.)
who -
в
cat -
в
grep
и так далее,
-
как
Это легко сказать, и было ясно с самого начала, что именно
это вы и хотели бы сделать. Но еще существуют все эти параметры". И время от време
ни я говорил: "Как бы нам сделать что-то вроде этого?" И вот в один прекрасный день
я пришел с синтаксисом для командного языка, который развивался вместе с конвейер
ной пересылкой данных, и Кен сказал: "Я готов сделать это!""
Применив множество вариантов, Томпсон обновил все UNIХ-программы за одну
ночь. Это было настоящее начало власти
а из взаимосвязей между ними. Теперь у
UNIX, возникшее не из отдельных программ,
UNIX бьши собственные язык и основополагаю
щие принципы:
•
•
•
пишем программы, которые бы выполняли одну задачу, но выполняли ее хорошо;
пишем программы, которые бы работали вместе;
пишем программы, которые обрабатывали бы текстовые потоки как универсаль
ный интерфейс.
Итак, можно было говорить о "рождении" операционной системы общего назначе
ния с разделением времени, но пока лишь в "недрах" фирмы Ве\1
Labs.
ОС
UNIX
обе
щала простое и незаметное разделение компьютерных ресурсов между проектами, груп
пами и организациями. Но прежде чем этот универсальный инструмент стал достоянием
всего мира, он должен был вырваться из собственной колыбели и "размножиться".
UNIX становится знаменитой (1974-1990)
В октябре
1973
года международная научно-образовательная Ассоциация по вы
числительной технике
(Association
fог
Computing Machinery -
АСМ) провела симпо
зиум на тему "Принципы построения операционных систем"
(Symposium on Operating
Systems Principles - SOSP) в аудитории Центра исследований Уотсона (Т.J. Watson
Research Center) компании IBM в Йорктаун Хайте (Yorktown Heights), штат Нью-Йорк.
Кен и Деннис в один прекрасный осенний день поехали в Долину JУдзона (Hudson
Valley), чтобы представить на рассмотрение свой доклад. (Томпсон сделал настоящую
презентацию.) В зале было около 200 человек, и доклад произвел фурор.
Шесть месяцев спустя количество инсталляций UNIX утроилось. Когда этот доклад
был опубликован в июльском (1974) выпуске журнала Communications of the АСМ, реак
ция читателей была просто ошеломляющей. Научно-исследовательские лаборатории
и университеты увидели в разделяемых
UN IХ-системах
потенциальное решение пробле
мы их постоянно возрастающих потребностей в компьютерных ресурсах.
В соответствии с положениями антимонопольного соглашения
санного корпорацией АТ&Т (из недр которой выделилась фирма
1958 года, подпи
Bell Labs) с федераль
ным правительством, ее деятельность бьша весьма ограничена: она не имела право за
ниматься рекламой, продажей и сопровождением компьютерных продуктов. Компания
Bell Labs должна
бьша давать разрешение на использование другими своей технологии.
Тем не менее система
UNIX
завоевала популярность в мире, особенно среди телефон-
Краткая история системного администрирования
1143
ных компаний. Отвечая на многочисленные просьбы, Кен Томпсон стал распространять
копии исходного кода
подписанную
UNIX, и, по легенде,
"love, ken" (с любовью, Кен).
каждый пакет включал его личную записку,
Одним из тех, кто получил копию системы от Кена, был профессор Роберт Фабри
(Robert Fabry) Калифорнийского университета
Berkeley UN IX попало в плодородную почву.
в Беркли. Так, к январю
1974 года
зерно
Другие ученые, работающие в области компьютерных наук, также проявили интерес
к
UN IX.
В
1976 году Джон
Лайонс
(John Lions),
преподаватель факультета компьютерных
наук в Университете Нового Южного Уэльса в Австралии, опубликовал подробные ком
ментарии относительно ядра версии Vб. Эта работа стала первым серьезным пакетом до
кументации по системе
UN IX и
помогла другим понять и развить работу Кена и Денниса.
Студенты Калифорнийского университета в Беркли поработали над версией
лученной из
Bell Labs,
UNIX,
по
и изменили ее так, чтобы она отвечала их требованиям. Первый лен
точный дистрибугив программы Беркли
(lst Berkeley Software Distribution - l BSD) содержал
Pascal для Unix и текстовый редактор vi для компьютера PDP-11. Этот дистриб}тив
подготовил аспирант Билл Джой (Bill Joy). Второй выпуск (28SD) вышел в следующем году,
а третий (ЗBSD) - в качестве первого дистрибутива программы Беркли для мини-компью
тера VAX, выпускаемого корпорацией DEC, увидел свет в конце 1979 года.
В 1980 году профессор Роберт Фабри заключил контракт с упраВJJением перспектив
ных исследовательских программ в области обороны (Defense Advanced Research Project
Agency - DARPA) на продолжение разработки системы UN IX. Результатом этого со
систему
глашения стало образование в Беркли исследовательской группы по компьютерным си
стемам
(Computer Systems Research Group - CSRG). В конце следующего года вышла
- 4BSD. Она приобрела довольно широкую популярность,
в основном потому, что это была единственная версия UNIX, которая работала на DEC
VAX 11/750, весьма распространенной в то время компьютерной платформе. Еще одно
крупное усовершенствование, отличавшее выпуск 4BSD, состояло в использовании со
кетов TCP/IP, обобщенной сетевой абстракции, которая в будущем породила Интернет
четвертая версия системы
и сейчас используется многими современными операционными системами. К середине
1980-х годов в большинстве крупных университетов и научно-исследовательских инсти
тутов была устаноВJJена хотя бы одна система
UN IX.
1982 года Билл Джой основал компанию Sun Microsystems (сейчас это
часть компании Oracle America) и положил в основу операционной системы SunOS
изобретенную им систему 4.2BSD. В 1983 году по решению суда началась ликвидация
В феврале
корпорации АТ&Т, и одним непредвиденным побочным эффектом этой ликвидации
было то, что АТ&Т отныне моrла свободно продавать систему
UNIX как программный
UNIX System У - общеизвестная, хотя
несколько неудобная коммерческая реализация системы UNIX.
Теперь, когда Berkeley, АТ&Т, Sun и другие дистрибутивы UNIX стали доступны
продукт. В результате увидела свет версия АТ&Т
и
для широкого круга организаций, был заложен фундамент для общей компьютерной
инфраструктуры, построенной на технологии
UNIX.
Систему, которую использовали
в области астрономии для вычисления звездных расстояний, можно было успешно при
менять в математике для вычисления множеств Мандельброта. И та же система одно
временно обеспечивала доставку электронной почты для всего университета.
Эра системных администраторов
УпраВJJение компьютерными системами общего назначения требовало другого уров
ня знаний, чем двадцать лет назад. Ушли в прошлое дни, когда системный оператор
обслуживал единственную компьютерную систему, предназначенную для выполнения
Краткая история системного администрирования
1144
специализированной задачи. Системный администратор в начале 1980-х годов стал на
стоящим "хозяином положения", который знает, как настроить систему
UNIX,
чтобы
она удовлетворяла требованиям самых разных приложений и пользователей.
Поскольку система
UNIX
была весьма популярной в университетах и множество сту
дентов горело желанием овладеть новейшими технологиями, именно университеты лиди
ровали в создании организованных групп системных администраторов. Такие учебные за
ведения, как Университет Пердью, Университет штата Юта, Университет штата Колорадо,
Университет штата Мэриленд и Университет штата Нью-Йорк (SUNY) в r. Буффало, ста
ли "рассадниками" специалистов в области системного администрирования.
Кроме того, системные администраторы разработали собственные процессы, стан
дарты, инструкции и инструменты (например,
sudo).
Большинство из этих продуктов
родилось из необходимости, поскольку без них системы работали нестабильно, что,
естественно, вызывало недовольство пользователей.
Эви Немет
(Evi Nemeth)
приобрела известность как "мать системного администриро
вания" тем, что приглашала на работу в качестве системных администраторов студентов
старших курсов Инженерного колледЖа
(Engineering College)
при Университете штата
Колорадо. Ее близкие связи с сотрудниками Калифорнийского университета в Беркли,
Университета штата Юта и
SUNY в r.
Буффало позволили создать сообщество экспертов
по вопросам системного администрирования, которые делились советами и инструмента
ми. Ее команду часто называли
munchkins,
т.е. "переработчики информации" или "рабы
Эви". Члены этой команды посещали различные конференции (в том числе и спонсиру
емые организацией
USENIX)
и работали там в качестве служебного персонала в обмен
на возможность получать информацию, излагаемую участниками этих конференций.
Уже стало ясно, что системные администраторы должны были стать "мастерами
на все руки". В 1980-х годах обычное утро системного администратора могло начаться
с использования инструмента для накрутки провода для починки поврежденного пере
ключателя на задней панели мини-компьютера
VAX.
Днем он мог заниматься очищени
ем лазерного принтера первого поколения от рассыпавшегося тонера. Его обеденный
перерыв мог быть потрачен на помощь какому-нибудь студенту отладить новый драйвер
ядра, а вечерние часы могли быть заполнены записью информации на архивные ленты
и уговорами пользователей почистить свои персональные каталоги, чтобы освободить
пространство в файловой системе. Системный администратор был, без преувеличения,
бескомпромиссным ангелом-хранителем, который должен был решить любую проблему.
1980-е годы можно было назвать временем ненадежного оборудования. Центральные
процессоры были сделаны не из одной кремниевой микросхемы, а из нескольких сотен
чипов, каждый из которых мог в любую минуту отказать. И именно системный админи
стратор должен бьт быстро отыскать неисправный элемент и заменить его работающим.
К сожалению, в то время почтовая служба
Federal Express
еще не работала, и поэтому
элементы для замены нужно бьто находить самим, что зачастую бьто очень непросто.
Однажды наш любимый компьютер
VAX 11/780
перестал работать, в результате чего
весь университет остался без электронной почты. Мы знали, что недалеко от нас есть
фирма, которая собирала компьютеры
VAX,
предназначенные "для научных исследова
ний" для отправки в Советский Союз (то бьто время "холодной войны"). Практически
без всякой надежды на успех мы заявились на склад с большой суммой наличных в кар
мане, и после часа переговоров мы все-таки получили необходимую печатную плату.
Кое-кто отметил, что в то время в Боулдере (штат Колорадо) было легче достать нарко
тики, чем запчасти к
VAX.
Краткая история системного администрирования
1145
Документация по системному администрированию и обучение
По мере того как отдельные компьютерные специалисты стали считать себя систем
ными администраторами
и причем стало ясно, что такая специализация может обе
-
спечить достойную жизнь,
-
потребности в документации и соответствующем обуче
нии ощутимо возросли. "Идя навстречу пожеланиям трудящихся", Тим О'Рейлли
O'Reilly)
(lim
O'Reil/y and Associates, а теперь O'Reilly Media)
системе UNIX, написанную простым языком
и его команда (именуемая ранее
начали публиковать документацию по
и основанную на реальном опыте.
В качестве посредника межличностного взаимодействия ассоциация
USENIX провела
1987 году.
свою первую конференцию, посвященную системному администрированию, в
Эта конференция
(Large
lпstallatioп
System
Admiпistratioп
- LISA) охватила, в основном,
SANS (SysAdmiп, Audit,
западное побережье. Три года спустя был учрежден институт
Network, Security) для
удовлетворения потребностей специалистов восточного побережья.
В настоящее время конференции
LISA
и
SANS
обслуживают всю территорию США и до
сих пор на достаточно высоком уровне.
В 1989 году мы опубликовали первое издание этой книги, имевшей тогда название UN/X
System Administration Handbook. Она бьта быстро раскуплена, в основном, из-за отсутствия
альтернативы. В то время наш издатель бьт настолько далек от системы UNIX, что в их ре
дакции все вхождения строки "etc" бьти заменены строкой "апd so оп", в результате чего
появились такие имена файлов, как
/and so on/passwd.
Мы воспользовались создавшей
ся ситуацией, чтобы взять под полный контроль все содержимое книги от корки до корки,
и сейчас, надо признать, наш издатель стал более осведомленным в вопросах
UNIX.
Наше
20-летнее сотрудничество с этим издателем дало пищу для других интересных историй, но
мы их опустим, дабы не испортить наши вполне дружеские отношения.
UNIX
при смерти. Рождение
К концу
1990
года казалось, что
Linux (1991-1995)
UNIX
стремительно движется к мировому господ
ству. Бесспорно, именно эту операционную систему выбирали как для ведения бизнеса
(например, Тасо
Bell и McDonald's), так и для исследовательских и научных расчетов.
CSRG (Computer Systems Research Group - исследовательская группа по ком
пьютерным системам) в Беркли, состоящая из Кирка Маккузика (Кirk McKusick),
Майка Карелса (Mike Karels), Кейта Бостика (Keith Bostic) и многих других, как раз вы
пустила версию 4.3BSD-Reпo, основанную на выпуске 4.3, в которую была добавлена
поддержка для процессора CCI Power 6/32 (с кодовым именем "Tahoe").
Коммерческие выпуски UNIX (например, SuпOS) также пользовались успехом, ко
Группа
торый, отчасти, им обеспечили появление Интернета и первые шаги в направлении
электронной торговли. Оборудование персонального компьютера стало предметом ши
рокого потребления. Оно уже бьто относительно надежным, недорогим и обеспечива
ло довольно высокую производительность. И хотя версии системы
UNIX,
запускаемые
на персональных компьютерах, действительно существовали, все они были коммерче
скими, причем с закрытым исходным кодом. Назрела ситуация для появления
UNIX
для персональных компьютерах с открытым исходным кодом.
В
1991 году группа разработчиков, трудившихся над выпусками BSD, - Донн Сили
Seeley), Майк Кареле, Билл Джолитц (ВШ Jolitz) и Трент Р. Хейн (Trent R. Hein) вместе с другими приверженцами BSD основали компанию Berkeley Software Design, lnc.
(BSDI). Под руководством Роба Колстада (Rob Kolstad) компания BSDI предоставляла
(Donп
исполняемые файлы и исходный код для полностью функциональной коммерческой
версии
BSD UNIX
на персональных компьютерах. Среди прочего, этот проект доказал,
Краткая история системного администрирования
1146
что для создания массовых производственных сред можно использовать недорогие пер
сональные компьютеры. Компания
BSDI
продемонстрировала взрывоподобный рост
прибыли на заре развития Интернета, поскольку именно ее операционную систему вы
бирали первые провайдеры услуг Интернета
(lntemet service providers - ISP).
1973 году, кор
порация АТ&Т в 1992 году начала судебный процесс против компании BSDI и членов
правления университета Калифорнии (Regents of the University of Califomia), заявив
Пытаясь снова упрятать джинна, который выскочил из бутылки в
о копировании кода и воровстве производственных секретов. Юристам компании АТ&Т
потребовалось более двух лет, чтобы идентифицировать проблемный код. В результате
судебного разбирательства из кода
BSD
было удалено три файла (из более чем
18 000).
К сожалению, этот двухлетний период неопределенности оказал негативное воздей
ствие на весь мир
UNIX,
операционную систему
Многие компании перешли на использование
BSD и подобные ей не-ВSD-версии.
Microsoft Windows, испугавшись, что они
могут оказаться во власти компании АТ&Т, которая практически "задушила в объяти
ях" свое дитя. К тому времени, когда дым сражений развеялся, оказалось, что компа
UNIX 3• К 1992 году по
Yggdrasil Linux). В 1994 году
Феноменальный успех Liпux основан на многих факторах. Мощная поддержка всех,
кому понравилась эта система, и обширный список программ из архива
GNU
сделали
Liпux неуязвимой системой. Она прекрасно работает в любых производственных средах,
и поговаривают, что на основе
Linux
можно построить более надежную и более произ
водительную систему, чем на основе любой другой операционной системы. Интересно
также отметить, что отчасти своим успехом
Linux обязана блестящей возможности, пре
BSDI и университета Калифорнии
процесс вселил страх в сердца приверженцев UNIX
доставленной ей действиями компании АТ&Т против
в Беркли. Тот неуместный судебный
прямо на заре электронной торговли и в начале эры Интернета.
Но не все ли равно теперь? Главное, что в результате всех этих перипетий осталась
огромная потребность в системных администраторах. Багаж знаний и опыт, накоплен
ный системными администраторами при обслуживании систем
менимы к
Linux,
UN IX,
полностью при
и большинство "UNIХ-лоцманов" заботливо продолжали вести своих
пользователей через бурные моря 1990-х. Возьмите себе на заметку: хороший системный
администратор должен оставаться спокойным во время любого шторма.
Мир
Windows (1996-1999)
В 1993 году компания Microsoft выпустила ОС Windows NТ. Эта "серверная" версия
Windows, которая имела популярный пользовательский интерфейс, имела значительный
эффект, причем как раз тогда, когда корпорация АТ&Т старалась убедить всех в том, что
она больше никому не позволит обманывать себя в лицензионных вопросах. Как следствие,
многие организации приняли
Windows
в качестве предпочтительной платформы для со
вместных вычислений. Это был конец 1990-х. Вне всякого сомнения, платформа
Microsoft
прошла долгий путь развития, и ДllЯ некоторых организаций это был наилучший выбор.
3 0С
Minix
была разработана Эндрю Таненбаумом
дамского свободного университета.
(Andrew S. Tanenbaum),
профессором Амстер
Краткая история системного администрирования
К сожалению, сначала администраторы
1147
UNIX, Linux
и
Windows использовали
в сво
ей работе конкурентные подходы, соперничая за "место под солнцем" путем противо
поставления аргументов из рекламы пива: "отличный вкус" против "меньшего объема" 4 •
Многие администраторы систем
UNIX
и
Linux
начали срочно изучать
Windows,
убеж
денные в том, что в противном случае им придется "положить зубы на полку". А на го
ризонте уже показалась
Windows 2000.
С приближением "миллениума" будущее
UNIX
выглядело все более мрачным.
Расцвет
UNIX и Linux (2000-2009)
С приходом Интернета все старались понять, что "настоящее", а что
всего лишь
-
мираж. Когда страсти "от новизны" немного улеглись, стало ясно, что многие органи
зации с успешными техническими стратегиями использовали
с
Windows,
UNIX
или
Linux
вместе
а не только что-то одно. Конкурентной войны больше не было.
Оценки экспертов, использующих методику определения суммарной стоимости вла
дения (соотношения цены-качества,
показатель для сервера
вера
Windows.
Linux
ТСО), показали, что этот
total cost of ownership -
был значительно ниже аналогичного показателя для сер
После экономического кризиса
2008 r.
показатель ТСО стал еще важнее.
Мир снова разворачивается лицом в версиям операционных систем
UNIX
и
Linux
с от
крытым кодом.
Системы UNIX и Linux в гипермасштабируемом
облаке (201 О- настоящее время)
Варианты
Linux и
UNIХдля персональных компьютеров, такие как
ют расширять свою долю на рынке, при этом
Linux -
FreeBSD,
продолжа
единственная операционная система,
доля рынка которой растет на серверах. Кстати, текущая полномасштабная операционная
система компании Арр\е под названием
macOS, также является
вариантом
UNIX. 5
Значительная часть недавнего роста рыночной доли операционных систем
и
Linux объясняется
UNIX
виртуализацией и облачными вычислениями. Более подробную ин
формацию об этих технологиях см. в главах
9
и
24.
Возможность создания виртуальной инфраструктуры (и целых виртуальных цен
тров обработки данных) путем использования вызовов
API
коренным образом изме
нила тенденции. Ушла в прошлое эпоха ручного управления физическими серверами.
Масштабирование инфраструктуры больше не требует закупок новых серверов в короб
ках. Благодаря таким службам, как
Google GCP, Amazon AWS
и
Microsoft Azure,
насту
пила эпоха гипермасштабируемого облака. Стандартизация, инструменты и автоматиза
ция
это не просто новинки, а неотьемлемые атрибуты каждой вычислительной среды.
-
Сегодня грамотное управление парками серверов требует обширных знаний и навы
ков. Системные администраторы должны быть дисциплинированными профессионала
ми. Они должны знать, как создавать и масштабировать инфраструктуру, как работать
совместно со сверстниками в среде
DevOps,
как программировать простые сценарии ав
томатизации и мониторинга и как сохранять спокойствие, когда одновременно выходит
из строя тысяча серверов. 6
•Для ясности: в
Windows действительно "меньше объема".
iPhone компании Apple можно назвать кузенами UNIX,
компании Google основана на ядре Liпux.
sдаже смартфоны
Aпdroid
6 0дно
торов.
а операционная система
не изменилось: виски по-прежнему остается лучшим другом многих системных администра
Краткая история системного администрирования
1148
Завтрашний день
UNIX
и
Linux
Куда мы направляемся дальше? Экономная модульная парадигма, которая так хо
рошо служила в сфере
UNIX
последние несколько десятилетий, также является од
ной из основополагающих технологий Интернета вещей
Брукингса
(Brookings lnstitution),
к
2020
(loT). По данным Института
50 миллиардов небольших
г. будет существовать
распределенных устройств, образующих Интернет вещей (см.
brook. gs/2bNwbya).
Заманчиво думать об этих устройствах так же, как мы думали о несетевых бытовых
приборах (например, тостерах или блендерах) прошлых лет: подключите их, используйте
в течение нескольких лет и, если они сломаются, выбросьте их на свалку. 7 Им не нужно
управление или услуги системного администратора, не так ли?
На самом деле ничто не могло быть дальше от истины. Многие из этих устройств об
рабатывают конфиденциальные данные (например, звуковые, передаваемые из микро
фона в вашей гостиной) или выполняют критически важные функции, такие как управ
ление температурой вашего дома.
Некоторые из этих устройств запускают встроенное программное обеспечение, по
лученное из мира
OSS.
Но независимо от того, что находится внутри самих устройств,
большинство из них отчитывается перед материнским кораблем, находящимся в облаке,
которое работает, вы уже догадались, под управлением систем
UNIX
или
Linux.
На ран
них, захватнических этапах развития рынка многие устройства уже были развернуты без
особого внимания к вопросам безопасности или будущих экологических последствий.
Интернет вещей не ограничивается потребительским рынком. Современные ком
мерческие здания пронизаны сетевыми устройствами и датчиками, например для ос
вещения, вентиляции и отопления, обеспечения физической безопасности и видеона
блюдения. Эти устройства часто появляются в сети без координации с IТ-отделами или
подразделениями информационной безопасности. Затем о них забывают без какого-ли
бо плана постоянного управления, исправления или мониторинга.
Размер не имеет значения, когда дело доходит до сетевых систем. Системным ад
министраторам необходимо защищать безопасность, производительность и доступ
ность устройств Интернета вещей (и их поддерживающей инфраструктуры) независимо
от размера, местоположения или функции.
Системные администраторы заботятся о целостности компьютерной инфраструкту
ры, решают сложнейшие проблемы эффективности и масштабируемости систем и снаб
жают квалифицированными рекомендациями в области компьютерных технологий как
рядовых пользователей, так и руководителей организаций.
