Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

272 Глава 8. Настройка DNS

• Записывать полное содержимое домена в файл для последующего про-

смотра

Чтобы узнать о других возможностях nslookup, воспользуйтесь командой

help. Включите отладку (команда set debug) и изучите дополнительную ин-

формацию. По мере изучения инструмента nslookup вы обнаружите много

полезных возможностей.

Резюме

Система доменных имен (Domain Name System, DNS) является важной поль-

зовательской службой, необходимой каждой системе, подключенной к Ин-

тернету. Подавляющее большинство реализаций DNS для Unix основано на

пакете BIND (Berkeley Internet Name Domain). BIND содержит приложения

клиента и сервера DNS.

Клиент BIND, или DNS-клиент (resolver), генерирует запросы и реализован

в виде набора библиотечных подпрограмм. Его настройка выполняется по-

средством файла resolv.conf. Клиент DNS существует на всех системах.

Сервер BIND отвечает на запросы и существует в качестве демона. Демон на-

зывается named. Настройка named выполняется посредством файла na-

med.conf, определяющего источники доменной информации для сервера и

тип сервера. Серверы бывают трех типов: основные, подчиненные и специ-

альные кэширующие. Поскольку кэширование выполняют серверы всех ти-

пов, один и тот же вариант настройки может подходить для серверов различ-

ных типов.

Исходные записи базы данных DNS хранятся в файлах на основном сервере.

Файл базы данных DNS называется файлом зоны. Файл зоны состоит из

стандартных записей ресурсов (RR-записей), формат которых определен до-

кументами RFC. RR-записи имеют общую структуру и являются средством

определения любой информации базы данных DNS.

Тестирование сервера DNS может выполняться при помощи nslookup. Дан-

ный инструмент входит в комплект поставки BIND.

В данной главе мы научились настраивать и тестировать службу DNS. В сле-

дующей главе мы займемся другими службами.

• Сетевая файловая

система (NFS)

• Совместный доступ

к принтерам Unix

• Samba и Windows:

совместный доступ к ресурсам

• Сетевая информационная

служба (NIS)

• DHCP -

• Управление распределенными

серверами СЛужбЫ СвТИ

• Серверы почтовой службы

Переходим к настройке локальных серверов сети. Подобно службе имен, эти

серверы не являются строго необходимыми для функционирования сети, но

предоставляют службы, позволяющие использовать сеть по назначению.

Сетевых служб существует великое множество - больше, чем мы сможем

рассмотреть в этой главе. Поэтому наше внимание будет сосредоточено на

службах, наиболее востребованных локальными клиентами:

• Сетевая файловая система NFS (Network File System)

• Демон печати LPD (Line Printer Daemon) и служба печати LP (Line Printer)

• Службы печати и файлов Windows (Samba)

• Сетевая информационная служба NIS (Network Information Service)

• Протокол динамической настройки узлов DHCP (Dynamic Host Configu-

ration Protocol)

• Протокол почтовой службы POP (Post Office Protocol)

• Интернет-протокол доступа к сообщениям IMAP (Internet Message Access

Protocol)

Нее перечисленные программные пакеты проектировались с прицелом на

обслуживание пользователей в пределах организации, но не на внешних

пользователей. Основные службы, востребованные как внешними пользова-

телями, так и пользователями локальной сети, - это электронная почта, веб-

служба (сервер Apache) и служба имен. Их описанию посвящены отдельные

главы.

Разговор о локальных сетевых службах мы начнем с NFS - сервера, обеспе-

чивающего совместный доступ к файлам в сетях Unix.

274 Глава 9. Локальные службы'сети

Сетевая файловая система (NFS)

Сетевая файловая система NFS (Network File System) позволяет организо-

вать совместный доступ пользователей к каталогам и файлам по сети. Ав-

торство системы принадлежит компании Sun Microsystems, но сегодня она

поддерживается практически всеми операционными системами Unix, а так-

же многими другими ОС. Посредством NFS пользователи и программы мо-

гут обращаться к файлам, хранящимся на удаленных системах, так, как

будто это локальные файлы. В идеальном случае пользователь NFS не знает

и не испытывает необходимости знать, где на самом деле хранятся файлы.

NFS имеет ряд преимуществ:

• Сокращает потребность в локальном дисковом пространстве - единствен-

ная копия каталога, доступного всем пользователям сети, может хра-

ниться на сервере.

• Упрощает реализацию централизованной поддержки - обновленные фай-

лы немедленно становятся доступны всей сети.

• Позволяет пользователям использовать для работы с удаленными файла-

ми знакомые команды Unix и не требует изучения новых команд. NFS не

принуждает пользователя обращаться к ftp или гср, если требуется ско-

пировать файл; ср оказывается более чем достаточно.

Существует две стороны NFS: клиент и сервер. Клиент - это система, исполь-

зующая удаленные каталоги в качестве каталогов локальной файловой сис-

темы. Сервер - это система, которая делает такие каталоги доступными для

клиентов. Включение удаленного каталога в локальную файловую систему

(функция клиента) называется монтированием каталога. Предоставление

удаленного доступа к каталогам (функция сервера) называется организа-

цией совместного доступа (sharing) или экспортированием (exporting) ка-

талога.

Достаточно часто система выступает в качестве сервера и клиента

одновременно. В этом разделе мы изучим настройку системы на экспортиро-

вание и монтирование каталогов посредством NFS.

Если в вашем ведении находится сервер NFS крупной сетевой площадки,

следует тщательно планировать создание среды NFS. В этой главе описана

настройка NFS для клиента и сервера, но могут потребоваться и дополни-

тельные сведения о проектировании оптимальной среды NFS. Подробная

информация по теме приводится в книге Хэла Стерна (Hal Stern) «Managing

NFS and NIS» (O'Reilly & Associates).

Демоны NFS

Работа сетевой файловой системы (Network File System) основана на ряде де-

монов, выполняющих функции клиента или сервера. Прежде чем перейти к

Термин «организация совместного доступа» (sharing) используется в Solaris, в

большинстве других систем - «экспортирование» (exporting).

Сетевая файловая система (NFS)

275

настройке NFS, рассмотрим функциональность и назначение демонов NFS в

системе Solaris 8:

nfsd [nservers]

Демон NFS nfsd работает на серверах NFS. Этот демон обслуживает запро-

сы клиентов NFS. Параметр nservers определяет число запускаемых де-

монов.

mountd

Демон монтирования NFS mountd обрабатывает запросы клиентов на мон-

тирование каталогов. Демон mountd работает на серверах NFS.

nfslogd

Демон журналов NFS nfslogd фиксирует активность для экспортирован-

ных файловых систем. Демон журналов работает на серверах NFS.

rquotad

Сервер удаленных квот rquotad предоставляет информацию о квотах

пользователей в удаленных файловых системах. Информация отобража-

ется по команде

quota.

Демон квот может работать как на серверах, так и

на клиентах.

lockd

Демон блокировки lockd обрабатывает запросы на блокировку файлов.

Демон блокировки работает как на серверах, так и на клиентах. Клиенты

запрашивают блокировку файлов, а серверы ее разрешают.

statd

Демон наблюдения за сетевым состоянием statd необходим для работы

lockd. В частности, он позволяет корректно отменять блокировку после

сбоя. Демон statd работает как на серверах, так и на клиентах.

В системе Solaris 8 демоны, необходимые для работы NFS, располагаются в

каталоге /usr/lib/nfs. Большая часть этих демонов запускается при загрузке

системы из двух сценариев, nfs.client и nfs.server, расположенных в катало-

ге /etc/init.d. Сценарий nfs.client запускает программы statd и lockd.

На

серверах NFS работают эти два демона плюс демон сервера NFS

(nfsd),

демон

журналов NFS (nfslogd) и демон монтирования (mountd). В системе Solaris

сценарий nfs.server запускает mountd, nfslogd, а также 16 экземпляров nfsd.

Системы Solaris обычно не запускают демон rquotad в процессе загрузки.

Вместо этого rquotad запускается демоном

inetd,

как можно видеть из следу-

ющей команды grep:

Как вариант имена демонов может предварять префикс грс. Например, в системе

Slackware Linux демон NFS называется грс.nfsd. Сверьтесь с документацией по

своей системе.

276

Глава 9. Локальные службы сети

В каждой системе существуют свои способы запуска этих демонов. Если от-

дельные демоны не запускаются, проверьте правильность загрузочных сце-

нариев и файла inetd.conf.

Совместный доступ к файловым системам Unix

При настройке сервера необходимо, прежде всего, определить, для каких

файловых систем будет организован совместный доступ и какие ограниче-

ния будут действовать для этих файловых систем. Клиентам следует предо-

ставлять только те файловые системы, которые могут быть полезны. Преж-

де чем открывать доступ к файловой системе, подумайте о том, каким целям

это послужит. Вот некоторые из распространенных причин организации со-

вместного доступа к файловым системам:

• Предоставить дисковое пространство бездисковым клиентам

• Избежать ненужного дублирования данных на многих системах

• Обеспечить централизованную поддержку программ и данных

• Организовать совместный доступ к данным для группы пользователей

Для всех выбранных файловых систем необходимо провести настройку при

помощи соответствующих команд. В следующем разделе данный процесс

описан для системы Solaris. Для Linux процесс значительно отличается и бу-

дет описан позже. Обращайтесь к документации по своей системе за точны-

ми сведениями о том, как организован совместный доступ к файлам по NFS.

Команда share

В системах Solaris каталоги экспортируются при помощи команды share.

Упрощенный синтаксис этой команды выглядит следующим образом:

share -F nfs [-о параметры] путь

где путь - путь к каталогу на сервере, экспортируемому в пользу клиентов,

а параметры управляют доступом клиентов к данному каталогу. Доступные

параметры:

Параметр rw разрешает чтение и запись для файловой системы. Может

иметь вид гм=список_доступа, что позволяет указывать системы, которым

разрешен такой доступ. В последнем случае доступ к файловой системе

предоставляется только системам из списка доступа. Если список досту-

па отсутствует, все узлы получают полномочия чтения/записи в данной

файловой системе.

го

Данный параметр ограничивает доступ только чтением. Он также позво-

ляет указать список доступа - в формате го=список_доступа. В последнем

случае доступ предоставляется только системам из списка, и этот доступ

разрешает только чтение данных. В отсутствие списка доступа все узлы

Сетевая файловая система (NFS)

277

получают в искомой файловой системе полномочия только чтения - что

является умолчанием для команды share.

aclok

Предоставляет полный доступ всем клиентам. Может стать причиной не-

санкционированного проникновения в систему. Этот параметр описан в

документации системы Solaris, но его не следует использовать ни при ка-

ких обстоятельствах. Он нужен только для обратной совместимости с бо-

лее не существующей версией NFS.

anon=uid

Указывает, какой идентификатор пользователя (UID) следует использо-

вать, если пользователь не представил корректный идентификатор.

index= file

Предписывает NFS использовать файл индекса в стиле индекса веб-серве-

ра - вместо стандартного списка файлов каталога для данной файловой

системы.

log[=tag]

Включает регистрацию событий в журнале. Если присутствует дополни-

тельный тег (tag), он должен совпадать с тегом, определенным в файле

/etc/nfs/nfslog.conf.

nosub

Запрещает клиентам монтирование подкаталогов. По умолчанию монти-

рование подкаталогов разрешено.

nosuid

Запрещает клиентам создавать в этой файловой системе файлы setuid и

setgid. По умолчанию создание таких файлов разрешено.

public

Предписывает использовать открытый файловый дескриптор для этой

файловой системы.

root=список_доступа

Разрешает root-доступ к файловой системе пользователям root с указан-

ных систем.

sec=type

Определяет вид аутентификации, прохождение которой требуется для до-

ступа к данной файловой системе. Вид (type) - это список режимов безопас-

ности NFS, элементы которого разделяются двоеточиями. Чтобы получить

доступ, клиент должен поддерживать по меньшей мере один режим без-

опасности из перечисленных в списке. Существуют следующие режимы:

sys

Управление доступом к файловой системе осуществляется на основе

идентификаторов пользователей и групп, передаваемых открытым

278

Глава 9. Локальные службы сети

текстом. Таким же образом работают традиционные права доступа в

Unix-системах - на основе идентификаторов UID и GID. В NFS UID и

GID передаются по сети, и сервер вынужден доверять удаленному ис-

точнику, от которого поступили данные.

Для аутентификации используется криптографический метод с от-

крытым ключом Диффи-Хеллмана.

krb4

Проверка подлинности по протоколу Kerberos версии 4.

попе

Не использовать аутентификацию. В этом случае все пользователи по-

лучают доступ к файловой системе в качестве пользователя nobody.

window=seconds

Указывает максимальное время действия данных идентификации для

методов dh и krb4. Сервер NFS отказывает в доступе клиентам, предостав-

ляющим данные идентификации с большим временем действия. Число

секунд (seconds) по умолчанию равно 30000.

Некоторые из параметров принимают в качестве аргумента список доступа,

элементы которого разделяются двоеточиями. Каждый элемент обозначает

либо конкретный компьютер посредством имени узла или IP-адреса, либо

домен, сеть или сетевую группу NIS, к которым принадлежат узлы. Синтак-

сис элементов списка доступа следующий:

имя узла

Произвольное имя узла, которое преобразуется в IP-адрес. Допустимы аб-

солютные имена, равно как и локальные имена узлов, но в любом случае

должна существовать возможность превратить имя в адрес. Если имя

упоминается в локальной таблице узлов, можно использовать краткую

форму. Если разрешение имен выполняется при помощи DNS, следует

указывать абсолютное доменное имя. Однако не следует использовать аб-

солютные имена, если ваша система не использует DNS, а полагается в

работе исключительно на NIS.

адрес

IP-адрес в десятичной записи через точку.

сетевая группа (netgroup)

Если указано имя сетевой группы NIS, параметр действует для всех сис-

тем этой сетевой группы. Имена сетевых групп похожи на локальные

имена узлов, что вносит некоторую путаницу. Имена сетевых групп сле-

дует использовать, только если применяется NIS.

.домен

Доменное имя позволяет применить параметр ко всем системам домена.

Имена доменов предваряются точкой (.). Таким образом, указание имени

.wrotethebooh.com распространяет действие параметра на все системы до-

Сетевая файловая система (NFS) 279

Первая команда share разрешает чтение и запись узлам crab и rodent и предо-

ставляет доступ только для чтения всем прочим. С другой стороны, вторая ко-

манда share разрешает чтение/запись узлам rodent, crab, horseshoe и jerboas,

но запрещает доступ любого рода всем остальным клиентам.

Команда share утрачивает силу при перезагрузке системы. Поместите ко-

манды share в сценарий /etc/dfs/dfstab - это позволит клиентам получать

доступ к соответствующим файловым системам и после перезагрузки. Вот

пример файла dfstab, содержащего две приведенные выше команды:

Команда

share,

файл dfstab и даже собственно термин «share» присущи толь-

ко системе Solaris. В большинстве систем Unix, если речь заходит о предо-

ставлении клиентам доступа к файлам по NFS, то для файлов выполняется

экспортирование, а не организация совместного доступа. Более того, в

этих системах не используется команда share и файл dfstab - режимы досту-

па к файловым системам устанавливаются в файле /etc/exports. Примером

такой системы является Linux.

Файл /etc/exports

Файл /etc/exports содержит настройки сервера NFS для систем Linux. Он

определяет, какие файлы и каталоги экспортируются и в каких режимах до-

ступа. Например, файл /etc/exports может содержать следующие записи:

Адрес сети позволяет распространить действие параметра на все системы

определенной сети. Адреса сетей предваряются символом Необязатель-

ный префикс сети (prefix) позволяет четко указать маску для сети.

Сочетание параметров rw и го может использоваться для предоставления

различного уровня доступа различным клиентам. Например:

мена wrotethebook.com. Доменные имена следует использовать, только ес-

ли сервер взаимодействует с системой DNS.

280

Глава 9. Локальные службы сети

Здесь сказано, что:

• /usr/тап доступен для монтирования любому клиенту, но запись в ката-

лог разрешена только узлам crab и horseshoe. Прочим клиентам разреше-

но только чтение файлов.

• /usr/local может монтироваться любым клиентом, разрешено только чте-

ние файлов.

• /home/research может монтироваться только узлами rodent, crab, horses-

hoe и jerboas. Этим узлам разрешены чтение и запись.

Параметры каждой из записей файла /etc/exports определяют режимы до-

ступа. Записи подчиняются следующему формату:

каталог [узел (.параметр)].,.

каталог указывает экспортируемый каталог или файл, узел - имя узла или

клиента, которому разрешен доступ к экспортированному каталогу, параметр

определяет режим доступа для клиента.

В приведенном файле /etc/exports в качестве узла фигурирует имя отдельно-

го клиента. В одном случае имя узла не указано. Если указано имя одного

узла, доступ получает отдельный клиент. Если узел не указан, каталог экс-

портируется для всех клиентов. Подобно Solaris, Linux позволяет использо-

вать домены, сети и сетевые группы, хотя синтаксис немного отличается.

Допустимые значения для поля узел:

• Имена отдельных узлов, такие как crab или crab.wrotethebooh.com.

• Маски доменов. Например, маска *wrotethebook.com включает все узлы

домена wrotethebook.com.

• Пары вида адрес IP/маска. К примеру, 172.16.12.0/255.255.255.0 вклю-

чает все узлы, адреса которых начинаются с 172.16.12.

• Сетевые группы, такие как @groupl.

Обратите внимание, что в Linux имена доменов начинаются с символа звез-

дочки (*), а не с точки (.), как в Solaris. Кроме того, символ @ предваряет

имя сетевой группы, а не адрес сети, как в Solaris.

Параметры, использованные в примере файла /etc/exports:

го

Режим только для чтения запрещает клиентам NFS запись в каталог. По-

пытки записи в такой каталог завершаются неудачно сообщением «Read-

only filesystem» (Файловая система доступна только для чтения) или

«Permission denied» (Недостаточно полномочий). Если указан параметр

го, но отсутствует имя узла клиента, все клиенты получают доступ толь-

ко для чтения.

Режим чтения/записи разрешает клиентам чтение и запись в данный ка-

талог. Если не указано имя узла, всем клиентам разрешается доступ в ре-

жиме чтение/запись. Если указано имя узла, только этот узел получает

полномочия чтения/записи.

Сетевая файловая система (NFS) 281

Итак, отдельные узлы получают доступ в режиме чтения/записи к некото-

рым из каталогов, однако доступ конкретных пользователей этих узлов рег-

ламентируется стандартными для Unix правами уровня пользователя, груп-

пы и глобального доступа, вычисляемыми на основе идентификатора поль-

зователя (UID) и группы (GID). NFS считает, что удаленный узел выполнил

проверку подлинности пользователей и назначил им корректные идентифи-

каторы UID и GID. Экспортирование файлов дает пользователям системы-

клиента такой же доступ к этим файлам, как если бы они регистрировались

напрямую на сервере. Разумеется, предполагается, что клиент и сервер на-

значили одинаковые идентификаторы UID и GID каждому из пользовате-

лей. Но это далеко не всегда так. Если клиент и сервер назначили один и тот

же идентификатор UID определенному пользователю, например идентифи-

катор пользователя Craig равен 501 на обеих системах, тогда обе системы

корректно определят пользователя Craig, и он в результате получит доступ к

своим файлам. Если же клиентская система назначила пользователю Craig

идентификатор UID, равный 501, а сервер назначил тот же UID пользовате-

лю Michael, сервер предоставит пользователю Craig доступ к файлам пользо-

вателя Michael - так, словно они принадлежат пользователю Craig. В NFS

существует ряд механизмов, позволяющих справляться с проблемами, воз-

никающими вследствие такого несовпадения идентификаторов UID и GID.

Первая из очевидных проблем - работа с учетной записью администратора.

Маловероятно, что администратор разрешит доступ на сервер пользовате-

лям, обладающим root-полномочиями на клиентских системах. По умолча-

нию NFS блокирует такой доступ параметром

root_squash,

который выполня-

ет отображение UID и GID пользователя root в соответствующие идентифи-

каторы пользователя nobody. Таким образом, пользователь root с системы-

клиента может получить только общие полномочия на сервере. Чтобы изме-

нить это поведение, можно воспользоваться установкой

no_root_squash,

одна-

ко no_root_squash делает сервер потенциально уязвимым.

Отображение прочих идентификаторов UID и GID в идентификаторы поль-

зователя nobody достигается при помощи параметров

squash_uids,

squash_gids

и all_squash. all_squash выполняет такое отображение для всех пользовате-

лей клиентской системы. squash_uids и squash_gids выполняют отображение

конкретных идентификаторов UID и GID. Пример:

Первая запись экспортирует каталог /pub и делает его доступным только

для чтения всем клиентам. Все пользователи клиентских систем получают

общие полномочия, присущие пользователю nobody, то есть могут читать

только те файлы, которые доступны для чтения всем пользователям, а не

только владельцу или группе.

Вторая запись экспортирует каталог /usr/local/pub и делает его доступным

для чтения/записи (режим по умолчанию) всем клиентам. Параметры squ-

ash_uid и squash_gid в данном примере показывают, что для некоторых пара-