Эви Немет, Гарт Снайдер
Скотт Сибасе, Трент Р. Хейн
ЧЛЯ ПРОФЕССИОНАЛОВ
UNIX
РУКОВОДСТВО
СИСТЕМНОГО
АДМИНИСТРАТОРА
♦ТРЕТЬ* ИЗДАНИЕ-
(bhv
РЕПИТЕР'
Москва • Санкт-Петербург • Нижний Новгород • Воронеж
Ростов-на-Дону • Екатеринбург • Самара
Киев • Харьков • Минск
2002
Эей Немет, Герт Снайдер, Скотт Собесе, Трент Р. Хейн
UNIX: руководство системного администратора
Для профессионалов
Литературный редактор
Технический редактор
Художник
£. Курбатова
О. Заплаткина
Н. Биржаков
ББК 32.973.2-016.2
УДК 681.31
Немет Э.« Снайдер Г., Сибасе С., Хейн Т. Р.
Н50 UNIX: руководство системного администратора Для профессионалов / Пер.
с англ. — СПб.: Питер; К.: Издательская группа BHV, 2002. — 928 с.; ил.
ISBN 966-552-106-3
ISBN 5-318-00754-6
Третье издание уже ставшего классикой бестселлера. Эта книга — одна из немногих, предназначен-
ных не для широкого круга пользователей, а для системных администраторов, работающих а среде UNIX.
Изложенный материал будет полезен как профессионалам, так и тем. кто еще только постигает тонкости
этой увлекательной и трудной работы. Другими словами, перед читателями исчерпывающее руководство,
в котором подробно описаны многие используемые опытными администраторами приемы работы с раз-
нообразными ресурсами системы UNIX.
Кек создать файлы конфигурации, повысить быстродействие и надежность системы, организовать
работу в корооративмой сети, наладить обмен электронной почтой, подключить новые устройства, — от-
веты на эти и многие другие важные вопросы читатели найдут в данной книге. Кроме того, значительное
внимание уделено обслуживанию технических средств, и также правилам работы администраторов и поль-
зователей.
Книга снабжена большим количеством примеров, взятых из реальной жизни и относящихся к попу-
лярнейшим версиям UNIX: Solerii, HP-UX, Red Hal Linux и FreeBSD.
© Prentice Hall PTR 2001
© Издательская группе BHV, Киев. 2002
© ЗАО Издательский дом «Питер», 2002
Праве на иэданиа получены по осглашанию с Ргапии Hall PTR
Вся права защищены. Никакая часть данной книги на может быть воспроизведен»  какой бы го ни было форме без письменного
сварешения ападильцав авторских прав
Информация, содержащаяся а данной книге, получена из источнике» рясоматриааемых издательством как надежные. Тем не
менее имея а виду возможные человеческие или технические ошибки, издательство ив может гарантировать абсолютную
точность и полноту приводимых сведений и но несет ответственность м возможные ошибки, связанные с использованием книги.
ISBN 066-552-106-3
ISBN 5-316-00754-6
ISBN 0-13-020601-6 (енгл.)
ООО «Питер Принте. 196105, Санкт-Петербург, ул. Благодатная, д 67в.
Лицензия ИД М 05784 от 07.09.01.
ООО «Издательская группа ВН V»
Свидетельство о занесении а Государственный реестр
серия ДК № 175 ст 13.09.2000.
Налоговая льгота - общероссийский классификатор продукции ОК005-93,том 2: 953005 - литературе учебная.
Подписано а печать 18.09.02. Формат 70х|0(У I6. Усл п. л. 74,82. Доп. тираж 3000 экз. Заказ .41302.
Отпечатано с фотоформ в ФГУП «Печатный даорн им. А. М. Горького
Министерства РФ по делам печати, телерадиовещания и средств массовых коммуникаций.
197110. Санкт-Петербург, Чкаловский пр., 15.
Мы посвящаем это издание
памяти трех гигантов мира UNIX и Internet:
Джону Лайонзу, Джону Постелу и Ричу Стивензу.
Джон Лайонз (John Lions), профессор университета штата Новый
Южный Уэльс (Австралия), написал замечательные комментарии
к исходным текстам UNIX в середиие 70-х гт. Он объяснил
назначение примерно 10000 строк кода, из которых в то время
состояла операционная система. Книга Джона использовалась на
учебных курсах по UNIX во всем мире. Проблемы с авторскими
правами привели к тому, что книга перестала издаваться, но еще
в течение многих лет она циркулировала в студенческой среде в виде
ксерокопий с ксерокопий. Те, которые дошли до нас, с трудом
можно прочесть. Джон умер в декабре 1998 г.
Джон Постел (John Postel) был редактором серии RFC-документов
(и автором многих документов), великодушным диктатором сети
Internet и ее технической совестью. Много лет он был поводырем,
который вел сообщество Internet на пути от игровой площадки для
университетских умннков до основной социальной и экономической
движущей силы эпохи компьютерной революции.
Джон умер н октябре 1998 г. (www.postel.org)
Рич Стивенз (Rich Stevens) широко известен в академических кругах
благодаря своим чудесным книгам по сетям и программированию в
UNIX. Студенты любили эти книги, поскольку Рич приводил
примеры, в которых максимально наглядно пояснялись те
или иные концепции и особенности сетевых протоколов. Щедрый
вклад Рича в сообщество Internet заключался в ответах
на многочисленные вопросы по TCP, часто появлявшиеся
в телеконференциях. Трудно представить себе более доступный и
авторитетный источник информации Второй том книги Рича
TCP/IP Illustrated считается неформальной документацией по TCP.
Рич умер в сентябре 1999 г. (www.kohala.com)
5
Предисловие
Мне приятно поздравить сообщество Linux с появлением книги “UNIX:
руководство системного администратора”. В предыдущем издании книги
описывалось шесть вариантов UNIX, все из которых были коммерческими.
Следуя современным тенденциям, нынешнее издание охватывает всего четыре
системы, причем две из них (половина!) — бесплатные. Столь существенные
изменения произошли всего за пять лет.
Такие системы, как Linux и FreeBSD, доказали жизнеспособность модели
открытого распространения ПО с исходными текстами. Они являются такими
же стабильными и полнофункциональными, как и их коммерческие аналоги
Но преимущество открытых систем заключается в том, что сообщество
разработчиков в сжатые сроки устраняет выявляемые ошибки и добавляет
поддержку популярных технологий. Сколько традиционных поставщиков
могут похвастаться этим?
Как следует из книги, системное администрирование не всегда хорошо
вписывалось в традиционную модель разработки Поставщики делают то. что
им заблагорассудится (по причинам, далеко не всегда очевидным), и
администраторы вынуждены принимать удар на себя. Сложность их работы
состоит в том, что программное обеспечение поставляется в виде больших
интегрированных систем. Затронешь один компонент — “полетят” другие.
Ситуация улучшается по мере того, как мы учимся строить полнофунк-
циональные системы из множества отдельных компонентов. Действительно,
почему бы администратору не выбирать, к примеру, систему аутентификации
так же, как секретарша выбирает наиболее удобный для себя текстовый
редактор? Опыт показывает, что возможность выбора ведет к победе хороших
программ над плохими.
Просматривая новое издание книги, я убеждаюсь, что существуют
способы сделать администрирование UNIX-систем удобным, легким и
понятным. Первые признаки этого появились в прошедшем десятилетии.
В ближайшие голы нас наверняка ожидает прорыв в данной области. А пока
наслаждайтесь книгой. Нет предела совершенству!
Линус Торвальдс
Июнь 2000 г.
6
Предисловие
ко второму изданию
В последнее время появилось множество книг, посвященных системному
администрированию. Но эта. на наш взгляд, имеет два существенных
преимущества.
Во-первых, это хорошая книга. Ее авторы в своей повседневном
деятельности занимаются решением реальных административных задач в
реальных системах, с которыми работают тысячи пользователей и где
осуществляется огромное количество сетевых соединений Авторы начали
заниматься этим очень давно и до сих пор помнят, что такое адаптер Unibus
и в чем заключалась проблема DZ1I (не поддерживались прерывания). Они
живут и работают в мире, в котором существуют десятки операционных
систем, созданных разными производителями, и множество версии каждой
системы. Это — не приятное подарочное издание, предназначенное для
аккуратного, чистого мира. Это — тяжелая книга, написанная для суровою
мира.
Во-вторых, это исчерпывающая книга. К настоящему времени выпущено
много хороших изданий, посвященных различным аспектам работы с UNIX
(например, нам известно замечательное пособие по системе -электронной
почты sendmail). но существует очень мало книг, рассматривающих проблему
системного администрирования в целом и стоящих сотен срубленных ради
них деревьев. Рукопись первого издания этой книги имела название
“Усложненное системное администрирование в UNIX". и эю соответствовало
действительности: в книгах типа “Упрошенное..." упускалось всегда так много
деталей, что, вопреки названию, это только усложняло работу.
Факт остается фактом, системное администрирование — (..южная задача.
UNIX-снстемы исключительно мошны, а подобное достоинство всегда
сопровождается повышением степени сложности. Системы на базе персо-
нальных компьютеров тоже будут усложняться, когда вы начнете подключать
их к сетям» модемам, принтерам и внешним дисковым накопителям и
поймете, что нужно заботиться о таких вопросах, как резервное копирование
и безопасность. И вот наступит момент, когда процесс управления персо-
нальным компьютером станет здорово смахивать па администрирование
UNIX-системы: “Это очень просто! Щелкаешь там-то, потом выключаешь
принтер, иначе не будет доступа к сети (выбираешь тут, открываешь эго
меню, щелкаешь на кнопках Disable и Apply), затем открываешь следующее
меню, выбираешь этот пункт, здесь вводишь имя своей машины, потом
щелкаешь вог гут, тут и выполняешь двойной щелчок тут (закрой это
диалоговое окно, оно всегда появляется, не знаю, почему...), потом перехо-
дишь сюда, выбираешь это меню, активизируешь сетевую подсистему,
переходишь в этот каталог, запускаешь приложение TCP/IP, затем — ой!
Забыли установить сетевую маску. Никаких проблем, просто нано вернуться
UNIX — это зарегистрированная горючая марка компании Open Gioup в США и других
странах.
7
в третье меню и изменить маску — черт, а сеть-то отключилась, придется
все исправлять (щелкаем, переходим, щелкаем...). Отлично, теперь опять
запускаем приложение TCP/IP (щелкаем), и можно вызывать telnet! Видишь,
как все просто!”
В UNIX-системах, в отличие от персональных компьютеров, сетевые
средства входят в стандартную поставку ОС. Они настраиваются один раз, и
большинство пользователей не видят, как выполняется конфигурирование.
К сожалению, системные администраторы не относятся к “большинству
пользователей”, поэтому им приходится проделывать эту неблагодарную
работу от начала и до конца.
У авторов есть также что предложить вам для тех редких спокойных
минут, когда у вас пояаляется возможность поразмышлять о том, как
облегчить себе жизиь и улучшить конфигурацию системы. Эта книга,
например, поможет вам настроить систему так, чтобы она работала с
максимальной производительностью, позволит сократить до минимума за-
держки и навсегда избавиться от некоторых проблем. Вы получите советы
относительно того, как отличить хороших пользователей от злоумышленников.
Кое-где еще используются изолированные UNIX-системы, функциони-
рующие без сетей, принтеров, модемов и даже внешних дисководов Если
вы один из приверженцев таких машин или считаете, что графический
интерфейс вас полностью устраивает (и не хотите узнать, что происходит за
его кулисами), эта книга вам, наверное, не нужна. Здесь в деталях
рассматриваются такие мудреные веши, которые вам просто никогда не
понадобятся.
Однако подобные пользователи встречаются достаточно редко и, надеем-
ся, постепенно исчезнут совсем. Наша книга предназначена для всех
остальных пользователей.
Эрик Оллман
Маршалл Керк Маккузик
Август 1994 г.
8
Предисловие
к первому изданию
Вопросу администрирования UNIX-систем всегда уделяли недостаточно
внимания. На мой взгляд, такое отношение обусловлено рядом причин,
связанных с различными аспектами необычной истории UNIX.
Во-первых, система создавалась и развивалась среди ее ревностных
поклонников, которые скоро изучили все ее особенности и нюансы. Этих
людей часто раздражали порядки, установленные в больших компьютерных
центрах, которые в 70-х годах были основными поставщиками вычислитель-
ных ресурсов, поэтому они изобретали собственные — колдовские — адми-
нистративные рецепты, игнорируя популярные справочные руководства.
Во-вторых, типичная UNIX-система занимает в компьютерном мире
несколько обособленную нишу. Чаше всего такая система представляет собой
либо машину среднего класса, обслуживающую один отдел фирмы или
факультет университета, либо рабочую станцию, используемую одним чело-
веком. но соединенную через сеть со многими другими системами. Большей
частью (сейчас появились исключения) UNIX-системы — это ни мэйнфрей-
мы с профессиональным штатным персоналом, прошедшим подготовку у
производителя или в большом компьютерном центре, ни персональные
компьютеры, принадлежащие отдельным пользователям.
Большую машину, как правило, обслуживают профессионалы. Для
персональных компьютеров производитель пишет руководство пользователя
с перечнем советов, предназначенных для ограниченного круга приложений.
Покупатели же машин среднего класса неожиданно для самих себя сталки-
ваются с необходимостью выполнения обязанностей обслуживающего персо-
нала. Им становится почти так же одиноко, как если бы они купили
персональный компьютер, но при этом им приходится следить за множеством
пользователей, иметь дело с одной или несколькими сетями и решать другие
ужасные головоломки.
Наконец, UNIX-системы поступают к нам из разных источников.
Несмотря на наличие в стандартном комплекте поставки ряда полезных
административных утилит, не все поставщики систем в достаточной степени
обеспечивают их техническую поддержку. Кроме того, многие организации
получают значительные объемы программного обеспечения из университетов,
сети Usenet и других источников, не предусматривающих вообще никакой
поддержки.
Несмотря на все эти проблемы, многие поставщики UNIX-систем
все-таки рассказывают своим клиентам о том, как работать с их продуктами.
Тем не менее, исчерпывающая книга по администрированию определенно
необходима. Представление производителя о том, что вам нужно, не всегда
совпадает с вашими желаниями, а документация часто находится в разных
местах. К тому же ваш поставщик может быть более талантлив в производстве
аппаратуры, нежели в составлении руководств по ее использованию. И вы.
возможно, будете работать с популярными программами, которые не входят
в комплект поставки.
Поэтому данная книга вам наверняка пригодится.
Деннис Ритчи
Октябрь 1988 г.
9
Введение
Когда в середине 80-ч гг. мы готовили первое издание книги, нам не
терпелось сравнить нашу рукопись с другими книгами, посвященными
администрированию UNIX-систем К своему удовольствию, мы смогли найти
только три подобных издания
Сегодня существует минимум пятьдесят книг на эту тему. Вот в чем
отличительные особенности нашего издания’
•	Книга является практическим руководством, цель которого — не
пересказывать содержание документации, а поделиться с вами нашим
коллективным опытом системного администрирования. Она содержит
множество практических примеров и советов.
•	В книге подробно излагаются вопросы, связанные с работой UNIX-систем
в сетях. Эго самый трудный аспект администрирования в UNIX, и именно
здесь наша помошь. скорее всего, окажется для вас наиболее полезной
•	Материал книги не подается в упрощенном виде Наши примеры, в
большинстве случаев взятые из практики эксплуатации систем промыш-
ленного уровня, — реальные жизненные ситуации со всеми их подвод-
ными камнями и нюансами.
•	Внимание читателя акцентируется на использовании инструментальных
программных средств. Каждая упомянутая в книге программа представ-
ляет собой либо стандартное средство UNIX, либо может быгь загружена
из Internet. В некоторых случаях программа относится к обеим жим
категориям, потому что многие поставщики UNIX-систем не утруждают
себя и не следя! за появлением новых версии продуктов.
•	В книге рассмотрены все основные версии UNIX
Четыре примера операционных систем
Существуют две основные разновидности UNIX: одна из них (оригиналь-
ная. известная под общим названием System V) разработана компанией
AT&T, а вторая (более свежая) — в Калифорнийском университете в городе
Беркли (известна как BSD). Ни AT&T. ни Калифорнийский университет уже
не работают на рынке UNIX, но термины "AT&T UNIX” и "Berkeley UNIX"
по историческим причинам сохранились.
В этой книге рассматриваются четыре операционные системы
•	Solans 2.7;
•	HP-UX 11.00;
•	Red Hat Linux 6 2:
•	FreeBSD 3.4 (и частично 4 0).
10
Мы выбрали эти системы потому, что они наиболее популярны и, кроме
того, позволяют показать весь спектр подходов к вопросу администрирования
UNIX-систем. Первые две системы произошли от AT&T UNIX, FreeBSD
является прямым потомком Berkeley UNIX, a Red Hat Linux представляет
собой некую смесь.
При рассмотрении каждой темы мы даем подробную информацию об
этих системах. Комментарии, относяшиеся к той или иной операционной
системе, отмечены в книге эмблемой производителя.
Существует много других версий ОС UNIX. Большинство из них является
каким-либо вариантом одной из вышеупомянутых систем, а некоторые
(например, А1Х и SCO) отличаются от остальных в такой степени, что требуют
специфического подхода к их рассмотрению.
Структура книги
Книга включает в себя три большие части:
•	“Основы администрирования”,
•	“Работа в сетях”,
•	“Разное”.
В первом разделе приводится общий обзор ОС UNIX, сделанный с точки
зрения системного администратора. В главах этого раздела описаны основные
факты и методы, которые необходимо знать для управления автономной
UNIX-системой.
В разделе “UNIX в сетях” рассмотрены протоколы, используемые в
UNIX-системах, а также способы построения, расширения и сопровождения
сетей. Кроме того, описывается высокоуровневое сетевое программное
обеспечение. Среди перечня тем можно выделить систему доменных имен
(DNS), сетевую файловую систему (NFS), методы маршрутизации, систему
электронной почты sendmaii и др.
Раздел “Разное" содержит массу вспомогательной информации. Здесь
рассматриваются дополнительные программные пакеты, в частности система
печати в UNIX (правильнее сказать, системы печати). В главах этого раздела
даны рекомендации по обслуживанию аппаратных средств, принципам
организации UNIX-систем и т.д.
Информация для контактов
В этом издании книги мы бы хотели поблагодарить Адама Боггса (Adam
Boggs), Роба Брауна (Rob Brown), Неда Макклейна (Ned McClain). Линду
Мак1инли (Lynda McGinley) и Тодда Миллера (Todd Miller), которые внесли
свой авторский вклад в ее создание. Мы обращались к ним. пользуясь их
знаниями в самых разных областях. Полученная от них информация
значительно обогатила нашу книгу и наш коллективный опыт, которым мы
делимся с вами.
Замечания, предложения, комментарии и сообщения об ошибках, обна-
руженных в этой книге, присылайте по адресу:
sa-book0acmi.n. com
11
Мы отвечаем на всю корреспонденцию, ио, пожалуйста, будьте терпели-
вы: иногда возможность заняться почтой появляется не сразу. Чтобы получить
список обнаруженных на данный момент опечаток, а также другую свежую
информацию по данной книге, обращайтесь по адресу:
www-admin.com
Надеемся, что книга вам понравится, и желаем удачи в системном
администрировании.
Эви Немет
Гарт Снайдер
Скотт Сибасе
Трент Р. Хейн
Июнь 2000 г.*
Обозначения и логотипы, встречающиеся в книге, являются собственностью соответствую-
щих владельцев и используются с их разрешения. В частности:
Red Hat и Red Hal SHADdW MAN — это зарегистрированные торговые марки компании
Red Hat, Inc.
Авторские права на изображение демона BSD (© 1988) принадлежат Маршаллу Керку
Маккузику (Marshall Kirk McKusick). Дополнительную информацию о демоне можно
получить по адресу http://www.mckusick.corn/beastic.
Полное название операционной системы, которую мы называем “Solaris”, звучит так: "the
Solaris Operating Environment”. Приносим извинение ребятам из Sun.
12
Благодарности
С момента выхода в свет первого и второго изданий этой книги сотни
читателей прислали нам сообщения об обнаруженных ими ошибках, ком-
ментарии и критические замечания. Мы хотели бы поблагодарить всех, у
кого нашлось время написать нам, и надеемся, что учли все замечания.
Системное администрирование в UNIX за последние одиннадцать лет
усложнилось, поэтому технический уровень этой книги существенно возрос.
Научные редакторы, работавшие над различными разделами книги, помогли
нам во многих аспектах: от уточнения исторических и технических подроб-
ностей до редактирования неудачного юмора. Эти люди заслуживают
отдельного упоминания:
Эрик Оллман (Eric Allman)	Стив Гэд (Steve Gaede)	Джефф Моу (JelT Мое)
Пит Барбер (Pete Barber)	Эндрю Голлан (Andrew Gollan)	Херб Морриль (Herb Morreale)
Дэйв Барр (Dave Barr)	Боб Грей (Boh Gray)	Ласло Немет (Laszlo Nemeth)
Дэйв Клементс (Dave Clements)	Андреас Густавссон (Andreas Gustafsson)	Тоби Утикер (Tobi Oeriker)
Дэвид Конрад (David Conrad)	Джефф Холприн (Geoff Halprin)	Рэй Плъзак (Ray Plzak)
Дрю Экхардт (Drew Eckhardt)	Дэниел Карренберг (Daniel Karrenberg)	Энди Рудофф (Andy Rudoff)
Рэнди Элс (Randy Else)	Крикет Лиу (Cricket Liu)	Грэг Шапиро (Greg Shapiro)
Билл Феннер (Bill Fenner)	Билл Маннинг (Bill Manning)	Дэниел Салли (Daniel Sully)
Пени Феннер (Peggy Fenner)	Линда Макгилл и (Lynda McGinley)	Пол Ви кси (Paul Vixie)
Джефф Форис (Jeff Forys)	Хол Миллер (Hal Miller)	
Мы выражаем особую признательность Барб Дийкер (Barb Dijker) за ее
усилия по рецензированию книги, а также Пат Парсегян (Pat Parseghian),
которая проделала такую же работу во втором издании книги и продолжила
оказывать нам моральную поддержку в этом издании.
Мэри Франц (Магу Frantz), редактор настояшего издания, заслуживает
не только благодарности, но и награды за успешное обуздание темперамент-
ных авторов. Мэри была бесконечно терпелива к нам, даже когда мы этого
не заслуживали, и сделала все возможное, чтобы заставить нас сконцентри-
роваться на повышении качества книги.
13
Благодарим также редактора первого издания. Джона Уэйта (John Wait).
Большое спасибо Тайлеру Кертину (Tyler Curtain), который занимался
дизайном первого и второго изданий книги и остался с нами в качестве
штатного карикатуриста.
Мэри Ду Hop (Mary Lou Nohr) проделала огромную работу по оформ-
лению настоящего издания. Мы высоко ценим ее усилия.
Дэнни Савард (Danny Savard) из Hewlett-Packard и Энди Рудофф из Sun
Microsystems заслуживают благодарности за то, что убедили свои организации
предоставить нам оборудование.
Наконец, мы искренне признательны сотрудникам факультета вычисли-
тельной техники университета штата Колорадо, которые дали нам возмож-
ность воспользоваться своими вычислительными ресурсами и помогли
проверить множество примеров.
Об авторах
Эви Немет работает преподавателем на факультете вычислительной
техники университета штата Колорадо и внештатным сотрудником CAIDA
(Cooperative Association for Internet Data Analysis) в центре суперкомпьютеров
в Сан-Диего. Она собирается покинуть мир UNIX и отправиться в
кругосветное путешествие на яхте.
evi@cs.Colorado.edu
Гарт Снайдер работал в компаниях NeXT и Sun и имеет степень бакалавра
электротехники в колледже Суортмор (Swarthmore), штат Пенсильвания.
В настоящее время он является аспирантом в университете Рочестера
(Rochester), штат Нью-Йорк.
garth@cs.colorado.edu
Скотт Сибасе — специалист по UNIX, который работал во многих
компаниях, включая Interactive Systems и Xinti. В настоящее время он является
генеральным исполнительным директором компании Xinet, занимающейся
разработкой программного обеспечения для систем допечатной подготовки
Скотт имеет степень бакалавра компьютерных наук и статистики в универ-
ситете Беркли, штат Калифорния.
scott@xinet.com
Трент Р Хейн является руководителем технического отдела компании
XOR 1пс_, разрабатывающей полнофункциональные решения в области
электронной коммерции. Трент получил награду Lifetime Achievement Award
от ассоциации USENIX за разработки, сделанные им в vHHBepCHTere Беркли.
Он имеет высшую степень технической сертификации Cisco.
trent@xor.com
15
Часть I
Основы администрирования
С чего начать
Мы задались целью написать книгу, которая была бы надежным
помощником системного администратора и служила бы источником практи-
ческих советов и полезных сведений по теории системного администрирова-
ния, ведь их далеко не всегда можно найти на страницах интерактивного
руководства. Таким образом, наша книга дополняет, но ни в коем случае не
заменяет документацию, поставляемую с вашей системой.
Эта книга поможет читателю.
•	узнать о различных компонентах систем администрирования и понять
принципы их совместной работы;
•	познакомиться с общими методами администрирования, которые необ-
ходимы при практической работе;
•	научиться внедрять такие решения, которые в дальнейшем не помешают
расширять и усложнять структуру системы,
•	научиться отделять хорошие идеи от плохих и разобраться в особенностях
системных решений различных фирм-поставщиков;
•	усвоить комплекс основных приемов работы, что избавит от нсобхочи-
мостн рыться в документации, пытаясь узнать, как выполнить простую
задачу.
Перечисленные задачи невозможно решить с абсолютной степенью
объективности. Поэтому по ходу книги мы постарались максимально четко
сформулировать свои субъективные взгляды и предпочтения. Особенность
системного администрирования заключается в том, что опытные админист-
раторы могут иметь совершенно разные представления о правилах и
процедурах управления системами. Вам придется самостоятельно решать,
какой именно материал и в какой степени соответствует той среде, в которой
вы работаете.
Глово 1 С чего ночотъ
19
1.1.	Что необходимо знать
Мы предполагаем, что у читателя есть определенный опыт работы с
UNIX. В частности, необходимо иметь общее представление о том, как
выглядит и ведет себя система с точки зрения пользователя. Лишь при этом
условии можно переходить к изучению принципов администрирования.
Книги, перечисленные в параграфе 1.9, помогут заложить необходимый
фундамент знаний.
Большинство задач администрирования решается путем редактирования
файлов конфигурации и написания сценариев, поэтому читатель должен быть
знаком с каким-нибудь текстовым редактором. Настоятельно рекомендуем
изучить редактор vi. Он является стандартным для всех UNIX-систем и, хотя
выглядит несколько "бледным** на фоне более мощных программ (в
частности, emacs), абсолютно пригоден для работы. Если отдать предпочтение
другому редактору, очень быстро надоест устанавливать его в каждой новой
системе. К разочарованию многих, использование Microsoft Word в качестве
универсального текстового редактора является серьезной помехой на пути
эффективного системного администрирования.
Один из важнейших инструментов администратора UNIX — это сценарии,
предназначенные для автоматизации основных задач. Примеры такого рода
сценариев приводятся на протяжении всей книги. Чтобы стать профессио-
налом. необходимо научиться читать и модифицировать сценарии, написан-
ные на языке Bourne shell (sh). Сценарии, которые пишутся “с нуля”, можно
составлять на командном языке или любом доступном языке сценариев.
Для новых проектов мы рекомендуем применять язык Perl. Как язык
программирования, он несколько необычен, однако включает много средств,
полезных для администратора. Кроме того, советуем изучить язык системы
expect, который более подробно рассматривается в параграфе 18.2. Этот язык
можно освоить достаточно быстро.
1.2.	Краткая история UNIX
Операционная система UNIX зародилась в 1969 г. в рамках научно-ис-
следовательского проекта лабораторий Beil Labs корпорации AT&T. В 1976 г.
она стала бесплатно распространяться в университетской среде, что послужило
основой для многочисленных курсов по операционным системам и, соответ-
ственно, для дипломных проектов.
В конце 70-х гг. в AT&T была создана группа поддержки UNIX (UNIX
Support Group, USG), впоследствии преобразованная в систему лабораторий
UNIX (UNIX System Laboratories, USL). Задачей группы была “раскрутка”
UNIX как коммерческого продукта. Разработку системы продолжали и в Bell
Labs, и в USG, но в разных направлениях. Версии USL — System III и
System V — получили широкое распространение и оказали большое влияние
на развитие современных операционных систем.
ОС Berkeley UNIX была создана в 1977 г., когда Исследовательская группа
по вычислительным системам (Computer Systems Research Group, CSRG),
организованная в Калифорнийском университете в Беркли, приобрела
лицензию не исходный код системы у компании AT&T. Версии, выпускаемые
этой группой, сокращенно назывались BSD (Berkeley Software Distribution).
Их выпуск начался в 1977 г. с версии 1BSD для машины PDP-11 и достиг
кульминации в 1993 г., когда вышла версия 4.4BSD.
20
Честь I Основы одминистрировония
Для коммерческих пользователей лицензии AT&T на исходные тексты
всегда стоили дорого. Для университетов они сначала были дешевыми или
вообще бесплатными, но по мере завоевания системой UNIX коммерческого
признания цена быстро росла. В конце концов, специалисты Беркли приняли
решение убрать код AT&T из BSD. Работа предстояла долгая, утомительная
и кропотливая. Незадолго до ее завершения университет лишился финанси-
рования в области исследований операционных систем и Исследовательскую
группу по вычислительным системам расформировали.
Перед расформированием группа выпустила финальную версию системы
без кода AT&T под названием 4.4BSD-Lite. Большинство современных версий
BSD UNIX (включая BSD/OS, FreeBSD, NetBSD и OpenBSD) ведут свое
начало именно от этой системы.
Хотя системы BSD и System V лежат в основе большинства других версий
UNIX, сами они никогда не имели коммерческого влияния. Обычно
поставщики выбирали одну из таких систем в качестве исходного варианта,
на основании которого разрабатывали свою собственную ОС. Иногда на свет
появлялись гибриды, соединяющие в себе черты обеих базовых систем.
Неудивительно, что со временем версии UNIX стали достаточно существенно
отличаться друг от друга.
Настоящим потрясением для мира UNIX стало появление ядра Linux,
которое сегодня внедрено во многие UNIX-системы. Разработка Linux
началась в 1991 г. и была личной инициативой финского аспиранта Линуса
Торвальдса (Linux Torvalds), который задался целью переписать стандартное
ядро UNIX. Со временем к проекту подключилось множество разработчиков,
пользователей и прочих энтузиастов. В результате было создано полнофунк-
циональное ядро системы промышленного уровня, поддерживаемое многими
поставщиками. Для среды Linux уже написаны версии крупных коммерческих
пакетов (к примеру, Oracle).
1.3.	Современные UNIX-продукты
В данной книге в качестве примеров для изучения используются четыре
популярных варианта UNIX: Solaris 2.7, HP-UX 11.00, Red Hal Linux 6.2 и
FreeBSD 3.4. Они столь распространены, что едва ли найдется сервер UNIX,
на котором не была бы установлена хотя бы одна из этих систем.
Операционная система Solaris компании Sun Microsystems относится к
семейству System V, но облапает множеством расширений. Sun UNIX (так
она называлась в середине 80-х гг.) первоначально являлась потомком
Berkeley UNIX, но альянс (уже прекратившийся) между Sun и AT&T привел
к изменению платформы.
ОС HP-UX компании Hewlett-Packard является гибридом между System V
и Berkeley UNIX, но со своими собственными “странностями”.
Существует несколько систем UNIX для платформы Intel, которые
распространяются бесплатно. Самая популярная из них — Linux*. Она
реализована в виде ядра, к которому требуется добавить набор команд, утилит
и демонов, чтобы получить законченную UNIX-систему. Ядро Linux постав-
ляется вместе с другими компонентами в виде дистрибутива, предназначенного
для полноценной инсталляции. Компании, занимающиеся распространением
Linux, используют разные подходы к реализации системы, поэтому версии
Система Linux была перенесена иа множество других платформ, включая игровые приставки
Nintcndo64.
Глова 1. С чего почать
21
Linux могут весьма отличаться друг от друга. Некоторые компании (включая
Red Hat, SuSE и Corel) поставляют системы промышленного уровня,
снабженные всем комплексом технической поддержки.
FreeBSD — это версия UNIX, основанная на системе 4.4jBSD-Lite.
Подобно Linux, она работает на платформах Intel. Коммерческий вариант
системы распространяется компанией BSDL
1.4	Шрифты и условные обозначения
Имена файлов, команды и аргументы команд, которые следует набирать
на клавиатуре без изменений, даны жирным шрифтом. Переменные пара-
метры, вместо которых необходимо подставлять конкретные значения,
выделены курсивом. Например, в команде
ср файл каталог
предполагается, что аргумент файл будет заменен именем реального файла,
а аргумент каталог — именем реального каталога.
Результаты работы команд, а также фрагменты сценариев и файлов
конфигурации набраны моноширинным шрифтом. Комментарии к интерак-
тивным сеансам выделены курсивом, например:
% grep Bob /pub/phonelist /* Найти номер телефона Боба */
Bob Knowles 555-2834
Bob Smith 555-2311
При описании синтаксиса команд мы, как правило, используем те же
обозначения, что и в интерактивном руководстве по UNIX:
•	текст, заключенный в квадратные скобки (’[' и ’]’)> является необязатель-
ным;
•	текст, после которого следует многоточие можно повторять;
•	фигурные скобки (’{’ и '} ) указывают на то. что необходимо выбрать один
из элементов, разделенных вертикальной чертой ('I').
Например, записи
bork [-х] ionioff} имя_файла ...
соответствует любая из следующих команд:
bork on Zetc/passwd
bork -x off /etc/p&sswd /ets/termcap
bork off /usr/lib/traac
В выражениях с шаблонами поиска применяются следующие метасимволы:
• звездочка (’*’) обозначает нуль или более символов;
•	вопросительный знак (’?') обозначает один символ;
•	тильда С~') обозначает начальный каталог текущего пользователя, а
выражение 'пользователь — начальный каталог указанного пользователя.
Например, иногда вместо названий сценариев запуска BSD
/etc/rc
/etc/rc.boot
/etc/rc.local
можно использовать сокращенный шаблон /etc/rc*.
22
4
Чость I Основы одАлинисгрироеония
Информация по конкретным системам
Приведенные в книге сведения относятся, как правило, ко всем
упомянутым системам, есчи не имеется соответствующих указаний. Подроб-
ности, касаюшиеся конкретной системы, помечаются эмблемой поставщика:
Solaris 2.7	ш HP-UX II о
Red Hat Linux 6.2	FreeBSD 3.4
Эти эмблемы использованы с разрешения их владельцев. Отметим, что
фирмы не рецензировали эту книгу.
1.5.	Как пользоваться интерактивным руководством
В документации no UNIX можно наити все, что необходимо знать для
обеспечения работоспособности системы По иногда эту информацию сложно
отыскать, кроме того, часто она подана в трудной для восприятия форме.
У вас обязательно должен быть в наличии полный компло т документации
по той версии UNIX, которую аы используете. Но это новее не означает,
что нужно покупать печатные издания. Большинство документации доступно
в электронном виде либо в самой системе, либо на VVeb-узлс ее поставщика.
Документация, поставляемая вместе с UNIX, как правило, бывает двух
типов, шап-страницы (их название говорит о том, что 'ти страницы
предназначены для просмотра с помошыо команды man) н дополнительные
статьи. Первые содержат полное описание отдельных команд, форматов
файлов и библиотечных подпрограмм. Обычно они доступны и диалоговом
режиме, но иногда поставляются и в распечатанном виде.
Статьи — это более объемные документы, в которых и но подробное
описание той или иной темы. Они служат для углубленного изучения
материала и помощи в решении практических задач. Со многими компонен-
тами программного обеспечения связана как тип-странниа, гак и статья
Например, тпап-странина редактора vi содержит информацию об аргументах
командной строки, но для того чтобы узнать, как редактировать конкретный
файл, придется обратиться к прилагаемой статье.
Поскольку man-страницы тесно связаны с программным обеспечением,
которое они описывают, поставщики стараются нс сильно их менять и делают
это лишь при модификации самих программ’. С дополнениями дело обстот
иначе, так как многие поставщики полностью заменили традиционные
руководства новыми книгами и документами.
Ряд важнейших компонентов UNIX поддерживается сторонними органи-
зациями, такими как ISC (Internet Software Consortium — консорциум
разработчиков программного обеспечения для Internet) и ASF (Apache Software
Foundation — организация разработчиков программною обеспечения для
Apache). Эти организации обычно предоставляют и документацию к рас про
страняемым пакетам. Некоторые поставщики продают программное обсспе
ченкс без документации, поэтому в таких случаях необходимо ингсресопаться.
имеются ли дополнительные материалы.
• Однако так происходит нс всегда. Компания Hewlett-Packard. например, проделала огром
ную работу по редактированию тип-странни
Главе 1. С чего ночоть
23
Другим пенным источником информации о программных пакетах UNIX
является серия документов RFC (Request for comments — запрос на коммен-
тарии), в которых описываются протоколы и программное обеспечение сети
Internet (см. параграф 13.1).
Организация страниц руководства
Во всех UNIX-системах man-страницы делятся на разделы, однако точное
определение каждого раздела зависит от системы. Базовая организация
man-страниц представлена в табл. 1.1.
Таблица 1.1. Разделы таг-сгрониц й UNIX
Solorls HP-UX	Linux FreeBSD	Содержание
1	1	Команды и приложения пользовательского уровня
2	2	Системные вызовы и коды ошибок ядра
3	3	Библиотечные функции
4	5	Стандартные форматы файлов
5	7	Различные файлы и документы
6	6	Игры и демонстрационные программы
7	4	Драйверы устройств и сетевые протоколы
1m	8	Команды системного администрирования
9	9	Внутренние интерфейсы и спецификации ядра
Во многих системах осуществляется разбивка разделов man-страниц на
подразделы. Например, подраздел 3m часто содержит man-страницы с
информацией о библиотеке математических функций системы. Существуют
также значительные различия в распределении man-страниц по разделам: в
некоторых системах раздел 8 оставлен пустым, а команды системного
администрирования помещены в первый раздел. Во многих системах
отсутствуют игры и демонстрационные примеры, поэтому раздел 6 пуст.
Большинство систем позволяют создавать раздел руководства под назва-
нием “I” для man-страниц, которые имеются только на данной машине
(локальные man-страницы). Другое общепринятое обозначение — раздел “п”
для описания тех программных средств, которые не являются строго
локальными, но и не включены в стандартную поставку.
Неформатированная информация для man-страниц традиционно хранится
в каталогах /usr/man/manX, где X — цифра от 1 до 9 либо буква 'Г или ’л’,
и выводится на экран с помощью программы trofT. Отформатированные
версии руководств находятся в каталоге /usr/man/catX. Команда man форма-
тирует man-страницы “на лету” (непосредственно в процессе отображения).
Если в каталоги cat можно записывать информацию, то эта команда сохраняет
отформатированные страницы по мере их создания, помещая наиболее часто
читаемые страницы в кэш. Если в каталоге достаточно места, то, восполь-
зовавшись командой catman, можно одновременно отформатировать все
man-страницы. В некоторых системах, например во FreeBSD, man-страницы
перемещены в каталог /usr/share/man. Часто страницы хранятся сжатыми
(с помощью утилиты compress или gzip) с целью экономии места.
24
Честь I. Основы одминистрмравания
В Solaris языком форматирования man-страниц является SGML (Standard
Generalized Markup Language — стандартный обобщенный язык разметки).
Страницы, отформатированные с помощью утилиты 1го(Т, поддерживаются,
но хранятся в отдельном каталоге.
Чтение страниц руководства: команда man
Команда man заголовок форматирует конкретную страницу руководства и
посылает ее на терминал пользователя посредством программы more (или
другой программы постраничной разбивки, заданной в переменной среды
PAGER), Аргумент заголовок — это, как правило, имя команды, устройства
или файла, о которых необходимо получить справочную информацию. Поиск
по разделам руководства осуществляется в порядке возрастания номеров, но
разделы, описывающие команды (1, 6 и 8), обычно просматриваются в первую
очередь.
Команда man раздел заголовок вызывает man-страницу из указанного
раздела. Так, команда man tty выдает на экран страницу руководства по
команде tty, а команда man 4 tty — страницу для драйвера последовательного
порта.
В Solaris номер раздела необходимо предварять флагом -s, например
man -s 4 tty.
Почти все версии команды man проверяют, определена ли переменная
среды MAN PATH, которая должна содержать разделенный двоеточиями
список каталогов. С помощью переменной MANPATH можно отменить или
расширить список каталогов, в которых по умолчанию проводит поиск
команда man. Например, размещенная в файле .login запись
setenv MANPATH /home/share/localman: /usr/man
указывает команде man на то, что требуется вести поиск сначала в каталоге
локальных man-страниц а затем в каталоге /usr/тав. Версия этой команды
для интерпретатора Bourne shell будет иметь такой вид:
MANPATH=/home/share/localman:/usr/man
export MANPATH
В некоторых системах переменная MANPATH полностью отменяет путь
поиска, заданный по умолчанию. Поэтому следует указать стандартный
каталог явно, если необходимо продолжать просмотр man-страниц, получен-
ных от поставщика системы.
Команда man -к ключевое_слово печатает список man-страниц, в строке
пояснений к которым имеется указанное ключевое слово. Например;
% man -k translate
gftype (IL) - translate a font file for humans to read
pktype (IL) - translate a packed font file
tr (1)	- translate characters
База данных ключевых слов обычно хранится в файле wharis в'корневом
каталоге иерархии man-страниц (/usr/man или /usr/share/man). Если в систему
вводятся дополнительные man-страницы, то. возможно, потребуется перестро-
ить этот файл с помощью команды catman -w.
Глово 1. С чего ночоть
25
1.6	Основные задачи системного сдминисгратора
В этом параграфе содержится обзор некоторых задач, решение которых
обычно возлагается на системного администратора. Совсем не обязательно,
чтобы эти функции выполнял один человек. Во многих организациях работа
распределяется среди нескольких администраторов. В любом случае необхо-
дим хотя бы один человек, который понимал бы все поставленные задачи и
обеспечивал их реализацию другими людьми
Добавление и удаление пользователей
0 Боке подробную информацию о добавлении новых пользователей можно получить
в главе 6.
Создание учетных записей дня новых пользователей и удаление учетных
записей тех пользователей, которые уже не работают в системе, является
обязанностью системного администратора. Процесс управления записями
можно автоматизировать, но ряд решений, связанных с включением в систему
ноиого пользователя (где следует разместить его начальный каталог, на каком
компьютере будет создана учетная запись и т.д.), должен принимать
администратор.
I ели необходимо прекратить доступ пользователя к системе, следует
отключить его учетную запись. Все файды, относящиеся к атому пользова-
телю, нужно удалить, чтобы они не занимали места на диске.
Подключение и удаление аппаратных средств
0 Дополнительная информация по данной теме приведена в главах 8, 12 и 23.
В случае приобретения новых аппаратных средств или подключения уже
имеющихся устройств к другой машине систему нужно переконфигурировать
таким образом, чтобы она распознала и активизировала эти устройства.
Изменение конфигурации может быть как простой задачей (например,
подключение принтера), так и более сложной (скажем, подключение жесткого
диска)
Резервное копирование
0 Подробнее о резервном копировании вы можете узнать в главе 10.
Резервное копирование является одной из наиболее важных задач
системных администраторов, которую они, к сожалению, чаще всего игно-
рируют или выполняют спустя рукава. Процедура резервного копирования
довольно утомительна и занимает много времени, но осуществлять ее
необходимо. Этот процесс можно автоматизировать или поручить подчинен-
ным, но все равно системный администратор обязан убедиться в том, *гто
резервное копирование выполнено правильно и по графику.
Инсталляция новых программ
После приобретения нового программного обеспечения его нужно
инсталлировать и протестировать, часто в разных версиях UNIX и на
рахтичном оборудовании. Если программы работают нормально, пользовате-
лям необходимо сообщить об их наличии и местонахождении. Локальное
25
Чость 1 Основы одминистрировония
программное обеспечение следует инсталлировать туда, где его можно будет
легко отличить от программных средств, поставляемых в составе (INIX. Это
значительно упрощает задачу расширения операционной системы, поскольку
исчезает опасность уничтожения локальных программ в ходе подобного
расширения.
Мониторинг системы
Существует великое множество обязательных для исполнения ежедневных
операций, например: проверка правильности функционирования электронной
почты и телеконференций, просмотр регистрационных файлов на предмет
наличия ранних признаков неисправностей, контроль за подключением
локальных сетей; контроль наличия системных ресурсов (в частности,
проверка наличия свободного пространства на диске).
Поиск неисправностей
Системы UNIX и аппаратные средства, на которых они работают, время
от времени выходят из строя. Задача администратора — диагностировать сбои
в системе и в случае необходимости вызывать специалистов. Как правило,
найти неисправность бывает намного сложнее, чем устранить ее
Ведение локальной документации
Рекомендации, касающиеся ведения документации, даны в параграфе 21.10.
Настраивая конфигурацию системы под конкретные требования, вы
вскоре обнаружите, что она значительно отличается от базовой конфигурации,
которая описана в документации. Поэтому системный администратор должен
документировать все инсталлируемые программные средства, не входящие в
стандартный комплект поставки, документировать разводку кабелей, вести
записи по обслуживанию всех аппаратных средств, ре нитрировать состояние
резервных копий, документировать локальные процедуры и правила работы
с системой.
Слежение за безопасностью системы
Вопросы безопасности рассматриваются в главе 21.
Системный администратор отвечает за реализацию стратегии зашиты и
должен периодически проверять, не нарутдена ли зашита системы В системах
с низким уровнем безопасности эта процедура может быть сведена всего
лишь к нескольким текущим проверкам на предмет несанкционированного
доступа. В системах с высоким уровнем безопасности обычно применяется
сложная система ловушек и программ контроля.
Оказание помощи пользователям
Пункт "оказание помощи пользователям в решении различных проблем”
редко включается в должностную инструкцию системного администратора,
несмотря на то что выполнение подобного рода обязанностей “съедает"
большую часть рабочего времени. Системных администраторов бомбардируют
самыми разными вопросами, начиная от "Вчера моя программа работала, а
сегодня нет! Что Вы поменяли0” до "Я пролила кофе на клавиатуру! Нужно
ли теперь полить ее водой, чтобы смыть кофе?”
Ггово I С чего ночоть
27
1.7.	Как искать файлы в Internet
Информация по вопросам системного администрирования доступна в
больших количествах и в разных формах. Список ресурсов, к которым может
обращаться начинающий администратор, приведен в главе 27.
Основным источником информации является Internet. Вопросы, касаю-
щиеся системного администрирования, можно вводить даже в таких поиско-
вых системах, как www.yahoo.com,www.altavista.com и www.webopedia.com.
Многие Web-узлы непосредственно посвящены данной теме. Вот неко-
торые из них:
•	freshmeat.com — огромная коллекция программного обеспечения для
Linux;
•	www.ugu.com — аббревиатура “ugu” расшифровывается как “UNIX Guru
Universe — вселенная гуру UNIX”; на этом узле содержится много
информации для системных администраторов;
•	www.stokely.com — хорошая коллекция ссылок на ресурсы, связанные с
системным администрированием;
•	www.tucows.com — качественное программное обеспечение для Windows
и Macintosh;
•	slashdot.org — место, где публикуются новости для особо любознательных;
•	www.cpan.org — центральный источник сценариев и библиотек Perl:
•	securityfocus.com — Web-узел, посвященный вопросам безопасности;
огромная поисковая база данных.
1.8.	Издержки профессии
Системные администраторы — это люди, сидящие на нескольких стульях.
Они часто имеют другую работу: просто их попросили присмотреть за
несколькими компьютерами “на стороне”. Если вы один из таких людей,
подумайте о том, к чему, в конце концов, это может привести.
Чем больше вы будете знать о UNIX, тем больше пользователи будут
зависеть от вас. Сети неуклонно разрастаются, и, следовательно, вы будете
вынуждены тратить все больше и больше времени на выполнение функций
администратора. Вскоре окажется, что вы — единственный человек во всей
организации, который знает, как решить целый ряд важнейших проблем.
Если коллеги стали считать вас локальным системным администратором,
от этой роли уже трудно отказаться. Мы знаем нескольких людей, которые
вынуждены были даже поменять место работы, чтобы избавиться от
дополнительной нагрузки Поскольку крут обязанностей системного админи-
стратора четко ограничить нельзя, от вас, скорее всего, потребуют, чтобы вы
были не только штатным администратором, но и штатным инженером,
писателем, а также секретарем.
Чтобы прекратить поток просьб со стороны своих коллег, некоторые
администраторы начинают плохо выполнять свои обязанности, становятся
раздражительными или вообще игнорируют большинство просьб. Не реко-
мендуем вам придерживаться такой политики, иначе у вас могут возникнуть
дополнительные проблемы, в том числе и в отношениях с окружающими.
Вместо этого предлагаем следующее, ведите работу на должном уровне,
одновременно регистрируя время, затрачиваемое на системное администри-
рование. Собирайте доказательства, которые можно будет использовать, когда
вы попросите освободить вас от обязанностей администратора. В большинстве
организаций для того, чтобы добиться замены, приходится упрашивать
руководство полтода, а то и год, так что учитывайте это в своих планах.
28
Чость I. Основы одминистрировония
1.9.
С другой стороны, может оказвтъся, что системное администрирование
вам нравится, и вы захотите стать штатным администратором. В этом случае
проблем с поиском работы у вас не будет. К сожалению, сама работа от
этого не станет легче. О том, какие ужасы вас ждут на данном поприще,
рассказывается в главе 27.
Синдром хронического администрирования
Одной из малоприятных, но, увы, распространенных болезней, сопрово-
ждающих человека, который работает системным администратором, является
синдром хронического администрирования. Признаки заболевания обычно
проявляются на третий год после начала работы администратором и могут
привести к преждевременному уходу на пенсию. Ниже перечислен неполный
список характерных симптомов.
•	Острая пейджерофобия — раздражающее ощущение того, что у вас
сработал пейджер и ваш мирный вечер с супругой внезапно прерван.
Вам кажется, что вас срочно вызывают для устранения последствий ЧП
и вам придется работать 72 часа подряд без перерывов на еду.
•	Навязчивая пользователемания — маниакальное стремление протыкать
иголками кукольные фигурки отдельных представителей пользовательско-
го племени, которые не понимают, что постоянное отсутствие грамотного
планирования является причиной того, что они называют неправильным
администрированием.
•	Идиопатическая лентоплексия — внезапно проявляющееся поздней ночью
стремление смонтировать ленточный накопитель для резервного копиро-
вания, чтобы убедиться в том, что ои читается и маркирован правильно
•	Интеллектуальная шизоидная нетерпимость — непреодолимое желание
стукнуть знакомого системного администратора, который никогда не
применял научных методов администрирования.
Для лечения болезни могут использоваться различные терапевтические
методики. Наиболее эффективными являются принудительное развитие
чувства юмора и организация небольшого, но хорошо оборудованного
винного погребка в офисе. Допускаются также более медитативные методы,
например молчаливо-безучастное разглядывание окружающего пространства,
когда рядом с вами раздается очередной гневный возглас "Что? Сервер снова
упал?!” Если ничего другого не помогает, возьмите отпуск.
Рекомендуемая литература
•	Anderson, Gail, and Paul Anderson. The UNIX C Shell Field Guide. Englewood
Cliffs, NJ: Prentice Hall. 1986
•	Hewlett-Packard Company. The Ultimate Guide to the VI and EX Text Editors.
Redwood City, CA: Benjamin/Cummings. 1990.
•	Abrahams, Paul W., and Bruce A. Larson. UNIX for the Impatient, 2nd Edition.
Reading, MA: Addison-Wesley. 1995.
•	Peek, Jerry, Tim O'Reilly, and Mike Loukides. UNIX Power Tools, 2nd Edition.
Sebastopol, CA: O'Reilly & Associates. 1997.
•	Montgomery, John, and Woody Leonard. The Underground Guide to Unix:
Slightly Askew Advice from a Unix Guru. Reading, MA: Addison-Wesley. 1995.
•	Reichard, Kevin, and Eric Foster-Johnson. Unix in Plain English, 3rd Edition.
Foster City, CA: IDG Books Worldwide. 1999.
•	Rankin, Bob. The No BS Guide to Linux. No Starch Press. 1997.
•	Wall, Larry, Tom Christiansen, and Randal L. Schwartz, Programming Perl,
2nd Edition. Sebastopol, CA: O'Reilly & Associates. 1997.
Слово 1 С чего ночоть
29
2
Запуск и останов системы
UNIX — сложная операционная система, и процедура ее включения/вы-
ключения не сводится к простому нажатию кнопки питания. Поэтому если
вы хотите, чтобы система работала корректно, выполняйте операции запуска
и останова по всем правилам.
Процесс начальной загрузки системы всегда казался загадочным, но он
был проще в те времена, когда один производитель поставлял целиком как
аппаратную, так и программную часть системы. Сейчас, когда UNIX работает
иа персональных компьютерах, необходимо придерживаться правил, установ-
ленных компанией Microsoft, что порождает существование многочисленных
конфигураций. Несмотря на то, что мы рассматриваем особенности загрузки
всех тестовых систем, вы увидите, что гораздо больше внимания уделяется
системам, установленным на персональных компьютерах, чем системам,
выполняющимся на оборудовании собственного поставщика.
Хотя данная глава в книге — одна из первых, в ней мы иногда оперируем
понятиями, которые подробно рассматриваются лишь через несколько сотен
страниц. Поэтому рекомендуем также ознакомиться с главами 5, 12 и 28.
Если ваша система загружается без проблем, можно пропустить эту главу и
вернуться к ней позже.
Отметим, что протекание процесса начальной загрузки зависит от типа
используемого оборудования. Приведенная здесь информация верна для
общего случая, однако в конкретной системе могут проявиться некоторые
отличия.
2.1.	Печальная загаузка
Под начальной загрузкой подразумевается самозапуск компыогера при
включении питания. Поскольку средства операционной системы на данном
этапе недоступны, компьютер должен в буквальном смысле “обслужить себя
сам". Процесс включает загрузку системного ядра в память и его последую-
щую активизацию. Затем выполняется ряд инициализационных задач, после
чего система готова к обслуживанию пользователей.
30
Чсоь I. Основы администрировония
Начальная загрузка — это период особой уязвимости в жизни системы.
Ошибки в конфигурационных файлах, сбои в работе оборудования, повреж-
дения файловых систем могут помешать компьютеру нормально начать работу.
Настройка режимов загрузки во многих случаях является одной из первых
задач, которую приходится решать администратору в новой системе. К не-
счастью, эта задача — одна из наиболее сложных, и для ее решения
необходимо хорошо знать UNIX.
Когда происходит включение питания, запускается на выполнение
загрузочный код, хранящийся в ПЗУ. В его обязанность входит запуск ядра
Ядро опрашивает состояние оборудования, а затем запускает системный
процесс init, идентификатор которого всегда равен 1.
Прежде чем на экране появляется регистрационное приглашение, про-
исходит целый ряд событий. Файловые системы должны быть проверены и
смонтированы, а системные демоны — запушены.. Соответствующие проце-
дуры реализуются с помощью сценариев интерпретатора shell, которые один
за другим запускаются процессом init. Стартовые сценарии часто называют
11 гс-файлами”, поскольку они имеют префикс “тс”. Он расшифровывается
как “run command" — “команда запуска" — и является пережитком,
доставшимся UNIX в наследство от операционной системы CTSS. Конкретная
структура стартовых сценариев и способ их выполнения зависят От системы
Все эти вопросы будут рассмотрены в данной главе.
Автоматическая и ручная загрузка
Большинство UNIX-систем может загружаться либо в автоматическом,
либо в ручном режиме. В первом случае система загружается самостоятельно,
без какого-либо вмешательства извне. Во втором случае она также загружается
автоматически, но до определенного момента: перед выполнением основных
инициализирующих сценариев управление передается оператору (человеку,
сидящему за терминалом). В это время система находится в так называемом
“однопользовательском режиме”. Большинство системных процессов не
выполняется, и вход других пользователей в систему невозможен.
В повседневной работе почт» всегда применяется автоматическая загруз-
ка Типичная процедура загрузки выглядит так: пользователь включает
питание и ждет (ждет...), пока система перейдет в диалоговый режим.
Системный администратор, однако, обязан не только понимать, как проходит
процесс автоматической загрузки, но и знать, как загрузить систему вручную.
Загружать систему вручную чаще всего приходится при возникновении
проблем, вызывающих прерывание автоматического процесса загрузки. Это
могут быть, например, повреждения файловой системы или ошибки в
конфигурации сетевой платы.
Этапы загрузки
Обычно процесс начальной загрузки состоит из шести этапов:
•	загрузка и инициализация ядра;
•	распознавание и конфигурирование устройств;
•	запуск самовыполняющихся системных процессов;
•	выполнение команд оператора (только при ручной загрузке);
•	выполнение стартовых сценариев;
♦	переход в многопользовательский режим.
Глово 2. Зопуск и остонов системы
31
Почти все этапы проходят без контроля со стороны администратора.
Можно управлять процессом загрузки, редактируя стартовые сценарии.
Инициализация ядра
Подробно о ядре рассказывается в главе 12.
Ядро UNIX само по себе является программой, и первый этап начальной
загрузки заключается в считывании этой программы в память для последую-
щего выполнения. Имя файла ядра определяется разработчиком конкретной
системы, но традиционное его название /unix или /vmunlx. В настоящее время
разработчики ие придерживаются строго этого соглашения.
В большинстве систем загрузка ядра осуществляется в два этапа. Сначала
в память машины с диска или магнитной ленты считывается (с помощью
кода, записанного в ПЗУ) небольшая программа начальной загрузки, которая
затем выполняет собственно загрузку ядра. Весь процесс происходит еще вне
UNIX, поэтому в разных системах он реализован по-разному.
Ядро выполняет тестовые программы, позволяющие определить, сколько
памяти имеется в наличии. Большинство внутренних структур ядра обладают
фиксированным размером, поэтому ядро точно знает, сколько памяти нужно
зарезервировать для самого себя. Эта память будет недоступной пользова-
тельским процессам В большинстве систем ядро выдает на консоль сообще-
ние об общем объеме физической памяти и объеме памяти, не занятой ядром
Конфигурация аппаратных средств
Одна из первых задач, стоящих перед ядром, — выявление компонентов
аппаратного обеспечения. Создавая ядро для своей системы, вы можете
указать, какие устройства оно должно проверять. Когда ядро начинает
выполняться, оно пытается найти и инициализировать все устройства, о
которых ему было сообщено. Большинство ядер выводят на консоль краткую
информацию о каждом обнаруженном устройстве.
Информация об устройствах, задаваемая при конфигурировании ядра,
зачастую является неполной. В таких случаях ядро пытается получить
необходимые сведения, опрашивая системную шину на предмет наличия
устройств и запрашивая нужную информацию у соответствующих драйверов.
Драйверы отсутствующих или не отвечающих на контрольный сигнал
устройств отключаются. Даже если позже устройство подключить к системе,
оно будет недоступно для UNIX-процессов до тех пор, пока вы не
перезагрузите’ машину.
Системные процессы
После завершения базовой инициализации ядро создает в области памяти,
выделенной для процедур пользователя, несколько “самовыполняющихся"
процессов. Это происходит в обход стандартного системного вызова fork
(см. параграф 4.2).
Современные системы plug-and-play позволяют подключать периферийное оборудование
во время работы компьютера. Несмотря на то что эта технология достаточно широко
распространена, большинство систем по-прежнему требуют перезагрузки, чтобы новое
устройство было корректно распознано и инициализировано.
32
Часть I. Основы администрирования
Число и характер таких процессов определяются типом операционной
системы. В BSD-системах создаются три процесса:
•	swapper (идентификатор 0);
•	Init (идентификатор 1);
•	pagedaemon (идентификатор 2).
Число самовыполняюшихся процессов в системах семейства System \
варьируется:
•	sched (идентификатор 0);
•	Inlt (идентификатор 1);
•	различные обработчики сигналов ядра.
В Linux процесс с идентификатором 0 отсутствует, а обшее число
самовыполняюшихся процессов зависит от версии ядра:
♦	Inlt (идентификатор I);
•	различные обработчики сигналов ядра (kflushd, kupdate, kpiod. kswapd).
Из всех упомянутых процессов только inlt является полноценным
пользовательским процессом; остальные фактически представляют собой
части ядра операционной системы, которые были преобразованы в процессы
из концептуальных соображений.
После этого ядро больше не принимает участия в процедуре начальной
загрузки системы. К этому моменту, однако, еще не создан ни один из
процессов, управляющих базовыми операциями (например, входом пользо-
вателей в систему), и большинство демонов не запушено. Обо всех этих
задачах позаботится (в некоторых случаях косвенно) процесс init.
Действия оператора (только при ручной загрузке)
Если систему нужно запустить в однопользовательском режиме, оператор
указывает при запуске специальный флаг в командной строке, а ядро передает
эту информацию процессу init. При загрузке в однопользовательском режиме
обычно выдается приглашение ввести пароль пользователя root. Если он
введен правильно, запускается командный интерпретатор с правами пользо-
вателя root. Можно не задавать пароль, а просто нажать <Ctrl-D>, после чего
загрузка продолжится в многопользовательском режиме. В Red Hat команд-
ный интерпретатор запускается без ввода пароля.
Более подробная информация о привилегиях пользователя root содержится в
главе 3.
В однопользовательском режиме оператор может выполнять команды
почти так же. как и в многопользовательском. Однако обычно автоматически
монтируется только раздел диска с корневым каталогом. Другие файловые
системы оператор должен смонтировать вручную для того, чтобы использовать
программы, находящиеся вне каталогов /bin, /sbin нли /etc*. Демоны в
однопользовательском режиме не запускаются, поэтому команды, зависящие
от некоторых серверных процессов (например, mail), работать не будут.
Подробнее о файловых системах и их монтировании читайте в главе 5.
Во многих однопользовательских средах корневая файловая система
монтируется доступной только для чтения. Если каталог /tmp является частью
корневой системы, множество программ, работающих с временными файлами
В некоторых системах монтируется также каталог /ибг.
Глово 2. Зопуск и останов системы
33
(например, редактор vt), откажутся выполняться. Чтобы исправить подобную
ситуацию, необходимо в самом начале однопользовательского сеанса смон-
тировать каталог / в режиме чтения/записи. Как это сделать, зависит от
системы. В большинстве случаев достаточно выполнить команду mount /, а
всю необходимую информацию команда возьмет из файла fctab или vfstab.
В Red Hat система ведет себя немного “агрессивнее” в однопользова-
тельском режиме. К тому моменту, когда отобразится приглашение интер-
претатора shell, система попытается смонтировать все локальные файловые
системы. На первый взгляд, это кажется удобным, но если с какой-нибудь
файловой системой что-то не в порядке, возникают проблемы.
Команда fsck, которая проверяет и восстанавливает поврежденные
файловые системы, обычно выполняется в процессе автоматической загрузки.
Если система запускается в однопользовательском режиме, команду fsck
нужно “прогнать” вручную. Подробно данная команда описана в
параграфе 8.4.
Когда интерпретатор команд, выполняющийся в однопользовательском
режиме, завершит работу, система продолжит загрузку в многопользователь-
ском режиме.
Выполнение стартовых сценариев
К тому моменту, когда система окажется готова выполнять стартовые
сценарии, все “загадочные” этапы процесса загрузки будут завершены. Перед
нами еще не полностью загруженная система, но это уже UNIX. Файлы
сценариев, по сути, представляют собой обычные командные файлы, которые
запускаются процессом init по определенному алгоритму.
Точное местонахождение, содержимое и организация стартовых сценариев
заслуживают отдельного изучения (см. параграф 2.4).
Работа в многопользовательском режиме
Детальное описание процесса регистрации в системе дано в параграфе 7.8.
После выполнения иниииализационных сценариев система полностью
готова к работе, за одним исключением: никто не может в нее войти. Для
того чтобы с конкретного терминала можно было попасть в систему,
необходимо, чтобы терминал имел свой процесс getty, ожидающий поступ-
ления запросов от этого терминала*. По окончании работы последнего
стартового сценария процесс init порождает все необходимые процессы getty.
завершая процесс загрузки Если система сконфигурирована для работы н
графическом режиме, процесс inti также порождает соответствующие регист-
рационные процессы, такие как xdin, gdni или dtlohin.
Необходимо помнить, что процесс init продолжает играть важную роль
даже после завершения начальной загрузки. В BSD-системах он имеет всего
два состояния: однопользовательское и многопользовательское. В других
системах у него есть один однопользовательский и несколько многопользо-
вательских “уровней выполнения”, определяющих, какие ресурсы системы
будут доступны пользователю. Уровни выполнения описаны в параграфе 2.4.
В Solaris используется более сложная процедура регистрации.
34
Часть I Основы администрирования
2.2.	Загрузка системы на персональном компьютере
До сего момента описывалась общая процедура загрузки. Теперь неко-
торые наиболее важные (и сложные) ее этапы необходимо рассмотреть
подробно, проанализировав особенности работы каждой из тестовых опера-
ционных систем.
А начнем мы опять с этапа включения питания и загрузки ядра. На
традиционном UN IX-оборудована и это простой процесс, заслуживающий
лишь нескольких строк описания. Однако если система установлена на
персональном компьютере, то все значительно сложнее. Нам придется дать
много вводной информации, чтобы вы смогли понять суть происходящих
событий.
Если вы не работаете на персональном компьютере, переходите непо-
средственно к параграфу 2.3.
Чем персональный компьютер отличается
от фирменного оборудования
Когда компьютер загружается, начинает выполняться код. записанный в
ПЗУ Точное его местоположение и структура зависят от типа оборудования.
В компьютерах, созданных специально для UNIX, код "прошивается"
разработчиком, который заранее задает алгоритм подключения устройств,
базовой инициализации сети и распознавания локальных файловых систем.
Это очень удобно для системного администратора. Ему достаточно ввести
имя нового файла ядра, а код ПЗУ автоматически обнаружит и прочитает
этот файл.
На персональных компьютерах код начальной загрузки представлен в
виде базовой подсистемы ввода-вывода — BIOS (Basic Input/Output System),
которая чрезвычайно упрощена в сравнении с фирменным кодом UNIX-ма-
шин. В действительности в BIOS существует несколько уровней кода один
для самого компьютера, другой для видеоплаты и еще один для SCSI-адаптера,
если таковой имеется.
Встроенный код BIOS знает о некоторых устройствах, расположенных на
материнской плате, в частности о контроллере IDE (и жестких дисках),
клавиатуре, последовательных и параллельных портах. A SCSI-адаптеры
распознают только те устройства, которые подключены непосредственно к
ним. Выявление конфликтов между различными уровнями BIOS может стать
настоящим кошмаром Сложнее всего понять то. как происходит выбор
устройства, с которого должна быть произведена загрузка.
Процесс загрузки ПК
В современных компьютерах BIOS-программы "умнее", чем раньше Они
позволяют на этапе загрузки входить в режим конфигурирования, удерживая
нажатой одну или две клавиши. Как правило, названия этих клавиш
отображаются на экране, чтобы их не нужно было искать в документации.
В режиме конфигурирования можно выбрать, с какого устройства
требуется производить загрузку. Как правило, это дисковод для гибких дисков,
первый IDE-дисковод CD-ROM или первый жесткий диск IDE. Нам бы
хотелось объяснить вам, как все работает, но, к сожалению, это невозможно,
так как данная стадия процесса загрузки находится под контролем произво-
дителей персональных компьютеров н их многочисленных BIOS-программ.
Глове 2. Зопуск и остонов системы
35
Они устанавливают свои собственные правила игры, которых приходится
придерживаться.
Когда компьютер определил, с какого устройства следует загружаться,
производится считывание первых 512-ти байтов с диска. Этот сегмент диска
известен как главная загрузочная запись (ГЗЗ). В ней содержится программа,
которая сообщает компьютеру о том, в каком разделе диска находится
программа вторичной загрузки (загрузчик ОС). Дополнительная информация
о разделах дисков на персональных компьютерах и главной загрузочной
записи приводится в главе 8.
Стандартная программа ГЗЗ дает компьютеру указание извлечь загрузчика
ОС из первого раздела диска. Linux и FreeBSD поддерживают более сложные
программы, которые знают, как работать с несколькими операционными
системами и ядрами.
Когда программа ГЗЗ находит раздел, с которого будет выполнена
загрузка, она пытается запустить загрузочную программу, связанную с этим
разделом. В случае успеха этой программе передаются полномочия по
дальнейшей загрузке ядра.
LILO: загрузчик Linux
Загрузчик LILO невероятно сложен и в то же время ужасно бестолков.
В нем поддерживается множество возможностей, отсутствующих у других
загрузчиков, но нет некоторых элементарных свойств.
Загрузчик LILO входит в состав практически всех дистрибутивов Linux,
включая Red Hat. При первой установке системы инсталляционные сценарии
создают копию LILO со стандартными параметрами загрузки. Как-то повлиять
на этот процесс нельзя. LILO не так уж необходим для загрузки Linux, но
это часть системы. Придется научиться ее любить...
LILO может быть установлен в главную загрузочную запись диска или в
загрузочную запись корневого раздела Linux. Конфигурирование и инсталля-
ция загрузчика осуществляется с помощью программы lilo. которая извлекает
параметры конфигурации из файла /etc/lilo.conf Чтобы изменить настройки
загрузчика, достаточно отредактировать этот файл и повторно запустить
програкгму lilo. Эту процедуру необходимо проделывать всякий раз при
изменении процесса загрузки — в частности, каждый раз. когда добавляется
новый загрузочный раздел или создается новое ядро.
Конфигурирование LILO
Ниже приведено содержимое файла lilo.conf для системы, в которой
имеется рабочее и резервное ядро-
boot=/dev/b.da	# помешаем загрузчик в ГЗЗ
root”/dev/hdal	# залаем корневой раздел
install-/boot/boot.b
map=/boot/map
delay-20	# 2-секундная задержка, дающая пользователю
возможность вмешаться
image-/vmlinuz	* загружаемое ядро
label-1inux	И метка ядра
read-only
image-Zvmlinuz-backup * резервное ядро
label=backup
read-only
36
Часть I Основы администрирования
Каждому возможному сценарию загрузки назначается метка. Введя метку
на этапе загрузки, можно сообщить модулю LILO о том, какой из сценариев
следует выбрать. Тот сценарий, который указан в файле lilo.conf первым,
выбирается по умолчанию.
В стандартном сценарии (метка linux) загружается файл /vmlinuz. Флаг
reaa-only указывает на то. что ядро монтирует свою файловую систему в
режиме “только чтение”. Этот флаг должен всегда присутствовать; стартовые
сценарии позаботятся о том, чтобы повторно смонтировать раздел в режиме
“чтение/запись", когда возникнет такая необходимость. Система сконфигу-
рирована таким образом, чтобы в случае неудачи загрузить резервное ядро
(файл /vmllnuz-backup). Подобная возможность является очень удобной.
Если запустить программу Шо без аргументов, она создаст и инсталлирует
загрузчика, сообщив о том, какие ядра доступны. Рядом с названием
основного ядра будет отображена звездочка. При наличии ошибок в файле
lilo.conf они не будут обнаружены до тех пор, пока процедура инсталляции
загрузчика не достигнет середины. Система окажется в переходном состоянии.
Не перезагружайте ее, пока программа Шо не завершится успешно. Чтобы не
попасть в подобную ситуацию, запускайте программу с опцией -t, которая
позволяет протестировать файл, ие выполняя инсталляцию. Если ошибок не
выявлено, можно переходить к процедуре инсталляции. Честно говоря,
непонятно, почему программа Шо не делает такую проверку автоматически.
В нашем случае результаты работы программы будут выглядеть так:
#	Шо
Added linux*
Added backup
При загрузке системы модуль LILO выдаст приглашение следующего
вида:
LILO:
После паузы длиной 2 секунды (параметр delay, равный 1. соответствует
1/10 секунды, а в рассматриваемом файле lilo.conf он равен 20) будет загружено
ядро /vmlinuz и смонтирован первый раздел первого IDE-диска в качестве
корневого раздела. Список сценариев загрузки можно просмотреть, нажав
клавишу <ТаЬ>:
LILO: <Tab>
linux backup
LILO:
Чтобы загрузить резервное ядро, введите его метку в строке приглашения.
Загрузчик FreeBSD
Модуль загрузки во FreeBSD прост и эффективен. Он разделен на две
части: одна находится в главной загрузочной записи, а вторая — в корневом
разделе FreeBSD. Обе части инсталлируются раздельно.
Первичный загрузчик инсталлируется с помошъю команды bootOcfg
Например, команда
#	bootOcfg -В /dev/wdO
помешает первую часть загрузчика в ГЗЗ первого IDE-диска системы. Здесь
практически ничего не нужно менять (а чаще всего это сделать просто
Глово 2. Зопуск и остонов системы
37
невозможно). В процессе загрузки модуль просматривает список доступных
дисков (извлекается из BIOS) и находит разделы, которые, по его мнению,
являются загрузочными. Перечень разделов отображается в виде небольшого
меню:
Fl FreeBSD
F2 Windows
Default: Fl
Дополнительную информацию о тонкой настройке первичного загрузчика
можно получить на странице интерактивного руководства, посвященной
программе bootOcfg.
Второй модуль непосредственно отвечает за загрузку FreeBSD и позволяет
пользователю передать ядру дополнительные параметры. Инсталляция модуля
осуществляется с помощью команды disklabel -В. Программа disklabel является
достаточно мошной: она обладает множеством опций и поддерживает почти
все дисковые накопители. Вот как она обычно вызывается:
#	disklabel -В /dev/wdOsl
Здесь вторичный загрузчик записывается в первый раздел первого
IDE-диска.
Параметры конфигурации вторичный загрузчик извлекает из следующих
файлов:
•	/boot/Ioader.conf
•	/boot/loader.coBf.local
•	/boot/defaults/loader.conf
Последний файл содержит стандартные установки загрузчика и не должен
никогда модифицироваться Все эти установки можно переопределить с
помощью файлов loader.conr и loader.conf.local. а также из командной строки
на этапе загрузки системы. Информацию о параметрах загрузчика вы можете
найти на страницах руководства boot(8) и loader(S).
Мультисистемная загрузка
Поскольку на одном персональном компьютере могут работать несколько
операционных систем, привычной является ситуация, когда компьютер
загружается в мультисистемном режиме. Чтобы добиться этого, необходимо
правильно сконфигурировать модуль загрузки, позволив ему распознать
имеющиеся на локальных дискггх операционные системы.
В каждом разделе диска может располагаться собственный вторичным
загрузчик, однако главная загрузочная запись только одна. Поэтому необхо-
димо решить, какой из загрузчиков будет главным. Как правило, выбор
диктуется особенностями имеющихся операционных систем. Если одной из
иих является Linux, то лучше всего в качестве главного загрузчика выбрать
L1LO. Исключение составляет случай, когда присутствует Windows NT/2000.
Загрузчик этой операционной системы всегда должен помешаться в ГЗЗ.
Проблемы при мультисистемном загрузке
Организация мультисистем ной загрузки может быть болезненным про-
цессом. Ниже излагается информация, которая позволит вам сберечь
множество нервных клеток.
38
Чость I. Основы ОДмИНИСТрИрОВОНИЯ
Когда на компьютере с мультисистемной загрузкой планируется устано-
вить одну из клиентских версий Windows (95. 98 или Me), это должно быть
сделано до того, как будут инсталлированы остальные системы. Данные
версии Windows слишком глупы и не предполагают, что на компьютере может
быть установлена какая-нибудь другая ОС. Они всегда занимают первый
рззлел первого диска, перезаписывая в процессе инсталляции существующие
программы загрузки.
Аналогичное правило применяется в отношении Windows NT/2000.
Windows всегда инсталлируется первой. Причины этого могут быть разными,
ио результат всегда один. Загрузчик NT/2000 очень хочет инсталлировать
себя в главную загрузочную запись и быть Самым Главным. Сопротивление
бесполезно.
Чтобы заставить этого загрузчика распознавать разделы UNIX, необхо-
димо предварительно инсталлировать UNLX и загрузиться с дискеты или
компакт-диска. Затем нужно прочитать первые 512 байтов раздела UNIX
(загрузочный сектор раздела) и записать их в файл. Это можно сделать с
помощью команды dd. Вот пример ее использования в Linux:
*	dd if=/dev/hda2 of=linux.bin bs=512 count=l
Далее следует скопировать этот файл в раздел NT/2000 и добавить в файл
конфигурации загрузчика NT запись о том, как загружаться с использованием
данного файла. Все. что для этого требуется. — поместить в файл C:\boot.ini
строку с указанием пути к файлу и метки. В случае Linux эта строка будет
выглядеть так:
С:\linux.bin””Linux”
Дополнительную информацию о структуре файла boot.ini можно получить
в интерактивной базе знаний на Web-узле supporl.microsoft.com.
Если Linux и Windows NT/2000 сосуществуют вместе, загрузчик LILO
должен быть инсталлирован в раздел Linux, так как главная загрузочная
запись уже занята Для этого достаточно в файле lilo.conf поместить в параметр
boot ссылку на раздел Linux. Например, если ОС Linux инсталлирована на
втором разделе первого IDE-диска, строка будет иметь следующий вид:
boot=/dev/hda2
Это действие должно быть проделано до того, как вторичный загрузчик
будет записан в файл и скопирован в раздел NT. По сути, весь процесс
должен повторяться каждый раз, когда требуется повторный запуск програм-
мы lilo.
Мультисистемное конфигурирование LILO
Если LILO является главным загрузчиком (например, иа компьютере
установлены системы Linux и Windows 98), начните со стандартного процесса
конфигурирования LILO, описанного выше. Затем по мере необходимости
можно добавлять записи для других операционных систем в файл /etc/lilo.conf.
Вот как будет выглядеть запись, предназначенная для загрузки Windows
из первого раздела первого IDE-диска:
other = /dev/hdal
label = windows
table « /dev/hda
Глово 2. Зопуск и остонов системы
39
Ниже приведен полный текст файла Шо.совГ для случая, когда Windows
загружается из первого раздела, Linux — из второго, a FreeBSD — из третьего:
boot - /dev/hda	« помешаем загрузчик в ГЗЭ первого
IDE-лиска
delay * 20	* 2-секундная задержка, лапдая пользователю
возможность вмешаться
default - linux	# по умолчанию загружается Linux
из второго раздела
image • /boot/vmlinuz-2.3.41
root - /dev/hda2
label - linux
read-only
image - /dev/hdal	# загрузка Windows из первого раздела
label = windows
table • /dev/hda
image - 7dev/hda3	# загрузка FreeBSD из третьего раздела
label " freebsd
table = /dev/hda
После модификации файла lilo.conf программа lllo должна быть вызвана
повторно. Не забудьте предварительно выполнить ее в тестовом режиме с
ПОМОЩЬЮ ОПЦИИ -t.
Мультисистемное конфигурирование FreeBSD
Загрузчик FreeBSD всегда пытается автоматически обнаружить загрузоч-
ные разделы. Но можно самостоятельно сообщить ему о них, воспользовав-
шись опцией -т маска программы bootOcfg. Параметр маска содержит битовую
маску разделов, из которых требуется загружаться. Первый раздел представ-
ляется двоичным кодом 0001 (шестнадцатеричный эквивалент — 0x1), второй
раздел — кодом 0010 (эквивалент 0x2) и т.д. Например, команда
# bootOcfg -В -т 0x7
инсталлирует первичного загрузчика и сообщает ему о том. что разделы I.
2 и 3 являются загружаемыми (0x7=0111) В процессе загрузки на экране
отобразится меню с тремя элементами — по одному для каждого раздела.
2.3. Загрузка в однопользовательском режиме
В следующих параграфах описываются особенности однопользователь-
ской загрузки в каждой из тестовых операционных систем.
Solaris
Чтобы прервать процесс загрузки и войти в ПЗУ на компьютерах Sun.
. нажмите одновременно клавиши <L1> и <А>. На современных клавиатурах
Sun клавиша <L1> иногда обозначается как <STOP>. Перейдя в ПЗУ. введите
boot -s, для того чтобы продолжить загрузи}' в однопользовательском режиме.
Если в системе Solaris требуется загрузить альтернативное ядро, необхо-
димо задать полный пуль к устройству и файлу. Имя устройства — это
длинная загадочная строка, которую можно увидеть, выполнив команду Is -I
по отношению к соответствующему файлу /dev
% Is -1 Zdev/rdsk/cOtOdOsO
Irwxrwxrwx 1 root root	55 Jan 15 1998 Zaev/rdsk/cOtDdOsO
. . /. . /devices/sbus@lf,O/SUNW, fas(?e. 8BODOOO/sdGOf 0: a, raw
40
Чость I Основы ОДМИНИСТрирОВОНИЯ
Чтобы загрузить ядро, хранящееся на лиске в файле /kemel/backup, нужно
ввести следующую команду:
boot /devices/abusSIf,0/SUNW,fas0e,8800000/sd60,0:a,raw/karn«l/backup
В табл. 2.1 перечислен ряд полезных команд, которые можно вводить в
режиме конфигурирования ПЗУ на компьютерах Sun.
Тоблицо 2.1. Комонды конфигурирования ПЗУ для компьютеров Sun
Команда	Выполняемое действие
boot /луть_к_файлу_ядра	Загрузка альтернативного ядра
boot -1	Загрузка в однопользовательском режиме
boot -г	Псрекоифигурирование ядра и поиск новых устройств
boot -a /etc/iyitem.bak	Уведомление ядра о необходимости чтения файла /etc/iyatem.bak, а не /etc/eyitem
probe-ьсы	Выдача списка подключенных SCSI-устройств
HP-UX
Процедура однопользовательской загрузки на компьютере HP-UX зависит
от типа машины. Приведенные ниже сведения относятся к компьютеру
HP 9000/735.
После выдачи соответствующего сообщения прервите процесс загрузки.
Появится строка приглашения. Введите boot pri isl, чтобы отобразить
расширенную строку приглашения. Она будет выглядеть примерно так:
ISL> prompt;
Следующая команда выбирает требуемое ядро и загружает систему в
однопользовательском режиме:
ISL> prompt: hpux -is /stand/vmunix
Linux
Перейти в однопользовательский режим в Linux можно с помощью
загрузчика LILO В строке приглашения L1LO введите метку ядра, которое
требуется загрузить (задана в файле lllo.conf), а затем опцию -s или single.
Например, стандартное ядро, поставляемое в составе Red Hat, имеет метку
“linux”, поэтому, чтобы загрузиться в однопользовательском режиме, необ-
ходимо задать такую команду:
LILO: linux «ingle
Загрузчик LILO понимает различные опции командной строки (табл. 2.2).
Таблица 2.2. Примеры опций зогрузчико LILO
Опция	позноченис
root-Zdev/foo	Сообщает ядру о том, что корневым является устройство /dev/foo
single init-/sbin/init ether-0,о,ethl	Задает режим однопользовательской загрузки Сообщает ядру путь к программе inlt Заставляет ядро осуществить поиск адаптера Ethernet
Главе 2. Запуск и остонов системы
41
В однопользовательском режиме система Red Наг особенно чувствительна
к ошибкам. Прежде чем войти в этот режим. Red Hat пытается выполнить
команду fsck и смонтировать все локальные файловые системы, причем
практически ни одна из системных команд не компонуется статически Если
в результате ошибок монтирования нужные библиотеки функций оказались
не подключенными, динамически компонуемые команды не будут выпол-
няться. Даже базовые команды манипулирования файлами, сетевые утилиты
и текстовые редакторы требуют наличия совместно используемых библиотек
функций.
По этой причине работать в однопользовательском режиме в Red Hat, в
общем-то. бессмысленно. Необходимо будет всегда держать под рукой
спасательную загрузочную дискету. Обычно для решения незначительных
проблем удобнее загружаться в режиме подтверждения или непосредственно
со спасательной дискеты.
FreeBSD
Чтобы перейти в однопользовательский режим, прежде всего выберите
FreeBSD из меню первичного загрузчика:
Fl FreeBSD
Default: Fl
Затем, получив соответствующее приглашение, прервите процесс загрузки
и введите boot -s:
Hit [Enter] to boot immediately, or any other key for the command
prompt.
Booting [kernel] in 9 seconds...
<Пробел>
Type ‘?’ for a list of commands, 'help' for more detailed help.
disklsla:> boot -a
Система продолжит загрузку до того момента, когда потребуется ввести
путь к командному интерпретатору. Если нажать <Enier>, будет вызван
интерпретатор /bin/sh
Вторичный загрузчик понимает различные опции командной строки.
Например, чтобы найти и загрузить альтернативное ядро, выполните следую-
щую последовательность команд:
disklsia:> is
d var
d stand
d etc
kernel.SYNACK
kernel.LMC
kernel
disklsla:> unload
disklsla:> load kernel.SYNACK
disklsla:> boot
Здесь демонстрируется, как оператор получает список файлов корневом
файловой системы, выгружает стандартное ядро (/kernel), загружает новое
ядро (/kemcl.SYNACK) и продолжает процесс загрузки.
42
Чость I. Основы одминистрировонмя
2 4 Стартовые сценарии
После выхода из интерактивного режима (или при автоматической
загрузке, когда завершает работу командный интерпретатор, запущенный с
правами пользователя root) программа init выполняет сценарии запуска
системы. Они являются сценариями интерпретатора Bourne shell (sh), а их
точное местоположение и содержимое зависят от системы.
Наиболее широко распространены два способа организации работы со
стартовыми сценариями, уходящие корнями в историю. В BSD-системах эти
файлы хранятся в каталоге /etc и их имена начинаются с префикса "гс”.
В системах семейства System V файлы сценариев располагаются в каталоге
/etc/init.d, а ссылки на них созданы в каталогах /etc/rcO.d, /ete/гсLd и т.д
Второй вариант организации является более четким и позволяет аккуратнее
выполнять останов системы
Ниже приведен перечень задач, которые часто выполняются инициал и-
зационными сценариями:
•	задание имени компьютера;
•	установка часового пояса;
•	проверка дисков с помощью команды fsck (только в автоматическом
режиме);
•	монтирование системных дисков,
•	удаление файлов из каталога /tinp;
•	конфигурирование сетевых плат;
•	запуск процессов-демонов и сетевых служб
Большинство стартовых сценариев выводит на консоль подробную
информацию о выполняемых ими задачах. Это может оказать существенную
помощь при отладке или поиске причин зависания в процессе начальной
загрузки.
В старых системах нередко приходилось модифицировать стартовые
сценарии, чтобы настроить их для конкретной среды. Сегодня сценарии,
поставляемые разработчиком системы, должны быть достаточно общими,
чтобы работать в системах любой конфигурации. Сведения о локальной
конфигурации системы не задаются в самом сценарии, а помещаются в
отдельный файл (или набор файлов). Конфигурационные файлы, как правило,
представляю! собой небольшие сценарии Bourne shell, включаемые в старто-
вые сценарии для получения доступа к некоторым переменным командного
интерпретатора.
Стартовые сценарии в системах семейства System V
Сегодня сценарии в стиле System V наиболее распространены. Они
используются в трех из четырех рассматриваемых нами операционных систем.
Мы в первую очередь опишем общие принципы запуска системы, а затем
перейдем к анализу особенностей конкретных ОС.
В системах семейства System V программа init определяет 7 “уровней вы-
полнения”. на каждом из которых должен выполняться конкретный набор
системных сервисов
•	Уровень 0 говорит о том. что система полностью прекратила работу.
•	Уровень I или S означает однопользовательский режим.
•	Уровни 2—5 предназначены для многопользовательского режима.
•	Уровень 6 определяет этап перезагрузки системы.
Глово 2. Зопуск и останов системы
43
Уровни 0 и 6 отличаются тем. что система в действительности не может
в них оставаться. Переход на эти уровни означает, что система либо завершает
работу, либо перезагружается. В многопользовательском режиме чаше всего
установлен уровень выполнения 2 или 3; уровни 4 и 5 используются редко.
Уровни 1 и S различны для каждой системы.
Однопользовательскому режиму традиционно соответствует уровень 1. На
этом уровне запрещены все многопользовательские сеансы и процессы
удаленной регистрации, а в системе выполняется минимальный набор
программ. Поскольку в данном режиме доступ к системе осуществляется с
правами пользователя root, администраторам необходимо, чтобы при загрузке
в таком режиме система выдавала приглашение на ввод пароля. Для этой
цели предназначен уровень S: в нем создается отдельный процесс, выдающий
требуемое приглашение на экран. В Solaris уровень S является вполне
самостоятельным, но в Linux он носит переходный характер и завершается
сразу после ввода пароля.
Создается впечатление, что уровней выполнения больше, чем нужно.
Обычно это объясняется тем, что в телефонном коммутаторе 7 уровней,
поэтому в UNIX-системе должно быть как минимум столько же. В Red Hat
поддерживается до 10-ти уровней„ хотя уровни 7—9 не определены.
В файле /etc/inittab содержатся параметры, определяющие, что должна
делать программа init на каждом из уровней. Формат файла зависит от
системы, но основная идея состоит в том, что в нем задаются команды,
которые должны быть выполнены (или продолжать выполняться), когда
система переходит на конкретный уровень.
В процессе загрузки программа Init последовательно продвигается от
уровня 0 к уровню, заданному по умолчанию в файле /etc/inittab. Чтобы
осуществить переход между соседними уровнями, программа init выполняет
Команды из этого файла. Аналогичные действия производятся в обратном
порядке при останове системы.
К сожалению, структура файла /etc/lnittab довольно сложна и не всегда
согласуется с тем, как на самом деле происходит запуск и останов сервисов
в UNIX-системах. Чтобы сделать этот файл более полезным, многие системы
семейства System V реализуют дополнительный, абстрактный уровень. Он
обычно представлен в виде команды, которая запускается из файла /etc/inittab
и осуществляет смену уровней. На этом уровне выполняются сценарии из
каталога, зависящего от целевого уровня; они переводят систему в новое
состояние.
Системным администраторам обычно нет необходимости работать непо-
средственно с файлом /etc/lnittab, так как существующие сценарии подходят
для большинства случаев. Далее в главе мы не будем упоминать этот файл
и все те механизмы, которые связывают программу inlt со стартовыми
сценариями. Просто когда мы говорим о том, что программа Init выполняет
такой-то сценарий, нужно понимать: связь со сценарием может быть
косвенной.
Основные копии стартовых сценариев хранятся в каталоге init.d. Он, в
свою очередь, может располагаться в каталоге /etc. но это не всегда так.
Каждый сценарий отвечает за запуск одного демона или определенной
подсистемы. Сценариям можно передавать аргументы start и тор, которые
означают, что соответствующий сервис должен быть либо запущен, либо
остановлен. Большинство сценариев понимают также аргумент restart,
который эквивалентен связке stop+start. Обладая правами системного
администратора, можно вручную запускать или останавливать отдельные
сервисы, вызывая нужный сценарий из каталога init.d и передавая ему
требуемый аргумент.
44
Чость I. Основы ОДМИНИСТрИрОБОНИЯ
Ниже показан простой сценарий, позволяющий запускать, останавливать
или перезапускать демон sshd:
#! Zbin/sh
test -f /usr/localZsbinZsshd I I exit 0
case "$1" in
start}
echo -n "Starting sshd: sshd”
/usr/local/sbin/sshd
echo ”."
stop)
echo -n "Stopping sshd: sshd"
kill ’cat /var/run/sshd.pid’
echo
restart)
echo -n "Stopping sshd: sshd"
kill cat Zvar/run/sshd.pid
echo "."
echo -n "Starting sshd: sshd"
/usr/local/sbin/sshd
echo "."
-)
echo "Usage: /etc/init.d/sshd start I stop I restart"
exit 1
esac
Чтобы перейти на требуемый уровень, программа init должна получить
дополнительную информацию о том, какие сценарии и с какими аргументами
запускать. Но она не просматривает непосредственно каталог init.d, а
обращается к каталогу гсуровень.ф где уровень — это номер требуемого уровня
выполнения, к которому осуществляется переход (rcO.d. rcl.d и т.д.).
В каталогах гсуровень.Д обычно содержатся символические ссылки на
сценарии в каталоге init.d. Имена ссылок начинаются с префикса S или К.
за которым идет номер и имя сервиса, управляемого сценарием (например.
S34named). Если программа init переходит к более высокому уровню, она
выполняет все сценарии с префиксом s (“start” — запуск) в порядке
возрастания номеров, причем каждому сценарию передается аргумент start.
Когда осуществляется переход к более низкому уровню, запускаются сценарии
с префиксом К (“kill" — уничтожить) в порядке убывания номеров, и всем
им передается аргумент stop. В зависимости от системы, программа init
может просматривать только каталог гсуровень-d, относящийся к целевому
уровню, либо все каталоги иа пути от исходного к целевому уровню.
Чтобы сообщить системе, когда следует запускать тот или иной демон,
необходимо создать символическую ссылку в соответствующем каталоге.
В большинстве систем основная часть сетевых демонов запускается на
уровне 2. Следующие команды информируют систему о том. что демон sshd
должен быть запущен на уровне 2 и остановлен при завершении работы
системы:
* In -• /«tc/init.d/eshd /etc/rc2.d/S99s*h2
I In -s /etc/init.d/eshd /etc/rcO.d/K25sah2
Глово 2. Зопуск и останов системы
45
Первая ссылка говорит о том, что сценарий /etc/init.d/sshd следует
запустить в самом конце этапа перехода на уровень 2 и передать ему аргумент
start. Вторая ссылка сообщает, что в процессе завершения работы системы
сценарий /etc/init.d/sshd должен быть запушен относительно рано, причем с
аргументом stop. В некоторых системах процессы останова и перезагрузки
трактуются по-разному, поэтому необходимо также поместить символическую
ссылку в каталог /etc/rc6.d. чтобы обеспечить корректный останов демона
при перезагрузке системы.
Solaris
Системы Solaris. HP-UX и Red Hal используют сценарии в стиле
System V. которые хранятся в каталоге init.d. В Solaris этот каталог, как и
каталоги гсуровень.й. находится в каталоге /etc.
Раньше стартовые сценарии Solaris обращались к конфигурационным
файлам, разбросанным по всей системе, что приводило к невообразимом
путанице. В последних версиях системы компания Sun устранила большин-
ство проблем. Стартовые сценарии теперь значительно улучшены и большей
частью самодостаточны.
Некоторые конфигурационные файлы собраны в каталоге /etc/defaults
(табл. 2.3), однако общее число настраиваемых параметров не так уж велико.
Остальные файлы по-прежнему распределены между различными каталогами.
Таблица 2.3. Конфигурационные файлы стартовых сценариев Solaris
Файл	Нозначение
/etc/.UNCONFIGURED	Сообщает стартовым сценариям о необходимости пол- ностью переконфигурировать систему (обычно исполь- зуется только в процессе инсталляции)
/etc/hostname.uwne/i^euc	Содержит имя узла, связанное с указанным сетевым интерфейсом (сетевой платой)
/etc/dhcf.интерфейс	Сообщает о том. что сетевой интерфейс должен быть сконфигурирован с помощью протокола DHCP
/etc/defaultr outer	Содержит имя узла и адрес стандартного шлюза
HP-UX
В HP-UX стартовые сценарии хранятся в каталоге /sbin/init.d. Каталоги
символических ссылок также находятся в каталоге /sbin. Конфигурационные
файлы размещаются в каталоге /etc/rc.config.d. Их имена соответствуют
именам стартовых сценариев. Например, сценарий
/sbin/iniL.d/SnmpMaster
извлекает конфигурационную информацию из файла
/etc/rc.config.d/SnmpMaster
и вызывается программой init с помощью таких ссылок:
/sbin/rc2. d/S560SnrnpMaster
/sbin/rcl.d/K440SnmpMaster
Результаты работы стартовых сценариев сохраняются п файле /etc/rc.log.
Если какой-то из сценариев не смог выполниться, просмотрите этот файл
46
Чость I Основы одминистрироеония
на предмет наличия сообщений об ошибках или другой информации,
позволяющей выявить суть проблемы. Это настолько полезная и несложная
в реализации особенность, что просто удивительно, почему поставщики
других систем не догадались сделать нечто подобное.
Конфигурационные файлы могут быть сложны для понимания, хотя они
снабжены хорошими комментариями. В табл. 2.4 описано назначение файлов,
которые модифицируются чаще других.
Таблица 2.4, Канфигуроционные файлы HP-UX (каталог /etc/rc.conflg.d)	
Фойл(ы)	Назначение
SnmpMaster	Включает или отключает поддержку протокола SNMP
Scrap*	Другие параметры, связанные с протоколом SNMP
acct	Включает или отключает подсистему учета процессов, см. acct(IM)
auditing	Управляет работой подсистемы аудита; см. audsys(lM) и aude- vent(lM)
cde	Содержит настройки CDE (Common Desktop Environment — единая настольная среда)
clean*	Управляет операциями очистки, выполняемыми на этапе загрузки
desktop	Определяет, какой из имеющихся рабочих столов будет аыбран по умолчанию
hpbaselOOconf	Конфигурирует устройства Fast Ethernet
hpetherconf	Конфигурирует Ethernet-платы; см. lanadmin(IM)
listmode	Управляет отображением меню стартовой загрузки
Ip	Включает или отключает подсистему буферизации печати
rnailser¥5	Запускает утилиту sendmail или задает почтовый сервер
nameservj.	Конфигурирует или запускает демон службы имен
nddconf	Задает параметры ядра, устанавливаемые на этапе загрузки с помощью демона ndd
netconf	Задает параметры конфигурации сети (IP-адрес и т.п.)
netdaemons	Указывает на то. какие сетевые демоны следует запустить
nettl	Конфигурирует подсистемы сетевой трассировки и регистрации; см. nettl(lM), nettlconfflM) и nettlgen.c(»r(4)
nfsconf	Задает параметры NFS (Network File System — сетевая файловая система)
pd	Конфигурирует сервис распределенной печати HP-UX
Yt	Запускает демои vtdaemon
xfs	Включает и отключает сервис шрифтов X Windows
Для большинства этих файлов вполне подходят стандартные установки.
Чаще всего модифицируются файлы netconf, netdaemons и, возможно, nddconf.
Red Hat
Стартовые сценарии — это то, что отличает дистрибутивы Linux друг от
друга. Напрнмер, сценарии Debian очень напоминают сценарии Solaris, а
сценарии Slackware сходны со своими “родственниками” во FreeBSD В Red
Hat используются гибридные сценарии, сочетающие в себе черты сценариев
Слово 2. Запуск и останов системы
47
System V и FreeBSD плюс еше несколько “наворотов”, добавленных только
для того, чтобы сделать жизнь администраторов сложнее.
В сценариях Red Hat достаточно сложно разобраться, так как в них могут
присутствовать комментарии вида
# дурацкий прием, но должен раОотать
ИЛИ
♦ это неправильно!
Программа init в Red Hat в основном соответствует своему аналогу в
System V. На каждом уровне выполнения программа вызывает сценарий
/etc/rc.d/rc, передавая ему номер уровня в качестве аргумента. Этот сценарий
может выполняться как в обычном режиме, так и в режиме подтверждения,
в котором перед выполнением каждого стартового сценария выдается запрос.
Управлять символическими ссылками на стартовые сценарии можно с
помощью команды chkconfig.
В Red Hat имеется также сценарий rc.local, напоминающий одноименный
сценарий во FreeBSD. В процессе загрузки он выполняется последним. Не
стоит добавлять в него собственные команды; лучше воспользоваться
средствами System V.
Вот пример сеанса загрузки в Red Hat:
[информация о ядре]
INIT; version 2.77 booting
Welcome to Red Hat Linux
Press 'I' to enter interactive startup.
Mounting proc filesystem	l OK ]
Setting clock (utc): Fri Mar 10 07:16:41 MST 2000	( OK ]
Loading default keymap	[ OK ]
Activating swap partitions	[ OK ]
Когда появится сообщение “Welcome to Red Hat Linux”, можно нажать
клавишу <I>, чтобы продолжить загрузку в режиме подтверждения. Однако
подтверждение о нажатии самой клавиши выдано не будет. Red Hat спокойно
продолжит монтировать локальные файловые системы, активизировать раз-
делы диска подкачки, загружать таблицы клавиш и вести поиск модулей ядра.
Только после перехода на уровень 3 программа init начнет выдавать запросы:
Welcome to Red Hat Linux
Press ’I’ to enter interactive startup.
Mounting proc fileeystem	[ OK ]
Setting clock (utc): Fri Mar 10 07:16:41 MST 2000	[ OK ]
Loading default keymap	[ OK ]
Activating swap partitions	[ OK ]
Setting hostname redhat.synack.net [ OK ]
Checking root filesystem
/dev/hdal: clean, 73355/191616 files, 214536/3B3032 blocks (	OK	]
Remounting root filesystem in read-write mode	[	OK	]
Finding module dependencies	[	Ok	]
Checking filesystems	[	OK	]
Mounting local filesystems	[	OK	]
Turning on user and group quotas for local filesystems	[	OK	]
Enabling swap space	[	OK	]
INIT: Entering runlevel; 3
48
Чость I. Основы одминистрировония
Entering interactive startup
Start service kudzu (Y)es/(N)о/(C)ontinue? [Y]
Режимы интерактивной и однопользовательской загрузки начинаются с
одного и того же места. Если в процессе загрузки возникли серьезные
проблемы и этой точки достичь невозможно, воспользуйтесь спасательной
загрузочной дискетой.
Можно передать загрузчику LILO параметр inlt»/bin/sh, чтобы
заставить его вызвать командный интерпретатор однопользовательского
режима еше до того, как будет запущена программа init'. В этом случае все
действия по запуску системы придется производить вручную, включая
выполнение программы Гаск и монтирование локальных файловых систем.
Повлиять на процесс загрузки в Red Hat можно путем модификации
конфигурационных файлов, расположенных в каталоге /etc/sysconfig. Прин-
ципы работы с ними такие же, как и с файлами в каталоге /etc/rc.config.d
в HP-UX, хотя самих файлов меньше, а опций в них больше (табл. 2.5).
Тоблица 2.5. Фойлы и подкотологи котолого /etc/sysconfig в Red Hot
Фойл/подкотолог	H.. значение, или cojejXMMoe
арин!	Список аргументов для демона подсистемы АРМ (Advanced Power Management — расширенное управление питанием)
dock	Задает тип системных часов (почти всегда СТС)
console	Загадочный каталог, который всегда пуст
hwconf	Включает всю информацию о системном оборудовании; ис- пользуется сервисом Kudzu
il8n	Содержит региональные установки системы (формат представ- ления двты/времени, язык и т.д.)
bit	Определяет, как отображаются сообщения, поступающие от стартовых сценариев
keyboard	Задает тип клавиатуры (используйте идентификатор “us” для стандартной 101-клавишной клавиатуры )
monte	Задает тип мыши*, используется системой X Windows и программой gpm
network	Задает глобальные сетевые опции (имя узла, шлюз, маршрути- зация и тд.)
network-scripts	Каталог, в котором содержатся вспомогательные сценарии и сетевые конфигурационные файлы
pcmcia	Сообщает, следует ли запускать демоны PCMCIA, и содержит необходимые опции
Bsndmail	Задает параметры для утилиты sendmali
Некоторые элементы списка заслуживают дополнительных комментариев:
• Файл hwconf просматривается сервисом Kudzu, который проверяет, было
ли добавлено или удалено какое-нибудь устройство, и запрашивает у
пользователя дополнительные инструкции. В промышленных системах
Однажды в нашей системе был поврежден файл, содержащий таблицу клавиш, и поскольку
система Red Hat загружала этот файл даже в однопользовательском режиме, данный режим
оказался бесполезным. Передача загрузчику параметра init—'/bln/sh оказалась единственным
способом загрузить систему в безопасном состоянии и исправить ошибку.
Глово 2. Зопуск и остонов системы
49
этот сервис можно деактивировать, поскольку он сильно задерживает
процесс загрузки. Каждый раз, когда обнаруживается изменение аппа-
ратной конфигурации, возникает задержка в 30 с.
•	Каталог network-scripts содержит вспомогательные файлы, связанные с
сетевой конфигурацией. Все, что может потребоваться в нем изменить. —
это файлы с именами 1ГсГ£-цн/п£7?(/)ейс. Например, файл network-
scripts/ifcfg-ethO включает параметры платы с идентификатором ethO, в
частности ее IP-адрес. О конфигурировании сетевых плат рассказывается
в параграфе 13.10.
•	Файл sendmail содержит две переменные: DAEMON и QUEUE. Если пере-
менная DAEMON равна yes, система запустит утилиту sendmail в процессе
загрузки. Переменная QUEUE информирует утилиту sendmail о том,
сколько времени после возникновения ошибки сообщение должно
находиться в очереди, прежде чем будет предпринята попытка повторной
отправки_
FreeBSD
Представленная ниже информация касается FreeBSD, но общие принци-
пы организации стартовых сценариев применимы ко всем BSD-снстемам.
Программа init во FreeBSD выполняет только один, главный сценарий —
/etc/rc. Он, в свою очередь, запускает остальные сценарии, которые
расположены в каталоге /etc и носят имена вида гс.ция. Сценарии запускаются
в определенном порядке, а концепция уровней выполнения не поддержива-
ется.
Сценарий /etc/rc начинает свою работу с выполнения грех сценариев,
определяющих конфигурационную информацию:
•	/etc/defaults/rc-conf
•	/etc/гс.сопГ
е /etc/гс.conf.local
В этих файлах задаются другие каталоги, в которых необходимо искать
стартовые сценарии (имена каталогов заносятся в переменную local.star-
tup). Кроме того, в них определяется ряд переменных интерпретатора shell,
используемых последующими сценариями. Сценарий /etc/rc применяет
команду source (точнее, ее оригинальный псевдоним чтобы преобразовать
конфигурационные и все последующие сценарии в единый поток выполнения
Эта процедура включает в себя конкатенацию файлов в один большой
сценарий.
Файл /etc/defaults/rc.conf содержит огромный перечень всех конфигура-
ционных параметров и их стандартных значений. Его нельзя редактировать.
Если требуется изменить значение какой-либо переменной, просто переоп-
ределите ее в файлах /etc/rc.conf и /etc/rc.conf.local. На страницах интерак-
тивного руководства, посвященных файлу /etc/гс, приведен исчерпывающий
список переменных, которые можно менять.
Заглянув в каталог /etc, вы можете обнаружить в нем много различных
сценариев:
% 1н /etc/rc*
ГС	rc.disklessl	rc.isdn	rc.pccard
re.atm	rc.diskless2	rc.local	rc.resume
rc.conf	rc.firewall	rc.serial	rc.devfs
rc.i3B6	rc.network	rc.shutdown	rc.suspend
50
Часть I. Основы администрирования
Если ядро сконфигурировано как бездисковый клиент, в первую очередь
вызывается сценарий гс. diskless!. Затем вызываются сценарии rc.sysctl,
гс.serial, rc.pccard и re.network, после чего сценарий /etc/rc переходит к
выполнению служебных функций. В качестве завершающего аккорда запус-
кается сценарий rcJocal. Если какой-то сценарий не определен, он просто
пропускается (в приведенном выше списке сценарий rc.sysctl отсутствует).
Стандартный сценарий гс.serial ничего не делает, а лишь определяет набор
функций, которые позволяют инициализировать последовательные порты и
устройства на этапе загрузки.
Если в одном из файлов rc.conf задана поддержка интерфейсов
PCMCIA/CardBus, сценарий rc.pccard загружает модули ядра, связанные с
контроллером PCMCIA, и запускает демон pccardd, управляющий динамиче-
ским конфигурированием устройств PCMCIA по мере их подключения и
отключения.
Сценарий rc.network инициализирует сетевую среду компьютера. Он
использует переменные, определенные в файлах rc.conf, для конфигурирова-
ния сетевых интерфейсов, протоколов DHCP и РРР, маршрутизаторов и
брандмауэров. Редактировать этот сценарий нет необходимости, так как все
параметры содержатся в файлах rc.conf. Он вызывает другие сетевые стартовые
сценарии; rc.atm, rc.isdn и rc.firewall.
Для конфигурирования сетевого интерфейса во FreeBSD предназначены
три переменные: hostname, defaultrouter и if conf ±д_инт (где num —
имя интерфейсного устройства). Переменная if conf ig__unm должна содер-
жать строку опций, передаваемых команде ifcorifig при инициализации
устройства. Например, в строках сценария
hostname="my. fullyqualified.name'’
ifeonfig_deO"inet 192.168.1.2 netmask OxffffffDO"
defaultroute r="192.168.1.1''
узлу назначается IP-адрес 192.168.1.2 и задается стандартный адрес шлюза
192.168.1.1. Если данное интерфейсное устройство должно конфигурироваться
динамически по протоколу DHCP, задайте строку следующего вида:
ifconfig_deO=”DHCP"
Сервер DHCP автоматически назначит узлу IP-адрес, доменное имя и
маршрут по умолчанию.
2.5. Перезагрузка и останов системы
UNIX-системы хранят буферы изменений в памяти и лишь изредка
записывают их на диск. Это ускоряет выполнение операций дискового
ввода-вывода, но также делает систему более подверженной потерям данных
в случае внезапных зависаний.
Раньше UNIX-системы были очень щепетильны в отношении процедуры
выключения. Современные системы более терпимы, но все же по возмож-
ности лучше корректно завершать работу. Неправильное выключение системы
может привести к появлению труднообиаруживаемых, неочевидных ошибок,
а иногда и к полному краху.
Перезагрузка операционной системы на персональном компьютере —
средство решения почти всех проблем. Но при работе в UNIX советуем
сначала подумать и только потом перезагружаться. Проблемы, возникающие
в этой системе, как правило, скрытые и сложные, поэтому перезагрузка дает
Глово 2. Зопуск и остонов системы
51
ожидаемый результат гораздо реже, чем в других системах. Кроме того,
процесс перезагрузки UNIX занимает больше времени, что создает неудобства
для пользователей.
Перезагружаться необходимо в том случае, когда подключается новое
устройство или работающее устройство зависает так. что его невозможно
сбросить. Если модифицируется файл конфигурации, который используется
только при начальной загрузке, то изменения вступят в силу лишь после
перезагрузки. И наконец, если систему “заклинило” так. что в ней
невозможно зарегистрироваться, иного выхода, кроме как перезагрузиться,
просто не существует.
В отличие от начальной загрузки, которая осуществляется одни.м-един-
ственным способом, останов и перезагрузку системы можно выполнить
по-разному:
•	выключить питание;
•	дать команду shutdown,
•	использовать команды halt и reboot (в BSD-системах и Linux);
•	послать программе Init сигнал TERM,
•	изменить уровень выполнения программы init с помощью команды telinit
(в системах семейства System V);
•	уничтожить процесс init.
Выключение питания
Даже в небольших UNDCcHcreMax такой способ останова неприемлем.
Он может привести не только к потере данных и повреждению системных
файлов. Вы рискуете испортить дисковод, если он относится к числу тех, на
которых перед отключением питания необходимо установить в соответствую-
щее положение защитный переключатель либо произвести парковку головок.
В некоторых компьютерах (например, Hewlett-Packard) присутствует
кнопка программного останова, при нажатии которой выполняется ряд
команд, осуществляющих корректное завершение работы системы. Если вы
не уверены, поддерживает ли ваш компьютер такую возможность, не
нажимайте кнопку выключения питания в процессе работы системы. Будет
меньше проблем, если остановить систему вручную.
Конечно, в случае наводнения или пожара лучше отключить питание,
если вы не успеваете корректно остановить систему. В машинных залах и
сейчас иногда встречается аварийная кнопка, которая позволяет выключить
все оборудование одновременно.
Команда shutdown: корректный способ останова системы
Команда shutdown — самый безопасный и наиболее корректный способ
остановить или перезагрузить систему либо вернуться в однопользовательский
режим. К сожалению, трудно найти поставщика, который бы “не приложил
руку’’ к ее аргументам. Мы рассмотрим эту команду в обшем. а затем
приведем сводку синтаксиса и аргументов, которые пригодятся при работе в
какой-либо из описываемых систем.
Можно дать команде shutdown указание делать паузу перед остановом
системы. Во время ожидания команда посылает зарегистрированным поль-
зователям через постепенно укорачивающиеся промежутки времени сообще-
ния, предупреждая их о приближающемся останове. По умолчанию в
52
Чость I Основы одминистрировония
сообщениях говорится о том, что система заканчивает работу, и указывается
время, оставшееся до останова. При желании администратор может добавить
собственное короткое сообщение, в котором поясняется, почему система
останавливается и сколько примерно времени придется подождать, прежде
чем пользователи вновь смогут войти в систему.
Многие версии команды shutdown позволяют задать, что конкретно
должна сделать система: остановиться, перейти в однопользовательский
режим или перезагрузиться. Иногда можно также указать, необходимо ли
после перезагрузки проверить диски с помощью команды fsck. В современных
системах с большими дисками такая проверка займет много времени, поэтому
в общем случае ее можно не выполнять, если работа системы была перед
этим корректно завершена. В некоторых системах этап проверки дисков
автоматически пропускается, если файловые системы были правильно
демонтированы.
В табл. 2.6 перечислены аргументы командной строки команды shutdown
для шести рассматриваемых систем. Прочерк означает вариант по умолчанию.
Таблица 2.6. Многоликой комондо shirtdown						
Система	Путевое имя	Псузо	п1	о	В	Без fsck
Solaris	/usr/sbin/ahutdown	-{^секунды	-16	-10	-IS	-
HP-UX	/etc/shutdowD	секунды	-г	-ь	—	—
Red Hat	/bln/ihutdown	время	-г	-h	—	-f
FreeBSD	/abln/ehutdown	+минуты	-г	-h	—	—
1 П — перезагрузка, О — останов,		В — вход в однопользовательский режим.				
Комондо halt: более простой способ останова
Команда halt выполняет все основные операции, необходимые для
останова системы. Чтобы вызвать эту команду, можно в командной строке
указать shutdown -h или непосредственно halt. Команда halt регистрирует в
журнальном файле событие останова, уничтожает несущественные процессы,
выполняет команду sync (она, в свою очередь, осуществляет системный вызов
sync), дожидается завершения операций дисковой записи, а затем прекращает
работу ядра.
При указании команды halt -п системный вызов sync подавляется. Эта
команда используется после восстановления корневого раздела командой fsck0
чтобы ядро не могло затереть исправления старыми версиями раздела,
хранящимися в кэше. Команда halt -q инициирует почти немедленный
останов без синхронизации, уничтожения процессов и регистрации события.
Флаг -q используется редко.
Команда reboot: быстрый перезапуск
Команда reboot почти идентична команде halt. Разница заключается в
том, что система перезагружается, а не останавливается. Режим перезагрузки
вызывается также командой shutdown -г. Помимо этого, команда shutdown
поддерживает флаги -п и -q
Глово 2. Зопуск и останов системы
53
Передача программе init сигнала TERM
Результаты уничтожения программы init непредсказуемы и в большинстве
случаев очень вредны. Перед тем как посылать этой программе какой-либо
сигнал, обратитесь к документации. Когда BSD-версня программы init
получает сигнал TERM, она обычно уничтожает все пользовательские
процессы, демоны, процессы getty и переводит систему в однопользователь-
ский режим. То же самое делает команда shutdown.
Для того чтобы послать процессу сигнал, нужно с помошью команды ps
узнать идентификатор этого процесса. Программа init — это всегда процесс
номер один. С целью отправки сигнала воспользуйтесь командой kill:
#	вупс; вупс
*	kill -TZKM 1
Подробная информация о сигналах и команде kill приведена в главе
Комонда telinit: изменение уровня выполнения программы init
В системах, где программа init поддерживает несколько уровней выпол-
нения. можно с помощью команды telinit дать программе указание перейти
на конкретный уровень. Например, команда
<	telinit S
переводит систему в однопользовательский режим в Solaris и HP-UX В Red
Hat необходимо указать 1. а не S, иначе будет запущен интерпретатор shell
с правами пользователя root, а сам уровень изменен не будет:
«	telinit 1
То же самое можно сделать с помощью команды
и shutdown -il
которая, помимо всего прочего, может выдать предупреждающее сообщение
и сделать небольшую паузу перед переходом на новый уровень.
Команда telinit наиболее полезна при проверке изменений, внесенных в
файл ini tub. При наличии флага -q команда заставит программу init повторно
прочитать этот файл.
Уничтожение процесса init
Процесс init настолько важен для работы системы, что если его
уничтожить с помощью команды kill -KILL или kill -9. то большинство систем
автоматически перезагрузится (некоторые ядра при этом просто выдают
сообщение о панике — фатальной ошибке). Это очень “грубый” способ
перезагрузки. Лучше пользоваться командами shutdown и reboot
54
Честь I. Основы одминистрирования
Сило привилегий

Каждый файл и процесс в UNIX принадлежат определенному пользова-
телю. Не имея соответствующих привилегий, другие пользователи не могут
получить доступ к чужим объектам. Подобная схема позволяет защитить
пользователей друг от друга и предотвратить несанкционированный доступ,
случайный или злонамеренный.
Системными файлами и процессами владеет фиктивный пользователь
root, известный также как суперпользователь. Все его ресурсы надежно
защищены от вмешательства. Чтобы иметь возможность выполнять админи-
стративные задачи, необходимо зарегистрироваться в системе как суперполь-
зователь, о чем и пойдет речь в настоящей главе.
Суперпользователь обладает несколькими “волшебными” возможностями.
В частности, он имеет право выступать в роли владельца любого файла или
процесса и выполнять действия, недоступные рядовым пользователям.
Привилегированный пользователь — очень ответственная должность, а в
руках новичка или злоумышленника — очень опасная.
В этой главе рассматриваются основы привилегированного доступа к
системе. О том. как предотвратить несанкционированный доступ на уровне
суперпользователя, рассказывается в главе 21. В главе 27 описываются
политические и административные аспекты этого процесса.
3.1.	Владение файлами и процессами
Каждый файл в UNIX принадлежит владельцу и группе. Владелец файла
имеет только одну привилегию, которая другим пользователям системы
недоступна: ему разрешено изменять права доступа к файлу. В частности,
владелец может установить права доступа так, что никто, кроме него, не
сможет обращаться к данному файлу'. Мы еше вернемся к теме прав доступа
в главе 5.
Более того, можно сделать так, что файл станет недоступным даже для владельца.
Глово 3- Сило привилегий
55
Владелец файла — это всегда один человек. В группу могут входить
несколько пользователей. Сведения о группах хранятся в файле /etc/group.
Дополнительная информация о группах приведена в параграфе 6,1.
Владелец файла определяет, какие операции могут выполнять над файлом
члены группы. Такая схема допускает коллективное использование файлов
членами одной группы. Узнать о том. кому принадлежит файл, можно с
помощью команды Is -I имя_файла. Напрнмер:
% Is -1 /staff/scctt/todo
-tw------- 1 score staff 1258 Jun 4 18:15 /staff/scott/todo
Несложно заметить, что владельцем файла является пользователь “scott",
а группа, которой ои принадлежит, называется “staff".
UNIX отслеживает не символьные имена владельцев и групп, а их
идентификаторы. Идентификаторы пользователей (сокращенно UID — User
ID) и соответствующие им имена хранятся в файле /etc/passwdn а идентифи-
каторы и имена групп (GID — Group ID) — в файле /etc/group*. Символьные
эквиваленты присваиваются идентификаторам исключительно для удобства
пользователей системы. Чтобы команда вроде 1s могла вывести информацию
о принадлежности файла в удобочитаемом виде, она должна просмотреть
базу данных идентификаторов н найти в ней нужные имена.
Что касается процессов, то с ними связано не два, а четыре идентифи-
катора: реальный и эффективный пользовательский (UID), а также реальный
и эффективный групповой (GID). Реальные номера применяются для учета
использования системных ресурсов, а эффективные — для определения прав
доступа. Как правило, реальные и эффективные идентификаторы совпадают.
Владелец процесса может посылать ему сигналы (см. параграф 4.3), а также
понижать приоритет процесса.
В принципе, процесс нс может явно изменить ни одного из своих четырех
идентификаторов, но есть одна особая ситуация, когда происходит косвенная
установка новых эффективных идентификаторов Дело в том, что существуют
два специальных бита, устанавливаемых в маске прав доступа к файлу: SUID
(Set User ID — бит смены идентификатора пользователя) и SGID (Set Group
ID — бит смены идентификатора группы). Когда пользователь или процесс
запускает исполняемый файл, у которого установлен одни из этих битов,
файлу временно назначаются права его владельца или группы (в зависимости
от того, какой именно бнт задан). Таким образом, пользователь может даже
запускать файлы от имени суперпользователя.
Бит SUID позволяет обычным пользователям выполнять программы,
осуществляющие административные действия или обращающиеся к системе
на низком уровне. Это нс вызывает проблем безопасности, так как авторы
программ жестко регламентируют их работу. Например, команда passwd„ с
помощью которой пользователь меняет свой пароль, должна обращаться к
файлу /etc/passwd. принадлежащему суперпользователю. Вследствие этого у
нее установлен бит SUID. Она модифицирует файл строго определенным
образом и завершает работу. Конечно, даже столь простое действие может
стать причиной злоупотреблений, поэтому, прежде чем выполнять запраши-
ваемые изменения, команда passed проверяет, знает ли пользователь свой
текущий пароль.
В некоторых системах эта информация больше нс хранится в текстовом формате
(см главу 18)
56
Чость I. Основа одминистрировония
3.2.	Суперпользователь
Определяющей характеристикой учетной записи суперпользователя явля-
ется значение UID. равное 0. UNIX не запрещает менять имя этой учетной
записи или создавать другую запись с нулевым идентификатором, но такие
действия ни к чему хорошему не приведут. Их следствием будет возникно-
вение новых брешей в системе зашиты, а также растерянность других
пользователей, которым придется разбираться с особенностями конфигури-
рования такой системы.
UNIX позволяет привилегированному пользователю (т.е. всякому процес-
су, у которого эффективный идентификатор пользователя равен 0) выполнять
над файлом или процессом любую допустимую операцию . Кроме того,
некоторые системные вызовы (обращения к ядру) .может осуществлять только
суперпользователь. Вот примеры операций, доступных лишь суперпользова-
телю:
•	изменение корневого каталога процесса с помощью команды chroot.
•	создание файлов устройств;
•	установка системных часов;
•	увеличение лимитов использования ресурсов и повышение приоритете
процессов;
•	задание сетевого имени системы:
•	конфигурирование сетевых интерфейсов;
•	останов системы.
Процессы суперпользователя обладают способностью изменять свои
идентификаторы. Один из таких процессов — это программа login, которая
выдает приглашение ввести пароль при входе в систему. Если введенные
пароль и имя пользователя правильны, то программа заменяет свои
идентификаторы соответствующими идентификаторами указанного пользова-
теля и запускает интерпретатор команд. После юго как процесс суперполь-
зователя, изменив свою принадлежность, станет обычным пользовательским
процессом, восстановить свое предыдущее привилегированное состояние он
не сможет.
3.3.	Пароль суперпользователя
Пароль пользователя root должен состоять как минимум из восьми
символов; семисимвольные пароли взламываются достаточно легко. В не ко
торых системах задавать более длинный пароль не имеет смысла, потому что
обрабатываются только первые восемь символов.
Подробнее о взломе паролей читайте в главе 21
Пароль суперпользователя следует выбирать так. чтобы его нельзя было
определить методом перебора Теоретически наиболее безопасный пароль
состоит из случайной последовательности букв, знаков препинания и цифр
Такой пароль, однако, тяжело запомнить и, как правило, трудно вводить.
Поэтому, если системный администратор записывает пароль или вводит его
слишком медленно, об оптимальном уровне безопасности системы говорить
не приходится.
Ооратите внимание на слово ‘допустимую". Некоторые операции (например, запуск файла,
для которого нс установлен бит выполнения) запрещены даже суперпользователю.
Глово 3. Сила привилегий
57
До недавнего времени достаточно надежным и удобным для запоминания
считался пароль, состоящий из двух случайно выбранных слов, разделенных
знаком препинания, К сожалению, теперь такие пароли взламываются очень
быстро, н мы ие рекомендуем нх применять.
Сегодня наибольшее распространение получил подход, заключающийся
в выборе фразы по принципу “шокирующего абсурда”. Этот принцип был
определен Гради Уордом (Grady Ward) в ранней версии FAQ-документа,
посвященного выбору идентификационной фразы для PGP:
Принцип “шокирующего абсурда "заключается в составлении короткой фразы
(или предложения), которая лишена смысла и в то же время вызывает шок
у пользователя в данной культурной среде. То есть она должна содержать
совершенно неприличные или расистские высказывания либо состоять из
абсолютно не стыкующихся между собой выражений. Применять такой
подход не предосудительно, поскольку подразумевается, что пароль никогда
не станет известен людям, чьи чувства могут быть им оскорблены.
Маловероятно, чтобы подобный пароль был повторен кем-то еще, так как
он уникален по своей сути. При этом он легко запоминается, потому что
имеет яркую эмоциональную окраску. Сдержанный пример шокирующего
абсурда выглядит так: “Моллюски отгрызли мои гарцующие гениталии"
Любой читатель без труда придумает гораздо более шокирующие фразы.
Сократить фразу до восьми символов можно, записав только первые
буквы каждого слова или применив какое-нибудь другое легко запоминаю-
щееся преобразование. Безопасность пароля значительно возрастет,, если
включить в него цифры, знаки препинания и прописные буквы (некоторые
системы теперь этого требуют).
Пароль привилегированного пользователя следует менять:
•	минимум раз в три месяца;
•	каждый раз, когда кто-либо, знающий пароль, увольняется из вашей
организации;
•	когда, по вашему мнению, безопасность системы поставлена под угрозу;
•	если вы планируете провести вечер так бурно, что на следующее утро
рискуете не вспомнить пароль.
3.4.	Как стать суперпользователем
Поскольку пользователь root является таким же членом системы, как и
другие пользователи, можно войти в систему непосредственно под этим
именем. Однако оказывается, что это достаточно неудачное решение.
Во-первых, не будет сделано никаких записей о том. какие действия выполнял
суперпользователь. Согласитесь, не елншком-то приятно выяснить, что вчера
ночью в 3:00 вы сделали что-то не так, но никак не можете вспомнить, что
именно. Еще хуже, если такой доступ был неавторизованиым и необходимо
понять, какой ущерб системе нанес нарушитель. Во-вторых, сценарий
регистрации суперпользователя не предполагает сбора никакой другой
идентифицирующей информации. Когда под именем root в систему могут
входить несколько пользователей, не существует способа определить, кто из
них и когда это сделал.
По этим причинам в большинстве систем регистрация под именем root
запрещена на терминалах и по сети, т.е. везде, кроме системной консоли.
Мы рекомендуем придерживаться данного правила (см. параграф 21 6. в
58
Чость I. Основы одминистрировония
котором рассказывается, какие системные файлы потребуется для этого
отредактировать).
Команда su: замена идентификатора пользователя
Лучше воспользоваться командой su. Будучи вызванной без аргументов,
она выдаст приглашение на ввод пароля суперпользователя, а затем запустит
командный интерпретатор с правами пользователя root. Интерпретатор будет
выполняться в привилегированном режиме, пока не завершит работу (по
команде exit или при нажатии клавиш <Control-D>). Команда su не фиксирует
действия, выполняемые в среде интерпретатора, но добавляет запись в
журнальный файл, информирующую о том. кто и когда вошел в систему под
паролем суперпользователя.
Команда su способна также подставлять вместо имени root имена других
пользователей. Иногда единственный способ решить проблему пользова-
теля — войти с помощью команды su в его среду.
Зная чей-либо пароль, можно непосредственно зарегистрироваться в
системе под его именем, выполнив команду su имя_пользователя. В одних
системах пароль пользователя root позволяет регистрироваться с помощью
команд su или login под любым именем, а в других сначала нужно стать
суперпользователем, воспользовавшись командой su, а затем с помощью этой
же команды перейти в другую учетную запись.
Рекомендуем взять за правило прн вводе команды использовать полное
путевое имя, например /bin/su или /esr/bin/su, а не просто su. Это в какой-то
мере защитит вас от тех программ с именем su, которые преднамеренно были
прописаны в переменной PATH злоумышленником, намеревавшимся “со-
брать хороший урожай” паролей.
Во многих системах выполнять команду su имеют право только члены
группы wheel.
Программа sudo: ограниченный вариант команды su
Поскольку полномочия привилегированного пользователя распределить
нельзя, трудно предоставить кому-то право выполнять конкретную операцию
(например, создание резервных копий), не давая возможности свободной
работы в системе. Если же учетная запись root доступна целой группе
администраторов, то вы и понятия не будете иметь о том, кто ею пользуется
и что он при этом делает.
Предлагаемое нами решение заключается в использовании программы
sudo, которая в настоящее время распространяется Тоддом Миллером (он
является одним из соавторов настоящей книги). Программу можно получить
на Web-узле www.courtesan.com.
Программа sudo в качестве аргумента принимает командную строку,
которая подлежит выполнению с правами пользователя root (или другого
уполномоченного пользователя). Программа обращается к файлу /etc/sudoers,
содержащему список пользователей, имеющих разрешение на ее выполнение,
и перечень команд, которые они могут использовать на конкретной машине.
Если предлагаемая команда разрешена, программа sudo приглашает пользо-
вателя ввести его собственный пароль и выполняет команду от имени
суперпользователя.
До истечения пятиминутного периода бездействия (его продолжитель-
ность можно менять) программа sudo позволяет выполнять другие команды.
Глово 3. Сило привилегий
59
не вводя пароля. Такая мера — зашита от тех привилегированных пользова-
телей, которые бросают свои терминалы без присмотра.
Программа sudo ведет файл регистрации выполненных команд и вызвав-
ших их пользователей, а также каталогов, из которых запускались команды,
и времени их вызова. Эта информация может регистрироваться с помощью
системы syslog или размешаться в любом журнальном файле по усмотрению
пользователя. Мы рекомендуем направить ее на “безопасную" центральную
машину.
Строка файла регистрации, содержащая данные о пользователе randy,
который выполнил команду /bin/cet etc/sudoers, может выглядеть следующим
образом:
Dec 7 10:57:19 tigger sudo: randy: TTY-ttypO TTY-ttypO;
PWD“/tigger/users/randy; USER=root; COMMAND-/bin/cat /etc/audoers
Файл /etc/sudoers существует в единственном варианте и используется на
всех компьютерах. Ои выглядит примерно так:
#	Определяем псевдонимы для компьютерного и физического факультетов
Host_Alias CS " tigger, anchor, piper, moet, sigi
Host_Alias PHYSICS •= eprince, pprince, icarus
#	Определяем набор команд
Cmnd_Aiias DUMP - /usr/sbin/dump, /usr/sbin/restore
Cmnd_Alias PRINTING * /usr/sbin/lpc, /usr/sbin/lprm
Cmnd_Alias SHELLS - /bin/sh, /bin/tcsh, /bln/csh
#	Права доступа
mark, ed	PHYSICS =• ALL
herb	CS — /usr/local/bin/tcpdump : PHYSICS - (operator)
DUMP
lynda	ALL - (ALL) ALL, [SHELLS
%wheel	ALL, !PHYSICS - NOPASSWD: PRINTING
Первые пять незакомментнрованных строк определяют набор компьюте-
ров и команд, на которые осуществляются ссылки в спецификациях прав
доступа. Списки элементов можно включать в спецификации в полном виде,
но работать с псевдонимами проще, к тому же они делают файл sudoers
понятнее, и его легче будет обновлять в будущем. Разрешается также создавать
псевдонимы для различных групп пользователей.
В каждую спецификацию прав доступа включается следующая информация:
•	пользователи, к которым относится данная запись;
•	компьютеры, на которых пользователям разрешено выполнять какие-то
действия;
•	команды, которые могут выполняться пользователями;
•	пользователи, от имени которых могут выполняться команды.
Первая строка спецификаций применяется к пользователям mark и ed.
регистрирующимся в системе на компьютерах группы PHYSICS (eprince,
pprince и Icarus). Встроенный псевдоним ALL разрешает им выполнять любые
команды. Поскольку дополнительный список пользователей в скобках не
указан, программа sudo будет выполнять команды только от имени пользо-
вателя root.
Пользователь herb может выполнять команду' tepdump на машинах группы
CS, а также команды оперативного контроля на компьютерах группы
60
Чость I. Основы одминистрировония
PHYSICS. Заметьте, однако, что вторая группа команд 8 данном случае будет
иметь привилегии не пользователя root, а пользователя operator. Реальная
команда, которую пришлось бы ввести пользователю herb, выглядит примерно
так;
% sudo -u operator /usr/abin/dump Ou /d®v/rsdOa
Пользователь lynda имеет право выполнять команды от имени любого
пользователя на любой машине, но не может запускать некоторые распро-
страненные командные интерпретаторы. Означает ли это. что она не может
запустить интерпретатор, будучи суперпользователем? Конечно, нет:
4 ср -р /Ып/csh /tnp/csh
% sudo /txnp/cah
Вообще говоря, попытка разрешить “все команды, кроме...” обречена на
провал, по крайней мере с технической точки зрения. Тем не менее, имеет
смысл создавать файл sudoers в таком виде, так как это послужит хотя бы
напоминанием о том, что вызывать командный интерпретатор в режиме
суперпользователя не рекомендуется, и предотвратит случайные попытки вызова
В последней строке пользователям UNIX-группы wheel разрешается
выполнять команды печати 1рс и Iprm от имени суперпользователя на всех
компьютерах, за исключением машин группы PHYSICS. Более того, от них
не требуется вводить пароль.
Обратите внимание на то, что команды в файле /etc/sudoers даются с
полными путевыми именами, чтобы пользователи не могли выполнять свои
собственные программы и сценарии от имени суперпользователя. Разрешается
также указывать допустимые аргументы для каждой команды. Вообще,
возможности файла sudoers очень велики, а показанный пример иллюстрирует
лишь основные из них.
Для модификации файла /etc/sudoers предназначена специальная команда
visudn. Она проверяет, не редактируется ли файл кем-то другим, затем
открывает его в редакторе, а перед инсталляцией файла выполняет синтак-
сический контроль. Последнее действие особенно важно, поскольку ошибка
в файле sudoers может не позволить повторно вызвать программу’ sudo для
ее исправления.
Использование программы sudo имеет следующие преимущества;
•	благодаря регистрации команд значительно повышается степень контроля
над системой;
•	операторы могут выполнять рутинные задачи, не имея неограниченных
привилегий;
•	настоящий пароль суперпользователя знают всего один-два человека;
•	вызывать программу sudo быстрее, чем выполнять команду su или входить
в систему под именем root;
•	у пользователя можно отобрать привилегии без изменения пароля
суперпользователя,
•	ведется список всех пользователей с правами пользователя root,
•	меньше вероятность того, что интерпретатор команд, запущенный
суперпользователем, приведет к не предсказуемым последствиям;
•	управлять доступом ко всей сети можно с помощью одного файла
Глово 3. Сило привилегий
61
У программы есть и свои недостатки. Самый большой из них заключается
в том. что любая брешь в системе безопасности того или иного привилеги-
рованного пользователя эквивалентна нарушению защиты самой учетной
записи root. Противостоять этому нелегко. Можно лишь предупредить тех,
кто имеет право выполнять программу sudo, о необходимости защищать свои
учетные записи так. как если бы они были суперпользователями.
Другой недостаток — это возможность обмануть программу sudo с
помощью таких уловок, как временный выход в командный интерпретатор
из разрешенной программы или выполнение команд sudo csh нли sudo su.
если они допустимы.
3.5. Другие псевдопользователи
Пользователь с именем root — единственный, кто имеет для ядра UNIX
особый статус. Есть, однако, еще несколько неперсонифицнруемых регист-
рационных имен, которые используются для системных целей. Пароли этих
псевдопользователей в файле /etc/passwd обычно заменяют звездочкой, чтобы
нельзя было войти в систему под их именем.
Владелец непривилегированных системных программ:
daemon
Учетная запись daemon, как правило, имеет идентификатор пользователя,
равный 1. Файлы н процессы, которые должны принадлежать операционной
системе, а не конкретному пользователю, часто назначаются данной учетной
записи, а не пользователю root, чтобы уменьшить угрозу безопасности
системы. Имеется также UNIX-группа с именем daemon, которая создается
по аналогичным причинам.
Владелец системных команд: bin
В некоторых системах пользователь bin является владельцем большинства
системных команд, а также каталогов, в которых они хранятся. Назначение
отдельного пользователя для этих целей часто считается избыточным (и даже
небезопасным;, поэтому в современных системах соответствующую роль берет
на себя пользователь root.
Владелец образов ядра и памяти: sys
В некоторых системах пользователь sys владеет специальными файлами,
такими как /dev/kmem, /dev/mem и /dev/drum или /dev/swap, которые содержат
образы адресного пространства ядра, физической памяти системы и файла
подкачки соответственно. Доступ к этим файлам имеют лишь немногие
программы, и все они изменяют эффективный идентификатор пользователя
иа sys. Иногда вместо пользователя sys создается rpvnna kmcm или sys.
Общий сетевой пользователь: nobody
В большинстве версий UNIX определяется пользователь nobody с
идентификатором -1 или -2. Разработчики Solaris выбрали идентификатор
60001 (следующий идентификатор 60002 назначается специальному пользо-
вателю noaccess).
62
Чость I. Основы администрировония
Сетевая файловая система — NFS (Network File System) — использует
учетную запись nobody для представления суперпользователей в других
системах. Чтобы лишить суперпользователей их исключительных прав при
доступе к удаленным машинам, NFS должна заменить нулевой идентификатор
чем-то другим. Этой пели как раз и служит учетная запись nobody.
Дополнительная информация об учетной записи nobody приведена в параг-
рафе 17.1.
Пользователю nobody не нужны специальные права доступа, и он не
должен владеть никакими файлами. Сетевая файловая система использует
это средство для зашиты файловых серверов в сетях, где бездисковые клиенты
могут перезагружаться в однопользовательском режиме всеми, кто имеет
физический доступ к ним. С правами пользователя nobody работают и
некоторые демоны, например fingerd.
Идентификаторы пользователей — это короткие целые числа, следова-
тельно, значение -1 будет представлено как 32767. В алгоритмах определения
следующего доступного идентификатора, которые используются многими
программами adduser, это не учитывается.
Управление процессами
Процесс — это абстракция, применяемая в UNIX для описания
выполняющейся программы. Это системный объект, посредством которого
можно контролировать обращения программы к памяти, процессору и
ресурсам ввода-вывода.
Концепция, согласно которой как можно больше работы должно
выполняться в контексте процессов, а не в ядре, является частью философии
UNIX. Она пронизывает все системные команды UNIX Системные и
пользовательские процессы подчиняются одним и тем же правилам, благодаря
чему управление ими осуществляется с помощью одних и тех же команд.
4.1.	Компоненты процесса
Процесс состоит из адресного пространства и набора структур данных,
содержащихся внутри ядра Адресное пространство представляет собой
совокупность страниц памяти', которые ядро выделило для выполнения
процесса. В него загружается код процесса и используемые им библиотеки
функций, переменные, стек и различная вспомогательная информация,
необходимая ядру во время работы процесса. Поскольку в UNIX поддержи-
вается концепция виртуальной памяти, страницы адресного пространства
процесса в конкретный момент времени могут либо находиться в физической
памяти целиком или частично, либо вообще отсутствовать там.
В структура* данных ядра хранится различная информация о каждом
процессе. К наиболее важным сведениям относятся:
•	таблица распределения памяти процесса;
•	текущий статус процесса (неактивен, приостановлен, выполняется и т.п.);
•	приоритет выполнения процесса;
•	информация о ресурсах, которые используются процессом;
•	маска сигналов процесса (запись о том. какие сигналы блокируются):
’ Страницы — это базовые блоки памяти размером, как правило, от 1 до 8 Кб.
64
Чость I. Основы одминистрировония
•	идентификатор владельца процесса.
В традиционных UNIX-системах процесс также отслеживает. какие
инструкции центральный процессор выполняет от его имени, В ряде
современных систем код процесса может выполняться несколькими "процес-
сорами” (реальными или имитируемыми, в зависимости от конфигурации
системы). При этом информация о каждом контексте выполнения содержится
в объекте, называемом потоком.
Теоретически два потока могут управляться системным планировщиком
совершенно независимо, даже будучи частью одного процесса. На практике
библиотеке потоковых функций, распространяемая большинством поставщи-
ков, ие поддерживает такую возможность. Почти все задачи планирования
решаются на уровне процессов, поэтому многопотоковое программирование
ие особо заботит системных администраторов.
Многие характеристики процесса непосредственно влияют на его выпол-
нение. Имеет значение, сколько времени выделяется этому процессу цен-
тральным процессором, к каким файлам он имеет доступ и т.д, В следующих
параграфах мы рассмотрим наиболее интересные с точки зрения системного
администратора характеристики процессов. Они поддерживаются во всех
версиях UNIX.
Идентификатор процесса (PID)
Каждому новому процессу, созданному ядром, присваивается уникальный
идентификатор (Process ID, P1D). Большинство команд и системных вызовов,
работающих с процессами, требуют указания конкретного идентификатора,
чтобы был ясен контекст операции. Идентификационные номера присваива-
ются процессам по порядку по мере их создания. Когда номера заканчива-
ются, ядро сбрасывает счетчик в единицу и снова начинает присваивать их
по порядку, пропуская те идентификаторы, которые еше используются.
Идентификатор родительского процесса (PPID)
В UNIX нет системного вызова, который создавал бы новый процесс
для выполнения конкретной программы. Вместо этого существующий процесс
должен клонировать сам себя, чтобы породить новый процесс. Путь, по
которому осуществляется клон, может отличаться от пути выполнения
породившего его процесса.
Исходный процесс в терминологии UNIX называют родительским, а его
клон — порожденным или дочерним. Помимо собственного идентификатора,
каждый процесс имеет атрибут PPID (Parent Process ID), который равен
идентификатору родительского процесса, породившего данный процесс’.
Идентификатор пользователя (UID) и эффективный
идентификатор пользователя (EUID)
UID (User ID) — это идентификатор пользователя, создавшего данный
процесс, или, точнее, это копия значения EU1D родительского процесса.
Вносить изменения в процесс могут только его создатель (владелец) и
пользователь root.
По крайней мере, первоначально. Если родительский процесс по какой-то причине пре-
кращает работу, программа init (процесс номер 1) подставляет себя на место предка
(см. параграф 4.2).
Глобо 4. Упровлвние проивссоми
65
Детальная информация об идентификаторах пользователя приведена в па-
раграфе 6.1.
EUID (Effective User ID) — это “эффективный" пользовательский
идентификатор процесса. Он используется для того, чтобы определить, к
каким ресурсам и файлам у процесса есть право доступа в данный конкретный
момент. У большинства процессов значения UID и EUID будут одинаковыми
Исключение составляют программы с установленным битом смены иденти-
фикатора пользователя (SUID).
Зачем нужны два идентификатора? Просто потому, что имеет смысл
разграничить понятия персонификации и прав доступа. Программа, у которой
установлен бит SUID, не всегда хочет выполняться с расширенными
привилегиями. В большинстве систем значение EUID можно устанавливать
и сбрасывать, чтобы предоставить процессу дополнительные полномочия или
отобрать нх
Идентификатор группы (GID) и эффективный
идентификатор группы (EGID)
GID (Group ID) — это идентификатор группы, к которой относится
владелец процесса. Эффективный идентификатор группы (Effective Group ID.
EGID) связан с атрибутом G1D так же. как значение EUID — с UID Если
процесс попытается обратиться к файлу, который ему не принадлежит, ядро
автоматически проверит, можно ли предоставить процессу соответствующие
разрешения на основании эффективного идентификатора группы.
Дополнительную информацию о группах вы найдете в параграфе 6.1.
В некоторых системах процесс одновременно может относиться к
нескольким группам. В этом случае атрибуты GID и EGID представляют
собой списки идентификаторов групп. Если пользователь пытается получить
доступ к какому-либо ресурсу, весь список проверяется на предмет того,
принадлежит ли этот пользователь к группе, члены которой имеют право
использовать данный ресурс.
Приоритет и зночение nice
От приоритета процесса зависит, какую долю времени центрального
процессора он получит. Ядро применяет динамический алгоритм назначения
приоритетов, учитывающий, сколько времени центрального процессора уже
использовал процесс и сколько времени он ожидает своей очереди. Кроме
того, учитывается заданный административным путем так называемый фактор
уступчивости (устанавливается с помощью команды nice), определяющий, в
какой степени программа может “делиться" процессором с другими програм-
мами. Чем выше значение nice, тем “уступчивее” программа. Подробнее этот
механизм рассматривается в параграфе 4.6.
Упровляющий терминал
Большинство процессов имеют связанный с ними управляющим терми-
нал. Он определяет базовую конфигурацию стандартных каналов ввода,
вывода и ошибок. Когда пользователь вводит какую-либо команду в
интерпретаторе shell, его терминал, как правило, становится управляющим
66
Чость I Основы одминистрировония
терминалом процесса. От управляющего терминала также зависит распреде-
ление сигналов, о чем пойдет речь в параграфе 4.3.
4.2.	Жизненный цикл процесса
Для создания нового процесса существующим процесс клонирует самого
себя с помощью системного вызова fork Результатом является получение
копии исходного процесса, имеющей лишь некоторые отличия. В частности,
новому процессу присваивается новый идентификатор, и учет ресурсов
ведется для него независимо от предка.
Системный вызов fork обладает уникальным свойством: он возвращает
сразу два значения. В порожденном процессе эта функция возвращает 0. а
в родительском — идентификатор потомка. Поскольку в остальном процессы
идентичны, они должны проверять это значение, чтобы определить, в какой
роли следует выступать дальше.
После выполнения системного вызова fork новый процесс обычно
запускает новую программу с помощью одного из системных вызовов
семейства ехес* Все вызовы семейства ехес производят приблизительно
одинаковые действия: они замещают сегмент кода пронесся и устанавливают
сегменты данных и стека в исходное состояние. Формы вызовов ехес
отличаются только способами указания аргументов командной строки и
переменных среды, передаваемых новой программе.
Когда система загружается, ядро самостоятельно создает несколько
процессов. Наиболее важный из них — процесс init, идентификатор которого
всегда равен 1. Программа init отвечает за вызов командного интерпретатора
для выполнения стартовых сценариев, если они используются в системе. Все
процессы, кроме тех. что создаются ядром, являются потомками процесса init.
р| Подробная информация о начальной загрузке и демоне init приведена в главе 2.
Программа init играет и другую важную роль в управлении процессами.
Когда процесс завершается, он вызывает функцию _exit(). чтобы уведомить
ядро о своей готовности прекратить работу. В качестве параметра функции
_exit() передается код завершения — целое число, указывающее на причину
останова процесса. По соглашению нулевой код завершения означает, что
процесс окончился успешно.
В UNIX требуется, чтобы, прежде чем процесс окончательно исчезнет,
его удаление было подтверждено родительским процессом с помощью
системного вызова wait. Данная функция возвращает код завершения потомка
и. если требуется, статистику использования ресурсов. По этой причине ядро
должно хранить код завершения, пока родительский процесс не запросит его.
По окончании дочернего процесса его адресное пространство освобождается,
время центрального процессора ему не выделяется, однако в таблице
процессов ядра сохраняется запись о нем. Процесс в этом состоянии
называется зомби
Описанный механизм работает нормально, если родительским процесс
завершается позже порожденных им процессов и добросовестно выполняет
системные вызовы wait для того, чтобы все проиессы-зомбн были уничтоже-
ны Если же родительский процесс завершается первым, то ядро понимает,
что вызова wail не последует, и переназначает все процессы-зомбн программе
На самом деле все они. кроме одного, являются библиотечными функциями.
Глове 4. Упровпение процессоми
67
Init. Она обязана принять "осиротевшие" процессы и ликвидировать их.
осуществив для каждого из этих процессов вызов wait.
Раньше программа init не всегда выполняла свои обязанности как следует
и зомби оставались в системе. В последнее время, однако, подобных проблем
мы не замечали.
4.3.	Сигналы
Сигналы — это запросы иа прерывание на уровне процессов. В UNIX
определено свыше тридцати различных сигналов, и они находят самое разное
применение:
•	сигналы могут посылаться от одного процесса к другому как средство
межзадачного взаимодействия;
•	сигналы могут посылаться драйвером терминала для уничтожения или
приостанова процессов, когда пользователь нажимает специальные ком-
бинации клавиш, такие как <Conirol-C> и <Control-Z>';
•	сигналы могут посылаться пользователем или администратором с помо-
щью команды kill;
•	сигналы могут посылаться ядром, когда процесс выполняет нелегальную
инструкцию, например деление на ноль.
Когда поступает сигнал, возможен один из двух вариантов развития
событий. Если процесс назначил данному сигналу подпрограмму обработки,
то оиа вызывается, и ей предоставляется информация о контексте, в котором
был сгенерирован сигнал. В противном случае ядро выполняет от имени
процесса действия, определенные по умолчанию. Эти действия различны для
разных сигналов. Многие сигналы приводят к завершению работы процесса,
а в некоторых случаях при этом еще выполняется дамп оперативной памяти
0 Дамп памяти — это файл, содержащий образ памяти процесса; его можно
использовать для целей отладки.
Процедуру вызова обработчика называют перехватом сигнала. Когда
выполнение обработчика завершается, процесс возобновляется с той точки,
где был получеи сигнал.
Чтобы сигналы не поступали в программу, можно указать, что они
должны игнорироваться или блокироваться. Игнорируемый сигнал просто
пропускается и ие оказывает на процесс никакого влияния. Блокируемый
сигнал ставится в очередь на обработку, но ядро не требует от процесса
никаких действий до явиого разблокирования сигнала. Обработчик вызыва-
ется для разблокированного сигнала только одни раз, даже если в течение
периода блокировки поступило несколько таких сигналов.
В табл. 4.1 перечислены сигналы, представляющие интерес для систем-
ного администратора. Традиционно имена сигналов записываются пропис-
ными буквами. В программах на языке С к именам добавляется префикс
S1C (например, SIGHUP).
Функции, связанные с этими комбинациями клавиш, могут назначаться другим клавишам
с помощью команды stty, но иа практике такое случается очень редко. В этой главе мы
подразумеваем, что с данными клавишами связаны их стандартные функции. Дополнитель-
ную информацию можно получить в параграфе 7,!0.
68
Чосгъ I. Основы одминистрировония
Таблица 4.1. Сигналы, которые должны быть известны каждому администратору
No	Имя	Описоние	Реакция по умолчанию	Перехваты Блокируется? эоется?		Дамп памяти?
1	HUP	Отбой	Завершение	Да	Да	Нет
2	INI	Преры- вание	Завершение	Да	Да	Her
3	QUIT	Выход	Завершение	Да	Да	Да
9	KILL	Уничто- жение	Завершение	Нет	Нет	Нет
।	BUS	Ошибка на шине	Завершение	Да	Да	Да
	SEGV	Ошибка сегмен- тации	Завершение	Да	Да	Да
15	TERM	Програм- мное за- вершение	Завершение	Да	Да	Her
1	STOP	Останов	Останов	Нет	Нет	Нет
।	TSTP	Сигнал ос- танова, по- сылаемый с клавиатуры	Останов	Да	Да	Нет
	CONT	Продол- жение по- сле остано- ва	Игнорируется	Да	Нет	Нет
	WINCH	Изменение окна	Игнорируется	Да	Да	Hei
	USRI	Определя- ется поль- зователем	Завершение	Да	Да	Нет
।	USR2	Определя- ется поль- зователем	Завершение	Да	Да	Нет
В разных системах разный (см. файл /usr/include/aignal.h или раздел man signal
интерактивного руководства).
Имеются и другие сигналы, не показанные в табл. 4.1, большинство из
которых сообщает о всяких загадочных ошибках, например “неверная
инструкция”. По умолчанию такие сигналы, как правило, приводят к
завершению программы и созданию дампа памяти. Перехват и блокирование
обычно разрешены, так как есть достаточно “умные" программы, которые
всегда стараются устранять последствия возникающих ошибок.
Сигналы BUS и SEGV также посылаются в случае ошибок. Мы включили
их в таблицу, поскольку они чрезвычайно распространены: в 99% случаев
программа аварийно завершается именно из-за них. Сами по себе эти сигналы
не имеют диагностической ценности. Они лишь указывают на то, что была
произведена попытка неправильного обращения к памяти.
Большинство эмуляторов терминалов посылают сигнал WINCH, когда
происходит изменение их конфигурационных параметров (например, числа
линий на виртуальном терминале). Это позволяет программам, которые тесно
Глово 4 Упровпение процессами
69
связаны с терминалами (в основном текстовым редакторам), автоматически
переконфигурировать себя в ответ на изменения.
Сигналы KILL и STOP нельзя ни перехватить, ни блокировать, ни
проигнорировать. Сигнал KILL уничтожает процесс, которому он посылается,
а сигнал STOP приостанавливает выполнение процесса до получения сигнала
CONT. Сигнал CONT можно перехватить и проигнорировать, но нельзя
блокировать.
Сигнал TSTP представляет собой “облегченную" версию сигнала STOP.
Проще всего описать его как запрос на останов. Он генерируется драйвером
терминала при нажатии пользователем комбинации клавиш <Clri-Z>. Про-
граммы, обрабатывающие этот сигнал, обычно выполняют операции очистки,
а затем посылают сами себе сигнал STOP. С другой стороны, сигнал TSTP
можно просто проигнорировать, чтобы сделать программу невосприимчивой
к случайным нажатиям клавиш.
Может показаться, что сигналы KILL, INT, HUP, QUIT и TERM
означают одно и то же, но на самом деле они используются совершенно
по-разному:
•	Сигнал KILL не может блокироваться и приводит к безусловному
завершению процесса на уровне операционной системы. В действитель-
ности процесс не может принять этот сигнал, так как уничтожается
раньше.
•	Сигнал INT посылается драйвером терминала при нажатии пользователем
клавиш <Ctr1-C>. Он запрашивает завершение текущей операции.
Простые программы должны прекратить свою работу (если онн перехва-
тывают этот сигнал) илн позволить уничтожить себя стандартному
обработчику сигнала. Программы, в которых есть режим командной
строки, должны прервать текущую операцию, произвести очистку и снова
перейти в режим ожидания.
•	Сигнал TERM представляет собой запрос на полное завершение про-
граммы. Предполагается, что процесс, который получит этот сигнал,
произведет очистку и прекратит работу.
•	У сигнала HUP есть две распространенные интерпретации. Во-первых,
многие демоны понимают его как команду сброса Если демон способен
повторно прочитать свой конфигурационный файл и адаптироваться к
изменениям без перезапуска, сигнал HUP позволяет менять его поведе-
ние. Во-вторых, данный сигнал иногда генерируется драйвером терминала
при попытке “очистить” (т.е. удалить) процессы, связанные с конкретным
терминалом. Это происходит, например, при завершении сеанса работы
с терминалом или когда модем внезапно разрывает соединение (отсюда
название “hang-up" — отбой). Интерпретаторы семейства С shell (csh,
tcsh и др.) обычно делают фоновые процессы невосприимчивыми к
сигналу HUP, чтобы они могли продолжать свою работу, даже когда
пользователь выходит из системы, Пользователи интерпретаторов семей-
ства Boume shell (sh, ksh, bash) могут эмулировать данное поведение с
помощью команды nohup.
•	Сигнал QUIT напоминает сигнал TERM, ио отличается от него тем, что
по умолчанию стандартный обработчик создает дамп памяти.
Сигналы USRI и USR2 не имеют стандартного назначения. Ими можно
пользоваться в различных ситуациях. Например, демон named интерпретирует
их как запросы на выбор уровня отладки.
70
Чость I Основы ОДМИНИСТрИрОВОНИЯ
4.4.	Отправка сигналов: команда kill
Команду kill чаше всего используют для прекращения выполнения
процесса. Эта команда может послать процессу любой сигнал, но по
умолчанию это сигнал TERM (программное завершение). Команду kill могут
выполнять как обычные пользователи (для своих собственных процессов),
так и пользователь root (для любого процесса). Она имеет следующий
синтаксис:
kill I-сигнал] идентификатор
где сигнал — это номер или символическое имя посылаемого сигнала (см.
табл. 4.1), а идентификатор — это номер процесса-адресата. В некоторых
системах идентификатор -1 означает широковещательную передачу сигнала
всем процессам, кроме системных и текущего интерпретатора команд.
Команда kill без номера сигнала ие гарантирует, что процесс будет
уничтожен, потому что сигнал TERM можно перехватывать, блокировать и
игнорировать. Команда
kill -9 pid
’'безусловно” уничтожает процесс, потому что сигнал номер 9, KILL, не
перехватывается. Мы написали ’‘безусловно” в кавычках, так как иногда
процессы попадают в состояния, в которых их нельзя завершить даже таким
способом (обычно это связано с блокировкой ввода-вывода, например
ожиданием жесткого диска, который перестал вращаться). Остается один
выход — перезагрузка.
4.5.	Состояния процессов
Факт существования процесса не дает ему автоматического права на
получение доступа к центральному процессору Необходимо знать о четырех
состояниях выполнения процесса, которые перечислены в табл. 4.2.
Тоблицо 4.2. Состояния процесса
Состояние	Описание
Выполнение	Процесс можно выполнять
Ожидание	Процесс адет выделения какого-либо ресурса
Зомби	Процесс пытается завершиться
Останов	Процесс приостановлен (не имеет разрешения на выполнение)
Выполняемый процесс получил все необходимые ресурсы и ждет, пока
системный планировщик предоставит ему доступ к центральному процессору
для обработки данных. Если процесс выполняет системный вызов, который
нельзя осуществить немедленно (например, чтение части файла), система
переводит его в состояние ожидания.
Ожидающим процесс ждет наступления определенного события. Интер-
претатор команд и системные демоны проводят в этом состоянии большую
часть своего времени, ожидая поступления данных с терминала или из
сетевого соединения. Поскольку ожидающий процесс фактически блокиро-
ван. то доступ к процессору будет предоставлен ему только в случае получения
сигнала.
Глово 4. Управление процессами
71
Остановленному процессу администратор запретил выполняться. Процес-
сы останавливаются при получении сигнала STOP или TSTP и возобновляют
работу по сигналу CONT. Это состояние аналогично ожиданию, но выйти
из него можно только с помощью другого процесса.
4.6.	Изменение приоритета выполнения:
команды nice и renice
Значение nice (фактор уступчивости) подсказывает ядру, как следует
относиться к данному процессу по сравнению с другими процессами,
конкурирующими за право доступа к центральному процессору. Чем ниже
значение nice, тем выше приоритет процесса.
Диапазон допустимых значений меняется от системы к системе. Как
правило, он простирается от -20 до + 19, а иногда — от 0 до 39 (см. табл. 4.3).
Несмотря на различия в диапазонах значений nice, все системы трактуют
фактор уступчивости примерно одинаково. Если пользователь не предприни-
мает особых мер, то дочерний процесс наследует приоритет своего родитель-
ского процесса. Владелец процесса может увеличить значение nice, ио не
может уменьшить его. Это не дает возможности процессам с низким
приоритетом порождать высокоприоритетных потомков. Только суперпользо-
ватель имеет полную свободу в установке значений nice и даже может
присвоить процессу такой высокий приоритет, что все остальные процессы
не смогут работать.
В некоторых системах ядро автоматически повышает значение nice
процессов, которые достаточно долго работали с центральным процессором
или переведены в фоновый режим.
Установка приоритетов процессов вручную быстро ухолит в прошлое.
Когда ОС UNIX работала на слабых машинах 70—80-х гг.. на производи-
тельность больше всего влияло то, какой процесс занимал основную часть
времени центрального процессора. Сегодня, когда на рабочих столах стоят
намного более быстродействующие компьютеры, планировщик UNIX, как
правило, обслуживает все процессы весьма оперативно. К сожалению, уровень
производительности подсистемы ввода-вывода растет не так быстро, как
быстродействие центральных процессоров, поэтому жесткие диски стали
основным “узким местом" в большинстве ОС.
0 О производительности читайте также в главе 25.
Фактор уступчивости процесса можно установить во время его создания.
Это делается с помощью команды nice. Команда rcnice позволяет изменять
значение nice во время выполнения процесса. Первая из этих команд
принимает в качестве аргумента командную строку, а вторая — идентифи-
катор процесса либо (в некоторых случаях) имя пользователя. Приведем
примеры:
% nice +10 -/bin/longtask
% renice -5 а829
Следует отметить, что в разных системах нет четкого соглашения
относительно того, как задавать требуемый приоритет. Обычно даже команды
nice и renice одной системы имеют различный синтаксис. Иногда нужно
указывать только приращение, а иногда — абсолютное значение. В одних
случаях значению должен предшествовать дефис, в других — флаг -п. а в
третьих — вообще ничего.
72
Чость I. Основы ОДМИНИСТрИрОВОНИЯ
Чтобы все было еше сложнее, существует версия команды nice, встроенная
в интерпретатор С shell и некоторые другие (но не в sh). Если не указать
абсолютное путевое имя, будет вызвана именно встроенная версия, а не
системная. Это очень неудобно, так как синтаксис их в большинстве случаев
различен (иногда отличаются даже диапазоны значений).
В табл. 4.3 перечислены основные варианты. Параметр приор — это
абсолютное значение nice, тогда как параметр инкр определяет приращение
приоритета по отношению к значению nice текущего интерпретатора команд.
Чтобы ввести отрицательное значение, необходимо поставить два дефиса
(например, —10). Знак '+’ нужно указывать только во встроенной версии
команды nice.
Тоблицо 4.3. Синтаксис зодония приоритетов в роаличных версиях команд nice и renice
1  ОС	Диапозон	Системная комо ндо nice	Команда nice в esh	Команде renice
Solaris	0-39	-инкр или -п инкр	+инкр или -инкр	инкр ИЛИ -П инкр
HP-UX	0-39	-приор или -п приор	+инкр или -инкр	-в приор}
Red Hat	-20-20	-инкр или -п инкр	+инкр ИЛИ -инкр	приор
FreeBSD	-20-20	-приор	+инкр или -инкр	приор
Указывается абсолютный приоритет, но к введенному значению добавляется 20.
4.7.
Самый распространенный из высокоприоритетных процессов в современ-
ном мире — xntpd, демон тактовой синхронизации. Поскольку для выполне-
ния его миссии быстрый доступ к центральному процессору имеет очень
большое значение, этому процессу обычно назначается фактор уступчивости -12.
Если какой-либо процесс займет столько времени центрального процес-
сора, что доведет показатель средней загруженности системы до 65, то перед
выполнением команд, необходимых для исследования этой проблемы, может
понадобиться запуск с помощью команды nice высокоприоритетного интер-
претатора shell. В противном случае весьма вероятно, что у команд не будет
ни малейшего шанса быть выполненными.
Текущий контроль процессов: команда ps
Команда ps — основной инструмент, которым системный администратор
пользуется для текущего контроля процессов. Версии этой команды разли-
чаются аргументами и выходным форматом, ио, по сути, выдают одну и ту
же информацию. Все версии можно разбить на два основных лагеря: системы
семейства System V (Solaris, HP-UX) и системы семейства BSD (Red Hat,
FreeBSD). Кроме того, поставщики могут настраивать эту команду с учетом
конфигурации системы, так как она тесно связана с особенностями обработки
процессов в ядре и поэтому часто отражает изменения в ядре.
С помощью команды ps можно получить информацию об идентифика-
торах, приоритете, управляющем терминале того или иного процесса и многое
другое. Она также позволяет узнать о том, какой объем памяти использует
процесс, сколько времени центрального процессора он затребовал, каково
его текущее состояние (выполняется, остановлен, простаивает и т.д.).
Процессы-зомбн в листинге команды ps обозначаются как <exiting> или
<defunct>.
Глово 4 Упровление процессом^
73
Администратор должен научиться понимать выходную информацию коман-
ды ps. Посмотрев на полученный листинг, можно определить (помимо всего
прочего), какие процессы выполняются в системе, сколько ресурсов централь-
ного процессора и памяти они используют и кому принадлежит каждый из них.
Команда ps стремительно усложнилась за последние несколько лет.
Некоторые поставщики бросили попытки стандартизировать выходной фор-
мат этой команды и сделали ее полностью конфигурируемой. Проведя
небольшую настройку, можно получить практически любые требуемые
результаты. В Red Hat команда ps является настоящим хамелеоном и понимает
наборы опций из целого ряда других систем. Имеется также специальная
переменная среды, с помощью которой можно выбрать нужный набор.
Не пугайтесь подобной сложности: пусть это будет кошмаром разработ-
чиков ядра, а не системных администраторов! Несмотря на частое применение
команды ps. достаточно знать лишь несколько магических заклинаний.
* В Red Hat и FreeBSD получить список всех процессов, выполняющихся
[Ц в системе, можно с помощью команды ps aux. Ниже показаны результаты
работы этой команды во FreeBSD (в Red Hat они будут немного другими).
n ps aux
USER РЮ
root О
root 1
root 2
root 46
root be
root 75
root 100
evi 1251
evi 1517
evi 1520
%CFU ЧМЕМ
0.0	0.0
VSZ RSS TT
0 0??
208 120 ??
0 12 ??
160 112 -?
226 15г >-
236 104 ?'
204 92 ??
320 256 p8
126 64 pB
332 224 pB
STAT STARTED TIME
DLs 8:35PM
Ss 8:35PH
DL 8:35PM
Ss 8:37PM
I 8:?7PM
IWs 8-3“PM
Is 6:37PM
Is* 1:50PM
St 3:П PM
R+ 3:17PM
0:00.06
0:00.20
0:00.03
0:01.45
0:00.2.3
0:00.02
0:00.1«
0:00.47
0:00.03
0:00.04
COMMAND
(swapper)
init -s
(pagedaenwn)
eyslogd
cron
Lpd
inetd
-esh (cab»
nan Logger
ps aux
Описание каждого поля приводится в табл. 4.4.
Fine один полезный набор аргументов команды ps в Red Hat н FreeBSD —
lax Команда ps lax выдает более специализированную информацию и
выполняется быстрее, поскольку не осуществляет сопоставления идентифи-
каторов процессов с именами пользователей. Это может оказаться весьма
важным фактором, если система уже серьезно загружена каким-то процессом
Ниже в сокращенном виде показаны результаты работы команды. Обратите
внимание на дополнительные поля PPID (идентификатор родительского
процесса), NI (значение nice) и WCHAN (ресурс, которого ожидает процесс).
4 ps lax
□ID	PTD PPID	CPU
0	0	0	0
0	10	0
0	2	0	0
0	46	1	C
0	77	1	c
0 64 to
PRГ	NT	VSZ	RS5
-18	000
10	0	2GB	120
-IB	0	0	12
2	0	160	112
2	C	'60	B8
2	0	260	204
WCHAN
a5e6c
wait
a203c
select
select IWs
select IMs ??
STAT TT
DLs ??
Is ??
DL ??
Ss ??
TIME
0:00.06
0:00.20
0:00.06
COMMAND
(swanper)
init -s
psgedaemon
0:01.47 syslcgd
0:00.0/ portmap
0:00.2? mojntd
74
Чостъ I. Основы ОДМИНИСТрИрОВОКИ!
Тоблица 4.4 Пояснения к выходной информации команды ps оих (во FreeBSD)
Поле Содержимое
USER	Имя владельца процесса
PID	Идентификатор процесса
% CPU	Доля времени центрального процессора (в процентах), выделенная
данному процессу
%М£М	Часть реальной памяти (в процентах), используемая данным процессом
VSZ	Виртуальный размер процесса в килобайтах
RSS	Размер резидентного набора (количество стран на памяти размером
1 Кб)
ТТ	Идентификатор управляющего терминала
STAT	Текущий статус процесса:
R — выполняется
D — ожидает записи на диск
I — неактивен (< 20 с)
S — неактивен (> 20 с)
Т — приостановлен
Z — зомби
Дополнительные флаги:
> — процесс имеет повышенный приоритет
N — процесс имеет пониженный приоритет
< — процесс превысил программный лимит на использование памяти
А — процесс запросил замену произвольной страницы
S — процесс запросил замену страницы по принципу FIFO
V — процесс приостановлен на время выполнения вызова vTorV
Е — процесс пытается выполнить вызов exit
L — некоторые страницы блокированы в оперативной памяти
X — процесс находится в состоянии трассировки или отладки
S — процесс является лидером сеанса (владельцем управляющего
терминала)
w — процесс выгружен ня диск
+ — процесс находится в интерактивном режиме своего
управляющею терминала
STARTED Время запуска процесса
TIME	Время центрального процессора, затребованное процессом
COMMAND	Имя и аргументы команды1
1 Список аргументов может быть неполным. Добавьте опцию ww. чтобы запретить
усечение.
В Solans и HP-UX получить информацию о вгдполняемых процессах
можно с помошью команды ps -ef (она работает н в Red Hat):
% рв -< DID	PID	PF ID	r	STIME	TTY	TIME
root	0	0	60	Dec 21	о	0:02
root	1	6	2	Dec 21	1	4:32
root	2	0	e	Dec 21	•з	0:00
root	171	1	BO	Dec 21		0:02
trent	8462	6444	35	14:34:10	pts/7	0:00
trent	6444	B422	203	14:32:50	pts/?	0:01
COMD
shed
/etc/inlt -
pageout
/usr/lib/senmail -bd
ps -ef
-esh
Пояснения к этому листингу даны в табл. 4.5.
Глово 4. Упровление процессоми
/5
Таблица 4.5. Пояснения к выходной информации команды ps -ef
(Solaris, HP-UX и Red Hot)
Поле	Содержимое
UID	Имя владельца процесса
PID	Идентификатор процесса
PPID	Идентификатор родительского процесса
c	Информация об использовании центрального процессора и планировании
STINE	Время запуска процесса
TTY	Управляющий терминал
TIME	Время центрального процессора, затребованное процессом
COMD	Команда и аргументы
Подобно команде ps lax в Red Hal и FreeBSD, ps -elf позволяет в системах семейства System V увидеть и другие интересные данные:	
1 ps -elf F S UID 19 T root 8 5 root В S root	PID PPID	С	Р	KI	ADDR	SZ	KCHAN	TIME	COMD 0	0	ВО	0	SY	f00c2fd8	0	С:С2	sched 1	0	65	1	20	ff2vaB00	B8	ff2632c8	4:32	init - 142	1	41	1	20	ff2eB000	176	f00cb69	0:00	sysLoad
Столбцы STIME и TTY здесь опущены, чтобы листинг уместился по ширине страницы; они идентичны столбцам, выдаваемым командой ps -ef. Поля листинга описаны в табл. 4.6.	
Таблице 4.6. Пояснения к выходной информации команды рв -elf (Solaris, HP-UX, IRIX и Red Ног)	
Поле	Сое .химое
F	Флаги процесса; возможные значения зависят от системы (редко используются системными администраторами)
S	Статус процесса: о — в текущий момент выполняется S — неактивен (ожидает события) R — разрешен к выполнению Т — остановлен или отлаживается Z — зомбн D — неактивен и не может быть прерван (обычно ожидает записи на диск)
с	Информация об использовании центрального процессора (применя- ется для планирования процессов)
₽	Приоритет планирования (внутреннее значение ядра, отличается от значения nice)
NI	Значение nice или константа SY для системных процессов
ADDR	Адрес процесса в памяти
SZ	Число страниц, занимаемых процессом в оперативной памяти
WCHAN	Адрес ресурса, которого ожидает процесс
76
Часть J. Основы администрирования
4.8. Улучшенный текущий контроль процессов:
программе top
Команда ps позволяет сделать только разовый, моментальный “снимок*’
системы, но получить полную картину всего происходящего в ней довольно
сложно. Существует бесплатная программа top, которую можно установить
в системах многих типов, чтобы получать с ее помощью регулярно
обновляемую сводку активных процессов и используемых ими ресурсов.
Автором этой программы является Уильям Лефевр (William LeFebvre).
fc/’f Программу top можно загрузить с Web-узла www.groupsys.com.
Вот примерные результаты ее работы:
last pld: 2131 Load averages: 2.93, 2.95, 2.69 15:51:51
75 processes: 71 sleeping, 3 running, 1 zombie
epu states: 44.54 user. 0% nice, 23.9* system, 31,64 idle
Memory: 113M avail, 108M in use, 4972K tree, 6232K locked
PID	USER	PHI NICE		SIZE	RES	STATE	TIME	WCFU	CPU	COMMAND
1313	root	1	-19	297K	148K	sleep	0:00	9.34	0.7%	erped
2В5В	root	1	0	1564K	67 6K	sleep	0:20	5.4%	0.7%	sendma
1310	root	27	0	812K	4BBK	run	0:00	7.6%	0.3%	sendma
981	root	29	0	2152K	2324K	run	0:03	0.0%	0.0%	top
132	root	1	0	44 К	27 6K	sleep	0:48	0.0%	0.0%	in.rlc
778	UUCP	27	0	244K	508K	run	0:04	0.0%	0.01	UUC1CC
5296	randy	15	0	22BK	176K	sleep	0:00	0.0%	0.0%	esh
151	root	15	0	I2K	8K	sleep	54:40	0.0%	0.0»	upda te
0962	trent	15	0	212K	OK	sleep	0:00	0.0*	0.0%	cab
5843	toeth	15	0	20BK	OK	sleep	0:00	D.04	0.0%	esh
167	root	15	0	ICON	OK	sleep	0:00	0.0%	0.0%	Ipd
1311	randy	5	0	224K	4DBK	sleep	0:00	0.0%	0.0%	prev
По умолчанию эта информация обновляется каждые десять секунд,
Наиболее активные процессы указываются первыми. Программа top позво-
ляет также посылать процессам сигналы и использовать команду renice,
чтобы пользователь мог наблюдать за тем, как его действия влияют на общее
состояние системы.
Для того чтобы обновлять информацию каждые десять секунд, программа
top должна занимать некоторую часть времени центрального процессора.
По этой причине ее следует использовать только для диагностических целей,
а не как программу, постоянно работающую в отдельном окне.
Пользователь root может запустить программу top с опцией -q, чтобы
обеспечить ей максимально возможный приоритет. Это очень удобно, если
какие-то процессы уже существенно замедлили работу системы.
4.9. Процессы, вышедшие из-под контроля
Иногда в системе появляются процессы, которыми по той или иной
причине должен заниматься администратор. Неуправляемые процессы бывают
двух видов: пользовательские, потребляющие слишком много системных
ресурсов (например, времени центрального процессора или дискового про-
странства), и системные, которые внезапно "ападают в буйство” и начинают
вести себя непредсказуемо. Процессы первого типа могут быть вполне
работоспособными, просто они некорректно обращаются с ресурсами. В то
же время системные процессы всегда должны работать в соответствии с
определенными правилами.
Глово 4„ Упровление процессом^
77
Об обработке неуправляемых процессов читайте также в параграфе 25.4.
Процессы, занимающие чересчур много времени центрального процес-
сора. можно выявить, проанализировав результаты работы команды ps. Если
очевидно, что какой-либо пользовательский процесс потребляет больше
ресурсов, чем ему действительно необходимо, его нужно исследовать. Самый
простой способ разобраться в ситуации — связаться с владельцем процесса
и спросить, что происходит. Если это невозможно, придется действовать на
свой страх и риск. Хотя в обычной ситуации системный администратор
старается не заходить а каталоги пользователей, это допускается, если нужно
изучить исходный текст неуправляемого процесса н выяснить, что же он
делает.
Это может понадобиться по двум причинам. Во-пераых. процесс может
быть действительно важным для пользователя Уничтожать каждый процесс,
который занимает много времени центрального процессора, не совсем
разумно. Во-вторых, процесс может оказаться деструктивным. написанным
хаке ром-злоумышлении ком. В этом случае нужно точно знать, что он
натворил, иначе исправить положение не удастся.
Если причину появления неуправляемого процесса определить не удается,
приостановите его сигналом STOP и отправьте владельцу по электронной
почте сообщение о том, что случилось. Процесс можно впоследствии
перезапустить сигналом CONT. Помните о том, что некоторые процессы
перестают нормально функционировать в случае слишком долгого простоя,
поэтому описанный подход не всегда приемлем. Например, процесс мог
осуществлять обмен данными через сетевое соединение, а после “пробужде-
ния” обнаруживается, что соединение уже разорвано.
Если процесс использует слишком много ресурсов процессора, по делает
нечто обоснованное и работает правильно, необходимо с помощью команды
renice понизить его приоритет и попросить владельца в будущем запускать
процесс с более низким приоритетом.
В системах, где не реализованы касты, результаты работы неуправляемых
процессов могут заполнить всю файловую систему н. таким образом, повлечь
за собой бесчисленные проблемы. При переполнении файловой системы на
консоль выдается множество сообщений, и попытки записать что-либо на
диск вызывают появление сообщений об ошибках.
Первое, что нужно сделать в такой ситуации, — это остановить процесс,
который переполняет диск. Если на диске было специально зарезервировано
свободное пространство, то в случае его внезапного заполнения можете быть
уверены: тут что-то неладно. Не существует средства, аналогичного команде
ps, которое сообщило бы о том, кто использует дисковое пространство. Но
есть утилиты, позволяющие полу*гить список открытых файлов и процессов,
работающих с ними; описание утилит fuser и Isof приведено в параграфе 5.2.
Можно приостановить все подозрительные процессы, пока не обнару-
жится источ1гик проблем. В этом случае не забудьте после выявления
нарушителя удалить все созданные им файлы и перезапустить невиновные
процессы.
Старый и хорошо известный трюк — запуск из интерпретатора команд
бесконечного цикла:
while 1
mkdir adir
cd adir
78
Чость I. Основы одминистрировония
touch afile
end
Такое иногда происходит, если злоумышленник проник в систему через
незащищенную учетную запись или зарегистрированный в системе терминал,
брошенный без присмотра. Созданное дерево каталогов не занимает много
места на диске, просто переполняется таблица индексных дескрипторов
файловой системы, и другие пользователи теряют возможность создавать
новые файлы. Единственное, что можно сделать в подобной ситуации. —
устранить последствия и предупредить пользователей о необходимости зашиты
своих учетных записей. Поскольку дерево каталогов, оставленное таким
маленьким программным “перлом", может оказаться слишком большим для
команды гт -г, придется написать сценарий, который спустится по дереву
вниз, а затем, возвращаясь, удалит все каталоги.
Если проблема возникла в каталоге /tmp, а он был создан как отдельная
файловая система, то вместо того чтобы пытаться удалять файлы, можно
проинициализировать каталог /tmp с помощью команды newts. Более
подробно об управлении файловыми системами рассказывается в главе 8.
5
Файловая система
Ответьте, не раздумывая, на вопрос: что из нижеперечисленного можно
встретить в файловой системе?
•	Процессы
•	Последовательные порты
•	Каналы межзадачного взаимодействия
•	Совместно используемые сегменты памяти
Если речь идет о UNIX, ответом будет “все вышеперечисленное”. Ну и.
конечно, в файловую систему входят собственно файлы.
Хотя основным предназначением файловой системы является организа-
ция хранимых ресурсов системы (т.е файлов), программистам не хотелось
каждый раз заново изобретать колесо при управлении объектами других типов
Очень часто оказывалось удобным представлять такие объекты в виде
элементов файловой системы Подобный унифицированный подход имеет
как преимущества (единый программный интерфейс, легкий доступ из
командного интерпретатора), так и недостатки (реализация файловых систем
по методу доктора Франкенштейна). Но независимо от того, нравится он
вам или нет, именно такой подход применяется в UNIX.
Файловую систему можно представить состоящей из четырех основных
компонентов:
•	пространство имен — методы именования объектов и организации их в
виде иерархий;
•	API" — набор системных вызовов, предназначенных для перемещения
между узлами системы и управления ими;
Инзсрфейс программирования приложений (Application Programming Interface, API) — это
обший термин для описания набора подпрограмм, организованных в ваде библиотеки или
совокупности библиотек и доступных программистам.
80
Чосгь I Основы ОДМИНИСТрИрОВОНИЯ
•	модель безопасности — схема зашиты, укрывания и совместного исполь-
зования объектов;
•	реализация — программный код, который связывает логические модели
с дисковой подсистемой.
Современные файловые системы в UNIX определяют абстрактный
интерфейс уровня ядра, позволяющий работать с различными аппаратными
интерфейсами. Некоторые части файлового дерева обрабатываются традици-
онной дисковой подсистемой, другие управляются отдельными драйверами
ядра. Например, за работу сетевых файловых систем (NFS) отвечает драйвер,
который перенаправляет запросы серверу на другой компьютер.
К сожалению, архитектурные границы нечетко очерчены, и имеется
слишком много “особых” случаев. Скажем, файлы устройств позволяют
программам взаимодействовать с драйверами ядра. Они не являются файлами
данных, но обрабатываются базовыми средствами файловой системы, а их
характеристики записываются на диск. Наверное, имело бы смысл переписать
операционную систему с учетом опыта последнего десятилетия.
Другим усложняющим фактором является то, что современные версии
UNIX поддерживают несколько типов файловых систем. Помимо базового
варианта — 4.3BSD, распознаваемого большинством ОС, существуют файло-
вые системы, обладающие повышенной надежностью или упрощенными
средствами восстановления после сбоев (например, VXFS в HP-UX), системы,
поддерживающие иную семантику (например, расширения, связанные со
списками прав доступа в Solaris и HP-UX), и системы, построенные на других
типах носителей (в частности, жесткие диски DOS или компакт-диски
формата ISO-9660). Все они могут отличаться от стандартной файловой
системы UNIX, описываемой в настоящей главе.
5.1.	Путевые имена
Файловая система — это единая иерархическая структура, которая
начинается с каталога / и разветвляется, охватывая произвольное число
подкаталогов. Катвлог самого верхнего уровня именуется корневым.
Цепочка имен каталогов, через которые необходимо пройти для доступа
к заданному файлу, вместе с именем этого файла называется путевым именем.
Путевые имена могут быть абсолютными (например, /tmp/afile) или относи-
тельными (скажем, book3/fflesystem). Последние интерпретируются, начиная
с текущего каталога. Некоторые считают, что текущий каталог задается
командным интерпретатором. На самом деле текущий каталог имеется у
каждого процесса.
Термины файл и имя файла, а также путевое имя и путь в большей или
меньшей степени являются взаимозаменяемыми. Понятия имя файла и путь
можно употреблять как для абсолютных, так и для относительных путевых
имен. Под путевым именем, как правило, подразумевают абсолютный путь.
Слово файл часто используется в случаях, когда нужно сконцентрировать
внимание на содержимом файла, а не на его имени.
Файловое дерево в UNIX может быть произвольного размера. Однако
существуют определенные ограничения: имя каталога должно состоять не
более чем из 255 символов, а в отдельном путевом имени не должно быть
более 1023 символов. Чтобы получить доступ к файлу, абсолютное путевое
имя которого не удовлетворяет этим требованиям, необходимо с помощью
Глово 5. Фойл он or системе
81
команды cd перейти в промежуточный каталог, а затем воспользоваться
относительным путевым именем".
На имена файлов и каталогов не накладывается никаких ограничений,
за исключением того, что длина имен не должна превышать заданный предел
и в имена нельзя включать символы '/’. В частности, теоретически допуска-
ются имена, содержащие пробелы. Но на самом деле по давней традиции
аргументы командной строки в UNIX разделяются пробелами, поэтому старые
программы интерпретируют пробелы в именах файлов как признак конца
одного имени и начала другого.
Учитывая количество всевозможных файловых систем, существующих на
сегодняшний день, нельзя полагать, что вам никогда не встретятся имена
файлов с пробелами. Даже если вы не взаимодействуете с компьютерами,
работающими под управлением Macintosh или Windows, все равно есть много
пользователей, привыкших давать своим файлам сложные имена. О подобной
возможности не следует забывать при написании любых сценариев, взаимо-
действующих с файловой системой
В общем случае имена с пробелами надлежит просто заключать в двойные
кавычки. Например, команда
% more "Му excellent file. txt''
будет воспринята как попытка передать программе тоге единый аргумент Му
excellent file.txt.
5.2.	Монтирование и демонтирование файловой системы
Файловое дерево формируется из отдельных частей, называемых файло-
выми системами, каждая из которых содержит один каталог и список его
подкаталогов и файлов. Термин “файловая система*’, по сути, имеет два
значения. С одной стороны, это составная часть файлового дерева, а с
другой — все файловое дерево и алгоритмы, с помощью которых UNIX
управляет им. Как правило, значение термина становится ясным из контекста.
Большинство файловых систем являются разделами диска, но, как уже
упоминалось раньше, файловой системой может быть все. что подчиняется
определенным функциональным правилам: сетевые файловые системы, ком-
поненты ядра, резидентные диски и т.д.
Файловые системы прикрепляются к файловому дереву с помощью
команды mount. Эта команда берет из существующего файлового дерева
каталог (он называется точкой монтирования) и делает его Корневым
каталогом присоединяемой файловой системы. На время монтирования
доступ к содержимому точки монтирования становится невозможным. Как
правило, точка монтирования — пустой каталог. Например, команда
fl mount /dsv/adlc /users
монтирует файловую систему, размешенную на устройстве /dev/sdlc. под
именем /users. После монтирования можно с помощью команды Is /users
посмотреть, что содержит эта файловая система.
Список файловых систем, которые были смонтированы пользователями,
хранится в файле /etc/fstab, /etc/vfstab или /etc/checklist, в зависимости от
Здесь необходимо дать пояснения. Сама дисковая подсистема не накладывает никаких
ограничений на длину путевого имени. Но системные вызовы, получающие доступ к
файловой системе, не позволяют своим аргументам иметь длину Более чем 1023 символа.
82
Чость I Основы ОДМИНИСТрИрОЕОНИЯ

операционной системы. Благодаря этому становятся возможными автомати-
ческая проверка (fsck -р) и монтирование (mount -а) файловой системы на
этапе начальной загрузки, а также выполнение коротких команд наподобие
mount /usr. Точное местоположение монтируемой файловой системы ищется
в файле fstab (см. параграф 8.3).
Демонтируются файловые системы командой umount. В большинстве
систем занятую файловую систему демонтировать невозможно. В ней не
должно быть открытых файлов и выполняющихся процессов. Если демонти-
руемая файловая система содержит исполняемые программы, онн не должны
быть запущены.
Во FreeBSD допускается применение команды umount -Г, которая прину-
дительно демонтирует занятую файловую систему. Это не лучший выход из
положения, потому что программа, работающая с данной файловой системой,
может зависнуть или начать вести себя ненормально. Использовать команду
umount -Г можно только на свой страх и риск.
В Solaris 8 также имеется команда umount -Г. хотя в более ранних версиях
системы аналогичного результата можно было добиться в два этапа. Сначала
выполнялась команда lockfs -h точка монтирования, которая ставила на
файловую систему “жесткую блокировку”. Затем вызывалась обычная команда
umount.
Если ядро ’‘жалуется” на то, что демонтируемая файловая система занята,
можно запустить команду fuser, которая позволит узнать, кто работает с
файловой системой. Команда fuser -с точка_монтировония выводит иденти-
фикаторы всех процессов, обращающихся к файлам или каталогам указанной
файловой системы. К этим идентификаторам добавляются специальные
символьные коды, обозначающие выполняемые действия. Например:
% fuser -с /иаг
/usr;	157trn	315ctom	474tom	5049tom	84tm 496ctom
490tm	16938c	16902ctm	358ctom	484tm
Точное количество символьных кодов зависит от системы. Наиболее
распространены следующие коды:
с текущий каталог процесса расположен в файловой системе;
о открыт файл;
t выполняется программа;
m подключен файл (обычно совместно используемая библиотека);
г корневой каталог процесса находится в файловой системе (задается с помощью
команды chroot)
Чтобы определить, какие программы связаны с этими процессами,
вызовите команду ps„ передав ей список интересующих вас идентификаторов
процессов, о которых сообщила команда fuser. Например:
% pa -fp "157 315 5049”
UID	PID	PPID	C	STIME	TTY	TIME	CMD
root	5049	490	0	Oct	14	?	0:00	/usr/bin/Xl1/xdm
root	157	1	D	Jun	27	?	5:26	/usr/sbin/named
Ip	315	1	0	Jun	27	?	0:00	/usr/lib/lpsched
Список идентификаторов взят в кавычки, чтобы интерпретатор shell
передал его команде ps как один аргумент.
Глово 5. Фойловоя системе
83
Команда fuser может также выдавать статистику использования отдельных
файлов, а не всей файловой системы. Синтаксис ее вызова в этом случае
должен быть таким:
fuser -f ив4я_файла
Указав опцию -к, можно заставить команду' fuser послать всем найденным
процессам сигнал KILL. Это очень опасное действие, и для его выполнения
следует иметь привилегии пользователя root (им можно стать с помощью
команды sudo).
В Red Hat команда fuser, разработанная Вернером Альмсбергером (Werner
Almesberger), использует вместо опции -с опцию -т Если нужно получить
статистику по отдельным файлам, просто опустите опцию -гл. Имеется также
полезная опция -v, которая заставляет команду' fuser выдавать результаты
своей работы в стиле команды ps:
I fuse г
/usr
-mv /usr
USER
root
root
root
root
FID
1
125
274
321
ACCESS
... .m
... ,m
... .m
.. . .tn
COMMAND
init
epmd
portmap
sysiogd
Bo FreeBSD нет команды fuser, но есть команда fstal с аналогичными
возможностями.
Альтернативой команде fuser является бесплатная программа Isof (“list of
open files” — список открытых файлов), которая формирует список дескрип-
торов открытых файлов по процессам и и менам файлов. Программу Isof
написал Вик Эйбелл (Vic Abell) из университета Пердью, штат Индиана.
Получить ее можно на FTP-узле
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof
Она работает во всех рассматриваемых нами системах.
5.3.	Организация файловой системы
Файловая система в UNIX никогда не была хорошо организована.
Поскольку не существует единой системы присвоения имен, одновременно
используется много разных, не согласованных между собой правил имено-
вания файлов. Во многих случаях файлы группируются по выполняемым
функциям, независимо от того, как часто они изменяются. Это затрудняет
модификацию операционной системы. Например, каталог /etc содержит
файлы, которые никогда не меняются, а также полностью локальные файлы.
Такие нововведения, как каталог /var, помогли справиться с рядом
проблем, но файлы большинства систем все еще не упорядочены. Тем не
менее, для всего находится свое место. Большинство UNIX-программ можно
инсталлировать с минимальными усилиями в плане переконфигурнрования
системы, если ее настроили стандартным способом. Однако попытка
улучшить структуру, задаваемую по умолчанию, может привести к неприят-
ностям.
Корневая файловая система включает в себя корневой каталог и
минимальный набор файлов и подкаталогов. В ней располагается ядро,
которое обычно носит имя /unix или /vmunix. Этот файл может быть
дополнительно скрыт в подкаталоге /kernel или /stand. Корневая файловая
84
Чость I Основы одминистрировония
система также содержит каталог /dev для файлов устройств, каталог /etc для
системных конфигурационных файлов, каталоги /sbln и /bin для важнейших
утилит и иногда каталог /tmp для временных файлов.
В некоторых системах совместно используемые библиотечные файлы, а
также файлы препроцессора языка С хранятся в каталоге /lib. В других
системах этой же цели служит каталог /usr/lib, а каталог /lib является
символической ссылкой.
Очень большое значение имеют также каталоги /usr и /var. В первом
хранится большинство стандартных программ и другие полезные компоненты,
например электронная документация. Совсем не обязательно, чтобы каталог
/usr был отдельной файловой системой, однако для удобства администриро-
вания его, как правило, создают именно так.
В каталоге /var содержатся буферные каталоги, файлы регистрации,
учетная информация и прочие компоненты, которые быстро разрастаются и
изменяются. Каждый компьютер имеет свой список таких компонентов.
Каталоги /usr и /var должны существовать чтобы система могла загрузиться
в многопользовательском режиме.
Большая часть содержимого каталога /var первоначально находилась в
каталоге /usr. В своей системе вы, вероятно еще обнаружите соответствующие
символические ссылки, являющиеся остатками прежней эпохи.
Начальные каталоги пользователей следует держать в отдельной файловой
системе, которая обычно монтируется в корневом каталоге, а иногда — в
каталоге /usr. Некоторые файловые системы можно использовать и для
хранения больших информационных массивов, например библиотек исходных
текстов программ и баз данных.
Наиболее важные стандартные каталоги перечислены в табл. 5.1.
Тоблицо 5.1. Стондортные котологи и их содержимое
Путевое имя	Содержимое
/bin или /яЫп	Команды, необходимые для обеспечения минимального уровня работоспособности системы1
/dev /etc /lib /trap /Ч* /proc /stand /usr/bin /usr/gimes	Файлы устройств: терминалов, дисков, модемов и т.д. Важные файлы запуска и конфигурации Библиотеки компилятора языка С Временные файлы, удаляемые в процессе перезагрузки Рабочая область для построения ядра, файлы конфигурации (BSD) Образы всех работающих процессов (в некоторых новых системах) Автономные утилиты, программы форматирования дисков и др. Исполняемые файлы Игровые н развлекательные программы (большей частью не очень веселые)
/usr/lnclude /nsr/5bin	Файлы заголовков С-программ Команды, обеспечивающие совместимость с ядром System V в BSD-системах
/шг/sbln	Служебные системные команды
Если есть каталог /яЬ1л, то каталог /bin обычно представляет собой символическую
ссылку на каталог /ияг/Ып.
Г лов о 5 Фойловоя системо
85
	Путевое имя	Содержимое
	/usr/lfb /usr/пиш /usr/share /vtr/adm /«г/log /var/spool /var/tmp /usr/ucb /usr/local /usr/local/adm /usr/local/Ып /usr/local/etc /usr/local/Ub /usr/local/sbin /usr/local/src /kerne!	Вспомогательные файлы для стандартных UNIX-программ Страницы электронных руководств Элементы, общие для различных систем (часто сюда входят страницы электронной документации) Учетные файлы, журналы использования ресурсов Различные системные журнальные файлы (в некоторых системах) Буферные каталоги для принтеров, UUCP, электронной почты и тл. Каталог для временного хранения файлов (после перезагрузки файлы не исчезают) Утилиты и программы BSD Локальное программное обеспечение (все, что инсталлируется пользователями) Локальные учетные файлы и файлы регистрации Локальные исполняемые файлы Локальные системные команды и файлы конфигурации Локальные вспомогательные файлы Локальные служебные системные команды Исходные тексты для программ каталогов /usr/local/* Файлы, необходимые для загрузки ядра (в Solaris)
5.4.	Типы файлов	
В большинстве файловых систем поддерживается семь типов файлов:
•	обычные файлы;
•	каталоги;
•	файлы байт-орнентированных (символьных) устройств;
•	файлы блок-ориентированных (блочных) устройств;
•	сокеты;
•	именованные каналы (FIFO);
•	символические ссылки.
В некоторых системах не реализована поддержка таких типов файлов,
как сокеты или именованные каналы.
Обычные файлы
Обычный файл — это просто последовательность байтов. В UNIX не
накладывается ограничений иа его структуру. Текстовые документы, испол-
няемые программы, библиотеки функций и многое другое — все это хранится
в обычных файлах. К ним возможен как последовательный, так и прямой
доступ.
Каталоги
Каталог содержит именованные ссылки на другие файлы. Он создается
командой mkdir и удаляется (если пустой) командой rmdir. Каталоги, в которых
есть файлы, можно удалить командой пл -г.
86
Чость I Основы одминистрировОния
Специальные ссылки и обозначают соответственно сам каталог и
его родительский каталог. Их нельзя удалить. Поскольку у корневого каталога
нет родителя, ссылка в ием эквивалентна ссылке
Имя файла хранится в родительском каталоге, а не в самом файле. На
файл можно ссылаться из нескольких каталогов одновременно и лаже из
нескольких элементов одного и того же каталога, причем у всех ссылок могут
быть разные имена. Это создает иллюзию того, что файл в одно и то же
время находится в разных каталогах.
Ссылку невозможно отличить от имени файла, на который она указывает:
в UNIX они идентичны. UNIX подсчитывает количество ссылок, указываю-
щих на каждый файл, и при удалении файла не освобождает блоки данных
до тех пор, пока не будет удалена его последняя ссылка. Ссылки можно
задавать только в пределах одной файловой системы.
Ссылки такого рода обычно называют “жесткими”, чтобы отличить их
от символических (“мягких”) ссылок, которые описаны ниже. Жесткие
ссылки создаются командой In. а удаляются командой пи.
Синтаксис команды In легко запомнить, так как она повторяет работу
команды ср. Команда
ср oldfile newfile
создает копию файла oldfile под именем newfile. Точно так же, команда
In oldfile newfile
создает новую ссылку newfile на файл oldfile.
Важно понимать, что жесткие ссылки не являются отдельным типом
файлов. Просто файловая система позволяет создавать ссылки на один и тот
же файл в разных каталогах. Атрибуты файла, в частности права доступа и
идентификатор владельца, являются общими для всех ссыпок.
Файлы ба йт-ари визированных
и блок-ориентированных устройств
Подробно устройства и драйверы рассматриваются в главе 12.
Файлы устройств позволяют UNIX-программам взаимодействовать с
аппаратными средствами и периферийными устройствами системы. При
конфигурировании ядра к нему подключаются те модули, которые знают,
как взаимодействовать с каждым из имеющихся устройств*. За всю работу
по управлению конкретным устройством отвечает специальная программа,
называемая драйвером устройства.
Драйверы устройств образуют стандартный коммуникационный интер-
фейс, который выглядит для пользователя как обычный файл. Когда ядро
получает запрос к файлу байт-ориентированного или блок-ориентированного
устройства, оно просто передает этот запрос соответствующему драйверу.
Важно отличать файлы устройств от драйверов устройств. Файлы сами по себе
не являются драйверами. Их можно представить как шлюзы, через которые
драйверу передаются запросы.
Файлы байт-ориентированных устройств позволяют связанным с ними
драйверам выполнять свою собственную буферизацию ввода-вывода. Файлы
блок-ориентированных устройств обрабатываются драйверами, которые
Во многих системах возможна также динамическая загрузка этих модулей ядром
Глово 5. Фойл своя системо
87
осуществляют ввод-вывод большими порциями (блоками) и возлагают
обязанности по выполнению задач буферизации на ядро. Аппаратные средства
некоторых типов, такие как накопители на жестких дисках и магнитных
лентах, могут быть представлены файлами любого типа.
В системе может присутствовать несколько однотипных устройств.
Поэтому файлы устройств характеризуются двумя номерами: старшим и
младшим. Старший номер устройства говорит ядру о том, к какому драйверу
относится данный файл, а младший номер сообщает драйверу, к какому
физическому устройству следует обращаться. Например, старший номер
устройства 6 в Linux обозначает драйвер параллельного порта. Первый
параллельный порт (/dev/lpO) будет иметь старший номер 6 и младший
номер 0.
Некоторые драйверы используют младший номер устройства нестандарт-
ным способом. Например, драйверы накопителей на магнитных лентах часто
руководствуются им при выборе плотности записи и для определения того,
необходимо ли переметать ленту после закрытия файла устройства. В неко-
торых системах “драйвер терминала” (который на самом деле управляет всеми
последовательными устройствами) применяет младшие номера устройств для
того, чтобы отличать модемы, используемые для вызова удаленных систем,
от модемов, работающих на прием сообщений.
Файлы устройств можно создавать командой mknod, а удалять — коман-
дой пи. В большинстве систем имеется командный сценарий MAKEDEV
(обычно находится в каталоге /dev), который создает стандартные наборы
управляющих файлов для основных устройств. Прежде чем бездумно вызывать
этот сценарий, просмотрите его текст, чтобы понять, что конкретно он делает
в вашей системе-
Со кеты
Сокеты инкапсулируют соединения между процессами, позволяя им
взаимодействовать, не подвергаясь влиянию других процессов. В UNIX
поддерживается несколько видов сокетов, использование которых в большин-
стве своем предполагает наличие сети. Сокеты UNIX локальны для конкрет-
ного компьютера. Обращение к ним осуществляется через объект файловой
системы, а не через сетевой порт.
Несмотря иа то что другие процессы распознают файлы сокетов как
элементы каталога, процессы, не участвующие в соединении, не могут
осуществлять над этими файлами операции чтения и записи. С сокетами
работают система печати, система X Window и система Syslog.
Дополнительная информация о системе Syslog приводится в главе II.
Сокеты создаются с помощью системного вызова socket. Когда с обеюс
сторон соединение закрыто, сокет можно удалить посредством команды rm
либо системного вызова unlink.
Именованные канолы
Подобно сокетам, именованные каналы обеспечивают взаимодействие
двух процессов, выполняемых на одной машине. Именованные каналы
создаются командой mknod,, а удаляются командой пп.
88
Чость I Основы ОДМИНИСТрИрОВОНИЯ
Символические ссылки
Символическая, или "мягкая", ссылка обеспечивает возможность вместо
путевого имени файла указывать псевдоним. Когда ядро сталкивается с
символической ссылкой при поиске файла, оно извлекает из нее хранящееся
в ней путевое имя. Различие между жесткими и символическими ссылками
состоит в том, что жесткая ссылка — прямая, т.е. указывает непосредственно
на индексный дескриптор файла, тогда как символическая ссылка указывает
на файл по имени. Файл, адресуемый символической ссылкой, и сама ссылка
физически являются разными объектами файловой системы.
Символические ссылки создаются командой In -s, а удаляются командой
rm. Поскольку' они содержат произвольное путевое имя, то могут указывать
на файлы, хранящиеся в других файловых системах, н даже на несуществую-
щие файлы. Иногда несколько символических ссылок образуют никл
Символическая ссылка может содержать либо абсолютное, либо относи-
тельное путевое имя. Например, команда
In -s ../,./ufs /usr/include/bsd/sys/ufs
связывает имя /usr/indude/bsd/sys/ufc с каталогом /usr/include/ufs с помощью
относительного пути. Каталог /usr/include можно переместить куда угодно,
но символическая ссылка, тем не менее, останется корректной.
Остерегайтесь использовать обозначение в путевых именах, вклю-
чающих символические ссылки, поскольку по символическим ссылкам нельзя
проследовать в обратном направлении. Ссылка всегда обозначает
истинный родительский каталог данного файла или каталога. Например, в
приведенной выше ссылке путь
/usr/include/bsd/sys/ufs/../param.h
раскрывается как
/usr / include/рагагл. h
а не
/usr/include/bsd/sys/param.h
Распространенная ошибка — думать, будто первый аргумент команды
In -s как-то связан с текущим каталогом. На самом деле он не раскрывается
командой hi, а записывается в символическую ссылку буквально.
5.5.	Права доступа к файлам
Каждому файлу соответствует набор прав доступа, представленный в виде
девяти битов режима. Он определяет, какие пользователи имеют право читать
файл, записывать в него данные или выполнять его. Вместе с другими тремя
битами, влияющими на запуск исполняемых файлов, этот набор образует код
режима доступа к файлу. Двенадцать битов режима хранятся в 16-битовом
поле индексного дескриптора вместе с четырьмя дополнительными битами,
определяющими тип файла.
Последние четыре бита устанавливаются при создании файла и не
подлежат изменению. Биты режима могут изменяться владельцем файла или
суперпользователем с помощью команды climod (“change mode” — изменить
режим) Просмотр значении этих битов осуществляется с помощью команды Is.
Глово 5. Фойловоя системе
89
Биты SUID и SG1D
Биты, которым в коде режима доступа соответствуют восьмеричные
значения 4000 и 2000, — это биты смены идентификатора пользователя
(SU1D) и смены идентификатора группы (SGID). Они позволяют программам
получать доступ к файлам и процессам, которые при прочих обстоятельствах
недоступны пользователю, выполняющему эти программы. Подробнее данный
механизм был описан в параграфе 3.1.
Если бит SGID установлен для каталога, то создаваемые в нем файлы
при запуске будут принимать идентификатор группы каталога, а не группы,
в которую входит владелец файла. Это упрощает совместный доступ к
каталогам для пользователей, принадлежащих одной группе. Подобная
возможность поддерживается не во всех версиях UNIX (это не относится к
нашим тестовым системам). Следует также учитывать, что установка бита
SGID для исполняемого файла перекрывает аналогичную установку для
каталога.
В некоторых системах бит SG1D можно устанавливать для файлов, не
являющихся исполняемыми. Тем самым запрашивается специальный режим
блокировки файлов при их открытии.
Sticky-бит
Бит, которому в коде режима доступа соответствует восьмеричное
значение 1000. называется sticky-битом (“sticky" — липучка). Это хороший
пример того, как UNIX по мере взросления избавляется от рудиментов, но
они продолжают следовать за системой по пятам. В системах с небольшой
памятью, например PDP- 11/70. где UNIX работала в свои ранние годы,
требовалось, чтобы отдельные программы постоянно оставались в памяти.
Тогда sticky-бит был очень важен, так как запрещал выгрузку программ из
памяти. Сегодня в мире 25-долларовых модулей памяти и быстродействующих
дисковых накопителей sticky-бит никому не нужен, и современные ядра
попросту игнорируют его.
Если sticky-бит устанавливается для каталога, то большинство версий
UNIX позволяют удалять и переименовывать его файлы только в том случае,
если пользователь является владельцем каталога, владельцем файла или
пользователем root. Иметь одно лишь разрешение на запись в каталог
недостаточно. Такая мера направлена на то, чтобы сделать каталоги вроде
/Imp более защищенными.
Системы Solaris и HP-UX не столь строги в отношении каталогов с
Остановленным sticky-битом Пользователь, имеющий право записи в такой
каталог, может удалять из него файлы, даже если он не является их
владельцем.
Биты режиме
Девять битов режима предназначены для того, чтобы определить, кто и
какие операции может выполнять над файлом. В UNIX нельзя устанавливать
биты прав доступа отдельно для каждого пользователя". Существуют разные
Если быть более точными, то этого не позволяет делать традиционная модель безопасности
UNIX. В Solaris и HP-UX есть расширения, изменяющие многие аспекты традиционной
модели. Средн прочего в них поддерживаются списки управления доступом Тем не менее,
эти расширения здесь не описываются
90
Чость I. Основы одминистрировония
наборы (триады) битов для владельца файла, группы, которой принадлежит
файл, и прочих пользователей. Каждый набор состоит из трех битов: бита чтения,
бита записи и бита выполнения (для каталога последний называется битом
поиска).
Режим доступа удобно представлять в виде восьмеричного числа, так как
каждая цифра в нем представляется тремя битами. Три старших бита (в коде
режима доступа им соответствуют восьмеричные значения 400, 200 н 100)
служат для управления доступом к файлу со стороны его владельца. Вторые
три бита (40, 20 и 10) залают доступ для пользователей группы. Последние
три бита (4, 2 и 11 определяют доступ к файлу со стороны всех остальных
пользователей. Старший бит каждой триады — бит чтения, средний — бит
записи, младший — бит выполнения.
Каждый пользователь попадает только в одну из категорий, соответст-
вующих одной из триад битов режима. В случае неоднозначности выбираются
самые строгие права доступа Например, права доступа для владельца файла
всегда определяются триадой битов владельца и никогда — битами группы.
Возможна ситуация, когда внешние пользователи имеют больше прав, чем
владелец, но такая конфигурация используется редко.
Для обычного файла бит чтения позволяет открывать и читать файл, а
бит записи — изменять его содержимое. Возможностью удаления и переиме-
нования файла управляют биты прав доступа, установленные для его
родительского каталога (поскольку именно там хранится имя файла).
Установкой бита выполнения задается разрешение запускать файл, если
он является программой или командным сценарием. Существует два типа
исполняемых файлов: двоичные файлы, которые выполняются непосредствен-
но центральным процессором, и сценарии, обрабатываемые интерпретатором
shell или какой-нибудь другой программой (например, awk или sed). По
соглашению сценарии начинаются со строки примерно такого вида:
*! bin/csh -f
Она задает соответствутоший интерпретатор команд Текстовые файлы, в
которых не указан конкретный интерпретатор, считаются сценариями интер-
претатора sh (Bourne shell)’
Установкой бита выполнения (в этом контексте часто называемого битом
поиска) для каталога дается разрешение входить в каталог, но при этом
нельзя получить список его содержимого. Если для каталога задана комби-
нация битов чтения и выполнения, можно будет получить список содержи-
мого каталога. Комбинация битов записи и выполнения позволяет создавать,
удалять и переименовывать файлы в данном каталоге.
Просмотр отрибутов файла
Файловая система хранит информацию о каждом файле в структуре,
называемой индексный дескриптором. Каждый индексный дескриптор содер-
жит около сорока информационных полей, но большей частью они исполь-
зуются только ядром. Системного администратора будут в основном
интересовать количество жестких ссылок, владелец, группа, код прав доступа.
Когда файл начинается с символов D!. он в первую очередь обрабатывается самим ядром
Но если интерпретатор команд неуказан или задан неправильно, ядро откажется выполнять
файл. В этом случае текущий интерпретатор предпринимает вторую попытку, пытаясь
выполнить сценарий в интерпретаторе Bourne shell.
Глово 5 Фойловоя системе
91
размер, время последнего обращения, время последней модификации и тип
файла. Всю эту информацию можно получить с помощью команды Is -I.
Для каждого файла хранятся также сведения о времени последнего
изменения атрибутов, т.е. самого индексного дескриптора. Название данного
атрибута ("dime”) вводит многих людей в заблуждение, так как они полагают,
что это время создания файла. На самом деле в нем хранится время
последнего изменения одного из атрибутов файла (например, владел еца. кода
режима), но не его содержимого.
Рассмотрим пример:
% 1« -1 /bin/eh
-rwxr-xr-x 1 root bin 85924 Sep 27 1997 /bin/sh
В первом поле задается тип файла и маска режима доступа к нему.
Поскольку первый символ — дефис, значит, перед нами обычный файл.
Различные типы файлов обозначаются односимвольными кодами (табл. 5.2).
Таблица 5.2. Кодирование типов файлов в листинге команды b
Тип файл о	Символ	Создается к< мандой	Уделяется комондой
Обычный файл		редакторы, ср н др.	ПИ
Каталог	d	rnkdir	nndir, rm -г
Файл байт-ориентированного устройства	с	rnknod	пл
Файл блок-ориентированного устройства	b	mknod	rm
Сокет	S	socket(2)	FJ
Именованный канал	Р	rnknod	ПИ
Символическая ссылка	1	In -я	ГШ
Следующие девять символов в этом поле — это три набора битов режима.
В листинге команды Is они представляются буквами г, w и х (соответственно
чтение, запись и выполнение). В данном случае владелец имеет все права
доступа к файлу, а остальные пользователи — только право на чтение и
выполнение.
Если бы был установлен бит смены идентификатора пользователя (SUID),
то вместо буквы х, обозначающей право владельца на выполнение, стояла
бы буква s. Если бы был установлен бит смены идентификатора группы
(SGID), то вместо буквы х для группы тоже стояла бы буква s Последний
бит режима (право выполнения для остальных пользователей) представляется
буквой t, когда для файла задан sticky-бит. Если биты SUID/SG1D или
slicky-бит установлены, а надлежащий бит выполнения — нет, эти биты
представляются соответственно символами S и Т, указывающими на наличие
ошибки и игнорирование данных атрибутов.
Далее раположено поле со счетчиком ссылок на файл. В нашем примере
здесь стоит единица, свидетельствующая о том. что /bin/sh — единственное
имя, под которым известен данный файл. Всякий раз при создании жесткой
ссылки на файл этот счетчик увеличивается на единицу
9>
Чость I. Основы одминистрировония
Каждый каталог имеет минимум две жесткие ссылки: одну из родитель-
ского каталога и одну из специального файла внутри самого каталога.
Символические ссылки в счетчике не учитываются.
Следующие два поля — владелец и группа файла. В данном случае
владельцем файла является пользователь root, и файл принадлежит группе
bin. В действительности ядро хранит эти данные не как строки, а как
идентификаторы пользователя и группы. Если символьные версии имен
определить невозможно, в этих полях будут отображаться числа. Такое может
случиться, если запись пользователя или группы была удалена из файла
/etc/pesswd или /etc/group соответственно. Не исключено также, что возникла
ошибка в сетевой административиой базе данных (см. главу 18).
Затем следует поле, отображающее размер файла в байтах. Рассматривае-
мый файл имеет размер 85924 байта, т.е. почти 84 Кбайт'. Далее указывается
дата последнего изменения: 27 сентября 1997 г. В последнем поле листинга
содержится имя файла: /bin/sh.
Для файла устройства команда Is выдает несколько иную информацию.
Например;
Ь 1» -1 /dev/ttya
crw-rw-rw- 1 root daemon 12, 0 Dec 20 1998 /dev/ttya
В основном поля те же, но вместо размера в байтах показаны старший
и младший номера устройства. Имя /dev/ttya относится к первому устройству,
управляемому драйвером устройства 12 (в данной системе это драйвер
терминала).
При поиске жестких ссылок может оказаться полезной команда Is -i,
отображающая для каждого файла номер индексного дескриптора. Не
вдаваясь в детали реализации файловой системы, скажем, что этот номер
представляет собой индекс таблицы, в которой перечислены все файлы
системы. Жесткие ссылки, указывающие на один и тот же файл, будут иметь
один и тот же номер.
Система автоматически отслеживает время изменения, число ссылок и
размер файла. С другой стороны, права доступа и идентификаторы принад-
лежности файла изменяются явным образом с помощью команд chmod, chown
и chgrp.
Дополнительные флаги во FreeBSD
Во FreeBSD и других системах, построенных на ядре 4.4BSD, имеется
ряд дополнительных флагов, которые могут быть установлены для файлов.
Эти флаги связаны с расширенной семантикой файловой системы. Например,
флаг sappnd делает файл доступным только для присоединения (это может
быть полезно при создании журнальных файлов). А благодаря флагу schg
файл становится неизменяемым и неудаляемым. Узнать о наличии этих
файлов поможет команда Is -Io:
% la -lo /kernel
-r-xr-xr-x 1 root wheel schg 2498230 Nov 3C 23;51 /kernel
“К” обозначает “кило" — метрическую приставку, которой соответствует множитель 1000.
В вычислительной технике этот символ имеет несколько иной смысл: 1 килобайт равен 210,
или 1024, байтам. Аналогичным образом мегабайт — это ие миллион байтов, а 220, или
1048576, байтов.
Глово 5 Фойлоеоя системе
93
Управлять флагами можно с помощью команды chflags
#	chflags noschg /kernel
#	Is -lo /kernel
-	r-xr-xr-x 1 root wheel - 2498230 Nov 30 23:51 /kernel
Список доступных флагов вы можете получить на странице интерактив-
ного руководства chflags(l).
Комондо ch mod: изменение пров доступа
Код режима доступа к файлу можно изменить с помощью команды chmnd
Это право предоставлено только владельцу файла и пользователю root.
В ранних UNIX-системах код задавался в виде восьмеричного числа.
В современных версиях поддерживается также система мнемонических обо-
значений. Первый способ удобнее для системного администратора, но при
этом можно задать только абсолютное значение режима доступа А используя
мнемонический синтаксис, вы можете сбрасывать и устанавливать отдельные
биты режима.
Первым аргументом команды chmod является спецификация прав доступа.
Второй и последующий аргументы — имена файлов, права доступа к которым
подлежат изменению. При использовании восьмеричной нотации первая
цифра относится к владельцу, вторая — к группе, а третья — к остальным
пользователям. Если необходимо задать биты SUID/SGID или sticky-бит,
следует указывать не три, а четыре восьмеричные цифры. Первая цифра в
этом случае будет соответствовать трем специальным битам.
В табл. 5.3 показано восемь возможных комбинаций для каждого
трехбитового набора, где символы г, w и х обозначают соответственно чтение,
запись и выполнение.
Тоблицо 5.3. Коды пров доступо в комонде chmod		
Восьмеричное число	Двоичное число	Моско режимо доступо
0	ООО	___
1	001	—X
2	010	~w-
3	011	-WX
4	100	г—
5	101	г-х
6	по	rw-
7	III	CWX
Например, команда chmod 711 myprog предоставляет владельцу все права,
а всем остальным пользователям — только право выполнения*.
В табл. 5.4 представлены некоторые примеры мнемонических специфи-
каций.
Если файл myprog является сценарием интерпретатора shell, должно быть также задано право
чтения для остальных пользователей. Файлы сценариев, запускаемые интерпретатором,
открываются и читаются в текстовом виде. Двоичные файлы выполняются непосредственно
ядром, поэтому для них не нужно задавать право чтения.
94
ЧОСГЬ I. Основы ОДминиСфирОвОния
Тоблицо 5.4. Примеры мнемонических спецификоций комонды chmod
Спецификация	Смысл
U+W	Владельцу файла дополнительно дается право выполнения
ug~rw,о=г	Владельцу и группе предоставляется право чтения/запмеи. ос- тальным пользователям — право чтения
а-х	Все пользователи лишаются права выполнения
ug=srx,o^	Владельцу и группе дается право чтения/выполнения, устанав- ливается также бит SUID; остальным пользователям запрещен доступ к файлу
g=u	Группе назначаются такие же прана, что и владельцу
Символ u (“user”) обозначает владельца файла, символ g (“group”) —
группу, символ о (“others”) — других пользователей, символ a (“all*') — всех
пользователей сразу.
Команды chown и chgrp: смена владельцев
Команда chown предназначена для изменения владельца файла, а команда
chgrp — для изменения группы, которой принадлежит файл. Первым
аргументом обеих команд является имя нового владельца или новой группы
соответственно. Для того чтобы выполнять команду chgrp, необходимо либо
быть владельцем файла и входить в назначаемую группу, либо быть
пользователем root.
В большинстве версий команд chown и chgrp предусмотрен флаг -R,
который задает смену владельца или группы не только самого каталога, но
и всех его подкаталогов и файлов. Например, последовательность команд:
t chmod 755 -matt
# chown -R matt --matt
# chgrp -R staff -matt
можно использовать для конфигурирования начального каталога нового
пользователя после копирования в него стандартных файлов сценариев. Не
следует пытаться выполнять команду chown для файлов, имена которых
начинаются с точки;
# chown -R matt -matt/.*
Указанному шаблону поиска соответствует также файл 'matt/.., вследст-
вие чего команда изменит и владельца родительского каталога.
В некоторых системах посредством команды chown можно изменять
владельца и группу файла одновременно. Ее синтаксис в этом случае таков:
chown пользователь:группа файл...
Например:
Й chown —R matt;staff -matt
Версии UNIX, относящиеся к семейству System V, часто позволяют
пользователям отказываться от владения своими файлами с помощью
команды chown, тогда как в BSD-системах команду chown может выполнять
только суперпользователь. Практика показывает, что возможность свободного
изменения принадлежности файлов приводит к многочисленным проблемам.
Глово 5. Фойловоя системе
95
в частности к превышению дисковых квот. Лучше всего, если выполнять эту
команду разрешается только пользователю root.
Команда umaslc задание стандартных прав доступа
Встроенная shell-команда umask позволяет менять стандартный режим
доступа к создаваемым файлам. Значение umask задается в виде трехразряд-
ного восьмеричного числа, которое соответствует отнимаемым правам
доступа. При создании файла код доступа устанавливается равным разнице
между величиной, которую запрашивает создающая файл программа, и
значением umask. В табл. 5.5 перечислены возможные комбинации битов
режима для команды umask.
Таблица 5.5. Схема кодиоовония значения umask
Восьмеричное число Двоичное число Мооса режима доступа 
0	ООО	rwx
1	001	rw-
2	010	r-x
3	011	г—
4	100	-WX
3	101	-w-
б	по		X
7	111	—
Например, команда umask 027 предоставляет все права владельцу файла,
запрещает читать файл группе и не дает никаких прав остальным пользова-
телям. По умолчанию значение umask равно, как правило, 022, т.е. выполнять
модификацию файла разрешается только его владельцу.
Не существует способа, которым можно было бы заставить пользователя
придерживаться конкретного значения umask, так как ан в любой момент
может изменить его. Возможно, однако, задание стандартного значения umask
в тех копиях файлов .eshre и .profile, которые предоставляются новым
пользователям системы.
О стандартных файлах сценариев читайте в главе 6.
96
Часть I. Основы администрирования
6
Подключение новых
пользователей
В большинстве систем подключение новых поаъзователей и удаление
старых — обычное дело. Операции, связанные с этим, просты, но утоми-
тельны, поэтому многие администраторы создают средства автоматизации
данного процесса, а затем перепоручают реальную работу своему помощнику
или оператору.
Правильное управление учетными записями является залогом безопасно-
сти системы. Редко используемые учетные записи становятся главными
мишенями атак хакеров, как и те записи, пароль к которым легко подобрать.
Даже если для подключения и удаления пользователей применяются стан-
дартные системные утилиты, важно понимать, какие при этом происходят
изменения в системе.
6.1.	Файл/etc/passwd
Файл passwd — это список пользователей, которые известны системе
В процессе регистрации пользователя система обращается к денному файлу
в поисках идентификатора пользователя, а также с целью проверки входного
пароля. Каждая строка файла описывает одного пользователя и содержит
семь полей, разделенных двоеточиями:
•	регистрационное имя;
•	зашифрованный пароль (если не используется файл скрытых паролей;
см. ниже):
•	идентификатор пользователя;
•	идентификатор группы по умолчанию;
•	поле GECOS (полное имя, номер офиса, рабочий и домашний телефоны);
•	начальный каталог;
I ново 6. Подключение новых пользовотвлай
97
•	регистрационный интерпретатор команд.
Вот примеры правильно составленных строк файла /etc/passwd:
root:jsg8Y.IpfiuWMo:0:О:The System,,кбОЭб,:/:/bin/csh
jl:Hwex6bM8cT3/E: 100:0: Jim Lane,ECT8-3,, :/staff/jl;/bir>/sh
dotty;oP0vdZ/s93ZiY:101:20::/home/korbel/dotty:/bin/csh
Файл /etc/passwd часто используется несколькими системами через СУБД,
такую как NIS или NIS+. Более подробную информацию на эту тему вы
найдете в главе 18.
Ниже рассматривается назначение отдельных полей файла /etc/passwd.
Регистрационное имя
Регистрационные имена (называемые также пользовательскими именами)
должны быть уникальными. Как правило, они содержат не более восьми
символов*. Если используется база данных NIS или NIS+, длина имени
ограничена 8 символами независимо от операционной системы.
Ранее регистрационные имена могли состоять только из алфавитно-циф-
ровых символов. В современных системах допускаются любые символы, кроме
двоеточий и символов новой строки. Тем не менее, лучше придерживаться
старых правил и ие создавать имена длиной более 8 символов. Это позволит
избежать конфликтов с почтовыми системами н старыми программами, а
также гарантировать, что пользователи смогут иметь одинаковые регистраци-
онные имена на любой машине. Помните: сегодня у вас одни компьютеры,
а завтра могут быть другие.
Регистрационные имена могут содержать как строчные, так и прописные
буквы Правда, большинство почтовых систем (включая send mail) предпола-
гает. что используются только строчные буквы. По этой причине мы
рекомендуем избегать употребления прописных букв в регистрационных
именах за исключением случая, когда пользователям не нужно работать с
электронной почтой.
Следует выбирать такие регистрационные имена, которые можно легко
запомнить, поэтому имя. состоящее из случайной последовательности букв,
является не совсем удачным вариантом. Избегайте также кличек и прозвищ.
Поскольку регистрационные имена часто используют в адресах электронной
почты, полезно установить стандартную процедуру их формирования. Поль-
зователям должна быть предоставлена возможность делать обоснованные
догадки о регистрационных именах друг друга. Имена, фамилии, инициалы
и сочетания этих элементов — вот приемлемые варианты для схем форми-
рования имен.
Любая жестко заданная схема в конечном итоге приводит к появлению
дубликатов имен или слишком длинных имен, поэтому иногда придется
делать исключения. В случае появления длинного имени можно в файле
/etc/mail/aliases задать две версии одного и того же имени, по крайней мере,
для электронной почты.
Подробно о почтовых псевдонимах рассказано в параграфе 19.4.
Например, схема именования может быть такой: первый инициал н
фамилия каждого сотрудника. Пользователь Брент Браунинг (Brent Browning),
таким образом, превратится в “bbrowning", но девять символов — слитком
Во FreeBSD допускаются имена длиной до 16-ти символов, а в Red Hat — до 32-х.
98
Чость I Основы одминистрироеония
много. Лучше присвоить этому пользователю регистрационное имя “brentb”,
a “bbrowning” сделать элементом файла aliases:
bbrowning: brentb
Если в организации есть глобальный файл почтовых псевдонимов, то все
новые регистрационные имена должны отличаться от любого псевдонима,
указанного в этом файле. В противном случае почта будет доставляться не
новому пользователю, а пользователю с таким же псевдонимом.
Когда пользователь работает за несколькими машинален, то регистраци-
онные имена должны быть уникальными в двух аспектах. Во-первых,
необходимо, чтобы имя конкретного пользователя на всех машинах было
одним и тем же. Это предусматривается главным образом для удобства —
самого пользователя и администратора.
Во-вторых, конкретное регистрационное имя всегда должно относиться
к одному и тому же лицу. Если в сетевой среде одно имя принадлежит двум
разным пользователям, это приводит к возникновению слабых мест в системе
защиты. Например, если записи scott@boHlder и scotl@refuge относятся к
разным пользователям, то при определенных обстоятельствах оба пользователя
могут получить доступ к файлам друг друга.
Вопросы эквивалентности регистрационных имен рассматриваются в параг-
рафе 21.6.
Опыт также показывает, что дублирующиеся имена сбивают с толку
пользователей лотовых систем. Сама почтовая система различает, кому
именно принадлежат имена, однако ее пользователи при отправлении писем
часто ошибаются адресом.
Зашифрованный пароль
Пароли хранятся в файле /etc/passwd в зашифрованном виде. Если только
вы не производите DES-кодирование в уме (в этом случае мы очень хотели
бы с вами познакомиться), необходимо либо установить содержимое этого
поля с помощью команды passwd (или yppasswd. если используется база
данных NIS). либо скопировать строку, содержащую зашифрованный пароль,
из другой учетной записи'.
Редактируя файл /etc/passwd дня создания новой учетной записи, в поле
зашифрованного пароля поставьте звездочку (*). Она воспрепятствует несанк-
ционированному использованию учетной записи до установки реального
пароля. Никогда не оставляйте это поле пустым, иначе в системе защиты
возникнет огромная брешь, поскольку для доступа к такой учетной записи
пароль не требуется.
В системах, где применяются стандартные DES-пароли, длина незашиф-
рованного пароля не может превышать 8 символов. Более длинные пароли
допускаются, но значащими в них будут только первые 8 символов.
Зашифрованный пароль будет иметь длину 13 символов независимо от длины
исходного пароля. В алгоритме используется случайная двухсимвольная
“примесь”, чтобы одному исходному паролю соответствовало несколько
зашифрованных форм. Таким образом, факт выбора пользователями одина-
ковых паролей не может быть выявлен путем просмотра файла passwd.
Не во всех системах пароли шифруются с помощью алгоритма DES. Закодированные пароли
можно копировать только между теми компьютерами, на которых используется одинаковый
алгоритм шифрования
Главе 6. Подключение новых пользователей
99
FMjl В HP-UX существует ‘'доверительный режим", при котором допускаются
пароли любой длины. Это достигается путем многократного применения
алгоритма DES, по одному разу для каждого 8-символьного сегмента.
-л Мй в ^at и FreeBSD поддерживаются пароли MD5, которые также могут
fcXj Kjj иметь произвольную длину. Зашифрованные таким способом пароли легко
" распознать, так как они имеют длину 31 символ и всегда начинаются с
последовательности “SIS”.
С появлением быстродействующих аппаратных средств и эффективных
алгоритмов шифрования все более очевидной становится необходимость
прятать зашифрованные пароли путем помещения их в отдельный файл,
недоступный для всеобщего чтения. Это называется механизмом теневых
паролей. Полное описание теневых паролей приведено в параграфе 21.3.
В Solaris теневые пароли обязательны. Необходимо модифицировать файл
теневых паролей при подключении и отключении пользователей, чтобы он
был согласован с файлом /etc/passwd. Структура файла shadow в Solaris
описана в параграфе 6.4.
Идентификатор пользователя
В большинстве современных систем идентификатор пользователя
(UID) — это 32-разрядное целое число в диапазоне от 0 до 2147483647 Но
для обеспечения совместимости со старыми системами мы рекомендуем,
чтобы значение самого старшего идентификатора по возможности не
превышало 32767. В текущих версиях Linux максимальное значение L'lD
равно 65535, но подобное положение может измениться в будущем.
По определению пользователь root имеет идентификатор 0. В большинстве
систем есть также псевдопользователи bin (идентификатор 1) и daemon
(идентификатор 2). Как правило, псевдоимена помещаются в начало файла
/etc/passwd, и им назначаются низкие идентификаторы. Чтобы зарезервиро-
вать побольше номеров для неперсонифипированных пользователей, реко-
мендуем присваивать реальным пользователям идентификаторы, начиная с
номера 100.
Нежелательно создавать более одной учетной записи с идентификато-
ром 0. Может показаться удобным иметь несколько суперпользовательских
записей с разными интерпретаторами команд и паролями, но в действитель-
ности это создает дополнительные бреши в системе зашиты и приводит к
лишним трудностям. Если нескольким пользователям необходимо быть
администраторами, пусть они применяют команду sudo.
Избегайте повторного использования идентификаторов, даже идентифи-
каторов тех пользователей, которые уволились из организации и учетные
записи которых удалены. Такая мера предосторожности позволит избежать
путаницы, если файлы впоследствии будут восстанавливаться из резервных
копий, где пользователи идентифицируются по номерам, а не по регистра-
ционным именам,
Идентификаторы должны быть уникальными в пределах всей организа-
ции. Иными словами, необходимо, чтобы заданный идентификатор соответ-
ствовал одному и тому же регистрационному имени и физическому лицу на
каждой машине. Нарушение уникальности идентификаторов приведет к
появлению проблем безопасности в такой системе, как NFS, а также может
вызвать замешательство у пользователей, переходящих из одной рабочей
группы в другую.
Более детальная информации об NFS представлена в главе 17.
100
Чость I Основы одминистрировония
Трудно соблюдать уникальность идентификаторов, когда группы компь-
ютеров администрируются разными лицами и даже организациями. Это
проблема как техническая, так и политическая. Лучшим решением будет
создание центральной базы данных, содержащей для каждого пользователя
свою уникальную запись. Мы у себя самостоятельно создали такую базу
данных и назвали ее Uniquid* Проше всего назначить каждой группе в
пределах организации свой диапазон идентификаторов и позволить распоря-
жаться им по своему усмотрению. Проблема не решится полностью, но
вероятность совпадений значительно уменьшится.
Идентификатор группы по умолчанию
Идентификатор группы (G1D) представляет собой 16- или 32-разрядное
целое число со знаком или без. Идентификатор 0 зарезервирован для группы
с именем root или wheel, а идентификатор I обычно принадлежит группе
daemon.
Имя wheel было аналогом учетной записи root в ОС TOPS-20.
Группы определяются в файле /etc/group. В старых версиях UNIX
пользователь мог быть членом только одной группы. Для выбора эффектив-
ного идентификатора группы, используемой по умолчанию при входе в
систему, брали значение поля GID из файла /etc/passwd. Новейшие версии
UNIX позволяют пользователю быть членом до 16 групп одновременно,
поэтому поле GID в файле /etc/passwd никогда не используется и, по сути
дела, является рудиментом старой эпохи. Тем не менее, значение поля
продолжают включать в список групп пользователя.
В HP-UX список групп пользователя инициализируется во время
регистрации на основании файла /etc/logingroup, а не /etc/group. Мы
рекомендуем сделать файл /etc/logingroup символической ссылкой на файл
/etc/group, чтобы ОС HP-UX вела себя так же, как и другие системы при
работе в нескольких группах.
Единственный раз, когда эффективный идентификатор учитывается, —
при создании новых файлов и каталогов. Если используется семантика BSD.
новые файлы наследуют значение G1D у своего родительского каталога.
В противном случае им назначается текущий эффективный идентификатор
группы, которой принадлежит владелец. Изменить этот идентификатор можно
с помощью команды newgrp.
Большинство систем по умолчанию не используют семантику BSD, но
ее можно активизировать с помощью опции grpid команды mount либо путем
установки для нужных каталогов бита SG1D (2000). Во FreeBSD этот режим
всегда включен, так как в данной системе нет команды newgrp.
Поле GECOS”
Поле GECOS не имеет четко определенного синтаксиса. Первоначально
в Beil Labs его использовали для регистрации информации, необходимой при
передаче пакетных заданий из UNIX-системы мэйнфрейму, работающему под
управлением GECOS. Сейчас осталось одно название.
Она доступна по адресу ftp://ftp.colorado.edu/its/unix/src/uniquid.tar.gz.
Когда фирма Honeywell приобрела компьютерное подразделение компании General Electric,
название GECOS поменяли на GCOS. В настоящее время используются оба варианта
написания.
Г лова 6 Подключение новых пользовотелей
101
Как правило, это поле используют для хранения персональной инфор-
мации о каждом пользователе. Некоторые программы заменяют символ
в поле GECOS регистрационным именем пользователя, что позволяет немного
сократить объем вводимых данных В частности, это относится к программам
finger и sendmail. Лучше не полагаться на подобную возможность.
Программа finger интерпретирует разделенные запятыми элементы поля
GECOS в следующем порядке:
•	полное имя (часто используется только это поле);
•	номер офиса;
•	рабочий телефон;
•	домашний телефон.
С помощью команды chfn (passwd -g в Solaris) можно изменять инфор-
мацию, содержащуюся в поле GECOS. Эта команда полезна для ведения и
обновления списка телефонных номеров, но ею часто злоупотребляют:
пользователь может изменить информацию так, что она станет нецензурной
или некорректной. В нашем факультетском компьютерном центре, который
посещают толпы старшекурсников, эту команду пришлось отключить.
Начальный каталог
При входе в систему пользователь попадает в свои начальный каталог.
Если на момент регистрации у пользователя нет начального каталога,
выводится сообщение наподобие “no home directory” (начальный каталог
отсутствует). В некоторых системах допускается продолжение процедуры
регистрации, и пользователь попадает в корневой каталог. Есть системы, в
которых регистрация без начального каталога не разрешена.
Если начальные каталоги используются коллективно посредством сетевой
файловой системы, то в случае проблем с сервером или с самой сетью они
могут оказаться недоступными.
Регистрационный интерпретатор команд
В качестве регистрационного интерпретатора, как правило, задается
Войте shell или С shell (соответственно /bin/sh или /bin/csh), но в принципе
это может быть любая программа. В большинстве систем по умолчанию
используется интерпретатор Boume shell, который запускается, если соответ-
ствующее поле в файле /etc/passwd не указано. К другим распространенным
интерпретаторам относятся ksh (Korn shell), bash (Вонте-again shell) и tesh
(усовершенствованная разновидность С shell).
Мы рекомендуем для всех новых пользователей по умолчанию устанавливать
интерпретатор tosh
Во многих системах пользователи могут изменить интерпретатор с
помощью команды chsh. В Solaris лишь суперпользователь имеет право менять
интерпретатор другого пользователя (с помощью команды passwd -е). если
только не используется база данных N1S или NLS+. Файл /etc/shells содержит
список тех интерпретаторов, которые пользователь может выбирать с
помощью команды chsh. Пользователь root может применять эту команду
без ограничений. Проверьте, чтобы элементы файла /etc/shells содержали
полные имена команд.
102
Чость I Основы одминистрировония
6.2.	Файл /etc/master.passwd во FreeBSD
Во FreeBSD настоящим файлом паролей является файл /etc/master.passwd.
Файл /etc/passwd оставлен в целях обратной совместимости, но он генери-
руется на основании “главного” файла и никогда не редактируется напрямую.
Изменения, производимые в файле /etc/master.passwd с помощью команды
vipw, passwd. ch (в. chsh или chpass, автоматически отражаются на файле
/etc/passwd. Главный файл создается с помощью утилиты pwd_mkdb.
Файл mastcr.passwd выступает в роли теневого файла паролей в том
смысле, что он доступен для просмотра только пользователю root (в файле
/etc/passwd не содержится никаких паролей). В нем имеется три дополни-
тельных поля:
•	класс регистрации;
•	время изменения пароля;
•	срок действия учетной записи.
Поле класса регистрации (если он задан) содержит ссылку на запись в
файле /etc/login.conf. Класс регистрации определяет пользовательские квоты
на использование ресурсов и другие параметры регистрации (см. следующий
параграф).
Второе поле необходимо для реализации механизма, известного как
устаревание паролей. Это поле содержит время (число секунд, прошедших от
начала эпохи UNIX — 1 января 1970 г.), по истечении которого пользователь
должен будет изменить свой пароль. Если оставить поле пустым, пароль
никогда не устареет. Нам не очень нравится идея устаревания паролей
(см. параграф 21.3).
В третьем поле хранится дата (в том же формате, что и в предыдущем
случае), после которой учетная запись пользователя станет недействительной
и он не сможет зарегистрироваться в системе, если только администратор не
сбросит это поле. Поле также можно оставить пустым, чтобы учетная запись
никогда не устарела.
6.3.	Файл /etc/login.conf во FreeBSD
Файл /etc/login во FreeBSD содержит параметры учетных записей для
пользователей и групп. Его формат напоминает формат файлов termcap и
printcap. Файл состоит из разделенных двоеточиями пар ключ/значение и
булевых флагов.
Когда пользователь регистрируется в системе, поле класса регистрации
в файле /etc/master.passwd определяет, какую запись из файла /etc/login.conf
следует применить. Если класс не был задан, подразумевается класс default.
Запись в файле /etc/login.conf может задавать следующие параметры:
•	квоты ресурсов (максимальный размер процесса, число открытых файлов
и т.д.);
•	регистрационные ограничения (когда можно входить в систему и какова
длительность сеанса);
•	стандартные значения переменных среды;
•	стандартные путевые имена (переменные PATH, MAN PATH и др.);
•	местоположение файла, содержащего сообщение дня;
•	параметры доступа к узлам и терминалам;
•	стандартное значение шпазк;
Глово 6. Подключение новых пользователей
103
•	регистрационные параметры (минимальная длина пароля, срок устарева-
ния пароля).
В следующем примере для системного администратора переопределяется
ряд стандартных параметров:
sysadmin:'
:ignorenologin;\
:requirehomeE:\
:maxproc-uniimited:\
: oper.f iles^unlimited:
:tc-default:
Пользователям, имеющим класс регистрации sysadmin, разрешается
регистрироваться, даже если их имя упомянуто в файле /var/ruii/nologin Они
могут входить в систему, даже если у них нет начального каталога (это
позволяет регистрироваться, когда сетевая файловая система не работает).
Пользователи класса sysadmin могут запускать любое число процессов и
открывать произвольное количество файлов’. В последней строке подключа-
ется содержимое записи default.
6 4. Файл /etc/shadow в Solaris и Red Hat
Использование теневого файла паролей в Solaris является обязательным.
В Red Hai для работы с ним требуется наличие пакета shadow.
Файл /etc/shadow доступен для чтения только суперпользователю и
предназначен для хранения зашифрованных паролей подальше от любопыт-
ных глаз В нем также содержится учетная информация, которая недоступна
в файле /etc/passwd. В отличие от файла master.passwd во FreeBSD, файл
shadow не включает в себя файл passwd, и последний не генерируется
автоматически при изменении теневого файла. Оба файла необходимо
сопровождать независимо друг от друга.
Подобно файлу /etc/passwd, файл /etc/shadow содержит одну строку для
каждого пользователя. Каждая строка состоит из 9 полей, разделенных
двоеточиями:
•	регистрационное имя;
•	зашифрованный пароль;
•	дата последнего изменения пароля;
•	минимальное число дней между изменениями пароля;
•	максимальное число дней между изменениями пароля;
•	число дней, которое должно остаться до истечения срока действия пароля,
чтобы было выдано предупреждение:
•	период отсутствия активности, после которого учетная запись будет
отменена;
•	срок действия учетной записи;
•	флаги.
Лишь первые два поля должны быть непустыми. Поля дат задаются в
виде числа дней (не секунд), прошедших с 1-го января 1970 г. Это отличается
Имеется жесткое ограничение на число процессов и открытых файлов, с которыми может
работать ядро, но искусственно это ограничение задать нельзя
104
Честь I. Основы одминистри ровен ИЯ
от стандартного способа вычисления времени в UMIX-смстемах. К счастью,
задавать эти поля можно с помошью команды user-mod.
Типичная запись выглядит так:
mil left: ir.NQ. VAsclWn.: 11031: : 1BD;14 : r18627:
Вот более подробное описание каждого поля:
•	Регистраиионное имя берется из файла /etc/passwd. Оно связывает записи
в файлах passwd и shadow,
•	Зашифрованный пароль идентичен тому, который ранее хранился в файле
/etc/passwd.
•	Поле последнего изменения содержит время, когда пользователь послед-
ний раз менял свой пароль. Это поле обычно заполняется программой
/Ыл/passwd.
•	В четвертом поле задается число дней, которые должны пройти, прежде
чем пользователь сможет снова изменить пароль Эта возможность
кажется нам бесполезной и даже опасной, если в течение указанного
времени будет обнаружено нарушение в системе зашиты. Поэтому мы
не рекомендуем устанавливать данное поле
•	В пятом поле задано максимальное число дней между двумя изменениями
пароля. Это дает возможность администраторам заставлять пользователей
менять свои пароли (см. параграф 21.3). В Linux максимальное время
жизни пароля определяется суммой значений данного и седьмого полей.
•	В шестом поле задано количество дней, остающихся до момента
устаревания пароля, когда программа login должна начать предупреждать
пользователя о грядушем изменении пароля.
•	В Solaris и Linux седьмое поле интерпретируется по-разному.
— Solaris поступает так: если пользователь не регистрировался в системе
в течение указанного времени, его учетная запись будет отключена.
Неиспользуемые учетные записи являются любимой мишенью хаке-
ров. а данное поле дает администратору возможность своевременно
предотвращать атаки. Оно, однако, работает только в том случае,
когда имя пользователя можно найти в файле /var/adni/lastiog.
Пользователи, которые никогда не регистрировались в системе, не
могут быть отключены автоматически. Описанный механизм не очень
хорошо работает в сетевой среде, поскольку на каждом компьютере
имеется свой файл lastlog.
— В Linux все осуществляется совершенно по-другому. Данное поле
залает, сколько дней после устаревания пароля необходимо ждать,
прежде чем отменить учетную запись. Это совершенно неоправданное
изменение, так как механизм, используемый в Solaris, намного
удобнее. Ситуация усугубляется также тем, что в документации к
Linux назначение паля описано довольно расплывчато и нечетко. Нам
пришлось обратиться к исходным текстам системы, чтобы понять,
как она работает.
•	В восьмом поле задана дата, когда учетная запись будет отменена. После
этого пользователи нс смогут зарегистрироваться в системе, пока
администратор не сбросит данное поле. Если поле оставлено пустым,
учетная запись всегда будет активной.
•	Девятое поле в настоящее время всегда остается пустым; оно зарезерви-
ровано на будущее.
Ггова 6, Подключение новых пользователей
105
Теперь, когда мы выяснили назначение полей, давайте вернемся к
рассмотренному выше примеру:
millert:inNO.VAsclWn,:11031::180:14::18627:
В этой записи говорится о том. что пользователь milled последний раз
менял свой пароль 14-го марта 2000 г. Следующий раз пароль должен быть
изменен через 180 дней. За две недели до этого пользователь начнет получать
предупреждения о необходимости смены пароля Учетная запись действи-
тельна до 31-го декабря 2001 г.
6.5.
6 6
Файл /etc/group
Файл /etc/group содержит имена UNIX-групп и списки членов каждой
группы. Например:
wheel:*:О:root,evi,garth,scott,Trent
csstaff:*:10:lloyd,evi
student:*:200:dotty
Каждая строка представляет одну группу и содержит четыре поля:
•	имя группы;
•	зашифрованный пароль (устаревшее, редко используемое поле).
•	идентификатор группы;
•	список членов (разделяются запятыми).
Как и в файле /etc/passwd, поля разделяются двоеточиями. В некоторых
системах длина имени группы не должна превышать 8 символов. Несмотря
на наличие поля пароля (с помошью которого пользователи могут присое-
диниться к группе, выполнив команду newgrp), последний задается редко.
В большинстве случаев в это поле вводится звездочка (•), но можно оставить
его пустым.
Будьте аккуратны, чтобы случайно не вставить пробелы между именами
пользователей группы. В большинстве систем любая информация после
первого пробела игнорируется.
Имена групп и их идентификаторы должны быть одинаковыми на всех
компьютерах, получающих совместный доступ к файлам посредством NFS.
Этого трудно достичь в гетерогенной среде, поскольку разные операционные
системы используют разные идентификаторы для одних и тех же групп. Мы
считаем, что по умолчанию пользователь не должен регистрироваться как
член системной группы. Это также касается групп, создаваемых поставщи-
ками, в частности staff.
Чтобы избежать конфликтов, связанных с идентификаторами стандартных
групп, рекомендуем выбирать идентификаторы локальных групп, начиная с
номера 100 или последнего номера стандартной группы, в зависимости от
того, какой из них больше.
Подключение пользователей
Прежде чем создавать учетную запись для нового пользователя, крайне
важно потребовать от него подписать соглашение о правилах работы
пользователей. (Как'” У вас нет такого соглашения? Немедленно прочтите
параграф 27.1. чтобы узнать, для чего нужно подобное соглашение и как его
составлять.)
У пользователей нет особых причин подписывать соглашение, поэтому
в ваших интересах убедить их сделать это. После того как учетная 1апись
106
Чость I. Основы ОДМИНИСТрИрОВОНИВ
создана, добиться подписи может оказаться проблематично. Так что лучше
получить ее заранее.
Процесс подключения нового пользователя состоит из целого ряда этапов.
Три из них определяются системными требованиями, два связаны с
формированием пользовательской среды, а еще несколько могут понадобиться
для целей системного администрирования.
Обязательные этапы:
•	отредактировать файлы passwd и shadow с целью создания учетной записи
пользователя;
•	установить исходный пароль:
•	создать начальный каталог для нового пользователя.
Пользовательские этапы:
•	скопировать в начальный каталог пользователя стандартные конфигура-
ционные сценарии;
•	установить каталог электронной почты и создать почтовые псевдонимы.
Административные этапы:
•	добавить запись нового пользователя в файл /etc/group;
•	установить дисковые квоты;
•	проверить правильность создания учетной записи.
Каждый поставщик ОС предоставляет свои средства для автоматизации
этого процесса, но ниже мы подробно опишем все действия так, как если
бы их пришлось выпонять вручную. Все эти операции необходимо выполнять
с правами суперпользователя, зарегистрировавшись в системе под именем
root или воспользовавшись программой sudo.
Редактирование файлов passwd и shadow
Чтобы безопасно редактировать файл passwd. выполните команду vipw,
которая запустит текстовый редактор с копией файла. По умолчанию выбран
редактор vi. но эту установку можно изменить, задав новое значение
переменной среды EDITOR. Существование временной копии файла служит
своего рода блокировкой: команда vipw позволяет только одному пользователю
редактировать файл passwd. Когда пользователь выходит из редактора, команда
vipw заменяет исходный файл passwd отредактированной копией.
ФВ Solaris команда vipw спрашивает, хотите ли вы отредактировать файл
shadow после окончания работы с файлом passwd. Необходимо ответить “да”.
Во FreeBSD команда vipw редактирует файл master.passwd. а не /etc/passwd.
После внесения изменений она вызывает утилиту pwd mkdb, которая создает
файл passwd и две версии файла master.passwd (одна содержит зашифрованные
пароли и доступна только пользователю root, а другая не содержит паролей
и доступна для всеобщего обозрения).
Например, для создания учетной записи tyler необходимо добавить в файл
/etc/passwd следующую строку:
tyler: * : 103:100:Ту1ег Stevens, ЕСЕЕ 3-27, х7919, :/hojne/staf f/tyler :
/bin/csh
Обратите внимание на отсутствие зашифрованного пароля. Если бы в
системе использовался файл shadow,, мы бы записали в соответствующее поле
символ У и добавили в файл /etc/shadow такую строку:
tyler:*.-: : : ::18627-_
Глово 6 Подключение новых пользователей
107
В этой строке говорится о том. что у пользователя tyler нет зашифро-
ванного пароля, а учетная запись действительна до 31-го декабря 2001 г
Задание исходного пароля
Суперпользователь может изменить пароль любого пользователя с помо-
щью следующей команды:
i passwd пользователь
Команда passwd запросит новый пароль и потребует повторить его. Если
введен короткий пароль, состоящий только из строчных букв, команда passwd
попросит задать что-нибудь подлиннее. Система FreeBSD может принять
такой пароль, если он введен три раза подряд, но в большинстве других
систем требуется придумать пароль, состоящий из смеси строчных и
прописных букв и имеющий длину около 8 символов. Если первая попытка
не понравится команде passwd, она, возможно, сообщит о том. какие правила
действуют в конкретной реализации UNIX.
Правила выбора паролей приведены в параграфе 21.3.
Иногда пользователям требуется помошь при выборе пароля. Мы
рекомендуем заменить системный вариант команды passwd обновленной
версией, которая проверяет вводимые пароли на вероятность взлома. Таких
версий существует несколько. Мы предпочитаем утилиту npasswd. доступную
по следующему адресу:
htip://www.uiexas.edu/cc/unix/software/npassv-'d
Программа passwd, имеющаяся в Red Hat, проверяет, не входит ли пароль
в системный словарь. Это не столь надежная проверка, как та. которую
выполняет программа npasswd, но все же она полезна.
Никогда не оставляйте без пароля новую учетную запись или запись с
доступом к интерпретатору команд
Создание начального каталога
Каждый вновь создаваемый каталог изначально принадлежит пользова-
телю root, поэтому необходимо изменить его владельца и группу с помощью
команд chown и chgrp. Следующая группа команд создаст начальный каталог
для пользователя tyler
> mkdir /home/staff/tyler
# chown tyler /Ноше/staff/tyler
# chgrp staff /home/вtaff/tyler
# chmod 7DD /home/staff/tyler
Копировоние конфигурационных файлов
Работу некоторых команд и утилит можно настроить, поместив файлы
конфигурации в свой начальный каталог. Имена таких файлов традиционно
начинаются с точки, поэтому команда Is не включает их в листинги каталогов,
если только не указана опция -а. Некоторые наиболее часто встречающиеся
файлы перечислены в табл. 6.1.
Если у вас еще нет набора универсальных файлов конфигурации, создайте
их в каталоге /usr/local/lib/skel с помощью текстового редактора. Лучше всего
воспользоваться заготовками, оставленными разработчиками системы в
каталоге /etc/skel (/usr/share/skel во FreeBSD), если он есть.
. 38
Часть I. Основы администрирования
Таблице 6.1. Типичные файлы конфигурации		
, Утилита	Имя файла	Типичное применение
esb/tesb	.login	Установка типа терминала Установка переменных среды Установка опций biff и mesg
	.eshre	Установка псевдонимов команд Установка переменной среды PATH Установка значения unuuk Установка строки приглашении, формирование списка предыстории
	.logout	Вывод напоминаний Очистка экрана
lb	.profile	Аналог файлов .login и .esbre для Bourne shell
vi	.cxrc	Установка опинй редактора vi
eraser	.emacs_pro	Установка опций редактора етпасл Функциональная привязка клавиш редактора erases
rasilx	.mailrc	Задание персональных почтовых псевдонимов Установка параметров почтового клиента
Un	.newsrc	Задание списка телеконференций
xrdb	.Xdefaulu	Задание параметров конфигурации XII: шрифты, цвета И Т.Д.
itartx	.xlnitrc	Задание начальной среды XII
Убедитесь, что файлы конфигурации содержат стандартные значения,
приемлемые для неподготовленных пользователей. Не пытайтесь, однако,
“защитить” пользователей от операционной системы. Такие псевдонимы, как
alias dir Is -1
alias rm rm -i
alias ср ср -1
считаются дурным тоном.
В каталоге /etc могут содержаться системные конфигурационные файлы,
обрабатываемые раньше пользовательских. Например, во всех наших тестовых
системах интерпретатор Bourne shell читал файл /etc/profile. прежде чем
начинать обрабатывать файл '/.profile.
Последовательность команд инсталляции конфигурационных файлов для
нового пользователя tyler будет выглядеть следующим образом:
# ср /uar/local/lib/sk«l/.[a-zA-Z]• -/tylar
t chmod 644 '/tyler/.[a-zA-Z]*
# chown tyler '/tyler/.[a-zA-Z]*
» chgrp staff ~/tyler/.[a-zA-Z]*
Отметим, что нельзя использовать команду
# chown tylar -/tylar/.*
иначе пользователь tyler станет владельцем не только своих собственных
файлов, но также родительского каталога < 'home staff). Это очень
распространенная и опасная ошибка системного администратора
Назначение каталога для электронной почты
Пользователи предпочитают получать электронную почту на какой-то
одной машине. Это часто реализуется путем добавления записи в файл
Глово 6. Подключение новых пользовотелей
Ю9
глобальных псевдонимов /etc/mail/aliases или в пользовательскую базу данных
системы sendmail Информация об электронной почте приводится в главе 19,
а способы организации почтовых каталогов рассматриваются начиная с
параграфа 19.3.
Редактирование файла /etc/group
Продолжая добавление нового пользователя tyler. необходимо добавить
его регистрационное имя в список пользователей группы с номером 100,
поскольку именно эту группу мы назначили ему по умолчанию в файле
/etc/passwd. Строго говоря, пользователь tyler будет в группе номер 100
независимо от того, указан он в файле /etc/group или нет, потому что это
членство уже предоставлено ему благодаря записи файла passwd. Тем не менее,
указанную информацию желательно внести в файл /etc/groBp. чтобы можно
было всегда узнать, какие пользователи к каким группам относятся .
Предположим, что нам нужно также включить пользователя tyler в группу
wheel. В некоторых системах только члены этой группы могут выполнять
команду su В этом случае следует внести такие изменения в файл /etc/group:
wheel:w:C:root,evi,garth,scott,trent, tyler
csstaff::100:11 oyd,evi,tyler
Установка дисковых квот
Если в системе заданы дисковые квоты, их необходимо устанавливать
для каждой новой учетной записи с помошъю команды edquota. Эту команду
можно использовать для интерактивного задания квот, но чаще всего удобнее
назначать новому пользователю такие же квоты, как и у существующих
пользователей, например:
# edquota -р пользователь_лрототип новый_пользователь
Такой метод использования команды edquota особенно полезен в
сценариях adduser
Поскольку в наши дни жесткие диски относительно дешевы, мы не
являемся сторонниками дисковых квот. Они создают больше проблем, чем
решают, и вызывают дополнительную головную боль у администраторов.
Много лет назад, когда мы использовали дисковые квоты, нам пришлось
создать несколько учетных записей только для того, чтобы они служили
прототипами пользовательских квот.
Проверка нового регистрационного имени
Чтобы проверить, правильно ли сформирована новая учетная запись,
сначала выйдите из системы, а затем зарегистрируйтесь как новый пользо-
ватель и выполните следующие команды:
% pwd	/• проверка начального каталога */
% la -1а	/• проверка файлов конфигурации пользователя/группы */
Для ядра в принципе не имеет значения, что содержится в файлах /etc/passwd И /etc/group.
Оно оперирует только идентификаторами пользователя и группы. В файлах passwd и group
хранится учетная информация, используемая высокоуровневым программным обеспечени-
ем, например программой login Подробности процесса регистрации приведены в параг-
рафе 7.8.
Г .1
Чость I. Основы одминистрировония
0
6.7.
Администратор должен сообщить новым пользователям об их регистра-
ционных именах и исходных паролях. Это также удобный момент для того,
чтобы рассказать новичкам о том, какие традиции существуют в данной
организации и какие есть дополнительные документы, регламентирующие
работу пользователей.
Если в организации установлен порядок, согласно которому пользователи
должны подписать письменный контракт, то не забудьте выполнить эту
процедуру до создания учетной записи. Это предотвратит возможные
недоразумения и укрепит правовую базу санкций, которые впоследствии
администратору, возможно, придется применять.
Подробнее о письменных контрактах с пользователями рассказывается в
параграфе 27. 7.
Кроме того, не забудьте напомнить новым пользователям о необходимо-
сти немедленной замены паролей.
Удаление пользователей
Когда пользователь покидает организацию, его учетная запись и файлы
должны быть удалены из системы. Эта процедура охватывает удаление всех
ссылок на регистрационное имя, которые были введены вручную или с
помощью сценария adduser. Иными словами, необходимо проделать следующее:
•	сделать дисковую квоту удаляемого пользователя (если таковые исполь-
зуются) равной нулю;
•	удалить пользователя из локальных баз данных и телефонных списков;
•	удалить пользовательские псевдонимы из файла aliases, задать перена-
правление поступающих ему сообщений;
•	стереть пользовательские задания из crontab-файла и из очереди команды al;
•	уничтожить пользовательские процессы, которые еще выполняются;
•	уничтожить все принадлежащие пользователю временные файлы в
каталогах /var/tmp и /tmp;
•	удалить записи пользователя из файла passwd и group;
•	удалить начальный каталог пользователя;
•	удалить почтовый каталог пользователя.
Перед тем как уничтожить начальный каталог пользователя, необходимо
переместить из него в другие каталоги все файлы, которые нужны остальным
пользователям. Поскольку не всегда можно с уверенностью сказать, какие
файлы понадобятся, а какие — нет, лучше скопировать пользовательские
начальный и почтовый каталоги на магнитную ленту.
После удаления пользователя убедитесь, что в системе не осталось файлов
с его идентификатором. Проще всего сделать это с помощью команды quot.
Например, чтобы узнать, каким пользователям принадлежат файлы в каталоге
/home, задайте такую команду:
#	quot /home
Zdev/rdsk/c0t3d0s6:
156254 millert
34520 hilbert
5572 #1161
683 #1069
Глово 6. Подключение новых польэовотелей
111
Эта команда не только сообщает число дисковых блоков, занятых
файлами каждого пользователя, но также говорит, что два идентификатора
не обнаружены в файле /etc/passwd Чтобы узнать точный путь к этим файлам,
выполните следующую команду:
i find -х /horn* -nou»»r -print
Она будет выполняться гораздо дольше, чем команда quot.
Команда quol работает только с разделами локального диска. Она не
может анализировать файловые системы, смонтированные через NFS.
6.8.	Отключение регистрационных имен
Иногда нужно временно отключить регистрационное имя пользователя.
До вторжения сетей в мир UNIX достаточно было просто поставить звездочку
перед зашифрованным паролем, чтобы пользователь не смог войти в систему
Тем не менее, он все равно имел возможность входа в систему по сети без
указания пароля, поэтому данная методика перестала быть полезной.
Сегодня мы заменяем командный интерпретатор пользователя програм-
мой. которая выдает сообщение, поясняющее, почему данное регистрацион-
ное имя отключено, и содержащее инструкции по исправлению ситуации
Такой псевдоинтерпретатор не должен быть указан в файле /etc/shells. Многие
демоны, предоставляющие нерегистрацнонный доступ к системе (например,
ftpd), проверяют, упомянут ли интерпретатор пользователя в файле /etc/shells;
если он там не указан, вход в систему будет запретен (именно это нам и
требуется).
Правда, есть одна проблема. По умолчанию программа sendmail не
доставляет почту тем пользователям, интерпретаторы которых не указаны в
файле /etc/shells. Чтобы изменить эту установку, добавьте в файл /etc/shells
ложный интерпретатор с именем /SENDMAIL/ANY'/SHELL
6.9.	Системные утилиты управления учетными записями
В Solaris, HP-UX и Red Hat имеется схожий набор ¥тиж, помогающих
автоматизировать процесс создания, удаления и модификации групп и
пользовательских учетных записей. Во FreeBSD используется другой набор
утилит.
Команда useradd добавляет записи о пользователях в файл passwd (и в
файл shadow, если он есть). Она имеет интерфейс командной строки и легко
запускается вручную или из сценария adduser Команда usermod изменяет
записи файла passwd для существующих пользователей Команда userdel
удаляет пользователя из системы, при необходимости уничтожая и его
начальный каталог. Команды groupadd. groupmod и groupdel выполняют
аналогичные действия по отношению к файлу /etc/group.
Хотя эти команды удобны, в большинстве случаев их недостаточно, чтобы
реализовать все правила управления системой. Мы рекомендуем написать
собственные сценарии adduser и miuser. Для этого хорошо подходил язык Perl.
Вот как можно добавить в систему нового пользователя hilbert
* useradd hilbert
Эта команда создает в файле /etc/passwd следующую запись:
hilbert:*:I05:20::/home/hilbert:/bin/ah
112
Чость I Основы сдминистрировония
Обратите внимание на то, что поле пароля содержит звездочку. Таким
образом, доступ к учетной записи будет закрыт до тех пор, пока не будет
назначен реальный пароль.
Команда useradd имеет ряд полезных аргументов. В следующем примере
мы указываем, что основной группой пользователя hilbert является группа
faculty; кроме того, он входит в группу famous. Помимо этого, мы задаем
другой начальный каталог и просим команду useradd создать его, если он
еше не существует.
# u*eradd -с "David Hilbert" -d /home/math/hilbart -g faculty
-C famoua -m -a /bin/tceh hilbert
В результате в файле /etc/passwd появится такая запись:
bilbert:*:105:30:David Hilbert:/home/math/hilbert:/bin/tcsh
Кроме того, пользователь hilbert будет добавлен в группы faculty и famous
в файле /etc/group; появится также каталог /home/math/hllbert, заполненный
на основании содержимого каталога /etc/skel. В Solaris (и в Red Hat, если в
системе используется файл shadow) запись о пользователе hilbert будет
помешена в файл /etc/shadow.
Узнать текущие установки вы можете, выполнив команду useradd -D.
В HP-UX и Red Hat задать начальные параметры можно в файле /etc/de-
fault/useradd.
Команда usermod модифицирует существующую учетную запись и при-
нимает те же опции, что и команда useradd. Например, следующая команда
задает конечный срок существования учетной записи hilbert — 4 июля
2002 г.’:
# usermod -в "July 4, 2002" hilbert
Команда userdel уничтожает учетную запись, отменяя таким образом все
изменения, сделанные командой useradd. Чтобы удалить пользователя hilbert,
достаточно ввести
• userdel hilbert
Эта команда удалит все ссылки на учетную запись hilbert из файлов
passwd, shadow (если он есть) и group. По умолчанию начальный каталог
пользователя не удаляется. (В своей системе мы обычно не уничтожаем
начальные каталоги в течение нескольких недель, чтобы уменьшить число
возможных восстановлений с резервных копий на магнитной ленте.)
Во FreeBSD имеются сценарии adduser и rmuser, написанные на Perl. Их
можно либо использовать в неизменном виде, либо модифицировать под
свои нужды. Сценарий rmuser отлично справляется с удалением пользова-
тельских файлов и процессов (команда userdel даже не пытается этого делать).
В отличие от команд useradd и userdel, сценарии adduser и rmuser являются
интерактивными программами. Глобальные установки сценария adduser
хранятся в файле /etc/adduser.conf. По умолчанию сценарий adduser копирует
файлы конфигурации из каталога /usr/share/skel.
В HP-UX это можно сделать, только если система сконфигурирована в “доверительном
режиме".
Глава 6. Подключение новых пользователей
113
7 Последовательные устройства
Последовательные порты — это, без сомнения, самое удобное средство
ввода-вывода в UNIX-системах. Они не слишком быстродействующие, но
достаточно гибкие и присутствуют в любых машинах — от персональных
компьютеров до мэйнфреймов.
Последовательные порты можно использовать для связи с самыми
разными устройствами, в том числе принтерами, терминалами и другими
компьютерами. Устройство может подключаться к системе либо непосредст-
венно (с помощью кабеля), либо по телефонной линии через модемы,
обеспечивающие модуляцию-демодуляцию последовательных сигналов.
В этой главе рассказывается о том, как подключать к системе последо-
вательные устройства и конфигурировать программное обеспечение с целью
максимального использования возможностей этих устройств. В наших при-
мерах описано подключение терминалов, модемов и принтеров; другие
последовательные устройства подключаются практически аналогично.
7.1. Стандарты последовательной передачи данных
Большинство последовательных портов работает согласно различным
вариантам стандарта RS-232. Этот стандарт определяет электрические харак-
теристики и назначение каждого сигнального провода, а также разводку
контактов традиционного 25-контактного последовательного разъемного со-
единения, известного как разъем DB-25 (рис. А).
Полный набор сигнальных проводов интерфейса RS-232" чаще всего
избыточен, так как он предназначен для распространения сигналов, многие
из которых не используются в основных режимах передачи данных. Кроме
того, разъемные соединения DB-25 велики для установки в коммутационных
панелях и портативных компьютерах. Поэтому сейчас широко применяются
альтернативные модели разъемов (см. параграф 7.2).
’ С технической точки зрения правильнее называть его стандартом EIA-232-Е. Но если вы
будете так говорить, вряд ли вас кто-нибудь поймет.
114
Чость I Основы одминистрировония
Разъем
Номера выводов
Рис. А. Разъемное соединение DB-25
В традиционном интерфейсе RS-232 используется экранированная витая
пара (обычно это многожильный провод сортамента 22). Сначала в RS-232
применялись сигналы постоянного тока напряжением ±12 В, но сейчас
больше распространено напряжение ±5 В. Иногда используют напряжение
±3 В. Все эти значения соответствуют спецификации RS-232, поэтому
допускается соединение устройств с разными уровнями напряжений.
Интерфейс RS-232 не является электрически сбалансированной системой:
в нем имеется отдельный провод для передачи данных в каждом направлении.
Следовательно, применять витую пару нет необходимости. Преимуществом
экранированной витой пары является само экранирование, позволяющее
уменьшить риск внешних воздействий. Но когда два информационных провода
(TD и RD) скручиваются в одну пару, может произойти снижение надежности
и диапазона распространяемых сигналов, так что лучше этого не делать.
Нет общепринятого соглашения о том, какие сигналы стандарта RS-232
должны совместно распространяться по витой паре. Некоторые источники
рекомендуют спаривать провод заземления с проводами TD и RD, но,
во-первых, это требует выделения дополнительного провода, а во-вторых,
появляется несколько путей заземления. Насколько нам известно, придержи-
ваться подобного соглашения необязательно.
Разъемное соединение DB-25 состоит из вилки (разъем с торчащими
штырьками; обозначается как DB-25P) и розетки, или гнезда (“материнский”
разъем с соответствующими отверстиями; обозначается как DB-25S). Возле
штырьков и отверстий нанесены крошечные числа от 1 до 25 — это номера
контактов. Лучше всего они будут видны, если поднести разъем к свету и
посмотреть на него под углом. Иногда маркируются только выводы 1. 13, 14
и 25.
Вилка DB-25 изображена на рис. А. Во всех последовательных разъемных
соединениях номера контактов на розетке зеркально отражают номера на
вилке, чтобы при стыковке разъемов контакты с одинаковыми номерами
совпадали.
Обратите внимание: у разъема, изображенного на рисунке, установлено
всего семь выводов. Именно так чаще всего и бывает. Сигналы интерфейса
RS-232 и соответствующие им контакты разъемного соединения DB-25
перечислены в табл. 7.1. На практике используются только сигналы 1—8
и 20, остальные можно проигнорировать.
Глово 7. Поспедовотельные устройство
115
Таблица 7.1. Сигналы интерфейса RS-232 и соответствующие им контакты
оозъемного соединения DB-25
1	FQ	Защитное заземление
2	TD	Передаваемые данные
3	RD	Принимаемые денные
4	RTS	Готовность к передаче
5	CTS	Готовность к приему
6	DSR	Готовность данных
7	SG	Заземление сигнала
8	DCD	Обнаружение несущей
9	—	Положительное контрольное напряжение
10	—	Отрицательное контрольное напряжение
11	—	Не назначен
12	SDCD	Вторичный сигнал DCD
13	SCTS	Вторичный сигнал CTS
14	STD	Вторичный сигнал TD
15	TC	Синхронизация передачи
16	SRD	Вторичный сигнал RD
17	RC	Синхронизация приема
18	—	Не иазначен
19	SRTS	Вторичный сигнал RTS
20	DTR	Готовность терминала
21	SQ	Детектор качества сигналя
22	R1	Индикатор вызова
23	DRS	Селектор скорости передачи данных
24	SCTE	Внешняя синхронизация передачи
25	BUSY	Занято
Для последовательных устройств существуют две конфигурации кабельной
системы: DTE (Data Terminal Equipment — терминальное оборудование) и
DCE (Data Communications Equipment — аппаратура передачи данных). Эти
конфигурации определяют, какие сигналы устройство будет ожидать на тех
или иных контактах разъемного соединения. Каждое устройство конфигури-
руется либо как DTE, либо как DCE, хотя некоторые устройства поддержи-
вают оба варианта (но не одновременно). Компьютеры, терминалы и
принтеры чаше всего относятся к типу DTE, тогда как модемы являются
DCE-устройствами. Последовательные устройства DTE и DCE могут взаи-
модействовать друг с другом в произвольных сочетаниях, но в разных случаях
требуются разные кабели.
Смысла в одновременном существовании двух конфигураций нет. по-
скольку для всего оборудования может использоваться одна и та же разводка
контактов. Просто это одно из многих бессмысленных исторических наследий
стандарта RS-232.
Ниже перечислены особенности обеих конфигураций:
•	Разводка контактов в любом разъемном соединении RS-232 всегда
одинакова независимо от того, вилка это или розетка (штырьки всегда
116
Чость I Основы администрировония
совпадают с соответствующими отверстиями) и где находится разъем: иа
кабеле. DTE- или D СЕ-устройстве.
•	Спецификация RS-232 построена на модели сквозного соединения DTE-
и DCE-устройств. (Под “сквозным" понимается соединение, при котором
линия TD DTE-устройства подключается к линии TD DCE-устроЙства и
т.д. Все одноименные контакты соединяются друг с другом.)
•	Именование сигналов произведено применительно к DTE-устройству.
Например, название сигнала TD (transmitted data — передаваемые дан-
ные) в действительности означает ‘‘данные, передаваемые от DTE-уст-
ройства к DCE-устройству”. Несмотря на название, контакт TD служит
для приема данных на DCЕ-устройстве. Аналогичным образом, контакт RD
является входным на DTE-устройстве и выходным на DCE-устройстве.
•	Когда кабелем соединяют два DTE-устройства (компьютер и терминал
либо компьютер и компьютер), их нужно “обмануть”, заставив думать,
что другая сторона является DCE-устройством. Поскольку оба устройства
будут предполагать передачу данных по линии TD и прием — по линии
RD, необходимо соединить провода крест-накрест, связав выходной
контакт одного устройства с входным контактом другого и наоборот.
•	Подобного рода “перекрещивание" при соединении двух DTE-устройств
требуется для трех групп сигналов. Во-первых, это сигналы TD и RD, о
чем говорилось выше. Во-вторых, это сигналы RTS и CTS. В-третьих,
контакт DTR должен быть связан с контактами DCD и DSR на
противоположном конце.
•	Кабель, соединяющий два DTE-устройства, называется нулъ-модемным.
Подключать к нему модемы нельзя. Кабель для модемов называется
модемным, прямым или обычным.
Изначально предполагалось, что DTE-устройства оснащены вилками, а
DCE-устройства — розетками. Со временем разработчики аппаратных средств
поняли, что вилки являются более хрупкими и чаще подвержены поломкам.
Сегодня в дорогостоящей вычислительной технике, как правило, ставят
розетки, а большинство кабелей с обоих концов имеет вилки.
На рис. Б изображена разводка контактов и схемы соединений нуль-мо-
демным и прямым кабелями. Показаны только “полезные" сигналы.
Рис. Б. Розводкс контоктов и схемы соединения кобелей для разъемов DB-25
Глава 7. Последовательные устройства
117
7.2.
Альтернативные разъемные соединения
Ниже описываются наиболее распространенные альтернативные разъем-
ные соединения: DIN-8, DB-9 и RJ-45. Несмотря на конструктивные
различия, эти соединения обеспечивают доступ к тем же электрическим
сигналам, что и разъем DB-25. Устройства, в которых используются разные
разъемы, всегда совместимы, если правильно выбран кабельный переходник.
Мини-разъем DIN-8
Разъемные соединения DIN-8 применяются в компьютерах Macintosh, в
некоторых портативных компьютерах и на рабочих станциях Эти почти
круглые и исключительно компактные разъемы имеют выводы для семи
наиболее часто используемых сигналов стандарта RS-232 (рис. В)
Разъем	Номера выводов
Рис. В. Вилко DIN-8
У местных поставщиков компьютеров всегда можно приобрести нераз-
борные кабельные переходники DB-25/DIN-8. Не пытайтесь сделать их сами,
потому что разъем D1N-8 настолько мал, что его невозможно собрать
вручную. Разводка контактов разъема DIN-8 дана в табл. 7.2.
Таблица 7.2. Разводке контактов для прямого кабельного перехода DIN-8/DB-25
DIN-8	DB-25	Сигнал	Функция
3	2	TD	Передаваемые данные
5	3	RD	Принимаемые данные
6	4	RTS	Готовность к передаче
2	5	CTS	Готовность к приему
4, 8	7	SG	Заземление сигнала
7	8	DCD	Обнаружение иесушей
1	20	DTR	Готовность терминала
Разъем DB-9
Этот девятиконтактный разъем (внешне напоминающий уменьшенную
копию DB-25) обычно применяется в персональных компьютерах. Он
обеспечивает передачу восьми наиболее часто используемых сигналов стан-
дарта RS-232 (рис. Г).
Г 8
Чость I Основы сдминистрировония
Разъем
Номе а выводов
Рис. Г. Вилка DB-9
У местных поставщиков персональных компьютеров обычно можно
приобрести фабричные кабельные переходники DB-9/DB-25. Разводка кон-
тактов представлена в табл. 7.3.
Таблица 7.3. Розводко контактов для прямого кобелы-юго перехода DB-9/DB-25
DB-9	DB 25	Сигнал	Функция
3	2	TD	Передаваемые данные
2	3	RD	Принимаемые данные
7	4	RTS	Готовность к передаче
8	5	CTS	Готовность к приему
6	6	DSR	Готовность данных
5	7	SG	Заземление сигнала
1	8	DCD	Обнаружение несущей
4	20	DTR	I отовность терминала	
Разъем RJ-45
RJ-45 — это, в сущности, восьмипроводнои модульный телефонный
разъем. Он напоминает стандартное соединение RJ-11. используемое в
телефонных аппаратах в США, но у последнего только 4 штырька, а у разъема
RJ-45 — 8 (рис. Е). Разъемные соединения RJ-45 обычно применяются в
Ethernet, но могут работать и в последовательных линиях.
Разъем	Номера выводов
Рис Д. Вилка RJ-45
Гнезда RJ-45 практически не встречаются в компьютерах и обычном
последовательном оборудовании Их часто применяют в качестве промежуточных
Глова 7. Последовательные устройства
119
соединителей при разводке последовательных линий через коммутационные
панели. Иногда их можно встретить в тех устройствах, где на небольшой
плошали размешено много портов (например, в серверах терминалов).
Разъемы RJ-45, как правило, используются не с витой парой, а с плоским
телефонным кабелем, но оба варианта допустимы в последовательных
соединениях.
Разъемные соединения RJ-45 компактны и дешевы. Они закрепляются
на кабеле с помошью специального обжимного инструмента. Вся процедура
крепления длится менее минуты.
Существует целый ряд стандартов, определяющих соответствие контактов
разъема RJ-45 контактам разъема DB-25. Самый лучший из них — система
Дэйва Йоста (Dave Yost), в которой каждое устройство снабжено гнездом
RJ-45 и используются стандартизированные кабели, позволяющие соединять
как DCE-, так и DTE-устройства.
Стандарт Поста для разъемного соединения RJ-45
Эту спецификацию разработал в июне 1987 г. Дэйв Йост (Dave@Yosl.com). Для
нашей книги он исправил и дополнил ее.
Вот схема, которая позволяет успешно справляться с некоторыми
трудностями стандарта RS-232:
•	Все кабельные разъемы — одного типа (вилки RJ-45).
•	DTE- и DCE-устройства ничем не отличаются друт от друга.
•	Понадобится кабель только одного вила.
•	Можно быстро готовить кабели, используя всего один обжимной
инструмент.
Каждый последовательный порт на всех аппаратных устройствах получает
свой собственный, соответствующим образом разведенный переходник DB-
25/RJ-45 или DB-9/RJ-45. Этот переходник "навечно” привинчивается к
порту. Теперь каждый порт представляет собой один и тот же соединительный
разъем — розетку RJ-45, независимо от того, каким был исходный разъем:
DB-25 или DB-9, DTE- или DCE-типа, вилкой или розеткой.
Установив переходники на порты RS-232, можно подключать к последо-
вательному порту различные устройства без использования нуль-модемов или
нуль-термин алов, без изменения разводки контактов на кабельных разъемах
и без изготовления специальных кабелей. С помощью кабеля одного вида
вы сможете подключать модем к компьютеру, модем к терминалу, терминал
к компьютеру, терминал к терминалу, компьютер к компьютеру и т.д.
Используется восьмипроводной плоский кабель в оболочке. Выводы
разъемов на обоих концах прижаты к проводникам кабеля специальным
обжимным устройством, поэтому паять их не нужно.
Имеется три сигнальных провода (один информационный и два управ-
ляющих) для каждого направления плюс пара проводов заземления. Кабели
разведены не обычным образом (т.е. когда каждый вывод разъема соединяется
с соответствующим выводом на другом конце кабеля), а с “перекруткой",
"зеркальным отображением”, “обратной стыковкой" — называйте как угодно.
Благодаря такому способу разводки кабель соединяет "передающий” штырек
с соответствующим "приемным” штырьком на другом конце кабеля. Подобная
схема работает потому, что расположение сигнальных проводов в плоском
кабеле симметрично, т.е. для каждого провода, по которому перелаются
120
Чость I Основы одминистрировсния
данные, есть соответствующий провод, по которому данные принимаются.
Этот провод расположен зеркально к первому относительно оси кабеля".
В фабричных кабелях RJ-45 обычно используется сквозная разводка,
поэтому необходимо снять разъем с одного конца кабеля и вмонтировать
новый с обратной разводкой. Увеличивать длину кабеля можно с помощью
соединителей “розетка-розетка”, но помните: два перекрученных кабеля,
соединенных таким способом, образуют кабель со сквозным соединением.
Переходники DB-25/RJ-45 производят многие фирмы. Их внутренняя
цветовая кодировка не совпадает с цветами кабелей. Переходники, соедини-
тели и провода сейчас можно свободно купить в магазинах электроники, но,
как это ни печально, они ничем не могут помочь при работе с интерфейсом
RS-232.
Описанная схема была рассчитана на применение плоского экраниро-
ванного кабеля, в котором все провода расположены рядом. В противопо-
ложность этому в витой паре имеется четыре пары проводов, и в каждой
паре провода скручены между собой по всей длине кабеля. Если используется
витая пара (например, кабель категории 5). разводка проводов будет не такой,
как в обычных соединениях RJ-45 (lOBaseT. телефонная линия и т.д.). Нужно
сделать так, чтобы провода 3:4 и 5:6 образовывали пары. Другое сочетание
может привести к возникновению перекрестных помех. Разводка остальных
проводов не имеет значения, но обычно спаривают провода 1:2 и 7;8.
Дополнительная информация о кабеле категории 5 приводится в параграфе 15.2.
Внутри переходника находится гнездо RJ-45. из которого выходят восемь
проводов. К этим проводам с помощью обжимного инструмента прикреплены
штырьки (или. в зависимости от ситуации, контактные гнезда). Эти штырьки
просто вставляются в отверстия разъема RS-232, а затем кожух переходника
защелкивается.
Тоблицо 7.4. Розводко проводов переходников Йаста RJ-45/DB-25 и RJ-45/DB-9
Кабель RJ-45	Переход	Контакт DCE		Контакт ОТЕ			
		DB 25	О В-9	и-ГНОЛ	DB-25	DB-9	Сигнал
1 Коричневый	Голубой	4	7	RTS	5	8	CTS
(к серому)							
2 Голубой	Оранжевый	20	4	DTR	8	1	DCD
(к оранжевому)							
3 Желтый	Черный	2	3	TD	3	2	RD
(к черному)							
4 Зеленый	Красный	7	5	GND	7	5	GND
(к красному)							
5 Красный	Зеленый	7	5	GND	7	5	GND
(к зеленому)							
6 Черный	Желтый	3	2	RD	2	3	TD
(к желтому)							
7 Оранжевый	Коричневый	8	1	DCD	20	4	DTR
(к голубому)							
8 Серый	Белый	5	8	CTS	4	7	RTS
(к коричневому)							
Дэйв не говорит оь этом явно, но нужно понимать, что физической “перекрутки" кабелей
быть не должно. Поскольку разъемы на противоположных концах направлены в разные
стороны, эффект достигается автоматически.
Глово 7 Последовательные устройство
121
0
7.3.
Имеется, однако, такая проблема: оба провода заземления должны быть
заведены в одно гнездо DB-25 или DB-9 (контакты 7 и 5 соответственно).
Эти провода можно спаять либо обжать с помощью специальных приспо-
соблений.
Некоторые DTE-y строй ства требуют, чтобы линия DSR была активна,
прежде чем они смогут посылать данные. Сигнал DSR обычно выдается
DCE-устройством, но можно совершить “подлог”, сведя вместе контакты 20
и 6 (или 4 и 6 в разъеме DB-9). В этом случае DTE-устройство будет получать
сигнал DSR от самого себя при выдаче сигнала DTR.
В некоторых DCE-принтерах контакт 7 переходника RJ-45 (коричневый
провод) должен быть подключен к линии DSR (контакт 6 в разъемах DB-25
и DB-9). Прочтите документацию к принтеру, чтобы узнать, может ли он
выдавать сигналы квитирования по линии DSR. а не DCD.
Спасибо за эту идею ребятам из Беркли. У них несколько иная разводка
(видимо, по историческим причинам), но сама идея пришла именно оттуда.
Если бы я мог узнать, кто конкретно является автором данной схемы, я
поблагодарил бы здесь этого человека персонально.
Дэйв Йост, Лос-Альтос, Калифорния, июль 1999 г.
Аппаратная несущая и программная несущая
При подсоединении и включении устройства сигнал обнаружения несу-
щей (DCD) должен перейти на высокий уровень (+5 В) Этот сигнал подается
на 8-й контакт разъемного соединения DB-25. Если в последовательном
кабеле есть линия DCD и компьютер действительно обращает на нее
внимание, значит, используется аппаратная несущая. В большинстве систем
также допускается применение программной несущей, когда компьютер “делает
вид”, что сигнал DCD всегда присутствует.
Для некоторых устройств (в частности, для терминалов) программная
несущая — подарок судьбы. Она позволяет в каждом последовательном
соединении обходиться всего тремя линиями: передаваемых данных, прини-
маемых данных и заземления сигнала. Но в модемных соединениях сигнал
DCD обязателен. Если терминал подключен через модем и сигнал обнару-
жения несущей пропадает, то модем “зависает”, особенно при передаче
данных на большие расстояния. Известно множество скандальных историй,
когда модем “заклинивало” и линия DCD долго ие освобождалась, а потом
приходили телефонные счета иа астрономические суммы.
В различных версиях UNIX обработка программной несущей осуществ-
ляется по-разному. В ранних версиях системы нужно было ставить “заплату"
в драйвер терминала, что было ие только очень обременительно, но и просто
глупо. Во многих современных системах эта проблема решена путем задания
режима программной несущей для последовательных портов по умолчанию
в системных конфигурационных файлах. Кроме того, можно использовать
команду stty -СLOCAL, которая заставит терминал предполагать наличие
программной несущей в работающей системе. Например, команда
* atty -CLOCAL < /dev/tty03
включает программную несущую для порта ttyO3. В некоторых системах
необходимо указывать оператор >. а не <; обратитесь к документации по
команде stty
122
Чость I. Основы администрирования
7.4.	Аппаратное управление потоком данных
Назначение сигналов CTS и RTS — обеспечить такую скорость передачи
данных, чтобы устройство-приемник успевало их обрабатывать. Например,
если существует опасность переполнения буфера модема (скажем, в том
случае, когда соединение с удаленным узлом работает медленнее, чем
последовательный канал между локальной машиной и модемом), модем может
приказать компьютеру “замолчать", пока буфер не освободится.
Управление потоком данных имеет большое значение для быстродейст-
вующих модемов и очень полезно для принтеров. В системах, где аппаратное
управление потоком данных отсутствует (либо из-за того, что последователь-
ные порты его не понимают, либо из-за того, что в последовательном кабеле
выводы CTS и RTS не подключены), его иногда можно моделировать
программным путем с помощью управляющих ASCH-символов XON и XOFF.
Однако программное управление потоком данных должно явно поддержи-
ваться высокоуровневым программным обеспечением, хотя даже в этом случае
оно функционирует не очень хорошо'.
В аппаратуре фирмы Sun режим управления потоком данных нужно
включить с помощью команды eeprom.
Большинство терминалов игнорирует сигналы CTS и RTS. Те немногие
терминалы, которые для установления связи требуют подтверждения по этим
линиям, можно обмануть, соединив перемычкой контакты 4 и 5 на том конце
кабеля, который подключается к терминалу. Когда терминал посылает сигнал
на вывод 4, заявляя “Я готов", то с вывода 5 он получает этот же сигнал
обратно, что означает “Начинай”. Таким же способом можно решить вопрос
с подтверждением по линиям DTR/DSR/DCD.
7.5.	Длина кабеля
Стандарт RS-232 определяет, что максимальная длина кабеля при
скорости передачи 9600 бит/с должна составлять 75 футов (22,86 м).
Стандарты обычно очень консервативны, и RS-232 — не исключение.
В повседневной работе нам приходилось прокладывать кабель гораздо большей
длины (иногда до 1000 футов). Опыт показывает, что предел находится где-то
между 800 (243,84 м) и 1000 фугами (304,8 м), причем это в значительной
степени зависит от конкретных моделей терминала и компьютера.
7.6.	Файлы последовательных устройств
Последовательные порты представляются в системе файлами устройств,
расположенными в каталоге /dev. У большинства компьютеров имеется два
встроенных последовательных порта. Раньше они обычно назывались /dev/ttya
и /dev/ttyb, но со временем соглашения по наименованию изменились.
Иногда на один и тот же порт ссылаются сразу несколько файлов.
Например, в Solaris с одним портом связаны файлы /dev/cua/a и /dev/term/a,
но у первого младший номер устройства другой:
% ! -1L /dev/terra/a /dev/cua/a
crw-rw-rw-	1 root	sys	29,	0	Jan 15 1998 /dev/term/a
crw------ 1 uucp	uucp	29,	1310T2	Jan 15 1998 /dev/cua/a
Символам XON и XOFF соответствуют сочетания клавиш <Ctrl-Q> и <Ctrl-S> Это
представляет проблему для пользователей редактора emacs. где при нажатии клавиш
<Ctrl-S> по умолчанию вызывается команда поиска. Решить эту' проблему можно, связав
Команду поиска с каким-нибудь другим сочетанием клавиш.
Глово 7. Последовательные устройство
123
Несколько файлов нужно для поддержки модемов, которые обслуживают
как входящие, так и исходящие звонки. В Solaris драйвер разрешает открыть
файл /dev/term/а, только когда модем выдал сигнал DCD, подтвердив наличие
активного соединения (предполагается, что для данного порта не задан режим
программной несущей). Файл /dev/cua/a можно открыть независимо от
состояния линии DCD. Он используется при подключении к модему,
которому нужно сообщить о необходимости сделать звонок. Доступ к любому
из файлов блокируется, если один из них уже открыт.
Во FreeBSD можно задать начальное и заблокированное состояние портов
в файле /etc/rc.serial. Это удобно, если нужно переопределить поведение
плохо написанных программ, неправильно конфигурирующих порты. Если
попытаться задать параметры заблокированного порта и затем открыть его в
программе, ядро проигнорирует попытку переконфигурировать порт (см. раз-
дел документации cio(4)).
Как всегда, имена файлов устройств не имеют особого значения. Их
работа определяется старшим и младшим номерами устройства, я имена
файлов являются лишь общепринятым соглашением'.
В табл. 7.5 перечислены стандартные имена файлов последовательных
портов в наших тестовых системах. Показаны имена для первых двух порток,
остальные именуются аналогичным образом.
Таблице 7.5. Файлы устройств для первых двух последовательных партав
Система	Стандартные 4 айпы	Дополнительные f айлы	Назначение
Solaris	/dev/tenn/[a,b]	/dev/cua/[a,b]	исходящие звонки
HP-UX1	/dev/ttyDp[O,l]	/dev/cuI0p(0.1] /dev/cuaOp[O,l] /dev/ttydOp[O,ll /dcv/c0p[0,l]_!p	модем для исходящих звонков исходящие звонки по прямому соединению модем для входящих звонков последовательный принтер
Red Hat	/dev/tty S(0,1J	/dev/cua[0,1 ]	исходящие звонки (существует только для совместимости)
FreeBSD	/dev/ttyd[O,l]	/dev/cuaa{O,l] /dev/cuala[0.1] /dev/cuaia[0.1]	модем для исходящих звонков модем для исходящих звонков: заблокирован модем для исходящих звонков: в начальном состоянии
1 Подробные пояснения приведены на странице руководства mksf(IM).			
7.7.	Конфигурирование программного обеспечения
для последовательных устройств
После подключения устройства с помощью соответствующего кабеля
следует задать определенную конфигурацию программного обеспечения,
чтобы устройство работало эффективно В отличие от устройств, которые
Это не значит, что их можно менять. Большинство программ предполагает, что система
придерживается стандартного соглашения о наименовании устройств.
124
Чость I. Основы одминисгрировония
подключаются непосредственно к шине компьютера, последовательные уст-
ройства не требуют конфигурирования на уровне ядра’. Тем не менее,
программным средствам высокого уровня все равно нужно сообщить о
наличия новых устройств.
Перечень конфигурационных задач, которые необходимо решать при
подключении нового устройства, зависит от типа устройства и приложений,
в которых оно будет использоваться:
•	Если это аппаратный терминал, нужно дать системе указание ожидать
подключения пользователей к порту терминала. Задайте скорость пере-
дачи и параметры последовательного соединения. Конфигурация терми-
налов описана в следующем параграфе.
•	Модемы, принимающие звонки, конфигурируются аналогично аппарат-
ным терминалам. В некоторых системах возможны незначительные
различия в перечне необходимых процедур.
•	Для конфигурирования выходного модема, который будет использоваться
оператором, следует описать этот модем в файле /etc/remote для команд
tip и си. Как это сделать, объясняется в параграфе 7.13.
•	Для того чтобы использовать модем при установлении сетевого соедине-
ния с удаленным пользователем по протоколу РРР, изучите материал,
изложенный в главе 13. Возможно, понадобятся дополнительные про-
граммные средства.
•	Информация о порядке и особенностях настройки последовательных
принтеров приведена в главе 23. Олни принтеры только принимают
данные, а другие могут передавать серверу информацию о своем
состоянии.
•	Пользовательское последовательное устройство, которое обслуживается
только с помощью своего программного обеспечения, не требует специ-
альной конфигурации. Для доступа к нему достаточно открыть файл
устройства. Описание функций семейства ioctl, с помощью которых
устанавливается скорость передачи, флеги и режим буферизации после-
довательного порта, содержится на странице документации, посвященной
описанию команды termio или tty.
7.8.	Конфигурирование аппаратных терминалов
За последнее десятилетие рабочие станции и Х-терминалы постепенно
вторглись на территорию, где когда-то единолично правили бал текстовые
терминалы. Но даже консольные программы на графическом дисплее ис-
пользуют те же драйверы и файлы конфигурации, что и реальные терминалы,
поэтому системный администратор должен понимать, как они работают.
При настройке терминале нужно решить две важные задачи: обеспечить
закрепление за терминалом процесса, который будет принимать поступающие
от него регистрационные запросы, и обеспечить доступность информации о
терминале после входа пользователя в систему.
Процесс регистрации
В процессе регистрации задействовано несколько программ. Во время
начальной загрузки запускается демон init. Одна из его задач — породить
• В действительности сами последовательные порты все же требуют конфигурирования нв
уровне ядра, но это всегда делает фирма-поставшик, а не администратор системы.
Глово 7. Последовотельные устройство
125
процесс, обычно getty (но не в Solaris), на каждом терминальном порте,
который определяется в файле /etc/ttys или /ctc/inittab (в зависимости от
системы). Процесс getty устанавливает исходные характеристики порта (в
частности, скорость передачи и контроль четности) и выводит на экран
регистрационное приглашение.
Последовательность событий при полной регистрации следующая:
•	пользователь вводит регистрационное имя по приглашению процесса getty;
•	процесс getty запускает программу login, передавая ей в качестве аргумента
указанное имя учетной записи;
•	программа login запрашивает пароль и сверяет имя и пароль пользователя
с записями в файле /etc/passwd*;
•	программа login выводит на экран “сообщение дня”, хранящееся в файле
/etc/motd;
•	программа login устанавливает переменную среды TERM и запускает
интерпретатор команд;
•	интерпретатор выполняет соответствующие файлы запуска’*;
•	интерпретатор выводит на экран приглашение командной строки и
ожидает ввода информации.
Когда пользователь выходит из системы, управление возвращается демону
init, который пробуждается и порождает новый процесс getty для порта
терминала.
Файлы в каталоге /etc управляют характеристиками, связанными с
каждым портом терминала. Сюда входит наличие регистрационного пригла-
шения и процесса getty на порте, ожидаемая скорость передачи в бодах и
тип терминала, а также многое другое.
К сожалению, подход фирм-поставщике в к вопросу конфигурирования
терминалов различен. В табл. 7.6 перечислены файлы, используемые в
тестовых системах.
Тоблица 7.6. Файлы конфигурации терминолов
Система	Включение/ Выключение	Тип терминале	Параметры	Монитор
Solaris*	sactab	sactab	zstnon/jpmtab	ttymon
HP-UX	/etc/inittab	/ctc/ttytype	/ctc/gertyders	geny
Red Hat	/etc/initub	/etc/ttyiypc	/etc/gettydefc	getty
FreeBSD	/etc/ttys	/etc/ttys	/etc/gettytab	getty
В Solaris конфигурационные файлы находятся в каталоге /etc/saf и обрабатываются
программой sac a dm
Файлы /etc/ttys и /etc/ttytab
В системах на базе ядра 4.3BSD (и более поздних версий) информация
о типе порта и терминала объединена в одни файл, который называется ttytab
или ttys (FreeBSD) Формат записей этого файла таков:
устройство программа тил_ термина лй (on|off| [secure]
В некоторых системах файл /etc/passwd заменяется или дополняется административной
СУБД, например N1S. Подробнее об этом рассказывается в главе 18.
Файл .profile в интерпретаторах sli, ksh и bash; файлы .login и .esbre — в csb и tesb.
126
Честь I. Основы одминистрировсния
Поля разделяются пробелами. В поле программа указывается управляю-
щий процесс, запускаемый демоном init, если данный порт включен.
В частности, для программы getty, которая обычно упоминается в этом поле,
задается аргумент, который определяет скорость передачи и конфигурацию
последовательного порта.
В поле тип терминала указывается элемент базы данных tcrmcap или
terminfo (см. ниже). Когда пользователь входит в систему, переменная среды
TERM устанавливается равной значению этого поля.
С помощью ключевых слов on и off включается и отключается
регистрация на данном порте (т.е. эти слова определяют, можно ли запускать
программу). Если присутствует ключевое слово secure, то с такого терминала
может входить в систему пользователь root. Во многих организациях вход
суперпользователя в систему с терминалов, установленных в машинных залах
и подключаемых через коммутируемый канал, не разрешается.
Вот несколько элементов файла /etc/ttys:
console	поле	unknown	off	secure
ttydO	"/usr/libexec/getty	std.9600"	dialup	off	secure
ttydl	"/usr/libexec/getty	std.96O0’‘	dialup	off	secure
ttyd2	”/usr'libexec/getty	std-9600"	dialup	off	secure
Аргумент команды getty содержит ссылку на элемент одного из следующих
файлов: inittab, gettytab или gettydefs (в зависимости от системы).
Демон init читает файл ttys или ttytab всего один раз. Если изменяется
файл конфигурации. необходимо дать демону явное указание прочесть файл
повторно. Для этого ему посылается сигнал отбоя (HUP). Демон init — всегда
процесс номер один, поэтому обычно подходит команда
# kill -1 1
выполняемая от имени пользователя root. Смотрите, не ошибитесь и не
пропустите дефис!
Файл /etc/ttytype
В некоторых системах информация о типе терминала отделяется от файла
/etc/ttys и хранится в файле /etc/ttytype. Формат его записей следующий:
тип_терминала устройство
Здесь устройство — это сокращенное имя файла устройства, соответст-
вующего порту, а тип терминала задается так же, как он описан выше в
файле /etc/ttys. Вот пример файла ttytype:
wyse console
dialup ttyiO
dialup ttyil
vt320 ttyi2
hl 9 ttyi3
dialout ttyi4
Фойл /etc/geftytob
Файл gettytab предназначен для связывания символьных имен (таких как
std.9600, использованное выше) с информацией о конфигурации порта —
Глово 7. Последовотельные устройство
127
скоростью передачи, контролем четности н строкой регистрационного
приглашения. Например:
*	Стандартная запись, задавшая начальные параметры
# для других записей; используется в случае, когда
# программа getty вызывается без указания записи.
default:\
:ар:lm"\r\n%h login\72 :spfr9600:
#	Записи, задающие фиксированную скорость
2|std.9600|9600-baud:\
:sp#9600:
hIstd.38400 I38400-baud:\
:sp#38400:
Формат здесь аналогичен формату файлов /etc/printcap и /etc/temicap.
Строки с именами, разделенными вертикальной чертой, содержат имена, под
которыми известна каждая конфигурация. В остальных полях задаются
параметры последовательного порта.
В большинстве систем в файле gettytab уже имеются записи для различных
терминалов. Описание формата, обшего для всех указанных файлов, приве-
дено в параграфе 23.3. Информацию о конкретных переменных можно
почерпнуть из документации.
Файл /etc/inittob
В Solaris, HP-UX и Red Hat демон init поддерживает различные “уровни
выполнения”, которые определяют, какие системные ресурсы задействуются.
Существует восемь уровней выполнения: от 0 до 6 плюс уровень s для
однопользовательского режима. При выходе нз однопользовательского режима
демон init приглашает пользователя ввести номер уровня выполнения, если
только в файле /etc/inittab нет поля initdefault (см. ниже). Затем демон
просматривает файл inittab и ищет все строки, соответствующие указанному
уровню.
Уровни выполнения обычно устанавливаются таким образом, чтобы у
пользователя был один уровень, на котором доступна только системная
консоль, и другой уровень, на котором доступны все терминалы. Можно
определять уровни выполнения так, как того требует конкретная система, но
мы рекомендуем не слишком отклоняться от значений, заданных по
умолчанию.
Записи файла inittab имеют следующий формат:
идентификатор: уровни_выполнения:действие: процесс
Приведем пример:
::sy	sinit:/etc/setclk </dev/console >/dev/console 2>&1
co:234:respawn:/etc/getty console console
11:234:respawn:/etc/getty ttyll 9600
12:234:off:/etc/getty ttyl2 9600
В этом формате идентификатор — одно- или двухсимволъная строка,
идентифицирующая данную запись. Поле идентификатора может быть
пустым, как в первой строке приведенного выше примера. Для терминалов
в качестве идентификатора обычно используют номер терминала.
128
Чость 1. Основы ОДМИНИСТрИрОВОНИЯ
Поле уровни_выполнения — это иомера уровней выполнения, к которым
относится данная запись. Если уровни не заданы (как в первой строке), то
запись действительна для всех уровней. В поле действие определяется, как
следует трактовать поле процесс, наиболее распространенные значения
приведены в табл. 7.7.
Тоблицо 7.7. Возможные зночения поля действие ФОйло /etc/lnfttob
Значение	Ждать?	Интерпретация
initdefault	—	Задает исходный уровень выполнения
boot	Нет	Процесс выполняется при первом чтении файла inittab
bootwait	Да	Процесс выполняется при первом чтении файла inittab
once	Нет	Запускает процесс однократно
wait	Да	Запускает процесс однократно
respawn	Нет	Всегда поддерживает процесс в работающем
		состоянии
powerfail	Нет	Процесс выполняется при получении демоном init сигнала сбоя питания
powerwait	Да	Процесс выполняется при получении демоном init сигнала сбоя питания
sysinit	Да	Процесс выполняется перед обращением к консоли
off	—	Завершает процесс, если он выполняется
Если одно из значений в поле уровни_выполнения совпадает с номером
текущего уровня, а значение поля действие говорит об актуальности записи,
то демон init с помощью интерпретатора sb выполняет команду, заданную в
поле процесс (или прекращает ее выполнение). В столбце "Ждать?” табл. 7.7
указано, в каких случаях демон init перед продолжением ожидает завершения
команды.
В приведенном выше примере в первой строке устанавливаются систем-
ные часы, во второй и третьей строках порождаются процессы getty, а
последняя строка обеспечивает отсутствие процесса getty на порте Иу12.
Команда telinit -q заставляет демон init повторно прочитать файл initial#.
Фойл /etc/gettydefs
Как и файл gettytab, файл getlydefs определяет различные варианты
конфигурации портов, используемые процессом getty. В системе, как правило,
присутствует только один из этих файлов. Файл gettyders выглядит следующим
образом:
console# В9600 HUPCL # В9600 SANE IXANY #login: #console
19200# B19200 HUPCL # B19200 SANE IXANY «login: #9600
9600#	B9600	HUPCL	#	B9600	SANE	IXANY	HUPCL	#logini	#4800
4800#	B4800	HUPCL	#	B4800	SANE	IXANY	HUPCL	Hogin:	#2400
2400#	B2400	HUPCL	#	B2400	SANE	IXANY	HUPCL	#login:	#1200
1200#	B1200	HUPCL	#	B1200	SANE	IXANY	HUPCL	«login:	#300
300# B300 HUPCL # B300 SANE IXANY TAB3 HUPCL «login: #9600
Запись этого файла имеет такой формат:
метка» начальншефлаги # конечные^флаги * приглашение Нслелухший
Глова 7 Последовательные устройство
1Г?
Процесс getty проводит сравнение своего второго аргумента с записью,
идентифицируемой полем метка. Если процесс вызывается без второго
аргумента, то для подобного сравнения используется первая запись файла В
поле начальные флаги перечисляются флаги системного вызова ioctl, задающие
конфигурацию порта до выполнения программы login В поле конечныефлаги
указаны флаги, которые необходимо установить после завершения программы
login.
Должна существовать запись, которая задает быстродействие соединения
и в начальных, и в конечных флагах. Список возможных флагов отличается
в зависимости от системы; обратитесь к разделу документации, касающемуся
файла gettydefs (обычно имена флагов те же, что задаются в С-программах).
Поле приглашение служит для описания регистрационного приглашения,
которое может включать символы табуляции и новой строки. В поле
следующий указывается метка записи файла gettydefs. которую необходимо
подставить вместо текущей при получении сигнала прерывания. Это было
полезно десятилетия тому назад, когда модемы не корректировали скорость
передачи автоматически и нужно было согласовывать скорость вручную с
помощью серии сигналов прерывания. Сегодня это анахронизм. Для аппа-
ратного терминала поле следующий должно содержать метку текущей записи
При каждом изменении файла gettydefs следует выполнять команду
getty -с gettydefs, которая проверяет синтаксис файла на предмет правильности
всех записей.
Конфигурирование терминалов в Solons
Вместо традиционных для UNIX процессов getty. которые наблюдают за
работой всех портов и выдают регистрационные приглашения, в Solaris
существует запутанная иерархическая система Service Access Facility (система
сервисного доступа), которая используется для управления мониторами
терминалов, мониторами портов /I многими другими устройствами, принося
в плане функциональных возможностей мало пользы и много осложнений.
Для настройки последовательного порта на выдачу' регистрационного
приглашения необходимо сначала сконфигурировать "монитор", наблюдаю-
щий за статусом порта (программа ttymon). Затем нужно сконфигурировать
монитор порта, который следит за статусом монитора терминала. Например,
чтобы настроить монитор порта ttyb на скорость 9600 бод и вывод
регистрационного приглашения на терминал типа VT100, требуется выполнить
следующие команды:
I sacadm -а -р myttymon -t ttymon -с /usr/lib/saf/ttymon -v 1
# pmadm -a -p myttymon -s b -1 root -fu -v 1 -m " ttyadm -d \
/dev/term/Ь -1 9600 -T vtlOO -a /usr/bin/loqin’”
Файл /etc/ttydefs служит в основном для того же. для чего в других
системах используется файл gettydefs. т.е. для установки скорости передачи
и контроля четности.
Более подробную информацию о настройке этих мониторов можно найти
на страницах документации, посвященных утилитам saf, pacadin. pmadm.
ttyadm и ttymon, а также в главе о терминалах справочника Solaris Answer Book.
Поддержка термин, лог базы данных tern cap и terminfo
В UNIX поддерживается много разных типов терминалов, в отличие от
программного обеспечения некоторых крупных фирм, которые поддерживают
’ЗС
Чость I. Основы администрирования
0
только термналы собственного производства. UNIX использует для этого
специальную базу данных, в которой содержатся характеристики и сведения
об особенностях программирования для каждой модели терминала.
В одних системах эта база данных называется Lermcap, а в других она
имеет иной формат и называется lemiinfo. Иногда для обеспечения макси-
мальной совместимости в системе присутствуют обе базы данных. Они обычно
располагаются в каталоге /etc или /usr/share.
Такие базы данных содержат снедения о сотнях различных терминалов.
Пользователю практически никогда не приходится составлять собственные
описания терминалов. Тем не менее, некоторые поставщики систем настаи-
вают. налример, на переименовании терминала “xterm", поэтому может
понадобиться добавить новое имя для существующей записи.
Для того чтобы определить, какая разновидность терминала используется,
UNIX-программы проверяют значение переменной среды TERM. Дополни-
тельную информацию об этом терминале можно затем найти в базе данных
temicap или lerminfo- Кроме того, можно поместить элемент базы данных
temicap непосредственно в переменную среды TERM САР. Как правило,
установка переменных TERMCAP u TERM производится во время регистра-
ции.
Подробнее о конфигурировании терминалов во время регистрации рассказано в
параграфе 7.11.
Сегодня, когда аппаратные терминалы почти не используются, лишь
несколько типов терминалов предстааляют практический интерес. Правило
гласит: “Все программы эмулируют терминал DEC VT100, если не доказано
обратное”
7.9.
Специальные символы и драйвер терминала
Драйвер терминала выполняет несколько специальных функций, доступ
к которым осуществляется посредством особых комбинаций клавиш (обычно,
в эти комбинации входит клавиша <Ctrl>). Точную привязку функций к
клавишам можно задать с помощью команд Lset и stty. Некоторые из этих
функций и обозначения соответствующих им клавиш приведены в табл. 7.8.
Таблица 7.8 Специальные символы и функции драйвера терминола		
Символ	По умолчанию	Функций
ERASE	H	Стирает опин введенный символ
WE RASE		Стирает олно введенное слово
KILL	и	Стирает целую строку
EOF	D	Посылает терминалу признак конца файла
INTR	С	Прерывает выполняемый процесс
QUIT	л	Уничтожает текущий процесс с созданием дампа оперативной памяти
STOP	AS	Останавливает вывод на экран
START	0	Перезапускает процедуру вывода на экран
DISCARD	о	Очищает буфер выходных данных
SUSPEND	z	Приостанавливает текущий процесс
LN EXT	V	Игнорирует специальное значение следующего символа
Глово 7 Последовотельные устройства
131
В зависимости от типа клавиатуры с символом ERASE может быть по
умолчанию связана клавиша <Deieie>, для которой в разных операционных
системах существуют различные текстовые представления. Это наглядное
свидетельство имеющихся серьезных разногласий между поставщиками
UNIX-систем, которые не могут прийти к соглашению даже по поводу того,
какой код должен генерироваться клавишей < Backspace >.
В самых ранних системах клавиши <#>, <@> и <Delete> по умолчанию
были связаны со специальными символами ERASE, KILL и INTR. Некоторые
системы до сих пор тайно используют их до того, как производится
регистрация в системе, поэтом}' не включайте их символьные представления
в свои пароли.
7.10.	Команда stty конфигурирование терминалов
Команда stty позволяет непосредственно изменять и запрашивать значе-
ния различных параметров драйвера терминала. Существует множество опций,
о которых можно узнать, обратившись к разделу документации, где описы-
вается драйвер терминала (tty(4), tty(5), но не tty(l) — это простая программа,
которая сообщает, на каком терминале или псе ндотерм инале зарегистрирован
текущий пользователь). За небольшим исключением указанные там опции
совпадают с опциями команды stty. Многие опции одинаковы для большин-
ства систем, но существуют и различия. причем даже среди родственных
вариантов, поэтом}' лучше посмотреть, что написано в руководстве по
имеющейся операционной системе.
Опции команды stty могут следовать в любом порядке и в любых
сочетаниях. Дефис перед опцией отменяет ее. Например, следующая команда
настраивает терминал на скорость 9600 бит/с с проверкой четности и без
аппаратной табуляции:
% stty 9600 even -tabs
Вот хорошее сочетание опций для простого терминала;
% stty intr *С kill ЛЦ erase ЛН -tabs
Здесь опция -labs запрещает драйверу терминала задействовать встроен-
ный механизм табуляции (во многих терминалах табуляция не реализована
аппаратно), а остальные опции назначают специальным символам 1NTR,
KILL и ERASE сочетания клавиш <Clrl-C>, <Ctrl-U> и <Ctrl-H> соответственно.
Команду stty можно использовать для анализа текущих режимов драйвера
терминала и их установки. Команда stty без аргументов выдает такую
информацию:
% stty
speed 9600 baud; -parity hupcl
rows - 24; columns ж 80
erase  '“h; swtch - <undef>;
brkint -inpck -istrip icrnl -ixany imaxbel onlcr
echo echoe echok echoctl echoke lexten
Более детальный отчет вы можете получить с помощью команды stty
everything, stty -а или stty all, в зависимости от конкретной системы. В этом
случае результат будет приблизительно таким:
т stty -
speed 9600 baud;
132
Чость I Основы одминистрировония
rows - 24; columns “ 80; ypixels - 364; xpixela " 739;
eucw 1:0:0:0, ecrw 1:0:0:0
intr “ лс; quit “ лI1 erase “ Ah; kill - Au; eof “ "d; eol “ <undef>;
eol2 « <undef>; switch - <undef>; start - Aq; stop - *s; susp • Az;
dsusp - 'y; rprnt flush - Ao; werase - "w; Inext " Av;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts
-parext -ignbrk brkir.t ignpar -parmrk -inpck -istrlp -inlcr
-igncr icrnl -iuclc ixon -ixany -ixoff imaxbel Isig icanon -xcese
echo echoe echok -echonl -noflsh -tostop echoctl -echoprt echoke
-defecho -flusho -pendin iexten opost -olcuc onlcr -ocrnl -onocr
-onlret -ofill -ofdel
Формат вывода остался прежним, но отображена вся имеющаяся
информация. О содержании полученной выходной информации можно
догадаться интуитивно.
Команда stty работает с файловым дескриптором своего стандартного
входного или выходного потока (в зависимости от конкретной системы),
поэтому с помощью операторов переадресации, предусмотренных в интер-
претаторе команд (“>” и <*’), можно устанавливать и запрашивать режимы
не только текущего, но и других терминалов. В некоторых системах изменять
режимы терминала другого пользователя имеет право только пользователь root.
7.11.	Команда tset: автоматическое конфигурирование
Команда tset устанавливает драйвер терминала в режим, соответствующий
данному типу терминала. Тип терминала можно задать в командной строке;
если он не указан, используется значение переменной среды TERM.
Синтаксис команды tset предусматривает возможность изменения значе-
ний переменной среды TERM. Это полезно, если вы часто входите в систему
через модем или коммутатор данных и хотите, чтобы драйвер был сконфи-
гурирован в расчете на реальный терминал, который используется на другом
конце соединения, а не на нечто слишком общее и бесполезное вроде
“коммутируемого терминала" (тип “dialup”).
7.12.	Как справиться с "зависшим'' терминалом
Некоторые программы (например, редактор vi) вносят в процессе своей
работы серьезные изменения в параметры драйвера терминала. Пользователь,
как правило, этого не замечает, поскольку при завершении или приостановке
программы состояние терминала полностью восстанавливается. Однако су-
ществует опасность, что программа прекратит работу аварийно или ее
выполнение будет прервано до завершения процедуры восстановления. Если
это случится, терминал может перестать правильно обрабатывать символы
новой строки, отображать вводимые символы и адекватно выполнять
команды.
Еше один способ нарушить работу терминала — выполнить команду cat
или more по отношению к двоичному файлу В большинстве таких файлов
содержится причудливая смесь управляющих символов, которая наверняка
окажется "смертельной" для недостаточно устойчивых терминалов и эмуля-
торов.
Для решения проблемы можно воспользоваться командой reset или stty
sane. В большинстве систем команда reset является лишь ссылкой на команду
tset и может принимать большинство ее аргументов, но, как правило, она
Главе 7. Последов отельные устройство
133
вызывается без аргументов. Обе команды, и reset, и stty sane, восстанавливаю!
работоспособность драйвера терминала и посылают терминалу соответствую-
щий код сброса из базы данных termcap (или term in Го), если таковая имеется.
Во многих случаях сброс необходим потому, что терминал был оставлен
в специальном режиме, в котором вводимые пользователем символы не
обрабатываются. В этом режиме большинство терминалов при нажатии
клавиши <Retum> или <Ешег> генерирует только символ возврата каретки
<<С(г1-М>). Символ перевода строки, после получения которого текущая
команда посылается на выполнение, не генерируется. Чтобы ввести символ
новой строки непосредственно, вместо клавиши <Retum> нажмите комби-
нацию клавиш <CtrI-J> или клавишу перевода строки (если она имеется).
7.13.	Модемы
Модем преобразует цифровой последовательный сигнал компьютера в
аналоговый, пригодный для передачи по стандартной телефонной линии.
Модемы применяются при работе со многими приложениями. Типичный
пример приведен в параграфе 13.8.
Внешние модемы имеют гнездо RJ-11 со стороны аналогового сигнала,
а со стороны цифрового сигнала — разъем стандарта RS-232 (обычно розетку
DB-25). На передней панели модема, как правило, есть ряд лампочек,
сигнализирующих о состоянии модема и происходящих в нем процессах. Сам
модем должен располагаться в области прямой видимости, чтобы лампочки
были хорошо заметны.
Внутренние модемы обычно применяются только в персональных ком-
пьютерах. Плата модема вставляется в слот ISA, PCI или PCMCIA и имеет
гнездо RJ-1I, которое выведено на заднюю панель компьютера. Внутренние
модемы дешевле внешних, но их труднее конфигурировать и у них нет
индикаторных лампочек.
Если вы собрались покупать внутренний модем, проверьте, поддержива-
ется ли он в имеющейся версии UNIX. Некоторые быстродействующие
процессоры берут на себя часть функций модема, выполняя обработку
основных сигналов. Для такого рода встроенных модемов требуются специа-
лизированные драйверы. Маловероятно, чтобы они поддерживались в PC-
версиях UNIX.
Модемы различаются по обшей устойчивости, но, не имея опыта, эту
характеристику оценить трудно. В прошлом одни модемы были более
устойчивы к помехам в линии, чем другие. Сегодня в большинстве моделей
стоит стандартный набор микросхем от одного из основных производителей,
поэтому различия между модемами не столь велики, как раньше.
Быстродействующие модемы требуют наличия сложных микропрограмм,
а в них часто встречаются ошибки. По мере возможности производители
стараются использовать один и тот же микрокод в разных моделях, поэтому
и хорошие, и плохие программы распространяются на целые семейства
модемов. По этой причине мы рекомендуем покупать модемы широко
известных марок.
Протоколы модуляции, коррекции ошибок и сжатия донных
В былые времена имело большое значение, какие именно протоколы
поддерживаются модемом, поскольку стандарты постоянно менялись, а
производители модемов не всегда реализовывали полный комплект протоколов.
134
Чость I. Основы одминистрировония
Сегодня модемы, имеющие одинаковую скорость, в основном придержива-
ются одних и тех же стандартов. Единственное различие между моделями
модемов — зашитые в них микропрограммы, набор электронных компонентов
и техническая поддержка.
Скорость передачи в бодах — это частота, с которой модулируется сигнал
несущей. Если имеется более двух уровней сигнала, то за один переход можно
передавать более одного бита информации и скорость в битах будет выше
скорости в бодах. Исторически сложилось так. что скорость передачи данных
и частота передачи сигналов модемами были одинаковыми, что привело к
непреднамеренному слиянию терминов “бод” и "бит/с”.
Самые быстродействующие на сегодняшний день модемы работают по
стандарту V.90 ‘•56К”, который в действительности не соответствует пропу-
скной способности 56 Кбит/с В лучшем случае он обеспечивает скорость
связи 33,6 Кбит/с между компьютером и провайдером и 53 Кбит/с в обратном
направлении. Тем не менее, стандарт V.90 позволяет очень близко подойти
к теоретическому и практическому пределу скорости распространения сиг-
налов по обычным голосовым телефонным линиям, поэтому маловероятно,
чтобы он был заменен в ближайшее время
Два предыдущих стандарта “56К° — Х2 и 56Kflex — являлись попытками
производителей (US Robotics, теперь часть ЗСот. и Rockwell соответственно)
внедрить модемы класса V.90 на рынок до того, как появился соответствую-
щий стандарт. Они по-прежнему поддерживаются некоторыми провайдерами,
но в ближайшее время наверняка окончательно исчезнут Большинство
модемов Х2 и 56Kflex можно обновить до уровня V.90, поэтому не
выбрасывайте такой модем, если он у вас есть.
Помехи в линии передачи могут быть причиной возникновения значи-
тельного количества ошибок в модемном соединении Для устранения
подобных проблем разработаны различные протоколы коррекции ошибок,
которые обеспечивают формирование пакетов передаваемых данных и
исправление ошибок на основании проверки контрольных сумм. Эти
протоколы защищают пользователя и прикладные программы от помех в
линиях связи и обычно не требуют дополнительного конфигурирования.
Алгоритмы сжатия данных обеспечивают уменьшение количества битов,
подлежащих передаче межл> аналоговыми оконечными источниками Коэф-
фициент сжатия варьируется от единицы (когда передаются данные, уже
подвергшиеся сжатию) до 4;]. Типичный показатель — 1.5:1. Как правило,
при включенном режиме сжатия скорость передачи данных увеличивается.
Выходная конфигурация: файлы /etc/phones и /etc/remote
Команды tip и си позволяют посылать последовательным устройствам
команды с клавиатуры Чаше всего они используются с модемами, ио могут
применяться и для “общения” с принтерами и терминалами. Команды tip и
си используют два файла конфигурации, в которых регистрируются номера
телефонов (/etc/phones) и информация о последовательных портах (/etc/re-
mote).
Файл /ctc/remote выглядит следующим образом:
#	/etc/remote: параметры модемов
dj.all.9200 119200 Baud:dv-/dev 'culO:bril 9200:'
cu“/dev/cul0:at^hayes:du:
dial3B400|dialer 1384 00 Baud:dv=/dev/eul0;br4 38400:
Глово 7. Поспедовотельные устройство
135
cu-/dev/culO:at-hayes:du;
#	Узлы, с которыми часто устанавливается связь
исс.рп-3338118: tc-dia!3B40D
сс:рл-0:tc-dial38400
dca:dv-/dev'ttyhl, /dev/ttyh2;br#9600:pa-nor.e
В первых двух записях описываются характеристики вызывающего
устройства. В последних трех строках дана информация о связи с конкрет-
ными компьютерами; каждому соединению назначено краткое имя. Обратите
внимание иа то. что в записи сс номер телефона записан как рп=@. Это
означает, что номер (или номера) следует брать из файла /etc/phohes.
#	/etc/phones: в этом файле могут содержаться номера
#	междугородных и международных телефонов, а также
#	секретные номера, поэтому он должен Выть доступным
# только суперпользователю
сс 5552530
monet S,,510,555-4567,,,,хххх-ххх
Файл phones содержит описания телефонных номеров, которым назначе-
ны символические имена. В этом примере хххх-ххх может обозначать номер
междугородной связи. Знаки препинания используются для обозначения
задержек или ожидания второго тонального сигнала Перечень и назначение
таких управляющих символов зависят от марки модема. Как правило, это
запятые, знаки равенства и звездочки.
Дуплексные модемы
Во многих случаях удобно конфигурировать один модем как на прием,
так и на передачу данных. Для этого требуется специальная настройка
последовательного порта, поскольку процесс getty во время начальной
загрузки обычно принимает на себя полное управление последовательными
портами. Другие процессы, которые хотят работать с модемом, остаются ‘‘вне
игры”, ибо не могут открыть порт даже тогда, когда модем фактически не
используется. К сожалению, не приходится говорить о высокой степени
стандартизации в плане управления дуплексными модемами.
В Solaris, чтобы перевести последовательный порт в дуплексный режим,
выполните следующие операции'
•	при подключении монитора порта укажите в команде ttyadm флаг -Ь;
•	в качестве аргумента команды ttyadm задайте файл /dev/cua/а ia не
/dev/term/з),
•	отредактируйте файл /etc/uucp/Devices. включив в него имя дуплексного
сервиса.
С примерами и подробным описанием этого процесса можно ознако-
миться в разделе “How to Sei Up Bidirectional Modem Service*' справочника
Solans AnswerBook.
В HP-UX и Red Hai с дуплексными портами можно применять
специальный процесс getty, называющийся uugetty. Во избежание конфликтов
процесс uugetty использует файлы блокировки совместно с такими програм-
мами, как cu. tip и uucico.
136
Чость I Основы одминистрировония
7.14.	Отладка последовательной линии
Наладить работу последовательной пинии несложно. Приведем перечень
типичных ошибок. Вероятно, вы:
•	забыли дать демону init указание повторно прочитать свои конфигура-
ционные файлы;
•	забыли установить режим программной несущей при использовании
трехпроводных кабелей;
•	используете кабель с оборванным нулевым проводом;
•	при пайке или обжимании проводов перевернули вверх ногами разъем DB-25;
•	подключили устройство не к тому проводу' (возможно, из-за того, что
монтажные схемы оказались неправильными или неточными);
•	неверно задали параметры терминала.
Отводная коробка — незаменимое средство устранения проблем в
кабельных системах. Коробка, которая подключается к последовательной
линии, предназначена для индикации наличия сигналов в любом из проводов
кабеля в данный момент времени. У хороших отводных коробок на каждой
стороне есть и вилки, и розетки, поэтому они могул подключаться самыми
разными способами. С каждым из представляющих интерес контактов
(а именно, с контактами 2, 3. 4, 5. 6, 8 и 20) связаны светодиоды, которые
показывают, когда контакт активен.
Некоторые отводные коробки позволяют просто наблюдать за сигналами,
а некоторые дают возможность осуществлять повторную разводку соединений
и подтверждать наличие напряжения на конкретном контакте. Например,
если есть подозрение, что кабель нужно сделать нуль-модемным. то можно
с помощью отводной коробки изменить имеющуюся разводку и поменять
местами контакты 2 и 3, 6 и 20.
7.15.	Другие распространенные порты ввода-вывода
Ранее последовательные порты были безусловным стандартом для под-
ключения низкоскоростных периферийных устройств к UNIX-системам. Но
сейчас. по мере перехода UNIX на персональные компьютеры, появляются
новые возможности.
Параллельные порты персонального компьютера схожи по архитектуре с
последовательными портами, но передают за раз 8 битов, а не I. Это позволяет
им работать гораздо быстрее, но усложняется структура кабельной системы
и разъемных соединений. Параллельные интерфейсы широко применяются
в принтерах, а также для подключения Zip-дисководов и накопителей на
магнитной ленте, так как им нужна более широкая полоса пропускания, чем
та, которую могут обеспечить последовательные порты. В UNIX, однако,
поддержка параллельных устройств в основном ограничена принтерами
USB (Universal Serial Bus — универсальная последовательная шина) —
это недавнее изобретение, устраняющее необходимость в последовательных
и параллельных портах. Это быстрый и эффективный интерфейс, в котором
применяются стандартные дешевые и простые кабели. К сожалению,
потребуются годы, прежде чем организации смогут избавиться от существую-
щих последовательных и параллельных устройств.
Глово 7. Последовотельные устройства
137
Пороллельные порты
В персональных компьютерах параллельные порты существовали десяти-
летиями. но лишь недавно они начали проникать в UNIX-системы. Когда
UNIX устанавливается на персональном компьютере, в системе конфигури-
руется один параллельный порт, но некоторые производители начали
встраивать такие порты и в специализированные рабочие станции UNIX,
чтобы к ним можно было подключать принтеры, сделанные для рынка
Windows.
За все время существования параллельных портов было пять или шесть
различных стандартов, определяющих их работу, но современные параллель-
ные интерфейсы совместимы со всеми этими стандартами. Нанлучший из
существующих стандартов — IEEF-1284 совместимый с большинством своих
предшественников
Для достижения максимальной пропускной способности можно перево-
дить современные параллельные порты в режим EPP (Enhanced Parallel Port —
расширенный параллельный порт) или ECP (Extended Capability Pon — порт
с расширенными возможностями). В обоих режимах достигается скорость
2 Мбит/с и выше. Эти режимы в основном эквивалентны друг другу, но в
режиме ЕСР дополнительно поддерживаются DMA-каналы. Неясно, имеет
ли это какой-то практический интерес.
Параллельный порт обычно оснащен розеткой DB-25, а на периферийном
оборудовании установлены 36-штырьковые розетки Centronix. Таким образом,
параллельные кабели имеют на одном конце вилку DB-25, а на другом —
вилку Centronix. Существует также разъемное соединение mini-Centronix,
описанное в стандарге IEEE-1284. Параллельные кабели могут быть длиной
до 10 м.
В отличие от среды Windows, где существует возможность подключения
множества периферийных устройств к параллельному порту, в UNIX широко
поддерживаются лишь принтеры. Другие устройства, например Zip-дисководы
и видеокамеры, требуют наличия специализированных драйверов. Как
правило, такие драйверы приходится устанавливать вручную, хотя операцион-
ная система Linux существенно продвинулась в данном направлении.
Хорошо это или плохо, вряд ли UNIX обеспечит большую поддержку
параллельных устройств, чем сейчас, поскольку в обозримом будущем усилия
разработчиков будут сосредоточены на стандарте USB
Интерфейс USB
USB — это универсальная система подключения периферийных уст-
ройств, разработанная компаниями Compaq, DEC, IBM. Intel, Microsoft, NEC
и Northern Telecom. Первый стандарт шины USB был опубликован в 1995 г.
В последние годы поддержка USB стала стремительно внедряться в Windows-
системы, в результате чего практически все новые компьютеры начали
оснащаться USB-портами. Кроме того, современные периферийные устрой-
ства теперь выпускают в USB-вариантах.
USB — отличный интерфейс. Мы думаем, что он приобретет большую
популярность в UNIX и будет существовать много лет. Вот его основные
характеристики:
•	можно подключать до 127 устройств:
•	в USB-кабеле есть всего четыре провода: питание, заземление и два
сигнальных провода;
13й
Чость I. Основы одминистрировония
•	разъемные соединения стандартизированы;
•	разъемные соединения невелики по размеру, а сами кабели тонкие и
гибкие;
е устройства можно подсоединять и отсоединять без выключения питания;
•	скорость передачи данных достигает уровня 12 Мбггт/с;
•	имеется возможность подключать к USB-порту старые последовательные
и параллельные устройства через специальные переходники.
К сожалению, на момент написания данной книги лишь компания
Hewlett-Packard обеспечивает поддержку интерфейса USB: ее рабочие станции
оснашаются USB-клавиатурой и USB-мышью. Скоро такая поддержка должна
появиться и в Linux. Не вызывает сомнений, что в ближайшем будущем
интерфейс USB станет неотъемлемой частью всех UNIX-систем.
О Добавление нового
U жесткого диска
Места на диске никогда не бывает достаточно. Только подключишь к
системе новый диск, а через минуту он уже наполовину заполнен или, по
крайней мере, кажется заполненным. Заставить пользователя очистить свой
диск так же трудно, как заставить подростка убрать у себя в комнате. Поэтому
администратору иногда приходится устанавливать дополнительные жесткие
диски.
В большинстве систем дисковые накопители подключаются к стандартной
шине периферийных устройств, называемой SCSI (Small Computer Systems
Interface — интерфейс малых вычислительных систем: произносится “скази”).
Альтернативный интерфейс IDE (Integrated Drive Electronics — встроенный
интерфейс накопителей) поддерживается производителями персональных
компьютеров. Мы начнем эту главу с общего описания стандартов SCSI и
IDE и конструкции современных жестких дисков, после чего перейдем к
общим механизмам форматирования и разбивки дисков на разделы, а также
к процедуре инициализации файловых систем.
Хотя почти все поставщики используют стандартные дисковые интерфей-
сы, команды конфигурирования для дисков разных фирм-производителей
различны. По этой причине в данной главе содержится подробная инфор-
мация по конкретным системам. Мы попытались описать каждую систему
детально, чтобы читатель мог разобраться в используемых командах и. при
необходимости, сумел найти нужную документацию. Мы также рассматриваем
процедуру инсталляции, проводимую в каждой системе при подключении
конкретного дискового накопителя.
140
Часть I Основы администрирования
8.1.	Дисковые интерфейсы
Сначала каждый производитель вычислительной техники предлагал для
подключения жестких дисков и других периферийных устройств интерфейс
собственной разработки. Отчасти это было обусловлено незрелостью интер-
фейсной технологии. Кроме того, производители стремились получить кон-
троль над рынком периферийных устройств для своих машин. В конечном
итоге другие фирмы начали выпускать дисковые системы, которые отличались
высокой экономической эффективностью и полной совместимостью, а кроме
того, во многих случаях работали гораздо лучше, чем устройства крупных
производителей.
Производителей компьютеров такой поворот событий не слишком
обрадовал. История знает несколько весьма шумных судебных процессов по
поводу защиты спецификаций интерфейсов как коммерческой тайны или
патентованной технологии В конце концов вопрос был снят, поскольку
промышленность перешла на стандартные интерфейсные технологии.
Сегодня широко используется всего несколько интерфейсных стандартов,
хотя на горизонте появился ряд новых технологий. Важно уметь выбрать
жесткий диск, соответствующий интерфейсу той системы, в которой он будет
установлен. Если система поддерживает несколько интерфейсов, выбор
нужного должен быть сделан на основании критериев скорости, производи-
тельности и цены.
•	SCSI — олин из наиболее распространенных и широко поддерживаемых
дисковых интерфейсов. Существует несколько его разновидностей, обес-
печивающих разную скорость работы; все они допускают подключение
к шине нескольких дисков.
•	IDE — это простой дешевый интерфейс для персональных компьютеров.
Он был назван “встроенным", потому что предполагал наличие аппарат-
ного контроллера, размешенного непосредственно в корпусе жесткого
диска. Взаимодействие между процессором и жестким диском осущест-
влялось на достаточно высоком уровне. Сегодня это стандартная архи-
тектура всех современных дисков. IDE-диски обладают средней скоростью
работы, высокой емкостью и невероятной дешевизной. Тем не менее,
особенности интерфейса IDE делают его пригодным для использования
только в рабочих станциях с четырьмя и менее дисками.
•	Волоконно-оптический канал (стандарт Fibre Channel) — это последова-
тельный интерфейс, завоевывающий популярность в корпоративной среде
благодаря высокой пропускной способности и большому числу устройств,
которые можно одновременно подключать к каналу. Устройства соеди-
няются между собой с помощью волоконно-оптического или коаксиаль-
ного медного кабеля. В настоящее время интерфейс обеспечивает
скорость передачи данных 100 Мбит/с и выше. Волоконно-оптические
сети могут строиться по топологии FC-AL (Fibre Channel Arbitrated
Loop — ответвление волоконно-оптического канала с арбитражной логи-
кой) или с помощью коммутаторов. Волоконно-оптическое устройство
идентифицируется аппаратным номером, которое называется всемирным
именем (World Wide Name) и напоминает МАС-адрес Ethernet.
•	USB — ставший популярным в последнее время стандарт подключения
таких устройств, как клавиатура и мышь. Однако он обладает достаточной
пропускной способностью для обслуживания дисковых накопителей, в
частности съемных жестких дисков и дисководов CD-ROM. Интерфейс
Глоео 8. Добовление нового жесткого диско
141
USB широко распространен и персональных компьютерах и позволяет
легко перемешать диски между системами.
Интерфейсы SCSI и IDF доминируют на рынке дисковых систем, поэтому
только их мы будем подробно рассматривать.
Интерфейс SCSI
Выпускается несколько комплектов интегральных схем, реализующих
интерфейс SCSI, поэтому продавцы часто ставят микросхемы поддержки SCSI
прямо на плату центрального процессора или периферийных устройств.
Стандарт SCSI определяет общи» канал передачи данных, которым могут
пользоваться периферийные устройства всех видов. В большинстве случаев
в SCSI-варианте выпускаются жесткие диски, накопители на магнитной ленте,
сканеры и принтеры. Стандарт SCSI не задает конструкцию и компоновку
диска, он лишь регламентирует взаимодействие диска с другими устройствами.
Стандарт SCSI прошел несколько стадий развития, и в настоящее время
существует версия SCSI-3. Первоначальный вариант, SCSI-1, был разработан
в 1986 г. на основании коммерческого интерфейса системной шины SASI
(Shugart Associates System Interface) и принят в качестве стандарта ANSI.
Вариант SCSI-2 появился в 1990 г. и был обратно совместим со специфи-
кацией SCSI-1, но обладал дополнительными средствами повышения произ-
водительности. В частности, в нем организовывалась очередь команд, что
позволяло устройству переупорядочивать очередь для повышения производи-
тельности. и поддерживался распределенный ввод-вывод.
Существуют разновидности интерфейса SCSI-2, называемые “Fast” (бы-
стрый) и •‘Wide” <расширенный), что означает соответственно удвоение
скорости работы шины и увеличение числа битов, одновременно передавае-
мых по шине (обычно 16 или 32, а не 8)’. Спецификация Wide SCSI допускает
подключение до 16-ти устройств, тогда как в обычном варианте интерфейса —
только 8. Скорость и ширина канала — независимые характеристики, которые
могут присутствовать одновременно.
SCSI-3 — это в действительности семейство стандартов. В него входят
спецификации различных физических носителей, включая традиционные
параллельные шины и высокоскоростные последовательные интерфейсы,
такие как Fibre Channel и IEEE 1394 (FireWire) Определены также наборы
SCSI-команд и введены улучшения, связанные с автоконфигурацией уст-
ройств. поддержкой мультимедийных приложений и новых типов устройств.
Хотя работы над спецификацией SCSI-3 продолжаются, многие ее
элементы уже присутствуют на рынке, часто под именем Ultra SCSI
Спецификация SCSI-3 охватывает стандарт SCSI-2, поэтому их можно считать
совместимыми Но помните: подключение старого устройства к новой шине
может замедлить работу всей системы. Кроме того, ограничивается длина
кабельной системы.
В SCSI-системах иногда применяется такая особенность, как Оифферсн-
пирование. В обычном (“несимметричном”) SCSI-устройстве каждый вывод
заземлен с целью уменьшения перекрестных помех сигналов . Такая разводка
32-разрядные шины SCSI не очень распространены. В некоторых из них требуется несколь-
ко кабелей, обозначаемых как кабель А и кабель Б.
Перекрестные помехи особенно сказываются на работе параллельной электрической шины
Они не оказывают влияния на последовательные и волоконно-оптические интерфейсы, где
максимальная длина кабеля гораздо выше.
142
Чость I Основы одминистрировония
ограничивает длину кабеля 6-ю метрами в SCSI 1 и З-мя метрами в SCSI-2.
В Ultra SCSI обшая длина шины еше меньше и составляет 1,5 метра. При
дифференцировании рядом с каждым проводом вместо заземления проходит
обратный сигнал, в результате чего суммарное напряжение становится равным
нулю и уровень шума существенно снижается.
Благодаря дифференцированию длина кабельной системы увеличивается
до 25-ти метров в SCSI-2 и 12-ти метров в Ultra SCSI. Дополнительная
длина — очень важное преимущество, если вес диски (или библиотеки на
магнитных лентах) расположены в разных стойках. Но дифференцирование
ие поддерживается обычными устройствами, поэтому необходимо убедиться в
наличии дифференциального контроллера, диска, кабеля и терминатора.
Необходимо маркировать все устройства, чтобы случайно не соединить
несовместимые устройства
В табл. 8.1 перечислены различные версии SCSI с указанием характери-
стик шины и длины кабеля
Таблица 8.1. Эволюция интерфейсе SCSI
Версия	Чостота (МГц)	Разрядность (биты)	Скорость (Мбайт/с)	Длина м	Длина в режиме дифферен- цирования (м
SCSI-1	5	8	5	6	25
SCSI-2	5	8	5	6	25
Fast SCSI-2	10	8	10	3	25
Fast/widc SCSI-2	10	16	20	3	25
Ultra SCSI	20	8	20	1.5'	25
Wide Ultra SCSI2	20	16	40	1,5’	25
Wide Ullra2 SCSI2	40	16	80	_з	25 (ВВД)4 12 (НВД)
Wide Ultra} SCSI5	80	16	160	_з	12 (НВД)
1 Может меняться, см. ниже.
2 Стандарты Wide Ultra SCSI и Wide Ultra? SCSI иногда называют Fast-20 wide SCSI
и Fasl-40 wide SCSI соответственно.
3 В этих версиях SCSI используется только дифференцирование.
4 ВВД — это высоковольтное дифференцирование, а НВД — низковольтное. Первое
использовалось в ранних версиях SCSI и нс поддерживается в спецификациях,
старших Ultra? SCSI.
5 Стандарт Wide Ultra3 SCSI иногда называют Ultra-160.
Максимальная длина кабеля в несимметричных системах Ultra SCSI и
Wide Ultra SCSI зависит от числа используемых устройств. В случае 8-ми
устройств предельная длина составляет 1,5 м; если используются только 4
устройства, шину можно увеличить до 3-х метров. В стандарте Wide Ultra
SCSI поддержка 16-ти устройств обеспечивается только в режиме дифферен-
цирования.
В SCSI-устройствах могут встречаться разъемные соединения различных
типов. Они могут быть как внешними, так и внутренними. В обычных
Глово 8. Добовление нового жесткого диско
143
SCSI-устройствах установлены 50-контактные разъемы, а в устройствах с
расширенной разрядностью — 68-контактные. Внутренние устройства под-
ключаются с помощью 50-контактной “'широкой” вилки или 68-контактной
вилки “мини-микро”, установленных на плоском кабеле. Внешние устройства
подключаются с помощью 50- или 68-контактных разъемов высокой плот-
ности. Фирма Apple уменьшила число контактов с 50 до 25, объединив все
линии заземления, чтобы к шине можно было подключать разъем DB-25.
Существует также интересный разъем SCA (Single Connector Attachment —
единое разъемное соединение), применяемый в дисковых массивах “горячей"
замены. Это 80-контактное универсальное разъемное соединение, через
которое могут подаваться все сигналы, в том числе напряжение питания.
На рис. А изображены наиболее распространенные разъемные соедине-
ния.
Centronics
50-контактный, SCSI-1/2, внешний
Разъем на плоском кабеле (розетка)
50-контактный, SCSI-1/2. внутренний
Мими-микро (HD50)
50-контактный, SCSI-2, внешний
Широкий мими-микро (HD66)
68-контектный. SCSI-2/3,
внвшний/внутренний
SCA-2
80-контактный, SCSI-32, внутренний
Рис. А. Роспростроненные розъемные соединения стондорто SCSI
(вид спереди; вилко, если не укозоно иное)
Кабели SCSI обычно имеют с обоих концов вилки, a SCSI-устройства
почти всегда оснашены розетками. Шины SCSI организованы по принципу
шлейфовой цепочки, поэтому у большинства внешних устройств два SCSI-
порта. Оба порта абсолютно одинаковые и взаимозаменяемые, любой можно
использовать как входной. По какой-то неизвестной причине поставщики
сканеров считают, что нормальные законы физики на них не распространя-
ются, и иногда делают в устройстве всего один SCSI-порт (если внутренней
оконечной нагрузки нет. то для таких устройств необходим особый тип
терминатора).
Внутренние SCSI-устройства обычно подключаются с помощью плоского
кабеля. Им нужен только один порт, поскольку разъемные соединения можно
устанавливать посреди плоского кабеля. Необходимо убедиться, что контакт
I шины SCSI подключен к контакту 1 жесткого диска*.
На плоском кабеле первый контакт обычно помечается красной полоской.
144
Чость I Основы одминистрировония
Оконечная нагрузка (терминатор) должна предусматриваться на обоих
концах шины SCSI. Терминаторы поглотают сигналы, достигающие конца
шины, и предотвращают их отражение обратно в шину. Оконечные устройства
различны по конструкции, от маленьких наружных вилок, которые вставля-
ются в обычный разъем, до крошечных резисторных блоков, которые
монтируются иа печатных платах. Некоторые устройства содержат внутрен-
нюю оконечную нагрузку.
В SCSI-1 применялись терминаторы другого типа по сравнению с более
поздними спецификациями (“пассивные”, а не “активные”), поэтому очень
старые терминаторы (и старые устройства с внутренней оконечной нагрузкой)
могут не работать в современных шинах SCSI. На практике такие устройства
встречаются очень редко, поэтому' проблем с терминаторами обычно не
возникает.
Один коней шины чаше всего располагается внутри компьютера (либо
на SCSI-контроллере, либо на внутреннем SCSI-дисководе). Другой конец
завершается на внешнем устройстве или SCSI-контроллере. Если на шине
SCSI периодически возникают ошибки, кажущиеся случайными, в первую
очередь проверьте правильность оконечной нагрузки на обоих концах.
Неправильное использование терминаторов — одна из наиболее частых
ошибок в SCSI-конфигурациях. Эти ошибки не всегда очевидны и трудно
обнаруживаются.
Каждое устройство имеет SCSI-адрес, или “целевой номер”, позволяющий
отличать его от других устройств, подключенных к шине. Целевые номера
располагаются в диапазоне от 0 до 7 или 15, в зависимости от того, какая
шина в наличии: с обычной или расширенной разрядностью. Сам SCSI-кон-
троллер считается устройством и обычно имеет номер 7 (даже в шинах с
расширенной разрядностью, чтобы обеспечивалась обратная совместимость).
Целевые номера всех остальных устройств должны быть уникальными.
Распространенная ошибка — забыть, что у контроллера есть номер, и
назначить этот номер другому устройству.
SCSI-адрес присваивается произвольно. С технической точки зрения он
определяет приоритет устройства на шине, но на практике это не имеет
особого значения. В некоторых системах диск с младшим номером выбирается
в качестве загрузочного, а в других системах требуется, чтобы загрузочный
диск имел целевой номер 0.
Если вам повезет, то на добавляемом к системе устройстве будет внешний
дисковый переключатель для установки целевых номеров. Существуют и
другие способы установки целевых номеров, в частности с помощью
DIP-переключателей и перемычек. Если методика установки номера устрой-
ства не ясна, обратитесь к документации, прилагаемой к аппаратным
средствам.
Стандарт SCSI поддерживает дополнительную форму адресации, назы-
ваемую “номером логического модуля”. В каждом целевом устройстве может
быть несколько логических модулей. Реальный пример — дисковый массив
с одним SCSI-контроллером. Однако на самом деле номера логических
модулей используются редко. Когда встречается термин “номер модуля SCSI”,
можно считать, что речь идет о целевом номере, пока не будет сказано
обратное. Если у SCSI-устройства один логический модуль, он всегда имеет
номер 0.
Шины SCSI довольно просты в конфигурировании, но при их исполь-
зовании может возникнуть целый ряд проблем. Вот некоторые из них.
•	Во многих рабочих станциях есть встроенные SCSI-устройства. Перед
тем как перезагружаться при включении нового устройства, проверьте
Глово 8 Добавление нового легть.ого диско
145
перечень текущих устройств. Помните, что большинство накопителей на
магнитной ленте, а также дисководы гибких дисков некоторых фирм
(главным образом, Hewlett'Packard) относятся к SCSI-устройствам.
•	Убедитесь, что к дифференциальному SCSI-контроллеру подключены
только аналогичные устройства и терминаторы, а если имеется несим-
метричная SCSI-цепочка, то в нее не входят дифференциальные устрой-
ства. Несимметричные и дифференциальные устройства не совместимы.
•	Подключив новое SCSI-устройство, проверьте перечень устройств, выяв-
ленных операционной системой при перезагрузке. Все ли устройства были
обнаружены? Большинство драйверов SCSI не обнаруживает устройств,
имеющих один SCSI-адрес (подобная конфигурация создает много других
проблем).
•	Некоторые расширительные коробки (кожухи с источником питания и
одним или несколькими SCSI-устройствами) имеют внутреннюю оконеч-
ную нагрузку. Если к ним подключены внешние устройства, могут
возникнуть проблемы. Всегда проверяйте наличие двух терминаторов и
следите, чтобы они были расположены на концах шины.
•	Иногда дисковый переключатель, используемый для установки SCSI-ад-
ресов, при установке ориентирован неверно. В таких случаях он будет,
конечно, изменять SCSI-адрес, но совсем не так, как указано на
перекл ючателе.
•	Рассчитывая длину шины SCSI-2, не забудьте учесть кабели внутри
устройств и расширительных коробок (а они могут быть весьма длинны-
ми). Помните также, что максимальная длина кабеля уменьшается при
подключении старых SCS[-устройств к шине нового типа.
•	Никогда не забывайте о том, что SCSI-контроллер имеет собственный
SCSI-адрес!
Интерфейс IDE
Интерфейс IDE. также известный как АТА (AT Attachment — подклю-
чение к АТ-сов.местимым компьютерам), по замыслу разработчиков должен
был быть простым и недорогим. Чаше всего он применяется в персональных
компьютерах и дешевых рабочих станциях. IDE-контроллер встроен непо-
средственно в диск, что уменьшает стоимость интерфейса и упрощает
микрокод контроллера. Интерфейс IDE завоевал популярность в конце
80-х гт. Вскоре после этого появился стандарт АТА-2, удовлетворявший
растущие запросы потребителей и фирм-поставщиков жестких дисков.
В АТА-2 были добавлены режимы PIO (Programmed I/O — программи-
руемый ввод-вывод) и DMA (Direct Memory Access — прямой доступ к
памяти), а также расширена поддержка технологии Plug and Play. Кроме того,
была реализована технология LBA (Logical Block Addressing — логическая
адресация блоков), которая (наряду с расширенными BIOS-программами
персональных компьютеров) позволяла системе обращаться не только к
первым 1024 цилиндрам диска. Ранее из-за подобного ограничения макси-
мальный размер диска составлял 540 Мбайт. В те времена никто и не думал,
что когда-нибудь понадобятся диски большей емкости’
Поскольку BIOS управляет процессом начальной загрузки, иногда
необходимо создать маленький загрузочный раздел в пределах первых 1024
цилиндров, чтобы гарантировать загрузку ядра старой BIOS-программой.
После того как ядро загружено и начало выполняться, необходимость в BIOS
146
Чость I Основы ОДМИНИСТрИрОВОНИЯ
исчезает и появляется возможность доступа к остальной части диска.
Подобный обходной маневр не нужен в сегодняшних системах, поскольку
технология LBA не использует схему адресации “цмлиндр-головка-сектор'.
Современная схема адресации является линейной
В стандарте АТА-3 добавлены средства повышения надежности, управ-
ления питанием и самодиагностики. Стандарт АГА-4 все еше находится в
стадии разработки. Спецификация Ultra-АТА является попыткой устранить
разрыв между стандарта ми АТА-3 и АТА-4 за счет добавления высокопроиз-
водительных режимов, называющихся Ultra DMA/33 и Ultra DMA/66. В них
полоса пропускания шины расширяется с 16 Мбит/с до 33 Мбит/с и
66 Мбит/с соответственно. Стандарт АТА-4 также преследует цель объединить
интерфейсы АТА-3 и ATAPI (АТА Packet Interface — пакетный интерфейс
АТА}. Последний представляет собой протокол, позволяющий дисководам
CD-ROM и накопителям на магнитной ленте работать на шине IDE.
IDE-диски всегда являются внутренними. Максимальная длина кабеля
для шины АТА-2 составляет всего 18 дюймов (45,72 см), из-за чего диск
бывает трудно установить даже в верхний отсек. Помимо ограничения на
длину кабеля, интерфейс IDE позволяет подключать к шине только два
устройства. Для преодоления этого недостатка некоторые производители
оснашают материнские платы несколькими шинами IDE
Доступ к IDE-устройствам производится последовательно, т.е. в опреде-
ленный момент времени активным может быть только одно устройство
Следовательно, производительность будет выше, если распределить устройства
по шинам. Разместите высокоскоростные устройства, например жесткие
диски, на одной шине, а накопители на магнитной ленте и дисководы
CD-ROM — на другой, чтобы медленные устройства не сдерживали работу'
быстрых. В стандарте SCSI работа с несколькими устройствами, подключен-
ными к одной шине, организована гораздо лучше, чем в IDE .
В IDE используется 40-контактный разъем, размещенный на плоском
кабеле, который соединяет диск и интерфейсную плату. В новых IDE-стан-
дартах, в частности в Ultra DMA/66, применяется другой кабель с большим
числом линий заземления, вследствие чего уровень шумов понижен Если
кабель или жесткий диск не маркированы должным образом, убедитесь, чтобы
первый контакт дискового разъема был соединен с первым контактом
интерфейсной платы. Контакт номер I обычно помечается маленькой
цифрой 1 на разъемном соединении Если этой цифры нет, то воспользуйтесь
правилом, которое гласит, что первый контакт расположен ближе всего к
разъему питания. На кабеле первый контакт обозначен красным цветом.
Если к шине IDE подключено несколько устройств, необходимо одно из
них сделать главным, а остальные — подчиненными. Некоторые старые
IDE-диски не могут быть подчиненными, в таком случае нужно попробовать
поменять устройства ролями. Если они по-прежнему не работают, лучше
поместить каждое устройство на отдельную шину.
Устанавливая IDE-устройства, необходимо помнить о следующих моментах.
• Новые IDE-диски работают со старыми платами, а старые IDE-диски
работают с новыми платами. Естественно, поддерживаются только те
возможности, которые являются общими для обоих типов устройств.
В SCSI поддерживаются такие возможности, как перекрывающиеся команды, очередность
команд, распределенный ввод-вывод и высокие скорости передачи данных. Все это позво-
ляет SCS[-устройствам лучше функционировать в многопользовательской среде UNIX.
Глове 8. Добовление нового жесткого диско
147
•	Длина кабеля слишком коротка, поэтому дополнительное устройство
может подключаться к шине с натяжкой. Если устройство работает
нестабильно, проверьте длину кабеля.
•	Иметь дело Со старыми BIOS-программами, которые “видят” только
первые 500 Мбайт диска, — настоящий кошмар. Проверьте в internet,
не выпустил ли производитель новую версию BIOS, В противном случае
лучше купить новую материнскую плату.
•	Хорошие драйверы могут существенно повысить производительность и
надежность жесткого диска, особенно если они поддерживают самые
последние стандарты. Проверьте, располагаете ли вы новейшей версией
драйвера.
Что лучше: SCSI или IDE?
Это часто задаваемый вопрос, на который обычно отвечают, что
“у каждого стандарта свои преимущества”. Мы же рискнем дать простой
ответ: SCSI лучше. Как правило.
Правильнее говорить о том, что стандарт SCSI превосходит IDE по всем
техническим параметрам, но стоимость SCSI-оборудования слишком высока
и часто оказывается неприемлемой. Для однопользовательской рабочей
станции дешевый IDE-диск высокой емкости обеспечит 85% производитель-
ности своего SCSI-аналога. Замена IDE-диска SCSI-вариантом в подобной
ситуации не приведет к заметному повышению производительности.
Однако в некоторых случаях устанавливать SCSI-устройство желательно
или даже необходимо.
•	Если требуется обеспечить максимально возможную производительность,
выбирайте SCSI. Частично рост производительности обусловлен техни-
ческим превосходством интерфейса SCSI в сравнении с интерфейсом
IDE, но в основном он связан с политикой производителей жестких
дисков, которые стремятся разграничить возможности IDE- и SCSI-уст-
ройств. Это выгодно с маркетинговой точки зрения, так как позволяет
производителям разнообразить линии своих продуктов, поэтому они
сознательно не оснащают свои самые новые и производительные
дисковые механизмы интерфейсом IDE.
•	В серверах и многопользовательских системах желательно устанавливать
SCSI-устройства. Интерфейс SCSI незаменим в плане умения эффективно
обрабатывать одновременные запросы. В загруженной системе замена
IDE-диска SCSI-аналогом приведет к ощутимому росту производитель-
ности.
•	Если нужно подключать много устройств, опять выход один: SCSI.
SCSI-устройства хорошо работают с устройствами других типов, тогда
как IDE-диски стараются захватить контроль над шиной.
•	Иногда требуются возможности, которые предоставляет только интерфейс
SCSI. Например, нельзя создать дисковый массив с возможностью
“горячей" замены, состоящий из IDE-дисков.
8 2. Конструкция современного дискового н копителя
Конструкция современного жесткого диска и терминология, используемая
для обозначения его составных частей, приведены на рис. Б. Эта информация
дана главным образом для того, чтобы читатель мог наглядно представить.
14С
Чость I. Основы одминистрировония
как работает жесткий диск Программам, обращающимся к диску, не нужно
знать его физическое устройство.
Рис. Б. Урок по конструкции дискового ноколителя
Жесткий диск состоит из вращающихся круглых пластинок (дисков),
покрытых магнитным слоем Чтение и запись данных осуществляет маленькая
головка, которая меняет ориентацию магнитных частиц на поверхности
пластинок. Корпус накопителя выполнен герметичным, чтобы внутрь не
могла попасть ни пыль, ни грязь. Это делает жесткие диски гораздо более
надежными, чем внешние носители.
На самой заре развития вычислительной техники в дисковых накопителях
устанавливался, как правило, всего один диск. Рост емкости достигался за
счет увеличения диаметра диска. На стене одного из наших кабинетов висит
древний диск диаметром больше четырех футов (120 см), который когда-то
вмещал около 280 Кбайт данных — менее 10% емкости современного гибкого
диска с повышенной плотностью записи.
Сегодня в накопителях стоит не один большой диск, а несколько
маленьких, размещенных этажеркой. Для хранения данных используются обе
стороны дисков, хотя одна из них обычно содержит информацию для
позиционирования, а не собственно данные. Емкость отдельного лиска
достигает 10 Гбайт, и не похоже, чтобы действие закона Мура прекратилось
в обозримом будущем.
Диски вращаются с постоянной скоростью. Чтение и запись производят
маленькие головки, которые скользят нал поверхностями дисков вперед-назад,
подобно игле звукоснимателя в проигрывателе грампластинок Головка
перемещается очень близко к поверхности диска, но не касается ее. Если
головка коснется диска, произойдет то. что называют аварией головки.
Последствия этого могут быть весьма неприятными..
Скорость вращения дисков за последнее время существенно возросла.
Старые диски делали 3600 или 5400 об/мин. Сегодня стандартный пока-
затель — 7200 об/мин. а лиски со скоростями вращения 10000 и 15000 об/мин
завоевывают все большую популярность в секторе устройств высокого класса.
Чем выше скорость вращения, тем меньше время доступа головки к нужному
участку диска и больше скорость передачи данных, но одновременно
Закои Мура (Мооге) гласит о том, что вычислительные мощности (частота процессоров,
емкость дисков и т.д.) удваиваются каждые 18 месяцев.
Глово 8. Добовление нового жесткого диско
149
увеличивается нагрев дисков в связи с повышенным выделением тепла.
Современные высокоскоростные диски требуют хорошей вентиляции.
Для каждой поверхности нужна как минимум одна головка. В первых
накопителях головкам приходилось ‘‘пробегать" огромные расстояния. Кон-
струкция современных дисков более рациональна. Диаметр диска продолжает
сокращаться. Двадцать лет назад стандартным считался диаметр 14 дюймов,
десять лет назад — 5.25 дюйма, а сегодня он составляет 3,5 дюйма и менее.
Перемещение головки в нужную позицию для чтения конкретной порции
данных называется поиском. Каждому дискретному положению, которое может
занимать головка, соответствует дорожка. Дорожки делятся на секторы,
которые обычно имеют размер 512 байтов.
Совокупность дорожек разных дисков, находящихся на равном расстоя-
нии от оси шпинделя, называется цилиндром Если все головки будут двигаться
вместе, то данные, записанные в одном цилиндре, можно будет читать без
дополнительных перемещений- Хотя головки перемещаются достаточно
быстро, диски все равно вращаются гораздо быстрее. Поэтому обращение к
диску, которое не требует от головок поиска новой позиции, будет
выполняться быстрее
В файловой системе UNIX этот факт используется для повышения
производительности. К сожалению, в BSD стала общепринятой неудачная
технология, известная как зональное разбиение на секторы, при которой
дорожки, расположенные ближе к краю диска, содержат больше секторов,
чем внутренние. Чтобы оптимизировать работу жесткого диска, файловая
система скрывает от программ подробности разбиения диска на секторы.
Вместо этого вводится искусственная схема адресации "цилиндр-головка-сек-
тор”, в которой емкость диска подогнана к реальному показателю. Даже
сегодня алгоритмы оптимизации многих файловых систем основаны на
подобной фикции.
8.3.	Обзор процедуры инсталляции
Процесс инсталляции нового диска состоит из следующих этапов:
•	подключение дискового накопителя к компьютеру;
•	создание файлов устройств, через которые будет осуществляться доступ
к диску';
•	форматирование диска;
•	маркировка и разбиение диска на разделы;
•	создание логических томов
•	создание файловых систем UNIX в разделах диска;
•	организация автоматического монтирования;
•	создание разделов подкачки.
Ниже этот процесс описан в общих чертах, без рассмотрения особенно-
стей, присущих конкретным системам. В параграфе 8.5 инсталляция нового
диска описывается детально для каждой из тестовых систем.
Подключение диска
Процедура подключения диска зависит от его интерфейса. Если это
IDE-диск, постарайтесь сконфигурировать систему так, чтобы к каждой шине
был подсоединен только один диск. Проверьте ориентацию кабелей и
150
Чость I Основы сдминистрировония
правильность установок “главный/подчиненный” на каждом диске Если это
SCSI-диск. убедитесь, что на обоих концах шины присутствуют терминаторы,
длина кабеля не превышает допустимую и целевой номер нового устройства
не конфликтует с номерами существующих устройств.
Создание файлов устройств
Подробно о файлах устройств рассказано в главе 12.
Прежде чем получить доступ к новому диску, нужно создать в каталоге
/dev файлы устройств для этого диска. Потребуются файлы как блок-ориен-
тированных устройств (используются в основном для монтирования файловых
систем), так и байт-ориентированных (для резервирования и проверки
целостности файловых систем). Многие версии UNIX автоматически создают
файлы для всех возможных SCSI-устройств. Подробная информация об этом
содержится в параграфе 8.5.
Одной неосторожной операцией записи на диск можно за считанные
секунды полностью разрушить файловую систему, поэтому права доступа к
файлам дисковых устройств следует устанавливать очень осторожно. Мы
предоставляем права на чтение и запись владельцу (пользователю root) и
права на чтение членам группы operator. Это позволяет операторам выполнять
программу dump без прав суперполыователя и запрещает простым пользова-
телям осуществлять прямой доступ к лиску.
Форматирование диско
Излишне усердные фирмы-продавцы часто указывают емкость дисков в
байтах без учета форматирования. Как правило, около 10% емкости уходит
на маркировку поверхностей дисков, которая необходима для того, чтобы
аппаратные и программные средства могли находить записанные там данные.
Покупая диск, всегда оценивайте его емкость в “форматированных" байтах
и соответствующим образом срашплванте цены.
Еше одна популярная уловка — указывать емкость диска в “мегабайтах’',
считая, что мегабайт равен миллиону байтов. На самом деле мегабайт равен
2м, или 1048576 байтам, и эта потрясающая арифметика приводит к тому,
что реальная емкость лиска завышается почти на 5%.
В процессе форматирования на диск записывается адресная информация
и метки синхронизации для разграничения секторов. Кроме того, выявляются
“дефектные” блоки — некачественные участки носителей, которые невоз-
можно использовать для чтения и записи. В старых дисках (в том числе
стандарта SMD) за обнаружение дефектных блоков и переадресацию записи
в них отвечает драйвер устройства UNIX. В SCSI-накопителях контроль
дефектных блоков осуществляет контроллер диска, поэтому о них не нужно
беспокоиться ни пользователю, ни драйверу'.
Все жесткие диски, как правило, форматируются на заводе, и качество
такого форматирования часто выше, чем то, которого можно достичь в
реальных условиях Лучше избегать низкоуровневого форматирования, если
оно не требуется. Когда начинают возникать ошибки чтения/записи, в первую
очередь проверьте кабели, терминаторы и номера устройств (для SCSI-дисков),
Все дефектные блоки, которые появятся после форматирования диска, не будут обрабаты-
ваться автоматически. Их использование может привести к ошибкам при чтении и записи
и даже к потере данных.
Глево 8 Добовление нового жесткого диско
151
так как появление таких ошибок не всегда означает наличие дефектных
блоков. Если после всего диск по-прежнему работает неустойчиво, лучше
заменить его, а не тратить много часов на форматирование.
IDE-диски, как правило, не предназначены для самостоятельного формати-
рования. Тем не менее, существуют специальные программы форматирования,
обычно работающие в Windows, которые предлагаются посгавшикакш дисков.
Убедитесь, что программа работает с конкретным диском, и тщательно
следуйте инструкциям разработчиков программы.
SCSI-диски форматируются автоматически по команде, посылаемой с
главного компьютера. Способ выдачи такой команды зависит от системы. На
персональном компьютере команду можно послать из BIOS-программы
контроллера SCSI В Solaris эта команда называется format, а в HP-UX —
mediainit.
В некоторых системах пользователь может проверить целостность диска,
записывая на него произвольные комбинации данных, а затем считывая их.
Этот процесс обычно очень длительный, поэтому такую проверку рекомен-
дуется проводить только в том случае, если есть подозрение, что диск
неисправен. Можете спокойно оставить машину, которая выполняет тесты,
включенной на всю ночь. Не беспокойтесь по поводу “износа" диска при
слишком интенсивной эксплуатации или активном тестировании. Диски
рассчитаны на непрерывную круглосуточную работу
Разделы и метки
После форматирования диска и маркировки дефектных блоков его
необходимо разбить на фрагменты, называемые разделами. Разбивка на
разделы позволяет рассматривать диск как группу независимых областей
данных, а не как одно огромное пространство блоков. Кроме того, можно
скрывать системные области диска (например, блоки начальной загрузки и
саму таблицу разделов) от высокоуровневого программного обеспечения
(например, от файловой системы). О компоновке всего диска в целом знает
только драйвер устройства, а остальные программы обращаются к разделам.
Наличие разделов облегчает выполнение резервного копирования, не
позволяет пользователям посягать на чужие области диска, повышает
производительность и ограничивает потенциальный ущерб, наносимый не-
управляемыми программами. В большинстве операционных систем таблица
разделов (равно как и другая информация о диске) хранится на диске в
записи, называемой меткой. Метка обычно занимает первые несколько
блоков диска. Ее содержимое зависит от типа системы, но в общем метка
содержит достаточно информации для того, чтобы программа начальной
загрузки нашла ядро ОС.
В принципе, разделы имеют четкие границы и отделены друг от друга,
но почти во всех системах один раздел определен как образ всего диска в
целом. Это позволяет командам пользовательского уровня обращаться к диску
“непосредственно” через обычный файл устройства. Например, пользователь-
ский процесс может записать метку диска или скопировать ее содержимое
на резервный диск с помощью команды dd. Конечно, этот специальный
раздел следует использовать очень осторожно, так как он позволяет мгновенно
испортить все разделы на диске.
Разработчики некоторых систем идут еще дальше и дают возможность
определять несколько перекрывающихся наборов разделов. Например, разде-
лы 0, 1 и 2 делят диск одним способом, а разделы 3 и 4 — другим.
152
Чость I Основы администрировония
Предполагается, что пользователь применяет один набор согласованных
разделов, а другие просто игнорирует. В реальной жизни такая конфигурация
приводит к операторским ошибкам и повреждению данных.
В современных системах по сравнению с их предшественницами коли-
чество разделов сокращено, но большинство систем все равно имеют минимум
три раздела.
•	Корневой раздел. В этом разделе содержатся все файлы, необходимые для
перевода системы в однопользовательский режим. Как мера предосто-
рожности на другом диске часто создается копия этого раздела.
•	Раздел подкачки. В области подкачки хранятся страницы виртуальной
памяти, если они не помещаются в физической памяти. В каждой системе
должен быть хотя бы один раздел подкачку. Подробнее о виртуальной
памяти читайте в параграфе 25.3.
•	Пользовательский раздел. Это общее пространство для начальных катало-
гов, файлов данных, библиотек исходных текстов программ и т.д.
Существуют разные мнения о том, какой способ разбиения дисков на
разделы является лучшим. Вот некоторые советы.
•	Если есть несколько дисков, сделайте на одном из них копию корневой
файловой системы и проверьте, может ли система загружаться с диска.
•	Наращивая память на своей машине, увеличивайте и раздел подкачки.
Для нормальной работы размер этого раздела должен как минимум
равняться размеру оперативной памяти, что позволит в случае сбоя
разместить в данном разделе файл дампа.
•	Распределив раздел подкачки между разными дисками, можно добиться
повышения производительности. Это касается и файловых систем.
Помещайте интенсивно используемые файловые системы на отдельные
диски. Замечания по этому поводу приведены в параграфе 25.3.
•	При создании резервных копий разделов не делайте размер дискового
раздела больше, чем позволяет емкость резервного устройства. Читайте
параграф 10.1.
•	Данные, которые часто подвергаются изменениям, целесообразно разме-
щать в таких разделах, резервные копии которых делаются чаще.
•	Рекомендуем создать отдельную файловою систему для временных файлов
(/hnp). Таким образом, можно будет отвести для них ограниченную
область дискового пространства и избавить себя от необходимости
создавать их резервные копии.
•	Если система ведет файлы регистрации в каталоге /var, то лучше сделать
этот каталог отдельным разделом диска. Во многих системах каталог /var
является частью очень маленького корневого раздела, что приводит к
быстрому заполнению последнего и останову машины.
Создание логических томов
В некоторых системах есть “менеджер логических томов”, который
реализует особый вид разбивки на разделы. Мы не станем здесь описывать
особенности всех существующих менеджеров, но у них есть ряд общих
характеристик, о которых следует упомянуть. (Тем не менее, далее мы
расскажем о менеджере Veritas, существующем в HP-UX.)
Большинство менеджеров позволяют сгруппировать несколько дисков или
разделов в логический том, или метадиск, который представляется для
Глово 8. Добавление нового жесткого диско
153
пользователя единым виртуальным диском. Компоненты логического тома
можно объединять различными способами. В режиме конкатенации физиче-
ские блоки каждого лиска остаются неразрывными, а диски как бы
соединяются друг с другом. В режиме чередования соседние блоки виртуаль-
ного диска могут на самом деле находиться на разных физических
устройствах.
Некоторые менеджеры томов поддержитют стандарт RAID5, в котором
применяется режим чередования с дополнительной проверкой контрольных
сумм. Контрольные суммы обеспечивают необходимую избыточность, благо-
даря чему данные можно восстановить, даже если один из дисков выходит
из строя
Менеджеры томов часто поддерживают и такую технологию как мркам-
ное дублирование. Зеркальный том связан с другим томом аналогичного
размера. Данные, записываемые в один том, дублируются в другом. Если в
одном томе происходит аппаратный сбой, система автоматически переадресует
запросы его зеркальному аналогу, не прерывая их выполнения После
устранения проблемы оба тома должны пройти процедуру синхронизации.
Veritas — это менеджер логических томов, поддерживаемый как в Solans,
так и в HP-UX. Фирма Sun предлагает для своих систем собственный
менеджер под названием Solstice DiskSuite. Vinum — это менеджер с открытым
кодом, доступный во FreeBSD и созданный под влиянием менеджера Veritas.
В Linux поддержка технологии RAI D реализована на уровне ядра, но имеется
также отдельный менеджер томов, называющийся Linux LVM.
Файловые системы
Даже после того как жесткий диск разбит на разделы, он еше не готов
к хранению файлов. Свою лепту в подготовку диска должна внести и файловая
система
Для инсталляции файловой системы в один из разделов диска исполь-
зуется команда mkfs или newfs. Команда newfs. по сути, является интерфейсной
надстройкой к команде mkfs. В старых версиях UNIX нужно было много
знать о характеристиках диска, но сейчас эта необходимость отпала. Чтобы
создать файловую систему, достаточно правильно задать команду (mkfs или
newfs) и указать имя раздела.
Процедура инсталляции в деталях будет описана ниже. Здесь же мы
рассмотрим вопрос о том. как при построении файловой системы файлы
помещаются на диск Речь пойдет о быстрой файловой системе Беркли
(Berkeley Fast File System), которая была разработана Маккузиком (McKusick),
Джоем (Joy) и Леффлером (Leffler) для 4.2BSD. Ее использует большинство
современных версий UNIX Файловая система BSD состоит из пяти
структурных компонентов:
•	совокупность блоков для индексных дескрипторов;
•	совокупность распределенных “суперблоков”;
•	таблица распределения дисковых блоков в файловой системе;
•	сводка использования блоков;
•	совокупность блоков данных.
Каждый раздел файловой системы разбит на группы, содержащие от 1
до 32 цилиндров. Такие структуры, как таблицы индексных дескрипторов,
распределены по группам цилиндров так. чтобы блоки, используемые вместе.
154
Чость I. Основы одминистрироеония
находились на диске близко друг к другу. Это позволяет сократить время
поиска при доступе к блокам одного файла.
Индексный дескриптор — это табличная запись фиксированного размера,
содержащая информацию об одном файле. Поскольку пространство для
индексных дескрипторов должно выделяться, когда UNIX выполняет началь-
ное структурирование файловой системы, необходимо заранее решить,
сколько индексных дескрипторов должно быть создано. Невозможно пред-
сказать точно, сколько файлов (индексных дескрипторов) понадобится в
будущем. Используя эмпирическую формулу, UNIX оценивает это число на
основании величины раздела и среднего размера файла.
При создании файловой системы можно увеличить или уменьшить
количество индексных дескрипторов: в файловых системах со множеством
мелких файлов должно быть больше индексных дескрипторов, а в файловых
системах с несколькими большими файлами — меньше Значение, заданное
по умолчанию, позволяет заполнить диск 2048 файлами.
Суперблок — это запись, содержащая характеристики файловой системы.
В суперблоке хранится информация о длине дискового блока, размере и
расположении таблиц индексных дескрипторов, таблица распределения дис-
ковых блоков и информация об использовании блоков, а также данные о
размерах групп цилиндров и другие важные параметры файловой системы.
Поскольку повреждение суперблока приводит к стиранию исключительно
важной информации, то в системе создается несколько копий суперблока,
которые размешаются в разных местах. Так было не всегда: ранние файловые
системы при повреждении суперблока разрушались полностью. Теперь же
при перестройке поврежденной файловой системы можно дать программе
fsck указание использовать другой суперблок О местонахождении резервных
суперблоков сообщит команда newfs -N. Один из них всегда находится в
блоке 32.
Дополнительно о программе fsck рассказано в параграфе 8.4.
Для каждой монтируемой файловой системы UNIX делает одну копию
суперблока в памяти и несколько копий на диске. Системный вызов sync
записывает кэшированные суперблоки на их постоянное место на диске,
делая файловую систему целостной. Это позволяет свести к минимуму ущерб,
который был бы нанесен аварийным остановом машины, если бы файловая
система не обновила суперблоки. Вызов sync, кроме того, извлекает из буфера
модифицированные индексные дескрипторы и кэшированные блоки данных
В большинстве систем вызов sync выполняется каждые 30 с, что позволяет
минимизировать потери данных в случае сбоя системы.
Таблица распределения дисковых блоков содержит сведения о размеще-
нии свободных блоков в файловой системе. При создании новых файлов эта
таблица анализируется на предмет выбора эффективной схемы размещения.
Сводка использования блоков отражает основную информацию о блоках,
которые уже используются.
Автоматическое монтирование файловой системы
Для того чтобы сделать файловую систему доступной для UNIX-процес-
сов, ее нужно смонтировать. Точкой монтирования может быть любой каталог.
Его файлы и подкаталоги будут недоступны, пока файловая система
смонтирована поверх них. Подробно о монтировании файловых систем
рассказывается в параграфе 5.2. Необходимо убедиться, что раздел, который
Глово 8 Добовление нового жесткого диско
155

монтируется или проверяется, содержит корректную файловую систему: если
попытаться применить команду' mount или fsck к разделу подкачки, результат
будет непредсказуем.
После подключения нового диска необходимо смонтировать новые
файловые системы “вручную” с целью проверки правильности их работы
Например, команда
#	mount /dev/edla /mnt
монтирует в каталоге /mnt файловую систему, находящуюся в разделе,
который представлен файлом устройства /dev/sdla (имена устройств неоди-
наковые в разных системах). Если файловая система абсолютно новая, то ее
содержимое будет выглядеть приблизительно так:
#	! /mnt
lost+found
Каталог lost+found автоматически создается при построении файловой
системы. Он используется программой fsck в экстренных случаях, поэтому
не удаляйте его. В каталоге lost+found заранее зарезервировано дополнитель-
ное место, чтобы программа fsck могла хранить там •несвязанные” файлы,
не заботясь о выделении дисковой памяти в нестабильно работающей
файловой системе. В некоторых системах имеется команда mklost+fonnd,
которая воссоздает этот специальный каталог, если он был случайно удален.
Информацию об использовании дискового пространства, занимаемого
файловой системой, можно получить с помощью команды df. Вот пример из
BSD-системы:
#	df /иве
Filesystem lK-blocks Used Avail Capacity Mounted on
Zdev/wdOslf 610495	509516	236140	68%	/mnt
Размер блока, которым оперирует команда df, может составлять 1 Кбайт
или 512 байтов в зависимости от системы. В некоторых системах команда
df -к выводит статистику с учетом блоков размером 1 Кбайт.
В HP-UX команда df работает совершенно по-другому. Чтобы получить
показанные выше результаты, воспользуйтесь командой bdf (“Беркли-версия df').
В большинстве случаев пользователь пытается настроить систему так.
чтобы локальные файловые системы монтировались во время начальной
загрузки. В конфигурационном файле в каталоге /etc перечислены, кроме
всего прочего, имена устройств и точки монтирования всех дисков системы.
В большинстве систем этот файл называется fstab (сокращение от “filesystem
table” — таблица файловых систем), но в старых версиях HP-UX он носит
имя checklist, а в Solaris имеет другой формат и называется vfstab. Далее мы
будет называть этот файл fstab. даже если в конкретной системе он именуется
по-друтому.
Файл fstab, включающим описание указанной выше файловой системы,
может выглядеть так’;
# Device	MouncpoinE	FSrype	Options	Dump	Pass#
/dev/wdOslb	none	swap	SW	0	0
/dev/wdOsla	/	ufs	rw	i	1
/dev/wdCslf	/usr	uf s	rw	2	2
Этот пример взят из FreeBSD. В других системах, кроме Solans, файл выглядит практически
так же.
.66
Чость I Основы одминистрировония
/dev/acdOc /cdrom	cd9660	ro,noauto	0	0
proc	/proc	procfs	rw	00
server:/export /server	nfs	rw	00
Каждая строка состоит из шести полей, разделенных пробелами, и
содержит описание одной файловой системы. Для удобочитаемости поля
обычно выравнивают, но делать это не обязательно.
В первом поле указывается имя устройства. Файл fstab может включать
имена точек монтирования удаленных систем. В этом случае первое поле
будет содержать путевое имя NFS, как в последней строке. Запись ser-
ver : /export обозначает каталог /export на машине server.
Подробно об NFS рассказывается в главе 17.
В некоторых случаях в первом поле задается тип виртуальной файловой
системы. Так, в показанном выше примере в предпоследней строке описана
файловая система proc, которая предоставляет информацию о процессах
ядра пользовательским утилитам. Иногда в качестве устройства указано имя
swap — это резидентная файловая система, которая использует раздел
подкачки для резервного хранения данных (к примеру, в Solaris это файловая
система типа tmpfs).
Во втором поле указывается точка монтирования, в третьем — тип
файловой системы. В разных системах тип локальных файловых систем
обозначается по-разному: в Solaris и FreeBSD — ufs, в HP-UX — vxfs или
hfs, а в Linux — ext2.
В четвертом поле задаются опции монтирования (запись rw обозначает
чтение-запись, это установка по умолчанию). В пятом поле указывается
“частота” создания файла дампа. Теоретически это поле может использоваться
программами резервного копирования, но обычно оно игнорируется.
В шестом поле указывается порядок проверки файловых систем програм-
мой fsck. Файловые системы с одинаковым значением этого поля проверяются
по возможности параллельно. Нежелательно, чтобы одновременно проверя-
лись файловые системы, расположенные на одном диске, так как в подобном
случае головка диска будет столь часто перемешаться вперед-назад, что
производительность существенно снизится.
Программа fick описывается в параграфе 9.5.
Файл fstab читают команды mount, umount, swapon и fsck, поэтому очень
важно, чтобы представленные в нем данные были полными и достоверными.
Команды mount и umount берут из этого файла недостающую информацию,
если в командной строке было указано только имя раздели или точка
монтирования. Например, при наличии приведенного выше файла fstab
команда
i mount /cdrom
будет интерпретирована так:
#	mount -t cd9660 -о го,noauto /dav/acdOc /cdrom
Команда mount -а монтирует все "обычные” файловые системы, пере-
численные в файле fstab. Она обычно выполняется из стартовых сценариев
во время начальной загрузки. Флаг -t (Red Hat и FreeBSD) или -F (Solaris
и HP-UX) ограничивает ее действие файловыми системами определенного
типа. Например, команда
*	mount -at ufa
Глово 8. Добавление нового жесткого диско
157
монтирует нее локальные файловые системы во FreeBSD. Команда mount
читает файл fstab последовательно. Поэтому файловые системы, которые
монтируются к другим файловым системам, должны следовать в файле за
своими родительскими разделами. Например, строка для точки монтирования
/usr/local должна следовать за строкой для точки /usr, если /usr — отдельная
файловая система.
Команда umount, предназначенная для демонтирования файловых систем,
имеет похожий синтаксис. В большинстве систем невозможно демонтировать
файловую систему, в которой какой-либо процесс хранит свой текущий
каталог или в которой есть открытые файлы. Имеются способы избежать
подобного ограничения (см. параграф 5.2).
Создание раздела подкачки
Одно из главных преимуществ UNIX состоит в реализации концепции
виртуальной памяти. Эта особенность позволяет операционной системе делать
вид, что у машины больше памяти, чем есть на самом деле. Когда процессы
пытаются использовать “дополнительную” память, запросы переадресуются
к системным дискам, которые выступают в роли очень медленного ОЗУ
Переброска содержимого памяти на диск и обратно называется выгрузкой или
перекачкой.'
Для достижения максимальной эффективности при подкачке в качестве
запоминающего устройства обычно используются неструктурированные дис-
ковые разделы (без файловых систем). Для управления содержимым области
подкачки ядро поддерживает собственную, упрошегпчую схему соответствия
блоков памяти дисковым блокам. В качестве области подкачки можно
использовать и обычный дисковый файл, но в этом случае подкачка будет
осуществляться медленнее.
Подробнее о создании разделов подкачки рассказано в параграфе 25.3.
Чем больше раздел подкачки, тем больше виртуальной памяти доступно
для процессов. Максимальная эффективность подкачки достигается в случае
распределения области подкачки между несколькими дисками (или, еше
лучше, между несколькими шинами SCSI).
Разрешить подкачку на конкретном устройстве можно вручную, но лучше,
чтобы эта функция выполнялась автоматически во время начальной загрузки.
В большинстве систем области подкачки можно указывать в файле fstab —
том самом, который содержит перечень монтируемых файловых систем.
Строка с информацией о подкачке выглядит так“-
/dev/daCb none	swap sw	00
В процессе загрузки выполняется команда (как правило, swapon или swap),
которая разрешает подкачку для всех разделов, перечисленных в файле fstab.
Конкретные команды и их синтаксис для каждой из тестовых систем описаны
в параграфе 8.5.
Выгрузка и перекачка — технически разные понятия. На данном этапе мы объединим их и
назовем ’’подкачкой”. Более подробное описание концепции виртуальной памяти в UNIX
приведено в параграфе 25.3-
Эта строка взята из FreeBSD; в остальных системах она будет другой.
158
Чость I Основы (администрирования
8.4.
U1
Ф
Программа fsck: проверка и восстановление
файловых систем
Файловая система UNIX на удивление надежна и выполняет значитель-
ную работу, справляясь с неожиданными сбоями системы и частыми отказами
аппаратных средств. Тем не менее, существует ряд причин, вызывающих
повреждение файловых систем и нарушение их целостности.
Каждый раз, когда ядро выдает сообщение о панике или отказывает
система питания, в тех файловых системах, которые непосредственно перед
сбоем находились в активном состоянии, происходят незначительные нару-
шения. Поскольку ядро хранит в памяти как блоки данных, так и
управляющую информацию, то самый последний образ файловой системы
распределяется между диском и памятью. Во время сбоя часть образа,
находящаяся в памяти, пропадает. Хранящиеся в памяти блоки практически
замешаются теми их версиями, которые были записаны на диск последними.
Имеются различные подходы к устранению этой проблемы. Небольшие
повреждения обычно поддаются устранению с помощью команды fsck
(сокращение от “filesystem consistency check” — проверка целостности фай-
ловой системы). С архитектурной точки зрения это не очень элегантный
подход, но он себя оправдывает в большинстве распространенных ситуаций.
Файловые системы, в которых ведется журнал событий, записывают
метаданные в последовательный журнальный файл, сохраняемый на диске
перед завершением каждой команды. Впоследствии метаданные переносятся
из журнального файла в соответствующее место файловой системы. Если
происходит сбой системы, журнальный файл просматривается в обратном
порядке и находится точка, когда система последний раз находилась в
согласованном состоянии. Полная проверка файловой системы не требуется.
Это очень полезно, если размер файловой системы очень велик.
Ведение журнала событий поддерживается в файловой системе UFS в
Solaris и в файловой системе VXFS в HP-UX. Просмотрите описание
процедуры инсталляции жесткого диска в HP-UX, где объясняется, как
включить журнальный режим.
Если журнал событий не поддерживается, остается надеяться на програм-
му fsck. Вот пять наиболее часто встречающихся видов повреждений:
•	наличие индексных дескрипторов, на которые нет ссылок;
•	неоправданно большие значения счетчиков ссылок;
•	неиспользуемые блоки данных, не отраженные в таблицах блоков;
•	блоки данных, указанные как свободные, но используемые в файле;
•	неверная статистическая информация в суперблоке.
Программа fsck устраняет все эти проблемы автоматически. Если
программа делает изменения в файловой системе, ее нужно повторно
выполнять до тех пор. пока файловая система не станет согласованной.
Диски обычно проверяются во время начальной загрузки с помощью
команды fsck -р. которая исследует локальные файловые системы, перечис-
ленные в файле fstab, и исправляет вышеуказанные пять ошибок. Новые
операционные системы запоминают, какие файловые системы не были
демонтированы корректно, и проверяют только их. Если ведется журнал
событий, программа fsck сообщает о том, что поддерживается журнальный
режим и восстанавливает последнее согласованное состояние системы на
основании записей в журнальном файле.
Глава 8 Добавление нового жесткого диско
1L9
Команду fsck -р можно выполнить и для отдельной файловой системы,
например:
*	fack -р /dav/radOg
Программа fsck обрабатывает файлы и блок-ориентированных, и байт-
ориентированных устройств, но с последними она работает быстрее
Когда программа fsck читает файл fstab, чтобы узнать, какие файловые
системы проверять, она придерживается последовательности, обозначенной
в последнем поле каждой записи. Файловые системы проверяются в порядке
возрастания номеров. Если две файловые системы размещены иа разных
дисках, им может быть присвоен один порядковый номер. Это заставит
программу fsck проверить их одновременно, при этом минимизируется время,
затрачиваемое на ожидание дискового ввода-вывода. Первым всегда следует
проверять корневой раздел.
Ошибки, не относящиеся ни к одной из пяти вышеуказанных категорий,
потенциально опасны. Они заставляют команду fsck -р вывести сообщение и
помощи и завершить свою работ}’. В этом случае нужно запустить программу
fsck без опции -р. При прогоне в ручном режиме программа просит
подтверждения на каждую восстановительную операцию, которую собирается
выполнить. Вот некоторые ошибки, которые программа fsck считает опасными:
	блоки, принадлежащие более чем одному файлу;
	блоки, находящиеся вне диапазона файловой системы;
•	слишком маленькие счетчики ссылок:
•	неучтенные блоки;
•	каталоги, содержащие ссылки на невыделенные индексные дескрипторы:
• различные ошибки формата файлов.
К сожалению, не имея глубоких знаний о структуре файловой системы,
восстановить диск вручную невозможно Никогда не пробуйте производить
прямую запись в файловую систему через файлы устройств.
Во многих операционных системах имеется отладчик файловых систем
(часто называемый fsdb), который позволяет проверять и модифицировать
данные на низком уровне, но для эффективного его использования нужно
очень хорошо понимать, что он делает. Если ограничиться чтением файловой
системы и не пытаться се модифицировать, то можно избежать усугубления
проблем.
На практике это означает, что выбор невелик и практически сводится к
принятию условий, поставленных программой fsck. Проблемы можно свести
к минимуму путем тщательной регистрации сообщений, выдаваемых про-
граммой. так как иногда они дают ответ на вопрос о том, какой файл (или
файлы) является сбойным. Если программа запрашивает разрешение на
удаление файла, попробуйте сначала скопировать его в другую файловую
систему, а уж потом разрешайте программе продолжать работу. Но помните;
каждый раз, пытаясь обратиться к поврежденной файловой системе, вы
рискуете вызвать в ядре неразрешимую ошибку.
Если поврежденная файловая система содержит ценные данные, и
программа fsck не смогла автоматически ее восстановить, не эксперименти-
руйте с ней, не создав предварительно резервной копии. Можно попробовать
применить.к диску команду dump, но она предполагает наличие неповреж-
денной файловой системы, поэтому в результате могут быть потеряны данные
(или команда завершится выдачей сообщения об ошибке). Лучше всего
160
Чость I. Основы одммнистрирования
перестраховаться и выполнить для всего диска команду dd, чтобы создать
резервный диск.
Если программа fsck знает только номер индексного дескриптора файла,
то для выяснения его путевого имени в некоторых системах можно
использовать команду ncheck. Для очистки дефектного индексного дескрип-
тора, который программа fsck не может восстановить, можно воспользоваться
командой clri (данные, естественно, будут потеряны).
Когда программа fsck обнаруживает файл, родительский каталог которого
определить невозможно, она помешает такой файл в каталог lost+found.
находящийся на верхнем уровне файловой системы. Поскольку имя. присво-
енное файлу, регистрируется только в его родительском каталоге, имена
файлов-сирот определить нельзя, и файлам, помещаемым в каталог lost+found,
присваиваются имена, совпадающие с номерами их индексных дескрипторов.
8.5. Особенности подключения дисков в различных
операционных системах
К сожалению, добавление новых дисковых накопителей — это задача,
которую каждый поставщик UNIX-систем трактует по-своему. При описании
этой процедуры для различных систем мы придерживаемся следующего
принципа: сначала перечисляем команды, необходимые для добавления диска,
а затем приводим наглядный пример. Даже команды одного поставщика могут
быть разными в зависимости от архитектуры диска и версии ОС.
Во всех примерах демонстрируется добавление к системе SCSI-диска с
тремя разделами: один из них будет резервным корневым (монтируемым в
каталоге /Ькгоог). второй — разделом подкачки, а в третьем будут находиться
пользовательские файлы (монтируется в каталоге /new). Модель добавляемого
диска — Seagate ST446452W. интерфейс — Wide Ultra SCSI, неформатиро-
ванная емкость — 63 Гбайт, форматированная емкость — 47 Гбайт.
Во многих случаях в форматирующие программы будут передаваться, на
первый взгляд, произвольные значения параметров конфигурации. Это
объясняется тем. что для SCSI-дисков многие аргументы не имеют никакого
смысла*. Раньше нужно было знать точные характеристики каждого диска,
сегодня достаточно воспользоваться значениями, предоставленными по умол-
чанию
Solaris
Ниже описывается процедура добавления диска в SPARC-системе Solaris
На платформе Intel процесс будет аналогичным, но имена устройств другие
и последовательность действий несколько иная. Если используется менеджер
логических томов Veritas, то информацию о работе с ним можно получить
в параграфе “HP-UX”, так как в системе HP-UX используется этот же
менеджер.
После подключения нового дискового накопителя проверьте целевые
номера всех SCSI-устройств с помощью команды probe-scsi монитора ППЗУ**
И сегодня можно корректировать параметры диска с целью повышения его производитель-
ности, но рассмотрение данного вопроса выходит за рамки нашей книги.
Если текущий монитор ППЗУ не понимает эту команду, попробуйте вызвать новую версию
монитора, нажав <N>. Строка приглашения нового монитора выглядит так: “ок”.
Ггово 8. Добовление нового жесткого диско
161
Если система непрерывно автоматически перезагружается, не выдавая ника-
ких сообщений, кроме
rebooting...
это значит, что имеет место либо конфликт адресов, либо проблема с
терминаторами. Если система успешно загружается, посмотрите на сообще-
ния, выдаваемые на консоль, и проверьте, найден ли диск
В нашем случае результаты работы команды probe-scsi бущт такими:
ok prob*-Fcai
Target 3
Unit 0 Disk SEAGATE ST446452W	0001
ok boot —r
Флаг -г команды boot служит для Solaris указанием переконфигурировать
себя, осуществив поиск нового оборудования и создав соответствующие
файлы устройств. Когда система загружена, просмотрите выходную инфор-
мацию команды dmesg и найдите сообщения ядра, касающиеся нового диска
В нашем случае ядро жалуется, что мы еше не записали на диск метку
системы Solaris. Но в действительности это хороший знак, поскольку он
означает, что ядро обнаружило диск.
sd3 at еврО: target 3 lun О
sd3 is /sbusfilf, 0/espdmage, 84OOOOO/esp0e, 08OO0OO/scl@3, 0
WARNING: /sbusglf ,O/espdmafie, 8400000/esp@e, 8800000/sdP3, 0 (sd3) :
corrupt label - wrong magic number
Vendor ’SEAGATE', product 'ST44b452W, 91923356
512 byte blocks
Файлы блок-ориентированных и байт-ориентированных устройств нахо-
дятся в каталогах /dev/dsk и /dev/rdsk соответственно Имена файлов имеют
следующий формат:
/dev/[г]dsk/cWtXdYsZ
где W — номер контроллера, X — целевой SCSI-номер, Y — логический
SCSI-номер (почти всегда 0). a Z — номер раздела. Эти файлы на самом
деле являются символическими ссылками на элементы дерева каталогов
/device, где находятся настоящие файлы устройств. Следует всегда работать
со ссылками, размещенными именно в каталоге /dev, так как имена файлов
в каталоге /device трудно набирать и они могут меняться.
При добавлении нового устройства нужно выполнить команду boot -г из
монитора начальной загрузки, чтобы убедиться в правильности создания
ссылок на новые устройства. Можно также создать ссылки на диски с
помощью команд drvconfig и disk (они, в свою очередь, запускают утилиту
devfcadm). Никаких аргументов они не требуют.
I drvconfig; disks
В Solaris раздел 2 обычно обозначает весь диск. Мы используем этот
раздел при форматировании диска и создании метки. Поскольку наш диск
имеет целевой SCSI-номер 3, файл устройства, соответствующий всему диску,
будет называться /dev/rdsk/c0t3d0s2.
1Г?
Чосгь I. Основы одминисгрировония
Программа format форматирует диски и разбивает их на разделы. Она
управляется в режиме меню.
# format /dev/rd»k/c0t3d0o2
/dev/rdsk/c0t3d0s2: configured with capacity of 43.77GB
selecting /dev/rdsk/c0t3d0s2
[disk formatted]
FORMAT MENU:
Если диск не был помечен или использовался другой операционной
системой, программа format может спросить, нужно ли прямо сейчас пометить
диск. Если ответить утвердительно, программа запишет на диск стандартную
метку Solaris. В противном случае нужно добавить метку вручную с помощью
команды label программы format. Мы рекомендуем поставить на диск
стандартную метку и посмотреть, нормальные ли получатся разделы:
format» label
Ready to label disk, continue? у
format» partition
PARTITION MENU:
partition» print
Current partition table (default):
Total cylinders available: 9994+2 (reserved cylinders)
Parr Tag Flag Cylinders Size	Blocks
0	root	wm	0-26	130.05MB	(29/0/0)	266336
1	swap	wu	29-57	130.05MB	(29/0/0)	266336
2	backup	wu	0-9993	43.77GB	(9994/0/0)	91784696
6 home wm
56-9993	43.51GB (9936/0/0) 91252224
Стандартная метка не очень хорошо подходит для наших целей, поэтому
мы увеличим размеры резервного корневого раздела и раздела подкачки, но
уменьшим размер раздела home. Для разделов root и home должны быть
установлены флаги wm (записываемый и монтируемый), а для раздела swap
обязательны флаги wu (записываемый и немонтируемый). Ниже показано,
как сделать один из разделов; остальные конфигурируются аналогичным
образом,
partition» 0
Part Tag Flag Cylinders Size	Blocks
0 root wm	0-26 130.05MB	(29/0/0)	266336
Enter partition id tag[root]: root
Enter partition permission flags[wm]- wm
Enter new starting cyl[OJ: 0
Enter partition size [266336b, 29c, 130.05mb, 0.13gb]: 2gb
После того как размеры всех разделов заданы, снова выведите таблицу
разделов, чтобы убедиться в успешном завершении процедуры. Проверьте,
нет ли перекрытия разделов (по крайней мере, тех разделов, с которыми
будет вестись работа), иначе файловая система почти наверняка будет
повреждена. Если все правильно, снова введите команду label, чтобы создать
новую метку. В нашем случае результат будет выглядеть так:
partition» print
Current partition table (unnamed):
Total cylinders available: 9994+2 (reserved cylinders)
Гпсво 8. Добовпенме нового жесткого диско
I6J
о
1
2
б
Tag	Flag	Cylinders	Size
root	wm	0-456	2.00GB
swap	wu	457-2263	8.00GB
backup	wu	0-9993	43.77GB
home	wm	2284-9993	33.76GB
Blocks
(457/0/0)
(1627/0/0)
(9994/0/0)
(7710/0/0)
4197086
16779166
91784896
70808640
partiticn> label
Ready to label disk, continue? yea
Выйдите из программы format, введя команду quit дважды: один раз для
выхода из режима создания разделов, второй — для выхода из самой
программы:
partition> quit
format> quit
Теперь мы готовы создать файловые системы для резервного корневого
раздела и пользовательские файловые системы.
# n«w£s -г 3600 /dev/rdsk/c0t3d0s0
newfs: construct file system Zdev/rdsk/c0t3d0s0; ly/n]? у
/dev/rdsk/c0t3d0s0: 4197068 sectors in 457 cylinders of 28 tracks,
328 sectors
2049.4MB in 42 cyl groups (11 c/g, 49.33MB/g, 8000 i/g)
super-block backups (for fsck —F ufs -o b=#) at;
32, 101392, 202752, 304112, 405472, 506832, 608192, 709552,
810912, 912272, 1013632, 1114992, 1216352, 1317712, 1419072,
1520432, 1621792,
После создания файловых систем сразу же проверим их командой fsck:
# fsck /dev/r-dek/cOt3dOsO
*	* /dev/rdsk/c0t3d0s0
*	* Phase 1 - Check Blocks and Sizes
•	* Phase 2 - Check Pathnames
*	* Phase 3 - Check Connectivity
*	* Phase 4 — Check Reference Counts
*	* Phase 5 - Check Cyl groups
2 files, 9 used, 2055846 free (14 frags, 256979 blocks, 0.0% fragmentation»
Необходимо также выполнить команды newfs и fsck для раздела 6. но
этот процесс здесь не показан.
Создав файловые системы, можно приступать к их монтированию. Для
доступа к разделу команда mount использует файлы блок-ориентированных
(каталог /dev/dsk), а не байт-ориентированных (каталог /dev/rdsk) устройств.
В новых версиях Solaris поддерживается журнальный режим для файловых
систем UFS (стандартный тип файловой системы). Записывая информацию
об изменениях в журнальный файл, прежде чем вносить изменения на диск,
можно обеспечить согласованность файловой системы. Это особенно удобно
при работе с большими файловыми системах™, когда в случае системного
сбоя команда fsck выполняется очень долго.
Чтобы включить журнальный режим, выполните команду mount с флагом
-о logging (или задайте эту команду в файле /etc/vfslabj Тогда команда fsck
не будет выполнять полную проверку файловой системы, а лишь просмотрит
журнальный файл в обратном порядке и отменит последние несогласованные
изменения. Мы не задали журнальный режим лишь из-за желания сделать
наш пример проще и понятнее.
164
Часть I Основы администрирования
Итак, мы готовы к монтированию новых разделов:
» mkdir /bkroot
*	mkdlr /new
№ mount /dev/dak/c0t3d0«0 /bkroot
t mount /dev/dak/c0t3d0»6 /new
#	d£ -k /bkroot
Filesystem	kbytes	used	avail	capacity	Mounted	on
/dev/dsk/cCt3dCsO	2055855	9	1994171	1%	/bkroot
Команда df показывает, что резервный корневой раздел смонтирован
правильно.
Теперь с помощью команды swap -а сообщим ядру о создании новой
области подкачки в разделе 1. а затем посредством команды swap -I убедимся
в том. что новая область активизирована:
t яwap -a /d«v/dak/c0t3d0al
#	swap -1
swapfile	dev	swaplo	blocks	free
/dev/dsk/c0t3d0sl 32,25	16	4194272	4194272
Команда swap -I выводит список всех активных в данный момент областей
подкачки. Поскольку новый раздел подкачки в списке присутствует, значит,
все прошло хорошо.
Необходимо добавить записи в файл /etc/vfslab. чтобы новые файловые
системы при загрузке системы монтировались автоматически. В Solaris этот
файл немного отличается от файлов /elc/fstab в других системах. Каждая его
запись содержит имя как блок-ориентированного, так и байт-ориентирован-
ного устройства (используются программами mount и feck соответственно).
Далее указаны точка монтирования, тип файловой системы и порядок
проверки. Следующей задается опция yes или по в зависимости от того,
должна ли файловая система монтироваться но время начальной загрузки.
В последнем поле указываются различные опции, например, следует ли
включать журнальный раздел. Если никаких опций не требуется, поставьте
дефис.
Вот какие строки мы добавляем'
tdevice
#to mount
/dev/dsk/cOt3dOsO
/dev/dsk/cOt3dOs6
/dev/dsk/c0t3d0sl
dev.ee	mount	FS	mount	
to fsck	point	Type		at boot
/dev/rdsk/cDt3dOsO	/bkroot	ufs	1	yes
/dev/rdsk/c0t3d0s6	/ new	ufs	2	yes
-	-	swap	—	no
Чтобы сделать файловую систему /bkroot резервной копией корневого
раздела, необходимо скопировать поверх нее содержимое корневого раздеча.
Эту работу выполняют команды и Гм! и nip н tifsrestore:
I cd /bkroot
#	ufadump Out / | ufsrestore -rf -
DUMP: Date of this level C dump: Tue Jun
7 19:11:44 1954
Раздел bkroot можно будет загружать только после прогона на новом
диске программы installboot, которая копирует небольшую программу началь-
ной загрузки в начало диска Когда включается питание системы, монитор
ППЗУ загружает эту программу, а она. в свою очередь, загружает ядро из
Гповс 8. Добовгение нового жесткого диско
165
корневой файловой системы. Программе in.stallbool нужно указать диск и
файл, содержащий блок начальной нагрузки
I /ижг/ibin/instailboot /usr/lib/fв/ufs/bootblk /dev/rdak/c0t3d0s0
Последний этап — перезагрузиться и проверить, чтобы все файловые
системы были смонтированы правильно и новый раздел подкачки был
активизирован. Кроме того, нужно убедиться в возможности начальной
загрузки из раздела /bkroot после того, как в него будут скопированы файлы.
HP-UX
В HP-UX 10.20 менеджер логических томов Veritas был дополнительным
системным компонентом. В HP-UX 11.00 он определен как стандартная
файловая система VXFS. Это очень удобное дополнение, особенно если
учесть, что в HP-UX раньше вообще не поддерживалось понятие дискового
раздела. Veritas также доступен в Solaris. Windows NT и других операционных
системах.
Менеджер логических томов позволяет достаточно гибко управлять
дисками, но весь процесс при этом усложняется. Мы воспользуемся
командами менеджера для создания резервного корневого раздела, большого
свободного раздела и раздела подкачки. Рассмотрение сложных возможностей
менеджера выхолит за рамки данной книги. Читайте интерактивную доку-
ментацию и руководство пользователя.
Перед начальной загрузкой UNIX можно получить из монитора ППЗУ
перечень SCSI-устройств. К сожалению, конкретный способ получения
списка в значительной степени зависит от типа компьютера. После начальной
загрузки нужно убедиться в том, что ядро распознало устройство, просмотрев
вывод команды dmesg или ioscan. Применив команд)' ioscan к нашим дискам,
мы узнали, что новый диск имеет целевой номер 3:
i ioscan -fn -С disk
Class	I	H/W Path	Driver	S/W State	Description
disk	2	S/16/5.3.0	sdisk	CLAIMED	SEAGATE ST446452W
/dev/dsk/c0t3d0 /dev/rdsk/cOt3dO
disk	1	S/16/5.6.0	sdisk	CLAIMED	SEAGATE ST34573W
/dev/dsk/c0t3d0 /dev/rdsk/c0t6d0
Убедившись, что диск распознан, можно начинать программную конфи-
гурацию. Менеджер логических томов определяет три уровня абстракции
Во-первых,, нужно задать физические тома, в данном случае добавляемые
жесткие диски. Во-вторых, нужно объединить физические тома в группы
томов, которые интерпретируются как единое дисковое пространство. Нако-
нец, группа томов разбивается на логические тома, которые обрабатываются
как отдельные диски. По сути, логические тома играют ту же роль, что и
дисковые разделы в других системах.
Команда pvcreate идентифицирует физические тома. Связь с ними
организуется посредством файлов устройств, которые располагаются в
каталогах /dev/dsk и /dev/rdsk (соответственно блок-ориентированные и
байт-ориентированные устройства). Эти файлы создаются программой insf
автоматически на этапе начальной загрузки. Имена файлов имеют следующий
формат:
/dev/[r]dsk/cItDdNIsP]
К D
Чость I Основы сдминистрировония
где I — номер интерфейса на шине контроллера. D — целевой SCSI-номер
диска, N — логический номер устройства (обычно 0), а Р — необязательный
номер раздела. В нашем случае новому диску соответствуют файлы
/dev/rdsk/c0(3d0 и /dev/dsk/cOt3dO.
Обычно современные жесткие диски не должны форматироваться на
низком уровне. В случае необходимости это можно сделать с помощью
команды mediainit. Когда низкоуровневое форматирование началось, его
нельзя прервать, иначе диск будет поврежден и его придется форматировать
заново. Сам процесс форматирования занимает достаточно много времени.
Мы пропустим этап низкоуровневого форматирования и просто иденти-
фицируем физические тома с помощью команды pvcreate Опция -В позволяет
зарезервировать место для информации о загрузке, которая добавляется
командой mkboot:
#	/uar/ebin/pvcraate -В /dav/rdsk/сОt3d0
Physical volume "/dev/rdsk/cot3d0" has been created.
I mkboot /dev/rdak/cOt3dO
Определив диск как физический том, нужно добавить его в новую группу
томов с помощью команды vgcreale. Впоследствии посредством команды
vgextend можно будет включить в группу дополнительные диски, но в нашем
случае группа будет содержать только один диск.
Прежде чем образовывать группу томов, нужно вручную создать для него
каталог (обычно /dev/vgXX. где ХК — номер группы), а в нем — файл
устройства по имени group Младший номер устройства должен быть
уникальным среди всех групп томов в системе. Его формат OxNNOOOO, где
NN — шестнадцатеричное число в диапазоне от 00 до максимального чиста
групп (задается с помощью настраиваемого параметра ядра maxvgs). По
умолчанию предел равен 14 в шестнадцатеричной системе (20 в десятичной).
Подробнее о параметрах ядра рассказывается в главе 12.
Может также потребоваться увеличить размер физическом страницы для
группы томов, если диск достаточно большой. Данное значение определяет
базовую единицу распределения дисковой памяти, и все размеры логических
томов будут устанавливаться кратными этой величине. Она указывается в
мегабайтах и по умолчанию составляет 4 Мбайт. Если в процессе конфигу-
рирования логических томов появляется сообщение вида ’"File loo big" (файл
слишком велик) или "‘No such device” (нет такого устройства), попытайтесь
увеличить размер страницы, воспользовавшись флагом -s команды vgcreate.
Мы рекомендуем начинать с размера 8 Мб и повышать его по возможности.
Для нашего диска емкостью 47 Гбайт размер страницы составляет 16 Мбайт.
# mkdir /dev/vgOl
#	mknod /dev/vgOl/group c 64 0x010000
#	vgcreate -s 16 /dav/vg01 /dev/dsk/c0t3d0
Increased the number of physical extents per physical volume to 2B05,
Volume group ’’/dev/vgOl" has been successfully created.
Volume Group configuration for /dev/vgOl has been saved in
/etc/lvmconf/vg01.conf
#--vgdisplay /dav/vgOl
	 Volume groups 	
VG Name	/dev/vgOl
VG Write Access	read/write
VG Status	available
Глово В. Добовление нового жесткого диско
167
После того как диски добавлены в группу томов, можно начинать обратно
разбивать ее, но уже на логические тома. Команда Ivcreate создает новый
логический том. При наличии флага -L размер тома задается в мегабайтах,
а при наличии флага -I — в логических страницах. Логическая страница
соответствует физической дисковой странице, описанной выше, и обычно
имеет размер 4 Мб, если не было указано иное значение с помощью команды
vgcreate. Размеры томов, задаваемые в мегабайтах, будут округляться, чтобы
оказаться кратными размеру логической страницы.
В представленном ниже фрагменте размеры корневого резервного раздела
(] Гбайт) и раздела подкачки (1 Гбайт) указываются в мегабайтах - Остав-
шееся число логических страниц выясняется с помощью команды vgdisplay.
и из них формируется третий логический том Стандартное имя логического
тома имеет формат /dev/vgXX/lvonN, где УХ — номер группы томов, а Л' —
номер тома в порядке возрастания. Можно задать более описательное имя,
воспользовавшись опцией -п. но мы не стали этого делать.
Если планируется использовать логический том для начальной загрузки,
подкачки или хранения дампов ядра, необходимо задать, чтобы соответст-
вующий участок диска был непрерывным, и отключить переназначение
поврежденных блоков. Это делается с помощью флагов -С и -г команды
Ivcreate.
I Ivcreate -С у -г n -L 1024 /dev/vgol
Logical volume ”/dev/vg01/lvoll" has been successfully created
with character device ”/dev/vg01/rlvoll”.
Logical volume •'/dev/vgOl/lvoll" has been successfully extended.
Volume Group configuration for /dev/vgOl has been saved in
/etc/lvmconf/vgOl.conf
#	Ivcreate -С у -r n -L 1024 /dev/vgol
Logical volume "7dev/vg01/lvol2" has been successfully created
with character device ”/dev/vg01/rlvol2”.
#	Ivcreate -1 2676 /dev/vgOl
Logical volume "/dev/vg01/lvol3" has been successfully created
with character device *‘/dev/vg01/rlvoi3" -
Необходимо выполнить команду Ivin boot, чтобы уведомить систему о
новом корневом томе и томе подкачки:
4 lvlnboot -I /dev/vgOl/lvoll
Volume Group configuration for /dev/vgOl has been saved in
/etc/lvmconf/vg01.conf
#	lvlnboot -в /dev/vg01/lvol2
Volume Group configuration for /dev/vgOl has been saved in
/etc/lvmconf/vgOl.conf
Другой способ создания логического тома включается в том. что сначала
выполняется команда Ivcreate. формирующая том нулевой длины, а затем
вызывается команда Ivextend. которая увеличивает его размер. При этом
можно точно указать, какие физические тома в группе образуют логический
В HP-ИХ присутствует ограничение, согласно которому область подкачки должна распо-
лагаться в пределах первых двух гигабайтов физического диска, а загрузочный том должен
быть первым логическим томом. Мы выбрали для корневого тома и тома подкачки
одинаковый размер I Гбайт, чтобы уложиться в рамки этого ограничения. Подробности
можно прочитать в документации к команде lvlnboot.
160
Чость I. Основы ОДМИНИСТрИрОБОНИЯ
том. Когда команда Ivcreate создает ненулевой том, она просто использует
свободные дисковые страницы любых физических томов, что подходит для
большинства ситуаиий.
После того как логические тома созданы, их необходимо проверить,
выполнив команду vgdisplay -v /dev/vgOl. Можно также узнать, каким
логическим томам принадлежит тот или иной физический том, запустив
команду pvdisplay -v /dev/dsk/c0t3d0. Результаты работы команды pvdisplay
могут быть достаточно большими, поэтому лучше направить их по каналу
программе постраничной разбивки, такой как more.
Далее следует с помощью команды newfs создать файловые системы в
логических томах. Стандартный тип файловой системы указан в файле
/etc/dcfault/fs. Обычно это VXFS (vxfs), т.е. файловая система менеджера
логических томов Veritas. В любой команде, работающей с файловой
системой, можно указать другой тип системы, воспользовавшись опцией -F.
Допустима также файловая система HFS (hfs), являющаяся разновидностью
быстрой файловой системы Беркли — FFS (по умолчанию используется в
большинстве версий UNIX). Поддержка HFS оставлена в целях обратной
совместимости; в новых системах гораздо лучше работать с VXFS.
Команда newfs в качестве аргумента принимает имя байт-орнентирован-
ного устройства, связанного с заданным логическим томом:
♦	newfs -F vxfs /dev/vgOl/гIvoll
version 3 layout
1048576 sectors, 1048576 blocks o£ size 1D24, log size
1024 blocks
unlimited inodes, 1048576 data blocks, 1047224 free data clocks
32 allocation units of 32768 blocks, 32768 data blocks
first allocation unit starts at block 0
overhead per allocationunit is 0 blocks
♦	newfs -J vxfs /dev/vg01/rlvol3
version 3 layout
43843584 sectors, 5480488 blocks of size 8192, log size 256 blocks
Поскольку операционная система VXFS поддерживает журнальный режим
(в Solaris он включается с помощью опции монтирования -о logging),
программа fsck всегда выполняется быстро:
#	fsck /dev/vg01/rlvoll
file system is clean - lof replay is not required
Теперь можно монтировать файловые системы. Как всегда, команда mount
требует указать имя блок-ориентированного устройства. Чтобы убедиться в
правильном выполнении процедуры монтирования, мы запускаем команду
bdf (это BSD-версия команды df, которая для некоторых людей понятнее).
#	mkdlr /new
1 mount /dav/vg01/lvol3 /new
t bdf /new
Filesystem	Kbytes	used	avail	%used	Mounted	on
/dev/vq01/lvol3	43843584	3616	4349T480	0%	/new
Далее мы добавим записи о диске в файл /etc/fstab, называвшийся
/etc/checklist в HP-UX 10 и ранее. В каждой записи этого файла указано имя
блок-ориентированного устройства, точка монтирования, тип файловой
Глово 8. Добовление нового жесткого диско
169
системы, опции, частота создания резервных копий и порядок проверки
программой fsck. Можно также добавить комментарии. Указанный ниже
параметр delaylog позволяет пожертвовать надежностью ради скорости.
Получить информвцию об этом и других параметрах монтирования файловой
системы VXFS можно на странице интерактивного руководства mount_vxfs.
Две наши новые файловые системы описаны так:
/dev/vgOl/lvoll	/bkroot	vxfs	delaylog	0	2
/dev/vg01/lvol3	/new	vxfs	delaylog	0	2
Все, что осталось сделать, — это включить режим подкачки для второго
логического тома. Команда swapon назначает устройство для подкачки и
принимает имя блок-ориентированного устройства- Если необходимо создать
несколько областей подкачки, может потребоваться модифицировать параметр
ядра maxswapchunks. В любом случае при возникновении проблем команда
swapon выдаст предупреждение. По завершении работы команды имеет смысл
выполнить команду swapinfo. чтобы убедиться в правильном назначении
областей.
Подробнее о параметрах ядра рассказывается в главе 12.
О swapon /dev/vg01/lvol2
# swapinfo					
	Kb	Kb	Kb	START/	Kb
TYPE	AVAIL	USED	FREE	LIMIT RESERVE PRI NAME	
dev	262144	0	262144	0	1 Zdev/vg00/lvol2
dev	1048576	0	1048576	0	1 /dev/vg01/lvol2
reserve	-	50876	-50876		
Похоже, все		прошло	успешно.	Нужно не	забыть добавить запись для
устройства подкачки в файл /etc/fstab, иначе при перезагрузке система не
выделит для него дисковое пространство;
/dev/vg01/lvo!2 /	swap defaults 0 0 # swap device
После всех этих операций следует перезагрузиться и проверить, добавлены
ли записи в файл /etc/btab, выполнено ли автоматическое монтирование и
правильно ли организована подкачка.
Red Hat
После инсталляции нового диска, прежде чем загружать ядро, желательно
убедиться, что система распознает устройство. Если это IDE-диск, проверьте,
что он распознается программой конфигурации BIOS, которую можно
вызывать нажатием “магической” последовательности клавиш перед началом
загрузки системы. Обратитесь к руководству, поставляемому с компьютером
или материнской платой, чтобы получить информацию о конфигурировании
BIOS для IDE-устройств.
Многие SCSI-платы имеют программу настройки BIOS, которую можно
вызвать перед началом загрузки. В этом случае необходимо провести
сканирование SCSI-шины. чтобы проверить, подключено ли к ней новое
устройство. Если эта процедура приводит к зависанию или выдаче сообщения
об ошибке, то, возможно, был выбран идентификатор устройства, который
уже кем-то занят, или неправильно установлены терминаторы.
170
Часть I. Основы администрирования
С помощью BIOS-программы SCSI-контроллера можно также провести
низкоуровневое форматирование диска Для некоторых дисков эта операция
занимает много времени; к тому же. ее нельзя прервать, так что будьте готовы
к этому.
Если SCSI-плата не располагает пользовательскими средствами конфи-
гурирования, всегда можно просто загрузить систему и посмотреть на
сообщения, выдаваемые ядром. При отсутствии сообщений от SCSI-драйвера
не исключено, что необходимо инсталлировать драйвер, прежде чем устрой-
ство сможет быть распознано ядром.
Об инсталляции драйверов устройств рассказывается в параграфе 12.8.
В нашем случае SCSI-контроллер BusLogtc выдал такое сообщение.
scsiO : BuslHjgic BT-948
всз1 : 1 host.
Vendor: SEAGATE Model: ST446452W Bev г 0001
Type:	Direct-Access	ANSI SCSI revision: 02
Detected scsi disk sda st scsiO, channel 0, id 3, ion 0
scsiO: Target 3: Queue Depth 2B, Asynchronous
SCSI device sda: hdwr sector-512 bytes. Sectors-91923356 [44884 MB] (44.9 GB1
sda: unknown partition table
He обращайте внимания на сообщение о таблице разделов, так как это
первое обращение к диску. Когда система завершит загрузку, можно будет
приступать к разбивке диска на разделы.
В первую очередь необходимо проверить, существуют ли файлы устройств
для диска. В Linux имена файлов, соответствующих SCSI-дискам, имеют
формат /dev/sdXN, где X — это символ в нижнем регистре, идентифицирую-
щий диск (а‘ — SCSI-диск с самым младшим номером, Ъ’ — следующий
диск и т-д.*), a JV- это номер раздела, начинающийся с 1. При ссылке на
весь диск номер раздела просто опускается. В Linux нет байт-ориентирован-
ных дисковых устройств.
В данном примере наш диск является первым в SCSI-цепочке. Следова-
тельно, первый раздел будет называться /dev/sdal, я ссылка на весь диск
будет такой: /dev/sda. Если файлов устройств нет, их можно создать с
помощью сценария /dev/MAKEDEV-
# cd /dev
* ./MAKEDEV sda
Теперь диск готов к разбивке на разделы. Как и в большинстве
операционных систем на персональных компьютерах, в Red Hat соответст-
вующая утилита называется fdisk. Хотя все версии утилиты работают примерно
одинаково (они реализуют стандартную систему разбивки на разделы,
предложенную компанией Microsoft), существует множество особенностей.
Желательно для начала прочесть документацию и убедиться, что имеющаяся
версия утилиты fdisk работает так. как описано ниже.
t fdisk /dev/sda
The number of cylinders for this disk is set to 5':21..
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1)	software that runs at boot tune (e.g., LILO)
Обратите внимание на то, что эти буквы обозначают порядок целевых номеров SCSI-уст-
ройств, а не сами номера. Если добавить или удалить диск, все буквы поменяются.
Глово 8. Добовление нового жесткого диско
171
2)	booting and partitioning software from other oSs
(e.g.r DIS FDISK, OS/2 FDISK)
Поскольку мы будем использовать диск только в среде Linux, мы
проигнорируем предупреждающее сообщение. Как объяснялось в
параграфе 8.2, иногда важно делать первый раздел маленьким, чтобы не
возникало проблем со старыми BIOS-программами и другими операционными
системами, установленными на том же диске.
Программа fdisk является интерактивной, введите гл, чтобы отобразить
список всех команд. Мы будем использовать такие команды:
•	п — создает новый раздел;
•	t — изменяет тип раздела;
•	р — отображает таблицу разделов;
•	w — записывает таблицу разделов на диск.
Так как на нашем диске еще нет разделов, мы начнем с того, что создадим
один. Если на диске имеются старые разделы, их нужно предварительно
удалить с помощью команды delete утилиты fdisk. Утилита ничего не
поменяет на диске, пока не будет дана команда записать таблицу разделов.
В таблице разделов есть место для размещения четырех первичных
разделов. Любой из них можно сделать расширенным, т.е. указывающим на
другую таблицу разделов с еще четырьмя элементами — логическими разде-
лами. Проше всего ограничиться только первичными разделами, что мы и
сделаем:
Command (m for help): new
Command action
e extended
p primary partition (1-4): p
Partition number (1-4): 1
First cylinder (1-5721, default 1) : 1
Last cylinder or +eize or +sizeM or +sxzeK (1-5721, default 5721): +2G
Command (m for help): print
Disk /dev/sda: 255 heads, 63 sectors, 5721 cylinders
Units - cylinders of 16065 * 512 bytes
Device	Boot Start	End	Blocks	Id	System
/dev/sdal	1	255	2С4Й256	83	Linux
Раздел подкачки создается аналогичным образом, только тип раздела
будет не Linux, a Swap. Хотя ядру безразличен тип раздела, некоторые
программы и сценарии пытаются на его основании понять назначение
раздела. В настоящее время размер областей подкачки в Linux не может
превышать 2 Гбайт, поэтому мы указали максимально допустимый размер.
Возможно, для большинства ПК-приложений это чересчур много, но раз уж
у нас такой большой диск, можно позволить себе быть столь щедрыми.
Команда mkswap выдаст предупреждение, если она не сможет использовать
все выделенное пространство.
Command (га for help): new
Command action
e extended
p primary partition (1-4): p
Partition number (1-4): 2
172
Чость I. Основы ОДМИНИСТрИрОВОний
First cylinder (256-5721, default 256): 256
Last cylinder or +size or +sizeM or +sizeK (256-1275, default 1275): 511
Command (m for help): type
Partition type (1-4): 2
Hex code (type L to list codes): 82
Changed system type of partition 2 to 82 (Linux swap)
Третий раздел создается точно так же. Перед тем как записать таблиц}'
разделов на диск, просмотрим ее:
Command (хп for help) : print
Disk /dev/sda: 255 heads, 63 sectors, 5721 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks
/dev/sdal 1 255 2048256
/dev/sda2 256 511 2056320
/dev/sda3 512 5721 41849325
id System
83 Linux
82 Swap
83 Linux
Рядом с числом блоков будет отображена звездочка, если раздел не
заканчивается на границе цилиндра. В этом случае можно либо удалить раздел
и создать его заново, указав нужное число цилиндров, либо смириться с тем,
что небольшая часть диска будет недоступна В данном случае с таблицей
разделов никаких проблем нет, поэтому мы записываем ее на диск:
Command (m for help): write
The partition table has been altered!
Calling ioctl() to re-read partition table.
SCSI device sda: hdwr sector-512 bytes. Sectors-91923356 [44884 MB] [44.9 GB]
sda: sdal sda2 sda3
Syncing disks.
Некоторые администраторы предпочитают после записи таблицы разделов
перезагрузиться, чтобы убедиться в стабильной работе компьютера, прежде
чем создавать файловые системы. В наши дни в этом нет особой необходи-
мости, но для тех, кто привык инсталлировать Windows, лучше все же
перезагрузиться, чтобы успокоить нервную систему.
Теперь можно приступать к созданию файловых систем. В настоящее
время стандартным типом файловой системы в Linux де-факто является
файловая система Extended 2 (ext2fs), которая основана на быстрой
файловой системе Беркли (FFS — Fast File System). Она создается с помощью
утилиты mkeZfs. В Linux поддерживается много других файловых систем, но
лишь для немногих имеется утилита mkfs.
Для утилиты tnkeZfs нужно указать имя устройства и размер раздела:
# mke2fa /dev/sdal 2048256
mke2fs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09
Linux ext2 filesystem format
514000 inodes, 2048001 blocks
102412 blocks (5.00%) reserved for the super user
First data block=l
Block size-1024 (ioq-0)
Fragment size-1024 (log=0)
250 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Главе 8. Добовление нового жесткого диско
173
Superblcck backups stored on blocks:
8193/ 16385, 24577, 32769, 40961, 49153, 57345, 65537,
Writing inode tables: 250/250 done
Writing superblocks and filesystem accounting information:
done
Более крупная система создается так же, но процесс выполняется дольше.
Если заранее известно, что не все из индексных дескрипторов, создаваемых
утилитой mke2fc, понадобятся, можно уменьшить их число, увеличив тем
самым место для реальных данных. Но лучше иметь запас, чем недостачу,
так как при нехватке дескрипторов нельзя будет создать ни одного файла.
После того как файловая система создана, увеличить число индексных
дескрипторов нельзя
Создав файловые системы, запустим программу fsck, чтобы проверить их
правильность:
#	fsck -f /dav/sdal
Parallelizing fsck version 1.14 (9-Jan-1999)
e2fsck 1.14, O-Jan-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdel: 11/514000 files (0.0% non-contiguous), 67014/2048001 blocks
Как только будут созданы точки монтирования, можно смонтировать
файловые системы:
#	mkdir /bkroot
*	mount /dev/sdal /bkroot
I df -k /bkroot ,
Filesystem	Ik-blocks	Used	Available	Use%	Mounted	on
/dev/sdal	1981000	13	1878575	0%	/bkroot
Чтобы обеспечить автоматическое монтирование новых файловых систем
на этапе начальной загрузки, необходимо добавить запись для каждой из них
в файл /etc/fctab. Каждая запись должна содержать имя устройства, имя точки
монтирования, тип файловой системы, опции монтирования, частоту созда-
ния резервных копий и номер прохода для программы fsck:
/dev/sdal /bkroot
/dev/sda3 /bkroot
ext2	defaults 0 2
ext2	defaults 0 2
Для того чтобы диск стал загружаемым, на него необходимо поместить
загрузчик LILO. Это делвется с помощью программы lilo, которая берет свои
параметры конфигурации (имя загружаемого ядра и др.) из файла /etc/lilo.conf
Подробнее об инсталляции и конфигурировании загрузчика LILO рассказы-
валось в параграфе 2.2.
Финальный шаг заключается в создании области подкачки и добавлении
ее к системе. Разделы подкачки инициализируются с помощью команды
mkswap, которая в качестве аргументов принимает имя устройства и размер
раздела подкачки в секторах. Последнее значение можно узнать у программы
fdisk (см. выше). Это, однако, отнимает много времени и едва ли необходимо.
174
Чость I. Основы одминистрировоний
Когда область подкачки создана, ее нужно активизировать с помощью
команды swapon. Эта команда также проверяет, правильно ли была добавлена
данная область.
i mkewap -с /dev/ede2 2056320
Setting up swapspace version 1, size = 2105667584 bytes
* swapon /dev/ada2
♦ awapon -
Filename	Type	Size	Used	Priority
/dev/hda5	partition	133020	688	-1
/dev/sda2	partition	2056316	0	-2
Как всегда, нужно добавить запись для нового раздела в файл /etc/fstab.
чтобы система автоматически подключила его при перезагрузке. В нашем
случае это будет следующая запись:
/dev/sda2 swap swap defaults 0 0
Теперь нужно перегрузиться и убедиться, что все записи добавлены в
файл /etc/fstab, а все файловые системы и раздел подкачки функционируют
нормально.
FreeBSD
Заставить иаш диск емкостью 47 Гбайт работать во FreeBSD оказалось
нелегкой задачей. Утилита разбивки диска disklabel постоянно выдавала
загадочное сообщение “no space left on device” (на устройстве не осталось
места). Потратив массу времени на выяснение причин каждой ошибки и
перебор различных параметров, мы сдались и выбрали диск гораздо меньшей
емкости. Seagate ST32550W (SCSI-2, 2 Гбайт). Возможно, к тому времени,
когда вы будете читать эту книгу, проблема будет решена, если же вы
столкнетесь с ней, воспользуйтесь инсталляционной утилитой /stand/sysinstall
Как и в других системах, необходимо проверить правильность инсталля-
ции на самом низком уровне. Современные SCSI-контроллеры имеют
встроенную программу конфигурирования BIOS, которую можно вызывать
нажатием “магической” последовательности клавиш во время процедуры
самотестирования при включении питания. BIOS-программа позволяет ска-
нировать шину SCSI в поиске устройств и сообщает о возможных проблемах
и конфликтах. Кроме того, она допускает низкоуровневое форматирование
диска.
Загрузив систему, посмотрите сообщения, информирующие о том, что
ядро распознало новый диск:
daO ar btO bus 0 target 3 lun О
daO: <SEAGATE ST32550W SUN2.1G O418> Fixed Direct Access SCSI-2 device
daO: З.ЗООМВ/s transfers. Tagged Queueing Enabled
daO: 2048MB (4194995 512 bytes sectors: 255H 63S/T 261C)
Разбивка диска на разделы во FreeBSD выполняется в два этапа. Сначала
создается секция, а затем она делится на разделы путем записи в нее
BSD-метки. Во FreeBSD секция — это то, что в других операционных
системах называется разделом, и ссылка на нее хранится в той же таблице
разделов, которую утилита fdisk создает в Red Hat и Windows. Придется
запомнить, что секцией называется физический раздел, создаваемый утилитой
Глово 8. Добовление нового жесткого диско
175
fdisk. а разделом — логическая область в пределах секции, определяемая
меткой тома’. К сожалению, путаница возникает довольно часто.
С диском связаны два файла: /dev/daO и /dev/rdaO. Это файлы блок-ори-
ентированного и байт-ориентированного устройства соответственно; они
адресуют весь диск. Имена, за которыми следуют буквы от ‘а’ до Ъ* (например.
/dev/daOa), задают BSD-разделы первой секции FreeBSD. Можно организовать
отдельный доступ к четырем секциям посредством файлов /dev/[r]da0s[l-4].
Имена устройств могут быть различными в зависимости от типа дискового
контроллера, поэтому, прежде чем форматировать диск, убедитесь в том, что
используется правильное имя устройства.
Как всегда, утилита редактирования секций (т.е физических разделов)
называется fdisk. Эта программе может быть запущена в автоматическом либо
интерактивном режиме. Не имея достаточного опыта добавления дисков,
лучше воспользоваться интерактивным режимом. Чтобы отредактировать
таблицу распределения текущей секции, необходимо задать флаг -е программы
fdisk, а для создания новой секции предназначен флаг -I:
« fdiak -1 d*0
При указании флага -i программа fdisk по умолчанию делает весь диск
секцией FreeBSD с номером 4. Поскольку' FreeBSD будет единственной
операционной системой, устанавливаемой на диск, мы примем стандартные
установки (этот процесс здесь не показан). Когда редактируется существую-
щая таблица разделов, программа предупреждает, если предлагаемые изме-
нения могут повредить другие операционные системы. Помните, что на диске
ничего не меняется до тех пор, пока программа fdisk не запишет на него
обновленную таблицу, поэтому всегда есть возможность начать сначала.
Создав новые секции, запустим снова программу fdisk. чтобы все
проверить:
t fdlak daO
•“•**’ Working on device /dev/rdaO
parameters extracted from in-core disklabel are:
cylinders=261 heads*=255 sectors/track-*63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=*261 heads-255 secters/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165,(FreeBSD/NetBSD/3e6BSD)
start 1, size 4192964 (2047 Meg), flag SO (active)
Обратим ваше внимание на то, что во FreeBSD используется терминология, противополож-
ная той, которая применяется в системе Solaris на Intel-платформах. В Solaris тома,
задаваемые меткой утилиты fdisk, называются разделами, а тома, задаваемые меткой Solaris,
называются секциями
176
Честь I Основы одминистрировония
beg: cyl 0/ sector 2/ head 0;
beg; cyl 260/ sector 63/ head 254
Теперь в нашу секцию можно записать метку. Метка BSD-диска (на
самом деле метка раздела) допускает наличие до 8-ми разделов с именами
от а до h. Раздел а обычно является корневым, раздел Ь используется для
подкачки, а раздел с содержит в себе всю секцию. Для создания метки
необходимо запустить программу disklabel с опцией -г или -w. Флаг -г
предписывает программе обратиться к диску напрямую, в обход драйвера
устройства, который наверняка неправильно определит метку, если это новый
диск. Опция -w требует дополнительных аргументов: имени дискового
устройства и типа диска (указаны в файле /etc/disktab). В большинстве случаев
тип диска можно обозначить как auto, что заставит программу disklabel
воспользоваться параметрами, выявляемыми системой в процессе автомати-
ческого обнаружения устройства. Например:
*	disklabel -г -w d*0 auto
Если автообнаружение не работает, придется вручную создать новую
запись в файле /etc/disktab.
Когда метка создана, ее можно отредактировать, выполнив команду
disklabel -е. Программа преобразует метку в текстовый формат, понятный
человеку, и запустит редактор vi. Информация, касающаяся раздела, приве-
дена в конце файла.
Если при создании метки диска не была указана запись в файле
/etc/disktab, то, вероятнее всего, будет создан единственный раздел, содер-
жащий всю секцию. Можно скопировать строку с описанием этого раздела
и использовать ее для задания других разделов. Необходимо будет соответ-
ственно изменить обозначающую раздел букву, размер в секторах, смешение,
тип файловой системы (4.2BSD или swap), а также размеры фрагментов и
блоков, используемые командой newfs.
Мы разбили диск на корневой раздел размером 1 Гбайт и раздел подкачки
такого же размера. Имя байт-ориентированного устройства /dev/rdaOc.
передаваемое программе diskiabeL обозначает секцию FreeBSD, которую
нужно сегментировать:
#	diaklabal -г -® /dev/rdaOc
type: SCSI
disk: SEAGATE
sectors/track: 63
tracks/cylinder: 255
cylinders: 261
sectors/unit; 4194995
#	size offset fstype [fsize bsize bps/cpg)
a:	2097153	0	4.2BSD	1024	0192	16
b:	2097841	2097154 swap
c:	4194995	0	4.2BSD	1024	8192	16
Файловые системы создаются командой newfs. Ей нужно задать имя
байт-ориентированного устройства для раздела, где формируется файловая
система.
I nawfe /dav/rdaOa
/dev/rdaOa:
2097152 sectors in 512 cylinders of 1 cracks, 4096 sectors
Глово 8. Добовление нового жесткого диско
177
1024.0MB in 32 cyl groups (16 c/g, 32.00MB/g, 7744 i/g)
super-block backups (for fsck -bi) at:
32, 65568, 131104, 196640, 262176, 327712, 393248,
458784, 524320, 589856, 655392, 720928, 786464, 852000,
После создания файловой системы проверим ее с помощью программы
feck. Ей также нужно указать имя байт-ориентированного устройства.
#	fsck /dsv/rdaOa
*	* /dev/rdaOa
*	* Last Mounted on /bkroot
*	’ Phase 1 - Check Blocks and Sizes
*	* Phase 2 - Check Pathnames
*	* Phase 3 - Check Connectivity
*	★ Phase 4 - Check Reference Counts
*	* Phase 5 - Check Cyl groups
1 files, 1 used, 1017070 free (14 frags, 127132 blocks, 0.0% fragmentation)
Команда swapon активизирует режим подкачки в соответствующем
разделе. Тип раздела должен быть указан в метке как swap. Команда swapinfo,
являющаяся аналогом команды pstat -s, сообщает об устройствах, которые в
данный момент используются для подкачки.
# swapon /dev/daOb
* swaplnfo
Device	IK-blocks Used Avail Capacity Type
/dev/wdOslb	70784	0	70656	0%	Interleaved
/dev/daOb	1048920	0	1048792	0%	Interleaved
Total	1119448	0	1119448	0%
Чтобы при загрузке новые разделы автоматически монтировались и
включался режим подкачки, нужно добавить следующие записи в файл
/etc/fstab:
# Device	Mountpoint	FStype	Options	Dump	Paas#
Zdev/daOa	/new	ufs	rw	2	2
/dev/daOb	none	swap	sw	0	0
Для проверки файла fstab следует демонтировать файловую систему и
выполнить команду mount -а, которая заново смонтирует все перечисленные
в списке файловые системы. Если команда завершилась успешно, перезагру-
зите компьютер и убедитесь, что все работает нормально.
178
Чость I. Основы одминистрироеания
ф Периодические процессы
Ключ к сохранению постоянного контроля нал системой — автоматиза-
ция максимально возможного числа задач. Например, сценарий adduser может
подключать новых пользователей быстрее, чем это сделает администратор
вручную, причем с гораздо мены пей вероятностью ошибки. Почти каждую
задачу можно запрограммировать в сценариях интерпретатора команд или
системы expect либо на языке Perl.
В некоторых случаях желательно, чтобы сценарий или команда выпол-
нялась без вмешательства оператора. Например, можно сделать так. чтобы
сценарий проверял (скажем, каждые полчаса), как работают сетевые маршру-
тизаторы и мосты, и при наличии проблем посылал администратору
сообщение по электронной почте’
9.1.	Демон cron: шпонирование команд
В UNIX периодическим выполнением процессов управляет демон cron
Он запускается во время начальной загрузки системы и остается в активном
состоянии до тех пор. пока система не будет выключена. Демон сгон читает
один или несколько файлов конфигурации, содержащих последовательности
командных строк и расписание их вызова. Командные строки обрабатываются
интерпретатором sh, поэтому почти все, что можно сделать в данном
интерпретаторе команд вручную, вы можете перепоручить демону сгоп ’.
Файлами конфигурации управляет команда crontab (сокращение от "стоп
table" — таблица демона сгоп), поэтому их называют crontab-фамлами. Все
они хранятся в едином системном каталоге, чтобы демон легко мог их найти
По запросам пользователей команда crontab добавляет и удаляет файлы в
этом каталоге.
Для любого пользователя создается не более одного crontab-файла.
В качестве имени файла используется регистрационное имя пользователя,
которому он принадлежит, и с помощью этого имени демон сгоп выясняет.
Многие организации идут еше дальше: в них модем может набирать номер пейджера, чтобы
администратора можно было вызвать даже тогда, когда он не имеет доступа к электронной
почте.
Некоторые версии демона сгоп допускают использование других интерпретаторов.
Глово 9. Периодические процессы
179
0
9.2.
какое значение UID нужно использовать прн выполнении команд, содержа-
щихся в файле.
Старые версии демона cron периодически просматривают свои crontab-
файлы и запускают все команды, которые должны были быть выполнены с
момента предыдущей проверки. Современные версии демона осуществляют
синтаксический анализ сгоп1аЬ-файлов. определяют, какую из перечисленных
команд нужно выполнить в ближайшую очередь, и переходят в состояние
ожидания до наступления требуемого срока.
В некоторых системах передача демону сгоп сигнала отбоя (HUP)
заставляет его повторно прочитать свои crontab-файлы. Как правило, нет
необходимости делать это вручную, так как команда crontab автоматически дает
демону указание перечитать файлы конфигурации при изменении одного из них.
Демон сгоп обычно выполняет свою работу “молча", но иногда может
вестись файл регистрации (как правило, это файл /var/cron/log или
/var/adm/cron/log), в котором отражаются все выполняемые команды и время
их запуска. В некоторых системах при создании файла регистрации автома-
тически включается режим регистрации, а при удалении этого файла
регистрация выключается. В других системах режим регистрации задается в
файле конфигурации. Кроме того, демон сгоп может пользоваться услугами
системы syslog. Файл регистрации быстро увеличивается в размерах и редко
приносит пользу; лучше не включать регистрацию вообще, если только вы
не занимаетесь устранением какой-то конкретной проблемы.
О системе syslog рассказывается в главе 11.
Если какая-либо команда не была запушена в нужное время (например,
из-за того, что система была выключена), то демон сгоп не выполняет такую
команду позже, поскольку информация о факте невыполнения не сохраня-
ется. Помимо этого, некоторые версии демона не понимают перехода на
летнее/зимнее время, что приводит к пропуску или двукратному выполнению
команд при переходе на другое время. К таким ситуациям следует быть
готовым. Проблем можно избежать, если не выполнять команды в "крити-
ческие’’ часы.
Формат crontab-файлов
Все crontab-файлы в системе имеют обший формат. Комментарии
начинаются со знака решетки (#) в первой позиции строки. Каждая строка,
не являющаяся комментарием, содержит шесть полей и представляет одн>
команду:
минуты часы день месяц деньнедели команда
Первые пять полей отделяются друг от друга пробелами, но в поле команда
пробел выполняет свою обычную роль разделителя аргументов.
В полях минуты, часы, день, месяц и день неде.ш дается информация о
времени запуска команды. Описание этих полей приведено в табл. 9.1.
Таблице 9 I Спецификации времени в crontob-файге
Поле	Описание	Диапазон
минуты	Минуты часа	от 0 до 59
часы	Часы дня	от 0 до 23
день	День месяца	от 1 до 31
месяц	Месяц года	от 1 до 12
день недели	День недели	от 0 до 6 (0 — воскресенье)
180
Чость I. Основы администрирования
Каждое из вышеуказанных полей может содержать:
•	звездочку, которая означает птабую цифру;
•	целое число, задающее отдельный элемент даты;
•	два разделенных дефисом целых числа, соответствующих диапазон)
значений.
•	целые числа или диапазоны, разделенные запятыми и соответствующие
любому из указанных значений.
Например, спецификация
45 10 ’ *	1-5
означает “10 часов 45 минут, с понедельника по пятницу".
С полями день недели и день сопряжена потенциальная двусмысленность,
которую необходимо учитывать. Каждым день является и днем недели, и
числом месяца. Если указаны оба этих поля, то подпадающему под их
действие дню достаточно удовлетворять одному из двух требований, чтобы
пройти отбор. Например, спецификация
О.ЗС -13-5
означает “каждые полчаса по пятницам и каждые полчаса тринадцатого числа
месяца", но не “каждые полчаса в пятницу тринадцатого числа".
Поле команда содержит командную строку, подлежащую выполнению
интерпретатором sh. Это может быть любая допустимая команда интерпре-
татора, причем без кавычек. Считается, что поле команда продолжается до
конца строки и может содержать пробелы и символы табуляции. Принадле-
жащий суперпользователю crontab-файл может включать команды, выполняе-
мые от имени произвольного пользователя. Они предваряются строкой /bin/su
имяуюлъзователя -с.
Более подробные сведения о команде su находятся в параграфе 3.4.
Большинство версий демона сгои допускают использование знака про-
цента (%) вместо символа новой строки в поле команда В реальную команду
включается только текст до первого знака процента: остальные строки
передаются команде в качестве стандартного входного потока.
Вот некоторые примеры допустимых команд в crontab-файле:
echo The time is now 'aate‘ > 7dev/console
write garth % Hi Garth. % Remember to get a job.
cd /ets; /bin/maii -s "Passwords file*’ evi < passwa
А вот полные примеры записи:
30 2	*	’	1 (cd /users/joe/project; make)
Эта строка будет активизироваться в 2130 по понедельникам. Она
инициирует выполнение команды make в каталоге /users/joe/project. Ее можно
использовать для запуска продолжительной компиляции на время, пока в
системе нс работают другие пользователи. Вся выходная информация команды
cron обычно посылается по электронной почте “владельцу" команды’.
20 I	find /стр -atime ^3 -exec rm -f {l
To есть пользователю, именем которого назван файл. Фактическим владельцем сгопtab-
файлов обычно является пользователь root
Глово 9 Периодические процессы
181
Данная команда будет выполняться каждый день в 1:20. Она удаляет из
каталога /tmp все файлы, к которым за последние 72 часа пользователи ни
разу не обратились.
55 23 *	*	0’3,6 /staff/trent/hin/acct-script
А эта строка запускает команду acct -script в 23:55 каждый день, кроме
четверга и пятницы.
9.3.	Изменение crontaj-фийлов
Команда crontab имяфайла инсталлирует в качестве crontab-файла
указанный файл. Команда crontab -е проверяет копию crontab-файла вызвав-
шего ее пользователя, запускает для нее текстовый редактор (указанный в
переменной среды EDITOR), а затем повторно записывает файл в системный
каталог. Команда crontab -I отображает содержимое сгопtab-файла, а команда
cron tab -г удаляет этот файл.
Большинство систем позволяют пользователю root задавать аргумент
имя пользователя, чтобы можно было просматривать и редактировать сгоп-
tab-файлы других пользователей. Например, команда crontab -г jsmith удаляет
crontab-файл. принадлежащий пользователю jsmith. В Red Нас и FreeBSD, где
в одной команде можно задавать как имя пользователя, так и имя файла,
необходимо перед именем пользователя ставить опцию -и (например,
crontab -u jsmith crontab.new).
Не получив аргументов, команда crontab попытается прочитать crontab-
файл из своего стандартного входного потока. Если этот режим был
активизирован случайно, не пытайтесь выйти из него, нажимая клавиши
<Ctrl-D>, так как весь crontab-файл будет уничтожен. Используйте для этого
комбинацию клавиш <Ctri-C>.
По умолчанию все пользователи имеют право создавать crontab-файлы.
Чтобы исправить подобную ситуацию, системный администратор может
создать два специальных файла: cron.allow и сгоп.deny. Отыскать эти файлы
довольно трудно. Прежде всего проверьте каталоги /etc/cron.d, /usr/lib
usr/lib/cron и /var/spool/cron. Во FreeBSD файлы находятся в каталоге
/var/сгоп и называются просто allow и deny. В табл. 9.2 указано размещение
файлов, связанных с демоном сгоп, в четырех тестовых системах.
Если существует файл cron.allow, то он содержит список пользователей,
имеющих доступ к демону сгоп (по одному имени в строке). Тот, кто в списке
отсутствует, выполнять команду crontab не имеет права. Если файла cron.allow
нет, проверяется файл cron.deny. Как и файл cron.allow. он содержит список
пользователей, но с противоположным назначением: доступ разрешен всем,
кроме указанных в списке. Если нет ни одного из двух файлов, только
пользователь root имеет право создавать crontab-файлы.
Важно понимать, что права доступа регулируются командой cron tab, а не
демоном сгоп. Если пользователь найдет способ обходным путем поместить
в системный каталог свой crontab-файл, демон сгоп будет благополучно
выполнять указанные в нем команды.
9.4.	Применение демона сгоп
Существует целый ряд стандартных задач, для решения которых, собст-
венно, и предназначен демон сгоп Соответственно, большинство записей
crontab-файла пользователя root служат именно стандартным целям. В данном
параграфе мы рассмотрим подобные задачи и элементы crontab-файла
обеспечивающие их реализацию
182
Чосгь I. Основы одминистрировсния
UNIX-системы часто поставляются с несколькими уже инсталлирован-
ными элементами crontab-файла. Если необходимо отключить эти элементы,
превратите их в комментарии, вставив в начало каждой строки знак решетки.
Не удаляйте такие строки: возможно, они еше пригодятся.
Чистка файловой системы
В любой UNIX-системе имеются файлы, в которых нет никакой
надобности. Например, при аварийном завершении программы ядро создает
файл дампа, содержащий образ адресного пространства программы. Раньше
этот файл назывался core, но некоторые современные системы включают в
имя файла название программы или идентификатор процесса (например,
netscape.core или соге.7288)* Такие файлы полезны для разработчиков
программного обеспечения, но для администраторов это бесполезная трата
драгоценного пространства на диске. Пользователи часто вообще не знают о
назначении файлов дампа, поэтому предпочитают не брать на себя ответст-
венность за их удаление
Еше один источник лишних файлов — NFS, сетевая файловая система.
На серверах NFS применяется специальное обозначение для зашиты файлов,
которые локально уничтожены, но продолжают использоваться удвленной
машиной. В большинстве реализаций таким файлам присваиваются имена
.nfsxxx, где Ахх — числовое значение. Случается так. что об этих файлах
забывают и оставляют их на диске, думая, что они удалены.
NFS рассматривается в главе 17
Многие программы создают в каталоге /tmp или /var/trop временные
файлы, которые по той или иной причине не удаляются. Некоторые
программы, особенно текстовые редакторы, имеют привычку создавать
резервные копии каждого файла, с которым они работают.
Частичное решение проблемы файлового “мусора” состоит в том, чтобы
установить некую процедуру регулярного восстановления свободного диско-
вого пространства, запуская ее (допустим, каждую ночь) с помощью демона
сгоп. В современных системах обычно имеются встроенные средства подобной
очистки, поэтому необходимо убедиться, что они соответствуют потребностям
организации. Во всех приведенных ниже примерах для удаления ненужных
файлов используется команда find.
find / -xdev -name core -atime +7 -exec rm -f [} ';'
Эта команда удаляет файлы с именем core, которые не использовались
в течение недели. Аргумент -xdev гарантирует, что команда find будет
выполнена только в корневой файловой системе и в другие файловые системы
не перейдет, что очень важно в сетях, где возможно монтирование множества
файловых систем с помощью NFS**. Если необходимо очистить несколько
файловых систем, используйте для каждой из них отдельную команду
(помните, что каталог /var часто является отдельной файловой системой),
find / -xdev -acime +3 '(' -name '#*’ -о -name ' -о -nanie ’*.CKP’ -о \
-паше ’*- -о -name '.nfs*' *J* -ехес rm -f {}
Слово “core” (сердечник) — синоним термина “memory” (память) Этот термин родился в
ранних вычислительных системах, где в качестве запоминающих элементов использовались
маленькие ферритовые кольца, закрепленные на пересечениях проводников.
Аргумент -xdev поддерживают не все версии программы find. В некоторых системах он
называется -х.
Глово 9. Периодические процессы
183
Е
Эта команда удаляет не использовавшиеся в течение трех дней файлы,
имена которых начинаются с префикса «. . F или .r.fs либо заканчиваются
символами .СКР. Часто это временные файлы и резервные файлы различных
текстовых редакторов.
find /var/preserve -jntrrue .4 -exec rir. -f { . ’
Такая команда уничтожает файлы в каталоге /var/preserve через две недели
после их последней модификации. Редактор vi использует этот каталог для
хранения копий файлов, которые редактировались пользователями в момент
краха системы. Такие файлы сохраняются и никогда не удаляются, если
только их не удалят владельцы с помощью команды vi -г имяфаит
cd /trap; find . 1 -name lost+found -type d -mtime +3 \
-exec /binZrm -rf i
Приведенная выше команда рекурсивно удаляет все подкаталоги каталога
/trap, не модифицировавшиеся в течение 72 часов. Обычные файлы в каталоге
/tmp удаляются стартовыми сценариями во время начальной загрузки, но
некоторые системы не выполняют операцию удаления каталогов. Если
существует каталог под именем lest+found. то он не включается в число
удаляемых. Это важно, если каталог /tmp — отдельная файловая система.
Каталог lost+found был описан в параграфе 8 4
Если в системе применяется какая-либо из этих команд, пользователи
должны знать, какими принципами руководствуется администратор при
чистке файловой системы
Распространение конфигурационных файлов по сети
При администрировании компьютерной сети во многих случаях удобно
пользоваться единой версией файлов конфигурации, например базой данных
о псевдонимах пользователей электронной почты (/usr/lib/aiiases или /etc/aii-
ases). Основные версии этих файлов можно распространять ежедневно с
помошью программы rdist или сценария на языке expect.
Подробнее о распространении конфигурационных файлов по сети вы узнаете,
прочитав главу 18.
Иногда необходима последующая обработка файлов. Например, во многих
системах требуется, чтобы пользователь выполнял программу newaliases для
преобразования текстового фаЙта почтовых псевдонимов в хешированный
формат, используемый программой sendmail. Может понадобиться и <агрузка
файлов в административную базу данных, такую как NIS или NIS+.
Циклическое использовоние журнальных файлов
Журнальные файлы в UNIX увеличиваются бесконечно до тех пор. пока
пользователь вручную не очистит их Есть различные способы разрешения
этой проблемы. Самый простой из них — периодически усекать файлы.
Более консервативный подход заключается в хранении нескольких старых
версий журнального файла и циклическом их использовании по-новому. Это
предотвращает бесконтрольное разрастание файлов и в то же время позволяет
постоянно держать под рукой информацию о последних изменениях. Такую
процедуру лучше всего планировать с помощью демона сгоп. Подробнее об
этом процессе рассказывается в параграфе 111.
184
Честь I Основы едминистрировония
9.5.	Особенности периодических процессов
в различных системах
Местоположение различных файлов и каталогов, связанных с демоном
сгоп, подытожено в табл. 9.2.
Таблица 9.2. Файлы и котологи демоно стоп в розничных системах
Система	Каталог crontab-файлов	Католаг файлов allow и deny	Журнальный файл
Solaris	/va г/spool/cron/crontabs	/etc/croird	/var/cron/log
HP-UX	/var/spool/cron/crootabs	/usr/lib/сгоп	/var/adm/cron/log
Red Hat	/var/spool/cron	/etc	/var/log/cron
FreeBSD	/var/cron/tabs	/var/cron	Используется система syslog1
По умолчанию сообщения демона сгоп направляются в каталоги /var/cron/log.*.
ф
&
Чтобы включить журнальный режим в Solaris, отредактируйте файл
/etc/default/cron. создав в нем запись CFONLOG=YES. В этом файле можно
также задать значение переменной среды PATH, передаваемой выполняемым
командам.
В Red Hat и FreeBSD используется написанным Полом Викси (Pau) Vixie)
демон Vixic-cron. Этот демон является свободно доступной реализацией
демона сгоп и имеет ряд улучшений. Например, он позволяет задавать в
crontab-файлах значения переменных среды.
Другим удобным усовершенствованием демона Vixic-cron является воз-
можность указывать шаг приращения в спецификациях времени в cronlab-
файлах. Например, последовательность 0,3,6,9,12,15,18,21 может быть
записана гораздо компактнее: 0-21/3.
Глово 9 Периодические процессы
185
J Q Резервное копирование
В большинстве случаев информация, хранящаяся в компьютерах, стоит
дороже самих компьютеров. Кроме того, ее гораздо труднее восстановить.
Зашита этой информации — одна из наиболее важных (и, к несчастью, самых
трудоемких) задач системного администратора.
Существуют сотни различных причин, которые вызывают потерю важных
данных. Ошибки в программном обеспечении постоянно приводят к порче
файлов. Пользователи случайно удаляют то, над чем работали всю жизнь.
Хакеры и обозленные служащие стирают целые диски. Проблемы в аппарат-
ных средствах и стихийные бедствия выводят из строя целые машинные залы.
Поэтому ни одну систему нельзя эксплуатировать без резервных копий.
При правильном подходе создание резервных копий данных позволяет
администратору восстанавливать файловую систему (или любую ее часть) в
том состоянии, в котором она находилась на момент последнего снятия
копий. Резервное копирование должно производиться тщательно и строго по
графику. Кроме того, устройства резервирования и сами носители следует
регулярно проверять на предмет корректной работы.
Безопасность резервных леит является важным элементом корпоративном
стратегии. Ответственные руководящие сотрудники должны четко понимать,
какой цели служат резервные архивы и как они должны эксплуатироваться.
Для какого-нибудь компьютерного класса в университете не так страшно
потерять результаты работы за один день, как для торговой компании,
регулярно принимающей заказы от десятков млн сотен клиентов.
Мы начнем эту главу с описания обшей методики резервного копирова-
ния. после чего познакомимся с наиболее распространенными устройствами
создания резервных копий и собственно резервными носителями (их
преимуществами, недостатками и ценой). Затем рассмотрим стандартные
команды резервирования и архивирования в UNIX, а также расскажем о том,
186
Чость I Основы одминистрировония
10 1
в каких ситуациях лучше та или иная команда. Далее речь пойдет о
планировании процедуры резервною копировать в сочетании с анализом
особенностей работы UN IX-команд dump и restore. В завершение главы мы
познакомимся с бесплатным сетевым пакетом резервного копирования
Amanda и несколькими его коммерческими альтернативами.
Принципы резервного копирования
Прежде чем рассматривать детали резервного копирования, мы хотели
бы поделиться с читателями тем. чему научились за годы практической работы
(иногда эти знания давались нам очень тяжело) Ни один из предлагаемых
сонетов не является абсолютным, но чем чаше вы будете им следовать, тем
спокойнее будет проходить процесс резервного копирования.
Создавайте резервные копии но одной машине
Программа rdump позволяет создавать резервные копии систем по сети.
Производительность несколько ухудшается, но это компенсируется легкостью
администрирования. Мы обнаружили. что лучше всего запустить на централь-
ном компьютере сценарий, который выполняет программу rdump (посредством
интерпретатора rsh или ssh) на каждой машине, где необходимо проводить
резервное копирование. Можно также воспользоваться программным пакетом
(коммерческим или бесплатным), автоматизирующим данный процесс. Все
архивы должны помешаться на одну’ ленту (без перемотки, естественно)
Если сеть очень велика и одной магнитной ленты явно недостаточно,
все равно следует пытаться сделать систему резервного копирования как
можно более централизовашчой Централизованное управление облегчает
администрирование и позволяет администратору проверять правильность
выполнения резервного копирования на всех машинах. Часто на сервер можно
поставить несколько ленточных накопителей, и это не повлияет на произ-
водительность. Но учитывая, что современные ленточные устройства обладают
высокой производительностью (6 Мбит/с и выше), это вряд ли имеет смысл
Архивы, созданные программой rdump, можно восстанавливать только на
машинах с аналогичным порядком следования байтов (и в большинстве
случаев — на машинах. работающих под управлением той же самой ОС)
Иногда проблему можно решить посредством побайтового копирования в
режиме перестановки байтов с помощью команды dd, но это не помогает
устранить различия между несовместимыми версиями программы rdump
Маркируйте ленты
Не забывайте четко и полно маркировать каждую резервную ленту. Лепты
следует помечать так. чтобы можно было однозначно определить их
содержимое. Советуем на коробке написать подробную информацию (напри-
мер, список файловых систем и даты создания архивов). Немаркированная
лента — рабочая
Важно, чтобы корневую файловую систему и файловую систему /usr
можно было восстановить, не заглядывая в сценарии архивов. Резервные
ленты для этих файловых систем необходимо маркировать с указанием
формата, точного синтаксиса использованной команды dump и других
сведений, требуемых для восстановления архива без обращения к докумен-
тации.
Глово 10. Резервное копировоние
187
Существуют бесплатные и коммерческие программы создания этикеток
для лент. Советуем приобрести одну из них, чтобы избавиться от головной
боли Для тех, кто любит экономить, подойдет программа trofT.
Правильно выбирайте периодичность резервного копирования
Чем чаше выполняется резервное копирование, тем меньше данных будет
потеряно в случае краха системы. Процесс резервного копирования, однако,
сопровождается расходованием ресурсов системы и операторского времени.
Системный администратор должен обеспечить адекватную защиту при
разумном уровне затрат времени и средств.
В интенсивно эксплуатируемых системах наиболее приемлемый ва-
риант — делать резервные копии файловых систем с начальными каталогами
пользователей каждый рабочий день В системах, которые используются менее
интенсивно или в которых данные изменяются ие столь часто, можно снимать
копии несколько раз в неделю. В малой системе с одним пользователем
достаточно делать копию раз в неделю. В конце концов, периодичность
определяется объемом данных, которые могут быть утеряны с момента
последнего создания резервных копий.
Тщательно выбирайте архивируемые файловые системы
Файловые системы, которые изменяются редко, не нужно архивировать
столь же часто, как начальные каталоги пользователей. Если в какой-либо
файловой системе регулярно изменяется лишь несколько файлов (например,
файл /etc/passwd), их можно каждый день копировать в другой раздел,
резервные копии которого создаются более часто.
Буферный каталог Usenet иа сервере новостей — это хороший пример
файловой системы, которая не должна резервироваться; не тратьте на нее
время и ленту. Новости — постоянно меняющаяся среда и ее состояние
невозможно восстановить.
Если каталог /tmp является отдельной файловой системой, то архивиро-
вать ее не нужно. Каталог /tmp не должен содержать ничего существенного,
поэтому нет никаких причин сохранять его. Впрочем, мы знаем одну большую
фирму, которая ежедневно резервирует данный каталог
Старайтесь умещать каждодневные архивы на одной ленте
В идеальном мире можно создавать каждодневные резервные копии всех
пользовательских файловых систем на одной единственной ленте. При
наличии устройств большой емкости, таких как накопители DI Т и А1Т, эта
цель становится реально достижимой в некоторых организациях. Вы можете
монтировать ленту вечером, перед уходом с работы, и автоматически запускать
резервное копирование поздно ночью с помошыо демона сгоп. Такая схема
позволяет создавать архив в тот момент, когда изменение файлов маловеро-
ятно и пользователей, скорее всего, нет в системе.
Информация о демоне сгоп приведена в главе 10.
К сожалению, реалии становятся все более суровыми. Когда пользователи
могут приобрести жесткий диск емкостью 40 Гбайт по цене 240S, не остается
финансовых барьеров для наращивания дискового пространства. Зачем
чистить лиски и устанавливать квоты., если можно вложить немного денег
для безболезненного решения проблемы.
8а
Чость I Основы одминмстрировония
В случае, когда ежедневные архивы невозможно разместить на одной
ленте, воспользуйтесь следующими решениями:
•	приобретите ленточное устройство более высокой емкости;
•	купите укладчик или ленточную библиотеку, чтобы можно было вставлять
несколько носителей в одно устройство;
•	измените периодичность создания резервных копий;
•	напишите более сложный сценарий архивирования;
•	используйте несколько устройств резервирования.
Система автоматического резервного копирования должна регистрировать
имена всех копируемых файловых систем. Это позволяет быстро находить
нужную файловую систему, когда приходится что-либо восстанавливать.
Рекомендуем также записывать на коробке или на самой ленте порядок
следования файловых систем. (Об этом уже говорилось раньше, но лучше
повторить: для лент, на которые записывается несколько архивов, необходимо
использовать устройство без перемотки.)
Создавайте файловые системы, объем которых меньше
емкости резервного носителя
Команда dump может прекрасно копировать файловые системы на
несколько лент. В этом случае, однако, должен присутствовать оператор,
меняющий ленты’, а ленты необходимо аккуратно маркировать, чтобы при
восстановлении информации не возникало никаких затруднений Если нет
реальных причин создавать большую файловую систему, не делайте этого.
Хроните ленты не в рабочем помещении
В большинстве организаций архивы хранят вне рабочего помещения,
чтобы избежать их порчи в случае пожара или стихийного бедствия. Фраза
’вне рабочего помещения’’ означает как сейф в банке, так и полку в доме
у президента компании. Фирмы, специализирующиеся на безопасном хране-
нии резервных носителей, обеспечивают для них надлежащий температурный
режим и гарантируют их сохранность.
Выбор внешнего хранилища определяется тем, как часто нужно восста-
навливать файлы и какие потери времени допустимы. В некоторых органи-
зациях выполняется по два резервных копирования в день на разные ленты:
одна остается в рабочем помещении, а вторую сразу же выносят’
Защищайте резервные копии
Дэн Гир (Dan Geer), специалист по вопросам безопасности, сказал: “Что
делает резервная копия? Гарантированно нарушает права доступа к файлу на
расстоянии” Ни больше, нм меньше!
Защищайте свои резервные ленты. Они содержат все данные, имеющиеся
в системе, и могут быть прочитаны любым, кто имеет физический доступ к
ленте. Ленты нужно хранить нс просто вне помещения, но также под замком
При условии, что ие используется укладчик, магазин или ленточная библиотека.
В одном крупном финансовом учреждении, расположенном во Всемирном центре торговли,
резервные носители хранились “вне рабочего помещения" — на один или два этажа ниже.
Во время взрыва бомбы резервные ленты (и компьютеры) были уничтожены. Так что
внешнее хранилище должно быть действительно “внешним”.
Ггово 10 Резервное копировоние
189
с надежно спрятанным ключом. Если вы пользуетесь для этой цели услугами
коммерческой компании, она должна гарантировать конфиденциальность лент.
Некоторые компании настолько заботятся о сохранности резервных лент,
что даже делают их копии.
Активность файловой системы во время создания архива
должна быть низкой
Снятие резервных копий лучше проводить в периоды низкой активности
системы, потому что изменения могут привести к ошибкам в работе команды
dump. Таким образом, можно создавать архивы, когда в системе работает
мало пользователей, или же в определенное время предоставлять доступ к
системе только команде dump
Звучит это, конечно, хорошо, ио на практике реализуется редко.
Пользователям нужен круглосуточный доступ к системе. В наши дни почти
невозможно добиться отсутствия дисковой активности при создании ре-
зервных копий.
Существуют менеджеры файлов (в частности, серия F700 компании
Network Appliance), которые позволяют в оперативном режиме создавать
снимки файловой системы через определенные, настраиваемые промежутки
времени. Это дает возможность безопасно получать резервные копии
работающей системы и является веским доводом в пользу специализирован-
ных файловых менеджеров.
О менеджерах файлов рассказывается в параграфе 17.5.
Проверяйте свои ленты
Известно много ужасных историй о системных администраторах, которые
не замечали проблем в выбранном ими режиме создания архивов до тех пор.
пока в системе не происходил серьезный сбой Важной задачей администра-
тора является непрерывный контроль нал соблюдением установленного
порядка резервного копирования и проверка качества его выполнения.
Ошибка со стороны оператора приводит к гибели большего объема архивов,
чем любая другая
Первый этап — заставить программу резервного копирования попытаться
после окончания своей работы перечитать все ленты. Хороший вариант
проверки — просмотр ленты на предмет наличия ожидаемого количества файлов.
Во многих случаях бывает полезно выполнить команду restore t, которая
формирует список файлов каждой файловой системы, и записать результаты
на диск. Полученные справочники нужно называть так, чтобы их имена
отражали связь с соответствующими лентами, например host:usr.Jan.13.
Недельный набор таких справочников помогает быстро определить, на какой
ленте находится пропавшим файл. Для этого следует запустить программу
grep с именем файла в качестве аргумента и выбрать самый последний его
экземпляр.
Подробнее о команде restore си. в параграфе 10.4.
Помимо создания каталога лент успешно выполненная команда restore [
показывает, что архив создан нормально и что можно в случае необходимости
прочитать ленту. Не помешает также прочитать произвольный файл, чтобы
укрепить свою уверенность*.
Команда restore t читает каталог архива, расположенного в начале ленты. Когда восстанав-
ливается конкретный файл, проверяется более крупная область носителя
190
Чость I. Основы одминистрировония
Периодически нужно пытаться восстанавливать информацию с разных
лент, чтобы проверить, возможно ли это вообще. Попробуйте прочитать
файлы со старых резервных лент (месячной и даже годичной давности), ведь
у накопителей временами нарушается центровка и они утрачивают способ-
ность читать ими же записанные ленты.
Еще один вид проверки — попытаться прочитать ленту на других
аппаратных средствах. Если машинный зал сгорит, пользы от осознания того,
что резервную копию можно было бы прочитать на расплавившемся
накопителе, будет мало.
Будет поучительно узнать одну историю, бывшую на слуху несколько лет
назад.
В одной крупной исследовательской компании работал оператор, который
был слишком занят хакерством, чтобы создавать резервные копии Он
открывал ленты, маркировал и\ и складывал иа полку, не записывая никаких
файлов. Это продолжалось в течение двух-трех месяцев, пока кто-то не
настоял на восстановлении одного из файлов. Что случилось с оператором?
Его уволили? Нет, его перевели в другой отдел, но впоследствии арестовали
и осудили за компьютерное мошенничество по совершенно другому делу По
слухам, ему дали 40 лет.
Определите жизненный цикл ленты
Время жизни лент ограничено. Их можно и нужно использовать повторно,
ио не забывайте о предельном сроке эксплуатации, определяемом произво-
дителем. Как правило, этот срок задается в виде количества проходов, которое
может выдержать лента. Каждая такая операция, как архивирование, восста-
новление и команда mt fsf (последовательный обход файлов), представляет
собой один проход.
Компонуйте данные с учетом резервного копирования
Когда есть столь дешевые и надежные дисковые устройства, возникает
искушение вообше отказаться от резервного копирования. 1см более, многие
системы имеют беспорядочную структуру и заполняются совершенно бескон-
трольно, поэтому их архивирование затруднено. Но если разумно подойти к
проектированию архитектуры дискового хранения, то можно существенно
упростить процесс резервного копирования. Начать необходимо с определе-
ния дисковых потребностей:
•	С какими типами данных придется иметь дело?
•	Как часто будут изменяться данные различных типов?
•	Как часто нужно выполнять резервное копирование, чтобы возможные
потери причиняли минимальный ущерб?
•	Какие административные границы должны быть определены между
данными?
Используя эту информацию, следует построить дисковую архитектуру с
учетом резервного копирования и возможного расширения системы в
будущем. Лучше размещать каталоги проектов и начальные каталоги пользо-
вателей на выделенных файловых серверах, что упростит управление данными
и позволит гарантировать их безопасность.
Глово 10. Резервное копировоние
191
Будьть готовы к худшему
После разработки методики резервного копирования изучите самый
худший сценарий: фирма полностью уничтожена. Определите, сколько
информации будет потеряно и сколько времени уйдет на восстановление
системы (включая время на приобретение нового оборудования) Затем
посмотрите, удовлетворяют ли вас полученные ответы.
102. Устройстга и носители, используемые
для резервного копирования
Поскольку многие виды неисправностей могут одновременно выводить
из строя сразу несколько аппаратных средств, резервные копии следует
записывать на съемные носители. Например, копирование содержимого
одного диска на другой, конечно, лучше чем ничего, но оно обеспечивает
весьма незначительный уровень защиты от отказа контроллера. В большинстве
организаций резервные копии хранятся вне машинного зала, чтобы какое-
нибудь бедствие вроде пожара не уничтожило и оригиналы, и копни.
Появились даже компании, организующие резервное копирование через
Internet.
Во многих видах носителей для записи данных используется эффект
намагничивания. Такие носители подвержены разрушительному воздействию
электрических и магнитных полей. Сейчас мы расскажем о некоторых
опасностях, которых следует избегать.
•	В звуковых колонках стоят большие электромагниты, поэтому никогда
ие храните ленты рядом с ними. Даже маленькие динамики, рассчитанные
иа кохтьютерные аудиосистемы, могут быть опасными.
•	Трансформаторы и источники бесперебойного питания генерируют элек-
тромагнитные поля. Трансформаторы обычно устанавливают в настенных
распределительных щитах.
•	В жестких дисках и накопителях на магнитной ленте имеются электро-
двигатели и магнитные головки, а корпуса этих устройств часто не
обладают экранирующим эффектом. Более безопасны накопители, вы-
полненные в металлических корпусах.
•	В мониторах используются трансформаторы и высокие напряжения.
Многие мониторы сохраняют электрический заряд даже будучи выклю-
ченными. Наихудший вариант в этом плане — цветные мониторы.
Никогда не кладите ленты на мониторы.
•	Длительное воздействие фонового излучения Земли очень вредно для
данных, записанных на магнитных носителях, и ограничивает срок
службы последних. По прошествии нескольких лет все ленты становятся
нечитаемыми. Большинство носителей выдерживает три года, и если
необходимо хранить данные дольше, то нужно либо воспользоваться
оптическими носителями, либо перезаписать данные.
Ниже описываются некоторые виды носителей, которые можно исполь-
зовать для хранения резервных копий. Они перечислены в порядке возрас-
тания емкости
Многие ленточные накопители сжимают информацию перед записью ее
на ленту, благодаря этому появляется возможность записать больше данных,
чем определено номинальной емкостью носителя. Производители любят
указывать емкость, отталкиваясь от объема сжатых данных, оптимистично

Чостъ I. Основы одминистрировония
предполагая коэффициент сжатия 2:1 или выше. Ниже мы будем приводить
реальное число байтов, которое физически можно записать на тот или иной
носитель.
Предполагаемый коэффициент сжатия влияет на пропускную способность
устройства. Если накопитель позволяет записывать данные иа ленту со
скоростью 1 Мбит/с, а производитель, к тому же, заявляет о коэффициенте
2:1, то пропускная способность волшебным образом возрастает до 2 Мбит/с.
Как и в случае емкости, мы проигнорируем “заявленную" скорость записи
и будем упоминать реальную.
Цена и емкость — это важнейшие характеристики носителя. но нельзя
не учитывать и пропускную способность. С более быстрыми устройствами
удобнее работать, и они позволяет эффективнее составлять график резервного
копирования.
Гибкие диски
Запись на гибкие диски — самый неудобный способ создания резервных
копий. Оим работают медленно и отличаются небольшой емкостью (в
настоящее время до 2.8 Мбайт). Кроме того, по удельной стоимости одного
мегабайта они дороже других носителей. Гибкие диски служат всего пару
лет; никогда не пользуйтесь ими для длительного хранения. С другой стороны,
дисководы гибких дисков недороги и часто поставляются вместе с системой.
Гибкие диски повышенной емкости
Zip-дисководы фирмы Iomega (www.iomega.com) сейчас распространены
повсеместно и в некоторых домашних компьютерах являются стандартным
внешним носителем. Их емкость за последнее время увеличилась со
100 Мбайт до 250 Мбайт. Эти устройства могут иметь следующие интерфей-
сы. последовательный, параллельный, SCSI и USB.
Компания I mation предлагает устройство Super Disk, которое позволяет
осуществлять запись как на стандартные гибкие диски, так и на специальные
носители емкостью 120 Мбайт.
Хотя подобного рода устройства используются достаточно широко,
соответствующие носители имеют относительно высокую стоимость при не
самой большой емкости, поэтому ие очень практично применять их для
резервного копирования.
Компакт-диски формата CD-R и CD-RW
Недавнее падение иен на записываемые и перезаписываемые компакт-
диски сделало эти носители гораздо более привлекательными кандидатами
для резервного копирования, чем несколько лет назад. Компакт-диски обоих
типов содержат около 650 Мбайт. Дисководы пишущего типа бывают самыми
разнообразными и имеют те же интерфейсы, что и жесткие диски: SCSI,
IDE, USB и др.
Запись на компакт-диск осуществляется фотохимическим способом
посредством лазерного луча. Хотя достоверных данных нет. считается. что
компакт-диски гораздо более долговечны, чем магнитные носители. Компакт-
диски с однократной записью (формат CD-R) не столь надежны, как обычные
компакт-диски. Они ие очень подходят для регулярного создания резервных
копий, но на них можно записывать архивы, которые потребуются в далеком
будущем.
Глово 10. Резервное копировоние
193
Технология записи DVD-дисков еше не получила широкого распростра-
нения, но следует ожидать всплеск се популярности в ближайшие несколько
лет. Емкость DVD-дисков составит примерно 10 Гбайт.
Съемные жесткие диски
За последние несколько лет на рынке появились съемные жесткие лиски
большой емкости. Компания Castlewood Industries (www.castlewood.com)
предлагает накопитель Orb емкостью 2,2 Гбайт. Он может иметь интерфейс
EIDE, USB или Ultra SCSI (внешний и внутренний).
Другим популярным устройством является дисковод Jaz компании Iomega,
который принимает носители емкостью 2 Гбайт и обеспечивает скорость
передачи данных 8,7 Мбайт/с. По заявлению производителя, срок жизни
такого носителя составляет 10 лет, тогда как дня устройства Orb эта цифра
более реалистична: 5 лет.
На рынке съемных устройств царит серьезная конкуренция и цены
постоянно меняются. Основное преимущество этих устройств — скорость,
сравнимая со скоростью обычных жестких дисков. Они хорошо подходят для
резервного копирования в небольших организациях или домашних условиях,
хотя цена устройств относительно высока.
8~миллиметровые кассетные ленты
Существует несколько моделей ленточных накопителей, которые записы-
вают информацию на стандартные 8-миллиметровые (малоформатные, ви-
деоленты. Эти накопители часто называют устройствами Exabyte, по названию
компании, которая первой стала их выпускать. Первоначальный формат
обеспечивал емкость около 2 Гбайт, а более новый формат позволяет достичь
емкости 7 Гбайт. За счет аппаратного сжатия данных эффективная емкость
ленты в некоторых накопителях еше выше.
Размер лент (8 мм) делает их очень удобными для внешнего хранения
Раньше возникали проблемы с лентопротяжными механизмами, так как
каждые 6—12 месяцев у них нарушалась центровка и приходилось отдавать
их в дорогостоящий ремонт. Сегодня таких проблем больше нет.
Ленты формата 8 мм могут использоваться для хранения видеофильмов
или цифровьсх данных. Некоторые производители рекомендуют использовать
только ленты второго типа и ие предоставляют гарантии на другие ленты
Наш опыт показывает, что видеокассеты тоже вполне подходят и проблемы
могут возникать только в отношении гарантий. Необходимо помнить, что
ленты обоих типов подвержены тепловому воздействию.
^миллиметровые цифровые аудиокассеты
Накопители DAT (Digital Audio Таре — цифровая аудиокассета) — это
устройства, в которых запись данных осуществляется на 4-миллиметровые
кассеты по методике спиральной развертки. На самом деле DAT-устройства
относятся к стандарту DDS (Digital Data Storage — хранилище цифровых
данных), однако это различие несущественно. Исходный формат обеспечивал
емкость около 2 Гбайт, но в следующих версиях стандарта DDS емкость
существенно возросла Современное поколение носителей (DDS-4) имеет
емкость до 20 Гбайт.
DAT-устройства характеризуются малым временем поиска и высокой
скоростью передачи данных (2,5 Мбайт/с для DDS-4), что делает их

Чость I Основы одминистрировония
достаточно быстродействующими. А благодаря высокой емкости носителей
появляется возможность реализовать полный цикл резервного копирования
без вмешательства оператора. Ленты формата 4 мм имеют небольшие
размеры, и их удобно хранить. К тому же, у DA1 -устройств никогда не было
проблем с центровкой лентопротяжного механизма.
Технология Travan
Стоит упомянуть о следующем поколении QIC-лент (Quarter-Inch Car-
tridge — четырехдюймовый картридж) — технологии Travan. В накопителях
Travan используется методика поспедовательной записи н поддерживаются
носители емкостью от 2,5 до 10 Гбайт. Сами накопители недороги, однако
иена лент относительно высока в сравнении с другими ленточными системами
большой емкости (3$/Гбайт). По заявлениям производителей, скорость
передачи данных может достигать 2 Мбайт/с.
В UNIX еше не в полной мере реализована поддержка накопителей
Travan В настоящее время существуют драйверы для устройств компаний
Hewlett-Packard, Tandberg и Tecmar.
Система OnStream ADR
Система ADR (Advanced Digital Recording — улучшенная цифровая
запись) компании OnStream относительно нова на рынке ленточных нако-
пителей. Она основана на технологии последовательной записи н в настоящее
время поддерживает носители емкостью от 15 до 25 Гбайт. Стоимость
накопителя невелика, а иена носителей сопоставима с ценой других
ленточных систем аналогичной емкости. Подобные устройства обладают
достаточно высокой скоростью работы Например, модель емкостью 25 Гбайт
обеспечивает пропускную способность 2 Мбайт/с.
Первоначально фирма OnStream столкнулась с рядом трудностей, что
неудивительно, когда новая компания выходит на рынок с новой технологией.
Со временем ранние ошибки были устранены, но драйверы ADR-устройств
все еще редки и, по слухам, также не лишены недостатков.
Технология DLT
Накопители DLT (Digital Linear Таре — лента для цифровой записи с
последовательным доступом) — это достаточно популярные устройства ре-
зервного копирования Они надежны, недороги и позволяют хранить большие
объекты данных. Их родоначальниками являются кассетные накопители ТК-50
и ТК-70. которые были популярными периферийными устройствами на
рабочих станциях VAX компании DEC. DLT-устройства первого поколения
могли читать только старые ленты ТК-70. Впоследствии компания Dec
продала технологию фирме Quantum, которая увеличила скорость и емкость
устройств и снизила на них иены
DLT-накопители могут хранить до 40 Гбайт данных. Скорость передачи
достигает 6 Мбайт/с. Производители заявляют, что ленты будут служить от
20 до 30 лет. Но останутся ли к тому времени устройства, способные их
прочесть? Много ли вам известно устройств чтения 9-дорожечных лент,
которые до сих пор функционируют?
Недостатком технологии DLT является иена носителей, которая достига-
ет 65$. Для какой-нибудь инвестиционной компании с Уолл-стрит это, может,
и нормальная цена, но для университета подобные расходы неприемлемы.
Глово 10. Резервное копировоние
'?5
Технология AIT
Технология AIT (Advanced Intelligent Tape — улучшенная лента co
встроенной логикой) — это линия усовершенствованных устройств с 8-мил-
лнметровой лентой компании Sony. В 1996 г. Sony отказалась от поддержки
устройств Exabyte и представила собственный стандарт AIT-1, в котором
также использовалась методика записи по спиральной развертке, но емкость
накопителя была в два раза выше. После этого появились две новые версии
устройств: AIT-1 (повышенной емкости с увеличенной длиной ленты) и AIT-2.
В ближайшем будущем Sony планирует выпустить спецификацию AIT-3.
В AlT-устройствах используются ленты АМЕ (Advanced Metal Evapo-
rated — улучшенное напыление металла), имеющие больший срок жизни.
В них также содержится встроенное ЭСППЗУ (электрически-стираемое
программируемое ПЗУ), включающее микрокод устройства. Но для исполь-
зования этого микрокода требуется программная поддержка. Устройства AIT-2
обладают пропускной способностью 6 Мбайт/с, а емкость носителя 50 Гбайт
Цена устройств и лент сопоставима с ценой DLT-аналогов.
Технология Mammoth
Система Mammoth компании Exabyte — это улучшенный вариант уст-
ройств с 8-миллиметровоЙ лентой. Компания Exabyte решила выпускать свои
собственные устройства после того, как прекратилось ее сотрудничество с
Sony. Претензии к Sony были вызваны недостаточным качеством производ-
ства. У Sony была единая технологическая линия как для потребительских
продуктов, так и для информационных носителей, поэтому в глазах компании
устройства Exabyte ничем не отличались от видеокамер.
У продуктов Mammoth первого поколения были проблемы с надежностью,
однако компания Exabyte прислушалась к своим клиентам и устранила
недостатки. Теперь, по заявлениям изготовителя, уровень отказов составляет 1 %
Устройства Mammoth также используют ленты АМЕ, но в них не
содержатся микросхемы памяти. Накопители Mammoth-2 имеют невероятно
высокую пропускную способность; 12 Мбайт/с. Это гораздо больше, чем у
других ленточньгх устройств данного ценового класса.
Системы с автоматической загрузкой носителей
Стоимость современных высокоемких жестких дисков столь мала и они
используются столь широко, что во многих организациях для резервного
копирования информации требуется несколько лент, даже если емкость
каждой из них 20 Гбайт. В таких случаях можно порекомендовать приобрести
укладчик, магазин или ленточную библиотеку.
Укладчик — это простое устройство для автоматической замены лент,
используемое со стандартным накопителем. Он оснашен загрузочным бунке-
ром, в который помешаются ленты. Заполненная лента изымается из
накопителя и заменяется пустой, которую укладчик берет из бункера.
В бункерах большинства укладчиков помещается до десяти лент.
Магазин — это устройство, которое автоматически меняет съемные
носители в нескольких накопителях. Выпускаются магазины для различных
типов носителей, включая кассеты DAT, DLT и AIT, а также компакт-диски.
Часто магазины поставляются вместе со специальными программами создания
резервных копий, которые знают, как манипулировать устройством смены
носителей. Данные продукты производятся, в частности, компаниями Storage
Technologies н Sony.
19o
Чость I. Основы ОДМИНИСТрИрОВОНИИ
Библиотеки лент — это устройства, предназначенные для хранения
огромных — терабайтных — объемов данных. Они представляют собой
аппаратные комплексы размером со шкаф, в которых имеется манипулятор
“рука”, обслуживающий многочисленные ленточные носители или дисководы
компакт-дисков. Несложно понять, что это весьма дорогие устройства как
для покупки, так и для обслуживания. Как правило, вместе с библиотекой
вызывается оператор, который отвечает за установку и наладку комплекса
С библиотекой поставляется также программный пакет, управляющий работой
комплекса. Ведущим производителем ленточных библиотек является компа-
ния Storage Technology.
Жесткие диски
Следует также упомянуть о стремительном снижении стоимости жестких
дисков, что делает их вполне достойными кандидатами на роль устройств
резервного копирования. И хотя мы не рекомендуем копировать один диск
на другой на той же самой машине, но можно создавать резервные копии
по сети, причем стоимость их будет очень невелика. При создании образа
диска, доступного по сети через NFS, пользователи получают возможность
восстанавливать случайно удаленные файлы без вмешательства администратора.
Сводка типов носителей
В табл. 10.1 приведены характеристики рассмотренных выше носителей
и соответствующих им устройств.
Таблице 10.1. Сравнительные характеристики носителей, преднозноченных
для резервного копирования
1 : i	В.5 i									и с 5? * t Е г н	»	>3 ;	; 5	i г	доступ
Носитель Емкость' Скорость Цена накопите Цена							носителя Цено в р на 1 Гбо				
Гибкий ДИСК	2.8	Мбайт	< 100 Кбайт/с		15$	0.25$		91.43$	д	а	Да
SuperDisk	120	Мбайт	1,1 Мбайт/с2		200$	8$		68,27$	д	а	Да
Zip 250	250	Мбайт	900 Кбайт/с		200$	15$		61.44$	д	а	Да
CD-R	650	Мбайт	2/	Мбайт/с	200$	0.75$		1.18$	Нет		Да
CD-RW	650	Мбайт	2.4 Мбайт/с		200$	2$		3,15$	д	а	Да
Jaz	2	Гбайт	7.4 МбаЙт/с		350$	100$		50.00$	Д	а	Да
Orb	2.2	Гбайт	12.2 Мбайт/с2		200$	40$		18.18$	Д	а	Да
Exabyte (8мм)	7	Гбайт	1	Мбайт/с	1200$	8$		1.14$	Д	а	Нет
Travan	10	Гбайт	1	Мбайт/с	200$	34$		3,14$	Д	а	Нет
DDS-4 (4 mm)	20	Гбайт	2.5	Мбайт/с	1000$	30$		1.50$	Д;	а	Нет
ADR	25	Гбайт	2	Мбайт/с	700$	40$		1.60$	д.	а	Нет
DET (0,5 дюйма)	40	Гбайт	6	МбаЙт/с	4000$	60$		1.50$	Д	а	Нет
AIT-2 (8 mm)	50	Гбайт	6	Мбайт/с	3500$	95$		1,90$	Д;	а	Нет
Mammoth-2	60	Гбайт	12	Мбайт/с	3500$	80$		1,33$	Д;	а	Нет
Емкость и скорость указаны без учета сжатия данных.
2 Указана максимальная скорость пакетной передачи; производитель не раскрывает
истинную среднюю пропускную способность.
Глово Ю. Резервное копировоние
197
Кертис Престон (W. Curbs Preston) публикует в Internet список устройств
резервного копирования с указанием их параметров и производителей. Этот
список доступен по адресу www.backupcentral.com/hardware-drives.html.
Что покупать
Все устройства резервного копирования работают достаточно хорошо, и
среди систем одной ценовой категории обычно трудно отдать какой-либо
предпочтение. Покупайте систему, которая отвечает требованиям конкретной
организации и имеет приемлемую цену.
Устройства DAT и Exabyte лучше всего подходят для небольших рабочих
групп и отдельных компьютеров, в которых установлены высокоемкие диски
Стартовая цена этих систем относительно умеренна, а их носители широко
распространены. Обе системы обладают достаточным быстродействием, что
позволяет архивировать большие объемы данных за разумное время.
В эту же группу можно было бы включить устройства ADR. но данная
технология все еще считается экзотичной, к тому же, ее поддерживает
однн-единствеиный производитель.
Устройства DLT, AIT и Mammoth-2 обладают близкими характеристика-
ми. Трудно сделать выбор в пользу какой-то одной из этих технологий, гем
более что ситуация может измениться с появлением новых спецификаций и
моделей устройств. Все устройства данной группы ориентированы на один
сегмент рынка: университетскую и корпоративную среду, где требуются
высокопроизводительные системы резервного копирования.
В наших дальнейших рассуждениях мы используем базовый термин
“лента” в качестве универсального обозначения носителей, выбранных для
резервного копирования. Примеры команд, выполняющих резервное копи-
рование, даются в контексте ленточных накопителей
1СЗ. Настройка режима инкрементного архивирования
Самые распространенные программные средства создания резервных
копий и восстановления из них данных — команды dump и restore. Эти
команды входят в состав операционной системы UNIX уже длительное время,
и их характеристики хорошо известны. В большинстве организаций команды
dump и restore используются автоматизированными системами резервного
копирования.
Архивирование файловых систем
Команда dump создает перечень файлов, которые модифицировались с
момента предыдущего архивирования, а затем упаковывает эти файлы в один
большой файл, поллежашнй записи на внешнее устройство Команда dump
обладает некоторыми преимуществами по сравнению с другими утилитами,
описанными в этой главе:
•	резервные копии могут быть записаны на несколько лент;
•	можно выполнять резервное копирование и восстановление файлов
любого типа (даже файлов устройств);
•	можно восстанавливать права доступа, принадлежность и время модифи-
кации файлов;
19В
Часть I. Основы администрирования
•	обеспечивается правильная обработка файлов с ‘ дырами” ;
•	резервное копирование может производиться в инкрементном режиме (на
ленту записываются только модифицированные версии файлов).
Команда dump понимает структуру исходных файловых систем и, читая
непосредственно таблицы индексных дескрипторов, решает, с каких файлов
необходимо делать резервные копии. Такое знание файловой системы
позволяет команде dump достигать высокой эффективности но вместе с тем
налагает на нее определенные ограничения”
Первое ограничение заключается в том. что каждая файловая система
должна архивироваться в индивидуальном порядке. Если диск разбит на
разделы, придется копировать каждый раздел отдельно. Следующее ограни-
чение: разрешается копировать только файловые системы локальной машины,
а файловую систему NFS архивировать нельзя. Тем не менее, можно создать
резервную копию локальной файловой системы на удаленном ленточном
накопителе; для этого используется программа rdump.
Подробная информация об NFS приведена в главе /7.
Самая важная особенность команды dump состоит в поддержке инкре-
ментного резервного копирования. Можно, конечно, каждый день создавать
копии всей системы, но это не совсем практично. В инкрементном режиме
резервируются только те файлы, которые изменились с момента последнего
копирования.
При создании архива ему присваивается уровень резервирования (целое
число от 0 до 9). В архив уровня N копируются все файлы, которые
изменились с момента создания последнего архива уровня, на единицу
меньшего, чем N. В архив нулевого уровня на ленту помешается вся файловая
система. При систематическом инкрементном резервировании можно восста-
новить файловую систему точно в том состоянии, в котором она пребывала
на момент последнего резервного копирования, хотя для этого может
потребоваться восстановление файлов из нескольких лент”'.
Еше одна чудесная особенность команды dump состоит в том, что она
не обращает внимания на длину имен файлов. Иерархии каталогов могут
быть произвольно глубокими, и длинные составные имена обрабатываются
корректно.
Команда dump принимает много аргументов, но различий между ними в
разных платформах немного. Мы приведем краткое описание флагов,
которые, вероятно, понадобятся для создания резервных копий по сети.
Обязательно сверьте эти флаги с приведенными в man-страницах руководства
той машины, на которой создается архив, потому что большинство фирм-
поставщиков считает своим долгом изменить хотя бы один флаг.
" ‘‘Дыры” — это блоки, которые никогда нс содержали данных. Если, открыв файл, записать
в него один байт, сдвинуть указатель записи на 1 Мбайт вперед и записать еще один байт,
то полученный файл будет занимать всею два дисковых блока, хотя ею логический размер
гораздо больше. Мною дыр обычно содержат файлы, созданные программами dbn и ndbm.
•• Команда dump требует доступа к неструктурированным разделам диска. Каждый, кому
разрешено выполнять резервное копирование, может, приложив определенные усилия,
прочесть все файлы в системе.
Большинство версий команды dump не отслеживает, какие файлы были удалены. При
восстановлении информации из инкрементных резервных копий удаленные файлы будут
создаваться заново.
Глово 10. Резервное копировоние
199
Команда dump анализирует свои аргументы не так, как большинство
остальных команд UNIX В строке ее вызова сначала следует указывать все
флаги, а затем перечислять аргументы флагов. Другими словами, вместо
строки -а 5 -b -С10 команда dump ожидает строку abc 5 10.
Первым аргументом команды dump должен быть уровень инкрементного
резервирования. Для того чтобы определить, насколько далеко создавался
последний архив, команда dump использует файл /etc/dumpdates. Флаг и
заставляет команду dump после завершения копирования автоматически
обновить файл /etc/dumpdates При этом регистрируется дата, уровень архива
и имя файловой системы. Если флаг и не указан, все архивы получают
уровень 0, поскольку факт предыдущего резервного копирования файловой
системы нигде не отражается. В случае если имя файловой системы
изменилось, можно отредактировать файл /etc/dumpdates вручную.
Свою выходную информацию команда dump посылает на некое стандарт-
ное устройство. Как правило, это основной ленточный накопитель. Если
необходимо задать другое устройство, воспользуйтесь флагом Г. чтобы
сообщить команде dump, куда она должна отправлять данные. Когда на одну
ленту помещается несколько архивов, укажите имя ленточного устройства,
не поддерживающего режим перемотки (т.е. задайте файл устройства, который
не вызывает перемотку ленты по окончании записи — для большинства
ленточных устройств такой файл создается наряду со стандартным) Чтобы
определить имя соответствующего файла, прочтите man-страницу с описанием
ленточного устройства (табл. 10.2)'.
Таблица 10.2. Файлы устройств для стандартного ленточного устройство SCSI
Система	Режим перемотки	Без режима перемотки
Solaris	/dev/rmt/О	/dev/rmt/оа
HP-UX	/dev/nnt/Oni	/dev/rmt/Onui
Red Hat	/dev/stO	/dev/nstO
FreeBSD	/dev/гваО	/dev/nrsaG
Если случайно выбран файл устройства с перемоткой, все закончится
сохранением только последней заархивированной файловой системы. По-
скольку команда dump понятия не имеет о том. перемотана лента в начало
нли нет. эта ошибка не повлечет за собой других ошибок и станет очевидном
лишь при попытке восстановления файлов.
Если архив помещается в удаленную систему с помощью программы
rdump. удаленное устройство нужно задать в формате илыгустройство.
например:
й rdump Ouf anchor:/dav/паt0 /spare
Права доступа к удаленному ленточному устройству задаются в файле .rliosts.
Но мы рекомендуем воспользоваться системой SSH (см параграф 21.8).
Раньше нужно было указывать команде dump точную длину ленты, чтобы
она могла прекратить запись при достижении конца ленты. Современные
Для всех файлов ленточного устройства задан один и тот же старший номер устройства.
Младший номер устройства сообщает драйверу особые характеристики (перемотка, пере-
становка байтов и т.д.).
200
Чость I Основы ОДМИНИСГрИрОВОНИЯ
накопители самостоятельно обнаруживают коней ленты и сообщают об этом
команде dump, которая перематывает ленту обратно, выталкивает носитель
из устройства и запрашивает новую ленту. Поскольку применение различных
аппаратных алгоритмов сжатия не позволяет так просто определить длину
ленты на основании ее емкости, лучше ориентироваться на сигнал конца
ленты (EOT — End Of Таре), если, конечно, его поддерживает устройство и
понимает команда dump
К сожалению, сигнал EOT появился гораздо позже, чем произошло
разделение семейств UNIX-систем, поэтому рахзичные версии команды dump
работают с лентами по-разному. Одни по умолчанию предполагают, что
ленточные накопители сами генерируют сигнал EOT, поэтому никак не
ограничивают размер ленты. Другие считают, что лента имеет длину 2300
футов (примерно 70 метров) и плотность записи 1600 bpi (битов на дюйм),
что соответствует 9-дорожечным лентам 15-летней давности, но никак не
сегодняшним носителям. Эти версии команды обычно понимают сигнал EOT.
если он возникает раньше запланированного конца ленты. В таких случаях
лучше обмануть команду' dump, сообщив ей. что лента гораздо длиннее, чем
есть на самом деле.
Все версии команды dump понимают опции d и s, которые задают
плотность ленты в байтах на дюйм и длину ленты в футах соответствен но.
Иногда можно даже указывать размер ленты в килобайтах. Если же такой
возможности нет. необходимо выполнить несложные арифметические вычис-
ления и получить нужный размер.
Предположим, например, что требуется создать архив пятого уровня для
каталога /work и записать его на устройство DDS-I (DAT), стандартная
емкость носителя которого составляет 1 Гбайт, а в режиме сжатия —
1.5 Гбайт. DAT-устройства выдают сигнал EOT. поэтому нужно сообщить
команде dump заведомо больший размер ленты, скажем. 4 Гбайт. Это составит
60000 футов при плотности записи 6250 bpi
# dussp 5usdf 60000 6250 /dev/retO /work
DUMP: Dace of this level 5 dump: Mon May 8 16:59:45 2000
DUMP: Date of Last level 0 dump: the epoch
DUMP: Dumping Zoev/hda2 (/work) to /dev/rstO
DUMP: mapping (Pass I) (regular files]
DUMP: mapping (Pass IT) [directories]
DUMP: estimated 942223 tape blocks on 0.23 tape(s).
За флагами 5usdf следуют значения аргументов s (размер: 60000), d
(плотность: 6250) и Г (файл устройства: /dcv/rstO). В конце указывается
обязательный аргумент, имя файловой системы (/work) Большинство версий
команды dump позволяют задавать файловую систему точкой ее монтирования,
как в приведенном примере. Некоторые версии этой команды требуют
указывать исходный файл устройства.
Последняя из показанных выше строк позволяет убедиться, что команда
dump не потребует произвести смену лент, так как. по мнению команды,
лишь четверть ленты будет занята архивом. Это удобно, если запись в
действительности осуществляется на несколько лент.
В Solaris команда dump не имеет ничего общего с резервным копирова-
нием: она используется для проверки объектных файлов. Когда инженерам
компании Sun становится скучно, один из менеджеров рассказывает историю
о том, как один '‘чайник” пытался архивировать лиски с помощью команды
Глово 10 Резервное копировоние
201
dump, и все смеются. “Настоящая" команда dump называется /usr/sbin/ulsdump.
К счастью, команда ufsdump использует те же флаги и аргументы, что и
традиционная версия dump. Например, команда
#	ufsdump Out /dev/nnt/2 /dav/rd»k/c0t3d0s5
создает архив раздела 5 SCSI-диска с целевым номером 3, помешан его на
ленточный накопитель с номером 2.
Возможно, в Linux придется явно инсталлировать команды dump и restore,
так как по умолчанию они отсутствуют. Имеется модуль rpm (Red Hat Package
Manager — менеджер пакетов Red Hat), который упрошает инсталляцию.
В Linux файлы не компонуются статически, поэтому необходимо наличие
общедоступных библиотек в каталоге /Jib. Во FreeBSD, OpenBSD и NetBSD
команда restore компонуется статически. В этом случае она является
совершенно самодостаточной, что упрощает восстановление после сбоев.
Схемы создания архивов
Поскольку уровни архива — величины произвольные (онн имеют значе-
ние только в связи с другими уровнями), то существует целый ряд расписаний,
по которым можно создавать архивы. Выбор плана резервного копирования
обусловлен следующими факторами:
•	активностью файловых систем,
•	емкостью устройства резервного копирования;
•	необходимой степенью избыточности,
•	числом лент, которые нужно приобрести
Раньше, когда для создания архивов требовалось много лент, раграбаты-
вались сложные графики архивирования, позволявшие свести к минимуму
число лент, занимаемых каждодневными архивами. Сегодня емкость лент
существенно возросла, поэтому разница между уровнями архива уже не так
важна.
Так как большинство файлов никогда не меняются, даже в простейшей
схеме инкрементного архивирования многие файлы не включаются в
ежедневный архив. При введении дополнительных уровней небольшое число
периодически изменяющихся файлов дробится на все меньшие и меньшие
сегменты.
Сложная схема резервного копирования может создаваться по трем
причинам:
•	данные будут архивироваться чаще, что позволит снизить возможные
потери;
•	можно использовать меньшее число каждодневных лент (илн уместить
все на одну ленту);
•	можно создавать несколько копий каждого файла, чтобы защитить себя
от ошибок лент.
Мы опишем несколько возможных схем и приведем аргументы в пользу
каждой из них.
Простая схема
Если обший размер дискового пространства меньше емкости ленточного
накопителя, можно предложить совершенно тривиальный график резервиро-
вания. Архивы нулевого уровня каждой файловой системы нужно создавать
202
Чость I. Основы одминистрировония
ежедневно. Используйте многократно один набор лент, но через каждые N
дней (где N определяется потребностями компании или организации)
откладывайте ленты навсегда Стоимость такой схемы составит
(365/N) • (цена ленты)
в год. При создании очередного архива нельзя использовать предыдущую
ленту. Лучше осуществлять ротацию лент, чтобы в случае, если один из
архивов будет уничтожен. можно было восстановить архив предыдущего дня
Подобная схема обеспечивает высокую избыточность и значительно
облегчает восстановление данных. Она хорошо подходит для организации,
имеющей много денег, но мало операторского времени (или опыта).
Умеренной схема
Более приемлемый план — выделить по одной ленте на каждый день
недели, каждую неделю месяца (здесь понадобится пять лент) и каждый месяц
года. Ежедневно создавайте архив девятого уровня на дневной ленте,
еженедельно — архив пятого уровня на недельной ленте, ежемесячно — архив
третьего уровня на месячной ленте. Архив нулевого уровня нужно создавать
каждый раз, когда инкрементные копии становятся слишком велики для
одной ленты. Чаще всего это происходит с месячными лентами. В любом
случае архивирование нулевого уровня необходимо выполнять хотя бы раз в год.
Уровни 3, 5 и 9 выбраны произвольно. С таким же успехом можно
использовать уровни 1. 2 и 3, но интервалы между уровнями дают некоторую
свободу для маневра на случай, если впоследствии потребуется добавить еще
один уровень.
Такой график требует наличия двадцати четырех основных лент, а также
некоторого количества лент для архивов нулевого уровня. Общее число
необходимых леит невелико, но и избыточность невысока.
10.4. Восстановление с резервных копий
Есть множество разновидностей команды, восстанавливающей данные с
резервных лент. Все они называются restore. Рассмотрим вначале вопрос
восстановления отдельных файлов (или небольшой совокупности файлов), а
затем расскажем, как восстанавливать файловые системы целиком.
Восстановление отдельных файлов
Первое, что нужно сделать, узнав о пропаже файла. — выяснить, на
каких лентах есть его версии. Пользователям часто хочется найти самую
последнюю версию файла, но так бывает не всегда. Например, пользователь,
потерявший файл из-за случайного копирования поверх него другого файла,
будет искать ту версию, которая существовала до этой неприятности. Важно
также узнать не только, какой файл пропал, но и где он пропал и когда
модифицировался последний раз.
Если не ведутся оперативные каталоги лент, придется монтировать ленты
одну за другой и пытаться найти пропавшие файлы наобум. В случае, когда
пользователь помнит, когда файл был изменен в последний раз, можно с
достаточной степенью вероятности предположить, на какой ленте он нахо-
дится.
Установив ленту. с которой будет производиться восстановление, создайте
временный каталог, к примеру /var/restorc. где будет образована большая
Гпаво 10. Резервное копирование
203
иерархия каталогов, и перейдите в него с помощью команды cd. Большинство
версий команды restore должны создать все каталоги, ведущие к конкретному
файлу, иначе восстановить его будет невозможно Не используйте для этих
целей каталог /tmp: в случае системного сбоя и последующей перезагрузки
содержимое каталога будет стерто.
У команды restore много опций Самые полезные из них — это i, которая
позволяет восстанавливать файлы в интерактивном режиме, и г, служащая
для полного восстановления всей файловой системы. Опция х запрашивает
неинтерактивное восстановление указанных файлов — будьте осторожны,
чтобы не перезаписать существующие файлы.
Команда restore i читает с ленты справочник файлов, а затем позволяет
перемещаться по архиву, как в обычном дереве каталогов, с помощью команд
Is, cd и pwd. Файлы, которые нужно восстановить, помечаются командой add
Выбрав все необходимые файлы, скопируйте их с ленты посредством команды
extract
Если на одной ленте много архивов, то перед выполнением команды
restore следует позиционировать ленту на соответствующий архив с помощью
команды mt. Не забудьте выбрать файл устройства без режима перемотки!
Описание команды mt дается в параграфе 10.7.
Например, для восстановления файла /users/janet/iamlost во FreeBSD с
использованием удаленного накопителя требуется задать показанную ниже
последовательность команд. Предполагается, что найдена нужная лента, она
смонтирована в точке tapehost:/dev/BstO, а файловая система, содержащая
начальный каталог пользователя janct, является четвертой на ленте.
I mkdir /var/restore
*	cd /var/restore
#	rah capehost mt -f /dev/nstO fsf 3
t rrestore if tapehost:/dev/nstO
restore> Is
janet/ garth/ lost+found/ lynda/
restore* cd janet
restore* Is
afile bfile cfne larnlosc
restore* add iaalost
restore* Is”
afile bfile cfile iamlost*
restore* extract
You have not read any volumes yet.
Unless you know which volume your files are on you should
start with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for [yn]: n
Ленточные тома нумеруются начиная с 1, а не с 0, поэтому для архива,
который умещается на одной ленте, нужно указать значение 1. Когда команда
restore спрашивает, следует ли установить владельца и режим доступа для
каталога это значит, что она интересуется, должен ли текущий каталог
• Можно воспользоваться командой ssh для обеспечения большей безопасности.
Звездочка рядом с именем iamlost означает, что этот файл отмечен для восстановления.
204
Чость I. Основы ОДмйНИСТрИрОВОНИЯ
соответствовать корневому каталогу ленты. Обычно в этом нет необходимости,
если только не восстанавливается вся файловая система целиком
После того как команда restore завершила свою работу, нужно передать
извлеченный файл пользователю janet.
t cd /var/restore
*	Is users/janet
larrlost
I Is -janet
afile bfile cfile
# cp -p users/janet/iamlost -janet/iamlost.restored
* chown janet -janet/iamlost.restored
# chgrp student -janet/iamlost.restored
» rm -rf /var/restore
i mail janet
Your file xamiost has been restored as requested and has
been placed in /users/janet/larrlosc. restored.
Your Name, Humble System Administrator
Некоторые администраторы предпочитают восстанавливать файлы в
специальный каталог, чтобы пользователи могли копировать их вручную.
В этом случае необходимо обеспечить защиту файлов, назначив им соответ-
ствующих владельцев и нужные права доступа. Не забывайте очищать этот
каталог, чтобы файлы не “засоряли” систему
Если резервная копия создавалась с помощью программы rdump и команда
restore не может восстановить файлы из архива, попробуйте воспользоваться
командой rrestore. Дчя сведения к минимуму вероятности возникновения
проблем старайтесь читать ленту на том же компьютере, на котором она
записывалась.
В целом команда restore 1 — самый простой способ восстановления
нескольких файлов пли каталогов и з архива Имеется лишь одно ограничение:
данная команда не будет работать, если ленту нельзя перематывать по одной
записи назад (такая проблема существует для некоторых 8-миллиметровых
накопителей) Если это случилось, не паникуйте, а сначала попробуйте
использовать команду restore х. Она требует указания полного путевого имени
восстанавливаемого файла (относительно корневого каталога архива) в
командной строке. Следующая группа команд повторяет приведенный выше
пример:
11 mkdir /var/restore
# cd /var/restore
# rsh tapehost mt -f /dev/nstO fsf 3
» rrestore xf tapehost:/dev/nstO /user»/janet/iamlost
Восстоновление файловых систем
Если читателю повезет, ему никогда не придется восстанавливать всю
файловую систему Иногда, однако, такие случаи все же бывают. Перед тем
как пытаться восстановить файловую систему, убедитесь, что та проблема,
которая привела к ее разрушению, устранена. Совершенно ни к чему сидеть
часами и мотать ленты лишь для того, чтобы тут же потерять файловую
систему еше раз.
Перел началом полного восстановления файловую систему нл жно создать
и смонтировать Подробно о том. как это делается, мы рассказали в главе 8.
Главе Ю. Резервное копирование
205
С помощью команды cd перейдите в каталог монтирования новой файловой
системы, вставьте в накопитель первую ленту самого последнего архива
нулевого уровня и введите команду restore г.
Команда restore будет сама подсказывать, когда нужно ставить следующую
ленту После восстановления архива нулевого уровня восстанавливайте все
инкрементные архивы вплоть до последнего в том порядке, в каком они
создавались. Поскольку всегда существует определенная избыточность, то.
как правило, нет необходимости восстанавливать все архивы. Вот примерная
последовательность действий:
•	Шаг 1: восстановите самый последний архив нулевого уровня.
•	Шаг 2: среди последующих архивов восствновите тот, у которого наи-
меньший уровень; если на данном уровне было создано несколько
архивов, восстановите новейшим из них.
•	Шаг 3: если это оказался самый последний из сделанных архивов, про-
цедуру можно считать завершенной, в противном случае следует вернуться
к шагу 2.
Приведем примеры архивных последовательностей. Восстанавливать нуж-
но только те архивы, номера которых выделены полужирным шрифтом:
оооооо
0 5 5 5 5
0 3 2 5 4 5
099599399599
0 3 5 9 3 5 9
Рассмотрим вето последовательность команд. Например, если последним
был создан месячный архив уровня 3, а перед ним создавался ежегодный
архив нулевого уровня (см. параграф “Умеренная схема” выше), то для
восстановления файловой системы /home. находящейся на физическом
устройстве /dev/dsk/c201d6s0, понадобятся следующие команды (имена уст-
ройств и вид команды newfs зависят от операционной системы):
« /etc/newfs /dev/dsk/c201d6ffi0 QUANTUM_₽D1050S
* /etc/mount /dev/dsk/c201d6s0 /home
f cd /home
/* Монтируем первую ленту архива уровня О для каталога /home */
г reetore г
/* Монтируем ленты, запрашиваемые командой restore */
/* Монтируем первую ленту ежемесячного архива уровня 3	*/
1 restore г
Если на одной резервной ленте было несколько файловых систем, то
перед обращением к команде restore необходимо с помощью команды mt
перейти к нужной файловой системе. Описание команды mt дано в
параграфе 10.7.
Приведенная последовательность команд позволит восстановить файло-
вую систему в том состоянии, в котором она находилась, когда был создан
архив третьего уровня, с одной особенностью: заодно будут “воскрешены” и
все удаленные с тех пор файлы. Эта проблема особенно неприятна, когда
восстанавливается активная файловая система или диск практически запол-
нен. Нс исключено, что во втором случае команда restore завершится
неудачей’
Говорят, что некоторые версии команд dump и restore отслеживают все удаления. Мы
полагаем, что это может иметь место в Solaris и Linux.
206
Чость 1. Основы одминистрировОния
10.5.	Архивирование и восстановление при модификации ОС
Прежде чем модернизировать операционную систему, необходимо путем
создания архива нулевого уровня получить резервные копии всех файловых
систем, а иногда и восстановить их. Восстановление требуется лишь в том
случае, если в новой ОС используется другой формат файловой системы или
если изменяется структура разделов диска. Резервное копирование нужно
обязательно предусматривать как меру предосторожности на случай проблем,
которые могут возникнуть в процессе модификации. Полный комплект
резервных копий, кроме того, даст возможность переинсталлировать старую
операционную систему, если новая версия не подойдет.
Не забудьте скопировать и восстановить все системно-зависимые файлы,
находящиеся в каталогах / и /usr. такие как /etc/passwd. /etc/shadow. /usr/local
и т.д. Эта задача довольно трудна, ибо специфическая — мягко говоря —
организация каталогов, принятая в UNIX, приводит к перемешиванию
файлов, созданных на данной машине, с файлами, входящими в комплект
поставки
Сразу после завершения модификации нужно создать полный набор
архивов нулевого уровня. Процедуры модернизации, принятые большинством
поставщиков ОС. предполагают установку даты модификации системных
файлов по времени их создания производителем системы, а не по текущему
времени. Это означает, что в случае краха инкрементные архивы, созданные
относительно архива нулевого уровня, записанного до модернизации, не
позволят восстановить систему в ее модернизированном состоянии.
10.6.	Другие программы архивирования
Будучи наиболее эффективным средством резервирования полных фай-
ловых систем, dump — не единственная программа, которую можно исполь-
зовать для архивирования файлов на ленты Перемещать файлы с одного
носителя на другой могут также программы tar. ерго и dd
Программа tan упаковка файлов
Программа tar берет несколько файлов или каталогов и записывает их
как один файл, часто прямо на ленту. 'Это удобный инструмент создания
резервных копий файлов, которые в ближайшем будущем придется восста-
навливать. Например, если пользователь уезжает на полгода, а в системе мало
дисковой памяти, администратор системы может воспользоваться программой
tar и перенести файлы этого пользователя на ленты, после чего удалить их
с диска
Программа tar, кроме того, хорошо подходит для перемещения дерева
каталогов из одного места в другое, особенно если имеющаяся в системе
программа ср не обеспечивает рекурсивное копирование или если файлы
копируются от имени пользователя root (поскольку программа гаг сохраняет
информацию о принадлежности объектов). Например, команда
tar cf - исходниИ_кап‘алог I ( cd конечный_катАпог ; Lar xfp - )
создает копию дерева исходного каталога в конечном каталоге. Небольшое
предупреждение, не указывайте каталог в качестве конечного, так как
наличие символических ссылок и программ автоматического монтирования
Глово 10 Резервное копировоние
207
может привести к тому, что реальный конечный каталог будет отличаться от
ожидаемого. Мы пострадали из-за этого несколько раз.
Большинство версий программы tar ие отслеживает символические
ссылки по умолчанию, ио им можно дать указание делать это. Загляните в
руководство по программе и найдите там правильный флаг, потому что в
разных системах ои разный.
Самый большой недостаток программы tar состоит в том, что большин-
ство ее версий не допускает использования многотомных архивов. Если
данные, которые нужно заархивировать, на одну ленту не помещаются,
программу tar использовать нельзя. Но даже если имеющаяся программа lar
заявляет о поддержке многотомных архивов, отнеситесь к этому скептически.
Не исключено, что она работает неправильно.
Еще одна проблема, характерная для многих версий программы tar,
заключается в том, что длина путевого имени ограничена 100 символами.
Это нс позволяет использовать программу для архивирования глубоких
иерархий каталогов. Если установленная в системе версия программы
поддерживает опцию, позволяющую работать с более длинными путевыми
именами (она есть в GNU-версии tar), помните о том, что обладатели
стандартной программы tar не смогут прочитать записанные вами ленты’.
Опция b программы tar позволяет задать размер блока (блок-фактор),
который должен учитываться при записи информации на ленту. Размер блока
указывается в виде числа 512-байтовых фрагментов и определяет, какой объем
данных программа помешает во внутренний буфер перед выполнением
операции записи. Отдельные DAT-устройства отказываются нормально рабо-
тать, если размер блока не установлен равным определенному числу; другие
накопители этого не требуют.
Иногда при некоторых значениях блок-фактора производительность
работы с лентой повышается. Оптимальный размер блока зависит от
конкретного компьютера и ленточного накопителя. Во многих случаях
разница в быстродействии незаметна. Если есть сомнения, задайте блок-фак-
тор 20.
Программа tar не допускает наличия ошибок на лентах.
Программа cpio: архивирование в системах
семейства System V
Утилита архивирования cpio по своим функциональным возможностям
близка к программе tar. Она является компонентом старых систем и редко
используется сегодня. Но ее можно применять для переноса дерева каталогов.
Команда
find мсходный_ка.талог -depth -print | cpio -pdni конечный_каталог
создает копию дерева исходного каталога в конечном каталоге. Аналогично
программе tar, большинство версий утилиты cpio не разрешает создавать
многоленточные архивы. Некоторые версии некорректно работают с канала-
ми, а специальные файлы может копировать только пользователь root. Опции
этой программы сильно отличаются в разных системах, поэтому следует
внимательно читать руководство.
GNU-вереия записывает таблицу соответствия имен в один из файлов архива. Пользователи
стандартной версии tar могут извлечь содержимое архива и исправить все вручную, но это
очень утомительный процесс.
208
Часть I Основы администрирования
Программа dd: манипулирование битами
Программа dd предназначена для копирования и преобразования файлов.
При отсутствии указаний о выполнении какого-либо преобразования про-
грамма просто копирует информацию из входного файла в выходной. Если
пользователь принес ленту, которая записана не в UNIX, программа dd может
оказаться единственным способом ее прочитать.
Одним из первоначальных применений программы dd было создание
копии всей файловой системы. Сегодня есть более эффективный вариант:
создать с помощью утилиты newfs целевую файловую систему, а затем
запустить команду dump в конвейере с командой restore. Программа dd, при
неправильном ее использовании, иногда может искажать информацию о
структуре разделов Она может копировать файловые системы только между
разделами в точности одного и того же размера.
Более подробную информацию о программе newfs вы можете найти в главе 8.
Программу' dd можно также применять для создания копий магнитных
лент. При наличии двух ленточных накопителей (к примеру, /dev/rmt8 и
/dev/rmt9) используйте команду
% dd if«/d«v/rmt8 of»/dev/rat9 cbe=16b
Если есть один накопитель (/dev/rmt8), воспользуйтесь такой последова-
тельностью;
% dd if«/d«v/rmtfi of»t£lla cbs“16b
/* Модифицируем ленты */
% dd if=t£ile of—/d*v/rratS cbe«16b
% гп tfile
Конечно, когда имеется всего один накопитель, должно быть достаточно
дискового пространства для сохранения образа ленты.
Еще одна историческая функция программы dd — преобразование данных
в нужный формат при обработке QIC-лент, отличающихся друг от друга
только порядком следования байтов. Например, чтобы прочесть на компью-
тере Sun ленточный tar-архив, записанный на компьютере SGI, нужно задать
команду
% dd i£«/dav/ret8 conv^awab | t*r xf -
Имя ленточного устройства зависит от используемой системы
Программа volcopy: дублирование файловых систем
Программа volcopy создает точную копию файловой системы на другом
устройстве, изменяя при необходимости размер блока. Эта программа имеется
в Solaris, HP-UX и Linux. Ее можно использовать для резервного копирования
файловой системы на съемный диск или для создания полной копии системы
на ленте.
10.7.	Запись нескольких файлов на одну ленту
Фактически магнитные ленты содержат одну’ длинную строку данных. Но
очень часто возникает необходимость поместить на ленту несколько архивов,
поэтому ленточные накопители и их UNIX-драйверы могут поддерживать
более сложную структуру хранения. Когда команда dump или какая-нибудь
Глава 10 Резервное копировоние
209
другая команда записывает поток байтов на ленту, а затем закрывает файл
устройства, на ленту автоматически помешается маркер конца файла (end of
file, EOF). Этот маркер отделяет один поток от другого. При извлечении
потока операция чтения автоматически прекращается в случае обнаружения
маркера EOF.
Для позиционирования ленты на конкретный поток используется команда
mt. Она очень полезна при размещении на одной лейте нескольких файлов
(например, нескольких резервных копий). Кроме того, сообщения об ошибках
этой команды — одни из самых интересных среди утилит UhlIX. Базовый
формат команды таков:
rat [~f имя_лен1ъг] команда [счетчик]

Аргумент имяленты — это имя ленточного устройства (с отключенным
режимом перемотки, если необходимо выполнить какие-либо операции нал
файлами).
В HP-UX вместо опции -Г используется опция -t.
Аргумент команда имеет множество значений. От платформы к платформе
они меняются, поэтому мы рассмотрим лишь те варианты, которые важны
для создания резервных копий и их восстановления.
rew
оН
status
fsf [счетчик]
bsf [счетчик]
Перемотать ленту в начало.
Переключить ленту в автономный режим. В некоторых накопителях
это приводит к выбросу ленты из приемника. Большинство сценариев
архивирования применяет эту команду для изъятия ленты по окон-
чании операции, что должно свидетельствовать об успешном ее
завершении.
Вывести информацию о текущем состоянии ленточного накопителя
(вставлена ли лента и т.д.).
Перемотать ленту вперед. Если аргумент счетчик отсутствует, лсвта
перематывается на один файл. Если указан числовой аргумент,
команда пропускает соответствующее количество файлов. Эту команду
можно использовать для перехода к нужной файловой системе на
ленте, содержащей несколько архивов.
Вернуться назад на указанное число файлов. В некоторых системах
текущий файл при этом считается, а в некоторых — нет. Иногда эта
команда не делает ничего (и не сообщает об этом). Если лента
перемотана слишком далеко, лучший вариант — дать команду rew и
начать сначала.
Точный перечень команд, которые поддерживает команда mt. можно
найти в документации.
10.8.
Amanda
Amanda (Advanced Maryland Automatic Network Disk Archiver — усовер-
шенствованный автоматический сетевой дисковый архиватор Университета
штата Мэриленд) — это сложная система сетевого резервного копирования,
которая заменяет доморощенные сценарии, используемые многими компа-
ниями и организациями. Она позволяет создавать архивы всех компьютерных
систем в сети и помешать их на ленту через единствениый накопитель на
сервере. Amanda поддерживает большинство UNIX-систем и многие виды
резервных носителей.
Система Amanda была написана Джеймсом да Сильвой (James da Silva)
из Университета штата Мэриленд в 1991 г. Теперь ее сопровождением и
210
Чость I. Основы ОДМИНИСТрИрОВОНИЯ
доработкой занимается коллектив системных администраторов со всего мира.
Последнюю информацию и исходные тексты можно получить по адресу
www.amanda.com.
Сама по себе Amanda — это ие программа, а оболочка, управляющая
другими программами резервного копирования. В большинстве организаций
она работает с системными командами dump и restore, но может также
использовать программу gnutar и даже программу smbtar сервера Samba,
установленного в NT-системах.
Amanda поддерживает большое число ленточных накопителей, а также
умеет работать с укладчиками и ленточными магазинами. Она может
использовать аппаратный алгоритм сжатия накопителя или же запускать на
клиентских машинах программу compress либо gap, перед тем как данные
отправятся по сети.
Другая прекрасная особенность системы — механизм управления лента-
ми. Amanda записывает служебный заголовок на каждую ленту, поэтому
никогда не затирает неправильную ленту. Кроме того, система управляет
уровнями архивов, основываясь на параметрах конфигурации и заполненно-
сти ленты Ведется список архивов, находящихся на каждой из лент, и можно
распечатывать наклейки с информацией о содержимом лент (это оказывается
очень кстати, если выходит из строя диск, включающий базу данных Amanda).
Amanda — одно из самых популярных бесплатных решений в области
резервного копирования. Она установлена на 1500 серверах по всему миру.
Amanda хорошо справляется с увеличением числа обслуживаемых компьюте-
ров и постоянно улучшается с целью поддержки самых последних устройств
резервного копирования.
Архитектура
В архитектуре Amanda ленточные накопители и буферные диски подклю-
чены к центральному серверу. Сервер также содержит все конфигурационные
и журнальные файлы плюс базу данных. Amanda может записывать на ленту
только один архив за раз, но может временно помещать многотомные архивы
на буферные диски, а затем последовательно переносить их на ленты.
В системе Amanda на одном сервере Поддерживается несколько конфи-
гураций Например, в одной конфигурации создаются только архивы уровня 0.
а в другой — инкрементные архивы. С каждой конфигурацией связаны свои
журнальный файл и база данных.
Сервер Amanda проверяет конфигурационные файлы, чтобы определить,
какие файловые системы нужно архивировать, какие ленточные накопители
доступны и сколько системных ресурсов (сетевой канал, накопители,
центральный процессор) разрешается использовать. Затем он обращается к
клиентским машинам и просит их подсчитать размер архивируемых файлов. На
основании этой информации Amanda составляет план резервного копирования
Сервер Amanda представляет собой коллекцию программ, которые
реализуют разные задачи системы. Лучше всего запускать серверные про-
граммы на быстрой машине, которая, как правило, не слишком загружена.
Если архивируются данные большого объема, то сервер должен иметь самое
быстрое соединение с сетью, какое только возможно в рамках существующей
архитектуры. Буферный диск, содержащий копии сетевых архивов, должен
обладать как минимум таким же размером, что и самый большой дисковый
раздел среди клиентских машин. Необходимо также дополнительное место
на диске (не более 75 Мбайт) для хранения журнальных файлов и баз данных.
Глово 10 Резервное копировоние
211
Инсталляция
На момент написания книги последний стабильный выпуск системы
Amanda имел номер 2.4. Ipl. Приводимые ниже примеры конфигурационных
файлов и команд даны именно для этой версии. Если будете загружать из
Internet исходные тексты Amanda, берите последний стабильный выпуск, а
не текущую версию для разработчиков. Ведь речь идет о создании резервных
копий, поэтому здесь важна надежность.
Распаковав исходные тексты, прочтите файлы README, docs/SYS-
ТЕМ.NOTES и docs/INSTALL. Во втором из них указаны все системно-за-
висимые особенности. В файле INSTALL даны пошаговые инструкции по
поводу инсталляции.
Прежде чем запускать программу configure залайте команду configure —
help, чтобы получить полный список опций. Требуется определить не только
каталог инсталляции, но также от имени какого пользователя и какой группы
должна работать Amanda. Необходимо, чтобы этот пользователь имел доступ
к каждому дисковому разделу, предназначенному для арх1£вирования с
помощью команды dump Как правило, при использовании команды chgrp
права на соответствующие файлы устройств передаются специально созданной
группе, и сервер Amanda работает от ее имени. После завершения программы
configure запустите команды make и make install, чтобы завершить инсталля-
цию.
Каждый клиент Amanda должен иметь доступ к двоичным файлам сервера.
Однако идея предоставить всем клиентам доступ к файлам через NFS является
не лучшим решением, поскольку' бывают ситуации, когда все клиенты должны
запускать программы одновременно (например, в начале процедуры резерв-
ного копирования, когда Amanda просит клиентов подсчитать размер
архивов). Желательно инсталлировать программы на локальные диски каждого
клиента, обычно где-то в каталоге /usr/local.
Список программ, инсталлируемых на каждом клиентском компьютере,
представлен ниже. Они никогда не должны запускаться вручную.
amandad Управляет всем взаимодействием между клиентом и сервером;
запускает все остальные клиентские программы
selfcheck	Проверяет, сконфигурирован ли клиент для работы с Amanda, а
именно: установлены ли права доступа к устройству, можно ли найти
программу gzip, можно ли осуществлять запись в файл /etc/dumpdates
и т.Д-
seodbackup Выполняет резервное копирование
seodsize	Оценивает размеры резервных копий для различных уровней архи-
вирования
На клиентских машинах должны быть выполнены еше некоторые
операции конфигурирования. В файлы /etc/inetd.conf и /etc/services нужно
добавить по одной дополнительной строке для сервера Amanda. Каждое
устройство, с которого будут сниматься резервные копии, должно быть
доступно для пользователей группы, в которую входит в Amanda. Необходимо
также, чтобы эта группа имела право записи в файл /etc/dumpcheck. После
того как все конфигурационные файлы заданы, запустите программу amcheck,
которая произведет финальную проверку.
Ниже показана строка, добавляемая в файл inetd.conf (предполагается,
что в качестве имени пользователя и группы сервера Amanda выбрано имя
“amandaM):
amanda dgrani udp wait amanda /usr/local/sbin/amandad amandad
212
Чость I. Основы одминистрировония
Эта строка может использоваться как на сервере, так и на клиенте. Чтобы
еше сильнее защитить систему резервного копирования, поместите в файл
inetd.conf строку вызова программы tcpd, написанной Уитсом Венема (Wietse
Venema); более подробную информацию можно найти в параграфе 21.7.
Вот строка, помещаемая в файл /etc/senices:
amanda	10080/udp
Ниже представлен список команд Amanda. Большинство из них прини-
мает аргумент, сообщающий о том. какую из конфигураций Amanda следует
использовать.
amdump Выполняет ночное архивирование; обычно используется демоном стоп
агпЛивЬ Осуществляет принудительную запись содержимого буферных дисков
на ленту в случае возникновения проблем
amcleanop Производит очистку, если на сервере произошел сбой в процессе
создания архива
amrestore	Выполняет операции восстановления из архивов Amanda
а го label	Записывает метки Amanda на леиту; служит для предотвращения
проблем, связанных с перезаписью не тех лент
amadmln Находит нужную тенту для восстановления и выполняет другие
административные операции
яшсЬеск Проверяет, верная ли лента используется, достаточно ли места на
буферных дисках и сконфигурирован ли клиентский компьютер долж-
ным образом
aintape Управляет укладчиками и устройствами смены лент
□mplot Стронг графики активности сервера Amanda (например, процент
использования буферного диска и сетевого канала) для каждого
создаваемого архива
Для каждой конфигурации создается отдельный каталог к файлы
amanda.conf и disklist. Первый из этих файлов задает общие параметры
конфигурирования сервера, а второй содержит список клиентов и файловых
систем, для которых осуществляется резервное копирование. Данные файлы
располагаются только на сервере.
Файл amanda.conf
Файл amanda.conf достаточно велик, поэтому мы разобьем его на четыре
логических компонента: локальная информация, параметры стратегии архи-
вирования, параметры использования ресурсов и определения типов архивов.
Эти компоненты являются нашим изобретением. Ни в самой системе Amanda.,
ни в ее документации не проводится подобного разграничения.
Формат файла достаточно понятен, поэтому мы представим файл в виде
одного большого фрагмента с комментариями к каждой секции. Начнем с
секции локальной информации, где определяется организация, в которой
установлена Amanda, оператор резервного копирования, каталоги журнальных
и других конфигурационных файлов, а также формат меток, записываемых
на ленту
##»################♦#######•»###############<#######•«*###»#*»##«####
# Локальные параметры
«#••»»»*« ###»####
org "Podunk Univ." # имя организации (для отчетов)
Главе 10. Резервное копирование
213
mailto "amanda"
dumpuser "amanda"
runrapes 1
tpohanger "chg-manual"
tapedev "/dev/rmt/Obn"
#	разделенный запятыми список операторов узла
#	пользователь, от имени которого создаются
#	архивы
#	число лент, задействуемых при одном запуске
#	программы amdump
#	сценарий управления устройством для смены
*	лент (предоставляется самой системой Amanda)
♦	используемое ленточное устройство
#	(Вез перемотки)
labelstr '"'Pcdunk- [0-9] [0-9] *5"	# регулярное выражение, определяющее
# названия меток; ему должны
# соответствовать все ленты
infofile ”/usr/adm/amanda/podunk/curinfo" * каталог базы данных
logdir ’’/usr/adm/amanda/podunk”	# каталог журнальных файлов
indexdir "/usr/adm/amanda/podunk/index“	# индексный каталог
Amanda считывает метку с каждого носителя и не применяет ленту, если
ее метка не совпадает с регулярным выражением, заданным в параметре
labelstr. Следовательно, все ленты должны быть помечены с помощью
программы amlabel до того, как они будут использованы для записи резервных
копий. Метки не могут содержать пробельных символов.
Определение схемы наименования зависит от системного администратора.
Например, вместо звездочки в регулярном выражении можно указывать
используемый алгоритм сжатия или тип компьютера, на котором выполняется
архивирование. В рассматриваемом примере ленты будут иметь метки
Podunk-01, Podunk-02 и т.д.
Если попытаться повторно использовать ленты до того, как будет
завершен нормальный цикл ротании, сервер откажется их принять. Такая
мера служит зашитой от случайной перезаписи лент.
Параметры схемы резервного копирования (как часто должна использо-
ваться та или иная лента, как часто нужно создавать архив уровня 0 для
каждой файловой системы, когда повышать уровень архива и т.д.) определены
во второй секции файла amandaxonf:
# Локальные параметры
dumpcycle 4 weeks
bumpdaуs 2
bumpsize 20 Mb
bumpmult 2
runspercycle 20
tapecycle 25 tapes
I число дней в нормальном цикле архивирования
#	минимальное число дней для каждого уровня
<	т минимальный размер (порог) для перехода
#	с уровня 1 на уровень 2
й порог = bumpsize * bumpmult'' (level-1)
#	число запусков программы amdurap в одном цикле;
#	в данном случае 20 «= 4 недели • 5 запусков в
#	неделю (только в будни)
#	число циклически меняемых леит;
#	в данном случае 25-4 недели * 5 запусков в
#	неделю (только ь будни) плюс еще несколько лент
#	на случай ошибок, чтобы запускаемая в этой
# ситуации программа amflush не затирала ленты,
#	заполненные в начале предыдущего цикла
214
Чость I. Основы одминистрировония
В системе Amanda архивирование не планируется строго по датам. Вместо
этого системе предоставляется общая информация о том, какая степень
избыточности допустима. После этого Amanda пытается распределить работу
на весь никл, чтобы леиты использовались эффективно и была обеспечена
их защита. Amanda каждую ночь пересчитывает график работ на основании
полученной в реальном времени информации о каждой клиентской файловой
системе. Точную схему архивирования невозможно предугадать заранее.
Цикл архивирования — это период времени, за который архивы уровня О
будут созданы как минимум один раз для каждой файловой системы. Чем
дольше цикл, тем более гибко можно осуществлять планирование, но вместе
с тем увеличивается число лент, которые нужно будет читать при восстанов-
лении данных. При наличии свободных лент Amanda может делать архивы
нулевого уровня чаще, чем того требует периодичность цикла.
Amanda предполагает, что архивы будут создаваться каждый день. Если
это не так, задайте в параметре runspercycle число дней в цикле.
В рассматриваемом примере архивы формируются только по будням, что
разумно, если кто-то должен вручную менять ленты.
Другое предположение, делаемое по умолчанию, заключается в том, что
одна лента пишется за один день (или за один “’проход”, согласно
терминологии Amanda). Если имеется укладчик или ленточный магазин, за
один раз может обрабатываться несколько лент. В этом случае требуется
дополнительная конфигурация.
Параметр lapecycle сообщает, сколько лент участвует в цикле. Мини-
мальное значение — это число проходов за один цикл, умноженное на число
лент, используемых при одном проходе, плюс еше несколько лент на случай
возникновения проблем. Если число лент хотя бы в два раза превышает
минимальное значение, то для каждой файловой системы будут созданы по
крайней мере два архива нулевого уровня.
Пороговые параметры позволяют контролировать, насколько большим
может стать инкрементный архив, прежде чем Amanda перейдет на следующий
уровень. Эти параметры вычисляются по определенным формулам, поэтому
для надежности лучше воспользоваться опцией bumpsize программы aniadniin.
Например, с учетом приведенных выше параметров программа сообщит такие
данные (предполагается, что конфигурационные файлы хранятся в каталоге
podunk):
t amadmln podunk bumpsize
Current bump parameters:
bumpsize 204BO KB - minimum savings (threshold) co bump level 1 -> 2
bumpdays 2	- minimum days at each level
bumpmult 2	- threshold = bumpsize * (level-1)“'bumpmult
Bump -> To Threshold
1	->	2	20480	KB
2	->	3	40960	KB
3	->	4	81920	KB
4	->	5	163840	KB
5	->	6	327680	KB
6	->	7	655360	KB
7	~>	8	1310720	KB
8	->	9	2621440	KB
После начального уровня 0 Amanda начинает делать архивы уровня 1.
Когда размер архива 1-го уровня превышает 20 Мбайт, осуществляется
Гпово 10 Резервное копировоние
215
переход на уровень 2. Если архив второго уровня переходит рубеж в 40 Мбайт.
Amanda перемешается на уровень 3 и т.д.
Необходимо правильно управлять этими параметрами, чтобы согласовать
требуемую степень избыточности с допустимой стоимостью лент. Слишком
большая избыточность приведет к высокой стоимости эксплуатации, а
слишком маленькая — к возможным потерям данных.
Остальная часть файла amanda.conf посвяшена параметрам, определяю-
щим степень использования сетевого канала, центрального процессора и
дисков, а также тип ленточного устройства, на которое будет осуществляться
запись, и типы архивируемых клиентских разделов.
нннннншн itf шиннин
# Параметры использования ресурсов
tapetype ЕХВ-8500	t тип ленты (см, ниже)
inparallel 4	♦ максимальное число процессов архивирования, # которые могут быть запущены одновременно
netusage 600 Kbps etimeout 300	# максимальный сетевой трафик для системы Amanda # число секунд, в течение которых можно ждать, # пока будет проведена оценка размеров архивов # для каждой файловой системы
holdingdisk hdl {
comment "main holding disk"
directory ”/dumps/amanda"	# точка монтирования буферного диска
use 8196 Mb	t сколько пространства на нем можно
* использовать
}
define capetype ЕХВ-8500 (
comment "Exabyte EXB-8500 drive on decent machine”
length 4200 mbytes
filemark 48 kbytes
speed 474 kbytes
1
Здесь показана конфигурация системы Amanda для ленточного накопи-
теля Exabyte 8500. Параметры типа ленты чрезвычайно важны и никогда не
должны подставляться наугад. Если имеющееся в системе устройство
резервного копирования не указано в файле amanda.conf входящем в
дистрибутив Amanda, можно попробовать найти его в файле docs/TAPETYPES
или по адресу
hnp://www.cs.columbia.edu/~sdossick/arnanda
Вы можете также запросить нужную конфигурацию в одной из телекон-
ференций, посвященных системе Amanda. Если ничего не подошло, восполь-
зуйтесь программой lapetype. входящей в комплект поставки. Она определяет
корректные параметры накопителя, заполняя тенту блоками размером
32 Кбайт. Но к ней нужно прибегать лишь в самом крайнем случае: на
некоторых устройствах эта программа выполняется очень долго (I или 2 дня)!
Последними в списке параметров указываются типы архивов, задающие,
какого рода данные (например, часто изменяемые, важные, статические)
могут содержаться в файловых системах. Для каждой клиентской файловой
системы должен быть назначен конкретный тип архива. Определение типа
216
Чость I. Основы ОД*ии-и1СтрирОВОИИЯ
также содержит информацию о том, какой алгоритм сжатия должен
применяться к архивируемым данным. Вот ряд примеров:
I####»#######»######* 1#1штшшн#шншннншнн
# Определения п?ипов архивов
Н#Й*#Н»»Н1ННН1Н*Н1ИШНННШНН»Н»Ш«МНИНШ»
define dumptype comp-user {
comment "partitions on reasonably fast machines’1
compress client fast
priority medium
define dumptype comp-root {
comment "root partitions on reasonably fast machines"
compress client fast
priority low
I
define dumptype nocomp-user {
comment "partitions on slow machines"
compress none
priority medium
}
define dumptype clone-user I
comment "partitions which should only get incremenrals"
compress client fast
skip-incr
priority medium
1
define dumptype comp-high-samba j|
comment "used for NT systems"
program "GNUTAR"
compress server fast
1
define dumptype dos-user [
comment "used for dos partitions that are always mounted"
program "GNUTAR”
compress client fast
I
Все эти типы предопределены в Amanda. Можно ссылаться на них
непосредственно или модифицировать по своему усмотрению, а также
создавать свои собственные типы. В поле comment содержится строка с
описанием того, для чего предназначены архивы данного типа.
Поле compress указывает на то, где должно производиться сжатие
данных: на клиентской машине, на сервере или нигде. Программа сжатия
(например, compress или gzip) задается при инсталляции системы Amanda.
Это поле может принимать следующие значения: попе, client best,
client fast, server best и server fast. По умолчанию используется
значение client fast.
Модификаторы best и fast сообщают о том, как сильно должны
сжиматься данные. Они соответствуют опциям программы gzip: --best и --fast.
Глово 10. Резервное копировоние
217
В нашем примере мы использовали только модификатор fast. В режиме
best сжатие происходит медленнее, а результат ненамного лучше.
Поле holdingdisk может иметь два значения: yes и по. Оно указывает,
должен ли буферный диск использоваться для временного хранения архива.
Эту опцию можно отключить, если архивируется сам буферный диск. По
умолчанию установлено значение yes.
Поле maxdvnips задает максимальное число архивов, которые могут
одновременно создаваться на клиентской машине. Значение по умолчанию — I.
но его можно увеличить, чтобы повысить производительность, если имеется
мощный сервер и сетевой канал с хорошей пропускной способностью.
Поле priority указывает на то. насколько важным является архив. Оно
может принимать значения low. medium и high. Второе установлено по
умолчанию. Если не хватает лент для записи всех запланированных архивов,
то низкоприоритетные архивы просто пропускаются. При обнаружении
ошибок ленты Amanda пытается перенести высокоприоритетные архивы на
буферный диск. Если там достаточно места, туда же помещаются и
низкоприоритетные архивы.
Мы рекомендуем за каждым приоритетом закрепить свой тип архива.
Начальные каталоги должны архивироваться с высоким приоритетом. Сред-
ний приоритет подходит для локальных программных пакетов (например,
каталог /usr/local), а низкий приоритет — для системных файлов, которые
редко изменяются.
Поле program определяет, какую программу архивирования следует
использовать: dump или gnutar. По умолчанию принимается первая, и обычно
это лучший выбор.
Оиния skip-full указывает серверу Amanda на необходимость пропус-
тить файловую систему в случае архива уровня 0. Ее можно устанавливать,
если архивы нулевого уровня создаются вне системы Amanda
Опция sk.ip-incr заставляет сервер Amanda пропустить все архивы
кроме тех. которые имеют нулевой уровень. Ее можно устанавливать в тех
конфигурациях, когда должны создаваться полные архивы.
Файл disklist
Файл anianda.conf сообщает о том. как создавать архивы, но не задает
файловые системы, подлежащие архивированию. Эта информация хранится
в файле disklist. Каждой клиентской файловой системе назначается один из
типов архивов, определенных в файле anianda.conf
#	<»###* и #н#г#нт
#	клиент раздел	тип архива	I точка монтирования
# сервер архивов
ocean	sdOa	comp-root	It	/
ocean	sdOg	comp-user	1	/use
ocean	sdOd	comp-user	f	/var
ocean	sdOh	comp-high	#	/amanda
#	NT-раздел пользователя lorien, смонтированный
#	с помощью системы Samba на компьютере ocean
ocean	//lorien/c$	comp-high-samba	# c:\
#	прототип
squish	ycOtOdOsO	comp-high	# I
218
Чость I. Основы одминистрироеония
squish	ycOtOdOsfi	comp-high	#	/usr
squish	yc0t0d0s3	comp-high	#	/vai
squish	yc0t0d0s7	comp-high	#	/local
t клон				
zamboni	cOtOdOsO	clone-user	t	/
zamboni	cOtOdOsb	clone-user	#	/usr
zamboni	c0c0d0s3	comp-root		/var
zamboni	C0t0d0s7	comp-user	*	/local
# медленный	ПК			
fuzz	sdla	nocomp-high	-	/
fuzz	sdlf	nocomp-high	#	/local
fuzz	sdle	nocomp—high	»	/usr
fuzz	sdld	nocomp-high	#	/var
fuzz	/dos	dos-user	#	/dos
Первый столбец содержат сетевые имена клиентских компьютеров,
разделы которых архивируются. Во втором столбце приведен список дисковых
разделов. Можно указывать либо имя устройства, либо точку монтирования.
Обратите внимание иа то, что буферный диск сервера архивов (ocean)
не упомянут в файле disklist. В нашем случае его архивировать не нужно,
так как он содержит лишь образы архивов, записываемые системой Amanda.
Если бы на нем хранились журнальные файлы или другая важная информа-
ция, его следовало бы включить в список, указав в третьем столбце тип
holdingdisk.
Опция skip-incr (включенная в определение типа clone-user)
подходит для архивирования клонов машины-прототипа. На нашем узле для
каждой архитектуры имеется одна маши на-прототип, которая клонируется иа
другие машины с аналогичной архитектурой. Поскольку корневые разделы
клонов те же, что и у прототипа, мы не тратим ленты на их архивирование
каждую ночь.
Тем не менее, у каждого клона есть свои уникальные файлы (например,
файлы конфигурации в каталоге /etc), поэтому один раз за цикл архивиро-
вания мы все же создаем архив уровня 0. В разделе /таг на машине zamboei
содержатся почтовые каталоги пользователей, вследствие чего данную фай-
ловую систему необходимо архивировать каждую ночь.
На сервере архивов мы установили программу smbtar системы Samba,
чтобы можно было создавать резервные копии файловых систем Windows NT
В рассматриваемом примере архивируется диск С машины lorien. Обратите
внимание на то, что в файле disklist упомянут клиент ocean, а не lorien. Когда
для доступа к файловой системе используется система Samba, клиентом
Amanda должна быть не NT-машина, а UNLX-машина, на которой располо-
жена программа smbtar. (Раздел /dos машины fuzz не задан подобным образом,
так как он всегда смонтирован и доступ к нему не осуществляется посредством
Samba.) Amanda различает разделы Samba и обычные точки монтирования
(такие как /usr и /dos) по количеству символов косой черты в начале имени:
два у раздела Samba и один у точек монтирования.
Информация о системе Samba дана в главе 26.
Журнальные файлы
Для каждого архива на сервере Amanda создаются два журнальных файла.
Первый называется amdoinp.n, где п — число дополнительных запусков
Глово 10 Резервное копировоние
219
Amanda с момента создания журнального файла. Этот файл содержит
текстовое описание действий, связанных с планированием, которые предпри-
няла система Amanda. Второй файл именуется iog.dazna.n, где дата — это
дата создания архива, ал — число архивов, уже созданных в тот день.
Отладка
После каждого запуска Amanda создает отчет по итогам резервного
копирования и посылает его по электронной почте главному оператору. В
отчет включается информация о количестве использованных леит, успешно
заархивированных файловых системах и произошедших ошибках. Вот пример
такого отчета (он создан на основании конфигурации, в которой применяется
не тот файл disklist, что показан выше):
То: amanda@ocean
Subject: Podunk, Univ. AMANDA MAIL REPORT FOR September 1, 1999
These dumps were to tape Podunk-481
Tonight's dumps should go onto 1 tape: Podunk-482.
FAILURE AND STRANGE DUMP SUMMARY:
fuzz sdla lev 0 FAILED [no estimate or historical data]
taper: FATAL syncpipe_get: w: unexpected EOF
STATISTICS:	Total	Full	Daily	
Dump Time (hrs:min)	3:02	0:36	0:04	(0:34 start, 1:49 idle)
Output Size (meg)	2954.6	2666.8	287.8	
Original Size (meg)	7428.1	6292.5	1135.5	
Avg Compressed Size (%)	39.8	42.4	25.3	
Tape Used (%)	70,5	63.5	7.0	(level:Odisks ...)
Filesystems Dumped	18	8	10	(1:8 2:2)
Avg Dump Rate (k/s)	105.3	124.5	43.4	
Avg Tp Write Rate (k/s)	1254.2	1251.8	1276.9	
NOTES
planner: Adding new disk zamboni:cOtOdOs?.
driver: WARNING: /dumps/amanda: 8550400 KB requested, but only
1035113 KB available.
planner: Forcing full dump of squishy:cOtOdOsO as directed.
planner: Request to fuzz timed out.
planner: Incremental of ocean:sdOh bumped to level 2.
driver: going into degraded mode because of tape error.
Одна из самых распространенных проблем заключается в том, что иногда
Amanda не может записать архив на ленту. Это может случиться, если в
накопитель вставить неправильную ленту или если в процессе записи
возникла ошибка ленты (в показанном примере это произошло с клиентом
fuzz). В любом случае Amanda записывает резервные копии иа буферный
диск. Чтобы сбросить буферные архивы на ленту, вставьте в накопитель
правильную ленту и запустите программу amflush.
220
Чость I Основы одминистри ровен ия
Для диагностики других проблем нужно просмотреть либо журнальные
файлы на сервере, либо файлы отладки на клиенте. Местоположение
журнальных файлов указано в файле anianda.conf. Файлы отладки находятся
в каталоге /tmp/amanda, если система Amanda компилировалвсь с опцией
—with-debugging (она задана по умолчанию).
Приведенное выше почтовое сообщение создается на основании жур-
нальных файлов. Вот текст файла amdump.n:
SETTING UP FOR ESTIMATES...
dumper: pid 18199 executable dumper version 2.4.Ipl, using port 791
driver: started duripersetup_estimates: ocean:sdOd: command 0, options:
last_level 1 next_levelO 6 level_days 16
getting estimates 0 (20023) 1 (2735) -1 (-1)
zamboni:cOtOdOsO lev 1 skipped due to skip-incr flag
planner: SKIPPED zamboni cOtOdOsO 1 (skip-incr]
GETTING ESTIMATES...
got results for host ocean disk sdOa: 0 -> 53797K, 1 -> 1797K, -1 -> -IK
got results for host ocean disk sdOd; 0 -> 19695K, 1 -> 2696K, -1 -> -IK
ANALYZING ESTIMATES...
pondering ocean:sdOd... next_levelO 6 last_level 1 (not due for a
full dump, picking an incr level)
Ниже показан файл log. 19990901.0.
START planner date 19990901
START driver date 19990901
INFO planner Adding new disk depot:dsk/dl.
SUCCESS planner zamboni COtOdOsO 1 [skipped: skip-incr]
WARNING driver WARNING: /dumps/amanda: 8550400 KB requested, but only
1035113 KB available.
START taper datestamp 19990901 label Podunk-481 tape 0
FAIL planner fuzz sdla 0 [no estimate or historical data]
STATS driver startup time 2019.456
SUCCESS dunper ocean sdOa 0 [sec 418.311 kb 25088 kps 59.97 orlg-kb 58087]
SUCCESS dumper ocean sdOd 1 [sec 15.867 kb 800 kps 50.42 orig-kb 2719]
SUCCESS taper ocean sdOa 0 [sec 53.366 kb 25088 kps 474.612 [wr: writes 2
rdwalt 0.000 wrwait 0.032 fliemark 38.332)]
SUCCESS taper ocean sdOd 1 [sec 6.345 kb 800 kps 133.3 [wr: writes 1
rdwalt 1.470 wrwait 0.356 filemark 2.637}]
STRANGE dumper ocean sdOh 1 [sec 82.435 kb 33.4 kps 0.4 orig-kb 155.0]
aendbackup: start [ocean:sd0h level 1 datestamp 19990901]
I DUMP: Date of this level 1 dump: Wed Sep 01 23:47:54 1999
I DUMP: Date of last level 0 dump: Mon Aug 30 23:43:23 1999
1 DUMP: Dumping Zdev/rsdOh t/amanda) to standard output
| DUMP: mapping (Pass I) [regular files]
I DUMP: mapping (Pass II) [directories]
? DUMP: (This should not happen) bread from /dev/rsdOh [block 64] :
count-8192, got—1
I DUMP: estimated 38 blocks (19KB) on 0.00 tape(s).
I DUMP: dumping (Pass III) [directories]
Главе 10 Резервное копирование
221
I DUMP: dumping (Pass IV) [regular files]
I DUMP: level 1 dump on Wed Sep 01 23:47:54 1999
| DUMP: 310 blocks (155KB) on 1 volume
I DUMP: DUMP IS DONE
sendbackup: size 15B720
sendbackup: end
Каждая строка SUCCESS dumper означает, что архив был записан в
буферный диск, а строка SUCCESS taper — что архив был помещен на
ленту. Строка STRANGE dumper говорит о том, что система Amanda
обнаружила ошибку при выполнении команды dump. В случае ошибки Amanda
сохраняет результаты работы в журнальном файле (перед строками, свиде-
тельствующими об ошибке, ставится знак вопроса), а также включает их в
почтовое резюме.
Еще одна проблема, с которой часто сталкивается Amanda, заключается
в невозможности вычислить размер архива для клиентской файловой системы
В этой ситуации нужно в первую очередь проверить доступность клиента по
сети и правильность конфигурирования соответствующей клиентской копии
Amanda. Можно также просмотреть файлы отладки в каталоге /tmp/amanda
на клиентском компьютере Все клиентские программы Amanda при каждом
своем запуске записывают в этот каталог отладочную информацию.
Когда Amanda не может оценить размер архива, просмотрите отладочный
файл программы sendsize. Эта программа анализирует результаты работы
команды dump и ищет строку, в которой сообщается о размере. Если строка
не найдена, Amanda выдает сообщение [по estimate]. Вот пример файла
sendsize.debug:
sendsize: getting size via dump for c0t0d0s3 level 1
sendsize: running "/usr/ccs/bin/dump Isf 100000 - /dev/dsx/cOtOdCsj"
DUMP: Date of this level 1 dump: Wed Sep 01 21:59:36 1999
DUMP: Date of last level 0 dump: Mon aug 30 05:08:33 1999
DUMP: Dumping /dev/dsk/c0t0d0s3 (/var) to standard output
DUMP:	mapping	(Pass	I)	[regular files]
DUMP:	mapping	(Pass	II)	[directories]
DUMP:	mapping	{Pass	II)	[directories]
DUMP:	mapping	(Pass	II)	[directories]
DUMP: estimated 7150 blocks on 0.00 tape(s).
DUMP: mapping {Pass III) [directories]
calculating for amname ’cOtOdOsO’, dirname */local•
sendsize: getting size via dump for c0t0d0s7 level 0
sendsize: running "/usr/ccs/bin/dump Osf 100000 - /dev/dsk/cOtCdOs7"
DUMP: Cannot open/stat /dev/rdsk/c0t0d0s7. Permission denied
(no size line match in above dump output)
В данном случае очевидно, что необходимо изменить права доступа к
файлу /dev/rdsk/c0t0d0s7.
Если проблему не удается разрешить путем просмотра журнальных файлов
или документации к системе Amanda, обратитесь к архивам телеконференций
Amanda по следующим адресам:
http://www.egroups.com/lisi/amanda-users
hitp;//www.egroups.com/list/amanda-hackers
222
Часть I. Основы администрирования
Восстановление файла из резервной копии
Для восстановления архивов Amanda необходимо воспользоваться про-
граммами amadmin и amrestore Рассмотрим конкретный пример.
Предположим, имеется пользователь, который удалил целый каталог и
хочет восстановить его. Первый шаг заключается в нахождении лент на
которых был заархивирован каталог. Для этого нужна следующая информация:
• имя компьютера и раздела, где располагался каталог;
•	полное путевое имя каталога;
•	дата удаления каталога или его повреждения;
•	дата, когда каталог был последний раз модифицирован.
Даты определяют диапазон лент, содержащих каталог в том состоянии,
в котором нам может понадобиться его восстановить. Допустим, что требуется
восстановить каталог в разделе /local иа компьютере zamboni; он был
модифицирован 5-го октября и удален 12-го октября. Программа amadmin
определит, какие ленты нужны:
% amadmin podunk find zamboni c0t0dOa7
date	host	disk	Iv	tape	file	status
2000-01-26	zamboni	c0t0d0s7	1	Podunk-795	33	OK
2000-01-25	zamboni	cOtOdOsT	1	Podunk-794	41	OK
2000-01-23	zamboni	c0t0d0s7	0	Podunk-792	9	OK
2000-01-22	zamboni	c0t0d0s7	1	Podunk-791	32	OK
1999-10-13	zamboni	c0t0d0s7	1	Podunk-685	38	OK
1999-10-12	zamboni	c0t0d0s7	1	Podunk-684	37	OK
1999-10-11	zamboni	c0t0d0s7	1	Podunk-683	39	OK
1999-10-10	zamboni	cOtOdOs?	1	Podunk-682	72	OK
1999-10-09	zamboni	c0t0d0s7	1	podunk-681	44	OK
1999-10-08	zamboni	cOtOdOs?	1	Podunk-680	88	OK
1999-10-07	zamboni	cOtOdOa?	1	Podunk-518	35	OK
1999-10-06	zamboni	c0t0d0s7	1	Podunk-517	33	OK
1999-10-05	zamboni	cOtOdOsT	1	Podunk-516	33	OK
1999-10-04	zamboni	cOtOdOs?	1	Podunk-515	51	OK
1999-10-03	zamboni	c0t0d0s7	1	Podunk-514	16	OK
1999-10-02	zamboni	c0t0dds7	1	Podunk-513	19	OK
1999-10-01	zamboni	cOtOdOs?	1	Podunk-512	36	OK
1999-09-30	zamboni	cOtOdOs7	1	Podunk-511	15	OK
1999-09-29	zamboni	cOtOdOs?	1	Podunk-510	78	OK
1999-09-28	zamboni	cOtOdDsT	0	Podunk-509	99	OK
Опция find заставляет программу amadmin просмотреть каждый журналь-
ный файл, перечисленный в файле конфигурации amanda.conf в поисках
машины и раздела, которые указаны в качестве аргументов. Чтобы восста-
новить искомый каталог, необходима лента Podunk-509 с архивом уровня О
и лента Podunk-683 с архивом уровня 1, созданным за день до удаления
каталога. Для архива уровня I теоретически можно взять любую ленту,
записанную после пятого числа, так как пользователь не модифицировал
каталог между 5-м и 12-м октября. Но лучше все же воспользоваться самой
последней лентой, ведь воспоминания пользователей могут быть такими
ненадежными!
Далее необходимо вызвать программу amrestore, которая выполнит
собственно восстановление данных. Начнем с ленты Podunk-509. так как на
Глава 10. Резервное копирование
27
ней находится архив нулевого уровня. После вставки ленты в накопитель
выполним команду
% amzaatoza -р /dav/rmt/Obn zamboni c0t0d0c7 | restore if -
которая отыщет нужную запись и начнет интерактивный сеанс восстановле-
ния. Программа amrestore просматривает каждый образ архива на ленте, пока
не находит нужный, после чего направляет этот архив в стандартный
выходной поток, передаваемый команде restore. Далее процесс осуществляется
так, как было описано в параграфе 10.4. Завершив извлечение архива
уровня 0, повторяем всю процедуру для архива уровня 1.
Программа amrestore распознает нужный архив благодаря тому, что
система Amanda помещает перед каждым архивом заголовок размером
32 Кбайт, в котором записано, откуда поступил этот архив и какими
средствами он был сжат. Если применялось сжатие, программа автоматически
пропускает образ архива через модуль декомпрессии.
Просмотр всех заголовков может занять много времени, так как не
исключено, что придется пройти через сотни файловых систем. Но из
результатов работы программы amadmin мы уже выяснили, что нужно искать,
поэтому не надо заставлять программу amrestore выполнять ту же самую
работу повторно. Можно просто ввести команду mt fsf, чтобы перемотать
ленту, прежде чем запускать программу amrestore.
Команда restore должна выполняться на компьютере с той же архитек-
турой и операционной системой, где был создан исходный архив. Amanda
ничего не знает о внутреннем содержимом архива и не может защитить
пользователя от межплатформенных несовместимостей.
Если журнальные файлы Amanda были удалены, всегда можно просмот-
реть наклейки на лентах, чтобы определить их содержимое. Но что если будет
удалена сама программа amrestore? Не пугайтесь: эта программа делает не
более, чем знакомая нам программа dd. Если просмотреть заголовок архива,
то можно обнаружить в нем инструкции по его восстановлению. К примеру,
вот текст заголовка, полученный с ленты, содержащей архив уровня 0;
#	mt -f /dev/rmt/ОЬп fsf 99
#	dd if"/dsv/xrat/Obn b««32k count^l
AMANDA : FILE 19990920 zamboni cOtOdOsl lev 0 comp . gz
To restore, position tape at start of file and run;
dd lf-<tape> ba«32k skip-1 I gzcat I restore ...f -
1+0 records in
1	+0 records out
Существующие альтернативы: другие открытые пакеты
резервного копирования
В Internet доступно несколько других бесплатных пакетов резервного
копирования. Перечислим некоторые из них:
•	BURT — утилита резервного копирования и восстановления, написанная
на Tcl/Tk 8.0.
•	CD Backup Linux — автоматизированная утилита, предназначенная для
компакт-дисков CD-R.
•	hostdump.sh — быстрая утилита резервного копирования.
224
Чость I. Основы ОДМИНИСТрирОВОНИЯ
•	К Backup — утилита резервного копирования с графическим интерфейсом,
обладающая рядом интересных возможностей.
•	star — более быстрая версия программы tar Имеет ряд дополнительных
особенностей, например, может автоматически переставлять байты. Не
разрушает существующие файлы при восстановлении.
10.9.	Коммерческие системы резервного копировония
Нам бы всем хотелось, чтобы UNIX была единственной операционной
системой в мире, но. к сожалению, это не так. Анализируя различные
коммерческие системы резервного копирования, необходимо учесть их
способность работать с другими операционными системами. Большинство
современных продуктов позволяет включать рабочие станции Windows и
Macintosh в схему резервного копирования, осуществляемого в UNIX.
Зашишать от сбоев нужно также портативные компьютеры пользователей
и другие компьютеры, не постоянно присутствующие в сети. Коммерческая
программа должна правильно обрабатывать ситуации, когда архивируются
идентичные файлы с каждого ноутбука. В конце концов, сколько резервных
копий coniniand.com вам нужно?
Поскольку система Amanda идеально подходит для наших потребностей,
мы не имеем особого опыта работы с другими продуктами. Мы опросили
нескольких знакомых из разных коммерческих организаций на предмет их
впечатлений от систем, которыми пользуются они. Ниже представлены их
комментарии.
ADSKVTSM
Этот продукт был разработан компанией IBM и впоследствии приобретен
фирмой Tivoli. Сегодня он носит название Tivoli Storage Manager 1TSM —
менеджер систем хранения компании Tivoli) и представляет собой систему
управления данными, поддерживающую также резервное копирование. До-
полнительную информацию можно получить на Web-узле www.tivoli.com.
Достоинства:
•	поддержка со стороны IBM;
•	удачная ценовая политика;
•	низкий процент сбоев;
•	использование дисковых кэш-буферов. что удобно при работе с медлен-
ными клиентами;
•	работа с клиентами Windows;
•	великолепная документация (за отдельную цену).
Недостатки:
•	плохой графический интерфейс;
•	каждые два файла занимают 1 Кбайт в базе данных;
•	сложность постоянно возрастает.
Veritas
Компания Veritas продает системы резервного копирования для различных
платформ. Информацию о них можно получить на Web-узле www.veritas.com.
Гпово 10. Резервное копировоние
225
Достоинства:
•	приятный графический интерфейс;
•	прямое взаимодействие с файловыми серверами Network Appliance;
•	удобная инсталляция в UNIX;
•	возможность записи лент в формате gnutar;
•	централизованная база данных, но поддерживается только распределенное
резервное копирование.
Недостатки:
•	ряд программных ошибок,
•	отсутствие поддержки DHCP-клиентов (возможно, к настоящему моменту
ситуация изменилась);
•	неудачная ценовая политика,
•	недостаточная поддержка NT-систем.
legato
Система резервного копирования Legato продается непосредственно
компанией Legato, но также поставляется ведущими компьютерными произ-
водителями, например Compaq. Дополнительную информацию можно полу-
чить на Web-узле www.legalo.com.
Достоинства:
•	приятный графический интерфейс;
•	очень разумная цена;
•	автоматическая рассылка почтовых сообщений пользователям с уведом-
лением о статусе резервного копирования.
Недостатки:
•	некоторые проблемы с поврежденным индексным файлом;
•	не рекомендуется использовать, когда число клиентов превышает 100;
•	отсутствие поддержки гетерогенных клиентов (несмотря на рекламные
заявления);
•	невозможность работы с крупными файловыми системами;
•	плохая техническая поддержка.
Прочие программы
Уже упоминавшийся Кертнс Престон, автор книги по резервному
копированию, вышедшей в издательстве O’Reilly, ведет очень полезную
Web-страничку, посвященную вопросам резервного копирования (программам
зеркального дублирования дисков, работе с файловыми системами, удален-
ному резервному копированию и т.д.). Помимо прочей информации там
размещена большая таблица, в которой перечислены все известные програм-
мы и системы резервного копирования. Мы рекомендуем посетить эту
страничку по адресу www.backupcentral.com и прочитать указанную ниже
книгу.
10.10.	Рекомендуемся литература
• Preston. Curtis W. Unix Backup and Recovery. O’Reilly, 1999.
226
Чость I Основы администрирований
7 7 Система SysIод
- • и журнальные файлы
Система учета, ядро, различные утилиты — все эти программы выдают
данные, которые регистрируются и. в конце концов, попадают на далеко не
безразмерные диски. “Срок полезной службы” большинства данных ограни-
чен. поэтому их нужно группировать, упаковывать, архивировать и. наконец,
выбрасывать.
11.1.	Методики оброботки журнольных файлов
У каждой организации свои принципы работы с журнальными файлами.
Вот некоторые общепринятые схемы
•	немедленное уничтожение всей регистрационной информации,
•	сброс журнальных файлов в исходное состояние через определенные
промежутки времени;
•	повторное использование журнальных файлов (данные хранятся в течение
фиксированного периода времени);
•	сжатие данных и архивирование их на ленту иди постоянные носители
других гнпов.
Правильный выбор стратегии зависит от того, сколько имеется дисковой
памяти и какое внимание уделяется вопросам зашиты. Даже те пользователи,
у которых дискового пространства и избытке, должны учитывать вероятность
неприемлемого разрастания файлов регистрации.
Независимо от выбранной схемы процедуру управления журнальными
файлами необходимо автоматизировать с помощью демона сгоп. Общие
сведения об этом демоне даны в главе 9.
Уничтожение журнальных файлов
Не рекомендуем удалять всю регистрационную информацию. Орга низа
ции. стадиивающиеся с проблемами безопасности, всегда могуч обнаружить
Глово 1 I. Системе Sysiog и журнопьные фойлы
227
в учетных данных и журнальных файлах важные доказательства имевших
место взломов. Кроме того, журнальные файлы весьма полезны как способ
привлечения внимания администратора к проблемам, возникающим в аппа-
ратных и программных средствах. В общем случае прн наличии достаточною
объема дискового пространства данные следует хранить как минимум месяц,
а затем уничтожать На практике именно столько времени может учти иа
выяснение того, что в организации завелся хакер и нужно просмотреть файлы
регистрации. Если требуется совершить возврат в более далекое прошлое,
можно восстановить старые файлы с архивных лент.
Некоторые администраторы позволяют журнальным файлам разрастаться
до тех пор. пока их размер не начнет вызывать раздражение, после чего
файлы обнуляются. Это, конечно, лучше, чем вообще не хранить регистра-
ционные данные, но такой метод не гарантирует, что элементы журнального
файла сохранятся в течение какого-то определенного промежутка времени
Кроме того, средний объем используемой дисковой памяти при такоп
“стратегии” может быть выше, чем прн других методах регистрации.
Повторное использование журнальных файлов
Многие фирмы не архивируют файлы регистрации на ленту, а ежедневно
сохраняют регистрационную информацию на диске, иногда в упакованном
виде. Эти файлы хранятся в течение определенного периода времени, а затем
удаляются. Если дискового пространства достаточно, то удобнее держать
журнальные файлы в неупакованном виде, чтобы в них можно было быстро
проводить поиск с помощью команды grep.
В нашей организации мы выделяем под файлы регистрации раздел диска
(/var/log) на центральной регистрационной машине. Данные за последнюю
неделю не сжимаются, а остальная информация сжимается с помощью
программы gzip.
Один из наиболее распространенных методов реализации этой стратегии
называется ротация. Ротационная система предполагает хранение резервных
файлов с разбивкой по времени создания: файлы однодневной давности,
двухдневной и т.д. Каждый день файлы переименовываются, в результате
чего более старые данные сдвигаются в коней цепочки. Если, например,
журнальный файл называется logfile. то резервные копии могут носить имя
logfile. 1, logfilc.2 и т.д. Когда к организации хранится недельный комплект
данных, то последняя копия будет называться logfile.7, а файла logfile.8 уже
не будет Каждый день данные в файле logfile.7 пропадают, так как иа их
место записываются данные из файла iogfiie.6.
Предположим, что с файлом работают ежедневно, а его содержимое
нужно хранить в течение трех дней. Соответствующая стратегия ротации будет
реализована с помощью следующего сценария;
t!/bin/sh
cd /var/log
mv logfile.2 logfile.3
mv logfile.1 logfile.2
mv logfile logfile.1
cat /dev/null > logfile
chmod 600 logfile
Для некоторых журнальных файлов большое значение имеет информация
о принадлежности. Возможно, понадобится запускать сценарий ротации
228
Честь 1 Основы ОДминиСтрирОВОниР
средствами демона cron от имени владельца журнальных файлов, а не в
качестве пользователя root, или добавить в сценарий команду chown.
В некоторых организациях журнальные файлы классифицируются по
датам, а не по порядковым номерам, например logfile.tues или Ioglile.aug26.
Такую систему имен немного труднее реализовать, но усилия окупятся, если
необходимость обращаться к старым журнальным файлам возникает довольно
часто. Вот самая простая реализация:
nw logfile logfxle.'date +%¥.%m.%d’
Теперь с помощью команды is можно будет выводить список журнальных
файлов в хронологическом порядке.
Некоторые демоны все время держат свои журнальные файлы открытыми.
Из-за особенностей работы файловой системы вышеописанный сценарий с
такими демонами использовать нельзя: вместо того чтобы направляться во
вновь созданный файл logfile, данные регистрации начнут таинственным
образом исчезать. Активная ссылка (обращение из какого-либо процесса) па
исходный файл позволяет ему оставаться в системе даже после того, как был
удален соответствующий элемент каталога и создан новый файл с таким же
именем. Файл не исчезает (и занимаемое им дисковое пространство не
используется системой) до тех пор, пока не будут закрыты все указывающие
на него ссылки. Для того чтобы инсталлировать новый журнальный файл,
нужно либо послать демону сигнал, либо уничтожить и перезапустить его.
Вот пример, в котором используется сжатие журнальных файлов и
посылается сигнал демону:
t!/bin/sh
cd /var/log
mv logfile.2,gz logfile.3.gz
rov logfile.l.gz logfile.2.gz
mv logfile logfile.1
cat /dev/null > logfile
kill -сигнал pid
gzip logfile.1
Программа gzip сжимает файл logfile. 1, вследствие чего к нему добавляется
расширение gz. В поле сигнал указывается соответствующий сигнал для
программы, записывающей данные в журнальный файл; поле pid — это
идентификатор ее процесса. Сигнал жестко задается в сценарии, а вот
идентификатор процесса нужно вычислять динамически: либо путем чтения
специального файла (например, /etc/syslog. pid; см. ниже), либо филыруя
результаты работы программы ps В некоторых системах имеется стандартная
команда (такая как skill, написанная Альбертом Каталаном (Albert Cahalan).
или kiilall, написанная Вернером Альмсбергером (Wemer Almesberger); обе
входят в состав Red Hat), упрощающая типичную цепочку команд ps-grep-kill*
Каждая программа ведет себя в плане регистрации по-своему Для того
чтобы определить, какие процедуры нужны в каждой конкретной ситуации,
обратитесь к той главе, где описана та или иная программа (или к
интерактивному руководству).
Во многих системах имеется готовый сценарий ротации, запускаемый
демоном сгоп. В любом случае лучше пользоваться стандартными средствами.
Будьте внимательны: в Solaris и HP-UX также есть команда kiilall, но она выполняет
совершенно иные действия. Чтобы добиться требуемого результата, применяйте команду
pkill
Глове 11 Системе Syslog и журнольные файлы
229
Особенности работы с журнальными файлами в различных операционных
системах описаны в параграфе 11.4.
Если в системе нет модуля ротации, советуем воспользоваться Perl-сце-
нарием roU, написанным Маттом Сегуром (Matt Segur) и Майклом Берн-
стайном (Michael Bernstein). Он доступен на Web-узле www.admin.com.
Архивирование журнальных файлов
В некоторых организациях необходимость архивирования всех учетных
данных и журнальных файлов обусловлена характером их деятельности
Архивирование проводится, например, в ожидании предстоящей ревизии
В таких случаях журнальные файлы нужно сначала скопировать на диске
методом ротании, а затем переписать на ленту или другие постоянные
носители. Данная схема позволяет уменьшить частоту создания резервных
копий на лентах.
Архивы журнальных файлов можно хранить в составе регулярных
резервных копий либо на отдельных лентах. Второй вариант более накладный,
но он требует меньше усилий по составлению документации и дает
возможность циклически использовать архивные ленты, не затрагивая резерв-
ные копии журнальных файлов. В подобном случае мы рекомендуем написать
сценарий автоматизации резервного копирования и применять программу tar
0 Подробную информацию о резервном копировании можно найти в главе 10.
11.2.	Поиск журнальных файлов
Операционную систему UNIX часто критикуют за противоречивость. Гак
и есть на самом деле, загляните, например, в каталог журнальных файлов,
и вы наверняка найдете несколько файлов с именами наподобие mailing,
файлы вида ftp.log и даже что-нибудь вроде IpNet, Ipd-errs или consolcjog
Мало того, что журнальные файлы имеют случайные имена, так они еше и
разбросаны по различным каталогам и файловым системам.
В этом параграфе мы попытаемся помочь читателям найти все файлы,
которые незаметно ‘‘поедают” диск, а также предложим кое-какие рекомен-
дации. Кроме того, будет рассказано, где обычно размещаются журнальные
файлы в каждой из четырех тестовых систем.
Для того чтобы найти журнальные файлы, просмотрите тексты стартовых
сценариев системы (/etc/rc*, /etc/rc.d/* или /etc/mit.d/*) и проверьте,
включается ли регистрация при запуске демонов. В настоящее время
большинство программ выполняет регистрацию посредством системы Sysiog.
которая рассматривается в параграфе 11.5. Загляните в текст конфигурацион-
ного файла /etc/syslog.conf системы Sysiog, чтобы узнать, куда направляются
данные.
0 Формат файла syslog.conf описан в параграфе П.5.
В табл. 11.1 приведена информация о наиболее часто используемых
журнальных файлах. Указано, в частности, следующее:
•	имена журнальных файлов, подлежащих архивированию или какой-либо
другой обработке;
•	программа, создающая каждый из этих файлов;
•	информация о том, как задается имя файла;
	частота контроля, которую мы считаем приемлемой;
•	владелец и группа, которым должен принадлежать файл;
•	описание содержимого файла
230
Чость I. Основы одминисгрировония
Таблица 11.1. Журнольные фойлы
			Частота1	> > I J j Содержимов/нозначение
а. Файл	Прогроммо			
Стандартные системные файлы				
messages	различные	s	M 1	? Часто это основной системный журнальный файл
sysiog	различные	s	M 1	Часто это основной системный журнальный файл
shutdownlog	shutdown	s	M I	< Причины выполнения команды shutdown
sulog	su	H	M 1	Регистрационные сообщения команды su
authlog	sir	s	M 1	£ Авторизационные сообщения
mqueue/swlog	scndmail	F	W 1	R Журнальный файл электронной почты
fip.lQg	ftpd	s	W 1	< Журнальный файл FTP-соединений
gatediog	gated	CS1 2 3	W 1	R Сообщения демона сетевой маршрутизации
Учетные файлы				
acct	ядро	C	D 1	R Учет процессов в BSD (двоичный файл)
pacct	ядро	c	D 1	К Учет процессов в Syaem V (двоичный файл)
wimp4	login	H	M 1	R Учет времени соединения (двоичный файл)
Ipacct	Ipd	F	M 1	0 Учетная информация принтера в BSD
Ipd-cns	Ipd	F	W 1	3 Ошибки принтера в BSD
aculog	tip, UUCP	H	M 1	U Учетная информация по модемным соединениям.
				которые инициируются системой
fd21og	runacct	F	M 1	К Ошибки учета в System V
Разное				
news/news	in nd	H	D 1	N Ошибки и транзакции телеконференций
news/’log	nnrpd	S	W [	М Деятельность участников телеконференций
majordomo.	Majordomo	F	M 1	R Журнальный файл диспетчера групп новостей
log				
sudo log	sudo	S	M 1	R Регистрационные сообщения программы sudo
tcpJog	tepd	s	W 1	R Информация о ТСР-соединениях
XOmsgs	xll	II	M 1	R Журнальный файл сервера X Windows
xdm-cnois	xdm	F	M 1	R Ошибки программы управления Х-дисплеем
httpd/’ log	httpd	F	W 1	R Журнальные файлы Wcb-сервсра
1 Столбец “Где” (в котором задается имя файла): S = Sysiog, Н = встроенное имя, F =
конфигурационный файл, С = командная строка.
Столбец “Частота” (рекомендуемая частота проверки): D = ежедневно, W = еженедельно,
М = ежемесячно.
Столбец “Владелец" (владелец и группа файла). R == root/system. U = uncp/daemon, N =
news/news, D - daemon/daemon.
2 Команды passwd, login и shutdown тоже записывают информацию в этот файл.
3 В версии 2.1 демона имя файла задается в командной строке; в последующих версиях
используется система Sysiog.
4 Иногда создается несколько в ином формате под именем wtmpx.
Глово 11. Системе Sysiog и журнольные фейл!
231
Файлы в таблице представлены под своими базовыми именами; специ-
фика конкретных систем изложена в параграфе 11.4. Не все файлы присут-
ствуют в каждой конкретной системе.
Имена файлов даны относительно каталога /var/adm или /var/log. если
не указано другое (однако файлы в группе “Разное” инсталлируются локально
и, следовательно, их каталоги именуются в соответствии с предпочтениями
пользователей).
Буква в столбце “Где” показывает, как задается файл регистрации: S —
в системе Syslog, С — в командной строке на этапе начальной загрузки; F —
в конфигурационном файле, Н — имя файла определено в ядре. Реальные
имена могут сильно отличаться, особенно если они задаются посредством
системы Syslog. В таблице показаны лишь типичные примеры.
В графе “Частота” указана предлагаемая периодичность чистки журналь-
ных файлов.
Для журнальных файлов обычно назначается код доступа 644. иногда это
значение уменьшают до 640 или 600. Правом записи должен обладать только
владелец. Файлам sulog, authlog и sudo.log следует присвоить код доступа 600.
Рекомендуется также ограничивать доступ к файлам mqueue/syslog u paccl.
11.3.	Файлы, которыми нельзя управлять
У читателя может возникнуть искушение управлять всеми журнальными
файлами по схеме “ротация плюс архивирование”. Но есть два файла, которые
трогать не следует: /var/adm/lustlog и /etc/utmp. В файле tastlog регистрируются
данные о последнем входе в систему' каждого пользователя. Это разреженный
файл, где записи упорядочены по идентификатору пользователя. Размер файла
будет меньше, если все идентификаторы находятся в узком диапазоне, однако
этого невозможно добиться при наличии идентификатора пользователя root,
равного 0. и идентификатора пользователя nobody, равного -2 (65534). Не
копируйте файл lasting. иначе он займет все пространство на диске.
0 Подробные сведения о разреженных файлах содержатся в одном из примечаний
д параграфу 10.3.
Файл utmp предназначен для хранения данных обо всех пользователях,
работающих в данный момент в системе. Иногда эти сведения неверны, из-за
того что пользовательский интерпретатор команд был уничтожен неправиль-
ным сигналом, а родительский процесс этого интерпретатора не обеспечил
надлежащую очистку. Во многих случаях право записи в файл utmp имеют
все пользователи.
11.4.	Особенности журнальных файлов в различных
операционных системах
Создается впечатление, что поставщики систем стремятся спрятать
журнальные файлы на всем пространстве диска. Тщательный анализ конфи-
гурационных файлов различных демонов и системы Syslog позволит выявить
многие из журнальных файлов. Ниже описываются некоторые особо тайные
каталоги, где могут прятаться эти файлы.
В Solaris самая беспорядочная коллекция журнальных файлов. Впрочем,
если есть каталог /var/log, то найти эти файлы большого груда не составит.
Вот некоторые из них:
•	/var/log/*
232
Чость I Основы одминистрировония
•	/var/cron/log
•	/var/lp/logs/*
•	/var/saf/Jog
•	/var/saf/zsmon/log
•	/var/adm/{ messages, aculog. sulog, vold.log. wtmpx}
•	/var/adm/log/aspppJog
Последний файл предназначен для протокола PPP. используемого в сетях
с коммутацией пакетов. Похоже, что в Solans 2.4 режим регистрации
сообщений в этом файле включен по умолчанию, даже если сама подсистема
РРР не установлена или не используется. Файл заполняется сообщениями
об отсутствии маршрутов для соединений
Более детальную информацию о РРР вы найдете в параграфе 13.8.
Можно с помощью демона сгоп запускать системный сценарий
/usr/lib/newsyslog, чтобы осуществлять ротацию основных журнальных файлов,
а также файлов /var/adm/messages и /var/log/syslog.
гтл| ® HP-UX журнальные файлы находятся в каталоге /var/adm. В нем много
разных файлов, не все из них журнальные, поэтому будьте внимательны при
работе с ними. Файл nettl.LOGOO содержит информацию об управлении сетью
и сетевой статистике; дополнительную информацию можно получить с
помощью команды man nettl. По умолчанию все регистрационные сообщения,
поступающие в систему Syslog, направляются в каталог /var/adm/syslog
у->.	В Red Hat регистрационная политика заслуживает самых лестных оценок
Все журнальные файлы именуются согласованно и постоянно хранятся в
—'	каталоге /var/log, к тому же, имеется великолепная утилита Jogrotatc для
работы с ними. Новые программные пакеты могут помешать в каталог
/etc/logrotate.d конфигурационный файл, в котором описывается стратегия
управления журнальными файлами. Благодаря стараниям создателей Red Hai
системные администраторы скоро останутся без работы!
FreeBSD также не вызывает никаких нареканий. Все журнальные файлы
в основном хранятся в каталоге /var/log. хотя демон сгоп помещает свои
файлы в каталог /var/сгоп. а файлы подсистемы учета записываются в каталог
/var/account. Утилита newsyslog отвечает за управление журнальными файлами
и их ротацию. Она запускается с помошью демона сгоп и берет свои установки
из файла /elc/newsyslog.conf.
Кроме того, во FreeBSD каждый день, неделю и месяц с помощью демона
сгоп выполняется команда periodic, которая запускает сценарии, находящиеся
в каталоге /etc/periodic. Через них можно управлять журнальными файлами,
если утилита ncwsyslog по каким-то причинам не справляется со своими
обязанностями.
11.5.	Система регистрации событий: Syslog
Syslog — это полноценная система регистрации событий, написанная
Эриком Оллманом (Eric Allman). Многие поставщики пользуются ею для
управления информацией, которую генерируют ядро и системные утилиты
Система Syslog выполняет две важнейшие функции' она освобождает
программистов от утомительной механической работы по ведению журналь-
ных файлов и передает управление регистрацией в руки администратора. До
появления Syslog каждая программа могла сама выбирать политику регист-
рации, а у системных' администраторов не было возможности контролировать,
какая информация и где именно сохраняется.
Глово 11. Системе Syslog и журнальные файлы
233
Данная система отличается высокой гибкостью. Она позволяет сортиро-
вать сообщения по источникам и степени важности (“уровню серьезности"
в терминологии системы Syslog) и направлять их в различные пункты
назначения: в журнальные файлы, на терминалы пользователей и лаже на
другие машины. Одной из самых ценных особенностей этой системы является
ее способность централизовать процедуру регистрации событий в сети.
Система Syslog состоит из трех компонентов:
•	syslogd — демон, который осуществляет регистрацию (его конфигурацион-
ный файл называется /elc/syslog.con();
•	openlogO, syslog©, closelog© — библиотечные функции, которые передают
сообщения демону syslogd;
•	logger — команда пользовательского уровня, которая принимает регист-
рационные сообщения от интерпретатора команд.
Демон syslogd запускается во время начальной загрузки системы и
работает непрерывно. Программы, взаимодействующие с системой Syslog.
записывают регистрационные сообщения (с помощью библиотечной функции
syslog©) в специальный файл /dcv/log (иногда /var/run/log), который, в
зависимости от системы, представляет собой сокет, именованный канал или
потоковый модуль. Демон syslogd читает сообщения из этого файла, сверяется
со своим конфигурационным файлом и пересылает каждое сообщение
соответствующему адресату. Во многих системах демон, кроме того, читает
сообщения ядра из устройства /dev/klog.
По сигналу “отбой" (HUP. сигнал 1) демон syslogd закрывает свои файлы
регистрации, перечитывает конфигурационный файл и вновь запускает
процесс регистрации. Если изменяется файл syslog.conf, нужно послать демон)'
syslogd сигнал HUP, иначе изменения не вступят в силу. Сигнал TERM
приводит к завершению работы демона.
Демон syslogd записывает свой идентификатор процесса (PID) в файл
/var/nin/syslog.pid (в некоторых системах — в файл /elc/syslog.pid). Это
облегчает передачу демону сигналов из сценариев. Напрнмер, следующая
команда выдает сигнал отбоя:
% kill -HUP /bin/cat /var/run/sysLog.pid"
Попытки сжать или заменить файл регистрации. который был открыт
демоном syslogd для записи неразумны и приводят к непредсказуемым
последствиям. Некоторые поставщики предлагают заготовку сценария (часто
она находится в каталоге /usr/lib/newsysiog). назначение которой — ротация
журнальных файлов*. Улучшенная версия сценария, называющаяся гоп.
доступна на Web-узле www.admm.com.
Конфигурирование демона syslogd
Действия демона syslogd зависят от содержимого файла /etc/syslog.conf.
Это текстовый файл относительно простого формата. Пустые строки и строки
начинающиеся со знака решетки (#), игнорируются. Базовый формат этого
файла таков*’:
селектор <ТаЬ> действие
Этот простейший сценарий отличается (причем в худшую сторону) от утилиты newsvslog во
FreeBSD.
В очень старых версиях syslog используется другой синтаксис, который мы описывать нс
будем.
234
Чость I. Основы одминистрировония
Например, строка
mail.info /var/log/maillog
обеспечивает сохранение сообщений, поступающих от почтовой системы, в
файле /var/log/maillog. Поля селектор и действие должны быть разделены
одним или несколькими знаками табуляции; пробелы не используются н
качестве разделителей и становятся невидимыми ошибками, которые бывает
очень тяжело отследить. Один из способов внесения таких ошибок —
операции вырезания и вставки текста при работе с многооконным графиче-
ским интерфейсом.
Селектор обозначает программу (“средство1' в терминологии системы
Sysiog), которая посылает регистрационное сообщение, и уровень серьезности
этого сообщения. Формат селектора такой:
средство.уровень
Имена средств и уровни серьезности следует выбирать из стандартного
списка значений; программы не могут составлять собственных списков. Есть
средства, определенные для ядра, для группы общих программ и для
локальных программ. Все остальное проходит под общим именем “user”
(т.е. пользователь).
Селекторы могут содержать ключевые слова * и попе, которые обозна-
чают соответственно “все” и “ничего”. Селектор может включать группу
средств, разделенных запятыми. Допускается также разделение с помощью
символов точки с запятой.
В общем случае селекторы объединяются методом логического ИЛИ; для
сообщения, соответствующего любому из селекторов, будет выполняться
действие, указанное в одноименном поле. Селектор уровня попе означает
исключение перечисленных в нем средств независимо от того, что указано
в остальных селекторах этой же строки.
Ниже приведены примеры селекторов:
средство.уровень	действие
средство1,средство2.уровень	действие
средство!. уровень!;средство2.уровень2 действие
.уровень	действие
*.уровень:плохое_ средство.попе	действие
В табл. 11.2 перечислены допустимые имена средств. В большинстве
версий системы Sysiog определено 18 средств (в самой последней версии — 21).
Отдельные имена зарезервированы для будущего использования.
Демон syslogd сам выдает сообщения о временных метках, которые
регистрируются, если в файле syslog.conf для них указан селектор со средством
“mark”. Временные метки помогают точно определить, когда машина вышла
из строя: не просто “сегодня ночью", а “между 3:00 и 3:20 ночи”. Это очень
полезно при устранении проблем, которые возникают регулярно. Например,
в нескольких организациях системы таинственным образом сбоили, тюка не
оказалось, что уборщицы поздно вечером включали пылесосы, отключая при
этом компьютеры.
Когда система сильно загружена, другие зарегистрированные сообщения
часто содержат достаточно много временных меток. Но так бывает не всегда,
особенно в утренние часы.
Уровни серьезности перечислены в порядке убывания важности в
табл. 11.3.
Гпово 11. Системе Sysiog и журнольные фойлы
235
Тоблицо 11.2. Имено средств Syslog
Средство Прогроммы или сообщения, которые его используют
kern	Ядро
user	Пользовательские процессы	(по умолчанию,	если не указано иное)
mail	Система sendmall н другие	почтовые	программы
daemon	Системные демоны
auth	Команды, связанные с безопасностью и авторизацией
1рг	Система буферизации печати в BSD
news	Система телеконференций Usenet
uucp	Зарезервировано для системы UUCP, которая его не использует
сгоп	Демон стоп
mark	Метки времени, генерируемые через одинаковые промежутки
1оса10-7	Восемь разновидностей локальных сообщений
syslog1	Внутренние сообщения демона syslogd
authpriv*	Частные (не системные) авторизационные	сообщения
ftpl	FTP-демон ftpd
•	Все средства, кроме "‘mark”	_____________________________
1 Новые средства в версии 8.1 от Беркли.
Тоблицо 11.3. Уровни серьезности сообщений Syslog
Уровень	Приблизительное зночение
cmerg	Экстренные ситуации
alert	Срочные ситуации
спс	Критические состояния
егт	Другие ошибочные состояния
warning	Предупреждающие сообщения
notice	Необычные события, которые заслуживают внимания
info	Информационные сообщения
debug	Отладочные сообщения
Уровень сообщения определяет его важность. В файле syslog.conf уровни
обозначают минимальную важность, которую сообщение должно иметь для
того, чтобы быть зарегистрированным. Например, сообщение почтовой
системы с уровнем серьезности “warning” будет соответствовать селектору
mail .warning, а также селекторам mail .notice, mail, inf о, mail.de-
bug, *.warning, ‘.notice, ‘.info и ‘.debug. Если в файле syslog.conf
указано, что сообщения mail, inf о должны регистрироваться в файле, то
сообщения mail.warning тоже будут направляться туда.
Поле действие определяет, что нужно делать с сообщением. Возможные
варианты перечислены в табл. 11.4.
236
Чость I Основы одминистрировония
Тоблицо 11.4. Действия Syslog
Действие	Описоние
имя_файла	Записать сообщение в файл на локальной машине
вимя_мащины	Переслать сообщение демону syslogd на машину с указанным именем
$1Р_адрес	Переслать сообщение машине с заданным IP-адресом
пользователь], пользователь!,	Вывести сообщение на экраны терминалов указанных пользовате- лей, если они зарегистрированы в системе
•	Вывести сообщение на экраны всех зарегистрированных пользова- телей
Если в качестве действия задано имя файла, то необходимо, чтобы это
было абсолютное путевое имя. Указанный файл должен существовать; демон
syslogd не будет создавать его. Если задается не JP-адрес, а имя машины,
оно должно быть известно одной из систем преобразования имен, например
DNS или NIS.
Подробнее о преобразовании доменных имен в IP-адреса питайте в параг-
рафе 18.3.
Некоторые версии системы Syslog используют при работе с конфигура-
ционным файлом препроцессор макрокоманд т4 Изучите имеющуюся
документацию, чтобы узнать, как правильно пользоваться кавычками. На-
пример, нужно брать в кавычки ключевые слова т4 или выражения,
включающие запятые. Ниже приведен образец строки конфигурационного
файла, рассчитанной на обработку препроцессором гл4
auth.notice	ifdef(’LOGHOST', '/var/log/authloq', '@loghost’J
Обратите внимание на употребление как обратных, так и одиночных
кавычек. Эта строка направляет сообщения в файл /var/log/authlog, если
определено значение переменной LOGHOST. В противном случае сообщения
пересылаются на машину loghost. Инструкции ifdef препроцессора гп4
очень эффективны. Они позволяют администратору системы создать один
файл syslog.conf, который будет затем использоваться на всех машинах.
Хотя в селекторе допускается указывать сразу несколько средств и
уровней, выполнение нескольких действий не предусмотрено. Для того чтобы
послать сообщение в два места (например, в локальный файл и на
центральную регистрационную машину), нужно включить в конфигурацион-
ный файл две строки с одинаковыми селекторами
Улучшения системы Syslog в Red Hat
В Red Hat имеется улучшенная версия демона syslogd. Разрешается
направлять регистрационные сообщения в именованные каналы и употреблять
пробелы в качестве разделителей в файле syslog.conf
В файле syslog.conf перед названиями уровней могут ставиться символы
'=' и обозначающие “только этот приоритет” и ”за исключением этого и
более высоких приоритетов" (табл. 11.5).
Глово 11 Системе Syslog и журнолыные фойлы
237
Тоблицо 11.5. Примеры ислользовония кволифмкоторов в фойпе syslog.conf
в Red Hot
Селектор	Зночение
mail.info	Выбор почтовых сообщений уровня "info” и выше
mail.=info	Выбор почтовых сообщений только уровня "info"
mail.in£o;mail.!err	Выбор почтовых сообщений уровней ‘‘info”, “notice” и “warning”
mail .debug;mail. ! =warning Выбор почтовых сообщений любого уровня, кроме
“warning’’
В Red Hat демон syslogd особенно осторожен при работе в сети. Если
отсутствует флаг -г, демон не станет принимать сообщения от других
компьютеров. По умолчанию он также отказывается выступать в роли
маршрутизатора сторонних сообщений; сообщения, поступающие от сетевого
узла, не могут быть пересланы на другой узел. Флаг -h отменяет такое
поведение демона. (Если нужно, чтобы эти опции были установлены всегда,
модифицируйте сценарий /etc/rc.d/init.d/syslog.)
В Red Hat имеется отдельный демои, klogd, принимающий сообщения
от ядра и вставляющий их в поток сообщений Sysiog. Модифицировать его
работу не рекомендуется.
Улучшения системы Sysiog во FreeBSD
Как и Red Hat, FreeBSD поддерживает дополнительные способы задания
уровней серьезности в файле syslog.conf (табл. 11.6).
Тоблицо 11.6. Примеры использовония кволификоторов в фойпе syslog.conf
во FreeBSD
Селектор	Значение
mail.info	Выбор почтовых сообщений уровня “info” и выше
mail.>=info	То же, что и предыдущее
mail.«-info	Выбор почтовых сообщений только уровня “info”
mail.<=info	Выбор почтовых сообщений уровня "info” и ниже
mail-<info	Выбор почтовых сообщений уровней ниже “info”
mail.>info	Выбор почтовых сообщений уровней выше ‘ info”
В отличие от общепринятой схемы классификации сообщений, FreeBSD
позволяет выбирать сообщения на основании имени программы, от которой
они поступают, а не расплывчато-неопределенного имени средства. К сожа-
лению, демон syslogd не владеет информацией о программах, поэтому
вынужден просматривать сообщения на предмет того, начинаются ли они с
имени программы и двоеточия. Например, сообщение
named: starting, named 4.9.7 Sat Sep 2 09:39:12 GMT 1998 PHNE_I4618
будет распознано как поступившее от демона named В файле syslog.conf
секции, относящиеся к сообщениям, которые поступают от конкретных
238
Чость I. Основы одминистрировония
программ, предваряются восклицательным знаком и именем программы.
Например, строки:
!named
*	.* /var/log/named.log
заставляют демона syslogd посылать все сообщения демона named в файл
/var/log/named.log.
Распределение сообщений на основании имен программ — не самый
лучший способ управления регистрацией. Он базируется на определенных
правилах формирования сообщений, которым следуют далеко не все про-
граммы.
Демону syslogd во FreeBSD необходимо сообщить посредством опции -а.
от каких удаленных узлов следует принимать сообщения Набор узлов может
быть задан в виде списка IP-адресов с масками (например, - а 128.138,192.0.20)
или списка доменных имен (например, - а * .cs. Colorado .edu). Чтобы
запретить прием сетевых сообщений, нужно с помощью опции -ss дать демону
syslogd указание не открывать свой сетевой порт.
Аргументы командной строки демона syslogd можно поместить в файл
/etc/гс.сопГ, чтобы они автоматически активизировались во время начальной
загрузки системы. Например:
syslogd_flags="-a 12S . 138.192.0/20 -а * .св .colorado.edu''
Примеры конфигурационных фойлов
Ниже приведены примеры трех файлов syslog.conf которые соответствуют
автономному компьютеру, используемому в небольшой сети, маши не-клиенту
в крупной сети и центральному регистрационному узлу этой же сети
Последний называется nctloghost'
Автономный компьютер
Ниже показана базовая конфигурация для автономного компьютера:
#	Файл syslog.conf для малых сетей и автономных систем
#	экстренные сообщения направляются всем зарегистрированным пользователям
*.emerg	*
#	важные сообщения
*	.warning;daemon, auth. i nfo, user, none /var/adm/rnessages
#	ошибки принтера
Ipr.debug	/var/adm/lpd-errs
Первая не являющаяся комментарием строка организует вывод экстрен-
ных сообщений на экраны терминалов всех текущих пользователей. В качестве
примера можно привести сообщения, выдаваемые программой shutdown во
время выключения системы.
Вторая значащая строка обеспечивает запись важных сообщении в файл
/var/adm/messages. Уровень “info” ниже уровня “warning", поэтому выражение
daemon, auth. info включает дополнительную регистрацию сообщении из
Точнее, netloghost — один из псевдонимов данного узла. Эго позволяет заменять регистра-
ционный узел с минимальными затратами на переконфигурирование системы. Псевдоним
можно добавить в файл /etc/hosts или задать с помощью записи CINAME в базе данных
DNS. Подробнее об этом рассказывается в параграфе 16.11.
Глово 11. Системе Syslog и журнольиые фойлы
239
программ passwd, su и всех демонов. Третья строка предназначена для записи
сообщений об ошибках принтера в файл /var/adm/lpd-errs.
Сетевой клиент
Машина-клиент обычно пересылает серьезные сообщения на централь-
ный регистрационный узел.
>	Файл syslog.conf факультета вычислительной техники
f для клиентских машин
#	экстренные сообщения направляются всем зарегистрированным пользователям
*. etnerg; user . попе	*
#	важные сообщения пересылаются на центральный компьютер
’. warning; Ipr, locall, none	@netlogbiost
daemon,auch.info	@necloghost
#	сообщения от локальных программ также идут на центральный компьютер
localO,local2,local?.debug	enetloghost
#	демон cardd регистрируется через средства locall —
# направляем сообщения на машину boulder
locall.debug	@bouldeг.Colorado.edu
#	сообщения об ошибках принтера хранятся локально
Ipr.debug	/var/adm/lpd-errs
#	пользователи программы sudo регистрируются через средство
i °local2" — сохраняем копии сообщений
local2.info	/ va г/adiu/sudolog
#	сообщения ядра также хранятся локально
kern.info	/var/adm/kern.log
В этой конфигурации не очень много информации хранится локально.
Следует учесть, что если компьютер netloghost выключен или недоступен,
регистрационные сообщения будут безвозвратно утеряны. На этот случай
можно создавать локальные копни важных сообщений.
В организации, где инсталлирован большой объем локального програм-
много обеспечения, неоправданно много сообщений может регистрироваться
с помошью средства “user” на уровне “emerg”. В показанном примере такая
ситуация заведомо исключается с помощью выражения user .попе в первой
строке.
Вторая и третья строки служат для пересылки всех важных сообщений
на центральный регистрационный сервер; сообщения подсистемы печати и
университетской системы доступа по карточкам направляются в другое место.
Четвертая строка организует отправку локальной регистрационной информа-
ции также на центральный компьютер- В пятой строке регистрационная
информация системы доступа по карточкам отправляется на центральную
машин)' boulder. Последние две строки обеспечивают хранение локальных
копий сообщений об ошибках принтера и регистрационных сообщений
программы sudo.
Детальнее о программе sudo рассказывалось в параграфе 3.4.
240
Чость I Основы ОДМИНИСТрИрОВОНИЯ
Центральный регистрационный узел
Это пример для компьютера netloghost — центрального высоконадежного
регистрационного узла сети среднего размера, включаюшей 400—500 машин-
#	Файл syslog.conf факультета вычислительной техники
#	для главного регистрационного узла
4 экстренные сообщения направляются на консоль и в журнальный файл,
if записываются метки времени
*	. ernerg	/oev /console
”.err; kern,mark.debug;auch .notice /dev/console
	* .err; kern, mark.debug;user.none / var/adm/console . log
auth.notice	/vax/adn; 'console, log
S' сообщения, не являющиеся экстренными,, записываются в обычные
# журнальные файлы
*	.err,-user.none;kern.debug	/var/adm/raessages
daemon,auth.notice;mail.crit	/var/adm/messages
Ipr.debug	/var/adm/lpd-errs
mail.debug	/var/adm/mail.log
#	в следующих строках обрабатываются сообщения локальных программ
# авторизации, иаких как sudo и npasswd
local2.deoug	/var/adm/sudo- log
1оса12.alert	/var/adm/sudo-errs.log
auth.info	/var/adm/auth.log
if другие локальные программы
local0.info
locals.notice
1oca16.debug
local?.debug
#	пользовательские процессы
user.info
/var/adm/netbiazer.log
/var/adm/da.log
/var/adm/annex-isn.log
/var/adm/tcp.log
/var/adm/user.log
Регистрационные сообщения, поступающие от локальных программ и
демонов syslogd по сети, записываются в указанные выше файлы. В некоторых
случаях выходная информация каждого средства записывается в отдельный
файл.
Центральный регистрационный компьютер генерирует метки времени для
каждого получаемого сообщения. Это время не всегда совпадает со временем
отправки сообщения. Если в системе регистрируются компьютеры, располо-
женные в разных часовых поясах, или системные часы не синхронизированы,
информация о времени оказывается недостоверной.
Пример выходной информации системы Sysiog
Ниже показан фрагмент одного из журнальных файлов, скопированный
с главного регистрационного узла факультета вычислительной техники
университета штата Колорадо. На этот компьютер поступает регистрационная
информация приблизительно с двухсот машин.
Dec 18 15:12:42 avl8.cs.colorado.edu sbacchd[495]: sbatcha/main: ls_info()
tailed: LIM is down; try later; trying ...
Dec 18 15:14:28 proxy-1.cs.colorade.edu pop-proxy[272831: Connection from
Глово 11. Системе Sysiog и журнольные фойлы
241
128-138.196-64
Dec 18 15:14:30 mroe.cs.colorado.edu pingem[271]: maltese-
office.cs.colorado.edu has not answered 42 times
Dec 18 15:15:05 schwarz.cs.colorado.edu vmunix: Multiple softer-
rors: Seen 100
Corrected Softerrors from SIMM J0201
Dec 18 15:15:05 schwarz.cs.colorado.edu vmunix: AFSR - 0x4c21, AFARO —
0x87ffdd30, AFAR1 = oxb8fBaO
Dec 18 15:15:48 proxy-l.cs.colorado.edu pop-proxy(27285]: Connection from
12.2.209.183
Dec 18 15:15:50 avl8.cs.colorado.edu last message repeated 100 times
В этом примере представлена информация, поступившая с нескольких
машин (avl8. proxy-1. mroe и schwarz) и от нескольких программ, shaichd.
pop-proxy, pingem и vmunix (ядра). Обратите внимание на последнюю строку,
в которой говорится о сообщении, повторившемся 100 раз. Чтобы сократить
объем журнальных файлов, система Syslog обычно пытается объединять
дублирующиеся сообщения и заменять их резюмирующей строкой. Однако
компьютер, с которого был взят этот файл, принимает регистрационные
сообщения от множества других компьютеров, поэтому данное конкретное
сообщение может немного сбить читателя с толку. Оно ссылается на
предыдущее сообщение от компьютера av18. а не на предыдущее сообщение
в журнальном файле.
Рекомендуем регулярно просматривать свои журнальные файлы. Устано-
вите, какое их состояние является нормальным, чтобы в случае отклонения
от нормы сразу заметить это. А еще лучше установить программу обработки
журнальных файлов, такую как swatch, которая будет делать то же самое
автоматически (см. параграф 11.6).
Разработка схемы регистрации для конкретной организации
Для небольшой организации достаточной будет такая конфигурация
системы регистрации, при которой важные системные ошибки и предупре-
ждения хранятся в отдельном файле на каждом компьютере. В основном так
было до появления системы Syslog. Файл syslog.conf можно адаптировать для
каждой конкретной машины.
В большой сети необходима централизованная регистрация. Такой подход
позволяет контролировать информационные потоки и — если повезет —
скрывать получаемые в результате проверки данные от лица, взломавшего
систему зашиты какого-либо компьютера в сети. Хакеры часто изменяют
системные журнальные файлы, чтобы замести следы: если регистрационную
информацию сразу же скрыть, то подделать ее будет гораздо труднее.
Помните, однако, о том, что каждый может вызвать систему Syslog и создать
регистрационные записи, якобы посланные каким-либо демоном или утили-
той. Кроме того, система Syslog пользуется протоколом UDP, который не
является надежным, так как не гарантирует доставку сообщений. Имеющийся
в сети брандмауэр должен запрещать внешним узлам передавать сообщения
демону syslogd.
В качестве сервера-регистратора выбирайте стабильно работающую ма-
шину, лучше такую, доступ физических лиц к которой ограничен и хорошо
контролируется и где мало зарегистрированных пользователей. Другие
компьютеры сети могут пользоваться базовым конфигурационным файлом,
который хранится на центральном узле. Таким образом, нужно вести лишь
242
Чость I. Основы одминистрировония
две версии файла syslog.conf*. Это обеспечивает полноту регистрации, не
превращая ее в кошмар для злминистратора.
Информация о распределении файлов в сети приведена в главе 18.
В некоторых очень больших организациях считают необходимым ввести
в иерархию регистрации дополнительные уровни К сожалению, текущая
версия системы Syslog сохраняет имя машины-отправителя только для одной
пересылки. Если машина-клиент отправляет регистрационные данные маши-
не-серверу, которая пересылает их ведущему компьютеру, то последний будет
рассматривать эти данные как поступившие от сервера, а не от клиента.
Прогроммы, использующие систему Syslog
В табл. 11.7 перечислены некоторые программы., работающие с системой
Syslog, средства и уровни, на которых они регистрируются, а также дано
краткое описание каждой программы.
Таблица 11.7. Программы, использующие Систему Syslog			
Программе	Средство	Уровни	Описание
amd	daemon	err-info	Программа автомонтирования NFS
date	auth	notice	Установка даты и времени
ftpd	daemon	err-debug	Демон FTP
gated	daemon	alert-info	Демон маршрутизации
halt /reboot	auih	ent	Программы останова системы
inetd	daemon	err, warning	Демон Internet
logm/rlogind	auth	crit-info	Программы входа в систему
Ipd	Ipr	err-info	Демон принтера в BSD
named	daemon	err-info	Сервер имен (DNS)
nnrpd	news	crii-notice	Программы чтения новостей INN
ntpd	daemon, user	cril-mfo	Сетевой демон времени
passwd	auth	en	Программа установки паролей
popper	loealO	notice, debug	Программа электронной почты для Macintosh и ПК
sendmall	mail	alert-debug	Система доставки почты
su	auth	crit, notice	Программа подстановки идентификато- ров пользователей
sudo	local 2	alert, notice	Ограниченная версия программы su
syslogd	syslog, mark	err-info	Демон обработки внутренних ошибок, меток времени и др.
tepd	local?	err-debug	TCP-демон для демона inetd
стоя	cron, daemon	info	Демон планирования заданий
v mu nix	kern	изменяются	Ядро
На компьютерах, где ведется обработка файла syslog.conf с помощью процессора макроко-
манд ш4, можно даже объединить обе конфигурации в один файл
Глово 11. Системе Syslog и журнольные фойлы
243
Располагая приведенной информацией, можно, казалось бы. безошибочно
определить, какие сообщения следует сохранять, а какие — игнорировать.
Но это не совсем так. На практике нужно определить, какие уровни
регистрации важны для системы. Лучше начать с регистрации всех сообщений
и постепенно отсеивать ненужные, пока объем передаваемых данных не станет
приемлемым
Отладка системы Syslog
Команда logger позволяет обрабатывать регистрационные сообщения,
поступающие от shell-сценариев. Кроме того, эта команда используется для
проверки изменений в конфигурационном файле демона syslogd. Например,
если только что была добавлена строка
1оса15 .warning	/tinp/evz.. log
и нужно убедиться в том, что она действительна, дайте команду
% logger -р locals. warning "test message"
Строка, содержащая фразу “lest message” (тестовое сообщение), должна
быть записана в файл /tmp/evi.log. Если этого не произошло, значит, файла
не существует, установлены неверные права доступа к нему или демону syslogd
не был послан сигнал отбоя.
В первых версиях демона syslogd имеется константа NLOGS. В ней
определяется общее количество действий, которое может быть задано в
конфигурационном файле. Обычно она устанавливается равной 20. Если
превысить это число, демон syslogd будет игнорировать лишние действия н
просто отбрасывать регистрационные сообщения, которые посылаются ему.
В более поздних версиях демона есть константа MAXUNAMES (также
равная 20). ограничивающая количество пользователей, которые могут быть
адресата ми сообщения.
При вызове демона syslogd с флагом -d (“debug”, т.е. отладка) он выдает
таблицу' средств, уровней и действий, заданных в файле syslog.conf. Каждое
входящее сообщение также выводится на экран вместе с информацией о том,
как оно обрабатывается. Вот несколько строк из такой таблицы:
О О О О О О О О О О О О О О О 0 О О О О X WALL:
7Х466444444444444444Х FILE: /adm/msgs
ХХХХХХ7ХХХХХХХХХХХХХХ FILE: /acta/lperr
OOOOOOOOOOOCOOOOOOOOO UNUSED:
OOOOOOOOOOOOOOOODOGCO UNUSED:
В этой таблице столбцы соответствуют средствам, а строки — действиям.
Показанные значения — это уровни приоритета во внутреннем представле-
нии; х означает отсутствие уровня.
Если в таблице есть строки с признаком UNUSED и без указания действия,
то число адресатов все еше не превышает значения константы NLOGS. Если
таких строк нет, обязательно проверьте, не превышен ли лимит. Для этого
нужно просмотреть последнюю запись файла syslog.conf с помощью команды
logger. Строки с признаком UNUSED и именем файла означают, что
соответствующий журнальный файл не создан.
Очень осторожно подходите к вопросу вывода регистрационной инфор-
мации на системную консоль, /dev/console. Если консоль — это старый
терминал VT100 и кто-то случайно нажмет на нем клавиши <Clrl-S>, вывод
244
Чость I Основы ОДМИНИСТрИрОВОНИЯ
на консоль прекратится. Все вызовы системы Sysiog будут заблокированы, и
система начнет работать очень медленно. Хороший способ проверки подобной
ситуации — послать регистрационное сообщение на консоль с помощью
команды logger. Если команда зависает, нужно иайти консоль-виновницу,
нажать <Ctrl-Q> — и пересмотреть свою политику регистрации Вывод
регистрационных сообщений на консоль опасен еще и тем, что при
возникновении серьезной проблемы поток сообщений “парализует" консоль
именно тогда, когда она больше всего нужна.
Использование функций Sysiog в сценариях
Библиотечные функции openlogO- syslogO и doselog() позволяют програм-
мам обращаться к системе Sysiog. Существуют версии этих функций для
языков С и Perl. Ниже мы рассмотрим лишь программирование Perl-сцена-
риев. Чтобы импортировать определения библиотечных функций, нужно
включить в начало сценария следующую строку:
use Sys::Sysiog;
Функция openlogO инициализирует систему регистрации, передавая ей
заданное имя средства:
open 1 од (идентифика тор, опции__регистрации, средств о);
Сообщения регистрируются с указанными опциями и начинаются с
идентификационной строки, переданной в первом аргументе. Если функция
openlogO не используется, то по умолчанию идентификационная строка равна
текущему имени пользователя, в качестве опций задается пустая строка, а
именем средства становится строка “user". Список возможных опций
приведен в табл. 11.8.
Тоблицо ll.fi. Опции регистроции для функции openlog(}
Опция	Нозначение
pid	Включать идентификатор текущего процесса в каждое регистрационное
сообщение
ndelay Подключаться к демону syslogd немедленно (не ждать, пока сообщение
будет доставлено)
cons Посылать сообщения на системную консоль, если демон syslogd
недоступен
nowait Не вызывать функцию wait() для дочерних процессов, созданных с
помощью функции fork() для записи сообщений на консоль
К примеру, вызов функции openlogO может выглядеть так:
openlog("adminscript", ”pid,cons", "daemon");
Библиотечная функция syslogO посылает сообщение демону syslogd.
который регистрирует его с заданным приоритетом:
sysiog(приоритет, сообщение, ...) ;
В журнальном файле к сообщению добавляются дата, время, имя
компьютера и строка идентификации, заданная в функции openlogO. После
Глово 11. Системе Sysiog и журнольные фойлы
245
аргумента сообщение могут идти другие параметры, а формат сообщения
напоминает спецификацию формата функции printf()t например:
sysloq("info", "Delivery со '%s' failed after %d attempts.",
Suser, SnAttempts);
Если есть спецификатор %m, то он заменяется сообщением об ошибке,
номер которого извлекается из переменной ermo (в ней хранится код самого
последнего сообщения об ошибке UNIX).
Строка приоритета вида уровен^средство" задает уровень серьезности и
название средства. Если функция openiogO не была вызвана и строка
идентификации не задана явно, то функция syslogO также проверяет, выглядит
ли второй аргумент как стандартное сообщение об ошибке UNIX, например:
adminscript: User "nobody" not found in /etc/passwd file.
Если проверка прошла успешно, часть строки перед двоеточием тайно
принимается в качестве идентификационной строки. Эта удобная (хотя и
недокументированная) особенность делает вызов функции openiogO ненуж-
ным. Тем не менее, не следует от этого отказываться, так как лучше ыдать
имя средства один раз (в функции openiogO), чем постоянно повторять его
в тексте программы.
Функция closelogO закрывает файл регистрации.
closelog (};
Ее нужно вызывать, если требуется повторно открыть файл с другими
опциями. Хорошим стилем также считается вызов функции closelogO при
завершении работы программы.
Приведем полный пример сценария:
use Sys::Syslog;
openlog("adminscript", "pid,cons", "user");
syslog("info", "Those whom the gods would destroy, they first
teach Basic*');
closelog();
Этот сценарии выдает сообщения следующего вида:
Dec 28 22:56:24 moet.colorado.edu adminscript[191]: Those whom the qods
would destroy, they first teach Basic.
11 6 Поиск полезной информации в журнальных файлах
Система Syslog прекрасно подходит для сортировки и маршрутизации
сообщений, но в результате все равно получается большой набор журнальных
файлов. Они могут содержать много важной информации, но се бывает нс
так-то просто найти. Необходимо дополнительное программное обеспечение
для анализа журнальных файлов и поиска в них нужных сообщений.
В данном сегменте рынка предлагается много бесплатных продуктов, и
большинство из них работает примерно одинаково: они сканируют недавние
записи журнального файла, сравнивают их с регулярными выражениями из
базы данных и определенным образом обрабатывают важные сообщения.
Некоторые программы направляют пользователю отчет по электронной почте.
Различия между программами проявляются в степени гибкости и размере баз
данных с шаблонами.
246
Чость I. Основы одминиелрировоиия
Двумя наиболее распространенными программами обработки журнальных
файлов являются утилиты swatch Тодда Аткинза (Todd Atkins) и logcheck
Крейга Роуленда (Craig Rowland). Первая из них доступна по адресу
ftp://ftp.sianford.edu/general/security-tools/swatcri/
а вторая — на Web-узле
hnp://www.psionic.corTi/abaciis/logcheck
Утилита swatch — это Perl-сценарий, работающий по указаниям, остав-
ленным в конфигурационном файле. Синтаксис этого файла достаточно
гибок, так как позволяет выполнять все существующие в языке Perl операции
сравнения с шаблонами. Утилита swatch может обработать конфигурационный
файл за один вызов, но обычно она выполняется автономно, отслеживая
новые сообщения по мере их поступления. Недостатком является то, что
конфигурационный файл, по сути, нужно создавать с нуля. Утилита не знает
об особенностях работы системы и о том, какие регистрационные сообщения
в ней генерируются.
Утилита logcheck — это более простои сценарий интерпретатора sli.
В дистрибутив входит также программа на языке С, которая помогает утилите
logcheck запоминать свое текущее положение в журнальном файле. Благодаря
этому у сообщения меньше шансов пройти незамеченным на этапе начальной
загрузки или перезагрузки. Утилита может запускаться периодически с
помощью демона cron, а не выполняться постоянно.
С утилитой logcheck поставляются базы данных с шаблонами для
нескольких версий UNIX. Даже если в самой утилите нет особой надобности,
полезно просмотреть эти базы данных, так как в них могут содержаться очень
интересные и полезные шаблоны.
Недостаток обеих утилит состоит в том. что за раз они обрабатывают
только один журнальный файл Если система Sysiog направляет сообщения
сразу в несколько файлов, нужно дублировать некоторые из них в каком-то
центральном файле, который часто обнуляется, а затем передавать этот файл
на последующую обработку одному из сценариев. Это проще, чем организо-
вывать сложную сеть сценариев, управляющих несколькими журнальными
файлами.
Независимо от того, какая система используется для сканирования
журнальных файлов, есть ряд моментов, которые нужно проверить, чтобы в
случае необходимости немедленно проинформировать системного админист-
ратора.
•	Большинство сообщений, связанных с безопасностью, должно просмат-
риваться немедленно. Важно отслеживать неудачные попытки регистра-
ции. равно как вызовы команд su и sudo, чтобы предотвратить возможный
взлом системы, пока еше не поздно. Если кто-то просто забыл или
неправильно набрал пароль (как чаше всего бывает), то появление
оперативной подсказки произведет хорошее впечатление и повысит
репутацию системного администратора.
•	Сообщения о нехватке места на диске должны помечаться и немедленно
обрабатываться. Когда диск переполнен, работать на нем невозможно
•	Многократно повторяемые сообщения заслуживают внимания, хотя бы
ради профилактики.
Глово 11 Системе Sysiog и журнольные файлы
247
J Драйверы и ядро
UNIX-систему можно разбить на три основных уровня:
•	аппаратные средства;
•	ядро операционной системы;
•	пользовательские программы.
Ядро скрывает доступ к аппаратным средствам системы благодаря
абстрактному высокоуровневому интерфейсу программирования. Оно отвечает
за реализацию многих концепций, которые пользователи и программы
пользовательского уровня принимают как нечто само собой разумеющееся.
Например, на базе аппаратных возможностей низкого уровня ядро реализует
следующие элементы операционной системы UNIX:
•	процессы (защита адресных пространств, разделение времени и ресурсов
процессора);
•	сигналы и семафоры;
•	виртуальную память (выгрузка, подкачка, отображение виртуальных
адресов в физической памяти);
•	файловую систему (файлы, каталоги, пространство имен);
•	межзадачное взаимодействие (каналы и сетевые соединения).
Ядро содержит драйверы устройств, которые управляют отдельными
элементами аппаратного уровня; остальная часть ядра в основном не зависит
от внешних устройств. Взаимосвязь ядра и драйверов устройств аналогична
связи между ядром и процессами пользовательского уровня. Когда процесс
просит ядро прочитать первые 64 байта файла /etc/passwd. ядро транслирует
эту просьбу в команду драйвера устройства, например “выбрать блок 3348
из устройства 3" Драйвер представляет эту команду в виде последователь-
ности двоичных кодов, которые посылаются в управляющие регистры
устройства.
248
ЧОСП> I Основы одминистрировояия
Ядро написано преимущественно на языке С, но для низкоуровневой
обработки частично использовался язык ассемблера. Много лет назад
объектный код ядра UNIX имел довольно умеренные размеры (обычно
гораздо меньше половины мегабайта). За последние годы на уровне ядра
были реализованы сетевые и многопотоковые функции, а стоимость микро-
схем памяти сильно упала, поэтому теперь ядро занимает от 400 Кбайт до
более чем 15 Мбайт.
12.1. Типы ядер
Ф
ш
%
Все UNIX-системы позволяют пользователю предоставить ядру явную
информацию о том, какие аппаратные средства присутствуют в системе.
Некоторые ядра могут самостоятельно искать устройства.
В Solaris ядро почти полностью является модульным и может загружать
драйверы устройств по мере необходимости. Не нужно сообщать системе
заранее, какие устройства присутствуют, так как компания Sun разработала
очень четкую аппаратную архитектуру (сравнимую с архитектурой персональ-
ных компьютеров). Когда ядро обнаруживает новое устройство, подключенное
к системе, оно ищет и загружает модуль соответствующего драйвера.
В большинстве случаев данный механизм работает без сбоев.
Как и в Solaris, в HP-UX поддерживается относительно небольшой н
четко определенный круг аппаратных устройств. Как правило, система
самостоятельно находит устройства без особого вмешательства пользователя.
В общем случае во FreeBSD и других BSD-системах на этапе компиляции
ядра нужно явно указывать, какие устройства могут быть найдены в системе.
Иногда следует также задать, где именно подключено устройство. Подобную
информацию часто бывает трудно получить, так как производители персо-
нальных компьютеров не всегда ее предоставляют Приходится снимать
корпус и самостоятельно находить ответы на вопросы наподобие следующего:
“Какой микропроцессорный набор установлен на моей Frhemet-плате?”
Linux находится посредине между' Solaris и BSD-системами. Как и
F reeBSD, Linux страдает от работы в среде персональных компьютеров, где
очень сложно определить точный состав аппаратных устройств в системе.
Ядро Linux также можно сконфигурировать вручную, сообщив ему заранее
об имеющихся устройствах, в результате чего размер ядра получится очень
большим. С другой стороны, допускается конфигурация в стиле Solaris, когда
драйверы загружаются по мере необходимости. Поддержка модулей в Linux
не столь универсальна, как в Solaris, по в основном это связано с недостатками
архитектуры персональных компьютеров.
В табл. 12.1 указано местоположение каталога, в котором выполняется
построение ядра, и стандартное имя инсталлированного ядра в каждой из
четырех тестовых систем.
Тоблицо 12.1. Местоположение ядер в тестовых системах
Система		
	Каталог для построения ядро	Ядро
Solaris	-	/kcmel/unix
HP-UX	/stand	/stand/vmunix
Linux	/usr/src/linux	/vmlinuz или /boot/vmlinuz
FreeBSD	/usr/sre/sys	/kernel
Глово 12 Драйверы и ядро
249
12.2.
12.3.
0
Зачем нужно конфигурировать ядро
При инсталляции системы создается базовое ядро, которое рассчитано
на работу практически в любой аппаратной среде. В это ядро входит
множество драйверов устройств и дополнительных пакетов. Имеет смысл
переконфигурировать его, чтобы адаптировать к конкретной системе: удалить
модули, которые никогда не будут использоваться, и отключить ненужные
опции. Незадействова!пше компоненты ядра не влияют на работу системы,
однако занимают драгоценную память.
Современные ядра лучше справляются с выгрузкой ненужных драйверов,
чем их предшественники, но большинство опций по умолчанию включено.
В наши дни заниматься переконфигурированием ядра для повышения
эффективности его работы уже не так актуально, как раньше, но. тем не
менее, это хорошая привычка.
Еще одна причина, по которой может потребоваться переконфигурировать
ядро, заключается в необходимости добавить поддержку нового типа устрой-
ства (т.е. нового драйвера). Файл драйвера нельзя просто записать в каталог
ядра; его нужно интегрировать в структуры данных и таблицы ядра,
В некоторых системах для этого следует добавить в конфигурационные файлы
ядра сведения о новом устройстве, т.е. перестроить ядро заново. В других
системах требуется выполнить специальную программу, которая сама внесет
необходимые изменения.
Инструкции но добавлению нового драйвера приведены в параграфе 12.8.
В ряде систем реализована концепция загружаемого драйвера устройства,
которая в большинстве случаев подразумевает, что новый код можно
загружать в ядро в процессе его работы Однако это опасная процедура, не
всегда приводящая к нужным результатам.
Компилировать ядро не так ум сложно. Сложнее восстановить его работу,
если что-то было сделано не так.
Конфигурирование ядра в Solans
Ha этапе загрузки ядро Solaris опрашивает системную шину на предмет
наличия устройств и инициализирует драйвер для каждого найденного
устройства. Ядро поддерживает концепцию загружаемых модулей и загружает
код только для тех устройств, которые реально присутствуют (если нс
поступило других указаний).
Благодаря средствам автоматического конфигурирования в Solans редко
возникает необходимость создавать собственное ядро. В идеальном мире ядро
Solans правильно идентифицировало бы свою аппаратную сред\ в 100%
случаев. К сожалению, нестандартные или просто дефектные устройства (либо
драйверы ОС Solaris) могут превратить процедуру автоконфигурирования в
источник нескончаемых мучений.
Учитывая сказанное, давайте рассмотрим, как конфигурировать ядро
Solaris на случай, если это когда-нибудь понадобится
Область построения ядра
Чтобы процедура загрузки драйверов по запросу работала правильно, в
Solaris принята специальная организация каталогов. Система ожидает, что в
250
Чость I. Основы ОДМИНИСГрИрОВОНИЯ
определенных местах файловой системы находятся нужные каталоги. в
которых содержатся модули заданного типа:
•	/kernel — модули, общие для компьютеров с одинаковым набором
инструкций процессора;
•	/platform/имяплатформы/kernel — модули, специфичные для конкретного
типа кохгпьютера, например Ultra Enterprise;
•	/platfonn/r/AOT_ic«7rce_vcmpoucme/kai№:\ — модули, специфичные для кон-
кретного класса аппаратных устройств, например для всех машин
семейства “sun4u”;
•	/usr/kernel — аналогичен каталогу /kernel.
Определить имя платформы и имя класса устройств можно с помощью
команд uname -i и плате -т соответственно. Рассмотрим пример
Ь uname -i
SUKW,Uleva-Enterprise
"fc ипалге -®
sun4u
Когда система Solaris загружается, она просматривает следующую после-
довательность каталогов:
'platform/имя платформы/kernel:/kernel:/usr/kernel
пытаясь найти ядро. В первую очередь ищутся файлы с именем nnix, а
затем — genunix. Второе имя обозначает платформ но-независимую часть
базового ядра.
В каждом из перечисленных каталогов может содержаться несколько
стандартных подкаталогов (табл 12.2). Чтобы избежать ненужной детализа-
ции. мы в дальнейшем будем ссылаться на обобщенный каталог KERNEL,
означающий любой каталог ядра
Таблица 12.2. Подкаталоги котолого /KERNEL в Solons
Подкаталог	Содержимое.
orv	Загружаемые объектные файлы для драйверов устройств и файлы
	конфигурации, содержащие адреса всех устройств
misc	Загружаемые объектные файлы для различных подпрограмм ядра
CPL	Процессорные модули для машин UltraSPARC
si mod	Модули STREAMS
sparc9	64-разрядное ядро
is	Модули ядра, связанные с файловыми системами
exec	Модули для расшифровки форматов исполняемых файлов
sched	Модули планирования процессов
sys	Загружаемые системные функции
qenunix	Стандартное ллатформно-независимое ядро
LiJllX	Базовое нлатформно-зависимое ядро
Обычно нет необходимости менять файлы в этих каталогах, если только
не выполняется инсталляция нового драйвера. Единственным исключением
могут быть файлы с расширением conf в каталоге KERNEL/drv. в которых
Ггова 12 Драйверы и ядро
251
rootfs
rootdev
forceload
exclude
moddir
set
maxusers
pt_cnt
max_nproc
содержатся параметры конфигурации конкретных устройств. Но даже их
нужно менять только тогда, когда этого требует производитель устройства.
Конфигурирование ядра посредством файла /etc/system
Файл /etc/system в Solans является главным конфигурационным файлом
ядра. Директивы и переменные, которые могут поянляться в этом файле,
перечислены в табл. 12.3. Переменным нужно назначать значения с помошыо
директивы set.
Тоблицо 12.3. Директивы и переменные, используемые в фойле /etc/system
Имя ______ Тит? Нозночение_____________________________________________
D	Задает	тип файловой системы корневого раздела
D	Задает	местоположение корневого раздела
D	Задает	драйверы ("модули"), которые должны быть загружены
D	Задает	модули, которые нс нужно загружать
D	Задает	альтернативное местоположение модулей
D Задает переменные настройки ядра (например, maxusers)
V Определяет размеры таблиц и ряд других параметров
V	Задает	число доступных псевдотерминалов
V	Задает	максимальное число процессов
V	Задает	максимальное число пользовательских	процессов
1 D — директива, V — переменная.
Система обращается к файлу /etc/system во время начальной загрузки,
поэтому модифицировать его нужно крайне осторожно, иначе система нс
сможет загрузиться. С помошыо команды boot -а можно задать путь к
резервной копии файла, если она была создана (если ее нет, а имеющаяся
версия не работает, укажите /dev/null).
Пример файла /etc/system
Рассмотрим образец файла /etc/system для простого ядра:
rootfs:ufs
rootdev:/sbus@l,f8000000/esp@0,800000/sd63,0:a
Эти строки говорят о том, что корневая файловая система будет иметь
тип UFS (UNIX File System — файловая система UNIX) и располагаться в
разделе sd3a. Синтаксис, используемым для задания устройства, содержащего
корневую файловую систему, идентичен синтаксису, применяемому в про-
грамме мониторинга openprom системы Sun. Для каждой платформы он свой,
поэтому обратитесь к имеющейся документации или проследите символиче-
ские ссылки в каталоге /dev.
modair: /platform/SUNWrUltra-Enterprfse/kernel:/platform/sun4u/kernel:
/kernel:/usr/kernel
Данная строка (перенос был сделан, так как она не умещалась на
странице) задает путь поиска загружаемых модулей. Эта запись рекомендуется
252
Чость I Основы администрирования
на странице руководства kernel, но она не задана по умолчанию, поэтому ее
нужно установить самостоятельно.
exclude: sys/shwsys
forceload: drv/superplctter
Первая строка исключает из ядра подсистему совместного использования
памяти, что позволяет немного уменьшить его размер (на самом деле это
плохая идея, так как система может начать работать неправильно). Вторая
строка задает загрузку драйвера “суперграфопостроителя".
set raxusers=64
Эта строка обеспечивает настройку размеров таблиц ядра на поддержку
одновременной работы 64-х пользователей.
Отладка конфигурации
Поскольку Solaris динамически формирует системную среду, отладка
сбойной машины может оказаться сложным делом. К счастью, в этой системе
предусмотрены средства, позволяющие отобразить текущую конфигурацию
компьютера.
Команда prlconf выводит на экран сведения, относящиеся к обшей
конфигурации машины, включая ее тип. номер модели, объем памяти и
данные о сконфигурированных аппаратных средствах. Строки, которые
описывают устройства (точнее. их драйверы), оформлены таким образом, что
информация о периферийных устройствах отображается в виде дерева.
Команда sysdef — это улучшенная версия команды prtconf. помимо
обычной информации она также выдает список драйверов псевдоустройств,
настраиваемых параметров ядра и имен загруженных модулей. Если моди-
фицируется стандартное ядро важного компьютера, не забывайте добавить
копию выходных данных команды sysdef в файлы документации по этому
компьютеру.
Информацию о динамически загружаемых модулях можно получить с
помощью команды modinfo. Подобным образом в Solaris загружаются
драйверы устройств, драйверы файловых систем и модули STREAMS. Не
удивляйтесь, если в выводе команды modinfo будет содержаться свыше
пятидесяти позиций. Дополнительная информация приводится в парагра-
фе 12.11.
12.4.	Построение ядро HP-UX
В HP-UX применяется старый подход к построению ядра: все драйверы
включаются в одно большое ядро. Имеется также сложный и запутанный
конфигурационный файл. К счастью, администрапганая утилита SAM позво-
ляет существенно упростить весь процесс. Настоятельно рекомендуем начать
осваивать процедуру построения ядра именно с этой утилиты. Ее графический
интерфейс прост: достаточно выбрать команду в меню, и ядро будет
построено. Единственный недостаток заключается в том, что нужно быть
готовым после активизации команды “Process new kernel” немедленно
перегрузиться.
В этом параграфе мы рассмотрим, как создавать ядро вручную. так как
эта процедура обычно не описана в документации и не столь очевидна, как
в случае применения утилиты SAM. Процесс ручного построения ядра более
Главе 12. Драйверы и ядро
253
управляем, поскольку можно сконфигурировать и скомпилировать ядро, а
затем дождаться нужного времени для перезагрузки системы. Кроме того, не
требуется иметь под рукой Х-терминал и тратить время на многочисленные
движения мышью, когда достаточно ввести всего несколько команд.
Конфигурирование ядра HP-UX осуществляется посредством файла
/stand/system. Предварительно необходимо скопировать этот файл под другим
именем; мы воспользуемся именем system.exampie. Файл system обычно
генерируется утилитой SAM. поэтому он труден для понимания и в нем
отсутствуют комментарии. Единственный способ узнать, что означают все
эти загадочные команды и переменные. — использовать саму утилиту SAM.
Но можно просто загрузить ее и распечатать копию окна с конфигурацион-
ными параметрами. Это позволит получить список имен настраиваемых
переменных, а также краткое описание их назначения с указанием стандарт-
ных значении.
Наш файл system.exampie представляет собой список драйверов, подсистем
и переменных, которые будут встроены в ядро. Устройства обычно перечис-
лены первыми, за ними идут подсистемы. В конце указаны переменные с
их значениями.
GSCtoPCI
asioO
с730
sdisk
sctl
cdfs
nfs_core
STRMSGSZ 65535
dump Ivol
nstrpty 60
Как видите, расшифровать этот список невозможно без помощи утилиты
SAM. Если переменной присваивается значение по умолчанию, то она вообще
не включается в файл. В табл. 12.4 перечислены некоторые наиболее часто
используемые переменные вместе с их стандартными значениями.
Таблице 12.4. Полезные переменные фойло system в HP-UX
Переменная	По умолчанию	Описание
maxfiles lim	1024	Неизменяемое максимальное число открытых файлов в одном процессе
maxusers	60	Максимальное число одновременна работающих пользователей
maxupre	75	Максимальное число пользовательских процессов
np roc	276	Максимальное число процессов
nfile	910	Максимальное число открытых файлов
nflocks	200	Максимальное число блокировок файлов
ninode	476	Максимальное число открытых индексных де- скрипторов
npty	60	Максимальное число псевдотерминалон
nstrtel	60	Максимальное число сеансов telnet
nkchread	499	Максимальное число потоков ядра
254
Часть I. Основы администрирования
После окончания редактирования файла system.example остается построить
ядро с помощью команды mkjccrncl. По умолчанию эта команда берет
установки из файла /stand/system и создает ядро с именем /stand/vmimix.test.
С помощью опции -s можно указать другой конфигурационный файл, а с
помощью опции -о — другое имя ядра В нашем случае команда будет иметь
следующий вид:
1 mk_kern_il -з /stand/system.example -о /stand/vmunix. example
Перезагрузиться можно в любое удобное время. Если нужно, чтобы новое
ядро загружалось автоматически, скопируйте старое ядро /stand/vmunix
куда-нибудь и поместите па его место новое ядро.
12.5.	Конфигурирование ядра Linux
Процедура конфигурирования ядра Linux совершенствуется уже довольно
долгое время, однако она все еше достаточно примитивна в сравнении с
другими операционными системами. Весь процесс сосредоточен вокруг файла
/usr/src/linux/.config. В этом файле приведена вся информация. касающаяся
конфигурирования ядра, но его формат очень труден для понимания. Для
упрощения работы в Linux предусмотрено несколько make-сцснариев, реали-
зующих различные интерфейсы конфигурирования ядра
Если в системе установлена оболочка X Windows, то удобнее всего
воспользоваться командой make xconlig. Она отображает окно конфигурации,
в котором можно выбрать драйверы устройств, добавляемые к ядру (пли
компилируемые в качестве загружаемых модулей).
В отсутствие графической среды на помощь придет команда make
iiienuconlig, работающая на основе библиотеки curses'. Наконец, есть старая
команда make config, которая отображает запрос на изменение каждою
конфигурационного параметра и не позволяет менять сделанные ранее
установки. Мы не рекомендуем ею пользоваться.
Все эти команды просты, так как их действие сводится к установке
нужных опций. Тем не менее, они мало подходят для ситуации, когда нужно
поддерживать несколько версий ядра для различных архитектур или аппарат-
ных конфигураций.
В любом случае генерируется файл .config, имеющий примерно такой
вид:
#	Automatically generated make config: don't edit
I
#	Code maturity level options
*
CONFIG_EXPERIMENTAL=y
*
<	t Processor type and features
#
#	CONFIG_M3Eb is not set
#	CONFIG_M48o is not set
#	CONrIG_M586 is not sec
К CONFIG_M58oTSC is not set
CONFIG M686=y
CON FIG_X8 6_WP_WORKS_OK-y
• Библиотека curses содержит функции, формирующие псевдографический интерфейс в
терминальном окне.
I ново 12. Дроиверы и ядро
255
CONFIG_X86_INVLPG=y
COMF1G_X8 6_BSWAP=y
CONFIG_X8 6_POPAD_OK“y
CONFIG_X8 6_T SC-y
CONFIG_X86_GOOD_APIC=y
Как видите, содержимое файла не слишком понятно; не дается никаких
пояснений относительно того, что означают теги CONFIG. По сути, каждая
строка CONFIG указывает на активизацию того или иного параметра ядра.
Значение у говорит о том. что соответствующий компонент компилируется
вместе с ядром; значение m означает, что компонент будет загружаемым
модулем.
Не все компоненты можно сконфигурировать как модули. В файле .config
сведений об этом нет, поэтому нужно самостоятельно “покопаться” в
документации. Не так-то легко узнать и назначение тегов CONFIG. Обычно
данную информацию можно извлечь из файла Config.in, имеющегося в
каталоге каждого драйвера. Но собирать все эти файлы нелегко, так что
лучше просто воспользоваться командой make xconfig или make menuconfig.
После того как создано рабочее ядро, ему нужно на этапе начальной
загрузки передать специальные конфигурационные параметры, например имя
корневого устройства или инструкцию, указывающую на необходимость
проверки нескольких Ethernet-плат. За передачу этих параметров отвечает
LILO — загрузчик Linux. Статические параметры конфигурации можно задать
в файле /etc/lilo.conf, указав ключевое слово append; дополнительная
информация была приведена в параграфе 2.2.
Если отредактировать файл lilo.conf не представляется возможным (что-то
было сделано не так и машина не загружается), требуемые параметры можно
задать при запуске LILO. Например, в строке приглашения LILO введите
следующее:
LILO: linux root^/dev/hdal ethsr=O,0,ethO ethar=0,0,ethl
Эта строка заставляет LILO загрузить ядро, обозначаемое меткой “linux”,
использовать в качестве корневого устройство /dev/hdal и проверить наличие
двух Ethernet-плат.
Построение двоичного ядро Linux
Модификация файла .config — это самый важный этап в процессе
конфигурирования ядра Linux, но нужно выполнить еще целый ряд действий,
прежде чем получить готовое ядро. Схема всего процесса такова:
• перейти с помощью команды cd в каталог /usr/src/linux;
•	выполнить команду	make	xconfig или	make menuconfig;
•	выполнить команду	make	dep;
•	выполнить команду	make	clean;
•	выполнить команду	make	bzlmage;
•	выполнить команду	make	modules;
•	выполнить команду	make	modules_instalJ;
•	скопировать файл /usr/src/)mux/arch/i386/boot/bzlmage под именем
/boot/vmlinuz;
256
Чость 1. Основы ОДМИНИСТрироВОНИР
•	отредактировать файл /etc/lilo.conf и добавить в него конфигурационные
параметры для нового ядра;
•	запустить программу /sbin/lilo. чтобы инсталлировать переконфигуриро-
ванный начальный загрузчик.
Выполнять команду make clean не всегда нужно, но. как правило, лучше
очищать переменные среды, чтобы избежать многих труднообнаруживаемых
проблем.
Настройка конфигурации
К сожалению, посредством файла .config невозможно осуществлять
настройку параметров ядра Но это можно делать с помошыо файлов в
каталоге /ргос. являющемся отдельной файловой системой. Они напоминают
стандартные файлы UNIX, но на самом деле являются “шлюзами” к ядру,
позволяющими просматривать и менять его параметры прямо в процессе
работы. Если в одном из этих файлов есть значение, которое требуется
изменить, можно попытаться осуществить запись в этот файл. Правда, нс
все файлы доступны для записи (отображаемые права доступа не лают полной
картины), и нигде в документации не говорится о том, в какие файлы можно
осуществлять запись, а в какие — нет.
Например, чтобы изменить максимальное число файлов, которые можно
открыть в одном процессе, введите такую команду:
# echo 3276В » /prcc/eys/fж/file-max
Со временем можно привыкнуть к столь нетрадиционному интерфейсу
взаимодействия с ядром, тем более что он очень удобен для изменения
конфигурационных параметров. Но сразу предупредим: изменения не явля-
ются постоянными. Чтобы зафиксировать их. нужно добавить соответствую-
щие команды echo в стартовые сценарии. В табл 12.5 перечислены некоторые
полезные файлы.
Тоблицо 12.5. Фойлы в каталоге /ргос, содержошие таста ностроивоемые
порометрь! ядро			
Каталог1	Фойл	По умолчанию	Назначение
F	file-max	4096	Задает максимальное число открытых файлов в одном процессе
F	inode-max	16384	Задает максимальное число открытых индексных деск- рипторов в одном процессе
N	ipforward	0	Разрешает прохождение IP- пакетов. если значение рав- но 1
N	Icni pechoign ureal!	0	Задает	игнорирование ICMP-запросе в команды ping, если значение равно 1
N	i cm p_echo_l gnor ebroadcasts	0	Задает игнорирование ши- роковещательных запросов команды ping, если значе- ние равно 1
F — /ргос/sys/fs, N - /proc/sys/ncf/ipv4.
Глово 12. Дроиверы и ядро
257
12 6. Построение ядра FreeBSD
Приведенные в этом параграфе примеры были получены в системе,
работающей под управлением FreeBSD, но конфигурация для Net BSD,
Open BSD и BSD/OS очень похожа на показанную.
У каждого BSD-ядра есть имя, на которое следует ссылаться в ходе всего
процесса конфигурирования. Это имя может быть любым, но оно должно
указывать на систему, где будет работать ядро. Если ядро предназначено для
выполнения на одной конкретной машине, в качестве имени лучше всего
подойдет сетевое имя компьютера.
Чтобы построить ядро FreeBSD, нужно сначала создать конфигурацион-
ный файл со списком параметров нового ядра. Потом следует запустить
команду config для создания каталога, в котором будет вестись компиляция
ядра. Имя ко нф к i-y рацио иного файла становится именем каталога, а затем и
самого ядра.
Все файлы, необходимые для построения BSD-ядра. находятся в каталоге
/nsr/src/sys, на который обычно создается символическая ссылка в каталоге
/sys. В дальнейшем мы будем обозначать этот каталог прописными буквами
SYS, просто чтобы подчеркнуть, что его местонахождение никакого значения
не имеет. Если найти конфигурационный каталог не удается, обратитесь к
документации
Вот результат выполнения команды Is -F для каталога SYS:
* Is -F
Makefile	ddb/	libkern/	netinec/	pccard/
alpha/	dev/	mesefs/	netipx/	pci/
boot/	gnu/	modules/	netkey/	posix4/
сап/	i386/	msdosfs/	netnatm/	sys/
coda/	i4b/	net/	netns/	ufs/
compile/	isa/	netatalk/	nfs/	vm/
conf/	isofs/	netatm/	ntfs/	
contrib/	kern/	netgraph/	pc98/	
Каталог 1386 содержит модули, зависящие
от архитектуры машины:
% Is —F 1386
Maxefile	Ьоос/
арт/	conf/
eisa/
1386/
ibcs2/ isa/
include/ linux/
В каталоге SYS содержится ряд важных каталогов с общим названием
S\’S/apxumeKmypa/con(. В них находятся конфигурационные файлы, каждый
из которых соответствует одному ядру. В нашей книге мы предполагаем, что
используется архитектура Intel i386. хотя операционная система FreeBSD
поддерживает также архитектуру Alpha. Команда config читает файл конфи-
гурации нз каталога SY’S/flpxwwxvrjj’pfl/conf и создает соответствующий
компиляционный каталог под именем SNS/кютр^ ИМЯ_ЯДРА.
Например, когда система инсталлируется первый раз, создается базовое
ядро с именем GENERIC. Стандартный конфигурационный файл называется
SYS/i386/conf/GENERIC. поэтому компиляционный каталог будет назван
SYS/compile/GENERIC.
Остальные каталоги в ветви SYS содержат различные компоненты ядра,
путем объединения которых формируется исполняемый образ ядра. Точный
перечень файлов и подкаталогов у каждой BSD-систсмы свой.
2эС
Чость I Основы одминистрировония
Схема построения ядра
Процесс построения нового ядра состоит из восьми этапов:
•	ревизия аппаратных средств системы;
•	создание и редактирование файла конфигурации ядра в каталоге
SYS/i386/conf;
•	выполнение команды config в каталоге conf;
•	выполнение команды make depend в компиляционном каталоге;
•	построение ядра с помощью программы make;
•	архивирование старого ядра и инсталляция нового;
•	тестирование и отладка нового ядра;
•	документирование нового ядра.
Ревизия аппаратных средств системы
Прежде чем конфигурировать ядро, нужно определить, какими устрой-
ствами ему придется управлять. Проведите инвентаризацию системы и
составьте список всех устройств, подключе иных к компьютеру, включая:
• жесткие диски, дисководы CD-ROM, другие дисководы и их контроллеры;
•	сетевые интерфейсы;
•	специализированные устройства;
•	клавиатуру и мышь
Подобная ревизия может оказаться чрезвычайно трудоемкой в мире
персональных компьютеров Производители ПК часто продают полностью
собранные машины и не сообщают подробно их комплектацию. А просто
указать ** Ethernet-плата” — недостаточно. Выпускаются сотни различных плат,
у каждой из которых есть десяток модификаций. Как правило, приходится
разбирать компьютер и смотреть, что конкретно установлено внутри него.
Не забудьте на этапе начальной загрузки просмотреть сообщения,
выдаваемые ба юным ядром. Из них можно узнать о том, какие драйверы
следует включить в ядро. Получить текущий список распознанных устройств
можно с помощью команды dmesg. В качестве дополнительного справочника
можно воспользоваться файлом SYS/i386/conf/LINT.
Создание файла конфигурации в каталоге SYS/i386/conf
Решив, какая конфигурация ядра нужна, следует представить эту
информацию в форме, которая будет понятна команде config. Для этого в
каталоге SYS/i386/conf создается файл конфигурации. Имя этого файла может
быть любым, но оно должно быть достаточно содержательным для того,
чтобы любой человек, впервые заглянувший в каталог SYS, смог определить,
для чего предназначено каждое ядро.
Не создавайте файл конфигурации с нуля. Лучше скопируйте файл
GENERIC и удалите из него те части, которые не нужны. Если возникнут
какие-либо вопросы, связанные с этим файлом, обратитесь к документации
на команду config. Хорошим источником информации служат также man-
странипы, посвященные драйверам устройств. В них обычно приводятся
строки из файла конфигурации ядра, которые можно взять в качестве образца
Например, man-страница для устройства de начинается так:
SYNOPSIS
device de
I лево 12 Дройверы и ядро
259
Это именно та строка, которую нужно поместить в файл конфигурации,
чтобы подключить к ядру соответствующее устройство. (Конечно, это не
самый удобный метод, так как. для того чтобы найти шяп-странииу.
необходимо узнать имя драйвера устройства. В этом вам поможет команда
тяп -к.)
Описание формата конфигурационного файла займет добрый десяток
страниц, поэтому мы не будем прерывать обзор процесса построения ядра,
а отложим описание до параграфа 12.7.
Выполнение команды config
Перед запуском команды config необходимо перейти в каталог
SYS/1386/conf, поскольку именно в текущем каталоге команда рассчитывает
найти файл конфигурации, указанный в командной строке. Простые версии
команды принимают один-единственньгй аргумент — имя файла. В более
сложных версиях имеется ряд опций. Чтобы создать компиляционный каталог
для ядра, описанного в файле SYS/i386/conf/EXAMPLE. мы воспользуемся
такими командами:
t cd SYS/1386/conf
И config EXAMPLE
Если команда config выдает сообщения об ошибках, необходимо исправить
файл конфигурации, прежде чем продолжать. Если же ошибок не было,
считайте, что по крайней мере синтаксически конфигурация верна, и
продолжайте работу'.
Выполнение команды make depend
После завершения команды config перейдите в компиляционный катала
нового ядра (cd ../../compIle/EXAMPLE) и введите команду 1s. Должно
отобразиться очень много файлов. Пусть их содержимое вас не волнует:
команда config знает, что делает.
Теперь выполните команду make depend Она инициализирует информа-
цию о связях между файлами для программы make. Эта команда может выдать
большой объем данных
Построение ядра
Находясь в компиляционном каталоге, просто задайте команду make.
В процессе компиляции ядра нужно внимательно следить за сообщениями
об ошибках Программа make, как правило, выявляет ошибки и прерывает
компиляцию, но никогда не помешает проявить бдительность. В качестве
дополнительной меры зашиты укажите команду tee, которая заставит
программу make регистрировать в журнальном файле все сообщения,
посылаемые на терминал:
# make I & tee ERRS.LOG
Оператор & после знака канала указывает на то. что через канал будут
направляться как сообщения об ошибках, так и информационные сообщения.
Пользователи интерпретатора Boume shell должны воспользоваться такой
командой:
I make 2>4il I tee ERRS.LOG
260
ЧоС'Ь I. Основы одминистрировония
Если в процессе компиляции возникла ошибка, нужно прежде всего
проверить файл конфигурации. Сообщения об отсутствующих файлах или
неопределенных подпрограммах говорят о том, что, возможно, какой-то
элемент файла пропущен. Причиной сообщений о синтаксических ошибках
может быть файл конфигурации или собственно система, хотя последнее
маловероятно.
Инсталляция ядра
Перед начальной загрузкой нового ядра убедитесь, что сможете восста-
новить систему, если с ней что-нибудь произойдет. Никогда не заменяйте
старое ядро новым непосредственно, ибо в случае катастрофы неоткуда будет
загрузиться. Раньше ядра назывались /vmunix. но в наши дни в каждой
операционной системе используется свое соглашение об именовании ядер.
Во FreeBSD ядро называется /kernel.
Необходимо создать резервную копию старого ядра, скопировав файл
/kernel под именем /kernel, works. Во всех системах предусмотрены средства
сохранения загружаемое™ старого ядра на время тестирования нового.
Конкретнее об этом говорилось в глазе 2. Дополнительную информацию
можно получить в документации
Имя ядра /kernel может быть жесткой ссылкой на другой файл, поэтому
достаточно просто создать ссылку на новое ядро, а не копировать его поверх
старого. Если ядро не называется /kernel и нужная ссылка не создана, то
загрузчик не сможет найти ядро.
Тестировоние и отладка ядра
Если система загрузилась успешно, то, скорее всего, все в порядке. Но
не помешает перестраховаться и провести ряд дополнительных проверок.
Попробуйте «пустить команду 1s хотя бы для одного каталога в каждой
файловой системе. Отсутствие ошибок означает, что файловая система
функционирует нормально Выполните команду ping, указав адрес соседнего
компьютера, чтобы проверить правильность работы сетевой платы.
Документирование ядра
Прежде чем со спокойной дутой идти пить кофе, вернитесь к исходному
файлу SYS/i386/conf/Ш/ЯЯ27РЛ и добавьте в нею подробные комментарии,
чтобы через полгола-год. когда опять нужно будет прочесть этот файл, можно
было попять его содержимое.
Ьсли на диске много меша, сохраните каталог SYS/compilc/ЯЛ/Я ЯДРА
для ускорения последующих изменений. Когда свободного пространства
недостаточно, просто удалите лот каталог: все его содержимое можно будет
повторно сгенерировать с пом о шью команды config.
12.7 Создание файла конфигурации в BSD-системе
Создание факта конфигурации в каталоге S/i38b/conf — самый труд-
ный этап построения BSD-ядра; весь остальной процесс выполняется чисто
механически.
Файт конфигурации — это перечень управляющих фра г, каждая in
которых занимает не менее одной строки. Строка, начинающаяся со тпаки
табуляции, считается продолжен нем предыдущей Все. чго находится между
Глава 12. Дройверы и ядоо
261
знаком решетки (#) и концом строки, является комментарием, причем пустые
строки игнорируются. От аргументов ключевые слова отделяются пробелами.
Во всех остальных случаях пробелы и знаки табуляции игнорируются.
Целые числа в файле конфигурации могут быть представлены в
шестнадцатеричном, восьмеричном или десятичном формате. Восьмеричные
числа идентифицируются начальным нулем, а шестнадцатеричные — пре-
фиксом Ох. Если символьная строка содержит числа, которые необходимо
трактовать как текст, ее нужно заключить в двойные кавычки.
Управляющая фраза начинается с ключевого слова, которое определяет,
как нужно интерпретировать остальную часть строки. Далее следуют аргу-
менты. Для некоторых ключевых слов можно указывать список аргументов,
разделенных пробелами или запятыми, но удобнее задавать только по одному
аргументу в строке. Если для ключевого слова задается много аргументов, то
допускается указание нескольких идущих подряд фраз с данным ключевым
словом и разными аргументами.
Порядок управляющих фраз обычно не имеет значения. Традиционно
используется порядок, показанный в табл. 12.6.
Тоблицо 12.6. Ключевые слово, используемые в фойпох конфигуроции BSD-систем
Ключевое слово	Функция		 __
machine	Задает тип машины
cpu	Задает тип центрального процессора
ident	Задает имя ядра
maxusers	Задает размеры таблиц ядра
options	Задает различные опции компиляции
config	Назначает корневую область и область подкачки
controller	Объявляет контроллер диска или ленты
disk	Объявляет диск, подключенный к контроллеру
tape	Объявляет ленту, подключенную к контроллеру
device	Объявляет устройства без контроллеров
pseudo-device	Объявляет псевдоустройства
Ключевое слова maxusers
Ключевое слово max users задает размеры нескольких важных системных
таблиц. Как следует из названия, аргументом здесь является максимальное
число пользователей, которые могут одновременно работать в системе (хотя
в большинстве версий UNIX предел как таковой не устанавливается).
В общем случае следует увеличивать этот параметр на единицу для каждого
из пользователей, которые предположительно будут одновременно работать
в системе. Если конфигурируется ядро для сервера NFS, параметр maxusers
соответствует количеству машин-клиентов. Для каждого буфера кадров, с
которым может работать графическая многооконная система, нужно добавить
число восемь.
Параметр max users влияет на значения нескольких других параметров
ядра, в частности на максимальное число процессов, число записей в таблице
дескрипторов файлов и число буферов для терминальной подсистемы
262
Чость I. Основы одминистрировония
ввода-вывода. Самую важную роль играет первый из перечисленных пара-
метров. Вот формула, по которой он вычисляется:
Максимальное число процессов - 20 + I6*maxusers
Здесь учтено, что около 18 процессов запускаются при загрузке ядра.
Ключевое слово options
Директива options предназначена для объявления переменных. интер-
претируемых препроцессором в ходе компиляции ядра Существуют две
формы этой директивы В первой из них определяются имена переменных,
но им не присваиваются конкретные значения. Эти имена используются для
того, чтобы указать, включена опция или нет (директивы препроцессора
#ifdef и fiifndef). Когда аргументом директивы options является имя,
то определяется соответствующая макроконстанта препроцессора. Вот. к
примеру, фраза, включающая в ядро поддержку NFS:
options NFS
Обратите внимание на то, что во FreeBSD любая строка конфигураци-
онного файла, содержащая буквы и цифры, должна быть заключена в
кавычки. Например, поддержка файловой системы 1SO-9660, используемой
при работе с компакт-дисками, активизируется следующим образом:
options "CD9660"
Во второй форме директива не только определяет переменную, но также
присваивает ей конкретное значение Ядро использует данную переменную
так, как будто это константа, а препроцессор языка С выполняет необходимые
подстановки динамически Переменная такого типа объявляется посредством
следующего синтаксиса:
options символ="значение"
Например, для изменения значения переменной MAXDSIZ (максимальный
объем виртуальной памяти, которую можно выделить сегменту данных одного
процесса) используется такая строка:
options MAXDS 12“="(64*1024’1024)"
В этом примере для переменной MAXDSIZ задано значение 64 Мбайт.
Ниже перечислены наиболее распространенные опции. Ни одна из них
не требует задания каких-либо значений. Полный перечень опций должен
предоставляться поставщиком.
INET Эта опция включает поддержку сетевых протоколов. При ее отсутствии
многие программы будут работать неправильно, так что опцией она является
лишь номинально. Необходимо также включить псевдоустройство loop (см
ниже). Опция INET активизирует сетевую поддержку только со стороны
программного обеспечения. Объявление сетевых устройств дается в кон-
фигурационном файле позже.
FFS Данная опция позволяет подключать к машине локальные диски. Она
устанавливается всегда, кроме случая, когда формируется исключительно
“тонкое” ядро для бездискового клиента.
NFS Эта опция включает поддержку NFS. Она требуется как для клиентов, так
И для серверов NFS.
Глово 12. Драйверы и ядро
263
GATEWAY Такую опцию следует устанавливать ня машинах, которые содержат более
одного сетевого интерфейса и предназначены для выполнения функций
маршрутизации и пересылки сообщений в сети internet. В настоящее время
эффект от этой опции незначителен: они задает увеличение размеров
некоторых структур ядра, чтобы оно могло справляться с ожидаемой
нагрузкой, и обеспечивает реализацию специального сетевого режима, если
один из интерфейсов выходит из строя.
Ключевое слово config
Директива config используется для задания местоположения корневого
раздела на дисках системы. Корневой раздел — самый верхний элемент
иерархии файловой системы. Он содержит каталог / и несколько других
важных файлов и подкаталогов. Информация о том. как монтировать
файловые системы, обычно хранится в файле /ctc/fsiab. но операционная
система может добраться до него только после монтирования корневого
раздела.
Более подробные сведения о файле fstab содержатся в параграфе 8.3.
Для начальной загрузки файловой системы информацию о разделе,
включающем корневой каталог, нужно либо интегрировать в ядро путем
компиляции последнего, либо (в некоторых системах) передать ядру посред-
ством загрузчика. Что касается раздела подкачки, то ситуация немного проще,
потому что подкачка вряд ли будет иметь место до того момента, как
стартовые сценарии (/etc/rc*) запустят команду swapon.
Синтаксис директивы config таков:
config имя_ядра root on раздел
Параметр имя ядра задает файл, в котором будет храниться скомпилиро-
ванный образ ядра. Ядра FreeBSD называются kernel, имена альтернативных
ядер должны идентифицировать диск, который они используют для хранения
корневого раздела (например, dakeniel)
Параметр раздел сообщает о том в каком разделе находится корневая
файловая система. Для IDE-дисков это обычно раздел wdO. а для SCSI-
дисков — daO.
Полностью директива config выглядит примерно так:
config kernel root ©л wdO
Возможность построения альтернативных вариантов ядра полезна с точки
зрения планирования мероприятий по ликвидации последствий аварии.
Второй корневой раздел, оснащенный своим собственным ядром, может
оказать большую помощь в случае повреждения основного корневого раздела.
Если вспомогательный раздел управляется тем же контроллером. что и
поврежденный, обязательно перед перезагрузкой убедитесь в работоспособ-
ности аппаратуры, иначе вы рискуете разрушить запасной раздел точно так
же, как перед этим разрушили основной.
В некоторых системах процедура начальной загрузки производится с
дискеты или компакт-диска Загрузчик расположенный на дискете, знает
местонахождение ядра и может управлять его вызовом Если имеется запасной
корневой раздел, то придется создать еше одну загрузочную дискету, которая
будет его использовать.
264
Чость I Основы одминистрировония
Аппаратные устройства
Синтаксис объявлений устройств довольно путаный, и основные элемен-
ты, необходимые для того, чтобы заставить систему работать, изменяются от
машины к машине. Информацию об устройствах можно получить в разделе 4
документации по BSD-системам. В большинстве тяп-страниц, посвященных
драйверам устройств, приводится пример конфигурационной строки, которую
следует добавить к ядру.
Не воспринимайте приведенные здесь инструкции буквально. Ниже
рассматривается обший синтаксис, но, поскольку мы предполагаем, что в
большинстве случаев вы будете модифицировать базовую конфигурацию
системы, а не создавать ее заново, мы не будем рассказывать о том, как
писать свои собственные спецификации устройств с нуля
Вот исходная форма объявления:
типустройства имя устройства at соединение port адрес
{класс_ус^ройстваI irq прерывание
Не все предложения этой инструкции применимы ко всем устройствам.
Параметр niwt^ycmpoucniea, как следует из его названия, задает тип объяв-
ляемого устройства. С некоторыми устройствами связаны свои ключевые
слова, в частности controller и disk. Все остальные устройства иденти-
фицируются общим словом device.
Параметр ымя_устройства — это стандартное имя устройства (точнее,
имя драйвера устройства) плюс его логический номер. Например, имя первого
IDE-контроллера — wdcO. Анализируя базовую конфигурацию, можно поис-
кать информацию о каждом устройстве в разделе 4 документации и выяснить,
какое устройство скрывается за тем или иным именем. Отметим, что
логический номер устройства не имеет никакой связи с номером устройства,
заданным аппаратно.
Параметр соединение сообщает ядру, где необходимо искать данное
устройство. Для дисковых и ленточных накопителей, как правило, указывается
имя контроллера. Для контроллеров и прочих внешних устройств задается
имя шины или контроллера шины. Например, в следующих строках
объявляются системная шина ISA. подключенный к ней IDE-контроллер и
IDE-диск. соединенный с контроллером:
controller isaO
controller	wccO	at xsa? port ”ZO_WD1‘' bio rrq 14
disk	wdcO	at wdcO drive 0
В большинстве случаев достаточно констатировать, что устройство
подключено к контроллеру конкретного типа, не указывая, к какому именно
Например, место подключения IDE-контроллера wdcO обозначено выше не
как isaO или isal, а как isa?.
Параметр адрес, аргумент ключевого слова port, обозначает местонахо-
ждение регистров устройства в адресном пространстве шины или объедини-
тельной панели, к которой оно подключено. Для контроллеров и устройств,
подключенных непосредственно к шине, этот параметр чаще всего задан.
С устройством каждого типа связано определенное число адресных ячеек,
которые оно занимает в адресном пространстве шины. Задавать значения
нужно только для устройств ISA и EISA. PCI-драйверы динамически
определяют диапазон адресов, с которыми работает устройство.
Глово 12. Дройверы и ядро
265
В параметре прерывание задается вектор прерываний (IRQ), используемых
устройством. Как и в предыдущем случае, он требуется только для устройств
ISA и EISA, a PCI-драйверы сами определяют нужные прерывания.
С некоторыми устройствами нужно связывать параметр класс_устройства.
В основном это относится к сетевым устройствам и отдельным контроллерам.
Получить соответствующую информацию можно на тап-страннце по кон-
кретному устройству.
Вот строка конфигурации сетевой ISA-платы NE200. в которой исполь-
зуются все перечисленные выше параметры:
device edC at isa? port gx36C net irq 10
В этой строке сообщается о том, что устройство edO нужно искать на
шине ISA по адресу 0x360. Устройство использует прерывание 10
Гораздо чаще те или иные ключевые слова не включаются в директиву.
Ниже показана строка конфигурации Ethernet-платы, на этот раз подклю-
ченной к шине PCI:
device deO
Благодаря достоинствам интерфейса PC! мы избавляемся от необходи-
мости знать все детали функционирования устройства.
Самый эффективный способ построения вышеупомянутых объявлений —
группировать связанные устройства. Если в системе есть какой-то контроллер,
разместите рядом с его строкой строку подключенного к нему устройства.
Например, сразу после строки для контроллера IDE следует расположить
конфигурационные строки подключенного к нему IDE-диска или дисковода
CD-ROM. Так гораздо легче проследить связи между устройствами.
Ключевое слово pseudo-device
Теоретически драйверы псевдоустройств — это программы, которые ведут
себя как драйверы устройств, но при этом не поддерживают никаких реальных
аппаратных средств. Мы говорим ‘’теоретически", потому что некоторые
компоненты ядра, маскирующиеся под псевдоустройства, вообще не работают
как драйверы устройств, по крайней мере с точки зрения пользователя.
Синтаксис директивы pseudo-device таков:
pseudo-device имяустройства число_экзеыпляров
Аргумент имя_устройства — это имя псевдоустройства. а необязательный
аргумент чисяо_экземпляров — целое число, показывающее, сколько подобных
воображаемых устройств якобы имеется. Во многих драйверах счетчик
экземпляров не используется.
Обычно применяется лишь несколько псевдоустройств, но большинство
из них необходимо для нормальной работы системы. В некоторых системах
предусмотрен ряд нестандартных псевдоустройстн. которые поддерживают
оконные подсистемы, дополнительные клавиатуры и вспомогательные дис-
плеи. Прочтите в документации о том, как обращаться с такими устройствами,
или просто активизируйте в базовом файле конфигурации все псевлоустрои-
ства, чтобы не возникало случайных конфликтов.
266
Чость I Основы ОДМИНИСТрИрОВОНПЯ
Ниже приведен перечень некоторых распространенных псевдоустройств:
ply Устройства PTY — это псевдотерминалы. Они имитируют настоящие
терминалы, но вместо реального терминала к каждому из них
подключен какой-нибудь UNIX-процесс. Псевдотерминалы активно
используются сетевыми программами, такими как ssh, xterm. telnet и
rlogin. Кроме того, с ними взаимодействуют некоторые стандартные
утилиты (например, script), обрабатывающие посредством них вход-
ную информацию.
loop Драйвер loop имитирует устройство сопряжения с сетью, в которую
входит только локальный компьютер (так называемый интерфейс
обратной связи). Этот драйвер позволяет автономным машинам
использовать сетевое программное обеспечение и, кроме того, пре-
доставляет машине стандартный метод направления сетевых пакетов
самой себе. Он иеобходим, если установлена опция INET.
Подробнее об интерфейсах и адресации вы узнаете в главе 14.
Пример файла конфигурации
Давайте рассмотрим образец файла конфигурации какого-нибудь простого
ядра, которое назовем EXAMPLE:
machine	”1386"
cpu	"I386CPU"
cpu	"1486 CPU"
cpu	"I5B6_CFU"
cpu	"1686 CPU"
ident	EXAMPLE
maxusers	32
Первые несколько строк говорят о том, что мы создаем ядро для
платформы Intel PC и оно должно поддерживать все указанные типы
процессоров. Имя конфигурации — EXAMPLE. Ядро конфигурируется в
расчете на одновременную работу максимум 32 пользователей и 532
процессов.
options options	I NET "СПЭббО"	#	Internet: TCP/IP файловая система ISO 9660		(CD-ROM)
options	FFS		локальная файловая система (FFS)		
options	NFS	#	сетевая	файловая система	(NFS)
Это лишь небольшой фрагмент секции опций из конфигурационного
файла. Наше ядро конфигурируется в расчете на поддержку работы в Internet,
локальных файловых систем, файловой системы ISO-9660 (используется
компакт-дисками) и NFS.
config kernel root on wdO
Основной корневой раздел будет расположен на первом жестком диске
IDE.
controller IsaO
controller pnpO
controller eisaO
controller pciO
Глово 12 Дроиверы и ядро
267
Приведенные выше строки объявляют различные шинные интерфейсы,
поддерживаемые в системе: ISA, EISA и PCI- Во второй строке включается
поддержка технологии Plug and Play для ISA-устройств (pnpO).
controller	atkbdcO	at isa?	pert IO_KBD	tty
device device	ackbdO psmO	at isa? at isa?	tty irq 1 tty irq 12	
device	vgaO # хранитель экрана pseudo-device splash		at isa?	port ? conflicts	
# eysccns — это стандартный драйвер консоли, device	асО	at isa? tty				напоминающей консоль SCO
В этих строках объявляются все элементы, необходимые для работы
консоли: клавиатура и ее контроллер, мышь, видеоплата и сама консоль.
* Гибкие диски
controller disk disk	fdcO fdO fdl	at ar	isa? port ' fdcO drive fdcO drive	"IO__FD1” bio irq 0 1	6 drq 2
# Контроллеры	и жесткие	диски IDE			
controller	wdcO	at	isa? port '	"IO WDl" bio irq	14
disk	wdO	at	wdcO drive	0	
disk	wdl	at	wdcO drive	I	
controller	wdcl	at	isa? port '	"IO_WD2" bio irq	15
disk	wd2	at	wdcO drive	0	
disk	wd3	at	wdcO drive	1	
Здесь объявляются различные контроллеры и диски: контроллер гибких
дисков, два дисковода гибких дисков (используется только один из них. но
объявить второй не помешает) и два контроллера IDE с соответствующими
дисками.
options
options
device
ATAPI	I поддержка ATARI ДЛЯ шины IDE
ATAFISTATIC # не делать загружаемым модулем
acdO	# IDE-дисковод CD-ROM
Во FreeBSD нужно включать показанные выше специальные опции для
поддержки IDE-устройств. Драйвер IDE можно сконфигурировать как
загружаемый модуль ядра, но если IDE-диск содержит корневой раздел,
драйвер должен подключаться статически. В противном случае система не
сможет обнаружить корневой раздев на этапе начальной загрузки.
pseudo-device loop
pseudo-device ether
pseudo-device bpfilter 4
# сетевой интерфейс обратной связи
♦ поддержка Ethernet
f фильтр пакетов Беркли
Из этих псевдоустройств только первое (loop) является обязательным,
но в общем случае все псевдоустройства следует включать в конфигурацию
GENERIC. Псевдоустройство ether необходимо для поддержки Eihemet-
оборудования. Псевдоустройство bpfilter требуется для запуска утилиты
tepdump и DHCP-клиентов. Его можно удалить. чтобы запретить пользовате-
лям выполнять анализ сетевых пакетов. Но в этом случае сам администратор
лишится возможности производить диагностику сети.
268
Чость I Основы одминистрировония
Настройка ядра
Ядро KERNEL нс настроено на максимальную производительность, что
будет особенно заметно, если инсталлировать в системе крупный Web-сервср.
Приведем несколько указании по улучшению работы ядра FreeBSD.
Частично динамическую настройку ядра FreeBSD можно выполнять с
помощью команды sysctl, которая реализует пользовательский интерфейс
доступа к некоторым внутренним структурам и параметрам ядра. Это очень
мощная (и опасная) команда.
Команда sysctl -а выводит список переменных ядра. Почти все параметры,
перечисленные в табл. 12.7, доступны для динамического изменения. В до-
кументации очень мало говорится о том. что означает каждая переменная;
подсказкой служат только имена переменных.
Изменения, вносимые командой sysctl, теряются при перезагрузке
системы. Как правило, команда sysctl применяется для тестирования; если
же изменения требуется сделать постоянными, нужно отредактировать
конфигурационный файл и перекомпилировать ядро. Преимущество такого
подхода заключается в том, что в любой момент можно перезагрузиться, и
система вернется в исходное состояние.
В табл. 12.7 перечислены переменные, наиболее часто меняемые с
помощью команды sysctl
Тоблицо 12.7. Важные переменные ядро FreeBSD, доступные для изменения
командой sysctl
Переменная	По умолчанию	Описание
kern.maxfiles	1064	Максимальное число открытых файлов
kern.maxproc	532	Максимальное число процессов
kern.maxf ilesperproc	1064	Максимальное число открытых файлов в одном процессе
ke rn.maxp roeper uid	531	Максимальное число процессов для од- ного пользователя
kern.ipc.nmbclusters	1024	Максимальное число сетевых буферов
kern.Ipc.maxsockecs	1064	Максимальное число доступных сокетов
Обратите внимание на то, что в стандартной конфигурации отдельный
пользователь может занять все позиции в таблице процессов, кроме одной.
Это таит в себе потенциальную угрозу, так как, даже если в системе
действительно работает всего один пользователь, не резервируется место для
запуска системных процессов. Желательно делать больший интервал между
значениями переменных гпахрсос и maxprocperuid.
Ниже мы опишем процесс модификации некоторых самых простых
параметров ядра GENERIC. Обычно это имеет смысл делать на Web-сервере,
хотя рассматриваемые изменения позволяют повысить производительность
большинства сетевых серверов.
maxusers 2Ь6
Параметр rnaxusers влияет на ряд других характеристик ядра, в
частности на максимальное число процессов в системе и для одного
Глово 12. Дройверы и ядро
269
пользователя, максимальное число открытых файлов в системе и в отдельном
процессе, а также максимальное число сетевых буферов. При конфигуриро-
вании сервера желательно устанавливать достаточно высокие лимиты
options NMBCLUSTERS=4096
Здесь задается разумное число сетевых буферов. По умолчанию их всего
256, что недопустимо мало даже в серверах среднего размера.
options CHILD_MAX=1024
В приведенной директиве определяется максимальное число дочерних
процессов в системе. Когда речь идет о сетевом сервере, зто число должно
быть достаточно большим. Как правило, демоны, выполняемые на сервере,
создают дочерний процесс для каждого поступившего запроса на подключение.
options OPEN_MAX-1024
Здесь устанавливается максимальное число дескрипторов файлов в
системе. Обычно это значение должно быть равно параметру CHILD_MAX,
так как с каждым запросом на подключение связывается свой дескриптор.
12 8. Добавление драйверов устройств
Драйвер устройства — это программа, которая обеспечивает взаимодей-
ствие системы с определенным компонентом аппаратной среды. Драйвер
выполняет роль переводчика команд конкретного устройства на "язык”
API-функций ядра. Благодаря наличию драйверов обеспечивается приемле-
мый уровень независимости UNIX от внешних устройств.
Драйверы являются компонентами ядра, а не пользовательскими процес-
сами. Тем не менее, доступ к драйверу возможен как из ядра, так и со
стороны команд пользовательского уровня. Для последних в каталоге /dev
создаются специальные файлы устройств. Ядро преобразует операции,
выполняемые над этими файлами, в обращения к коду драйвера.
Раньше, во времена хаоса, для большинства аппаратных устройств
требовались интерфейсная плата и специальный драйвер. Затем, когда многие
системы стали поддерживать технологию SCSI в качестве стандартного
интерфейса подключения дисков, лент и дисководов CD-ROM, а поставщики
интегрировали в свои системы поддержку стандартных технологий, в
частности Ethernet, появилась надежда на стабильность.
Потом наступила эпоха ПК. которая снова внесла хаос в наш прекрасный
мир системных администраторов. Власть опять захватили патентованные
интерфейсы, появились многочисленные “стандарты” и всевозможные аппа-
ратные устройства с различными уровнями поддержки со стороны операци-
онной системы. И вот что мы видим;
•	в Linux поддерживается более 30 различных наборов микросхем SCSI для
персональных компьютеров, и каждый из них продается в два раза
большим числом поставщиков;
•	существует более 200 сетевых интерфейсов для персональных компьюте-
ров; эти интерфейсы предлагаются различны ми поставщиками под
разными именами;
•	все время разрабатываются и выпускаются новые, улучшенные, более
дешевые устройства; для каждого из них нужен свой драйвер, работающий
с требуемой версией UNIX.
2/1
Чость I. Основы одминистрировония
Учитывая скорость появления новых устройств, практически невозможно
выпускать дистрибутивы операционных систем, в которых интегрирована
поддержка всех новинок. Поэтому раз за разом приходится самостоятельно
добавлять к ядру новые драйверы.
Изготовители оборудования обращают все больше внимания на рынок
UNIX и даже иногда создают UNIX-версии драйверов. Если повезет, для
имеющегося устройства в системе будет и драйвер, и инструкции по его
инсталляции- Но вероятнее всего, нужный драйвер можно будет найти только
на какой-нибудь неофициальной Web-странине.
Как бы там ни было, ниже мы опишем, что происходит в системе при
добавлении драйвера устройства. Мы предполагаем, trro читатель ознакомился
с приведенной выше базовой процедурой конфигурирования ядра.
Номера устройств
Для многих устройств в каталоге /dev имеются соответствующие
специальные файлы; исключение в современных операционных системах
составляют лишь сетевые устройства. С каждым из этих файлов связан
старший и младший номер устройства. Посредством этих номеров ядро
преобразует обращения к файлу в вызовы нужного драйвера.
Старший номер устройства обозначает драйвер, за которым закреплен
данный файл (другими словами, он обозначает тип устройства). Младший
номер устройства указывает на то, к какому конкретно устройству подобного
типа следует обращаться. Младший номер устройства часто называют просто
номером или экземпляром устройства.
Узнать номера устройств можно с помощью команды Is -I:
% Is -1 /dev/sda
brw-rw----- 1 root disk 8,	0 Mar 3	1999 /dev/sda
Младший номер иногда используется драйвером для выбора конкретной
характеристики устройства. Например, накопитель на магнитной ленте может
иметь в каталоге /dev несколько файлов, обеспечивающих реализацию
различных сочетаний параметров, таких как плотность записи и наличие
режима перемотки. По сути, драйвер волен интерпретировать младший номер
устройства по своему усмотрению. Особенности поведения драйвера можно
узнать на соответствующей тап-странице.
Файлы устройств бывают двух типов: блок-ориентированные и байт-ори-
ентированные. Чтение из блок-ориснтироватюго устройства и запись в него
осуществляется по одному блоку (группа байтов, размер которой обычно
кратен 512) за раз. тогда как чтение из байт-ориентированного устройства и
запись в него может производиться по одному байту. Для некоторых устройств
предусматривается доступ как через блок-ориентированные, так и через
байт-ориснтированные файлы. Например, диски и ленты ведут “двойную
жизнь”, в отличие от терминалов и принтеров.
Драйверы устройств образуют стандартный интерфейс связи с ядром.
В каждом драйвере есть подпрограммы, предназначенные для выполнения
некоторых или всех из перечисленных ниже функций:
attach	close	dump	ioctl	open	probe
psize	read	receive	resec	select	stop
strategy	timeout	transmit	write
Глово 12. Дройверы и ядро
271
Отдельные системные функции удобно реализовывать, используя некий
драйвер устройства, даже если связанное с иим устройство отсутствует в
системе. Такие устройства-**призраки" называют псевдоустройствами. Напри-
мер, пользователю, вошедшему в систему по сети, назначается псевдотерми-
нал (PTY), который с точки зрения высокоуровневого программного
обеспечения ничем не отличается от обычного последовательного порта.
Благодаря такому подходу программы, написанные в те времена, когда все
пользователи еще работали на алфавитно-цифровых терминалах, могут
продолжать функционировать в мире окон и сетей.
Когда программа выполняет операцию нал файлом устройства, ядро
автоматически перехватывает обращение к файлу, ищет в таблице переходов
соответствующее имя функции и передает ей управление. Для выполнения
необычных операций, не имеющих прямых аналогов в модели файловой
системы (таких, как изъятие дискеты из дисковода), используется системный
вызов foctl, который передает пользовательскую команду непосредственно
драйверу
Драйверы и их конфигурационные файлы обычно прячутся как можно
дальше, чтобы какой-нибудь не в меру любопытный пользователь случайно
не испортил их. В табл 12.8 указано стандартное местоположение драйверов
и конфигурационных файлов в наших тестовых системах.
Тоблицо 12.8. Местоположение дройверов и конфигуроционных фойлов
Системе	Конфигуроционные фойлы	Дройверы 
Solaris	/kernel/drv/*conf	/kernei/drv/*
HP-UX	/stand/system	/nsr/conf/*
Linux	/usr/src/liniK/.CGufig	/usr/src/linux/drivere/*
FreeBSD	/ивг/ягс/5ув/1386/соаГ/ЯДРС>	/sys/i386/conf/files* 
В ниже мы рассмотрим три примера добавления драйвера к ядру, для
Solaris, Linux и FreeBSD. Мы не будем описывать эту процедуру для
операционной системы HP-UX, поскольку в ней редко присутствуют
сторонние устройства (а для всех устройств Hewlett-Packard драйверы входят
в состав системы).
Добавление драйвера устройства в Solaris
Проше всего добавить драйвер устройства в Solaris. Драйверы Solaris
обычно распространяются в пакетном виде. Подключить драйвер к системе
можно с помощью команды pkgadd. Если по какой-то причине добавление
не происходит автоматически, это всегда можно сделать вручную, так как
все драйверы реализованы в виде загружаемых модулей.
Драйверы Solaris всегда поставляются в виде объектных файлов, а не в
исходных текстах, как во FreeBSD и Linux. В нашем примере мы добавим
к системе устройство ‘'snarf*. Его драйвер должен быть представлен как
минимум двумя файлами: snarf.o (собственно драйвер) и snarf.conf (файл
конфигурации). Оба должны находиться в каталоге /platforni/sun4u/kernd/drv
После копирования конфигурационного файла можно отредактировать
его, чтобы задать параметры конкретного устройства. Обычно этого делать
не требуется, но иногда некоторые параметры доступны для "тонкой"
настройки.
272
Чстгтъ I Основы ОДМИНиСтрирОВОНИЯ
Далее нужно загрузить модуль. Модули подключаются к работающему
ядру командой add_drv (подробнее о загружаемых модулях речь пойдет в
параграфе 12.11). В нашем случае команда имеет вид add_drv snarf. Вот и
все! Более простую процедуру трудно себе представить.
Добавление драйвера устройство в Linux
В Linux драйверы устройств распространяются в одной из трех форм:
•	“заплата” к конкретной версии ядра;
	загружаемый модуль;
•	инсталляционный сценарий, устанавливающий соответствующие “заплаты”.
Чаще всего встречаются именно “заплаты”. Установить их можно
следующим образом:
I cd /uar/aro/linux : patch, -pl < driver.diff
Ниже мы рассмотрим, как вручную добавить к ядру драйвер сетевого
устройства "snarf'. Это очень сложный и утомительный процесс, особенно
если сравнивать его с другими тестовыми операционными системами.
По существующему соглашению исходные файлы ядра Linux хранятся в
каталоге /usr/src/linux. В подкаталоге drivers нужно найти еще один подка-
талог, соответствующий типу добавляемого устройства. Вот как выглядит
список имеющихся подкаталогов:
% 1в -F /иах/вгс/llnux/dxive»					
Ma kefile	edrom/	12с/	nubus/	sbus/	telephony/
acorn/	char/	isdn/	parpert/	scsi/	usb/
арЮОО/	dio/	macintosh/	pci/	sgi/	video/
atm/	fc4/	misc/	pemcia/	sound/	zorro/
block/	i2c/	net/	pnp/	tc/	
Чаше всего драйверы добавляются в каталоги block, char, net. usb, sound
и scsi. В них содержатся драйверы блок-ориентированных устройств (напри-
мер, IDE-дисков), байт-ориентированных устройств (например, последова-
тельных портов), сетевых устройств, USB-устройств, звуковых плат и
SCSI-плат соответственно. В других каталогах находятся, в частности
драйверы для самих шин (pci, nubus и zofto); маловероятно, чтобы потребо-
валось добавлять в них файлы. Некоторые каталоги предназначены для
хранения платформ но-зависимых драйверов (Macintosh, acorn, арЮОО). Есть
каталоги для специализированных драйверов (atm, isdn, telephony).
Поскольку наше устройство является сетевым, мы поместим его драйвер
в каталог drivers/net. Потребуется модифицировать следующие файлы:
•	drivers/net/Makefile0 чтобы драйвер мог быть скомпилирован;
•	drivers/net/Config.in, чтобы устройство появилось в списке конфигурируе-
мых настроек;
•	drivers/net/Space.c, чтобы устройство искалось на этапе начальной загрузки.
После размещения файлов с расширениями .с и .h в каталоге drivers/net
нужно добавить запись о драйвере в файл drivers/net/Makefile. Вот эти строки
(они располагаются ближе к концу файла):
ifeq (S(CONFIGSNARF),у)
L—OBJS +« snarf.о
else
Глово 12 Дройверы и ядро
273
ifeq (S(CONFIG_SNAHF),m)
M_OBJS +« snarf.о
endif
endif
Благодаря таким строкам драйвер может быть сконфигурирован как
загружаемый модуль либо непосредственно встроен в ядро.
Когда запись добавлена в файл Makefile, нужно убедиться, что устройство
будет доступно для конфигурирования при настройке ядра. Все сетевые
устройства должны быть перечислены в файле drivers/net/Config.in. В нашем
случае требуется добавить приведенную ниже строку, чтобы драйвер был
встроен либо как загружаемый модуль, либо как интегрированная часть ядра
(в соответствии с тем, что было заявлено в файле Makefile);
tristate 'Snarf device support' CoNFIG_SNARF
Ключевое слово tristate означает, что драйвер станет загружаемым
модулем. Если это невозможно, необходимо указать ключевое слово bool.
Следующий элемент инструкции — строка, которая будет отображаться в
окне конфигурации. Это может быть произвольный текст, но он должен
идентифицировать для пользователя конфигурируемое устройство. Последний
элемент инструкции — это конфигурационная макроконстанта. Она должна
быть такой же, как и та, что проверяется в ветви if eq файла Makefile
Наконец, нужно отредактировать файл drivers/net/Space.c. В нем содер-
жатся ссылки на подпрограммы опроса устройств, а также определяется
очередность опроса. Нам понадобится отредактировать файл в двух разных
местах. Во-первых, нужно добавить ссылку на функцию опроса, а затем
внести устройство в список опрашиваемых устройств.
В верхней части файла Space.c находится группа ссылок на функции.
Добавим следующую строку:
extern int snarfjprobe(struct device ’);
Прежде чем вносить устройство в список опроса, нужно определить,
какой именно список нас интересует. Существуют отдельные списки для
каждого типа шины (PCI. EISA. SBUS, MCA. ISA. параллельный порт и
т.д.). Устройство “snail” является РС1-устройством, поэтому нужный нам
список называется pci_probes. За строкой
struct devprobe pcijprobesI) ____initdata ~ {
следует упорядоченный список устройств. Устройства, стоящие выше, опра-
шиваются раньше. Порядок опроса не имеет особого значения для PCI-уст-
ройств, но для некоторых устройств он важен. Нужно просто убедиться, что
устройство “snarf” обнаруживается, поэтому в начало списка мы поместим
такие строки:
struct devprobe pci_probes[]  initdata — f
#ifdef CONFIGSNARF
sr.arf_probe, 0},
flendif
Теперь устройство добавлено к ядру Linux. При следующем конфигури-
ровании ядра устройство должно появиться в списке конфигурируемых
настроек в группе “Network devices” (сетевые устройства).
274
Чость I. Основы ОДМИНИСТрИрОВОНИЯ
Добавление драйвера устройства во FreeBSD
Добавление совершенно нового драйвера во FreeBSD предполагает
включение его описания в файлы конфигурации и редактирование исходного
текста ядра с целью включения ссылок на подпрограммы драйвера. Эта
процедура — не для слабонервных!
В качестве примера рассмотрим систему FreeBSD. Следует заметить, что
все BSD-системы (в том числе NetBSD и OpenBSD) функционируют схожим
образом, за исключением того, что местонахождение файлов может быть
разным. Для примера добавим в систему устройство “scarf” (псевдосетевое
устройство).
В первую очередь нужно скопировать исходные файлы в соответствующий
каталог:
I ср -'bbraun/enarf.с /ays/pci/snarf.с
Так как наше устройство относится к PCI-устройствам, мы поместим
исходные файлы в каталог SYS/pci ко всем остальным PCI-драйверам. Если
устройство не попадает ни в одну из существующих категорий, следует создать
для файлов новый каталог и отредактировать файл SYS/i386/conf/files.i386
К нашему драйверу это не относится, поэтому он будет автоматически
скомпилирован и подключен к ядру.
Далее необходимо добавить запись об устройстве в конфигурационный
файл ядра. Мы включим следующую запись в конфигурацию EXAMPLE:
device snfG t Snarf, псевдо-сетевое устройство
Эта строка является инструкцией для команды config на подключение
файлов драйвера к ядру. Поскольку у сетевых устройств нет ни старших, ни
младших номеров, их соответственно не нужно указывать. В случае блок-ори-
ентированного или байт-ориентироваиного устройства ситуация была бы иной.
Когда инсталлируется драйвер стороннего поставщика, нужно поискать
в документации к нему старший и .младший номера устройства Следует
использовать только номера, упомянутые в документации, иначе возможны
конфликты с другими устройствами. Старшие номера устройств задаются в
файле SYS/i386/conf/niajors.i386 Запись, добавляемая в этот файл, зависит
от устройства. Получить информацию можно в документации к драйверу
Следующие этапы предусматривают:
•	запуск команды config и построение нового ядра:
•	создание резервной копии старого ядра и инсталляцию нового ядра;
•	перезагрузку и тестирование нового ядра.
Эти операции рассматривались выше в настоящей главе. В самом конце
может потребоваться создать файлы устройства (см следующий параграф) и
протестировать само устройство.
12.9. Файлы устройств
По существующему соглашению файлы устройств хранятся в каталоге
/dev". В больших системах, особенно гам, где используются сети и псевдо-
терминалы. количество устройств может исчисляться сотнями. В Solaris и
’ Основные файлы устройств в Solaris хранятся в каталоге /devices, на который автоматически
создаются ссылки в каталоге /dev.
Главе 12 Дройверы и ядро
275
HP-UX эта проблема решается довольно изяшно: для каждого типа устройств
в каталоге /dev выделен отдельный подкаталог: disk, cdrom, terminal и т.д.
Файлы устройств создаются командой mknod, которая имеет следующий
синтаксис:
mknod иия_файла тип старший младший
где имя_файла — создаваемый файл устройства, тип — тип устройства (с.
если это байт-ориентированное устройство, и b - если блок-ориентирован-
ное), старший и младший — соответственно старший и младший номера
устройства. Если создается файл устройства, относящийся к драйверу,
который уже имеется в ядре, просмотрите соответствующую этому драйверу
man-страницу (во FreeBSD — в разделе 4, в Solaris и HP-UX — в разделе 7,
в Linux вообще нет nian-страниц дтя драйверов устройств) и найдите старший
и младший номера, указанные в ней.
Иногда в комплект поставки входит shell-сценарий /dev/MAKEDEV,
который автоматически передает команде mknod стандартные значения
Просмотрите этот сценарий и найдите аргументы, требуемые для имеющегося
устройства. Например, для подключения псевдотерминалов во FreeBSD нужно
использовать такие команды:
#	cd /d*v
#	./MAXKDBV pty
12.10 Соглашения об именах устройств
Соглашения об именах устройств — это нечто весьма неопределенное.
Во многих случаях применяется методика, которую использовали еше при
работе на компьютерах PDP-11 фирмы DEC.
Для устройств, работающих и в блочном, и в символьном режимах, имя
байт-ориентированно го файла обычно начинается с буквы ’г’ (“raw" —
неструктурированный), например: /dev/daO и /dev/rdaO. В соответствии с
другим соглашением этот файл помешается в подкаталог с именем, которое
также начинается с буквы г' (сравните: /dev/dsk/dks0d3s0 и /dev/rdsk/dks0d3s0 j
Однако буква ’г не всегда означает упрошенный (байтовый) режим доступа.
Имена последовательных устройств обычно состоят из префикса tty и
последовательности букв, обозначающей интерфейс, к которому подключен
порт. Иногда для терминала имеется несколько файлов устройств; дополни-
тельные файлы предназначены для поддержки альтернативных методов
управления потоками и протоколов блокировки.
И Подробнее о последовательных портах рассказывалось в главе 7
Имена дисков в BSD-системах часто начинаются с двухбуквенной
аббревиатуры, обозначающей дисковод или контроллер. Затем следует номер
дисковода и имя дискового раздела. Например. daOa — блок-ориентированное
устройство, представляющее раздел а первого дисковода SCSI-контроллера,
a rdaOa — соответствующее байт-ориентированное устройство
Имена накопителей на магнитной денге часто включают не только ссылка
на сам накопитель, но и указание на то, перематывается ли лента после
каждой операции и какова плотность чтепня/записи Каждый поставщик
придерживается своей системы именования ленточных накопителей.
В табл. 12.9 приведены типовые имена широко распространенных
устройств (жестких дисков и дисководов CD-ROM) для наших тестовых
систем.
2/5
Чосгь I Основы одминистрировония
Тоблицо 12.9. Соглашения об именох устройств для дисков и лент1
Система	SCSI-диск	SCSI-дисковод CD-ROM	IDE-диск
Solaria	/dev/[rJdjk/cAtBdNiP	/dev/[r]<Uk/cAtBdNaP	/dev/lr]dak/cAtBdN«P
HP-UX	/d ет/[г ] djk/cAtBdN	/dev/[r]dak/cAtBdN	-
Linux	/dev/sdLP	/dev/acdLP	/dev/hdLP
BSDI	/dev/daNsP	/dev/daNeP{lmh}	/dev/wdNaP
А — номер контроллера, В — SCSI-идентификатор, N — номер устройства, Р —
буква или номер раздела.
12.11	. Загружаемые модули ядра
Загружаемые модули поддерживаются в Solaris, Linux и FreeBSD, но
степень поддержки существенно различается. В Solaris ядро является самым
модульным, в Linux — менее модульным, а во FreeBSD модули вообще
используются очень мало.
Помимо всего прочего загружаемые модули позволяют подключать и
отключать драйверы устройств непосредственно в процессе работы ядра. Это
значительно облегчает инсталляцию драйверов, поскольку двоичный код ядра
не нужно менять. Кроме того, уменьшается размер ядра, так как ненужные
драйверы просто не загружаются.
Поддержка загружаемых модулей реализуется путем вставки в ядро одной
или нескольких документированных “точек подключения’’, которые доступны
драйверам. Существует пользовательская команда, которая дает ядру указание
загрузить новые модули в память. Обычно имеется также команда, выгру-
жающая драйверы.
Загружаемые драйверы очень удобны, ио они не обеспечивают стопро-
центной безопасности. При каждой загрузке и выгрузке модуля существует
риск нарушить работоспособность ядра. Во избежание краха системы не
рекомендуем загружать и выгружать непроверенные модули.
Как и другие аспекты управления устройствами и драйверами, реализация
механизма загружаемых модулей зависит от конкретной операционной
системы Н1гже приводятся команды и рекомендации для Solaris. Linux и
FreeBSD.
Soloris
В Solaris практически все компоненты являются загружаемыми модулями.
Перечень модулей, загруженных на текущий момент, можно получить с
помощью команды modinfo. Выходная информация этой команды выглядит
так:
f modinfo
id	Loadaadr	Size	info Rev		Module Name
1	ffOTeCOO	3ba0	1	1	speefs (filesystem for speefs)
2	ffOBfiOOO	1340	-	1	swapgeneric (root/swap config)
3	ff082000	la56	1	1	TS (time sharing sched class)
4	ff084000	49c	-	1	TS_DPTBL (Timesharing dispatch)
5	ff0950D0	15248	2	1	ufs (filesystem for ufs)
6	ff0b8000	20e0	1	1	rootnex (sun4c root nexus)
7	ff084a0e	170	57	1	options (options driver)
Глово 12, Дройверы и ядро
277
8	ffOSdcOO	2f4	62	1	circa (Direct Memory Access)
9	ffOficOOO	968	59	1	sbus (SBlis nexus driver)
В нашей системе Solaris этот список занял более 80 строк. Многие
элементы, которые в других версиях UNIX “зашиты" в ядро (например,
UFS — локальная файловая система), в Solaris реализованы как загружаемые
драйверы. Такая организация призвана значителъио облегчить сторонним
фирмам разработку программного обеспечения, которое будет легко и
незаметно интегрироваться в ядро — по крайней мере теоретически.
Драйвер можно добавить к ядру с помощью команды addjlrv. Она
загружает драйвер в ядро и создает необходимые ссылки на устройство (при
каждой перезагрузке ядра все ссылки перестраиваются). Драйвер остается
частью системы до тех пор, пока не будет удален явно. Драйверы можно
выгружать вручную с помощью команды reni_drv.
После загрузки драйвера желательно также выполнить команду drvconfig.
Она перестраивает каталог /devices и добавляет в него все файлы, связанные
с загруженным драйвером.
Загружаемые модули, доступ к которым через файлы устройств не
производится, можно загружать и выгружать командами modload и mod unload.
Linux
Linux в чем-то проще, а в чем-то — сложнее, чем Solaris, в плане
обработки загружаемых модулей ядра, по крайней мере с точки зрения
системных администраторов. В Linux почти все компоненты можно сделать
загружаемыми модулями. Исключение составляет драйвер устройства, на
котором расположена корневая файловая система.
Загружаемые модули хранятся в каталоге /lib/modи\е$/версия, где послед-
няя часть имени — это версия ядра Linux, о которой сообщает команда
uname -г. Получить список загруженных в данный момент модулей можно с
помощью команды Is mod.
* lamod
Module	Size	Used by
РРР	21452	0
slhc	4236	0 [ppp]
ds	6344	1
i82365	26648	1
pcmcia_core	37024	0 [ds 182365]
Как видно из списка, в системе установлены модули контроллера
PCMCIA, драйвер РРР, а также модули сжатия РРР-заголовков.
Загружаемые модули Linux вы можете подключать к ядру посредством
команды insmod. В частности, с помощью приведенной ниже команды можно
добавить модуль нашего устройства "snarf’:
#	inamod /path/to/snarf.о
Также имеется возможность передавать модулям конфигурационные
параметры, например:
#	insmod /path/to/snarf.о io=0xXXX irq=X
После того как модуль был вручную добавлен к ядру, удалить его вы
сможете только по явному запросу. Для этой цели подойдет команда mimod
278
Чость I. Основы одминистрировония
snarf. Команду rmmod разрешается выполнять в любое время, но она сработает
только в том случае, если текущее число ссылок на модуль (указано в столбце
Used by вывода команды Ismod) равно 0.
Модули ядра Linux могут за1ружаться полуавтоматически с помощью
команды modprobe, которая распознает межмодульные зависимости, парамет-
ры модулей, процедуры инсталляции и выгрузки. Эта команда просматривает
файл /etc/conf.modules, чтобы узнать, как обрабатывать каждый модуль.
Можно динамически создать файл /etc/conf.modules, соответствующий
текущей конфигурации, выполнив команду modprobe -с. Эта команда гене-
рирует длинный файл, имеющий примерно следующий вид:
#	This tile was generated by: modprobe -c (2.1.121)
path[pcmcia]-/lib/modules/preferred
path Jpcir.cial=/lib/modules/default
path[pcmcia]-/lib/modules/2.3.39
path[misc]=/lib/modules/2 .3.39
t Aliases
alias block-major-l rd
alias block-major-2 floppy
alias char-ma]or-4 serial
alias char-major-5 serial
alias char-major-6 Ip
anas dos msdos
alias plipO plip
alias pppO ppp
options ne io=x0340 irq=9
Инструкции path указывают на то, где можно найти конкретный модуль.
Существует возможность модифицировать или добавлять записи данного типа
при необходимости хранить модули в нестандартных каталогах.
Инструкция alias обеспечивает привязку старших номеров блок-ори-
ентированных и байт-ориентированных устройств, фшиювых систем, сетевых
устройств и сетевых протоколов к соответствующим модулям. Поддерживается
динамическая загрузка модулей, реализуемая демоном kerne Id (см ниже).
Строки с ключевым словом options не генерируются динамически. Они
задают параметры, передаваемые модулю при его загрузке. Например, в
следующей строке модулю устройства “snarf" сообщаются адрес ввода-вывода
и вектор прерываний:
options snarf io-oxXXX irq=X
Команда modprobe понимает также инструкции pre-install, post-in-
stal-, ore-remove, post-remove, install и remove. С их помощью
задаются команды выполняемые, когда соответствующий модуль подключа-
ется к работающему ядру или отключается от него. Их синтаксис таков:
pre-install модуль команда
install модуль команда ...
post-install модуль команда
pre-rerr.ove модуль команда .
remove модуль команда ...
post-remove модуль команда
Глово 12 Драйвера и ядро
279
Команды выполняются соответственно перед подключением, одновремен-
но с подключением (если это возможно), после подключения, перед
удалением, во время удаления (если возможно) и после удаления.
Но это еше не все! Модули ядра могут загружаться и выгружаться
динамически демоном kerneld. Если этот демон запушен, модули загружаются
автоматически при обратении к связанным с ними устройствам. Демон берет
конфигурационную информацию из файла /etc/conf.modules, как и команда
niodprobe. На основании инструкций alias определяется, какой модуль
закреплен за нужным устройством.
Например, если кто-то пытается обратиться к последовательному порту,
а драйвер порта не загружен, демон просматривает файл /etc/conf.modules в
поисках модуля, связанного с байт-ориентированным устройством, старший
номер которого равен 4. Вообще демон kerneld делает все то же самое, что
и команда modprobe, просто он предназначен для постоянной фоновой работы.
FreeBSD
Во FreeBSD поддержка модулей появилась недавно по сравнению с Solaris
и даже Linux. Текущие версии FreeBSD не позволяют добавлять драйвер
устройства к работающему ядру. В основном все сводится к открытию файла
/dev/kmem и вставке в него некоторого кода. Возможно, именно по этой
причине поддержка загружаемых модулей отключена в ядре GENERIC.
Как ни странно, во FreeBSD присутствуют команды modload, modstal и
mod unload, которые соответственно загружают модуль, отображают его статус
и выгружают. Все они выполняют системный вызов ioctl по отношению к
файл)' /dev/lkm.
По умолчанию модули ядра FreeBSD располагаются в каталоге /modules.
Все эти модули управляются посредством вышеупомянутых утилит.
12.12	Рекомендуемая литература
•	McKusick, Marshall Kirk, et al. The Design and Implementation of the 4.4BSD
Operating System. Reading. MA: Addison-Wesley. 1996.
•	Beck, Michael, et al. Linux Kernel Internals, Second Edition. Reading, MA.
Addison-Wesley. 1998.
2СЭ
Чость I Основы администрирования
Часть II
Работа в сетях
] $ Сети TCP/IP
7 0Р / Ч*Р.
ЛСЛеллло^ ay»6fiAvvx
НО&МДС .L^fMAVWerM.
/Иле Нау^&аслс его 707* / ^7•
7ей*нс
1994
7ей*нс
1995
Трудно переоценить важность сетей в современном компьютерном мире.
Во многих организациях одним из основных видов деятельности является
работа в WWW и доступ к электронной почте. По оценкам на начало 2000 г.
в Internet работало более 300 миллионов пользователей, и этот показатель
по-прежнему растет экспоненциально. Обыденной задачей системных адми-
нистраторов является обслуживание локальных сетей, Internet-подключений,
Web-узлов и сетевого программного обеспечения.
TCP/IP — это семейство сетевых протоколов, широко используемых в
UNIX, MacOS, Windows, Windows NT и большинстве других операционных
систем. Данное семейство определяет основной язык общения в среде Internet.
Ключевыми протоколами в нем являются IP (Internet Protocol — межсетевой
протокол) и TCP (Transmission Control Protocol — протокол управления
передачей).
Благодаря TCP/IP формируется единый программный интерфейс доступа
к сетевому оборудованию различных типов, который позволяет гарантиро-
ванно обмениваться данными, несмотря на все архитектурные различия.
В основе Internet лежит протокол IP, используемый для доставки неструкту-
рированных пакетов. TCP и UDP (User Datagram Protocol — протокол
передачи дейтаграмм пользователя) — это транспортные протоколы, реали-
зованные поверх IP и служащие для доставки пакетов нужным приложениям.
Протокол TCP ориентирован на установление соединений. Он сущест-
венно облегчает взаимодействие между двумя программами. ТСР-соединекие
напоминает телефонный разговор: информация, выдаваемая на одном конце,
принимается на другом, и наоборот. Соединение удерживается даже в том
случае, когда оба абонента молчат. Протокол TCP обеспечивает надежную
доставку пакетов, управление потоком данных и трафиком.
Протокол UDP ориентирован на доставку одиночных пакетов без
установления соединения. Этот процесс напоминает отправку письма. Дос-
тавка пакетов не гарантируется, и нет средств управления трафиком.
TCP — это “вежливый” протокол, заставляющий одновременно работаю-
щих пользователей делить между собой сетевой канал, что способствует
Глово 13. Сети TCP/IP
283
повышению производительности. В противоположность этому протокол UDP
старается передавать пакеты с максимально возможной скоростью, Разраба-
тываются новые, улучшенные версии данного протокола, но они еще не
добились широкого признания.
По мере роста сети Internet все большую долю трафика должны занимать
TCP-потоки, что позволяет избегать заторов и эффективно использовать
имеющуюся полосу пропускания Но как показывают измерения, проведен-
ные за последние несколько лет. доля UDP-трафмка возросла с 5% в
1997—1998 гг. до 7% в 1999—2000 гт. Начинает сказываться популярность
игровых приложений
В этой главе мы начнем знакомство с техническими аспектами TCP/IP.
К сожалению, даже изложение основ работы в сети — слишком обширная
тема, чтобы “втиснуть” ее в рамки одной главы. Поэтому мы будем
продолжать данную тему в главах 14. 16 и 20.
13.1.	TCP/IP и Internet
История TCP/IP тесно связана с историей Internet и ухолит своими
корнями на несколько десятилетий назад. Популярность Internet во многом
обязана гибкости и эффективности архитектуры TCP/IP. В свою очередь,
широкое распространение TCP/IP именно в сети Internet позволило этом}
семейству протоколов одержать верх над несколькими конкурирующими
семействами, популярными в свое время по тем или иным причинам.
Краткая история
Вопреки распространенному заблуждению. Internet — это не продукт
Microsoft, появившийся в 1995 г. Прародителем Internet была сеть ARPANET,
основанная в 1969 г. Управлением по перспективным исследовательским
программам при министерстве обороны США (Defense Advanced Research
Project Agency. DARPA). Впоследствии ARPANET стала национальной
магистралью сети NFSNET (National Science Foundation Network — сеть
Национального научного фонда), которая связывала между собой суперком-
пьютеры и региональные сети США.
К концу 80-х гг. сеть перестала быть научно-исследовательским проектом,
и для Национального научного фонда пришло время отойти от сетевого
бизнеса. Переход на коммерческие рельсы занял около семи лет; сеть
NFSNET была отключена в апреле 1994 г Сегодня основу глобальной сети
составляет совокупность частных сетей, принадлежащих провайдерам Internet.
В середине 80-х гг. сеть Internet состояла из первоначальных вычисли-
тельных центров ARPANET и группы университетов, в которых были
установлены компьютеры DEC VAX с операционными системами семейства
Berkeley UNIX. Университетские сети строились по технологии Ethernet
(скорость работы — 10 Мбит/с) и получали доступ в Internet по выделенной
цифровой телефонной линии со скоростью 56 Кбнт/с. Каждый сентябрь,
когда студенты приступали к учебе, глобальная сеть испытывала существен-
ную перегрузку' вследствие возникновения заторов. Ван Джейкобсон (Van
Jacobson), научный сотрудник группы сетевых исследований при лаборатории
Bell Labs университета Лоренса, заинтересовался поведением существующих
протоколов в условиях повышенной нагрузки и нашел пути их оптимизации
Отсюда берут свое начало известные сегодня алгоритмы медленного старта,
избежания заторов, быстрой ретрансляции и быстрого восстановления.
284
Чость II Робота в сетях
Вступление в силу закона Мура (гласящего, что мощность вычислитель-
ных средств удваивается каждые 18 месяцев) и рыночный спрос существенно
ускорили развитие глобальной сети. С конца 80-х гг., когда были зафикси-
рованы существующие на сегодняшний день алгоритмы TCP, скорость
сетевых интерфейсов возросла в 1000 раз (пояаленне десятимегабитных
технологий Ethernet привело к повышению эффективности на 6%, а
гигабитных технологий Ethernet — на 90%), выделенных канатов — в
12000 раз, а общее число узлов — в 50000 раз.
Любой, кому случалось разработать программную систему, устаревшую
сразу после появления следующего поколения аппаратных средств или
следующего выпуска операционной системы, будет восхищен тем, что сеть
Internet до сих пор жива и успешно функционирует, эксплуатируя то же
семейство протоколов TCP/IP. которое было разработано 25 лет назад для
совершенно другой сети. Мы снимаем шляпы перед Бобом Каном (Bob Kahn).
Винтом Церфом (Vint Cerf). Джоном Постелом (John Postel), Ваном
Джейкобсоном и другими людьми, которые стояли у истоков этого чуда.
Кто сегодня управляет сетью Internet
Разработка глобальной сети всегда осуществлялась на кооперативных и
открытых началах. Сегодня, когда Internet стала важным фактором мировой
экономики, многие обеспокоены тем. что руководство глобальной сетью
сосредоточено в руках группы людей, получающих указания от правительства
США. Поэтому недалеко то время, когда появится правительство Internet.
В процесс управления глобальной сетью вовлечены следующие организации:
• ICANN (Internet Corporation for Assigned Names and Numbers — Органи-
зация по назначению имен и адресов в Internet) — именно про нее можно
сказать, что она отвечает за работу гнобальной сети (www.icann.org);
•	IETF (Internet Engineering Task Force — проблемная группа проектиро-
вания сети line met) — эта организация отвечает за разработку и
публикацию технических стандартов Internet, являясь открытым форумом,
принять участие в котором может каждый желающий (www.ietf.org);
•	ISOC (Internet Society — Общество Internet) — это членская организация,
которая объединяет в своих рядах пользователей Internet (www.isoc.org).
Среди перечисленных организаций наибольшая ответственность лежит на
ICANN, она выступает в роли руководящего органа Internet, исправляя
ошибки прошлого и продумывая пути дальнейшего развития.
Сетевые стандарты и документация
Научно-техническая деятельность сообщества пользователей Internet на-
ходит отражение в серии документен, известных как RFC (Requests For
Comments — запросы на комментарии). Стандарты протоколов, предлагаемые
технические изменения, а также информационные бюллетени в итоге находят
свое отражение в документах RFC. Иногда они действительно имеют вид
комментариев, но чаше выпускаются в виде пояснений к существующим
методикам и технологиям.
Документы RFC имеют порядковые номера. На сегодняшний день их
около 3000. У них есть описательные названия (например, Algorithms for
Synchronizing Network Clocks — алгоритмы синхронизации сетевых таймеров),
но во избежание неоднозначности на документы RFC чаше всего ссылаются
по номерам Будучи опубликованным, документ RFC никогда не меняется.
Глобо 13 Сети TCP/IP
285
Изменения и дополнения публикуются в виде новых документов со своими
собственными номерами. По соглашению обновленные документы содержат
всю информацию из предшествующих документов, которая остается актуаль-
ной. Таким образом, происходит полная замена одного документа другим,
по крайней мере теоретически.
Процесс публикации документов RFC. в свою очередь, описан в
документе под названием Internet Official Protocol Standards (официальные
стандарты протоколов Internet). В него также включены ссылки на большин-
ство документов, содержащих описания протоколов. Поскольку эта инфор-
мация часто меняется, данный документ повторно публикуется через каждые
100 номеров: если текущая версия имеет номер 2600. то следующей будет
2700 и т.д. Процесс публикации стандартов Internet описан в документе
RFC2026. Другой полезный документ — RFC2555. 30 Years of RFCs (30 дет
существования документов RFC). В нем рассмотрены культурные и техниче-
ские аспекты публикации документов RFC.
Пусть вас не пугает обилие технических подробностей в документах RFC.
В большинстве из них содержатся вводные описания и толкования, которые
будут полезны системным администраторам. Некоторые документы специ-
ально написаны в виде обзора или общего введения. Чтение документов
RFC — не самый простой способ разобраться в той или иной теме, но это
авторитетный, лаконичный и бесплатный источник информации.
Не все документы RFC написаны сухим техническим языком Встреча-
ются документы развлекательного содержания (некоторые опубликованы 1-го
апреля), среди которых нам особенно нравятся следующие:
•	RFC1118 — The Hitchhiker's Guide to the Internet (Руководство для
путешествующих no Internet автостопом);
•	RFC 1149 — A Standard for the Transmission af IP Datagrams on Avian Carriers
(Стандарт передачи дейтаграмм птичьей почтой);
•	RFC2324 — Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (Гипер-
текстовый протокол управления кофеварками);
•	RFC2795 — The Infinite Monkey Protocol Suite (IMPS} (Семейство протоколов
для управления бесконечным числом обезьян).
Помимо последовательных номеров документам RFC могут назначаться
номера серий FYI (For Your Information — к вашему сведению). ВСР (Best
Current Practice — лучший существующий подход) и STD (Standard —
стандарт). Перечисленные серии являются подмножествами серии RFC,
группирующими документы по важности или назначению.
Документы FYI — это вводные или информационные материалы,
предназначенные для широкой аудитории. Как правило, именно с них лучше
всего начинать знакомство с исследуемой темой. Документы STD содержат
описания протоколов Internet, которые прошли процедуру проверки и
тестирования в IETF и были формально приняты в качестве стандартов
Документы ВСР описывают рекомендуемые процедуры для администраторов
Internet-серверов; с точки зрения системных администраторов, это наиболее
ценные документы в серии RFC.
Нумерация документов в рамках серий RFC, FYI, STD и ВСР ведется
раздельно, поэтому один документ может иметь несколько номеров. Напри-
мер, документ RFC 1635, How to Use Anonymous FTP (как использовать
анонимный протокол FTP) также известен как FYI0024.

Чость II Робота в сетях
Документы RFC доступны из самых разных источников. Список поддер-
живаемых зеркальных RFC-серверов можно получить на Web-узле www.rfce-
ditor.org, который является центром сбора информации по документам RFC.
13.2.	Семейство TCP/IP
Познакомившись с историей, давайте подробнее рассмотрим, что собой
представляют протоколы TCP/IP. TCP/IP — это семейство сетевых протоко-
лов, ориентированных на совместную работу В состав семейства входит
несколько компонентов:
•	IP (Internet Protocol — межсетевой протокол) — обеспечивает транспор-
тировку пакетов данных с одного компьютера на другой (RFC79I);
•	ICMP (Internet Control Message Protocol — протокол управляющих
сообщений в сети Internet) — отвечает за различные виды низкоуровневой
поддержки протокола IP. включая сообщения об ошибках, вспомогатель-
ные маршрутизирующие запросы и подтверждения о получении сообще-
ний (RFC792);
•	ARP (Address Resolution Protocol — протокол преобразования адресов) —
выполняет трансляцию IP-адресов в аппаратные МАС-адреса (RFC823) ;
•	UDP (User Datagram Protocol — протокап передачи дейтаграмм пользо-
вателя) и TCP (Transmission Control Protocol — протокол управления
передачей) — обеспечивают доставку данных конкретным приложениям
на указанном компьютере. Протокол UDP реализует передачу отдельных
сообщений без подтверждения доставки, тогда как TCP гарантирует
надежный полнодуплексный канал связи между процессами на двух
разных компьютерах с возможностью управления потоком и контроля
ошибок (RFC768 и RFC793).
TCP/IP базируется на многоуровневой схеме взаимодействия протоколов
(табл. 13.1).
Тоблицо 13.1. Сетевой модель TCP/IP
Уровень	Функция
Прикладной	Пользовательские приложения
Транспортный	Доставка данных приложениям1
Сетевой	Базовые функции коммуникации, адресации и маршрутизации
Канальный	Сетевые аппаратные средства и драйверы устройств
Физический	Кабели к другие физические носители
Дополнительно может обеспечиваться подтверждение доставки и управление
потоком.
После того как семейство протоколов TCP/IP было реализовано и
внедрено. Международная организация по стандартизации (International
Organization for Standardization. ISO) предложила собственную семиуровневую
сетевую модель, названную OSI (Open System Interconnection — взаимодей-
ствие ^открытых систем) Она так никогда и не приобрела широкой
Мы немного грешим против истины, утверждая, что протокол ARP входит в семейство
TCP/IP. На самом деле этот протокол вполне может использоваться вместе с другими
семействами протоколов. Просто он является неотъемлемой частью стека TCP/IP в боль-
шинстве локальных сетей.
Глово 13. Сети TCP/IP
:87
популярности из-за своей сложности и неэффективности. Некоторые даже
считают, что к семи уровням OSI нужно добавить еше два: финансовый и
политический.	_
На рис. А изображено, как различные компоненты и клиенты TCP/IP
вписываются в общую многоуровневую архитектуру.
г
Прикг.вдной
уровень
I и<  .ч »в..а оптоволокно. ра.-(ионолны
транспортный
уровень
Сетевой
уровень
Канальный
уровень
Физический
уровень
Рис. А. Семейство TCP/IP
13.3.
Пакеты и инкапсуляция
UNIX поддерживает работу в целом ряде физических сетей, включая
Ethernet (в том числе беспроводная связь), FDD1, Token Ring, ATM и системы
с последовательными соединениями. Управление аппаратными устройствами
осуществляется на канальном уровне архитектуры TCF/IP, а протоколы более
высоких уровней не знают о том, как именно используются аппаратные
средства.
Данные передаются по сети в форме пакетов, имеющих максимальный
размер, определяемый ограничениями канального уровня. Каждый пакет
состоит из заголовка и полезного содержимого (сообщения). Заголовок
включает сведения о том, откуда прибыл пакет и куда он направляется.
Заголовок, кроме того, может содержать контрольную сумму, информацию,
характерную для конкретного протокола, и другие инструкции, касающиеся
обработки пакета. Полезное содержимое — это данные, подлежащие пере-
сылке.
Имя базового блока передачи данных зависит от уровня протокола. На
канальном уровне это кадр или фрейм, в протоколе IP — пакет, а в протоколе
TCP — сегмент. Мы будем придерживаться универсального термина “пакет”.
Когда пакет передается вниз по стеку протоколов, готовясь к отправке,
каждый протокол добавляет в него свой собственный заголовок. Законченный
пакет одного протокола становится полезным содержимым пакета, генери-
руемого следующим протоколом. Эта операция известна как инкапсуляция.
На принимающей машине инкапсулированные кадры восстанавливаются в
обратном порядке.
Например, дейтаграмма, передаваемая по сети Ethernet, упакована в трех
различных “конвертах". В среде Ethernet она “вкладывается” в простой
физический кадр, заголовок которого содержит сведения об аппаратных
адресах отправителя и ближайшего получателя, длине кадра и его контрольной
сумме (CRC). Полезным содержимым Eihemet-кадра является IP-пакет.
288
Чость II Роб ото в сетях
Полезное содержимое IP-пакета — UDP-пакет, и. наконец, полезное содер-
жимое UDP-пакета состоит собственно из передаваемых данных. Компоненты
такого кадра изображены на рис. Б.
UDP-nam (108 байтов)
|Р-пакет (126 байтов)
Заголовок' Заголовок Заголовок 1Пм BaKHb,.j KoHg₽gl;““
Ethernet I IP UDP ।________________________________________j Ethernet____I
14 байтов J 20 байтов । В байтов | ICQ Вайтов j а Сайта
Ethernet-Kaqp (*»46 байтов)
Рис. Б. Типичный сетевой покет
Под словом ’’байт” мы подразумеваем 8-битовую цепочку данных.
В былые времена этот термин имел более широкое значение, поэтому иногда
в документах RFC можно встретить термин “октет”.
Канальный уровень
Канальный уровень обеспечивает связь между7 сетевым программным
обеспечением и собственно сетевым оборудованием.
Стандорты формирования кадров Ethernet
Одна из основных обязанностей канального уровня — добавление
заголовков к пакетам и вставка разделителей между ними. Заголовки содержат
информацию об адресах канального уровня и контрольные суммы, а
разделители позволяют принимающей стороне определить, где заканчивается
один пакет и начинается другой. Процесс добавления вспомогательных битов
называется формированием кадров.
В десятимегабитных сетях Ethernet существует два различных стандарта
кадровой разбивки; DIX Ethernet II и IEEE 802.2 LLC SNAP’. На серверах
UNIX и в маршрутизаторах Cisco применяется первый стандарт, в сетях IPX
и системах Novell — второй. Стандарты различаются несколькими полями в
заголовке кадра, но они не конфликтуют друг с другом, поэтому принимаю-
щее устройство может однозначно определить формат каждого пакета и
соответствующим образом декодировать заголовок.
Выбор стандарта кадровой разбивки диктуется имеющейся сетевой платой
и ее драйвером. На персональных компьютерах, работающих под управлением
Windows, выбор можно делать самостоятельно, а в UNIX — обычно нет.
С точки зрения UNIX оба стандарта прекрасно взаимодействуют. А вот в
среде Windows компьютеры, расположенные в одной сети, но придерживаю-
щиеся различных стандартов, не могут общаться друг с другом. Системному
администратору обычно не приходится заниматься вопросами формирования
кадров, если только не выполняется низкоуровневая отладка в смешанной
сети.
Канальный уровень в действительности разбит на два подуровня: MAC (Media Access
Control — управление доступом к среде) и LLC (Logical Link Control — управление логиче-
ским соединением). На подуровне МАС производится вставка пакетов в кабельную систему.
Подуровень LLC отвечает за формирование кадров.
Глово 13 Сети TCP/IP
289
Стандарты кабелей Ethernet
Выбор кабелей в десяти мегабитной сети Ethernet довольно прост, по
ситуация усложняется, когда речь заходит о стомегабитных сетях. Раньше
существовали три различных стандарта для витой пары (ТХ. в котором
использовались две пары кабелей категории 5, а также Т4 и VG. в каждом
из которых требовались четыре пары категории 3) и еще один для оптоволокна
(FX, в котором используется многорежимный волоконно-оптический кабель».
Компания Hewlett-Packard отстаивала стандарт VG и первой выпустила для
него продукты. Другие производители проигнорировали его и остановили
свой выбор на стандарте ТХ. который в настоящее время используется
повсеместно.
Дополнительная информация о рахличных стандартах Ethernet приведена
в главе 15. Другим полезным источником является Web-узел wwwhost.ots.uic-
xas.edu/ethemet, поддерживаемый Чарльзом Сперджоном (Charles Spurgeon).
Беспроводные сети
В спецификации IEEE 802.11 делается попытка описать стандарты
кадровой разбивки и передачи сигналов для беспроводных сетей. К сожале-
нию, спецификация является весьма нечеткой и включает ряд параметрон,
которые не были полностью определены При взаимодействии разнородных
сетей приходилось учитывать такие аспекты, как трансляция и инкапсуляция.
В случае трансляции пакет преобразуется из одной формы в другую, а
при инкапсуляции он упаковывается в структуру требуемого формата. В среде
Windows применяется инкапсуляция, а в UNIX — трансляция, поэтому
базовые беспроводные станции должны конфигурироваться явным образом.
Когда развертывается беспроводная сеть, нужно убедиться, что базовая
станция и связанные с ней рабочие станции функционируют в одинаковом
режиме.
Пользователи портативных компьютеров сталкиваются с другой пробле-
мой, вызванной неоднозначностью спецификации 802.11. Беспроводные
платы PCMCIA имеют энергосберегающий режим, несовместимый с некото-
рыми базовыми станциями. По умолчанию он, естественно, включен. Если
окажется, что пользовательские портативные компьютеры не работают в
беспроводной сети, попросите пользователей отключить энергосберегающий
режим. Самая лучшая конфигурация домашней беспроводной сети — с
базовой станцией Apple AirPon и сетевыми платами Lucent. Посредством
портативного компьютера в такую сеть можно входить отовсюду: в постели,
в бассейне и даже с улицы
Максимальный размер передаваемого блока
Размер пакетов ограничивается как характеристиками аппаратных
средств, так и требованиями протоколов. Например, объем полезного
содержимого El he met-па кета не может превышать 1500 байтов. Предельный
размер пакета устанавливается на канальном уровне и называется максималь-
ной единицей передачи (Maximum Transfer Unit, MTU). Типичные значения
параметра MTU приведены в табл. 13.2.
Для ATM параметр MTU не вполне применим, так как сеть ATM
расположена где-то на границе между физическим и канальным уровнями.
Ячейка ATM обычно имеет размер 53 байта с 48-байтовым блоком данных,
но в спецификации AAL/5 паке'*' может иметь размер до 216 бантов. Как
правило, в обычном режиме параметр MTU равен 9180 байтов, а в режиме
LANE (Local Area Network Emulation — эмуляция локальной сети) —
1500 байтов.
290
Чость II. Роботе в сетях
Тоблицо 13 2. Моксимольные размеры передаваемых блоков в сетях различных типов
Тип сетевого соединения Максимальный размер блока
Ethernet	1500 байтов (1492 в спецификации 802.2)
FDD]	4500 байтов (4352 для IP/FDD1)
РРР	настраиваемый, обычно 512 или 576 байтов
А ГМ	53 байта
Спутниковые каналы (Tl, ТЗ) настраиваемый, обычно 1500 или 4500 байтов
В TCP/IP протокол IP отвечает за разбивку пакета на фрагменты, чтобы
их размер соответствовал требованиям конкретного сетевого соединения. Если
пакет проходит через несколько сетей, в одной из них параметр MTU может
оказаться меньшим, чем в исходной сети. В этом случае маршрутизатор
подвергнет пикет дальнейшей фрагментации Подобный процесс нежелателен,
когда маршрутизатор сильно загружен Протокол TCP способен определить
наименьшее значение MTU вдоль всего пути следования пакета и с самого
начала разбить пакет в соответствии с этим значением. Протокол UDP не
столь “любезен” и перекладывает всю ответственность на протокол IP.
В стандарте IPv6 промежуточные маршрутизаторы больше не могут выполнять
фрагментацию пакетов: режим предварительного определения максимального
размера блока является обязательным.
Иногда проблема фрагментации оказывается достаточно коварной На-
пример. в виртуальной частной сети с туннельной архитектурой необходимо
проверять размер пакетов, проходяшии через туннель Обычно их начальный
размер — 1500 байтов, но когда к ним добавляется туннельный заголовок,
размер пакетов становится равным примерно 1540 батон, и уже требуется
фрагментация. Уменьшение размера блока позволяет избежать фрагментации
и повысить производительность сети Обратитесь к тан-странице по команде
ifconfig, чтобы узнать, как настроить параметр MTU сетевой платы.
Адресация пакетов
Подобно письмам и сообщениям электронной почты, сетевые пакеты
могут достичь пункта назначения только при наличии правильного адреса.
В TCP/IP используется сочетание нескольких схем адресации:
•	МАС-алрсса сетевого оборудования;
•	IP-адреса программного обеспечения.
•	текстовые имена компьютеров.
Сетевая плата может иметь МАС-адрес канального уровня, который
отличает ее от других сетевых плат данной физической сети, 1Р-адрес,
определяющий ее положение в сети Internet, и текстовое имя, понятное
пользователям.
Самый нижний уровень адресации задается сетевыми аппаратными
средствами. Например, El he met-устройствам при изготовлении присваиваются
уникальные шестибайтовые аппаратные адреса. Платы сетей Token Ring
имеют аналогичные шест и байтовые адреса. В некоторых сетях с двухточечным
соединением 1 например. РРР: см параграф 13.8) аппаратные адреса вообще
не нужны: адрес пункта назначения указывается непосредственно при
установлении соединения.
Глава 13. Сети TCP/IP
291
Шестибайтовые адреса Ethernet разбиваются на две части: первые ipn
байта определяют изготовителя платы, а последние три байта выступаю! в
качестве уникального серийного номера, назначаемого изготовителем. Теку-
щий список производителей сетевого оборудования можно получить по адресу
http://wwu.iana.org/assignments/ethemet-numbers
В свое время эта информация регулярно публиковалась в виде документов
RFC. но затем такая практика прекратилась. Последним документом в серии
Assigned Numbers (назначенные номера) был документ RFC1700 (1994 г.)
Официальным хранилищем всех специальных имен, действующих в сети
Internet, является Web-страничка www.iana.otg/numbers.htm.
Аппаратные адреса Ethernet должны быть постоянными и неизменным!!
К сожалению, некоторые сетевые платы допускают программное задание
аппаратных адресов. Особенно сложно в этом отношении с платами
беспроводной связи Избегайте назначения адресов из диапазона групповою
вещания и других специальных адресов. В Solaris и Red Hat можно менять
аппаратный адрес любого сетевого интерфейса, но лучше этого не делать.
На следующем, более высоком уровне используется Internet-адресация
(которую чаще называют ГР адресацией). Каждому сетевому интерфейс)
присваивается четырехбайтовый IP-адрес. Эти адреса глобально уникальны
и аппаратно независимы. Мы уделим им достаточно много внимания к
параграфе 13.4.
Соответствие между IP-адресами и аппаратными адресами реализуется ни
канальном уровне модели TCP/IP В сетях, допускающих широковещательный
режим (т.е. в сетях, позволяющих адресовать пакеты всем компьютерам
данной физической сети), протокол ARP обеспечивает автоматическую
привязку адресов без вмешательства системного администратора.
Подробнее о протоколе ARP рассказывается в параграфе 13.6.
Поскольку IP-адреса представляют собой длинные, на первый взгляд
случайные, числа, то запомнить их трудно. UNIX-системы позволяют
связывать текстовые имена с IP-адресами, чтобы вместо telnet 128.138.242.1
пользователь мог ввести telnet anchor.
Существует несколько способов осуществления подобной привязки’ с
помощью статического файла (/etc/hosts), баз данных NIS и NIS+ и. наконец.
DNS — глобальной системы доменных имен. Помните, что имя компьюте-
ра — это просто сокращенный способ записи IP-адреса; низкоуровневое
сетевое программное обеспечение его не понимает.
Порты
IP-адреса идентифицируют компьютеры, точнее, сетевые интерфейсы
компьютера; они недостаточно конкретны для адресации отдельных процессов
и сервисов. Протоколы TCP и UDP расширяют концепцию IP-адресов, вводя
понятие порта. Порт в данном случае представляет собой двухбайтовое число,
добавляемое к IP-адресу и указывающее конкретный канал взаимодействия
Все стандартные сервисы UNIX, в частности электронная почта. FTP, сервер
удаленного доступа, связываются с ’‘известными’’ портами, которые опреде-
лены в файле /etc/services. Для того чтобы предотвратить попытки сторонних
Это не всегда верно В следующем параграфе, когда речь пойдет о системе NA I. буде»
рассказано, в каких случаях адреса оказываются неуникальными.
292
Чость II. Роботе В сетях
процессов замаскироваться под стандартные сервисы, UNIX-системы огра-
ничивают доступ к портам с номерами до 1024 только для пользователя root.
Типы адресов
В протоколе IP и на канальном уровне поддерживается несколько типов
адресов:
•	направленный — адрес, который обозначает отдельный компьютер
(в действительности сетевой интерфейс);
•	групповой — адрес, идентифицирующий группу узлов;
•	широковещательный — адрес, обозначающий все узлы локальной сети
Режим группового вешания используется в таких приложениях, как,
например, видеоконференции, где одна и та же последовательность пакетов
посылается всем участникам конференции. Протокол 1GMP (Internet Group
Management Protocol — протокол управления группами Internet) отвечает за
управление группами узлов, идентифицируемыми как один групповой адресат.
Режим группового вещания все еще является экспериментальным Тем не
менее, он находит все более широкое применение в таких областях, как
передача голосовых данных по IP-сетям и передача видео по запросу.
На канальном уровне младший бит старшего байта группового адреса
(первый байт, передаваемый по кабелю) установлен равным 1, т.е. любой
адрес с нечетным первым байтом рассматривается как групповой. Такие
адреса используются различны ми аппаратными устройствами в протоколах
начальной конфигурации. Адрес группового вешания в Internet — 01:00,5Е.
Широковещательные адреса канального уровня, если рассматривать их в
двоичном виде, состоят из одних единиц.
В протоколе IP групповые адреса начинаются с байта, значение которого
находится в диапазоне 224—239. В широковещательных адресах последняя
часть адреса в двоичном виде состоит из одних единиц.
13 4. 1Радреса
IP-адрес имеет в длину четыре байта и состоит из двух частей: сетевой
н машинной. Первая часть обозначает логическую сеть, к которой относится
адрес, а вторая идентифицирует конкрегпый компьютер в сети.
По соглашению IP-адреса записываются в виде группы десятичных чисел
(по одному на каждый байт), разделенных точками. Например. 1Р-адрес
нашей машины boulder выглядит как 128.138.240.1. Левый байт — старшин
и всегда является компонентом сетевой части адреса
Если первым байтом адреса является число 127. оно обозначает интерфсис
обратной связи — фиктивную сеть, не имеющую реального аппаратного
интерфейса и состоящую только из локальной машины. .Адрес 127.0.0.1 всегда
ссылается на текущую машину; ее символическое имя — localhosl.
IP-адрес и другие параметры сетевого интерфейса задаются командой
ifeonfig. Ее полное описание дано в параграфе 13.10.
Клоссы 1Р-адресов
Исторически IP-адреса группировались в классы, определявшиеся на
основании первых битов самого левого байта. Классы отличались распреде-
лением байтов адреса между сетевой и машинной частями. Современные
маршрутизаторы используют явные маски для задания сетевой части адреса.
Глово 13 Сети TCP/IP
293
причем компоненты адреса могут разделяться по границе отдельных битон.
а не обязательно байтов. Тем не менее, традиционные классы все еше
используются по умолчанию, если не предоставлена явная маска.
Классы А, В и С обозначают обычные IP-адреса; классы D и Е
применяются при групповой адресации и в исследовательских целях.
В табл. 13.3 представлены характеристики каждого класса адресов. Сетевая
часть адреса обозначена буквой С, а машинная — буквой М.
Таблица 13.3. Клоссы 1Р-одресов
Клосс	Первый байт1	Формат	Комментарии
А	1-126	С.М.М.М	Самые ранние сети или адреса, зарезерви ро ванные для Министерства обороны США
В	12а-191	С.С.М.М	Крупные организации, обычно с подсетя- ми; адреса данного класса почти полно- стью заняты
С	192-223	С.С.С.М	Небольшие организации; адреса данного класса получить легко, они выделяются целыми блоками
D	224-239		Групповые адреса, нс назначаются на по- стоянной основе
Е	240-254	-	Экспериментальные адреса
Значения 0 и 255 для обычных IP-адресов не используются. Значение 127
зарезервировано для адресов обратной связи.
Организация подсетей
В редких случаях в состав локальной сети входит более ста компьютеров.
По этой причине полезность адресов класса А и класса В (которые допускают
наличие в одной сети соответственно 16777214 и 65534 машин) весьма
сомнительна. К примеру, 126 адресов класса А занимают половин)' доступного
адресного пространства!
Большинство организации, имеющих эти адреса, пользуются улучшенным
вариантом схемы адресации, в которой применяются подсети. Здесь некоторая
доля машинной части адреса “заимствуется” для расширения сетевой части.
Например, четыре байта адреса класса В обычно интерпретируются как
С.С.М.М. При наличии подсети третий байт также отводится пол номер сети,
а не номер машины, поэтому формат адреса становится таким: С.С.С.М. Это
превращает один сетевой адрес класса В в 256 сетей, подобных сетям класса
С, в каждую из которых может входить 254 компьютера.
Переназначение адресов производится с помошью команды ifeonfig.
которая назначает сетевому интерфейсу так называемую маску подсети.
Каждый бит маски, соответствующий сетевой части IP-адреса, равен I, а
биты машинной части равны 0. Например, маска для адреса класса С будет
иметь вид 255.255.255.0 в десятичной системе и OxFFFFFFOO — в шестна-
дцатеричной. Ядро, как правило, использует класс адреса для того, чтобы
выяснить, какие биты относятся к сетевой части Если задается явная млека,
то эта функция просто отменяется.
Более подробная информация о команде ifeonfig содержится в параграфе 13.10
>91
Чость II. Роботе в сетях
Граница между сетевой и машинной частями адреса не обязательно
приходится на границу байта, но чаше всего бывает именно так. Биты сетевой
части должны быть смежными. Конфигурация вида С.С.М.С раньше допус-
калась, хотя и не была распространена. Сегодня подобный формат адреса
недопустим.
Сетевые маски, не оканчивающиеся на границе байта, труднее декоди-
ровать. Они обычно записываются в виде суффикса /XX. где XX — число
битов в сетевой части адреса (длина маски). Например, адрес 128.138.243.0/26
обозначает первую из четырех сетей с общим компонентом адреса 128.138.243.
В трех других сетях последний байт адреса идентифицируется значениями
64, 128 и 192. Сетевая маска, связанная с этими сетями, имеет вид
255.255.255.192. нли OxFFFFFFCO. В двоичном представлении это 26 единиц,
за которыми следуют шесть нулей (рис. В).
IP-адрес	. М, ,	,	,
Десятичная маска 255	•	255	•	255	•	192
Шестнадцатеричная I ,	♦ •**	, II •	1
маска
Двоичная маска ПИ НИ • till 111	•	1111	1111	•	110С	0000 * •
Рис В. Структуре маски подсети
В сети с длиной маски /26 для нумерации узлов отводится 6 битов
(32 — 26 = 6). Таким образом, появляется возможность задать 64 адреса
(26 = 64). В действительности можно использовать 62 адреса, поскольку
адреса, состоящие из всех нулей и всех единиц, зарезервированы (соответ-
ственно для самой сети и широковещательного режима).
Манипулировать всеми этими битами в голове трудно, но есть ряд
приемов, позволяющих упростить вычисления. Число узлов в сети и значение
последнего байта сетевой маски в сумме всегда дают 256:
последний байт сетевой маски = 256 — размер сети
К примеру, в рассмотренном выше случае 256 — 64 = 192 — это послед-
ний байт маски. Другое правило гласит, что значение последнего байта
фактического сетевого адреса (не сетевой маски) должно нацело делиться на
число узлов в сети В описываемом примере последние байты равны 0, 64,
128 и 192 — каждое нз этих чисел делятся нацело на 64.
Старшие два бита последнего байта адреса могут принимать значения 00.
01, 10 и II. Таким образом, сеть 128.138.243.0/24 может быть разделена на
четыре сети /26:
•	128.138.243.0/26	(0 - 00000000);
128.138.243.64/26
128.138.243.128/26
128.138.243.192/26
(64 - 01000000).
(128 - 10000000);
(192 - 11000000).
Выделенные полужирным шрифтом биты последнего байта каждого
адреса относятся к сетевой части этого адреса.
Имея конкретный IP-адрес (допустим, 128.138.243.100) невозможно
сказать, не узнав сетевую маску, каким будет адрес сети и широковещатель-
ный адрес. В табл. 13.4 представлены возможные варианты для масок /16
Глово 13. Сети TCP/IP
295
(выбирается го умолчанию для адресов класса В), /24 и /26 (наиболее
реалистичное значение, если учитывать нехватку адресов в сети: см. ниже).
Таблица 13.4. Пример расшифровки IP-адресо
1 1₽-адрес	Сетевая маска	Сетевой адрес	Широковещательный адрес
128.138.243.100/16	235.255.0.0	128.138.0.0	128.138.255.255
128.138.243.100/24	255.255.255.0	128.138.243.0	128.138.243.255
128.138.243.100/26	255.255.255.192	128.138.243.64	128.138.243.127
Кит Оуэнз (Keith Owens) написал прекрасный Perl-сценарий ipcalc.pl.
который помогает выполнять адресную арифметику. Он доступен по адресу
ftp.ocs.com.au и требует наличия интерпретатора Perl 5. Сценарий отображает
всю информацию, касающуюся заданного сетевого адреса. Мы даже обнару-
жили, что была написана версия этого сценария для системы Palm Pilot
(www.ajw.com/ipcalc.htm).
Ниже приведен образец работы сценария (формат вывода для наглядности
немного изменен):
% lpcalc.pl 128138 243.100/26
IP address	128	138 .	243	.	100 / 26	128.138.243.100/26
Mask Bins	11111111	11111111	11111111	11000000	
Mask bytes	255 .	255 .	255 .	192	255.255.255.192
Address	10000000	10001010	11110011	01100100	
Network	128	138	243	64	128.138.243.64
Broadcast	12B	138	243	127	128.138.243.127
First Host	128	138	243	65	128.138.243.65
Last Host	128	138	243	126	128.138.243.126
Total Hosts		62			
PTR		100.243.	138.128.1	n-aadr.arpa	
IP Address	(hex)	808AF364			
В Red Hai существует программа, которая также называется ipcalc и
выполняет аналогичные вычисления, но имеет несколько отличающимся
синтаксис.
Исходный документ RFC. посвяшенный 1Р-подсетям (R.FC950). не
разрешал использовать первый и последний адреса подсети (состоящие из
всех нулей и всех единиц соответственно). В нашем случае это привело бы
к исключению половины подсетей, с адресами 0 и 192. В действительности
все игнорировали это правило, кроме компаний Novel! и Cisco. (Правда, в
последних версиях операционной системы IOS компании Cisco — 12 0 и
выше — подсеть 0 доступна по умолчанию.)
Разработчики данного документа ошиблись, хотя их намерения были
благородными. Запрет подсети 0 был вызван опасением, что возникнет
путаница из-за совпадения адреса подсети и сетевого адреса без маски. Этот
страх оказался беспочвенным, поэтому адреса подсетей, состоящие из всех
нулей и всех единиц, широко используются сегодня. На самом деле подобным
запрет относится к машинной части адреса.
Сетевой (все нули) и широковещательный (все единицы) адреса сокра-
щают «тело узлов в каждой локальной сети на 2, поэтому в самой маленькой
сети формально будет 4 узла: два реальных, соединенных напрямую, и ава
296
Чость II Робото в сетях
фиктивных (сетевой и широковещательный адреса). Для того чтобы создать
подобную сеть, необходимо выделить два бита под машинную часть адреса,
т.е. суффикс адреса будет /30, а сетевая маска — 255.255.255.252, или
OxFFFFFFFC
Сетевые маски понятны компьютерам в локальной сети, но внешний
мир о них не зиает и продолжает интерпретировать адреса в соответствии с
заложенными в них классами. В нашем случае (адрес 128.138.243.100) не
нужно сообщать миру о каждой подсети, достаточно сообщить об одной сети
класса В. Когда пакет прибудет в пункт назначения, после которого
происходит разделение на подсети, к адресу нужно применить сетевую маску,
обнаружить реального получателя и направить ему пакет.
Кризис 1Р-адресов
Примерно в 1992 г. сообщество Internet наконец-то осознало три
фундаментальные проблемы, возникающие вследствие применения исходной
схемы выделения адресов. Во-первых, при существующих темпах развития
адресное пространство класса В — наиболее желанное для организаций
умеренного размера — окажется исчерпанным к середине 1995 г. Во-вторых,
таблицы маршрутизации серверов, управляющих Internet-магистралями, стали
настолько большими, что появились опасения относительно нехватки памяти
на маршрутизаторах. И в-третьих, IP-адреса выделялись по принципу ‘’первым
попросил — первым получил" без учета информации о местоположении
адресата. Таким образом, соседние адреса могли находиться как в одной
организации, так и на разных континентах. Представьте, какая путаница
могла бы возникнуть, если бы так же бессистемно назначались почтовые
индексы!
Для решения проблемы было одновременно предложено два подхода:
один на ближайшее будущее, а другой — более долгосрочный. Первое из
решений — протокол CIDR (Classless Inter-Domain Routing — бесклассовая
междоменная маршрутизация) — предусматривало изменение принципов
управления существующими четырехбайтовыми адресами и упрощение таблиц
маршрутизации за счет введения понятия смежности.
Долговременное решение — это стандарт IPv6. Он представляет собой
следующее поколение протокола IP. в котором длина адреса увеличена до
16-ти байтов и учтен ряд других ошибок, выявленных на протяжении 25 лет
эксплуатации протокола 1Р. Некоторые элементы протокола вообще исключены
»п нового стандарта, так как опыт показал, что онн не имеют практической
ценности. В результате протокол стал потенциально быстрее и проще в
реализации. В нем интегрированы средства аутентификации и обеспечения
безопасности, а также устранена процедура фрагментации на промежуточных
маршрутизаторах. Благодаря 16-байтовым адресам появилась возможность ис-
пользовать 2128 адресов, что составляет примерно 665570793348866943898599
адресов на один квадратный метр поверхности Земли. Размерность 16 была
выбрана потому, что проведенные вычисления показали; существует неболь-
шая вероятность того, что 8-ми байтов адреса окажется педостаточно.
В 2000 г. протокол IPv6 все еще проходил процесс стандартизации. А вот
протокол CIDR был полностью внедрен в эксплуатацию; он поддерживается
серверами Internet-магистралей и ведущими производителями маршрутизи-
рующего оборудования. Существенную роль в уменьшении требуемого числа
IP-адресов сыграла также система NAT. обеспечивающая повторное исполь-
зование существующих адресов (описывается далее в главе).
Г-адво 13. Сети TCP/IP
297
Сложность стандарта IPv6, эффективность протокола CIDR и системы
NAT. а также инертность существующей сети Internet заставляет предполагать,
что потребуется много времени, прежде чем произойдет переход на IPv6. Он
может быть ускорен такими странами, как Япония и Китай, которые не
получают необходимую долю адресного пространства, или какой-нибудь
новой суперпопулярной системой, ориентированной на стандарт IPv6.
Кандидатами на эту роль могут быть WAP-терминалы или беспроводные
устройства, встраивающие номер телефона в адрес IPv6. Системы передачи
голосовых данных по IP-сетям также выиграют от более близкого соответствия
между телефонными номерами и адресами IPv6.
CIDR: протокол бесклоссовой междоменной маршрутизоции
Протокол CIDR, описанный в документе RFC1519, устраняет потребность
в системе классов, на основании которой раньше определялась сетевая часть
IP-адреса. Он является прямым расширением идеи подсетей, поскольку также
позволяет задавать сетевую маску', определяющую границу между сетевой н
машинной частями адреса. Но в целях маршрутизации допускается, чтобы
сетевая часть была меньше, чем того требует класс адреса. Благодаря
укороченной маске возникает эффект объединения нескольких сетей 11о этой
причине протокол CIDR иногда называют протоколом формирования падсетеи.
При использовании протокола C1DR можно одной организации вылечить
несколько сетей класса С. причем не нужно для каждой из них создавать
отдельную запись в таблице маршрутизации. Предположим, например, что
организации предоставлен блок из 32-х адресов класса С, пронумерованных
последовательно от 192.144.0.0 до 192.144.31.0 (в нотации CIDR — 192.144.0.0/21).
Внутри самой организации адреса могут распределяться так:
•	I сеть с длиной маски 21 — 2046 узлов’, сетевая маска 255.255.224.0;
•	32 сети с длиной маски 24 — 254 узла в каждой, сетевая маска
255.255.255.0;
•	64 сети с длиной маски 25 — 126 узлов в каждой, сетевая маска
255.255.255.128,
•	128 сетей с длиной маски 26 — 62 узла в каждой, сетевая маска
255.255.255.192;
•	и тд.
Возможно смешение подсетей с разной длиной сетевой части адреса,
если только они не перекрывают друг друга. Например, провайдер Internet,
которому выделена адресная область 193.143.0.0/21, может создать группу
сетей /30 для PPP-клиентов, несколько сетей /24 для крупных клиентов и
ряд сетей /27 для более мелких компаний Все узлы в сети должны
конфигурироваться с помошыо одной сетевой маски Нельзя для одного узла
задать длину маски 24, а для другого — 25.
Ценность протокола CIDR заключается в том. что для перечисленных
адресов не обязательно иметь 256, 128 или даже 32 записи в таблице
маршрутизации. Ведь все они ссылаются на компьютеры в одной и тон же
организации, поэтому пакеты предварительно нужно доставлять в некий
Первоначальная спецификация Ethernet для коаксиального кабеля RG-11 допускала нали-
чие 1024 узлов в локальной сети. Очевидно, это было связано с максимальной длиной кабеля
(подсчитывалось среднее расстояние между компьютерами). Подобное ограничение по-
прежнему может быть “зашило*1 где-то в программном обеспечении, поэтому данная
конфигурация сети является непрактичной.
298
Чость II. Робото в сетях
обший приемный пункт. А в таблицу маршрутизации достаточно внести
запись 199.144.0.0/21.
С появлением протокола CIDR системным администраторам пришлось
поднатореть в двоичной и шестнадиатер»гчной арифметике. Правда, многие
открыли для себя UNIX-утнлиту Ьс. которая выполняет преобразования в
любой системе счислений при помощи директив ibase и ohasc. В табл. 13.5
представлена шпаргалка по нашему примеру.
Тоблицо 13.5. Конфигуроция сети в зовисимости от длины сетевой моски
Сетевая часть	Машинная ЧОСТЬ	Узлов/сетей2	Сетевая маска (десятичная)	Сетевая маско (шестнадцатеричная)
/20	12	4094	255.255.240.0	OxFFFFFOOO
/21	II	2046	255.255.248.0	0xFFFFF800
m	10	1022	255.255.252.0	OxFFFFFCOO
/23	9	510	255.255.254.0	OxFFFFFEOO
/24	8	254	255.255.255.0	OxFFFFFFOO
/26	7	126	255.255.255.128	OxFFFFFF80
/26	6	62	255.255.255.192	OxFFFFFFCO
/27	5	30	255.255.255.224	OxFFFFFFEO
/28	4	14	255.255.255.240	OxFFFFFFFO
/29	3	6	255.255.255.248	0xFFFFFFF8
/30	2	2	255.255.255.252	OxFFFFFFFC
Размеры сетевой и машинной частей адреса в сумме всегда дают 32.
Число ухчов определяется по формуле 2 "(длина машинной части)-2. Адреса узлов,
состоящие из всех нулей и всех единиц, являются зарезервированными.
Когда протокол C1DR появился в 1993 г. таблицы маршрутизации
магистральных серверов содержали примерно 20000 записей. Несмотря на
последующий экспоненциальный рост сети Internet, размер таблиц увеличился
всего до 80000 записей к лет\г 2000 г. Столь умерешгый рост связан с активной
агрегацией старых и новых адресных областей*.
Имеется одна нсагрегированная область адресного пространства, назы-
ваемая “болотом” 192 (есть также ряд более мелких “болот” в диапазонах
199 и 205). Она состоит из ранних адресов класса С, владельцы которых не
моп-т выполнить их агрегацию, но и не хотят поменжь их на другие адреса.
Особенно остро данная проблема стоит в США Европа и Азия, начавшие
подключаться к Internet позже, учли ошибки США и более разумно подошли
к вопросу выделения адресов. Организации, владеющие адресами в диапазоне
192, должны вернуть их в Американскую канцелярию номеров Internet
(American Registry Гог Internet Numbers. ARIN) и получить новые блоки
адресов от своих провайдеров. К сожалению, стоимость перерегистрации (по
крайней мере, в адресном пространстве IPv4) отпугивает большинство
организаций от подобного шага.
Когда мы начали писать книгу летом 1999 г., число записей н таблицах составляло 60000.
А год спустя их было уже 80000 — 25-процентный рост! Существующие маршрутизаторы и
алгоритмы маршрутизации могут выдержать годовой прирост в несколько процентов, но ие
25%. Глобальную статистику маршрутизации вы можете узнать по адресу www.antc.uore-
gon. edu /route-views/dy nam ics.
Неро 13 Сети TCP/IP
299
Хотя протокол Cl DR предусматривался как промежуточное решение,
оказалось, что он отлично справляется с проблемой роста сети Internet. По
крайней мере, в ближайшем будушем причин для беспокойства не предви-
дится. По сути, протокол CIDR зарекомендовал себя настолько хорошо, что
теперь не ясно, нужен ли вообше новый протокол IP. Конечно, в разработку
и прототипную реализацию спецификации IPv6 был вложен огромный
инженерный труд и будет стыдно, если он окажется напрасным, но
широкомасштабное внедрение стандарта IPv6, очевидно, напрямую зависит
от появления какого-нибудь суперпопулярного приложения, ориентирован-
ного исключительно на IPv6, или от решения компании Microsoft отправить
протокол IPv4 “на пенсию".
Выделение одресов
В самом начале эпохи Internet отдельные организации обращались в
информационный центр сети Internet (Internet Network Information Center,
InterNIC) за получением адресов. В настоящее время в Америке эту функцию
выполняет ARIN. Только провайдеры Internet, выделяющие достаточное число
адресов в год. имеют право направлять запрос в ARIN напрямую. Все
остальные организации должны обращаться к своим локальным провайдерам.
Формально назначаются лишь сетевые адреса. Организации должны
самостоятельно определять номера компьютеров и закреплять за ними
IP-адреса.
В административном порядке организация ICANN делегировала полно-
мочия по распределению адресов трем региональным канцеляриям, которые
предоставляют блоки адресов провайдерам Internet в рамках своих регионов
(табл. 13.6). Провайдеры, в свою очередь, выделяют адреса отдельным
клиентам. Только крупные провайдеры могут напрямую контактировать со
своими региональными канцеляриями.
Тоблицо 13.6. Регионольные концелярии, отвечоющие зо рослределение lntemet-одресон
Нозвоние	Web-одрес	Охватывоемый регион
ARIN	www.ann.net	Северная и Южная Америка, Африка южнее Сахары
APNIC	www.apnic.net	Азия и Океания
RIPE	www.npe.net	Европа и прилегающие области
Делегирование полномочий от ICANN к ARIN, RIPE и APNIC, а затем
к национальным или региональным провайдерам Internet обеспечивает
должную агрегацию адресов в таблицах маршрутизации магистральных сетей.
Клиенты, получившие адреса из адресного блока своего провайдера, не имеют
маршрутных записей в магистральных серверах. Достаточно одной записи,
ссылающейся на самого провайдера.
Изначально адресное пространство распределялось не самым честным
образом. Правительство США зарезервировало примерно половину адресов
для себя, предоставив Европе и Азии сравнительно небольшие блоки. Однако
в Европе и Азии гораздо рациональнее управляли адресным пространством,
чем в Америке. Это очень хорошо видно на текущей карте распределения
адресов. Она доступна по адресу
http://www.caida.org/analysis/topology/as_core_nefwork
зос
Чость II Робото в сетях
На этой карте демонстрируется все адресное пространство в целом,
выделенные области, маршрутизируемые (т.е. доступные) области, а также
адреса, трафик для которых постоянно замеряется в нескольких основных
точках США
Частные адреса и система NAT
Другое временное решение проблемы исчерпания адресного пространства
заключается в использовании частных областей IP-адресов (RFC 1918) В эпоху
протокола CIDR организации получали свои IP-адреса у провайдеров 1 me met.
Если организация хотела сменить провайдера, она должна была оплатить
услуги по переадресации своих сетей. Дело в том, что провайдер предоставлял
адресное пространство только своим клиентам. При смене провайдера можно
было попытаться убедить старого провайдера оставить зарезервированные за
организацией адреса и попросить нового провайдера настроить на них систему
маршрутизации. Но обычно провайдеры не хотели заниматься подобными
вещами и требовали от клиентов перерегистрации.
В противоположность этому частные адреса не известны провайдеру.
Документ RFCI9I8 определил, что одна сеть класса А, 16 сетей класса В и
256 сетей класса С резервируются для частного использования и никогда не
выделяются глобально. Это делается для того, чтобы пакеты, несущие в себе
частные адреса, никогда не выходили в глобальную сеть. Их должен
фильтровать маршрутизатор В табл. 13.7 указаны диапазоны частных адресов
(в последней колонке каждый диапазон представлен в более короткой нотации
протокола CIDR). Из перечисленных диапазонов организации могут выбирать
для себя сети нужного размера
Тоблицо 13.7. IP-адреса, эорезервировоньые для честного использования
Класс	Начало	Конец	Диапазон CIDR
А	10.0.0.0	10.255.255.255	10.0.0.0/8
В	172.16.0.0	172.31.255.255	172.16.0.0/12
С	192.168.0.0	192.168.255.255	192.168.0.0/16
Чтобы узлы, использующие частные адреса, могли получать доступ в
Internet, на пограничном маршрутизаторе организации выполняется система
NAT (Network Address Translation — трансляция сетевых адресов!. Эта система
перехватывает пакеты и заменяет в них адрес отправителя реальным внешним
IP-адресом Может также происходить замена номера порта. Система хранит
таблицу преобразований между внутренними и внешними алресами/портами.
чтобы ответные пакеты могли поступить правильному адресату.
Благодаря использованию номеров портов появляется возможность под-
ключить несколько исходящих соединений к общему IP-адресу. Таким
образом, группа внутренних узлов может совместно использовать одинаковый
внешний IP-адрес Иногда в организации достаточно иметь один-единствен-
ный ’настоящим'' внешний адрес.
Организация, использующая систему NAT. по-прежнему должна запра-
шивать диапазон адресов у провайдера, но большинство адресов теперь
используется для внутрисистемных привязок и не на тачается отдельным
компьютерам. Если организация захочет сменить провайдера, потребуется
Глово 13 Сети TCP/IP
301
лишь изменить конфигурацию пограничного маршрутизатора и системы NAT.
но не самих компьютеров.
Система NAT реализована в маршрутизаторах нескольких фирм-произ-
водителей. включая Cisco. Можно также заставить саму UNIX-систему
выполнять функции NAT, хотя мы и не рекомендуем делать этого. Подобной
способностью обладают операционные системы Red Hat и FreeBSD*
Подробнее этот процесс описан в параграфах 13.14 и 13.15. По определенным
причинам система NAT в Linux называется “1Р-маскиравание”.
Неправильная конфигурация системы NAT может привести к тому, что
пакеты с частными адресами начнут проникать в Internet. Они достигнут узла
назначения, но ответные пакеты не смогут прийти обратно. Организация
CAJDA (Cooperative Association for Internet Data Analysis — совместная
ассоциация по анализу данных в сети Internet), занимающаяся замером
трафика магистральных сетей, сообщает о том. что 0.1-0.2% пакетов,
проходящих через магистраль, имеют либо частные адреса, либо неправиль-
ные контрольные суммы. На первый взгляд, это кажется очень незначитель-
ным показателем, но на самом деле он приводит к тому, что через узел
МАЕ-West (одна из основных точек обмена, через которую идет трафик
различных провайдеров Internet) каждые 10 минут проходит 20000 пакетов.
Дополнительную информацию по статистике сети Internet и средствам
измерения производительности глобальной сети можно получить на Web-узле
www.caida.org.
Одним из недостатков системы NAT (а возможно, и ее преимуществом)
является то, что произвольный узел в сети Internet не может напрямую
подключиться к внутреннему компьютеру вашей организации. В некоторых
реализациях (например, в брандмауэрах Cisco PIX) разрешается создавать
туннели, которые поддерживают прямые соединения с выбранными узлами.
Другая проблема заключается в том, что некоторые приложения встраи-
вают IP-адреса в информационную часть пакетов. Такие приложения (к ним
относятся определенные протоколы маршрутизации, программы потоковой
доставки данных RealVideo и SHOUTcast, FTP-команды PORT и PASV,
сообщения ICQ и многие игры) не могут нормально работать совместно с
NAT.
Система NAT скрывает внутреннюю структуру сети. Это может показаться
достоинствам с точки зрения безопасности, но специалисты в данной области
говорят, что на самом деле система NAT не обеспечивает должную
безопасность и уж во всяком случае не устраняет потребность в брандмауэре.
Кроме того, она препятствует попыткам оценить размеры и топологию сети
Internet,
Адресеция в стондорте IPv6
В IPv6 адрес имеет длину 128 битов. Изначально столь длинные адреса
вводились для того, чтобы решить проблему сокращения адресного простран-
ства IPv4. Сегодня они также служат целям маршрутизации и локализации
ссылок.
IP-адреса никогда не были географически упорядочены подобно тому,
как это имеет место в сггучае телефонных номеров или почтовых индексов.
Строго говоря. Red Hat поддерживает систему PAT (Port Address Translation — трансляция
адресов портов), а не NAT. IP-адрес машины, выполняющей трансляцию, используется в
качестве единственного “внешнего” адреса, а номер исходящего порта служит осн о вой для
мультиплексирования соединений.
302
Чость II. Робота в сетях
Теперь, с внедрением в стандарт IPv6 понятия сегментации адресного
пространства. IP-адрсса стали, по крайней мере. 1руппироваться в кластеры
вокруг провайдеров Internet. Гранииа между сетевом и машинной частями
адреса в IPv6 зафиксирована на отметке 64 бита В сетевой части адреса
граница между блоками обшей и локальной топологии также зафиксирована
и проходит на отметке 48 битов (табл. 13.8).
Тоблицо 13.8 Компоненты одресо IPv6
Полный адрес IPv6 (120 битов)
1  Префикс провайдера	Подсеть	Идентификатор узла
45 битов	16 битов	64 бита
Тип адреса Збмта		
	Биты	Акроним	Интерпретация
	1-3	FP	Format Prefix — префикс формата; определяет тип адреса, например однонаправленный или групповой
	4-|6	I LA ID	Top-Level Aggregation ID — идентификатор агрегации верхнего уровня, например провайдера магистральной cent
	17-24	RES	Reserved — зарезервировано на будущее
	25-48	NLA ID	Next-Level Aggregation ID — идентификатор агрегации следующего уровня, например регионального провайдера internet или организации
	49-64	SLA ID	Side-Level Aggregation ID — идентификатор агрегации уровня организации, например локальной подсети
I	65—128	INTERF ACE ID	Идентификатор интерфейса (МАС-адрес плюс биты-за- полнители)
Из перечисленных элементов только идентификаторы SLA и INTERFACE
“принадлежат" узлу и организации, в которой он находится. Другие
идентификаторы предоставляются провайдером. Идентификатор SLA опреде-
ляет локальную подсеть, а 64-разрядный идентификатор интерфейса опреде-
ляет сетевую плату компьютера В последнем, как правило, содержится
48-разрядный МАС-адреи, внутрь которого вставлены два байта-заполнителя
(OxFFFE). Специальный бит МАС-адреса (седьмой слева в старшем байте),
называемый битом “и’\ определяет то, каким является этот адрес: универ-
сальным или локальным (RFC2373). Его наличие позволяет автоматически
нумеровать узлы. что очень удобно для администраторов, которым остается
управлять только подсетями.
В IPv6 МАС-адреса видны на уровне IP, что имеет как положительные,
так и отрицательные стороны Тип и модель сетевой платы кодируются в
первой половине МАС-адреса. что облегчает задачу хакерам. Это вызвало
беспокойство со стороны специалистов в области безопасности. Однако
разработчики стандарта IPv6 указали на то. что использование МАС-адресов
не является обязательным. Были предложены схемы включения случайного
идентификатора в локальную часть адреса.
Годе 13 Сети TCP/IP
303
С другой стороны, назначать адреса IPv6 проще, чем адреса IPv4, так
как нужно отслеживать только адрес подсети. Узлы могут самостоятельно
конфигурировать себя (по крайней мере, теоретически).
Префикс формата определяет тип адреса: однонаправленный, групповой
или широковещательный. Для однонаправленных адресов префикс равен 001
(в двоичной системе). Идентификаторы TLA и NLA определяют соответст-
венно магистральный сервер верхнего уровня и локального провайдера
Internet.
Большинство поставщиков разрабатывает или уже внедрило в эксплуата-
цию собственный стек протоколов IPv6. В табл. 13.9 указана степень
готовности стеков IPv6 различных производителей операционных систем и
маршрутизаторов. (Переключатели не заботятся об адресах IPv6, так как не
принимают участия в маршрутизации и не заглядывают внутрь IP-заголовка.)
Тоблицо 13.9. Готовность стеков IPv6 розличных поставщиков
Система	Поддержка IPv6	Комментарии
Solaris	да	Solaris 8 и выше
HP-UX	да	Пакеты инструментальных средств разработки поставляются с HP-UX 11.00
Red Hat	да	Поддержка IPv6 интегрирована в ядре Linux версий 2.2 и выше
FreeBSD	да	FreeBSD 4.0 и выше1
Windows 2K	частично	Доступна исследовательская версия (включая ис- ходные тексты)
Cisco	да	Реализован в алгоритме медленного обнаружения маршрута2
Jumper	нет	—
Bay	да	Поставляется с 1997 г.
1	Во FreeBSD 3.4 нс было поддержки IPv6, но в этой системе могуг выполняться
стеки сторонних поставщиков, таких как INRIA и КАМЕ.
2	Возможно, по требованию клиентов будет реализован в алгоритме быстрого
обнаружения маршрута.
Подробную информацию о реализации стека IPv6 можно получить по
адресу
http://playground.sun.com/pub/ipng/-html/ipng-implementation.htnil
Адресные канцелярии недавно начали выделять адреса в пространстве
IPv6. Пока что ARIN предоставляет адреса только крупным провайдерам,
которые в ближайшие 12 месяцев планирутот развернуть сеть IPv6. Эти
провайдеры могут затем предоставлять адреса своим клиентам.
Вот несколько полезных источников информации, касающейся IPv6:
•	www.6bone.net — испытательный полигон для сетей IPv6;
•	www.6rcn.net — всемирная научно-исследовательская и общеобразователь-
ная сеть IPv6;
•	www.ipv6.org — список FAQ-документов и различная техническая инфор-
мация;
•	www.ipv6forum.coni — форум приверженцев IPv6.
304
Чость II. Робою в сетях
Основное преимущество стандарта IPv6 заключается в том. что он решает
проблему смены адресов. В пространстве IPv4 провайдеры выделяют адресные
блоки своим клиентам, но эти адреса не являются переносимыми когда
клиент меняет провайдера, он должен вернуть старые адреса и запросить
новые. В IPv6 новый провайдер просто предоставляет клиенту собственный
адресный префикс, который добавляется к локальной части существующего
адреса. Обычно это выполняется на одной машине: пограничном маршрути-
заторе организации. Подобная схема напоминает систему NAT, но лишена
ее недостатков.
13.5.	Маршрутизация
Маршрутизация — это процесс направления пакета по лабиринту сетей,
находящихся между отправителем и адресатом. Маршрутизация в TCP/IP
происходит подобно тому, как путешественник, первый раз посетивший
незнакомую страну, отыскивает нужный ему дом, задавая вопросы местным
жителям. Первый человек, с которым он заговорит, возможно, укажет ему
нужный город. Войдя в этот город, путешественник спросит другого
прохожего о нужной улице, и тот расскажет, как туда попасть. В конце
концов наш путешественник подойдет достаточно близко к конечному пункту
своих странствий, чтобы кто-нибудь указал ему дом, который он ищет.
Данные маршрутизации в системе TCP/IP имеют форму правил (маршру-
тов), например: “Для того чтобы достичь сети А, посылайте пакеты через
машину С”. Может существовать и стандартный маршрут; он объясняет, что
нужно делать с пакетами, предназначенными для отправки в сеть, маршрут
к которой не указан явным образом.
Данные маршрутизации хранятся в одной из таблиц ядра. Любой элемент
подобной таблицы содержит несколько параметров, включая сетевую маску
для каждой перечисленной сети (раньше это поле было опциональным, но
теперь оио обязательно, если стандартная сетевая маска неверна). Для
направления пакета по конкретному адресу ядро подбирает наиболее подхо-
дящий маршрут (т.е. тот, где самая длинная маска). Если ни один из
маршрутов (в том числе стандартный) не подходит, то отправителю возвра-
щается ICMP-сообшение об ошибке “network unreachable’’ (сеть недоступна).
Слово “маршрутизация” употребляется:
•	с целью обозначения процедуры поиска сетевого адреса в специальной
таблице для направления пакета а пункт его назначения;
•	для обозначения процесса построения упомянутой таблицы.
Ниже мы рассмотрим, как осуществляется переадресация пакетов и как
вручную добавить или удалить маршрут. Более сложные вопросы, связанные
с работой протоколов маршрутизации, создающих и обслуживающих мар-
шрутные таблицы, освещаются в главе 14.
Таблицы маршрутизации
Таблицу маршрутизации можно просмотреть с помощью команды net-
stat -г, доступной во всех системах, или route get в BSD-системах. Команда
будет подробно изучена в параграфе 20.4, здесь же мы приведем небольшой
пример, чтобы у читателей было представление о том, что такое маршруты.
В рассматриваемой системе две сетевые платы: 132.236.227.93 (ethO) в сети
132.236.227.0/24 и 132.236.212.1 (ethl) в сети 132.236.212.0/26.
% netetat -г -п
Kernel IP routing table
Destination Mask	Gateway	Fl MSS If
Глово 13. Сети TCP/IP
305
132.236.227.0
default
132.236.212.0
132.236.220.64
127.0.0. 1
255.255.255.0
0.0.0.0
255.255.255.192
255.255.255.192
255.255.255.255
132.236.227.93
132.236.227.1
132.236.212.1
132.236.212.6
127.0.0.1
U 1500 ethO
UG 1500 ethO
U 1500 ethl
UG 1500 ethl
U 3584 loO
Поле destination обычно содержит сетевой адрес. В поле gateway
должен быть указан адрес узла Например, четвертый маршрут говорит о том,
что для достижения сети 132.236-220.64/26 пакеты следует посылать в шлюз
132.236.212.6 через интерфейс ethl Вторая запись содержит стандартный
маршрут; пакеты, нс адресованные явно ин одной из указанных сетей (или
самому компьютеру), будут направлены в стандартный шлюз 132.236.227.1.
Компьютеры могут посылать пакеты только тем шлюзам, которые физически
подключены к той же самой сети.
Вести таблицы маршрутизации можно статически, динамически или
комбинированным методом. Статический маршрут — это маршрут, который
задается явно с помощью команды route. Он должен оставаться в таблице
маршрутизации на всем протяжении работы системы. Во многих случаях
такие маршруты задаются с помощью одного из стартовых сне париев во
время начального запуска системы. Например, в Red Hai команды
; route add -net 132.236.220.64 netmaak 255.255.255.192
132.236.212.6
t route add default 132.236.227.1
добавляют четвертый и второй маршруты из числа тех, что отображаются
выше командой netstat -г -п t первый и третий маршруты добавляются
командой ifconlig при конфигурировании устройств ethO и ethl).
Полное описание команды route приведено в параграфе 13.10.
Последний маршрут также добавляется на этапе начальной загрузки. Он
определяет псевдоустройство, называемое интерфейсом обратной связи. Это
устройство не дает пакетам, которые компьютер посылает сам себе, выходить
в сеть. Вместо этого они напрямую переносятся из выходной очереди во
входную внутри ядра.
В относительно стабильной локальной сети статическая маршрутиза-
ция — достаточно эффективное решение. Эта система проста в управлении
и надежна, но она требует, чтобы системный администратор знал топологию
сети ня момент начальной загрузки и чтобы эта топология в периоды между
загрузками не изменялась. Компьютеры локальной сети имеют один единст-
венный выход во внешний мир, поэтому маршрутизация осуществляется
очень просто: достаточно на этапе начальной загрузки добавить стандартный
маршрут.
В сетях с более сложной топологией требуется динамическая маршрути-
зация. Она выполняется процессом-демоном, который ведет и модифицирует
таблицу маршрутизации. Демоны маршрутизации, “обитающие" на различных
машинах, общаются между собой с пелью определения топологии сети и
решения вопроса о том, как добраться до дальних адресатов. Имеется
несколько таких демонов. В главе 14 мы опишем стандартный UNIX-демон
routed и более совершенный демон gated, а также протоколы, на которых
они общаются.
ЗОи
Чость II. Роботе в сетях
Переадресующие пакеты протокола ICMP
В принципе, протокол IP не предусматривает средств управления
маршрутной информацией, но в нем есть небольшой механизм контроля
нарушений — переадресующие ICMP-пакеты. Если маршрутизатор направ-
ляет пакет компьютеру, находящемуся в той же сети, из которой этот пакет
был получен первоначально. то что-то работает явно неправильно. Поскольку
отправитель, маршрутизатор н маршрутизатор следующего уровня находятся
в одной сети, то пакет, вероятно, можно послать не через два перехода, а
через один. Маршрутизатор делает вывод о том. что таблицы маршрута займи
отправителя — неточные или неполные.
В этой ситуации маршрутизатор может уведомить отправителя о данной
проблеме с помошыо переадресуюшего ICMP-пакета. Такой пакет, по сути
дела, сообщает: "Не нужно посылать мне пакеты для машины хюг. их следует
адресовать машине зп-т". Протокол ICMP позволяет посылать переадресующие
пакеты как ио адресам отдельных компьютеров, так и целым сетям Во многих
реализациях, однако, допускается создание пакетов только первою типа.
Получив переадресуюший пакет, отправитель должен обновить свою
таблицу маршрутизации, чтобы следующие пакеты, предназначенные для
данного адресата, шли но более прямому пути Раньше, когда только
появилась технология группового вешания, некоторые системы генерировали
переадресующие ICMP-пакеты в ответ на получение групповых пакетов.
Современные системы избавлены от подобной проблемы
Стандартный ICMP-сценарий не подразумевает этапа аутентификации
Маршрутизатор получает от другою, известного ему маршрутизатора команду
перенаправить трафик в другое место. Нужно ли подчиниться этой команде?
В действительности такой сценарии создает определенные проблемы с точки
зрения безопасности. Поэтому переадресующие пакеты запрещены в ядрах
Linux н FreeBSD, а также в маршрутизаторах Cisco Считается, что пе стоит
позволять непроверенным узлам модифицировать таблицы маршрутизации.
13.6.	ARP протокол преобразования адресов
Несмотря на то что идентификация IP-пакетов осуществляется при
помоши IP-адресов, для фактической передачи данных через канальный
уровень должны применяться аппаратные адреса’. Определением того, какой
аппаратный адрес связан с данным IP-адресом, занимается протокол ARP
(Address Resolution Protocol — протокол преобразования адресов) Его можно
применять в сетях любых типов, которые поддерживают широковещательный
режим. но чаще всею этот протокол рассматривают в контексте сети Ethernet.
Когда компьютер А хочет послать пакет компьютеру Б. расположенному
в том же самом Ethernet-сегменте, он использует протокол ARP для отыска»П1я
аппаратного адреса Б. Если Б не находится в той же сети. А с помошыо
протокола ARP выясняет аппаратный адрес маршрутизатора следующего
уровня, которому будут посылаться пакеты, адресованные Б Так как в ARP
применяются широковещательные пакеты, которые не могут выити за
пределы локальной сети”, этот протокол позволяет находить только адреса
компьютеров, непосредственно подключенных к той же самой сети.
Эго не касается соединений типа “точка-точка1', где получатель очевиден.
Часто маршрутизатор можно сконфшурировать так. что он будет пропускать широковеща-
тельные пакеты в другие сети. Нс делайте этого!
Глово 13 Сети TCP/IP
307
Каждый компьютер хранит в оперативной памяти специальную таблицу,
называемую кэшем ARP. Кэш содержит результаты последних ARP-запросов.
В нормальных условиях многие адреса, необходимые компьютеру, выявляются
вскоре после начальной загрузки, поэтому протокол ARP не оказывает
серьезного воздействия на загруженность сети.
Протокол ARP функционирует путем широковещательной рассылки
пакета примерно следующего содержания: “Знает ли кто-нибудь аппаратный
адрес для 128.138.116.4?"’ Машина, которую разыскивают, узнает свой адрес
и посылает ответ: "Это я. мой El heme [-адрес — 8:0:20:0:fb‘6a”.
Исходный запрос содержит IP-адрес и Elhemei-адрес запрашиваются
стороны, благодаря чему разыскиваемая машина может ответить, не выдавая
собственный ARP-запрос. Таким образом, оба компьютера узнают адреса друг
друга всего за один сеанс обмена пакетами. Другие компьютеры, •‘слышав-
шие" исходное широковещательное сообщение, посланное инициатором
запроса, тоже могут записать информацию о его адресах.
В большинстве систем имеется команда агр. которую можно применять
для изучения и обработки содержимого кэша ARP. Она обычно используется
для добавления и удаления записей. Команда агр -а отображает содержимое
кэша; естественно, в каждой системе у нее свой формат.
Вот примеры выполнения команды агр -а в Solans и Red Hat:
solaria* /u»r/ibin/arp -в
Net to Media Table
Device IP Address Mask	Flags Phys Addr
hmeO titania
hmeO earth
hmeO pluto
255.255.255.255
255.255.255.255
255.255.255.255
00:50:da:6b:b5:90
00:50:da:12:4e:e5
00:50:da:12:4e:19
redhat* /яЫп/агр -*
xor.com (192.109.21.1) at 08:00:20:77:5E:A0 [ether] on ethO
earth.xor.com (192.108.21.180) at 00:50;DA:12:4E:E5 [ether] on ethO
lollipop.xor.com (192.108.21.48) at 08 :00:20.-79:4F:49 [ether] on ethO
Команда агр, как правило, используется в целях отладки н при работе
со специальным оборудованием. Некоторые устройства не могут общаться
по протоколу ARP (например, сетевые принтеры и специализированные
графические мониторы), и для включения их в сеть нужно сконфигурировать
другую машину в качестве агента-посредника ARP. Обычно этой цели служит
команда агр.
Если два компьютера в сети имеют одинаковый 1Р-адрес, то на одном
из них запись в ARP-таблице будет правильной, а на другом — нет.
С помощью команды агр можно найти машину-нарушитель.
Иногда аппаратные адреса нужно транслировать в IP-адреса. Многие
специальные аппаратные устройства (бездисковые рабочие станции, сетевые
компьютеры, принтеры) делают это во время начальной загрузки. Вместо
того чтобы жестко задавать IP-адрес в файле конфигурации^ машина может
обратиться к центральному серверу, который сообщит ей ее собственный
адрес. Обратные преобразования адресов выполняет протокол RARP (Reverse
ARP — обратный протокол ARP), который представляет собой устаревшее
расширение протокола ARP.
В АКР применяются средства широковешания канального уровня, а нс протокола 1Р
308
Часть II Работа в сетях
В отличие от ARP. RARP требует, чтобы в каждой сети был запущен
центральный серверный процесс Протокол RARP не предполагает самокон-
фитурирования; нужно указать явное соответствие между Ethernet-адресами
и их IP-эквивалентами. В большинстве систем, которые поддерживают RARP.
в качестве процесса выступает демон rarpd. а данные конфигурации
извлекаются из файлов /etc/clhcrs и /etc/hosls.
Протокол RARP в настоящее время практически не используется. Сначала
ему на смену пришел протокол ВООТР, а затем — DHCP.
13.7.	DHCP: протокол динамического
конфигурирования узлов
Для добавления UNIX-узлов в сеть всегда требовалась ручная настройка.
Но если компьютеры Мас или Intel без проблем подключаются к сети, то
почему нельзя делать то же самое в UNIX? Протокол DHCP (Dynamic Host
Configuration Protocol — протокол динамического конфигурирования узлов)
позволяет удовлетворить столь естественную потребность пользователей.
Этот протокол дает возможность клиенту взять некоторые сетевые и
административные параметры “в аренду" у центрального сервера, отвечаю-
щего за их распространение. Парадигма аренды особенно подходит для
персональных компьютеров, которые выключены, если на них никто не
работает, и провайдеров Internet, имеющих дело с клиентами, подключаю-
щимися по коммутируемым линиям.
К "арендуемым” параметрам относятся:
•	IP-адреса и сетевые маски;
•	шлюзы (стандартные маршруты);
•	адреса DNS-серверов;
•	имена машин, на которых выполняется система Sysiog;
•	адреса серверов WINS, NTP и прокси-серверов;
•	адреса серверов TFTP (для загрузки начального образа)
и десятки других (см. документ RFC2132). Экзотические параметры редко
используются на практике В большинстве случаев DHCP-сервер предостав-
ляет лишь базовые сетевые параметры, такие как 1Р-адреса, сетевые маски,
стандартные шлюзы и имена серверов DNS.
Периодически клиенты должны повторно обращаться к DHCP-серверу,
чтобы обновить свои параметры. Если параметр не будет обновлен, он станет
недействительным. DHCP-сервер будет волен предоставить его другому
клиенту. Срок аренды может меняться, но обычно он достаточно большой
(до нескольких дней).
Протокол DHCP существенно облегчает жизнь системным администра-
торам. Когда сервер DHCP сконфигурирован и запущен, клиенты автомати-
чески определяют параметры сетевой конфигурации на этапе начальной
загрузки. Никакой путаницы не возникает
Программное обеспечение DHCP
В табл. 13.10 перечислены программные компоненты DHCP, входящие
в состав четырех наших тестовых систем.
Гпоно 13. Сети TCP/IP
309
Таблица 13.10. Программные компоненты DHCP в тестовых системах
Системе	РНСР-клиент__________________РНСР-сервер
Solaris	/sbin/dbepagent	/usr/iib/inet/in.dhcpd1
HP-UX	встроенный, также auto_paranis	bootpd
Red Hat	/usr/sbin/dbeped и /sbin/pump	/usr/sbin/dhcpd dt ISC
FreeBSD	/sbin/dhclient			/usr/ports/net/ise-dhcpZ
Имеется shell-сценарий dhcpconfig, который позволяет конфигурировать DHCP-сер-
вер Solaris.
Консорциум разработчиков программного обеспечения Interne! (Internet
Software Consortium, ISC) создал эталонную реализацию протокола DHCP.
Клиент, сервер и агент ретрансляции доступны по адресу ftp.isc.oig. Сервер
ISC также поддерживает протокол ВООТР (он напоминает DHCP, но не так
сложен).
Мы рекомендуем пакет ISC, а не пакеты конкретных поставщиков
В типичной гетерогенной среде процедура администрации сильно упростится,
если будет применяться стандартная единая реализация протокола DHCP.
Программное обеспечение ISC — это надежное решение, распространяемое
на условиях открытой лицензии и без проблем инсталлируемое в большинстве
версий UNIX. На момент написания данной книги готовился выпуск 3.0, в
котором были обешаны новые полезные параметры конфигурации, включая
раздельные пулы адресов, условное поведение и многое другое.
DHCP-клиенты должны инициировать диалог с DHCP-сернером при
помощи пакета с общим широковещательным адресом (все единицы), гак
как они еще не знают свои сетевые маски. К‘сожалению, некоторые ядра
(HP-UX и Linux) могут работать только с локальными широковещательными
адресами. Это не позволяет клиентам и серверам соединяться друг с другом
и обмениваться информацией. В документации по 1SC указываются пути
решения данной проблемы. Тем не менее, гетерогенные среды все еше
представляют определенные трудности для протокола DHCP. Каждым раз
при установке нового сервера или клиента нового типа приходится тщательно
все проверять.
DHCP-сервер IS С понимает протокол динамического обновления базы
данных DNS. Сервер не только предоставляет компьютеру 1Р-адрес и другие
сетевые параметры, но также вносит в базу данных DNS запись о соответствии
между именем машины и ее IP-адресом Дополнительная информация об
этом приведена в параграфе 16.12.
Мы вкратце рассмотрим особенности протокола DHCP, а затем опишем,
как установить сервер 1SC, реализующий этот протокол. Вопросы конфигу-
рирования DHCP-клиентов будут обсуждаться в параграфах, посвящен пых
конкретным клиентам.
Схема работы DHCP
DHCP — это расширение протокола ВООТР, который был придуман для
того, чтобы бездисковые станции UNIX могли загружаться по сети. Подсис-
тема ВООТР предоставляет клиентам IP-адреса, сетевые маски, стандартные
шлюзы, а также информацию, касающуюся начальной загрузки через TFTP
(Trivial File Transfer Protocol — простейший протокол передачи файлов)
310
Чость П. Робото в сетях
Протокол DHCP не ограничивается этими параметрами, вводя понятие
'‘аренды”.
DHCP-клиент начинает диалог с DHCP-сервером, посылая сообщение
DHCPDISCOVER’, которое можно перевести так: “Помогите мне узнать, кто
я”. Так как клиент не знает ни свой собственный, ни серверный 1Р-адрес,
он посылает сообщение по широковещательному адресу 255.255.255.255,
указывая адрес отправителя 0.0.0.0. Сообщение DISCOVER может содержать
подсказки от клиента, например информацию о том, какова аппаратная
архитектура клиента или какой конкретный адрес ему требуется.
Сообщение DISCOVER обычно принимается DHCP-сервером, находя-
щимся в той же подсети Но оно может также поступить в другие подсети
через специальный прокси-сервер, называемый агентом ретрансляции.
В ответ серверы выдают сообщение OFFER, содержащее предлагаемый
адрес и другие базовые параметры. Клиент получает это сообщение (возмож-
но, от нескольких серверов одновременно) и принимает одно из предложений,
посылая выбранному серверу сообщение REQUEST Обычно сервер возвра-
щает в ответ подтверждающее сообщение АСК и назначает клиенту адрес
В сообщение АСК может включаться произвольное число конфигурируе-
мых параметров; оно также задает срок аренды. В ответ на неправильное
сообщение REQUEST сервер может выдать сообщение NAK, указывающее
на то. что клиенту' необходимо начать процесс сначала.
Прежде чем начать использовать адрес, клиент должен проверить его с
помощью протокола ARP. Если адрес уже где-то задействован, клиент
посылает серверу сообщение DECLINE, и все начинается сначала.
Когда срок аренды приближается к концу. клиент должен обновить
арендованные параметры, послав новое сообщение REQUEST. Если клиент
решает прекратить аренд}', он посылает сообщение RELEASE.
Сервер обязан отслеживать адреса, предоставленные в аренду, и сохранять
эту информацию между перезагрузками. Предполагается, что клиенты делают
то же самое, хотя это не обязательно. Цель заключается в максимальной
стабилизации сетевой конфигурации.
Протокол DHCP обычно не используется для конфигурирования комму
тируемых PPP-интерфейсов. Этой цели служит специальный протокол РРРСР
(РРР Control Protocol — протокол управления РРР-соелинсниями).
DHCP-сервер ISC
DHCP-сервер ISC доступен по адресу fip.isc.org или www.isc.org. Ниже
рассмотрена версия 2.0. Близка к завершению версия 3.0. поэтому не забудьте
проверить, актуален ли приведенный ниже материал в той версии, которую
вы загрузите.
Распакуйте файл tar.gz и перейдите в дистрибуционный каталог. Там
должны быть подкаталоги для сервера, клиента н агента ретрансляции, а
также каталог для совместно используемого кода. Запустите команду ./con-
figure. а за ней — make и make install, чтобы скомпилировать и установить
каждый компонент.
Для конфигурации DHCP-сервера, dhcpd. нужно отредактировать файл
dhepd.conf в каталоге sener и записать его под именем /etc/dbcpd.conC
Все DHCP-сообщения начинаются с префикса “DHCP”. Чтобы текст легче читался, мы
будем исключать этот префикс при упоминании имен сообщений.
Будьте осторожны! У файла dhepd.conf очень “чувствительный” формат: достаточно удалить
какую-нибудь точку' с запятой, и будет выдано непонятное сообщение об ошибке.
Глово 13 Сети TCP/IP
311
Необходимо также создать пустой файл базы данных по арендуемым
параметрам, назвав его /var/db/dhcp.leases- Убедитесь, что демон dhepd имеет
право записи в этот файл. Для настройки файда dhcpd.conf потребуется
следующая информация:
•	подсети, для которых демон dhepd должен управлять IP-адресами, и
диапазоны выделяемых адресов;
•	начальный и максимальный срок аренды в секундах;
•	конфип'раниопные параметры клиентов ВООТР, если таковые имеются
(им назначаются статические IP-адреса, также должны быть указаны их
аппаратные МАС-адреса);
•	все остальные параметры, которые сервер должен передавать DHCP-кли-
ентам: сетевая маска, стандартный маршрут, домен DNS. серверы имен
и т.д.
На тал-странице, посвященной демону dhepd, рассмотрен процесс
конфигурации. Точный синтаксис конфигурационного файла описан на
man-странице, которая посвящена файлу dhcpd.conf. Обе эти страницы
расположены в подкаталоге server дистрибуционного каталога.
Демон dhepd должен запускаться автоматически на этапе начальной
загрузки системы. Удобно сделать запуск демона условным, осуществляемым
при наличии файла /etc/dhcpd.conf.
Ниже показан пример конфигурационного файла dhepd.conf, взятого из
Linux-системы с двумя интерфейсными устройствами: одним внутренним и
одним внешним, подключенным к Internet. На компьютере выполняется
система NAT для трансляции адресов внутренней сети, которой выделяется
10 IP-адресов. Файл содержит пустую запись для внешнего интерфейса
(обязательна) и запись host для одной конкретной машины, которой нужен
фиксированный адрес.
#	dhcpd.conf
#
#	глобальные параметры
option domain-name "synack-net*';
option domain-name-servers gw.synack.net;
option subnet-mask 255.255.255.0;
detault-lease-tirue 60C;
max-lease-rime 7200;
subnet 192.168.1.0 netmask 255.255.255.0
range 192.168.1.51 192.168.1.60;
option broadcast-address 192.168.1.255;
option routers gw.synack.net;
}
subnet 2C9.180.251.0 netmask 255.255.255.0
1
host gandalf (
hardware ethernet 08:00:07:12:34:56;
fixed-address gandalf.synack.net;
j
Адреса, назначаемые DHCP-сервером, потенциально могут конфликто-
вать с содержимым базы данных DNS. Очень часто каждому динамически
выделяемохгу адресу присваивается об шее имя (например, dhcpl.synack.net)
312
Чость И Робота в сетях
и разрешается, чтобы имена отдельных машин "сосуществовали" с IP-адре-
сами. Если имеется одна из последних версий системы BIND, которая
поддерживает динамические обновления, можно сконфигурировать демон
dhcpd, чтобы он обновлял базу данных DNS при выделении очередного адреса.
Динамическое обновление — сложная процедура, но она позволяет устранить
конфликты имен ухтов.
Подробнее о DNS будет рассказано в главе 16.
Демон dhcpd добавляет запись о каждом акте аренды в файл dhcp.leases.
Он также периодически создает резервную копию этого файла, переимено-
вывая его в dhcpd.leases' и воссоздавая исходный файл dhcp.leases на
основании информации из базы данных, находящейся в памяти. Если в
процессе этой операции произойдет сбой, останется только файл dhcpd.leases'
В таком случае демон dhcpd откажется запускаться, и придется переимено-
вывать файл вручную. Нельзя просто создать пустой файл dhcp.leases. иначе
возникнет хаос, так как у клиентов окажутся дублирующиеся адреса.
13.8.
РРР: протокол двухточечного соединения
РРР (Point-to-Point Protocol — протокол двухточечного соединения) —
это протокол, определяющий правила кодирования IP-пакетов для передачи
по медленному (и часто ненадежному) последовательному каналу. Каналы
данного типа просто ретранслируют потоки битов и не знают о том, где
начинается и заканчивается пакет. За кодирование и декодирование пакетов,
передаваемых через последовательный канал, отвечает драйвер РРР. Он
добавляет к пакету1 заголовок канального уровня и маркеры-разграничители.
Протокол РРР иногда применяется в новых “домашних” технологиях,
таких как DSL и кабельные модемы, но пользователи обычно об этом не
знают. Инкапсуляция пакетов выполняется интерфейсным устройством, и
весь трафик проходит через Ethernet, так что пользователь видит лишь
Et he met-соединение.
Предшественниками РРР послужили протоколы SLIP (Serial Line Internet
Protocol — межсетевой протокол для последовательного канала) и CSLIP
(Compressed SLIP — сокращенный протокол SLIP), разработанные соответ-
ственно Риком Адамсом (Rick Adams) и Ваном Джейкобсоном. Протокол
РРР отличается от них тем. что позволяет передавать пакеты множества
протоколов по одному каналу. Описание этого протокола приведено в
RFC 1331.
В состав протокола РРР входят три компонента:
•	процедура инкапсуляции дейтаграмм для передачи их по последователь-
ным каналам.
•	протокол LCP (Link Control Protocol — протокол управления каналом),
предназначенный для установления, конфигурирования и тестирования
соединения на канальном уровне:
•	семейство протоколов NCP (Network Control Protocol — протокол управ-
ления сетью), обеспечивающих конфигурирование и функционирование
различных протоколов сетевого уровня.
Эти компоненты вместе с таблицами состояний, безупречными с точки
зрения теории конечных автоматов, подробно описываются в RFC-докумен-
тацин, поэтому мы не будем на них останавливаться.
Гпово 13 Сети TCP/IP
313
Поддержка PPP имеется во всех четырех тестовых системах. В табл. 13.11
указано местоположение соответствующих команд и конфигурационных
файлов.
Тоблицо 13.11. Комонды и конфигурационные файлы протокола РРР в розничных
системой
Система	Команды1	Конфигурационные файлы
Solaris	/usr/sbin/espppd /usr/sbin/aspppls	/etc/asppp.cf /etc/uucp/Sysicme /etc/uucp/ Devices /ctc/uucp/Dialers /etc/uucp/Auth
HP-UX	/usr/bin/pppd /etc/ppp/Autosurt	/etc/ppp/Systcms /erc/ppp/Filier /eic/ррр/Devices /elc/ppp/Dialers /etc/ppp/Auth /etc/ppp/Keys
Red Hat	/usr/sbin/pppd /usr/sbin/chat	/etc/ppp/options /etc/ppp/ppp.conf /ctc/ppp/allow
FreeBSD	/usr/sbin/pppd /usr/sbin/chat	/eic/ppp/options /etc/ppp/options.ttyscrver /etc/ppp/cha t.ttyservcr
Списки файлов и команд поданы независимо друг от друга. Между командой и
указанным рядом с ней файлом не обязательно есть соответствие.
Производительность РРР
Протокол РРР обеспечивает все функциональные возможности Ethernet,
но на гораздо меньшей скорости. Обычные офисные локальные сети работают
со скоростью 10 или 100 Мбит/с. т.е. примерно 10000—100000 Кбнт/с.
А коммутируемое соединение функционирует со скоростью 28—56 Кбит/с."
Подобное соотношение приводит к тому, что для передачи файла размером
1 Мбайт через РРР-каиал требуется примерно 5 минут. Это еще можно
стерпеть при отправке электронной почты, но не при работе с Web-узлами
Чтобы повысить скорость, можно задать параметр MTU (максимальным
размер передаваемого блока) соединения очень низким. По умолчанию он
равен 512 байтам; задайте 128. если выполняется много интерактивной
работы
Работать с NFS через PPP-канал очень неудобно из-за ни жом скорости
Имеет смысл делать это только в том случае, когда NFS нсполыует протокол
TCP, а не UDP. В некоторых системах (например, в Solaris) протокол TCP
применяется в NFS по умолчанию.
Подробнее об NFS говорится в главе 17.
В X Windows также используется TCP, поэтому через PPP-канал можно
запускать Х-приложения. Программы наподобие xterm работают прекрасно.
Протокол РРР чаше всего применяется в соединениях со скоростью работы 19200 бод. Он
может использоваться и в более медленных каналах, но скорость становится невыносимо
низкой.
314
Чость II. Роботе в сетях
0
но следует избегать приложений с экзотическими шрифтами и растровой
графикой.
Подключение к сети посредством РРР
Для того чтобы соединить компьютер с сетью средствами РРР, нужно
обеспечить выполнение трех требований.
•	Ядро компьютера должно уметь посылать IP-пакеты по последователь-
ному каналу в соответствии с требованиями протокола РРР.
•	Необходимо, чтобы в системе была программа пользовательского уровня,
позволяющая устанавливать и обслуживать РРР-соединения.
•	На другом конце последовательного канала должна быть система,
понимаюшая используемый протокол.
Как заставить компьютер общаться по протоколу РРР
Для установки РРР-соединения нужно, чтобы система могла посылать и
принимать PPP-пакеты. В UTsllX протокол РРР реализован в виде модуля
ядра, который помещает сетевые пакеты в выходную очередь последователь-
ного устройства и извлекает поступающие пакеты из входной очереди. Обычно
этот модуль функционирует подобно сетевому интерфейсу, поэтому им можно
манипулировать с помощью стандартных средств, например команды ifconfig.
Более подробные сведения о команде ifconfig вы найдете в параграфе 13.10.
Управление РРР-каналами
Точная последовательность событий, происходящих при установлении
РРР-соединения. зависит от операционной системы и тип» сервера, с которым
осуществляется связь. Соединения можно устанавливать либо вручную, либо
динамически.
При ручном подключении пользователь запускает команду, которая
вызывает модем, аконит в удаленную систему и загружает в ней демон
протокола РРР Если эта процедура заканчивается успешно, последовательный
порт конфигурируется как сетевой интерфейс. В этом случае канал обычно
остается активным длительное время, что лучше всего подходит для
выделенных телефонных линий.
В динамической конфигурации демон наблюдает за последовательными
‘сетевыми” интерфейсами, отслеживая запросы на передачу данных через
них. Когда кто-то пытается послать пакет, демон автоматически вызывает
модем для установления соединения, передает пакет и, если канал возвра-
щается в режим ожидания, по истечении соответствующего периода времени
разрывает соединение. Динамические каналы применяются, когда по теле-
фонной линии передаются как голосовые, так н двоичные данные, а также
когда осуществляются звонки на большие расстояния или соединение
является платным.
Программы, реализующие обе эти схемы, входят в состав большинства
версий РРР.
Поиск компьютера для связи
Когда организуется канал связи между двумя удаленными узлами
компании или между офисом и домом, можно просто инсталлировать
Глоеа 13. Сети TCP/IP
315
протокол РРР на обоих концах соединения. Если же речь идет об
использовании этого протокола для подключения к Internet, следует обра-
титься к провайдеру. Большинство провайдеров предлагает коммутируемые
соединения по разумной цене.
Присвоение одресов
Каждому PPP-интерфейсу должен быть назначен !Р-адрес, подобно тому
как это имеет место при включении нового компьютера в сеть Ethernet
Существует несколько способов назначения адресов PPP-каналам (иногда для
установления связи присваивать адреса вообще нс требуется). Ниже рассмот-
рен самый простой из них.
Более детальная информация о назначении IP-адресов приведена в парагра-
фе 13.10.
PPP-канал нужно рассматривать как отдельную сеть, т.е. сеть, состоящую
из двух машин (ее часто называют ‘'двухточечной” сетью). Сетевой адрес
присваивается каналу так же, как и новому сегменту Ethernet, в соответствии
с правилами, принятыми в организации Можно выбрать два любых адреса
компьютеров в этой сети и присвоить по одному адресу каждому концу
канала. Необходимо следовать и другим местным правилам, например
стандартам назначения маски подсети. Каждый из компьютеров, нмеюшмй
подобное соединение, становится для внешнего миром “шлюзом” к рассмат-
риваемой двухточечной сети.
Для назначения IP-адресов может также применяться протокол DHCP.
Домашним клиентам провайдеры Internet обычно предоставляют услуги
DHCP, а организациям выделяют статические адреса.
Маршрутизоция
Поскольку протокол РРР требует, чтобы удаленный сервер выступал н
роли IP-маршрутизатора, вопросы IР-маршругмзации должны учитываться
так же, как и на реальном шлюзе (например, на машине, соединяющей две
сети Ethernet). Задача маршрутизации заключается в направлении пакетов по
шлюзам в заданные пункты назначения
Настраивать схему' маршрутизации можно разными способами. На
рядовом РРР-клпенте должен быть задал маршрут по умолчанию, обеспечи-
вающий направление пакетов к PPP-серверу. Необходимо, чтобы сервер был
известен остальным машинам сети как шлюз к клиенту.
Подробнее о маршрутизации читайте в гюве 14.
Большинство PPP-систем выполняют эти операции автоматически
Безопасность
Проблемы безопасности возникают всякий раз. когда в сеть добавляется
новый компьютер. Поскольку' машина, подключенная средствами РРР,
является полноправным членом сети, с ней нужно обращаться должным
образом: следить, чтобы не было учетных записей без паролей или с
ненадежными паролями, чтобы были инсталлированы вес средства защиты
и т.д.
В главе 21 содержится более подробная информация о безопасности.
316
Чость II Робото в сетях
Терминальные серверы
Когда организация предоставляет РРР-каналы домашним пользователям,
может оказаться, что число запросов превышает число последовательных
портов. Существует множество терминальных серверов, работающих по
протоколу РРР, а в самых новых из них даже есть встроенные модемы. Наш
фаворит — Lucent Ponmaster 3. Пользуется популярностью также серия Cisco
Access Server AS5xOO. Эти системы позволяют легко управлять последователь-
ными портами и поставляются с предустановленным программным обеспе-
чением РРР. В них можно организовать пул модемов, обслуживающих
удаленных РРР-пользователей.
Диалоговые сценарии
Во многих реализациях РРР применяется диалоговый сценарий, предна-
значенный для подключения к модему, регистрации на удаленной машине и
запуска PPP-сервера. Идея такого сценария первоначально появилась в
протоколе UUCP. Сам сценарий состоит из набора посылаемых строк и
строк, которые предполагается получить обратно. Имеется простенькая
условная конструкция, позволяющая выражать правила вида "ожидать строки
'Login', но если она не будет получена — послать символ возврата каретки
и подождать еще’*.
Как правило, имеются готовые сценарии, которые можно адаптировать
к конкретной конфигурации. В сценарии нужно установить такие параметры,
как номер телефона, по которому делается звонок, и команда, запускаемая
после успешного входа в систему. В большинстве сценариев содержится
пароль в незашифрованном виде, поэтому следует соответствующим образом
установить права доступа к ним.
13 9. Вопросы безоп< сности
Теме безопасности посвящена отдельная глава (21), но ряд вопросов,
касающихся IP-сетей, заслуживает отдельного упоминания. В этом параграфе
мы рассмотрим те ситуации при работе в сети, в которых традиционно
возникают проблемы безопасности, и опишем пути решения этих проблем.
Перенаправление IP-покетов
Если в UNIX-системе разрешено перенаправление IP-пакетов, компьютер
может выступать в роли маршрутизатора. Активизировать эту функцию
рекомендуется только тогда, когда в системе есть несколько сетевых
интерфейсов и она действительно играет роль уполномоченного сетевого
маршрутизатора. Посредством механизма перенаправления можно сделать так,
что внешние пакеты будут казаться поступившими от локального компьютера.
Эта уловка позволяет пакетам обходить сетевые сканеры и фильтры пакетов.
Переадресующие ICMP-директивы
Посредством переадресуюших ICMP-пакетов можно злонамеренно менять
направление трафика и редактировать таблицы маршрутизации. Большинство
операционных систем по умолчанию принимает эти пакеты и следует
заключенным в них директивам. Но, согласитесь, вряд ли можно назвать
приемлемой ситуацию, когда на несколько часов весь трафик организации
Ггово 13. Сети TCP/IP
317
перенаправляется конкуренту. особенно если к это время осуществляется
резервное копирование. Мы рекомендуем так конфигурировать маршрутиза-
торы (или осуществляющие их функции системы), чтобы переадресуют! ie
1СМР-директивы игнорировались н фиксировались в журнальном файле.
Напровленная маршрутизация
Механизм направленной маршрутизации в протоколе IP позволяет явно
указать последовательность шлюзов, через которые должен пройти пакет на
пути к получателю. При этом отключается алгоритм поиска следующего
перехода, выполняемый на каждом шлюзе для определения того, к^да нужно
послать пакет.
Направленная маршрутизация была частью исходной спецификашгп
протокола IP и служила для целей тестирования. Но она создает проблему
с точки зрения обеспечения безопасности, ведь пакеты часто фильтруются в
зависимости от того, откуда они прибыли. Злоумышленник может так
подобрать маршрут, что пакет будет казаться прибывшим из внутренней сети,
а не из Internet, поэтому брандмауэр его пропустит. Мы рекомендуем не
принимать и не перенаправлять направленные подобным образом пакеты.
Широковещательные ping-пакеты и другие виды
исправленных широковещательных сообщений
Пакеты, направленные посредством команды ping, несут в себе широко-
вещательный адрес сети (а не конкретного узла) и доставляются всем узлам
сети. Такие пакеты применяются в атаках типа “отказ в обслуживании”,
например в так называемых атаках “smurf” (по имени программы, в которой
они впервые были применены) Большинство узлов располагает средствами
запрета широковещательных ping-запросов, т.е. их можно сконфигурировать
на запрет приема и перенаправления таких пакетов. Маршрутизатор также
способен фильтровать широковещательные пакеты, поступающие из Internet,
чтобы они не попадали в локальную сеть. Лучше всего устанавливать средства
защиты как на саму машину, так и на брандмауэр, если это возможно.
Широковещательные ping-пакеты одновременно являются ’"направленны-
ми” в том смысле, что они посылаются по широковещательном)' адресу
конкретной удаленной сети. Стандартные подходы к обработке таких пакетов
постепенно меняются. Например, в операционной системе Cisco IOS версий
11л по умолчанию осуществлялась переадресация направленных широкове-
щательных пакетов, но в версиях 12.0 и выше этого уже нет. Обычно можно
настроить стек TCP/IP так. чтобы широковещательные пакеты, приходящие
из других сетей, игнорировались, но, поскольку это нужно сделать для
каждого сетевого интерфейса, такая задача является аесьма трудоемкой в
крупной организации.
Брандмауэры UNIX
В Red Hat и FreeBSD имеются встроенные средства фильтрации пакетов
(программные брандмауэры). Мы опишем эти средства в соответствующих
параграфах (13.14 и 13.15), хотя и не рекомендуем использовать рабочую
станцию в качестве брандмауэра. Безопасность UNIX-систем (особенно в том
виде, в каком они выпускаются нашими любимыми поставщиками) и так
невысока, а безопасность Windows NT — еше хуже. Поэтому советуем
318
Чость II Робото в сетях
приобрести аппаратный брандмауэр. Даже самые сложные программные
решения, например система Firewall-1 компании Checkpoint (работает в
Solaris), уступают в надежности аппаратным аналогам наподобие устройств
Р1Х компании Cisco, хотя имеют почти такую же пену!
Узнать подробнее о брандмауэрах можно в параграфе 21.9.
Виртуальные частные сети
Многим организациям, имеющим офисы в различных частях света,
хотелось бы, чтобы все эти офисы были соединены в одну большую частную
сеть. К сожалению, стоимость аренды трансконтинентальных и даже транс-
национальных линий связи делает это нереальным. Таким организациям
приходится использовать Internet в качестве “частного” канала, организуя
серию защищенных, зашифрованных “туннелей” в офисах. Подобные конг-
ломераты называются виртуальными частными сетями.
В некоторых частных сетях используется протокол IPSEC, который
недавно был стандартизирован организацией IETF, В других сетях применя-
ются собственные патентованные решения, как правило, несовместимые друг
с другом. Мы рекомендуем обратить внимание на такие продукты, как
маршрутизатор 3660 компании Cisco и брандмауэр Firebox фирмы Watch-
Guard; оба они поддерживают туннелирование и шифрование. Устройство
Firebox использует протокол РРР для управления последовательным портом
Системный администратор может установить соединение с этим устройством,
чтобы сконфигурировать его или получить доступ в виртуальную частную
сеть для тестирования.
IPSEC: безопасный протокол IP
IPSEC (IP Secure — безопасный протокол IP) — это стандартизированная
организацией IETF система аутентификации и шифрования соединений. Ее
внедрению мешают федеральные законы США, запрещающие экспорт
стойких (с большой длиной ключа) систем шифрования. Поэтом)' ряд
неамериканских компаний выпустил собственные реализации протокола.
К сожалению, ни в одной из реализаций не предусмотрены средства
распространения ключей шифрования, что является важнейшей предпосыл-
кой для широкого внедрения и использования протокола IPSEC. В документе
RFC2409 (рассматриваемом комитетами по стандартизации) определен про-
токол IKE (Internet Key Exchange — протокол обмена ключами в сети
Internet), представляющий собой гибридную систему обмена ключами шиф-
рования.
В настоящий момент в протоколе IPSEC шифруется заголовок транс-
портного уровня, содержащий номера портов отправителя и получателя.
К сожалению, данная методика напрямую конфликтует с принципами работы
большинства брандмауэров. В IETF рассматривается предложение об ее
отмене.
В табл. 13.12 приведены сведения, касающиеся реализации протокола
IPSEC в наших тестовых системах.
Нетрудно догадаться, что протокол IPSEC снижает производительность
всего стека сетевых протоколов,
Чтобы установить соединение по протоколу IPSEC между двумя конеч-
ными узлами, нужно создать две базы данных: SAD (Security Association
Database — база данных о связях в системе безопасности) и SPD (Security
Гпово 13. Сети TCP/IP
31
Policy Database — база данных о политике безопасности). Добавлять в них
записи можно с помощью команды setkey, в которой имеются подкоманды
add и spdadd. Дополнительную информацию вы сможете найти на Web-узле
www.kame.neL
Тоблицо 13.12. Реолизоции протоколе IPSEC в розничных опероционных систег.-.ох
Системе Поддержка Комментарии_____________________
Solaris	да	В версии S и выше
HP-UX	да	В состав HP-UX 11.00 входит система Praesidiiini lPSec/9000
Red Hat	неполная	Вскоре появится бесплатная система FrecS/WAN1
FreeBSD	да	В версии 4.0 и выше имеется реализация протокола IPSEC проекта КАМЕ
В SuSe Linux она имеется с 1999 г.
13.10.	Добавление компьютеров к сети
Процесс добавления нового компьютера в существующую сеть состоит
всего из нескольких этапов. Проблема заключается в том, что в некоторых
системах файлы, которые требуется модифицировать, глубоко спрятаны,
поэтому задача становится нетривиальной. В других системах имеется
сценарий инсталляции, отображающий приглашение на ввод соответствующих
сетевых параметров. Работать со сценарием удобно до тех лор, пока не
потребуется отменить какие-нибудь установки
Основные этапы таковы:
•	назначение компьютеру IP-адреса и сетевого имени;
•	настройка компьютера на конфигурирование своих сетевых интерфейсов
во время начальной загрузки;
•	задание стандартного маршрута и. возможно, других параметров маршру-
тизации;
•	настройка DNS-сервера, чтобы к компьютеру можно было получать
доступ через Internet.
Сначала мы опишем всю процедуру в общем виде, а затем рассмотрим
особенности добавления компьютеров к каждой из наших тестовых систем
Естественно, к приведенной последовательности можно добавить этап
отладки После любого изменения, которое способно повлиять на процесс
начальной загрузки, необходимо обязательно перезагрузиться и проверить
правильность функционирования системы, даже если речь идет о крупном
сервере. Ведь когда через полгода произойдет внезапный сбой питания к
система откажется загружаться, будет очень трудно вспомнить, какие
изменения оказались источником проблем.
Стоит упомянуть такой факт- некоторые системы способны самостоя-
тельно определить, подключены они к сети или нет. Процедура начальной
загрузки в том и другом случаях может значительно различаться; машина,
прекрасно работавшая в автономном режиме, может необъяснимо зависнут!
во время начальной загрузки после подключения к ней сетевого кабеля, даже
если никаких изменений в конфигурации сделано нс было.
Процесс проектирования и построения физической сети описан ь
главе 15. Когда читатель имеет дело с уже сформированной сетью и в общих
320
Чость II. Роботе в сетях
чертах знает, как она построена, то, наверное, нет смысла еше что-то читать
о физических аспектах организации сетей, если только не планируется
расширение действующей сети.
Ниже мы опишем процесс конфигурирования сети Ethernet; для других
топологий процедура будет схожей.
Присваивание сетевых имен и IP-адресов
В распоряжении администраторов имеется множество методик, по
которым определяется соответствие между именами компьютеров и IP-адре-
сами в локальной сети: файл hosts, СУБД NIS и NIS+, система DNS или
комбинация каких-либо из этих средств. Если используется несколько систем,
необходимо продумать их совместную работу. Конечная система должна
учитывать возможность наращивания сети, уметь работать в гетерогенной
среде и позволять компьютеру загружаться даже в тех случаях, когда не все
сервисы доступны.
Использование файла /etc/hosts — старейший и простейший способ
преобразования имен в IP-адреса. Каждая строка файла начинается с
IP-адреса и содержит различные символьные имена, под которыми известен
данный адрес. Ниже показан пример содержимого файла /etc/hosts для узла
lollipop:
127.0.0.1
192.108.21.48
192.108.21.254
192.108.21.1
192.225.33.5
localhost
lollipop.xor.com lollipop loghost
chimchim-gw.xor.com ohimchim-gw
ns.xor.com ns
licenses.xor.com license-server
Чаше всего в первой записи файла определяется узел localhost. По слухам,
в некоторых системах это является обязательным требованием (во FreeBSD,
например).
Поскольку файл /etc/hosts содержит лишь локальные адреса привязки,
большинство современных систем использует его для хранения адресов,
требующихся при начальной загрузке. Остальные локальные и глобальные
адреса проверяются в базе данных DNS. Иногда в файле /etc/hosts хранятся
записи, о которых не следует знать другим компьютерам и которых нет в
базе данных DNS.
Файл /etc/hosts важен для начальной загрузки, так как сервер DNS еше
не доступен. Он должен содержать адреса самого компьютера и адрес
обратной связи. Кроме того, желательно наличие стандартного шлюза и адреса
сервера имен. Во многих организациях в этот файл помещаются адреса всех
важных узлов, серверов и шлюзов, иногда — адреса всех локальных узлов и
внешнего резервного сервера имен.
Если файл /etc/hosts содержит адреса всех локальных узлов, он должен
быть реплицирован на каждую машину, где требуется работать с символиче-
скими адресами компьютеров. Существуют различные методики хранения
единой версии файла на центральном узле и его распространения на другие
компьютеры организации (или совместного использования различными
машинами); подробнее об этом говорится в главе 18. Но лучше все же
упраалять адресами посредством DNS. В главе 16 описана система DNS и
пакет BIND — реализация DNS в UNIX.
Команда hostname назначает компьютеру сетевое имя. Она обычно
запускается во время начальной загрузки из какого-нибудь стартового
Глово 13. Сети TCP/IP
321
сценария, который запрашивает назначаемое имя из конфигурационного
файла. Естественно, все поставщики систем называют этот файл по-разному
(см. параграф 13 II). Большинство современных систем назначают компью-
теру полностью определенное доменное имя (т.е. оно включает как имя узла,
так и имя домена DNS. например anchor.cs.colora.do.edu).
В небольшой организации вполне можно выделять IP-адреса и сетевые
имена вручную. Если же в организации имеется много сетей и разнородных
административных групп, лучше придерживаться принципа централизации.
Наша университетская система addhost представляет собой набор распреде-
ленных средств, которые решают некоторые проблемы управления сетевыми
компьютерами. Другими решениями являются протоколы DHCP и LDAP
(Lightweight Directory Access Protocol — упрошенный протокол доступа к
каталогам). Система addhost довольно стара и "корява”, ио она все еше
применяется в нескольких организациях. Если не найдете ничего лучшего,
обратитесь по адресу ftp.xor.com.
Команда ifconfig: конфигурирование сетевых интерфейсов
Команда ifconfig используется для подключения и отключения сетевого
интерфейса, задания его IP-адреса и маски подсети, а также других опций
и параметров. Она обычно выполняется во время начальной загрузки
(аргументы командной строки берутся из конфигурационного файла), но
может применяться и для внесения изменений в работающую систему. Будьте
осторожны при модификации удаленной системы, так как не всегда есть
возможность оперативно исправить ошибки.
В большинстве случаев команда ifconfig имеет следующий формат:
ifconfig интерфейс адрес опции ... up
Например:
# ifconfig *пО 126.136.240.1 netmask 255.255.255.0 up
Параметр интерфейс обозначает аппаратный интерфейс, к которому
применяется команда. Как правило, это двух-трехсимвольное имя устройства,
за которым следует число. Примеры распространенных имен: ieO, 1еО, lei,
InO, enO, weO, qeO, hmeO, ethO и lanO; loO — это имя интерфейса
обратной связи. Имя интерфейса образовывается из имени драйвера устрой-
ства, используемого для управления им; обычно оно соответствует комплекту
микросхем, который установлен в устройстве (Intel Ethernet. Lance Ethernet
и т.л.).
Команда ifconfig интерфейс выводит текущие установки для указанного
интерфейса. Во многих системах опция -а понимается как “все интерфейсы",
поэтому с помошъю команды ifconfig -а можно узнать, какие интерфейсы
присутствуют в системе. Если эта команда не поддерживается, попробуйте
команду nets tat -i.
В Solaris сетевые интерфейсы подключаются с помощью команды ifconfig
интерфейс plumb: только после этого они становятся конфигурируемыми и
видимыми для команды netstat -i.
Параметр адрес задает IP-адрес интерфейса. Как правило, он дается в
традиционной для Internet точечной нотации, но во многих системах можно
указывать имя машины. Мы рекомендуем пользоваться числовой записью;
если команде ifconfig будет задано имя машины (или результат работы
команды hostname) и в процессе преобразования имени возникнет ошибка.
Я'
Чость II. Робото в сетях
то данный компьютер не загрузится или загрузится в состояние, при котором
доступ к нему по сети будет невозможен. Администратору придется идти
самому и устранять проблему на месте. DNS-запросы в подобной ситуации
выполняются очень долго, поэтому возникает впечатление, будто машина
зависла.
Ключевое слово up активизирует интерфейс, а ключевое слово down
отключает его.
Команда i Геол fig поддерживает множество опции. Мы рассмотрим лишь
самые основные из них. Детали, касаюшнеся конкретной системы, как всегда,
можно узнать на страницах интерактивного руководства. Все опции имеют
символические имена. Указывая опцию, вы устанавливаете ее. Некоторые
опции требуют наличия аргументов, которые должны размещаться сразу после
имени опции. В ряде версий команды ilconfig должен был указываться
параметр, задающий семейство адресов. Сегодня этот параметр не обязателен,
а по умолчанию используется семейство inet.
Опция netmask задает маску подсети для данного интерфейса. Она
обязательна, если подсеть формируется не на основании класса адреса (А. В
или С). Маску можно указывать в точечной нотации либо в виде четырех-
байтового шестнадцатеричного числа, начинающегося с префикса Ох.
Опция broadcast задает широковещательный IP-адрес интерфейса в
шестнадцатеричной или точечной записи. Правильный широковещательный
адрес — тот, в котором все биты машинной части равны 1. В большинстве
систем по умолчанию используется именно это значение. Ойо определяется
на основании сетевой маски и 1Р-адреса.
В UNIX в качестве широковещательного адреса можно использовать
любой IP-адрес, существующий в сети, к которой подключен компьютер.
В некоторых организациях широковещательный адрес специально выбран
нестандартным, чтобы избежать некоторых сетевых атак, основанных на
команде ping. По ряду причин мы не рекомендуем такой подход.
Во-первых, для этого требуется сбросить широковещательные адреса на
каждом компьютере локальной сети, что весьма накладно в крупной
организации. Во-вторых, необходимо убедиться, что переконфигурации
подверглись все компьютеры, иначе возникнет лавина широковещательных
запросов, при которой пакеты будут переходить от машины к машине до тех
пор, пока не истечет время их жизни (параметр TTL станет равным нулю).
Широковещательный "шторм” происходит по гой причине, что для
транспортировки пакетов применяется один и тот же широковещательный
адрес канального уровня независимо от того, какой задан широковещатель-
ный IP-адрес. Предположим, например, что для компьютера X широковеща-
тельный адрес — А1. а для компьютера Y — А2. Если X посылает пакет по
адресу А1. то Y примет этот пакет (его целевой адрес канального уровня
является широковещательным), обнаружит, что он не предназначен данному
компьютеру и не является широковещательным (ведь для Y таковым служит
адрес А2), и вернет его обратно в сеть. Если таких машин, как Y. две, пакет
будет циркулировать до тех пор, пока время его жизни не истечет.
Широковещательный '‘шторм*’ приводит к серьезному снижению производи-
тельности крупных коммутируемых сетей.
Лучший способ избежать проблем с широковещательными запросами —
запретить пограничнокзу маршрутизатору перенаправлять их, а отдельным
узлам — отвечать на них. Далее будет рассказано о том, как реализовать
подобные ограничения в конкретной системе.
Глово 13 Сети TCP/IP
323
В показанном выше примере широковещательный адрес —
128.138.240.255, так как длина сетевой части адреса равна 24. что следует из
значения сетевой маски (255.255.255.0).
При выполнении команды ifconfig епО будет получен такой результат:
enO: flags=63<UP, BROADCAST, NOTRAILERS,RUNNING> inet 128.138.240,1
netmask fEffffOC broadcast 128.138.240.255
Рассмотрим несколько конкретных примеров.
# ifconfig loO 127.0.0.1 up
Эта команда конфигурирует интерфейс обратной связи, который, как
правило, ие требует никаких опций. Нельзя менять стандартную системную
конфигурацию данного интерфейса. Подразумеваемая маска 255.0.0.0 является
правильной и не должна переопределяться вручную.
♦ ifconfig eno 128.138.240.151 netmask 255.255.255.192
broadcast 128.138.243.191 up
Это типичный пример для платы Ethernet. IP-адрес и широковещательный
адрес устанавливаются равными 128.138.243.15! и 128.138.243.191 соответст-
венно. Сеть относится к классу В (что видно из первого байта адреса), при
этом в ней выделяется подсеть /26. Значение 192 в сетевой маске — это
11000000 в двоичном виде, т.е. от трех октетов 255 отнимаются еше два бита.
Значение 191 в широковещательном адресе — это 10111111 в двоичном виде,
т.е. все шесть битов машинной части равны 1, а сам интерфейс принадлежит
третьей (10) из четырех подсетей.
Теперь, когда мы узнали, как конфигурировать сетевой интерфейс
вручную, осталось познакомиться с тем, как задавать параметры команды
ifconfig при начальной загрузке системы Кроме того, требуется убедиться,
что новые значения введены правильно. Для этого необходимо отредактиро-
вать один или несколько конфигурационных файлов. Данная процедура
описывается далее в параграфах, посвященных настройке конкретных систем.
Команда route: конфигурирование статических маршрутов
Команда route определяет статические маршруты — явно заданные
элементы таблицы маршрутизации, которые обычно не меняются даже в тех
случаях, когда запускается демон маршрутизации*. При добавлении нового
компьютера в локальную сеть достаточно указать стандартный маршрут. Не
забудьте также прочитать страницы интерактивного руководства, посвящен-
ные команде route: се синтаксис, флаги и аргументы существенно различаются
в разных системах.
В данной книге вопросы маршрутизации рассматриваются в двух главах:
настоящей и следующей. И хотя в этой главе приведена информация по
основам маршрутизации н команде route, будет полезно прочитать также
несколько первых параграфов главы 14.
Маршрутизация происходит на сетевом уровне. Когда приходит пакет,
предназначенный для другого узла, его целевой IP-адрес ищется в таблице
маршрутизации ядра. При совпадении (хотя бы частичном) с каким-нибудь
маршрутом в таблице пакет направляется по IP-адресу следующего шлюза,
связанного с данным маршрутом.
Тем нс менее некоторые версии демона routed перезаписывают статические маршруты.
324
Чость II. Робото в сетях
Есть два особых случая. Во-первых, пакет может быть предназначен для
компьютера, включенного в ту же сеть, что и машина-отправитель. В этом
случае адрес следующего шлюза указывает на один из интерфейсов локального
компьютера, и пакет посылается прямо в пункт назначения. Маршруты этого
типа добавляются командой ifconfig при конфигурировании интерфейса.
Во-вторых, может не оказаться маршрута, совпадающего с адресом пункта
назначения. В этом случае применяется маршрут по умолчанию, если таковой
имеется, иначе отправителю выдается ICMP-сообщение “network unreachable"
(сеть недоступна). Многие локальные сети имеют единственный выход ' и
мир”, иа него-то и ссылается стандартный маршрут. В магистральной сети
Internet нет стандартных маршрутов — это конец пути.
Каждая команда route добавляет или удаляет один маршрут. Вот ее
формат:
route [-f] операция [тип] адресат шлвз сче'гчих_переходов
Параметр операция принимает одно из двух значений: add (добавить
маршрут) или delete (удалить маршрут). В некоторых версиях команды
поддерживаются и другие виды операций, например get, change, flush и monitor
Параметр адресат содержит адрес машины, адрес сети или ключевое слово
default. В ряде систем стандартный маршрут представляется сетевым адресом
О.О.О.О.
Параметр шлюз задает компьютер, котороьгу должны адресоваться пакеты
Необходимо, чтобы этот компьютер находился к той же сети, что и машина,
на которой формируется данный маршрут. Пересылка может выполняться
только по одному переходу за раз. Иногда вместо шлюза (или наряду с ним)
может указываться интерфейс.
Параметр счетчик_переходов определяет предельное число переходов на
пути к адресату. В одних операционных системах этот параметр обязателен,
в других он допустим, но игнорируется, в третьих — считается устаревшим
и не должен использоваться. Но даже если счетчик переходов необходим, не
требуется указывать точное его значение; часто его просто устанавливают
равным I.
Во FreeBSD счетчик переходов не нужен. Если же по ошибке указать
его, то он будет проинтерпретирован как сетевая маска. Согласитесь, от
маски 1 мало пользы!
Необязательный параметр тип задает тип адреса: сетевой или машинный.
Соответственно, он может принимать значение net или host. Если тип опушен,
команда route проверяет машинную часть целевого адреса на предмет
равенства ее нулю. Если машинная часть равна нулю или адрес найден в
файле /etc/networks, то маршрут считается обычным сетевым маршрутом
Поскольку команда route не знает, разбита ли сеть с указанным адресом
на подсети, тип адреса приходится задавать достаточно часто. Например,
адрес 128.138.243.0 относится к разделенной на подсети сети класса В,
имеющейся в нашей организации, но для команды route он выглядит как
адрес класса В 128.138 с машинной частью 240.0. Чтобы ие вводить команду
route в заблуждение, следует задать опцию net. Желательно указывать тип
адреса для всех маршрутов, где могут встретиться подсети.
Файл /etc/networks используется для связывания доменных имен с сетевыми адресами
подобно тому, как файл /etc/hosts связывает имена компьютеров с их IP-адресами. Многие
команды, требующие указания сетевых адресов, понимают также доменные имена, если
они указаны в файле /etc/networks (или в базе данных DNS).
Глово 13 Сети TCP/IP
325
$
Команда route delete адрес удаляет указанную запись из таблицы
маршрутизации. Команда route -Г удаляет из таблицы данные обо всех
маршрутах. Если объединить ее с командой add, таблица сначала очищается,
а затем вносится требуемое изменение.
В последних выпусках BSD-систем вместо команды route -f используется
команда route flush, а вместо опций net и host — опции -net и -host.
В Red Hat также используются опции -net и -host, но команда route flush
не поддерживается. Похоже, что в Red Hat вообще нельзя удалить вес записи
из таблицы маршрутизации одной командой.
Существующие маршруты можно проанализировать с помощью команды
netstat -пг. Подробную информацию об этой команде вы найдете в парагра-
фе 20.4.
Стандартные маршруты
Благодаря наличию стандартного маршрута все пакеты, целевые адреса
которых не найдены в таблице маршрутизации ядра, будут посланы в
указанный шлюз. Для установки стандартного маршрута достаточно добавить
в один из стартовых сценариев такую строку:
route add default TP-адрес
Чтобы не задавать жестко IP-адрес в стартовых сценариях, большинство
поставщиков заставили свои системы получать этот адрес из конфигурацион-
ного файла. Конкретная процедура зависит от системы (табл. 13.13).
Таблица 13.13. Зодоние стондортного маршруте в розничных операционных
системох
Система	Редактируемый фойл	Изменяемая переменная
Solaris	/etc/ defaultrouter	-
HP-UX	/etc/rc.config.d/netconf	ROUTE_GATEWAY[0]
Red Hat	/etc/sysconflg/nelwork	GATEWAY, GATEWAYDEV
FreeBSD	/etc/rc.conf	defauitrouter
Прочерк в последнем столбце означает, что в указанный файл достаточно
поместить IP-адрес или сетевое имя стандартного шлюза. Если задается
сетевое имя. оио должно присутствовать в файле /etc/hosts.
Конфигурирование DNS
Чтобы сконфигурировать машину в качестве DNS-клиента, достаточно
отредактировать один или два файла: /etc/resolv.conf (во всех система?) и
файл "переключения сервисов” (в некоторых системах).
Файл /etc/resolv.conf содержит список DNS-доменов, просматриваемых
при анализе неполных имен (например, "anchor4 вместо anchor.cs.colo-
rado.edu). и IP-адресов серверов имен, в которых осуществляется поиск имен.
Ниже показан пример этого файла; подробнее о нем рассказывается в
параграфе 16.8.
search cs.colorade.edu colorado.edu
nameserver 128-13В.242.1
nameserver 128.138.243.151
nameserver 192.108.21.1
326
Часть II Роботе в сетях
Первым должен быть указан ближайший стабильный сервер имен, так
как он опрашивается в первую очередь. Всего можно задать три записи
nameserver. Желательно указывать более одного сервера. Период тайм-аута
достаточно большой, поэтому, если первый сервер не отвечает, пользователи
это заметят.
Иногда вместо записи search присутствует запись domain. Это говорит
о том, что в системе имеется либо старая версия файла resolv.conl, либо
старый модуль преобразования имен. Директивы domain н search не
эквивалентны, вторая является более предпочтительной.
В некоторых системах база данных DNS по умолчанию не используется,
даже если есть правильно сконфигурированный файл resolv.conf В таких
системах имеется файл “переключения сервисов”, определяющий, какой
механизм должен применяться для преобразования сетевых имен в iP-anpeca.
О приоритетах информационных служб рассказывается в параграфе 18.3, но
здесь мы также рассмотрим эту тему, поскольку она важна с точки зрения
разрешения проблем при конфигурировании нового компьютера.
Файл “'переключения сервисов” позволяет задать порядок, в котором
должны просматриваться базы данных DNS. NIS (или NIIS+} и файл
/etc/hosts. Некоторые информационные источники можно полностью исклю-
чить из рассмотрения Порядок просмотра оказывает влияние на начальную
загрузку системы. Если первым источником является DNS. то для корректной
загрузки в локальной сети должен присутствовать сервер имен, а его сетевое
имя и IP-адрес должны быть указаны в файле /etc/liosts.
В табл. 13.14 приведено местоположение соответствующих конфигура-
ционных файлов в каждой из тестовых систем и строки, требуемые, для
организации поиска сетевых имен.
Таблица 13.14. Файлы 'переключения сервисов* в различных операционных
системах
Системе	Фойл	Строка поиска сетевых имен
Solaris	/ etc/nsswitcb.conf	nis (NOTFOUND-return] files
HP-UX	/etc/nsswitch.conf	dns [NOTFOUND=return] nis [NoTFOUND-return] fkles
Red Hal	/etc/nsswitch-conf1 /etc/host.conf	do files nlsplus dns hosts, bind
FreeBSD	/etc/bost.conf	hosts, bind
С большинством приложений компонуется библиотека libefi, где используется
система BIND и файл asswitcb-conf. К некоторым старым приложениям подключа-
ется библиотека Iibc5, и в ней используется файл host.conf.
Стандартная строка поиска в Solans определяется на основании парамет-
ров, заданных в процессе ннсталляини системы. Модифицируемая запись
называется hosts в Solaris 7: в Solaris 8 и более поздних версий добавляется
запись ipnodes. которая ссылается также на процедуру преобразования
сетевых имен в IP-адреса.
Строки для Solaris и HP-UX содержат предложение [NOTFOUND=return],
которое указывает, что нужно делать, если поиск имени не увенчался успехом.
В данном случае процедура поиска немедленно завершается. Переход к
следующему сервису осуществляется только в том случае, когда первый сервис
оказывается недоступным. Определены также три других условия — SUCCESS,
Глово 13 Сети TCP/IP
327
UNAVAIL и TRYAGAIN, а вместо команды return может быть указана
команда continue.
В Solaris и HP-UX в каталоге /etc содержатся образцы рассматриваемых
файлов; их имена — nsswitch.*. В HP-UX стандартные установки находятся
в файде nsswitch.hpdefaulis.
13.11.	Конфигурирование сети в различных системах
В старых системах конфигурирование сети выполнялось путем редакти-
рования сценария /etc/гс (или /ete/rc.loca!) и прямого изменения содержа-
щихся в них команд ifconfig и route. Современные системы настроены так,
чтобы свести к минимуму количество модификаций, вносимых в стартовые
сценарии
В новейших сценариях используются данные конфигурации из других
системных файлов либо определяются собственные файлы конфигурации.
Это, конечно, хорошая идея, но в каждой системе она реализована по-своему
Кроме того, она предполагает, что иногда аргументы команд ifconfig н route
задаются косвенным образом, в результате чего повышается вероятность
ошибок.
В обшем случае мы рекомендуем по возможности придерживаться
стандартного подхода, принятого в конкретной системе. Заманчиво, конечно,
внести парочку “улучшений”, но UNIX — “хрупкая” экосистема, уязвимая
для неожиданных побочных эффектов, особенно если оии возникают в
процессе начальной загрузки.
В главе 2 были подробно описаны процедуры начальной загрузки для
всех наших тестовых систем. В следующих четырех параграфах мы просто
подытожим те задачи, которые связаны с конфигурированием сети. Наши
системы конфигурируют интерфейс обратной связи автоматически; эту часть
процесса модифицировать не нужно. В остальном же все систеьш отличаются
друг от друга.
Поставщики UN IX-систем постоянно находятся в непонятном “творче-
ском поиске". Они все время меняют содержимое конфигурационных файлов
и переименовывают их, не задумываясь о том (или просто не обращая
внимание на то), что есть масса других разработчиков, пишущих программы,
которые зависят от формата этих файлов. В табл. 13.15 перечислены файлы,
которые нужно отредактировать для задания сетевого имени и [Р-алреса
компьютера. После изменения одного из этих файлов следует перезагрузить
систему или. по крайней мере, деактивизировать сетевой интерфейс, а потом
снова запустить его, чтобы изменения вступили в силу.
Два файла являются общими для всех операционных систем: /etc/hosts
и /etc/resolv.conf. Мы указали отдельно их в начале таблицы. Файлы
“переключения сервисов" в этой таблице не приведены (см. табл. 13.14),
В следующих четырех параграфах будут подробно описаны процедуры
сетевого конфигурирования каждой из тестовых операционных систем.
Список рассматриваемых тем таков:
•	базовое конфигурирование;
•	примеры;
•	конфигурирование DHCP-клиента;
•	динамическое переконфитурпровапие и настройка;
•	конфигурирование средств защиты и фильтрации, а также брандмауэров
и системы NAT;
328
Чость II Роботе в сетях
•	конфигурирование РРР;
•	системные особенности.
Таблица 13.15. Фойлы конфигурации сети в различных операционных системок		
Система	Файл	Назначении
Все	/etc/hosts	Связи между сетевыми именами и IP-адре- сами
	/etc/resolv.conr	DNS-домсны н серверы имен
Solaris	/etc/hostnaine.uHmep$e4c	Сетевые имена дл.я каждого интерфейса
	/etc/dhep. интерфейс	Параметры конфигурации DHCP для каждо- го интерфейса
	/etc/nodenarae	Имя узла
	/elc/defaultrouter	Стандартный маршрут
	/etc/'nel/Detmasks	Основная версия файла, содержащего сете- вые маски
	/etc/inet/hoets	Основная версия файла /etc/hosts
	/elc/ioet/ipnodes1	Расширение файла /etc/hosts в Solaris 8 и выше
HP-UX	/etc/rc.config.d/netconf	Все сетевые параметры
Red Hat	/etc/syscoofig/network	Имя компьютера, стандартный маршрут, до- мен
	network-scnpts/lfcfg-	IP-адрес, сетевая маска, широковещательный
	интерфейс1	адрес
FreeBSD	/etc/гс.сопГ	Все сетевые параметры
В Solaris 8 и более поздних версий файл /etc/inet/lpnodes заменяет файл /etc/hosts.
Он содержит как адреса IPv4, так и адреса IPv6. Файл /etc/hosts оставлен в целях
обратной совместимости.
3	Имя дано относительно каталога /etc/sysconBg.
13.12.	Сетевое конфигурирование Solaris
Операционная система Solaris поставляется с обширным набором стар-
товых сценариев. На недавней компьютерной выставке мы наткнулись на
отрывной календарь, на каждом листике которого были записаны несложные
вопросы для системных администраторов. Вопрос от 1-го января был таким:
перечислите все файлы, которые нужно отредактировать для изменения
сетевого имени и IP-адреса компьютера, работающего под управлением
Solaris, н компьютера, работающего под управлением SunOS. В ответе для
Solaris было указано 6 файлов. Это следствие модульного подхода в своем
крайнем проявлении.
Базовое конфигурирование
В Solaris часть файлов сетевой конфигурации спрятана в каталоге /etc.
а часть — в каталоге /etc/inet Многие из них дублируются благодаря
всевозможным символическим ссылкам, причем сами файлы находятся в
каталоге /etc/inet. а ссылки — в каталоге /etc.
Сетевое имя компьютера должно быть помешено в файл /etc/nodenaine.
Изменение вступит в силу после перезагрузки компьютера. В одних
Глово 13 Сети TCP/IP
329

организациях компьютерам присваиваются простые имена, в других —
полные доменные имена. Если в файле node пат с задано полное доменное
имя, могут возникнуть проблемы с базой данных NIS+.
Подробнее о NIS+ рассказывается в параграфе 18.4.
На основании имени файла /ctc/defaukdomain можно сделать вывод, что
он предназначен для задания домена DNS. На самом же деле ои содержит
доменное имя NIS или NIS+. DNS-домеи определяется в файле /etc/re-
solv.conf.
В Solans на основании файла /etc/nsswitch.conf система узнает, в каком
порядке просматривать файл /etc/hosts, базы данных NIS. NIS+ и DNS при
поиске имени компьютера. Мы рекомендуем сначала проверять файл hosts,
а затем базу данных DNS. чтобы упростить загрузку, но это противоречит
рекомендациям разработчиков самой системы. Строка в файле nsswitch.conf
может выглядеть так:
hosts:	files dns
В Solaris IP-адреса всех сетевых интерфейсов задаются в файлах
/etc/hostname.izw/лср^ейс, где интерфейс — обычное имя интерфейса (1е0.
smcD. hmeO и т.п.). В этих файлах содержится либо сетевое имя компьютера
(в старых версиях Solaris), приведенное в файле hosts, либо IP-адрес (в новых
версиях). Значение, находящееся в файле, передается в качестве параметра
адрес команде ifconfig, поэтому лучше указывать IP-адреса, несмотря на имя
самого файла. В файл могут также включаться специальные опции команды
ifconfig, но это делается редко. Если для интерфейса нет соответствующего
файла hostname, стартовые сценарии пытаются выявить его адрес с помощью
протокола DHCP или R.ARP*
В стартовых сценариях поставочного варианта Solaris используются опции
netmask+ и broadcast + команды ifconfig Знак + означает, что маска подсети
извлекается из файла /ctc/netmasks и на ее основании определяется широко-
вещательный адрес. Файл /etc/netmasks"’ содержит список сетевых адресов и
соответствующих им масок подсетей В этом файле должны быть перечислены
все сети, в которых подсети формируются не так как того требует класс
сети (А. В или С). Вот пример файла netmasks.
# База масок подсетей для факультета вычислительной техники
# Сеть	Маска		
» =____			
128.138.0.0 #	255.255.255.192	1	по умолчанию для факультета
128.138.192.64	255.255.255.192	»	drag
128.138.192.192	255.255.255.192		с sops
128.138.193.0	255.255.255.224		berg
128-138.193.32	255.255.255.224		database
128.138.198.0	255.255.255.192	S	slip
Сетевые интерфейсы Solaris должны быть предварительно подключены с помощью команды
ifconfig plumb. Возможно, администратору придется выполнять эту команду вручную при
самостоятельном конфигурировании интерфейсов.
В Solaris 7 man-страница, посвященная файлу netmasks, повреждена; в более поздних
версиях она исправлена.
330
Чость II Роботе в сетях
В первой строке задается стандартная маска /26 для адреса 128.138.0.0
класса В. Затем определяются различные вспомогательные маски. В файле
перечислены все сети, даже те, к которым применяется стандартная маска.
В системах, из которых был взят этот пример, файл netmasks ведется на
центральном узле и распространяется на все остальные машины. Ни на одном
компьютере нет интерфейсов для связи со всеми сетями.
Конфигурирование интерфейса происходит па ранних стадиях процесса
начальной загрузки, до того как стартуют сетевые информационные серверы.
Solaris повторно выполняет команду ifeonfig после запуска некоторых сервисов
(предполагается, что они могут предоставить команде новые параметры).
Дополнительную информацию можно получить в следующих стартовых
сценариях:
•	/etc/init.d/rootusr;
•	/etc/init.d/inetinit;
•	/etc/init.d/sysid.nct:
• /etc/inil.d/inetsvc
Если существует файл /elc/dcfaultroutcr, то подразумевается, что он
содержит идентификатор (имя машины или IP-адрес) стандартного шлюза,
и дальнейшее конфигурирование маршрутов не требуется. Как всегда,
предпочтительнее указывать IP-адреса; если задано имя. для него должна
существовать запись в файле /elc/hosts или на сервере DNS в локальной сети.
Если стандартный шлюз не задан, Solaris пытается запустить демон routed
для построения таблиц маршрутизации. Подсчитывается число сетевых
интерфейсов, и если их более одного или существует файл /etc/gateways, то
демон routed запускается в режиме сервера и объявляет о своем присутствии
с помощью демона обнаружения маршрутизатора. Если обнаружен всего один
интерфейс или имеется файл /etc/notrouter, демон routed запускается в
“бесшумном" режиме Во всех режимах, кроме “бесшумного", демон routed
является "вредоносным” — отключите его"
Примеры конфигураций
Ниже показано несколько примеров команд для подключения сетевого
интерфейса в Solaris и добавления маршрута к стандартному шлюзу;
i ifeonfig hmeC plumb
И ifeonfig hmeO 192.108.21.48 netmaek 255.255.255.0 up
» route add default 192.108.21.254
Следующие примеры демонстрируют, как просмотреть статус сетевого
интерфейса и содержимое таблиц маршрутизации. Команды, вызываемые
посредством утилиты sudo, запускаются от имени суперпользователя. Послед-
ний пример иллюстрирует особенность команды route в операционных
системах Solans и FreeBSD, отсутствующую в других системах; при наличии
аргумента get отображается информация о следующем переходе на пути к
заданному узлу.
% ifeonfig -а
1о0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
Демон routed не имеет средств контроля доступа и принимает все поступающие сообщения
Узел, на котором были запушена команда routed -q, принимает запросы, ио не отвечает на
них. При отсутствии опции -q узел оповещает о маршрутах. Такой узел может нарушить
работу сети, так как все остальные демоны routed будут принимать его сообщения.
Глово 13. Сети TCP/IP
331
inet 127,0.0.1 netmask ffOOOOOO
hmeO:flags-863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST? mtu 1500
mat 192.108.21.48 netmask ffffffOO broadcast 192.108,21.255
% sudo ifconfig iuncO
hmeO;flags-863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST? mtu 1500
inet 192.108.21.48 netmask ffffffOO broadcast 192.108.21.255
ether 8:0:20;79:4f:49
Обратите внимание: когда команда ifconfig запускается от имени супер-
пользователя, она отображает аппаратный адрес интерфейса, а когда ее
выполняет рядовой пользователь,
% netstat -nr
Destination Gateway
этого не происходит.
Flags Ref Use Interface
192.108.21.0 192.108.21.48	U	3	244	hmeO
224.0.0.0	192.108.21.48	U	3	0	hmeO
default	192.108.21.254	UG	0	459
127.0.0.1	127.0.0.0	UH	0	296	loD
% sudo route get anchor.cs.colerado.edu
route to: anchor.cs.Colorado.EDU
destination: default
mask: default
gateway: xcr-gw2
interface: hmeO
flags: CUP,GATEWAY,DONE,STATIC?
reevpipe sendpipe ssthr rtt.msec rtrvar
0	CO	0	0
hopct mtu expire
0	1500	0
Конфигурирование DHCP
В Solaris имеется собственный DHCP-клиент, и эта операционная система
заслуживает отдельной награды за самую простую и понятную процедуру
конфигурирования данного клиента:
Ifconfig интерфейс dhep
Представьте себе, эта команда работает! Она вызывает программу
dhepagent для получения параметров интерфейса от сервера DHCP и
последующего конфигурирования интерфейса в соответствии с этими пара-
метрах™. Команде Ifconfig можно передавать различные опции, делающие
интерфейс первичным, устанавливающие тайм-ауты, увеличивающие срок
аренды параметров или запрашивающие отображение статуса интерфейса.
Чтобы отменить конфигурацию DHCP-клиента, выполните такую команду':
ifconfig интерфейс drop
Все это очень удобно, но, как правило, требуется автоматически
опрашивать сервер DHCP на этапе начальной загрузки. Данная процедура
должна выполняться отдельно для каждого интерфейса. С этой целью
необходимо создать файл /е1с/ЯЬср.интерфейс. Он может содержать дополни-
тельные параметры, передаваемые команде ifconfig.
Файл /etc/hostname.uwnepi/iebc по-прежнему должен существовать, чтобы
интерфейс можно было активизировать. Но его можно оставить пустым, если
применяется протокол DHCP. Когда файл hostname.интерфейс не является
332
Чость II. Робото в сетях
пустым, стартовые сценарии сначала статически конфигурируют интерфейс
на основании содержимого этого файла, а затем осуществляют его перекон-
фигурацию средствами DHCP.
С помощью команды dhcpinfo можно узнать, какие параметры получены
от сервера DHCP. Загляните также в файл /etc/dhcp/««znep()tebic.dhc. который
содержит текущие настройки указанного интерфейса.
Программа dhcpagent управляет интерфейсом по протоколу DHCP.
Помимо прочего оиа договаривается с сервером о продлении срока аренды
и отменяет арендованные параметры, если они больше не нужны. Если
интерфейс, получивший свои параметры от DHCP-сервера, впоследствии
переконфигурируется вручную, программа перестает управлять им.
Программа dhcpagent собирает параметры, полученные от DHCP-сервера
(стандартный маршрут, домен, адреса серверов имен и т.д.), но не управляет
большинством из них напрямую. Вместо этого оиа записывает их в файлы
соответствующих интерфейсов в каталоге /etc/dhcp Далее эти параметры
читаются сценариями /etc/rc.*. передаются в качестве аргументов команде
route, помешаются в файл resolv.conf и т.д. в зависимости от конкретного
параметра
Программа dhcpagent регистрирует ошибки в системе Syslog (средство
•‘daemon", уровень “err"); она также записывает информацию об ошибках в
устройство /dev/console. Ошибки более низких уровней (предупреждающие
сообщения, информационные сообщения и т.д.) по умолчанию не учитыва-
ются, если явно не включить их в командной строке посредством флага - IN.
Когда Л’ равно 1, регистрируются предупреждающие сообщения; при более
высоких значениях регистрируются также сообщения самых нижних уровней.
Если программе dhcpagent посылается сигнал USR1 (с помощью команды
kill), оиа выводит информацию о состоянии аренды
Найти конфигурационную информацию по конкретному интерфейсу
можно в файлах каталога /etc/dhcp. Но сам факт присутствия файла
интерфейс.АХк. еше не означает, что программа dhcpagent управляет данным
интерфейсом: срок аренды мог истечь.
Динамическое переконфигурирование и настройка
Команда ndd в Solaris позволяет переконфигурировать драйвер устройства
в выполняющейся системе. Возможно, ‘‘переконфигурировать’' — слишком
сильное слово. Просто каждый драйвер предоставляет доступ к некоторым
своим параметрам, которые можно просмотреть и в определенных случаях —
изменить. Именно для просмотра конкретных параметров мы чаще всего
применяем команду ndd. Например, с ее помощью можно узнать, с какой
скоростью работает Ethernet-плата: 10 Мбит/с или 100 Мбит/с.
Синтаксис этой команды в Solaris почти такой же. как и в HP-UX, но
документация к ней гораздо хуже. Базовый синтаксис, упоминаемый на
man-странице, следующий:
ndd [-set] устройство ? 1 переменная (значение]
При наличии аргумента ? (его нужно защищать от интерпретации: \?)
команда ndd возвращает список переменных, распознаваемых драйвером
указанного устройства. Если задать имя переменной, будет получено ее
значение, а если указать флаг -set и значение, оно будет присвоено заданной
переменной.
Главе 13 Сети TCP/IP
333
К сожалению, в документации не упоминаются возможные имена
устройств; ничего не говорится о том, что для доступа к одним устройствам
(например, ip и hmc) требуются прана суперпользователя, а к другим (tcp и
udp) — нет. В случае отсутствия соответствующих пран доступа команда «dd
выдает загадочное сообщение об ошибке следующего вида:
"couldn't push module 'ip', No such device or address"
В табл. 13.16 перечислены устройства, которые нам удалось обнаружить
при работе с командой ndd.
Тоблицо 13.16. Устройство, с которыми рсботоет комондо ndd в Solons
Устройство	Описание	Имена переменных
/de»/tcp	Переменные протокола TCP	tcp-
'dev udp	Переменные протокола LI DP	udp •
/dev/ф	Переменные протокола IP	ip*
/dev/iemp	Переменные протокола ICMP	iemp*
/dev/ruwip	То же, что /dev/iemp	icmp_’
/dev/агр	Переменные протокола ARP	arp_‘
/dev/hme	Переменные Ethernet	нет конкретной схемы
Скорость работы большинства современных Ethernci-плат — либо
10 Мбит/с, либо 100 Мбнт/с. В наших сетях по мере перехода на новые
технологии нам часто приходится выяснять, с какой скоростью в настоящий
момент работает сетевая плата. Вот удобный сценарий, написанный Тоддом
Уилльямзом (Todd Williams) и предназначенный для определения параметров
Eihemet-платы посредством команды ndd-
#!/bin/sh
[’ndd /dev/hme link_status'-ea 1] && STATUS-UP || STATUS-DOWN
['ndd /dev/hme link_speed'-eq 1) SPEED=100 |i SPEED=10
['ndd /dev/hme link_mode’-eq LI && MODE-FULL II MODE=HALF
echo "ethernet is SfSTATUS}, running S'SPEEDl Mbps S'MODE) duplex"
Результаты работы сценария выглядят примерно так:
Ethernet is UP, running 10 Mbps HALP duplex
Если перевести это иа язык переменных, получим следующее:
•	link_status = 1, если интерфейс активен, 0 — если неактивен;
•	link_speed = 1, если скорость равна 100, 0 — если она равна 10;
•	link mode = I. если интерфейс полнодуплексный. 0 — полудуплексный
Есть другой набор переменных, которые задают скорость работы и
дуплексный режим при наличии нескольких интерфейсов. Следующий
сценарий отключает процедуру автоматического согласования обоих интер-
фейсов, переводит первый интерфейс в полудуплексный режим со скоростью
10 Мбнт/с. а второй — в полнодуплексный режим со скоростью работы
100 Мбит/с:
#!/bin/sh
ndd -set /dev/hme instance	0
ndd -set /dev/hme adv autoneg cap 0
nad -set /dev/hme adv LDOfdx cap 0
334
Чость II Роботе в сетях
ndd -вес	/dev/hme	adv_100hdx_cap	0
ndd -set	/dev/hme	adv lOfdxcap	0
ndd -set	/dev/hme	adv_10hdx_cap	1
ndd -set	/dev/hme	instance	1
ndd -set	/dev/hme	adv_autoneg_cap	0
ndd -sec	/dev/hme	adv_lO0fdx cap	1
ndd -set	/dev/hme	adv_100hdx_cap	0
ndd -set	/dev/hme	adv_10fdx cap	0
nda -set	/dev/hme	adv_10hdx_cap	C
Если процедура автосогласования в имеющейся сетевой плате не работает,
можно отключить ее и задать параметры работы платы вручную, как это
сделано в данном примере.
Если имеется доступ к системе HP-UX, запустите команду ndd с флагом
-I» (вызов справки), чтобы получить доступ к интерактивному руководству,
где можно узнать имена устройств и переменных, а также назначение этих
переменных. Имена многих переменных там такие же, как н в Solaris.
Безопасность, брандмауэры, фильтрация и система NAT
В табл. 13.17 оггисаио, как в Solaris реализован ряд технологий,
касающихся безопасной работы в сети О них кратко рассказывалось в параг-
рафе 13.9. Большинство настроек можно изменить с помощью команды ndd.
Таблица 13.17. Поддержке технологий, связанных с сетевой безопасностью,
в Solaris
Технология	По умолчанию	Переменной, изменяемой командой ndd
Перенаправление IP- пакетов	отключено	ip forwardinq: 0 — отключено. 1 — включено
Переадресующие 1СМР-пакеты	принимаются	Отменить это попечение нельзя, можно лишь изменить значение TTL
Направленная маршрутизация	разрешена	ip_forward_src_routed: 0
Широковещательные ping-пакеты	разрешены	ip_respond_to_ech<3_broadcast: 0 ip forward directed broadcasts: 0
Как уже говорилось, не следует использовать UNIX-систему (или
NT-систему) в качестве брандмауэра или шлюза NAT; для этой цели лучше
купить специализированное оборудование, например систему Cisco Р1Х.
В Solans этому правилу следовать легче, поскольку в дистрибутив не входит
ПО межсетевой зашиты и 1Р-фильтрации.
Тем не менее в Solaris имеется библиотека pfmod, с помощью которой
можно создавать ST REAMS-модули для фильтрации пакетов. Компания Sun
также предлагает пакет программной организации брандмауэра для Solaris,
но его нужно покупать отдельно
Сторонние поставщики также разрабатывают программы IP-фильтрации
и системы NAT для Solaris. Наш фаворит — пакет I PFilter. Это бесплатное
решение, распространяемое на условиях открытой лицензии и работающее
на оборудовании SPARC или Intel. Пакет доступен по следующему адресу:
http://cheops.anu.edu.au/~avaJon/ip-fiIter.html
Глово 13. Сети TCP/IP
335
Детали конфигурирования программ ipf и ipnat, входящих в этот пакет,
приведены в параграфе 13.15.
Коммерческая система Firewall-1 компании Checkpoint работает в Solans
и обеспечивает функциональные возможности, аналогичные пакету IPFiker.
Правда, она достаточно дорогая и, по слухам, не очень хорошо зарекомен-
довала себя на Web-узлах, занимающихся Web-хостингом.
Конфигурирование РРР
В Solaris имеется встроенный пакет “асинхронного” протокола РРР,
поскольку он предназначен для управления соединениями по стандартным
последовательным линиям связи (например, модемами). Так как этот пакет
является неотъемлемой частью Solaris, не нужно выполнять утомительные
этапы по инсталляции соответствующего модуля ядра. Проверить наличие
пакета можно с помощью такой команды:
* pkginfo | grep ppp
Если пакет присутствует в системе, будут получены следующие резуль-
таты:
system SUNWapppr PPP/IP Async PPP daemon config files
system SUNWapppu PPP/IP Async PPP daemon, login service
system SUNWpppk PPP/IP and IPdialup Device Drivers
Если пакет еще не установлен, придется сделать это вручную. Соответ-
ствующую информацию можно получить иа man-странице, посвяшениой
команде pkgadd. В табл. 13.18 перечислены файлы, отвечающие за конфигу-
рирование протокола РРР и управление им в Solaris.
Таблица 13.18. Файлы, связанные с протоколом РРР в Solans
Файл	Назначение
/etc/Lnit.d/asppp	Сценарий начальной загрузки для коммутируемых РРР-со- единений
/usr/sbin/aspppd	Демон, управляющий РРР-соединениями
/etc/asppp.cf	Конфигурационный файл, в котором содержится список соединений
/ uer/sb in/aspppls	Регистрационный интерпретатор команд для коммутируе- мых соединений
/wir/adm/log/asppp. log	Файл регистрации сообщений РРР
/trnp/.asppp.fifo	Используется демоном iispppd для коммутируемых соедине- ний
Ha man-странице.	посвященной демону aspppd, говорится о том, что его
регистрационный файл называется /etc/log/asppp.log. Это неверно. Выполняя
команду grep над стартовыми сценариями и команду strings над двоичным
файлом демона, мы выяснили, что файл на самом деле находится в каталоге
/var/adm. а не /etc.
Мы были уверены, что протокол UUCP давно ушел в небытие, но (увы!)
PPP-пакет в Solaris пользуется старыми конфигурационными файлами UUCP
для задания PPP-серверов и управления модемами. Остается только тяжела
вздохнуть. Чтобы установить PPP-соединение с удаленным узлом, необходимо
336
Часть II Работа в сетях
сначала добавить записи о модеме и узле в файлы Systems, Dialers и Devices
в каталоге /etc/uucp. Мы описывали детали этой процедуры в предыдущем
издании книги, но решили не включать данный материал здесь. Если у вас
есть предыдущее издание, обратитесь к главе 30, а лучше всего — купите
терминальный сервер и избавьте себя ат ненужной головной боли.
После того как записи о модеме и удаленном узле добавлены в
UUCP-файлы, необходимо отредактировать файл /etc/asppp.cf. поместив в
него IP-адрес соединения и связав этот адрес с записью в файле Systems.
Ниже показан пример файла /etc/asppp.cf, в котором описано соединение
с узлом ppphub (192.225.32.1), устанавливаемое из узла mybost (192.225.32.2):
# задаем IP-адреса псевдоинтерфейса
ifeonfig ipdptpO plumb 192.225.32.2 192.225.32-1 up
f динамические параметры соединения с псевдоинтерфейсом
interface ipdptpO
peer_system_name ppphub ♦ то же, что в файле Systems
inactivity_txmeout 600 ♦ тайм-аут, если нет связи в течение 10
минут
Далее нужно вручную запустить PPP-демона с помощью такой команды:
* /stc/init.d/aappp start
Этот этап необходим, только когда осуществляется самое первое конфи-
гурирование протокола РРР. При последующих перезагрузках системы демон
будет запускаться программой init. Если все прошло успешно (сообщения об
ошибках записываются в файл /var/adm/log/asppp.log). то можно обращаться
к удаленному узлу с помощью программы ssh или ftp.
Особенности сетевого конфигурировония
В Solaris имеются две версии команды ifeonfig: одна — в каталоге /shin,
а другая — в каталоге /usr/sbin. В первой из них применяется фиксированный
порядок поиска соответствия между сетевыми именами и IP-адресами:
сначала просматривается файл /etc/hosts. а затем — база данных DNS.
Во второй версии последовательность поиска определяется на основании
файла /etc/nsswitch.conf: это более “естественное” поведение. Когда команда
/sbin/ifconfig вызывается на этапе начальной загрузки, предполагается, что в
файле /etc/hosts содержится достаточно записей для активизации интерфейсов
и обращаться к DNS-серверу не потребуется.
Результаты работы команды ifeonfig -а будут разными в зависимости от
того, кто ее вызывает: пользователь root или рядовой пользователь. Это
касается обеих версий команды. В первом случае помимо IP-адресов и
параметров отображаются также МАС-адреса.
Solaris разрешает менять МАС-адрес сетевой платы с помощью команды
ifeonfig. Мы считаем это ошибкой, а не полезной возможностью.
13.13. Сетевое конфигурирование HP-UX
Операционная система HP-UX заслуживает золотую медаль за простоту
сетевого конфигурирования. Все конфигурационные параметры хранятся в
файле /etc/rc.config.d/netconf. Значения параметров из этого файла (а также
всех других файлоа в каталоге rc.config.d) записываются в переменные среды
на этапе начальной загрузки; они используются сценарием /sbin/гс Файл
Глово 13 Сети TCP/IP
337
netconf снабжен комментариями, в которых поясняется, что должно быть
записано в ту или иную переменную и иля чего она нужна.
Базовое конфигурирование
Чтобы назначить компьютеру имя и сконфигурировать его первый сетевой
интерфейс, отредактируйте файл netconf, присвоив значения следующим
переменным:
HOSTNAME
INTERFACE_NAME[0]
IP ADDRESS|0]
SUBNET_MASK[0]
Например:
HOSTNAME=disaster
INTERFACE_NAME[0]“land
IP_ADDRESS[01=192.108.21.99
SUBNET—MASK[0]—255.255.255.0
Второй интерфейс будет иметь индекс 1. О его присутствии говорит
значение переменной NET CARDS. равное 2.
Файл netconf содержит также переменные, предназначенные для конфи-
гурирования статических маршрутов и запуска демона маршрутизации. Чтобы
задать стандартный маршрут, нужно выполнить следующие присваивания.
ROUTE-DESTINATION[01=default
ROUTE-MASK (0 ] ="’•
ROUTE_GATEWAY[0]=192.108.21.254
ROUTE_COUNT[0]“1
Переменная ROUTE_MASK нужна для сети, в которой маска подсети
отличается от стандартной маски, используемой в данном классе адресов.
Переменная ROUTE_CO(JNT должна содержать 0, если в качестве шлюза
выступает локальный компьютер, и I, если шлюз расположен на удаленной
машине. Параметры остальных статических маршрутов задаются в перемен-
ных ROUTE--* с индексами [ 1 ', 12 ] и т.д. Эти значения передаются
непосредственно команде route Например, переменная ROUTE_DESTINATION
может содержать ключевое слово default, как показано выше, либо предло-
жение net адрес, либо предложение host имя.
В HP-UX используется демон gated, а не routed. Необходимо задать
переменную GATED равной 1, а в массив GATED_ARG5 записать список
аргументов, передаваемых демону. Подробнее о конфигурировании этого
демона рассказывается в главе 14. Много полезной информации содержится
па man-странице, посвященной маршрутизации (man routing).
Многие переменные в файле netconf могут содержать либо сетевое имя.
либо IP-адрес. Если указано имя, оно обязательно должно присутствовать в
файле /etc/hosts. На этапе начальной загрузки система просматривает только
файл /etc/hosts и не использует никаких других механизмов поиска имен.
В этом файле сначала должны идти полностью определенные доменные
имена, затем короткие имена и псевдонимы.
В системе имеется команда Ian scan, которая отображает информацию об
имеющихся сетевых интерфейсах. Команда ifconfig -а не работает, зато
работает команда ifconfig интерфейс. Имена сетевых интерфейсов начинаются
?2‘1
Чость [I Роботе в сетях
с префикса “Ian” или “snap”. Префикс “Ian” обозначает канальный уровень
Ethernet, а префикс "snap" — спецификацию IEEE 802.3. Первый интерфейс
обозначается LanO, второй — lanl и т.д.
В HP-UX. как и в Solaris, имеется концепция подключения интерфейсов
Но все интерфейсы подключаются автоматически, когда команда ifconfig
назначает им IP-адреса.
SAM — это системная административная утилита, оснащенная меню и
позволяющая конфигурировать сетевые интерфейсы, а также выполнять
многие другие административные задачи.
Примеры конфигураций
Чтобы вручную подключить сетевой интерфейс и задать стандартный
маршрут, нужно выполнить команды следующего вида:
к ifconfig lanO 192.108.21.99 netmaak OxffffffOO
# route add default 192.108.21.254 1‘
Команда lanscan выводит список сетевых интерфейсов, имеющихся в
системе, и параметры связанных с ними драйверов. Команда lanscan -v
отображает чуть больше информации. Ниже показан ряд примеров. Поле MAi
со значением ETHER подразумевает, что именем устройства будет lanO, п не
snapO. Команда ifconfig подтверждает, что это правда.
% lanscan
Hardware	Station	Crd.	Hdw	Net-Int	NM	MAC	HP-DLPI	DLPI
Path	Address	In#	State	NameFPA	ID	Type	Support	Mjrt
8/0/20/0	0x001...	0	UP	lanO snapO	1	ETHER	Yes	130
% ifconfig lanO
lanO: flags=643<UP,BROADCAST,RUNNING,MULTICAST* inet 192.108.21.99
netmask ffffffOO broadcast 192.108.21.255
% ifconfig snapO
ifconfig: no such interface
Команда netsiai -i отображает имена сетевых интерфейсов, а команда
nctstat -nr выводит содержимое таблицы маршрутизации:
% natatat -i
Name	Mtu	Network	Address	Ipkcs	Opkts
lanO	1500	192.108.21.0 disaster.xor.com	6047	3648
loO	4136	127.0.0.0	localhost-xor.com	231	231
% netatat -nr
Routing tables
Dest/Netmask	Gateway	Flags	Refs	Use	Int	Pmtu
127.0.0.1	127.0.0	UH	0	231	loO	4136
192.108.21.99	192.108.21.99	UH	8		lanO	4136
192.108.21.0	192.108.21.99	и	2	0	lanO	1500
127.0.0.0	127.0.0.1	и	0	0	loO	4136
default	192.108-21.254	UG	0		lanO	1500
В HP-UX 11 счетчик числа переходов не требуется; по умолчанию он равен 0, если не
указано иное. В более ранних версиях системы счетчик доджей был присутствовать.
Глава 13. Сети TCP/IP
33г
Программа lanadmin отображает статистику сетевого трафика для каждого
обнаруженного интерфейса. С ее помощью можно управлять работой интер-
фейсов. Эта программа оснащена текстовым меню, упрощающим доступ к
нужной информации. Ниже показан пример сбора данных по интерфейсу
1ап0:
% lanadmin
LOCAL ARE?. NETWORK ONLINE ADMINISTRATION, Version 1.0
Copyright 1994 Hewlett Packard Company.
All rights are reserved.
Test Selection	mode.
Ian	-*	LAN Interface Administration
menu	»	Display this menu
quit	-	Terminate the Administration
terse	—	Do not display command menu
verbose	=	Display command menu
Enter command; lan
LAN Interface test mode. LAN Interface PPA Number “ 0
clear
display
end
menu
ppa
quit
reset
specific
“ Clear statistics registers
Display LAN Interface status/statistics
- End LAN Interface Admin., go up 1 level
- Display this menu
- PPA Number of the LAN Interface
- Terminate the Admin, return to shell
= Reset LAN Interface, execute selftest
= Go to Driver specific menu
Enter command: display
LAN INTERFACE STATUS DISPLAY
PPA Number
Description
Rev 0.
Type (value)
MTU Size
Speed
Station Address
Administration Status (value)
Operation Status (value)
Thu, Mar 2,2000 00:41:24
= C
- lanO HP 10/100 TX Half-Duplex Hw
= ethernet-csmacd(6)
- 1500
= 10
- 0xl08303e9e6
" up(l)
- Up(l)
Inbound Unicast Packets	“	4204
Inbound Non-Unicast Packets	=	5594
Inbound Unknown Protocols	=	501
Outbound Octets	=	454903
Outbound Unicast Packets	=	3603
Deferred Transmissions	=	2
Lace Collisions	=	0
Excessive Collisions	=	2
К тому времени, когда была запушена эта программа, система работала
всего 3 часа глубокой ночью (мы добавляли диск, поэтому часто перезагру-
жались). В результате график оказался очень низким. Помимо команд Ian и
340
Чость И Роботе в сетях
display, результаты работы которых показаны выше, мы также попытались
выполнить команды clear (обнуляет счетчики) и reset (сбрасывает конф ите-
рационные параметры интерфейса), но поскольку у нас не было прав
суперпользователя, нам было отказано в этом.
Конфигурирование DHCP
Как и в случае других сетевых параметров, включить использование
протокола DHCP иа этапе загрузки можно путем задания переменных в файле
/etc/rc.config.d/netconf. В данном случае переменные хранятся в массиве
□HCP_enable; индекс [0] означает первый интерфейс, индекс [1] —
второй и т.д. Например, запись
DHCP_ENABLE[0]-1
переводит первый интерфейс в режим DHCP. Сетевая плата получит свой
ГР-адрес, маску подсети и другие параметры от DHCP-сервера, расположен-
ного в локальной сети. Если задать переменную равной 0, поддержка
протокола DHCP будет отключена; придется назначать плате статический
адрес в файле netconf. Если запись DHCP_ENABLE отсутствует, считается, что
соответствующая переменная по умолчанию равна 1.
Сценарий /sbin/auto_parms берет на себя задачу взаимодействия с
DHCP-сервером Программа dhcpdblconf записывает параметры DHCP, по-
лученные сценарием autojarnis в файл netconf. из которого на этапе
начальной загрузки извлекается конфигурационная информация.
На стороне сервера система HP-UX реализует DHCP-сервер в виде демона
bootpd, который также обрабатывает запросы ВООТР Программа dhcptools
записывает параметры DHCP в базу данных демона, проверяет конфигура-
ционные файлы на предмет наличия ошибок, возвращает неиспользуемые
адреса и выполняет множество других задач. Если возникнут проблемы,
диагностическая информация программы dhcptools окажется очень кстати.
Создаваемые ею файлы помешаются в каталог /imp, и в их именах
присутствует компонент “dhep”.
Конфигурировать протокол DHCP можно также с помощью утилиты
SAM. Могут возникать проблемы совместимости, если клиенты HP-UX
работают с посторонними DHCP-серверами или. наоборот, серверы HP-UX
взаимодействуют со сторонними DHCP-клиентами.
Динамическое переконфигурирование и настройка
Как и в Solaris, можно применять команду ndd для настройки различных
сетевых параметров (более 100). Будучи вызванной в интерактивном режиме,
команда ndd меняет значения “на лету”. Чтобы изменения стали постоянны-
ми, нужно добавить их в файл /etc/rc.conng.d/nddconf, который читается на
этапе начальной загрузки.
Опция -h (вызов справки) очень удобна. При отсутствии дополнительных
аргументов команда ndd -h выводит список всех настраиваемых параметров.
Если указано имя переменной, отображается информация о том, для чего
нужна переменная, каковы ее минимальное, максимальное и стандартное
значения. Например:
% ndd -h | дгезр воигсв
ip_forward_src_routed - Controls forwarding of source rout.ee packets
% ndd -h ip_forw*rd_«rc_routed
Глово 13. Сети TCP/IP
341
ip_f orward_src_roiited:
Set to 1 to forward source-routed packets; set to 0 to
disable forwarding. If disabled, an ICMP Destination
Unreachable message is sent to the sender of source-
routed packets needing to be forwarded. [0,1] Default: 1
Как показывает команда ndd в данной версии HP-UX (11.00) по
умолчанию поддерживается направленная маршрутизация. (Надеемся, что,
когда значение по умолчанию меняется, документация к команде ndd тоже
обновляется.) Чтобы просмотреть и модифицировать значение переменной
ip_forward_src_routed, воспользуемся опциями -get и -set:
% ndd -get /dav/ip ip_forward_src_routed
1
% sudo ndd -set /dev/ip ip_forwardsrc_routed 0
% ndd -get /dav/ip ip_foxrward_src_routed
0
Чтобы навсегда отключить направленную маршрутизацию, добавьте
приведенные ниже строки в файл nddconf:
# отключаем направленную маршрутизацию
TRANSPORT NAME[0]=1р
NDD_NAME [О] -ip_f orward_src_r outed
NDD_VALUE(0]=0
Для следующей модифицируемой переменной нужно добавить в файл
nddconf те же три строки, указав ггмя переменной и ее значение, а также
индекс 1. а не 0. К сожале[<ию, в этом файле можно задать всего 10
параметров.
Безопасность, брандмауэры, фильтрация и система NAT
В табл. 13.19 описано, как в HP-UX реализован ряд технологий,
касаюшихся безопасной работы в сети О них кратко рассказывалось в
параграфе 13.9. Большинство настроек можно и вменить с помошыо команды
ndd
Таблица 13.19. Поддержка технологий, связанных с сетевой безопасностью, в HP-UX
Технология
Перенаправление
IP-пакетов
Переадресуюшис
ICMP-пакеты
По умолчанию Переменная, изменяемая командой ndd
динамическое1 ip forwarding: 0 — отключено, 1 — вклю-
чено, 2 — динамически
принимаются Отменить это поведение нельзя
Направленная
маршрутизация
разрешена
ip forward_src_routed: 0
Широковешатсль- разрешены ip_forward directedbroadcasts: 0
ные ping-пакеты___________________________________________________
1 Разрешено для всех интерфейсов, номер которых больше 1.
В HP-UX пет встроенных пакетов межсетевой защиты и IP-фильтрации,
за исключением PPP-соединений (см. далее). Система NAT также не
поддерживается. Правда, Даррен Рид (Darren Reed) уже перенес свой бес-
платный пакет IPFilter в HP-UX.
342
Чость II Роботе в сетях
Версия демона inetd r HP-UX содержит встроенные функции работы с
протоколом TCP. которые можно конфигурировать посредством файла
/var/adm/inetd.scc. Подробности даны в параграфе 21.7.
Мы рекомендуем использовать специализированное оборудование, на-
пример систему Cisco Р1Х. в качестве брандмауэра. UNIX-системы для этой
роли слишком небезопасны. Если вас интересует, как именно ОС HP-UX
оказывается незащищенной, обратитесь по адресу
http://people.hp.se/stevesk/bastion11 .html
В этом документе описано, какие шаги следует предпринять, чтобы
превратить компьютер, работающий под управлением HP-UX 11.00. в '‘бас-
тион” на пути в незащищенную сеть. В нем перечислены ясе “ловушки",
которые необходимо отключить в HP-UX, чтобы машина могла безопасно
работать в internet. Нам бы хотелось узнать, есть ли аналогичные Web-узлы.
посвященные другим рассматриваемым в книге системам?
Конфигурирование РРР
В HP-UX входит PPP-пакет компании Morning Star, испальзуюшнй tun —
драйвер IP-туннелей. Конфигурирование протокола РРР в HP-UX осущест-
вляется почти так же. как в Solaris. В обеих системах используется
конфигурация HoneyDanBer UUCP, но в Solaris она оставлена без изменений,
а в HP-UX файлы перемешены в другие каталоги и улучшена интерактивная
документация.
В табл. 13.20 перечислены файлы, связанные с протоколом РРР
О некоторых из них рассказывалось в параграфе, посвященном конфигури-
рованию РРР в Solaris.
Таблица 13.20. Файлы, связанные с протоколом РРР в HP-UX
Файл	Назначение
/etc/ppp/Auth	Содержит имена одноранговых компьютеров и параметры аутен- тификации
/etc/ppp/Dcvwes	Описывает физические устройства (модемы)
/ctc/ppp/Dialers	Содержи! описание телефонных номеров для каждого сне гем него модема
/etc/ppp/Filter	Определяет параметры автоматическою набора номера, фильтра- ции и регистрации пакетов
/etc/ppp/Keys	Содержит ключи для шифрования соединений
/etc/ppp/Systems	Включает информацию о соседних системах
/etc/ppp/Autos tart	Содержит команду запуска демона pppd с соответствующими аргументами
/usr/bin/pppd	Демон РРР
Все man-странииы, связанные с этими файлами, написаны качественно,
но у них странные имена: имя каждой страницы начинается с префикса
"ррр”, за которым следует имя файла. Например, команда man Systems не
работает, зато команда man ppp.Systems отображает детальное описание
формата файла Systems, включая несколько примеров.
В каталоге /etc/ррр содержится также ряд образцов для каждою
конфигурационного файла. Ниже показан фрагмент файла Systcms.cv: л им
Глово 13. Сети TCP/IP
343
строкам предшествовали сотни строк комментариев, почти целиком повто-
ряющих man-странииу ppp.Systems:
* Examples of entries that we use at Morning Star Technologies
#
#roughy Any ACU 19200-PEP 5551212 ogln:—ogln: Premora sswordi VqkjLJHIuD
tmanatee Any ACU 36400 5552466 ogin:—ogln: Premora ssword: \qd7DW3KlZ
В каталоге /etc/ppp/exatnplcs находятся более специфичные примеры,
посвященные терминальным серверам различных производителей.
Чтобы протокол РРР работал в HP-UX, нужно заполнить UUCP-файлы
информацией о модеме и системе, с которой устанавливается соединение,
включая регистрационное имя и пароль, передаваемые терминальному серверу
на противоположном койне соединения. Необходимо создать и отредактиро-
вать сценарий /etc/ppp/Autostart, для того чтобы при установлении соединения
запускался демон pppd с нужными параметрами. Имеется образец такого
сценария — Autostart.ex, снабженный хорошими комментариями. На этапе
начальной загрузки один из сценариев в каталоге /sbin/rcl.d вызовет сценарий
Autostart автоматически.
Особенности сетевого конфигурирования
Операционная система HP-UX не любит, когда длина имени компьютера
превышает 8 символов. Длинные имена можно использовать, но предвари-
тельно следует задать имя узла в формате UUCP в файле /etc/rc.con-
fig.d/NODENAME, причем длина имени должна быть 8 символов или меньше.
13.14.	Сетевое конфигурирование Red Hot
В Red Hat большинство сетевых конфигурационных файлов хранится в
каталогах /etc/sysconfig и /etc/sysconfig/network-scripts. Эта операционная
система поддерживает протоколы DHCP и РРР, а также IP-фильтранию.
В стеке сетевых протоколов имеется поддержка избирательных подтвержде-
ний, которые иногда улучшают производительность TCP в загруженных
соединениях.
Базовое конфигурирование
Сетевое имя компьютера задается в файле /etc/sysconfig/network. где также
определяется DNS-домен и стандартный шлюз. К примеру, ниже показано
содержимое файла network для компьютера, в котором одна Ethernet-плата и
перенаправление IP-пакетов не поддерживается:
NETWORKING-yes
FORWARD_IPV4=false
HOSTNAME=redhac.хог.com
DOMAINNAME—xor.СОШ
GATEWAY-192.108.21.254
GATEWAYDEV=ethO
Имя компьютера должно также присутствовать в файле /etc/hostname.
В настоящее время, однако, этот файл используется только для обратной
совместимости.
Данные, касающиеся конкретных интерфейсов, находятся в файлах
/etc/sysconfig/network-scripts/ifcfg-Wifficp^euc, где последний компонент — имя
344
Чость II. Робота в сетях
сетевого интерфейса. В этих файлах можно задавать IP-адрес, маску подсети,
сетевой и широковещательный адреса каждого интерфейса. Имеется также
строка, в которой вы можете указать, должен ли интерфейс активизироваться
на этапе начальной загрузки, что особенно полезно в портативных компью-
терах.
Обычно в системе присутствуют файлы для Ethemet-платы (ethO) и
интерфейса обратной связи (1о). Вот каким будет содержимое файлов
ifcfg-ethO и iTcfg-loO для компьютера redhat.xor.com, описанного выше в файле
network:
DEVICE~erhO
1PADDR=192.108.21.73
NETMASK»255.255.255.0
NETWORKS 92.108.21.0
BROADCAST»!92.108-21.255
ONBOOT-yes
и
DEVICE“lo
IPADDR-127.0.0-1
NETMASK»255.0.0.0
NETWORK=127.0.0.0
BR0ADCAST=127.255.255.255
ONBOOT-yes
В Red Hat имеется ряд удобных сценариев, которые упрошают управление
интерфейсами. Сценарии /sbin/ifup и /sbin/ifdown принимают в качестве
аргумента имя интерфейса и соответственно подключают или отключают
интерфейс. После изменения любого файла в каталоге /etc/sysconfig не
забудьте выполнить последовательно команды /sbin/ifdown интерфейс и
/sbin/ifup интерфейс. А еше лучше перезагрузить систему, чтобы быть
уверенным в отсутствии скрытых побочных эффектов.
Если нужно управлять всеми интерфейсами одновременно, воспользуй-
тесь сценарием /etc/rc.d/init.d/network, принимающим аргументы start, slop,
restart и status. На этапе начальной загрузки этот сценарий вызывается с
аргументом start.
Стартовые сценарии также могут конфигурировать статические маршруты.
Любой маршрут, внесенный в файл /etc/sysconfig/static-routes. добавляется в
таблицу маршрутизации на этапе начальной загрузки. Записи из этого файла
содержат аргументы для команды route add.
echO лес 130.225.204.48 netmask 255.255.255.248 gw 130.225.204.49
ethl лес 192.38.8.0 netmask 255.255.255.224 gw 192.38.8.129
Первым указывается интерфейс, за ним — аргументы команды route: тип
маршрута (net или host), адресуемая сеть, маска для этой сети и< наконец,
шлюз для следующего перехода. Ключевое слово gw необходимо. В сущест-
вующих ядрах Linux не поддерживается параметр metric команды route, но
его можно добавить в таблицу маршрутизации, чтобы о нем узнали демоны
маршрутизации.
В Red Hat 5.1 и более поздних версий имеется утилита linuxconf. С ее
помошью можно выполнять многие административные задачи, включая
вопросы, связанные с конфигурированием сети.
Глава 13. Сети TCP/IP
345
Примеры конфигураций
Следующие команды активизируют сетевой интерфейс и добавляют
стандартный маршрут. Обратите внимание иа то, что ключевое слово up в
строке вызова команды ifconfig не требуется, но ключевое слово gw в строке
вызова команды route должно присутствовать:
I ifconfig ethO 192.10В.21.73 netmask 255.255.255.0
i route add default gw 192.108.21.254 ethO
I Io умолчанию команда ifconfig в Red Hat выдает множество информации,
включая аппаратный адрес, данные канального уровня и различную стати-
стику:
% /sbin/ifconfig
ethO Link encap:Ethernet HWaddr 00:CO:FO:1F:57 :61
inet addr:192.10S.21.73 Beast:192.108.21.255
Mask:255:255:255:0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric;!
RX pkts:248725 errors:0 dropped:0 overruns:!) framezO
TX pkts:5219 errors:24 dropped:0 overruns:0 carrier:20
collisions:1280 txqueuelen:100
Interrupt:10 Base addr 0x6500
lo Link ecnap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:3924 Metric:1
RX pkts:44 errors:0 dropped:0 overruns:0 frame:0
TX pkts:44 errors: droppea:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Число конфликтов пакетов для Ethernet-платы равно 1280, что составляет
24,5% от числа отправленных пакетов. Это чрезвычайно высокий показатель,
который свидетельствует о том. что сеть перегружена и должна быть разделена
на несколько подсетей или же следует перейти на коммутируемую архитек-
туру.
Как и и большинстве систем, команда netstal -nr выводит таблицу
маршрутизации. а команда netsiat -i отображает информацию о сетевых
интерфейсах.
% netstat -nr
Kernel IP routing table
Destination	Gateway	Geninas k	Flags MSS Window irtt I face				
192.108.21.73	0.0.0.0	255.255.255.255 UH	0	0	0	ethO
192.108.21.0	0.0.0.0	255.255.255.0 U	0	0	0	ethO
127.0.0.0	0.0.0.0	255.0.0.0	U	0	0	0	lo
С.0.0.0	192.108.21.254	0.0.0.0	UG	D	0	0	ethO
% netstat -1
Kernel Interface table
				Receive						Transmit				
I face	MTU	Met	OK	Err drp	OVR	ok	ERR DRP	OVR	rig
ethO	1500	0	251684	0	0	0	5710	24	0	0	BRU
lo	3924	0	44	0	0	0	44	0	0	0	LRU
Команда nets tat -i показывает для каждого интерфейса число обычных
пакетов, ошибок, удаленных пакетов и переполнений как во входной, так и
в выходной очередях.
346
Чость II. Роботе в сетях
Конфигурирование DHCP
В Red Hat имеется DHCP-сервер dhepd и два различных DHCP-клиента:
pomp и dheped (старая разработка университета Карнеги-Меллона, представ-
ляющая собой усовершенствованный вариант демона bootpd). Мы рекомен-
дуем отказаться от обоих клиентов и воспользоваться программой,
предоставленной организацией ISC (www.isc.otg). По нашему опыту, она
надежнее. DHCP-сервер Red Hat разработан этой же организацией, поэтому
остается только удивляться, почему в данную операционную систему не
включен аналогичный клиент. Конфигурирование ISC-клиента рассматрива-
ется далее в параграфе 13.15.
Программа pump — это стандартный DHCP-клиент в Red Hat. Он
запускается на этапе начальной загрузки из сценария /etc/sysconfig/nelwork-
scripts/ifcfg-шялерфейс Например, чтобы задать автоматическое конфигури-
рование интерфейса ethO посредством DHCP, нужно отредактировать файл
/etc/sysconfig/network-scripts/ifcfg-ethO, указав вместо IP-адреса, маски подсети
и других параметров строку
BOOT PROT0=dhcp
Если требуется вручную запустить программу pump для управления
интерфейсом ethO, воспользуйтесь командой
# ршпр -1 ithO
Остановить программу pump можно так:
f pump —х —1 ethO
Демон dheped, являющийся альтернативой программе pump, практически
не используется. Наверное, разработчики Red Hat не удалили его только
потому, что боялись нарушить работу существующих приложений. Этот демон
конфигурируется посредством файлов в каталоге /etc/dhcpc.
Диномическое переконфигурировоние и настройка
В Linux настройка ядра и сетевых параметров осуществляется не так, как
в других операционных системах. Вместо того чтобы предоставить команды
для чтения и установки параметров, разработчики Linux поместили “образ”
каждой настраиваемой переменной в специальную файловую систему /ргос.
Важные сетевые параметры находятся в каталоге /proc/sys/net/ipv4. Вот их
сокращенный перечень;
% cd /ргос/вув/net/lpv4; la -F
conf/
icmp_destunreach_rate
i cmp_echo_ignore_broadcasts
icmp_ignore_bog'js_error_respons es
icrap_t imeexceed_rate
ip_alwaysde frag
ipdefau1 t_C11
ip_forward
ipjnas k debu g
ipfrag high thresh
ipfrag_tirne
route/
tcp_keepalive_probes
icmp__echo_ignore_all
i emp echorep1y_rate
i cmp_pa rarapr ob__ra t e
icmp_max_niember ships
ip_autoconfig
ip_dynaddr
ip_local_port_range
ipno_pmtu_disc
ip frag_low_th resh
neigh/
tcp_fin_tinieout
tepkeepalive_time
Глово 13. Сети TCP/IP
347
tcp_ma x_kd_pгobeз
tcp_retrans_collapse
tcp_retries2
tcpsack
tcp__syn__re tries
tcp_timestamps
ccp_max_s yn_ba cklog
tcp_retriesl
tcp_rfcl337
tcp_stdurg
tcp_syncookies
tcp_window_scaling
Многие переменные, в именах которых присутствуют компоненты “rate"
и “max”, используются для пресечения атак вида “отказ в обслуживании”
В подкаталоге conf хранятся переменные, устанавливаемые для каждого
интерфейса по отдельности. Там есть подкаталоги all и defaults, а также
подкаталоги для всех интерфейсов (включая интерфейс обратной связи)
В каждом подкаталоге содержится одинаковый набор файлов:
% is -F
accept_redirects
forwarding
proxy_arp
send redirects
accept_source_route
log_marcians
rp filter
shared media
bootp_relay
mc_forwarding
secure redirects
Изменения, производимые в подкаталоге all, отражаются на всех интер-
фейсах. Но если та же самая переменная меняется, скажем, в подкаталоге
ethO. то это затронет только соответствующий интерфейс- В подкаталоге
defaults содержатся стандартные значения переменных на момент инсталляции
системы.
Чтобы узнать значение переменной, воспользуйтесь командой cat. Изме-
нить это значение можно с помощью команды echo, перенаправив ее
результаты в соответствующий файл. Например, команда
% cat lcny_echo_rgncre_broadcasts
О
показывает, что текущее значение переменной icmp_echo_ignore_broad-
casts равно 0, т.е. широковещательные ping-пакеты допустимы. Чтобы
сделать ее ранной 1 (и тем самым защитить систему от атак типа “smurf’)
введите
% sudo csh -с "echo 1 > icmp echo_igncre_brcadcast5"
В документе /usr/src/linux/Docu mentation/proc.txt, написанном разработ-
чиками SuSE Linux, приведены хорошие примеры настройки ядра средствами
файловой системы /ргос. В нем объясняется, что означает та или иная
переменная, иногда указывается, какие значения лучше всего задавать.
Безопосность, брандмоуэры, фильтрация и система NAT
В табл. 13.21 описано, как в Red Hat реализован ряд технологий,
касающихся беюпасной работы в сети. О них кратко рассказывалось в
параграфе 13.9.
Если задать команду sudo echo 1 > icmpechoignorebroadcasts, будет получено сообщение
"permission denied" (доступ за пре шеи), поскольку интерпретатор команд попытается от-
кры гь выходной файл до запуска программы sudo. В данном случае необходимо, чтобы права
суперпользователя распространялись не только на команду echo, но и на операцию
перенаправления. Следовательно, нужно создать порожденный интерпретатор с правами
пользователя root, в котором будет выполнена вся команда.
3^3
Чость II Робото в сетях
Таблице 13.21. Поддержка технологий, связанных с сетевой безопасностью, в Linux
Технология	Узел	Шлюз	Управляющий файл (в каталоге /р гос/sys/net)
Перенаправление [Р-пякетов	отключено	включено	ipv4/ip_forward для всей системы Ipv4/conf/uKwe.p$euc/forwardiDg для каждого интерфейса1
Переадресующие ICMP-пакеты	принимаются	игнорируются	lpv4/conf/nHmep$euc/«ccept_re- dlrects
Направленная маршрутизация	нс разрешена	разрешена	ipv4/conf/ интерфейс/ксер^оаг- ceroute
Широковещатель- ные ping-пакеты	принимаются	принимаются	ipv4/i p_echo_ignore_broa dcasta
В качестве параметра интерфейс может быть задано имя конкретного интерфейса
или ключевое слово all.
Чтобы сделать изменение любого из параметров постоянным (точнее,
чтобы переустанавливать его всякий раз при перезагрузке системы), добавьте
соответствующую команду echo в сценарий, выполняющийся в процессе
начальной загрузки.
В Red Hat имеется неплохая программа IP-фильтрации. Обычно мы не
рекомендуем использовать компьютер на базе UNIX (или Windows NT) в
качестве брандмауэра, поскольку в целом эта операционные системы не
обеспечивают надлежащий уровень безопасности. Но уж лучше ставить
программный брандмауэр, чем вообще ничего, если речь идет о домашнем
компьютере или организации, бюджет которой не предусматривает покупку
специализированного оборудования (например, системы Cisco PIX). Именно
поэтому мы подробно описываем программу ipchains
Устанавливая Linux-систему в качестве брандмауэра, убедитесь, по
крайней мере, что она включает самые последние обновления и “заплаты”,
касающиеся брешей в системе защиты. В главе 21 описаны многие вопросы,
которые обязательно следует учесть, чтобы сделать систему максимально
безопасной. Компьютер, играющий роль брандмауэра, — идеальное место
для практической проверки рекомендаций, изложенных в главе по безопас-
ности. (В параграфе 21.9 даны сведения, касающиеся брандмауэров в целом.
Читателям, не знакомым с концепцией брандмауэра, советуем предварительно
прочитать приведенный там материал.)
В программе ipchains применяется концепция упорядоченной “цепочки"
правил, согласно которым проверяются сетевые пакеты. В каждой цепочке
имеется директива, определяющая, что следует делать с пакетами, подчиняю-
щимися данному правилу. Если пакет прошел проверку, его судьба предре-
шена и другие проверки не выполняются. По этой причине правила в цепочке
задаются в направлении от наиболее конкретного к наименее конкретному.
По умолчанию существуют три цепочки: inpur, output и forward.
Можно создавать и свои собственные цепочки. Каждый пакет, обрабатывае-
мый ядром, поступает на проверку лишь в одну' стандартную цепочку.
В цепочке forward проверяются все пакеты, которые поступают в одни
интерфейс и перенаправляются в другой. В цепочке input обрабатываются
пакеты, поступающие из внешней сети и адресованные локальному компью-
теру. И наконец, в цепочке output проверяются только пакеты, посланные
Глове 13 Сети TCP/IP
349
с локального узла. Для каждого сетевого интерфейса существуют свои копии
этих цепочек, поэтому для разных интерфейсов можно назначать свои
критерии обработки пакетов.
Наиболее распространенные директивы — ACCEPT. DENY. REJECT. MASQ.
REDIRECT и RETURN. Директива ACCEPT разрешает пакету следовать своим
маршрутом. Директивы DENY и REJECT запрещают пропускать пакет, но
первая приводит к “безмолвному” удалению пакета, а вторая — к выдаче
iCMP-сообшения об ошибке.
Директива MASQ включает механизм 1Р-маскирования (на жаргоне Linux
это синоним системы NAT)’. Чтобы этот механизм заработал, нужно задать
переменную FORWARD_LPV4 в файле network равной true и скомпилировать
ядро с установленным параметром CONFIG_IP_MASQUERADE.
Директива REDIRECT перенаправляет пакеты прокси-серверу. Чтобы она
имела силу, нужно скомпилировать ядро с установленным параметром
CONFIG_IP_TP.ANSPARENT_PP.OXY. Эта особенность удобна, когда весь тра-
фик Web-утла должен проходить через кэширующую программу, такую как
Squid. Директива RETURN объявляет конец пользовательской цепочки.
В Red Hal брандмауэр обычно реализуется в виде последовательности
команд ipchains, содержащихся в стартовом сценарии rc.firewall. Отдельные
команды ipchains. как правило, имеют один из двух форматов:
Ipchains -F имя_цепочки
ipchains -Л имяцепочки -1 интерфейс -j директива
В первом случае из цепочки удаляются все предыдущие правила. Во
втором случае заданное правило добавляется к цепочке. Опции -i и -j
обязательны для каждого добавляемого правила. Программа ipchains поддер-
живает также ряд других опций (табл. 13.22).
Таблица 13.22. Дополнительные опции программы ipchoins
Опция	Назначение
-р протокол	Соответствие протоколу: tep, udp или iemp
-s исходный адрес	Соответствие исходному IP-адресу узла или сети (допускается нотация CIDR)
-d целевой адрес	Соответствие целевому IP-адресу узла или сети
—sport номер порта	Соответствие номеру исходною порта (обратите внимание на двойной дефис)
—dport номер порта	Соответствие номеру целевого порта (обратите внимание на двойной дефис)
—icnip type тип	Соответствие типу ICMP-сообщения (обратите внимание на двойной дефис)
-1	Регистрация пакетов в системе Sysiog (средство “кегле!", приоритет '‘info’’)
-у	Соответствие только новым TCP-запросам на установление соединения (проверяются флаги заголовка пакета)
!	Инверсия смысла опции
Строю говори, в Red Hal применяется ограниченная разновидность системы NAT, которую
правильнее называть PAT (Pon. Address Translation — грансляиия адресов портов). В ней ис
использусгся диапазон частных адресов, как в истинной системе NAT, а все соединения
коммутируются по одному-единствеююму адресу. С практической точки зрения эго не
имеет особого значения, поэтому для простоты мы будем продолжать употреблять термин
"NAT".
350
Чость II. Робото в сетях
Ниже приведен ряд полных примеров. Мы предполагаем, что интерфейс
рррО подключен к Internet, а интерфейс ethO — к локальной сети. Первый
набор правил задает прием всех пакетов из локальной сети и удаление тех
пакетов, которые поступают от интерфейса рррО и исходные адреса которых
попадают в диапазон частных адресов (система NAT). Эти пакеты должны
также удаляться в цепочке output, так как не нужно, чтобы они проникали
в Internet.
ipchains -A input -i lo -j ACCEPT
ipchains -A input -i. ethO -j ACCEPT
ipchains -A input -i pppO -s 192.168.0.8/16 —j DENY
ipchains -A input -i pppO -8 172.16.0.0/12 -j DENY
ipchains -A input -i pppO -s 10.0.0.0/8 -j DENY
Чтобы блокировать доступ в Internet через программу telnet (порт 23), но
разрешить почтовые соединения и систему SSH (порты 25 и 22 соответст-
венно), необходимо установить следующие правила:
ipchains -A	input	-i	рррО	-р	tcp	—dport	23	-j	DENY
ipchains -A	input	-i	pppO	-p	tcp	—dport	23	-j	ACCEPT
ipchains -A	input	-i	pppO	-p	tcp	—dport	23	-j	ACCEPT
Цепочка	input заканчивается	правилом,	запрещающим все пакеты,
которые не были разрешены явным образом. Интересно также узнать, кто
пытается проникнуть в систему из Internet, поэтому добавим флаг -1 после
директивы DENY, чтобы обеспечить регистрацию пакетов, не прошедших
данную проверку:
ipchains -A input -i рррО -j DENY -1
Наконец, зададим IP-маскирование (система NAT), чтобы не раскрывать
частные адреса, применяемые в локальной сети 192.168.1.0/24:
ipchains -A forward -i рррО -s 192.168.1.0/24 -d I 192-168.1.0/24 -
] MASQ
Здесь указан критерий отбора, согласно которому исходный адрес пакета
является локальным, а целевой адрес — внешним (флаг ! инвертирует смысл
проверки). Внутренний трафик, направляющийся локальному узлу, не
затрагивается.
Поскольку в Linux применяется система РАТ, а не истинная система
NAT, не нужно задавать диапазон внешних адресов для доступа в Internet-
Шлюз Linux использует свой собственный IP-адрес для всего внешнего
трафика, а переключение соединений от внутренних узлов осуществляется
на основании номеров портов.
Когда привыкаешь к рассмотренной системе записи, программа ipchains
начинает казаться разумным способом описания работы брандмауэра, однако
привлечение сюда же системы NAT выглядит не очень логичным. Дополни-
тельные примеры брандмауэров, основанных на программе ipchains, можно
найти по адресу www.wiley.corn/compbooks/sonnenreich.
По слухам, программа ipchains будет удалена из ядра Linux после
версии 2.2 и заменена новым механизмом фильтрации.
Почему эти пакеты нс отвергаются предыдущим правилом? Потому что данное правило
является частью цепочки forward, а нс input-
Глово 13 Сети TCP/IP
351
Конфигурирование РРР
В Red Hat используется та же реализация протокола РРР, что и во
FreeBSD (это касается версии уровня ядра, а не пользовательского уровня),
и конфигурируется она аналогичным образом. Чтобы не повторять здесь ее
описание, отошлем читателей к соответствующему разделу параграфа 13.15.
Особенности сетевого конфигурирования
В отличие от большинства систем, Linux обращает внимание на флаги
поля TOS (Type of Service — тип обслуживания) IP-пакета и быстрее
обслуживает пакеты, помеченные как интерактивные (минимальная задерж-
ка). Восхитительная возможность! К сожалению, умники из Microsoft сделали
все для того, чтобы нам пришлось от нее отказаться.
Все пакеты, поступающие от Windows 95, 98, NT и 2000, помечаются как
интерактивные независимо от их назначения. UNIX-системы этого не делают.
Если Linux-шлюз обслуживает смешанную сеть, в которой используется как
UNIX, так и Windows, Windows-пакеты всегда будут иметь приоритет. В то
же время в однородной UNIX-среде производительность заметно повышается.
Отменить сортировку пакетов на основании поля TOS можно во время
компиляции ядра Linux. Нужно просто отключить опцию “IP: use TOS value
as routing key”.
Когда используется 1Р-маскирование (система NAT), ядро собирает
полный пакет из фрагментов, прежде чем перенаправить его, даже если сразу
после этого придется заново разбивать пакет на фрагменты. На это уходит
несколько циклов работы центрального процессора, однако современные
процессоры настолько быстры, что подобная потеря времени вряд ли окажется
заметной.
Linux позволяет менять МАС-адреса сетевых интерфейсов определенных
типов. Мы считаем это ошибкой и не рекомендуем делать ничего подобного.
13.15.	Сетевое конфигурирование FreeBSD
Во FreeBSD имеются самые современные инструменты из сетевого
арсенала: два пакета межсетевой зашиты (включая систему NAT), две
реализации протокола РРР, поддержка протокола Т/ТСР (представляющего
собой достаточно успешную попытку сделать Web-соединения более эффек-
тивными) и многое другое.
Основные сетевые параметры указываются в файле /etc/rc.conf. Стартовые
сценарии читают также файл /etc/defaults/rc.conf, в котором задаются
стандартные значения большинства переменных. Можно создать файл
/etc/rc.conf,local в котором будут храниться параметры, специфичные для
заданного узла.
На самом деле перечисленные файлы представляют собой shell-сценарии,
создающие среду для работы других стартовых сценариев. Формат этих файлов
одинаков, а необходимость их существования объясняется тем, что разработ-
чики хотели разделить конфигурационные данные на уровни и хранить их
по отдельности. Файл /etc/defaults/rc.conf содержит начальные значения для
большинства параметров. В файле /etc/rc.conf находятся параметры, которые
являются локальными, но, возможно, они общие для нескольких машин
FreeBSD. Файл rc.conf.local хранит установки, применимые лишь к локальной
352
Чость II. Робото в сетях
машине. Для простоты мы предполагаем, что в системе используются только
файлы rc.conf.
Модифицировать файл /etc/defaults/rc.conf не нужно. Он полезен тем,
что содержит практически полный список переменных, доступных для
модификации, наряду с описанием их предназначения,
С точки зрения системного администратора единственное заметное
различие между FreeBSD 3.4 и 4.0 заключается в том, что стандартное ядро
содержит больше драйверов сетевых устройств (общим числом 13), а также
имеется встроенная поддержка стандарта IPv6.
Базовое конфигурирование
Ниже показаны установки, которые нужно сделать в файле гс.сопГ, чтобы
переопределить пустые значения соответствующих переменных, заданные в
файле /etc/defaults/rc.conf:
НовСпате-"и14я_узлаи	♦	это обязательно!
ifconfig_xxx-"lnet IP-адрес"	#	конфигурация сетевого	устройства
defaultrcuter-''шлюз"	#	стандартный шлюз
Переменная necwork_interfaces по умолчанию равна auto, чтобы
система могла находить сетевые интерфейсы на этапе начальной загрузки.
В эту переменную можно также записать список имеющихся интерфейсов
(не забудьте включить интерфейс обратной связи). Например:
network_lnterfacea-"loO х10"
Статические маршруты задаются в переменной static_routes:
static_rautee-"backlan 212"	• список статических маршрутов
route_backlan-"-net 10.0.2.0 132.236.212.2"
route_212-’’-net 132.236.212.64 -netnuisk 255.255.255.192 132.236.212.6я
Переменная static_routes содержит разделенный запятыми список
имен маршрутов. Имя маршрута — это произвольная строка, определяющая
переменную гои1е_щчя, в которой задаются аргументы для команды route add
По умолчанию маршрутизация полностью запрещена. Поэтому в боль-
шинстве систем нужно либо указать стандартный маршрут, либо задать
стандартные маршруты, либо активизировать демон routed или gated. (По
умолчанию база данных NIS тоже отключена.)
Примеры конфигураций
Чтобы вручную сконфигурировать Ethernet-плату и задать стандартный
маршрут, необходимо воспользоваться такими командами:
*	Ifconfig xlO inet 192.108.2111 netmaak OxffffffOO
*	route add default 192.106.21.254
Вторая из показанных команд эквивалентна следующей команде:
*	route add -net 0.0.0.0 192.108.21.254
В отличие от большинства версий команды route, во FreeBSD эта команда
требует наличия дефиса перед опцией, задающей тип маршрута (-net или
-host), и не принимает счетчик числа переходов.
Глово 13. Сети TCP/IP
353
После выполнения указанных выше действий команды ifeonfig и netstat -nr
выдают такие результаты:
% ifeonfig xlO
xlO: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>mtu 1500
inet 192.108.21.11 netmask. OxffffffOO broadcast 192.108.21.255
ether 00:60:97:9b:69;9a
media; lObaseT/UTP <half-duplex>
supported media: auroselect lOObaseTX <full-duplex> lOObaseTX
<half-duplex> lOObaseTX lObaseT/UTP <full-duplex> lObaseT/UTP
lObaseT/UTP <half-duplex>
% natatat -nr
Routing tables
Internet:
Destination	Gateway	Flags
default	192.10B.21.254	UGSc
127.0.0.1	127.0.0.1	UH
192.108.21	linktl	UC
192.108.21.1	8:0:20:77:5e:a0	UHLW
192.108.21.246	0:30:f2:f:48:0	UHLW
192.108.21.254	0:0:c:14:82:81	UHLW
Reis	Use
0	18
0	3
0	0
2	2586
0	0
1	0
Netif Exp
xlO
IcO
xlO
xlO	1160
xlO	303
xlO	1126
Флаги с и с в выводе команды netstat -nr говорят о том, что новые
маршруты узла (три последние строки) должны быть автоматически сгене-
рированы и добавлены в таблицу маршрутизации при выборе локального
сетевого маршрута или стандартного маршрута. Обратите внимание на то.
что у каждого из новых маршрутов есть срок действия.
Необходимость увеличения таблицы маршрутизации объясняется двумя
причинами. Первая из них заключается в том, что для маршрутов локальной
сети таблица маршрутизации одновременно является ARP-таблицей. Обычно
это разные таблицы, но в 4.4BSD они были объединены, и FreeBSD
унаследовала это свойство. Вторая причина та, что FreeBSD пытается
сохранять параметры соединений с внешними узлами (напрнмер, значение
MTU для TCP-соединения), запоминая их в таблице маршрутизации. Тогда
при последующих подключениях к тому же самому узлу можно будет повторно
использовать эти параметры, ие вычисляя их заново. Когда срок действия
записи истекает, оиа удаляется из таблицы маршрутизации.
Флаг s в описании стандартного маршрута говорит о том, что это
статический маршрут, который не должен удаляться из таблицы.
Следующий пример приведен в системе FreeBSD 4.0. где реализован как
стек IPv4, так и стек IPv6. В обоих случаях конфигурирование интерфейса
осуществляется посредством команды ifeonfig:
% ifeonfig fxpl
fxpl: flags=8943<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>mtu 1500
inet 135.197.1.116 netmask OxffffffOO broadcast 135.197.1.255
inec6 fe80::208:c7ff:fe89:4f03%fxpl prefixlen 64 scopeid Cx2
ether 00:08:c7:89:4f:C3
media: autoselect (lOObaseTX <half-duplex>) status:active
supported media; autoselect lOObaseTX <Eull-duplex> lOObaseTX
lObaseT/UTP <full-duplex> lObaseT/UTP
354
Чость II Робото в сетях
Конфигурирование DHCP
Во FreeBSD имеется DHCP-клиент организации ISC. Он конфигуриру-
ется посредством файлов rc.conf. Стандартные значения в файле /etc/de-
faults/rc.conf таковы;
dhcp_p г ogram«=,,/sbin/dhclient” # Путь к DHCP-клиенту
dhcp flags-и"	# Флаги, передаваемые клиенту
Скорее всего, эти значения правильны; менять их требуется только в том
случае, когда программа dhclient перемещается в другой каталог или вместо
нее подставляется другая программа. Чтобы активизировать протокол DHCP
для конкретного интерфейса, добавьте следующую строку в файл /etc/rc.conf:
if conf хд_интерфейс-"DHCP" # Активизация DHCP для данного интерфейса
При такой конфигурации программа dhclient будет запушена на этапе
начальной загрузки, если существует файл /etc/dhchenl.conf. Эта программа
отвечает за получение IP-адреса для интерфейса, задание стандартного
маршрута, выбор правильного сервера имен и т.д.
Файл dhclient.conf — это текстовый конфигурационный файл произволь-
ной формы, напоминающий аналогичный файл пакета BIND или DHCP-
сервера ISC. С ним связано слишком много опций и параметров, чтобы все
их можно было описать здесь. К счастью, стандартные установки в
большинстве случаев подходят, поэтому можно оставить файл пустым.
Программа dhclient хранит информацию об арендованных параметрах в
файле dhclient.leases, а свой идентификатор процесса — в файле /var/run/dhcli-
ent.pid.
Диномическое лереконфигурирование и настройка
Узнать или задать значение переменной ядра во FreeBSD можно с
помощью команды sysctl Существуют сотни различных переменных, из
которых около 65-ти связаны с конфигурированием сети. Подробное их
описание можно получить на man-страниие sysctl(3).
Команда sysctl -А выводит список переменных с их текущими значениями.
В именах переменных, связанных с конфигурированием сети, присутствует
компонент “net”. Чтобы отобразить только их, задайте команду sysctl -А |
grep net.
Если нужно узнать значение конкретной переменной, укажите ее имя в
строке вызова команды sysctl. Например, посредством следующей команды
можно определить, поддерживает ли система перенаправление 1Р-пакетов;
% sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: L
Значение 1 означает поддержку. Чтобы изменить значение переменной,
укажите флаг -w и задайте новое значение через знак равенства:
% sudo sysctl -w net.inet.ip.forwardingsО
net.inet.ip-forwarding: 1 -> 0
Эта команда отключает перенаправление IP-пакетов
Глово 13. Сети TCP/IP
355
Безопасность, брандмауэры, фильтрация и система NAT
В табл. 13.23 описано, как во FreeBSD реализован ряд технологий,
касающихся безопасной работы в сети. О них кратко рассказывалось в
параграфе 13.9, В третьем столбце указаны переменные, посредством которых
можно изменить соответствующую установку, эти переменные должны быть
заданы в файле /etc/гс. сопГ, а не с помощью команды sysctl.
Тоблицо 13.23. Поддержке технологий, связонных с сетевой безопосностью,
во FreeBSD
Технология	По умолчанию	Переменная файла rcconf
Перенаправление IP-пакетов	отключено	gateway_enable
Переадресуюшие ICMP-пакеты	принимаются	icmp_drop_reairecti
Направленная мар-	игнорируется	forward sourceroute
шрутизация		и acc(spt_scurceroute
Широковещатель- ные ping-пакеты	игнорируются	i cmp_brr.ca з t e c ho
Имеется также переменная lcmp_Log_redlrect, посредством которой включается
регистрация ICMP-пакетов.
Лучше не применять компьютер, работающий под управлением UNIX
(или Windows NT), в качестве брандмауэра, особенно в крупной организации,
где по сети передаются важные данные. Безопаснее и надежнее использовать
специализированное оборудование, например систему Cisco Р1Х. В то же
время программный брандмауэр на базе UNIX подойдет для домашнего
компьютера, где пользователь регулярно обновляет систему, устанавливая
самые последние “заплаты”. Ниже мы опишем два пакета межсетевой зашиты,
имеющихся во FreeBSD: ipfw и IPFilter.
Программа ipfw поддерживает концепцию “фиктивной" сети, посредством
которой можно управлять Internei-трафиком, задавая ширину полосы про-
пускания н длину очередей ввода-вывода, а также имитируя задержки и
потери. Изначально “фиктивная” сеть была задумана как средство устранения
заторов в TCP-каналах, но затем нашла много других применений. Сегодня
она используется для ограничения ширины канала, занимаемого Web- или
FTP-трафиком, и для управления загруженностью выделенных линий. Более
подробная информация приведена на man-странице dummynet.
С программой ipfw легко работать, а ее синтаксис напоминает синтаксис
списков доступа компании Cisco. Чтобы реализовать систему NAT посредст-
вом программы ipfw, воспользуйтесь утилитой natd в каталоге /sbin.
Подобно программе ipchains в Linux, программа ipfw вызывается по одному
разу для каждого правила фильтрации. Таким образом, брандмауэр реализу-
ется в виде shell-сценария, из которого вызывается последовательность команд
ipfw. Ниже показан фрагмент этого файла, который поможет понять синтаксис
команды. В данном примере de О — это внешний интерфейс, a edl —
внутренний. Третий параметр каждой строки задает номер правила. Правила
обрабатываются по порядку, от младшего к старшему. Этот порядок важен,
так как самое первое правило, которому соответствует проверяемый пакет,
определяет выполняемое действие.
#	Файл программы ipfw для FreeBSD
#	Скачала удаляем старые правила
ipfw -f flush
356
Чость II. Роботе в сетях
i Разрешаем все пакеты от DHCP-сервера и узла gw.syanck.net
ipfw add 500 allow ip from 128-138.129.136 to any
ipfw add 510 allow ip from 209.180.251.58 to any
t Разрешаем входной и выходной трафик SSH
ipfw add 600 allow tcp from any to any 22 via deC
ipfw add 605 allow tcp from any 22 to any in via deO
* Разрешаем ARP-пакетам проходить через мост
ipfw add 1000 allow udp from 0.0.0.0 2054 to 0.0.0.0
Другие правила разрешают входной и выходной DNS-трафик, доступ к
внешнему Web-содержимому, DHCP-запросы и UDP-пакеты для программ
traceroute и Quake (это студенческий компьютер). Весь трафик в пределах
локальной сети также разрешен. Ведется “черный" список адресатов,
обращающихся к DNS-серверу с запросами относительно несуществующих
узлов. Весь остальной трафик из внешнего мира блокируется.
Пакет IPFilter. написанный Дарреном Ридом, заслуживает большего
внимания, поскольку он совместим со многими другими версиями UNIX-
В него входит программа ipf, конфигурирующая брандмауэр, программа
ipfstat, отображающая список инсталлированных правил фильтрашш, про-
грамма ipnat, реализующая систему NAT, и ряд других утилит. Пакет доступен
по адресу
http://coombs.anu.edu.au/~avalon/ip-filter.html
Прежде чем начинать работать с пакетом, нужно скомпилировать ядро
со следующими параметрами:
option IPFILTER
option IPFILTER_LOG
Пакет IPFilter проводит четкое разграничение между фильтрацией пакетов
и системой NAT, а не смешивает их подобно программе ipchains в Red Hat.
На man-страницах ipf(l) и ipf(5) описан язык задания фильтров и приведено
множество примеров.
Программа ipf читает файл (по умолчанию это /elc/ipf. rules), в котором
заданы правила следующего вида:
действие in lout [quick] условие...
Параметр действие может принимать следующие значения:
•	pass — принять пакет;
•	block — удалить пакет;
•	log — зарегистрировать пакет в системе Syslog;
•	count — вести подсчет пакетов, соответствующих данному правилу.
Модификатор quick говорит о том, что заданное действие должно быть
выполнено как можно быстрее. Он задан по умолчанию для действий со rt
и log. Обычно правила применяются последовательно и никакие действия
не производятся до тех пор, пока не будут проверены все правила. Если
пакет соответствует нескольким правилам, самое последнее правило определяет
выполняемое действие.
Описанное поведение прямо противоположно работе программ ipchains
и ipfw, поэтому в Linux брандмауэр работает быстрее, при первом же
совпадении обработка пакета прекращается. Программу ipf удобно применять
для реализации гак называемого консервативного брандмауэра, в котором
самое первое правило запрещает все пакеты, а остальные правила разрешают
пакеты конкретных типов.
Глово 13. Сети TCP/IP
357
В табл. 13.24 даны примеры условий, которые можно задавать в программе
ipf. Это лишь вершина айсберга. Полная информация приведена на тап-стра-
нине. посвященной программе ipf.
Тоблицо 13.24. Примеры условий в прогромме ipf
Успдеие on интерфейс	Позначение Применить правило к указанному интерфейсу
proto протокол	Отобрать пакеты, соответствующие указанному прото- колу; tcp, udp или iemp
from исходный адрес	Фильтрация на основании адреса отправителя; машин- ный адрес, сетевой адрес или any
to целевой адрес	Фильтрация иа основании адреса получателя; машин- ный адрес, сетевой адрес или any
port = номер порта	Фильтрация в соответствии с номером порта, который может быть задан по имени (из файла /etc/services) или номеру; вместо знака = может быть любой другой арифметический оператор (<, >. <—, >=)
flags спецификация флагов	Фильтрация на основании флагов заголовка ТСР-па- кета
iemp-type номер keep state	Фильтрация на основании типа и кода ICMP Сохранить информацию о состоянии сеанса; обычно это нужно, чтобы отличать рабочие TCP-сеансы от новых сеансов
Давайте повторно реализуем цепочку правил, описанную ранее в
параграфе, посвященном Red Hat, но на этот раз вместо программы
ipchains применим программу ipf. Как и раньше, мы предполагаем, что
интерфейс ррр 0 — это соединение с Internet, а интерфейс ethO —локальная
Ethernet-плата. Следующие правила разрешают весь локальный трафик и
запрещают пакеты, поступающие по частным адресам из внешнего мира:
pass in on ethO all
pass in on lo all
block in quick on pppO from 192.168.0.0/16 co any
block in quick on pppO from 172.16-0.0/12 to any
block in quick on pppO from 1C.0.0.0/8 to any
Чтобы блокировать пакеты программы telnet, но разрешить почтовые и
SSH-соединения, воспользуемся такими правилами:
block in proto tcp from any to any port = 23
pass in on pppO proto tcp front any to any port = 25
pass in on pppO proto tcp from any to any port 22
Последние два правила должны также включать предложения flags и
keep-state, чтобы предотвратить перехват ТСР-соедннений. Обратитесь к
параграфу 21.9 и тап-странине ipf(5), где подробно описано, какие правила
нужно задавать и как их записывать. Те, кто работает в операционной системе
OpenBSD, могут просмотреть файл /usr/share/ipf. В нем содержится множе-
ство примеров команд ipf и ipnat.
Чтобы заработала система NAT, нужно сообщить ядру входные и
выходные адреса для привязки, а также диапазон номеров портов, благодаря
358
Чость II. Роботе в сетях
которым происходит расширение адресного пространства Подробнее о
механизме привязки адресов рассказывалось в параграфе 13.4.
Синтаксис правил NaT, задаваемых в программе ipnat, напоминает
синтаксис правил программы ipf. Эти правила тоже упорядочены, но в
обратной последовательности: действие выбирается на основании первого
подошедшего правила
Вот несколько примеров правил программы ipnat (они задаются в файле
ipnat. rules).
map pppO 192.168.1.0/24 -> 128.138.198.0/26 portmap tcp/udp 20000:65000
map pppO 192.168.1.0/24 -> 128.138.198.0/26
Опять-такн. мы предполагаем, что pppO — это интерфейс доступа в
Internet, а локальным компьютерам назначаются адреса из диапазона частных
адресов. Эти правила связывают адреса из сети /24 с адресами сети /26.
Поскольку в сеть /26 может входить в четыре раза меньше узлов, чем в сеть
/24, существует вероятность, что в какой-то момент целевых адресов окажется
недостаточно. Но предложение portmap расширяет диапазон адресов,
разрешая назначать каждому адресу 45000 различных портов.
Первое правило регулирует весь трафик TCP и UDP. но не затрагивает
ICMP, так как в этом протоколе нет понятия порта. Второе правило задает
перехват всех ICMP-сообщений; должна быть сделана попытка вернуть их
узлу-отправителю. Если ядро не может однозначно определить, кто должен
принять заданное 1СМ Р-сообшенне. оно осуществляет широковещательную
рассылку пакета. Любая машина, которая получит не предназначенный ей
пакет, должна удалить его.
На домашнем компьютере пользователю может быть предоставлен
реальный IP-адрес провайдера или адрес, полученный от DHCP-сервера
провайдера. Если выделяется статический адрес, нужно в строке шар задать
для целевого адреса суффикс /32 и достаточно широкий диапазон номеров
портов. Если же при каждом подключении адрес назначается заново,
воспользуйтесь нотацией 0/32, которая заставит программу ipnat получить
адрес непосредственно от сетевого интерфейса. Например, ниже показана
строка для случая, когда динамически назначается один единственный адрес.
map рррО 192.168.1.Ь/24 -> 0/32 portmap tep/udp 20000:65000
Механизм фильтрации пакетов, система NAT и режим регистрации
должны активизироваться на этапе начальной загрузки. Соответствующие
команды выглядят так.
t ipf —Е -Fa f /etc/ipf.rules
ft ipnat -CF -f /etc/ipnat.rules
Й ipmon -D -в
Флаг -E команды ipf разрешает фильтрацию, флаги -Fa вызывают сброс
существующих правил для всех потоков, а флаг -f задает чтение новых правил
из файла /etc/ipf.rules. Точно так же в случае программы ipnat сначала
удаляются старые правила, а затем загружаются новые из файла /etc/ip-
nat.rules. Программа ipmon выполняется в качестве демона, отслеживая
пакеты, которые регистрируются программой ipf на псевдоустройстве /dev/ipl,
и направляя их системе Sysiog.
По умолчанию FreeBSD предполагает, что в качестве системы фильтрации
используется программа ipfw. а не ipf. Нужно придумать новые переменные,
которые включали бы фильтрацию программы ipf в файле гс.сопГ. и задать
Глово 13. Сети TCP/IP
359
соответствующие строки в стартовом сценарии rc.network. Возьмите за образец
строки вызова программы ipfw. Редактирование файла rc.network мы оставляем
читателям в качестве домашнего задания; укажем лишь, что система NAT
конфигурируется посредством переменных natd_*:
r.atd_program-" /usr / sbin / ipna t"
natd_enable-,,YES”
natd_interface-"xxx"	t имя устройства или IP-a,ppec
natd_flags-"-f /etc/rpnat.rules"	w плюс люОые необходимые флаги
Не забывайте о правильном порядке инициализации компонентов на
этапе начальной загрузки. Из соображений безопасности лучше включать
фильтрацию до того, как будут сконфигурированы сетевые интерфейсы.
Конфигурирование РРР
Во FreeBSD имеются две реализации протокола РРР: одна в самом ядре,
а другая — на пользовательском уровне. Пользовательская программа назы-
вается ррр. Она использует драйвер IP-туннелей и файл конфигурации
/etc/ppp/ppp.conf. Эта программа работает медленнее, чем аналогичный модуль
ядра, но у нее есть много дополнительных особенностей. Она подробно
описана в соответствующих man-страницах, поэтому' мы не будем рассказы-
вать о ней так же детально, как о реализации РРР уровня ядра.
Программа ррр требует, чтобы в ядро было включено псевдоустройство
tun и существовали файлы /dev/tunO, /dev/tunl н т.д. Она конфигурируется
посредством файла ррр.сопГ; его образец расположен в каталоге /etc/ррр и
содержит примеры всех опций, которые могут когда-либо понадобиться
Существует также ряд вспомогательных файлов. Файл ppp.deny содержит
список пользователей (например, root и bin), которым запрещается вызывать
программу ррр. Файл ррр.shells включает список каталогов для всех доступных
интерпретаторов команд; программа ррр запрещает доступ в систему пользо-
вателям. чей интерпретатор не указан в списке.
Запись default в файле ppp.conf задает такие параметры, как скорость
передачи в бодах, файл устройства для модема, опции регистрации и порядок
подключения. Далее следуют записи для всех узлов, с которыми могут быть
установлены PPP-соединения, например:
allow user имя_лока.пьного_пользователя
netblazerBOO:
set phone номертелефона
set login "ABORT NOWsCARRIER TIMEOUT 5 ogin :—ogin : имя
word: пароль"
set timeout 120
delete ALL
add default HISADDR
В данном примере указывается пользователь, которому разрешается
вызывать программу ррр (ему не нужно регистрироваться под именем root),
номер телефона и сценарий регистрации (включая регистрационное имя и
пароль). В последних дву'х строках удаляются все существующие маршруты
и добавляется стандартный маршрут к PPP-серверу (скорее всего, серверу
провайдера).
PPP-модуль ядра использует демон pppd Его регистрационные файлы
также хранятся в каталоге /etc/ррр. основные из них — это options и ppp.deny
Они обычно служат в качестве дополнения к локальным файлам терминаль-
ного сервера на противоположном конце соединения Например, файл
36С
Чость II. Робото в сетях
options, netblazer содержит параметры конкретного устройства, а файл chat.net-
blazer — регистрационную информацию. Во FreeBSD имеются образцы
конфигурационных файлов для нескольких РРР-спенариев: они расположены
в каталоге /usr/share/examples.
Показанные ниже конфигурационные файлы описывают РРР-соединение
между домашним компьютером Эви Немет и университетом штата Колорадо.
Первый файл содержит глобальные параметры демона pppd. второй —
параметры подключения к древнему терминальному серверу Netblazer,
установленному на факультете вычислительной техники, а третий файл —
это диалоговый сценарий, осуществляющий регистрацию на сервере;
% cat /etc/ррр/option»
l Глобальные PPP-параметры
lock	# всегда блокировать используемое устройство
азупстпар 0x00000000
crtscts	* использовать аппаратное управление потоком
modem	# использовать управляющие сигналы модема
defaultroute	* добавить стандартный маршрут через РРР-интерфейс
mru 552	# MRU/MTU 512 (данные! * 40 (заголовок)
mtu 552
% cat /ate/ррр/©ptIona.netblazer
# Файл параметров конкретного РРР-соединения
120.136.196.47:128.138.243.167 #	локальный:удаленный	1Р-адрес
netmask 255.255.255.0	#	маска подсети
/dev/cuaa2	#	используется третий	последов,	порт
57600	#	скорость соединения	в бодах
«persist	#	пытаться повторно подключиться
# в случае неудачи
itholdoff 5	# ждать 5 секунд между попытками
connect "/usr/bin/chat -v -f /etc/ррр/chat.netblazer"
disconnect "/etc/ppp/hangup” I пытаться отсоединиться корректно
% cat /сtc/ppp/chet.netblazer
ABORT BUSY ABORT 'NO CARRIER'
TIMEOUT 5 OK-,,-,• ATZ 0K-+t+ATH2-OK ATDThомеp_телефона
TIMEOUT 60 CONNECT '’
TIMEOUT 10 ogxn:--ogln: Pevl
ssword: пароль
’Packet mode enabled'
Обычно можно просто отредактировать существующий диалоговый сце-
нарий, не вникая особенно в принципы его работы. В данном примере первая
строка описывает, в каких случаях сценарий должен завершиться. Вторая
строка инициализирует модем и вызывает набор номера. Следующие строки
задают периоды ожидания, а также передают имя пользователя и пароль.
В нашей системе регистрационные РРР-имена — это имена пользовате-
лей, перед которыми ставится префикс ‘Р‘. Так их легче запоминать.
Для запуска демона pppd необходимо задать такую команду:
% sudo pppd file /etc/ррр/options netblazer
13. Сети TCP/IP
3/1
Демону можно передавать аргументы в командной строке, а также
посредством файлов /etc/ppp/options, ~/.ррргс и /eta/ppp/options.tfie/wwftub-
ныйсервер.
Чтобы разорвать РРР-соединение, нужно просто уничтожить демон pppd:
% sudo kill 'cat /var/run/рррО.pid'
Если компьютер является портативным и периодически подключается к
сети посредством Ethernet-платы, а не протокола РРР, то перед запуском
демона pppd будет существовать стандартный маршрут через сетевой интер-
фейс Ethernet- К сожалению, демон pppd не умеет удалять этот маршрут и
устанавливать свой собственный, что логично было бы ожидать. Для
устранения этой проблемы нужно перед запуском демона удалять стандартный
маршрут. Мы рекомендуем написать маленький сценарий ррр.ир, осуществ-
ляющий эту задачу автоматически.
Вот как будет выглядеть конфигурация РРР-интерфейса и таблица
маршрутизации после установления РРР-соединения:
% ifconfig pppO
pppO : flags=8051<UP,POINTOPOINT, RUNNING,MULTICAST» mtu 552
inet 128.138.198.47 —> 128.138.243.167 netmask OxffffffOO
% netstat -nr
Routing cables
Internet:
Destination	Gateway	Flags	Refs	Use	Netif	Expire
default	128.138.243.167	UGSC	3	0	pppO	
127.0.0.1	127.0.0.1	UH	0	0	loO	
128.138.243.167	128.138.198.47	UH	4	0	pppO	
С помощью команды pppstats можно узнать статистику РРР-соединения:
% ppp a tats
IN	PACK	COMP	UNC	ERR	| OUT	PACK	COMP	UNC	NON-VJ
1647029	5101	4596	157	0	I	203582	5051	4566	210	275
В столбце comp отображается число пакетов, для которых применяется
сжатие TCP-заголовка, а в столбце UNC — соответственно число пакетов без
сжатия. Подробнее об этом можно узнать в документе RFC1144.
Особенности сетевого конфигурирования
Команда route во FreeBSD не понимает параметр, задающий число
переходов. Если же по ошибке указать его. команда воспримет это число
как сетевую маску. Таким образом, “безобидный" счетчик I будет проинтер-
претирован как маска 00.0.1, которая сделает все маршруты, включая
стандартный, совершенно бесполезными.
13.16.	Рекомендуемая литература
•	Stevens, W. Richard. TCP/IP Illustrated. Volume One: The Protocols. Reading.
MA: Addison-Wesley. 1994.
•	Wright, Gary R., and Stevens, W. Richard. TCP/IP Illustrated. Volume Two
The Implementation. Reading, MA: Addison-Wesley. 1995
Эти два тома представляют собой прекрасное, исчерпывающее руково-
дство по протоколам TCP/IP, хотя уже немного устарели.
36'Л
Чость И. Робото в сетях
•	Stevens, W. Richard. UNIX Network Programming. Prentice Hall. 1990.
•	Stevens, W. Richard. UNIX Network Programming, Volume 1: Networking APIs —
Sockels and XT1. Lipper Saddle River, NJ: Prentice Hall. 1997.
•	Stevens, W. Richard. UNIX Network Programming, Volume 2: interprocess
Communications. Upper Saddle River, NJ: Prentice Hall. 1998.
Данные книги являются библиями студентов, изучающих сетевое про-
граммирование. В первом издании описан только интерфейс сокетов
Беркли. Во втором издании рассмотрен также интерфейс STREAMS. Все
три книги написаны в четком и понятном стиле Рича Стивенса.
•	Tanenbaum. Andrew. Computer Networks, 3rd Edition. Upper Saddle River, NJ:
Prentice Hall. 1996.
Эта книга по-прежнему является классикой. Она содержит подробнейшее
описание физического и канального уровней стека сетевых протоколов.
Предыдущие издания были ориентированы на протоколы ISO, но
последнее издание охватывает современную архитектуру Internet.
•	Salus, Peter Н. Casting the Net. From ARPANET to INTERNET and Beyond.
Reading, MA: Addison-Wesley. 1995.
Захватывающая история о том. как сеть ARPANET превратилась в Internet.
Книга написана историком, который многие годы общался с профессио-
налами UNIX, поэтому кажется, будто ее писал один из них!
•	Comer, Douglas. Internetworking with TCP/IP Volume I: Principles, Protocols,
and Architectures, 4th Edition. Upper Saddle River. NJ: Prentice Hall. 2000.
Книги этого автора долгое время считались эталонным справочником по
протоколам TCP/IP. Новое издание содержит описание современных
сетевых технологий, а также семейства протоколов TCP/IP. Оно предна-
значено в качестве учебного пособия для студентов и является хорошим
источником справочного материала.
•	Hunt Craig. TCP/IP Network Administration, Second Edition. Sebastopol, CA:
O'Reilly & Associates. 1998
Данное издание ориентировано на администраторов UNIX-систем. По-
ловина книги посвящена протоколам TCP/IP, а остальной материал
касается средств UNIX более высокого уровня, таких как электронная
почта и удаленный доступ
е Sonnenreich, Wes, and Tom Yales. Building Linux and Open BSD Firewalls.
New York, NY; J.W. Wiley. 2000.
Это прекрасная небольшая книга, написанная понятным языком, с
наглядными примерами и хорошим чувством юмора. Единственный ее
недостаток в том, что автор утверждает, будто не следует применять
программу sudo для выполнения действий от имени суперпользователя.
Якобы программу неудобно использовать и она того не стоит. Мы
категорически не согласны с автором.
На Web-узле www.netscan.org ведется список “усилителей” атак типа
“smurf’ (т.е. систем, которые реагируют на широковещательные ICMP-паке-
ты). Можно ввести собственный сетевой IP-адрес, чтобы проверить его, при
условии, что маска подсети проходит на Гранине байтов. Если ваша сеть
имеется в списке, запретите направленное широковещание — станьте поря-
дочным гражданином глобальной сети!
Прекрасная коллекция документов, посвященных истории развития сети
Internet и различных ее технологий, находится по адресу www.isoc.org/in-
ternet/history.
Глово 13. Сети TCP/IP
363
Маршрутизация
В главе 13 кратко рассказывалось о маршрутизации IP-пакетов. В на-
стоящей главе мы подробнее изучим данный процесс и познакомимся с
различными протоколами, благодаря которым маршрутизаторы автоматически
находят наиболее приемлемые маршруты. Эти протоколы берут на себя
основную нагрузку по управлению таблицами маршрутизации, существенно
упрощая задачу администраторам. Они также позволяют быстро перенаправ-
лять трафик, если маршрутизатор или сетевой сегмент выходят из строя.
Важно отличать процесс реальной переадресации пакетов от процесса
управления таблицей маршрутизации, потому что в обоих случаях, как
правило, употребляют один и тот же термин “маршрутизация”. Переадресация
пакета — простая процедура, тогда как вычисление маршрута — довольно
сложный алгоритм. Мы познакомимся только с одноадресной маршрутиза-
цией, поскольку при многоадресной маршрутизации возникает целый ряд
новых проблем, рассмотреть которые не представляется возможным в данной
книге.
Почему-то считается, что !Р-маршрутизация — чрезвычайно сложная
тема, понятная только кучке длинноволосых хиппи, обитающих в подземельях
университета Беркли. На самом деле это не так, достаточно лишь вспомнить,
что в ее основе лежит принцип нахождения “следующего перехода". В любой
конкретной точке требуется определить следующий узел нли маршрутизатор,
куда будет отправлен пакет на пути к пункту своего назначения. Это
полностью отличается от многих старых протоколов, где перед отправкой
пакета в сеть требовалось узнать его точный маршрут. Данный подход
известен как направленная маршрутизация’.
Можно задавать точный путь следования LP-пакетов, но это обычно не делается. Из
соображений безопасности подобная возможность чаше всего оказывается недоступной.
36-1
Чость II. Робото в сетях
14.1, Подробнее о маршрутизации пакетов
Прежде чем приступать к изучению алгоритмов маршрутизации, рассмот-
рим подробнее, как используются маршрутные таблицы. Предположим, сеть
имеет топологию, изображенную на рис. А.
Рис. А. Пример сети
Маршрутизатор Ml связывает между собой два Ethcrnet-сегмента, а
маршрутизатор М2 соединяет один из сегментов с внешним миром (считаем,
что Ml и М2 — это UNIX-компьютеры, а не выделенные маршрутизаторы).
Проверим, как выглядят таблицы маршрутизации. Вот таблица узла А:
А% netstat -rn
Routing tables
Destination
127.0.0.1
199.165.145.0
default
Gateway
127.0.0.1
199.165.145.17
199.165.145.24
Flags Refs
UH	6
U	5
UG	2
Uee	If
563131	loO
2845294	leO
168589	leO
Узел А имеет самую простую конфигурацию среди всех четырех машин.
Первые два маршрута описывают собственные сетевые интерфейсы узла. Они
необходимы, чтобы пакеты, направляемые в непосредственно подключенные
сети, не маршрутизировались особым образом. Устройство 1е0 — это
Ethernet-плата* ухла А, а 1с0 — интерфейс обратной связи (виртуальный
сетевой интерфейс, эмулируемый программным способом в ядре). Обычно
эти записи автоматически добавляются командой ifeonfig при конфигуриро-
вании сетевого интерфейса
Подробнее о команде ifeonfig можно узнать в параграфе 13.10.
Как указывает флаг Н, первая запись обозначает узловой маршрут,
связанный с одним конкретным IP-адресом, а не всей сетью. Данный маршрут
можно сделать сетевым, но это не имеет особого смысла, так как в сети
обратной связи существует один-единственный IP-адрес В таблице маршру-
тизации будет сделано всего одно изменение: в столбце destination
появится адрес 127.0.0.0. а не 127.0.0.1 (соответственно, флаг Н исчезнет).
Существенной разницы между узловым и сетевым маршрутом нет. Когда
ядро ишет адреса в таблице маршрутизации, оно обрабатывает их одинаково.
Отличается лишь длина неявной маски.
Имена интерфейсов будут отличаться в зависимости от конкретной операционной системы
и аппаратной платформы.
Глово 14 Моршрутизоция
365
О сетевых часках рассказывалось в параграфе 13.4.
Стандартный маршрут узла А залает перенаправление всех пакетов, не
адресованных локальному компьютеру или сети, на маршрутизатор МI. адрес
которого б данной сети — 199.165.145.24. Флаг G указывает на то, что данный
маршрут ведет к шлюзу, а не к одному из локальных интерфейсов узла Л
Шлюзы должны находиться на расстоянии одного перехода.
Предположим теперь, что узел А посылает пакет узлу Б, адрес которого —
199.165.146.4. 1Р-подсистема ищет маршрут к указанной сети 199.165.146 и,
не найдя такового, отправляет пакет по стандартному маршруту, т.е.
маршрутизатору Ml На рис. Б приведен вид пакета, прохоляшего по сети
Ethernet (в заголовке Ethernet указаны МАС-адреса интерфейсов А и Ml в
сети 145).
Сравнение IP- и Ethemel-adpecoe производилось в параграфе 13.3.
Заголовок Ethernet	Заголовок IP	Заголовок UDP и данные
Or А Кому: М1 Тип: IP	Or 189.165.145.17 Кому; 199.16S.146.4 Тип; UPD	11001010110101011101010110110101 01110110110111010100010100100010 О1011111011010101010011101010000
UDP-пакет
IP-пакет
Ettiemet-кадр
Рис. Б. Ethernet-покет
Целевой аппаратный Ethernet-адрес обозначает маршрутизатор Ml, ио
IP-пакет, скрытый в Ethernet-кадре, не содержит никаких упоминаний о
маршрутизаторе. Когда маршрутизатор проверяет поступивший пакет, он
замечает, что его пелевой IP-адрес не совпадает с аппаратным. Тогда он
просматривает собственную таблицу маршрутизации, чтобы узнать, как
переслать пакет узлу Б, не переписывая его заголовок (необходимо, чтобы
отправителем пакета оставался узел А).
Так выглядит таблица маршрутизации узла М1:
Rl% netstiat -rn
Routing tables
Destination	Gateway	Flags Refs	Use	If
127.0.0.1	127.0.0.1	UH	10	10233	loO
199.165.146.0	199.165.146.1	U	15	4529	lei
199.165.145.0	199.165.145.24	U	0	121	leO
default	199.165.146.3	UG	4	16S589	lei
первой
Эта таблица похожа на таблицу для
узла А. за исключением того, что в
присутствуют два физических сетевых интерфейса. Стандартный
маршрут в данном случае ведет к узлу М2, поскольку через него осуществ-
ляется выход в Internet. Пакеты, адресованные любой из сетей 199.165,
доставляются напрямую.
Узел Б подобно узлу А имеет один реальный сетевой интерфейс. Но для
корректного функционирования ему нужен дополнительный маршрут, по-
скольку он напрямую подключен сразу к двум маршрутизаторам. Трафик для
366
Чость II Робота в сетях
сети 199.165.145 должен проходить через узел Ml, а весь остальной трафик —
направляться в Internet через узел М2.
В% netetat -гл
Routing tables
Destination
127.0.0.1
199.165.146.0
199.165.145.0
default
Gateway
127.0.0.1
199.165.146.4
199.165.146.1
199.165.146.3
Flags Refs
UH	2
U	15
UG	0
UG	4
Use	If
1543	loO
4529	leO
121	leO
168569	leO
Можно сконфигурировать узел Б так, чтобы изначально он знал только
об одном шлюзе, полагаясь на помощь переадресуюших ICMP-директив для
устранения избыточных переходов Ниже показан один из примеров началь-
ной конфигурации.
В% netetat -rn
Routing tables
Destination
127.0.0.1
199.165.146.0
default
Gateway
127.0.0.1
199.165.146.4
199.165.146.3
Flags Refs
UH	2
U	15
UG	4
Use	If
1543	loO
4529	leO
1685S9	leO
Теперь, если узел Б посылает пакет узлу А (199.165.145.17), прямой
маршрут найден не будет, и пакет отправится на узел М2. Тот, будучи
маршрутизатором, имеет полную информацию о состоянии сети, поэтому не
только пошлет пакет узлу М1. но также направит узлу Б 1СМР-сообшение,
в соответствии с которым узел Б добавит в таблицу маршрутизации прямой
путь к узлу А.
199.165.145.17 199.165.146.1 UGHD 0	1	1е0
Благодаря этому маршруту весь будущий трафик, адресованный узлу А,
будет идти непосредственно через маршрутизатор М1. Однако данное
изменение ие затрагивает трафик к другим узлам в сети 145. Для них нужно
получить отдельные уведомления от маршрутизатора М2.
Некоторые администраторы выбирают для своих систем переацресуюшие
ICMP-директивы в качестве основного ’‘протокола" маршрутизации, думая,
то подобный подход обеспечит большую динамичность. К сожалению, если
информация, касающаяся переадресованного маршрута, изменяется, нужно
либо удалить маршрут из таблицы вручную, либо перезагрузить систему. Из-за
этой, а также ряда других проблем (увеличение сетевого трафика, возрастание
нагрузки на маршрутизатор М2, хаос в таблице маршрутизации, зависимость
от внешних серверов) мы не рекомендуем применять такой подход. В пра-
вильно сконфигурированной сети переадресованные маршруты не должны
появляться в таблице маршрутизации.
14.2.
Демоны и протоколы маршрутизации
В простейших сетях, подобно той. что представлена на рис. А. имеет
смысл настраивать маршрутизацию вручную. Но начиная с определенного
момента сеть становится слишком сложной для подобного администрирова-
ния. Вместо того чтобы явно сообщать каждому компьютеру каждой подсети,
как находить другие компьютеры и сети, лучше заставить сами компьютеры
отыскивать эту информацию. Данная задача возлагается на протоколы
маршрутизации и демоны, которые их реализуют.
Глово 14. Моршрутизоция
с 67
Динамические протоколы имеют то преимущество над системами стати-
ческой маршрутизации, что они позволяют быстро адаптироваться к изме-
нениям в сетевой топологии. Когда пропадает канал, демоны быстро находят
альтернативные маршруты и сообщают о них в сети, связанные с этим
каналом.
Демоны маршрутизации собирают информацию из трех источников:
конфигурационных файлов, существующих таблиц маршрутизации и “родст-
венных” демонов других систем. Данные объединяются, и вычисляется
оптимальный набор маршрутов, после чего новые маршруты записываются
обратно в системную таблицу (и при необходимости посылаются другим
системам посредством протоколов маршрутизации). Состояние сети время от
времени меняется, поэтому демоны должны периодически опрашивать друг
друга, чтобы убедиться в актуальности имеющейся у них информации.
Конкретный алгоритм вычисления маршрутов зависит от протокола
Протоколы бывают двух типов: дистанционно-векторные и топологические.
Дистанционно-векторные протоколы
В основе дистанционно-векторных протоколов лежит следующая идея:
“Если маршрутизатор X расположен на расстоянии пяти переходов от сети
Y и является моим соседом, то я нахожусь в шести переходах от данной
сети". Компьютер, работающий по такому протоколу, объявляет о том, как
далеко, по его мнению, находятся от него известные ему сети. Если соседние
компьютеры не знают лучших маршрутов к этим сетям, они помечают данный
компьютер как стандартный шлюз. В противном случае они просто игнори-
руют это уведомление . Предполагается, что со временем таблицы маршру-
тизации придут в стабильное состояние.
Как упростилась бы маршрутизация, если бы все работало так, как
задумано! К сожалению, описанный алгоритм не лучшим образом справляется
с изменениями топологии. Иногда стабилизация вообще ие наступает
вследствие возникновения бесконечных циклов (например, маршрутизатор X
получает информацию от маршрутизатора Y и посылает ее маршрутизатору
Z, который возвращает ее маршрутизатору Y). На практике приходится
вводить сложные эвристические правила или задавать произвольные ограни-
чения. К примеру, в RIP (Routing Information Protocol — протокол маршрут-
ной информации) считается, что любая сеть, находящаяся на расстоянии
более 15-ти переходов, недоступна.
Даже в обычных ситуациях может потребоваться слишком много циклов
обновлений, чтобы все маршрутизаторы перешли в стабильное состояние.
Следовательно, для предотвращения зацикливания необходимо сделать пе-
риоды обновлений очень короткими, а это, в свою очередь, ведет к тому,
что дистанционно-векторные протоколы оказываются слишком “словоохот-
ливыми” Например, протокол RIP требует, чтобы маршрутизаторы осуще-
ствляли широковещательную рассылку имеющейся у них информации каждые
30 секунд. В протоколах IGRP и EIGRP обновления посылаются каждые 90
секунд.
В противоположность этому, в BGP (Border Gateway Protocol — погра-
ничный межсетевой протокол) вся таблица посылается один раз, после чего
Не все так просто, поскольку определенные изменения топологии могут приводить к
удлинению существующих маршрутов. Некоторые дистанционно-векторные протоколы,
например EJGRP, хранят информацию обо всех возможных маршрутах, чтобы на крайний
случай был “план отступления”. Впрочем, конкретные детали не так уж важны.
368
Чость II. Робото в сетях
передаются только изменения, по мере того как они происходят. Такая
оптимизация позволяет существенно снизить “переговорный" трафик (боль-
шей частью ненужный).
В табл. 14.1 перечислены дистанционно-векторные протоколы, широко
используемые сегодня.
Тоблицо 14.1. Ноиболее роспростроненные дистанционно-векторные протоколы
	моршрутизоции
	у	ни»	П именение
RIP	Routing Information Protocol (протокол мар- Локальные сети шрутной информации)
IGRP	Interior Gateway Routing Protocol (протокол Некоторые гло- маршрутизации между внутренними шлюзами) бальные сети
EIGRP	Enhanced Interior Gateway Routing Protocol Глобальные сети, (улучшенный протокол маршрутизации между корпоративные внутренними шлюзами)	локальные сети
BGP	Border Gateway Protocol (пограничный межсе- Магистральные тевой протокол)	сети Internet
Топологические протоколы
Топологические протоколы, или протоколы состояния канала, распростра-
няют информацию в относительно необработанном виде. Записи выглядят
примерно так: “Маршрутизатор X является смежным по отношению к
маршрутизатору Y, и канал функционирует". Полный набор таких записей
образует карту сетевых связей, на основании которой каждый маршрутизатор
может построить свою собственную таблицу. Основное преимущество топо-
логических протоколов по сравнению с дистанционно-векторными заключа-
ется в способности быстро находить функционирующий маршрут в случае
краха. К издержкам относится необходимость хранения полной карты
соединений на каждом узле, для чего требуются дополнительные процессор-
ные мощности и память.
Поскольку процесс общения между' маршрутизаторами не является частью
алгоритма вычисления маршрута, появляется возможность реализовать топо-
логические протоколы так, чтобы не возникало циклов Изменения в
топологической базе данных распространяются по сети очень быстро, не
загружая ни канал, ни центральный процессор.
Топологические протоколы сложнее дистанпиопно-векторных, зато они
позволяют реализовать такие технологии, как маршрутизация на основании
запрашиваемого типа обслуживания (поле TOS IP-пакета) и предоставление
нескольких маршрутов к одному адресату. Ни одна из этих возможностей не
поддерживается в готовых UNIX-системах, и для их использования потребу-
ется покупать выделенные маршрутизаторы.
В табл. 14.2 перечислены популярные топологические протоколы
Таблица 14.2 Роспростроненные топологические протоколы моршрутизоции
rZC ту.	Погци незнание	П имеиение
OSPF	Open Shortest Path First (открытый про- Крупные сети токол первоочередного обнаружения кратчайших маршрутов)
ISIS	Intermediate System to Intermediate (практически не приме - System (протокол связи между лроме- няется)
жуточными системами)
Глава |4. Маршрутизация
369
Метрики кратчойшего пути
Чтобы протокол маршрутизации мог определить, какой путь к заданной
сети является кратчайшим, необходимо прежде всего прояснить, что значит
“кратчайший”. Это путь с наименьшим числом переходов? С наименьшим
временем задержки? С наименьшими финансовыми затратами?
Для целей маршрутизации качество канала определяется числом, назы-
ваемым метрикой стоимости. Путем сложения отдельных метрик вычисляется
общая стоимость маршрута. В простейших системах каждому каналу назна-
чается стоимость 1, в результате метрикой маршрута является число
переходов. Но любой из перечисленных выше критериев может стать
метрикой стоимости.
Знатоки сетей долго и упорно грудились нал тем, чтобы определение
такого понятия, как метрика стоимости, было максимально гибким, а
некоторые современные протоколы даже позволяют использовать разные
метрики для разных видов сетевого трафика. Тем не менее в 99% случаев иа
всю эту суету можно ие обращать внимания. Просто воспользуйтесь
стандартными метриками, принятыми в большинстве сетей.
Бывают ситуации, когда кратчайший физический маршрут* к адресату не
должен выбираться по умолчанию из политических соображений. В таких
случаях можно искусственно завысить стоимость критических каналов. Всю
остальную работу предоставьте демонам.
Внутренние и внешние протоколы
Автономная система — это группа сетей, находящихся под администра-
тивным или политическим контролем одного юридического липа. Это
довольно нечеткое определение. Реальные автономные системы могут пред-
ставлять собой как глобальные корпоративные сети, так и отдельные
университетские объединения. Все зависит от того, как осуществляется
маршрутизация. Основная тенденция заключается в том, чтобы сделать
автономную систему как можно более крупной. Это приводит к упрощению
администрирования и повышению эффективности маршрутизации.
Маршрутизация внутри автономной системы отличается от маршрутиза-
ции между такими системами. Протоколы второго типа (внешние) должны
уметь управлять множеством маршрутов к различным сетям и понимать тот
факт, что соседние маршрутизаторы находятся под контролем других людей.
Внешние протоколы не раскрывают топологию автономной системы, поэтому
в определенном смысле их можно рассматривать как второй уровень
маршрутизации, иа котором соединяются между' собой группы сетей, а ие
отдельные компьютеры.
На практике небольшим организациям редко требуется внешний прото-
кол, если только они не подключены к нескольким провайдерам одновре-
менно. При наличии нескольких провайдеров традиционное разделение иа
локальный домен и домен Intemei нарушается, поскольку маршрутизаторам
приходится определять, какой маршрут лучше всего подходит для данного
конкретного адреса. (Это не означает, что каждый маршрутизатор должен
знать всю необходимую информацию. Большинство узлов может по умолча-
нию направлять свои пакеты внутреннему шлюзу, осуществляющему основ-
ную работу.)
Внешние протоколы не сильно отличаются от своих внутренних аналогов,
но именно на последних мы сосредоточим внимание в данной главе, так как
они применяются гораздо чаше.
3/0
Чость II Работе в сетях
14.3.	Основные протоколы маршрутизации
В этом параграфе мы познакомимся с основными внутренними прото-
колами маршрутизации, узнаем их преимущества и недостатки.
RIP: протокол маршрутной информации
RIP (RFCI058) — это старый протокол компании Xerox, адаптированный
для IP-сетей. Он используется демоном routed и представляет собой простой
дистанционно-векторный протокол, метрикой стоимости в котором является
число переходов. Поскольку протокол R1P разрабатывался в те времена, когда
серверы стоили сотни тысяч долларов, а сети были относительно маленькими,
в нем предполагается, что все машины, находящиеся на расстоянии
пятнадцати и более переходов, недостижимы. По этой причине в крупных
локальных сетях с более чем пятнадцатью маршрутизаторами на одном пути
протокол RIP использовать нельзя.
Несмотря на то что вследствие расточительного использования широко-
вещательного режима протокол RIP стал настоящим “пожирателем” ресурсов,
он весьма эффективен при частых изменениях сети, а также в том случае,
когда неизвестна топология удаленных сетей. Однако после сбоя канала
стабилизация системы может занять довольно много времени.
Протокол R1P широко используется не на UNIX-платформах. Многие
устройства, включая сетевые принтеры и SNMP-компоненты, способны
принимать R1P-сообщения, узнавая о возможных шлюзах. Кроме того, почти
во всех UNIX-системах имеется демон routed, поэтому протокол RIP считается
“наименьшим обшим знаменателем” в большинстве систем. Как правило, он
применяется для маршрутизации в пределах локальной сети, тогда как
глобальную маршрутизацию осуществляют более мощные протоколы.
RIP-2: протокол моршрутной информоции, версия 2
RIP-2 — это улучшенная версия протокола RIP с поддержкой ряда
особенностей, отсутствующих в исходном варианте протокола. Самое важное
изменение заключается в том, что вместе с адресом следующего перехода
передается сетевая маска. Это упрощает управление сетями, где применяется
протокол CIDR. Была также предпринята попытка усилить безопасность
протокола R1P. но определение конкретной системы аутентификации остав-
лено для будущих разработок.
[у7! О протоколе CIDR говорилось в параграфе 13.4
Во многих системах демон routed выполняется с опцией -q (“бесшумный”
режим). В этом режиме он управляет таблицей маршрутизации и принимает
сообщения об изменении маршрутов, но самостоятельно не осуществляет
широковещательную рассылку имеющейся информации. Вычислением мар-
шрутов занимается более эффективный протокол, например OSPF. Найден-
ные маршруты преобразуются в RIP-сообшения и рассылаются клиентским
машинам. Демон routed, работающий в “бесшумном” режиме, поддерживается
почти повсеместно, поэтому большинство машин может пользоваться пре-
имуществами динамической маршрутизации, не требуя специального конфи-
гурирования.
Протокол RIP-2 имеет ряд особенностей, ориентированных на исполь-
зование в многопротокольной среде. Благодаря сообщениям об обновлении
следующего перехода широковещательные станции могут уведомлять о
Глово 14. Моршрутизоция
371
маршрутах, для которых они не являются шлюзами. Посредством специаль-
ных меток информация о маршрутах, обнаруженных внешними протоколами,
может распространяться через протокол RIP.
Маршрутизатор RIP-2 может работать в режиме совместимости, сохраняя
большинство новых особенностей протокола RIP-2, но в то же время
обслуживая и обычных R1P-клиентов. Предпочтительнее использовать про-
токол RIP-2, если он поддерживается в системе.
OSPF: открытый протокол первоочередного обнаружения
кратчайших маршрутов
Протокол OSPF является топологическим и определен в документе
RFC2328. Термин “первоочередное обнаружение кратчайших маршрутов”
обозначает специальный математический алгоритм, по которому вычисляются
маршруты; термин “открытый" — синоним слова “непатентованный”.
OSPF был первым топологическим протоколом, нашедшим широкое
применение, и до сих пор остается одним из самых популярных протоколов.
Своей популярностью он обязан поддержке со стороны демона многопрото-
кольной маршрутизации gated, о котором мы подробно поговорим ниже.
К сожалению, сам протокол очень сложен, поэтому имеет смысл применять
его только в крупных системах (где важна эффективность маршрутизации).
В спецификации протокола OSPF ничего не говорится о конкретных
метриках стоимости. Демон gated по умолчанию использует в качестве
метрики число переходов, как и маршрутизаторы Cisco. Последние можно
сконфигурировать так, чтобы метрикой была полоса пропускания.
OSPF — это протокол промышленного уровня, который эффективно
работает в крупных сетях со сложной топологией. По сравнению с RIP он
имеет ряд преимуществ, включая возможность выбора между несколькими
маршрутами, ведущими к одному адресату, и возможность разделения сети
иа сегменты, которые будут совместно использовать только высокоуровневые
данные маршрутизации.
IGRP и EIGRP: протоколы маршрутизоции между
внутренними шлюзами
IGRP и его преемник EIGRP — это патентованные протоколы, исполь-
зуемые только маршрутизаторами Cisco. Протокол IGRP был создан для
устранения некоторых недостатков протокола RIP еше в те времена, когда
не было таких стабильных протоколов, как OSPF. Протокол E1GRP
конфигурируется примерно так же, как и IGRP, хотя внутренне он реализован
совсем по-другому. Протокол IGRP понимает только маршрутные уведомле-
ния. в которых IP-адреса заданы в соответствии с традиционными границами
классов, тогда как EIGRP понимает произвольные маски CIDR.
Оба протокола являются дистанционно-векторными, но они спроектиро-
ваны так, чтобы избежать проблем зацикливания и стабилизации, свойствен-
ных другим аналогичным протоколам. С этой точки зрения протокол EIGRP
является образцом. Для большинства применений протоколы EIGRP и OSPF
обеспечивают равные функциональные возможности.
По нашему мнению, лучше придерживаться открытого, широко исполь-
зуемого протокола, каковым является OSPF. С ним многие работают, и
имеется ряд его реализаций.
372
Чость II Робота в сетях
IS IS: протокол связи между промежуточными системами
Протокол IS-IS является ответом на протокол OSPF со стороны
организации ISO. Первоначально он предназначался для маршрутизации в
рамках стека протоколов OS1, но впоследствии был расширен на стек TCP/IP.
Оба протокола — 1S-IS и OSPF — разрабатывались в начале 90-х гг.,
когда модель OSI была в моде и считалась стандартом. Благодаря усилиям
со стороны организации IETF протокол IS-IS нашел применение в сетях
TCP/IP. но со временем стал все сильнее уступать в популярности протоколу
OSPF и сегодня используется редко. Он отягощен множеством функциональ-
ных особенностей, свойственных модели OSI, поэтому лучше его избегать.
MOSPF, DVMRP и PIM: протоколы многоадресной
маршрутизации
MOSPF (Multicast OSPF — многоадресный протокол OSPF), DVMRP
(Distance Vector Multicast Routing Protocol — дистанционно-векторный про-
токол многоадресной маршрутизации) и PIM (Protocol Independent Multi-
cast — протокольно-независимая многоадресная маршрутизация) — это
протоколы, предназначенные для поддержки группового вещания в IP-
сетях — технологии, еще не нашедшей широкого применения. Информацию
об этих протоколах можно найти по адресу wv,w.cs.columbia.edu/~hgs/in-
ternct/mbone-faq. html.
Протокол обнаружения маршрутизаторов
Протокол обнаружения маршрутизаторов использует 1СМР-сообшения,
посылаемые по групповому IP-адресу 224.0.0.1, для обмена информацией о
других маршрутизаторах в сети. К сожалению, не все маршрутизаторы в
настоящее время умеют рассылать такие сообщения, и не все компьютеры
могут их принимать. Надеемся, что когда-нибудь этот протокол станет более
популярным.
14.4.	Демон routed: стандартный демон маршрутизации
Демон routed в течение длительного времени был стандартным демоном
маршрутизации UNIX, и его до сих пор включают в большинство системных
дистрибутивов’. Он признает только протокол RIP, но иногда поддерживается
также RIP-2. Если нужно работать по протоколу RIP-2, а демон routed его
не понимает, всегда можно воспользоваться демоном gated (реальная потреб-
ность в этом возникает, только когда имеются подсети с масками разной
длины).
Демон routed может работать в режиме сервера (-s) или в "бесшумном”
режиме (-q). В обоих режимах принимаются широковещательные сообщения,
но свою собственную информацию рассылают лишь серверы. Вообще говоря,
серверами должны быть только машины с несколькими интерфейсами. Если
не указана ни опция -s, ни -q, то демон routed работает в “бесшумном”
режиме при наличии одного интерфейса и в режиме сервера — при наличии
нескольких. Во многих системах, однако, это правило не действует”.
•	В некоторых версиях UNIX (например, в HP-UX) стандартным является демон gated.
•	• Демон routed неправильно себя ведет во многих системах. Один из наших рецензентов даже
сказал: “Этому демону просто нельзя доверять”.
Глово 14. Моршрутизоция
373
Демон добавляет обнаруженные маршруты в таблицу ядра. Все маршруты
должны быть доступны как минимум каждые четыре минуты, иначе они
будут удалены. Правда, это не относится к статическим маршрутам,
добавляемым с помощью команды route.
0 О команде route рассказывалось в параграфе 13.10.
Для отладки подсистемы маршрутизации можно воспользоваться коман-
дой routed -t. Опция -t заставляет демон работать в интерактивном режиме
и отображать все посланные и полученные пакеты.
Демой routed, как правило, выявляет маршрутную информацию динами-
чески и не требует конфигурирования. Если же в системе есть шлюзы в
Internet или в другие автономные системы, то, вероятно, понадобятся
некоторые дополнительные операции, для того чтобы заставить эти каналы
работать с демоном routed
Когда имеется всего один выходной шлюз, можно объявить его стандарт-
ным глобальным маршрутом; для этого нужно запустить на нем демон routed
с флагом -g. Это аналогично заданию стандартного маршрута на одиночной
машине, ио в данном случае он распространяется на всю сеть.
Второй вариант работы со шлюзами — описать их в файле /etc/gateways,
к которому демон routed обращается при запуске. Однако в наши дни со
статическими маршрутами удобнее работать посредством демона gated.
14.5.	Демон gated: более удачный демон маршрутизации
Демон gated — это базовый командный процессор маршрутизации,
позволяющий одновременно использовать различные маршрутные протоколы.
Под его контролем находятся маршруты, о которых были получены уведом-
ления, а также широковещательные адреса, политики безопасности и метрики
стоимости. Он разрешает нескольким протоколам использовать одни и те же
маршруты, позволяя тем самым создавать шлюзы между сетями, в которых
приняты разные системы маршрутизации. Наконец, демон gated имеет один
из самых удобных интерфейсов среди всего административного ПО, что также
можно сказать и о формате его конфигурационного файла.
0 Демон gated можно получить на Web-узле www.,gated.org.
В разработку’ демона gated внесли свой вклад многие люди. Изначально
работа координировалась университетом Корнелла, а сам демон распростра-
нялся бесплатно. Но в 1992 г. он был приватизирован и перешел в ведение
консорциума Merit GateD. Текущие версии демона доступны только членам
консорциума. Таковым может стать каждый, но, во-первых, для этого
требуется принять условия лицензионного соглашения, а, во-вторых, членство
является бесплатным лишь для пользователей из научной среды.
Конечно, определение “только для академического и научно-исследова-
тельского использования” является довольно широким, но мы советуем
избегать бюрократической “трясины”, в которой увяз демон gated. Последняя
его общедоступная версия — номер 3 — работает вполне успешно. На момент
написания книги самый свежий ее релиз имел номер 3.5.10, именно его мы
и опишем ниже.
Демон gated поддерживает протоколы RIP (обе версии), OSPF и IS IS
для внутренней маршрутизации, EGP и BGP — для внешней По историче-
ским причинам предусмотрена поддержка старого протокола HELLO
374
Чость II. Роботе в сетях
В табл 14.3 представлены данные о поддержке демонов routed н gated в
наших тестовых системах. Текущая версия демона gated компилируется
практически на всех распространенных системах, поэтому их легко обновлять.
Таблице 14.3. Поддержке демонов маршрутизации в тестовых системах
Система	routed?	gated?
Solaris	Д»	Нет
HP-UX	Her	3.5 Beta 3
Red Hat	Да	3.5.10
FreeBSD	Да	3.5.11
Управление начальным запуском и параметрами демона
Обычно демон gated запускается на этапе начальной загрузки без
аргументов. Способ запуска зависит от системы (подробнее об этом
рассказывается в параграфе 14.6, нужную информацию можно также найти
в главе 2).
Демон берет свои инструкции из единственного конфигурационного
файла По умолчанию он называется /elc/gated.conf, но благодаря спениаль
ному флагу командной строки можно задать другой файл После запуска
демона управлять им можно посредством команды gdc, которая инсталлиру-
ется вместе с ним. Как правило, она имеет такой формат:
gdc инструкция
Ниже дан список наиболее распространенных инструкций.
interface	Сообщает демону о необходимости повторно просмотреть список активных сетевых интерфейсов ядра. Демон сам делает это периодиче- ски, но, если конфигурации какого-нибудь интерфейса только что изменилась, можно запросить немедленное обновление
recoofig	Заставляет демон повторно прочитать свой конфшу рационный файл
checkconf	Осуществляется синтаксический анализ конфигурационного файла и поиск в нем ошибок, но демону не сообщается о необходимости загрузки файла
toggletrace	Запуск или останов режима регистрации
stop	Завершение работы демона; по возможности осуществляется корректное завершение, но в случае необходимости демон останавливается прину- дительно
start	Запуск демона, если он еще нс выполняется
restart	Уничтожение демона и повторный его запуск; эквивалентно инструкции stop, за которой следует инструкция start
Трассировке
Демон gated может выполняться в режиме отладки (трассировки), в
котором все действия регистрируются в журнальном файле. Этот режим очень
удобен, когда создается новый конфигурационный файл. Кроме того, в
журнальном файле фиксируются все обновления маршрутов.
Когда включены некоторые опции трассировки, журнальный файл может
очень быстро разрастаться, поэтому его нужно периодически считать и
Глово 14 Моршрутизоция
375
формировать заново. Команда gdc toggletrace закрывает журнальный файл,
чтобы его можно было переименовать или очистить. Следующая команда gdc
toggietrace опять включит режим регистрации.
Опции трассировки могут задаваться в конфигурационном файле или в
строке запуска демона (перед опциями должен стоять флаг -t. перед именем
журнального файла ничего указывать не нужно). В конфигурационном файле
можно задавать различные опции для каждого конкретного протокола. Опции,
указываемые в командной строке, являются глобальными. Ниже перечислены
наиболее полезные опции.
аП	Включение всех опций трассировки
normal Трассировка обычных событий; необычные события регистрируются всегда
policy Отслеживание того, каким образом административные правила безопасно-
сти влияют иа распространение маршрутов
route Трассировка изменений в таблице маршрутизации
general Включение опций normal и route
Есть еше более детальный уровень отладки, позволяющий заносить в
журнальный файл отдельные сетевые пакеты. Но режим трассировки пакетов
включается только в конфигурационном файле, а не в командной строке.
Конфигурационный файл
В отличие от многих административных утилит UNIX, по умолчанию
демон gated работает достаточно хорошо. У него имеются сотни опций, но
для простейших сетей требуется лишь несколько строк конфигурационного
файла. Поэтому, читая далее настоящую главу, а также документацию,
помните, что большинство опций демона будут неактуальными в конкретной
системе.
Ниже описаны самые основные параметры конфигурации демона gated.
Синтаксис многих из них дан в усеченном виде — указаны только те
компоненты, о которых мы хотим поговорить. Если читателям кажется, что
должны существовать дополнительные компоненты, то, возможно, так оно и
есть, они просто не показаны. Подробности можно узнать в документации
по демону gated.
В документации объясняется формат конфигурационного файла, но не
говорится о сложных вопросах маршрутизации. Если у читателей возникнет
необходимость разобраться в назначении той или иной опции, советуем
обратиться к списку литературы, представленному в параграфе 14.9.
Конфигурационный файл состоит из набора инструкций, разделенных
символами точки с запятой. Лексемы разделяются пробельными символами,
к которым относится также символ новой строки. Иногда для группировки
употребляются фигурные скобки.
Имеется несколько классов инструкций. Инструкции каждого типа
должны размешаться рядом в конфигурационном файле, а секции следует
располагать в таком порядке:
•	опции и определения (включая объявления сетевых интерфейсов);
•	конфигурационные настройки отдельных протоколов;
•	статические маршруты;
•	параметры импорта, экспорта и агрегации.
Допускаются пустые секции.
376
Чость II. Роботе в сетях
Опции трассировки могут находиться где угодно. Если они стоят в
фигурных скобках, то относятся только к контексту конфигурируемого
параметра или протокола. Такие опции задаются с помощью инструкции
traceoptions:
traceoptiona I "журнальный_файл" [replace] [size размер[kIm]
files число]] опции_трассировкм
[except спции_трассировки];
Аргумент журналъный-файл — это имя файла, в котором сохраняются
результаты трассировки. Если указано ключевое слово replace, файл будет
очищаться при каждом запуске демона (по умолчанию информация добав-
ляется в конец файла). Аргумент размер задает максимальный размер
журнального файла в кило- или мегабайтах. Когда файл становится слишком
большим, он очищается и все старые файлы подвергаются переименованию:
журнальныи_файлЛ, журналъный_файл.2 и т.д. вплоть до файла с номером,
заданным аргументом число. Если указано предложение size, должно обяза-
тельно присутствовать и предложение files.
Возможные опции трассировки были перечислены выше. Поддерживается
также ряд дополнительных опций.
Ниже приведена инструкция, создающая журнальный файл /usr/lo-
cal/etc/gated.log, предельный размер которого — 1 Мбайт, число сохраняемых
версий — 3, и все возможные опции трассировки включены:
traceoptions "/usr/local/etc/gaced.log" replace size Im files 3 all;
Задание конфигурационных параметров
Формат задания конфигурационных параметров таков:
options [nosend] [noresolv] [syslog [upto] уровеньрегистрации];
Аргументы имеют следующий смысл:
nosend	Запрещает демону посылать любые пакеты. Эта опция полезна при
отладке, так как можно попросить демон обрабатывать информацию,
поступающую от других маршрутизаторов, но самому не взаимодей-
ствовать с ними
noresolv Запрещает демону использовать базу данных DNS для преобразования
имен компьютеров в IP-адреса. DNS-запросы потерпят неудачу, если
для их обработки недостаточно маршрутной информации, что приведет
к возникновению взаимоблокировки. Мы советуем не указывать имена
компьютеров в какой бы то ни было сетевой конфигурации — данная
опция позволяет реализовать подобную политику
syslog	Определяет, какой объем информации регистрируется через систему
Syslog. Эта опция бесполезна, если в организации не используется
система Syslog Доступные уровни регистрации можно узнать на
man-странице syslogtnask. По умолчанию принята опция syslog upto info
Пример
options noresolv;
Определение сетевых интерфейсов
Свойства сетевого интерфейса задаются посредством инструкции inter-
faces, формат которой имеет вид:
interfaces [
options [strictinterfaces]:
Глово 14. Моршрутизсция
377
define адрес [broadcast адрес] I [pointtopoint адрес];
interface списокинтерфейсов [preference приоритет] [passive]
[simplex];
[netmask маска] [multicast];
I;
Может быть несколько инструкций opticas, interface или define либо ни
одной. То же самое справедливо в отношении большинства инструкции
конфигурационного файла.
Опция strictinterfaces делает нелегальной ссылку из конфигурационного
файла на интерфейс, который на момент запуска не зарегистрирован в ядре
и не упомянут в инструкции define. Подобная ссылка всегда является
ошибкой, но при наличии опции strictinterfaces она становится не фатальной.
Инструкция define описывает сетевой интерфейс, который может отсут-
ствовать на момент запуска демона. Обычно указываются коммутируемые
каналы и платы PCMCIA.
Инструкция interface определяет параметры конкретного интерфейса или
набора интерфейсов. В качестве имени может использоваться реальное имя
интерфейса, такое как deO или lei, обобщенное имя, например de или 1е
(ссылается на все экземпляры интерфейсов данного типа), доменное имя.
IP-адрес или ключевое слово аП.
Если интерфейс объявлен с ключевым словом passive, маршруты через
него будут существовать даже в том случае, когда сам интерфейс не
подключен. Ключевое слово simplex указывает на то, что интерфейс не должен
принимать свои собственные широковещательные пакеты. Обычно демон
gated самостоятельно выполняет подобного рода конфигурирование, но в
некоторых системах его нужно задавать явно.
Предложение preferences требует более подробного пояснения. Поскольку
протоколы маршрутизации работают по-разному и используют различные
метрики стоимости для определения “кратчайшего" пути, нет гарантии, что
любые два протокола смогут договориться о том, какой маршрут наилучший.
Если результаты, полученные с помошью разных протоколов, оказываются
неодинаковыми, необходимо на административном уровне решить, какие
маршруты следует занести в таблицу ядра и послать другим маршрутизаторам.
Для реализации такой политики можно посредством демона gated
назначить каждому маршруту числовой приоритет. Когда возникает конфликт
двух маршрутов, выбирается тот. приоритет которого наименьший.
Значения приоритетов могут поступать из самых разных источников.
У каждого протокола маршрутизации есть свой внутренний приоритет.
Приоритеты можно также назначать сетевым интерфейсам и удаленным
шлюзам Поскольку' каждый маршрут соответствует и определенному прото-
колу. и сетевому интерфейсу, и удаленному шлюзу, имеется несколько
возможных приоритетов. Демон gated выбирает среди них наименьший.
Обычно маршруты к непосредственно подключенным сетям имеют
приоритет 0. Если необходимо предпочесть один интерфейс другому, можно
воспользоваться предложением preference для расстановки приоритетов.
В табл. 14.4 перечислены некоторые стандартные приоритеты, признаваемые
демоном gated
В следующем примере интерфейс led объявляется пассивным, т.е. через
него не будет распространяться маршрутная информация:
interface (
interface 1е0 passive;
I;
378
Чость II Роботе в сетях
Тоблицо 14.4. Стандортные приоритеты маршрутов
Источник маршрутной информации	Приоритет
Маршруты к непосредственно подключенным сетям Маршруты, полученные с помощью протокола OSPF	0 10
Переадресуюшие директивы ICMP	30
Статические маршруты, определенные внешне Статические маршруты, заданные в файле gated.сопГ	40 60
Маршруты, полученные посредством протокола RIP Маршруты между РРР-интсрфейсами Маршруты через интерфейсы, которые не работают	100 но 120
Другие определения
В секции определений можно задавать ряд других глобальных параметров,
например:
routeгid узел;
Инструкция routerid задает идентификатор маршрутизатора, который
используется протоколами BGP и OSPF. Он должен быть представлен в
формате ГР-адреса и по умолчанию соответствует адресу первого физического
интерфейса машины. Это значение важно для протоколов, которые им
пользуются. Другие маршрутизаторы могут явно ссылаться на него в своих
конфигурационных файлах,
martians {
hose узел [allow];
сеть [allow] [exact I refines];
сеть mask маска [allow] [exact I refines];
сеть masklen число [allow] [exact I refines];
default [allow];
>;
“Марсианские" маршруты — это маршруты к адресатам, которых нужно
игнорировать. В сети могут существовать неправильно сконфигурированные
маршрутизаторы, осуществляющие широковещательную рассылку' маршрутов
к фиктивным адресатам Помимо этого может потребоваться просто исклю-
чить некоторые записи из таблицы маршрутизации. Любой маршрут к
адресату, указанному в инструкции martians. игнорируется демоном gated.
С каждым пунктом маршрутизации связаны адрес и сетевая маска.
Различные варианты инструкции martians представляют собой различные
способы задания пары адрес/маска.
В предложениях mask и masklen оба значения задаются явно. Если маска
не указана, она вычисляется на основании класса адреса.
Ключевые слова exact и refines определяют два способа сопоставления
адресов, хотя в действительности их три: если ни одно из ключевых слов не
задано, целевая маска игнорируется. До тех пор пока часть целевого адреса,
покрываемая указанной в инструкции маской, совпадает с указанным там же
адресом, адресат считается “марсианином”.
При наличии ключевого слова exact целевой адрес и маска должны в
точности соответствовать значениям, приведенным в инструкции, чтобы
Глово 14. Моршрутизоций
379
адресат считался “марсианином”. Точное совпадение определяет выбор самой
сети, но не ее подсетей или надсетей.
При наличии ключевого слова refines целевая маска должна быть длиннее,
чем та, что указана в инструкции. В подобном случае адреса сравниваются
обычным способом (с использованием маски из инструкции). Это эквива-
лентно выбору подсетей, а не самой сети.
Записи
host узел;
default;
можно представить так:
узел mask 255.255.255.255 exact;
О.О.О.О mas к 0.О.О.О exact;
Ключевое слово allow разрешает адрес, запрещенный ранее более обшей
спецификацией. Например:
martians (
128.138.0.0 mask 255.255.0.0;
128.138.145.0 mask 255.255.255.0 allow;
1;
В данной конфигурации запрещаются все маршруты к сети 128.138 класса
В, однако допускается маршрут в подсеть 128.138.145. Более конкретное
правило всегда имеет приоритет.
Конфигурирование протокола RIP
Обе версии протокола R1P конфигурируются посредством инструкции rip:
rip yes I по I on | off [{
broadcast;
nobroadcast;
preference приоритет;
defaultmetric метрика;
interface список_интерфейсов
[noripin | ripin] [noripout I ripout]
[version 1] I [version 2 [multicast I broadcast]];
trusredgateways спжок_шлюзов:
sourcegateways список_шлюэов;
traceoptions [packets [ request I response [detail]];
И;
Ключевые слова yes и по являются синонимами слов on и off. Протокол
RIP по умолчанию разрешен. Если нужно запретить его, включите такую
запись:
rip по;
Опции broadcast и nobroadcast аналогичны флагам -s и -q демона routed
Опция broadcast заставляет лемон рассылать RIP-обновления даже тогда, когда
компьютер подключен всего к одной сети. Опция nobroadcast запрещает
посылать любые RIP-обновления.
Предложение defaultmetric назначает указанную метрику стоимости мар-
шрутам, которые были получены от других протоколов, но повторно
рассылаются средствами R1P. Вообще говоря, это не самый лучший способ
380
Чость 11. Робото в сетях
трансляции маршрутов, но элегантного решения просто не существует. По
умолчанию метрика задается равной 16, т.е. адресат недоступен, поэтому
маршруты других протоколов никогда не будут распространяться через RIP.
Если же нужно разрешить подобную рассылку, хорошим значением будет 10.
Имена интерфейсов назначаются так же, как и в инструкции interfaces,
описанной выше. Опция ripin задает прием RIP-обновлений для данного
интерфейса, а опция noripin запрещает их принимать. Опции ripout и noripout
являются аналогами опций broadcast и nobroadcast, используемыми для
отдельных интерфейсов. Опция noripout установлена по умолчанию для
РРР-соединениЙ.
Предложение version определяет, какую версию протокола — RIP-1 или
RIP-2 — следует применять для заданных интерфейсов. В случае протокола
RIP-2 по умолчанию осуществляется групповая, а не широковещательная
рассылка маршрутов, поэтому маршрутизаторы RIP-1 их не получат. Чтобы
отменить подобное поведение, задайте опцию broadcast.
По умолчанию демон gated принимает R1 P-обновления от каждого, кто
их посылает. Но, если присутствует список trustedgateways, допускаться будут
только сообщения от упомянутых в нем узлов. Список шлюзов представляет
собой перечень IP-адресов, разделенных пробелами.
В предложении sourcegateways перечислены узлы, RIP-обновления к
которым должны посылаться напрямую, а не широковещательно. Подобная
возможность используется для отправки разной маршрутной информации
заданным шлюзам и для доступа к маршрутизаторам в сети, где широкове-
щание не поддерживается или запрещено.
Опции трассировки устанавливаются посредством уже знакомой нам
инструкции traceoptions. Перечисленные здесь опции применимы только к
протоколу R1P. Опции request, response и packets задают регистрацию
полученных запросов, отправленных запросов и всех пакетов соответственно.
В последнем случае обычно записывается суммарная информация, но при
наличии опции detail формируется подробный отчет о каждом пакете.
Базовые сведения а протоколе OSPF
Прежде чем погружаться в детали конфигурирования протокола OSPF,
необходимо поговорить о двух особенностях протокола: областях маршрути-
зации и отмеченных маршрутизаторах.
Области маршрутизации
В крупных организациях обычно не требуется распространять всю
информацию о состоянии канала из одного конца сети в другой. Протокол
OSPF позволяет с целью уменьшения трафика, вызываемого обновлениями
маршрутов, объединять отдельные сети в области. Канальная информация
(т.е. данные о физической топологии сети) распространяется только в
пределах области. Сведения об областях передаются во внешний мир в виде
маршрутных резюме.
Каждая сеть может входить только в одну область. Маршрутизаторы
считаются членами всех областей, в которых у них есть сетевые интерфейсы.
Маршрутизатор, принадлежащий нескольким областям, называется погранич-
ным и отвечает за преобразование канальных записей в резюмирующие
сообщения.
Маршрутные резюме представляют собой совокупность маршрутов сле-
дующего вида: “Маршрутизатор X может посылать пакеты в сеть Y,
Глово 14. Моршрутизоция
381
находящуюся на расстоянии трех переходов” (где X — пограничным маршру-
тизатор). Маршрутизаторы, находящиеся за пределами данной области,
складывают метрику стоимости, заявленную в резюме, с вычисленной
стоимостью доступа к пограничному маршрутизатору и получают итоговую
стоимость пути в требуемую сеть.
Описанная схема напоминает завуалированный дистанционно-векторный
протокол, но есть два важных отличия. Во-первых, резюмирующие сообщения
распространяются точно в том виде, в котором они поступают от пограничных
маршрутизаторов. Маршрутизатор может подсчитать для себя, что если он
находится на расстоянии двух переходов от сети X. а сеть X расположена в
трех переходах от Y, то от него до Y — 5 переходов. Но он никогда не
откроет результаты своих вычислений другому маршрутизатору, а просто
передаст дальше исходный резюмирующий маршрут*.
Другое отличие от дистанционно-векторных протоколов заключается в
том, что протокол OSPF не пытается подстроиться под произвольные сетевые
топологии. Требуется, чтобы все области маршрутизации были логически
,смежными с центральной опорной областью, известной как область 0 (они
также могут быть смежными друг с другом). Маршрутные резюме могут
распространяться только от краевых областей в центральную и наоборот, но
не между краевыми областями**. Подобная простая двухуровневая иерархия
предотвращает возникновение циклов.
Если архитектура реальной сети не соответствует двухуровневой модели
OSPF, еше не все потеряно. Построить двухуровневую иерархию можно,
воспользовавшись имеющейся в OSPF концепцией “виртуальных каналов”
К сожалению, эта тема выходит га рамки нашей книги.
Отмеченные маршрутизаторы
Теоретически топологические протоколы распространяют маршрутную
информацию в виде записей, описывающих связи между маршрутизаторами,
например: *’ Маршрутизатор А граничит с маршрутизатором Б, а стоимость
соединения равна Г’. Если в сети 6 маршрутггзаторов, придется рассылать
30 различных канальных уведомлений, поскольку каждый маршрутизатор
граничит с пятью другими. Более того, все маршрутизаторы будут считать
друг друга соседями, и, таким образом, потребуется синхронизация их баз
данных.
Протокол OSPF сокращает объем рассылаемой информации, делая один
из маршрутизаторов в сети отмеченным . Отмеченный маршрутизатор
принимает канальные уведомления от всех других маршрутизаторов, а затем
рассылает итоговый отчет о собранных маршрутах.
Маршрутизаторы договариваются о том. кого из них выбрать иа
“руководящую должность”, основываясь на значениях приоритетов, заданных
административным путем. Маршрутизаторы с приоритетом 0 не могут быть
Это справедливо только внутри области. Если резюмирующее сообщение поступает в
смежную область, пограничный маршрутизатор производит перерасчет маршрутов относи-
тельно своего местоположения.
Это утверждение не совсем верно. Есть несколько специальных типов областей, например
NSSA (Not So Stubby Area — менее замкнутая область), предназначенных для переноса
маршрутной информации между краевыми областями. Но каждый маршрут, полученный
таким способом, особым образом помечается, чтобы случайно не возник цикл.
Правильнее вместо термина “сеть” употреблять термин "широковсщательньЕй домен”.
Имеется также механизм поддержки отмеченных маршрутизаторов в сетях, где не поддер-
живается широковещание.
382
Чость II. Роботе в сетях
отмеченными. Среди оставшихся победителем становится тот, у кого самый
высокий приоритет. Если таких маршрутизаторов несколько, выбор осуще-
ствляется псевдослучайным способом.
Аналогичным образом назначается резервный отмеченный маршрутиза-
тор. Каждый маршрутизатор в сети постоянно держит связь с обоими
отмеченными маршрутизаторами. Если центральный выходит из строя, его
место тут же занимает резервный, а на освободившуюся “должность"
проводятся новые выборы.
Отмеченные маршрутизаторы обрабатывают больший объем данных. Это
следует учитывать при их выборе.
Конфигурирование протокола OSPF
Настройка параметров протокола OSPF проводится с помощью инструк-
ции ospf:
ospf yes | no 1 on I off [{
defaults {
router-prio;
};
traceoptions опции_трассировки;
backbone I (area область) (
networks {
сеть [exact l refines] [restrict];
сеть mask маска [exact I refines] [restrict];
сеть masklen число [exact | refines] [restrict];
host узел [exact I refines] [restrict];
};
stubhosts [
узел cost стоимость;
I;
interface спмсок_интерфейсов [cost стоимость] {
enable I disable;
priority приоритет;
];
};
}];
Эта инструкция проше, чем кажется на первый взгляд. Ключевые слова
on, off, yes и по имеют очевидное значение. По умолчанию протокол OSPF
не используется.
Ключевое слово router-prio в разделе defaults указывает на то, что
маршрутный приоритет (применяется при выборе отмеченного маршрутиза-
тора) равен 1 для всех интерфейсов. При желании это значение можно
переопределить, описывая конкретный интерфейс. По умолчанию приоритет
равен 0, вследствие чего демон gated не может стать отмеченным маршрути-
затором какой бы то ни было сети.
Определение области начинается с ключевого слова backbone или area.
Необходимо, чтобы была одна такая инструкция для каждой области, членом
которой является маршрутизатор. В спецификации протокола OSPF сказано,
что опорная область должна быть областью 0, но демон gated требует
указывать ключевое слово backbone, а не area 0.
Аргумент область может быть задан в виде десятичного числа или
четырехбайтового числа в формате IP-адреса (например, 128.138.45.2). Демон
gated никогда не интерпретирует номер области как IP-адрес, но точечная
Глово 14. Моршрутизоии!
383
четырехбайтовая запись предусмотрена для того, чтобы области можно было
помечать IP-адресами основных маршрутизаторов или серверов.
В списке networks перечислены сети, входящие в область. Сети нужно
указывать только в конфигурационных файлах пограничных маршрутизаторов.
Спецификация адреса и сетевой маски дается так же, как и в рассмотренной
выше инструкции martians, за исключением того, что ключевое слово allow
отсутствует. Сети, помеченные ключевым словом restrict, ие включаются в
маршрутные резюме. Оии являются “секретными” и доступны только в
пределах данной области.
В списке stubhosts перечислены непосредственно подключенные узлы,
которые объявляются доступными через данный маршрутизатор и имеют
указанную стоимость (обычно 1). Обычно таким образом описываются РРР-
и SLIP-соединения.
Наконец, в списке interface указывается стоимость маршрута к каждой
подключенной сети (по умолчанию 1) и приоритет демона gated для нее
(используется при выборе отмеченного маршрутизатора). Если для интерфейса
задано ключевое слово disable, то через него не будет проходить OSPF-трафик.
Конфигурирование переадресующих ICMP-директив
Демон gated позволяет обеспечивать административный контроль над
маршрутами, найденными благодаря переадресующим ICMP-директивам
(см. параграф 13.5).
redirect уев I no | on | off [{
preference приоритет;
interface список_интерфейсов [noredirects] I [redirects];
trustedgateways спиаок_шлх>зов;
traceoptions опции_трассировки;
И?
Все опции должны быть уже знакомы читателям. Предложение preference
задает общий приоритет переадресованных маршрутов (по умолчанию 30, что
вполне приемлемо). Опции redirects и noredirects соответственно разрешают
и запрещают прием переадресующих сообщений по данному интерфейсу.
В списке trustedgateways перечислены маршрутизаторы, от которых разреша-
ется принимать такие сообщения. С переадресацией не связаны никакие
дополнительные опции трассировки.
В некоторых системах ядро самостоятельно обрабатывает переадресуюшие
ICMP-директивы, не позволяя вмешиваться демону gated. В этом случае
демон проверяет, приняло ли ядро директиву, и самостоятельно удаляет
маршрут из таблицы, если он нежелателен.
Статические маршруты
Статические маршруты конфигурируются посредством инструкции static:
static {
адрес gateway список_идиозов [Interface список_интерфейсов]
[preference приоритет] [retain] [reject] [blackhole]
[noinscall];
]?
384
Чость II Робото в сетях
Аргумент адрес может быть задан одним из следующих традиционных
способов:
host узел
default
сеть
сеть mask маска
сеть masklen длина
Аргумент список_шлюзов — это перечень маршрутизаторов, посредством
которых можно достичь указанного адресата. Теоретически может существо-
вать несколько шлюзов, но в большинстве систем ядро не поддерживает
многовекторную маршрутизацию. Если обозначенный шлюз не находится в
непосредственно подключенной сети (список интерфейсов подключения
задается в предложении interface), маршрут игнорируется.
По умолчанию приоритет маршрута равен 60. что позволяет перекрывать
его маршрутами, найденными посредством протокола OSPF или переадре-
суюших ICMP-директив.
Если маршрут помечен ключевым словом retain, он будет существовать
в таблице маршрутизации ядра, пока выполняется демон gated. Обычно демон
производит после себя очистку, оставляя лишь адреса интерфейсов и те
маршруты, которые существовали до него. В противоположность этому
ключевое слово noinstall запрещает помещать маршрут в локальную таблицу
маршрутизации, разрешая лишь сообщать о нем другим маршрутизаторам.
Данная возможность оказывается полезной при реализации “серверов мар-
шрутизации”, которые реально не осуществляют переадресацию трафика, а
лишь управляют маршрутной информацией в рамках сети.
Маршруты, помеченные ключевыми словами blackhole и reject, запрещают
перенаправление пакетов в тех системах, где оно поддерживается. В случае
опции reject отправителю возвращается ICMP-пакет с сообщением об ошибке;
а при использовании опции blackhole пакеты просто исчезают.
Экспортируемые маршруты
Если демон gated нашел все необходимые ему маршруты, он помешает
их в таблицу ядра. Для большинства приложений больше ничего не требуется.
Но иногда нужно так сконфигурировать демон, чтобы он выступал в роли
транслятора, принимая информацию от одного протокола и направляя се в
другой. Управление этим процессом осуществляется посредством инструкции
export:
export proto протокол
[interface список_интерфейсов I gateway список_щлюаов]
restrict?
ИЛИ
export proto протокол
[interface список_интерфейсов | gateway список_шлвзов]
[metric метрика] {
зкспортируемый_список;
};
Аргумент протокол — это протокол маршрутизации, осуществляющий
рассылку транслируемой информации. В экспортируемом списке содержится
Глово 14. Моршрутизоция
385
по одному предложению proto для каждого транслируемого набора данных.
Вот пример такого списка:
proto static [
ALL metric 1;
ь-
В соответствии с этим списком все статические маршруты помешаются
в экспортируемый список с метрикой стоимости I.
Полный пример конфигурации демона gated
Ниже показана конфигурация сети, в которой используется как протокол
RIP, так и OSPF. Конфигурационный файл предназначен для пограничного
маршрутизатора (рис. В).
Рис. В. Топология сети для примере конфигуроции демоно gated
В верхней сети (корпоративной магистрали) используется протокол OSPF,
но в нижней локальной сети имеются устройства (несколько сетевых
принтеров), которые понимают только протокол RIP В данной среде демон
gated повторно осуществляет широковещательную рассылку OSPF-маршрутов
через протокол RIP. Это хороший образец корпоративной или университет-
ской сети, в которой персональные компьютеры и сетевые устройства
получают маршрутную и « [формацию посредством протокола R1P, но в то же
время используют более эффективный протокол для взаимодействия через
магистраль с компьютерами, расположенными в других рабочих группах,
этажах и зданиях.
Содержимое конфигурационного файла выглядит так:
Секция 1:
rip yes (
broadcast;
defaultmetric 10;
interface 192.225.40.253 noripout;
interface 192.225-55.253 ripout;
}:
386
Чость II. Роботе в сетях
Секция 2:
ospf yes {
area 0.0.0.2 |
authtype none;
networks (
192.225.55.0 mask 255.255.255.0;
1;
interface 192.225.55.253 cost 1 (
priority 2;
}:
1;
backbone (
interface 192.225.40.253 '
priority 2;
);
I;
Секция 3:
static {
default gateway 192.225.40.254 preference 140 retain;
1;
Секция 4:
export proto rip ।
proto ospf {
ALL metric 1;
I;
proto direct (
ALL metric 1;
H
proto static {
ALL metric 1;
);
Секция 5:
export proto ospf {
proto direct {
ALL metric 1;
};
};
В секции I демону gated сообщается о необходимости поддержки прото-
кола RIP. Демон принимает широковещательные RlP-обновления от других
маршрутизаторов по обоим интерфейсам, но собственные RIP-пакеты посы-
лает только через интерфейс 192.225.55.253. Это позволяет устранить неже-
лательный широковещательный трафик в корпоративной магистрали.
В секции 2 активизируется протокол OSPF. Интерфейс 192.225.40.253
находится в опорной области 0. Через него демон рассылает другим
маршрутизаторам “приветственные” OSPF-сообшения (протокол HELLO),
чтобы обнаружить своих соседей. Интерфейс 192.225.55.253 располагается в
области 2.
Данная сеть имеет лишь один выход во внешний мир. Поэтохгу в секции 3
объявляется стандартный статический маршрут к Internet-шлюзу в сети
192.225.40.0.
Гпово 14. Моршрутиэоция
387
В секциях 4 и 5 демону gated сообщается о том, какие маршруты следует
распространять через протоколы RIP и OSPF соответственно. В RIP-уведом-
ления будут включаться маршруты к непосредственно подключенным сетям,
стандартный статический маршрут, а также любые маршруты, полученные
через протокол OSPF. В OSPF-уведомления будут включаться только
маршруты к непосредственно подключенным сетям (например, 192.225.55.0).
Объявлять стандартный шлюз нет необходимости, так как это внутренний
маршрутизатор.
14.6.	Особенности маршрутизации в различных системах
ф
ш
Демон gated не входит в дистрибутив Solaris. Демон routed активизируется
в режиме сервера (-s), когда компьютер имеет не менее двух реальных сетевых
интерфейсов и не использует протокол DHCP. Если какое-либо из этих
требований не выполняется, демон routed запускается в “бесшумном’' режиме
<-q) при условии, что стандартный маршрут не задан (в файле /etc/defaul-
trouter) и не используется протокол обнаружения маршрутизаторов (демон
in.rdisc).
Демон gated запускается, если в файле /etc/rc.config.d/netconf выполняется
условие GATED=1. Демон routed не входит в дистрибутив HP-UX.
В Red Hat демон gated запускается в том случае, если существует файл
/etc/gated.conf. Демон routed по умолчанию отключен. Чтобы активизировать
его, нужно переименовать файл /etc/rc.d/rc3.d/K55routed в S55routed (это
можно также сделать с помощью графической утилиты control-panel).
Во FreeBSD демон routed запускается на этапе начальной загрузки, если
в файле rc.conf переменная router_enable равна YES, а переменная router
равна routed.. Чтобы в данной операционной системе стала возможной
пересылка пакетов между интерфейсами, необходимо в файле rc.conf устано-
вить переменную gateway_enable равной YES. Инсталляцию демона gated
можно произвести из каталога /usr/ports/gated-
14.7.	Выбор стратегии маршрутизации
По сути, существуют четыре уровня сложности, посредством которых
можно охарактеризовать процесс управления маршрутизацией в сети:
•	отсутствие маршрутизации как таковой;
•	только статическая маршрутизация;
•	преимущественно статическая маршрутизация, но клиенты принимают
RIP-обновления;
•	динамическая маршрутизация.
Общая топология сети существенно влияет на потребности в маршрути-
зации каждого отдельного сегмента. В различных сетях могут требоваться
совершенно разные уровни поддержки маршрутизации. При выборе стратегии
пользуйтесь следующими эмпирическими правилами.
•	Автономная сеть не требует маршрутизации.
•	Если из сети есть только один выход во внешний мир, клиенты сети
(нешлюзовые машины) должны иметь стандартный статический маршрут
к этому шлюзу. Никакой другой конфигурации не требуется, кроме как
на самом шлюзе.
•	Можно задать явный статический маршрут к шлюзу, ведущему к
небольшой группе сетей, и стандартный маршрут к шлюзу, ведущему во
388
Чость II Робота в сетях
внешний мир. Тем не менее рекомендуется динамическая маршрутизация,
если есть возможность добираться до нужной сети разными маршрутами.
•	Если используется протокол RIP, избегайте запускать демон routed в
режиме сервера, так как он передает все, что знает (независимо от того,
верны эти сведения или нет), в широковещательном режиме через
короткие промежутки времени, вследствие чего возникает избыточная
нагрузка на сеть и систему. В отличие от него демон gated позволяет
явно указывать, о каких маршрутах можно сообщать, что сокращает объем
маршрутной информации. Кроме того, демон gated может посылать
RIP-обновления в конкретные шлюзы, а не осуществлять их широкове-
щательную рассылку.
•	Дня того чтобы клиенты пассивно ожидали поступления обновленных
маршрутов и не рассылали свою собственную информацию, используйте
с целью запуска демона команду routed -ф То же самое можно сделать
и посредством демона gated, но им сложнее управлять.
•	Многие считают, что RIP — ужасный, кошмарный протокол, а демон
routed — потомок Сатаны Это совсем не так. Если демон работает и
системе и обеспечивает нормальную производительность, пользуйтесь им
на здоровье. Не нужно тратить время на разработку сверхсложных схем
маршрутизации.
•	Если RIP — не основной протокол маршрутизации, можно заставить
демон gated преобразовывать и передавать в широковещательном режиме
свои маршрутные данные через протокол R1P для удобства пассивных
клиентов.
•	Демон routed принимает данные отовсюду, не выполняя никаких
проверок. Демон gated позволяет осуществлять более строгий контроль
над маршрутными обновлениями. Даже если в сети используется протокол
RIP, можно управлять обменом маршрутными данными с помошью
демона gated, а демон routed запускать только на машинах-клиентах.
•	Динамическую маршрутизацию следует применять в точках, где сети
пересекают политические или административные границы.
•	В сетях с динамической маршрутизацией, содержащих замкнутые контуры
или избыточные пути, по возможности применяйте протокол OSPF.
•	Маршрутизаторы, подключенные к 1 me met-магистрали, должны исполь-
зовать протокол BGP. Обычно подключение производится в одной
единственной точке, поэтому подойдет простой статический маршрут.
Хорошая стратегия маршрутизации для организации среднего размера с
относительно стабильной локальной структурой и имеющимся соединением
с какой-либо другой сетью — использовать комбинацию статической н
динамической маршрутизации Те компьютеры, которые не являются шлю-
зами к внешним сетям, могут использовать статическую маршрутизацию, по
умолчанию направляя все неизвестные пакеты на машину, способную
общаться с внешним миром и выполнять динамическую маршрутизацию.
Сеть, которая для управления по такой схеме слишком сложна, должна
основываться на динамической маршрутизации. В краевых сетях по-прежнему
можно использовать стандартные статические маршруты, но компьютеры в
сетях с более чем одним маршрутизатором должны выполнять демон routed
в “бесшумном” режиме Всем компьютерам с несколькими сетевыми
интерфейсами следует выполнять демон gated в серверном режиме и
осуществлять широковещательную рассыпку маригрутов через протокол RIP
Глово 14. Моршрутизоция
389
14 8 Маршрутизаторы Cisco
Маршрутизаторы, выпускаемые компанией Cisco Systems, Inc., сегодня
являются стандартом де-факто на рынке подобных устройств. Захватив более
70% рынка, компания Cisco добилась широкой известности своих продуктов,
к тому же имеется множество специалистов, умеющих работать с этими
продуктами. Раньше в качестве маршрутизаторов приходилось часто исполь-
зовать UNEX-системы с несколькими сетевыми интерфейсами. Сегодня
офисы крупных компаний буквально напичканы маршрутизаторами, распо-
ложенными в стенных шкафах и над искусственными потолками, где сходятся
сетевые кабели. Эти маршрутизаторы дешевле, быстрее и безопаснее, чем их
UNIX-аналоги.
Большинство маршрутизаторов Cisco работает под управлением опера-
ционной системы IOS, которая является собственностью компании Cisco и
не имеет отношения к UNIX. У нее достаточно большой набор команд,
полная бумажная документация занимает на полке почти полтора метра. Мы
никогда не смогли бы полностью описать здесь эту операционную систему,
но все же постараемся дать о ней основные сведения
В IOS определены два уровня доступа (пользовательский и привилеги-
рованный). каждый из которых включает парольную защиту. По умолчанию
можно получить доступ к маршрутизатору Cisco на пользовательском уровне
посредством программы telnet* Будет выдано приглашение на ввод пароля:
% tainst хог-gw.хог.com
Connected to xor-gw.xor.com.
Escape character is ’
User Access Verification
Password:
После ввода правильного пароля появится приглашение от интерпрета-
тора команд ЕХЕС:
xor-gw,хог.сога>
С этого момента можно начинать вводить команды, например команду
show interraces, отображающую список сетевых интерфейсов маршрутизатора,
или show ?, отображающую справку по возможным параметрам.
Для перехода в привилегированный режим задайте команду enable, а при
последующем запросе — пароль Признаком привилегированного режима
является наличие символа в конце строки приглашения:
xor-gw.хог.com#
Будьте осторожны! Находясь в данном режиме, можно делать все, что
угодно, включая удаление конфигурационной информации и самой опера-
ционной системы.
Введя команду show running, вы можете узнать текущие динамические
параметры конфигурации. а по команде show config отображаются текущие
неизменяемые параметры. В большинстве случаев оба набора данных одина-
ковы. Вот типичная конфигурация:
хог-gw.хог.com# show running
Current configuration:
Можно сконфигурировать множество методов доступа. Если в вашей организации уже
используются маршрутизаторы Cisco, обратитесь к сетевому администратору, чтобы узиать,
какие методы доступа имеются.
391
Чость II. Роботе в сетях
version 12.О
hostname xcr-gw
enable secret xxxxxxxx
ip subnet-zero
interface EthernetO
description XOR internal network
ip address 192.108.21.254 255.255.255.0
no ip directed-broadcast
interface Ethernetl
description XOR backbone network
ip address 192.225.33.254 255.255.255.0
no ip directed-broadcast
ip classless
line con 0
transport input none
Line aux 0
transport input telnet
line vty 0 4
password xxxxxxxx
login
end
Модифицировать конфигурацию маршрутизатора можно разными спосо-
бами. Компания Cisco предлагает графические утилиты, работающие в
некоторых версиях UNIX и NT, но опытные сетевые администраторы никогда
ими не пользуются. Их самый мощный инструмент — командная строка.
Кроме того, существует возможность посредством протокола ТЕТР загрузить
с маршрутизатора его конфигурационный файл и отредактировать в любимом
текстовом редакторе, после чего записать файл обратно на маршрутизатор.
Чтобы отредактировать конфигурационный файл в режиме командной
строки, введите config term
xor-gw.xor.com# config tarm
Enter configuration commands, one per line. End with CNTL/Z.
xor-gw(config)#
Теперь можно вводить конфигурационные команды точно в таком виде,
в каком их будет отображать команда show running. Например, если нужно
изменить IP-адрес интерфейса EthernetO. укажите:
interface EthernetO
ip address 192.225.40.253 255.255.255.0
По завершении ввода конфигурационных команд нажмите <Control-Z>,
чтобы вернуться к обычной командной строке. Если все прошло нормально,
сохраните новую конфигурацию в постоянной памяти посредством команды
write mem.
Предлагаем вам несколько советов касательно работы с маршрутизато-
рами Cisco.
•	Присвойте маршрутизатору имя с помощью команды hostname Это
позволит избежать неприятностей, связанных с изменением конфигура-
ции не того маршрутизатора. Заданное имя всегда будет отображаться в
командной строке.
Глово 14. Моршрутизоция
391
•	Всегда храните резервную копию конфигурационного файла маршрутизатора.
Можно написать короткий сценарий expect, который будет посредством
протокола TFTP каждую ночь пересылать текущую конфигурацию в
UNIX-систему.
•	Контролируйте доступ к командной строке маршрутизатора путем созда-
ния списка доступа для каждого порта VTY (аналогичен порту PTY в
UNIX-системе). Это позволит исключить вероятность "взлома" маршру-
тизатора посторонними пользователями.
•	Управляйте трафиком между сетями (а, возможно, и во внешний мир),
создавая списки доступа для каждого интерфейса. О том, как составлять
такие списки, рассказывается в первом разделе параграфа 21.9.
•	Физически ограничивайте доступ к маршрутизаторам. Ведь если у
злоумышленника есть физический доступ к устройству, он легко сможет
сбросить пароль привилегированного режима.
14.9. Рекомендуемся литература
•	Huitema, Christian. Routing in the Internet, Second Edition. Prentice Hall. 2000.
Эта книга представляет собой введение в маршрутизацию для начинаю-
щих. В ней описано большинство используемых сегодня протоколов
маршрутизации, а также рассматривается ряд сложных тем, например
групповое вешание.
•	Моу, John Т. OSPF: Anatomy of an Internet Routing Protocol. Addison-Wesley.
1998.
Данная книга содержит исчерпывающее описание протокола OSPF,
выполненное автором самого протокола.
•	Halabi, Bassam. Internet Routing Artectures. Cisco Press. 1997.
Книга ориентирована на описание BGP — основного протокола внешней
маршрутизации.
Имеется также множество документов RFC, посвященных маршрутиза-
ции. Основные из них перечислены в табл. 14.5.
Тоблица 14.5. Документы RFC, посвященные маршрутизации
RFC	Название	Авторы
2328	OSPF Version 2	John T. Moy
1058	Routing Information Protocol	C. Hedrick
2453	RIP Version 2	Gaiy Scott Malkin
1256	ICMP Router Discovery Messages	Stephen E. Deering
1142	OS1 1S-IS Intra-domain Routing Protocol	David R. Oran
1075	Distance Vector Multicast Routing Protocol	D. Waitzman et al.
1519	CIDR: an Address Assignment and Aggregation Strategy	Vince Fuller et al.
1771	A Border Gateway Protocol 4 (BGP-4)	Yakov Rekhter et al.
392
Часть II Робота в сетях
7 ДГ Сетевые аппаратные
• средства
Ничто не оказывает сегодня столь большого влияния на развитие науки,
как возможность перемещать огромные объемы данных из одного места в
другое с очень большой скоростью. Глобальные коммуникации достигли
такого уровня развития, о котором десять лет назад могли мечтать лишь
фанатики научной фантастики. За всем этим безумием стоит самое разное
сетевое оборудование, многие компоненты которого берут свое начало в
UNLX
Актуальная на сегодня задача — угнаться за стремительно развивающимся
миром. Быстродействие и надежность сети оказывают непосредственное
влияние на результаты деятельности компаний и организаций. Недостатки в
построении сети приводят к личным и профессиональным проблемам, и
устранение этих недостатков порой обходится очень дорого.
Успешное создание сети зависит от трех важнейших факторов:
•	разработки приемлемой структуры сети;
•	выбора высококачественного оборудования;
•	правильной инсталляции и документирования
В настоящей главе рассматриваются среды передачи, которые чаше всего
используются для организации локальных и глобальных сетей, в том числе
Ethernet, ATM и DSL. Кроме того, освещаются некоторые вопросы проек-
тирования сетей, актуальные для любых сетей — как новых, так и сущест-
вующих.
15.1. ЛВС, ГВСиОВС
В определенном смысле нам повезло, что протоколы TCP/IP могут легко
работать в самых разных средах. Но в действительности рынок сетевых
аппаратных средств разбит на множество плохо совместимых друг с другом
сегментов.
Главе 15. Сетевые оппоротные средство
393
Сети, проложенные в пределах здания или группы зданий, называют
локальными вычислительными сетями, или ЛВС. В них распространены
высокоскоростные дешевые линии передач. В глобальных вычислительных
сетях (ГВС) конечные точки соединения географически могут быть удалены
друг от друга на значительные расстояния (тысячи километров). В таких сетях
высокоскоростные каналы стоят большие деньги, зато в сеть могут объеди-
няться компьютеры, расположенные в разных городах и странах. Общегород-
ская вычислительная сеть (ОВС) — это новый термин, обозначающий
высокоскоростную умеренной стоимости среду, функционирующую в рамках
города или группы городов. В этой главе мы узнаем, какие технологии стоят
за всеми этими сетями.
15.2. Ethernet: сбщвпризн лнная ЛВС
Захватив более 80% мирового рынка ЛВС, сети Ethernet стали почти
повсеместным явлением в современном компьютерном мире. Разработку
стандарта Ethernet начал Билл Меткаф (Bill Metcalfe) из Массачусетского
технологического института в рамках подготовки своей докторской диссер-
тации. После окончания учебы Билл стал работать в научно-исследователь-
ском центре фирмы XEROX. Объединив усилия с корпорациями DEC и Intel,
фирма XEROX в конце концов превратила Ethernet в готовый продукт. Этот
проект стал одним из первых примеров сотрудничества конкурирующих
компьютерных фирм.
В первоначальной спецификации Ethernet была определена скорость
передачи 3 Мбит/с, но она почти сразу же выросла до 10 Мбит/с. Аппаратура
разрабатывалась на основе системы Xerox Alto, на печатной плате которой
не нашлось места для внешнего тактового генератора. Поэтому пришлось
использовать внутренний генератор этой системы, в результате чего скорость
передачи должна была составить 2.94 Мбит/с. Эту цифру округлили до
3 Мбит/с. Билл Меткаф и другие специалисты, работавшие в то время нал
архитектурой ARPANET, возражали против такой погрешности округления,
которая превышала всю полосу пропускания сети ARPANET, но соображения
маркетинга победили.
Период становления технологии Ethernet пришелся на 80-е гг. Это было
время, когда многие сетевые операционные системы, включая UNIX,
приобретали базовые функциональные возможности и учились взаимодейст-
вовать друг с другом. Всеобщее внимание технология приобрела в 1994 г.,
когда в соответствии с новой спецификацией ее скорость работы составила
100 Мбит/с. В 1998 г. был достигнут новый рубеж: I Гбит/с Сегодня перед
разработчиками стандарта стоит цель — 10 Гбит/с. Технология Ethernet уже
затмила всех своих конкурентов, и. по существующим прогнозам, к 2008 г.
широкое распространение получат терабитные сети! В табл. 15.1 перечислены
основные этапы эволюции различных стандартов Ethernet.
394
Чость II Роботе в сетях
Тоблицо 15.1- Эволюция Ethernet
Год	Скорость	Позвонив стандарта	lEEENo	Расстояние	Среда
1973	3 Мбит/с	Xerox Ethernet	-	9	Коаксиальный кабель
1980	10 Мбит/с	Ethernet 1	-	500 м	Коаксиальный кабель RG-11
1982	10 Мбит/с	DLX Ethernet (Ethernet 11)	-	500 м	Коаксиальный кабель RG-1I
1985	10 Мбит/с	10 Base 5 (“Thicknet”)	802.3	500 м	Коаксиальный кабель RG-I1
1985	10 Мбит/с	10 Base 2 (“Thinnet’’)	802.3	180 м	Коаксиальный кабель RG-58
1989	10 Мбит/с	lOBascT	802.3	100 M	Медный кабель НВП1 категории 3
1993	10 Мбит/с	lOBascF	802.3	2 km 25 km	ММ2 оптоволокно ОМ оптоволокно
1994	100 Мбит/с	lOOBaseTX (Fast Ethernet)	802.3u	100 м	Медный кабель НВП ка- тегории 5
1994	100 Мбит/с	lOOBaseFX	802.3u	2 km 20 km	ММ оптоволокно ОМ оптоволокно
1998	1 Гбит/с	lOOOBaseSX	802.3z	260 м 550 м	ММ оптоволокно (62,5 мкм) ММ оптоволокно (50 мкм)
1998	1 Гбит/с	lOOOBaseLX	802.3z	440 м 550 м 3 km	ММ оптоволокно (62,5 мкм) ММ оптоволокно (50 мкм) ОМ оптоволокно
1998	1 Гбит/с	lOOOBaseCX	802.3z	25 м	Двухпроводный экрани- рованный кабель
1999	1 Гбит/С	lOOOBaseT (Gigabit Ethernet)	802.3ab	100 м	Медный кабель НВП ка- тегории 5Е и 6
1 НВП — неэкранированная витая пара.
2 ММ — многомодовое. ОМ — одномодовое.
Как работает Ethernet
Технологию Ethernet можно представить в виде великосветского раута,
на котором гости (компьютеры) не перебивают друг друга, а ждут паузы в
разговоре (отсутствия трафика в сетевом кабеле), чтобы заговорить. Если два
гостя начинают говорить одновременно (т.е. случается конфликт), оба они
останавливаются, извиняются друг перед другом, ждут немного, а затем один
из них начинает говорить снова.
Глово 15. Сетевые оппоротные средство
395
Рис. А. "Тойноя вечеря' Ethernet
В технической терминологии эта схема называется CSMA/CD (Carrier
Sense Multiple Access with Collision Detection — множественный доступ с
контролем несущей и обнаружением конфликтов) Вот смысл этого названия:
•	художественный доступ: любой может передавать сообщения;
•	контроль несущей, можно определить, занят ли канал;
•	обнаружение конфликтов: передающая система знает, когда "перебивает''
кого-нибудь.
Фактическая задержка при обнаружении конфликтов — величина слу-
чайная. Это позволяет избежать такого развития событий, при котором две
машины одновременно передают сообщение в сеть, обнаруживают “столкно-
вение”, ждут некоторое время, а затем синхронно возобновляют передачу,
переполняя таким образом сеть конфликтами.
Топология Ethernet
С точки зрения топологии сеть Ethernet представляет собой шину с
ответвлениями, но без контуров. У каждого пакета есть только один путь
следования между любыми двумя машинами в одной сети. В Ethernet могут
передаваться пакеты трех типов: однонаправленные, групповые и широкове-
щательные. Пакеты первого типа адресованы одному узлу, второго — группе
узлов, третьего — всем узлам в данном сегменте.
Широковещательный домен — это совокупность узлов, которые прини-
мают пакеты, направляемые по аппаратному широковещательному адресу.
В каждом логическом Ethemet-сегменте имеется ровно один широковеща-
тельный домен. В ранних стандартах Ethernet (например, 10Base5) понятия
физического и логического сегмента были тождественными, поскольку все
пакеты передавались по одному большому кабелю, к которому прикреплялись
сетевые интерфейсы компьютеров’.
Мы не шутим! Подключение нового компьютера к сети предполагало прокалывание
отверстия в изоляции кабеля с помощью специального соединителя, называемого "зуб
вампира", который позволял добраться до центрального проводника. Этот соединитель
затем прикручивался отверткой.
396
Чость II. Роботе в сетях
С появлением современных мостов логические сегменты стали включать
в себя множество (десятки и даже сотни) физических сегментов, к которым
подключены всего два устройства: порт моста и компьютер. Мосты отвечают
за доставку групповых и однонаправленных пакетов в физический сегмент,
где расположен нужный адресат (адресаты); широковещательные пакеты
доставляются всем сетевым портам в логическом сегменте.
Логический сегмент может состоять из физических сегментов, имеющих
разную скорость передачи данных (10 Мбит/с, 100 Мбит/с или I Гбит/с).
Следовательно, мосты должны иметь средства буферизации и синхронизации,
позволяющие устранить возможные конфликты.
Неэкранированноя витая паро
Неэкранированная витая пара (НВП) — самая популярная среда передачи
данных в сетях Ethernet. Этот стандарт основан на звездообразной топологии
и имеет ряд преимуществ по сравнению с другими средами-
•	применяется недорогой, недефицитный медный кабель (иногда можно
использовать уже проложенную телефонную проводку);
•	соединение на основе НВП гораздо проще смонтировать и наладить, чем
соединение на основе коаксиального кабеля иди оптоволокна;
•	используются дешевые, надежные н удобные в эксплуатации разъемы
RJ-45;
•	все соединения функционируют независимо друг от друга, поэтому
неисправность аппаратуры или дефект кабельной системы в одном
соединении нс повлияет на другие компьютеры, работающие в сети;
•	все соединения являются частными, и соседние компьютеры не могут
перехватывать трафик друг друга.
Обшая схема сети на основе НВП изображена на рис. Б.
Рис. Б. Схеме сети но основе НВП
(Провода, используемые в современных ЛВС на основе НВП. обычно
подразделяют на восемь категорий. Эта система опенки параметров была
впервые введена фирмой Anixter, крупным поставщиком кабельной продук-
ции. Сегодня выделяются категории 1—7 и промежуточная категория 5Е.
Кабели категорий 1 и 2 годятся только для передачи звуковых сигналов.
Кабель категории 3 — стандартный для сетей lOBaseT со скоростью передачи
10 Мбит/с. Кабель категории 4 конкретно ни для какого приложения не
Глово 15. Сетевые еппоротные средство
397
предназначен. Иногда его применяют в построенных на основе НВП сетях
Token Ring со скоростью передачи 16 Мбит/с, а также в специализированных
системах lOBaseT. Кабель категории 5, поддерживающий работу на скорости
100 Мбит/с. чаше всего применяется в современных кабельных системах.
Кабели категорий 5Е и 6 поддерживают скорость передачи I Гбит/с.
Для соединений lOBaseT требуются две пары проводов категории 3,
причем длина каждой линии передачи ограничена 100 метрами. В соединении
lOOBaseTX предельная длина та же самая, но используются две пары проводов
категории 5. Бывают провода с поливинилхлоридной и тефлоновой изоля-
цией. Ее выбор диктуется средой, в которой будут проложены кабели.
В замкнутых помещениях, связанных с вентиляционной системой здания,
обычно требуется тефлоновая изоляция. Поливинилхлоридная изоляция
дешевле и проще в эксплуатации.
Подробнее о прокладке кабелей можно узнать в параграфе 15.10.
При монтаже соединений используются разъемы RJ-45, в которых
задействованы выводы I, 2, 3 и 6. Хотя для нормальной работы соединения
со скоростью 10 или 100 Мбит/с достаточно двух пар проводов категории 3,
рекомендуем в случае монтажа новой сети использовать кабель категории 5
с четырьмя парами проводов и подключать все восемь контактов розетки
RJ-45.
Подключая четьтрехпарный НВП-кабель к коммутационным панелям и
настенным розеткам RJ-45. используйте стандарт разводки TIA/EIA-568.A.
Этот стандарт позволяет избежать ошибок при разводке концов кабеля
независимо от того, есть свободный доступ к самим парам или нет. Некоторые
требования этого стандарта отражены в табл. 15.2.
Тоблицо 15.2. Стондорт TIA/EIA-568A: подключение четырехлорного
НВП-кобеля к розетке RJ-45
Поре	Цвет	Контакты розъемс
1	Белый/Сииий	5/4
2	Белый/Оранжсвый	3/6
3	Белый/Зелекый	1/2
4	Белый/Коричневый	7/8
Имеющаяся в здании проводка может подходить или не подходить для
прокладки сетей, а зависимости от того, как и когда прокладывалась она
сама.
Соединение и расширение сетей Ethernet
Согласно семиуровневой модели ISO, сети Ethernet можно логически
соединять в нескольких точках. На первом уровне, физическом, используются
либо аппаратные соединители, либо повторители (в наши дни заменяемые
концентраторами) Они передают непосредственно электрические сигналы.
На втором уровне, канальном, применяются мосты. Они передают сетевые
кадры, содержащие аппаратные адреса отправителя и получателя.
На третьем уровне, сетевом, используются маршрутизаторы. Они достав-
ляют сообщение следующему узлу на пути к адресату, не заботясь о том. что
затем произойдет с этим сообщением.
3' 3
Чость II. Робота в сетях
Повторители и концентраторы
Концентратор — активное устройство, которое используется для соеди-
нения физических сегментов Ethernet, построенных на основе НВП. Он может
восстанавливать и ретранслировать сигналы и требует внешнего источника
питания. Выступая в роли повторителя, концентратор передает сигналы из
одного кабеля в другой, не выполняя обработку сетевых пакетов. Он не имеет
представления ни о том, куда направляются пакеты, ни о том. какой протокол
используется.
Две самые дальние точки сети должны отстоять друг от друга на
расстояние не более четырех повторителей. В первом и втором стандартах
Ethernet число последовательно устанавливаемых повторителей ограничива-
лось двумя на сеть; в спецификации IEEE 802.3 (10 Мбит/с) это число
возросло до четырех. В сетях со скоростью передачи 100 Мбит/с допускаются
два повторителя, а в стандарте lOOOBaseT — только один На рис. В показаны
допустимая и недопустимая конфигурации для десятимегабитной сети.
РиС. В. Считоем повторители
Концентраторы время от времени требуют внимания со стороны систем-
ного администратора, поэтому их не следует располагать в труднодоступных
местах. Включение н выключение питания обычно позволяет "оживлять" их
в случае зависания
Мосты
Мрсты соединяют сети Ethernet на канальном (втором) уровне модели
OSL Их назначение — объединить две отдельные физические сети так, чтобы
они выглядели как одна большая физическая сеть. Мосты не требуют
программного обеспечения, принимая, регенерируя и повторно передавая
пакеты на аппаратном уровне’. Большинство мостов используют алгоритм
динамического обучения. Они запоминают, какие исходные адреса поступают
с одного порта, а какие — с другого. Пакет переходит из одного порта в
другой только в том случае, если его получатель находится в соседней сети.
Первоначально пересылаются все пакеты, но через несколько секунд, когда
мост изучит расположение большинства компьютеров, он запускает механизм
фильтрации.
Поскольку между сетями пересылаются не все пакеты, каждый сегмент
кабеля менее загружен, чем в случае, когда все компьютеры подключены к
Поскольку' пакеты регенерируются, то сели, все сегменты которых соединены мостами,
лишены ограничения, подобного "счетчику повторителей” иа рис. В.
Глово 15 Сетевые оппоротные средство
399
одному кабелю. А в связи с тем, что основной трафик имеет тенденцию к
локализации, увеличение реальной пропускной способности может оказаться
довольно серьезным. Кроме того, мост не влияет на логическую модель сети,
поэтому его установка влечет за собой лишь незначительное вмешательство
со стороны администратора.
Если сеть имеет замкнутые контуры, мост может безнадежно запутаться,
потому что пакеты, посылаемые одной машиной, окажутся иа обоих портах
моста (или сразу на нескольких портах, если у моста их более двух; такие
мосты иногда называют коммутаторами). В одной сети Ethernet замкнутых
контуров не бывает, ио после объединения нескольких таких сетей маршру-
тизаторами и мостами топология изменится, вследствие чего может образо-
ваться несколько путей к одной машине. Некоторые мосты решают эту
проблему за счет резервирования альтернативных маршрутов на тот случай,
если основной маршрут станет недоступным. Они упрошают топологию
видимой ими сети до тех пор, пока в оставшихся частях не окажется только
по одному маршруту к каждому узлу сети. Некоторые мосты создают между
сетями двойные каналы и направляют трафик по кольцевой схеме.
Наращивание функциональных возможностей микропрограммного кода
мостов позволяет повышать их “уровень интеллекта*’. Некоторые мосты
можно использовать для контроля безопасности сети. Они регистрируют все
“чужие” Ethcmet-адреса, выявляя таким образом новые ответвления на кабеле
и сообщая о них. Поскольку мосты функционируют на канальном уровне,
они не зависят от протоколов и могут обрабатывать любые сочетания пакетов,
использующих протоколы более высокого уровня (например. IP, AppleTalk
или NetBEUI).
Мосты должны просматривать каждый пакет и определять, нужно ли его
пересылать в другой сегмент. Их производительность обычно измеряют как
скоростью просмотра пакетов, так и скоростью их пересыпки. Многие
поставщики не указывают в диаграммах производительности мостов размеры
пакетов, поэтому реальная производительность может быть ниже объявлен-
ной Вообще говоря, мосты — хороший, но довольно дорогой способ
соединения сетей Ethernet.
Несмотря на то что быстродействие мостов все время растет, эффективно
использовать их можно при объединении в один логический сегмент не более
чем сотни компьютеров. В крупных коммутируемых сетях часто возникают
проблемы наподобие “широковещательных штормов”, поскольку широкове-
щательный трафик должен проходить через все порты. Для решения проблемы
нужно изолировать трафик между' сегментами посредством маршрутизатора
(создавая тем самым более одного логического Ethemet-сегмента).
В крупных организациях можно использовать мосты, позволяющие
разбивать их порты (программным путем) на группы, называемые виртуаль-
ными ЛВС (ВЛВС). ВЛВС — это группа портов, принадлежащая одному и
тому же логическому сегменту, как если бы порты были соединены со своим
собственным выделенным мостом. Подобное секционирование позволяет
повысить степень изоляции трафика, что полезно с точки зрения как
безопасности, так и производительности.
Выбор моста может представлять определенные трудности. В этом
сегменте рынка очень высокая конкуренция, следствием которой являются
многочисленные рекламные заявления, не всегда подтверждаемые на прак-
тике. Поэтому не стоит особо доверять данным, которые приводятся
поставщиками; лучше прислушаться к советам независимых экспертов.
В последние годы нередко случалось так, что чей-то продукт сказывался
400
Чость II Роботе в сетях
'‘лучшим” в течение нескольких месяцев, а затем, после попыток внести
улучшения, его производительность или надежность падала ниже критической
отметки.
В любом случае убедитесь, что скорость объединительной панели моста
является достаточной У хорошо спроектированного моста эта скорость
должна превышать сумму скоростей всех его портов.
Маршрутизаторы
Маршрутизатор представляет собой специализированное вычислительное
устройство с двумя или несколькими сетевыми интерфейсами, работающее
на третьем (сетевом) уровне модели OSI, Маршрутизаторы доставляют пакеты
адресатам, основываясь на информации, хранящейся в IP-заголовках. Помимо
простого перемещения пакетов из одного места в другое маршрутизаторы
выполняют также ряд особых функций, например фильтрацию пакетов (в
соответствии с правилами безопасности), разделение трафика по приоритетам
(в соответствии с заданным качеством обслуживания) и обнаружение общей
сетевой топологии. Подробно об этом рассказывалось в главе 14.
На одном маршрутизаторе могут быть установлены аппаратные интер-
фейсы разных типов (FDDI, Ethernet, ATM). На программном уровне
некоторые маршрутизаторы могут обрабатывать трафик, не относящийся к
протоколу IP, например пакеты протоколов IPX и AppleTalk. В этом случае
маршрутизатор и его интерфейсы нужно сконфигурировать для каждого
конкретного протокола.
У маршрутизаторов может быть фиксированная или модульная конфи-
гурация. Устройства первого типа содержат сетевые интерфейсы, предуста-
новленные в заводских условиях. Они подходят для специализированных
применений. Например, маршрутизатор с интерфейсами TI и Ethernet может
оказаться удобным, когда нужно подключить небольшую компанию к сети
Internet.
Модульные маршрутизаторы имеют слотовую или шинную архитектуру,
а интерфейсы к ним добавляются конечными пользователями. Обычно это
более дорогие устройства, но зато они проявляют большую гибкость в
эксплуатации.
В зависимости от необходимой надежности и ожидаемого трафика
выделенный маршрутизатор может оказаться как дороже, так и дешевле
UNIX-системы, выступающей в роли маршрутизатора. Однако специализи-
рованное устройство всегда будет демонстрировать более высокую произво-
дительность и надежность. Это та область сетевого проектирования, где лучше
заранее вложить дополнительные деньги, чем потом иметь ненужную
головную боль.
15.3.	FDDI: дорогая локальная сеть-разочарование
При скорости передачи 10 Мбит/с технология Ethernet ие обеспечивала
пропускную способность, необходимую для решения некоторых сетевых задач,
например соединения рабочих групп через корпоративную или университет-
скую магистраль. С целью создания более производительной среды комитет
ХЗТ9.5 Американского национального института стандартов (American Na-
tional Standards Institute, ANSI) в середине 80-х гг. опубликовал стандарт
FDD! (Fiber Distributed Data Interface — распределенный интерфейс передачи
FDDI был также принят в качестве стандарта ISO.
Гпово 15 Сетевые апгоротные средства
401
данных по волоконно-оптическим каналах!). Он разрабатывался и выпускался
на рынок как интерфейс для сетей Token Ring со скоростью передачи
100 Мбит/с. Ожидалось, что технология FDDI позволит легко решить
проблему пропускной способности, стоящую перед многими организациями.
К сожалению, очень скоро стандарт всех разочаровал. В первое время
цена интерфейсов FDDI (около 10000$) часто превышала стоимость рабочих
станций, на которых они устанавливались, а производительность (например,
в первых FDDI-платах фирмы DEC) была во многих случаях хуже, чем у
Ethernet. FDDI-платы и сейчас дороги, но их производительность улучшилась.
Современные платы такого типа имеют пропускную способность примерно
80 Мбит/с.
Для нормального качества функционирования FDDI-плате требуется
гораздо большее значение МТС (максимальный размер передаваемого блока),
чем то, что по умолчанию установлено для Ethernet. Наилучший выбор -
4352 (задается с помощью команды ifconfig). До тех пор пока программное
обеспечение, используемое для перемещения файлов по сетям, не будет
настроено на быстродействие и характеристики FDD1, пользователи будут
довольствоваться производительностью в диапазоне от одной трети до
половины теоретического максимума.
Более подробно о значении MTU рассказываюсь в параграфе 13.3.
Стандарт FDDI определяет кольцевую топологию сети с передачей
маркера, построенную на базе волоконно-оптической среды со скоростью
передачи 100 Мбит/с (рис. Г). Здесь используется двойная кольцевая архи-
тектура: основное кольцо обеспечивает передачу данных, а вспомогательное
используется как резервное на случай разрыва.
Рис. Г. Двойной кольцевой сеть но бозе FDD1
Компьютеры могут подключаться к обоим кольцам (в этом случае они
называются машинами класса А, или машинами с двойным подключением)
или только к основному кольцу (машины класса Б, с одинарным подклю-
чением). Магистральные маршрутизаторы и концентраторы обычно имеют
двойное подключение, а рабочие станции — одинарное, через концентратор
FDDI.
Одно из преимуществ кольцевой сети с передачей маркера заключается
в том, что доступом к такой сети управляет жестко детерминированный
протокол. Конфликтов не происходит, поэтому производительность сети при
высокой нагрузке не ухудшается, как это бывает в Ethernet. Многие кольцевые
402
Чость 11. Роботе в сетях
системы с маркерным доступом при обслуживании нескольких клиентов могут
выходить на 90—95% своей номинальной пропускной способности.
Для физической среды стандарт FDDI предлагает два типа оптоволокна:
одномодовое и многомодовое. Моды — это пучки световых лучей, входящих
в волокно под конкретным углом. По одномодовому волокну может
распространяться световая волна только одной частоты, поэтому в качестве
источника излучения предпочтительно использовать лазер* Многомодовое
волокно допускает распространение света несколькими путями и обычно
применяется с менее дорогостоящими и менее опасными светодиодами.
Одномодовое волокно обеспечивает передачу информации на более дальние
расстояния, чем многомодовое. Для FDD1 чаше всего используется много-
модовое волокно диаметра 62.5 мкм.
В FDD! применяются самые разные оптические соединители, предлагае-
мые различными производителями. Независимо от того, какие соединители
используются, помните, что чистота наконечников оптических соединителей
играет большую роль в обеспечении надежного функционирования волокон-
но-оптических линий связи. На рынке предлагаются специальные комплекты,
предназначенные для самостоятельного монтажа соединений, но лучше
обратиться за помошью к профессионалам.
15.4.	ATM: локальная сеть несбывшихся надежд
Аббревиатура ATM расшифровывается как Asynchronous Transfer Mode
(асинхронный режим передачи), но некоторые настаивают, что она должна
обозначать Another Technical Mistake (еше одна техническая ошибка). Один
обозреватель списал ATM как "попытку телефонной компании превратить
работу в сети в некую услугу t. за которую можно назначить тариф".
С технической точки зрения ATM — особая технология, так как здесь
проповедуется идея о том, что небольшие пакеты фиксированного размера
(называемые ячейками) — самый эффективный способ реализации гигабит-
ных сетей будущего. ATM, кроме того, обешает возможности, которыми не
располагают другие среды передачи, включая резервирование полосы про-
пускания и гарантированное качество обслуживания.
ATM широко рекламировалась как универсальная коммутируемая сетевая
среда для локальных, глобальных и общегородских вычислительных сетей.
Но сегодня эта технология практически мертва, сохранившись лишь в тех
глобальных сетях, где крупные телефонные корпорации все еще пытаются
вернуть инвестиции, недальновидно вложенные в АТМ-оборудование.
Размер ячейки в ATM составляет 53 байта. Для транспортировки ячеек
определены пять уровней адаптации ATM (ATM Adaptation Layer, AAL). Их
назначение описано в табл. 15.3.
Не ясно, как в реальной жизни может использоваться AAL 2. Никакого
стандарта для этого уровня пока нет. AAL 3 и 4 оказались очень похожими,
и их объединили. Те производители, которым пришлось реализовывать
стандарт ATM, были весьма недовольны этими уровнями и разработали свое
решение — уровень SEAL (Simple and Efficient Adaptation Layer — простой
и эффективный уровень адаптации), который вскоре стал уровнем AAL 5.
Никогда не смотрите на концы висящего или обрезанного волокна! Если световод сопряжен с
лазером, можно обжечь сетчатку глаза.
Гпово 15. Сетевые оппоротные средство
403
Тоблица 15.3. Уровни адаптации ATM
AAL Применение	____ _________
1	Передача с постоянной скоростью; например, голосовые данные
2	Передача с переменной скоростью, требующая ограниченной задержки
сигнала
3	Передача данных с установлением соединений
4	Передача данных без установления соединений
5	Общие средства передачи данных (особенно IP-трафик); заменяет уровни 3
и 4 
15.5.	Ретрансляция кадров: глобальная убыточная сеть
Ретрансляция кадров — это технология глобальных сетей, основанная на
передаче данных с коммутацией пакетов, как правило, по приемлемым ценам.
Часто говорят, что ретрансляция кадров — это вновь выпущенный на рынок
протокол Х.25 (технология доступа к сетям с коммутацией пакетов, сущест-
вовавшая с середины 70-х гт). К счастью, протокол Х.25 распространен
достаточно широко, поэтому оборудование и программное обеспечение за
многие годы научились работать надежно и эффективно.
В традиционной схеме пользователи, желающие установить соединение
с удаленными компьютерами, должны были покупать у телефонной компании
выделенный канал, например линию DDS (Digital Data Service — служба
цифровой передачи данных) со скоростью 56 Кбит/с или линйю Т1. Это
каналы передачи данных типа '‘точка-точка”, которые подключены 24 часа
в сутки. Увы, такое соединение стоит довольно дорого, так как телефонная
компания должна выделять для канала отдельное оборудование и полосу
частот.
Ретрансляция кадров, в противоположность традиционной системе,
предполагает использование эффекта масштаба. Телефонная компания создает
сеть (часто называемую “облаком”), которая соединяет между собой ее
центральные станции. Пользователи передают предназначенные для удален-
ных узлов данные в виде небольших пакетов. Телефонная компания
коммутирует пакеты через соответствующие центральные станции и обеспе-
чивает их доставку в пункты назначения. В такой модели пользователь и
телефонная компания исходят из того, что в каждую конкретную секунду
трафик не превысит пропускной способности сети.
За доставку IP-трафика в сетях с ретрансляцией кадров отвечают
маршрутизаторы. Пакеты коммутируются через невидимые постоянные вир-
туальные каналы (Permanent Virtual Channel. PVC), которые обеспечивают
получение пакетов только в тех пунктах, доставка в которые была оплачена.
При этом гарантируется определенная степень конфиденциальности, что
защищает информацию пользователя от получения ее другими абонентами,
подключенными к этой же сети.
Самое большое преимущество технологии ретрансляции кадров заключа-
ется в том, что использующие ее сети, как правило, недороги. В реальной
жизни, однако, пользователь получает столько, сколько заплатил, — и часто
обнаруживает, что производительность таких сетей болезненно низка. Доля
накладных расходов на коммутацию пакетов в соединениях с ретрансляцией
404
Чость II. Роботе в сетях
кадров достаточно высока, поэтому в периоды значительной нагрузки
быстродействие канала может ухудшаться.
15	6 ISDN: глобальная сеть невидимка
ISDN (Integrated Services Digital Network — цифровая сеть с комплексным
обслуживанием) — это сервис телефонных компаний, способный принимать
самые разные формы. Наиболее распространен сервис BRI (Basic Rate
Interface — интерфейс базового уровня). Он представляет собой чисто
цифровую телефонную линию, которая включает два коммутируемых кана-
ла-носителя (называются В-каналами) со скоростью передачи 64 Кбит/с и
один дополнительный конфигурационный канал (называемый D-каналом) со
скоростью передачи 16 Кбит/с. Каждый из В-каналов можно использовать
для доставки звука или данных (звук можно передавать по одному каналу).
ISDN позволяет получить относительно быстродействующую цифровую
линию связи за приемлемую цену (от 30 до 150 долларов в месяц в
зависимости оттого, где вы живете). Устройства, называемые терминальными
адаптерами, превращают эту телефонную линию в более привычный интер-
фейс, например в RS-232. Они используются почти так же, как модемы, и
стоят приблизительно столько же. Большинство адаптеров способно объеди-
нять два В-канала, формируя в результате один канал передачи данных со
скоростью 128 Кбит/с.
ISDN можно применять вместо обычных коммутируемых сетей, а также
как глобальную технологию, в которой посредством маршрутизатора или
моста удаленные машины соединяются по телефонной линии. Но несмотря
на то что многие телефонные компании США уже установили коммутаторы,
совместимые с ISDN, они до сих пор не решили, как предоставлять и
обеспечивать эти услуги’.
15.7.	DSL: всенародная глобальная сеть
Для крупных компаний не составляет особого труда перемешать большие
объемы данных. Такие технологии, как Tl, ТЗ, SONET, ATM и ретрансляция
кадров, реализуют достаточно простые каналы обмена данными. Но они не
подходят для подключения к сети в домашних условиях. Их стоимость очень
высока, да и не всегда можно найти подходящее оборудование.
В технологии DSL (Digital Subscriber Line — цифровая абонентская линия)
используется обычный медный телефонный провод, по которому передаются
данные со скоростью до 7 Мбит/с (правда, для типичного DSL-соединения
этот показатель находится в диапазоне от 256 до 768 Кбит/с). В большинстве
домов есть телефонная линия, что делает технологию очень удобной. Со
стороны пользователя DSL-линия заканчивается в устройстве, работающем
подобно маршрутизатору TCP/IP. К нему подключаются локальные Ethernet -
устройства. Технология DSL в целом оказалась дешевле и быстрее, чем ISDN,
поэтому сегодня именно ее предпочитают домашние пользователи.
В отличие от обычных телефонных линий и ISDN-соединений, где
требуется “дозваниваться” до абонента, DSL — это выделенная линия, в
которой постоянно есть связь. Данная особенность делает ее еше более
Отсюда такой вариант расшифровки аббревиатуры ISDN: “It Still Docs Nothing", т.е. “она
все еще ничего не делает'’.
Глово 15. Сетевые оппоротные средство
4U5
привлекательной, поскольку отсутствуют задержки, связанные с начальным
конфигурированием и дозвоном.
Существует несколько реализаций DSL, поэтому название технологии
часто приводят в виде xDSL, где х — префикс конкретной реализации,
например: А (асимметричная), S (симметричная), Н (высокоскоростная) и
RA (с адаптируемой скоростью). Конкретный вариант реализации и доступная
скорость передачи зависят от оборудования, установленного в центральном
офисе телефонной компании или провайдера Internet.
Подключение к сети сотен миллионов домашних пользователей —
заветная цель для многих компаний. Здесь замешаны большие деньги
Технология DSL основана иа существующей инфраструктуре телефонных
линий, инвестиции в которую позволили телефонным компаниям и провай-
дерам Internet извлекать сказочные прибыли, пока мимо них проносилась
сетевая революция 80-х — 90-х гт.
Компании кабельного телевидения, развивающие оптоволоконную ин-
фраструктуру, предлагают собственные высокоскоростные (хоть и асиммет-
ричные) решения для конечных пользователей. В индустрии кабельных
модемов не так давно начался процесс стандартизации протоколов передачи
данных, и сегодня рекламируется стандарт DOCSIS (Data Over Cable Service
Interface Specification — спецификация интерфейса передачи данных no
кабельным линиям). Этот стандарт определяет технические характеристики
как кабельных модемов, так и оборудования компании, предоставляющей
соответствующие услуги, и позволяет взаимодействовать устройствам различ-
ных производителей.
Если сравнивать DSL и кабельную технологию, то DSL-соединения
являются частными для абонентов, тогда как пользователи кабельных модемов
обычно делят канал передачи со своими соседями. Поэтому кабельные линии
подвержены перегрузкам в периоды повышенной активности пользователей.
Они также гораздо менее безопасны.
15.8	Будущее сетей
Когда знакомишься со всеми описанными выше технологиями, замечаешь
одну общую закономерность: простые и недорогие решения побеждают, а
сложные и дорогие быстро уходят в небытие. Куда же, в конце концов,
приведет нас “нить Ариадны”?
Технология Ethernet разгромила своих конкурентов благодаря необычай-
ной дешевизне. Она столь проста в реализации, что сегодня можно даже
купить микроволновую печь, оснащенную интерфейсом Ethernet. Топологи-
чески эта технология хорошо масштабируется. Во многих организациях старые
10-мегабитные сети, проложенные еще в начале 80-х гг.» до сих пор
функционируют, соединяясь с сегментами, работающими на скоростях
100 Мбит/с и 1 Гбит/с. В настоящее время в стадии разработки находится
спецификация 10 Гбит/с, которая должна быть внедрена в эксплуатацию к
2004 г.
Что касается пользовательского сегмента рынка, то технология DSL
вдохнула новую жизнь в покрывающиеся пылью старые медные рудники.
Очевидно, при существующих темпах развития скорость DSL-соадннений в
ближайшем будущем возрастет на порядок, открыв новые горизонты для
домашних пользователей и малых офисов.
Другая перспективная область разработок — беспроводные сети. Уже
начали появляться продукты промышленного уровня по вполне приемлемой
406
Чость II Робота а сетях
иене. К сожалению, в сравнении с успехами традиционных проводных
технологий скорость этих сетей кажется несколько неадекватной современным
требованиям, колеблясь в диапазоне от 2 до 11 Мбит/с. Отладка беспроводной
сети тоже сродни черной магии. Короче говоря, беспроводная сеть — модная
игрушка для малых офисов, но маловероятно, чтобы в обозримом будутцем
она вытеснила корпоративные магистрали.
Во всех этих новых разработках прекрасно то, что, несмотря на тип
носителя и скорость передачи данных, протоколы TCP/IP применимы аезде.
15.9.	Тестирование и отладка сетей
Серьезным преимуществом широкомасштабного перехода к стандарту
Ethernet (и к другим технологиям, основанным на использования неэкрани-
рованной витой пары) стала простота отладки сети. Поскольку эти сети
можно проверять посегментно, аппаратные проблемы решаются за считанные
секунды, н не приходится возиться целыми днями.
Ключ к отладке сети — разбивка ее на сегменты и тестирование каждого
из них до тех пор, пока не будет обнаружено неисправное устройство илн
кабель. Загадочные лампочки на мостах и концентраторах (обозначающие, к
примеру, статус канала и трафик пакетов) во многих случаях дают ключ к
быстрому нахождению источника проблемы. Высококачественная документа-
иия на проводную систему позволит разобраться в назначении этих индика-
торов.
Как всегда, важно иметь под рукой нужные инструменты, чтобы суметь
выполнить работу правильно и без проволочек. Есть два основных типа
средств сетевой отладки (правда, наблюдается тенденция к их объединению).
Устройство первого типа — это ручной кабельный тестер. Он измеряет
электрические характеристики кабеля, включая также его длину. Обычно
такие устройства могут выявлять простейшие проблемы, например разрыв
или неправильную скрутку кабеля.
Второй тип устройств — сетевые анализаторы. Эти устройства просмат-
ривают сетевые пакеты на предмет наличия ошибок протоколов, неправиль-
ной конфигурации и прочего беспорядка. Для эффективного применения
подобного устройства требуется специальная подготовка и много терпения,
к тому же в наши дни анализ сети на пакетном уровне необходим редко.
Тем. кого интересует эта тема, рекомендуем посетить Web-узел компании
Sniffer Technologies (www.snifTer.com)
15.10.	Построение кабельной системы
При прокладке кабелей Ethernet, гигабитных или обычных, рекомендуем
использовать провод максимально высокого качества. Это повысит вероят-
ность того, что спустя десять лет можно будет продолжать им пользоваться
Самый дешевый вариант — проложить кабели сразу во всем здании, а не
растягивать эту процедуру иа неопределенное время.
Варианты разводки НВП
Кабель категории 5Е является относительно новым и имеет нам лучшее
соотношение цена/производительность на современном рынке. Его стандарт-
ный вариант — четыре пары проводов под одной оболочкой, что подходит
для большинства соединений, включая RS-232 и гигабитные линии.
Глово 15. Сетевые оппоротные средство
407
Спецификации кабеля категории 5Е требуют, чтобы скрутка провода
заканчивалась не более чем за полдюйма до соединения с монтажным блоком.
Это означает, что кабель с более чем четырьмя парами проводов под одной
оболочкой необходимо снабжать ответвлениями либо дополнительно обма-
тывать, так как данный кабель предназначен для обслуживания нескольких
соединений.
Офисные подключения
Одного подключения на помещение явно недостаточно. Сколько же
нужно: два или четыре? Мы рекомендуем четыре, обосновывая это следую-
щими причинами.
•	Такие подключения можно использовать для последовательных устройств
(молем, принтер и т.д.).
•	Их можно применять просто для подключения телефонов.
•	Их можно использовать для подключения дополнительных или демонст-
рационных компьютеров.
•	Стоимость материалов составляет, как правило, всего 5—10% обшей
стоимости.
•	Гораздо дешевле проложить весь кабель сразу, чем делать это позже.
При прокладке кабеля по всему зданию можно установить дополнитель-
ные розетки в холлах, конференц-залах, столовых и даже ванных комнатах.
Сети проникают повсюду.
Стандарты кабельных систем
Необходимость обеспечения всех видов деятельности, протекающей
внутри современных зданий, обуславливает потребность в крупной и сложной
кабельной инфраструктуре. Если кто-то заглянет в обычный распределитель-
ный шкаф, он будет потрясен, увидев его стенки, сплошь покрытые
непомеченными проводами одного цвета.
С целью улучшения прослеживаемости и стандартизации кабельных
систем зданий в феврале 1993 г. был выпущен административный стандарт на
телекоммуникационную инфраструктуру коммерческих зданий (TLA/EIA-606).
Этот стандарт устанавливает требования, а также принципы идентификации
и документирования телекоммуникационной инфраструктуры. Он касается
следующих аспектов:
•	оконечной аппаратуры;
•	кабелей;
•	прокладки кабелей;
•	расстояний между элементами оборудования;
•	цветовой маркировки;
•	обозначений стандартных компонентов.
В частности, определены стандартные цвета маркировки проводов
(табл. 15.4).
408
Чость II. Роботе е сетях
Таблица 15.4. Тоблицо цветовой маркировки по стандарту TIA/EIA-606
Тип оконечной	ц нагрузки		Код1	Комментарии
Граничная	Оранжевый	I50C	Центральные офисы
Сетевые соедине- Зеленый НИЯ		353С	Также применяется для вспомогатель- ных электросетей
Общее оборудова- Фиолетовый нис2		264С	Основное оборудование коммутации и передачи данных
Магистраль во го уровня	пер- Белый	-	Кабели
Магистраль рого уровня	вто- Серый	422С	Кабели
Станция	Синий	291С	Горизонтальные кабели
Магистраль между Коричневый зданиями		465С	Кампу сны е кабели
Разное	Желтый	101С	Служебные и сигнальные линии
Ключевые теле- Красный фо иные системы		184С	-
В соответствии с цветовой моделью Ратнопе.
Офисные АТС, компьютеры, ЛВС, мультиплексоры и т.д.
15.11.	Вопросы проектирования сетей
В настоящем параграфе рассматриваются вопросы, связанные с логиче-
ской и физической структурами сети. Этот материал касается сетей средней
величины. Представленные здесь идеи применимы для нескольких сотен
машин, но не подходят ни для трех, ни для трех тысяч компьютеров,
включенных в одну сеть. Мы также предполагаем, что у читателя достаточно
средств и он начинает работу' с нуля, хотя, наверное, это соответствует
реальности лишь частично.
Основной объем работ по проектированию сети состоит из определения:
•	типов сред передачи;
•	топологии и способов прокладки кабелей;
•	системы повторителей, мостов и маршрутизаторов.
Еше один ключевой вопрос проектирования сети — контроль перегрузки.
Например, распределенные файловые системы (NFS) очень сильно загружают
сеть, поэтому файловый сервис по магистральному кабелю осуществлять
нежелательно.
Ниже освещены аспекты, которые необходимо учитывать при проектп-
ровапин любой сети.
Архитектуре сети и орхитектурс здания
Архитектуру сети проще изменить, чем архитектуру здания, но обе они
должны нормально сосуществовать. Если же имеется возможность проекти-
ровать сеть до постройки здания — вам крупно повезло, поэтому будьте
щедрым. Однако в большинстве случаев здание и технический отдел компании
Глово 15 Сетевые оппоротные средство
409
на момент проектирования сети уже существуют и являются жесткими
ограничивающими факторами.
В готовых сооружениях сеть должна адаптироваться к архитектуре здания,
а не противостоять ей. В современных зданиях помимо высоковольтной
электропроводки, водо- и газопроводов иногда имеются каналы для прокладки
кабелей. Часто монтируются подвесные потолки — настоящая удача для тех,
кто устанавливает сеть. Во многих университетских городках и офисах
существуют туннели, которые облегчают создание сетей.
Необходимо сохранять целостность брандмауэров*. При прокладывании
кабеля через брандмауэр отверстие должно соответствовать диаметру кабеля
и заполняться негорючим веществом Выбирая кабель, учитывайте наличие
приточной вентиляции. Если узнают, что вы нарушили правила пожарной
безопасности, от вас потребуют устранить созданные проблемы, даже если
для этого придется разрушить всю сеть и построить ее заново
Логическая структура сети должна соответствовать физическим ограни-
чениям. накладываемым на нее архитектурой зданий, в которых будет
функционировать сеть. Приступая к проектированию, помните, что можно
очень легко найти логически красивое решение, а затем вдруг обнаружить,
что реализовать его физически сложно или вообще невозможно.
Существующие Сети
Этот материал касается компьютерных сетей, но во многих организациях
уже используются сети кабельного телевидения и телефонные сети, по
которым можно передавать данные. Среди них часто встречаются волокон-
но-оптические линии связи. Если ваша организация готовится к установке
новой телефонной системы, купите побольше волоконного кабеля и попро-
сите проложить его одновременно с телефонным.
Нам представилась такая возможность пару лет назад. Мы спросили
подрядчиков, не могли бы они проложить для нас немного волоконно-оп-
тического кабеля. Они ответили: “Конечно, и даже бесплатно”, а затем слегка
опешили, когда мы появились с грузовиком, полным кабеля.
Модернизация
Прогнозировать потребности на десять лет вперед очень сложно, особенно
а области вычислительной техники н сетей. Поэтому, проектируя сеть, всегда
нужно иметь в виду перспективы ее расширения и увеличения пропускной
способности Прокладывая кабель, особенно в труднодоступных местах,
протягивайте в три-четыре paj больше пар, чем нужно. Помните: основная
часть стоимости установки приходится на оплату' труда, а не на материалы.
Даже если не планируется использовать волоконно-оптические линии
немедленно, разумно будет все же проложить немного оптоволокна, особенно
если известно, что впоследствии протянуть его будет гораздо труднее.
Прокладывайте и многомодовый, и одномодовый кабель; всегда бывает так,
что нужным оказывается как раз тот кабель, который не проложен.
Речь идет о брандмауэрах в их перво начальном смысле: бетонных, кирпичных или огне-
упорных стенах, которые препятствуют распространению огня по всему зданию. Значитель-
но отличаясь от сетевых брандмауэров, они так же важны.
410
Чость II. Робота в сетях
Перегрузка
Сеть подобна цепи: ее качество определяется самым слабым или самым
медленным звеном. Производительность Ethernet, как и многих других
сетевых архитектур, при увеличении нагрузки падает.
Бездисковые клиенты, концентраторы терминалов, иестыкуклциеся ин-
терфейсы, низкоскоростные каналы связи — все это может привести к
перегрузке. Эффективный способ борьбы с ней — локализация трафика путем
создания подсетей и установки маршрутизаторов. Подсети можно использо-
вать и для изоляции компьютеров, задействованных в отдельных экспери-
ментах. Трудно проводить эксперимент на нескольких компьютерах, если нет
надежного и легкого способа изолировать их физически и логически от
остальной части сети.
Обслуживание и документирование
Наш опыт показывает, что удобство обслуживания сети напрямую зависит
от качества ее документации. Точная, полная, своевременно корректируемая
документация — абсолютно необходимое условие.
Кабели следует маркировать во всех точках подключения нагрузки и через
каждые один-два метра, чтобы их можно было легко узнавать*. Рекомендуем
вкладывать копии местных монтажных схем в распределительные шкафы,
чтобы при всех нзменениях эти экземпляры можно было откорректировать
на месте. Раз в несколько недель необходимо переносить все корректировки
в электронную базу данных.
Стыки между крупными системами в виде повторителей, мостов,
маршрутизаторов и даже соединителей могут облегчить отладку, поскольку
они позволяют изолировать части сети и отлаживать их по отдельности.
Полезно также ставить стыки между политическими и административными
областями.
15.12.	Вопросы управления
Если необходимо обеспечить нормальную работу сети, некоторые аспекты
управления нужно централизовать, некоторые — распределить, а неко-
торые — оставить на локальном уровне. Требуется сформулировать и
согласовать обоснованные “правила поведения добропорядочных граждан”
Типичная среда включает в себя:
•	магистральную сеть, соединяющую здания;
•	сети подразделений, подключенные к магистрали;
•	подсети рабочих групп в рамках подразделения;
•	соединения с внешним миром (например, с Internet или периферийными
филиалами).
Некоторые аспекты проектирования и реализации сетей должны предпо-
лагать повсеместный контроль, ответственность, сопровождение и финанси-
рование. Поскольку подразделения, как правило, стремятся свести к
минимуму собственные расходы, быстро растет число сетей с централизован-
ной оплатой каждого соединения. Вот основные объекты централизованного
управления:
 Некоторые производители поставляют катушки с уже промаркированным через каждый
метр кабелем.
Глово 15. Сетевые олпоротные средство
411
•	структура сети, в том числе использование подсетей, маршрутизаторов,
мостов и т.д.;
•	сам магистральный кабель, в том числе соединения с ним;
•	IP-адреса и имена компьютеров, имена поддоменов;
•	протоколы, главным образом с целью обеспечения их взаимодействия;
•	политика доступа в Internet
Имена доменов, IP-адреса и имена сетей в определенном смысле уже
находятся под централизованным контролем таких организаций, как AR1N
и ICANN, но координация использования этих элементов на локальном
уровне также необходима.
Центральный орган управления имеет общее представление о сети, ее
структуре, производительности и перспективах роста. Он может позволить
себе иметь собственное контрольное оборудование (и обслуживающий его
персонал) и следить за нормальной работой магистральной сети. Центральный
орган может настоять на правильном выборе структуры сети, даже если для
этого нужно будет дать подразделению указание купить маршрутизатор и
создать подсеть для подключения к магистральной сети университетского
городка. Такое решение может быть необходимым для того, чтобы новое
соединение не навредило работе существующей сети.
Если в сети работают разнородные компьютеры, операционные системы
и протоколы, обязательно нужно иметь “высокоинтеллектуальный'’ маршру-
тизатор (например, компании Cisco), который будет служить шлюзом межд>
сетями
15.13.	Рекомендуемые поставщики
За 15 с небольшим лет нашей рабогы по инсталляции сетей во всем
мире мы несколько раз обжигались па продуктах, которые не соответствовали
спецификациям, имели завышенную цену, неправильно указанные характе-
ристики или как-то иначе не оправдывали наши ожидания. Ниже приведен
список поставщиков, которым мы доверяем, которых рекомендуем и услугами
которых пользуемся сами.
Кабели и соединители
АМР
www.amp.com
Antxter
www. an ixier. com
Belden Cable
www.belden.com
Krone
www.krone.com
Lantech
hw. lantechinc. com
Newark Electronics
ww. newark.com
The Siemon Companj
www siemon.com
Black Box Corporation
www blackbox.com
Контрольно-измерительная аппаратура
Fluke Corporation	Acterna
www.fluke com	www.actema.com
Марш рутизатор ы
Cisco Systems
www.cisco.com
412
Чооь II. Робота в сетях
15.14.	Рекомендуемая литература
•	Groth, David and Jim McBee. Cabling; The Complete Guide to Network Wiring.
Sybex. 2000,
•	Seifen. Rich Gigabit Ethernet. Reading, MA: Addison-Wesley. 1998.
•	ANSI/TIA/E1A-568-A, Commercial Building Telecommunications Cabling Stand-
ard. и ANSI/T1A/EIA-606. Administration Standard for the Telecommunications
Irfrestructure of Commercial Buildings, — это стандарты построения кабель-
ных систем для телекоммуникационной промышленности. К сожалению,
они доступны не бесплатно. Посетите Web-узел www.tiaonline.org.
Советуем также посетить Web-узел Чарльза Сперджона (Charles Spurgeon),
целиком посвященный Ethernet:
http://wwwhost.ots.utexas.edu/eihernei/eihemet-home.html
J & Система доменных имен

К Internei подключены миллионы компьютеров. Как управлять ими
всеми, если они принадлежа! разным странам, сетям и административным
группам? Этой пели служат два элемента глобальной сетевой инфраструктуры,
система доменных имен (Domain Name System. DNS), которая отслеживает
информацию об именах компьютеров, и система маршрутизации в Internet,
контролирующая соединения между компьютерами.
В настоящей главе речь пойдет о DNS. Эта система выполняет несколько
задач. но основная ее работа — преобразование имен компьютеров в
IP-адреса и наоборот Пользователям и программам пользовательского уровня
удобнее обращаться к компьютерам по именам, но низкоуровневое сетевое
программное обеспечение понимает только числовые адреса. DNS выполняет
роль промежуточной связующей системы.
DNS представляет собой распределенную базу данных. Сведения о
компьютерах хранятся на многих серверах, которые автоматически вступают
в контакт Дрхг с другом, запрашивая данные и обмениваясь информацией.
16.1.	DNS для нетерпеливых: добавление нового
компьютера
Данная глава имеет размер небольшой книги, поэтому, прежде чем
погружаться в детали функционирования DNS, ответим на наиболее часто
задаваемый вопрос, как добавить новый компьютер в сеть, где уже
используется DNS? Ниже продемонстрировано, как это сделать, копируя и
редактируя существующие записи для похожего компьютера: lenipiatehosi.
my.domain.
Шаг 1 Выберите для нового компьютера сетевое имя и IP-адрес, согласован
последний с системным администратором или провайдером Internet.
414
Чость II Робота в сетях
Шаг 2. Найдите похожий компьютер в той же подсети. Мы воспользуемся
записями этого компьютера в качестве модели для новых записей.
Шаг 3. Зарегистрируйтесь на компьютере, являющемся главным сервером
имен.
Шаг 4. Просмотрите файл /etc/named.conf или /etc/namedb/named.conf
•	Найдите в инструкции options строку directory, где сообщается
местоположение файлов зон в системе (параграф 16.9) В этом файле
находятся реальные имена и IP-адреса компьютеров.
•	Отыщите в инструкциях zone имена файлов зон прямого и обратного
преобразований для сети, которой принадлежит новый 1Р-алрес
(параграф 16.9).
Шаг 5. Перейдите в каталог файлов зон и отредактируйте файл зоны прямого
преобразования (для этого придется запустить систему RCS или программу
sudo). Найдите записи для компьютера-образца. Они будут выглядеть
примерно так:
templarehost	IN А 128.136.243.100
IN	MX	10 mail-hub
IN	MX	20 Templatehost
Шаг 6. Скопируйте эти записи и модифицируйте их должным образом для
нового компьютера. Записи файла могут быть отсортированы по именам
компьютеров, поэтому следуйте принятым соглашениям. Измените также
порядковый номер записи SO А в начале файла (это первое из пяти чисел в
данной записи). Порядковый номер может только возрастать. Прибавьте к
нему единицу, если порядковые номера выбираются произвольно, или
поместите в данное поле текущую дату’, если в системе используется подобное
соглашение.
Шаг 7. Откройте файл зоны обратного преобразования , скопируйте запись
для компьютера-образца и отредактируйте ее. Она будет выглядеть примерно
так:
100	IN PTR templatehost.my.domain.
Необходимо также обновить порядковый номер записи SOA в данном файле.
Если в файле зоны обратного преобразования отображается не только
последний байт IP-адреса каждого узла, то числа нужно вводить в обратном
порядке. Например, запись
100	.243	IN PTR templatehost.my.domain.
соответствует IP-адресу 128.138.243.100 (здесь зона обратного преобразования
относится к домену 138.128.in-addr.arpa, а не 243.138.128.in-addr.arpa).
Шаг 8. Не выходя из системы, вызовите команду ndc reload .
Шаг 9. Попробуйте выполнить команду ping или traceroute, задав имя нового
компьютера, даже если он еще не сконфигурирован. Сообщение “host
unknown” (неизвестный узел) говорит о том, что вы ошиблись. Сообщение
“host not responding” (узел не отвечает) означает, что все в порядке. Можно
Этот файл может храниться где угодно, например у провайдера. В этом случае изменения
придется вносить там.
До появления версии 8 в Solaris отсутствовала программа ndc. Если она не была установлена
вручную из дистрибутива BIND, придется послать демону named сигнал HUP, чтобы
инициировать перезагрузку.
Глово 16. Системе доменных имен
415
также проверить конфигурацию системы посредством программы dig
(параграф 16.14).
16.2.	История DNS
В старые добрые времена таблицы соответствия имен и адресов хранились
в одном текстовом файле, который велся централизованно и рассылался на
все компьютеры сети ARPANET Никакой иерархии в именах машин не
было, и процедура присваивания имени компьютеру предполагала проверку
уникальности выбранного имени в масштабах страны. Объем изменений был
огромен и поглошал большую часть пропускной способности сети ARPANET,
поэтому в содержимом данного файла часто не отображалось реальное
состояние сети.
Вскоре стало ясно, что статическая таблица компьютеров явно неадек-
ватна потребностям большой и растущей сети ARPANET. DNS решает
проблемы, с которыми не справилась такая таблица, используя дае концеп-
ции. иерархию имен компьютеров и распределение обязанностей. Систему
доменных имен формально описал Пол Мокалетрис (Paul Mockapetris) в
документах RFC882 и RFC883 (1983 г.), обновив спецификацию в документах
RFC1034 и RFC1035 (1987 г.). Пол, кроме того, создал первую версию DNS
не для платформы UNIX.
Работа по реализации DNS в UNIX была начата в 1984 г, четырьмя
аспирантами университета Беркли. Дугласом Терри (Douglas Terry). Марком
Пейнтером (Mark Painter). Дэвидом Ригглом (David Riggle) и Сонг Ньян Чжоу
(Songnian Zhou). Эстафету подхватил Ральф Кемпбелл (Ralph Campbell),
сотрудник исследовательской группы по вычислительным системам, который
начал встраивать DNS в BSD UNIX. В 1985 г. Кевин Данлап (Kevin Dunlap),
инженер DEC, временно работавший в Беркли, принял на себя руководство
проектом и создал пакет BIND (Berkeley Internet Name Domain — система
доменных Intemet-имен реализации университета Беркли). Майк Кареле
(Mike Karels), Фил Альмквист (Phil Almquist) и Пол Викси (Paul Vixie)
сопровождали этот пакет в течение многих лет. Он входит в большинство
дистрибутивов UNIX и, кроме того, доступен на Web-узле www.isc.org.
ISC (Internet Software Consortium — консорциум разработчиков програм-
много обеспечения для Internet) — это некоммерческая организация, управ-
ляющая разработкой важнейших программных компонентов для Internet,
включая пакет BIND. Пол Викси в настоящее время отвечает в этой
организации за сопровождение всех вариантов BIND 8, пользуясь помощью
многочисленных добровольцев Параллельно с этим консорциум занимается
созданием пакета BIND 9 за счет финансовых средств ряда поставщиков
операционных систем, правительственных учреждений и других компаний.
ISC также предоставляет пользователям своих продуктов различные виды
технической поддержки, включая помощь в настройке и даже программиро-
вании. Некоторые организации оказывают консорциуму финансовую под-
держку посредством заключения дорогостоящих контрактов иа обслуживание,
хотя никогда не звонят в сервисный центр.
Документы RFC 1034 и RFC 1035 по-прежнему считаются базовыми
спецификациями DNS, хотя за последнее десятилетие появилось более 30-ти
других документов, видоизменивших или дополнивших различные аспекты
DNS (перечислены в конце главы). В настоящее время не существует единого
стандарта, в котором все эти компоненты были бы сведены воедино.
Традиционно определение DNS звучало так: “Это то, что реализует пакет
416
Чость II. Робото в сетях
BIND”. Но такое определение становится все меиее точным по мере того,
как появляются другие серверы DNS.
Система доменных имен реализована для разных платформ, но в этой
книге мы будем рассматривать только пакет BIND. Компания None!
перенесла BIND в Windows NT, передав права на полученный продукт
обратно организации ISC. В результате, начиная с версии 8.2, пакет BIND
доступен также в среде NT. Благодаря стандартизации протокола DNS
различные DNS-серверы, работающие как в UNIX, так и в других операци-
онных системах, могут свободно взаимодействовать и обмениваться данными
друг с другом. Во многих организациях имеются UNIX-серверы, выступающие
в роли серверов DNS для рабочих станций Windows.
16.3.	Оснс.зные задачи ''NS
DNS определяет:
•	иерархически организованное пространство имен компьютеров;
•	таблицу имен компьютеров, реализованную в виде распределенной базы
данных:
•	“распознаватель” — клиентскую библиотеку функций, осуществляющих
запросы к базе данных DNS;
•	усовершенствованные средства маршрутизации электронной почты;
•	механизм поиска сервисов в сети;
•	протокол обмена информацией об именах.
Узлу, подключенному к Internet, система доменных имен нужна для
полноценного участия в работе сети. Вести локальный файл /etc/hosts с
данными о каждом компьютере, с которым когда-нибудь понадобится
установить контакт, невозможно в принципе.
В каждой организации хранится один или несколько фрагментов
распределенной базы данных, составляющей всемирную систему DNS.
В состав фрагмента входят два или более текстовых файла, содержащих
записи об имеющихся в организации компьютерах. Запись — это отдельная
строка, состоящая из имени компьютера, обозначения типа записи и
нескольких информационных полей.
Например, строки
forklift	IN А 192.108.21.7
IN	MX	10 chimchim.xor.com
в файле зоны прямого преобразования и строка
IN	PTR forklift.xor.com
в файле зоны обратного преобразования устанавливают соответствие между
узлом forklift.xor.com и IP-адресом 192.108.21.7
DNS — это клиент-серверная система. Серверы (называемые серверами
имен) загружают данные из клиентских DNS-файлов в память и пользуются
ими при ответах на запросы как от внутренних клиентов, так и от внешних
компьютеров Все сетевые компьютеры должны быть клиентами DNS. но
лишь некоторым из них требуется быть серверами имен.
В небольшой организации (несколько компьютеров в одной сети) можно
запустить сервер на одной из машин или попросить lnternei-провайпера
обеспечить сервис DNS. Средних размеров организация с несколькими
Г ю и 16 Системе доменных имен
417
подсетями должна иметь серверы DNS в каждой подсети, чтобы снизить
общую нагрузку на сеть. Очень большая организация может разделить свои
домен на поддомены и запустить для каждого из них несколько серверов.
16.4.	Что нового в DNS
За последние несколько лет в DNS был внесен ряд важных изменений.
В этом параграфе мы расскажем об основных изменениях и о том. где можно
узнать о них более подробно.
И сам протокол DNS, и пакет BIND постоянно обновляются. В DNS
появились новые типы записей о ресурсах и добавился ряд новых функцио-
нальных возможностей Пакет BIND был полностью переписан с учетом
поддержки многопотоковых и многопроцессорных систем. Основные изме-
нения представлены в табл. 16.1.
Тоблицо 16.1. Новые возможности в DNS и BIND		
ПорогроФ	RFC	Описание	1
16.11	2052	Записи SRV. задающие местоположение сервисов
16.11	—	Записи А6, задающие адреса IPv6
16.1!	2672- 2673	Записи DNAME, предназначенные для поиска адресов IPv6
16.11	2317	Бесклассовое формирование подсетей в домене in-addr.arpa (новое применение записи С NAME)
16.11'	-	Применение домена ip6.arpa для преобразования адресов IPv6 в сетевые имена
—1	-	Модуль распознавания, поддерживающий стандарт IPv6
16.7	2671	EDNS0 — изменения и расширения протокола
16.9	1996	Асинхронные уведомления об изменениях зон
16.12	2136	Динамические обновления (для организаций, в которых используется протокол DHCP)
16.12	1995	Инкрементные зонные пересылки
16.13	2535- 2541	Спецификация DNSSEC (аутентификация и безопасность зонных данных)
16.13	2845	Спецификации TSIG/TKEY для сигнатур и ключей шифро- вания транзакций
1 Не описаны в данной книге или, в случае домена трб.агра, описаны лишь в общих
чертах.
Некоторые из новых возможностей — это огромные проекты, еше не
прошедшие стандартизацию в организации IETF. Рабочие группы, отвечаю-
щие за составление стандартов, имеют в своих рядах хороших писателей, но
им недостает программистов, которые занимались бы тестированием специ-
фикаций на постоянной основе. Поэтому' некоторые из наиболее свежих
спецификаций очень трудно или вообще невозможно реализовать. В текущей
версии пакета BIND {8.2.2-Р5) имеется лишь часть нз перечисленных выше
новых возможностей. В первоначальный выпуск пакета BIND 9 входят почти
все они, но не в своем финальном виде.
418
Чость II. Роботе в сетях
Два дополнения — поддержка стандарта IPv6 и спецификация DNSSEC —
заслуживают более подробных комментариев. В IPv6 длина 1Р-адреса возросла
с 32-х битов до 128-ми. Если бы этот стандарт был полностью реализован,
он оказал бы огромное влияние на всю сеть Internet Пакет BIND 9
поддерживает те компоненты IPv6, которые прошли процесс стандартизации,
но маловероятно, чтобы на протяжении жизненного цикла данной книги
стандарт IPv6 получил широкое распространение. Поэтому мы лишь вкратце
затронем вопросы поддержки IPv6 в BIND 9.
Спецификация DNSSEC является попыткой добавить средства аутенти-
фикации к базе данных и серверам DNS. В ней используется алгоритм
шифрования с открытым ключом для проверки источника данных DNS и
их целостности В этой схеме посредством DNS распространяются не только
данные о компьютерах. но и ключи шифрования.
Описаны также более простые механизмы аутентификации, например
системы совместного использования секретного ключа. По такой ключ
должен передаваться каждой паре серверов, желающей осуществлять взаим-
ную аутентификацию. Подобная схема хорошо работает в небольшой орга-
низации, располагающей несколькими серверами, однако она неприменима
в глобальном масштабе. BIND 9 реализует системы аутентификации DNSSEC
(используется открытый ключ) и TSIG (используются сигнатуры транзакций
в виде совместных секретных ключей).
16.5.	Пространство имен DNS
В следующих разделах мы сначала рассмотрим обшую структуру DNS
(спецификацию), а затем опишем файлы конфигурации, используемые
пакетом BIND (реализацию). Те. кто хорошо знаком с DNS. могут сразу
переходить к параграфу 16.8 или 16.9.
В реальном мире термины DNS и BIND часто заменяют друг друга. Тем
не менее в этой главе мы сделаем попытку (возможно, неудачную) сохранить
различие между ними.
Пространство имен DNS имеет вид дерева доменов. Каждый домен —
это отдельный фрагмент пространства имен, которым управляет один
административный субъект. Корень дерева носит нмя (точка); пол ним
находятся домены верхнего, или корневого, уровня. Домены верхнего уровня
раньше были относительно постоянны, но в настояшее время организация
ICANN* прорабатывает вопрос создания новых доменов.
Олпа половина дерева доменов описывает преобразование сетевых имен
в IP-адреса, а другая — IP-адресов обратно в сетевые имена. Первая
процедура называется прямым преобразованием, и связанные с ней информа-
ционные файлы пакета BIND именуются файлами зон прямого преобразо-
вания. Вторая процедура называется обратным преобразованием, а
соответствующие файлы — файлами зон обратного преобразования.
По историческим причинам существуют два вида имен доменов верхнего
уровня. В США домены верхнего уровня изначально отражали организацион-
но-политическую структуру глобальной сети и, как правило, имели трехбук-
венные имена, например “conf’ или “edu". Некоторые из этих доменов
ICANN (Internet Corporation for Assigned Names and Numbers) — это организация no
назначению имен и адресов в internet, являющаяся руководящим органом глобальной сети
(см. параграф 13.1).
Глово 16 Системо доменных имен
419
(особенно “com", “org" и “net”) распространены также за пределами США
Все они называются общими или организационными доменами верхнего уровня
В табл. 16.2 перечислены наиболее важные общие домены и указано и\
первоначальное предназначение (после того как домен “сот” был оккупи
рован многочисленными организациями и многие “красивые", короткие
имена оказались занятыми, адресные канцелярии стали продавать имена н
доменах “org” и “net”, не обращая внимания на существовавшие доселе
ограничения).
Таблица 16.2. Организационные домены верхнего уровня
Домен	Для кого предназначен________________________________________
сот	Коммерческие компании
edu	Учебные заведения
gov	Правительственные учреждения
mil	Военные учреждения
net	Поставщики сетевых услуг
org	Некоммерческие организации
int	Международные организации
агра Верхний элемент дерева IP-адресов
Для большинства доменов вне США используются двухбуквенные коды
стран, принятые организацией ISO. Эти домены называются географическими
Домены обоих типов сосуществуют в одном глобальном пространстве имен
Некоторые коды стран приведены в табл. 16.3.
Тоблицо 16.3. Коды строн
—-----------------------------------------------------------------------
Код Строно
аи	Австралия
са	Канада
Ьг	Бразилия
de	Германия
fi	Финляндия
fr	Франция
jp	Япония
se	Швеция
ch	Швейцария
hu	Венгрия
иа	Украина
ru	Россия
Во многих странах организационная структура строится на базе домен- .»
второго уровня, прн этом правила именования могут быть разными
Например, научные учреждения в США относятся к домену “edtT. a ।
Японии — к домену ac.jp.
420
Чость II. Роботе в с».-= 
В Соединенных Штатах домен верхнего уровня “us” используется чаше
всего в сочетании с региональными доменами; например, bvsd.kl2.co.us —
домен школьного округа города Боулдер, штат Колорадо. Домен “us" никогда
не объединяется с организационными доменами, т.е. домена edu.us нет (пока).
Преимущество домена “us” заключается в том, что регистрация имен в нем
бесплатна или стоит очень недорого; за подробностями обратитесь на
Web-узел www.nic.us.
Торговцы доменами иногда выкупают пространства имен целых стран.
Например, домен республики Молдова, “md”, в настоящее время продается
медицинским заведениям и резидентам штата Мэриленд (MD), США. Другой
пример — островное государство Тувалу, код страны которого — “tv". Первая
сделка такого рода коснулась королевства Тонга (домен “to”). В настоящее
время активнее всего распродается домен острова-колонии Ниуэ (“пи”), а
одним из самых привлекательных является домен Туркменистана (“tm").
Иногда подобные сделки были выгодны этим странам, иногда — нет.
Широко практикуется также самовольный захват доменных имен. Пред-
приимчивые дельцы регистрируют имена, которые, по их мнению, обязатель-
но будут востребованы в будущем. Через некоторое время какая-нибудь ничего
не подозревающая компания пытается зарегистрировать аналогичное имя и
с удивлением обнаруживает, что оно занято. Ей приходится выкупать имя у
предусмотрительного владельца. Много лет назад один бизнесмен зарегист-
рировал доменные имена всех лыжных курортов" Колорадо и заработал
большие деньги, продавая имена по мере того, как администрации лыжных
курортов осваивали глобальную сеть. Стоимость хорошего имени в домене
“сот” колеблется от нескольких тысяч до нескольких миллионов долларов.
Недавно домен business.com был продан за 3,5 млн. долларов. Нам предло-
жили 50000$ за домен admin.com, который мы зарегистрировали несколько
лет назад после того, как оказалось, что домен sysadmin.com уже занят
журналом “/Sys/Admin*’.
В именах доменов не учитывается регистр. В контексте DNS домен
“Colorado” идентичен “Colorado" и “COLORADO”. В текущих реализациях
протокол DNS должен игнорировать регистр при сравнении имен, но
распространять имена в том регистре, в котором они указаны. Раньше
принято было домены верхнего уровня обозначать прописными буквами и
начинать с прописной буквы домены второго уровня. Сегодня пальцы очень
устают от работы с клавиатурой, и нормой стали строчные буквы.
Два новых свойства DNS — интернационализация имен и спецификация
DNSSEC — конфликтуют с точки зрения регистра символов. В международ-
ных доменных именах регистр важен и должен быть сохранен, а в DNSSEC
все имена переводятся в нижний регистр перед вычислением сигнатур.
Очевидно, в DNS вскоре будет официально принят нижний регистр для
внутренних криптографических вычислений, но фактические данные будут
рассылаться с учетом регистра. Потребуется разработать правила преобразо-
вания имен из международных кодировок во внутреннее представление.
Надеемся, что организация IETF сумеет разобраться в этих вопросах до того,
как новые технологии получат широкое распространение.
Полностью определенное имя компьютера, подключенного к Internet,
формируется путем прибавления имени домена к имени машины. Например,
boulder.colorado.edu — полное имя узла boulder, находящегося в университете
штата Колорадо. Другие организации могут использовать имя boulder, не
спрашивая на то разрешения, потому что полностью определенные имена их
компьютеров все равно будут другими.
Глово 16. Системе доменных имен
421
В DNS полные имена заканчиваются точкой, например “boulder.colo-
rado.edu.". Отсутствие завершающей точки свидетельствует об относительном
адресе. В зависимости от контекста, в котором используется относительный
адрес, к нему могут присоединяться различные дополнительные компоненты.
Пользователи DNS обычно не подозревают о существовании хвостовой точки
Более того, некоторые системы (например, электронная почта) неправильно
проинтерпретируют адрес, если в конце него указать точку.
Компьютеры часто имеют несколько имен К примеру, узлу bouider.colo-
rado.edu можно также дать имя www.colorado.edu или ftp.cotorado.edu, если в
названии требуется отразить предоставляемый сервис Вообще это достаточно
распространенная практика — делать “сервисные" имена (в частности, те,
что начинаются с "www”) мобильными, т.е. серверы можно переносить с
одного компьютера на другой, не меняя основное имя компьютера
Когда нам выделили домен colorado.edu, мы получили гарантию того,
что имя "Colorado" уникально в пределах домена “edu". Мы разделили этот
домен на поддомены в соответствии со списком факультетов нашего
университета Например, машина anchor на факультете вычислительной
техники носит Internet-имя anchor.cs.colorado.edu.
Создание каждого нового поддомена необходимо согласовывать с адми-
нистраторами домена, чтобы гарантировать уникальность имени. Записи в
конфигурационном файле родительского домена делегируют поддоменх
полномочия по управлению пространством имен
Хозяева своих доменов
Управление доменами верхнего уровня “com", "oq;”. “net" и “edu"
раньше осуществляла компания Network Solutions, 1пс,, по контракту с
Национальным научным фондом США. Теперь эта монополия ушла в
прошлое, и другие организации получили разрешение регистрировать домен-
ные имена в общих доменах. Что касается географических доменов, то ими
управляют региональные организации.
Были различные предложения по поводу того, чтобы разрешить частным
компаниям управлять своими собственными доменами верхнего уровня,
поэтому вполне вероятно, что в ближайшем будущем такие домены появятся.
Самую последнюю информацию можно получить на Web-узле www.icann.org.
Большинство провайдеров Internet предоставляет платные услуги по
peiистрании доменных имен В ответ на поступивший запрос они свя зываются
с адресными канцеляриями верхнего уровня и настраивают свои DNS-серверы
на поиск имен в пределах нового домена. Конечно, можно сократить прямые
затраты, самостоятельно связавшись с адресной канцелярией и организовав
собственный DNS-сервер, но вряд ли это приведет к обшей экономии денег.
Лучше поручить решение организационных вопросов провайдерам, хотя в
таком случае теряется прямой административный контроль над доменом
Даже если организация хочет запустить собственный DNS-сервер, она
все равно должна связаться с провайдером, так как на его сервере
осуществляется обратное преобразование адресов в доменные имена в рамках
CIDR-блоков. Нужно убедиться, что провайдер отключил этот сервис для
запрашиваемого блока адресов и передал организации соответствующие
полномочия.
О протоколе C1DR рассказываюсь в параграфе 13.4.
422
Чость II Роботе в сетях
Прямые и обратные преобразования по возможности должны осуществ-
ляться в одном месте. Некоторые провайдеры с удовольствием отдают
контроль над прямым преобразованием, но отказываются делать то же самое
в случае обратного преобразования. Подобное разделение обязанностей ведет
к проблемам синхронизации. В параграфе 16.11 описан красивый прием,
позволяющий посредством записей CNAME управлять делегированием даже
крошечных фрагментов адресного пространства.
Домены DNS должны (более того, обязаны; см. RFC12I9) обслуживаться
как минимум двумя серверами. Чаще всего в организации функционирует
главный сервер, а серверы провайдера являются резервными. После того как
система сконфигурирована, серверы провайдера автоматически загружают
информацию из главного сервера организации. Изменения в конфигурации
DNS отражаются на резервных серверах, не требуя вмешательства админи-
страторов любой из сторон.
Выбор имени домена
Некоторые имена запрещены. Это. в частности, относится к уже
используемым именам. Ряд имен, выбор которых ранее был запретен, теперь
доступен; таковыми являются комбинации имен доменов верхнего уровня
(например, edu.com*). а также имена, содержащие повторяющиеся компо-
ненты (например, х.х.сот”).
В предыдущем издании книги-мы советовали выбирать имена так. чтобы
они были короткими, удобными для ввода и идентифицировали использую-
щую их организацию. Сегодняшняя действительность такова, что все
хорошие, короткие имена заняты, по крайней мере в домене "сот” Часть
из них предусмотрительно скуплена дельцами, но в основном все они
используются реальными лицами.
Документ RFC 1032 рекомендует, чтобы имена доменов второго уровня
имели в длину не более 12 символов, несмотря на то что DNS допускает
использовать в каждой составляющей до 63-х символов и 255 символов в
полном имени. Двеналпатисимвольное ограничение часто игнорируется,
поэтому нет смысла его придерживаться (не стоит, однако, забывать о том,
что длинные имена очень неудобно вводить).
Взрывоподобный рост числа доменов
Протокол DNS предназначался для того, чтобы можно было связать
доменное имя организации с сервером имен, закрепленным за этой
организацией. Данная схема должна была применяться во всех организациях,
подключенных к Internet. Но сегодня сеть Internet стала элементом массовой
культуры, и доменные имена есть у многих коммерческих продуктов,
кинофильмов, спортивных событий и т.д. Имена наподобие iwinkies.com или
playstation.com ие связаны (напрямую) с компаниями, создавшими продукт:
они используются скорее в рекламных целях. Не ясно, сможет ян DNS
справиться с подобным разрастанием глобальной сети Проблема заключается
в том. что дерево имен DNS является эффективной информационной
структурой лишь в том случае, когда в нем прослеживается четкая иерархия.
Следует отметить, что многие версии BIND не работают с такими именами.
Не все имена с повторяющимися компонентами считались нелегальными. Например.
xinet.xinet.com всегда было допустимым именем, поскольку имя домена — xinct.com, а в
нем есть компьютер xinet.
Глово 16. Системе доменных имен
423
Но когда каждая организация дает сотням или тысячам своих продуктов
доменные имена, расположенные у самой вершины дерева, о какой бы то
ни было иерархии говорить не приходится.
На самом деле нам нужна служба каталогов, которая связывала бы
названия различных торговых марок с соответствующими компаниями,
предоставив DNS возможность заниматься только IP-адресами. В своем
начальном виде эта идея реализуется в современных Web-броузерах посред-
ством сервиса, предоставляемого компанией RealNames Corporation. Но эта
услуга не бесплатна; только организации, подписавшиеся на нее и заплатив-
шие определенную сумму денег, смогут иметь свои ключевые слова в базе
данных. Другое возможное решение заключается в установлении принуди-
тельной иерархии имен, однако подобное никогда не случится: все зашло
слишком далеко и компании, имеющие серверы .сот. заняли прочное место
на рынке.
Регистрация домена второго уровня
Для того чтобы получить домен второго уровня, необходимо подать заявку
в орган управления соответствующего домена верхнего уровня. В настоящее
время организация ICANN занимается аккредитацией многочисленных
агентств, управляющих регистрацией имен в географических доменах. На
момент написания книги существовало около 25-ти регистрационных бюро
и еще почти 80 проходили процедуру аккредитации. Полный их список
имеется на Web-узле www.icann.org.
В Европе заявления о предоставлении доменных имен принимает
организация CENTR (Council of European National Top-level domain Regis-
tries — Совет европейских национальных доменных канцелярий верхнего
уровня). Ее Web-алрес — www.centr.org. Там же можно узнать адреса
региональных регистрационных бюро. В азиатско-тихоокеанском регионе
ответственным органом является организация APN1C (Asia-Pacific Network
Information Center — Азиатско-тихоокеанский центр сетевой информации);
www.apnic.net.
Для того чтобы заполнить бланки регистрации, нужно назначить ответ-
ственного технического специалиста, ответственное административное лицо
и хотя бы два компьютера, которые будут серверами домена. Кроме того,
нужно выбрать доменное имя, еще никем не занятое.
Создоние собственных поддоменов
Процедура формирования поддомена аналогична процедуре создания
домена второго уровня, за исключением того, что ответственный орган теперь
находится в пределах самой организации. Этот процесс предусматривает
следующие этапы;
•	выбор имени, уникального для данного поддомена;
•	назначение двух илн более компьютеров серверами нового домена;
•	согласование всего сделанного с администратором родительского домина
Прежде чем осуществлять передачу полномочий, серверы родительского
домена должны убедиться в том. что серверы имен дочернего домена
сконфигурированы и работают правильно Если данное условие не выполня-
ется. произойдет то. что называется напрасным делегированием. Подробнее об
этом говорится в параграфе 16.14.
424
Чость II. Роботе в сетях
16.6.	Пакет BIND
BIND (Berkeley Internee Name Domain — система доменных Internet-имен
реализации университета Беркли) — это открытый программный пакет,
предлагаемый организацией ISC. Он реализует протокол DNS и функциони-
рует в качестве сервера имен на платформах UNIX (с недавнего времени
также в Windows NT).
Версии пакета BIND
Имеются три основные разновидности пакета. BIND 4. BIND 8 и
BIND 9. Первая из них существовала с конца 80-х гг. (ее выпуск примерно
соответствует появлению документов RFC 1034 и RFCI035). Вторая была
выпущена в 1997 г., а третья — в середине 2000 года. Версий 5, 6 и 7 никогда
не было. Существовала красивая легенда, будто версия 8 содержала в себе
столь значительные изменения, что авторы решили увеличить ее номер в два
раза по сравнению с предшественницей. Это, конечно же. не так. Просто
пакет BIND 8 предназначался для 4.4BSD, где номера версий многих
программных продуктов были доведены до восьми (то же самое произошло
с системой sendmail, которая также “перескочила” через несколько номеров)
Пакет BIND 8 содержит множество технических новннок, способствую-
щих повышению эффективности, надежности и безопасности. В BIND 9
планка поднялась еше выше: поддерживаются многопроцессорные системы,
потоковые операции, реальные технологии безопасности (шифрование с
открытым ключом), стандарт IPv6, инкрементные зонные пересылки и многое
другое. Пакет BIND 9 оказался полностью переписанным и. по сути,
реализованным заново. В нем изолированы фрагменты кода, зависящие от
платформы, благодаря чему стало легче переносить пакет в другие опера-
ционные системы. Внутренняя структура пакета BIND 9 существенно изме-
нилась, но процедура конфигурации осталась той же.
Поддержка пакета BIND 4 осуществляется только в виде выпусков
“заплат”, закрывающих бреши в механизме защиты. Вскоре даже такая
поддержка прекратится. Ожидается, что через год или два, когда работа пакета
BIND 9 стабилизируется и он получит широкое распространение, уйдет в
небытие и BIND 8. В этой главе мы будем описывать язык конфигурирования
обоих пакетов: BIND 8 и 9.
Многие организации затягивают с обновлением версий, поскольку им не
хочется менять работу полностью функционирующей системы. Те, кто до сих
пор работает с BIND 4, могут воспел ьзоввться Perl-сценарием named-boot -
conf.pl, входящим в дистрибутивы версий 8 и 9. Он преобразует конфигура-
ционный файл из формата версии 4 в эквивалентный формат версии 8 или 9.
Записи самой базы данных DNS менять не требуется. Конечно, преобразо-
ванный конфигурационный файл не будет поддерживать новые свойства
версий 8 и 9, но зато он послужит отправным пунктом для начала расширения
системы.
Определение текущей версии
Поставщики операционных систем часто не указывают, какие версии
внешних программных пакетов они включают в свои дистрибутивы. Поэтом}
нам, администраторам, приходится выступать в роли ишеек. чтобы узнать, с
какой версией мы имеем дело. В случае пакета BIND получить интересующую
I ново 16 Системо доменных имен
425
нас информацию можно посредством программы dig, входящей в состав
пакета. Команда
dig gсервер version.bind txt chaos
возвращает номер версии при условии, что эта информация не была удалена
из конфигурационного файла. К примеру, данная команда выдает нужный
результат для сервера vix.com:
% dig @bb. гс. vix. com version.bind txt. chaos
VERSION.BIND. OS CHAOS TXT "е.2.3-Т4В"
но в случае сервера cs.colorado.edu она бессильна:
% dig 6niroe.c8.coLorado.edu version.bind txt chaos
VERSION.BIND.	OS CHAOS TXT "wouldn't you like to know...”
Некоторые администраторы конфигурируют пакет BIND так. чтобы номер
его версии нельзя было узнать посредством такого рода запросов. Считается,
что это повышает безопасность системы. Мы не одобряем подобную практику,
хотя она действительно способна поумерить пыл некоторых юных хакеров
Подробнее о задании версии речь пойдет в параграфе 16.9.
Обычно можно узнать версию BIND, просматривая журнальные файлы
в каталоге /var/log или его эквивалентах. Например, демон named при запуске
регистрирует свой номер версии через систему Syslog (средство "daemon'’}.
Поиск посредством команды grep дает такие результаты:
Dec 13 16:32:27 disaster named[2399]: starting, named 4.9.7 Wed Sep 2
09:39:12 GMT 1990 PHNE14618
Dec 13 16:35:13 sued named[93251: starting, named 8.2.2-P3 Wed Nov 10
17:27:59 MSI 1999 millertghaxrus /nfs/depot/src/cs/Bind/bind-
8.2.2-РЗ/ooj / sunfl---SunOS 4/bin/named
О системе Systog рассказывалось в главе 11.
Первая строка получена в HP-UX 11.00 (дистрибутивный вариант систе-
мы), вторая — в SunOS (система некоторое время была в эксплуатации) Во
втором случае данные немного не верны, поскольку “заплата'’ 4 дня
BIND 8.2.2 по какой-то причине не повысила отображаемый уровень
“заплаты”. В действительности полная версия пакета — 8.2.2-Р4.
Если демон named инсталлирован. но система не запускает его па этапе
начальной загрузки, вызовите этот демон самостоятельно (без аргументов} от
имени пользователя root Демон зарегистрирует свои номер версии, обнаружит
отсутствие конфигурационного файла и завершится.
В табл 16.4 указано, какие версии BIND входят в состав наших тестовых
систем. В версиях ниже 8.2.2-РЗ имеются проблехгы с безопасностью.
Тоблицо 16.4. Версии BIND в розничных опероционных системох
Системе	Версия ОС	Версия BIND
Solaris	7 или 8	8.1.2
HP-UX	11.00	4.9 7
Red Hat	6.1	8.2
	6.2	8.2.2-Р5
FreeBSD	3.4 или 4.0	8.2.2-Р5
426
Чость II. Роботе в сетях
Известно, что в Red Hat номера версий фиксируются и не меняются при
последующей установке “заплат”. Поэтому при поиске номера может
отображаться недостоверная информация, как в показанном выше примере.
В Red Hat внутренние номера версий добавляются к именам файлов,
содержащих исходные тексты пакета, и иногда к ним присоединяется внут-
ренний номер исправления или “заплаты”. Например, birtd-8.2-7 arch.rprn —
это седьмое исправление исходной версии 8.2.
Компоненты покето BIND
В пакет BIND входят три компонента:
•	демон named, отвечающий на запросы;
•	библиотечные подпрограммы, контактирующие с серверами распределен-
ной базы данных DNS;
•	программы nslookup, dig, host, позволяющие выполнять DNS-запросы из
командной строки.
Согласно терминологии, принятой в DNS, демон вроде named (или
компьютер, на котором он работает) называется сервером имен, а программа-
клиент. которая обращается к нему, — распознавателем. Ниже мы вкратце
рассмотрим функции всех этих компонентов, а реальная конфигурация пакета
BIND описывается начиная с параграфа 16.8.
Демон nomed: сервер имен покето BIND
Демон named отвечает на запросы об именах компьютеров и их IP-адресах.
Если демону не известен ответ на какой-нибудь запрос, он опрашивает другие
серверы и помещает результаты их ответов в кэш. Кроме того, этот демон
осуществляет зонные пересылки, копируя данные между серверами домена.
(Зона — это домен без своих поддоменов. Серверы имен работают именно
с зонами, но часто говорится “домен", хотя на самом деле подразумевается
“зона”.)
Серверы имен работают в нескольких режимах, различающихся по
нескольким аспектам, поэтому дать их точное определение нелегко. Ситуация
усложняется еше и тем, что один и тот же сервер может играть неодинаковые
роли в разных зонах. В табл. 16.5 перечислены прилагательные, употребляе-
мые при описании серверов имен. Определения, данные с отступом,
считаются относящимися к более крупной категории.
Серверы имен систематизируются на основании источника данных
(авторитетный, кэширующий, главный, подчиненный), типа хранимых дан-
ных (усеченный), пути распространения запроса (переадресуюший), типа
выдаваемого ответа (рекурсивный, нерекурсивный) и, наконец, доступности
сервера (невидимый). В следующих нескольких разделах конкретизируются
наиболее важные из этих различий; об остальных речь пойдет в других
разделах главы.
Глово 16 Системе доменных имен
427
Таблица 16.5. Таксономия серверов имен	
Тип се ера	Описание
Авторитетный главный подчиненный усеченный внутренний	Официальный представитель зоны Основное хранилище зонных данных; получает информацию из дискового файла Копирует свои данные с главного сервера Напоминает подчиненный сервер, ио копирует данные только о серверах имен (записи NS) Сервер, доступный только в пределах домена1 (также называ- ется невидимым сервером)
Неавторитетный2 кэшируюший персадресуюший	Отвечает на запросы, пользуясь данными из кэша; ие знает о том, являются ли эти данные корректными Кэширует данные, полученные от предыдущих запросов; обыч- но не имеет локальных зон Выполняет запросы от имени многих клиентов; формирует большой кэш
Рекурсивный	Осуществляет запросы от имени клиента до тех пор, пока не будет найден ответ или получена ошибка
Нерекурсивный	Отсылает клиента к другому серверу, если не может получить ответ на запрос
1	Внутренний сервер доступен любому, кто знает его 1Р-адрес.
2	Строго говоря, атрибут "неавторитетный" относится к ответу на DNS-залрос, а не
к серверу.
Авторитетные и кэширующие серверы
Главный, подчиненный и кэшируюший серверы различаются только
двумя характеристиками: откуда поступают данные и авторитетен ли сервер
для данного домена. В каждой зоне есть один основной сервер имен. На
нем хранится официальная копия зонных данных (в файле на диске).
Системный администратор модифицирует информацию, касающуюся зоны,
редактируя файлы главного сервера.
Подчиненный сервер копирует свои данные с главного сервера посред-
ством операции, называемой зонной пересылкой. В зоне может быть несколько
подчиненных серверов; обязательный минимум — один. Усеченный сервер —
это особая разновидность подчиненного сервера, загружающего с главного
сервера только записи NS (описания серверов имен). О том, зачем нужно
создавать такой сервер, речь пойдет в параграфе 16.11. Один и тот же
компьютер может быть главным сервером для одних зон и подчиненным —
для других.
О зонных пересылках рассказывается в параграфе 16.12.
Кэширующий сервер имен загружает адреса серверов корневого домена
из конфигурационного файла и получает все остальные данные, кэшируя
ответы на выдаваемые им запросы. Своих собственных данных у кэширую-
щего сервера нет, и ои не является авторитетным ни для одной зоны. Пример
создания такого сервера приведен в параграфе 16.10, в разделе “Кафедраль-
ный сервер".
Гарантируется, что авторитетный ответ сервера имен является точным;
неавторитетный ответ может быть устаревшим. Тем не менее большое число
неавторитетных ответов оказывается совершенно корректным Главные и
подчиненные серверы авторитетны для своих зон, но не для кэшированной
428
Чость II. Робото в гвтях
информации о других доменах. По правде говоря, даже авторитетные ответы
могут быть неточными, если системный администратор изменил данные
главного сервера и забыл обновить их порядковый номер либо запустить
команду ndc reload (или если изменения еше не успели дойти до подчиненных
серверов)
Главный сервер имен должен располагаться на машине, которая стабиль-
на, имеет небольшое количество пользователей, относительно безопасна и
подключена через источник бесперебойного питания. Необходимо, чтобы
подчиненных серверов имен было минимум два. причем один из них — вне
организации. Подчиненные серверы на местах должны быть включены в
разные сети и в разные цепи питания,
В зонных данных домена обычно присутствуют идентификаторы серверов
имен всех его поддоменов. Наличие подобной цепочки позволяет DNS-клиен-
там опускаться вниз по дереву доменов в поисках любого узла, подключенного
к internet. Если в родительском домене не упоминаются определенные
серверы имен поддомена, они становятся •‘внутренними" и недоступными
для внешнего мира.
Кэширующие серверы не авторитетны, но они, тем не менее, позволяют
сократить объем DNS-трафика во внутренней сети и уменьшить время
затрачиваемое на выполнение DNS-запросов. Желательно размещать один
такой сервер в каждой подсети. В большинстве организаций DNS-запросы
от настольных компьютеров обычно проходят через кэширующий сервер.
В BIND 4 и BIND 8 не рекомендовалось делать один и тот же сервер
имен авторитетным для одних зон и кэширующим — для других. Каждый
демон named эксплуатировал свою резидентную базу данных, и смешение
могло произойти лишь в том случае, когда из-за нехватки памяти данные
выгружались на диск. В BIND 9 эта проблема устранена.
Рекурсивные и нерекурсивные серверы
Серверы имен бывают либо рекурсивными, либо нерекурсивными. Если
у нерекурсивного сервера есть адрес, оставшийся в кэше от предыдущего
запроса, или если этот сервер авторитетен для домена, к которому относится
запрашиваемое имя, то он даст соответствующий ответ. В противном случае
он вернет отсылку на авторитетные серверы другого домена, которые должны
знать ответ. Клиент нерекурсивного сервера должен быть готов принимать
отсылки и обрабатывать их.
У нерекурсивных серверов обычно есть веские причины не выполнять
дополнительную работу. Например, все корневые серверы и серверы доменов
верхнего уровня являются нерекурсивными, поскольку им приходится вы-
полнять до 10000 запросов в секунду.
Рекурсивный сервер возвращает только реальные ответы или сообщения
об ошибках. Он сам отслеживает отсылки, освобождая от этой обязанности
клиента. Базовая процедура анализа запроса, по сути, остается той же;
единственное отличие заключается в том, что рекурсивный сервер заботится
об обработке отсылок, не возвращая их клиенту.
Библиотеки функций распознавания, имеющиеся в большинстве версий
UNIX, не понимают отсылок. Они ожидают, что локальный сервер имен
является рекурсивным.
Есть один побочный эффект при отслеживании отсылок: в кэше сервера
имен накапливается информация о промежуточных доменах. При работе в
локальной сети от этого обычно только польза, поскольку в последующих
Глово 16 Системе доменных имен
429
операциях поиска, инициируемых любым компьютером этой сети, можно
будет пользоваться результатами предыдущих запросов. С другой стороны,
сервер домена верхнего уровня (такого как “сот” или "edy") не должен
хранить информашпо, запрашиваемую компьютером, который находится на
несколько уровней ниже.
В ранних версиях BIND требовалось модифицировать исходный код и
перекомпилировать пакет, чтобы изменить рекурсивность сервера. Затем
появилась опция командной строки -г, которая теперь является параметром
конфигурационного файла. Можно даже сконфигурировать сервер таким
образом, что он будет рекурсивным для внутренних клиентов и нерекурсив-
ным — для внешних.
Отсылки генерируются иа иерархической основе. Если сервер, к примеру,
не сможет узнать адрес узла lair.cs.colorado.edu. он выдаст отсылки к серверам
доменов cs.colorado.edu. colorado.edu, “ediT или корневого домена. Отсылка
должна содержать адреса серверов того домена, на который она указывает,
поэтому выбор домена ие случаен: сервер должен ссылаться на тот домен,
серверы которого ему уже известны.
Как правило, возвращается наиболее полный из известных доменов.
В нашем примере в первую очередь были бы выданы адреса серверов домена
cs.colorado.edu. при условии, что они известны. Если этот домен не известен,
но известен домен colorado.edu, были бы выданы адреса его серверов имен
и т.д.
Сервер имен предварительно наполняет свой кэш содержимым файла
“подсказок’*, в котором указаны серверы корневого домена. Благодаря этому
всегда можно сделать какую-нибудь отсылку, даже если она гласит: “спроси
у корневого сервера”.
Модуль распознавания
Клиенты ищут соответствия между именами компьютеров и их IP-адре-
сами, вызывая библиотечную функцию gethostbynamcO, В исходной версии
этой функции имена искались в файле /etc/hosts. Для того чтобы такую
информацию выдавала система DNS, функция должна делать запросы к
модулю распознавания, который знает, как находить серверы имен и
взаимодействовать с ними.
В большинстве операционных систем функция gethostbyname() может
черпать информацию из нескольких источников: обычных файлов (например,
/etc/hosts), DNS и даже локальных административных СУБД, таких как NIS
и NIS+. Иногда возможен четкий административный контроль над тем, какие
источники опрашиваются и в каком порядке Подробнее об этом рассказы-
вается в параграфе 18.3, а также в параграфе 16.16 применительно к нашим
тестовым системам.
Выполнение запросов из командной строки
В пакет BIND входят программы dig и nslookup. позволяющие выполнять
DNS-запросы в режиме командной строки. Они полезны при отладке и как
инструменты извлечения информации из базы данных DNS Обе программы
имеют сходные функциональные возможности, но реализованы немного
по-разному. Подробнее о них рассказывается в параграфе 16.14.
43U
Чость II Роботе в сетях
16-7. Как работает DNS
Каждый компьютер, пользующийся услугами DNIS. является либо кли-
ентом данной системы, либо одновременно м клиентом, и сервером. Те
читатели, которые не планируют запускать серверы DNS, могут, пропустив
следующие несколько разделов, сразу переходить к параграфу 16.8, Отметим,
однако, что эти разделы полезны для более глубокого понимания архитектуры
DNS.
Делегирование
Все серверы имен знают о существовании корневых серверов. Последние,
в свою очередь, знают о доменах "com”, "org”, "edu”, “fi”. "de" и других
доменах верхнего уровня. Сервер домена “edu” знает о домене colorado.edu.
сервер домена “сот" знает о домене admin.com и т.д. Каждая зона может
делегировать полномочия по управлению своими поддоменами другим
серверам.
Рассмотрим реальный пример. Предположим, требуется узнать адрес узла
vangogh.cs.berkeley.edu с машины lair.cs.colorado.edu. Компьютер lair просит
свой локальный сервер имен, ns.cs.colorado.edu, найти ответ на этот вопрос.
Последующие события изображены на рис. А. Мы использовали относитель-
ные имена, чтобы уменьшить неразбериху и улучшить читабельность надпи-
сей. Цифры возле стрелок определяют порядок событий, а буквы — тип
транзакции (запрос, ответ или отсылка). Мы предполагаем, что перед
запросом никакие из требуемых данных не кэшировались, за исключением
имен и IP-адресов серверов корневого домена.
Рекурсивные	Нерекурсивные
Рис. А. Процесс оброботки зопросо в DNI5
Локальный сервер имен не знает нужный адрес. Более того, ему ничего
не известно ни о домене cs.berkeley.edu. ни о домене berkeley.edu. Он знает
лишь некоторые серверы корневого домена и. будучи рекурсивным, спраши-
вает корневой домен об узле vangogh.cs.berkeley.edu.
Раньше корневые серверы хранили данные как о корневых зонах, так и
об общих доменах, но сегодня у последних есть свои собственные серверы
имен. В ответ на запрос к корневому серверу об узле vangogh.cs.berkeley.edu
мы получим ссылку на сервер домена “edu”.
Локалъный сервер имен посылает свой запрос к серверу домена “edu” и
получает обратно ссылку на серверы домена berkeley.edu. Тогда он повторяет
запрос, направляя его в домен berkeley.edu. Если сервер университета Беркли
Глово 16. Системе доменных имен
431
ие рекурсивен и не содержит ответ в кэше, он вернет ссылку на домен
cs.berkeley.edu. Сервер этого домена авторитетен в отношении запрашиваемой
информации и возвращает адрес компьютера vangogh.
Когда все закончится, в кэше сервера ns.cs.colorado.edu окажется адрес
компьютера vangogh, В кэше также будут списки серверов доменов “edu".
berkeley.edu и cs.berkeley.edu.
Демон named посылает запросы по протоколу UDP через порт 53.
Ответные пакеты также имеют формат UDP, если только их объем не
превышает 512 байтов: в этом случае используется протокол TCP. В зонных
пересылках всегда применяется протокол TCP.
Кэширование и эффективность
Благодаря кэшированию повышается эффективность поиска: кэширован-
ный ответ почти бесплатен и, как правило, точен, так как адресно-именные
соответствия меняются редко. Большинство запросов касается локальных
машин и разрешается быстро. Пользователи невольно содействуют повыше-
нию эффективности работы серверов имен, так как многие запросы
повторяются,
В течение долгого времени кэширование применялось только к положи-
тельным ответам. Если имя или адрес компьютера было невозможно найти,
этот факт не фиксировался. Схема кэширования отрицательных DNS-ответов
была описана в документе RFC 1034, но она оказалась неполной и осталась
нереализованной в большинстве версий BIND. В 1998 г. был опубликован
документ RFC2308, в котором описывалась обновленная схема отрицательного
кэширования. Она была реализована в BIND 8.2 в виде опционального
компонента, но в BIND 9 это уже обязательный компонент.
Измерения, проведенные на сервере RIPE в Европе, показали, что 60%
DNS-запросов относилось к несуществующим данным (многие запросы были
адресованы домену 127.in-addr.arpa или содержали в качестве сетевых имен
названия сервисов Microsoft). Кэшируя эту информацию как можно глубже
в DNS-дереве, можно добиться резкого снижения нагрузки на корневые
серверы.
При отрицательном кэшировании сохраняются ответы следующих типов:
•	отсутствие узла или домена, соответствующих запрашиваемому имени;
•	данные запрашиваемого типа не существуют для указанного узла;
•	запрашиваемый сервер не отвечает;
•	сервер недоступен из-за проблем в сети
Ответы первых двух типов сохраняются в кэше в течение 1—3 часов,
остальные — 5 минут. Неавторитетные ответы могут кэшироваться, а авто-
ритетные негативные ответы — обязаны.
Демон named часто получает несколько DNS-записей в ответ на запрос.
Например, при попытке узнать адрес сервера имен корневого домена будет
получен список из всех 13-ти корневых серверов, К какому из них следует
обращаться?
Когда демону named приходится выбирать среди удаленных серверов, все
из которых авторитетны для данного домена, он в первую очередь определяет
период кругового обращения (round-trip time, RTT) каждого сервера. Затем
серверы сортируются по '‘корзинам” в соответствии со значением RTT. после
чего выбирается сервер из самой быстрой корзины. Серверы в пределах одной
корзины считаются равнозначными и выбираются по циклической схеме.
432
Часть II. Робота в сетях
Простейший, ио весьма эффективный способ распределения нагрузки —
закреплять одно имя за несколькими IP-адресами (соответствующими разным
компьютерам):
www	IN A 192.168.0.1
IN	А	192-168-0.2
IN	А	192.168.0.3
Загруженные Web-серверы, такие как Yahoo и AltaVista, в действитель-
ности не являются одной машиной. Они просто известны под одним
доменным именем в DNS. Сервер имен, обнаруживший несколько эаписей
с одинаковым именем и типом, возвращает все их клиенту, но в циклическом
порядке. Например, порядок записей А в показанном выше примере будет
1, 2, 3 для первого запроса, 2, 3, 1 — для второго и 3, 1,2 — для третьего.
Расширенный протокол DNS
Исходное определение протокола DNS датируется конном 80-х гг. и
предполагает использование протоколов СЮР и TCP. Первый нужен для
запросов и ответов, а второй — для зонных пересылок между главными и
подчиненными серверами. К сожалению, максимальный размер пакета,
который гарантированно принимается всеми реализациями UDP, составляет
512 байтов. Это слишком мало для новых схем обеспечения безопасности
DNS, подразумевающих включение в каждый пакет цифровой подписи.
Данное ограничение влияет на число и названия корневых серверов.
Чтобы все данные этих серверов умещались в 512-байтовом UDP-пакете,
количество серверов ограничено числом 13, а имя каждого сервера состоит
из одной буквы.
Многие распознаватели выдают сначала UDP-запрос, и если приходит
усеченный ответ, то запрос повторяется в формате TCP. Эта процедура
позволяет выйти за рамки 512-байтового лимита, но она неэффективна.
Кое-кто может посчитать, что следует вообще отказаться от UDP и перейти
исключительно на TCP, но TCP-соединения являются гораздо более дорого-
стоящими. Обмен данными между серверами имен в рамках протокола UDP
может свестись всего к двум пакетам: один запрос и один ответ. В случае
протокола TCP требуется минимум семь пакетов: трехфазовос квитирование
для инициализации диалога, запрос, ответ и завершающее квитирование для
разрыва соединения.
В середине 90-х гг. протокол DNS был усовершенствован механизмами
инкрементных зонных пересылок (напоминает применение команды difT для
сравнения старого и нового зонных файлов; прототипом послужила програм-
ма patch, написанная Ларри Уоллом), асинхронных уведомлений (для
информирования подчиненных серверов об изменениях файлов главного
сервера) и динамических обновлений (для DHCP-узлов). Все эти нововведе-
ния привели к расширению функциональных возможностей DNS, но они не
решили фундаментальную транспортную проблему.
В конце 90-х гт. появилась спецификация EDNS0 (расширенный
протокол DNS, версия 0), которая устраняла некоторые недостатки DNS.
В этой спецификации запрашивающая сторона сообщает размер буфера
сборки пакетов, поддерживаемые опции и версию протокола. Если сервер
имен отвечает сообщением об ошибке, запрашивающая сторона возвращается
к исходному протоколу DNS. Пакет BIND 9 реализует спецификацию EDNS0
как на стороне сервера, так и на стороне распознавателя.
Глово 16. Системе доменных имен
'33
16 8. Работа с клиентом BIND
Перед тем как вплотную заняться проблемами конфигурирования пакета
BIND, давайте определим крут основных задач, которые сопряжены с
использованием BIND в Internet. В табл. 16.6 показано, что нужно делать,
кому и как часто. Если элемент в столбпе “Как часто” содержит слово
“распространить”, то это означает, что указанное действие необходимо
выполнить один раз в каждой подсети или архитектуре, а затем скопировать
результат на другие компьютеры с помощью такой программы, как rdist или
rsync.
Jvf Подробнее о распространении файлов по сети можно узнать в главе 18.
Поскольку каждый компьютер в сети должен быть клиентом BIND,
начнем с рассмотрения задач, стоящих перед клиентами
Таблице 16.6. Задачи, связочные с инсталляцией и сопровождением покето BIND		
Задача	д™	Как моего
Получить доменное имя	Организации	Один раз
Выбрать серверы имен	Организации	Один раз или больше
Получить дистрибутив BIND	Организация	Один раз, но следить за обнов- лениями
Сконфигурировать распознаватель	Клиента	Один раз и распространить
Сконфигурировать эффективный распознаватель	Клиента	Для каждой подсети и распро- странить
Сконфигурировать файл "пере- ключения сервисов”	Клиента	Для каждой архитектуры и рас- пространить
Запустить демон named во время начальной загрузки	Сервера	Для каждого сервера имен
Отредактировать конфигурацион- ный файл демона named	Сервера	Для каждого типа сервера
Сконфигурировать файл "подска- зок”	Сервера	Один раз1 и распространить на серверы имен
Сконфигурировать файлы зон	Главных серве- ров	Один раз
Обновлять файлы зон	Главных серве- ров	По мере необходимости
Просматривать журнальные фай- лы	Узла-регистра- тора	Хотя бы раз в неделю
Обучать пользователей	Всех узлов	Постоянно
1 Нужно выполнять повторно, если меняются корневые серверы.		
Конфигурирование распознавателя*
На каждом компьютере, подключенном к сети, должен быть файл
/etc/resolv.conf, содержащий список серверов имен, которым можно посылать
На многих компьютерах содержится файл “переключения сервисов”, который задает, к
каким источникам данных следует обращаться в процессе поиска имен. Если в этот файл
не добавить запись dns, то в ряде операционных систем (например, в Solaris 7 и более ранних
версиях) протокол DNS не будет использоваться. Подробнее об этом рассказывается в
параграфе 16.16.
434
Чость II. Роботе в сетях
запросы. Если узел получает свой IP-адрес и сетевые параметры от
DHCP-сервера, этот файл заполняется автоматически. В противном случае
его нужно редактировать вручную. Файл имеет следующий формат:
search имя_домен<з .. .
nameserver ip-адрес
Может быть указано от одного до трех серверов имен. Вот полный
пример;
search cs. cole ratio, edu colorado.edu ее. Colorado, ecu
nameserver 128.138.243.151	;	ns
nameserver 128.138.204.4	;	piper
nameserver 128.138.240.1	;	anchor
Для файла resolv.conf никогда не вводилось понятие комментариев. Они
поддерживаются лишь в том смысле, что любой нераспознанный элемент
файла игнорируется. Комментарии разрешается размещать в конце директивы
nameserver, поскольку анализатор файла ищет лишь IP-адрес, игнорируя
остальную часть строки. Директива search может содержать несколько
аргументов, поэтому комментарии в ней лучше не ставить.
В директиве search указан список доменов, которые следует опраши-
вать, если имя компьютера оказывается не полностью определенным
Например, когда пользователь вводит команду ssh foo. распознавател.
дополняет имя первым доменом в списке (в данном случае — cs.colorado.edu)
и в результате ишет узел foo.cs.colorado.edu. Если зто имя не найдено, делается
попытка найти узел foo.colorado.edu, затем foo.ee.coloradc.edu.
Пользователи нашего поддомена "cs” могут обращаться к любому
локальному узлу по сетевому имени, а вот пользователи родительского домена
должны указывать имя_узла.си, чтобы получить доступ к нужному компьютеру
в этом поддомене. При создании новых поддоменов приходится дополни-
тельно обучать пользователей.
Директива search в файлах resolv.conf компьютеров родительского
домена может допускать использование простых имен в обоих направлениях:
search colorado.edu. cs.colorado.edu. ee-colorado.edu.
Естественно, в такой конфигурации предполагается, что имена компью-
теров уникальны в пределах всех трех доменов В директиве search можно
задавать до восьми доменов.
Серверы имен, указанные в файле resolv.conf. должны быть рекурсивными
(распознаватель не понимает отсылок) и иметь свой кэш. Если используется
пакет BIND 4 или BIND 8, то серверы не должны быть авторитетными ни
для одной зоны. И.х кэши могут стать очень большими, а поскольку в
версиях 4 и 8 работа с кэшем ведется некорректно, вся память компьютера
может оказаться занятой. При смешении кэшированных и авторитетных
данных нужно воспользоваться конфигурационным параметром Listen-on,
позволяющим запустить на одном компьютере два отдельных сервера,
прослушивающих разные порты.
Серверы имен опрашиваются в том порядке, в котором заданы директивы
nameserver. Если первый сервер отвечает на запрос, друтие серверы
игнорируются. В случае превышения периода тайм-аута запрос переадресуете я
следующему серверу Все серверы опрашиваются по очереди, до четырех раз
каждый. С каждой неудачей период тайм-аута увеличивается.
Большинство распознавателей допускает наличие максимум трех серверов
имен. Все остальные просто игнорируются. Если узел сам является сервером
имен, он должен быть указан первым в собственном файле resolv.conf
В ранних версиях BIND вместо директивы search в файле resolv.conf
использовалась директива domain. Она задавала единый домен, который
Глово 16. Системе доменных имен
435
следовало добавлять к неполным именам. Мы рекомендуем заменить
директивы domain директивами search. Они являются взаимоисключающими,
так что только одна из них должна присутствовать. Если имеется старый
распознаватель, а а файле resolv.conf присутствуют обе директивы, действительной
будет та, что указана последней.
По умолчанию современные распознаватели ведут себя каждый по-сво-
ему. Одни предполагают, что локальный компьютер является DNS-сервером,
если в конфигурационном файле не указаны серверы имен. Другие раскла-
дывают полное имя локального компьютера на компоненты, формируя список
поиска. Третьи могут работать вообще без файла /etc/resolv.conf. Не обращайте
на все это внимание. Просто сконфигурируйте должным образом файч
resolv.conf на каждом компьютере.
DNS-запросы, поступающие из внешнего мира, попадут на авторитетный
сервер имен. Хорошим решением будет выделить отдельные серверы для
ответа на запросы внутри домена. Необходимо, чтобы внутренние серверы
были кэширующими и рекурсивными. В крупной организации должны
функционировать несколько серверов имен, а файл resolv.conf нужно скон-
фигурировать так. чтобы распределить нагрузку между серверами, миними-
зировать сетевой трафик и уменьшить последствия выхода из строя серверов.
Когда сервис DNS перестает работать, вся сеть “зависает”.
Оптимизировать работу организации можно также посредством переад-
ресуюших серверов. Локальные серверы имен обращаются к переадресуюшему
серверу, который делает все внешние запросы и создает очень большой кэш.
В подобной схеме внешний трафик, вызываемый серверами имен, сводится
к минимуму, а все локальные компьютеры совместно пользуются одним
большим кэшем. Подробнее о переалресуюших серверах будет рассказано в
параграфе 16.9.
На рис. Б изображена примерная схема функционирования DNS. Здесь
представлена двухуровневая иерархия переадресации, что, конечно же.
является избыточным для маленьких организаций. Отрегулируйте загрузк}
серверов, обрабатывающих исходящие запросы, и серверов, принимающих
входящие запросы, чтобы ни одна из групп не оказалась перегруженной
Обратите внимание иа наличие внешнего подчиненного сервера. Настоятель-
но рекомендуется следовать данной структуре, если есть возможность
использовать сервер провайдера в этой роли.
Рис. Б. Архитектуре сервере DNS
436
Чость II Роботе в сетях
Тестирование распознавателя
В некоторых системах для начала работы с DNS нужно лишь добавить
в файл /etc/resolv.conf директиву nameserver. В других системах следует
дать явное указание на использование DNS вместо файла /etc/hosts или
службы NIS (это делается в файле “переключения сервисов”, который чаше
всего называется /etc/nsswitch.conf) Комментарии по использованию пакета
BIND в наших тестовых системах приведены в параграфе 16.16. Описание
того, как назначать приоритеты источникам административных данных, дано
в параграфе 18.3.
После конфигурирования файла /etc/resolv.conf (предполагаем, что соеди-
нение с локальной сетью установлено и функционирует правильно) пользо-
ватель сможет ссылаться на другие компьютеры по именам, а не IP-адресам.
Если при обращении к локальному компьютеру команда “зависнет", попро-
буйте найти машину по IP-адресу. Успешное завершение такого поиска
означает, что в конфигурации DNS есть ошибка. Убедитесь, что IP-адреса
серверов имен в файле /etc/resoh'.conf правильны, а самим серверам
разрешено обрабатывать запросы из вашей сети (см. описание параметра
al low-query в следующем параграфе).
Влияние на остальную часть системы
Переход от статических таблиц имен к DNS создает некоторые зависи-
мости между процедурой начальной загрузки и конфигурацией системы, от
которых нужно избавиться.
Ссылки на имена компьютеров в сценариях /etc/гс* или init.d могут
оказаться неразрешимыми, если они встречаются раньше, чем загружается
сетевая подсистема. Команды сценариев будут безуспешно пытаться связаться
с DNS. Благодаря устойчивости распознавателя они станут повторять попытки
много раз на многих серверах, при каждой из попыток увеличивая интервал
тайм-аута. Пару минут спустя команда, которой нужно имя компьютера,
наконец выдаст ошибку.
Проблему можно решить, используя на ранних стадиях процесса началь-
ной загрузки только явные IP-адреса. Или же, если система поддерживает
одновременное использование DNS и файла /etc/hosts. можно инсталлировать
файл hosts, содержащий адреса серверов, которые необходимы во время
начальной загрузки. При этом данный файл должен проверяться в первую
очередь, чтобы не пришлось ждать истечения срока тайм-аута.
Полностью определенные имена доменов требуются в нескольких местах.
Одно из них — файл /etc/exports, который управляет совместным использо-
ванием файлов NFS в некоторых системах. В списках компьютеров, имеющих
право монтировать файловые системы, должны содержаться полностью
определенные имена этих машин. В некоторых системах каждая строка в
файле exports ограничена 1024 знаками; когда имена компьютеров меняются
с anchor на anchor.cs.colorado.edu. этот предел достигается пугаюше быстро.
|71 Подробно об NFS рассказывается в главе 17.
16.9.	Конфигурирование сервера BIND
В следующих разделах мы предполагаем, что все “политические” задачи
вами решены, т.е. вы получили имя домена (возможно, поддомена), связались
с администратором DNS-сервера родительского домена и передали полномочия
Глава 16. Системе доменных имен
437
по обратному преобразованию адресов домену in-addr.arpa. Был выбран
главный сервер имен и несколько подчиненных, а также инсталлирован пакет
BIND.
Аппаратные требования
Пакет BIND — настоящий пожиратель ресурсов. Его база данных
хранится в памяти, поэтому одновременно с увеличением кэша растет число
страниц памяти, занимаемых демоном named. Некоторые новые компоненты
BIND 9, особенно DNSSEC и подсистема IPv6, столь же интенсивно
используют центральный процессор. Для снижения нагрузки пакет BIND 9
был сделан многопотоковым, и теперь он способен эффективно работать в
многопроцессорных системах. Имеются также конфигурационные параметры,
посредством которых можно контролировать, как демон named использует
системные ресурсы.
Лучший способ определить, достаточно ли памяти на компьютере, где
установлен сервер имен, — дать серверу поработать некоторое время, а затем
проверить размер процесса named. Требуется одна-две недели, чтобы этот
размер стабилизировался и старые записи в кэше устаревали с той же
скоростью, с какой появляются новые записи.
Запуск демона named
Демон named запускается во время начальной загрузки и работает
непрерывно. Например, для запуска этого демона в Solaris необходимо
добавить в один из стартовых сценариев следующие строки:
if 1 -f /usr/sbin/in.named -a -r /etc/named.conf ]; then
/usr/sbin/жп-named; echo -n * named' > /dev/console
В последних версиях BIND имеется программа ndc (или mdc. в
зависимости от версии), позволяющая посылать команды демону named. Ее
формат прост:
#	ndc команда
Среди полезных команд назовем start, stop, restart и status, назначение
которых очевидно. Программа ndc будет подробно описана в параграфе 16.14.
Демон named использует систему Syslog, поэтому сначала нужно запустить
демон syslogd. Не применяйте для управления сервером имен демон inetd: он
будет при малейшей необходимости перезапускать демон named, замедляя
время его реакции и препятствуя накоплению полезной информации в кэше.
Подробнее о демоне inetd рассказывается в параграфе 28.3.
Конфигурационные файлы
Под конфигурацией демона named понимается конфигурационный файл,
файл “подсказок” и. в случае главного сервера,, файлы зонных данных,
содержащие адресные привязки для каждого узла. Конфигурационный файл
имеет свой собственный формат; остальные файлы представляют собой
коллекции отдельных DNS-записей, отформатированных в соответствии со
спецификацией DNS. Ниже речь пойдет о содержимом конфигурационного
файла, тогда как о формате DNS-записей будет рассказываться в парагра-
фе 16.11.
43В
Чость II. Роботе в сетях
В конфитурационном файле демона named задается роль (главный,
подчиненный или усеченный) данного сервера в каждой зоне и определяется
способ, которым сервер получает свою копию записей о ресурсах, состав-
ляющих локальную часть базы данных. Здесь же приводятся всевозможные
параметры — как глобальные, связанные с работой самого демона и сервера,
так и зонные, влияющие на функционирование отдельных областей DNS.
При переходе от BIND 4 к BIND 8 формат конфигурационного файла
полностью поменялся и стал напоминать формат файла gated, con Г Имя файла
также изменилось: в BIND 4 он назывался /ctc/named.boot, aeBIND8»i9 —
/etc/named.conf. Формат файлов кэша и файлов данных остался прежним.
Мы опишем конфигурационный файл пакетов BIND 8/9. проигнорировав
BIND 4. Надеемся тем самым подстегнуть самых консервативных из наших
читателей к переходу на новые версии пакета. Как и в случае со многими
другими программами, старые версии BIND могут содержать “дыры" в
системе защиты, которые давно устранены в современных версиях.
Файл named.conr состоит из набора инструкций, каждая нз которых
оканчивается точкой с запятой. Лексемы разделяются пробельными симво-
лами, к. которым относится и символ новой строки. Иногда для группировки
лексем применяются фигурные скобки. Формат файла очень “хрупкий” —
достаточно одной пропущенной точки с запятой, чтобы нее перестало
работать.
Комментарии допускаются везде, где могут стоять пробелы. Распознаются
комментарии в стиле языков С, C++ и командного интерпретатора
/* Это комментарий, который может занимать несколько строк. ’/
// Все, что идет до конца строки, является комментарием.
#	Все, что идет до конца строки, является комментарием.
Каждая инструкция начинается с ключевого слова, определяющего ее
тип. Может присутствовать несколько инструкций одного типа, за исключе-
нием инструкций options и logging. Отдельные инструкции, а также их
части могут отсутствовать; в этом случае будут приняты установки по
умолчанию. В табл. 16.7 перечислены инструкции, включенные в BIND 9.
Тоблицо 16.7. Инструкции, используемые в фойпе nomed.conf
Инструкция	Функция
include	Вставляет дополнительный файл (чаще всего подключаются файлы с ключами шифрования, доступные только демону named)
options	Задаст глобальные параметры конфигурации сервера имен, а также установки по умолчанию
server	Задает параметры конкретного сервера
key acl	Определяет аутентификационную информацию Формирует список управления доступом
zone	Определяет зону, для которой демон является авторитетным
trusted-keys controls	Задает заранее установленные ключи шифрования Определяет, как программа ndc будет управлять сервером имен
logging	Устанавливает категории регистрационных сообщений и каналы их распространения
view	Определяет представление пространства имен (только в BIND 9)
Глово 16. Системе доменных имен
439
Прежде чем приступить к описанию этих инструкций, необходимо
рассказать о структуре данных, используемой во многих инструкциях: список
соответствия адресов. Этот список является обобщением понятия IP-адреса
и может содержать:
•	IP-адрес (например, 199.165.145.4.);
•	адрес сети, включающий маску CIDR (например, 199 165/16);
•	имя ранее определенного списка управления доступом (см. описание
инструкции acl);
•	ключ аутентификации;
•	оператор отрицания !.
Списки соответствия адресов используются в качестве аргументов многих
инструкций и опций Приведем ряд примеров:
{ • 1.2.3.13; 1.2.3/24; J;
{ 128.138/16; 198.11.16/24; 204.228.69/24; 127.0.0.1; 1;
В первом из этих списков из числа адресов исключается узел 1.2.3.13.
но разрешаются другие адреса в сети 1.2.3/24. Во втором списке указаны
сети, закрепленные за университетом штата Колорадо. Фигурные скобки и
завершающая точка с запятой не являются частью списка: они относятся к
инструкции, в которой содержится список.
Когда IP-адрес или адрес сети проверяется на соответствие списку,
содержимое списка просматривается по очереди до тех пор, пока не будет
найдено совпадение. Порядок элементов списка важен, так как ищется первое
совпадение- Например, если в первом из показанных выше списков поменять
элементы местами, результат не будет достигнут, поскольку адрес 1.2.3.13
удовлетворит первому условию (сетевому адресу 1.2.3/14) и второе условие
никогда не будет проверяться.
Далее перейдем непосредственно к инструкциям. Некоторые из них
короткие и понятные, для описания других может потребоваться целая глава.
Инструкция include
Когда конфигурационный файл становится слишком большим, можно
разбить его на части, поместив их в отдельные файлы. Дополнительные
компоненты подключаются к файлу па med.conf посредством инструкции
include:
include “путь";
Если указан относительный путь, то он добавляется к путевому имени,
заданному в параметре directory (описан в следующем разделе). Очень
часто инструкцию include применяют для подключения файлов. содержа-
щих ключи шифрования. Эти данные должны быть доступны только демону
named. Чтобы не запрещать доступ ко всему файлу named.conf, ключи хранят
в отдельных файлах, которые может читать лишь демон named.
Инструкция options
Инструкция options задает глобальные параметры конфигурации,
которые впоследствии могут быть переопределены для конкретных зон или
серверов. Общий ее формат таков:
options {
параметр;
440
Чость II Работе в сетях
параметр;
};
Если в файле named.conf нет инструкции options, принимаются
установки по умолчанию.
В BIND 8 имеется около 30-ти параметров, а в BIND 9 — более 50-ти.
Полный их список можно узнать в документации. Ниже мы опишем лишь
те параметры, которые рекомендуется задавать. Значения по умолчанию
указаны в квадратных скобках рядом с каждым параметром.
version "строка";	[реальный номер версии сервера!
Имеются два принципиальных подхода к вопросу о том. нужно ли
скрывать номер версии. Некоторые администраторы полагают, что их серверы
будут больше подвержены атакам, если хакеры смогут узнать, какая версия
пакета BIND выполняется. Другие считают это избыточной процедурой,
аргументируя свою позицию тем, что хакеры в любом случае будут пытаться
"взломать” систему, а большинство недавно обнаруженных ошибок присут-
ствует во всех версиях пакета
Мы рекомендуем не сбрасывать строку версии. Для администратора будет
очень полезной возможность запрашивать сервер имен, чтобы выяснить
текущую версию пакета.
directory "путь";	[каталог, откуда был запушен сервер
Этот параметр залает каталог, из которого должен стартовать демон named
Когда в конфигурационном файле встречаются относительные путевые имена,
к ним добавляется указанный путь (сам он должен быть абсолютным). В этот
каталог также помещаются все выходные файлы (отладка, вывод статистиче-
ских данных и т.д.).
Лучше хранить все конфигурационные файлы пакета BIND (кроме
named.conf и resolv.conf) в подкаталоге каталога /var (или любого другого
каталога, где содержатся конфигурационные файлы других программ)
В нашей системе это каталог /var/named
notify yes I no;	[yesj
aiso-notify адреса серверов; [пусто]
Если параметр notify равен yes, а демон named является главным
сервером одной или нескольких зон, то демон будет автоматически уведомлять
подчиненные серверы этих зон при изменении соответствующих баз данных.
В ответ на полученное уведомление подчиненные серверы связываются с
главным и обновляют свои копии зонных данных Параметр notify может
устанавливаться как на глобальном уровне, гак и на уровне отдельных зон. Это
позволяет быстрее обновлять зонные файлы при внесении изменений в DNS
Демон named выясняет, какие компьютеры являются подчиненными
< ; играми ыпы. просмаливая записи NS зтой юны. При наличии параметра
с- ю1 I будут также уведомляться дополнительные серверы, которые
не itipeniciрнрованы посредством записей NS. Подобный прием иногда
необходим, если в организации имеются внутренние серверы. В списке
a_so-nac.Lv не нужно указывать усеченные серверы. Поскольку их
интересуют только записи NS. они могут участвовать в обычном цикле
обновления.
Об усеченных зонах рассказывается в конце параграфа 16./1.
Глава 16. Системе доменных имен
441
Серверы BIND 4 не понимают уведомляющих сообщений. Они регист-
рируют ошибку и обновляют свою информацию только по истечении периода
обновления, указанного в зонных данных (см. описание записи SOA в
параграфе 16.11). Уведомления желательно также отключать для зоны обрат-
ного преобразования узла localhost.
recursion yes I no; t-tf и	lyes]
allow-recursion { агпсок_cootsетствия_адресоЕ }; [все узлы]
Параметр recursion указывает на то, является ли демон named
рекурсивным сервером (см. параграф 16.6). Можно разрешить рекурсию для
внутренних клиентов демона и отключить для внешних запросов.
Параметр allow-recursion позволяет точнее управлять рекурсией.
В нем задается список узлов и сетей, от имени которых разрешается
выполнять рекурсивные запросы.
use-id-pool yes | no;	[no (только в V8)]
В BIND 8 этот параметр заставляет демои named хранить идентификаторы
исходящих запросов, что позволяет избегать их дублирования и незаконного
использования. Когда параметр включен, демон использует больше памяти,
но результат того стоит, поэтому мы рекомендуем всегда устанавливать
значение yes. В BIND 9 параметр use-id-pool исчез, поскольку демои
всегда сохраняет идентификаторы запросов.
maintain-ixfr-base yes I no; [no (только в V8J]
При помощи механизма инкрементных зонных пересылок (см. RFC 1995)
серверы рассылают '‘заплаты" к зонным базам данных при наступлении
изменений, благодаря чему устраняется необходимость в повторной отправке
всей базы данных. Для такой зоны, как, например, “сот”, это очень важно.
В текущей реализации BIND 8 разрешаются инкрементные пересылки для
любой юны, поддерживающей динамические обновления; когда параметр
maintain - ix f г -base равен yes, ведется журнал транзакций. В BIND 9
журнальный файл присутствует постоянно. Подробнее о зонных пересылках
рассказывается в параграфе 16.12.
check-names { master I slave I response действие J; [см. текст]
В BIND 8 появился модуль проверки правильности доменных имен. Под
правильностью подразумевается не то, существует узел или нет, а то, следует
ли данное имя правилам, определенным в RFC-спецификациях для доменных
имен. Как ни странно, многие имена оказываются неправильными. Имя
считается правильным, если оно содержит только буквы, цифры и дефисы,
длина каждого компонента (включая точку) ограничена 64-мя символами, а
общая длина имени не превышает 256 символов. Правила именования и
вопросы разграничения узловой и доменной частей имени обсуждаются до
сих пор. Локализация системы DNS и поддержка специализированных
кодировок символов могут привести к тому, что все правила придется менять.
Параметр check-names можно задавать глобально и отдельно для каждой
зоны. Зонные спецификации перекрывают глобальную. Этот параметр может
применяться к главным и подчиненным серверам, а также к ответам,
возвращаемым в результате запроса. Существует три возможных действия:
• ignore — не выполнять проверку;
• warn — регистрировать неправильные имена, но продолжать обработку;
• fail — зарегистрировать неправильное имя и отказаться его принять.
442
Чость 11. Робото в сетях
Для главного сервера действием по умолчанию является fail, поскольку
ошибки на главном сервере, скорее всего, возникают вследствие опечаток
или ввода неприемлемых имен. Все это системный администратор должен
устранить: организации не следует заниматься распространением неправиль-
ных имен. Для подчиненного сервера установка по умолчанию — warn, а
для ответов на запросы — ignore. Стандартные установки вполне прием-
лемы, и менять их ие нужно.
transfer-format one-answer I many-answers; [см. текст]
Этот параметр влияет на то, каким образом записи базы данных DNS
(описываются в параграфе 16.11) передаются от главного к подчиненным
серверам. Раньше пересылка осуществлялась по одной записи за раз, что
было очень медленно и неэффективно. Атрибут many-answers, позволяю-
щий объединять несколько записей в один пакет, появился в BIND 8 I; он
установлен по умолчанию в BIND 9. Задавать атрибут many-answers можно
только в том случае, если на всех серверах, между которыми происходит
обмен зонными данными, выполняется пакет BIND версии как минимум 8.1,
поскольку серверы BIND 4 не понимают этот атрибут. При работе в
смешанной среде глобальные установки можно переопределить для отдельных
серверов.
transfers-in число;
transfers-out число;
transfers-per-ns число;
transfer-source IP-адрес;
serial-queries число;
(10J
[10 (только в V9) 1
[2]
[зависит от системы]
[4 (только в V8) ]
Эти параметры отвечают за работу механизма зонных пересылок Их
требуется настраивать в крупных серверах, управляющих очень большими
зонами (в частности, зоной "сот”, база данных которой в настоящее время
превышает 2 Гбайт) или обслуживающих тысячи зон. Параметры trans-
fers-in и transfers-out ограничивают число входящих и исходящих
зонных пересылок, которые могут происходить одновременно. Параметр
transfers-per-ns задает предельное число входящих зонных пересылок,
одновременно поступающих от одного удаленного сервера. В крупных
серверах может потребоваться увеличить значения transfers-in и trans-
fers-out, но будьте осторожны, иначе можно превысить допустимое число
файловых дескрипторов для процесса named. Параметр transfers-per-ns
обычно не требуется менять; его можно увеличить только в том случае, если
все удаленные главные серверы готовы обрабатывать более двух одновремен-
ных зонных пересылок Если уж что-то менять, то лучше делать это
посредством предложения transfers инструкции server.
Параметр transfer-source позволяет указать IP-адрес сетевого интер-
фейса, используемого для приема входящих пересылок. Этот адрес должен
совпадать с адресом, указанным в параметре allow-transfer главного сервера.
В BIND 8 можно ограничить число одновременных попыток выяснить
порядковый номер зоны. Этой цели служит параметр serial-queries. При
каждом подобном запросе сохраняется информация о локальном состоянии.
Соответственно, если одновременно поступает тысяча запросов, данное
ограничение поможет серверу не "захлебнуться”. Стандартное значение — 4.
что слишком мало для крупного сервера; можно повысить его до нескольких
сотен или даже тысячи. В BIND 9 этот параметр пока что игнорируется; в
будущем он будет заменен показателем частоты запросов.
Глово 16. Системе доменных имен
443
При изменении любого из перечне ленных параметров нужно внимательно
следить за тем, чтобы производительность системы не ухудшилась. В этом
вам помогут журнальные файлы.
files числа	[unlimited]
Параметр files задает максимальное число файлов, которые могут быть
одновременно открыты на сервере. Значение по умолчанию, unlimited, не
допускается в некоторых операционных системах. В таком случае нужно
посредством параметра files сообщить демону named о том, какой предел
установлен в операционной системе. Если параметр не указан, а в операци-
онной системе ограничивается число открытых файлов, демон вызывает
библиотечную функцию sysconf(), чтобы узнать существующий предел, и
функцию setrlimitO, чтобы попытаться повысить его.
listen-on port аорт список_соответстяия_адресов; [53, все интерфейсы]
query-source address IP-адрес port порт;	[случайные значения]
Параметр listen-on определяет сетевые интерфейсы и порты, по
которым демон named ожидает поступления запросов. Параметр query-
source задает интерфейс и порт, через которые демон named будет
опрашивать другие серверы имен. Если ни порт, ни IP-адрес не указаны,
демон ведет себя следующим образом: прослушивает порт 53 по всем
интерфейсам и посылает запросы по произвольному интерфейсу, используя
непривилегированный UDP-порт. выбранный случайным образом.
Благодаря параметру listen-on можно запускать несколько серверов
имен на одном узле. Это требуется, например, в тех случаях, когда не нужно,
чтобы сервер BIND 4 или BIND 8 был одновременно и авторитетным, и
кэширующим. В этих версиях пакета информация хранится в одной
гигантской базе данных, поэтому демон named может столкнуться с нехваткой
памяти, вследствие чего данные окажутся поврежденными. Чтобы не попасть
в такую ситуацию, запустите два отдельных процесса named: один в качестве
авторитетного сервера, а другой — кэширующего. Во втором случае в
параметре Listen-on должен быть указан другой виртуальный 1Р-адрес.
Авторитетный и кэширующий серверы могут взаимодействовать так, будто
они выполняются на разных компьютерах. В файле resolv.conf необходимо
указывать IP-адрес только кэширующего сервера.
Если в организации имеется брандмауэр, настройте должным образом
параметр query-sou гее, чтобы можно было легко распознавать внешние
DNS-запросы. Брандмауэр должен знать, что исходящий DNS-трафик
поступает от одного из надежных серверов имен.
forwarders { входной адрес; входнойалрес; ... }; [пустой список]
forward only | first;	[first]
Вместо того чтобы поручать каждому серверу имен выполнять свои
собственные внешние запросы, можно сделать один или несколько серверов
переадресующими. В такой конфигурации обычный сервер просматривает в
своем кэше записи, для которых он авторитетен, и если не находит ответ,
то посылает запрос переадресуюшему узлу. Последний создает кэш, которым
пользуются все остальные серверы. Это позволяет снизить нагрузку на сеть,
сократить использование центрального процессора и памяти на более слабых
серверах, повысить производительность работы пользователей и уменьшить
зависимость от внешнего подключения к Internet. Многие организации
назначают свои наиболее мощные компьютеры переадресуюшими серверами.
444
Чость II. Робото в сетях
Организация среднего размера может построить очень эффективную
DNS-систему, сделав так. чтобы группа кэширующих серверов указывала
всего на один или два переадресующих сервера. В более крупных организациях
может потребоваться сформировать иерархию переадресующих серверов.
В разделе “Кафедральный сервер” параграфа 16.10 создается двухуровневая
иерархия.
В параметре forwarders перечисляется список IP-адресов машии,
являющихся переадресуюшими серверами. Они опрашиваются в указанном
порядке. При использовании переадресуюшего сервера традиционная проце-
дура поиска домена (сначала опрашивается корневой сервер, затем осущест-
вляется проход по цепочке отсылок) нарушается. Поэтому нужно внимательно
следить за тем, чтобы не возникало циклов переадресации.
Сервер, для которого установлен атрибут forward only, опрашивает
лереалресуюшие серверы и кэширует их ответы, но не обращается ни к кому
другому. Если переадресуюший сервер не отвечает, запрос потерпит неудачу.
Сервер с атрибутом forward first предпочитает иметь дело с переадре-
суюшими серверами, но при необходимости сможет обработать запрос
напрямую.
Поскольку у параметра forwarders нет значения по умолчанию,
переадресация не происходит, если она не была сконфигурирована созна-
тельно. Включать переадресацию можно либо глобально, либо в пределах
отдельных зон.
allow-query { список_соответствия_адресов 1; [все узлы]
allow-transfer [ список_соотнетствия_адресов ] ; [ясе узлы]
blackhole [ список_соответствия_адресов ];	[пусто]
Эти параметры позволяют указывать, какие узлы (или сети) могут
обращаться к данноьгу серверу имен и запрашивать пересылки зонных данных
В списке blackhole перечислены серверы, которые никогда не удостоятся
внимания со стороны демона named: он не будет принимать от них запросы
и обращаться к ним за ответом.
sortlist { список_соответствия_адресов ]; [не должен использоваться]
Мы упоминаем этот параметр лишь затем, чтобы читатели помнили: его
не нужно использовать. Он предназначался для оказания помощи примитив-
ным распознавателям, которые неправильно сортировали наборы записей
Он позволяет задать порядок, в котором возвращаются множественные
ответы, что противоречит внутренней логике текущих версий пакета BIND.
Среди других параметров, нарушающих привычный порядок вещей,
следует упомянуть параметр rrset-order, определяющий, в какой после-
довательности должны возвращаться множественные ответы: циклической,
фиксированной или случайной. Имеется также параметр topology, посред-
ством которого можно попытаться предугадать, как будет осуществляться
выбор удаленных серверов. В большинстве случаев ни один из этих
параметров использовать не нужно.
Инструкция ocl
Список управления доступом — это просто именованный список соот-
ветствия адресов:
acl имя_списка {
список_соответствия_адресов
};
Гпово 16. Системе доменных имен
.45
Заданное имя можно указывать везде, где требуется список соответствия
адресов.
Инструкция acl должна стоять самой первой в файле named.conf, поэтому
не пытайтесь размешать ее среди других объявлении. Файл named.conf читается
за один проход, поэтому списки управления доступом должны быть опреде-
тены до того, как на них встретится ссылка. Существует четыре предопре-
деленных списка: any, localnets, localhost и none, относящихся
соответственно ко всем узлам, всем узлам локальной сети, самому компьютеру
и ни одному узлу. Сети., входящие в группу local nets, определяются
адресами интерфейсов компьютера с учетом сетевых масок.
Инструкция server
Демон named потенциально способен общаться даже с такими серверами,
которые используют не самую последнюю версию пакета BIND, а также с
теми, что неправильно сконфигурированы. Инструкция server сообщает
демону характеристики удаленных узлов.
server ТР-адрес 1
bogus yes I no;
provide-ixfr yes I no;
request-ixfr yes I no;
support-ixfr yes I no;
transfers число;
[no J
[yes (только в V9)J
[yes (только в VSJ]
[no (только в VB) ]
[2 (только в V9) ]
transfer-format one-answer | many-answers; [V8: один, v9: много]
keys [ ключ; ключ; ... 1;
Посредством инструкции server можно переопределять значения кон-
фигурационных параметров, относящихся к серверам. Просто укажите
требуемые параметры и их новые значения.
Если для сервера задан атрибут bogus, демон named не будет посылать
ему запросы. Этот атрибут устанавливается для серверов, которые не должны
опрашиваться.
Предложения с суффиксами ixfr изменились при переходе от BIND 8
к BIND 9. В версии 8 присутствовало предпожение support-ixfr, а в
версии 9 его заменили предложения provide-ixfr и request-ixfг
Атрибут support-ixfr задается равным yes, если удаленный сервер
понимает инкрементные зонные пересылки. Сервер версии 9, являющийся
главным сервером зоны, будет выполнять инкрементные зонные пересылки,
если атрибут provide-ixfr равен yes. Точно также подчиненный сервер
версии 9 будет запрашивать инкрементные зонные пересылки, если атрибут
provide-ixfr равен yes.
Атрибут transfers ограничивает число одновременных входящих зон-
ных пересылок от удаленного сервера. Это серверный эквивалент параметра
transfers-in, но поскольку он применяется только к одному серверу, то.
по сути, переопределяет параметр transfers-per-ns. Его имя изменено
для сохранения совместимости с BIND 8.
Предложение transfer-format является эквивалентом одноименного
параметра. Его приходится использовать, когда происходит взаимодействие
серверов BIND 8/9 и BIND 4.
В предложении keys содержится идентификатор ключа, который ранее
был определен в инструкции key для использования в сигнатурах транзакций
TSIG (о них рассказывается в параграфе 16.13). К любому запросу, посылаемому
446
Чость II. Роботе в сетях
удаленному серверу, будет добавлена сигнвтура, зашифрованная посредством
этого ключа. Запросы, поступающие от удаленного сервера, не обязаны иметь
цифровую подпись, но если она есть, то будет проверена.
Инструкция logging
Демон named в настоящее время заслуживает награду “за наиболее
конфигурируемую подсистему журнальной регистрации на Земле”. Система
Syslog предоставляет программистам контроль над приоритетами сообщений,
а системным администраторам — контроль над местом хранения этих
сообщений. Но в рамках заданного приоритета администратор не может
сказать. “Это сообщение меня интересует, а это — нет”. В BIND 8 были
добавлены категории, позволяющие классифицировать сообщения по типам,
и каналы, расширяющие возможности в плане хранения сообщений. Кате-
гории назначаются программистом, а каналы — администратором.
Поскольку вопросы журнальной регистрации лежат несколько в стороне
от нашего повествования (особенно если учесть объем материала), мы
рассмотрим их позднее, в параграфе 16.14.
Инструкция zone
Инструкции zone являются “сердцем” файла па med. conf Они сообщают
демону named о зонах, для которых он авторитетен, и задают параметры
управления каждой зоной. Инструкция zone также используется для
предварительной загрузки '’’подсказок” с корневого сервера (“подсказки” —
это имена и адреса корневых серверов, участвующих в инициализации
процесса DNS-поиска).
Точный формат инструкции zone зависит от роли, которую демон named
должен играть в отношении этой зоны (например, главный или подчиненный
сервер). Мы по очереди проанализируем каждую роль. Многие из рассмот-
ренных ранее глобальных параметров могут быть частью инструкщга гопе
и тем самым переопределять глобальные установки. Мы не будем повторно
упоминать о них, за исключением тех параметров, которые наиболее часто
используются.
Конфигурирование главного сервера зоны
Ниже показан формат инструкции zone для зоны, в которой демон
named является главным сервером
zone "имядоменг" I
type master;
fij.e "путь”;
allow-query f список_соответствия_адресов }; [все узлы]
allow-transfer ( список_ооответствия_адресов }; [ясе узлы]
allow-updare ( списоксоответствияадресов }; [попе]
ixfr-base "путь";	Iимя_домена.ixfг (только в VB}]
1;
Доменное имя в спецификации зоны всегда дается в двойных кавычках.
Зонные данные хранятся на диске в текстовом файле, доступном для
редактирования. Поскольку нет соглашения о наименованни этого файла, в
объявлении зоны должна присутствовать директива file Зонный файл
представляет собой набор записей о DNS-pecypcax; его формат описан в
параграфе 16.11.
Глово 16. Система доменных имен
447
Параметры, связанные с управлением доступом, не являются обязатель-
ными. Если для зоны поддерживаются динамические обновления, в предчо-
жении al low-update должен присутствовать список узлов, от которые
разрешено принимать данные. Динамические обновления применимы только
в отношении главных зон; предложение al low-update не может присутст-
вовать в объявлении подчиненной зоны (в BIND 9). Убедитесь, что в списке
имеются лишь локальные DHCP-серверы .
Если зона поддерживает инкрементные зонные пересылки, то в BIND S
для нее создается журнал транзакций — файл имя_домена.ЬЛ' в начальном
каталоге демона named. Изменить имя файла можно посредством директивы
ixfr-base. Этот файл ведется демоном named и не требует вмешательств;!
со стороны администратора.
В BIND 9 журнал транзакций используется как для динамических
обновлений, так и для инкрементных зонных пересылок. Его имя закапчи-
вается на Jnl и не может быть изменено. Оба упомянутых механизма являются
относительно новыми в BIND. Подробнее они описываются в парагра-
фе 16.12.
При наличии различных зонных параметров (а мы не обо всех рассказали)
конфигурация зоны начинает казаться довольно сложной. На самом же деле
вполне допускается объявление главной зоны, состоящее из имени зонного
файла. В BIND 4 больше ничего нельзя было задать. Ниже показан пример,
взятый из документации и слегка модифицированный нами:
zone "example.com” {
type master;
file "forward/example.com”;
allow-query { any; };
allow-transfer i my-slaves; 1;
};
Имя my-slaves относится к списку управления доступом, определен-
ному ранее.
Конфигурирование подчиненного сервера зоны
Формат инструкции zone для подчиненного сервера будет почти таким
же, как и в случае главного сервера:
zone "ниялоиена" [
type slave I stub;
file "путь";
ixfr-base “путь";	[только в UB]
masters { IP-адрес; IP-адрес; ... );
allow-query ( список_соответствмя_адресов }; [все узлы]
allow-transfer { списск_соответствмя_адресов ); [все узлы]
1;
Подчиненные серверы обычно хранят полную копию зонной базы
данных. Но если тип сервера stub, а не slave, ему передаются только
записи NS (описания серверов имен). Усеченные зоны позволяют демонам
named родительской зоны автоматически узнавать, какие компьютеры пре-
доставляют сервис DNS для дочерних зон. Это делается на тот случай, если
администратор дочерней зоны забудет проинформировать родительскую зону
Необходима также входная фильтрация на брандмауэре, а еще лучше использовать техно-
логию TSIG для аутентификации.
448
Чость II Роботе В сетях
об изменениях. Родительской зоне нужна эта информация, чтобы правильно
делать отсылки либо рекурсивные запросы. Подробнее данная тема будет
освещаться в конце параграфа 16.11.
Директива file задает имя файла, в котором сохраняется реплициро-
ванная база данных. Каждый раз, когда сервер извлекает новую копию зонных
данных, он сохраняет их в этом файле. В случае сбоя н перезагрузки сервера
файл можно просто загрузить с диска, а не пересылать по сети.
Редактировать файл базы данных не нужно, так как он управляется
демоном named. Тем не менее имеет смысл просмотреть его, если есть
подозрение, что в базу данных главного сервера закралась ошибка. Файл
подчиненной зоны создается уже после того, как демон named проинтерпре-
тировал исходные зонные данные н раскрыл все относительные имена. Когда
в файле присутствуют имена наподобие
128.138.243.151 .cs.colorado.edu.
anchor, cs.colorado.edu .cs.colorado.cdu.
можно быть уверенным в том, что где-то пропущена завершающая точка.
В списке masters перечислены IP-адреса компьютеров, с которых можно
получить зонную базу данных. Выше мы говорили о том, что лишь один
компьютер может быть главным сервером зоны. Почему же допускается
указывать более одного адреса? По двум причинам.
Во-первых, у главного компьютера может быть несколько сетевых
интерфейсов и, соответственно, несколько IP-адресов. Когда один из интер-
фейсов становится недоступным (проблемы с сетью или маршрутизацией),
остаются в резерве другие интерфейсы. Следовательно, рекомендуется ука-
зывать все топологически различные адреса главного сервера.
Во-вторых, демону named п действительности все равно, откуда поступают
зонные данные. Он так же легко может извлечь базу данных с подчиненного
сервера, как и с главного. Этой особенностью демона можно воспользоваться
для того, чтобы сделать какой-нибудь подчиненный сервер, с которым легко
устанавливается связь, резервной копией главного сервера. В любом случае
IP-адреса проверяются по очереди до тех пор, пока не будет найден рабо-
тающий сервер. Теоретически можно даже создать иерархию серверов, в
которой главный сервер обслуживает несколько серверов второго уровня, а
те, в свою очередь, обслуживают множество серверов третьего уровня.
Мы советуем указывать только адреса главного сервера в директиве
masters.
Задание корневых 'подсказок'
Инструкция zone типа hint сообщает демону named местоположение
файла, из которого он может загрузить имена и адреса корневых серверов
имен, чтобы предварительно заполнить свой кэш:
zone ”." t
type hint;
file "путь";
}:
“Подсказки” — это набор DNS-записей, в которых перечислены серверы
корневого домена Они нужны для того, чтобы демон named знал, откуда
начинать поиск доменов. Не имея “подсказок”, демон знал бы только о тех
доменах, которые сам обслуживает, а также о своих подпоменах
Файл “подсказок" чаще всего называется root.cache. В нем содержатся
результаты ответов, которые можно получить, если запросить у корневого
Глово 16 Системо доменных имен
449
сервера список серверов имен в домене Подробнее о создании файла
“подсказок” речь пойдет в параграфе 16.15.
В BIND 9 “подсказки” корневого сервера встроены в скомпилированный
код пакета, поэтому конфигурировать корневую зону не требуется. Но если
все же задать файл “подсказок”, то система примет его. Мы рекомендуем
предоставлять явные “подсказки”; сегодня в область DNS начала вторгаться
политика, поэтому корневые серверы имен и их IP-адреса стали больше
подвержены изменениям.
Задание зоны переадресации
Зона типа forward переопределяет глобальные параметры переадресации
демона named для конкретного домена:
zone “имя домена" {
type forward
forward only I first;
forwarders { JF-адрес; IP-адрес; -..)
};
Создавать такую зону имеет смысл, если у организации есть деловой
партнер и нужно направлять трафик непосредственно его серверу имен в
обход стандартного пути распространения запросов. Благодаря этому можно
получить доступ к серверам имен, которые невидимы внешнему миру.
Инструкция key
Инструкция key задает именованный ключ шифрования, применяемый
для аутентификации на конкретном сервере. Подробнее о механизмах
аутентификации, используемых в пакете BIND, речь пойдет в параграфе 16.13
Здесь же мы лишь вкратце опишем суть процесса.
Для построения ключа нужно указать как алгоритм шифрования, так и
совместный секретный ключ, представленный в виде строки, закодированной
по основанию 64:
key идентификатор ключа (
а1g orithm строка;
secret строка;
1;
Как и в случае списков управления доступом, идентификатор ключа
должен быть определен в файле named.conf до того, как будет произведена
ссылка на ключ. Чтобы связать ключ с сервером, внесите идентификатор
ключа в список keys соответствующей инструкции server. Ключ исполь-
зуется как для проверки запросов, поступающих от сервера, так и для подписи
ответов на эти запросы.
Инструкция trusted-keys
Инструкция trusted-keys является частью механизма DNSSEC, опи-
санного в документе RFC2065. Каждая запись состоит из пяти компонентов,
идентифицирующих имя домена, флаги, протокол, алгоритм шифрования и
ключ. Все это необходимо для безопасного взаимодействия с сервером имен
домена. Формат инструкции таков:
trusted-keys {
домен флаги протокол алгоритм ключ;
450
Чость II. Роботе в сетях
домен флаги протокол алгоритм ключ;
!;
Атрибуты флаги, протокол и алгоритм являются неотрицательными
целыми числами. Атрибут ключ — это строка, закодированная по основанию 64.
Инструкция trusted-keys полезна в тех случаях, когда сама зона имеет
цифровую подпись, а ее родительская зона — нет. поэтому нельзя быть
уверенным в том. что открытый ключ, получаемый от DNS-сервера,
действительно надежен. Подробнее о технологии DNSSEC рассказывается в
параграфе 16.13.
Инструкция controls
Инструкция controls определяет, каким образом программа ndc будет
управлять работой демона named. Эта программа может запускать н останав-
ливать демон, выводить отчет о его состоянии, переводить демон в режим
отладки и т.д. Будучи сетевой программой, ndc требует должной конфигура-
ции. чтобы злоумышленники не могли через Internet влиять на работу сервера
имен. Формат инструкции таков:
controls {
inet IP-адрес port номер allow { список_соответствия_адресов
ключ . .. ) ;
unix режим_доступа владелец группа; [0600 0 0]
};
Было бы рискованно в открытую указать IP-адрес и порт сервера имен.
Лучше вообще опустить строку inet и обращаться к серверу только через
UNIX-сокет (параметры задаются в строке unix). Другой вариант — управ-
лять доступом посредством ключа аутентификации Те, кто любит риск, могут
попробовать оставить строку line, но настроить список allow так, чтобы
допускались только подключения по адресу 127.0.0.1. а внешние адреса
блокировались брандмауэром Но это подразумевает выдачу всем локальным
пользователям кредита доверия; предполагается, что они не будут делать
ничего противоправного с сервером имен. Хотя любой из них может
подключиться с помощью программы telnet к управляющему порту и ввести
команду “stop”. Поэтому по умолчанию строку inet удаляют.
Программа ndc может взаимодействовать с демоном named через имено-
ванный UNIX-сокет /var/run/ndc В строке unix задаются режим доступа к
этому сокету и его владельцы. Аргумент режимдоступа должен быть
восьмеричным числом, определяющим значение umask. Аргументы владелец
и группа должны содержать идентификаторы соответственно пользователя и
группы, которым принадлежит сокет. По умолчанию сокет доступен только
пользователю root, который имеет право чтения и записи.
Инструкция view
Представления — это новый элемент BIND 9, позволяющий показывать
внутренним компьютерам такой образ иерархии имен DNS, который
отличается от образа, доступного внешнему миру. Например, внутренние
пользователи могут видеть все компьютеры зоны и лишь несколько разре-
шенных внешних серверов. Или другой вариант: внутреннее и внешнее
представления одинаковы по охвату узлов, однако для внутренних пользова-
телей предоставляются дополнительные (либо отличающиеся) записи
Глово 16. Система доменных имен
451
Подобная конфигурация приобретает в последнее время все большую
популярность. Раньше, чтобы ее реализовать, требовалось запускать разные
серверы для внутренней и внешней версий. Локальные клиенты обращались
к внутреннему серверу, занимавшемуся рассылкой внутренней версии зонной
базы данных, а записи NS родительской зоны отправлялись на серверы,
хранившие внешнюю ее версию. Инструкция view, появившаяся в BIND 9,
упрощает эту конфигурацию, позволяя хранить оба набора данных в пределах
одной копии демона named. На основании списка соответствия адресов демон
выясняет, какие данные нужны тому или иному клиенту.
Инструкция view содержит список адресов, определяющий, кто имеет
доступ к этому представлению, плюс ряд параметров, применимых ко всем
зонам в представлении, и. наконец, определения самих зон Синтаксис
инструкции таков:
view имя_представления (
match-clients { список_соответствия_адресов };
параыетр_пре,цставления; . . .
мнетрукция_ zone; ...
};
Представления просматриваются по порядку, поэтому представления с
самыми большими ограничениями доступа должны идти впереди. Зоны в
разных представлениях могут иметь одинаковые имена. Представления
налагают следующее ограничение на структуру файла named.conf если они
присутствуют, в их состав должны входить все инструкции zone.
Ниже приводится взятый из документации к BIND 9 пример, имити-
рующий разделение пространства DNS-имен на внутреннее и внешнее.
В обоих представлениях задаются одинаковые зоны, но с разными базами
данных:
view ”internal'’ {
match-clients I наши сети; }; // только внутренние сети
recursion yes;	// только для внутренних клиентов
zone "exam.ple.com" [	// полное содержимое зоны
type master;
file "example-internal.db’';
I;
I;
view "external" {
match-clients I any };	// только внутренние сети
recursion no;	// рекурсия отсутствует
zone 'example.com" {	// только "общедоступные" узлы
type master;
file “example-external оЬ’’;
1;
Ь-
Если поменять порядок представлений, никто не сможет получить доступ
к внутреннему представлению. Адреса внутренних узлов пройдут проверку на
соответствие условию any в предложении ma tcn-cIrenes внешнего пред-
ставления до того, как начнет проверяться внутреннее представление.
16.10.	Примеры конфигурации пакете BIND
После детального знакомства с файлом named.conf настало время рас-
смотреть ряд готовых примеров. В следующих разделах мы опишем три
типичные конфигурации:
•	домашний компьютер студента, работающего в Linux;
452
Чость II. Роботе в сетях
•	кафедральный сервер, в котором применяется трехуровневая иерархия
переадресации;
•	сервер компании, занимающейся Web-хостингом и обслуживающей около
2000 зон.
Домашний Linux-компьютер
Робби Браун, студент, имеет лома Linux-систему, предоставляющую
услуги DNS для его домена synack.net, а также для доменов нескольких его
друзей В системе выполняется пакет BIND 8.2.2-Р5. Содержимое файла
named.сопГ представлено ниже. Мы добавили к нему ряд комментариев.
Конфигурация системы студента довольно проста. Параметры в основном
имеют стандартные значения: сервер является рекурсивным, файлы находятся
в привычных каталогах, записи базы данных реплицируются по одной за раз,
взаимодействие происходит через порт 53 и т.д. Изменения наблюдаются
лишь в настройках отдельных зон. Например, зона synack.net допускает
пересылки только к одному узлу и не разрешает динамические обновления.
Описываемый сервер имен является главным для двух доменов: synack.net
и xinetd.ot£. Он также выступает в качестве подчиненного сервера для доменов
teich.net и rmtai.com, принадлежащих двум друзьям Робби Раздел файла
named.conf, посвященный журнальной регистрации, является нестандартным,
что неудивительно, так как Робби все же студент факультета вычислительной
техники. Включен режим отладки на уровне 3 и созданы оригинальные
каналы (за основу взят образец файла конфигурации, входящий в комплект
поставки BIND).
/• Файл named.conf, gw.synack.net •/
options I
directory ”/var/named";
pid-file "/var/named/named.pid";
);
zone "synack.net” {
type master;
file "synack.forw";
allow-transfer ( 198.11.19.15; );
I;
zone ’‘xinetd.org" |
type master;
file "xinetd.forw”;
allow-transfer { 198.11.19.15; );
);
zone "1.168.192.in-addr.arpa" {
type master;
file "named.rev";	// обратный поиск, для частных адресов
);
zone "." {
type hint;
file “cache.db”;
);
zone “teich.net’’ ‘
Глово 16. Системе доменных имен
453
type slave;
file "teich.net.sec";
masters { 216.103.220.218; };
};
zone "rmtai.com" {
type slave;
file "rmtai.com.sec";
masters { 216.103.220.218; };
1;
// Определяются три канала регистрации событий (важные сообщения
// системы Sysiog, отладочные сообщения умеренной степени
// детализации, сообщения о загрузке зонной базы данных), а затем
// за ними закрепляются категории.
logging {
channel syslog_errors (
sysiog local1;
severity error;
I;
channel moderate__debug (
severity debug 3;	// отладка уровня 3
file "foo";	// запись в файл loo
print-time yes;	// вывод меток времени
print-category yes;	// вывод названия категории
print-severity yes;	// вывод уровня серьезности
);
channel no_info_messages {
sysiog local2;
severity notice:
};
category parser 1
syslog_errors;
default sysiog;
);
category lame-servers { null; }; // сообщения данной категории
// не регистрируются
category load { no_inf©messages; };
category default {
default_syslog;
moderate_debug;
I;
1; // конец инструкции logging
В этой конфигурации отсутствует зона обратного преобразования для узла
localhost. Соответствующая привязка должна быть сделана в файле /etc/hosts.
Кафедральный сервер
На факультете вычислительной техники университета штата Колорадо
применяются кэширующие серверы в каждой подсети. При отсутствии
нужных данных в кэше запрос переадресуется на один из подчиненных
серверов. Последние, в свою очередь, контактируют с главным сервером,
который связывается с внешними серверами от их имени. На каждом
переадресуюшем сервере установлен параметр forward first. Ниже при-
ведены все три конфигурационных файла: для кэшируюших серверов,
454
Чость II. Робота в сетях
подчиненных серверов и главного сервера. На всех серверах выполняется
пакет BIND 8.
Кэшируюший сервер удобен для подсети, где нужен локальный сервер,
но нет необходимости управлять зонной базой данных. Все, что требуется, —
это создать файл named.conf и файл “подсказок", а также организовать запуск
демона named на этапе начальной загрузки. В конфигурационном файле ие
создаются локальные зоны — только зона корневых “подсказок" и зона
обратного преобразования для узла localhost.
// Файл конфих’урации BIND 8.2 — кэширующий сервер
// Глобальные параметры
options {
directory ’’/var/nameo";
named-xfer '‘/usr/local/sbin/narned-xfer"; // только в BIND В
// создаем большой кэш благодаря главному и подчиненным серверам
forwarders {
128.138.243.151; // узел гпгое
128.138.243.140; // узел anchor
128.138.243.137; // узел rnoet
128.138.243.138; // узел vulture
128.138.236.20;	//	узел	piper
forward first;
query-source address * port 53;
I;
// Сообщения системы Sysiog регистрируются от имени средства 1оса13;
// сообщения о неправильно настроенных серверах не регистрируются
logging (
channel sysloginfo (
sysiog local!;
severity info;
};
category lame-servers { null; };
category default ( syslog_info; };
I;
// Кэш корневых серверов
zone "." i
type hint;
file "named.cache”;
// Главный сервер зоны обратного поиска для узла localhost
zone "О . С . 127 , in-adctr .arpa" [
type master;
file "localhost";
notify no;
1;
В конфигурационном файле подчиненных серверов определяется зона
прямого преобразования cs.colorado.edu и группа зон обратного преобразова-
ния, из которых мы показали только две. В данном примере маски зон
обратного преобразования не проходят по границе байтов (суффикс адреса
в основном равен /26), но поскольку все четыре подсети находятся под
единым административным контролем и описаны в одном файле, специальное
применение записи CNAME (описана в следующем параграфе) не требуется
Глово 16. Системе доменных имен
455
/I Файл конфигурации BIND 8.2 — подчиненный сервер
options (
directory "/var/named";
named-xfer ”/usr/local/sbin/named-xfer"; // только в BIND 8
forwarders { 128.138.243.151; );	H главный сервер
forward first;
query-source adaress * port 53;
allow-transfer { none; };
};
// Параметры регистрации, описания зоны корневых "подсказок'1 и зоны
// обратного преобразования для узла localhost такие же, как и
// в случае кэширующего сервера, поэтому они здесь не показаны.
// Подчиненные зоны
zone "cs.colorado.edu" {
type slave;
file "forward/cs.Colorado.edu";
masters I 128.138.243.151; I;
};
zone "250.138.128.in-addr.arpa" {
type slave;
file "reverse/250.138-128";
masters t 128.138.243.151; };
}:
zone "245.138.128.in-addr.arpa" {
type slave;
file "reverse/245.138.128”;
masters { 128.138.243.151; »;
I;
II ... описания множества зон обратного преобразования опущены
Следующий конфигурационный файл принадлежит серверу, которым
является для домена cs.colorado.edu главным и ле реадресу юшим одновремен-
но, т.е. через него проходят все локальные запросы. Это позволяет построить
большой кэш. но в то же время представляет собой нарушение правила,
гласящего, что нельзя смешивать авторитетные и кэшнруюшие серверы.
В данном файле посредством параметра topology задается приоритет
локальных серверов. Некоторые серверы не указаны в списке делегирования
родительского домена- они оповещаются об изменениях благодаря наличию
параметра also-notify.
Родительский сервер хранит свою базу данных DNS в нескольких файлах.
Зоны обратного преобразования организованы по номерам подсетей. У ка-
ждой подсети (в нашем случае — три октета в адресе класса В) имеется спой
собственный файл. Подобная организация не является обязательной, но опа
позволяет удерживать размеры файлов в разумных пределах и упрощает их
обновление. В то же время она предполагает, что маски подсетей проходят
по границе байтов или же, если подсети подвергаются дальнейшему делению,
каждый новый компонент остается под нашим административным контролем.
Если для всех зон обратного преобразования применяется один и тот же
файл, то записи можно организовать по адресам сетей, а в начале каждой
секции ставить директиву 50RIGIN, чтобы заново идентифицировать стан-
дартный домен. Подробнее об этом рассказывается при описании записи
DNAME в следующем параграфе.
56
Чость II Роботе в сетях
* Файл конфигурации BIND 8.x — главный сервер домена cs.colorado.edu
# Sid: named.conf, v 1.28 2000/01/12 00:20:34 root Exp $
acl CUnets {
128.138/16; 198.11.16/24; 204.228.69/24; 127.0.0,1;
I;
#	Глобальные параметры
options {
directory "/var/named";
named-xfer "/usr/local/sbin/named-xfer"; t только в BIND 8
notify yes;
also-notify [
128.138.192.205;	# sued
128.138.244.9;	# rtker
128.138.243.70;	1 squid
128.138.241.12;	* goober
128.138.244.100;	1 av-server
128.138.202.19;	fr nago
query-source address * port 53;
topology { localhost; localnets; CUnets; );
);
#	Параметры регистрации, описания зоны корневых "подсказок" и зоны
#	обратного преобразования для узла localhost такие же, как и прежде,
# поэтому они здесь не показаны.
г Факультет вычислительной техники
zone ’'cs.colorado.edu" {
type master;
file "forward/cs.Colorado.edu";
J;
#	Записи для зоны обратного преобразования (128.13В.Х.Х}
zone "250.138.12В.in-addr.arpa" j
type master;
file "reverse/250.138.128";
};
zone "245.138.128.in-addr.arpa”
type master;
file "reverse/245.138.128";
I;
#	... описания множества зон обратного преобразования опушены
#	Подчиненные зоны
zone "colorado.edu" [	# домен верхнего уровня
type slave;
file ’’secondaгу/Colorado.edu";
allow-transfer { none; );
masters { 128.138.240.1; );
1 ;
zone "openbsd.org"	# проект OpenBSD
type slave;
file "secondaryZopenbsd.org”;
masters { 199.45.131.58; };
};
zone "233.in-addr.arpa” { ff экспериментальный домен групповых адресов
Гпова 16. Система доменных имен
457
type slave;
file "secondary/233.In-addr.arpa";
masters ( 128.223.32.35; };
I;
♦ описания многих эон опущены
Сервер компании, занимающейся WeЬ хаСтингом
Наш следующий пример — компания, занимающаяся Web-дизайном и
Web-хостингом. Она предоставляет своим клиентам сервис DNS. Главному
серверу приходится обслуживать почти 2000 зон. причем для половины из
них он является главным, а для половины — подчиненным. Большинство
зонных файлов не очень велики (обычно 10—30 Кбайт, самый большой —
160 Кбайт), но их слишком много. Сервер — это компьютер SPARC 20,
работающий под управлением SunOS 4.1.3 и BIND 8.2.2-Р5. У него два
сетевых интерфейса и 512 Мбайт оперативной памяти.
Ниже приведены лишь небольшие фрагменты конфигурационного файла.
Объявления подчиненных зон не показаны; они аналогичны объявлениям
главных зон, за исключением типа зоны и директив master, указывающих,
где брать зонные данные. Зона корневых “подсказок” н зона обратного
преобразования для узла localhost также удалены из л истин! а; они такие же,
как и в предыдущих примерах.
Из-за наличия большого числа зон, информация о многих из которых
загружается с внешних серверов, журнальные файлы полны сообщений “zone
expired” (зонная база данных устарела) и “not authoritative for zone" (не
авторитетен для зоны). Просто многие организации не успевают вовремя
обновлять свои базы данных DNS.
// Главный сервер компании XOR
options {
directory "/var/domain";
query-source address 192.225.33.1 port 53;
aiso-notify 192.108.21.2;
I;
// Внутренние эоны прямого преобразования компании XOR
zone "xor.com" i
type master;
file "xor.com";
};
zone "creative.xor.com" {
type master;
file ’’creative.xor.com";
};
// ... другие внутренние зоны не показаны
// Зоны обратного преобразования компании ХОВ
zone "21.108.192.in-addr.arpa" {
type master;
file "xor.rev";
I;
zone "2.168.192.in-addr.arpa" (
type master;
4; iB
Чость II Робото в сетях
file "backlan-2.rev";
1;
// ... другие зоны обратного преобразования не показаны
II Клиентские зоны прямого преобразования
// Общественная больница города Боулдер	setup:01/21/2000
//=====-«==«=-—-===-™“-==““-=“==“-"“=“=““========
zone "boulderhospital.сот" (
type master;
file "boulderhosprtal.com";
1;
zone "boulderhospital.org" {
type master;
file "boulderhospital.com";
1;
// Описания примерно 1750 зон не показаны.
16.11 База данных DNS
База данных DNS для каждого домена представляет собой набор
текстовых файлов, которые системный администратор ведет на главном
сервере имен этого домена. Часто их называют зонными файлами. В них
содержатся элементы двух типов: директивы синтаксического анализатора
(например, SORTGIN и STTL) и записи о ресурсах. Первые не являются
частью базы данных, а предназначены для упрощения ввода записей.
В этом разделе мы сначала познакомимся с форматами записей о
ресурсах, которые регламентируются документами RFC882, 1035, 1183, 2065,
2181, 2308 и 2535
Записи а ресурсах
С каждой зоной в иерархии DNS связан набор записей о ресурсах (он
может быть пустым). Вот базовый формат записи:
[имя] [ ttll [класс] тип данные
Поля разделяются знаками табуляции или пробелами и могут содержать
специальные символы (табл. 16.8).
Тоблицо 16.8. Специольные символы, используемые в зописях о ресурсох
Символ	Назначение
;	Начало комментария
@	Имя текущего домена
()	Псзвсляег данным занимать несколько строк
*Метасимвол1 (только в поле имя)
1 Дополнительно об этом метасимволе будет рассказываться при описании записей MX.
Поле имя обозначает объект (обычно узел или домен), к которому
относится данная запись. Если несколько последовательно расположенных
записей ссылаются на один и тот же объект, то после первой записи поле
Глова 16. Системо доменных имен
459
имя можно опустить. Данное поле должно начинаться в первой колонке, если
она присутствует.
Имя может быть либо относительным, либо абсолютным. Имена второго
типа заканчиваются точкой и являются полностью определенными. На
внутреннем уровне программное обеспечение работает с абсолютными
именами, добавляя имя текущего домена и точку ко всем именам, которые
ие заканчиваются точкой. Это позволяет укорачивать имена, но часто
сопряжено с ошибками.
Например, в домене cs.colorado.edu имя anchor будет проинтерпретиро-
вано как “anchor.cs.colorado.edu.". Если же ввести имя anchor.cs.colorado.edu,
то отсутствие точки в конце также будет подразумевать относительное имя.
к которому следует добавить стандартный домен, что в итоге даст имя
“anchor.cs.colorado.edu.cs.colorade.edu.’’. Такие ошибки встречаются очень
часто и Moiyr оставаться необнаруженными довольно долго.
В поле tt! (Time То Live — время жизни) задается время (в секундах), в
течение которого элемент данных может оставаться в кэше и при этом
считаться достоверным. Это поле часто опускают, но оно обязательно
присутствует в файле, содержащем корневые "подсказки”. Стандартное
значение поля задается директивой STTL, размещаемой в начале зонного
файла. В BIND 9 эта директива обязательна. В BIND 8, если она отсутствует,
поле п1 определяется отдельно для каждой зоны на основании значения,
задаваемого в записи SOA.
Если время жизни записей задать равным примерно неделе, это приведет
к значительному снижению сетевого трафика и нагрузки на DNS Однако
следует помнить о том, что. когда запись сохранена в кэше за пределами
локальной сети, ее уже нельзя принудительно сделать недостоверной.
Поэтому, планируя провести реструктуризацию сети, сделайте значение $TTL
достаточно низким-, чтобы записи, находящиеся во внешних кэшах, быстро
устаревали
В поле каасс задается тип сети. Распознаются три значения: IN (Internet).
CH (Chaos) и HS (Hesiod). Класс Chaos обозначает ChaosNet — почти
исчезнувший сетевой протокол, ранее применявшийся на Lisp-машинах
фирмы Symbolics. Hesiod — это информационная служба, являющаяся над-
стройкой пакета BIND. Класс IN установлен по умолчанию, но даже несмотря
на это, он. как правило, явно указывается в зонных файлах. В настоящее
время лишь один элемент данных скрыт в пределах класса Chaos: номер
версии демона named, который можно узнать с помощью программы dig
(см. параграф 16.6).
Существуют различные типы DNS-записей, но широко используются
менее десяти из них. В стандарте IPv6 добавилось еще несколько типов. Мы
разбиваем записи о ресурсах на четыре группы:
•	зонные записи — определяют домены и их серверы имен;
•	базовые записи — связывают имена с адресами и обеспечивают маршру-
тизацию почты;
•	аутентификационные записи — предоставляют информацию, касающуюся
аутентификации и сигнатур;
•	факультативные записи — содержат дополнительную информацию о
компьютерах и доменах.
Содержимое поля данные зависит от типа записи (табл. 16.9).
460
Чость II Робота в сетях
Тоблицо 16.9. Типы зописей DNS
	Тип	Содержимое/нозначение
Зонные	SOA NS	Определение DNS-зоны Определение серверов зоны, делегирование полномочия поддоменам
Возовые	А АААА Аб PTR DNAME MX	Преобразование имени в адрес Устарела и не должна использоваться Преобразование имени в адрес IPv6 (только в BIND 9) Преобразование адреса в имя Передача полномочий при обратном преобразовании ад- ресов IPv6 (только в BIND 9) Маршрутизация электронной почты
Аутентмфи- коционные	KEY NXT SIG	Открытый ключ шифрования для DNS-имени Указание на следующую запись зонной базы данных при обработке отрицательных ответов в протоколе DNSSEC Сигнатура зоны
Фокульта- тивные	CNAME LOC RP SRV TXT	Дополнительные имена узла Географическое местоположение и физический размер DNS-объекта1 Контактная информация для связи с администратором узла Местоположение известных сервисов в пределах домена Комментарии или нестандартная информация
Существуют проблемы с поддержкой записи LOC в NT (запрос к записи LOC
приводит к краху сервера NT).
Существуют и другие типы записей, которые либо устарели, либо
являются экспериментальными, либо не нашлн широкого применения.
Полный их список приведен в документации к пакету BIND.
Порядок записей о ресурсах почти произволен. Запись SOA для зоны
должна идти первой. Последующие записи могут располагаться в любом
порядке, но обычно сразу же за записью SOA следуют записи NS. Записи
по каждому узлу, как правило, группируются. Самый распространенный метод
сортировки этих записей — по полю /шя.
Подробно описывая все типы записей о ресурсах, мы рассмотрим в
качестве примера записи из базы данных домена cs.colorado.edu. Поскольку
домен по умолчанию — cs.colorado.edu, то имя машины anchor в действи-
тельности означает anchor.cs.colorado.edu.
Запись SOA
Запись SOA отмечает начало зоны — группы записей о ресурсах, распо-
ложенных в одной области пространства имен DNS. Этот узел дерева DNS
также называют точкой делегирования. Как будет показано ниже, домен DNS
обычно соответствует минимум двум зонам; одна служит для преобразования
имен компьютеров в IP-адреса, а остальные — для обратного преобразования.
Для каждой зоны создается всего одна запись SOA. Зона продолжается
до тех пор. пока не встретится следующая такая запись. Запись SOA содержит
имя зоны, контактггъгй адрес, порядковый номер и различные параметры
обновления данных. Например:
; Начало зоны для домена cs.colorado.edu
0	IK SOA ns.cs.Colorado.ecu. admin.cs.colorado.edu. (
Глово 16. Системе доменных имен
461
1999121501	;	Порядковый номер
21600	;	Период обновления, 6 часов
1ВОО	;	Интервал между попытками, 30 минут
1209600	;	Период устаревания, 2 недели
7200 )	; Минимальное время жизни, 2 часа
Поле имя содержит символ обозначающий имя текущей зоны.
В данном примере можно было вместо этого символа использовать cs.colo-
rado.edu. Текущее имя задается в инструкции zone файла named.conf и может
быть изменено в зонном файле посредством директивы SORIGIN (см. опи-
сание записи DNAME)
В показанном фрагменте поле и! отсутствует. Класс зоны — IN (Internet),
тип записи — SOA, а остальные элементы составляют поле данные.
Имя “ns.cs.colorado.edu.” ссылается на главный сервер имен этой зоны.
Имя “admin.cs.colorado.edu.” указывает адрес электронной почты для контак-
тов с администратором домена. Адрес дан в формате '"пользователь.узел. ”
(а не пользователь&узел). Если необходимо отправить сообщение админист-
ратору, просто замените первую точку знаком @ и уберите хвостовую точку.
Вместо реального регистрационного имени часто используется псевдоним,
например admin или hostmaster
Круглые скобки позволяют растянуть запись SOA на несколько строк.
Их размещение не произвольно в BIND 4 и 8: мы попробовали укоротить
первую строку, разделив ее перед контактным адресом, но демон named не
смог распознать такую запись. В некоторых реализациях круглые скобки
распознаются только в записях SOA и TXT. В BIND 9 улучшенный модуль
синтаксического анализа, поэтому круглые скобки могут использоваться везде.
Первый числовой параметр — это порядковый номер конфигурационных
данных зоны. С его помощью подчиненные серверы определяют, когда
следует брать новые данные. Порядковым номером может быть любое
32-разрядное целое число, причем оно должно увеличиваться при каждом
изменении зонного файла. Во многих организациях в этот номер зашифро-
вывается дата последней модификации файла. Например, 2000123101 озна-
чает, что первое изменение в зонном файле было сделано 31-го декабря
2000 г.
Порядковые номера не обязаны быть непрерывными, но должны моно-
тонно возрастать. Если случайно задать на главном сервере очень большое
число и оно будет передано подчиненным серверам, то исправить порядковый
номер на главном сервере не удастся. Подчиненные серверы запрашивают
новые данные только в том случае, когда порядковый номер записи SOA
главного сервера больше, чем у них.
Существует три способа решения этой проблемы. В BIND 4.9 и BIND 8
есть прием, который позволяет сбросить порядковый номер в нуль на один
интервал обновления, а затем заново начать нумерацию. Нулевой номер
всегда вызывает обновление, поэтому не забудьте присвоить ему нормальное
значение после того, как все подчиненные серверы загрузят зонные данные.
Более утомительный способ — изменить порядковый номер на главном
сервере, уничтожить процессы named на подчиненных серверах, удалить их
резервные базы данных, а затем перезапустить их. При отсутствии кэша
подчиненные серверы вынуждены будут повторно загрузить базы данных с
главного сервера. Третий способ — воспользоваться особенностями последо-
вательного пространства, из которого выбираются порядковые номера Суть
заключается в том. что к имеющемуся номеру добавляется “магическое"
число, все подчиненные серверы обновляют свои данные, после чего
462
Чость II. Робото в сетях
устанавливается требуемый номер. Подробнее об этом рассказывается в
документе RFC 1982.
Наиболее распространенная ошибка состоит в том, что пользователь из-
меняет файлы данных, забывая при этом исправить порядковый номер.
В наказание демон named откажется распространить внесенные изменения
на подчиненные серверы.
Следующие четыре элемента записи SOA — значения интервалов времени
(в секундах), определяющих, как долго данные могут находиться в кэше в
различных точках всемирной базы данных DNS. Их выбор требует нахождения
компромисса между эффективностью (использование старого значения де-
шевле выборки нового) и точностью (новые значения более точны)
Первый элемент — период обновления данных. Он показывает, как часто
подчиненные серверы должны связываться с главным сервером и проверять,
не изменился ли порядковый номер конфигурации зоны. Если зонные данные
изменились, подчиненные серверы должны обновить свои копии базы
данных. Общепринятые значения для данного интервала — от одного до
шести часов (3600 — 21600 секунд).
Вместо того чтобы пассивно ждать истечения периода обновления,
современные серверы BIND самостоятельно уведомляют свои подчиненные
серверы об изменениях зон, если только в конфигурационном файле не
отключен параметр notify. Серверы, понимающие подобные уведомления,
немедленно обновляют свои базы данных.
Если подчиненный сервер пытается узнать порядковый номер у главного
сервера, а тот не отвечает, то по истечении определенного интервала будет
сделана повторная попытка. Наш опыт показывает, что наиболее подходящее
значение для второго элемента — от 20 до 60 минут (1200 — 3600 секунд).
Если главный сервер длительное время отключен, то подчиненные
серверы будут многократно пытаться обновить свои данные, однако безус-
пешно. В конце концов все подчиненные серверы решат, что главный сервер
не включится никогда и его данные наверняка устарели. Период устаревания
определяет, как долго подчиненные серверы будут продолжать обслуживать
домен в отсутствие главного сервера. Система должна просуществовать, даже
если главный сервер не работает неделю, поэтому третьему элементу следует
присваивать большое значение. Мы рекомендуем выбирать интервал от недели
до месяца.
До появления BIND 8.2 четвертый элемент задавал стандартное время
жизни записей о ресурсах. Он включался в каждую запись и использовался
для проверки устаревания записей на неавторитетных серверах. В BIND 8.2
значение этого параметра в записи SOA изменилось. Теперь он определяет
длительность нахождения в кэше отрицательных ответов. Время жизни по-
ложительных ответов (т.е. собственно записей) устанавливается директивой
$TTL в начале зонного файла. Как свидетельствует практика, значение $тть
должно быть от нескольких часов до нескольких дней, а минимальное время
жизни — один-два часа (предельное значение — три часа).
Значение $тть, период устаревания и минимальное время жизни в
конечном итоге заставляют всех пользователей DNS удалять старые данные.
Изначально архитектура DNS основывалась на том факте, что данные об
узлах относительно стабильны и меняются нечасто. Но с появлением прото-
кола DHCP и портативных компьютеров все перевернулось. Теперь разра-
ботчики пакета BIND отчаянно пытаются угнаться за временем, внедряя
механизмы инкрементных зонных пересылок и динамического обновления
(описаны в параграфе 16.12).
Глово 16. Системе доменных имен
463
Записи NS
Записи NS описывают серверы имен, которые авторитетны для данной
зоны (т.е. все главные и подчиненные серверы), а также делегируют
полномочия по управлению поддоменами другим организациям. Обычно эти
записи следуют за записью SOA. Их формат таков:
зона [ttl] IN NS иияузле
Например:
cs.Colorado.edu.
cs.Colorado.edu.
cs.Colorado.edu.
IN NS ns.cs-colorado.edu.
IN NS anchor.cs.colorado.edu.
IN NS nc.CB.utah.edu.
Если имя зоны совпадает с полем имя записи SOA, которая идет перед
записями NS, поле зона можно оставить пустым. Поэтому строки
IN	NS	ns.cs.Colorado.edu.
IN	NS	anchor.cs.colorado.edu.
IN	NS	nc.cs.utah.edu.
стоящие после записи SOA для зоны cs.colorado.edu, будут эквивалентны
приведенным выше.
Следует указывать все авторитетные серверы имен домена cs.colorado.edu.
причем это нужно делать как в зонном файле данного домена, так и в файле
родительской зоны, т.е. colorado.edu. Кэширующие серверы не могут быть
авторитетными, поэтому их приводить не нужно В записи NS нет ключевого
слова, которое указывало бы тип сервера (главный или подчиненный). Эта
информация находится в файле named.conf.
На основании записей NS зоны демон named находит подчиненные
серверы, когда ему нужно разослать уведомления об изменении зонных
данных. Те же самые записи, присутствующие в описании родительской зоны
(colorado.edu), определяют поддомен “cs" и передают полномочия по его
управлению серверам имен факультета вычислительной техники. Если список
серверов имен в описании родительской зоны не совпадает с аналогичным
списком самой зоны, то любой новый сервер становится невидимкой и не
используется для ответов на запросы из внешнего мнра. Подобные ситуации
иногда возникают вследствие ошибок проектирования, иногда — из-за
забывчивости.
Беглый взгляд на информацию о делегировании в нашей собственной
сети позволил обнаружить крупный сервер домена colorado.edu, о котором
домен "edu” ничего не знал. Иногда стоит проверять информацию о
делегировании с помощью программы nslookup или dig, чтобы убедиться в
наличии правильного набора серверов.
Подробнее о делегировании рассказывается в конце текущего параграфа.
Записи А
Записи А являются основной частью базы данных DNS. Они обеспечи-
вают перевод имен компьютеров в IP-адреса (процедура, ранее выполняв-
шаяся в файле /etc/hosts). Для каждого из сетевых интерфейсов компьютера
должна существовать одна запись А. Эта запись имеет следующий формат:
ммя_узла [ttl] IN А ТР-адрес
464
Часть II Работа в сетях
Например:
anchor IN A 128.138.243.100
Если у компьютера несколько сетевых интерфейсов, то с ними можно
связать общее доменное имя или же за каждым закрепить свое имя.
Записи PTR
Записи PTR выполняют обратное преобразование IP-адресов в доменные
имена. Как и в случае с записями А, для каждого сетевого интерфейса
компьютера должна быть сделана одиа запись PTR. Но прежде чем
знакомиться с этими записями, давайте немного отвлечемся и поговорим о
специальном домене верхнего уровня, который называется in-addr.arpa.
Полностью определенные имена компьютеров можно рассматривать как
структуру, в которой наиболее “значащая” часть стоит справа. Например, в
имени anchor.cs.coiorado.edu узел anchor принадлежит домену “cs”, последний
находится в домене “Colorado”, а тот — в домене “edu”. С другой стороны,
в IP-адресах самая “значащая” часть стоит слева. В адресе 128.138.243.100
узел 100 находится в подсети 243, которая является частью сети 128.138.
Домен in-addr.arpa был создай с той целью, чтобы и для прямых, и для
обратных преобразований использовался один и тот же набор программных
модулей и единое дерево имен. Домены в ветви in-addr.arpa именуются как
IP-адреса с обратным порядком следования байтов. Например, зона для
нашей подсети 243 называется 243.138.128.in-addr.arpa.
Общий формат записи PTR таков:
адрес [Etl] IN PTR имя_узла
Запись PTR в зоне 243.138.128.m-addr.arpa, соответствующая приведенной
выше записи А для узла anchor, будет иметь такой вид.
100 IN PTR anchor.cs.colorado.edu.
Имя 100 не заканчивается точкой и потому является относительным.
Вопрос: относительно чего? Ни в коем случае не относительно домена
“cs.colorado.edu.”. Для того чтобы эта запись была точной, домен по
умолчанию должен называться “243.138.128. in-addr. игра.”.
Этого можно добиться, поместив записи PTR для каждой подсети в
отдельный файл, за которым закрепляется стандартный домен в файле кон-
фигурации демона named. Другой способ выполнить обратное преобразова-
ние — включить в зонный файл записи вида
100.243 IN PTR anch.ar.cs.colorado.edu.
с доменом I38.128.in-addr.arpa по умолчанию. В некоторых организациях все
записи обратного преобразования помещаются в один файл, а задание подсети
осуществляется посредством директивы SORIGIN. Обратите внимание на то,
что имя anchor.cs.colorado.edu должно оканчиваться точкой, иначе к нему
будет добавлена строка 138.128.in-addr.arpa.
Поскольку cs.colorado.edu и 243.138.128. in-addr.arpa — разные области
пространства имен DNS, они составляют две отдельные зоны. У каждой из
этих зон должна быть своя запись SOA и свои записи о ресурсах. Помимо
определения зоны in-addr.arpa для каждой реальной сети, нужно также задать
зону, которая заботилась бы об интерфейсе обратной связи. 127.0.0 0.
Глово 16. Сисгемо доменных имен
465
Описанные привязки прекрасно работают, когда маски подсетей проходят
по границе байтов. Но как выполнять обратные преобразования для такой
подсети, как 128,138.243.0/26? В документе RFC2317 описан красивый прием,
основанный на применении записей CNAME; подробнее об этом речь пойдет
ниже.
Обратные преобразования, выполняемые записями PTR, используются
всеми программами, которые аутентифицируют входящий сетевой трафик.
Например, демон sshd допускает удаленную регистрацию без пароля, если
исходная машина указана по имени в пользовательском файле ~/.shosts. Когда
машина-адресат получает запрос на установление соединения, она знает
машину-отправитель только по iP-адресу. Пользуясь услугами DNS. она
преобразовывает IP-адрес в имя, которое сравнивается с содержимым
соответствующего файла. Программы netstat. tcpd, sendrnail, sshd, syslogd,
fingerd, ftpd, rlogind — вес они получают имена компьютеров из lP-алресов с
помощью обратного преобразования.
Важно, чтобы записи А соответствовали записям PTR Несовпадение и
отсутствие последних приводит к ошибкам аутентификации и тайм-аутам, в
результате чего система замедляет работу. Это само по себе неприятно, но
еще хуже то, что появляется почва для атак типа “отказ от обслуживания”,
направленных на любое приложение, требующее соответствия записям А или
Аб при обратном преобразовании.
Записи MX
Записи MX используются системой электронной почты для более
эффективной маршрутизации почтовых сообщений. Запись MX подменяет
адресата сообщения, в большинстве случаев направляя сообщение концен-
тратору электронной почты на сервере получателя, а не прямо на его рабочую
станцию.
Об электронной почте речь пойдет в главе 21.
Запись MX имеет следующий формат:
имя [ttl] IN MX приоритет узел ...
Ниже приведены два примера: один для узла, который получает
адресованную ему почту, несмотря на то что выключен, а второй — для узла,
который вообще ие может получать почту.
piper	IN	MX	10	piper
IN	MX	20	mailhub
IN	MX	50	boulder.colorado.edu.
xterml	IN	MX	10	ntailhub
IN	MX	20	anchor
IN	MX	50	boulder.colorado.edu.
Сначала опрашиваются узлы с низким приоритетом (наиболее предпоч-
тительный приоритет — 0; самый нежелательный — 65535). В данном случае
почта, адресованная пользователю bob@xterml, будет маршрутизироваться
следующим образом. Если доступен концентратор mailhub, почта отправляется
туда; в противном случае она посылается иа машину anchor. Если оба
отключены, почта направляется на узел boulder. При этом имя узла boulder
должно быть полностью определенным, поскольку он не является членом
стандартного домена (в данном примере — “cs.colorado.edu.").
466
Чость II. Робот© в сетях
Список приоритетов и узлов можно, н принципе, давать в одну строку,
но отдельные строки легче читать. Между значениями приоритетов оставляйте
числовое “пространство", чтобы в случае необходимости всегда можно было
добавить нового адресата.
Записи MX полезны во многих ситуациях, например:
•	если в системе есть центральный концентратор почты;
•	если машина-адресат выключена;
•	если адресат не подключен к Internet;
•	если маши на-адресат ие понимает протокол SMTP;
•	если локальный системный администратор лучше знает, куда следует
посылать сообщения.
В первом из этих случаев почта направляется на концентратор —
компьютер, где большинство пользователей читает почту. Во втором случае
почта переадресуется на ближайший компьютер и возвращается на машину-
адресат, когда та вновь будет включена.
Если компьютер не подключен к Internet, у него не может быть записи А
в DNS, но могут быть записи MX. Система sendmail не способна установить
непосредственное соединение с адресатом, но может переслать почту поближе
к нему, связавшись с одним из узлов, указанных в записях MX. Такой узел,
вероятно, напрямую подключен к маш ине-адресату или знает, как получить
к нему доступ (к примеру, через брандмауэр или по протоколу UUCP).
В конце концов, записи MX могут применяться просто потому, что
локальные системные администраторы гораздо лучше знают организацию
почтовой системы, чем те, кто присылает в организацию письма. За
администраторами остается право определять, по каким каналам распростра-
няются почтовые потоки.
У каждого учла должны быть записи MX. Для второстепенных узлов
достаточно одного-двух альтернативных вариантов. Крупный узел должен
иметь как минимум трн записи:
•	одну для себя, как основной вариант;
•	другую для локального почтового концентратора, как второй вариант;
•	третью для центрального концентратора домена или его родительского
домена, как резервный вариант.
У самого домена должна быть запись MX для узла-концентратора, чтобы
можно было посылать почту по схеме пользователь^ домен. Естественно, такая
конфигурация требует наличия уникальных пользовательских имен на всех
компьютерах данного домена. Чтобы иметь возможность посылать почту
пользователю evi@cs.colorado.edu, нам нужна либо машина cs. либо записи
MX в домене cs.colorado.edu:
cs	IN MX 10 mailhub.cs.colorado.edu.
IN MX 20 anchor.cs.colorado.edu.
IN MX 50 boulder.colorado.edu.
Компьютер, принимающий почту для другого узла, должен содержать его
нмя в файлах конфигурации sendmail. В параграфе 19.8 будет рассказываться
о средстве use cw file и файле local-host-names, используемых в sendmail
для этих целей.
В базе данных DNS иногда можно встретить метазаписи MX:
w	IN MX 10 mailhub.cs.colorado.edu.
inoeo 16. Системе доменных имен

На первый взгляд кажется, что такая запись позволяет избежать
многократного ввода данных и является стандартной записью для всех узлов.
Однако метасимвол работает совсем не так, как можно ожидать. Он
соответствует любому полю имени, которое еше не было указано в явном
виде в других записях о ресурсах.
Следовательно, нельзя использовать звездочку с целью задания какого-
либо стандартного значения для всех своих компьютеров. Можно — что
неправильно — задать посредством нее маршрут для "чужих” машин.
В результате на концентратор будет поступать масса почтовых сообщений,
тут же отвергаемых по той причине, что имя узла, обозначенное звездочкой,
не принадлежит данному домену. Посему следует избегать употребления
метасимвола в записях MX.
Записи CNAME
Записи CNAME позволяют назначать узлу дополнительные мнемониче-
ские имена. Псевдонимы широко применяются для закрепления за компью-
тером какой-либо функции либо просто для сокращения имени. Реальное
имя иногда называют каноническим. Вот несколько примеров:
ftp	IN CNAME anchor
kb	IN CNAME kibblesnbits
Запись CNAME имеет следующий формат:
псевдоним [tcJ] IN CNAME иияуэла
Когда DNS-модуль обнаруживает запись CNAME, он перестает посылать
запросы по мнемоническому имени и переключается на реальное имя Если
у компьютера есть запись CNAME, то другие записи для данного узла (А,
MX, NS и др.) должны ссылаться на его реальное имя, а не на мнемоническое
Например, строки
colo-gw IN A 128138.243.25
moogie IN CNAME colo-gw
www IN CNAME moogie
являются правильными Но если связать адрес или почтовый приоритет
(посредством записей А и MX) с именем www или moogie, то это будет неверно
В BIND длина цепочки записей CNAME не должна быть больше восьми.
Цепочка — это ситуация, когда одна запись CNAME ссылается на другую,
та — на третью и т.д. Последним, восьмым элементом должна, быть реальная
запись А.
В некоторых организациях делается попытка посредством записей
CNAME обеспечить распределение нагрузки. Открытое имя Web-сервера
связывается с несколькими компьютерами-
www	IN	CNAME	webl
www	IN	CNAME	web2
www	IN	CNAME	web3
Подобное применение записей CNAME является нестандартным. По
сути, оно запрещено, так как противоречит спецификации. В BIND 8 есть
специальный параметр, разрешающий данный механизм. Пакет BIND 9 более
требователен, поэтому .лучше не пользоваться множественными записями
CNAME. Лучше создать для Web-сервера несколько записей А, ссылающихся
на разные компьютеры.
468
Чость II Рсбото е сетях
0
Специальное применение записей CNAME
С помощью записей CNAME можно организовать поддержку зон
обратного преобразования для сетей, где маски подсетей не проходят по
границе байтов. До того как протокол CIDR получил широкое распростра-
нение, такая организация подсетей не применялась или. по крайней мере,
“неправильные” подсети существовали в рамках одной организации, поэтом}
управлять зонами обратного преобразования было несложно. Например, если
сеть 128.138 класса В разделить на группу подсетей класса С, то каждая
подсеть займет свое строго оговоренное место в домене in-addr.arpa. Зоной
обратного преобразования для подсети 243 будет 243.138.128.Ln-addr.arpa.
О протоколе CIDR рассказывалось в параграфе 13.4.
Но что произойдет, если подсеть 243 разделить еще. допустим, на четыре
подсети /26? Если все они находятся в пределах одной организации, то это
не проблема; такие подсети по-прежнему описываются в одном файле,
содержащем все их записи PTR. Но может быть так, что подсеть 243 при-
надлежит провайдеру Internet, который делегирует подсети /26 разным
клиентам В этом случае решение будет более сложным. Провайдер должен
либо управлять записями зон обратиого преобразования на стороне каждого
клиента, либо найти способ разделить третий байт IP-адреса (в данном
примере — 243) на четыре разных элемента, каждый из которых делегируется
независимо.
Когда административная граница проходит посередине байта, приходится
быть изворотливым. Нужно также тесно взаимодействовать с доменом,
находящимся выше или ниже в иерархии. Решение может быть следующим:
для каждого возможного адреса узла в зоне in-addr.arpa следует добавить
запись CNAME, которая переводит операцию поиска в зону, управляемую
владельцем соответствующей подсети. Подобная схема приводит к образова-
нию громоздких зонных файлов в родительском домене, но она же позволяет
передавать полномочия реальным пользователям каждой подсети.
Рассмотрим описываемый процесс детальнее. Родительская организация
(в нашем случае — провайдер) создает для каждого возможного IP-адреса
записи CNAME со специальным искусственным компонентом (отделяется
точкой), представляющим подсеть. Например, для первого из четырех блоков
адресов подсети /26 дополнительный компонент будет называться “0-63”, для
второго — “64-127” и т.д. Вот как это выглядит:
5ORIGIN 243.138.128,in-addr.arpa.
1	IN	CNAME	1.0-63
2	IN	CNAME	2.0-63
63	IN	CNAME	63.C-63
64	IN	CNAME	64.64-127
65	IN	CNAME	65.65-127
Чтобы передать управление адресами 0-63 зоны обратного преобразования
клиенту, за которым закреплена эта подсеть, нужно добавить следующие
записи NS:
0-63	IN NS	nsl .customer 1 .corn.
0-63	IN NS	ns2.customerl.com.
Глово 16 Системе доменных имен
469
На узле customerl.com будет создан зонный файл, содержащий привязки
для зоны обратного преобразования 0-63.243.138.128.in-addr.arpa. Например:
1	IN FTR	hostl.customerl.com.
2	IN PTR	hosc2.customerl.com.
Добавив дополнительный компонент, мы тем самым создали новую точку
передачи полномочий. Когда, например, кто-то попытается найти домен-
ное имя, соответствующее адресу 128.138.243.1, запись CNAME в точке
1.243.138.128. in-addr.arpa перенаправит поиск в точку 1.0-63.243.138.128.in-
addr.arpa, а этим именем уже управляет реальный клиент.
Клиентские зонные файлы не содержат ничего лишнего; со всеми
конфигурации иными записями приходится иметь дело провайдеру. Ситуация
усложняется, если клиент сам является провайдером и дальше делит свое
адресное пространство. Однако непреодолимых препятствий не существует:
в BIND поддерживаются цепочки записей CNAME длиной до восьми
элементов, а поскольку в байте, как известно, восемь битов, превышения
допустимого предела не произойдет. Различные документы RFC не одобряют,
но и не запрещают применение таких цепочек. К негативным последствиям
можно отнести то, что скорость распознавания имен замедляется, так как
модуль распознавания должен пройти по каждому звену цепочки, послав
соответствующее число запросов серверу.
Описанная схема применения записей CNAME ужасно неэффективна,
но она настолько удобна, что ее разновидность была принята в качестве
официального стандарта для обработки зон обратного преобразования IPv6.
Подробнее об этом будет рассказываться ниже, при описании записей
DNAME.
Когда данная схема стала достаточно популярной, набор команд,
понимаемых демоном named, пополнился директивой SGENERATE (о ней речь
будет идти далее), которая упрощает создание записей о ресурсах в
родительской зоне. Например, чтобы сгенерировать все необходимые записи
для первой подсети, достаточно следующих строк:
SORIGIN 243.138.128.in-addr.arpa.
SGENERATE 0-63 S CNAME S.0-63
0-63	IN NS	nsl.customerl.com.
0-63	IN NS	ns2.customerl.com.
Метасимвол $ в директиве SGENERATE является счетчиком цикла и
приводит к созданию 64-х различных записей CNAME. Остальные три
подсети /26 обрабатываются аналогичным образом-
Рассмотренное применение записей CNAME поддерживается в BIND 8
и 9. В некоторых старых модулях распознавания пакета BIND 4 не
предполагается получения записей CNAME в ответ на запрос к записям PTR,
поэтому такие запросы потерпят неудачу. Это одна из причин, по которой
не рекомендуется применять старые версии пакета.
Записи ЮС
Запись LOC определяет географическое местоположение и, необязатель-
но, физический размер (диаметр) объекта DNS. В настоящее время записи
LOC не оказывают влияния на функционирование сети Internet, и сущест-
вующие программы не производят их поиск. Но было предложено множество
470
Чость II Роботе в сетях
интересных применений информации, содержащейся в этих записях, включая
трассировку и оптимизацию маршрутов, а также сетевые исследования.
Записи L.OC описаны в документе RFC1876.
Формат записи таков;
имя [ttl] IN LOC широта долгота [высота (разм {горточн [вертточн]]} 1
Широта и долгота задаются в градусах, минутах и секундах (разделяются
пробелами), после которых следует обозначение N (north — север), S (south —
юг), Е (east — восток) или w (west — запад). Секунды можно опустить,
допускается также указывать только градусы.
Последующие поля задаются в сантиметрах (по умолчанию) илн в метрах
(суффикс т). Аргумент высота — это высота объекта иад уровнем моря,
разм — это диаметр воображаемой сферы, окружающей объект, горточн —
горизонтальная точность измерения, а вертточн — вертикальная точность.
По умолчанию размер равен одному метру, горизонтальная точность —
10 метров, а вертикальная — 10 километров.
Вот пример для узла caida.oiE, расположенного в Сан-Диего, штат
Калифорния;
caida.org. IN LOC 32 53 01 N 117 14 25 W 107m 30m Ifim 15m
Многие утилиты визуализации, написанные организацией CA1DA (Co-
operative Association for Internet Data Analysis — совместная ассоциация по
анализу данных в сети Internet), требуют наличия данных о широте и долготе,
поэтому администраторам Web-узлов рекомендуется включать соответствую-
щую информацию в свои базы данных DNS. Но не все заинтересованы в
том, чтобы кто угодно знал их местоположение. В таких ситуациях можно
использовать неточные значения. Они все равно представляют определенную
ценность для людей, занимающихся сетевым анализом, и в то же время
обеспечивают некоторую анонимность.
К особенностям записей LOC следует также отнести то, что запрос к
ним приводит к краху сервера имен NF 4.0. поэтому будьте осторожны
Записи SRV
Запись SRV определяет расположение сервисов в пределах домена.
К примеру, эта запнсь может позволить запросить удаленный домен и узнать
имя его FTP-сервера. Раньше в подобной ситуации приходилось действовать
наугад. Можно было лишь надеяться, что администратор удаленного домена,
следуя традиционной практике, добавил запись CNAME для имени “Пр’’ в
базу данных DNS.
Записи SRV гораздо разумнее применять для этих целей, и с их помощью
администраторам намного удобнее менять местоположение сервисов и
контролировать их использование. Однако требуется, чтобы сами клиенты
знали, как найти и проанализировать эти записи, поэтому эффект от их
применения пока не столь ощутимый
Записи SRV напоминают обобщенные записи MX с дополнительными
полями, которые позволяют локальному администратору DNS управлять
внешнимн соединениями и распределять нагрузку на сервер. Формат записей
таков;
сервис.протокол.имя [CtJ] IN SRV приоритет вес порт сервер
Глово 16. Системе доменных имен
471
Аргумент сервис — это имя сервиса, определенное в базе данных IANA
(Internet Assigned Numbers Authority — агентство по выделению имен и
уникальных параметров протоколов Internet); получить дополнительную
информацию можно в параграфе 13.3 или по адресу www.iana.oig/num-
bers.htm. Аргумент протокол должен быть равен либо сер, либо udp. Аргумент
имя — это домен, на который ссылается запись SRV. Аргумент приоритет
имеет тот же смысл, что и в записи MX. Аргумент вес используется для
распределения нагрузки между’ несколькими серверами, порт — это номер
порта, на котором выполняется сервис, а сервер — это имя сервера,
предоставляющего данную услугу. В ответ на запрос к записи SRV обычно
возвращается запись А сервера Имя сервера, равное “ ", означает, что сервис
недоступен на данном узле. Если вес равен 0. то специального распределения
нагрузки не требуется.
Ниже показан пример, взятый из документа RFC2052 (где определена
запись SRV) и адаптированный для домена cs colorado.edu:
ftp.cep	SRV	О	0	21	ftp-server.cs.colorado.edu.
; доступ к сервису Finger закрыт (имя сервера = .)
finger.tcp	SRV	О	0	79
; одна четверть соединений оОслуживается старым компьютером,
; а три четверти - новым
ash.tcp SRV О 1 22 old-slow~oox.cs_coloradc.edu.
SRV О 3	22 new-fast~nox.cs.colorado.edu.
; основной сервер доступен через порт ВО,
; а резервный — через ;:орт 8CQ0 на новом компьютере
http.tcp SRV О 0 80	www—server.cs.Colorado.edu.
SRV 10 0	8000 new-fast-box.cs.Colorado.edu.
; в адресной строке можно указывать как http://www.cs.colorado.eau,
; так и http://cs.colorado.edu
http.tcp.www SRV О 0	60 www-server.cs.coloraao.edu.
SRV ID 0	8000 new-fast-box.cs.coiorado.edu.
; все остальные сервисы блокированы
*.tcp	SRV ООО
*.udp	SRV ООО
В этом примере демонстрируется применение как аргумента вес (сервис
SSH). так и аргумента приоритет (сервис HTTP). Будут задействованы оба
сервера SSH. причем нагрузка между ними распределяется в соответствии с
производительностью серверов. Резервный сервер HTTP используется только
в том случае, когда основной сервер пе функционирует. Сервис finger не
доступен на данном узле, как и все остальные сервисы, имена которых не
упомянуты явно. Тот факт, что демон finger отсутствует в базе данных DNS. не
означает, что он не выполняется: просто его нельзя найти средствами DNS.
Раньше в базе данных DNS существовала запись WK.S (well-known
services — известные сервисы). Вместо того чтобы переадресовывать запра-
шивающего на узел, который предоставляет указанный сервис в рамках
домена, она содержала список всех сервисов, поддерживаемых заданным
узлом. Эта запись является практически бесполезной и. к тому же, считается
рискованной с точки зрения безопасности, поэтому она не получила
рас п ростране ния
472
Чость 11 Роботе в сетях
Компания Microsoft использует в Windows 2000 стандартные записи SRV.
но способ их внедрения в базу данных DNS является нестандартным и
несовместимым с документацией.
Записи TXT
Запись TXT добавляет в базу данных DNS произвольный текст. Например,
в нашей базе данных имеется следующая запись, идентифицирующая naury
организацию:
IN	TXT "University of CO, Boulder Campus. CS Dept“
Эта запись непосредственно следует за записями SOA и NS зоны “cs.colo-
rado.edu.”. наследуя таким образом от них поле имя.
Записи ТХТ нс пользуются также в сочетании с записью RP. которая
содержит контактную информацию для связи с человеком, отвечающим за
функционирование узла (в записи SOA указан лишь его электронный адрес).
Запись ТХТ имеет такой формат:
имя [ccl] IN TXT информация ...
Все информационные элементы должны быть заключены в кавычки. Это
может быть как одна строка, так и несколько строк, каждая из которых
заключена в кавычки. Будьте предельно внимательны — пропущенная
закрывающая кавычка может привести к разрушению базы данных DNS.
У записей ТХТ нет внутреннего порядка. Следовательно, не стоит
пытаться добавить в базу данных единый информационный блок, представ-
ленный в виде нескольких записей ТХТ: в ответ на запрос демон named
может возвращать их в произвольном порядке.
Записи ресурсов IPv6
IPv6 — это новая версия протокола IP. Процесс принятия спецификации
длится уже более десяти лет. Своим появлением протокол IPv6 обязан
существовавшей в то время острой потребности в дополнительных IP-адресах.
Однако решения этой проблемы, считавшиеся временными, — протокол
CIDR, система NAT и строгий административный контроль над адресным
пространством — оказались столь успешными, что массовый переход к
стандарту IPv6 вряд ли произойдет в скором будущем. Если не появится
какое-нибудь суперпогтулярное приложение, работающее только с IPv6 (нли
компания Microsoft не сделает этот протокол стандартным в Windows), то в
ближайшие несколько лет системные администраторы не захотят иметь дело
с иным форматом адресов Ряд аналитиков полагает, что чаша весов склонится
в пользу IPv6 благодаря новому поколению мобильных телефонов, имеющих
1Р-адрсса.
Хотя мы не ожидаем широкого распространения протокола IPv6, будет
все же полезно описать влияние 128-разрядных IP-адресов на DNS.
Изменению подвергнутся записи А и PTR, но это относительно простые
перемены в сравнении с задачей внедрения совершенно новой концепции:
совместного владения адресами.
Сетевой плате, которой соответствует адрес IPv6, принадлежит лишь
несколько битов адреса, но не все они. Другие биты делегируются выше-
стоящим провайдерам н попытке сделать перенумерацию и смену провайдера
простой задачей Однако реализация этого механизма довольно сложна.
Гпово 16, Системе доменных имен
473
В IPv6 эквивалент записи А первоначально назывался АААА, поскольку
адреса IPv6 в четыре раза длиннее, чем простые IP-адреса. Когда появилась
схема разделенного управления адресами, организация 1ETF стандартизиро-
вала два новых типа записей: А6 (для перевода имен компьютеров в адреса)
и DNaME (для передачи частей адреса другим организациям). Прототипом
для записи DNAME послужила запись CNAME, с помощью которой, как
было показано выше, обеспечивалась поддержка сетевых масок, не проходя-
щих по границе байтов. Запись А6 задает адрес, но при этом учитывается,
что часть старших битов должна быть получена из другого источника.
Мы не будем подробно рассматривать механизмы поиска имен в IPv6,
поскольку они еше недостаточно четко определены организацией IETF, да
и у нас ие очень большой опыт работы с ними. В следующих двух разделах
излагается лишь суть этой совершенно новой методики.
Записи Аб
Формат записи Аб таков:
имя_узла I ttl] IN Аб число_отложенньос битов IP-адрес ссылка
Например:
anchor	IN Аб 0	3ffe:8050:201:9:аОО:20ff:fe81:2Ь32.
anchor	IN Аб 48 ::9:а00:20ff:feBL:2Ь32 prefix.myisp.net.
Обе записи задают одни и тот же адрес IPv6 для узла anchor. В первом
случае адрес полностью определен, а во втором — 48 префиксных битов
делегируются узлу prerix.myisp.net. Обратите внимание на то, что в первой
записи в качестве ссылочного аргумента указана точка. Она означает, что
никаких дальнейших ссылок не требуется.
Модулю распознавания может потребоваться обратиться ко многим
серверам имен, чтобы собрать полный 128-разрядный адрес по цепочке
записей Аб. Например, во второй из показанных выше записей на следующем
уровне могут оказаться отложенными 47 битов, далее — 46 и тд. Для
получения ответов придется сделать 48 запросов. Добавьте эквивалентное
число запросов DNSSEC, требуемых для проверки каждого компонента
адреса, и получится 100-кратное увеличение DNS-трафика при распознавании
одного единственного имени! Как видите, официальные спецификации не
всегда просты и эффективны.
На практике из сорока восьми возможных уровней переадресации
останутся два или три, но сама концепция открывает интересное поле для
атак вида “отказ от обслуживания”. Более подробная (и менее предвзятая)
документация содержится в каталоге doc пакета BIND 9.
Записи DNAME
Обратное преобразование адресов IPv6 в доменные имена основано на
использовании традиционных записей PI'R и записей нового типа — DNAME.
Записи PTR связывают локальные биты адреса IPv6 с конкретным сетевым
именем, а записи DNAME определяют, какие из оставшихся частей адреса
каким организациям принадлежат.
В IPv4 зоны обратного преобразования располагались в домене in-
addr.arpa, а зоны прямого преобразования — в других ветвях дерева доменов
(например, в доменах “сот” или “edu”). В IPv6 информация об обратном
474
Чость II Роботе в сетях
преобразовании более рассредоточена. Часть ее находится в домене гпб.агра,
а часть хранится в зонах прямого преобразования.
Компоненты имен в домене in-addr.arpa представляют собой байты
IP-адреса. В IPv6 эта схема обобщена, и компонентам имени разрешается
представлять произвольные части адреса. Такие адресные секции могут быть
длиной от 1 до 128 битов; они известны как битовые строки.
Битовые строки записываются посредством специального синтаксиса.
Рассмотрим его на конкретном примере. Все однонаправленные адреса IPv6
начинаются с трехбитового префикса 001. Чтобы записать этот префикс
языком битовых строк, нужно взять двоичное число 001 и дополнить его
незначащим битом, чтобы длина цепочки была кратна четырем: 0010.
В результате получаем шестнадцатеричную цифру 2; у нее три бита значащих
и один — незначащий. Финальная строка записывается так:
\[х2/3]
Обратная косая черта, квадратные скобки и литера х ограничивают
каждую битовую строку. Содержательная часть строки — это последователь-
ность шестнадцатеричных цифр (в данном случае одна цифра — 2) и
спецификатор длины (/3). Последний указывает, сколько битов, представ-
ленных шестнадцатеричными цифрами, нужно учитывать. Это необязатель-
ный компонент. Если он отсутствует, длина битовой строки вычисляется на
основании количества шестнадцатеричных цифр, умноженного на 4 (в данном
случае длина строки составляет 4 бита).
Даже если битовые строки оканчиваются на границе шестнадцатеричных
цифр, желательно указывать спецификатор длины, иначе читатели DNS-фай-
лов ослепнут, пытаясь подсчитать длину больших строк.
Самые левые биты строки являются наиболее значащими. Дополнитель-
ные биты, присоединяемые к самой правой цифре, просто не учитываются.
Все они должны равняться нулю.
Поскольку все однонаправленные адреса IPv6 имеют общий префикс 001,
самый верхний домен в ветви обратного преобразования — \[х2/3].1р6.асра.
А вот более сложный пример. Ниже записано три разных представления
одного адреса: первый раз — в цельном виде, второй — с разделением на
три части (3/45/80), третий — на четыре (3/13/32/80)*. По мере перераспре-
деления блоков их шестнадцатеричное представление полностью меняется,
хотя в основе остаются те же самые биты. Чтобы получить двоичное
представление чисел, воспользуйтесь утилитой Ьс.
\[x3ffe0O5OO2OlOOO9OaOO2Offfe812b32/128].ipb.arpa.
\(xOOO9OaOO2Offfe812b32/80].\[xfff402801008/45].\[х2/3].хрб.агра.
\[x00090a0020fffe812b32/80].\[x8050C201/32].\(xfffO/13J
.\[x2/3]-ip6.arpa.
Как и в случае зон домена in-addr.arpa в IPv4, отдельные числа читаются
слева направо, а компоненты адреса (блоки, разделенные точками) — справа
налево. Первый компонент второй и третьей из показанных выше строк —
это локальная часть адреса. Он представляет младшие 80 битов адреса и
состоит из шестнадцатеричных цифр 00090a0020fffe812b32. Приведем
еще раз те же самые строки с выделенной локальной частью адреса:
Не упустите из виду тот факт, что адреса IPv6 сами по себе имеют определенную
внутреннюю структуру. В параграфе 13.4 рассказывалось о том, из каких компонентов
состоит адрес IPv6 и что они означают
Глово 16. Системе доменных имен
475
\[x3ffe8050020100090a0020fffe812b32/128J-хрб.агра.
\[xD0090a0020fffefil2b32/B0J.\(xfff402801008/45].\[x2/3).хрб.агра.
\(x00090a0020fffe812b32/80].\[x80500201/32].\[xff£0/13]
-\[x2/3].ip6.arpa.
Спецификатор /45 во второй строке говорит о том. что в шестнадцате-
ричной цепочке fff402801008 45 битов из 48-ми являются значащими.
Очевидно, разработчики стандартов считают, что для иас это развлечение —
вбивать все эти фрагменты в DNS-файлы без ошибок.
Записи DNAME делегируют адресные секции другим серверам имен.
Формат записей имеет следующий вид:
битовая_ строка [ttl] IK DNAME целееой_домен
Идея состоит в том. что разными частями адреса управляют разные
организации. Вам принадлежат 80 битов, вашему провайдеру — собственный
блок, его провайдеру — свой и т.д. Процесс делегирования иллюстрируется
на примере показанных ниже фрагментов. Здесь используется четырехблоко-
вое представление приводившегося выше адреса, при котором цепочка
делегирования проходит от корневого сервера к серверу провайдера и далее
к серверу искомого домена.
В данном примере директивы SORIGIN задают контекст каждой записи.
Эти фрагменты взяты из зонных файлов трех разных организаций: корневого
сервера домена ip6.arpa, сервера my-isp.net и сервера my-domain.com. Таким
образом, они не относятся к единой конфигурации какого-то одного узла.
Корневой сервер домена ip6.arpa — \[x2/3].ip6.arpa — делегирует задан-
ный 13-битовый адрес серверу my-isp.net. для чего в зонный файл включаются
следующие строки:
; передача адресного префикса серверу my-isp.net
SORIGIN \[х2/3].ipo.агра.
\[xfffG/13] IN DNAME ip6.my-isp.net.
При этом создается нечто вроде псевдонима для заданного адреса
\|xffTO/l3I-\[x2/3].ip6.arpa, и этот псевдоним указывает на строку ”ip6.my-
isp.net.”. Провайдер, в свою очередь, передает 32-битовый сегмент адреса
серверу my-domain.com. помещая такие строки в файл своей зоны ip6.my-
isp.net:
; передача адресного префикса серверу my-doraain.net
SORIGIN xp6.my-isp.net.
\fx80500201/321 IN DNAME ip6.my-domain.net.
Здесь формируется имя ,‘\|х80500201/321 >рб my-isp.net.”, которое, раскры-
ваясь из предыдущей записи DNAME, образует 48-битовый префикс адреса
IPv6. Эти 48 битов являются синонимом имени ip6.my-domain.com
В зонных файлах домеиа ip6.my-domain.com посредством записи PTR
устанавливается привязка для оставшейся части адреса:
SORIGIN ip6.my-doraain.net.
\fx00090a0020fffe812b32/80] IN PTR host.ray-aomain.net.
Мы советуем не беспокоиться по поводу делегирования, если у вас один
провайдер и система расположена в одном месте. Просто включите весь
128-разрядиый адрес в файлы зон прямого и обратного преобразования. Если
у провайдера произойдут какие-го изменения, он сообщит о них и несложно
будет самостоятельно отразить их в нескольких файлах.
476
Чость II Робото в сетях
Протокол IPv6 еше относительно молод, по крайней мере с точки зрения
ввода его в эксплуатацию Адресные канцелярии только начинают распреде-
лять адреса. Локальная часть адреса IPv6 никогда не меняется, и это
прекрасно. С другой стороны, большинство организаций так же редко меняет
своего провайдера, поэтому биты, получаемые от провайдера, можно смело
включать в зонные файлы. Напишите небольшой сценарий на Perl, который
поменяет префикс всех адресов, если вы решите перейти к другому
провайдеру.
Команды в файлах зон
Закончив изучение базовых записей о ресурсах, перейдем к знакомству
с командами, которые вставляются в зонный файл для модификации после-
дующих записей. Таких команд четыре:
SORIGIN иыя_домена
SINCLUDE имя_файла
STTL стандартное_значение
§GENERATE аргументы
Команды обязаны начинаться в первой колонке и занимать отдельную
строку.
Когда демои named читает зоииый файл, он добавляет стандартное имя
домена (“источник”) к любому имени, которое не является полностью
определенным. Первоначально источником служит домен, указанный в
соответствующей инструкции zone в файле named.conf. Эту установку можно
изменить в зонном файле посредством директивы SORIGIN.
Использование относительных имен вместо полных позволяет сэкономить
много времени на вводе данных и делает зонные файлы гораздо более
удобными для восприятия. Например, все записи зон обратного преобразо-
вания для сети класса В с группой подсетей могут находиться в одном зонном
файле, где директивы SORIGIN устанавливают контекст каждой подсети
Инструкция вида
SORIGIN 243-138.128.in-addr.arpa
будет предшествовать записям подсети 243.
Во многих организациях в зонные файлы включаются директивы
SINCLUDE, позволяющие разделять зонные базы данных иа логические блоки
или хранить ключи шифрования в отдельном файле с ограниченными правами
доступа. Указанный в директиве файл включается в базу данных в том месте,
где стоит директива.
Директива sttL задает стандартное значение для поля ///записей, идущих
после иее. Раньше это значение можно было определить только в записи
SOA В BIND 8 рекомендуется размешать директиву STTL в начале зонных
файлов. В BIND 9 это обязательное требование, и те файлы, в которых
директива отсутствует, ие будут загружены.
В BIND 9 применяется концепция, известная как согласование времени
жизни: все записи одного типа, принадлежащие одному узлу, должны иметь
одинаковое значение TTL. Используемое значение берется у первой записи,
относящейся к данной паре узел/тип.
Директива SGENERATE, относительно новая конструкция в BIND 8.
позволяет легко создавать наборы похожих записей. В основном она
применяется при работе с записями CNAME в файлах зон обратного
Глово 16. Системе доменных имен
477
преобразования, когда маски подсетей не проходят по границе байтов в
IP-адресе (см. документ RFC2317).
Формат директивы таков.
S GENERATE на чала -конец [/ди.г] левыйарг тип правый_арг I комментарий]
а генерируемые строки будут иметь следующий вид:
левый_арг1 тип правый^арп
Поля начало и конец определяют диапазон значений счетчика цикла. Для
каждого значения в диапазоне создается одна строка. Ссылка на счетчик
цикла в левом и правом аргументах осуществляется посредством метасимво-
ла $. Если задан шаг, счетчик цикла будет изменяться на указанную величину.
Поле тип определяет тип записи. В настоящее время поддерживаются только
записи CNAME, PTR и NS, причем лишь в BIND 8. В BIND 9 эта поддержка,
возможно, появится в будущем. Конкретный пример приводился при описа-
нии специального применения записи CNAME.
Зона locolhast
Адрес 127.0.0.1 обозначает исходный компьютер и должен всегда соот-
ветствовать имени “local host лока?ьлый_г?о.ие«,”. например localhost.cs.colo-
rado.edu. В некоторых организациях данный адрес связывается с именем
•‘localhosi.1*, как будто оно является частью корневого домена; подобная
конфигурация неверна.
Если забыть сконфигурировать зону localhosi, то компьютеры в системе
начнут запрашивать информацию о самих себе у корневых серверов. Послед-
ние в настоящее время принимают так много подобных запросов, что их
администраторы рассматривают вопрос об установлении соответствия между
именем localhost и адресом 127.0.0.1 на верхнем уровне.
Пример правильной конфигурации зоны localhost приведен в парагра-
фе 16.15.
Связующие записи: ссылки между зонами
У каждой зоны свой набор файлов данных, серверов имен и клиентов.
Но зоны должны быть соединены друг с другом, чтобы получалась связная
иерархия К примеру, домен cs.colorado.edu является частью домена colo-
rado.edu. и в DNS должна существовать связь между ними.
Поскольку отсылки всегда возвращаются в направлении от родительских
доменов к дочерним, серверу имен не обязательно знать что-то о доменах
(точнее, зонах), расположенных выше в иерархии DNS. В то же время серверы
родительского домена должны хранить IP-адреса серверов имен всех своих
поддоменов. По сути, в ответ на внешние запросы могут возвращаться
отсылки только к тем серверам имен, которые известны в родительской зоне.
Говоря языком DNS, родительская зона должна содержать записи NS
для каждой делегируемой юны. Но в них указываются доменные имена, а
не IP-адреса, поэтому родительский сервер должен иметь способ как-то
преобразовать эти имена, т.е. либо выполнить обычный DNS-запрос (если
при этом не возникает циклическая зависимость), либо обратиться к
собственным копиям соответствующих записей А. Реализовать это требование
можно двумя путями: хранить все необходимые записи либо использовать
усеченные зоны.
478
Чость II Робота в сетях
В первом случае в базу данных родительской зоны включаются требуемые
записи NS и А. Например, зонный файл домена Colorado edu может содержать
следующие записи:
; информация о поддоменах
cs	IN NS ns.cs.colorado.edu.
IN NS piper.cs.coorado.edu.
IN NS ns.xor.com.
ее	IN NS ns.ee.colorado.edu.
IN NS ns.cs.colorado.edu.
; связующие записи
ns.cs	IN	A
piper.ce	IN	A
ns.ee	IN	A
128.138.243.151
128.138.204.4
128.138.200.1
“Посторонние” записи А называются связующими, так как они в
действительности не принадлежат данной зоне. Они присутствуют лишь для
того, чтобы связать новый домен с деревом имен Internet. Отсутствие или
некорректность связующих записей приведет к тому, что часть адресного
пространства окажется недоступной и пользователи, пытающиеся обратиться
к нему, будут получать сообщения об ошибке "host unknown” (неизвестный
узел).
Распространенной ошибкой является включение связующих записей для
тех доменных имен, которые этого ие требуют. В частности, в показанном
выше примере адрес домеиа ns.xor.com может быть найден путем обычного
DNS-запроса. Запись А для него поначалу будет просто лишней, но
впоследствии окажет “медвежью’* услугу, если адрес домена по какой-то
причине изменится. Правило гласит, что записи А должны включаться только
для узлов, которые находятся в текущем домене или одном из его поддоменов.
Существующие версии BIND игнорируют ненужные связующие записи, а их
присутствие фиксируется в журнальном файле как ошибка.
Описанная схема представляет собой стандартный способ соединения зон
между собой, но она требует, чтобы дочерние зоны держали связь с
родительскими зонами и уведомляли их об изменениях своих серверов имен.
Однако в связи с тем, что такие зоны часто контролируются разными
организациями, это становится утомительным трудом, требующим объедине-
ния усилий нескольких администраторов. Как следствие, в реальной жизни
подобная конфигурация часто оказывается устаревшей.
Второй способ обслуживания межзоиных связей заключается в исполь-
зовании усеченных зон. Они полностью поддерживаются в BIND 8. ио были
также доступны и в BIN D 4 (там о иих говорилось как об экспериментальной
возможности). Усеченная зоиа, по сути, представляет собой то же самое, что
и подчиненная зона, но содержит только записи NS.
Усеченные зоны прекрасно работают в BIND 8, где данные различных
зон смешиваются в памяти, ио в BIND 9 дела обстоят по-другому. В BIND 9
усеченные зоны должны быть одинаково сконфигурированы на главных и
подчиненных серверах родительской зоны, которые сами по себе достаточно
сложно поддерживать в согласованном состоянии. Поэтому лучше всего
просто держать связь с родительским домеиом и проверять его конфигурацию
хотя бы несколько раз в год.
С помощью команды dig можно узнать, какие из ваших серверов в
настоящий момент известны родительскому домену. Сначала введите команду
dig родительский домен пв
Глово 16. Системе доменных имен
479
чтобы узнать серверы имен родительского домена. Выберите один из них и
введите
dig ^сервер имен.родительскии^домен дсчернийдсмен пя
чтобы получить список собственных общедоступных серверов имен.
Усеченные зоны особенно полезны в ситуации, когда внутренняя
адресация зоны основана иа частном адресном пространстве (см. документ
RFC 1918) и необходимо поддерживать синхронизацию с делегированными
зонами. Пример содержится в каталоге /src/conf/recursive дистрибутива
BIND 8.
Следует упомянуть о некоторых особенностях усеченных зон
•	Усеченные зоны не содержат авторитетных копий зонных данных, и
усеченные серверы не должны указываться в записях NS зоны.
•	Поскольку усеченные серверы не упоминаются в записях NS, они не
уведомляются автоматически при изменении зонных данных. Нужно либо
добавить параметр also-notify в конфигурацию главных серверов, либо
просто дождаться истечения периода обновления зоны, указанного в
записи SO А.
•	Теоретически демону named не нужны копии записей NS зоны, если он
не может получить соответствующие записи А. Но он способен сам себя
загрузить, используя IP-адрес главного сервера, содержащийся в файле
named.conf
•	Зачем ограничивать себя записями NS? Почему бы просто не быть
вторичным сервером поддомена? Этот прием тоже работает. Но если ка-
ждый сервер родительского домена будет одновременно сервером дочер-
него домена, то нижестоящие серверы никогда не будут получать отсылок
Серверы родительского домена станут предоставлять поддомену все
функции DNS. Возможно, это именно то. что нужно, а возможно — нет
16.12.	Обновление файлов зон
Когда в домен вносится изменение (например, добавляется или удаляется
компьютер), следует откорректировать файлы данных на главном сервере.
Кроме того, надлежит увеличить порядковый номер в записи SOA для этой
зоны и выполнить команду ndc reload, которая просигнализирует демон}
named о необходимости принять изменения. Можно просто уничтожить и
перезапустить демон (команда ndc restart), но это вызовет уничтожение
кэшированных данных, полученных из друпгх доменов.
В ранних версиях BIND для управления демоном named применялись
сигналы и команда kill, но когда у разработчиков перестало хватать сигналов,
появилась команда ndc. которая исправила ситуацию. Скорее всего, в будущем
сигналы вообше перестанут поддерживаться (за исключением сигнала HUP.
вызывающего повторное чтение конфигурационного файла, и сигнала TERM,
приводящего к выгрузке демона), поэтому рекомендуем пользоваться коман-
дой ndc.
Обновленные зонные данные будут переданы подчиненным серверам
немедленно, поскольку параметр notify включен по умолчанию. Если же
по какой-то причине он был отключен, подчиненным серверам придется
дожидаться, пока истечет период обновления, установленный в записи SOA
зоны (обычно от одного до шести часов). В случае, когда необходима более
срочная корректировка, можно выполнить на подчиненном сервере команду
480
Чость II. Роботе в сетях
ndc reload, которая заставит его связаться с главным сервером, убедиться в
том, что данные изменены, и запросить пересылку зонных данных.
При изменении имени или [P-адреса компьютера ие забывайте модифи-
цировать зоны как прямого, так и обратного преобразования, Если забыть о
файлах, в которых хранятся данные для обратного преобразования, это
приведет к появлению скрытых ошибок: некоторые комаллы будут работать,
а некоторые — нет.
Если изменить файлы данных, но не обновить порядковый иомер в
записи SOA. то изменения вступят в силу только иа главном сервере (после
перезагрузки), но ие на подчиненных.
Не следует редактировать файлы данных, относящиеся к подчиненным
серверам. Эти файлы ведет сам демон named; системные адмииистраторы не
должны вмешиваться в его работу. Лучше всего только просматривать файлы
данных, не делая в них никаких изменений. По этим файлам часто можно
обнаружить скрытые ошибки конфигурации. Например, досадный пропуск
точки, который можно запросто не заметить в файлах конфигурации главного
сервера, может привести к появлению в файле данных подчиненного сервера
явно ложного элемента наподобие
fоо.cs.Colorado.edu.cs.Colorado.edu
Документ RFC2136 разрешает производить зонные изменения через
библиотеку АР!-функций. Эта возможность называется динамическим обнов-
лением; оио необходимо для протоколов автоматического конфигурирования,
таких как DHCP. О том, как работает данный механизм, речь пойдет чуть
ниже.
Зонные пересылки
Сер верь! DNS синхронизируются посредством механизма зонных пере-
сылок. В исходной спецификации DNS (и в BIND 4) требовалось, чтобы все
данные, относящиеся к той или иной зоне, пересылались одновременно.
Инкрементные обновления были определены в документе RFC 1995 и
реализованы в BIND 8.2.
Подчиненный сервер, который хочет обновить свои данные, запрашивает
зонную пересылку с главного сервера и создает резервную копию данных иа
диске. Если данные на главном сервере не изменились, что можно определить
путем сравнения порядковых номеров (не самих даиных), корректировка не
производится и резервные копии файлов практически остаются без изменении
(лишь время их модификации устанавливается равным текущему времени).
Зонные пересылки осуществляются по протоколу TCP через порт 53.
Соответствующее событие регистрируется системой Syslog с пометкой ‘‘named-
xfer”. Организация IETF определила, что инкрементные обновления могут
производиться либо по протоколу TCP. либо UDP. но в BIND реализован
лишь первый вариант
Во время зонной пересылки и передающий, и принимающий серверы
остаются доступными для запросов. Подчиненный сервер начинает исполь-
зовать новые данные только после завершения всей операции. В BIND 8
пересылка осуществляется путем вызова отдельной программы named-xfer, а
в BIND 9 демон named управляет дайной операцией напрямую. Как следствие,
параметр named-xfer, определявший путь к одноименной программе,
перестал поддерживаться в конфигурационном файле BIND 9.
Глово 16. Системо доменных имен
481
Если зона очень велика (например, ‘ сот”) или обновляется динамически
(см. следующий раздел), объем изменений обычно мал в сравнении с
размером всей зоны. В этом случае используются инкрементные обновления,
при которых пересылаются только изменения (в том случае, когда изменения
превышают размер зоны, производится обычная зонная пересылка). Этот
механизм напоминает программу patch: старая база данных сравнивается и
синхронизируется с новой.
В BIND 8 для включения инкрементных зонных пересылок следует
указать демону named на необходимость ведения журнала транзакции (это
делается в глобальной секции options), а затем установить соответствую шип
атрибут в инструкции server любого сервера, которому нужны такие
пересылки. Конфигурационные строки выглядят так:
maintaln-ixfr-base true;	Я в секции options
support-ixfг true;	# в инструкции server
Если требуется изменить стандартные имена журнала транзакций и
временного файла, используемого при инкрементных пересылках, разместите
в инструкции zone следующие директивы:
ixfr-base "иияфайла";	# в инструкции zone
ixfr-tmp-file "имя фаЛла"; # в инструкции zone
В BIND 9 инкрементные пересылки поддерживаются по умолчанию для
любой зоны, сконфигурированной на прием динамических обновлений, а
демон named самостоятельно ведет журнал транзакций. В инструкции server
теперь поддерживаются две отдельные директивы: provide-ixfr и > -
quest-ixfr. Первая включает или отключает механизм инкрементных
пересылок для зои, в которых сервер является главным. Вторая делает то же
самое для тех зон, где сервер является подчиненным
provide-ixfг yes;	# в инструкции server
request-ixfг yes;	I в инструкции server
Пакет BIND не работает с зонами, которые одновременно могут
обновляться динамически и редактироваться вручную. Сервер BIND 9 может
инициировать инкрементную пересылку в результате динамического обнов-
ления или другой поступившей пересылки, но не тогда, когда изменения
вызваны редактированием зонных файлов. Вероятно, эта возможность
появится в следующих версиях пакета.
Было проделано много работы, чтобы в случае краха сервера во время
инкрементной пересылки зонные даиные ие превращались в мусор. Запрос
иа инкрементную пересылку к серверу, который не поддерживает данный
механизм, будет автоматически преобразован в обычный запрос иа обновление.
Динамические обновления
Система DNS основана на предпосылке, что соответствия между именами
и адресами относительно стабильны н меняются нечасто. Но это npaiuvin
постоянно нарушается, если в организации используется протокол DHCP и
при подключении к сети компьютеру динамически назначается IP-aapcc
Имеется два классических решения: добавить обобщенные записи в &ву
данных DNS или непрерывно редактировать DNS-файлы. В большинстве слу-
чаев ни одно из решений не является удовлетворительным.
482
Чость II. Робото В 1ШЯ>
Первое решение должно быть знакомо каждому, кто имеет удаленный
доступ к Internet. Конфигурация DNS в этом случае выглядит примерно
следующим образом:
dhcp-hostl.domain.	IN А	192.16В.0.1
dhcp-host2.domain.	IN A	192.166.0.2
Это простое решение, но оно означает, что указанные имена постоянно
связаны с данными IP-алресами, а компьютер, получающий новый адрес,
меняет имя В такой среде трудно соблюдать требования безопасности, да и
просто регистрироваться в системе под определенным именем.
Механизм динамических обновлений, появившийся в последних версиях
BIND, предлагает альтернативное решение. Он позволяет демону DHCP
уведомлять сервер BIND о сделанных адресных назначениях, обновляя таким
образом содержимое базы данных DNS “иа лету". Имеется также интерфейс
командной строки, дающий возможность выполнять динамические обновле-
ния вручную.
Посредством данного механизма можно добавлять, удалять и модифици-
ровать записи о ресурсах. Глубина обновлений — зона. Немного страшно
разрешать динамические обновления всей базы данных DNS, поэтому многие
организации создают поддомен (скажем. сИзср.орга/шзацыя) и осуществляют
динамические обновления только в его пределах.
Динамические обновления зоны разрешаются в файле named.conf посред-
ством директивы al low-update. После того как зона была динамически
обновлена, ее нельзя редактировать вручную — нужно сначала остановить
сервер BIND, чтобы текущая копия базы данных была записана на диск.
Затем можно отредактировать зонный файл и перезапустить демон earned.
Естественно, исходное форматирование зонного файла будет разрушено (он
будет выглядеть как файл, который ведется демоном named на подчиненных
серверах)
Инкрементные зонные пересылки по умолчанию поддерживаются для
зон, в которых используются'динамические обновления. Но через механизм
инкрементных пересылок не распространяются изменения зоны, осуществ-
ляемые посредством ручного редактирования главного файла, даже если
остановить демон named, отредактировать зонный файл и затем перезапустить
демон.
16.13.	Вопросы безопасности
DNS по своей сути — открытая система. Именно такой — открытой —
она вышла в свет, но в процессе своего развития приобретала все больше
средств зашиты или. по крайней мере, становилась более защищенной. По
умолчанию каждый, у кого есть доступ в Internet, может исследовать чужой
домен отдельными запросами с помощью таких утилит, как dig, host или
nslookup. В некоторых случаях можно получить дамп всей базы данных DNS.
Для устранения этих недостатков в последние версии BIND были введены
различные средства управления доступом, основанные на проверке адресов
или криптографической аутентификации. В табл. 16.10 перечислены элементы
подсистемы безопасности, которые настраиваются в файле named.conf.
Глово 16. Системе доменных имен
483
Таблица 16.10. Средство зощиты в файле nomed.conf
Средство	Инструкции	Что определяет
allow-cruery	options, zone	Кто может посылать запросы зоне или серверу
allow-transEer	options, zone	Кто может запрашивать зонные пересылки
alicw-update	zone	Кто может делать динамические обновления
blackhole	options	Какие серверы нужно полностью игнориро- вать
bogus	server	Какие серверы никогда нельзя опрашивать
acl	various	Списки управления доступом
Демон named может функционировать в среде, где корневой каталог
изменен с помощью команды chroot. и при этом иметь непривилегированный
идентификатор пользователя Таким образом, устраняется малейшая вероят-
ность разрушений, вызванных неконтролируемыми действиями со стороны
суперпользователя. Благодаря сигнатурам транзакций демон способен кон-
тролировать динамические обновления И конечно же. он полностью
поддерживает спецификацию DNSSFC Обо всем этом речь пойдет в
следующих разделах.
Еще роз о списках управления доступом
Список управления доступом — это именованный список соответствия
адресов, который может служить аргументом различных директив, в частност и
al low-query, allow-transfer и blackhole. Они позволяют справляться
с такими нарушениями зашиты DNS. как имитация доменного имени и атаки
вида "отказ от обслуживания”. Синтаксис списков был рассмотрен при
описании инструкции ас! в параграфе 16.9.
В каждой организации должен существовать по крайней мере один такой
список для недоступных адресов и один — для локальных. Например:
acl nogusnets t
0.0.0.С/8;
169.254.0.0/16;
192.0.2.0/24;
224.0.0.0/3;
10.0.0.0/8;
172.16.0.0/8;
192.168.0.0/16;
acl cunets {
128.138.0.0/16;
198.11.16/24;
204.228.69/24;
// список недоступных и фиктивных сетей
// адреса с подстановочными знаками
// канально-локальные делегируемые адреса
// тестовые адреса, наподобие example.com
// пространство групповых адресов
// частное адресное пространство (RFC1918)
// частное адресное пространство (RFC1918)
// частное адресное пространство (RFC1918)
Il список сетей университета штата Колорадо
// основная кампусная сеть
• Каиалъио-локальные адреса используются компьютерами Macintosh и персональными
компьютерами, которые должны работать по протоколу LP. но пе могут найти сервер DHCP.
В этом случае они просто назначают себе адрес из сети 169.254.0.0/16. Адреса в данном
диапазоне должны жестко фильтроваться, чтобы несущие их пакеты никогда ие смогли
выйти за пределы локальной кабельной системы. Кабельные и DSL-модемы также начина-
ют пользоваться этим адресным диапазоном.
*" Не делайте частные адреса недоступными, если они используются для конфигурирования
внутренних DNS-серверов!
484
Чость II Робото в сетчз
Далее нужно в глобальной секции options конфигурационного файла
разместить следующие директивы:
allow-recursion { cunets; } ,•
blackhole г bogusnets; );
Также желательно ограничить зонные пересылки только легитимными
подчиненными серверами. Это достигается с помощью приведенных ниже
списков:
acl ourslaves {
128.13В.242.1;	' anchor
ь-
acl measurements {
128.9.160.157;	II	проект	Билла	Маннинга
196.32.4.0/24;	//	проект	Билла	Маннинга
192.5.5.0/24;	//	проект	Марка	Лотторза
Собственно ограничение реализуется такой строкой:
allow-transfer i ourslaves; measurements; >;
Пересылки разрешены только нашим подчиненным серверам, а также
компьютерам двух глобальных* исследовательских проектов, которые посвяшены
определению размеров сети Imernet и процента неправильно сконфигуриро-
ванных серверов Подобное ограничение лишает остальных пользователей
возможности получать дамп всей базы данных посредством утилиты nslookup.
dig или host.
Например:
% nslookup
Default Server: мы сервера
Address: IP-адрес сервера
> Is cs.Colorado.edu.
[имя сервера।
ж'*" Can't List domain cs.co.orado.ed..: Unspecified error
По-прежнему нужно защищать сеть на более низком уровне с помошыо
списков управления доступом на маршрутизаторе и стандартных средств
зашиты на каждом узле. Если такой возможности нет. ограничьте, график
DNS-пакетов шлюзовой машиной, которая находится под постоянным
адми 11 ист рати вны м контролем
Ограничение возможностей демона named
Чтобы предотвратить ущерб. который может быть нанесен в случае атаки
на сервер, можно запустить демон named в среде с измененным корневым
каталогом и шли от имени непривилегированного пользователя. Флаг -I задает
корневой каталог для демона, а флаги -u п -g — значения LID И GID.
присваиваемые процессу named. Последний из перечисленных флагов не
поддерживается в BIND 9. К примеру, команды
I named -и 53 -д 53 -t /var/named	* BIND В ’/
* named -и 53 -t /var/named	' BIND 9 ’
Глово 16. Системе доменных имен
485
запускают демон с идентификатором пользователя 53. идентификатором
группы 53 (только в BIND 8) и корневым каталогом /var/named.
Новый корневой каталог не может быть пустым, так как он должен
содержать все файлы, необходимые для нормальной работы демона named:
/dev/null библиотеки совместно используемых функций, зонные файлы,
named.conf и т.д. Если скомпилировать демон так, чтобы библиотеки
компоновались статически, то не придется думать, какие библиотечные файлы
копировать в каталог /var/named
Хакер, взломавший демон named, получает доступ к системе от имени
того пользователя, который осуществил запуск демона. Если это пользователь
root и корневой каталог не был изменен, последствия могут оказаться
разрушительными. Многие администраторы не заботятся об использовании
флагов -и. -g и -t, но в таком случае они должны быстрее ставить “заплаты",
чем хакеры будут атаковать систему в случае обнаружения очередной “дыры’’.
Безопасные межсерверные взаимодействия
посредством спецификаций TSIG и TKEY
Пока спецификация DNSSEC (описана в следующем разделе) находилась
в стадии принятия, организация IETF разработала более простой механизм,
названный TSIG (RFC2845). Он позволял организовывать безопасное взаи-
модействие серверов благодаря использованию сигнатур транзакций. Кон-
троль доступа, основанный на таких сигнатурах, надежнее, чем контроль на
основании исходных IP-адресов.
В сигнатурах транзакций применяется симметричная схема шифрования,
т.е. ключ шифрования тот же. что и ключ дешифрования. Такой ключ
называется совместным секретным ключом. Для каждой пары серверов, кото-
рые хотят организовать защищенный канал взаимодействия, должен исполь-
зоваться другой ключ. Спецификация TSIG гораздо менее затратна в
вычислительном плане, чем шифрование с открытым ключом, но она
подходит только для локальной сети, где число пар взаимодействующих друг
с другом серверов невелико. На глобальную сеть эта спецификация не
распространяется.
Сигнатурами TSIG подписываются DNS-запросы и ответы на них. Они
передаются только между серверами, но не между сервером и распознавате-
лем. Сигнатура проверяется в момент поступления пакета и тут же
отбрасывается; она не сохраняется в кэше и не становится частью базы
данных DNS. Спецификация TSIG допускает применение различных методов
шифрования, но в BIND реализован лишь один из них: алгоритм НМАС-
MD5.
Утилита dnssec-keygen', являющаяся частью пакета BIND, генерирует
ключ для пары серверов. Например, если имеются два сервера, сере! и сервЗ.
команда
# dnaaec-kaygen -Н 12В -h -п серв1-серв2
создаст 128-разрядный ключ и сохранит его в файле Ксе/>«/-сер<?2+-157+00000.рп-
vate. В этом файле содержится строка “Key:”, за которой следует собственно
ключ, закодированный по основанию 64.
Сгенерированный ключ представляет собой всего лишь длинное случай-
ное число. Создать ключ можно вручную, записав ASCII-строку нужной
В BIND 8 она называется dnskeygen.
486
Чость II. Робото в сетях
длины и притворившись, что она закодирована по основанию 64. Можно
также воспользоваться утилитой mmencode для кодирования произвольной
строки. Способ создания ключа не важен; главное, чтобы он существовал иа
обеих машинах.
Скопируйте ключ на оба сервера посредством команды асрлибо вырежьте
и вставьте его в нужном месте. Не используйте программы telnet и ftp для
копирования ключа: даже внутренние сети могут быть небезопасными Ключ
должен присутствовать в файле named.conf на обеих машинах. В связи с тем,
что этот файл является общедоступным, а ключ — нет, поместите ключ в
отдельный файл, который будет подключаться к файлу named.conf посредством
инструкции include.
Команда scp является частью пакета SSH; см. параграф 21.8.
Например, можно создать файл scrvl-serv2.key и включить в него такой
фрагмент:
key servl-serv2 {
algorithm hmac-md5;
secret ПсгенерироввнныИ_клч^';
ь-
Режим доступа к файлу должен быть 600, а идентификатор его
владельца — таким же. как и у демона named. В файл named.conf, ближе к
началу, нужно добавить следующую строку:
include "servl-servZ.key";
На данном этапе был лишь определен сам ключ. Чтобы его можно было
использовать для подписи и проверки обновлений, следует заставить каждый
сервер идентифицировать другую сторону посредством директивы keys. Для
этого необходимо в файл named.conf первого сервера включить строки
server адрес серв2 f
keys { servl-serv2; );
и аналогично в файл named.conf второго сервера — такие строки:
server адрес_серв1 {
keys { servl-serv2; );
1;
Любые предложения allow-query, allow-transfer и allow-update
в инструкции zone также должны ссылаться на ключ, например:
allow-transfer ( key servl-serv2; I;
Если вы впервые имеете дело с сигнатурами транзакций, запустите демон
aamed на какое-то время на уровне отладки 1 (о режиме отладки рассказы-
вается в параграфе 16.14) и посмотрите, не будут ли выданы сообщения об
ошибках. Старые версии пакета BIND не понимают подписанных сообщений
и генерируют сообщения об ошибках, иногда даже отказываясь загружать
зонные данные.
TKEY — это механизм в BIN D 9. позволяющий двум узлам автоматически
генерировать совместный секретный ключ без телефонных звонков и
удаленного копирования ключа. При этом используется алгоритм обмена
ключами Диффи-Хеллмана, в котором каждая сторона создает случайное
Глово 16. Системе доменных имен
4В7
число, выполняет над ним определенные математические операции и
посылает результат противоположной стороне. Полученное число заданным
образом объединяется с имеющимся, и получается один и тот же ключ.
Человек, прослушивающий линию, будет тать о содержании сеанса, но не
сможет выполнить обратные математические преобразования".
Технология DNSSEC
DNSSEC — это набор расширений DNS. позволяющих аутентифициро-
вать источник происхождения зонных данных и проверить их целостность,
используя шифрование с открытым ключом Таким образом, DNSSEC дает
возможность DNS-клиентам задавать вопросы вида "Действительно ли зонные
данные поступили от владельца зоны?" и "Те ли это данные, которые послал
владелец?”.
DNSSEC предлагает три разных сервиса: распределение ключей посред-
ством записей KEY, хранящихся в зонных файлах, проверка подлинности
серверов и данных, а также проверка целостности зонных данных. Система
основана на цепочке доверия: корневые серверы предоставляют подтверждаю-
щую информацию для доменов верхнего уровня, те — для доменов второго
уровня и т.д.
В системах шифрования с открытым ключом имеется два ключа: один
шифрует (подписывает) сообщение, а другой дешифрует (проверяет) его
Опубликованные данные подписываются секретным "личным” ключом
Любой может проверить правильность сигнатуры с помощью "открытого''
ключа, который свободно распространяется. Если открытый ключ правильно
расшифровал зонный файл, значит, зона была зашифрована соответствующим
личным ключом. Суть в том, чтобы убедиться в подлинности открытого
ключа, используемого для проверки. Подобные системы шифрования позво-
ляют одной из сторон поставить свою “подпись” на открытом ключе,
передаваемом другой стороне, гарантируя таким образом легитимность ключа.
Отсюда термин “цепочка доверия’’
Данные, составляющие зону, чересчур велики для шифрования с
открытым ключом: процесс шифрования получится слишком медленным
Вместо этого, поскольку данные сами по себе нс секретны, над ними
выполняется хэш-кодирование (к пример}, используется контрольная сумма
MD5), а результат подписывается (шифруется) секретным ключом зоны.
Полученный зашифрованный хэш-код называется цифровой подписью или
сигнатурой.
Цифровые подписи обычно присоединяются к данным, подлинность
которых они устанавливают. Для проверки сигнатуры ее нужно дешифровать
открытым ключом подписавшего, прогнать данные через гот же алгоритм
хэш-кодирования и сравнить вычисленный хэш-код с расшифрованным.
В случае совпадения подписавшее лицо считается аутентифицированным, а
данные — целостными.
В DNSSEC каждая зона имеет свои открытые н секретные ключи
Секретным ключом подписывается каждый набор ресурсов (т.е. всякий набор
записей одного типа, относящихся к одному уълу). Открытый ключ исполь-
зуется для проверки сигнатур и включается в зонную базу данных в виде
записи KEY.
В основе методики лежи г тог факт, что в модульной арифметике возведение в степень —
легкая операция, а найти логарифм, чтобы определить степень, почти невозможно.
4tP
Чость II. Роботе в сетях
Родительские юны подписывают открытые ключи своих дочерних зон.
Демон named проверяет подлинность записи КЕ) дочерней зоны, сравнивая
ее с сигнатурой родительской зоны. Для проверки подлинности последней
демон обращается к родительской зоне более высокого уровня и т.д. вплоть
до корневой зоны. Ее открытый ключ имеется в файле корневых “подсказок ’.
Для создания и использования подписанных зон требуется пройти
несколько этапов. Сначала нужно сгенерировать пару ключей для зоны. Это
делается с помощью такой команды в BIND 9;
t dnssec-keygen -a DSA -h 768 -n ZONE mydomain.com.
или в BIND 8
8 dnskeygen -D768 -z -n mydomain.com.
В табл. 16 II описано назначение аргументов этих команд.
Тоблицо 16.11. Описоние оргументов комонд dnssec-keygen и dnskeygen
Аргумент Нозночение
Для dnssec-keygen
-а	DSA	Использование алгоритма DSA
-о	768	Создание 768-6|гговой пары ключей
-л	ZONE my Goma in. coir.	Создание ключей для зоны rnydomain.com
Для dnskeygen
-D7 68	Использование алгоритма DSA с 768-разршшым ключом
Создание ключа зоны
-п myconiaxn.com.Создание ключей для зоны mydomain.com______________
Команды dnssec-keygen и dnskeygen возвращают следующий результат:
alg 003
key identifier 11342
flags — 16641
Они также создают файлы, содержащие открыты]'! и секретный ключи:
Kmydomaln.сот.+003+12345.key	ft открытый ключ
Kmydomaln.com.+003+12345.private	« секретный ключ
Файл открытого ключа обычно включается в зонный файл с помошыо
директивы S INCLUDE. Чаще всего он идет сразу же после записи SOA.
Тсхнолозия DNSSEC основана на принципе пеночки доверия, те
открытый ключ зоны должен быть подписан ее родительской зоной, чтобы
считаться гарантированно надежным. В BIND 8 нет механизма, который
заставил бы родительскую зону подписать ключ дочерней зоны; единственный
выход — взаимодействие администраторов. В BIND 9 имеется программа
dnssec-makekeysei. упрощающая этот процесс.
Программа dnssec-makekeyset упаковывает ключи, которые нужно подпи-
сать (это могут быть не только зонные ключи). устанавливает значение ITL
для полученного набора, задает период действия сигнатуры, а затем посылает
пакет в родительскую зону на подпись. Например, команда
* dnssac-makekeysat -t 3600 -в +864000
Kmydomain.com.+003+12345
Гповс 16 Системе доменных имен
489
упаковывает открытый ключ зоны, который был сгенерирован выше,
устанавливает время жизни пакета равным 3600 с (один час), а срок действия
родительской сигнатуры — 10 дней начиная с текущего момента. Про1рамма
dnssec- makekeyset создает один выходной файл, my domain, com. key set. Его
нужно послать в родительскую зону на подпись. Он содержит открытый ключ
и сигнатуры, созданные самими зонными ключами, чтобы родительская зона
могла проверить открытый ключ дочерней зоны.
В BIND 9 родительская зона использует программу dnssec-signkey для
подписи упакованного набора ключей:
#	dnssec-aignkey mydomain. сот .keyset Ксот.+003+56789
Эта команда создает файл mydonain.com.signedkcy, который родительская
зона (“сот”) возвращает дочерней зоне (rnydomain.com) для включения в ее
зонные файлы. В BIND 8 этой же цели служит программа dnssigner.
Получив родительскую сигнатуру, можно начать подписывать реальные
зонные данные. Этот процесс происходит следующим образом: берется
зонный файл и после каждого набора записей о ресурсах ставятся записи
S1G и NXT Первые содержат реальные сигнатуры, а вторые обеспечивают
подпись отрицательных ответов.
В BIND 8 цифровые подписи ставятся посредством программы dnssigner.
расположенной в каталоге contrib дистрибутива. В BIND 9 для этого
используется программа dnssec-signzone. Например, команды
i dnssigner -or mydomsin.com -zi db.mydomain -zo
db. my dome in . signed -kl mydomain.com dsa 12345 -st it BIND В
# dnssec-signzone -o mydomain.com db.mydomain	# BIND Q
читают зонный файл db.mydomain и создают подписанную версию зонного
файла, называемую db. my do main.signed. Первая из команд отображает также
статистическую информацию о процессе простановки подписи (запрашива-
ется параметром -st). В частности, сообщается, сколько времени заняло
подписание, и показывается, какие записи были добавлены или удалены.
Запись SIG содержит много информации:
•	тип подписываемой записи;
•	используемый алгоритм (в данном случае — DSA);
•	значение TTL для подписанного набора записей;
•	срок действия сигнатуры (в формате ггггММддччсссс);
•	время простановки подписи (также в формате ггггМ Мддччсссс);
•	идентификатор ключа (в данном случае — 12345),
•	имя подписывающего (mydomain.com.);
•	наконец, сама цифровая подпись.
Чтобы можно было работать с подписанной зоной, найдите в файле
named.солГзону mydomain.com и измените в инструкции zone параметр file
так. чтобы он указывал на файл dh.mydomain.signed, а не db.mydomain.
В BIND 8 нужно также включить в инструкцию zone предложение pubkeys.
Дело в том, что сервер BINDS проверяет зонные данные по мере их загрузки,
поэтому он должен знать ключ заранее В BIND 9 такая проверка отсутствует:
сервер берет открытый ключ из записи KEY зоны и не требует никаких
других настроек.
Цифровые подписи прекрасно подходят для положительных ответов
следующего вида: “Вот IP-адрес узла anchor.cs.colorado.edu, а вот сигнатура.
4'zU
Чость II. Робото в сетях
доказывающая, что данные действительно поступили из домена cs.coiorado.edu
и эти данные корректны". Но что делать с отрицательными ответами
наподобие "Нет такого узла”? При таких ответах обычно не возвращаются
подписанные записи.
В DNSSEC проблема решается за счет записей NXT, в которых
указывается следующая запись зоны, отсортированной в каноническом
порядке*. Например, если после записи anchor.cs.colorado.edu идет запись
awesome.cs.colorado.edu и поступает запрос к узлу auihill.cs.colorado.edu, в
ответ будет получена запись NXT следующего вида;
anchDr.cs.colorado.edu. IN NXT awesome.cs.colorado.edu A MX NXT
Она говорит о том; что сразу после имени "anchor” в зоне cs.colorado.edu
следует имя “awesome”, а имени "anchor” соответствует как минимум одна
запись А, MX и NXT. Последняя запись NXT в зоне ссылается на первый
узел. К примеру, запись NXT для имени zamboni.cs.colorado.edu ссылается
на первую запись, т.е. на сам домен cs.colorado.edu:
zambonl.c3.colorado.edu. IN NXT cs.colorado.edu A MX NXT
Запись NXT возвращается также в том случае, если узел существует, ио
запись запрашиваемого типа отсутствует. Если, скажем, запрос производится
к записи LOC узла anchor, будет выдана та же самая запись NXT, что и
показана выше, но в ней будут отображены только записи А, MX и NXT
Изложенный здесь материал касается реализации DNSSEC в BIND 9.0.0
(июль 2000). В пакет непрерывно вносятся значительные изменения, поэтому
информация вряд ли будет оставаться корректной в течение долгого времени.
Как всегда, точные детали можно узнать в справочных руководствах и
документации к пакету BIND. Помня об этом, рассмотрим, какие потенци-
альные проблемы могут возникать в текущей, реализации DNSSEC.
Спецификация DNSSEC не согласуется с понятиями кэширования и
переадресации. В ней предполагается, что запрос сначала адресуется корневой
зоне, а затем следует за отсылками вниз по дереву доменов в поисках ответа.
Каждая подписанная зона в свою очередь подписывает ключи своих дочерних
зон, и эта цепочка доверия надежна и нерушима. Если же в системе имеется
переадресуюший сервер, то первоначальный запрос попадает к нему, а не в
корневую зону. Кэширующий сервер, посылающий запросы через переадре-
сующий сервер, будет перепроверять сигнатуры, поэтому ответы будут
гарантированно надежными Но чтобы запрос имел успех, переадресующий
сервер должен уметь возвращать все записи SIG и NXT, требуемые для
проверки сигнатур. Серверы, не поддерживающие спецификацию DNSSEC,
не умеют этого делать, и в документах RFC ничего не говорится о проблеме
переадресации.
В BIND 9 реализован ряд дополнительных механизмов помимо тех.
которые определены документом RFC2535. поэтому кэширующий сервер
BIND 9 способен работать по протоколу DNSSEC через переадресующий
сервер BIND 9. Таким образом, для одновременного использования прото-
кола DNSSEC и переадресуюшего сервера во всей системе должен быть
установлен пакет BIND 9
Это разновидность алфавитного порядка, при котором имена, стоящие выше в иерархии
DNS. указываются первыми. Например, в зоне cs.colorado.edu имя cs.colorado.cdu следует
перед любым именем узелcs.colorado.edu. В рамках одного уровня иерархии порядок
сортировки — алфавитный.
Глово 16 Системе доменных имен
491
Технология DNSSEC основана иа существовании инфраструктуры откры-
тых ключей, которая на практике еше не реализована. Нет четкого способа
заставить родительскую зону подписать ключи дочерней зоны; нельзя послать
письмо по адресу hostname@com и получить в ответ подписанные ключи.
Широкое распространение технология DNSSEC. вероятно, получит в бли-
жайшие несколько лет. Сначала, очевидно, появятся подписанные версии
корневых зон.
Сигнатуры транзакций (технологии TSIG/TKEY) требуют меньше про-
цессорного времени и меньшую полосу пропускания, чем системы аутенти-
фикации с открытым ключом. Но они гарантируют подлинность лишь
отправителя, а не самих данных. Было бы неплохо взаимодействовать по
технологии TSIG с сервером, реализующим протокол DNSSEC, однако
невозможно установить подобные отношения с каждым сервером, так как
технология TSIG требует ручной настройки DNS-файлов
Microsoft — плохо, UNIX — хорошо
В Windows 2000 записи SRV используются для нахождения всего: серверов
имен, принтеров, файловых систем и т.д. Реализуя записи SRV. компания
Microsoft следовала спецификациям организации IETF, но способ вставки
этих записей в базу данных DNS посредством защищенных динамических
обновлений совершенно нестандартен. Компания использует разновидность
сигнатур транзакций, называемую спецификацией GSS-TSIG. которая также
основана на совместном секретном ключе. Ключ можно получить через
систему Kerberos из центра распределения ключей. Вся прелесть в том, что
реализация Kerberos, используемая компанией Microsoft, не совместима с
открытой версией Kerberos 5! И как прикажете называть тех, кто все это
придумал?
Если нужно работать с Win2K и использовать записи SRV, придется
отказаться от существующей системы Kerberos и запустить сервер Wm2K
Kerberos. Для многих организаций, где вся инфраструктура давно налажена,
это становится неразрешимой проблемой. Возможно, компания Microsoft
разработает какие-то свои расширения.
Через неделю после того, как была выпущена ОС Win2K. число запросов,
адресуемых корневым серверам DNS. резко возросло. Проведенные исследо-
вания показали, что неправильно сконфигурированные системы Win2K
пытались динамически обновить корневые зоны или зоны верхнего vpoBHfl.
В результате число UDP-запросов к корневому серверу А увеличилось более
чем вдвое. Хуже того, когда запросы на обновление заканчивались неудачей,
системы Win2K открывали TCP-соединение, чтобы запросить запись KEY и
попытаться выполнить аутентифицированное динамическое обновление.
У корневого сервера нет возможности отвечать на миллионы запросов об
установлении TCP-соединения. На момент выхода книги в печать проблема
все еше не была разрешена. Операторы корневых серверов тычут пальцами
на сотрудников Microsoft, а те говорят: “Нет, нет, это не мы!*’
16.14. Тестирование и отладка
Демон named располагает рядом встроенных средств отладки, основное
из которых — великолепная подсистема журнальной регистрации. Можно
также задавать уровни отладки в строке вызова демона или устанавливать их
посредством команды ndc. Имеются команды, заставляющие демон вывести
492
Чосп» II Робото в сетях
статистику результатов своей работы в файл. С помощью программ dig и
nslookup можно проверить, правильно ли функционирует механизм поиска
имен.
Журнальная регистрация
Возможности подсистемы журнальной регистрации демона named дейст-
вительно впечатляют. Сервер BIND 4 использует систему Syslog для записи
сообщений об ошибках и различных аномалиях В BIND 8 концепция
журнальной регистрации обобщена: добавлен еше один уровень переадреса-
ции и поддерживается направление сообщений непосредственно в файлы.
Прежде чем переходить к деталям, приведем мини-словарь терминов,
связанных с журнальной регистрацией в пакете BIND (табл. 16.12).
Таблица 16.12. Лексикон покето BIND
Термин________Что означает___________________________
канал	Место, куда направляются сообщения: система Syslog, файл или
устройство /dev/null
категория Класс сообщений, генерируемых демоном named; например, сооб-
щения о динамических обновлениях или сообщения об ответах на
запросы
модуль	Имя исходного модуля, который сгенерировал сообщение (только в
BIND 9)
средство Название средства системы Syslog; за DNS нс закреплено собствен-
ное средство, но можно выбрать любое стандартное
серьезность Степень тяжести сообщения об ошибке; то, что в Syslog называется
приоритетом 
Конфигурирование журнальной подсистемы осуществляется при помощи
инструкции logging в файле namcd.cont Сначала определяются каналы —
возможные пункты доставки сообщений. Затем различным категориям
сообщений назначаются те каналы, куда они будут поступать.
При генерации сообщения ему назначается категория, модуль (в BIND 9)
н уровень серьезности. После этого оно рассылается по всем каналам,
связанным с данными категорией н модулем. В каждом канале имеется
фильтр, определяющий, сообщения какого уровня серьезности можно про-
пускать. Каналы, ведущие в систему Syslog. подвергаются дополнительной
фильтрации в соответствии с правилами. установленными в файле /cic/sys-
log.conf
Вот общий вил инструкции logging:
logging {
опрелеление канала;
определение— канала;
category иия_кате1 'срии ।
имя_ канала;
имл_ канала :
};
);
Глово 16 Системе доменных имен
493
Определение канала может выглядеть немного по-разному в зависимости
от того, ведет ли он к файлу или к системе Sysiog. Для каждого канала
необходимо выбрать либо тип file, либо тип sysiog; совмещать их канал
не может.
channel иия канма {
file путь [versions чисдо_версии I unlimited] [size размер];
sysiog средство;
severity серьезность:
print-category yes I ho;
print-severity yes I no;
print-time yes I no;
);
Для файлового канала аргумент число_версий сообщает, сколько резервных
копий файла нужно хранить. Аргумент размер указывает, какой предельный
размер файла допускается (примеры. 204 8, 100k, 20m, 15g, unlimited,
default).
Для каналов системы Sysiog задается имя средства, указываемое при
регистрации сообщений. Это может быть любое стандартное средство, ио на
практике единственный разумный выбор — средства daemon и localO—lo-
cal?.
Список средств системы Sysiog приводился в параграфе 11.5.
Остальные предложения в определении канала являются необязательны-
ми. Аргумент серьезность может принимать следующие значения (в порядке
снижения приоритета): critical, error, warning, notice, info и debug
(к нему может добавляться номер уровня, например severity debug 3).
Понимается также значение dynamic, которое соответствует текущему
уровню отладки сервера.
Различные параметры семейства print задают или отменяют вывод
различных префиксов сообщений. Система Sysiog добавляет перед каждым
сообщением метку времени и имя узла, но не уровень серьезности или
категорию. В BIND 9 существует также параметр, позволяющий отображать
имя исходного файла (модуля), сгенерировавшего сообщение. Параметр
print-time рекомендуется включать только для файловых каналов, посколь-
ку в Sysiog произойдет ненужное дублирование информации.
В табл. 16.13 перечислены четыре канала, определенные по умолчанию.
В большинстве случаев создавать новые каналы не требуется.
Тоблицо 16.13. Стондортные конолы журнольной регистроции покето BIND
Имя коноло________Нозночение___________________________________________
default_syslog Посылает сообщения уровня info и выше в систему Sysiog от
имени средства daemon
default_debug Направляет сообщения в файл па med. run, уровень серьезности
устанавливается равным dynamic
default_stderr Направляет сообщения в стандартный канал ошибок демона
named с уровнем серьезности info
null Отбрасывает все сообщения
494
Чость 11 Роботе в сетях
В табл. 16.14 приведен список категорий сообщений, поддерживаемых
в BIND 8 и 9. Категории версии 9 еше не полностью определены. Если в
столбце Версия указано “8/9?”. это означает, что категория существует
в BIND 8, но еще не поддерживается в BIND 9.
Тоблицо 16.14. Котегории сообщений покето BIND
Категория	Версия	Что охватывает
default	8/9	Категории, для которых нс был явно назначен канал
general	9	Неклассифицированные сообщения
config	8/9	Этап анализа и обработки конфигурационного файла
parser	8	Этап низкоуровневой обработки конфигурационного файла
queries/client	8/9	Короткое сообщение для каждого запроса, принимае- мого сервером (!)
dnssec	9	Сообщения системы DNSSEC
lame-servers	8/9?	Сообщения о серверах, которые, как предполагается, обслуживают зону, но на самом деле это не такх
statistics	8/9?	Общие статистические сообщения серверов имен
panic	8/9?	Фатальные ошибки
update	8/9	Сообщения о динамических обновлениях
ncache	8/9?	Сообщения о кэшировании отрицательных ответов
xfer-in	8/9	Сообщения о зонных пересылках, принимаемых сер- вером
xfer-out	8/9	Сообщения о зонных пересылках, отправляемых сер- вером
db/database	8/9	Сообщения об операциях с базой данных
eventlib	8	Отладочная информация, поступающая от системы обрабо гки событий3
packet	8/9?	Копии принимаемых и отправляемых пакетов3
notify	8/9	Сообщения об изменении зоны
cname	8/9?	Сообщения вида ”... указывает на запись CNAME"
security	8/9	Принятые или не принятые запросы
OS	8/9?	Ошибки операционной системы
insist	8/9?	Внутренние ошибки
maintenance	8/9?	Периодические служебные события
load	8/9?	Сообщения о загрузке зоны
response-checks	8/9?	Пояснения к неправильно сформированным или неверным ответным пакетам
resolver	9	Операции преобразования имен, например рекурсив- ный поиск, выполняемый от имени клиента
network	9	Сетевые операции
1 В BIND 8 в категорию default попадают также неклассифицированные сообщения.
2 Эго может быть как родительская, так и дочерняя зона.
3 Это должен быть единый файловый канал
Полный список категорий BIND 8 содержится в файле /inchide/dns/
confcommon.h. В том же каталоге находится файл log.h со списком модулей.
Глово 16. Системе доменных имен
495
В BIND 9 эти файлы называются Hb/dns/include/dns/log.h и bin/named/ln-
clude/named/log .h.
Стандартный вид инструкции logging в BIND 8 таков:
logging {
category default ( default_syslog; default_debug; |;
category panic J default_syslog; default_stderr;
category eventlib ( default_debug;
category packet ( default_debug; };
I;
В BIND 9 он будет следующим:
logging (
category default { default_syslog; default_debug; };
};
Нужно просматривать журнальные файлы при внесении существенных
изменений в систему BIND: возможно, стоит также повысить уровень
отладки. После того как демон named вернется в стабильное состояние, следует
переконфигурировать систему так, чтобы регистрировались только важные
сообщения. Ниже перечислены наиболее распространенные сообщения.
•	Неправильно сконфигурированный сервер. Если подобное сообщение посту-
пает от одной из внутренних зон, значит, в конфигурации системы
присутствует ошибка Если же в сообщении говорится о какой-то зоне
в Internet, то можно не беспокоиться: это чья-то чужая ошибка.
•	Неправильная отсылка. Это сообщение свидетельствует о непрааильном
взаимодействии серверов имен определенной зоны
•	Не авторитетен. ПодтгненныЙ сервер не может получить авторитетные
данные о зоне. Возможно, у него хранится неправильная ссылка на
главный сервер или же тот не смог загрузить зону
•	Отказанная зона. Демон named отказался загружать зонный файл, по-
скольку тот содержит ошибки.
•	Не найдена запись NS. В зонном файле после записи SOA отсутствуют
записи NS. Возможно, они действительно отсутствуют либо перед ними
не поставлен знак табуляции или какой-нибудь другой пробельный
символ. Во втором случае эти записи не присоединяются к зоне и,
следовательно, интерпретируются неправильно.
•	Не задано стандартное значение TTL. Желательно задавать стандартное
значение TTL посредством директивы $TTL, расположенной в начале
зонного файла. Данная ошибка свидетельствует о том, что такая директива
отсутствует. В BIND 8 в подобной ситуации берется значение параметра
.минимальное время жизни записи SOA* В BIND 9 наличие директивы
обязательно, в противном случае демон named откажется загружать
зонный файл.
•	Нет корневого сервера имен для данного класса. Демону named не удается
найти корневые серверы имен. Следует проверить файл корневых
‘'подсказок’’ и подключение сервера к Internet.
•	Адрес уже используете;/. Порт, который нужен для работы демона named,
занят другим процессом, возможно, другой копией демона. Если демон
В BIND 8.2 смысл этого параметра изменился: раньше он задавал стандартное значение
TTL для всех записей, теперь — только для отрицательных ответов.
496
Часть II Роботе в сетях
отсутствует в списке выполняющихся процессов, то, очевидно, он перед
этим аварийно завершил свою работу и оставил открытым управляющий
сокет программы ndc.
Прекрасную таблицу с описанием сообщений об ошибках BIND можно
найти по адресу
http://www .acmebw.com/asknirdrts/bind-messages. him
Уровни отладки
Уровни отладки демона named обозначаются целыми числами от 0 до 11
Чем выше уровень, гем больше текста содержит выходная информация
Уровень 0 выключает отладку. Уровни I и 2 отлично подходят для отладки
конфигурационного файла и базы данных. Уровни выше четвертого прсдна
значены для программистов, сопровождающих программный код демона.
Отладку можно запустить из командной строки, активизируя демон named
с флагом -d. Например, команда
# named -<12
запускает демон на уровне отладки 2. По умолчанию отладочная информация
записывается в файл named.niB, местоположение которого зависит от опера-
ционной системы (подробности указаны в параграфе 16-16). Он растет очень
быстро, поэтому в процессе отладки будьте внимательны.
Если отладку нужно включить во время работы демона named необходимо
воспользоваться командой ndc trace, которая увеличивает уровень отладки на
единицу'. Команда ndc notrace отключает режим отладки. Кроме того, воз-
можно создание канала регистрации сообщений, в определение которого
входит строка следующего вида:
severity debug 3
Она обеспечивает направление всех отладочных сообщений вплоть до
уровня 3 в данный канал. Другие директивы в определении канала указывают
на то, куда в конечном итоге попадут сообщения. Чем выше уровень
серьезности, тем больше информации регистрируется.
Просматривая файлы регистрации и отладочные сообщения, можно
заметить, как часто делаются ошибки в конфигурации DNS. Малюсенькая
точка в конце имени (точнее, ее отсутствие) приводит к угрожающему росту
трафика DNS. Теоретически точка нужна в конце каждого полностью
определенного имени домена.
Отлодко посредством программы ndc
Программа ndc (nidc в BIND 9) — очень удобное средство управления
демоном named. Поддерживаемые ею команды перечислены в табл. 16 15 1с
команды, которые создают файлы, помешают их в каталог, обозначенный в
файле named.conf как начальный каталог демона named.
Выполнить Команду ndc reload — все равно что послать демону named
сигнал HUP. Эта команда заставляет демон ганово прочитать конфигураци-
онный файл и повторно загрузить зонные файлы. Команду ndc reload юна
удобно применять иа загруженном сервере, когда изменению подвергается
только одна зона, а остальные трогать не нужно
Глово 16. Системе доменных имен
497
Таблица 16.15. Полезные отладочные команды программы ndc
Команда Функция ________________ ________________ 
help	Вывод списка доступных команд программы ndc
status	Отображение текущего статуса выполнения демона named
trace	Увеличение уровня отладки на единицу
notrace	Выключение отладки
dumpdb	Вывод образа базы данных DNS в файл nameddutnp.db
stats	Вывод статистической информации в файл named, stats
reload	Повторная загрузка файла named.conf и зонных файлов
reload зона Повторная загрузка только указанной зоны
restart Повторный запуск демона named с очисткой кэша
querylog Переключение режима трассировки поступающих запросов
Команда ndc dumpdb заставляет демон named записать образ своей базы
данных в файл nameddump.db, Он будет очень большим и будет содержать
не только локальные данные, но также данные, накопленные в кэше сервера
имен. Не так давно мы провели эту операцию иа основном сервере имен
домена colorado.edu0 и вышло, что кэш базы данных занял 16 Мбайт, тогда
как весь зонный файл — менее 200 Кбайт.
Последние версии демона named ведут статистику запросов, которую
можно получить с помощью команды ndc stats. В ответ на нее демон
записывает статистическую информацию в файл named.stais. Ниже показан
образец такого файла, взятый с главного сервера домена cs.colorado.edu (перед
этим ои непрерывно функционировал в течение 43-х дней). Мы немного
сократили вывод, удалив записи, касающиеся устаревших или неиспользуемых
типов записей. Кроме того, мы переформатировали нижнюю секцию, которая
обычно записывается в одну строку.
+++ Statistics Dump +++ Wed Feb 2 15:07:18 2000
180465	time since boot (secs)
52669	time since reset (secs)
0	Unknown query types
475460 A queries
3	NS queries
194	CNAME queries
15686	SOA queries
138816	PTR queries
76244	MX queries
130939	TXT queries
1	LOC queries
171	SRV queries
42	AXFR queries
124587	ANY queries
+* Name Server Statistics ++
RR	RNXD	RFwdR	RDupR	RFail	RFErr	RErr	RAXFR	RLame
320252	23620	249826	1013	3532	0	903	42	10339
ROpts	SSysQ	SAns	SFwdQ	SDupQ	SErr	RQ	RIQ	RFwdQ
498
Часть II. Роботе в сетях
О	55547	652973	265736 291448 G	963690 О	О
RDupQ	RTCP	SFwdR	SFail	SFErr	SNaAns	SNXD
478/6	1605	249826	18	0	162533	190644
Загадочные данные в конце листинга отображают такие статистические
показатели, как число дублирующихся запросов и ответов, а также количество
случаев напрасного делегирования. Первая буква аббревиатуры обозначает
принятый (R) или отправленный (S) пакет, последняя — запрос (Q) или ответ
(R). Реальный смысл заголовков описан в файле ns_stats.c. который распо-
ложен в каталоге sre/bin/named дистрибутива BIND 8. На момент написания
книги статистические показатели еще не были реализованы в BIND 9.
поэтому мы не можем указать нужный исходный файл. Его можно будет
найти с помощью утилиты grep или find.
Любой запрос, приводящий к ошибке, регистрируется, учитывается в
одном или нескольких статистических показателях и отбрасывается. В кате-
горию Unknown query types (неизвестные типы запросов) включается
любой запрос к ресурсу, тип которого не поддерживается сервером. Группа
ANY — это не настоящий тип записей. Сюда попадают запросы, содержащие
просьбу предоставить любую информацию о требуемом имени. Колонки в
нижней половине листинга, в заголовке которых содержится строка Dup,
отображают число дублирующихся запросов или ответов. Дублирование
обычно происходит, когда срок действия запроса истекает раньше, чем на
него будет получен ответ. В этом случае запрос посылается заново.
В BIND 8, если установлен параметр 6eallocate-on-ex.ut. команда
ndc stats, помимо всего прочего, записывает в файл iiamed.memstats статистику
использования памяти. В BIND 9 данная информация доступна только в
режиме отладки демона named.
Отлодко с помощью программ nslookup, dig и host
Программы nslookup. dig и host позволяют в режиме командной строки
посылать запросы базе данных DNS. Самая старая из них — nslookup, опа
всегда являлась частью дистрибутива BIND Программа dig (domain information
groper — искатель доменной информации) первоначально была написана
Стивом Хотпом (Sieve Holz). а Майкл Сойер (Michael Sawyer) переписал ее
для BIND 9 Она также входит в состав BIND. Программа host, написанная
Эриком Вассенааром (Eric Wassenaar), поставляется с исходными текстами и
имеет функции для проверки синтаксиса зонных файлов. Мы рассмотрим
все три утилиты, но прежде нужно сказать, что мы предпочитаем пользоваться
программой dig. а не nslookup, хотя программа host нам тоже нравится Иногда
они выдают разные результаты из-за того, что используются разные модули
распознавания: в dig и host это распознаватель пакета BIND а в nslookup
свой собственный.
Программа nslookup — утилита пользовательского уровня, посылающая
запросы базе данных DNS. Она принимает в качестве аргумента полностью
определенные имена, оканчивающиеся точкой, и добавляет стандартное имя
домена, если точка не указана. При работе с локальными именами это как
раз то, что нужно. В табл. 16 16 показан краткий список команд, поддержи-
ваемых программой nslookup.
Гпово 16 Системе доменных имен
499
Таблице 16.16. Команды, которые поддержчвою“ся программой nslookup
КомоНДО	Функция
имя	Вывод информации об указанном узле или домене
help или ?	Вывод полного списка команд
exit	Выход
server узел	Задание сервера по умолчанию с использованием текущего сервера
Iserver узел	Задание сервера по умолчанию с использованием исходного сервера
set type^xxx	Установка типа записи для запроса1
set debug	Включение отладки
set d2	Включение массы отладочных средств
Is домен	Вывод всех машинно-адресных соответствий
Хороший аргумент для этой команды — any, т.е. “все”.
Программа dig имеет те же функциональные возможности, что и nslookup.
но установки, заложенные в ней по умолчанию, более эффективны. Кроме
того, она выдаст больше информации н отличается более изысканным
интерфейсом пользователя (особенно в сравнении со старыми версиями
nslookup).
Например, запросить записи MX для узла anchor можно посредством
команды
% dig anchor.cs.colorado.edu. их
Команда
% dig 6n91.berkeley.edu vangogh.berkeley.edu. any
запрашивает все записи для узла vangogh с сервера berkeley.edu а команда
% dig -X 12В.32.33.5
выполняет обратный запрос, в результате которого будет найден узел vangogli.
Приведем полный пример, в котором программы nslookup и dig запра-
шивают одни и те же данные
% nslookup
Default Server: bb.rc.vix.com
Address: 204.152.187.11
> set typ«=any
> amazon.com.
Server: bb.rc.vix.corr
Address: 204.152.lB7.il
Non-authoritative answers:
amazon.com
amason.com
amazon.com
amazon.com
amazon.com
amazon.com
amazon.com
nameserve: = AUTHOO.NS -UU.NET
nameserver NS2.PNAP.NET
nameserver = KS1.PNAP.NET
naireserver — NS-1 .amazon, com.
preference = 10, mall exchanger —
service-4.arazon.com
preference = 10, mail exchanger =
service-5.amazon.com
internet address 208.216.182.15
Authoritative answers can De found from:
amazon.com
nameservet = AUTHOC.NS.HU-NET
500
Чость II Роботе в сетях
amazon.com
amazon.com
amazon.com
AUTHO0 .NS.L'U.NEl
NS2.PNAP.NET
NS1.PNAP.NET
NS-l.anazon.com
service-4 . amazon .com
service-5. amazon. coir.
nameserver - MS2.
naneeerver = MSI.
nameserver = NS-J
internet address
.nLetnet address
Lnternet aooress
.ncernet address
-r.cernet address
internet address
P\AP.NET
PNAP.NET
.ar az on. con.
198.ю.i.65
206.J53.194 . ®7
- 206 -2э3.х94- ft-
= 209.19.U. j. p4 .20
2O9.191.io4.50
- 209.191 164 .51
Программа nslookup вернула четыре записи NS. две записи MX л одну
запись А. Она также выдала |Р-адрсса серверов имен и МХ-узлов
% dig ajuzon.com. any
; «>> DiG 8.3 *.<» amazon.com any
;; res options: init recurs deLnam dns si
;; got answer:
;; -»HEADER«- opcode: QUEF-Y, status: NOEPROF, in: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: , AUTHOR!-Y: < ADDITION X..
;; QUERY SECTION:
;; amazon.3?m,
it ANSWER SECTION:
amazon.com.
amazon.com.
amazon.corn.
amazon.com.
aiaazon.com.
amazon.com.
amazon.com.
Lh27mlls
lh27ml1s
Lh27mlls
lh27aills
tj9iTi22s
59rr.2zs
Lh39>r.i9s
;; AUTHORITY SECTION:
amazon.com.	LL-'.-Jls
amazon. cor.	’.r.2	11 s
amazon.com.	ih27rlls
amazon. coir..	.--s
AUTHOO.NS.UU.NE.
NS2.PKAP.NET.
N31.PNAP.NEi'.
NS-1.amazon.com.
10 servrce-4.amazon.
1C serv-ee-5.air.a_or,
208.21o.182.1=
AUTHOO.NS.UU.NET.
№2 . FNAP. NET.
NS1.PNAP.NET.
NS—i . air.a zon . coir .
;; ADDITIONAL SECTION:
AUTHOO.NS.UU.NET. _ЗГ,_*.т20з IN A
NS2.PNAP.NET ,	20h51tr.44s IN A
NSl.PKAP.Nb2.	201151^4 4s IN A
NS-1.amazen.com. 59x22s IN A
service-4.amazon.com. 59r22s IN a
service-5.amazon.com. 59m.22s IN A
1“8.6.2.65
206.253.194
206..(53.194.65
209-191 --64.zO
209. 9i.lc4.50
д.0-5 19.. o4 .
;Total query time: 7 nsec
;; FROM: ob.rc.v-x.com to SERVER: aetault 2O4.li2.-8
;; WHEN: Sen Jul 2 12:45: =9 2000
;; MSG SIZE sent: 28 revd: 333
Программа dig довольно многословна lie выходная информация вклicM.iei
не только сведения о домене, но и данные о количестве посланных запросов
и полном времени прохождения ответа. Выводные данные отформатированы
так. чтобы их можно было использовать в юнпых файлах. Это особенно
удобно, если делаются запросы к корневым серверам с целью заполнения
файла "подсказок**.
Программа host по умолчанию выдает краткую но полезную информацию
об \ казанном домене Существует также опция -v для более детального
описания (хотя и не столь подробного, как в случае программы dig). Вводимое
имя домена должно завершаться точкой. Встречая относительное имя,
программа сначала пытается добавить к нему домены, указанные к файле
resolv.conf Если ни одно из них не подходит, программа просто присоединяет
к имени точку
Глово 16 Система доменных име»
501
% host amazon.com.
amazon.com has address 208.216.182.15
amazon.com mail is handled (pri=10) by service-4.araazon.com
amazon.com mail Is handled (pri^lO) by service-5.amazon.com
Тестируя новую конфигурацию, не забудьте проверить как локальные,
так и удаленные узлы. Если доступ к узлу' можно получить по IP-адресу, но
не по имени, скорее всего, виновата система DNS.
Напросное делегирование
Подавая заявление о получении доменного имени, вы просите, чтобы
вашему основному серверу имен и администратору DNS была выделена
(делегирована) некоторая часть дерева имен. Если не поддерживать работу
домена или перенести сервер имен на другой компьютер, не обновив
связующие записи родительского домена, будет иметь место так называемое
напрасное делегирование.
Последствия напрасного делегирования могут быть очень плохими. Если
пользователь попытается связаться с узлом, находящимся в неправильно
сконфигурированном домене, сервер имен отклонит этот запрос, но система
DNS продолжит повторять запрос сотни раз, терроризируя и главный сервер
пользователя, и корневые серверы. В одном журнальном файле, размер
которого за неделю возрос до 3,5 Мбайт (на уровне info), более трети
записей касались напрасного делегирования. Из ннх 16% запросов были к
корневым серверам, предположительно по поводу несуществующих доменов
Один настойчивый пользователь более сотни раз запрашивал корневые
серверы о домене lokyotopless.nei. Бедняга!
Приведем пример:
Jan 29 05:34:52 ipn.caida.org named1223]: Lame server on
'www.games.net' (in 'GAMES.net'?): [207.82.198.150].53
1NS2.EX0DUS.net’
Вот как можно установить источник проблемы с помощью программы
dig (часть выходных данных отброшена):
% dig www.games.net.
;; QUESTIONS:
;; www.games.net, type = A, class = IN
;; ANSWERS:
www.games.net.	3600	A	209.1.23.92
;; AUTHORITY RECORDS:
games.net.	3600	NS	ns.exodus.net.
games.net.	3600	RS	ns2.exodus.net.
games.net.	3600	NS	ns.pcworld.com.
;; ADDITIONAL RECORDS: .
В ответ на первый запрос к локальному серверу возвращается адресная
запись для узла vAW-.games.nei и список авторитетных серверов. Сервер
ns.exodLis.net на момент обращения к нему работал нормально (результаты
запроса здесь не показаны), а вот сервер ns2.exodus.net — совсем другая
история:
% dig gns2.exodue.net www.gamee.net.
;; QUESTIONS:
;; www.games.net, type = A, class •= IN
;; AUTHORITY RECORDS:
502
Чость II Робото 8 сетях
пес.
net.
пес.
пес.
244362 NS
244362 NS
244362 NS
244362 NS
F.GTLD-SERVE RS.net.
J.GILD-SERVERS.net.
К.GTLD-SERVERS.net.
A.GTLD-SERVERS.net.
Сервер указан как авторитетный для домена, но для него не возвращается
записей, лишь ссылки на серверы домена верхнего уровня “net”. Следова-
тельно, мокно сделать вывод о том. что домен ns2.exodus.coni сконфигури-
рован неправильно.
16.15.	Всякая всячина
В этом параграфе собран материал, который должен был появиться
раньше, но мы не смогли найти для него нужное место.
Фойл 'подсказок'
Файл “подсказок” служит для первичного заполнения кэша демона named
информацией о серверах корневого домена. Это позволяет автоматически
начинать процесс поиска всех других имен. При отсутствии файла ‘ подска-
зок” сервер BIND 9 воспользуется списком корневых серверов, заложенным
в коде самого пакета, и в любом случае сможет загрузить корневую зону.
В более ранних версиях пакета этот файл обязателен. (В BIND 9 содержимое
файла “подсказок” переопределяет предустановленные "подсказки” )
Корневые серверы имен время от времени подвергаются изменениям, но
за ними легко следить, так как всем этим серверам присвоены имена в
домене root-servers.nei. Если в системе уже работает сервер имен, можно
посредством программы dig связаться с корневым сервером и сгенерировать
файл “подсказок”. Главным в настоящее время является сервер a.rooi-serv-
ers.net, но в данном случае подойдет любой из них:
%	dig 0f.root-earvere.net . ns > root.cache
Если сервер f.root-servers.nei не отвечает, можно вообще не указывать
конкретный корневой сервер:
%	dig . ns > root.cache
В результате будет получен список корневых серверов из кэша локального
сервера имен, а не из авторитетного источника. Но ничего страшного в этом
нет. Даже если сервер имен не перезагружался или не перезапускался год
или два, он периодически сам обновлял записи корневых серверов по мере
их устаревания. Когда демон named запускается, он повторно запрашивает
“подсказки” от одного из корневых серверов. Таким образом, даже в отно-
сительно старом файле содержится по крайней мере одна запись о доступном
сервере имен.
Приведем пример файла “подсказок” (использовать его в таком виде не
следует):
cs.colorado.edu. IN NS	anchor.cs.colorado.edu.
cs.colorado.edu. IN NS	ns.cs.utah.edu.
;	«» DIG 8.2 «» 0f.root-servers.net . ns
;	Lots of detailed dig info formatted as comments here...
Глово 16. Системе доменных имен
503
Idlh42m IN NS E.ROOT-SERVERS-NET.
Idlh42ir. IN № D.ROOT-SERVERS.NET.
Idlh42m IN NS A.ROOT-SERVERS.NET.
Idlh42m IN NS H.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.	2dlh42m	IN	A	192.203.23D.10
D.ROOT-SERVERS.NET.	2dlh42m	IN	A	128-8.10.90
A.ROOT-SERVERS.NET.	2dlh42m	IN	A	198.41.0.4
H.ROOT-SERVERS.NET.	2dlh42m	IN	A	128.63.2.53
Обратите внимание иа точки, с которых начинаются записи первого
набора. Это не пятна, оставленные типографским станком. На самом деле
они определяют домен (корень), к которому относятся записи NS Некоторые
версии программы dig отображают время жизни в секундах, а не в формате
дней, часов, минут и секунд
Текущий файл подсказок, называемый domain/named.root. можно получить
через анонимный доступ с FTP-узла rs.interinc.ner. В нем имеются коммен-
тарии, в которых указываются старые имена корневых серверов. Альтерна-
тивный адрес — ftp://ftp.nic.mil/domain/named.root.
Конфигурирование домена localhost
Прямая привязка к имени localhost или 1оса!йоы.<Эаиен устанавливается в
файле зоны прямого преобразования для данного домена. Но каждый сервер
обычно является главным для своей собственной зоны обратного преобразо-
вания узла localhost. Вот пример зонного файла:
0	IN SOA cs.colorado.edu. hostipaster .cs.Colorado.edu.
1996110801	;	Порядковый номер
3600	г	Период обновления
900	;	Интервал между попытками
3600000	;	Период устаревания
10000 )	;	Минимальное время жизни
IN NS cs.colorado.edu.
1	IN PTR localhost.cs.colorado.edu.
Обратная привязка к адресу localhost (127.0.0 lJ никогда не меняется,
поэтому периоды обновления и устаревания можно делать достаточно
большими. Обратите внимание на порядковый номер, в котором закодирована
дата: последний раз файл модифицировался в 1996 г. Заметьте также, что
для домена "localhost'’ указан только главный сервер имен. Метасимвол @
здесь раскрывается как "0.0.127.in-addr.arpa.”
Свяжите адрес 127.0.01 с именем “localhosLdojweH.". а не просто ’‘local-
host.”. Правда, корневые серверы принимают столько запросов к ломену
'localhost.”. что, возможно, в конце концов появится глобальная запись
0.0.127 .in-addr.arpa.
Средство управления узлами
Файлы базы данных DNS часто бывают распределены по целым регионам,
административным или даже политическим. Во многих случаях жесткий
централизованный контроль невозможен. Такая ситуация порождает общую
Адрес этого узла вскоре может измениться, поскольку компания Network Solutions больше
не собирается обслуживать главный корневой сервер имен.
504
Чость 11 Робото б сетях
проблему администрирования: как управлять важными (и уязвимыми) фай-
лами данных, которые будут постоянно редактироваться множеством неопыт-
ных пользователей’* Как сделать так, чтобы, например, факультет прикладной
математики не мог изменять записи факультета вычислительной техники и
наоборот?
Если какой-либо политический регион содержит много компьютеров и
в нем имеется административный персонал, то лучшим способ распределить
управление — создать для этого региона поддомен. Если же основной домен
мал и насчитывает лишь несколько компьютеров, подаомен не нужен.
Лучше всего сформировать базу данных LDAP, содержащую сведения об
узлах в пределах всей организации, и воспользоваться утилитами, создающими
зонные файлы отдельных подразделений. Мы пока работаем с древней,
написанной собственными силами программкой addhost, но планируем
перейти на LDAP, как только представится возможность сделать эту задачу
студенческим проектом.
|у/[ Программа addhost доступна на yuic ftp. xor.com.
Доступ к DNS для систем, не подключенных к Internet
Если система не подключена к Internet, а нужно работать с DNS. можно
объявить свой главный сервер имен авторитетным для корневого домена.
Такая конфигурация подойдет либо для небольшой фирмы, еще не имеющей
доступ в Internet, либо для организации, скрывающей свою структуру за
брандмауэром.
|у7| Подробнее о брандмауэрах рассказывается в параграфе 21.9.
В такой системе файл “подсказок'’ должен указывать па локальные
серверы имен, а не на корневые серверы Inieinet. Лучше, конечно, получить
зарегистрированное доменное имя и официальные IP-адрсса или воспользо-
ваться частными IP-адресами, которые определены в документе RFCI918
(см. табл. 13.7 в параграфе 13.4).
16.16.	Особенности DNS в различных операционных системах
В этом параграфе описано, каким изменениям подвергся свободно
распространяемый организацией ISC пакет BIND в наших тестовых опера-
ционных системах. Мы приводим ссылки на конфигурационные файлы,
сообщаем, какая версия BIND используется в том или ином случае и как
интегрировать пакет с другими источниками административных данных,
например с обычными файлами и системой NIS. Более подробно последняя
тема освещена в главе 18. В частности, обратите внимание на параграф 18 3.
Solons
Операционные системы Solans 7 и 8 в настоящее время поставляются с
пакетом BIND 8.1.2. Имеется файл “переключения сервисов ". называющийся
/etc/nsswitch.conf. который определяет, как взаимодействуют между собой
BIND, NIS. NIS+ и файл /etc/hosts. Есин строку host этого файла записать
следующим образом:
hosts: tiles dns
Гпово 16. Системе доменных имен
505
то в процессе преобразования имен сначала будет опрашиваться файл
/etc/hosts, а затем — DNS. Желательно поместить в этот файл адреса
важнейших серверов и маршрутизаторов, чтобы устранить возможное зави-
сание системы, которое может произойти, если сервер имен будет недоступен
на этапе начальной загрузки.
В документации рекомендуется запускать серверы N1S в режиме переад-
ресации, чтобы они перенаправляли серверам DNS запросы, ответ на которые
не получен из локальной базы данных. На этом основании компания Sun
рекомендует такую строку конфигурации:
hosts: nis INOTFOUND=return] files
Мы не согласны. Локальный сервер NIS не быстрее локального сервера
DNS, а данные все равно должны находиться в DNS, чтобы из внешнего
мира можно было получить доступ к системе. Поэтому, даже если в
организации используется NIS, лучше разделять обе системы.
Имена файлов пакета BIND и их местонахождение в Solaris указаны в
табл. 16.17.
Тоблицо 16.17. Фойлы покето BIND в Soloris
Фойл	Каталог	Описоние
resolv.conf	/ек-	Файл конфшурацин распознавателя
in.named	/usr/sbin	Демон сервера имен
named-xfer	/usr/sbin	Код модуля зонных пересылок
named.conf	/etc	Конфигурационный файл сервера имен
named.pid	/etc	Идентификатор процесса демона in.named
named, run	каталог1	Выходная отладочная информация
named.stats	каталог^	Выходная статистическая информация
nameddump.db	каталог1	Образ всей базы данных
named-bootconf	/usr/sbin	Программа преобразования конфигурационных файлов BIND 4 в формат BIND 8
1 Этот каталог указан в		файле /etc/named.conf как начальный для файлов BIND
HP-UX
Используемый в HP-UX 11.00 вариант BIND построен на базе версии
BIND 4.9.7. Задействован тот же принцип переключения сервисов, что и в
Solaris. Самого файла nsswitch.conf нет, но в каталоге /etc имеется несколько
файлов-примеров (найти их можно с помощью команды Is /etc/nssw*).
Чтобы создать файл nsswitch.conf, узнайте в документации, какую
конфигурацию нужно реализовать, а затем найдите в файлах-примерах
нужный вариант. Один из файлов, /etc/nsswitch.hpdefaults, иллюстрирует по-
ведение системы в ситуации, когда файл nsswitch.conf отсутствует и пи
содержит синтаксическую ошибку. В отношении поиска имен конфигурация
такова:
hosts: dns [NOTFOUND=return] nis [N0TFOUND=return] files
Сначала используется DNS, но если сервер недоступен или не сконфи-
гурирован, поиск продолжается в NIS, а затем — в файле /etc/hosts. Когда
сервер DNS не может найти ответ на запрос, возвращается сообщение об
ошибке вида ‘‘host unknown”.
506
Чость II. Робото в сетях
Чтобы в процессе начальной загрузки не возникало конфликтов, мы
рекомендуем такую конфигурацию:
hosts: files [NOTFOUND»=continue] dns
Если используется система NIS, она должна опрашиваться второй, перед
DNS, а в конфигурационном файле нужно указать директиву continue
(продолжать) как действие, выполняемое в случае возникновения ошибки.
Важно сконфигурировать процесс начальной загрузки сети таким образом,
чтобы имена узлов не искались в NIS или DNS. Для этого строка files
должна стоять первой, а в стартовых сценариях следует задавать IP-адреса,
а не доменные имена.
В табл. 16.18 указано местоположение важнейших файлов пакета BIND
в HP-UX.
Таблица 16.18. Файлы пакета BIND в HP-UX
Файл	Каталог	Описание	
resolv.conf	/etc	Файл конфигурации распознавателя	
named	/usr/sbin	Демон сервера имен	
named-xfer	/usr/sbin	Код модуля зонных пересылок	
named, boot	/etc	Конфигурационный файл сервера имен	
named.pid	/var/run	Идентификатор процесса демона named	
named.mn	/var/tmp	Выходная отладочная информация	
named.stats	/var/tmp	Выходная статистическая информация	
nameddump.db	/var/tmp	Образ всей базы данных	
В HP-UX, в каталоге /usr/newconfig, имеются файлы-примеры с отлич-
ными комментариями, но почему-то разработчики не удосужились создать
такие файлы для DNS. В ранних версиях HP-UX (до версии 11.00) образцы
файла named.conf зонных файлов и файла resolv.conf находились в каталоге
/etc/newconfig. Каталог /nsr/newconfig, похоже, является обобщением каталога
/etc/newconfig, но лучшее — всегда враг хорошего: пытаясь создать более
полный набор примеров, разработчики забыли о файлах пакета BIND.
Надеемся, это недоразумение будет исправлено,- когда операционная система
HP-UX перейдет к BIND 8 или BIND 9.
Кроме того, в HP-UX предусмотрены средства, которые помогут перейти
от файла /etc/hosts к DNS. Программа hosts_to_named выполняет преобразо-
вание файла /etc/hosts в формат записей о ресурсах DNS. Программа
sig named позволяет посылать сигналы демону named; это просто надстр^ика
команды kill с аргументами наподобие программы ndc.
Red Hat
Red Hat Linux 6.1 поставляется c BIND 8.2, а все файлы находячся н
стандартных каталогах (табл. 16.19). В Red Hal 6.2, как и во FreeBSD,
используется версия пакета 8.2.2-Р5, поэтому информацию о файлах вы
можете почерпнуть из следующего раздела. Файл "переключения сервисов”
такой же, как и в Solaris. Он задает приоритеты различных источников
данных. (Информацию по нему можяо получить посредством команды твп
nsswitch, а не man nsswitch.confj
Глово 16. Система доменных имен
507
Таблица 16.19. Фойпы покето BIND в Red Hot Linux
Файл	Каталог	Описание
resolv.conf	/etc	Файл конфи|урвции распознавателя
named	/usr/sbin	Демон сервера имен
naniedxfer	/usr/sbin	Код модуля зонных пересылок
named.conf	/cic	Конфигурационный файл сервера имен
named, pid	/var/run	Идентификатор процесса демона named
named.run	каталог1	Выходная отладочная информация
named.stats	каталог'	Выходная статистическая информация
named.memstats	катамг1	Статистика использования памяти
nameddump.db	каталог'	Образ всей базы данных
Этот каталог указан в файле /etc/named.conf как начальный тыл файлов BIND-
При отсутствии файла nsswitch.conf система по умолчанию принимает
приведенную ниже конфигурацию:
hosts; dns (*UNAVAIL=return] files
Предложение JUMAVAIL. которое, как сказано в документации. установ-
лено по умолчанию. кажется нам неправильным. К тому же. оно вступает в
противоречие с файлом-примером, поставляемым с Red Нац где строка hosts
выглядит следующим образом:
hosts: db files nispins dns
Мы рекомендуем такую конфигурацию:
hosts; files dns
В Red Hal есть ряд образцов конфигурационных файтов. Все они
находятся в каталоге /etc и снабжены хорошими комментариями. Для файла
named.conf отсутствует своя тап-странииа.
FreeBSD
Во FreeBSD 3.4 и 4.0 входит пакет BIND 8.2.2-Р5 Файл "переключения
сервисов" называется /elc/hosl.conf и определяет порядок обращения к
информационным службам только в процессе преобразования имен. Возмож-
ные источники информации указаны в отдельных строках в том порядке, в
котором они должны опрашиваться.
» Сначала пповеряетсч файл etc/hosts
hosts
В Следующим опрашивается сервер имен
oind
# Если сконфигурировано «дгужба YP/NIS. активизируйте следующую строку
# *115
Если файла host.conf не существует, первой опрашивается система DNS.
В случае неудачи проверяется файл /etc/hosis Во FreeBSD файл named.conf
переместился из каталога /elc в каталог /etc/namedh. Имена файлов и
каталогов, в которых расположены файлы, приведены в табл. 16.20.
508
Чошь II Робото в сетях
Таблица 16.20. Файлы пакета BIND во FreeBSD
Фойл	Коталог	Описание
resolv.conf	/etc	Файл конфигурации распознавателя
named	/usr/sbin	Демон сервера имен
named-xfer	/usr/libcxcc	Код модуля зонных пересылок
named.conf	/etc/namedb	Конфигурационный файл сервера имен
named.pid	/var/гип	Идентификатор пронесся демона named
named.run	ka/wuo/	Выходная отладочная информация
named.stats	каталог^	Выходная статистическая информация
named.memstats	катами1	Статистика, использования памяти
named dunip.db	катами1	Образ всей бззы данных
Зонные файлы	/etc/namedb	Стандартное местоположение зонных файлов
1 Этот каталог указан в файле /etc/namcdb/named.conf как начальный для файлов
BIND.
Каталог /etc/namedb содержит ряд файлов-примеров: файл корневого
кэша (named.root), прототип файла зоны обратного преобразования для узла
localhost (PROTO.localhost.rev) и shell-сценарий make-localhost, который запра-
шивает у пользователя имя домена, после чего создает файл зоны обратного
преобразования для узла localhost на основании имеющегося прототипа.
Perl-сценарий named-bootconf, находящимся в каталоге /usr/sbin, преоб-
разует стартовый сценарий па med. boot пакета BIND 4 в файл named.conf
формата BIND 8.
По нашему мнению, перемещение файла named.conf из каталога /etc
следует рассматривать как уголовное преступление. Мы рекомендуем создать
на прежнем месте ссылку на новое местоположение файла, чтобы оба
имени — новое и старое — работали. Просматривая комментарии в конце
файла named.conf, мы догадались. что первоначально разработчики FreeBSD
планировали запускать демон named в среде с измененным корневым
каталогом. Но в стандартной конфигурации этого на самом деле не
происходит. Дополнительную информацию можно получить из переменных
named_* в файче /etc/defaults/rc.conf.
На niап-странице, посвященной демону ranted, неправильно указаны
некоторые пути, в частности к файлу- статистики и файлу образа баш данных.
Очевидно, ошибка имеется в самом дистрибутиве на узле isc.org, поскольку
в Solaris и FreeBSD одинаковые ошибки.
1617. Рекомендуемая литература
Система DNS и пакет BIND описаны во многих источниках, включая
документацию, входящую в состав дистрибутива, отдельные главы в некото-
рых книгах об Internet, целую книгу серии *'|n a Nutshell’’ издательства
O’Reilly, а также многочисленные ресурсы в internet.
Списки рассылки и группы новостей
Ниже перечислены списки рассылки, посвященные пакету BIND:
•	bind-users — чтобы присоединиться, пошлите сообщение по адресу
b i nd - use rs-request@ i sc. org;
Ггово 16 Системо доменных имен
509
•	bind-announce — чтобы присоединиться, пошлите сообщение по адресу
bind-announce-request@isc.org;
•	namedroppers — чтобы присоединиться, пошлите сообщение по адресу
namedroppers-request@intemic.net;
•	bind-workers — чтобы присоединиться, пошлите сообщение по адресу
bind-workers-request® isc-о rg.
Сообщать о найденных ошибках можно по адресу bind-bugs@isc.org пли
bind9-bugs@isc.ocg.
Книги и другая документация
•	The Nominum BIND Development Team. B!NDv9 Administrator Reference
Manual.
Этот документ доступен из дистрибутива BIND (doc/arm) на Web-узле
www.isc.org. Здесь в общих чертах описаны принципы администрирования
пакета BIND 9. Более ранний документ, BIND Operations Guide, или BOG.
как его называют, содержит подробное описание функционирования и
конфигурирования пакета BIND 4. Документ BOG входит в дистрибутивы
BIND вплоть до версии 8.
•	Albitz, Paul, and Cricket Liu. DNS and BIND, Fourth Edition. Sebastopol, CA:
O'Reilly, 2001.
Это новое издание популярной и очень уважаемой книга о пакете BIND,
содержащее описание всех основных версии пакета (8.2.3. 9.1.0. а также 4.9).
Ресурсы в Internet
В списке часто задаваемых вопросов телеконференции comp.sys.tcp-ip.do-
mains имеется множество информации о пакете BIND, в основном версии 4.
Список ведется Крисом Пекемом (Chris Peckham) и доступен по адресу
http: //www. i п tac. со пт/~ cdp/c ptd -faq
Каталог ресурсов DNS (www.dns.net/dnsrd) — это полезная коллекция
ресурсов и ссылок на них, сопровождаемая Андрасом Саламоном (Andras
Salamon).
Документы RFC
RFC-документы, в которых описывается система DNS, можно получить
на Web-узле www.rfc-editor.org. Ниже перечислены избранные подмножества
этих документов
Исходные стандарты
•	1034 — Domain Names: Concepts and Facilities (Доменные имена: понятия
и базовые возможности);
•	Ю35 — Domain Names: Implementation and Specification (Доменные имена;
реализация и спецификация).
Предложенаые стандарты
•	1995 — Incremental Zone Transfer in DNS (Инкрементные зонные
пересылки в DNS);
•	1996 — A Mechanism for Prompt Notification of Zone Changes (Механизм
уведомления об изменениях зон);
•	2136 — Dynamic Updates in DNS (Динамические обновления в DNS),
510
Чость II. Роботе в сетях
•	2181 — Clarifications to the DNS Specification (Пояснения к спецификации
DNS);
•	2308 — Negative Caching of DNS Queries (Кэширование отрицательных
ответов на DNS-запросы).
Наборы новых стандартов
•	2535 — Domain Name System Secuntv Extensions (Расширения DNS.
связанные с безопасностью);
•	2671 — Extension Mechanisms for DNS: EDNSO (Механизмы расширения
DNS: EDNSO);
•	2672 — Non-Terminal DNS Name Redirection: DNAME (Передача управ-
ления именами в DNS: запись DNAME);
•	2673 — Binary Labels in DNS (Двоичные метки в DNS).
Различные документы
•	1535 — A Security Problem and Proposed Correction With Widely Deployed
DNS Software (Проблема безопасности широко распространенного про-
граммного обеспечения DNS и предложенное решение);
•	1536 — Common DNS Implementation Errors and Suggested Fixes (Распро-
страненные ошибки в реализации DNS и предлагаемые исправления);
•	1982 — Serial Number Arithmetic (Вычисление порядковых номеров);
•	2536—2541 — документы, связанные со спецификацией DNSSEC.
Типы записей о ресурсах
•	1183 — New DNS RR Definitions: AFSDB, RP, X25, ISDN. RT (Определения
новых записей о ресурсах в DNS: AFSDB, RP, Х25. ISDN, RT);
•	1706 — DNS NSAP Resource Records (Записи о ресурсах NSAP в DNS);
•	1876 — A Means for Expressing Location Information in DNS (Средства
представления информации о местоположении в DNS);
•	2052 — A DNS RR for Specifying the Location of Services: SRV (Запись
DNS, задающая расположение сервисов- SRV);
•	2168 — Resolution of Uniform Resource Identifiers using DNS (Преобразо-
вание универсальных идентификаторов ресурсов средствами DNS);
•	2230 — Key Exchange Delegation Record for the DNS (Запись о ресурсах
DNS. позволяющая передавать право на осуществление обмена ключами).
DNS и Internet
•	1101 — DNS Encoding of Network Names and Other Types (Кодирование
сетевых имен и других типов ресурсов в DNS);
•	1123 — Requirements for Internet Hosts: Application and Suppon (Требования
к Internet-узлам: прикладные и служебные протоколы);
•	1591 — Domain Name System Structure and Delegation (Структура DNS и
делегирование полномочий);
•	2317 — Classless in-addr.arpa Delegation (Бесклассовое делегирование в
домене in-addr.arpa).
Функционирование DNS
•	1537 — Common DNS Data File Configuration Errors (Распространенные
ошибки конфигурирования базы данных DNS);
•	1912 — Common DNS Operational and Configuration Errors (Распростра-
ненные ошибки функционирования и настройки DNS);
Глово 16. Системе доменных имен
-511
•	2182 — Selection and Operation of Secondary DNS Servers (Выбор и
функционирование вторичных серверов DNS);
•	2219 — Use of DNS Aliases for Network Services (Использование
DNS-псевдонимов для сетевых сервисов).
Другие документы, связанные с DNS
•	1464 — Using DNS to Store Arbitrary String Attributes (Использование DNS
для хранения произвольных строковых атоибутов);
•	1713 — Tools for DNS debugging (Средства отладки DNS);
•	1794 — DNS Support for Load Balancing (Средства распределения нагрузки
в DNS);
•	2240 — A Legal Basis for Domain Name Allocation (Правовые основы
выделения доменных имен);
•	2345 — Domain Names and Company Name Retrieval (Поиск доменных
имен и имен компаний),
•	2352 — A Convention For Using Legal Names as Domain Names (Соглашение
об и с пользе вашш зарегистрированных имен в качестве доменных).
J 7 Сетевая файловая система
Сетевая файловая система, или NFS (Network File System), позволяет
компьютерам совместно использовать их локальные файловые системы. NFS
почти прозрачна для пользователей и не поддерживает понятие сеанса, т.е.
при крахе сервера данные в удаленных файловых системах не пропадают.
Клиенты просто ждут, когда сервер вновь начнет функционировать, а затем
продолжают работать так, будто ничего не произошло.
Сетевую файловую систему внедрила компания Sun Microsystems в
1985 году. Первоначально NFS была реализована как суррогат файловой
системы для бездисковых клиентов, но предложенный протокол оказался
столь удачным, что со временем стал универсальным решением проблемы
совместного использования файлов Сейчас уже трудно припомнить, какой
была жизнь до появления NFS. Большинство поставщиков UNIX-систем
предлагают ту или иную версию NFS, причем многие используют код,
полученный по лицензии от Sun.
17.1.	Общая информация об NFS
Сетевая файловая система состоит из ряда компонентов, включая
протокол и сервер монтирования, демоны, координирующие работу базового
файлового сервиса, а также несколько диагностических утилит. Части
клиентского и серверного программного обеспечения NFS находятся непо-
средственно в ядре. К счастью, они не требуют конфигурирования и
преимущественно “прозрачны” с точки зрения администрирования.
Версии протокола NFS
Протокол NFS отличается удивительной стабильностью. Первый откры-
тый выпуск NFS имел версию 2. В начале 90-х тт. в протокол были внесены
изменения, которые привели к появлению версии 3. Ее характеризовали
повышенная производительность и улучшенная поддержка больших файлов.
Глово 1 7. Сетевой фойповоя системе
513
Пока существовала версия 2, клиент не мог считать операцию записи
завершенной, не получив подтверждения от сервера. Сервер должен был
записать иа диск каждый модифицированный блок, прежде чем отвечать.
Это позволяло избежать проблем в случае краха сервера. Подобное ограни-
чение являлось причиной существенного замедления работы системы, по-
скольку во многих случаях модифицированные блоки вполне можно было
хранить лишь в резидентном буфере.
В версии 3 данное узкое место было устранено за счет схемы
согласования, которая позволяет выполнять операции записи асинхронно.
Был улучшен также ряд других параметров протокола, связанных с произво-
дительностью. вследствие чего NFS 3 стала работать гораздо быстрее, чем
NFS 2.
Сервер версии 3 всегда может взаимодействовать с сервером версии 2.
Просто он при этом переключается на использование более старого
протокола.
Выбор транспортного протокола
В основе NFS лежит протокол RFC (Remote Procedure Call — удаленный
вызов процедур) компании Sun. который определяет системно-независимым
способ взаимодействия процессов по сети. Положительным побочным
эффектом этой архигекгуры является возможность выбора транспортного
протокола — TCP или UDP.
Изначально в NFS применялся протокол UDP. поскольку он обеспечит
наилучшую производительность в локальных сетях 80-х гг. И хотя программ-
ное обеспечение NFS само выполняет сборку пакетов и осуществляет
контроль ошибок, но ни в UDP, ни в NFS ие реализованы алгоритмы
контроля перегрузки, которые необходимы для достижения нормальной
производительности в крупной IP-сети.
С целью решения этих проблем в большинстве систем было разрешено
использовать в качестве транспортного протокола для NFS не UDP, a TCP.
Первоначально данная возможность предназначалась для обеспечения работы
NFS через маршрутизаторы и в сети Internee Но в настоящее время
большинство специалистов рассматривает TCP и как оптимальное средство
для управления локальным трафиком. В конце концов, по мере удешевления
памяти и роста производительности центральных процессоров первоначаль-
ные доводы в пользу UDP становятся все менее актуальными.
Серверы, поддерживающие протокол TCP. как правило, принимают
запросы на установление соединений от обоих транспортных протоколов.
поэтому выбор между TCP н UDP делает клиент. Большинство клиентов по
умолчанию работают с UDP, Solaris к их числу не относится.
Поддержка TCP официально появилась в спецификации протокола NFS
версии 3. но существуют реализации версии 2, где такая поддержка тоже
имеется (например, в Red Hal) В ю же время есть и реализации версии 3.
где поддержка ГСР отсутствует (в частности, в HP-UX).
Все данные о поддержке протокола I СР и NFS версии 3 в наших тестовых
системах сведены в табл 17.1. В колонке "По умолчанию” указано, какому
протоколу отдает предпочтение клиентская часть системы.
514
Чость II. Роботе в сетях
Тоблицо 17 1	Поддержке росши ре иных возможностей NFS в операционных системах		
Система	NFSv3?	TCP?	По умолчанию
Solaris	Да	Да	TCP
HP-UX	Да	Нет	UDP
Red Hat	Нет	Да1	UDP
FreeBSD	Да	Да	UDP
1 Протокол TCP поддерживается только		на стороне	клиента.
WebNFS
В 1996 г. компания Sun предприняла попытку внедрить NFS в глобальную
сеть, предложив собственную оригинальную систему WebNFS. Будучи над-
множеством стандартного протокола NFS версии 3, WebNFS устраняет
(точнее, делает необязательными) некоторые вступительные транзакции, через
которые должен пройти традиционный клиент NFS. прежде чем он получит
доступ к файловой системе. Этот механизм предназначен не для замены NFS.
а для поддержки апплетов, выполняющихся в среде Web-броузеров. Следо-
вательно, для организаций, не занимающихся написанием таких апплетов,
система WebNFS не представляет особого интереса
Все наши тестовые операционные системы (кроме HP-UX) обеспечивают
серверную поддержку протокола WebNFS. Дополнительную информацию
можно получить ио адресу www.sun.com/wcbnfs.
Блокировка файлов
Блокировка файлов (.реализуемая системными вызовами flock и/илп lockf)
в течение долгого времени являлась “больным" вопросом для UNIX-cuciext
В локальных файловых системах этот механизм был реализован далеко не
идеально. Что касается NFS. то положение все еше неустойчиво. Серверы
NFS не поддерживают понятие сеанса: они не знают о том. какие компьютеры
работают с конкретным файлом Но эта информация необходима для
использования блокировок Как быть?
Традиционное решение заключается в реализации механизма блокировок
отдельно от NFS. В большинстве систем этой цели служат два демона, lockd
и statd. К сожалению, реализация такого подхода затруднена по ряду причин,
поэтому блокировка файлов в NFS часто организована неоптимальным
образом.
Дисковые квоты
Доступ к информации о дисковых квотах на удаленном компьютере
осуществляет серверный демон rquolad. работающий во внеполосном режиме
Сервер NFS будет поддерживать дисковые квоты, но клиенты не смогхт
ничего о них узнать, если на удаленном компьютере не работает демон
rquolad. Мы считаем механизм дисковых квот большей частью устаревшим,
поэтому не будем рассказывать об этом демоне.
Глово 17. Сетевой фойловоя остемо
515
Глобальные идентификаторы пользователей и групп
В UNLX пользователи и группы пользователей идентифицируются по
номерам. Если пользователь компьютера X имеет файлы на компьютере .
то желательно, чтобы его идентификатор был одинаковым в обеих системах,
иначе могут возникнуть серьезные проблемы с безопасностью или конфи-
денциальностью.
Боме подробные сведения об идентификаторах пользователей и групп содержат-
ся в главе 6.
В некоторые серверы NFS были внедрены средства преобразования
удаленных идентификаторов в локальные, но эта возможность не является
частью официального протокола NFS и не может считаться надежной при
работе с несколькими операционными системами. Мы рекомендуем обра-
щаться с идентификаторами старым, но надежным способом: следует сделать
так, чтобы на всех компьютерах, где происходит совместная работа с файлами,
за пользователями и группами были закреплены одни и те же номера. Чтобы
избавить администратора от головной боли, добейтесь уникальности иденти-
фикаторов в пределах всей организации.
Серверы NFS не требуют регистрации удаленных пользователей в системе.
Пользователь может даже не иметь записи в файле /etc/passwd, если только
на сервере не установлена какая-нибудь необычная опция, например rap_nis
в Red Hat.
Учетные записи root и nobody
В общем случае пользователи должны иметь одинаковые привилегии в
любой системе, к которой они получают доступ. Однако традиционно
ограничиваются возможности неконтролируемого применения прав супер-
пользователя в файловых системах, смонтированных посредством NFS. По
умолчанию сервер NFS перехватывает входящие запросы, посылаемые от
имени пользователя с идентификатором 0, и “делает вид”, будто они
поступают от другого пользователя. Таким образом, учетная запись root не
отменяется, но уравнивается в правах с обычными учетными записями
В большинстве систем специально определена фиктивная учетная запись
nobody, чтобы под нее *’маскировался” пользователь root, работающий на
сервере NFS. Ее идентификатор может быть разным в зависимости от системы
и в принципе не играет особой роли; чаше всего это -2 или 65534. Важно
то, что этот идентификатор не пересекается ни с одним из идентификаторов
реальных пользователей. В Solaris и HP-UX доступ в систему будет вообще
запрещен, если назначить учетной записи root идентификатор -1.
Все эти предосторожности преследуют благородную цель, однако конеч-
ный результат далек от идеала. Будучи клиентом NFS, пользователь root
может с помощью команды su ‘‘принять облик” любого пользователя, так
что наши файлы никогда не бывают полностью защищены. Системные
учетные записи, такие как bin и sys, не подвергаются смене идентификатора',
поэтому принадлежащие им файлы (а это большой процент системных
файлов) открыты для нападений. Единственный действенный эффект от
смены идентификаторов заключается в том, что предотвращается доступ к
В действительности в Red Hat можно менять идентификаторы других учетных записей
помимо root. Подробнее об этом рассказывается в параграфе 17,2. Будьте осторожны, чтобы
подобными изменениями не нарушить работу стандартных программ, в частности sendmail.
516
Чость II Робото в сетях
файлам, которые принадлежат пользователю root и недоступны для чтения
или записи остальным пользователям.
Секретные ключи и монтирование без учета состояния
Прежде чем начинать работу с файловой системой NFS, клиент должен
ее смонтировать, как если бы это была файловая система, хранящаяся на
локальном диске. Но NFS не сохраняет информацию о сеансах, поэтому
сервер не знает, какие клиенты смонтировали каждую файловую систему.
Вместо этого сервер выдает клиенту секретный ключ по факту успешного
завершения операции монтирования. Этот ключ идентифицирует каталог
монтирования на сервере NFS и позволяет клиенту получить доступ к
содержимому данного каталога.
Как правило, при демонтировании и повторном монтировании файловой
системы на сервере ее секретный ключ меняется. Но есть особый случай
ключ сохраняется при перезагрузке, чтобы сервер после краха смог вернуться
в свое нормальное состояние. Не стоит, однако, пробовать загружаться в
однопользовательском режиме, работать с файловой системой, а затем
зафужаться вновь: это приведет к аннулированию ключей и лишит клиентов
возможности доступа к файловым системам, которые они смонтировали, до
тех пор. пока они либо не перезафузятся, либо не осуществят повторное
монтирование этих файловых систем.
Если у клиента есть секретный ключ, он может с помощью протокола
RPC посылать файловой системе запросы, например на создание файла или
чтение блока данных. Поскольку в NFS нет понятия сеанса, то серверу все
равно, какие запросы клиент делал (или не делал) ранее. В частности, прежде
чем удалять собственную копию данных, подлежащих записи, клиент сам
должен убедиться, что сервер подтвердил запрос на запись.
Соглашения об именах совместна
используемых файловых систем
Управлять сетевой файловой системой становится проще, если придер-
живаться стандартной схемы именования. Полезны такие имена, которые
содержат имя сервера (например, /anchor/tools — файловая система, распо-
ложенная на машине anchor), потому что они позволяют переводить
объякления вида ‘‘машина anchor будет всю субботу отключена в связи с
модификацией’' в "я не смогу поработать над файлом 'anchor/'tools ТеX в
субботу, чтобы закончить диссертацию, поэтому лучше отправлюсь на
лыжную прогулку"
К сожалению. *та схема требует, чтобы каталог /anchor существовал в
корневых каталогах всех клиентских компьютеров. Если клиент получает
доступ к файловым системам, расположенным на нескольких машинах, его
корневой каталог может оказаться захламленным. Рассмотрите возможность
углубления иерархии, например, используйте каталоги /home/anchoi. ,Ъо-
me/rastadon и т.д. Мы советуем привет нуть к помоши демонов автоматиче-
ского монтирования, описание которых начинается в парафафе 17 6.
Безопасность и NFS
Сетевая файловая система предоставляет удобный способ доступа к
файлам по сети и потому является серьезным источником угроз для
Глово 11 Сетевоя сЬойловоя система
517
безопасности. Она подобна тренажеру, на котором можно проверять любые
бреши, существующие илн когда-либо существовавшие в UNIX.
Изначально в протоколе NFS не были предусмотрены никакие средства
зашиты. Позднее лежащий в его основе протокол RPC подвергся модифи-
кации и появилась возможность использовать подключаемые модули аутен-
тификации. Однако новая спецификация так и не предложила конкретного
механизма зашиты.
Тогда на арену вышли два конкурента: компания Sun, представившая
собственную технологию на основе систем шифрования с открытым ключом,
проигнорированную другими поставщиками, и система Kerberos, расширив-
шая свои стандартные средства аутентификации на RPC. Оба решения
позволяли убедиться, что удаленный пользователь действительно тот, за кого
себя выдает. Но ни в одном из случаев данные, передаваемые по сети, не
подвергались шифрованию, поэтому пользователи по-прежнему находились
во власти хакеров, пользовавшихся анализаторами пакетов.
0 Подробнее о системе Kerberos рассказывается в параграфе 21.8.
Если в организации уже используется система с открытым ключом
компании Sun или система Kerberos, обязательно применяйте ее совместно
с N FS Раз есть корова, пусть она дает молоко! В противном случае установка
такой системы вряд ли себя оправдывает. Возможно, оба этих варианта
представляют интерес, но на самом деле они обеспечивают лишь минимальное
повышение защищенности по сравнению с уровнем, который определяется
здравым смыслом. В организациях среднего размера достаточной мерой
зашиты от нежелательного проникновения является жесткий контроль нал
совместно используемыми файловыми системами.
Самая высокая степень риска связана с локальными компьютерами,
которым официально разрешено монтировать файловые системы. Если
человек, которому вы не доверяете, имеет привилегированный доступ к
клиентскому компьютеру, не экспортируйте на эту машину никакие файловые
системы.
При наличии в организации брандмауэра блокируйте доступ к TCP- и
UDP-портам 2049. которые используются протоколом NFS’. Кроме того,
необходимо блокировать доступ к демону portmap системы Sun RPC, который
обычно прослушивает TCP- и UDP-порты 111. Несмотря на все эти
предосторожности, не стоит также забывать правило, согласно которому
файловые системы NFS не должны экспортироваться иа нелокальные
машины (WebNFS не в счет)
0 О брандмауэрах речь пойдет в параграфе 21.9.
17.2.	Серверная часть NFS
Говорят, что сервер “экспортирует" файловую систему, если он делает
ее доступной для использования другими компьютерами. В Solaris употреб-
ляется термин “предоставляет в совместное использование" Для ясности мы
решили придерживаться в этой главе первого варианта.
Процесс монтирования файловой системы (т.е. определения ее секретного
ключа) полностью отличается от процесса последующего доступа к удаленным
файлам В обеих операциях используются совершенно разные протоколы, а
Правда, если организация предоставляет сервис WebNFS, придется разблокировать ТСР-
порт 2049. Но это не относится к компьютерам, содержащим критические данные.
518
Чость II. Робото в сетях
запросы обслуживаются разными демонами: в первом случае — mountd, во
втором — nfsd. В некоторых системах оии называются соответственно
rpc.inountd и rpc.nfsd — как напоминание о том, что их работа основана на
технологии Sun R.PC (следовательно, для их выполнения требуется демон
portrnap. о котором рассказывается в параграфе 28.3).
На сервере NFS оба демона, mountd и nfsd, должны стартовать на этапе
начальной загрузки системы и продолжать выполняться, пока система ие
будет выключена. Чаше всего запуск демонов осуществляется автоматически
Стартовые сценарии проверяют, сконфигурированы ли экспортируемые
файловые системы, и если это так. то демоны запускаются.
Демоны mountd и nfsd совместно эксплуатируют обшую базу данных с
информацией о правах доступа, где указано, какие файловые системы следует
экспортировать и какие клиенты могут их монтировать. Рабочая копия этой
базы данных обычно хранится в двоичном фай ле (в большинстве систем он
называется xtab, в Solaris — sharetab) где-то в корневой файловой системе;
ее копия может быть также спрятана в ядре.
Поскольку файл базы данных представлен в нечитаемом формате, для
добавления и редактирования записей требуется вспомогательная команда.
В большинстве систем это команда exportfs, в Solaris — share. Удалить записи
можно посредством команды exportfs -и или unshare.
Управлять двоичным файлом вручную — не самое приятное занятие,
поэтому большинство систем предполагает, что пользователь ведет текстовый
файл, в котором перечислены все экспортируем fate каталоги системы и права
доступа к ним На этапе начальной загрузки система читает этот файл и на
его основании автоматически создает файл xtab или sharetab.
В большинстве систем имеется файл /etc/exports. включающий канони-
ческий список экспортируемых каталогов в текстовом виде. Его содержимое
читается посредством команды exportfs -а В Solaris канонический список
хранится в файле /etc/dfs/dfstab. который в действительности представляет
собой сценарий, состоящий из последовательности команд share. (Команда
shared! с помощью утилиты grep извлекает из файла d fstab все NFS-команды
и выполняет их Но NFS — единственная широко распросграненная система
совместного использования файлов, поэтому команда shareall эквивалентна
вызову sh /etc/dfs/dfstab.)
FreeBSD необычна тем. что демон mountd опрашивает файл /etc/exports
напрямую, поэтому необходимости в файле xtab и команде export fs не
возникает. Изменив файл exports, нужно послать демонх mountd сигнал HUP.
чтобы он повторно прочитал содержимое файла:
# kill -HUP 'cat /var/run/mountd-pid'
Все вышесказанное сведено в табл. 17.2. В ней указано, какой файл
нужно редактировать прн экспорте новой файловой системы и что нужно
сделать по окончании редактирования, чтобы изменения вступили в силу
Тоблицо 17.2. Кок экспорта ровоть котопог
Системе	Список экспортируемых фойловых систем	Что делать после внесения изменений
Solaris	/etc/dfs/dfstab	Выполнить команду sbareall
HP-UX	/etc/exports	Выполнить команду /usr/sbin/exportfs -а
Red Hai	/etc/exporls	Выполнить команду /usr/sbin/exportfs -а
FreeBSD	/etc/exports	Послать демону mountd сигнал HUP
Глово 17. Сетевой фойповоя системе
519
NFS работает не на физическом уровне файловой системы, а на
логическом. Экспортировать можно любой каталог; он необязательно должен
быть точкой монтирования или корневым каталогом физической файловой
системы. Однако из соображений безопасности NFS определяет границы
между файловыми системами, которые относятся к различным устройствам,
и требует чтобы каждая такая файловая система экспортировалась отдельно.
К примеру, если раздел смонтирован как /users, то корневой каталог можно
экспортировать независимо от этого раздела.
Обычно клиентам позволяется монтировать подкаталоги экспортирован-
ного каталога. Скажем, если сервер экспортирует каталог /chimchim/users, то
клиент может смонтировать подкаталог /chimchim/users/joe, а остальную часть
каталога users — проигнорировать. Большинство систем не позволяет экс-
портировать подкаталоги с другими параметрами, чем у родительского
экспортированного каталога, хотя Red Hal — исключение из правила.
ф
Команда share и файл dfstau (Sc'nris)
Сценарий /etc/dfs/dfstab выполняет команду share однократно для каждой
экспортируемой файловой системы. Например, на сервере, совместно ис-
пользующем каталог /chimchim/users с машинами band и moon (при этом
клиент band имеет права пользователя root) и каталог /user/share/man с
машинами chimchim и rastadon. файл /etc/dfs/dfstab будет содержать такие
команды:
share -F nfs -о rw-bar.a.хог . com:moon.хог«сот» root=band.хог. сот
/chimchim/users
share -F nfs о rw=chimchim.хог.com:rasradon хог.сот /usr/share/man
После редактирования файла /etc/dfs/dfstab нс забудьте вызвать команду
shareall. и все изменения вступят в силу. Учтите, что команда shareall просто
выполняет команды, записанные в файле dfstab, поэтому она не сможет
отменить совместное использование файловые систем, шпион которых были
удалены из файла. Наиболее распространенные опции команды share
перечислены в табл. 17.3.
Тоблицо 17.3 Опции команды shore {Solans)
Опция	Описание	_ ________________________________
гп	Экспорт с доступом только для чтения всем пользователям (не
рекомендуется)

rw—список
тоа1=список
»noo^uid
nosub
позпИ
•Экспорт с доступом только дня чтсгия указанным узлам
Экспорт с доступом для чтения и записи всем пользователям (не
ре ком е щц'стся)
Экспорт с доступом дтя чтения и записи заказанным узлам
Список узлов, которым разрешен доступ к этой файловой системе
с правами суперпользователя; без данной опции привилегированный
доступ с машины-клиента эквивалентен доступу от имени пользова-
теля nobody (как правило, его идентификатор равен -2)
Значение UID которое нужно использовать для запросов, поступаю-
щих от пользователя root; по умолчанию — nobody
Запрещает клиентам монтировать подкаталоги экспортированного
каталога
Запрещает создавать через NbS файлы с чстанокленными битами
SLID и SG1D
520
Чооъ II. Робота в сетях
Список, используемый в различных опциях команды share, должен
состоять из групп элементов, разделенных символами двоеточия (табл. 17.4).
Все элементы идентифицируют узлы или группы узлов.
Таблица 17.4 Спецификации узлов в команде share
Тип_______________Синтаксис_______Нозначение___________________________.
Имя компьютера имяксмпъютера Имена отдельных узлов (должны быть полно-
стью определены, если используется DNS)
Сетевая группа	имя группы	Сетевые группы NIS; подробнее об этом
рассказывается в параграфе 18.3
Домеи DNS	-хег.ууу	Любой узел в пределах домена
JP-сети@имя сети Имена сетей, заданные в файле /etc/networks1
1 Допускаются также спецификации в формате C1DR. например ® 128.138.92.128/25
Примечание к табл. 17.4, касающееся имен узлов, стоит повторить еще
раз: если в организации используется система DNS, имена отдельных узлов
должны быть полностью определенными, иначе они будут проигнорированы.
Перед элементом можно поставить дефис, что означает запрет Список
просматривается слева направо, пока не будет найдено совпадение, поэтому
операции отрицания должны предшествовать более общим спецификациям.
Напрнмер. строка
share -F nfs -о rw—GL26.136.243/24 : .cs-Colorado.edu /users
экспортирует каталог /usr с доступом для чтения-загтсн всем узлам в домене
cs.colorado.edu. за исключением узлов сети 128.138.243.
Разрешается экспортировать каталог одним клиентам с доступом только
для чтения а другим — для чтения-записи Нужно просто включить в
спецификацию как опцию rw=. так и опцию го=.
На man-странице share(IM) описаны некоторые базовые параметры NFS
Полный их список приведен на странице share_nfs( IМ).
Команда exportfs и файл exports (HP-UX, Red Hat, FreeBSD)
Файл exports содержит в крайней левой колонке перечень экспортируемых
каталогов, за которым следуют списки опций п атрибутов. Например, в
HP-UX файл exports, содержащий строки
/chinichxm/users -acces3=band:moon, root=bana
/usr/share/man	-access^xorasaurus: rastadon :rr.oon, ro
определяет, что машинам band и moon разрешено монтировать файловую
систему /chinieliini/users. а с машины band можно получить доступ к этой
файловой системе от имени суперпользователя . Кроме того, машины
xorasaurus. rastadon и moon могут монтировать файловую систему /usr/sha-
re/man с доступом только для чтения.
Файловые системы, которые указаны в файле exports без соответствую-
щего списка компьютеров, обычно могут монтироваться всеми компьютерами
Подобная беспечность приводит к возникновению серьезной бреши в системе
зашиты.
Доступ на уровне суперпользователя разрешен также chitnchim — реальному владельцу' этой
файловой системы
Глово 17 Сетевой фойповоя системе
521
В некоторых реал и ганиях NFS длина строк в файле exports ограничена
1024 символами. Этот предел иногда наступает ужасающе быстро, особенно
если указываются полностью определенные доменные имена. Выходом из
положения может стать использование сетевых групп и масок подсетей.
Конкретные параметры, которые можно указывать в файле /etc/exports.
а также их синтаксис у каждой системы свои, хотя и наблюдается
определенное сходство Ниже описаны особенности систем HP-UX, Red Hat
Linux и FreeBSD, но, как всегда, не помешает все сверить по документации.
Файл exports в HP-UX
В HP-UX формат файла expons наиболее '‘классический” среди всех
наших тестовых систем. Возможные опции (табл. 17.5) очень напоминают
те, которые распознаются командой share в Solaris. Но есть и ряд тонких
различии. Например, строка
.г w—anchor. cs. Colorado. edu:meet. cs. Colorado . edu
в Solans означает экспорт каталога с доступом для чтения-записи только
перечисленным узлам. В HP-UX эта же строка разрешает всем пользователям
монтировать каталог только для записи, а двум укачанным — еше и для
чтения. Попробуй пойми этих разработчиков! В HP-UX, чтобы разрешить
монтирование заданным клиентам, нужно воспользоваться опцией access:
tv, dcces.s=anch<3r. cs. Colorado. edu:meet. cs - Colorado .edu
Установка на чтение-запись сделана по умолчанию, поэтому опцию rw
можно опустить. С другой стороны, не помешает указать ее явно.
В HP-UX каждая строка файла exports должна содержать путь к каталогу,
пробел и дефис, после которого идет список опций, разделенных запятыми.
Примеры строк уже приводились выше
В табл 17.5 перечислены наиболее распространенные опции, которые
можно указывать в файле exports. Под стиком понимается разделенная
двоеточиями последовательность имен узлов и сетевых групп (о последних
речь пойдет в параграфе 18.3).
Таблице 17.5. Ноиболее роси ростра пенные опции фойпо exports в HP-UX
Опция Описание
access ^список	Список клиентов. которые могут монт ировать файловую систему
го	Экспорт только для чтения; ни один клиент не имеет права записи
в файловую систему
• »	Экспорт для чтения и записи (по умолчанию)
'v. спасок	Экспорт 1 данным образом для ч!ения; в списке перечислены
клиент, которым разрешено монтирован не для записи; все
остальные должны монтировать файловую систему только для
чтения
tovt-список
Список клиентов. которым разрешен доступ к файловой системе
с правами суперпользователя, без этой опции привилегированный
доступ с машины-клиента эквивалентен доступу от имени поль-
зователя nobody
Значение UID. которое нужно использовать для запросов, посту-
пающих от пользователя root. По умолчанию это -2 (пользователь
nobody). При указании значения -1 доступ or имени суперлользо-
ва1еля будет вообще запрещен
Асинхронная обработка всех запросов на запись; при наличии
этой опции производительность операций записи повышается,
равно как и вероятность потери данных в случае краха сервера
522
Часть II. Робато в сетях
Не забудьте по окончании редактирования файла /eic/cxports выполнить
команду exportfe -а.
Файл exports в Red Hat Linux
В Red Hat клиенты, которые могут получить доступ к определенной
файловой системе, указываются в файле exports в виде списка, разделенного
пробелами. Сразу после имени клиента в круглых скобках задается перечень
связанных с ним опций, разделенных запятыми. Длинные строки можно
разбивать на части с помощью обратной косой черты.
Вот образцы записей:
/chimchim/users bandtrw,no_root_squash) moorrtrw)
/usr/share/man •.cs.colorado.edu(ro)
Нельзя задать список клиентов с одинаковым набором опции, хотя
некоторые типы “клиентов” соответствуют многим узлам. В табл. 17 6
перечислены четыре типа клиентских спецификаций, которые могут встре-
чаться в файле exports в Red Hat*.
Тоблицо 17.6. Клиентские спецификации в Red Hot
Тип	Синтаксис	Назначение	j	«а
Имя компьютера	имя_компьют ера	Имена отдельных узлов
Сетевая группа	@имя группы	Сетевые группы NIS, подробнее об этом рассказывается в параграфе 18.3
Подстановочные знаки	• и ?	Полностью определенные доменные имена с подстановочными знаками; ме- тасимвол нс соответствует точке
!Р-сети	1Р-адрес/маска	Спецификация в формате C1DR. на- пример 128.138.9 2.128/25
В табл. 17.7 описаны наиболее распространенные опции фаича exports,
характерные для Red Hal
Программное обеспечение NI’S в Red Hat обладает необычной но лож-
ностью: разрешается экспортировать родительский каталог с одними опция-
ми. а подкаталоги — с другими. Имеется также опция по®-г*
позволяющая отменить экспорт подкаталогов, к которым не нужно предос-
тавлять удаленный доступ. Например, в конфигурации
/users
/users/evi
*.хог.com(rw)
(noaccess)
узлам домена xor.com разрешен доступ ко всем катали ам файловой системы
/users, кроме /users/evi. Отсутствие имени клиента во второй строке означает,
что установка относится ко всем узлам; так. очевидно, безопаснее
В Red Hat имеется богатый набор средств преобразования удаленных
идентификаторов пользователей в локальные Мы не советуем применять их
в гетерогенной среде, но если в организации установлены только Linux-сис-
темы. тогда пожалуйста. Подробности можно узнать на тап-страннце
exporis(5).
В действительности их пять, но спецификация -public используется только в WebNFS
Глово 17. Сетевой фойловоя системе
523
Тоблицо 17.7. Ноиболее роспрастроненные опции фойло exports в Red Но!
Опция	Описание		
го	Экспорт только для чтения
rw	Экспорт для чтения и записи (по умолчанию)
гы-список	Экспорт главным образом для чтения, в списке перечислены клиенты, которым разрешено монтирование для записи все остальные должны монтировать файловую систему только для чтения
roor_squash	Закрепляет значения U1D и GID, равные 0, за идентификато- рами, указанными в опциях anonurd и anong id:1 это установка по умолчанию
no_root_squash all_squash	Разрешает обычный доступ от имени пользователя root (опасно) Закрепляет идентификаторы всех пользователей и групп за своими анонимными версиями; это удобно при работе с персональными компьютерами и ненадежными однопользова- тельскими станциями
anonuid=xxx	Значение DID, которое нужно использовать для запросов, поступающих от пользователя root
anong id-xxx	Значение GID, которое нужно использовать для запросов, поступающих от пользователя root
secure	Требует, чтобы запрос на удаленный доступ поступал из привилегированного порта
insecure	Разрешает удаленный доступ с любого порта
noaccess	Предотвращает доступ к данному каталогу и его подкаталогам
В отличие от большинства операционных систем, Red Hat допускает преобразование
идентификатора не только учетной записи root, но и любой другой. Подробности
можно узнать в документации из описания опций squash_ulds и all_squash.
Демон mountd в Red Hat может запускаться по запросу из демона inetd,
а не выполняться непрерывно. Это позволяет обеспечить дополнительный
контроль доступа с помощью программы tepd; подробнее о ней говорится в
параграфе 21.7,
В настоящее время в Red Hat не поддерживается NFS 3, но ожидается,
что эта поддержка появится в ближайшем будущем. Клиентам, по умолчанию
работающим с версией 3, нужно явно сообщить о необходимости монтиро-
вания файловых систем с помощью протокола NFS 2. иначе будут появляться
непонятные сообщения об ошибках
Фойл exports во FreeBSD
Во FreeBSD записи файла exports состоят из разделенного пробелами
списка каталогов, аналогичного списка опций (каждая из них начинается с
дефиса) и набора клиентских спецификаций, также разделенных пробелами.
Приведем короткий пример:
/chimchim/userg	-maproot-rooc band
/chimchim/users	moon
/usr/share/man	-ro -mapall=daemon	xorasaurus rastadon moon
Особенность FreeBSD состоит в том, что имя каталога может встречаться
в нескольких строках. В каждой строке определяются некоторый набор опций
->24
Часть II. Робота в сетях
и клиенты, к которым они относятся. Если разные наборы опций применимы
к различным клиентам, каталогу должно соответствовать несколько записей.
В табл. 17.8 описаны наиболее распространенные опции. В отличие от
большинства реализаций NFS, FreeBSD не позволяет клиентам монтировать
подкаталоги экспортируемых файловых систем, если только разрешение не
выдано явно с помощью опции -alldxrs. Зачем это было сделано, навсегда
останется загадкой; безопасность от этого не повышается.
Во FreeBSD клиенты задаются в виде имен компьютеров или сетевых
групп Это также могут быть номера сетей, представленные в следующем
формате:
-network. сетевой_<сц₽ес -mask маска
Тоблицо 17 8. Ноибогее распространенные опции фойло exports ео FreeBSD
Опция
Описание
Экспорт только для чтения; по умолчанию экспорт предос-
тавляется для чтения-записи
taproot-пользователь Закрепляет идентификатор учетной записи гот1 за указан-
ным пользователем (это может быть значение U1D или
имя) По умолчанию выбирается пользователь nobody (иден-
тификатор -2) Чтобы разрешить привилегированный дос-
туп, задайте -mapLoot=ioot
-тара11=лольэовдте/гь Закрепляет все значения U1D зв определенным пользова-
телем; это удобно при работе с персональными компьюте-
рами и ненадежными однопользовательскими станциями
-alldirs	Разрешает монтировать чюбой подкаталог; по умолчанию
разрешение выдается только для указанного каталога
-webnfs	Экспорт каталога в формате WebNFS; доступ только для
чтения всем пользователям, а все идентификаторы закреп-
ляются за пользователем nobody
Документация иногда требует наличия оператора = между параметром
-network или -mask и его аргументом. но похоже, что такая система записи
работает неправильно Сетевой адрес и маска подсети задаются в традици-
онной точечной нотации, например.
/chimchtm/users -го -network 128.138.243.0 -mask 255.255.255.0
Спецификация номера сети не может присутствовать в той же строке,
где указаны имена узлов и сетевых групп Если это необходимо, задайте для
каталога две строки
Помните о необходимости отправки демону mountd сигнала HUP.
который заставит его повторно прочитать файл /etc/exports после внесения
в него изменении К сожалению демон не способен сообщать пользователям
об обнаруженных в файле ошибках. Придется просматривать системные
журнальные файлы Демон mountd передает сообщения в Syslog от имени
средства “daemon’
Демон nfsd: файловый сервис
Если демон mountd проверил клиентский запрос на монтирование и нашел
его правильным клиенту разрешается запрашивать различные операции
файловой системы. Эти запросы обрабатываются на стороне сервера демоном
Глово 17 Сетевой фон г. своя системе
525
ф
ш
Г
nfsd . Ему нет необходимости выполняться на машине-клиенте NFS. Един-
ственное исключение — когда клиент тоже экспортирует свои файловые
системы.
Демон nfsd принимает числовой аргумент, который определяет, сколько
экземпляров самого процесса nfsd нужно породить посредством системного
вызова fork Выбор необходимого количества процессов очень важен, но, к
сожалению, относится к области черной магии. Если это число будет слишком
мало или слишком велико, производительность NFS может оказаться низкой.
Производительность старых систем сильно снижалась при завышении
числа выполняющихся демонов nfsd, поскольку в случае поступления запроса
ядро посылало каждому неактивному процессу nfsd сигнал пробуждения. Эта
проблема известна как ‘‘лавинный сход процессов". В современных системах
она решена, так что ничего страшного не произойдет, если на выполнение
будет запушено несколько "лишних” процессов.
Раньше максимальное количество процессов nfsd было тесно связано с
чистом аппаратных контекстов, поддерживаемых центральным процессором.
Сегодня в большинстве реализаций NFS все копии демона совместно
пользуются общим контекстом, поэтому упомянутый показатель больше не
является определяющим Более реальная метрика — число обслуживаемых
жестких дисков. При высокой активности NFS полоса пропускания жесткого
лиска станет ограничивающим фактором для канала NFS. Нет необходимости
запускать слишком много экземпляров демона на один шпиндель.
Четыре процесса вполне достаточно для сервера, который используется
нечасто, и достаточно для того, чтобы не возникало проблем с производи-
тельностью. На крупном сервере этот показатель должен быть в диапазоне
от 12 до 20. Увеличивайте число процессов до тех пор. пока показатель
средней загруженности сервера (его сообщает команда uptime) не начнет
заметно возрастать. Это признак того, что система не справляется со своими
функциями. Уничтожьте несколько процессов, и все придет в норму.
На загруженном сервере NFS с большим числом UDP-клиентов буферы
UDP-сокетов могут переполниться, если запросы будут поступать в то время,
когда все демоны nfsd уже задействованы. Число переполнений можно
отслеживать с помощью команды netstat -s. Запускайте дополнительные
демоны до тех пор. пока число переполнений не упадет до нуля, так как
переполнение свидетельствует о серьезной нехватке серверных демонов.
Во многих системах число процессов nfsd задается в одном из файлов
/etc/rc* или в одном из стартовых сценариев, запускаемых демоном init
Иногда существуют и более элегантные способы установки намного значения
В Solaris демон nfsd нужно запускать с флагом -а. чтобы разрешить сервис
NFS как через протокол UDP. так и через TCP Подобный запуск
осуществляется по умолчанию.
В HP-UX число процессов nfsd задается посредством переменной
NUM NFSD в файле /etc/rc.config.d/nfsconf.
Во FreeBSD демон nfsd нужно запускать с флагами -[ и -и, что сделает
возможным обслуживание по протоколам TCP и UDP. Число процессов
задается с помощью флага -п (например, nfsd -I -в -п 8). Аргументы команд-
ной строки, передаваемые демону, берутся из переменной nfs serv-
ELaos в файле /etc/rc.conf (или в файле /etc/defaults/rc.conf. если
пользователь не задал эту переменную, по умолчанию используются следующие
Демон nfsd — это, как правило, очень простая программа, которая посылает системный
вызов, пе предусматривающий ответа, во встроенный в ядро код NFS-сервера.
526
Чость II. Робото в сетях
аргументы: *'-u -t -n 4”). Необходимо также установить переменную
nfsserver enable равной YES, чтобы обеспечить запуск демонов NFS.
17.3.	Клиентская часть NFS
Команда mount понимает запись вида
нмя_компьютера: каталог
как путь к каталогу, расположенному на другом компьютере.
Команда mount и ее NFS-расширения — самая важная область деятель-
ности системного администратора на NFS-клненте. Во многих системах
добиться повышения производительности можно с помощью демона блочного
ввода-вывода biod (иногда он называется nfsiod). Этот демон не относится к
числу обязательных, но мы настоятельно рекомендуем им пользоваться.
Демоны biod и nfsiod: кэширование на стороне клиента
При работе с файловыми системами демон biod/nfsiod выполняет базовые
операции блочного кэширования по алгоритму опережающего чтения и
отстающей записи. Он доступен как в NFS 2, так и n NFS 3. Мы советуем
запускать этот демон на всех NFS-клиентах, хотя это и не является строго
обязательным требованием. Наличие или отсутствие кэширующего демона не
влияет на решение задач администрирования.
Как и iifsd, демон biod в качестве аргумента принимает число, показы-
вающее, сколько экземпляров самого себя ему нужно запустить. Для обычной
машины достаточно будет четырех или восьми копий. Если демоны nfsd и
biod работают на одном компьютере, то разумнее будет разделить “оптималь
ное" число экземпляров между ними. Все зависит от того, как используется
система — вам придется поэкспериментировать.
Во FreeBSD число экземпляров демона nfsiod задается в командной строке
Ч,!.*	с помощью флага -п.
Монтирование удаленных файловых систем
Для создания временных сетевых точек монтирования может использо-
ваться команда mount. Но те монтируемые файловые системы, которые
являются частью постоянной конфигурации, должны быть перечислены в
файде /etc/fstab (/etc/vfstab в Solaris), в таком случае они будут монтироваться
автоматически на этапе начальной загрузки. С другой стороны, они могуч
быть обработаны службой автоматического монтирования, например програм-
мой automount или amd (подробнее об этом речь пойдет начиная с
параграфа 17.6).
Следующие элементы файла fstab предназначены для монтирования
файловых систем /beast/users и /usr/man машин beast и chimcliim.
# filesystem	mountpoint fstype
beast:/beast/users /beast/users nfs
chimchim:/usr/man /usr/гг.ап nfs
flags
rw, bg, intr, hard
ro,bg,intr,soft
dump fsck
0	0
0	U

В Solaris файл /etc/vfstab имеет немного другой формат, но опции NFS
указываются схожим образом. В основном это те же опции что и в других
системах.
Добавляя элементы в файл fslab/vfstab обязательно создавайте с помощью
команды mkdir каталоги точек монтирования. Можно сделать так. чтобы
Глово 17. Сетевое фойловоя система
527
Е
изменения вступали в силу немедленно. Для этого в Solaris или HP-UX
следует выполнить команду mount -a -F nfs, а в Red Hat и FreeBSD — вместо
флага -F указать флаг -t.
Подробнее о файле fstab рассказывалось в параграфе 8.3.
В поле флаги файла /etc/fstab задаются параметры точек монтирования
NFS. Наиболее распространенные флаги перечислены в табл. 17.9.
Таблица 17.9. Флаги монтирования NFS
Флаг	Система	Назначение
rw	SHRF2	Монтирование файловой системы для чтения-записи (она должна экспортироваться сервером в режиме чтения-записи)
го	SHRF2	Монтирование файловой системы только для чтения
bg	SHRF	Если монтирование прошло неудачно (сервер не отвечает), перевести операцию в фоновый режим и продолжать обрабатывать другие запросы монтирования
hard	SHR3	Если сервер отключился, операции, которые пытаются получить к нему доступ, повторяются до тех пор, пока сервер не включится вновь
soft	SHRF	Если сервер отключился, операции, которые пытаются получить к нему доступ, завершаются, выдавая сооб- щение об ошибке; этот флаг полезно устанавливать для того, чтобы предотвратить зависание процессов в случае неудачного монтирования не очень важных файловых систем
intr	SHRF	Позволяет прерывать с клавиатуры заблокированные операции (и заставляет их выдавать сообщения об ошибках)
nolntr	SHRF2	Не позволяет прерывать с клавиатуры заблокирован- ные операции
retrans=4i	SHRF1	Указывает, сколько раз нужно повторить запрос, прежде чем будет выдано сообщение об ошибке (в файловой системе, смонтированной с флагом soft)
Cimeo-=n	SHRF4	Устанавливает интервал тайм-аута для запросов (в десятых долях секунды)
rsize-^и	SHRF4	Задает размер буфера чтения равным л байтам
wgize-n	SHRF4	Задает размер буфера записи равным п байтам
verson	SH	Задает версию протокола NFS: 2 или 3 (обычно определяется автоматически)
nfav3, nfsvZ	F	Задаст версию протокола NFS; 2 или 3 (обычно определяется автоматически)
pro ^протокол	s	Назначает транспортный протокол; возможные значения — тер и udp
tcp	RF	Выбирает TCP в качестве транспортного протокола; по умолчанию принят протокол UDP
Рассматриваемые системы Solans, HP-UX, Red Hat Linux и FreeBSD обозначены
как S, H, R, и F соответственно.
Этот флаг ие упоминается в документации к FreeBSD, но работает.
Во FreeBSD не разрешается указывать данный флаг явно, ио тяпана< мог им
поведение принято по умолчанию.
Во FreeBSD эти флаги называются по-другому; zetrans — -х, tx.ueo — -t,
rsize — -г, wsize — -w.
528
Чость II. Роботе в сетях
Файловые системы, смонтированные с флагом hard, могут вызвать
зависание процессов при отключении серверов. Это особенно неприятно,
когда такими процессами оказываются стандартные демоны Вообще говоря,
использование флагов soft и intг позволяет сократить число проблем,
связанных с NFS. Но эти флаги могут вызывать нежелательные побочные
эффекты (например, останов 20-часового процесса моделирования из-за
временного сбоя в сети после 18 часов работы)*. Некоторые средства для
борьбы с проблемами монтирования предлагает программа arad (описывается
в параграфе 17.8).
Флаги, задающие размеры буферов чтения и записи, применимы в
отношении обоих протоколов, TCP и UDP, но оптимальные значения будут
разными. В случае TCP буфер должен быть большим, поскольку данные
передаются эффективнее. (В Solaris по умолчанию принят размер 32 Кбайт.)
В случае UDP, если сервер и клиент находятся в одной сети, оптимальный
размер буфера — 8 Кбайт. В некоторых системах по умолчанию установлены
гораздо меньшие значения (в Red Hat, например, всего 1 Кбайт).
Демонтирование сетевых файловых систем осуществляется командой
amount.
Выбор порта
Клиенты NFS при подключении к серверу NFS могут использовать любой
TCP- или UDP-порт. Но некоторые серверы требуют, чтобы запросы
поступали из привилегированного порта (номер которого меньше, чем 1024)
В других серверах данное требование может включаться пользователем
В мире персональных компьютеров и настольных UNIX-станций применение
привилегированных портов не приводит к реальному повышению безопасно-
сти системы.
Большинство клиентов NFS следует традиционному (и по-прежнему
рекомендуемому) подходу: по умолчанию выбирается привилегированный
порт, что позволяет предотвратить возникновение конфликтов.
17.4.	Программа nfsstat: отображение статистики NFS
В большинстве систем имеется программа nfsstat, которая предоставляет
различные статистические данные, собираемые системой NFS. Команда
nfsstat -s выдает статистику процессов NFS-сервера, а команда nfsstat -с
отображает информацию об операциях на стороне клиента. Например:
chimchim% nfsstat -с
Client rpc:
calls	badcalls	retrans	badxid	timeout	wait	newcred	timers
64235	1595	0	3	1592	0	0	886
Client nfs:
calls	badcalls	nclget	nclsleep
Джефф Форис (Jeff Forys), один из наших рецензентов, заметил по этому повод}': “Боль-
шинство точек монтирования должно иметь флаги hard, intr и bg, поскольку они
наилучшим образом соответствуют исходной концепции NFS (надежность и отсутствие
информации О состоянии). Флаг soft — мерзкий сатанинский трюк! Если пользователь
захочет прервать операцию монтирования, пусть он сделает это сам. В противном случае
следует дождаться включения сервера, и все, в конце концов, придет в норму без какой бы
то ни было потери данных".
Глово 17. Сетевоя фойловоя системо
529
62613	3	62643	0			
null	getat.tr	secater	read-ink	lookup	root	read
0%	34%	0%	21%	30%	0%	2%
write	wrcache	create	remove	rename	link	syralink
3%	0%	0%	0%	0%	0%	0%
nikdir	readdir	nudir	fsstat			
0%	6%	0%	0%			
Эти результаты получены у относительно нормально функционирующего
NFS-клиента. Если более 3% вызовов заканчиваются тайм-аутом, это говорит
о наличии проблемы ня NFS-сервере или в сети. Причину, как правило,
можно определить путем проверки поля badxid. Если значение badxid
близко к нулю, а число тайм-аутов больше 3%, значит, пакеты, идущие на
сервер и от него, теряются где-то в сети. Возможно, проблему удастся решить
путем уменьшения значений параметров монтирования rsize и wsize
(размеров буферов чтения и записи). Если значение badxid почти так же
велико, как и tirceout, это означает, что сервер отвечает на запросы, но
слишком медленно. Замените сервер или увеличьте параметр timeo
Регулярный прогон программы nfsstat и анализ выдаваемой ею инфор-
мации поможет администратору выявлять возникающие в NFS проблемы
раньше, чем с ними столкнутся пользователи.
17.5.	Специализированные файловые серверы NFS
Быстрый и надежный файловый сервис — один из важнейших элементов
любой серьезной вычислительной среды. Дешевле всего развернуть файловый
сервер на рабочей станции UNIX, разместив его на нескольких жестких
дисках Но это не оптимальное решение с точки зрения производительности
и удобства администрирования.
Уже более десяти лет на рынке имеются специализированные файловые
серверы. У них есть целый ряд преимуществ:
•	они оптимизированы на выполнение операций с файлами и, как правило,
обеспечивают наивысшую производительность при работе с NFS;
•	по мере увеличения требований к хранилищу файлов можно легко
наращивать мощности сервера, который справится с терабайтными
массивами данных и сотнями пользователей;
•	они более надежны, чем UNIX-станции, благодаря усеченному набору
программ, применению дополнительной аппаратуры, обеспечивающей
избыточность данных, и зеркальному дублированию информации на
жестких дисках;
•	они реализуют файловый сервис для клиентов как UNIX, так и Windows,
некоторые даже содержат встроенные Web- и FTP-серверы;
•	чаше всего они проще в администрировании, чем файловые серверы
UNIX;
•	они обладают улучшенными средствами резервного копирования и
контроля состояния, чем обычные UNIX-системы.
На рынке существующих систем фаворитами являются устройства
компании Network Appliance. Inc. (www.netapp.com). Диапазон предло-
жений — от малых до очень крупных систем, и цены вполне приемлемы.
Компании Auspex и ЕМС занимают нишу1 устройств высшего класса. Они
530
Чость II. Роботе в сетях
делают хорошие продукты, но их цены могут испугать кого угодно.
Приготовьтесь также изучить модные маркетинговые термины".
17.6.	Автоматическое монтирование
Индивидуальное монтирование файловых систем посредством упомина-
ния их в файле /etc/fstab илн /etc/vfstab сопряжено в крупных сетях с рядом
проблем. Во-первых, ведение файла /etc/fstab на нескольких сотнях машин —
утомительная задача. Каждая из этих машин может отличаться от других и
требовать индивидуального подхода.
Во-вторых, если файловые системы монтируются с десятка-другого
компьютеров, то в случае краха всего лишь одного из этих серверов наступает
полный хаос, так как все компьютеры, отслеживающие состояние точек
монтирования, зависают.
В-третьих, крах какого-нибудь важного сервера может нанести немалый
ущерб пользователям, сделав недоступными такие важные разделы, как,
например, /usr/share/man. Самый простой выход из подобной ситуации —
временно смонтировать копию раздела с резервного сервера.
Демон автоматического монтирования подключает файловые системы,
когда к ним производится обращение, и отключает их, когда надобность в
них отпадает. Делается это незаметно для пользователей и позволяет свести
к минимуму число активных точек монтирования. Большинство автомонтн-
ровщиков. кроме того, ведет список "дублирующихся" (идентичных) файловых
систем, чтобы сеть могла продолжать функционировать в случае отказа
основного сервера.
Для того чтобы реализовать фоновое подключение и отключение,
автомонтировщик связывает драйвер виртуальной файловой системы с
каталогами, обозначенными как точки автоматического монтирования. Рань-
ше он делал это. выступая в роли сервера NFS. но данный подход имеет
рял серьезных ограничении, поэтому редко применяется в современных
системах. В настоящее время используется драйвер файловой системы autofs.
размещаемый в ядре.
Вместо того чтобы зеркально дублировать в сети реальную фа иловую
систему, автомонтировщик воссоздает ее иерархию в соответствии со
спецификациями, указанными в его файле конфигурации. Когда пользователь
ссылается на каталог в виртуальной файловой системе автомонтировщика,
последний перехватывает эту ссылку, монтирует реальную файловую систему,
к которой обращается пользователь, и передает ссылку дальше. В системах,
где поддерживается драйвер autofs. файловая система NFS монтируется
традиционным для UNIX способом. В других случаях может потребоваться
осуществлять монтирование в отдельном каталоге, на который создаются
символические ссылки.
Идеологом автоматического монтирования является компания Sun. Реа-
лизованная ею программа autoniount поставляется с большинством клиентов
NFS. входящих в состав ее продуктов. В Red Hal имеется одноименная
программа, которая функционирует схожим образом, но реализована неза-
висимо.
Насчет маркетинговых терминов. В рассматриваемом контексте чаще всего можно встретить
выражение “устройство хранения данных с подключением к сети", сокращенно NAS
(Network Attached Storage). На ‘•человеческом" языке это означает файловый сервис.
Глово 17. Сетевоя файловой система
531
До появления драйвера autofs программа automount изобиловала ошибками
и просчетами, которые делали ее неконкурентоспособной в коммерческих
системах. Современные реализации функционируют значительно лучше, хотя
отзывы все еще неоднозначны. Многие пользователи широко применяют ее
без каких-либо проблем, в то время как некоторые сталкиваются с перио-
дическими зависаниями. Несомненно, надежность программы зависит от
операционной системы и реализации.
Программа amd, написанная Джан ом-Саймон ом Пендри (Jan-Simon
Pendry) из Лондонского Королевского колледжа, стала результатом доктор-
ской диссертации, которая развивает идею компании Sun. В программе
исправлены многие серьезные недочеты ранних версий утилиты automount.
Она бесплатна и легко инсталлируется в самых разных UNIX-системах.
Конфигурация программы automount относительно проста и понятна
В случае amd больше сложностей, но и функциональные возможности шире,
хотя некоторые реализуемые данной программой средства считаются экспе-
риментальными.
В предыдущем издании книги мы настоятельно рекомендовали исполь-
зовать amd, а не automount Поскольку в то время программа automount
действительно работала плохо, сделать выбор было несложно . Однако при
наличии более удачной версии automount, основанной на использовании
драйвера autofs. аргументы в какую бы то ни было пользу оказываются
одинаково весомыми. Если говорить в общем, то простота программы
automount и тот факт, что она поставляется со многими системами, повышают
ее шансы. Принять решение можно следующим образом: просмотрите список
возможностей программы amd, и если не найдете там ничего такого, без чего
нельзя обойтись, не тратьте на нее время.
17.7.	Программа automount:
самый первый автомонтировщик
В настоящее время программа automount входит в состав Solaris и HP-UX.
В Red Hat одноименная программа имеет незначительные отличия в
синтаксисе конфигурационного файла Подробнее о ней рассказывается в
конце параграфа.
Программа automount поддерживает три вида конфигурационных файлов
(называемых таблицами назначений): таблицы прямых назначений, таблицы
косвенных назначений и главные таблицы’*. Таблицы первых двух типов
содержат информацию о файловых системах, подлежащих автоматическому
монтированию. Главная таблица — это список таблиц прямых и косвенных
назначений, на которые программа automount должна обращать внимание.
В определенный момент времени активной может быть только одна главная
таблица. Стандартная ее версия хранится в файле /etc/auto_master.
При запуске программа automount читает конфигурационные файлы,
создает необходимые точки монтирования в файловой системе autofs. после
чего завершает свою работу. Ссылки на смонтированные файловые системы
в действительности обрабатываются (через драйвер autofs) отдельным демоном
automountd. Он выполняет свою работу, не требуя дополнительной настройки.
Если в вашей системе поддерживается старая NFS-версия программы automount, мы
по-прежнему рекомендуем избегать ее.
Таблицей прямых назначений можно управлять как базой данных NIS. по на домашнем
компьютере лучше не делать этого.
532
Чость II Роботе в сетях
После редактирования главной таблицы или одной из таблиц прямых
назначений, на которую она ссылается, нужно повторно запустить программу
automount. При наличии флага -v эта программа сообщит об изменениях,
вносимых в конфигурацию.
Получив флаг -t, программа automount сообщает, как долго (в секундах!
файловая система может оставаться неиспользуемой, прежде чем будет
демонтирована. Стандартная установка — 5 минут. Желательно удалять
неиспользуемые точки монтирования, поскольку в случае краха сервера
программы, обращающиеся к NFS, зависнут Из-за этого не рекомендуется
устанавливать период тайм-аута слишком большим .
Таблицы косвенных назначений
Таблицы косвенных назначений используются для автоматического
монтирования нескольких файловых систем в общем каталоге. Путевое имя
каталога задается в главной таблице. Например. 1аблина косвенных назна-
чений для файловых систем, монтируемых в каталоге /chimchim. будет иметь
следующий вид:
users chimchim;/chimchim/ users
devel -sof z, proto-udp chimchim:/chimchim/devex
info -ro chimchim:/chimchim/infо
В первой колонке дается имя подкаталога, в котором будет инсталлиро-
вана файловая система. В следующих колонках перечислены опции монти-
рования и исходное путевое имя файловой системы В этом примере (он
вероятно, хранится в файле /etc/auto.chim) программе automount сообщается
о том, что она может монтировать каталоги /chimchim/users. /chimchim, dev ci
и /chimehim/info с компьютера chimchim. причем каталог info разрешается
монтировать только для чтения, а каталог devel — только по протоколу UDP
(пример взят из Solaris, где по умолчанию выбран протокол TCP)
В рассматриваемой конфигурации подкаталоги на компьютере vhimcliim
и на локальном компьютере будут идентичными, но это вовсе не обязательно
Таблицы прямых назначений
В таблице прямых назначений перечисляются файловые системы, v
которых нет общего префикса, например /usr/src и /cs/tools. Таблица (скажем,
/etc/auto-direct), которая описывает эти файловые системы для программы
automount. может выглядеть так
/usr/src chimchim:/usr/src
/cs/tools -ro anchor:/cs/looIs
He имея общего родительского каталога. обе файловые системы должны
подключаться через отдельные точки монтирования к файловой системе
autofs. Накладные расходы при этом возрастают, но появляется дополтггель-
ное преимущество: точка монтирования и реальная структура каталога всегда
доступны для таких команд, как. например. Is. Использование команды Is в
каталоге с косвенно смонтированными файловыми системами часто затруд-
нительно для пользователей, потому что программа automount не отображает
Обратной стороной медали является тот факт, что монтирование файловой системы rpeoyei
определенного времени. С точки зрения производительности нежелательно, чтобы файло-
вые системы непрерывно подвергались персмонтированию.
Глово 17. Сетевой фойловоя системе
"33
подкатало! и до обращения к их содержимому (команда Is не заглядывает
внутрь каталогов, поэтому и не вызывает их монтирования).
Главные таблицы
Главная таблица содержит список таблиц прямых и косвенных назначе-
ний. Для каждой таблицы косвенных назначений указывается корневой
каталог, применяемый для монтирования перечисленных в таблице файловых
систем.
Главная таблица, использующая вышеупомянутые таблицы прямых и
косвенных назначе»п1Й. имеет такой вид:
♦ Directory Мар
/chimchiiB	/etc/auto.chim -proto=tcp
/-	/etc/auto.direct
Первая колонка — имя локального каталога (для таблицы косвенных
назначений) или специальная лексема /- (для таблицы прямых назначений)
Вторая колонка — имя файла, в котором хранится соответствующая таблица.
При необходимости может быть создано по нескольку таблиц каждого типа
Параметры монтирования, указываемые в конце строки, задаются для всех
точек монтирования в данной таблице.
В большинстве систем параметры, указываемые в главной таблице, не
смешиваются с параметрами, задаваемыми в соответствующей таблице
прямых или косвенных назначений. Если запись подчиненной таблицы имеет
свой список опций, стандартные параметры полностью игнорируются В Red
Hat все происходит по-другому. Оба набора объединяются в один, а в случае
пересечения предпочтение отдается локальному параметру.
Исполняемые таблицы
Если файл, содержащий таблицу косвенных назначений, является испол-
няемым. он считается сценарием, динамически генерирующим информацию
об автоматическом монтировании Программа-автомонт ировшик не читает
таблицу в текстовом виде, а исполняет сценарий, передавая ему аргумент
(называемый ‘ключом’), в котором указывается, к какому подкаталогу
пользователь пытается получить доступ. Сценарий отвечает за вывод соот-
ветствующей записи таблицы. Если полученный ключ неверен, сценарий
просто завершается, ничего не отображая.
Данная методика очень удобна и позволяет компенсировать многочис-
ленные недостатки довольно странной системы конфигурирования программы
automount. По сути, она дает возможность создать единый для всей
организации конфигурационный файл произвольного формата. Можно на-
писать несложный сценарии на Perl, декодирующий глобальные конфигура-
ционные параметры на каждом компьютере.
Сценарии автоматического монтирования запускаются динамически,
поэтому нет необходимости после каждого изменения распространять главный
конфигурационный файл или преобразовывать его в формат программы
automount. Этот файл может постоянно находиться на сервере NFS.
Программа automount и дублирующиеся файловые системы
В некоторых случаях доступные только для чтения файловые системы
(например, /usr/man) могут быть идентичными на нескольких серверах.
534
Чость II. Робота в сетях
В этой ситуации можно сообщить программе automount о нескольких
потенциальных источниках данных. Она выберет сервер, основываясь на
собственном представлении о том. какой из них отвечает быстрее других.
Прн этом учитываются сетевые адреса, версии протокола NFS, а также время
ответа на первоначальный запрос
Дублирующиеся файловые системы должны быть доступными только для
чтения, хотя программа automount этого не требует Просто она не способна
синхронизировать операции записи в группе серверов, поэтому редактируемые
файловые системы полностью дублировать невозможно.
Дублирующиеся файловые системы должны быть абсолютно идентичны-
ми. В противном случае при замене файловой системы пользователи начнут
волноваться и вести себя непредсказуемо.
В Solaris npoipaMMa automount в случае возникновения проблемы может
свободно переключаться от одного сервера дублирующейся файловой системы
к другому. Это подразумевает монтирование файловой системы только для
чтения, но. по слухам, файловые системы с возможностью записи обраба-
тываются правильнее, чем об этом говорит документация Правда, при
переключении серверов все равно происходит зависание программ, которые
ссылаются на файлы, открытые для записи. Это еше одна из причин, по
которой дублирующиеся файловые системы, доступные в режиме чтения-за-
писи, практически бесполезны.
Как уже было сказано, программа automount выбирает серверы на
основании собственных критериев эффективности и доступности. но можно
назначить им явные приоритеты Чем выше номер, тем ниже приоритет. По
умолчанию установлен приоритет 0. обозначающий легкодоступный сервер.
Файл auto.direct. который определяет каталоги /usr/man и /cs/tools как
дублирующиеся файловые системы, будет выглядеть так:
/usr/man -го chimchrm:/usr/share/man band(l):/usr/man
/сз/cools -го anchor,band:/cs/cools
Обратите внимание на то, что имена серверов можно указывать вместе,
если путь к искомой файловой системе в них одинаковый. Выражение (1)
после имени сервера band в первой строке задает приоритет этого сервера
по отношению к файловой системе /usr/man.
Автоматическое выполнение программы automount
Вместо того чтобы указывать все возможные точки монтирования в
таблицах прямых и косвенных назначении, можно рассказать программе
automount немного о принципах именования файловых систем и дать ей
возможность действовать самостоятельно. Ключевым моментом данного
подхода является возможность обратиться к демону mountd. выполняющемуся
на удаленном сервере, и узнать у него, какие файловые системы экспорти-
руются этим сервером.
Есть несколько способов соответствующим образом сконфшурировать
программу automount. Самый простой из них — воспользоваться опцией
монтирования -hosts. Если указать эту опцию в качестве имени таблицы
в файле главной таблицы назначений, программа automount закрепит экспор-
тируемые файловые системы удаленного компьютера за указанным каталогом:
/net -hosts -nosvxd,soft
Глово 17. Сетевоя файловая система
535
Например, если машина chimchim экспортирует каталог /usr/share/man,
он будет доступен через ссылку /net/chimchim/usr/share/maa.
Заранее определить все возможные узлы, с которых монтируются
файловые системы, невозможно Вместо этого программа automount ожидает,
пока не будет сделана ссылка на отдельный подкаталог, после чего монтирует
соответствующую файловую систему с запрашиваемого узла.
Аналогичный эффект достигается, если указать метасимволы * и & в
таблице косвенных назначений Кроме того, существует ряд макроконстант,
заменяющих имя текущего узла, тип архитектуры и т.д. Подробности можно
узнать на man-страниие aulomount( i М).
Особенности Red Hot Linux
В системе Red Hat имеется собственная независимая реализация про-
граммы automount, которая несколько отличается от версии компании Sun
В основном изменения затрагивают имена команд и файлов
В Red Hat программа automount — это демон, действительно монтирую-
щий и демонтирующий удаленные файловые системы. Он занимает ту же
нишу, что и демон automountd в других системах, н обычно не требует запуска
вручную
Программа, выполняемая для закрепления изменений в главной таблице
назначений, в Red Hat называется /etc/re.d/init.d/autofs (в других системах
это сама automount). Она принимает аргументы stop, start, reload и status;
нужный нам аргумент — естественно, reload.
Стандартная главная таблица назначений хранится в файле /etc/auto.mas-
ter. Ее формат, а также формат таблицы косвенных назначений, были описаны
выше В документации этим таблицам посвяшены man-страницы auto.mas-
ler(5) и autofs(5) Во втором случае будьте внимательны: на тап-страниие
autofs(8) описан формат команды autofs.
Таблицы прямых назначений в Red Hat не поддерживаются.
17.8.	Прогромма amd: более совершенный
автомонтировщик
Программа amd олицетворяет собой дальнейшее развитие концепции
автоматического монтирования Она стала в некотором роде сиротой, когда
ее автор Джан-Саймон Пендри Перес г«ь. сопровождать се В настоящее время
разработку программы предо гжаег Эрсц Задок (Erez Zadok) из Колумбийского
университета, сделав ее компонентом пакета am-utils Соответствующий
Web-адрес таков:
http://www.cs.columbia.edu/'ezk/am-uiils
Программа amd выгодно отличается от конкурентов следующими особен-
ностями.
• Она посылает удаленным серверам через постоянные промежутки време-
ни запросы типа “оставайся на связи" и ведет список доступных серверов
На основании этой информации происходят монтирование, демонтиро-
вание и замена файловых систем. Если какой-то сервер зависнет, при
последующих попытках доступа к файловой системе будет возвращаться
сообщение об ошибке “operation would block” (операция приведет к
блокировке), предотвращающее зависание программы
536
Чость II Робота в сетях
•	В amd нет патентованного исходного кода; эта программа перенесена
более чем на двадцать версий UNIX.
•	Программа amd реализует ряд видов монтирования, которые не поддер-
живаются утилитой automount г например, монтирование ^объединения"
каталогов)
•	В дистрибутив amd входит команда amq. позволяющая отслеживать статус
программы amd и посылать ей советы и команды (например, запросы на
принудительное демонтирование)
•	Синтаксис таблиц назначений amd более стандартизирован, чем v
программы automount Для всех компьютеров организации можно исполь-
зовать один файл, распространяемый посредством программы rdisi или
rsync.
•	Программа amd основана па следующей концепции, любой сервер имеет
одну или несколько файловых систем, каждая из которых содержит один
или более томов (связных совокупностей файлов). Это позволяет
упростить обработку подкаталогов по сравнению с программой aulomount
Таблицы назначений программы amd
Формат таблиц назначений програхшы amd исключительно гибок и
позволяет использовать на нескольких компьютерах общий файл конфигура-
ции. Элементы таблицы могут содержать условные операторы, предназначен-
ные для активизации таблицы только в конкретных случаях (например, на
заданном компьютере или при определенном типе архитектуры) В условных
операторах применяются встроенные переменные (селекторы). которые
заполняются различной информацией о среде выполнения программы amd
Наиболее часто используемые селекторы перечислены в табл 17.10
Тоблицо 17 10. Селекторы прогроммы omd
	Зкомьн-	_	1
arch	Архитектура текущего компьютера
aur.odir	Каталог по умолчанию, и котором монтируются файловые системы
byte	Порядок следования байтов для данною компьютера (прямой или обратный)
cluster	Имя локального кластера компьютеров, го умолчанию — aomain
domain	Имя локального домена N1S
host	Имя локального компьютера
host.d	Имя компьютера, объединенное с именем локального домена DNS
karch	Архитектура ядра (по умолчанию — значение селектора arch)
key	Имя используемого тома
wap	Имя используемой таблицы монтирования
network	Имя сети или адрес любого сетевого интерфейса
os	Операционная система
osver	Версия операционной системы
Ниже представлен образен таблицы, сообщающей программе amd о двух
файловых системах- /usr/man и /cs/tools Для каждой из них имеется два
Глово 17 Сетевой фойповоя системо
537
набора опций. Первый определяет параметры монтирования файловой
системы на том компьютере, где она реально находится, а второй залает
параметры монтирования по сети:
/default opts:~rw,soft,timeo=10, xetrans=5
usr/man	host“=chimchini; type:“Ufs;dev; =/dev/sdlf \
host!=chimchim;rhost=chimchim;rfs:=/5{key};\
type-nfs;fs:-S(autodir)/S{key}
cs/tools host—anchor; type: =ufs;dev ;“/dev/sd3c \
host!“anchor;rhost=anchcr;rfs:=/${ key};\
type=nfs;fs:-S'autodir}/S(key}
Элементы вида имя: -значение определяют различные атрибуты монтиро-
вания. Например, первая строка устанавливает, что по умолчанию принима-
ются такие параметры, rw,sof t, timeo^lO, recrans=5. Элементы вида
и мя== значение или имя \ =значение — это условные операторы: следующие за
ними элементы используются только в том случае, если условный оператор
имеет значение “истинно” Записи вила ${autodir} и $(кеу} предназна-
чены для вставки значения соответствующего селектора.
Предложение /default залает значения по умолчанию, которые при-
меняются ко всем элементам таблицы назначений, если не отменяются явным
образом. Различные опции описаны в табл. 17.11
Тоблица 17.11. Опции таблиц нозночений программы omd
Опция	Описание
rhost	Удаленный компьютер, на котором находится том
rfs	Имя удаленной файловой системы
type	Тип монтирования, обычно nfs или ufs (локальный диск)
fs	Локальная точка монтирования
opts	Параметры монтирования
adoopts	Опции, добавляемые к заданным	по умолчанию
reinop is Опции, применяемые в том случае, когда сервер нс является
локальным
Запуск программы amd
Выполняющаяся копия программы amd управляет одним каталогом
виртуальной файловой системы, в котором происходят все операции автома-
тического монтирования Имя каталога и файл таблзщы назначений, где
указано, что именно монтировать, задаются в командной строке.
Программу,’ amd можно запустить посредством такого сценария:
# ! Zbin/csh -f
cd /usr/local/etc/amd
exec /usr/local/bin/amd -x fatal, error, user -r -1 syslog -a /tmp_rnnt
/amd amd.master.map >S /dev/console
Опции, использованные в этом сценарии, описаны в табл. 17.12.
538
Чость 11. Робото в сетях
Таблица 17.12. Опции командной строки cmd
Опция ।	_____Описание, 
-	х	Задает параметры регистрации сообщений на время работы
программы
-	г	Задает подключение уже смонтированных файловых систем
-	1	Задает файл регистрации или систему Syslog для регистрации
сообщений об ошибках
-	а	Задает альтернативное расположение точек монтирования*
/amd	Имя виртуального каталога (для автоматического монтирова-
ния)
amd.roaster .тар Файл таблицы назначений, содержащий опции монтирования
По умолчанию — /а.
Когда пользователь обращается к одной из файловых систем, определен-
ных в таблице назначений amd, программа монтирует эту файловую систему
и контролирует ее последующее использование. Если в течение определенного
периода времени (обычно от 5 до 15 минут) файловая система остается
незадействованной. программа amd демонтирует ее до нового обращения.
Статус смонтированных файловых систем можно узнать с помощью
команды amq.
Останов программы amd
Программу amd нужно останавливать аккуратно, чтобы у иее была
возможность “выпутаться” из структуры файловой системы. Корректный
способ сделать это — послать программе сигнал TERM.
17 9. Рекомендуемая литература
•	Callaghan, Breni. NFS Illustrated. Addison-Wesley. 1999.
•	Pendry, Jan-Simon, and Nick Williams. “AMD: The 4.4BSD Automounter
Reference Manual." 4.4BSD System Manager’s Manual, Usenix and 0‘Reillv.
1994,
•	Stem, Hal, Mike Eisler, and Ricardo Labiaga. Managing NFS and NIS. Second
Edition. Sebastopol' O'Reilly & Associates. 2001.
В табл. 17.13 перечислены различные документы RFC, посвященные
протоколу NFS и его расширениям.
Таблица 17.13. Документы RFC, связанные с протоколом NFS
RFC	Название	Автор	Дата
1094	Network File System Protocol Specification	Sun Microsystems	Mar 1989
1813	NFS Version 3 Protocol Specification	B. Callaghan et al.	Jun 1995
2054	WebNFS Client Specification	B. Callaghan	Oct 1996
2055	WebNFS Server Specification	B. Callaghan	Oct 1996
2224	NFS URL Scheme	B. Callaghan	Oct 1997
2623	NFS Version 2 and Version 3 Security Issues	M. Eisler	Jun 1999
2624	NFS Version 4 Design Considerations	S. Shepler	Jun 1999
Глово 17. Сетевоя файловой система
539
7 Q Совместное использование
» системных файлов
Нормально функционирующая система зависит от десятков, а иногда
даже сотен файлов конфигурации, каждый из которых должен содержать
корректные данные. Умножьте количество конфигурационных файлов, имею-
щихся на одном компьютере, на число машин, работающих в сети, и вы
получите тысячи файлов — слишком много, чтобы управлять ими вручную.
С административной точки зрения в реальном мире многие компьютеры
схожи друз с другом Вместо того чтобы редактировать текстовые файлы на
каждом компьютере, гораздо эффективнее будет объединить компьютеры в
группы, совместно использующие информацию о конфигурации. Это можно
сделать несколькими способами
Простейший из них заключается в хранении главной копии каждого
конфигурационного файла в каком-то одном месте и предоставлении ее
членам группы при каждом изменении. Преимуществом такого решения
является простота и доступность на любой UNIX-платформе.
Другой подход — удаление всех текстовых файлов и выдача каждому
компьютеру информации о его конфигурации с центрального сервера. Делать
это сложнее, чем просто копировать файлы, но зато попутно решаются
некоторые другие пробами Например, клиенты в любом случае будут
получать исправленные версии файлов, даже если во время внесения
(вменений машина-клиент была отключена. Кроме того, получать информа-
цию с сервера в некоторых случаях можно быстрее, чем из файла (это зависит
от быстродействия локального диска и объема кэширования, выполняемого
сервером). С другой стороны, отказ сервера может привести к зависанию
всей сети.
Имели место попытки разработать административные базы данных для
бо 1ьших сетей, в результате чего были созданы интересные системы,
к сожалению. ни один из современных продуктов не кажется нам безупреч-
ным по своей идеологии Некоторые нз них просты, но не отличаются
достаточной степенью безопасности и потенциального расширения. Другие
обладают хорошими функциональными возможностями, но чересчур тяжело-
весны. Третьи выглядят многообещающе, но пока что находятся на начальном
540
Чость II Роботе в сетях
этапе своего развития Всем этим системам присуши ограничения, которые
могут помешать организовать и настроить сеть так. как хочется администра-
тору.
В настоящей главе мы рассмотрим некоторые базовые методики синхро-
низации файлов в сети, а затем поговорим о двух наиболее широко
используемых административных СУБД (N1S и NIS+) и одной относительно
новой системе, которая способна завоевать широкую популярность в
ближайшие несколько лет (LDAP).
18 1. Предмет совместного использования
В UNIX-системе имеется много файлов конфигурации, но совместно
использоваться несколькими компьютерами могут далеко не все из них.
Наиболее распространенные совместно используемые файлы перечислены в
табл. 18.1.
Тоблицо 18.1. Системные фойлы которые обычно используются совместно
Имя файле	Назначение
/etc/passwd /etc/shadow1 /etc/group /etc/hosts /etc/networks1 /etc/services /etc/protocols /etc/ethers1 /etc/maU/a liases /etc/rpc /etc/netgroup1 /etc/prtoicap /etc/termcap	База данных с информацией о пользовательских учетных записях Теневой файл паролей Определения UNIX-групп Соответствия между именами компьютеров и их JP-адресами Соответствия между именами сетей и их 1Р-адрссами Перечень номеров портов для основных сетевых сервисов Соответствия между символьными именами и номерами протоколов Соответствия между именами компьютеров и Ethemet-адресами Псевдонимы электронной почты Перечень идентификаторов RPC-сервисов Определения групп компьютеров, пользователей и сетей База данных с информацией о принтере База данных с информацией о типе терминала
Используется не во всех системах
Большинство серверных систем сконфигурировано на работу только с
этими файлами. В некоторых случаях возможно распространение по сети еше
нескольких файлов, но поскольку стандартное системное программное
обеспечение не будет обращаться к ним автоматически, эта особенность
наиболее полезна для совместного использования локальных файлов.
Доступ к файлам, перечисленным в табл. 18.1, обычно осуществляется
через функции, определенные в стандартной библиотеке языка С. Например,
поиск в файле /etc/passwd производится с помощью функций getpwuid(),
getpwnam() и getpweut() Они берут на себя открытие, чтение н синтаксический
анализ файла passwd. освобождая от этой задачи программы пользовательского
уровня.
Так как лишь немногие программы обращаются к вышеперечисленным
конфигурационным файлам напрямую, перестроить систему на использование
сетевой базы данных относительно несложно. При корректировке библиотечных
Глово 18. Совместное использовоние системных фойпов
541
функции большинство программ-клиентов модифицируется автоматически.
Даже программное обеспечение, полученное бесплатно нои от третьих фирм,
обычно работает корректно с обновленной версией библиотеки.
18 2. Копирование файлов
При обслуживании сети университета штата Колорадо мы распространяем
файлы методом грубой силы. Это решение не из самых элегантных, но оно
применимо на всех типах компьютеров и отличается простотой настройки и
сопровождения. Оно также надежно, поскольку число перекрестных зависи-
мостей между компьютерами минимально.
В руководствах (в соответствии с общими принципами UNIX-культуры)
предполагается, что администраторы будут использовать систему типа NIS
или NIS4 , если таковая имеется Однако если в организации не решаются
сложные задачи, то и в сложных решениях нет необходимости. Иногда самое
“лобовое”, самое тривиальное решение оказывается наилучшим.
Наша организация состоит из нескольких связанных, но независимых
“участков”. Совместно используется лишь незначительная часть администра-
тивных данных. В нашей схеме распространения файлов каждый участок
имеет один-два сервера, где хранятся оригиналы его системных файлов. Это
разновидность среды, в которой принцип последовательного копирования
файлов работает хорошо, поскольку задача сводится к простой перекачке
данных, без подгонки их под условия конкретных архитектур иди сетей.
Системы копирования файлов могут работать по модели принудительном
рассылки файлов или по модели запроса В первом случае главный сервер
периодически рассылает самые свежие версии файлов каждому клиенту
независимо от желания последнего. Файлы могу! копироваться явно при
каждом изменении или просто регулярно отправляться согласно графику (при
этом, вероятно, одни файлы будут обновляться чаше других).
Преимущество модели принудительной рассылки заключается в том. что
система распространения работает централизованно, на одном компьютере.
Файлы, списки клиензов. откорректированные сценарии и расписания
хранятся в одном месте, что делает эту схему простой в управлении. Есть у
Fiee и недостаток: каждый клиент должен позволять главному серверу
модифицировать свои системные файлы, что не всегда приемлемо с точки
зрения безопасности.
В модели рассылки по запросу каждый клиент отвечает за самообновление
с помощью данных, запрашиваемых с сервера. Это менее централизованный
способ распространения файлов, но он более гибок н более безопасен.
Система копирования особенно привлекательна при совместном использова-
нии данных с пересечением ими различного рода границ, поскольку вовсе
не обязательно, чтобы главный компьютер и машина-клиент находились в
одном “политическом” регионе.
Утилита rdist: принудительная рассылка
В большинстве случаев нанлучшим способом распространения файлов с
центрального сервера считается использование утилиты rdist. В ней есть
сходство с программой make: вначале пользователь в текстовом редакторе
составляет описание (спецификацию) файлов, подлежащих рассылке, а затем
утилита rdist осуществляет операции копирования в соответствии с описанием
Утилита копирует файлы, если их локальные копии устарели, поэтому в
542
Часть II. Робато в сетях
спецификации можно задать копирование всех файлов, а утилита rdisi
самостоятельно определит, какие из них подлежат этой операции
Утилита rdist сохраняет информацию о владельце, группе, правах доступа
и времени модификации фай за. Когда утилита обновляет существующий
файл, то перед инсталляцией нового она удаляет старую версию. Это
позволяет использовать данную программу для пересылки исполняемых
файлов, которые могут оказаться запущенными во время обновления’
К сожалению, утилита rdist имеет ряд слабых мест с точки зрения
безопасности. Она работает поверх программы rsti и использует ее средства
аутентификации для получения доступа к удаленным системам. При этом
доступ от имени суперпользователя возможен с любого узла, указанного в
файле /.rhosts удаленной системы. В прошлом такая схема еше была
приемлема в изолированных или матодоступных сетях. Сегодня, учитывая
распространение Internet, она слишком опасна. L-’сли один компьютер
взломан, все остальные компьютеры, слепо доверяющие ему, также становятся
небезопасными.
Поскольку распространяются административные файлы, например
/etc/passwd. понятно, что привилегированный доступ к главному сервер}
может быть использован для получения аналогичного доступа к клиентским
машинам. Но проблема не в этом, а в том. что, выполняя демон rlogind
(сервер для программы rsh. а также rlogin и гср), клиенты мопт подвергаться
другим видам атак.
В общем случае наш сокет таков: откажитесь от демона rlogind. Гели без
утилиты rdist нечьзя обойтись, нужно, по крайней мере, использовать пакет
tcpd. который нозволи*! задать, каким узлам разрешен доступ к демону rlogind
каждого конкретного клиента. Этот пакет можно получить по адресу
ftp.porcupine.org, дополни тельная информация о нем приведена в парагра-
фе 21.7.
Утилита rdist может выполняться не только от имеют суперпользователя,
но демон rlogind нее равно должен работать на каждом удаленном узле. Кроме
того, в данной конфигурации требуется, чтобы на каждом клиенте была
программа, принимающая копируемые файлы и инсталлирующая их в
требуемые каталоги. Данная операция доступна только пользователю root. Но
все равно, ничего не мешает непривилегированному взломщику передать в
удаленную систему фальсифицированный файл /etc/passwd Так что мы не
считаем, что возможность выполнения утилиты rdist от имени непрнкнлеги
рованного пользователя повышает безопасность системы
Утилита rdist в Red Hat и FreeBSD позволяет заменять программ} rsh
любой другой, понимающей аналогичный синтаксис. Гаковой може1 быть
программа ssh. имеющая два основных преимущества. Во-первых. она может
использовать шифрование с открытым ключом для проверки подлинности
сигнатуры главного узла. Во-вторых, она шифрует весь диалог. не давая
возможности шпионам, прослушивающим сеть, получать конин системных
файлов. Недостаток заключается в том. что удаленные серверы ssh должны
выполняться в режиме, позволяющем не указывать пароль, а это менее
безопасный режим, чем требуется в обычных условиях. Подробнее о демоне
sshd и его режимах аутентификации рассказывается в параграфе 21.8.
Хотя старая версия удаляется из пространства имен файловой системы, она продолжает
существовать до гех пор, пока не будут освобождены все ссылки на нее. О данном эффекте
следует также помнить при работе с журнальными файлами. Подробнее об этом рассказы
вастся в параграфе 11-1 -
Глава 18 Совместное использование системных фойлов
543
Итак, разобравшись с тем, какую угрозу таит в себе утилита rdist.
рассмотрим подробно, как она функционирует. Как и программа make,
утилита rdist ишет в текущем каталоге управляющий файл (distfile или Distfile).
Команда rdist -f файл задает путевое имя управляющего файла явно.
В качестве разделителей в этом файле используются знаки табуляции,
пробелы и признаки новой строки. Комментарии предваряются знаком
решетки (#).
Тело управляющего файла состоит из операторов, имеющих следующий
синтаксис:
метка: путевыеимена -> адресаты команды
Поле метка является именем данного оператора. Из командной строки
можно дать команду rdist метка, которая обеспечит рассылку только тех
файлов, что описаны в указанном операторе.
Поля путевые_имена и адресаты содержат соответственно список файлов,
подлежащих копированию, и список компьютеров, куда их нужно переслать.
Если в списке больше одного элемента, его нужно заключить в круглые
скобки, а элементы — разделить пробелами. Список путевые_имена может
включать метасимволы, допустимые в интерпретаторе команд (например,
/usr/lib/* или /usr/man/man[123]). Приемлема также запись 'пользователь. но
соответствующие ей значения на маш ине-отправителе и машине-адресате
могут не совпадать.
По умолчанию утилита rdist копирует файлы и каталоги, перечисленные
в списке путевые имена, в эквивалентные каталоги иа каждой маши не-адре-
сате. Этот порядок можно изменить, указав последовательность команды.
Каждую команду следует завершать точкой с запятой.
Можно использовать такие команды:
install опции [каталог-адресат];
notify список_имен;
except список_путей;
exceptpat список_шаСлонов;
special [список_путей’ строка;
Команда install задает опции, влияющие на то, как утилита rdist
копирует файлы. Опции, как правило, используются для управления процес-
сом обработки символических ссылок, проверки правильности применяемого
в утилите алгоритма сравнения файлов, а также для контроля над процедурой
обработки файлов, отсутствующих в исходном дереве каталогов В каждой
системе эти опции задаются по-своему, и мы не будем здесь вдаваться в
детали.
Имя команды install слегка вводит в заблуждение, так как файлы
копируются вне зависимости от того, присутствует эта команда или нет.
Опции задаются так. как они задавались бы в командной строке утилиты
rdist, но при включении в управляющий файл они действуют только на
совокупность файлов, указанную в данном операторе.
Необязательный аргумент каталог-адресат задает каталог, в который
инсталлируются файлы на машин ах-адресатах По умолчанию утилита rdist
использует исходные путевые имена.
В команде notify в качестве аргумента задается список адресок
электронной почты. При каждом обновлении очередного файла утилита rdist
посылает по этим адресам почтовое сообщение. Имя маш ины-адресата
добавляется ко всем адресам, не содержащим знак Например, при выдаче
544
Часть II. Робота в сетях
списка файлов, откорректированных на компьютере anchor, компьютер pete
превратится в pete@anchor.
Команды except и except_pat служат для удаления путевых имен из
списка файлов, подлежащих копированию. Аргументы команды except
трактуются буквально, а аргументы команды except_pat интерпретируются
как регулярные выражения. Эти команды весьма полезны, поскольку утилита
rdist, как и make, позволяет задавать в начале управляющего файла
макроконстанты. Можно использовать один список с несколькими операто-
рами. указывая для каждого компьютера только те имена, которые нужно
удалить или добавить.
Команда special запускает интерпретатор sh (аргумент строка которого
нужно брать в кавычки) на всех удаленных компьютерах. Если есть аргумент
список_путей. утилита rdist запускает интерпретатор один раз после копиро-
вания каждого из указанных файлов. В противном случае интерпретатор
активизируется после копирования каждого файла в пределах текущего
оператора. К сожалению, интерпретатор нельзя запустить один раз после
копирования всех файлов.
Приведем пример файла Distfilc:
SYS_FILES - (/etc/passwd /etc/group /etc/mail/aliases)
GET_ALL = (chimchim lollipop barkadon)
GET_SOME * (whammo spiff)
all: S(SYSFILES) -> $(GET_ALLJ
notify barb;
special /ecc/mail/aliases *,/usr/bin/newaliases";
some: S{5YS_FILESj -> ${GET_SOMEJ
except /etc/mail/aliases;
notify eddiePspiff;
В данной конфигурации три указанных системных файла копируются на
компьютеры chi meh im, lollipop и barkadon. а по адресу barb@adpecam посылается
сообщение с описанием всех изменений и замеченных ошибок. После
копирования файла /etc/mail/aliases утилита rdist запускает на каждой
машине-адресате программу newallases. На компьютеры whammo и spiff
копируются только два файла, а отчет отправляется по адресу eddie@spiB*.
Программа ncwaliases на этих двух компьютерах не запускается.
Подробнее о программе newaliases рассказывается в параграфе 19.4.
Программа rsync более безопасная рассылка файлов
Программа rsync. написанная Эндрю Триджеллом (Andrew Tridgell) и
Полом Макеррасом (Paul Mackerras), близка по духу утилите rdist, но
по-другому реализована. Она напоминает улучшенную версию программы
гер, пытающуюся сохранить ссылки, информацию о времени модификации
и правах доступа Программа rsync более эффективна, чем rdist, поскольку
способна анализировать отдельные файлы и пытается передавать только
различия между версиями.
Программа rsync доступна по адресу rsync.samba.org.
С нашей точки зрения, основным преимуществом программы rsync
является то, что на принимающих компьютерах серверный процесс может
запускаться из демона inetd. Сервер (на самом деле это та же программа
Глава 18. Совместное использовоние системных файлов
545
rsync. но работающая в другом режиме; она должна быть инсталлирована как
на главном компьютере, так и на клиентах) допускает гибкую настройку он
может предоставлять удаленный доступ лишь к заданному набору каталогов
и требовать, чтобы главный компьютер подтвердил свою подлинность
паролем. Поскольку доступ на уровне программы rsh не требуется, можно
организовать распространение системных файлов посредством программы
rsync, не жертвуя безопасностью. (Тем не менее, программа rsync разрешает
пользоваться программами rsh и ssh. а не серверным процессом, работающим
под управлением демоиа Inetd.)
Так как у програьгмы rsync нет конфигурационного файла на отправляю-
щей стороне, она должна запускаться многократно для передачи набора
файлов нескольким узлам. Например, команда
#	гsyne -gopt —password-file=/ete/rsync.pwd /etc/passwd
lollipop:./sysfiles
посылает файл /etc/passwd на компьютер lollipop. Флаг -gopt указывает на
необходимость сохранения прав доступа, идентификаторов принадлежности
и времени модификации файла. Два двоеточия в выражении lollipop::/sysfi!es
заставляют программу rsync связаться с удаленным сервером rsync непосред-
ственно через порт 873, ие используя для этого программу rsh Для
аутентификации соединения берется пароль из файла /etc/rsync.pwd .
Чтобы сконфигурировать сервер rsync на каждом клиентском компьютере
(т.е. на каждом компьютере, принимающем файлы; с точки зрения самой
программы такие “клиенты”, скорее, являются серверами), требуется выпол-
нить несколько действий:
•	добавить номер порта программы rsync в файл /etc/services;
•	добавить строку вызова сервера (rsync --daemon} в файл /etc/inetd. con Г;
•	сохранить аутентификационные пароли в файле /etc/rsyncd.secrets;
•	сконфигурировать сервер в файле /etc/rsyncd.conf.
Записи в файлах services и inetd.conf достаточно просты. В первом
случае это
rsync вТЗ/tcp
во втором —
rsync stream tcp nowait root /local/bin/rsync rsyncd —daemon
Если используется пакет tcpd, можно сконфигурировать его таким
образом, чтобы блокировать доступ всем узлам, за исключением того, который
будет распространять системные файлы. Аналогичную установку можно
сделать и в файле rsyncd.conf. никогда не помешает воздвигнуть несколько
барьеров.
Файл rsyncd.secrets должен содержать единственную запись:
root:пароль
Необходимо, чтобы пароль, используемый программой rsync, отличался
от реального пароля суперпользователя Поскольку пароль отображается в
Пароль не посылается по сети в текстовом виде, но сами передаваемые фай ты не
шифруются. С другой стороны, если в качестве транспортного средства используется
программа ssh (rsync -gopt -е ssh /etc/passwd /etc/shadow lollipop:/sysfiles — обратите внима-
ние на одинарное двоеточие), шифруется все соединение, но демон sshd придется сконфи-
гурировать так, чтобы он не запрашивал пароль Воистину, мы сами выбираем свою казнь!
546
Часть II. Робота в сетях
незашифрованном виде, файд должен быть доступен для чтения только
пользователю root.
Наконец, следует модифицировать файл /etc/rsyncd.conr, который сооб-
щает серверу rsync (принимающей стороне) о том. как себя вести. Разумная
конфигурация выглядит примерно так:
(sysfiles]
path - /etc
secrets file = /etc/rsyncd.secrets
read only = false
uid = root
gid - root:
hosts allow = главный^сервер
Существует масса других опций, но установки по умолчанию вполне
приемлемы. В данной конфигурации все операции локализованы в каталоге
/etc, а доступ разрешен только указанному узлу.
Программа rsync входит в дистрибутив Red Hat. Исходный код (общий
для всех систем) можно загрузить с узла rsync.samba.org.
Система expect: рассылка файлов по запросу
Существует несколько способов реализации системы рассылки файлов
по запросу. Один из них. который нам нравится н который, оказывается,
полезен и дтя решения других задач, заключается в том. чтобы сделать
системные файлы доступными на центральном сервере по протоколу FTP и
осуществлять последующую их выборку и инсталляцию с помощью системы
expect.
Подробнее о протоколе FFP речь пойдет в параграфе 22.6.
Система expect представляет собой набор расширений языка Tel (Tool
Command Language — инструментальный командный язык), разработанного
Джоном Оусгерхаутом (John Ousterhout). Эти расширения позволяют писать
управляющие сценарии для интерактивных программ. Автором системы expect
является Дон Л ибис (Don Libes) из Национального института стандартов и
технологий (National institute of Standards and Technology, NIST). Система
expect отличается от обычного языка сценариев (например, от принятого в
большинстве интерпретаторов команд) тем. что обеспечивает пошаговое
управление подпроцессами. Можно проверять результат каждой операции и
определять, какие входные данные необходимо посылать дальше. Кроме того,
язык expect устойчив к недружелюбным действиям, которые способна
предпринять программа, считающая, что работает с реальным терминалом.
Тс1 сам по себе — это функционально полный язык сценариев. Фор-
мально сценарии expect являются просто сценариями Tel, в которых исполь-
зуются дополнительные команды, определенные в расширениях expect. Тем
не менее для написания простейших сценариев expect нс требуется глубокое
знание языка Tel.
Язык Тс! синтаксически прост. Большинство команд задается аналогично
командам системного интерпретатора: команда и ее аргументы просто
разделяются пробелами. Фигурные скобки объединятот групповые элементы
в отдельные ‘‘слова” и позволяют продлевать операторы на несколько строк.
В качестве разделителя команд используется точка с запятой; в конце строки
и перед закрывающей фигурной скобкой разделитель не обязателен.
Глово 18. Совместное мспользовоние системных фойлов
547
Вот основные команды системы expect;
е spawn — запускает подпроцесс;
е send — посылает подпроцессу входную информацию;
• expect — выполняет действие в зависимости от выходной информации
подпроцесса.
Четвертая команда, interact, также может оказаться полезной, если
нужно, чтобы система expect выполнила часть задачи, а затем передала
управление пользовательской программе.
Прежде чем рассматривать команды по отдельности, разберем простой
пример. Следующий сценарий пересылает с компьютера сервер (посредством
программы ftp) файл /etc/passwd:
spawn /usr/bin/Etp сервер
while 1 ( expect ч
’’Name*: "	(send ”клиент\г"}
"Password; " {send "клиентсгсий_пароль\г" }
”ftp>	{break}
"failed”	{send_user	’’Can't	log	in.\r“;	exit	1)
timeout	(send_user	"Timeout	problem.\r";	exit 2}
}}
send "led /etc\r"
expect "ftp> " {send "cd pub/sysfiles\r"}
expect "ftp> " {send "get passwd\r"}
expect "ftp> " {send ”quic\r’‘,- send_user "\r"}
exit 0
Последовательность выполнения операций здесь очевидна. Рассматривае-
мый сценарий сначала запускает команду ftp сервер, а затем ожидает
приглашения на ввод имени и пароля в цикле while (базовая конструкция
языка Тс1). После получения основного приглашения ftp> программа
выходит из цикла while, и в программу ftp подается простая серия команд.
Перед отправкой каждой команды сценарий ожидает, пока завершится
выполнение предыдущей команды; это не строго обязательно, но делает вывод
информации очень удобным.
Начальный цикл регистрации предназначен для решения двух проблем.
Во-первых, производится проверка строки “failed”, позволяющая выявить
ситуацию, когда удаленный компьютер отклоняет указанное имя и пароль и
программа ftp выводит сообщение “Login failed”. Во-вторых, условие timeout
позволяет обнаружить случаи, когда в течение десяти секунд ничего не
происходит, возможно, потому, что сервер отключен. Если возникает одна
из описанных выше ситуаций, сценарий выводит сообщение об ошибке и
завершает свое выполнение.
Данный сценарий предполагает, что после успешного входа в систему
ошибок быть не может; реальные сценарии обычно включают дополнительные
проверки. В этом примере благодаря циклу while для нескольких пересылок
задается одна процедура обработки ошибок. Есть несколько специальных
версий команды expect, предназначенных для решения этой проблемы более
элегантным способом.
Команда send посылает на вход подпроцесса строку, указанную в
качестве аргумента. Прн желании можно явно включить в эту строку символ
возврата каретки (обозначается как \г). Строку без пробелов и специальных
символов не нужно брать в кавычки. Команда send_user аналогична
548
Чость II. Робото в сетях
команде send, за исключением того, что строка записывается в стандартный
выходной поток сценария.
В команде expect в качестве аргументов задаются группы пар шаб-
лон/действие. Если аргументы занимают несколько строк, как в приведенном
выше примере, их следует заключать в фигурные скобки. Каждый аргумент
действие также необходимо брать в фигурные скобки.
Шаблон — это то, что нужно искать в выходной информации команды;
как только появляется эта строка, инициируется соответствующее ей действие.
Понс к по шаблону осуществляется, как правило, в соответствии с синтакси-
сом интерпретатора команд, но можно использовать н регулярные выражения
Действия, указанные для условий timeout и eof. запускаются соответст-
венно после некоторого (задаваемого) периода бездействия и по достижении
конца входного потока.
Исходный код системы expect можно загрузить с узла expeci.nisi.gov.
18.3. NIS: сетевоя информационная служба
Административная база данных NIS (Network Information Service —
сетевая информационная служба) была выпущена в свет компанией Sun в
80-х гг. Сначала она называлась Sun Yellow Pages (Желтые страницы Sun),
но по причинам правового характера ее пришлось переименовать. Команды
NIS до сих пор начинаются с префикса ур. поскольку имя, данное при
рождении, забыть трудно. Многие фирмы купили у Sun лицензию на это
программное обеспечение, что сделало NIS наиболее широко распространен-
ной системой совместного использования файлов.
В начале 90-х компания Sun выпустила новую административную СУБД:
N1S+. Невзирая на сходство названий. NIS и NIS+ не связаны друг с другом.
Система NIS+ гораздо сложнее, чем N1S, и не столь популярна. Подробнее
о ней рассказывается в параграфе 18.4. В табл. 18.2 отражены сведения о
поддержке NIS н NIS+ в наших тестовых системах.
Тоблицо 18 2 Поддержке NIS и NIS+ в олероционных системох
Система	Поддерживает NIS?	Поддерживает NIS+?
Solaris	Да	Да
HP-UX	Да	Да
Red Hat	Да	Нет
FreeBSD	Да	Нет
Единицей совместного использования в NIS является запись, а не файл
Запись обычно соответствует одной строке конфигурационного файла.
Главный сервер хранит авторитетные копии системных файлов, которые
находятся в своих исходных каталогах и имеют текстовый формат. Серверный
процесс делает содержимое этих файлов доступным по сети. Сервер и его
клиенты образуют домен NJS".
Для повышения эффективности поиска файлы подвергаются предвари-
тельной обработке подпрограммами хэширования (обычно это ndbm или ее
Не путайте домены N1S с доменами DNS. Это два абсолютно разных понятия, которые не
имеют между собой ничего общего
Глово 18 Совместное использовоние системных фойлов
549
GN U-эквивалент gdbm). превращаясь в файлы базы данных, называемые
картами. После редактирования файлов на главном сервере необходимо
попросить N1S преобразовать их в хэшированный формат либо с помощью
программы make, либо посредством сценария ypmake (в зависимости от
системы).
Базовые подпрограммы хэширования позволяют связывать с каждой
записью всего один ключ, поэтому' системный файл, возможно, придется
транслировать в несколько карт NIS. Например, файл /etc/passwd преобра-
зуется в две карты: passwd.byname и passwd.byuid Первая применяется для
поиска элементов по имени пользователя, а вторая — для поиска по
идентификатору. Любую из них можно использовать для получения списка
всех элементов файла passwd. Но хэширующие подпрограммы не сохраняют
порядок записей, поэтому нельзя воссоздать точную копию исходного файла
(если только он не был отсортирован).
Служба NIS позволяет тиражировать сетевые карты, размешал их на
нескольких подчиненных серверах. Использование группы серверов помогает
ослаблять нагрузку на главный сервер н поддерживать функционирование
клиентов даже в том случае, когда некоторые серверы недоступны. Если на
главном сервере файл изменился, необходимо разослать соответствующую
NIS-карту на все подчиненные серверы, чтобы на всех серверах были
одинаковые данные. Клиенты не различают главный н подчиненные серверы
В соответствии с традиционной реализацией NIS. в каждой физической
сети необходимо назначать хотя бы один сервер NIS. С целью обнаружения
серверов клиенты посылают широковещательные IP-пакеты, которые не
перенаправляются маршрутизаторами и шлюзами. Для нацеливания клиента
на конкретный сервер можно воспользоваться командой ypset, однако при
первых признаках тревоги клиент попытается обнаружить новый сервер путем
широковещательного запроса Если в клиентской сети нет сервера, это может
вызвать зависание машины-клиента.
Solaris и Red Hat позволяют избежать традиционного широковещательного
способа обнаружения серверов NIS. Подробнее об этом рассказывается в
конце даниого параграфа.
Сетевые группы
Вместе с системой N1S появилось новое понятие, ставшее вскоре весьма
популярным: так называемые сетевые группы. Это совокупности пользовате-
лей. компьютеров и сетей, па которые делается ссылка в системных файлах.
Сетевые группы определяются в файле /etc/netgroup и становятся известными
клиентам сети через NIS-карту.
Формат записи файла netgroup гаков:
имя группы список— членов
Имена членов группы разделяются пробелами или знаками табуляции.
Член группы может, в свою очередь, представляться именем сетевой группы
или триплетом следующего вида:
1имя_компьютера, имя пользователя, имя ломена ЛГТ^)
Каждое пустое поле в триплете — это метасимвол. Так. элемент (boul-
der,,) ссылается на всех пользователей во всех доменах на компьютере
boulder (или на сам компьютер boulder в зависимости от контекста, в котором
используется имя данной сетевой группы). Знак в том или ином поле
5и.)
Чость II. Робото в сетях
свидетельствует об отрицании. Например, элемент (boulder, ) обозначает
компьютер boulder и отсутствие пользователей. Определения групп могут быть
вложенными друг в друга.
Вот простой пример файла /etc/netgroup:
bobcats	(snake,,) (headrest,,)
servers	(anchor,,) (meet,,) (piper,,)	(kirk,,)
anchorclients (xx,,| (watneys,,) (molson,,)
beers	(anchor,,) (anchor-gateway,,)	anchorclients
allhosts	beers bobcats servers
Все эти сетевые группы определены в виде совокупностей компьютеров,
что типично для реальных условий.
Сетевые группы можно использовать в различных файлах, определяющих
права доступа. Например, в файле /etc/exports илн в команде share (в Solaris)
они указывают на то, какие компьютеры имеют право монтировать файловые
системы. Это очень удобно, если файловая система экспортируется на
множество компьютеров и необходимо указывать полностью определенные
доменные имена, потому что длина записи в файле exports часто ограничена
1024 символами.
Вообще говоря, применение сетевых групп — прекрасная идея. Их
использование помогает упростить системные файлы и сделать их более
понятными. Они также дают возможность ввести дополнительный уровень
абстракции, который позволяет для изменения статуса пользователя или
компьютера вносить необходимые изменения в одном файле, а не в
пятнадцати.
Задание приоритетов для источников
административной информации
В большинстве систем информацию о конфигурации можно распростра-
нять несколькими способами. Обычные файлы способна обрабатывать любая
система; кроме того, почти во всех системах реализована поддержка N1S и
обеспечивается возможность поиска имен компьютеров и Internet-адресов
средствами DNS. Поскольку для каждого элемента информации может
существовать несколько потенциальных источников, поставщики систем
обычно предусматривают способ задания источников и порядок их опроса.
В первоначальной реализации NIS некоторые конфигурационные файлы
(в частности, /etc/passwd и /etc/group) должны были “втягивать” в себя
содержимое соответствующих карт NIS. Для этого в сами файлы помешались
особые обозначения. Одинокий символ '+' в начале строки означал включение
всей карты NIS, выражение “+@сетевая группа" задавало включение записей,
относящихся только к указанной группе, а выражение соответствовало
отдельной записи.
У этого подхода никогда не было много сторонников, поэтому в
большинстве систем был введен центральный конфигурационный файл
/etc/nsswitch.conf, позволяющий для каждого типа административной инфор-
мации указывать явный путь поиска. Типичный файл nsswitch.conf выглядит
следующим образом:
passwd: files nis
hosts:	files dns
group:	files
Глово 18 Совместное использовоние системных файлов
551
Каждая строка описывает отдельный тип информации (обычно это
эквивалент одного текстового файла). Возможные константы источников
таковы: nis, nisplus, files, dns и coinpat. Им соответствуют (в порядке
перечисления) следующие источники: NIS, NIS+. обычные текстовые файлы
(без учета специальных обозначений наподобие DNS и обычные файлы
системы NIS. DNS предоставляет информацию только об узлах.
Источники просматриваются слева направо, пока один из них не выдаст
ответ на запрос. В случае показанного выше примера функция gethostbyname()
сначала проверит файл /etc/hosts, и если требуемый узел там не будет указан,
обратится к DNS. В процессе обработки запросов, касающихся UNIX-rpynn.
будет проверяться только файл /etc/group.
При необходимости можно явно указать, как следует поступать при
получении отрицательного ответа на запрос от того или иного источника.
Например, строка
hosts:	ans [NOTFOUND=returnj nisplus
заставляет получать информацию только от DNS, если эта система доступна.
Получение отрицательного ответа от сервера имен приведет к немедленному
завершению запроса (с выдачей кода ошибки), и обращения к NIS+ не
произойдет. Однако служба NIS4- будет задействована, если все серверы имен
окажутся недоступными. В табл. 18.3 перечислены различные условия
проверки ошибок. Каждое из них может быть задано равным return или
continue, что означает соответственно прерывание запроса или переход к
следующему источнику.
Таблица 18.3. Условия проверки ошибок в файле /etc/nsswitch.conf
Условие	Смысл____________________________________________________
unavail	Источник	нс существует	или недоступен
NOTFOUND Источник существует, но нс может ответить на запрос
TRYAGAIN	Источник	существует, но занят
SUCCESS	Источник	смог ответить	на запрос
В каталоге /etc обычно содержится несколько образцов файла nsswitch.conf
(Is /etc/nss*). Прежде чем создавать собственный файл, проверьте, не подойдет
ли один из имеющихся вариантов.
a	FreeBSD еше не поддерживает концепцию центрального файла “пере-
ключения сервисов’’ Приоритет источников данных при поиске узлов может
быть задан в файле /etc/host.conf, который является самолокументируемым.
Специальные обозначения NIS должны включаться в файлы passwd и group
для импорта удаленных карт. Дополнительную информацию можно получить
в разделе 5 интерактивной документации по этим файлам.
Преимущества и недостатки NIS
У системы NIS есть одна хорошая черта: ее могут понять простые
смертные. Работает она аналогично схеме копирования файлов. В большин-
стве случаев администраторам не нужно ничего знать о внутренних форматах
данных NIS. Администрирование осуществляется с помощью привычных
текстовых файлов, и дополнительно требуется изучить всего одну-две новые
процедуры.
552
Чость II. Роботе в сетях
0
Поскольку механизма объединения доменов в системе NIS ие существует,
она годится для управления крупной сетью только при условии, что каждый
входящий в сеть компьютер имеет одну и ту же конфигурацию. Можно
разделить большую сеть на несколько NIS-доменов, но тогда каждый из них
должен администрироваться отдельно.
Если подчиненный сервер в момент изменения карты не работает или
недоступен, находящаяся на нем копия откорректирована не будет. Подчи-
ненные серверы должны периодически опрашивать главный сервер, чтобы
иметь самую последнюю версию всех карт. Хотя в NIS есть базовые средства,
позволяющие это делать, требуемую схему опроса нужно реализовывать с
помощью демона сгоп. Но даже в этом случае существует вероятность того,
что две разные версии одной карты в течение некоторого времени будут
обслуживаться одновременно. При этом клиенты, получая доступ к различ-
ным подчиненным серверам, будут попеременно видеть то одну, то другую
версию.
Более подробная информация о демоне сгоп содержится в главе 9.
Система NIS не безопасна. Любой компьютер сети может выступить в
роли сервера для того или иного домена и распространить среди NIS-клиентов
ложные административные данные. Любой человек может прочесть NIS-карты
и попытаться расшифровать пароли с помощью программы-взломщика, если
в системе есть плохо защищенные учетные записи.
Некоторые серверы NIS пытаются повысить безопасность паролей,
запрещая доступ к карте теневых паролей из непривилегированных портов.
Это благородная мера, но она является очень слабым способом зашиты Те.
кого волнуют проблемы безопасности, не должны использовать N1S.
Схема работы NIS
Файлы данных NIS (а часто и некоторые команды этой системы)
содержатся в одном каталоге, обычно /var/ур. Далее мы будем называть его
“NIS-каталогом” Все NIS-карты хранятся в хэшированном виде в подката-
логе N IS-каталога, соответствующем домену NIS. Точные имена и число карт
зависят от применяемой подпрограммы хэширования. Например, в домене
cssuns могут быть следующие ndbm-файлы для карт файла /etc/passwd:
/var/ур/cssuns/passwd.byname.dir
/var/ур/cssuns/passwd.byname.pag
/var/yp/cssuns/passwd.byuid.di r
/var/ур/cssuns/passwd.byuid.pag
Помните, что для каждого поля, по которому можно произвести поиск
в файле, должна быть создана отдельная карта. Поиск в файле passwd
осуществляется по имени и по идентификатору, поэтому из него получаются
две карты (четыре файла в случае программы ndbm).
Команда makedbm создает NIS-карты из обычных файлов. Ее никогда не
нужно вызывать непосредственно. В большинстве систем файл Makefile в
NIS-каталоге сконфигурирован так, чтобы автоматически генерировать все
распространенные NIS-карты. После модификации системного файла перей-
дите в N1 S-каталог и запустите программу make. Она сверит время
модификации каждого файла с временем модификации карт, полученных из
него, и выполнит команду makedbm для каждой карты, которую необходимо
перестроить.
Глово 18 Совместное использовоние системных фойлов
553
(Л1
В HP-UX вместо программы таке используется команда ypmake
Копирование карт с главного сервера иа подчиненные осуществляется с
помощью команды ypxfr. Данная команда работает по принципу запроса; для
того чтобы она импортировала карты, ее нужно запускать на каждом
подчиненном сервере. Подчиненные серверы время от времени выполняют
команду ypxfr. с тем чтобы проверить, последние ли версии карт находятся
в их распоряжении. Посредством демона сгоп можно управлять периодично-
стью этих проверок.
Стандартная реализация механизма копирования карт не очень эффективна,
поэтому в большинстве систем существует демон ypxfrd, выполняющийся на
главном сервере для ускорения ответов на запросы команды ypxfr. Этот демон
работает в обход стандартного протокола NIS и просто рассылает копии
файлов карт. К сожалению, в разных системах карты хранятся в разных
форматах и имеют неодинаковый порядок следования байтов, поэтому
применение демона ypxfrd чревато возникновением их несовместимости.
Команда yppush используется на главном сервере. Она. по сути, не
пересылает никаких данных, а просто заставляет каждый подчиненный сервер
выполнить команду ypxfr. Команда yppush задается в файле Makefile,
находящемся в NIS-каталоге, и обеспечивает принудительную рассылку
откорректированных карт на подчиненные серверы.
Есть специальная карта ypservers. которая не соответствует ни одному
обычному’ файлу'. Она содержит список всех серверов данного домена и
строится автоматически при его конфигурировании посредством программы
у pin it (о ней будет рассказано далее). Содержимое этой карты изучается всякий
раз, когда главному серверу нужно разослать карты на вспомогательные
серверы.
После начального конфигурирования активными компонентами системы
N1S остаются лишь демоны ypserv и ypbind. Первый работает только на
серверах (и главном, и подчиненных); он принимает запросы от клиентов и
отвечает на них, осуществляя понск информации в хэш-файлах карт.
Демон ypbind работает на всех компьютерах NIS-ломепа. включая серверы.
Функции библиотеки языка С обращаются к локальному демону ypbind всяким
раз, когда им нужно ответить на административный запрос (при условии,
что это разрешено файлом /etc/nsswitch.conf). Демон ypbind находит в
соответствующем домене демон ypserv и возвращает сведения о нем библио-
течной функции, которая затем обращается непосредственно к серверу.
Механизм обработки запроса изображен на рис. А.
Сторона клиента
Г ПрийладНая^!	I	I
L . программа J	I_______________I
, , t г-----------------1
| I gatpwuid !	" Си-библиотека
t_____________________________
Сторона сервера
Рис. А. Процедуре оброботки зопросов в системе NIS
554
Чость II Роботе в сетях
Найдя сервер, демон ypbind будет пользоваться им при ответе на все
запросы до тех пор, пока сервер не отключится или пока не возникнет
какая-нибудь проблема со связью. Демон ypbind на сервере не пре доставляет
себе никаких льгот, поэтому серверы не обязательно обращаются к самим
себе.
При некоторых обстоятельствах (например, когда все серверы, кроме
одного, одновременно перезагружаются) клиенты могут “закрепиться” на
одном сервере и отказаться уйти с него даже после того, как станут доступны
остальные серверы. Это значительно уменьшает быстродействие системы.
В NIS есть ряд вспомогательных команд, которые используются для
изучения карт, определения версий карт, используемых каждым сервером, и
управления привязкой клиентов к серверам. Полный перечень команд и
демонов NIS дан в табл. 18.4.
Таблица 18.4. Команды и демоны системы NIS
Команда	Описание		
ypserr ypbind domainname	Демон сервера NIS. запускается но время начальной загрузки Демон клиента N1S. запускается во время начальной загрузки Задаст домен NIS, в который входит данный компьютер (выполняется во время начальной загрузки)
ypxfr ypxfrd	Загружает текущую версию карты с главного сервера Обслуживает запросы, поступающие от команды ypxfr (работает на главном сервере)
yppush makedbin ypmake1 ypinit ypset	Заставляет подчиненный сервер обновить свою версию карты Создает хэшированную карту из обычного файла Обновляет хэшированные карты для тех файлов, которые изменились Конфигурирует компьютер как главный или подчиненный сервер Заставляет демон ypbind установить соединение с конкретным серве- ром
ypwhich yppoU у peat ypmatcb	Определяет, с каким сервером работает текущий компьютер Определяет, какую версию карты использует сервер Выводит на экран значения, содержащиеся в NIS-карте Выводит на экран элементы карты, соответствующие заданному ключу
yppaaswd ypebfh ypebsb	Изменяет пароль на главном сервере NIS Изменяет информацию GECOS на главном сервере NIS Меняет регистрационный интерпретатор команд на главном сервере NIS
yppaaswdd ypupdated1	Сервер для команд yppasswd, ypchsh и ypebfh Сервер для обновления N1 S-карт (им управляет демон inetd)
1 Используется не во всех системах.
Создание N IS-домен а
Службу N1S следует инициализировать на главном сервере, на подчинен-
ных серверах и на всех клиентах. Эта работа выполняется в два этапа
Во-первых, необходимо запустить программу ypinit на каждом сервере.
Глово 18. Совместное использование системных фонтов
555
Во-вторых, на каждом компьютере домена нужно задать доменное имя в
одном из системных стартовых сценариев и сконфигурировать файл
/etc/nsswitch.conf на импорт данных N1S.
Конфигурирование серверов NIS
Для инициализации главного н подчиненных серверов домена предна-
значена программа ypinit. На главном сервере используются следующие
команды*.
*	cd /var/ур	/* NIS-каталог ♦/
#	domainnaiM домен /• имя нового домена /
#	ypinit: -m	/• инициализация главного сервера /
#	ypaerv	/ запуск сервера NIS ’/
Флаг -т указывает программе ypinit на то, что она конфигурирует главный
сервер. Программа сама предложит ввести список подчиненных серверов.
После запуска главного сервера необходимо инициализировать каждый
подчиненный сервер, для чего запускается программа ypinit с флагом -s:
*	cd /var/ур
И ypinit - главныЯ_сервер
♦	ypaarv
Команда ypinit -s создает локальную копию текущих данных главного
сервера. Наличия файлов данных для какого-либо домена достаточно для
того, чтобы демон ypserv знал о необходимости обслуживать этот домен.
На каждом подчиненном сервере нужно задать crontab-элементы, которые
запрашивают свежие копии всех карт с главного сервера Команда ypxfr карта
(где карта — имя наподобие passwd.byuid) запрашивает указанную карту с
главного сервера. Эта команда выполняется по одому разу для каждой карты.
Карты, как правило, изменяются не одновременно, и если пропускная
способность сети ограничена, одни карты потребуется пересылать чаше, чем
другие. В большинстве случаев речь может идти о пересылке всех карт не
более одого-двух раз в день (лучше поздно вечером).
Следующий сценарий организует пересылку всех карт:
#!/bin/csh -f
set mydomain =» '/usrZbin/doitiainname'
cd /var/yp/$mydomain	# NIS-каталог
foreach map ('/bin/Is'}
/usr/lib/yp/ypxfг Snap
end
В некоторых системах используются готовые сценарии ypxfr_lperday.
ypxfr_2perday и ypxfr_lperhour которые пересылают NIS-карты с различной
частотой.
Многие системы, поддерживающие службу NIS, на этапе начальной
загрузки проверяют, является ли данный компьютер сервером N1S, и, если
это так, автоматически запускают демон ypserv. В остальных системах демон
нужно запускать вручную. Подробнее об этом мы расскажем далее.
Если нужно предоставить пользователям возможность изменять свои
пароли посредством программы yppasswd. на главном сервере N1S следует
запустить демон yppasswdd
Команды N1S, такие как ypinit и ypserv, обычно прячут в нестандартных каталогах.
Воспользовавшись документацией, выясните, где находятся эти команды в вашей системе.
556
Чость II. Роботе в сетях
Конфигурировоние клиентов NIS
После конфигурирования серверов необходимо проинформировать всех
клиентов о том, что они стали членами нового домена. Серверы домена, как
правило, являются одновременно и клиентами.
Команда domaineame задает NIS-домен, которому принадлежит данный
компьютер. Обычно ее выполняют в одном из стартовых сценариев на этапе
начальной загрузки; детали подобного процесса зависят от системы (см.
ниже).
Сведения о системных стартовых сценариях можно найти в главе 2.
Каждый клиент должен иметь, по крайней мере, личные версии файлов
passwd, group и hosts в минимальной конфигурации. Первые два необходимы
для того, чтобы суперпользователь мог войти в систему при отсутствии сервера
NIS. Они должны содержать описания стандартных системных учетных
записей и групп: root, bin, daemon, wheel и т.д. Файл hosts нужен как источник
информации на этапе начальной загрузки, пока служба NIS не начала
работать.
Особенности NIS в различных операционных системах
В Solaris нмя домена NIS должно быть помешено в файл /etc/defaultdo-
main. Сценарий /etc/init.d/inetinit запрашивает этот файл при запуске системы
и, если таковой существует, выполняет команду domainname, передавая ей
содержимое файла в качестве единственного аргумента. В процессе начальной
загрузки сценарий ypstart обнаруживает, что имя домена установлено, и
запускает демоны ypbind и ypserv. На главном сервере автоматически
запускаются также демоны yppasswdd и ypxfrd.
Чтобы запретить демону ypbind осуществлять широковещательный поиск
серверов NIS, выполните на каждом клиентском компьютере команду ypinit -с
и задайте имена серверов, с которыми должен работать каждый клиент. Для
того чтобы изменения вступили в силу, нужно уничтожить демон ypbind и
запустить его повторно без опции -broadcast (или перезагрузиться). Имена
серверов должны присутствовать в файле /etc/hosts, лишь при этом условии
они могут быть распознаны до того, как произойдет запуск NIS.
В HP-UX конфигурационная информация системы NIS хранится в файле
/etc/rc.conng.d/namesvTs. На клиентских компьютерах переменная NIS_DO-
MAIN должна содержать имя домена N1S, а переменная NIS_CLIENT должна
равняться единице. На серверах нужно также переменную NIS_MASTER_SER-
VER или NIS_SLAVE_SERVER (но не обе) установить равной 1. Демоны
yppasswdd и ypxfrd автоматически запускаются на главных серверах.
В Red Hat имя домена N1S задается в переменной NISDOMAIN в файле
/etc/sysconfig/network. Запуск демонов ypbind, ypserv и yppasswdd включается
и отключается с помощью команды chkconfig:
t chkconfig ypbind on
Демон ypbind можно заставить работать с конкретным сервером NIS (не
используя широковещательный поиск), поместив следующую строку в файл
/etc/yp.conf:
ypserver ммя_сервера
Эта строка должна быть единственной в данном файле. Указанное имя
сервера должно присутствовать в файле /etc/hosts.
Глово 18. Совместное использовоние системных фойлов
557
£
18.4.
Во FreeBSD имя домена N1S содержится в переменной nisdcmainname
в файле /etc/гс.conf. Например:
nisdomainname - "cssuns"
Для запуска демонов ypbind. ypserv и yppasswdd необходимо задать
значения переменных nis_client_enable, nis_server_enable и
nis_yppasswdd_enable равными YES.
Файлы /etc/passwd и /etc/group должны содержать специальную метку '+*.
если требуется использовать службу NIS в качестве источника информации
NIS+: потомок NIS
Система N1S+ предназначена для устранения недостатков N1S. Она
работает с большими компьютерными сетями и имеет встроенные средства
зашиты. Эта система позволяет управлять группами доменов из любой точки
сети, а также эффективно рассылает обновления. Кроме того, она является
распределенной базой данных В обшем, данная система подозрительно
хороша, чтобы существовать на самом деле.
Хотя серверы N1S+ могут обслуживать клиентов NIS (с некоторым
снижением уровня безопасности). NIS+ — совершенно другая система, у
которой нет общего с NIS кода. Она поддерживается некоторыми крупными
поставщиками ОС (например, HP-UX), но вследствие своей сложности не
входит ни в одну из бесплатных операционных систем.
NIS+ — это хороший пример того, что Фредерик Брукс-младшин
(Frederick Р. Brooks. Jr.) в своей классической книге The Mythical Man-Month
(“Мифический человеко-месяц”), посвященной технологиям разработки про-
граммного обеспечения, назвал “эффектом второй системы”. Эта система
пытается пробиться к пользователям на волне успеха своей предшественницы,
избегая всех ошибок и ловушек предыдущей концепции. Разработчики
уделили существенное внимание ее формальной архитектуре. Теоретически
система должна получиться совершенной. На практике же она неуклюжа,
тяжеловесна и находится несколько в стороне от повседневной жизни. Нам
рассказали, что лаже в самой компании Sun ею не пользуются.
Между NIS и NIS+ имеется несколько существенных различий.
•	Система доменов NIS+ обладает иерархической структурой в масштабе
организации, подобно DNS Как и в случае использования NIS. на
компьютеры каждого домена рассылается административная информация
различных видов. С целью делегирования административных полномочии
домены можно делить на поддомены Каждый компьютер относится к
одному домену, но домены могут обращаться к данным друг друга, что
позволяет компьютерам получать информацию из нескольких доменов.
•	NIS+ больше похожа на базу данных, чем NIS, и позволяет осуществлять
поиск в картах (которые здесь называют таблицами) по любому палю.
Благодаря этому устраняется необходимость в ведении для каждого
системного файла нескольких карт. В NIS+ каждый файл трактуется как
одна таблица
•	В отличие от NIS. в NIS+ не используются обычные файлы. Можно
переслать в NIS+ данные из UNIX-файла (или NIS-каргы). но после
этого служба NIS+ будет считаться авторитетным источником переданной
ей информации. При последующем изменении файла система не станет
обновлять свою копию этого файла автоматически — для внесения
55Е
Чость II. Роб ото в сетях
изменений следует пользоваться командой, которая редактирует инфор-
мацию непосредственно в таблицах NIS+.
•	NIS+ гораздо эффективнее N1S в плане управления подчиненными
серверами, которые в NIS+ называют репликами. Пересылается только
информация о последних изменениях, а удобная схема регистрации
позволяет обнаружить реплицированные серверы, которые вступают в
контакт (или прекращают таковой) с главным сервером. Главный сервер
может переслать серверу-реплике всю свою базу данных NIS+, если
посчитает, что реплика слишком устарела для пошагового обновления.
•	Служба N1S+ построена на базе системы Sun Secure RPC, которая,
помимо стандартной аутентификации, обеспечивает аутентификацию на
основе шифрования с открытым ключом. Серверы NIS+ можно настроить
так, чтобы они либо требовали идентификационную информацию в
зашифрованном виде, либо следовали обычным правилам UNIX
•	Как и обычный файл, каждый объект N1S+ (таблица, столбец, запись)
имеет владельца и группу. Права доступа к объекту устанавливаются
отдельно для владельца, группы и прочих пользователей. Те, кто не имеет
своих идентификаторов (например, клиенты N1S), могут получить доступ
с правами пользователя nobody. “Принципалами” системы Secure RPC
(объектами, которые могут предъявлять свои идентификационные дан-
ные) могут быть и пользователи, и компьютеры. При обращении к NIS+
от имени пользователя root вместо данных суперпользователя применя-
ются данные самого компьютера.
С точки зрения клиента служба NIS+ выглядит почти так же, как и
любая другая административная СУБД. Доступ к большинству данных
осуществляется посредством тех же библиотечных функций, и сложный мир
доменов, таблиц, прав доступа и путей поиска в конечном итоге сводится к
обычным UNIX-файлам.
N1S+ не имеет никакого отношения к DNS, за исключением того, что
они применяют одинаковую схему именования. DNS и N1S+ используют
имена, обратные путевым именам в файловой системе: читая имя слева
направо, продвигаешься по направлению к корню иерархического дерева.
Например, cs.colorado.edu — является поддоменом домена colorado.edu. Ком-
пьютер в этом домене может иметь имя anchor.cs.colorado.edu.
В соответствии с соглашением, корень иерархии NIS+ называется так
же, как и DNS-домен верхнего уровня для данной организации. Если, скажем,
DNS-домен имеет имя xor.com, то корневой домен NIS+ тоже будет
называться xor.com, а marketing.xor.com будет, к примеру, поддоменом для
отдела маркетинга. Поскольку DNS и NIS+ не взаимодействуют, риск от
использования одинаковых имен сведен к нулю.
Формально NIS+ не поддерживает концепцию доменов и никому ее не
навязывает. В этой системе просто предлагается базовый метод постороения
иерархии каталогов NIS+, создания в этих каталогах разных таблиц и
привязки частей этой иерархии к различным главным серверам. Согласно
соглашению, “домен” в NIS+ — это каталог, который содержит подкаталоги
orgdir и groups dir. Административные данные этого домена помешаются в
таблицы, находящиеся в подкаталоге org dir, а идентификационные данные
“принципалов” N1S+ определяются в подкаталоге groups_dir. Теоретически в
обоих названных подкаталогах могут быть другие подкаталоги, но обычно
этого избегают.
Глово 18. Совместное использование системных файлов
559
Например, org_dir.markeling.xor.com — это имя каталога, содержащего
системные таблицы домена markeiing.xor.com. В плане синтаксиса обращение
к таблицам производится как к каталогам: строка hosts.org_dir.market-
ing. xor.com обозначает эквивалент файла /etc/hosts для данного домена в
NIS+. При обращении к элементу таблицы используется другой синтаксис
(здесь он не рассматривается).
Наше мнение относительно N1S+ таково: по возможности следует
избегать этой системы. Она, конечно, функционирует нормально, но то же
самое можно сказать и о более простых ее альтернативах. Естественно, мы
противники тотального отрицания; просто мы считаем, что нет особых
причин, по которым предпочтение следовало бы отдавать именно NIS-
18.5. LDAP: упрощенный протокол доступа к каталогам
Организациям, использующим UNIX, необходим надежный способ рас-
пространения своих административных данных. Но проблема в действитель-
ности более глобальна. Как быть с неадминистративными ресурсами,
например с телефоном и каталогами электронной почты? Как контролировать
информацию, которую нужно предоставить внешнему миру? Решение
устраивающее всех, заключается в унифицировании службы каталогов.
Служба каталогов — это просто база данных, но такая, в которой сделан
ряд дополнительных предположений. Любой набор данных с характеристи-
ками, соответствующими этим предположениям, становится кандидатом на
включение в базу данных. Основные предположения таковы:
•	информационные объекты относительно невелики;
•	база данных будет реплицироваться и кэшироваться на множестве
компьютеров;
•	у информации есть атрибуты;
•	данные извлекаются часто, но записываются редко;
•	операции поиска выполняются очень часто.
Текущая стандартная система, предложенная организацией IETF для этик
целей, называется LDAP (Lightweight Directory Access Protocol — упрошенный
протокол доступа к каталогам). В спецификациях LDAP говорится не о самой
базе данных, а лишь о том, как получить к ней доступ по сети. В то же
время заданы схемы организации данных и осуществления поиска, т.е.
подразумевается достаточно четкая модель данных.
История LDAP едва ли напоминает красивую скажу. Она ведет свое
начало от модели 0S1 — мертворожденного семейства сетевых протоколов,
ошибочно принятого в качестве международного стандарта в середине 80-х гг.
Модель OSI в целом потерпела крах, но отдельные ее протоколы получили
шанс на “загробную жизнь”, будучи включенными в “мутировавшем"’ виде
в стек TCP/IP. Одним из них был протокол сетевого управления CM IP
(Common Management Information Protocol — протокол обшей управляющей
информации); за ним следовал LDAP.
Изначально LDAP был задуман как простои шлюзовый протокол,
который позволял бы клиентам TCP/IP взаимодействовать с серверами
каталогов Х.500, работающими в OSI-системах. Со временем стало очевидно,
что стандарт Х.500 умирает и в UNIX необходима какая-то стандартная служба
каталогов. Все это привело к тому, что из LDAP получилась совершенно
самостоятельная, полноценная система управления каталогами (возможно,
буква L в названии стоит незаслуженно).
560
Чость II Робота в сетях
На время работы над книгой процесс разработки все еще находился в
промежуточной стадии. Наиболее распространенной версией LDAP является
версия 2, где недостает множества элементов, которые могут потребоваться
в будущем для того, чтобы сделать LDAP такой же функциональной и
надежной системой, как, скажем, DNS. Даже версия 3, еше не принятая в
качестве стандарта, имеет ряд значительных недостатков. Если не считать
некоторых специфических областей применения (телефонные книги в
Internet, конфигурирование псевдонимов sendmail, определенные справочные
службы), реальное распространение протокола LDAP все еще ограничено.
К сожалению, протокол LDAP успел стать удобной мишенью для всякого
рода спекуляций. Подобно технологии Java в середине 90-х гг., на тему LDaP
было выпушено слишком много пресс-релизов, звучали клятвенные заверения
в поддержке и любви до гроба, но в результате получилось слишком мало
программного кода. А пока нам остается сидеть на берегу моря, наслаждаться
восходом и ждать появления прекрасной Венеры.
Трудно предсказать, будет ли от развития протокола LDAP реальная
помощь системным администраторам. Протокол еще не сумел найти свою
нишу. Мы советуем избрать тактику “внимательного наблюдения’’.
Документация и спецификации LDAP
В настоящее время наилучшим введением в LDAP является брошюра
Understanding LDAP, написанная Хайнпом Йонером (Heinz Johner) с соавто-
рами для международной службы технической поддержки компании IBM. Ее
можно загрузить в формате PDF на узле www.redbooks.ibm.coni. Части,
касающиеся библиотек функций языка С, можно проигнорировать; все
остальное — полезная информация для системных администраторов.
Существует множество документов RFC, посвященных протоколу LDAP.
Важнейшие из них перечислены в табл. 18.5. Многие упомянутые здесь
документы относятся к версии 3 протокола; у них есть эквиваленты и для
версии 2. Как видно из названий документов, большинство объектов и
транзакций LDAP может быть представлено в текстовом виде, что является
одной из наиболее приятных особенностей протокола. Можно легко генери-
ровать запросы из сценария или организовывать шлюзы к другим протоколам,
в частности к HTTP.
Тоблицо 18.5 Документы RFC, посвященные протоколу LDAP
RFC	Нсзвоние
1777	Light weight	Directory Access Protocol	(v2)
2251	Lightweight	Directory Access Protocol	(v3)
2252	LDAPv3: Attribute Syntax Definitions
2253 LDAPv3: UTF-8 String Representation of Distinguished Names
2254 The Sen ng Representation of LDAP Search Filters
2255 The LDAP URL Format
2256 A Summary of the X.500 User Schema for Use with LDAPv3
2307 An Approach for Using LDAP as a Network Information Service
Глово 18 Совместное использовонме системных фоилов
5<f 1
В документе RFC2307 предлагаются способы привязки традиционных для
UNIX наборов данных, в том числе файлов passwd и group, к пространству
имен LDAP. Этот документ носит пометку "экспериментальный”, что
является наглядным свидетельством того, сколь далеки мы от момента, когда
протокол LDaP станет реальной заменой таким системам, как NIS и N1S+.
Практическое применение протокола LDAP
Протокол LDAP был реализован университетом штата Мичиган, компа-
нией Netscape и рядом других организаций Лучшее нз современных
решений — система OpenLDAP Ее реализацией занимается группа Ореп-
LDAP (www.openldap.org). которая унаследовала код мичиганского универси-
тета. К середине 2000 г. почти не было документации, посвященной работе
с OpenLDAP. Краткое руководство, имеющееся на Web-узле, поможет
инсталлировать и запустить систему, но в нем нет информации о том, как
ее настраивать или отлаживать.
Об использовании LDAP в системе sendmail рассказывается в параграфе 19.4.
В дистрибутив OpenLDAP входит стандартный серверный демон slapd, а
также демон slaprd, управляющий репликацией (напоминает механизм
подчиненных серверов NIS). Сетевая структура представляется в иерархиче-
ском виде независимо от того, являются ли таковыми сами данные. Только
когда протокол LDAP версии 3 будет полностью введен в действие, мы
перейдем к полноценным иерархическим системам.
Если кому-то нужно использовать LDAP для распространения конфигу-
рационной информации (хотя мы пока не рекомендуем этого делать), то в
настоящее время существуют дня способа решения данной задачи. Первый
вариант — применить программу ypldapd, продаваемую компанией PaDL
Software и реализующую шлюз между LDAP и NIS. Этот демон извлекает из
LDAP информацию о пользователях, группах и узлах и выдает себя за сервер
NIS, передавая данные ничего не подозревающим клиентам NIS. К сожале-
нию, лицензия стоит слишком дорого даже для некоммерческих организаций.
Дополнительную информацию можно получить на Web-узле www.padl.com.
Второй вариант — встроить поддержку LDAP в библиотеку функций
языка С, с тем чтобы LDAP можно было указывать в файле /etc/nssHtch.conf
наряду с другими источниками информации Компания PADL предлагает
бесплатный пакет nssjdap, реализующий данный подход. Но. как и в случае
любого другого изменения стандартных библиотек, степень требуемого
программистского вмешательства оказывается излишне высокой Есть также
пакет pam ldap, позволяющий использовать протокол LDAP совместно с
подключаемыми модулями аутентификации.
562
Чость II Робото в сетях
Электронная почта
Взявшись подготовить эту главу для третьего издания, мы предполагали,
что внести в нее новые данные будет нетрудно. Ведь, казалось бы, за 5 лет
изменилось не так много: появилась пара “заплат”, улучшающих безопасность
электронной почты, введены новые возможности по управлению спамом,
вышла из употребления устаревшая версия IDA sendmail Однако мы
ошибались.
С момента выхода в свет предыдущего издания книги электронная почта
превратилась из просто важного в самое важное средство общения между
людьми как в деловой, так и в личной жизни. Многие изменения в программе
sendmail были вызваны тем, что провайдерам, к которым обращались
миллионы желающих пользоваться электронной почтой, потребовалось уве-
личить гибкость и масштабируемость имеющихся почтовых систем. Рост
объема спама и возросшая активность хакеров, постоянно атакующих системы
с конфиденциальной информацией, стали причиной дополнительных изме-
нений и попыток ввести более строгие правила. Все эти процессы оказали
влияние на Internet и электронную почту. В результате организации IETF
приходится постоянно совершенствовать существующие стандарты и разра-
батывать новые.
Широкое распространение электронной почты повлекло за собой любо-
пытные социальные последствия. Электронная почта кажется менее офици-
альной, чем бумажная, поэтому люди обычно более откровенны в своих
высказываниях. Кроме того, при электронном общении отсутствует личный
контакт, поэтому авторы писем чаше проявляют такие чувства, как раздра
жение, гнев, разочарование и т.п. Люди обмениваются такими словами,
которые никогда бы не произнесли вслух и не написали бы на бумаге.
Например, один из наших пользователей, будучи чем-то недовольным,
выходил из себя и часто оскорблял администраторов. Мы нашли единственно
возможный способ защиты: мы сохраняли его сообщения, а через пару недель,
когда он остывал, возвращали их ему. Читая свои “перлы”, этот человек
приходил в ужас.
Глово 19. Электронноя почто
563
Другой социальный аспект, связанный с электронной почтой, особенно
явно начал проявляться в последние годы. Речь идет о массово рассылаемой
информации рекламного характера, которая просто засоряет глобальную сеть.
Такого рода почту называют спамом. Послать сообщение через Internet
намного дешевле, чем, например, посредством обычной почты. Для отпра-
вителя стоимость передачи одного и, скажем, 25 миллионов сообщений
практически одинакова. Однако этого нельзя сказать о провайдере, который
должен обеспечить достаточную полосу пропускания при рассылке спама
(а объем такового в одной только сети America Online составляет порядка
30% от всей почты). Попытки ограничить спам при помощи законов и судов
не привели к желаемому результату. Более эффективными являются техни-
ческие решения, в том числе применение почтовых фильтров. (Подробнее
об этом рассказывается в параграфе 19-10.)
Большой объем данной главы (около 100 страниц) свидетельствует о том,
что почтовые системы — тема достаточно сложная. Здесь представлены как
базовые сведения по рассматриваемому вопросу, так и более детальная
информация, в частности о конфигурировании программного обеспечения.
Сначала мы хотели разделить эту главу на четыре поменьше, посвятив
их почтовым системам в целом, конфигурации программы sendmail, спаму и
системе Postfix. Однако затем мы отказались от этой идеи и думаем, что
поступили верно. Ниже представлена таблица, в которой описан каждый
параграф данной главы.
Тоблицо 19.1. Порогрофы донной главы
Параграф Описание  „ 
1	Системы электронной почты и их структура
иМ 2	Адресация и ее синтаксис, заголовки сообщений
5 3	Принципы работы электронной почты, модель клиент/сернер,
О	почтовые каталоги
4	Псевдонимы, маршрутизация почты, программы для работы со
списками рассылки, протокол LDAP__________________________
Программа sendmail: инсталляция, запуск, очередь сообщений
Основы конфигурирования sendmail
Базовые примитивы конфигурации sendmail
Более сложные примитивы конфигурации sendmail
Примеры: домашний компьютер, небольшая компания, компания,
занимающаяся виртуальным хостингом
Спам
Безопасность
Статистика, тестирование, отладка ________________________
Система Postfix, альтернатива программе sendmail
Дополнительные источники информации
В помошь тем, кому может понадобиться быстро отыскать в главе нужные
сведения, мы составили табл. 19.2. В ней приведен перечень часто встречаю-
щихся задач и номера параграфов, где изложена нужная информация.
564
Чость II Робота в сетях
Тоблица 19.2. Список задом с укозонием соответствующих пооогооФов
Задаче	, HpMftpn параграфов u
Обновление sendmail	5,	6
Начальное конфигурирование sendmail	3,	6, 7,	8,	9,	12
Проектирование почтовой системы	организации 3,	4, 6,	7,	8,	9, 11
Борьба со спамом	10
Проверка безопасности	11
Настройка ПК ня прием почты	1,	3
Создание списка рассылки	4
Настройка производительности	3.	8
Виртуальный хостинг 8,	9
В данной главе в основном рассматривается	конфигурация sendmail —
UNIX-программы, которая анализирует и маршрутизирует электронную
почту. Эту программу написал Эрик Оллман (Eric Allman) из Калифорний-
ского университета в Беркли. Существуют три основные версии програм-
мы: 5 (V5), IDA и 8 (V8). Не за горами выпуск версии 9. Версии 5 и IDA
в настоящее время применяются сравнительно редко. Ниже мы опишем
версию 8 (точнее, 8.11), а также попытаемся заглянуть в будущее и рассмотрим
возможности, которые, как ожидается, предоставит нам версия 9.
Коммерческие версии программы sendmail разрабатываются компанией
Sendmail, Inc. Эта же компания осуществляет поддержку и свободно
распространяемой версии с открытым кодом. Коммерческие версии имеют
графический интерфейс и дополнительные возможности по улучшению
производительности; всего этого еше нет в открытой версии.
Программа sendmail занимает достаточно прочные позиции на рынке,
однако в последние годы появились новые свободно распространяемые
транспортные агенты электронной почты. Среди них следует отметить систему
Postfix, описанную в параграфе 19.13. Остальные программы подобного рода
будут упомянуты лишь вкратце.
19 1. Системы электронной почты
Теоретически система электронной почты состоит из четырех компонентов:
•	пользовательского агента, который предоставляет пользователям возмож-
ность читать и составлять сообщения;
•	транспортного агента, который пересылает сообщения с одного компью-
тера на другой;
•	агента доставки, который помешает сообщения в локальное хранилище
сообщений*,
•	агента доступа, который соединяет пользовательского агента с хранили-
щем сообщений (например, посредством протокола IMAP или POP). Этот
компонент является необязательным.
В некоторых организациях используется также агент подачи почты,
который работает по протоколу SMTP и выполняет часть функций транс-
портного агента Схема взаимодействия всех указанных компонентов пред-
ставлена на рис. А.
• Почтовые ящики пользователей, иногда — база данных
Глово 19 Электронная почто
56 j
Узел А - отправитель
Узел В - получатель
mail-local
ПА= Пользовательский агент
ТА = Транспортный агент
ДА = Доставочный а гейт к локальным '
пользовательским.
procmail
Хранилище
сообщений
imapd
АП  Агент подачи
АД * Агент доступа
ж
Рис- А. Компоненты системы электронной почты
Пользовательские агенты
Эти программы используются для чтения и составления электронных
сообщений. Первоначально сообщения могли содержать только простой текст,
однако благодаря стандарту MIME (Multipurpose Internet Mail Extensions —
многоцелевые расширения электронной почты в сети Internet) появилась
возможность включать в них форматированный текст и присоединять к
сообщениям разные файлы (в том числе вирусы). Стандарт MIME поддер-
живается большинством пользовательских агентов. Поскольку он не влияет
на процесс адресации и доставки почты, мы не будем его рассматривать -
Одна из задач пользовательского агента — обеспечение того, чтобы текст
сообщения, который может быть истолкован почтовой системой неправильно,
не попал в нее “незащищенным”. Примером является строка “From”, которая
служит разделителем сообщений.
Самым первым пользовательским агентом была программа /bin/mail
Сейчас имеется несколько программ этого класса. Вот перечень наиболее
популярных из них:
•	/bin/mail — существовала в первоначальной версии UNIX;
•	/usr/ncb/mail — появилась в BSD”.
•	mh и nmh — разработаны на основе кода компании Rand Corporation,
есть также пользовательская оболочка exmh. созданная Брентом Уэлшем
(Brent Welch) из компании Scriptics;
•	pine — разработана в университете штата Вашингтон (www.washing-
ton.edu/pine);
•	elm — разработана Дэвидом Тейлором (David Taylor), сейчас поддержи-
вается организацией Elm Development Group и Кари Хуррта (Кап Hurrta).
доступна на FTP-узле ftp.virginia.edu;
•	mutt — разработана Михаэлем Элкинзом (Michael Elkins), доступна на
FTP-узле ftp.muu.org.
Порой кажется, что основной результат от внедрения стандарта MIME состоит в том, что
вместо единого открытого формата почты появилось множество более мелких коммерческих
форматов. Деньги определяют все.
Программа /usr/ucb/mail иногда называется /Ып/nudlx или /Ьш/Mail в системах, производ-
ных от System V.
566
Чость II Робота в сетях
•	rmail и V’M — пользовательские агенты, которые являются частью
редакторов emacs и XEmacs;
•	Netscape Communicator — разработана компанией Netscape Communica-
tions для различных платформ;
•	Eudora — разработана компашгей Qualcomm для систем Macintosh и
персональных компьютеров, работающих под управлением Windows;
•	Outlook Express" — разработана компанией Microsoft для Windows.
Некоторые пользовательские агенты поддерживают системный файл
конфигурации, в котором задаются стандартные установки для всех пользо-
вателей. Любой пользователь может изменить эти значения, создав в своем
начальном каталоге персональный файл конфигурации. Пользовательские
агенты электронной почты для Windows и Macintosh конфигурируются
посредством графического интерфейса самого приложения. Большинство из
них также допускает глобальную и автоматическую настройку на случай
эксплуатации в крупной организации.
В табл. 19.3 приведены имена файлов конфигурации и возможности
перечисленных выше пользовательских агентов. Местонахождение н даже
имена системных файлов иногда являются системно-зависимыми. Многие их
файлов находятся в каталоге /etc.
Таблица 19.3. Фоилы конфигурации и характеристики пользовательских агентов
Пользовательский агент	Системный файл	Персональный ^IMb ..айл	L	POP	IMAP	SMTP
bin/mail	—	—			
ncb/mail	MaiLrc	.mailic			
*mh	-	mh profile	Z .maildelivery	z		z
pine	pine.conf	.pinerc	Z	✓	/	z1
eUn	lib/elm.rc	.elm/elmrc	Z	✓2	✓2	
mutt	Muttrc	.muttrc	Z	✓	✓	
Netscape	—	— ✓	✓	/	/
Eudora	—	_ ✓	/	/	/
Outlook Express	—	—	Z	/	✓	✓
Программа pine по умолчанию вызывает sendmail. однако поддерживает и протокол
SMTP.
В стандартной реализации не поддерживается, однако доступна соответствующая
“заплата".
Столбец ‘’.SMTP’' указывает на способ передачи почты от пользователь-
ского агента к транспортному агенту или агенту подачи. Наличие отметки
означает, что пользовательский агент открывает сетевое соединение непо-
средственно к транспортному агенту' нли агенту подачи Отсутствие отметки
говорит о том, что он самостоятельно запускает программу транспортного
агента или агента подачи.
Outlook Express — это свободно распространяемая программа для чтения электронной
почты, которая не имеет никакого отношения к коммерческому продукту Microsoft Outlook.
Глово 19 Электронноя почто
567
ш
ф
Транспортные агенты
Задача транспортного агента — принимать почту от пользовательского
агента, интерпретировать адреса получателей и каким-то образом направлять
почту на соответствующие компьютеры для последующей доставки. Кроме
того, большинство транспортных агентов выступает в качестве агентов подачи,
осуществляя первоначальную вставку новых сообщений в почтовую систему.
Транспортные агенты работают по протоколу SMTP (Simple Mail Transpon
Protocol — простой протокол передачи почты), который определен в доку-
менте RFC821, или по протоколу ESMTP (Extended SMTP), определен ному
в документах RFC1869, 1870, 1891 и 1985.
Для UNIX разработано несколько транспортных агентов (PMDF, Postfix,
small, qmail, exim. zmailer и др.), но самым мощным, гибким и поэтому самым
распространенным (75% по последним оценкам) является sendmail.
Агенты доставки
Агент доставки отвечает за прием почты от транспортного агента и ее
передачу соответствующим получателям. Почта может доставляться конкрет-
ному лицу, в список рассылки, в файл и даже в программу.
Для обслуживания получателя каждого типа может понадобиться отдель-
ный агент. Программа /bin/mail — это агент доставки для локальных
пользователей. Программа /bin/sh — агент доставки для почты, которая
направляется в файл или программу. Последние версии sendmail осуществляют
доставку почты при помощи более надежных локальных агентов доставки,
именуемых mail.local и smrsh. В качестве агента может также использоваться
программа procmail (описывается в конце параграфа 19.8; доступна на
Web-узле www.procmajl.org).
Программу mail.local не следует использовать в таких системах, как.
например, HP-UX. которые осуществляют доставку почты в пользовательские
почтовые ящики, меняя принадлежность файлов при помощи команды chown.
В старых версиях Solaris также не следует применять mail.local, однако эта
программа поддерживается вплоть до версии Solaris 7.
Хранилища сообщений
Когда из университетской игрушки электронная почта превратилась в
средство обслуживания организаций наподобие America Online с миллионами
подписчиков, файловая система UNIX перестала подходить для хранения
сообщений. Поиск в каталоге, который содержит миллионы почтовых
ящиков, — занятие очень дорогое.
Хранилище сообщений — это место на локальном компьютере, где
располагается электронная почта. Обычно для этого используется каталог
/var/spool/maii или /var/mail. Почта хранится в файлах, которые называются
в соответствии с регистрационными именами пользователей- Однако так
выглядит обычное хранилище. Провайдеры, у которых тысячи или миллионы
клиентов, ищут другие технологии организации хранилищ (обычно это базы
данных).
В системах, где применяется каталог /var/spool/mail или /var/mail. он
создается во время инсталляции операционной системы. Режим доступа к
данному каталогу должен иметь значение 775 (имя группы — mail),
568
Чость II Роботе в сетях
Агенты доступа
Такие программы, как imapd и spop, являются агентами доступа для
пользователей ПК, Macintosh или UNIX, чья почта доставляется на UNIX-
сервер. а затем загружается с него по протоколу JMAP (Internet Message Access
Protocol — протокол доступа к сообщениям в сети Internet) или POP (Post
Office Protocol — почтовый протокол) соответственно. (Оба протокола
рассматриваются в параграфе 19-3.)
Агенты подачи почты
Необходимость в программах этого класса возникла в связи с ростом
объема почтовых узлов. На большом узле транспортный агент вынужден
тратить много времени на предварительную обработку сообщений. Он должен:
•	проверять, являются ли имена узлов полностью определенными;
•	модифицировать заголовки сообщений, полученных от неправильно
работающих пользовательских агентов;
•	вести журнал;
•	переписывать заголовки и тл.
В документе RFC2476 была сформулирована идея отделить агента подачи
почты от транспортного агента с целью распределения нагрузки и повышения
общей производительности
Идея заключается в том, что агент подачи работает на другом порту и
выступает в качестве регистратора новых сообщений, поступающих в
почтовую систему от локальных пользовательских агентов. Он делает всю
предварительную работу, включая проверку ошибок перед отправкой сооб-
щения транспортному агенту.
В частности, агент подачи должен убедиться в том, что все имена узлов
являются полностью определенными. Кроме того, перед добавлением к адресу
локального доменного имени он проверяет, являются ли имена локальных
узлов легитимными. Агент подачи также исправляет заголовки сообщений,
если в них есть ошибки (и добавляет заголовки, если они отсутствуют).
К примеру, могут добавляться заголовки "From" и “Date" и корректироваться
заголовок "Message-Id”. Наконец, агент подачи может переписать адрес
отправителя, поменяв регистрационное имя на заданное внешнее (например,
в формате Имя_Фамияия).
Чтобы этот механизм работал, пользовательский агент должен быть
сконфигурирован на подключение к агенту подачи через порт 587. а не через
порт 25, который традиционно применяется для электронной почты. Если
пользовательский агент не может работать с портом 587, существует другой
путь: вызвать агент подачи через порт 25, но не на том сервере, на котором
работает транспортный агент. Необходггмо также сконфигурировать транс-
портный агент таким образом, чтобы он не проделывал повторно работу,
выполненную агентом подачи. Дублирование не скажется на правильности
обработки почты, но отразится на производительности.
Программа sendmail может действовать и как агент подачи, и как
транспортный агент. В sendmail версии 8.10 агент подачи включен по
умолчанию. Эта конфигурация устанавливается при помощи средства по-
canonify и макроса DAEMON_OPTIONS (параграф 19.8). Когда программа
sendmail играет двойную роль, она предоставляет каждый из сервисов на
отдельном порту': порт 25 для транспортного агента и порт 587 (по умолчанию)
для агента подачи.
Глово 19. Электронной почто
5и>
19.2.
Анатомия почтового сообщения
Прежде чем перейти к вопросам конфигурирования программы sendmail,
рассмотрим структуру электронного сообщения. Оно состоит из трех частей:
•	конверт;
•	заголовки;
•	тело
Конверт определяет, куда должно быть доставлено сообщение или куда
его требуется возвратить в случае, если доставка невозможна. Обычно эти
адреса соответствуют указанным в заголовках “From" и “То’, хотя они
формируются отдельно средствами агента подачи почты. Конверт невидим
для пользователя и является внутренним средством программы sendmail.
Заголовки — это набор пар свойство/значение, отформатированных в
соответствии с документом R.FC822. В них содержится различная информация
о сообщении, в том числе дата и время его отправки, а также транспортные
агенты, через которые оно прошло на своем пути. Заголовки — это
неотъемлемая часть сообщения, но пользовательские агенты часто скрывают
некоторые менее интересные заголовки при отображении сообщения.
Тело сообщения — это та информация, которую собственно и требуется
переслать. Тело сообщения должно содержать ASCII-текст, однако часто он
представляет собой двоичные данные в специальной почтовой кодировке.
В параграфах, посвященных вопросам конфшурирования, мы иногда
будем говорить об отправителе и получателях конверта, а иногда — об
отправителе и получателях. указанных в заголовках. Там, где из контекста
не ясно, о чем идет речь, тип адреса будет конкретизирован.
Адресация почты
Механизм локальной адресации прост, потому что регистрационное имя
пользователя является уникальным идентификатором. Если же у адресата нет
учетной записи на локальном компьютере, то адресация и доставка услож-
няются.
Есть два вида почтовых адресов: маршрутно-зависнмые (относительные)
и маршрутно-независимые (абсолютные). При использовании первого способа
адресации требуется, чтобы отправитель знал промежуточные компьютеры,
через которые должно пройти сообщение на пути к получателю. В адресе
второго вида просто указывается пункт назначения. UUCP-адреса являются
маршрутно-зависимыми, а Intemei-адреса обычно не зависят от маршрута.
Почтовый lniemet-адрес имеет следующий формат:
пользовательвузел.домен
где символ @ отделяет имя пользователя от спецификации сетевого узла
Электронные сообщения доставляются в почтовый ящик указанного пользо-
вателя на комтгьютере узел.домен. В большинстве случаев домен — это обычный
DNS-домен. Например, в адресе evi@boulder.colorado.edn часть ’*evi” соответ-
ствует имени пользователя, "boulder" — это имя узла, а colorado.edu — имя
домена.
О DNS рассказывается в главе 16.
Раньше применялись адреса и других типов. В частности, речь идет о
некоторых вариантах маршрутно-зависимых адресов. Мы не будем описывать
570
Чость II. Робото в сетях
их детально, так как они устарели. Вместо этого приведем таблицу, в которой
показаны примеры таких адресов и их совремеиные эквиваленты.
Тоблицо 19.4. Примеры устаревших моршрутно-зовисимых адресов
Тип адреса Пример
Современная форма
UUCP	mcvax!uunet!ucbvax!hao!boulder!lairicvi evi@>lair
Мзршрутно-
зависимый
Процентный
< ©узел 1,@узел2,... ©узел Мполъзователъ
(^конечный _узел >
пользователъ%узел!%узел2@узелЗ
полъзаватель@конечный_узел
пользователъ&узел I
Основные сложности в конфигурации программы sendmail вызваны
существовавшей ранее необходимостью управлять указанными видами адре-
сов. Каждая из этих форм адресации связана с ретрансляцией, от которой
постепенно отказываются из-за активности спамеров. “Процентный” адрес
(указан последним в табл. 19.4) является любимым средством спамеров,
которые хотят скрыть свою личность или переслать почту через ничего не
подозревающие компьютеры-посредники. Подробнее о работе с такими
адресами можно узнать в документации к программе sendmail.
Зоголовки почтовых сообщений
Каждое электронное сообщение начинается несколькими строками,
которые называются заголовками и содержат информацию о сообщении.
Любой заголовок начинается с ключевых слов, таких как “То”, “From" или
“Subject”, после которых следуют символ двоеточия и содержимое заголовка.
Формат стандартных заголовков определен в документе RFC822. Однако
допускаются и заголовки других типов. Любой заголовок, начинающийся
символами “Х-”, игнорируется почтовой системой, но пересылается вместе
с сообщением. Следовательно, можно добавить в сообщение заголовок
наподобие “X-Joke-of-the-Day” и не беспокоиться о том, способна ли
почтовая система обработать его.
Одни заголовки добавляет пользовательский агент, а другие — транспорт-
ный Некоторые заголовки отражают путь сообщения. Большинство пользо-
вательских агентов скрывает эти неинтересные заголовки от пользователей,,
но, как правило, всегда имеется возможность заставить агента показать их.
Чтение заголовков становится важным делом, когда вас бомбардируют спамом
и нужно проследить, откуда он поступает. Ниже приведен блок заголовков
простого сообщения.
From evi Wed Jan 19 19:01:11 2000
Received: (from evi@localhost) by xor.com (8,9.3/8.9.3) is TAA17820;
Wed, 19 Jan 2000 19:01:11 -O70D(MST)
Date: Wed, 19 Jan 2000 19:01:11 -0700 (MST)
From: Evi Nemeth <Evi.NemethGxor.com>
Message-Id: <200001200201 .TAA17820@xor.coni>
To: trent@xor.com
Subject: xor.mc
Cc: evi@xor.com
Status: R
тело сообщения
Гповс 19. Электронной почто
571
Это сообщение не покидало локальной машины Его отправитель —
пользователь evi, а получатель — пользователь trenr. Первая строка “From"
добавлена программой mail.local, которая в данном случае выступила в
качестве агента доставки. Заголовок “Status” добавлен программой чтения
почты пользователя evi, а другие заголовки — программой sendmail (транс-
портным агентом). Каждый компьютер, участвующий в процессе передачи
сообщения, добавляет заголовок “Received”.
Заголовки электронного сообщения содержат массу информации о том.
где было сообщение, как долго оно там оставалось и когда, наконец, было
доставлено адресату. Ниже подробно описаны заголовки почтового сообще-
ния, посланного через Internet. Мы расскажем о назначении различных
заголовков, а также о том, какие программы их добавляют. Номера строк
(слева) даны для справки и частью сообщения не являются. Некоторые
заголовки разбиты на несколько строк, чтобы пример поместился на странице
1:	From eric@knecht. sendmail .org
Первую строку добавила программа /bin/mat! или mail.local в процессе
доставки, чтобы отделить это сообщение от других сообщений, находящихся
в почтовом ящике пользователя-получателя. Программы чтения почты
распознают границы сообщений путем поиска пустой строки, за которой
следует слово "From” (здесь обязательно наличие конечного пробела). Эта
строка не существует до тех пор. пока сообщение не будет доставлено, и ее
не следует путать со строкой, начинающейся выражением “From:”. Многие
программы чтения почты не отображают строку “From”, поэтому ес можно
и не увидеть.
2:	Return-Path: ericek.necht.sencur.a-1 .org
3:	Received: from anchor.cs.Colorado.EDU [root@anchor.cs.colcrado.edu
[128.138.242.1]) by colurnbine.es.colorado.edu (8.9. 3/8.9.2) wxth
ESMTP id HAA21741 for <evi@ruperr, sberg .cs .colorado.edu>; Fri, 1
Oct 1999 07:04:25 -0700 (MST)
4:	Received: from mroe.Colorado.edu (mroe.coiorado.edu 128.138.243._311)
by anchor.cs.colorado.edu (8.9.3/8.9.2) with ESMTP id HAA261J6
for <evi@anchor.es.Colorado.edu>; Fri, 1 Oct 1999 07:04:24
-0700 (MST)
5:	Received: from knecht.seriamail.org (-snecht.senamail.org
[209.31.233.1601) by mroe.cs.colcrado.edu (S.9.3/8.9.2} with
ESMTP id HAA09899 for <evi@anchor.cs-Colorado.edu>; Fri, 1 Oct
1999 07:04:23 -0700 (MST)
6:	Received: from knecht.sendmail.org (Localhost ,127.0.0.1]) by
knecht.sendniail.org (8.9.3/8.9.3} with ESMTP Id GAA18984;
Fri, 1 Oct 1999 06:04:02 -800 (PST)
В строке 2 указан адрес для возврата сообщения. Причем он может
отличаться от адреса, указанного ранее в строке "From". Сообщение об
ошибке посылается по адресу, заданному с строке "Return-Path", которая
содержит адрес конверта отправителя
В строках 3—6 содержится информация о продвижении сообщения по
различным системам на пути к почтовому ящику пользователя. Каждый
компьютер, который обрабатывает электронное сообщение, добавляет к его
заголовку строку “Received" Новые строки размещаются вверху, поэтому.
572
Чость II Роботе в сетях
□
читая строки “Received” последовательно, можно проследить путь сообщения
в обратном порядке (от получателя к отправителю). Однако если сообщение
является частью спама, то единственная строка '’Received”, которой можно
доверять, — это строка, сгенерированная локальным компьютером.
Каждая строка “Received" содержит имя машины-отправителя, имя
машины-получателя, данные о версии программы sendmail (или другого
транспортного агента) на машине-получателе, уникальный идентификатор
сообщения на машине-получателе, данные о пользователе-получателе, дату,
время и разность между временем в данном часовом поясе и временем по
Гринвичу. Эти сведения берутся из внутренних макроконстант программы
sendmail. Рассмотрим приведенные выше строки, начиная с последней, и
проследим путь сообщения от отправителя к получателю.
Из строки 6 видно, что сообщение поступило из интерфейса localhost
(который был выбран пользовательским агентом Эрика Оллмана, программой
exmh, для установления соединения) узла knecht на внешний интерфейс этого
узла посредством псевдоустройства обратной связи. В строке 5 отражен тот
факт, что компьютер knecht направил сообщение по адресу mroe.cs.colo-
rado.edu, несмотря на то что заданный пользователем адрес — evi@an-
chor.cs.colorado.edu. Быстрая проверка посредством программы nslookup или
dig показывает, что узел anchor имеет запись MX, которая ссылается на
компьютер mroe. что и вызывает перенаправление сообщения. Строка 5
демонстрирует различие между адресом конверта (evi@mroe.cs.colorado.edu) и
адресом получателя, указанным в заголовке (evi@anchor.cs.colorado.edu)
Подробнее о записях MX можно узнать в параграфе 16.11.
На компьютере mroe работает программа sendmail версии 8.9.3, и эта
программа присвоила данному сообщению идентификатор очереди НАА09899.
Затем сообщение было послано на узел anchor.cs.colorado.edu (строка 4), после
чего сразу же перенаправлено по адресу evi@nipertsberg.cs.colorado.edu (стро-
ка 3). Очередная смена адреса вызвана наличием псевдонима (подробнее об
этом рассказывается в- параграфе 19.4).
Псевдонимы играют большую роль в пересылке почты. Псевдоним ставит
имя пользователя в соответствие другому объекту, например имени этого же
пользователя на другом компьютере, группе пользователей или даже варианту
написания его имени. Таким образом, на основании содержимого одних лишь
заголовков невозможно определить, почему сообщение отклонилось от своего
пути. Как и в случае с записями MX, нужно искать внешние источники
информации.
Строки 5 и 4 содержат текст “for <evi@anchor.cs.colorado.edu>”. Он
определяет, как выглядит адрес получателя, когда сообщение поступает на
локальный узел. Эта информация полезна, если нужно исключить пользова-
теля из списка рассылки, отправив сообщение об отказе с того компьютера,
с которого была произведена подписка (возможно, много лет тому назад),
либо узнав адрес этого компьютера и включив его в тело сообщения.
В финальном заголовке “Received” (строка 3) содержится текст “for
<evi@rupertsberg.cs.colorado.edu>”. Значение макроконстанты программы send-
mail. хранящей адрес получателя, было изменено при по моши псевдонима
на узле anchor. Но вместо узла rupertsberg.cs.colorado.edu сообщение было
доставлено на компьютер columbine. Просмотр записей DNS показывает, что
на компьютере rupertsberg есть записи MX, ссылающиеся на компьютер
columbine. Они были определены в тот период, когда компьютер nipertsberg
обновлялся. Вероятно, по завершении работы эти записи забыли отменить.
Ггово 19. Электронной почто
573
Компьютер columbine, на котором работает программа sendmail версии
8.9.3, доставил сообщение в почтовый ящик Эви Немет (идентификатор
очереди — НАА21741).
7:	Message-Id: <1999100011404 .GAA18984@knecht. sendmail ,org>
В строке 7 содержится идентификатор сообщения. Он отличается от
идентификатора очереди, уникален во всемирной системе электронной почты
и добавляется к сообщению, когда оно попадает в почтовую систему.
8:	X-Mailer: exmh version 2.0.2 2/24/98
9:	То: Evi Nemeth <evi@anchor.cs.Colorado.edu>
10:	From: Eric Allman <eric@sendmail.com>
11:	CC: eric@sendmail.com
12:	Subject: Re: hi
13:	Date: Fri, 1 Oct 1999 06:04:02 -800
В строке 8 в качестве пользовательского агента Эрика Оллмана указана
программа exmh. Она сама добавила эту строку в заголовок. Заголовки,
которые начинаются символами “Х-”, не являются стандартными. В то время,
когда разрабатывались стандарты электронной почты, никто не мог предста-
вить, что когда-нибудь понадобится более чем один пользовательский агент,
поэтому такой заголовок и не был включен в число стандартных.
Строки с 9 по 13 — стандартные. Заголовок “Subject”, вообше-то, не
нужен, но большинство пользовательских агентов включает его. Строка “То”
содержит адрес основного получателя (или получателей). В строке “Dare”
указываются дата и время отправки сообщения. В данном случае время
отправки почти совпадает с заданным в строках '‘Received", несмотря на то.
что все значения брались на разных компьютерах.
Строки “Received” обычно добавляются транспортными агентами, а
другие заголовки создаются пользовательскими агентами. Некоторые пользо-
вательские агенты работают некорректно и не добавляют нужных заголовков.
В этом случае на помощь приходит программа sendmail.
Первая строка “Received” обычно создается машиной-отправителем, когда
сообщение поступает на выходной интерфейс. Иногда эта строка включает
фразу “ident", которая содержит регистрационное имя отправителя. Это имя
совпадает с указанным в строке “From’' (если последнюю не подменили).
В нашем примере на компьютере Эрика knecht не запущен демон, реализую-
щий эту функцию (identd), поэтому фраза “ident” у нас отсутствует.
На рис. Б изображен путь сообщения по системе электронной почты.
Показано, какие действия, где и какими программами выполнялись.
Нетрудно заметить, что программа sendmail в данном процессе выполняет
роль рабочей лошадки. Эта программа занималась сообщением с момента
его выхода из про|раммы exmh вплоть до прибытия на компьютер columbine
для доставки адресату.
Дополнительные примеры анализа заголовков приведены в конце
параграфа 19.10.
574
Чость II. Робото в сетях
Рис. Б. Путь сообщения от Эрика
19.3. Основные принципы организации электронной почты
Соблюдение принципов работы с электронной почтой, описанных в этой
главе, является почти обязательным условием нормального функционирова-
ния почтовых систем в средних и крупных организациях. Естественно, ими
можно руководствоваться и в небольших организациях. Существует несколько
основных факторов, которые позволяют значительно облегчить решение
административных задач. Это.
•	наличие серверов для входящей и исходящей почты или. в случае очень
больших организаций, иерархии серверов;
•	наличие почтового каталога для каждого пользователя в организации;
•	поддержка протоколов IMAP или POP’ для интеграции персональных
компьютеров, систем Macintosh и удаленных клиентов.
Каждый из этих факторов будет подробно проанализирован ниже. Кроме
того, необходимо добиться хорошего взаимодействия и функционирования
других подсистем и средств: записи MX службы DNS должны быть
правильными, брандмауэры должны обеспечивать прохождение почты внутрь
сети и наружу, должны быть определены компьютеры, иа которых органи-
зованы хранилища сообщений, и т.д.
[7[ Подробнее о записях MX рассказывается в параграфе 16.11.
Почтовые серверы выполняют три задачи:
•	принимают исходящую почту от пользовательских агентов и направляют
ее в почтовую систему;
•	принимают входящую почту из внешнего мира;
•	доставляют почту на рабочие места конечных пользователей посредством
протокола IMAP или POP.
В небольшой организации серверы, реализующие указанные функции,
могут работать на одном компьютере. В больших сетях для них следует
выделить отдельные машины. Настройка брандмауэра значительно упростит-
ся, если входящая почта будет поступать на один компьютер, а исходящая
почта будет отправляться с другого.
• Сейчас предпочтение отдается протоколу 1МАР.
Глово 19. Электронная гочто
575
В некоторых организациях внешняя почта поступает на прокси-сервер.
В действительности прокси-сервер не обрабатывает почту, а лишь принимает
и накапливает ее у себя. Отдельный процесс затем переправляет эту почту
программе sendmaD для транспортировки и обработки. Примерами прокси-
серверов для программы sendmail являются демоны smtpd и smtpfwdd (доступны
на Web-узле www.obtuse.com). Оба демона распространяются свободно. Демон
smtpd способен фильтровать входящую почту на основании списков доступа.
Почтовые серверы
Для почтового сервера необходимо выбрать надежный и стабильно
работающий компьютер Ниже мы опишем структуру почтовой системы,
которая, как нам кажется, является легко масштабируемой, хорошо управ-
ляемой и безопасной. Задачи управления входящей и исходящей почтой к
ней выполняют специально выделенные для этой цели серверы. Одна из
таких структур приведена на рис. В.
Рис. В. Архитектуре почтовой системы (ворионт 1)
Почтовая система, изображенная на рис В. имеет одну точку получения
данных нз внешнего мира — это почтовый сервер, принимающий сообщения
из сети Internet. Такой сервер можно снабдить средствами мониторинга,
установить на нем дополнительные средства безопасности н последнюю
версию программы sendmail, включающую фильтры для борьбы со спамом.
Сервер, который отвечает за исходящую почту, также должен быть хорошо
управляемым. Он может содержать собственные фильтры от спама для
проверки того, не является ли кто-нибудь из локальных пользователей
инициатором спама. Когда есть риск утечки информации из внутренней сети,
наличие одного-единственного сервера, через который проходит исходящая
почта, упрощает реализацию правил безопасности и контроль над их
соблюдением. Если а организации используются большие списки рассылки,
на сервере исходящей почты можно установить средства программы sendmail.
предназначенные для повышения производительности.
Если объем почтовых сообщений очень велик, обеспечьте репликацию
серверов входящей и исходящей почты. Но учтите, что данные между ними
не должны передаваться напрямую. Серверы следует отделить друг от друга
посредством внутреннего брандмауэра.
Провайдеры, проектирующие почтовые системы для обслуживания кли-
ентов, должны установить дополнительный сервер, на который будут
указывать резервные записи MX клиентов и который будет управлять
576
Чость II Робото в сетях
списками рассылки. Этот компьютер должен принимать почту и распростра-
нять ее среди клиентов. Его следует жестко контролировать на предмет того,
что почта отправляется только аутентифицированным клиентам, и отделить
брандмауэром от серверов входящей и исходящей почты.
На пользовательских UNIX-системах достаточно установить программу
sendmail в минимальной конфигурации, чтобы они могли пересылать исхо-
дящую почту соответствующему серверу для обработки. Нет необходимости
реализовывать на таких компьютерах прием почты из Internet. Однако иногда
от этой жесткой модели отступают и разрешают любым UNIX-станциям
посылать почту непосредственно в Internet. В любом случае все клиентские
компьютеры могут иметь одинаковую конфигурацию программы sendmail.
Организовать распространение такой конфигурации можно с помощью
программы rdist или rsync
Подробнее о вопросах распространения файлов рассказывается в параграфе 18.2.
В организациях, где используются программы наподобие Microsoft
Exchange и Lotus Notes и где нежелательно предоставлять этим программам
прямой выход в Internet, можно применять архитектуру почтовой системы,
изображенную на рис. Г.
Входящая почто
Исходящая почта
Пользовательские почтовые агенты
Рис. Г. Архитектуре почтовой системы {ворионт 2)
Вне зависимости от того, какая структура почтовой системы выбрана,
позаботьтесь о том, чтобы конфигурация программы sendmail, записи MX и
правила работы брандмауэра соответствовали обшей политике работы с
почтой в вашей организации.
Почтовые котологи пользователей
Естественно, пользователю удобно читать всю свою почту на одном
компьютере, даже если у него есть учетные записи в нескольких системах.
Эта возможность реализуется с помощью файла aliases, поля maildrop
пользовательской базы данных или даже базы данных LDAP. Удаленный
доступ к каждому из почтовых ящиков пользователей можно организовать
при помощи протокола IMAP или POP.
Схема создания псевдонимов, которой мы пользуемся, позволяет нам
иметь один и тот же файл псевдонимов на всех компьютерах домена. С точки
зрения администратора это большой выигрыш. (Мы предполагаем, что
регистрационные имена и идентификаторы пользователей уникальны на всех
компьютерах, и настоятельно рекомендуем проводить такую политику.)
Глово 19 Электронноя почта
577
В некоторых организациях систему электронной почты централизуют,
экспортируя каталог /var/spool/mail через NFS. Но проблемы блокировки
файлов NFS могут привести к потере или повреждению файлов, хранящих
почту пользователей. Можно, конечно, потом обвинять NFS, программу
sendmail или агентов доставки, ио это вряд ли поможет несчастному
пользователю, чей почтовый яшик поврежден (программа sendmail всегда
невиновна, потому что в действительности она никогда не доставляет почту).
Некоторые варианты реализации NFS (например, с использованием
выделенных файловых серверов) включают программу управления блокиров-
ками, которая работает нормально. Но большинство реализаций либо не
поддерживают блокировку, либо делают это не так. как нужно. В одних
организациях проблему блокировки просто игнорируют, надеясь на авось, а
в других — требуют, чтобы пользователи читали почту на файловом сервере
Наш совет: не используйте совместный доступ к каталогу /var/spool/mail
через NFS.
Протоколы IMAP и POP
IMAP и POP — это протоколы, которые загружают почту на пользова-
тельские компьютеры, когда те подключаются к сети. Данные протоколы
являются идеальным средством управления почтой, особенно для компьюте-
ров. которые нс всегда подключены к сети из-за того, что выключаются
после работы илн размешены дома и соединяются с сетью по телефонной
линии.
Протокол IMAP (Internet Message Access Protocol — протокол доступа к
сообщениям в сети Internet), который создан в университете штата Вашинг-
тон, является более предпочтительным средством Он доставляет сообщения
по одному, а не все сразу. Такой метод лучше для тех пользователей, которые
подключены к медленной сети или имеют портативные компьютеры.
Протокол 1МАР особенно удобен при отборе писем с объемными вложения-
ми: можно просматривать заголовки сообщений и не загружать письма с
вложениями до тех пор, пока не будет выяснено их содержимое. Протокол
IMAP управляет почтовыми папками в нескольких системах, например на
почтовом сервере и персональном компьютере. Почта, находящаяся на
UNIX-сервере, может быть объектом резервного копирования. (Много
полезной информации о протоколе IMAP и его реализациях можно найти
на Web-узле www.imap.org.)
POP (Post Office Proiocol — почтовый протокол) — это протокол,
реализующий похожую модель, в которой, однако, все сообщения загружа-
ются с сервера на персональным компьютер. При этом они могут удаляться
с сервера (зачастую безвозвратно) или сохраняться на нем (в этом случае
хранилище почты будет постоянно увеличиваться в размерах). Метод доставки
всей почты за раз не оптимален для сети и не очень гибок с точки зрения
пользователя. Это особенно проявляется в коммутируемых соединениях.
(Приемлемая реализация POP доступна по адресу www.cudora.com/qpopper.)
Программное обеспечение сервера IMAP можно найти по адресу
www.washingion.edu/iinrfp. Конфигурировать сервер пе требуется, нужно лишь
поместить соответствующие IMAP-ianucu в файлы /cic/services и
/etc/inetd-conf. Кроме того, следует убедиться, что брандмауэр не препятствует
работе сервера С протоколом IMAP раньше было связано много проблем
безопасности, поэтому старайтесь пользоваться самыми последними версиями
программ.
578
Чость II. Робота в сетях
19 4. Почтовые псевдонимы
Псевдонимы позволяют системному администратору и отдельным поль-
зователям переадресовывать почту*. Имн можно пользоваться для задания
списков рассылки, для пересылки почты между компьютерами и для того,
чтобы к пользователям можно было обращаться по нескольким именам.
Псевдонимы обрабатываются рекурсивно, поэтому' могут указывать на
объекты, которые, в свою очередь, являются псевдонимами.
Программа sendmail поддерживает несколько механизмов создания псев-
донимов, а именно: протокол LDAP, службы NIS и NIS+, систему Nel Into
(разработка NeXT/Apple), базы данных почтовой маршрутизации, а также
различные файлы псевдонимов, которые могут создаваться пользователями
и системными администраторами.
Если требуется придерживаться концепции личных почтовых каталогов
пользователей, рекомендуем реализовать ее путем хранения псевдонимов на
сервере LDAP. Другие методы обладают рядом недостатков. Традиционными
файлами псевдонимов обычно должен управлять пользователь root В случае
базы данных псевдонимов ее приходится перестраивать при каждом измене-
нии, а затем реплицировать на все компьютеры, которые доставляют почту.
В тех организациях, где имеется много виртуальных доменов, в каждом домене
ведется отдельный фрагмент файла псевдонимов, з общий файл псевдонимов
собирается посредством специального сценария.
Сам по себе протокол LDAP не может работать с псевдонимами списков
рассылки. Ими лучше управлять при помоши стандартных механизмов
псевдонимов.
Программа sendndmail работает с сервером LDAP почти гак же. как с
сервером DNS. Сервер DNS необходим для преобразования имен в 1Р-адрсса.
чтобы можно было определить, куда следует послать сообщение. Аналогичным
образом с помощью сервера LDAP ведется поиск псевдонимов, позволяющих
перенаправлять почту в правильное место. В обоих случаях поиск начинается
в простых файлах (/etc/hosts и /etc/aliases) и заканчивается в базе данных.
Протокол LDAP подробно описан в этой главе, а также в главе 18.
В конце этого параграфа мы расскажем о том. как работает данный протокол,
затем, в параграфе 19.S. рассмотрим вопросы взаимодействия LDAP и sendmail
и, наконец, в параграфе 19 9 приведем пример использования протокола для
создания псевдонимов и виртуального хостинга.
Однако прежде всего следует рассмотреть традиционные способы назна-
чения псевдонимов. Псевдонимы могут быть определены в трех местах (к
сожалению, с использованием трех разных синтаксисов):
•	н файле конфигурации пользовательского агента (пользователем-отпра-
вителем);
•	в общесистемном файде псевдонимов /clc/mail/aliases (системным адми-
нистратором);
•	в пользовательском файле переадресации '/.forward (пользователем-по-
лучателем).
Пользовательский агент ищет псевдонимы в файлах конфигурации
пользователя и раскрывает их до подачи сообщения в почтовую систему.
• С технической точки зрения псевдонимы конфигурирует только системный администратор.
Пользователи управляют маршрутизацией почты при помоши файла .forward, который в
действительное гм нс имеет прямого отношения к псевдонимам, но мы объединили здесь
оба этих средства
Глово 19 Электронной почто
579
Транспортный агент, т.е. программа sendmail. ищет псевдонимы и глобальном
файле aliases, а затем в общесистемном файле .forward или в файлах
переадресации получателей. Псевдонимы применяются только к тем сообще-
ниям, которые программа sendmail считает локальными.
Вот несколько примеров определения псевдонимов в файле aliases*
nenterh: evi
evi: evi@mailhub
authors: evi,garth,scett,rrent
В первой строке указано, что почту, поступающую на нмя nemeth. следует
доставлять пользователю evi на локальном компьютере. Во второй — что всю
почту, приходящую на имя evi, следует доставлять на компьютер mailhub.
И наконец, третья строка определяет, что почту, адресованную группе authors,
следует доставлять пользователям evi, garth, scoti и trent. Благодаря рекурски,
почта, посланная на имя nemeth. попадет по адресу evj@mailhub.
Глобальные псевдонимы определяются н файле /etc/mail/aliases (в неко-
торых системах — /usr/lib/aliases или /etc/aliases). Местонахождение файла
aliases указывается в файле конфигурации программы sendmail. Допускается
наличие нескольких файлов aliases, а также использование альтернативных
механизмов, например службы NIS или специальных баз данных.
Более подробную информацию о службе NIS можно найти в главе /8.
Записи файла aliases имеют следующий формат:
покалл.ное_иыя: получатель!, полу чатель2, ...
где .юкальное_имя — это адрес, сопоставляемый с адресом входящего
сообщения, а список получателей содержит либо адреса получателей, либо
другие псевдонимы. Строки с отступом считаются продолжением предыдущих
строк.
С точки зрения системы электронной почты файл aliases имеет приоритет
над файлом /etc/passwd, поэтому существование записи
david; david@somewhere_else.edu
не позволит локальному пользователю david вообще когда-либо получить
почту. По этой причине при добавлении новых пользователей (вручную или
с помощью сценария adduser) необходимо проверять и файл passwd, и файл
aliases.
Файл /etc/mail/aliases всегда должен содержать псевдоним postmaster,
который обеспечивает пересылку сообщений лицу, отвечающему за работу
электронной почты. Кроме того, должен существовать псевдоним для
автоматических сообщений программы sendmail. Обычно он называется
Mailer-Daemon и эквивалентен псевдониму postmaster.
Почту, приходящую на имя root, необходимо переадресовывать админи-
стратору или лицу, которое входит в систему ежедневно. Учетные записи bin,
sys, daemon, nobody и hoslmaster (и все остальные имеющиеся в системе
псевдопользовательские учетные записи) также должны располагать псевдо-
нимами, с помощью которых осуществлялась бы пересылка почты реальному
пользователю. Файл sendmall/aliases из дистрибутива программы является
хорошим шаблоном для создания псевдонимов системного уровня В нем
можно найти советы относительно безопасности и примеры того, как
обрабатываются некоторые пользовательские запросы.
580
Чость II Роботе в сетях
Программа sendmail выявляет циклы в псевдонимах, способные привести
к бесконечной пересылке почты к месту назначения и обратно. Программа
подсчитывает число строк “Received” в заголовке сообщения и, как только
это число превышает установленный лимит (обычно он равен 25) . возвращает
сообщение отправителю. Каждое посещение сообщением нового компьютера
на жаргоне разработчиков sendmail называется “прыжком” (hop), а возвра-
щение сообщения отправителю — “рикошетом" (bounce)' .
Помимо списков пользователей псевдонимы могут обозначать
•	файл, содержащий список адресов;
•	файл, в который должны добавляться сообщения;
•	команду, на вход которой должны передаваться сообщения.
Поскольку отправитель сообщения полностью определяет его содержи-
мое, указанные выше элементы часто используются хакерами. Однако
программа sendmail очень подозрительна в отношении владельцев н прав
доступа к таким файлам и командам. Чтобы избавить программу от этой
подозрительности, нужно установить одна' из опций DontBlareSenarnail.
К сожалению, сообщения об ошибках, которые генерируются программой
sendmail при обнаружении нарушении, касающихся прав доступа и владельцев
файлов, не всегда понятны.
Получение списков рассылки из файла
Директива :include: является отличным способом управления пользо-
вательскими списками рассылки. Она позволяет не указывать объекты,
обозначаемые псевдонимом, непосредственно в файле aliases, а брать их из
внешнего файла. Этот файл можно изменять без вмешательства системного
администратора, отвечающего за глобальный файл aliases
Для создания списка рассылки системный администратор должен ввести
псевдоним в глобальный файл aliases, а затем создать подключаемый файл
и при помощи команды chown сделать его владельцем пользователя,
управляющего списком рассылки. Например, файл aliases может содержать
строку:
sabook.: :include: /usr/Local/raail/usah. readers
Файл usah.readers должен находиться в локальной файловой системе, а
не в системе, смонтированной средствами NFS Кроме того, запись в jtoi
файл должна быть разрешена только его владельцу. Для полноты нужно также
создать псевдоним. соотиетсизующпн владельцу списка рассылки, с тем чтобы
сообщения об ошибках (“рикошеты’’) посылались владельцу, а не отправи-
телю сообщения*
owner-sabook :evi.
Число 25 задано по умолчанию. Этот параметр можно измешггь в файле конфигурации
В этой главе мы несколько непоследовательны в терминолог ни, иногда называя возвращае-
мое сообщение “рикошетом", иногда — “сообщением об ошибке". Оба герм и па ошачаюг
одно и то же: сообщение, которое оказалось невозможно доставить адресату, поэтому оно
возвращается обратно, обычно отправителю.
Если файловая система смонтирована с флагом hard и сервер NFS выйдет из строя, то
программа sendmail “зависнет”. При этом останутся открытыми дескрипторы некоторых
файлов и окажутся заблокированными некоторые процессы. Это может привести к превы-
шению лимитов на число процессов и открытых файлов. В результате придется перезагру-
зить компьютер.
Глово 19 Электронная почто
581
О списках рассылки и их взаимосвязи с файлом aliases речь пойдет чуть
ниже.
Исправление почты в файл
Если объект, на который указывает псевдоним, — это абсолютное путевое
имя файла (заключенное в двойные кавычки при наличии специальных
символов), то сообщения добавляются в указанный файл Сам файл должен
существовать. Вот пример псевдонима:
complaints: /dev/null
Возможность посылать почту в файл иди на вход программы очень
полезна, но она ослабляет безопасность и поэтому должна быть ограничена.
Приведенный синтаксис подходит только для файлов aliases и пользователь-
ских файлов .forward (а также для файлов, которые присоединяются к ним
посредством директивы : incl ode:). Имена файлов не трактуются как адреса,
поэтому почта, направленная по адресу /eic/passwd@host. domain. будет
возвращена.
В базах данных LDAP нельзя указывать файлы в качестве места доставки
почты Некоторые пользовательские агенты позволяют направлять почту в
локальный файд {например, в папку исходящей почты), но таким способом
создается копия сообщения, т.е. сообщение в действительности не посылается
в почтовую систему.
Если ссылка на файл содержится в файле aliases, то адресуемый файл
должен либо иметь разрешение на запись для всех пользователей, либо иметь
установленный бит смены идентификатора пользователя (SUID) и быть
иеистюлняемым, либо принадлежать основному пользователю программы
sendmail Этот пользователь ?адается при помоши опции DefaultUser
Обычно им является пользователь rnailnnll. daemon или пользователь со
значениями UID и G1D. равными I.
Если же ссылка на файл содержится в файле .forward, то адресуемый
файл должен принадлежать и быть доступным для записи основному
получателю сообщения. Необходимо, чтобы этот пользователь был указан в
файле /etc/passwd. а его интерпретатор команд был упомянут в файле
/etc/shells. Для файлов, принадлежащих пользователю root, следует задать
режим доступа 4644 или 4600. т.е. установить бит SUID и отменить
возможность выполнения.
Направление почты в программу
Благодаря псевдонимам можно организовать перенаправление почты на
вход заданной программы. Это реализуется с помощью строки примерно
следующего вила:
autoftp: "1/usr/local/bin/ftpserver"
Однако использование такого механизма создает еше более серьезные
бреши в защите, чем направление почты в файл, поэтому данный механизм
разрешен только для файлов aliases и .forward, а также для файлов, которые
присоединяются к ним посредством директивы : include:. В файле aliases
программа вызывается от имени основного пользователя программы sendmail.
в остальных случаях — от имени владельца файла .forward или подключаемого
582
Чость II Робою в сетях
файла. Такой пользователь должен быть указан в файле /etc/passwd, а его
интерпретатор команд должен быть упомянут в файле /etc/shells.
Вызываемая программа использует каталог очереди программы sendmail
в качестве рабочего, но не всем интерпретаторам команд разрешен к нему
доступ. Если выдается сообщение об ошибке, просмотрите в документации
сведения о флаге D= агента доставки.
Направление почты в файл создает потенциальную брешь в системе
зашиты. Поэтому из соображений безопасности не следует использовать
программу /bin/sh в качестве агента доставки. Вместо этого применяйте
программу snirsh, которая представляет собой усеченный интерпретатор
команд sendmail (о ней речь пойдет в параграфе 19.11).
Примеры псевдонимов
Вот некоторые псевдонимы, которые могут понадобиться системному
администратору:
i Обязательные псевдонимы
postmaster: trcuDle, evi
postmistress: postmaster
MAILER-DAEMON: postmaster
hostmaster: trent
abuse: postmaster
webmaster: trouble, trent
root: trouble, trent
Usenet: newsmaster
#	Списки рассыпки для "проблемней" почты
trouble: :include:/usг/local/mail/trouble.alias
trouoletiap: ’*/usr/local/mail/logs/troublemail'*
tmr: troubletrap, zinclude:/usr/local/mail/trnr. alias
It Для удобства системного администратора
diary: "/usr/local/admln/diary"
info: "i/usr/local/bin/sendinfo”
I Псевдонимы учебных классов, меняющиеся каждый семестр
sa-class: real-sa-classPnag
real-sa-class: ;include:/usr/local/adm/sa-class.list
В данном примере мы хотим, чтобы при возникновении проблем все
пользователи университетского городка могли посылать почту по одному
псевдониму: trouble. Отчеты о проблемах всегда должны направляться
соответствующей группе местных системных администраторов. Мы считаем,
что почтовые псевдонимы нужно задавать так, чтобы:
•	почтовые сообщения о неисправностях всегда поступали в соответствую-
щую локальную группу;
•	на всех компьютерах использовался одинаковый файл псевдонимов;
Это не совсем верно. На самом деле нужны только псевдонимы postmaster и MAILER-
DAEMON (этого требуют документы RFC). Однако обычно включают еще псевдонимы
hostmaster, abuse, webmaster.
Глово 19. Электронной почто
583
•	отдельные группы администраторов контролировали свои собственные
списки рассылки;.
•	копии всех почтовых сообщений о неисправностях поступали в локальный
журнальный файл каждой группы
В приведенном выше примере эти цели достигнуты: определение
псевдонима trouble берется из одного и того же файла на каждом компьютере.
Почта по адресу lrouble@anchor и почта по адресу irouble@boulder попадает
в конце концов в разные места, несмотря на то что на компьютерах anchor
и boulder используется один и тот же файл /etc/mail/aliases
В пределах каждого факультета почтовые сообщения о неисправностях
обычно обрабатываются на одном компьютере. Например, прн наличии адреса
С rouble^главный—компьютер
в файле trouble.alias на подчиненном компьютере сообщения о неисправностях
направляются на соответствующий главный компьютер.
Поступившее сообщение посылается псевдониму tmr. под которым
скрываются читатели почты о неисправностях. Псевдоним tmr задан таким
образом, что сообщение сначала записывается в журнальный файл благодаря
псевдониму troubletrap, а затем рассылается пользователям, список которых
берется из файла на главном компьютере Включение администраторов-но-
вичков в список tmr — хороший способ ознакомить их с типичными
вопросами по сопровождению системы, с ответами администраторов и с тем
льстивым тоном, которым нужно общаться с пользователями.
Данный механизм — лишь верхушка айсберга, малая часть солидной
системы обработки диагностической электронной почты queuemh, построен-
ной на базе пользовательского агента rnh.
Псевдоним sa-class является двухуровневым, поэтому файл данных,
содержащий список студентов, может управляться с одного компьютера: nag.
Для псевдонима sabook, приводившегося в одном из предыдущих примеров,
также должен использоваться такой подход, чтобы нс требовалось копировать
подключаемый файл.
Псевдоним diary очень удобен для тех студенческих администраторов,
которым требуется документировать свои действия В файле diary системные
администраторы могут хранить сообщения о важных событиях в жизни
компьютера (обновление ОС и аппаратных средств, поломки и т.п.). Однако
не помещайте этот файл в ту же файловую систему, что и журнальные файлы.
Хакеры могут добиться переполнения файловой системы и тем самым
воспрепятствовать записи в журнальные файлы (что позволит им замести
следы).
Переноправление почты
Файл aliases — это общесистемный конфигурационный файл, который
должен вестись администратором. Если какой-нибудь пользователь захочет
перенаправлять свою почту (а для доступа к почте в организации не
применяется протокол POP ii.m IMAP), он сможет сделать это путем создания
файла .forward в своем начальном каталоге. Раньше программа sendmail всегда
просматривала начальные каталоги пользователей па предмет наличия файла
.forward. однако сейчас для включения данного режима необходимо исполь-
зовать переменную ForwardPatti. Файл .forward часто применяется в случае,
когда пользователь хочет получать почту на конкретном компьютере или
584
Чость II Роботе в сетях
когда он переходит из одного подразделения в другое и хочет, чтобы почта
пересылалась туда.
Файл .forward состоит из одной строки, в которой содержится список
разделенных запятыми адресов, или из нескольких строк с адресами в каждой
Например:
evlGipn.caida.org
evi^xor.com
ИЛИ
\mcbryan, "/home/mcbryan/archive", mctoryanGflsupil.gmd.de
В первом примере по’гга пользователя evi не будет сохраняться на
локальном компьютере, а будет пересылаться на компьютер ipn в организации
CAIDA (Сан-Диего) и на узел xor.com. Второй пример — это запись
пользователя, который не доверяет почтовым системам и хочет, чтобы его
почта копировалась в три места: в обычный почтовый каталог на локальном
компьютере, в постоянный архив всей входящей почты и по временному
адресу в Германии, где он в настоящей момент находится. Обратная косая
перед именем пользователя предписывает сохранять почту на локальном
компьютере вне зависимости от того, что задают файлы aliases и .forward.
Если речь идет о временных изменениях в системе маршрутизации почты,
то лучше использовать файл .forward, чем глобальный файл aliases. Накладные
расходы (машинное и пользовательское время), необходимые для изменения
общесистемных псевдонимов, довольно высоки.
Пользовательский файл .forward должен принадлежать данному пользо-
вателю и не иметь разрешения на запись для группы п остальных
пользователей. Если программа sendmail решит, что путь к файлу .forward
является безопасным (т.е. на пути от корневого каталога не нарушаются права
доступа), то файл .forward будет включен в почтовую систему. В противном
случае присоединения не произойдет, так как подозрительные файлы .forward
игнорируются. Права доступа к родительскому каталогу также должны быть
правильными (т.е. право записи должен иметь только тот пользователь,
который владеет файлами).
Естественно, программа scndinail должна обладать правом доступа к
начальному каталогу' пользователя на компьютере, куда доставляется почта,
ведь программе нужно определить, имеется ли там файл .forward. Если
изменение адреса носит постоянный характер, его необходимо внести в файл
/ctc/mail/aliases, так как начальный каталог и файлы пользователя будут в
конечном итоге удалены.
Программа sendmail располагает чудесным средством. FEATURE (1 redi-
rect 1), которое позволяет обрабатывать изменения почтовых адресов. Если
псевдоним пользователя указывает иа адрес по,гьзователъ@ковый_адрес.ИЕ01-
RECT. почта возвращается отправителю с уведомлением о новом адресе.
Поскольку сообщение не пересылается по новому адресу, отправитель
вынужден внести изменение в свою адресную книгу’ и повторно послать
сообщение.
Программу sendmail можно сконфигурировать на поддержку центрального
каталога для файлов .forward. Это, однако, удобнее для программы sendmail.
а не для пользователей Местоположение файлов .forward задается опцией
ForwardPar.h, которая указывает сначала на центральный каталог. а затем
на начальный каталог пользователя. В доменном файле generic.m4 (приведен
в параграфе 19.9) содержится пример задания центрального каталога для
файлов .forward.
Глово 19 Электронноя почто
585
Записи глобального файла aliases имеют приоритет нал записями файла
.forward. Поскольку эти файлы ведутся разными людьми, следует действовать
очень аккуратно и следить, чтобы не создавались "почтовые циклы". Если
пользователь сети имеет почтовый каталог (и. следовательно, запись в
глобальном файле aliases), он не может с помощью файла .forward перена-
правлять почту на компьютер, где используется такой же файл псевдонимов.
Например, в университете штата Колорадо, где мы применяем глобальный
файл aliases, запись
evi: eviSboulder
и файл .forward на компьютере boulder, содержащий строку
evi@anchor. cs
создадут “почтовый цикл”. Почта, адресованная пользователю ей. будет
направляться на компьютер boulder где в файле .forward задана ее пересылка
на компьютер anchor в поддомене “cs”. Однако в файле aliases на компьютере
anchor содержится указание пересылать почту обратно на компьютер boulder .
После 25 переходов почта будет возвращена отправителю.
Если ваш основной способ коммуникации — электронная почта, то
уведомить пользователя о возникновении “почтового цикла" непросто Когда
псевдоним задан в виде \пояьзивателъ . почта будет доставляться на локальный
компьютер независимо от того, что указано в общесистемном файле aliases
и пользовательском файле .forward. Если именно на этом компьютере
пользователь ожидает получить почту’ — прекрасно, если нет, пошлите
сообшешге о цикле псевдониму postmaster или обратитесь к проверенному
средству: телефону.
Хэшированная база данных псевдонимов
Поскольку элементы в файле aliases расположены неупорядоченно,
прямой поиск в этом файле был бы для программы sendmail неэффективным.
Поэтому создается хэшированная версия файла aliases. Это делается либо
средствами библиотеки Berkeley DB либо с помощью программы ndbm,
которая является стандартом для большинства версии UNIX. Хэширование
значительно ускоряет поиск псевдонимов, особенно в больших файлах.
Файлы, образованные из файла /etc/mail/aliases, нашваются aliases.dh
(если они получены средствами DB) или aliases.dir и aliases.pag (в случае
использования ndbm) Файл с расширением dir — это индекс для файла с
расширением pag. в котором находятся данные. При каждом изменении файла
aliases хэшированную базу данных следует перестраивать с помошыо команды
newaliascs, которая просто вызывает программу sendmail со специальными
флагами командной строки (-bi), указывающими на необходимость перестрой-
ки базы данных. Если команда newaliascs вызывается в автоматическом
режиме, сохраняйте выходные сообщения об ошибках, поскольку' могут быть
проблемы с форматированием.
Компилируя программу sendmail, нужно включить поддержку базы данных
либо для библиотеки dbm/ndbm, либо для библиотеки Berkeley DB, либо для
обеих сразу. Если подключены обе библиотеки и создается файл базы данных,
тип которого не указан, используется версия DB. Если применяется служба
Возможно, придется использовать не один, а два или более символов обратной косой черты,
чтобы один из них "прошел" интерпретатор команд н попал в программу sendmail.
5в6
Чость II. Робото в сетях
NIS, программа sendmail создаст базы данных обоих типов, но работать будет
только с версией DB.
Подробнее о NiS рассказывается в главе 18
Библиотека Berkeley DB написана и сопровождается Китом Бостиком
(Keith Bostic) и Марго Сельцер (Margo Seltzer); ее код можно получить на
Web-узле www.sleepycat.com. Оиа намного лучше (обеспечггвает более быстрый
доступ и меньшие размеры файлов базы данных), чем программа ndbm
Библиотека имеет открытый код и свободно распространяется при условии,
что она не входит в состав коммерческого продукта. В противном случае
требуется приобрести лицензию
Списки рассылки и программы для работы с ними
Список рассылки — это громадный псевдоним, при помоши которого
копия каждого сообщения, адресованного списку, передается каждому члену
списка. Списки рассылки подобны группам новостей Usenet, в которых
новости распространяются посредством электронной почты.
Списки рассылки обычно объявляются в файле aliases, но формируются
во внешнем файле. Существуют стандартные соглашения по присвоению
имен, понятные программе sendmail и специальным программам ведения
списков рассылки. Опытные пользователи гоже придерживаются их Эти
соглашения иллюстрируются следующими примерами;
mylist: : include:/etc/mail/inelude/mylist
owner-niylist: mylisC-request
mylist-request: evi
owner-owner: postmaster
где mylist — имя списка рассылки; в файле /elc/mail/include/mylisl содержится
список его членов. Сообщения об ошибках, возникающие при отправке почты
по списку рассылки, и запросы на включение в список новых членов
посылаются его владельцу: пользователю evi Косвенная адресация
“владелец — запрос — пользователь” удобна, гак как адрес владельца
(mylist-request) становится адресом "Return-Path” каждого сообщения, посы-
лаемою в список рассылки. Псевдоним mylist-request — более подходящая
форма, чем настоящее имя владельца. Сообщения об ошибках при направ-
лении писем псевдониму owner-niylist (на самом деле это evi) посылаются
псевдониму owner-owner.
Если доставку сообщения выполнить невозможно и владельцу списка
возвращается сообщение об ошибке, это называется рикошетом (bounce).
Если же невозможно доставить само сообщение об ошибке, то уведомление
об этом называется двойным рикошетом. В нашем примере такое уведомление
посылается псевдониму owner-owner (т.е. postmaster).
Когда попользуется общесистемный файл псевдопимоп, необходимо
ввести сшс одни уровень косвенной адресации, связав псевдоним mylist с
адресом реальное_и»я_списка@главный_коАгныотер. чтобы файл данных, со-
держащий список членов, хранился только в одном месте.
Существует несколько пакетов программ, которые автоматизируют работу'
со списками рассылки. С их помощью пользователи могут добавлять и удалять
себя из списка, просматривать информацию о списке, получать файлы по
электронной почте и т.д. Среди этих пакетов отметим следующие:
• Majordomo (vyvw.greaicircle.com);
Глово 19. Электронное почто
587
•	Mailman (www.lisi.org);
•	ListProc (www.cren.nei);
•	SmartList (www.procrnail.org);
•	LISTSERV Lite (www.lsoft.com)*.
Хороший FAQ-архив на тему программ для списков рассылки составлен
Нормом Алексом (Norm Aleks) и доступен на FTP-узле rtfm.mit.edu (ишите
раздел mail/list-admin). К сожалению, этот архив больше не пополняется,
поэтому может содержать несколько устаревшую информацию. Тем не менее
в нем много полезных сведений, способных помочь в выборе нужной
программы.
SmartList — самая простая и маленькая по объему программа из данного
перечня, a ListProc — самая большая и сложная. Остальные, согласно этому
критерию, находятся где-то посредине. Они отличаются методами управления
списками рассылки. Одни больше ориентированы иа администраторов
(ListProc), другие — на пользователей, управляющих списками рассылки
(Majordomo, Mailman, SmartList, LISTSERV Lite). Программы Majordomo n
LISTSERV Lite поддерживают удаленное администрирование. Управляющему
списком даже не нужно регистрироваться иа том компьютере, где находится
список, поскольку все операции осуществляются по электронной почте.
Большинство программ позволяет создавать информационные подборки
(дайджесты) на основе материалов, публикуемых в списке рассылки. Одни
делают это автоматически (ListProc, Mailman, LISTSERV Lite), а другие —
после соответствующего конфигурирования вручную (SmartList, Majordomo).
Мы предпочитаем использовать Majordomo, однако, по слухам, некоторые
организации переходят на Mailman. Програмкгы ListProc и LISTSERV Lite
являются коммерческими, поэтому менее предпочтительны; первая — доро-
гая, а вторая — доступна только в двоичных кодах и ненадежна в работе.
Мы не пробовали работать с пакетом SmartList. однако нам нравится
программа procmail, на основе которой он построен.
Ниже кратко описана каждая из этих программ. За более подробной
информацией обращайтесь к документации.
Majordomo
Majordomo — это написанный на языках Perl и С программный пакет,
который можно получить иа Web-узле www.greatcircle.com. Программа была
создана Брентом Чапманом (Brent Chapman), улучшена Джоном Руйаром
(John Rouillard), а в настоящее время сопровождается Чаном Уилсоном (Chan
Wilson). Разработка программы приостановлена. Majordomo 2 существует
только в виде бета-версии, поэтому мы опишем исходную версию программы.
Majordomo выполняется с правами непривилегированного пользователя,
обычно от имени пользователя majordom и группы daemon. Если в системе
поддерживаются длинные имена (более 8 символов), можно задать имя
majordomo в качестве регистрационного. Пользователь должен принадлежать
к числу “доверенных" пользователей программы sendmail и быть упомянутым
в ее конфигурации (обычно посредством объявления опции сог,-
f TRUSTED_USERS).
Информацию о "доверенных" пользователях можно получить в параграфе 19.11
Majordomo конфигурируется при помощи файла majordorno.cf. Этот файл
содержит команды на языке Perl, посредством которых инициализируются
Эго свободно распространяемая версия коммерческого пакета LISTSERV
588
Чость II. Роботе в сетях
переменные, задаются каталоги, определяются поддерживаемые списки рас-
сылки и правила доставки сообщений об ошибках. Вспомогательная про-
грамма conf-test позволяет протестировать конфигурационный файл на
предмет отсутствия нужных переменных и синтаксических ошибок
Majordomo требует наличия специальных псевдонимов в файле aliases
программы sendmail. Самый правильный способ их интеграции в систему —
создание отдельного файла псевдонимов для Majordomo (последние версии
программы sendmail поддерживают несколько файлов псевдонимов). Такой
файл содержит псевдонимы для самого пакета Majordomo и набор псевдо-
нимов для каждого управляемого им списка рассылки. Дистрибутив пакета
включает файл majordomo.aliases, который может служить образцом.
Пользователи часто задают вопрос о том, как исключить себя из списка
рассылки (отказаться от подписки). Что касается списков, управляемых
программой Majordomo, то ответ звучит так. Чтобы отказаться от получения
информации из списка имя_списка@имя_узм, следует направить по адресу
majordorno@uw?_yi/a сообщение, в теле (а не в заголовке) которого есть фраза
“unsubscribe имя_списка" или “unsubscribe ила_спыска адрес_м&<троннойпочты"
В первом случае сообщение должно быть отправлено именно с того
компьютера, с которого ранее была осуществлена подписка на рассылку. Во
втором случае имя компьютера, для которого следует отказаться от подписки,
является частью почтового адреса. Просмотрите еще раз параграф 19.2, где
рассказывается, как извлечь необходимую информацию из заголовков сооб-
щения, чтобы отказаться от подписки даже в том случае, когда вы забыли,
с какого компьютера когда-то подписались на рассылку. Для некоторых
списков рассылки достаточно послать сообщение с текстом “unsubscribe” по
адресу имя_ сп иска- req uesc@wiя_узм.
Никогда не посылайте сообщение об отказе от подписки непосредственно
в список рассылки, поскольку оно будет разослано всем его подписчикам и
все поймут. что вы не понимаете, что делаете.
Mailman
Mailman — это довольно молодой член семейства программ, предназна-
ченных для работы со списками рассылки (версия 1.0 программы появилась
в июле 1999 года). Программу можно найти на Web-узле www.lrst.org или в
GNU-архивах. Ее автором является Джон Виега (John Viega). Сейчас в ее
разработке принимают участие Кен Манхаймер (Ken Manheimer) и Барри
Уорсо (Barry Warsaw). Как и Majordomo, программа Mailman написана иа
языке сценариев, но в данном случае это Python (www.python org).
Толчком к созданию Mailman послужили недостатки программы Major-
domo: плохое управление "рикошетами”, сложный способ конфигурирования
дополнительных возможностей (в частности, информационных подборок и
списков с централизованным управлением), а также низкая производитель-
ность при работе с большими списками. В дистрибутив Mailman входит
сценарий, который позволяет импортировать списки Majordomo. Программа
Mailman обладает также средствами обнаружения спама и борьбы с ним.
Большим преимуществом программы является ее Web-интерфейс. Его
наличие упрошает координатору списка (модератору) пли почтмейстеру
процесс управления списком, а пользователям — подписку, отказ от рассылки
и настройку списка
Глово 19 Электронная почто
589
ListProc
ListProc — это одна из старейших программ данною класса. Она была
написана в 1991 г. Анастасиосом Котсиконасом (Anastasios Kotsikonas) и
поддерживалась приблизительно до 1994 года. Затем, после нескольких лет
забвения, в 1998 г. появилась новая бета-версия программы. Ее можно было
бесплатно получить на факультете вычислительной техники в университете
Бостона, но на несколько странных условиях лицензирования. Сейчас
программа LisfProc доступна на Web-узле www.cren.net. но условия ее
получения неприемлемы (2000$ за копию, даже для университетов). Так что
забудьте о ListProc и пользуйтесь свободно распространяемыми программами
с открытым кодом.
SmartList
Программу SmartList написал Стефан ван леи Берг (Stephen van den Berg),
который является также автором пакета procmail. Дистрибутив SmartList
можно найти на Web-узле www.procmail.org. Поскольку данная программа
использует пакет procmail, потребуется загрузить файлы procmail.tar.gz и
SmartList. tar.gz.
SmanLtst — простая и маленькая по объему программа. По сути она
представляет собой комбинацию кода на языке С. правил пакета procniail и
сценариев интерпретатора команд. С “рикошетами”. главной неприятностью
списков рассылки, программа борется автоматически Пользователь автома-
тически удаляется из списка после того, как направленная в его адрес почта
возвращается определенное число раз. Программа SmartList требует наличия
в файле passwd записи (smart или. может быть, list), соответствующей
“доверенному” пользователю в конфигурационном файле программы sendmail.
Дистрибутив SmartList включает утилиту led. которая защищает программу
от использования с несогласованным или частично отредактированным
файлом конфигурации.
LISTSERV Lite
LISTSERV Lite — это усеченная версия пакета LISTSERV, коммерческого
продукта компании L-Soft International, Inc. Ее автором является Эрик Томас
(Eric Thomas). Некоторые возможности LISTSERV здесь отсутствуют, поэтому
программа способна управлять всего 10 списками рассылки по 500 членов
каждый. Программа работает с правами псевдопользователя iistscrv, который
должен быть владельцем ее файла. Желательно также создать группу listsen
Программа снабжена Web-интерфейсом как для подписки на рассылку, так
и для управления самой программой.
Дистрибутив LISTSERV Lite можно загрузить с Web-узла www.lsofi.com.
Исходный код программы не распространяется, однако доступны предвари-
тельно скомпилированные двоичные файлы для многих версий UNIX и Linux.
Тем, кто уже работал с пакетом и располагает созданными им списками
рассылки, может быть, имеет смысл использовать усеченную его версию.
Всем остальным рекомендуем остановить свой выбор на одной из описанных
ранее программ с открытым кодом.
LDAP
LDAP (Lightweight Directory’ Access Protocol — упрошенный протокол
доступа к каталогам) — это протокол, который обеспечивает доступ к
590
Чость II Роботе в сетях
унифицированном службе каталогов. Он существует уже несколько лет, но
лишь недавно начал приобретать популярность.
Администраторы обнаружили. что протокол LDAP очень удобен дня
выполнения самых разнообразных задач, а именно;
•	конфигурирования программы sendmail (псевдонимы, виртуальные доме-
ны и почтовые каталоги):
•	управления пользователями (регистрационные имена, пароли и т.д.);
•	ведения административных конфигурационных файлов (например, в SuSL
Linux);
•	в качестве замены \IS;
•	в качестве календарного сервера;
•	для использования с подключаемыми модулями аутентификации (Plug-
gable Authentication Modules, РАМ).
Таким образом. LDAP в скором времени станет глобальным инструмен-
том для работы с каталогами, который будет применяться во многих областях
В основе LDAP лежат протоколы ISO и почтовая система zX.500. А такое
наследство предполагает сложность, громоздкость, массу недостатков и т.д.
Однако наличие в названии протокола буквы “L” указывает на отсутствие
таковых. Версии I и 2 протокола уже прошли процесс стандартизации. Работа
над версией 3 также завершена. К счастью, все версии обладают обратной
совместимостью. Версии I и 2 не являются иерархическими, в отличие от
версии 3.
Протокол I DAP очень удобен для работы с почтовыми псевдонимами,
особенно сейчас, когда программа sendmail обеспечивает внутреннюю под-
держку протокола. Программа sendmail может посылать серверу LDAP запрос
на поиск псевдонимов, вместо того чтобы осуществлять поиск непосредст-
венно. Протокол способен управлять маршрутизацией почты и виртуальными
доменами. Средства поддержки LDAP должны быть встроены в двоичный
код программы sendmail на этапе компиляции.
Тем. кто не знает, где взять программную реализацию LDAP, рекомендуем
обратиться на сервер www.openldap.org организации OpenLDAP. Она получила
в свое распоряжение, а затем улучшила код предыдущего сервера LDAP,
разработанного в Мичиганском университете. (Дополшггельная информация
о программном обеспечении I.DAP приведена в конце главы 18.)
Записи базы данных LDAP напоминают элементы базы Lermcap, но с
более длинными именами. Атрибуты (имена переменных) в базе данных
LDAP еще не полностью стандартизованы, что может привести к несовмес-
тимости реализаций LDAP.
Атрибуты, находящиеся в первой строке записи, определяются в файле
конфигурации LDAP. В приводимых ниже примерах мы предполагаем, что
серверный демон LDAP (slapd в случае пакета OpenLDAP) сконфигурирован
с корневым именем (запись го о ton) следующего вида
"cn-iroot,dc“synacz dc=net"
Атрибут de указан дважды, поскольку доменный компонент имени не
может включать точку, следовательно, для представления домена synac.nei
требуются два элемента. Последующие атрибуты (имена переменных) могут
быть произвольны ми. Регистр символов в данном случае не важен. Программа
sendmail (которая ищет предопределенные имена атрибутов и назначает им
заранее заданные значения), сервер LDAP и утилита создания базы данных
Глово 19. Электронной почто
591
LDAP должны взаимодействовать друг и другом и использовать одинаковые
соглашения об именовании атрибутов.
Среди допустимых атрибутов, которые могут располагаться в первой
строке записи (ключи базы данных), упомянем dn (доменное имя), о
(название организации), с (название страны), uid (уникальный идентифи-
катор, например регистрационное имя).
Программа sendmail распознает следующие дескрипторы данных:
mailLocalAddress
mallRouLingAddress
mailHost
Ниже приведен пример файла Idap.conr демона slapd:
# Файл Idap.conf должен быть доступен для записи всем пользователям.
I
BASE dc-»synack, сс-Пес
HOST qw.synack.net
PORT	ЗВ9
Он обеспечивает поддержку базы данных с записями следующего вида:
dn; uic=jon, dc=synack, dc-г.ет
objectClass: inetLocalMailRecipient
inaillocalAddress: 30n@synack.net
uiailRoutingAddress: stabilej@cs.colorado.edu
uid: 30П
Адрес получателя входящего сообщения сравнивается с полем mailLo-
calAddress. Если они совпадают, письмо перенаправляется по адресу,
указанному в поле mailRoutingAddress. Наличие строки objectClass
необходимо: таковы требования документа RFC. который определяет взаи-
модействие протокола LDAP и почтовой системы. На узле gw.synack.net этому
элементу базы данных соответствует псевдоним
3©п: scabilejfics.Colorado.edu
Все это несколько длинновато, не правда ли? Такие записи базы данных
могли бы заменить обычные элементы файла aliases, которые применяются
для определения почтовых каталогов пользователей. Однако файл aliases все
еше остается лучшим методом объявления списков рассылки (при помощи
директивы :include:). Программы управления списками рассылки обычно
передают (через канал) сообщение сценарию-упаковщику и повторно посы-
лают сообщение. А LDAP-запрос может вернуть локальный адрес, по
которому ведется обработка списка рассылки (посредством файла aliases), но
не может непосредственно вызвать программу.
Дополнительная информация о включении в программе sendmail под-
держки протокола LDAP содержится в параграфе 19.8. В параграфе 19 9
приведен пример использования протокола LDAP для реализации псевдони-
мов и виртуального хостинга.
19.5. Почтмейстер sendmail
Программа sendmail — самая сложная и самая полная из широко
используемых систем транспортировки электронной почты. Ее иаггисал Эрик
Оллман (Eric Allman), будучи студентом Калифорнийского университета в
592
Чость II. Роботе в сетях
Беркли. Он как раз заканчивал курс по вычислительной технике, в процессе
изучения которого работал с системами промышленного уровня. Эрик решил
аналогичным образом подойти к проблеме доставки почты. В то время такой
подход казался ему погоней за мухой с кувалдой, и он собирался со временем,
разобравшись как следует в проблеме, использовать более простые методы.
Однако оказалось, что универсальность программы sendmail позволила
Эрику идти в ногу с быстро изменяющимся миром стандартов электронной
почты. Некоторые важнейшие стандарты находились в стадии доработки и
изменялись чуть ли не каждую неделю. Эрик понял, что муха, за которой
он гонялся, на самом деле — слон и силы его кувалды едва хватает.
Программа sendmail может адаптироваться к причудам создателей стан-
дартов благодаря гибкости своего файла конфигурации, который позволяет
ей удовлетворять потребностям очень разнородного сообщества пользовате-
лей. Поэтому остальная часть данной главы посвяшена описанию структуры
этого файла, называющегося sendmail.cf.
Программа sendmail —• это транспортный агент, программа-связка между
пользовательскими агентами и агентами доставки. Она работает по протоколу
SMTP и доставляет сообщения на удаленные компьютеры через Internet.
Программа sendmail выполняет следующие задачи:
•	управляет сообщениями после того, как они были сгенерированы
пользователями;
•	анализирует адреса получателей;
•	выбирает соответствующий агент доставки или транспортный агент;
•	преобразует адреса в форму, понятную агенту доставки;
•	осуществляет необходимое переформатирование заголовков;
•	передает преобразованное сообщение агенту доставки.
Программа sendmail также генерирует сообщения об ошибках и возвра-
щает сообщения отправителю, если их оказалось невозможно доставить.
История программы sendmail
Программа sendmail версии 5 написана Эриком Оллманом в 1983 году.
Один из ее вариантов был доработан Леннартом Левстрандом (Lennart
Luvstrand) из Линчепингского университета (Швеция) в 1987 г. и назван IDA
sendmail*. Сопровождением этой версии занимались Нил Рикерт (Neil Rickert)
и Пол Поумз (Paul Pomes). Другой вариант. King James Sendmail (KJS),
разработан Полом Викси (Paul Vixie) из компании DEC на протяжении
1989—1993 гт. Он основан на версии IDA sendmail, но акцент сделан на
повышении производительности и пропускной способности коммерческих
узлов. В IDA и KJS впервые были реализованы некоторые возможности,
которые теперь включены в sendmail версии 8 (написана Эриком Оллманом
в 1993 году).
На момент написания этой книги большинство реализаций программы
sendmail, предлагаемых производителями операционных систем, основаны на
версии 8. Однако обычно они на один-два выпуска отстают от версии,
выпускаемой компанией Sendmail... Inc. Производители чаще всего просто
настраивают под свою систему определенную версию sendmail. а затем
отказываются модифицировать ее с учетом текущих версий программы.
 Лениарт в то время был студентом факультета вычислительной техники, который на
шведском языке называется Institutionen fsr Datavetenskap, отсюда и сокращение IDA.
Слова 19. Электронной почта
593
Перечень систем, а также информация о том, какие версии sendmad в них
включены, приведены в табл 19.5.
Мы опишем программу sendmail версии 8.11 и совсем не будем касаться
версий 5 и IDA, поскольку они устарели. В версии 8 используется
макропроцессор m4t облегчающий создание файла конфигурации для стан-
дартных ситуаций (в большинстве организаций больше ничего и не требуется).
К сожалению, при возникновении проблем с конфигурацией sendmail
придется заниматься отладкой исходного файла конфигурации. Нам доводи-
лось слышать о нем такие нелестные отзывы, как “непостижимый",
“устрашающий”, “крайне тяжелый”, “загадочный", “оставляющий тягостное
впечатление'’, “мерзкий”, “утомляющий’', "издевательский”, “запутанный",
“громоздкий", "нелепый”, “сбивающий с толку”, “закрученный’' и еще много
чего. В предыдущем издании книги описание этого файла занимало более
20 страниц. В этом издании из сострадания мы предлагаем читателям
обратиться к руководству "Sendrnail Installation and Operations Guide"
авторства Эрика Оллмана и Брайана Косталеса (Bryan Costales), поставляе-
мому вместе с программой.
Версии программы sendmail, поставляемые
производителями систем
В табл. 19.5 перечислены версии sendmail. поставляемые с нашими
тестовыми операционными системами. В таблице также указано, где нахо-
дится исполняемый файл и файл конфигурации sendmail.сГ Для сравнения в
перечень включена также стандартная реализация, находящаяся на Web-узле
www .se ndmai 1. о tg.
Таблице 19.5. Версии прогроммы sendmail, поставляемые производителями
систем (но 2000 год)
Система	Версия кода	Версия конфигурации	Каталог для двоичного кода	Каталог для конфигурации
sendmail.org	8.11.0	8.11.0	—	/etc/mail
Solaris 7	8.9.3'	8.9 1	/usr/lib	/etc/mail
HP-UX 11.00	8.8.6	8.8.6	/usr/sbin	/etc/mail
Red Hai Linux 6.2	8.9.3	8.9.3	/usr/sbin	/etc
FreeBSD 4.0	8.9.3	8.9.3	/usr/sbin	/etc
Адаптирована компанией Sun.
Появление новых выпусков программы sendmail зачастую вызвано про-
блемами с безопасностью. Поэтому мы рекомендуем посетить ссылку “Release
Notes” на сервере www.sendmail.org и загрузить соответствующие “заплаты".
Для их подключения потребуются компилятор языка С и препроцессор го4
(они обычно входят в стандартную поставку UNIX).
Компилятор gee можно найти на Web-узле www.gnu.org.
Иногда трудно определить, какой выпуск sendmail установлен в системе.
Попробуйте выполнить команду
# /usr/sbin/sendmail -dO.l -bt < /dev/null
594
Часть II. Робото в сетях
которая заставит программу сообщить свою базовую версию, параметры
компиляции и свои идентификационные имена, найденные после чтения
файла конфигурации. Флаг -d задает уровень отладки (об этом рассказывается
в параграфе 19.12), флаг -bt переводит программу в режим тестирования
адреса, а чтение входного потока из устройства /dcv/null приводит к тому,
что адрес для тестирования будет отсутствовать. Результат работы команды
будет примерно таким:
Version 8.9,3
Compiled with: MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7
NAMEDBIND NDBM NETINET NETUNIX NEWDB NIS NISPLUS QUEUE
SCANF SMTP USERDB XDEBUG
SYSTEM IDENTITY (after reader)
(short	domain	name)	Sw	-	katroo
(canonical	domain	name)	Sj	=	katroo.Sendmail.COM
(subdomain	name)	$m	*-	Sendmail.COM
(node	name)	Sk	—	katroo.Sendniail.COM
Программа sendmail должна использовать записи MX службы DNS,
поэтому ее всегда следует компилировать с установленной опцией
NAMED BIND (как в приведенном примере).
Инсталляция программы sendmail
В этом разделе мы кратко опишем процесс инсталляции программы
sendmail. За всевозможными подробностями, а также за информацией,
касающейся конкретных операционных систем, обращайтесь к примечаниям
по инсталляции, которые включены в дистрибутив sendmail. Если программа
уже инсталлирована в системе и производится лишь ее замена, может
оказаться, что некоторые этапы (например, инсталляцию файлов помоши)
осуществлять не придется.
Для работы программы требуются:
•	двоичный файл sendmail, который обычно инсталлируется в каталог
/usr/sbin или /usr/lib и запускается с правами пользователя root (код прав
доступа — 4755);
•	файл конфигурации /etc/mail/scnd mail.cf. устанавливаемый системным
администратором;
•	каталог очереди /var/spool/mqucue. созданный администратором вручную
(код прав доступа — 700, владелец — root);
•	различные ссылки на sendmail (newaliases, maiiq. hoststar и пр.):
	безопасные локальные агенты доставки (smrsh и mail.local), обычно
устанавливаемые в каталог /iisr/libexec.
Последнюю версию программы можно загрузить с узла www.sendniail.org.
Для компиляции и инсталляции пакета запустите сначала сценарий Build, а
затем — Build install.
Однако до начала компиляции нужно определиться в отношении формата
базы данных, а также стратегии взаимодействия с административными базами
данных, такими как NIS, NIS+, Nell л Го или даже Hesiod. Для баз данных,
хранящихся на диске, мы рекомендуем пакет Berkeley DB. указанный в файле
Makefile как NEWDB. Только не редактируйте файл Makefile, а создайте свой
файл site.config.ni4. посредством которого будет осуществляться настройка и
Глово 19 Электронной почто
595
установка опций программы sendmail. Например, в случае использования
протокола LDAP создайте файл site.conng.m4 со следующими строками:
define(’confHAPDEF', •-DLDAPMAP')
define ('conf LIBS', '-lldap -liber’)
Затем скомпилируйте программу при помоши такой команды:
t ah ./Build -с -f site .config .
Программа sendmail обычно не работает под управлением демона inctd.
поэтому должна явно запускаться из гс-файлов в процессе начальной загрузки
системы. Обычно это делается так-
if [~f /usr/sbin/sendir.ail -а -С /etc/mail/sendmall.cf);
then
(cd /var/spool/requeue; rm -f [tTx]f’}
/usr/sbin/sendmail -bd -q30m ь
echo -n 1 sendmail' > /dev/console
В данном случае прсизводгггся проверка двоичного файла и файла
конфигурации, а затем программа запускается в режиме демона. Если
компьютер не является почтовым сервером, а на нем нужно запустить
sendmail. можно сконфигурировать компьютер в качестве “нулевого клиента"
и не вызывать программу в режиме демона (т.е не указывать ключ -bd).
Таким образом, она не будет принимать запросы на подключение из Internet.
О средстве nullclient рассказывается в параграфе 19.8.
Приведенный фрагмент следует добавить в файл /etc/гс (для BSD-систем)
или /etc/init.d/sendmail (для систем System V). Можно также воспользоваться
более сложным сценарием из руководства по инсталляции, который пытается
удалять файлы из прерванных очередей сообщений.
Этот сненарггй работает с одним каталогом очереди. Если их несколько,
сценарий усложнится (см. раздел "Очередь почтовых сообщений”).
Традиционно файлы, необходимые программе sendmail. располагались в
таких каталогах, как /usr/lib, /etc, /usr/ucblib п /usr/share. Начиная с
версии 8.10 предполагается, что все файлы хранятся в подкаталогах каталога
/etc/mail*. Надеемся, что поставщики систем поймут этот намек к будут
располагать файлы в каком-то одном месте.
Фойл переключения сервисов
Во многих операционных системах имеется специальный конфигураци-
онный файл, называемый файлом переключения сервисов. В нем перечис-
лены методы, которые могут быть использованы для выполнения стандартных
запросов, в частности поиска компьютеров и пользователей. Этот файл также
определяет порядок применения методов поиска в случаях, когда для данного
типа запроса указано более одного метода.
Файл переключения сервисов подробно описан к главе 18.
Это пока еще не совсем так. Файл sendmail.pid и иногда файл статистики хранятся в другом
месте.
596
Честь II. Роб ото е сетях

Обычно программы не заботятся о наличии файла переключения
сервисов. Однако программа sendmail слишком педантична и тщательно
контролирует операции поиска. В Solans, например, она читает файл
переключения сервисов напрямую. В других версиях UNIX у нее есть свой
собственный персональный вариант этого файла
В файле переключения сервисов имеются два поля, которые влияют на
почтовую систему: aliases и hosts. Возможные значения поля hosts
таковы: dns, nis, nisplus и files. Поддержка всех механизмов поиска
(за исключением файлового) должна быть встроена в двоичный файл sendmail
на этапе компиляции.
По умолчанию файл переключения сервисов программы sendmail назы-
вается /etc/mail/service.switch. Он содержит следующие записи:
aliases files nisplus nis # если программа компилируется
Ц с поддержкой служб nis/nis+
hosts dns nisplus nis files
Если в строке hosts присутствует элемент dns, то программа sendmail
будет осуществлять поиск записей MX службы DNS, даже когда элемент nis
указан первым
Режимы работы
Программа sendmail может работать в нескольких режимах, которые
задаются с помощью флага -Ь. Он всегда используется в сочетании с другим
флагом, определяющим роль, которую предстоит играть программе. Допус-
тимые значения флагов перечислены в табл. 19.6.
Таблица 19.6. Флоги командной строки для основных режимов роботы
программы sendmail
Флог	Назначение
-	bd	Рабата в качестве демона, прослушивание порта 25
-	bD	Работа в качестве демона, но в интерактивном, а не фоновом режиме1
-	ЬЬ	Отображение информации о последнем соединении (то же, что про-
грамма boststat)
-	ЬН	Удаление с диска старой информации о соединениях (то же, что
программа purgestat)
-	bi	Инициализация хэшированных псевдонимов (то же, что программа
news liases)
-	bp	Печать содержимого очереди сообщений (то же, что программа tnaDq)
-	bt	Включение режима проверки адресов
-	bv	Только проверка адресов, почта нс отправляется
-	bs	Включение режима SMTP-сервера (чтение данных из стандартного
входного потока, а не из порта 25)
Режим применяется при отладке, поскольку будут отображаться сообщения об
ошибках.
Глово 19, Электронной почто
597
Если входящая почта будет поступать по сети, программу sendmail следует
запускать в режиме демона (-bd). В этом режиме программа прослушивает
сетевой порт 25' и ожидает поступления запросов. Обычно указывается также
флаг -q, который назначает интервал обработки очереди почтовых сообщений.
Например, флаги -q30m и -qlh шгют обработку очереди каждые 30 минут
и 1 час соответственно.
Программа sendmail обычно старается доставить сообщение немедленно,
не записывая его в очередь. Если же компьютер слишком занят или адресат
недоступен, программа ставнт сообщение в очередь, а через некоторое время
вновь пытается отправить его. Каждый раз, когда программа обрабатывает
очередь, оиа порождает дочерний процесс, поэтому интервалы обработки не
следует устанавливать слишком маленькими. В документе RFC 1123 рекомен-
дуется делать этот интервал равным минимум 30 минутам. Поскольку
программа осуществляет блокировку рабочих файлов, одновременные обра
щения к очереди не вызывают конфликтов.
Программа sendmail читает свой файл конфигурации, sendmail.cf, только
при запуске Поэтому прн измененнн файла конфигурации нужно либо
уничтожать и перезапускать процесс sendniail, либо посылать процессу сигнал
отбоя (HLJP). Программа создаст файл sendmail.pid, содержащий идентифи-
катор процесса sendmail и команду. использованную для его запуска. При
вызове программы нужно указывать абсолютный путь, так как она переза-
пускает себя с помощью функции ехес() в ответ на сигнал отбоя. Наличие
файла sendmail.pid позволяет уничтожать процесс командой
6 klU. -HUP ’head -1 sendmail.pid'
Раньше местоположение PI D-файла задавалось при компиляции, но
сейчас оно может устанавливаться в конфигурационном mc-файле при
помощи опции cor.fPID FILE:
define (confPID_FILE, ‘ /var/run/sendniail.pid’)
В BSD-системах PI D-файл по умолчанию называется /var/run/sendmail.pid.
а в остальных — /etc/sendmail.pid.
Очередь почтовых сообщений
Если коктьютер слишком загружен н не может доставить сообщение
немедленно либо недоступен адресат, сообщение записывается в каталог
очереди. Этот каталог обычно называется /var/spool/mqueue. его владельцем
является пользователь root, а код режима доступа равен 700*’ Все сообщения,
поступающие от пользовательского агента, на короткое время попадают в
очередь.
Программа sendmail способна работать с несколькими очередями
одновременно Если каталог mqueue содержит подкаталоги ql, q2 и q3 и
каталог очереди задается как /var/spool/mqueue/q*, то будут использоваться
Порты, прослушиваемые программой sendmail, задаются с помощью макроса daemon op-
TIONS.
Если получателем почтового сообщения является сценарий интерпретатора csb, то буфер-
ный каталог должен иметь режим доступа 711 либо с помощью флага D- агента доставки
следует задать другой каталог, в котором сможет выполняться этот сценарий (у данного
каталога должен быть установлен как минимум бит поиска).
59Е
Чость II Роботе в сетях
все три очереди. Это улучшает производительность при высокой загрузке
почтовой системы*.
Когда сообщение ставится в очередь, оно записывается по частям в
разные файлы. Имя каждого из этих файлов содержит двухбуквенный
префикс, обозначающий часть сообщения, и случайный идентификатор,
который образуется из идентификатора процесса sendmail. Данный иденти-
фикатор не является константой, потому что программа sendmail постоянно
порождает новые процессы. Части, на которые может быть разделено
сообщение, перечислены в табл. 19.7.
Тоблицо 19.7. Префиксы фойлов сообщений в очереди
Префикс Содержимое файле,
qf	Заголовок сообщения и управляющий файл
if	Тело сообщения
tf	Временная версия файла qf на случай, когда производится его обновление
Tf	Означает, что было сделано 32 и более без) спешных попыток блокировки
Qf	Означает, что сообщение отброшено и не может быть возвращено
ХГ	Временный файл сообщений об ошибках, поступающих от агентов
доставки
Если в каталоге очереди имеются подкаталоги qf, df пли хГ, то к них
будут размешаться соответствующие части сообщения. Файт qf содержит не
только заголовок сообщения, но и сведения о получателях, отправителе, лате,
когда оно должно быть возвращено из-за невозможности доставки, приори-
тете сообщения в очереди и причине, по которой оно там находится. Каждая
строка начинается однобуквенным кодом, который идентифицирует осталь-
ную часть строки.
Для каждого сообщения, которое ставится в очередь, должны существо-
вать файлы qf и df. Все остальные файлы используются программой sendmail
при попытках доставить сообщение При перезагрузке компьютера после
краха необходимо удалять файлы if. хГ и ТГ из каждого каталога очереди.
Системный администратор, отвечающий за работу почтовой системы, должен
периодически проверять файлы Qf на предмет того, не стали ли причиной
возврата сообщения ошибки локальной коифшу рации.
Очередь сообщений может стать причиной конфликтов в нескольких
ситуациях Во-первых, может переполниться файловая система (поэтому по
возможности не помешайте каталоги /var/spool/mqueue и /var/spool/news в
один раздет). Во-вторых, может переполниться сама очередь. Наконец, в
очереди могут появиться '‘осиротевшие" сообщения.
Программа sendmail имеет опцию управления дисковым пространством
(confMIK_FREE_BLOCKS). Если файловая система, которая содержит очередь
сообщений, переполняется, то почта не принимается, и до тех пор, пока не
освободится место на диске, будет выдаваться сообщение "ну again later”
(попробуйте позднее) Причем прием почты останавливается раньше, чем
диск переполнится и система зависнет.
Каталоги UNIX являются эффективным хранилищем данных только тогда, когда не
содержат много файлов. Если же почтовый сервер слишком загружен и работает с большим
числом списков рассылки, каталог очереди может так переполниться, что скорость поиска
в нем станет неприемлемой.
Глоео 19. Электронной почто
599
Если выйдет из строя основной концентратор почты, то резервные
MX-узлы окажутся перегружены тысячами сообщений’ В этой ситуации
програлгма sendmail может породить стишком много экземпляров самой себя
и тем самым ’’монополизировать” систему. Если очередь переполнилась,
нужно переместить ее во временный каталог, продолжить обработку новой
почты в обычном режиме, а когда все стабилизируется — запустить отдельный
экземпляр sendmail для обработки переполненной очереди.
Подробнее о DNS-записях MX рассказывается в параграфе 16.11.
Вот пример для одного каталога очереди:
#	kill 'head -1 sendmail.pid'
#	nrv queue cloggedqueuo /’ fi другую файловую систему,
если необходимо */
I rnkdir mqueue	/* Задаем владельца и права доступа */
О chown root xnqueue
i chino в 700 enqueue
R /usr/sbin/sendmail -bd -glh £
Когда все нормализуется, запустите программу sendmail с такими флагами:
#	/иsr/lib/sendmail -oQ/var/spool/cloggedquey® -q
Эти флаги указывают программе, где находится каталог переполнившейся
очереди, и дают ей команду немедленно обработать данную очередь.
Повторяйте эту команду до тех пор, пока очередь не очистится.
Если размеры очередей огромны, сортируйте сообщения по разным
очередям на основании последней цифры идентификатора сообщения, как
показано в следующем сценарии:
#!/Ып/csh -£
foreach suffix (0 1 2 3 4 5 6 7 £ 9)
mkdLr dog$ [ suff lx f
rcv ?£"$(suffxx} clogStsuffLxj
sendmail -cQclcgS(suffix}
end
Цель разбиения очереди — уменьшить время поиска в каталоге. Десять
маленьких очередей обрабатываются быстрее одной большой, поскольку
скорость работы программы sendmail больше зависит от производительности
подсистемы ввода/вывода. чем от мощности процессора.
Момент переполнения очереди зависит от размеров организации и
аппаратных средств, на которых работает программа sendmail. Естественно, у
обычной рабочей станции и у концентратора почты на узле aol.com
обрабатывающего миллионы сообщений в день, будут разные критерии, по
которым определяется, переполнена очередь или нет Информация о методике
измерения трафика приведена в параграфе 19.12.
Несколько лет назад компания Sun Microsystems решила изменить свою стратегию маршру-
тизации почты и перейти от непосредственной адресации к системе шлюзов в подразделе-
ниях. Очереди иа этих шлюзах стали такими длинными, что почта к сотруднику, сидящему
в другом конце зала, шла дольше дня. Дзя решения этих проблем пришлось в очень сжатые
сроки пара шивать аппаратные мощности всех шлюзовых машин.
600
Чость II. Робото в сетях
19 6. Конфигурирование программы sendmail
Действиями программы sendmail управляет единственный файл конфигу-
рации sendmaJI.cE который располагается в каталоге /etc/mail (ранее — /etc
или /вБг/lib). В этом файле определяется следующее:
•	выбор агентов доставки.
•	правила подстановки адресов,
•	форматы заголовков почты,
•	опции,
•	меры безопасности.
•	средства зашиты от спама.
Формат первичного файла конфигурации проектировался таким образом,
чтобы файл легко поддавался синтаксическому анализу. По этой причине
файл малопонятен пользователям, и его сопровождение — самая серьезная
административная задача в области электронной почты.
Файл конфигурации необходим программе sendmail всех версий. Однако
в современных версиях процесс создания файла несколько упрошен, так как
для этого используется препроцессор т4. Если провести аналогию в языками
программирования, то можно сказать, что первичный файл конфигурации —
это уровень языка ассемблера, а конфигурирование средствами т4 — это
уровень языка Peri*.
Когда макросы т4 были впервые представлены, показалось, что ими
можно будет пользоваться в 80—90% случаев. В действительности этот
процент оказался еще выше: порядка 98%. Поэтому мы рассмотрим только
конфигурирование средствами т4. Вникать в структуру реального файла
конфигурации придется лишь в том случае, если потребуется устранить
какую-то серьезную проблему или расширить почтовую систему каким-нибудь
необычным способом.
Существует три основных источника, из которых можно почерпнуть
подробные сведения о программе sendmail. Это книга "Sendmail** издательства
O’Reilly, написанная Брайаном Косталесом и Эриком Оллманом, работа
Эрика Оллмана “Sendmail Installation and Operations Guide” (находящаяся в
каталоге doc/op дистрибутива) и файл README (в каталоге сП-
Конфигурирование с помощью препроцессора т4
Сначала мы кратко опишем препроцессор ш4, а затем покажем, как
построить конфигурационный файл из файла ш4. После этого будут описаны
некоторые макросы in4, которые поставляются с дистрибутивом sendmail
Изложение темы завершится примерами конфигурационных фапчов для
следующих случаев:
•	домашней Linux-системы студента, который предоставляет услуги хостин-
га для своих друзей:
•	узла небольшой компании, н которой внают, как правильно конфигури-
ровать программу sendmail;
•	организации, занимающейся Web-хостингом.
• Язык конфигурирования прО(раммы sendmail является ’‘функционально полным по Тью-
рингу”, Это означает, что он может быть использован для написания любой возможной
компьютерной программы. Тс. кто сталкивался с первичным файлом конфигурации, имеют
представление о том, насколько мошным является его язык.
Глово 19 Электронной почто
601
Препроцессор m4 задумывался как внешний интерфейс для языков
программирования, который позволил бы разработчикам писать более
понятные программы. Препроцессор т4 — достаточное мощное средство
решения многих задач, связанных с преобразованием входной информации.
Он очень хорошо работает с файлами конфигурации sendmail.
Макросы щ4 имеют следующий вид:
имя1ар!-1, арг2, арг-п)
Между именем и открывающей скобкой не должно быть пробела. Для
заключения аргументов-строк в кавычки используются левая и правая
одиночные кавычки. Отметим, что в т4 правила употребления кавычек
отличаются от правил, принятых в других языках, так как для левой и праной
кавычек используются разные символы’. Допускается вложенное употребле-
ние кавычек. Удивительно, как препроцессор ш4 с таким экзотическим
синтаксисом смог выжить в борьбе с современными компиляторами.
В ш4 есть несколько встроенных макросов. Кроме того, пользователи
могут определять свои собственные макросы. Встроенные макросы, которые
наиболее часто встречаются в файлах конфигурации sendmail, перечислены в
табл. 19.8.
Тоблица 19.8. Мокросы гп4, чосто применяемые для конфигурирования
программы sendmoil
, Мокрос Назначение_____________________________________ ______
define Определяет макроконстанту с именем арг! и значением арг2
unde fine Отменяет предыдущее определение макроконстангы С именем арг!
include Включает файл с именем арг!
dnl	Отменяет интерпретацию всех символов до следующего символа новой
строки включительно
divert Управляет выходными потоками
Некоторые администраторы добавляют макрос dnl в конец каждой
строки, чтобы транслированный cf-файл выглядел аккуратнее. Без этого
макроса препроцессор т4 добавляет в файл пустые строки Они не влияют
на работу программы sendmail но делают файл конфигурации трудным для
чтения. Мы не включили макросы dnl в наши примеры.
Для программы sendmail требуется препроцессор т4 более новой версии,
чем исходная версия 7 компании Bell Labs, входящая в состав UNIX.
Большинство версий, поставляемых сейчас, подходит. При возникновении
сомнений используйте GNU-версию.
Препроцессор ш4 не очень любит комментарии в файлах. Комментарий
# And then define the......
не выполнит возложенную на него функцию, так как define является
ключевым словом препроцессора. В данном случае следует использовать
макрос dnl:
dnl t And then define the....,
Символы кавычек можно заменить с помощью макроса changequcte, но лучше этого не
делать, так как вы лишь усложните задачу для человека, который впоследствии будет
сопровождать файл.
602
Чость II. Роботе в сетях
При этом не забудьте вставить пробел между именем макроса и
комментарием.
Файлы, необходимые для конфигурирования
программы sendrrail
В дистрибутиве sendmail имеется подкаталог cf, в котором содержится все
необходимое для конфигурирования средствами т4, в частности файл
README и несколько подкаталогов, перечисленных в табл. 19.9-
Тоблицо 19.9. Каталоги, содержощие файлы для настройки программы sendmail
Коталог Содержимое	__________ _________________
сГ	Примеры mc-файлов (главные конфигурационные файлы)
domain Примеры т4-файлов для различных доменов в университете Беркли
feature Фра тенты файлов, иллюстрирующие реализацию различных средств
hack	Специальные средства
т4	Базовый файл конфигурации и другие основные файлы
ostype	Файлы для конкретных операционных систем
mailer файлы т4, задающие конфигурацию наиболее распространенных агентов
доставки
sh Сценарии интерпретатора команд, используемые препроцессором т4
Каталог cf/cf содержит примеры тс-файлов, однако их так много, что
можно легко запутаться. Мы рекомендуем переместить содержимое каталога
cf в каталог cf.examples и создать новый каталог cf для своих локальных
mc-файлов. После этого скопируйте в новый каталог сценарии Makefile и
Build. Лучше также скопировать все конфигурационные me-файлы в одно
место и не оставлять их в структуре каталогов дистрибутива sendmail. Пути,
указанные в сценарии Build, потребуется изменить, если cf-файл будет
создаваться на основании me-файла, не находящегося в иерархии каталогов
дистрибутива.
Создание файла конфигурации из готового тс-файла
Прежде чем перейти к описанию всевозможных макросов, средств и
опций, давайте научимся создавать простейшую конфигурацию без всяких
излишеств. Это будет файл конфигурации для одиночного узла foo.com.
Назовем наш файл Гоо.тс.
Этот файл мы поместим в новый каталог cf. Преобразованный (средст-
вами препроцессора т4} файл конфигурации будет называться foo.cf,
находиться в этом же каталоге и инсталлироваться в каталог /etc/mail под
именем sendmail.cf.
Существует ряд шаблонов, которые должны присутствовать в каждом
новом тс-файле:
divert(-1}
ИН базовый mc-file лля узла foo.com
divert 10)
VERSIONID(’Sld$’)
Глово 19. Электронной почто
603
Если в начале файла есть комментарии, то первая строка должна иметь
такой вид:
divert(-1)
Данная инструкция будет отсеивать всю ненужную информацию в
выходном потоке т4. После нее могут располагаться комментарии (начина-
ются символом дополняемые другой инструкцией divert. Стандартная
часть файла завершается макросом VERSISNID (здесь используется формат
RCS). Эта директива подробно рассматривается в следующем параграфе.
В большинстве случаев файл конфигурации заканчивается заданием
системно-зависимых параметров (макрос OSTYPE) и агентов доставки (макрос
MAILER):
OSTYPE( linux’)
define('confCOPY_ERRORS_TO', * postmaster')
MAILER('local’)
MAILER('smtp'i
Кроме того, здесь устанавливается опция conf СОР Y_ERRORS_TO. опре-
деляющая, что копии заголовков всех сообщений, которые отправить не
удается, будут посланы локальному администратору электронной почты. Это
позволит ему вмешиваться в процесс функционирования почты при возник-
новении проблем локального масштаба.
Для построения файла конфигурации необходимо вызвать сценарий Build,
который мы скопировали в новый каталог cf:
» ./Build fdo.cf
Наконец, следует инсталлировать файл foo.cf в нужное место. Обычно
он превращается в файл /etc/mail/sendmail.cf. однако некоторые поставщики
систем придерживаются других правил. Л юбимые их тайники — каталоги /etc
и /usr/lib.
В крут ной организации можно в каталоге cf/domain создать отдельный
ш4-файл, содержащий стандартные общесистемные установки. Пользователи
затем будут подключать содержимое этого файла к своим конфигурационным
файлам. Не каждый компьютер нуждается в отдельном файле конфигурации,
однако каждая группа похожих систем (имеющих одинаковую архитектуру и
роль: сервер, клиент и т.п.), вероятно, должна иметь свой конфигурационный
файл.
Даже сейчас, когда процесс конфигурирования программы sendmail
значительно упростился, некоторые решения о том, какой должна быть
конфигурация почтовой системы, придется принимать самостоятельно. Читая
материал о возможностях этой программы, подумайте о том. как эти
возможности ’‘впишутся" в структуру вашей организации. В небольшой
организации, скорее всего, будет только узел-концентратор и несколько
одиночных узлов, поэтому понадобятся всего две верснн файла конфигурации.
В более крупной организации, очевидно, потребуются отдельные концентра-
торы для входящей и исходящей почты и, может быть, сервер POP/IMAP.
Независимо от сложности структуры почтовой системы и от того, в каком
виде (открытом-, за брандмауэром или в виде виртуальной частной сети) она
представлена внешнему миру, в каталоге ef всегда найдутся готовые
фрагменты файла конфигурации, в которые требуется внести лишь незначи-
тельные изменения, и они будут готовы к использованию.
604
Чость II Роботе в сетях
19 7. Базовые примитивы конфигурации
программы sendmail
Конфигурационные команды sendmail чувствительны к регистру символов.
В соответствии с Принятыми соглашениями имена стандартных макросов
пишутся прописными буквами (например, ostype), а команды препроцессора
ш4 — строчными (например, define). Имена конфигурационных перемен-
ных начинаются с префикса conf, за которым следует описательная часть
имени, набранная прописными буквами (например, confCOPY_ERRORS_TO).
Макросы обычно (за исключением VERSIONID) ссылаются на файлы
,./имя_Л1акроса/арг1.т4. К примеру, макрос OSTYPE( linux*) вызывает
подключение файла ,./ostype/linux.m4.
В этом параграфе мы рассмотрим только основные конфигурационные
команды. Дополнительные средства будут описаны далее.
Макрос VERSIONID
Файлы конфигурации необходимо вести с применением системы кон-
троля версий CVS, RCS или SCCS. Это нужно не только для того, чтобы
иметь возможность вернуться к одной из предыдущих версий, но и для того,
чтобы можно было определить версии ш4-файлов, задействованных в
формировании файла конфигурации. Для автоматического встраивания ин-
формации о версии используется макрос VERSIONID. В системе CVS/RCS
этот макрос вызывается следующим образом:
VERSIONID (‘SldS’)
а в SCCS вызов макроса будет таким:
VERSIONID(‘(идентификатор) %G%')
Реальная информация о версии вносится системой CVS/RCS или SCCS,
когда пользователь компилирует файл. В итоговом файле sendmail.cf опа
появляется в виде комментария. Эта информация может оказаться полезной
в ситуации, когда пользователь забыл, куда он поместил дистрибутив sendmail
(во многих случаях местоположение файлов определяется не логикой
построения файловой системы, а свободным дисковым пространством).
В SCCS выражение %W% раскрывается в имя и версию файла, a %G% —
в дату последней модификации. Аргумент идентификатор следует заменить
строкой, которая идентифицирует организацию.
Макрос OSTYPE
Файлы в каталоге ostype носят имена, соответствующие операционным
системам. Эти файлы содержат установки по умолчанию для соответствующей
операционной системы. В частности, в них хранится информация о
местоположении относящихся к почтовой службе файлов, путевых именах
команд, необходимых программе sendmail, флагах агентов доставки и т.п.
По соглашению эта информация встраивается в конфигурационный файл
с помощью макроса OSTYpe*, Вызов макроса располагается в начале файла
обычно после макроса VERSIONID.
• А где же определен сам макрос ostype? В файле, находящемся в каталоге cf/ni4. Этот файл
волшебным образом присоединяется к конфшурациопному файлу при вызове сценария
Build.
Глово 19. Электронной почта
605
Файлы в каталоге ostype в основном содержат определения других
переменных т4. Например, команда
define('ALIAS_FILE', '/usrZlib/aliases’)
задает местоположение общесистемного файла aliases. Стандартные установки
можно переопределить в mc-файле. Только не изменяйте находящийся в
каталоге ostype файл, за исключением случаев, когда он действительно
неправильный (при этом нужно послать отчет о найденной ошибке).
В некоторых организациях стремятся унифицировать местоположение файла
aliases для разных платформ и потому переопределяют его местоположение
в файле каталога domain.
В файле README, находящемся в каталоге сГ. перечислены все
переменные, которые могут быть определены в файлах каталога ostype.
Наиболее важные из них приведены в табл. 19.10. В таблицу также включены
переменные, связанные с борьбой против спама (по умолчанию они не
заданы).
Таблица 19 10. Стандартные значения переменных, устоновпиваемых
в файлах каталога ostype
Переменная	Значение no умолчанию
ALIAS_FILE	/etc/mail/aliases
HELP_FILE	/eic/mail/hclpfile
STATUS_FILE	/etc/ma П/statistics
QUEUE_DIR	/var/spool/ni queue
local_mailer_path	/bin/mail
LOCAL_SHELL_PATH	/bin/sb
local_mailer_max	не определена
LOCAL MAILER_MAXMSGS	не определена
SET Р ИАILEK MAX	не определена
SMTP MAILER MAXMSGS	не определена
Программа sendmail допускает использование нескольких файлов aliases
и NIS-карт. Это позволяет искать псевдонимы одновременно в обычных
файлах, и в службе NIS, а также упрощает распределение псевдонимов между
локальными и глобальными файлами. Например, команда
define(’ALIAS_FILE*, ' ‘/etc/aliases,nis:mail.aliases’1)
задает следующий порядок поиска: сначала в файле /etc/aliases. а затем, если
поиск завершился неудачен, в NJS-карте, называемой meil.aliases.
Подробнее о службе MS рассказывается в главе 18.
Если программа sendmail инсталлируется в новой версии ОС или в новой
среде, создайте соответствующий файл в каталоге ostype и отправьте его на
узел sendmail.org, чтобы файл был включен в последующие версии программы
Моделируйте новый файл на основе существующих и сверяйтесь с таблицей
стандартных значений из файла cf/README. Если значение переменной в
новой системе такое же, как значение по умолчанию, нет необходимости
606
Чость II. Робото в сетях
повторно определять эту переменную (можно, правда, обезопасить себя на
случай изменения стандартных установок).
Файлы каталога ostype для наших тестовых систем перечислены в
табл. 19.11.
Таблица 19.11. Файлы из котолаго ostype для распространенных		
	операционных систем	
Система	соайл	Строка вызова
Solaris	solans2.ni4	OSTYPEf’solaris2’J
HP-UX	hpuxl l.m4	OSTYPE('hpuxl!'J
Red Hat	linux.ni4	OSTYPE(‘linux’)
FreeBSD	b»d4.4.m4	OSTYPE( bsd4.4’)
Макрос DOMAIN
Макрос DOMAIN позволяет хранить общесистемную информацию в одном
месте (cf/doinain/^w;_^atuc.rn4) и ссылаться на нее в файлах конфигурации
каждого компьютера следующим образом:
DOMAIN (' имя файла ')
Имя файла обычно выбирается так, чтобы в нем отражалось название
организации. Например, наш файл для факультета вычислительной техники
(Computer Science department) носит имя cs.m4:
DOMAIN(’CS)
Как и макрос OSTYPE, макрос DOMAIN является хорошим средством
подключения внешних файлов. Он делает структуру конфигурационного
файла понятнее и позволяет в будущем легко вносить изменения в
конфигурацию. Макрос особенно полезен, когда все cf-файлы централизовано
создаются из nic-файлов, хранящихся в одном месте.
В небольших организациях необходимости в доменном файле, как
правило, нет. а вот крупные организации часто используют такие файлы для
указания машин-ретрансляторов, установки общесистемных опций зашиты,
а также для определения таблиц агентов доставки, виртуальных доменов н пр
Доменный файл, включенный в дистрибутив, содержит примеры записей,
которые обычно помещают в общесистемные файлы. Он показан в
параграфе 19.9.
Мокрос MAILER
Макрос mailer необходимо включать для каждого агента доставки,
который требуется активизировать. Полный перечень поддерживаемых аген-
тов находится в каталоге сГ/mailers дистрибутива sendmBil В настоящее время
поддерживаются следующие агенты: local, smtp. fax, usenet. procmail.
qpage, cyrus. pop, phquery и uuep. Вот синтаксис этого макроса:
MAILER(‘local ’)
MAILER(‘smep’)
Первая директива активизирует агенты local и prog, а вторая — агенты
smtp, esmtp, dsmtp. smtpB и relay.
Глово 19. Электронная почто
607
Планируя менять значение какой-либо макроконстанты, связанной с
агентами доставки (например, usenet_mailer_args или fax_mai-
LER PATH). убедитесь, что строка, в которой устанавливается макроконстанта.
предшествует строке вызова самого агента. В противном случае будет
использовано старое значение. По этой причине макросы mailer размещают
в конце файла конфигурации.
Агент pop взаимодействует с программой spop, которая является частью
пакета МН и реализует поддержку протокола POP, определенного в документе
RFC 1460. Агент pop применяется персональными компьютерами и Мас-сис-
темами для доступа к почте, находящейся нв UNIX-станции. Агент cyrus
предназначен для использования с сервером IMAP разработки университета
Карнеги - М елло на.
Директива MAILER ('uucp*) активизирует несколько разновидностей
UUCP-агентов.
Агент Usenet формирует интерфейс между электронной почтой и
системой телеконференций Usenet. Для того чтобы он работал правильно,
нужно настроить значения макроконстант USENET_MAILER_* в файле
каталога ostype, соответствующем архитектуре системы. Публикация статьи в
телеконференции осуществляется путем отправки текста статьи по адресу
телеконференция.USENET. Иногда добавляют ар!умент, идентифицирующий
локальную организацию. Например, добавление элемента
-с "Organization: University of Colorado”
к значению макроконстанты USENET_MAILER__ARGS приведет к включению
заголовка “Organization” в каждую публикуемую статью. К сожалению,
Usenet — это рай для спамеров. Еще больше проблем возникнет, если будет
применяться агент usenet. поэтому мы не рекомендуем делать это.
Агент fax интегрирует пакет HylaFAX, написанный Сэмом Леффлером
(Sam Leffler), в систему электронной почты. При отправке почты по адресу
полъзоеателъ@получатель.Тах тело сообщения передается как факс-документ.
В качестве аргумента получатель, как правило, задают номер телефона. Чтобы
разрешить указание символических имен вместо телефонных номеров,
используйте индексированную базу данных или файлы /etc/remote и
/etc/phones.
Пакет HylaFAX можно получить на Web-узле www.hylafax.org.
Программы HylaFAX и sendmail необходимо интегрировать друг с другом
путем инсталляции сценария из дистрибутива HylaFAX в каталог /usr/iocai/bhi.
Если требуется, измените значение макроконстанты FAX_MAILER_PATH. Для
доставки входящих факсов из буферной области в почтовый ящик пользо-
вателя все равно необходимо вмешательство человека. Факс-документы можно
преобразовывать в формат PostScript (с помощью программы HylaFAX) и
просматривать с помощью GNU-пакета ghostscript.
Пакет ghostscript доступен на Web-узле www.gnu.org.
Агент qpage взаимодействует с программой QuickPage для доставки
почты на пейджер. (За более полной информацией об этой программе
обратитесь на Web-узел www.qpage.org.)
Описанные выше макросы VERSION ID. OSTYPE, DOMAIN И MAILER -
это все, что необходимо для создания базового файла имя_компыотера.тс
608
Чость II. Работе в сетях
19.8.	Дополнительные примитивы кпнфигуроции
программы sendmail
В этом параграфе мы продолжим описание макросов и, кроме того,
рассмотрим некоторые средства, используемые для изменения стандартного
поведения программы sendmail. Будет также показано, как на уровне
конфигурационных настроек решать ряд административных задач, в частности
маскировать адреса, создавать виртуальные домены, управлять безопасностью
и бороться со спамом.
Мокрос FEATURE
Макрос FEATURE позволяет активизировать некоторые распространенные
опции (называемые средствами) путем подключения т4-файлов из каталога
feature. Мы поместили вместе описание средств макроса FEATURE и ряда
других макросов программы seedmall, поскольку они тесно связаны друг с
другом. Даже в то время, когда возможность конфигурировать программу
sendmail при помощи препроцессора т4 была нова, описание макроса
FEATURE занимало значительную часть главы об электронной почте. На
сегодняшний день список средств макроса FEATURE так велик, что для их
рассмотрения потребовалась бы целая глава. Синтаксис макроса имеет вид:
FEATURE(ключевое_слово. орг, арг, .. .)
где ключевое_слово указывает на файл ключевое_слово.тА в каталоге cf/feature,
а арг — это аргументы, записываемые в файл. Полный перечень средств
макроса FEATURE можно найти в файле cf/README. Ниже описаны наиболее
часто используемые средства.
Средство usecwfile
Внутренний класс w программы sendmail содержит имена всех компью-
теров, для которых данный узел принимает и доставляет почту. Если речь
идет о клиентском компьютере, то в этот класс можно включить имя
компьютера, его псевдонимы и номер интерфейса localhost. Если же
конфигурируемая машина является концентратором почты, ее класс w должен
также включать имена всех локальных узлов и виртуальных доменов, для
которых он принимает почту.
Средство use_cw_file определяет класс w на основании содержимого
файла /etc/mail/local-host-names (который раньше назывался sendmail.cw;
точное имя файла можно задать с помощью опции confCW_FILEk Без этого
средства программа sendmail принимает только почту, адресованную компью-
теру, на котором она работает. Поскольку программа sendmail читает cw-файл
только в процессе своего запуска, нужно послать ей сигнал HUP, если
cw-файл был изменен и необходимо, чтобы изменения вступили в силу.
Команда
FEATURE('use_CW_file')
активизирует описываемое средство и подключает файл local-host-names.
Команда
FEATURE("use_cw_f ile' . ' имя_ф<айла')
позволяет выбрать другой файл.
Глово 19. Электронная почта
"9
Средство redirect
Если кто-то из сотрудников покинул организацию, его почту нужно либо
пересылать по новому адресу, либо возвращать отправителю с сообщением
об ошибке. Средство переадресации redirect обеспечивает более элегант-
ный способ возврата почты. Пусть, к примеру, некто Джо Смит (Joe Smith)
закончил учебу в университете (oldsite.edu) и поступил на работу в компанию
(newsite.com). Включение средства redirect командой
FEATURE('redirect•)
и добавление строки
smith]: joe@newsite.com.REDIRECT
в файл псевдонимов обеспечат возврат почты, приходящей на имя пользо-
вателя smith), отправителю вместе с сообщением об ошибке, в котором
предлагается посылать почту по адресу joe@newsite.com. Сами почтовые
сообщения пересылаться не будут.
Средство olwoysodd_domain
Когда средство always_add_domain включено, программа sendmail
добавляет имя локального узла к адресу получателя, если адрес не является
полностью определенным. Предположим, что копия сообщения (от пользо-
вателя lynda@cs.colorado.edu), направленного по адресу barb@netrack.neL
посылается локальному пользователю evi. Если средство always_add_domair
не включено, пользователь barb увидит в заголовке L,Cc:” просто имя evi.
Предположим, пользователь barb хочет ответить всем указанным в заголовках
данного письма адресатам. В их число попадет и пользователь evi. одним 
такое регистрационное имя на машине netrack.net может либо отсутствовать,
либо принадлежать совсем другому пользователю При включенном средстве
always add domain имя evi будет преобразовано в evi@cs.colorado.edu до
того, как сообщение покинет компьютер пользователя linda.
Данное средство эффективно также в том случае, когда буферные каталоги
совместно используются компьютерами, не имеющими единого файла alias
или не содержащими одинаковые файлы passwd (в этой ситуации, очевидно,
не следовало бы совместно использовать почтовые буферы). Поскольку
адресат (псевдоним или пользователь) будет известен не на каждом компью-
тере, то необходимо на исходном компьютере полностью определить адрес,
чтобы по нему можно было послать ответное сообщение.
Еще один аргумент в пользу средства always_add_domain состоит ь
том, что сообщения с неполными именами часто отбрасываются как снам
Поэтому мы рекомендуем всегда активизировать это средство.
Если используется макрос MASQUERADE_AS, средство always—a.id_d
main добавляет имя узла, которое было выбрано для маскирования, a гь
имя локального узла. Это может вызвать проблемы, если файл aliases или
passwd на локальном компьютере не является подмножеством одноименного
файла на узле, указанном в качестве маскирующего.
Средство nocononify
Это средство отменяет процесс поиска адресов в DNS. KOTopi.ni
необходим для отправки сообщения. Например, при наличии гланишч
610
Чость II Робою в
концентратора почты, через который посылают свою почту все клиентские
компьютеры, на последних можно задать команду
FEATURE('nocanonifу’)
и тем самым отменить поиск в DNS на локальном уровне. Такой прием
продемонстрирован в нашем втором примере (см. далее). Данное средство
также может быть использовано на очень больших почтовых узлах, где
функционируют агенты подачи и транспортировки почты. В этом случае
поиск в DNS осуществляет агент подачи, а главный компьютер, на котором
запушен агент транспортировки, работает в режиме nocanonify.
Таблицы и базы данных
В программе sendmail имеется несколько средств, используюших конст-
рукцию, условно называемую таблицей. Она указывает, как маршрутизировать
почту. Таблица представляет собой текстовый файл с информацией о
маршрутах, псевдонимах и методах доступа, который конвертируется при
помощи команды makemap в формат базы данных и затем используется
программой sendmail в качестве внутренней поисковой базы данных. Однако
наличие централизованного IMAP- или POP-сервера избавляет программу от
рутинных операций по поиску' пользователей и делает ненужными некоторые
из описанных ниже таблиц.
Поддерживаются две библиотеки функций, предназначенных для работы
с базами данных: dbm/ndbm (является стандартом в большинстве версий
UNIX) и Berkeley DB (расширяемая библиотека, поддерживающая несколько
схем хранения). Выбор библиотеки необходимо сделать на этапе компиляции.
Мы рекомендуем библиотеку Berkeley DB так как она работает быстрее и
создает меньшие по объему файлы.
Имеются три типа поисковых таблиц:
•	dbm — использует расширяемый алгоритм хэширования (dbm/ndbm);
•	hash — использует стандартную схему хэширования (Berkeley DB);
•	btree — использует структуру данных типа двоичного дерева (Berkeley DB).
Для большинства задач, связанных с применением таблиц, наиболее
приемлемым оказывается тип hash, который предлагается по умолчанию
Используйте команду makemap для построения базы данных из текстового
файла. При этом нужно указать тип базы данных и имя ее файла. Текстовая
версия базы данных должна подаваться на стандартный вход команды
makemap:
#	makemap hash /etc/шаИ/access < /etc/mall/access
На первый взгляд данная команда выглядит неправильной, так как
кажется, что в результате произойдет замена входного файла пустым
выходным. Однако команда makemap присоединяет к имени файла суффикс,
и потому выходной файл в действительности называется /elc/mail/access.db.
При каждом изменен ни текстового файла необходимо с помощью команды
makemap перестраивать файл базы данных (останавливать программу sendmail
сигналом HUP нет необходимости).
Поскольку для базы данных строятся ключи и прн поиске ключа
выбирается самое длинное из возможных совпадений. порядок размещения
элементов в текстовом файле не имеет значения. Если какое-то средство
ожидает файл базы данных в качестве параметра, то по умолчанию
Главе 19. Электронная почто
611
принимается тип hash и файл /etc/mail/uM#_nmfi4U4u.db. Чтобы изменить
эту установку, укажите требуемый тип при вызове команды makemap и в
макросе FEATURE либо поменяйте стандартные значения, переопределив
переменную DATABASE_MAP_TYPE:
define ("DATABASE J4AP_TYРЕ’ , 'dbm')
Для подключения новой базы данных access.db необходимо добавить в
тс-файл следующую команду:
FEATURE t access_db', 'hash /etc/mail/access')
Поскольку в данной строке активизируются установки по умолчанию, ее
можно упростить:
FEATURE [’accessjdb'}
Имя файла базы данных разрешается указывать как с суффиксом (.db),
так и без него.
Не забывайте перестраивать базу данных при помощи команды makcmap
всякий раз, когда изменяется текстовый файл. В противном случае эти
изменения не будут учитываться.
В следующих разделах мы опишем средства mailertabie, generict-
аЫе и virtusertable. Средство access_ob рассмотрено в параграфе,
посвященном спаму. Средство user_db мы не рассматриваем вовсе, так как
в настоящее время оно используется редко.
Средство moilertoble
Средство mailertabie перенаправляет почту, адресованную конкретно-
му узлу' или домен}', по альтернативному адресу с помощью заданного агента
доставки Оно применяется для отправки почты и принимает во внимание
только доменную часть адреса, а имя пользователя не рассматривает. Адрес
конверта при этом не переписывается, поэтому почта предназначается тому
же самому пользователю, но посылается на другой узел другим агентом
доставки. Средство mailertabie было создано для взаимодействия с иными
почтовыми системами, такими как UUCP, DECnet и BITNET, но, поскольку
они в настоящее время почти не применяются, потребность в средстве
mailertable в основном отпала.
Запись для средства ma ile г table имеет следующий вид.
старый__домен	агентдоставки:польэователь@ксвый_домен
Если перед левым ключевым словом указана точка, то это означает
“любой узел домена”. В качестве ключа для средства mailertabie можно
применять только имя компьютера или домена; имена пользователей
недопустимы. Элемент кольэователь@новыц_домен может быть опушен. В этом
случае заголовки сообщения не изменяются. В качестве параметра агентдос-
тпавки может быть задан только агент, определенный с помощью макроса
MAILER.
Чтобы включить средство mailertabie, в тс-файл необходимо вставить
следующую строку:
FEATURE{‘mailercable’)
612
Чость II. Робато в сетях
Средство genericstable
Применение средства genericstable (“generics table” — общая таблица)
аналогично созданию псевдонимов для исходящей почты. Например, можно
заменить имя trent@xor.com в исходящем сообщении именем
trent.hein@xor.com. При этом переписываются заголовки сообщения, а не его
конверт. Данное средство не влияет на то. куда будет доставлена почта. Оно
определяет, кто получит ответ.
Существует несколько методов переписывания имени компьютера, однако
только средство genericstable позволяет помешать в ключ замены как
имя пользователя, так и имя компьютера. К адресам, заданным в средстве
genericstable, могут также применяться описанные ниже средства nas-
querade_envelope И allmasquerade.
Перед использованием средства genericstable убедитесь, что требуе-
мый домен является доменом класса generics. Чтобы поместить домен в
класс generics, укажите его в макросе GENERIC_DOMAIN или включите в
файл, заданный в макросе GENERIC_DOMAIN_FILE.
Следующие команды активизируют средство genericstable со стан-
дартными установками:
GENER1C_DOMAIN_=ILE(*/etc/mail/local-host-names’)
FEATURE Ggenericscaole‘}
В данном примере в файл включается имя любого компьютера, для
которого принимается почта. Средство genericstable замедляет работ.’
программы sendmail, поскольку оно требует просматривать каждый адрес
отправителя.
Средство virtusertoble
Таблица виртуальных пользователей содержит доменные псевдонимы для
входящей почты. Средство virLusertable позволяет работать на одном
компьютере с несколькими виртуальными доменами. Оно часто используется
в организациях, занимающихся Web-хостингом
Поле ключа таблицы содержит адрес электронной почты (пользова-
тельФколшыотер.домен) или спецификацию домена (@ домен). Поле значения
представляет собой локальный почтовый адрес, внешний почтовый адрес или
спецификацию типа агент_доставки:адрес. Если ключ — это имя домена, то
имя пользователя в поле значения может задаваться в виде переменной %1
либо указываться явно.
Рассмотрим следующий пример*
info@foo.com foo-info
info@bar.com bar-info
joe@bar.com error:No such user
Gtoaz.org jane@elsewhere.com
Gbaz.org %l@elsewhere.coin
1 маршрут к локальному пользователю
#	другой локальный пользователь
#	возврат ошибки
#	вся почта направляется
пользователю jane
f вся почта направляется тому же
пользователю
Все узлы, перечисленные в левой части, должны быть указаны в cw-фаиле
(или в новом классе VirtHost) В противном случае программа sendmail
попытается найти узел в Internet и доставить почту гуда. Если DNS направит
программу sendmail назад ни данный сервер, будет получено сообщение об
ошибке локальной конфигурации К сожалению, программа sendmail не может
Глово 19. Электронной почто
613
сказать, что в действительности сообщение об ошибке должно выглядеть тлк
"‘В файле cw отсутствует ключ для средства virtusertable”.
Чтобы описанный механизм работал, необходимо соблюдение следующих
условий:
•	должны существовать такие DNS-записи MX, чтобы почта доставлялась
правильному узлу;
•	в cw-файле должны быть такие записи, чтобы локальный компьютер moi
принять почту; с этой же целью может быть задан макрос VIRTUSER DO-
MAIN (или эквивалентный ему макрос VIRTUSER_DOMAIN_FILE);
•	таблица виртуальных пользователей должна указывать программе sendmail
что делать с почтой.
Данное средство активизируется при помощи следующей команды:
FEATURE('virtusertable')
Примеры в параграфе 19.9 демонстрируют использование средства тт
tusertable для организации виртуального хостинга
Среда вс Idop routing
Рассказывая о псевдонимах и перенаправлении почты, нельзя не упомя
нуть еше раз протокол LDAP. Этот протокол может быть использован вместо
средства virtusertable для маршрутизации и приема почты в виртуальных
доменах Он также позволяет управлять псевдонимами, за исключением
списков рассылки.
Чтобы использовать протокол LDAP для решения указанных задач,
необходимо ввести в конфигурационный файл несколько команд, а затем
скомпилировать программу sendmail с поддержкой LDAP. В mc-файл требуется
включить следующие строки:
FEATURE('ldap_routing1)
LDAPROUTE_DOMAIN('домен’)
define('confLDAP_DEFAULT_SPEC’, '-h сервер -b база поиска1)
Благодаря им программа sendmail узнает о том, что нужно использовать
базу данных LDaP для маршрутизации входящей почты, адресованнои
указанному домену. Опция LDAp_PEFAULT_SPEC определяет сервер LDAP
и имя базы данных, в которой осуществляется поиск
В следующем примере база, в которой надо осуществлять поиск,
определяется так: o=sendmail.com, c=US. Если протокол LDAP применяется
не на стандартном порте 389. добавьте выражение -о порт# в спецификацию
опции LDAP_DEFAULT SPEC.
Программа sendmail использует два тега в базе данных LDAP:
•	mailLocaiAddress — для получателей входящей почты.
•	mailRoutingAddress — для псевдонимов адресатов.
Программа sendmail также поддерживает тег mailHost. При его нали*П и
почта для узла, указанного в теге mailRoutingAddress, посылается
компьютеру, на который ссылается наиболее приоритетная запись MX yr.!,
указанного в теге mailHost.
Например, присутствие LDaP-зэписи (для сервера, сконфигурирован ниш
с уникальным именем корневого каталога, равным cn=root, o=ser -
mail.com, c=OS)
614
Чость II Роботе в сетях
dn: uid=eric, o=sennail.com, c=US
objectclass: inetLocalMailRecipient
mailLocalAddress: ericesendmail.org
mailRoutingAddress: eric6eng.sendmail.com
приведет к тому, что почта, адресованная пользователю eric@sendmail.org
(записи MX предписывают посылать ее на узел sendmail.com), будет
доставляться по адресу enc@eng.sendmail.com. Если же LDAP-запись будет
включать еще строку
mailHost: mailserver.sendmail.com
то почта для пользователя eric@sendmail.org будет адресоваться пользователю
eric@eng.sendrnail.com и направляться узлу, на который ссылается наиболее
приоритетная запись MX компьютера mailserver.
Формат базы данных LDAP допускает использование неполных записей
типа @домен, которые перенаправляют почту на указанный домен вне
зависимости от того, кому конкретно она адресована (как в средстве
virtusertable).
Маскирование адресов и мокрое MASQUERADEAS
Макрос MASQUERADE AS позволяет задать единый адрес, за которым
будут '‘скрываться” все компьютеры. При этом создается видимость. что вся
почта поступает с одного компьютера или из одного домена. Адрес
отправителя пользователь@ исходный_узея.домен меняется на полъзователъ@мас-
кированное_имя. Конечно, адреса-маски должны быть легитимными, чтобы
можно было получить ответ на свою почту.
Такая конфигурация позволяет всем пользователям организации иметь
одинаковые электронные адреса. Если, например, все узлы домена xor.com
маскируются под именем xor.com, то почта, направленная с адреса пользова-
тель@компьютер.тг.сот, будет содержать адрес отправителя полъзова-
meib@xor.com. Компьютер, который управляет доменом xor.com, должен
знать, как доставлять почту всем пользователям, даже тем. кто не имеют
регистрационного имени на сервере входящей почты. Естественно, регистра-
ционные имена должны быть уникальными во всем домене.
Некоторые пользователи и адреса (например, root, postmaster, hostmaster,
trouble, operations, Mailer-Daemon и др.) должны быть исключены из системы
маскирования. Это можно сделать явно с помощью макроса EXPOSED JUSER.
В частности, последовательность команд
MASQUERADE_AS('xor.сот *)
EXPOSEDUSER('root•1
EXPOSED USER('Mail-Daemon’)
идентифицирует всю почту как поступающую от имени лользолз/ке,ib@xor.com,
если только она не послана пользователями root и postmaster Почта этих
пользователей будет снабжена адресом реальной машины-отправителя.
Существует несколько расширений базового макроса MASQUERADE_AS.
Они реализованы как в виде макросов, так и в виде средств:
•	макрос MASQUERADE_DOMAIN,
•	макрос MASQUERADE_DOMAIN_FILE,
•	макрос MASQUERADE_EXCEPTION,
•	средство lxniited_masqueradet
Глово 19. Электронная почта
615
•	средство allmasquerade.
•	средство masquerade_envelope,
•	средство masquerade_entire_domain.
Мы рекомендуем использовать макрос MA5QUERADE_AS вместе со
средствами allraasquerade и masquerade_en.velope. Средство lim-
ited_masquerade модифицирует повеление макроса MASQ(jERADE_DOMAIN.
Оно полезно для организации среды виртуального хостинга. Макрос MAS-
QUERADE—DOMAIN позволяет перечислить домены, подлежащие маскирова-
нию. Этот список предварительно загружается из класса и. который обычно
определяется с помощью средства jse_cw_file и содержит перечень узлов
домена. Средство limited_masquerade не инициализирует список на
основе информации из класса w Все эти домены будут скрыты за доменным
именем, указанным в качестве маскирующего
Средство allmasquerade расширяет маскирование на получателей
сообщения, а средство masquerade_envelope маскирует адреса конверта
и адреса в заголовках’ Этих двух средств достаточно, чтобы все адреса
обрабатывались одинаково. Средство limited^masquerade маскирует ад-
реса указанных доменов.
Мокро константы MAILHUB и SMARTHOST
Используя средства маскирования, можно сделать так, что почта будет
выглядеть как отправленная из одного компьютера или домена. Достигается
это путем переписывания заголовков или, иногда, конвертов. Однако в
некоторых случаях требуется, чтобы отправкой (или приемом) почты
действительно занимался один компьютер. Для входящей почты это реали-
зуется при помощи макроконстанты MAIL_HUB, а для исходящей —
посредством макроконстанты SMART_HOST.
Если необходимо пересылать всю входящую почту на центральный сервер
для последующей ее доставки, присвойте макроконстанте MAIL_HUB значение
агент доставки.компъютер, где агент доставки — это агент, который должен
использоваться для достижения указанного компьютера. Если данный аргу-
мент не задан, используется агент relay. Например:
define{'smtp:mailhub.es.colorado.edu’)
Макроконстанта SMART_HOST заставляет компьютер доставлять локаль-
ную почту, а внешнюю почту отправлять по указанному адресу. Эта константа
может применяться компьютерами, которые скрыты за брандмауэром и не
могут непосредственно посылать запросы в службу DNS. Синтаксис опреде-
ления этой константы такой же, как у константы mail_HUB. Агентом
доставки, установленным по умолчанию, является агент relay. Например:
define! ' SMART’_HOST ’, ' smep: mailhub. cs .Colorado. edu ’)
Это адреса "To”, “From”, “Cc" и “Вес”, которые появляются в заголовках сообщения. Адрес
конверта — это адрес, по которому в действительности отправляется сообщение. Адреса
конвертов формируются пользовательским агентом нз адресов в заголовках, однако про-
грамма sendmail обрабатывает их отдельно. Многие средства программы, относящиеся к
маскированию и перенаправлению почты, невозможно было бы реализовать при отсутствии
возможности учета различий между адресами в заголовке и конверте.
6Г>
Чость II. Робота в сетях
В данном примере один и тот же компьютер действует как сервер и
входящей, и исходящей почты. В больших организациях может потребоваться
выделить для этих целей разные компьютеры.
Маскирование и маршрутизация
Итак, мы уже описали много средств и макросов, которые тем или иным
способом воздействуют на адреса электронной почты. Сейчас, вероятно, самое
время провести их анализ. В частности, следует рассмотреть, что именно они
делают: изменяют заголовки, адреса конверта или адрес доставки сообщения,
применяются к входящей или исходящей почте, к адресам получателя или
отправителя и т.д. Конечно, если бы страница книги была раза в два шире,
мы могли бы проиллюстрировать все различия. А поскольку это не так.
приведем только общую информацию. За более полными сведениями
читателям придется обратиться к документации по программе sendmail.
Элементы, указанные в табл. 19.12 прописными буквами, являются
макросами препроцессора т4. Строчными буквами записаны средства,
которые активизируются посредством макроса FEATURE. Отступами слева
иллюстрируется зависимость средств и макросов. Например, средства, кото-
рые связаны с макросом MASQUERADE_AS, не работают, пока этот макрос не
включен. Средства маскирования воздействуют на адреса в заголовках
исходящих сообщений и определяют, можно ли будет получить на ннх ответ.
Средства маршрутизации влияют на доставку сообщений.
Тоблицо 19 12. Сровнение средств москировония и моршрутизоции
Конструкция	Почта	Влияние1	Чость адреса
MASQUERADE_AS	ИСХ.	03	уэел.домен
® allmasquerade	ИСХ.	пз	уэел.домен
§ MASQUERADE_DOMATN[_FiLEj	ИСХ.	03	узел.домен
%	masouerade entire domain	ИСХ.	03	пользователь.под-
5			домен.домен
О Irmtteojr.asquerade	ИСХ.	03	уэел.домен
masque rade_envelope	ИСХ.	ОК3	уэел.домен
genericstable	ИСХ.	03	пояьзователь@узел.
			домен
mailertable	ИСХ.	АгАД	уэел.домен
=r virtusertable	вход.	пд	пользователъ@уэел.
TO			домен
g Idap	вход.	пд	пользователь®узел.
3			домен
.° mailhub	вход.	пд	уэел.домен
smarthost	ИСХ.	пд	уэел.домен
1 О — отправитель, П — получатель, Д — доставка, 3 — заголовок, К — конверт.
Аг — агент, А — адрес.
2 Если при помоши средства masquerade envelope задано переписывание адреса
конверта, все другие маскирующие конструкции будут переписывать нс только
заголовок, но и конверт.
Глоао 19. Электронноя почто
617
Средство nullclient
Средство nullclient предназначено для компьютера, который не
должен получать почту непосредственно, а всю исходящую почту должен
посылать на центральный сервер. Для такого компьютера mc-файл включает
всего две строки*
OSTYPE(*ТипОС’)
FEATURE(’nullclxent’, 'иочтовый_сервер ')
Средство nullclient отменяет назначения, выполненные при помощи
других средств. Вся почта без исключения будет доставляться на компьютер
почтовый сервер для обработки". Учтите, что сервер должен обеспечивать
дальнейшую ретрансляцию почты, исходящей от клиента. В последних
версиях программы sendmail эта возможность отключена по умолчанию. Об
управлении ретрансляцией будет подробнее рассказываться в параграфе,
посвященном спаму. Так как все * нуль-клиенты" будут выглядеть как
почтовый-Сервер, возможно, понадобится ввести конструкцию EXPOSED_USER
для пользователя root.
Клиент, иа котором активизировано средство nullclient, должен иметь
соответствующую запись MX, указывающую на сервер. Он также должен
быть упомянут в cw-файле сервера (обычно это файл /etc/mail/local-hoM-
namesj Все эти установки позволят серверу принимать почту для данного
клиента.
‘‘Нуль-клиент’* не должен принимать входящую почту. Если бы он это
делал, ему все равно пришлось бы перенаправлять почту' на сервер. Запустите
программу sendmail без флагов -bd. чтобы оиа не ожидала SMTP-соединений
на порту 25. Флаг -q30m не удаляйте, чтобы в случае останова почтового
сервера клиент мог помещать исходящие сообщения в очередь и отправлять
их позднее.
Средство nullclient подходит для конечных узлов небольшой органи-
зации с центральным почтовым сервером. В крупных организациях следует
рассмотреть возможность возложения почтовых функций на маши ну-кон цен-
тратор, разделить серверы входящей и исходящей почты или использовать
иерархический подход к организации электронной почты.
Средства local Imtp и smrsh
Программа /bin/mail все хуже справляется с ролью локального агента
доставки r UNIX. Если средство local _ Imtp определено, то его аргументом
является имя локального агента, который понимает протокол LMTP (Local
Mail Transpon Protocol — протокол доставки локальной почта), определенный
в документе RFC2033. По умолчанию таковым является программа mail-local,
включенная в дистрибутив sendmail. Эта профамма инсталлируется в каталог
/usr/libexec/mail .local. но посредством отшпн confEBlNDIB можно задать
другой каталог.
Профамма smrsh — это усеченный интерпретатор команд, входящий в
дистрибутив sendmail. Он служит заменой традиционному агенту программной
доставки, /bin/sh Программа smrsh облегчает администратору локальной
Если клиентский компьютер сконфигурировать таким образом, а затем протестировать
конфигурацию посредством команды sendmail -ht, то окажется, что клиент локально дос-
тавляет локальную почту. Причиной этого является то обстоятельство, что директива
nullclient обрабатывается позднее, в наборе правил 5 файла конфигурация.
6 8
Чость II Робото в сетях
системы контроль над тем. какие команды вызываются для обслуживания
электронной почты. Запускать можно только те программы, которые нахо-
дятся в каталоге двоичных файлов программы smrsh. Обычно это каталог
/usr/adm/sm.bin (задается в процессе компиляции программы! Программа
smrsh также отслеживает в командах ‘’подозрительные” символы (например,
операторы перенаправления стандартного выходного потока) и при их
обнаружении прерывает доставку почты.
Мы рекомендуем инсталлировать и программу smrsh, и программу
mail.local, а также включить средства, которые их используют:
FEATURE('local—Smtp’, '/usr/libexec/mail.local')
FEATURE{’smrsh’, ’/usr/libexec/smrsh')
Подробнее о программе smrsh рассказывается в параграфе 19.11.
Средство local procmail
При включении средства local procmail появится возможность при-
менять в качестве локального агента доставки программу procmail (автор —
Стефан ван лен Берг), Данное средство требует указания только одного
аргумента. Таковым является путь к двоичному файлу procmail.
Программа procmail может делать гораздо больше, чем простые программы
/bin/mail или mail.local. Кроме доставки сообщений в почтовые ящики
пользователей программа способна сортировать сообщения по папкам,
сохранять их в файлах, вызывать программы и фильтровать спам Программа
procmail не входит в дистрибутив sendmail. Ее можно получить на Web-узле
www.procmail.oTE. При помоши средства local procmail можно задать
использование другой, отличной от procmail. программы. Для этого обманите
программу sendmail. сделав вид. что залаете локальную копию программы
procmail:
FEATURE{'localprocmail’, /usr/locai/bin/mymailer')
Макросы LOCAL *
Если требуется написать несколько новых экзотических правил для
каких-либо особых ситуаций, используйте набор макросов с префиксом
LOCAL. Примеры таких конструкций приведены в параграфе 19.9.
Конфигурационные опции
Конфигурационные опции и макросы (команды О и D языка конфигу-
рирования программы sendmail) могут быть установлены при помощи команды
define препроцессора т4. Полный список опций, доступных в виде
переменных препроцессора, а также их значения по умолчанию приведены
в файле сГ/README. Для большинства систем подходят стандартные
значения
Вот несколько примеров:
defгпе('confTO_QUEUERETURN1, ’7d')
define (’confTO__QUEUEWARN ', ’ 4h ’)
define(‘confPRIVACY FLAGS', 'поекрп'3
Опция confTO_QUEUERETUFN определяет, как долго разрешено нахо-
диться в очереди сообщению, которое не может быть доставлено. Опция
confTO QUEUEWARN задает, сколько времени сообщение должно стоять в
19 Электронной почто
619
очереди, чтобы его отправитель получил уведомление о том. что с сообщением
не все в порядке. В первых двух строках для данных опций задаются значения
7 дней и 4 часа соответственно.
В следующей строке устанавливаются флаги безопасности, которые
запрещают SMTP-команду EXPN (раскрытие адреса). Опция confPRl-
VACY_FLAGS принимает разделенный запятыми список флагов. Некоторые
версии препроцессора гп4 требуют в этом случае ставить дне пары кавычек:
def ine( ’conf PRIVACY_FLAGS 1 , 'г.оехрп, novrfy1')
Более полная информация об опциях безопасности приведена в параграфе 19. И.
Стандартные значения большинства опций оказываются приемлемыми
для небольших и среднего размера организаций, в которых безопасность и
производительность не являются критическими факторами. Однако, пользуясь
значениями по умолчанию, можно стать жертвой спама. С целью борьбы со
спамом ряд установок придется изменить. Если почтовый концентратор
испытывает большую нагрузку и обрабатывает много списков рассылки,
возможно, потребуется настроить ряд опций, влияющих на производитель-
ность.
Опции, которые может понадобиться настраивать, перечислены в
табл. 19.13 (это лишь около пятнадцати процентов из 150 опций конфигу-
рации). Тут же указаны и их значения по умолчанию. В целях экономии
места опции приведены без префикса conf. Например, опция FALLBACK__MX
в действительности называется confFALLBACK_MX. Таблица разделена на
части в соответствии с тем, для каких целей применяется опция: общих,
связанных с ресурсами, производительностью и безопасностью/спамом и
прочих. Некоторые опции правильнее было бы разместить в нескольких
частях, однако мы указали их только в одном месте.
Тоблицо 19.13. Бозовые опции конфигурации
	Опция	Описание и значение по .молчанию
	CWFILE	Ухты, для которых принимается почта и кото- рые считаются локальными (/etc/mail/local-host- names)
а> I	COPY_ERRORS_TO	Адрес в заголовке "Сс” сообщения об ошибке (отсутствует)
UD О	DOUBLE_BOLNCE_ADDRESS	Перехват спама, в некоторых системах спам направляется в файл /dev/null, ко это чревато тем, что серьезные проблемы останутся незаме- ченными (postmaster)
1	M1N_FREE_BLOCKS	Минимальное пространство в файловой системе для получения почты (100)
1	МАХ_М ESSAG E_SIZE TOjmu	Максимальный размер в байтах одного сообще- ния (Неограничен) Время тайм-аута для разных ситуаций (варьи- руется)
о	TOJDENT MAX_DAEMON_CHI LDR EM	Время ожидания запросов на аутентификацию отправителя; если задано значение 0, проверка не выполняется (5s) Максимальное количество порожденных про- цессов1 (не ограничено)
Если быть более точным, то это максимальное количество порожденных процессов,
запускаемых одновременно При достижении предельного значения программа
sendmail отказывается принимать запросы. Эта опция позволяет предотвратить атаки
вида "отказ от обслуживания".
62U
Часть II. Робота в сетях
	Опция	Описание и значение по умолчанию
	MCI_CACHE_SIZE	Количество открытых кэшированных ТСР-соади- нений (2)
	MCI_CACHE_TIMEOUT	Время, в течение которого кэшированные со- единения остаются открытыми (5m)
	HOST_STATUS_DIRECTORY	Описание приведено в основном тексте (значе- ние по умолчанию отсутствует)
g	FALLBACK MX	Локальный узел для пересылки сообщений, от-
о		правка которых завершилась неудачно; позволяет
1		централизовано обрабатывать "проблемную" поч- ту (значение по умолчанию отсутствует)
1	QUEUE LA	Показатель средней загруженности, при кото-
£		ром сообщения помещаются в очередь, а не
г		отправляются немедленно (Ъ*число_процессорое)
&	REFUSE LA	Показатель средней загруженности, при кото-
		ром происходит отказ от почты (12" число_про- цессоров)
	min_queue_age	Минимальный период времени, в течение ко- торого задание должно находиться в очереди, позволяет улучшить обработку очереди на пере- груженной машине (0)
	DONT_INIT GROUPS	Рекомендуется включать, если почтовый сервер имеет файл группы большого объема, управляе- мый службой NIS (false)
	TRUSTED.USERS	Позволяет владельцам программ, связанных с управлением списками рассылки, подделывать сроку "From" (root, daemon)
	PRIVACY_FLAGS	Задает ограничения на информацию, выдавае- мую по протоколу SMTP (authwarnings)
	MAX_HEADERS_LENGTH	Максимальный размер (в байтах) заголовка письма; позволяет защитить буфер пользова- тельского агента от атаки по принципу пере-
о		полнеиия (не ограничен)
.ь I";	MAX_MIME_HEADERS_LENGTH	Также защищает буфер пользовательского агента от переполнения (размер буфера не ограничен)
О	CONNECTION RATE THROTTLE	Предотвращает атаки вида "отказ от обслужи- вания” за счет ограничения скорости, при
т и		
		которой разрешается устанавливать почтовое
0 р		соединение (ие ограничена)
>8	MAX_RCFTS_PER_MESSAG E	Задерживает отправку спама; приостанавливает обработку избыточного числа получателей и генерирует временное сообщение об ошибке (число получателей ие ограничено)
	DONTBLAM ESEN DMAIL	Отменяет такие функции программы sendmail. как контроль безопасности и проверка файлов; не изменяйте значение этой опции без особой необходимости (safe)
	AUTH_MECHAN|SMS	Список механизмов аутентификации по прото- колу SMTP для библиотеки Cyrus SASL (пуст)
	DEF_AUTHJNFO	Файл с аутентификационной информацией для исходящей почты (не определен)
8	LDAP_DEFAULT SPEC	Спецификация базы данных LDAP, включая
		имя компьютера, иа котором залущеи сервер,
а		и номер порта (ие определена)
Глово 19. Электронной почто
621
Используйте опцию HOST__STATUS_DIrectory на загруженных узлах,
которые вынуждены обрабатывать большой объем отвергнутой почты. Эта
опция предписывает программе sendmail хранить в статусном каталоге фант
для каждого компьютера, на который не удается выполнить доставку. На
основании данной информации определяются приоритеты просмотра узлов
при повторной обработке очереди. Это позволяет реализовать схему отрица-
тельного кэширования (см. главу 16) и обмениваться статусной информацией
при обработке разных почтовых очередей. Ниже приведена команда, в
которой каталог /etc/mail/.hoststat выделяется для хранения статусной инфор-
мации (этот каталог сначала нужно создать):
define('confHOST_STATUS_DIRECTORY’ , ' .hoststat)
Опция FALLBACKJMX также позволяет повысить производительность. Она
задает пересылку всей неотправленной по’пы на локальный сервер, освобо-
ждая тем самым основной почтовый сервер для доставки почты с правиль-
ными адресами. Это средство очень удобно для узлов с большими списками
рассылки, где постоянно попадаются адреса, по которым невозможно
доставить почту. Например, команда
define(‘confFALLBACKMX1, 'mailbackup.xor.com’)
задает пересылку всех сообщений, которые не удалось доставить с первого
раза, на центральный сервер mailbackup.xor.com для последующей обработки.
Некоторые опции, относящиеся к режиму демона н влияющие на
производительность, имеют слегка отличающийся синтаксис вызова. Напри-
мер, чтобы заставить программу sendmail действовать и как агент подачи, и
как транспортный агеит, введите следующие команды:
DAEMON_OPTIONS (' Pcrc=25, Name=MTA’)
DAEMON OPTIONS(‘Port -567,Name-MSA,М-Е‘)
Это стандартная конфигурация начиная с версии 8.10.
19.9. Примеры файлов конфигурации
Несмотря ня то что мы изучили не все конфигурационные опции
(параграфы, посвященные спаму и безопасности, приведены далее), сейчас
самое время рассмотреть примеры конфигурационных файлов. Конечно, это
может показаться очередной попыткой поставить телегу впереди лошади, но
мы уверены, что практика — лучший способ упорядочить полученные знания.
Кроме того, мы еще не рассмотрели такой важный механизм, как база
доступа, которая используется преимущественно для фильтрации и управле-
ния спамом. Она также описана чуть позже.
Собранные нами в различных системах конфигурационные файлы
содержали “мусор", который наслоился в процессе их модификации. Перед
включением файлов в книгу мы " почистил и *’ их, исправили грамматические
ошибки, несоответствия и пр. Поэтому файлы предстанут перед читателями
не совсем в том виде, в котором они находились на реальных узлах. Тем не
менее они отражают вполне реальные конфигурации.
622
Чость 11 Робото в сетях
Домашний компьютер студента факультета
вычислительной техники
В центре нашего первого примера — студент Роб Браун, который имеет
дома Linux-систему (gw.synack.net) и занимается виртуальным хостингом для
почтовых доменов своих друзей: xinetd.org, teich.net и cubecast.com
Роб выполняет хостинг и для собственного домена synack.net. Правильный
адресат входящей почты определяется посредством протокола LDAP. Для
управления виртуальным хостингом используется средство virtusertable,
а для обработки исходящей почты — средство genericstable. Из всего
многообразия способов управления исходящей почтой только средство
genericstable позволяет менять как имя пользователя, так и адрес домена
получателя.
Принадлежащий Робу файл для средства genericstable (называется
outmap) содержит следующие записи:
bbraun
stabile]
teich
rob@synack.net
j on@synack.net
oren@teich.net
С целью отслеживания спама Роб ведет список DNS Realtime Blackhole
(dnsbl). Он пользуется также функциями маскирования для того, чтобы
любые исходящие сообщения, адреса которых еше не модифицированы
средством genericstable, выглядели как поступившие от пользователя
лг<?льзовсшель@5упаск.пс1_ а не от полъзователb@gw.synack.net. Ниже приведено
полное содержимое файла gw.тс;
divert(0)
VERSIONIDCe (#)synack.net.тс В-7 (Berkeley) 5/19/1998•)
OSTYPE(linux)
DOMAIN(generic)
FEATURE(dnsbl)
FEATURE(virtusertable, '/etc/mail/inmap')
FEATURE(genericstable, ‘/etc/marl/outmap’)
GENERICS_DOMAIN_FILE(’/etc/mail/local-host-names')
MASQUERADE_AS(synack.net)
FEATURE('masquerade_envelope1)
FEATURE('Idap routing')
LDAPROUTEDOMAIN(’synack.net')
define (' confLDAP_DEFAULT_SPEC’, " -h gw.synack.net -b dc=synack, dc=net *)
MAILER(local)
MAILER(smtp)
Файл /etc/mail/local-host-names (раньше он назывался sendmail.cw) содер-
жит имена компьютеров и доменов, для которых данный узел принимает
почту. Средство use_cw_f ile, подключающее этот файл, скрыто в доменном
файле generic (его содержимое приведено в следующем разделе). Ретрансляция
отключена по умолчанию, потому что файл /etc/mail/relay-domains обычно
пуст. Но в данном случае этот файл содержит имена доменов, для которых
узел gw.synack.nei осуществляет виртуальный хостинг. База данных LDAP
сконфигурирована посредством файла Jdap.conf, в котором задается уникаль-
ное имя корневого каталога LDAP, узел для сервера LDAP и порт:
BASE dc=synack, dc=net
HOST gw.synack.net
PORT 389
Глово 19. Электронной почто
623
Сама база данных LDAP формируется на основе текстового файла
следующего вида:
dn: uid-rob, dc-зупаск, dc-net
objectClass: inetLocalMailRecipient
mailLocalAddress: robesynack.net
mailRoutingAddress: bbraunGsynack.net
uid:rob
dn: uid-webmaster, dc-synack, dc-net
objectclass: inetLocalMailRecipient
mailLocalAddress: webmaster0Bynaok.net
mailRoutingAddress: bbraunesynack.net
uid:webmaster
dn: uld-teich, dc-synack, dc-net
objectClass; inetLocalMailRecipient
mailLocalAddress: teichfisynack.net
mallRoutlngAddress: orenGteich.net
uid:teich
dn: uid“xinetd, dc-synack, dc-net
objectclass: inetLocalMailRecipient
mailLocalAddress: xinetd0synack.net
mailRoutingAddress: xinetd
uid-.xinetd
Три первые записи служат для установки соответствия между зарегист-
рированными именами rob webmaster и oren и их псевдонимами. Четвертая
запись представляет собой список рассылки, который связан с локальным
файлом псевдонимов и обрабатывается программой Majordomo. Соответст-
вующие записи файла /etc/mail/aliases выглядят так:
xinetd: “|/usr/local/majordomo/wrapper resend -1 test xinetd-iist"
xinetd-iist: iinclude:/usr/local/maj ordomo/listsIxinetd
xinetd-ow net; bbraun
owner-xinetd: bbraun
xinetd-request: bbraun
xinetd-approval: boraun
Рассматривая первый пример, мы познакомились с несколькими вспо-
могательными файлами. Следующие примеры более наглядно иллюстрируют,
что из себя представляет конфигурация программы sendmail, и не содержат
текстов вспомогательных файлов.
Не забывайте, что в любом примере для программы sendmail DNS-записи
MX играют важную роль и должны соответствовать имеющейся конфигурации.
Небольшой компония, использующоя прогромму sendmail
В следующем примере мы проанализируем конфигурационные файлы
небольшой компании Sendmail. Inc. знающей, как правильно настраивать
программу sendmail Их почтовая система включает главный почтовый сервер,
который выполняет функцию концентратора электронной почты для входя-
щих сообщений и служит “интеллектуальным" узлом для исходящих сооб-
щений. Сначала мы познакомимся с конфигурацией клиентов, а затем изучим
более сложную конфигурацию сервера.
624
Чость II Робото в сетях
Во всех примерах мы слегка изменили оригинальные файлы: исключили
примечания о защите авторских прав, добавили несколько комментариев и
удалили директиву dnl в конце строк. Читатели, которые решат использовать
один из наших примеров в качестве образца для собственных тс-файлов.
должны убедиться в том, что в конце всех строк удалены комментарии.
Клиентские компьютеры на узле sendmall.com
Файл smi-client.mc для клиентских компьютеров довольно прост. Он
ссылается на сервер smtp.sendmail.com, что в действительности является
псевдонимом (DNS-запись CNAME) узла katroo.sendmail.com Применение
записи CNAME удобно тем. что ее легко изменить при смеие главного
почтового сервера.
Обратите внимание на то. что файл датирован октябрем 1998 года,
В течение периода, прошедшего с того момента, программа sendmail неодно-
кратно обновлялась, однако конфигурационный файл не потребовалось
изменять.
divert(-1)
#	#### Этот файл содержит настройки для клиентских компьютеров
>	♦### компании Sendmail, Inc.; версия В.9.3.
divert(0)
VERSIONIDCe (#)smi-client.me 1.0 (Sendmail) 10/14/98’)
OSTYPE( bsd4.4')
FEATURE(’nocanonify’j
Undefine(’ALIAS_FILE')
define(‘MAIL_HUB’, 'smtp.sendmail.com’)
define(*SMART_HOST', ’smtp.sendmail.com’)
define('confFORWARD_PATH’, *')
MAILER(’local')
MAILER(’smtp’)
Макро константы MAIL_HUB и SMART_HOST задают перенаправление
входящих и исходящих сообщений на узел smtp.sendmail.com. DNS-записи
MX должны указывать на то. что этот узел имеет более высокий приоритет
(более низкий номер записи MX), чем отдельные клиентские компьютеры.
Путь для файлов .forward устанавливается пустым, файл псевдонимов также
пуст. Расшифровка псевдонимов осуществляется на сервере. Средство no-
canonify установлено здесь для экономии времени, поскольку поиск в
службе DNS выполняется на главном компьютере.
Главный компьютер на узле sendmail.com
Почтовый сервер на узле sendmail.com, как правило, подвергается
наиболее интенсивным атакам извне. Ои должен обеспечивать высокую
эффективность при обработке спама, быть устойчивым ко всем почтовым
атакам и защищать клиентские компьютеры. Вот файл, задающий конфигу-
рацию сервера.
divert(-1)
#	#### Серверный файл karroo.тс,- версия В. 9.3
divert(0)
VERSIONID£‘fi(Г)katroo.mc 2.1 (sendmail) 10/19/98')
OSTYPE('solaris2’)
DOMAIN('generic')
MASQUERADE_AS('sendmail.com')
MASQUERADEDOMAIN('sendmail.com1)
undefine('BITNET_RELAY')
Глово 19 Электронной почто
625
undefine(*UUCP_RELAY *)
define('confCHECKALIASES', 'True•)
define('confCOPY_ERRORS_TO’, 'Postmaster’)
define('confEBINDIR*, '/usr/lib1)
define('confERRORMODE•, m‘)
define('confHOST_STATUS_DIRECTORY', *.hoststat’)
define('confNO_RCPT_ACTI0N', ‘add-to-undisclosed’)
define('confPRIVACYFLAGS', authwarnings,needmailhelo,noexpn,novrfy')
define(’confTRUSTEDUSERS', majordomo’}
define(‘confMAX_DAEMON_CHILDREN1. '3Q’)
FEATURE(‘allmasquerade')
FEATURE(*masquerade_entire_domain’)
FEATURE('masquerade_envelope')
FEATURE('always_add_domain')
FEATURE('locallmtp’)
define('LOCAL_MAILER_FLAGS•, "SXfranz9PE•)
FEATURE!'mailertable•, hash /etc/mail/mailertable’)
FEATURE('virtusertable', 'hash /etc/mail/virtusercable•)
MAILER('local’)
MAILER('smtp’)
LOCAL_CONFIG
'#>#### Регулярное выражение для отбрасывания:'
• локальных числовых адресов из доменов aol.com и msn.com'
*t * локальных адресов из домена juno.com, начинающихся с цифры'
Kcheckaddress regex -а@МАТСН
Л[0-9]+<@(aol|msn)\.com|[0-9][Л<]*<вjuno\.com)\.?
’#####* Имена, которые не допускаются в строке "То:”’
С{RejectToLocalparts}	friend you
C{RejectToDomains)	public.com
LOCAL_RULESETS
НТО: $>CheckTo
SCheckTo
RS=(RejectToLocalparts)03* Slerror S: "553 Header error"
R$*fi$=(RejectToDomains) Sterror Sr "553 Header error"
HMessage-Id: $>CheckMessageId
scheckMessageld
r< s+ e $+> $e ok
RS*	Slerror S: "553 Header error"
LOCAL_RULESETS
SLocal_check_mail
'# проверка адресов на соответствие различным регулярным выражениям'
R5*	$: $>ParseO S>3 51
RS+	$: ${checkaddress $1 $)
RgMATCH	$#error S: "553 Header error"
Макрос LOCAL_CONFIG, расположенный в конце файла, определяет
правила проверки заголовков на предмет наличия в них сведений о различных
вирусах и известных спамерах. Мы не будет комментировать данный
фрагмент, поскольку привели его для тех, кто хорошо знаком с файлом
конфигурации и сможет адаптировать его для своего узла.
В конфигурационных файлах машин-клиентов не осуществляется кон-
троль спама, так как вся поступающая на узел почта проходит через
концентратор, где и происходит фильтрация. Некоторые средства и конст-
рукции в этом примере не описаны нами в книге. Необходимую информацию
можно найти в файле cf/README.
626
Чость II Робото в сетях
Доменный файл generic.m4, на который имеется ссылка в файле
katroo.mc — это файл, включенный в дистрибутив sendmail в качестве
примера. Он содержит следующие записи:
divert(-1)
'######## Файл generic.т4 из каталога domain’
divert(0)
VERSIONID(’$Id: generic.m4, v В.15 1999/04/04 00:51:09 ca Exp S’)
detine (’ confFORWARD_PATH1, ' St/. forward.Sw<-$h:$z/ . forward^Sh:
$z/.forward.Sw:$z/.forward’)
define('confMAX_HEADERS LENGTH 1, ’32168’)
FEATURE('redirect)
FEATURE(1use_cw_file‘)
EXPOSED_USER('root11
Строка, где определяется опция confFORWARD_PATH, была разбита нами
на две части, так как не умещалась на странице.
Еще один пример модели с главным почтовым сервером
XOR Inc. — это средняя по величине компания, в которой имеется один
главный почтовый сервер. В общих чертах применяющаяся здесь архитектура
почтовой системы напоминает ту. что используется на узле sendmail.com. но
реализована она при помощи других конфигурационных средств.
Клиентский файл конфигурации имеет следующий вид:
divert(-1)
##### Файл xor-client.тс; все клиенты пересылают
I#### свои сообщения узлу xor.com.
divert(0)
VERSIONID(‘8(#)tcpproto.mc8.5 (Berkeley) 3/23/96’)
OSTYPE(bsdi’J
define(‘confPRIVACYFLAGS’, noexpn‘)
FEATURE('nullclient’, 'xor.com')
Этот файл содержит минимум конфигурационных опций. Даже локальная
почта пересылается на узел xor.com (указан в определении средства null-
client). Никакие агенты доставки также не заданы.
Ниже показан файл конфигурации главного компьютера. Компания XOR
предоставляет услуги Web-хости ига и обслуживает много виртуальных доме-
нов. В первом примере компьютер студента управлял тремя виртуальными
доменами при помощи протокола LDAP и средства genericstable.
Компания XOR управляет почти тысячью виртуальных доменов, пользуясь
средством virtusertable. А средство genericstable в данном случае
применяется для преобразования в исходящей почте регистрационных имен
в форму имя.фамилия. Псевдонимы задаются в стандартном файле aliases,
который состоит их 3000 строк и содержит много списков рассылки.
Некоторые из этих списков включают несколько тысяч получателей, а один —
более 100000. И все это ведется в старой системе SunOS.
Файл псевдонимов следует упорядочить и отделить псевдонимы клиентов
от псевдонимов служащих компании. Псевдонимы служащих указывают на
IMAP-сервер, а клиенты применяют протокол 1МАР для доступа к своей
почте.
Глово 19 Электронная почта
627
Обратите внимание на то, что в начале файла отсутствуют директивы
divert. Они необходимы, только если в начале файла стоят комментарии
в стиле интерпретатора команд (начинаются с символа
На сервере работает программа sendmail версии 8.9.3 и применяются
некоторые старые (до версии 8.10) конструкции. Высокий уровень загружен-
ности потребовал увеличить стандартные значения некоторых опций, связан-
ных с производительностью.
VERSIONID('0(#)хог.тс3.0 (trent) 3/29/99')
OSTYPE('sunos4.1’)
define(‘confPRIVACY_FLAG S', °noexpn,novrfy')
define('confMESSAGE_TIMEOUT', ‘5d/72h’)
define(LOCAL_MAILER_PATH1. '/usr/bin/mail.local')
dnl ##40# увеличиваем значения опций, связанных с производительностью
define(’confMCI_CACHE_SlZE1, '16')
define('confMCI_CACHE TIHEOUT', ‘10m')
define('confCHECK_ALIASKS', 'False')
define(*confDOMAIN_NAME', ‘xor.com1)
define(‘confMAX_MESSAGE_SIZE’, ‘5000000’)
define(‘confDAEMON_OPTIONS' , 'Port’NNN')
define( confQUEUE_LA'. 25)
define I * confREFUSE_LA’ , 30)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(virtusertable)
GENERICS_DOMAIN(‘xor.com')
FEATURE(genericstable)
FEATURE ('masqueradeenvelope ')
FEATURE(‘redirect•)
FEATURE(‘access_db', ‘hash -o /etc/cnail/access ')
MAILER(local)
MAILER(smtp)
LoCAL_RULESETS
♦ #♦### Правила проверки спама и вирусов удалены; см. предыдущий раздел
Из этих примеров видно, что не существует единого рецепта по
составлению конфигурационного файла. В программе sendmail имеется много
конструкций, предназначенных для настройки маршрутизации и изменения
заголовков сообщений. Поэтому конкретный выбор будет зависеть от личных
предпочтений,
19.10. Средства программы sendmail
для борьбы со спамом
Спам — это жаргонное слово, обозначающее “мусорную”, навязчивую
электронную почту коммерческого характера. Спам стал серьезной пробле-
мой, в основном из-за того, что отправитель сообщения (по крайней мере,
в США) платит не за переданное количество байтов, а за факт соединения.
Если же плата взимается за объем трафика, то создается одно сообщение,
адресуемое тысяче получателей, но ретранслируемое через другой компьютер.
При этом пользователь того компьютера платит высокую цену за весь объем
спама, а сам спамер (т.е. отправитель оригинала письма) оплачивает только
628
Чость II Робота в сетях
одну копию. Конечные пользователи во многих странах, естественно, тоже
весьма недовольны тем. что они получают спам и вынуждены оплачивать его
побайтово.
Похоже, проблема спама характерна, а первую очередь, для Соединенных
Штатов. Просто американские маркетологи нашли золотую жилу и продол-
жают ее эксплуатировать.
В США провайдеры стали ощущать влияние спама, когда нх службы
технической поддержки начали сталкиваться со все возрастающим числом
злоупотреблений спамом со стороны своих собственных клиентов. Один
провайдер в Колорадо, имеющий около 150 подчиненных клиентов Т1
(многие из которых сами являются провайдерами), вынужден тратить
половину рабочего времени своих сотрудников на то. чтобы разбираться с
проблемами спама.
С точки зрения маркетологов, спам — очень полезное дело. Эффектив-
ность применения спама высока, плата за его использование, наоборот,
низкая, а доставка — мгновенная. Отправка сообщения по списку, содержа-
щему 30 миллионов электронных адресов, стоит всего около 40 долларов.
Многие спамеры пытаются изображать невинность, помещая в свое
послание ссылку “remove” (удалить), тем самым предлагая получателям
возможность удалить себя из списка рассылки. Казалось бы, все честио, но
отвечая на их письмо, получатель тем самым подтверждает наличие дейст-
вующего электронного адреса. Удалив получателя из одного списка, спамеры
могут тут же внести его в другой список. Спамеры любят также менять
заголовки своих сообщений, пытаясь тем самым замаскировать автора
послания и то, с какого компьютера оно было отправлено.
Люди, которые продают электронные адреса спамерам, недавно начали
применять новый вид “словарной” атаки для поиска неизвестных ранее
адресов. Берется список наиболее часто встречающихся фамилий, и при
помощи программы-сканера к ним добавляются разные инициалы в надежде
случайно образовать действительный адрес электронной почты. Для проверки
адресов программа связывается с почтовыми серверами, скажем, 50-ти
крупных провайдеров и выполняет команду VRFY для каждого из несметного
числа образованных ею адресов.
Такое зондирование подвергает почтовый сервер огромной нагрузке и
отрицательно сказывается на его способности обрабатывать почту реальных
клиентов. Программа sendmail может бороться с этой проблемой, если для
переменной PrivacyOption будет задано значение goaway. Однако умно
написанная программа-сканер поступает следующим образом: если команда
VRFY заблокирована, сканер пытается выполнить команду EXPN, а если
заблокированы обе команды, то будет опробована команда RCPT. В результате
опрашиваются миллионы адресов, и хотя не было послано ни одного
сообщения, почтовый сервер гарантированно окажется загруженным.
В программу sendmail включены достаточно эффективные средства борьбы
со спамом, а также почтовыми вирусами К сожалению, большинство
провайдеров вынуждено сканировать всю почту, в результате чего, опять-таки,
страдают ни в чем не повинные клиенты. Тем не менее на компьютерах
конечных пользователей эти средства оказываются очень полезными.
Существует четыре типа средств, предназначенных для борьбы со спамом.
• Правила управления ретрансляцией, под которой понимается использо-
вание почтового сервера при отправке почтового сообщения одним
сторонним пользователем другому, тоже стороннему. Спамеры часто
прибегают к ретрансляции, пытаясь таким способом замаскировать
Глово 19. Электронной почто
’629
действительного адресата сообщения и тем самым избежать обнаружения
со стороны своих собственных провайдеров.
•	База доступа позволяет фильтровать почту согласно адресам, содержа-
щимся в базе. Это напоминает применение брандмауэра для электронной
почты.
•	“Черные” списки открытых ретрансляторов и известных спамеров
используются программой sendmail для борьбы со спамом.
•	Проверка заголовков — это мощное средство, поддерживаемое в про-
грамме sendmail версии 9. Оно заключается в произвольном сканировании
сообщений с последующим отбрасыванием сообщений, удовлетворяющих
определенным критериям.
Сначала мы опишем перечисленные средства, а затем познакомимся с
реальными примерами спама и покажем, как следует настроить почтовую
систему, чтобы она распознавала и отвергала спам автоматически.
Ретрансляция
Программа sendmail и другие транспортные агенты получают входящую
почту, читают заголовки и адреса конверта, принимают решение о том. куда
следует переслать сообщение, и затем отправляют его в соответствующий
пункт назначения. Им может быть не только локальный получатель, но и
другой транспортный агент, расположенный далее по цепи доставки Когда
входящее сообщение не имеет локального получателя, транспортный агент,
обрабатывающий его, выполняет то, что называется ретрансляцией.
До появления программы sendmail версии 8.9 по умолчанию задавался
режим “беспорядочной” рассылки (известный как открытая ретрансляция).
Программа sendmail принимала любые сообщения через порт 25 и пыталась
осуществить доставку самым оптимальным способом. В те времена считалось,
что Internet — это дружественная среда.
К сожалению, ретрансляцией начали злоупотреблять спамеры. Они
использовали ее для своей маскировки и, что более сушестпенно, для
перекладывания нагрузки (в том числе финансовой) на другие компьютеры.
Поэтому конфигурирование почтового сервера в режиме открытой ретранс-
ляции считается в настоящее время дурным тоном.
Позаботиться следует не только о своей собственной политике ретранс-
ляции: нужно знать, кому вообще можно доверять. В конце концов, любые
сообщения, полученные с серверов открытой пересылки, оказываются
спамом. Пол Викси, пламенный бореи со спамом, и организаторы проекта
ORBS (Open Relay Behavior-modification System — система модификации
поведения серверов открытой ретрансляции) собрали базы данных 1Р-лдресов
тех серверов, где используется открытая ретрансляция. Эти базы данных
можно легко подключить к программе sendmail в виде *’черного" списка, в
соответствии с которым сообщения, поступающие от одного из этих адресов,
будут игнорироваться Создатели проекта ORBS позволяют орган и 1аииям.
устранившим проблему открытой ретрансляции, автоматически \далять себя
из такого списка.
На одном Web-узле подсчитали, что от трети до половины всех почтовых
серверов сконфигурированы в режиме открытой ретрансляции (по состоянию
на весну 2000 года). Статистика ORBS показывает, что количество таких
серверов составляет как минимум 15%.
630
Часть I! Робота в сетях
В программе sendmail начиная с версии 8.9 ретрансляция отключена по
умолчанию Только узлам, помеченным ключевым словом RELAY в базе
доступа, или узлам, перечисленным в файле /etc/mail/relay-domains, разреша-
ется предоставлять почту для ретрансляции. Доля серверов открытой ретранс-
ляции будет снижаться в течение следующих нескольких лет, и произойдет
это вследствие упомянутого выше изменения в программе sendmail, а также
благодаря повышению степени осведомленности публики по этому вопросу
и профилактической деятельности проекта ORBS
Таким образом, ясно, что “беспорядочная’' ретрансляция — это плохо.
Но ясно и то. что некоторые типы ретрансляции и нужны, и легитимны.
Как определить, какое сообщение необходимо ретранслировать, а какое —
отклонить? Ретрансляция действительно нужна лишь в двух случаях.
•	Когда транспортный агент функционирует в качестве шлюза для узлов,
недоступных никаким другим способом. Это могут быть UUCP-системы,
периодически выключаемые компьютеры (PPP-узлы, персональные ком-
пьютеры, работающие под управлением Windows) и виртуальные узлы.
В данном случае все получатели, которым требуется переслать сообщение,
должны быть расположены внутри того же домена.
•	Когда транспортный агент служит сервером исходящей почты для других
узлов. В этом случае имена и IP-адреса всех узлов-отправителей являются
локальными.
Любые другие случаи ретрансляции, вероятнее всего, свидетельствуют о
плохой конфигурации сервера Настройка в соответствии с первым из
упомянутых вариантов подразумевает отмену протокола UUCP гон и так
почти не используется) и конфигурирование центрального сервера на прием
почты (с использованием протокола POP или IMAP для клиентского доступа).
Второй вариант должен быть всегда допустим, но только для локальных узлов.
Лучше проверять IP-адреса, чем имена компьютеров, так как последние легко
подделать.
В программе sendmail функция ретрансляции отключена по умолчанию,
но с помощью специальных средств ее можно включить либо в полном
объеме, либо в ограниченном и контролируемом режиме. Эти средства
перечислены ниже. Их можно использовать, но мы рекомендуем проявлять
максимум осторожности и не злоупотреблять ими. Средство access db.
рассматриваемое в следующем разделе, — это наиболее безопасный метод
задействования ограниченной ретрансляции.
•	FEATURE! relay_entire_domain‘) — разрешает ретрансляцию для
узлов текущего домена;
•	RELA¥_DOMAIN('домен, . ..’) — добавляет дополнительные домены
к списку ретрансляции;
•	RELAY DOMAIN-FILE (' иыя_файла ’) — то же самое, но список доменов
берется из файла;
•	FEATURE! relay hoscs_only’I — влияет на макрос RELAY_DOMAIN
и средство access_db.
Придется сделать исключение, если с помощью макроконстант
SMART HOST и MAIL_HUB почта направляется на конкретный почтовый
сервер. Этот сервер должен быть настроен на ретрансляцию всей почты,
поступающей от локальных компьютеров:
FEATURE(*relay_entire_domain•)
Глово 19 Электронной почто
631
Организациям, предоставляющим услуги виртуального хостинга, потре-
буется активизировать также макрос RELAY_DOMAINt чтобы ретрансляция
поддерживалась для виртуальных доменов, хотя средство
FEATURE('use_cw_file1)
выполняет, по сути, те же самые действия.
Ниже представлено еще несколько средств, но их использование связано
с существенным риском.
•	FEATURE ('promiscuaus__relay ’) — разрешает “беспорядочную” рет-
рансляцию;
•	FEATURE (’ relay_based__on_MX') — разрешает ретрансляцию для всех
узлов, записи MX которых ссылаются на текущий компьютер;
•	FEATURE ('loose_relay_check’) — разрешает "процентную'' адреса-
цию;
•	FEATURE('relay_Local_fram’) — разрешает ретрансляцию для ло-
кальных адресов, указанных в поле “From" сообщения.
Средство promiscuous_relay позволяет осуществлять пересылку почты
из какого-либо узла на любой другой узел. Активизируя это средство, вы
неминуемо попадете в черные списки Пола В икс и. Не пользуйтесь этим
средством.
Средство relay_based_on_MX опасно по той причине, что не позволяет
контролировать, какие узлы ссылаются в своих записях MX на данный
компьютер. Обычно соответствующие записи MX имеют только локальные
компьютеры, но ничего не мешает другим узлам поменять установки своего
сервера DNS. Спамеры обычно не могут менять записи MX, но организации
с сомнительной репутацией вольны в своем выборе.
Средство loose_relay_check разрешает применять “процентный” тип
адресации, которым спамеры с удовольствием пользуются.
Средство relay_local_f г от заставляет программу sendmail доверять
адресу отправителя, указанному в конверте сообщения, и осуществлять
ретрансляцию тех сообщений, которые якобы поступают от локальных
адресов. Естественно, и конверт, и заголовки почтовых сообщений подделать
легко, а спамеры — специалисты в области подделки.
Планируя использовать ретрансляцию, не поленитесь сначала обратиться
к документации на программу sendmail (файл cf/README), чтобы нечаянно
не стать лучшим другом спамеров. Активизировав функцию ретрансляции,
проверьте, не включен ли случайно режим открытой пересылки. Для этого
следует обратиться на узел ordb.org или abuse.net.
При неправильной конфигурации компьютер может осуществлять
ретрансляцию сообщений со странными адресами, основанными на искаже-
нии синтаксиса адресации UUCP. Чтобы предупредить появление такой
“дыры”, отключите протокол UUCP (а также BITNET и DECnet):
FEATURE('nouucp', ’reject’)
undefine('UUCP^RELAY)
undefine(’BITNET_RELAY' )
undefine(’DECNET_RELAY *)
Лучше всего разместить эти строки в доменном файле.
Еще один тип ретрансляции, который часто определяется в доменном
файле, задается макроконстантой LUSER_RELAY. Этот тип предназначен для
локальных пользователей, которые на самом деле не существуют. Узел, на
632
Чость II. Робота в сетях
котором работает неправильно сконфигурированная программа sendmail,
иногда допускает “утечку" сообщений с не полностью определенными
именами локальных пользователей (обычна содержатся в поле “Сс”). Тот.
кто попытается ответить на такое сообщение, на самом деле укажет в качестве
адресата мнимого, несуществующего локального пользователя. Такая почта
направляется агенту доставки error:
define{’LUSER_RELAY', 'error:No such user')
База доступа
Программа sendmail поддерживает базу доступа, которую можно исполь-
зовать для создания на узле почтового брандмауэра. Он будет проверять почту,
приходящую из внешнего мира, и отбраковывать те сообщения, которые
поступают от определенных пользователей или доменов. База доступа может
также хранить имена доменов, для которых разрешается осуществлять
ретрансляцию.
База доступа подключается следующим образом:
FEATURE (" access_di>', ‘ тип нмя_файпа ’)
Если параметры тип и имя_файла не указаны, то по умолчанию
принимается тип hash и файл /etc/mail/access. Как обычно, база доступа
создается с помощью команды makemap.
I	hash /atc/mail/access < /etc/inall/ассевв
Поле ключа может содержать адрес электронной почты, имя пользователя,
имя домена или сетевой адрес. Например:
cyberspammer.com
okguy@cyberspamnier.com
badguy@aol.com
sendmail.org
128.32
170.201.180.16
hoclivesex@
friend@
550 Spam not accepted
OK
REJECT
RELAY
RELAY
REJECT
550 Spam not accepted
550 You are not my friend!
В поле значения должен находиться один из элементов, представленных
в табл. 19.14.
Таблица 19.14. Элементы, которые могут присутствовоть в поле значения
Значение	Что означает
ОК	Прием и доставка почты в обычном режиме
RELAY	Прием почты и пересылка ее получателю
REJECT	Отклонение почты с выдачей типового сообщения об ошибке
DISCARD	Удаление почты без выдачи соответствующего уведомления
ххх сообще- ние	Выдача сообщения об ошибке; вместо ххх должен стоять числовой код, определенный в документе RFC8211
ERROR:ххх сообщение	То же. что и предыдущее, но сообщение об ошибке помечается более явно
ERROR:х.х.х сообщение	Вместо х.хл должен стоять один из кодов состояния доставки, определенных в документе RFC 1893
550 — код единичной ошибки.
Глова 19. Электронной почта
633
Показанная выше база доступа пропускает сообщения от пользователя
okguy узла cyberspammer.com, но отклоняет все остальные сообщения из
данного узла, выдавая сообщение об ошибке. Почта, приходящая из домена
sendmail.org или сети 128.32.0.0/16 (сеть Калифорнийского университета в
Беркли), будет ретранслироваться. Почта от пользователя badguy узла aol.com,
а также почта, приходящая от пользователей hollivesex и friend любых доменов,
будет отклоняться.
В поле ключа могут стоять адреса IPv6 с разделителями в виде двоеточий.
Символ @ после имен hollivesex и friend нужен для того, чтобы отличать
имена пользователей от имен доменов.
Код 550 задан в документе RFC821. Кодов состояния доставки, опреде-
ленных в документе RFC 1893, гораздо больше. Первая цифра 4 означает
временную ошибку, цифра 5 — постоянную ошибку. Несколько кодов
приведено в табл. 19.15,
Тоблицо 19.15. Коды состояния доставки (документ RFC 1893)			
Временная ошибка	Постоянная ошибка	Значение	j
4.2.1	5.2.1	Почтовый ящик недоступен	
4.2.2	5.2.2	Почтовый ящик переполнен	
4.2.3	5.2.3	Сообщение слишком велико	
4.2.4	5.2.4	Проблема с раскрытием списка рассылки	
4.3.1	5.3.1	Почтовая система переполнена	
4.4.4	5.4.4	Маршрутизация невозможна	
4.4.5	5.4.5	Перегрузка почтовой системы	
Поле ключа может содержать теги Connect, То и From, позволяющие
задавать более точные критерии фильтрации. Тег Connect содержит ин-
формацию о соединении, например адрес или имя клиента. Теги То и From
ссылаются на адреса конверта, а не заголовков. С помощью данных тегов
можно переопределять другие установки.
При наличии любого из этих тегов поиск сначала производится по
условию, заданному тегом, а затем — обычным способом, что необходимо
для поддержания обратной совместимости с более старыми базами доступа.
Вот несколько примеров:
F г от: spamine г @ some. domain	REJECT
То:friend.domain	RELAY
Connect:friend.domain	OK
Из этого примера видно, что почта, приходящая от имени spam-
mer@some.domain, будет заблокирована, но по данному адресу все равно
можно будет посылать почту, даже если он помещен в "черный” список.
Разрешается ретранслировать почту, посылаемую по адресу friend.doniain, но
это не относится к сообщениям, поступающим от данного адреса (предпо-
лагается. что ретрансляция запрещена где-то в другом месте). Соединение с
узлом friend.domain допускается, даже если этот адрес помешен в один из
“черных" списков DNS.
Базы доступа используются многими организациями с целью контроля
над спамом. Наш сервер входящей почты на факультете вычислительной
634
Чость II. Робото в сетях
техники университета Колорадо отклоняет почту от более чем 500 известных
спамеров, определяемых по именам, доменам или IP-адресам.
Занесение пользователей или узлов в 'черные' списки
Если необходимо блокировать почту каких-либо локальных пользователей
или узлов, воспользуйтесь средством
FEATURE('blacklist_recipi ents *)
которому в базе доступа соответствуют следующие записи:
nobodyG	550	Mailbox disabled for this	user
printer.mydoiuain.edu	550	This host does not accept	mail
userGhosL.mydomain.edu	550	Mailbox disabled for this	user
Эти записи блокируют почту, приходящую на адрес пользователя nobody
на любом узле, а также почту, адресованную сетевому принтеру и одному из
пользователей.
С помощью средства dnsbl можно подключить “черные” списки,
которые ведет Пол Викси в своем проекте MAPS (Mail Abuse Prevention
System — система предотвращения почтовых злоупотреблений; обратитесь на
Web-узел mail-abuse.org), а также любые DNS-списки блокируемых адресов'
FEATURE(‘dnsbl’)
Это средство заставляет программу sendmail отклонять почту, приходящую
с того узла. IP-адрес которого имеется в списке Realtime Blackhole List. В
него занесены адреса спамеров, известных проекту MAPS В других списках
указаны спамеры, работающие по коммутируемым линиям, и узлы, поддер-
живающие открытую ретрансляцию.
“Черные" списки распространяются через службу DNS. Например,
специальная DNS-запись
1Р-алрес.гЫ.maps, vix.com in а 127.0.0.2
введенная в базу данных DNS домена rbl.maps.vix.com. блокирует почту от
указанного узла, если средство dnsbl включено (программа sendmail явно
проверяет, существует ли такая запись) В данном примере IP-адрес — это
сетевой адрес в обратной точечной нотации.
О DNS рассказывается в главе 16.
Средство dnsbl можно активизировать всякий раз. когда необходимо
проверить тот или иной список злоумышленников. Достаточно добавить
второй аргумент. задающий сервер имен для "черного” списка, и третий
аргумент, содержащий требуемое сообщение об ошибке. Если третий аргумент
опушен, будет выдано фиксированное сообщение (из базы данных DNS,
содержащей проверяемые записи) Ниже даны примеры трех списков: гЫ
t стандартный), dul — список спамеров, работающих по коммутируемым
гиниям. и гss — список узлов, поддерживающих открытую ретрансляцию.
EATURE (* dsnbl ‘ , 'rhl.iuaps.vix.com', "Rejected - see
www.mall-abuse.org/rbl/’)
FEATURE('dsnbl', dul.maps.vix.com', ‘Dialup - see
www.mail-abuse.org/dul/’)
FEATURE(‘dnsbl1, 'relays.mail-abuse.org', ‘Relay - see
www.mail-abuse.org/rss/’)
Глово 19 Электронное почто
635
Проверка заголовков
Проверка заголовков — мощный механизм борьбы со спамом, в основе
которого лежит использование синтаксиса низкоуровневого файла конфигу-
рации программы sendmail; мы ие рассматриваем этот файл в данном издании
книги. Выполняя проверку заголовков, программа sendmail сверяет их с
имеющимися образцами (например, “То: friend@public.cora”) и отклоняет
подозрительные сообщения до того, как они будут доставлены в пользова-
тельские почтовые ящики.
Проверка заголовков может также применяться для распознавания
почтовых вирусов при условии, что они имеют характерную строку заголовка.
Например, вирус Melissa (1999 г.) содержал тематическую строку вида
“Important Message From...”. В пределах нескольких часов, пока вирус Melissa
распространялся, на узле sendmail.com был опубликован локальный набор
правил по идентификации вируса и отбрасыванию содержащих его сообще-
ний То же самое происходит в отношении других почтовых вирусов: как
только выясняются отличительные особенности вируса и появляется возмож-
ность выразить их в виде правил программы sendmail, быстро публикуются
исправления к почтовой системе (как иа V/eb-узле scndmail.com, так и на
узле www.sendmail.org).
Характерный образец правил фильтрации, предназначенных для борьбы
со спамом и вирусами, можно найти в файле конфигурации программы
sendmail для домашнего компьютера Эрика Оллмана (knecht). Эта конфигу-
рация включена в дистрибутив sendmail (файл cf/c(/knecht.mc) Позаимствуйте
из иее правила фильтрации спама и добавьте их в конец своего тс-файла.
Разбирая различные примеры, мы встречали следующие правила проверки
заголовков:
•	почта, адресованная любому пользователю в домене public.com;
•	почта, адресованная пользователям “friend” или “you”;
•	почта, имеющая заголовок X-Spanska, который указывает иа наличие
вируса-червя Нарру99;
•	почта с тематической строкой  Important Message From,..” (вирус Melissa);
• почта с тематической строкой “all.net и Fred Cohen...” (вирус Papa);
•	почта с тематической строкой “ILOVEYOU” (вирус “iloveyou” и его
варианты);
•	почта от узлов aol.com и insn.com с числовыми именами пользователей;
•	почта от узла juno.com с именами пользователей, начинающимися с
цифры.
Все правила проверки заголовков задаются макросами LOCAL_CONFIG и
LOCAL_RULESETSt расположенными в конце me-файла. С помощью команды
divert препроцессора п>4 программа sendmail размещает эти правила в
нужном месте низкоуровневого файла конфигурации.
В ответ на получение спама вызывайте агент доставки error (с сооб-
щением об ошибке “user unknown"), а не discard. Многие спамеры
“подчищают” свои списки рассылки, оставляя только коммерчески ценные
адреса, поэтому можно легко удалить себя из списка, записав в него
сообщение об ошибке.
636
Чость II. Роботе в сетях
Обработка спама
Борьба со спамом может оказаться трудным и часто безрезультатным
занятием. Не нужно тратить усилия на поимку отдельных спамеров. Время,
затраченное на анализ заголовков спама и прочие переживания, — это
потерянное время. Да, это благородная борьба, но объем поступающего спама
она вряд ли уменьшит.
Постоянных спамеров можно нейтрализовать довольно быстро, вычислив
их провайдера. Однако спамеры, работающие по принципу “напакостил и
удрал", используют учетную запись иа узле провайдера только один раз, после
чего избавляются от нее. Их поймать трудно. Если о»™ рекламируют свой
Web-узел, то ответственность можно возложить на него. Если же они
объявляют номер телефона или почтовый адрес, то идентифицировать
отправителя спама будет тяжело, но вполне возможно. Впрочем, многие из
таких ''мобильных’’ спамеров могут оказаться вообще недосягаемыми для
наказания.
Всевозможные "черные” списки в некоторой степени эффективны для
блокировки спама и приводят к уменьшению числа серверов, поддерживаю-
щих открытую ретрансляцию. Быть помещенным в такой список — значит
подорвать свою деловую репутацию, поэтому многие провайдеры и органи-
зации внимательно следят за действиями своих пользователей. Наш главный
совет, касающийся спама, таков: регулярно проводите профилактические
мероприятия н публикуйте имеющиеся “черные” списки.
Посоветуйте своим пользователям просто удалять полученный ими спам.
Многие сообщения содержат инструкции о том, как получатели могут удалить
себя из списка рассылки. Не попадайтесь на эту уловку. Если последовать
таким инструкции, то спамеры действительно могут удалить получателя из
текущего списка, но при этом они немедленно внесут его в несколько других
списков, причем сопроводят адрес аннотацией типа “Вот реальный клиент,
который действительно читает наши сообщения". После этого, как вы
понимаете, ценность данного электронного адреса еще больше возрастет.
Если вам все же нравится вести борьбу со спамом, воспользуйтесь
помощью, предлагаемой соответствующими Web-узлами. В первую очередь
следует упомянуть узлы mail-abuse.org и abuse.net. На узле www.spamrecycle.com
вас попросят направить им образец спама; они перешлют его федеральным
властям, которые могут предпринять какие-то законодательные меры. Этот
Web-узел также публикует правила зашиты от спама. Узел производит анализ
спама и использует результаты анализа для усовершенствования спам-фильт-
ров. Три других Web-узла. заслуживающих внимания, — это ordb.org,
spamcop.net и w4w.cauce.0rg. На первом из них содержатся наиболее полные
базы данных серверов, поддерживающих открытую ретрансляцию. На втором
предлагаются средства анализа заголовков почтовых сообщений и определе-
ния действительного отправителя. На третьем приведена хорошая информация
о законах, касающихся спама.
Примеры сламо
Хотя мы не рекомендуем читателям заниматься анализом спама, иногда
все же полезно знать, как это делается. Например, вас могут вызвать для
объяснений в связи с тем, что генеральный директор компании получил
сообщение порнографического характера (необходимо доказать, что оно не
поступило от кого-то из служащих компании).
Глово 19. Электронной почто
637
Приведенные ниже примеры иллюстрируют, насколько тяжело определить
действительного отправителя и насколько легко подделать заголовки сооб-
щений. Сначала перечислим несколько ключевых моментов.
•	Заголовки “Received” образуют последовательную цепочку, начиная от
верхней части сообщения и заканчивая его нижней частью.
•	Любые заголовки “Received”, расположенные ниже заголовка “Dale”. —
поддельные.
•	Обращайте внимание на любой заголовок "Received”, в котором имена
двух узлов не совпадают Вероятно, почтовое сообщение было ретранс-
лировано через первый узел (узел, имя которого заключено в круглые
скобки, является действительным источником сообщения).
•	Заголовок “Received”, имеющий старую дату, вероятнее всего, подделан.
•	Сетевая часть заголовка “From” должна согласоваться с последним
заголовком “Received”.
•	Домен заголовка "Message-Id” должен совпадать с доменом заголовка
“ From”.
•	Проверьте, нет ли в заюловках “Received” признаков того, что сообщение
ретранслировано через посторонний узел.
•	Убедитесь, что все перечисленные узлы действительно существуют в базе
данных DNS.
В качестве первого примера возьмем сообщение, авторы которого
предлагают будущим спамерам купить компакт-диск, содержащий 10000000
электронных адресов. Этот компакт-диск представляет определенный интерес:
гарантируется, что он не содержит дублирующиеся адреса, а также “отрав-
ленные” адреса (вероятно, те. где отправитель автоматически заносится в
один из “черных” списков).
С целью упрощения комментариев мы пронумеровали строки заголовков.
Сами номера в письме отсутствуют.
1:	From mrktnet77@kayak.msk.ru Thu Nov 4 22:10:48 1999
2:	Received: from qaia.es ([195.55.166.66]} by xor.com (8.9.3/8.9.3)
with ESMTP io WAA26343 for <evi@xor.cem>; Thu, 4 Nov 1999 22:10:42
-0700 (MST)
3:	From: mrktnet77@kayak.msk.ru
4:	Recervea: from default by qaia.es (8.8.8+Sun/SMI-SVR4) id GAA03907;
Fri, 5 Nov 1999 06:31:10 -0100 (Etc/GMT)
5:	Date: Fri, 5 Nov 1999 06:31:10 -0100 (Etc/GMT)
6:	Received: from loqin_011556.wqukas.com (mail.wqukas.com
[233.214.241.07]) by (8 8.5/8.7.3) with SMTP id XAA01510 for
fraklin321@thaxqhklo.um.de; Thu, 4 November 1999 00:21:59 -0700
(EDT)
7:	To: mrktnet77@kayak.msk.ru
8:	Subject: Just Released! Millions CD Vol. 6A
9:	Comments: Authenticated Sender is <userll556@wqukas.com>
10:Messaqe-Id: 02202108722648597456@sa_qhklo.um.de
/* Несколько страниц маркетинговой информации */
Do not reply to this message -
To be removed from future mailings:
ma i1to:qreg114 8 @usa.ne t?Subject=Remove
638
Чость II Роботе в сетях
Строка I была добавлена программой /bin/mail в процессе локальной
доставки. Домен msk.ru существует, а узел kayak.msk.ru — нет. Строка 2
содержит достоверный ?аголовок ’‘Received". Это единственная заголовок
"Received", которому можно доверять, поскольку он добавлен на нашем
собственном узле xor.com Строка 3 — это заголовок “From", добавленный
программой sendmail где-то “в пути”, поскольку оригинал сообщения не имел
его.
Строка 4 содержит достоверный заголовок “Received4 от ничего не
подозревающего узла gaia.es. сыгравшего роль козла отпущения. На этом узле
выполняется программа sendmail 8.8. которая по умолчанию поддерживает
ретрансляцию (в такой конфигурации ее поставляет компания Sun). Стро-
ка 6 — это поддельный заголовок “Received” Он находится ниже заголовка
"Date”, следовательно, был создан до того, как первый экземпляр программы
sendmail получил сообщение. Кроме того, формат заголовка неверен, а адрес
23.1214.241.87 не имеет обратной записи в DNS.
Строка 7 (заголовок “То”) также поддельная. Адреса получателей были
только на конверте
Строка 9. по идее, идентифицирует истинного отправителя, что иногда
является ключом к разгадке источника сообщения. В данном случае
подразумевается, что сообщение отправлено из домена wgukas.com, но такого
домена не существует. Эта строка в действительности была добавлена
пользовательским почтовым агентом на персональном компьютере и. следо-
вательно. может быть поддельной.
Строка 10 говорит о том, что компьютер, отправивший сообщение, имеет
адрес sa _gliklo.iim.de. но у этой строки неправильный формат (отсутствуют
угловые скобки), значит, она тоже поддельная.
Невозможно сказать, откуда пришло это сообщение. Оно было ретранс-
лировано через узел gaia.es. очевидно без разрешения. Этот узел еще не попал
в “черный" список сервера mail-abuse.org, но может вскоре там оказаться.
Пользователь greg!148, возможно, действительно является спамером, но
может быть и обычным пользователем, имевшим неосторожность пожало-
ваться на полученный спам. Во втором случае пользователя gregl!48 следует
рассматривать как жертву, так как в скором будущем он получит сотни, а
то и тысячи сердитых посланий от пользователей с требованием удалить их
из списка рассылки.
Тело сообщения призывает получателей летать заказ по телефону или
факсу. Типичный случай: вся информация, касающаяся того, как связаться
со спамером и купить предлагаемый им продукт, приведена в теле сообщения.
Заметьте, что адрес в заголовке “From” такой же, как и в заголовке “То”.
Вероятно, оба они поддельные.
В другом сообщении, полученном нами через неделю, нам предлагали
разбогатеть, для чего требовалось послать по факсу чек на 40 долларов до
15 ноября, так как после этой даты цена на товар подскочит до 195 долларов.
Возникает вопрос: являются ли факсимильные копии чека законным
платежным средством? Или. может быть, злоумышленникам нужно лишь
получить номер нашего текущего счета в банке и нашу подпись, чтобы потом
самим напечатать фальшивые чеки? О таких предпожениях следует сразу же
сообщать н полицию.
1:	From ju.mdelnoGapexrnaxl.com Thu Nov 11 10:31:41 1999
2:	Received: from saturn.globalcon.com (sacurn.globalcon,com
[209.5.99.8]) by xor.com (8.9.3/8.9.3} with ESMTP id KAA15479;
Thu, 11 Nov 1999 10:31:30 -0700 (MST)
noBti 9 Электронной почто
639
3:	Received: from Hamilton ([168.191.61.20]) bysaturn.globalcon.com
(Post.Office MTA v3.1.2 release (PO205-101C) ID# 0-35881U1500L100S01
with SMTP id AAA148; Thu, 11 Nov 1999 12:33:24 -0500
4:	Date; Thu, 11 Nov 1999 02:39:57 +0000
5:	Subject: Free Information On "Debt Reduction 1"
6; Message-Id: <yjsul.Inmggaasnjymgqaac@hamilton>
7: From; F.Pepper@pmail.net
8: To: benfranklin@onehundred.net
Строка 2 содержит достоверный заголовок “Received”. Строка 3 также
правдоподобна, но команда traceroute, выполненная из домена xor.com на
узлы hamilton (168.191.61.20) и satum.globalcon.com (209.5.99.8), показала, что
эти два узла не имеют никакого отношения друг к другу. Адрес 168.191.61.20
находится в коммутируемой сети Sprint, причем где-то в Европе, судя по
формату отображения времени. Адрес 209.5.99.8 принадлежит канадской
компании, находящейся в Онтарио. Очевидно, сервер saturn.globalcon.coni
поддерживает открытую ретрансляцию. На нем работает не программа
sendmail, а транспортный агент Post.Office версии 3.1.2 (его можно получить
на узле www.openwave.com).
В строке 4, добавленной пользовательским агентом отправителя, гово-
рится о том, что текущее время — примерно 2 часа ночи. Лишь через
несколько часов это сообщение было принято компьютером на узле
saturn.globalcon.com. Возможно, список получателей был слишком длинным,
поэтому процесс пересылки занял так много времени. Или, что вероятнее,
сообщение было составлено заранее на персональном компьютере спамера и
только потом, спустя пару часов, было отправлено в Internet. Судя по формату
отображения времени (если только это не подделка), разница составляет 5
часовых поясов — это как раз разница между часовыми поясами Европы и
восточного побережья США.
В строке 6 сетевая часть заголовка “Message-Id” должна быть полностью
определенным именем домена, а не локальным именем “hamilton”. Узел
hamilton, возможно, неправильно сконфигурирован, поскольку неполное имя
появляется также в строке 3. Часть заголовка “Message-Id" слева от символа
'(§>' обычно состоит из цифр, но в данном случае она содержит наугад взятые
буквы. Это указывает на то, что строка может быть поддельной.
Строка 8 явно подделана. Действительный адрес получателя присутствует
только на конверте сообщения и больше нигде в заголовках.
Это сообщение действительно могло быть получено от пользователя
F.Pepper@pmail.net. Доменному имени pmail.net соответствует реальный
IP-адрес, а программа whois сообщает о том, что узел pmail.net принадлежит
компании British telecom Среди примерно двадцати экземпляров спам-сооб-
щений, которые мы проверили при подготовке данного раздела, только это
сообщение содержит достаточно информации для того, чтобы можно было
составить обоснованную жалобу (в адрес компьютера hostmaster, который
указан в базе данных DNS для IP-адреса, приведенного в строке 3 заголовка).
Никогда не нужно посылать жалобу непосредственно спамеру или в домен
спамера.
SpamCop — это программа, выполняющая синтаксический анализ
заголовков почтовых сообщений и определяющая, какие строки реальные,
какие — могут быть подделаны, а какие — безусловно подделаны. Программа
выдает пользователю, который присылает пример спама по электронной почте
или на Web-узел spamcop.net, пошаговое описание заголовков и разъясняет,
какие компоненты подтверждаются, а какие — нет. На этом узле можно
640
Чость II. Робото в сетях
легко составить жалобу на спам. В жалобу следует включить всю относящуюся
к делу информацию, которая была собрана путем синтаксического анализа
заголовков.
Мы запустили программу SpamCop для анализа нашего первого спам-
сообшения, в котором нам пытались продать компакт-диск со списком
адресов. Программа обнаружила, что заголовок “Received” с адресом gaia.es
подлинный, но домен wgukas.com — фиктивный. Затем программа опреде-
лила, что узел gaia.es ие имеет IP-адреса, о котором говорится в письме, и
что действительный виновник, возможно, находится на узле nd.net. Ясно,
что анализ с помошью программы SpamCop оказался намного лучше, чем
наш, и занял он всего несколько секунд.
Ниже приведен небольшой фрагмент из результатов анализа относительно
свежего спама. Анализ выполнен программой SpamCop.
Received: from sunl.cskwam.mil.pl (cskwam.mil.pl) [148.81.119.2] by
maill.es.net with smtp (Exim 1.81 fr2) id 12oBHL-000494-00; Sat,
6 May 2000 13:34:23 -0700
Possible spammer: 143.81.119.2
"nslookup cskwam.mll.pl" (checking ip) [show] ip not found;
cskwam.mil.pl discarded as fake.
"dig cskwarn.mil.pl mx" (digging for Mail exchanger) [show] "nslookup
cskwam.rail.pl" (checking ip) [show] cskwam.mil.pl not 148.81.119.2,
discarded as fake.
"nslookup sunl.cskwam.mil.pl" (checking ip) [show] ip •= 148.81.119.2
Taking name from IP...
"nslookup 148.81.119.2" (getting name) [show] 148.81.119.2 -
sunl.cskwara.mil.pl
"nslookup sunl.cskwam.mil.pl" (checking ip) [show] ip =* 148-81.119.2
"nslookup 2.119.81,148.rbl.maps,vix.com." (checking ip) [show]
not found
"nslookup 2.119.81.148.relays.orbs.org." (checking ip) [show] ip =
127.0.0.2
blocked by ORBS
Chain testimaill.es.net »? raaill.es.net
Chain verified maiil.es.net ~ maill.es.net
148.81.119.2 has already been sent to ORBS
Received line accepted
Каждое слово [show] является ссылкой на Web-страницу программы
SpamCop. Там показана команда, которая была выполнена, и ее результат.
19.11. Безопасность и программа sendmail
С началом взрывоподобного роста сети Internet программы наподобие
sendmail, принимающие произвольные входные данные и направляющие их
локальным пользователям, в файлы или в интерпретаторы команд, стали
излюбленной мишенью для хакеров. В настоящее время программа sendmail,
наряду со службой DNS и даже протоколом IP. начала обзаводиться
встроенными средствами аутентификации и шифрования, позволяющими
решать основные проблемы безопасности.
Недавнее послабление американских федеральных законов, касающихся
экспорта систем шифрования, позволило оснастить программу sendmail
собственными механизмами шифрования. Версии 8.11 и более поздние
поддерживают систему SMTP-аугентификаиии и SSL (Secure Sockets Layer —
протокол защищенных сокетов). Протокол SSL в sendmail называется TLS
(Transport Layer Security — безопасность транспортного уровня) и реализован
Глово 19. Электронной почто
641
в виде дополнения STARTTLS к протоколу SMTP. Ему соответствуют шесть
новых конфигурационных параметров, связанных с файлами сертификатов и
ключей.
В этом параграфе мы рассмотрим эволюцию модели безопасности
программы sendmail. В конце кратко описан протокол SASL.
Безопасность программы sendmail постоянно усиливалась, и теперь
программа, прежде чем довериться содержимому, скажем, файлов .forward
или aliases, тщательно проверяет права доступа к ним. Как правило, подобные
меры предосторожности действительно необходимы, но иногда все же
требуется их ослабить. С этой целью в программе появилась опция
DontBlameSendmail. название которой (“не обвиняй sendmail’") подсказы-
вает системным администраторам, что после изменения опции все действия
программы станут небезопасными.
У опции DontBlameSendmail много возможных значений. По умолча-
нию она равна safe. Полный список значений можно найти в файле
sendmail/сопГ.с.
Владельцы файлов
Программа sendmail разл!тчает трех специальных пользователей: Defaul-
tuser, TrustedUser и RunAsUser. По умолчанию все агенты доставки
работают от имени пользователя Defaultuser, если не заданы специальные
флаги. При наличии в файле /etc/passwd записи “niailnull” или “sendmail"
именно эта запись будет соответствовать пользователю Defaultuser. В про-
тивном случае пользователю будут сопоставлены значения UID и GID,
равные I, что эквивалентно учетной записи “daemon’". Мы рекомендуем
применять учетную запись “mailnull" Добавьте ее в файл /etc/passwd со
звездочкой в поле пароля, с пустым полем идентификатора команд, с пустым
полем начального каталога и группой “nogroup". Этой учетной записи не
должны принадлежать никакие файлы.
Пользователь TrustedUser может владеть файлами баз данных и
псевдонимов. Ему разрешается запускать демон и перестраивать файл aliases.
Этот пользователь не соответствует классу TRUSTED USERS программы
sendmail, который определяет, кто имеет право менять заголовок “From”
сообщений*.
Пользователю RunAsUser соответствует значение UID. которое присваи-
вается программе sendmail при открытии сокета, подключенного к порту 25.
Привилегированные порты, номера которых меньше 1024, могут открываться
только суперпользователем, следовательно, программа sendmail первоначально
работает от имени пользователя root. Тем не менее после завершения
указанной операции программа может взять себе другое значение UID Это
уменьшает вероятность возможных угроз безопасности, если программа
sendmail запускается обманным путем.
По умолчанию, однако, программа продолжает выполняться от имени
пользователя root. Если потребуется поменять установку для учетной записи
RunAsUser, придется многое изменить. Пользователю RunAsUser принад-
лежит очередь почтовых сообщений, он может читать все включаемые фа илы
и файлы баз данных, осуществлять запись в журнальные файлы, запускать
Средство TRUSTED_USERS обычно применяется для поддержки программ, работающих со
списками рассылки. Например, если используется программа Majordomo, нужно добавл гь
пользователя “majordom” в класс trusted_USERS. По умолчанию членами этого класса
являются стандартные пользователи daemon и root.
642
Чость II Робота в сетях
программы и т.д. Может уйти несколько часов на поиск всех файлов и
каталогов, владелец которых должен быть изменен.
Права доступа
С точки зрения безопасности программы sendmail важное значение имеют
права доступа к определенным файлам и каталогам. Установки, приведенные
в табл. 19.16, считаются безопасными.
Таблица 19.16. Атрибуты каталогов программы sendmoil			
Каталог	Владелец	Режим	Назночение/содержимое
/var/spool/mqueue	RunAsUser	700	Очередь почтовых сообщений
/, /var. /var/spool	root	755	Компоненты путевого имени каталога mqueuc
/etc/mail/*	TrustedUser	644	Таблицы, конфигурационный файл, файлы псевдонимов
/etc/mail	TrustedUser	755	Родительский каталог для разных файлов
/etc	root	755	Путь к каталогу mail
Программа sendmail не будет читать файлы с ослабленными правами
доступа (например, файлы, доступные для записи группе или остальным
пользователям, а также файлы, находящиеся в каталогах. которые доступны
для записи группе или остальным пользователям) Такая предосторожность
вызвана тем, что многие операционные системы позволяют пользователям
отдавать свои файлы в “чужие руки’’ с помощью команды chown (в основном
это относится к системам, производным от System V)*.
В частности, программа sendmail очень тщательно проверяет полное
путевое имя любого файла псевдонимов и файла .forward. Это сказывается
на управлении списками рассылки программы Majordomo. Если список
рассылки находится, например, в каталоге /usr/local, все путевое имя должно
быть надежным; ни один компонент его пе должен иметь право записи для
группы. Это усложняет владельцу' списка работу с файлом псевдонимов
Чтобы проверить текущее положение дел, запустите команду
# sendmail -v -fax
Флаг -bi заставляет программу пронниииализировать базу данных псев-
донимов и выдать предупреждение, если права доступа не подходят.
Программа sendmail не читает файл .forward. если значение счетчика
ссылок на него превышает единицу, а путь к каталогу небезопасен (права
доступа ослаблены).
Отключить многие ограничения на доступ к файлам можно с помощью
опции DontBlarneSendmail.
За годы своего существования команда chown вызвала массу проблем, связанных с безопас-
ностью. Мы считаем ее ошибкой разработчиков. Отключите данную команду, если это
разрешено в операционной системе.
Глово 19 Электронная почто
643
Безопасная пересылка почты в файлы и программы
Мы рекомендуем применять в качестве агента программной доставки
утилиту smrsh, а не /bin/sh, и назначить агентом локальной доставки утилиту
mail.local, а не /bin/тай. О них рассказывалось в параграфе 19.8. Обе
программы входят в дистрибутив sendmail. Для их активизации необходимо
добавить в тс-файл команды
FEATURE (' smrsh', * путь_кпрограше~ smrsh ’)
FEATURE(‘local_lmtp *, 'путъ_к_программе_та±1.local')
Если путевые имена не указаны, по умолчанию принимаются следующие
установки: /usr/libexec/smrsh и /usr/libexec/mail.local.
По умолчанию программа smrsh запускает только программы, находя-
щиеся в каталоге /usr/adm/sm.bin*. Она игнорирует заданные пользователями
путевые имена и пытается искать запрашиваемые команды в собственном
каталоге. Она также блокирует некоторые метасимволы интерпретатора
команд, в частности ’<’ — оператор переадресации входного потока. В ката-
логе sm.bin допускается наличие символических ссылок, поэтому создавать
копии программ не потребуется.
Приведем несколько примеров команд вместе с возможными интерпре-
тациями программы smrsh-
vacation eric	выполняется /usr/adm/sni.bin/vacation eric
cat /atc/paaawd	отклоняется, программы cat нет в каталоге
sm.bin
vacation eric < /etc/passwd отклоняется, оператор < не разрешен
Опция SafeFileEnvironment программы sendmail контролирует, куда
можно записывать сообщения, если в файле aliases или .forward задано
перенаправление почты в файл. Эта опция заставляет программу выполнить
системный вызов chroot, вследствие чего корневым каталогом файловой
системы станет не /, a /safe или любой другой заданный в опции каталог.
Например, если в файле псевдонимов задается перенаправление почты в файл
/etc/passwd, то на самом деле сообщения будут записываться в файл
/safe/etc/passwd.
Опция SafeFileEnvironment защищает файлы устройств, каталоги и
другие специальные файлы, позволяя записывать почту только в обычные
файлы. Это полезно не только в плане улучшения безопасности, но и с точки
зрения борьбы с пользовательскими ошибками. В некоторых системах
значение этой опции задают равным /home, что открывает доступ к начальным
каталогам пользователей, но оставляет системные файлы вне досягаемости.
Агенты доставки тоже могут запускаться в среде с измененным корневым
каталогом. В настоящий момент соответствующая опция содержится в настрой-
ках агента, но в скором времени "перекочует” в файл конфигурации т4.
Опции конфиденциальности
В программе sendmail имеются опции конфиденциальности, которые
определяют:
	какие сведения о системе можно узнать из внешнего мира при помоши
протокола SMTP;
Не помешайте в каталог sm.bin программы наподобие procmail, которые способны запускать
интерпретатор команд. Лучше назначьте программу procmail локальным агентом доставки.
644
Чость II Роботе в сетях
•	что требуется от узла на противоположном конце SMTP-соединения;
•	могут ли пользователи просматривать или обрабатывать очередь почтовых
сообщений.
В табл. 19-17 приведены текущие значения опций конфиденциальности.
Самая актуальная информация содержится в каталоге /sendmall/conf.c дист-
рибутива.
Тоблицо 19.17. Зночения переменной Privacyoptions
Значение	И нтериретация
public	Проверка конфиденциальности/безопасности не производится
needmailhelo	Требуется SMTP-команда HELO (идентифицирует удаленный узел)
поехрп	Не допускается SMTP-команда EXPN
novrfy	Нс допускается SMTP-команда VRFY
needexpnhelo	Не допускается раскрытие адреса (команда EXPN) без команды HELO '
needvrfyhelo	Не допускается проверка адреса (команда VRFY) без команды HELO
noverb1	Не допускается “многословный” режим команды EXPN
restriccmailg	Только пользователи группы, которой принадлежит каталог mqueue, могут просматривать очередь сообщений
rescrictqrun	Только владелец каталога mqueue может обрабатывать очередь сообщений
noetrn2	Не допускается асинхронная обработка очереди
authwarnings	К сообщениям добавляется заголовок “Authentication-Warning" (это установка по умолчанию)
noreceipts	Запрещает выдачу кодов состояния доставки
nobodyrecurn	При выдаче кода состояния доставки не возвращается тело сообщения
goaway	Отменяются все статусные SMTP-запросы (EXPN, VRFY и тл.)
1	В этом режиме команда EXPN отслеживает переадресацию в файле .forward и
позволяет получить дополнительную информацию о местонахождении пользователь-
ской почты. Необходимо включать опцию noverb или, еще лучше, поехрп на
любом компьютере, имеющем выход во внешний мир.
2	ETRN — это команда протокола ESMTP, которая используется узлами с коммути-
руемым доступом. Оиа запрашивает обработку очереди только для сообщений
данного узла.
Мы рекомендуем сделать в mc-файле "консервативные” установки
define ГconfPRIVACY_OPTIONS', * goaway, authwarnings, restrictmarlc,
restrictqrun*')
По умолчанию установлена лишь опция authwarnings. Обратите
внимание на удвоенные кавычки: некоторые версии препроцессора гп4
требуют этого для предотвращения интерпретации запятых в списке значений
Запуск программь sendmail при помощи камандь chroot
Те, кто беспокоится о влиянии программы sendmail на файловую систему,
могут запускать ее с помощью команды chroot в специальном корневом
каталоге вроде /jail (“тюрьма”). Создайте в этом каталоге минимальную
Гпово 19 Электронной почто
.45
файловую систему, включив в нее файл /dev/null, важные файлы каталога
/etc (passwd, group, resolv.conf. sendmail.cf, таблицы баз данных, mail/*),
необходимые программе sendmail совместно используемые библиотеки, дво-
ичные файлы sendmail. каталог очереди почтовых сообщений и требуемые
журнальные файлы.
Команда для запуска программы sendmail будет выглядеть так:
й chroot /jai.1 /ивг/sbin/sendmall -bd -q30m
Отражение атак типа * отказ от обслуживания'
Атаки типа “'отказ от обслуживания" невозможно предотвратить. потому
что нельзя заранее предсказать, является ли сообщение оружием атак» или
действительным компонентом почты Злоумышленники могул поступать
по-разному, например переполнять SMTP-порт ложными запросами на
подключение, забивать разделы диска гигантскими сообщениями, засорять
выходные соединения, бомбардировать систему почтовыми сообщениями
В программе sendmail имеются конфигурационные параметры, позволяющие
ограничить воздействие этих атак на систему, но в результате может
пострадать и легитимная почта.
Опция MaxDaemonChildren ограничивает число процессов sendmail. Она
не позволяет npoi-рамме sendmail захватить все вычислительные ресурсы
системы, но зато дает возможность хакерам очень легко ‘’завалить" сервис
SMTP. Опция MaxMessagelJi *е защищает каталог очереди от переполнения,
ио если задать значение опции слишком низким, ’’жертвами” могут оказаться
обычные сообщения. Нужно уведомить пользователей о существующем
ограничении на размер сообщения, чтобы они не удивлялись. если письмо
вдруг вернется обратно. Размер сообщения обычно может быть достаточно
большим
Оппия ConnectionRat«Throttle задает предельно допустимое число
соединении в секунду. Она может привести к небольшому замедлению работы
программы sendmail Наконец, опция MaxBcpcsPerMessage задает макси-
мальное число получателей сообщения
Несмотря иа все меры предосторожности, трудно предусмотреть ситуа
шло, когда кто-то начинает бомбардировать систему письмами. Это очень
неприятная проблема.
В университете штата Колорадо для каждого студента (всего их 25000)
создается почтовая учетная запись, а стандартным почтовым клиентом
является программа pine. Один студент устроился на работу в местный
компьютерный магазин, и хозяин попросил студента предоставить ему копию
файла паролей. Затем компания разослала рекламное сообщение всем
пользователям, упомянутым в файле паролей, пакетами по 1000 получателей
за раз В результате строка “То" получилась очень длинной
Программа pine была скомпилирована так. чтобы отвечать не только
Отправителю, но и всем получателям. Многие студенты ответили на рекламу
письмами с вопросами вроде "Зачем вы прислали мне эту чушь?’’, и,
естественно, письма оказались разосланы всем, кто был упомянут в строке
“То". В результате сервер был полностью выведен из строя. Он не мог
обрабатывать не только почту, но и любые другие запросы. Программа
sendmail захватила все ресурсы процессора, очередь почтовых сообщений стала
огромной, и все выполняемые задания зависли Пришлось отключать
компьютеры от сети, а затем заходить в почтовый буфер каждого пользователя
и вручную удалять сообщения.
646
Чость II Робото в сетях
Фальсификации
Подделать почту раньше было, что называется, “раз плюнуть”. В про-
грамму sendmail версии 8.10 входят средства SMTP-аутентификации, позво-
ляющие проверять подлинность машины-отправителя. До версии 8.10 любой
пользователь мог подделать сообщение так, как если бы оно поступило из
вашего собственного домена. И даже в версии 8.10 проверку все еще нужно
включать отдельно, с помощью опции AuthMechanisms.
В почтовых сообщениях можно представиться любым человеком. Будьте
осторожны, если электронная почта является средством аутентификации для
таких вещей, как ключи шифрования, карточки доступа н электронные
деньги. Необходимо предупредить об этом пользователей и потребовать, чтобы
в случае появления подозрительной почты якобы от уполномоченного лица
они проверяли достоверность таких сообщений. Это вдвойне необходимо,
если в сообщении содержится требование предоставить неоправданные льготы
какому-то липу, не имеющему к ним никакого отношения. Например, очень
подозрительно, если письмо содержит просьбу выдать студенту ключ шиф-
рования.
При установленной опции authwarnings программа sendmail добавляет
заголовок ‘‘Authentication-Warning” к любому исходящему сообщению, кото-
рое выглядит подделанным. Тем не менее многие пользовательские почтовые
агенты по умолчанию скрывают этот заголовок.
Если фальшивая почта поступает с компьютера, находящегося под вашим
административным контролем, можно попытаться отловить нарушителя.
Демон identd позволяет узнать реальное регистрационное имя отправителя
письма Программа sendmail посылает обратный запрос к машине-отпрааи-
телю, чтобы работающий там демон ideBtd сообщил ей имя пользователя,
пославшего почту. Если демон иа удаленной машине не работает, то ничего
выяснить не удастся. Если удаленный компьютер является однопользователь-
ской рабочей станцией, то ее владелец может настроить демон identd так,
чтобы тот возвращал заведомо неправильный ответ. Если же удаленный
компьютер — это большая многопользовательская система (такая, к примеру,
как во многих университетских вычислительных центрах), то демон identd
возвращает реальное регистрационное имя пользователя, которое программа
sendmail включает в заголовок сообщения.
Во многих организациях демон identd не работает с внешним миром: он
блокируется брандмауэром. Применять демон имеет смысл только внутри
организации, так как компьютерам, находящимся под посторонним админи-
стративным контролем, нельзя доверять.
Несколько лет назад, когда мы впервые начали экспериментировать с
демоном identd, один студент решил подшутить над своими коллегами по
курсовому проекту. Он посылал им письма от имени руководителя проекта,
в которых говорил, что они плохо выполняют свою работу и должны работать
лучше. К сожалению, однажды он допустил синтаксическую ошибку, и
письмо вернулось руководителю. Программа sendmail благодаря протоколу
IDENT сама сообщила нам имя нарушителя, включив в сообщение такую
строку:
The original message was received at Wed, 9 Mar 1994 14:51 -0700 from
CTKHewrCbenji.Colorado.EDU [128.138.126.10]
А в заголовке было сказано нечто иное:
From: руководительбcs.Colorado.EDU
Глово 19. Электронной почто
647
Мораль: занимаясь хакерством, хотя бы не допускайте синтаксических
ошибок! В соответствии с нашими правилами, учетная запись студента была
отключена до конца семестра, чего, наверное, он и сам хотел. Он не
справлялся с курсовым проектом, и его коллегам приходилось часто
выполнять работу за него.
Безопасность сообщений
Истинную безопасность электронной почты невозможно соблюсти, если
не применять внешнюю систему шифрования, например TLS. По умолчанию
вся почта посылается в незашифрованном виде. Сообщите пользователям о
том, что они сами должны выполнять шифрование, если хотят обеспечить
конфиденциальность своих сообщений.
В настоящее время делаются попытки внедрить в протокол SMTP средства
аутентификации и шифрования, хотя раньше такая деятельность тормозилась
федеральными законами США, касающимися ограничений на экспорт систем
шифрования. Для двустороннего шифрования требуется поддержка не только
со стороны программы sendmail, но и со стороны пользовательских почтовых
агентов.
Две другие системы, позволяющие повысить конфиденциальность сооб-
щений, — это S/MIME и PGP. Обе они описаны в документах RFC. Мы
предпочитаем РСР. так как эта программа широко доступна и написана
великолепным шифровальщиком Филом Циммерманом (Phil Zimmermann),
которому мы доверяем.
Информацию о программе PGP можно найти в параграфе 21.8.
SASL: простой протокол защиты и аутентификации
Программа sendmail версии 8.10 (н более поздних версий) поддерживает
систему SMTP-аутентификации, определенную в документе RFC2554. Она
основана на протоколе SASL (Simple Authentication and Security Layer).
SASL — это базовый механизм аутентификации, который может быть
встроен в ряд других протоколов. Пока что его используют программа sendmail
и демон imapd компании Cyrus. В протоколе SASL реализованы две основные
концепции: идентификатор авторизации и идентификатор аутентификации
Эти идентификаторы могут быть связаны с правами доступа к файлам,
паролями UNIX, билетами Kerberos и т.д. Библиотека функций SASL состоит
из двух частей: модуля аутентификации и модуля шифрования. В связи с
федеральными ограничениями на экспорт систем шифрования, программа
sendmail версии 8.10 использует только модуль аутентификации. В начале
2000 г. ограничения были ослаблены, поэтому модуль шифрования, который
изначально планировалось включить в коммерческую версию sendmail. стал
общедоступен в версии 8.11.
Библиотеку Cyrus SASL можно найти по следующему адресу:
ftp://ftp.andrew.cnju.edit/pub/cynis-niail
Инструкции по инсталляции и настройке библиотеки сложноваты для
понимания, поэтому мы советуем посетить Web-страницу Клауса Ассмана
(Claus Assmann), посвященную использованию SASL в программе sendmail:
http://www.sendmarLorg/~ca/emaiJ/auth.html
Новый модуль шифрования описан в документе RFC2487 и реализован
в программе sendmail в виде дополнения STARTTLS к протоколу SMTP
o4t
Чость II. Работа в сетях
Протокол TLS аналогичен протоколу SSL, используемому многими Web-уз-
лами.
19.12. Статистика, тестирование и отладка
Программа sendmail может собирать статистические данные о количестве
и размере сообщений, которые она обрабатывает. Эти данные группируются
по агентам доставки и отображаются командой mailstats. Опция
conf STATUS_FILE в файле каталога ostype программы sendmail задает имя
файла, в котором должны сохраняться статистические данные. Если этот
файл существует, автоматически включается функция сбора учетной инфор-
мации.
По умолчанию файл статистики находится в каталоге /etc/mail/statistics,
но некоторые поставщики перемещают его в каталог /var/log/sendmail.st или
/usr/Iib/sendmail.st. Данные накапливаются в файле с момента его создания.
Поэтому, если необходима статистическая информация за определенный
период времени, следует соответствующим образом пронниимализировать этот
файл из демона сгоп.
О повторном использовании журнальных файлов рассказывается в параг-
рафе 1 /. /
Ниже приведен образец статистических данных. Чтобы пример помес-
тился на странице, мы удалили первую (там указаны номера агентов доставки)
и последнюю (удаленные сообщения — она оказалась пустой) колонки.
Statistics from Wed Nov 17 00:56:30 1999
msgsfr	bytes_from	msgsto	bytes_to	msgsrej	Mailer
0	OK	2015	5314K	0	prog
0	OK	2	4K	0	•file*
5399	37455K	20	20K	18	local
42449	383837K	72885	450631K	4207	esmtp
47846	421292K	74922	455969K	4225	
Показано пять значений: число полученных сообщений и их суммарный
объем (msgsfr, byces_f rom), число отправленных сообщений и нх суммар-
ный объем (msgsto. bytes_to). число отклоненных сообщений (msgsrej).
Эти значения относятся как к локальной, так и к ретранслируемой почте.
Тестировоние и отлодка
Конфигурация, основанная на применении препроцессора т4, в какой-то
степени тестируется автоматически. Низкоуровневая отладка в основном ие
требуется. Единственное, что невозможно контролировать при помощи флагов
отладки, — это смысловые ошибки. В процессе подготовки этой главы мы
обнаружили несколько подобного рода ошибок в конфигурационных файлах.
Иногда, к примеру, вызывалось средство без сопутствующего ему макроса
(в частности, активизировалось средство masquerade_envelope, но не
включался режим маскирования с помощью макроса MASQUERADE_AS). Или
конфигурация программы sendmail не соответствовала настройкам брандмау-
эра, который определял, какую почту разрешается пропускать.
Нельзя проектировать почтовую систему саму по себе. Ее необходимо
согласовать с имеющимися DNS-записями NS и настройками брандмауэра.
Глово 19, Электронноя почта
649
Комплект отладочных средств программы sendmail — один из богатейших
в UNIX-смете мах. Отладочные флаги представляют собой не просто булевы
значения и даже нс целые числа, а двухмерные величины хл1. где л определяет
тему, a j- - объем выдаваемой информации. Если у равно 0. то это означает
отсутствие отладки, а значение 127 соответствует максимально подробному
отчету Темы могут иметь номера от 0 до 99 (в настоя шее время определено
68 тем).
В файле sendmail/TRACEFLAGS дистрибутива содержится список поддер-
живаемых значений, а также перечень файлов и функций, в которых они
используются. Вся поддержка отладочных флагов реализована в низкоуров-
невом файле конфигурации
Если программа sendmail вызывается с флагом -dx.r. то отладочная
информация поступает на дкран (стандартный поток ошибок) Некоторые
важные значения \ и рекомендуемые Эриком О шманом значения у приведены
в табл. 19.18.
Таблица 19.18 Порометры от лодки
Номер-темы Описание и предлагаемые значения у
0	Отображение флагов компиляции, а также информации об опера-
ционной системе (испробуйте значения у. ранные I или 10)
8	Выдача информации о преобразовании имен в DNS (попробуйте
значение у, равное 7)
11	Трассировка процесса доставки (отображаются вызовы агентов дос-
тавки )
12	Выдача информации о преобразован им локальных имен в удаленные
17	Выдача списка записей MX
21	Трассировка правил подстановки (попробуйте значения г, равные 2
или 12)
27	Огобрижение данных о псевдонимах и перенаправлениях (попробуйте
значение у. равное 4)
44	Отображение сведений о неудачных попытках открытия файлов
(попробуйте значение у. равное 4)
60	Выдача информации о поиске и базах данных
Джин Ким (Gene Kim) п Роб Кочстад (Rob Kolsiad) написали Perl-cue-
нарии checksendniail. который вызывает программу sendmail в режиме проверки
адресов, передавая ей файл тестовых адресов (предоставляется пользователем).
Этот сценарии сравнивает полученные результаты с ожидаемыми. Он
позволяет построить тестовым набор типичных адресов и впоследствии
проверять новые версии конфигурационных файлов па предмет того, нс
нарушилась ли случайно работоспособность программы.
Сценарий checknendmail можно получить на Web-узле www.hurker.com.
Достовко с комментариями
Многие пользовательские агенты вызывают программу sendmail с фла-
гом -v. чтобы опа выдавала информацию обо всех действиях, выполняемых
в процессе дос ганки сообщения.
650
Чость II Робото в сетях
Следующий пример подучен с помощью почтового агента /usr/ucb/niail.
Текст, набранный полужирным шрифтом, вводится пользователем; осталь-
ное — результаты работы программы sendmail
anchor 53% mail -v evigxor.com
Subject: just testing, please ignore
hi
Cc:
evi0xor.com... Connecting to xor.com via esmtp..
220 xor.com ESMTP Sendmail 8.9.3/8.9.3; Fri, 2b Nov 1999 17:42:57
-0700 (MST)
>» EHLO anchor.cs.colorado.edu
250-xor.com Hello anchor.cs.Co_orado.EDU [128.138.242.11, pleased to
meet you
250-8B1TMIHE
250-SLZE 5000000
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
»> MAIL From: <eviganchor.es .Colorado .edu> SIZE^-oT
250 <evi@anchor.cs.Colorado.edu>... Sender ok
>» RCPT To :<evi@xor .co!r.>
250 'evig.xor.coni> . . Recipient ok
»> DATA
354 Enter mail, end rfith on a line by itself
250 RAA00511 Message accepted for delivery
evi0xor.com... Sent (RAA0051 Message accepted for delivery)
Closing connection to xor.com.
>» QUIT
221 xor.com closing connection
Программа sendmail на компьютере anchor связалась с программой sendmail
на узле xorcom. Оба компьютера в процессе обмена сообщениями общались
по протоколу FSM ГР
Обмен данными по протоколу SMTP
В процессе отладки почтовой системы можно непосредственно выполнять
команды протокола SMTP Для запуска SMTP-сеанса свяжитесь с помощью
программы telnet с ГСР-портом 25. На этом порте пршрамма sendmail работает
на прием в режиме демона <-bd). Некоторые SMTP-команды приведены в
табл. 19.19.
В протоколе SMTP всего 14 команд, поэтому он прост в изучении и
применении. Регистр символов здесь не различается. Полная спецификация
протокола изложена в документе RFC821 (см. также RFC1123). В документах
RFC 1869, 1870, 1891 и 1985 описано расширение SMTP — протокол ESMTP.
Большинство транспорт!гых агентов, включая sendmail. понимает и SMTP,
и ESMTP. Исключение составляет лишь программа sniap. В протоколе ESMTP
диалог начинается командой EHLO, а не HELO. Если в ответ на эту команду
противоположная сторона возвращает ОК. то участники диалога обменива-
ются информацией о поддерживаемых расширениях и приходят к наимень-
шему общему знаменателю Если же возвращается сообщение об ошибке,
осуществляется переход к протоколу SMTP.
Глово 19 Электронной почто
551
Таблица 19.19. Команды протокола SMTP
Команда	Функция
HELO имя_компъютера	Идентифицирует компьютер, устанавливающий соеди- нение по протоколу SMTP
EHLO имякомпьютера	Идентифицирует компьютер, устанавливающий соеди- нение по протоколу ESMTP
MAIL From: обратный_путъ	Инициирует почтовую операцию (отправитель конверта)
RCPT То: прямой_нуть1	Идентифицирует получателей конверта
VRFY адрес	Проверяет действительность адреса (т.е. можно ли по нему доставить почту)
EXPN адрес	Раскрывает псевдонимы и соответствия, заданные в файле .forward
DATA	Начинает тело сообщения2
QUIT	Завершает обмен и закрывает соединение
RSET	Сбрасывает состояние соединения
HELP	Выводит список SMTP-команд
1 Для одного сообщения может быть несколько команд RCPT
2 Тело завершается при вводе строки, состоящей из одной точки
Регистрация событий
Для выдачи сообщений об ошибках и своем состоянии программа sendmail
пользуется услугами системы Syslog. Сообщения регистрируются от имени
средства “mail” на уровнях от "debug” до “crit”. Есе сообщения помечаются
строкой "sendmail”.
Подробнее о системе Syslog рассказывается в главе 11.
Опция confLOG_LEVEL, заданная в командной строке или в файле
конфигурации, определяет уровень серьезности, который программа sendmail
будет использовать как пороговый уровень регистрации. Высокие пороговые
значения соответствуют низким уровням серьезности и обеспечивают реги-
страцию большего объема информации.
Вспомните, что сообщения, регистрируемые в системе Syslog иа опреде-
ленном уровне, передаются также на все вышестоящие уровни. В файле
/etc/syslog.conf определяется, куда, в конце концов, попадет каждое сообще-
ние. В табл. 19.20 показано приблизительное соответствие между уровнями
регистрации в программе sendmail и уровнями серьезности Syslog.
Таблица 19.20. Соотношение между пороговыми уровнями sendmail
и уровнями серьезности Syslog
По ог	Уровни	 				
0 1	Без рсгистрапии “alert’’ или "crit”
2 3 4 5-10 >=11	"crit” “егг" или "warning” “notice” “info” “debug”
652
Часть II. Работе в сетях
19.13.	Почтовая система Postfix
Проект Postfix начался б научно-исследовательском центре компании IBM
T.J,Watson Research Center с легкой руки Витса Венема, Postfix является
альтернативой программе sendmail. характеризуясь такими качествами, как
надежность, простота администрирования и (есть надежда) безопасность.
Postfix — прямой конкурент программы qmail, разработанной Дэном Берн-
стайном (Dan Bernstein). Целями создания системы Postfix были политика
открытого распространения, высокая производительность, надежность, гиб-
кость и безопасность.
Вероятно, наиболее важным в системе Postfix является то, что она
функционирует практически автономно (простейший файл конфигурации
содержит всего одну или две строки). Кроме того, с целью эффективной
фильтрации почты используются регулярные выражения, синтаксис которых
основан на библиотеке PCRE (Perl Compatible Regular Expression). Это очень
мошное средство, но усложненные регулярные выражения напоминают
синтаксис низкоуровневого файла конфигурации программы sendmail. Сис-
тема Postfix совместима с программой sendmail в том смысле, что файлы
aliases и .forward системы Postfix имеют тот же формат и ту же семантику,
что и аналогичные файлы программы sendmail.
Система Postfix понимает протокол ESMTP и имеет ограниченную
поддержку протокола UUCP. Поддерживаются также виртуальные домены и
средства фильтрация спама. Postfix не имеет собственных средств переписы-
вания адресов, в отличие от программы sendmail Вместо этого используется
табличный поиск в обычных файлах, библиотеках DB и dbm. а также службах
LDAP, NIS и Netlnfo.
Архитектура системы Postfix
Система Postfix состоит из нескольких небольших, взаимодействующих
друт с другом процессов, каждый из которых осуществляет свою функцию;
отправляет сообщения в сеть, принимает сообщения, доставляет почту по
локальным адресам и т.д. Взаимодействие между процессами осуществляется
через UbJIX-сокеты или через очереди. Такая архитектура существенно
отличается от архитектуры программы sendmail, в которой один большой
процесс выполняет все операции.
Система Postfix использует четыре разные очереди для осуществления
почтовых операций:
•	Maildrop —• сюда пользовательский агент помешает исходящие сообщения:
•	Incoming — для входящей почты;
•	Active — резидентная очередь сообщений, находящихся в процессе
доставки;
•	Deferred — почта, доставка которой была отложена.
Менеджер очередей перемещает сообщения между очередями. При этом
используется алгоритм кругового обслуживания, заключающийся в баланси-
ровке очередей Incoming и Deferred и принятии решения относительно того,
какое сообщение в данный момент попадет в очередь Active. Сообщения в
очереди Active перед началом обработки сортируются по пунктам назначения,
так что. если несколько сообщений имеют обшего получателя, они могут
быть переданы через одно ТСР-соединение.
Глово 19. Электронной почта
653
Чтобы не перегружать узел, принимающий сообщения, система Postfix
использует алгоритм медленного старта для контроля того, как быстро
доставляется почта. Отложенные сообщения получают отметку о времени
повторной попытки доставки, причем интервал между попытками экспонен-
циально увеличивается, чтобы ресурсы системы не тратились на сообщения,
которые, возможно, не удастся доставить. Наличие кэша недоступных-
адресатов позволяет избежать ненужных попыток доставки сообщений (это
аналогично опции HOST_STATUS_DIRECTORY программы sendmail)
Безопасность контролируется на нескольких уровнях. Большинство де-
монов системы Postfix может запускаться в среде с измененным корневым
каталогом. Демоны — это отдельные программы, не имеющие отношений
типа предок/потомок. Ни один из них не имеет установленного бита SUID.
Память для строк и буферов выделяется динамически; длинные строки
предварительно разбиваются на части, а затем снова объединяются Разбивка
необходима, чтобы ие возникало переполнение буфера. Очередь Mail drop
доступна для записи (ио не для чтения) всем пользователям, поэтому система
Postfix не нуждается в помощи доверенных пользовательских агентов.
Наличие каталога, открытого для записи, дает определенные шансы
хакерам, но система Postfix предотвращает большинство связанных с этим
проблем, используя специальный формат файлов, находящихся в очереди.
Система не пытается обрабатывать неправильные файлы Если у программы
postdrop будет установлен бит SGID, каталог очереди Maildrop окажется
доступен для записи только группе. Такая возможность была добавлена под
давлением Дэна Бернстайна, активно отстаивавшего свою точгку зрения в
списке рассылки “bugtraq".
Центральными частями системы Postfix являются главный демон, запус-
кающий остальных демонов, и файл masler.cf, содержащий управляющие
настройки и ограничения. Стандартные установки файла master.cf Приемлемы
для любых ситуаций, кроме очень медленных или очень быстрых компьютеров
или сетей. Особой необходимости в модификации этого файла нет. Другой
файл конфигурации, main.cf. содержит параметры маршрутизации и фильт-
рации сообщения. Файл main.cf немного напоминает файл scndmail.cf; файл
master.cf не имеет аналога в программе sendmail, так как последняя состоит
из единичного демона.
Ниже перечислен ряд утилит командной строки, которые позволяют
пользователям взаимодействовать с почтовой системой:
•	postfix — запускает и останавливает почтовую систему (должна выпол-
няться от имени пользователя root):
•	postalias — эквивалент команды newaliases;
•	postcat — отображает содержимое файлов, находящихся в очереди;
•	postconf — отображает и редактирует содержимое файла main.cf:
•	postdrop — добавляет сообщения в очередь Maildrop,
•	postkick, postlock, posllog — вызываются нз командных сценариев,
выполняя функции блокировки и журнальной регистрации,
«	postmap — строит таблицы базы данных (аналогична команде makemap);
•	postsuрсг — управляет очередями (вызывается при запуске системы)
Конфигурирование системы Postfix
В файле mail.cf можно задавать около сотни параметров. Большинство
из них имеет логичные установки по умолчанию Язык конфигурирования
654
Часть II Роботе в сетях
немного напоминает последовательность операторов присваивания интерпре-
татора Boume shell. В приведенных ниже примерах мы иногда сопровождаем
операторы комментариями, в которых указывается эквивалентная конструк-
ция программы sendmail. Эти комментарии расположены в конце строк
конфигурации и не являются частью операторов.
Для начала определим несколько переменных, которые понадобятся
позднее. Переменная myhostname содержит имя компьютера Если оно ие
является полностью определенным, дополните его вручную:
my ho s t name = имя.jtxx.ууу
Переменная ту domain содержит имя родительского домена для пере-
менной myhostname; система Postfix вычисляет его путем удаления имени
компьютера. Если результат получился неправильным, задайте домен само-
стоятельно:
mydomain = локальная часть.домен
Обе переменные, myhostname и mydomain. могут задавать виртуальные
домены.
Переменная mynetworks содержит список всех сетей, к которым
подключен компьютер, включая интерфейс обратной связи. Например:
mynetworks = 128.138.243.64/26, 127.0.0.0/8
Система Postfix понимает сетевые адреса в CIDR-нотации. Переменная
inet_in ter faces определяет интерфейсы, прослушиваемые системой Post-
fix (по умолчанию это все активные интерфейсы). Необходимо изменить
стандартное значение дайной переменной, если используются виртуальные
домены.
В случае самой простой конфигурации требуется сконфигурировать
только три переменные: myorigin, mydestination и notifyclasses.
Переменная myorigin определяет, какой домен будет использоваться
для исходящей почты. Она задается следующим образом:
myorigin - Smyhostname
myorigin = Smydomain # напоминает маскирование в программе sendmail
Переменная mydestination определяет домены, для которых будет
приниматься входящая почта. Она аналогична средству use_cw_file про-
граммы sendmail и может содержать список имен компьютеров, имя домена,
имя файла или спецификацию табличного поиска. Например:
mydestination = Smyhostname localhost.Smydomain
mydestination = Smyhostname localhost.Smydomain Smydomain
mydestination = /etc/mail/local-host-names
Переменная notify classes определяет, о каких проблемах следует
ставить в известность почтового администратора (пользователь postmaster)
По умолчанию устанавливаются такие параметры:
notifyclasses = resource, software
В данном случае регистрируются только ошибки, касающиеся проблем с
ресурсами и проблем программного обеспечения Postfix. В табл. 19.21
показаны возможные классы.
Глово 19. Электронной почто
655
Таблица 19.21. Возможные значения переменной notify_clasees
Класс Тип ошибок
bounce Недоставленные сообщения (только заголовок)
2bounce Двойной отказ (сообщение об отказе тоже не может быть доставлено)
delay Сообщение задержано в очереди (только заголовок)
policy	Отказ от спама (включает SMTP-расшифровку)
protocol	Ошибки протокола (включает SMTP-расшифровку)
resource Проблемы с ресурсами (например, сбой при записи в очередь,
переполнение файловой системы)
software Внутренние ошибки Postfix____________________________________
Postfix имеет опции управления ресурсами, которые используются поч-
товой системой также для регуляции трафика,
Система Postfix имеет ограниченные возможности перезаписи адресов.
Н ап ример, она может
•	преобразовывать регистрационные имена в адреса формата имя.фамилия',
•	запрещать направленную маршрутизацию;
•	преобразовывать UUCP-адреса в доменный формат;
•	запрещать “процентные" адреса;
е добавлять к адресам локальные домены для получения полностью
определенных имен.
Маскирование адресов тоже поддерживается, но не в столь многих
формах, как в программе sendmail. Соответствие виртуальным адресам ищется
путем табличного поиска, подобно программе sesdniBil. Переадресация
осуществляется с помощью специальной таблицы (переменная relo-
cated_maps). Поддерживаются файлы aliases и .forward такого же формата,
как и в sendmail. Имеется даже аналог средства loser_relay для обработки
сообщений типа “user unknown”.
Ретрансляция отключена по умолчанию, но начальное поведение системы
немного отличается от такового в программе sendmail. Последняя по
умолчанию вообще не выполняет ретрансляцию, тогда как система Postfix
осуществляет ретрансляцию почты для локальных доменов, подчиненных
доменов и сетей класса А, В или С.
Борьбо со сломом
Для фильтрации спама система Postfix применяет регулярные выражения,
таблицы баз данных и '‘черные” списки проекта MAPS. В табл. 19.22
представлены некоторые переменные Postfix, имеющие отношение к спаму.
Если для сообщения найдено соответствие в таблице поиска н запись
таблицы содержит значение REJECT, то сообщение отклоняется н выдается
соответствующее уведомление об ошибке. Если среди наших читателей есть
Perl-хакеры, приведем для них пример регулярного выражения, используемого
в спам-фильтрах одного Web-узла:
/''friend@. *5/	550 Stick this in your pipe SO
Если в домене действительно имеется пользователь friend, можно
исключить его из проверки:
/~fгiend@(?Imysite.com)."S/ 550 Stick this in your pipe $0
656
Чооь II Роботе в сетях
Таблица 19.22. Переменные системы Postfix, связанные с фильтрацией	спомо
Переменная____________________Назначение____________________________
header_checks	Фильтрация заголовков
smtpd_client_restrictions	Фильтрация клиентских	соединений,	“чер-
ных” СПИСКОВ И Т.Д.
smtpd_sender_res trict ions
8mtpd_recipient_restrictiona
smtpd_helo_requ ired
smtpd_helo_restrieCions
emtpd_etrn_restrictionB
Фильтрация адресов отправителей
Фильтрация адресов получателей
Для идентификации имени компьютера требу-
ется SMTP-команда HELO
Требуется обратный DNS-поиск
Содержит список компьютеров, имеющих дос-
туп к очереди
Чтобы подключить “черные” списки проекта MAPS, добавьте в свой
файл main.cf следующие строки:
maps_rbl_domains -
rbl.maps.vix.com
dul.maps.vix.com
relays.mail-abuse.org
smtpd_client_restrictions - reject_maps_rbl
Примеры конфигурирования системы Postfix
Поскольку наш опыт работы с системой Postfix гораздо более скромен,
чем с программой sendmail, мы попросили Витса Венема предоставить нам
примеры. Каталог conf дистрибутива Postfix также содержит ряд примеров.
В среде “почтовый концентратор — клиенты” все системы посылают
почту от имени пользователь@<)о.мен и принимают почт} на имя пользова-
гпель@компыотер. Концентратор принимает почту' на имя пользователь@домен.
На клиентском компьютере файл /etc/postfix/main.cf будет содержать
следующее:
mycrigin - Smydomain
На почтовом концентраторе файл /etc/postfix/main.cf выглядит так:
myorigin - Smydomain
mydestination - Smyhostnarne,localhost.Smydomain,Smydomain
Эту конфигурацию можно модифицировать таким образом, чтобы рабочая
станция не принимала почту из сети, а ретранслировала ее через почтовый
концентратор. Для этого следует изменить как файл main.cf, так и файл
master.cf.
В случае клиента файл /etc/postfix/main.cf будет таким:
myorigin = Smydomain
relayhost - Smydomain
На клиентской системе необходимо также превратить в комментарий
строку вызова SMTP-сервера в файле /etc/postfix/master.cf:
#smtp inet n - n -	- smtpd
Если каталог очереди экспортируется через NFS к клиентам, им будет
нужен только почтовый агент системы Postfix и файлы main.cf и master.cf
нулевой длины
Глово 19. Электронная почто
657
Ниже показан пример, в котором отдельные компьютеры обрабатывают
как входящую, так и исходящую почту, но сообщения в формате BIT1NET
или UUCP пересылаются на главный компьютер.
Конфигурация почтового концентратора такова:
myorigin =» Smydomain
mydestination = Smyhostname,localhost.Smydomain,Smydomain
transportmaps = hash:/etc/postfix/cransport
Клиенты используют приведенную ниже конфигурацию:
myorigin = Smydomain
transportmaps = hash:/etc/postfix/transport
Как на главном компьютере, так и на компьютерах клиентов файл
/etc/postfix/transport должен содержать следующее:
.bitnet	smtp:master
.uucp	smtp:master
19 14. Рекомендуемая литература
•	Cosiales. Bryan and Eric Allman, sendmail, 2nd Edition Sebastopol, CA:
O’Reilly. 1997.
Данная книга — объемный труд размером в 1000 страниц. Она
представляет собой не только очень полный справочник, но и учебник.
Эту книгу можно читать в режиме случайного просмотра страниц, что,
на наш взгляд, является очень важным достоинством любого справочника.
Имеется также хороший предметный указатель.
•	Avolio, Frederick М. and Paul A. Vtxie. Sendmail Theory and Practice. Digital
Press. 1995.
В этой книге больше рассказывается о том, зачем и как применять
программу sendmail, тогда как книга Косталеса/Оллмана больше посвя-
щена описанию того, что такое sendmail.
•	Clayton, Richard. “Good Practice for Combating Unsolicited Bulk Email.1’
RIPE/Demon Internet. 2000. http://www.ripe.net/ripe/docs/ripe-206.html
Этот ресурс будет полезен провайдерам Internet.
•	Schwartz, Alan and Paula Ferguson. Managing Mailing Lists. O'Reilly, 1998.
Эта книга является хорошим справочником по спискам рассылки.
Аргументы командной строки программы sendmail описаны на посвящен-
ной ей man-странице. Обзор можно найти в книге Эрика Оллмана Sendmail:
An Internetwork Mad Router.
Инструкции по инсталляции и хорошее описание файла конфигурации
приведены в документе Sendmail Installation and Operation Guide, который
находится в каталоге doc/op дистрибутива sendmail. Этот документ довольно
полон и в сочетании с файлом сГ/README дает хорошее представление о
том, что такое sendmail.
В документе RFC822 описан синтаксис сообщений и адресов в сетевой
почтовой системе, а в документе RFC 1123 изложены требования к компью-
терам. В некотором смысле эти документы представляют собой функцио-
нальные спецификации, в соответствии с которыми построена программа
sendmail.
В документе RFC821 описан протокол SMTP, а в документах RFC1869,
1870, 1891 и 1985 — протокол ESMTP.
658
Чость II Робото в сетях
В документе RFC974 описаны записи MX службы DNS и их связь с
механизмом маршрутизации почты.
Среди прочих документов RFC, посвященных электронной почте, укажем
следующие:
•	RFC 1891—1894 — коды состояния доставки;
•	RFC 1985 — удаленная обработка очередей;
•	RFC2033 — протокол LMTP;
•	RFC2034 — коды ошибок SMTP;
•	RFC2045 — расширения MIME;
•	RFC2476 — спецификация агента доставки почты;
•	RFC2487 — безопасный трафик SMTP поверх TLS;
•	RFC2554 — SMTP-аутентификация.
Документацию и информацию о системе Postfix можно найти на Web-узле
www.porcupinc.org.
20
Управление сетями
Поскольку при объединении компьютеров в сеть число связей между
машинами увеличивается, то при этом, как правило, усугубляются все
имевшиеся ранее проблемы. Как говорят, “работа в сети — это когда вы не
можете выполнить свое задание из-за отказа компьютера, о котором никогда
не слышали”.
Управление сетями — это, прежде всего, искусство и наука предотвра-
щения их разрушения. Сюда обычно входят следующие задачи:
•	поиск неисправностей в сетях, шлюзах и важных серверах:
•	разработка схем уведомления администратора о наличии проблем;
•	общий мониторинг сети с целью распределения нагрузки в ней и
планирования ее дальнейшего расширения;
•	документирование и визуализация работы сети;
•	управление сетевыми устройствами с центральной станции.
В отдельной сети Ethernet формальные процедуры управления сетью
внедрять, как правило, не стоит. Достаточно провести тщательное тестиро-
вание сети после ее прокладки и время от времени проверять уровень
нагрузки Сломается — почините.
По мере роста сети npoueavpbi управления должны становиться более
систематизированными. В сети, где несколько подсетей объединяются
посредством мостов или маршрутизаторов, решение управленческих задач
можно автоматизировать с помощью командных сценариев и простейших
программ. Если в организации задействованы протоколы глобальных сетей
или сложные ЛВС. рассмотрите вопрос приобретения выделенных станций
управления сетью со специальным программным обеспечением.
В некоторых случаях усложнение системы управления сетью объясняется
потребностью в обеспечении ее надежности Во многих организациях бывает
так, что возникновение проблемы в сети приводит к остановке абсолютно
660
Чость II Робото 8 сетях
всей деятельности. Если подобные задержки недопустимы, лучше приобрести
и установить высококлассную корпоративную систему управления сетью.
К сожалению, даже самая лучшая система не поможет предупредить все
проблемы. Важно иметь хорошо документированную схему сети и высоко-
квалифицированный обслуживающий персонал, способный справляться с
неизбежными крахами.
20.1.	Поиск неисправностей в сетях
Существует несколько хороших инструментов, позволяющих искать
неисправности в сети на уровне TCP/IP. Большинство этих средств выдает
низкоуровневую информацию, поэтому для того чтобы пользоваться ими.
нужно понимать принципы работы протоколов TCP/IP и маршрутизации.
С другой стороны, источником сетевых проблем могут служить и ошибки в
работе таких высокоуровневых протоколов, как DNS, NFS и HTTP Прежде
чем приступать к изучению данной главы, мы рекомендовали бы вам еше
раз просмотреть содержимое глав 13 и 14.
В этом параграфе мы рассмотрим общую стратегию поиска неисправно-
стей, после чего перейдем к знакомству с основными средствами такового:
командами ping, tracerouie. netstat, tcpdump и snoop Команда arp, которая
также предназначена для поиска неисправностей в сети, здесь не описывается;
так как о ней говорилось в параграфе 13.6.
Когда в сети возникает неисправность, первым желанием часто оказы-
вается желание побыстрее все устранить. Остановитесь! Важно сделать паузу
и обдумать возможные способы решения проблемы, а не предпринимать
необдуманные действия. Наибольшая ошибка заключается во внесении в
неисправную сеть нецелесообразных изменений.
Прежде чем “атаковать" собственную сеть, примите во внимание
следующие рекомендации.
•	Вносите пошаговые изменения в конфигурацию и выполняйте проверку
работоспособности сети после каждого изменения, чтобы убедиться в
совпадении полученного эффекта с ожидаемым.
•	Задокументируйте возникшую ситуацию и все вносимые изменения.
•	Начните с “края" системы или сети и продвигайтесь по ключевым ее
компонентам, пока не доберетесь до источника неисправности. Например,
сначала исследуйте сетевую конфигурацию клиента, затем проверьте
физическое соединение клиента с сетевым оборудованием, само сетевое
оборудование и, наконец, аппаратные сетевые средства сервера и его
программную конфигурацию.
•	Регулярно обментвайтесь мнением с сотрудниками. Большая часть
сетевых проблем касается многих людей: пользователей, провайдеров,
системных администраторов, инженеров по телекоммуникациям, сетевых
администраторов и т.д. Постоянный контакт позволит вам не мешать
друг другу при решении проблемы.
•	Работайте в команде. Многолетний опыт показывает, что люди совершают
меньше дурацких ошибок, если им оказывают поддержку.
•	Помните о многоуровневой структуре сетевых средств. Начните с верхнего
или нижнего уровня и последовательно продвигайтесь по стеку протоко-
лов. проверяя работу программных и аппаратных компонентов.
Последнюю рекомендацию следует рассмотреть несколько подробнее. Как
указывалось в параграфе 13.2, в архитектуре TCP/IP описываются уровни
Глово 20. Упровление сетями
56
абстракции, иа которых функционируют различные компоненты сети. На-
пример. протокол HTTP тесно связан с протоколом TCP, который, в свою
очередь, основан на протоколе IP, а последний взаимодействуете протоколом
Ethernet, работоспособность которого зависит от целостности сетевого кабеля.
Можно существенно уменьшить время поиска неисправности, если предва-
рительно разобраться, средства какого уровня ведут себя неправильно.
Проходя стек протоколов уровень за уровнем (вверх или вниз), задавайте
себе вопросы, подобные следующим.
•	Есть ли физическое соединение и светится ли индикатор связи?
•	Правильно ли сконфигурирован сетевой интерфейс?
•	Правильно ли настроены параметры DNS:*
•	Отображаются ли в таблицах маршрутизации имена других компьютеров?
•	Находит ли команда ping локальный компьютер (127.0.0.1)?
•	Находит ли команда ping другие компьютеры в локальной сети по
I Р-адресам?
•	Находит ли команда ping другие компьютеры в локальной сети по именам?
•	Находит ли команда ping компьютеры, находящиеся в другой сети?
•	Работают ли высокоуровневые сетевые команды, в частности telnet или
ssh?
Определив, на каком уровне возникает проблема, не спешите предпри-
нимать какие-либо действия Подумайте, как отразятся последующие про-
верки и вносимые изменения на других сетевых сервисах и компьютерах.
20.2.	Команда ping: проверка доступности компьютера
Команда ping удивительно проста. Она посылает ICMP-пакет ECHO RE-
QUEST конкретному компьютеру и ждет ответа. Несмотря на свою простоту,
команда ping стала одним из основных инструментов, использующихся при
отладке сетей.
Команду ping можно применять для проверки работоспособности отдель-
ных компьютеров н сегментов сети. В обработке ее запроса участвуют таблицы
маршрутизации. физические компоненты сетей и сетевые шлюзы, поэтому
для достижения положительного результата сеть должна быть (в большей или
меньшей мере) в рабочем состоянии Если не работает команда, можно быть
совершенно уверенным в гом. что более сложные средства и подавно не
станут функционировать. Однако это правило неприменимо в сетях, где
брандмауэры блокируют эхо-запросы ICMP Прежде чем грешить на зонди-
руемый компьютер, который якобы игнорирует команду, убедитесь, что ее
работе не препятствует брандмауэр В конце концов, отключите на короткое
время вмешивающийся не в свои дела брандмауэр и проверьге работоспо-
собности сети.
Команда ping поддерживается во всех системах. Большинство версии
команды работает в бесконечном цикле. если не задан аргумент “число
пакетов". Команда ping -s в Solaris выдает расширенную информацию,
которая в других операционных системах сообщается по умолчанию. Чтобы
прервать выполнение команды, нажмите <Ctrl-O
Если компьютер загружается очень медленно, зависает при загрузке или после попытки
установить связь посредством программы telnet, вероятнее всего, служба DNS функциони-
рует неверно.
662
Чость II Роботе в сетях
Вот пример работы команды:
% ping b«a*t
FING beast (10.1.1.46): 56 data bytes
64	bytes	from	10.1.1.46:	icmp_seq=0	ttl=255	time=0.808	ms
64	bytes	from	10.1.1.46:	icmp_seq=l	ttl=255	titne=0-400	ms
64	bytes	from	10.1.1.46:	icmp_seq=2	ttl=255	time=0.390	ms
ЛС
---- beast ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/raax/stddev = 0.390/0.533/0.808/0.195 ms
Информация о компьютере beast включает его IP-адрес, порядковый
номер ГСМР-пакета и время полного обхода (время затраченное на
прохождение пакета к пункту назначения и обратно). Такая информация,
очевидно, свидетельствует о том, что компьютер beast работает и подключен
к сети.
В нормально функционирующей сети команда ping позволяет выяснить,
включен компьютер или нет. Если же точно известно, что зондируемый
компьютер включен и работает корректно, то с помощью данной команды
можно получить полезную информацию о состоянии сети Пакеты, отправ-
ляемые командой ping, как и любые другие пакеты, маршрутизируются
средствами протокола IP. и успешное получение такого пакета после
завершения им кругового маршрута свидетельствует о том, что все компо-
ненты сети между источником и приемником пакета функционируют
правильно, хотя бы в первом приближении.
Порядковый номер ICMP-пакета — особенно полезный элемент инфор-
мации. Несмотря на то. что протокол IP не гарантирует доставки пакетов,
пакеты будут пропадать только в том случае, если сеть чересчур загружена.
Потерю пакетов нужно обязательно выявлять, потому что этот факт иногда
маскируется протоколами более высокого уровня. Может показаться, что сеть
функционирует нормально, но на самом деле она работает гораздо медленнее,
чем должна, — не только из-за повторной передачи пакетов, но также из-за
“накладных расходов", требуемых для выявления и обработки пропавших
пакетов соответствующими протоколами.
Если не все пакеты доходят до адресата, запустите программу tracerouie
(описана в следующем параграфе), с тем чтобы выяснить маршрут, по
которому пакеты следуют к компьютеру-адресату. Затем посредством команды
ping проверьте все промежуточные шлюзы, через которые пролегает маршрут,
и узнайте, на каком этапе теряются пакеты. Чтобы точно диагностировать
проблему, следует отправить такое количество пакетов, которое позволит
получить статистически достоверные результаты. С достаточной степенью
вероятности можно утверждать, что неисправность будет найдена на участке
между последним шлюзом, для которого количество потерянных пакетов не
больше некоторой заданной величины, и шлюзом, при обращении к которому
количество потерянных пакетов превышает эту величину.
Время полного обхода, сообщаемое командой ping, дает представление
об обшей скорости передачи пакета по сети. Колебания этого значения, как
правило, нс являются признаком проблем. Иногда пакеты задерживаются на
десятки и сотни миллисекунд без какой-либо очевидной причины — просто
так работают протокол IP и сама ОС UNIX. Но все-таки следует ожидать,
что время полного обхода для большинства пакетов будет постоянным, за
некоторыми исключениями. Большинство современных маршрутизаторов
Глово 20. Упровление сетями
6uJ
обеспечивает выдачу ответов на 1СМР-запросы с ограничениями по скорости,
т.е. маршрутизатор может задержать ответ на пакет команды ping в связи с
общим ограничением трафика протокола ICMP-
Команда ping позволяет задавать размер посылаемого эхо-пакета. Если
передается пакет, длина которого превышает максимально допустимое для
данной сети значение (в частности. 1500 байтов в сети Ethernet), включается
принудительная фрагментация. Это позволяет выявлять ошибки передачи
данных в самом носителе и другие низкоуровневые ошибки, например
проблемы, связанные с перегрузкой сети ATM.
СО • R Solaris И	нужная длина пакета указывается в конце команды
% ping cuinfo.comell.edu 1500
WA В Red Hat Linux и FreeBSD длина пакета в байтах задается флагом -s.
хУ1 Так как слишком большие пакеты могут вызвать проблемы в сети, во FreeBSD
эту опцию может указывать только пользователь root’
# ping — 1500 cuinfo.cornsll.edu
При работе с командой ping следует придерживаться следующих ограни-
чений. Во-первых, сложно отличить неисправность сети от неисправности
сервера, пользуясь только этой командой. Сообщение команды ping о потере
пакетов говорит лишь о том. что какой-то компонент работает неправильно
Во-вторых, команда ping не позволяет получить информацию о состоянии
исследуемого компьютера. Эхо-запросы обрабатываются в стеке протокола
LP и не требуют, чтобы на зондируемом компьютере выполнялся серверный
процесс. Наличие ответа служит гарантией лишь того, что компьютер включен
и ядро системы функционирует. Для проверки работы отдельных служб, таких
как HTTP и DNS. следует применять высокоуровневые средства.
20.3. Программа traceroute: отслеживание IP-пакетов
Программа traceroute, которую написал Ван Джейкобсон (Van Jacobson),
позволяет установить последовательность шлюзов, через которые проходит
IP-пакет на пути к пункту своего назначения. Почти все современные
операционные системы содержат ту или иную версию данной программы.
Синтаксис ее вызова таков:
traceroute имя_компьютера
У этой программы очень много опций, большинство из которых в
повседневной работе не применяется. Как обычно, имя_компьютера может
быть задано в символической или числовой форме. Выходная информация —
это список узлов начиная с первого шлюза и заканчивая пунктом назначения.
Например, на нашем компьютере jaguar команда traceroute drevil дает
следующие результаты
% tracerouts dxevil
traceroure to drevil (192.225.55.137), 30 hops ir.ax, 38 oyre packers
1	xor-gw2 (192.108.21.254)	0.840 cs 0.693 ms 0.671 tr.s
В 1998 г. была осуществлена атака Ping of Death (буквально — “свист проносящейся
смерти”), которая вызвала крах многих систем UNIX и Windows. Заключалась она в том,
что посылались очень длинные ping-пакеты, сборка которых на компьютере-получателе
приводила к переполнению буфера и краху системы.
664
Чость II. Робото в сетях
2	xor-gw4 (1S2.225.56.10) 4.642 ms 4.582 ms 4.674 ms
3	drevil (192.225.55.137) 7.959 ms 5.949 ms 5.908 ms
Эта информация говорит о том, что для попадания с компьютера jaguar
на компьютер drevil пакеты должны пройти два наших внутренних шлюза.
Кроме того, показано время полного обхода для каждого шлюза — проведено
по три замера. Обычно количество переходов от одного узла Internet к другому
составляет от 10 до 12
Программа traceroute осуществляет запись искусственно заниженного
значения в поле TTL (Time То Live — время жизни, или предельное число
переходов) исходящего пакета Когда пакет приходит на очередной шлюз,
его значение TTL уменьшается на единицу. Если шлюз обнаруживает, что
значение TTL стало равным нулю, он удаляет пакет и возвращает узлу-от-
правителю специальное ICMP-сообщение.
Для первых нескольких пакетов программа traceroute задает значение TTL
равным 1 Первый же шлюз, получивший пакет (в нашем примере это
xor-gw2), обнаруживает, что его время жизни истекло. Тогда он отбрасывает
пакет и посылает компьютеру jaguar ICMP-сообшение, в поле отправителя
которого указывается IP-адрес шлюза. Программа traceroute обращается к
службе DNS и по имеющемуся адресу находит имя шлюза.
Информация о поиске имен в DNS приведена в параграфе 16.1 / (раздел,
посвященный записям PTR).
Для получения данных о следующем шлюзе посылается очередная группа
пакетов, поле TTL которых равно 2. Первый шлюз маршрутизирует эти
пакеты и уменьшает значение TTL на единицу. Второй шлюз удаляет пакеты
и генерирует описанное выше ICMP-сообшение. Этот процесс продолжается
до тех пор. пока пакеты не достигнут требуемого компьютера; значение TTL
при этом будет равно числу переходов.
Большинство маршрутизаторов посылает свои ICMP-сообшения через тот
интерфейс, который является “ближайшим” к узлу-отправителю. Если,
наоборот, запустить программу traceroute на машине-получателе, чтобы узнать
маршрут к исходному компьютеру, то. скорее всего, будет выдан другой
список IP-адресов, соответствующий тому же набору маршрутизаторов.
Программа traceroute посылает для каждого значения TTL три пакета,
что иногда приводит к неожиданным результатам. Если промежуточный шлюз
распределяет трафик по нескольким маршрутам, то эти пакеты могут
возвращаться разными компьютерами. В таком случае программа traceroute
сообщает обо всех полученных ответах
Рассмотрим интересный пример, в котором посредством программы
iraceroute определяется маршрут с компьютера в домене colorado.edu к домену
xor.com.
rupertsbergfc traceroute xor.com
traceroute: Warning: xor.com has multiple addresses; using 192.225.33.1
uaseroute to xor.com (192.225.33.1), 30 hops max, 40 byte packets
1 cs-gw3-faculty.cs.colorado.edu (128.138.236.3) 1.362 ms 2.144 ms 2.76 ms
2 cs-gw-dmz.cs.colorado.edu (128.138.243.193) 2.720 ms 4.378 ms 5.052 ms
3 enqr-cs.Colorado.EDU (128.138.80.141) 5.587 ms 2.454 ms 2.773 ms
4 hut-enar.Colocado.EDU (128.138.80.201) 2.743 ms 5-643 ms 2.772 ms
5 cuatrr.-gw.Colcrado.EDU (128.138.80.2) 5.587 ms 2.784 ms 2.777 ms
6 204.131.62.6 (204.131.62.6) 5.585 ms 3.464 ms 2.761 ms
7	border-frm-BRAN.coop.net (199.45.134.81) 5.593 ms 6.433 ms 5.521 ms
8	core-gw-eth-2-5.coop.net (199.45.137.14) 53.806 ms * 19.202 ms
9	xor.com (192.225.33.1)	16.838 ms 15.972 ms 11.204 ms
Глово 20 Упровление сетями
n65
Мы видим, что пакеты, прежде чем покинуть домен colorado.edu, проходят
пять внутренних шлюзов (от cs-gw3-faculty до cuatm-gw). На следующем
переходе пакеты попадают в шлюз с адресом 204.131.62.6, который не имеет
DNS-имени. Затем, после двух переходов в домене coop.net, они оказываются
в домене xor.com.
На восьмом переходе вместо одного из значений времени обхода
отображается звездочка. Это означает, что на какой-то из отправленных
пакетов не был получен ответ. Такая ситуация может быть вызвана
перегрузкой сети, но это не единственное возможное объяснение. Программа
traceroute использует низкоприоритетные ICMP-пакеты, которые отбрасыва-
ются многими маршрутизаторами, отдающими предпочтение “реальному"
трафику Появление нескольких звездочек в выводе программы traceroule не
является причиной для беспокойства.
Если для конкретного шлюза отображаются все три звездочки, это
означает, что от него не было получено ни одного сообщения Вероятнее
всего, шлюз просто выключен. Правда, иногда шлюз конфигурируют таким
образом, чтобы он молча отбрасывал устаревшие пакеты. В этом случае
пакеты благополучно перейдут на следующий шлюз. Другой возможной
причиной появления звездочек может быть то, что ответные пакеты шлюза
возвращаются слишком долго и программа traceroute перестает ожидать их
прибытия.
Некоторые брандмауэры полностью блокируют передачу 1СМР-сообще-
ний о пакетах с истекшим временем жизни. Если маршрут пролегает через
один из таких брандмауэров, программа не сможет получить информацию о
шлюзах, находящихся за ним. Однако она узнает общее число переходов до
пункта назначения, так как отправляемые эхо-пакеты в конце концов пройдут
весь маршрут. Некоторые брандмауэры могут также блокировать исходящие
UDP-пакеты, которые программа traceroute посылает для инициирования
ICMP-ответов. В этой ситуации программа не выдаст никакой полезной
информации.
Медленная передача данных не всегда свидетельствует о неисправности
сети. Некоторые сети действительно имеют большую задержку. Медлитель-
ность может быть также следствием перегрузки передающих сетей, особенно
если в них используется технология CSMA/CD (Carrier Sense Multiple Access
with Collision Detection — множественный доступ с контролем несущей и
обнаружением конфликтов). В таких сетях (например, в Ethernet) произво-
дятся многократные повторные попытки передачи пакета. Определить это
можно по нелогичному значению времени полного обхода, так как коллизии
(конфликты) увеличивают случайную составляющую поведения сети.
Иногда можно увидеть символы !N вместо значения времени. Это говорит
о том, что соответствующий шлюз вернул сообщение о “недостижимости"
сети, т.е. ему не известно, куда посылать пакет. Сообщения о “недостижи-
мости” узла или протокола помечаются как ! Н или ! Р соответственно. Шлюз,
от которого получено одно из указанных сообщений, является последним в
маршруте и обычно имеет проблемы с маршрутизацией (возможно, они
вызваны разрывом связи): либо его статические маршруты заданы неверно,
либо протоколы динамической маршрутизации не могут определить верный
маршрут для передачи пакета получателю.
Если программа traceroute не работает (или работает слишком медленно),
это может быть вызвано превышением периода тайм-аута при попытках узнать
имя компьютера посредством службы DNS. Если на том компьютере, с
которого производится трассировка, не функционирует DNS, воспользуйтесь
командой traceroute -п Она будет выводить только IP-адреса шлюзов.
666
Чость II Роботе в сетях
20.4.	Команда netstah получение всевозможной
информации j состоянии сети
Команда netstat выдает различную информацию о состоянии сетевого
программного обеспечения, включая статистику сетевых интерфейсов, данные
о маршрутизации и таблицы соединений. Никакого объединяющего звена во
всех этих информационных блоках нет, просто они касаются функциониро-
вания сети. Команда netstat включена во все операционные системы, но в
каждой из них поддерживаются разные нвборы опций.
Мы рассмотрим четыре наиболее распространенных варианта использо-
вания команды netstat. Это:
•	проверка состояния сетевых соединений;
•	анализ информации о конфигурации интерфейсов;
•	изучение таблицы маршрутизации,
•	получение статистических данных о различных сетевых протоколах.
Контроль состояния сетевых соединений
Будучи вызванной без аргументов, команда netstat выдает информацию
о состоянии активных TCP- и UDP-портов. Неактивные серверы, ожидающие
запросов на установление соединений, как правило, не отображаются. О них
можно узнать с помощью команды netstat -а’. Результат выглядит так:
% netstat -а
Active Internet connections (including servers)
Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
tcp4	0	0	*.6013	* *	LISTEN
tcp46	0	0	•-6013	* *	LISTEN
tcp4	0	0	nimi.ssh	xor.com.4105	ESTABLISHED
tcp4	0	20	nimi.ssh	xcr.com.1612	ESTABLISHED
tcp4	0	0	*.13500	* •	LISTEN
tcp4	0	0	nimi.ssh	135.197.2.114.883	ESTABLISHED
tcp4	0	0	nimi.1599	xor.com.telnet	ESTABLISHED
tcp4	0	0	* .ssh	* *	LISTEN
tcp46	0	0	* .ssh	* *	LISTEN
tcp4	0	0	nimi.ssh	135.197.2.114.776	ESTABLISHED
tcp4	0	0	*.cvsup	* w	LISTEN
udp4	0	0	*.syslog	* *	
udp 4	0	0	*.ntalk	* *	
Этот результат получен на компьютере nimi. Вывод команды свидетель-
ствует о наличии нескольких входящих соединений по протоколу SSH, одного
исходящего telnet-соединения и группы портов, ожидающих установления
соединения. Обратите внимание на строки, в которых тип протокола —
tcp46. Это сервисы, работающие в соответствии со стандартом IPv6.
Адреса представлены в формате имя_компьютера. сервис, где сервис —
номер порта. Для известных сервисов порты указаны в символическом виде
(соответствия между номерами портов и их именами определены в файле
/etc/services). При наличии опции -п все адреса отображаются в числовом
Она отображает соединения с именованными UNIX-сокетами, но, поскольку они устанав-
ливаются в рамках одного компьютера, мы их здесь рассматривать не будем.
Глово 20. Улровление сетями
667
виде. Помните, что при нефункционирутошей службе DNS команда netstat
будет выполняться очень медленно, если не указать флаг -п.
В колонках Send-Q и Recv-Q показывается, сколько запросов находится
во входящих и исходящих очередях на данном компьютере. На другом конце
соединения размеры очередей могут быть другими. Желательно, чтобы эти
значения были близки к нулю и не были ненулевыми постоянно. Конечно,
если команда netstat запускается через сетевой терминал, для ее соединения
размер исходящей очереди, скорее всего, никогда не будет равен 0.
Состояние соединения имеет значение только для протокола TCP
Протокол UDP не проверяет факт установления соединения. Наиболее
распространенные состояния: ESTABLISHED (установлено) — для активных
соединений, LISTENING (ожидание) — для серверов, ожидающих поступле-
ния запросов (при отсутствии опции -а обычно не показываются), TIME_WAIT
(ожидание закрытия) — для соединений, находящихся в процессе закрытия.
Эта информация полезна главным образом дпя устранения проблем на
более высоком уровне, если, конечно, базовые сетевые средства работают
нормально. Команда netstat позволяет проверить правильность настройки
серверов и диагностировать определенные виды нарушений связи, особенно
при работе с протоколом TCP. Например, если соединение находится в
состоянии SYN SENT, это означает наличие процесса, который пытается
установить контакт с несуществующим или недоступным сервером.
Если команда netstat сообщает о большом количестве соединений,
находящихся в состоянии SYN WAIT, то компьютер, вероятно, не в состоянии
обработать запросы на установление соединений. Такая ситуация может быть
вызвана ограничениями системного ядра или даже злонамеренными попыт-
ками вызвать перегрузку.
О настройке ядра можно узнать в главе 12.
Просмотр информации о конфигурации интерфейса
Команда netstat -i сообщает о состоянии сетевых интерфейсов. Вот, к
примеру, результаты, полученные на компьютере evolve, работающем под
управлением Solaris:
% netstat
Name Mtu
loO 8232
hmeO 1500
hmel 1500
Net/Dest
loopback,
evolve
evoive-bl
Ipkts	lerrs OpKts	Oerrs Collis
11650	0	11650	0	0
16438	0	18356	0	110
94852	3	379410	13	487
Указанный компьютер имеет два сетевых интерфейса. В колонках ipkts
и Opkts указывается количество пакетов, принятых и переданных через
каждый интерфейс с момента начальной загрузки системы. В колонках lerrs
и Oerrs приводится число ошибок в принимаемых и передаваемых данных:
здесь учитывается много разных типов ошибок, и наличие какого-то их числа
вполне нормально.
Количество ошибок должно составлять менее 1% от числа пакетов. Если
частота появления ошибок высока, сравните эти показатели на нескольких
соседних компьютерах. Большое число ошибок на одном компьютере
свидетельствует о наличии проблемы в его интерфейсе или соединении, тогда
как высокая частота ошибок, возникающих на всех компьютерах, в боль-
шинстве случаев обусловлена наличием проблемы в среде передачи.
668
Чость II. Робото б сетях
Количество коллизий — это показатель степени загруженности сети;
наличие ошибок свидетельствует о проблемах с кабелями. Хотя коллизия
является одной из разновидностей ошибки, их число команда netstat
подсчитывает отдельно. В колонке Collis указывается число конфликтов,
произошедших при отправке пакетов*. Это число следует использовать для
вычисления доли ошибочных пакетов от общего количества отправленных
пакетов (Opkts). В приведенном выше примере частота конфликтов в
интерфейсе hmeO составляет около 0,6%, а в интерфейсе hmel — 0,13%.
“Нормальным” считается значение менее 5%, а значение выше 15% говорит
о серьезной перегрузке сети.
Работу сетевого интерфейса можно контролировать в реальном времени,
однако соответствующие опции командной строки различаются в зависимости
от системы. Показанные ниже команды выдают статистику с интервалом в
одну секунду. Выводные данные взяты из FreeBSD.
solaris% netetat -i 1
hp-ux% netetat 1
redhat% netetat -1 -c
freebsd% netstat 1
input		(Total)	output	
packets	errs	packets	errs	colls
13971549	1216	14757869	16	1431629
512	0	99	1	27
464	1	94	0	40
516	0	101	□	26
452	1	87	0	14
336	0	71	0	19
В этом примере количество коллизий составляет от 20% до 30%. Видимо,
сеть передает пакеты очень медленно или вообше не функционирует.
Непрерывный режим работы команды netstat особенно эффективен при
выслеживании источника ошибок. Команда netstat -i может сообщить о
существовании проблем, но она не скажет, какова причина ошибок: то ли
это постоянно возникающая аппаратная проблема, то ли кратковременное,
но фатальное событие. Наблюдение за сетью при различных уровнях
загруженности позволит получить гораздо более полное представление о том.
что происходит. Задайте команду ping с большой длиной пакетов и наблюдайте
за выводом команды netstat
Проверка таблицы маршрутизации
Команда netstat -г отображает таблицу маршрутизации ядра. Вот пример,
полученный на компьютере, который работает под управлением Solaris и
имеет два сетевых интерфейса.
% netstat -г -п
Routing Table					
Destination	Gateway	Flags	Ref	Use	Interface
192.225.44.0	192.225.44.88	U	3	1841	hmeO
192.168.3.0	192.168.3.12	u	2	1317	hmel
10.0.0.0	192.168.3.252	UG	0	4	hmel
Это поле имеет смысл только в сетях с широковещательной передачей, например в Ethernet.
Глова 20 Управление сетями
669
default	192.225.44.254	UG	0	91666
127.0.0.1	127.0-0.1	UH	0	543	loO
Пункты назначения и шлюзы могут быть представлены либо доменными
именами, либо IP-адресами. Опция -п задает вывод IP-адресов.
В колонке Flags отображаются флаги, характеризующие маршрут: и
(пр) — активный, G (gateway) — шлюз, н (host) — узловой (связан с
конкретным адресом, а не сетью). Флаг D (не показан) обозначает маршрут,
полученный в результате переадресации по протоколу ICMP. Флаги G и Н
вместе обозначают маршрут к компьютеру, проходящий через промежуточный
шлюз. Остальные поля содержат статистические данные о маршруте: текущее
число ТСР-соединений по этому маршруту, количество отправленных пакетов
и имя используемого интерфейса. Точный вид представленных данных
зависит от конкретной операционной системы.
Информацию о таблице маршрутизации можно найти в параграфе 13.5.
Приведенный вариант команды netstat полезен для проверки правильно
сти таблицы маршрутизации. Особенно важно убедиться в наличии и
корректности стандартного маршрута. Иногда он обозначается в виде адреса
со всеми нулями (0.0.0.0), иногда — словом default.
Просмотр статистики функционирования
различных сетевых протоколов
Команда netstat -$ выдает содержимое всевозможных счетчиков, исполь-
зуемых в сетевых программах. Информация разбивается на разделы в
соответствии с протоколами: IP, ICMP, TCP и UDP. Ниже приведены
отдельные фрагменты листинга команды netstat -s, полученного на компыо-
тере-шлюзе; они отредактированы так. чтобы были видны только наиболее
интересные данные.
1р:
2313683 total packets received
0 bad header checksums
1642600 packets for this host
25743 packets sent from this host
0 output packets dropped due to no bufs, etc.
Отсутствие ошибок контрольных сумм говорит о том, что аппаратное
соединение работает нормально. Также важен тот факт, что пакеты не
отбрасывались иг-за недостатка свободной памяти (последняя строка)’.
icmp:
57 calls to icinp_error
Output histogram:
echo reply: 157
destination unreachable: 57
Input histogram;
echo reply: 6
destination unreachable: 4
echo: 157
Применяйте опцию -ш при запуске команды netstat в Solaris или FreeBSD для получения
более подробной информации об использовании памяти сетевыми службами.
670
Чость II. Робота в сетях
time exceeded: 14
157 message responses generated
Показатели числа эхо-запросов, сгенерированных ответов и эхо-ответов
совпадают. Отметим, что сообщения "destination unreachable” (адресат недос-
тижим) могут посылаться даже тогда, когда пакеты, казалось бы. маршрути-
зируются нормально. Например, дефектные пакеты рано или поздно
достигают шлюза, который отклоняет их, и по цепи шлюзов возвращается
сообщение об ошибке.
tcp:
25087 packets sent
25499 packets received
31 connection requests
30 connection accepts
56 connections established {including accepts)
64 connections closed (including 13 drops)
4 embryonic connections dropped
Рекомендуем определить приемлемые диапазоны этих показателей, чтобы
можно было сразу же замечать необычное поведение сети.
20.5.	Анализаторы пакетов
Программы tcpdump, snoop и nettl относятся к классу инструментальных
средств, известных как анализаторы пакетов. Они следят за трафиком в сети
и регистрируют либо выводят на экран пакеты, которые удовлетворяют
заданным критериям. Например, можно перехватывать все пакеты, посылае-
мые на какой-то компьютер или с него, либо TCP-пакеты, относящиеся к
конкретному сетевому соединению.
Анализаторы пакетов полезны как для решения известных проблем, так
и для выявления абсолютно новых. Весьма полезно время от времени
запускать эти программы и проверять, нормально ли обрабатывается сетевой
трафик.
Поскольку анализаторам необходимо уметь перехватывать пакеты, кото-
рые локальный компьютер обычно не получает (или на которые не обращает
внимания), базовые сетевые аппаратные средства должны разрешать доступ
к каждому пакету. Это характерно для широковещательных технологий, в
частности Ethernet, а также для некоторых видов сетей Token Ring, в которых
отправитель пакета удаляет его из кольца после полного обхода контура.
Анализаторы пакетов должны иметь доступ к низкоуровневому трафику,
поэтому их работе могут мешать сетевые мосты, одной из функций которых
является препятствие распространению "ненужных" пакетов. Однако с
помощью анализаторов возможно получение полезной информации даже в
сетях с мостами. Можно, к примеру, обнаружить проблемы, затрагивающие
широковещательные и групповые пакеты. Объем выдаваемой информации
зависит от модели моста.
Более подробно о сетевых мостах рассказывается в параграфе 15.2.
Аппаратный интерфейс должен не только иметь возможность получать
доступ ко всем сетевым пакетам, но также содержать механизм, обеспечи-
вающий передачу этих пакетов вверх на программный уровень. Ведь обычно
адреса пакетов проверяются на аппаратном уровне, а ядру показываются лишь
широковещзтелыше/групловые пакеты и те, которые адресованы данному
Глово 20 Упровление сетями
671
компьютеру. В беспорядочном режиме (promiscuous mode) интерфейс позволяет
ядру получать все сетевые пакеты, даже если они предназначены для других
компьютеров.
Анализаторы пакетов, как правило, поддерживают многие форматы
пакетов, используемые стандартными демонами UNIX, и часто могут
отображать содержимое пакетов в удобном для пользователя виде. Это
облегчает пользователю анализ сеанса между двумя программами. Некоторые
анализаторы кроме заголовка пакета выводят и содержимое пакета в текстовом
виде, что полезно для исследования протоколов верхних уровней Так как
некоторые из этих протоколов пересылают информацию (в том числе и
пароли) по сети в незашифрованном виде, следует заботиться о сохранении
конфиденциальности пользовательских данных.
Каждая из рассматриваемых нами операционных систем имеет анализатор
пакетов. В связи с тем что анализатору необходим доступ к пакетам на самом
низком уровне, он должен запускаться от имени пользователя root. Подобное
ограничение снижает шансы обычных пользователей получить доступ ко
всему сетевому трафику, но на самом деле этот барьер можно преодолеть.
Во многих организациях анализаторы пакетов удалены с большинства
компьютеров для уменьшения риска злоупотребления этими программами.
Если данная мера невозможна, следует проверять интерфейсы системы, чтобы
они не работали в “беспорядочном” режиме без ведома или согласия
администратора.
Программа snoop: анализатор пакетов в Solaris
В Solaris анализатор пакетов называется snoop. С помощью аргументов
командной строки можно задать перехват пакетов определенного типа,
конкретного компьютера, протокола, порта и т.д.
Если программа запушена без аргументов, она анализирует пакеты,
проходящие через первый из найденных ею‘интерфейсов. Обычно это тот
интерфейс, который приведен первым в выводе команды netstat -i (исключая
интерфейс обратной связи). Для указания конкретного интерфейса применя-
ется опция -d имя_интерфейса. Имя интерфейса следует вводить в том виде,
в котором оно сообщается командой netstat -i (например, для первого
интерфейса Ethernet часто используется имя hmeO). Опция -V позволяет
получить развернутую информацию, а при наличии опции -v выводится
несколько дополнительных поясняющих строк для каждого пакета.
Синтаксис командной строки программы snoop достаточно сложен, но
все ее опции хорошо описаны на соответствующей man-странице. В команд-
ную строк}- можно помещать выражения, содержащие такие ключевые слова,
как host, port, tcp. udp и ip, а также обозначения операций and, or или not.
Рассмотрим несколько примеров. Ниже приведены результаты работы
программы snoop, которые могут оказаться полезными для настройки
процесса передачи электронных сообщений между компьютерами evolve и
chimchim. Мы задали такие параметры командной строки, которые позволят
проиллюстрировать работу этого анализатора пакетов:
* anoop host сЫлсЫл and host evolve and tcp port 25
evolve.xor.com -> xor.com SMTP C
xor.com -> evolve.xor.com SMTP R 220 xor.com ESMTP Se
evolve.xor.com -> xor.com SMTP C
evolve.xor.com -> xor.com SMTP C EHLO evolve.xor.com\r
xor.coin -> evolve.xor.com R 250- xor.com Hello ev
672
Чость II Робото в сетях
evolve.xor.com -> xor.com SMTP C MAIL FROM: <root0evol
xor.com -> evolve.xor.com SMTP R
xor.com -> evolvn.xor.com SMTP R 250 <rooz0evolve.xor
evolve.xor.com -> xor.com SMTP C RCPT TO: <ned0xor.com>
xor.com -> evolve.xor.com SMTP R 250 <ned0xor.com>...
evolve.xor.com -> xor.com SMTP C DATA\r\n
xor.com -> evolve.xor.com SMTP R 354 Enter mail, end
Указанная командная строка означает следующее: “Перехватывать все
пакеты, передаваемые между компьютерами chimchim и evolve и адресованные
TCP-порт>г 25”.
Из примера видно, что каждому пакету соответствует одна строка.
В начале строки приводится имя отправителя пакета, а затем имя получателя.
Кроме того, в строке содержится и высокоуровневая информация, такая как
имя протокола, номер порта и начальные байты данных пакета (здесь эта
информация приведена не полностью для экономии места).
Если с помощью программы telnet зарегистрироваться на удаленном узле,
а затем запустить анализатор snoop, придется отфильтровать пакеты самого
сеанса от общего трафика. Например, чтобы проигнорировать трафик,
направленный к компьютеру evolve или идущий от него, следует задать такую
команду:
й snoop not host «volva
Если нужно исследовать неработающий DNS-сервер с именем mrhat,
воспользуйтесь следующей командой:
# snoop host mrhat | grep DNS
В этом случае утилита grep позволит исключить вывод ненужной
информации.
Программа nettl: анализатор пакетов в HP-UX
В HP-UX входит жалкая пародия на анализатор пакетов, называемая
nettl . На самом деле это очень мощная программа, способная работать в
быстрых сетях, но конфигурировать ее настолько сложно, что для быстрой
отладки сети она не годится. Тем. кто планируют осуществлять анализ пакетов
с компьютера, работающего под управлением HP-UX. мы рекомендуем
инсталлировать программу tcpdump.
Программа nettl входит в пакет Network Tracing and Logging (трассировка
пакетов и регистрация событий в сети) системы HP-UX. По умолчанию эта
программа запускается на этапе начальной загрузки системы. Если ее
использование не планируется, то не забудьте отключить ее. Для этого в
файле /ctc/rc.config.d/nettl установите переменную NETTL равной 0.
Программа nettl считывает параметры своей конфигурации из файла
/etc/nettlgen.conf.
Программа tcpdump: самый лучший анализатор
Замечательный анализатор пакетов tcpdump, написанный Ваном Джей-
кобсоном, входит в комплект поставки систем Red Hat Linux и FreeBSD и
Такое отношение к программе подтверждается и ее названием: слово “nettle” означает
“крапива; раздражать, сердить”.
Глово 20. Упровление сетями
,73
уже давно считается промышленным стандартом. Его исходные коды имеются
в HP-UX, Solans и большинстве других операционных систем. Работа с этим
анализатором напоминает работу с программой snoop.
По умолчанию программа tcpdunip использует первый найденным ею
сетевой интерфейс. Если она выбрала не тот интерфейс, то посредством
опции -i следует задать нужный. В случае неисправности службы DNS или
если необходимо видеть адреса компьютеров, воспользуйтесь опцией -п. Эта
опция имеет большое значение, так как медленная работа DNS может вызвать
отбрасывание пакетов до того, как они будут проанализированы программой
tcpdunip. Опция -v позволяет получить более детальное описание каждого
пакета, а самые подробные результаты выдаются при задании опции -w. Если
указана опция -w. программа сохраняет перехваченные пакеты в файле. Для
чтения пакетов из файла предназначена опция -г.
Ниже показаны результаты работы программы tepdump. запушенной на
узле jaguar.xor.com. Спецификация host jaguar задает получение информации
только о тех пакетах (получаемых и отправляемых), которые имеют непо-
средственное отношение к компьютеру jaguar.
й tcpdunip host jaguar
13:40:23 jaguar.xor.com.1697 > xor.com.domain: A? cs.colorado.edu.
13:40:23 xor.com.domain > jaguar.xor.com.1697: A rn.roe.cs.colorado.edu
13:40:23 jaguar.xor.com.1698 > xor.com.domain: PTR? 5.96.138.128.in-adar.arpa.
13:40:23 xor.com.domain > jaguar.xer.com.1698: PTR ir.roe.cs.colorado.edu.
В первой строке вывода содержится информация о том. что с компьютера
jaguar в домен xor.com отправлен пакет с запросом к службе DNS.
касающимся имени cs.colorado.edu. Во второй строке приводятся сведения об
ответном пакете, где говорится о том. что указанное имя является псевдо-
нимом узла mroe.cs.colorado.edu. Далее выдаются данные о пакете с запросом
доменного имени, соответствующего I P-адресу компьютера mroe. В последней
строке сообщается результат запроса
На man-стран и не. посвященной программе tepdump. приведен ряд хоро-
ших примеров задания различных фильтров, а также полный список ключевых
слов, которые могут использоваться в командной строке.
20.6.	Протоколы упровления сетями
За последние десять лет сети быстро усложнялись и разрастались, что
вызвало потребность в разработке средств сетевого управления. Поставщики
операционных систем и организации по стандартизации подходили к
решению этой задачи разнообразными путями. Самым значительным резуль-
татом стала разработка ряда стандартных протоколов управления сетевыми
устройствами и множества высокоуровневых программных средств, которые
их используют.
Протоколы управления сетями о предел яки стандартный метод зондиро-
вания какого-либо устройства с целью выявления его сетевых соединении,
конфигурации и общего состояния. Кроме того, протоколы позволяю!
модифицировать часть згой информации, чтобы стандартизировать управле-
ние различными видами аппаратуры на сетевом уровне и осуществлять это
управление с центральной станции
Наиболее распространенным протоколом управления, используемым в
сетях TCP/IP, является SNMP (Simple Network Management Protocol —
простой протокол управления сетью). Несмотря на свое название, на самом
674
Чость II. Робото в сетях
20.7.
деле, этот протокол достаточно сложен. Он определяет иерархическое
пространство имен для объектов управления и способ чтения и записи
данных, относящихся к этим объектам, на каждом узле иерархии. Он также
задает способ, которым управляемые сущности (“агенты”) посылают сооб-
щения о происходящих событиях (“прерывания”) станциям управления. Ядро
протокола действительно является простым; самая сложная часть SNMP
находится над протокольным уровнем и заключается в соглашениях по
построению пространства имен и соглашениях по форматированию элементов
данных на узле иерархии. Протокол SNMP широко поддерживается разра-
ботчиками программного обеспечения.
Существует и ряд других стандартов управления сетями. Многие из них
созданы организацией DMTF (Distributed Management Task Force — рабочая
группа по разработке распределенных систем управления), которая реализо-
вала такие концепции, как WBEM (Web-Based Enterprise Management —
система управления предприятием, основанная на использовании Web-тех-
нологий), DMI (Desktop Management Interface — интерфейс управления
компьютером) и С1М (Conceptual Interface Model — концептуальная модель
интерфейса). Некоторые из этих концепций, в частности DMI. приняты
рядом известных фирм-производителей и могут служить полезным дополне-
нием (а иногда и заменой) протоколу SNMP. В настоящее время, однако,
основным средством управления сетями является все же SNMP.
Поскольку SNMP — абстрактный протокол, то для его использования
нужна программа-сервер (’‘агент”) и программа-клиент (“менеджер”). (Как
ни странно, серверная сторона SNMP является управляемым элементом, а
клиентская — управляющим.) Клиентом может быть как простая утилита,
работающая в режиме командной строки, так и выделенная станция
управления, на мониторе которой в графическом виде отображается сеть
вместе со всеми своими неполадками
Выделенные станции управления сетями — главная причина существо-
вания протоколов управления. Большинство программных продуктов позво-
ляет строить не только логическую. но и топографическую модель сети. Обе
эти модели выводятся на экран, при этом постоянно отображается текущее
состояние каждого компонента.
Подобно тому, как график может показать скрытый смысл, заложенный
в заполненной цифрами странице, так и станция управления сетью способна
обобщить и представить состояние крупной сети в форме, удобной для
понимания Другим способом такую информационную сводку получить
практически невозможно.
Основное преиь(ущество SNMP заключается в том, что абсолютно все
типы сетевых аппаратных средств выводятся на один уровень. UNIX-системы
в основном похожи друг на друга, чего нельзя сказать о маршрутизаторах,
шлюзах и остальных низкоуровневых компонентах. При использовании
протокола SNMP все они начинают “общаться” на одном языке и могут
зондироваться, сбрасываться в начальное состояние и конфигурироваться с
центральной станции. Очень удобно, когда есть один согласованный интер-
фейс, применимый ко всем сетевым устройствам.
SNMP: простой протокол управления сетью
Когда в начале 90-х гт. протокол SNMP впервые появился на рынке,
возникла золотая лихорадка в миниатюре. Сотни компаний выпустили
собственные пакеты управления по протоколу SNMP. Кроме того, многие
Глово 20. Упровление сетями
675
поставщики аппаратных и программных средств стали включать в свои
продукты SNMP-агенты.
Перед тем как погрузиться в дебри SNMP, заметим, что терминология,
применяемая в этой области, одна из самых бестолковых и невразумительных.
Стандартные названия объектов и концепций SNMP будут активно уводить
читателей от понимания их назначения. Так что запаситесь терпением.
Структура протокола SNMP
В SNMP данные организованы иерархически, причем структура иерархии
жестко определена. Это позволяет пространству данных оставаться универ-
сальным и расширяемым, по крайней мере теоретически. Большие его области
оставлены для перспективного использования; дополнения поставщиков
операционных систем локализуются в определенных диапазонах во избежание
конфликтов. Для формирования пространства имен применяются так назы-
ваемые базы управляющей информации (Management Information Base, MI В)
Это структурированные текстовые файлы, которые содержат описания
данных, доступных по протоколу SNMP. Ссылки на конкретные переменные,
описываемые в базе, называются идентификаторами объектов (Object Identi-
fier. OID).
В переводе на человеческий язык это означает, что протокол SNMP
определяет иерархическое пространство имен переменных, хранящих “инте-
ресные" параметры системы.
В осноаном SNMP-переменные содержат данные целого и строкового
типов, а также пустые значения. Данные базовых типов разрешается
объединять в последовательности, а каждую последовательность можно
многократно повторять, создавая таким образом таблицу. В большинстве
реализаций SNMP поддерживаются и другие типы данных.
Иерархия SNMP напоминает иерархию имен файловой системы. В ка-
честве символа-разделителя здесь используется точка, а каждому узлу
иерархии присваивается не имя. а номер. Для облегчения ссылок узлам
присваиваются также текстовые имена, но схема именования выходит за
рамки самой иерархии и определяется на высоком уровне (в принципе, это
похоже на связь между именами компьютеров и их IP-адресами).
К примеру, идентификатор 01D. соответствующий показателю общего
времени работы системы, выглядит так: 1.3.6.1.2.1.1.3. В более понятной
форме его можно записать следующим образом:
iso.org.dod. internet, mgmt. mib-2.system.sysUpTime
Верхние уровни иерархии SNMP носят искусственный характер и обычно
не содержат никаких полезных данных. По сути, интересная информация
появляется только на уровне iso.org.dod.internet.mgmt (OID равен 1.3.6.1.2).
Основная административная база данных SNMP для протоколов TCP/IP
(MlВ-1) определяет доступ к наиболее важным управляющим данным:
информации о системе, ее интерфейсах, преобразовании адресов и протоколах
(IP, ICMP, TCP, UDP и др.). В документе RFC1213 описана новая, более
полная версия этой базы, получившая название MIB-1I. Большинство
поставщиков, выпускающих SNMP-серверы, поддерживает MIB-1I.
В табл. 20.1 приведена выборка узлов иерархии из пространства имен MIB-II.
С76
Часть II Робота в сетях
Таблица 20.1. Некоторые идентификаторы из бозы M1B-II
OID1	Тип	Содрржоние
system.sysDescr	строка	Информация о системе; производитель, модель, тип ОС и тл.
system.sysLocation	строка	Физическое местонахождение компьютера
system.sysContact	строка	Информация о владельце компьютера
system.sysNamc	строка	Имя системы (обычно это полное DNS-имя)
Interfaces.ifNumber	целое	Количество имеющихся сетевых интерфейсов
intcrfeccs.ifTablc	таблица	Таблица с информацией о каждом интерфейсе
ip.ipForwarding	целое	1, если система является шлюзом, иначе 2
ip.ipAddrTable	таблица	Таблица данных IP-адресации (маски и тл.)
ip.ipRouteTablc	таблица	Системная таблица маршрутизации
icmp.icmplnRedirects	целое	Число полученных переадресуюших ICMP-паке- тов
icmp.icmpinEchos
tcp.tcpConnTable
udp.udpTable
целое
таблица
таблица
Число полученных пакетов команды ping
Таблица текущих TCP-соединений
Таблица с информацией о UDP-сокетах, через
которые серверы ожидают прием запросов
Относительно узла isc.org.dod.inteniet.mgmt.mib-2.
Помимо основной административной базы существуют базы для различ-
ных типов аппаратных интерфейсов и протоколов. Имеются также базы
данных по отдельным поставщикам и по конкретным изделиям.
MIB — это лишь соглашение об именовании управляющих данных. Для
того чтобы эта схема заработала, ее необходимо подкрепить программой-
агентом. которая будет обеспечивать соответствие содержимого SNMP-пере-
менных и текущего состояния устройства. Код для основной базы MIB
(в настоящее время MIB-II) поставляется с большинством SNMP-агентов
UNIX. Некоторые агенты разрешают подключать дополнительные базы
данных.
Операции протокола SNMP
В пространстве имен SNMP определены всего четыре базовые операции:
get (прочитать), get-next (прочитать следующий), set (записать) и trap
(прерывание).
Операции get и set — базовые операции чтения и записи данных на узле
иерархии, который определяется конкретным значением OID. Операция
get-next используется для последовательного прохода по базам MIB. а также
для чтения таблиц.
Прерывание (операция trap) — это неожиданное, асинхронное уведомле-
ние клиента о том, что на сервере произошло интересное событие. Определен
ряд стандартных прерываний, включая уведомления вида “я только что
включился”, сообщения об отказах и восстановлении сетевых каналов, а
также сообщения, связанные с различными проблемами маршрутизации и
аутентификации. Широко распространены и нестандартные прерывания,
например такие, которые просто используются для отслеживания значений
требуемых SNMP-переменных. Если эти значения выходят за границы
установленного диапазона, выдается соответствующее сообщение. Способ
определения получателей таких сообщений зависит от реализации агента.
Глово 20 Упровление сетями
677
Поскольку сообщения SNMP потенциально могут изменять информацию
о конфигурации компьютеров, необходим какой-то механизм 5ашиты.
Простейшая защита основана на концепцнн “имени сообщества" (community
name) Для тех, кто не страдает косноязычием, поясним: на языке разработ-
чиков стандарта это синоним слова “пароль”. Доступу только для чтения
соответствует один пароль, простите, “имя сообщества”, а доступу для
записи — другой.
Версия 3 стандарта SNMP включает методы управления доступом с
высокой степенью безопасности. Использование этих методов несколько
ограничивается возможностями сетевых аппаратных средств, но есть основа-
ния ожидать изменений в лучшую сторону.
RMON: база MIB для удаленного мониторинга
База RMON (remote monitoring — удаленный мониторинг) накапливает
данные об общих характеристиках сети (т.е. таких, которые не относятся к
какому-то конкретному устройству). Сетевые анализаторы или “зонды" могут
собирать информацию а загруженности и производительности сети. Полезные
данные группируются, предварительно обрабатываются, и их важная часть
доставляется на центральную станцию управления для анализа и графического
воспроизведения. Многие зонды имеют буферы для перехваченных пакетов
и могут работать подобно программе tepdump.
База RMON описана в документе RFC 1757. который был принят в
качестве чернового стандарта в 1995 году. База разделяется на девять “групп
RMON”. Каждая группа хранит собственный набор статистических данных.
Если сеть достаточно велика и имеет много глобальных соединений,
необходимо рассмотреть возможность приобретения зондов для снижения
SNMP-трафика через глобальные соединения. При наличии итоговых стати-
стических данных отпадет необходнмостъ в удаленном сборе первичных
данных. Многие мосты и маршрутизаторы поддерживают базы RMON и
хранят в них собственные статистические данные.
20.8. Агенты SNMP
Многие производители операционных систем и сетевого оборудования
поставляют свою продукцию с готовыми к использованию SNMP-агентами.
Пароль доступа только для чтения чаще всего равен “public”, а пароль доступа
для записи иногда задается как “private" или “secret”. Мы сталкивались со
многими производителями, использующими такое решение Это удобно для
системных администраторов, но также удобно и для хакеров. Тем, кто
планирует использовать SNMP, советуем сконфигурировать агентов так.
чтобы пароли и для чтения, и для записи было трудно угадать.
Операционные системы Solaris и HP-UX поставляются с неплохими
SNMP-агентами. UCD-агент системы FreeBSD находится в каталоге
/usr/ports/net/ucd-snmp. В стандартном дистрибутиве Red Hat поддержка
протокола SNMP отсутствует.
Ниже мы рассмотрим агентов систем Solaris н HP-UX, а затем — пакет
UCD, который рекомендуем использовать в системах, не имеющих собствен-
ных агентов.
б; и
Часть II. Робот о в сетях
SNMP-агент в Solaris
Solaris располагает солидными средствами управления сетями. В допол-
нение к довольно мощному SNMP-агенту система также обеспечивает
поддержку интерфейса DMI.
Главным SNMP-агентом является демон /usr/lib/snmp/snmpdx, конфигу-
рация которого хранится в файле /etc/snmp/conf/snmpd.conf. В этот файл
можно записывать значения многих переменных MIB. а также основные
параметры конфигурации агента. Например, можно задать строку описания
системы (sysdescr), узлы, которым требуется посылать уведомляющие
сообщения (параметр trap), и пароли для чтения и записи (read-commu-
nity, write-community). После изменения содержимого конфигурацион-
ного файла уничтожьте и запустите заново демон snmpdx. чтобы внесенные
изменения вступили в силу.
Демон snmpdx извлекает информацию с безопасности из файла
/etc/snmp/conf/snmpdx.acl. В этом файле перечислены IP-адреса компьютеров,
которым разрешен доступ к локальному SNMP-агенту. Каждый набор
компьютеров может иметь собственный пароль (“имя сообщества”) для
чтения и записи данных. Такие возможности существенно повышают
безопасность протокола SNMP. К сожалению, по умолчанию все ограничения
отключены.
В своем дистрибутивном варианте система Solaris на этапе начальной
загрузки запускает два процесса, связанных с интерфейсом DMI. Первый —
это демон /usr/lib/dmi/dmispd. который непосредственно отвечает на DM I-за-
просы. Второй демон — /usr/lib/dmi/snmpXdmid — преобразует SNMP-запросы
в формат DMI и передает их демону dinispd. Ответ последнего преобразуется
демоном snmpXdmid и возвращается обратно SNMP-серверу snmpdx. Параметры
преобразования SNMP/DMI определяются содержимым файлов, находящихся
в каталоге /var/dmi/map. По умолчанию заданы два вида преобразования.
Если дополнительные преобразования не планируются, то нет смысла
запускать демон snmpXdmid.
Если в системе отсутствуют средства DMI-управления или их использо-
вание не планируется, следует запретить запуск всех DMI-пропессов при
начальной загрузке системы. Для этого необходимо переименовать файл
/etc/rc3.d/S77dmi в /etc/rc3.d/s77dmi. Если требуется отключить демон
snmpXdmid, переименуйте его конфигурационный файл snmpXdmid.conf в
snmpXdmid.conf.orig.
SNMP-агент в HP-UX
Одним из самых удачных программных средств, разработанных компа-
нией Hewlett-Packard для управления сетями масштаба предприятия, считается
пакет HP OpenView. Так как эта компания — признанный лидер в разработке
средств управления сетями, то факт включения SNMP-агента в дистрибутив
HP-UX не стал большой неожиданностью. Вот только вместо единого агента
в HP-UX используется набор специализированных “субагентов”. Такая схема
позволяет разработчикам добавлять необходимые субагенты для новых
аппаратных или программных компонентов без изменения всей системы.
Главным агентом является демон /usr/sbm/snmpdm. но он никогда не
запускается непосредственно. Этой цели служит сценарий /usr/sbm/siimpd.
который кроме агента snmpdm запускает нужные субагенты для сбора данных
Глово 20 Упровление сетями
679
Агент читает свои установки из файла /etc/SnmpAgent.d/snmpd.conf. Кроме
того, конфигурационные параметры могут быть заданы в строке запуска
сценария snmpd.
В файле snmpd.conf можно использовать только пять ключевых слов.
Рассмотрим пример:
# Конфигурация SNMP-агента для узла disascer.xor.com
де с-communi ty-name: ro-community
set-community-name: Dfij4kL.2nG
trap-aest: jaguar.xor.com
crap-dest: ov.xor.com
location; First floor lab machine room
contact: root@disaster.xor.com
Ключевые слова get-community-name и set-community-name задают
пароли для чтения и записи данных. Выражений, определяющих пароли,
может быть несколько, однако управление доступом не должно различаться
для разных групп компьютеров. Любой пароль, указанный в любой инструк-
ции set-community-name, действителен для любой поддерживаемой опе-
рации чтения или записи.
Ключевым словом trap-dest задается имя или IP-адрес SNMP-клиента,
который будет принимать уведомления о прерываниях. Клиентов может быть
несколько, и уведомления посылаются во все пункты назначения.
Ключевые слова location и contact задают значения объектов
sysLocation н sysConiact базы
С помощью флага -т можно контролировать объем журнальной инфор-
мации. выдаваемой сценарием snmpd:
snmpd -m маска
Аргумент маска должен представлять собой побитовое объединение
флагов, выбираемых из табл, 20.2.
Тоблица 20.2. Флоги для сценория snmpd в HP-UX
Флаг	Функция
О	Отключить журнальную регистрацию
1	Регистрировать отказы в аутентификации
2	Регистрировать ошибки
4	Регистрировать запросы на конфигурирование
8	Регистрировать SNMP-транзакции
16	Регистрировать добавляемые объекты
32	Распечатывать все пакеты в шестнадцатеричном виде
64	Регистрировать сообщения о трассировке
К сожалению, в HP-UX SNMP-агент не использует систему Syslog.
Стандартный файл регистрации — /Yar/adm/snmpd.log; другой файл можно
задать с помощью опции -1.
680
Чость II. Робота в сетях
SNMP-агент UCD
После выхода первого стандарта SNMP в университете Карнеги-Меллона
и Массачусетском технологическом институте были разработаны реализации
протокола. Университетская реализация получилась более полной и быстро-
действующей. поэтому она стала стандартом де-факто для UNIX-систем
После прекращения разработки SNMP-продуктов в университете Карнеги-
Меллона работы продолжили специалисты Калифорнийского университета в
Дэвисе (University of California at Davis, UCD).
В настоящее время дистрибутив UCD широко распространен в качестве
бесплатной реализации протокола SNMP для UNIX. Мы настоятельно
рекомендуем использовать этот пакет в тех системах, которые не имеют
собственных SNMP-агентов. В состав пакета входит SNMP-агент, несколько
утилит командной строки и даже библиотека для разработки SNMP-прило-
жений. Ниже мы рассмотрим работу самого агента, а об утилитах поговорим
чуть позже. Последнюю версию пакета можно получить на Web-узле
ucd-snmp.ucdavis.edu*.
Как н в других реализациях SNMP, UCD-агент собирает данные о
локальном компьютере и предоставляет их SNMP-менеджерам по сети. По
умолчанию инсталлируются базы Ml В. содержащие статистические данные
об использовании сетевого интерфейса, памяти, дисков, процессов и цен-
трального процессора. Возможности агента достаточно велики, так как он
может запустить любую UNIX-команду и представить ее выходные данные
в качестве SNMP-ответа. Это позволяет посредством протокола SNMP
осуществлять мониторинг практически любых событий, происходящих в
системе.
По умолчанию агент инсталлируется под именем /usr/sbin/snmpd. Обычно
он запускается на этапе начальной загрузки системы и считывает параметры
своей конфигурации из файлов, находящихся в каталоге /etc/snmp. Наиболее
важный из этих файлов — snmpd.conf; он содержит большинство конфигура-
ционных параметров и описание множества доступных методов сбора данных.
При разработке пакета его авторы полагали, что пользователи должны
редактировать только файл snmpd.local.conf. Но на практике приходится хотя
бы один раз изменять и файл snmpd.conf, чтобы отключнть те методы сбора
данных, использование которых не планируется.
Сценарий configure пакета UCD позволяет задать используемый по
умолчанию журнальный файл и ряд других локальных параметров. С помо-
щью опции -I, указываемой при вызове демона snmpd. можно выбрать другой
журнальный файл, а посредством опции -s организуется направление
журнальных сообщений в систему Sysiog. Перечень наиболее важных опций
демона snmpd приведен в табл. 20.3. Мы рекомендуем всегда задавать опцию
-а. При поиске неисправностей удобно применять опции -V. -d и -D, которые
позволяют получать более подробную информацию о происходящих в системе
событиях.
Следует заметить, что существует большое количество полезных модулей
Perl для SNMP. Тем, кто собирается писать собственные сценарии управления
сетью, рекомендуем обратиться в архив С PAN*’ за примерами.
С конца 2000 г. проект перешел под управление компании SourceForge и стал называться
Net-SNMP. Изменилось и местонахождение Web-узла; теперь его адрес — net-snmp.source-
forge.net. — Примеч. ред.
Архив CPAN (Comprehensive Perl Archive Network — глобальная сеть архивов Perl-программ)
содержит великолепную коллекцию полезных модулей Perl. Обращайтесь по адресу
www.cpan.org.
Глово 20. Упровление сетями
681
Тоблицо 203, Опции демоно snmpd гокето UCD
	Опция	Функция^	_________У « * , 1___________
-	I файл Направлять журнальную информацию в файл
-	а	Регистрировать адреса всех SNMP-соединений
-	d	Регистрировать содержимое каждого SNMP-пакета
-	V	Включить режим подробного описания событий
-	D	Регистрировать отладочную информацию
-	h	Отображать все аргументы демона snmpd
-	Н	Отображать все директивы конфигурационного файла
-	А	Добавлять данные и журнальный файл, а не перезапись)нать его
-	s Направлять peiистрапионные сообщения в систему Syslog
20.9.	Программы управления сетью
Мы начнем этот параграф с рассмотрения простейших SNMP-инстру-
ментов: утилит пакета UCD. С их помощью удобно проверять значения
конкретных идентифтткаторов 01D. Затем мы познакомимся с программой
MRTG, строящей графики изменения SNMP-переменных, и системой
мониторинга событий NOCOI.. В «вершение приводятся рекомендации
относительно того, на что следует обратить внимание при покупке коммер-
ческих систем.
Утилиты пакета UCD
Даже если система поставляется с собственным SNMP-сервером, для
полноценного администрирования понадобится скомпилировать и инсталли-
ровать семь клиентских утилит пакета (JCD. перечисленных в табл. 20.4.
Тоблицо 20 4 Утилиты покета UCD
РТ-
УТИЛ ИТО
snmpgel
snmpgctnext
snmpset
snmp table
snmp translate
snmptrap
snmpwalk
Назначение
Получает от агента значение SNMP-переменной
Получает значение следующей переменной последовагельности
Передаст агенту значение SNMP-иерсменной
Получает таблицу 1Начений SNMP-переменных
Осуществляет поиск идентификаторов OID и их описаний в иерархии
базы MIB
Генерирует сообщение о прерывании
Просматривает базу М1В, начиная с заданного идентификатора OID
Перечисленные утилиты чрезвычайно удобно использовать в сценариях.
Например, часто требуется сценарий, в котором данные, полученные утилитой
snmpgel, каждые несколько минут сохраняются в текстовом файле. (Составить
расписание работы утилиты snmpget позволит демон сгоп, см. главу 9 1
Примечательна также утилита snmpwalk. Начав с указанного идентифи-
катора OID (или. по умолчанию, с начала базы MIB), она выполняет в цикле
запрос get-next В результате формируется полный список доступных иден-
тификаторов 01D и их значений Ниже приведен пример выполнения утилиты
6С2
Чость II. Робота в сетях
snmpwalk для компьютера jaguar (аргумент public задает пароль, или “имя
сообщества”):
% sump-walk jaguar public
system.sysDescr.О = Linux jaguar 2.2.12-20 #1 Mon Sep 27 10:40:35 EOT 1999
system.sysUpTime.O - Timeticks: (88516617} 10 days, 5:52:46.17
system.sysName.O - jaguar
system. sysLocation. 0 = Second Floor Machine Room
interfaces.ifNumber.0 = 2
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.iflndex.2 ” 2
interfaces.ifTable.ifEntry.ifDescr.1 =- "loO" Hex: 6C 6F 30
interfaces.ifTable.ifEntry.ifDescr.2 — "ethO" Hex: 65 74 68 30
interfaces.. ifTable . if Entry. ifType. 1 = sof twareLoopback (24)
interfaces.ifTable.ifEntry.ifType.2 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifMtu.l ~ 3924
interfaces.ifTable.ifEntry.ifMtu.2 = 1500
interfaces.ifTable.ifEntry.iflnOctets.l = 12590602
interfaces.ifTable.ifEntry.iflnoctets.2 = 2287718531
interfaces.ifTable.ifEntry.ifInUcastPkts.1 • 75576
interfaces.ifTable.ifEntry.ifInUcastPkts-2 = 79730602
interfaces.ifTable.ifEntry.ifInErrors.1 = 0
interfaces.ifTable.ifEntry.ifInErrors.2 - 218
interfaces.ifTable.IfEntry.ifOutOctets.l = 12591593
interfaces.ifTable.ifEntry.ifOutOctets.2 = 3374588125
Утилита отобразила основную информацию о системе и статистические
данные о работе двух* сетевых интерфейсов. 1о0 и ethO. Вывод утилиты
snmpwalk может содержать сотни строк; их количество зависит от поддержи-
ваемых агентом баз М1В
MRTG: многомаршрутный визуальный анализатор трафика
Программа MRTG (Multi-Router Traffic Grapher — многомаршрутный
визуальный анализатор трафика), созданная Тобиасом Утикером (Tobias
Oe(iker) из Швейцарского федерального технологического института в Цю-
рихе, собирает данные SNMP и строит графики их изменения во времени.
Программа написана преимущественно на языке Perl. Она оказывает
неоценимую помощь в анализе использования системы и сетевых ресурсов.
Программа MRTG периодически запускается демоном сгоп и может
получать данные от любого источника SNMP. При каждом запуске получен-
ные данные сохраняются и строятся новые графики.
Эта свободно распространяемая программа имеет ряд приятных особен-
ностей. Во-первых, она использует не требующую административного вме-
шательства базу данных фиксированного размера, в которую записываются
только сведения, необходимые для создания трафиков. Например, программа
MRTG умеет сохранять одну выборку для каждой минуты дня, для каждого
часа недели и для каждой недели года Такая схема укрупнения позволяет
предоставлять пользователям важную информацию, не требуя хранения
несущественных деталей и затрат времени на администрирование базы
данных.
Во-вторых, программа MRTG способна записывать значения и отобра-
жать графики их изменения во времени для любой SNMP-переменной. Вместе
с SNMP-агентом пакета UCD программа MRTG обеспечивает мониторинг
практически всех системных и сетевых ресурсов.
Глово 20 Управление сетями
683
На рис. А приведены примеры графиков, созданных программой MRTG.
Эти графики характеризуют трафик, проходящий через сетевой интерфейс в
течение дня и недели.
Идеи, заложенные в программе MRTG, получили развитие в новой
системе RRDtool. созданной тем же автором. Концепция системы та же
самая, но средства укрупнения данных и графические возможности усовер-
шенствованы. Правда, в отличие от программы MRTG, система RRDtool не
имеет собственных методов сбора информации. Данные должны быть
получены другими программами.
На сегодняшний день сбор данных для системы RRDtool лучше всего
осуществляет программа Cricket, написанная Джеффом Алленом (Jeff Allen).
Она не ограничивается только данными SNMP и способна получать
информацию почти от любого сетевого источника. Программа написана на
Perl и может быть легко модифицирована для обработки новых источников
данных.
На Web-странице Тобиаса Утикера (ee-staff.ethz.ch/~oetiker) находятся
ссылки на текущие версии программ MRTG RRDtool п Cricket.
2000.0 k
1500.0 k
1000.0 k
500.0 k
0.0 k
6	8	10 12 14 16 18 20 22	0	2	4	6	8	10 12 14
Рис. А. Примеры грофиков прогроммь MRTG
NOCOL: интерактивный сетевой административный центр
NOCOL (Network Operation Center On-Line — интерактивный сетевой
административный центр) представляет собой систему управления событиями.
Эта система не поможет администратору выяснить, насколько возросла
загруженность сети за последний месяц, зато она способна уведомить о крахе
Web-сервера. Система может посылать сообщения на пейджеры обслуживаю-
щего персонала (или по электронной почте), информируя о самых разных
событиях.
В дистрибутив входят программы мониторинга, которые следят за
различными “проблемными" компонентами сети. Можно создавать дополни-
тельные мониторы на языках Perl или С. Базовые методы оповещения
пользователей таковы: отправка сообщения по электронной почте, создание
Web-страницы, отображение статусной информации посредством функций
библиотеки curses и сброс сообщения на пейджер через модем. Как и в случае
с8Х
Чость II Робота в сетях
с программами мониторинга, разрешается дополнять этот список собствен-
ными методами.
Тем. кто не может себе позволить приобрести коммерческие средства
управления сетью, мы настоятельно рекомендуем использовать систему
NOCOL. Она очень хорошо работает в сетях, где число узлов и контроли-
руемых устройств не превышает 100. За дополнительной информацией
обращайтесь по адресу www.netplex-iech.com'.
Коммерческие системы сетевого управления
Сотни компаний продают программное обеспечение для управления
сетями, и каждую неделю на рынке появляются новые игроки. Мы не будем
рекомендовать конкретные новейшие продукты (за время подготовки книги
к печати все может измениться), а попробуем сформулировать требования к
системе управления сетью.
Возможность получения различных видов данных. Для систем управления
сетью важно уметь получать не только данные SNMP. Многие пакеты
позволяют принимать информацию от большинства других сетевых служб,
например выполнять SQL-запросы, обращаться к DNS и Web-серверам.
Качество пользовательского интерфейса. Дорогостоящие системы обычно
позволяют выбирать между имеющимся графическим интерфейсом или
Web-интерфейсом. Пакеты, разработчики которых учитывают рыночную
конъюнктуру, поддерживают XML-шаблоны для представления данных.
Важно, чтобы интерфейс позволял представлять информацию наглядно и
понятно
Стоимость. Некоторые пакеты имеют завышенную цену. Пакет OpenView
компании Hewlett-Packard является одним из наиболее дорогостоящих, но в
то же время одним из самых распространенных. Для ряда корпораций
престижно, что их сети управляются высококачественной коммерческой
системой. Если для вашей организации это не так важно, обратите внимание
на бесплатное программное обеспечение вроде MRTG или NOCOL.
Автоматическое обнаружение узлов Ряд систем обладает возможностью
“обнаруживать" сеть Отправляя широковещательные ping-пакеты, выполняя
SNMP-запросы, просматривая таблицы маршрутизации и обращаясь к службе
DNS, они способны идентифицировать все компьютеры и устройства в сети.
Как правило, данная функция реализована достаточно хорошо, но она не
всегда справляется со сложными сетями или сетями со ‘"строгими” бранд-
мауэрами.
Средства отчета. Многие программы способны отправлять предупрежде-
ния по электронной почте, выдавать сообщения на пейджеры и автоматически
генерировать уведомления для популярных систем слежения за ошибками.
Убедитесь, что выбранная платформа позволяет гибко настраивать систему
отчетности. Кто знает, какие электронные устройства появятся в ближайшие
годы?
Возможности конфигурирования. Некоторые производители в своих раз-
работках пошли гораздо дальше простого мониторинга и выдачи сообщений.
Их системы позволяют управлять конфигурацией компьютера или устройства
Например, система Cisco Works посредством специального интерфейса
В настоящее время компания Netplex Technologies предлагает систему следующего поколе-
ния: SNIPS (System and Network Integrated Polling Software — интегрированная программа
опроса системы и сети). — Примеч. ред.
Глово 20 Упровление сетями
685
разрешает пользователю изменять конфигурацию маршрутизатора. Поскольку
данные о конфигурации устройства необходимы для глубокого анализа
сетевых проблем, мы предполагаем, что в будущем большинство программ
будет располагать средствами изменения конфигурации сетевых компонентов
20.10.	Рекомендуемая литература
•	Cisco Online. Internetworking Technology Overview: SNMP. http://www.cis-
co.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.hUn
	Hunt. Craig, and Gigi Estabrook. TCP/IP Network Administration, Second
Edition. Sebastopol: O'Reilly & Associates. 1998.
•	Stallings, William. Snrnp. Snmpv2, Snmpv3, and Rmon 1 and 2, Third Edition.
Reading, MA: Addison'Wesley. 1999.
Также могут оказаться полезными перечисленные ниже документы RFC.
Вместо названий мы приводим краткое описание их содержимого, так как
названия представляют собой не вполне понятный набор модных словечек
и жаргона SNMP.
•	RFC 1155 — характеристики пространства данных SNMP (типы данных
и т.п.).
•	RFC1156 — определения базы Ml В-i (описание идентификаторов OID).
•	RFCI157 — протокол SNMP.
•	RFC12I3 — определения базы M1B-II (описание идентификаторов O1D).
•	RFC 1901-RFC 1910 — протокол SNMPv2.
•	RFC2011	—	база	Ml В	для	протокола	1Р в SNMPv2.
•	RFC2O12	—	база	Ml В	для	протокола	ГСР в SNMPv2.
•	RFC2013	—	база	Ml В	для	протокола	L1DP в SNMPv2.
•	RFC202I	—	база	RMON версии 2 с использованием SMIv2.
•	RFC2570 — введение в протокол SNMPvj.
Ь8б
Чость II Роботе в сетях
21
Безопасность
Разработчики операционной системы UNIX не придавали особого
значения вопросам зашиты. и по этой причине ни одну из UNIX-систем
нельзя сделать по-настоящему безопасной. На протяжении всей истории
UNIX-систем их регулярно взламывают, портят, увечат, а также незаконно
присваивают и модифицируют данные. С появлением сети Internet начался
новый этап этой “холодной войны”
Кое-что для повышения надежности UNIX-системы, разумеется, сделать
можно. Но полная нирвана безопасности все же недостижима, ибо в модели
UNIX есть несколько фундаментальных изъянов, которые невозможно устра-
нить.
•	ОС UNIX ориентирована прежде всего на удобство в применении, что
отнюдь не предполагает естественность и простоту ее зашиты. Эту систему
разрабатывали исследователи для исследователем, и концепция UNIX
заключается в обеспечении удобного манипулирования дагшыми в сетевой
многопользовательской среде.
•	Стратегия защиты в UNIX, по сути. предполагает всего два статуса
пользователя: пользователь, ие обладающий привилегиями, и суперполь-
зователь Такая возможность UNIX, как выполнение программ с уста-
новленным битом смены идентификатора пользователя, обеспечивает
привилегированный доступ ко всем вычислительным ресурсам системы
При этом из-за незначительных огрехов в защите может быть поставлено
под угрозу нормальное функционирование системы как таковой.
•	Большинство административных функций реализовано вне ядра, поэтому
к ним можно без особого труда получить доступ с целью просмотра и
внесения изменении. Это открывает широкое поле деятельности для
хакеров.
Первое издание этой книги вышло в свет всего несколько месяцев спустя
после появления в сети Internet знаменитого “червя” (1988 г.). Это событие,
которое застало врасплох очень многие организации (в том числе и пати
Гпово 21 Безопосность
687
университет), получило широкую огласку. Тогда казалось, что Роберт
Моррис-младший (Robert Morris. Jr.), автор программы-**червя’*, навлек
страшнейшее бедствие на все сообщество Internet.
На самом деле "червь" нанес лишь незначительный ущерб, зато
бдительность пользователей глобальной сети возросла на порядок. Все мы
просто еше раз вспомнили о народной мудрости: чем выше заборы, тем
добрее соседи. В результате появился целый ряд прекрасных инструменталь-
ных средств для системных администраторов (а также была основана
организация, предназначенная для борьбы с подобным вредительством).
В системе защиты UNIX существует множество всем известных изъянов,
которые никогда не будут устранены, и просчетов, которые одни произво-
дители устранили, а другие — нет. Помимо этого, многие организации на
одну-две версии программного обеспечения отстают: либо по причине
сложности локализации, либо потому, что они не заключили с поставщиком
договор о сопровождении системы. Если производитель заткнул маленькую
дырочку в системе защиты, это не означает, что окно для взлома исчезнет
на следующий же день.
Раньше считалось, что по мере выявления и устранения брешей
безопасность операционной системы UNIX будет непрерывно повышаться.
Суровая реальность оказалась иной. Сложность системного программного
обеспечения стремительно растет, хакерская деятельность все больше приоб-
ретает черты организованной преступности, компьютеры оказываются все
более тесно связанными посредством сети Internet. Война переходит в новые
измерения, и, похоже, победителей не будет.
Запомните такую формулу:
г	1
Безопасность =----------------
1,072 х Удобство
Чем безопаснее система, тем труднее в ней работать пользователям.
21.1.	Семь правил защиты
Эффективная система безопасности должна базироваться на здравом
смысле. Она во многом напоминает борьбу с грызунами в доме. Вот семь
правил, которые при этом следует соблюдать.
•	Не оставляйте на ночь на кухонном столе то. что может привлечь
грызунов. Лучшие лакомства для них — сыр и масло.
•	Заткните все дыры, через которые грызуны обычно попадают в дом. Если
они не залезут внутрь, то не смогут вас побеспокоить.
•	Позаботьтесь о том. чтобы в доме не было мест, где грызуны могли бы
вывести потомство. Мыши любят устраивать гнезда в кучах тряпья.
•	Расставьте вдоль стен, в тех местах, где вы хотя бы раз видели мышь,
мышеловки.
•	Каждый день проверяйте мышеловки, меняйте приманки и выбрасывайте
дохлых грызунов. В заполненные мышеловки грызуны уже не попадают,
в частности, из-за плохого запаха.
•	Избегайте ядовитых приманок. Отравленные грызуны могут навсегда
остаться в стенах дома. Кроме того, есть риск, что отравится ваша собака.
Лучше всего пользоваться традиционными мышеловками
•	Заведите кота!
688
Чость II. Работе в сетях
Этими же семью правилами (с незначительными корректировками)
можно с успехом руководствоваться при организации защиты UNIX-систем.
Вот как они звучат применительно к UNIX.
•	Не оставляйте без присмотра файлы, которые могут представлять интерес
для хакеров и нс в меру любопытных сослуживцев. Коммерческие тайны,
персональные досье, бухгалтерские ведомости, результаты выборов и
т.д. — за всем этим нужен глаз да глаз. Гораздо надежнее зашифровать
данные, чем просто пытаться предотвратить к ним несанкционированный
доступ.
В организации должен существовать порядок работы с секретной
информацией. Некоторые рекомендации по этому поводу даны в главе 27
и документе RFC2196.
•	Затыкайте “дырки”, через которые хакеры могут получить доступ к
системе. Читайте бюллетени фирм-производителей и списки рассылки
по вопросам защиты, чтобы своевременно узнавать о выходе “заплат".
Отключите ненужные сервисы.
•	Сделайте так. чтобы в системе не было мест, где хакеры могли бы
закрепиться. Хакеры часто вламываются в одну систему, а затем
используют ее как базу для операций по взлому других систем.
Анонимные FTP-каталоги с возможностью записи, групповые учетные
записи, учетные записи с плохо подобранными паролями — вот основные
уязвимые места.
•	Устанавливайте ловушки для обнаружения фактов или попыток вторже-
ния. Такие средства, как tripwire, tcpd и crack (описаны в параграфе 21.7).
помогут предупредить возможные проблемы.
•	Следите за отчетами, которые генерируются этими программами. Незна-
чительная проблема, проигнорированная в отчете, к моменту получения
следующего отчета может перерасти в катастрофу.
•	Учитесь защищать UNIX-системы своими силами. Иначе вам не изба-
виться ог различного рода высокооплачиваемых •‘консультантов” по
вопросам безопасности, которые будут пугать вас и ваших руководителей
леденящими душу рассказами о том, насколько беззащитны ваши
системы. Такие специалисты обучены грамотно доказывать, почему вам
нужно вложить “всего” 50000$ в обеспечение полной безопасности
системы.
К сожалению, после таких благодетелей внутри системы часто остаются
дохлые мыши, из-за которых производительность работы пользователей
падает до нуля. Так что защита системы должна базироваться на
традиционных технологиях и здравом смысле.
•	Постоянно следите за тем, не появились ли отклонения от нормального
хода работы системы. Обращайте внимание на все необычное, например
на непонятные журнальные сообщения или изменение характера исполь-
зования какой-либо учетной записи (резкое усиление активности, работа
в необычное время, работа во время отпуска владельца учетной записи)
2L2. Слабые места в системе безопасности
В последующих параграфах рассматриваются некоторые наиболее распро-
страненные проблемы, связанные с безопасностью UNIX-систем, и стандарт-
ные контрмеры, позволяющие избежать этих проблем. Но прежде чем
Гпово 21. Безопосность
689
погрузиться в детали, необходимо взглянуть на ситуацию в целом и определить
основные источники неприятностей.
•	Человеческий фактор. Пользователи (и администраторы) системы часто
являются ее слабейшим звеном. Например, компания America Online
печально прославилась тем. что ее многократно атаковали хакеры,
притворявшиеся служащими компании. Они посылали письма потенци-
альным жертвам с просьбой выслать пароли для “системного теста” или
“плановой проверки учетной записи”. Наивные пользователи часто
выполняли такие просьбы (некоторые до сих пор так делают).
Есть масса разновидностей подобного шарлатанства. Одна из задач
системного администратора состоит в обучении пользователей правилам
техники безопасности. Многие пользователи, начиная работать в Internet,
часто не подозревают, сколько там всякого жулья. Научите их выбирать
хорошие пароли и хранить их. а главное — никогда не общаться с
незнакомцами! Не забудьте в своих наставлениях упомянуть об неэлек-
тронных средствах коммуникации: в умелых руках телефон тоже может
оказаться опасным оружием.
•	Ошибки в программах. За много лет в программном обеспечении UNIX
(включая сторонние программы, как коммерческие, так и бесплатные)
было выявлено несметное число ошибок, связанных с безопасностью.
Используя незаметные программистские просчеты или архитектурные
зависимости, хакерам удавалось манипулировать системой по своему
усмотрению. Что может сделать в этом случае администратор? Немногое,
по крайней мерс до тех нор. пока ошибка не будет выявлена, а
разработчик не исправит ее или не выпустит "заплату” Быть в курсе
последних событии — святая обязанность администратора.
•	Открытые двери. Многие компоненты программного обеспечения можно
сконфигурировать в режиме полной или не очень полной безопасности.
К сожалению, по умолчанию чаще всего принимается второй вариант.
Хакеры вламываются в системы, иезуитски эксплуатируя функциональ-
ные возможности, с миссионерской щедростью предоставленные разра-
ботчиками в надежде сделать работу пользователей удобнее и гуманнее:
учетные записи без паролей, глобальный совместный доступ к жестким
дискам и т.д. и т.п. Одна из самых важных задач, связанных с
обеспечением безопасности системы, — убедиться в том. что, заботясь о
благополучии пользователей, вы не пригласили на вечеринку монстра в
маскарадном костюме.
Проще всего устранить проблемы последней категории, хотя их может
быть очень много и не всегда очевидно, что именно следует проверять.
Большая часть усилий, затраченных за несколько последних лет на разработку
программных средств защиты, была связана с анализом причин, по которым
система может непреднамеренно оказаться открытой для вторжений. Такие
программы, как. например, COPS (описана в параграфе 21.7), помогают
сделать процесс аудита быстрым и автоматизированным.
21.3.	Проблемы защиты файла /etc/passwd
В файле /etc/passwd (в некоторых системах также в файле /etc/shadow)
содержатся сведения о том, кто может входить в систему и что он при этом
имеет право в ней делать. Такой файл следует рассматривать как передовую
690
Чость II Работе а сетях
линию зашиты системы от захватчиков. Его нужно вести с особой тщатель-
ностью. стараясь не допускать ошибок и не загромождать устаревшими
данными.
Подробнее о файле /etc/passwd можно узнать в главе 6.
Во FreeBSD файл /etc/passwd генерируется на основании файла /etc/mas-
tcr.passwd и не должен редактироваться напрямую. Тем не менее не помешает
в одинаковой мере защищать оба файла. О файле /ete/master.passwd
рассказывалось в параграфе 6.2.
Проверка и выбор паролей
Регулярно (желательно каждый день) проверяйте, все ли учетные записи
имеют пароль. В элементах файла /etc/passwd, содержащих описания псев-
докод ьзовател ей наподобие daemon (такие псевдо пользователи являются
владельцами некоторых системных файлов, но они никогда не регистрируются
в системе), в поле пароля должна стоять звездочка (*) Она не соответствует
ни одному паролю и, таким образом, предотвратит использование учетной
записи.
Существует несколько специализированных программных пакетов, кото-
рые обеспечивают проверку файла /etc/passwd на предмет наличия проблем,
связанных с безопасностью, хотя для поиска пустых паролей вполне
достаточно и такой команды":
perl -F: -апе ’print if not 5F[1];' /etc'passwd
Сценарии, выполняющий эту проверку и направляющий по электронной
почте результаты администратору, можно запускать посредством демона сгоп
Дополнительно обезопасьте себя с помощью сценария, который будет
ежедневно сверять файл /etc/passwd с его версией за предыдущий день (это
позволяет делать команда di(T) и сообщать о выявленных различиях. К тому
же вы получите возможность проверять правомерность внесенных изменений.
Доступ к файлам /etc/passwd и /etc/group следует организовать так, чтобы
их могли читать все пользователи, но право на запись имел только
пользователь root. Если в системе присутствует файл /ctc/shadow. он должен
быть недоступен пользователям Файл /etc/master.passwd во FreeBSD должен
быть доступен лишь суперпользователю.
В UNIX пользователи могут задавать собственные пароли. Это, конечно,
очень удобно, но влечет за собой массу проблем, связанных с безопасностью
Выделяя пользователям регистрационные имена, обязательно даггаите им
указания о том. как правильно выбрать пароль. Следует предупредить
пользователей о недопустимости задавать в качестве такового фамилии,
инициалы, имен детей и супругов, а также слова, которые можно найти н
словаре. Пароли, сконструированные на основе таких личных данных, как
номера телефонов и адреса, тоже достаточно легко поддаются расшифровке.
Рекомендуется выбирать пароль, состоящий не менее чем из восьми
знаков, при этом допускается использование цифр, знаков препинания, а
также прописных и строчных букв. Бессмысленные сочетания знаков, слогов,
первые буквы слов легко запоминаемой фразы — вот самые лучшие пароли.
При этом легко запоминаемая фраза не должна быть одной из широко
Для ее выполнения требуется наличие интерпретатора Perl версии 5 или выше
Ггово 21. Безопосность
□ У1
распространенных. Лучше придумать собственную. Совет по выбору фраз
приводился в параграфе 3.3.
Во многих системах значащими являются лишь первые 8 символов
пароля. Остальные просто игнорируются. Этот вопрос рассматривался в
параграфе 6.1.
Пароли обычно меняются с помощью команды passwd. Существует
множество ее эквивалентов, призванных заставить пользователей выбирать
более удачные пароли. Мы рекомендуем применять для этой цели известный
многим пакет npasswd, поддерживаемый Клайдом Хувером (Clyde Hoover) из
университета штата Техас Пакет можно найти по адресу
http://www.utexas.edu/cc/unix/sofiware/npasswd
ф
В Solans входит версия программы passwd, заставляющая пользователей
придерживаться определенных правил, например не выбирать в качестве
паролей свои регистрационные имена. Правила построения паролей задаются
в файле /etc/default/passwd.
Модель аутентификации в Red Hai основана на подключаемых модулях
аутентификации (Pluggable Authentication Modules, РАМ). В связи с этим
команда passwd подчиняется набору правил имеющегося модуля, описанных
в файле /etc/pam.d/passwd. Получить более подробную информацию о модулях
РАМ можно по адресу
http://parc.power.nei/morgan/Linux-PAM/index.html
Теневые пороли
Каждый элемент файла /etc/passwd состоит из семи полей: второе поле
содержит строку, которая представляет собой зашифрованный пароль поль-
зователя. Для того чтобы могли работать такие команды, как Is и ей подобные,
к файлу /etc/passwd должны иметь доступ для чтения все пользователи Таким
образом, зашифрованная строка пароля доступна каждому пользователю
системы. Злоумышленнику ничего не стоит представить в зашифрованном
виде целый словарь или отдельные слова и провести сравнение с указанным
полем во всех элементах файла /etc/passwd При совпадении сравниваемых
объектов злоумышленник получает в свои руки пароль.
Подробнее об отгадывании паролей рассказывается в параграфе 21.7.
Насколько это опасно? В 80-е гг. существовал по крайней мере один
способ очень быстрой расшифровки паролей’, но рядовому хакеру приходи-
лось довольствоваться библиотечной функцией cryptO”, для того чтобы
шифровать слова из словаря для их последующего сравнения. Но в 80-е гг.
“быстродействующий" компьютер мог выполнять лишь порядка нескольких
сотен операций шифрования в секунду. В 1998 г. Джон Гилмор (John Gil more)
из организации Electronic Frontier Foundation и шифровальщик Пол Кошер
(Paul Kocher) взломали 56-разрядныи ключ DES методом “грубой силы" за
В 1984 г. Эви Немет с помощью суперкомпьютера НЕР нашла ключ к шифру Дифф и-Хелл-
мана, которым часто пользовались при работе по алгоритму DES (Data Encryption Stand-
ard — стандарт шифрования данных). Считалось, что алгоритм DES математически
надежен; тем не менее при использовании ключей малой ди ины степень секретности
значительно понижается.
Не следует путать ее с командой crypt, в которой используется другой, менее безопасный
алгоритм шифрования.
692
Часть II Работа в сетях
56 часов. Последние исследования показывают, что с помощью специализи-
рованного компьютера стоимостью 1 млн долларов можно взломать любой
56-раз рядный ключ DES за считанные часы.
Из этих далеко не обнадеживающих подсчетов вытекает настоятельная
необходимость в ограничении доступа пользователей к зашифрованным
строкам паролей. Самый распространенный способ — поместить пароли в
отдельный файл, который может читать только суперпользователь, а осталь-
ную часть файла /etc/passwd оставить без изменений. Файл, содержащий
информацию о паролях, называется “файлом теневых паролей” (часто он
имеет имя /etc/shadow). Большинство производителей UNIX-систем, в том
числе наших тестовых, реализует механизм теневых паролей.
В HP-UX для работы механизма теневых паролей требуется установить
вспомогательный программный пакет. Он содержит множество дополнитель-
ных средств защиты, но в то же время на порядок усложняет задачу
администрирования.
Групповые и совместно используемые учетные записи
Опасно, если учетная запись используется более чем одним человеком.
Регистрационные имена групп (например, guest или demo) — удобная лазейка
для хакеров, поэтому применять их не следует.
Нельзя допускать, чтобы пользователи делили учетные записи с членами
семьи или друзьями. Если маленькому Джонни нужно войти в систему, чтобы
решить домашнее задание, лучше предоставить ему для этой конкретной цели
отдельное имя. В случае злоупотребления проще удалить регистрационное
имя Джонни, чем поставить под удар папину учетную запись, особенно если
речь идет о правительственном учреждении.
Дополнительные комментарии по поводу совместно используемых учетных
записей даны в параграфе 27.1.
Во многих организациях учетная запись root является групповой. Это
опасно! Рекомендуем контролировать предоставление прав суперпользователя
с помощью программы sudo (см. параграф 3.4).
Устаревание паролей
Многие системы, поддерживающие теневые пароли, позволяют реализо-
вать механизм так называемого устаревания паролей, при котором пользова-
телей принуждают периодически менять таковые. На первый взгляд, это
хорошая идея, однако на практике ее реализация влечет за собой определен-
ные проблемы. Не всякому пользователю по душе замена пароля, поскольку
она требует определенных усилий по его поиску и запоминанию Обычно
для пароля выбирается простое слово, которое легко вводится и запоминается,
и когда подходит время замены, многие пользователи, не желая себя
утруждать, опять берут предыдущий пароль. Таким образом, дискредитируется
сама идея.
Тем не менее пароль пользователя root следует модифицировать регуляр-
но. При вводе он должен легко "скатываться” с пальцев, чтобы его нельзя
было угадать, следя за движением пальцев по клавиатуре. В нашей
организации многие работают с программой sudo, но к выбору пароля
суперпользователя мы все равно относимся с особой ответственностью.
Глово 21. Беэопосиость
693
Пользовательские интерпретаторы команд
Не используйте сценарий как средство для неконтролируемой (беспа-
рольной) регистрации в системе Вход в систему без пароля следует разрешать
только для прогона небольших не интерактивных утилит, таких как date, sync
и Ipq
Привилегированные учетные записи
Единственная отличительная черта пользователя root состоит в том, что
его идентификатор равен 0. Поскольку в файле /etc/passwd может быть
несколько элементов, для которых установлен этот идентификатор, то
существует и несколько способов входа в систему в качестве суперпользова-
теля.
Один из способов, который хакеры, получив доступ к интерпретатору
команд суперпользователя, широко применяют для открытия “черного
хода”, заключается в редактировании файла /etc/passwd посредством ввода в
него новых регистрационных имен с идентификатором пользователя, равным
0. Поскольку такие программы, как who и w, работают с регистрационным
именем, записанным в файле /etc/utmp. а не с идентификатором владельца
регистрационного интерпретатора, они не в состоянии разоблачить хакера,
который выглядит как рядовой пользователь, а на самом деле зарегистрирован
в системе в качестве суперпользователя.
Спасение от такого вероломства — применение мини-сценария, подоб-
ного тому, который используется для поиска учетных записей без паролей*:
perl -F: -ane 'print if not SF[2J:‘ /etc/passwd
Этот сценарий отображает любые элементы файла passwd. в которых
идентификатор пользователя не указан или равен 0 Сценарий можно
адаптировать для поиска в файле элементов с подозрительными идентифи-
каторами групп или идентификаторами пользователей, совпадающими с
идентификаторами руководящих сотрудников организации.
Пристального внимания заслуживают, кроме того, элементы файла
passwd, в которых нет имени пользователя либо вместо имени стоят знаки
препинания. Эти элементы могут показаться не имеющими смысла, но очень
часто они позволяют свободно входить в систему.
21.4.	Программы с установленным битом смены
идентификатора пользователя
Программы, которые запускаются с измененным идентификатором поль-
зователя. особенно те, для которых установлен идентификатор пользователя
root, являются источником проблем, связанных с безопасностью системы
Теоретически команды с установленным битом SU1D (Sei User ID — смена
идентификатора пользователя), поставляемые вместе с операционной систе-
мой, являются безопасными. Тем не менее огрехи в защите обнаруживались
в прошлом и. несомненно, будут обнаруживаться в будущем.
Самый надежный способ уменьшения количества проблем, вызванных
сменой идентификатора, — это сведение к минимуму числа программ с
установленным битом SUTD. Подумайте дважды, прежде чем инсталлировать
Для его выполнения требуется наличие интерпретатора Perl версии 5 или выше.
694
Чость II. Робото е сетях
такую программу, и вообще избегайте задания этого бита в собственных
программах.
Особенно подвержены всякого рода проблемам сценарии интерпретатора
команд. Они автоматически ставят систему под угрозу. Интерпретаторы
допускают множество способов настройки, поэтому их легко обмануть. Интер-
претатор. запускаемый для выполнения сценария, не всегда читает пользова-
тельские файлы конфигурации, но есть и другие способы воздействия на
него: посредством пользовательских переменных среды, содержимого теку-
щего каталога, способа вызова сценария и тд
Не существуют правила. гласящего, что программы с установленным
битом SUID должны запускаться от имени суперпользователя Если нужно
всего лишь ограничить доступ к файлу или базе данных, достаточно добавить
в файл /etc/passwd псевдо пользователя, единственное назначение которого
будет заключаться во владении требуемыми ресурсами. Следуйте обычным
соглашеггиям о добавлении псевдопользователей: используйте низкое значе-
ние UID. поставьте в поле пароля звездочку и сделайте начальным каталогом
псевдопользователя каталог /dev/null
Большинство систем позволяет отключать выполнение программ с
установленными битами SUID и SGID (Set Group ID — смена идентифика-
тора группы) в отдельных файловых системах с помощью опции -о nosuid
команды mount. Чаще всего это файловые системы, содержащие начальные
каталоги пользователей или смонтированные из ненадежных доменов.
Полезно периодически сканировать диски на предмет выявления новых
программ с установленным битом SUID. Хакер, взломавший систему, без
особых усилий может создать собственный командный SUID-интерпретатор
и утилиту, которая облегчит ему последующий вход в систему. Некоторые
из программ, описанных в параграфе 21.7, позволяют обнаруживать такие
файлы, но с этой задачей справится и простая команда find:
/usr/bin/find , -user root -perm -4000 -print 1
/bin/mail -s "Setuid root files" netadmin
В данном случае пользователю netadmin по электронной почте направля-
ется список всех файлов, при надлежащи]: пользователю root и имеющих
установленный бит SUID.
21.5.	Специальные права доступа
В UNIX-системах есть много файлов, для которых должны быть
установлены специальные права доступа, позволяющие предупреждать воз-
никновение проблем, связанных с безопасностью. Некоторые поставщики
выпускают дистрибутивы, в которых права доступа заданы в расчете на
собственггую “дружественную" среду разработки. Вашей системе такие
установки могут оказать ‘медвежью услугу".
В некоторых системах специальный файл /dev/kmem позволяет получить
доступ к виртуальному адресному пространству ядра Его используют те
программы (например, ps). которые работают со структурами данных ядра
Право чтения указанного файла должно предоставляться только его владельцу
и членам соответствующей группы Если необходимо получить доступ к файлу
нз определенной программы, для нее должен быть установлен идентификатор
группы, владеющей этим файлом (обычно это kmern). и бит SGID.
В прошлом некоторые поставщики беззаботно выпускали дистрибутивы,
в которых файл /dev/kmem был доступен для чтения всем пользователям. Это
Глово 21 Безопасность
695
создавало серьезную угрозу для безопасности системы, потому что опытный
программист, получив доступ к данным и буферам ядра, мог найти там
незашифрованные пароли. Если в вашей системе файл /dev/kmern могут читать
все пользователи, немедленно исправьте этот промах. Правда, после внесения
изменений может оказаться, что некоторые программы перестали работать.
Для них следует установить бит SG1D и идентификатор той i руппы, которой
принадлежит файл /dcv/kmcm.
Проверьте также права доступа к файлам /dev/drum н /dev/mein, если они
присутствуют в системе. Этн файлы позволяют получить свободный доступ
к системной области подкачки и физической памяти н потенциально так же
опасны, как и файл /dev/kmem.
Файлы /etc/passwd и /etc/group должны быть доступны для записи только
владельцу (пользователю root) и его группе. Режим доступа в данном случае
будет 644. Группа должна быть какой-нибудь системной группой (обычно
это daemon). Чтобы пользователи, не имея права записи в файл /etc/passwd.
могли изменять свои пароли, команда passwd (владельцем которой является
пользователь root) выполняется с установленным битом SU1D
Пользователи, относящиеся к категории “прочие", не должны иметь права
записи в каталоги, доступные по анонимному протоколу FTP. Такие каталоги
позволяют хакерам незаконно копировать программное обеспечение и яруше
важные файлы Если вы управляете FTP-архивом. допускающим добавление
в него файлов, не забывайте регулярно просматривать каталог добавлений.
Информация о безопасной настройке FTP-cepeepa приведена в параграфе 22.6.
При настройке анонимного FTP-сервера в каталог ~ftp/etc/passwd обычно
копируется усеченный файл паролей (с сохранением его структуры), что
позволяет правильно работать программе 1s. Не забудьте удалить зашифро-
ванные строки паролей.
Еше один потенциальный источник проблем — файлы устройств для
разделов жесткого диска Наличие права чтения и записи такого файла
равнозначно наличию аналогичных прав для любого элемента файловой
системы этого раздела. Право чтения-записи может иметь только ехперполь-
зователь. Члены группы иногда могут получать право чтения, что позволит
им выполнять резервное копирование. Для категории ‘‘прочие” права доступа
не устанавливаются.
21.6.	Различные аспекты защиты
Ниже рассматривается ряд дополнительных вопросов, связанных с
безопасностью. В основном внимание уделяется либо средствам, которые
могут быть полезны администратору, либо “антисредствам", которые при
отсутствии должного контроля могут стать оружием в руках хакеров.
Удаленная регистрация событий
Система Sysiog позволяет записывать журнальную информацию о про-
цессах ядра и пользовательских процессах в файл, рассылать ее членам группы
пользователей или передавать на другой компьютер сети. Рассмотрите вопрос
о выделении защищенного компьютера, который будет служить центральной
регистрационной станцией и выдавать сообщения о нарушении зашиты на
старый матричный принтер. Это помешает хакерам заметать следы путем
перезаписи и удаления журнальных файлов.
0 Более детальная информация о системе Sysiog содержится в гчаве 11
696
Чость II Роботе в сетях
Защищенные терминалы
Некоторые системы можно настроить так, чтобы суперпользователь мог
зарегистрироваться в системе только с определенных, ‘’защищенных” терми-
налов. Рекомендуется запрещать привилегированный вход в систему по таким
каналам, как модемы и сетевые псевдотерминалы.
Защищенные каналы обычно задаются в виде списка TTY-устроЙств или
с помощью специального ключевого слова в файле конфигурации. В Solaris
это файл /etc/default/login’, в HP-UX и Red Hat — /etc/securetty, а во
FreeBSD — /etc/ttys.
Файлы /etc/hosts.equiv и ~/. rhosts
В файлах hosts.equiv и '/.rhosts компьютеры определяются как админи-
стративно “эквивалентные” друг другу, что позволяет пользователям входить
в систему' (с помощью программы rlogin) и копировать файлы (посредством
программы гср) с одной машины на другую без ввода паролей . Раньше, в
эпоху беззаботного существования UNIX, подобная конфигурация была
широко распространена, но со временем все осознали потенциальную угрозу.
Мы рекомендуем отключать серверные демоны rshd и rlogind. читающие
файлы .rhosts и hosts.equiv В большинстве систем для этого достаточно
превратить в комментарии строки их вызова в файле /etc/inetd.conf. Конечно,
в отсутствие серверных демонов компьютер окажется недоступен программам
rlogin, rsh и гср. Но их всех с успехом заменяет более безопасный пакет SSH
(см. параграф 21.8).
В простейших случаях получить удаленный доступ к системе, где
отключен демон rlogind. позволит программа telnet. Но не забывайте о том,
что эта программа передает по сети пароль в незашифрованном виде.
Некоторые программы, используемые вместо rlogin (включая SSH!)T все
же обращаются к файлам .rhosts и /etc/hosts.equiv; если их неправильно
сконфигурировать. С целью повышения безопасности имеет смысл для
каждого пользователя (в том числе пользователя root) создать файлы
/etc/hosts.equiv и '/.rhosts нулевой длины, причем без права записи. Тогда
можно будет написать сценарии, определяющий, каково состояние файла, к
примеру. « 3 часа дня и не подвергался ли он изменениям. Это может очень
помочь при выслеживании нарушителей, пытающихся “взломать” систему.
Демоны rexd, rexecd и tftpd
Демон rexd в Solaris (он имеется и в других системах, включая HP-UX) —
это слабо защищенный сервер удаленного выполнения команд. Dh обычно
поставляется в отключенном виде (данная установка делается в файле
/etc/inetd.conf). и “будить” его не рекомендуется. Ни одна стандартная
системная программа к нему не обращается.
Демон rcxecd тоже предназначен для удаленного выполнения команд. Он
служит сервером для библиотечной функции гехесО- Запросы, посылаемые
демону, содержат в себе незашифрованные пароли, поэтому любая программа,
‘прослушивающая” сеть, способна узнать их и получить доступ к требуемой
системе. Этот демон также должен быть отключен.
Подойдет также файл /etc/default/su.
В некоторых системах эти файлы используются программами печати для проверки прав
доступа к удаленному принтеру. Подробнее об этом рассказывается в главе 23.
Гпово 21. Безопосность

Демон tftpd — это сервер ГЕТР (Trivial File Transfer Protocol — простей-
ший протокол передачи файлов). Иногда с его помощью в сетевые устройства
загружается программа ПЗУ или код начальной загрузки. Позволяя компью-
терам в сети запрашивать файлы с жестких дисков, данный протокол является
потенциальной брешью в системе зашиты. Лучше оставлять демон tftpd
отключенным, если он не используется
Деман fingerd
Команда finger выводит короткий отчет об определенном пользователе:
% finger evi
Login name: evi	In real life; Evi Nemeth
Directory: /beast/users3/evL	Shell: /bin/Cosh
On since Jan 22 07:07:55 on ttyp3 from xor-train4.xor.com
50 minutes Idle Time
Mail last read Sat Jan 22 07:08:57 2000
No Plan.
Будучи вызванной без аргументов, команда finger выдает отчет обо всех
зарегистрированных в системе пользователях.
Если на удаленном компьютере запушен демон fingerd. команда fiuger
может быть вызвана с аргументом пользоваты*@компыотер или просто
©компьютер. К сожалению, выдаваемая информация может представлять
интерес для хакеров, поэтому мы рекомендуем отключать запуск демона
fingerd в файле /ctc/inetd.conf*
Безопасность и NIS
Эти слова можно поставить рядом разве что в заголовке. Сетевая
информационная служба, или NIS (Network information Service; раньше ее
называли Yellow Pages). — это разработанная компанией Sun система
распространения баз данных, которой многие организации пользуются для
ведения и рассылки таких файлов, как /etc/group, /etc/passwd и /etc/iiosts.
К сожалению, порочна уже сама идея “легкого доступа к информации",
положенная в основу этой системы и делаюшая ее лакомым кусочком для
хакеров. В пришедшей на смену NIS системе NIS+ сделана лишь робкая
попытка устранить присущие NIS проблемы зашиты информации, поэтому
лучше всего вообще не использовать ни оДн\ из версий этой системы.
Подробнее о MS молено узнать в главе 1S.
Более безопасный и надежный способ рассылки указанных файлов —
создать учетную запись наподобие netadmin и поместить последние копии
файлов в каталог "'netadmin. После этого на каждой машине-клиенте
необходимо с помощью демона сгоп периодически запускать сценарий,
назначение которого — рассылка (посредством программы scp). проверка и
инсталляция файлов. Программа scp является частью пакета SSH, о котором
рассказывается в параграфе 21.8
Следует также отметить, что за годы эксплуатации в демоне fingerd был выявлен целый ряд
ошибок, связанных с безопасностью, что просто недопустимо для столь простой программы.
698
Чость II. Робото в сетях
Безопасность и NFS
Информация о безопасности NFS приводилась в параграфе 17.1 С по-
мощью команды showmount -е можно узнать, какие файловые системы
экспортируются и кому именно. Для каждой файловой системы следует задать
список управления доступом, а все имена компьютеров должны быть
полностью определенными.
Безопасность и sendmail
Пакет sendmail — это большая сетевая система, значительная часть
которой выполняется с правами суперпользователя. Вследствие этого она
часто становилась мишенью хакеров, и со временем здесь были обнаружены
многочисленные уязвимые места. Поэтому следует пользоваться только самой
новой версией sendmail. Проблемы безопасности часто приводят к появлению
новых версий программ, так что ошибки, скорее всего, есть во всех версиях
sendmail, кроме последней (в ней они либо еше не обнаружены, либо скоро
будут исправлены). Свежие новости можно узнать на Web-узле www.send-
mail.org.
Более подробные сведения о sendmail содержатся в главе 19.
Безопасность и резервное копирование
Регулярное создание резервных копий данных является неотъемлемым
компонентом любой стратегии обеспечения безопасности. Необходимо, чтобы
все разделы диска регулярно архивировались на ленту, а некоторые резервные
копии хранились вне фирмы. Если произойдет серьезный инцидент, можно
будет быстро восстановить работоспособность системы.
Более подробная информация о резервном копировании приведена в главе 10.
Поскольку установить ленту в накопитель и прочитать ее содержимое
может любой человек, держите резервные ленты под замком.
Троянские кони
Троянские кони — это программы, назначение которых полностью
противоречит заявлениям предлагающего их лица. В качестве примера можно
привести программу turkey, которая когда-то распространялась в Usenet. Она
обещала нарисовать на экране терминала индюка, а на самом деле удаляла
файлы из начальных каталогов доверчивых любителей домашней птицы.
Учитывая количество нападений, которые сообщество UNIX пережило
за несколько последи их десятилетий, остается удивляться малому числу
троянских коней, встретившихся нам. По сути, нам не известен ни один
задокументированный случай обнаружения программы, которая:
•	имела бы некое полезное предназначение;
•	не распространялась как часть операционной системы;
•	предоставлялась в виде исходных текстов;
•	была широко распространена
и при всем при этом специально содержала злонамеренный код или
умышленно обходила механизмы защиты операционной системы. Не поймите
нас превратно: мы допускаем, что где-то такое могло случиться Просто для
среднестатистического администратора угроза троянских коней была мини-
мальной.
Глово 21. Безопосность
699
Таким положением вешей мы обязаны законопослушному сообществу
Internet. Наиболее очевидные проблемы, связанные с безопасностью, быстро
выявляются и широко обсуждаются в Сети. Злонамеренные программы не
задерживаются на популярных серверах Internet.
Можете быть уверены: любая программа, у авторов которой были
нечистые намерения, будет выявлена и проанализирована в Usenet. Если
перед инсталляцией какой-то программы нужно узнать ее “репутацию’',
поищите имя программы в архивах на узле wvw.deja.com.
2	1.7. Инструментальные средства защиты
Для решения многих задач, о которых упоминалось в предыдущих
параграфах, можно использовать свободно распространяемые программы.
Ниже мы рассмотрим наиболее интересные из них.
Программа птар: сканирование сетевых портов
Программа птар является сетевым анализатором. Ее основная функция
заключается в проверке указанных сетевых узлов на предмет того, какие ТСР-
и UDP-порты на них прослушиваются серверными программами". За
большинством сетевых сервисов закреплены "известные” порты, поэтому
данная информация позволяет узнать о том, какие программы выполняются
на компьютере.
Запуск программы птар — отличный способ узнать, как выглядит система
в глазах того, кто пытается ее взломать. В качестве примера ниже показан
отчет, выданный этой программой на самом обычном, относительно неза-
щищенном компьютере:
% пшлр -яТ hostl.uexanyle.com
Starting nmap V. 2.12 by Fyodor (fyodorGdhp.com, www.insecure.org/nmap/)
Interesting ports on hostl.uexample.com (10.10.2.1):
Роге	State	Protocol	Service
7	open	tcp	echo
о	open	tcp	discard
	open	tcp	daytime
19	open	tcp	charaen
21	open	tcp	ftp
23	open	tcp	telnet
25	open	tcp	smtp
513	open	tcp	xOgln
Nmap run completed - 1 IP address (1 host up) scanned In 1 second
Аргумент -sT сообщает программе nmap о необходимости подключиться
к каждому TCP-порту па указанном узле"" Как только соединение устанав-
ливается. программе nmap немедленно отключается, что не очень корректно,
зато безболезненно для правильно написанного сетевого сервера.
Как объяснялось в главе 13, порт — это нумерованный капал взаимодействия. 1Р-адрес
идентифицирует весь компьютер, а комбинация IP-адреса и номера порта определяет
конкретный сервер или сетевое соединение.
На самом деле по умолчанию проверяются только привилегированные (их номера меньше
1024) и “известные" порты. С помошыо опции -р можно явно указать диапазон сканиро-
вания
700
Чость II Робота в сетях
Как следует из приведенного выше примера, на узле hostl.uexample.com
выполняется несколько серверов, являющихся традиционными источниками
проблем безопасности системы: ftpd (ftp), rJogind (login) и, очевидно,
sendmail (smtp). Таким образом, потенциальные направления удара уже ясны.
Колонка state (состояние) содержит запись open (открыт) для портов,
с которыми связаны серверы, запись unfiltered (не фильтруется) для
портов без серверов и запись filtered (фильтруется) для портов, доступ к
которым невозможен из-за наличия брандмауэра. Чаще всего встречаются
нефильтруемые порты. Они отображаются лишь в том случае, если их
относительно немного. Приведем результат запроса к более защищенному
коммерческому Web-серверу www.aexample.com:
% хшар	hoctl. uexcanplo. coni
Starting nmap v. 2.12 by Fyodor (fyodor@dhp.coni, www.insecure.org/nmap/)
(Not showing ports in state: filtered)
Port	State	Protocol	Service
53	unfiltered	tcp	domain
80	open	tcp	http
179	unfiltered	tcp	bgp
443	open	tcp	https
Nmap run completed — 1 IP address (1 host up) scanned in 122 seconds
Ясно, что узел сконфигурирован на обработку только Web-трафика.
Брандмауэр блокирует доступ к остальным портам Трафик протоколов DNS
и BGP пропускается, но нет серверов, которые бы его принимали.
В идеальном случае брандмауэр должен блокировать трафик всех неисполь-
зуемых сервисов (как DNS и BGP в данном примере), чтобы соответствующие
порты не оказались захваченными для других целей.
Помимо стандартного опроса TCP- и UDP-портов программа птар
способна проверять порты по-хакерски, не устанавливая с ними реального
соединения. В большинстве случаев посылаются пакеты, которые выглядят
взятыми из уже имеющегося TCP-соединения (это не квитирующие пакеты),
а затем проверяются полученные в ответ диагностические пакеты. Таким
способом можно обойти брандмауэр или программу мониторинга сети,
которая контролирует появление сканеров портов. Если в вашей организации
имеется брандмауэр, не поленитесь проверить его работу в разных режимах
сканирования.
Программа птар обладает магической способностью угадывать, какая
операционная система установлена на удаленном узле. Это делается путем
анализа деталей реализации стека TCP/IP. Чтобы проверить работ}-' програм-
мы птар в этом режиме, воспользуйтесь опцией -О:
% птар -О disaster mrhat lollipop
Starting птар V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on disaster.xor.com (192.108.21.99):
Remote operating system guess: HP-UX 11.00
Interesting ports on mrhat.xor.com (192.108.21.2):
Remote operating system guess: ESDI 4.0
I гово 21 Безолосносгь
701
Interesting ports on lollipop.xor.com (192.108.21.48):
Remote operating system guess: Solaris 2.6 - 2.7
Nmap run completed -- 3 IP addresses (3 hosts up) scanned in 5 seconds
Данная возможность полезна при анализе состояния локальной сети.
К сожалению. она же является и рабочим инструментом хакеров, которые
могут определить требуемый тип атаки на основании известных слабостей
конкретной операционной системы.
SAINT: выявление слабых мест сетевых систем
SAINT (Security Administrator’s Integrated Network Tool — интегрирован-
ный пакет для безопасного администрирования сети) — это обновленная и
улучшенная версия программы проверки сетевой гашиты, SATAN (Security
Administrator Tool for Analyzing Networks — инструментарий администратора
для анализа безопасности сети), выпущенной в 1995 г. и вызвавшей море
жалоб. Исходная версия SATAN была написана Даном Фармером (Dan
Farmer) и Витсом Венема (Wieise Venema) Сопровождением программы
занимается компания World Wide Digital Security. Inc., c Web-узла которой
(www.wwdsi.com) ее можно загрузить. Бесплатно!
Подобно утилите nmap. SAINT опрашивает компьютеры в сети, чтобы
узнать, какие серверы на них запущены. Но в то же время программа многое
знает о серверных утилитах UNIX и об их недостатках. Она ищет наиболее
типичные случаи неправильного конфигурирования, приводящего к сниже-
нию безопасности, а также проверяет наличие известных ошибок.
Отчет программы SAINT как бы содержит инструкции по взлому системы,
поэтому ряд администраторов считает, что лучше запустить ее или подобную
ей программу (например, Nessus. которая рассмотрена ниже) раньше, чем
это сделают хакеры.
Пользовательский интерфейс SAINT является полностью Web-ориенти-
рованным, в связи с чем для работы программы требуется Web-броузер.
Присутствие угштиты nmap не обязательно, но если таковая имеется, она
будет использована. По заявлениям разработчиков, программа SAINT работает
и с утилитами пакета Samba (если они инсталлированы), обеспечивая
проверку Windows-машин. Информация о пакете Samba приводится в
главе 26.
Nessus: сетевой сконер следующего поколения
Рено Дерезон (Renaud Deraison) разрабатывает пакет Nessus. в котором
реализуются многие функциональные возможности SAINT. Однако с архи-
тектурной точки зрения пакет Nessus понятнее и проще, а кроме того, в нем
предусмотрена возможность последующих расширений. Этот пакет доступен
на Web-узде www.nessus.org.
Мы познакомились с ранним (версии до 1.0) выпуском Nessus и
обнаружили, что он еше не совсем готов к полноценной эксплуатации. Пока
не ясно, насколько удачным получится финальная версия и сможет ли она
вообще завоевать популярность, но мы считаем необходимым упомянуть о
пакете из-за его модульной архитектуры, позволяющей сторонним фирмам
добавлять собственные модули проверки Если сообщество пользователей
702
Чость II Робото в сетях
станет создавать и накапливать базы сценариев для Nessus. пакет сможет
функционировать долгое время, не требуя постоянных обновлений.
Программа crack: поиск ненадежных паролей
Поскольку большинство производителей продолжает выпускать системы,
в которых зашифрованные пароли выставлены на всеобщее обозрение,
злобные хакеры запросто могут провести их сравнение со словами зашифрован-
ного словаря. Один из способов предупреждения подобных неприятностей —
провести это сравнение самостоятельно и потребовать от пользователей
сменить пароли, которые окажутся раскрытыми. Программа crack, написанная
Алеком Маффеттом (Alec Moffett), для выявления неудачных паролей
использует ряд широко известных приемов.
Даже если зашифрованные пароли скрыты от всеобщего обозрения в
файле теневых паролей, не лишним будет проверить их надежность с
помощью программы crack. Знание пользовательского пароля может помочь
администратору в обнаружении слабых мест в системе, ведь пользователи
стремятся многократно использовать одни и те же пароли Единый пароль
применяется для доступа к другой системе, шифрования файлов в начальном
каталоге, доступа к финансовой информации в Internet и т.д. Стоит ли
говорить о том, насколько это неразумно с точки зрения безопасности. Но
кому хочется запоминать десять разных паролей?
На момент написания данной книги текущая версия программы crack
имеет номер 5.0а. Ее можно найти по адресу
ftp://coast.cs.purdue.edu/pub/lools/unix/ pwdutils/crack/
Будьте осторожны: программа записывает расшифрованные пароли в
текстовом виде. Поэтому их нужно надежно защищать и по возможности
сразу же удалять.
Программа tcpd: защита Internet-сервисов
Программа tcpd, часто называемая пакетом “TCP-оболочек”. позволяет
регистрировать подключения к таким TCP-сервисам, как telnetd, rlogind и
fingerd. Кроме того, она позволяет задавать перечень систем, которые имеют
право устанавливать подключения. Обе эти возможности очень полезны при
выслеживании нежелательных гостей. Программа tcpd написана уже упоми-
навшимся Витсом Венема и доступна на узле ftp.porcupine.org. Она является
стандартным компонентом Red Hat и FreeBSD (находится в каталоге
/usr/ports/security/tcp_wrapper).
Программа tcpd легко инсталлируется и не требует внесения изменений
в действую шие сетевые утилиты. Она работает в связке с демоном inetd
Достаточно модифицировать файл /etc/rnetd.conf, чтобы вместо реального
сетевого сервера выполнялась tcpd. Перед запуском соответствующего сервера
программа выполняет необходимые операции регистрации и проверки
безопасности. Например, если соответствующая строка в файле /etc/inctd.conf
имеет вид
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
то ее можно заменить такой строкой:
telnet stream tcp nowait root /usr/soin/tcpd in.telnetd.
О демоне inetd рассказывается в параграфе 28.3.
Глово 21. Безопосность
703
ш
Результирующий журнальный файл (его имя должно быть задано в файле
/etc/syslog.conf) будет выглядеть примерно так:
Nov 12 08:52:43 chimchim in.telnetd[25880]: connect from tintin.Colorado.EDU
Nov 12 19:19:44 chimchim in.telnetd[15520]; connect from catbelly.com
Nov 12 23:48:45 chimchim in.telnetd[19332]t connect from atdt.xor.com
Nov 13 20:14:57 chimchim in.telnetd[2362]: connect from 130.13.13.11
Встроенные ТСР-оболочки  HP-UX
В HP-UX есть версия демона inetd, в которой реализованы схожие
функциональные возможности. Ее параметры задаются в файле /var/adm/
inetd.sec. Записи файла имеют следующий формат:
сервис allow | deny имя_компьютера I адрес имя__коыпыотера; адрес ...
Необходимо, чтобы имя сервиса присутствовало в файле /etc/services или
/etc/грс. Любое указываемое имя компьютера должно быть полностью
определенным (например, moomin.xor.com).
Понимаются подстановочные знаки и обозначения диапазонов. Так.
выражение “192.108.21.*” соответствует всем узлам указанной сети класса С,
а выражение “192.108.21.1-50’’ — ее первым пятидесяти узлам.
Комментарии обозначаются символом решетки (®) и должны стоять в
отдельной строке. Не допускается задавать несколько строк описания одного
сервиса. В расчет берется лишь самая последняя строка. Если сервис не
упомянуг в файле, к нему' может подключаться кто угодно.
В следующих строках разрешается удаленная регистрация, но только для
двух сетей, а также запрещается доступ к демону sprayd со стороны двух
компьютеров:
login	allow	192.108.21.* 192.225.33.*
sprayd	deny	192.108.21.5 freddy.xor.com
По умолчанию демон inetd в HP-UX не ведет журнальную регистрацию
соединений, но при вызове с флагом -I он начнет направлять в систему
Syslog соответствующие сообщения от имени средства “facility” и с приори-
тетом “info”. Сообщения об отказах на доступ к сервисам регистрируются с
приоритетом "notice”.
COPS: оудит системы защиты
COPS (Computer Oracle and Password System — система проверки
компьютеров и паролей) — это написанный Даном Фармером пакет про-
грамм, которые осуществляют мониторинг различных компонентов системы
зашиты UNIX. С помощью демона сгоп пакет можно запускать каждую ночь.
Стандартизируя и упрощая способы простых проверок, пакет COPS
экономит время администратора, избавляя его от необходимости выполнять
операции вручную. К сожалению, активная разработка пакета прекращена,
но он остается удобным инструментом, позволяющим выявлять множество
классических проблем безопасности. Запустите его до того, как это сделает
кто-нибудь из пользователей.
COPS предупреждает о потенциальных проблемах (но не делает попытки
их устранить), посылая администратору письмо по электронной почте
В число подлежащих контролю атрибутов входят:
•	права доступа к файлам, каталогам и устройствам:
704
Часть II. Робот© в сетях
•	содержимое файлов /etc/passwd и /etc/group;
•	содержимое системных стартовых сценариев и crontab-файлов;
•	возможность записи в начальные каталоги пользователей.
После инсталляции пакета COPS администратору каждую ночь будет
приходить отчет о степени защищенности системы, имеющий примерно такой
вид:
ATTENTION:
Security Report from host raja.xor.com
Warning! Root does not own the following file(s): /etc
Warning!	(or current directory) is in root's path!
Warning! /var/spool/mail is World_ writable!
Warning! /etc/utmp is _World_ writable!
Warning! User randy’s home directory /home/staff/randy is mode 0777!
Warning! Password file, line 8, no password:
runmailq:;33:10:,,, :/home/staff/runmailq:/bin/csh
Warning! /usr/bin/uudecode creates setuid files!
Warning! Password Problem: Guessed: beth shell: /bin/csh
В пакет COPS входит экспертная система Kuang, которая предназначена
для выявления попыток присвоения обычными пользователями прав супер-
пользователя. Дополнительную информацию о пакете можно найти по адресу
hup://dan.yosemtte.ca.us/cops
Программа tripwire: контроль изменений в системных файлах
Программа tripwire, написанная Джином Кимом (Gene Kim) и Джином
Спаффордом (Gene SpafTord) из университета Пердью, контролирует права
доступа и контрольные суммы важных системных файчов, благодаря чему
можно легко обнаружить замененные, поврежденные или подделанные
файлы. Например, программа tripwire позволяет определить, что злоумыш-
ленник заменил программу /bin/login копией, которая записывает пароли в
секретный файл
Программа tripwire сверяется с базой данных, где записаны характери-
стики и контрольные суммы файлов на момент создания последней. Файлы,
подлежащие частым изменениям (например, /etc/utmp), в конфигурационном
файле программы, могул- быть особым образом помечены — в таком случае
предупреждения для них генерироваться не будут. В случае изменения
конфигурации системы или инсталляции новой программы базу данных
следует перестроить.
Каталог, где расположена база данных и конфигурационный файл
программы tripwire, по возможности должен монтироваться с безопасного
сервера в режиме “только для чтения”. При этом условии хакерам будет
сложнее замести следы и остаться незамеченными.
Программу tripwire нужно настроить так, чтобы она каждую ночь посылала
администратору по электронной почте отчет. Вот типичный пример такого
отчета:
#	tripwire
Tripwire (tin) ASR (Academic Source Release) 1.3.1
File Integrity Assessment Software
(c) 1992, Purdue Research Founaation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Глово 21. Безопоскость
705
Authorized Licensees.
*	## Phase 1: Reading configuration file
*	*| Phase 2: Generating file list
#	#f Phase 3: Creating file information database
Ш Phase 4: Searching for inconsistencies
ft#
tf*	Total files scanned:	20344
#	##	Files added:	0
It#	Files deleted:	0
#	# if	Files changed:	1
##>
#	##	Total file violations:
tit
changed: -rwxr-xr-x coot 262184 Jan 22 12:04:42 2000 /bin/tcsh
###
##t Phase 5: Generating observed/expected pairs for changed files
ft#
ft# Ater Observed (what it is)	Expected (what it should be)
### =«== -------------------- ---------------------------_=CT-^=-^__
/bin/tcsh
st_ctime: Sac Jan 22 12:04:42 2000 Fri May 14 05:11:41 1999
В этом примере про(рамма tripwire сообщает, что время изменения
индексного дескриптора файла /bin/tcsh отличается от указанного на момент
создания базы данных. Это может свидетельствовать о том. что хитрыи хакер
заменил исходную версию интерпретатора /bin/tcsh “троянским конем”,
который притаился до следующего запуска пользователем root. Сравнение
контрольных сумм этого файла и его версии на дистрибутивной ленте
(воспользуйтесь специальной утилитой siggen. поставляемой вместе с про-
граммой tripwire) поможет подтвердить или опровергнуть это предположение.
Поскольку некоторые хакеры достаточно умны и подделывают контрольные
суммы модифицированных файлов, программа tripwire использует два разных
метода вычисления контрольных сумм.
История программы tripwire несколько необычна: первоначально опа
распространялась бесплатно, но впоследствии была приватизирована и
превратилась в коммерческий продукт. К счастью, невозможно запретить то,
что когда-то было бесплатным Компания Tripwire. Inc., любезно продолжает
предоставлять бесплатную версию программы и даже выпустила к ней
высококлассную документацию и обновления. Все это доступно иа Web-узле
www. tri pwi resecn rity. co m.
TCT: криминалистическая экспертиза
Еще одним полезным средством зашиты стад пакет ТСТ (The Coroners
Toolkit — инструментарии следователя), написанный все теми же Даном
Фармером и Витсом Венема. ТСТ — до коллекция утилит, помогающих
анализировать систему после проникновения в нее нарушителя. Пакет
работает в Solaris, Red Hal и FreeBSD, но не в HP-UX (пока).
С помощью пакета ТСТ можно определить, что произошло и как это
случилось. Иногда даже удается восстановить данные, уничтоженные в
результате нападения. Особенно интересной представляется утилита mactimc.
отслеживающая время изменения, доступа и модификации индексного
дескриптора каждого файла в системе На момент подготовки нашей книги
к печати эта утилита еше не была готова к открытому распространению, но
когда вы будете ее читать, утилита, возможно, уже появится по адресу
www.fish.com/securiiy.
706
Чость II. Роботе в сетях
21.8. Системы криптографической защиты
Большинство широко используемых в UNIX протоколов было создано
до появления WWW и изобретения современных криптографических систем
Поэтому во многих протоколах понятие безопасности вообще не предусмот-
рено. Там же, где оно якобы учитывается, реализованные механизмы дискре-
дитируются передачей паролей в незашифрованном виде или отсутствием
проверки на то. с надежного ли компьютера или порта поступил пакет.
Сегодня эти протоколы эксплуатируются в кишащих хакерами и прочей
нечистью глобальных сетях, где. по определению, весь трафик открыт для
прослушивания. Более того, любой может вмешаться в сетевой диалог. Как
удостовериться в личности собеседника?
Криптография — это решение многих проблем. Уже давно существует
возможность шифровать сообщения так. чтобы даже в случае перехвата их
нельзя было прочитать, но это лишь одно из чудес криптографии. Такие
разработки, как шифрование с открытым ключом и защитное хэширование,
сделали возможным построение криптосистем, удовлетворяющих самым
строгим требованиям*.
К сожалению, все эти математические открытия нс удалось преобразовать
в надежное, полезное программное обеспечение, которое было бы повсеме-
стно распространено и удобно в применении. Разработчиков программных
криптографических систем больше интересовало доказательство их правиль-
ности и абсолютной безопасности, чем то. представляет ;н< такая система
практический интерес. Почти все современные программы в данной области
выглядят слишком заумными, поэтому неудивительно, что пользователи при
первой же возможности с радостью избавляются от них Сегодня практиче-
ской криптографией занимаются фанатики, параноидальные сторонники
теории всемирного заговора, а также ге. кому пе оставляет другого выбора
политика, проводимая руководством их организаций
Непонятно, полнится ;п< что-нибудь более разумное в данной области в
ближайшие годы. А пока мы познакомимся с тем. что сегодня имеется на
рынке.
Kerberos: унифицированный подход к сетевой безопасности
Система Kerberos, разработанная в Массачусетском технологическом
институте, ориентирована на решение задач, связанных с обеспечением
безопасности компьютерных сетей. Kerberos — это система аутентификации,
предоставляющая “гарантию" того, что пользователи и сервисные программы
на самом деле являются теми, за кого себя выдают. Никаких- дополнительных
проверок и шифрования передаваемых данных не предусмотрено.
Используя алгоритм DES. Kerberos создает вложенные наборы иденти-
фикаторов. называемых бшеталш. Билеты передаются по сети с целью
подтверждения личности пользователе и предоставления ему доступа к
сетевым службам. В каждой организации, где используется Kerberos, должен
выделяться хотя бы один физически защищенный компьютер (называемый
сервером аутентификации) дня выполнения демона Kerberos. Этот демон
выдает билеты пользователям и сервисным программам, требующим аутен-
тификации, на основании предъявляемых ими "удостоверений”, таких как
Тем, кого интересуют вопросы криптографии, рекомендуем обратиться к двум великолеп-
ным источникам: ресурсу ‘RSA Labs' Frequently Asked Questions about Today’s Cryptography"
(www.rsasecurity.coiii/rsalabs/faq) и FAQ-архиву телеконференции sei.crypt, доступному па
FTP-узле rtfm.niil.edu.
Глово 21 Безопосносгь
707
пароли. По сути, Kerberos улучшает традиционную систему парольной зашиты
в UNIX всего двумя способами: пароли никогда не передаются по сети в
незашифрованном виде, а пользователи избавляются от необходимости
многократно вводить пароли.
Kerberos существует уже долгое время и поддерживается многими
поставщиками операционных систем. Такие системы готовы работать с
Kerberos при наличии сервера аутентификации. Сам пакет, возможно
потребуется получить из внешних источников (один из них — web niit.edu/ker-
beros).
Что касается наших тестовых систем, то Kerberos поддерживается в Solaris
и HP-UX, а во FreeBSD этот пакет является частью системы. Определенная
поддержка имеется также в маршрутизаторах Cisco, хотя раньше применение
пакета часто сопровождалось возникновением ошибок. Компания Microsoft
заявила о расширенной поддержке Kerberos в Windows 2000, однако эта
реализация обладает целым рядом несовместимостей.
Сообщество пользователей Kerberos может похвастаться одним из самых
толковых и приятных документов, посвященных криптосистемам, а именно:
“Designing an Authentication System: a Dialogue in Four Scenes” (Проектиро-
вание системы аутентификации, диалог в четырех актах), написанным Биллом
Брайантом (Bill Bryant). Документ будет интересно прочесть любому, кто
интересуется темой криптографии. Документ можно найти по адресу
http://web.mil.edu/kerberos/www/diaiofiue.html
Имеется также хороший FAQ-архив:
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
Лучше использовать Kerberos, чем полностью отказаться от системы
защиты как таковой. К сожалению, Kerberos нельзя назвать вполне безопасной
системой, а ее инсталляция и запуск — не самое приятное занятие. В то же
время она не заменяет собой ни одну из программ, описанных в данной
главе. По нашему мнению, большинство организаций благополучно может
обойтись и без нес. Регулярная проверка Kerberos и применение системы
шифрования удаленных соединений, скажем SSH или SRP (см. ниже),
позволяют обеспечить достаточно приемлемый уровень безопасности пользо-
вателей.
PGP: высокая конфиденциальность
Пакет PGP (Pretty Good Privacy), написанный Филипом Циммерманом
(Philip Zimmermann), содержит криптографические утилиты, широко приме-
няемые для обеспечения безопасности систем электронной почты. Посред-
ством PGP можно шифровать данные, генерировать сигнатуры и проверять
источники происхождения файлов и сообщений.
Попытки то отрегулировать, то остановить распространение пакета
привели к появлению разнообразных его вариантов. Сегодня он существует
в нескольких версиях, включая ряд коммерческих продуктов от компании
Network Associates (www.nai.com). В США используется версия PGP. одоб-
ренная правительством. Международная его версия с более сильным шифром
доступна на Web-узле w'ww.pgpi.org.
PGP — это наиболее популярная криптографическая программа. Правда,
работать с ней в UNIX может лишь тот, кто очень хорошо разбирается в
криптографии. С другой стороны, к пакету прилагается 88-страничнып
учебник по криптографии, с которым может ознакомится любой желающий
708
Чость II. Робота в сетях
В целом, пакет PGP может оказаться полезным, но ьгы не рекомендуем
пользователям работать с ним из-за нетривиальное™ процесса обучения.
Гораздо удобнее использовать Windows-версию PGP. чем UNIX-команду pgp
с ее 38 различными режимами.
Программные пакеты, распространяемые через Internet, часто содержат
файл сигнатуры PGP, подтверждающий их подлинность и целостность Но
проверить эти сигнатуры не так-то легко людям, не являющимся фанатиками
PGP. Не потому, что процесс проверки сложен, а потому, что при
использовании PGP истинная безопасность достигается только путем созда-
ния персональной коллекции открытых ключей тех людей, которые были
проверены напрямую. Загрузка дистрибутива с открытым ключом и файлом
сигнатуры примерно так же безопасна, как и загрузка одного дистрибутива.
SSH: безопасный интерпретатор команд
Пакет S.SH (Secure Shell). написанный Тату Илёнепом (Tain Ylonen),
является безопасной заменой програкгм rlogin, гер и telnet. Он использует
криптографическую аутентификацию для подтверждения личности пользова-
теля и шифрует любые соединения между двумя компьютерами. Протокол
SSH уже хорошо изучен и проходит процесс стандартизации в IETF.
Подобно программе tripwire, пакет SSH трансформировался из бесплатно
распространяемой открытой системы (SSHI) в коммерческий продукт (SSH2).
И точно так же остается доступной и его бесплатная версия. Тем не менее
базовый протокол изменился, поэтому версии стали несовместимыми.
В принципе, пакет SSH2 доступен для использования в некоммерческих
целях, но условия лицензии достаточно жесткие. Мы советуем работать с
пакетом SSHI, который довольно надежен.
Первоначальную версию SSH1 можно найти по адресу ftp.ssh.com/pub/ssh.
Но похоже, что активная ее разработка прекращена. Группа OpenBSD взяла
в свои руки управление исходным текстом пакета, внеся некоторые изменения
в его структуру, но принципы работы пакета п его администрирования не
изменились. Данная версия называется OpenSSH и описана на Web-узле
www.openssli.com. Она функционирует лучше, мем оригинал, но порядок
получения исходных текстов в настоящее время слишком утомителен.
Возможно, в будущем ситуация изменится
В любом случае стоит упомянуть о несколько неопределенном правовом
статусе пакета SSH в США, гак как он использует запатентованную систему
шифрования RSA, а срок действия патента должен был истечь в сентябре
2000 года.
Основными компонентами пакета SSH являются серверный демон sshd
и две про1раммы пользовательского уровня: ssh. предназначенная для
удаленной регистрации, и scp. предназначенная для копирования файлов.
Среди остальных компонентов отмстим программу ssli-kcygen, генерирующую
пары открытых ключей, и несколько утилит, необходимых для поддержки
безопасных серверов X Windows.
Демон sshd способен аутентифицировать пользователей различными
способами. Выбор остается за администратором.
•	Метод А. Если имя удаленного компьютера, и которого регистрируется
пользователь, х казано в файле '"/.rhosts, ~/.shosts, /etc/hosts.cquiv или
/etc/shosts.equiv, то пользовате ль автоматически получает доступ к системе
без проверки пароля. Подобная схема моделирует работу старой програм-
мы rlogin и. по нашему мнению, не приемлема для широкого и с пользе
гания
Глове 21 Безопасность
71 9
•	Метод Б. В дополнение к методу А демон sshd может применять
шифрование с открытым ключом для проверки подлинности удаленного
компьютера. Чтобы это стало возможным, открытый ключ данного
компьютера (генерируется при инсталляции пакета) должен находиться
а файле /etc/ssh_known_hosts локального узла или в файле
~/.ssh/known_hosts пользователя. Если удаленный компьютер предостав-
ляет соответствующий секретный ключ (обычно он хранится в файле
/etc/ssh_host_key. недоступном для чтения рядовым пользователям),
пользователю разрешается войти в систему без проверки пароля. Мы
полагаем, 'поданный метод еше недостаточно безопасен. Если удаленный
компьютер подвергся взлому, локальный узел также окажется под угрозой.
•	Метод В Демон sshd может применять шифрование с открытым ключом
для идентификации пользователя. На этапе регистрации пользователь
должен иметь доступ к файлу своего секретного ключа и предоставить
пароль для его дешифрования Этот метод самый безопасный, но он
утомляет пользователей. Он также делает невозможной регистрацию в
системе мобильных пользователей (разве что они носят с собой копию
файла секретного ключа).
•	Метод Г. Наконец, демон sshd может просто попросить пользователя
ввести свой регистрационный пароль. Это делает программу ssli подобной
программе telnet, за исключением того, что шифрованию подлежат пароль
и весь сеанс. Основной недостаток данного метода заключается в том,
что пароли оказываются относительно слабыми (часто их длина ограни-
чена 8 символами), и уже существуют готовые программы (например,
crack) для взлома таких паролей. Тем не менее данный метод, как
правило, подходит для повседневного использования.
Правила аутентификации задаются в файле /elc/sshd config Этот файл
уже заполнен разного рода конфигурационным "мусором ”, большую часть
из которого можно спокойно проигнорировать. Параметры, касающиеся
аутентификации, перечислены в табл. 21.1.
Тоблицо 21.1. Порометры аутентификоции, зодовоемые в фойле /etc/sshd_config
Порометр	Метод *	По умолчанию	Нознсчеимег когда включен
RhostsAuthentx- CdtXOO	A	no	Разрешает регистрацию через файлы ’/.shosts. /etc/shosts.equiv и др.
RhostsRSAAuchen— txcatxon	Б	yes	Разрешает регистрацию через файл ~/.shosls и его эквива- ленты. но также требует от ком- пьютера предоставления ключа
IgnoreRhos ts	А, Б	no	Задает игнорирование файлов ""/.rhosts и hosts.equiv*
IgnoreRootRhosts	А, Б	no’	Предотвращает аутентифика- цию пользователя root через файлы .rhosts и .shosts
RSAAuthentxcation	В	yes	Разрешает	аутентификацию пользователей по методу шиф- рования с открытым ключом
PasswordAuthen- ticacion	I	yes	Разрешает использование обыч- ных регистрационных паролей
Методы аутентификации, к которым относится данный параметр.
Файлы "/.shosts и shosts.eguiv продолжают использоваться.
По умолчанию равен значению параметра ignoreRhosts.
7”.
Чость II Робото в сетях
Рекомендуемая нами конфигурация, в которой разрешаются методы В и
Г, но не А и Б, такова:
Rhos ^Authentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
SRP: безопасные удаленные пароли
Протокол SRP (Secure Remote Password), разработанный Томасом By
(Thomas Wu) из Стэнфордского университета, реализует простои, быстрый,
беспатентный и высоконадежный способ проверки паролей в общедоступных
сетях. Этот протокол пока что менее распространен, чем SSH, но он кажется
нам более элегантным. Его программное обеспечение проще с точки зрения
администрирования, а сам протокол легче адаптировать к существующим
сервисам. Вместо того чтобы переключаться на новый набор команд, как
того требует SSH, пользователи могут продолжать работать с программами
telnet и Пр. Единственное отличие заключается в том, что все сетевые
соединения будут незаметно шифроваться. Если говорить конкретно о
программах telnet и ftp. то клиенты и серверы SRP будут обратно совместимы
со своими стандартными аналогами. Аутентификация и шифрование исполь-
зуются только тогда, когда они поддерживаются обеими сторонами.
К сожалению, применяемый в UNIX стандартный алгоритм шифрования
DES математически неприемлем для протокола SRP, поэтому пароли SRP
должны храниться вне файла /etc/passwd. Существующая версия пакета SRP
(доступна на Web-узле srp.stanford.edu) создает нечто вроде файла теневых
паролей (/etc/tpasswd). а котором содержатся SRP-версии паролей всех
пользователей Имеется замена стандартной команды passwd, позволяющая
синхронизировать пароли в обоих файлах.
OPIE: универсальные одноразовые пароли
Одно из неудобств, с которыми сталкиваются системы SSH и SRP.
заключается в том, что обе стороны соединения должны поддерживать
специальный протокол, обеспечивающий безопасность соединения. Обычно
это не вызывает проблем, по иногда пользователи оказываются в затрудни-
тельном положении. Клиенты SSH имеются не во всех операционных
системах, поэтому мобильным пользователям приходится регистрироваться в
системе через компьютеры других людей.
Стандарт OTP (One-Time Password — одноразовый пароль), определенный
в документе RFC1938. реализует несколько иной подход к безопасности
паролей: вместо того чтобы их шифровать, он убеждается, что они
используются однократно. В таком случае обычные текстовые пароли можно
свободно передавать по сети, не беспокоясь о том. что их кто-нибудь
перехватит. Пользователи обычно распечатывают группу паролей и носят этот
список с собой. В О'ышчпс от обычных паролей, одноразовые пароли
генерируются от имени пользователя, их не приходится выбирать самостоя-
тельно.
В настоящее время наиболее распространенной OTP-системой является
OPIE (One-time Passwords In Everything — универсальные одноразовые
пароли). Она представляет собой модификацию более ранней системы S/Key
компании Bellcore (теперь Telcordia Technologies), усовершенствованной в
Глово 21. Безопосность
711
научно-исследовательских лабораториях военно-морского флота США. Ос-
новными элементами OPIE являются OTP-совместимые версии демонов
telnetd и ftpd, а также утилиты для генерирования списков паролей и
управления ими. Пакет OPIE доступен по адресу www.inner.net/pub/opie.
Необходимо отметить. что OTP-системы решают только проблемы,
связанные с кражей паролей. Они не шифруют сами данные, передаваемые
через сетевое соединение. Любой, кто тайно подключится к сеансу telnet,
даже не сумев получить пароля, наверняка сможет многое узнать о
пользователе. Каждый пароль, набранный после входа в систему (в программе
sudo, например), окажется совершенно незащищенным".
С учетом растущей популярности систем наподобие SSH, остается все
меньше и меньше причин применять пакет 0Р1Е. Если нет крайней
необходимости, не используйте данный пакет: его неудобно инсталлировать
и сопровождать, да и порядок работы с ним не совсем привычен для
пользователей
21 9 Брандмауэры
Наряду с защитой отдельных компьютеров можно предпринять меры и
по обеспечению безопасности на сетевом уровне, Основной инструмент
сетевой зашиты — брандмауэр. Существует три категории брандмауэров:
пакетный, сервисный и анализирующий.
Фильтрация пакетов
Брандмауэр, фильтрующий пакеты, ограничивает трафик через Iniernei-
шлюз (или через внутренний шлюз. соединяющий домены в пределах
организации), основываясь на информации из заголовка пакетов. Вы
указываете, какие целевые адреса, номера портов и типы протоколов являются
допустимыми, а брандмауэр просто отбрасывает (в некоторых случаях также
регистрирует) все пакеты, которые не соответствуют заданному критерию.
Фильтрацию выполняют специализированные маршрутизаторы (напри-
мер, выпускаемые компанией Cisco). Возможна также программная фильт-
рация; все зависит от компьютера, выполняющего функции шлюза, и его
конфигурации. В целом фильтрующие брандмауэры значительно повышают
безопасность, не требуя существенных финансовых затрат и особо сложной
настройки.
В Red Hal и FreeBSD имеется программный фильтр пакетов (см.
параграфы 13.14 и 13.151. Для этой пели можно купить коммерческую
программу. Все они позволят обеспечить разумную защиту домашнего
компьютера или небольшого офиса Но прочитайте еще раз начало главы,
прежде чем рассматривать UNIX-систему в качестве корпоративного бранд-
мауэра*’ Это тот случай, когда действительно стоит вложить деньги в покупку
специализированного сетевого оборудования, например брандмауэра PIX
компании Cisco.
Отсюда правило: пользователи нс должны запрашивать дополнительные О ГР-пароли.
зарегистрировавшись в системе по протоколу ОГР Все эти пароли будут переданы в
незащищенном виде.
Мы также предполагаем, что пользователям нс приходя! в голову тупые идеи наподобие
того, как сделать Windows платформой для брандмауэра. Неужели при мысли о Windows у
кого-то возникает чувство безопасности? Давайте не будем заниматься еру ндой: Windows -
для настольных компьютеров.
712
Чость II. Роботе в сетях
Принципы фильтрации сервисов
Большинству “известных” сервисов назначается сетевой порт в файле
/etc/services (или его системно-зависимом эквиваленте). Демоны, которые
реализуют соответствующие сервисы, постоянно опрашивают порты, ожидая
запросов на установление соединений со стороны удаленных компьютеров
Большинство таких портов — “привилегированные’'. Это значит, что их
номера находятся в диапазоне от I до 1023 и что порты могут использоваться
только процессами, работающими от имени пользователя root. Порты с
номерами 1024 и выше являются непривилегированными.
Фильтрация сервисов основана на предположении, что клиент (компью-
тер, инициирующий соединение по протоколу TCP или UDP) будет
использовать непривилегированный порт для установления контакта с
привилегированным портом сервера. Например, если компьютеру с адресом
192.108.21.200 нужно разрешить только входящие SMTP-соединения, то
следует установить фильтр, который позволит посылать TCP-пакеты по этому
адресу только через порт 25 и отправлять TCP-пакеты с данного адреса через
любой порт”. Способ инсталляции такого фильтра будет зависеть от типа
маршрутизатора.
Некоторые сервисы, например FTP. еше больше усложняют эту голово-
ломку. При пересылке файла по протоколу FTP устанавливается на самом
деле два соединения: одно — для команд, другое — для данных. Клиент
инициирует командное соединение, а сервер — информационное. Следова-
тельно. если необходимо получать файлы из Internet по протоколу FTP, нужно
разрешить вход в систему через все непривилегированные TCP-порты, так
как неизвестно, какой из них будет использован для установления инфор-
мационного соединения.
Подробнее о конфигурировании FTP-сервера рассказывается в параграфе 22.6.
Это сводит на нет преимущества фильтрации пакетов, поскольку
некоторые общеизвестные сервисы, славящиеся своей незащищенностью,
работают с непривилегированными портами (например, XII — порт 6000).
Кроме того, не в меру любознательные пользователи в организации получают
возможность запускать собственные сервисные программы (например, сервер
telnet на нестандартном и непривилегированном порте), к которым они и их
друзья могут обращаться из Internet.
Самый безопасный способ использования фильтра пакетов — начать с
конфигурации, в которой не допускается ничего, кроме входящего SMTP-
трафика. Затем можно постепенно ослаблять фильтр по мере того, как будет
обнаруживаться, что отдельные полезные сервисы не работают.
В некоторых фирмах, уж очень заботящихся о безопасности, используется
двухступенчатая фильтрация. Один фильтр в этой схеме подключен к Internet
как шлюз, а второй находится между этим шлюзом и остальной частью
локальной сети. Идея состоит в том, чтобы оставить наружный шлюз
относительно открытым, а внутренний сделать очень жестким. Если проме-
жуточный компьютер административно отделен от остальной части сети,
появляется возможность предоставлять различные сервисы internet с меньшим
риском.
Во многих случаях задачу ожидания берет на себя демон metd. Подробнее об этом
рассказывается в параграфе 28.3.
Порт 25 — это порт SMTP, определенный в файле /etc/scrvices.
Гпово 21 Безопасность
713
Наиболее разумный способ урегулирования проблем с FTP — разрешить
выход по протоколу FTP во внешний мир только с одного этого изолиро-
ванного компьютера- Пользователи смогут регистрироваться на ием, когда
им понадобится выполгнятъ другие сетевые операции, запрещенные во
внутренней сети. Поскольку копирование всех пользовательских учетных
записей на FTP-сервер противоречит сути административного деления, можно
создавать учетные записи только по заявкам. Естественно, на FTP-сервере
должен работать полный комплект средств зашиты.
Сервисные брандмауэры
Сервисные брандмауэры перехватывают входящие и исходящие запросы
на соединение и устанавливают собственные подключения к сервисам в
пределах сети, играя роль преграждающего затвора либо посредника между
двумя мирами. По своей архитектуре сервисные брандмауэры менее гибкие
и быстродействующие, чем обычные фильтры пакетов. Они должны иметь
специальный модуль декодирования и перенаправления пакетов для каждого
протокола, трафик которого проходит через брандмауэр. В начале 90-х гт.
это было относительно несложно сделать, так как широко использовалось
лишь небольшое число протоколов. Сегодня, путешествуя в паутине глобаль-
ной сети, пользователь за один час может задействовать несколько десятков
протоколов. Поэтому сервисные брандмауэры относительно непопулярны в
организациях, где основной средой взаимодействия стала сеть Internet.
Анализирующие брандмауэры
В основе анализирующих брандмауэров лежит следующий принцип: при
внимательном прослушивании всех диалогов (на всех языках) в толпе
аэропорта можно узнать, не планирует ли кто-нибудь пронести с собой в
самолет бомбу. Такие брандмауэры проверяют проходящий через них трафик
и сравнивают реальную сетевую активность с той. которая, по их мнению,
должна быть. Например, если в пакетах, передаваемых' в процессе обмена
FTP-командами, указывается порт, через который должно быть установлено
информационное соединение, брандмауэр обязан убедиться, что запрос
придет именно к этому порту. Попытки удаленных узлов подключиться к
другим портам будут считаться ошибочными, а следовательно, игнорироваться.
К сожалению, суровая действительность вносит свои коррективы. Нере-
ально отслеживать состояние сетевых соединений для тысяч компьютеров и
сотен протоколов, как нереально пытаться подслушать каждый разговор в
переполненном аэропорту. Возможно, когда-нибудь, когда процессорные
мощности и объемы оперативной памяти возрастут на порядок, этот замысел
и воплотится в жизнь.
Так что же нам пытаются продать под маркой “анализирующие
брандмауэры”? Такие системы либо контролируют очень ограниченное число
соединений и протоколов, либо ищут определенные “неправильные” ситуа-
ции, Это, конечно, неплохо. Полезна любая технология, позволяющая
выявлять аномалии графика. Но в данном конкретном случае нужно помнить
о том. что большинство рекламных заявлений подобного рола так и остаются
рекламными
Насколько безопасны брандмауэры
Фильтрация пакетов не должна быть основным средством зашиты от
незваных гостей. Это всего лишь вспомогательная мера. При применении
714
Чость II. Робота в сетях
брандмауэра у пользователя порой создается ложное впечатление, будто
уровень его безопасности является исключительно высоким. Если, доверив-
шись брандмауэру, ослабить бдительность на других рубежах, это отрица-
тельно скажется на защищенности информации в вашей организации
Каждый компьютер необходимо защищать индивидуально и регулярно
проверять, пользуясь такими средствами, как crack, tcpd. nmap, COPS и
tripwire. В противном случае за твердой оболочкой окажется мягкая,
податливая сердцевина — настоящая “конфетка” для голодных хакеров.
В идеале локальные пользователи должны иметь возможность подклю-
чаться к любому сервису Internet, но доступ к локальным сервисам со стороны
Intemet-узлов следует ограничить. Например, к архивному серверу может
быть разрешен FTP-доступ, а к серверу электронной почты — доступ только
по SMTP-соединениям
Чтобы Internet-канал функционировал с максимальной эффективностью,
советуем все же обратить особое внимание на удобство работы и доступность.
В конце концов, сеть становится безопасней благодаря бдительности систем-
ного администратора, а не благодаря “навороченному” брандмауэру.
21.10. Источники информации на тему безопасности
В битве за безопасность системы немалая доля успеха зависит от знания
современных разработок а данной области. Если система оказалась взломан-
ной, это вряд ли стало следствием применения технологической новинки
Скорее всего, маленькая трещинка в броне системы широко обсуждалась в
какой-нибудь группе новостей, и одному из неофитов захотелось ее заметно
увеличить.
Организация CERT
В связи с бурной реакцией общественности на вторжение Internet- "червя”
организация DARPA (Defense Advanced Research Projects Agency — Управле-
ние перспективных исследовательских программ Министерства обороны
США) учредила новую структуру CERT (Computer Emergency Response
Team — группа компьютерной ‘‘скорой помоши”) В ее обязанности входит
сбор информации, касающейся компьютерной безопасности. CERT до сих
пор остается наиболее известным консультативным органом, хотя со временем
оиа ствла весьма медлительной и бюрократичной. Более того, в самой
организации сейчас настаивают на том. что ее название не означает ничего
кроме “зарегистрированной служебной марки университета Карнеги-Меллона”.
Хотя, согласно уставу. CERT обязана решать возникающие на практике
проблемы, на деле эта организация не способна ни расследовать гаковые.
ни призывать к порядку нарушителей. Она является не более чем хранилищем
“заплат”, предлагаемых производителями для повышения степени защиты
программных продуктов, а также выпускает объявления о выходе новых
средств. Эти “заплаты” и объявления называются “рекомендациями CERT”.
Новые рекомендации публикуются на Web-узпе www.cen.org и в телеконфе-
ренции comp.security.announce. а также распространяются в соответствующем
списке рассылки. Чтобы подписаться на него, обратитесь по адресу
http://www.cert oig/coiiiact_cen/cenmaillist.html
Глово 21 Безопосность
715
ф
ш
Сервер SecurityFocus.com и список рассылки BugTroq
Сервер SecurityFocus.com специализируется на сборе новостей и инфор-
мации на тему безопасности. В новостях публикуются как общие обзоры,
так и статьи, посвященные конкретным проблемам. Имеется также обширная
библиотека полезных документов, удобно отсортированных по тематике.
Программный архив сервера содержит инструментальные средства для
множества операционных систем Программы снабжаются аннотациями и
пользовательскими рейтингами. Это наиболее глобальный и исчерпывающий
из известных нам архивов подобного рода.
Список рассылки BugTraq — это форум для обсуждения проблем
безопасности и путей их устранения. Чтобы подписаться на него, направьте
по адресу listserv@securityfocus.com письмо следующего содержания:
SUBSCRIBE BUGTRAQ фамилия, имя
Объем информации, рассылаемый по списку, может оказаться довольно
значительным. На Web-узле хранится база данных с отчетами о рассмотрен-
ных в форуме BugTraq проблемах.
Организация SANS
SANS (System Administration, Networking and Security Institute — Институт
системного и сетевого администрирования и проблем безопасности) — это
профессиональная организация, которая спонсирует конференции и обучаю-
щие семинары, посвященные вопросам безопасности. Ее Web-узел
www.sars.org является ценным информационным ресурсом, занимающим
промежуточное положение между серверами SecurityFocus.com и CERT: он
не столь маниакален, как первый, но и не столь нуден, как второй.
SANS рассылает по электронной почте ряд еженедельных и ежемесячных
бюллетеней, на которые можно подписаться на vine этой организации.
Информационные ресурсы операционных систем
Проблемы безопасности способны оказывать серьезное влияние на
репутацию, поэтому поставщики операционных систем остро заинтересованы
в том, чтобы помочь пользователям сделать свои системы безопасными.
Многие крупные поставщики ведут собственные списки рассылки и публи-
куют в них бюллетени по вопросам безопасности. Эта же информация часто
доступна и на Web-узлах. Не редкость, когда защитные “заплаты" распро-
страняются бесплатно, даже если поставщики обычно взимают плату за
программную поддержку.
В Internet есть Web-порталы, например www.securityfocus.com, на которых
содержится информация, касающаяся конкретных производителей, и имеются
ссылки на последние официальные пресс-релизы.
Чтобы подписаться на бюллетень компании Sun. посвященный вопросам
безопасности, отправьте письмо по адресу secunty-alert@sun.coin. включив в
тело сообщения строку “subscribe cws ваш_адрес”. Программные заплаты и
архивы бюллетеней находятся на Web-узле sunsolve.sun.com.
Компания Hewlett-Packard имеет Web-узлы поддержки: us-suppon.exter-
nal.hp.com — для жителей Америки и Азии и europe-suppon.extemal.lip.com —
для жителей Европы. Однако найти на них информацию, касающуюся
безопасности, непросто. Чтобы произвести поиск в базе, войдите в область
“maintenance/suppon" (сопронождение/поддержка) и щелкните на ссылке
“search technical knowledge base" (предварительно нужно будет зарегистриро-
ваться). В нижней части открывшейся страницы есть ссылка на бюллетени
по вопросам безопасности. По этой же ссылке можно получить доступ к
защитным ‘'заплатам”. Чтобы запросить высылку бюллетеней, вернитесь на
7Ц
Чость II. Роботе в сетях
главную страницу области "maintenance/support” и щелкните на ссылке
‘support information digest" в разделе “notifications". К сожалению, прямого
способа подписки через электронную почту, похоже, не существует.
Список рекомендаций по вопросам зашиты системы Red Hat можно
получить по адресу www.redhat.com/suppon/errata. На момент написания книги
не существовало официального списка рассылки по данной тематике, спонси-
руемого поставщиком Red Hat. Но в Сети есть множество ресурсов, касающихся
Linux. Большая часть информации в них напрямую применима к Red Hat.
Информация о безопасности системы FreeBSD находится по адресу
жЛ www.freebsd.org/securiiy- Имеется формальный список рекомендаций по
хЬ*' FreeBSD, а также ряд неофициальных списков рассылки. Вся работа системы
проходит под наблюдением “офицера контрразведки" (security officer), за
которым скрывается целая группа преданных ей профессионалов.
Информация о безопасности продуктов Cisco распространяется в виде
практических замечаний, список которых находится по адресу www.cis-
co.com/warp/public/770. Чтобы подписаться на список рассылки, посвященный
вопросам безопасности Cisco, направьте письмо по адресу majordomo@cisco.com,
включив в тело сообщения строку “subscribe cust-security-announce”.
Другие списки рассылки и Web-уэлы
Перечисленные выше контактные адреса — это лишь небольшая часть
ресурсов по вопросам безопасности, которые доступны в Internet. В преды-
дущем издании книги мы упоминали некоторые из них. но учитывая объем
имеющейся на сегодняшний день информации, а также скорость, с которой
появляются и исчезают различные ресурсы, мы посчитали целесообразным
указать несколько “метаресурсов”.
Хорошей стартовой площадкой в вашем поиске может стать Web-узел
X-Force (xforce.iss.net) компании Internet Security Systems, где содержится
множество полезных FAQ-архивов. Там можно найти текущий перечень
списков рассылки по вопросам безопасности, а также информацию по
конкретным операционным системам и “заплатам” к ним.
И конечно же, нельзя не упомянуть портал www.yahoo.com, содержащий
множество полезных ссылок на интересующую нас тему. Лучше искать их в
общем разделе “Computers and Internet", так как раздел, посвященный UNIX,
слишком анемичен.
21.11. Что нужно делать в случае атаки на сервер
Ключ к отражению атаки прост: не паниковать. Весьма вероятно, что к
моменту обнаружения факта вторжения большая часть ущерба уже нанесена.
Возможно, хакер “гулял" по системе несколько недель или даже месяцев.
Вероятность того, что вы поймали вора, прокравшегося в систему' всего час
назад, близка к нулю.
Мудрая сова в подобном случае посоветовала бы сделать глубокий вздох
и начать тщательно продумывать стратегию устранения “взлома". Старайтесь
не вспугнуть злоумышленника, во всеуслышание заявляя о происшествии
или выполняя какие-то действия, которые покажутся ненормальными для
того, кто, возможно, наблюдает за деятельностью организации на протяжении
нескольких недель. (Подсказка: в данный момент неплохо было бы выполнить
резервное копирование. Надеемся, это не удивит нарушителя?!)’
Если создание резервных копий не является “нормальным" действием в вашей организа-
ции, то обнаружение взлома окажется самой незначительной из ожидающих вас проблем.
Глово 21 Безопосность
717
Стоит также напомнить самому себе о том. что, согласно исследованиям,
в 60% инцидентов, связанных с нарушением безопасности, присутствовал
“внутренний враг”. Не изучив всех фактов, старайтесь не посвящать в
проблему лишних людей, кем бы они ни были.
Приведем короткий план, который, будем надеяться, поможет админи-
стратору пережить кризис
Этап 1: прекратите панику. Во многих случаях проблема обнаруживается
только спустя какое-то время. Еще один-два часа или пара дней уже ничего
не решают. Но имеет значение, какой будет реакция на событие: панической
или рациональной. Часто в результате возникшей паники ситуация только
усугубляется уничтожением важной информации.
Этап 2: определите адекватную степень реакции. Никому не выгодно
раздувание инцидента. Будьте благоразумны. Решите, кто из персонала будет
участвовать в решении возникшей проблемы и какие ресурсы при этом
должны быть задействованы. Остальные будут помогать осуществлять “вынос
тела”, когда все закончится.
Этап 3: соберите всю возможную информацию. Проверьте учетные н
журнальные файлы Попробуйте определить, где первоначально произошел
‘‘взлом”. Выполните резервное копирование всех систем. Убедитесь в том,
что резервные ленты физически защищены от записи, если вы вставляете их
в дисковод для чтения.
Этап 4: оцените нанесенный ущерб. Определите, какая важная информация
(если таковая имеется) “покинула” компанию, и выработайте стратегию
смягчения возможных последствий. Оцените степень будущего риска.
Этап 5: выдерните шнур Если это необходимо и возможно, отключите
“взломанные” компьютеры от сети. Остановите кровотечение и перевяжите
раны. В архиве Compromise FAQ компании ISS даны дельные технические
советы относительно того, что следует делать в случае “'взлома” системы.
Архив доступен по адресу
h ttp-7/xforce. iss. net/security Д ibrary/faqs/comprom ise.php3
Этап 6: разработайте стратегию восстановления. Соберите толковых людей
и обсудите план восстановления. Не заносите его в компьютер. Сосредоточь-
тесь на том, чтобы свести ущерб к минимуму. Постарайтесь никого не
обвинять и не нагнетать обстановку. Помните отом психологическом ударе,
который могут испытать пользователи.
Этап 7: сообщите о своем плане. Расскажите пользователям и управляющему
персоналу о последствиях “взлома”, возможных проблемах и предварительной
стратегии восстановления, Будьте честны и откровенны. Инциденты, связанные
с безопасностью, являются неотъемлемой частью современной сетевой жизни.
Это не отражение ваших способностей как системного администратора или
чего-то другого, чего можно было бы стыдиться. Открытое признание
возникшей проблемы — 90% победы, поскольку тем самым вы демонстри-
руете, что у вас есть план выхода из ситуации.
Этап 8: воплотите план в жизнь Вы знаете свои системы и сети лучше,
чем кто-либо другой. Доверьтесь плану и инстинктам. Посоветуйтесь с
коллегами из других организаций, чтобы убедиться в правильности выбран-
ного направления.
Этап 9: сообщите об инциденте в компетентные органы. Если в инциденте
участвовал “внешний игрок”, сообщите об этом случае в организацию CERT
(адрес ее электронной почты — cert(?'cert.org), предоставив как можно больше
информации
Стандартная форма отчета находится иа Web-узле www.cert.org. Ниже
перечислено, что желательно в него включизь:
718
Чость II. Робота в сетях
•	информацию о моделях и архитектуре “взломанных” компьютеров, а
также об установленных на них операционных системах;
•	список “заплат”, которые были установлены в системе на момент
инцидента;
•	список учетных записей, подвергшихся нападению;
•	имена и IP-адреса удаленных компьютеров, вовлеченных в инцидент;
•	соответствующие журнальные записи и учетные данные;
•	контактную информацию.
Если в ходе инцидента была обнаружена ранее неизвестная прореха в
программном обеспечении, следует сообщить о ней компании-разработчику.
21.12. Рекомендуемая литература
•	Bryant, William. ‘ Designing an Authentication System: a Dialogue in Four
Scenes”. web.mil.eduAerberos/www/dialogue.html.
•	CERT Coordination Center. “Intruder Detection Checklist”.
www.cert.oig/tech_tips/intruder detection_checklist.html.
•	CERT Coordination Center. “UNIX Configuration Guidelines”,
www.cen. org/tech _tips/u nixconfigu rat ionfuide lines, hl m 1.
•	Cheswick. William R.. and Steven M. Beliovin. Firewalls and Internet Security.
Second Edition. Reading, MA; Addison-Wesley. 2000.
•	Cunin. Mall, and Marcus Ranum. “Internet Firewalls. Frequently Asked
Questions”, www.interhack.nei/pubs/fwfaq.
•	Farmer. Dan. and Wietse Venema. “Improving the Security of Your Site by
Breaking into it”. 1993. www.fish.com/security.
•	Fraser, B., Editor RFC2196: Site Security’ Handbook, www.rfc-editor.oig.
•	Garfinkel, Simson, and Gene Spafford. Practical UNIX and Internet Security’.
Sebastopol: O'Reilly & Associates, 1996.
•	Kerby, Fred, et al. “SANS Intrusion Detection and Response FAQ”.
www.sans.org/newlook/resources/I DFAQ/I D_FAQ.htm.
•	Mann, Scott, and Ellen L. Mitchell. Linux System Security: The Administrator's Guide
to Open Source Security Tools. Upper Saddle River, NJ: Prentice Hall PTR. 2000.
•	Morris, Robert, and Ken Thompson. “Password Secunty: A Case History".
Communications of the ACM, 22 (11): 594-597. November 1979- Перепеча-
тано в UNIX System Managers Manual, 4.3 Berkeley Software Distribution.
University of California, Berkeley. April 1986.
•	Pichnarczyk, Karyn. Steve Weeber, and Richard Feingold. “UNIX Incident
Guide: How to Detect an Intrusion”. Computer Incident Advisory Capability.
U.S. Department of Enetgy. 1994. http://www.ciac.org/cgi-bin/index/docu-
ments.
•	Ritchie. Dennis M. “On the Security of UNIX”. May 1975. Перепечатано
в UNIX System Managers Manual. 4.3 Berkeley Software Distribution. University
of California, Berkeley. April 1986.
•	Schneier, Bruce. Applied Cryptography: Protocols. Algorithms, and Source Code
in C. New York, NY: Wiley. 1995.
•	Thompson. Ken. “Reflections on Trusting Trust”. Опубликовано в ACM
Turing Award Lectures: The First Twenty Years 1966-1985. Reading, MA: ACM
Press (Addison-Wesley). 1987.
•	Zimmermann. Philip R. The Official PGP Users Guide. Cambridge: MIT Press,
1995.
Глово 21. Безопосносгь
719
Г}Г} Web-хостинг и серверы
Internet
В течение последнего десятилетия темпы компьютеризации возрастают с
невиданным доселе ускорением. Среда UNIX стала чем-то вроде ‘аминокис-
лотного бульона”, породившего клиент-серверные вычисления и сеть Internet.
Еше в 80-х гт ОС UNIX приобрела репутацию высокопроизводительной и
надежной сетевой платформы, которая может применяться совместно с
различными аппаратными архитектурами. После того как в начале 90-х гг.
возникла '‘всемирная паутина", ставшая оптимальной средой разработки
распределенных клиент-серверных приложений. UNIX оказалась идеальной
операционной системой, пригодной для их практической реализации.
В настоящее время существует множество служб Internet, “хостинг"
(размещение) которых может осуществляться либо на пользовательском узле,
либо на сервере одного из многочисленных провайдеров’. В этой главе будут
рассмотрены три самые главные службы: WWW, FTP и новости
22.1.	Web-хостинг
В начале 90-х гг. UNIX была единственной системой, пригодной для
работы с WWW. С ростом популярности “всемирном паутины" резко
увеличивалось и количество пользователей (ими становились кто угодно —
от рекламных агентств до зоопарков), заинтересованных в своем присутствии
в глобальной сети. Однако для многих UNIX оставалась “терра инкогнита".
Оценив открывающиеся перед ними возможности, большие и малые
компании бросились на рынок со своими серверными решениями. Во многих
случаях эти решения требовали значительной перестройки операционных
систем, поскольку', в отличие от UNIX, им изначально не была свойственна
истинная многозадачность. Необходимость поддержки Web-содержимого
• В последнее время для обозначения провайдеров, предоставляющих услуги Web-хостин-
га, употребляется термин ASP (Application Service Provider — поставщик услуг прикладного
уровня).
720
Чость II Робото в сетях
привела к возникновению нового сегмента рынка, известного как Web-хос-
тинг. Приемные серверы не только выполняют доставку исходных Web-стра-
ниц (HTML), но и реализуют вспомогательные службы, такие как FTP SSL,
потоковые аудио- и видеоканалы
В настоящее время наряду со специализированными серверами, разра-
ботанными для удовлетворения специфичных потребностей рынка, стали
доступными различные платформы поддержки Web-хостинга. В качестве
одной из платформ усиленно рекламируется основной программный продукт1
компании Microsoft — операционная система Windows. Однако те. кто ценит
максимальную степень надежности, безопасности и производительности,
справедливо полагают, что наилучшим выбором является UNIX.
В специализированных изданиях публиковались многочисленные статьи,
освещавшие вопрос “Какая платформа лучше всего подходит для Web-хос-
тинга”. Обычно противопоставлялись две системы — Windows и UNIX. Как
правило, аргументы за или против ограничивались лишь заявлениями типа
"Менее функциональна'” и “Классная система!”. Если же рассматривать
вопрос беспристрастно, то, несомненно, станет ясно, что именно платформа
UNIX больше всего подходит для создания коммерческих Web-узлов.
К наиболее важным преимуществам UNIX относятся удобство админи-
стрирования и высокая производительность. Изначально UNIX проектирова-
лась как многопользовательская интерактивная операционная система. После
установки системы один администратор может работать с базой данных,
другой — отслеживать производительность операций ввода-вывода, третий —
обслуживать Web-сервер. В среде Windows только один администратор может
осуществлять контроль при помощи консоли (непосредственно или с
удаленной станции, применяя инструментальные средства наподобие РС-Апу-
where). В отношении производительности можно отметить такой факт:
хороший администратор может настроить ОС UNIX так, что на одном и том
же оборудовании она будет выполняться в два-три раза быстрее, чем Windows.
22.2.	Основы Web-хостинга
Хостинг Web-узла мало чем отличается от других сетевых услуг. В основе
функционирования WWW лежит HTTP (HyperText Transfer Protocol —
протокол передачи гипертекста) — простой протокол семейства TCP/IP,
используемый для форматирования, передачи и связывания документов друг
с другом. При этом документы могут содержать различные типы информации,
включая текст, изображения, звук, анимацию и видео. HTTP аналогичен
другим клиент-серверным протоколам, используемым в Internet, в том числе
SMTP (электронная почта) и FTP (передача файлов).
Web-сервер — это система, сконфигурированная для ответа на НТТР-за-
просы. Чтобы преобразовать обычную UNIX-систему в платформу Web-хос-
тинга, необходимо установить демон, который будет прослушивать ТСР-порт
с номером 80 (в соответствии со стандартом HTTP), принимать запросы на
выдачу документов, а затем передавать эти документы пользователю.
Web-броузеры, в частности Netscape и Internet Explorer, подключаются к
удаленным Web-серверам и делают запросы от имени пользователей. Полу-
ченные при этом документы могут содержать текстовые указатели (гипер-
ссылки) на другие документы, находящиеся (или не находящиеся) на том
сервере, к которому изначально подключился пользователь. Поскольку
протокол HTTP полностью стандартизирован, клиенты, работающие в любой
операционной системе, могут подключаться к любому серверу HTTP.
Глово 22 Web-хостинг и серверы Internet
721
Подобная независимость от платформы наряду с возможностью автоматиче-
ского перенаправления пользователя от одного сервера к другому способствует
повышению популярности протокола HTTP.
В настоящее время, однако, Web-хостинг '‘перешагнул" рамки протокола
HTTP Разработано много расширенных протоколов, обеспечивают их под-
держку самых разных возможностей — от шифрования данных до потокового
видео Эти дополнительные сервисы зачастую управляются отдельными
демонами даже в случае размещения на одном физическом сервере
Например, одним из наиболее популярных дополнительных сервисов является
HTTPS (Secure HTTP — безопасный протокол HTTP). Им управляет демон,
который использует SSL (Secure Sockel Layer — протокол защищенных
сокетов) и принимает запросы через ТСР-порт 443. Если нужные демоны не
входят в дистрибутив системы, их можно получить у сторонних поставщиков.
Унифицировонные укозотели ресурсов
URL (Uniform Resource Locator — унифицированный указатель ресурса)
представляет собой обобщенный адрес объекта или сервиса в Internet.
Порядок доступа к объекту определяют пять базовых компонентов адреса:
• протокол или приложение:
•	имя узла:
•	порт TCP/IP (необязательно):
•	каталог (необязательно);
•	имя файла (чувствительно к смене регистра символов, часто завершается
расширением “.him” или “.html’*}.
Типичный URL-адрес с указанием его компонентов приведен на рис. А.
Файл находится на узле www.apacne.org
в каталоге/foundation.
http://www.apache.org/foundation/FAQ.html
как	что
Протокол передачи гипертекста Файл называется FA Q. html.
Ч	•
Рис. А. Составные чости URL-одресо
В табл. 22.1 перечислены протоколы, которые наиболее часто упомина-
ются в URL-адресах.
Тоблицо 22.1. Протоколы URL
Протокол Назначение _____________________________Пример____________________________
http	Доступ к файлам с помощью про- http://adniin.coni/indcx.html
токола HTTP
https Доступ к файлам с помощью про- hups://admin.com/order.shiml
токолов HTTP/SSL
ftp	Доступ к файлам с помощью про- ftp://ftp.xor.com/adduser.tar.gz
токола FTP
722
Чость II Работе в сетях
Протокол	Нозночециа.	Пример
mailto	Отправка электронного сообщения по указанному адресу	rnailto:sa book@adBiin.com
news	Доступ к группам новостей Usenet	news: alt .cooking
telnet	Регистрация на удаленном компью- тере	telnet://spot.acme.com
Idap	Доступ к службе каталогов LDAP	ldap:/Adap.bigfoot.com:389/cn=Hert>
61e	Доступ к локальному файлу (не Internet)	file://etc/syslog.conf
Принцип роботы HTTP
HTTP — это удивительно простой клиент-серверный протокол, не
хранящий информации о состоянии сеанса. В парадигме НТГР инициатором
подключения всегда становится клиент (обычно броузер). Клиент запрашивает
у сервера “содержимое'” заданного URL-адреса. Сервер отвечает, передавая
поток данных либо возвращая сообщение об ошибке. Затем соединение
закрывается (это справедливо для HTTP версий 0.9 и 1.0; в HTTP 1.1 клиент
может запросить другой объект).
Поскольку протокол HTTP является довольно простым, к Web-броузеру
можно легко подключиться с помощью программы telnet. Для этого доста-
точно установить связь с портом 80 выбранного Web-сервера. После
установления соединения сервер готов принимать HTTP-команды. Чаще всего
при этом используется команда GET, которая запрашивает содержимое
документа. Обычно она задается в формате GET /, а возвращается корневой
документ, как правило, начальная страница, сервера. Протокол HTTP
чувствителен к регистру символов, поэтому при вводе команд используйте
заглавные литеры.
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost. xor.com.
Escape character is *Л]’.
GET /
<далее следует содержимое файла index. html>
Connection closed by foreign host.
CG 1-сценории: создание динамического Web-содержимого
Работая со статическими документами, HTTP-сервер способен выдавать
пользователям и страницы, создаваемые “на лету”. Например, если требуется
отобразить текущие время и температуру, сервер вызывает сценарий, обес-
печивающий предоставление данной информации. Такие сценарии зачастую
создаются с помощью CGI (Common Gateway Interface — единый шлюзовый
интерфейс).
Интерфейс CG1 является не языком программирования, а, скорее,
спецификацией, описывающей процесс обмена информацией между НТТР-
сервером и другими программами. Чаше всего CGI-сценарии представляют
собой программы, написанные на языке Perl или С и предназначенные
специально для взаимодействия с HTTP-сервером. Хотя на самом деле
подойдет практически любой язык программирования, поддерживающий
операции ввода-вывода в режиме реального времени. Даже фанаты языка
FORTRAN найдут применение своим знаниям при работе в Internet!
Глово 22 Web-хостинг и серверы Internet
723
Как правило, CGI-сценарии больше интересуют Web-разработчнков и
программистов. Но один из основных аспектов функционирования сценариев
не обходит стороной и системных администраторов. Мы имеем в виду
обеспечение безопасности. Поскольку CGI-сценарии получают доступ к
файлам, сетевым соединениям и прочим механизмам перемещения данных
из одного места в другое, выполнение этих сценариев несет потенциальную
угрозу компьютеру, на котором выполняется HTTP-сервер. В конечном счете.
CGI-сценарий позволяет любому пользователю выполнять программы на
сервере. Поэтому для CGI-сценариев должна применяться такая же система
безопасности, как и для других сетевых программ Дополнительная инфор-
мация по обеспечению безопасности CGI-сценариев находится по адресу
www.w3.org/Security/Faq/www-securiiy-faq.html.
Распределение нагрузки
Довольно трудно предсказать, сколько обращений (запросов к одному
объекту, такому как текстовый файл или изображение) либо операций
просмотра страниц (запросов всех объектов на одной просматриваемой
странице) может обработать единственный сервер. Все зависит от операцион-
ной системы, типа ее настройки, архитектуры системного аппаратного
обеспечения, а также от организации Web-узла (в частности от того,
содержатся ли там чисто статические HTML-страницы, выполняются ли
запросы к базе данных и производятся ли математические вычисления).
Только непосредственное измерение производительности и уточнение фак-
тических параметров узла, использующего реальное аппаратное обеспечение,
позволит ответить на данный вопрос. Иногда подсказку могут дать пользо-
ватели, создающие подобные узлы с помощью аналогичного аппаратного
обеспечения. Но ни в коем случае не стоит полагаться на цифры, указываемые
поставщиками UN 1Х-систем.
Вместо показателя производительности одного сервера лучше сосредото-
читься на показателе масштабируемости. Убедитесь в том, что вы и ваша
команда работаете по плану, который позволяет распределять нагрузку узла
между несколькими серверами Простейшим способом распределения трафи-
ка является использование коммерческого аппаратного обеспечения, скажем
Load Director компании Cisco или Alteon AC Eswitch. Подобные системы
ориентируются на параметры, задаваемые администратором, в частности на
время отклика отдельного сервера и время доступности. Благодаря распре-
делению нагрузки увеличивается производительность и отказоустойчивость
сети.
22.3.	Инсталляция НТТР-сервера
Установить Web-сервер очень просто! Web-службы не сравнимы в плане
легкости администрирования с системами электронной почты и службой
DNS.
Выбор сервера
Большинство поставщиков UNIX не включают HTTP-сервер в системный
дистрибутив (правда, в состав FreeBSD и Red Hat входит HTTP-сервер
Apache). Поэтому придется потратить некоторое время на выяснение того,
какой сервер наилучшим образом подходит для данного приложения и
выбранной платформы. К счастью, на сегодняшний день имеется целый ряд
724
Чость II. Робото в сетях
весьма неплохих серверов. Наиболее популярные из них выпускаются
компаниями Netscape и Apache*.
Достаточно полное сопоставление характеристик доступных НТТР-серве-
ров можно найти на Web-узле webcompare.intemet.com. Ниже указано
несколько факторов, которые следует учитывать при осуществлении выбора
•	надежность;
•	производительность;
•	своевременность обновлений и исправлений ошибок:
•	доступность исходного кода;
•	цена;
•	безопасность и контроль доступа;
•	возможность использования в качестве прокси-сервера;
•	возможность шифрования.
Последние несколько лет сервер Apache лидирует по показателю произ-
водительности и числу7 поддерживаемых операционных систем. Исходя из
этих соображений он и был выбран в качестве сервера приложений для
данной главы.
Компилирование и инсталляция сервера Apache
HTTP сервер Apache распространяется бесплатно, и его полный исходный
код доступен иа Web-узле www.apache.oqs. Первым делом обратитесь на
данный узел и загрузите последнюю версию сервера.
По окончании загрузки вызовите сценарий configure (включен в дистри-
бутив). который автоматически определяет тип операционной системы, а
также устанавливает соответствующие файлы сборки проекта. Потребуется
указать каталог, где должен располагаться сервер Apache. Для этого предна-
значена опция -prefix:
% ./configure —prefix=/uer/local/apache/
Некоторые компоненты сервера Apache могут включаться и отключаться
с помощью опций -enable-module= и -disable-module= сценария configure.
Установленный по умолчанию набор модулей вполне приемлем, но имеются
и дополнительные модули (табл. 22.2)
Тоблицо 22.2. Дополнительные модули Apoche, которые по умолчонию не включены
Модуль_______Нозночение_______	 ______________________________________
autlidbm Использует базу данных DBM для управления доступом со стороны
пользователей/групл (рекомендуется)1
authdb Использует базу данных DB для управления доступом со стороны
пользоватслей/групл (рекомендуется)1
usenrack Позволяет отслеживать щелчки мышью в броузерах, поддерживающих
технологию ‘‘cookie’’
rewrite	Переписывает URL-адреса, используя регулярные выражения
expires	Позволяет включать в документ дату его истечения
proxy	Конфигурирует Apache в качестве прокси-сервера (подробнее о данной
______________технологии рассказывается далее в этой главе)______________
1	Рекомендуется использовать один из перечисленных модулей (но нс оба сразу).
Компания Apache была сформирована несколькими людьми, создававшими файлы “заплат”
для httpd — популярного Web-ссрвера организации NCSA (примерно 1993 г.).
Глово 22. Web-хостинг и серверы Internet
725
В табл. 22.3 перечислены модули, которые могут быть отключены.
Отключая неиспользуемые модули, следует исходить из соображений безо-
пасности и повышения производительности.
Тоблицо 22.3. Модули Apoche, которые могут быть отключены
Модуль	Функция
asis	Позволяет посылать файлы указанных типов без использования
НТТР-заголо вков
autoindex Индексирует каталоги, в которых отсутствует начальная HTML-стра-
ница (например, index.html)
env	Позволяет устанавливать специальные переменные среды для CGI-
сценариев
include	Разрешает использовать серверные вставки (старый способ создания
динамического содержимого)
userdir	Разрешает пользователям иметь собственные HTML-каталоги
Полный перечень стандартных модулей можно найти в файле src/Confi-
gu ration входящем в дистрибутив Apache, либо по адресу www.apache.org/
docs/mod/index.himl.
После выполнения сценария configure запустите сценарии make и make
install для фактической компиляции и установки соответствующих файлов.
Во FreeBSD сервер Apache является одним из дополнительных программных
пакетов, который может быть установлен из каталога /usг/ports (подробнее об
этом каталоге рассказывается в параграфе 27.9). Для инсталляции Apache
перейдите в каталог /usr/ports/www/арасЫЗ и введите команду make.
Конфигурирование сервера Apache
После установки сервера необходимо сконфигурировать его с учетом
выполняемых функции. Все файлы конфигурации находятся в каталоге conf
(например, /usr/local/apache/conf). Необходимо проверить и настроить три
различных файла конфигурации: httpd.conr, srm.conf и access.con Г.
Файл httpd.conf определяет, каким образом демон Apache (httpd) взаимо-
действует с системой. В этом файле задается TCP-порт, через который
HTTP-сервер принимает запросы (обычно это порт 80). На одном компьютере
можно запустить несколько HTTP-серверов, подключенных к различным
портам. Помимо этого в файле httpd.conr указывается местоположение
журнальных файлов, а также задаются различные паоаметры, определяющие
характеристики сети и производительность сервера. Здесь же осуществляется
настройка виртуальных интерфейсов (дополнительные сведения по этому
вопросу приводятся в следующем параграфе).
Ресурсы, доступ к которым необходим серверу, настраиваются в файле
srm.conf. В нем располагается самая важная директива — DocumentRcct.
которая задает корневой каталог для обслуживаемых документов. В этом
файле также содержится ряд дополнительных установок, связанных, в
частности, с обработкой “специальных” URL-адресов (например, http://
www.xor.com/steve).
Параметры безопасности устанавливаются в файле access.conf. Он вклю-
чает директивы, которые позволяют управлять доступом на уровне каталога
72и
Чость II. Роботе в сетях
или файла. С их помощью можно предотвратить доступ к важным файлам
через демон httpd как из внешнего мира, так и внутри организации.
Необходимо задать как минимум два уровня управления доступом: на
одном уровне будет охватываться весь каталог документов, а второй должен
применяться только к каталогу cgi-bin. В последнем случае вызов сценариев
осуществляется только из каталога cgi-bin. Таким образом, отдельные
пользователи не могут создавать ‘‘бреши” в системе безопасности — случайно
или намеренно — с помощью своих собственных сценариев. Для установки
этого ограничения задайте опцию ExecCGl в файле srm.conf.
Запуск сервера Apache
Демон httpd можно запустить вручную либо воспользовавшись стартовыми
сценариями, имеющимися в системе. Последний способ предпочтительнее,
поскольку гарантирует, что Web-сервер перезапускается всякий ра.з при
перезагрузке компьютера. Дзя запуска сервера вручную следует ввести
примерно такую команду:
% /ияг/local/apache/apachactl start
Если требуется, чтобы демон httpd запускался автоматически на этапе
начальной загрузки, вставьте следующий фрагмент когда в функцию 1оса1гс()
стартовых сценариев либо включите его в файл /etc/rc.local, если используется
отдельный локальный сценарий.
if [ -х /usr/local/apache/httpcl ]; then
/usr/local/apache/apachectl start
echo —n ’www_server1
£1
22.4.	Виртуальные интерфейсы
Раньше UNIX-система обьлгно служила сервером для одного единствен-
ного Web-узла (например, www.acme.com). По мере роста популярности WWW
практически у каждого пользователя стало возникать желание обзавестись
собственным Web-узлом, и как грибы после дождя начали появляться тысячи
новых компаний, занимающихся Web-хостингом
Провайдеры быстро пришли к выводу о том. что можно добиться
существенной экономии средств и ресурсов, если на одном сервере разместить
несколько узлов. Благодаря этому приему можно легко управлять группой
узлов, используя одно и то же аппаратное обеспечение. На практике такой
подход реализуется с помощью виртуальных интерфейсов.
Виртуальные интерфейсы позволяют демону идентифицировать соедине-
ния, основываясь не только на номере целевого порта (обычно при работе
с HTTP используется порт 80), но и на целевом IP-адресе соединения.
В настоящее время виртуальные интерфейсы используются достаточно ши-
роко и доказали свою эффективность не только в сфере Web-хостинга.
Идея, положенная в основу функционирования виртуальных интерфей-
сов. весьма проста: одиночный UNIX-компыотер в сети обслуживает больше
IP-адресов, чем позволяют имеющиеся физтгческие сетевые интерфейсы.
Каждый из ‘‘виртуальных" сетевых интерфейсов может иметь доменное имя.
под которым он известен пользователям Internet. Это позволяет одному
UNIX-серверу обслуживать буквально сотни Web-узлов. (Для сравнения:
конкурирующая операционная система, работающая на платформе Intel.
Глово 22. Web-хостинг и серверы Internet
727
поддерживает виртуальные интерфейсы, но на практике может выполнять
хостинг не более десятка Web-узлов. Вряд ли стоит пользоваться такой
системой.)
Протокол HTTP 1.1 реализует функциональные возможности, подобные
возможностям виртуальных интерфейсов (официально это называется "вир-
туальные интерфейсы, не имеющие IP-адреса"), устраняя потребность в
назначении уникальных IP-адресов Web-серверам и в конфигурировании
специального интерфейса на уровне операционной системы. Этот подход
позволяет совместно использовать IP-адреса, что особенно полезно, когда
один сервер содержит сотни или тысячи начальных страниц (например, в
случае университетских Web-узлов). Однако такой подход нельзя назвать
практичным для коммерческих узлов, поскольку уменьшается степень их
масштабируемости (приходится изменять IP-адрес при перемещении узла на
другой сервер) и появляется угроза безопасности системы (если доступ к узлу
фильтруется брандмауэром на основе IP-адресов). Похоже, настоящие
виртуальные интерфейсы еше долго будут использоваться.
Конфигурирование виртуальных интерфейсов
Нвстройка виртуального интерфейса проходит в два этапа. Сначала
требуется создать виртуальный интерфейс на уровне TCP/IP. Конкретная
процедура зависит от используемой верезга UNIX; в следующих разделах
приведены инструкции для каждой из наших тестовых систем На втором
этапе необходимо сообщить серверу Apache об инсталлированных виртуаль-
ных интерфейсах.
Solons
Solaris поддерживает виртуальные интерфейсы (известные как "вторичные
интерфейсы”), используя понятия физического интерфейса и логического
модуля Например, если имя физического интерфейса hmeO. то соответст-
вующие виртуальные интерфейсы мопз называться hmeO:!. hmeO:2 и т.д.
По умолчанию у физического интерфейса может быть до 256 виртуальных
модулей. Если потребуется изменить это ограничение, модифицируйте с
помощью команды ndd значение параметра гр_аddгs_pe г _if (подробнее о
команде ndd рассказывалось в параграфе 13.12).
Чтобы сконфигурировать виртуальный интерфейс, вызовите команду
ifconfig, указав в качестве параметра одно из виртуальных имен (базовый
физический интерфейс уже должен быть активизирован.) В большинстве
случаев система настраивается так. чтобы команды ifconfig для виртуальных
интерфейсов автоматически вызывались на этапе начальной загрузки
Ниже приводится пример, когда компьютер, работающий под управле-
нием Solaris, получает адрес в закрытом адресном пространстве виртуальной
частной сети (Virtual Private Network, VPN), а также внешний Internet-адрес
Оба этих адреса связаны с физическим интерфейсом hmeO Чтобы интерфейсы
автоматически конфигурировались на этапе начальной загрузки, админист-
ратор создал два разных файла, содержащих их сетевые имена: /etc/host-
name.hmeO и /etc/hostnanie.hmeO:!.
% ! -1 /etc/hout*
-rw-r—г—	1	root.	10	Nov 4 10:19	/etc hostname.hmeO
-rw-r—г—	1	root	Lo	Dec 21 19;34	/etc/hosrname.hmeC:-
798
Чость И Робото в сетях
В этих файлах могут находиться либо имена компьютеров из файла
/etc/hosts, либо IP-адреса. В рассматриваемом случае используются оба
варианта:
% cat /•tc/hoetnam«.hma0
overkill
% cat /«tc/hoBtname.hmaO:1
206.0.1.133
% grep overkill /etc/hosts
10.1.2.9 overkill overkill.domain
Во время начальной загрузки оба адреса конфигурируются автоматически
(наравне с адресом интерфейса обратной связи, который в приведенном ниже
примере не показан):
% ifconfig -а
HmeO: flags=663<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST > mtu
1500 inet 10.1.2.9 netmask ffffffOO broadcast 10.1.2.255
hmeO:1: Elaqs-863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu
1500 inet 206.0.1.133 netmask ffffffSO broadcast 206.0.1.255
HP-UX
HP-UX версии 11.00 и выше поддерживает виртуальные, или “вторич-
ные”, интерфейсы, используя такое же соглашение об именовании интер-
фейсов, как и Solaris. Если land является именем физического сетевого
интерфейса, то 1ап0:1 — это первый связанный с ним виртуальный
интерфейс. Обозначение типа •*:!” представляет собой порядковый [Р-номер.
Каждому интерфейсу (реальному или виртуальному) при помощи команды
ifconfig могут быть назначены свой IP-адрес, сетевая маска и параметры
конфигурации.
Виртуальные интерфейсы появились в HP-UX 10.20, однако для работы
с ними требовалось установить “заплату”, которая добавляла команду i (alias
для их конфигурирования.
Red Hot
Виртуальные интерфейсы в Red Hat обозначаются в том же формате
интерфейс, ж'лемтяр. что и в Solaris и HP-UX. Например, если интерфейс
Ethernet называется ethO, то связанные с ним виртуальные интерфейсы
именуются как eth0:0, eth0:l и т.д. Все интерфейсы конфигурируются с
помощью команды ifconfig. Так, команда
#	ifconfig etho:0 120.13В.243.150 netmask 255.255.255.192 up
настраивает интерфейс cth0:0 и назначает ему адрес в сети 128.138.243.128/26
Чтобы назначенные виртуальные адреса стали постоянными, необходимо
создать для них файлы в каталоге /etc/sysconfig/nctwork-scripts.
Файл ifcfg-ethO:O, соответствующий приведенной выше команде ifconfig
может содержать такие строки;
DEVICE—ethO:0
IPADDR=128.138.243.150
NETMASK=255.255.255.192
NETWORh=128.138.243.128
BROADCASTS 2 8.J 38.243.191
ONBOOT=yes
Глово 22. Web-хостинг и серверы Internet
729
FreeBSD
Сервер FreeBSD поддерживает виртуальные интерфейсы (“IP-псевдони-
мы”) посредством опции alias команды ifeonfig. Например, следующая команда
закрепляет дополнительный IP-адрес за интерфейсом х1С:
#	ifeonfig xlO inet 192.168.0.1 netmask 255.255.255.255 alias
Чтобы просмотреть всю конфигурацию интерфейса, запустите команду
ifeonfig еще раз:
% ifeonfig xlO
xlO: flaqs=8843<UP,BCAST,RUNNING,SIMPLEX,MCAST> mtu 1500
inet 192.108.21.9 netmask OxffffffOO ncast 192.108.21.255
inet 192.160.0.1 netmask Oxffffffff beast 192.160.0.1
ether 00: 60-.97 :9b :69:9a
media: lObaseT/UTP <half-duplex>
supported media: autoselect lOObaseTX <full-auplex>
lOObaseTX <half-duplex> lOObaseTX lObaseT/UTP <full-duplex>
lObaseT/UTP lObaseT/UTP chalf-duplex>
Обратите внимание на два различных IP-адреса, указанных во второй и
третьей строках вывода.
Для удаления виртуального интерфейса выполните команду ifeonfig delete:
#	ifeonfig xlO inet 192.168.0.1 delete
Чтобы виртуальные интерфейсы автоматически конфигурировались на
этапе начальной загрузки, добавьте указанные ниже строки в файл rc.conf:
1£config_xl0_alias0-"inet 192.168.0.1 netmask 255.255.255.255”
ifconfig_xlO_aliasl=”-.."
Нумерация должна начинаться с суффикса aliasO и оставаться непре-
рывной.
Передача серверу Apache информации
о виртуальном интерфейсе
После создания виртуального интерфейса с помошыо команды ifeonfig
требуется сообщить серверу Apache о том. какие документы должны
обрабатываться при попытке подключения клиента к каждому интерфейсу.
Это можно сделать посредством конструкции Virtual Host из файла
httpd.conf. Каждому сконфигурированному виртуальному интерфейсу должна
соответствовать одна конструкция VirtualHost. Приведем пример:
<VirtualHost 192.225.33.37>
ServerAdmin webmasterPwww.company.com
DocumentRoot /usr/local/apache/htdocs/company
ServerName www.company.com
ErrorLog logs/www.company.com-error_log
TransferLog logs/www.company.com-access log
</VirtualHost>
После подключения клиента к виртуальному узлу 192.225.33.37 будут
обрабатываться документы из каталога /usr/local/apache/htdocs/company.
730
Чость II Работа в сетях
22.5.	Кэширование и прокси-серверы
Рост сети Internet и объема находящейся в ней информации происходит
по экспоненциальному закону. Следовательно, полоса пропускания глобаль-
ных каналов и мощность вычислительных ресурсов, требуемых для их
обслуживания. также возрастают согласно данному закону. Как укротить эту
“стихию”?
Единственным методом обуздания подобного роста является использова-
ние репликации. Независимо от того, на каком уровне — национальном,
региональном или корпоративном — находится информация, по мере роста
Internet ее необходимо перемещать на ближние узлы. Не имеет смысла,
скажем, передавать одну и ту же популярную Web-страницу из Австралии в
Северную Америку миллион раз в день, используя весьма дорогостоящий
международный канал связи. Должен быть способ сохранять эту информацию
после ее однократной передачи по каналу. К счастью, такой способ
существует.
На помощь приходит бесплатно распространяемый пакет Squid (в
переводе с английского — кальмар)’, являющийся кэширующим сервером и
прокси-сервером одновременно Он работает под управлением UNIX и
поддерживает несколько протоколов, включая HTTP. FTP, Gopher и SSL.
Схема работы пакета следующая. Клиентские Web-броузеры (такие как
Netscape и Internet Fxplorer) подключаются к серверу Squid, чтобы запросить
объект из Internet. Сервер выполняет запрос от имени клиента (либо извлекает
объект из кэша) и возвращает результат клиенту. Прокси-серверы этого типа
часто используются для усиления безопасности, а также для фильтрации
содержимого.
В системе, где работает прокси-сервер, непосредственный доступ в
Internet через брандмауэр нужен лишь одному компьютеру. В компьютерных
классах средних школ прокси-серверы зачастую выполняют фильтрацию
содержимого, предотвращая доступ детей к неподобающим материалам.
В настоящее время имеется множество коммерческих и бесплатных прокси-
серверов (но лишь некоторые из них основаны на пакете Squid).
Служба фильтрации — это хорошо, но кэширующие возможности Squid
просто замечательны. Сервер Squid не только кэширует информацию,
получаемую в результате выполнения запросов локальных пользователей, но
и позволяет создавать иерархию серверов. Группы серверов Squid для передачи
друг другу сведений о содержимом своих кэшей используют протокол ICP
(Internet Cache Protocol — протокол кэширования в сети Internet).
Это позволяет администратору создать систему, в которой локальные
пользователи с целью получения Internet-содержимого взаимодействуют с
кэширующим сервером организации. Если пользователь этого узла уже
запрашивае те же самые данные, ему передается их копия, причем скорость
передачи сравнима со скоростью работы сети (обычно 10 или 100 Мбит/с).
При отсутствии требуемой информации на локальном сервере Squid таковая
запрашивается у регионального кэширующего сервера. Как и в случае с
локальным сервером, если какой-либо пользователь регионального сервера
уже запрашивал объект раньше, этот объект хранится в кэше и будет
возвращен незамедлительно. В противном случае сервер обратится к выше-
стоящему серверу (обслуживающему страну или континент). Благодаря этому
Почему “кальмар"? Как объясняют разработчики, “вес хорошие имена уже используются”.
Глово 22. Web-хостинг и серверы Infernei
731
производительность обработки запросов достаточно высока и пользователи
чувствуют себя комфортно.
Использование пакета Squid экономически выгодно. Поскольку пользо-
ватели Internet часто запрашивают одну и ту же информацию, в средних и
крупных организациях наблюдается значительное дублирование внешних
Web-запросов. Эксперименты показали, что установка кэширующего сервера
приводит к уменьшению внешнего трафика на 40%. Выигрыш особенно
заметен на Web-узлах с поминутной платой за пользование каналом.
Инсталляция сервера Squid
Сервер Squid может инсталлироваться, конфигурироваться и работать в
большинстве современных UNIX-систем. Поскольку ему нужно свободное
пространство для кэша, потребуется выделенный компьютер, имеющий
достаточный объем оперативной и дисковой памяти. Приемлемая конфигу-
рация такова: 256 Мбайт ОЗУ и 20 Гбайт на жестком диске.
Свежую копию пакета Squid можно загрузить с узла www.squid-cache.org.
После распаковки дистрибутива запустите сценарий configure, находящийся
в начальном каталоге. По умолчанию предполагается, что пакет будет
инсталлирован в каталоге /usr/local/squid Если требуется указать другое
местоположение, воспользуйтесь опцией — prefix—каталог сценария configure.
После завершения работы сценария запустите сначала команду make all,
а потом — команду make install. Далее потребуется модифицировать файл
конфигурации /usr/local/squid/etc/squid-conf. Обратитесь к файлу QUICK-
STA.RT. находящемуся в дистрибутивном каталоге, для получения перечня
изменений, которым должен подвергнуться имеющийся файл squid.conf.
Нужно также выполнить команду /usr/local/squid/bin/squid -z. чтобы
построгггъ и обнулить структуру каталогов, в которой будут храниться
кэшированные Web-страницы. Сервер можно запустить вручную, с помощью
сценария /Bsr/Iocal/squid/bin/RunCache, хотя обычно он вызывается из сис-
темных rc-файлов — в таком случае сервер Squid автоматически запускается
на этапе начальной загрузки.
Для тестирования сервера Squid необходимо указать его в качестве
прокси-сервера для Web-броузера
22.6.	Установка анонимного FTP-сервера
Протокол FTP считается одной из старейших служб Internet Несмотря
на то, что он может применяться для решения различных внутренних задач
организации, в Internet часто встречаются "анонимные FTP-серверы”, с
помощью которых пользователи могут загружать файлы, не имея учетной
записи на данном узле.
Через FTP-серверы может распространяться программное обеспечение,
документация и тд. Как правило, доступ к ним осуществляется поверх
протокола HTTP. Основное преимущество такого подхода заключается в том,
что пользователи могут легко просматривать дерево доступных каталогов,
видеть размеры файлов и даты их обновления. При добавлении новых файлов
нет необходимости создавать какой-либо код HTML — достаточно поместить
их в заданной зоне узла.
Для организации анонимного FTP-сервера создайте учетную запись
псевдопользователя ftp. задайте соответствующий начальный каталог и
сконфигурируйте серверный демон ftpd. Поскольку анонимный FTP-сервер
732
Чость II. Робото в сетях
общедоступен, необходимо правильно его настроить, чтобы важные файлы
случайно не оказались доступными внешнему миру.
Демон ftpd управляется демоном iuetd, следовательно, должен иметь
соответствующие записи в файлах /etc/inetd.conf и /etc/services. Если поль-
зователи FTP-сервера регистрируются анонимно, демон ftpd выполняет
команду chroot. Тогда файлы, не находящиеся в каталоге 'ftp, становятся
невидимыми и недоступными. Это довольно важная мера зашиты, поскольку
демон ftpd должен выполняться с установленным битом SUID, меняя свой
идентификатор пользователя на root, чтобы иметь доступ к привилегирован-
ным портам сокетов.
Дополнительные сведения о демоне inetd приведены в параграфе 283.
Перечислим действия, которые необходимо выполнить при создании
анонимного FTP-сервера:
•	добавить запись псевдо пользователя ftp в файл паролей:
•	создать подкаталоги bin. etc и pub в каталоге 'ftp;
•	скопировать программу 1s в каталог 'ftp/bin;
•	скопировать файлы /etc/passwd и /etc/group в каталог 'ftp/etc;
•	отредактировать файлы passwd и group, как показано ниже;
•	заменить все пароли в файле ~ftp/etc/passwd звездочками;
•	задать надлежащие права доступа к файлам и каталогам в каталоге 'ftp.
Поскольку никто не должен регистрироваться в системе под именем ftp.
задайте для данного имени звездочку' вместо пароля. Желательно также
назначить в качестве регистрационного интерпретатора команд программу
/bin/falsc.
В сеансе доступа к анонимному FTP-серверу корневым каталогом
системы становится ~flp (это делает команда chroot), поэтому подкаталоги
bin и etc должны содержать копии всех команд и конфигурационных файлов,
необходимых демону ftpd. После выполнения команды chroot каталоги ~ftp/bin
и ~ftp/etc выглядят как /bin и /etc. В большинстве случаев демон ftpd
пользуется только командой Is и урезанными копиями файлов /etc/passwd и
/etc/group из каталога ~ftp/etc.
Усеченный файл passwd должен содержать записи лишь пользователей
root, daemon и ftp. Пароли необходимо заменить звездочками, поскольку эта
копия файла доступна любому посетителю FTP-сервера. Даже если пароли
зашифрованы, остается риск, что другие пользователи смогут их раскрыть*.
Более подробно о защите паролей можно узнать в параграфе 21.3.
С целью усиления мер безопасности сделайте файл ~ftp/bin/ls доступным
только для выполнения, назначив ему режим доступа 111. В этом случае
клиенты не смогут копировать двоичный код, пытаясь найти в нем слабые
места.
Поместите в каталог 'ftp/pub те файлы, которые предполагается выставить
на всеобщее обозрение.
Если в системе установлены совместно используемые библиотеки функ-
ций, а программа Is не была скомпонована статически, может потребоваться
скопировать библиотечные файлы в каталог "ftp либо создать на них жесткие
ссылки для формирования корректной среды выполнения. Дело в том, что
В некоторых системах нужно выполнить команду inkpasswd passwd после изменения файла
паролей.
Глоно 22. Web-хостинг и серверы Internet
733
библиотечные файлы становятся недоступными после выполнения команды
chroot
Очень важно правильно задать права доступа к различным файлам и
каталогам. Рекомендуемые нами права перечислены в табл. 22.4.
Таблице 22.4 Рекомендуемые прово доступо к содержимому которого —ftp
Фойл/католог	Владелец	Режим	
'«Р	root	555	
'ftp/bin	root	555	
"ftp/bin/ls	root	111	
~ftp/etc	root	555	
~ftp/etc/passwd	root	444	
~ftp/etc/group	root	444	
'ftp/pub	root	755	
ш
В Solaris требуется, чтобы программа Is размешалась в каталоге
'ftp/usr/bin Файл в каталоге 'ftp/hin должен представлять собой символиче-
скую ссылку на каталог nsr/bin (о не на ~ftp/usr/bin, поскольку после
выполнения команды chroot это путевое имя становится неопределенным).
В Solaris применяются совместно используемые библиотеки функций. поэтому
для функционирования команды 1s в каталоге 'ftp следует установить
множество дополнительных файлов. Более подробную информацию на эту
тему можно найти на man-странице демона ftpd. Не забудьте скопировать
файл /etc/netconfig в каталог ~ftp/etc.
В HP-UX вместо файла /etc/group используется файл /etc/logingroup.
копию которого надлежит поместить в каталог 'flp/etc.
Как во FreeBSD, так и в Red Hat применяются совместно используемые
библиотеки функций, однако все необходимые файлы автоматически копи-
руются в каталог 'ftp в процессе инсталляции операционной системы
Фактически, анонимный FFP-сервер создастся по умолчанию В результате
возникает угроза безопасности системы, если администратор ничего не
подозревает о ггодобном положении вещей. Если не требуется поддерживать
анонимный FTP-сервер, удалите запись псевдо пользователя ftp из файла
passwd (во FreeBSD после редактирования файла паролей нужно запустить
команду pwd mkdb. чтобы создать его хэш-версию — pwd.db).
22.7.	Группы новостей Usenet
Usenet представляет собой программную систему, созданную в 70-х гг
для распространения по всему миру небольших сообщений (’'статей'')
В действительности речь идет не о типе сети, а лишь о наборе протоколов,
форматов файлов и способов связи между узлами. В Usenet имеется большое
число "групп новостей”, аналогичных доскам объявлений. которые поддер
живаются некоторыми Web-узлами и интерактивными службами. В наши дни
Usenet в большинстве случаев вытесняется Web-службами. Многие провай-
деры даже не предлагают пользователям услуги Usenet, и новые пользователи
часто не шают о подобной возможности.
734
Чость II Робото в сетя>
В Usenet применяется “широковещательный” метод доставки. В таком
случае центральный узел, занимающийся распространением новостей, отсут-
ствует*. Когда пользователь создает (“публикует”) новую статью, она посы-
лается на сервер новостей его провайдера. Сервер провайдера предлагает эту
статью другим узлам. Всякий раз. когда статья поступает на новый сервер,
она рассылается всем остальным серверам, с которыми установлены двусто-
ронние отношения. В статье содержится список адресов, не позволяющий
серверам предлагать статьи гем узлам, где они уже есть.
На момент написания книги полный трафик Usenet без применения
средств фильтрации (по спаму юти по размеру статей) составлял более
100 Гбайт в день (новые статьи). За последние полтора года ежедневный
объем сообщений вырос в пять раз, хотя количество статей увеличилось за
этот период только на 50%.
Основу трафика Usenet составляют аудио- и видеофайлы в формате
MPEG, а также пиратские копии программ. Ранее большой объем памяти
занимали порнографические изображения. Трудно дать однозначную оценку
этому явлению, но в любом случае Usenet заслужил славу хранилища
“гигабайтов информации, полученных с нарушениями авторских прав".
Если размеры статей не будут превышать I Мбайт, будет учитываться
наличие спама и производиться фильтрация групп с неправильными назва-
ниями, то объем ежедневного трафика составит около 35 Гбайт в день. Однако
и этот объем данных впечатляет. Как правило, только крупные провайдеры
Internet располагают необходимыми ресурсами (достаточной пропускной
способностью канала передачи данных и соответствующим объемом дисковой
памяти) или имеют желание предоставлять их для обработки подобных
объемов информации**. С целью доставки новостей на узлы, которые не
обладают нужными ресурсами, были созданы альтернативные схемы передачи
сообщений
Подписка на новости Usenet
Чтобы иметь возможность получать новости Usenet, проще всего обра-
титься к службам специализированных компаний (www.supemews.com или
www.giganews.com). В общем случае достаточно указать сервер новостей
провайдера в настройках броузера, благодаря чему администрирование службы
новостей будет полностью выполняться на сервере провайдера.
Другой вариант (если провайдер его поддерживает) заключается в
рассылке новостей по запросу. В соответствии с данной схемой сервер
новостей получает доступ к статьям другого сервера, выполняя запрос.
Загруженные статьи кэшируются на локальном компьютере, благодаря чему
популярные статьи не требуется загружать повторно.
Преимущества такого подхода заключаются в том. что статьи передаются
из удаленного сервера только один раз (канал передачи данных используется
экономнее) я, поскольку сервер новостей является локальным для органи-
зации, чтение новостей проходит быстрее. Главный же недостаток — наличие
задержки по времени между получением статьи удаленным и локальным
Это не совсем так. Вследствие огромного объема новостей в наше время большинство узлов
получает информацию по крайней мере от одного крупного сетевого провайдера (Sprint.
WorldCom, AT&T и т.д_). Фактически провайдеры функционируют как стандартные пункты
рассылки новостей и гарантируют эффективное распространение статей.
Основной объем новостей (примерно 97%) приходится на иерархию “all”, главным образом
на группы "alt.binaries” (92%).
Глово 22. Web-хостинг и серверы Internet
735
серверами Кроме того, если пользователи нечасто просматривают новости,
статьи могут устаревать и уничтожаться удаленным сервером до того, как
будут переданы на локальный сервер.
Для устранения этих ограничений некоторые серверы новостей отслежи-
вают информацию о тех группах, которые просматриваются пользователями,
и заранее загружают статьи из этих групп по мере их поступления.
К сожалению, а такой схеме приходится отслеживать слишком большое число
групп, что противоречит смыслу подписки по запросу.
Существует и третий, гибридный подход к подписке на новости: сервер
получает обычный поток новостей, но передаются только заголовки статей,
а не их содержимое". Поскольку заголовки относительно невелики, не
требуется большая пропускная способность или же много дискового про-
странства. Лишь когда пользователь запрашивает статью для просмотра, она
пересылается внешним сервером. Заголовки хранятся а локальной системе,
поэтому сервер может быстро сообщать пользователям тематику и другую
информацию по всем доступным статьям.
Программное обеспечение Usenet
Если требуется просматривать группы новостей в домашних условиях, не
оплачивая услуги внешнего провайдера, необходимо найти внешний сервер
новостей и установить программное обеспечение для просмотра иерархии
статей. Придется также регулярно уделять время управлению и поддержке
системы.
Описание распространенных пакетов чтения новостей содержится в
табл. 22.5.
Тоблицо 22.5. Прогроммное обеспечение для упровпения группоми новостей
Нозвоние	Бесплотен?	Типы подписки	Web-узел
INN	Да	Традиционная, поддерж- ка клиентов чтения ново- стей	www.isc.oiE
Diablo	Да	Традиционная, по запро- су, гибридная	www.openusenei.org
Dnews	Нет	Традиционная, по запро- су, поддержка клиентов чтения новостей	netwmsite.com
Cyclone	Нет	Только традиционная	discussion.openwave.com
Typhoon/Breeze	Нет	Поддерживаются только клиенты чтения новостей	discussion.openwave.com
Нужны ли новости Usenet?
Трудно сказать, какой будет судьба Usenet С появлением WWW
значительно сократилось число пользователей, публикующих статьи в Usenet.
В то же время во много раз вырос обший объем новостей. Некоторые
исследователи заявляют, что соотношение емгнал/шум в Usenet сегодня столь
мало, что от этой системы пора отказаться. Однако немалое число адептов
спешит защитить кандидатские диссертации, посвященные благотворному
влиянию, которое Usenet оказывает на всемирное сообщество пользователем
Как говорится, "никогда не знаешь, где найдешь, где потеряешь”.
В заголовке содержатся имя автора, название темы, дата создания, идентификатор сообще-
ния и потоковые данные.
736
Чость II Робото в сетях
Часть III
Разное
23 Печать
Когда готовилось первое издание этой книги, самыми распространенными
принтерами считались построчно-печатающие ASCII-принтеры. Лазерные
принтеры были в новинку. стоили дорого и встречались редко. Для устройств
вывода с высокой разрешающей способностью требовались заказные драй-
веры и программы форматирования.
К тому времени, когда было опубликовано второе издание нашей книги,
постройно-печатаюшие принтеры стали редкостью. Были разработаны мно-
гочисленные стандартные языки описания страниц и печати. Появились и
получили широкое распространение лазерные принтеры.
Сегодня построчно-печатаюише принтеры относятся к числу раритетов.
Почти повсюду компьютерам неизменно сопутствуют лазерные принтеры, а
также многочисленные языки описания страниц.
Сейчас, когда мы готовим третье издание, лазерные принтеры чаше
подключаются к сети Ethernet. чем к последовательному или параллельному
порту компьютера-одиночки. Они практически уступили нижний сегмент
рынка струйным принтерам.
Принимая во внимание упомянутые технические новшества, можно было
бы предположить, что за прошедшие годы UNIX-системы печати кардинально
изменились. К сожалению, этого не произошло. Попросту' были модифици-
рованы старые программы спулинга для построчно-печатающих принтеров,
с тем чтобы обеспечить поддержку новых технических средств.
Все главные производители используют либо BSD-систему спулинга (Ipd.
Ipc, 1рг и др ), либо систему спулинга System V (Ipsched, Ipadmin. Ip и т.д),
либо комбинацию двух этих систем.
Для того чтобы определить, какой системой печати вы пользуетесь, прошс
посмотреть, какой спулер в ней присутствует (Ipd для BSD и Ipsched для
System V). чем разбираться в командах управления очередью. Многие
поставщики используют команды, названия которых совпадают с именами
команд других систем. Например, в HP-LJX применяется команда 1рг но ее
система печати аналогична системе, используемой в System V.
Глово 23. Печоть
739
Мы начнем эту главу со знакомства с терминологией, используемой в
области печати, а затем опишем системы печати BSD и System V. Будет
также рассмотрен вопрос организации совместной работы этих систем в сети
и, наконец, описаны некоторые программные средства, имеющие отношение
к печати.
23.1. Мини-словарь терминов по печати
Обзор современных технологий печати не входит в круг вопросов,
рассматриваемых в этой книге. Однако изложенной здесь информации будет
вполне достаточно, чтобы дать достойный ответ любому, кто обратится к вам
на принтерном жаргоне.
Спулинг Система спулинга принимает задания для печати, записывает их в
буферный каталог и в соответствии с приоритетами посылает на
принтер. Передача заданий в систему спулинга осуществляется
посредством команды пользовательского уровня.
dpi Большинство моделей современных принтеров — растровые уст-
ройства. Это означает, что печатаемые символы формируются с
помощью точечной матрицы, а их печать осуществляется путем
переноса на бумагу красителя в результате удара. Единица измере-
ния разрешающей способности принтера, dpi. соответствует коли-
честву точек, которые устройство способно выводить на отрезке
длиной (высотой) в дюйм. Чем больше число точек на дюйм, тем
выше качество печати. Так, выражение “300x600 dpi” означает
горизонтальное разрешение 300 точек на дюйм и вертикальное —
600 точек на дюйм.
PDL Так называемые языки описания страниц PDL (Page Descriplion
Language) предназначены для передачи данных принтерам. Средст-
вами такого языка описывается размещаемое на печатной странице
изображение. Пересылка на принтер и обработка образов страниц,
созданных с использованием PDL, занимает, как правило, гораздо
меньше времени, чем пересылка необработанных изображений.
Кроме того, упрощается процесс генерации изображений для
вывода на печать из прикладных программ. Еще одним достоин-
ством таких языков является их независимость от используемых
устройств и их разрешающей способности.
Битовый Иногда предназначенные для вывода на печать изображения
массив невозможно описать средствами PDL В этих случаях используется
битовый массив (bitmap) — структура данных, которая включает
описания всех точек изображения. В таких описаниях указывается,
должна или нет печататься данная точка (иди цвет точки, если
изображение цветное). Форматов битовых массивов, как и языков
описания страниц, существует несколько Каждый язык PDL
поддерживает один или несколько форматов. Поскольку битовые
массивы обычно очень велики, их часто сжимают. Есть очень много
средств для преобразования битовых массивов из одних форматов
в другие.
R1P Процессор растровых изображений (Raster Image Processor. RIP) —
это программа, которая получает поток предназначенных для
вывода на печать данных на одном из язьгкоа PDL и преобразует
их в битовые массивы, формат которых соответствует формату.
740
Чость III. Розное
поддерживаемому устройством вывода Когда появились первые
устройства, обеспечивающие высокое качество вывода на печать,
преобразование PDL-документа в битовый массив выполнялось на
компьютере. Впоследствии процессоры растровых изображений
стали встраивать в принтеры. По мере совершенствования систем
печати и усложнения преобразования такие процессоры все чаше
и чаше включаются в программное обеспечение компьютера.
Фильтры Фильтры представляют собой программы, которые модифицируют
задания на печать “по дороге” к принтеру. Они преобразовывают
форматы, выполняют контроль доступа и часто контролируют
соединение с принтером. Фильтры, как правило, не нужны для
принтеров, печатающих простые тексты, но без них трудно обойтись
при выдаче заданий на печать для принтеров, которые требуют
нестандартных языков описания страниц. Некоторые PostScript -
принтеры принимают неотфмльтрованные задания, но для боль-
шинства из них эти задания должны быть предварительно отфильт-
рованы. В терминологии System V фильтры называются
интерфейсами. Для получения более подробной информации о
фильтрах и интерфейсах обратитесь к параграфу 23.3.
PostScript Язык PostScript в настоящее время — наиболее распространенный
язык PDL в UNIX-системах. Он разработан компанией Adobe
Systems Incorporated, которая выдает лицензии на его использова-
ние. Выходные данные на языке PostScript могут генерироваться
почти всеми программами компоновки страниц, а большинство
моделей принтеров имеют встроенные интерпретаторы этого языка.
PostScript, по сути дела, является полноценным языком програм-
мирования. Написанные на нем программы можно читать с
помощью текстового редактора. Они отличаются обилием круглых
скобок и символов косой черты. В первых байтах любого Post-
Script-файла обычно содержится идентификатор файла, начинаю-
щийся символами %!. Существуют версии UNIX-программ печати,
которые используют эти символы при обработке заданий на печать
для распознавания языка описания страниц.
PCL Язык управления принтером PCL (Primer Command Language) —
разработанный компанией Hewlett-Packard аналог языка PostScript.
Этот язык широко распространен в мире персональных компью-
теров и используется практически на всех принтерах производства
Hewlett-Packard. В прикладных UNIX-программах, как правило, не
предусмотрена возможность генерации данных на этом языке, но
тем не менее большинство моделей устройств прои!водства Hewlett-
Packard имеет встроенные средства для обработки PostScript-файлов.
23.2. Типы принтеров
При работе в среде UNIX можно формировать задания для принтера
почти любого типа. На наиболее фундаментальном уровне принтеры клас-
сифицируются исходя из используемого ими интерфейса (сетевой, последо-
вательный. параллельный) и по типам данных, которые они “понимают”
(текст, язык PostScript, язык PCL или нечто совершенно иное).
Многие из дешевых принтеров, используемых в Windows (их обшее
название — Win Printers) нельзя использовать в среде UNIX. Эти принтеры
Ггово 23 Печоть
741
не имеют встроенных "мозгов" и не понимают ни одного языка PDL Часть
информации, необходимой для общения с такими принтерами, скрыта в
кодах их патентованных драйверов. Такая секретность делает бесполезными
усилия по развитию UNIX-поддержки для подобных устройств.
Последовательные и параллельные принтеры
Последовательные принтеры требуют внешней конфигурации. Более
подробно последовательные порты описаны в главе 7. Программное обеспе-
чение спулера должно “знать" подходящие значения скорости передачи в
бодах и другие параметры последовательного порта, чтобы иметь возможность
общаться с принтером на понятном ему языке. За детальной информацией
об этом и прочих особенностях системы печати обратитесь к шал-страницам.
Только персональные компьютеры имеют параллельный порт Параллель-
ные порты более быстродействующие, чем стандартные последовательные
порты, и, к удовольствию системных администраторов, требуют установки
меньшего числа опций при конфигурировании. Хотя этот стандарт и не
устарел, он предоставляет в наше распоряжение порты, которые все же
требуют относительно небольшой настройки. При работе под управлением
Red Hat Unux первый (обычно он же к последний) параллельный порт —
это /dev/'parportO; в системе FreeBSD используется порт /dev/lptO.
Болес современная технология созда»шя последовательных портов назы-
вается Universal Senal Bus (USB) и еще только прокладывает себе путь в мир
UNIX. Порт USB получил большое распространение в компьютерах, рабо-
тающих под управлением Windows, но его поддержка в среде UNIX еще только
начинается. В то время, когда мы пишем эти строки, последние стабильные
версии FreeBSD и Linux накопеи-то начали включать поддержку USB.
Сетевые принтеры
Некоторые принтеры снабжены полноценными сетевыми интерфейсами,
которые позволяют непосредственно подключать эти принтеры к сети и
принимать задания с использованием одного или нескольких протоколов.
Данные могут быть посланы на подключенные к сети принтеры гораздо
быстрее, чем на принтеры, работающие через последовательный или парал-
лельный порт. Но даже при наличии таких принтеров будет лучше, если все
задания будут пропускаться через одну очередь печати. Во многих сетях
приходится иметь дело с различными комбинациями систем, работающих с
командами ip и 1рг, а также с многочисленными модификациями базовых
систем печати разных производителен.
Поскольку любой компьютер сети потенциально может послать задание
непосредственно на сетевой принтер, возникает конкуренция. Часто это
происходит вследствие недостаточного контроля со стороны администрации
Для того чтобы упростить администрирование, следует попытаться
обустроить сеть так, чтобы все сетевые принтеры контролировались неболь-
шим количеством компьютеров. Другие компьютеры должны просто переда-
вать задания на эти серверы печати Подобный подход позволит избежать
излишних трудозатрат, потому что вам не придется опекать систему печати
на каждой машине. Кроме того, при возникновении каких-либо проблем с
печатью потребуется исследовать относительно немного конфигураций.
Многие сетевые лазерные принтеры включают в свой состав Ipd-сервер.
Благодаря этому UNIX-клненты могут посылать файлы на принтер точно так
742
Часть III. Розное
и
23.3.
же. как они отправляли бы их на BSD-сервер. Поскольку все рассматриваемые
нами операционные системы могут посылать задания на Ipd-сервер, эти
принтеры нам нравятся больше других.
Старые сетевые принтеры требуют, чтобы задания на печать посылались
на ТСР-порт 9100. Такую конфигурацию трудно поддерживать в системах
печати BSD и System V, но она упрощается при использовании системы
LPRng. Если у вас именно такой принтер, мы настоятельно рекомендуем
почитать о системе LPRng в параграфе 23.6.
Жизнь без PostScript
PosiScripi-принтеры, естественно, поддерживаются системами печати
UNIX, и конфигурировать такие принтеры относительно просто. К сожале-
нию, принтеры, не относящиеся к упомянутой категории, в частности
струйные и дешевые модели лазерных, использовать труднее.
Для того чтобы печатать на принтере, не поддерживающем технологию
PostScript, часто бывает необходимо специальное программное обеспечение,
выполняющее "перевод" задания на печать на язык PDL. понятный принтеру.
Некоторые поставщики предоставляют соответствующее программное обес-
печение. как правило, за отдельную плату. Альтернативой этому является
свободно распространяемый пакет ghostscripl. который может преобразовать
предназначенное для PostScript-принтера задание в PDL-страницы, подходя-
щие для сотен принтеров. Вам придется соответствующим образом настроить
фильтр печати, чтобы он “на лету" выполнял необходимое для работы
ghostscript преобразование. В документации glioslscripl приведены соответст-
вующие примеры. При использовании системы LPRng решение этой задачи
облегчается.
Более детальная информация о пакете ghosiscript содержится в параграфе 23.8.
BSD-система печати
Система печати BSD была разработана специально для использования
построчно-печатающих принтеров. К счастью, удачная “конструкция” этой
системы позволяет легко приспосабливать ее для печати на большинстве
современных принтеров. Сетевая часть системы печати BSD также хорошо
масштабируется для использования в больших неоднородных сетях и
позволяет многим компьютерам совместно использовать принтеры. Спулер
печати Ipd фактически стал стандартом де-факто и применяется во многих
сетевых принтерах.
Из числа рассматриваемых в пашей книге систем Red Hat и FreeBSD
используют систему печати BSD как основу для своего программного
обеспечения печати.
Обзор процесса печати
В BSD-системе всем доступом к принтерам управляет демон Ipd, который
обычно находится в каталоге /usr/lib и запускается в процессе загрузки
системы. Демон Ipd отвечает за прием заданий на печать от пользователей и
других (удаленных) демонов Ipd, обрабатывает их и посылает на свободный
принтер. Чтобы выполнить указанные действия. Ipd считывает данные о
конфигурации принтера из файла /etc/printcap — базы данных системы,
содержащей информацию о принтерах.
Гпова 23 Печоть
743
Пользователи, для отправки своих заданий на печать демону Ipd,
пользуются услугами команды Ipr. Эти два процесса взаимодействуют через
сокет /dev/printer.
Рассмотрим процесс выбора принтера, на который необходимо послать
задание печати. Если программе Ipr передается аргумент -Рпринтер. то
пунктом назначения становится принтер. В противном случае проверяется
среда на предмет наличия переменной PRINTER. Если эта переменная
определена, используется ее значение. Во всех остальных случаях задание
перелается на общесистемный принтер, заданный по умолчанию. Почти все
команды, относящиеся к печати, включая Ipq и 1рпп, понимают аргумент -Р
и переменную среды PRINTER.
Как только команда Ipr узнает, на какой принтер направляется текущее
задание, она начинает искать этот принтер в базе данных о принтерах системы
(/etc/printcap). Из данного файла команда Ipr получает имя каталога, в
который следует помещать задания печати для указанного принтера. Этот
"буферный каталог" обычно носит имя /уаг/&р(ю\/имя_нринтера.
Для каждого задания команда Ipr создает в буферном каталоге два файла.
Имя первого состоит из букв cf (control file) и числа, идентифицирующего
задание*. Этот файл содержит справочную информацию и информацию об
обработке задания, например сведения о пользователе, который его передал.
Числовая часть имени файла может состоять максимум из трех цифр, поэтому
при наличии в очереди более 999 заданий система печати начинает работать
некорректно Имя второго файла начинается с букв df (data file) и
заканчивается тем же числом. Этот файл содержит данные, подлежащие
печати. После его постановки в очередь команда Ipr уведомляет демона Ipd
о существовании задания.
Получив это уведомление, демон Ipd обращается к файлу printcap и
выясняет местонахождение пункта назначения: локальный он или удаленный
Если в файле printcap указано, что принтер подключен локально, демон Ipd
проверяет наличие демона печати, обрабатывающего соответствующую оче-
редь, и в случае отсутствия такового создает его (т.е. экземпляр самого себя).
Если соответствующий принтер подключен к другому компьютеру, демон
Ipd устанавливает соединение с демоном Ipd удаленного компьютера и
пересылает туда файл данных и управляющий файл Затем демон Ipd удаляет
локальные копии этих файлов.
Планирование заданий печати осуществляется по алгоритму “первым
пришел — первым обслужен” (FIFO), но системный администратор может
при желании изменить порядок печати с помошыо команды 1рс. К сожалению,
нет возможности дать системе печати инструкцию о том, чтобы она все время
отдавала предпочтение заданиям, направленным на печать тем или иным
пользователем или компьютером.
Когда задание готово к печати, демон Ipd создает ряд программных
каналов между буферным файлом и печатающим устройством для передачи
данных, подлежащих печати. Посередине этой цепочки демон Ipd устанавли-
вает процесс-фильтр, в задачи которого входит просмотр и, возможно,
редактирование содержимого потока данных, прежде чем они поступят на
принтер.
Процессы-фильтры могут выполнять над данными различные преобра-
зования либо вообще ничего не делать. Основное их назначение — обеспе-
чивать форматирование для специальных прикладных программ и
В процессе обработки задания программой Ipr этот файл называется tf (temporary file). После
записи файла Ipr меняет его имя с tfxxx па cfxxx.
744
Чость III. Розное
поддерживать все зависящие от устройств протоколы, которые мотуг пона-
добиться для работы с данным принтером. В командной строке 1рг можно
назначить для принтера другой фильтр вместо заданного по умолчанию
Управление средой печати
На практике для ежедневного сопровождения системы печати необходимо
знать всего три команды: Ipq, Iprm и Ipc. Команда Ipq позволяет просматривать
очередь заданий, ожидающих печати на конкретном принтере. Посредством
команды Ipmi можно удалять одно или несколько из этих заданий (при этом
стираются соответствующие файлы данных и из системы печати удаляются
все ссылки на них). Обе эти команды доступны для пользователей, и обе
работают в сети, не оказывая влияния на работу системы.
Команда 1рс позволяет вносить изменения в среду печати: например,
отключать принтеры и переупорядочивать очереди печати. Некоторые из ее
функций доступны для пользователей, но в основном это средства админи-
стратора.
Тоблицо 23.1. Комонды системы печоти BSD
Комондо	Местонахождение	Выполняемая функция
Ipq	/usr/bin	Показывает содержимое и статус очереди на печать
1рг	/usr/bin	Ставит задания в очередь на печать
Iprm	/usr/bin	Ликвидирует очередь иля отменяет задание иа печать
Ipc	/usr/sbin	Управляет принтером илн очередью на печать
Ipd	/usr/sbin	Включает н очередь и выводит на принтер задания на печать
iptest	/usr/bin	Создаст тестовый ASCI 1-код
Ipunlock	/usr/bin	Разблокирует ''зависший” принтер (только в Red Hat)
printtool	/usr/bin	Конфигурирует указанную систему печати (только в Red Hat)
Iptcontrol	/usr/sbin	Конфигурирует для печати параллельный порт (только во FreeBSD)
Демон Ipd: BSD-спулер печати
Когда демон Ipd приступает к своей работе, он считывает файл
/etc/printcap. в котором содержатся данные о принтерах системы. Затем он
начинает печать какого-нибудь задания, ожидающего этого момента в
буферном каталоге, и принимается за считывание нового задания на печать.
Демон Ipd, запущенный с флагом -1. регистрирует задания на печать в
системе Sysiog от имени средства “1рг”. Прн отсутствии флага -I этот демон
регистрирует только системные ошибки.
Управление доступом производится на каждом компьютере, система
печати BSD не позволяет осуществлять контроль за конкретным удаленным
пользователем* Только компьютеры, имена которых значатся в файлах
На самом деле возможна реализация аутентификации в фильтрах печати. Но так как в
большинстве систем используются различные варианты фильтров, на практике не поддер-
живается единый способ контроля доступа.
Глово 23. Печоть
745
/etc/hosts.equ или /etc/hosts.Ipd. имеют возможность ставить задания в очередь
на печать. Помните, что добавление имени какого-либо компьютера в файл
/etc/hosts.equ iv означает абсолютное “доверие” этому компьютеру. Мы
рекомендуем всегда использовать файл /etc/hosts.lpd для контроля за доступом
к принтеру. Если необходима более надежная модель зашиты, рассмотрите
возможность перехода к системе LPRng.
Более подробную информацию о файле hosfs.eguiv можно найти в параграфе 21.6.
Команда Ipr: выдача заданий на принтер
Единственная программа в системе BSD. которая может выстраивать
подлежащие печати файлы в очередь. — это команда Ipr. Все остальные
программы, используемые для печати файлов (например, программы cnscrtpl
и netscape), делают это. вызывая программу Ipr.
В качестве аргументов команды !рг могут быть использованы несколько
полезных опций. Флаг -Ячисло позволяет напечатать количество копий, равное
значению число, а флаг -h запрещает печать титульной страницы. Как
напоминание о временах, когда принтеры печатали очень медленно, суще-
ствует флаг -т, обеспечивающий уведомление пользователя о том, что его
задание на печать выполнено, по электронной почте.
Например, чтобы напечатать две копии файла thesis на принтере howlcr-lw.
следует ввести следующую команду:
% Ipr -Phowler-lw -#2 thesis
Команда Ipq: просмотр очереди печати
Команда Ipq обычно применяется с опцией -Р но можно использовать
и другие аргументы командной строки, чтобы ограничить перечень просмат-
риваемых заданий. Выходные данные команды Ipq выглядят примерно так:
% Ipq
anchor-lj is ready and printing
Rank	Owner	Job	Files	Total S:
active	garth	314	domain.2x1.ps	296778 i
1st	kingery	286	standard input	17691 i
2nd	evi	12	appendices	828 i
3rd	garth	13	proc	43229 i
4 th	scoct	14	periodic	16676 1
5th	garth	16	standard input	4 89 i
В	первой колонке		дается информация	О TOM,
>1 ze
byres
bytes
bytes
bytes
bytes
bytes
в каком порядке будут
распечатываться задания. Эти сведения в принципе не нужны, потому что
выходные строки всегда расположены по порядку; активное задание указы-
вается первым. Если первое задание обозначено как 1st. а не как active.
это значит, что демон печати для принтера не запущен.
Во второй колонке дается имя пользователя, который послал задание на
печать. В третьей — идентификационный номер задания; его необходимо
знать, если впоследствии планируется обрабатывать это задание с помощью
команд Ipmi или 1рс. В четвертой колонке перечисляются указанные в
командной строке ipr файлы, посылаемые на печать. Если данные для вывода
на печать поступили по программному каналу' (как. например, первое и пятое
задания нашего примера), в этой графе будет стоять запись standard input.
В пятой колонке указывается размер задания. Это значение соответствует
размеру задания до его передачи в программу-фильтр и не дает информации
о том. сколько страниц займет задание и как долго оно будет печататься.
7*т6
Чость III Розное
Команда Iprm: удаление заданий
Самая распространенная форма команды Iprm — Iprm идзадания, где
идзадания — идентификатор задания согласно выходным данным команды
Ipq. Команда Iprm пользователь удаляет все задания, принадлежащие указан-
ному пользователю. Команда Iprm без аргументов удаляет активное задание.
Если указать Iprm то будут удалены все задания, переданные на печать,
если данную команду задает пользователь root, удаляются все задания,
стоящие в очереди. Обычный пользователь не может удалить задания другого
пользователя, в то время как суперпользователь имеет право удалять любое
задание
Выходную информацию команда Iprm выдает только в случае успешного
выполнения, в противном случае она молча уходит со сиены. Если вы не
увидели что-нибудь наподобие
dfA621xlnet dequeued
cfA621xinet dequeued
это значит, что команда Iprm вызвана неправильно.
Система печати ре1истрирует происхождение задания и имя пользователя,
который послал его на печать, что учитывается соответствующим процессом
Iprm Так. пользователь ganh@boulder не эквивалентен garth@sigi. и ни один
из них не может удалять зада угия другого.
Попытка удалить с помощью команды Iprm активное задание может
вызвать проблемы на некоторых принтерах (особенно на лазерных, где
используется программное обеспечение TranScript фирмы Adobe). Пронесс-
фильтр задания надлежащим образом не уведомляется о прерывании,
вследствие чего вся система со скрипом останавливается, а процесс-фильтр
продолжает блокировать порт принтера, не давая использовать его другим
процессам.
Единственный способ исправить положение заключается в определении
номеров пронессов-фильтров с помощью команды ps и уничтожении нх
вручную. Команда Ipc в такой ситуации не годится. В принципе, при
зависании демона Ipd есть хорошее лекарство — перезагрузка системы, но
это радикальная мера. Прежде чем перезагружать систему, можно еще
попробовать уничтожить и перезапустить главный экземпляр демона Ipd
Команда Ipc: внесение административных изменений
Команда Ipc выполняет следующие функции:
•	включение и выключение режима постановки заданий в очередь на
конкретный принтер;
•	включение и выключение печати на конкретном принтере:
•	удаление всех заданий из очереди принтера;
•	перенесение задания в начало очереди принтера;
•	управление демоном Ipd;
•	получение информации о состоянии принтера.
Когда система печати работает гладко, команда Ipc функционирует просто
отлично. Стоит только '‘захлебнуться" фильтру или появиться другой
незначительной проблеме, как команда Ipc полностью “сходит с ума" и
начинает, помимо всего прочего, просто врать: иногда она заявляет, что все
исправлено, тогда как на деле она и пальцем не пошевелила Приходится
Ггово 23. Печать
747
устранять проблемы вручную и даже отключать и включать питание
оборудования, если печать идет уж очень плохо.
Команду Ipc нельзя использовать в сети; нужно зарегистрироваться на
компьютере, к которому подключен манипулируемый принтер. Обычно
команда работает в диалоговом режиме, хотя возможен и разовый вызов
путем включения интерактивной директивы в командную строку 1рс. В среде
Ipc допустимо применение следующих директив.
help [команда]
Если директива help указывается без аргументов, то выдается краткий
перечень всех команд, которые можно использовать в среде Ipc. При наличии
аргумента выдается однострочное описание конкретной команды.
«п*Ь1« принтер
disable принтер
Эти команды служат для включения и выключения режима организации
очереди заданий к указанному принтеру. Если постановка задания в очередь
невозможна, пользователю вежливо сообщат об этом. Указанные операции
выполняются посредством установки или сброса соответствующего бита кода
прав доступа /var/spool/npwHwep/lock для группы.
start принтер
stop принтер
Директива start включает, а директива stop — выключает печать на
указанном принтере. После выключения печати на принтере постановка
заданий в очередь продолжается, однако вывод их на печать приостанавли-
вается до тех пор, пока печать не будет запущена вновь. Эти операции
выполняются посредством установки или сброса бита выполнения для
владельца файла /var/spool/npuwmep/lock. Кроме того, указанные директивы
уничтожают и запускают соответствующие демоны для принтера. Получив
директиву stop, система печати сначала завершает активное задание и только
после этого выключает печать.
bort принтер
Директива abort работает так же, как stop, но при этом не завершается
активное задание. После возобновления печати задание будет печататься с
самого начала
down принтер сообщение
up принтер
Эти директивы влияют и на организацию очереди, и на печать. Они
используются в случае серьезной поломки принтера и необходимости
отключения его на длительный период времени. Параметр сообщение в
директиве down может иметь произвольную длину (в пределах одной строки)
и не должен заключаться в кавычки. Это сообщение помещается в файл
/var/sprol/npuwzwfp/status принтера и выдается всем пользователям, которые
запускают команду Ipq Как правило, сообщение содержит краткое разъясне-
ние причины выхода принтера из строя и информацию о том, когда он вновь
начнет работать. Действие директивы up обратно действию директивы down
с 1 шп принтер
748
Чость III Розное
Эта директива удаляет из очереди к принтеру все задания, включая
активное. Поскольку демон печати для данной очереди все равно будет
содержать ссылки на файлы текущего задания, то оно будет завершено.
topq принтер ид_задания
topq принтер имя_пользователя
Первая директива topq перемешает в начало очереди печати указанное
задание, а вторая — все задания, принадлежащие пользователю имя_пользо-
ватеяя.
restart принтер
Данная директива используется для перезапуска демона печати, который
таинственным образом “скончался”. О том, что демон "мертв”, можно узнать,
когда команда Ipq сообщит: "No daemon present”. На первый взгляд может
показаться, что действие директивы restart аналогично действию последова-
тельности директив stop/start, однако это не так: если продолжает работать
фильтр принтера, то с помощью директивы restart перезапустить принтер
нельзя.
tatua принтер
Эта директива сообщит следующие сведения об указанном принтере:
ставятся ли задания в очередь к нему, включена ли печать, сколько заданий
стоит в очереди, каково состояние демона данного принтера. Если в очереди
заданий нет, появится нечто вроде
lpc> status csr
cer:
queuing is enabled
printing is enabled
no entries
no daemon present
Факт отсутствия демона сам по себе не является причиной для
беспокойства; если очередь пуста, демон принтера “исчезает” и запускается
вновь главным экземпляром демона Ipd только при постановке в очередь
нового задания.
Файл /etc/printcap
Файл /etc/printcap является основной базой данных BSD-системы печати.
На принтер можно передавать задания только в том случае, если он описан
в этом файле.
Для файла /etc/printcap используется тот же формат, что и для файлов
/etc/termcap и /etc/remote. Каждый элемент начинается со списка имен
принтера, разделенных вертикальной чертой (|). Затем следует ряд параметров
конфигурации, разделенных двоеточиями. Каждый параметр имеет вид
хх=сгпрока или хх#число, где хх — двухсимвольное имя параметра, а строка
и число — присваиваемые ему значения. Если никакого значения не
присваивается, значит, переменная является булевой и ее присутствие
означает “истина”.
Допускаются пустые операторы: два двоеточия, стоящих рядом. Рекомен-
дуется начинать и заканчивать каждую строку двоеточием, чтобы впоследст-
вии легче было вносить изменения. Комментарии в файле /etc/printcap
Главе 23 Печоть
749
должны начинаться со знака решетки (*). Элемент может состоять из
нескольких строк, причем строки, за которыми следуют строки продолжения,
должны заканчиваться обратной косой чертой. Строки продолжения в целях
повышения наглядности текста программы обычно размешаются с некоторым
сдвигом по отношению к первой позиции.
В качестве иллюстрации к описанию синтаксиса файла /etc/printcap дадим
небольшой пример. Более полный пример приведен ниже, после описания
переменных файла printcap
*	HP LaserJet 5М remote printcap. CS Department.
anchor-ljtcer11-561 LaserJet 5M in cer lab;\
;lp~/var/spool/Ipd/anchor-lj/-null:\
:sd /var/spool/lpd/anchor-lj:\
:lf=/var/adm/lpd-errs;\
:rw:mx#0;rnv=anchor:rp -anchor-1j;
И1 первой строки видно, что cer. anchor-lj, 1-56 и LaserJet 5M
in cer lab — Это эквивалентные имена одного принтера. Данные имена
представляют собой хорошо известные сокращения, номер комнаты, в
которой находится принтер, и его полное название. Принтерам можно
присваивать сколько угодно имен, но обязательно следует указывать минимум
три формы основного имени
•	сокращенную (три четыре символа, которые удобно вводить, например г.ег);
•	полную (имя компьютера и тип принтера, например anchor-lj);
•	описательную (прочая информация, например LW Plus in cer lab).
Следующие две строки нашею примера содержат установки конфигура-
ции для устройства с указанным именем (1р). каталога спулинга (sd) и
журнального файла (1 f) Последняя строка определяет параметры соединения
с принтером, в ходе которого осуществляется запись-считывание (rw),
максимальный размер файла (шх. в данном случае размер не ограничен), имя
удаленного компьютера (rm) и имя удаленного принтера (гр).
Задания, переданные в систему печати без конкретного пункта назначе-
ния, направляются на первый принтер, среди указанных имен которого есть
Llp” . Имя “ip" нельзя использовать в качестве основного имени принтера,
поскольку замена стандартного принтера в этом случае будет затруднена.
Переменные бозы данных printcop
Высокие "адаптационные способности" системы печати BSD в значи-
тельной степени обусловлены особенностями файла printcap. Переменные
базы данных printcap описаны на соответствующей man-странице руководства,
а здесь мы рассмотрим лишь наиболее часто используемые переменные. Они
приведены в табл. 23.2.
Все элементы записи printcap должны обязательно включать абсолютные
имена буферного каталога (sd). журнального файла ошибок (If) и устройства
печати (1 р). Если у вас современный принтер, то следует указать, что этот
принтер открыт для записи и чтения (rw). чтобы он мог посылать сообщения
о своем статусе и ошибках компьютеру.
75')
Чость III. Розное
Таблица 23.2 Часто используемые переменные программы printcop
Пв1 ембньон	Тип	Назначение	Пример
sd	строка	Каталог спулинга	sd=/var/spool/lpd/howler-J
if	строка	Журнальный файл ошибок	If»/vaг/log/1рг
Ip	строка	Имя устройства	lp-/dev/lpC
at	строка	Файл учетных записей	af=/usr/adm/lpr.acct
rm	строка	Имя удаленного компьютера	rm»oeast.xor.com
rp	строка	Имя удаленного принтера	rp=howler-1w
of	строка	Выходной фильтр	of=/usr/libexec/lpr/lpf
if	строка	Входной фильтр	if=/usr/sbin/stylascii
mx	число	Максимально- допустимый объем файла	mx#0
sh	булево значение	Отмена печати заголовков	sh
Переменная sd: буферный каталог
У каждого принтера должен быть свой буферный каталог. Все буферные
каталоги должны находиться в одном родзггельском каталоге (обычно лто
/var/spool) и иметь имена, совпадающие с полными именами обслуживаемых
ими принтеров (в нашем примере anchor-1 j) Буферный каталог необходим
даже в том случае, если описываемый принтер подключен к другому
компьютеру: задания находятся на локальном компьютере до тех пор. пока
они не будут переданы на печать.
При инсталляции нового принтера необходимо создать буферный каталог
вручную и назначить ему код прав доступа 775. И в качестве владельца, и
в качестве группы для этого каталога должен быть указан пользователь daemon
Буферный каталог для принтера включает также два статусных файла:
lock и status. Файл status содержит однострочное описание состояния
принтера. Эту строку формирует демон Ipd и использует команда Ipq.
Назначение файла lock заключается в том. чтобы избежать активизации
нескольких экземпляров демона Ipd в одной очереди, кроме того, в нем
хранится информация об активном задании Программа Ipc в процессе
управления спулингом и печатью на принтере изменяет код прав доступа к
файлу lock
Переменная If: журнальный файл
Ошибки, сообщения о которых присылаются фильтрами печати, регист-
рируются н файле, указанном в данной переменной. Один журнальный файп
ошибок может коллективно использоваться всеми принтерами и размешаться
где угодно. При создании записи этого файла указывается имя принтера-”на-
рушителя” В приведенном выше примере журнальный файл — /var/adm/lpd-
errs Журнальные файлы должны быть даже для удаленных принтеров — а
вдруг возникнет проблема, касаюшаяся связи с удаленным компьютером?
Более подробную информацию о журнальных файлах можно найти в главе / /.
Гпаво 23 Печать
751
Имейте в виду, что демон Ipd посылает сообщения об ошибках в систему
Syslog. Некоторые фильтры также направляют свои сообщения об ошибках
в систему Syslog, никак не регистрируя их в определенном в базе данных
printcap журнальном файле. При возникновении проблем нужно проверять
оба названных файла.
Переменная 1р: имя устройства
Параметр имя__устройства должен задаваться только для локального
принтера. Для локального принтера, подключенного через последовательный,
параллельный или SCSI-порт, это файл в каталоге /dev. с помощью которого
происходит обращение к данному принтеру. Если в базе данных printcap
указан сетевой принтер (т.е, принтер в сети, а не просто ‘'удаленный”: см.
параграф 23.8), то в переменной 1р должен быть задан фиктивный (dummy)
файл (важен факт существования этого файла, но в качестве файла устройства
он не применяется).
Программа Ipd использует данные файла блокировки, соответствующего
указанному в переменной 1р устройству, чтобы определить, используется
принтер или нет. Даже если доступ к принтеру осуществляется по сетевому
соединению, переменная 1р обязательно должна быть задана. Необходимо
указать уникальный файл, который существует и расположен на локальном
диске.
Переменная rw: режим открытия устройства
Если принтер может посылать информацию о своем состоянии компью-
теру через свой файл устройства, то необходимо, чтобы была определена
булева переменная (rw), потому что это устройство должно быть открыто
как для записи, так и для чтения. Режим чтения-записи полезен, поскольку
позволяет сообщать данные об учетной записи и статусе, поэтому некоторые
фильтры требуют установления такого режима.
Переменная of: учетный файл
Если вы намереваетесь взимать плату за пользование принтером или
просто хотите учитывать объем информации, распечатываемой пользователя-
ми, следует включить учет по данному принтеру, указав учетный файл.
Учетный файл нужно задавать только на том компьютере, к которому принтер
подключен физически, так как учетные записи делаются только после
реального вывода задания на печать.
Для обработки учетной информации используется команда рас. Обычно
учетный файл данных принтера называется /var/adm/npuKwep-acct. В этот
файл записывается количество страниц, напечатанных по каждому заданию
(обычно не соответствующее действительности), имя компьютера, с которого
было запущено задание, и имя владельца задания.
Одной из обязанностей входного фильтра принтера является генерация
учетных записей. При использовании PostScript-принтеров вообще не стоит
доверять счетчику страниц, если только фильтр нс запрашивает показания
счетчика страниц до и после печати.
Переменная тк предельные размеры файлов
Переменная тх используется для задания предельного размера файла,
посылаемого на печать. Однако для большинства принтеров (кроме построч-
но-печатающих) задавать эту величину бессмысленно. При печати небольших
PostScript- и PCL-файлов могут быть выданы сотни никому не нужных
страниц. Это несоответствие между размером файла и количеством страниц
752
Часть III Розное
хорошо выявляется на практике, когда студенты пытаются печатать скомпи-
лированные версии двоичных файлов, содержащих разработанные ими
программы Если все пользователи обладают достаточной квалификацией, не
стоит обращаться к этом}' средству. У некоторых пользователей имеются
вполне законные причины для печати больших файлов.
В некоторых системах значение переменной тх, устанавливаемое по
умолчанию, отлично от нуля (0 означает отсутствие ограничений), и для того,
чтобы иметь возможность выводить на печать большие задания, необходимо
явно указать гг.х#0). Отметим, что переменная тх является числовой, поэтому
нельзя указывать тх=0.
Если действительно требуется знать, какое количество страниц могут
печатать люди, необходимо использовать заказные программы-фильтры или
перейти к системе LPRng.
Переменные rm и гр: удаленный доступ
В большинстве случаев к принтеру нужно обращаться не с одного, а с
нескольких компьютеров сети. Даже если принтер — сетевое устройство,
следует выбрать один компьютер и назначить его ответствеггным за связь с
принтером. Все остальные машины должны пересылать задания на этот
компьютер. Это позволяет демону Ipd создавать единую очередь заданий, что
исключает случаи конфликтов между’ компьютерами за право управления
принтером. Кроме того, если печать не работает, вы будете знать, где искать
причину.
В файле printcap “удаленного” компьютера (компьютера, не имеющего
непосредственного соединения с принтером) присутствует группа из двух
переменных, где указывается, куда посылать задание (как в примере,
рассмотренном выше). В переменной rm определяется компьютер, на который
должны направляться задания, а переменной гр задается имя принтера на
этом компьютере. Ниже процесс удаленной печати рассмотрен более подроб-
но и проиллюстрирован на конкретных примерах.
На первый взгляд, файл /etc/printcap — сущий кошмар для администра-
тора, потому что элементы, в которых описывается локальный принтер,
отличаются от элементов, где описывается принтер удаленный. Выход из этой
ситуации может быть следующим: нужно сделать имена для принтеров
разными на локальном и удаленном компьютерах, например howier-lw-local
и howler-lw. Такая конфигурация делает принтер howler-lw “удаленным” даже
для того компьютера, к которому он подключен, но. тем не менее, все
отлично работает. Однако если вы хотите использовать команду 1рс, следует
обращаться к принтеру howler-lw-local.
Переменные of, if, nf: фильтры печати
Фильтры выполняют целый ряд функций Фильтр печати, заданный по
умолчанию (обычно это /usr/lib/lpf), производит обработку управляющих
символов в подлежащем печати тексте и, если требуется, генерирует учетную
запись. На заре эпохи UNIX на фильтры часто возлагались обязанности по
выполнению различных функций форматирования, но сейчас эта практика
уже не так распространена, как раньше. Единственные специальные фильтры,
с которыми вам, возможно, придется иметь дело, — это фильтры для
обработки выходной информации программы trofT. выходной информации
системы ТеХ и дампов экрана.
Если у вас только текстовый принтер, вообще забудьте о том, что такое
фильтры Если у вас лазерный принтер, наборное устройство или графопо-
строитель, то необходимые фильтры, как правило, имеются в комплекте
Глово 23 Печоть
753
поставки программного обеспечения. Если вам нужно конфигурировать
принтер, для которого у вас нет программных средств, придется внимательно
изучить информацию о различных фильтрах, приведенную в этой главе
В противном случае лучше пропустить эти сведения и жить в блаженном
неведении.
Фильтры — это, как правило, просто сценарии shell, которые вызывают
ряд конвертирующих программ Программа-фильтр должна принимать зада-
ние печати со стандартного ввода, конвертировать это задание в формат,
поддерживаемый данным устройством, и посылать результат на стандартный
вывод.
Если при выполнении программы 1рг пользователь не указал фильтр, то
будет использоваться либо входной фильтр, либо выходной. Эти имена нельзя
назвать удачными, ибо оба фильтра на самом деле служат для посылки данных
принтеру.
Когда в файле /etc/printcap присутствует переменная if. но нет пере-
менной of, устройство будет открываться один раз для каждого задания, а
фильтр будет посылать одно задание на принтер и завершать работу.
Если есть выходной фильтр, но нет входного, то демон Ipd однократно
откроет устройство и вызовет программу-фильтр для посылки сразу всех
заданий, стоящих в очереди. Это средство полезно для тех устройств,
установление соединения с которыми занимает много времени; но такие,
однако, встречаются редко.
При наличии в файле /etc/printcap переменных .; и of выходной фильтр
будет использован для передачи страницы заголовка (и будет вызван даже в
том случае, если печать заголовков отключена), а входной будез вызван для
передачи задания. Такая комбинация слишком сложна для простых смертных,
поэтому лучше ее избегать.
Если приходится создавать новые фильтры, ориентируйтесь на входные
фильтры: их легче отлаживать.
Входные фильтры вызываются с многочисленными аргументами, которые
в каждой реализации свои. Наиболее заслуживающие внимания из них —
имя пользователя, имя компьютера и имя учетного файла. Если вы желаете
организовать учет работы принтера, входной фильтр должен генерировать
учетные записи и добавлять их к учетному файлу. Если необходимо
ограничить доступ к принтеру (например, запретить доступ пользователю
guest на всех компьютерах), то эту обязанность тоже нужно возложить на
входной фильтр, поскольку у демона Ipd нет встроенных средств ограничения
доступа отдельных пользователей к системе печати
Чтобы проиллюстрировать использование фильтров, рассмотрим очень
простой пример с входным фильтром. Этот пример — для PostScript-прин-
тера, подключенного через последовательный порт к локальному компьютеру:
#!/bin/csh -f
/usг/local/bin/textps $* I /usr/local/bin/psreverse
Поскольку принтер подключен последовательно, демон Ipd открывает это
устройство с соответствующими режимами согласно указаниям в файле
/etc/printcap. Первой вызывается программа lextps. которая анализирует
входные данные и определяет их формат. Если это не формат PostScript
(который поддерживает наш принтер), данные конвертируются в этот формат.
Указанная программа берет все переданные ей аргументы фильтра ($*) и нв
основе данной информации должна генерировать учетные записи. Вторая
754
Чость III. Розное
программа, psreverse, изменяет порядок следования страниц на обратный,
чтобы они выходили в соответствующей последовательности.
Переменные базы данных printcap
для последовательных устройств
Следующие несколько переменных полезны только для локальных
принтеров, подключаемых к последовательному порту. Если вы устанавли-
ваете сетевой принтер, остальную часть этого параграфа можете не читать.
Вместо этого откройте инструкцию, найдите спецификации, касающиеся
линии связи, и изучите их.
С помощью переменных файла printcap можно контролировать параметры
связи трех типов: скорость в бодах, биты установки флагов и биты локального
режима.
Переменная Ьг скорость передачи в бодах
Если принтер подключен к последовательному порту, понадобится
переменная Ьг, Последовательный принтер ничем не отличается от других-
аппаратных средств: для нормального функционирования следует согласовать
набор коммуникационных параметров, определяющих взаимодействие прин-
тера и компьютера, в частности скорость передачи, четность и лея ику
управления потоками Конфигурация принтера имеет много обшего с
конфигурацией терминала. Обзор последовательных устройств и кабельных
систем приведен в главе 7.
В файле printcap можно задавать три параметра' скорость передачи в
бодах, биты флагов и биты локального режима. Скорость передачи в болах —
целое число. Поскольку это числовое значение, для его установки использу-
ется знак решетки (Л). Например, Ьг#9600 устанавливает скорость передачи
9600 бит/с.
Переменные fc и fs: биты флагов
Значения битов флагов и битов локального режима (см. ниже) — тоже
целые числа, но установкой каждого бита такого числа задается конкретный
параметр порта. Для правильной установки этих параметров необходимо
найти описание значений каждого бита на man-страниие, посвященной
драйверу tty (раздел 4, а не I) и определить, значения каких битов следует
установить или сбросить. Значения надлежит корректировать только на том
компьютере, к которому подключен принтер.
Существуют две переменные, которые можно использовать для коррек-
тировки битов флагов: fc и fs. Переменная fc (flag clear — сброс флага)
задает биты, которые нужно выключить, a fs (flag sei — установка флага) —
биты, которые нужно включить. Биты, не указанные ни в одной из этих
переменных, принимают значения, заданные по умолчанию. Одновременно
устанавливать и сбрасывать бит бессмысленно (но развлечения ради можно
попробовать).
Подробно назначение каждого бита флагов описано на man-странице
драйвера tty.
Переменные xs и хс: биты локального режима
Биты локального режима полезны только для построчно-печатаюших
принтеров, подключаемых к последовательному порту. Переменные хс и xs
убирают и устанавливают индивидуальные биты режима во многом анало-
гично тому, как переменные fc и fs убирают и устанавливают биты флагов
Глобо 23. Печоть
755
Различие между битами флагов и битами локального режима состоит в том,
что последние предназначены для конфигурации последовательного драйвера,
а первые — для реального канала связи. Большая часть битов режима
предназначена для использования в интерактивных видеотерминалах и не
относится к конфигурированию принтера.
Расширения базы данных printcap
У связки программ Ipr/lpd есть одна прекрасная особанность: они не
обращают внимания на нестандартные переменные printcap. Во многих
случаях, когда принтеру нужно больше информации о конфигурации, чем
имеется в базовой системе, можно определять в файле printcap дополнитель-
ные переменные, которые будут использоваться фильтрами принтера.
Например, для выходного фильтра сетевого принтера требуется сетевое
имя этого устройства. В элемент файла printcap для этого принтера можно
добавить следующую запись:
:nn=>laser. Colorado. edu : \
Использование такого рода расширений позволяет хранить всю инфор-
мацию о конфигурации принтера в одном, удобном для вас месте. Если вы
вдруг увидите в файле printcap переменные, не упомянутые на шап-странице,
поищите их значения в документации на драйверы принтера.
В нашей сети документируется физическое местоположение каждого
принтера. Наши принтеры имеют записи типа
:lo**Room 423, Engineering building
Мы используем сценарии, которые отслеживают наличие бумаги и запас
тонера в этих принтерах и при необходимости посылают в группу техниче-
ского обслуживания сообщения типа “Добавьте бумагу в принтер, находя-
щийся в комнате 423 Инженерного корпуса”. За более подробной
информацией о мониторинге сетевых устройств обратитесь к главе 20.
Печать не на принтеры
Недавно мы рассматривали случай "творческого неправильного исполь-
зования”. о котором сообщил Шон Маккрири (Sean McCreary), когда система
печати BSD применялась для загрузки в буфер музыкальных файлов в формате
MP3, в результате чего получался своеобразный музыкальный автомат,
Оставляя в стороне этическую сторону дела, можно сказать, что это —
прекрасная характеристика гибкости системы печати
Запись в файле printcap выглядит примерно так:
трЗ-local;\
:sd=/var/spool/lpd/mp3-local;\
:lf-/var/log/lpd~errs:\
:if>/usr/local/lib/mp3-play:\
:1р«/dev/null:\
:тх#0:
Настоящий МРЗ-плейер, апгр, по умолчанию не читает данные из потока
stdin, поэтому сценарий, состоящий из одной строки, называемый mp3-play,
связывает его с системой печати:
#! /bin/sh
exec /usr/local/bin/atnp -
756
Чость III. Резное
23.4. Печать в System V
К сожалению, система печати System V проектировалась без учета
потребностей печати в сетях, и к новым условиям работы адаптируется с
трудом. Использующие ее производители внесли многочисленные изменения,
одни из которых способствовали расширению ее функциональных возмож-
ностей, в то время как назначение других объяснить трудно.
Из числа рассматриваемых нами систем System V используют Solaris и
HP-UX. Однако обе существенно ее модифицировали. Ниже будет рассмот-
рена стандартная система с многочисленными примечаниями, касающимися
конкретных систем.
Обзор
Пользователь, желающий что-нибудь вывести на печать, должен исполь-
зовать либо команду 1р, либо команду, которая косвенно вызывает 1р. Команда
1р получает входной файл и помешает его в буферном каталоге, соответст-
вующем пункту назначения этой информации. Демон Ipsched определяет,
когда и где должен быть распечатан конкретный файл, а затем выполняет
интерфейсную программу, которая форматирует данные и выводит их на
заданный принтер. Краткое описание команд системы печати System V
приведено в табл. 23.3.
Тоблицо 23.3. Комонды печоти АТТ-системы
	Команда	Местонахождение Функция	
	accept	/usr/sbin	Запуск приема заданий для данного устройства
	cancel	/bin	Отмена поставленного в очередь или печатае- мого задания
	disable	/bin	Выключение печати на устройстве
£	enable	/bin	Включение печати на устройстве
¥	Ip	/bin	Постановка задания в очередь на печать
V	Ipadmin	/usr/sbin	Конфигурация системы печати
ш 3 ш О	Ipmove	/usr/sbin	Перемещение задания с одного устройства на другое
	Ipsched	/usr/lib	Вызов демона-планировщика принтера
	Ipshut	/usr/sbin	Отключение демона Ipse bed
	Ipstat	/bin	Вывод информации о состоянии системы
	reject	/usr/sbin	Прекращение приема заданий для данного устройства
	Ipfilter	/usr/sbin	Управление фильтрами печати
	Ipfonns	/usr/sbin	Управление использованием предпечатных форм
	Ip users	/usr/sbin	Управление приоритетами очереди
V)	Ipget	/bin	Считывание значений параметров конфигура- ции
	Ipset	/bin	Модифицирование параметров конфигурации
	Ipalt	/bin	Модифицирование заданий в очереди
3	Ipr	/bin	Обеспечение поддержки BSD-печати
	Ipana	/usr/sbin	Анализ регистрационных записей
	Ipfence	/usr/sbin	Установка минимального приоритета занято- сти для принтера
Глово 23. Печоть
757
Пункты назначения и классы
Пункт назначения имеет имя, которое может состоять максимум
из 14 букв, цифр и знаков подчеркивания. Помимо имени, для пункта
назначения определяется принадлежность к классам (классов может быть нуль
или более). Пункт назначения, как правило, — принтер, но это не
обязательно. Например, таковым может являться обычный текстовый файл,
в который различные пользователи помещают свою информацию. Систему
печати можно использовать для предотвращения ситуаций, когда два человека
пытаются дополнить файл одновременно.
Класс — это группа пунктов назначения, которые можно объединить по
какому-либо признаку. Например, если два принтера стоят в одной комнате,
их можно отнести к одному классу. Демон Ipsched будет направлять вывод,
предназначенный для этого класса, на тот из двух принтеров, который
свободен в данный момент. Имена классов составляются по тем же правилам,
что и имена пунктов назначения.
В остальной части главы вместо термина “пункт назначения” чаще всего
используется слово “принтер”, даже если пункт назначения принтером не
является.
Краткое описание команды 1р
Команда ip — это команда пользовательского уровня, которая применя-
ется для постановки данных в очередь на печать. Команда 1р помешает копию
подлежащих печати данных (которые могут поступать либо из именованных
файлов, либо из стандартного ввода) в файл или в совокупность файлов в
буферном каталоге. Буферный каталог для пункта назначения обычно имеет
имя /var/spool/lp/re<]iicst/««3«, где назн — имя, под которым этот принтер
или класс принтеров известны команде 1р.
Имя файла-копии имеет вид хххп, где п — идентификационный номер
задания, присвоенный командой 1р, а ххх зависит от конкретной системы
Это имя файла служит как пользователю — для идентификации задания, так
и системе печати — для внутренних целей. Далее мы будем называть это
имя “идентификатором задания”.
Если в вызове команды 1р указана опция -d пунктназначения, то входная
информация ставится в очередь для вывода на пункт назначения, где
пункт_назначения — принтер или класс. Если опция -d не указана, команда
1р использует в качестве имени устройства ввода значение переменной среды
LPDEST, если она установпена. Если последняя не установлена, команда 1р
ставит данные в очередь для вывода на устройство, используемое по
умолчанию, если таковое задано системным администратором, или отклоняет
запрос, если оно не задано. (Устройство, используемое по умолчанию, можно
задать командой Ipadmin -d.)
В Solaris, если устройство, не выбираемое по умолчанию, указывается
командой Ipadmin -d. то команда 1р ищет файл ' .primers, файл /clc/prim-
ers.conf и. наконец, службу Federated Naming Service* как место назначения,
выбираемое по умолчанию.
Да-да, именно Federated Naming Service. Такова принятая в Solans схема управления
службами имен /etc/hosts, DNS, NIS, NIS+ и LDAP. Не пугайтесь этого акронима;
отдельные службы работают как обычно.
758
Чость 111 Разное
LJ
Комонды Ipsched и Ipshut: запуск и останов печати
Назначение демона Ipsched — по мере освобождения соответствующего
устройства посылать на печать файлы, помешенные в буферный каталог
командой 1р. Демон Ipsched заносит в файл (обычно /usr/spool/ip/log) всю
информацию обо всех обрабатываемых файлах и ошибках.
Прн запуске демон Ipsched записывает содержимое файла /usr/spool/tp/lpg
в файл /usr/spool/lp/oldlog и начинает запись в новый журнальный файл.
Журнальный файл выглядит примерно так:
***** LP LOG:	Jul 6 12;	:05			
prl-107	garth	prl	Jul	6	12:10
pr-112	scott	Prl	Jul	6	12:22
pr-117	evi	pr2	Jul	6	12:22
prl-ИВ	garth	Prl	Jul	6	12:25
prl-119	garth	prl	Jul	6	13:38
pr-132	evi	prl	Jul	6	13:42
В первой колонке указывается идентификатор задания. Во второй — имя
пользователя, пославшего задание на печать. В третьей колонке задается
принтер, на который было послано задание. и, наконец, в последней
колонке — время постановки задания в очередь.
В системе, взятой для этого примера, имеются два принтера — рг! и рг2.
которые относятся к классу рг. Пользователь garth во всех случаях указывал
конкретный принтер prl. поэтому его задания посылались именно туда.
Пользователи scott и evi, наоборот, указывали класс рг, поэтому их задания
посылались на первый свободный принтер этого класса.
Если нужно по какой-либо причине прервать выполнение демона Ipsched
(например, для запуска команды Ipadmin). введите /usr/lib/lpshut Когда демон
Ipsched не работает, никакие задания не печатаются, хотя можно продолжать
постановку заданий в очередь с помощью команды 1р. Задание, которое в
момент останова демона печаталось, будет после его перезапуска напечатано
с начала. Чтобы перезапустить демон Ipsched. достаточно просто ввести
/usr/lib/lpsched.
Файл /usr/spool/ip/SCHEDLOCK — это файл, который предназначен для
контроля за тем, чтобы работал только один экземпляр демона Ipsched. Если
выполнение демона Ipsched прервано не с помощью команды Ipshut, а другими
средствами, то перед перезапуском демона файл SCHEDLOCK обязательно
нужно удалить вручную.
Команда Ipadmin: конфигурирование среды печати
Команда Ipadmin используется для информирован ня системы печати о
локальной конфигурации принтеров. Ее применяют для присваивания имен
принтерам, для создания классов и для задания принтера, используемого по
умолчанию. На самом деле эта команда только создает текстовые файлы в
каталоге /usr/spool/lp.
Но рядом с этими файлами неплохо бы поместить знакомую всем нам
табличку: 'Туками ие трогать!’’. Другими словами, упомянутые файлы не
нужно пытаться редактировать непосредственно: они имеют жестко заданный
формат и поэтому их очень легко повредить.
Разработчики Solaris поставили перед собой цель обеспечить возможность
параллельной работы демона Ipsched и большинства команд администратора
но, на наш взгляд, эта сумасшедшая идея невыполнима.
Глово 23. Печотн
7й9

Большинство команд Ipadmin не могут работать одновременно с демоном
Ipsched, поэтому прежде чем запускать команду Ipadmin, нужно активизировать
команду Ipshut, чтобы прекратить работу демона Ipsched.
Система сможет начать вывод заданий на принтер только после того,
как ей будет сообщено о том. что этот принтер доступен. Чтобы сделать
доступным новый принтер, необходимо выполнить следующую команду:
# /пег/«bin/Ipadmin -рпринтер -^устройство { -•принтер | -амодель
1 -Интерфейс | [ -скласс ... ] [{ -1 I -Ь }]
где принтер — имя принтера (как внутреннее в системе организации очередей,
так и на уровне пользовательских команд), а устройство — файл устройства
для принтера. Имя принтера может включать буквы, цифры и знаки
подчеркивания. Длина его ограничена 14-ю знаками. В качестве аргумента
устройство может задаваться любой файл. Обычно это специальный файл в
каталоге /dev,
С помощью флагов -е, -т и -i задается интерфейсная программа принтера,
которую должна использовать система печати. Интерфейсная программа
отвечает за форматирование заданий, которые поступают непосредственно на
принтер. Интерфейсные программы System V аналогичны фильтрам системы
BSD. Более подробную информацию можно найти в одном из следующих
параграфов.
Интерфейсную программу можно задать одним из трех способов:
-епринтер В этом случае принтер — имя существующего принтера. Этот метод
задания интерфейсной программы полезен в том случае, если
добавляется принтер, идентичный одному из уже имеющихся.
Команда Ipadmin создает копию интерфейсной программы с новым
именем пункта назначения.
-тмодель Здесь модель — это тип устройства, для которого в системе имеется
интерфейсная программа. Информация о том, какие модели
поддерживает система, содержится в документации и в каталоге
/usr/spool/lp/model. Если файл модели задан, команда Ipadmin
создает копию файла /usr/spool/lp/model/jwodewb в каталоге
/usr/spool/Ip/interface/пункт_назначения.
Линтер- В этой опции интерфейс является полным путевым именем про-
фейс граммы, которая будет служить интерфейсным сценарием. Боль-
шинство версий команды Ipadmin делает копию интерфейсной
программы, поэтому если вы захотите изменить ее после прогона
команды Ipadmin, нужно будет менять копию в каталоге
/usr/spool/lp/interface, а ие свой оригинал.
В HP-UX реализована возможность определять программы, которые
возвращают информацию о состоянии очереди и отменяют задания печати.
Их можно задавать как интерфейсные сценарии, но при этом используются
другие префиксы опций (-ост и -osm задают соответственно сценарий отмены
и сценарий выдачи статуса).
Помимо этих обязательных флагов, при вызове команды Ipadmin можно
задавать следующие опции;
-^принтерсообщает программе Ipadmin, к какому принтеру или принтерам
следует обращаться. Комбинируйте этот флаг с другими опциями,
чтобы изменить принтер.
-скласс где класс — имя класса, к которому принадлежит принтер. Для
одного принтера можно задать сколько угодно классов. Если указан
’<5 )
Чость III. Розное
несуществующий класс, он будет создан. Имя класса может
включать не более чем 14 символов.
-хпринтер Удаляет указанный принтер из системы печати Если принтер
является представителем целого класса принтеров, удаляются все
принтеры этого класса. Ни принтер, ни класс не могут быть
удалены, если уже выполняют задание из очереди на печать. Если
поставленные в очередь задания мешают удалить принтер, исполь-
зуйте команду reject, чтобы предотвратить загрузку в буфера новых
заданий. Затем примените команды Ipmove и cancel для удаления
существующих заданий. Если команда Ipadmin -х по-прежнему не
хочет удалять принтер, последуйте совету, приведенному в пара-
графе “Интерфейсные программы” этой главы.
-гкласс Удаляет принтер из запанного класса, но не из системы печати.
Если указанный принтер является единственным представителем
класса, этот класс удаляется.
Команда 1р не будет принимать заявки на новый принтер, пока ей не
поступит указание это делать (от команды accept, см. ниже соответствующий
раздел).
Если флаг применим к нескольким объектам, то вместо одиночного
объекта можно задавать список объектов (в кавычках, через запятую).
Напрнмер, команда
< /ииг/sbin/Ipadmin -р"howler-lw,ralphie-lw” -ceng-printers
введет принтеры howler-lw и ralphie-lw в класс eng принтеров. Другие команды
печати также могут относиться сразу ко многим принтерам, если это
необходимо. Флаги, которые используются при вызове программы Ipadmin.
перечислены в табл. 23.4.
Тоблицо 23.4. Фгоги комонды Ipadmin
Флог	Функция	.		 		
-рпринтер -Лназн	Задастся принтер, к которому относятся все последующие опции Пункт назначения назн определяется как используемый по умолчанию
-кназн	Пункт назначения назн удаляется из системы печати
-Скласс	Принтер принтер добавляется к классу класс
-гкласс	Принтер принтер удаляется из класса класс
-еназн	Интерфейсная программа для принтера принтер копируется из пункта назначения назн
-[интерфейс	В качестве интерфейсной программы для принтера принтер задается интерфейс
-тмоделъ	Интерфейсная программа для модели модель назначается в качестве интерфейсной программы для принтера принтер
-Ь -1	Определяется, что принтер подключен аппаратно Определяется, что принтер — регистрационный терминал1
-тфайл	Определяется, что выходные данные, посылаемые на принтер принтер, должны также направляться в файл
-D “описание "	Задает строку описания принтера
По умолчанию печать на принтерах, указанных в команде Ipadmin — I, невозможна.
Глово 23. Печоть
761
Ниже приведены несколько примеров команд семейства Ipadmin с
краткими пояснениями
F /usr/lib/Ipadmin -phowler-lw -v/dev/tty06 -mPostScript -cpr
Эта команда сообщает системе печати о том, что принтеру с именем
howler-lw назначен файл устройства /dev/tty06 и что он должен относиться к
классу рг. а также о том, что следует использовать интерфейсную программу
для принтеров PostScript. Следует отметить, что Ipadmin сама создает буферный
каталог с необходимыми правами доступа.
Команда
#	/usr/sbin/lpadmin -dpr
задает используемый по умолчанию системный пункт для класса (или
принтера) рг.
Команда
#	/usr/sbin/lpadmin -phowler-lw -D"LaserJet named howler"
описывает принтер howler-lw.
Команда
If /usr/sbin/Ipadmin -howler-lw -rpr -cfast
удаляет принтер howler-lw из класса рг и добавляет его в класс fast.
А в результате ввода команды
i /usr/sbin/lpadmin -xhowler-lw
из системы печати полностью удаляется принтер howler-lw. Если этот принтер
был единственным членом какого-либо класса, весь класс также удаляется.
Несколько других примеров команды Ipadmin приведены в параграфах,
касающихся систем Solaris н HP-UX (см. ниже).
Команда Ipstat: получение информации
о состоянии системы печати
Команда Ipstat выдает информацию о состоянии системы печати. При
вызове без аргументов эта команда сообщает статус всех заданий, которые
посланы на печать задавшим ее пользователем. При указании аргумента -р
она выдает информацию о состоянии конкретного принтера. Например,
команда
% Ipstat -phowler—lw
howler-lw is now printing pr-125. enabled since Jul 4 12:25
расскажет о состоянии принтера phowler-lw. Статус демона Ipsched можно
определить командой Ipstat -г.
% Ipstat -г
scheduler is running
В данном случае она сообщает, что все нормально. Флаги команды Ipstat
перечислены в табл. 23.5.
Соглашение о добавлении в конец имени принтера символов “-Iw” имеет исторические
корни и возникло при использовании принтеров Apple LaserWriter. Вы можете разработать
собственную систему задания имен принтеров.
762
Чость III Розное
Тоблицо 23.5. Флоги команды Ipstot
Флаг -г	функция Предоставляет информацию о состоянии демона Ipsched
-d	Предоставляет информацию об используемом по умолчанию пункте назначения
-скласс	Предоставляет перечень членов класса
-оарг	Предоставляет информацию о состоянии запросов вывода для арг'
-^пользователь	Предоставляет информацию о состоянии заданий, посланных на печать пользователем пользователь
-рпринтер	Предоставляет информацию о состоянии принтера принтер
-'/принтер	Предоставляет информацию об устройстве вывода, которое назна- чено в качестве принтера принтер
-^список	Предоставляет информацию о состоянии очередей, имена указаны параметром список
-1	Предоставляет полную информацию о состоянии системы печати
Параметр арг может быть принтером, классом или идентификатором задания
Команда cancel: удаление заданий печати
Команда cancel обеспечивает отмену выполнения задании, которые стоят
в очереди или печатаются в данным момент. В этой команде можно указывать
либо идентификатор задания (он задается с помощью команды Ips tat), либо
имя принтера (в этом случае отменяется задание, которое выводится на печать
в данный момент).
Например, команда cancel 576 отменяет задание 576 a cancel howler-lw —
задание, которое в текущий момент печатается на принтере howler-lw. Для
команды cancel обычно установлены такие права доступа: владелец —
псевдо пользователь 1р. группа — bin, а код прав доступа — 6775, поэтому
любой пользователь может воспользоваться этой командой для отмены
заданий, которые явно того заслуживают. Если задание отменяет тот, кто его
не посылал, владельцу задания посылается сообщение по электронной почте.
Не исключено, что пользователи начнут злоупотреблять этой возможностью,
тогда код прав доступа можно изменить.
Команды accept и reject: управление организацией очереди
Если предполагается отключить принтер на длительное время (например,
из-за аппаратной неисправности), необходимо блокировать посылку заданий
в очередь к нему, чтобы задания пользователей, не знающих о выходе
принтера из строя, не переполнили очередь. Это делается командой reject.
Так. после ввода команды
t /usr/lib/reject -r"howler-lw will be down until TueHday" howler-lw
команда Ip будет отклонять запросы на печать на принтере howler-lw.
Флаг -г является необязательным, однако это хорошее средство проин-
формировать пользователей о причине, по которой принтер отклоняет
запросы При попытке вывести файл на печать, пользователь получит
сообщение.
% /usr/bin/lp —dhowler-lw myfxle
Ip: cannot accept requests lor destination "nowler-lw"
— howler-lw will be down until Tuesday
Гпово 23. Печоть
763
ш
Команда accept принтер дает программе 1р указание начать прием запросов
на печать на указанном принтере. Команду accept необходимо выполнять
один раз для каждого нового принтера, добавляемого командой Ipadmin,
потому что новые принтеры по умолчанию конфигурированы так, что запросы
на постановку в очередь отклоняются. Чтобы обеспечить возможность
управления очередями в рамках класса, в командах accept и reject вместо
имени пункта назначения следует указывать имя класса.
Команды enable и disable: управление печатью
Командой disable демоиу Ipsched дается указание прекратить посылку
заданий на конкретный принтер. В отличие от команды reject, команда disable
не препятствует программе 1р продолжать ставить задания в очередь на этот
принтер, однако стоящие в очереди задания начнут выводиться на печать
только после того, как принтер будет повторно включен командой enable.
Команда disable обычно не прерывает печать текущего задания; если требуется
это сделать, воспользуйтесь опцией -с. Как и команда reject, команда disable
поддерживает флаг -г, который позволяет вам указать причину отключения
принтера. Например, для выключения печати на принтере howler-lw дается
команда
#	/Ып/сНваЫ» -r,,Belng cleaned, back In 5 minutes" howler-lw
Для возобновления печати введите
#	/Ып/anabla howler-lw
Команде Ipmove: перемещение заданий
Иногда возникает необходимость переместить задания, стоящие в очереди
к одному принтеру или классу, на другой принтер. Для этого служит команда
Ipmove. В качестве аргументов этой команды задается перечень идентифика-
торов заданий и имя нового принтера. Например, команда
t /ияг/sbin/Ipmove howler-lw-324 howler-lw-325 anchor-lj
перемешает задания с номерами 324 и 325 из очереди к принтеру howler-lw
в очередь к принтеру anchor-lj. В качестве источника можно задать принтер
или класс принтеров. В частности, команда
#	/ивг/sbin/Ipmove howler-lw anchor-lj
переместит все задания из очереди к принтеру howler-lw в очередь к принтеру
anchor-lj. При таком использовании команды Ipmove возникает побочный
эффект: для исходного принтера выполняется команда reject, Так, после
выполнения приведенной выше команды программа 1р перестанет принимать
запросы для принтера howler-lw.
Вследствие особенностей HP-UX команду Ipmove нельзя использовать,
если выполняется демон Ipsched. Вначале следует запустить программу Ipshut.
Интерфейсные программы
Интерфейсная программа получает файлы от демона Ipsched, форматирует
полученные данные и посылает их на свое стандартное устройство вывода.
Кроме того, интерфейсная программа отвечает за правильную установку
режимов на устройстве вывода и за формирование заголовков и завершителей.
764
Чость 111. Розное
если они необходимы. Интерфейсные программы, как правило, представляют
собой сценарии shell, но могут быть и исполняемыми двоичными файлами.
Демон Ipsched вызывает интерфейсные программы со следующими
аргументами;
ид_задания пользователь заголовок зкз опции файл [файл ...]
где:
•	идзадания — идентификатор задания, который назначается программой 1р;
•	пользователь — пользователь, являющийся владельцем задания;
•	заголовок — необязательный заголовок (задается пользователем);
•	зкз — количество печатных экземпляров документа;
•	опции — указываемые пользователем опции;
•	файлы — полные путевые имена файлов, подлежащих выводу на печать.
Все перечисленные аргументы должны указываться при каждом выпол-
нении интерфейсной программы; некоторые из них могут быть пустыми
строками. В качестве стандартного входного потока для интерфейсной
программы определен файл /dev/null, а стандартный поток вьгаода и
стандартный поток данных об ошибках направляются на устройство, заданное
командой Ipadmin -v.
В соответствии с концепцией системы печати BSD каждому формату
файлов должна соответствовать собственная интерфейсная программа. Раз-
работчики System V пошли по другому пути: интерфейсные программы
предназначены для обработки данных всех типов, которые поддерживает
принтер (если получены данные неизвестного типа, такая программа с
“чарующей улыбкой” прекращает работу). По этой причине интерфейсные
программы обычно представляют собой сценарии интерпретатора команд,
которые просто обрабатывают данные, заданные им в качестве аргументов,
а для выполнения реальной работы по форматированию вызывают другие
программы.
По сути дела, интерфейсный сценарий отвечает в системе печати за весь
этап вывода данных. Это облегчает настройку, но вместе с тем приводит к
тому, что результаты вывода на печать на разных принтерах могут сильно
различаться между собой.
Без интерфейсов практически нельзя обойтись, если требуется печатать
что-либо помимо текста, подготовленного специально для печати на Post-
Script-принтере. В настоящее время почти все принтеры используют интер-
фейсы. Струйные принтеры обязательно используют интерфейсы для
преобразования задания на печать в свой собственный формат.
Если интерфейсная программа закончила свою работу успешно, то ее
код завершения равен 0; при ошибке он представляет собой целое число
от 1 до 127. В случае если задание не выведено на печать, интерфейсный
сценарий должен предпринять повторную попытку. Если же ошибка оказалась
серьезной, интерфейсная программа должна отключить принтер командой
disable. А если проблемы с печатью возникают постоянно, причину, скорее
всего, следует искать именно в интерфейсном сценарии.
Что делать, если программу 1р заклинило?
Иногда попытки конфигурировать принтер приводят к тому, что про-
грамма 1р безнадежно запутывается. Информация о конфигурации системы
хранится в разных файлах каталога /usr/spool/lp. Содержимое и структура
Глово 23. Печоть
/65
файлов конфигурации зависят от варианта реализации и во многих случаях
в них трудно разобраться, а сопроводительная документация для этих файлов
обычно отсутствует.
Если получилось так, что своей попыткой внести принтер вы запутали
систему, то лучшее решение — полностью удалить из системы печати
выходное устройство и начать все сначала. Иногда система запутывается
настолько, что не удается даже удалить устройство.
В такой ситуации остается только применить грубую силу. В приведенном
ниже примере мы пытаемся удалить принтер dest (если имя dest не уникально,
этого делать нельзя).
f Ipshut
# Ipadmin -xhoeir
I? find /usr/spool/lp -name hoser -exec rm -rf (| \;
I Ipsched
If Ips tat -t
Первые две команды введены с целью отключить планировщик и
попытаться удалить принтер. Если система запуталась, команда Ipadmin -х
может дать отрицательный результат. Команда find удаляет все интерфейсные
программы и буферные каталоги, соответствующие данному принтеру. Демон
Ipsched перезапускает планировщик, а команда Ipstat используется для
проверки того, все ли ссылки на принтер dest в системе печати уничтожены.
23.5. Добавление принтера
В этом параграфе описаны детали конфигураций, специфичные для
различных поставщиков принтеров. Для каждой операционной системы мы
рассмотрим:
•	процедуру установки локального принтера, подключаемого к последева
тельному нли параллельному порту;
•	печать в сети посредством демона печати Ipd;
•	получение из сети заданий на печать для демона Ipd
Следует отметить, что мы будем рассматривать печать в сети только с
точки зрения системы BSD. Это обусловлено тем, что не существует такой
веши, как “удаленная печать в системе System V”; системы, базирующиеся
на последней и пытающиеся при этом осуществлять удаленную печать,
адаптируют для этого фрагменты протокола BSD.
Далее мы предполагаем, что принтер физически уже подключен к
компьютеру или включен в сеть. Чтобы вспомнить, как это делается,
обратитесь к главе 7 за информацией относительно подключения соответст-
вующих принтеров, а также к главе 15, где содержится общая информация
о включении устройств в сеть.
Сетевые принтеры требуют определенного "внешнего" конфигурирова-
ния В частности, нм должны быть назначены IP-адреса. Обычно это делается
одним из следующих методов.
Во-первых, многие современные принтеры могут загружаться по сети с
ВООТР- или DHCP-сервера. Этот метод хорош, когда в сети имеется много
однотипных принтеров.
0 Подробнее о протоколе DHCP рассказывалось в параграфе 13.7.
Альтернативный метод — присвоение принтерам ]Р-адресов с консоли
Иногда “консолью” является последовательный порт, но чаше это просто
766
Чость III. Розное
несколько кнопок на передней панели принтера, которые нужно нажать в
определенной последовательности После того как принтер включен в сеть
и отзывается на команд}' ping, позаботьтесь о соответствующей защите для
него; как это осуществить, рассказано в конце данной главы.
Чтобы сделать материал следующих разделов более понятным, мы будем
говорить о конкретном наборе оборудования. Сервер beast является ‘’родным"
Ipd-спулером, подключенным к лазерному принтеру howler-lw.
Soloris
Начиная с версии Solaris 2.6. фирма Sun использует еше и другую систему
печати. Наилучшим методом управления печатью при работе в данной системе
является применение утилиты Solstice Printer Manager, входящей в состав
пакета Solstice AdminSuite Если данный продукт в вашей системе отсутствует,
имеется еше один неплохой вариант — утилита Admintool (ее можно найти
в каталоге /usr/bin/admiiiiool). Для тех. кто хотел оы лучше разобраться в
системе печати, мы опишем ниже весьма интригующие детали.
В системе Solaris используется несколько нестандартных команд печати.
Команда Ipfilter просматривает и добавляет в систему новые интерфейсные
программы’.
Команды Ipset и Ipget облегчают редактирование и обзор данных о
конфигурации принтера. Команда Ipset выполняет в основном те же функции,
что и команда Ipadmin. но ее уникальная особенность — способность работать
с обеими конфигурациями файлов, используемыми как в системе, так и в
конкретном принтере.
Команда Ipusers управляет слегка улучшенной системой приоритетов и
системой контроля доступа, а команда Ipfomis обеспечивает представление
стандартизированных страниц посредством механизма групп пользователей.
Ни одна из этих команд на практике не используется, поэтому рассматривать
мы их не будем.
Система Solaris предоставляет команды печати системы BSD как состав-
ную часть пакета “SunOS/BSD Compatibility Package”, который по умолчанию
включается в дистрибутив системы Solaris. Следовательно, если понадобится,
можно использовать демон Ipd для нужд печати во всех случаях.
В системе Solaris информация о конфигурации принтера находится в
файле, который аналогичен файлу printcap и называется /etc/printers.conf.
Дополнительная информация находится в каталоге /ctc/lp. а специфическая
информация о принтере — в файле /etc/lp/plinters/prin tername. Пользователи
могут приспосабливать систему печати под свои нужды с помошыо опцио-
нального файла '/.printers, который позволяет им делать для пршггера
установки по умолчанию и создавать псевдонимы для команд печати.
Сообщения об ошибках из спулера Ipsched регистрируются по умолчанию в
файле /var/lp/logs/lpsched.
В отличие от команд в традиционной системе печати System V, команды
печати системы Solaris используют пробел между флагами опций и их
значениями (т е. пишется, например. Ipstat -р anciior-lj. а не Ipstat -paneiior-Jj).
Однако они принимают также н старый формат команд. Возможно, лучше
все-таки придерживаться документированного (с пробелами) синтаксиса.
Пользователи системы печати, основанной на принципах системы System V (например
Solaris), применяют термин фильтр вместо термина интерфейс
Гпово 23 Печоть
767
При работе в системе Solans необходимо указывать, какого типа задания
может принимать устройство. Располагая такой информацией, система печати
определяет, может ли принтер принять данное задание на печать. Интер-
фейсная программа отвергает задания, не относящиеся к одному и*
специфицированных типов, так что если вы забыли указать какой-то тип,
принтер будет простаивать. Чтобы указать нужное значение, используйте
команду Ipadmin -I. Опция -I PostScript.simple полезна в случае использования
PostScript-принтеров. Для построчи о-печатаю тих принтеров, "понимающих"
только текст, следует выбрать опцию -I simple.
Требуется также указать тип принтера, используя в команде Ipadmin
флаг -Т. Системе печати необходимо "знать” тип принтера, чтобы определить,
как его инициализировать и как с ним связываться. Кроме того, некоторым
фильтрам необходима эта информация, чтобы правильно установить свои
параметры Типом принтера может быть некоторое значение, которое
содержится в базе данных terminfo, находящейся в каталоге /usr/sliare/lib
Ищите в нем запись, соответствующую принтеру. В случае использования
PostScript-принтера можно применять тип PS:
#	Ipadmin -р howler-lw -Т PS
Система Solaris хранит новые интерфейсные программы в каталоге
/etc/lp/interfaces, хотя никакие фильтры не предоставляются ею в этом
каталоге сразу после инсталляции. Чтобы получить список всех интерфейсных
программ, воспользуйтесь командой Ipfilter:
♦	Ipfilter -f all -1
Задание локального последовательного принтера
Прежде всего подключите последовательный принтер и определите
устройство, с которым он ассоциируется. Обычно последовательные устрой-
ства Solaris называются /dev/term/а и /dev/term/Ь. Владельцем этих устройств
должен быть пользователь 1р, и права доступа следует установить так. чтобы
только пользователь 1р имел право чтения или записи для данного устройства:
*	chown Ip /dev/term/а
# chmod 600 /dav/taxm/a
Затем конфигурируйте принтер, зарегистрировавшись как пользователь
Ipadmin. Нужно указать имя принтера, имя устройства, тип принтера
(PostScript или обычный) и типы данных, которые обязан принимать принтер
Команда Ipadmin должна выглядеть примерно так:
#	Ipadmin -р имя_принтера -v /dev/harm/а -Т тмп_принтера
-I тип_содержимого -D ’’описание”
Прикажите спулеру приступить к приему заданий на печать и распоря-
дитесь, чтобы принтер начал их печатать:
#	enable имяпринтера
# accept имя_принтера
И наконец, с помощью команды Ipstat убедитесь в том, что установка
принтера прошла успешно:
#	Ipstat -р имя_принтера
768
Чость III PojHoe
Печать из Solaris на BSD-сервер печати
Для того чтобы разрешить спулинг из системы Solans на удаленный
lpd-сервер Гили запуск на другом компьютере тибо сетевом принтере),
используйте в команде Ipadmin специфичный для системы Solaris флаг -s
Этот флаг позволяет определять удаленный принтер как сервер!принтер
Применяемый вами язык программирования shell, возможно, требует, чтобы
вы избегали использования восклицательного знака после обратной косой
черты, поэтому в действительности команда может выглядеть так’
9 Ipadmin -р howler-lw -• baaat\fhowler-lw -I PostScript,aimpla
-T PS -D “howler-lw via beset"
Если принтер имеет одно и то же имя на сервере и на локальном
компьютере, можно пропустить часть .'принтер команды (в данном случае это
•‘Vhowler-lw”).
После того как удаленный принтер опознан, активизируйте его, как
обычно:
*	enable howler-lw
# accept howler-lw
И наконец, протестируйте новый принтер:
#	Ip -phowler-lw /etc/motd
# Ipefat -phowler-lw
Если сетевой принтер не понимает команду Ipd. он, вероятно, ожидает,
что вы подберетесь к нему напрямую, через TCP-соединение Система Solaris
поддерживает такую конфигурацию посредством интерфейсной программы
neLstandard; эта программа распределяет задания на печать по всей сети, так
что имя локального устройства, определенного с помошыо флага -v. может
быть указано в файле /dev/nuIL
Команда Ipadmin -о позволяет передать опции в команду netstandard
Например, следующая команда создает новый PostScript-принтер с именем
dinger-Iw для сетевого принтера, который принимает PostScript-файлы через
TCP-порт 9100:
#	Ipedmin -р dinger-lw -v /dev/null -I PostScript -T PS -re netetan-
dard —о protoccl=tcp -o deet*dinger-lw;9100 -o timeout-15
Программа netstandard поддерживает также отправку заданий на Ipd-сервер
системы BSD; это достигается записью Ipadmin -о protocol=bsd. Того же
результата можно добиться посредством команды Ipadmin -s.
Прием заданий на печать от BSD-систем
Система Solaris включает в свой состав демон in.Ipd. который по
умолчанию запускается из демона inetd Этот демон понимает протокол
демона Ipd и может запросто получать буферизованные задания от 1рг-клн-
ентов на локальный или сетевой принтеры. Демон in.Ipd берет параметры
конфигурации из файла /etc/printers.conr. так что ни в каком другом
конфигурировании, помимо выполняемого командой Ipadmin, нет необходи-
мости. Если вы не собираетесь предоставлять услуги печати Ipd-клиентам,
превратите в комментарий строк) вызова демона in.Ipd н файле /etc/ineld.conf.
Глово 23. Печать
76У
HP-UX
Помимо выполне11ия в полном объеме команд обычной системы
System V, система HP-UX предоставляет несколько уникальных клиентских
команд и богатый особенностями сервер. Система HP-UX не любит, когда
администратор вносит какие-то изменения во время работы демона Ipsched.
Команда Ipana анализирует характеристики буфера печати. Этот инстру-
мент дает достаточно информации для того, чтобы можно было оптимизи-
ровать систему буферирования принтера; она включает такие статистические
данные, как среднее время ожидания заданий в очереди и среднее время
печати одного задания. Для записи учетных данных, выдаваемых командой
(рала, запустите демон Ipsched с флагом -а.
Команда Ipfence определяет минимальный приоритет, который должны
иметь задания, поступающие в очередь на печать. Этот приоритет устанав-
ливается для принтера, в отличие от приоритета задания.
Задания, которые помешены в буфер, но еще не начали выполняться,
могут быть изменены с помошыо команды Ipalt. Эта команда позволяет
изменить большинство опций программы 1р. благодаря чему пользователь
избавлен от необходимости отменять, а потом i аново помещать в буфер
задания, которые нуждаются в корректировке.
Как и в системе Solans, версия команды Ipadrnin системы HP-UX
поддерживает флаг -о, позволяющий передать значения параметров в
интерфейсную программу. Этот флаг очень полезен, потому что избавляет
системного администратора от необходимости редактировать сценарии или
перекомпилировать интерфейсные программы лишь для того чтобы изменить
их опции. Соответствующий пример был приведен выше.
Задание локального последовательного принтере
Предположим, мы хотим подключить принтер HP LaserJet 4М к
последовательному' порту, указанному в файле /dev/ttyp2 Прежде чем
выполнять команду' Ipadmin. нужно остановить все сервисы печати:
т /usr/sbin/Ipshut
Какая-то интерфейсная модель всегда существует для печати на принтерах
в каталоге /usr/lib/lp/model, полому для конфигурирования принтера мы
будем использовать команду Ipadmin -ш:
*	/usr/sbin/ipadmin -phowler-lw -mlaser^et4 -v/dev/ttyp2
Потом мы начнем прием заданий на печать в буфер, сделаем притер
доступным и перезапустим демон буферирования:
#	/usr/lib/accept howler-lw
I /bin/enable howler-lw
#	/usr/sbin/ipsched
Печать из HP-UX на BSD-сервер печати
Система HP-UX предоставляет в ваше распоряжение интерфейсный
сценарий, называемый rmodel, который может посылать задания иа удаленный
сервер Ipd. Опции сценария rmodel устанавливаются посредством команды
Ipadmin -о. Например, следующие команды делают принтер howler-lw на
компьютере beast доступным для локальных пользователей:
#	/usr/sbin/lpshut
й /usr/sbin/Ipadmin -phowler-lw -v/dev/null -mrmodel -ormbeast
-orphowler-lw -ob3
II /usr/lib/accept howler-lw
770
Чость 111. Розное
# /bin/enable howler-lw
# /uar/sbln/lpached
Интерфейс rmodel использует аргументы omi. огр и ob для описания
удаленного компьютера, удаленного принтера и применяемого BSD-стиля.
На самом деле для отправки задания на удаленный Ipd-сервер интерфейс
rmodel вызывает команду rip. К сожалению, команды rip, rcancel и ripstat
предназначены исключительно иля использования другими частями системы,
их никогда не должны вызывать непосредственно пользователи. Если эти
ограничения оказались существенными для вас, рассмотрите возможность
использования пакета rlpr, описанного в параграфе 23.8.
Прием заданий на печать от BSD
Спулер удаленной печати системы HP-UX, rlpdaemon. принимает задания
от системы Ipr/lpd. Демон rlpdaemon обычно запускается демоном inetd. но
компьютер, который получает много заданий на печать, должен начинать
свою работу во время загрузки; демон rlpdaemon принимает задания от любого
из компьютеров, перечисленных в файле /etc/hosts.equiv или /usr/spool/ip/.rhosts.
Red Hat
Система печати, используемая в Red Hat. является прекрасным вопло-
щением BSD-стандарта. Некоторые из инструментов, применяемых в Red
Hat, являются весьма полезными, особенно графическая утилита printtool,
которая автоматизирует редактирование файла /etc/printcap. и сценарий
ipunlock, благодаря которому можно спасти заблокированные серверы печати.
Замечательная утилита prinitool поможет отконфигурировать множество прин-
теров. включая локальные, удаленные серверы Ipd, SMB (Windows) и принтеры
NetWare (NCP). Следует предостеречь вас от следующего: утилита printtool
требует, чтобы файл /etc/printcap был сформирован очень тщательно, если
отредактировать этот файл вручную, может случиться так, что его невозможно
будет открыть утилитой printtool.
Известно, что Red Hat поддерживает относительно небольшое количество
принтеров. Основной причиной этого является то, что Red Hat Linux
использует GNU-версию программы ghostscript, которая поддерживает на-
много меньше принтеров, чем популярная версия Aladdin Enterprises.
Свободно распространяемая, но псевдокоммерческая программа ghostscript,
входящая в состав Aladdin и используемая в различных дистрибутивах, может
растеризовать изображения для многих других принтеров, не относящихся к
категории PostScript. Если вы обнаружите, что принтер ие поддерживается
системой Red Hai по умолчанию, рассмотрите вариант инсталляции версии
Aladdin программы ghostscript с узла www.aladdin.com.
Зодоние локального последовательного принтера
В системе Red Hat используется пакет фильтров печати RHS, который
трудно конфигурировать без помоши программы printtool. Запись в случае,
когда фильтры не применяются, выглядит примерно так:
howler-lw|howlilaserjet:\
:sd=/var/spool/lpd/howler-lw:\
:mx#0:\
:lp=/dev/parportO:\
: sh:
Глово 23 Печоть
771
Эта запись определяет три имени для принтера, указывает каталог буфера
и порт устройства, отменяет максимальный размер задания и подавляет печать
их заголовков.
Из данного файла устройства видно, что он относится к параллельному
принтеру. Последовательные принтеры конфигурируются аналогично. Это
устройство, вероятно, могло бы быть устройством /dev/ttySO (или S1 для
второго последовательного порта), а не устройством /dev/parportO, и могло
бы использовать различные фильтры Кроме того, можно было бы указать
такие параметры для последовательного порта, как скорость передачи в бодах
Ищите данные о соответствующих установках в тап-странииах, посвященных
базе данных printcap.
Печать из Red Hat на сетевой сервер печати
Как и во всех системах печати BSD, для новых принтеров должна быть
сделана запись в файле /etc/printcap клиентского компьютера:
howler-lw|1р|8-6("LaserJet 5М, called howler-lw on beasc”:
:lp«/var/spool/lpd/howler-Lw/.null:\
:rm-beaet;rp-howler-lw:\
:sd^/var/spool/lpd/howler-lw:mx#O;
Затем следует создать каталог для буфера и файл .null на клиентском
компьютере.
#	mkdlr /var/врос1/Ipd/howler-lw
if touch /var/вроо1/Ipd/howler-lw/.null
#	chown -R daemon /var/spool/lpd/howler-lw
» chgrp -R daemon /var/apool/lpd/howler-lw
#	chmod 775 /var/spool/Ipd/howler-lw
Если lpd-сервер является действительно компьютером (а не просто
“умным” принтером), перед тем как конфигурировать сетевые клиенты,
следует убедиться, что печать заданий с этой машины возможна. Для проверки
функционирования печати со стороны клиента можно использовать после-
довательность команд, аналогичную следующей:
#	Ipc start howler-lw
#	Ipr -Phowler-lw /etc/motd
#	Ipq -Phowler-lw
Прием заданий на печать из сети
Прежде чем пытаться загрузить в буфер задания из сети, убедитесь в
том, что имеется возможность печатать задания с локального компьютера.
Затем добавьте в файл /etc/hosts.Ipd клиентов, от которых вы хотите получать
задания.
FreeBSD
По умолчанию в системе FreeBSD файл /etc/pnntcap поступает с
некоторыми заранее подготовленными примерами локальной и сетевой
конфигураций принтера, к которым можно обращаться при добавлении н
систему принтеров. Образцы файла printcap, приведенные в разделе, касаю-
щемся системы Red Hat, также работают и в системе печати FreeBSD (хотя
фильтры, о которых там говорилось, не поставляются вместе с FreeBSD).
772
Чость III. Розное
По умолчанию сервисы печати в системе FreeBSD недоступны. Чтобы
активизировать их. измените NO на YES в следующей строке, находящейся
в файле /etc/rc.conf:
lpa_enable«,,NO" # Run the line printer daemon.
Ни одна из команд печати, используемых в системе FreeBSD (за
исключением, пожалуй, команды Iptcontrol). ничем вас не удивит. Команда
Iptcontrol позволяет конфигурировать параллельный порт так, что становится
возможным использование любого из нескольких различных режимов, таких
как печать с прерыванием, печать по запросу, а также расширенного и
стандартного режимов. Для того чтобы заставить первый параллельный порт
(/dev/lptO) работать в режиме печати с прерыванием, используйте команду
Iptcontrol следующим образом:
Iptcontrol -1 -U О
Лишь посредством команды Iptcontrol можно изменить текущее состояние
параллельного порта. Если нужно, чтобы порт был конфигурирован опреде-
ленным образом каждый раз. когда загружается система, следует включить
команду Iptcontrol в один из сценариев ее загрузки.
Несколько полезных примеров печати и сценариев включены в справоч-
ник по системе FreeBSD. Его можно найти на узле www.freebsd.org.
Задание локального принтера
Первый параллельный порт на компьютере с системой FreeBSD — это
порт /dev/lptO Несмотря на разницу в именах устройств, конфигурация базы
данных printcap локального последовательного или параллельного порта почти
аналогична таковой в системе Red Hat (см. выше).
Дистрибутив FreeBSD включает в свой состав относительно простой
текстовый фильтр, /usr/libexec/lpr/lpf. который выполняет основное форма-
тирование. и частности формирует переходы на новую строку и отступы, а
также преобразование из текстового в Post Script-формат.
Конфигурирование сетевой печати
Система F reeBSD поддерживает удаленные принтеры во многом анало-
гично тому, как зто делает система Red Hal, хотя отвечающие за это фильтры
различны. Предоставление локальных принтеров для печати по сети выпол-
няется также аналогично.
23.6.	Спулер LPRng
I PRug — это новый спс.чер печати, основанный па BSD-системе. Система
LPRng. ге кушая поддержка которой осуществляется Патриком Пауэллом
(Panick Powell) из AStAn Technologies, представляет собой удачную попытку
совместить иаилучшие черты систем печати BSD и System V.
I PRug заменяет 1екущую систему печати совместимыми с нею. но
улучшенными командами. Все общие команды BSD остаются доступными
Наиболее важные команды System V также поддерживаются и выполняются
как ссылки на свои двойники системы BSD. Например, команда 1р является
ссылкой на команду 1рг, а команда cancel — ссылкой на 1рпп Эти команды
ожидают своего вызова и затем выполняются.
Одной из наиболее важных проблем во шикающих при использовании
системы печати BSD. является то. что почти все программное обеспечение
Глово 23 Печст*
773
печати должно запускаться пользователем root Это относится не только к
Ipr-клиентам, ио и к Ipd-фильтрам. Поскольку фильтры часто представляют
собой сценарии интерпретатора команд, такая перспектива пугает.
LPRng решает эту проблему, позволяя клиентам запускаться как обычным
пользователям. В случаях, когда LPRng не должен взаимодействовать с
клиентами, не относящимися к LPRng, даже демон печати может запускаться
непривилегированным пользователем. Этот пакет предостаапяет также много
новых возможностей по контролю безопасности, которые отсутствуют в
большинстве BSD-систем.
Одной из наиболее полезных особенностей LPRng считается ее способ-
ность выдавать подробные диагностические сообщения и уведомления об
ошибках. Вместо того чтобы молча не принимать задание или возвращать
непонятые сообщения, программы этого пакета дают подробные и полезные
объяснения тому, что делается неправильно*.
Хотя демон Ipd обеспечивает контроль доступа через файл /etc/hosls.lpd.
никакая аутентификация невозможна. LPRng поддерживает методы аутенти-
фикации Kerberos 5. SSL и PGP.
И наконец, LPRng предоставляет довольно большие возможности по
управлению очередью, большая часть которых унаследована от системы
System V. LPRng обеспечивает динамическое перенаправление очереди на
печать, поддержку многих принтеров для одной очереди и даже распределение
нагрузки между несколькими принтерами.
Учитывая все эти улучшения, почему бы не перейти к использованию
LPRng? В случае небольшого сетевого окружения, состоящего из малого числа
пользователей и еше меньшего количества принтеров обе системы печати, и
BSD. и System V, работают одинаково хорошо. Рели не планируется добавлять
много новых принтеров или если особенности и дополнительные средства
защиты вас не волнуют, установка и конфигурирование системы LPRng,
возможно, не оправдают затраченных усилий.
Как минимум, рассмотрите возможность установки LPRng на сервере
печати. Этот простой шаг значительно повысит безопасность и функциональ-
ность развертывания сети при весьма незначительных трудозатратах.
Команды LPRng
Версия команды Ipr спулера LPRng обратно совместима с большинством
других версий этой команды. Единственным исключением стал флаг -s,
который игнорируется командой 1рг спулера LPRng. Этот флаг предназнача-
ется для организации символической ссылки на печатаемый файл вместо
создания его копии. Обычно такой прием применяется при печати больших
файлов.
Версия команды Ipr спулера LPRng имеет богатые возможности. Чрезвы-
чайно полезными являются флаги вывода подробной информации -V и
отладочных данных —D (или -D5 для получения подробных отладочных
данных).
Команды LPRng позволяют кроме имени принтера указать машину и
порт, к которой он подключен. Эта функция дает возможность пользователям
осуществлять печать на удаленных принтерах, которые не указаны в
локальном файле printcap.
Возможно, комиссия по стандартизации UNIX нс работала в тот день, когда был представ-
лен LPRng...
774
Чость 111. Розное
Для указания компьютера, к которому подключен принтер, добавьте его
имя к имени принтера в виде @ил<я_компьютера. После этого может быть
задан порт как %порт Например:
% Ipr -Phcwler-lw@bea8t%6552 иияфаИпа
Такой способ задания принтера можно использовать для команд Ipr. Ipq,
Iprm и Ipc спулера LPRng. предполагая, что клиенты системы печати часто
вообще не нуждаются в файле printcap
Если принтер не указан в командной строке, используется значение
переменой среды PRINTER. Если же эта переменная не задана, применяется
первая запись файла /etc/printcap. Если и файла printcap не существует, то
используется принтер, заданный по умолчанию в файле Ipd.conf.
Команда ipq спулера LPRng имеет ряд новых функций. Добавлены
несколько форматов выводных данных при указаний флагов -sT -I и -L,
полезных в сценариях, работа которых зависит от вывода команды ipq. Также
имеется флаг, задающий периодическое выполнение запроса <-t секунд).
Кроме того, с этой командой можно использовать флаг отладки, описанный
выше. При указании флага -D5 в вывод команды включаются подробные
сообщения о состоянии, полученные от локальных и удаленных принтеров,
а также от спулеров печати.
Возможно, самой важной особенностью команды Ipc спулера LPRng
является ее способность распределять запросы по приоритетам. Правила
задания приоритетов могут быть достаточно сложными, для удовлетворения
требований любой политики. В отличие от традиционной команды Ipc, версия
этой команды спулера LPRng может быть запушена по сети.
Команда !рпп спулера LPRng позволяет ликвидировать звдания на печать,
основываясь на различных критериях. Традиционной команде необходимо
указывать идентификатор задания или имя пользователя, а рассматриваемая
команда позволяет удалять из буфера те задания, идентификаторы которых
являются результатом вычисления регулярного выражения.
Получение и инсталляция LPRng
Инсталляционный пакет LPRng можно получить с Web-узла www.as-
ian.com. Документация входит в комплект поставки и помогает выполнить
инсталляцию. Кроме этого, инструкции об инсталляции и конфигурировании
пакета имеются в вопросах FAQ на указанном Web-узле.
Одной из наиболее впечатляющих возможностей LPRng является способ-
ность оперировать с минимальным количеством двоичных файлов. Для того
чтобы скомпилировать LPRng таким образом, укажите опцию - disable-setuid
для сценария configure при первоначальном задании среды компиляции:
f ./configure —disable-setuid
Если необходимо, чтобы демон Ipd работал со своим стандартным
портом 515, его следует запускать от имени владельца root Привилегии
демона Ipd нужно изменить вручную:
i chmod 4755 /usx/local/sbin/lpd
Стандартный файл Makefile пакета LPRng версии 3.6.12 не работает с
утилитой make системы Solaris 2.7. Чтобы спулер L PRng был скомпилирован
корректно, необходимо включить в содержимое переменной path имя
Глово 23. Печоть
775
каталога, в котором находится утилита make GNU. ранее имени каталога со
стандартной утилитой make системы Solaris 1/usr/ccs/bin).
Файл /etc/lpd.conf: конфигурирование демона Ipd
Демон Ipd спулера LPRng конфигурируется посредством файла
/etc/lpd.conf. В этом файле можно задать значения 185 различных параметров
сервера. Большинство параметров связано с заданием стандартных каталогов
и операционной системы. Также определяется способ получения значений
по умолчанию для переменных, не указанных в файле /etc/printcap.
Лучшим способом создать собственный файл конфигурирования Ipd.conf
является копирование файла Ipd.conf из корневого каталога комплекта
поставки LPRng. Этот файл содержит описания всех параметров и примеры.
Если у вас нет времени на чтение этого длинного списка всех параметров,
обратитесь к man-странице руководства Ipd.conf.
Файл /etc/lpd.perms: настройка прав доступа
Посредством файла /etc/lpd.perms можно задать очень сложные политики
печати. Правила для управления доступом к системе печати применяются к
заданиям печати в том порядке, в котором они перечислены в файле Ipd.perms.
Правила состоят из дв\х частей Первая часть представляет собой
директиву ACCEPT или REJECT, определяющую разрешенные действия. Эти
директивы сопровождаются параметрами, посредством которых задаются
пользователи, компьютеры, принтеры или операции, для которых предназна-
чено правило.
Например, следующая строка указывает системе печати, что пользователь
evi с удаленного компьютера beast может создавать, помещать в буфер, удалять
и проверять состояние заданий печати для принтера howler-lw
ACCEPT SERVICED, R,M,Q REHOTEHOST—beast REMOTEUSER=ev_
PRINTER-howler-lw
Однобуквенные колы, укатанные в параметре SERVICE определяют
операции, для которых предназначено правило. В табл. 23.6 приведены все
возможные коды.
Тоблица 23.6. Коды порометро с'ЕЕЪТСЕ фойго /etc/lpd.perms
Код	Действие	Описание
р	Печать	Печать задания из очереди
С	Проверка принтера	Использование команды 1рс (позволяет секретар- шам разблокировать принтер)
R	Помешен ие в очередь	I[смещение заданий в буфер очереди печати посредством команды 1рг
М	Удаление	Удаление заданий из очереди печати посредством команды Iprm
Q	Проверка состояния	Получение информации о состоянии заданий с помощью команды Ipq
X	Подключение	Подключение к демону Ipd
Проше всего создать собственный файл Ipd.perms на основе фаи.ча-при
мера из комплекта поставки пакета 1 PRng. В этом примере строки с
77ё
Чость HI Розное
примерами директив ACCEPT и REJECT снабжены подробными коммента-
риями. Также в файле-примере описаны все возможные параметры конфи-
гурации.
Настройка базы данных printcap
Важно помнить о том, что файл printcap спулера LPRng обладает полной
обратной совместимостью с традиционным файлом printcap системы BSD
Следовательно, все традиционные файлы printcap действительны и для
системы LPRng.
Однако система LPRng также позволяет применять множество новых
функций файла printcap. Описания в этом файле могут переноситься на новые
строки с использованием отступов без добавления в конце переносимой
строки символа обратной косой черты. Длина имени переменной не
ограничивается двумя символами. Также имеется ряд сценариев, облегчающих
процесс конфигурирования. Конфигурационные записи файла могут быть
предназначены для различных компьютеров.
Видимо, наиболее впечатляющим средством конфигурирования LPRng
является программа checkpc. По умолчанию она помещается в каталог
/usr/local/bin и позволяет проверить правильность содержимого файла printcap.
Она выводит предупреждения об отсутствующих каталогах буферов, несуще-
ствующих файлах и некорректных правах доступа. Если запустить программу
checkpc с флагом -f, она попытается самостоятельно исправить найденные
ошибки (создать отсутствующие каталоги или изменить права доступа к
файлу). При указании флага -D5 программа checkpc выдаст более подробную
диагностическую информацию.
Фильтры
Кроме поддержки стандартных возможностей фильтров системы BSD,
система LPRng позволяет применять фильтры для заданий, отправляемых на
удаленные принтеры. Эта функция служит для форматирования данных
одного компьютера без ориентации на конкретный принтер.
Выходной (переменная of в файле printcap) и входной фильтры
(переменная if) работают в системе LPRng несколько по-другому. Выходной
фильтр в традиционной системе печати BSD применяется как к документу,
так и к баннеру. В системе LPRng выходной фильтр используется только для
баннера, а входной — только для печатаемого текста. Фильтры для файлов
других типов задаются посредством переменных xf, где вместо х указывается
буква, соответствующая типу файла. Использование всех фильтров можно
запретить вводом опции -Y в строку запуска команды Ipr.
В системе LPRng имеются специальные команды Ipbanner. pcibanner н
psbanner. Эти команды предназначены для создания текста, PCL- и PostScripr-
баннеров, соответственно. Каждая из них воспринимает параметры командной
строки, посредством которых задаются имя баннера, имя пользователя и
заголовок задания.
Система LPRng поставляется с одним очень полезным фильтром, ifhp.
который позволяет осуществлять печать на потрясающем количестве прин-
теров. Несмотря на то что этот фильтр изначально разрабатывался для
поддержки принтеров фирмы Hewlett-Packard, он позволяет работать и со
многими другими принтерами Не поддерживаемые явно принтеры обычно
удается заставить работать без особого труда.
Глово 23. Печоть
777
Учет
Во времена использования только построчно-печатающих принтеров учет
осуществлялся просто. Можно было получить точное число напечатанных
страниц для любого задания, подсчитав количество строк Однако такой
способ учета неприемлем при печати файлов PostScript
Единственный способ узнать точное число напечатанных страниц того
юти иного задания и а печать — это подсчитать количество листов, вышедших
из принтера. К счастью, большинство современных принтеров содержат
счетчик страниц, которые были напечатаны ими за весь срок службы.
Фиксируя значения этого счетчика до и после выполнения задания на печать,
драйвер принтера позволяет определять правильное число напечатанных
страниц.
Подобный способ подсчета напечатанных страниц реализован н в спулере
LPRng. Соответствующий сценарий находится в файле ./UTILS/accounting-pl
Прочитайте комментарии в начале этого файла, чтобы понять, как корректно
вызывать сценарий из файла printcap
23.7.	Устранение проблем при печати
Демон Ipd для передачи заданий на печать по сети использует порт 515
TCP. Если получение посторонних заданий на печать не желательно, следует
заблокировать передачу данных через этот порт из Internet на брандмауэре.
Для проверки возможности установления соединения с удаленным сервером
Ipd воспользуйтесь программой telnet и обратитесь с компьютера-клиента к
порту 515 сервера Если соединение будет установлено, значит, сеть работает
и демон Ipd запушен на сервере.
В случае возникновения проблем при настройке соединения с удаленным
принтером придется заглянуть в шесть (да-да, в шесть) мест, чтобы выяснить
причину неполадки. Это:
•	системный журнальный файл на печатающем (т.е. управляющем прин-
тером) компьютере (сообщения о проблемах с режимом доступа);
•	системный журнальный файл на машине-отправителе (проблемы с
определением имен и режимом доступа);
•	журнальный файл демона печати на печатающем компьютере (сообщения
о неправильных именах устройств, ошибках формата и т.д );
•	журнальный файл демона печати па маши не-отправителе (отсутствие
фильтров, неизвестные принтеры, отсутствие каталогов и т.д.):
•	журнальный файл принтера на печатающем компьютере (ошибки прн
передаче задания);
•	журнальный файл принтера на машине-отправителе (ошибки при пред-
варительном обработке и постановке задания в очередь).
При настройке удаленных принтеров не следует забывать о том. что на
машине-отправителе должна существовать очередь посылаемых на печать
заданий, должен быть определен метод принятия решения о том. куда
посылать задание, а также способ пересылки задания на удаленный компью-
тер. На печатающем компьютере должно быть место для постановки задания
в очередь, права доступа, необходимые для того, чтобы задание было
напечатано, и способ вывода на устройство.
778
Чостъ III Розное
Перед тем как начинать поиск причины проблем при сетевой печати,
проверьте, можно ли выполнять печать с локального компьютера, к которому
подключен принтер-
23.8	Основные программы печати
И BSD-системы, и системы System V обладают достаточными во лож-
ностями для организации очередей, контроля и вывода заданий печати,
однако ни в одной из них практически нет средств преобразования форматов,
необходимых для управления современными принтерами. В большинстве
своем производители обеспечивают как минимум один набор инструментов,
позволяющих дополнять системы печати необходимыми для форматирования
компонентами. Иногда этот инструментарий включается в ОС, но чаше всего
он поставляется как расширение, за отдельную плату. Кроме того, широко
используются пакеты третьих фирм и бесплатно распространяемые программы
Мы не ставили перед собой задачу подробно описать здесь эти
программные средства. В данном разделе дается лишь краткий обзор их
функциональных возможностей.
Программа rlpr
Если у вас нет желания резко переходить на использование LPRng. но
есть необходимость улучшить процесс печати на удаленных принтерах, то
обратите внимание на пакет rlpr. Данный бесплатный пакет содержит
команды, которыми можно заменить стандартные клиентские команды печати
системы BSD (Ipr, Ipq и Iprm). Эти новые команды полностью совместимы
со стандартными, но имеют ряд новых функций, более зашишены и надежны.
Команды пакета rlpr отправляют задания печати непосредственно на
сетевые принтеры (и поддерживают большое количество различных принте-
ров) без обращения к локальному демону Ipd. Локальные службы печати
полностью игнорируются, что дает возможность пользователям печатать на
новых принтерах и серверах печати без вмешательства системного админи-
стратора. Домашняя страница для пользователей пакета rlpr находится по
адресу irufTula.coin/rlpr. Это программное обеспечение работает в большинстве
систем UNIX.
Программа ghastscript
Программа ghostscript — это бесплатно распространяемый интерпретатор
формата PostScript, который позволяет просматривать файлы PostScript на
экране. Если нужно управлять какими-то устройствами вывода растровых
изображений, а вы не хотите тратить деньги на коммерческий драйвер, можете
попробовать написать свой драйвер на базе ghostscript Однако имейте в виду,
это очень сложная задача. Существует несколько версий программы. Ин-
формацию о них можно наити на Web-yx’te www.ghostscnpt.com.
Программа траде
Пакет mpage — это конвертер текстового формата в формат PostScript,
который дает возможность размещать несколько логических страниц на одной
физической. Использование этой программы позволяет сэкономить большое
количество бумаги и гем самым спасли жизнь множеству деревьев, в
Глово 23. Печоть
779
особенности когда речь идет о печати, например, исходных текстов, где
можно обойтись без крупного шрифта и широких полей.
Программа enscrlpt
Фирма Adobe разработала программный продукт enscript. предназначен-
ный для преобразования текстовых файлов в PostScript-файлы для печати.
Это программное обеспечение и подобное ему выдает поток текста,
“понятного” PostScript-принтерам. Кроме того, enscript обеспечивает форма-
тирование текста, например задание сложных титульных страниц или печать
двух страниц в уменьшенном масштабе на одной стороне листа.
Несмотря на то что фирма Adobe прекратила поддержку этого продукта,
он по-прежнему является неплохой альтернативой стандартным средствам
печати. GN U-версия программы enscript распространяется бесплатно и
обладает обратной совместимостью с версией фирмы Adobe. GNU-версия
enscript также обладает дополнительными функциональными возможностями,
такими как выделение текста на определенном языке, поддержка различных
размеров бумаги, загрузка в принтер шрифтов PostScript и задание пользо-
вательских титульных страниц.
GNU-версию программы enscript можно получить по адресу
people.ssh.fi/mtr/genscript
Так как большая часть работ по этому проекту была выполнена Маркку
Росси (Markku Rossi) из Финляндии, то по умолчанию используется формат
бумаги А4. Для “американизации" GNU-версии enscript после инсталляции
запустите команду configure с таким аргументом:
# ./configure —with-media—Letter
Формат бумаги также можно задать в командной строке запуска enscript.
Если вы забудете указать формат бумаги и примените программу enscript для
печати на высококлассном принтере, в различные подающие лотки которого
загружена бумага разных типов, принтер может вовсе отказаться печатать
задание.
23.9. Основные принципы работы с принтером
Основные неприятности, неизбежно сопутствующие работе с принте-
ром. — это различного рода неисправности и сбои. Впрочем, если что-нибудь
работает нс так, остается только радоваться, что это нс MS-DOS.
Организуйте учет роботы принтера
Учет работы принтера необходимо организовать даже в том случае, если
вы не собираетесь взимать плату за печать. Накладные расходы возрастут
незначительно, но появится возможность видеть, кто и как часто пользуется
принтером. Кроме того, можно будет получить информацию об источниках
заданий на печать, которая окажется весьма полезной при конфигурировании
новых принтеров.
Используйте строницы заголовки только
в случае необходимости
Система печати может предварять каждое задание страницей информации
о нем. Такие страницы-заголовки полезны при работе с принтерами.
780
Чость III Розное
которыми пользуются многие сотрудники, но если принтер загружен не
сильно или используется лишь несколькими пользователями, то печать
заголовков будет лишь тратой времени и бумаги. Если вам это не нужно,
выполните подавление печати заголовков. В BSD-системах это делается путем
установки в базе данных printcap булевой переменной sh в значение "истина”,
а в System V нужно просто исключить генерацию заголовка из интерфейсного
сценария.
Обеспечьте утилизацию отходов
Все виды компьютерной бумаги пригодны к переработке. Коробки, в
которых поставляется бумага, могут быть использованы в качестве контей-
неров для ненужных листов. Проверьте, чтобы такие коробки не содержали
посторонних материалов (например, скрепок, скоб скоросшивателей и газет),
и маркируйте их соответствующей надписью, чтобы утиль не отвергли.
Обеспечьте предворительный просмотр
Часто бывает так, что после распечатки документа пользователь обнару-
живает незначительную ошибку в форматировании, и приходится распечаты-
вать все задание заново. Ненужного расхода бумаги можно избежать, если
инсталлировать специальные программы, позволяющие увидеть готовый к
печати текст на экране дисплея.
Средства предварительного просмотра встроены во многие современные
WYSIWYG-редакторы, но если пользователи преданы старым наборным
системам, придется поискать другой способ просмотра документов.
Некоторые документы в формате PostScript можно просматривать с
помощью программы ghostscript. Для roff-документов подходит программа
xditsee, а для ТеХ попробуйте xdvi. После инсталляции необходимых программ
просмотра следует обучить пользователей работе с ними. Можно изучить
учетные записи печати, чтобы выявить документы, которые печатаются
многократно, и принять необходимые меры.
Приобретайте дешевые принтеры
Современный уровень печатающей техники является весьма высоким, и
на устройства с высокой производительностью и надежной механикой сейчас
не нужно тратить много средств.
Не гоняйтесь за дорогими принтерами “для рабочих групп”, если в этом
нет острой необходимости. По производительности, скорости печати и
надежности “персональный” принтер среднего уровня во многих случаях не
уступает дорогому “групповому”, не говоря уже о том, что он на десятки
фунтов легче. Принтер с производительностью 10 страниц в минуту может
обслуживать пять штатных клерков, поэтому гораздо выгоднее купить для
группы из 25 сотрудников пять тысячедолларовых принтеров, чем один за
пять тысяч.
Никогда не покупайте принтеры (да и жесткие диски, память и т.д.) v
продавцов компьютеров. Они обдерут вас как липку. Лучшие принтеры —
PostScript-принтеры, выпускаемые для рынков PC и Macintosh. На наш взгляд,
превосходными (и при этом очень дешевыми) изделиями являются принтеры
HP и Apple.
Глово 23 Печоть
781
Держите под рукой заносные картриджи с тонерам
В лазерных принтерах нужно регулярно менять картриджи с тонером,
поэтому всегда держите под рукой запасные расходные материалы. Наличие
полос и сероватых участков на документах — признак того, что тонер
заканчивается. Перед тем как менять картридж, выньте его из принтера и
осторожно встряхните, чтобы перемешать оставшиеся частицы тонера. Иногда
таким способом можно получить еше сотню-другую страниц.
Вместо замены картриджей их можно заправить новым тонером. Хорошие
фирмы не только заправляют картриджи, но и производят их чистку, а также
заменяют барабаны. Такая услуга стоит дорого, но это все равно дешевле,
чем покупать новые картриджи. У нас заправленные картриджи работают не
хуже новых
Производители принтеров получают большую часть своих доходов от
продажи чернил и специальных видов бумаги. В последнее время некоторые
жадные производители начали выпускать картриджи, которые нельзя повтор-
но заправить. Перед покупкой конкретного принтера поищите в Web
информацию о том, существует ли служба заправки картриджей для этой
модели.
Защищайте принтеры
Большинство современных сетевых принтеров поддерживают средства
удаленного управления. Возможность удаленного управления очень удобна
для системных администраторов, так как они могут выполнять конфигури-
рование без беготни по комнатам. Обычно для удаленного управления
применяются программные средства, работающие по протоколам telnet. HTTP
или SNMP Такие программы позволяют администратору но сети задать
IP-адрес принтера, шлюз по умолчанию. сервер ретистрации системных
событий, имя SNMP, параметры протокола и. что очень важно, пароль.
По умолчанию большинство принтеров, допускающих удаленное адми-
нистрирование. не защищено и пароль для доступа к ним следует задавать
в процессе инсталляции Например, чтобы задать пароль для нового принтера
HP Jet Direct посредством программы Jet Direct Telnet Client, сначала необхо-
димо с помощью кнопок на принтере установить ею параметры, касающиеся
протокола IP. Затем следует активизировать сеанс telnet-связи с принтером
и ввести пароль:
% telnet howler-lw
> passwd
Enter Password[16 character max.; 0 to disable]: > junkttbond
Password set co : newpass
782
Чость III Розное
QA Обслуживание аппаратных
средств
На протяжении многих лет UNIX служила базовой операционной
системой для широкого диапазона аппаратных платформ. Когда-то десятки
программистов совместно работали в одной системе, например в знаменитой
VAX. В те времена огромные усилия тратились на обслуживание техники и
обеспечение благоприятных условии ее эксплуатации. Опытные системные
администраторы знали об этиленгликолевых системах охлаждения столько
же, сколько об управлении учетными записями UNIX.
Девяностые годы ознаменовались бурным ростом количества настольных
рабочих станций и уходом в небытие ’‘больших железных ящиков’’ На
какое-то время показалось, что дни центральных машинных залов сочтены
Однако стремительное развитие архитектуры клиент/сервер привело к увели-
чению спроса на серверные платформы, на которых работает операционная
система, обеспечивающая гибкость, надежность, безопасность и производи-
тельность. Эту нишу заняла ОС UNIX, и миллионы серверов UNIX вернулись
в уже почти остывшие машинные залы (правда, в большинстве случаев
рабочие площади резко сократились). Задача формирования благоприятных
условий эксплуатации этих серверов остается столь же актуальной, как и
ранее.
В этой главе мы даем советы по обслуживанию аппаратных средств и
поддержке рабочих помещений в надлежащем состоянии. Но учтите. что
некоторые из наших рекомендаций вступают в противоречие с гарантийными
обязательствами производителей. Действуйте иа свой страх и риск.
24.1.	Основы технического обслуживания
Техническое обслуживание традиционно считалось областью, в которой
заключались дорогостоящие ежегодные контракты. Такие контракты и сегодня
практикуются, но они не популярны. Стоимость обслуживания обычно
составляет 10—12% прейскурантной цены устройства в год. Если вы можете
позволить себе заключить такой контракт с изготовителем или авторитетной
Глово 24. Обслуживание ап по ротных средств
783
третьей фирмой, обязательно сделайте это. Если нет. то вскоре вы сами
выработаете ‘чутье” на отказы и сможете составить свой план обслуживания
Если в организации ведется регистрационная книга, то беглый просмотр
записей за последние полгода-год ласт представление об интенсивности
отказов. Рекомендуем аккуратно вести перечень отказов и замен комплек-
ту-юших изделий, чтобы можно было дать точную оценку различным
вариантам обслуживания. Некоторые элементы дают сбой чаше, чем преду-
сматривается изготовителем, поэтому контракты иногда не только удобны,
но и выгодны с финансовой точки зрения. Помните, однако: приходит время,
когда все оборудование нужно уже не обслуживать, а менять. Не пропустите
момент и вовремя дайте своим аппаратным средствам ‘'тихо уйти на покой”.
Можно даже подарить списанное оборудование местной школе или универ-
ситету. Для них аппаратное обеспечение редко бывает слишком старым.
0 Подробно о списывании оборудования рассказывается в параграфе 27.12.
В настольных рабочих станциях обычно установлены материнские платы,
не подлежащие ремонту со стороны пользователей. Они дешевы и очень
надежны, но если все-таки что-нибудь отказывает, приходится заменять всю
плату.
На наш взгляд, самая лучшая методика обслуживания — это та. в основу
которой положена стратегия "избирательной гарантии" Изготовители диско-
водов часто дают гарантию до пяти лет. а у некоторых модулей памяти срок
работы вообще не ограничен. Гарантийный срок многих рабочих станций —
минимум год. Покупая новую технику, выбирайте ту, у которой самый
большой гарантийный срок. — это позволит в конечном итоге сэкономить
деньги.
24.2.	Контракты на обсп''живание
Некоторые крупные компании предлагают услуги по обслуживанию
аппаратных средств, выпускаемых другими фирмами. Эти компании часто
стремятся вытеснить изготовителя и занять его место Иногда можно добиться
очень выгодного контракта на техническое обслуживание, настроив изгото-
вителя против третьей фирмы Если есть возможность, соберите сведения
обо всех потенциальных сервисных центрах.
К сожалению, сервисные центры не всегда способны диагностировать
проблемы на уровне более глубоком, чем печатные платы в целом. Есть
старая шутка: ‘‘Сколько обслуживающего персонала нужно для замены
спустившей шины? Четыре человека — по одному на каждое колесо" Часто
бывает так, что инженер по ремонту просто наугад меняет платы, пока система
не заработает.
Типичный процесс обслуживания состоит из нескольких этапов, и его
характер зависит от типа сервиса.
Обслуживание на месте
Если контракт предусматривает обслуживание на месте, то инженер по
ремонту принесет запасные части прямо к машине. Гарантированный срок
его прихода колеблется в пределах от четырех до двадцати четырех часов и
как правило, оговаривается в контракте. В рабочее время вызванный
специалист обычно приходит гораздо быстрее, чем в нерабочее.
/84
Чость III. Розное
Обслуживание с заменой плат
Контракт на замен)' плат требует от администратора и его помощников
самостоятельного диагностирования проблем, возможно, при помощи спе-
циалистов службы круглосуточной поддержки фирмы-изготовителя. После
выявления неполадок нужно позвонить в службу, описать их и заказать
необходимую плату. Плата, как правило, отправляется немедленно и поступает
на следующий день. Ее нужно установить, включить аппаратуру, убедиться,
что все работает нормально, и вернуть на фирму старую плату в той же
упаковке, в которой была получена новая.
Иногда изготовитель присваивает каждой сервисной операции номер
разрешения на возврат покупки. Его следует написать на сопроводительных
документах, отправляемых со старой платой.
Горантии
Гарантийный Срок, установленный изготовителем аппаратуры, должен
играть значительную роль в расчете затрат на эксплуатацию оборудования
Обычной для компьютеров является трехмесячная гарантия, но иногда дают
год и даже больше.
В университетской среде, похоже, гораздо легче добиться федерального
финансирования капиталовложений, чем денег на содержание обслуживаю-
щего персонала и оплату сервисных услуг. Мы иногда оплачивали “продленную
гарантию” на новое оборудование (ее можно считать также обслуживанием
с предоплатой) чтобы превратить доллары, выделенные на закупку оборудо-
вания, в доллары, которые можно потратить на обслуживание.
Если заказы на компьютерную систему размещаются в нескольких
фирмах, ее компоненты обычно поставляются не одновременно. Гарантийный
срок должен начинаться только с момента доставки всего оборудования и
монтажа системы. И еще: учтите, что при наличии большого числа
компонентов самые большие проблемы в плане обслуживания и надежности
возникают почти сразу после установки системы.
24.3.	Уход за печатными  ..латами
Сегодня редко возникает необходимость “влезать" внутрь системы для
установки или замены печатных плат. Системы на базе ПК являются
исключением, так как для достижения уровня стандартной рабочей станции
в них нужно установить четыре-пять плат расширения. (Подсчитаем: SCSI,
аудиоплата, видеоплата, сетевая плата, модули памяти... Ого! А что же тогда
установлено на самой материнской плате?)
С печатными платами нужно обращаться аккуратно, не ронять их, не
проливать на них кофе, не класть на них книги и т.п Многие наладчики
(имеются в виду те обаятельные специалисты, которые приходят из фирмы,
с которой ваша организация заключила контракт на обслуживание) обраща-
ются с платами раз в десять грубее положенного
Статическое электричество
Электронные компоненты чувствительны к статическому электричеству.
Чтобы не повредить плату, перед установкой и во время нее следует заземлить
себя. Заземляющий провод, одетый на запястье и соединенный со специальным
ковриком, на котором вы стоите на коленях (большинство компьютеров
Глово 24 Обслухсивоние огпоротных средств
71 5
требует почтительного отношения!), надежно предохраняет платы от стати-
ческого электричества.
Помните о том, что беспокоиться о статическом электричестве нужно не
только во время установки платы, но и при первом вскрытии упаковки, в
которой она поставляется. Это особенно важно в том случае, если пол
помещения покрыт ковром: ковры генерируют больше статического электри-
чества, чем обычные полы
Вот один из способов снятия заряда с ковровых покрытий. Купите в
отделе хозтоваров антистатическое средство и раз в неделю распыляйте
водный раствор этого средства на ковре (на компьютеры брызгать не надо).
Эта процедура снижает уровень статического заряда до минимального, и,
кроме того, в помещении будет стоять свежий апрельский аромат.
Переустановка плат
Многие аппаратные проблемы можно устранить, просто выключив
питание оборудования, переустановив интерфейсные платы (SCSI, Ethernet
и т.д.) и включив питание вновь. Для этого необходимо вынуть каждую плату
из посадочного гнезда (обычно это разъем с высокой плотностью размещения
контактов) и установить вновь. Если проблема на некоторое время устраня-
ется, но через неделю или месяц возникает вновь, это, скорее всего, говорит
о плохом контакте между интерфейсной и материнской платами.
Если на плате смонтирован торцевой разъем, вытащите ее совсем и
почистьте контакты обычным ластиком. Резинка не должна быть старой и
жесткой; если она плохо стирает карандашные линии с бумаги, то электри-
ческие контакты она тем более не очистит. Старайтесь не прикасаться к
контактам пальцами. Протрите их ластиком, отряхните крошки и установите
плату на место.
На некоторых материнских платах (особенно в персональных компьюте-
рах) до сих пор устанавливают микросхемы, располагаемые в гнездах. Со
временем качество соединений в гнездах ухудшается, главным образом из-за
вибрации, вызванной работой вентиляторов. Попробуйте восстановить кон-
такт, сильно нажав на микросхему большим пальцем (естественно, сначала
следует надеть антистатический браслет).
24.4.	Мониторы
Монитор — наименее надежный компонент современной компьютерной
системы. Во многих моделях мониторов ряд важных регулировок можно
производить только на плате. Как известно, в мониторах часто используется
напряжение в десятки тысяч вольт, сохраняемое длительное время даже после
отключения питания. Из-за опасности поражения электрическим током для
регулировки монитора рекомендуется приглашать квалифицированного спе-
циалиста Не пытайтесь налаживать монитор самостоятельно.
24.5.	Модули памяти
В современных аппаратных средствах в основном применяются не
отдельные микросхемы памяти, а модули SIMM (Single In-line Memory
Module — модуль памяти с однорядным расположением выводов) или DIMM
(Dual In-line Memory Module — модуль памяти с двухрядным расположением
7G6
Чость III. Розное
выводов). Емкость этих модулей, устанавливаемых на одной маленькой плате,
составляет от 256 Кбайт до 512 Мбайт.
Если требуется расширить память рабочей станции юти сервера, модули
памяти можно заказать в какой-нибудь третьей фирме и установить их
самостоятельно. Не покупайте память у продавцов рабочих станций: онн
обдерут вас как липку*. Добавляя память, будьте щедрым. Цены на память
постоянно снижаются, одновременно с этим уменьшается и число слотов
расширения на типичной материнской плате.
При самостоятельной установке модулей памяти соблюдайте два основных
правила.
•	Модули памяти в большей степени, чем другие устройства, чувствительны
к электростатическим зарядам. Перед тем как открывать упаковку' с
модулями памяти, хорошо заземлитесь
•	В разных системах для монтажа модулей памяти на материнской плате
применяются различные разъемные соединения. Обычно модули встав-
ляются достаточно легко, а вот для их изъятия нужен специальный
инструмент. Не поддавайтесь искушению открыть защелки шариковой
ручкой или скрепкой, потому что это часто приводит к повреждению
разъема
ТА 6 Профилактическое обслуживание
В некоторых устройствах имеются воздушные фильтры, которые нужно
регулярно чистить или менять. Забитые фильтры препятствуют циркуляции
воздушного потока, что может привести к перегреву, а это одна из основных
причин отказов аппаратуры Вентиляционные отверстия на всех устройствах
всегда нужно держать открытыми. Часто можно видеть книги или газеты,
лежащие на вентиляционных отверстиях. В таких случаях к нарушителю не
грех применить и физические меры воздействия
Все устройства с движущимися частями требуют регулярной смазки,
чистки и профилактики приводных узлов. Сказанное относится главным
образом к старым построчно-печатаюшим принтерам, а также к старым
лентопротяжным механизмам и дисководам (все дисководы, выпускаемые
последние лет пять, полностью герметичны и обслуживания не требуют).
Следите за старым оборудованием и, едва заслышав визг, принимайте
соответствующие меры.
В серверных системах чаще всего ломаются вентилятор и блок питания.
Это особенно актуально для персональных компьютеров, где оба устройства
заключены в одном сменном модуле. Периодически проверяйте функциони-
рование вентиляторов. Если они начинают выходить из строя, необходимо
заменить весь модуль, иначе возникает риск перегрева компьютера. Не
пытайтесь самостоятельно смазывать вентилятор: эта процедура может
отсрочить неизбежный крах, а может и усугубить проблему либо привести к
повреждению других компонентов.
В пыльной среде компьютерные компоненты выходят из строя гораздо
чаше, чем в относительно чистом помещении Пыль попадает в воздушные
фильтры, высушивает смазку, забивает движущиеся механизмы (например,
вентиляторы) и покрывает устройства слоем “изоляции”, снижающим их
способность рассеивать тепло. Регулярно прочищайте воздушные фильтры.
• Имеется в виду не комплексная покупка. Приобретение памяти в составе готовой системы
может быть весьма выгодным делом для покупателя.
Глово 24. Обслуживоние оппоротных средств
787
При работе в неблагоприятных условиях рекомендуется иногда проводить
внутреннюю чистку компьютера (любое помещение, в котором есть ковер,
является неблагоприятной средой).
Удалять пыль лучше всего специальные пылесосами, но держите мотор
не менее чем в полутора метрах от системных компонентов для уменьшения
влияния магнитных полей. В компьютерном помещении следует регулярно
проводить уборку, причем делать это должен обученный человек, умеющий
соблюдать дистанцию и беречь оборудование от повреждений (уборщицам,
как правило, доверять нельзя).
Лентопротяжные механизмы также требуют регулярной чистки. Большин-
ство кассетных накопителей чистится с помощью специальной кассеты, а
для накопителей других типов может потребоваться ручная чистка техниче-
ским спиртом.
24.7.	Условия эксплуатации
Подобно людям, компьютеры работают лучше и дольше, если находятся
в благоприятной среде. Конечно, им не важно, какой вид открывается из
окна, но за другими параметрами помещения необходимо внимательно
следить.
Температура
Идеальная рабочая температура для компьютерной техники составляет от
17 до 20*С при влажности около 45%. К сожалению, она не соответствует
идеальной рабочей температуре для пользователей. При температуре в
компьютерном помещении выше 27'С внутри машин создается температура
около 45‘С. Для серийно выпускаемых микросхем верхняя граница диапазона
рабочих температур составляет около 45’С (в этой точке они перестают
работать), а при температуре свыше 7ГС микросхемы выходят из строя.
Влажность
Идеальная влажность для большинства компьютерных устройств — от 40
до 60%. Если влажность слишком низкая, возникают проблемы, связанные
с электростатическими зарядами. Если влажность слишком высокая, влага
конденсируется на платах, вызывая короткие замыкания и окисление.
Охлаждение офисных помещений
В наши дни многие компьютеры “коротают свой век” в офисах и
вынуждены “выживать” в условиях общей системы кондиционирования
воздуха (которая часто выключается по ночам и на выходные), с кипами
газет и книг на вентиляционных отверстиях. Устанавливая компьютер в
офисе, помните, что он будет поглощать воздух, которым дышат люди.
Инженеры систем отопления, вентиляции и кондиционирования воздуха
печально славятся своими неправильными оценками реальной тепловой
нагрузки помещений, где установлены компьютеры. Те. кто собирается
рассчитывать производительность системы охлаждения, должны помнить
правило: каждый человек в комнате производит 300 тепловых единиц (BTU)
в час, тогда как средний офисный персональный компьютер — 1100 единиц.
Не позволяйте инженерам забывать также о солнечной нагрузке тех окон,
которые пропускают прямой солнечный свет.
7СЗ
Чость 111. Розное
Охлождение мошинных золов
Тот, кому посчастливилось разместить свои UNIX-серверы в одном из
тех модных машинных залов с фальшполом, которые были построены в
80-е гг. и оснашены средствами охлаждения всей техники в зале, может
позволить себе заботиться лишь о базовом обслуживании системы кондицио-
нирования. Остальным же придется вспомнить математику, так как важно
правильно рассчитать производительность охлаждающей подсистемы.
Мы стараемся тщательно проверять оценки охлаждающей мощности,
выполненные специалистами из фирмы по установке кондиционеров, осо-
бенно когда речь идет о компьютерном помещении. В чем мы им полностью
доверяем, так это в расчете тепловой составляющей, приходящейся на
потолок, стены и окна Сне забывайте также о солнечной нагрузке). В данной
области у инженеров накоплен большой опыт и их оценки достаточно точны.
Проверки требует расчет внутренней тепловой нагрузки компьютерного
помещения.
Свой вклад в общую опенку вносят следующие компоненты:
•	потолок, стены и окна (расчет предоставляется специалистом);
•	электронные устройства;
•	осветительные приборы;
•	операторы (люди).
Электронные устройства
Для вычисления количества тепла, производимого серверами (и другими
электронными устройствами), необходимо определить их потребляемую
мощность. Проше всего снять показания непосредственно со счетчика
электроэнергии. Большинство устройств снабжено также паспортами, где
указана максимальная потребляемая мощность в ваттах, однако при нормаль-
ных условиях потребление энергии не достигает максимума. Тепловая
мощность измеряется в других единицах — BTU/час (British Thermal Unit —
британская тепловая единица), поэтому значение потребляемой мощности
необходимо умножить на 3,412 ВТи/(час*Вт). Например, если оборудуется
компьютерное помещение с 25-ю серверами, каждый из которых потребляет
450 Вт. расчет производится по формуле:
(25 серверов) (-^М) (VP.ETU) = 38385 МУ
\ к к / \ серверЧасх Вт /	час
Осветительные приборы
Как и в случае с электронными устройствами, вычисление тепловой
нагрузки осветительных приборов основано на их потребляемой мощности.
Типичный офисный светильник содержит четыре 40-ваттные флюоресцент-
ные трубки. Если в новом помещении шесть таких светильников, расчет
производится следующим образом:
.„«т
Глово 24. Обслужи во ние оллоротных средств
789
Операторы
В компьютерном помещении регулярно работают какие-то люди. Тепло-
вая мощность каждого из них — 300 BTU/час. Предположим, одновременно
в помещении находятся четыре человека. Тогда:
Л \/ 300 ВТ и оллВТи
14 человека II —------ ) — 1200——
\	i 'час*человека/	час
Общоя тепловая нагрузка
После вычисления тепловой мощности каждого компонента необходимо
сложить полученные значения, с тем чтобы определить общую тепловую
нагрузку. Допустим, специалист по установке кондиционеров подсчитал, что
тепловая составляющая потолка, стен и окон равна 20000 BTU/час. Тогда:
20000 BTU/час (потолок, стены и окна)
+ 38385 BTU/час (серверы и другие электронные устройства)
3276 BTU/час (осветительные приборы)
1200 BTU/час (операторы)
62861 BTU/час (всего)
Производительность системы охлаждения обычно выражается в тоннах.
Одна тепловая тонна равна 12000 BTU/час. Необходимо также ввести
коэффициент ухудшения (не менее 50%). что позволит учесть погрешность
вычислений и будущий рост тепловой нагрузки.
(62681^) (~ВТОС) (*’5) = ’.84 тонн охлаждения
Проверьте, то ли это значение, которое вам сообщил специалист.
Контроль температуры
При эксплуатации компьютеров в промышленных условиях рекоменду-
ется вести контроль температуры (а также других факторов окружающей
среды, например уровня шума и потребляемой мощности) в помещении, даже
когда администратора нет на месте. Никому не хочется после прекрасно
проведенных выходных прийти в понедельник на работу и обнаружить на
иолу лужицу расплавленного пластика. К счастью, можно воспользоваться
услугами системы автоматического контроля компьютерных помещений. Мы
рекомендуем обратить внимание на семейство продуктов Phonetics Sensaphone
Это недорогие устройства, позволяющие следить за параметрами окружающей
среды, такими как температура, уровень шума и т.д.. и сообщать о возникших
проблемах звонком на телефон (или пейджер) администратора. Узнать об
этих устройствах можно на Web-узле www.sensaphone.com.
24.8.	Источники питания
Компьютеры любят хорошее, стабильное и “чистое” питание. Для
компьютерного помещения это означает наличие стабилизатора напря-
жения — дорогого устройства, которое фильтрует выбросы и позволяет
устанавливать нужные уровни и фазы напряжения. В офисах можно
использовать фильтры, которые помогут уберечь аппаратуру от перепадов
напряжения в сети.
790
Чость III. Розное
Серверы и сетевое оборудование можно подключить к сети через
источник бесперебойного питания (Uninterruptible Power Supply. UPS).
Хороший UPS может подключаться к компьютеру через интерфейс RS-232.
Это позволяет источнику предупреждать компьютер о том. что напряжение
в сети пропало и что он должен успеть выключиться до того, как сядут
батареи
Проведенное исследование показало, что 13% от обшего количества
электроэнергии, потребляемой в Соединенных Шпатах, используется для
питания компьютеров. Традиционные UNIX-системы строились иа аппарат-
ных и программных средствах, которые были рассчитаны на круглосуточную
работу. Сегодня 24 часа в сутки должны работать только серверы и сетевые
устройства. Настольные компьютеры вечером нужно выключать.
[у7[ Более подробные сведения о процедуре останова системы содержатся в па-
раграфе 2.5.
Уходя домой, не забывайте выключать мониторы и лазерные принтеры,
так как это основные потребители электроэнергии При покупке нового
оборудования ищите устройства с сертификатом Energy Star. Его наличие
говорит о том, что устройство соответствует требованиям ЕРА (Environmental
Protection Agency — Управление по охране окружающей среды) по энерго-
сбережению. В частности, мониторы Energy Star после определенного периода
бездействия автоматически отключаются от сети.
Удаленное управление питанием
Иногда UNIX-сервер приходится регулярно перегружать' из-за аппарат-
ных проблем или сбоев в работе ядра Возможно также, что в помещении
имеются серверы Windows, которые сильнее подвержены подобным сбоям.
В любом случае может потребоваться установить систему, которая позволит
осуществлять дистанционную перезагрузку серверов.
Мы пользуемся недорогой и популярной системой контроля питания
Х-10. подключающейся к телефонной линии и реагирующей на тоновые
сигналы. Базовая линия продуктов Х-10 описана (и продается) на Web-узле
www.xlO.com.
Более сложное и дорогое решение предлагает компания А PC. Ее продукт
MasterSwitch может управляться посредством Web-броузера через встроенный
Ethernet-порт. Получить информацию о нем можно на Web-узле
www.apcc.com
24.9.	Стеллажи для аппаратуры
К ужасу парней с Уолл-стрит, которые считали фальшполы символом
корпоративного статуса, сродни обладанию автомобилем Ламборджини, эпоха
машинных залов с настоящими фальшполами ушла в прошлое Вы когда-
нибудь пытались проследить проводку кабелей под одним из этих пластиковых
чудовищ? Наш опыт показывает, что слово "фальшпол" является синонимом
словосочетания "крысиное гнездо". Если фальшпол нельзя не проложить,
используйте его для размещения электропроводки и ничего более.
При обустройстве профессиональных компьютерных помещений важно
выделить комнату для машин серверного класса. В серверной комнате можно
• Под перезагрузкой понимается процесс, при котором компьютер выключают, жгут 30—60
секунд, пока разрядятся батареи, а затем снова включают
Глово 24. Обслуживоние оппоротных средств
791
регулировать температуру и другие параметры окружающей среды; она также
позволяет соблюсти требования физической безопасности серверов.
С профессиональной точки зрения, единственный правильный вариант
для выделенного помещения — располагать оборудование в стеллажах (а не,
скажем, на столах или на полу). В лучших современных системах стеллажи
соединены подвесными конструкциями для прокладки кабелей. Это придает
помещению высокотехнологичный вид.
24.10.	Инструменты
Чем лучше оснащен системный администратор, тем эффективнее он
работает. Важно всегда иметь под рукой набор необходимых инструментов,
чтобы быстро реагировать на возникающие проблемы. В табл. 24.1 дан
перечень инструментов, которые у администратора должны быть с собой или
храниться неподалеку.
Тоблицо 24.1. Инструментарий системного одминистроторо
Инструменты общего нозночения	
Набор крестообразных отверток	Пинцет
Набор плоских отверток	Ножницы
Электротехнический иож	Набор торцевых ключей с удлиненны- ми головками
Плоскогубцы и круглогубцы	Маленький фонарик
Мелкие ювелирные отвертки	Набор шестигранных ключей
Молоток с круглым бойком	Набор ключей тиля TORX (шести- угольная звезда)
Специольные компьютерные инструменты	
Устройство для зачистки проводов (со встро- енными кусачками)	Сетевой анализатор
Кабельные соединители	Прибор для извлечения микросхем
Запасные переходные кабели категории 5 для интерфейса RJ-45	Обжимной инструмент для интерфей- са RJ-45
Запасные разъемы RJ-45	Терминаторы SCSI
Цифровой универсальный электроизмери- тельный прибор	Коммутационная панель
Антистатический браслет	
Розное	
Список адресов сервисных центров1	Изолента
Номера телефонов и пейджеров специали- стов, работающих по вызову	Зубоврачебное зеркальце
Аптечка	Мобильный телефон
Шесть упаковок хорошего пива	
И гарантийные талоны, если имеются.
792
Чость III. Розное
25 Анализ
производительности
Производительность — одна из наиболее заметных характеристик любой
системы, именно на нее чаще всего жалуются пользователи. Многие
пользователи убеждены в том. что их системы могли бы работать в два раза
быстрее, если бы администраторы знали, как нужно настроить эти системы,
чтобы реализовать заложенный в них огромный потенциал. В действитель-
ности это чаще всего не так.
Одно из известных заблуждений администраторов заключается в мани-
пулировании переменными ядра, которые управляют подсистемой виртуаль-
ной памяти и буферными областями. Когда-то давно это было действительно
необходимо и разумно. Сегодня данная идея изжила себя. Вероятнее всего,
вы просто снизите общую производительность системы и даже не узнаете о
том, что сделали, продолжая тем не менее поздравлять себя: ах, какой же я
классный специалист по ядру!
В современных системах ядро изначально настроено на достижение
достаточной (хотя и не оптимальной) производительности при различных
режимах работы. Если попытаться оптимизировать систему по какому-то
случайно выбранному показателю производительности, весьма вероятно, что
поведение системы ухудшится в отношении других показателей и режимов
работы Получение результатов кажется делом легким, но выигрыш чаше
всего — не более чем иллюзия.
В частности, относитесь скептически ко всему, что пишется в Internet.
Какие только аргументы не приводятся в дискуссиях по производительности
систем! При этом большинство сторонников всевозможных теорий не
обладает ни знаниями, ни дисципчиной, ни временем, необходимыми для
проведения достоверных экспериментов. Широкая поддержка пользователей
также ничего не значит, ибо каждое глупое предложение очень часто
сопровождается хором восторженных комментариев: '‘Я увеличил размер
кэш-буфера в десять раз, как предложил Джо. и система заработала ГОРАЗДО.
ГОРАЗДО быстрее!!!’'.
Кое-какие средства управления производительностью, конечно же, име-
ются. Просто нужно помнить о том, что для достижения высокой произво-
дительности недостаточно “волшебных” исправлений или “заплат".
Соблюдайте два основных правила.
Глово 25. Анолиз производительности
’93
•	Не перегружайте систему и сеть. UNIX создает для каждого процесса
иллюзию бесконечности ресурсов. Однако, как только в дело вступают
все 100'% ресурсов системы, операционной системе приходится работать
очень напряженно. На поддержку иллюзии расходуется ощутимая доля
самих ресурсов. В результате процессы замедляются.
•	Собирайте и анализируйте хронологические данные о работе системы.
Если еше неделю назад был полный порядок, а сейчас все изменилось,
сравнение характеристик системы в двух состояниях позволит выявить
источник проблемы. Всегда держите при себе список оптимальных
параметров производительности.
В этой главе мы сосредоточим внимание на производительности сервер-
ных систем. В настольных системах описанные ниже проблемы, как правило,
не возникают, поэтому ответ на вопрос о том, как повысить производитель-
ность настольной системы, обычно прост: “Проведи модернизацию”. Поль-
зователям такой ответ нравится, поскольку он означает, что им чаще придется
устанавливать у себя новые модные системы.
25.1.	Как повысить производительность
Приведем ряд советов, касающихся повышения производительности.
•	Убедитесь, что в системе достаточно памяти. Как будет показано ниже,
объем памяти — один из основных факторов, влияющих на производи-
тельность. Память сегодня столь дешевая, что ее можно оперативно
наращивать при первых же признаках загруженности системы.
•	Устраните проблемы, связанные с использованием ресурсов. Проблемы
могут создаваться как пользователями (одновременный запуск слишком
большого количества заданий, неэффективные методы программирова-
ния, выполнение заданий с завышенным приоритетом, запуск громоздких
программ в часы пик), так и самой системой (квоты, учет времени
центрального процессора, ненужные демоны).
•	Если UNIX-система используется в качестве Web-сервера или сетевого
сервера приложений, распределите трафик между несколькими компью-
терами с помощью коммерческой системы выравнивания нагрузки,
например Local Director компании Cisco (www.cisco.com) или ACEswitch
компании Alteon Networks (www.alteonwebsystems.com). Эти устройства
делают так, что несколько физических серверов начинают восприниматься
внешним миром как один логический сервер. Распределение нагрузки
осуществляется по алгоритму, выбираемому пользователем.
Такие системы обеспечивают также избыточность данных на случай, если
один из серверов выйдет из строя. Они совершенно необходимы, если
система должна выдерживать внезапные “всплески" активности.
•	Организуйте жесткие диски и файловые системы так, чтобы сбаланси-
ровать нагрузку на них и таким образом максимально повысить
пропускную способность средств ввода-вывода. В специфических ситуа-
циях, например при работе с базами данных, можно использовать
технологию RAID, позволяющую оптимизировать обмен данными.
Необходимо отметить, что разные приложения и СУБД по-разному ведут
себя, будучи распределенными на несколько дисков. У технологии RAID
имеется несколько вариантов реализации, поэтому придется потратить
усилия на выяснение того, какой из них (если таковой вообще имеется)
подходит для данного конкретного случая.
794
Чость III Розное
	Осуществляйте текущий мониторинг сети, чтобы избежать ее перегрузки
и добиться низкого коэффициента ошибок. Сети можно контролировать
с помошью программы netstat. о которой рассказывалось в парагра-
фе 20.4.
•	Сконфигурируйте ядро так, чтобы отключить ненужные драйверы н
опции, а также использовать системные таблицы корректного размера.
Эти вопросы освещаются в главе 12.
•	Выявите ситуации, когда система совершенно не удовлетворяет предъяв-
ляемым к ней требованиям
Эти меры перечислены в порядке убывания эффективности. Подключение
дополнительной памяти и распределение трафика между несколькими серве-
рами может значительно повысить производительность. Некоторого улучше-
ния можно добиться за счет правильной организации системных дисков и
устранения проблем с сетью. Все остальные меры могут и не дать желаемого
результата.
25.2.	Факторы, влияющие на производительность
Производительность системы во многом определяется эффективностью
распределения и коллективного использования ее ресурсов. Определение
термина ‘’ресурс" весьма расплывчато. Оно может подразумевать даже такие
компоненты, как кэш содержимого регистров центрального процессора и
элементы адресной таблицы контроллера памяти. В первом приближении,
однако, серьезное влияние на производительность оказывают только четыре
вида ресурсов:
•	время использования нейтрального процессора;
•	память;
•	полоса пропускания дисковой подсистемы ввода-вывода,
•	полоса пропускания сетевой подсистемы.
Каждый процесс потребляет некоторую часть ресурсов системы. Если
после того как активные процессы взяли все, что им нужно, остались
свободные ресурсы, можно сказать, что производительность системы является
удовлетворительной.
Если ресурсов недостаточно, процессы становятся в очередь. Процесс,
не имеющий немедленного доступа к необходимым ресурсам, должен
подождать, ничего при этом не предпринимая Время, затрачиваемое на
ожидание ресурсов. — один из основных показателей ухудшения производи-
тельности.
Самый простой с точки зрения учета ресурс — время использования
центрального процессора (ЦП). В распоряжении системы бывает всегда
примерно одна и та же часть его мощности. Теоретически эта величина
составляет все 100% циклов ЦП. но “накладные расходы’’ и другие причины
снижают эту цифру где-то до 95%. Для процесса, занимающего более 90%
времегга ЦП, ограничивающим фактором яталяется быстродействие централь-
ного процессора. Такой процесс потребляет большую часть вычислительных
мощностей системы.
Многие считают, что быстродействие ЦП — самый важный фактор из
тех. которые влияют на общую производительность системы. При наличии
неограниченных объемов всех остальных ресурсов или для определенных
типов приложений (например, программ численного моделирования) быст-
родействие ЦП действительно играет роль. На практике же этот показатель
не столь важен.
Глово 25. Анолиз производительности
/95
Настоящее узкое место в UNIX-системах — канал обмена данными с
жестким диском. Жесткие диски представляют собой механические системы,
поэтому на поиск необходимого блока, выборку его содержимого и пробуж-
дение ожидающего его процесса уходят десятки миллисекунд. Задержки такого
порядка отодвигают на второй план нее остальные источники ухудшения
производительности. Каждое обращение к диску вызывает приостановку7
активного процесса “стоимостью” в несколько миллионов команд ЦП.
Поскольку в UNIX исполгьзуется виртуальная память, то скорость
дискового обмена непосредственно связана с объемом имеющейся памяти.
В сильно загруженной системе с ограниченным объемом ОЗУ для получения
чистой страницы виртуальной памяти часто приходится записывать ее
содержимое на диск. К сожалению, это означает, что обращение к
оперативной памяти по своей "стоимости” приближается к работе с диском.
Выгрузка и подкачка страниц, вызванные непомерно раздутыми объемами
выполняющихся программ, в большинстве рабочих станций — враг номер
один производительности
Пропускная способность сети подвержена примерно таким же ограниче-
ниям, что и скорость дискового обмена. Ее ухудшение связано со всевоз-
можными задержками Но возникающие проблемы охватывают целые
сообщества, а не отдельные компьютеры. Кроме того, сети восприимчивы к
проблемам аппаратного обеспечения и перегрузкам серверов.
25.3.	Проверка производительности системы
Программы анализа производительности в большинстве своем сообщают
о том, что происходит в данный момент времени. Но следует учесть, что
структура и характер нагрузки в течение дня изменяются Поэтому перед
принятием мер обязательно проведите всесторонний анализ данных, касаю-
щихся производительности. Истинная производительность выясняется только
после длительного (месяц или даже больше) наблюдения за системой.
Анализ использования центрального процессора
Обычно собирают три вида данных о центральном процессоре: общим
показатель использования, средняя величина нагрузки и потребление ресурсов
с разбивкой по процессам. Первая характеристика определяет, является ли
скорость работы самого процессора слабым местом. Вторая характеристика
дает возможность оценить общую производительность системы. Данные,
касающиеся отдельных процессов, позволяют выявить такие процессы,
которые потребляют наибольшее количество ресурсов.
В большинстве систем требуемую информацию выдает команда vmstat. а
в Solaris и HP-UX этой цели служит команда sar -и Обе они принимают
два аргумента: время (я секундах), в течение которого нужно наблюдать за
системой для получения каждой строки выходной информации, и нсобходи-
мое число	о гчетов.	Например:		
% ваг -и	5 5			
13.-33:40	%usr	%sys	%W1O	
13:33:45	4	58	27	11
13:33:50	7	83	9	0
13:33:55	9	77	13	0
13:34:00	2	25	3	71
13:34:05	0	0	0	100
Average	4	49	10	36
796
Чость II! Розное
Команда sar -и выдает данные о доле времени центрального процессора,
затраченного на работу пользовательских программ (%изг), на выполнение
кода ядра (%зув) и на простой. При наличии процессов, заблокированных
в ходе выполнения высокоскоростных операций ввода-вывода (обычно это
обращения к жесткому диску), время простоя добавляется в категорию %wio,
в противном случае оно записывается в колонку % idle.
Команда vmstat выдает много разной информации. Сведения, касающиеся
центрального процессора, приводятся в последних колонках:
3 vmstat 5 5
procs
г b w	re
ООО	О
1 0 0	67
ООО	96
ООО	16
ООО	1
раде
mf	pi	ро	fr	de
0	0	0	0	0
2	0	0	0	0
0	0	0	0	0
0	0	0	0	0
0	0	0	0	0
faults
вг in	sy
0 4	22
0 26	751
0 39	1330
0 84	1626
0 11	216
cpu
cs	us	sy	id
19	2	1	97
52	53	47	0
42	22	71	7
99	7	74	19
20	1	11	88
Некоторые колонки в этом примере опущены. Данные, имеющие
отношение к выгрузке и подкачке страниц виртуальной памяти, мы пока
рассматривать не будем.
Пользовательское время, системное время и время простоя показаны
соответственно в столбцах us, sy и id. Большие числовые значения в столбце
us обычно означают вычисления, а в столбце sy говорят о том, что процессы
производят очень много системных вызовов или выполняют операции
ввода-вывода (команда vmstat показывает число системных вызовов в секунду
в столбце sy раздела faults). Выработанное нами за многие годы
эмпирическое правило, справедливое для большинства систем, гласит, что
система должна тратить примерно 50% рабочего времени на обслуживание
пользовательских запросов и столько же времени — на системные запросы.
Общее время простоя не должно быть нулевым. В колонке cs показано
число переключений контекстов за данный период, т.е. сколько раз ядро
переключало процессы. Слишком большое значение в данном столбце
свидетельстаует о неправильно работающем аппаратном устройстве.
Длительные измерения статистики работы центрального процессора
позволяют определить, достаточно ли его ресурсов для нормальной работы.
Если процессор тратит часть своего времени на простой, значит, есть запас
по тактовой частоте. В этом случае увеличение быстродействия процессора
ненамного улучшит общую производительность системы, хотя может и
ускорить выполнение отдельных операций.
Как видно из приведенных примеров, центральный процессор постоянно
переключается из режима полной нагрузки в режим полного бездействия и
обратно. Поэтому необходимо наблюдать за показателями, соответствующими
обоим режимам, и выводить среднее за определенный период времени. Чем
меньше интервал наблюдения, тем ниже достоверность оценок.
Центральный процессор однопользовательской рабочей станнин обычно
тратит на простой 99% своего времени. Когда запрашивается прокрутка
содержимого одного из окон, ЦП справляется с этой операцией за несколько
секунд. В такой ситуации долгосрочный средний показатель использования
ЦП практически не имеет смысла.
Второй статистический показатель, полезный для оценки интенсивности
использования системы. — это средняя величина нагрузки, т.е. среднее число
выполняемых процессов. В общем случае сюда включаются процессы.
Главе 25 Анолиз производительности
79/
ожидающие обмена данными с диском или сетью, так что это не “чистый”
показатель использования ЦП. Тем не менее он дает достаточное представ-
ление о том, на сколько кусочков режется процессорный “пирог”. Среднюю
величину нагрузки можно узнать с помощью команды uptime:
% uptime
2:07pm up 4:02, 5 users, load average: 0.95, 0.38, 0-31
Выдаются три значения, которые в большинстве систем соответствуют
средней нагрузке за пять, десять и пятнадцать минут. Как правило, чем выше
средняя нагрузка, тем важнее общая производительность системы. Если
выполняется всего пишь один процесс, он. обычно, бывает ограничен
одним-единственным ресурсом (чаще всего центральным процессором или
пропускной способностью жесткого диска). Пиковый спрос на этот ресурс
и становится определяющим фактором производительности.
Когда в системе одновременно работает несколько процессов, нагрузка
может распределяться более равномерно. Если все работающие процессы
потребляют ресурсы ЦП, диска и памяти, то зависимость производительности
системы от ограниченных возможностей какого-то одного ресурса снижается.
В такой ситуации гораздо важнее следить за средними показателями нагрузки,
в частности за общим временем использования центрального процессора.
Современные системы плохо справляются со средней нагрузкой более 6.0
Показатель такого порядка — намек на то. что нужно начать поиск путей
искусственного перераспределения нагрузки, например попросить пользова-
телей запускать длительные процессы вечером или назначить процессам
приоритеты с помощью команды nice.
Подробнее о приоритетах можно узнать в параграфе 4.1.
Средняя величина нагрузки — это отличная метрика для повседневного
контроля системы. Если известен показатель нормально работающей системы
и при возникновении проблем показатель находится в том же самом
диапазоне, значит, следует искать внешний источник проблемы (это может
быть, к примеру, сеть). В противном случае нужно проверить процессы самой
UN IX-с ис темы
Еше один способ контроля над использованием ЦП — посмотреть, какую
часть его времени потребляет каждый процесс. Для этого служит команда ps
с соответствующими аргументами (-aux в Red Hat и FreeBSD, -elf в HP-UX
и Solaris). Чаще всего оказывается, что в перегруженной системе минимум
70% времени ЦП потребляется одним-двумя процессами (помните о том. что
команда ps сама занимает немного ресурсов). Запуск процессов-пожирателей
в другое время суток или снижение их приоритетов позволит высвободить
ЦП для выполнения других процессов.
Прекрасная альтернатива команде ps — программа top. Она выдает
примерно ту же информацию, что и ps. ио в "живом” формате, позволяющем
наблюдать за изменением состояния системы во времени"
Бочее подробная информация о программе fop содержится в параграфе 4.8.
Программа top потребляет довольно много ресурсов, поэтому пользуйтесь ею в разумных
пределах.
798
Чость III. Розное
Управление памятью в UNIX
Память обычно организована в виде модулей, называемых страницами и
имеюших объем минимум 4 Кбайт. Если эта величина превышает размер
страницы, поддерживаемый центральным процессором или контроллером
памяти, такие модули иногда называют ’’кластерами страниц”. Дисковые
блоки обычно меньше страниц памяти (1 Кбайт или 512 байт), поэтому ядро
связывает с каждой записываемой страницей несколько блоков.
Операционная система UNIX старается управлять памятью так, чтобы
страницы, к которым недавно обращались, хранились в памяти, а менее
активные страницы “выгружались”. Этот алгоритм известен под названием
LRU (least recently used — замещение наименее используемых элементов),
потому что те страницы, к которым долго никто не обращался, перемещаются
на диск. Отслеживание всех обращений к страницам — слишком дорогое
удовольствие для ядра, поэтому в большинстве версий UNIX используется
статистический метод управления памятью, известный как “алгоритм часов”.
Он обходится гораздо дешевле системы LRU, а результаты дает такие же.
Ядро ведет список неиспользуемых страниц, которые можно выгружать
на диск. Если памяти не хватает, страницы помещаются в этот список как
бы в случайном порядке (на самом деле существует определенный порядок,
в соответствии с которым стрелка “часов” указывает на все страницы
одинаково часто). Когда страница попадает в список, ее адрес удаляется из
контроллера памяти и при следующем обращении к ней выдается сообщение
об ошибке.
Если к “неиспользуемой” странице производится обращение до ее
выгрузки (так называемая нестрогая ошибка), ядро изымает ее из списка и
восстанавливает соответствие адресов в контроллере памяти. После этого
страница находится в безопасности до следующего прохода стрелки. Обычно
страницам, к которым обращаются нечасто, спастись не удается; их
содержимое в конце концов переписывается на диск, и освободившиеся
страницы можно использовать для других процессов*
Потребность в памяти меняется, поэтому' ядро может запускать алгоритм
часов с разной скоростью. Если свободной памяти много, часы не работают
вовсе, освобождая систему от необходимости обрабатывать нестрогие ошибки.
Когда спрос на память крайне высок, часы “тикают" очень быстро и страницы
нужно “спасать" гораздо быстрее, иначе они будут выгружены на диск.
Если к помешенной в список странице в течение какого-то промежутка
времени не было обращения, то система виртуальной памяти считает эту
страницу “неактивной” и может выгрузить ее содержимое в файл подкачки.
Для выбора соответствующей скорости “часов” системе приходится прогно-
зировать будущую активность процесса замещения страниц. Если “часы”
станут работать слишком медленно, того числа страниц, которое находится
в списке, может не хватить для обеспечения достаточного объема памяти.
Если ‘’часы", наоборот, начнут работать быстрее, чем нужно, ядро будет
тратить лишнее время на обработку нестрогих ошибок.
Поскольку алгоритм выгрузки — прогнозирующий, то между сзучаями
выгрузки страниц и случаями выделения страниц работающим процессам не
обязательно должно быть однозначное соответствие. Цель системы — обес-
печить наличие достаточного объема памяти, чтобы процессам не приходи-
лось ждать выгрузки страниц всякий раз, когда им нзжна свободная память.
Не всегда нужно сохранять на диске содержимое страницы, которая будет использоваться
повторно. Те страницы, содержимое которых можно извлечь из доступных для системы
источников, просто выбрасываются.
Г нова 25 Анолиз производительности
/99
Перекачка (свопинг) реализуется несколько иначе, чем выгрузка. Она
также осуществляется упреждаюше, но на основе точных записей о каждом
процессе, а не статистических оценок. Если свободной памяти очень мало
и известно, что тот или иной процесс по каким-то причинам долго
простаивает (десятки секунд), лучше сразу выгрузить из памяти все его
страницы, а не ждать, пока их соберет алгоритм часов.
Когда ядро принудительно выгружает из памяти готовые к выполнению
процессы, это очень плохой признак. Такую ситуацию называют "пробук-
совкой”, или “перекачкой от отчаяния”, и означает она крайний дефицит
памяти При этом значительная часть ресурсов системы тратится не на
полезную работу, а на управление памятью.
Похожая патология системы виртуальной памяти может иметь место,
когда два больших процесса конкурируют за право использования централь-
ного процессора. Когда первый процесс начинает работу, он активизирует
группу своих страниц, вытесняя некоторые страницы второго процесса. Затем
запускается второй процесс, который восстанавливает свои страницы за счет
первого. В результате ни один из двух процессов не работает нормально.
•‘Воровать” страницы могут даже процессы, работающие с низким
приоритетом Предположим, например, что на рабочей станции выполняется
моделируюшая программа с очень низким приоритетом (и, соответственно,
высоким значением nice), и одновременно с этим в окне терминала
пользователь читает электронную почту. Как только пользователь делает паузу,
чтобы прочесть сообщение, показатель использования ЦП падает до нуля и
моделируюшая программа получает разрешение на работу. Она активизирует
все свои страницы, вытесняя из памяти интерпретатор команд, менеджер
окон, программу чтения почты и, наконец, эмулятор терминала. Когда
пользователь нажимает клавишу <N> для перехода к следующему сообщению
возникает длинная пауза, потому что большой блок памяти системы перекачан
на диск. Таким образом, на практике высокое значение nice не гарантирует, что
процесс с низким приоритетом не вызовет ухудшения производительности.
Анолиз использовония памяти
Для тех, кто работает на рабочих станциях, самый лучший анализатор —
уши. Интенсивность операций подкачки, как правило, пропорциональна
громкости "треска”, который слышится из дисковода. В большинстве случаев
он вызван обычным перемещением головок, но соответствие достаточно
корректно и позволяет получить общее представление о происходящем.
Интенсивность операций с памятью количественно представляется двумя
показателями: общим объемом задействованной виртуальной памяти и
скоростью подкачки. Первый показатель характеризует общую потребность в
памяти, а второй указывает на то. какая доля этой памяти активно
используется. Цель заключается в снижении интенсивности использования
или увеличении объема памяти до тех пор, пока не будет получен приемлемым
уровень подкачки. Подкачка — процесс неизбежный поэтому полностью
избавиться от нее не удастся никогда.
Данные об объеме используемой области подкачки можно получить с
помощью команды swap -1 в Solaris, spawinfb в HP-UX, доароп -s в Red Hai
и pstat -s во FreeBSD. В Solaris есть также команда sar -г (как обычна, с
аргументами. задающими интервал наблюдения), но по каким-то причиним
она дает результат, не полностью совпадающий с результатом команды swap -I.
% swap -1
swapfile	dev swapl blocks free
Ci
Чость III. Розное
Zdev/dsk/cOtCdOsl 32,1	16 164400 162960
% tar -r 5
17:58:52	freemem	freeawap
17:58:57	361	179616
% patat -a
Device	IK-blOcks	Used	Avail	Capacity	Type
/dev/wdOslb	70784	0	70656	0%	Interleaved
/dev/daOb	1048920	0	1048792	0%	Interleaved
Total	1119448	0	1119448	0%
Команда pstat позволяет узнать объем области подкачки в килобайтах,
тогда как команды swap -I и sar -г — в 512-байтовых блоках. В число величин,
сообщаемых этими командами, не входит объем ОЗУ, поэтому общий объем
виртуальной памяти приблизительно можно оценить по такой формуле:
ВП - ОЗУ * используемый_объеы_области_подкачки
В большинстве систем статистику страничных
помощью команды vmstat:
операций
получают с
% vmstat 5 5
procs memory
г b w swap free
000 338216 10364
000	341784	11064
000 351752 12968
000 360240 14520
100 366648 15712
page
re	mf	pi	po	fr	de	sr
0	3	1	0	0	0	0
0	26	1	1	1	0	0
1	69	0	9	9	0	0
0	30	6	0	0	0	0
0	73	0	8	4	0	0
disk
sO s6 s4 —
0 0 0 0
0 0 10
0 0 2 0
0	0	10
0 0 36 0
faults
in sy cs
132 101 58
150 215 100
173 358 156
138 176 71
390 474 237
Информация об использовании центрального процессора в этом примере
опущена. Под заголовком procs показано количество процессов, готовых к
немедленному выполнению, заблокированных в ожидании ввола/вывода. а
также готовых к выполнению, но перекачанных на диск. Если значение в
колонке w когда-нибудь станет отличным от нуля, это будет означать, что
объем системной памяти не соответствует текущей нагрузке.
В колонке swap выдается объем доступной виртуальной памяти в
килобайтах. В колонке free отображается объем (в килобайтах) списка
неиспользуемых страниц системы. Если приведенные в ней числа не
достигают 3% от общего объема системной памяти, это говорит о наличии
проблем.
В следующих семи колонках содержатся сведения о страничных опера-
циях. Приведены средние значения (количество в секунду).
• ге — число возвращенных (восстановленных из списка неиспользуемых)
страниц;
•	mf — число незначительных ошибок (связанных с небольшим числом
страниц);
•	pi — объем подкачанных данных в килобайтах;
•	ро — объем выгруженных данных в килобайтах;
•	fr — объем списка неиспользуемых страниц в килобайтах;
•	de — объем “ожидаемого краткосрочного дефицита памяти” в килобайтах;
•	sr — число страниц, обработанных по алгоритму часов.
Самый надежный показатель возникновения серьезных проблем с
памятью — колонка de. Если стоящее в ней число часто зашкаливает за 100,
Глово 25. Анолиз производительности
8U
это значит, что компьютеру нужно больше памяти К сожалению, во многих
версиях команды vmstat это значение не выводится
Команда vmstat -S выдает статистические данные не по страничным
операциям, а по перекачке процессов
Кажущиеся несоответствия между колонками большей частью иллюзорны.
В одних колонках указывается число страниц, а в других — объем к
килобайтах. Алгоритм часов не отвечает за все случаи освобождения страниц,
так как некоторые страницы могут добровольно освобождаться самими
процессами. Все приведенные числа — округленные средние. Более того,
одни из них — средние скалярных величин, а другие — средние изменений.
Например, нельзя вычислить следующее значение free по текущему
значению этого параметра и имеющимся сведениям о страничных операциях,
потому что события, которые определяют следующее среднее значение tree,
еще не произошли.
Подкачка данных не обязательно означает, что из области подкачки
восстанавливается страница. Это может быть исполняемый код, постранично
загружаемый из файловой системы, или копия страницы, дублируемой при
записи. Оба этих случая нормальны и не обязательно означают нехватку
памяти. С другой стороны, выгрузка всегда говорит о принудительном изъятии
данных ядром.
Когда в системе имеет место непрерывный поток операций выгрузки, ей
явно не хватает памяти. Если же выгрузка происходит лишь время от времени
и не создает никаких проблем, на нее можно не обращать внимания. Если
состояние системы — где-то посередине, дальнейший анализ будет заиисеп.
от того, что нужно сделать: оптимизировать систему для интерактивною
режима (например, как рабочую счаннию) или сконфигурировать ее для
одновременной работы пользователей (например, как сервер приложении)
Если половину операций обмена составляет выгрузка, можно подсчитать,
что каждые 50 таких операций создают задержку приблизительно в одну
секунду. Если для прокрутки окна необходимо провести 75 операций
выгрузки, придется ждать их окончания около полутора секунд. Исследова-
тели пользовательских интерфейсов утверждают, что средний пользователь
считает систему “медленной”. если время ее реакции превышает семь десятых
секунды.
Анализ операций обмена с диском
В большинстве систем можно контролировать пропускную способность
жесткого диска с помощью команды iostat. Как и vmstat, эта команда имей
необязательные аргументы, задающие промежуток времени в секундах между
моментами выдачи статистических данных за истекший период и число
повторений. Первая строка выходной информации содержит сводку' событии,
произошедших с момента начальной загрузки системы. Как и vmstat, команда
iostat выдает информацию об использовании времош центрального процессора
% iostat 5 5
tty
tin	tout
0	1
0	39
2	26
3	119
1	16
s do
kps tps serv
5*1	18
0	0	0
3	0	13
0	0	0
5	1	19
sdl
kps	Lps	serv
14	2	20
2	0	14
8	1	21
19	2	13
0	0	0
nfsl
kps tps serv
’ 0	’ 0	0
0	0	0
0	0	0
0	0	0
0	0	0
cpu
us sy к io
0 0 0 99
000 10L
000 ICv
0 1 1 98
0 0 0 10L
81?
Чость III Розно»
Колонки разделены по темам (в данном случае их пять: tty, sdO, sdl,
nfsl и cpu). В разных системах выходная информация команды iostat
выглядит по-разному (данный пример взят из Solaris).
В разделе tty содержатся данные о терминалах и псевдотерминалах.
В обшем-то, это неинтересная информация, хотя она и может оказаться
полезной для опенки пропускной способности модема. В колонках tin и
tout дается среднее суммарное число символов, введенных и выведенных
всеми терминалами системы за секунду.
Информация о каждом жестком диске размешается в колонках kps, tps
и serv: объем данных, пересланных за секунду (в килобайтах), общее
количество пересылок за секунду и среднее время позиционирования головки
в миллисекундах. Одно обращение к диску может затронуть сразу несколько
его секторов, поэтому соотношение между числами, приведенными в столбцах
kps и tps, говорит о структуре пересылок: то ли это несколько крупных
пересылок, то ли множество мелких. Крупные пересылки более эффективны.
Механизм вычисления времени позиционирования, похоже, работает только
на некоторых дисковых накопителях и иногда дает странные результаты
(к значениям, приведенным в данном примере, это не относится).
В некоторых системах поддерживается команда iostat -D, которая выдает
данные об интенсивности использования каждого диска в процентах:
% ioatat -D 5
sdl
rps	wps	util
0	0	1.3
9	8	41.1
11	4	48.4
8	0	15.6
0	0	0.0
5
sd2
rps	wps	util
0	0	0.3
1	0	1.8
0	12.0
0	0	0.0
0	0	0.0
sd3
rps	wps	util
0	0	0.5
1	0	2.4
0	0	0.0
0	0	0.0
0	0	0.0
sd5
rps wps util
1	1	4.2
6	8	34.8
3 11 32.6
3	0	9.2
0	0	0-0
Здесь интенсивность использования определяется в виде количества
операций чтения и записи в секунду.
Время, затрачиваемое на подвод головки, — самый важный фактор из
тех, что влияют на производительность дискового накопителя. В первом
приближении скорость вращения диска и быстродействие шины, к которой
он подключен, не имеют особого значения. Современные диски могут
пересылать десятки мегабайтов данных в секунду, если эти данные считыва-
ются из смежных секторов. В то же время количество операций позициони-
рования головки ограничено 50—100 в секунду. Если после каждой операции
поиска пересылаются данные всего лишь из одного сектора, легко подсчитать,
что задействуется менее 5% максимальной пропускной способности накопителя.
Затраты времени на подвод головки возрастают, если ей приходится
перемещаться на большие расстояния. Если есть диск с файловой системой,
записанной в разных разделах, и файлы считываются из каждого раздела в
случайной последовательности, то для перехода из одного раздела в другой
головка должна проходить очень большой путь. С другой стороны, файлы в
одном разделе расположены относительно близко друг к другу. Разбивая
новый диск на разделы, необходимо принять во внимание факторы,
влияющие на производительность, и постараться поместить файлы, обраще-
ние к которым производится одновременно, в одну файловую систему.
Глово 25. Анализ производительности
803
Для достижения максимальной производительности нужно помещать
файловые системы, которые используются одновременно, на разные диски.
Большинство компьютеров может работать с несколькими дисками парал-
лельно, что значительно повышает пропускную способность дисковой под-
системы (это, однако, зависит от архитектуры шины и драйверов устройств).
Например, данные и журнальные файлы Web-ссрвера имеет смысл размешать
на разных дисках.
Если в системе много дисков, то поднять производительность можно за
счет установки нескольких дисковых контроллеров или шин SCSI. Эффек-
тивность этого метода зависит от архитектуры системы Обратитесь к
документации на аппаратуру или посоветуйтесь с поставщиком.
Особенно важно по возможности распределять между несколькими
дисками область подкачки, поскольку подкачка обычно замедляет работу
системы в целом. Это можно сделать в любой из систем, воспользовавшись
либо командой swapon, либо командой swap, либо файлами конфигурации
ядра (см. главу 8). Многие системы позволяют организовывать как выделен-
ные разделы подкачки, гак и файлы подкачки, записываемые в обычную
файловую систему. Выделенные разделы более эффективны; если есть
возможность выбора, файлами подкачки лучше не пользоваться.
В некоторых системах можно настроить каталог /tmp как "резидентную”
файловую систему — это фактически то же самое, что и виртуальный диск
ПК. Специальный драйвер выдает себя за драйвер диска, но на самом деле
записывает данные в память. Этот прием приводит к уменьшению объема
памяти, доступной для общего пользования, но значительно ускоряет чтение
и запись временных файлов. Как правило, такой подход оказывается весьма
эффективным. Более подробную информацию можно получить на man-стра-
ницах, посвященных команде tmpfs (Solaris), ram (Red Hat) или mfs (FreeBSD).
Есть приложения, которые замедляют выполнение основных операций и
тем самым ухудшают производительность системы. В качестве примеров
приведем дисковые квоты и учет работы центрального процессора. Квоты
требуют изменения статистической сводки использования дисков по мере
записи и удаления файлов, а учет времени ЦП предполагает запись данных
в учетный файл после завершения работы каждого процесса Кэширование
диска помогает смягчить воздействие этих факторов, однако оно все равно
может быть ощутимым. Поэтому подобные средства нужно включать лишь
в случае серьезной необходимости.
Виртуальный помощник Адриан
Администраторы операционной системы Solans могут обращаться за
помощью к Адриану, т.е. Адриану Коккрофту (Adnan Cockcroft). Он является
экспертом компании Sun по вопросам производительности и занимается
распространением собственных утилит анализа и настройки системы. Его
пакет SymbEL (известный как SE) представляет собой интерпретатор языка,
предназначенного для построения такого рода утилит. В пакет включен набор
правил “Виртуальный Адриан”, в котором обобщен многолетний опыт
Адриана по настройке производительности операционной системы Solaris.
Компания Sun официально не поддерживает этот пакет, но его можно
загрузить с Web-узла Sun по следующему адресу.
Iittp://www.sun.com/sun-on-nei/performance/se3
804
Чость III. Розное
Команда procinfo: отображение данных
о производительности в Red Hat
В Red Hat есть команда procinfo, которая выдает удобную сводку
производительности системы. Примерно то же самое делает команда vmstat,
но в менее понятной форме. Особенно полезна информация о прерываниях,
отображаемая на персональных компьютерах. Если система не слишком
загружена, запустите в отдельном окне команду procinfo -Г. которая будет
обновлять результаты каждые 5 секунд.
% procinfo
Linux 2.2.5-15 (root0porky.devel.redhat.com) (gcc egcs-2.91.66) #1 iredhatl
Memory:	Total	Used	Free	Shared	Buffers	Cached
Mem:	30756	23908	6848	9084	12496	3968
Swap:	133016	224	132792
Bootup: Tue May 2 12:26:13 2000 Load average: 0.08 0.02 0.01 1/26 16173
user	:	0:08:15.35	0.0%	page	in :	774301 disk 1: 229922г	109442w
nice	:	0:00:00.00	0.0%	page	out:	177675
system:	0:10:46.41	0.0%	swap	in :	183
idle	: 30d 2:06:40.89	100.0%	swap	out:	60
uptime: 30d 2:25:42.64	context : 7221B65
irq	0 :	260074265 timer	irq	10	3032801	ethO
irq	1 :	8	keyboard	irq	13	1	f pu
irq	2 :	0	cascade [4]	irq	14	1905415	ideO
irq	6 :	3	irq	15	5	idel
irq	8 :	2	rtc				
Комондо pstot: вывод статистических донных во FreeBSD
Еше одно полезное средство, имеющееся во FreeBSD, — команда pstaL
Она отображает содержимое различных таблиц ядра в форме, почти понятной
для пользователя. В выдаваемой информации нет никакой объединяющей
темы. Команда просто извлекает из ядра все интересные данные. Возможны
следующие виды отчетов:
•	дамп таблицы индексных дескрипторов (-1);
•	дамп таблицы процессов, более подробный, чем у команды ps (-Р),
•	дамп таблицы открытых файлов (-П;
•	информация о состоянии всех терминалов (-t),
•	информация о заданном процессе (-в);
•	информация об использовании области подкачки (-s).
•	информация о степени заполненности таблиц ядра (-Т).
Команда pstat -Т используется при конфигурировании ядра, так как она
позволяет определить оптимальное значение параметра maxusers- К сожа-
лению, эта команда показывает лишь малую толику того, на что влияет
параметр maxusers, поэтому следует предусматривать значительный запас
по этому параметру. Подробнее об этом рассказывалось в главе 12.
Глово 25. Анолиз производительности
805
25.4. Помогите! Моя система почти осгановиллсь!
В предыдущих параграфах мы говорили в основном о том, что касается
средней производительности системы Для ее повышения требуется коррек-
тировать конфигурационные параметры или модернизировать систему.
Но даже правильно сконфигурированные системы иногда работают
медленнее обычного. К счастью, нерегулярные проблемы в большинстве
своем легко поддаются диагностированию. В 90% случаев они создаются
алчным процессом, который потребляет так много ресурсов процессора или
жесткого диска, что остальные процессы буквально останавливаются.
Иногда для того чтобы определить, какой конкретно ресурс пожирается,
не нужно даже запускать диагностическую программу. Если система начинает
“пробуксовывать"* или диск подозрительно долго и громко перемалывает
данные, проблема, скорее всего, связана с пропускной способностью лиска
или дефицитом памяти. Если же производительность приложений падает
ниже критического уровня, проблема, должно быть, вызвана недостаточной
мощностью центрального процессора.
Первый шаг в установлении диагноза — запуск команд ps и top для
выявления заведомо неуправляемых процессов. Любой процесс, потребляю-
щий более 50% времени ЦП. можно с большой долей вероятности считать
ненормальным. Если столь непомерную долю ресурсов ЦП не получает ни
один процесс, посмотрите, сколько процессов получают минимум по 10%.
Когда их больше двух-трех (не считая самой команды ps), то средняя нагрузка,
скорее всего, будет очень высокой Такая ситуация сама по себе является
причиной низкой производительности. Проверьте среднюю загруженность
системы с помощью команды uptime, а затем вызовите команду vmstat или
sar -и, чтобы узнать, простаивает ли когда-нибудь процессор.
Если конкуренции за право использования центрального процессора не
наблюдается, посмотрите путем вызова команды vmstat или sar -g, каков
объем операций подкачки. Следует обращать внимание на все операции
обмена с диском: множество операций выгрузки может означать соперниче-
ство за память, а наличие дискового трафика при отсутствии подкачки говорит
о том, что какой-то процесс монополизировал диск, непрерывно читая и
записывая файлы.
Способа непосредственного сопоставления дисковых операций и процес-
сов не существует, но с помощью команды ps можно сузить круг подозре-
ваемых. Любой процесс, вызывающий дисковый трафик, скорее всего,
использует некоторую часть времени ЦП. Обычно всегда можно сделать
обоснованное предположение о том, какой конкретно из активных процессов
является истинным виновником интенсивной загрузки процессора**. Для
проверки своей теории на практике выполните команду kill -STOP.
Предположим, процесс-виновник найден. Что же делать с ним дальше'.'
Как правило, ничего. Некоторые операции действительно требуют много
То есть требуется больше времени на переключение между приложениями, хотя скорость
выполнения отдельных заданий приемлема.
Раньше подозрительными признаками служили или большой размер области данных
процесса, размещенной в виртуальной памяти, или аномально большой объем занимаемой
процессом оперативной памяти, ио появление совместно используемых библиотек сделало
эти показатели не столь полезными. Большинство версий команды ps не настолько разумно,
чтобы отделять общесистемное пространство совместно используемых библиотек от адрес-
ного пространства процессов. Кажется, что многие процессы занимают мегабайты активной
памяти, хотя на самом деле это не так.
806
Чость III. Розное
ресурсов и неизбежно замедляют работу системы, но это вовсе не означает,
что они незаконны. С помощью команды renice можно изменить приоритет
процесса, для которого ограничивающим фактором является скорость ЦП,
но не забудьте попросить владельца этого процесса впоследствии выполнить
команду nice.
Процессы-пожиратели дисков и памяти нелегко поддаются воздействию.
Команда renice обычно не помогает. Можно уничтожить или остановить
процесс, но, на наш взгляд, такая мера оправдана только в экстренных
ситуациях Как и в случае с пожирателями времени ЦП. можно прибегнуть
к непопулярной мере: попросить владельца запустить процесс позже.
Некоторые системы позволяют ограничивать потребление процессами
физической памяти. Для этого служит системный вызов setrlimit. Обращение
к нему возможно через встроенную команду limit интерпретатора С shell.
Например, команда
% limit memoryuBe 32m
ограничивает использование физической памяти для всех последующих
пользовательских команд величиной в 32 Мбайт. Ее действие подобно
действию комвнды renice в отношении процессов, ограничивающим фактором
для которых является объем памяти. Можете тактично предложить “проблем-
ным” пользователям вставить такую строку в свои файлы .cshrc.
Если источником снижения производительности не является неуправляе-
мый процесс, нужно исследовать две другие вероятные причины. Первая —
перегрузка сети. Многие программы настолько тесно связаны с сетью, что
иногда трудно различить, где кончается производительность системы и
начинается производительность сети. Подробная информация о средствах
контроля над работой сети приведена в главе 20.
В некоторых случаях проблемы, вызванные перегрузкой сети, выявить
сложно, потому что они возникают и исчезают очень быстро. Например,
если на всех компьютерах сети каждый день в определенное время с помощью
демона стоп запускается какая-то сетевая программа, в сети может возникать
краткосрочная, но серьезная помеха. Все компьютеры зависнут секунд на
пять, а затем помеха исчезнет так же быстро, как и появилась.
Еше одна причина кризисов производительности — задержки, связанные
с серверами. UNIX-системы постоянно обращаются к удаленным серверам
для вызова служб NFS, NIS. DNS и т.п. Если сервер не функционирует или
какая-то иная проблема привела к тому, что связь с ним стала ненадежной,
это ощущают на себе все системы-клиенты. Предположим, к примеру, что
в интенсивно работающей системе какой-то процесс каждые несколько секунд
вызывает библиотечную функцию gethostent(). Если сбой в работе службы
DNS заставляет эту функцию тратить на свое выполнение две секунды, будет
заметно общее снижение производительности
25.5 Рекомендуемая литература
•	Cockcroft, Adnan and Richard Pettit. Sun Performance and Tuning: Java and
the Internet. Upper Saddle River, NJ: Prentice Hall. 1998.
•	Loukides, Mike. System Performance Tuning. Sebastopol: O'Reilly. 1991.
Глобо 25. Анализ производительности
807
26
Взаимодействие с Windows
Приходится признать, что операционные системы Windows не собираются
уходить в небытие. Игнорировать этот факт иелъзя, поэтому нужно научиться
мирно сосуществовать с таковым. Как известно, UNIX предоставляет удобные
средства работы с TCP/IP и Internet, тогда как именно в Windows работают
миллионы пользователей. А на долю системных администраторов выпадает
управление всем этим “сатанинским шабашем”.
К счастью, современные средства позволяют существенно снизить риск
отторжения Windows-трансплантата в UNIX. Реальность такова, что обе
платформы имеют свои сильные стороны и их можно заставить работать
совместно. Windows — популярная и удобная настольная платформа, способ-
ная стать тем мостиком, который соединяет пользователя и сетевой кабель,
уходящий куда-то в стену. По другую сторону этой стены находится UNIX —
целостная платформа с расширяемой инфраструктурой.
В настоящей главе рассматриваются различные вопросы, с которыми
приходится сталкиваться администраторам в этом постмодернистском мире —
среде совместного существования персональных компьютеров и платформы
UNIX
26.1.	Совместное использование файлов и принтеров
Наиболее высокий уровень интеграции персональных компьютеров и
платформы UNIX достигается благодаря совместному использованию ката-
логов, размешенных на UNIX-компьютере (или в специализированном
файловом сервере UNIX), настольными компьютерами, работающими пол
управлением Window's’. Совместно используемые каталоги могут быть
• Можно также монтировать файловые системы, расположенные на персональном компью-
тере и работающие под управлением Linux, но эта конфигурация функционирует нс совсем
стабильно.
808
Чость III Розное
настроены таким образом, чтобы представляться частью среды Windows: либо
в качестве логических дисков либо в качестве дополнения дерева сетевых
файловых систем Windows. Для выполнения этой функции можно использо-
вать файловую систему NFS или CIFS.
Файловая система NFS
Файловая система NFS (Network File System) разрабатывалась для
обеспечения возможности совместного использования файлов в сети UNIX-
компьютеров, где механизмы блокировки файлов и безопасности системы
существенно отличаются от таковых в среде Windows. И хотя имеется
множество программ, позволяющих монтировать NFS-каталоги в Windows,
следует избегать этого — во-первых, из-за различия архитектур, а во-вторых,
по причине того, что файловая система CIFS работает гораздо лучше.
Подробнее об NFS рассказывалось в главе 17.
Файловая система CIFS
CIFS (Common Internet File System — общая файловая система для
Internet) основана на протоколе SMB (Server Message Block — блок серверных
сообщений). SMB стал дополнением к DOS. когда-то давно разработанным
компанией Microsoft для того, чтобы операции дискового ввода/вывода
переадресовывались в NetBIOS (Network Basic Input/Output System — сетевая
базовая система ввода-вывода). Созданная компаниями IBM и Sytec система
NetBIOS представляла собой примитивный интерфейс между сетью и
приложениями.
В настоящее время пакеты SMB передаются через протокол NBT
(NetBIOS over TCP), являющийся расширением NetBIOS. Как ни парадок-
сально это звучит, упомянутые протоколы получили широкое распростране-
ние и стали доступными на многих платформах — от MVS и VMS до наших
любимых UNIX и Windows. Все оказались счастливы.
Samba: система CIFS для UNIX
Чрезвычайно популярный пакет Samba распространяется на условиях
открытой GNU-лицензии и реализует файловую систему CIFS на UNIX-
станциях. Он был создан Эндрю Триджеллом (Andrew Tridgell) из Австралии,
который путем “обратного” проектирования воссоздал кол протокола SMB.
использовав его реализацию в других системах, и опубликовал полученный
программный код в 1992 г.
Пакет Samba постоянно дорабатывается и расширяется. Он обеспечивает
стабильный, проверенный механизм интеграции компьютеров, работающих
под управлением Windows, в сеть UNIX. Прелесть Samba заключается в том.
что достаточно инсталлировать только один пакет на UNIX-компьютер —
никакого дополнительного программного обеспечения на Windows-компьютер
устанавливать не нужно’.
Файловая система C1FS предоставляет пять основных услуг:
•	совместное использование файлов:
•	сетевую печать;
•	аутентификацию и авторизацию;
При условии, что компьютер уже сконфигурирован в режиме "Microsoft networking".
Глово 26. Взаимодействие с Windows
809
•	преобразование имен;
•	объявление о наличии сервисов (“обзор” файловых серверов и принтеров).
Большая часть функций пакета Samba реализована в двух демонах: smbd
и nmbd. Первый предоставляет сервисы печати и доступа к файлам, а также
сервисы аутентификации и авторизации, а второй управляет другими
важными функциями C1FS — подсистемой преобразования имен и сервис-
ными объявлениями.
В отличие от NFS, которая жестко связана с ядром, пакет Samba не
требует модификации ядра и запускается исключительно как пользователь-
ский процесс. Он связывается с сокетами, через которые посылаются
NВТ-запросы, и ждет запроса от клиента на доступ к ресурсу. Как только
запрос поступает и аутентифицируется, демон smbd создает свой дубликат и
запускает его от имени пользователя, сделавшего запрос. В результате все
разрешения на доступ к UNIX-файлам (включая групповые разрешения)
остаются ненарушенными. Имеется только одна специальная функциональная
возможность, которую демон smbd реализует сверх этого, — сервис блоки-
ровки файлов, позволяющий клиентским персональным компьютерам при-
держиваться привычной для них семантики блокирования.
Инсталляция и конфигурирование пакета Samba
В настоящее время пакет Samba входит в комплект поставки систем Red
Hat н FreeBSD (его местоположение — каталог /usr/ports). а в Solans и
HP-UX его нужно загрузить и инсталлировать самостоятельно. Пакет доступен
по адресу www.samba.org.
Независимо от используемой системы следует отредактировать файл
smb.conf. указав в нем параметры конфигурации пакета Samba. В этом файле
задаются каталоги и принтеры, предназначенные для совместного использо-
вания, а также права доступа к ним. Все опции задокументированы на
тап-странине, посвященной файлу smb.conf. Ознакомиться с документацией
придется каждому, кто попытается интегрировать пакет Samba в сеть, в
которой уже настроен совместный доступ к файлам Microsoft.
Важно также понимать, какие угрозы безопасности возникают вследствие
совместного использования файлов или ресурсов в сети. В пакете Samba
имеются средства контроля безопасности, но они работают только тогда,
когда кто-то их применяет Чтобы обеспечить базовый уровень безопасности,
нужно выполнить два действия
•	Расположенная в файле smb.conf строка hosts allow задает адреса
клиентов, которым разрешен доступ к ресурсам Samba Удостоверьтесь,
что список содержит только проверенные IP-адреса (или диапазоны
адресов).
•	Блокируйте доступ из Internet к TCP-портам CIFS, соответствующим
образом настроив фильтрующий брандмауэр. Это TCP-порты с номерами
137—139. Более полную информацию о том, как осуществить подобную
настройку, можно получить в параграфе 21.9.
Ниже представлен образен полного файла smb.conf. используемого в
простой сети:
[global]
#	workgroup - имяцомена NT или. имя рабочей группы
workgroup “ MYGROUP
81.)
Чость 111 Розное
t Список узлов, которым разрешен доступ к объектам Samba.
#	Б данном случае допускаются лишь компьютеры двух сетей класса С-
hosts allow = 192.168.1. 192.168.2.
#	Автоматическая загрузка списка принтеров из файла .
printcap name = /etc/printcap
load printers - yes
#	Использование отдельного журнального файла на каждом компьютере
#	и задание его предельного размера равным 5С Кбайт.
log file = /var/log/samba/log.%m
max log size = 50
#	Выбор режима безопасности. В большинстве случаев требуется обеспечить
# безопасность на уровне пользователя. Более подробная информация
# об этом содержится в документации к пакету (файл security_level.txt).
security = user
# При желании можно установить парольную защиту. Этот процесс
t подробно описан в файлах ENCRYPTION.ext, Win95.txt и WinNT.txt,
# прилагаемых к документации. Не активизируйте данные опции,
# предварительно не прочитав документацию.
; encrypt passwords = yes
; smb passwd file = /etc/smbpasswd
#	Б большинстве случаев следующая установка обеспечивает повышение
#	производительности. Дополнительная информация имеется в файле
#	speed.txt, а также в документации.
socket options = TCP_NODELAY
#	Совместное использование начальных каталогов. Например, каталог
# ~trent в UNIX станет каталогом "trent** а проводнике Windows.
[homes]
comment = Home Directories
browseable = no
writable = yes
f Совместное использование всех принтеров.
[printers]
comment = All Printers
path = /var/spool/samba
browseable =- no
guest ok = no
writable = no
printable = yes
#	Совместное использование заданного каталога.
Принтеры уже должны быть подключены к (JNlX-компыотеру. Не все UNIX-системы
используют базу данных printcap, но Samba может адаптироваться к любой системе.
11одробнее об э том рассказывается в главе 23.
।  то 26. Взоимодействие с Windows
811
[develJ
comment - Staff Development Shared Directory
path - /devel/shared
public - no
writable - yes
printable - no
create mask =• 0765
Как видно из комментариев, этот файл настроен таким образом, что.
когда пользователи включают свои компьютеры, их начальные каталоги и
каталог /devel/shared оказываются общедоступными. Пользователи могут
также печатать на всех принтерах, имеющихся в сети.
Отладка пакета Samba
Обычно пакет Samba работает нормально, не требуя вмешательства со
стороны администратора. Тем не менее, если при запуске возникли проблемы,
можно обратиться к двум основным источникам отладочной информации:
журнальным файлам, разным для каждого клиента, и команде smbstatus.
Местоположение журнальных файлов указано в файле smb.conf. В жур-
нальном каталоге содержится файл для каждого клиента, обращавшегося к
пакету. Демон smbd хранит эти файлы так, чтобы их размер не превышал
заданной максимальной величины.
Следующие журнальные записи отражают успешные попытки соедине-
ний:
01/19/2000 17:38:01 pan [192.225.55.154) connect to service trent
as user trent (uid*-8164, gid*=lC) (pid 16625)
01/19/2000 17:40:30 pan (192.225.55.154) connect to service
silver-lw as user trent (uid-=B164, gid-=10) (pid 16625)
01/19/2000 17:43:51 pan (192.225.55.154) closed connection
to service silver-lw
01/19/2000 17:43:51 pan (192.225.55.154) closed connection co service trent
Команда smbstatus позволяет проверить текущие активные соединения и
открытые файлы. Эта информация особенно полезна, когда приходится
отслеживать проблемы блокировки (например, кто из пользователей открыл
файл xyz для чтения-записи в монопольном режиме). В первой части
выходных данных перечислены ресурсы, к которым подключены пользова-
тели, во второй дана информация об активных блокировках файлов, а в
третьей части отображена статистика использования ресурсов, собранная
демоном smbd’.
Samba version 2.0.5
Service	uid	gid	pid	machine
info	trent	staff	22545	pan
trent	trent	staff	22545	pan
Locked	files:			
Pid	DenyMode	R/W	Oplock	Name
22545 DENY_NONE RDWR EXCLUSIVE+BATCH /home/trent/res alioc 2.xls
Share mode memory usage (bytes):
1048336(99%) free + 168(0%) used + 72(0%) overhead - 1048576(100%) total
В выводе команды smbstatus содержится несколько весьма длинных строк; для большей
наглядности мы сократили распечатку.
812
Чость 111. Розное
Блокировку можно отменить, уничтожив демои smbd, который “владеет”
ею. Идентификатор процесса для каждой блокировки отображается в выводе
команды smbstatus. Не рассказывайте своим пользователям о том, что вы
знаете, как это делается, и помните, что принудительное снятие блокировки
может привести к повреждению файлов. Кто-то же должен делать грязную
работу!
26.2 Безопасная эмуляция терминала
с использованием системы SSH
Возможно, некоторые пользователи захотят покинуть мир Windows, чтобы
отправиться покорять манящие заснеженные вершины, на которых обитают
старые добрые интерпретаторы С shell или Korn shell. Конечно, простейший
способ сделать это — воспользоваться программой telnet, которую компания
Microsoft поставляет вместе с Windows. К сожалению, в ней отсутствует целый
ряд привычных средств, в частности таких, как непосредственные операции
вырезания и вставки. Кроме того, подобно многим реализациям протокола
TELNET, эта программа не имеет собственной концепции безопасности.
(Хотя кому нужна чужая командная строка?) К счастью, существуют
разнообразные эмуляторы терминалов, доступные в Windows; они гораздо
совершеннее, чем программа telnet компании Microsoft.
Наш любимый эмулятор — SecureCRT компании VanDyke Technologies,
Inc. Этот недорогой коммерческий продукт сочетает средства защищенного
входа в систему и передачи данных через систему SSH с надежным
эмулятором терминала. Поддерживается шифрование данных с длиной ключа
от 56 до 256 битов, а также переадресация портов других приложений, в
частности электронной почты. Более подробную информацию о продукте
можно найти на Web-узле www.vandyke.com.
0 Сведения о системе SSH содержатся в параграфе 21.8.
Другой коммерческий эмулятор — SSH client for Windows — предлагается
компанией F-Secure Corporation. Информация о нем доступна на Web-узле
www.fsecure.com.
Тем, кто ищет бесплатный эмулятор, советуем воспользоваться програм-
мой TeraTenn с подключаемым модулем TTSSH, доступной по адресу
http://hp.vector.co.jp/authors/VA002416/teraterm.html
Подключаемый модуль можно найти по адресу:
http://www.zip.com.au/" roca/ttssh.html
Совместно они предлагают весьма надежное и безопасное решение.
26.3. Эмуляторы X Windows
X Windows — это система управления окнами, которая не имеет никакого
отношения к операционным системам Windows компании Microsoft. Система
X Windows была разработана в Массачусетском технологическом институте
в 80-х гг. и принята большинством производителей рабочих станций UNIX
в качестве базовой оконной среды (иногда, правда, она поставляется с
существенными модификациями).
Эмуляторы X Windows, работающие в среде Microsoft Windows, реализуют
протокол XII. Сервер организует связь между клиентскими приложениями
(например, эмулятором терминала xterm) и рабочим столом Windows Как
только на компьютере активизируется сервер XI1, клиенты получают
Глово 26. Взоимодействие с Windows
813
26.4.
26 5.
0
возможность запускаться в среде UNIX и отображать данные на рабочем
столе. Х-приложения, функционирующие в этом режиме, могут сосущество-
вать на рабочем столе вместе с обычными приложениями Windows. Есть
эмуляторы, с помошью которых можно использовать оконный менеджер и 5
среды UNIX.
Существуют десятки Х-эмуляторов. Два из них. которые мы хотим
отметить, — это eXceed компании Hummingbird (www.hunimmgbird.com) и
SuperX компании Frontier Technologies (www.frontienech.com). SuperX —
именно тот эмулятор, которым Трент Хейн пользуется ежедневно. Этот
эмулятор вполне корректно производит операции вырезания и вставки между
X-приложениями и приложениями Windows, а его система подстановки
шрифтов чрезвычайно проста.
 (очтовые клиенты на персональных компьютерах
Первое, что хотят сделать пользователи, включив свой компьютер, — это
проверить электронную почту'. Обеспечение устойчивой электронной связи
важно для большинства организации. Причем это именно та область, где и
персональные компьютеры, и UNIX-серверы блестяще проявляют себя
Персональные почтовые клиенты, такие как Microsoft Outlook, Netscape
Messenger и Eudora компании Qualcomm, обладают великолепными возмож-
ностями и намного превосходят старые программы чтения почты в UNIX.
Они позволяют пользователям обмениваться обычными и зашифрованными
почтовыми сообщениями, посылать вложения и письма со специально
отформатированным ичи даже цветным текстом. Все это — важные инстру-
менты мира Internet; давно ушли в прошлое программа /usr/ucb/mail и другие
текстовые почтовые утилиты.
Организациям требуется предоставлять надежную почтовую связь сотням,
а то и тысячам пользователей. Это возможно только там. где в качестве
платформы выбрана UNIX. Данная операционная система обеспечивает
расширяемую, защищенную и конфигурируемую среду для приема и передачи
почтовых сообщений через internet. Сообщения могут храниться на UNIX-
сервере и быть доступными персональным почтовым клиентам с помошыо
протоколов 1МАР и POP. Эта система является лучшей в мире. К тому же
UNIX не восприимчива к вирусам Windows.
Более полная информация о протоколах IMAP и POP представлена в парагра-
фе 19.3.
Другое преимущество данного подхода, особенно в случае применения
протокола IMAP, заключается в том, что почта хранится на сервере. Если
какой-нибудь персональный компьютер сломался или вообще сгорел, это не
значит, что папки с почтой пользователя безвозвратно пропали Кроме того,
1МАР позволяет пользователю получить доступ к своей почте откуда угодно —
из дома, из Internet-кафе и тд.
Резервное копирование
на персональных компьютерах
Резервное копирование данных на персональных компьютерах может
стать весьма серьезной проблемой, особенно сейчас, когда емкость обычного
жесткого диска превышает 20 Гбайт. Имеется ряд подходов к решению этой
проблемы, включая использование мощных сетевых средств резервного
814
Чость III Розное
копирования, предлагаемых такими компаниями, как IBM и Seagate. Конечно,
всегда можно воспользоваться локальным накопителем на магнитной ленте.
И если есть деньги и терпение, то это именно та область, где коммерческие
продукты оказываются наиболее эффективными.
|^| О системах резервного копирования можно узнать в главе 10.
Но как быть тем, кто привык экономить деньги? Можно, конечно,
скопировать содержимое жесткого диска (всего или его части) на UNIX-сер-
вер, воспользовавшись для этой пели утилитой smbtar, включенной в пакет
Samba. Правда, данный подход весьма трудоемок, поэтому мы не можем
рекомендовать его читателям.
В подобной ситуации нам кажется, что наилучшее решение — вообще
не создавать резервную копию содержимого компьютера. В организациях, где
применяется такой подход, пользователей учат хранить все важные файлы
на совместно используемом сетевом диске. Это позволяет конфигурировать
все персональные компьютеры в пределах организации одинаково (имеются
в виду инсталлированные приложения, конфигурация рабочего стола и т.д.)
Если какой-нибудь компьютер выходит из строя, то другой взамен него может
быть загружен буквально за несколько минут. Опасно? Может быть. Но
ресурсы используются разумно? Да!
26.6.	Мультисистемноя загрузка
Слава богу, в мире еше не перевелись изобретатели! Многим хотелось
“добиться максимума от своего компьютера”, установив на нем несколько
операционных систем. Это стало возможным благодаря появлению средств
“мультисистемной” загрузки. Данный термин означает, что в процессе
начальной загрузки пользователь выбирает одну из нескольких операционных
систем. Популярной стала комбинация Linux с Windows, особенно среди
программистов, которым нужно быстро переключаться из одной среды в
другую. В некоторых случаях можно даже совместно использовать одни и те
же файловые системы во всех инсталлированных операционных системах.
О том, как настроить мулътисистемную загрузку, рассказывалось в па-
раграфе 2.2.
26.7.	Запуск приложений Windows в среде UNIX
Во многих версиях UNIX можно запускать приложения Windows, но не
все! Это делается разными методами, но все они обычно сводятся к созданию
“виртуальной машины", благодаря которой приложению кажется, будто оно
работает в Windows. Обычно эти виртуальные среды несколько нестабильны,
и далеко не все приложения хорошо функционируют в них.
* СТЬ Два заслуживающих внимания пакета, которые позволяют запускать
приложения Windows непосредственно в среде Red Hat Linux. Коммерческий
продукт VMware (www.vmware.com) сделает весь компьютер единой виртуаль-
ной машиной, где сможет функционировать несколько операционных систем
одновременно. Пакет Wine (www.winehq.com) реализует библиотеку Windows
API в среде Linux, позволяя запускать приложения, которые не имеют доступа
• Есть два продукта, которые могут помочь в данной ситуации: это Norton Ghost компании
Symantec и Drive Image Pro компании PowerQuest. При их использовании стандартный файл
образа диска либо хранится в сети, либо записывается на загрузочный компакт-диск.
Глово 26. Взоимодействие с Wincows
815
Ф0
ни к одному драйверу". Правда, на момент написания книги пакет Wine
рекламировался своими создателями как “система не для регулярного
использования, а для тех случаев, когда нужна помощь в устранении дефектов
в программном обеспечении”
Заслуживают внимания три пакета для Solaris. Наиболее интересным
является SunPC — коммерческий продукт компании Sun, включающий плату
SBus с Intel-совместимым процессором, предназначенным для интерпретации
инструкций ПК. Среди других приложений стоит упомянуть SoftWindows
компании FWB Software (www.fwb.com), полноценный эмулятор Windows, и
NTRIGUE компании Citrix (www.citrix.com), которому для работы требуется
отдельная Intel-система с Windows NT (эта программа позволяет пользовате-
лям запускать приложения Windows на рабочих станциях Solaris).
Sun бесплатно распространяет пакет StarOffice — аналог Microsoft Office
для Solaris и Linux. В пакет входят основные офисные утилиты, такие как
редактор электронных таблиц, текстовый редактор и простая СУБД. Эти
программы могут читать и записывать файлы в форматах Microsoft Word и
Microsoft Excel. Более подробную информацию о них можно найти по адресу
http://www.sun.com/products/scaroffice
26.8.	Советы i о аппаратным средствам
п<“осональных компьютеров
Одним из достоинств оборудования для персональных компьютеров
принято считать его невысокую стоимость. С другой стороны, как мы все
прекрасно понимаем, за что уплатил — то и получил. Поэтому даже при
покупке высококлассного устройства следует учитывать целый ряд факторов.
Во-первых, если вы хотите оснастить свой компьютер не Windows, а
какой-либо иной операционной системой, выясните, какие устройства в ней
поддерживаются. Производители оборудования обычно снабжают все свои
новые разработки Windows-драйверами, но в UNIX они бесполезны. Неко-
торые поставщики “исправились” и стали предлагать драйверы для Linux.
Во-вторых, помните, что производительность компьютера зависит от
многих факторов. В настоящее время тактовая частота процессора не является
узким местом. Недостаточная производительность подсистемы ввода-вывода
приводит к снижению быстродействия всей системы. Выбирая устройство,
ориентируйтесь на самую высокую скорость передачи данных и самую
быструю шину Будьте особо внимательны при покупке таких устройств, как
дисковые контроллеры. Убедитесь в том. что они разработаны для действи-
тельно многопользовательской операционной системы и способны обрабаты-
вать несколько “запросов” одновременно.
Еще один источник проблем составляют недорогие модемы, которые
требуют наличия на компьютере программного обеспечения, выполняющего
обработку сигналов. Маловероятно, что это программное обеспечение когда-
нибудь будет перенесено в UNIX, поэтому нужно выбирать модемы, имеющие
собственный сигнальный процессор.
Пакет Wine доступен также во FreeBSD.
8.6
Чость III Розное
Стратегия и политика
< администрирования
В этой главе рассматриваются некоторые нетехнические вопросы, которые
часто приходится решать системному администратору. Помимо обсуждения
различных правовых и политических проблем, мы поговорим о личных
взаимоотношениях администратора с окружающими и политических интри-
гах, ведущихся иногда на UNIX-узлах.
И ОС UNIX, и компьютерные сети довольно молоды — им всего
каких-то 25 лет, но, несмотря на это, при их использовании возникают
социальные проблемы, существующие уже тысячи лет. Во многих случаях
правовые и социальные институты “внешнего” мира слишком медленно
приспосабливаются к “внутреннему” миру новых технологий.
Internet в настоящее время оказывает значительное влияние на методы
работы некоторых ключевых составляющих экономики. Речь идет, в частно-
сти, о сферах распространения информации, телекоммуникации, индустрии
развлечений, почтовом обслуживании, а также о посреднической деятельности
(туристических агентствах, торговле книгами и музыкой, биржевых конторах
и т.д.). Причем во многих случаях наши технологические и финансовые
возможности, кажется, далеко превосходят уровень развития необходимой
для их поддержки правовой инфраструктуры.
Например, существуют четкие законы и конвенции по обеспечению
конфиденциальности и правилам использования обычной почты. А как же
электронная почта? Она конфиденциальна, или владелец диска, на котором
хранится почта, имеет право ее читать? Если компьютер пересылает
клеветническое или оскорбительное сообщение, несет ли владелец компью-
тера ответственность за содержимое этого сообщения?
Понятие интеллектуальной собственности становится все более расплыв-
чатым. Понятно, что вы можете позволить любому прослушать купленный
вами компакт-диск и даже дать его друзьям попользоваться. Вы также можете
Гпово 27. Стро^егич и пош-шю одмини<-трировопия
817
переписать музыку на компьютер и проигрывать ее с помощью компьютера.
А как быть, если вы захотите преобразовать содержимое компакт-диска и
сделать его доступным через Internet? Или позволите слушать его таким
образом своим друзьям?
Крайностью стало появление таких служб, как Napster (napster.com).
которые обеспечивали бесплатное распространение музыки через Internet.
Napster позволяла сделать доступной через сервер Internet любую пользова-
тельскую коллекцию музыки в цифровом формате. С точки зрения компью-
терных технологий Napster является весьма интересной системой, так как.
скорее всего, это самое большое распределенное приложение типа кпиент/сер-
вер. Однако она породила множество проблем.
Осенью 1999 года служба Napster стала популярна в студенческих
кампусах и быстро вытеснила Internet-афиши. Некоторые провайдеры стали
угрожать отключением клиентам, которые применяли Napster. Представители
музыкальной индустрии стали преследовать Napster в судебном порядке за
нарушение авторских прав. Количество проблем вокруг Napster росло, как
снежный ком, было открыто много судебных тяжб, в которые вовлекались
самые различные стороны. Однако мы сомневаемся, что разрешение этих
проблем внесет ясность по поводу главных причин, которые их вызвали.
Как и можно ожидать, при такой неопределенности многие организации
(не говоря уже о правительствах) нуждаются в документах, четко регламен-
тирующих решение данных вопросов.
27.1.	Правила и методики
Работая над этой главой, мы беседовали с видными деятелями в области
системного администрирования, зашиты компьютеров, стандартизации н
компьютерного права. Как ни странно, все они считают, что документально
оформленные, доведенные до сведения всех сотрудников правила совершенно
необходимы для нормального функционирования любой организации.
Правила и методики должны быть соответствующим образом оформлены,
утверждены руководством и проверены юристами. Лучше это сделать до того,
как возникнет необходимость обращения к подобным документам для
решения какой-нибудь острой проблемы. Желательно, чтобы в каждой
организации были такие документы:
•	правила административного обслуживания;
•	перечень прав и обязанностей пользователей;
•	правила для администраторов (пользователей с особыми привилегиями);
• правила создания “гостевых” учетных записей.
Для систематизации практического опыта можно использовать различные
методики, оформленные в виде контрольных списков и инструкций. Эти
документы полезны как для новых администраторов, так и для ветеранов.
Вот некоторые преимущества, получаемые при использовании стандартных
методик:
•	рутинные задачи всегда выполняются одинаково,
•	уменьшается вероятность появления ошибок;
•	работа по инструкциям выполняется администратором гораздо быстрее;
•	изменения самодокументируются;
818
Чость III. Розное
•	корректность действий администратора можно соизмерять с неким
эталоном.
Сегодня в корпоративной среде UNIX-системы заменили большие
мэйнфреймы. и на них возлагается основная вычислительная нагрузка.
В UNIX-системах почти все стандартные задачи документированы в форме
контрольных списков и инструкций (называемых "run books" или ‘'checklists"),
доступных в оперативном режиме или хранящихся в печатном виде.
Написанием и поддержкой этих инструкций занимается дополнительная
группа системных администраторов (не входящая в состав основного штата
системных администраторов, обслуживающих технику и использующих эти
инструкции). Тем не менее, такая организация и стандартизация в конце
концов окупаются.
Следует рассмотреть вопрос о разработке методик:
•	подключения компьютера;
•	подключения пользователя;
•	настройки и конфигурирования компьютера:
•	установки библиотеки TCP-оболочек на компьютер;
•	настройки резервного копирования для нового компьютера;
•	защиты нового компьютера:
•	перезапуска сложного программного обеспечения;
•	восстановления Web-серверов, которые не отвечают на запросы или не
предоставляют данных;
•	разгрузки очереди и перезагрузки принтера;
•	модернизации операционной системы;
•	инсталляции пакета прикладных программ;
•	инсталляции программного обеспечения по сети;
•	модернизации наиболее важных программ (sendmail, gee, named и т.д );
•	резервного копирования и восстановления файлов;
•	выполнение аварийной остановки системы (всех компьютеров, всех,
кроме наиболее важных компьютеров, и т.д.).
Часто проблему можно отнести и к правилам, и к методикам, например:
• Кто может иметь учетную запись?
•	Что произойдет, если этот пользователь уволится?
Такие вопросы следует регламентировать особенно тщательно, чтобы не
стать жертвой известной уловки четырехлетних детей: "Мама не разрешила,
надо спросить у папы!’’ Ответы на вопрос ‘'что если?" обычно составляют
политику компании, а ответы на вопрос "как?" представляют собой
процедурную часть ее реализации.
Некоторые положения инструкций диктуются особенностями програм-
много обеспечения, с которым вы работаете, либо правилами, принятыми в
тех или иных сторонних группах, например, у поставщиков услуг Internet.
Соблюдение некоторых положений является обязательным, особенно если вы
должны обеспечить секретность данных пользователей. Такие вещи мы
называем “безоговорочными правилами".
В частности, мы считаем, что управление lnlemei-адресами, именами
компьютеров, идентификаторами пользователей и групп, регистрационными
именами должно осуществляться единообразно для всех компьютеров орга-
низации. Для больших структур (в частности, транс национальных корпораций)
Глово 27. Стратегия и политика администрирования
819
такой подход реализовать непросто, но если вам удастся это сделать,
управление значительно упростится. Средства, которые облегчают управление
хостами и пользовательскими учетными записями, можно получить по сети.
Имеющиеся у нас старые версии addiiost и adduser не являются хорошими
примерами, однако они еще применяются и, если вы не найдете ничего
лучшего, возьмите эти программы на узле ftp.xor.com.
Мы убеждены, что ни в коем случае нельзя предоставлять нескольким
пользователям одно и то же регистрационное имя. Это правило гораздо легче
внедрить, если сразу же устранить соблазн коллективного использования
имени. Хорошая альтернатива несанкционированному применению одного и
того же имени — “гостевой” компьютер с либеральными правилами создания
учетных записей. Однако сейчас, когда некоторые службы (AOL, Hotmail,
Yahoo и др.) предоставляют адреса электронной почты и существует доступ
к Internet из библиотек, Intemet-кафе и пр., мы не считаем данный метод
необходимым.
Многие вопросы регламента относятся не только к вашей локальной
административной группе. Это, например:
•	нарушения системы защиты:
•	управление экспортом в NFS;
•	критерии выбора паролей;
•	удаление регистрационных имен;
•	зашита материалов знаком авторского права (например, для файлов MP3
и DVD);
•	программное пиратство.
Обеспечение связи между’ административными группами в крупных
организациях — один из важнейших факторов предотвращения проблем и
создания атмосферы доверия и сотрудничества. Некоторые группы админи-
страторов применяют для общения такие средства, как MUD и МОО.
Конечно, они могут показаться слишком “чатистыми”. однако при разумном
использовании, безусловно, будут полезны, особенно если часть персонала
работает дома.
Правила безопасности
Что именно вы хотите защитить? Данные? Аппаратное обеспечение? Или
речь идет о способности быстро восстанавливаться после катастрофы? При
проектировании политики безопасности для сети организации вы должны
найти разумный баланс между:
•	предлагаемыми услугами и обеспечиваемой безопасностью (больше сер-
висов = меньше безопасность);
•	простотой и удобством использования и безопасностью (безопасность =
1/удобство);
•	стоимостью средств безопасности и убытками (риском) от ее нарушения.
В 1997 г. одна из подгрупп IETF выпустила 75-страничный документ,
озаглавленный Site Security Handbook (Справочник по защите систем) и
оформленный как RFC2196. В нем содержатся рекомендации системным
администраторам по различным аспектам зашиты, правилам использования
и методикам работы. Рецепта обеспечения безопасности Internet-узлов здесь
нет, но есть другая, не менее ценная, информация.
82С
Чость III. Розное
Документ RFC2I96 предлагает включать в правила следующие разделы:
• Рекомендации по закупке оборудования и программного обеспечения. Участие
системных администраторов в выборе оборудования и программного
обеспечения может оказать большую пользу, так как часто они знают о
его недостатках и ограничениях то, чего не афишируют продавцы и
производители.
•	Политика секретности. Устанавливает степень контроля нал почтой и
действиями пользователей, а также политику размещения пользователь-
ских файлов.
•	Политика доступа. Определяет, кто может иметь доступ в систему, что
можно делать в рамках этих прав доступа, какое программное и
аппаратное обеспечение можно устанавливать и пр. Данный документ
должен включать те же меры предосторожности относительно авториза-
ции доступа и степени контроля, что и политика секретности.
•	Политика учетных записей. Содержит описание прав и обязанностей
пользователей и системных администраторов.
•	Политика аутентификации. Устанавливает правила применения паролей
и порядок удаленного доступа.
•	Политика доступности. Определяет, в какое время система должна быть
доступна, содержит расписание обслуживающих мероприятий, перечень
действий при возникновении проблем, а также инструкции по докумен-
тированию проблем и оповещению о них администраторов и ориенти-
ровочное время их устранения.
•	Политика управления. Устанавливает правила общения с внешним миром
и порядок доступа для приглашенных из других организаций специали-
стов.
Примечательно, что из документа RFC2196 исключена часть о политике
аутентификации, определяющая, кто может создавать новые регистрационные
имена и расширять привилегии. Предыдущая версия документа Site Security
Handbook (регистрационный номер RFC 1244) содержала список конкретных
политических задач и вопросов, требующих регламентирования, а не просто
описание типов политик, что, вероятно, было более полезно системному
администратору. Более новый RFC включает рекомендации для каждого типа
службы, которая может работать на компьютере, описывает круг возможных
проблем, связанных с этими службами, и методы их решения.
Независимо от сути принятых в вашей компании правил, они должны
быть четко сформулированы, документально оформлены, доведены до
сведения всех пользователей и системных администраторов и подписаны ими.
Этому надо следовать, даже когда пользователи являются клиентами, которые
платят за обслуживание. Ошибки в применении политики ослабляют ее
юридическую силу и законность.
Правила для пользователей
На факультете компьютерных наук Университета Колорадо используется
специальная программа, которая предлагает каждому новому пользователю
прочитать и подписать соглашение о правилах поведения в системе и
предъявляемых к нему требованиях. Только подписав это соглашение,
пользователь получает учетную запись и доступ к системе. Такая схема доступа
очень удобна, она экономит время и позволяет избежать многих проблем,
но прежде чем применить ее в своей организации, посоветуйтесь с юристом.
Глово 27. Стротегия и политике одминистрировония
821
В правилах для пользователей необходимо регламентировать такие
вопросы:
•	использование учетных записей совместно с друзьями и родственниками.
•	выполнение программ дешифровки паролей для расшифровки локального
файла passwd’;
•	выполнение программ дешифровки паролей для расшифровки файлов
passwd других систем;
•	нарушение нормального процесса обслуживания;
•	проникновение в чужие учетные записи;
•	неправильное использование электронной почты;
•	просмотр файлов других пользователей (есть ли возможность чтения''
записи? одобряется ли?);
•	публикации в Usenet (запрещены? с оговорками? разрешены?);
•	импорт программ из Internet (запрещен? разрешен? разрешен с провер-
кой?);
•	использование системных ресурсов (принтеров, дисков, модемов, процес-
сора);
•	копирование лицензионного программного обеспечения;
•	выдача разрешений на копирование лицензионного программного обес-
печения другим лицам;
•	копирование защищенных авторскими правами материалов (музыки,
фильмов и пр.);
•	всевозможная незаконная деятельность: мошенничество, клевета и др.;
•	вовлечение в деятельность, которая является запрещенной (например,
порнография).
Два примера соглашений вы найдете на нашем сервере www.admin.com.
Одно предназначено для студентов первых курсов, у которых наличие
регистрационного имени является привилегией, а не правилом. Оно является
более жестким. Второй документ предназначен для преподавателей, сотруд-
ников и студентов старших курсов.
В качестве примера простого и краткого соглашения мы приводим
документ, который требуется подписать для доступа к компьютерам факуль-
тета компьютерных наук Университета Мельбурна:
Я. нижеподписавшийся, настоящим объявляю. что буду придерживаться
приведенных ниже правил:
•	Я буду использовать возможности компьютеров и сети факультета
исключительно для учебных целей, относящихся к моему обучению
компьютерным дисциплинам.
•	Я знаю, что факультет предоставляет регистрационное имя исключительно
для применения его получателем Поэтому я не буду способствовать
использованию моей учетной записи и файлов другими лицами и
сообщать свой пароль другим лицам.
Например, программы crack, которая является эффективным средством распознавания
паролей.
822
Чог'Ь III Розное
•	Я не буду осуществлять доступ или попытку доступа ни к одному
компьютеру, регистрационной записи, сети или файлу без соответствую-
щего и явного разрешений. Такой доступ является незаконным и
противоречит университетским правилам. Если мне станет известно, что
такой доступ имел место, я немедленно проинформирую об этом
руководство факультета.
•	Я знаю, что некоторые программы и данные, находящиеся в файловой
системе, могут быть защищены законом об авторских правах и другими
законами или лицензионными либо другими соглашениями. Я не буду
нарушать накладываемых ими ограничений.
•	Я не буду использовать университетские ресурсы для получения, разра-
ботки, запуска и распространения нелицензионного программного обес-
печения.
•	Я обязуюсь сохранять конфиденциальность любых полученных мною от
университета сведений о программном обеспечении (включая методы и
принципы его использования), лицензированном для применения на
компьютерах ун!гверситета, и тем самым обезопасить университет от
претензий любого рода, связанных с разглашением этой информации.
•	Я обязуюсь проявлять предельную честность и порядочность во всех
вопросах, связанных с использованием компьютерных и сетевых возмож-
ностей факультета. Гарантирую, что буду избегать любых действий,
связанных с использованием компьютерных и сетевых возможностей
университета, которые могут повредить репутации факультета или уни-
верситета.
Я понимаю, что должен придерживаться Правил 8.1.R7 Университета
Мельбурна (изложены в Дневнике студента), которые также определяют и
регулируют порядок использования вычислительных средств университета.
Я понимаю, что действия, противоречащие изложенным выше принци-
пам. повлекут за собой жесткие взыскания, включая отказ в изучении темы
или предмета, временный запрет нли лишение доступа к университетским
вычислительным средствам, временное или полное исключение из универ-
ситета, штраф и/или другие действия, предусмотренные Crimes (Computer)
Act* 1988 г.
Обратите особое внимание на неоднозначные слова о честности, поря-
дочности и необходимости беречь репутацию университета. Подобные
требования общего характера помогают охватить вопросы, которые трудно
описать строгими детерминированными правилами. И хотя юридическая сила
таких требовании невелика, все же полезно их включать во внутренние
правила компании.
Правила для администраторов
В правилах для администраторов (и других лни с особым статусом)
должны быть сформулированы руководящие принципы использования пре-
доставленных привилегий и соблюдения секретности пользовательских дан-
ных. Трудно, конечно, ответить на жалобу пользователя о том. что почта не
работает, не видя “отскочивших” сообщений, но копии заголовка в боль-
шинстве случаев хватает для определения сути проблемы и ее устранения.
Подробно программа sudo рассматривается в параграфе 3.4.
Здесь речь идет об Австралии. Однако аналогичные законы, касаюшиеся компьютеров и
программного обеспечения, существуют и в США.
Глово 27. Стротегмя и политике одминистрировония
Ь23
Если для доступа в систему с правами root применяется программа типа
sudo, администраторам следует выбирать надежные пароли и не делить
учетные записи с кем попало. Регулярно проверяйте пароли системных
администраторов при помощи программы crack. Кроме того, важно, чтобы
они не использовали команду sudo tcsh. поскольку этим нарушается
способность sudo регистрировать события и выполняемые команды.
Некоторые системные администраторы злоупотребляют своими возмож-
ностями. Таким сотрудникам лучше предложить другие должности
В некоторых организациях обладание паролем root является символом
занимаемого положения, возможно, даже более ценным, чем ключ от
персонального туалета. Иногда этот пароль есть у инженеров, которым он
не нужен или не должен выдаваться. Мы знаем одну фирму, где всем
инженерам предложили пароль привилегированного пользователя при усло-
вии, что его обладатели будут носить пейджер и в случае необходимости
помогать другим. Заявки потекли рекой.
Есть еше один успешно проверенный нами метод: поместить пароль root
в конверт и спрятать его в известном месте. Администраторы обычно
пользуются в своей работе программой sudo; если по какой-либо причине
им понадобится пароль root, они вскроют конверт После этого пароль root
меняется и прячется в новый конверт. Конечно, отпарить конверт ничего нс
стоит, но доступ к тому месту, где он хранится, имеют только администра-
торы
Правила и методики для экстренных случаев
Заблаговременно решите вопрос о том, кто будет руководить работой в
случае нарушения защиты. Заранее определите субординацию; имена и
телефоны должностных лиц держите вне системы. Может оказаться так. что
лучшим руководителем в подобной ситуации будет администратор “из
окопов”, а не директор вычислительного центра (обычно он не подходит для
этой роли).
Для общения и получения документов мы обычно пользуемся сетью.
В случае инцидента с зашитой доступ к сетевым средствам может быть
затруднен или вообще окажется невозможным. Держите сведения о своих
связях и методиках вне сети. Не забывайте о том, где можно взять последние
дамп-ленты и какие команды нужно использовать для восстановления без
обращения к файлу /etc/dumpdates. Избегайте расспросов со стороны
представителей средств массовой информации, особенно если инцидент
получает развитие.
У хакеров сейчас в моде взламывать Web-узлы. Для системных админи-
страторов компании, предоставляющей услуги Web-хостинга, такой взлом —
очень большая неприятность. Тут же начинаются телефонные звонки от
обеспокоенных клиентов, СМИ и от партнеров компании, увидевших новость
по CNN. Кто будет отвечать на все эти звонки? Что он скажет? Кто возьмет
на себя ответственность за исправление ситуации? Какими будут обязанности
каждого из членов персонала? Если ваш бизнес на виду у широкой
общественности, все это нужно очень тщательно продумать, и возможно,
даже провести учения.
О том. что делать в случае нарушения защиты, подробно рассказывалось
в главе 21.
824
Чость 111. Розное
Планирование на случай аварий
Действия персонала в случае аварии нужно планировать заранее. Худшие
из аварий почему-то случаются на ноутбуках руководителей, и именно они
поднимают больше всего шума. В этом разделе рассматриваются различные
виды аварий и рассказывается о том, какие данные понадобятся для
успешного восстановления работоспособности системы и каковы важнейшие
элементы плана аварийных мероприятий.
Существует несколько типов аварий и непредвиденных ситуаций:
•	нарушение защиты (60% нарушений защиты обычно происходит внутри
организации);
•	внешние воздействия на технику: скачки напряжения и отключение
питания, поломки кондиционеров и вентиляторов, потопы, ураганы,
землетрясения, метеоры, вторжения пришельцев из космоса:
•	человеческие ошибки: удаленные или поврежденные файлы и базы
данных, потерянная конфигурационная информация (возможно, ваша
система зеркалирования данных работает с такой скоростью, что ошибка
успевает распространится в ней до того, как вы сообразите, что произошло?);
•	неожиданный выход из строя аппаратного обеспечения; отказ сервера,
поломка жесткого диска, нарушение работы сети.
В любой из этих ситуаций вам необходим доступ к копиям важной
информации, хранящейся в компьютерах и на внешних носителях. Для
оперативного доступа к таким копиям по возможности нужно использовать
независимый компьютер с богатым набором всевозможных утилит и инстру-
ментальных средств, специально настроенный и оборудованный для использо-
вания системными администраторами. На нем должен работать собственный
сервер имен, должен быть полный файл /elc/hosts, все необходимые для его
работы файлы должны храниться на нем, а не где-то в сети, к нему должен
быть непосредственно подключен принтер и т.д. Вот какие данные следует
хранить на резервной машине и иметь под рукой в распечатанном виде:
• план действий персонала в случае аварии, в котором должно быть указано,
кого и когда оповещать и что говорить;
•	номера телефонов обслуживающих организаций и клиентов;
•	важнейшие номера телефонов (персонала, полиции, пожарной службы,
босса, агентства по трудоустройству);
•	сведения об аппаратном обеспечении и конфигурации программного
обеспечения: таблицы разделов дисков, аппаратные установки компью-
теров, номера прерываний, номера каналов DMA и т.п.
•	ленты с резервными копиями и расписание резервного копирования,
использовавшееся для их создания;
•	карты сети;
•	серийные номера программного обеспечения, лицензионные данные и
пароли;
•	контактная информация производителей или продавцов дисков, которые
должны быть восстановлены немедленно.
При составлении плана аварийных мероприятий обычно предполагается,
что административный персонал будет на месте и в состоянии справиться с
ситуацией. Однако в реальности люди болеют, переходят на другие должности,
уходят в отпуск и увольняются. Поэтому стоит заранее продумать, где можно
Глово 27. Стротегия и политике одминистрировония
825
быстро найти дополнительный персонал. (Если ваша система не слишком
устойчива, а персонал неопытен, то недостаточное количество администра-
торов уже само по себе рискованно.)
Одним из решений может быть договор с местной консультационной
компанией или университетом, где всегда имеются свободные системные
администраторы. Но самое главное — обеспечьте надежную работ)' своей
системы, наймите достаточно администраторов и не требуйте, чтобы они
работали по 12 часов в сутки.
План аварийных мероприятий лучше проверить заранее. Если вы
основательно готовились к выживанию в случае аварий, ожидавшихся
1 января 2000 года, возможно, стоит оставить кое-что из запасов — например,
фонари с аккумуляторами. (Есть очень удобные — они вставляются розетку
и зажигаются, когда отключается электричество, так что их сразу легко найти.)
Проверьте генераторы и источники бесперебойного питания. Убедитесь,
что все важные устройства подключены к источникам бесперебойного
питания (ИБП), их батареи в порядке и механизм включения питания
работает. Для проверки ИБП достаточно просто вынуть вилку из розетки, а
для того, чтобы проверить, все ли важное оборудование к ним подключено,
нужно отключить питание в здании или в комнате, и убедиться, что все
работает.
Как правило, электричество отключается ненадолго, но на всякий случай
батареи должны обеспечивать два часа работы, чтобы было время правильно
выключить технику. Некоторые ИБП оборудованы последовательными пор-
тами или интерфейсом Ethernet, позволяюшим отключать не самые важные
машины через пять минут после отключения питания (тайм-аут настраива-
ется).
Даже из краткого отключения питания можно извлечь некоторую
пользу — например, добавить на сервер еше один диск или выполнить еше
какую-то пятиминутную работу', которую вы давно запланировали Некоторые
неудобства будут приняты как нечто само собой разумеющееся. Люди обычно
спокойнее воспринимают дополнительную пятиминутную задержку после
отключения электричества, чем пятиминутное плановое отключение системы,
о котором их оповестили за неделю. Если у вас есть старые машины,
которыми, как вам кажется, уже никто не пользуется, не включайте их, пока
кто-нибудь не пожалуется на их отсутствие. Иногда отсутствие такой машины
может оставаться незамеченным в течение нескольких недель.
Системы охлаждения часто оборудованы датчиками температуры со
средствами оповещения о ее повышении. Задайте такую верхнюю границу
температуры, чтобы после сигнала у вас оставалось время выключить технику,
прежде чем она перегреется и выйдет из строя. Держите в машинной комнате
обычный термометр или термометр, работающий от батареи. Не забывайте,
что. как только отключится питание, все ваши чудесные электронные
индикаторы окажутся бесполезными.
За дополнительной информацией о проблемах, связанных с влиянием внешних
факторов, обратитесь к параграфу 24.7.
В одной из крупных правительственных лабораторий США недавно
создали новый машинный зал и установили в нем кластер из 256 процессоров
Alpha, предназначенный для обработки больших научных моделей Все было
подключено к источникам бесперебойного питания и продумано до деталей.
И вот однажды недолгое отключение питания вывело всю систему из строя
на целых четыре часа. Почему? Оказалось, что компьютер, который управлял
826
Чость III Розное
0
27.2.
кондиционером, не был подключен к ИБП Он отключился и отключил
систему кондиционирования. Так что тестируйте системы как можно
тщательнее.
Непредвиденные обстоятельства
Провайдеры услуг Internet постоянно сливаются в более крупные
компании или приобретаются крупными компаниями. В результате наруша-
ются их тщательно разработанные планы поддержания избыточных подклю-
чений к Internet. Объединяясь, компании часто объединяют и свои сети.
Поэтому может оказаться, что имеющиеся у вас два независимых соединения
с Internet теперь выходят на общий оптоволоконный кабель.
Когда CNN или Sladshot объявляет, что ваш Web-узел отключен,
пользователи могут ринуться смотреть, как дела, и в результате трафик
возрастет настолько, что может разрушить то, что вы только что починили.
Если ваш Web-узел ие рассчитан на 25-процентное увеличение трафика,
подумайте о том, чтобы использовать простое программное обеспечение,
балансирующее нагрузку. Оно может просто направлять лишние обращения
на сервер, возвращающий одну и ту же страницу: “Извините, узел слишком
загружен и в данный момент мы не можем обработать ваш запрос”.
Используйте программу tripwire, чтобы согласовывать действия системных
администраторов, особенно если разные группы администраторов отвечают
за разные аспекты работы одной машины. Например, “заплаты” СУБД Oracle
и “заплаты” операционной системы могут конфликтовать друг с другом, и
поставившая одну из них группа администраторов может даже не подозревать,
что причиной проблемы являются действия второй группы. Сведения,
собранные программой tripwire, могут очень пригодиться и организации,
предоставляющей административные услуги, если ее специалистам нужно
восстановить систему клиента после неудачных действий его собственных
администраторов. Эта программа легко идентифицирует, что и когда изме-
нилось, и поможет доказать местным системным администраторам, что
именно их действия послужили причиной неполадок.
О программе tripwire рассказывается в параграфе 21.7.
Правовые аспекты
Федеральное правительство и некоторые штаты издали законы о престу-
плениях в области вычислительной техники. На федеральном уровне таких
законов несколько:
•	Федеральный закон о секретности связи;
•	Закон о компьютерном мошенничестве и компьютерных злоупотреблениях;
•	Закон о компьютерных кражах;
•	Закон об авторском праве “Digital Millennium Copyright Act”.
С началом нового тысячелетия перед системными администраторами,
сетевыми операторами и Web-узлами, предоставляющими услуги хостинга,
встали новые ответственные задачи: это и усиление защиты электронной
коммерции, и защита авторских прав, и зашита конфиденциальности.
Глово 27. Стротегия и политике одминистрировония
827
Ответственность
Системные администраторы обычно не отвечают за то. что пользователи
хранят иа машинах, которые они обслуживают. Провайдеры услуг Internet
чаще всего просто направляют всех, кто к ним подключается, к своим
клиентам. Вся ответственность за действия клиентов возлагается нв самих
клиентов, а не на провайдеров или организации, предоставляющие услуги
провайдерам. Целью такой политики является защита провайдеров от
ответственности за спам и прочие неприятности, такие как, например,
хранение пользователями на своих узлах детской порнографии. Узнайте,
каковы законы на этот счет в вашей стране.
Полезная юридическая информация имеется на узле www.mibh.net. Там
есть сведения о незаконных действиях, нарушениях интеллектуальной собст-
венности и нарушениях правил использования продуктов и услуг. Вы найдете
на этом узле список запрещенных действий, ограничений, описание процедур
регистрации жалоб и кое-что об ответственности.
Шифрование
Необходимость шифрования в сферах электронной коммерции и комму-
никации очевидна. Однако в некоторых странах шифрование запрещено
законом. Полиция и другие организации, охраняющие закон, не хотят, чтобы
они не могли расшифровать передаваемые гражданами данные.
В Соединенных Штатах законы, касающиеся шифрования, меняются
В прошлом запрещалось экспортировать серьезные технологии шифрования.
Поэтому компаниям приходилось разрабатывать по две версии программного
обеспечения: одну для локального рынка, а другую на экспорт. Очевидная
абсурдность этой политики (как будто больше нигде в мире не разработаны
технологии шифрования!) и явные требования электронной коммерции
заставили правительство изменить этот закон. Хотя некоторые ограничения
на экспорт по-прежнему существуют, ситуация в США уже значительно
улучшилась.
Еще один побочный эффект, вызванный устаревшим законом США,
заключается в том. что все программные проекты, связанные с шифрованием,
разрабатываются вне страны. IETF провела серьезную работу по'стандарти-
зации в области зашиты двусторонней коммуникации на уровне протоколов
(усилиями IPSEC), и производители начали разрабатывать системы на основе
этих стандартов. Аутентификационная часть пока еше привязана к конкретной
системе, однако шифрующее программное обеспечение уже устанавливается
отдельно. Такая архитектура, кроме прочего, обеспечивает большую гибкость
а разработке программного обеспечения для стран, где шифрование запре-
щено.
Защита авторских прав
Музыкальная индустрия и кинопроизводство оказались перед серьезным
фактом: на домашних компьютерах можно проигрывать музыку с компакт-
дисков и просматривать фильмы в формате DVD. С одной стороны, это
открывает новые возможности, а с другой, ставит множество проблем,
особенно с распространением таких служб, как Napster.
Содержимое диска в формате DVD шифруется по технологии, называемой
CSS (Content Scrambling System). Это делается для того, чтобы диски могли
проигрываться только лицензированными и одобренными плеерами Эти
8: !8
Чость III. Розное
плееры, как и лицензированное программное обеспечение для проигрывания,
имеют ключ для раскодирования дисков.
И вот один норвежский студент и еще пара неизвестных европейских
хакеров проанализировали процесс шифрования CSS и поместили в Web
программу, названную DeCSS. Эта программа не обходит схему шифрования
DVD. Она просто использует ключ законного плеера Windows для декоди-
рования потока данных DVD и сохраняет расшифрованный поток на диске.
Этого студента судят в Норвегии, a Motion Picture Association of America
и DVD Copy Control Association судятся с множеством дистрибьюторов
программного обеспечения DeCSS. Их обвиняют не в краже материалов,
защищенных авторским правом, а в распространении коммерческой тайны
и “нарушении защиты от копирования”, что запрещено законом Соединенных
Штатов “Digital Millennium Copyright Act", изданным в 1998 году.
Поскольку на этих судебных процессах обсуждаются многие проблемные
вопросы компьютерного законодательства, общественность и специализиро-
ванные юридические организации следят за ними с большим интересом.
За информацией на эту тему можно обратиться по адресу www.cssfaq.org.
Компания CyberPatrol разрабатывает программное обеспечение для фильт-
рации данных, получаемых из Internet Религиозные организации распростра-
няют это программное обеспечение в семьях, где имеются дети, в школах и
библиотеках, чтобы защитить детей от того, что им видеть не нужно.
Компания A Canadian and a Swede разработала программу cphack, позволяю-
щую расшифровывать списки блокировки, создаваемые программным обес-
печением CyberPatroi, чтобы узнать, какие Web-узлы заблокированы, каков
уровень ошибок и какие невидимые программы присутствуют в системе. Ее
сотрудники сообщили, что все, кто критиковал программное обеспечение
CyberPatrol, заблокированы по всем категориям.
Мэттел, которому принадлежит компания CyberPatrol, подал в суд на
авторов этой программы, утверждая, что лицензия CyberPatrol запрещает
инженерный анализ программного обеспечения компании. Мэттел получил
предварительное судебное заключение, запрещаюшее распространение про-
граммного обеспечения, но, к сожалению, судебный процесс так и не начался,
поскольку дело было улажено. Авторы программы cphack продали ее Мэттелу
за 1 доллар и согласились выполнить это постановление. Похоже, что авторы
отступили, и Мэттел пытается доказать свои права на программу, выпушен-
ную как общедоступное программное обеспечение (т.е. с лицензией GNU
Public License).
Мэттел собирается использовать свое новоприобретенное право интел-
лектуальной собственности для того, чтобы запретить копирование программы
cphack через Internet (как будто это возможно!). Но поскольку эта программа
выпушена авторами с лицензией GPL, ее можно распространять безо всяких
ограничений, кто бы ни был владельцем авторского права. Раз уж программа
выпушена с лицензией GPL и все сделано в соответствии с законом, обратно
ее не вернешь.
Конфиденциальность
Обеспечение конфиденциальности всегда было задачей не из легких, а
уж с появлением Internet дело тут стало совсем плохо. Возьмем, к примеру,
недавний инцидент в Университете штата Мичиган. Медицинские карточки
студентов университета в один прекрасный день оказались опубликованными
в internet. К тому времени, как один из студентов заметил ’‘утечку”, они
находились там уже несколько месяцев.
Глово 27. Стротегия и политике одминистрировония
829
Еще один большой скандал произошел вокруг компании Double-
Click, net — рекламного агентства, создающего баннеры для Web-страниц.
Годами эта компания заверяла своих пользователей в их полной анонимности,
утверждая, что никто не сможет их обнаружить и идентифицировать. Недавно
DoubleClick приобрела компанию, выполняющую поиск и анализ данных и
начала собирать информацию о пользователях, посещающих Web-страницы
с ее баннерами Конечно, как только об этом стало известно, поднялся шум
и компании пришлось закрыть проект и нанять пару опытных в таких делах
юристов.
Но афера компании DoubieClick — чепуха по сравнению с той угрозой
конфиденциальности, которую представляют наши провайдеры услуг Internet
в сочетании с действиями компании, называемой Predictive Networks. Как
утверждается в "PRIVACY Forum Digest", компания Predictive с помощью
провайдеров планирует наблюдать за вашей работой в сети и собирать
информацию о посещаемых вами URL, ключевых словах, вводимых вами в
программах поиска ресурсов, и т.п. На основе этой информации она будет
формировать вашу цифровую “подпись" и пользовательский профиль и
использовать его для того, чтобы подбирать Iniernet-ресурсы и рекламу
персонально для вас.
Predictive утверждает, что эта информация будет "анонимной" и вы
можете доверять всем, кто вовлечен в процесс ее сбора1 сотрудникам
компании Predictive, сотрудникам своего Internet-провайдера, тем. кто раз-
мешает рекламу и ресурсы. — в обшем. чуть ли не всему миру. Вы можете
запросить копию своей цифровой подписи, но за это придется «платить
Можно также отказаться от использования этого "сервиса'’, но тогда
подключение к Internet будет стоить вам дороже или провайдер даже вовсе
расторгнет с вами договор. На момент написания этой книги на Web-узле
Predictive (www.predictivenetworks.com) не было никаких сведений о политике
защиты конфиденциальности и вообще было мало информации о том. чем
они на самом деле занимаются. Статья из “PRIVACY Forum Digest" (V09,
#13, www.vonex.com) содержит больше подробностей об их планах и позиции
в отношении защиты пользователей Internet
Внедрение в жизнь политики администрирования
Файлы регистрации у вас лично не оставят и тени сомнения относительно
того, кто именно и что плохого сделал, однако для суда это — все равно
что доказательство, основанное на слухах. Используйте для зашиты офици-
ально заверенные "бумажные" документы, ибо документы, представленные
в электронной форме, в суде могут не возыметь действия. Некоторую пользу
могут принести штампы времени в файлах регистрации. однако только в том
случае, если на компьютере работает Network Time Protocol (NTP). синхро-
низирующий его часы с реальным временем.
А вот правила безопасности могут помочь возбудить дело о злоупотреб-
лениях. В эти правила следует включать такое положение:
Unauthorized use of University computing systems may involve not only transgression
of University policy but also a violation of state and federal laws. Unauthorized
use is a crime and may involve criminal and civil penalties; it will be prosecuted
to the full extent of the law.
(Несанкционированное использование компьютерных систем универси-
тета связано с нарушением не только университетских правил, но и
330
Чость III Розное
законов штата и государства. Несанкционированное использование яв-
ляется преступлением, влечет за собой уголовную и гражданскую
ответственность и подлежит наказанию, предусмотренному законодатель-
ством.)
Рекомендуем помещать в файл /etc/motd (сообщение дня) предупреждение
о действующих у вас правилах. Наше выглядит так:
Your keyboard input may be monitored in the event of a real or perceived security
incident.
(В случае реального или предполагаемого инцидента с системой защиты
вводимая вами с клавиатуры информация будет контролироваться.)
Для некоторых типов соединений сообщение дня не отображается
(например, во время сеанса ftp). Пользователи могут также воспрепятствовать
выводу этого сообщения на экран, создав в своих начальных каталогах файл
.hushlogin. Можно сделать так, чтобы пользователи прочли это уведомление
хотя бы раз; для этого нужно включить его в файлы запуска, выдаваемые
новым пользователям.
Обязательно укажите, что сам факт использования учетных записей
пользователей равносилен согласию соблюдать установленные правила.
Объясните, где можно получить экземпляры правил, и поместите основные
документы на соответствующей доске объявлений. Укажите особые меры на
случай их несоблюдения: удаление учетной записи, изъятие миллиона
долларов со счета в швейцарском банке, лишение родительских прав и т.д.
Предположим, с вашего узла в телеконференцию отправлено какое-ни-
будь нехорошее сообщение. Если вы работаете в CompuServe (сейчас это
часть AOL), проблем не избежать. В судебном деле Кабби против CompuServe
рассматривался случай публикации некоего клеветнического сообщения
Судья постановил, что сама CompuServe невиновна, а ведущего телеконфе-
ренции, в которой это сообщение было опубликовано, обвинил в халатности
Мораль: чем больше вы пытаетесь контролировать информацию, тем большую
ответственность на себя берете.
Этот принцип прекрасно иллюстрируется историей бизнеса, которым
занимался в Техасе один изобретательный студент по фамилии Чизер. Он
написал сценарии на языке Perl, просматривающие группы новостей Usenet,
собирал с их помощью непристойные картинки и публиковал их на
собственном Web-узле. Он брал с подписчиков по 12 долларов в месяц и
зарабатывал на этом огромные деньги.
Чизер пытался проявить ответственность и не подписывался на группы
новостей, где могла быть детская порнография. Однако он имел дело с
некоторыми группами новостей, материалы которых были на грани незакон-
ных. Этот просчет, а также то. что он выбрал для своего бизнеса один из
консервативных округов штата Техас, привели к тому, что его деятельность
вскоре была прекращена.
Получив анонимное сообщение (вероятно, от конкурента), полиция
конфисковала его компьютеры. Естественно, они нашли снимок детской
порнографии, случайно попавший из “безопасной” группы новостей. И хотя
дело не дошло до суда, из соглашения о принятии вины обвиняемым было
ясно, что судья считает Чизера виновным не в создании узла, а в том, что
он плохо отбирал материалы. Так что, если бы Чизер не отбирал их вовсе,
по закону все было бы в порядке.
Глобо 27 Стротегия и политике одминистрировония
831
Безопаснее всего ситуация, когда ваша организация, являясь подписчиком
всех телеконференций, не подвергает цензуре их статьи и не сокрашает
иерархию телеконференций на основании их содержания. Другое дело, когда
для сокрашения появляются основания технического характера (например,
нет места на диске). Если иерархию телеконференций нужно сократить,
сделайте это ближе к вершине дерева. Легче оправдать отказ от всей категории
“alt”, чем объяснить, зачем вы удалили alt.sex.fetish.feet и оставили alt.sex.bes-
tiality .hamsters.
За информацией о группах новостей Usenet обратитесь к параграфу 22.7.
Этот принцип распространяется и на другие отношения с внешним
миром. С юридической точки зрения вывод однозначен: чем больше вы
контролируете использование Internet вашими пользователями, тем большую
ответственность можете понести за их действия и публикации. Если вы знаете
о противоправной, подсудной деятельности, закон обязывает вас расследовать
ее и доложить о результатах куда следует.
Вот по этой причине некоторые компании ограничивают данные, которые
они вносят в журналы доступа на своих Web-узлах, сокращают время хранения
журналов, и не все их данные записывают в архивы и резервные копии. Для
реализации подобной политики существует даже специальное программное
обеспечение (например, Squid web cache), определяющее уровень протоколи-
рования доступа, что позволяет системным администраторам разрешать
возникающие проблемы и при этом не нарушать конфиденциальности
действий пользователей.
Системные администраторы должны знать правила, действующие во всех
подразделениях организации, и обеспечивать их неукоснительное соблюдение
При этом учтите, что не имеющие законной силы и противоречивые
правила — это еще хуже-, чем их отсутствие (как с практической, так и с
юридической точки зрения).
Лицензии на программное обеспечение
Многие компании оплачивают меньшее количество копий программных
пакетов, чем на самом деле используют. Если об этом становится известно,
компания теряет гораздо больше, чем сэкономила на приобретении недос-
тающего числа лицензий. Другие компании получают демо-версию дорогого
пакета и взламывают ее (меняют дату на компьютере, определяют лицензи-
онный ключ и т.п.), чтобы пакет продолжал работать по истечении
демонстрационного срока. Как системный администратор должен реагировать
на предложения нарушить лицензионное соглашение и установить нелииен-
зионные копии продукта на дополнительные машины? Что ему делать, если
он обнаружит, что на обслуживаемых им компьютерах работает пиратское
программное обеспечение? И как быть с условно-бесплатными программами,
за которые так никогда и не заплатили?
Это сложный вопрос. К сожалению, руководство не всегда поддерживает
администратора, предлагающего либо удалить нелииензионные копии паке-
тов, либо их оплатить. А ведь часто именно системный администратор
подписывает лицензионное соглашение, требующее удалить демонстрацион-
ные копии после определенной даты, тогда как решение их не удалять
принимает руководитель.
Даже если вы дорожите своей работой, помните, что речь идет о вашей
личной и профессиональной честности. Что касается работы, то спрос на
832
Чость III. Розное
хороших системных администраторов настолько велик, что без работы вы
надолго не останетесь. Нам известно несколько случаев, когда непосредст-
венный начальник системного администратора предлагал ему не раскачивать
лодку. В каждом случае администратор написал докладную записку высшему
руководству, в которой указал количество лицензированных и используемых
копий и процитировал лицензионное соглашение. В результате в одном случае
уволился непосредственный начальник системного администратора, в другом
администратор.
Спам: навязчивая почта коммерческого содержания
Множество рекламных агентов, коммерческих представителей и просто
аферистов ринулись в Internet. чтобы воспользоваться преимуществом “бес-
платной” электронной почты. Стоимость отправки рекламы тысячам поль-
зователей Internet ничтожно мала по сравнению со стоимостью отправки
традиционной бумажной почты, и доходит она невероятно быстро. В резуль-
тате страдают две категории людей: пользователи Internet, ежедневно полу-
чающие горы спама, и провайдеры услуг Internet, оплачивающие весь этот
трафик.
Мы не будем вдаваться в технические детали борьбы со спамом. Они
достаточно полно описаны в главе 19, посвященной электронной почте. Здесь
же мы упомянем юридические аспекты вопроса.
В Соединенных Штатах действуют законы (преимущественно на уровне
штатов), которые могут использоваться для юридического преследования лиц.
занимающихся рассылкой спама. Как минимум в одном случае отправителям
спама пришлось заплатить за каждое отправленное ими сообщение, поскольку
они нарушили нормальное ведение бизнеса получателями. К сожалению,
большинство получателей спама его просто удаляют и не трудятся призвать
его отправителей к ответу.
Провайдеры услуг Internet пытаются всячески препятствовать рассылке
спама, причем не только из-за используемых им ресурсов н полосы
пропускания, но еше и потому', что спам обычно нарушает правила их
собственных провайдеров и подвергает их риску утратить подключение к
сети.
Полезные ссылки на материалы, связанные с рассылкой спама, вы
найдете по адресу: http://www.elsop.com./wrc/nospam.htm
27.3.	Некоторые интересные факты
В 1992 г. Роб Колстад (Rob Kolstad) и Джефф Полк (Jeff Polk) провели
опрос участников LISA (Large Installation System Administration Conference —
Конференция системных администраторов крупных организаций, проводимая
USENIX) на предмет того, сколько времени они тратят на административные
задачи и какой уровень поддержки необходим для сопровождения узла. После
этого SAGE (System Administrators' Guild — Ассоциация системных админи-
страторов), связанная с ассоциацией USENIX, провела несколько аналогич-
ных исследований, концентрируясь на вопросах заработной платы. Еше одно
исследование по вопросу заработной платы провел в 1999 году институт SANS
(System Administration, Networking, and Security Institute — Институт систем-
ного администрирования, сетевых технологий н зашиты). О результатах этих
исследований рассказывается в следующих разделах.
Глово 27. Стротегия и политике одминистрировония
<33
Результаты опооса, проведенного организацией SAGE
Ha конференции LISA осенью 1999 года SAGE провела опрос системных
администраторов, в котором основное внимание уделялось оплате их труда.
Полный отчет об этом исследовании вы найдете по адресу www.useiiix.org/sKgc.
Члены ассоциации SAGE могул загружать файл Acrobat, указывая свои
учетный номер и' пароль. Те, кто не является ее членами, должны
зарегистрироваться и получить файл по электронной почте. SAGE не будет
никому предоставлять ваш адрес, но может присылать вам информацию о
своих конференциях и публикациях. (Впрочем, при регистрации можно сра-л
отказаться от их почты.)
Вот несколько интересных фактов, полученных в результате этого опроса,
охватившего 2300 системных администраторов, присутствовавших на конфе-
ренции или заполнивших форму через Web. Большинство респондентов были
штатными системными администраторами, для которых это занятие было их
основной работой. Около 80% из них работают в Соединенных Штатах,
остальные — в 48-ми других странах.
•	Половина системных администраторов имеет зарплату более 60000 долл.
Зарплата десяти процентов составляет почти 90000 долл.
•	Более 86% респондентов получили повышение в 1999 году, в том числе
8% остались на той же работе, а 23% — сменили работу и работода гелей
•	Более 70% организаций не могут найти достаточное число системных
администраторов.
•	В оплате труда системных администраторов не распространены бонусы
и оплата сверхурочных.
•	Штатный администратор в среднем работает 47 часов в неделю .
•	Наиболее распространенными операционными системами (в порядке
уменьшения популярности) являются: Solaris, Windows NT, Linux, Win-
dows 95 и 98. HP-UX, IRIX, MacOS. True 64 UNIX и FreeBSD.
•	Администрирование Windows NT и BSD оплачивается ниже, чем других
систем.
•	Образование не имеет прямой корреляции с зарплатой. Степень бакалавра
добавляет к зарплате всего 6000 долл.
•	Зарплата очень зависит от опыта работы Чаще всего назывался
пятилетний стаж.
•	Более трети системных администраторов работают на нынешнем месте
менее года.
•	Более 80% респондентов предполагают ближайшие пять лет остаиаил-я
администраторами.
•	Женщины составляют менее 13% всех системных администраторов.
•	Почти половина всех системных администраторов имеет возраст от 25
до 35 лет, а менее 1% — младше 20 или старше 55 лет.
•	Самым трудным и неприятным в своей работе системные администраторы
считают взаимодействие с руководством, процесс распределения обяын-
ностей и бюрократию.
Согласно опросу, проведенному в 1992 год}, администраторы работали 47,5 часов в неделю,
хотя в том опросе отбрасывались сообщения о работе более чем по 70 часов в неделю,
поскольку считалось, что такая работа не может продолжаться долго.
834
Чость III Резное
Отвечая на анкету, многие администраторы поняли, что они не знают,
как проводят день. Почти во всех организациях чувствовался дефицит кадров
Немного пользователей-нытиков — и их число на одного системного
адхгинистратора становится угнетаюшим.
Результаты опроса, проведенного организацией SANS
Ассоциация SANS провела в 1999 голу Web-опрос администраторов.
В нем приняло участие около 11 тыс. респондентов следующих категорий:
системные администраторы, сетевые администраторы, администраторы сис-
темы зашиты, администраторы баз данных, консультанты по вопросам зашиты
и аудиторы систем зашиты.
Многие вопросы были теми же, что и в опросе ассоциации SAGE, но
прямое сравнение результатов этих двух опросов провести сложно, поскольку
диапазон его участников был шире. Еше одна трудность сравнения состоит
в том. что SAGE вычисляла статистические результаты на основе медиан, а
SANS на основе средних значений. Некоторые результаты исследований SANS
представлены в виде гистограмм, и мы преобразовали их в медианы, чтобы
их удобнее было сравнивать с результатами SAGE.
84% участников опроса работают в Соединенных Штатах, из них 50%
назвались системными администраторами, а 24% — сетевыми администрато-
рами. Администраторов остальных категорий очень мало Вот некоторые
интересные результаты этого опроса.
•	Распределение операционных систем оказалось иным: 63% приходится
на Windows NT, 14% на Solaris. 6% на Novell NetWare, остальные едва
набрали 3%. Только 2,1% опрошенных назвали основной операционной
системой Linux.
•	Профессиональный опыт большинства опрошенных составляет 3—4 года
(а не 5, как в опросе LISA/SaGE).
•	Половина администраторов Windows NT получает более 50000 долл., а
половина администраторов UNIX - более 60000 долл. При этом женщи-
ны-администраторы Windows NT получают на 2000 долл, меньше, а
женщины-администраторы UNIX — на 4000 долл, меньше (при одина-
ковом с мужчинами опыте работы и образовании) Женщинами были
12% респондентов.
•	Степень бакалавра добавляет к зарплате всего 5000 долл, для админист-
раторов Windows NT и 8000 долл, для администраторов UNIX. Степень
магистра добавляет еше 5000—8000 долл.
•	Зарплата новичков, молодых специалистов и опытных администраторов
растет с опытом работы, но ближе к верхнему пределу степень увеличения
становится все меньше.
•	Рабочая неделя в среднем длится 46,8 часов, и здесь администраторы
UNIX и Windows NT в равном положении
27.4.	Объем и качество обслуживания
Перечень услуг, оказываемых группой административной поддержки,
должен быть четко сформулирован, иначе ожидания пользователей не
оправдаются
Следует рассмотреть такие вопросы:
•	время реагирования;
Глово 27. Стротегия и политика администрирования
835
•	обслуживание в выходные дни и внеурочное время;
•	вызовы на дом (обслуживание компьютеров, установленных дома у
пользователей);
•	специализированные аппаратные средства;
•	устаревшее аппаратное обеспечение;
•	поддерживаемые операционные системы;
•	стандартные конфигурации;
•	специальное программное обеспечение;
•	обязанности уборщицы (протирание экранов и клавиатур).
Пользователи должны знать не только о том. какие предоставляются
услуги, но и о схеме приоритетов, используемой при управлении очередью
на выполнение заданий. В схемах приоритетов всегда есть исключения, но
нужно попробовать разработать такую схему, которая охватит большинство
ситуаций без исключений. Вот некоторые параметры, связанные с приори-
тетами;
•	количество пользователей, подпадающих под действие схемы приоритетов;
•	степень важности пользователей, подпадающих под действие схемы
приоритетов;
•	привередливость подпадающих под приоритеты пользователей;
•	важность предельных сроков выполнения работы (поздняя работа дома
или грант на исследовательские работы, за счет которого частично
оплачивается груд группы системных администраторов).
Наша группа сопровождения клиентов — преподавателей, сотрудников и
аспирантов — разработала комплект документов, регламентирующих виды
оказываемых группой услуг, схему приоритетов и механизм контактов
В нашей группе клиентов используется несколько уровней важности и
привередливости. Эти документы применялись несколько лет с неплохими
результатами. Их копии можно найти по адресу www.admin.corn.
27.5.	Информационно-диагностические системы
В нашей информационно-диагностической системе используется псевдо-
ним электронной почты trouble. Одно время нас бомбардировали неполными
и непонятными сообщениями о неисправностях. Мы написали сценарии,
который задавал пользователю конкретные вопросы, например:
•	На каком компьютере возникла проблема?
•	Повторяющаяся ли она?
•	Насколько важно устранить эту проблему немедленно?
Через час пользователи подняли бунт, а через день нам пришлось все
отменить. Единственным результатом стало то, что многие пользователи
все-таки прочитали наши вопросы, поэтому качество сообщений о неисправ-
ностях, по-прежнему составляемых в свободной форме, повысилось.
В другой организации к этому' вопросу подошли так: разослали документ,
в котором разъяснялось, какая информация важна для сообщении о
неисправностях, и были приведены примеры бесполезных сообщений При
получении последних давался ответ с извинением (“Извините, но у меня
недостаточно информации для того, чтобы...”) и копией желаемого поясни-
тельного сообщения. Пользователи быстро поняли, что к чему.
,3и
Чость III. Розное
Если вы не хотите, чтобы пользователи получали либо пять ответов на
свой вопрос, либо ни одного, вам необходима хорошая система для
отслеживания проблем. В этой системе должны фиксироваться все возни-
кающие проблемы и то, как они решались. Информацию об их решении
можно отсылать администраторам-новичкам и стажерам. Файлы журналов
часто оказываются очень полезным источником информации при подготоаке
отчетов для руководства (особенно если вам нужно доказать, что штат
администраторов жизненно нуждается в расширении). А администраторы-но-
вички могут почерпнуть из них информацию о типичных проблемах вашей
компании и о том, как они решаются.
Мы много лет использовали доморощенную систему отслеживания
проблем, называемую queuemh или troubmh Сейчас предпочитаем систему
wreg (www.math.duke.edu/~yu/wreg). Она разработана на основе системы reg,
созданной в Университете штата Мериленд, — функции последней несколько
расширены и добавлен Web-интерфейс. Система wreg имеет почти те же
возможности, что и коммерческий продукт Remedy, но ее легче настраивать
и использовать. Кроме того, она нам по карману (потому' как распространя-
ется бесплатно!).
Собираемые, обрабатываемые н рассылаемые системой wreg отчеты
полезны как администраторам, так и руководству. Они помогают выявить
долгосрочные тенденции, но у этой системы имеется один важный
недостаток — она практически не документирована.
27.6.	Как руководить руководителями
Очень важно, чтобы руководство вас ценило, уважало и поддержзгаало.
Обычно труднее всего получить поддержку руководства в вопросах политики
защиты. Чем жестче зашита системы, тем больше неудобств испытывают ее
пользователи, и они немедленно начинают протестовать. Поэтому следите за
тем, чтобы пользователи были заранее оповещены обо всех изменениях в
системе зашиты, которые отражаются на их работе (например, переход от
telnet па ssh, от паролей на ключи RSA и т.п.). Все этн изменения должны
бьггь хорошо документированы, и пользователям во время их внедрения
должны оказываться повышенное внимание и поддержка. Документация
должна быть понятной и содержать подробнейшие инструкции по работе с
новой системой. Выделите дополнительные человеко-часы для работы с
пользователями, которые паникуют из-за того, что не прочли свою электрон-
ную почту или motd.
Вышестоящее руководство часто не имеет ни малейшего представления
о том. чем занимаются системные администраторы. Дневник, в котором вы
записываете все, что делаете, и отмечаете, сколько времени занимает та или
иная работа, способен удивить даже вас самого. Этот документ крайне
необходим, если вы собираетесь начать кампанию по набору дополнительного
персонала или покупке нового оборудования. Он. кроме того, может стать
серьезным оружием в текущих разборках. Рекомендуем вести подробные
записи даже при отсутствии конкретной цели.
Руководители. особенно нетехнического направления, часто недооцени-
вают сложность и трудоемкость задач, стоящих перед системным админист-
ратором. Чаше всего это касается поиска неисправностей
Старайтесь подходить к планированию с реалистических позиций.
Удваивайте или утраивайте время, которое, на ваш взгляд, понадобится для
решения масштабных и очень важных задач. Если расширение системы будет
Глово 27. Стротегия и политике одминистрировония
837
выполнено за два дня вместо трех, пользователи скажут вам спасибо, а вот
если вы обешали сделать это за один день и не сделали. их недовольство
будет совершенно справедливым.
Иногда администратору бывает трудно добиться официального введения
правил. В этом случае фиксируйте документально су шествующую практику.
Например: "У нас восемь лицензий на Excel, инсталлировано 47 конин"
Попросите денег на покупку дополнительных копии. Если получите отказ,
подайте докладную записку вышестоящему руководству. К счастью, хороших
системных администраторов не хватает, поэтому другую работу- вам долго
искать не придется.
27.7.	Прием на оаботу, увольнение и обучение
Существует два подхода к вопросу обеспечения фирмы административным
персоналом:
•	нанимать опытных людей:
•	воспитывать свои кадры.
Опытные специалисты обычно набирают скорость быстрее, однако всегда
есть такие вещи, которые им сообщать нежелательно. Для того чюбы
выполнять свою работу, они должны иметь привилегированный доступ Вы.
однако, не знаете их достаточно хорошо и. возможно, не захотите, чтобы к
ним в руки попали некоторые сведения о вашей компании.
Подготовка администратора требует массы времени и усилии, а компью-
терная сеть производственного предприятия — не самый лучший учебный
класс. Если, однако, вам попался хороший кандидат (умный, заинтересован-
ный. внимательный и т.д ). конечный результат оправдает затраты.
Мы разработали две методики оценки опытных претендентов. Раньше
мы называли эти методики “тестами”, но потом узнали, что некоторые
учреждения не имеют права тестировать претендентов. Поэтому мы их больше
не тестируем, а оцениваем
Первый не-тест. письменная анкета, предполагает оценку претендентами
своего опыта и знаний в различных областях системотехники и сетей.
Используется следующая шкала:
•	никогда не слышал об этом (0),
•	слышал об этом, но нс делал (I).
•	делал это, могу это делать под контролем (2).
•	могу это делать без контроля со стороны (3).
•	могу обучать этому других (4).
В анкете есть вопросы с ловушками. Например, в разделе по техническим
средствам есть вопрос о разъемах RS-232. а за ним — вопрос о “разъемах
MX’’’. Если кандидат в качестве ответа поставил “3", с ним все ясно. Остается
только напоследок задать ему невинный вопрос: “Так для чего же ны
используете разьемы MX?*’
Вторая методика разработана для телефонною интервью. Вопросы
построены так, чтобы можно было быстро получить ответы от человека,
знающего свои предмет. За правильный ответ мы даем +1. за *’я не знаю" —
0. за очевидную ложь или явное обращение к документации — -1
MX — это тип записей ресурсов, используемый в DNS, а не тип разъема.
,33
Чость III Розное
Для нас результаты опросов по этим двум схемам всегда были достаточно
надежным показателем Количество вопросов с ловушками зависит от
конкретной ситуации; как правило, одного-двух недостаточно. Отметим, что
сделанные на основании такого не-тестировання выводы не дают ответов на
другие ключевые вопросы, важные при выборе перспективного администра-
тора.
•	Уживется ли он с другими членами команды?
•	Хорош ли его “пользовательский интерфейс”?
•	Будет ли он выполнять указания?
•	Возможен ли его рост как специалиста?
Ответы на некоторые И1 этих вопросов вы сможете получить в личной
беседе. Дополнительные сведения можно узнать по телефону у рекомендате-
лей. Слушайте внимательно, потому что многие не любят говорить плохое о
бывших подчиненных и коллегах. Если претендент ие имеет рекомендаций
с последнего места работы, это должно настораживать.
Если вы сделали ошибку при подборе специалиста, немедленно увольте
принятого сотрудника. Держать на работе людей, не желающих впрягаться в
общую повозку, — значит, настраивать против себя других сотрудников,
которым приходится взваливать все на свои плечи и подчищать огрехи за
лентяями.
Однако во многих организациях уволить кого-либо бывает очень трудно.
Возможно, придется подбирать факты, подтверждающие некомпетентность,
давать официальные предупреждения, ставить задания по производительности
и т.д. Иногда уволить человека легче во время испытательного срока, чем
после него, поэтому первоначальную оценку необходимо проводить тщатель-
но. Наши анкеты имеются по адресу www.admin.com. Вы найдете все
вопросы-ловушки?
Корректировка позиции
Системные администраторы, особенно страдающие манией величия, часто
забывают, что они — поставщики услуг, а пользователи — их клиенты
Многие администраторы втайне считают, что системы принадлежат им. а
пользователи — это так, печальное недоразумение
Сейчас администраторов уважают, считают опытными профессионалами
и хорошо им платят А вот в прошлом иа них смотрели как на электронных
швейцаров, которые стоят на несколько каст ниже разработчиков и инжене-
ров. В настоящее время зарплата администраторов настолько выросла, что
вместе с ней изменился и их статус. Руководителям желательно советоваться
с административным персоналом в вопросах повышения по службе того или
иного работника, поскольку то, как он взаимодействует с администраторами,
очень важно для оценки его личных качеств — творческого подхода и
способности к самостоятельному решению проблем
Некоторые качества хорошего системного администратора вступают в
противоречие друг с другом. Администратор должен быть достаточно смелым,
чтобы предлагать неординарные решения задач, но вместе с тем и достаточно
осторожным, чтобы не сделать ничего губительного для системы. Хорошие
человеческие качества и мастерство в решении проблем одинаково важны,
но, кажется, у многих администраторов, которых мы знаем, они исключают
друг друга. Один из наших редакторов сказал, что "приятный системный
администратор** — это просто оксюморон.
Глово 27. Стротегия и политике одминистрировония
839
Обещанные Microsoft системы. "не нуждающиеся в администрирова-
нии”. — это утопия. Ведь кто-то должен нажать <Ешег> или щелкнуть на
кнопке ОК и принять на себя ответственность за последствия!
Опере горские войны
Новые администраторы часто становятся жертвами так называемых
"операторских войн”, когда более опытные пользователи дают команде logout
псевдоним Is. посылают администратору электронной почтой всевозможные
"бомбы" и выставляют таким образом их неопытность на всеобщее посме-
шище. Особенно привлекательные жертвы — администраторы, забывающие
выйти из системы.
В университетах такое случается чаще, чем в коммерческих структурах,
но, вероятно, подобное происходи г везде С одной стороны, это вроде бы
весело, но иногда дело заходит слишком далеко, поэтому такие штучки нужно
строго запрещать. Новому администратору и так хватает забот, л не нужно
добавлять ему новые, пусть даже в шутку.
Последовательное улучшение
Часто бывает гак, что администратор считает проблему устраненной, но
тут же получает несколько еше более тревожных сообщений, а это значит,
что задача должна быть решена по-другому: пусть медленнее, но зато
полностью и правильно. Это может случиться, например, из-за того, что
пользователь, первым сообщивший о проблеме, описал ее неточно или
предложил неверное решение. Иногда причиной является нежелание адми-
нистратора всесторонне проверить найденное решение.
Вот некоторые типичные жалобы:
•	для нового программного обеспечения нет man-страниц и документации.
•	программное обеспечение инсталлировано не везде, где нужно:
•	право на использование программного обеспечения принадлежит только
администратору или установлено с неверными разрешениями
Тестирование, конечно, утомляет, но, пропустив этот важный этан
администратор вдвое урезает производительность системы Каждое сообщение
о неисправности неизбежно приводит к трате времени и усилии — как
пользователей, так и администратора. Любую задачу можно успешно выпол-
нить только после выявления и устранения всех шероховатостей.
Типичная жалоба пользователя звучит так "команда или программа X
не работает на машине Y”. Администратор отправляется па машину V.
выполняет команду X. и все работает прекрасно. Он отвечает пользователю.
“У меня все работает” Но па самом деле администратор часто выполняет
не совсем го. что сделал пользователь, пли то же самое, но в другой среде
Например, администратор должен не забыть непосредственно перед проблем-
ной командой выполнить команду sudo su - имя_помзоватем, чтобы приме-
нить те же параметры среды, что п пользователь.
Пользователи обычно огорчаются, если проблему не удается полностью
решить с первой попытки, поэтому старайтесь настраивать их соответствую-
щим образом. Пригласите пользователя, сообщившего о проблеме, поработать
вместе с вами над ее решением, особенно если проблема связана с освоением
незнакомого пакета npoi-рамм Вы получите дополнительную информацию, а
пользователь уже не будет считать ваше участие чпего консультативным.
840
Чость III Розное
27.8 Невыдуманные истории
В этом параграфе рассматриваются этические вопросы. Дело в том. что
в работе системных администраторов многое строится на доверии. .Админи-
стратор должен уважать конфиденциальность информации, с которой рабо-
тают пользователи, и защищать профессиональные секреты компании. На
доверии основываются отношения как с пользователями, так и с руководством
компании, и без него администраторам очень трудно выполнять свою работу.
Личная и профессиональная честность администратора совершенно бесценны,
так что старайтесь никогда не давать окружающим повода в ней сомневаться
В этом разделе мы предлагаем вашему вниманию ‘‘военные истории",
иллюстрируюшие этические дилеммы, которые могут встать перед системным
администратором. Некоторые из них мы извлекли из собственной практики,
а о некоторых узнали из других источников, иногда через энные руки, поэтому
абсолютную точность не гарантируем
Ошибка начальника {номер один)
Однажды декан факультета ошибся и послал данные о персонале не в
исполнительный комитет, для которого они предназначались, а всем сотруд-
никам факультета. Он попросил администратора-студента, работавшего в те
выходные, откорректировать содержимое электронных почтовых яшиков
сотрудников и изъять это сообщение. Должен ли студент делать это? Должен
ли он отказаться? Должен ли он прочесть подлежащее изъятию сообщение
и решить для себя, достаточно ли оно серьезно для того, чтобы оправдать
вторжение в частные владения?
В этом примере администратор все-таки сделал то. о чем его попросили,
но потребовал, чтобы декан послал сотрудникам факультета сообщение с
разъяснением того, что произошло. Он поставил еше одно условие: сообщение
из почтовых яшиков будет изыматься в присутствии свидетеля, который
убедится, что администратор никуда больше не влезает. Это, несомненно,
хорошее решение удовлетворило и администратора, и декана.
Ошибка начальника (номер два)
Новая секретарша крупной компании по производству компьютеров слабо
разбиралась в ОС UNIX и электронной почте. В конце своей первой рабочей
недели она послала начальнику сообщение о том, насколько хороша
предоставленная ей работа и как помогли ей все сотрудники. Вот ее
командная строка:
% mall boss I like my new job, everyone Is so helpful,
thank you. Working here for you will be really fun ...
Начальник прочел это сообщение и в ответ послал шутливое грубо-сек-
суальное замечание относительно размера ее бюста. Другие сотрудники
(everyone было общим псевдонимом для всех сотрудников) отметили необ-
ходимость наличия символа возврата каретки между именем получателя и
самим сообщением.
Через несколько часов начальник позвонил главному администратору
(который к тому времени прочел и сообщение секретарши, и ответ босса) и
сказал, что допустил ошибку (вероятно, вместо г поставил R), поэтому копии
сообщения нужно изъять из почтового ящика everyone, т.е. у нескольких
тысяч служащих. Нечего и говорить, что администратор отказался.
Глово 27. Стратегия и политике одминистрировония
г-‘.
Дэн, твое новое имя — Лестэр
Эта история произошла в американской компании с несколькими
тысячами сотрудников и несколькими офисами. Использовавшаяся в этой
компании коммерческая программа для работы с электронной почтой умела
находить и преобразовывать имена получателей почты. вводимые в строке "То”.
Новый начальник отдела кадров по фамилии, скажем, Смит-Джонс была
в ярости, поскольку предназначавшаяся ей важная электронная почта
направлялась другому человеку по фамилии Джонс. Похоже, что люди,
направлявшие ей эти сообщения, вводили в строке “То" просто "Джонс” и
не смотрели, как преобразовывается эта фамилия. Все это происходило в то
время, когда компания реорганизовывалась и некоторые сотрудники уволь-
нялись. Сообщения как раз и касались увольнений.
В результате руководство стало требовать “исправить ошибку”. Созыва-
лись совещания, приглашалась эксперты. Один из руководителей даже
предложил переименовать Джонса в базах данных компании И наконец,
когда казалось, что проблема не разрешима, один из руководителей
информационного отдела выступил и сказал, что все это вопрос обучения
пользователей. В конце концов пользователей, которые отправляли сообще-
ния не тому человеку, просто научили сначала смотреть, кому отправляется
сообщение, и только после этого давать команду отправки.
Кого увольнять?
Администратор-новичок и ученик оператора нашли способ проникнове-
ния в студенческие компьютеры вычислительного центра. Этими компьюте-
рами управляла другая группа, известная своими крайне консервативными
взглядами. Новички хотели сохранить "черный ход”. Когда они собирались
редактировать файл /etc/passwd, старший администратор дал им совет —
вместо vi воспользоваться редактором vipw. После создания “черного хода”
новички им не пользовались, в отличие от старшего гшминнстратора, который
был в конце концов на этом пойман Кого следует уволить?
Наш ответ: либо всех троих, либо одного старшего администратора,
который должен был воспрепятствовать попытке взлома. узнав о ней', а не
советовать и подсказывать, как сделать “черный ход”. В дашзом случае,
однако, руководство посчитало, что старший администратор — слишком
ценный сотрудник и терять его нельзя, поэтому уволили двух новичков.
На наш взгляд, это очень плохое управленческое решение. Оценивая
поведение человека по степени его важности для организации, а не по
установленным и строго соблюдаемым правилам, организация рискует
постоянно выступать ответчиком в суде (не говоря уже о рассерженных
служащих с винтовками наперевес).
Упрямец Джо
Джо. новый администратор крупной компании по производству компью-
теров. увлекся секретаршей и пригласил ее на свидание. Она отказалась
Через неделю секретарша сказала одному из старших администраторов, что
компьютер постоянно сообщает ей о наличии почты, даже когда она не
опрашивает новую почту. Старший администратор проверил журнальные
файлы и установил, что Джо читает почту, предназначенную секретарше. Что
бы вы сделали в этом случае?
• Уволили бы Джо?
842
Чость III. Розное
•	Вынесли бы ему строгое предупреждение?
•	Просто пожурили бы?
•	Ничего не сделали?
Правильный ответ зависит от ответа на другой вопрос: существуют ли
официальные правила, в которых написано: ’Не читайте чужую электронную
почту”? Поскольку таких правил не было, дело кончилось строгим преду-
преждением.
Спустя несколько недель все повторилось. На этот раз почту читал другой
человек: Том. Старший администратор вызвал его и предъявил
доказательства — журнальные файлы. Оказалось, однако, что в то время,
когда Том якобы читал почту, он на самом деле был на баскетбольном матче.
Дальнейшее расследование показало, что истинным виновником вновь
был Джо. Через полчаса он был уволен.
Правила, допускающие одно предупреждение, — не более чем разрешение
воровать до тех пор, пока не поймают.
Приглашения на свадьбу
Системный администратор, который вот-вот должен был жениться и не
успел закончить все приготовления к свадьбе, дал своему лучшему другу
(администратору из другой организации) ключ оз кабинета и пароль root к
своей рабочей станнин. Друг должен был сделать карточки для размещения
гостей за свадебным столом. Этим администратор нарушил сразу несколько
пунктов правил. Другие администраторы сразу заметили подлог, потому что
у них было принято пользоваться командой sudo, а не регистрироваться под
паролем root или через su.
Пароль root был одинаковым на всех компьютерах, поэтому посетитель
фактически получил в свои руки пароль привилегированного пользователя и
физический доступ ко всем компьютерам организации. Никакого ущерба,
однако, нанесено не было.
Обстоятельства, которые стали причиной такого поступка жениха, можно
рассматривать как особые, однако были нарушены письменные правила.
Служащий был ценным работником. Что делать? Все кончилось тем, что его
уволили — правда, с неохотой. Он подал в суд. ио проиграл дело.
Порнографические GIF изображения
Как-то летом друг одного студента пришел к нему в гости в компьютер-
ную лабораторию. Студент показал Другу, как просматривать GIF-файлы и
где найти “интересные картинки”. Он посадил друга за последнюю станцию
у задней стены, а сам стал делать домашнее задание. Закончив все дела, оба
ушли.
Через некоторое время (несколько дней спустя) декан факультета в
сопровождении тренера баскетбольной команды показывал территорию
университета новой студентке из Техаса. У декана были ключи от лаборато-
рии. поэтому он вошел не так. как студенты (по карточке), а через заднюю
дверь.
Первая же увиденная ими рабочая станция оказалась как раз той, на
которой друг студента смотрел GIF-картинки После прикосновения к мыши
на дисплее появилась откровенно сексуальная фотография. Как и следовало
ожидать, декан и баскетбольный тренер пришли в ярость. Декан потребовал
Ггпво /7. Стротегия и политике одминистрировония
З-чЗ
немедленно удалить из университетских компьютеров все GIF-файлы,
исключить студента, оставившего картинку на экране, и т.д.
Наши правила (вышеупомянутый студент с ними тоже был ознакомлен)
говорят о том, что пользователь не должен выводить на экран изображения,
которые могут быть оскорбительными для других. В результате студент на
семестр был лишен своего регистрационного имени. Правила были проверены
юристами (которые стали на нашу сторону, а не на сторону декана), и
инцидент был исчерпан. В завершение мы принесли свои извинения новой
студентке
Перенос данных
Обслуживание техники и программных средств одной небольшой компа-
нии осуществляла местная сервисная фирма. Как-то вечером системный
администратор работал с диском, в котором барахлили подшипники. Сер-
висная фирма доставила не только диск для замены, но и большой
вспомогательный диск, чтобы можно было переписывать данные без исполь-
зования лент. Администратор заменил неисправный диск, установил вспомо-
гательный диск и перезагрузил систему.
К своему удивлению, после загрузки станции с нового диска он увидел,
что часы отстают на 29? дней. Что делать: немедленно очистить диск,
посмотреть данные, вернусь диск обратно? Первым его побуждением было
удалить все файлы, но, подумав, администратор решил проверить данные и
посмотреть, чьи они
Беглый просмотр файла passwd показал, что раньше диск принадлежал
этой же компании. Он содержал нс только корневой раздел с зашифрован-
ными паролями, но и базы данных компании, информацию о новых изделиях
и т.д. Короче говоря, на якобы новом лиске компания получила ст сервисной
фирмы свои же данные, правда, слегка устаревшие.
Руководители сервисной фирмы признались, что тестировали диски путем
копирования данных с одного диска на другой, не обращая внимания на то,
какие данные были на исходном диске.
Этот случай иллюстрирует проблему, которая выявляется постфактум п
трудно поддается решению. Кто отвечает за судьбу данных, оставшихся на
сломанном диске? Не всегда можно удалить информацию с диска перед
отправкой его в ремонт Сервисные службы не считают ваши данные чем-то
ценным; для них существует только сломанный или плохо работающий диск.
Как администраторы мы обычно защищаем свои резервные ленты от
несанкционированного копирования, но при поломке диска этого не делается.
Если есть возможность, перед отправкой в ремонт ценные данные с диска
нужно стереть (путем низкоуровневого форматирования с проверкой). Если
неисправность диска не позволяет переформатировать его. сообщите сервис-
ной фирме о том. что диск содержит важные данные, которые хотелось бы
удалить.
Возможно, стоит узнать у представителей сервисной фирмы о том. каких
правил они придерживаются по отношению к информации, принадлежащем
клиентам. Если у них таких правил нет, изобразите крайнюю степень
удивления.
В секретных американских правительственных учреждениях (особенно
оборонного характера) иногда вообще запрещается выносить с территории
вычислительную технику. Если компьютер сломался, покупается новый. На
первый взгляд это похоже на бред, но, как видно из нашего рассказа, такое
B44
Чость III. Розное
подход не лишен оснований. Аналогичные правила распространяются даже
на такие компоненты, как процессорные платы, на которых никогда не бывает
никаких данных. Нельзя ведь заранее знать о том, где прячутся шпионы!
Билл должен умереть!
Один студент работал на компьютере в факультетской лаборатории. Не
закрывая сеанса, он пошел за каким-то документом в другое помещение.
В его отсутствие кто-то послал сообщение электронной почты по адресу
president@whitehouse.gov.
Сообщение содержало угрозы предать Президента Клинтона эффектной
насильственной смерти. На следующее утро раздался звонок из секретной
службы.
Студент оказался иностранцем и когда-то служил в милиции своей страны
экспертом-шифровальщиком. Он не сообщил местным системным админи-
страторам о том. что получил из Белого дома подтверждение о получении
почты, которую не посылал. Все выглядело не очень красиво.
Системные администраторы потратили неделю на сбор журнальных
файлов и записей доступа по карточкам. К счастью, в журнальных файлах
оказалось достаточно доказательств того, что студент, скорее всего, стат
жертвой чьей-то глупой шутки.
Файл '/-history, содержащий список ранее введенных студентом команд,
показал, что он регулярно пользуется программой pine, тогда как злосчастное
сообщение было послано с помощью mail, причем до отправки и после нее
имели место длительные периоды бездействия. Большинство пользователей
для чтения и записи почты применяет одну и ту же программу, поэтому
сразу же встал вопрос о незаконном проникновении в пользовательскую
учетную запись.
Оказывается, угрозы Президенту являются уголовным преступлением.
Несмотря на то, что студента-иностранца оправдали, расследование продол-
жалось. Некоторое время спустя инцидент повторился, и поданным журналов
удалось вычислить шутника.
Мы рекомендуем студентам пользоваться программой xlock*. прежде чем
оставить свой терминал без присмотра Мы модифицировали эту программу
так, что она просто выгружает пользователя, который долго не активен, чтобы
машины в лаборатории не блокировались надолго.
27.9. Размещение и обновление программ
В каждой компании свои правила размещения и модернизации програм-
много обеспечения. Тут не существует хороших и плохих методов, а правила
и процедуры во многом определяются масштабом сети. Объем данного
материала можно было бы увеличить до отдельной главы, но мы решили
ограничиться только общими рекомендациями Кроме того, мы предлагаем
список программного обеспечения (с открытым кодом), которое может быть
вам полезно
xlock — это хранитель экрана для системы X Windows, который разблокирует экран только
после ввода пароля.
Глово 27. Стротегия и политике одминистрировония
845
Управление программным обеспечением в крупных системах
Управление программным обеспечением и установка выпускаемых его
производителями “заплат” с ростом компании может стать очень сложной
задачей. В ее решении может помочь множество различных средств. Это и
коммерческие системы управления конфигурацией ПО. и вспомогательные
утилиты, такие как rdist. rsync и make.
Советы, относящиеся к распространению файлов, приведены в параграфе /8.2.
В компании обычно имеется несколько различных комбинаций аппарат-
ных средств и операционной системы Как правило, все машины одного типа
имеют сходную конфигурацию и на них устанавливаются одни и те же
выпуски программного обеспечения, которые отличаются только настройками
для конкретных пользователей. В небольшой системе распространение ПО
может быть организовано плохо и этого никто не заметит, однако в крупной
компании работа должна быть выполнена один раз и затем быстро перенесена
на другие машины.
При этом необходимо решить две важные задачи:
•	организовать иерархию каталогов обсуживаемого программного обеспе-
чения;
•	определить механизм распространения устанавливаемого ПО с машины -
прототипа на рабочие компьютеры.
В некоторых организациях используются программы типа automuonter или
amd, скрывающие от пользователя реальное расположение программных
пакетов. В других организациях пакеты хранятся централизованно и для
каждой архитектуры определяется свое дерево каталогов. В любом случае,
нельзя просто сбрасывать все в /usr/local/bin — имена программ из разных
пакетов могут вызвать конфликт.
Системные администраторы разработали два пакета, облегчающих самую
трудоемкую часть работы. Это cfengine и SEPP. Пакет cfengine, созданный
Марком Бургесом из колледжа Осло (Норвегия), представляет собой высо-
коуровневый язык для описания конфигурации машины. Он помешает все
данные в единое хранилище. Пакет cfengine выполняет команду diff. а затем
синхронизирует клиентскую систему с главной. Этот пакет распространяется
бесплатно и работает во всех четырех наших опытных системах. Вы найдете
его по адресу www.iu.hioslo.no/sfengine.
Программа SEPP, созданная Тоби Оэтикером из Swiss Federal Institute of
Technology (ETH. Швейцарский федеральный институт технологий), — это
упаковочная система для инсталляции и совместного использования про-
граммного обеспечения. Она также распространяется бесплатно, и ее можно
получить по адресу www.ee ethz.ch/sepp. Более подробные сведения об этих
пакетах имеются в материалах, указанных в конце главы.
Существует много средств для автоматизации и стандартизации установки
операционных систем н программного обеспечения. Мы не рассматриваем
их здесь, но в табл. 27.1 приводятся ссылки на дополнительные источники
информации.
846
Чооъ III. Розное
Тоблицо 27.1. Средство устоновки лрогроммного обеспечения
Система	Программа	Дополнительная информаций
Solaris	JampStart	См. документ “Solaris Advanced Installation Guide” no адресу docs.sun.com
HP-UX	SD-UX	Дистрибьютор ПО. распространяется в составе HP-UX 11.Х
	SD-OV	Усовершенствованная SD-UX, более дорогая и исполь- зующая OpenVicw
Red Hat	Kickstan	См. документ “Red Hat Installation Guide” по адресу www.readhat.com
	RPM	Red Hat Package Manager, man rpm
FreeBSD	каталог ports	Использует make и pkg {add, create, delete, info}
Обновление программ
Модернизация программного обеспечения — процедура болезненная и
нарушающая налаженную работу пользователей и системы, но часто она
необходима. А потому не откладывайте ее надолго, особенно если оказалось,
что вы на несколько порядков недооценили количество пользователей
Web-узла. Здесь важно умение найти разумный компромисс. Не стоит
торопиться внедрять каждое усовершенствование продукта, предлагаемое его
производителем, поскольку при этом всегда что-нибудь да ломается. Но и
затягивать надолго не стоит, чтобы вручную не исправлять то, что давно
исправлено производителем.
Новую версию операционной системы или важного программного пакета
сначала устанавливают на тестовой площадке и эксплуатируют недели и
месяцы и только затем переносят на основную рабочую технику компании.
Попросите разработчиков протестировать новую систему на вашей машине,
чтобы они убедились, что используемые ими средства установлены и
работают. Тщательно протестируйте каждое коммерческое приложение, чтобы
как следует разобраться со всеми вопросами лицензирования.
Одно из важнейших правил модернизации гласит: сначала создайте
полную и надежную резервную копию существующей системы и только после
этого приступайте к ее обновлению. Желательно иметь подробный план
восстановления на случай, если модернизация не получится. Для резервного
копирования лучше использовать запасной компьютер или на худой конец
запасной диск, на котором полностью установлена старая версия системы.
Вот что мы можем посоветовать, исходя из собственного опыта 
•	Будьте осторожны с версиями х.О продуктов.
•	Читайте отзывы о продуктах, чтобы узнавать о связанных с ними важных
проблемах.
•	Утраивайте предполагаемое время обновления ПО.
•	Составьте план возврата к старой системе и заранее оцените, сколько
времени займет его выполнение.
Много лет назад в новой версии Sun изменилось форматирование диска, и из-за ошибки в
программе format и мы не смогли восстановить свою систему. С тех пор мы не устанавливаем
первую версию ПО.
Глово 27. Стротегия и политике одминистрировония
847
•	Включите в план инсталляции возможность отменить ее и попробовать
еше раз на следующий день. При этом строго придерживайтесь состав-
ленного расписания.
Приведенная ниже история, произошедшая в крупной телекоммуника-
ционной компании, иллюстрирует некоторые типичные проблемы. Планиро-
валось обновить операционную систему и одно из приложений. После
некоторых наблюдений и исследований администраторы решили, что спра-
вятся с задачей за три дня, т.е. с 7:00 в пятницу до 18:00 в понедельник.
Первая попытка не удалась, поскольку администраторы обнаружили, что
производитель программного обеспечения не рекомендует пользоваться
имевшимся у них CD-ROM. На нем было слишком много ошибок. Прислали
новый набор дисков, и администраторы приступили к работе. К сожалению,
новое приложение и новая операционная система конфликтовали друг с
другом, и то, на что обычно уходит несколько часов, не удалось сделать за
три дня. После 60 часов непрерывной работы они, наконец, установили
операционною систему. Руководители компании, включая вице-президента,
были довольны, что обновление завершилось, но и порядком устали,
поскольку все это время каждые три-четыре часа они справлялись о
состоянии дел.
Этот пример показывает, что до тех пор, пока не получена информация
о работе программного обеспечения от тех, кто его уже использует, и пока
оно не протестировано на отдельной площадке в полной конфигурации (новое
приложение плюс новая ОС), нечего даже думать об установке его на
основной технике компании. Производственное оборудование — не полигон
для испытаний.
Полезные программы сторанних производителей
В нашем списке полезного программного обеспечения имеется несколько
настолько важных программ, что их нужно обязательно устанавливать на все
машины Другие программы необходимы или полезны только на отдельных
компьютерах. Однако стоимость дискового пространства сегодня настолько
низквя, что проще установить все и везде, чтобы служебное программное
обеспечение на всех машинах было идентичным. Перечень программ, которые
мы советуем обязательно устанавливать, приведен в табл. 27.2.
В табл. 27.3 описаны наши любимые программы, которые, однако, не
являются необходимыми. Мы разделили их на программы для пользователей
и прогрвммы для администраторов.
Программы, перечисленные в табл. 27.2 и 27.3, являются бесплатными.
Большинство из них можно загрузить из Web, а некоторые доступны только
по FTP. Для их поиска можно применять поисковые программы и ссылки
в этой книге (предметный указатель).
В архивах Red Hat Linux содержится много программного обеспечения
сторонних производителей, упакованного в виде дистрибутивов RPM (Red
Hat Package Manager). Для управления этими файлами и их установки можно
использовать команду гртп. подобную программе pkgadd из Solaris. С пакетами
RPM работать гораздо удобнее, чем с большинством встроенных процедур
компиляции и инсталляции программного обеспечения. Поэтому, прежде чем
пускаться на поиски оригинала, всегда проверяйте, доступна ли RPM-версия
команды.
8дЗ
Чость III Розное
Таблица 27.2. Важные программы сторонних производителей
Покат	Описоние и комментарии
aeh	Оболочка для защиты — использует шифрование, не показывает пароли
sudo	Заменяет яи. предоставляя дополнительные возможности контро- ля и управления входом в систему
undmftU	Программа транспортировки электронной почты — получите последний выпуск (для лучшей защиты)
traceroute1	Показывает сетевые маршруты — нужна для выявления сетевых проблем
tcp dump	Используется для анализа сетевого трафика и выявления сетевых проблем
nmap	Сканирует сетевые порты — используется для мониторинга системы и защиты сети
tesh/bash	Хорошие интерпретаторы — tesh хорош для использования по умолчанию, всегда приятно иметь удобный интерпретатор
gzlpa	Программа сжатия и распаковки zip-файлов GNU — использует- ся для распаковки загружаемых материалов
netscape	Web-броузер
tepd	TCP-оболочки — регистрируют входящие подключения к серверу и управляют ими
RCSa/SCCS/CVS	Системы ревизионного контроля —* полезны к системным адми- нистраторам, и пользователям
Perl	Язык сценариев. Установите Perl 5. Удобен для администраторов и CGI
Эти программы входят в состав всех описываемых нами систем, но ие обязательно
устанавливаются вместе с ними по умолчанию. Возможно, они ие включены и в
пакеты других производителей.
В каталоге /usr/ports системы FreeBSD содержится make-файл, который
знает, как найти и установить несколько тысяч различных программных
пакетов. Если войти в этот каталог и ввести команду make имя_пакета,
система найдет в make-файле адрес того места, где хранится оригинал
программного обеспечения, загрузит его через Internet, откомпилирует и
установит. Это очень удобная система. Ее нужно регулярно обновлять,
поскольку содержимое и место хранения пакетов может время от времени
изменяться. Подробные инструкции по ее использованию вы найдете в
руководстве “FreeBSD Handbook” иа сервере www.freebsd.ois/handbook.

Глово 27. Стротегия и политике одминистрировония
\49
Таблица 27.3. Полезное программное обеспечение сторонних производителей
Пакет	Описание и команды
Инструменты для системного администрирования	_________
gcc	Компилятор C/C++ — очень качественный компилятор от GNU
BIND1	Средства службы имен — установите последнюю версию (для более
надежной защиты)
tripwire	Проверяет статус файлов и обнаруживает изменения в системных
файлах
COPS	Средство защиты — выявляет слабые места системы
crack	Средство для взлома паролей — пытается отгадать пароли пользо-
вателей
npasswd	Замена passwd — заставляет пользователей выбирать правильные
пароли
snifTit/etiiereal Утилиты для обследования сети и выявления проблем
xntpd	Поддерживает правильное, синхронизированное время на системных
часах
Samba	Windows SMB — средство для совместного использования файлов и
принтеров в системах Windows
Apache	Web-сервер
Squid
LPRng
imapd/procmail
Прокси и кэширование для Web
Программное обеспечение для печати — замена для Ipr/lpd со
множеством усовершенствований
Почтовые утилиты — для доступа к электронной почте и ее
фильтрации
Инструменты для пользователей
Acrobat Reader Отображает PDF-файлы, прекрасное бесплатное средство от Adobe
xv/gimp	Манипулирует двоичными графическими форматами в X Windows
xfig	Программа для рисования XI1 — вроде Mac Draw для UNIX
PGP	Pretty Good Privacy — подписывает, проверяет и шифрует сообщения
nvi/vim	Текстовый редактор типа vi — рекомендуем системным админист-
раторам
emacs	Текстовый редактор/операционная система — хорош для опытных
пользователей
picos
enscript/mpage
pine/mh/exmh
glimpse
gs/gv/ghostview
Текстовый редактор — хорош для начинающих
Утилиты для печати и форматирования
Программы чтения электронной почты — pine для начинающих и
mh/exmh для большого количества почты
Средство индексирования — индексирует файлы и выполняет бы-
стрый поиск
Средства для просмотра и печати документов PostScript
В пакет BIND входят утилиты dig и nslookup.
850
Чость 111. Розное
27.10	Внутренняя документация
Работу нац документацией часто отодвигают на задний план. Сделать это
очень просто, потому что в тот момент, когда ее следовало бы написать, вы
обычно вспоминаете, что нужно срочно выполнить давно ждущую своей
очереди задачу. У любой административной группы, в состав которой входят
студенты, наверняка возникают серьезные проблемы с ведением документа-
ции.
Документация с описанием локального компьютера оказывается необхо-
димой во многих ситуациях. Заходили ли вы когда-нибудь в машинный зал,
до потолка забитый стойками с аппаратурой, разной и в то же время похожей
друг на друга как две капли воды, без единой надписи? А приходилось ли
вам устанавливать устройство, с которым вы раньше имели дело, но о котором
помните лишь то, что настраивать его было очень трудно? Или, может быть,
вы когда-нибудь тратили несколько дней на подгонку нового компьютера
под конкретные условия, обнаруживая затем, что в самом начале забыли
выполнить пару обязательных операций?
Внутреннюю документацию необходимо держать в определенном месте
(например, в каталоге /usr/local/doc). Некоторые документы лучше оформлять
на бумаге, в виде брошюр, а некоторые — в виде табличек, приклеиваемых
к устройствам.
На всех системных консолях должны быть прикреплены отпечатанные
инструкции с указанием имени компьютера, последовательности его загрузки,
архитектуры и специальных комбинаций клавиш, используемых для переза-
грузки (например, <L1+A>, <Cni+AIi+Del>). Имя компьютера должно быть
видно с другого конца комнаты. Совет насчет специальной комбинации
клавиш может выглядеть глупо, но на многих серверах мониторы украдены
и заменены старенькими терминалами. Поиск клавиши <L1> на терминале
VT100 может оказаться сложной задачей.
Таблички с именем компьютера нужно наклеить и на другие связанные
с ним устройства: дисководы, модемы, принтеры, ленточные накопители
и т.д. Если компьютер — очень важный объект (например, сервер или
центральный маршрутизатор), укажите, где находится его выключатель. Если
для начальной загрузки необходим гибкий диск или специальная карточка,
укажите, где они находятся. Ня файловом сервере необходимо наклеить
перечень имен дисковых устройств, имен разделов, точек монтирования,
адреса резервных суперблоков.
Для накопителей на лентах требуется указывать сведения о файлах
устройств и командах, необходимых для доступа к ним. Лучшее место для
этой информации — сам накопитель. Рекомендуем указывать тип лент, с
которыми работает накопитель, ближайшее место, где их можно найти, и
цену
На принтерах нужно указывать их имена, краткие инструкции по печати
и имена компьютеров, с которыми они работают (если таковые имеются).
Сейчас принтеры уже начали поставляться с сетевыми интерфейсами и скоро
станут полноправными гражданами сети.
Наиболее тщательно необходимо документировать схему сети. Следует
пометить все кабели, обозначить коммутационные панели и розетки,
промаркировать сетевые устройства. Не мешайте электромонтерам вносить
коррективы в документацию. В монтажном шкафу повесьте карандаш и
бланки, чтобы техник смог сразу же зафиксировать, например, что кабель
Глово 27. Стротегия и политике одминистрировония

перекинут с одного устройства на другое. Зарегистрированные таким образом
изменения можно перенести в память компьютера позже.
Центральный пункт, где собраны сведения о состоянии компьютера, —
файл diary, в котором документируются основные события его жизни
(расширения, ремонт аппаратной части, инсталляция основных программ и
т.д.). Можно создать псевдоним электронной почты, указывающий на этот
файл; тогда его копии будут рассылаться всем администраторам. Это наиболее
безболезненный и наименее организованный способ ведения записей.
Рекомендуем составить печатный документ, который можно выдавать
новым пользователям. В нем следует изложить местные правила, порядок
уведомления о неисправностях, имена и адреса принтеров, график резервного
копирования и отключения и т.д. Такой документ позволит администратору
сэкономить массу времени. Эту информацию можно распространять и через
Web-сервер.
Помимо этого своеобразного введения в локальную среду, в университетах
важную роль играют инструкции с наиболее распространенными пользова-
тельскими командами, поскольку в таких средах пользователи часто меняются
и не обладают достаточными знаниями по UNIX-системам. Мы применяем
одностраничные информационные листки о редакторе vi. системе mail,
телеконференциях, входе и выходе из системы, Х-среде и порядке исполь-
зования man-страниц.
27.11.	Закупка оборудования
Во многих организациях команда системных администраторов и команда
снабженцев полностью разделены. Это плохо.
Администраторам нужно знать, какая техника заказывается, иначе они
не смогут решить, впишется ли она в имеющуюся инфраструктуру. Админи-
страторы должны иметь возможность участвовать в составлении специфика-
ций, прилагаемых к заказам, потому что они могут сообщить полезные
сведения о надежности оборудования и его поставщиках.
Участие системного администратора в решении таких вопросов особенно
важно в организациях, которые должны покупать технику по минимальным
ценам (это. например, правительственные учреждения и государственные
университеты). В большинстве случаев при закупке можно предварительно
указывать критерии соответствия предлагаемых изделий предъявляемым
требованиям.
Эффект при подключении дополнительной рабочей станции зависит от
многих факторов. Какая она по архитектуре — шестидесятая или первая?
Достаточно ли места на ее диске для системных файлов? Имеется ли
свободный сетевой порт? Будет ли она размещена в той части здания, где
ее можно будет легко подключить к сети? Насколько отличается ее ОС от
уже используемых в организации?
Такие вопросы обычно связаны с более фундаментальным вопросом:
останетесь ли вы консерватором и купите оборудование у постоянного,
стабильно работающего поставщика или же попробуете взять свежайшую
штучку у фирмы-новичка, которая может потрясти весь мир. а может и
обанкротиться? Здесь ответ зависит от того, в какой организации вы работаете
Это не просто “да” или “нет”; часто речь идет о сложном выборе между
новейшей техникой и компьютерами, которые вы хорошо понимаете и
чувствуете.
852
Чость III Розное
Если есть возможность поговорить с поставщиками (официально или по
другим каналам), системный администратор может добиться более выгодных
условий, чем отдел снабжения. Не стесняйтесь называть ценк на аналогичное
оборудование других поставщиков или завышать объемы закупок, ожидаемых
в следующем году. Способность быстро и выгодно разместить заказ играет
большую роль в такие критические моменты, как конец квартала и конец
года. Если заказ делается в последнюю неделю июня, можно надеяться на
значительную дополнительную скидку, Еше один выгодный период для
заключения сделок — непосредственно перед появлением на рынке новых
моделей (продавцы стремятся побыстрее сбыть залежи старых товаров). Такой
тактики придерживаются, в частности, университеты, а в фирмах и государ-
ственных учреждениях все зависит от конкретной ситуации.
27.12.	Списание оборудования
Списание компьютера — весьма болезненная процедура. Упрямые
пользователи не желают расставаться со своими “любимцами”, зная, что им
придется изучать новую систему и переходить на новые прикладные
программы. Руководители некоторых фирм убеждают себя, что новая система
им не по карману, и принуждают сотрудников работать на старой. Обычно
это заканчивается тем, что понапрасну тратится такая сумма денег, которой
хватило бы не на одну новую систему. Старый компьютер VAX ежемесячно
потребляет электроэнергии на сумму, превышающую его ликвидационную
стоимость, но попробуйте заставить пользователей смириться с его отключе-
нием!
В университетах аналогичная проблема связана с пожертвованиями,
которые делают предприятия с целью уменьшения налогов. Во многих случаях
правильнее сказать: “Нет, спасибо, нам не нужны ни две тысячи девятидо-
рожечных лент, ни стеллажи для их хранения". Одному университету в
Будапеште недавно предложили мэйнфрейм IBM. Вместо того чтобы сказать
"нет” и купить быстродействующие персональные компьютеры, они взяли
эту машину и к настоящему времени потратили только на доставку и
прокладку электропроводки сумму, превышающую весь их годовой бюджет.
Стоит только производительности аппаратуры возрасти, как программное
обеспечение начинает тянуть ее вниз — увеличиваются его объем и слож-
ность. После инсталляции новых программных средств старая техника
работает медленно, иногда до невозможности. Мы превратили свои старые
рабочие станции в Х-терминалы. загрузив специально настроенное для этой
цели ядро. Машина Sun 3/50 с 4 Мбайт ОЗУ в роли автономной станции,
работающей с современными UNIX-программами, вряд ли сможет даже
загрузиться, но вот в паре с 19-дюймовым монитором из нее получится
отличный Х-терминал.
Поскольку пользователи и руководители с неохотой соглашаются сдавать
устаревшее оборудование в утиль, иногда системному администратору при-
ходится самому проявлять инициативу. Самое убедительное доказательство —
финансовая информация. Если вы сможете продемонстрировать на бумаге,
что затраты на эксплуатацию старого оборудования превышают затраты на
его замену, многие возражения будут сняты.
Переход с одной системы на другую можно упростить, если держать оба
компьютера в рабочем состоянии. Оставьте питание старой системы вклю-
ченным. но уменьшите объем административного сопровождения. Можно
прекратить обслуживание ее аппаратной части — пусть хромает, пока не
Глово 27. Стротвгия и политике администрирования
853
умрет сама собой. Пользователей можно соблазнить разными приманками:
повышенной производительностью, программным обеспечением нового по-
коления н тл.
Даже очень старому компьютеру можно найти применение — например,
в качестве сервера печати или “гостевой” станиии. Если ваша организация —
коммерческая, рассмотрите вопрос о передаче старой техники университету
или школе (“Алло! Не хотели бы вы получить даром две тысячи девятидо-
рожечных лент и стеллажи для их хранения?”). Если ничего не получается,
придется подумать о методах созидательной ликвидации. Например, списан-
ная машина Pyramid Р90Х превратилась в отличную связку железок,
привязанную к автомобилю нашего главного администратора в день его
свадьбы. Очень эффектное применение. Мы видели н другой вариант
утилизации — на ежегодном конкурсе по бросанию яиц (сырое яйцо
упаковывается так, чтобы при бросании из окна восьмого этажа оно осталось
целым).
Остатки компьютерного оборудования мы продали с аукциона студентам
нашего местного отделения Association for Computer Machinery, профессио-
нального сообщества компьютерных наук. Студентам не разрешалось распла-
чиваться деньгами, а только жетонами стоимостью в два часа их труда. Оии
должны были отработать в лабораториях или классах новичков в той области,
которую изучали. На нашем факультете компьютерных наук к этому
привыкли, но на других факультетах очень удивляются, когда появляются
наши студенты и объявляют, что они должны 10 часов помогать ступсным-
первокурсникам в лаборатории. Для такой системы нужен хорошим аукцио-
нист. Мы надеемся переманить к нам Роба Колсада из LISA.
27.13.	Патенты на программное обеспечение
С некоторых пор началось вторжение в компьютерную промышленность
патентов на программное обеспечение. Этот вопрос в принципе не имеет
отношения к системному администрированию, но мы все-таки затронем его.
Сначала бюро патентов установило, что нельзя ^патентовать математи-
ческую теорему. Затем теорема стала алгоритмом, но запатентовать алгоритм
также было нельзя. Алгоритм был реализован в аппаратуре, которую
патентовать разрешили. Встроенные программы запатентовать иногда удава-
лось, программное обеспечение — никогда. Однако правомерность отказа в
выдаче патента можно обжаловать, и один из судов низшей инстанции
прямо-таки полюбил патенты на программное обеспечение. Бюро патентов
начало против своей воли выдавать их, в некоторых случаях на прикладные
программы, созданные 10—15 лет назад.
К сожалению, исторически сложилось так, что бюро патентов слабо
разбирается в положении дел, складывающемся в области программирования.
По этой причине оно выдало много неправильных (даже глупых) патентов.
На алгоритм сжатия данных Лемпеля-Зива выдано пять разных патентов.
Этот алгоритм был опубликован в одном математическом журнале, реализован
и распространен в составе Berkeley UNIX. Запатентованы идея header-файлов
для С-программ и концепция курсора. Запатентована технология вычитания,
предназначенная для решения проблемы 2000 года. Запатентован процесс
переноса изображения из памяти в экранное окно и использование операции
XOR для обработки накладывающихся окон. Запатентованы несколько
стандартов кодирования данных и принцип встраивания рекламного мате-
риала в пользовательский интерфейс. Недавно British Telecom оспаривала в

Чость III Розное
суде собственный патент, который, как они утверждали, должен был
защищать авторство гипертекстовых ссылок.
Во втором издании этой книги мы писали о патентах на программное
обеспечение и о наивности U.S. Patent and Trademark Office в отношении
программного обеспечения. Пять лет спустя эта тема все еще актуальна, но
в США появилось еще большее зло: патенты на деловые операции Выдаются
патенты на такие обычные действия, как извлечение учетной записи
пользователя из базы данных в случае, когда пользователь звонят в службу
поддержки. Компания Amazon.com получила патент на “технологию одного
щелчка”. Они получили юридическое предписание, требуюшее, чтобы Barnes
and Noble заставляли пользователей выполнять для получения книги минимум
два щелчка мышью'.
Сейчас бюро патентов пытается улучшить свою работу, но ущерб, кажется,
уже нанесен. Важной вехой во всей этой истории является отзыв в 1994 году
патента, принадлежавшего Compton’s new media, на извлечение данных,
хранящихся на CD-ROM. Некоторые аналитики считают, что он мог бы
охватить до 80% существующих CD-продуктов. В конечном счете 41
предпринятая указанной фирмой попытка получить патент не удалась.
В области программного обеспечения вообще очень трудно доказать
наличие изобретения или новой технологии Обычно это приходится решать
в суде.
Более подробную информацию о патентовании программных технологий
вы найдете в архивах Electronic Frontier Foundation по адресу www.eff.org. а
последние новости о патентовании — на узле Slashdot.otg
27.14.	Организации и конференции
Существует несколько групп поддержки ОС UNIX, как общего плана,
так и по различным версиям. Задача этих групп — помочь вам в контакт
с людьми, которые пользуются тем же программным обеспечением, что и
вы. Краткий перечень организаций и наша характеристика каждой из них
приведены в табл. 27.4. Существует также множество национальных и
региональных групп, которые в этой таблице отсутствуют. Многие из этих
организаций, вероятно, обидятся на то, что мы пользуемся словом UNIX, и
заявят, что относятся к приверженцам “открытых систем”.
Каждая организация издает свои информационные материалы и ежегодно
проводит одну-две конференции. USENIX устраивает одну общую конферен-
цию и несколько специализированных. UniForum, SUG и AUUG проводят
крупные коммерческие выставки с конференциями.
Проводятся также такие мероприятия, как Interop и UNIX Expo —
коммерческие выставки с небольшими техническими семинарами Выставка
Interop — заметное событие, а консультативные курсы Interop отличаются
высоким качеством, упор делается на сети, а не конкретно на ОС UNIX
Выставка Interop раньше проводилась ежегодно, и ее с нетерпением ждали
как технические специалисты, так н производители. Сейчас она проводится
пять раз в год (так сказать, бродячий сетевой цирк), а зарплата консультантов
сокращена вдвое.
Возможно, компания DoubleClick.net могла бы превзойти их. запатентовав двойной щелчок.
Глово 27. Стротегия и политике одминистрировония
355
Таблица 27-4. Организации, занимающиеся ОС UNIX
Название	URL	Комментарии
USENIX	www.usenix.org	Группа пользователей UNIX; занимается техни- ческими вопросами
SAGE	www.sage.org	Гильдия системных администраторов, связанная с USENIX; проводит ежегодные конференции LISA
SANS	www.Banfi.oig	Проводит конференции системных администра- торов и администраторов зашиты. Это менее техническая организация, чем SAGE, с акцентом на учебные пособия
EUROPEN	www.curopen.org	Объединяет национальные группы, но практи- чески прекращает функционирование. В настоя- щий момент действуют только NLUUG. DUUG, UKUUG и некоторые другие национальные группы
AUUG	www.auug.org.au	Австралийские пользователи UNIX, занимаю- щиеся техническими аспектами и менеджмен- том
SAGE-AU	www.sage-au.org.au	Австралийское подразделение SAGE, проводит ежегодные конференции в Оз
JUS	www.jus.org	Японские пользователи UNIX, занимающиеся техническими аспектами и менеджментом
SAGE: гильдия системных администраторов
SAGE, гильдия системных администраторов USENIX. — первая между-
народная организация системных администраторов. Она развивает и рекла-
мирует профессию системных администраторов, оказывая спонсорскую
помощь в проведении конференций и информационных программ. Подроб-
ную информацию о ее деятельности вы найдете по адресу www.sage.org.
В настоящее время SAGE прорабатывает вопросы сертификации. Она
планирует выработать процедуру сертификации системных администраторов,
включающую письменный экзамен и практикум. Это будет больше похоже
на сертификацию Cisco СС1Е (очень основательную как по части теории,
так и по части практики), нежели на сертификацию Microsoft MSCE (менее
тщательную, включающую только экзамены с выбором одного из нескольких
вариантов ответа).
Поскольку профессия системных администраторов охватывает разные
технические области и системы разных производителей. SAGE планирует
организовать несколько сертификаций Вероятно, они будут выдавать базовый
сертификат об общих знаниях и навыках. а также специализированные
сертификаты по разным темам и системам различных производителей. Детали
программы SAGE пока не проработаны. Последнюю информацию вы найдете
на узле www.usenix.org/sage.
Еще одна важная задача, над которой работает SAGE, — программа
помоши начинающим системным администраторам, которую могут оказывать
их более опытные коллеги. Преподаватели будут работать один на один с
учащимися раз или два в неделю. Проводится и более формальное обучение —
члены сообщества SAGE преподают в университетских классах. Эта группа
обменивается опытом и идеями через список почтовой рассылки sysadm-edu-
cation. Для того чтобы на него подписаться, отправьте сообщение по адресу
majordorno@maillist.peak.org и включите в него текст “subscribe sysadm-education”.
836
Чость III. Розное
Гильдия готовит один из разделов “‘.login:”, бюллетеня USENIX; раздел
содержит новости, интересующие администраторов систем UNIX, советы,
обзоры и объявления. Гильдия SAGE выпустила также серию кратких
тематических дешевых буклетов (5 долл, для членов гильдии и 10 долл, для
всех остальных). Вот текущий список:
•	Job Description for System Administrators, редактор Tina Darmohray;
•	A Guide to Developing Computing Policy Documents, редактор Barbara Dijker;
•	System Security: A management perspective, David Oppenheimer;
•	Educating and Training System Administrators: A Survey, David Kune icky и
Bruce Wynn;
•	Hiring System Administrators, Gretchen Philips;
•	A System Administrator's Guide to Site Audits. Geofl' Halprin;
•	System and Network Administration for Higher Reliability. John Seilens;
•	Role of Postmaster, Rose Chalup*.
Последние три брошюры вышли только в 2000 году, и еше несколько
планируется: Effective Customer Support. Monitoring Techniques and Practices и The
Role of Web Master.
Вместе c USENIX, своей родительской организацией, SAGE каждую осень
устраивает конференцию LISA. Проводимая USEN1X/SAGE конференция
L1SA — самое масштабное, самое лучшее, самое “техническое" и самое
конкретное из всех подобных мероприятии. Она проводится каждую осень,
обычно в Калифорнии. Ее программа, как правило, включает в себя
трехдневный семинар и три дня технических совещаний, переговоров и
консультаций. Параллельно работают однодневные семинары по разным
специализированным вопросам. Получить информацию об этой конференции
можно по электронной почте (conference@usenix.org) или на узле
www.usenix.org.
Помимо общенациональной группы SAGE, сформированы несколько
региональных групп, задача которых — оказывать администраторам помощь
в регулярных контактах со своими коллегами. В настоящее время существует
группа SAGE-AU в Австралии, SAGE-WISE в Уэльсе, Ирландии, Шотландии
и Англии и SAGE-PT в Португалии. Контактную информацию этих
региональных групп можно найти по адресу www.usenix.org/sage/iocals.
Списки рассылки и Web-ресурсы
Существуют многочисленные списки рассылки для администраторов
различных систем.
Для подписки на Sun Managers отправьте письмо по адресу major-
& donio@sunmanagers.ececs.uc.edu. включив в него текст “subscribe sun-managers".
Архивы здесь ведутся с 1991 года, они доступны по адресу www.latech.edu/sun-
man.html. Соответствующие группы новостей Usenet называются
comp.sys.sun.adnun и conip.unix.Solaris.
yi Одно время существовал список hpux-admin, но похоже, он умер где-то
в 1998 году. Его замена имеется по адресу www.egonips.com.
ь	За информацией о списках рассылки, связанных с Linux, обратитесь по
• адресу www.redhat.com/mailing-lists. Можно подписаться прямо через Web.
Списки называются Linux-xxx. К сожалению. ни один из них не адресован
непосредственно системным администраторам.
Название этого документа могло измениться. В койне 2000 года он еще не вышел.
Глово 27 Стротегия и политике одминистрмровония
857
Информацию о списках рассылки, связанных с FreeBSD, можно найти
по адресу www,freebsd.org/handbook/eresources.htnil. Для подписки на любой
из них нужно отправить сообщение “subscribe ххх” по адресу major-
domo@freebsd.org. К сожалению, ни один из них не адресован непосредст-
венно системным администраторам, но в списках freebsd-questions,
freebsd.stable и freebsd-security можно найти много полезного.
Для системных администраторов имеется масса ресурсов. Полезные
ссылки вы найдете на Web-страницах SAGE. Несколько наших любимых
адресов приведены в табл. 27.5.
Тоблицо 27.5. Web-ресурсы для одминистроторов
Сойт	Содержимое
freshmeat.com	Огромное собрание программного обеспечения для Linux
www.ugu.com	Unix Guru Universe, все для системных администраторов
www.stokcly.com	Хорошее собрание ссылок иа все, что необходимо системным администраторам
www.tucoes.com	Программное обеспечение для Windows и Мас, отобрано наиболее качественное
Slashdor.org	Новости для любознательных
securityfocus.com	Информация, касающаяся безопасности; огромная, но уязви- мая база данных
google.com	Быстрый интеллектуальный поиск, особенно полезен для технического персонала
www.oreilly.com	Книги, немного коммерции и кое-что полезное
Литература
Лучшими печатными ресурсами для администраторов UNIX являются
книги издательства O'Reilly Серия начинается с книги “UNIX in a Nutshell'’,
вышедшей более 20 лет назад, и сейчас включает книги практически по всем
важнейшим подсистемам и командам UNIX. Кроме того, в этом издательстве
выходят книги. посвященные Internet, Windows NT и другим темам, не
связанным с UNIX. Они имеют разумную цену, вовремя выходят и очень
информативны Тим О'Рейли проводит ежегодные конференции, посвящен-
ные открытому программному коду, а также конференции на тему Peri, Java
и TOL/Tk. За дополнительной информацией обращайтесь по адресу
www.oreilly.com,
27.15. Стандарты
Стандартизация в одних случаях нам помогает (модемы разных произ-
водителей могут общаться друг с другом), а в других — вредит (протоколы
OSI — не более чем миллионы долларов, выброшенных на ветер). Комитеты
по стандартам не должны заниматься изобретательством.
Вообще-то задача стандартов состоит в том, чтобы предоставить пользо-
вателям возможность покупать совместимые продукты, созданные конкури-
рующими производителями. Некоторые организации, вовлеченные в процесс
стандартизации, просто систематизируют и документируют существующую
практику. Другие преследуют политические цели’ стремятся к победе нал
858
Чость III Розное
конкурентами или сокращению объемов работ по приведению собственной
продукции в соответствие с нормами.
Часто крупнейшими заказчиками стандартизированных систем и прило-
жений являются правительственные организации. Наличие стандартов позво-
ляет им не привязываться к конкретным производителям Однако крупные
компании могут по собственной воле замедлять процесс стандартизации в
ожидании, пока их продукты не закрепятся на рынке.
Существует несколько органов по стандартизации, как официальных, так
и неофициальных. В каждой из этих структур действуют свои правила приема
новых членов, голосования и работы. С точки зрения администратора системы
или сети самыми важными органами являются POSIX (Portable Operating
System Environment — Организация по переносимым операционным систе-
мам) и IETF (Internet Engineering Task Force — Инженерная комиссия
Internet). Рефераты новых стандартов публикуются в материалах телеконфе-
ренций comp.std.uiux и comp.org.usenix, а также в “Jogin:", бюллетене USENIX.
Организация POSIX, являющаяся ответвлением IEEE, последние несколь-
ко лет занимается выработкой единого стандарта на ОС UNIX. Повлияло ли
это на коммерческие версии UNIX? Да! Open Group, лицензировавшая
торговую марку UNIX, основывает свою спецификацию UNIX на стандарте
POSIX. Каждая система, вызывающая UNIX, теперь поддерживает интерфей-
сы POSIX. Кто-то может возразить, что теперь все стало значительно сложнее,
так как производители поддерживают и стандарты POSIX. и свои оригиналь-
ные интерфейсы, но в целом это неверно. Альтернативные интерфейсы
используются всего в нескольких доменах. К сожалению, P0S1X ничего не
говорит о том, что происходит на тех уровнях ОС, которые отданы на откуп
системным администраторам.
Документы POSIX доступны только в печатном виде. Их издает IEEF
Computer Society. В стандартах POSIX.I и POSIX.2 (теперь это стандарты ISO
9945-1 и 9945-2) описываются POSIX-версии системных вызовов и команд
UNIX. В настоящее время эти стандарты совместно пересматриваются ISO.
IEEE и Open Group, планирующими закончить эту работу в конце 2001 или
в начале 2002 года. После этого все три организации будут пользоваться
одним стандартом. Его законченная версия должна быть бесплатно доступна
через Web,
Консорциум Open Group, ранее называвшийся Х/Open. выработал
подмножество стандартов POSIX, названное Single UNIX Specification (SUS).
Этот процесс начался с анализа всех систем и приложений, которые захотели
контролировать члены консорциума. В результате было идентифицировано
1170 различных широко используемых интерфейсов (команд, утилит, систем-
ных вызовов и т.п.). В результате проект получил рабочее название Spec 1170.
Торговая марка UNIX первоначально принадлежала AT&T Bell Labs.
Затем она перешла к UNIX Systems Laboratories (дочерней компании AT&T),
затем к Novell и после этого к SCO. SCO предоставила безгонорарные
лицензионные права консорциуму Open Group. Если ваш продукт соответ-
ствует спецификации Single UNIX Specification и у вас достаточно денег,
можете назвать свое изделие “UNIX”. Специализированные лаборатории
проведут сертификацию. Документ, определяющий спецификацию Single
UNIX Specification, можно приобрести или загрузить по адресу www.open-
group.org/publications.
Посещаемость совещаний по стандартизации за последние несколько лет
упала, но только ие в IETF. Некоторые организации по стандартизации
(точнее, большинство из них) получают основной доход от продажи копий
Глово 27. Стротегия и политике сдминистрировония

стандартов не по 20 долл, (затраты на бумагу и тиражирование), а прибли-
зительно по 300 долл. Практически все стандарты пишутся добровольцами,
работа которых не оплачивается.
Консорциум Austin Group (Austin — это название города в штате Техас,
где впервые собрались его представители) состоит из организаций-участников
IEEE, ISO и Open Group. Он поддерживает Web-узел с рабочими документами
разных стандартов. Заинтересованных пользователей приглашают посещать
узел, загружать черновики и принимать участие в процессе стандартизации.
На этом узле нужно зарегистрироваться, но ои не будет присылать спам или
счета за- загруженные документы. Его адрес: www.opengroup.org/austin.
Группа пользователей USENIX финансирует участие одного своего
представителя в нескольких группах стандартизации. Его задача состоит не
в том, чтобы определять направление будущего стандарта, а скорее в
информировании пользователей UNIX о состоянии дел в области стандар-
тизации и препятствовании появлению лжестандартов. Представитель
USENIX собирает информацию, поступающую из многих источников, из
которых наиболее заметными являются так называемые осведомители
(snitches).
Осведомитель — это технический специалист, который посещает неко-
торое мероприятие и составляет о нем отчет. Такие отчеты ложатся в основу
материалов, публикуемых в журнале “Jogin:". Кроме того, эти отчеты
помогают понять, что предлагает стандарт и что в нем неправильно (или же.
что в нем хорошо!). Если вы активный участник процесса стандартизации и
технически компетентны, возможно, вы захотите быть осведомителем в своей
области. Говорят, обеды для осведомителей исключительно хороши.
27 16. Образцы документов
Некоторые упоминавшиеся в этой главе политические и процедурные
документы можно получить по адресу www.admin.com. Эти документы
описаны в табл. 27.6.
Таблица 27.6. Перечень документов, находящихся но www.odmin com
Документ	Содержание
ugrad. policy	Соглашение о правилах пользования компьютерной лабораторией для студентов-новичков
grad.policy	Соглашение о правилах пользования компьютерной лабораторией для выпускников и преподавательского состава
sysadmin, policy	Правила для системных администраторов
services	Сервисы CSOPS. политики и приоритеты
hiring.QBkl	Тесты для определения опыта работы
hirmg.quiz2	Тесты на знание вопросов администрирования
localization	Контрольный список для локализации
amanda	Контрольный список для резервного копирования с помощью Amanda
tep-wrappers	Контрольный список для установки ТСР-оболочек
860
Чость 111. Розное
27.17.	Рекомендуемая литература
•	Burgess, Mark “Cfengine: a site configuration engine.” USENIX Computing
Systems, Vol 8, No 3. 1995.
•	Burgess, Mark "Computer Immunology.” LISA, 1998.
•	Oetiker. Tobias '‘SEPP — Soflawre Installation and Sharing Svstem.” LISA.
1998.
•	San Diego Supercomputer Center. Local policies, standarts, and procedures.
http://security.sdsc.edu/helpSGs.shtml.
•	М.1.В.Н., Inc. “Acceptable Use Policy.” http://www.mibh.net/mibh-aup.html.
M.I.B.H. приобретена компанией Metromedia Fiber Network, но ее
документ AUP по-прежнему доступен и представляет собой хороший
пример строгих и действенных правил.
•	Eaton, David W. “comp.software.config-mgmt FAQ. part 3.”
http://www.iac.honeywell.com/Pub/Tech/CM/PMTools.html.
Этот документ содержит ответы на вопросы, связанные с системами
отслеживания проблем, включая и многие коммерческие системы о
которых мы даже не слышали. Он поддерживается как полагается, но
мы ие нашли в нем информации о наших любимых пакетах.
•	Harrow, Jeffrey R., and Compaq Computer Corporation “The Rapidly
Changing Face of Computing” (периодическое издание), http://www.com-
paq.eom/rcfoc.
Эти регулярно обновляемые Web-узлы содержат интересные статьи на
технологические темы.
Ггсво 27 Стротегия и политике сдминистрировония
861
Процессы-демоны
Операционная система UNIX — это гибкая и универсальная многозадач-
ная среда, но ее функциональные возможности заключены не только в ядре.
В системе имеется богатый набор демонов, отвечающих за ее жизнедеятель-
ность. Системные администраторы могут также инсталлировать дополнитель-
ные демоны, полученные из Internet, предоставленные производителями или
написанные пользователями.
Демон — это фоновый процесс, который выполняет системную задачу.
В полном соответствии с господствующим в UNIX принципом модульности
демоны являются программами, а не частями ядра. Многие демоны
запускаются во время начальной загрузки системы и продолжают работать
все время, пока система включена. Остальные демоны запускаются при
необходимости и работают столько, сколько предусмотрено их функциями.
Слово ‘демон” (daemon) впервые употребил в компьютерной практике
Мик Бейли (Mick Bailey), англичанин, который в начале 60-х гг. работал
программистом в Массачусетском технологическом институте. Для объясне-
ния смысла и правильного написания слова ‘daemon” Мик цитировал
Окфордский словарь английского языка.
Слова "daemon” и “demon” имеют общий корень, но первое — более
древнее, сохранившее первоначальное значение. Слово “daemon” дословно
означает “гений, дух-покровитель человека”. В этом смысле демоны являются
не воплощениями добра или зла, а независимыми существами со своими
собственными намерениями и желаниями .
Из системы CTSS, в работе над которой Бейли принимал участие, этот
термин перешел в МLillies, а затем и в UNIX, где демоны стали настолько
популярными, что для управления ими понадобился “супердемон “ (inetd)
В этой главе дан краткий обзор наиболее распространенных демонов. Не
все перечисленные здесь демоны поставляются со всеми версиями UNIX, и
не каждый демон, входящий в состав той или иной версии UNIX, здесь
упомянут. Прочитав о том, что делают все эти демоны, вы не только станете
Эту историю рассказал нам Деннис Ритчи со слов Джерри Зальцера из МТИ.
862
Чость III Розное
еще более квалифицированным специалистом по ОС UNIX, но и перестанете
бояться вопросов пользователей о том, что делает, например, демон xntpd.
До того как был напнеан демон inetd. все демоны запускались во время
начальной загрузки и работали непрерывно (точнее, блокировались в
ожидании работы) Со временем в систему вводились все новые и новые
демоны. Их появилось столько, что начали возникать проблемы с произво-
дительностью. В ответ специалисты университета Беркли разработали inetd —
демон, отвечающий за запуск других демонов по мере необходимости
Супердемон inetd стал таким популярным, что теперь его включают во все
основные версии UNIX, а большинство новых демонов работает под его
контролем.
Системные администраторы должны быть хорошо знакомы с целым рядом
демонов: либо потому, что они требуют много внимания администратора,
либо потому, что играют значительную роль в повседневной работе системы.
Многим демонам, которые здесь описаны одной-двумя строчками, посвящены
целые разделы в других главах этой книги. Там. где необходимо, мы даем
перекрестные ссылки.
В начале этой главы мы познакомим читателей с парой очень важных
системных демонов (init и сгоп), а затем перейдем к рассмотрению демона
inetd. Потом мы вкратце опишем большинство демонов, с которыми
системному администратору, скорее всего, придется столкнуться при работе
в четырех наших тестовых системах.
28.1.	Основные демоны
Демон init — это первый процесс, который запускается после начальной
загрузки системы, и во многих отношениях это самый важный демон. Он
всегда имеет идентификатор процесса 1 и является предком всех пользова-
тельских и почти всех системных процессов.
Во время начальной загрузки демон init либо переводит систему в
однопользовательский режим, либо порождает интерпретатор команд для
чтения стартовых сценариев. Когда система загружается в однопользователь-
ском режиме, демон init начинает читать стартовые сценарии после того, как
однопользовательский интерпретатор команд завершается нажатием клавиш
<Ctrl-D>.
После обработки файлов запуска демон init обращается к файлу
конфигурации (/ctc/ttytab, /etc/ttys или /etc/inittab, в зависимости от системы)
и получает оттуда список портов, через которые следует ожидать входа в
систему. Демон init активизирует эти порты и порождает для каждого из них
процесс getty’. Если порт открыть нельзя, демон init периодически выдает на
системную консоль сообщения, пока порт не будет открыт или удален из
списка активных портов.
0 Подробнее о портах TTY рассказывается в главе 7
В старых системах управление терминалыгыми портами было основной
задачей администраторов. Сегодня терминалы являются реликтами былой
эпохи. Пользователи регистрируются в системах по сети при помоши таких
демонов, как rlogind. telnetd и sshd.
Операционная система Solaris является исключением из правила (см. параграф 7.8).
Глово 28. Процессы-демоны
63
Демон init, кроме того, выполняет довольно неприятную задачу: изгоняет
еще живые процессы-зомби, которые скапливаются в системе. Роль демона
init в этом процессе описана в параграфе 4.2.
Останов системы осуществляется путем передачи демону init соответст-
вующего сигнала (обычно это SIGTERM), который заставляет его перевести
систему в однопользовательский режим. Это последняя операция в большин-
стве сценариев останова. Демон init играет настолько существенную роль в
работе системы, что в случае его зависания инициируется автоматическая
перезагрузка системы.
В большинстве современных систем демон init поддерживает различные
“уровни выполнения”, на которых его можно запускать. Уровни выполнения
определяют, какой набор системных ресурсов нужно задействовать. Обычно
есть семь или восемь уровней: от 0 до 6 плюс уровень “s” (однопользова-
тельский режим). Описания характеристик уровней выполнения содержатся
в файле /etc/inittab.
0 Подробнее о файле inittab рассказывается в параграфе 7.8.
Начальный уровень выполнения назначается (передается в виде аргумента
командной строки) демону init системным загрузчиком. Если задан уровень
“s”, демон init входит в однопользовательский режим. В противном случае
он находит в файле /etc/inittab записи, соответствующие указанному уровню,
и выполняет содержащиеся в них команды.
Для изменения уровня выполнения в процессе работы системы исполь-
зуется команда telinit. Например, команда telinit 4 заставляет демон init
перейти на уровень выполнения 4. Самый полезный аргумент команды
telinit — -q. который заставляет демон init повторно прочитать файл
/etc/inittab.
В тех системах, где стартовые сценарии хранятся в каталоге /etc/inii.ii и
имеют ссылки на каталоги /etc/rcX.d, перевод демона init на определенный
уровень вызывает выполнение сценариев из соответствующего каталога
(/etc/rcX.d, где X — новый уровень выполнения) с аргументом start
Сценарии, связанные со старым уровнем выполнения, выполняются с
аргументом stop. Это позволяет упорядочить запуск и останов системы. Более
подробное описание данного механизма приведено в параграфе 2.4.
LhL	Во FreeBSD демону init можно дать указание перечитать свой управляю-
щую ший файл. Для этого посылается сигнал отбоя (SIGHUP). Поскольку демон
init всегда имеет один и тот же идентификатор процесса, можно просто
выполнить команду kill -HUP 1. Не забудьте указать аргумент -HUP, иначе
система зависнет.
28.2.	Демон сгоп: планирование команд
Демой сгоп отвечает за выполнение команд по установленному графику.
Он обрабатывает файлы с расписанием задач (crontab-файлы), созданные как
пользователями, так и администраторами.
Демон стоп часто применяют в административных целях, например для
управления учетными и журнальными файлами и ежедневной чистки
файловой системы. Этот демон настолько важен для системных администра-
торов, что мы посвятили ему целую главу 9.
864
Чость III. Розное
28.3.	Демон inetd: управление демонами
Демон inetd управляет другими демонами. Он запускает демоны-клиенты,
когда для них есть работа, а после выполнения задачи позволяет им тихо
завершиться.
Демон inetd работает только с теми демонами, которые оказывают услуги
по сети. Для того чтобы установить, не пытается ли кто-нибудь получить
доступ к одному из его клиентов, демон inetd контролирует те редко
активизируемые сетевые порты, которые обслуживаются обычно бездельни-
чающими демонами. Когда устанавливается соединение, демон inetd запускает
соответствующий демон и соединяет каналы его стандартного ввода-вы вода
с сетевым портом. Это правило следует учитывать при написании демонов,
совместимых с inetd.
Работа некоторых демонов (например, тех, что связаны с NIS и NFS)
основана на протоколе RPC. который был разработан и реализован компанией
Sun в качестве механизма совместного использования информации в
распределенной сетевой среде. Назначениями портов для RPC-демонов
управляет демон porimap (иногда называется rpcbind).
Многие демоны могут использоваться либо традиционным способом (т.е.
они запускаются однократно и работают до выключения системы), либо под
контролем демона inetd. Далее в этой главе мы приняли следующее условное
обозначение: если демон совместим с демоном inetd. он помечен знаком ©
Конфигурирование демона inetd
Для того чтобы определить. какие сетевые порты нужно контролировать,
демон inetd читает файл конфигурации (обычно /etc/inetd.conf, а иногда
/usr/etc/inetd.conf или /etc/servers). Его формат одинаков для всех платформ.
Приведем пример:
ftp	stream	tcp	nowait	root	/usr/sbin/ftpa ftpd
telnet	stream	tcp	nowait	root	/usr/sbin/telnecd teinetd
shell	stream	tcp	nowait	root	/usr/stoin/rshd rshd
finger	stream	tcp	nowait	guest	/usr/sbin/fingerd fingerd
boocp	dgram	udp	wait	root	/usr/sbin/bootpd bootp -f
pop-2	stream	tcp	nowait	root	/usr/sbin/popper popper
pop-3	stream	tcp	nowait	root	/usr/sbin/popper popper
mountd/1	stream	rpc/tcp	wait	root	/use/sb^n/mountd mourtd
mountd/1	dgram	rpc/uap	wait	rOOL	/usr/sbin/mountd mountd
Первая колонка содержит имя сервиса. Эти имена преобразуются в
номера портов на основе данных, содержащихся в файле /etc/services (для
UDP- и TCP-сервисов) или демоном porimap (для RPC-сервисов). RPC-сер-
висы можно отличить по формату имени имя/номер и обозначению грс в
третьей колонке. В приведенном выше примере RPC-сервисы указаны в двух
последних строках.
Во второй колонке определяется тип сокета, которым будет пользоваться
сервис: stream или dgram. Сокеты типа stream используются с ТСР-сер-
висами (ориентированными на установление соединения), а сокеты типа
dgram — с UDP-сервнсамн
В третьей колонке указывается протокол обмена, которым пользуется
данный сервис. Допустимые типы перечислены в файле protocols (обычно он
находится в том же каталоге, что и файл конфигурации демона inetd) Почти
Глово 28 Процессы-демоны
865
всегда в этой колонке указывается тип tcp или udp. RPC-сервисы
предваряют тип протокола обозначением грс/ (см. в примере грс/tcp я
rpc/udp).
Если описываемый сервис может обрабатывать одновременно несколько
запросов (а не завершает выполнение после обработки одного запроса), в
четвертой колонке нужно ставить ключевое слово wait, которое не даст
демону inetd постоянно порождать новые экземпляры демона этого сервиса.
Данное средство применяется для сервисов, которые обрабатывают множество
мелких запросов. Если опция wait не подходит, то в этом поле нужно
поставить ключевое слово nowait.
В пятой колонке указан пользователь, от имени которого должен
выполняться данный демон. Если вы не доверяете той или иной программе
либо знаете, что она порождает проблемы, связанные с безопасностью
системы, можете выполнить ее от имени непривилегированного пользователя.
Естественно, это годится только для демонов, которые не требуют привилегий
пользователя root. В нашем примере демон fingerd выполняется с правами
пользователя guest.
В остальных полях даются полное путевое имя демона и аргументы его
командной строки. Первым аргументом всегда должно быть сокращенное
имя програхгмы. Это не особенность демона inetd, а традиционное для UNIX
соглашение. Пользователю обычно не приходится с этим сталкиваться,
поскольку все скрыто в интерпретаторе команд.
Файл services
После добавления нового сервиса в файл inetd.conf, возможно, понадо-
бится ввести его и в файл services. Этот файл обычно находится в том же
каталоге, что и файл inetd.conf, и используется несколькими стандартными
библиотечными функциями, которые преобразуют имена сервисов в номера
портов. Например, если ввести команду
% telnet anchor smtp
то в файле services будет произведен поиск номера порта, соответствующего
SMTP-сервису. В большинстве систем все самые распространенные сервисы
на момент поставки уже сконфигурированы. Если потребуется добавить еще
несколько сервисов, нужно будет просто отредактировать файл services.
Файл services используется только для сервисов TCP/IP. Аналогичная
информация для RPC-сервисов хранится в отдельном файле конфигурации
(обычно это /etc/rpc).
Ниже приведено несколько строк из файла services (размер которого
около 70 строк):
tcp	1/tcp	# TCP port multiplexer
echo	7/сер
echo	7/udp
smtp	25/tcp	ma il
time	37/tcp	timserver
time	37/udp	timserver
rip	39/udp	resource	#	resource location
name	42/tcp	# IEN 116
whois	43/tcp	nicname
866
Чость III. Розное
Формат строки таков:
имя	порт/тип	псевдонимы I комментарий
Сервисы в файле обычно упорядочены по номерам, но это не обязательно.
В поле имя указывается имя сервиса (которое используется в файле inetd.conf)
В поле порт значится номер порта, контролируемого сервисом. Если сервис
работает под управлением демона inetd. то это тот порт, который контроли-
руется демоном inetd’.
Поле тип обозначает протокол, которым пользуется данный сервис (на
практике это всегда tcp или udp) Если программа может работать и по
протоколу TCP, и по протоколу UDP, необходимо включить строку для
каждого из этих протоколов (как в записи для сервиса time; см. пример).
Поле псевдонимы содержит дополнительные имена сервиса (например, сервис
whois можно искать по имени nicname).
Перезапуск демона inetd
Изменения, внесенные в файл конфигурации, вступят в силу лишь после
того, как демону inetd будет дано указание перечитать файл Это делается
путем передачи этому демону сигнала отбоя. Послав сигнал, подождите
минуту и проверьте, нет ли в журнальных файлах сообщений об ошибках,
связанных с внесенными изменениями (демон inetd регистрирует ошибки в
системе Syslog). Можно попробовать связаться с новыми сервисами и
проверить, как они работают.
Подробнее о системе Syslog рассказывается в главе II.
Защита демона inetd
Делтон inetd отвечает за функционирование множества распространенных
сетевых сервисов, поэтому он играет важную роль с точки зрения безопас-
ности системы. Следует убедиться в том, что в файле inetd.cunf активизиро-
ваны только действительно необходимые и проверенные сервисы. В новой
системе почти наверняка придется отредактировать jtot файл, чтобы
отключить ненужные или нежелательные сервисы.
Но даже после этого рекомендуется дополнить демон inetd пакетом
TCP-оболочек, написанным Витсом Венема. Этот пакет регистрирует все
попытки установления соединений и ограничивает доступ к демонам в
зависимости от того, кто именно к ним обращается. Описание пакета
приведено в параграфе 21.7.
В HP-UX демон inetd имеет встроенные средства, напоминающие
TCP-оболочки. Демон проверяет файл /var/adm/inctd.scc и определяет, кому
разрешено подключаться к данному конкретноьу сервису. Если демон
запускается с флагом -I, он также регистрирует все запросы на установление
соединений. Инструкции, касающиеся конфигурирования средств зашиты
системы HP-UX. приведены в параграфе 21.7.
Номера портов назначаются не в произвольном порядке. Все компьютеры должны согла-
совать вопрос о том. какие сервисы за какими портами закрепляются. В противном случае
запросы будут постоянно идти не на те портье Создавая сервис специально для своей
системы, присвойте ему большой номер порта, которого еще нет в файле services.
Глово 28. Процессы-демоны
*67
28.4
Демон portmap/rpcbind: преобразование номеров
RPC-сервисов в номера портов TCP и UDP
Демон portmap (в настоящее время называется rpcbmd во многих
системах — спасибо компании Sun!) преобразует номера RPC-сервисов в
номера портов TCP/IP, которые контролируются их серверами Когда
запускается PRC-сервер, он регистрирует себя с помощью демона port-
map/rpcbind. указывая поддерживаемые сервисы, а также используемый порт.
Клиенты запрашивают демон portmap/rpcbind и выясняют, как связаться с
соответствующим сервером.
Такая схема позволяет устанавливать соответствие между номером порта
и символьным именем сервиса. Это уже принципиально иной уровень
абстракции, более высокий, чем используемый в файле services, но вместе с
ним появляются дополнительные сложности (и проблемы безопасности),
тогда как реальных проблем он не решает. Многие RPC-сервисы фактически
запускаются демоном inetd. Таким образом, создается не один, а два уровня
косвенного вызова программ
Если демон portmap/rpcbind зависает, все связанные с ним службы
(включая ieetd и NFS) должны перезапускаться. На практике это означает
перезагрузку системы. Для того чтобы демон inetd обрабатывал RPC-запросы
правильно, демон portmap должен быть запущен раньше, чем inetd.
Системные демоны
Ряд системных задач, например управление виртуальной памятью и
синхронизация дисковых кэш-буферов, находится в ведении демонов, а не
ядра. Системный администратор не может вмешиваться в работу этих
демонов.
Демон замещения страниц
Реализация данного демона и его функционирование зависят от конкрет-
ной системы. Он называется pageout в Solaris, vhand в HP-UX, kpiud в Red
Hat и pagedaemon во FreeBSD.
Этот демон является частью системы управления виртуальной памятью.
При обращении к странице виртуальной памяти система проверяет таблицу
и определяет, находится ли страница в данный момент в оперативной памяти.
Если ее там нет, то выдается сообщение об ошибке и вызывается демон
замещения, который переносит страницу в память из области подкачки. Если
свободных физических страниц нет, демон освобождает место, переписывая
какую-нибудь страницу в раздел подкачки и корректируя соответствующие
элементы таблицы страниц
Подробнее о виртуальной памяти рассказывается в параграфе 25.3.
Демон подкачки
Этот демон называется swapper во FreeBSD и HP-UX н kswapd в Linux
Когда одновременно работает много процессов, система тратит массу
времени на обработку ошибок, возникающих из-за отсутствия свободных
страниц, потому что каждый процесс использует определенное количество
страниц, к которым регулярно обращается. Такая перегрузка системы
управления виртуальной памятью серьезно ухудшает производительность
системы.
868
Чость III Розное
Демон подкачки контролирует количество вышеупомянутых ошибок,
которое прямо пропорционально числу обращений к памяти. Если ошибок
слишком много, демон начинает сбрасывать в область подкачки целые
процессы. Выгруженные процессы полностью удаляются из физической
памяти и не выполняются в течение сравнительно длительного времени
(порядка нескольких секунд). Демон подкачки продолжает удалять процессы
из оперативной памяти до тех пор, пока частота страничных ошибок не
упадет до приемлемого уровня.
Механизм подкачки был изобретен в те времена, когда оперативная
память была относительно дорогой Его полезность в современных компью-
терных системах сомнительна. Тем не менее он по-прежнему поддерживается
в большинстве систем
Демон синхронизации файловых систем
Демон синхронизации каждые 30 секунд выполняет системный вызов
sync, который инициирует запись на диск всех модифицированных дисковых
блоков, включая суперблоки файловых систем, таблицы индексных дескрип-
торов и буферизованные блоки данных’. Такая операция минимизирует
ущерб, наносимый крахом системы.
0 Подробнее о суперб.юках файловых систем рассказывается в параграфе 8.3.
В большинстве систем этот демон называется update, но в HP-UX он
носит имя syncer, а в Solans — ГчЛихЬ.
28.5. Демоны печати
Системы печати BSD и System V располагают собственными семействами
демонов, реализующими функции печати. Иногда семейства ‘‘скрещиваются"
друг с другом, а иногда работают параллельно в одной системе.
Ipd: управление печатью в BSD-сисгемах
Демон Ipd отвечает за механизм печати в BSD-системах. Он принимает
задания от пользователей и порождает процессы для выполнения реальных
операций печати. Кроме того, демон Ipd отвечает за пересылку заданий печати
в удаленные системы и получение заданий из них Иногда этот демон зависает
и требует ручного перезапуска.
0 Более подробное опис ание демона Ipd дано в параграфе 23.3.
Ipsched: управление печатью в АТТ-системах
Демон Ipsched — это АТТ-версия демона построчно-печатающего прин-
тера Он принимает задания из программы ip и ставит их в очередь на печать
Когда нужное устройство освобождается, демон Ipsched порождает процесс,
который управляет печатью.
0 Подробное описание демона Ipsched можно найти в параграфе 23.4.
Функция sync просто дает указание записывать эти блоки на диск, но не гарантирует. что
запись будет успешно завершена.
Глово 28 Процессы-демоны
869
ripdaemon: печать из BSD в HP-UX
Efl Демон ripdaemon позволяет демону Ipsched в HP-UX принимать запросы
на печать из систем BSD-типа. Подробно этот демон рассматривается в
параграфе 23.5.
28.6 Демоны NFS
Следующие демоны входят в состав сетевой файловой системы — NFS.
Здесь мы дадим лишь беглое описание их функций, а подробную информацию
можно найти в главе 17.
nfsd: файловый сервис
Демон nfsd работает на серверах и отвечает за обработку запросов,
поступающих от клиентов NFS. В некоторых системах он называется rpc.nbd .
В большинстве реализаций NFS демон nfsd является частью ядра,
“замаскированной” под процесс из соображений простоты планирования
У этого демона есть один аргумент — количество порождаемых экземпляров
самого себя. Правильно выбрать количество экземпляров довольно сложно
(см. параграф 17.2).
СТ mountd: ответы на запросы монтирования
Демон mountd (иногда называемый rpc.mountd) принимает от потенци-
альных клиентов NFS запросы на монтирование файловых систем. Он
отвечает за проверку наличия у каждого клиента разрешения на монтирование
заявленных каталогов. Для того чтобы выяснить, какие запросы правомочны,
демон mountd обращается к файлу /etc/exports.
amd и automount: монтирование файловых систем
по запросу
Программы amd и automount — это автоматические монтировщики NFS,
которые, прежде чем смонтировать файловую систему, ждут, когда процесс
попытается обратиться к ней Впоследствии, если к файловой системе не
было обращения в течение определенного промежутка времени, демоны
демонтируют ее.
Автоматические монтировщики очень удобны в крупных организациях,
когда десятки и сотни файловых систем совместно используются по сети.
Эти демоны повышают стабильность сети и уменьшают сложность ее
конфигурирования, так как все компьютеры в сети работают с одними и
теми же файлами конфигурации демонов. Подробнее об этих демонах
рассказывается в параграфах 17.6, 17.7 и 17.8.
lockd и statd: управление файлами блокировки NFS
Демоны lockd и statd (называемые также rpc.lockd и грс.statd) всегда
работают в паре. Демон lockd отвечает за блокировку файлов NFS. Демон
statd позволяет процессам контролировать состояние компьютеров, на кото-
рых работает NFS. Он используется демоном lockd для принятия решения о
Префикс “грс” означает, что данный демои использует протокол RPC.
870
Чость 111. Розное
0
28.7.
И
28.8.
том, когда следует произвести попытку установления связи с удаленным
компьютером.
biod: кэширование блоков NFS
Демон biod (называемый nfsiod во FreeBSD) отвечает за кэширование
запросов чтения и записи на машинах-клиентах NFS. Демон выполняет
буферизацию как с опережающим чтением, так и с отстающей записью, что
значительно повышает производительность сетевой файловой системы.
Подробнее о демоне biod рассказывается в параграфе 17.3.
Демоны NIS
Несколько демонов входят в состав систем управления административ-
ными базами данных NIS и NIS+. Службы N1S и N1S+ описаны в главе 18.
Несмотря на схожесть названий, это разные, не связанные друг с другом
системы.
ypbind: поиск серверов N1S
Демон ypbind работает на всех машинах-клиентах и серверах N1S. Он
отвечает за поиск сервера NIS. на который можно направлять запросы. Сам
демон не обрабатывает запросы, а просто сообщает клиентским программам,
к какому серверу обращаться.
ypserv: сервер NIS
Демон ypserv работает на всех серверах NIS. Демон ypserv принимает
запросы от маш ин-клиентов и отвечает на них. О конфигурировании систем,
в которых работает демон ypserv, рассказывается в параграфе 18.3.
ypxfrd: пересылка баз данных NIS
Демон ypxfrd пересылает базы данных NIS на подчиненные серверы.
Подчиненный сервер инициирует пересылку командой ypxfr. Как только база
данных на главном сервере изменилась, она должна быть немедленно
разослана на все подчиненные серверы.
rpc.nisd: сервер NIS+
Демон rpc.nisd — это коллега демона ypserv. Он должен работать на всех
серверах NIS+. При вызове с опцией -В демон rpc.nisd автоматически
порождает процесс rpc.tiisdresolv, который позволяет пользоваться службой
DNS через систему NIS+.
Служба DNS описывается в главе 16.
Демоны Internet
Мы определяем категорию "демоны Internet” очень свободно, подразу-
мевая демоны, которые для обработки запросов пользуются Internet-прото-
колами. В реальности большинство демонов Internet основную часть времени
тратят на обслуживание локальных запросов.
Глово 28. Процессы-демоны
71
Ф talkd: сервер программы talk
Декгон talkd обрабатывает запросы на установление соединений, посту-
паю шие из программы talk. Получив запрос, демон talkd согласовывает с
другим компьютером порядок установления сетевого соединения между двумя
пользователями, выполняющими программу talk.
Существуют две разновидности программы talk: первоначальная
(порт 517) и новая, из версии 4.3BSD (ntalk, порт 518). Программа ntalk не
совместима с предыдущими версиями и не принимает запросы на установ-
ление соединений от клиентов talk. Хотя система 4.3BSD была выпушена в
1986 г., многие системы до сих пор используют старую версию программы
talk (15 лет спустя!).
ф comsat: уведомление пользователей о наступлении почты
Демон comsat отвечает за уведомление пользователей о поступлении новой
почты. Получив сообщение о наличии для пользователя новой почты и
убедившись в том. что файл /etc/utmp подтверждает факт регистрации этого
пользователя в системе, демон cumsat проверяет, разрешено ли уведомлять
его о наличии почты командой biff у". Если разрешение имеется, демон comsat
отображает начало почтового сообщения на терминале пользователя. В на-
стоящее время большинство пользователей читает почту на персональных
компьютерах с помощью почтовых клиентов, работающих по протоколу IMAP
или POP. Программа comsat не имеет к этому никакого отношения.
sendmail: транспортировка электронной почты
Задачи программы sendmail включают прием сообщений от пользователей
и удаленных компьютеров, подстановку адресов, раскрытие псевдонимов и
пересылку почты по сети Internet. Это очень важный и очень сложный демон.
Подробно он рассматривается в глазе 19.
snmpd: сервер удаленного управления сетями
Демон snmpd отвечает на запросы, посылаемые по протоколу SNMP. Этот
протокол разработан с целью стандартизации некоторых общих операций
управления сетями. Он описан в параграфе 20.7.
rv/hod: ведение списка удаленных пользователей
Демон rwhod — это пережиток прошлого (80-е гг). Он собирает
информацию о пользователях, зарепчстрировавшихся на, компьютерах сети
Демон принимает информацию на локальной системе и осуществляет
широковещательную рассылку данных. Получая информацию с других
компьютеров, демон проверяет ее достоверность, а затем помешает в файл
/usr/spool/rwho.имякомпьютера. где последний компонент — имя компьютера.
Считается, что название “biff” расшифровывается как “bark if from found” (гавкни, если
пришла почта). На самом деле так звали собаку Хайди Штетгнер (Heidi Stettner), которая
всегда лаяла при появлении почтальона. Как рассказал Керк Маккузик, программы comsat
и biff написал Билл Джой, когда Хайди Штетгнер пришла к нему и сказала: “Моя собака
лает при появлении почтальона. Почему я не могу получить такую же функцию оч
электронной почты?” Название “comsat" расшифровывается как “communication satellite”
(спутник связи).
В 72
Чость III. Розное
пославшего данную информацию. Этой информацией пользуются программы
rwho и niptinie.
По умолчанию демон rwhod осуществляет широковещательную передачу
каждые три минуты. поэтому информация, которую сообщают программы
rwho и niptime, верна лишь приблизительно. Демон rwhod работает крайне
неэффективно, поэтому, если не хотите ухудшить пропускную способность
сети, его лучше выключить.
ф ftpd: сервер пересылки файлов
Демон ftpd обрабатывает запросы, поступающие из программы ftp. Во
многих организациях этот демон отключен — либо потому, что без толку
“пожирает” ресурсы, либо по соображениям безопасности. Демон ftpd может
быть настроен так, чтобы все пользователи имели право пересылать файлы
в систему и копировать файлы из нее.
Подробнее о демоне ftpd рассказывается в параграфе 22.6.
Ф popper: простейший сервер почтового ящика
Демон popper реализует протокол POP. Этот протокол используется в
не-UNIX-системах для приема электронной почты.
Ф imapd: высококлассный сервер почтового ящика
Демон imapd реализует протокол IMAP, являющийся более мошной
альтернативой протоколу POP. Демон позволяет пользователям персональных
компьютеров (или UNIX-пользователям, которые работают с почтовыми
клиентами, поддерживающими протокол IMAP) получать доступ к своим
почтовым папкам, хранящимся на UNIX-сервере, из самых разных мест.
ф rlogind: сервер удаленной регистрации
Демон rlogind отвечает за удаленную регистрацию в системе. Будучи
вызванным из демона inetd, он пытается автоматически аутентифицировать
удаленного пользователя, исследуя содержимое файла /etc/hosts.equiv и
пользовательского файла '/.rhosts. Если аутентификация проведена успешно,
пользователь входит в систему непосредственно. В противном случае демон
rlogind выполняет программу login, которая запрашивает у пользователя
пароль. Из-за упрошенной схемы аутентификации демон rlogind считается
небезопасным. Подробнее об этом говорится в параграфе 21.6.
Ф telnetd: еще один сервер удаленной регистрации
Демон telnetd напоминает демон rlogind, но пользуется протоколом
TELNET. Этот протокол позволяет двум компьютерам (клиент)' и серверу)
согласовывать порядок управления потоком данных и работу в дуплексном
режиме. Для низкоскоростных и малонадежных каналов передачи это более
предпочтительный выбор, нежели демон rlogind. Программа telnet передает
пароли в незашифрованном виде по сети, поэтому использовать ее не
рекомендуется. Программа telnet поддерживается не только в UNIX-системах
Глово 28. Процессы-демоны
873
CD sshd: безопосный сервер удаленной регистрации
Демон sshd функционирует подобно демону rlogind, но все данные (в том
числе аутентификационные) передаются через зашифрованный канал. Под-
держивается множество алгоритмов шифрования. В связи с тем что совре-
менная среда Internet весьма небезопасна, доступ в систему через Internet
необходимо разрешать только этому демону, а демонам rlogind и telnetd —
запрещать. Подробнее о демоне sshd рассказывалось в параграфе 21.8.
Ф rshd: сервер удаленного выполнения команд
Демон rshd обрабатывает запросы на удаленное выполнение команд,
поступающие из программ rsh* и remd Процесс аутентификации, инициируемый
этим демоном, напоминает действия демона rlogind, за одним исключением:
если автоматическая аутентификация не срабатывает, запрос отклоняется без
предоставления пользователю возможности указать пароль. Демон rshd — это,
помимо всего прочего, еше и сервер для программы удаленного копирования
гср.
(D rexecd: еще один сервер удаленного выполнения команд
Демон rexecd напоминает демон rshd. но ие выполняет автоматическую
аутентификацию. Все запросы должны сопровождаться именем пользователя
и паролем. Этот сервер использовался в первых сетевых программах, а затем
вышел из широкого употребления.
(D грс. rexd: третий сервер удаленного выполнения команд
Программа rexd — демон протокола RPC. Она применяется не часто и
изобилует просчетами, чреватыми нарушением безопасности. В файле кон-
фигурации демона inetd строку запуска программы rexd следует превратить в
комментарий. Демон rexd используется командой ив. которая перестанет
работать, если его отключить.
routed: ведение таблиц маршрутизоции
Демон routed ведет таблицы маршрутизации, используемые стеком
протоколов TCP/IP для передачи пакетов по сети. Демон routed занимается
только динамической маршрутизацией; статически заданные маршруты (т.е.
назначаемые командой route) не модифицируются Демон routed довольно
прост и неэффективен, поэтому мы рекомендуем пользоваться им только в
особых случаях. Подробнее о нем рассказывается в параграфе 14.4.
gated: ведение сложных таблиц маршрутизации
Демон gated понимает несколько протоколов маршрутизации, в том числе
и RIP, который используется демоном routed. Демон gated служит перево-
дчиком данных маршрутизации на языки разных протоколов и отличается
большой гибкостью. Он, кроме того, гораздо дружественнее относится к
сетям, чем демон routed. Подробнее о демоне gated рассказывается в
параграфе 14.5.
Называется remsh в HP-UX.
874
Чость ill. Розное
(Г named: сервер DNS
Демон named — самый популярный сервер доменной системы имен
(DNS). Он преобразует имена компьютеров в сетевые адреса и выполняет
много других функций, пользуясь распределенной базой данных, которую
ведут его коллеги в других системах. Подробная информация об этом демоне
приведена в главе 16.
syslogd: обработка сообщений об ошибках
Демон syslogd играет роль координирующего центра для сообщении об
ошибках, выдаваемых системными программами и демонами. До того как
была написана программа syslogd. демоны либо выдавали свои диагностиче-
ские сообщения прямо на системную консоль, либо вели собственные
журнальные файлы. Теперь они пересылают сообщения демону syslogd,
пользуясь библиотечной функцией syslog. Демон сортирует сообщения в
соответствии с правилами, заданными системным администратором.
Подробно о системе Syslog рассказывается в главе П
Ф fingerd: поиск пользователей
Демон fingerd предоставляет информацию о пользователях, зарегистриро-
вавшихся в системе. При необходимости он может сообщить более подробные
сведения об отдельных пользователях. Работы у него немного: демон fingerd
просто принимает вводимые строки и передает их в локальную программу
finger.
Среди прочей информации о пользователе программа finger выдает его
регистрационные данные, содержимое поля GECOS в файле /etc/passwd, а
также содержимое пользовательских файлов '/.plan и '/.project.
Если система подключена к Internet, информацию, выдаваемую програм-
мой finger, может получить кто угодно. Демон fingerd оказывает ряд весьма
полезных услуг (например, осуществляет поиск в “белых страницах" Internet),
но бессовестные личности пользуются им в своих корыстных интересах.
Некоторые организации в целях предотвращения злоупотреблений отключают
демон fingerd, а некоторые просто ограничивают объем выдаваемой им
информации. Если вы решили оставить демон fingerd, инсталлируйте текущую
его версию, потому что старые версии плохо соблюдают правила безопасно-
сти, чем в свое время успешно воспользовался знаменитый вирус-“червь”.
® httpd: сервер World Wide Web
Демон httpd позволяет текущему узлу стать сервером гипертекстовых
документов всемирной паутины. Демон httpd может посылать своим клиентам
текст, изображения и звук Подробнее о работе с Web-стран инам и расска
зывалось в главе 22.
28 9. Демоны синхронизации времени
По мере того как сети все сильнее опутывали компьютерные системы,
становилась все более очевидной необходимость согласовывать на разных
компьютерах представление о текущем времени. Таймеры синхронизации
важны для сопоставления записей в журнальных файлах при обнаружении
Ггово 28. Процессы-демоны
875
“пробоя” в системе защиты. Они также используются во множестве
прикладных программ.
timed: синхронизация часов
Существует целый ряд систем синхронизации времени, и имя timed носят
несколько демонов. В большинстве систем используется практически одна и
та же схема. Один или несколько компьютеров назначаются главными.
Показания их часов считаются достоверными, и они согласовывают друг с
другом ’’точное” время. Остальные компьютеры — подчиненные; они перио-
дически запрашивают время у главного компьютера я соответствующим
образом регулируют свои внутренние часы.
Промежуток времени между процедурами установки часов подчиненного
компьютера достаточно мал, поэтому обычно нужна лишь незначительная их
корректировка. Используя системный вызов adjtime (если он есть), подчи-
ненные компьютеры сглаживают последствия корректировки системных
часов". Особенно нежелательной операцией является внезапный перевод часов
назад: время должно быть монотонно возрастающей функцией.
Понятие “точное время” весьма туманно. Некоторые системы опраши-
вают сеть и определяют среднее значение времени, а некоторые волевым
решением объявляют время главного компьютера точным.
xntpd: более точная синхронизация часов
Программа xntpd — это демон, который, пользуясь протоколом NTP
(Network Time Protocol — протокол сетевого времени; RFC1I19), синхрони-
зирует ряд “равноправных” часов с точностью до миллисекунд. Синхрони-
зируемые серверы образуют иерархию, каждый уровень которой называется
слоем.
Демон xntpd имеет доступ к ряду вторичных эталонов времени, поэтому
он точнее устанавливает время на UNIX-системах, чем демон timed: часы не
только синхронизируются, но и точно идут. Текущую версию демона xntpd
можно получить по анонимному FTP-доступу на узле ftp.udel.edu.
28.10. Демоны начальной загрузки и конфигурирования
В 80-е гг. мир UNIX охватила мания внедрения бездисковых рабочих
станций. Эти компьютеры загружались по сети и выполняли все свои
дисковые операции средствами удаленных файловых систем, например NFS.
По мере падения цен на жесткие диски и повышения их быстродействия
интерес к бездисковым рабочим станциям быстро угас. О бездисковой эпохе
сейчас напоминает только плеяда демонов, предназначенных для поддержки
бездисковых компьютеров, и причудливая организация файловых систем
большинства производителей.
Несмотря на то что бездисковые рабочие станции практически вышли
из употребления, их протоколы загрузки все еше используются другими
устройствами. Большинство сетевых концентраторов и сетевых принтеров
загружается с помошъю той или иной комбинации демонов, описанных ниже.
Библиотечная функция яфШпе изменяет скорость хода часов системы так. чтобы коррек-
тировка была достаточно плавной. Когда системное время сравняется с текущим объектив-
ным временем, регулирование прекратится.
876
Чость III. Розное
©bootpd: сервер начальной загрузки
Когда бездисковый клиент включается, он передает в сеть запрос ВООТР.
Получив такой запрос, демон bootpd ишет Ethemet-адрес клиента в файле
/etc/bootptab. Найдя соответствующий элемент, он сообщает компьютеру его
IP-адрес и файл, из которого он должен загружаться (обычно файл
пересылается по протоколу TFTP). К физической пересылке файла начальной
загрузки демон bootpd отношения не имеет.
Ф tftpd: тривиальный сервер пересылки файлов
Демон tftpd реализует протокол пересылки файлов, похожий на тот, с
которым работает демон ftpd. но гораздо более простой. Многие бездисковые
системы пользуются протоколом TFTP для загрузки своих ядер с сервера.
Демон tftpd не выполняет аутентификацию, но обычно его функции
ограничены обслуживанием файлов в одном каталоге (чаще всего — /tftpboot).
Поскольку все материалы, помещаемые в каталог tftpboot, доступны для всей
сети, в этом каталоге должны находиться только файлы начальной загрузки
и отсутствовать разрешение на запись для всех пользователей.
rarpd: преобразование Ethernet-адресов в IP-адреса
Демон rarpd реализует протокол RARP, который позволяет бездисковым
компьютерам определять свои IP-адреса во время начальной загрузки. Демон
rarpd работает на сервере. Для каждого сетевого интерфейса, нуждающегося
в RARP-поддержке, при начальной загрузке запускается один экземпляр этого
демона. Демон rarpd определяет необходимые соответствия, обращаясь к
файлам /etc/ethers и /etc/hosta, поэтому отдельный файл конфигурации не
нужен. Протокол RARP — это подмножество протокола ВООТР, но выбор
протокола зависит от имеющегося набора аппаратных средств.
© bootparamd: усовершенствованная
поддержка бездисковой работы
Используя файл /etc/bootparams, демон bootparamd сообщает бездисковым
клиентам о том, где искать их файловые системы. Услугами демона bootparamd
часто пользуются компьютеры, которые получают свои IP-адреса по прото-
колу RARP и монтируют файловые системы с помощью NFS.
©dhepd: динамическое назначение адресов
Протокол DHCP позволяет персональным компьютерам, ноутбукам и
другим мобильным системам на этапе начальной загрузки получать инфор-
мацию о своих IP-адресах, стандартных шлюзах и сервере имен. Демон dhepd
реализует этот протокол в UNIX. О протоколе DHCP можно прочитать в
параграфе 13.7.
Глово 28. Процессы-демоны
877
Предметный указатель
Агент ретрансляции  ...................311
Адресное пространство, определение  ...64
Анализатор пакетов.—...................671
Б
База данных:
— termcap............................130
— term info........................  130
Безопасность.......................  687
—	источники информации..........  .715
—	основные правила.................688
— слабые места системы...............689
Беспроводная сеть..................  290
Бит:
- SG1D...........................56.	90, 694
- SUID..................... 56,	66, 90, 694
Брандмауэр..............   318, 712
— анализирующий......................714
- в HP-UX............................342
- в Red Hat.................... 348.	712
— в Solans...........................335
-- во FreeBSD.................. 356,	712
— консервативный.....................357
— сервисный..........................714
— фильтрация пакетов.................712
— фильтрация сервисов_______________ 713
в
Виртуальная частная сеть..............319
Волоконно-оптический канал............141
г
Главная загрузочная запись............36
Группа, идентификатор.................56
— эффективный.........................56,	66
Группы поддержки UNIX................855
д
Дамп памяти, определение.................68
Демон:
— замещения страниц.......... ..........868
— начальной загрузки...................-876
— определение...........................862
— печати................................869
— подкачки___________-................  868
— синхронизации времени —_____________  875
— синхронизации файловых	систем.......869
— aspppd................................336
— automountd............................532
- biod..............................527.	871
— bootparamd.............................877
- bootpd .................... 341,.	347. 877
— comsat ................................872
- cron......179, 184. 188, 229, 233, 247. 864
—	версия Vixie-cron................185
—	изменение crontab-файлов.........182
—	применение.......................182
—	файл cron.allow..................182
—	файл cron.deny...................182
—	файлы и каталоги.................185
—	формат сгогнаЬ-фаЙлов............180
-	dheped.............................  347
- dhepd........................311,	347. 877
—	dmispd.............................. 679
-	fingerd  ..................... 698.	875
-	-	fsflush............................869
— ftpd...........................  .732,	873
- gated..............338, 372-373, 389, 874
-	в HP-UX.........................388
—	в Red Hal...................... 388
—	во FreeBSD....................  388
—	конфигурирование протокола ICMP...384
—	конфигурирование протокола OSPF. .. 383
—	конфигурирование протокола RIP...380
—	начальный запуск................375
—	описание__________________      374
878
—	определение сетевых интерфейсов....377
—	параметры конфигурации............377
—	пример конфигурации...............386
—	приоритеты маршрутов..............379
—	статические маршруты—.............384
—	трассировка...................... 375
—	файл конфигурации.................376
—	флаг -1...........................376
—	экспортируемые маршруты...........385
— hlipd........................726-727, 875
— identd.......................~.........647
— imapd.............................569.	873
—	in Ipd..............................769
—	in. rd isc..........................388
- inetd......343, 438, 524, 545, 703, 862, 865
—	inetd: в HP-UX......................704
—	защита__________________________ 867
—	конфигурирование.............    865
—	опция -I........................ 704
—	перезапуск.......................867
—	init................................863
-	-	kerncid...........................  280
—	kflushd...............................33
-	klogd .............................. 238
—	kpiod........................   33,	868
-	- kswapd.......... .............  33.	868
—	kupdate.............................  33
— lockd.........................    515.	870
- Ipd...................... 743. 745, 778. 869
— конфигурирование.................  776
- Ipsched.......................757-759.	869
—	флаг -a..........................770
— mountd.......................519, 535, 870
—	в Red Hat........................524
—	во FreeBSD..................519.	525
- named......427. 429, 432. 438. 440. 446-448.
451, 462, 464. 465, 470, 473. 477, 480. 875
— безопасность.........484-485, 487, 489
—	журнал	транзакций...............448
—	журнальная регистрация..... 447, 493
—	запуск...........................438
— зонные	пересылки.—..............481
—	конфигурирование................ 438
—	начальное заполнение
кэша.........................430, 449, 503
—	начальный каталог................441
—	номер версии............... 426,	460
—	обновление зоны.............480.	483
—	отладка...................  492,	497
—	переадресация....................450
—	схема работы.....................432
—	уровни отладки...................497
—	флаг -d..........................497
—	флаг -g......................... 485
— флаг -t......................    485
— флаг -и..........................485
—	natd............................356
- nfsd........................    519.	870
—	описание......................525
—	опция	-а......................526
—	опция	-п......................526
—	опция	-I......................526
—	опция -и......................	526
- nfsiod..............................  527.	871
— опция -п...............................527
— pagedaemon..	... 33. 868
— pageout				868
— pccardd					51
— popper				873
— portmap			 518-519.	868
- PPPd			344,	360
— rarpd			309,	877
- rexd				697.	874
— rexccd 					697,	874
— rlogind			 543,	697, 873
- ripdaemon .... 				771.	870
— routed			331. 371, 389, 874
— В Red Hal			 388
в Solans.		 388
— во FreeBSD				388
описание			...373
— опция -q			371,	373-374, 388
— ОПНИЯ -s							373, 388
— опция -I..					  374
— rpc.lockd.....................................870
— rpc.mountd...............................519,	870
— rpc.nfed......................................519
—- rpc.nisd...................................  871
— rpc.rexd.....................................—	874
— rpc.staid.....................................870
—	rpebind........................-.............868
—	rquoled....................................  515
-	rshd.......................................  874
— rwhod...............................872
— sched.............................   33
— slapd....................  .........591
— smtpd...............................576
— smtplwdd............................576
— snmpd...............................872
— snmpdm..............................679
— snmpdx...________________________   679
snmpXdmid........................  679
- spop 			569.	608
— sshd			 466.	709. 874
— statd			515,	870
— swapper.				 33,	868
— syncer				869
879
- syslogd ...234, 24J-242, 245, 438. 875
—	в Red Hat..	........ - -237
-	во FreeBSD	238
—	константа MAXL NAMES	244
—	константа NLOGS	............ 244
—	конфигурирование.................234
—	опция -a ........................239
—	опция -h.........................238
-	опция -г......................... ... 238
—	опция	. ..239
—	флаг -d.... . _ ............... 244
— lalkd....................  ............. 872
— telnetd............................   873
-tftpd.........................  697, 877
— timed...............................  876
— update................................869
— vhand................................ 868
— Vixie-cron........................... 185
— xntpd........................... 73. 876
— ypbind	  871
—	ypserv..........................    87]
—	ypxfrd--------------------------   87]
Документация:
— команда man.................-..........25
—	общая организация...................24
— man-страницы...........................23
Домен:
— второго уровня........................424
— выбор имени...........................423
— географический........................420
определение  ....................... ..	419
— организационный...................... 420
— принципы управления..................—422
— создание поддоменов ...............   424
Драйвер устройства.....................87.	248
— добавление........................    270
—	в Linux...........................	273
—	в Solans....................... 272
—	во FreeBSD......................275
конфигурационные файлы...............272
— номер устройства......................271
ж
Жесткая ссылка .......  .	87
Жесткий диск:
— анализ использования ............  ...802
— запись метки во	FreeBSD ............177
— конструкция........... ...............148
— подключение.........................150,	161
- в HP-UX...........................166
— в Red Hat ........................170
в Solaris ..................... ...	161
во FreeBSD	 175
—	процедура инсталляции..	(50
—	разбивка на разделы...- —---------- 152
—	в Red Hat_____________________ |7|
—	в Solaris... ................  163
-	во FreeBSD.....................175
—	создание логических томов.........153
—	создание метки ....................152
— в Solans..........................163
—	форматирование .................  151
—	в Solans..................     163
—	низкоуровневое................ 167
3
Загрузка:
—	автоматическая.....................31
—	главная загрузочная	запись.........36
—	многопользовательский	режим ... ...34
— мультисистсмная...................38,	815
—	начальная......	 30
— однопользовательский режим 31, 40
-	в HP-UX..............-...........41
—	в Linux..............-..........—41
—	в Solaris.......................40
—	во FreeBSD..................... 42
—	персонального компьютера ........  35
— ручная ......—............ .......31,	33
—	этапы..............................31
Зомби ...........................   67,	73
Зона’
—	конфигурирование главного сервера..447
—	конфигурирование подчиненного
сервера............................ 448
—	обновление........................480
— динамическое............-.........482
—	определение..................     427
—	переадресация..	 450
—	создание..........................447
и
Идентификатор:
—	группы...................... ...56.	101
- в NFS............................. 516
— эффективный ........	.....56.	66
—	пользователя_______________ ...56.	100
- в NFS.............	....516
— эффективный ,..............  56,	65
— процесса............_..................65
— родительский........................65
Индексный дескриптор.....................9!
— определение...........................155
Интерпретатор команд:
— регистрационный.....	.102
- bash...............................   102
880
—	Bourne	shell.......................102
-	C shell...........................—J02
—	Korn shell.........................102
-	icsh...............................102
Интерфейс:
—	виртуальный........................727
-	в HP-UX.........................729
-	в Red Hat...................... 729
—	в Solans........................728
—	во FreeBSD......................730
—	и сервер Apache.................730
—	конфигурирование .............. 728
—	дисковый............................14)
— Fibre Channel..................... 141
- IDE...................140-141,	146. 148
- SCSI......................140-142.	148
- USB..............................  141
к
Канал, именованный.......................88
Каталог..................................86
—	для электронной почты................109
—	начальный ...........................102
— создание ..........................108
—	родительский .......................89
—	текущий (.).........................87
— lost+found...................156,	161, 184
Квоты, установка........................110
Класс регистрации...................103-104
Команда:
— accept..............................  763
- add_drv...........................273,	278
— агр:
— опция	-а.......................308
- bdf...................................169
— boot:
— опция	-а.......................252
—	bootOcfg..............................37
—	cancel............................  763
—	caiman...............................24
— опция	-w........................25
—	chflags..............................94
-	chfn................................102
-	chgrp	.	108. 212
—	описание.....................    95
—	флаг -R..........................95
—	chkconfig...........................48
—	chmod................................89
— описание —..........................94
— chown............................  108	. 229
—	описание.........................95
—	флаг -R..........................95
—	ebroot.............................733
— chsh....................................102
— clri.....................-..............161
— config......................... 258-261,	275
- cp:
— синтаксис.........................   87
— crontab ................................179
—	опция	-e.........................182
—	опция	-1.........................182
—	опция	-r.......................  182
—	опция	-u.........................182
— cu.................................  ...135
- dd.........................39, 152, 161. 187
- df......................................165
— опция -k............................156
— dhepinfo................................333
— disable...............................  764
— disk .................................  162
— dmesg.................................. 259
— drvconfig...........................162,	278
- dump...........160, 189-190, 209. 211-212. 222
—	описание.........................198
—	опция d........................—.201
—	опция б..........................201
—	сигнал конца ленты...............201
—	флаг и...........................200
—	echo.................................257
-	edquota..............................110
—	eeprom...............................123
—	enable...............................764
— exportfs:
— описание............................521
— опция -a........................519,	523
— опция	-u.........................519
— find:
— опция	-xdev.......................183
-	finger.............................. 698
- fsck........................... 34. 42-43, 53
— опция	-p..........................83
- fstat......................«,............84
— fuser:
—	опция	-c..........................83
—	опция	-f......................... 84
—	опция	-k......................    84
—	опция	-m.....................    .84
—	опция	-v..........................84
—	gdc..................................375
— опция	toggletrace...............376
—	grep..................................228
—	groupadd..............................112
—	groupdel..........................    112
—	groupmod..............................112
-	halt...................................53
—	опция	-n.........................53
—	опция	-q.........................S3
301
- hdf_____________________________________156
hostname_______....321
ключевое слово	down..—---------- 323
—	ключевое слово	plumb.	.........322
—	ключевое слово	up ...........  .323
—	опция -a...........................322
—	опция broadcast ...................323
опция netmask..................... 323
ifeonfig.......51, 294, 306, 325,328, 330, 332,
337-339, 346, 354, 365, 728-729
—	описание-------------------—..... 322
—	опция	-a................       .337
—	опция	alias................  ....730
—	опция	broadcast * ............ ..330
опция	delete....................730
опция netmask*..................—....330
— insmod.........................«......  278
— loscan.................................... 166
iostat_____________________...........__802
— опция -D.................«.........  803
- kill.................................... 54
— описание . ...........................71
killal!............................... 229
— lanscan.................................338
— опция	-v.........................339
— limit.__________________—...............807
— In
—	опция -s...........................89
—	синтаксис........................  87
— lockfs.
—	опция -h...........................83
logger__________________________-......234
—	описание..............-..... .....244
- Ip..™................_..............    757
—	описание........................  758
Ipadmin................................759
—	опция I........................  .768
—	опция -о.......................... 769
—	опция -s......-....... ...........769
—	опция T.........«............  .	768
флаг m„-------------------------   770
—	флаг -о..............._........-...770
-	Ipalt.............................. 770
—	Ipana...............................770
Ipbanner...............................777
- Ipc........................744-745. 747, 775
— Ipfence_____________________.—..........770
-	Ipfilter.-767
—	Ipforms.............................767
—	IpgeL...............................767
—	Ipmove..............................764
—	Ipq...........................  745-746
—	опция	-D.........................775
—	опция	-t.........................775
— Ipr..................................  744.	746
—	опция -D.........................    774
—	опция -s.  ---------------------------774
—	опция -V............................  774
— Iprm.............................745, 747, 775
— Ipset.....................................—	767
— Ipshut....................................-759
- Ipstat...................................  762
— Iptconlrol----------—..................... 773
— Ipusers .................—-.......-......—.767
- is...............-_____________________89. 229
—	опция -F.......................  258
—	опция -i..........................93
— опция -1......................40. 56. 92
— Ismvd ................................. 278
— Ivcrealc:
—	опция -C 168
—	опция -L...«...............—------168
—	опция -r.....................   —	168
Ivextend.............................. 168
— Ivlnboot................................168
—	make clean ..........................256
-	make config...........................255
—	make depend_____________________ 259-260
—	make rnenuconfig.................255-256
—	make xconfig ------------------  255-256
— makemap ..................... —......  .611
- man......................................23
— описание...........................25
— опция	-k........................25
— опция	-s........................25
— mediainit.............................167
— mkkcmel
— опция	-о ..................255
— опция	-s........................255
— mkboot................................  167
— mkdir...............-....................86
— mkfs....................................154
— mkJosi t-found .......................—	156
— mknod.......—.........................   88
— описание ...........................276
— mkswap,.................................172.	174
— modinfo.................................253,	277
— modload..........................  278.	280
— modprobe:
— опция c.........................  279
— modstat.........______.....____________280
— modunload  ________________________278. 280
- mount ...................  34.	156. 169, 527
— опция -a....................83, 157
—	опция	-a ........................178
—	опция	-F........................ 157
—	опция	-о logging.................164
—	опция	-t---------------------    157
882
— опция grpid							101
— mt			.			.....204	206
- описание	...				210
— опция -f			..	  210
— опция -е			210
- ncheck 			 161
— ndd 			333.	335. 341-342
— опция gel..........		.342
— опция -h		335. 341
— опция -set						333,	342
— netstat:	
— описание		....		667
— опция -а					667
— опция -i		322. 339. 346, 668, 672
— опция -п 				 667,	670
— ОПЦИЯ -ПГ—					339	346 354
— опция -г				-	305,	669
— ОПЦИЯ $				   526.	670
— newfs......			79, 154. 164, 169, 177
— опция N 			155
— newgrp			 101,	106
— nice				66
— описание,....				72
— nohup					   70
— passwd				.56. 99. 692
— описание				  108
— опция -е				  102
- опция -g				 102
— pdbanner			777
— penodic			233
- P»ne	-			»	323
— атака на сервер .			318
— описание				—	662
— опция -S				 662
— pkgadd				272
— pppstals			362
— prveinfo			805
— prtconf							 -	....253
— ps 	-—					78. 83, 798
— описание ...»				-	  73
— опции ef			75
— опции -cif			76
— опции aux				74
— опции lax				74
— опция ww			75
- psbanner 							777
— pstat:	
— описание				 805
— опция -s	».»....	—	  178,	800
— pvereate..	  .		 166
— опция В			 167
— pvdisplay:	
— ОПЦИЯ -v			. . .	169
— quoi......................................  in
— reboot 						..	53
— reject											 76?
rem drv							  278
— renice					77-78
— renice:	
— описание....				_	72
reset					133
— restore					. 202, 209, 211. 224
— описание			  .203
— опция i.						  ..204
— опция г.™.					204. 206
— опция t			  190
— rm			  87-89
— опция -г			 79.	86
— rmdir						 86
— rmmod.						-	 279
route	 		328. 138, 362 374
— директива add		. 325-326, 345. 353
— директива change.....	..	..	  325
— директива delete			325
— директива flush			  125
— директива get			305.	325. 331
— директива monitor...		 325
— ключевое слово gw			  146
описание.				324
— опция -Г			  326
— опция -host						 353
— опция -net.		353
— sar
— опция -r..........................  KOO
— опция -u..........................  796
- setkey..................._......_.......320
—	share..............................  519
— описание...........................  520
shareall...........................519-520
—	showmount............................699
—	shutdown............................. 54
— опция -h___________________________  53
— опция -r................-............53
— синтаксис............................52
-	skill................................229
source:
— псевдоним	”.................   50
- stty.................................131
— описание.......................   132
— опции -a.............. »....... ..132
- опция	-CLOCAL__________________122
— опция	-everything.-___________132
— опция	-tabs................   132
— опция	all......................132
— опция	sane.....................133
- su.................................. 247
— описание........................   59
— опция -с.........-..............  —	181
883
— swap..............................     158
—	опиия -a..........................165
—	опиия -I ..................  165.	800
— swapinfo..................... 170,	178, 800
- swapon...........157-158, 170. 175. 178. 264
— swapon:
— опции -s.......................800
— sync..........................................53
— syscl)................................... 355
—	опиия -a.......................269,	355
—	опция -w....._.................... 355
— sysdef.....................................253
- tee........................................260
— telinit................................54.	864
—	описание -q........................129
—	опции -q.. ........................	54
-	tip.................................  .135
-	uet ...............................131.	133
— описание............................... 133
— tiyadm:
— опция -b..............................136
— ufsdump...............................165.	202
— ufsrestore................................165
— umask:
— описание...............................96
— umount............................... 157,	529
— опиия	-f...........................83
— li name:
— опиия	-i....................  251
— опция	-m..........................251
— unload-'
— опция	-r......................278
—	unshare.................................519
—	uptime..................................798
—	useradd................................112
— опция	-D..........................113
—	userdel................................112
— usermod.............................. 105,	112
—	vgcreate.............................. 167
— опция	-s..........................167
—	vgdisplay..............................16b
— опция	-v......................... 169
—	vgextend.............................   167
—	vipw..................................  107
—	visudo...................................6)
—	vmstat............................ 796,	801
— опция	-S..........................802
—	yppasswd..............................  99
Концентратор..............................  399
Криптография.................................707
м
Маршрутизатор
.401
Маршрутизация..................-305.	364. 388
—	автономная система.................. 370
—	в протоколе РРР..................... 316
—	внешние протоколы....................370
—	внутренние протоколы.................370
—	демоны.............................. 367
—	дистанционно-векторные протоколы______36b
—	метрики стоимости....................370
—	направленная.........................318
—	протокол обнаружения маршрутизаторов. 373
—	протоколы состоянии канала..........369
—	сетевой маршрут......................365
—	стандартный маршрут................. 326
—	статическая.......................   306
—	стратегии............................388
—	таблица........................................305. 354. 365
— проверка.........................  669
—	топологические протоколы............369
-	узловой маршрут......................365
Маска подсети........................... 294
— задание ...............................323
Метасимволы...............................22
Метка диска............................. 152
—	в Solaris...........................163
-	во FreeBSD..........................177
Многопользовательский режим...............34
Модем:
— внешний......................... .....	134
—	внутренний.........................  134
-	дуплексный.......................... 136
—	кабельный .......................    406
—	конфигурирование.....................135
—	скорость передачи...............  .	135
Мост.....................................399
н
Несушая:
—	аппаратная.................................    122
— программная.................................... __122
Неэкранированная витая	пара .....................397
— разводка кабелей..................................407
о
Однопользовательский режим...........................31
Останов системы......................................51
—	выключение питания..............................52
п
Пакет...............................................288
—	адресация......................................29]
—	анализатор.....................................67]
—	маршрутизация..........	. ..	.365
88-ч
— перенаправление.....................317
— поле TOS............................352
— поле TTI..............„............... . 665
— число переходов.................325, 665
— IP-адрес............................292
— МАС-адрес......	..... 291, 366
Память:
— алгоритм часов......................799
— анализ использования .............. 800
— управление..........................799
Пароль:
— выбор...........................„...691
— задание исходного...............    108
— зашифрованный........................99
— редактирование......................107
— теневой.....................100,	|04, 692
— устаревание ..................... 103. 693
Перезагрузка...........................51
Переменная среды:
- MANPATH............................. 25
— PAGER..............................  25
- TERM......................  |26.	131, 133
- TERMCAP.............................131
Печать................................  739
—	база данных принтеров..........749-750
—	в BSD-системах.....................743
—	в System V.........................757
—	выдача задания.....................746
—	очередь заданий....................745
—	просмотр очереди заданий..........746
—	удаление заданий..................747
—	устранение проблем................778
— фильтры.....................741,	753, 777
Повторитель...........................399
Подкачка..............................158
Подсеть;
— маска...........................294, 323
— организация.........................294
Пользователь:
— идентификатор........................56
— эффективный..................56, 65
—	bin................................62
—	daemon..............................62
—	noaccess...........................62
—	nobody.............................62
- в NFS............................516
— root .........„.......55,	57-58, 100. 694
—	в NFS.........................516
—	пароль...........................57
- eys................................. 62
Порт..................................292
— параллельный....................137-138
—	режим	ECP.....................138
—	режим	EPP.....................138
— последовательный......................114
— аппаратная несущая................122
—	дуплексный режим................136
—	программная несущая........... .122
— разъем DB-25......................114
—	разъем DB-9.....................118
—	разъем DIN-8............-.......118
—	разъем RJ-45..............  119-120
—	стандарт RS-232.................114
—	управление потоком	данных.......123
- USB...............................137-138
Поток..................................  65
Почтовый сервер.....................575-576
Правила для администраторов.............823
Правила для пользователей...............821
Принтер:
— добавление..........................  766
-	в FreeBSD.........-.............772
-	в HP-UX..................   ...	770
—	в Red Hat......„................771
—	в Solans..................„.....767
— класс.................................758
— основные принципы	работы..........780
— параллельный ........................ 742
— последовательный ................742.	755
—	сетевой............................742
—	совместное использование............808
—	типы...-...........................741
-	USB...................._..._.......742
Приоритет:
— значение nice..........................66
Программа:
— /bin/mail........................566.	568
—	/bin/sh..............................568
—	/usr/ucb/mail........................566
—	addhost..............................505
- amd..............................532,	870
—	запуск...........-..............538
—	команда amq................537,	539
—	описание........................536
—	останов.........................539
—	селекторы.....................  537
—	таблицы назначений..............537
— autofs................................536
— automount........................531,	870
—	автоматическое выполнение.......535
—	в Red Hat.......................536
—	главная таблица назначений.532, 534
—	дублирующиеся файловые системы.. 534
—	исполняемая таблица назначений .... 534
—	описание........................532
—	опция -t........................533
—	опция -v........................533
—	таблица косвенных назначений. 532-533
885
— таблица прямых назначений............532-533
- Ьс_........ .......................... ......299
— bootOcfg’
— опция -m	.		... 40
— checkpc						777
— cfengine ...				846
— compress					211. 217
— cpio:	
описание					.208
— crack			 703
Cricket			684
- dd			224
- описание.					209
— devlsadm			 162
— dhclicnt			355
- dhepagent				  332
— dhcplools				 341
- dig	   430.	460, 502-503
— описание			 499
— определение версии BIND	.............. 426
— dbklabcl 				  175
- опция -В			 38
— опция -е			  177
— опция -г			177
— опция -w				 177
— dns-makekeyset						 489
dns-stgnkey 				490
— dnskeygen 		. 486. 489
- dnssec-keygen			486. 489
dnssec-signzone			 490
— dnssigner..		490
— elm					566
— ensenpt				 780
— exmh			566
fdisk 			 171, 175
— опция -e		176
— опция -i..........................  176
— finger............................. 102. 875
— fonnat ..	..........................163
fsck............155-156.	164. 169. 174. 178
—	описание.......... ............ ... 159
—	опция	-p...........................159
—	fsdb ................................ 160
-	gdbm...............................   550
- getty..............34.	54. 126-127, 129. 136
— опция	-c.........................  130
— ghostscnpl................608, 743. 771, 779
— gnutar..............................211, 218
- gzip.....	...211,217.228
— host:
— описание.... ...».......    ...	..499
— опция -v.........................—501
— hosls_to_named........................507
— HylaFAX...........................    608
- init...............31.	33-34, 67. 125, 127, 337
—	a Red Hal..........................48
—	во FreeBSD.........................50
—	получение сигнала	KILL...........54
—	получение сигнала	TERM............. 54
—	стартовые сценарии.................43
—	уровни выполнения ........43.	54. 128
—	insf..................................166
—	installboot...........................165
-	ipcalc............................... 296
—	ipchains..............................349
—	опция -i......................— 350
—	опция	-j........................ 350
-	- опция	-I........................351
список	опций......................350
-	ipfw................................ 356
—	lanadmin............................ 340
- lilo.................................36. 174
— ОПЦИЯ	-t......................... 40
linuxconf...	 ........................345
— Lisi Proc ...........................588. 590
- LISTSERV Lite........................588. 590
—	logcheck............................ 247
-	login...................57.	105. 126. 130
-	logrotatc.............................233
	Isof ..................................84
— mail.local ..........................568, 6|8
—	Mailman..........................588-589
—	Majordomo.........................587-588
—	make..............................    260
-	mke2fs.............................   173
—	tnkfs...............................  173
—	mpagc..............................   779
-	MRTG..................................683
—	mutt................................  566
—	mx.................................   566
—	named-xfer.......................... 481
—	ndbtn...............................  549
—	ndc...............................438, 451
команда dumpdb.....................498
—	команда notrace.............—....497
—	команда reload____________ 429. 480. 497
—	команда restart................. 480
—	команда stais....................498
команда trace......................497
—	описание.........................497
—	список команд................... 498
—	nettl............................    673
—	newaliascs...........................184
—	ncwls.................................209
—	nlsslat...............................529
—	nmap................................  700
 опция -s...........................700
—	nmh..............................    566
8£u
—	NOCOL					684
—	npasswd				108,	692
—	nslookup 			430
	— описание				499
	— список команд					500
—	ntalk					872
—	openprom 				.252
—	passwd 			240
—	pine	„									566
—	PPP 			360
—	pnntlool			771
—	procmail					568.	619
—	pump		.........				347
—	pwd mkdb			103,	107
—	QuickPagc			.608
—	rdist			.184
	— описание—				.542
	— опции -f......			544
	— управляющий файл		544
—	rdump 			 187. 199,	205
—	rlpr	 -			779
—	rmail			_....						567
—	rndc		.	438.	497
—	RRDlool			.684
—	rsh	-	-	-			543
— rsync:
— описание...........................545
—	sacadm..............................126
— scp....................................709
-	SfcPP.............................  846
—	shutdown.............................239
—	sig_ named.......................  .507
— Smart List.........................588.	590
— smrsh .............._.........568.	618. 644
- snoop ...............................  672
— snoop.
—	опция	-d.........................672
—	опция	-V.........................672
-	ssh..............................543.	709
—	ssh-keygen	...........................709
-	su....................................240
—	sudo.............................240,	247
—	описание...........................59
—	swatch...........................242.	247
— sysinstall........_...................   175
-	talk................................  872
-	tar...................................230
—	описание.........................   .207
—	опция	b......................... 208
- tcpd.............„...213.	524. 543, 546. 703
— tepdump...............................  268
— описание.............................673
— telnet.......................  390.	697. 723
- top...............-...................  798
—	описание—....—.................   .77
—	опция -q .........„..........  „...77
— traccroutc..............................664
— опция -n..........................  666
— tripwire.—........................  705.	827
— ttymon..................................130
— uugetty................................................._.......136
- VM..................................... 567
— volcopy
— описание........................... 209
Прокси-сервер...........	..........731
Процесс:
— влияние на	производительность.......795
— жизненный	цикл....................  67
— значение nice....................66,	72, 800
— зомби................................67,	73
—	идентификатор.....„.................. 65
— родительский.........................65
—	код завершения........................67
—	компоненты. .......................... 64
—	неуправляемый.—........................77
—	определение........................    64
—	приоритет ........................ 66,	800
—	системный..........................    32
—	состояния............................  71
—	управляющий	терминал................66
Псевдоустройства ...................... 266. 272
Путевое имя............................... 81
р
Раздел диска........................... 152
— во FreeBSD .........................175
— для подкачки .....................  153
— создание........................158
— корневой .....................   ....	153
— логический..........................172
— первичный...........................172
— пользовательский....................153
— расширенный.........................172
— создание............................152
Регистрационное имя ...................98
— отключение...........................112
— проверка........................     НО
Регистрация:
— процедура...........................125
Резервное копирование.................186
—	DDS-устроЙства .................  194
—	безопасность ................. ...699
— библиотека лент.............-.......197
—	восстановление архива.............203
—	гибкие диски....................  193
—	гибкие диски повышенной емкости...... 193
—	жесткие диски.................... 197
887
—	жизненный цикл лент----------------- 191
—	запись нескольких архивов	на	ленту...209
защита лент............................189
—	инкрементное......................... 198
—	компакт-диски.........................193
—	ленточный магазин.....................196
—	маркировка лент.......................187
—	на персональных компьютерах.......-	. 814
— накопители:
-	ADR................................195
-	AIT................................196
-	DAT................................194
-	DLT...............................195
—	Exabyte...................................194
—	Mammoth.........................  196
—	Travan............................195
— носители................................192
—	периодичность......................  188
—	принципы......-......................187
—	проверка лент........................190
—	программа Legato.....................226
— сигнал конца ленты......................201
— система Amanda..........................210
— системы автоматической
загрузки лент....................   196
— схема создания архива..........................202
—	простая.........................  202
—	умеренная.........................203
— съемные жесткие диски...................194
— типы носителей, таблица.................197
— укладчик лент......................  ...196
— хранение лент...........................189
Ретрансляция кадров.......................404
с
Секция диска.........................175
Сервер имен....................... 427
—	авторитетный...................428.	464
— главный..........................428,	447
—	кэширующий................. ...428
—	нерекурсивный..................429
—	переалресуюший.................4Д4
-	подчиненный.................428 , 448
—	разновидности..................427
—	рекурсивный....................429
—	усеченный......................428.	479
Сигналы.............................68
—	перехват.........................68
—	список основных..................69
-	BUS..............................69
-	CONST............................72
-	CONT.........................70,	78
-	HUP..........................70,	234
-	INT..	 70
-	KILL.......................  ....70-71
-	QUIT.............................   70
-	SEGV ...	   .....69
— STOP ............................70, 72. 78
- TERM.........................54,	70-71, 23’
-	TSTP . ----------- -------------70. 72
- USR1......	...70,333
—	USR2...	 70
-	WINCH....................   .	. .69
Символическая ссылка....................89
Система wreg................,..........837
Системный вызов;
— схес...............................   67
- fork...............................32,	67
- icctl..................    .130,	272. 280
— socket ............................   88
—	sync............................53,	155
—	unlink.............................88
—	wait.............................. 67
Служба каталогов.......................560
Сокет................................   88
Спам..............................  ...564
—	обработка..................... ...637
—	определение....	...628
—	примеры.........................  637
Список рассылки........-............581,	587
Спулер в BSD-системах..................745
Спулинг.............................   740
Ссылка:
— жесткая	 — символическая	 Стартовые сценарии			87 	89 3), 34, 43
в HP-UX...	46
— в Red Hat..	.... 47
— в Solaris 			46
— во FreeBSD				50
обшая структура			41
Суперблок, определение...		155
Супер пользователь		...55, 57-58, 100, 694
— парать			57
Сценарий: — adduser 			113
— auto_panns					.....341
— checksendmail 			650
— ifdown			345
— ifup			345
— inetinit		....,	  .557
— ipcalc.pl				296
— Ip unlock					771
— make-local host			509
- MAKEDEV			 88.	171. 276
— named-bootconf			425.	509
— network	  .....	..	.... .. ....345
ляс
—	newsyslog ......................  233
—	rc.Grewall......................  350
—	rmodel............................770
—	rmuser..—.......... ...............1[3
—	roiz......................... 230.	234
—	snmpd. .........................  679
T
Терминал:
—	‘зависший’’ ......................133
—	аппаратный, файлы конфигурации......126
—	база данных.........................130
—	защищенный.........................697
конфигурирование ...	.............125
- в Solaris......................130
—	специальные символы.	..	.„.131
—	управляющий.........................66
— эмуляция.............................к 13
Терминальный сервер ..................317
То.м:
— группа..............................166
— логический........................  166
—	зеркальное дублирование........154
—	.менеджер......................153
—	менеджер Linux LVM.............154
—	менеджер Solstice DiskSmte.....154
—	менеджер Veritas......... 154,	166
—	менеджер Vi num —...........  154
— создание....	... ............. ..153
—	физический......	„166
Троянский конь...	  699
У
Уровень выполнения ............ ...43,	128
Устройство:
— байт-ориентированное.............. ..87
—	блок-ориентированное....... ..	...87
—	драйвер........................ ...87
ф
Файл;
— байт-ориен тированного
устройства..................87.	271. 275-276
-	в HP-UX.	  166
в	Linux	... . „.... |7i
—	в Solaris.	162
—	но FreeBSD .....................176
—	биты режима......	  90
—	блок-ориентированного
устройства................. 87,	271, 275-276
-в HP-UX. ..........................166
— в Solans..........................162
— во FreeBSD.......................... 176
—	блокировка в NFS........................515
—	владелец ..............................  56
—	выполнение в качестве сценария__________ 91
—	журнальный- ...	.........184. 232, 246
—	архивирование......................230
—	обработка.......................   227
—	поиск............................. 230
—	ротация........................... 228
—	список основных....................231
—	уничтожение....................... 227
—	индексный дескриптор.....................91
—	код режима доступа.......................89
—	конфигурационный, список основных... 108
—	копирование.............................542
—	по запросу...................542.	547
—	принудительная рассылка.......542, 545
—	обычный...............................  Кб
— переключения сервисов..........327, 551.	596
—	последовательного устройства...........123
—	права доступа........................   89
—	просмотр атрибутов..................... 91
—	рахличныс типы..........................86
—	системный...............................54)
— совместное использование.......540-541,	808
-	устройства, создание....................151
—	.rhosts.............................   697
-	 /boot/loadcr.conf......................38
—	/boot/loader.conf.local ..............  38
—	/etc/aliases...........................1)0
—	/ctc/conf. modules.................... 279
—	/etc/delault/useradd.................. .113
—	/ctc/deraultdomain.. ................. 330
—	/etc/defaultrouter.....................331
—	/ctc/detaults/rc.conf....... 352-353,	355
—	/etc/dfs/dfstab.......................519
— описание............................  520
- /ctc/dhclient.conf........................355
— /ctc/disktab............. ...............177
—	/ctc/dumpcheck..........................212
—	/etc/dumpdates........................  200
-	/etc/ethers............................ 309
-	/elc/exports ................... 437. 519
-	в HP-UX............................. 522
-	в Red 1 lac..........................523
-	во FreeBSD.......................... 524
—	описание.............................521
— /есс/fstab..........................264.	527
— /ctc/gatcways...........................  374
—	/ctc/geltydefs:
— описание  ............................  |29
—	/etc/gettytab:
— описание............................    127
88У
— /etc/group......................56, JOI. 112
—	описание ..........................106
—	редактирование.....................110
— /etc/hosl.conf......................508,	552
— /etc/hostname...........................—.344
- /etc/hosts... 309.	321, 327, 330, 337-338, 437
— /etc/hosls-equiv..........................697
— /etc/ineld.conf....................... ...212
— /etc/initlab....................44, 54, 126
— описание...............................128
- /etc/liloconf............ 36,	39. 174. 256-257
— /etc/login.conf...........................103
— описание............................   103
— /eic/logingroup...........................101
— /etc/lpd.conf.............................776
— /ctc/lpd.pcrms............................776
— /eic/mail/aliascs .........................98
— /eic/maslcr.passwd........................103
—	описание..........................  103
—	редактирование......................107
— /elc/motd.................................126
— /etc/named conf......... 439,	483. 487. 490
—	инструкция	acl....................445
—	инструкция	controls...............451
—	инструкция	include................440
—	инструкции	key....................450
—	инструкции logging...........447.	493
—	инструкция options..................440
—	инструкция server.................. .. 446
—	инструкция trusted-keys.......450
—	инструкция view.................... 451
—	инструкция zone.............447-450
—	пример...................453-454,	458
—	список соответствия адресов........440
—	список управления доступом.... 445,	484
— /etc/netgroup.............................550
— /ctc/netmasks.........................    330
— /etc/newsyslog.conf.......................233
— /etc/nodename.............................329
— /etc/nsswitch.conf..........330. 337. 505-506
— описание...............................551
— /etc/passwd.....56, 99-103, 112, 126, 541, 550
— зашита...................... 690-692,	694
—	описание.............................97
—	редактирование......................107
— /etc/phones: описание.................  ..135
— /etc/ppp/ppp.conf........................ 360
— /etc/printcap.......................749.	755
—	настройка.......................... 777
—	описание..........................  750
—	переменная	af.................... 752
—	переменная	Ьг.....................755
—	переменная	Гс.....................755
—	Переменная	fs.....................755
—	переменная	if...................753
—	переменная	If....................751
—	переменная 1р.......................752
—	переменная	гпх...................752
—	переменная	nf....................753
—	переменная	оГ...................753
—	переменная	rm...................753
—	переменная	гр.................. 753
—	переменная	rw...................752
—	переменная sd.......-..............751
—	переменная	хс....................755
—	переменная	xs...................755
—	расширения..........................756
—	/etc/rc..................................50
—	/etc/rc.conf........-......50,	352, 355-356
—	/etc/rc.conf. local......................50
—	/etc/rc.co nfig.d/nddconf.............-341
—	/etc/гс.config.d/netconf...........337, 341
—	/etc/rc.dtsklessl......................  51
—	/etc/rc.network........................  51
—	/etc/rc .pccard..........................51
—	/etc/rc.serial...........................51
—	/etc/гс .sysctl..........................51
—	/ctc/remoie:
— описание.............................  135
— /etc/resolv.conf.............326,	330, 434, 437
— /ctc/scrvices................... 212,	292. 713
— /etc/shadow.................................693
—	описание..—.......................-	104
—	редактирование.....................107
— /etc/shells............................102,	112
—	/etc/sshd_config........................710
—	/etc/sudoers............................59
—	/elc/sysconfig/hwconf....................49
—	/etc/syscon fig/network................344
—	/etc/sysconfig/sendmail.................50
—	/etc/sysconfig/static-rouies...........345
— /ecc/syslog.conf.............230,	234. 242. 244
-	в Red Hat..........................237
—	во FreeBSD........................  238
—	примеры.............................239
—	формат............................—	234
— /etc/system................................252
— /eic/ttydefs...............................130
— /etc/ttys..............................-................126
— описание...............................126
— /etc/ttytab:
— описание....................-..........126
— /etc/ttytype:
— описание—...........................   127
— /etc/vfstab................................527
—	/stand/system..........................254
—	/var/adm/lastlog.......................105
jyo
— checklist..................._......156, 169
—	core..........-...................... 183
-	fstab......34. 82, 158. 160, 169. 174. 178
—	fstab:
— описание..............................156
—	services............................  866
—	vbiab............................34. 156
Файловая система.....................80. 154
—	автоматическое монтирование .......... 155
-	в Red Hat........................  174
—	в Solaris......................... 165
-	во FreeBSD........................ 178
—	восстановление из архива....—.......205
—	демонтирование......................... 82
—	каталоги, список	основных .............85
—	компоненты...................... 80, 154
—	монтирование.........................  82
- в NFS........................... 527 , 53)
—	организация..........................   84
—	отладка............................... 160
—	проверка ...........................159
—	в Red Hat........................  174
—	в Solaris..........................164
—	резервное копирование..................198
—	резидентная.......................    804
—	совместно используемая................517
—	создание:
-	в HP-UX.............................169
—	в Red Hat...........................173
—	в Solaris...........................164
—	во FreeBSD....-...................  177
—	удаленная —.........................  527
— автоматическое монтирование...........531
—	чистка................................ 183
—	Extended 2...........................  173
-	FFS..........._.................154, 173
-	FS...................................  169
-	NFS...................................183
-	UFS.............................. 159, 164
-	VXFS.............................159.	169
Фактор уступчивости.........................66
Функция:
-	_exit().................................67
—	closelogO........................234,	245
—	gethostbynameO.........................430
—	openlogO......................... 234.	245
—	setrlimilO............................ 444
—	sysconff)............................. 444
—	syslogO.. _......................234.	245
Ц
Цифровая подпись.........................  488
ш
Широковещательный домен................ 396
э
Электронная почта...	.........563
— агент:
—	доставки..............._....565. 568
—	доступа.....................565, 569
—	подачи почты..................  569
—	пользовательский........... 565-566
—	транспортный................565. 568
—	адресация.........................  570
—	заголовки сообщений.................571
—	компоненты-----------------------   565
—	маршрутизация сообщений ........... 466
—	на персональных компьютерах....... ..814
— почтовые каталоги............	..... ..577
— почтовые псевдонимы.................  579
— почтовый сервер...................575-576
— принципы организации..................575
— спам............................      564
— структура сообщения.................. 570
— хранилище сообщений...................568
я
Ядро..............................      248
— за»ружаемые модули................... 277
—	в Linux.........................278
—	в Solans ...................................277
—	во FreeBSD..................   .280
— инициализация..........................32
— конфигурирование......................250
—	в Linux.....................255. 257
—	в Solaris................ 250, 252-253
—	во FreeBSD ..................   269
— область построения....................250
— параметры:
—	maxswapchunks...................170
—	maxvgs..........................167
— переменные............................269
— построение:
- в HP-UX...................._......253
— в Linux.......................    256
- во FreeBSD....................258-261
— типы................................  249
Язык:
- PCL.................................  741
- PDL...................................740
— PostScript............................741
891
A
addhosl	  ....820 adduser			........	820 Amanda, система резервного копирования-210 —	архитектура 		 211 —	восстановление	файла... 		223 —	журнальные файлы	219 —	инсталляция	212 —	конфипраиим	-.21) —	отладка. ..	 220 — программа:	— категории сообщений	  495 — уровень серьезности	494 —	история-	    416 —	клиент	434 —	компоненты.. . 		427 —	конфигурационные файлы	  438 —	конфигурирование	437 —	параметры конфигурации	440 — allow-query	445 — allow-recursion	442
— amadmin	213, 215, 223 —	amandad.. 	    212 —	amcheck	 .213 —	amcleanup	213 —	amdump	   213 —	amflush	 213,	220 -	amlabel...	 213-214 —	amplot	213 —	amrestore	213,	223 — amtape	    213 —	selfcheck	   2)2 -	sendbackup			 212 —	sendsize 	 212.	222 —	tapetype	216 — файл: — amanda.conf	_	2J3 — disklist	218 —	цикл архивирования	215 Apache: —	виртуальные интерфейсы	730 -	демон httpd		726-727 —	запуск сервера	 727 —	инсталляция сервера	725 —	конфигурирование сервера	726 АРМС	424 AR1N	299-300.	304 АКР, протокол	287 — описание	 307 ATM	403	—	ailow-transfer	   445 -	also-notify		  441 —	blackhole	 445 —	check-names	442 —	directory				 441 —	files	 444 —	forward	  445 —	forwarders. .	..445 —	listen-on	444 —	mat ntain-txfr-base			442 -	notify ..................................................... 441 —	query-source	  444 —	recursion	442 —	rrset order	   445 —	serial-queries	 .....	443 —	sori list	445 —	topology'	-	445 —	transfer-format 	..443 —	transfer-source	   ..443 —	transfers-in	 443 —	transfets-oul	   ..	443 —	transfers-per-ns	    ..	443 —	iise-id-pool	442 —	version...	   441 —	представления	.451 — примеры Конфигурации	452,	454, 458 — программа: — dnskeygen	486,	489 — dnssec-kcygcn		...486, 489 — dnssec-makekeyset 			 489
в	— dnssec-stgnkcy	  .490
ВСР. серия документов.....		286 BGP, протокол	 368.	389 BIND, пакет..	 ...418,425 — аппаратные требования ....	 438 — версия	     425,	441 — определение текущей	425 —	демон named	427 —	журнальная регистрация	  ..493 — каналы...............................	.494	— dnssec-signzone	 . 490 — dnssigner..	490 — named-xfer....	481 BOOTP, протокол	  310 C САЮА		302.	471 CENTR 	 424 CERT	  715 CGI-сценарии ...	 723
92
CIDR, протокол.......................297
— описание................ .	.....298
CIFS, файловая система...............809
Cisco, маршрутизаторы............372, 390
— операционная система IOS.......... 390
COPS................................ 704
CSLIP. протокол......................313
D
DCE. тип устройства —.............116, 122
DHCP, протокол....................322, 877
— конфигурирование
-	в	HP-UX.......................341
-	в	Red Hal..................   34?
—	в	Solans....................  332
—	во FreeBSD....................355
— описание..........................  309
— принцип работы ...............  ....310
— программные компоненты..............309
— реализация ISC ...........  310-311.	355
— сообщение.
АСК........	 311
—	сообщение DECLINE ............311
-	DISCOVER ...................... 311
-	ХАК ............................311
-	OFFER ........................311
RELEASE	 311
REQUEST.........................311
DNS .....................  -...... 414. 418
— база данных.........................459
- директива SGENERATE..........470. 477
— директива SINCLUDE...............477
директива SORIGIN. ..462, 465. 476-477
- директива STTL..........460, 463, 477
-	директивы......................477
-	- записи о ресурсах.. ........ 459
—	запись А...................464, 478
- запись А6 .....................  474
— запись АААА....................  474
— запись CNAME............423, 468-469
— -гапись DNAME....................474
запись KEY....................  488
запись LOC..................... 470
запись MX.......	  466
-	запись NS ..	.... 464 , 479
запись NXT.. ...................... 490
-	запись PIR	.... 465
-	запись SIG	490
запись SOA...........„...... 415. 461
- запись SRV...................471, 492
-	гапись ТХТ.....................473
гапись WKS......................472
-	класс записи	...	 460
— обновление....................480. 482
— связующие записи.................478
- в HP-UX...—.........................,506
— в Red Hat........................—...507
— в Solans.........................~... 505
— во FreeBSD...........................508
— выбор имени домена.................. 423
— делегирование .....................  431
— добавление нового компьютера.........414
— зона localhost..............    478,	504
— зонные пересылки.............428, 443, 481
— инкрементные________442, 446, 448. 482
— история..............................416
— конфигурирование.................  .	326
— кэширование..............._..........432
—	отрицательное ...............  432
— напрасное делегирование........ 424.	502
— обратное преобразование.........419.	465
—	в стандарте IPv6 ............  474
—	посредством записей CNAME.....469
— основные задачи............	........417
— порядковый номер зоны................415
— проблема доменов.................... 423
п ростра нс гво и мен...............419
— прямое преобразование...........419.	464
-	- в стандарте IPv6........, .. 474
— распознаватель .............417. 427. 430
—	конфигурирование.._............434
—	тестирование ..................437
—	расширенная версия	(EDNSO).........433
—	регистрация домена....—............424
—	сервер имен........................427
— авторитетный.................428.	464
— главный..................... 428.	447
—	кэширующий......................428
—	нерекурсивный...................429
—	переадресующий................  444
—	подчиненный ............. 428,	448
—	разновидности.................  427
—	рекурсивный...—.......-........429
—	усеченный.......—....... .428.	479
— сигнатуры транзакций ..............  486
—	создание поддоменов. ............. 424
—	спецификация TKEY-
— описание..........................486
— спецификация TSIG...........-..—.—,419
— описание..........................486
—	ссылки между	зонами ............. 478
— схема работы....................431,	436
—	управление доменами................422
— файл "подсказок".....,.430, 447, 449, 503
—	цифровая подпись...................488
DNSSEC, спецификация..........419, 421, 450
—	описание..................... . ,488
893
DSL 	   405-406 DTE, тип устройства	  .116,	122 DVMRP, протокол	373	— сетевое конфигурирование		352-353, 355-356, 362 — система NAT				302. 356 - система Syslog	.238
E	— служба NIS	558
EIGRP. протокол.....	368 — описание	372 Ethernet	 398.	406 — история			..--394 — принципы работы	395 — топология	  396 expect, язык сценариев...	547	—	стартовые сценарии	  50 —	статическая маршрутизация	 325 —	управление учетными записями. .. .113 —	файл: —	/ete/login-СопГ	103 —	/elc/master.passwd	  ЮЗ —	/etc/passwd 		691 —	/etc/ttys	 126
F	— файлы лсмона сгоп...,	 182 — файлы последовательных устройста	124
FDDI	...401 FreeBSD...	22 —	анонимный FTP-сервер	....734 —	виртуальные интерфейсы	730 — лемон	gated	388 —- лемон	mountd....	 519 — лемон	nfsd	    526 — лемон	nlsiod	 527 —	демон	routed	388 —	демон	Vixie-cron	185 —	демонтирование файловой системы	83 —	добавление принтера	...772 —	документация	м	24 —	драйвер устройства: — добавление	275 —	журнальные файлы	 233 —	загрузчик	37 —	задание исходного пароля	108 —	задание локального принтера.	773 —	идентификаторы групп	  ...101 —	команда: —	fetal	84 —	ping	  664 —	ps 	74 psi at	805 —	конфигурирование DHCP	355 —	конфигурирование PPP		ЗбО — монтирование удаленных файловых систем	 528 —	мультнеистемная загрузка	40 —	однопользовательский режим	-	42 -	пакет BIND	508 —	пароли пользователей	..100 —	подключение жесткого лиска	175 —	принудительная рассылка файлов.....	543 —	приоритеты источников информации	552 —	редактирование паролей	    107 —	сервер Apache	726	— фильтрация пакетов	318,	356 —	флаги доступа к файлам 	 	 		93 —	экспорт файловых систем	524 —	ядро	 244 —	загружаемые модули	280 —	конфигурирование 	 269 —	построение	  258-261 —	файл конфигурации	 259,	261-267 FTP. протокол		713 — анонимный сервер	 732 FY1, серия документов			286 н HP-UX	21 —	SNMP-агент	 ...679 —	st icky-бит	  90 —	анализатор пакетов	673 —	анонимный ЕТР-сервср	 734 —	виртуальные интерфейсы	 729 —	лемон gated .............................................. 388 —	демон inetd	...................704 —	демон nfsd	526 —	добавление принтера	770 —	дуплексные порты	136 —	журнальные файлы	233 —	журнальный режим	- 159 —	задание локального последовательного принтера	—			770 — команда -	df.	 156 —	ping	 664 —	ps	-	  75 —	mt	  210 —	конфигурационные	файлы	47 —	конфигурирование	DHCP	341 —	конфигурирование DNS	. 327 —	конфигурирование РРР	343 —	монтирование удаленных файловых систем	528
894
—	однопользовательский режим..........41
—	пакет BIND.......................  506
—	пароли пользователей...............100
—	подключение жесткого диска.........]66
—	сетевое конфигурирование.......337-339,
341-342,	344
—	система NAT........................342
—	система SAM.......................339
—	служба NIS........................ 557
—	стартовые сценарии.................46
— теневые пароли ............  ,.......693
—	управление учетными записями.......112
—	уровни выполнения .................128
—	файл /etc/logingroup..,............101
—	файл checklist.....................156
—	фильтрация пакетов........„........342
—	экспорт файловых систем............522
ядро............................... 249
— построение.......................253
HTTP, протокол  ...................... 721
—	версия 1.1.......................  728
—	выбор сервера......................724
—	инсталляция сервера. ..............724
—	принцип работы..................   723
HTTPS, протокол............. .722
IANA.......... ..........
ICANN....................
ICMP, протокол ... „.....
— переадресация..........
1СР, протокол............
IDE, интерфейс...........
— описание................
— сравнение со SCSI
IETF....... .............
IGMP, протокол...........
IGRP, протокол...........
1GRP, протокол:
— описание...............
IKE. протокол.........—.
IMAP, протокол...........
— описание...............
InterNIC ...................
IOS. операционная система
IP. протокол..
— пакет..................
— разбивка пакетов ..
1Р-адрес..........
— в стандарте IPv6.......
— выделение................
— групповой..............
— классы..........
....................472
.285, 300, 419,	424
...л..............  287
........307, 317, 384
....................73!
.............140-141
...............146
................148
....................285
...........................	293
...................—368
_____372
-----319
....569
.....578
.... 300
.....390
... 287
-----288
....291
293, 297
.-302
....300
.....293
.293
— маска подсети......................  294
— направленный ........................293
— обратной связи.......................293
— порт.................................29?
— преобразование.......................307
— присваивание ......................  321
— сетевой...........................   296
— соответствие аппаратному адресу.. ..292
— типы...............................  293
— частный..........................    301
— широковещательный  ..........293, 296, 323
IPFilter, пакет................335, 342. 357
— программа:
— ipf.............._...............357
— ipfstat......................... 357
—	ipmon........................  359
—	ipnat...................      357
IPSEC, протокол........................319
IPv6, стандарт....................     297
— адресация............................302
— поддержка в BIND.................419,	473
IS-IS, протокол.....................   369
— описание............................ 373
ISC:
— DHCP-клиент ...	..355
— DHCP-сервер.......	  311
— (пакет BFND...........	....... .416, 425
— реализация DHCP..................... 310
ISDN..............................     405
ISOC.................................  285
к
Kerberos..	................518, 707
l
LCP, протокол........................... 313
LDAP, протокол.....................322,	560
—	документация.........................561
—	исполгьзованис в sendmail..579, 590,	614
—	практическое применение........562
LILO............................... 36. 256
—	загрузчик.........................174
—	конфигурирование .....................36
— мулы и с метем ное..................39
Linux LVM. менеджер томов................154
Linux.
— 1Р-маскирование.............302,	350, 352
—	драйвер устройства: добавление....273
— загрузчик LILO .......... 36,	39. 174. 256
—	мультисистсмная загрузка......  38-39
—	однопользовательский режим ........4|
—	системные процессы..........  .....33
'95
— ядро............................. .....  249
—	загружаемые модули................ 278
—	конфигурирование............ 255.	257
—	построение............................................256
LMTP, протокол........................... .618
LPRng, спулер.............................773
— инсталляция..............................775
— команды..............................    774
— конфигурирование демона	Ipd ........776
— настройка базы данных	printcap.......... 777
— настройка прав доступа...................776
— учет страниц.............................778
—	фильтры печати........................777
м
т4, препроцессор...........................237
МАС, протокол..............................291
—	стандарт IPv6.........................303
MIME, стандарт...........................  566
MOSPF, протокол............................373
N
NAT, система...	 301
-	в HP-LX........................    342
—	в Red Hat..........................348
в Solaris........................... 335
— во FieeBSD........................... 356
NCP, протокол...........................313
Nessus................................  702
M-’S ...............................513.809
— безопасность.....................517,	699
—	блокировка файлов. ..	515
—	версии ............................513
—	выбор порта........................529
—	выбор транспортного протокола......514
—	дисковые квоты ......................515
—	идентификаторы пользователей....	-.516
—	имена файловых систем................517
—	клиент...........................  527
—	кэширование........................527
—	монтирование файловой	системы......527
— автоматическое.................... 531
— пользователь nobody...............63,	516
—	пользователь root.................516
—	секретный ключ.....................517
—	сервер..............................518
—	система WebNFS......................515
N1S+, информационная служба.......549,	558
NIS, информационная служба........549,	551
—	безопасность...................  ..698
—	в разных ОС..................      557
— демон:
— ypbind..........	.........554. 557
— yppasswdd..................... 556-557
— ypserv.................... 554,	556-557
— ypxfrd........................554.	557
— список существующих................555
—	карта ypservers.....................554
—	команда:
—	domainname.........  ,....._.... 557
—	makedbm .........................553
—	ypinit.................. ....555,	557
—	ypmake............	.....550,	554
—	yppasswd........................556
—	yppush...........................554
—	ypsei..........................  550
—	ypstart........................  557
-	ypxfr.....................  554,	556
— список существующих................555
—	конфигурирование	клиентов...........557
—	конфигурирование	сервера...........556
—	преимущества и недостатки...........552
—	сетевые группы..................... 550
— создание домена........................555
—	сравнение с NIS+....  ............  558
—	схема работы....................... 553
NS. специализированные серверы ..........53(1
NTP, протокол..........................  876
о
OpenLDAP.. .........................  ...562
OPIE...................................  711
OS1, модель...............-............  287
OSPF, протокол.........	....369. 389
—	конфигурирование ......	_____383
—	.маршрутизатор:
—	отмеченный..................... .382
—	пограничный......................381
—	область .маршрутизации..............381
—	область маршрутизации: опорная......382
— описание..........................-372. 381
ОТР, стандарт...................................711
Р
PGP...................................708
PIM. протокол.........................373
POP, протокол........................ 569
— описание........................... 578
POSIX.................................859
Postfix, почтовая система.............653
— архитектура.....................    653
— конфигурирование..............  654,	657
— очереди сообщений...................653
>6
—	спам..............................656
—	утилиты командной	строки......... 654
РРР, протокол..........-......-.....  315
—	безопасность.......................316
—	диалоговый сценарий................317
—	конфигурирование:
-	в	HP-UX.......................343
-	в	Red Hat.....................352
—	в	Solaris.....................336
—	во FreeBSD................ ...360
—	маршрутизация.....................316
—	описание...*......................313
—	подключение к сети.................315
—	присвоение адресов.................316
—	производительность.................314
—	терминальный сервер................317
РРРСР, протокол.....................  311
R
RARP. протокол.......................  308
Red Hat Linux..........................21
Red Hal:
— анализ производительности............805
— анонимный FTP-сервер.................734
— виртуальные интерфейсы...............729
— выбор пароля.........................692
— демон gated..........................388
—	демон routed.......................388
—	Демон Vixie-cron.................  185
—	добавление принтера................771
-	дуплексные порты.................. 136
—	журнальные файлы..	 233
—	загрузчик LILO......................36
—	задание исходного пароля...........108
—	задание локального последовательного
принтера.............................. 771
—	запуск приложений Windows............. 815
—	команда fuser....................... 84
—	команда ping...................... 664
—	команда р$.......................... 74
—	конфигурационные	файлы........... 49
—	конфигурирование	DHCP............ 347
—	конфигурирование	РРР...... .......352
—	модуль rpm..........................202
—	монтирование удаленных
файловых систем.....................   528
—	однопользовательский режим.. 34, 42. 54
— определение версии BIND..............427
— пакет BIND.........................  507
— подключение жесткого диска...........„170
— принудительная рассылка файлов ......543
— программа automount..........531, 534, 536
— сетевое конфигурирование.....344, 346-348,
352
— система NAT....................  302,	348
—	система Sysiog....................237
—	служба NIS....................,...557
—	стартовые сценарии.................47
—	статическая маршрутизация ........326
—	управление учетными записями.......112
—	уровни выполнении.................128
—	файл /etc/shadow.	  104
—	фильтрация пакетов .......... 318.	348
-	экспорт файловых систем............523
—	пароли пользователей..............100
RFC2I96.................................820
RFC, серия документов...................285
RIP, протокол......................368.	389
—	конфигурирование.................. 380
- описание.............................371
RIP, процессор.........................740
R1P-2, протокол........................371
root, суперпользователь...55, 57-58, 100, 694
—	пароль............................. 57
RPC. протокол..........................514
RS-232, стандарт........................ 114
—	сигналы. список....................116
S
SAGE.................................. 856
SAINT ............................    702
Samba ............................... 809
— демон nmbd.......................... 810
— демон smbd......................810,	812
—	команда smbstat us.....	.812
—	конфигурирование ................  810
— отладка ... .. ....	......812
— программа smbtar....	..211, 219
SANS..................................716
SASL, протокол .	. .............  648
SATAN ................................702
SCSI, интерфейс.................. 140-141
—	описание.........................  142
—	сравнение с	IDE....................148
sendmail. почтовая система.......563. 872
—	“черные” списки...................635
—	агенты доставки................. .	607
—	база доступа...	 633
—	безопасность	. .641, 648. 699
— библиотека Berkeley DB ..	586. 611
— библиотека ndbm................ 586,	611
—	Версии............................594
—	доставка почты с комментариями...650
—	запуск с измененным корневым
каталогом.........................   645
—	инсталляция.......................595
—	история...........................593
897
—	коды состояния доставки.............634
—	конфигурирование.... 601. 603. 605. 609
—	опции............................619
—	примеры..........................622
— макроконстанта:
- MAJLJ4UB...................616. 625
- SMART HOST ................ 616, 625
— макрос:
— DOMAIN......................... 607
-	EXPOSED.USER.................... 615
-	FEATURE..........................609
-	GENERIC DOMAIN ..................613
-	GENER1C_DOMAIN_ FILE....... 613
-	LOCAL_CONFIG.....	626
-	MAILER...........................607
-	MASQUERADE-AS ..........610.	615
-	MASQUERADE-DOMAIN............ 615
-	MASQUERADE-DOMAIN-FILE... 6|5
-	MASQUERADE-EXCEPTION ............615
-	OSTYPE...........................605
-	RELAY_DOMAIN.....................631
-	RELAY-DOMAIN_FILE................631
-	VERSIONID .......................605
-	VIRTUSER-DOMAIN................. 614
-	VIRTUSER-DOMAIN-HLE .............614
— маршрутизация сообщений......... 467.	617
— маскирование адресов......... 615,	617
—	направление почты	в	программу......582
— безопасное.........................644
—	направление почты	в	файл...........582
— безопасное.........................644
—	описание............................592
—	опции конфиденциальности............644
—	отладка.............................649
—	очередь сообщений ................  598
—	перенаправление почты.............  584
—	права доступа............—	. .643
—	препроцессор т4.....................601
— проверка заголовков.................. 636
— псевдонимы.................... 579. 583
— хэшированная база данных...........586
— регистрация событий.............. 652
—	режимы работы.......................597
—	ретрансляция.....................   630
— спам.........................._  628
—	обработка........................637
—	примеры..................... ....637
— специальные пользователи.	 642
— списки рассылки...............581, 587
— средство............................  609
—	access_db.......................  633
—	al (masquerade...................—616
—	always_edd_domain..............   610
—	b)acklist_recipients...„..........635
—	dnsbl.................  -.......635
—	gencncsiable..............„..613, 623
— Idaprouling.........................614
—	lim iCed_masquerade.............615
—	local lmip—.................618.	644
—	local-procmail..................619
—	loose_relay_check...............632
—	mailcnable..................    612
—	masqueradc_cnlire_domain........616
—	masquerade_cnvclope............ 616
—	nocanorufy...................... 610
—	nullclient..................... 618
—	promiscuous relay ..............632
—	redirect........................ 585
—	redirect.-.......................610
—	rclay_based_on_MX.....-..........632
—	rclay_entire_domain..............631
—	re)ay_hostS-Only.................631
—	rclay_local_from ............... 632
—	smrsh.................  618, 644
—	usccw_llle.............. _.......609
—	vinuscrtable...............613. 623
—	статистика работы.......	 649
—	сценарий checkscndmail...............650
—	таблицы............._................611
-	файл переключения сервисов..........596
—	фальсификация писем.............. ...647
—	флаш............................  ...597
SLIP, протокол.......................... 313
SMTP, протокол..........—................568
—	команды.............................651
SNMP, протокол.......................674-675
—	агенты........	 678
— агенты: UCD.......-............... 681-682
— агенты в	HP-UX......................679
— агенты- в Solans......- 679
- база MIB.............	....676
-	база M1B-II........	... 676
-	база RMON ................. .	-678
—	идентификатор	01D............ ....676
—	имя сообщества..............-.......678
- операции ........................ —677
—	прерывание........................  677
—	структура ........................  676
—	удаленный мониторинг............... 678
Solans............-..... -................21
-	SNMP-aieHT ......................   679
—	sticky-бит.........................  90
—	анализатор пакетов................. 672
—	анонимный FTP-сервер........ ...	.734
—	виртуальные интерфейсы...	. 728
—	выбор пароля------------- —.........692
демон nfsd........................... 526
—	демон routed........................388
898
—	демонтирование файловой системы....КЗ
—	добавление принтера...............767
—	документация.......................25
— драйвер устройства: добавление-------272
— дуплексные порты.....................136
—	журнальные файлы...................232
—	журнальный режим........ ...159. 164, 185
—	задание локального последовательного
принтера............................. 768
—	запуск демона named....	43К
—	запуск приложений	Windows.........816
—	команда dump......................201
—	команда ping—...................  664
—	команда ps........................  75
—	конфигурационные	файлы...........46
— конфигурирование:
-	DHCP ________________________  332
-	DNS.................i..........327
-	РРР............ -............. 336
—	терминалов ..................  130
—	монтирование удаленных
файчовых систем...................... 527
—	однопользовательский режим.... ....40
—	пакет BIND........................505
—	подключение жесткого диска........ 161
—	подключение сетевых интерфейсов...322
—	пользователь nobody................62
—	программа automount...............535
—	редактирование паролей ...........107
— сетевое конфигурирование.....329. 331. 333,
335. 337
—	система NAT.	...	-335
—	служба NIS................. ..557
—	смена интерпретатора команд...	.. 102
— стартовые сценарии. ..................46
—	теневые пароли................... 100
—	управление учетными записями..... 112
—	уровни выполнения .. ............ 128
— файл /etc/shadow.................... 104
— фай л vfstab ........................156
— файлы последовательных устройств.... 124
— фильтрации пакетов...................335
— экспорт файловых систем.....-	..520
— ядро.................................249
—	загружаемые модули .....-......277
—	конфигурирование........250, 252-253
Solstice DiskSuite. менеджер томов ....154
Squid, сервер..........................731
— инсталляция..........................732
SRP. протокол....	 711
SSH.............................   709,813
SSL, протокол	.641. 722
STD. серия документов	286
St icky-бит......	-90
Syslog, система регистрации ....230, 232-233,
243, 246
-	в Red Hat...........................237
—	во FtecBSD..........................238
—	выходная информация	......... 241
—	выходная информация,	отладка......244
—	действия —........................237
— демон syslogd ...................234,	237
—	демон syslogd. конфигурирование ..234
и безопасность............ .........696
-	использование в BIND...............493
— команда logger................  -234,	244
—	средства................. .	...236
—	уровень серьезности.........—234, 236
—	функция.
— closelogO...............234, 245
—	openlogO...—...............234,	245
—	syslogO..................  234,	245
т
Tel, язык сценариев.................  547
TCP, протокол.........—...........283.	287
- в NFS.........................  ....	.529
— использование в	NFS... —........ -514
— сегмент ..........................  288
TCP/IP........................... 283-284
— канальный уровень’
—	адресация..	..292
—	беспроводные сети...	..290
—	кадр—......................  —	288
—	максимальный размер	блока..... 290
—	стандарты кабелей............  290
—	стандарты формирования	кадров. 289
— описание ..........................-287
ТСТ...................................706
TFTP, протокол........	310, 391. 698
TKEY, спецификация’
— описание ..................... ..486
TLS, протокол ......	. .641
TSIG, спецификация   419
TS1G, спецификация.
— описание......................   ...486
tun. псевдоустройство..	...343, 360
и
UDP. протокол....................283.	287
- в NFS................ --...........529
— использование в NFS...	...514
UNIX:
— документация........	•	. 23
— краткая история.	— 20
URL.... ......-......................722
USB, интерфейс	... 137-138. 141
899
USB, принтеры.......................  742
Usenet.......................-... 734.	736
— подписка иа новости.................735
— программное обеспечение.............736
UUCP, протокол........................336
V
Veritas, менеджер томов...........154,	166
Vinum, менеджер томов.................154
— распределение нагрузки.............724
Web-хостинг..-...................720.	727
— основы.............................721
WebNFS.................-.............515
X
X Windows:
— эмуляторы........—-................813
W
Web-сервер.................................721
Содержание
Предисловие......................................................6
Предисловие ко	второму изданию...................................7
Предисловие к первому	изданию....................................9
Введение........................................................10
Благодарности...................................................13
Об авторах......................................................15
Часть I. Основы администрирования
Глава 1. С чего начать...................................................19
1.1.	Что необходимо знать...................................  -20
1.2.	Краткая история UNIX......................................20
1.3.	Современные UNIX-продукты.....—...........................21
1.4.	Шрифты н условные обозначения.............................22
Информация по конкретным системам....................  ...23
1.5.	Как пользоваться интерактивным руководством...............23
Организация страниц руководства....................   ....24
Чтение страниц руководства: команда man...............  .	.25
1.6.	Основные задачи системного администратора............... .26
Добавление и удаление пользователей.......	.26
Подключение и удаление аппаратных средств.................26
Резервное копирование.....................................26
Инсталляция новых программ.............................   26
Мониторинг системы........................................27
Поиск неисправностей....................................  27
Ведение локальной документации..........................  27
Слежение за безопасностью системы.........................27
Оказание помощи пользователям.............................27
1.7.	Как искать файлы в Internet.......................-.......28
1.8.	Издержки профессии......................................-..28
Синдром хронического администрирования....................29
1.9.	Рекомендуемая литература.....—  ...............................29
901
Глава 2. Запуск и останов системы............................................30
2.1.	Начальная загрузка.......................................    30
Автоматическая и ручная загрузка............................  31
Этапы загрузки...........................—................... 31
Инициализация ядра...............................-............32
Конфигурация аппаратных средств...............................32
Системные процессы............................................32
Действия оператора (только при ручной загрузке)...............33
Выполнение стартовых сценариев................................34
Работа в многопользовательском режиме.........................34
2.2.	Загрузка системы на персональном компьютере..................35
Чем персональный компьютер отличается от фирменного
оборудования...................................  -............35
Процесс загрузки ПК...........................................35
LILO: загрузчик Linux.........................................36
Конфигурирование LILO.........................................36
Загрузчик FreeBSD.............................................37
Мультисистемная загрузка......................................38
Проблемы при мультисистемной загрузке.........................38
Мульти систем ное конфигурирование LILO.......................39
Мультисистемное конфигурирование FreeBSD...............-.... -40
2.3.	Загрузка в однопользовательском режиме........................40
Solaris.....................................................  40
HP-UX........................................................-41
Linux.........................................................4!
FreeBSD.......................................................42
2.4.	Стартовые сценарии...........................................43
Стартовые сценарии в системах семейства System V..............43
Solaris.....................................................  46
HP-UX.........................................................46
Red Hal.......................................................47
FreeBSD.......................................................50
2.5.	Перезагрузка и останов системы................................51
Выключение питания............................................52
Команда shutdown: корректный способ останова	системы..........52
Команда halt: более простой способ останова...................53
Команда reboot; быстрый перезапуск.......................... -53
Передача программе init сигнала TERM..........................54
Команда telinit: изменение уровня выполнения	программы init..54
Уничтожение процесса init.....................................54
Глава 3. Сила привилегий...................................................  55
3.1.	Владение файлами и процессами.................................55
3.2.	Суперпользователь...........................................  57
3.3.	Пароль суперпользователя....................................  57
3.4.	Как стать суперпользователем................................  58
Команда su: замена идентификатора пользователя................59
Программа sudo: ограниченный вариант команды su...............59
902
3.5.	Другие псевдопользователи.................................62
Владелец непривилегированных системных программ: daemon....62
Владелец системных команд: bin........................    62
Владелец образов ядра и памяти: sys........-............  62
Общий сетевой пользователь: nobody........................62
Глава 4. Управление процессами...........................................64
4.1.	Компоненты процесса.....................................  64
Идентификатор процесса (P1D)............................  65
Идентификатор родительского процесса (PPID)...............65
Идентификатор пользователя (UID) и эффективный
идентификатор пользователя (EU1D)........................—65
Идентификатор группы (GID) и эффективный
идентификатор группы	(EGID)..............................66
Приоритет и значение	nice................................66
Управляющий терминал......................................66
4.2.	Жизненный цикл процесса...................................67
4.3.	Сигналы...................................................68
4.4.	Отправка сигналов: команда kill.........-.................7)
4.5.	Состояния процессов.......................................71
4.6.	Изменение приоритета выполнения: команды	nice	и renice....72
4.7.	Текущий контроль процессов: команда ps....................73
4.8.	Улучшенный текущий контроль процессов:	программа top......77
4.9.	Процессы, вышедшие из-под контроля........................77
Глава 5.	Файловая система...............................................80
5.1.	Путевые имена.........................................    81
5.2.	Монтирование и демонтирование файловой	системы............82
5.3.	Организация файловой системы..............................84
5.4.	Типы файлов...............................................86
Обычные файлы.............................. ...............86
Каталоги..............................  ..................86
Файлы байт-ориентированных
и блок-ориентированных устройств..........................87
Сокеты.... .............................„.................88
Именованные каналы.....................................   88
Символические ссылки......................................89
5.5,	Права доступа к файлам....................................89
Биты SU1D и SG1D..........................................90
Sticky-бит................................................90
Биты режима...............................................90
Просмотр атрибутов файла........... .......................91
Дополнительные флаги во FreeBSD.........................  93
Команда chmod: изменение прав доступа.....................94
Команды chown и chgrp: смена	владельцев...................95
Команда umask; задание стандартных	прав доступа...........96
903
Глава 6.	Подключение новых пользователей..................................  97
6.1.	Файл /etc/passwd..............................................97
Регистрационное имя........................................... 98
Зашифрованный пароль.....................-..........-..........99
Идентификатор	пользователя...............................100
Идентификатор	группы по умолчанию........................101
Поле GECOS.....................................................Ю1
Начальный каталог............................................-.Ю2
Регистрационный интерпретатор	команд......................-102
6.2.	Файл	/etc/master.passwd во FreeBSD.........................103
6.3.	Файл	/etc/login.conf во FreeBSD............................ЮЗ
6.4.	Файл /etc/shadow в Solaris и Red Hat...............-........104
6.5.	Файл	/etc/group...........................................106
6.6.	Подключение пользователей.....-..................-...........106
Редактирование файлов passwd и shadow.........................107
Задание исходного пароля.....................................- 108
Создание начального каталога.................................-108
Копирование конфигурационных файлов.........................  108
Назначение каталога для электронной почты.................... 109
Редактирование файла /etc/group...............................110
Установка дисковых квот........................................1 Ю
Проверка нового регистрационного имени.........................ПО
6.7.	Удаление пользователей.......................................111
6.8.	Отключение регистрационных имен..............................112
6,9.	Системные утилиты управления учетными записями..............  112
Глава 7. Последовательные устройства.........................................114
7.1.	Стандарты последовательной передачи данных....................114
7.2.	Альтернативные разъемные соединения...........................118
Мини-разъем D1N-8.......................................      118
Разъем DB-9...................................................118
Разъем RJ-45................................................  119
Стандарт Йоста для разъемного соединения RJ-45...............-.120
7.3.	Аппаратная несущая и программная несущая....................  122
7.4.	Аппаратное управление потоком данных —........................123
7.5.	Длина кабеля.....................................—...........123
7.6.	Файлы последовательных устройств-----------....---------...  123
7.7.	Конфигурирование программного	обеспечения
для последовательных устройств.............................   124
7.8.	Конфигурирование аппаратных терминалов....................... 125
Процесс регистрации...........................................125
Файлы /etc/ttys и /etc/ttytab.................................126
Файл /etc/ttytype.....................  ..................    127
Файл /etc/gettytab.......................-....................127
Файл /etc/inittab.............................................128
Файл /etc/gettydefs.......................................... 129
Конфигурирование терминалов в	Solaris................    130
Поддержка терминалов: базы данных termcap и terminfo.........-,— 130
904
7.9.	Специальные	символы и драйвер терминала...............  131
7.10.	Команда stty:	конфигурирование терминалов.................132
7.11.	Команда tset:	автоматическое конфигурирование.............133
7,12.	Как справиться с “зависшим” терминалом....................133
7.13.	Модемы....................................................134
Протоколы модуляции, коррекции ошибок и сжатия данных......134
Выходная конфигурация: файлы /etc/phones и /etc/remote.-.....135
Дуплексные модемы ........................................136
7.14.	Отладка последовательной линии........................  -	137
7.15.	Другие распространенные порты ввода-вывода. ..............137
Параллельные порты......................................  138
Интерфейс USB. ...........................................138
Глава 8.	Добавление нового жесткого диска...............................140
8.1	Дисковые интерфейсы.......................................141
Интерфейс SCSI............................................142
Интерфейс IDE.............................................146
Что лучше: SCSI или IDE?..................................148
8.2.	Конструкция современного дискового накопителя.............148
8.3.	Обзор процедуры инсталляции...............................150
Подключение диска.........................................150
Создание файлов устройств.................................151
Форматирование диска....................................  151
Раздеты и метки...........................................152
Создание логических томов.................................153
Файловые системы......................................    154
Автоматическое монтирование файловой системы..............155
Создание раздела подкачки.................................158
8.4.	Программа fsck: проверка и восстановление файловых систем..159
8.5.	Особенности подключения дисков в различных
операционных системах.....................................161
Solaris.................................................  161
HP-UX.....................................................166
Red Hat...................................................170
FreeBSD...........................................        175
Глава 9.	Периодические процессы.........................................179
9.1.	Демон сгоп: планирование команд.........................  179
9.2.	Формат crontab-файлов.....................................180
9.3.	Изменение crontab-файлов..................................182
9.4.	Применение демона сгоп..................................  182
Чистка файловой системы.................................  183
Распространение конфигурационных файлов по сети...........184
Циклическое использование журнальных файлов...............184
9.5.	Особенности периодических процессов в различных системах...185
Глава 10.	Резервное копирование.........................................186
10.1.	Принципы резервного копирования...........................187
Создавайте резервные копии на одной машине................187
Q05
Маркируйте ленты......................................... 187
Правильно выбирайте периодичность резервного копирования....188
Тщательно выбирайте архивируемые файловые системы.....-...188
Старайтесь умещать каждодневные архивы на одной ленте.......188
Создавайте файловые системы, объем которых меньше
емкости резервного носителя..........................-....189
Храните ленты не в рабочем помещении......................189
Защищайте резервные копии.................................189
Активность файловой системы во время создания
архива должна быть низкой................................ 190
Проверяйте свои ленты...-....-............................190
Определите жизненный цикл ленты...................   -....191
Компонуйте данные с учетом резервного копирования.........191
Будьте готовы к худшему...................................192
10.2.	Устройства и носители, используемые
для резервного копирования.....................................192
Гибкие диски..............................................193
Гибкие диски повышенной емкости...........................193
Компакт-диски формата CD-R и CD-RW........................193
Съемные жесткие диски.....................................194
8-миллиметровые кассетные ленты.........................  194
4-миллиметровые цифровые аудиокассеты.....................194
Технология Travan..,......................................195
Система OnStream ADR......................................195
Технология DLT.........................................   195
Технология А1Т........................................    196
Технология Mammoth......................................  196
Системы с автоматической загрузкой носителей .............196
Жесткие диски.. ... ....................................  197
Сводка типов носителей.......................   ..........197
Что покупать............---------------------.............198
10.3.	Настройка режима инкрементного архивирования---------------198
Архивирование файловых систем ............................198
Схемы создания архивов...................................— 202
10.4.	Восстановление с резервных копий ....................    203
Восстановление отдельных файлов...........................203
Восстановление файловых систем............................205
10.5.	Архивирование и восстановление при модификации ОС........207
10.6.	Другие программы архивирования...........................207
Программа tar упаковка файлов.............................207
Программа cpio: архивирование в системах семейства System V.....208
Программа dd: манипулирование битами......................209
Программа volcopy; дублирование файловых систем.........  209
10.7.	Запись нескольких файлов на одну ленту...................209
10.8.	Amanda...............................................    210
Архитектура...............................................211
Инсталляция...........................................    212
Файл amanda.conf........................................  213
906
Файл disklist.............................................218
Журнальные файлы..........................................219
Отладка...................................................220
Восстановление файла из резервной копии...................223
Существующие альтернативы; другие открытые пакеты
резервного копирования....................................224
10.9.	Коммерческие системы резервного копирования..............225
ADSM/TSM..................................................225
Veritas.................................................  225
Legato...............................................  -..226
Прочие программы......................................... 226
10.10.	Рекомендуемая литература................................226
Глава 11 Система Syslog и журнальные файлы...............................227
111.	Методики обработки журнальных файлов....................227
Уничтожение журнальных файлов.............................227
Повторное использование журнальных	файлов.................228
Архивирование журнальных файлов.........................  230
11-2. Поиск журнальных файлов.........—....................  -.230
11.3.	Файлы, которыми нельзя управлять.......................  232
11.4	Особенности журнальных файлов в различных
операционных системах...................................—......232
11.5.	Система регистрации событий: Syslog.......................233
Конфигурирование демона syslogd  ..........................234
Улучшения системы Syslog в Red Hat........................237
Улучшения системы Syslog во FreeBSD.......................238
Примеры конфигурационных файлов...........................239
Пример выходной информации системы Syslog.................241
Разработка схемы регистрации для конкретной организации.... ....242
Программы, использующие систему Syslog..................  243
Отладка системы Syslog.....................—..............244
Использование функций Syslog в сценариях...............  .245
11.6.	Поиск полезной информации в журнальных файлах...........246
Глава 12. Драйверы и ядро................................................248
12.1.	Типы ядер...............................................249
12.2.	Зачем нужно конфигурировать ядро........................250
12.3.	Конфигурирование ядра в Solaris ....................... 250
Область построения ядра.................................  250
Конфигурирование ядра посредством файла /etc/system.......252
Пример файла /etc/system..................................252
Отладка конфигурации....................................  253
12.4	Построение ядра HP-UX.....................................253
12.5.	Конфигурирование ядра Linux..............................255
Построение двоичного ядра Linux...........................256
Настройка конфигурации..................................  257
12.6.	Построение ядра FreeBSD..................................258
Схема построения ядра.....................................259
907
Ревизия аппаратных средств системы ........................259
Создание файла конфигурации в каталоге SYS/i386/conf.......259
Выполнение команды config..................................260
Выполнение команды make depend.............................260
Построение ядра............................................260
Инсталляция ядра...........................................261
Тестирование и отладка ядра......—..............-..........261
Документирование ядра......................................261
12.7.	Создание файла	конфигурации в BSD-системе...............261
Ключевое слово	maxusers................................  262
Ключевое слово	options ..................................263
Ключевое слово	config....................................264
Аппаратные устройства......................................265
Ключевое слово pseudo-device...............................266
Пример файла конфигурации .................................267
Настройка ядра.............................................269
12.8.	Добавление драйверов устройств............................270
Номера устройств ..........................................271
Добавление драйвера устройства	в Solaris...................272
Добавление драйвера устройства	в Linux....................273
Добавление драйвера устройства во FreeBSD...............  .	.275
12.9.	Файлы устройств...........................................275
12.10.	Соглашения об именах устройств...........................276
12.11.	Загружаемые модули ядра...........................-......277
Solaris....................................................277
Linux......................................................278
FreeBSD..................................................  280
12.12.	Рекомендуемая литература.............................    280
4i 1сть II. Работа в сетях
Глава 13. Сети	TCP/IP...................................................283
13.1.	TCP/IP и Internet.........................................284
Краткая история............................................284
Кто сегодня управляет	сетью Internet.......................285
Сетевые стандарты и	документация...........................285
13.2.	Семейство TCP/IP.........................................287
13.3.	Пакеты и инкапсуляция.....................................288
Канальный уровень........................................  289
Адресация пакетов......................................    291
Порты....................................................  292
Типы адресов............................................   293
13.4.	IP-адреса.......................................... ......293
Классы 1Р-адресов.................................      ...	293
Организация подсетей...................................... 294
Кризис IP-адресов.....................................     297
CIDR: протокол бесклассовой междоменной маршрутизации........298
908
Выделение адресов.,....................................... 300
Частные адреса и система NAT.............................301
Адресация в стандарте IPv6.............................. 302
13.5.	Маршрутизация........................................... 305
Таблицы маршрутизации....................................305
Переадресуюшие пакеты протокола ICMP.....................307
13.6.	ARP: протокол преобразования адресов.....................307
13.7.	DHCP: протокол динамического конфигурирования узлов .....309
Программное обеспечение DHCP ............................309
Схема работы DHCP........................................310
DHCP-сервер ISC..........................................311
13.8.	РРР: протокол двухточечного соединения...................313
Производительность РРР...................................314
Подключение к сети посредством РРР . ....................315
Как заставить компьютер общаться по протоколу РРР........315
Управление РРР-каналами—.................................315
Поиск компьютера для связи ............................. 315
Присвоение адресов.....................................  316
Маршрутизация. ......................................    316
Безопасность.................  -.........................316
Терминальные серверы...................................  317
Диалоговые сценарии..................................... 317
13.9.	Вопросы безопасности..................................  317
Перенаправление IP-пакетов...............................317
Переадресуюшие ICMP-директивы............................317
Направленная маршрутизация...............................318
Широковещательные ping-пакеты и другие виды
направленных широковещательных сообщений.................318
Брандмауэры UNIX..................................    -....318
Виртуальные частные сети..........................   ....319
IPSEC. безопасный протокол 1Р..........................  319
13.10.	Добавление компьютеров к сети..........................320
Присваивание сетевых имен и LP-адресов...................321
Команда ifconfig: конфигурирование сетевых интерфейсов...322
Команда гонге: конфигурирование статических маршрутов.......324
Стандартные маршруты.....................................326
Конфигурирование DNS..................................   326
13.11.	Конфигурирование сети в различных системах.........    328
13.12.	Сетевое конфигурирование Solaris.......................329
Базовое конфигурирование...............................  329
Примеры конфигураций.....................................331
Конфигурирование DHCP ...................................332
Динамическое переконфигурирование и настройка............333
Безопасность, брандмауэры, фильтрация и система NAT......335
Конфигурирование РРР.....................................336
Особенности сетевого конфигурирования....................337
909
13.13,	Сетевое конфигурирование HP-UX......................-..337
Базовое конфигурирование................................ 338
Примеры конфигураций.....................................339
Конфигурирование DHCP....................................341
Динамическое переконфигурирование и настройка............341
Безопасность, брандмауэры, фильтрация и система	NAT......342
Конфигурирование РРР . ................................  343
Особенности сетевого конфигурирования.. .................344
13.14.	Сетевое конфигурирование Red	Hat...............344
Базовое конфигурирование...............................  344
Примеры конфигураций.....................................346
Конфигурирование DHCP....................................347
Динамическое переконфигурирование и настройка............347
Безопасность, брандмауэры, фильтрация и система	NAT......348
Конфигурирование РРР.....................................352
Особенности сетевого конфигурирования...............-....352
13.15.	Сетевое конфигурирование FreeBSD........................352
Базовое конфигурирование................................ 353
Примеры конфигураций....................... —..............353
Конфигурирование DHCP....................................355
Динамическое переконфигурирование	и настройка............355
Безопасность, брандмауэры, фильтрация и система NAT........356
Конфигурирование РРР...................................  360
Особенности сетевого конфигурирования....................362
13.16.	Рекомендуемая литература................................362
Глава 14. Маршрутизация...........................................      364
14.1.	Подробнее о маршрутизации пакетов....................... 365
14.2.	Демоны и протоколы маршрутизации........................367
Дистанционно-векторные протоколы...............—..........368
Топологические протоколы................................ 369
Метрики кратчайшего пути.................................370
Внутренние и внешние протоколы...........................370
14.3.	Основные протоколы маршрутизации......................  371
R1P: протокол маршрутной информации.—....................371
R1P-21 протокол маршрутной информации, версия 2..........371
OSPF: открытый протокол первоочередного обнаружения
кратчайших маршрутов...................................  372
IGRJP и EIGRP: протоколы маршрутизации между
внутренними шлюзами..................................    372
1S-IS: протокол связи между	промежуточными системами.....373
MOSPF, DVMRP и PIM: протоколы многоадресной
маршрутизации........................................    373
Протокол обнаружения маршрутизаторов.....................373
14,4.	Демон routed: стандартный демон маршрутизации...........373
14.5.	Демон gated: более удачный демон маршрутизации.....  ...374
Управление начальным запуском и параметрами демона.......375
Трассировка........................................      375
9.
Конфигурационный файл....................................-.376
Задание конфигурационных параметров........................377
Определение сетевых интерфейсов...........................-377
Другие определения.........................................379
Конфигурирование протокола RIP.............-.......-.......380
Базовые сведения о протоколе OSPF..........................381
Конфигурирование протокола OSPF...........................-383
Конфигурирование переадресующих 1СМР-директив..............384
Статические маршруты..................................-....384
Экспортируемые маршруты....................................385
Полный пример конфигурации демона	gated.................386
14.6.	Особенности маршрутизации в различных системах............388
14.7.	Выбор стратегии маршрутизации...............-.......-.... .388
14.8.	Маршрутизаторы Cisco......................................390
14.9.	Рекомендуемая литература..................................392
Глава 15. Сетевые аппаратные средства....................................393
15.1.	ЛВС, ГВС и ОВС.........................................  -393
15.2.	Ethernet: общепризнанная ЛВС.............................-394
Как работает Ethernet......................................395
Топология Ethernet.......................................  396
Неэкранированная витая пара............................ ...397
Соединение и расширение сетей Ethernet.....................398
15.3.	FDDI: дорогая локальная сеть-разочарование................401
15.4.	ATM: локальная сеть несбывшихся надежд....................403
15.5.	Ретрансляция кадров: глобальная убыточная	сеть.—......... 404
15.6.	ISDN: глобальная сеть-невидимка...........................405
15.7.	DSL: всенародная глобальная сеть..........................405
15.8.	Будущее сетей............................................ 406
15.9.	Тестирование и отладка сетей..............................407
15.10.	Построение кабельной системы..........................., 407
Варианты разводки НВП...................... ---............407
Офисные подключения.....................................   408
Стандарты кабельных систем.........................-.......408
15.11.	Вопросы проектирования сетей..........................  409
Архитектура сети и архитектура здания....................  409
Существующие сети...........................................410
Модернизация.........................................      410
Перегрузка................................................411
Обслуживание и документирование ..........................411
15.12.	Вопросы управления......................................411
15.13.	Рекомендуемые поставщики................................412
15.14.	Рекомендуемая литература............................... 413
Глава 16. Система доменных имен .......................................  414
16.1.	DNS для нетерпеливых: добавление нового компьютера........ ..414
16.2.	История DNS............................................  416
16.3.	Основные задачи DNS...................................... 417
911
16.4.	Что нового в DNS..........................................418
16.5.	Пространство имен DNS.................................... 419
Хозяева своих доменов.... .............................    422
Выбор имени домена.....................................-...423
Взрывоподобный рост числа домеиов..........................423
Регистрация домена второго уровня..........................424
Создание собственных поддоменов............................424
16.6.	Пакет BIND................................................425
Версии пакета BIND.........................................425
Определение текущей версии.................................425
Компоненты пакета BIND.....................................427
Демон named: сервер имен пакета BIND.......................427
Авторитетные и кэшируюшие серверы..........................428
Рекурсивные и нерекурсивные серверы........................429
Модуль распознавания.............  -.......................430
Выполнение запросов из командной строки....................430
16.7.	Как работает DNS........................................  431
Делегирование..............................................431
Кэширование и эффективность............................-...432
Расширенный протокол DNS...................................433
16.8.	Работа с клиентом BIND......................  ............434
Конфигурирование распознавателя..........................  434
Тестирование распознавателя..............-.............-...437
Влияние на остальную часть системы................-........437
16-9- Конфигурирование сервера BIND ...................-........437
Аппаратные требования....................................  438
Запуск демона named......................................  438
Конфигурационные файлы.....................................438
Инструкция include.........................................440
Инструкция options.........................................440
Инструкция acl............................................ 445
Инструкция server......................................... 446
Инструкция logging.........................................447
Инструкция zone............................................447
Инструкция key...........................................  450
Инструкция trusted-keys....................................450
Инструкция controls....................................... 451
Инструкция view............................................451
16.Ю. Примеры конфигурации пакета	BIND ......................  452
Домашний Linux-компьютер.................................. 453
Кафедральный сервер........................................454
Сервер компании, занимающейся	Web-хостингом................458
16.11.	База данных DNS......................................  ..459
Записи о ресурсах......................................  -.459
Запись SOA.............................................    461
Записи NS................................................  464
Записи А............................................... ...464
912
Записи PTR.................................................465
Записи MX................................................  466
Записи CNAME.............................................. 468
Специальное	применение записей CNAME.......................469
Записи LOC..............................................-..470
Записи SRV...............................................  471
Записи ТХТ...............................................  473
Записи ресурсов IPv6.......................................473
Записи Аб..................................................474
Записи DNAME ..........................................-.-.474
Команды в файлах зон.......................................477
Зона localhost.............................................478
Связующие записи: ссылки между зонами......................478
16.12.	Обновление файлов зон....................................480
Зонные пересылки...........................................481
Динамические обновления...............................-....482
16.13.	Вопросы безопасности.....................................483
Еще раз о списках управления доступом......................484
Ограничение возможностей демона named......................485
Безопасные межсерверные взаимодействия
посредством спецификаций TSIG	и TKEY....................486
Технология DNSSEC..........................................488
Microsoft — плохо, UNIX — хорошо........................ . 492
16.14.	Тестирование и отладка...................................492
Журнальная регистрация.....................................493
Уровни отладки........................................     497
Отладка посредством программы ndc.......................   497
Отладка с помощью программ nslookup, dig и host ........-..499
Напрасное делегирование....................................502
16.15.	Всякая всячина...................................   .....503
Файл '‘подсказок”............................-...........  503
Конфигурирование домена localhost............-..............504
Средства управления узлами.............. ..................504
Доступ к DNS для систем, не подключенных	к Internet .......505
16.16.	Особенности DNS в различных	операционных системах........505
Solaris................................. ...................505
HP-UX......................................................506
Red Hat....................................................507
FreeBSD....................................................508
16.17.	Рекомендуемая литература..................................— 509
Списки рассылки и	группы новостей.......................509
Книги и другая документация................................510
Ресурсы в Internet.........................................510
Документы RFC.........................................-....510
Глава 17. Сетевая файловая система........................................513
17.1.	Общая информация	об NFS................................513
Версии протокола NFS ....................................  513
913
Выбор транспортного протокола.............................514
WebNFS....................................................515
Блокировка файлов.........................................515
Дисковые квоты.......................................  ...515
Глобальные идентификаторы пользователей	и	групп.........516
Учетные записи root и nobody.........................     516
Секретные ключи и монтирование без учета	состояния........517
Соглашения об именах совместно используемых
файловых систем......................................     517
Безопасность и NFS .....................................  517
17.2	Серверная часть NFS....................................  518
Команда share и файл dfstab (Solaris).....................520
Команда exportfs и файл exports (HP-UX, Red Hat, FreeBSD)...521
Демон nfsd: файловый сервис...........................    525
173.	Клиентская часть NFS ....................................527
Демоны biod и nfsiod: кэширование на стороне клиента......527
Монтирование удаленных файловых систем....................527
Выбор порта.........................................._....529
17.4.	ПрО1рамма nfsstat: отображение статистики NFS..	..529
17.5.	Специализированные файловые серверы NFS................  530
17.6.	Автоматическое монтирование............................  531
17.7.	Программа automount: самый первый автомонтмровшик........532
Таблицы косвенных назначений............................  533
Таблицы прямых назначений.................................533
Главные таблицы...........................................534
Исполняемые таблицы.......................................534
Программа automount и дублирующиеся	файловые системы......534
Автоматическое выполнение программы	automount.........535
Особенности Red Hat Linux...............................  536
17.8.	Программа amd: более совершенный автомонтировщик.........536
Таблицы назначений программы amd..........................537
Запуск программы amd......................................538
Останов программы amd.....................................539
17.9.	Рекомендуемая литература.............................    539
Глава 18. Совместное использование системных файлов......................540
18.1.	Предмет совместного использования......................  541
18.2.	Копирование файлов.....................................  542
Утилита rdist: принудительная рассылка...... ...........  542
Программа rsync: более безопасная рассылка	файлов________ 545
Система expect: рассылка файлов	по	запросу................547
18.3.	NIS: сетевая информационная служба.......................549
Сетевые группы............................................550
Задание приоритетов для источников
административной информации.............................  551
Преимущества и недостатки NIS...........................  552
Схема работы N1S........................................  553
914
Создание NIS-домена......................................555
Особенности N1S в различных операционных системах... ....55?
18.4.	N1S+: потомок NIS.............................          558
18.5.	LDAP: упрощенный протокол доступа к каталогам...........560
Документация и спецификации LDAP........................ 561
Практическое применение протокола LDAP........... . 562
Глава 19. Электронная почта.............................................563
19.1.	Системы электронной почты...............................565
Пользовательские агенты.............................—.......566
Транспортные агенты......................................568
Агенты доставки..........................................568
Хранилища сообщений.................................... .568
Агенты доступа...........................................569
Агенты подачи почты.................................   ..569
19-2.	Анатомия почтового сообщения............................570
Адресация почты...................................  —....570
Заголовки почтовых сообщений.................,...........571
19.3.	Основные	принципы организации электронной почты........575
Почтовые	серверы...................................    576
Почтовые	каталоги пользователей........................577
Протоколы IMAP и POP...................................  578
19.4.	Почтовые	псевдонимы..................................  579
Получение списков рассылки из файла......................581
Направление почты в файл.................................582
Направление почты в программу .........................  582
Примеры псевдонимов....................................  583
Перенаправление почты....................................584
Хэшированная база данных псевдонимов ....................586
Списки рассылки и программы для работы с ними............587
LDAP.....................................................590
19.5.	Почтмейстер sendmail....................................592
История программы sendmail...............................593
Версии программы sendmail. поставляемые
производителями систем...................................594
Инсталляция программы sendmail...........................595
Файл переключения сервисов...............................596
Режимы работы............................................... 597
Очередь почтовых сообщений...............................598
19.6.	Конфигурирование программы sendmail.....................601
Конфигурирование с помощью препроцессора т4............  601
Файлы, необходимые для конфигурирования программы sendmail.603
Создание файла конфигурации из готового тс-файла.........603
19.7.	Базовые примитивы конфигурации программы sendmail.......605
Макрос VERSIONID.......................................... 605
Макрос OSTYPE......................................      605
Макрос DOMAIN............................................607
Макрос MATLER...................................    .....607
915
19.8.	Дополнительные примитивы конфигурации
программы sendmail...........................-...................	. .609
Макрос FEATURE................................................609
Средство usecwfile........................................... 609
Средство redirect.............................................610
Средство always_add_domain...................................610
Средство nocanonjfy...........................................610
Таблицы и базы данных.........................................611
Средство mailertable..........................................612
Средство genericstable........................................613
Средство virtusertable........................................613
Средство ldap_raiiting....................................    614
Маскирование адресов и макрос MASQUERaDE_AS...................615
Макроконстанты MAIL HUB и SMART HOST............—.............616
Маскирование и маршрутизация............,	.617
Средство nullclient.........................................  618
Средства local_lmtp и	smrsh...................................618
Средство local_procmail.......................................619
Макросы LOCAL_*.............................................  619
Конфигурационные опции....................................... 619
19 9. Примеры файлов конфигурации...............................   622
Домашний компьютер студента факультета
вычислительной техники............	..........................623
Небольшая компания, использующая программу sendmail..........624
Еше один пример модели с главным почтовым сервером...........627
19-10. Средства программы sendmail для борьбы со спамом............628
Ретрансляция................................................  630
База доступа................................................  633
Занесение пользователей или узлов в “черные” списки...........635
Проверка заголовков.........................................  636
Обработка спама.............................................	.637
Прим	еры спама....................................      ...637
19.11.	Безопасность и программа sendmail...........................641
Владельцы файлов............................................  642
Права доступа.................................................643
Безопасная пересылка почты в файлы и программы................644
Опции конфиденциальности. ....................................644
Запуск программы sendmail при помоши команды chroot..........645
Отражение атак типа “отказ от обслуживания”............  .....646
Фальсификации.................................................647
Безопасность сообщений...................... ...... ......... 648
SASL: простой протокол зашиты	и	аутентификации............648
19.12.	Статистика, тестирование и отладка....	..................649
Тестирование и отладка.......................................649
Доставка с комментариями......................................650
Обмен данными по протоколу SMTP...............................651
Регистрация событий.....................................   ...652
9 5
19.13.	Почтовая система Postfix................................653
Архитектура системы Postfix...............................	.653
Конфигурирование системы Postfix..........................654
Борьба со спамом..........................................656
Примеры конфигурирования системы Postfix..................657
19.14.	Рекомендуемая литература................................658
Глава 20. Управление сетями..............................................660
20.1.	Поиск неисправностей в сетях.............................661
20.2.	Команда ping: проверка доступности компьютера............662
20.3.	Программа trace route: отслеживание IP-пакетов...........664
20.4.	Команда netstat: получение всевозможной
информации о состоянии сети ....................................667
Контроль состояния сетевых соединений.....................667
Просмотр информации о конфигурации интерфейса.............668
Проверка таблицы маршрутизации............................669
Просмотр статистики функционирования
различных сетевых протоколов..............................670
20.5.	Анализаторы пакетов......................................671
Программа snoop: анализатор пакетов в Solaris.............672
Программа nettl: анализатор пакетов в HP-UX............,..673
Программа tepdump: самый лучший анализатор................673
20.6.	Протоколы управления сетями..............................674
20.7.	SNMP: простой протокол управления сетью..................675
Структура протокола SNMP..................................676
Операции протокола SNMP...................................677
RMON база М1В для удаленного мониторинга..................678
20.8.	Агенты SNMP..............................................678
SNMP-агент в Solaris......................................679
SNMP-агент в HP-UX........................................679
SNMP-агент UCD............................................681
20.9.	Программы управления сетью...............................682
Утилиты пакета UCD........................................682
MRTG: многомаршрутный визуальный анализатор трафика.......683
NOCOL: интерактивный сетевой административный центр.......684
Коммерческие системы сетевого управления..................685
20.10.	Рекомендуемая литература................................686
Глава 21. Безопасность...................................................687
21.1.	Семь правил зашиты.....................................  688
21.2.	Слабые места 8 системе безопасности......................689
21.3.	Проблемы зашиты файла /etc/passwd........................690
Проверка и выбор паролей..................................691
Теневые пароли............................................692
Групповые и совместно используемые учетные записи.........693
Устаревание паролей.......................................693
Пользовательские интерпретаторы команд....................694
Привилегированные учетные записи..........................694
917
21.4.	Программы с установленным битом смены
идентификатора пользователя............................... 694
21.5.	Специальные права доступа.................................695
21.6	Различные аспекты защиты................................  696
Удаленная регистрация событий..........................    696
Защищенные терминалы.....................................  697
Файлы /etc/hosts.equiv и “/.rhosts.....................    697
Демоны rexd, rexecd и tftpd................................697
Демон fingerd ...........................................  698
Безопасность и NIS.......................................  698
Безопасность и NFS.........................................699
Безопасность и sendmail .................................  699
Безопасность и резервное копирование.......................699
Троянские кони....—.....................................  .699
21.7.	Инструментальные средства зашиты..-.......................700
Программа nmap: сканирование сетевых портов................700
SAINT: выявление слабых мест сетевых систем................702
Nessus: сетевой сканер следующего поколения................702
Программа crack: поиск ненадежных паролей..................703
Программа tcpd: защита Internet-сервисов.................. 703
COPS аудит системы зашиты..................................704
Программа tripwire: контроль изменений в системных файлах...705
ТСТ: криминалистическая экспертиза.........................706
21.8.	Системы криптографической защиты........................  707
Kerberos: унифицированный подход к сетевой безопасности....707
PGP: высокая конфиденциальность............................708
SSH: безопасный интерпретатор команд.......................709
SRP: безопасные удаленные пароли.........................  711
OPIE: универсальные одноразовые пароли...................  711
21.9.	Брандмауэры..............................................712
Фильтрация пакетов.....................................    712
Принципы фильтрации сервисов.............................. 713
Сервисные брандмауэры....................................  714
Анализирующие брандмауэры.............	  ...714
Насколько безопасны брандмауэры.............................7 И
21.10.	Источники информации на тему безопасности................715
Организация CERT...........................................715
Сервер SecurityFocus.com и список рассылки BugTraq.........716
Организация SANS ........................................  716
Информационные ресурсы операционных систем.................716
Другие списки рассылки и Web-узлы..........................717
21.11.	Что нужно делать в случае атаки на сервер.._________     717
21.12.	Рекомендуемая литература..................................719
Глава 22. Web-хостинг и серверы Internet..................................720
22.1.	Web-хостинг.......................................    ...720
9Д
22.2.	Основы Web-хостинга.......................................721
Унифицированные указатели	ресурсов........................722
Принцип работы HTTP........... .......................    723
CGI-сценарии: создание динамического Web-содержимого......723
Распределение нагрузки....................................724
22.3.	Инсталляция НТТР-сервера..................................724
Выбор сервера.................-...........................724
Компилирование и инсталляция сервера	Apache.............. 725
Конфигурирование сервера Apache —........................-726
Запуск сервера Apache.................................... 727
22.4.	Виртуальные интерфейсы.........................  -.......727
Конфигурирование виртуальных интерфейсов..................728
Передача серверу Apache информации о	виртуальном интерфейсе..730
22.5.	Кэширование и прокси-серверы .............................731
Инсталляция сервера Squid.................................732
22.6.	Установка анонимного FTP-сервера..........................732
22.7.	Группы новостей Usenet ...................................734
Подписка на новости Usenet............................... 735
Программное обеспечение Usenet..........................  736
Нужны ли новости Usenet?...................—..............736
Часть III. Разное
Глава 23.	Печать........................................................739
23.1.	Мини-словарь терминов по печати...—....................  740
23.2.	Типы принтеров ........................................  741
Последовательные	и параллельные принтеры................742
Сетевые принтеры........................................  742
Жизнь без PostScript....................................  743
23.3	BSD-система печати ..................................    743
Обзор процесса печати...................................... 743
Управление средой печати...............................  .745
Демон Ipd: BSD-спулер печати...............—..........  ..745
Команда 1рг: выдача заданий на принтер....................746
Команда Ipq: просмотр очереди печати..............-.......746
Команда Iprm: удаление заданий.........................   747
Команда Ipc: внесение административных изменений..	..747
Файл /etc/printcap ..........................................749
Переменные базы данных printcap.........................  750
Переменные базы данных printcap
для последовательных устройств..........................  755
Расширения базы данных printcap...........................756
Печать не на принтеры.....................................756
23.4	Печать в System V..................................  —...757
Обзор..........................................   -.......757
Пункты назначения и классы------ -------------------------758
Краткое описание команды 1р...............................758
V19
Команды Ipsched и Ipshut: запуск и останов печати....... ..759
Команда Ipadmin: конфигурирование среды печати.............759
Команда Ipstat: получение информации
о состоянии системы печати.................................762
Команда cancel: удаление заданий печати....................763
Команды accept и reject: управление организацией очереди.....763
Команды enable и disable: управление печатью...............764
Команда Ipmove: перемещение заданий........................764
Интерфейсн ые п рограммы.................................  764
Что делать, если программу 1р заклинило?...................765
23.5.	Добавление принтера.......................................766
Solaris..................................................  767
HP-UX..................................................... 770
Red Hat.............................................       771
FreeBSD..................................................  772
23.6.	Спулер LPRng.. ...	....... .............................. .773
Команды LPRng..............................................774
Получение и инсталляция LPRng ...........................  775
Файл /etc/lpd.conf: конфигурирование демона Ipd............776
Файл /etc/ipd.penns: настройка прав доступа............. ..776
Настройка базы данных printcap.............................777
Фильтры................................................  ..777
Учет.....................................................  778
23.7.	Устранение проблем при печати.. ......................... 778
23.8.	Основные программы печати.....	   779
Программа rlpr............... ...... ......................779
Программа ghostscript.	  779
Программа mpage..	... .... . ...................779
Программа enscnpr .......................................  780
23.9.	Основные принципы работы с	принтером......................780
Организуйте учет работы принтера...........................780
Используйте страницы-заголовки только
в случае необходимости...................................  780
Обеспечьте утилизацию отходов......................... ....781
Обеспечьте предварительный просмотр . .	.781
Приобретайте дешевые принтеры..............................781
Держите под рукой запасные картриджи с тонером.............782
Защищайте принтеры ...................................    .782
Глава 24. Обслуживание аппаратных средств...............................  783
24.1.	Основы технического обслуживания..........................783
24.2.	Контракты на обслуживание.............................    784
Обслуживание на месте................................      784
Обслуживание с заменой плат ...........................    785
Гарантии.. ..............................................  785
24.3.	Уход за печатными платами...	  785
Статическое электричество ..	 785
Переустановка плат................................. ..	.. ...786
У20
24.4.	Мониторы...................................................786
24.5.	Модули памяти..............................................786
24.6.	Профилактическое обслуживание............................. 781
24.7.	Условия эксплуатации.......................................788
Температура-................................................788
Влажность.................................................. 788
Охлаждение офисных помещений................................788
Охлаждение машинных залов...................................789
Контроль температуры....................................... 790
24.8.	Источники питания—.......................................  790
Удаленное управление питанием...........................  --791
24.9.	Стеллажи для аппаратуры..................................  791
24.10.	Инструменты,..............................................792
Глава 25. Анализ производительности........................................793
251.	Как повысить производительность............................794
25.2.	Факторы, влияющие на производительность—.................. 795
25.3.	Проверка производительности системы........................796
Анализ использования центрального процессора................796
Управление памятью в UNIX...................................799
Анализ использования памяти.................................800
Анализ операций обмена с диском.............................802
Виртуальный помошник Адриан.................................804
Команда procinfo: отображение данных
о производительности в Red Hat......................... . 805
Команда pstat: вывод статистических данных во FreeBSD.......805
25.4.	Помогите! Моя система почти остановилась!..................806
25.5.	Рекомендуемая литература...................................807
Глава 26. Взаимодействие с Windows.........................................808
26.1.	Совместное использование файлов и принтеров............... 808
Файловая система NFS_________—..............................809
Файловая система CIFS.....................................  809
Samba: система CIFS для UNIX................................809
Инсталляция и конфигурирование пакета Samba.................810
Отладка пакета Samba....................................    812
26.2.	Безопасная эмуляция терминала
с использованием системы SSH...................................  813
26.3.	Эмуляторы X Windows...................................... .813
26.4.	Почтовые клиенты на персональных компьютерах...............814
26.5.	Резервное копирование на персональных компьютерах..........814
26.6.	Мультисистемная загрузка.................................  815
26.7.	Запуск приложений Windows в среде UNIX.....................815
26.8.	Советы по аппаратным средствам персональных компьютеров....816
Глава 27. Стратегия и политика администрирования...........................817
27.1.	Правила и методики.......................................  818
Правила безопасности......................................  820
Правила для пользователей ......... ,	.....821
921
Правила для администраторов..............-................823
Правила и методики для экстренных случаев.................824
Планирование на случай аварий..............................825
Непредвиденные обстоятельства..............................827
27.2.	Правовые аспекты.........................................827
Ответственность......................................     828
Шифрование..............................................  828
Зашита авторских прав...........................—.........828
Конфиденциальность........................................829
Внедрение в жизнь политики администрирования..............830
Лицензии на программное обеспечение...................    832
Спам: навязчивая почта коммерческого содержания...	 833
27.3.	Некоторые интересные факты.............................  833
Результаты опроса, проведенного организацией	SAGE.........834
Результаты опроса, проведенного организацией	SANS.........835
27.4.	Объем и качество обслуживания............................835
27.5.	Информационно-диагностические системы.....................836
27.6.	Как руководить руководителями............................837
27.7.	Прием на работу', увольнение и обучение............      838
Корректировка позиции.....................................839
Операторские войны..............................„.........840
Последовательное улучшение............................    840
27.8.	Невыдуманные истории...................................  841
Ошибка начальника (номер один)............................841
Ошибка начальника (номер два).............................841
Дэн, твое новое имя — Лестер..............................842
Кого увольнять? ..........................................842
Упрямец Джо.......................................        842
Приглашения на свадьбу................................... 843
Порнографические GIF-изображения..........................843
Перенос данных.......................................  ...844
Билл должен умереть!.....................—............    845
27.9.	Размещение и обновление программ.........................845
Управление программным обеспечением в крупных системах..... 846
Обновление программ.......................................847
Полезные программы сторонних производителей...............848
27.10	Внутренняя документация...........................      851
27.11.	Закупка оборудования....................................852
27.12.	Списание оборудования..................................853
27.13.	Патенты на программное обеспечение......................854
27.14.	Организации и конференции...............................855
SAGE: гильдия системных администраторов...................856
Списки рассылки и Web-ресурсы.............................857
Литература..............................................  858
27.15.	Стандарты...........................................    858
27.16.	Образцы документов...................................  860
27.17.	Рекомендуемая литература................................861
922
Глава 28. Процессы-демоны.................*................................862
28.1.	Основные демоны.........................................   863
28.2.	Демон cron: планирование команд............................864
28.3.	Демон inetd. управление демонами..........,................. 865
Конфигурирование демона inetd...............................865
Файл services.............................................. 866
Перезапуск демона inetd...................................... 867
Защита демона inetd....................................... .867
Демон portmap/rpcbind: преобразование номеров
RPC-сервнсов в номера портов TCP и UDP......................868
28.4.	Системные демоны................v........................  868
Демон замещения страниц.....................................868
Демон подкачки............................................  868
Демон синхронизации файловых систем........................ 869
28.5.	Демоны печати............................................  869
Ipd: управление печатью в BSD-системах......................869
Ipsched: управление печатью в АТТ-системах..................869
ripdaemon: печать из BSD в HP-UX............................870
28.6.	Демоны NFS................................................ 870
nfsd: файловый сервис...................................    870
mountd: ответы на запросы монтирования......................870
amd и automount: монтирование файловых систем по запросу....870
lockd и statd: управление файлами блокировки NFS............870
biod: кэширование	блоков NFS..............................871
28.7.	Демоны NIS..................................................871
ypbind: поиск серверов NIS..................................871
ypserv: сервер NIS......................................... 871
ypxfrd: пересылка баз данных NIS............................871
rpc.nisd: сервер NIS+.....................................  871
28.8.	Демоны Internet......................................  .....871
talkd: сервер программы talk................................872
comsat: уведомление пользователей о поступлении почты.......872
sendmail: транспортировка электронной почты.................872
snmpd: сервер удаленного управления сетями..................872
rwhod: ведение списка удаленных пользователей..........-.......S72
ftpd: сервер пересылки файлов...............................873
popper: простейший сервер почтового яшика.................  873
imapd: высококлассный сервер почтового	ящика............ ...873
rlogind: сервер удаленной регистрации.......................873
telnetd: еше один сервер удаленной регистрации..............873
sshd: безопасный сервер удаленной регистрации...............874
rshd: сервер удаленного выполнения команд..................—	874
rexecd: еше один сервер удаленного выполнения команд........874
rpc.rexd: третий сервер удаленного выполнения команд........874
routed: ведение таблиц маршрутизации......................  874
923
gated: ведение сложных таблиц маршрутизации................874
named: сервер DNS..........................................875
syslogd: обработка сообщений об ошибках....................875
fingerd: поиск пользователей...............................875
httpd. сервер World Wide Web...............................875
28.9.	Демоны синхронизации времени..............................875
timed: синхронизация часов.................................876
xntpd: более точная синхронизация часов....................876
28.10.	Демоны начальной загрузки и конфигурирования..............876
boorpd: сервер начальной загрузки..........................877
tftpd: тривиальный сервер пересылки файлов............ ....877
rarpd: преобразование Ethemet-адресов	в IP-адреса........  877
bootparamd: усовершенствованная поддержка
бездисковой работы.........................................877
dhcpd: динамическое назначение	адресов.....................877
Предметный указатель.............................................878