Address Resolution(поиск по адресу).
Теперь, когда вы видели как создаются IP адреса, Вы можете спросить как же они используются в Ethernet при адресации различных хостов? В конце концов Ethernet протокол опознает хосты по шести байтовому адресу, который не имеет абсолютно ничто общего с IP адресом.
Именно поэтому необходим механизм, переводящий IP адреса в адреса Ethernet. Это так называемый Address Resolution Protocol (Протокол Решения Адреса), или ARP. Фактически, ARP не ограничен Ethernet, он используется и на сетях других типов. Идея, лежащая в основе ARP аналогична способу применяемому большинством людей, когда они хотят найти господина X. Они ходят по толпе и выкрикивают его имя. И если он там, он откликнется.
Когда ARP хочет выяснять Ethernet адрес соответствующий данному IP адрес, он использует особенность Ethernet известную как "broadcast"(широковещательное), когда дэйтаграмы адресовываются одновременно всем станциям в сети. Широковещательная дэйтаграма посланная ARP содержит запрос с IP адресом. Каждый хост сравнивает его с собственным адресом, и если они совпадают, возвращает ARP-ответ на спрашивающий хост. Спрашивающий хост может теперь извлечь Ethernet адрес отправителя из этого ответа.
Конечно Вы могли бы удивиться как хост может знать на котором из миллионов Ethernet во всем мире должен находить желаемый хост, и почему это вообще должен быть Ethernet. Все это называется Routing(маршрутизация), а именно выяснение физического местоположения хоста в сети. Это и будет темой следующей секции.
Давайте пока еще поговорим об ARP. Если хост обнаружил Ethernet адрес, он сохранит его в ARP кэше, чтобы, когда в следующий раз потребуется послать дэйтаграму рассматриваемому хосту, не требовалось тратить время на его поиск. Однако, он не знает сохранить ли эту информацию навсегда; например, на удаленном хосте могут поменять Ethernet карту, так что хранимая информация окажется не верной. Что потребует через некоторое время еще раз полностью повторить описанную процедуру.
Иногда, также необходимо выяснять IP адрес связанный с данным Ethernet адресом. Это случается, когда бездисковая машина хочет загрузится с сервера по сети, что является весьма общей ситуацией для локальных сетей. Бездисковый клиент, однако, не имеет никакой информацию относительно себя кроме Ethernet адреса! Он посылает широковещательное сообщение содержащее просьбу к серверу сообщить ему его IP адрес. Для этого существует другой протокол, называемый Reverse Address Resolution Protocol (Реверсивный ARP), или RARP. А также BOOTP протокол, который служит для определения процедуры загрузки бездисковых клиентов по сети.
Администрирование и Глупые Приемы Почты
Теперь, когда мы обсудили теорию конфигурирования, установки, и тестирования sendmail + IDA, давайте рассмотрим несколько моментов, чтобы изучить вещи, которые случаются обычно в жизни администратора почты. Отдаленные системы иногда ломаются. Ошибка модема или сбой телефонных линий, определения DNS установлены неправильно из-за человеческой ошибки. Сети падают неожиданно. В таких случаях, администраторы почты должны знать, как реагировать быстро, действенно, и безопасно схранить почту, текущую через альтернативные маршруты, пока отдаленные системы или поставщики услуг не могут восстановить нормальные услуги. Остальная часть этой главы предназначена, чтобы обеспечить Вас решениями для наиболее частыми " критическми состояниями электронной почты ".
Aliases
Aliases(специальные возможности) разрешают ряд вещей:
+ Они обеспечивают короткое имя или общеизвестное имя для почты, которая будет адресована к одному или большому количеству людей.
+ Они вызывают программу с сообщением почты как ввод для программы.
+ Они посылают почту в файл.
Все системы требуют aliases для Постмастера. Всегда чрезвычайно важна защита при определении aliases, которые вызывают программы или запись к программам, так как sendmail вообще выполняет setuid-root. Изменения в файле aliases, не воздействуют до команды
# /usr/lib/sendmail -bi
выполняемой, чтобы формировать требуемые dbm таблицы. Это может также быть выполнено, выполняя команду newaliases, обычно из cron.
#--------------------- /usr/local/lib/mail/aliases ------------------ # # demonstrate commonly seen types of aliases # usenet: janet # alias for a person admin: joe,janet # alias for several people newspak-users: :include:/usr/lib/lists/newspak # read recipients from a file changefeed: | /usr/local/lib/gup # alias that invokes a program complaints: /var/log/complaints # alias that writes mail to a file # # The following two aliases must be present to be RFC-compliant. # It is important to have them resolve to 'a person' # who reads mail routinely. # postmaster: root # required entry MAILER-DAEMON: postmaster # required entry # #-------------------------------------------------------------------
Альтернативы
Иногда желательно иметь несколько описаний для входа в одну систему, например, если система может быть достигнута на различных модемных линиях. С Taylor UUCP Вы можете делать это, определив так называемую альтернативу. Альтернативная строка сохраняет все установки из основной , и определяет только те значения, которые должны быть отменены в заданной по умолчанию , или добавиться к ней. Альтернатива - смещение из входа системы строкой, содержащей ключевое слово altgrnave.
Чтобы использовать два номера телефона для pablo, Вы должны изменить sys следующим образом:
system pablo phone 123-456 alternate phone 123-455
При вызове pablo, uucico теперь сначала наберет 123-456, и ,если ничего не получается пробует альтернативу. Альтернативный вход сохраняет все установки из основного входа системы, и изменяет только номер телефона.
Анонимный UUCP
" Зсли Вы хотите обеспечивать анонимный UUCP- доступ к вашей системе, Вы сначала должны саздать специальное имя для него(см. выше). Общей практикой является дать ему имя входа в систему и пароль uucp. Кроме того, Вы должны установить несколько опций защиты для неизвестных систем. Например, Вы можете запретить им из выполнения любых команд на вашей системе. Однако, Вы не можете задать эти параметры в файле sys, потому что команда требует имени системы, которое Вы не знаете. Taylor UUCP решает эту проблему через команду unknown.Команда unknown может использоваться в файле конфигурации, чтобы определить любую команду, которая может обычно появляться во входе системы:
unknown remote-receive ~/incoming unknown remote-send ~/pub unknown max-remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown commands rmail
Это ограничит неизвестные системы разгрузкой файлов из подкаталогов pub и загрузкой файлов в каталоги ниже /var/spool/uucppublic. Следующая строка говорит uucico игнорировать любые запросы из удаленной системы, чтобы включить отладку локально. Последние две строки разрешают неизвестным системам выполнять rmail; но путь команды разрешает uucico искать команду rmail в частном каталоге, с именем anon-bin. Это позволяет Вам обеспечить некоторый специальный rmail, что, например, может передавать всю почту супер-пользователю для исследования. Это разрешает, чтобы анонимные пользователи достигли maintainer системы, но предотвращает в то же самое время отправление любой почты в другие места. Чтобы дать возможность анонимному UUCP, Вы должны определить по крайней мере одно неизвестное утверждение в конфигурации. Иначе uucico отклонит неизвестные системы.
| |
Аппаратные Средства для последовательных линий.
Linux в настоящее время поддерживает разнообразные последовательные платы, которые используют стандарт RS-232. RS-232 в настоящее время наиболее общий стандарт для последовательных коммуникаций в мире PC.
Хотя аппаратные средства handshake необязательны, но очень полезны. Они позволяют любой из двух станций сигнализировать о готовности получить данные или о том, что другая станция должна подождать пока приемник не обработает поступающие данные. Линии используемые для этот названы "Clear to Send" (Чистыми для посылки или CTS) и "Ready to Send"(Готовыми послать или RTS), соответственно, которые, объясняют второе название handshake аппаратных средств, а именно "RTS/CTS".
В PC, интерфейс RS-232 обычно управляется UART чипом, полученным из 16450 чипа, или более новой его версии, NSC 16550A. Некоторые марки ( особенно внутренних модемов оборудованных набором чипов Rockwell) используют другие чипы, которые были запрограммированы, чтобы вести себя так же как 16550-ые.
Главное различие между 16450 и 16550 то, что последний имеют FIFO буфер размером 16 Байт, в то время как первый только 1 байт
Это делает 16450 подходящими для скорости в 9600 Бод, в то время как для больших скоростей требуются чипы совместимые с 16550. Кроме этих чипов, Linux также поддерживает 8250 чип, который был сделан специально для PC-AT.
В стандартной конфигурации, ядро ищет четыре стандартных последовательных платы от COM1 до COM4. Они связываются с устройствами с незначительными номерами от 64 до 67, так как описано выше.
Если Вы хотите отконфигурировать ваши последовательные порты по-другому, Вы должны установить Ted Tso's setserial команду в rc.serial скрипте. Этот скрипт должен вызываться из /etc/rc во время загрузки системы. Он использует setserial чтобы конфигурировать последовательные устройства. Типичный rc.serial скрипт напоминает это:
# /etc/rc.serial - serial line configuration script. # # Do wild interrupt detection /sbin/setserial -W /dev/cua*
# Configure serial devices /sbin/setserial /dev/cua0 auto irq skip test autoconfig /sbin/setserial /dev/cua1 auto irq skip test autoconfig /sbin/setserial /dev/cua2 auto irq skip test autoconfig /sbin/setserial /dev/cua3 auto irq skip test autoconfig
# Display serial device configuration /sbin/setserial -bg /dev/cua*
Пожалуйста обратитесь к документации, которая поставляется вместе с setserial для объяснения параметров.
Если ваша последовательная карта не обнаружена, или setserial -bg команда показывает неправильные установки, Вы должны будете отконфигурировать его явно, используя правильные значения. Пользователи с внутренними модемами оборудованными Rockwell набором чипов как сообщается испытывают эту проблему. Так, например, UART чип называется NSC 16450, в то время как фактически это NSC 16550, Вы должны изменить конфигурационную команду для причиняющего неприятность порта
/sbin/setserial /dev/cua1 auto irq skip test autoconfig uart 16550
Подобные опции существуют и для того чтобы изменить основной адрес, и IRQ COM порта. Пожалуйста обратитесь к man страницам, setserial(8).
Если ваш модем поддерживает аппаратные средства handshake, Вы должны удостовериться, что вы разрешили работу сними. Большинство коммуникационных программ по умолчанию не пытаются этим пользоваться. Вы должны устанавливать его в ручную. Лучше всего это сделать в rc.serial скрипте, используя команду stty:
$ Stty crtscts < /dev/cua1
Чтобы проверить действительно ли используется handshake
$ Stty -a < /dev/cua1
Это команда выдаст Вам состояния всех флагов для данного устройства; флаг показанный с предшествующим минусом как и в -crtscts означает что флаг выключен.
APPENDIX A
Null Кабель Принтера для PLIP
Чтобы сделать Кабель Принтера для использования с PLIP соединением, Вы нуждаетесь в двух соединителях с 25 штырьками (называемых DB-25) и некотором кабеле с 11 проводниками. Кабель должен быть длиной 15 метров. Если Вы рассматриваете коннектор, Вы должны видеть крошечные числа в основе каждого штырька. Для кабеля Принтера, Вы должны соединить следующие штырьки обоих разьемов друг с другом:
+-------------------------------+ |D0 2 15 ERROR | |D1 3 13 SLCT | |D2 4 12 PAPOUT | |D3 5 10 ACK | |D4 6 11 BUSY | |GROUND 25 25 GROUND | |ERROR 15 2 D0 | |SLCT 13 3 D1 | |PAPOUT 12 4 D2 | |ACK 10 5 D3 | |BUSY 11 6 D4 | +-------------------------------+
Все остающиеся штырьки остаются не связанными. Если кабель экранирован, экран должен быть соединен с DB-25 металлической оболочкой на одном конце.
APPENDIX B
Примеры smail Файлов Конфигурации
Этот раздел показывает типовые файлы конфигурации для пункта UUCP в локальной вычислительной сети. Они основаны на типовых файлах, включенных в исходное распределение smail-3.1.28. Хотя я делаю слабую попытку объяснить, как эти файлы работают. Первый показанный файл - файл программ маршрутизации, который описывает набор программ маршрутизации для smail. Когда smail должен послать сообщение к данному адресу, он вручает адрес всем программам маршрутизации по очереди, пока одна из них не найдет соответствие. Соответствие здесь означает что программа маршрутизации находит host адресата в базе данных, буть это файл paths, /etc/hosts, или любой механизм маршрутизации. Входы в smail файлах конфигурации всегда начинаются с уникального имени, идентифицирующего программу маршрутизации, транспорт, или руководитель. Они сопровождаются списком атрибутов, которые определяют поведение. Этот список состоит из набора глобальных атрибутов, типа драйвера, и частных атрибутов, которые понятны только этому специфическому драйверу. Атрибуты отделяются запятыми, в то время как наборы глобальных и частных атрибутов отделяются от друг друга, используя точку с запятой. В smail, Вы можете определять две программы маршрутизации в файле программ маршрутизации, обе из которых используют pathalias драйвер. Этот драйвер ищет hostnames в pathalias базе данных. Он ожидает имя файла в частном атрибуте:
# # pathalias database for intra-domain routing domain paths: driver=pathalias, # look up host in a paths file transport=uux; # if matched, deliver over UUCP file=paths/domain, # file is /usr/lib/smail/paths/domain proto=lsearch, # file is unsorted (linear search) optional, # ignore if the file does not exist required=vbrew.com, # look up only *.vbrew.com hosts # # pathalias database for routing to hosts outside our domain world paths: driver=pathalias, # look up host in a paths file transport=uux; # if matched, deliver over UUCP file=paths/world, # file is /usr/lib/smail/paths/world proto=bsearch, # file is sorted with sort(1) optional, # ignore if the file does not exist -required, # no required domains domain=uucp, # strip ending ".uucp" before searching
Второй атрибут глобальной переменной, данный в каждом из двух входов программ маршрутизации выше определяет транспорт, который должен использоваться, когда программа маршрутизации обрабатывает адрес. В нашем случае, сообщение будет передано используя uux транспорт. Транспорты определены в файле transports, который объяснсется ниже. Вы можете подстраивать, которым транспортом сообщение будет передаваться, если Вы определяете mathod файл вместо атрибута transports. Файлы методов обеспечивают отображение целевого hostnames на transports. Мы не будем иметь дело с ними здесь. Следующий файл программ маршрутизации определяет программы маршрутизации для локальной вычислительной сети, которые сделают запрос библиотеки решающих устройств. На host Internet, однако, Вы хотели бы использовать программу маршрутизации, которая обрабатывает записи MX. Вы должны следовательно разкомментировать альтернативную inet программу маршрутизации, которая использует встроенный драйвер BIND smail. В среде, которая смешивает UUCP и TCP/IP, Вы можете сталкиваться с проблемой, что Вы имеете главные ЭВМ в вашем файле /etc/hosts, с которыми Вы имеете только случайный SLIP или PPP контакт. Обычно, Вы все еще хотели бы посылать любую почту для них по UUCP. Чтобы предотвращать inet драйвер главных ЭВМ от соответствия этих главных ЭВМ, Вы должны поместить их в файл paths/force. Это - другая база данных pathalias-стилей, она проверяется прежде чем smail делает запрос решающего устройства.
# A sample /usr/lib/smail/routers file # # force - force UUCP delivery to certain hosts, even when # they are in our /etc/hosts force: driver=pathalias, # look up host in a paths file transport=uux; # if matched, deliver over UUCP file=paths/force, # file is /usr/lib/smail/paths/force optional, # ignore if the file does not exist proto=lsearch, # file is unsorted (linear search) -required, # no required domains domain=uucp, # strip ending ".uucp" before searching # inet addrs - match domain literals containing literal # IP addresses, such as in janet@[191.72.2.1] inet addrs: driver=gethostbyaddr, # driver to match IP domain literals transport=smtp; # deliver using SMTP over TCP/IP fail if error, # fail if address is malformed check for local, # deliver directly if host is ourself # inet hosts - match hostnames with gethostbyname(3N) # Comment this out if you wish to use the BIND version instead. inet hosts: driver=gethostbyname, # match hosts with the library function transport=smtp; # use default SMTP -required, # no required domains -domain, # no defined domain suffixes -only local domain, # don't restrict to defined domains # inet hosts - alternate version using BIND to access the DNS #inet hosts: # driver=bind, # use built-in BIND driver # transport=smtp; # use TCP/IP SMTP for delivery # # defnames, # use standard domain searching # defer no connect, # try again if the nameserver is down # -local mx okay, # fail (don't pass through) an MX # # to the local host # # pathalias database for intra-domain routing domain paths: driver=pathalias, # look up host in a paths file transport=uux; # if matched, deliver over UUCP file=paths/domain, # file is /usr/lib/smail/paths/domain proto=lsearch, # file is unsorted (linear search) optional, # ignore if the file does not exist required=vbrew.com, # look up only *.vbrew.com hosts # # pathalias database for routing to hosts outside our domain world paths: driver=pathalias, # look up host in a paths file transport=uux; # if matched, deliver over UUCP file=paths/world, # file is /usr/lib/smail/paths/world proto=bsearch, # file is sorted with sort(1) optional, # ignore if the file does not exist -required, # no required domains domain=uucp, # strip ending ".uucp" before searching # smart host - a partically specified smarthost director # If the smart path attribute is not defined in # /usr/lib/smail/config, this router is ignored. # The transport attribute is overridden by the global # smart transport variable smart host: driver=smarthost, # special-case driver transport=uux; # by default deliver over UUCP -path, # use smart path config file variable
Обработка почты для локальных адресов конфигурирована в файле directors. Это сделано точно так же как файл программ маршрутизации, со списком входов, которые определяют руководителя каждой. Руководители не посылают сообщение, они просто выполняют всю переадресацию, которая является возможной, например через aliases, пересылку почты, и т.п.. При поставке почты к локальному адресу, типа janet, smail передает имя usr всем directors по очереди. Если director соответствует, это или определяет транспорт, которым сообщение должно быть передано (например, к mailbox файлу пользователя), или генерирует новый адрес (например, после специальной оценки). Из-за включаемых проблем защиты, directors обычно делает множество проверок того, могут ли файлы которые они используют быть скомпрометированы или нет. Адреса, полученные несколько сомнительным способом (например от world -перезаписываемый файл aliases) помечены как небезопасные. Некоторые транспортные драйверы отвергнут такие адреса, например транспорт, который передает сообщение файлу. Кроме этого, smail также связывает пользователя с каждым адресом. Любая запись или операции чтения выполняется как пользователь. Для получения в, скажем mailbox janet, адрес конечно связан с janet. Другие адреса, типа тех что получены из файла aliases, имеют других пользователей, связанных с ними, например, пользователь nobody. Для подробностей этих возможностей, пожалуйста обратитесь к smail manpage.
# A sample /usr/lib/smail/directors file # aliasinclude - expand ":include:filename" addresses produced # by alias files aliasinclude: driver=aliasinclude, # use this special-case driver nobody; # access file as nobody user if unsecure copysecure, # get permissions from alias director copyowners, # get owners from alias director # forwardinclude - expand ":include:filename" addrs produced # by forward files forwardinclude: driver=forwardinclude, # use this special-case driver nobody; # access file as nobody user if unsecure checkpath, # check path accessibility copysecure, # get perms from forwarding director copyowners, # get owners from forwarding director # aliases - search for alias expansions stored in a database aliases: driver=aliasfile, # general-purpose aliasing director -nobody, # all addresses are associated # with nobody by default anyway sender okay, # don't remove sender from expansions owner=owner-$user; # problems go to an owner address file=/usr/lib/aliases, # default: sendmail compatible modemask=002, # should not be globally writable optional, # ignore if file does not exist proto=lsearch, # unsorted ASCII file # dotforward - expand .forward files in user home directories dotforward: driver=forwardfile, # general-purpose forwarding director owner=real-$user, # problems go to the user's mailbox nobody, # use nobody user, if unsecure sender okay; # sender never removed from expansion file=~/.forward, # .forward file in home directories checkowner, # the user can own this file owners=root, # or root can own the file modemask=002, # it should not be globally writable caution=0-10:uucp:daemon, # don't run things as root or daemons # be extra careful of remotely accessible home directories unsecure="~ftp:~uucp:~nuucp:/tmp:/usr/tmp", # forwardto - expand a "Forward to " line at the top of # the user's mailbox file forwardto: driver=forwardfile, owner=Postmaster, # errors go to Postmaster nobody, # use nobody user, if unsecure sender okay; # don't remove sender from expansion file=/var/spool/mail/${lc:user}, # location of user's mailbox forwardto, # enable "Forward to " check checkowner, # the user can own this file owners=root, # or root can own the file modemask=0002, # under System V, group mail can write caution=0-10:uucp:daemon, # don't run things as root or daemons # user - match users on the # local host with delivery to their mailboxes user: driver=user; # driver to match usernames transport=local, # local transport goes to mailboxes # real user - match usernames when prefixed with the string "real-" real user: driver=user; # driver to match usernames transport=local, # local transport goes to mailboxes prefix="real-", # for example, match real-root # lists - expand mailing lists stored below /usr/lib/smail/lists lists: driver=forwardfile, caution, # flag all addresses with caution nobody, # and then associate the nobody user sender okay, # do NOT remove the sender owner=owner-$user; # the list owner # map the name of the mailing list to lower case file=lists/${lc:user},
После успешно маршрутизации или направления сообщения, smail вручает сообщение транспорту, заданному программой маршрутизации или director, который соответствовал(согласовал) адресу. Эти transports определен в файле transports. Снова, транспорт определен набором глобальных и частных опций. Наиболее важная опция, определенная каждым входом - драйвер, который обрабатывает транспорт, например драйвер трубопровода, который вызывает команду, заданную в cmd атрибуте. Кроме этого, имеется число глобальных атрибутов, которые транспорт может использовать, которые выполняют различные преобразования заголовка сообщения, и возможно тела сообщения.
# A sample /usr/lib/smail/transports file # local - deliver mail to local users local: driver=appendfile, # append message to a file return path, # include a Return-Path: field from, # supply a From envelope line unix from hack, # insert > before From in body local; # use local forms for delivery file=/var/spool/mail/${lc:user}, # location of mailbox files group=mail, # group to own file for System V mode=0660, # group mail can access suffix="\n", # append an extra newline # pipe - deliver mail to shell commands pipe: driver=pipe, # pipe message to another program return path, # include a Return-Path: field from, # supply a From envelope line unix from hack, # insert > before From in body local; # use local forms for delivery cmd="/bin/sh -c $user", # send address to the Bourne Shell parent env, # environment info from parent addr pipe as user, # use user-id associated with address ignore status, # ignore a non-zero exit status ignore write errors, # ignore write errors, i.e., broken pipe umask=0022, # umask for child process -log output, # do not log stdout/stderr # file - deliver mail to files file: driver=appendfile, return path, # include a Return-Path: field from, # supply a From envelope line unix from hack, # insert > before From in body local; # use local forms for delivery file=$user, # file is taken from address append as user, # use user-id associated with address expand user, # expand ~ and $ within address suffix="\n", # append an extra newline mode=0600, # set permissions to 600 # uux - deliver to the rmail program on a remote UUCP site uux: driver=pipe, uucp, # use UUCP-style addressing forms from, # supply a From envelope line max addrs=5, # at most 5 addresses per invocation max chars=200; # at most 200 chars of addresses
cmd="/usr/bin/uux - -r -a$sender -g$grade $host!rmail $(($user)$)", pipe as sender, # have uucp logs contain caller log output, # save error output for bounce messages # defer child errors, # retry if uux returns an error # demand - deliver to a remote rmail program, # polling immediately demand: driver=pipe, uucp, # use UUCP-style addressing forms from, # supply a From envelope line max addrs=5, # at most 5 addresses per invocation max chars=200; # at most 200 chars of addresses cmd="/usr/bin/uux - -a$sender -g$grade $host!rmail $(($user)$)", pipe as sender, # have uucp logs contain caller log output, # save error output for bounce messages # defer child errors, # retry if uux returns an error # hbsmtp - half-baked BSMTP. The output files must # be processed regularly and sent out via UUCP. hbsmtp: driver=appendfile, inet, # use RFC 822-addressing hbsmtp, # batched SMTP w/o HELO and QUIT -max addrs, -max chars; # no limit on number of addresses file="/var/spool/smail/hbsmtp/$host", user=root, # file is owned by root mode=0600, # only read-/writeable by root. # smtp - deliver using SMTP over TCP/IP smtp: driver=tcpsmtp, inet, -max addrs, -max chars; # no limit on number of addresses short timeout=5m, # timeout for short operations long timeout=2h, # timeout for longer SMTP operations service=smtp, # connect to this service port # For internet use: uncomment the below 4 lines # use bind, # resolve MX and multiple A records # defnames, # use standard domain searching # defer no connect, # try again if the nameserver is down # -local mx okay, # fail an MX to the local host
APPENDIX C
Общая Публичная Лицензия GNU
Имеется Общая Лицензия GNU (GPL или copy-left), под которой Linux запатентован. Она не воспроизведена здесь. Большая часть ядра Linux - copyright (C) 1993 Linus Torvalds, и другое программное обеспечение обеспечены авторским правом их авторами. Таким образом, Linux обеспечен авторским правом, однако, Вы можете перераспределять его (копировать) в соответствии с GPL (GNU GENERAL PUBLIC LICENSE).
Глоссарий
Огромная трудность в работе с сетями - помнить все сокращения и термины. Имеется список тех что мы часто использовали в этом руководстве, наряду с коротким объяснением.
ACU Автоматический Модуль Обращения. Модем.
ARP Протокол Разрешающей способности Адреса. Используется чтобы отобразить IP адреса на адреса локальной сети на основе протокола CSMA-CD (Ethernet).
ARPA Агентство Проектов Перспективного исследования, позднее управление перспективных исследований Министерства обороны США. Основатель Internet.
ARPANET Предок сегодняшнего Internet; экспериментальная сеть, финансируемая Агентством Защиты Проектов Перспективного исследования США (управление перспективных исследований Министерства обороны США).
BBS Система BBS. Телефонный вызов по номеру mailbox.
BGP Протокол Ворот Границы. Протокол для обмена информации маршрутизации между автономными системами.
BIND Berkeley Internet Name Domain сервер. Реализация сервера DNS.
BNU Базисные Утилиты Работы с сетями. Это - наиболее общее разнообразие UUCP в настоящее время. Они также известны как HoneyDanBer UUCP. Это имя происходит от имен авторов: P. Honeyman, D.A. Novitz, и B.E. Redman. broadcast network Сеть, которая позволяет одной станции адресовать датаграмму всем другим станциям в сети одновременно.
BSD Berkeley Распределение Программного обеспечения. Разновидность Unix. CCITT (рус. МККТТ) Международная организация телефонных услуг, и т.д. CSLIP Сжатая Последовательная IP Линия. Протокол для обмена IP пакетами по последовательной линии, используя сжатие заголовка большинства датаграмм TCP/IP.
DNS Domain name system.Это - распределенная база данных, используемая в Internet для отображения имен host к адресам IP.
EGP Внешний Протокол Ворот. Протокол для обмена информации маршрутизации между автономными системами.
Ethernet Технически, Ethernet - часть набора стандартов, изложенных ИИЭРом. Аппаратные средства Ethernet используют одиночный фрагмент кабеля, часто кабель соединяет ряд главных ЭВМ, и позволяет скорость передачи до 10Mbps. Протокол Ethernet определяет способ, которым главные ЭВМ могут связываться по этим кабелям.
FQDN Полностью Квалифицированное Имя Области. Hostname с именем области, так, чтобы это был допустимый индекс в базу данных Имен Области.
FTP Протокол Передачи Файлов. Этот протокол одно из самых известных обслуживаний передачи файла.
FYI "Для Вашей Информации." Ряд документов с неофициальной информацией относительно предметов Internet.
GMU Groucho Marx University. Фиктивный Университет, используемый например через эту книгу.
GNU GNU не Unix - этот рекурсивный акроним - имя проекта Свободной Ассоциации Программного обеспечения, чтобы обеспечить когерентный набор инструментальных средств Unix, которые могут использоваться и копироваться бесплатно. Все программное обеспечение GNU покрыто специальным Объявлением об авторском праве, также называемым Общей Публичной Лицензией GNU (GPL), или Copyleft. HoneyDanBer Имя разнообразия UUCP. См. также BNU.
host Вообще, сетевой узел: кое-что, что является способным получать и передавать сетевые сообщения. Это будет обычно Компьютер, но Вы можете также думать о x-терминалах, или интеллектуальных принтерах.
ICMP Internet Протокол Управляющих Сообщений. Протокол работы с сетями, используемый IP, чтобы возвратить информацию ошибки host посылки, и т.д.
IEEE Institute of Electrical and Eletronics Engineers.Другая организация стандартов. С точки зрения пользователя UNIX, их наиболее важное достижение - POSIX стандарты, которые определяют аспекты систем UNIX, в пределах от интерфейсов системного вызова и семантики к инструментальным средствам администрации.
IETF Internet Силы Проектироваия Задач.
internet Компьютерная сеть, сформированная из коллекции индивидуальных меньших сетей.
Internet Специфический "мировой" internet.
IP Internet Protocol. Протокол работы с сетями.
ISO Организация Международных эталонов.
ISDN Интегрированные Услуги Цифровой Сети. Новая технология передачи данных, использующая цифровую вместо аналоговой схемы.
LAN Локальная вычислительная сеть. Малая компьютерная сеть.
MX Экспреобразователь Почты. Тип записи ресурса DNS, используемый для маркировки host как gateway почты для области.
NFS Сетевая Файловая система. Стандартный протокол работы с сетями и набор программного обеспечения для доступа к данным относительно отдаленных дисков очевидно.
NIS Сетевая Информационная Система. Rpc-основанное приложение, которое позволяет совместно использовать файлы конфигурации типа файла паролей между отдельными главными ЭВМ. См. также вход YP.
NNTP Сетевой Протокол передачи Новостей. Используется чтобы передать новости по TCP сетевым соединениям. octet На Internet, технический термин, касается количества восьми битов. Используется этот термин а не байт, потому что имелись машины на Internet, которые имеют байт, по величине отличный от восьми битов.
OSI Соединение Открытых систем. Стандарт ISO на сетевом программном обеспечении. path Часто используется в сетях UUCP как синоним для маршрута.
PLIP Параллельная IP Линия. Протокол для обмена IP пакетами по параллельной линии типа порта принтера.
PPP Двухточечный протокол (из точки в точку). PPP - гибкий и быстрый протокол связи, чтобы посылать различные сетевые протоколы типа IP или IPX по двухточечному соединению. Кроме использования на последовательных связях (модем), PPP может также быть использован как протокол связи на ISDN.
RARP Обратный Протокол Разрешающей способности Адреса. Он разрешает главным ЭВМ выяснять их адрес IP при начальной загрузке.
RFC Просьба о Комментариях. Ряд документов, описывающих стандарты Internet.
RIP Направляющий Информационный Протокол. Это - протокол маршрутизации, используемый для динамической коррекции маршрутов внутри (малой) сети.
RPC Дистанционное управление вызовом. Протокол для выполнения процедур внутри процесса на отдаленном host.
RR Сокращение для "запись ресурса".
RS-232 Это - очень общий стандарт для последовательных интерфейсов.
RTS/CTS Разговорное название для аппаратного контакта, выполняемого двумя устройствами, сообщающимися (поддерживающими связь) по RS-232. Имя происходит от двух сокращений RTS (" Готов Послать ''), и CTS (" Чист, чтобы Послать '').
RTM Internet Worm Вирусо-подобная программа, которая использовала отдельные дефекты в VMS и BSD 4.3 Unix, чтобы распространиться через Internet. Несколько "ошибок" в программе заставили ее размножаться безпредельно, и вызвали падение больших частей Internet. RTM - инициалы автора (Robert T. Morris), которые он оставил в программе.
SLIP Последовательная IP Линия. Это - протокол для обмена IP пакетами по последовательной линии, см. также CSLIP.
SMTP Простой Протокол передачи Почты. Используется для транспорта почты по TCP соединениям, и также для транспортировки пакетов по связям
UUCP (batched SMTP).
SOA Начало Полномочий. Тип записи ресурса DNS.
System V Разновидность Unix.
TCP Протокол Управления Передачей. Протокол работы с сетями.
TCP/IP Общее описание набора программ протокола Internet в целом.
UDP Протокол Датаграмм Пользователя. Протокол работы с сетями.
UUCP Копирование из Unix в Unix. Набор программ сетевых транспортных команд для сетей телефонных вызовов по номеру.
virtual beer Виртуальное пиво любимый спиртной напиток Каждого Linux'ера. Первое упоминание о виртуальном пиве, которое я помню, было в примечании выпуска Linux 0.98.X kernel, где Linus упоминал "Oxford Beer Trolls" в его разделе кредитов для посылки некоторого виртуального пива.
YP Желтые Страницы. Более старое имя для NIS, которое больше не используется, потому что Желтые Страницы - марка изготовителя Британской Телесвязи. Однако, большинство NIS утилит сохранило имена с префиксом yp.
Кто сказал что герои сетей останутся невоспетыми ?!
|
Автоматическое определение Ethernet
Во время загрузки, Linux попробует найти вашу плату и определить ее тип. Карты ищутся по следующим адресам и в следующем порядке:
------------------------------------------------------ +--------------+-------------------------------------+ |карта | адреса поиска | +--------------+-------------------------------------+ |WD/SMC | 0x300, 0x280, 0x380, 0x240 | |SMC 16 Ultra | 0x300, 0x280 | |3c501 | 0x280 | |3c503 | 0x300, 0x310, 0x330, 0x350, 0x250, | | | 0x280, 0x2a0, 0x2e0 | |NEx000 | 0x300, 0x280, 0x320, 0x340, 0x360 | |HP | 0x300, 0x320, 0x340, 0x280, 0x2C0, | | | 0x200, 0x240 | |DEPCA | 0x300, 0x320, 0x340, 0x360 | +--------------+-------------------------------------+ +--------------+-------------------------------------+
Имеются два ограничения autoprobing. Во первых, он может не распознавать все платы должным образом. Это особенно касается некоторых из дешевых клонов известных плат, а также для некоторых WD80x3 плат. Вторая проблема состoит в том, что ядро находит не больше одной платы. Если Вы используете больше чем одну плату, или если autoprobe не в состоянии обнаружить вашу плату, Вы должны явно сообщить ядру основной адреса карты и имя.
В Net-3, для этого Вы может использовать две различных схемы Один путь состoит в том, чтобы изменить или добавить информацию в файл drivers/net/Space.c в исходном коде ядра, который содержит всю информацию относительно драйверов. Это рекомендуются только, если Вы знакомы с сетевым кодом. Лучший путь состoит в том, чтобы обеспечить ядро этой информацией при загрузке. Если Вы используете lilo для загрузки вашей системы, Вы можете передавать параметры ядру, определяя их через опцию в lilo.conf. Чтобы сообщить ядру о Ethernet устройстве, Вы можете передавать следующий параметр:
ether=irq,base addr,param1,param2,name
Первые четыре параметра числовые, в то время как последний - имя устройства. Все числовые значения необязательные; если они опущены или равны нолю, ядро будет пробовать само обнаружить эти значения или использует значение установленное по умолчанию.
Первый параметр устанавливает IRQ для устройства. Если он не указан, ядро будет пробовать обнаружить IRQ канал само. 3c503 драйвер имеет специальную особенность, которая позволяет ему выбирать свободный IRQ (из 5, 9, 3, 4) и конфигурировать плату для использования этой линии.
addr параметр задает основной адрес ввода-вывода платы; значение ноль сообщает ядру исследовать адреса внесенные в следующий список.
Следующие два параметра могут использоваться по-разному различными драйверами. Для плат с разделяемой памятью типа WD80x3, они определяют начальный и конечный адреса разделенной области памяти. Другие карты обычно используют param1 чтобы устанавливать уровень отладочной информации. От 1 до 7 обозначают увеличивающиеся уровни подробности, в то время как 8 выключает их; 0 обозначает значение установленное по умолчанию. 3c503 драйвер использует param2 чтобы выбрать внутренний transceiver (установленный по умолчанию) или внешний transceiver ( значение 1). Первый использует BNC; последний -- AUI порт.
Если Вы имеете две Ethernet платы, Вы можете одну плату определять автоматически, а параметры второй платы с помощью lilo. Однако, Вы должны удостоверился, что драйвер случайно не находит вторую плату, в то время как первая не будет регистрироваться вообще. Это можно сделать, указывая в lilo избегать исследовать пространство ввода-вывода занятое второй платой.
Например, прося Linux установить вторую Ethernet плату в 0x300 как eth1, Вы бы передали следующие параметры к ядру:
Reserve=0x300,32 ether=0,0x300, eth1
reserve опция требует чтобы никакие драйверы не трогали при исследование пространство ввода-вывода некоторого устройства. Вы можете также использовать параметры ядра для управления авто поиском:
Reserve=0x340,32 ether=0,0x340, eth0
Чтобы выключить autoprobing вообще, Вы можете определить addr в -1:
Ether=0,-1, eth0
База данных DNS
Мы видели, что DNS имеет дело не только с IP адресами хостов, но также обменивается информацией относительно серверов имен. В DNS базе данных фактически имеется целая куча различных типов записей.
Единица информации в DNS базе данных названа resource record (записью ресурса), или RR. Каждая запись имеет определенный тип, описывающий тип данных, которые в ней записаны, и определяющий тип сети, к которой она применяется. Последний используется при определении схемы адресования, типа IP адресов (IN класс), или адресов в Hesiod сетях (используемые в MIT), и др. Основной записью ресурсов является запись, которая связывает полное имя области с IP адресом.
Конечно, хост может иметь больше чем одно имя. Однако, одно из этих имен должно быть определенно как официальное, или каноническое имя хоста, в то время как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А записью, в то время как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.
Мы не будем приводить здесь все типы записей, а сделаем это позже, в другой главе, здесь же ограничимся кратким примером. Картинка 3.6.5 показывает часть базы данных области которая загружена на сервере имен для зоны physics.groucho.edu.
Кроме A и CNAME записи, Вы можете видеть специальную, занимающую несколько строк, запись сверху файла. Это - SOA запись ресурса, расшифровывается Start of Authority (Начало Власти), которая содержит общую информацию относительно зоны, для которой этот сервер является авторитарным. Она включает, например, время жизни для всех записей.
Обратите Внимание что все имена в файле с примером, которые не заканчиваются точкой интерпретируются относительно groucho.edu области. Специальное имя "@", используемое в SOA записи при обращении к имени данной области.
Мы видели, что сервера имен для groucho.edu области так или иначе должен знать хоть что-то относительно зоны физиков так, чтобы направлять запросы серверам имен. Это обычно достигается парой записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP адресом. Так как эти записи появляются вместе, они часто называются склеенными записями. Это -- фактически единственный случаи записи, в которой родительская зона держит информацию относительно хостов в зоне подчиненного. Склеенные записи указывающие на сервера имен для physics.groucho.edu показаны на рисунке 3.6.5.
; ; Authoritative Information on physics.groucho.edu @ IN SOA { niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 1034 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl } ; ; Name servers IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23 ; ; Theoretical Physics (subnet 12) niels IN A 149.76.12.1 IN A 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 ... ; Collider Lab. (subnet 14) boson IN A 149.76.14.1
muon IN A 149.76.14.7 bogon IN A 149.76.14.12 ...
Картинка 5. фрагмент файла amed.hosts для Отдела Физики.
База данных путей
Smail ожидает находить pathalias базу данных в файле путей в /usr/lib/smail. Этот файл необязателен, так если Вы не хотите выполнять любой pathalias вообще, просто удалите любой существующий файл путей. Paths должен быть сортируемый файл ASCII, который содержит входы, которые отображают имена пункта адресата UUCP. Файл должен сортироваться, потому что smail использует двоичный поиск пункта. Комментарии не позволяются в этом файле, и имя пункта должно отделиться от пути, используя МЕТКУ ТАБУЛЯЦИИ. Pathalias базы данных обсуждены подробнее в главе 14 .. Если Вы генерируете этот файл вручную, Вы должен удостовериться, чтобы включить все допустимые имена для пункта. Например, если пункт известен и простым именем UUCP и полностью квалифицированным именем области, Вы должны добавить вход для каждого из них. Файл может сортироваться конвейерной пересылкой его через команду sort. Если ваш пункт является только пунктом листа, то никакой файл paths, не должен быть необходим вообще: только установите атрибуты smart host в вашем файле конфигурации, и оставьте всю маршрутизацию вашей подаче почты.
Безопасность системы
Другой очень важный аспект администрирования системы в сети -- защита системы и пользователей от злоумышленников, которые могут вредить вам не только фальшивыми сообщениями, но и стиранием данных или нарушения секретности ваших пользователей. Мы будем yпоминать некоторые специфические проблемы при обсуждении случаев, когда они могут происходить, и предложим несколько общих способов защиты.
Здесь мы будет обсуждать несколько примеров и основных методов обеспечения безопасности системы. Конечно, охваченные темы не могут решить всех проблем безопасности, с которыми вы столкнетесь; они просто служат иллюстрацией проблем, которые могут возникнуть. Поэтому, необходимо прочитать хорошую книгу по безопасности, особенно администратору сетевой системы. Simon Garfinkel "Практическая UNIX Безопасность" ( см. [ GETST "безопасность"]) -- очень рекомендую.
Безопасность системы начинается с хорошего администрирования системы. Это включает в себя проверку собственности и разрешений всех жизненено важных файлов и каталогов, контроль использования привилигерованных прав, и т.д.. COPS программа, например, будет проверять вашу файловую систему и общие файлы конфигурации на необычных разрешения и другие аномалии. Также следует ввести определенные правила по созданию пользовательских паролей, которые позволяли бы уменьшить вероятность их подбора. Например, потребовать чтобы пароль имел по крайней мере пять букв, и содержал как верхние так и низкие регистры и цифры.
При создании сервиса доступного по сети, постарайтесь дать ему "наименьшие привилегии," удастовертесь что Вы не разрешаете ему делать вещи, которые не требуются для его работы. Например, Вы должны делать программы с привилегии root только, когда они действительно нуждаются в этом. Например, если Вы хотите разрешить бездисковым хостам загружаться от вашей машины, Вы должны обеспечить TFTP (тривиальный сервис передачи файла) так, чтобы они загружали основные файлы конфигурации из дириктории /boot. Однако, когда используется неограниченный TFTP, это позволяет любому прочитать общедоступные файлы с вашей машины. Если это не то, что Вы хотите, почему бы не ограничить TFTP сервис дирикторией /boot?
По той же самой причине, Вы могли бы захотеть ограничить доступ к определенным услугам пользователям с определенных хостов. В главе 10., мы представляем tcpd, который делает это для разнообразных сетевых приложений.
Другой важный пункт -- избегайте "опасного" программного обеспечения. Конечно, любое программное обеспечение, которое Вы используете может быть опасно, потому что программное обеспечение может иметь ошибки, так что умные люди могли бы использовать их чтобы получить доступ к вашей системе. Подобные вещи случаются и нет никакой полной защиты против этого. Эта проблема касается как бесплатного, так и коммерческого программного обеспечения. Однако, программы, которые требуют специальных привилегий несоизмеримо опаснее чем другие, потому что любая лазейка может иметь непоправимые последствия. Если Вы устанавливаете сетевую программу будте вдвойне осторожны и ничего не пропускаете в документации, чтобы случайно не нарушить безопасность системы. Вы не можете исключить того, что ваши предосторожности могут потерпеть неудачу, независимо от того насколько осторожный Вы были. Поэтому Вы должны удостовериться, что Вы обнаружите злоумышленников сразу же после их появления. Хорошее начало -- проверка log файлов системы, но злоумышленник вероятно умный человек, и будет удалять любые очевидные следы перед уходом. Однако, имеются инструменты подобно tripwire, которые позволяют Вам проверять жизненно важные системные файлы и регистрировать были ли их содержание или разрешения изменены. Tripwire вычисляет различные сильные контрольные суммы по этим файлам и хранит их в базе данных. Потом контрольные суммы повторно вычисляются и сравниваются с сохраненными для обнаружения любых модификации.
Библиотека гнезд(socket)
В Unixоидных операционных системах программное обеспечение, выполняющее все задачи и протоколы описанные выше, обычно является частью ядра, аналогично и в Linux. Интерфейс программирования наиболее общий для мира Unix - Библиотека Гнезд Berkeley. Свое название она получила из-за популярной аналогии которая рассматривает порты как гнезда(розетки). Она обеспечивает (bind(2)) запрос, который определяет отдаленный хост, транспортный протокол, и сервис, к которому программа может присоединится или слушать (используя connect(2), listen(2), and accept(2)).
Библиотека гнезд однако несколько более общая, она обеспечивает не только класс TCP/IPоснованных гнезд (AF INET гнезда), но также класс, который управляется локальной связью машины (AF UNIX класс). Некоторые версии могут также управляться другими классами типа XNS ( Система Организации Сети Ксерокса ) протокол, или X.25.
В Linux, библиотека гнезд -- часть стандартной libc C библиотеки. В настоящее время, она поддерживает только AF INET и AF UNIX гнезда, но ведется работа над включением поддержки для Novell протоколов, так, чтобы в конечном счете один или больше классов гнезд для него были бы добавлены.
Библиотека решающих устройств.
Когда мы говорим о " решающем устройстве ", то мы не подрузамеваем никакого специального применения, поэтому достаточно обратится к библиотеке решающих устройств - системе функций, которая может быть найдена в стандарной библиотеке C. Центральные программы являются gethostbyname(2) и gethostbyaddr(2), которые ищут все IP адреса принадлежащие хосту, и наоборот. Они могут быть сконфигурированы при простом просмотре информации в хосте, при запросе ряда серверов, или при использовании баз данных хоста NIS(а) (Network Information Service). Другое применение, подобно smail, может включать различные драйверы для любого из вышеперечисленного, и нуждается в особой осторожности.
Благодарности
Olaf благодарит всех людей, которые профессионально прочитали эту книгу, и потратили свое время на исправление ошибок как грамматических так и технических. Наиболее энергичный среди них был Andy Oram.
Я очень признателен Andres Seplveda, Wolfgang Michaelis, Michael K. Johnson, и всем разработчикам кто потратил свое время чтобы проверить информацию, находящуюся в данном Руководстве. Я также хочу поблагодарить всех тех кто читал первую версию Руководства за посланные меня исправления и предложения. Вы можете найти полный список помощников в файле Thanks. И Наконец, эта книга не появилась бы без поддержки Holger Grothe.
Я также хотел бы поблагодарить следующие группы и компании, которые напечатали первое издание Руководства и пожертвовали деньги или мне, или LDP в целом.
+ Linux Бригада Поддержки, Erlangen, Германия
+ S.u. S.E. GmbH, Fuerth, Германия
+ Linux Лаборатории Системы, Компания, Соединенные Штаты
Vince благодарит Neil Rickert и Paul Pomes за большую помощь во время работы с sendmail+IDA и Rich Braun за перевод sendmail+IDA на Linux. Самая большая благодарность моей жене Susan за всю поддержку в этом и других проектах.
Будте бдителны - проверки последовательности обращения
Другой способ отражать и обнаружить самозванцев состоит в том, чтобы использовать проверки последовательности обращения. Вызовите проверки последовательности, помогают Вам защитить против "злоумышленников ", которые так или иначе сумели выяснять пароль, с которым Вы регистрируете в вашу систему UUCP. При использовании проверок последовательности обращения, обе машины следят за числом соединений, уже установленных . Оно увеличивается с каждым соединением. После регистрации, вызывающий посылает порядковый номер обращения, а вызываемый сверяет его со своим. Если они не соответствуют, попытка соединения будет отклонена. Если начальный номер выбирать произвольно, нападавшим будет нелегко угадать правильный порядковый номер обращения. Но проверки последовательности обращения делают для Вас еще больше: даже если некоторыq очень умный человек обнарузит ваш порядковый номер обращения также как ваш пароль, Вы pfvtnbnt это извне. Когда нападавший вызывает вашу подачу UUCP, и захватывает вашу почту, это увеличит порядковый номер обращения корма на один. В следующий раз Вы вызываете вашу подачу и пробуете регистрировать в, удаленный uucico откажется от Вас, потому что числа не соответствуют(согласовывают) anymore! Если Вы допустили проверки последовательности обращения, Вы должны регулярно проверять ваши регистрационные файлы на сообщения об ошибках, которые намекают на возможные причины. Если ваша система отклоняет порядковый номер обращения, система вызова предлагает, это, uucico поместит сообщение в регистрационный файл, говорящий что - нибудь вроде " Вне обращения последовательности, отклонил ''. Если ваша система не допущуна, потому что порядковые номера находятся вне синхронизации, в регистрационном файле будет примерно следующее " рукопожатие потерпело неудачу (RBADSEQ) ''. Чтобы включить проверку последовательности обращения, Вы должны добавить следующую команду к входу системы:
# enable call sequence checks sequence true
Еще Вы должны создать файл, содержащий порядковый номер. Taylor UUCP хранит порядковый номер в файле, называемом ".Sequence" в каталоге spool удаленной системы. Он должен принадлежать uucp, и иметь режим 600 (то есть чтение и запись разрешены только uucp). Самое лучшее инициализировать этот файл произвольным, согласованным начальным значением. Иначе нападающий может подобрать номер, пробуя все значения меньше, скажем, 60. # cd /var/spool/uucp/pablo # echo 94316 > .Sequence # chmod 600 .Sequence # chown uucp.uucp .Sequence
Конечно, удаленная система должна дать возможность проверкам последовательности обращения также, и использовать то же самое начальное значение, что и Вы.
Будущее
Linux все еще развивается. Главные изменения в ядре принесет очень гибкую схему конфигурации, которая позволит Вам конфигурировать сетевые устройства во время работы. Например, команда ifconfig будет работать с аргументами, которые устанавливают IRQ линию и DMA канал.
Другое изменение -- дополнительный mtu флаг для команды route, которая будет устанавливать Максимальный размер пакета для определенного маршрута. Этот маршруто-определенный MTU заменит MTU для интерфейса. Вы будете использовать эту опцию для маршрутов через gateway, где связь между gateway и хостом места назначения требует очень низкого MTU. Например, предположите что хост wanderer связан с vlager через SLIP связь. При посылке данных от vstout до wanderer, сетевой уровень на wanderer использовал бы пакеты до 1500 байтов, потому что пакеты посылаются через Ethernet. SLIP связь, с другой стороны, используется с MTU 296, так что сетевой уровень на vlager был бы должен разбивать IP пакеты на меньшие фрагменты, которые вписываются в 296 байтов. Если вместо этого, Вы конфигурировали бы маршрут на vstout так, чтобы сразу использовать MTU 296, этого относительно долгого разбиения можно избежать:
# route add wanderer gw vlager mtu 296
Обратите Внимание что mtu опция также позволяет Вам выборочно отменить результаты "Подсети Локальны" политики (SNARL). Эта политика -- это опция конфигурации ядра и описана в главе 4.
C News в NFS Среде
Простой способ распределять новости внутри локальной сети состоит в том, чтобы хранить все новости на центральном host, и экспортировать релевантные каталоги через NFS, так, чтобы newsreader мог просматривать статьи непосредственно. Преимущество этого метода над NNTP - то, что непроизводительные затраты, заключаемые в поиске и продевании нитки статей являются значительно ниже. NNTP, с другой стороны, побеждает в разнородной сети, где оборудование изменяется широко среди главных ЭВМ, или где пользователи не имеют эквивалентных прав на машине сервера. При использовании NFS, статьи, зарегистрированные на локальном host должны быть посланы к центральной машине. Также, Вы могли бы хотеть защищать вашу область spool новостей, экспортируя их только для чтения, что требует пересылки к центральной машине, также. C News обрабатывает это очевидно. Когда Вы отправляете по почте статью, ваш newsreader обычно вызывает inews, чтобы ввести статью в систему новостей. Эта команда выполняет ряд проверок на статье, завершает заголовок, и проверяет файловый сервер в /usr/lib/news. Если этот файл существует и содержит hostname отличный от имени локального host, inews вызывается на тот host сервер через rsh. Так как inews команда использует ряд двоичных команд и файлов поддержки от C News, Вы должны также иметь C News, установленный локально, или устанавливать программное обеспечение новостей из сервера. Чтобы rsh вызов работал правильно, каждый пользователь должен иметь эквивалентный вход на систему сервера, то есть вход котороый она может регистрировать без запроса о пароле. Удостоверитесь, что hostname, данный в сервере буквально соответствует выводу команды hostname (1) на машине сервера, иначе C News будет зацикливаться навсегда при попытке получить статью.
"C" Новости
Один из наиболее популярных пакетов программ для Netnews - Новости C. Это было разработано для абонентов, которые несут новости по связям UUCP. Эта глава обсудит центральные понятия Новостей C, и базисной установки и задач сопровождения. Новости C (C News) сохраняют файлы конфигурации в /usr/lib/news, а большинство binaries в каталоге /usr/lib/news/bin. Статьи сохраняются ниже /var/spool/news. Вы должны удостовериться виртуально что все файлы в этих каталогах принадлежат новостям пользователя, групповым новостям. Большинство проблем является результатом файлов, являющихся недоступным для Новостей C. Сделайте это правилом для Вас, определить новостями пользователя, используя su прежде, чем Вы что - нибудь там измените. Единственые исключения - setnewsids, которые используются, чтобы установить реальный id пользователя некоторых программ новостей. Это должно принадлежать root и должно иметь setuid набор битов. Далее мы описываем все файлы конфигурации C News подробно, и показываем Вам, что Вы должны делать, чтобы сохранить ваш пункт в рабочем состоянии.
Checkgroups Сообщение
Checkgroups сообщения посылаются администраторами новостей, чтобы для всех абонентов внутри сети синхронизировать их файлы active с фактами Usenet. Например, коммерческие поставщики услуг Internet могли бы выпускать такое сообщение к абоненту их заказчиков. Один раз в месяц "оффициальное" checkgroups сообщение для главных иерархий зарегистрировано в comp.announce.newgroups их регулятором. Однако, оно зарегистрировано, как обычная статья, а не как управляющее сообщение. Чтобы выполнить операцию checkgroups, сохраните эту статью в файл, скажем /tmp/check, удалите все до начала сообщения управления непосредственно, и передайте это к checkgroups команде, используя следующую команду:
# su news -c "/usr/lib/news/bin/ctl/checkgroups" < /tmp/check
Это модифицирует ваш newsgroups файл, добавляя группы, перечисленные в localgroups. Старый newsgroups файл будет перемещаться в newsgroups.bac. Обратите внимание, что регистрация сообщения локально редко будет работать, потому что inews отказывается принимать это как статью. Если C News находит несоответствия между списком checkgroups и файлом active, это произведет список команд, которые модернизируют ваш пункт, и сообщат это администратору новостей. Вывод обычно походит на это:
From news Sun Jan 30 16:18:11 1994 Date: Sun, 30 Jan 94 16:18 MET From: news (News Subsystem) To: usenet Subject: Problems with your active file
Следующие newsgroups не допустимы и должны быть удалены.
alt.ascii-art bionet.molbio.gene-org comp.windows.x.intrisics de.answers
Вы можете делать это, выполняя команды:
/usr/lib/news/bin/maint/delgroup alt.ascii-art /usr/lib/news/bin/maint/delgroup bionet.molbio.gene-org /usr/lib/news/bin/maint/delgroup comp.windows.x.intrisics /usr/lib/news/bin/maint/delgroup de.answers
Следующие newsgroups отсутствовали.
comp.binaries.cbm comp.databases.rdb comp.os.geos comp.os.qnx comp.unix.user-friendly misc.legal.moderated news.newsites soc.culture.scientists talk.politics.crypto talk.politics.tibet
Когда Вы получаете такое сообщение от вашей системы новостей, не отбрасывайте его вслепую. В зависимости от того, кто послал checkgroups сообщение, оно может испытывать недостаток нескольких групп или даже всех иерархий; так что Вы должны быть осторожны относительно удаления любых групп. Если Вы находите группы, перечисленные как отсутствующие и Вы хотите иметь их в вашем пункте, Вы должны добавить их, используя addgroup команду. Сохраните список отсутствующих групп в файле и передайте его следующей небольшой команде:
#!/bin/sh cd /usr/lib/news
while read group; do if grep -si "^$group[[:space:]].*moderated" newsgroup; then mod=m else mod=y fi /usr/lib/news/bin/maint/addgroup $group $mod done
Что Должен Знать UUCP
Прежде, чем Вы начинаете писать файлы конфигурации UUCP, Вы должны уяснить некоторую необходимую информацию.Сначала Вы будете должны выяснить,к какому последовательному порту присоединен ваш модем.Обычно порты (DOS) COM1 - COM4 отображают на специальные файлы устройств /dev/cua0 - /dev/cua3.Большинство дистрибутивов, напр. Slackware,создают /dev/modem ссылку как связь с соответствующим cua * файлом устройства,и конфигурируют kermit,seyon и т.д. использовать этот обобщенный файл.В этом случае,Вы должны также использовать /dev/modem в вашей конфигурации UUCP. Причина для этого то,что все программы используют так называемые файлы блокировки,чтобы сообщить,когда последовательный порт используется.Имена этих файлов блокировки - конкатенация строки LCK .. и имени файла устройства,например LCK .. cua1.Если программы используют различные имена для одного устройства,они будут быть не в состоянии распознавать чужие файлы блокировки.Как следствие, они прервут чужие сеансы начатые в то же самое время.Это - не маловероятное событие,если Вы планируете чтобы ваш UUCP использовал crontab.Подробности настройки последовательных портов см. в главе 5 .. Затем Вы должны выяснить с какой скоростью ваш модем и Linux могут связыввться и установить максимальную эффективную скорость передачи.Эффективная скорость передачи может быть намного выше чем физическая скорость вашего модема. Например, много модемов посылают и получают данные со скоростью 2400bps (биты в секунду).При использовании протоколов сжатия типа V. 42bis,фактическая скорость передачи может достигать 9600bps. Конечно,если вы хотите,чтобы UUCP cделал что-нибудь,Вам для вызова нужен номер телефона системы.Также Вам нужен идентификатор для входа в систему и возможно пароль для удаленной машины. (3) Вы также должны знать,как регистрироваться в системе. Например,Вы должны нажать КЛАВИШУ BREAK прежде, чем подсказка входа в систему появляется? Что отображается: "login:" или "user:"? Это необходимо для создания сценария дружеской беседы(chat script),который описывает uucico, как регистрироваться.Если у Вас возникают затруднения,пробуйте вызывать систему программой терминала подобно kermit или minicom,и записать точно,что Вы делаете.
Что является Usenet, Во всяком случае?
Одно из наиболее поразительных предложений относительно Usenet - то, что это не часть любой организации, и не имеет централизованной сетевой власти для управления. Фактически, это - все Usenet сведения, кроме технического описания. Вы не можете определять, что это, Вы можете только сказать чем это не является. С риском звучать глупо, можно было определить Usenet как сотрудничество отдельных абонентов, которые обмениваются Usenet новостями. Базисный модуль Usenet новостей - статья. У статьи есть так называемый заголовок. Это очень похоже на формат заголовка почты, установленный в Internet, стандарт RFC 822, в котором это состоит из отдельных строк текста, каждое начинается с имени поля, завершенного двоеточием, которое сопровождается значением поля. (1) Статьи представлены на рассмотрение в одну или большое количество newsgroups. Можно рассматривать newsgroup форумом для статей в отношении общего предмета. Все newsgroups организованы в иерархии, с именем каждой группы, указывающим место в иерархии. Например, любой может видеть из имени newsgroup, что comp.os.linux.announce используется для объявлений относительно операционной системы Linux.
Что такое - Сообщения Почты?
Сообщение Почты вообще состоит из тела сообщения, которое является текстом, написанным отправителем, и специальных данных, определяющих получателей, транспортную среду, и т.д., подобно тому, что Вы видите когда Вы рассматриваете почтовый конверт. Эта административно-управленческая информация относится к двум категориям; в первом классе - любые данные, который является специфическими для транспортной среды, подобно адресу отправителя и получателя. Это следовательно называется конвертом или оболочкой. Это может быть преобразовано транспортным программным обеспечением, при передаче сообщения. Вторая - любые данные, необходимые для обработки сообщения почты, которые - не часть любого транспортного механизма, типа подчиненной строки сообщения, списка всех получателей, и даты. В многих сетях, стало стандартным добавлять эти данные к сообщению почты, формируя так называемый заголовок почты. Это отделено от тела почты пустой строкой. (1) 1. Обычно добавляются сигнатура или .sig к сообщению почты, обычно содержащая информацию относительно автора, наряду с шуткой или девизом. Она отделяется от сообщения почты строкой, содержащей "--".
Большинство программного обеспечения для транспорта почты в мире Unix использует формат заголовка, выделенный в RFC 822. Его первоначальная цель - определить стандарт для использования на ARPANET. RFC 822 однако - только самый общий. Более современные стандарты были задуманы, чтобы справиться с возрастанием потребностей как, например, шифрование данных, поддержка набора интернационального символа, и мульти-средств расширения почты (MIME). Всего эти стандарты, заголовка состоят из отдельных строк, отделяемых символами перевода строки. Типичный заголовок почты может выглядеть следующим образом: From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994 Return-Path:
Received: from brewhq.swb.de by monad.swb.de with uucp (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp (Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 21:47 MEST Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 - 0400 Date: Tue, 12 Apr 1994 15:56:49 -0400 Message-Id: <199404121956.PAA07787@ruby> From: andyo@ora.com (Andy Oram) To: okir@monad.swb.de Subject: Re: Your RPC section Обычно, все необходимые поля заголовка генерируются Вашим mailer`ом, например elm (электронная почта), pine, mush, или mailx. Некоторые однако необязательны, и могут быть добавлены пользователем. Электронная почта, например, позволяет Вам редактировать часть заголовка сообщения. From: Это содержит адрес email отправителя, и возможно "реальное имя''.
To: Это - адрес email получателя. Subject: Описывает содержание почты в нескольких словах. По крайней мере должен. Date: Дата посылки почты. Reply-To: Определяет адрес для ответа получателя. Это может быть полезно, если Вы имеете несколько адресов, но хотите получать большую часть почты только на том, который Вы используете наиболее часто. Это поле необязательно. Oranization: организация, которая обладает машиной из который почта исходит. Это поле необязательно. Message-ID: строка, сгенерированная транспортировщиком почты. Она уникальна для этого сообщения. Received: Каждый пункт, через который проходит ваша почта (включая машины отправителя и получателя) вставляет такое поле в заголовок, указывая имя пункта, идентичность сообщения, время и дату получения сообщения, из какого пункта оно происходит, и которое транспортное программное обеспечение использовалось. Это сделано чтобы Вы могли проследить путь сообщения сообщения. X-заголовок: mail-программы не должны жаловаться на заголовки, которые начинаются с X-. Они используются, чтобы воплотить дополнительные возможности, которые еще не реализованы в RFC. Одно исключение к этой структуре - сама первая строка. Она начинается с ключевого слова From, которое сопровождается пробелом вместо двоеточия. Она содержит маршрут, время и дату, когда оно было получено последней машиной, обрабатывавшей его, и необязательную часть, определяющую, от которой главной ЭВМ оно было получено.
Поле From предусмотрено для совместимости с несколько более старым mailer'ами, и не используется особенно часто, за исключением интерфейсами пользователя почты.
Dip ссылка.
"Хотя широко используемый, dip не был еще очень хорошо описан. Поэтому, в этом разделе мы дадим ссылку для большинства dip команд. Вы можете получить краткий обзор всех команд, вызывая dip в test режиме, и вводя help команду. Для того, чтобы выяснять относительно синтаксиса команды, Вы можете набрать его без каких-либо аргументов; конечно это не работает с командами, которым не нужны никакие аргументы.
$ dip -t DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van Kempen, MicroWalt Corporation.
DIP> help DIP knows about the following commands:
databits default dial echo flush get goto help if init mode modem parity print port reset send sleep speed stopbits term wait
DIP> echo Usage: echo on|off DIP>
На всем протяжении, примеры, которые выделяют DIP> prompt показывают, как ввести команду в test режиме, и что output производится. Примеры, испытывающие недостаток в prompt должны приниматься как script отрывок.
Дистанционное управление
Очень общий механизм для клиент-сервера приложения обеспечивается RPC, пакетом дистанционного управления. RPC был разработан Sun Micrsystems, и эта система - набор инструментальных средств и библиотечных функций. Важные приложения, сформированны на вершине RPC - NFS, Network Filesystem, и NIS, Network Information System, обе из которых будут представлены в следующих главах.
RPC сервер состоит из системы процедур того, что клиент может обратится, посылая RPC запрос к серверу, наряду с параметрами процедуры. Сервер вызовет обозначенную процедуру по защите клиента, вручая обратно возвращаемое значение, если имеется любое. Чтобы быть машинно-независимыми, зсе жанные, обмененные между клиентом и сервером преобразованны к так называемому Внешнему Представлению Данных (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 серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с обслуживанием с данным номером программы сначала сделает запрос portmapper на числа порта обслуживание, которые могут быть достигнуты.
Этот метод имеет частичный недостаток, что это вводит единственную точку отказа, очень похожую на inetd daemon. Однако, этот случай немного хуже, потому что когда portmapper умирает, вся RPC информация порта теряется; это обычно значит, что Вы должны перезапустить все RPC серверы вручную, или перезагрузить целую машину.
На Linux, portmapper называется rpc.portmap и постоянно находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2, рortmapper не требует любой работы по конфигурации.
DNS файл базы данных.
Основной файл включаемый named, подобно named.hosts, всегда имеет область соединенную с ним, которая называется origin. Это - область название которой определено с кэшем и с основными командами. Внутри основного файла Вам дозволено определить область и имена хостов относительно этой области. Имя, данное в файле конфигурации, считается абсолютным, если оно заканчивается в единственной точке, иначе она будет рассматривается относительно origin. Весь оrigin может быть упомянут, если Вы используете "@".
Все данные, содержащиеся в основном файле определены в источнике записей, или Rrs(resource records) для краткости. Они составляют самую малую единицу информации доступную через DNS. Каждый способ записи имеет тип. Запись, например отображение имени хоста к IP адресу, и CNAME запись ассоциируется с псевдонимом для хоста с его официальным именем. Например, посмотрите на рисунок 7.2.3 на странице 116, которая показывает named.hosts основной файл для virtual brewery.
Способ записи в основых файлах является общим форматом:
[domain] [ttl] [class] type rdata
Поля отделены пробелами или табуляцией. Запись может быть продолжена через несколько строк, если открываящая"фигурная скобка появляется перед первой строкой, и последнее поле оканчивается закрывающей фигурной скобкой. Что-либо между точкой с запятой и новой строкой игнорируется.
domain Это имя области в которой появляется запись. Если имя области не дано, RR попытается обратиться к области из предыдущего RR.
ttl Необходим для того чтобы заставить решающие устройства отбрасывать информацию после определенного промежутка времени, каждый RR ассоциируется с "time to live'', или ttl для краткости. Поле ttl определяет время в секундах.
information имеет силу после того, как она была найдено на сервере. Это - десятичное число с восемью разрядами.
Если ttl значение не дано, то будет использоваться значение по умолчанию к значению минимального поля предшествующей SOA записи.
class Это - класс адреса, подобно IN для IP адресов, или HS для объекта в Hesoid классе. Для TCP/IP сетей, Вам необходимо сделать это IN. Если никакой класс поля не дан,то будет принят класс предшествующего RR.
type Это описывает тип RR. Наиболее общие типы: A, SOA, PTR, и NS. Следующие разделы описывают различные типы RR.
rdata Это задерживает данные связанные с RR. Формат этого поля зависит от типа RR. Ниже, это будет описано для каждого RR поотдельности.
following - незавершенный список RR, который нужно использовать в DNS основном файле. Имеется несколько пар из них, которые мы не будем объяснять. Они являются экспериментальными, и вообще, небольшого использования.
SOA
Это описывает зону власти (SOA означает " Start of Authority''). Он сообщает что запись следующая за SOA RR содержите авторитарную информацию для области. Каждый основной файл, включенный основным оператором должен содержать SOA запись для этой зоны. Источники данных содержат следующиз поля:
origin Это - каноническое имя хоста основного сервера для этой области. Обычно дается как абсолютное имя.
contact Это - email адрес человека ответственного за поддержания области, со знаком "@" в качестве точки. Например, если ответственный в Virtual Brewery - janet, то тогда это поле содержало бы janet.vbrew.com.
serial Это - номер версии зонального файла, выраженный как единственное десятичное число. Всякий раз, когда данные меняются в зональном файле, то это число должно быть увеличено.
Серийный номер используется вторичными серверами, чтобы распознать, когда зональная информация была изменена. Чтобы оставаться на уровне современных требований, вторичные серверы запрашивают SOA запись примарного сервера в определенные промежутки времени, и сравнивают порядковый номер с кэшируемой SOA записью. Если номер изменился, то вторичные серверы переносут целую зону баз данных из основного сервера.
refresh Определяет интервал, в секундах, который вторичные серверы должны использовать между проверками SOA записей основного сервера. Это - десятичный номер более чем с восемью разрядами.
В основном, сетевая топология слишком часто не изменяется для того, чтобы этот номер точно определял интервал для сликшом бурных дней больших сетей, и даже для меньших сетей.
retry Этот номер определяет интервалы за которые вторичный сервер должен повторить соединение с основным сервером, если запрос или зональная регенерация терпит неудачу. Он не должно быть слишком маленьким, потому что даже временный отказ сервера или сетевая проблема могут потратить впустую все сетевые ресурсы. Один час, или возможно полчаса, могли бы быть хорошим выбором.
expire - определяет время в секундах после которого сервер должен наконец-то отбросить все зональные данные, если невозможно было войти в контакт с основным сервером. Этот промежуток времени в основном должен быть очень большим. Craig Hunt (GETS "hunt - tcpip"]) рекомендует 42 дня.
minimum - задает по умолчанию ttl значение для исходных записей, которые точно не определяют его. Требует другого сервера, чтобы отбросить RR при проверки после определенного кол-ва времени.
Ничего нельзя сделать с временем после которого вторичный сервер попробует модифицировать зональную информацию.
minimum должен быть большим значением, особенно для LANs, где сетевая топология почти никогда не меняется. Значение в неделю или в месяц. В случае, когда единственные Rrs могут часто изменяться, то Вы все еще можете приписывать им различные ttl.
A
Ассоциирует IP адрес с hostname. Источник полей данных содержит адрес в dotted quad notation.
Для каждого хоста должна быть только одна запись. Hostname используемый в этой А записи рассматривается служебным или каноническим hostname. Все другие hostnames - псевдонимы и должны быть отображены на каноническом hostname используя CNAME запись.
NS
Указывает на главный сервер подчиненной зоны. Для объяснения, почему, каждый должен иметь NS запись, просмотрите раздел 3.6. Источник полей данных содержит hostname сервера. Можно разрешить дополнительный hostname к A записи, так называемый glue, которая дает IP адрес сервера.
CNAME
Ассоциирует псевдоним хоста с его каноническим hostname. Каноническиий hostname - главный файл, который обеспечивает А запись; псевдонимы просто связаны с этим именем CNAME записью, но не имеют собственные записи.
PTR
Этот тип записи используется, для того, чтобы соединить имя в Addr.arpa области с hostnaoes. Это используется для обратного отображения IP адресов к hostnames. Данный hostname должен быть каноническим hostname.
MX
Эта RR объявляет преобразователь почты для области. Для чего надо иметь преобразователи почты, обсуждено в разделе 14.4.1 в главе 14.. Синтаксис MX записи следующий:
[domain] [ttl] [class] MX preference host
host объявляет преобразователь почты для области. Каждый преобразователь почты предпочитает целое число, связанное с этим хостом. Агент переноса почты, то кто желает доставить почту к области, будет перебирать все хосты, не имеющие MX записей в этой области, пока все не пойдет успешно. Сначала будет пробоваться тот хост, у которого самое низкое число, а дальше все хосты с числом по возрастанию (это число называется-preference value).
HINFO Эта запись предоставляет информацию относительно аппаратных средств системы и программного обеспечения. Синтаксис этой записи:
[domain] [ttl] [class] HINFO hardware software
Аппаратная область идентифицирует аппаратные средства, используемые этим хостом. Имеются специальные соглашения, чтобы точно определить ее. Список подходящих имен дан в "Assigned Numbers'' (RFС 1340). Если область содержит пробелы, то это надо заключить в двойные кавычки. Имена областей программного обеспечения используються операционной системой. И снова, подходящее имя может быть выбрано из "Assigned Numbers'' RFC.
Документация о Linux
Одна из жалоб, которая часто возникает в связи с Linux (и свободным программным обеспечением вообще) -- жалкое состояние или полное отсутсвие документации. Раньше было обычным делом, что пакет программ распространялся с горсткой примечаний по установке и README-файлов. Они давали опытному оператору достаточное количество информации чтобы успешно установить и управлять этим пакетом, но были недостаточны для пользователя.
Так в 1992, Lars Wirzenius и Michael K. Johnson предложили организовать проект документации для Linux, или LDP (Linux Documentation Project), который стремится к обеспечению пользователя полным набором документации. Коротко останавливаясь на вопросах типа " Как? ", "Почему?", или "Что - значит жизнь, вселенная, и все остальное?", эти руководства пытаются охватить все аспекты управления и использования Linux пользователем, не требуя от него предварительного знания Unix. Среди достижений LDP - Руководство по установке, написанное Matt Welsh, Руководство по взлому ядера, Michael K. Johnson, и проект создания man-страниц, скоординированный Rik Faith, который пока снабдил Linux 450 страницами руководства для большого количества системных вызовов и Cи библиотек. Руководство для администраторов системы, написанное Lars Wirzenius, находится все еще на стадии разработки. Руководство пользователя уже подготовлено.
Однако, книги LDP - не единственный источник информации о Linux. В настоящее время, имеются больше чем дюжина HOWTOs, которые отправлены по почте к comp.os.linux.announce и регулярно архивируются на различных FTP серверах.
HOWTOs - короткие документы, состоящие из нескольких страниц, которые дают Вам краткое представление по темам типа поддержки Ethernet под Linux, или конфигурации Usenet программного обеспечения, а также ответы на часто задаваемые вопросы. Они обычно обеспечивают наиболее точную и современную информацию, доступную по даннной теме. Список доступных HOWTO приводится в "Аннотируемой Библиографии" в конце этой книги.
Domaintable
Domaintable вообще используется, чтобы вынудить некоторое поведение после того, как поиск DNS произошел. Это разрешает администратору делать короткие имена доступными для обычно вызываемых систем или областей, заменяя такое имя на соответствующее автоматически. Это может также использоваться, чтобы заменить неправильный host или имена области на " правильные ". Большинство абонентов не будет нуждаться в любых входах domaintable. Следующий пример показывает, как заменить неправильные адреса на правильный адрес:
#============= /usr/local/lib/mail/domaintable ================= # # brokenhost.correct.domain brokenhost.wrong.domain # # #=================== end of domaintable ========================
Дополнительная Информация
Если Вы следуете инструкциями этой книги, и что-нибудь не работает, пожалуйста будьте терпеливы. Некоторые из ваших проблем могут возникнуть из-за моих глупых ошибок, но могут также быть вызваны изменениями в программном обеспечении. Лучше спросить относительно своих проблем на comp.os.linux.help. Есть большая вероятность что Вы не единственный кто столкнулся с подобными вашим проблемами, и ее решение известно. Если Вы имеете возможность, Вы должны также попробовать получить самую последнюю версию ядра и сетевого программного обеспечения на одном из Linux FTP серверах, или на ближайшей от вас BBS.
Много проблем связаны с программным обеспечением находящихся на различных стадиях разработки, которые оказываются не в состоянии работать вместе должным образом.
Другое хорошее место, где можно узнать о процессе разработки организация сети HOWTO. Ее поддерживается Terry Dawson HOWTOs отсылаются по почте на comp.os.linux.announce один раз в месяц, и содержат наиболее современную информацию. Текущая версия может быть также получена на tsx-11.mit.edu, в /pub/linux/doc. Если свои проблемы Вы не можете решить другим путем, Вы можете также войти в контакт с автором этой книги по адресу данному в ведении. Но, пожалуйста, воздержитесь от обращения за помощью к разработчикам. Они и так посвящают основную часть свободного времени Linux.
Дополнительно о портах
Порты могут рассматриваться как точки присоединения сетевых связей. Если приложение (сервер) хочет предложить некий сетевой сервис, оно ассоциирует себя с портом и ждет клиентов (это называется слушать порт). Клиент, который хочет использовать этот сервис получает порт на местном хосте и соединяется с портом сервера на отдаленном хосте.
Важная особенность портов то, что пока существует связь между клиентом и сервером, другая копия сервера может присоединиться к тому же порту и ждать подключения других клиентов. Это разрешает, например, несколько параллельных отдаленных входов на один и тот же хост, причем все используют один самый 513 порт. TCP способен отличать этим связи друг от друга, потому что они все прибывают от различных портов или хостов. Например, если Вы дважды войдете на quark от erdos, тогда первый rlogin клиент будет использовать местный порт 1023, а второй будет использовать порт 1022. Однако, будут соединяться с тем же самым портом 513 на quark.
Этот пример показывает использование портов как пункты, где клиент входит в контакт с определенным портом чтобы получить определенное обслуживание. Клиенту необходимо знать надлежащий номер порта, соглашение о назначении этих номеров должно быть достигнуто между администраторами обеих систем. Для услуг которые широко используются, типа rlogin, эти номера должны устанавливаться централизованно. Этим занимается IETF (или Проектирующая задачи Internet сила), которая регулярно выпускает RFC статьи. Которые, среди прочего, назначают номера портов для общеизвестных услуг. Linux использует файл, в котором регистрируют названия доступного другим сервеса и номера портов, к которым определенный сервес прикреплен, называется он /etc/services. Он описан в секции 10.3.
Стоит заметить, что хотя и TCP и UDP полагаются на порты, эти номера не находятся в противоречии. Это означает что TCP порт 513, например, отличается от UDP порта 513. Фактически, эти порты служат как точки доступа для двух различных услуг, а именно rlogin (TCP) и rwho (UDP).
Доступ к последовательным устройствам
Подобно всем устройствам в Unix системах, последовательные порты доступны через специальные файлы, располагающиеся в директории /dev. Имеются два множества файлов устройств, связанных с последовательными драйверами, и для каждого порта, имеется один файл из каждого множества. В зависимости от файла к которому обращаются, устройство будет вести себя по-разному.
Первые файлы требуются в случае, если порт используется для входа; они имеет главный номер 4, и файлы названы ttyS0, ttyS1, и т.д.. Вторые используется для выхода; файлы названы cua0, и т.д., и имеют главный номер 5. Незначительные номера одинаковы для обоих типов. Если ваш модем подключен к одному из портов от COM1 до COM4, незначительный номер будет номер COM порта плюс 63. Если ваша установка отлична от этой, например при использовании платы поддерживающей множество последовательных линий, пожалуйста обратитесь к Serial Howto.
Предположим, что ваш модем находится на COM2. Таким образом незначительный номер будет 65, а главный номер для дозвона будет 5. Следовательно, должно иметься устройство cua1 которое имеет этот номер. Просмотрите список последовательный ttys в директрорие /dev. Колонки 5 и 6 должны показать главные и незначительные номера, соответственно:
$ ls -l /dev/cua* crw-rw-rw- 1 root root 5, 64 Nov 30 19:31 /dev/cua0 crw-rw-rw- 1 root root 5, 65 Nov 30 22:08 /dev/cua1 crw-rw-rw- 1 root root 5, 66 Oct 28 11:56 /dev/cua2 crw-rw-rw- 1 root root 5, 67 Mar 19 1992 /dev/cua3
Если нет таких устройств, Вы должны создать их: войдите супер-пользователем и наберите
# mknod -m 666 /dev/cua1 c 5 65 # chown root.root /dev/cua1
Некоторые Люди предлагают создание символической связи /dev/modem на ваше устройство модема, так, чтобы случайные пользователи не должны были запоминать несколько неинтуитивное cua1. Однако, Вы не можете использовать modem в одной программе, а реальное название файла устройства в другой. Это - потому что эти программы используют так называемые файлы замка (lock files) для обозначения того, что устройство используется. В соответствии с соглашением, имя файла замка для cua1, например, является LCK..cua1. Использование различных файлов устройства для того же самого порта приведет к тому, что программы окажутся не в состоянии распознавать файлы замка для каждого имени, и будут и использовать устройство в одно и то же время. В результате, оба приложения не будут работать вообще.
Другие полезные инструментальные средства
Имеется несколько инструментальных средств, которые помогут Вам с Вашими задачами как BIND администратор. Я кратко опишу два из них. Пожалуйста обратитесь к документации, которая прилагается с этими инструментальными средствами для выяснения того, как их использовать.
hostcvt - средство, которое помогает Вам с Вашей начальной BIND конфигурации, преобразовывая ваш /etc/hosts файл в главный файл для named. Оно генерирует оба и прямое (A) и обратное отбражение (PTR), и заботится о псевдонимах и т.п. Конечно, оно не будет делать всю работу за Вас, поскольку Вы можете все еще захотеть настроить значения блокировки по втемепи в SOA записи сами, например, или прибавить MX запись и т.п. Но оно может помочь сохранить Вам несколько таблеток аспирина. Hostcvt - часть BIND источника, но может также быть использован как автономный пакет на несколько Linux FTP серверах.
После установки вашего сервера, Вы можт быть захотите проверить Вашу конфигурацию. Идеальным (и, по моему мнению тоже) средством для этого является dnswalk, perl-based пакет который прогуливается по вашей DNS базе данных, выискивая общие ошибки и проверяет совместимость информации. Dnswalk был выпущен на comp.sources.misc недавно, и должен быть доступен на всех FTP, которые архивируют эту группу.
Другие пути развития
В это время, продолжая разработку, Fred предложил Net-2e, в которой сильно пересмотрено вся структура организации сети. Во время написания этой книги, Net-2e все еще Beta программное обеспечение. Наиболее интересен в Net-2e - объединение DDI, Интерфейса Драйвера Устройства. DDI предлагает однотипный доступ и метод конфигурации для всех устройств сети и протоколов.
Пока используется TCP/IP сеть написанная Matthias Urlichs, написавшего ISDN драйвер для Linux и FreeBSD. Для этого, он встроил BSD сетевой код в ядро Linux.
В течение обозримого будущего, Net-3 скорее всего останется. Alan в настоящее время работает над AX.25 протоколом, используемого любителями радио. Несомненно, скоро будет разработан "модуль" для ядра, который позволит Вам добавлять драйвера к ядру не переустанавливая систему.
Хотя эти различные реализации сети борются за обеспечение одного и того же сервеса, основные их различия находятся на уровне ядре и устройств. Поэтому, Вы не сможете отконфигурировать систему используя Net-2e ядро с утилитами от Net-2d или Net-3, и наоборот. Это относится только к командам, которые имеют дело с ядром; приложения и общие сетевые команды типа rlogin или telnet пойдут на любом из них.
Однако, все эти различные версии сети не должны волновать Вас. Если Вы не участвуете в активной разработке, Вы не должны волноваться относительно версии сода TCP/IP. Официальные выпуски ядра будут всегда сопровождаться набором сетевых инструментов, которые являются совместимыми с кодом представленным в ядре.
Другие типы аппаратных средств
В больших сооружениях, типа Groucho Marx Университет, Ethernet обычно не единственный тип используемого оборудования. В Groucho Marx Университет, локальная сеть каждого отдела связана с университетской магистралью, которая является оптическим кабелем FDDI. FDDI использует совершенно другой подход к передаче данных, который основывается на рассылке определенных символов, и только если станция получает этот символ, она может послать некий кусок информации. Главное преимущество FDDI - скорость, достигающая 100 Mbps, и максимальная длина кабеля до 200 км.
Для дальней связи часто используются различные типы оборудования, которые основаны на стандарте названном X.25. Большинство так называемых "Общественных Сетей Данных", подобно Tymnet в США, или Datex-P в Германии, предлагают свои услуги, основываясь именно на нем. X.25 требует специальных аппаратных средств, а именно пакет Assembler/Disassembler или PAD. X.25 определяет собственный набор протоколов, но часто используется чтобы соединить сети работающие под TCP/IP и другими протоколами. Так как IP пакеты не могут быть прямо отображены на X.25 ( и наоборот ), они просто вставляются в X.25 пакеты и посылаются по сети.
Часто, радио любители используют свое оборудование для создания сети из своих компьютеров; это называется пакетное радио или ham радио. Протокол используемый ham радио назван AX.25 (он получен из X.25).
Есть методы, которые используют специально для медленных, но дешевых телефонных линий. Они требуют других протоколов для передачи пакетов, типа SLIP или PPP, которые будут описаны ниже.
Другой пример
Для остатка этой книги, позвольте мне представить новый пример, который является менее сложным чем Groucho Marx Университет, и ближе к задачам, с которыми Вы будете фактически сталкиваться. Рассмотрим виртуальную пивоварню, маленькую компанию, которая варит пиво. Чтобы управлять этим бизнесом более эффективно, в пивоварне хотят создать сети из компьютеров, которые все оказались PC, управляемые Linux 1.0.
На том же самом этаже, только через коридор, имеется виртуальная винодельня, которая работает рядом с пивоварней. Там используется собственный Ethernet. Весьма естественно, что две компании хотят связать свои сети. Как первый шаг, они хотят создать gateway, который будет передавать дейтограмы между двумя полсетями. Позже, они также за хотят иметь UUCP связь с внешним миром. В конечном счете, они захотят установить SLIP соединение чтобы соединяться иногда с Internet.
Dummy(фиктивный) интерфейс
Фиктивный интерфейс действительно немного экзотический, но довольно полезен. Он наиболее полезен для автономных хостов, и машин, которые связаны с сетью через модем. Фактически, последний большинство времени также является автономным хостом.
Проблема автономных хостов в том, что они имеют только одно активное сетевое устройство, loopback устройство, которому обычно назначен адрес 127.0.0.1. На в некоторых случаях, Вы должны послать данные к "официальному" IP адресу локального хоста. Например, рассмотрите laptop vlite, который был отъединен от сети Приложение на vlite может захотеть послать некоторые данные к другому приложению на том же самом хосте. Поиск vlite в /etc/hosts выдает IP адрес 191.72.1.65, таким образом приложение пытается послать данные этому адресу. Поскольку интерфейс loopback в настоящее время единственный активный интерфейс на машине, ядро не имеет никакую идей относительно этого адреса! Как следствие, ядро отказывается от дэйтаграмы, и возвращает приложению ошибку.
В этот момент просто необходимо фиктивное устройство. Оно решает эту проблему также как loopback. В случае vlite, Вы просто даете ему адрес 191.72.1.65 и добавляете новый маршрут указывающий на него. И каждая дэйтаграма для 191.72.1.65 будет рассматривается локально. Требуемые действия:
# ifconfig dummy vlite # route add vlite
Echo и term.
Команда ECHO служит как помощь в отладке, в которой использование ECHO ON делает dip ECHO на консоли и все посылает к порядковому устройству. Он может быть выключен снова, набирая ECHO OFF.
Dip также позволяет Вам оставить script режим временно и вступить в terminal режим. В этом режиме, Вы можете использовать dip точно так же как и обычную terminal программу, пишущей в последовательную линию и читющей из нее. Чтобы оставить этот режим, введите " Ctrl-] ".
Email Адреса
Для электронной почты, адрес состоит из по крайней мере имени машины, обрабатывающей почту определенного человека, и идентификацию пользователя, распознаваемую этой системой. Это может быть имя входа в систему получателя, но может также быть что - нибудь еще. Другая почтовая адресующая схема, подобно X.400, использует более общий набор " атрибутов " которые используются, чтобы искать главную ЭВМ получателя в X.500. Способ интерпретации машинного имени зависит от сети, в которую Вы включены. Абоненты Internet твердо придерживаются RFC 822 стандарта, который требует записи user@host.domain, где host.domain - полностью квалифицированное имя главной ЭВМ области. В середине знак "в". Потому что эта запись не включает маршрут до главной ЭВМ адресата, но дает (уникальное) hostname взамен, это называется абсолютным адресом. В оригинале UUCP среды, распространенная форма была path!host!user (путь!главная ЭВМ!пользователь), где путь описывал последовательность главных ЭВМ для достижения главной ЭВМ адресата. Эта конструкция называется записью пути удара, потому что метка восклицания называется "Ударом". Сегодня, много uucp- подобных сетей приняли RFC822, и понимают этот тип адреса.
Однако, имеется способ определить маршруты RFC822- совместимыми способоами: < @hostA,@hostB: user@hostC > обозначает адрес пользователя на hostC, где HostC должен быть достигнут через hostA и hostB (в этом порядке). Этот тип адреса - часто называется адресом маршрута. Когда, имеется " % " оператор адреса: user%hostB@hostA будет сначала послан hostA, который расширяет знак процента в знак "@". Адрес - теперь user@hostB, и Mailer будет счастливо передавать ваше сообщение к hostB, который передаст его пользователю. Этот тип адреса иногда упоминается как "Ye Olde ARPANET Kludge''. Однако, много средств транспорта почты генерируют этот тип адреса. Другие сети имеют различные способы адресации. Decnet- основанные сети, например, используют два двоеточия как разделитель адресов, производя адрес так - главная ЭВМ::пользователь. X.400 стандарт использует полностью отличную схему, описывая получателя набором пар свойств, подобно стране и организации. В сети FidoNet, каждый пользователь идентифицирован кодом подобно 2:320/204.9, состоящем из четырех чисел, обозначающих: зону (2 - для Европы), сеть (320 для Парижа), узел (локальный узловой хаб), и указатель (PC индивидуального пользователя). Fidonet адреса можгут быть отображены на RFC 822; вышеупомянутое написали бы как Thomas.Quinot@p9.f204.n320.z2.fidonet.org.
Если Не Проходит ...
Если кое-что идет неправильно с вашей установкой, имеется ряд возможностей, которые могут помочь Вам найти корень проблемы. Первое место, которое нужно проверить - регистрационные файлы smail. Они сохраняются в /var/spool/smail/log, и именованы logfile и paniclog, соответственно. Типичный вход в logfile походит на это: 04/24/94 07:12:04: [m0puwU8-00023UB] received | from: root | program: sendmail | size: 1468 bytes 04/24/94 07:12:04: [m0puwU8-00023UB] delivered | via: vstout.vbrew.com | to: root@vstout.vbrew.com | orig-to: root@vstout.vbrew.com | router: smart host | transport: smtp
Это показывает, что сообщение от root до root@vstout.vbrew.com было правильно передано host vstout над SMTP. Сообщения smail не могут быть переданы, генерацией входа в регистрационном файле, но сообщение об ошибке передается: 04/24/94 07:12:04: [m0puwU8-00023UB] received | from: root | program: sendmail | size: 1468 bytes 04/24/94 07:12:04: [m0puwU8-00023UB] root@vstout.vbrew.com ... deferred (ERR 148) transport smtp: connect: Connection refused Вышеупомянутая ошибка типична для ситуации, в которой smail правильно распознает, что сообщение должно быть передан к vstout, но не был способен соединиться с SMTP обслуживанием по vstout. Если это случается, Вы или имеете проблему конфигурации, или поддержка TCP отсутствует в вашем smail binaries. Эта проблема не так уж необыкновена, как можно было думать. Имелся бы исходник smail binaries, даже в некоторых распределениях Linux, без поддержки для работы с сетями TCP/IP. Если дело обстоит так, Вы должны компилировать smail самостоятельно. Устанавливая smail, Вы можете проверять, имеет ли он TCP поддержку работы с сетями telnet к SMTP порту на вашей машине. Успешное соединие с SMTP сервером, показывается ниже: $ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 monad.swb.de Smail3.1.28.1 #6 ready at Sun, 23 Jan 94 19:26 MET QUIT 221 monad.swb.de closing connection Если этот тест не производит SMTP заголовок (строка, начинающаяся с 220 кода), сначала удостовертесь, что ваша конфигурация действительно правильна прежде, чем компилировать smail самостоятельно, как описано ниже.
Если Вы сталкиваетесь с проблемой с smail, и Вы неспособны разместить сообщения об ошибках smail, Вы можете включить сообщения отладки. Вы можете сделать это используя -d флаг, необязательно сопровождаемый числом, определяющим уровень точности. Smail будет печатать отчет на экран, который может давать Вам большое количество подсказок относительно того что, идет неправильно.
Ethernet
Тип аппаратных средств наиболее широко используемый повсюду в локальных сетях обычно называют Ethernet. Он состоит из единственного кабеля с хостами
Присоединяемый к нему через connector, tap или transceivers. Простой Ethernet весьма недорог, хотя, вместе с сетью предлагает скорость в 10 Мегабитов в секунду.
Ethernet бывает трех видов: толстый и тонкий, соответственно, и витая пара. Тонкий и толстый Ethernet использует коаксиальный кабель, отличающейся по ширине и способу подключения машины к кабелю. Тонкий Ethernet использует "BNC" connector в форме буквы Т, в который Вы вставляете кабель и вкручиваете сзади вашего компьютера в гнездо сетевой платы. Толстый Ethernet требует, чтобы ВЫ проделали маленькую дырку в кабеле, и воткнули transceiver "методом вампира". Один или больше хостов может быть присоединено к одному transceiver. Тонкий и толстый кабель Ethernet может иметь длину не больше 200 и 500 метров, соответственно, и поэтому также названы 10base-2 и 10base-5. Витая пара использует кабель сделанный из двух медных проводов которые используются в телефонии, но обычно требует дополнительных аппаратных средств. Он также известен как 10base-T.
Добавление хоста к толстому Ethernet не слишком сложно, оно даже не вырубает сеть. Чтобы добавлять машину к сети с тонким Ethernet Вы должны прервать работу сети по крайней мере на несколько минут потому что Вы должны разрезать кабель чтобы вставить Т-connector.
Большинство людей предпочитают тонкой Ethernet, потому что это очень дешево: карты PC стоят всего $50, а кабель находится в диапазоне нескольких центов за метр. Однако, для больших сооружений, толстый Ethernet подходит лучше Например, в отделе математики используют толстый Ethernet, так что у них работа сети не будет прерваться каждый раз, когда к сети добавляется новый хост.
Один из недостатков Ethernet технологии -- ограниченная длинна кабеля, который позволяет использовать его только для локальных сетей. Однако, несколько Ethernet сегментов могут быть связан друг с другом с помощью repeaters (повторителей), bridges (мостов) или routers (маршрутизаторов). Repeaters просто копируют сигналы между двумя или больше сегментами так, что все сегменты вместе действуют как будто это один Ethernet. Но между двумя любыми машинами сети не может быть больше четырех repeaters. Bridges и Routers более сложные. Они анализируют поступающие данные и отправляют их только тогда, когда хоста получателя нет на местном Ethernet.
Ethernet работает подобно системной шине, где хост может послать пакеты до 1500 байтов другому хосту на том же самом Ethernet. Хост идентифицируется адресом, состоящем из шести байт зашитыми в Ethernet плату при ее создании. Эти адреса обычно записываются как последовательность шестнадцатиричных чисел с двумя цифрами отделяемыми двоеточиями, на пример aa: bb: cc: dd: ee: ff.
Структура посланная одной станцией видна и всеми остальными станциями, но только хост места назначения подбирает и обрабатывает ее. Если две станции пробуют послать сообщение одновременно, происходит столкновение, которое решается двумя станциями с помощью остановки передачи и попытке передать его несколько позже.
Ethernet интерфейсы
Конфигурирование интерфейса Ethernet, идет почти также как и интерфейса loopback, он только требует больше параметров когда Вы используете подсети.
В Виртуальной Пивоварне, мы разбивали на подсети IP сеть, которая была первоначально класс B. При установке интерфейса для требовалось бы написать:
# ifconfig eth0 vstout netmask 255.255.255.0
Эта запись назначает eth0 интерфейсу IP адрес vstout (191.72.1.2). Если бы мы опустили netmask, ifconfig вывел бы netmask из класса сети, что привело бы к netmask 255.255.0.0. Теперь быстренько проверим:
# ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0
Вы можете видеть что ifconfig автоматически устанавливает широковещательный адрес (поле Bcast) равный обычному значению, которое является номером сети хостов с битами хоста равными 1. Также, размер передаваемых сообщений (для данного интерфейса устанавливается максимальный размер Ethernet пакета) был установлен равным максимальному значению 1500 байтов. Все эти значения могут быть исправлены специальными опциями, которые было описаны позже.
Также как в loopback случае, Вы должны теперь установить маршрутизационную запись, которая сообщает ядру о сети, которая может быть достигнута через eth0. Для Виртуальной Пивоварни, Вы это сделали бы так
# route add -net 191.72.1.0
Сначала это смотрится как волшебство, потому что это действительно не очевидно как route обнаруживает, которые сети связываются с помощью каких интерфейсов. Однако, уловка довольно проста: ядро проверяет все интерфейсы которые были отконфигурированы и сравнивает адрес места назначения (в этом случае 191.72.1.0) с сетевой частью адреса интерфейса. Единственный интерфейс, который соответствует данному адресу, -- eth0.
Теперь, что такое -net опция? Она используется, потому что route может работать с маршрутами к сетям и с маршрутам к отдельным хостам (как Вы видели в localhost). Когда route получает адрес в dotted quad стандарте, он пытается предположить принадлежит ли этот адрес сети или хосту, проверяя биты части хоста. Если хост часть адреса - ноль, маршрут предполагает, что это обозначает сеть, в противном случае, что это адрес хоста.
Поэтому, route решил бы, что 191.72.1.0 - адрес хоста, потому что он не может знать что мы используем подсети. Поэтому мы должны явно сообщить, что это адрес сети, это делает -net флаг.
Конечно, вышеупомянутая команда, немного утомительна для набора и дает много ошибок. Более удобный подход -- использование сетевых имен, которые мы определили в /etc/networks. Это делает команду еще более удобочитаемой; и даже -net флаг может быть теперь опущен, потому что route теперь знает, что 191.72.1.0 обозначает сеть.
# route add brew-net
Теперь, когда вы закончили основные шаги конфигурации, надо удостовериться что ваш Ethernet интерфейс действительно работает правильно Выберите хост на вашем Ethernet, например vlager, и наберите
# ping vlager PING vlager: 64 byte packets 64 bytes from 191.72.1.1: icmp seq=0. time=11. ms 64 bytes from 191.72.1.1: icmp seq=1. time=7. ms 64 bytes from 191.72.1.1: icmp seq=2. time=12. ms 64 bytes from 191.72.1.1: icmp seq=3. time=3. ms ^C
----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 3/8/12
Если Вы не видите вывод подобный этому, значит что-то не так. Если Вы сталкиваетесь с необычным количеством потерянных пакетов, это означает проблему аппаратных средств, типа плохого или отсутствующего terminator, и т.д.. Если Вы не получаете пакеты вообще, Вы должны проверить конфигурацию интерфейса с помощью netstat. Пакетная статистика, показанная ifconfig, должна сообщить Вам были ли вообще посланы какие-то пакеты. Если у вас есть доступ к удаленному хосту, Вы должны сходить к той машине и проверять там статистику интерфейса. Таким образом, Вы можете точно решить, где пропали пакеты. Кроме того, Вы должны посмотреть маршрутизационную информацию с помощью route, чтобы выяснить имеют ли оба хоста правильные записи в таблице маршрутов. route печатает всю таблицу маршрутизации, если его вызвать без аргументов( -n опция указывает печатать вместо адресов имена хостов):
# route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 191.72.1.0 * 255.255.255.0 U 1 0 10 eth0
Детальное значение этих полей объясняется ниже в секции 6.9. Колонка Flags содержит список флагов устанавливаемых для каждого интерфейса. U - всегда устанавливают для активных интерфейсов, а H сообщает, что адрес места назначения обозначает хост. Если H флаг - установлен для маршрута, который Вы считаете сетевым маршрутом, тогда Вы должны использовать -net опцию с командой route. (Чтобы проверить, используется ли маршрут, который Вы ввели, посмотрите на поле Use, которое находится между двум сообщениями ping.) To check whether a route you have entered is used at all, check if the Use field in the second to last column increases between two invocations of ping.
Файл active
Файл active расположенный в /usr/lib/news перечисляет все группы, известные в вашем пункте, и статьи в настоящее время интерактивные. Вы редко будете должны изменять его, но мы объясним это ради законченности. Входы имеют следующую форму:
newsgroup high low perm
Newsgroup, конечно, имя группы. Low и high - самые низкие и самые высокие числа статей, в настоящее время доступных. Если ни одна не является доступной в настоящее время, low = high + 1. Perm - параметр, детализирующий доступ пользователей в зависимости от группы. Он принимает одно из следующих значений:
y Пользователям разрешают отправить по почте к этой группе.
n Пользователям не разрешают отправить по почте к этой группе. Однако, группа может все еще читаться.
x Эта группа была заблокирована локально. Это случается иногда, когда администраторы новостей (или их старшие) закрывают статьи, зарегистрированные в некоторых группах.
Статьи, полученные для этой группы не сохранены локально, хотя они посланы к абонентам, которые запрашивают их. m Это обозначает уменьшенную группу. Когда пользователь пробует отправлять по почте к этой группе, интеллектуальный newsreader сообщит какая она, и пошлет статью регулятору взамен. Адрес регулятора принимается из файла регуляторов в /usr/lib/news. =real-group Это отмечает newsgroup как локальную специализацию для другой группы, а именно real-группы. Все статьи, зарегистрированные в newsgroup будут переназначены в нее. В C News, Вы вообще не будете должны обращаться к этому файлу непосредственно. Группы могут быть добавлены или удаляться, локально используя addgroup и delgroup (см. ниже в разделе 18.10). Когда группы добавляются или удаляются для всего Usenet, это обычно делается, посылая newgroup или rmgroup сообщение управления, соответственно. Никогда не посылайте такое сообщение самостоятельно! Для команд о том, как создавать newsgroup, читайте ежемесячник в news.announce.newusers. Файл, близко связанный с active - active.times. Всякий раз, когда группа создана, C News регистрирует сообщение в этот файл, содержащее имя созданной группы, дату создания, было ли это выполнено в соответствии c сообщением управления новой группы или локально, и кто сделал это. Это - для удобства newsreaders, которые могут сообщать пользователю относительно любой недавно созданной группы. Это также используется командой NEWGROUPS NNTP.
Файл экспорта
В то время как вышеупомянутые опции обращаются к 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) /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.
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 как и сервер. Эта опция определена по умолчанию.
map daemon Эта опция сообщает NFS серверу принять, что клиента и сервер не разделяют то же самое пространство uid/gid. nfsd затем построит список идентичности отбора между клиентом и сервером, запрашивая client's ugidd daemon.
Ошибка, анализирующая файл экспорта сообщает daemon syslogd's оборудованию всякий раз, когда nfsd или mountd запущен.
Заметьте, что имена хостов получены из IP адреса клиента обратным отбором, так что Вы должны иметь правильно сконфигурированное решающее устройство. Если Вы используете BIND и очень security-conscious, то Вы должны включить spoof проверку в Вашем host.conf файле.
Файл конфигурации хоста.
Центральный файл, который управляет вашей установкой - host.conf. Он сообщает решающему устройству какой сервис использовать, и в каком порядке.
Опции в host.conf должны быть на отдельных строках. Области могут быть отделены пустым пространством (spaces или tabs). Знак (#) вводит строку, которая простирается вплоть до следующей строки.
Доступны следующие опции:
Order: Эта опция определяет порядок в котором перебераются все доступные услуги. Valid опция - связывает запроса сервера и поиск хостов в /etc/hosts, и nis для NIS поисков. Любая или все из них могут быть определены. Порядок, в которым они появляются на строках определяет порядок в котором будут перебираться определенные услуги.
Multi: Она может использоваться как опция. Эта опция определяет, разрешено ли хосту в /etc/hosts иметь несколько IP адресов, которые обычно пазываются "multi - homed". Этот флаг не действует на DNS или NIS запросы.
Nospoof: Как уже было объяснено в предыдущей главе, DNS позволяет Вам найти имя хоста принадлежащего IP адресу, используя inaddr.arpa область. Попытки серверов поддержать ложное имя хоста называется "spoofing".Чтобы обезопасить себя от этого, решающее устройство может быть сконфигурировано на проверку, является ли настоящий IP адрес фактически связанным с полученным именем хоста. Если нет, то этому имени будет отказано и будет возвращен код ошибки. Это поведение зависит от того включен ли nospoof.
Alert: Эта опция может использоваться как аргумент. Если эта опция включена, то любые попытки spoof (см. выше) будут причинами того, чтобы решающее устройство отправило бы сообщение к syslog оборудованию.
Trim: Эта опция берет имя области как аргумент, которое будет удалено из имени хоста перед поиском. Это полезно для информационных элементов, где Вы могли бы только желать точно определить имя хоста с локальной областью. При поиски хоста с именем локальной области, будет удалено имя этой области, таким образом легко осуществить поиск в /etc/hosts.
Опция Trim позволяет рассматривать Ваш хост локальным для нескольких областей.
Типовой файл для vlager описывается ниже:
# /etc/host.conf # We have named running, but no NIS (yet) order bind hosts # Allow multiple addrs multi on # Guard against spoof attempts nospoof on # Trim local dooain"(not really necessary). trim vbrew.com.
Файл named.boot.
Файл named.boot в основном очень мал и содержит еще немного информации, но содержит указатели на главные файлы, содержащие zone информацию, и указатели к другим серверам. Комментарии в файле начальной загрузки начинаются с точки с запятой и простираются вплоть до следующей линии. Прежде, чем мы обсудим формат named.boot файла более подробно, мы рассмотрим типовой файл для vlager представленный на рисунке 7.2.1. (2)
Кэш и основные команды, показанные в этом примере загружают информацию в named. Эта информация берется из главного файла, определенного во втором аргументе. Он содержат текстовые представления DNS источника записи, которые мы рассмотрим ниже.
1. Имеются различные named binaries касающиеся Linux FTP sites, каждые из которых не намного, но отличаются друг от друга. Некоторые имеют свой собственный pid файл, некоторые хранят его в /tmp или /var/tmp. 2. Заметьте, что имена областей в этом примере даны без конечной точки. Более ранние версии named принимают конечные точки в named.boot за ошибку, и их отбрасывают. BIND-4.9.3, как уже упоминалось, устраняет это.
; ; /etc/named.boot file for vlager.vbrew.com ; directory /var/named ; ; domain file ;--------------------------------------------------- cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 72.191.in-addr.arpa named.rev
Рисунок 9. Named.boot файл для vlager.
В этом примере, мы сконфигурировали named как основной сервер для трех областей, как обозначено основными операторами в конце файла. Первая из этих строк, например, инструктирует named действовать как основной сервер для vbrew.com, принимая zone данные из файла named.hosts. Ключевое слово каталога сообщает ему, что все zone files размещаются в /var/named.
Кеш запись очень особа и должна присутствовать фактически на всех машинах, запускающих сервер. Его функция - двукратная: она инструктирует named для отмены кэша, и загружает основной сервер hints из кэш файла (named.ca в нашем примере). Мы вернемся к серверам hints ниже.
Также имеется список наиболее важных опций, которые Вы можете использовать named.boot:
directory - определяет директорию, в которой zone files постоянно находятся. Имена файлов могут быть даны относительно этой директории.Несколько директорий могут быть определены неоднократно используя directory. Согласно стандарту Linux filesystem, эта директория должна быть /var/named.
primary - берет имя области и имя файла как аргумент, объявленный локальным сервером авторитарно для named области. Как основной сервер, named загружает zone информацию из данного главного файла.
В основном будет всегда, по крайней мере хотя бы одна основная запичь в каждом boot-файле, а именно для обратного отбора сети 127.0.0.0, которая является локальной замкнутой сетью.
secondary - берет имя области, список адресов, и имя файла как аргумент. Он объявляет локальный сервер вторичным главным сервером для установленной области.Вторичный сервер задерживает авторитарные данные поступающие на область, но он не собирает их из файла, и пробует загрузить их из основного сервера. IP адрес, по крайней мере одного основного сервера, должен быть дан named(у) в списке адресов. Локальный сервер войдет в контакт с каждым из них, пока он успешно не перенесет всю зональную базу данных, которая затем будет сохранена в файле с резервной копией, данной как третий аргумент. Если ни один из основных серверов не отвечает,то зональные данные восстановятся из файла с резервной копией взамен.named затем пытается обновить зональные данные в постоянные интервалы. Это объясняется ниже с SOA типом записи.
cache -Эта опция берет область и имя файла как аргументы. Этот файл содержит подсказки сервера hints, который является списком записей, указывающих на серверы. Но только NS и А записи будут признаны. Аргумент области, в основном ,- источник имени области.Эта очень важно: если кэш оператор не пояляется в boot-файле, named не начинает разрабатывать локальный кэш вообще. Это строго ухудшит характеристику и увеличит сетевую загрузку, если следующий сервер делает запрос не на локальную сеть. Кроме того, named не будет способен достичь всех серверов, и таким образом это не решит проблему адресов за исключением тех, которые авторитарны. Исключение из этого правила - это когда используются серверы пересылки (опция механизмов продвижения дана ниже).
forwarders -Этот оператор берет список адреса как аргумент. IP адреса в этом списке точно определяют список серверов, на которые named может сделать запрос, решается ли запрос из его локального кэша. Они тестируются по порядку, пока один из них не отвечает на запрос.
slave - это оператор делает главный сервер подчиненным сервером. То есть он никогда не будет выполнять рекурсивные запросы самостоятельно, и будет только направлять их к серверам определенных с forwarders оператором.
Имеются две опции, которые мы не будем описывать здесь, это sortlist и domain. Дополнительно, имеются две директивы, которые могут использоваться внутри zone файлов базы данных. Это - $INCLUDE и $ORIGIN. Так как они редко когда понадобятся, то мы не будем описывать их здесь.
Файл шифров CHAP
Когда это должно опознать себя с некоторым сервером, используя CHAP, рppd ищет файл шифров PAP для записи с клиентской областью равной локальному hostname, и области сервера равной к remote hostname посланный в CHAP Challenge. При требовании peer к опознаванию себя, роли просто поменялись: pppd будет затем искать запись с клиентской областью приравненной к отдаленному hostname (посланный в CHAP ответ клиенту) и область сервера приравненной локальному хосту.
Следующее - типовой файл шифров chap для vlager: (9)
# CHAP secrets for vlager.vbrew.com # # client server secret addrs #------------------------------------------------------------------- --- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com * vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com
При установлении PPP связи с c3po, c3po запрашивает vlager опознать себя, используя CHAP, посылая CHAP challenge. Pppd затем просматривает chap шифры для записи с клиентской областью, приравненой к vlager.vbrew.com и областью сервера приравненной к c3po.lucas.com, (10) и находит первую линию, показанную выше. Затем производится CHAP ответ от challenge string и шифра (Используйте Источник Luke), и посылает от c3po.
В то же самое время, pppd составляет CHAP challenge для c3po, содержащую уникальную challenge string, и пплноутью квалифицированный hostname vlager.vbrew.com. C3po создает CHAP ответ способом, который мы только что обсудили, и возвращает это к vlager. Pppd теперь извлекает клиентский hostname (c3po.vbrew.com) из ответа, и поисков файлов шифра chap для линии, соответствующей c3po как клиент, и vlager как сервер. Вторая линия делает так что pppd объединяет CHAP challe pasteve, шифрует их, и сравнивает результат с с3po CHAР ответа.
Произвольная четвертая область перечисляет адреса IP, которые являются для клиентуры, именованной в первой области. Адреса могут быть даны в dotted quad notation или как hostnames, которые разысксканы с помощью решающего устройства. Например, если запрос c3po, на использование IP адреса во время IPCP переговора, который не в этом списке, запрос будет отклонен, и IPCP будет выключено. В типовойфайле, показанном выше, с3po следовательно будет ограничен использованием собств Если область адреса пуста, любые адреса будут позволяться, значение которых - предотвращает использование IP с клиентом.
Третья линия в примере файле шифров chap позволяет любому хосту установить связь PPP с vlager потому что клиент или область сервера соответствует hostname. Единственое требование - то, что он знает пароль, и использует адрес pub.vbrew.com. Вход с групповым символом hostnames может появится где-нибудь в файле шифров, так как pppd будет всегда использовать наиболее специфическую запись, которая применяется к паре сервера / клиента.
9. Двойные кавычки - не часть пароля, они просто служат для того, чтобы защитить незаполненное пространство внутри пароля. 10. Этот hostname принимается из CHAP challenge.
Имеются некоторые слова, которые нужно упоминуть относительно способа, которым pppd достигает hostnames: он ищет в файле шифров. Как было объяснено прежде, отдаленный hostncme всегда обеспечивается peer в CHAP Challenge или в Response packet. Локальный hostname будет получен, если вызвать gethostname функцию (2) по умолчанию. Если Вы установили название системы Вашему неквалифицированному hostname, то Вы должны обеспечить его pppd областью.
# pppd ...domain vbrew.com
Это конкатенирует название Brewery области к vlager для всех установленых подлинностью действия. Другие опции, которые модифицируют progpppd's idea относительно локального hostname - usehostname и name. Когда Вы даете локальный IP адрес на командной строке, использующей "local:varremote", и local - название вместо dotted quad, pppd использует это как локальный hostname. Для деталей, пожалуйста обратитеськ pppd странице справочника (8).
Файл шифров PAP.
Файл шифров PAP очень похожа на тот, который используется CHAP. Сначала две области всегда содержат название пользователя и название сервера; третья часть задерживает шифр PAP. Когда remote посылает опознающийся запрос, рppd использует запись, которая имеет область сервера равной локальному hostname, и область пользователя приравненной к имени пользователя, посланному в запросе. Когда опознание себя с peer произойдет, pppd выберет шифр, который будет послан из линии с область приравненной к локальному имени пользователя, и областью сервера приравненной к remote hostname.
Типовой файл шифров PAP мог бы выглядить следующим образом:
# /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com
Первая линия используется для того, чтобы опознать нас когда мы говорим с с3ро.
Вторая линия описывает, как пользователь именнованняй c3po, должен быть опознаным непосредственно с нами.
Имя vlager-pap в столбце, который является именем пользователя, мы посылаем к c3po. По умолчанию, pppd выберет локальный hostname как имя пользователя, но Вы можете также определить различные названия, давая опцию пользователя, сопровождаемую эти именем.
При выборе записи из файла шифров PAP регистрируются для установления подлинности с peer, pppd должен знать название remote хоста. Поскольку это не имеет способа нахождения того, что Вы должны точно определить на этой командной строке, используяе remotename ключевого слова, сопровождаемого hostname peer. Для образца, как использовать вышеупомянутую запись для установления подлинности с c3po, мы добавляем опцию следования к командной строке pppd's:
\#{} pppd ... remotename c3po user vlager-pap
В четвертой области (и все следующие области), Вы можете точно определить какие адреса IP разрешены для того частного множества, точно как и в файле шифров CHAP. Peer может затем только запроситьь адреса из этого списка. В типовом файле, мы требуем, чтобы c3po использовал реальный адрес IP.
Заметьте, что PAP довольно слабый опознавательный метод, и это предполагает всякий раз, когда Вы используете CHAP, если это возможно. Мы не будем следовательно описывать PAP в деталях здесь; если Вы заинтересованы в использовании PAP, Вы найдете несколько больше в pppd странице справочника (8).
Файлы Конфигурации --- Краткий обзор
Традиционный sendmail установлен через файл конфигурации системы (обычно /etc/sendmail.cf или /usr/lib/sendmail.cf), который - не относится к любому языку, который вы видели прежде. Редактирование sendmail.cf файла, чтобы обеспечить настроенное поведение может быть хорошим опытом.
Sendmail + IDA делает такую работу по существу делом прошлого при наличии всех опций конфигурации, с формированием изображений при помощи таблицы с довольно простым, чтобы понять синтаксис. Эти опции конфигурируются, выполнением m4 (процессора макркоманд) или dbm (процессора базы данных) в ряде файлов данных через Make-файлы, обеспеченные исходниками. Sendmail.cf файл определяет только заданное по умолчанию поведение системы. Виртуально вся специальная настройка выполнена через ряд необязательных таблиц а не непосредственно редактируя sendmail.cf файл.
Файлы Конфигурации UUCP
В отличие от более простых программ передачи файлов, UUCP был разработан, чтобы обрабатывать все передачи автоматически.Если только все установлено правильно, ежедневное вмешательство администратора не необходимо.Вся необходимая информация сохраняется в паре файлов конфигурации, которые постоянно находятся в каталоге /usr/lib/uucp. Большинство этих файлов используется только при запросе снаружи.
