Установка sendmail
В этом разделе, мы рассмотрим как установить типичное двоичное распределение sendmail + IDA, и что должно быть выполнено, чтобы сделать его локализованным и функциональным. Текущее двоичное распределение sendmail + IDA для Linux может быть получено из sunsite.unc.edu в /pub/Linux/system/Mail. Даже если Вы имеете более раннюю версию sendmail, я строго рекомендую, чтобы Вы использовали sendmail5.67b + IDA1.5. Если Вы формируете sendmail из исходников, Вы должны следовать советам в README, включенном в исходное распределение. Текущие исходники sendmail + IDA доступны из vixen.cso.uiuc.edu. Чтобы формировать sendmail + IDA на Linux, Вы также нуждаетесь в Linux -специфических файлах конфигурации из newspak-2.2.tar.gz, который является доступным на sun- site.unc.edu в каталоге /pub/Linux/system/Mail. Если Вы предварительно установили smail или другое средство получения почты, вам возможно нужно удалить (или переименовать) все файлы из smail для безопасности.
Установки для локальной сети
Если Вы имеете пункт с двумя или больше главными ЭВМ, соединенными локальной сетью (LAN), Вы будете должны обозначить один host, который обрабатывает ваше UUCP соединение со внешним миром. Представте, что мы снова на Виртуальном Пивоваренном заводе, и vstout установлен как UUCP ворота. В среде с сетевой структурой, самое лучшее хранить пользовательские mailbox на одиночной файловой системе, которая nfs- связана со всеми главными ЭВМ. Это позволяет пользователям двигаться от машины до машины, без необходимости перемещать их почту (или даже хуже, проверять приблизительно три или четыре машины для недавно прибытой почты каждое утро). Следовательно, Вы также хотите делать адреса отправителя независимыми от машины. Общая практика - использовать область, как адрес отправителя, вместо hostname. Janet, например, определил бы janet@vbrew.com вместо janet@vale.vbrew.com. Мы объясним ниже, как заставить сервер распознать имя области как допустимое имя для вашего пункта. Другой способ хранения всех mailbox на центральном host состоит в том, чтобы использовать POP или IMAP. POP замещает Протокол Почтового отделения и допускает пользователей, обращаться к их mailbox по TCP/IP. IMAP, интерактивный Протокол Доступа Почты подобен POP, но более общий. И клиентура и серверы для IMAP и POP была пренесена на Linux, и доступна из sunsite.unc.edu ниже /pub/Linux/system/Network.
Установление подлинности с PPP..CHAP против PAP
С PPP, каждая система может требовать, чтобы peer опознал себя используя однин из двух опознавательных протоколов. Они - (PAP), и (CHAP). Когда связь установлена, каждый может запросить другой, чтобы опознать себя, независимо от того, является ли это caller или callee. Ниже я буду говорить о "клиенте " и " сервере " когда я захочу сделать различие между системой опознания и authenticator. PPP daemon может спрашивать peer отно подлинности, посылая однако другой LCP запрос конфигурации, опознавающий желаемый протокол.
PAP в основном работает в том же самом способ как нормальная процедура входа в систему. Клиент опознает себя, посылая имя пользователя и пароль ксерверу, который сравнивается с базой данных секретов. Этот метод легкоуязвим к eavesdroppers, который может попытаться получить пароль, слушая последовательную линию, и к повторению испытания и решения ошибки.
CHAP не имеет этих недостатков. С CHAP, authenticator (то есть сервер) посылает беспорядочно сгенерированную " challenge'' строку к клиенту, наряду с hostname. Клиент использует hostname для того, чтобы искать соответствующий шифр, объединяя это с challenge, и шифруя строку, используя однонаправленную hashing function. Результат будет возвращен на сервер наряду с hostname клиента. Сервер теперь выполняет то же самое вычисление, и подтверждает клиента.
Другая особенность CHAP - то, что он не требуется опознания клиента для опознания самого себя при запуске, но посылает challenges в определенные промежутки времени, чтобы удостовериться не был клиент заменен "злоумяшлепником ", например, только переключая телефонные линии.
Pppd хранит секретные ключи для CHAP и PAP в двух отдельных файлах, вназываемых /etc/ppp/chap-secrets и pap-secrets соответственно. Входом отдаленного хоста в один или другой файл, Вы имеете хороший контроль над CHAP или PAP предназначенный для этого, чтобы опознать нас с нашим peer, и наоборот.
По умолчанию, pppd не требует установления подлинности от remote, но соглашается опознавать себя когда запрошено remote. Так как CHAP намного более сильна чем PAP, pppd пробует использовать вышеупомянутый всякий раз, когда это возможно. Если peer этого не поддерживает, или если pppd не может найти CHAP шифр для remote системы в файле шифров chap, он возвращается к PAP. Если он имеет PAP шифр для peer также, то он откажется опознавать в целом, и как следствие, связь закроется.
Это поведение может быть изменено отдельными способами. Например, когда дается auth ключевое слово, pppd требует, чтобы peer опознал сам себя. Pppd согласится использовать или CHAP или PAP для этого, как только это будет имеет шифр для peer в CHAP или в базе данных PAP соответственно. Имеются другие опции, чтобы включить или выключить частный опознавательный протокол, но я не буду описывать их здесь. Пожалуйста обратитесь к pppd (8) для деталей.
Если все системы, с которыми Вы говорите PPP, соглашаются опознавать самих себя с Вами, Вы должны поместить опцию auth в глобальный файл /etc/ppp/options и определить пароли для каждой системы в файле шифров chap. Если система не поддерживает CHAP, добавьте запись к файлу pap шифров. Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом.
Следующие два раздела обсуждают два PPP файла шифров, pap- secrets и chap-secrets. Они размещзны "в /etc/ppp и содержат тройки клиентуры, серверов и паролей, необязательно сопровождаемых списком из адресов IP. Интерпретация клиента и областей сервера отлична для CHAP или PAP, и также зависит от того, опознаем ли мы себя самостоятельно с peer, или потребуем опознать сервер непосредственно с нами.
Устаревшие Новости
В Bnews, устаревание выполняться программой называемой expire, которая принимает список newsgroups как аргументы, наряду с спецификацией времени после которого статьи должны устареть. Иногда, Вы можете хотеть сохранять статьи из некоторых групп даже после того, как они устарели; например, Вы могли бы хотеть сохранить программы, зарегистрированные в comp.sources.unix. Это называется архивирование. Explist разрешает Вам отмечать группы для архивирования. Вход в explist похож на это:
grouplist perm times archive
Grouplist - отделенный запятой список newsgroups, к которым вход применяется. Иерархии могут быть определены префиксом имени группы, необязательно конкатенированным ко всем. Например, для входа, обращающегося к всем группам ниже comp.os, Вы могли бы вводить comp.os или comp.os.all в grouplist. При устаревании новости из группы, имя будет проверено против всех входов в explist в данном порядке. Первый соответствующий вход применяется. Например, чтобы отбросить большую часть comp после четырех дней, кроме comp.os.linux.announce, который Вы хотите хранить в течение недели, Вы просто должны иметь вход для последнего, который определяет семи-дневный период окончания, сопровождаемый входом для comp, который определяет четыре дня. Поле perm детализирует, если вход применяется к уменьшенной, или любой группе. Оно может принимать значения m, u, или x, которые обозначают уменьшенный, неуменьшенный, или любой тип. Третье поле, times, обычно содержит только одиночное число. Это - число дней после которых статьи будут устаревать, если они не были назначены, искусственная дата окончания в поле Expires в заголовке статьи. Обратите внимание, что это - число дней подсчитывается с поступления в ваш пункт, а не с даты регистрации. Поле times может, однако, быть более сложно. Это может быть комбинация до трех чисел, отделяемых от друг друга черточкой. Первое обозначает число дней, которые должны пройти прежде, чем статья рассматривается кандидатом на окончание. Редко полезно использовать значение отличное от нуля. Второе поле - вышеупомянутое заданное по умолчанию число дней после, которых оно будет устаревать. Третья часть - число дней после которых статья будет устаревать безоговорочно, независимо от того, имеет ли она поле Expires или нет. Если только среднее число дано, другие два берут значения по умолчанию. Они могут быть определены, используя специальный /bounds/ входа, который описан ниже. Четвертое поле, archive, обозначает, должен ли newsgroup быть заархивирован, и где. Если никакого архивирования не предназначено, должна использоваться черточка. Иначе, Вы либо используете полное имя пути (указывающее на каталог), или знак (@). Знак обозначает заданный по умолчанию каталог архивов, который должен то быть дан doexpire, используя -a флаг в командной строке. Каталог архивов должен принадлежать news. Когда doexpire архивирует статью из, скажем comp.sources.unix, он сохраняет ее в каталоге comp/sources/unix ниже каталога архивов, создавая его если он не существует. Каталог архивов непосредственно, однако, не будет создан. Имеются два специальных входа в вашем explist файле, на который doexpire полагается. Вместо списка newsgroups, они имеют ключевые слова /bounds/ и /expired/. Вход /bounds/ содержит значения по умолчанию для трех значений поля времен, описанного выше. Поле /expired/ определяет, как долго C News будет содержать строки в файле хронологии. Это необходимо, потому что C News не будет удалять строку из файла хронологии, если соответствующая статья устарела, но будет содержать ее в случае, если дубликат должен прибыть после этой даты. Простой explist файл с довольно плотными интервалами истечения воспроизведен ниже:
# keep history lines for two weeks. Nobody gets more than three months /expired/ x 14 - /bounds/ x 0-1-90 - # groups we want to keep longer than the rest comp.os.linux.announce m 10 - comp.os.linux x 5 - alt.folklore.computers u 10 - rec.humor.oracle m 10 - soc.feminism m 10 - # Archive *.sources groups comp.sources,alt.sources x 5 @ # defaults for tech groups comp,sci x 7 - # enough for a long weekend misc,talk x 4 - # throw away junk quickly junk x 1 - # control messages are of scant interest, too control x 1 - # catch-all entry for the rest of it all x 2 -
С устареванием в C News, имеется ряд потенциальных проблем при чистке. Например, ваш newsreader мог бы полагаться на третье поле файла active, который содержит число самой низкой интерактивной статьи. При истечении статьи, C News не модифицирует это поле. Если Вы хотите чтобы это поле, представляло реальную ситуацию, Вы должны выполнить программу, называемую updatemiin после каждого выполнения doexpire.
| |
Устройства, драйвера, и все это
До сих пор, мы весьма немного говорили относительно сетевых интерфейсов и общих проблем TCP/IP, но не говорили о том, что происходит, когда "сетевой код" в ядре обращается к аппаратным средствам. Для этого, мы должны немного поговорить о концепциях интерфейсов и драйверов.
Во-первых, конечно, имеются непосредственно аппаратные средства, например Ethernet карта: пластина из эпоксидной смолы, утыканная большим количеством крошечных чипов с глупыми номерами на них, и воткнутая в слот вашего PC. Это - то что мы обычно называем устройством.
Для того чтобы использовать Ethernet карту, необходимы специальные функции, расположенные в ядре вашего Linux, которые знают как работать с этим устройством. Это так называемые драйвера устройств. Например, Linux имеет драйвера устройства для нескольких марок Ethernet плат которые очень похожи по выполняемым функциям. Они известны как "Becker Series Drivers" ,и называются так по имени их автора, Donald Becker. Другой пример - D-link драйвер, который работает с адаптером D-link пакетов, присоединяемым к параллельному порту.
Но, что мы подразумиваем, когда говорим что драйвер "управляет" устройством? Давайте вернемся к Ethernet плата, которую мы уже упоминали. Драйвер должен быть способен работать с переферией этой платы: он должен посылать команды и данные плате, в то время как плата должна передать полученные данные драйверу.
В PC, эта связь устанавливается через область памяти ввода-вывода которая является отображением регистров платы и т.п. Все команды и данные которые ядро посылает плате проходят через эти регистраторы. Память ввода-вывода описывается указанием начального(или основного) адреса Типичные основные адреса для Ethernet плат 0x300, или 0x360.
Обычно, Вы не должны волноваться относительно проблем аппаратных средств, типа основного адреса, потому что ядро делает попытку во время загрузки обнаружить местоположение платы. Это называется autoprobing(автоматический поиск), который означает что ядро во время загрузки считывает несколько участков памяти и сравнивает считанные данные с тем, что должны быть, если установлена Ethernet. Однако, существуют Ethernet платы, которые ядро не может автоматически обнаружить; это часто случается с дешевыми Ethernet картами.
Также, во время загрузки, ядро будет пытаться обнаружить только одно Ethernet устройство. Если вы используете больше чем одну плату, Вы должны явно сообщить ядру об этой плате.
Другой параметр, который Вы могли бы сообщить ядру -- interrupt request channel (канал прерывания запроса). Компоненты аппаратных средств обычно прерывают ядро когда они нуждаются во внимании, например когда прибыли данные, или произошли другие события. В PC, прерывание может происходить на одном из 15 каналов (0, 1, 3 и до 15). Номер прерывания назначенный компоненту аппаратных средств называется interrupt request channel или IRQ.
Как описано в главе 3., ядро обращается к устройствам через так называемый интерфейс. Интерфейсы предлагают абстрактный набор функций, которые являются стандартными для всех типов аппаратных средств, типа посылки или получения дэйтаграм.
Интерфейсы идентифицируются посредством имен. Эти имена определенны внутри ядра, это не файлы устройств в директории /dev. Типичные имена для интерфейсов Ethernet. - eth0, eth1, и т.д. Назначение интерфейсов для определенных устройств обычно зависит от способа, которым устройства конфигурированы; например первая установленная Ethernet плата станет eth0, следующая -- eth1, и так далее. Исключение из этого правила - SLIP интерфейсы, которые назначаются динамически; То есть всякий раз, когда устанавливается SLIP связь, последовательному порту назначается интерфейс
Картинка пробует показать связь между аппаратными средствами, драйверами устройств и интерфейсами.
Во время загрузки, ядро показывает какие устройства обнаружены, и какому какой интерфейс будет установлен. Фрагмент типичного экрана загрузки:
This processor honours the WP bit even when in supervisor mode. Good. Floppy drive(s): fd0 is 1.44M Swansea University Computer Society NET3.010 IP Protocols: ICMP, UDP, TCP PPP: version 0.2.1 (4 channels) OPTIMIZE FLAGS TCP compression code copyright 1989 Regents of the University of California PPP line discipline registered. SLIP: version 0.7.5 (4 channels) CSLIP: code copyright 1989 Regents of the University of California dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95 Checking 386/387 coupling... Ok, fpu using exception 16 error reporting. Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994
Здесь показано что ядро компилировалось с TCP/IP, и с драйверами для SLIP, CSLIP, и PPP. Третья строка c низу сообщает, что был обнаружен адаптер d-link, и он установился как интерфейс dl0. Если Вы имеете Ethernet карту, ядро обычно печатает строку, начинающуюся с eth0, и сопровождаемую типом обнаруженной карты. Если Вы имеете Ethernet карту, но не увидели это сообщение, это означает что ядро неспособно обнаружить вашу плату. Об этом мы поговорим позже.
UUCP поверх TCP
В первый момент это может показаться абсурдом,но на самом деле UUCP поверх TCP не такая уж плохая идея, особенно при пересылке большого количества данных типа Usenet новостей. На TCP -базированных узлах, новостями в основном обмениваются, используя NNTP протокол, в котором статьи запрашиваются и посылаются индивидуально, без сжатия и прочей оптимизации. Хотя и подходящая для больших узлов с большим объемом новостей (newsfeeds), эта методика не подходит для небольших участков сети, которые получают новости медленным соединением типа ISDN. Им удобней объединить качества TCP с преимуществами посылки новостей в больших пакетах, которые могут быть сжаты и таким образом перемещаться с очень низкими затратами. Станжартпый способ передать эти пакеты состоит в том, чтобы использовать UUCP поверх TCP. В файле sys, Вы определяете систему, которую нужно вызвать через TCP.
10. Вы также можете сконфигурировать модемы на сброс при обнаружении перехода на DTR. Некоторые из них, однако, не понимают таких вещей и зависают.
system gmu address news.groucho.edu time Any port tcp-conn chat ogin: vstout word: clouseau
Команда address дает адрес IP главной ЭВМ, или ее полное имя области(domain name). Соответствующий участок файла port выглядел бы:
port tcp-conn type tcp service 540
Этот пример говорит, что соединение TCP должно использоваться, когда файл sys ссылается на tcp-conn, и что uucico должен пытаться соединяться с портом TCP Э 540 на удаленной ЭВМ. Это - заданный по умолчанию номер порта обслуживания UUCP. Вместо номера порта, Вы можете также давать символическое имя порта командой service . Номер порта, соответствующий этому имени будет разыскскан в /etc/services. Общее имя для UUCP-сервиса - uucpd.
UUCP Протоколы низкого уровня
Чтобы осуществлять контроль за приемом и передачей файлов, uucico кспользует набор стандартизированных сообщений. Этот набор иначе называется протоколом верхнего уровня. В течение фазы инициализации и фазы зависания они просто посланы поперек как строки. Однако, в течение реальной фазы передачи, дополнительный протокол низкого уровня использован, который является обычно ясным для более высоких(высших) уровней. Это должно делать проверки ошибки, возможные при использовании ненадежных линий, например.
UUCP сети.
UUCP (Unix-to-Unix copy) начинался как пакет программ для пересылки файлов через последовательные линии, управления этой пересылкой и выполнения программ на удаленной машине. Он претерпел большие изменения с тех пор как был впервые предложен в конце семидесятых, но до сих пор по спартански простой по. Его основные приложения до сих пор базируются на телефонных линиях.
UUCP впервые был предложен Bell лабораториями в 1977 году для связи между их Unix участками. В середине 1978 г. эта сеть объединяла уже 80 машин. Она позволяла использовать электронную почту и удаленную печать. Сегодня UUCP не ограничивается только Unix средами. Существует масса как коммерческих так и бесплатных переносов данного протокола на другие платформы, включая AmigoOS, DOS, Atari's TOS, и другие.
Один из главных недостатков UUCP сетей -- их низкая пропускная способность. С одной стороны, телефонное оборудование устанавливает жесткий предел на максимальную скорость передачи. С другой стороны, UUCP соединение -- редко постоянная связь; где хосты соединяются друг с другом через определенный интервал. Следовательно, наибольшее количество времени при передаче почты через UUCP она просто лежит на диске некоторого хоста, обживающего установления следующего сеанса связи.
Несмотря на эти ограничения, имеется большое количество UUCP сетей, работающих во всем мире главным образом под управлением энтузиастов, которые предлагают частный доступ к сети за разумные цены. Главная причина популярности UUCP в том, что это очень дешево по сравнению с наличием компьютера, связанного кабелем с Intеrnet. Чтобы сделать ваш компьютер UUCP узлом, все в чем Вы нуждаетесь это модем, работающее UUCP программное обеспечение и другой UUCP узел, который будет снабжать Вас почтой и новостями.
UUCP-Транспорт
Имеется ряд транспортировщиков, компилируемых в smail, которые используют UUCP набор программ. В UUCP среде, сообщения обычно передаются, вызывая rmail на следующем host, давая ему сообщение на стандартном вводе и адрес конверта в командной строке. На вашем host, rmail должен быть связан с командой smail. При вручении сообщения на UUCP транспорт, smail преобразовывает целевой адрес в путь удара UUCP. Например, user@host будет преобразован host!user. Любое местонахождение " % " оператора адреса сохраняется, так что user%host@gateway станет gateway!User%host. Однако, smail никогда не будет генерировать такие адреса самостоятельно. В качестве альтернативы, smail может посылать и получать BSMTP пакеты через UUCP. В BSMTP один или большее количество сообщений передаются в одиночном пакете, который содержит команды, которые локальный mailer выдал бы, если бы реальное SMTP соединение имело место. BSMTP часто используется с промежуточным накоплением, чтобы сохранить дисковое пространство. Типовой файл транспорта в приложении 20.3 содержит транспорт dubbed bsmtp который генерирует частичные BSMTP пакеты в каталоге очередей. Они должны быть объединены в конечные пакеты позже, при использовании команды оболочки, которая добавляет соответствующую команду HELO и QUIT. Чтобы давать возможность bsmtp транспорту для специфических связей UUCP, Вы должны использовать так называемые файлы метода (пожалуйста обратитесь к smail странице руководства для подробностей). Если Вы имеете только одну связь UUCP, и используете программу маршрутизации smart host, Вы даете возможность посылать SMTP пакеты, устанавливая интеллектуальную транспортную переменную конфигурации как bsmtp вместо uux. Чтобы получать SMTP пакеты над UUCP, Вы должны удостовериться, что Вы имеете команду распакетирования. Если отдаленный пункт использует smail, Вы должны связать rsmtp с smail. Если отдаленный пункт выполняет sendmail, Вы должны дополнительно установить команду оболочки, именованную /usr/bin/bsmtp, которая делает простой "запуск rsmtp".
UUCP Установки
Чтобы использовать smail в uucp среде, базисная установка довольно проста. Сначала, Вы должны удостовериться, что Вы имеете две символических связи к rmail и sendmail, упомянутому выше. Если Вы ожидаете получать SMTP пакеты от другого абонента, Вы также должны сделать rsmtp связь к smail. В smail распределении Vince Skahan, Вы найдете типовой файл конфигурации. Он называется config.sample и постоянно находится в /usr/lib/smail. Вы должны копировать его в конфигурации и редактировать его, чтобы отразить значения, специфические для вашего пункта. Примите, что ваш пункт именован swim .tobirds.com, и зарегистрирован в картах UUCP как swim. Ваш smarthost - ulysses. Тогда ваш файл конфигурации должен выглядеть следующим образом: # # Our domain names visible domain=two.birds:uucp # # Our name on outgoing mails visible name=swim.twobirds.com # # Use this as uucp-name as well uucp name=swim.twobirds.com # # Our smarthost smart host=ulysses Первое утверждение сообщает smail относительно областей, которым ваш пункт принадлежит. Вставьте их имена здесь, отделяемые двоеточиями. Если ваше имя пункта зарегистрировано в картах UUCP, Вы должен также добавить uucp.
При отправке(получении) сообщения почты, smail определяет имя вашего host, используя hostname системный вызов (2), и проверяет адрес получателя для этого hostname. Если адрес соответствует одному из имен, или неквалифицированному hostname, получатель, рассматривается локальным, и smail пытается передавать сообщение пользователю. Видимое имя должно содержать одиночное, полностью квалифицированное имя области вашего пункта, которое Вы хотите использовать при выходе почты. Это имя используется при производстве адреса отправителя для всей почты. Вы должны удостовериться, чтобы использовать имя, которое smail распознает относительно локального host (то есть hostname с одной из областей, перечисленных в атрибуте области). Последнее утверждение устанавливает путь, используемый для маршрутизации smart-host (описанный в разделе 14.4). С этой типовой установкой, smail будет передавать любую почту для отдаленных адресов интеллектуальному host. Путь, заданный в интеллектуальном атрибуте пути будет использоваться как маршрут до интеллектуального host. Так как сообщения будут передан через UUCP, атрибут должен определить систему, известную вашему UUCP программному обеспечению. Пожалуйста обратитесь к главе 13. При создании пункта, известного UUCP. Имеется одна опция, используемая в вышеупомянутом файле, который мы не объяснили; это - имя uucp. Причина использовать опцию: По умолчанию, smail использует значение, возвращенное hostname (2) для uucp-специфических вещей типа возвращающегося пути, данного в строке From заголовка. Если ваш hostname не зарегистрирован в UUCP проекте, Вы должен сообщить, чтобы smail использовал взамен ваше полностью квалифицированное имя области. Это может быть выполнено, добавлением опции имени uucp к файлу конфигурации. Имеется другой файл в /usr/lib/smail, называемый paths.sample. Это - пример файла путей. Однако, Вы не будете нуждаться в нем, если Вы не имеете связей почты больше чем к одному пункту. Если нет, Вы будете должны написать один непосредственно, или генерировать один из карт Usenet. Файл путей будет описан позже в этой главе.
| |
Uucp-зависимые Аспекты
define(UUCPNAME, vstout)dnl # our uucp name define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors define(BANGIMPLIESUUCP)dnl # make certain that uucp define(BANGONLYUUCP)dnl # mail is treated correctly Часто, системы известны под одним именем для целей DNS и другим для целей UUCP. UUCPNAME разрешает Вам определять различные hostname, которые появляются в заголовках выхода почты UUCP. UUCPNODES определяет команды, которые возвращают список hostnames для систем, с которыми мы соединены непосредственно с через UUCP соединения. BANGIMPLIESUUCP и BANGONLYUUCP гарантирует, что почта, адресованная с UUCP синтаксисом обрабатывается согласно UUCP, а не более современному DNS, используемому сегодня в Internet.
Uucpxtable
Обычно, почта на главные ЭВМ с полностью квалифицированными именами области передается в стиле Internet (SMTP), используя Domain Name Service (DNS), или через relay host. Uucpxtable вынуждает получение через маршрутизацию UUCP, преобразуя имя в отдаленный hostname UUCP-стиля.
Это часто используется, когда ваш узел служит для продвижения данных почты для пункта или области или когда Вы желаете послать почту через прямую и надежную связь UUCP, а не через множество абонентов через заданный по умолчанию mailer и любые промежуточные системы и сети. Абоненты UUCP, которые разговаривают с соседями по UUCP, которые используют заголовки почты с определенным именем области, использовали бы этот файл, чтобы вынудить получение почты через прямую UUCP двухточечную связь между двумя системами, а не использовали бы менее прямой маршрут через RELAY MAILER и RELAY HOST или через DEFAULT MAILER. Абонент Internet, который не входит в UUCP может не использовать uucpxtable. Предположите, что Вы обеспечиваете обслуживание пересылки почты к системе, называемой sesame.com в DNS и sesame в картах UUCP. Вы нуждались бы в следующем входе uucpxtable, чтобы вынудить почту для их host пройти через ваше прямое соединение UUCP.
#============== /usr/local/lib/mail/uucpxtable ============ # Mail sent to joe@sesame.com is rewritten to sesame!joe and # therefore delivered via UUCP # sesame sesame.com # #----------------------------------------------------------
Внутренние работы uucico
Чтобы понять, почему uucico должен знать некоторые вещи, приведем быстрое описание того, как фактически происходит соединение с удаленной системой. Когда Вы выполняете uucico -s система из командной строки, сначала происходит физическое соединение.Принимаемые действия зависят от типа открываемого соединения. Например, при использовании телефонной линии, она должна найти модем, и набрать номер.Если используется TCP, uucico должна вызвать функцию gethostbyname (3), чтобы преобразовать имя в сетевой адрес, выяснить, какой порт открывать, и связать адрес с соответствующим гнездом(socket). После того, как соединение было установлено, должна выполниться процедура идентификации пользователя. Она состоит из запроса удаленной системой, имени, и, возможно, пароля.Все это называется "login chat". Процедура идентификации выполняется или обычным getty/login набором программ, или - на гнездах TCP - непосредственно uucico . Если разрешение на вход получено, удаленная систзма запускает uucico. Локальная копия uucico, которая инициализировала соединение, назначается главной, удаленная - подчиненной. Затем следует фаза рукопожатия(handshake phase): главный посылает cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли hostname право входить в неё, посылать и принимать файлы, и т.д.. Флаги описывают (кроме всего прочего) максимальный приоритет буферизации передаваемых файлов. Если возможно, счет диалога, или проверка порядкового номера обращения происходит здесь. Благодаря этой возможностью, оба поддерживают счет успешных соединений, которые сравниваются. Если они не соответствуют, рукопожатиe прерывается. Это помогает защищать себя от самозванцев. В заключение, uucico пытаеться установить общий протокол передачи. Этот протокол обеспечивает способ перемещения данных, проверку на непротиворечивость, и повторную передачу в случае ошибки. Имеется потребность в различных протоколах из-за отличающихся типов обеспечиваемых соединений. Например, телефонные линии требуют " безопасный " протокол, который включает в себя жестокую проверку ошибок, в то время как передача TCP по существу надежна и может использовать более эффективный протокол, который предшествует наиболее тщательной проверке ошибок.
После того,как рукопожатие устновлено,начинается фактическая фаза передачи . Обе системы включают выбранный драйвер протокола. Драйверы, возможно, выполняют свою специфическую инициализацию. Сначала главная система посылает все файлы, поставленные в очередь для передачи на удаленную систему, приоритет буферизации которых является достаточно высоким. Когда передача завершена, она сообщает об этом подчиненной системе, подчиненный может теперь отключиться или принимать диалог. Это - изменение ролей(назначений): теперь удаленная система становится главной, а локальная становится подчиненной. Новый хозяин теперь посылает файлы. Когда передача завершена, обе программы обмениваются заключительными сообщениями, и закрывают соединение. Мы не будем вникать во все детали: пожалуйста обратитесь или к исходным текстам или к любой хорошей книге об UUCP для этого.Есть также действительно старинная статья, касающаяся сети, написанной David A. Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP FAQ также обсуждает некоторые подробности UUCP. Это всегда есть на comp.mail.uucp.
Возможности Имени Области
define(PSEUDODOMAINS, BITNET UUCP)dnl # don't try DNS on these Имеются отдельные известные сети, которые обычно указаны в адресах почты по историческим причинам, но это не допустимо для целей DNS. Определение PSEUDODOMAINS предотвращает бесполезные DNS попытки поиска, которые будут всегда терпеть неудачу.
Все о ifconfig
Имеются еще несколько параметров для ifconfig, о которых мы не писали раньше. Вот полное описание:
ifconfig interface [[-net|-host] address [parameters]]
interface - название интерфейса, и address - IP адрес который требуется назначить для интерфейса. Это может быть или IP адрес в dotted quad формате , или имя, которое ifconfig будет искать в /etc/hosts и /etc/networks. -net и -host опции вынуждают ifconfig обращаться с адресом как сетевым номером или адресом хоста, соответственно.
Если ifconfig используется только с именем интерфейса, он показывает конфигурацию этого интерфейса. Когда он вызывается без параметров, он показывает все интерфейсы, которые Вы отконфигурировали; опция -a вынуждает его показать и бездействующие. Образец вывода для Ethernet интерфейса eth0 может напоминать это:
# ifconfig eth0 eth0 Link encap 10Mbps 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 0 RX packets 3136 errors 217 dropped 7 overrun 26 TX packets 1752 errors 25 dropped 0 overrun 0
MTU и Metric поля показывают текущее MTU и метрическое значение для этого интерфейса. Метрическое значение традиционно используется некоторыми операционными системами чтобы вычислить сложность маршрута. Linux не использует это значение, но определяет его для совместимости.
RX и TX линии показывают сколько пакетов были получены или переданы без ошибок, сколько произошло ошибок, сколько пакетов были потеряны, вероятно из-за нехватки памяти, и сколько были потеряны из-за переполнения. Переполнение приемника обычно случается когда пакеты ходят быстрее чем ядро может их обслужить последнее прерывание. Значения флагов, выводимые ifconfig, передают дополнительную информацию о имени и опциях командной строки; они будут объяснены ниже.
Следующий список параметров используется ifconfig с соответствующими названиями флага, данными в скобках. Опция которая просто включает некоторую особенность также позволяют выключать ее, если названию опции предшествует (-).
up Эта опция делает интерфейс доступным для IP уровня. Эта опция подразумевается, когда дается IP адрес.
( Эта опция соответствует UP RUNNING флагам)
down Она делает интерфейс недоступным IP уровню. Она эффективно отключает любое IP движение через интерфейс. Обратите Внимание, что она не удаляет все маршрутизационные записи, которые используют этот интерфейс. Если Вы постоянно выключаете некий интерфейс, Вы должны удалить эти записи предоставить, если возможно, альтернативные маршруты.
netmask mask назначает маску подсети для использования интерфейсом. здесь можно давать как любой шестнадцатиричнре число с 32 битами, которому предшествует 0x, так и dotted quad десятичные номера.
Pointopoint adress Эта опция используется для point-to-point IP соединений. Эта опция необходима чтобы отконфигурировать, например, SLIP или PLIP интерфейсы.
(Если point-to-point адрес был установлен, ifconfig показывает POINTOPOINT флаг.)
broadcast address широковещательный адрес обычно создается из сетевого номера установкой всех битов части хоста. Некоторые IP используют различную схему; эта опция помогает приспособиться к этим странным средам.
(Если broadcast address был установлен, ifconfig показывает BROADCAST флаг.)
metric number Эта опция может использоваться для назначения метрического значения записи таблицы маршрутизации созданной для интерфейса. Эта метрика используется в RIP, для построения таблиц маршрутизации. Установленным по умолчанию оно равно нулю. Если Вы не используете RIP демона, Вы не нуждаетесь в этой опции вообще; если используете, Вы редко должны будете изменять это значение.
mtu bytes Эта опция устанавливает Maximum Transmission Unit (максимальную длину передаваемого пакета) Для Ethernets, MTU по умолчанию 1500; для SLIP интерфейсов 296.
arp Это опция определенная для широковещательных сетей типа пакетного радио или Ethernet. Она позволяет использовать ARP, протокола поиска адреса, используемый для определения физического адреса хоста включенного сеть. Для широковещательных сетей, включен по умолчанию.
( Если ARP не включен, ifconfig показывает флаг NOARP. )
-arp запрещает использование ARP на этом интерфейсе.
promisc Помещает интерфейс в promiscuous состояние. В широковещательной сети, это заставляет интерфейс получать все пакеты, независимо от того были ли они предназначены для другого хоста или нет. Это позволяет , используя фильтры пакетов, анализировать сетевой трафик. Обычно, это хорошая техника охоты на сетевые проблемы которые должны иначе интенсивно прибывать. С другой стороны, это позволяет врагам исследовать движение паролей по вашей сети и делать другие черные дела. Одна защита против этого типа нападения не позволять присоединятся к вашей сети чужим компьютерам. Другая способ использовать безопасные опознавательные протоколы, типа Kerberos, или SRA login. (Эта опция соответствует флагу PROMISC.)
-promisc отказ от promiscuous способа.
allmulti Multicast адреса -- некоторый вид широковещательных адресов позволяющих обращаться к группе хостов, которые не обязательно должны быть на той же самой подсети. Multicast адреса еще не поддерживаются ядром.
( Эта опция соответствует флагу ALLMULTI. )
-allmulti отключает Multicast адреса.
Идея сетей также стара, как
Идея сетей также стара, как и вообще идея телекоммуникаций. Рассмотрим людей, живших в каменном веке, когда для обмена сообщениями между людьми использовались барабаны. Предположим пещерный человек А хочет пригласить пещерного человека Б поиграть, но тот живет слишком далеко и не может услышать барабана, в который бьет А. Каковы же могут быть действия А? Он может а) пешком добраться до Б, б) взять барабан побольше , или в) попросить В живущего на полпути между А и Б передать сообщение. Позже это стали называть сетями.
Конечно мы далеко ушли от примитивных занятий и устройств наших предков. В наши дни мы пользуемся компьютерами которые общаются между собой по большому количеству проводов, оптиковолоконных кабелей, с помощью коротких волн, и т. д. , которые позволяют легко договорится о партии в сокер. Далее, мы будем обсуждать способы и пути, с помощью которых это можно сделать.
Здесь будет описано два типа сетей: те что базируются на UUCP протоколе, и те что базируются на TCP/IP. Это комплект протоколов и программ, которые предоставляют различные способы передачи информации между компьютерами. В этой главе мы рассмотрим оба типа сетей и обсудим их основополагающие принципы.
Мы определим сеть как набор из нескольких хостов, которые могу обмениваться информацией между собой, часто подразумевая набор специализированных хостов которые позволяют обмениваться информацией всем частям сети.
Хост -- это чаще всего компьютер, но не обязательно, это может быть и Х-терминал, и сетевой интеллектуальный принтер. Небольшой набор хостов можно называть участок(site).
Связь невозможна без какого либо языка или кода. В компьютерных сетях эти языки называют протоколами(protocols). Те мне менее, здесь вам ненужно думать о протоколах как о каком-то языке на котором разговаривают, а скорее вы должны думать о сильно формализованном коде, описывающем поведение при встрече глав государств. Точно также, протоколы, используемые в компьютерных сетях, являются набором строгих правил, используемых компьютерами при обмене сообщениями друг с другом.
Из-за различного сетевого используемого транспорта, NNTP обеспечивает(предусматривает) значительно отличные подходы к обмену новостей C News. NNTP замещает " Сетевой Протокол передачи Новостей '', и неспецифический пакет программ. Различные команды позволяют клиентуре отыскивать, посылать и отправлять по почте статьи. Различие между посылкой и регистрацией - то, что последний может включать статьи с незавершенной информацией заголовка. Поиск статьи может использоваться клиентурой передачи новостей также как newsreaders. Это делает NNTP превосходным средством для обеспечения доступа к новостям для клиентуры в локальной сети. NNTP также обеспечивает активый и пассивный способы передачи новостей, которые называются " pushing " и " pulling ". Выталкивание (pushing) - в основном тоже что C News ihave/sendme протокол. Клиент предлагает статью серверу через " IHAVE ", и сервер возвращает код ответа, который указывает, имеет ли он уже статью, или если она требуется. Если так, клиент посылает статью, завершенную одиночной точкой в отдельной строке. Выталкивание новостей имеет один недостаток - это вызывает тяжелую загрузку в системе сервера, так как она должна искать в базе данных хронологий каждую одиночную статью. Противоположная методика - перемещать(pulling) новости. Клиент запрашивает список всех доступных статей из группы, которые прибыли после заданной даты. Этот запрос выполняется командой NEWNEWS. Из возвращенного списка идентичности сообщения, клиент выбирает те статьи, которые он еще не имеет, используя команду ARTICLE для каждой из них по очереди. Проблема с перемещением новостей состоит в том, что требуется плотное управление сервером, которое позволяет клиенту запрашивать группы и распределения. Например, оно должно удостовериться, что никакой конфиденциальный материал из локальных newsgroups не послан несанкционированной клиентуре. Имеется также ряд команд удобства для newsreaders, которые разрешают им отыскивать заголовок статьи и тело отдельно, или даже одиночные строки заголовка из промежутка статей. Это допускает Вам, хранить все новости относительно центрального host, со всеми пользователями сетьи, используя nntp-основанные клиентские программы для чтения и регистрации. Это - альтернатива к экспорту каталогов новостей через NFS, который описан в главе 18 .. Полная проблема NNTP состоит в том, что она позволяет хорошо осведомленному специалисту вставлять статьи в поток новостей с ложной спецификацией отправителя. Это называется новостями faking. Расширение к NNTP позволяет требовать установления подлинности пользователя для некоторых команд. Имеется ряд доступных NNTP пакетов. Один из наиболее широко известных - NNTP daemon, также известный как реализация ссылки. Первоначально, он написан Stan Barber и Phil Lapsley, чтобы иллюстрировать подробности RFC 977. Самая современная версия - nntpd-1.5.11, описана ниже. Вы можете также получить исходники и компилировать ее непосредственно. Nntpd пакет состоит из сервера и двух клиентов для перемещения и выталкивания новостей, соответственно, также как inews замены. Они живут в Bnews среде, но с небольшими дополнениями, они будут счастливы с C news, также. Однако, если Вы планируете использовать NNTP для больше чем предложения newsreaders доступа к вашему серверу новостей, реализация ссылки не есть действительно опция. Мы следовательно обсудим только NNTP daemon содержащийся в nntpd пакете, и не учтем клиентские программы.
Введение в Sendmail + IDA
Уже упоминалось, что Вы не реальный администратор системы Unix, пока вы не редактировали sendmail.cf файл. Также скажут что вы сумасшедший, если вы попытаетесь сделать это дважды :-) Sendmail - невероятно мощная программа. Также невероятно трудно узнавать и понимать ее для большинства людей. Любая программа, чье окончательное руководство (Sendmail, изданный O'Reilly and Associatеs) состоит из 792 страниц, отпугивает большинство людей. Sendmail + IDA - это другое. Это удаляет потребность редактировать всегда загадочный sendmail.cf файл и позволяет администратору определять пункт-специфическую маршрутизацию и конфигурацию адресации через относительно простые для понимания файлы поддержки, называемые таблицами. sendmail + IDA может сохранять Вам много часов работы и спокойствия. Сравниваясь с другими главными средствами транспорта почты, не имеется ничего, что не может быть выполнено быстрее и проще с sendmail + IDA. Типичные вещи, которые необходимы, чтобы реализовать UUCP или Internet узел, станут простыми для выполнения. Конфигурации, которые обычно являются чрезвычайно трудными, просто создавать и поддержать. В этой запииси, текущая версия sendmail5.67b + IDA1.5 доступен через анонимный FTP из vixen.cso.uiuc.edu. Она компилируется без любого внесения исправлений, требуемого под Linux. Все файлы конфигурации, требуемые, чтобы получить исходники sendmail + IDA, чтобы компилировать, устанавливать, и выполнять под управлением Linux включены в newspak-2.2.tar.gz, который является доступным через анонимный FTP на sunsite.unc.edu в каталоге /pub/Linux/system/Mail.
Введение в TCP/IP-сети.
TCP/IP происходит от проекта, финансируемого американским DARPA ( Оборонное Агентство Продвинутых Исследований) в 1969. Это была экспериментальная сеть, ARPANET, которая была преобразована в эксплуатационную в 1975, после того, как была доказана ее полезность.
В 1983, новый протокол TCP/IP был принят как стандарт и от все хостов в сети требовалось его использование. Когда ARPANET наконец вырос в Inetrnet (ARPANET непосредственно окончил свое существования в 1990), использование TCP/IP распространилось и на сети вне Inetrnet. Наиболее известные -- Unix локальные сети, но из-за появлении быстрого цифрового телефонного оборудования, типа ISDN, он также имеет большой шанс стать протоколом транспортировки для телефонных сетей.
Для более конкретного рассмотрения TCP/IP повсюду в следующих секциях, мы будем пользоваться как примером Groucho Marx Университетом (GMU),который расположен где-нибудь в Fredland, большинство его отделов используют собственную локальную сеть, а другие используют несколько из них. Они все связаны, и подключены к Inetrnet через единственную быстродействующую линию.
Предположите что ваш Linux связан с сетью из Unix машин в Отделе Математики, и имя вашей машины erdos. Для доступа к хосту в Отделе Физики, называемого quark, вводите следующую команду:
$ rlogin quark.physics Welcome to the Physics Department at GMU (ttyq2) login:
В приглашении Вы вводите ваше имя, скажем andres, и ваш пароль. Вам дают shell(оболочку) на quark, к которой Вы можете обращаться как будто Вы сидите за системной консолью quark. После того как Вы покинете оболочку, Вы возвращаетесь к приглашению вашей собственной машины. Сейчас Вы использовали только одно из диалоговых приложение, которые предлагает TCP/IP: remote login.
Пока вы находитесь на quark, Вы можете захотеть управлять Х11 приложением. Чтобы сказать этому приложению что Вы хотите видеть окна на экране вашего хоста, Вы должны отрегулировать среду:
$ export DISPLAY=erdos.maths: 0.0
Если Вы теперь запускаете ваше приложение, оно будет входить в контакт с вашим X-сервером вместо quark, и отображать все окна на вашем экране. Конечно, это требует наличия у вас X11. TCP/IP позволяет quark и erdos послать X11 пакеты туда и обратно создавая у вас иллюзию, что вы находитесь на удаленной системе. Сеть здесь почти прозрачна.
Другое очень важное приложение в TCP/IP сетях - NFS, расшифровывается как сетевая операционная система. Это - другая форма создания прозрачной сети, она позволяет Вам установить директории от других хостов, так, чтобы они рассматривались подобно локальным файловым системам. Например, домашние директории всех пользователей могут быть на центральной машине, от которой все другие хосты в локальной сети устанавливают требуемые директории. В результате пользователи могут войти в любую машину и находиться в той же самой домашней директории.
Так, можно устанавливать приложения которые требуют большого количества места на диске ( типа TeX ) только на одной машине, а остальные будут лишь экспортировать директории. Мы вернемся к NFS в главе 12 ..
Конечно, это не единственные примеры того, что Вы можете делать по TCP/IP сетям. Ваши возможности почти безграничны.
Теперь мы поближе познакомимся с работой TCP/IP. Вы будете нуждаться в этом чтобы понять как и почему Вы должны конфигурировать вашу машину. Мы начнем с исследования аппаратных средств, и медленно пойдем дальше.
Выбор IP адресов
В примере выше, у нау был pppd, связывающейся с c3po и устанавливающий IP связь. Никакие условия не принимались для того, чтобы выбрать частный адрес IP на любом конце связи. Взамен, мы выбрали адрес vlager's как локальный адрес IP, и позволяем c3po обеспечить себя собственным. Иногда это полезно иметь контроль над тем , какой адрес используется на одном или на другом конец связи. Pppd поддерживает отдельные разновидности этого.
Чтобы просить о частных адресах, Вы вообще обеспечиваете pppd следующеми опциями:
local addr:remote addr
Где local addr и remote addr могут быть определены или в dotted quad notation, или как hostnames.(7) Это заставит pppd попытаться использовать первый адрес как собственный адрес IP, и второй как peer. Если peer отклоняет любой из них в течение IPCP переговоров, никакая связь IP не будет установленна. (8)
Если Вы хотите установить локальный адрес, но принимаете любой адрес, который использует peer, Вы просто не учитываете remote addr part. Например, для того, чтобы vlager использовал IP адрес 130.83.4.27 вместо собственного, Вы бы дали ему 130.83.4.27: на командной строке. Подобно установки remote адресов только, Вы покинули бы локальную область адреса. Используя значение по умолчанию, pppd затем использует адрес, связанный с вашим hostname.
Некоторые PPP серверы, которые обрабатывают множество клиентов, приписывают адреса динамически: адреса назначены системам только когда существует обращение и требуются после того, как они прекратили регистрироваться снова. Когда происходит соединение с таким сервером, Вы должны удостовериться, что pppd не запрашивает какой- либо IP адрес из сервера, но когда адрес будет принят сервер попросит Вас, чтобы Вы его использовали. Это означает то, что Вы не должны определить того, Вы должны использовать опцию noipdefault, которая заставит pppd ждатю pegr, чтобы обеспечить адрес IP вместо использования адреса локального хоста.
7. Использование hostnames в этой опции имеет следствия на CHAP установления подлинности. Пожалуйста обратитесь к разделу на CHAP. 8. Вы можете позволить peer PPP отменить ваши идеи относительно IP адресов, давая pppd ipcp-accept-local и ipcp-accept-remote опции. Пожалуйста обратитесь к руководству для выяснения деталей.
Выбор правых отображений
Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы должны решить который конфигурационный файл, чтобы заменить или увеличить с NIS отображениями. Обычно, Вы захотите использовать NIS отображения для множества и функций поиска пароля. Вышеупомяну тый особенно полезен, если Вы не запускаете BIND. Последний разрешает всем пользователям зарегестрироваться на их account из любой системы в NIS области; это обычно требует разделения центрального /местного к Это объяснено подробно в разделе 11.7 ниже. Другое отображение, подобно services.byname, не такое драматическое увеличение, но сохраняют Вас
от некоторой работы редактирования, если Вы устанавливаете любые сетевые приложения которые используют сервисное название, то это не в стандартном файле услуг.
Вообще, Вы хотите иметь некоторую свободу выбора когда поиск- функция использует локальные файлы, и когда это делает запрос NIS сервера. NYS позволяет Вам сконфигурировать порядок, в котором функция обращается к этим услугам. Это управляется через картотеку /etc/nsswitch.conf, который замещает обслуживание названия, но конечно не ограничивает название обслуживание. Для любой из функций поиска данных это содержит линию, именующие услуги, чтобы использовать.
Правильный порядок услуг зависит от типа данных. Это вряд ли то, что services.byname отображение будет содержать отличие входов из тех в локальном файле услуг; это может только содержать больше. Так хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и проверять NIS только если сервисное название не было найдено. Hostname информация, с другой стороны, может изменятся пченю часто, так, чтобы DNS или NIS сервер всегда имел наиболее точный accoun файл сохран как дублиррование, если DNS и NIS терпел неудачу. В этом случае, Вы захотели бы проверить локальный последний файл.
Пример ниже показывает, как сконфигурировать gethostbyname (2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они будут перечисленны как услуги по очереди; если поиск идет хорошо, то результат будет возвращен, иначе следующее обслуживание осуждено.
# small sample /etc/nsswitch.conf # hosts: nis dns files services: files nis
Полный список услуг, которые могут использоваться с записью в Nsswitch.conf файле показыны ниже. Фактические отображения, файлы, серверы и вещи, которые делают запрос зависят от названия записи.
Nisplus или nis + использует NIS + сервер для этой области. Локализация сервера получена из картотеки /etc/nis.conf.
Nis Использует текущий NIS сервер этой области. Локализация сервера делал запрос, сконфигурированный в картотеке yp.conf как показано в предыдущем разделе. Для записи множеств, отображения Hosts.byname и hosts.byaddr делают запрос.
dns использует DNS сервер. Этот служебный тип полезен только для записи хоста. Сервера делающие запрос, все еще определяются в соответствии cо стандартом resolv.conf файла.
files использует локальный файл, такой как /etc/hosts файл для хост записи.
dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя, используемое для файла - соответствующего NIS отображение.
В настоящее время, NYS поддерживает следующие nsswitch.conf записи: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, и др. Другие записи возможно могут быть добавленны.
Рисунок 11.6 показывает более полный пример, который демонстрирует другую &осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS или в DNS база данных. То есть NYS продолжит искать локальные файлы, только если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой причине. Локальные файлы будут затем только использоваться при начальной загрузке и как backup, когда NIS сервер выключен.
Выбор Специфических Протоколов
Не каждая реализация uucico понимает каждый протокол, так что в течение начальной фазы рукопожатия, оба процесса должны договориться об общем протоколе.Главный uucico предлагает подчиненому список обеспечиваемых протоколов, посылая Pprotlist, из#которого подчиненный может выбирать. Основываясь на типе используемого порта (модем, TCP, или прямой), uucico составит заданный по умолчанию список из протоколов. Для модема и прямых соединений, этот список обычно включает i, a, g, G, j и f. Для соединений TCP, список - t, e, я, a, перегрузка, G, j, и f. Вы можете изменить этот заданный по умолчанию список командой protocols, которая может быть определена во входе системы также как входе порта. Например, Вы могли бы записать в файл port примерно следующее:
port serial1 protocols igG
Это требует любого входящего или исходящего соединения через этот порт, чтобы использовать i,g, или G., если удаленная система не поддерживает никакой из них, диалог потерпит неудачу.
Выполнение команд
Задача UUCP состоит в том, чтобы копировать файлы от одной системы к другой, и запрашивать выполнение некоторых команд на удаленных главных ЭВМ. Конечно, Вы как администратор хотите управлять тем, какие права Вы предоставляете другим системам - разрешать им делать что угодно - определенно не очень хорошая идея. По умолчанию Taylor UUCP разрешает выполняьь на вашей машине лишь rmail и rnews, которые обычно используются для email и Usent новостей над UUCP. Заданный по умолчанию путь поиска, используемый uuxqt - опция времени компиляции, но обычно содержит /bin,/usr/bin, и /usr/local/bin. Чтобы изменять набор команд для определенной системы, Вы можете использовать ключевое слово commands в файле sys. Аналогично, путь поиска может быть изменен с утверждением пути команды. Например, Вы можете разрешить системе pablo выполнять команду rsmtp в дополнение к rmail и rnews: (11)
system pablo commands rmail rnews rsmtp
Выполнение Очереди Sendmail по требованию
Для обработки поставленных в очередь сообщений немедленно, просто набейте "/usr/lib/runq ". Это заставляет sendmail выполнить очередь заданий, немедленно а не ждать следующего планируемого.
Выполнение smail
Сначала, Вы должны решить, выполниться ли, smail как отдельный daemon, или управляет SMTP портом и smail вызывается только всякий раз, когда SMTP соединение запрошено от некоторого клиента. Обычно, Вы предпочтете операцию daemon на сервере почты, потому что это загружает машину гораздо меньше чем порождение smail много раз для каждого одиночного соединения. Поскольку сервер почты передает большинство входящей почты непосредственно пользователям, Вы выберете операцию inetd на большинстве других главных ЭВМ. Для любого режима работы, который Вы выбираете для каждого индивидуального host, Вы должны удостовериться, что Вы имеете следующий вход в вашем файле /etc/services: smtp 25/tcp # Simple Mail Transfer Protocol Это определяет TCP число порта, которое smail должен использовать для SMTP диалогов. 25 - стандарт, определенный Назначенными Числами RFC. В daemon режиме, smail поместится в фон, и будет ждать соединения на SMTP порте. Когда соединение происходит, он ветвится и проводит SMTP диалог с равным процессом. Smail daemon обычно запускается, как команда rc.inet2, используя следующую команду: /usr/local/bin/smail -bd -q15m -bd флаг включает daemon режим, а -q15m делает обработку сообщений в очереди каждые 15 минут.
Если Вы хотите использовать inetd взамен, ваш файл /etc/inetd.conf, должен содержать строку: smtp stream tcp nowait root /usr/sbin/smtpd smtpd Smtpd должен быть символическая связь к smail двоичному. Не забудьте, что Вы должны заставить inetd повторно-читать inetd.conf, посылая ему сигнал HUP после создания этих изменений. Daemon режим и inetd режим взаимно исключающиеся. Если Вы выполняете smail в deamon режиме, Вы должны удостовериться, и прокомментировать любую строку в inetd.conf для smtp обслуживания. При наличии inetd управления smail, удостоверитесь, что rc.inet2 не запускает smail daemon.
Запись главных файлов.
Рисунки 7.2.3, 7.2.3, 7.2.3, и 7.2.3 дают примерные файлы для названия сервера в brewery, размещенном на vlager. Вследствие характера обсуждаемой сети (единственная локальная вычислительная сеть), пример - довольно простой. Если ваши требования чересчур сложны, и Вы не можете запустить named, то вам поможет "DNS and BIND'' by Cricket Liu and Paul Albitz ([GETST "liu-dns"]).
& "
Кэш файл named.ca, который вы увидите на рисунке 7.2.3, показывает пример hint записи для root name сервера. Типичный кеш файл обычно описывает около дюжины серверов, или около того. Вы можете получить текущий список серверов для root области, используя nslookup, описанный ближе к концу этой главы.(3)
; ; /var/named/named.ca Cache file for the brewery. ; We're not on the Internet, so we don't need ; any root servers. To activate these ; records, remove the semicolons. ; ; . 99999999 IN NS NS.NIC.DDN.MIL ; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103 ; . 99999999 IN NS NS.NASA.GOV ; NS.NASA.GOV 99999999 IN A 128.102.16.10
Рисунок 10. Файл named.ca.
Запуск named.
Программа, которая обеспечивает обслуживание имени области на большинстве Unix машин обычно называется named. Эта программа первоначально разработанна для BSD обеспечения клиентуры, и ,возможно, для других серверов. Эта версия в настоящее время используется на большинстве Linux инсталяционных пакетов, как мне кажеться это BIND- 4.8.3. Новая версия, BIND-4.9.3, тестируется бетой в этот момент, и должна быть скоро доступна на Linux. Этот раздел требует некоторого понимания как работает Domain Name System. Если следующее изложение будет не совсем Вам понятно, то Вам следует перечитать главу 3., которая имеет более подробную информацию по основам DNS.
Named обычно запускается при начальной загрузке сичтемы, и работает пока машина вновь не перезагрузится. Она черпает информацию из конфигурационного файла называемого /etc/named.boot, и из различных файлов, которые содержат набор данных имен областей адресов. Далее они будут называться zone files. Форматы и семантика этих файлов будут объяснены в следующем разделе. Для запуска named, просто введите в командной строке:
# /usr/sbin/named
Появится named, читает named.boot файл и zone file, установленные там. Он записывает идентичность процесса id к /var/run/named.pid в ASCII, выгружая любые zone files из основных серверов, в случае необходимости запускает listening на порт 53 для запросов DNS. (1)
Запуск NIS Сервера
После такого многого теоретического techno-babble, это - время, чтобы очитстить наши руки от грязной работы с конфигурации. В этом разделе, мы опишем конфигурацию NIS сервера. Если имеется уже NIS запуск сервера на вашей сети, Вы не должны будете установить ваш собственный сервер; в этом случае, то Вы можете безопасно пропускать этот раздел.
<> Note that if you are just going to experiment with the server, make sure you don't set it up for a NIS domain name that is already in use on your network. This may disrupt the entire network service and make a lot of peo- ple very unhappy, and very angry.
В настоящее время используются два NIS сервера, свободно доступные для Linux, один содержится в yps пакете Tobias Reber's, и другой в Peter Erikson's ypserv package. Это не должно иметь значение, который Вы запускаете, независимо
от того, используете ли Вы NYS или NIS клиентский код, который находится в libc в настоящее время. Во время этой записи, цифра для обработки NIS подчиненных серверов, кажется, более полной в yps. Так что, если Вы должны иметь дело с подчиненными серверами, yps мог бы быть лучшим выбором.
После установки программы сервера (ypserv) в /usr/sbkn, Вы должны создать каталог, который будет проводить отображение, регистрируемо на Вашем сервере. При установке NIS области для brewery domain, отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это частную NIS область, проверяя есть ли каталог отображений. Если Вы блокируете обслуживание для некоторой NIS области, удостоверитесь удален ли каталог также.
Отображения обычно сохраняются в картотеках DBM, чтобы ускорить поиски. Они создаются от главы, регистрирующей использование программ, называемой makedbm (для Tobias' сервер) или dbmload (для сервера Peter's). Они не могут быть изменчивыми. Преобразовани е главы регистрирует в форму parseable dbmload обычно требуя некоторого awk или sed, которые имеют тенденцию, чтобы быть немного утомительными к типу. Следовательно, Peter Eriksson's Ypserv пакет содержит Формирование который делает всю работу за Вас. Вы должны установить это как Формирование файла в вашем отображении, и отредактировать это, чтобы отразить отображения которые Вы хотите распределить. В вершине файла Вы наход услуги Ypserv. По умолчанию, просмотры линии что - нибудь вроде этого:
all: ethers hosts networks protocols rpc services passwd group netid
Если Вы не хотите производить ethers.byname и ethers.byaddr отображения, например, просто удалите предпосылку эфиров из этого правила.Чтобы проверить вашу установку, это может удовлетворять тому, чтобы начать с только одного или двух отображении, подобно услугам. * Отображения.
После редактирования Формирования файла, в то время как Вы находитесь в каталоге отображений, набирите "make". Это автоматически генерирует и устанавливать отображения. Вы должны удостовериться, чтобы модифицировать отображения всякий раз, когда Вы изменяете главный файл, иначе изменения останутся невидимыми для сети.
Следующий раздел объясняет, кгк конфигурировать NIS клиентский код. Если ваша установка не работает, Вы должны пробовать выяснить или любые запросы достигнут вашего сервера или нет. Если Вы точно определяете команду -D, флажок линии к NYS серверу, то это печатает сообщения отладки на консоли относительно всех входящих запросов NIS, и возвращенных результатов. Они должны дать Вам подсказку относительно того, где задача находится. Tobias' сервер не имеет никакой такой опци
Запуск pppd
Когда Вы хотите соединитьcя с Internet через PPP связь, Вы должны установить базисные возможности работы с сетями типа возврата цикла, и решающего устройства. Оба были описаны в предыдчщих" главах. Имеются некоторые вещи, которые нужно упоминать относительно использования DNS над последовательной связью; пожалуйста обратитесь к SLIP главе для описания.
Как вводный пример того, как устанавливать PPP связь с pppd, представте, что Вы - во vlager снова. Вы уже соеденились с сервером по телефону, c3po, и зарегистрировались на ppp account. C3po уже запустила свой PPP драйвер. После выхода из коммуникационных программ, которые Вы используете для соединения по телефону, Вам необходимо выполнить следующую команду:
# pppd /dev/cua3 38400 crtscts defaultroute
Это переместит последовательную линию cua3 к PPP режиму и установит IP связь с c3po. Скорость передачи, используемая на последовательном порте будет 38400bps. Опция crtscts включает аппаратное рукопожатие на порт, который должен работать на скорости более чем 9600 бит\сек.
Первую вещь, которую pppd делает после запуска - договориться о некоторых характеристиках связи, используя LCP. Обычно, заданное по умолчанию множество опций, о котором pppd попробует договориться, так что мы не будем подробно вдаваться в это. Мы возвратимся к LCP более подробно несколько позже.
В настоящее время, мы также принимаем, что c3po не требует какого-либо установление нашей подлинности, так что период конфигурации завершен успешно.
Pppd будет договариваться о IP параметрах с peer используя IPCP, IP управляет протоколом. Так как мы не точно определяли IP
адрес к pppd выше, то он попробует использовать адрес, полученный при наличии решающего устройство, при просмотре локального hostname. И затем объявят этот адрес друг другу.
Обычно, ничего не случается с этими значениями по умолчанию. Даже если Ваша машина находится в Ethernet, Вы можете использовать тот же самый IP адрес для обоих. и для Ethernet, и для PPP interface. Но тем не менее, pppd позволяет Вам использовать различные адреса, или даже спрашивать Вашего peer для того, чтобы использовать некоторый специфический адрес. Эти опции обсуждены далее.
После прохождения IPCP периода установки, pppd подготовит Ваш host's networking layer для того, чтобы использовать PPP связь. Сначала будет сконфигурированн PPP сетевой interface как point-to-point связь, используя ppp0 для первой PPP cвязи, которая является активной, ppp1 для второй, и так далее. Затем, он установит маршрутную таблицу, которая указывает на хост в другом конце связи. В примере, показанном выше, pppd сделает заданный по умолчанию сетевой маршрут к c3 опциии defaultroute. (5) Он азаставляет все датаграммы к хостам не на вашей локальной сети быть посланными к C3po. Имеется ряд различных маршрутов, которые pppd поддерживает, которые мы обсудим позже в этой главе.
Запуск в server режиме
Установка вашего SLIP клиента была трудной частью. Выполнение противоположного, а именно конфигурирование вашего хоста для того, чтобы действовать как SLIP сервер, - намного проще.
Единственный способ сделать это - использовать dip в server режиме, который может быть достигнут, вызывая его как diplogin. Его главный файл конфигурации - /etc/diphosts, который присоединяет login имена к адресу этого хоста. В качестве альтернативы, Вы можете также использовать sliplogin, BSD-производное средство, которое описывает более гибкую схему конфигурации, которая позволяет Вам выполнить shell scripts всякий раз, когда хост соединяется и разъединяется. В настоящее время это происходит на Бете.
Обе программы требуют, чтобы Вы установили один login account на каждого SLIP клиента. Например, представте что Вы обеспечиваете SLIP обслуживание Arthur Dent в Dent.beta.com, Вы могли бы создать account названный dent, добавляя следующюю строку к вашему файлу пароля(passwd file):
dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin
Впоследствии, Вы должны были бы установит пароль Dent(а), утилиту passwd.
Теперь, когда dent подключен, dip запустится как сервер. Чтобы определить, действительно ли ему разрешено использовать SLIP, нужно найти имя пользователя в /etc/diphosts. Этот файл подробно описывает& птава доступа и параметры соединения для каждого SLIP пользователя. Типовая запись для dent могла бы быть похожа на:
dent::dent.beta.com:Arthur Dent:SLIP,296
Первая из отделяемых двоеточием областей - имя пользователя под которым он должен войти. Вторая область может содержать дополнительный пароль (см. ниже). Третья - hostname или IP адрес вызываемого хоста. Далее идет информационная область без специального значения (пока еще). Последняя область описывает параметры соединения. Это - список, отделенный запятыми, определяющий протокол (в настоящее время один из SLIP и CSLIP), следуя за MTU.
Когда dent входит в систему, diplogin извлекает информацию относительно него из diphosts файла, и, если вторая область не пуста, подсказывает " Пароль внешней защиты ''. Строка, введенная пользователем - сравнивается с (нешифрованным) паролем из diphosts. Если они не соответствуют, то попытка входа в систему будет отклонена.
Это связь остается установленной, пока пользователь не отсоединяется, или модем не бросает линию. Diplogin затем возвратит линию к нормальной discipline line и выйдет.
Diplogin требует привилегии супер-пользователя. Если Вы запустили dip setuid root, то Вы должны сделать diplogin отдельной копией dip(а) вместо простой связи. Diplogin может затем быть сделан setuid, без воздействия на состояние dip непосредственно.
Защита против Жуликов
Одна из самых больших проблем UUCP - то, что система вызова может назвать не свое имя; она объявляет имя вызываемой системе после фактического входа, но сервер не может проверить этого. Таким образом, нападающий может войти под своим именем UUCP, симулировать, что был кем -то еще, и прочитатьчужую почту. Это особенно опасно, если Вы предлагаете вход в систему через анонимный UUCP,чей пароль общеизвестен. Если Вы не уверены, что Вы можете доверять всем системам, которые вызывают вашу, Вы должны принять меры против самозванцев/Для"этого необходимо потребовать, чтобы каждая система использовала имя входа в систему, заданное called-login в sys.Например:
system pablo called-login Upablo
13. Опция -u присутствует в версии 1.04 также, но ничего не делает.
В результате этого всякий раз, когда система говорит, что она - pablo, uucico проверит, регистрировалась ли она как Upablo. Если же нет, вызов будет отвергнут, а соединение разорвано. Вы должны делать это привычка добавить команду вызываемого - входа в систему к каждому входу системы, который Вы добавляете к вашему системному файлу. Важно, что Вы делаете это для всего sytems, независимо от того, ли они будут когда-либо вызывать ваше место или нет. Для тех мест, которые никогда не вызывают Вас, Вы должны возможно установить вызываемый - вход в систему к некоторым полностью поддельное имя пользователя, типа neverlogsin.
Знакомство с NIS
NIS хранит информацию баз данных, находящихся в так называемых отображениях, содержащих keyvalue pairs. Отображения сохранены на центральном хосте, выполняющем NIS сервер, из которого клиентура может отыскивать информацию через различные RPC вызовы. Совершенно часто, отображения сохранены в файлах DBM. (4)
Отпбражения сами по себе обычно генерируются из текстовых файлов типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные отображения - созданы, один для каждого типа клавиши. Например, Вы можете искать хост файл для имени хоста также как для адреса IP. Соответственно, два NIS отображения получены из файла, вызываемый hosts.byname и hosts.byaddr, соответственно. Таблица 11.1 списков общих отображений и файлов из кооторых они сгенерированны.
4. DBM - простая библиотека управления базой данных которая использует метод хеширования, чтобы ускорить операцию исследования. Имеется свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который является частью большинства Linux распространен ия.
----------------------------------------------------------- +-----------------+---------------------------------------+ |Master File | Map(s) | +-----------------+---------------------------------------+ +-----------------+---------------------------------------+ |/etc/hosts | hosts.byname hosts.byaddr | |/etc/networks | networks.byname networks.byaddr | |/etc/passwd | passwd.byname passwd.byuid | |/etc/group | group.byname group.bygid | |/etc/services | services.byname services.bynumber | |/etc/rpc | rpc.byname rpc.bynumber | |/etc/protocols | protocols.byname protocols.bynumber | |/usr/lib/aliases | mail.aliases | +-----------------+---------------------------------------+ +-----------------+---------------------------------------+
Таблица 1. Некоторый стандарт NIS отображения и соответствующие чайлы.
Имеются другие файлы и отображения, которые Вы можете найти в любом NIS пакете или другом. Они могут содержать информацию для приложений не обсуждаемых в этой книге, типа bootparams отображения, которое может использоваться некоторыми BOOTP серверами, или подобно которому в настоящее время не имеют любую функцию в Linux (Ethers.byname и ethers.byaddr отображения).
Для некоторых отображений, люди обычно используют прозвища, которые являются короткими следовательно проще. Получать полный список прозвищ понимаемый вашими NIS инструментальными средствами, запустите следующую команду:
$ ypcat -x NIS map nickname translation table: "passwd" -> "passwd.byname" "group" -> "group.byname" "networks" -> "networks.byaddr" "hosts" -> "hosts.byname" "protocols" -> "protocols.bynumber" "services" -> "services.byname" "aliases" -> "mail.aliases" "ethers" -> "ethers.byname" "rpc" -> "rpc.bynumber" "netmasks" -> "netmasks.byaddr" "publickey" -> "publickey.byname" "netid" -> "netid.byname" "passwd.adjunct" -> "passwd.adjunct.byname" "group.adjunct" -> "group.adjunct.byname" "timezone" -> "timezone.byname"
NIS сервер традиционно называется ypserv. Для средней сети единственного сервера обычно хватает; большие сети могут выбирать несколько серверов на различных машинах и различных сегментах сети, чтобы уменьшить загрузку на машинах сервера и программах маршрутизации. Они синхронизированы, делая один из них главным сервером, к другие подчиненными серверами. Отображения будут созданы только на master server's host. Оттуда, они распределены всем slaves/
Вы отметили, что мы говорили относительно " сети " очень неопределенно все время; конечно имеется отличительное понятие в NIS, которое относится к такой сети, и которая является системой всех хостов та часть их данных конфигурации системы сделанны через NIS: NIS область. К сожалению, NIS области не имеют абсолютно ничего общего с областями, с которыми мы столкнулись в DNS. Избегая любой неоднозначности через эту главу, я буду всегда точно определять который тип области
NIS области имеют совершенно административную функцию только. Они обычно невидимы для пользователей, кроме разделения паролей между всеми машинами в области. Следовательно, название, данное NIS области релевантно только администраторам. Обычно, любое название будет как длинный поскольку это отлично от любого другого NIS названия области на вашей локальной сети. апример, администратор в Virtual Brewery может создайть две NIS области, одну для Brewery непосредственно, и о которыу она называет brewery и winery, соответственно. Другая совершенно общая схема для того, чтобы просто использовать DNS название области для NIS. Чтобы установить и показать NIS название области вашего множества, domainname. Когда она вызывается без любого аргумента, это печатает текущее NIS название области; к множеству названия области, Вы должны стать супер пользователеми ввести:
# domainname brewery
NIS области определяют, какой NIS сервер-приложение сделает запрос. Например, программа входа в систему на множестве в Winery должна, сделать запрос NIS сервера Winery (или один из них, если они там были отделены) для информации пароля пользователя; в то время как приложение на Brewery host должно приклеится к серверу Brewery'.
Одна тайна, которая пстазтся все еще не решенной, а именно, как клиент узнает с каким сервером он соединен. Самое простое приближение было бы иметь файл конфигурации, который называет хост, чтобы найти сервер. Однако, это приближение было бы довольно негибко, потому что это не позволяет клиентуре использовать различные серверы (из той же самой области, конечно), в зависимости от их доступности. Следовательно, традиционный NIS implementations полагаются на специальный d чтобы обнаружить подходящий NIS сервер в их NIS области. Перед способностью выполнить любой NIS
Запрос, любое приложение, сначала выясняти от ypbind который сервер используется.
Ypbind исследует серверы, передавая к локальной IP сети; сначало первый ответ принят, чтобы быть потенциально самым быстрым и будет использоваться во всех последовательных запросах NIS. После того, как некоторый интервал истек, или если сервер становится недоступным, ypbind, исследует активные серверы снова.
Теперь, спорная точка относительно динамического связывания - то, что Вы редко нуждайтесь в этом, и что это вводит задачу защиты: ypbind слепо верит, кто бы ни отвечаел, который мог бы быть NIS сервером также как и "злоумышленник". Само собой разумеется это становится затруднением - если Вы управляете вашими базами данных паролей над NIS. Для принятия мер против этого, NYS не использует ypbind по умолчанию, но подбирает сервер для имени хостаиз файла конфигурации.