Руководство системного администратора • третье издание { h h y с п п т п р



Pdf просмотр
страница45/82
Дата12.11.2016
Размер7.94 Mb.
Просмотров13854
Скачиваний0
ТипРуководство
1   ...   41   42   43   44   45   46   47   48   ...   82
kill с аргументами наподобие программы ndc.
Red Hat Linux 6.1 поставляется с B I N D 8.2, а все файлы находятся н стандартных каталогах (табл. 16.19). В Red Hal 6.2, как и во FreeBSD. используется версия пакета Р, поэтому информацию о файлах вы можете почерпнуть из следующего раздела. Файл "переключения сервисов" такой же, как ив. Он задает приоритеты различных источников данных. (Информацию по нему можно получить посредством команды т в пане) Файл Каталог Описание resolv.conf /etc Файл конфигурации распознавателя named /usr/sbin Демон сервера имен muned-xfer /usr/sbin Код модуля зонных пересылок named.boot /etc Конфигурационный файл сервера имен named.pid /var/run Идентификатор процесса демона named named-run /var/tmp Выходная отладочная информация named.Mats /var/tmp Выходная статистическая информация nameddump.db /var/tmp Образ всей базы данных
R e d H o t
Глоно 16. Система доменных имен
I
507
Таблица 16.19. Фойлы покето BIND в Red Hot Linux Файл Каталог Описание resolv.eonf
/etc Файл конфшураиии распознавателя named
/usr/sbin Демон сервера имен named-xfer
/usr/sbin Код модули зонных пересылок named.conf
/«C Конфигурационный файл сервера имен named.pid
/var/run Идентификатор процесса демона named namcd.run
каталог
1
Выходная отладочная информации named.stats
tcatna-ioe
1
Выходная статистическая информация named.niemstats
каталог
1
Статистика использования памяти nameddump.db
каталог*
Обра.» всей базы ланных
1
Этот кагалог указан в файле /etc/named.conf как начальный дым файлов При отсутствии файла nsswitch.conf система по умолчанию принимает приведенную ниже конфигурацию h o s t s : dns [!UWAVAIL=return] f l i e s Предложение ! UN AVAIL, которое, как сказано в документации, установлено по умолчагшю. кажется нам неправильным. К тому же. оно вступает в противоречие с файлом-примером, поставляемым с Red Hai, где строка hosts выглядит следующим образом h o s t s : d b f i l e s n i s p l u s dns Мы рекомендуем такую конфигурацию h o s t s : f i l e s dns Весть ряд образцов конфигурационных файлов. Все они находятся в каталоге /etc и снабжены хорошими комментариями. Для файла named.conf отсутствует своя страница.
F r e e B S D Во FreeBSD 3.4 и 4.0 входит пакет B I N D Р Файл "переключения сервисов" называется /etc/host.conf и определяет порядок обращения к информационным службам только в процессе преобразования имен. Возможные источники информации указаны в отдельных строках в том порядке, в котором они должны опрашиваться. и начала пооверяетсч файл e t c / h o s t s h o s t s
№ Следующим опрашивается сервер имен o i n d
# Если сконфигурировано .-лу:*6а YP/NIC-» активизируйте следукш^» строку
И
u s
Рели фаи;ы host.couf не существует, первой опрашивается система D.NS. В случае неудачи проверяется файл /ctc/hosts Во FreeBSD файл namcd.conf переместился из каталога /etc в каталог /etc/namedh. Имена файлов и каталогов, в которых расположены файлы, приведены в табл. 16.20.
508
Чость II. Роботов сетях
Таблица 16.20- Фойлы покета BIND во FreeBSD
Фойл Каталог Описание resolv.conf
/ « с Файл конфигурации распознавателя named
/usr/sbin Демон сервера имен named-xfer
/usr/libexec Код модуля зонных пересылок named.conf
/etc/namedb Конфигурационный файл сервера имен named.pid
/var/run Идентификатор промесса дечона named nnmed.mn
катаюг
1
Выходная отладочная информация namcd.stats
каталог*
Выходная статистическая информация named, mems tats
катазог
1
Статистика использования памяти named duinp.db
ката-юг
1
Образ всей базы данных Зонные файлы /etc/namedb Стандартное местоположение зонных файлов Этот каталог >казан в файле /etc/namcdb/named.conf как начальный для файпов
BIND. Каталог /etc/namedb содержит ряд файлов-примеров: файл корневого кэша (named.root), прототип файла зоны обратного преобразования для узла localhost (PROTO.localhost.rev) и сценарий make-localhost. который запрашивает у пользователя имя домена, после чего создает файл зоны обратного преобразования для узла localhost на основании имеющегося прототипа.
Рег1-сценарий named-hootconf. находящийся в каталоге /usr/sbin, преобразует стартовый сценарий named.boot пакета BIND 4 в файт named.conf формата BIND 8. По нашему мнению, перемещение файла named.conf из каталога /etc следует рассматривать как уголовное преступление- Мы рекомендуем создать на прежнем месте ссылку на новое местоположение файла, чтобы оба имени — новое и старое — работали. Просматривая комментарии в конце файла named.conf. мы догадались, что первоначально разработчики FreeBSD планировали запускать демон named в среде с измененным корневым каталогом. Нов стандартной конфигурации этого на самом деле не происходит. Дополнительную информацию можно получить из переменных ла!пеа_^ в файле /etc/defaults/rc.conf. На шап-страннце. посвященной демону named, неправильно указаны некоторые пути, в частности к файлу статистики и файлу образа баш данных. Очевидно, ошибка имеется в самом дистрибутиве на узле isc.org, поскольку в Solaris и FreeBSD одинаковые ошибки.
16.17- Рекомендуемая литература Система D N S и пакет B I N D описаны во многих источниках, включая документацию, входящую в состав дистрибутива, отдельные главы в некоторых книгах об Internet, целую книгу серии " In a Nutshell" издательства
O'Reilly, а также многочисленные ресурсы в Internet. Списки рассылки и группы новостей Ниже перечислены списки рассылки, посвященные пакету BIND:
• bind-usens — чтобы присоединиться, пошлите сообщение по адресу b i nd - use r^-request@ i sc. org;
Глово 16. Системо доменных имен
. 509

• bind-announce — чтобы присоединиться, пошлите сообщение по адресу bind-announce-requesi@isc.org:
• namedroppers — чтобы присоединиться, пошлите сообщение по адресу namedroppers-request@internic.net:
• bmd-workers — чтобы присоединиться, пошлите сообщение по адресу bind-workers-request@isc-org. Сообщать о найденных ошибках можно по адресу bind-bugs@isc.org или bind9 -bugs@isc.org. Книги и другая документация
• The Nominum BIND Development Team.
BINDv9 Administrator Reference
Manual.
Этот документ доступен из дистрибутива BIND (doc/arm) на узле www.isc.org. Здесь в общих чертах описаны принципы администрирования пакета BIND 9. Более ранний документ,
RIND Operations Guide,
или BOG. как его называют, содержит подробное описание функционирования и конфигурирования пакета BIND 4. Документ BOG входнт в дистрибутивы
BIND вплоть до версии 8.
• Albitz, Paul, and Cricket Liu.
DNS and BIND, Fourth Edition.
Sebastopol. CA
O'Reilly, 2001. Это новое издание популярной и очень уважаемой книги о пакете BIND, содержащее описание всех основных версии пакета (8.2.3. 9.1.0. а также 4.9). Ресурсы в Internet В списке часто задаваемых вопросов телеконференции со- mains имеется множество информации о пакете BIND, в основном версии 4. Список ведется Крисом Пекемом (Chris Peckham) и доступен по адресу lit t p://www. i ntac.com/
cdp с ptd -faq Каталог ресурсов DNS (www.dns.net/dnsrd) — это полезная коллекция ресурсов и ссылок на них. сопровождаемая Андрасом Саламоном (Andras
Salamon). Документы RFC документы, в которых описывается система DNS, можно получить на Web-узлс www.rfc-ediior.oig. Ниже перечислены избранные подмножества этих документов
Исходные стандарты
• 1034 — Domain Names: Concepts and Facilities (Доменные имена понятно и базовые возможности
• 1035 — Domain Names: Implementation and Specification (Доменные имена реализация и спецификация.
Предложена ые стандарты (Инкремеитные зонные пересылки в DNS);
• 1996 — A Mechanism for Prompt Notification of Zone Changes (Механизм уведомления об изменениях зон
• 2136 — Dynamic Updates in DNS (Динамические обновления в DNS),
510
Чость II. Роботов сетях

• 2181 — Clarifications to the DNS Specification (Пояснения к спецификации
DNS);
• 2308 — Negative Caching of DNS Queries (Кэширование отрицательных ответов на запросы.
Наборы новых стандартов
• 2535 — Domain Name System Security Extensions (Расширения DNS. связанные с безопасностью
• 2671 — Extension Mechanisms for DNS: EDNSO (Механизмы расширения
DNS: EDNSO);
• 2672 — Non-Terminal DNS Name Redirection: DNAME (Передача управления именами в DNS: запись DNAME);
• 2673 — Binary Labels in DNS (Двоичные метки в DNS).
Различные документы
• 1535 — A Security Problem and Proposed Correction With Widely Deployed
DNS Software (Проблема безопасности широко распространенного программного обеспечения DNS и предложенное решение
• 1536 — Common DNS Implementation Errors and Suggested Fixes (Распространенные ошибки в реализации DNS и предлагаемые исправления
• 1982 — Serial Number Arithmetic (Вычисление порядковых номеров
• 2536—2541 — документы, связанные со спецификацией DNSSEC.
Типы записей о ресурсах
• 1183 - New DNS RR Definitions: AFSDB, RP, X25, ISDN. RT (Определения новых записей о ресурсах в DNS: AFSDB, RP, Х. ISDN, RT);
• 1706 — DNS NSAP Resource Records (Записи о ресурсах NSAP в DNS);
• 1876 — A Means for Expressing Location Information in DNS (Средства представления информации о местоположении в DNS);
• 2052 — A DNS RR for Specifying the Location of Services: SRV (Запись
DNS, задающая расположение сервисов SRV);
• 2168 — Resolution of Uniform Resource Identifiers using DNS (Преобразование универсальных идентификаторов ресурсов средствами DNS);
• 2230 — Key Exchange Delegation Record for the DNS (Запись о ресурсах
DNS. позволяющая передавать право на осуществление обмена ключами.
DNS и Internet
• 1101 — DNS Encoding of Network Names and Other Types (Кодирование сетевых имени других типов ресурсов в DNS);
• 1123 — Requirements for Internet Hosts: Application and Suppon (Требования к узлам прикладные и служебные протоколы
• 1591 — Domain Name System Structure and Delegation (Структура DNS и делегирование полномочий
• 2317 — Classless in-addr.arpa Delegation (Бесклассовое делегирование н домене in-addr.arpa).
Функционирование DNS
• 1537 — Common DNS Data File Configuration Errors (Распространенные ошибки конфигурирования базы данных DNS);
• 1912 — Common DNS Operational and Configuration Errors (Распространенные ошибки функционирования и настройки DNS);
Глово 16. Системо доменных имен
5 П

• 2182 — Selection and Operation of Secondary DNS Servers (Выбор и функционирование вторичных серверов DNS);
• 2219 — Use of DNS Aliases for Network Services (Использование псевдонимов для сетевых сервисов).
Другие документы, связанные с DNS
• 1464 — Using DNS to Store Arbitrary String Attributes (Использование DNS для хранения произвольных строковых атрибутов
• 1713 — Tools for DNS debugging (Средства отладки DNS);
• 1794 — DNS Support for Load Balancing (Средства распределения нагрузки в DNS);
• 2240 — A Legal Basis for Domain Name Allocation (Правовые основы выделе mi я доменных имен
• 2345 — Domain Names and Company Name Retrieval (Поиск доменных имени имен компаний,
• 2352 — A Convention For Using Legal Names as Domain Names (Соглашение об использовании зарегистрированных имен в качестве доменных.

Сетевая файловая система
Сетевая файловая система, или NFS (Network File System), позволяет компьютерам совместно использовать их локальные файловые системы. NFS почти прозрачна для пользователей и не поддерживает понятие сеанса, те. при крахе сервера данные в удаленных файловых системах не пропадают. Клиенты просто ждут, когда сервер вновь начнет функционировать, а затем продолжают работать так, будто ничего не произошло. Сетевую файловую систему внедрила компания Sun Microsystems в
1985 году. Первоначально NFS была реализована как суррогат файловой системы для бездисковых клиентов, но предложенный протокол оказался столь удачным, что со временем стал универсальным решением проблемы совместного использования файлов Сейчас уже трудно припомнить, какой была жизнь до появления NFS. Большинство поставщиков систем предлагают ту или иную версию NFS, причем многие используют код, полученный по лицензии от Sun. Сетевая файловая система состоит из ряда компонентов, включая протокол и сервер монтирования, демоны, координирующие работу базового файлового сервиса, а также несколько диагностических утилит. Части клиентского и серверного программного обеспечения NFS находятся непосредственно в ядре. К счастью, они не требуют конфигурирования и преимущественно "прозрачны" сточки зрения администрирования. Версии протокола N F S Протокол NFS отличается удивительной стабильностью. Первый открытый выпуск NFS имел версию 2, Вначале х тт. в протокол были внесены изменения, которые привели к появлению версии 3. Ее характеризовали повышенная производительность и улучшенная поддержка больших файлов.
17.1. Общая информация об NFS
Глово
1 7. Сетевоя фойповоя системо
513
Пока существовала версия 2, клиент не мог считать операцию записи завершенной, ие получив подтверждения от сервера. Сервер должен был записать на диск каждый модифицированный блок, прежде чем отвечать. Это позволяло избежать проблем в случае краха сервера. Подобное ограничение являлось причиной существенного замедления работы системы, поскольку во многих случаях модифицированные блоки вполне можно было хранить лишь в резидентном буфере. В версии 3 данное узкое место было устранено за счет схемы согласования, которая позволяет выполнять операции записи асинхронно. Был улучшен также ряд других параметров протокола, связанных с производительностью. вследствие чего NFS 3 стала работать гораздо быстрее, чем
NFS 2. Сервер версии 3 всегда может взаимодействовать с сервером версии 2. Просто он при этом переключается на использование более старого протокола. Выбор транспортного протокола В основе NFS лежит протокол RFC (Remote Procedure Call — удаленный вызов процедур) компании Sun. который определяет системно-независимы и способ взаимодействия процессов посети. Положительным побочным эффектом этой архитектуры является возможность выбора транспортного протокола — TCP или UDP. Изначально в NFS применялся протокол UDP. поскольку он обеспечивал наилучшую производительность в локальных сетях х гг. И хотя программное обеспечение NFS само выполняет сборку пакетов и осуществляет контроль ошибок, но нив. нив ие реализованы алгоритмы контроля перегрузки, которые необходимы для достижения нормальном производительности в крупной сети. С целью решения этих проблем в большинстве систем было разрешено использовать в качестве транспортного протокола для NFS не UDP, а ТСР.
Первонячально данная возможность предназначалась для обеспечения работы
NFS через маршрутизаторы ив сети Iniernei. Нов настоящее время большинство специалистов рассматривает TCP и как оптимальное средство для управления вокальным трафнком. В коние концов, по мере удешевления памяти и роста производительности центральных процессоров первоначальные доводы в пользу UDP становятся все менее актуальными. Серверы, поддерживающие протокол TCP. как правило, принимают запросы на установление соединений от обоих транспортных протоколов.
ПОЭТОМУ выбор между TCP и UDP делает клиент. Большинство клиентов по умолчанию работают с UDP. Solaris к их числу не относится. Поддержка TCP официачьно появилась в спецификации протокола NFS версии но существуют реализации версии 2, где такая поддержка тоже имеется (например, в Red Hal) В ю же время есть и реализации версии 3. где поддержка ГСР отсутствует (в частности, в HP-UX). Все данные о поддержке протокола I CP н NFS версии 3 в наших тестовых системах сведены в табл 17.1. В колонке "По умолчанию" указано, какому протоколу оглаег предпочтение клиентская часть системы.
5 1 4
Чосгь II. Роботов сетях

Тоблица 17 1. Поддержка расширенных возможностей NFS в операционных системах Система
N K v 3 ?
TCP? По умолчании
Solaris Да Да
ТСТ
HP-UX Да Нет
UDP
Red Hat
НЕТ
Да'
UDP
FreeBSD Да Да
U DP Протокол TCP поддерживается только на стороне клиента.
W e b N F S В 1996 г. компания Sun предприняла попытку' внедрить N F S в глобальную сеть, предложив собственную оригинальную систему WcbNFS. Будучи надмножеством стандартного протокола N F S версии 3, WebNFS устраняет точнее, делает необязательными) некоторые вступительные транзакции, через которые должен пройти традиционный клиент NFS. прежде чем он получит доступ к файловой системе. Этот механизм предназначен не для замены NFS. а для поддержки апплетов. выполняющихся в среде Web-броузеров. Следовательно, для организаций, не занимающихся написанием таких апплетов. система WebNFS не представляет особого интереса Все наши тестовые операционные системы (кроме HP-UX) обеспечивают серверную поддержку протокола WebNFS. Дополнительную информацию можно получить по адресу wuTv.sun.com/webnfs. Блокировка файлов Блокировка файлов (реализуемая системными вызовами Поск и/или lock Г в течение долгого времени являлась "больным" вопросом для UNIX-CIICICM
В локальных файловых системах этот механизм был реализован далеко неидеально. Что касается NFS. то положение все еше неустойчиво. Серверы
N F S не поддерживают понятие сеанса они не знают о том. какие компьютеры работают с конкретным файлом Но эта информация необходима для использования блокировок Как быть Традиционное решение *аключается в реализации механизма блокировок отдельно от NFS. В большинстве систем этой цели служат два демона, lockd и staid. К сожалению, реализация такого подхода затруднена по ряду причин, поэтому блокировка файлов в N F S часто организована неоптимальным образом. Дисковые квоты Доступ к информации о дисковых квотах на удаленном компьютере осуществляет серверный демон rquolad. работающий во внсполосном режиме Сервер N F S будет поддерживать дисковые квоты, но клиенты ие СМОГУТ
ничего о них узнать, если на удаленном компьютере не работает демон rquolad. Мы считаем механизм дисковых квот большей частью устаревшим, поэтому не будем рассказывать об этом демоне.
Глово 1 7. Сетевоя фойповоя системо
510
Глобальные идентификаторы пользователей и групп В UNIX пользователи и группы пользователей идентифицируются по номерам. Если пользователь компьютера X имеет файлы на компьютере N. то желательно, чтобы его идентификатор был одинаковым в обеих системах, иначе могут возникнуть серьезные проблемы с безопасностью или конфиденциальностью.
Более подробные сведения об идентификаторах пользователей и групп содержат-
ся в главе 6.
В некоторые серверы NFS были внедрены средства преобразования удаленных идентификаторов в локальные, но эта возможность не является частью официального протокола NFS и не может считаться надежной при работе с несколькими операционными системами. Мы рекомендуем обращаться с идентификаторами старым, но надежным способом следует сделать так, чтобы на всех компьютерах, где происходит совместная работа с файлами, за пользователями и группами были закреплены одни и те же номера. Чтобы избавить администратора от головной боли, добейтесь уникальности идентификаторов в пределах всей организации. Серверы NFS не требуют регистрации удаленных пользователей в системе. Пользователь может даже не иметь записи в файле /etc/passwd, если только на сервере не установлена какая-нибудь необычная опция, например map_ms в Red Hal. Учетные записи raat и nabody В общем случае пользователи должны иметь одинаковые привилегии в любой системе, к которой они получают доступ. Однако традиционно ограничиваются возможности неконтролируемого пр!гменения прав суперпользователя в файловых системах, смонтированных посредством NFS. По умолчанию сервер NFS перехватывает входящие запросы, посылаемые от имени пользователя с идентификатором 0, и "делает вид, будто они поступают от другого пользователя. Таким образом, учетная запись root не отменяется, но уравнивается в правах с обычными учетными записями В большинстве систем специально определена фиктивная учетная запись nobody, чтобы под нее "маскировался" пользователь root, работающий на сервере NFS. Ее идентификатор может быть разным в зависимости от системы ив принципе не играет особой роли чаше всего это -2 или 65534. Важно то, что этот идентификатор не пересекается ни с одним из идентификаторов реальных пользователей. В Solaris и HP-UX доступ в систему будет вообше запрещен, если назначить учетной записи root идентификатор -1. Все эти предосторожности преследуют благородную цель, однако конечный результат далек от идеала. Будучи клиентом NFS, пользователь root может с помощью команды su "принять облик любого пользователя, так что иаши файлы никогда не бывают полностью защищены. Системные учетные записи, такие как bin и sys, не подвергаются смене идентификатора, поэтому принадлежащие им файлы (а это большой процент системных' файлов) открыты для нападений. Единственный действенный эффект от смены идентификаторов заключается в том, что предотвращается доступ кВ действительности в Red Hat можно менять идентификаторы других учетных записей помимо root. Подробнее об этом рассказывается в параграфе 17.2. Будьте осторожны, чтобы подобными изменениями не нарушить работу стандартных программ, в частности sendmail.
516
Чость К. Роботов сетях
файлам, которые принадлежат пользователю root и недоступны для чтения или записи остальным пользователям. Секретные ключи и монтирование без учета состояния Прежде чем начинать работу с файловой системой NFS, клиент должен ее смонтировать, как если бы это была файловая система, хранящаяся на локальном диске. Ноне сохраняет информацию о сеансах, поэтому сервер не знает, какие клиенты смонтировали каждую файловую систему. Вместо этого сервер выдает клиенту секретный ключ по факту успешного завершения операции монтирования. Этот ключ идентифицирует каталог монтирования на сервере NFS и позволяет клиенту получить доступ к содержимому данного каталога. Как правило, при демонтировании и повторном монтировании файловой системы на сервере ее секретный ключ меняется. Но есть особый случай ключ сохраняется при перезагрузке, чтобы сервер после краха смог вернуться в свое нормальное состояние. Не стоит, однако, пробовать загружаться в однопользовательском режиме, работать с файловой системой, а затем загружаться вновь это приведет к аннулированию ключей и лишит клиентов возможности доступа к файловым системам, которые они смонтировали, до тех пор, пока они либо не перезагрузятся, либо не осуществят повторное монтирование этих файловых систем. Если у клиента есть секретный ключ, он может с помошью протокола
RPC посылать файловой системе запросы, например на создание файла или чтение блока данных. Поскольку в NFS нет понятия сеанса, то серверу все равно, какие запросы клиент делал (или не делал) ранее. В частности, прежде чем удалять собственную копию данных, подлежащих записи, клиент сам должен убедиться, что сервер подтвердил запрос на запись. Соглашения об именах совместна используемых файловых систем Управлять сетевой файловой системой становится проще, если придерживаться стандартной схемы именования. Полезны такие имена, которые содержат имя сервера (например, /anchor/tools — файловая система, расположенная на машине anchor), потому что они позволяют переводить объявления вида машина anchor будет всю субботу отключена в связи с модификацией" в "я не смогу поработать над файлом 'anchor/tools Те в субботу, чтобы закончить диссертацию, поэтому лучше отправлюсь на лыжную прогулку" К сожалению, та схема требует, чтобы каталог /anchor существовал в корневых каталогах всех клиентских компьютеров. Если клиент получает доступ к файловым системам, расположенным на нескольких машинах, его корневой каталог может оказаться захламленным. Рассмотрите возможность углубления иерархии, например, используйте катают Доте. Тю- me/rastadon и т.д. Мы советуем прибе1нуть к помоши демонов автоматического монтирования, описание которых начинается в параграфе 17 6. Безопасность и N F S Сетевая файловая система предоставляет удобный способ доступа к файлам посети и потому является серьезным источником угроз для
Глово 17 Сетевой сЬоиловая система



Поделитесь с Вашими друзьями:
1   ...   41   42   43   44   45   46   47   48   ...   82


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал