Text
                    Эви Немет, Гарт Снайдер
Скотт Сибасе, Трент Р. Хейн
ЧЛЯ ПРОФЕССИОНАЛОВ
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 настолько мал, что его невозможно собрать вр