оляет безграничному числу образцов, чтобы быть запущенными одновременно; но это редко когда - 165 - используется. Эти серверы должны точно определить nowait. Гнезда потока должны всегда использовать nowait. User это является идентичностью входа в систему пользователя, объясненный ниже. Это будет часто root user, но некотпрые" услуги могут использовать различные account. Это - очень хорошая идея к применению принципа наименьшего количества привилегии здесь, который заявляет что Вы не должны запускать команду ниже привилегированного account если программа не требует этого для присущего функционирования. Для примера, NNTP сервер новостей будет запускать новости, пока ус риск защиты (типа tftp, или finger) будут управляться как nobody. server дает полный путь программы сервера, которая будет выполнена. cmdline это- командная строка, которую нужно запустить на сервере. Она включает аргумент 0, который является названием команды. Обычно, это не будет названием программы сервера, если программа ведет себя по-другому, когда вызывается с различным именем. Эта область пуста для внутренних услуг. Типовой inetd.conf файл изображен на рисунке 10.1. Finger service прокомментированног так чтобы это было не доступно. Это часто выполняется из соображений безопасности, потому что может использоваться нападавшими для того, чтобы получить имя пользовател и на вашей системе. Tftp имзображено прокомментированным также. Tftp осуществляет Примитивный Протокол Передачи файла, который позволяет передавать любые всемирно - читаемые файлы из вашей системы без пароля. Это особенно вредно для файла /etc/passwd, даже более того, когда Вы не используйте теневой пароль. TFTP обычно используется клиентурой без диска и X терминалами при загрузке их кода из сервера при начальной загрузке. Если Вы должны запустить tftpd для этой проблемы, удостоверитесь, что ограниченная - 166 - область действия к директориям клиентов будет восстановлена из файлов, добавляя те названия каталогов к команде tftpd's линии. Это показано во второй tftp линии в примере. 10.2 Tcpd средства управления доступом " Начиная с открытия компьютера к сети средство вовлекает много защиты, приложения разработанные так, чтобы принять меры против типов решения. Некоторые из этих, однако, могут быть flawed (наиболее решительно демонстрированными RTM Internet worm), или могут не различаться между безопасными хостами, из которых просьбы о частном обслуживании будут приняты, и опасными хостами, чьи запросы должны быть отклонены. Мы уже кратко обсуждали finger и tftp услуги выше. # # inetd services ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd - b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless login stream tcp nowait root /usr/sbin/rlogind in.rlogind shell stream tcp nowait root /usr/sbin/rshd in.rshd exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd internal services # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal - 167 - discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal Рис. 15. /etc/inetd.conf file. ограничить доступ к этим услугам " доверенные множества " только, которые невозможны с обычной установкой, где inetd обеспечивает эту защиту всей клиентуре. &Полззное средство для этого - tcpd, (1), так называемый daemon wrapper. Для ТСP услуги Вы хотите проконтролировать или защищать его, вызывая вместо его программу сервера. Tcpd регестрирует запрос к syslog daemon, проверяя позволяют ли remote хосту использовать обслуживание, и только если это будет выполнено в реальной программе сервера. Заметьте, что это не работа с udp-основанными услугами. Например, чтобы перенести finger daemon, Вы должны изменить corresponding линию в inetd.conf 1. Написано Wietse Venema, wietse@wzv.win.tue.nl. # wrap finger daemon finger stream tcp nowait root /usr/sbin/tcpd in.fingerd Без добавления какого-либо access контроля, это появится у клиенту точно также как и обычная установка finger, за исключением того, что любые запросы будут регистрироваться к syslog's auth facility. Управление доступом выполнено посредством двух файлов, называемых /etc/hosts.allow и /etc/hosts.deny. Они содержат разрешение входов и отрицание доступа, соответственно, к некоторым услугам и хостам. Когда tcpd обрабатывает просьбу о обслуживании finger от клиентского хоста, именованного Biff.foobar.com, он просматривает hosts.allow и hosts.deny (в этом порядке) для соответствующей записи и сервисного и клиентского хоста. Если запись соответствия была найдена в - 168 - тся, независимо от любой записи в hosts.deny. Если соответствие найдено в hosts.deny, то запрос будет отклонен закрывая связь.схему. Если никакое соответствие не найдено вообще, запрос будет принят. Входы в файл доступа выглядят следующим образом: Servicelist: hostlist [: shellcmd] Servicelist - список сервисных имен из /etc/services, или ключевое слово ALL. Чтобы соответствовать всем услугам за исключением finger и tftp, используйте "ALL"EXCGPT finger, tftp''. Hostlist - список имен хостов или адресов IP, или ключевых слов ALL, LOCAL, или UNKNOWN. ALL соответствует любой хост, в то время как LOCAL соответствует имя хоста, не содержащие точку.(2) UNKNOWN соответствует любым множествам чьи названия или адреса ошибочны. Name string, начинающееся с точки соответствует всем хостам, чьи области является равными этому названию. Например,.foobar.com пара - Biff.foobar.com. Имеются также условия для IP сетевых адресов и подсет к странице справочника (5) для деталей. Для того, чтобы отказать в доступе к finger и tftp услугам, кроме локальных хостов, поместите следующее в /etc/hosts.deny, и сделайте пустым /etc/hosts.allow: 2. Обычно только локальные имена хостов, полученные из поисков в /etc/hosts не содержать никакой точки. in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain Произвольная shellcmd область может содержать командную оболочку, чтобыбыть вызванной, когда запись согласована. Это полезно установить ловушку, которая может разоблачить потенциальных нападавших: in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \ echo "request from %d@%h" >> /var/log/finger.log; \ - 169 - if [ %h != "vlager.vbrew.com" ]; then \ finger -l @%h >> /var/log/finger.lы отличны. Область псевдонимов позволяет точно определить альтернативные имена для того же самого обслуживания. Обычно, Вы не должны менять файл услуг, который приходит Наряду с сетевым программным обеспечением на вашей Linux системе. Однако, мы даем малую выборку из того файла ниже. # The services file: # # well-known services echo 7/tcp # Echo echo 7/udp # discard 9/tcp sink null # Discard discard 9/udp sink null # daytime 13/tcp # Daytime daytime 13/udp # chargen 19/tcp ttytst source # Character Generator chargen 19/udp ttytst source # ftp-data 20/tcp # File Transfer Protocol (Data) ftp 21/tcp # File Transfer Protocol (Control) telnet 23/tcp # Virtual Terminal Protocol smtp 25/tcp # Simple Mail Transfer Protocol nntp 119/tcp readnews # Network News Transfer Protocol # # UNIX services exec 512/tcp # BSD rexecd biff 512/udp comsat # mail notification login 513/tcp # remote login who 513/udp whod " # remote who and uptime shell 514/tcp cmd # remote command, no passwd used - 170 - syslog 514/udp # remote system logging printer 515/tcp spooler # remote print spooling route 520/udp router routed # routing information protocol Заметьте, что, например, обслуживание ECHO предлагается на порте 7 для обоих и TCP и UDP, и этот порт 512 используется для двух различных услуг, а именно для СИСТЕМЫ СПУТНИКОВОЙ СВЯЗИ КОМСАТ daemon (которые сообщают пользователям относительно новой почты, смотри xbiff(1x)), над UDP, и для remote execution (rexec(1)), используя TCP. # # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol raw 255 RAW # RAW IP interface 10.4 Дистанционное управление Очень общий механизм для клиент-сервера приложения обеспечивается RPC, пакетом дистанционного управления. RPC был разработан Sun Micrsystems, и эта система - набор инструментальных средств и библиотечных функций. Важные приложения, сформированны на вершине RPC - NFS, Network Filesystem, и NIS, Network Information System, обе из которых будут представлены в следующих главах. RPC сервер состоит из системы процедур того, что клиент может обратится, посылая RPC запрос к серверу, наряду с параметрами процедуры. Сервер вызовет обозначенную процедуру по защите клиента, вручая обратно возвращаемое значение, если имеется любое. Чтобы быть машинно-независимыми, зсе жанные, обмененные между клиентом и сервером - 171 - преобразованны к так называемому Внешнему Представлению Данных (XDR) отправителю, и преобразованны обратно к машинно - локальному Иногда, уточнения к RPC приложению вводят несовместимые изменения в процедуре call interface. Конечно, при простом изменение сервер разрушил бы все приложение, которые все еще ожидают original behavior. Следовательно, RPC программы имеют номера версии, приписываемые к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с помощью интерфейса этот счетчик. Часто, сервер может предлагать несколько версий одновременно; клиентура затем указывает номером версии версии они хотят использовать. Сетевая связь между RPC серверами и клиентурой - особая. RPC сервер предлагает один или более системных процедур; каждое множество называется программой, и однозначно идентифицировано номером программы. Имена обслуживания отбора списка существуют для того, чтобы запрограммировать числа обычно сохраняемые в /etc/rpc, выборка которого воспроизведена ниже ра рисунке 10.4 В TCP/IP сетях, перед авторами RPC стояла задача программирования чисел к обобщенным сетевым услугам. Они выбрали - иметь каждый сервер, обеспечивающий, и TCP и UDP порт для каждой программы и каждой версии. Вообще, RPC приложения используют UDP посылку данных, и возвращаются обратно к TCP тогда, когда данные, которые будут переданы не впишутся в единственную UDP датаграмму. Конечно, клиентские программы должны иметь способ выяснить который из них порт отображения номера программы. Использование файла конфигурации для этого, был бы слишком негибки; с тех пор RPC приложения не используют зарезервированные порты, не имеется никакой гарантии, что порт первоначально подразумевал использоваться наше приложепие "баз данных. Следовательно, RPC приложения выбирают любой порт который, они могут получить, и зарегистрировать это с так называемым por действия - как обслуживание broker для всех RPC серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с обслуживанием с данным номером программы сначала сделает запрос - 172 - portmapper на числа порта обслуживание, которые могут быть достигнуты. Этот метод имеет частичный недостаток, что это вводит единственную точку отказа, очень похожую на inetd daemon. Однако, этот случай немного хуже, потому что когда portmapper умирает, вся RPC информация порта теряется; это обычно значит, что Вы должны перезапустить все RPC серверы вручную, или перезагрузить целую машину. На Linux, portmapper называется rpc.portmap и постоянно находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2, рortmapper не требует любой работы по конфигурации. 10.5 Конфигурирование r команд Имеется ряд команд для выполнения команд на remote хосте. Они - rlogin, rsh, rcp и rcmd. Они все порождают оболочку на remote хосте и позволяют пользователю выполнять команды. Конечно, клиент должен иметь account на хосте, где команда должна быть выполнена. Таким образом все эти команды выполняют процедуру разрешения. Обычно, клиент сообщяет название входа в систему пользователя на сервер, который # # /etc/rpc - miscellaenous RPC-based services # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 " ypupdated 100028 ypupdate - 173 - Рис. 16. A sample /etc/rpc file. по очереди запрашивает пароль, который утвержден обычным способом. Иногда, однако, желательно ослабить проверки разрешения для некоторых пользователей. Например, если Вы часто должны регистрироваться в других машинах на вашей локальной вычислительной сети, Вы могли бы захотеть быть признанным без ввода пароля каждый раз. Отключение разрешения желательно только на малом числе хостов, чьи базы данных паролей синхронизированы, или для малого числа из привилегированных пользователей, которые должны обращаться к многим машинам для административной причины. Всякий раз, когда Вы хотите позволять людям регестрироваться на вашем хосте при необходимости точно определить идентичность входа в систему или пароль, удостоверитесь, что Вы не делаете ошибку предоставляя доступ кому-нибудь еще. Имеются два способа блокировать разрешение, для того чтобы проверить r команды. Каждый - для супер пользователя, чтобы позволить некоторым или всем пользователям зарегестрироваться без пароля. Этот доступ управляется картотекой вызываемой /etc/hosts.equiv. Это содержит список множеств и имен пользователя, которые рассматриваются эквивалентными пользователям на локальном хосте. Альтернативная опция - для пользователя - предоставление другим пользователям на некоторых х быть перечислены в файле.rhosts в директории пользователя. Для соображений безопасности, эта картотека должна принадлежать пользователю или супер пользователю, и не должна быть symbolic link, иначе это будет игнорирован Когда клиент запрашивает r обслуживание, ее хост и название пользователя ищются в файле /etc/hosts.equiv, и затем в файле.rhosts пользователя. Как - пример, предположим, что janet работает " гауссе и пытается зарегестрироваться в joe's account на euler. Следуя далее, мы обратимся к Janet как клиентскому пользователю, и к Joe как к Локальному пользователю. - 174 - Теперь, когда типы Janet $ Rlogin -l joe euler на гауссе, сервер сначала проверил бы hosts.equiv (4), предоставлен ли Janet свободный доступ, и если нет, то он попробует просмотреть.Rhosts в исходном каталоге joe's. Файл hosts.equiv на euler походит на это: gauss euler -public quark.physics.groucho.edu andres Запись состоит из названия хоста, необязательно сопровождаемого именем пользователем. Если название множества появляется везде, то все пользователи от того множества будут допущены к их локальным acount без любых проверок. В вышеизложенном примере, Janet позволили бы зарегестрироваться в ее account janet когда выходит из гаусса, и тот же самый применяется любому другому пользователю за исключением root Однако, если Janet захочет зарегестрироваться как joe , пароля как обычно. Если название хоста сопровождается названием пользователя, как и в последней линии вышеупомянутой типовой картотеки, то этому пользователю будет дан пароль-свободный доступ ко всем accont за исключением accony\t root. Имени хоста может также предшествовать знак "минус", как на записи "-общий". Это требует разрешения на все account на общем, независимо от того, что пользователи единичного права предоставляют в их картотеке.rhosts. 3. В NFS среде окружения, Вы были бы должны дать этому защиту 444, потому что супер пользователь часто ограничивает в доступе к файлам на дисках, установленных через NFS. 4. Заметить, что файл hosts.equiv не обыскан когда кто -то делает попытку к регистрации как root. - 175 - " / 165 - Форматфайла.rhosts идентичен таковому hosts.equiv, но значение немного отлично. Рассмотрите Joe's.rhosts файл на Euler: chomp.cs.groucho.edu gauss janet Первая запись допускает, что joe освобождают acess при регистрации из Chomp.cs.groucho.edu, но не воздействуют на права любого другого account на euler или chomp. Вторая запись - небольшое изменение этого, в котором предоставляется janet свободный доступ к account Joe при регистрации из гаусса. Заметьте, что название хоста клиента получено обратным отбором. Адрес вызывающего оператора к названию, так, чтобы эта особенность failed с хостами к решающему устройству. Имя хоста клиента рассматривается в соответствии с названим в хостах зарегистри рованных в одном из следующих случаев: + Каноническиое имя хоста клиента (не псевдоним) буквально соответствует имени хоста в файле. + Если имя хоста клиента - полностью квалифицированно, то название области (типа возвращенного решающим устройством, когда Вы имеете выполняющую DNS), не соответствует имени хоста в множествах файлов, это сравнивается с тем именем хоста, расширенным с локальным названием области. 11. Сетевая информационная система Когда Вы запускаете локальную вычислительную сеть, ваша цель - обеспечить среду окружения вашим пользователям, которая делает сеть очевидной. Важен stepping stone к этому концу должен хранить насущными данные типа пользователя синхронизированные между всеми - 176 - множествами. Мы видели перед этим, что для решенияимени хоста, мощное и сложное обслуживание существует, являющееся DNS. Для других задачи, имеется нет такого специализированного обслуживания. Кроме того, если В малой локальной вычислительной сетью с 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, самый простой способ выяснять имеет ли ваше ядро включенную NFS поддержку - фактически попробовать установить NFS файловую систему. Для этого, Вы могли бы создать каталог ниже /tmp, и&поптобовать установить локальный каталог на нем: - 197 - # mkdir /tmp/test # mount localhost:/etc /tmp/test Если эта попытка установки выдает сообщениее об ошибках выводя, "fs type nfs no supported by kernel'', то Вы не должны делать новое ядро с включенной NFS. Любые другие сообщения об ошибках полностью безобидны, так как Вы пока еще не сконфигурировали NFS daemons на вашем множестве. 12.2 Установка NFS значения 4. Как мне объяснил Alan Cox: NFS спецификация требует сервер к потоку при каждой записи на диск прежде, чем он успевает вернуть подтверждение. Так как BSD ядра только способны к, установленным по размеру страницей, записям (4K), записанным по 4 куска по 1k каждый в bsd-based NFS, серверу получает в результате 4 операции записи по 4k каждый. NFS значения (5) установлены таким же способом, как и обычные файловые системы установленны. Вы вызываете mount, используя следующий синтаксис: # mount -t nfs nfs volume local dir options Nfs значение дано как отдаленный хост: отдаленная директория. С тех пор как эта совокупность условных знаков является уникальной в NFS файловых системах, то Вы можете не учитывать nfs опцию -t. Имеется ряд дополнительных опций, которые Вы можете точно определить установив над mounting NFS значение. Они могут также быть даны -o переключателем в командной строке, или в области опций /etc/fstab записей для значения. В обоих случаях, составные опции отделены друг от друга запятыми. Опции, точно определенные на командной строке всегда отменяют те, что были даны в файле fstab. Типовая запись в /etc/fstab могла бы быть такой: - 198 - # volume mount point type options news:/usr/spool/news /usr/spool/news nfs timeo=14,intr Этот значение может затем быть установлено при использовании # mount news:/usr/spool/news В отсутствии fstab записи, NFS устанавливает просмотр вызовов большинства uglier. Например, предположим, что Вы устанавливаете home каталоги Ваших пользователей из машины, называемой moonshot, которая использует заданный по умолчанию размер блока равный 4k для операции чтения - записи. Вы могли бы уменьшить размер блока до 2k, чтобы подойти под размер Linux(овских) датаграмм введя следующую команду: # mount moonshot:/home /home -o rsize=2048,wsize=2048 5. Никто не говорит "файловая система", потому что здесь не существует подходящей файловой системы. Список всех допустимых опций полностью описан в руководстве по Nfs(5), которая идет вместе с Rick Sladkey's NFS-aware mount tool, который может быть найден в Util-linux пакете Rik Faith). Следующее - незавершенный список тех, которые Вы возможно захотели бы использовать: rsize=n и wsize=n - они точно определяют датаграмный размер, используемый NFS клиентурой при чтении и записи запросов, соответственно. В настоящее время они определенны по умолчанию - 1024 байтам, из-за предела на UDP размере датаграммы, описанном выше. timeo=n - это устанавливает время (в десятках секунд), сколько NFS клиент будет ждать запрос, чтобы завершить работу. Значения по умолчанию - 0.7 секунды. hard - точно маркирует этот объем как hard-mounted. Это включено по - 199 - умолчанию. soft - soft-mount драйвер ( противоположный hard-mounted). intr - позволяет сигнализировать о том, что надо прервать NFS вызов. Полезно для прерывания выполнения, когда сервер не отвечает. Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер стал временно недостижим. Они работают вместе следующим способом: всякий раз, когда клиент ппсылвет запрос к NFS серверу, он ожидает, что операция закончится после данного интервала (точно установленным в опции блокировки по времени). Если никакого подтверждения не получено внутри этого промежутка времени, то появится так называемая minor timeout (незначительная остановка по времени), и операция повторится, но уже с интервалом блокировки по времени вдвое большим. После достижения максимальной блокировки по времени - 60 секунд, происходит глобальная блокировка по времени. По умолчанию, глобальная блокировка по времени заставит клиента напечатать сообщение на консоль и начинать все снова. В принципе это может продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор пока сервер не становится доступным, называются hard-mounted. В противоположность им, soft-mounted значения генерируют ошибку ввода - вывода для вызова процесс всякий раз, когда происходит глобальная блокировка по времени. Из-за того, что write-behind вводится буферным кэшем, то это условие ошибки не распространяется непосредственно на процесс прежде, чем это вызовет функцию записи 2 в следующий раз, так как программа никогда не сможет убедиться в том что операция записи к soft-mounted значению имела место вообще. Поставили ли Вы hard- или soft-mount значение - это не только вопрос вкуса, но также и то, что Вы должны сделать с тем сортом информации, которую Вы хотите получить от этого значения. Например, если Вы устанавливаете ваши Х программы NFS, Вы конечно не хотели бы, чтобы ваш X сеанс шел бы "бешено" только потому, что кто -то привел сеть к останову, - 200 - запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet разъем на некоторый момент. Используя hard-mounting, Вы удостоверяетесь в том, что ваш компьютер будет ждать, пока не появится возможность заново восстановить контакт с вашим nfs-сервером. С другой стороны, non-critical данные, типа nfs-mounted news partititons или FTP врхив может быть также soft-mounted, так что это не повесит ваш сеанс в случае, если отдаленная машина должна стать временно "недостигаемой", или просто быть выключенной. Если ваша сетевая связь с сервером - flakey или проходит через программу маршрутизации, то Вы может также увеличивать начальную блокировку по времени, используя опцию timeo, или hard-mount значение, но позволяйте сигнализировать прерывание вызова NFS, так чтобы Вы могли прервать любой hanging file access. Обычно, mountd daemon будет иным способом следить, которые каталоги были установлены, и какими хостами. Эта информация может быть отображена при использовании программы showmount, которая также включена в NFS пакет сервера. Linux mountd не делает этого. 12.3 NFS daemon(область) Если Вы хотите обеспечить NFS обслуживание другим хостам, то Вы должны запустить nfsd и mountd daemons на вашей машине. Как rpc-основанные программы, они не управляются inetd, но запускаются при начальной загрузке, и регестрируют сами себя непосредственно с portmapper. Следовательно, Вы должны удостовериться в том, что они запущенны только после того, как rpc.portmap выполнилось. Обычно, Вы должны включить следующие две линии в вашем rc.inet2 script: if [ -x /usr/sbin/rpc.mountd ]; then /usr/sbin/rpc.mountd; echo -n " mountd" fi if [ -x /usr/sbin/rpc.nfsd ]; then /usr/sbin/rpc.nfsd; echo -n " nfsd" if Информация монопольного использования файлов NFS daemon обеспечивает своей клиентуре, обычно содержащей только численного пользователя и идентичность группы. Если и клиент и сервер подсоединят того же самого - 201 - пользователя и группу имен с этой самой численной идентичностью, то им обязательно скажут разделить то же самое пространство uid/gid. Для примера, когда Вы используете NIS, чтобы распределить passwd информацию всем хостам на вашей LAN. & " В некоторых случаях, они не соответствуют. Достаточно модифицированного uid's и gid's клиента, чтобы соответствовать таковому серверу, Вы может использовать ugidd mapping daemon, чтобы работать вокруг этого. Использование map daemon опцию объяснено ниже, Вы может сообщить nfsd отобразить uid/gid пространство сервера к пространству uid/gid клиента при помощи ugidd на клиента. ugidd - rpc-основанный сервер, и запущен из rc.inet2 точно также как и nfsd и mountd. if [ -x /usr/sbin/rpc.ugidd ]; then /usr/sbin/rpc.ugidd; echo -n " ugidd" fi 12.4 файл экспорта В то время как вышеупомянутые опции обращаются к NFS конфигурации клиента, имеется различное множество опций на стороне сервера при выборе конфигурации per-client. Эти опции должны быть установленны в /etc/exports файле. По умолчанию, mountd не позволяет кому угодно устанавливать каталоги из локального хоста, которое является довольно разумной позицией. Для того, чтобы разрешить одному или большему количеству хостов установливать nfs каталог, то это должно быть экспортированно, то есть должно быть определено в файле экспорта. Типовой файл может выглядеть следующим образом: # exports file for vlager /home vale(rw) vstout(rw) vlight(rw) /usr/X386 vale(ro) vstout(ro) vlight(ro) - 202 - /usr/TeX vale(ro) vstout(ro) vlight(ro) / vale(rw,no root squash) /home/ftp (ro) Каждая линия определяет каталог, и хост, которому позволенно установить его. Имя хоста - обычно полностью квалифицированное название области, но может содержать * и ? универсальные символы, которые действуют способом при котором они действуют сомместно с Bourne оболочкой. Например, lab*.foo.com соответствует lab01.foo.com также как и laber.foo.com. Если никакое имя хоста не дано, как с каталогом /home/ftp в приоере выше, то любому хосту позволено установить этот каталог. При проверке клиентского хоста против файла экспорта, mountd будет искать hostname клиента используя gethostbyaddr(2) вызов. С DNS, этот вызов возвращает каноническиий hostname клиента, так что Вы должны удостовериться в том не используется ли псевдонимы в экспорте. Без использования DNS, возвращенное имя - первый hostname, найденный в файле хоста, которая соответствует адресу клиента. Имя хоста сопровождается произвольным, отделенным запятой, списком флагов, приложенных в скобках. Эти флаги могут принимать следующие значения: insecure - разрешает не-опознанный доступ из этой машины. unix-rpc - требует unix-области RPC установление подлинности из этой машины.Оно просто требует, чтобы все запросы происходили из зарезервированного internet порта (то есть номер порта должен быть меньше чем 1024). Эта опция определена по умолчанию. secure-rpc - требует secure RPC установления подлинности от этой машины. Это пока еще не осуществленно. См. Sun's документацию по Secure RPC. - 203 - kerberos - требует Kerberos установления подлинности на доступ из этой машины. Это тоже пока еще не осуществленно. См. MIT документацию по Kerberos опознавательной системе. root squash - это особенность защиты, которая отвергает super user на точно установленных хостах любых специальных прав доступа, отображая запросы из uid 0 на клиенте к uid 65534 (-2) на сервер. Этот uid не должен быть связан ни с каким пользователем. no root squash - не делает запросы отображения из uid 0. Эта опция включена по умолчанию. ro - устанавливает значение read-only на файловую архитектуру. Эта опция включена по умолчанию. rw - устанавливает значение rgad-write на файловую архитектуру. link relative - преобразовывает абсолютные символьные связи (где link contents начинается с наклонной черты вправо) в относительные связи вводя необходимое число ../, чтобы добраться из каталога содержащего связь к root на сервере. Эта опция имеет смысл только тогда, когда целая файловая система хоста установлена, или некоторые из связей не могли бы быть нигде, или даже хуже, файлы на которые они никогда не указывали. Эта опция определена по умолчанию. link absolute оставляет вся символьные связи какими они и были (нормальное поведение для Sun-supplied NFS серверов). map identity - map identity опция сообщает серверу, чтобы он принял того клиента, который использует теже самые uid's и gid's как и сервер. Эта - 204 - опция определена по умолчанию. map daemon Эта опция сообщает NFS серверу принять, что клиента и сервер не разделяют то же самое пространство uid/gid. nfsd затем построит список идентичности отбора между клиентом и сервером, запрашивая client's ugidd daemon. Ошибка, анализирующая файл экспорта сообщает daemon syslogd's оборудованию всякий раз, когда nfsd или mountd запущен. Заметьте, что имена хостов получены из IP адреса клиента обратным отбором, так что Вы должны иметь правильно сконфигурированное решающее устройство. Если Вы используете BIND и очень security-conscious, то Вы должны включить spoof проверку в Вашем host.conf файле. 12.5 Linux Automounter Иногда, это расточительно для установки всех NFS значений пользователей, к которым возможно хотят обратиться.; или же из-за острого числа зачений которые должны быть установленны, или из-за времени, которое требовалось бы при запуске. Жизнеспособный вариантдля этого - так называемый automounter. Это - daemon, которая атоматически и понятно устанавливает любое NFS значение как необходимо, и неустанавливает их , если они не были использованны в течении некоторого времени. Одна из умных вещей относительно automounter - то, что возможно установить определенное значение из любых мест. Например, Вы можете сохранить копии Ваших Х программ и файлов поддержки на двух или трех хостах, и все другин хосты устанавленные через NFS. При использовании automounter, Вы можете точно определить всех трех из них, чтобы быть установленными на /usr/X386; automounter затем попробует установить любой из них, пока одна из попыток установки не преуспевает. Automounter, обычно используемый с Linux называется amd. Сначала он был написан Jan-Simon Pendry и был перенесен на Linux Rick Sladkey. Текущая версия amd-5.3. - 205 - Описание amd - вне этой главы; для хорошего описания, пожалуйста, обратитесь к источникам; они содержат файл texinfo с очень подробной информацией. 13. Управление Taylor UUCP 13.1 Хронология UUCP был разработан в конце семидесятых Mike Lesk в AT&T Bell Laboratories, чтобы обеспечить простое соединение по модему. Так как большинство людей, которые хотят иметь email и новости Usenet на своей домашней машине все еще связываются через модемы, UUCP стал очень популярен. Хотя имеется много реализаций, разработанных для различных аппаратных платформ и операционных систем, все они совместимы с высокой степенью. Однако, как это случилось с большинством программного обеспечения, которое так или иначе стало "стандартом" за эти годы, нет такого UUCP, который можно было бы назвать подлинным UUCP. Он подвергался постепенному процессу эволюции начиная с первой версии, которая была разработана в 1976.В настоящее время имеются две основных разновидности, которые отличаются в основном поддержкой аппаратных средств и конфигурацией.Крпме  них существуют различные реализации, немного отличающиеся деталями элементами. Одна разновидность - это так называемая " Версия 2 UUCP ", которая датируется 1977 годом и реализована Mike Lesk, David A. Novitz, и Greg Chesson. Она все еще используется, хотя и устарела. Недавние реализации Версии 2 обеспечивают многие из возможностей более новой разновидности UUCP. Вторая разновидность была разработана в 1983, и обычно упоминается как BNU (Basic Networking Utilities(базисные утилиты работы с сетями)), HoneyDanBer UUCP, или HDB для краткости. Название получено из имен авторов, P. Honeyman, D. A.Novitz, и B. E. Redman. HDB был задуман, чтобы устранить некоторые из неточностей Версии 2 UUCP. Например, были добавлены новые протоколы передачи, и буферный каталог был разбит так, что теперь имеется - 206 - каталог для каждого компьютера, с которым Вы связываетесь через UUCP. Реализация UUCP, в настоящее время распространяемого с Linux - Taylor UUCP 1.04, (1), является версией,которую описывает эта глава. Версия Taylor UUCP 1.04 была выпущена в феврале 1993. Кроме традиционных файлов конфигурации, Taylor UUCP может быть скомпилирована так , чтобы понимать новый стиль - a.k.a. " Taylor " - файлы конфигурации. Версия 1.05 была выпущена недавно, и скоро будет поставляться на большинстве дистрибутивов. Различия между этими версиями обычно затрагивают возможности, которые Вы никогда не будете использовать, так что Вы сможете конфигурировать Taylor UUCP 1.05 используя информацию из этой книги. 1.Написано Ian Taylor, 1993. С большинства дистрибутивов Linux, Taylor UUCP обычно компилируется совместимым с BNU, или Taylor схемой конфигурации, или с обоими. Так как последний намного более гибок, и, возможно, проще для понимания, чем довольно часто запутанные файлы конфигурации BNU, ниже я буду описывать схему Taylor. Цель этой главы не в том, чтобы дать Вао исчерпывающее описание опций командной строки для команд UUCP, а в том, чтобы дать Вам введение в установку работающего узла UUCP. Первый раздел дает введение в то, как UUCP осуществляет удаленное выполнение и передачу файла. Если Вы не новичок в UUCP, Вы можете пропустить этот раздел и перейти к разделу 13.3, который объясняет различные файлы, используемые для установки UUCP. Мы примем, что Вы знакомы с пользовательскими программами набора программ UUCP - uucp и uux. Для описания обратитесь пожалуйста к страницам руководства. Кроме общедоступных программ - uux и uucp, набор программ UUCP содержит ряд команд, используемых только для административных целей. Они используются для контроля траффика UUCP через ваш узел, удаления старых регистрационных файлов, или для компиляции статистики. Они не будут описаны здесь, потому что они периферийные к основным задачам UUCP. Кроме того, они хорошо документированы и довольно легки для понимания. Однако, имеется третий класс, который включает рабочие программы UUCP. Они называются uucico (где cico обозначает copy-in copy-out), и uuxqt, которая выполняет - 207 - работы, посланные из удаленных систем. 13.1.1 Подробная информация о UUCP Если Вы в этой главе не найдете то, что хотите, прочитайте документацию,которая поставляется с пакетом. Это набор texinfo файлов, которые описывают установку с использованием Taylor схемы конфигурации. Texinfo может быть преобразован в DVI и GNU файлы информации, использующим tex и makeinfo, соответственно. Если Вы хотите использовать файлы конфигурации BNU (или даже Версии 2), есть очень хорошая книга - " Управление UUCP и Usenet " ([GETST "reilly-uucp"]). Другой хороший источник информации об UUCP для Linux - Vince Skahan's UUCP-HOWTO , который можно взять на comp.os.linux.announce. Имеется также newsgroup для обсуждения UUCP - comp.mail.uucp. Если у Вас есть специфические вопросы о Taylor UUCP, может быть лучше задать их тжм, чем на группах comp.os.linux. 13.2 Введение 13.2.1 Обзор Передач UUCP и удаленного запуска Ключ к пониманию UUCP - понятие задачи. Каждая передача, которую пользователь инициализирует с помощью uucp или uux, называется задачей. Она состоит из программы,которая будет выполнена на удаленной системе, и набора файлов, которые будут перемещены между системами. Одна из этих частей может отсутствовать. Например,примем, что на вашей ЭВМ Вы выдали следующую команду, которая заставляет UUCP копировать файл netguide.ps на ЭВМ pablo, и выполнить команду lpr, чтобы напечатать файл. # $ Uux -r pablo! Lpr! Netguide.ps UUCP не вызывает удаленную систему немедленно, чтобы выполнить задачу (иначе Вы могли это сделать kermit). Вместо этого он временно сохраняет описание задачи на удаленной системе. Это называется буферизацией задачи. Каталог, в котором сохраняется задача,называется буферным каталогом и - 208 - обычно находится в /var/spool/uucp. В нашем примере, описание задачи содержало бы информацию относительно удаленной команды, которая будет выполнена (lpr), пользователя, который запросил выполнение, и пары других предметов. В дополнение к описанию задачи, UUCP должен сохранить входной файл (netguide.ps). Точное расположение и наименование буферных файлов может изменяться в зависимости от некоторых опций времени компиляции. HDB-совместимые UUCP вообще сохраняют буферные файлы в каталоге, именованном /var/spool/uucp/site, где site - имя удаленной машины. Скомпилированный для Taylor конфигурации, UUCP создаст подкаталоги в /var/spool/uucp/site для различных типов буферных файлов. Через определенные интервалы UUCP связывается с удаленной системой. Когда соединение установлено, UUCP передает файлы, описывающие задачу, плюс все входные файлы. Входящие задачи не будут выполнены немедленно, а только после разрыва уоединения . Это делает программа uuxqt, которая также заботится о пересылке любых задач, если они предназначены для другой машины. Для различия между важными и менее важными задачами, UUCP с каждой задачей связывает уровень приоритета . Это - один знак, в пределах от 0 до 9, от А до Z, и через z, в уменьшающемся старшинстве. Почта обычно записывается в буферный файл с приоритетом B или C, в то время как новости записываются с приоритетом N. Работы с более высоким приоритетом передаются раньше. Приоритеты могут быть назначены используя опцию -g при вызове uucp или uux. Вы можете также запретить передачу задач с приоритетом ниже данного в определенное время. Это также называется максимальным приоритетом буфера, позволяемым в течение диалога ( по умолчанию z). Обратите внимание на терминологическую неоднозначность : файл перемещен только, если он имеет приоритет выше максимального приоритета буфера. 13.2.2 Внутренние работы uucico Чтобы понять, почему uucico должен знать некоторые вещи, приведем быстрое описание того, как фактически происходит соединение с удаленной системой. Когда Вы выполняете uucico -s система из командной строки, сначала происходит физическое соединение.Принимаемые действия зависят от типа открываемого соединения. Например, при использовании телефонной линии, она - 209 - должна найти модем, и набрать номер.Если используется TCP, uucico должна вызвать функцию gethostbyname (3), чтобы преобразовать имя в сетевой адрес, выяснить, какой порт открывать, и связать адрес с соответствующим гнездом(socket). После того, как соединение было установлено, должна выполниться процедура идентификации пользователя. Она состоит из запроса удаленной системой, имени, и, возможно, пароля.Все это называется "login chat". Процедура идентификации выполняется или обычным getty/login набором программ, или - на гнездах TCP - непосредственно uucico . Если разрешение на вход получено, удаленная систзма запускает uucico. Локальная копия uucico, которая инициализировала соединение, назначается главной, удаленная - подчиненной. Затем следует фаза рукопожатия(handshake phase): главный посылает cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли hostname право входить в нее, посылать и принимать файлы, и т.д.. Флаги описывают (кроме всего прочего) максимальный приоритет буферизации передаваемых файлов. Если возможно, счет диалога, или проверка порядкового номера обращения происходит здесь. Благодаря этой возможностью, оба поддерживают счет успешных соединений, которые сравниваются. Если они не соответствуют, рукопожатиe прерывается. Это помогает защищать себя от самозванцев. В заключение, uucico пытаеться установить общий протокол передачи. Этот протокол обеспечивает способ перемещения данных, проверку на непротиворечивость, и повторную передачу в случае ошибки. Имеется потребность в различных протоколах из-за отличающихся типов обеспечиваемых соединений. Например, телефонные линии требуют " безопасный " протокол, который включает в себя жестокую проверку ошибок, в то время как передача TCP по существу надежна и может использовать более эффективный протокол, который предшествует наиболее тщательной проверке ошибок. После того,как рукопожатие устновлено,начинается фактическая фаза передачи . Обе системы включают выбранный драйвер протокола. Драйверы, возможно, выполняют свою специфическую инициализацию. Сначала главная система посылает все файлы, поставленные в очередь для передачи на удаленную систему, приоритет буферизации которых является - 210 - достаточно высоким. Когда передача завершена, она сообщает об этом подчиненной системе, подчиненный может теперь отключиться или принимать диалог. Это - изменение ролей(назначений): теперь удаленная система становится главной, а локальная становится подчиненной. Новый хозяин теперь посылает файлы. Когда передача завершена, обе программы обмениваются заключительными сообщениями, и закрывают соединение. Мы не будем вникать во все детали: пожалуйста обратитесь или к исходным текстам или к любой хорошей книге об UUCP для этого.Есть также действительно старинная статья, касающаяся сети, написанной David A. Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP FAQ также обсуждает некоторые подробности UUCP. Это всегда есть на comp.mail.uucp. 13.2.3 Опции командной строки uucico Этот раздел описывает наиболее важные опции командной строки для uucico. Для полного списка, пожалуйста обратитесь к странице руководства uucico(1). -s системный вызов по имени системы, если нет запрета в соответствии c ограничениями времени обращения. -S системный вызов по имени системы безоговорочно. -r1 запукает uucico в режиме главного. Это опция по умолчанию,когда -s или -S заданы. Опция -r1 заставляет uucico пробовать вызывать все системы в sys", если не запрещено обращение и не настало ограничение времени повторения. -r0 запускает uucico в режиме подчиненного. Это - значение по умолчанию,когда -s или -S не заданы. В непривилегированном режиме, любой стандартный ввод - вывод соединяется с последовательным портом, порт TCP используется если опция -p задана. - 211 - -x typy, -X type Включают отладку заданного типа.Несколько типов могут быть разделены запятой.Следующие типы допустимы: abnormal, chat,handshake,uucp-proto, proto, port, config, spooldir, execute,incoming, outgoing. Использование all включает все опции Для совместимости с другими реализациями UUCP,взамен может быть определен номер, который включает отладку для первых n предметов"из  вышеупомянутого списка. Отладочные сообщения будут регистрироваться в файле DEBUG в /var/spool/uucp. 13.3 Файлы Конфигурации UUCP В отличие от более простых программ передачи файлов, UUCP был разработан, чтобы обрабатывать все передачи автоматически.Если только все установлено правильно, ежедневное вмешательство администратора не необходимо.Вся необходимая информация сохраняется в паре файлов конфигурации, которые постоянно находятся в каталоге /usr/lib/uucp. Большинство этих файлов используется только при запросе снаружи. 13.3.1 Нежное Введение в Taylor UUCP Сказать, что конфигурация UUCP является тяжелой,было бы замалчиванием темы.Это - действительно запутанная тема, и иногда краткий формат файлов конфигурации не делает вещи проще (хотя формат Talyor почти просто читается по сравнению с более старыми форматами в HDB или Версии 2). Что бы дать Вам понять как взаимодействуют все эти файлы, мы представим наиболее важное, и будем иметь просмотр в типовых входах этих файлов. Мы не будем объяснять все подробно; более точные сведения даны в отдельных разделах ниже.Если Вы хотите установить на вашу машину UUCP, лучше всего начать с некоторых типовых файлов, и адаптировать их постепенно.Вы можете выбирать из предложенного ниже,или того,что есть в вашем дистрибутиве Linux. Все файлы,описанные в этом разделе хранятся в /usr/lib/uucp или в его подкаталогах.Некоторые дистрибутивы Linux содержат UUCP binaries, которые поддерживают и HDB и Taylor конфигурации,и используют различные - 212 - подкаталоги для каждого набора файлов конфигурации.Есть обычно README файл в /usr/lib/uucp. Чтобы UUCP работал правильно, эти файлы должны принадлежать собственно пользователю uucp. Некоторые из них содержат пароли и номера телефона, и следовательно должны иметь прва доступа 600. (2) Центральный файл конфигурации UUCP - /usr/lib/uucp/config используется, чтобы установить общие параметры.Наиболее важный из них (и теперь, единственный), является именем UUCP вашей ЭВМ. В Виртуальном Пивоваренном заводе, они используют vstout как их ворота UUCP: # /usr/lib/uucp/config - основной файл конфигурации UUCP hostname vstout Следующий важный файл конфигурации - sys файл.Он содержит всю системно-привязанную информацию об участках сети, с которыми Вы связаны.Она включает имя участка(ЭВМ),и информацию относительно связи непосредственно,типа номера телефона при использовании связи модема.Типичный cценарий (сценарий - коммандный файл - script,далее сценарий) для модемной связи с pablo: # /usr/lib/uucp/sys - имена соседей UUCP #system pablo system pablo time Any phone 123-456 port serial1 speed 38400 chat ogin: vstout ssword: lorca Port задает порт,который нужно использовать,time определяет время в которое система может вызываться.Сhat описывает сценарии входа в систему - последовательность строк,которыми нужно обменяться,чтобы uucico зарегистрировал в pablo.Мы опишем сценарий входа позже.Команда порта не называет конкретный файл устройства типа /dev/cua1,но оба имени входят в файл port.Вы можете назначить любое походящее имя. 2.Обратите внимание, что хотя большинство команд UUCP должно устанавливать setuid для uucp, Вы должны удостовериться, что программа uuchk - нет. Иначе пользователи будут способны посмотреть пароли,даже если они имеют режим 600. - 213 - Файл port содержит информацию о связи непосредственно.Для модемной связи он описывает специальный файл устройства, который нужно использовать, скорость,и тип оборудования, соединенного с портом.Пример ниже описывает /dev/cua1 (a.k.a. COM 2),с которым соединен NakWell модем способный к перздачз на скорости до 38400bps.Имя порта должно соответствовать имени,данному в файле "sys". # /usr/lib/uucp/port - UUCP ports # /dev/cua1 (COM2) port serial1 type modem device /dev/cua1 speed 38400 dialer nakwell Информация,имеющая отношение к программам набора номера cохраняетсяняется в другом файле,называемом dial.Для каждого типа программы набора номера он содержит последовательность команд,которые требуются,чтобы вызвать удаленную машину по номеру телефона.Все это задано как chat script(сценарий дружеской системы).Пример для вышеупомянутого NakWell мог бы выглядеть следующим образом: # /usr/lib/uucp/dial - per-dialer information # NakWell modems dialer nakwell chat "" ATZ OK ATDT\T CONNECT Строка, начинающаяся с chat определяет дружескую беседу модема,которая является последовательностью команд, посланных и полученных от модема, чтобы инициализировать это и делать это,набирают желательный номер."\T" последовательность будет заменен на номер телефона uucico. Чтобы в общем показать Вам, как uucico работает с этими файлами конфигурации, предположим, что Вы дали команду: $ Uucico -s pablo Рисунок 18. Взаимодействие Файлов Конфигурации Taylor UUCP. Первым делом uucico ищет pablo в "sys" файле.Из строки в файле " - 214 - sys" для pablo она видит,что должна использовать serial1 порт для установки соединения.Файл port сообщает ей, что serial1 является портом модема,и что есть подключенный модем NakWell . Uucico теперь ищет набор кода,описывающий NakWell модем,и найдя первый,открывает /dev/cua1 последовательного порта и выполняет "дружескую беседу" программы набора номера.То есть поуылазт "ATZ", ждет "OK " в ответ,и т.д.. При столкновении с строкой "\T", он заменяет номер телефона (123 - 456) извлеченный из системного файла. После того,как соединение было установлено,Uucico возвращается к файлу "sys" и выполняет дружескую беседу входа в систему(login chat).В нашем примере она ждет приглашения "login: " затем послает имя пользователя (neruda), затем ждет приглашения "password:" ,и посылает пароль "lorca". После завершения разрешения, удаленная система активизирует собственный uucico.Они прводят фазу рукопожатия(handshake phase),описанную в предыдущем разделе. Связи и зависимости файлов конфигурации также показаны на рисунке 13.3.1. 13.3.2 Что Должен Знать UUCP Прежде, чем Вы начинаете писать файлы конфигурации UUCP, Вы должны уяснить некоторую необходимую информацию.Сначала Вы будете должны выяснить,к какому последовательному порту присоединен ваш модем.Обычно порты (DOS) COM1 - COM4 отображают на специальные файлы устройств /dev/cua0 - /dev/cua3.Большинство дистрибутивов, напр. Slackware,создают /dev/modem ссылку как связь с соответствующим cua * файлом устройства,и конфигурируют kermit,seyon и т.д. использовать этот обобщенный файл.В этом случае,Вы должны также использовать /dev/modem в вашей конфигурации UUCP. Причина для этого то,что все программы используют так называемые файлы блокировки,чтобы сообщить,когда последовательный порт используется.Имена этих файлов блокировки - конкатенация строки LCK .. и имени файла устройства,например LCK .. cua1.Если программы используют различные имена для одного устройства,они будут быть не в состоянии распознавать чужие файлы блокировки.Как следствие, они прервут чужие сеансы начатые в то же самое время.Это - не маловероятное событие,если Вы планируете чтобы ваш UUCP использовал crontab.Подробности настройки последовательных портов см. в главе 5 .. - 215 - Затем Вы должны выяснить с какой скоростью ваш модем и Linux могут связыввться и установить максимальную эффективную скорость передачи.Эффективная скорость передачи может быть намного выше чем физическая скорость вашего модема. Например, много модемов посылают и получают данные со скоростью 2400bps (биты в секунду).При использовании протоколов сжатия типа V. 42bis,фактическая скорость передачи может достигать 9600bps. Конечно,если вы хотите,чтобы UUCP cделал что-нибудь,Вам для вызова нужен номер телефона системы.Также Вам нужен идентификатор для входа в систему и возможно пароль для удаленной машины. (3) Вы также должны знать,как регистрироваться в системе. Например,Вы должны нажать КЛАВИШУ BREAK прежде, чем подсказка входа в систему появляется? Что отображается: "login:" или "user:"? Это необходимо для создания сценария дружеской беседы(chat script),который описывает uucico, как регистрироваться.Если у Вас возникают затруднения,пробуйте вызывать систему программой терминала подобно kermit или minicom,и записать точно,что Вы делаете. 13.3.3 Наименование Места Как и при работе с TCP/IP сетями,ваша главная ЭВМ(host) должна иметь имя для UUCP сетей. Пока Вы просто хотите использовать UUCP для передач файлов или соединения извне непосредственно,или по локальной сети, это имя не должно удовлетворять никакие стандартам. (4) 3. Если вы собираетесь пробовать UUCP, получите телефонный номер ближайшего архива. Запишите имя и пароль - они общеизвестны. В большинстве случаев они что - нибудь вроде /uucp uucp или nuucp/uucp. 4. Единственое ограничение - то, что имя не должно быть больше чем 7 символов, чтобы не путать ЭВМ с файловыми системами, которые накладывают узкое ограничение на имя файла. Однако, если Вы используете UUCP для почты или новостей, Вы должны подумать о наличиb имени, зарегистрированног в UUCP Mapping project . UUCP Mapping psojectо описан в главе 14 .., Даже если Вы делите домен, Вы можете получить официальное имя UUCP для вашего участка сети. - 216 - Часто, люди выбирают свое UUCP имя, чтобы соответствовать первому компоненту имени домена. Предположим, что адрес домена вашей ЭВМ - swim.twobirds.com, тогда имя главной ЭВМ UUCP было бы swim.Обычно именно так и бывает.Конечно, Вы можете также использовать любое UUCP имя. Однако не стоит использовать неквалифицированное имя в адресе почты, пока Вы не зарегистрировали его как ваше официальное имя UUCP. (5) В лучшем случае, почта на незарегистрированную ЭВМ UUCP отправится в мусорную корзину(big black bit bucket). Если Вы используете имя, уже присвоенное некоторому другому месту, эта почта не будет направлена к тому месту, и причине начальник почтового отделения никакой конец головных болей. По умолчанию, набор программ UUCP использует hostname как имя UUCP . Это имя обычно устанавливается в сценарие /etc/rc.local. Если ваше имя UUCP отлично от того, что Вы устанавливаете главным имя , Вы должны использовать опцию hostname в файле конфигурации, чтобы сообщить uucico о вашем имени UUCP. Это описано ниже. 13.3.4 Taylor Файлы Конфигурации Теперь мы вернемся к файлам конфигурации. Taylor UUCP получает информацию из следующих файлов: config -Это основной файл конфигурации. Вы можете определить ваше имя UUCP здесь. sys - описывает все участки сети, известные Вам. Для каждого участка, он определяет имя, в какое времяе вызывать его, какой номер набрать , какое устройство использовать, и как регистрироваться. port - описывает все доступные порты, вместе с обеспечиваемой скоростью и программами соединения, которые нужно использовать. 5. UUCP Mapping Project регистрирует все UUCP hostnames во всем мире и проверяет их на уникальность. Чтобы зарегистрировать ваше имя UUCP, спросите maintainers ЭВМ, которжя ограбатывает вашу почту; они помогут Вам с этим. - 217 - dial - Описывает программы набора номера, используемые, чтобы установить телефонное соединение. Dialcode Содержит расширения для символического сода набора (dialcodes). call Содержит имя входа в систему и пароль, который нужно использовать при вызове системы. Редко используется. Passwd Содержит имена входа в систему, и системы паролей используемые при регистрации . Этот файл используется только, когда uucico делает собственную проверку пароля. Taylor файлы конфигурации состоят из строк, содержащих пары ключевое слово - значение. Знак мусора представляет комментарий ,действующий до конца строки. Чтобы использовать знак мусора просто так , Вы можете ввести его с наклонной чертой влево( with a backslash). Есть очень много опций, которые Вы можете изменять в этих файлах конфигурации. Мы не можем описать все параметры здесь, и заденем лишь наиболее важные.С их помощью вы сможете сконфигурировать модемную связь UUCP. Дополнительные разделы описывают изменения, необходимые, если Вы хотите использовать UUCP поверх TCP /IP или поверх последовательного соединения. Полная описание дается в Texinfo документах, которые распространяются вместе с исходным текстом Taylor UUCP. Если Вы думаете, что сконфигурировали вашу систему UUCP полностью, можете проверить вашу конфигурацию, используя uuchk (находится в /usr/lib/uucp). Uuchk читает ваши файлы конфигурации, и печатает детализированный отчет о значениях , используемых для каждой системы. 13.3.5 Общие Опции Конфигурации - config