Страница:
сервера. 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.
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.