я других задачи, имеется нет такого специализированного обслуживания. Кроме того, если В малой локальной вычислительной сетью с no Internet activity, устанавливая DNS может показаться утояыим затруднение для многих администраторов. Это - то, почему Sun разрабатывало NIS, Сетевую Информационную Систему. NIS обеспечивает обобщенные средства доступа к базе данных, которые могут использоваться для дизинформации данных типа этого, содержали в passwd и группах файлах всех множествах на вашей сети. Это заставит сеть появиться только как единственная система, с теми же самыми account на всех множествах. В подобном режиме, Вы может использовать NIS, чтобы распределить hostname информационную форму /etc/hos сети. NIS основан на RPC, и включает сервер, client-side библиотеку, и несколько административных инструментальных средств. Первоначально, NIS назывался Желтые Страницы, или YP, который все еще широко используется, чтобы неофициально обратиться к этой услуге. С другой стороны, Желтые Страницы - марка изготовителя Британской Телесвязи, которая требует от Sun убрать то название. Поскольку вещи идут, некоторый стержень имен с людьми, и так YP живет на префиксе к именам больш команд типа ypserv, ypbind, и т.д. Сегодня, NIS доступны для виртуально всего Un*ces и там даже свободно реализуется. Каждый - из BSD разъединения Сеть -2 выпуск, и был получен из общей пожертвованной реализации сноски области Sun. Библиотечная клиентская цифра из этого разъединения была в GNU Libc в течение длительного времени, в то время как административные программы только недавно пренесенные к Linux Swen Thmmler. (1) NIS сервер - отсутствуетиз реализации сноски. Tobias Reber написал другой NIS пакет, е средства и сервер; это называется yps. (2) В настоящее время(постоянно), полная перезапись цифры NIS, называемой NYS, сделанная Peter Eriksson, (3), который поддерживает оба, и plain NIS и Sun's much пересмотренным NIS. 1. swen@uni-paderborn.de. NIS клиентура доступнаы как yp- linux.tar.gz из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от этой записи) - yps-0.21 и может быть получена из ftp.lysator.liu.se в - 177 - /pub/NYS каталоге. 3. pen@lysator.liu.se. +. NYS не только обеспечивает множество NIS инструментальных средств и сервера, но и также прибавляет новое множество библиотечных функций, которые будут наиболее возможными для того, чтобы попасть в стандарт libc в конечном счете. Это включает новую конфигурационную схему порции hostname решения, которое заменяет текущую схему использованную host.conf. Особенности этих функций будут обсуждены ниже. Эта глава сосредоточится на NYS скорее чем на двух других пакетах, к которому я буду относить как " традиционную " NIS цифру. Если Вы хотите запустить этих пакетов, то команд, описанных в этой главе может быть не достаточно. Чтобы получать дополнительн ую информацию, пожалуйста найдите стандартную книгу по NIS, типа NFS Hal Stern's и NIS (см. [GETST "строгий - nfs"]). В настоящее время, NYS - все еще развивается, и следовательно стандартные Linux утилиты типа сетевых программ или входа в систему программ, еще не знает NYS схему конфигурации. Пока NYS соединяется в mainstream libc Вы должны перетранслировать все эти binaries, если Вы хотите заставить их использовать NYS. В любом из этих приложений формирования файла, точно определите -lnsl как последнюю опция libc к компоновщику. Это связывается на релевантных функциях из libnsl, NYS стандарной библиотекы для C. 11.1 Знакомство с NIS NIS хранит информацию баз данных, находящихся в так называемых отображениях, содержащих keyvalue pairs. Отображения сохранены на центральном хосте, выполняющем NIS сервер, из которого клиентура может отыскивать информацию через различные RPC вызовы. Совершенно часто, отображения сохранены в файлах DBM. (4) Отпбражения сами по себе обычно генерируются из текстовых файлов типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные - 178 - отображения - созданы, один для каждого типа клавиши. Например, Вы можете искать хост файл для имени хоста также как для адреса IP. Соответственно, два NIS отображения получены из файла, вызываемый hosts.byname и hosts.byaddr, соответственно. Таблица 11.1 списков общих отображений и файлов из кооторых они сгенерированны. 4. DBM - простая библиотека управления базой данных которая использует метод хеширования, чтобы ускорить операцию исследования. Имеется свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который является частью большинства Linux распространен ия. ----------------------------------------------------------- +-----------------+---------------------------------------+ |Master File | Map(s) | +-----------------+---------------------------------------+ +-----------------+---------------------------------------+ |/etc/hosts | hosts.byname hosts.byaddr | |/etc/networks | networks.byname networks.byaddr | |/etc/passwd | passwd.byname passwd.byuid | |/etc/group | group.byname group.bygid | |/etc/services | services.byname services.bynumber | |/etc/rpc | rpc.byname rpc.bynumber | |/etc/protocols | protocols.byname protocols.bynumber | |/usr/lib/aliases | mail.aliases | +-----------------+---------------------------------------+ +-----------------+---------------------------------------+ Таблица 1. Некоторый стандарт NIS отображения и соответствующие чайлы. Имеются другие файлы и отображения, которые Вы можете найти в любом NIS пакете или другом. Они могут содержать информацию для приложений не обсуждаемых в этой книге, типа bootparams отображения, которое может использоваться некоторыми BOOTP серверами, или подобно которому в настоящее время не имеют любую функцию в Linux (Ethers.byname и ethers.byaddr отображения). - 179 - Для некоторых отображений, люди обычно используют прозвища, которые являются короткими следовательно проще. Получать полный список прозвищ понимаемый вашими NIS инструментальными средствами, запустите следующую команду: $ ypcat -x NIS map nickname translation table: "passwd" -> "passwd.byname" "group" -> "group.byname" "networks" -> "networks.byaddr" "hosts" -> "hosts.byname" "protocols" -> "protocols.bynumber" "services" -> "services.byname" "aliases" -> "mail.aliases" "ethers" -> "ethers.byname" "rpc" -> "rpc.bynumber" "netmasks" -> "netmasks.byaddr" "publickey" -> "publickey.byname" "netid" -> "netid.byname" "passwd.adjunct" -> "passwd.adjunct.byname" "group.adjunct" -> "group.adjunct.byname" "timezone" -> "timezone.byname" NIS сервер традиционно называется ypserv. Для средней сети единственного сервера обычно хватает; большие сети могут выбирать несколько серверов на различных машинах и различных сегментах сети, чтобы уменьшить загрузку на машинах сервера и программах маршрутизации. Они синхронизированы, делая один из них главным сервером, к другие подчиненными серверами. Отображения будут созданы только на master server's host. Оттуда, они распределены всем slaves/ Вы отметили, что мы говорили относительно " сети " очень неопределенно все время; конечно имеется отличительное понятие в NIS, которое относится к такой сети, и которая является системой всех хостов та часть их данных конфигурации системы сделанны через NIS: NIS - 180 - область. К сожалению, NIS области не имеют абсолютно ничего общего с областями, с которыми мы столкнулись в DNS. Избегая любой неоднозначности через эту главу, я буду всегда точно определять который тип области NIS области имеют совершенно административную функцию только. Они обычно невидимы для пользователей, кроме разделения паролей между всеми машинами в области. Следовательно, название, данное NIS области релевантно только администраторам. Обычно, любое название будет как длинный поскольку это отлично от любого другого NIS названия области на вашей локальной сети. апример, администратор в Virtual Brewery может создайть две NIS области, одну для Brewery непосредственно, и о которыу она называет brewery и winery, соответственно. Другая совершенно общая схема для того, чтобы просто использовать DNS название области для NIS. Чтобы установить и показать NIS название области вашего множества, domainname. Когда она вызывается без любого аргумента, это печатает текущее NIS название области; к множеству названия области, Вы должны стать супер пользователеми ввести: # domainname brewery NIS области определяют, какой NIS сервер-приложение сделает запрос. Например, программа входа в систему на множестве в Winery должна, сделать запрос NIS сервера Winery (или один из них, если они там были отделены) для информации пароля пользователя; в то время как приложение на Brewery host должно приклеится к серверу Brewery'. Одна тайна, которая пстазтся все еще не решенной, а именно, как клиент узнает с каким сервером он соединен. Самое простое приближение было бы иметь файл конфигурации, который называет хост, чтобы найти сервер. Однако, это приближение было бы довольно негибко, потому что это не позволяет клиентуре использовать различные серверы (из той же самой области, конечно), в зависимости от их доступности. Следовательно, традиционный NIS implementations полагаются на специальный d чтобы обнаружить подходящий NIS сервер в их NIS области. Перед способностью выполнить любой NIS - 181 - Запрос, любое приложение, сначала выясняти от ypbind который сервер используется. Ypbind исследует серверы, передавая к локальной IP сети; сначало первый ответ принят, чтобы быть потенциально самым быстрым и будет использоваться во всех последовательных запросах NIS. После того, как некоторый интервал истек, или если сервер становится недоступным, ypbind, исследует активные серверы снова. Теперь, спорная точка относительно динамического связывания - то, что Вы редко нуждайтесь в этом, и что это вводит задачу защиты: ypbind слепо верит, кто бы ни отвечаел, который мог бы быть NIS сервером также как и "злоумышленник". Само собой разумеется это становится затруднением - если Вы управляете вашими базами данных паролей над NIS. Для принятия мер против этого, NYS не использует ypbind по умолчанию, но подбирает сервер для имени хостаиз файла конфигурации. 11.2 NIS против NIS + NIS и NIS + принимают участие немногим больше чем их название и общая цель. NIS + структуирован полностью различным способом. Вместо плоского названия пространство с разделенными NIS областями, это использует иерархическое название, оставляют промежутки подобные к таковому DNS. Вместо отображений, так называемых таблиц используются то, что составлено из строк и столбцов, где лаждая строка представляет предмет в NIS + базе данных, в то время как столбцы покрывают те реквизит + знает и заботится относительно них. Каждая таблица для данный NIS + - область включающяя таковых родительских областей. Кроме того, запись в таблице может содержать связь с другой таблице. Эти особенности делают его возможным к получении информации многими способами. Традиционный NIS имеет RPC номер версии 2, в то время как NIS + - версию - 3. NIS + не кажется, очень широко используемым однако, и я действительно не знаю многого относительно этого. (Хорошо, почти ничего). По этой причине, мы не будет связываться с этим здесь. Если Вы - 182 - заинтересованы в изучении большего, пожалуйста обратитесь к NIS Sun + справочника администратора ([GETST "nisplus"]). 11.3 Клиентская Сторона NIS Если Вы знакомы с записью или перенесением приложений сети, Вы обязательно заметите, что большинство NIS отображений, перечисленных выше соответствуют библиотеке функций в библиотеке C. Например, чтобы получить passwd информацию, Вы используете getpwnam (3) и getpwuid функции (3) которая возвращает информацию счета, связанная с данным именем пользователя или численной идентичностью пользователя. При нормальных обстоятельствах, эти функции будут выполнены при запросе по на стандартном файле, типа /etc/passwd. Nis-знающяя реализация этих функций, однако, будет модифицированна, и место обращения RPC для того, чтобы иметь NIS сервер для поиска имен пользователя или идентичность. Это случается полностью с приложением. Функция может также "конкатенировать " NIS отображение или " заменить " первоначальную картотеку с этим. Конечно, это не относится к реальной модификации файла, это только означает то, что он появляется к приложению как если бы файл был бы заменен или конкатенирован. Для ттадиционных NIS реализаций, там использовались общие условия, относительно которых замененные отображения, и которые были конкатенированы к исходной информации. Некоторые, подобно passwd отображениям, требуемым kludgy modifications картотеки passwd, который, когда выполнен неправильно, обнаружил бы защиту. Чтобы избежать этого pitfalls, NYS использует общую схему конфигурации это определяет, использует ли частное множество клиентских функций первоначальную карто и в каком порядке. Это будет описанный позже. 11.4 Запуск NIS Сервера После такого многого теоретического techno-babble, это - время, чтобы очитстить наши руки от грязной работы с конфигурации. В этом разделе, мы опишем конфигурацию NIS сервера. Если имеется уже NIS запуск - 183 - сервера на вашей сети, Вы не должны будете установить ваш собственный сервер; в этом случае, то Вы можете безопасно пропускать этот раздел. <> Note that if you are just going to experiment with the server, make sure you don't set it up for a NIS domain name that is already in use on your network. This may disrupt the entire network service and make a lot of peo- ple very unhappy, and very angry. В настоящее время используются два NIS сервера, свободно доступные для Linux, один содержится в yps пакете Tobias Reber's, и другой в Peter Erikson's ypserv package. Это не должно иметь значение, который Вы запускаете, независимо от того, используете ли Вы NYS или NIS клиентский код, который находится в libc в настоящее время. Во время этой записи, цифра для обработки NIS подчиненных серверов, кажется, более полной в yps. Так что, если Вы должны иметь дело с подчиненными серверами, yps мог бы быть лучшим выбором. После установки программы сервера (ypserv) в /usr/sbkn, Вы должны создать каталог, который будет проводить отображение, регистрируемо на Вашем сервере. При установке NIS области для brewery domain, отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это частную NIS область, проверяя есть ли каталог отображений. Если Вы блокируете обслуживание для некоторой NIS области, удостоверитесь удален ли каталог также. Отображения обычно сохраняются в картотеках DBM, чтобы ускорить поиски. Они создаются от главы, регистрирующей использование программ, называемой makedbm (для Tobias' сервер) или dbmload (для сервера Peter's). Они не могут быть изменчивыми. Преобразовани е главы регистрирует в форму parseable dbmload обычно требуя некоторого awk или sed, которые имеют тенденцию, чтобы быть немного утомительными к типу. Следовательно, Peter Eriksson's Ypserv пакет содержит Формирование который делает всю работу за Вас. Вы должны установить это как - 184 - Формирование файла в вашем отображении, и отредактировать это, чтобы отразить отображения которые Вы хотите распределить. В вершине файла Вы наход услуги Ypserv. По умолчанию, просмотры линии что - нибудь вроде этого: all: ethers hosts networks protocols rpc services passwd group netid Если Вы не хотите производить ethers.byname и ethers.byaddr отображения, например, просто удалите предпосылку эфиров из этого правила.Чтобы проверить вашу установку, это может удовлетворять тому, чтобы начать с только одного или двух отображении, подобно услугам. * Отображения. После редактирования Формирования файла, в то время как Вы находитесь в каталоге отображений, набирите "make". Это автоматически генерирует и устанавливать отображения. Вы должны удостовериться, чтобы модифицировать отображения всякий раз, когда Вы изменяете главный файл, иначе изменения останутся невидимыми для сети. Следующий раздел объясняет, кгк конфигурировать NIS клиентский код. Если ваша установка не работает, Вы должны пробовать выяснить или любые запросы достигнут вашего сервера или нет. Если Вы точно определяете команду -D, флажок линии к NYS серверу, то это печатает сообщения отладки на консоли относительно всех входящих запросов NIS, и возвращенных результатов. Они должны дать Вам подсказку относительно того, где задача находится. Tobias' сервер не имеет никакой такой опци 11.5 Установка NIS Клиента с NYS Через остаток от этой главы, мы опишем конфигурацию NIS клиента. Ваш первый шаг должен быть - сообщить NYS который сервер использован для NIS обслуживания, устанавливая это в файле конфигурации /etc/yp.conf. Очень прост типовой файл для множества сети Winery's может выглядеть следующим образом: - 185 - # yp.conf - YP configuration for NYS library. # domainname winery server vbardolino Первая формулировка сообщает всей NIS клиентуре, что они принадлежат к Winery NIS области. Если Вы упускаете эту линию, NYS использует название области, которой Вы приписывали вашу систему через команду domainname. Сервер формулировки называется NIS сервером. Конечно, IP адреса адресуются к vbardolino, и должны быть хостом в файле хоста; в качестве альтернативы, Вы можете использовать адрес IP непосредственно с формулировкой сервера. В форме, показанной выше, команда сервера сообщает, чтобы NYS использовал именованный сервер любой NIS области которой может быть. Если, однако, Вы перемещаете вашу машину между различными NIS областями часто, то Вы возможно захотите сохранить информацию для отдельных областей в картотеке yp.conf. Вы можете иметь информацию относительно серверов для различных NIS областей в Yp.conf, прибавляя NIS название области к формулировке сервера. Для образца, Вы могли бы измен"типовой файл для портативной ЭВМ, чтобы это выглядило подобно этому: # yp.conf - YP configuration for NYS library. # server vbardolino winery server vstout brewery Это позволяет Вам выдать портативную ЭВМ в любой из двух областей, просто при установке желательной NIS области при начальной загрузке введите команду названия. После создания этого базисного файла конфигурации, и уверенности в том это - всемирно - читаемый, Вы запустить ваш первый критерий, чтобы проверить, можете ли Вы подсоединиться к вашему серверу. Удостоверитесь, что выбрано отображение вашего сервеа, подобно - 186 - hosts.byname, и испытанию, чтобы восстановить, используя ypcat утилиту. Ypcat, подобно всем другим административным NIS инструментальным средствам, должен жить в /usr/sbin. # ypcat hosts.byname 191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org 191.72.2.3 vbardolino vbardolino.linus.lxnet.org 191.72.1.1 vlager vlager.linus.lxnet.org 191.72.2.1 vlager vlager.linus.lxnet.org 191.72.1.2 vstout vstout.linus.lxnet.org 191.72.1.3 vale vale.linus.lxnet.org 191.72.2.4 vchianti vchianti.linus.lxnet.org Вывод, который Вы получаете, должен быть на подобие вышепоказанного. Если Вы получаете сообщение об ошибках взамен, которое говорит "Can't bind to server which serves domain" или что-нибудь на подобие, затем или NIS название области, которое не имеет сервер соответствия, определенный в yp.conf, или сервер - unreachable по некоторым причинам. В последнем случае, удостоверитесь в том, что ping множеству производится положительный результат, и что это действительно запу Вы можете проверить последний, используя rpcinfo, который должен произвести следующий вывод: # rpcinfo -u serverhost ypserv program 100004 version 2 ready and waiting 11.6 Выбор правых отображений Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы должны решить который конфигурационный файл, чтобы заменить или увеличить с NIS отображениями. Обычно, Вы захотите использовать NIS отображения для множества и функций поиска пароля. Вышеупомяну тый особенно полезен, если Вы не запускаете BIND. Последний разрешает всем пользователям зарегестрироваться на их account из любой системы в NIS области; это обычно требует разделения центрального /местного к Это объяснено подробно в разделе 11.7 ниже. Другое отображение, подобно services.byname, не такое драматическое увеличение, но сохраняют Вас - 187 - от некоторой работы редактирования, если Вы устанавливаете любые сетевые приложения которые используют сервисное название, то это не в стандартном файле услуг. Вообще, Вы хотите иметь некоторую свободу выбора когда поиск- функция использует локальные файлы, и когда это делает запрос NIS сервера. NYS позволяет Вам сконфигурировать порядок, в котором функция обращается к этим услугам. Это управляется через картотеку /etc/nsswitch.conf, который замещает обслуживание названия, но конечно не ограничивает название обслуживание. Для любой из функций поиска данных это содержит линию, именующие услуги, чтобы использовать. Правильный порядок услуг зависит от типа данных. Это вряд ли то, что services.byname отображение будет содержать отличие входов из тех в локальном файле услуг; это может только содержать больше. Так хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и проверять NIS только если сервисное название не было найдено. Hostname информация, с другой стороны, может изменятся пченю часто, так, чтобы DNS или NIS сервер всегда имел наиболее точный accoun файл сохран как дублиррование, если DNS и NIS терпел неудачу. В этом случае, Вы захотели бы проверить локальный последний файл. Пример ниже показывает, как сконфигурировать gethostbyname (2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они будут перечисленны как услуги по очереди; если поиск идет хорошо, то результат будет возвращен, иначе следующее обслуживание осуждено. # small sample /etc/nsswitch.conf # hosts: nis dns files services: files nis Полный список услуг, которые могут использоваться с записью в Nsswitch.conf файле показыны ниже. Фактические отображения, файлы, серверы и вещи, которые делают запрос зависят от названия записи. - 188 - Nisplus или nis + использует NIS + сервер для этой области. Локализация сервера получена из картотеки /etc/nis.conf. Nis Использует текущий NIS сервер этой области. Локализация сервера делал запрос, сконфигурированный в картотеке yp.conf как показано в предыдущем разделе. Для записи множеств, отображения Hosts.byname и hosts.byaddr делают запрос. -176 - dns использует DNS сервер. Этот служебный тип полезен только для записи хоста. Сервера делающие запрос, все еще определяются в соответствии cо стандартом resolv.conf файла. files использует локальный файл, такой как /etc/hosts файл для хост записи. dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя, используемое для файла - соответствующего NIS отображение. В настоящее время, NYS поддерживает следующие nsswitch.conf записи: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, и др. Другие записи возможно могут быть добавленны. Рисунок 11.6 показывает более полный пример, который демонстрирует другую &осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS или в DNS база данных. То есть NYS продолжит искать локальные файлы, только если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой причине. Локальные файлы будут затем только использоваться при начальной загрузке и как backup, когда NIS сервер выключен. 11.7 Использование passwd и группы Maps Одно из главных приложений NIS находится в синхронизации пользователя и account информации относительно всех множеств в NIS области. К концу, Вы - 189 - обычно хранит только малый локальный файл /etc/passwd, к которому добавлена site-wide информация из NIS отображений. Однако, просто предоставления возможности NIS поиска для этого обслуживания в nsswitch.conf не вполне достаточно. Полагаясь на информацию пароля, распределенную NIS, Вы сначала должны удостовериться, что числовая идентичность пользователя всех пользователей, которые у Вас есть в Вашем локальном passwd файлесоответствуют идеи NIS сервера относительно идентичности пользователя. Вы возможно захотите использовать это для других целей также, подобно установке NFS значений от других хостов на вашей сети. # /etc/nsswitch.conf # hosts: nis dns [NOTFOUND=return] files networks: nis [NOTFOUND=return] files services: files nis protocols: files nis rpc: files nis Рисунок 17. Примерный nsswitch.conf файл. Если любая из числовых идентичности в /etc/passwd или /etc/group отклоняется от тех, которые в maps, то Вы должны скорректировать файл ownerships для всех файлов, которые принадлежат этому пользователю. Сначала Вы должны заменить все uids и gids в passwd и в группах новых значений; затем найдите вуе фвйлы, которые принадлежат пользователям и былы только что изменены, и в заключение замените их ownerships. Примите новости используемые для того, чтобы иметь идентичность пользователя была бы 9, и okir имел бы идентичность пользователя 103, которые были заменены на некоторое другое значение; Вы могли бы затем выпорлнить следующие команды: # find / -uid 9 -print >/tmp/uid.9 # find / -uid 103 -print >/tmp/uid.103 # cat /tmp/uid.9 | xargs chown news - 190 - # cat /tmp/uid.103 | xargs chown okir Важно то, что Вы выполняете эти команды с новым, установленным passwd файлом, и что Вы собираете все имена файлов прежде, чем Вы изменените ownership любого из них. Для того, чтобы модифицировать ownerships группы файлов, Вы должны использовать похожую команду. Сделав это, численный uid's и gid's на вашей системе согласиться с теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет - прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски для пользователя и информации группы: # /etc/nsswitch.conf - passwd and group treatment passwd: nis files group: nis files Это заставляет команду входа в систему, и всех ее друзей сначала сделать запрос NIS maps, когда пользователь пробует log in, и если этот поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы удалите почти всех пользователей из Вашего локального файла, и только оставите записи для root и generic accounts подобно почте. Это потому, что некоторые насущные задачи системы могут требовать к map uids имя пользователя или наоборот. Например, административный cron job может выполнить команду su, для того чтобы временно стать новостями, или UUCP подсистема может отправлять по почте отчет состояния. Если новости и uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению, терпеть неудачу в течение&NIS"brownout. Имеются две большие проблемы: с одной стороны, установка, как уже было описано в начале, до сих пор работает только для наборов программ входа в систему, которые не используют теневой пароль, подобно тем, что включены в util-linux пакет. Путаница при использовании теневых паролей с NIS будет объяснена ниже. С другой стороны, команды входа в систему - не единственые, которые обращаются к passwd файлу - посмотрите на команду ls, которую большинство людей использует почти постоянно. - 191 - При выполнении длинной распечатки, ls выделит символические имена для пользователя и группу владельцев файла; то есть для каждого uid и gid это представляет собой целую схватку, это должно сделать запрос на NIS сервер, только один раз. Это ужасно замедлит выполнение, если ваша локальная сеть - clogged, или, еще хуже, когда NIS сервер не на той же самой сети, для этого датаграммы должны пройти через программу маршрутизации. Но пока это еще не вся история. Вообразите, что случится если пользователь захочет изменить свой пароль. Обычно, она вызовет passwd, который считает новый пароль и модифицирует локальный файл passwd. Это невозможно сделать с NIS, так как с тех пор файл локально больше не доступен, но если пользователи подсоединились к NIS серверу, и вдруг захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому, NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и обеспечивает его модифицируемой информацией пароля. Обычно, Вы устанавливаете yppasswd для нормальной программы, делая что - нибудь вроде этого: # cd /bin # mv passwd passwd.old # ln yppasswd passwd В то же самое время Вы должны установить rpc.yppasswdd на сервер и запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от ваших пользователей. 11.8 Использование NIS с Shadow Support Не имеется никакой NIS поддержки для мест, которые используют теневой вход в систему набора программ. John F. Haugh, автор теневого набора программ, недавно выпущенной версии теневых библиотечных функций, описанных GNU библиотекой GPL к comp.sources.misc. Это уже имеет некоторую поддержку - 192 - для NIS, но она пока еще не полна, и файлы пока еще не добавлены к стандарной библиотеке для C. С другой стороны, при публикации информации из /etc/shadow через NIS вид поражения цели теневого набора программ. Хотя NYS функции поиска пароля не используют shadow.byname map или что - либо аналогичное, очевидно NYS поддерживает использование локального /etc/shadow файла. Когда NYS реализация getpwnam обращается к просмотру информации, связанной с данным login именем, средства, точно определенные passwd записью в nsswitch.conf делают запрос. Nis обслуживание будет просто искать имя в passwd.byname map на NIS сервере. Обслуживание файлов, однако, проверит, существует ли /etc/shadow, и если существует, то попробует открыть это. Если ни один из файлов не присутствует, или если пользователь не имеет привилегию root, то происходит возвращение к обычной работе поиска информации пользователя в /etc/passwd. Однако, если теневой файл существует и может быть открыт, то NYS извлечет пароль пользователя из shadow. Getpwuid функция соответственно выполняется. В этом режиме, binaries, компилируемый с NYS, будет иметь дело с локальной установкой теневого набора программ. 11.9 Использование традиционного NIS кода. Если Вы используете код клиента, который находится в стандарте libc, то конфигурация NIS клиента немного отлична. С одной стороны, это использует ypbind daemon для того, чтобы передать информацию для активных серверов скорее чем считывать эту информацию из файла конфигурации. Вы следовательно должны удостоверится в том, что бужет запущен ypbind при начальной загрузке. Он должен быть вызван после установленной NIS области, и RPC portmapper тоже должен быть запущен. Вызов ypcat нужен для того, чтобы проверить работает ли сервер так, как он должен (см. выше). Недавно, имелось некоторое число bug reports, которые сообщают, что NIS терпит неудачу, сообщая при этом: "clntudp create: RPC: portmapper failure - RPC: unable to receive''. Это все из-за несовместимого изменения в способе, как ypbind связывается с библиотечными функциям. Получая последние источники для NIS - 193 - утилит и перетранслируя их, должна быть исправлена эта задача. (5) Также, способ традиционного NIS решает это, как соединить NIS информацию с этим из локальных файлов отклоняемую от используемого NYS. Например, чтобы использовать NIS отображение пароля, Вы должны включить следующую линию где-нибудь в Вашем /etc/passwd map: +: *:0:0::: Это маркирует место где функции поиска пароля "вставляют" NIS отображения. Вставка подобной линии (минус последние два двоеточия) в /etc/group делают тот же самое для group. * maps. Для того, чтобы использовать hosts.* maps, распределенные NIS, измените order line в host.conf файле. Например, если Вы хотите использовать NIS, DNS, и файл /etc/hosts (в том порядке), то Вы должны изменить эту линию на: order yp bind hosts Традиционная NIS реализация не поддерживает никакие другие отображения в настоящее время. 5. Источник для yp-linux может быть получен из ftp.uniрaderborn.de в каталоге /pub/Linux/LOCAL. 12. Сетевая файловая система (NFS) NFS, the network file system, является возможно наиболее видной сетью услуг, использующей RPC. Это позволяет обращаться к файлам на отдаленных хостах точно тем же самым способом, как пользователь обратился бы к любым" локальным файлам. Сделано возможным смешением kernel функциональных возможностей на клиентской стороне (которая использует отдаленную файловую систему) и NFS сервер на стороне сервера (который обеспечивает файл данных). Этот доступ к файлу полностью очевиден клиенту, и работает через все разнообразие серверов и архитектуры хостов. - 194 - NFS предлагает ряд преимуществ: + Данные, к которым обращаются все пользователи, могут быть сохранены на центральном хосте, с клиенами устанавливающими этот каталог при начальной загрузке. Например, Вы можете сохранить все accounts пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount /home от того хоста. Если оно установлено бок о бок с NIS, то пользователи могут затем войти в любую систему, и все еще работать на одном множестве файлов. + Данные, потребляющие большие количества дискового пространства могут быть сохранены в единственном хосте. Например, все файлы и программы относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в одном месте. + Административно-управленческая информация может быть сохранена в адинственном хосте. Нет нужды использовать rcp для того, чтобы установить тот же самый глупый файл на 20 различных машин. Linux NFS - в значительной степени работа Rick Sladkey, (1), кто написал NFS kernel код и большие части NFS сервера. Последний, выводил из unfsd пространства пользователя NFS сервер, первоначально написанный Mark Shand, и hnfs Harris NFS сервер, написанный Donald Becker. Давайте теперь посмотрим том, как NFS работает: клиент может запросить установить каталог от отдаленного хоста на локальном каталоге тем же способом, и он может установить физическое устройство. Однако, синтаксис, используемый для того, чтобы точно определить отличен ли отдаленный каталог. Например, чтобы mount /home хост vlager к /users на vale, администратор выпустил бы следующую команду на vale: (2)  " 1. Rick может быть найден в jrs@world.std.com. # mount -t nfs vlager:/home /users - 195 - mount затем попробует соединиться с mountd, устанавленный с daemon на vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и если так, вернет это к file handle. Этот handle файл будет использоваться во всех последовательных запросах к картотекам ниже /users. Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя файла, к которому обращаются, и user's user и идентичность группы как параметры. Они используются в определении прав доступа к точно определенному файлу. Чтобы предотвратить от несанкционированного чтения или модифицирования файла, пользователь и идентичность группы должны быть теме же самыми на обоих хостах. На большинстве Un*x реализаций, NFS функциональные возможности обоих клиентов и сервер выполнены как kernel уровень daemons, которые начаты из пространства пользователя при начальной загрузке системы. Они - NFS daemon (nfsd) на хосте сервера, и блок ввода - вывода Daemon (biod) выполняющийся на клиентском хосте. Чтобы улучшить производительность, biod выполняет асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также, несколько nfsd daemons обычно запускается совместно. NFS реализация Linux, немного отлична в этом самом клиентском коде, крепко объединена в файловой системе (VFS) уровень ядра и не требует дополнительного управления через biod. С другой стороны код сервера запускается полностью в пространстве пользователя, так, чтобы при запуске нескольких копий сервера в одно и то же время было бы почти невозможным из- за синхронизации. Linux NFS, в настоящее время также существует отсутствие чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот недостатолк в ближайшее время. (3) Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel версии 1.0 не способен распределить память в кусках больших чем 4k; как следствие, сетевой код не может обрабатывать датаграммы большие чем приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это значит, что передача к и из NFS daemons выполняющейся на системах, которые используют большие UDP датаграммы по умолчанию (например 8k на SunOS) - 196 - должны быть уменьшенны в размере искуственно. Этот причиняет вред характеристике под влиянием некоторых обстоятельств. (4) Этот предел входит в поздние Linux-1.1 ядра, и клиентский код был модифицирован для того, чтобы пользоваться этим преимуществом. 2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount видит из двоеточия то, что это определяет NFS объем. 3. Задача с write-behind - то, что kernel буфер кэша индексирован парами device/inode, и следовательно не может использоваться для nfs- установленных файловых систем. 12.1 Подготовка NFS Прежде, чем Вы можете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет NFS поддержку, компилируемую в. Более новые ядра для этого имеют простой интерфейс на proc файловой системе, файл /proc/filesystems, который Вы можете отобразить используя cat: $ cat /proc/filesystems minix ext2 msdos nodev proc nodev nfs Если nfs отсутствует из этого списка, то Вы должны скомпилировать Ваше собственное ядро с включенным NFS. Конфигурирование kernel сетевых опций объяснено в разделе " Kernel конфигурация " главы 4 .. Для более старых ядер до 1.1 Linux, самый простой спо